[00:53] <AskUbuntu> How does Juju "co-exist" with Chef, taking the automation process "one step further"? | http://askubuntu.com/q/267956
[03:05] <benji> hmm, the IRC logs for #juju seem a bit spotty
[10:17] <gtklocker> hey
[10:17] <gtklocker> I saw this: http://www.jorgecastro.org/2013/03/14/newsblur-volunteer-wanted/ I have no idea what juju is though
[10:19] <melmoth> gtklocker, it s a tool to deploy services in an easy way.
[10:19] <melmoth> think about it as apt-get for the cloud.
[10:20] <melmoth> works with amazon, openstack, and lxc containers.
[10:20] <melmoth> https://juju.ubuntu.com/docs/user-tutorial.html
[11:28]  * mariusko_ thinks Juju still is buggy! :/
[12:30] <_mup_> Bug #1155548 was filed: Consumes a lot of CPU resources <juju:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1155548 >
[12:54] <sidnei> mariusko_: no one said it wasnt. ;)
[13:17] <mariusko_> sidnei: nope, it says semi-clearly that it is not production ready yet
[13:18] <lifeless> sinzui: https://juju.ubuntu.com/docs/ "juju is still in a stage of fast development, and is not yet ready for prime time. The current software is being made available as an early technology preview, and while it can be experimented with, it should not be used in real deployments just yet."
[13:19] <mariusko_> for the charm instances that contain all state in the config, a workaround is to redeploy the service
[13:20] <sidnei> a workaround for what exactly?
[13:21] <mariusko_> all kind of strange behavior. Now I think I was having problem with phantom relations
[13:21] <mariusko_> after removing some of them
[13:21] <mariusko_> in the haproxy charm, but the bug might be in the core
[13:21] <mariusko_> resolved by redeploying
[13:22] <sidnei> more often than not the problems that i had were with the charms, ymmv
[13:22] <mariusko_> also possible
[13:23] <mariusko_> I just saw in the log of it iterating relations and found much more than expected
[14:27] <m_3> sidnei: hey, I'm marking the apache2 MP as resubmit to move those /tests to somewhere else
[14:28] <m_3> sidnei: I can put that as a but after the changes are in if that's easier for you
[14:28] <m_3> sidnei: but it seems simpler to move them before it's in trunk imo
[14:28] <m_3> ha!... s/but/bug/ above
[14:28] <sidnei> m_3: that's fine yes
[14:29] <m_3> cool... thanks man!
[14:29] <m_3> sorry the testing hasn't been communicated well
[14:29] <sidnei> np. i also want to solve the charmhelper/charmsupport issue, might end up delaying the resubmit for that.
[14:31] <m_3> sidnei: hey... side note
[14:32] <m_3> would it make sense to consolidate squid-{reverse,forward}proxy into a single charm?
[14:32] <m_3> that could take role based on the relations
[14:32] <m_3> similar to the hadoop charm (there's a great readme on that)
[14:32] <sidnei> m_3: i believe so, after the changes i did
[14:33] <m_3> sidnei: cool... well one step at a time, let's get these landed first
[14:34] <m_3> then we can see what people would expect to see for squid and what's easy to use
[14:37] <m_3> sidnei: awesome work man
[14:37] <sidnei> thanks!
[14:47] <dpb__> m_3: lp:~davidpbritton/charms/precise/landscape-client/add-landscape-relation is ready for review again
[15:04] <m_3> dpb__: cool, thanks!  there're a couple in-process atm
[15:12] <dpb__> m_3: backlog getting worked down? :)
[15:25] <m_3> dpb__: one bite at a time... was a big backlog
[15:56] <marcoceppi> hazmat: m_3 I've got a fix for failing charm-tools. It's kind of small but thought you should know https://code.launchpad.net/~marcoceppi/charm-tools/pep8-fix/+merge/153585
[16:05] <m_3> marcoceppi: ack, thanks
[16:05] <marcoceppi> Screw it, thundergun, going to just merge it
[16:05]  * marcoceppi Two seconds too late
[16:05] <m_3> marcoceppi: sounds good
[16:07] <marcoceppi> I should have run make check after "rebasing" from trunk
[16:15] <m_3> marcoceppi: I should've done it in the review ;)
[16:15] <m_3> doh
[16:15] <m_3> no biggie
[16:15] <marcoceppi> there's always next time ;)
[17:23] <mattyw> jcastro, sure
[17:27] <jcastro> mattyw: post your error
[17:27] <mattyw> jcastro, bzr: ERROR: Permission denied: "~mattyw/charms/precise/mongodb_auth_experiment/": : Cannot create branch at '/~mattyw/charms/precise/mongodb_auth_experiment'
[17:28] <qengho> mattyw: does  ~/charms/precise  exist?
[17:29] <qengho> What's the command that caused that?
[17:29] <mattyw> qengho, bzr push lp:~mattyw/charms/mongodb_auth_experiment
[17:30] <marcoceppi> mattyw try this:
[17:30] <marcoceppi> bzr push lp:~mattyw/charms/precise/mongodb_auth_experiment/trunk
[17:31] <mattyw> marcoceppi, mongodb_auth_experiment is not a valid source package name.
[17:32] <mattyw> that's the error I get :(
[17:33] <marcoceppi> mattyw interesting. You could always push to ~mattyw/+junk/mongodb_auth_experiment for the time being I don't know nearly enough about the name scheme to say why that doesn't work for you but works for me
[17:33] <mattyw> marcoceppi, do I need to be a member of any team?
[17:33] <mattyw> marcoceppi, the team that own the charms project?
[17:34] <qengho> mattyw: try dropping the "/precise" -- the system may interpret that as part of a distro/release/package/branchname sequence.
[17:34] <qengho> Oh, I see you started without it.  Never mind.
[17:35] <marcoceppi> mattyw I'm not sure what the rules are for creating branches in your own namespace. that might be the case. You may want to join https://launchpad.net/~charm-contributors to see if that fixes it
[17:36] <marcoceppi> that team, iirc, is your first stop if you're interested in helping with charms
[17:36] <mattyw> marcoceppi, nope that doesn't seem to have fixed it :(
[17:37] <mattyw> marcoceppi, member of charmers pherhaps? I've applied are you one of the mods?
[17:39] <marcoceppi> mattyw that's not it. I know other users who aren't in charmers who have branches with that address
[17:39] <mattyw> marcoceppi, ok, I'll keep trying and see what I can come up with
[17:40] <marcoceppi> I'm at at bit of a loss as to why you can't push. You could probably get away with ~mattyw/charms/precise/mongodb/auth_experiment
[17:40] <marcoceppi> not sure if it's actually part of the Mongodb charm or if it's something different
[17:41] <mattyw> marcoceppi, yep - that got it
[17:42] <marcoceppi> Cool, looks like it's based on the mongodb charm, so that would be the "best" address for it
[17:43] <mattyw> marcoceppi, jcastro qengho rather embarrassingly that is actually what the documentation says - thanks for helping guys!
[17:44] <jcastro> wait
[17:44] <jcastro> so what was the problem? I'm confused now
[17:45] <jcastro> m_3: you were pinging me about some broken branches earlier?
[17:51] <m_3> jcastro: nah, nm I got what I was looking for
[18:08] <mattyw> jcastro, I was trying to put it in bzr push lp:~mattyw/charms/precise/mongodb_auth_experiment rather than bzr push lp:~mattyw/charms/precise/mongodb/auth_experiment
[18:08] <jcastro> oh! the charm's name, of course, that makes sense now
[18:13] <mattyw> jcastro, it does say that in the docs I was reading - but seems like I tried to blaze my own trail :(
[18:13] <mattyw> jcastro, thanks for the help. I'll post it to the juju list
[18:57] <wedgwood> did anyone start on that newsblur charm?
[18:59] <jcastro> not yet!
[18:59] <jcastro> it would be awesome though
[19:01] <wedgwood> no kidding. I be the author would even be thankful. he's getting destroyed by demand
[19:01] <wedgwood> I'll give it the rest of my lunch break and see where that gets me.
[19:02] <wedgwood> ooh, off-by-30 error on that. gotta get back to work, but maybe this evening.
[19:02] <jcastro> nod
[19:02] <jcastro> yeah it would be nice to say
[19:03] <jcastro> "oh hey greader shut down, so I "juju add-unit newsblur -n 20"
[19:04] <marcoceppi> probably be around -n 100
[19:05] <salgado> juju occasionally tells me that it's using a cached version of the charm to deploy (e.g. "INFO Using cached charm version of postgresql"). is there a way to tell it not to use a cached version since I'm using local:postgresql and I've made changes to it?
[19:05] <salgado> if not, where can I find the cache so that I can manually delete it?
[19:08] <sarnold> salgado: juju deploy -u is probably what you're looking for
[19:08] <jcastro> http://askubuntu.com/questions/262833/how-do-i-force-the-juju-bootstrap-node-to-clear-the-charm-cache
[19:09] <jcastro> sarnold: I reworded the question to be more generic
[19:09] <sarnold> jcastro: aha :)
[19:10] <salgado> thanks sarnold, jcastro!
[19:22] <benm> Hello, where is the right place to ask for first time help testing a juju local mysql configuration?
[19:46] <marcoceppi> m_3 looks like pep8 needs to be added as a dependency for charm-tools. I'm not 100% sure how to do that though
[19:46] <m_3> marcoceppi: ack
[19:47] <marcoceppi> m_3 thanks!
[19:47] <m_3> marcoceppi: I'll fix it
[20:27] <sarnold> benm: here or askubuntu.com is fine :)
[20:32] <benm> \msg sarnold thanks, marcoceppi's blog is proving useful
[20:32] <sarnold> benm: oh, cool, I'll have to give it a look :D


[14:10] <Brainstorm> Updates for Bangladesh: +199 cases (now 1.6 million), +7 deaths (now 27953), +17135 tests (now 10.7 million) since 23 hours ago


[12:48] <AStorm> Hello.
[12:49] <AStorm> I heard that you're doing ubuntu init scripts too.
[12:49] <_ion> Welcome back. :-)
[12:49] <AStorm> I'm especially interested in the fsck - esp. not parallelising checks on things on the same physical drive.
[12:50] <AStorm> I have some ideas I've already implemented, but I'd like to hear yours.
[12:52] <AStorm> fsck itself isn't that good at checking multiple fses
[12:54] <AStorm> I wonder how does fsck check if the deviced are on the same physical device...
[12:59] <Md> major number?
[01:00] <_ion> That doesn't help much if you're e.g. comparing /dev/sda1 to /dev/volumegroup/foo which happens to be on software RAID-1, which happens to reside on /dev/sda2 and /dev/sdb2.
[01:02] <Keybuk> I didn't think fsck minded?
[01:02] <_ion> I assume fscking /dev/sda1 and /dev/sda2 simultaneously is *very* slow.
[01:03] <_ion> I don't see a reason for it not to work, but it's gotta be slow.
[01:09] <AStorm> Ok guys, did I miss something?
[01:09] <Keybuk> nope
[01:09] <AStorm> pfsck uses blkid_get_devname
[01:09] <AStorm> Which will fail with LVM or RAID.
[01:09] <AStorm> (fail to spot the use of the same device)
[01:10] <AStorm> My idea is to do some ls in /sys
[01:10] <AStorm> The dependency info is all exported in sysfs
[01:12] <Keybuk> what's the problem with checking the same device?
[01:12] <AStorm> seeking
[01:12] <AStorm> Means slowdown.
[01:13] <_ion> *Huge* slowdown, most likely.
[01:13] <AStorm> Not all that bad, because most fsck checks are small.
[01:13] <AStorm> I also wrote a tiny util to detect swap partitions.
[01:14] <AStorm> (4K on glibc)
[01:14] <AStorm> It could be useful when doing fsck totally automatically.
[01:16] <AStorm> (e.g. on HAL event when you hotplug your new shiny USB hard disc)
[01:17] <AStorm> Though some fsck options could probably fix it for us... if they are correctly implemented, that is
[01:17] <AStorm> not just checking the fstab
[01:19] <AStorm> Yes, it's broken. Will default to ext2.
[01:19] <AStorm> We could really use some FS detector.
[01:19] <Keybuk> AStorm: vol_id can do that
[01:20] <AStorm> How?
[01:20] <Keybuk> (detect swap partitions)
[01:20] <AStorm> Didn't work for me here...
[01:21] <AStorm> Ah, now it works. Stupid me.
[01:21] <AStorm> even the FS type (if known to the kernel)
[01:21] <AStorm> Ok, then it's no problem at all
[01:22] <AStorm> the devices will be discerned by sysfs data.
[01:23] <AStorm> ( reading /sys/block/*/* and /sys/block/*/*/slaves if present
[01:24] <AStorm> Probably there's some tool for that in sysfsutils too.
[01:24] <_ion> Has there been a lot of progress with the complex-event-config implementation?
[01:26] <AStorm> It works here :-)
[01:26] <Keybuk> _ion: I've written a parser
[01:26] <Keybuk> just need to rewrite that into the actual code and make it nice
[01:32] <AStorm> is "when x" isomorphic to "start on started x; stop on stopping x"?
[01:35] <Keybuk> there's no such thing as "when x" ?
[01:38] <AStorm> Bah.
[01:38] <AStorm> I meant "with x"
[01:39] <Keybuk> "with x" only exists in the complex-event-config
[01:40] <Keybuk> it's somewhat analogous to "starting x until stopped x", except that there's no serialisation of the two
[01:41] <AStorm> So it's more lax?
[01:41] <Keybuk> yes
[01:41] <AStorm> Nice still.
[01:42] <AStorm> I'm looking forward to complex-event-config full implementation.
[01:58] <Keybuk> me too
[10:37] <solemnwarning> Is upstart more stable then initng?
[02:18] <Keybuk> http://people.ubuntu.com/~scott/complex-event-config.patch
[02:18] <Keybuk> \o/
[02:33] <mbiebl> hehe, cool
[02:34] <mbiebl> Keybuk: Do you know, if the old sysv init sets the environment variables PREVLEVEL and RUNLEVEL on startup to N and S?
[02:34] <Keybuk> I have no idea
[02:34] <Keybuk> there's an open bug that the example job doesn't do that
[02:34] <Keybuk> I put the code in, and rc seemed to not work properly
[02:34] <Keybuk> so I'm not convinced
[02:36] <mbiebl> It's quite strange, the Debian udev scripts checks for the presence of these variables (and also splashy)
[02:36] <Keybuk> (this might just be a problem with /var/run/utmp, and /var/run not existing, of course)
[02:37] <mbiebl> But they are not set by /etc/init.d/rc
[02:37] <mbiebl> So, imho they must be set by sysv init.
[02:38] <mbiebl> I also find it strange, that bootmisc resets /var/run/utmp (to :) in S
[02:39] <Keybuk> yeah
[02:39] <Keybuk> sysvinit sets those itself
[02:39] <Keybuk> I think the bug is that we track the runlevel using /var/run/utmp as the authorative reference
[02:39] <mbiebl> Hard to N and S?
[02:40] <Keybuk> whereas sysvinit has an integer in memory that tracks it, and just uses utmp as an update
[02:40] <mbiebl> yeah, this is quite funny
[02:41] <mbiebl> if /var/run/utmp persists during reboot
[02:41] <mbiebl> You'd get 2 S from runlevel during S
[02:42] <Keybuk> pretty much the problem I had <g>
[02:42] <mbiebl> Do you know, if the behaviour of runlevel and PREVLEVEL/RUNLEVEL is specified somewhere?
[02:42] <Keybuk> I doubt it
[02:43] <Keybuk> I just used the sysvinit source as a reference for how they should behave
[02:43] <Keybuk> 0.3.5 is happily somewhat closer than 0.2.7 was
[02:43] <Keybuk> since "shutdown" now only generates runlevel change events
[02:45] <mbiebl> btw, I modified /etc/even.d/rcS for Debian to set PREVLEVEL/RUNLEVEL unconditionally to N/S
[02:46] <mbiebl> This is inconsistent to the output of runlevel at this  stage, but it seems to work fine.
[02:48] <Keybuk> that's a good idea :)
[03:03] <mbiebl> Yeah, it's then consistent to runlevel/previous defined in /etc/even.d/rc
[03:19] <AStorm> Keybuk, as to that init..
[03:19] <AStorm> Gentoo init depends on the fact that the RUNLEVEL is set to S or 1 on start.
[03:20] <AStorm> Had to fix that.
[03:23] <mbiebl> AStorm: What about PREVLEVEL?
[03:24] <mbiebl> Does the Gentoo init system make any assumptions about the value of this var?
[03:26] <AStorm> Not at all.
[03:27] <AStorm> (also, the runlevel names are special, like sysinit, single, nonetwork, default, reboot - not just numbers - but that's Gentoo-specific)
[03:27] <AStorm> the special sysinit runlevel is active only in S and there's explicit check for that
[03:27] <mbiebl> What's the output of runlevel during boot?
[03:28] <AStorm> Hmm?
[03:28] <mbiebl> Or when you have booted your system completely
[03:28] <AStorm> Completely.
[03:28] <AStorm> I'm running on upstart right now.
[03:28] <AStorm> (but totally using Gentoo scripts)
[03:28] <AStorm> (except the gettys - that also had to be hacked a bit)
[03:34] <AStorm> To be exact, the gettys were running too early
[03:35] <AStorm> making the init process look like crap
[03:35] <AStorm> Couldn't run them on stopped runlevel ...
[03:35] <AStorm> Because it didn't stop
[03:35] <AStorm> So I had to hack the last init script to emit that event.
[03:36] <AStorm> The always last script is /etc/init.d/local.start
[03:36] <AStorm> (due to after * clause in it)
[03:36] <AStorm> s/stopped runlevel/started runlevel/
[04:36] <Keybuk> runlevel is an event
[04:36] <Keybuk> not a job
[04:36] <Keybuk> events don't have a started or stopped :p
[04:37] <Keybuk> (unless you have an /etc/event.d/runlevel, of course)
[04:45] <_ion> Yay for complex-event-config.patch
[04:46] <Keybuk> it's still not "official" yet
[04:46] <Keybuk> it's only gdb-tested, and doesn't have test cases
[04:46] <Keybuk> and the code is messy at best
[04:46] <Keybuk> the implementation has some interesting side-effects too
[04:46] <Keybuk> e.g.
[04:47] <Keybuk> (foo and bar) until baz
[04:47] <Keybuk> foo happens, nothing
[04:47] <Keybuk> bar happens, it gets started
[04:47] <Keybuk> baz happens, it gets stopped
[04:47] <Keybuk> now, if foo or bar happen, it will be started again
[04:47] <Keybuk> since "foo and bar have happened" is satisfied
[04:47] <Keybuk> the until only "forgets" the AND combination
[04:48] <Keybuk> I actually quite like this behaviour, since the other intent can be expressed as:
[04:48] <Keybuk> foo until baz and bar until baz
[04:48] <Keybuk> (which requires foo and bar to both happen after baz, before it will be started again)
[04:50] <_ion> Well, that's exactly what i'd have expected to happen on (foo and bar) until baz
[04:50] <_ion> :-)
[04:51] <_ion> Agh, sorry. I misread your line as "if foo and bar happen, it will be started again"
[04:53] <_ion> Perhaps because there's "foo and bar" directly under the "foo or bar" ;-)
[04:56] <Keybuk> heh
[04:56] <Keybuk> after baz happens, it doesn't require foo and bar to both happen again
[04:56] <Keybuk> just one of them
[04:57] <AStorm> That's a bug.
[04:57] <Keybuk> is it though?
[04:57] <AStorm> It is. If you want "once" modifier, add it.
[04:57] <AStorm> from once foo and bar until baz
[04:57] <Keybuk> the "and" operator is TRUE if either expression has ever been TRUE
[04:58] <_ion> From the computer's point of view, that's the logical behavior. But from a human's point of view, it might be nicer if the code somehow reset the value of the (foo and bar) expression.
[04:58] <AStorm> hmm, or even
[04:58] <AStorm> from once foo and once bar until baz
[04:58] <_ion> ...when baz becomes TRUE
[04:58] <Keybuk> _ion: right, so the plan was that until would reset the tree on one side to FALSE when the other side went TRUE
[04:58] <Keybuk> and act as a flip-flop
[04:58] <AStorm> So, if both are satisfied _once_, they don't get reset
[04:58] <Keybuk> but that would have interesting interactions later with "with"
[04:58] <AStorm> But then... hmm.
[04:58] <AStorm> Weird.
[04:59] <AStorm> foo and once bar
[04:59] <AStorm> once foo and bar
[04:59] <AStorm> But both once degenerates to on.
[05:01] <AStorm> No, it doesn't :-)
[05:01] <AStorm> That'd be a nice extension.
[05:01] <AStorm> on once abc
[05:01] <AStorm> for a single-fire event
[05:02] <AStorm> (or even make on optional in this case)
[05:04] <AStorm> Like it?
[05:05] <Keybuk> not sure what the behaviour would be
[05:05] <AStorm> With once, or with those ands?
[05:05] <AStorm> The and should be like logic and
[05:05] <AStorm> And once should set a permanent flag
[05:06] <AStorm> It would be transitive too
[05:06] <AStorm> once (foo and bar) -> once foo and once bar
[05:10] <AStorm> similar with or...
[05:10] <Keybuk> I still don't get what "once" does?
[05:10] <AStorm> thought about adding xor?
[05:11] <AStorm> Keybuk, acts when the event is fired, but only once
[05:11] <Keybuk> so how is "once foo" different from "foo" /
[05:11] <Keybuk> once foo has been emitted, foo is always TRUE
[05:11] <AStorm> foo will fire multiple times
[05:11] <AStorm> Hmm.
[05:11] <Keybuk> sure, it can affect the tree multiple times
[05:11] <Keybuk> can you give me a use case for "once" ?
[05:12] <AStorm> Let me think...
[05:12] <AStorm> once startup-finished... mail me some info
[05:12] <AStorm> But then, you could create a one-time event
[05:12] <Keybuk> why not just make it a one-time event in the first place ? :p
[05:12] <AStorm> It's much better when you change and
[05:13] <AStorm> from bar and once foo until baz
[05:13] <Keybuk> change and?
[05:13] <AStorm> This means that if foo is fired once
[05:13] <AStorm> and baz is fired, we get launched
[05:14] <AStorm> unlike from bar and foo until baz
[05:14] <Keybuk> I still don't understand why this is useful, sorry
[05:14] <AStorm> which would mean that if both are fired...
[05:14] <AStorm> This means "foo got executed and finished, then on baz, do something"
[05:15] <Keybuk> I think you're confusing events and jobs?
[05:15] <AStorm> Probably.
[05:15] <AStorm> Due to JobEvents :P
[05:16] <Keybuk> job events went away
[05:16] <AStorm> Good.
[05:17] <AStorm> Well, then and works correctly it seems.
[05:17] <AStorm> (except that behaviour is not necessarily intuitive and has to be documented)
[05:18] <Keybuk> documentation is third on my TODO list :p
[05:18] <AStorm> :>
[05:18] <AStorm> Could lend you a hand there. Which format do you prefer?
[05:19] <Keybuk> docbook, I guess
[05:19] <AStorm> Could be asciidoc generated docbook?
[05:19] <Keybuk> what's that?
[05:19] <AStorm> asciidoc is a plaintext system
[05:20] <AStorm> http://www.methods.co.nz/asciidoc/
[05:21] <AlexExtreme> hmm
[05:21] <AlexExtreme> I could also help with docs
[05:23] <_ion> asciidoc looks quite nice.
[05:27] <AlexExtreme> hmm
[05:27] <AlexExtreme> the complex-event-config patch looks good
[05:28] <_ion> Ooo, nice. http://www.methods.co.nz/asciidoc/music-filter.html
[05:28] <_ion> Ooo, nice2. http://www.methods.co.nz/asciidoc/source-highlight-filter.html
[05:48] <AlexExtreme> Keybuk, how are the new jobs going? or haven't you started work on them?
[05:49] <Keybuk> slowly, but surely
[05:49] <AlexExtreme> cool
[05:50] <Keybuk> should be done today
[05:50] <_ion> Yay
[05:51] <AStorm> I have a question: How would one do normal logging to both console and system log?
[05:52] <AStorm> Use logger + echo?
[05:53] <Keybuk> or something like bootlogd or logd, etc.
[05:54] <AStorm> Yes, I was thinking about that logd
[05:54] <AStorm> How do you use that?
[05:55] <Keybuk> right now it's disabled
[05:55] <Keybuk> has a few bugs
[06:02] <AStorm> Ok, not a problem. For a while, I'll stick with plain echo.
[06:03] <AStorm> The hardest part is writing the network script
[06:03] <AlexExtreme> we talked about the possibility of integration with syslog-ng a while back
[06:03] <AStorm> the gentoo one is so universal, that it's quite slow :>
[06:03] <AStorm> (also, the network devices aren't parallelised)
[06:04] <_ion> astorm: It might be wise to start network interfaces based on events emitted by udev, too.
[06:04] <AStorm> Yep.
[06:04] <AStorm> Gentoo does that, but it has to wait for udev to settle :P
[06:04] <AlexExtreme> frugalware's networking script is quite simple, but it's not flexible in terms of bootup. everything is done by an external C program which uses profiles
[06:04] <AStorm> We don't have to.
[06:04] <AStorm> AlexExtreme, blah
[06:05] <AlexExtreme> why blah? :p
[06:05] <AStorm> I'd rather use a bunch of shell scripts :>
[06:05] <AStorm> and iproute2
[06:05] <AlexExtreme> :)
[06:05] <AStorm> and probably wireless-tools
[06:05] <Md> AStorm: only because currently daemons are started unconditionally when the interface is up. the correct way would be to start daemons when the interface is up, syslogd is running, /var is mounted, etc
[06:06] <AStorm> Md, yes, unfortunately.
[06:06] <AStorm> Gentoo init can be fixed, yes.
[06:06] <AStorm> But is it worth it? It is somewhat cruddy (e.g. /sbin/rc)
[06:07] <AStorm> _ion, I'm doing it right now, thank you
[06:07] <AlexExtreme> well
[06:07] <AStorm> :>
[06:07] <AlexExtreme> that would be hard
[06:07] <AlexExtreme> because
[06:07] <_ion> The result is probably a lot better than converting the gentoo script to upstart jobs automatically.
[06:08] <_ion> scripts
[06:08] <AlexExtreme> hmm wait
[06:08] <Keybuk> that's harder for Gentoo, because of their intricately interlinked deps
[06:08] <AStorm> No, it's the same as running the gentoo init.
[06:08] <AlexExtreme> no, forget i said anything
[06:08] <AlexExtreme> :)
[06:08] <Keybuk> they can't just remove one script
[06:08] <AStorm> Exactly. That's why they have to be wrapped.
[06:08] <Keybuk> because then all of its dependers wouldn't work
[06:08] <Keybuk> where as we can
[06:11] <AStorm> I simply wrap them in a wrapper script
[06:11] <AStorm> for upstart.
[06:11] <AStorm> And add a "runlevel" with a list of the deps.
[06:12] <AStorm> Still haven't got to modifying depscan.sh or rc-update to modify the file
[06:26] <AlexExtreme> hmm
[06:26] <AlexExtreme> that usplash in feisty atm is nice
[06:26] <AStorm> Hmm, what about checking a filesystem just before mounting? :>
[06:26] <AStorm> (except if a flag is given in the fstab, maybe...)
[06:27] <AStorm> upstart could be turned into an automounter too...
[06:27] <AStorm> (maybe not for network filesystems, for these there's autofs)
[06:29] <AStorm> Except that it wouldn't know who inserted the disc. So here, Unix user rights would have to be used.
[06:32] <AlexExtreme> hmm
[06:32] <AlexExtreme> does anyone know if kdump is implemented on feisty yet?
[07:35] <AStorm> Hmm, does initctl emit block until the event has been totally handled?
[07:36] <AStorm> and what about initctl start?
[08:06] <AStorm> ping, anyone?
[08:20] <int0x0c> AStorm, You have upstart running on Gentoo, right?
[08:26] <AStorm> int0x0c, in emulation currently
[08:26] <AStorm> writing the basic init and a proper init script emulation layer will take time
[08:27] <AStorm> I'm doing that currently
[08:27] <int0x0c> ahhh
[08:27] <AStorm> s/currently/right now/
[08:27] <int0x0c> heh
[08:27] <int0x0c> Have you seen Keybuk around recently?
[08:27] <int0x0c> I'm looking to port the init system fully to upstart
[08:27] <AStorm> [19:23:08]  * Keybuk has quit ("")
[08:28] <int0x0c> He's supposed to release a full upstart jobset soon
[08:28] <AStorm> I'm doing that too :-)
[08:28] <int0x0c> bah
[08:28] <AStorm> I'd appreciate the init scripts, but then, I'm porting it right now too.
[08:28] <int0x0c> ahhh, alright
[08:29] <int0x0c> I'm afraid I don't understand the init system well enough to port the base system scripts without some research
[08:30] <int0x0c> it would be great to get a full upstart init sequenceon gentoo
[08:31] <AStorm> It's actually quite simple.
[08:31] <AStorm> mount proc, dev, remount root ro
[08:31] <AStorm> start udev
[08:31] <AStorm> fsck root
[08:31] <AStorm> fsck other fses
[08:31] <AStorm> mount them
[08:31] <AStorm> that's the end of basic setup.
[08:31] <AStorm> The last step is starting gettys
[08:32] <AStorm> That's the basic skeleton. You probably want to add there some daemons, network setup, sound setup, such things.
[08:33] <AStorm> (forgot about remounting root rw :> )
[08:33] <AStorm> Also mount /dev/pts and /dev/usb optionally
[08:33] <AStorm> also, mounting sys
[08:35] <int0x0c> hmm
[08:35] <int0x0c> Have you implemented those as pure upstart jobs?
[08:35] <AStorm> Doing it right now.
[08:36] <AStorm> Actually, mostly done.
[08:36] <AStorm> Still working on improving the fsck
[08:36] <AStorm> Then, the init level/profile has to be launched. E.g. a script starting everything in some directory
[08:37] <AStorm> and stopping
[08:37] <AStorm> a runlevel simulation, that is.
[08:38] <AStorm> (or eINIT's mode, rather)
[08:40] <AStorm> At least until profiles are implemented.
[08:58] <AStorm> Well, the actual depscan.sh just launches a bunch of computation using awk
[08:58] <AStorm> I'd rewrite it in Python myself.
[08:58] <AStorm> (it's on Gentoo anyway)
[08:59] <AStorm> The emulation requires complex-event patch
[09:00] <AStorm> (otherwise it's impossible to link deps together)
[09:01] <AStorm> It's in awk, because the need system is too hard to implement in bash :>
[09:33] <int0x0c> Do you suppose you could post your base startup job somewhere?
[09:51] <_ion> Haha, i just now saw the picture Keybuk has at his launchpad page. :-)
[11:34] <AStorm> Hey guys...
[11:35] <AStorm> I wonder if this script is correct (with complex-events patch)
[11:36] <AStorm> http://wklej.org/id/8aba67fafb
[11:36] <AStorm> (check-fs does what you expect :-) )
[11:37] <AStorm> Maybe change the from line to
[11:37] <AStorm> start on started udev
[11:37] <AStorm> stop on stopped check-fs FS=/
[11:38] <AStorm> Hmm, or do I need something to listen on initctl events?
[11:39] <AStorm> Ah, no, I have to add sleep inf probably
[11:40] <AStorm> so that it's still running? (even with the fix for jobs w/o execs)
[11:49] <AStorm> I wonder...
[11:50] <AStorm> my test-event1 doesn't register as a job
[11:51] <AStorm> Ah, my bad. Braino
[11:53] <AStorm> Ok, got it :-)
[11:54] <AStorm> Is there a way to create a one-fire command that will block until the other event happens, or do I have to use that sleep inf hack?
[11:58] <AStorm> (which leaves nasty KILL messages around)
[11:58] <AStorm> mbiebl, oh, maybe you know.
[11:59] <mbiebl> AStorm: hi, what's up
[11:59] <AStorm> I wish to run a single-fire command, which should block until an event is fired
[11:59] <AStorm> sleep inf and using the dependencies leaves KILL messages.
[12:00] <AStorm> (looks yucky)
[12:01] <mbiebl> AStorm: could you explain a bit more detailed what you want to achieve
[12:02] <AStorm> I want to launch another event (which is an instance, so can't just wait on something)
[12:02] <AStorm> and then, block, until it finished
[12:02] <mbiebl> "launch an event" ?
[12:03] <AStorm> Actually, start a job
[12:03] <AStorm> But emitting an event would do the same
[12:03] <AStorm> Start command x, which returns
[12:03] <AStorm> and still wait until that one event
[12:06] <mbiebl> AStorm: Sorry, I think you lost me. I'd have to see the bigger picture to understand what you want to do.
[12:06] <AStorm> Launch 3 fsck in parallel
[12:06] <AStorm> and wait until they complete
[12:06] <AStorm> each fsck is a job.
[12:06] <AStorm> (because I would like to hook that up to udev events later)
[12:08] <mbiebl> Why do you have to wait, until all three of them have been completed?
[12:08] <_ion> "initctl emit foo" blocks automatically
[12:08] <AStorm> _ion, yep, but what will receive it? :>
[12:08] <AStorm> mbiebl, because then the mounting may happen
[12:08] <AStorm> (automounting that is)
[12:08] <_ion> /etc/event.d/test:
[12:08] <_ion> start on foo
[12:08] <_ion> exec sleep 5
[12:09] <AStorm> And I also want to use it in system startup sequence
[12:09] <_ion> % sudo initctl emit foo
[12:09] <AStorm> _ion, hmm, I have to pass parameters too
[12:09] <mbiebl> Well, I'd say, mount each partition separately when fsck has completed.
[12:10] <_ion> You probably should make the fsck job emit "filesystem-checked" and the mount job "start on filesystem-checked" or something like that.
[12:10] <mbiebl> I see no reason to way for / not being mounted because /usr is still checked.
[12:10] <mbiebl> s/way/wait/
[12:11] <AStorm> mbiebl, that's not the problem
[12:11] <AStorm> the problem is /usr/share mounted while /usr isn't
[12:11] <AStorm> :-)
[12:12] <mbiebl> Well, then the /usr/share mount job should "start on fsck-checked /usr"
[12:12] <AStorm> yeah right :>
[12:12] <AStorm> And I do know that from udev events :P
[12:13] <_ion> I'm not sure there should be separate mount jobs for separate partitions.
[12:13] <AStorm> _ion, there can, not a problem at all
[12:13] <AStorm> If I serialise mounting after the fsck
[12:13] <AStorm> _all_ of them
[12:14] <mbiebl> This is actually quite tricky.
[12:14] <mbiebl> You can't know in advance the partitioning scheme of a user.
[12:14] <AStorm> I can emit some events, right.
[12:14] <AStorm> yes, but can make educated guesses :P
[12:14] <mbiebl> So providing upstart mount jobs for each separate partition won't be possible.
[12:15] <mbiebl> You could, as _ion suggest, do the mounting in on single job.
[12:15] <_ion> Better make the mount intelligent: if MOUNTPOINT is /usr/share and there's a /usr entry in /etc/fstab, block until /usr is mounted.
[12:15] <_ion> Or something like that.
[12:15] <AStorm> Exactly.
[12:15] <AStorm> But not on the fstab check
[12:15] <AStorm> on mtab
[12:15] <AStorm> or rather, /proc/mounts
[12:16] <_ion> No, that doesn't contain /usr until /usr is mounted, right?
[12:16] <AStorm> fstab will be checked anyway, the mounts will be serialised separately by an external program
[12:16] <AStorm> I've temporarily solved the problem already, thank you.
[12:17] <AStorm> (I meant they will wait on each other, the scripts launched with an argument)
[12:19] <AStorm> Hmm, I could wait on the pids
[12:19] <_ion> % deps() { while read fstab_fs fstab_mountpoint rest; do case "$MOUNTPOINT" in "$fstab_mountpoint"*) echo "$fstab_mountpoint"; esac; done </etc/fstab }; MOUNTPOINT=/usr/share deps
[12:19] <_ion> If there's /usr in /etc/fstab, that should print it.
[12:20] <AStorm> More or less.
[12:20] <_ion> That's not a real implementation, it would print "/usr/loc" for /usr/local, but it demonstrates the idea.
[12:20] <AStorm> I know what I have to do...
[12:21] <AStorm> but the parsing will be done by an external program anyway.
[12:21] <AStorm> I just wonder, how to emit x events and wait on them all
[12:22] <AStorm> Well, wrong actually
[12:22] <_ion> for e in foo bar baz; do initctl emit "$e" & done; wait
[12:22] <mbiebl> AStorm: The basic question is, when can certain jobs start to run
[12:22] <AStorm> I can use complex-events and stop on (fsck / and fsck /usr and fsck /var and ... )
[12:22] <AStorm> But that will leave evil messages
[12:23] <AStorm> I will launch them using events, thank you.
[12:23] <AStorm> But what will wait w/o args do?
[12:23] <AStorm> mbiebl, that will be assured by another program and the deps :-)
[12:23] <_ion> wait for all children. To wait for only those initctls:
[12:24] <AStorm> Great then. Should've read the manpage better.
[12:24] <_ion> pids=; for e in foo bar baz; do initctl emit "$e" & pids="$pids $!"; done; wait $pids
[12:24] <_ion> (i didn't test that, though)
[12:24] <AStorm> Not a problem with "all children"
[12:25] <AStorm> The shell is running only these commands.
[12:27] <AStorm> Ok, so now the fsck problem is solved (thanks to emitting events)
[12:28] <AStorm> per-disk fsck is done too properly


[06:54] <lotuspsychje> when update manager has finished updating, the tip: you can use livepatch... is in english rather then native language (dutch in my case)
[06:54] <lotuspsychje> think thats an old bug, ill check it on jammy later
[13:59] <lotuspsychje> im dragging a folder to ftp via nautilus, but i dont see a progress bar on nautilus dock icon anymore, did they remove that on noble?
[16:04] <lotuspsychje> ok i found my older bug #1813262 wich happens just the same on noble here, should i re-use this bug and tag it noble, or file a new one?
[16:04] -ubottu:#ubuntu-next- Bug 1813262 in language-pack-gnome-nl (Ubuntu) "livepatch strings not fully translated yet in bionic" [Medium, Fix Released] https://launchpad.net/bugs/1813262
[17:12] <lotuspsychje> i filed bug #2044159 for those who want to test/reproduce
[17:12] -ubottu:#ubuntu-next- Bug 2044159 in apport (Ubuntu) "Ubuntu-bug triggers an error cloud-init run data not found on system. Unable to add cloud-specific data" [Undecided, New] https://launchpad.net/bugs/2044159
[17:56] <lotuspsychje> i filed bug #2044170 against nautilus
[17:56] -ubottu:#ubuntu-next- Bug 2044170 in nautilus (Ubuntu) "File copy progress bar on nautilus dock icon does not show" [Undecided, New] https://launchpad.net/bugs/2044170


[08:55] <tsdgeos> Mirv: https://codereview.qt-project.org/#/c/140510/ has landed, can we get it asap?
[08:55] <tsdgeos> mardy: cool ↑ :)
[09:03] <Mirv> tsdgeos: yes, mardy already noted it
[09:03] <Mirv> tsdgeos: it's in silo 046 now
[09:04] <tsdgeos> nice
[09:16] <Guest42341> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1515921
[09:18] <Guest42341> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1515923
[11:44] <Mirv> tsdgeos: oh right, the DBus patches are another thing why it'd be nice to have Qt 5.6 in 16.04 LTS.
[11:44] <tsdgeos> Mirv: totally
[11:44] <Guest42341> 100%
[11:45] <tsdgeos> Mirv: not sure if it was you or someone else asking but the 5.6 LTS is supposed to be for ~3 years
[11:45] <Mirv> tsdgeos: someone else
[11:47] <Mirv> tsdgeos: what do you think about switching to generic bearer plugin for 5.5? that would solve the most pressing network problems on 5.5. although it doesn't mean that the networking wouldn't need fixes later on, but if not doing something we're staying with 5.4...
[11:48] <tsdgeos> Mirv: i have honestly not been following the discussion
[11:48] <tsdgeos> switching from nm to generic?
[11:48] <Mirv> tsdgeos: I think the reasons behind us switching to use NM bearer backend over a year ago were no completely correct.. the 3G connectivity problems were probably not because of that, but the remaining functionality with NM plugin is AFAIK more correct behavior when switching 3g or wifi on/off
[11:49] <Mirv> tsdgeos: well bug #1508945 explains it, it was the "weather app" bug I reported but found out that it's just the apparmor <-> network manager problem getting worse in 5.5, and again the apparmor rules are not wanted to be relaxed.
[11:51] <Mirv> since apparmor rule changes aren't allowed, one possibility is to trust other components to route network traffic correctly and use a generic bearer in Qt instead, since we don't want Qt controlling network-manager anyway
[11:53] <tsdgeos> Mirv: for phone apps it might be sufficient yes
[11:53] <tsdgeos> not sure making it the default "ubuntu desktop" wide makes sense though
[11:56] <Mirv> tsdgeos: well it is what was default before. but with the newest patches it's also selectable.
[11:56] <Mirv> tsdgeos: there's the slight problem with the current hard coding to NM that on desktop user might choose to not use NM...
[11:57] <tsdgeos> sure
[12:01] <popey> On Ubuntu phone in windowed mode, phone sat in landscape, if you open an app which forces portrait mode, or if you have such an app already open and click it with the mouse, the phone flips to portrait...
[12:01] <popey> Shouldn't unity 8 ignore portrait .desktop file settings when in windowed mode?
[12:03] <davmor2> popey: you'd hope so that would be no fun on a monitor
[12:03] <popey> yeah, dunno what it does with an external display, we didn't have one handy
[12:05] <tsdgeos> popey: i agree it's weird, i'd say open a bug
[12:09] <popey> k
[19:02] <ljp> Mirv: I wrote simple bearer plugin based on connectivity-api https://codereview.qt-project.org/#/c/140752/
[19:02] <ljp> since the nm bearer plugin won't work due to app armor
[21:08] <mterry> mzanetti, is there a known problem getting app icons in store on rc-proposed?
[21:09] <mterry> If I go to a category I don't have cached icons for, they don't load
[21:13] <mzanetti> mterry, hmm, no, not known
[21:17] <mterry> Is it just me?