[00:09] <mwhudson> is there any way to listen to test match special in nz?
[01:34] <ibeardslee> South Islanders ..
[01:35] <ajmitch> ibeardslee: ?
[01:35] <ibeardslee> Truenet.co.nz are looking for more volunteers to help test and measure broadband in NZ
[01:36] <thumper> ?
[01:36] <ibeardslee> http://www.truenet.co.nz/get-involved-become-volunteer-tester
[18:54] <ibeardslee> morning
[18:56] <Atamira> mornin
[18:58] <ibeardslee> Atamira: where are you based?
[18:59] <Atamira> auckland
[18:59] <ibeardslee> ok .. for some reason I thought Hamilton
[19:07] <Atamira> you might be thinking of the other Liz
[19:07] <Atamira> who lives in cambridge
[19:07] <Atamira> who i havent met
[19:07] <ibeardslee> ahhh
[19:09] <ibeardslee> apologies
[19:12] <Atamira> no biggie. you're not the first one to get it wrong
[19:23] <ajmitch> morning
[19:33] <Atamira> sorry. not get it wrong but to assume we're the same person
[19:56] <mwhudson> morning


[02:23] <_bjorne> is someone live here?
[02:25] <_bjorne> i have some problem with maas clients.. only one client run dist-upgrade and install lxc and mongodb, the other one is not do that... can somone give some information? i have try in 12.04 and 13.10 and get same problem...
[08:46] <jtv> bigjools, rvba: having a look at how to remove the POWER_TYPE enum.  It does seem desirable, but we do encode a lot of knowledge about power parameters for each type.
[08:47] <jtv> Maybe we could step outside that whole system for unknown power types.
[08:50] <rvba> Let me have a look at the enum to refresh my memory.
[08:52] <rvba> jtv: I'm not entirely sure why you think we can get rid of that particular enum.
[08:53] <rvba> The DISTRO_SERIES enum we can probably get rid of.
[08:53] <jtv> Julian mentioned it as a potential work item.
[08:53] <rvba> Hum, then it's not very clear to me how we can do that.
[08:55] <jtv> Not to me either.  That's why I'm looking.  :)
[08:56] <jtv> rvba, could I beg you for a review of https://code.launchpad.net/~jtv/maas-test/check-for-dhcp-server/+merge/198001 ?
[08:56] <rvba> Sure, I'll have a look right now.
[08:56] <jtv> Thanks.
[09:02] <rvba> jtv: btw, I've got a postgresql-related question for you.
[09:03] <rvba> jtv: it's about the backup/restore script allenap and I have worked on recently.
[09:03] <rvba> jtv: the backup/restore procedure for the pg db errors and I'd like your opinion about that.
[09:04] <rvba> jtv: can you ssh<EMAIL_ADDRESS>and join the byobu session there?
[09:05] <jtv> rvba: coming!
[09:05] <jtv> rvba: I'm in.
[09:06] <rvba> jtv: so I'm running backup and then restore and the pg restoration fails.
[09:07] <jtv> I wonder why plpgsql is even mentioned.
[09:29] <melmoth> hi there.  I have been asked if there is a way to forward maas logs in a remote syslog server. Anyone knows if this can be done ?
[09:38] <jtv> Don't think you can.  :/
[09:38] <jtv> Unless you can make your local syslog do it.
[09:39] <melmoth> if i understand correclty, the people who asked me already have a centralised syslog server, so the maas boxes send any stuff there.
[09:40] <melmoth> that is, any stuff that should have ended in /var/log/syslog , but apparently not stuff that end up in /var/log/maas/*
[09:40] <jtv> Ah, right — we don't send it to syslog yet.
[09:41] <jtv> ...rsync?
[09:42] <melmoth> i m not sure they would like that.
[09:42] <melmoth> anyway, my main question was if there was a known way. wich is not the case, knowing that was helpfull anyway, thanks :)
[09:42] <jtv> Sorry!
[09:43] <rvba> jtv: I don't see why we can't run the restore script as the postgres user.
[09:44] <jtv> Because there's no peer authentication for that login in the hba config.
[09:45] <jtv> We'd need some configuration to say "it's OK for <system user> to log into <database> as <DB user>."
[09:45] <jtv> (When using peer authentication, that is, but that's probably what we want here.)
[09:46] <rvba> I see.  The backup/restore script must be run as root (there is even a check in the code for this) so we can switch to the postgres user.
[09:46] <jtv> But I don't think it'd be desirable to twiddle that config here.
[09:46] <jtv> I'm not sure root is allowed to do that by default.
[09:46] <rvba> But the changes you've made seem to work already… ?
[09:46] <rvba> Well, you've reverted them now.
[09:47] <jtv> That was the switch from "directory" format.
[09:47] <jtv> I still don't know why that made the difference.  :(
[09:47] <jtv> Yes, easy to reproduce.
[09:47] <jtv> Also of course, the default format is pretty slow.
[09:48] <jtv> No postgres "ident" entry for root→postgres by default.
[09:48] <jtv> The way to get around that is to sudo to the postgres system user.
[10:00] <jtv> rvba: it's coming to the point where I think the database should simply be dropped before restoring.
[10:00] <jtv> The dump can re-create the database, and then the maas user will be its owner.
[10:00] <jtv> At that point the permissions errors will go away.
[10:30] <jtv> rvba: changes to use the default format are now in place (but cleaner than before).  It'll be slow and bloated, but also simple.
[10:30] <rvba> jtv: just checking, the dhcp stuff doesn't introduce any new dependency right?
[10:30] <jtv> Not any more.
[10:30] <rvba> jtv: cool, thanks for your help.  I'll incorporate your changes into the branch.
[10:30] <rvba> All right.
[10:30] <jtv> It was going to import the code from maas, but that's what I took out today.
[10:31] <Martin_____> If I only need to be able to deploy Ubnutu to bare metal. Is MAAS a good solution for me or should I take a look at Razor/Cobbler or Foreman? I will hand over the clients to puppet as soon as they are installed.
[10:32] <Martin_____> I like that MAAS can handle power on and off.
[10:32] <jtv> (If you have the hardware for it, of course :)
[10:32] <jtv> Deploying Ubuntu to bare metal is exactly what MAAS does, so that sounds like a good match.
[10:33] <jtv> You _can_ integrate with Juju to deploy actual software, but you don't have to.
[10:34] <Martin_____> jtv: I don't at the moment want to use juju as we have our stuff in puppet.
[10:34] <jtv> rvba: you'll want to try that restore in a situation where the database does not exist yet as well, or at least one where it's empty.
[10:34] <rvba> jtv: well, the db is kind of empty in the testing machine.
[10:34] <rvba> s/in/on/
[10:34] <jtv> Martin_____: that's fine.  You ask maas to allocate you a machine (optionally with constraints), and you get an installed and running machine that you can ssh into with your registered key.
[10:35] <rvba> jtv: I'm getting rid of the VM now.
[10:35] <jtv> rvba: "kind of" — not "completely."  :)  The dump will also re-create tables, set permissions, and so on.
[10:35]  * jtv gets out of the VM
[10:37] <Martin_____> jvt: Whats with the linux bridge interfaces that are installed on the nodes. Is it for the LXC containers?
[10:53] <rvba> jtv: once your branch is merged, I'll give it a go in the lab.  Just for safety.
[11:09] <jtv> Good man.
[11:10] <jtv> And thanks for the review.
[11:13] <gmb> rvba: Before your EoD will you let Jeff know that maas-test is done and prod him re: testing? It'd be lovely if we could announce this internally at least next week.
[11:13] <rvba> gmb: already done :)
[11:13] <gmb> Sweet!
[11:23] <rvba> jtv: I found a problem with the dhcp stuff
[11:24] <jtv> That was quick.
[11:24] <rvba> jtv: http://paste.ubuntu.com/6529295/
[11:25] <rvba> the authbind problem.
[11:25] <rvba> Maybe we should simply force the user to run maas-test with sudo…
[11:25] <rvba> Since it's used everywhere.
[11:26] <jtv> That's how I've been running it...  Completely forgot that it wasn't standard.
[11:26] <jtv> But yes, we do sudo all over the place anyway...
[11:26] <jtv> When not ourselves, then inside uvtool.
[11:26] <rvba> Yes.
[11:27] <jtv> I can have a must-be-run-as-root patch up in no time.
[11:27] <jtv> Since main() is still fresh in my memory, and I've added a first test for it.
[11:27] <rvba> http://paste.ubuntu.com/6529316/
[11:28] <jtv> Hey, don't I recognize that from the maas-backup code?  :)
[11:28] <rvba> heh
[11:28] <jtv> Why the args.test?
[11:29] <rvba> Oh, that's just a shortcut in maas-backup to simulate a run.
[11:31] <jtv> rvba: power loss.  Amazing how little drama that is nowadays.  Anyway... ISTM patching geteuid() in tests makes more sense than a test argument, no?
[11:31] <rvba> jtv: definitely.  But in maas-{backup,restore} we have no tests (yet), hence the shortcut.
[11:36] <jtv> Ah OK
[11:36] <jtv> So I _did_ know that exact code.  :)'
[11:36] <rvba> :)
[11:38] <jtv> And before 2014 starts, I think I'll just update the copyright on main.py from 2012 to 2013.  :)
[11:38] <jtv> Sorry, test_main.py.
[14:10] <_bjorne> Do someone know how im restart cloud-init script so i can debug it? i have some problem with some nodes, only one node run dist-upgrade and installs lxxc and mongodb for me.
[14:12] <_bjorne> the node dont pick up user-data and cloud-config for me.
[14:39] <gmb> rvba, allenap: I have a branch for reporting, finally! It's not completely tested, but the bit that isn't tested is one small chunk, and I'm going to write tests for that this afternoon. But the functionality is done: https://code.launchpad.net/~gmb/maas-test/add-reporting/+merge/198067
[14:39] <gmb> Sorry it's a bit lengthy.
[14:41] <allenap> gmb: \o/ I have to travel now, but I’ll take a look later unless rvba beats me to it (hint).
[15:14]  * gmb -> also travelling; bbiab
[15:28] <roaksoax> allenap: around?
[15:28] <roaksoax> i guess he is not
[15:35] <_bjorne> how is cloud-init funtion in clients? can i debug it on some way manual?
[16:11] <allenap> roaksoax: Hi there, what’s up?
[16:12] <roaksoax> allenap: just wante dto ask how does the mprovisioning server detect the architecture being pxe booted, but i found this : https://code.launchpad.net/~racb/maas/arch-detect/+merge/127458
[16:12] <roaksoax> so that pretty much answered my question
[16:13] <allenap> Cool :)


[05:59] <_46> hi
[08:34] <highvoltage> LaserJock: how do you know that!?
[08:35] <LaserJock> jabber
[08:35] <highvoltage> aaah :)
[08:37] <LaserJock> actually it was because we spent a week together in Paris, but I didn't want to go there ;-)
[08:38] <highvoltage> what happens in Paris stays in Paris!
[08:40] <LaserJock> man, I could really use some Subway right now
[08:42] <highvoltage> well, seems like that story made it quite far :)
[08:42] <LaserJock> hmm, now that I'm a Fridge editor I could always put it there ;-)
[08:43] <highvoltage> LaserJock: heh
[08:43] <LaserJock> man, and think about that Burger King
[08:43] <LaserJock> that was soooo good
[08:44] <LaserJock> not that the Sevilla food was bad
[08:44] <LaserJock> it was just more like home or something
[08:44] <highvoltage> too be honest, the Burger King was the best Sevilla food I had :)
[08:44] <LaserJock> I liked that Mexicanish place
[08:45] <highvoltage> RichEd: actually I think the hotel food was quite good. had bacon and eggs quite often there :)
[08:45] <highvoltage> oh yes, that mexicanish place was fantastic
[08:45] <highvoltage> pity we didn't go there again.
[08:45] <RichEd> :) agreed ... b&e with tabasco ... that's a good way to start the day
[08:45] <RichEd> mehico was good as well
[08:46] <LaserJock> it was much nicer than Paris, which was a relief
[08:47] <LaserJock> the hotel food was just fine and going out for dinner was enjoyable
[08:47] <LaserJock> no shuttle ride then 30min train ride
[08:50] <highvoltage> yes, transport was way better in spain.
[09:06] <LaserJock> anybody here running gutsy, is more like it
[09:06] <LaserJock> ?
[09:29] <RichEd> hello pips1
[09:34] <LaserJock> RichEd: when are you and ogra going over specs?
[09:34] <RichEd> LaserJock: in 2.5 hours time
[09:44] <Rictoo|SLP> how do I see my current kernel version?
[09:46] <pips1> Rictoo: uname -v
[09:46] <pips1> or you probably want the kernel release, which you get with "uname -r"
[09:47] <pips1> ^^^ type that command into a text console (shell) :-)
[09:47] <RichEd> pips1: he left already ... ducked in, asked, and ducked out again :(
[09:47] <pips1> arg, I missed that
[09:49] <LaserJock> pips1: don't worry, I do that all the time
[09:49] <pips1> LaserJock: :-)
[09:51] <LaserJock> what would you guys call our 3 age ranges?
[09:51] <LaserJock> well, or what age ranges do you think we should have for a set of applications
[09:52] <LaserJock> I was thinking young, primray, secondary
[09:52] <LaserJock> but perhaps there isn't much distinction between young and primary
[09:53] <LaserJock> RichEd, pips1 ^^ ?
[09:54] <RichEd> LaserJock: yep ... that does not fit with all nations naming of schools, but it is a universally understood set of brackets
[09:55] <RichEd> I'd see 4 actually: young, primary, secondary and then the naming should go tertiary, but somehowe university seems more appropriate to me
[09:56] <RichEd> *but* I think we are a way away from convincing Universities to install Edubuntu and not Ubuntu, so that target level will not be in our sights for a while
[09:58] <LaserJock> well, it kinda depends
[09:58] <LaserJock> if we could choose the artwork on install
[09:58] <LaserJock> and I produces some decent uni-level metapackages
[09:59] <LaserJock> I'd say Edubuntu would pretty much be ready to rock quite a few University labs
[09:59] <LaserJock> of course stuff like network auth and some of the more corporate applications might not be ready yet
[10:00] <LaserJock> but as far as the smallish (10-30 computer) labs I see often in Uni deparments I think we're not too bad off
 of course stuff like network auth and some of the more corporate applications might not be ready yet
[10:08] <LaserJock> but as far as the smallish (10-30 computer) labs I see often in Uni deparments I think we're not too bad off
[10:09] <RichEd> LaserJock: the points you raise are valid, but we need to sort out the "perception stuff" before we can push it ...
[10:09] <RichEd> and by perception, I mean:
[10:09] <RichEd> 1. desktop look & feel for older students
[10:09] <RichEd> 2. menus for older students should not have the little kids stuff (or less prominent)
[10:10] <RichEd> 3. the edubuntu web site needs to move up an age level and get and stay updated
[10:10] <pips1> :-)
[10:11] <LaserJock> RichEd: exactly
[10:11] <LaserJock> but I think those aren't terribly hard things to do
[10:11] <LaserJock> in the whole scheme of things
[10:12] <RichEd> LaserJock: agree again, but i'd say that we "position ourselves" over the next release cycle, then give hard timelines for specific targets at release date, and then go for gold with 8.04
[10:13] <LaserJock> sounds good
[10:13] <RichEd> We're almost there, but we often wheelspin, so I think we need to be able to set a realistic date / time-frame, and nail it
[10:13] <LaserJock> RichEd: got a sec to do a brief look over my spec?
[10:14] <LaserJock> I need to go to bed but I'd like it in at least a reviewable state before I do so
[10:14] <LaserJock> pips1: you too
[10:14] <RichEd> sure ... where can I find it ?
[10:14] <pips1> url?
[10:14] <LaserJock> https://wiki.ubuntu.com/EdubuntuAddonEnhancements
[10:19] <RichEd> LaserJock: looks good, and is a significant need ... I'll make sure ogra and I give it high priority
[10:21] <LaserJock> RichEd: do you think there needs to be any additional metapackages?
[10:22] <RichEd> LaserJock: as per above, let's aim at the short list, and hit them properly. once the mechanisms are in place, we can extend the group
[10:23] <LaserJock> alright, as long as you think it'll fly, I'm happy
[10:23] <LaserJock> specs aren't so important for me as they are for the "employees"
[10:24] <LaserJock> if I'm implementing a spec I'm going to add/subtract as I go along as I'm not good enough yet to be able to figure out all the implemention before I start doing it ;-)
[10:24] <RichEd> just a comment, for milling around in the brain soup ... what about considering them as education-young, education-primary etc. so that they are meaningful for a dad who wants to install the packages on top of his ubuntu installation on his home PC ?
[10:24] <RichEd> i.e. do they need to be tied into edubuntu ?
[10:25] <LaserJock> hmm, let me check real quick, we might have a conflict with debian-edu
[10:25] <LaserJock> yep
[10:25] <LaserJock> education-* is taken by Debian-Edu metapackages
[10:26] <RichEd> so let's go with edubuntu for the spec, but we can always change names if we come up with a cohesive approach
[10:26] <LaserJock> yep
[10:27] <LaserJock> I'd almost rather we blacklist the Debian-Edu metapackages
[10:27] <RichEd> ?? that sounds heavy ... what do you mean by that ?
[10:27] <crimsun> why not consider carving up the namespace with the edubuntu- prefix (as I suppose RichEd alluded to)?
[10:27] <LaserJock> it might not seem very nice, but I don't know that they're useful for us
[10:28] <LaserJock> well, if we're trying to go more generic than edubuntu-
[10:28] <LaserJock> then education- seems like the only obvious alternative
[10:28] <RichEd> the longer view may be to consider naming the packages as: ubuntu-education-*
[10:29] <RichEd> the approach forming now is that:
[10:29] <LaserJock> but then I'm afraid of getting really really long package names
[10:29] <LaserJock> I'd love to split secondary into content areas
[10:29] <RichEd> edubuntu is the turnkey ubuntu bundle that give you a simple one-process install for education
[10:29] <RichEd> ubuntu is a general base, to which you can add any or all of the education packages
[10:30] <RichEd> but let me get that laid out clearly for discussion before we leap into the great beyond
[10:30] <RichEd> so LaserJock for the moment, go simple ?
[10:30] <crimsun> LaserJock: (long package names are not a constraint.  I -doubt- you'll hit even the 16-bit char limit.)
[10:31] <LaserJock> well, no, not a technical constraint
[10:31] <LaserJock> but I'm afraid of confusing people and making it just look bad in synaptic say
[10:31] <crimsun> Err, I hope people read the descriptions foremost...
[10:32] <LaserJock> hehe, that might be a bit of an assumption
[10:32] <LaserJock> anyway, you're probably right
[10:32] <LaserJock> at this point though, I don't foresee us putting very many apps in
[10:33] <LaserJock> I want to use the Universe meta packages as "these are good apps we should think about putting on the CD" rather than "here is every app in Ubuntu for X"
[10:33] <pips1> LaserJock: read your spec, sounds good. however, you might want to add a paragraph about "discussion points" <-- the meta package naming discussion (possible name space conflict with debian "education-" packages...)?
[10:34] <LaserJock> pips1: I could, but then I'm admitting I don't know exactly what I'm doing ;-)
[10:34] <pips1> don't start a flamewar in the wiki though :-)
[10:34] <pips1> LaserJock: hehe
[10:35] <pips1> LaserJock: ok, go for bold statement, then, that's close to the sabdfl's spirit anyway ;-)
[10:39] <LaserJock> pips1: ok, reload it and look at the bottom
[10:41] <pips1> LaserJock: well done
[10:42] <LaserJock> ok, I'm going to leave it at that
[10:42] <LaserJock> it's almost 2:00am
[10:42] <LaserJock> good night everybody
[01:07] <pips1> highvoltage: I'm sorry I won't be able to attend the meeting, since I have another meeting, but I'm definitely interested in what you discuss about the edubuntu.org site (your template chages). I'll read the meeting log and get in touch via mail
[01:07] <pips1> *changes
[01:08] <RichEd> ogra or ogra-classmat1 : ping
[01:12] <ogra-classmat1> RichEd: i'm here
[01:13] <RichEd> hi there
[01:13] <ogra-classmat1> trying to find wills spec overviviwe page
[01:13] <RichEd> okie
[01:13] <ogra-classmat1> https://wiki.ubuntu.com/Edubuntu/Devel/RoadMap
[01:14] <ogra-classmat1> there we go
[01:14] <RichEd> loading it now
[01:14] <ogra-classmat1> oh,m there is one missing
[01:16] <RichEd> which one is missing ?
[01:16] <ogra-classmat1> ltspfs-virtual-hal-devices
[01:16] <ogra-classmat1> just adding it
[01:17] <ogra-classmat1> whoops, you got the lock
[01:18] <RichEd> nah abandoned it ... you can grab the page ... i ws just checking if the table of contents was added automatically or if will put it in
[01:18] <RichEd> *was
[01:22] <ogra> ok
[01:23] <ogra> my high prio list: ltsp-boot-performance, ldm-improvements, edubuntu-application-review, edubuntu-artwork-procedures
[01:25] <ogra> my medium list: ltsp-update-manager-integration, ltspfs-virtual-hal-devices, edubuntu-addon-enhancements, edubuntu-menus-completion, edubuntu-documentation-procedures
[01:25] <ogra> the rest would fall under low prio for me
[01:26] <RichEd> ogra: check msg for some quick context
[01:31] <highvoltage> ogra: good list
[01:31] <RichEd> ogra: great ... my first question is how much of the LTSP stuff can we assume distro resources will take up ?
[01:32] <highvoltage> ogra: did we perhaps discuss the dual-cd thing at uds? I'm coming down with a cold so my memory isn't very good atm. some users have been unhappy about the applications on the live cd not available on install
[01:33] <RichEd> highvoltage: I'll need to add to the objectives or the spec list that we need to review the way the CDs are named and put together.
[01:33] <highvoltage> RichEd: ok. that would be really nice
[01:33] <ogra> highvoltage, dual-cd as in ubuntu server and edubuntu-addon ?
[01:33] <RichEd> we'll need to bed that down in the next week or two, but I see that as rearrangement and not a new requirement per se
[01:33] <ogra> or dual CD as in we need to fix that livecd ?
[01:34] <RichEd> hi there mr vagrantc :)
[01:34] <ogra> the first wont happen ... we'll likely even drop the ubuntu server Cd and have an LTSP feature on a new server DVD
[01:34] <vagrantc> greetings
[01:34] <ogra> the second one is a bug i talked with cjwatson about and we agreed to take care for it before release together
[01:35] <ogra> hey vagrantc :)
[01:35] <highvoltage> ogra: I meant, we just need to make it more straight-forward for the users, it's a bit confusing as it is at the moment (as you know, of course). I don't really mind so much in how it gets better, as long as it is kept in mind for the next release
[01:35] <highvoltage> ogra: ok, great
[01:35] <highvoltage> greetings vagrantc
[01:35] <ogra> highvoltage, the liveCd will install everything the user sees on the desktop in gutsy
[01:35] <ogra> you wiont need the addon for this
[01:35] <vagrantc> ogra: what list are we looking at?
[01:35] <RichEd> highvoltage: some of the issue is in the descriptions ...and we can solve this with some nice "how to get where you want to be" pages
[01:35] <highvoltage> ogra: cool, that's perfect!
[01:35] <ogra> so the naming can stay as is because it will be correct then
[01:36] <ogra> we correct the world, not the docs ;)
[01:36] <RichEd> that will be web site revision ... not needed as a spec ... but will need to taken care of.
[01:36] <ogra> vagrantc, https://wiki.ubuntu.com/Edubuntu/Devel/RoadMap
[01:36] <ogra> vagrantc,
 my high prio list: ltsp-boot-performance, ldm-improvements, edubuntu-application-review, edubuntu-artwork-procedures
 my medium list: ltsp-update-manager-integration, ltspfs-virtual-hal-devices, edubuntu-addon-enhancements, edubuntu-menus-completion, edubuntu-documentation-procedures
 the rest would fall under low prio for me
[01:37] <RichEd> ogra: a couple of people (as you have seen) asked why they need to use the Server CD to add applications to their workstation install. Will that also be resolved through the changes you anticipate ?
[01:38] <ogra> RichEd, nope, but we can fix that in the CD menu with adding "(needs the addon cd)" for example
[01:39] <ogra> that way its right in the face of the user
[01:39] <vagrantc> ogra: do you group ldm-load-balancing in with ldm-improvements ?
[01:39] <ogra> in the moment he nee4ds to know it
[01:39] <ogra> vagrantc, oh, yes, i did ---
[01:39] <ogra> i shouldnt
[01:39] <ogra> locald balancong is mid-low to me
[01:39] <ogra> could as well go into gutsy+1
[01:40] <ogra> the general rewrite of ldm is way more important
[01:41] <ogra> vagrantc, what was the specname of our spec for that ?
[01:41] <RichEd> my comments: I'd like to move edubuntu-documentation procedures up to high priority
[01:41] <ogra> we hd created a separate one
[01:41] <vagrantc> ogra: ldm-load-balancing ?
[01:41] <ogra> RichEd, even though we didnt hzave much input from the doc team yet ?
[01:42] <ogra> ah, registered inder ltsp, thats why i dont find it
[01:42] <RichEd> ogra: a couple of reasons ... #1 we need to get a "clockwork release cycle" to reduce the ad hoc last minute panics of gaps
[01:43] <RichEd> panics *or* gaps
[01:43] <RichEd> it is a pity if we have a quality product that is let down a bit by documentation (and I include web site in this)
[01:45] <ogra> i hope some community members will pick up
[01:46] <RichEd> ogra: I think we will be able to arrange that, if they have a framework to work under ...
[01:46] <RichEd> If they do not have a framework, then it goes ad hoc again. So I am not talking abou getting it all done for the next release, but getting a structure is a high priority
[01:47] <RichEd> w.r.t. on the priorities list, could we perhaps look at priorities against future versions, with a longer view ...
[01:47] <RichEd> so instead of labelling high/medium/low ...
[01:47] <RichEd> we arrange them in gutsy/gutsy+1/gutsy+2
[01:48] <RichEd> my specific example is that I think that: edubuntu-addon-enhancements, edubuntu-menus-completion : are almost non-negotiable for gutsy+1
[01:48] <RichEd> if something is low priority now for the next release, then it stays low ... and can get missed again.
[01:49] <RichEd> I'd like to see that we "prepare for edubuntu-addon-enhancements, edubuntu-menus-completion" in this relase cycle ... and then hit them for the next one ?
[01:49] <ogra> right
[01:49] <ogra> well
[01:49] <RichEd> i.e. look at any obstacles now, and get those under control ... like that gnome menu bug or wobbly you mentioned
[01:50] <RichEd> also then, it gives our audience an idea of what will arrive when ... pinned more accurately to a delivery ?
[01:50] <ogra> i would tag mid prio stuff as "can be finished next release"
[01:51] <ogra> and low prio stuff "if we find time"
[01:52] <ogra> the high prio stuff has to be done by release imho
[01:52] <RichEd> what about listing columns for releases, and arrranging features by release ...
[01:52] <ogra> thats a LP feature
[01:52] <RichEd> so what you call high is simply in the gutsy column as "definate"
[01:52] <ogra> you can tag specs for releases
[01:53] <RichEd> well for our planning then, I'll arrange as per releases ... and you can use the LP features to be consistent with the distro guys
[01:54] <ogra> well, we need to use that LP feature anyway, else they will get ignored
[01:54] <RichEd> perhaps we can allocate reponsibility that you manage the delivery of the current release cycle, and I'll look at managing the preparation for the *following* release cycle
[01:55] <ogra> well, i'm fine going on with managing the tech specs
[01:55] <RichEd> also a query: is moodle bundling covered in the application review process, or do we need to make it a specific target / spec ?
[01:55] <ogra> the thing is that you have to approve/decline
[01:56] <ogra> i dont think we need a spec for it ...
[01:56] <ogra> btw
[01:56] <RichEd> okay ... I'll keep it as a target ...
[01:56] <ogra> moquist, what happened to your moodle packaging effort ?
[01:56] <ogra> RichEd, i know moquist is/was on it ...
[01:57] <RichEd> ^^ approve decline ... walk me though how this would work in practice ?
[01:57] <ogra> add a distro target :)
[01:57] <ogra> i'll go through them and set priorities
[01:57] <ogra> after we agreed on proios indeed
[01:58] <ogra> there is an approver set for every spec, we need to set this to you
[01:58] <ogra> then you approve it for a release
[01:58] <RichEd> okay ... and to confirm ... we need this finalised by end of tomorrow w.r.t. the ubuntu gutsy schedule ?
[01:58] <ogra> no
[01:59] <ogra> the deadline for specs is tomorrowq
[01:59] <ogra> not the one for approval
[01:59] <ogra> but we should have our prio list done now
[01:59] <RichEd> so lets move to #ubuntu-meeting and continue in there ?
[01:59] <ogra> approval can go on over the week
[02:00] <ogra> let me get some fresh coffee :)
[02:00] <ogra> 3mins
[02:00] <RichEd> [02:02] <moquist> ogra: thx for the ping. :)
[02:03] <moquist> ogra: It's not dead, it's just...resting.
[02:04] <moquist> ogra: I've put it on the evening-time schedule for tonight or tomorrow night.
[02:04] <ogra> take your time, we just need to get it done this release :)
[02:05] <moquist> ogra: But the longer I let it go, the less I remember (even if I did save my bash history, etc.).
[02:05] <ogra> indeed
[02:05] <moquist> ogra: I'm sufficiently caught up after returning that now's a good time to return to it.
[02:05] <moquist> ogra: today I'm working more on the evil laptop, unless I get distracting word orders (always a possibility).
[02:07] <moquist> avahi seems to do funky things to my network interfaces. I'm not sure what it is, but after I kill it things behave more like I expect them to...
[02:21] <ogra> vagrantc, any proposals for the spec prio stuff ?
[02:21] <ogra> (we're in #ubuntu-meeting btw)
[03:45] <ace_suares> ogra!
[03:45] <ogra> hey
[03:45] <ace_suares> now you said, ldm patching would be easy, can we try it ?
[03:45] <ace_suares> do I need to compile
[03:45] <ogra> nope, its plain python
[03:46] <ogra> try to catch Gadi in #ltsp, he has a patch
[03:46] <ace_suares> okay going to #ltsp
[03:46] <ogra> its actually just setting the DISPLAY variable to the
[03:47] <ogra> thin client ip
[03:47] <vagrantc> and not using -X
[03:51] <ogra> right
[04:00] <RichEd> ace_suares: I'd be interested in chatting further on how we could work together ...
[04:01] <RichEd> give me a week to finalise our goals, objectives and actions for the rest of this year, and then I will share them with you and you can comment
[04:03] <sbalneav> Morning all
[04:06] <RichEd> hi sbalneav
[04:31] <cliebow> Scottie:!!!!
[04:37] <_46> Just installed edubuntu, ti's great
[04:38] <highvoltage> _46: :)
[04:39] <_46> Thank you for the acknowdgement :D
[04:40] <_46> this is my 1st. day on this channel.
[04:41] <highvoltage> _46: welcome to edubuntu!
[04:42] <highvoltage> _46: sometimes we may take a while te respond, but whenever you need help, just give us a shout and hang around
[04:42] <_46> ok, thank you
[04:42] <highvoltage> you're welcome.
[04:43] <_46> I've only been using Linux for less than 6 months, and I type with the 2 index fingers.
[04:46] <highvoltage> are you a teacher? or installed at home?
[04:46] <moquist> ogra: I'm sitting here with a feisty system defaulting to "US English". It uses A4 papersize for any new printers I set up.
[04:46] <moquist> ogra: I mention this just because we discussed it @UDS.
[04:49] <_46> installed at home, no teacher
[04:50] <_46> I am not affraid to open a box and check it for hardware etc.
[04:51] <_46> I do little things like change out hard drives or memory sticks...
[04:53] <_46> Have been known to change OS 2 or3 times a day, my installs must be perfect...
[04:55] <_46>  I have to go away now, till later...
[05:35] <RichEd> ogra: pingidy ping
[05:36] <RichEd> comment at leisure or sendme an email on the following:
[05:36] <RichEd> #1 are there any specs left over from feisty or edgy that we need to revive for gutsy
[05:37] <RichEd> #2 I'm making an action to tidy out the old LP pecs (for a task to do soon) and have also asked will to add it to the version cycle requirements
[05:37] <RichEd> LP specs ... not pectorals
[05:38] <jsgotangco> hi!
[05:39] <RichEd> hello jsgolatindancing
[05:40] <jsgotangco> huh?
[05:40] <jsgotangco> you're into ballroom dancing?
[05:45] <RichEd> tango ... bad pun
[05:46] <RichEd> bye for today peops
[05:46] <ogra> ciao
[06:39] <pips1_away> good evening
[07:55] <LaserJock> bah
[07:55] <LaserJock> is RichEd gone?
[07:56] <ogra-classmate> yep
[07:56] <LaserJock> I think the doc spec is sort of a weird thing
[07:57] <LaserJock> all that needs to be done is for Edubuntu docs efforts to fall in line with the general Doc Team
[07:57] <LaserJock> they already have the framework
[07:57] <LaserJock> and by the end of Feisty we were pretty much there
[07:57] <LaserJock> we were just a bit behind ;-)
[07:57] <LaserJock> I'm not sure why we even need that doc spec
[07:58] <ogra-classmate> well, if he wants it, give it to him and set it to implemented in a week :P
[07:58] <ogra-classmate> but i think he thinks beyond docteam ...
[07:59] <ogra-classmate> i.e. the contributor side and how to organize that
[07:59] <LaserJock> well, whatever, like you said, I'll give it to him ;-)
[07:59] <LaserJock> ogra-classmate: crimsun and I had a talk about gcompris last night
[08:00] <LaserJock> it looks to me like gcompris only needs gnuchess at runtime
[08:00] <LaserJock> I don't know why it's in the ./configure script
[08:00] <LaserJock> it has a hard coded path to gnuchess
[08:01] <LaserJock> I'm going to just patch it to look for gnome-gnuchess from gnome-games and see if that works
[08:01] <LaserJock> rather than rip out all the gnuchess stuff
[08:01] <LaserJock> you'd think they would have a configure flag to disable it, but no
[08:02] <ogra-classmate> tsk
[08:03] <LaserJock> they just have:
[08:03] <LaserJock> gnuchess_bin = g_build_filename( exec_prefix, "bin", "gnuchess", NULL);
[08:03] <LaserJock> so I think I can remove the build dep on any chess
[08:03] <LaserJock> and change the above line to look for gnome-gnuchess
[08:04] <quintin> Is there anything in edubuntu for managing the length of login sessions on public computers?
[08:07] <LaserJock> Quintin: I don't think there is a particular tool yet for that
[08:07] <LaserJock> Quintin: it's a fairly often requested feature
[08:07] <Quintin> well dammit make it already
[08:07] <Quintin> I've made something that sort of works in perl
[08:07] <Quintin> in combination with the "slay" program.  It's hardly professional though
[08:07] <ogra> LaserJock, yes, and i got this code from linus for it he refused to license :(
[08:09] <LaserJock> ogra: for what? the timer?
[08:10] <ogra> yes
[08:10] <LaserJock> that's too bad
[08:10] <ogra> a little c proggy running in his daughters session
[08:14] <Quintin> ogra: what did you get from Linus?
[08:15] <ogra-classmate> a proggy to restrict login time
[08:16] <Quintin> why not just rewrite it then? :p
[08:16] <Quintin> I don't see why he wouldn't license it
[08:16] <ogra-classmate> he didnt like to care about it ...
[08:18] <ogra-classmate> (about anything related to it... he didnt answer my mails anymore at some point and i didnt want to be pushy)
[08:18] <ogra-classmate> it should become a TCM plugin and should be trivial to implement now that we have python-tcm
[08:19] <Quintin> well, get on it!
[08:19] <Quintin> I'm in a library now full of Windoze machines with cybrarian
[08:19] <Quintin> meh
[08:19] <ogra-classmate> after i did the three million other things, yes :)
[08:20] <ogra-classmate> we have a slight lack of developers in edubuntu
[08:21] <LaserJock> Quintin: you want to help everybody out and work on it?
[08:21] <LaserJock> that would be a cool thing
[08:21] <Quintin> I'm a very bad coder.  nothing I have made is fit for public consumption
[08:22] <LaserJock> hehe, I can understand
[08:22] <LaserJock> I'm a Chemist and I think sometimes my programming reflects it
[08:22] <Quintin> if my perl thing ever gets practical, I'd release it under GPL
[08:22] <Quintin> bye for now
[08:25] <LaserJock> ogra-classmate: blah, I found it, this is going to be easyish :-)
[08:26] <LaserJock> the build dep actually does do something
[08:27] <ogra-classmate> ah
[08:28] <LaserJock> it just has a fallback to a hard-coded path
[08:29] <LaserJock> ok, in a few minutes I should have a .deb to test
[08:41] <john_s> hello all I have a question about large memory support, does anyone care to talk about that?
[08:47] <LaserJock> I'm not sure, you can just ask and see if anybody knows
[08:52] <ogra-classmate> john_s: thats your mail thread, right ?
[08:53] <LaserJock> ogra-classmate: have you seen any recent reviews/stories on Edubuntu?
[08:53] <ogra-classmate> nope
[08:53] <LaserJock> any for Feisty?
[08:53] <ogra-classmate> will might be a better bet
[08:54] <LaserJock> hmm, yeah
[08:54] <LaserJock> go faster!
[08:55] <ogra-classmate> LaserJock: get your classmate and you will not complain anymore :P
[08:55] <LaserJock> heh
[08:56] <LaserJock> hopefully it's comings sson
[09:00] <LaserJock> ogra-classmate: I should have a debdiff for you in a little bit
[09:00] <LaserJock> I'll send it in an email
[09:08] <john_s> Hi ogra-classmate
[09:08] <john_s> are you stil there?
[09:09] <john_s> I do see your response on the list, but I am running the edubuntu server edition
[09:09] <john_s> unless I had a complete brain freeze
[09:10] <john_s> after all thats the only version of edubuntu with LTSP built in, isn't it?
[09:12] <LaserJock> I think so yes
[09:12] <john_s> thanks
[09:12] <LaserJock> john_s: was he talking about the Desktop CD?
[09:12] <john_s> perhaps
[09:13] <john_s> I think I am going to have to recompile the kernel to get high memory support
[09:13] <john_s> strange but true
[09:13] <john_s> well, perhaps not true, but that's my impression right now.
[09:17] <LaserJock> let me go read his email real quick
[09:17] <john_s> thanks
[09:17] <LaserJock> ah
[09:17] <LaserJock> well, we have several kernels
[09:17] <LaserJock> he meant to get the -server kernel
[09:17] <john_s> great
[09:18] <LaserJock> not install the the server disk
[09:18] <john_s> ok, sounds good. So what ships with the server edition of edubuntu?
[09:18] <LaserJock> confusing terminology
[09:18] <LaserJock> I think the normal Ubuntu kernel
[09:18] <john_s> hmm
[09:18] <john_s> ok
[09:18] <john_s> Thanks
[09:18] <LaserJock> as and LTSP server is essentially an Ubuntu desktop
[09:18] <john_s> where should I go to find the server kernel
[09:18] <LaserJock> it's in the repos
[09:19] <LaserJock> just use synaptic or apt-get
[09:19] <john_s> ok
[09:19] <john_s> thanks
[09:19] <sbalneav> To get high memory support, you'll want the linux-image-server package
[09:19] <john_s> ok
[09:19] <john_s> will I loose ltsp functionality do you think?
[09:19] <sbalneav> no
[09:19] <john_s> hurray
[09:19] <sbalneav> That will just install a kernel that will support > 4G
[09:20] <john_s> ok, and ideally all of the other switches that were thrown for the stock kernel will be thrown for this one as well
[09:20] <john_s> ?
[09:21] <sbalneav> Should be.
[09:21] <john_s> ok, I'll see what I get
[09:21] <john_s> thanks for your help
[09:21] <sbalneav> NP
[09:22] <john_s> ok
[09:22] <john_s> sorry one more question
[09:23] <john_s> do i want linux-image-server or linux-image-server-bigiron
[09:23] <john_s> synaptic isn't very descriptive in this cas
[09:26] <LaserJock> hmm, I'm not sure what bigiron is
[09:26] <LaserJock> I'd guess you'd want just -server
[09:26] <john_s> ok
[09:27] <john_s> Yeah, big iron to me is a mainframe
[09:27] <john_s> Is there a place where I could go to find stuff out about the various kernels?
[09:28] <sbalneav> Big iron's got all the stuff compiled in for >64 cpu's, or for running on an E390
[09:28] <john_s> ok
[09:28] <john_s> not me then
[09:28] <john_s> thanks
[09:29] <sbalneav> I think the joke would be, "if you have to ask if you need the bigiron kernel, you don't need the bigiron kernel" :)
[09:29] <john_s> heh
[09:35] <ace_suares> it hink -server is for 'Server Equipment' and I thinks that's different from standard intel 686 stuff
[09:35] <ace_suares> altough I happen to be running -server on one of my dual xeons... it seems to work.
[09:48] <Pyld> Anyone using Edubuntu/Ubuntu as diskless clients?
[09:50] <LaserJock> Pyld: do you have a particular problem?
[09:52] <Pyld> LaserJock: I have problems with NFS mounts. I have a separate rootfs for each diskless client and a shared /usr that is mounted ro, but the clients stalls for about 1 minute during the mount and Ubuntu prints Failed even if /usr is mounted.
[09:53] <Pyld> I have tried Debian 4.0 as well and do not experience such problems so my NFS setup is okay on the server
[09:54] <Pyld> I have checked with rpcinfo -p <hostname>. rpc.lockd, rpc.statd and portmap is running on the diskless client.
[09:55] <Pyld> the server setup also seems okay. By the way, if I try to mount /usr after the diskless client finally have booted I do not experience such delays. /usr is mounted instantly. It is just during boot
[10:00] <LaserJock> Pyld: boy, I haven't really done anything with NFS
[10:01] <LaserJock> so I don't have much of anything to offer
[10:01] <LaserJock> Pyld: but perhaps the edubuntu-users mailing list might be a good place to try
[10:01] <LaserJock> there are quite a few people there that might know
[10:03] <Pyld> LaserJock: okay, I will try.
[10:12] <moquist> ogra-classmate: jammcq's 4.2 kernel config saved me about 62 seconds on this craptop
[10:12] <moquist> ogra-classmate: Now I'm down to 184 seconds from DHCP->login prompt
[10:13] <moquist> ogra-classmate: gtk (the C implementation) still uses almost all the processor it can get for 60-70 seconds every time.
[10:14] <moquist> I guess that looks crappy, or something.
[10:16] <LaserJock> well, it might be worth a shot
[10:16] <LaserJock> but if you need a console-based login screen isn't running a desktop going to be a problem?
[10:16] <LaserJock> or is it just on the clients end?


[08:50] <santa_> good morning everyone
[08:51] <santa_> RikMills: FYI I'm going to "finish" in the next hour or so, that pending KA release i.e.:
[08:51] <santa_> - I will copy the package to the dev-tools-testing PPA
[08:52] <santa_> - I will push the changelog entry + tag to git
[08:52] <santa_> all the code changes are already in git master
[13:31] <BluesKaj> 'Morning folks
 Hello