[12:54] [chaoticg33k(n=chaoticg@alphabox.cxw.utoledo.edu)]  hello
[01:49] <jme> I suppose this is the wrong place to ask re Usplash configuration
[05:45] <oneman> my upstart jobs in edgy are not starting on startup..
[05:45] <oneman> it works with start and stop
[05:46] <oneman> i also notice it doesn't work with daemons that fork off and become a session leader..
[05:47] <_ion> Add something like 'start on runlevel-2'
[05:47] <_ion> Add 'daemon' for a forking daemon.
[05:51] <oneman> ive got start on startup :P
[05:51] <oneman> where do i put daemon, just anywhere?
[05:59] <_ion> "start on startup" means that it's started before filesystems have been checked, or networking has been started, or syslogd has been started etc.
[05:59] <_ion> Yes.
[05:59] <_ion> I'd put it just before or after the 'exec foo' or 'respawn foo' line, or just before the 'script' block.
[06:01] <oneman> ohh
[06:02] <oneman> ok, for lighttpd
[06:02] <oneman> daemon worked for starting, but it doesn't kill it on stop
[07:00] <oneman> upstart is cool
[07:00] <oneman> but its apha betaboy stuff
[07:01] <oneman> and you have to go talk to the developers themselfs on internet chat to get them to tell you secret undocumented information to really do anything
[10:56] <H__2> anyone awake ?
[11:02] <Keybuk> yup
[11:02] <Keybuk> what's up?
[11:04] <H__2> i have a question about the new developments : the job-starting and such. Is the following planned : when service A requires service B, and B is restarted, is then A stopped before B stops and A started after B started again ?
[11:05] <Keybuk> it depends
[11:06] <H__2> ;-)
[11:06] <Keybuk> if A wants to be restarted when B is restarted, it would indicate as such in its job definition
[11:06] <Keybuk> e.g.
[11:06] <Keybuk> stop on job-stopped B
[11:06] <Keybuk> start on job-started B
[11:06] <H__2> ok, does "stop on job-stopped B" mean that A stops after B stopped ?
[11:07] <Keybuk> no
[11:07] <Keybuk> it means B stops because A is
[11:08] <H__2> Can't follow you there. This is the scenario : A requires B. B is restarted, the question is what happens to A, and in what order
[11:08] <Keybuk> B is stopped
[11:08] <Keybuk> A is stopped
[11:08] <Keybuk> B is started
[11:08] <Keybuk> A is started
[11:08] <Keybuk> with that example
[11:09] <H__2> exactly, so  A stops after B stopped. I think that is wrong.
[11:09] <Keybuk> if you needed it in the other order, you'd use "stop on job-pre-stop B" or similar
[11:09] <Keybuk> upstart doesn't enforce any of this, it simply issues sufficient events for you to define the behaviour
[11:09] <H__2> ah, perfect :)
[11:10] <H__2> very interesting
[11:11] <H__2> another small question : from the website "being developed for the Ubuntu distribution" does that mean that Ubuntu now actively uses it, or that it is targetted to replacing the system currently present in ubuntu ?
[11:12] <thom> H__2: ubuntu now uses it
[11:13] <H__2> nice, thanks. Will look into it.
[11:14] <Keybuk> (as of the release of edgy, yesterday)
[11:20] <H__2> is there a way in upstart to draw a dependency graph of a bunch of scripts that subscribed to upstart's events ?
[11:20] <Keybuk> there may be eventually, yes
[11:20] <Keybuk> I think that such a thing would be useful
[11:21] <H__2> heh :) I've been drawing those by hand and sometimes using graphviz ;-)
[11:21] <Keybuk> I figured upstart would output dotty
[11:29] <H__2> the example jobs from the homepage (http://upstart.ubuntu.com/download/example-jobs-2.tar.gz) don't have "job-pre-stop"-level rules, is there a second list of examples available for download perhaps ?
[11:31] <Keybuk> job-pre-stop rules don't exist yet
[11:32] <Keybuk> upstart's still in heavy development
[11:32] <Keybuk> they're planned for the 0.3 series
[11:32] <H__2> ow ;-)
[11:33] <H__2> I got the impression from your ' you'd use "stop on job-pre-stop B" ' that it was already available ;-)
[11:33] <Keybuk> you'd use "stop on B/stopping" at the moment
[11:34] <Keybuk> (and "start on B/starting")
[11:34] <Keybuk> they mean about the same thing
[11:34] <H__2> well, it's a race we suffer from at the moment. So we still must use our proprietary solution
[11:39] <H__2> another question : is the event queue re-read and any new (or removed) subscriber results merged with the active queue after any upstart action ?
[11:39] <Keybuk> not sure I understand the question>?
[11:39] <H__2> ok, i'll make up an axample :
[11:41] <H__2> let's say that upstart is active and it as to start scripts A, B, C and D (in that order). And it just finished starting B. This script B has enabled another event script called X. The dependency order of X is that it has to start before C. What does upstart do ?
[11:42] <Keybuk> upstart doesn't have dependency orders
[11:42] <Keybuk> it's not a dependency-based init system
[11:42] <Keybuk> it would be better if you phrased your question in terms of a real example
[11:43] <H__2> well, it is actually a real example, but from a proprietary system I wrote
[11:43] <Keybuk> ok
[11:43] <Keybuk> so you have four jobs, A, B, C and D
[11:44] <H__2> yes
[11:44] <Keybuk> B starts on job-started A, C starts on job-started B, D starts on job-started C
[11:44] <H__2> yes
[11:44] <Keybuk> what do you mean by "enabled another event script" ?
[11:46] <H__2> Let's say that script B wrote a script X (or copied it into place), and if available then C wants X to have started before C itself starts.
[11:47] <Keybuk> so C should be started by the "X started" event
[11:47] <Keybuk> not the one for B
[11:48] <H__2> the C - B relationship is not changed, there is a new one inserted halfway
[11:48] <H__2> and indeed, 'C should be started by the "X started" event'.
[11:50] <Keybuk> you're confusing relationships and events
[11:50] <Keybuk> upstart isn't a dependency-based init system ;)
[11:50] <Keybuk> it doesn't have relationships
[11:50] <H__2> possibly, i'm new to upstart terminology
[11:51] <Keybuk> it takes a little bit of a backstep to understand how to translate dependency-based information into event-base
[11:51] <Keybuk> they're not a 1:1 mapping by any means, and are quite different
[11:51] <Keybuk> we're convinced event-based is better
[11:52] <Keybuk> but it does mean that if you come from init-ng, gentoo, etc. you can't just run some perl/sed over the init script to get an upstart one -- you have to rethink how the service is started
[11:52] <Keybuk> and how multiple jobs interact (rather than depend)
[11:54] <H__2> ok
[11:55] <H__2> (I don't come from  init-ng, gentoo, etc, it's my proprietary development. And I'm wondering whether it can be replaced)
[11:56] <Keybuk> so the basic theory of upstart is not that services depend or require one another
[11:56] <H__2> so far upstart comes closest :)
[11:56] <Keybuk> but that services are started because other things happen
[11:56] <Keybuk> this is because in reality most things don't depend on another service, but an abstract concept
[11:56] <Keybuk> e.g. "on battery power"
[11:57] <H__2> well
[11:57] <H__2> what we have is fi. a script that creates an tunnel device, to which other services want to bind. I call that a dependency.
[11:57] <Keybuk> right
[11:58] <Keybuk> so the obvious change there is
[11:58] <Keybuk> other services do not depend on a script that creates a tunnel device
[11:58] <H__2> and if this tunnel device disappears, then the others are in trouble, they must be stopped upfront
[11:58] <Keybuk> instead, other services need the tunnel device!
[11:58] <Keybuk> so in upstart, you'd do "on network-device-added tun0"
[11:58] <Keybuk> and make sure udev sent that event to it
[11:58] <Keybuk> that way the services come up with the tunnel
[11:59] <Keybuk> likewise, you'd stop them because the tunnel device went away
[11:59] <Keybuk> which means even if the user ifconfig'd it down, the services would stop
[11:59] <H__2> went away is too late ;-) will go away is what we need
[11:59] <Keybuk> there's no way to know it "will go away"
[11:59] <Keybuk> ifconfig tun0 down
[11:59] <Keybuk> *boom*
[11:59] <Keybuk> you can have a "bring tunnel down safely" script
[12:00] <Keybuk> that can issue a "going to take tunnel down" event which stops the services
[12:00] <Keybuk> but they should also be stopped if the tunnel goes away unexpectedly
[12:00] <H__2> yes the 'die unexpectedly' is a different problem
[12:00] <Keybuk> we think it's the same one
[12:01] <H__2> interesting :)
[12:01] <Keybuk> so how I'd do that would be have
[12:01] <Keybuk> /sbin/remove-tunnel which is a script that does
[12:01] <Keybuk> initctl emit network-device-going-down tun0
[12:01] <Keybuk> ifconfig tun0 down
[12:01] <Keybuk> --
[12:01] <Keybuk> and then have the services include both
[12:01] <Keybuk> stop on network-device-going-down tun0
[12:01] <Keybuk> stop on network-device-down tun0
[12:01] <Keybuk> --
[12:02] <Keybuk> that way your services can safely come down if the script is used
[12:02] <Keybuk> but also come down if the script isn't used
[12:02] <Keybuk> one should try one's best to have the services at least deal with that sanely, where sane can include logging an error in syslog
[12:02] <hunger> Keybuk: Did you upstartify ifup/ifdown?
[12:02] <Keybuk> hunger: not yet, https://launchpad.net/distros/ubuntu/+spec/replacement-network-events
[12:03] <H__2> the " have the services at least deal with that sanely" is indeed what we want, sadly that piece of software is out of our control :-/
[12:06] <hunger> Is there a timeline for upstart in feisty yet?
[12:06] <H__2> why don't you call the " stop on network-device-going-down tun0" a dependency ? to me that is a fine example of a dependency
[12:06] <Keybuk> hunger: what kind of timeline?
[12:07] <Keybuk> H__2: because dependency infers in people's mind certain semantics; which don't exist in this case.  "network-device-going-down" is an event, it's something that happens
[12:07] <hunger> Keybuk: Like what is planned for when. On second thought I guess that will be in the specs once they become available.
[12:07] <Keybuk> hunger: the specs are already registered, just not yet written
[12:07] <hunger> Keybuk: I noticed:-)
[12:08] <hunger> I think I'll need to spend some time hacking my cryptdisk setup into your scripts when those hit the repositories.
[12:08] <H__2> heh :) and if others want to be notified of such events you still don't call that a dependency ? A subscription then perhaps ?
[12:08] <Keybuk> H__2: the particular case is "start on foo"
[12:09] <Keybuk> if bar depends on foo, people assume that even if bar is created after foo has been started, bar will be started
[12:09] <Keybuk> whereas when "foo" is an event, people realise that it's forgotten about once it happens
[12:11] <H__2> I don't get this "if bar depends on foo, people assume that even if bar is created after foo has been started, bar will be started" If bar depends on foo, then bar cannot be started if foo's not there. But if foo is there then bar can start.
[12:12] <Keybuk> yes
[12:12] <Keybuk> exactly
[12:12] <Keybuk> that's what dependency infers
[12:12] <Keybuk> which is why we don't use that term for upstart
[12:12] <Keybuk> bar can be started manually at any time
[12:13] <Keybuk> it's up to bar to decide whether it should fail to start because foo is not running
[12:13] <H__2> in my world it can not
[12:13] <H__2> but I think I see what you mean
[12:13] <Keybuk> unfortunately, without you elaborating on what your world is, I can't understand
[12:14] <Keybuk> if a service depends on a tunnel device, and that tunnel device is not present when it is started, /it should fail anyway!/
[12:14] <Keybuk> and it should present a useful error message to debug that failure
[12:14] <H__2> it should not even try to start, controlled by the service trying to start it
[12:14] <Keybuk> why not?
[12:15] <Keybuk> the sysadmin should always be able to get their hands dirty and try things
[12:15] <H__2> because we know it will fail
[12:15] <Keybuk> you don't know it will fail
[12:15] <Keybuk> the sysadmin may have created the tunnel by hand
[12:15] <H__2> true, interesting. Let's say "there is no sysadmin". these are embedded systems.
[12:16] <Keybuk> then you don't need to worry about this scenario, because it's inherently not possible ;)
[12:16] <Keybuk> if you have no tinkering sysadmin, then you can ignore it
[12:16] <H__2> I think you lost the plot :)
[12:16] <Keybuk> ?
[12:16] <Keybuk> I haven't been told the plot
[12:17] <H__2> I'll try to describe it better
[12:23] <H__2> that turns out to be quite hard. I'm not sure what to add to it what would help us.
[12:24] <Keybuk> you're saying that "bar should not be able to start if foo isn't running"
[12:24] <Keybuk> but I'm saying that if the only thing that can start bar is the init daemon, then you don't need to worry about that eventuality
[12:25] <Keybuk> nothing will try to start bar except the init daemon, as a result of the events that are listed as causing it to start
[12:25] <H__2> maybe this : if A has a "start on" subscription to B, and upstart just tried to start B, but B failed, does upstart then continue starting A ?
[12:25] <Keybuk> depends on the event subscribed to
[12:25] <Keybuk> if the event is the started one, then no
[12:25] <Keybuk> if it's the starting one, then yes
[12:26] <H__2> ok, clear :)
[12:28] <Keybuk> sorry that it seems a little confusing, it's much easier to demonstrate with examples
[12:29] <H__2> Can you elaborate a bit more on the "A has a dependency on B" versus "A is subscribed to an event of B" difference you make ?
[12:32] <Keybuk> upstart issues events as B changes state
[12:32] <Keybuk> e.g. job-starting, job-started, job-failed, job-stopping, job-stopped, etc.
[12:33] <Keybuk> if A is subscribed to any of those events, then it will be started or stopped if an event occurs
[12:34] <Keybuk> events are one-shot things, they are emitted, get handled by changing the state of any subscribed job, and then get forgotten about
[12:34] <Keybuk> they can be emitted by any part of the system
[12:34] <Keybuk> as well as job-started, you can also have network-device-added, block-device-added, path-mounted, battery-power, etc.
[12:35] <H__2> Ok, that part is clear. The question is why it is not considered to be a dependency. The end result in bout our systems is the same btw :)
[12:35] <H__2> bout->both
[12:35] <Keybuk> the word dependency conjours up certain things in people's minds
[12:35] <Keybuk> if I say that "foo depends on bar", then I would assume certain things:
[12:35] <Keybuk> - bar is started if I try and start foo
[12:36] <Keybuk> - if bar fails to start, foo does not start
[12:36] <Keybuk> - if bar is already running when I try and start foo, then foo is started
[12:36] <Keybuk> - if foo stops, and nothing else depends on bar, bar is stopped
[12:36] <Keybuk> - bar cannot be started if foo doesn't exist (or is disabled)
[12:37] <H__2> don't agree with " - if foo stops, and nothing else depends on bar, bar is stopped", and the one after it too, the rest: yes
[12:37] <Keybuk> while all of these things can be replicated in upstart with a combination of events, simply adding "start on job-started bar" does *not*
[12:37] <Keybuk> H__2: dependency-based init systems do that
[12:38] <H__2> only if they are bi-directional dependencies IMO
[12:38] <H__2> bar doesn't care if there's a foo that wants to use it, so if foo is stopped, bar doesn't care
[12:40] <Keybuk> but that's not what a dependency-based init system does
[12:40] <Keybuk> so calling events dependencies, in an init system, would confuse people
[12:41] <H__2> ah, that's then where our confusion comes from. It is what a dependency-based init system does in our opinion (see Gentoo for example).
[12:41] <H__2> dependencies have only one direction.
[12:41] <H__2> a system with bi-directional dependencies cannot start :)
[12:42] <Keybuk> I'm completely unfamilar with Gentoo's, I'm afraid
[12:42] <Keybuk> the way that initNG and SMF work is to start a set of goal services, which cause their dependencies to start, et. al. down the list
[12:42] <Keybuk> if you stop a goal service, than any dependencies unused by anything else are also stopped
[12:43] <Keybuk> this is consistent with dependencies in the package manager as well
[12:43] <H__2> I'm unfamiliar with  initNG and SMF :)
[12:44] <H__2> I would say " up the list" instead of " down the list" in 2 lines up
[12:45] <Keybuk> also to me, depends infers state tracking
[12:45] <Keybuk> "bar depends on network-device tun0"
[12:45] <Keybuk> which implies that the state of that network device is tracked
[12:45] <Keybuk> upstart relies on something else to track the state, and issue the events when it changes
[12:45] <H__2> ideally yes
[12:45] <Keybuk> so instead
[12:45] <Keybuk> "start bar on network-device-added tun0"
[12:45] <Keybuk> "stop bar on network-device-removed tun0"
[12:45] <Keybuk> type thing
[12:45] <H__2> clear
[12:46] <H__2> in our system the tracking is present, but handled outside the 'upstart' alternative. By using blunt checkscripts :)
[12:47] <H__2> can only do polling from scripts there, in most cases.
[12:47] <Keybuk> upstart is intended to be useful where you have events from other systems
[12:47] <Keybuk> and don't need to poll
[12:47] <Keybuk> e.g. udev for hardware
[12:48] <H__2> clear
[12:48] <hunger> Keybuk: I like the heartbeat idea that came up on the -devel ML.
[12:48] <hunger> Keybuk: That would absolutely rock for the server crowd.
[12:49] <H__2> ;-)
[12:49] <H__2> just joking, besides they're probably different anyway
[12:49] <Keybuk> hunger: without knowing much about heartbeat, I couldn't comment much
[12:50] <hunger> Keybuk: heartbeat is pretty simple: basically it is just doing something when the heartbeat is no longer heared.
[12:51] <H__2> from where to where is this heartbeat communicated ? what does it monitor ?
[12:51] <hunger> Keybuk: I only ever used something like that on AIX, so I can not comment on how linux works either.
[12:52] <hunger> H__2: heartbeat is used for eg. when you want a highly available webserver. You set up two that send each other heartbeat signals.
[12:52] <H__2> ok, so 'total service' is monitored
[12:52] <H__2> then it's the same as what we have
[12:52] <hunger> H__2: When the hearbeat of the master is no longer heared by the slave that takes over IPs and stuff and continues.
[12:52] <H__2> clear
[12:53] <Keybuk> you could have heartbeat emit a "flatline" event ;)
[12:53] <Keybuk> and then write upstart jobs with "on flatline"
[12:53] <hunger> Keybuk: Yes, exactly.
[12:53] <H__2> ack
[12:54] <Keybuk> it's a definite goal to get rid of everything's *.d script directories
[12:54] <H__2> btw, FreeBSD now has a similar dependency system in their init scripts (as what I talked about earlier)
[12:55] <H__2> with complaints like : % rcorder: requirement `named' in file `/usr/local/etc/rc.d/samba.sh' has no pro
[12:55] <H__2> viders.
[12:56] <H__2> nice to see the world moving in the same direction :)
[12:56] <Keybuk> right, but bear in mind that upstart doesn't do that ;P  it's not a dependency-based init system
[12:57] <Keybuk> in an upstart system, samba instead would be started by an event such as "dns-available"
[12:57] <H__2> and a lot more I hope
[12:57] <Keybuk> and that event could be emitted by either the bind9 job, a dhclient job or a network interface job if it detects an available IP in /etc/resolv.conf
[12:58] <hunger> Keybuk: That is the one weakness I see in upstart: It will be a PITA to figure out on which events to react, there being so many of them.
[12:59] <H__2> hey, if I understand right the need for 2 providors is also not present in upstart, like samba starts on 'dns-available' but samba also needs 'eth0 available' which may not be there yet, so samba would get started another time lateron when 'eth0' appears, right ?
[12:59] <hunger> Keybuk: And that some things will end up depending on more than one event will make things even worse.
[12:59] <Keybuk> H__2: not currently, methods of doing that are being discussed and will be in 1.0
[01:00] <H__2> and will still not be called dependencies, right ? ;-) (sorry , couldn't resist)
[01:00] <hunger> H__2: ... and all-exported-filesystems-available is another candidate ...
[01:00] <H__2> I'll get some coffee now
[01:02] <Keybuk> it depends on the semantics
[01:02] <Keybuk> we've talked about the idea of having jobs "wait" for an event
[01:02] <Keybuk> so one might do:
[01:02] <Keybuk> start on foo
[01:03] <Keybuk> wait for network-device-added eth0
[01:03] <Keybuk> wait for dns-available
[01:03] <Keybuk> --
[01:03] <Keybuk> does this mean that dns-available has to occur *after* foo
[01:03] <Keybuk> or does this mean that dns-available just has to occur at any point on the system
[01:03] <hunger> Keybuk: Will that work if dns-available happens before foo?
[01:03] <Keybuk> hunger: exactly
[01:04] <hunger> Keybuk: I have thought about how to integrate my cryptsetup script with upstart.
[01:04] <Keybuk> and how does that work if the network device comes back down again?
[01:04] <hunger> Keybuk: In addition to what the normal one shipped with ubuntu can do mine can mount a FS, read keys from there, mount other FSes and then unmount the key-FS again.
[01:04] <Keybuk> the network-device-added event happened, so that "wait" has been fulfilled
[01:05] <hunger> So basically I would need to make sure that the key-FS is setup and mounted before any FS it contains a key for and then unmount it again once all of them are up. No idea how I can express that in events.
[01:06] <Keybuk> why unmount the key FS?
[01:06] <hunger> Keybuk: So that nobody can get the keys once the system is up.
[01:07] <Keybuk> they could just mount it? :p
[01:07] <hunger> Keybuk: I unmount the FS and destruct its decrypted device. That way only the encrypted device is visible once the other crypted FSes are up.
[01:07] <H__2> I'll ask for open-source clearance once more, i'm very interested in what you have to say about it
[01:08] <hunger> all that happens before the network comes up, so I am pretty sure nobody can steal my keys;-)
[01:11] <H__2> only the tempest crew in the other building :-P
[01:11] <hunger> H__2: upstart breaks the displaying of the password prompt... that might confuse those guys;-)
[01:12] <H__2> Keybuk : is there an advanced examples tar ball ?
[01:12] <H__2> hunger: heh :o)
[01:12] <Keybuk> H__2: no
[01:13] <Keybuk> hunger: I don't understand why
[01:14] <H__2> ok, then maybe in Ubuntu 6.10 ?
[01:14] <hunger> edgy is screwed up wrt. displaying startup info anyway... running usplash gives the password prompt and displays the password which is even worse IMHO.
[01:14] <Keybuk> 6.10 was released yesterday
[01:14] <Keybuk> hunger: "screwed up" ?
[01:15] <H__2> i know it was released yesterday, I meant to ask whether it did contain more advanced stuff than the examples tar ball
[01:15] <Keybuk> no, the examples tar ball is the copy of the jobs from ubuntu 6.10
[01:15] <H__2> aah, ok :)
[01:16] <hunger> Keybuk: Without usplash: no password prompt, with usplash: password prompt is displayed but password is echoed to the screen.
[01:17] <hunger> Both is not really the way I expected it to be;-)
[01:17] <H__2> Thanks for the chat. (I'm off for a lunch-walk now.)
[10:31] <phsdv> hi all, I just managed to get my gentoo system booted using upstart.
[10:33] <phsdv> but I am getting some errors like: control-alt-delete: init: /dev/initctl: No such file or directory
[10:34] <phsdv> does someone know how to fix that?


[00:48] <dmcglone> Hi all
[01:10] <Cheri703> hi
[01:29] <dmcglone> I'm bored! LOL thats rare, but yeah I'll say it again.. I'm bored..
[01:33] <Cheri703> ha, yeah, I've had a VERY unproductive week....been doing a whole lot of nothing :/
[01:42] <dmcglone> sounds like what i do everyday
[01:42] <dmcglone> LOL
[01:42] <Cheri703> we have watched 3.5 seasons of battlestar galactica this week...
[01:43] <dmcglone> dang, you must hate it now
[01:43] <Cheri703> well, we're in the final season now
[01:43] <Cheri703> just about halfway through it
[01:44] <Cheri703> I watch LOTS of shows start to finish, all seasons until caught up or done
[01:44] <dmcglone> how did you get the whole season?
[01:44] <Cheri703> I honestly can't name all of them
[01:44] <Cheri703> ...magic
[01:44] <dmcglone> oh come on
[01:44] <dmcglone> hulu?
[01:45] <Cheri703> >.>
[01:45] <Cheri703> <.<
[01:45] <Cheri703> let's call it netflix
[01:46] <dmcglone> I'm not gonna fall for that unless your running windows... LOL
[01:59] <dmcglone> well I guess your not gonna tell
[02:00] <Cheri703> not in a logged channel :)
[02:04] <Unit193> Have a nice walk?
[02:05]  * Cheri703 didn't go
[02:06] <dmcglone> Hi Unit193
[02:06] <Unit193> Hello dmcglone!
[02:06] <Unit193> Find anything to do?
[02:08] <dmcglone> not really. just sitting here watching everybody loves chris
[02:14] <dmcglone> I still haven't heard from anybody on the time for the meet. I don't know whether to reserve the room or not
[02:14] <Unit193> One of them said another day would work better
[02:18] <dmcglone> I just checked my E-mail. Gilbert suggested the day after that. What does everybody here think about that?
[02:19] <Cheri703> sundays are less than ideal for me, but...majority rule I suppose
[02:19] <Cheri703> I'd just start looking at days that afternoons are available
[02:20] <dmcglone> yeah, maybe a weekend in may or june
[02:21] <dmcglone> I know we are trying to get something close to release, but that might be a tall order. But we may be able to look into other libraries around columbus
[02:21] <Cheri703> I don't think (could be wrong) that others have rooms as large (or are as easily accessed by OSU folks
[02:21] <Cheri703> )
[02:22] <dmcglone> the main library isn't anywhere close to OSU either
[02:22] <Unit193> Back!
[02:22] <Cheri703> true, but buses going downtown is easier than buses to grove city or dublin or wherever
[02:24] <dmcglone> ok let me think. I might be able to find a couple alternatives
[02:35] <dmcglone> Well I'm gonna go relax. I'll look around tomorrow for alternative places
[02:35] <dmcglone> I'll talk to you guys later
[02:35] <Unit193> Have fun!


[01:53] <zul> heylo
[02:58] <jbailey> BenC: Around?
[02:58] <BenC> jbailey: yeah
[02:58] <jbailey> BenC: Awhile ago I had bugged you about the machine freezes on the G5.  I don't know if we ever settled whether it was a kernel issue or an X issue.
[02:59] <jbailey> We had talked abotu disabling the radeon kernel driver on ppc64 to solve the problem for dapper if we didn't hit a better solution.
[02:59] <BenC> ah, I think the next kernel might interest you :)
[03:00] <BenC> care to test a ppc64 kernel from current git?
[03:00] <jbailey> Ah?  Okay.  I won't automatically do a sudo find /lib/modules -name radeon.ko -exec rm '{}' \; when it shows up then. =)
[03:00] <jbailey> Sure.  Is it hard to build?
[03:00] <BenC> I have one already built
[03:00] <jbailey> \o/
[03:00] <BenC> let me upload it somewhere
[03:00] <jbailey> If all you need is a tester, I'm always yours dude.
[03:01] <BenC> I had forgotten about that problem, but there are definitely changes in this kernel to the drm/accel that might help
[03:02] <jbailey> All good.  Deleting radeon.ko has just become automatic, and it occured to me that probably it shouldn't have become. =)
[03:02] <BenC> -rw-r--r-- 1 bcollins bcollins 23751558 May 15 09:01 linux-image-2.6.15-23-powerpc64-smp_2.6.15-23.35_powerpc.deb
[03:03] <BenC> it will soon be at p.u.c/~bcollins/linux-image-2.6.15-23-powerpc64-smp_2.6.15-23.35_powerpc.deb
[03:03] <jbailey> What's your uplink speed over the bird?
[03:03] <BenC> looks like it will take about 9 minutes
[03:03] <Mithrandir> BenC: does that mean you're trying to do a kernel ABI transition before flight 8?
[03:03] <BenC> like 256kbit/sec
[03:03] <BenC> Mithrandir: when's flight 8?
[03:03] <jbailey> Ah, so not horrible.
[03:03] <BenC> I planned on upload this today
[03:04] <Mithrandir> BenC: freeze thursday morning, release on friday's the plan.
[03:04] <Mithrandir> BenC: ahkay, that should work fine then.
[03:04] <BenC> ok, we should be good then
[03:05] <mjg59_> BenC: Have you stopped doing daily builds?
[03:06] <BenC> mjg59_: daily builds stopped themselves
[03:07] <BenC> I'm hardly ever in a buildable state when the auto run went through
[03:07] <mjg59_> BenC: Ah :)
[03:07] <BenC> so I just stopped it for now
[03:15] <BenC> jbailey: it's done
[03:16] <jbailey> BenC: Thanks, fetching.
[03:19] <jbailey> BenC: Trying it.
[03:24] <zul> heh...lupins
[03:24] <jbailey> BenC: Running it, I'll let you know how it goes.
[03:24] <jbailey> BenC: Although your changelog entry says taht you twiddle radeon on everything except ppc... ;)
[03:25] <BenC> jbailey: it sort of likes right now :0
[03:25] <BenC> plus, I actually updates to drm from 2.6.16
[03:25] <BenC> *updated
[03:25] <jbailey> Ah, hadn't noticed that part.
[03:26] <jbailey> We'll see how she goes.  It usually hangs within a day or so.
[03:35] <airlied> BenC: you might want to pull DRM from my tree, the radeon memmap changes are in it...
[03:36] <airlied> the only worry I hve with the 2.6.16 tree in 2.6.15 is compound page stuff..
[03:36] <airlied> jbailey: you running the latest xorg-driver-ati from dapper?
[03:36] <jbailey> Aucun paquet ne correspond  xorg-driver-ati.
[03:37] <jbailey> airlied: No such package, sorry.
[03:37] <zul> damn quebecers ;)
[03:37] <airlied> jbailey: hmm can't remember the package name xorg-x11-driver-ati maybe..
[03:37] <airlied> ...
[03:37] <airlied> xserver-xorg-driver-ati
[03:37] <jbailey> ii  xserver-xorg-driver-ati                      <IP_ADDRESS>-0ubuntu7               X.Org X server -- ATI display driver
[03:38] <jbailey> I should have current Dapper on here, yes.
[03:39] <airlied> jbailey: cool that will probably fix ati problems quicker than the kernel :-)
[03:41] <airlied> gotta run zzzz.
[03:54] <jbailey> airlied: I don't think I'v'e tried with the drm bits enabled since may 1st.
[03:54] <jbailey> So we'll see about the combo of them.
[03:55] <jbailey> airlied: ISTR benh saying that it was some sort of mmap misalignment between the two, though, so if there's fixes for that, it might be worth getting in.
[05:29] <allee> Should todays AMD64 netboot.tar.gz expected to work with modules in archive? d-i 'Download installer components
[05:29] <allee> tells me no kernel modules found
[05:53] <allee> BenC: reading channel title .. would be nice to get this fixed in dapper: [Bug 37452]  Re: fusion mpt sas driver does not find a RAID1 disk during installation(Sun Galaxy X4200 and X4100)
[05:54] <allee> BenC: latest comment states that it's fixed in <IP_ADDRESS>
[06:12] <BenC> saw that, I was planning on syncing to that
[06:12] <BenC> I have it marked important in my bug mbox
[06:31] <allee> BenC: great, thx.  I keep a box with RAID1 down for now so I can test
[10:59] <mdke> hi there.
[10:59] <mdke> I see there is an rt2570 driver in the kernel, and I've been trying to talk my brother into getting his wifi usb card to work over the phone
[11:00] <mdke> the module wasn't inserted and after inserting it, the device didn't show up in ifconfig -a. Any hints for debugging to put in a bug report?
[11:05] <mdke> ah, sounds like he has been lucky, looking at bugs #34845, #34902, #34845, #39227 (are these dups?)
[11:42] <jbailey> Wow klibc made it into the mm tree.
[11:58] <mdke> well, PM me if you have any ideas


[00:49] <Elliria> Hey there, does anybody here use Night Color?
[01:22] <Dragnslcr> Elliria- yes, do you have a question about it?
[01:23] <Elliria> Yes.  Mine does nothing that I can see and I have it set to the warmest setting. That's even if I set it on Always On (normally I have it set to come on automatically during the evening hours).
[01:24] <Elliria> I used to use Ubuntu MATE and that doesn't come with Night Color, so I used RedShift. I could see a strong difference between that being on and off.
[01:27] <Elliria> I thought I'd add that unchecking the "Activate Night Color" box and clicking the "Apply" button and then toggling that back on by putting the checkmark back into it and hitting that "Apply" button again doesn't do anything that I can see either.
[01:28] <Elliria> It occurred to me that the difference may be subtle or that the program is written in such a way that it affects colors not visible to the human eye.
 hi
 i don't think my fan is working
 can i test it by some command to make it speed up?
[08:11] <m_tadeu> hi...I'm trying to run a flatpak app but, the app doesn't run neither throws any error...the app is kde itinerary
 Can someone help with noson snap and flatpak? Amazon prime not working to play music
 I dk how to play music
 It says all the time  not working
[12:28] <BluesKaj> Hi all
[12:46] <user|21> hey i was wondering how to use fl studio 20 on wine
 UOGV
 U0GV
 I HAVE problem WITH INSTALLATION CODE 141
[18:49] <tomreyn> Kalyan: only do this is kubuntu will be the only operating system on this computer (i.e. you do not dial-boot with windows):   in bios, set "SATA mode" to "AHCI", disable "Intel RST RAID". if it still happens then, start the live mode of kubuntu and start the disk editing / partitioning utility there, and remove all partitions on the internal disk (where you want to install kubuntu to). then apply changes, reboot to the installer again and
[18:49] <tomreyn> install.
 I want dual boot and i have also data other partition i cannot delete them 😑 (re @IrcsomeBot: <tomreyn> Kalyan: only do this is kubuntu will be the only operating system on this computer (i.e. you do not dial-boot with windows):   in bios, set "SATA mode" to "AHCI", disable "Intel RST RAID". if it still happens then, start the live mode of kubuntu and start the disk editing / partitioning utility there, and remove all partitions on the inte
[18:54] <tomreyn> Kalyan: then i'm not sure i can help, sorry.
[18:54] <tomreyn> maybe someone else has the time to guide in this case.
[18:55] <user|21> hey my apex legends crashes my pc when i run it any idea on what might be the issue
 Ubuntu support dual boot then why kubuntu doesn’t support?
[18:57] <tomreyn> Kalyan: it's not a matter of kubuntu vs ubuntu, it's a matter of "disk is configured in a way that will only work for the existing operating system installation"
[18:57] <tomreyn> disk / computer firmware more precisely
[18:58] <tomreyn> more info https://askubuntu.com/questions/817344/ubi-partman-failed-with-exit-code-141-from-usb-install
[19:00] <tomreyn> ubuntu would detect if the cause of the 141 is having Intel RST enabled, though.
[19:03] <tomreyn> Kalyan: if you make these changes, make sure you have a complete backup before you start.
[19:15] <mmikowski> Kaylan: To add to tomreyn, be very careful as Windows likes to eat disks :P
[20:55] <wamyc> hello world
[20:56] <wamyc> bye bye  solitude direction


[00:13] <wililupy> Question: I just installed juju on 16.04 from repo (juju 2.0 beta15) and when I try to connect to the gui, it says connecting to Juju model and never goes past. Nothing in the logs looks suspicious other than in the machine-0.log there is an entry about reconfiguring lxd using dpkg and setup lxcbr0 which I do, but still nothing. Rebooted the controller and I had to tell Firefox to delete the SSL certificate for the server and
[00:13] <wililupy> have it re-issue it so that I could connect again, but same results.
[00:13] <bdx> wililupy: add juju/stable first ...
[00:13] <wililupy> bdx even on xenial?
[00:13] <bdx> wililupy: `sudo add-apt-repository ppa:juju/stable`
[00:14] <bdx> wililupy: yea ... not for much longer I think ..
[00:22] <wililupy> bdx: I'm updating it right now. Do I have to re-bootstrap?
[00:22] <bdx> wililupy: yes
[00:22] <bdx> wililupy: `rm -rf ~/.local/share/juju` too
[00:22] <wililupy> bdx: ack.
[00:47] <wililupy> bdx: That fixed it. Thank you so much. I eventually probably would have done that, but I was hoping not having to add a ppa.
[08:55] <admcleod_> magicaltrout: yep
[08:56] <magicaltrout> unlucky
[17:22] <bdx> lutostag, beisner, marcoceppi: where might one find the interfaces for the charm-jenkins charm?
[17:25] <beisner> marcoceppi, bdx, it looks like they're not in http://interfaces.juju.solutions  :-/
[17:27] <beisner> marcoceppi, bdx, i previously built using https://github.com/freeekanayaka/interface-jenkins-slave, which really should make it into jenkins upstream along side the jenkins-charm layer repo.
[17:29] <bdx> beisner: nice, thanks
[17:29] <bdx> looks like free has the other interfaces stashed there too :-)
[17:34] <jamespage> cory_fu, so the tweaks to bundletester config did not explode in the gate - https://review.openstack.org/#/c/395574/
[17:35] <cory_fu> jamespage: That's good.  We didn't get that rabbitmq branch into CWR, though, unfortunately.  Is that still something you need?
[17:36] <jamespage> cory_fu, it would be helpful to get this right first time - however if its alot of effort, we can probably get away with landing the changes and testing in stable, but that's not ideal
[17:37] <kwmonroe> cory_fu: jamespage:  the rabbit charm made it into cwr, just not in time for the overnight runs.  i'm pretty sure it'll be picked up when they kick off today.
[17:38] <jamespage> kwmonroe, based on my test charm under ~james-page right?
[17:38] <kwmonroe> correct jamespage
[17:38] <kwmonroe> cs:~james-page/rabbitmq-server-requirement
[17:38] <cory_fu> Yeah, sorry, I meant what kwmonroe said
[17:39] <cory_fu> jamespage: It will be run automatically this evening, but if need be, we could kick it off manually sooner, though I think it would still take a while before it actually runs
[17:39] <cory_fu> That CI infra is pretty over-committed, from what I can tell
[17:40] <jamespage> cory_fu, I just synced it up so I'll look am tomorrow
[17:40] <kwmonroe> tvansteenburgh1: it appears i'm hosting a timtimtim model in azure-east.  pretty sure that was for long-ago k8s test.  cool if i destroy that?
[17:40] <cory_fu> Ok
[17:40] <tvansteenburgh1> kwmonroe: yes
[17:40] <kwmonroe> thx
[17:41] <beisner> woot thanks jamespage cory_fu
[18:11] <deanman> Does anyone have a sample of yaml config file to be used during bootstrap. Cannot find any reference on the docs, only for charms.
[18:25] <lazyPower> deanman - its just a key: value map.   http://paste.ubuntu.com/23457321/
[18:26] <deanman> lazyPower: ok got it! Thanks
[18:47] <deanman> lazyPower: Can you put comments and/or environmental variables as values?
[18:47] <lazyPower> in yaml?
[18:48] <lazyPower> no, you would need to render it through a template wizard like envtemplate or something.
[18:48] <lazyPower> however, comments should be just fine, you can prefix a comment in yaml with #
[18:48] <deanman> lazyPower: ok thats seems reasonable!
[20:11] <deanman> Is it possible to `juju run` using a command that takes arguments? A simple `tail -f` seems to give an error with "flag provided but not defined: -f"
[20:13] <lazyPower> deanman - you'll need to quote the command
[20:13] <lazyPower> eg: juju run --application foobar "ls -al && whoami"
[20:16] <lutostag> any way to move bootstrap to a different ip/machine on 1.25.x? Our bootstrap node has run out of disk space. (Or a way to purge unused data from /var/lib/juju would work too)?
[20:17] <deanman> lazyPower: Shouldn't this work ? juju run -m controller --machine 0 "tail -f /var/log/juju/machine-0.log"
[20:17] <lazyPower> lutostag - thats rough, i think the option is to either go HA (probably not going to solve disk space issues) or to purge the cache/logs/whatever-is-using-the-diskspace
[20:17] <deanman> it just hangs
[20:17] <lazyPower> deanman - its async i think,s o you wont see the output until the command terminates
[20:17] <lazyPower> deanman - you should probably juju ssh into the unit if you need to tail logs.
[20:18] <deanman> ok lazyPower
[20:19] <lutostag> lazyPower: is /var/lib/juju/charm-get-cache safe to boot into the bit-bucket in the sky?
[20:20] <lazyPower> i think so, i'm fairly certain it will just replace whatever it needs that it doesn't find in the cache
[20:20] <lazyPower> *but*
[20:20] <lazyPower> with that being said, i haven't done it myself, so it might break things in unexpected ways
[20:20] <lazyPower> lutostag - i would highly recommend we file a bug about this so we can add an operational action to the controller to purge temporary/unneccesary data in the event this happens
[20:20] <lutostag> lazyPower: ack will find/create a bug
[20:23] <deanman> lazyPower: somehow even juju run -m controller --machine 0 "ls -al" hangs there.
[20:23] <lazyPower> mattrae ping
[20:36] <babbageclunk> deanman: does `juju ssh -m controller 0` work?
[20:38] <lazyPower> deanman - yeah that doesn't sound good. give babbageclunk's suggestion a go
[20:48] <deanman> babbageclunk: it does but i have since restarted the VM and now even run works
[20:48] <babbageclunk> deanman: sounds like sshd was having a bad time.
[20:49] <deanman> babbageclunk: it does take though like 5 seconds for a whoami
[20:49] <deanman> babbageclunk: is that normal?
[20:52] <babbageclunk> deanman: no that sounds very slow...
[20:54] <deanman> babbageclunk: http://paste.ubuntu.com/23457920/
[20:54] <deanman> seems like the previous command "tail -f" makes it unresponsive
[20:56] <babbageclunk> deanman: yeah, I see the same behaviour - can you file a bug for that?
[20:57] <deanman> `juju ssh` makes it recover somehow
[20:57] <deanman> sure babbageclunk !
[20:58] <babbageclunk> deanman: Thanks!
[20:59] <deanman> babbageclunk: can you `time juju run -m controller --machine - "whoami" for me and tell me what's your average?
[21:00] <deanman> i get 2-5 secs
[21:01] <babbageclunk> deanman: yeah, I get the same - 5 seconds sounded slow until I tried it.
[21:08] <deanman> babbageclunk: https://bugs.launchpad.net/juju/+bug/1640938
[21:08] <mup> Bug #1640938: `juju run` becomes unresponsive in consecutive runs when previous command passed is `tail -f` <juju:New> <https://launchpad.net/bugs/1640938>
[21:09] <babbageclunk> deanman: great thanks
[21:09] <deanman> Cheers!
[21:15] <lazyPower> babbageclunk - that tail -f doesn't exit, and i'm pretty sure that its just hanging the ssh session until timeout
[21:15] <lazyPower> deanman - humor me and try the tail with something like a -n 100  and omit the -f
[21:16] <babbageclunk> lazyPower: Oh, I think that's right, I'm just surprised that killing the run command doesn't kill the tail.
[21:25] <jproulx> Having trouble with image-metadata bootstrapping private cloud, have meta data json in ~/simplestreams as described in "getting" started but no matter how I feed it in keep getting
[21:25] <jproulx>  ERROR failed to bootstrap model: no image metadata found
[21:25] <jproulx> tried both --metadata-source=~/simplestreams and webserver using --config image-metadata-url=https://people.csail.mit.edu/jon/simplestreams amoung other things....Help?
[21:25] <jproulx> oh juju-2.0 on xenial
[21:30] <lazyPower> jproulx - i'm not as familiar with the clouds that require manual provisioning of simplestreams, however if you dont get an answer here in a timely fashion, the mailing list is an excellent resource for help with problems like that. https://lists.ubuntu.com/mailman/listinfo/juju
[21:31] <jproulx>  lazyPower: thanks for the pointer
[21:40] <mattrae> lazyPower: hey saw your ping :)
[21:40] <lazyPower> mattrae - found the answer already, thanks for pong'ing
[21:40] <mattrae> cool no problem :)