[00:36] <pmatulis> Damnit__, what instructions are you following? in general i mean
[08:57] <mup> Bug #1663517 opened: test_calls_decompose_machine leaving junk in reactor <tests> <MAAS:In Progress by allenap> <https://launchpad.net/bugs/1663517>
[10:59] <zeestrat> Hey, how can I change the hostname of a region/rack controller via the GUI or CLI?
[11:25] <brendand> zeestrat, there might be a ui bug in changing the hostname..
[11:32] <zeestrat> brendand: I'm not sure if I understand. Could you elaborate?
[11:33] <brendand> zeestrat, the list of controllers is at MAAS/#/nodes?tab=controllers
[11:33] <brendand> if you click on one, then click on the hostname field, it doesn't let you edit it. i'm not sure if that is intentional
[11:33] <brendand> roaksoax, should we be able to update the controller hostname?
[11:34] <zeestrat> Yes, I noticed that. So I was hoping there was a way to do so with the CLI.
[11:39] <brendand> zeestrat, i can't actually see a way at the moment, the region-controllers update command has no hostname parameter that i can see
[11:57] <zeestrat> brendand: I couldn't find anythere there either. Shal I wait for a response from roaksoax before creating a bug?
[12:03] <brendand> zeestrat, you could file a bug along the lines of 'controller hostname field not editable'. if it's not *meant* to be editable it should not be a text field, i think
[12:05] <mup> Bug #1663569 opened: [2.2] Prefer using <fabric-name>-<vlan-name> for shared network statement in dhcpd.conf <MAAS:New> <https://launchpad.net/bugs/1663569>
[12:14] <mup> Bug #1663569 changed: [2.2] Prefer using <fabric-name>-<vlan-name> for shared network statement in dhcpd.conf <MAAS:New> <https://launchpad.net/bugs/1663569>
[12:17] <mup> Bug #1663569 opened: [2.2] Prefer using <fabric-name>-<vlan-name> for shared network statement in dhcpd.conf <MAAS:New> <https://launchpad.net/bugs/1663569>
[12:28] <roaksoax> admcleod: no you cant
[12:28] <roaksoax> err
[12:28] <roaksoax> admcleod: sorry
[12:28] <roaksoax> zeestrat: no you cant
[12:28] <roaksoax> zeestrat: i responded on the bug
[12:28] <roaksoax> zeestrat: but basically, MAAS does not have a running agent on the controllers to change the hostname of the underlying system
[12:30] <zeestrat> roaksoax: Changing the hostname of the system is not a problem, however changing that (i.e. /etc/hostname) does not seem to update it in MAAS.
[12:35] <zeestrat> Basically we had a change of naming policy and would like this change to also reflect in MAAS on our controllers running in production.
[12:35] <roaksoax> zeestrat: does hostname -f reflect your new hostname ?
[12:36] <roaksoax> zeestrat: so you want ot change the underlying hostname but it doesn't reflect in MAAS
[12:36] <roaksoax> zeestrat: i'd recommend you re-open the bug and rename it to "changing controller's underlying machine hostname does not reflect in MAAS"
[12:38] <roaksoax> zeestrat: actually
[12:38] <roaksoax> zeestrat: i just tested
[12:38] <roaksoax> zeestrat: and it changed the hostname for me
[12:38] <roaksoax> zeestrat: i did: sudo hostname xyz
[12:39] <roaksoax> zeestrat: updated it in /etc/hosts
[12:39] <roaksoax> zeestrat: sudo service maas-rackd restart
[12:39] <roaksoax> zeestrat: and boom, new hostname
[12:40] <zeestrat> Oh, then I must have done something wrong. Let me try again.
[12:41] <roaksoax> zeestrat: try restarting maas-rackd
[12:41] <zeestrat> Will do. Get back to you in a few min.
[12:45] <roaksoax> tested again
[12:48] <brendand> roaksoax, also i think the controller hostname should be text and not an uneditable text-field. it's a bit confusing atm
[12:51] <roaksoax> brendand: maybe it is the browser, it doesn't show as an uneditable text field to me
[12:51] <brendand> roaksoax, when you click on it what happens?
[12:52] <roaksoax> nothing
[12:57] <brendand> roaksoax, looking at the angular code it does appear to be a non-editable text field
[12:59] <roaksoax> brendand: maybe because I'm now looking at latest trunk :)
[13:05] <zeestrat> roaksoax: You were absolutely right. Dumb mistake on my part. Forgot about an old node with the same name so of course MAAS complained because of the name collision.
[13:06] <roaksoax> zeestrat: no worries, it is not something obvious anyway :)
[13:06] <zeestrat> Thanks for bearing with me :)
[13:06] <roaksoax> zeestrat: thanks for using maas :)
[13:10] <zeestrat> roaksoax: With the hours we have saved we owe y'all a beer or two! Just give a ping if you come by Norway by any chance.
[13:13] <zeestrat> roaksoax: While I have you, do you know if there's a doc that describes which connections/ports are used between region and rack controllers? I saw some discussions in https://bugs.launchpad.net/maas/+bug/1352923 but nothing up to date.
[13:24] <pmatulis> zeestrat, afaik tcp ports 5240 and 5250-5259
[13:59] <roaksoax> zeestrat: 5250-5259 is for internal communication between region/rack
[13:59] <roaksoax> zeestrat: for user access, 5240
[14:04] <zeestrat> How about if you have region controller in HA with a VIP (keepalived as per your guide)? Do the rack controllers only talk to the VIP set in the rackd.conf, or also directly to one of the region controllers?
[14:26] <mup> Bug #1663612 opened: [2.2, UI] During commissioning, UI shows 'Error:Node must be connected to a network.' <MAAS:New> <https://launchpad.net/bugs/1663612>
[14:26] <mup> Bug #1663614 opened: MAAS creates a websocket connection per tab <performance> <MAAS:Triaged> <https://launchpad.net/bugs/1663614>
[15:39] <MaWe_> Hello there, I've a strange error while commisioning: "update clock skew to -7324" and "http error 401"
[15:40] <MaWe_> after several unique messages (within minutes) the systen shuts down.
[15:41] <MaWe_> MaaS node list shows "Failed commisioning"
[15:41] <MaWe_> 3 nodes, 3 errors :-(
[15:41] <MaWe_> any suggestions?
[15:49] <roaksoax> MaWe_: what version of MAAS are you using ?
[15:49] <roaksoax> MaWe_: seems like the clocks on your systems are not in sync
[15:49] <roaksoax> MaWe_: but cloud-init and ntp should handle that
[15:51] <MaWe_> Version: 2.1.3+bzr5573-0ubuntu1~16.04.1
[15:52] <MaWe_> maas-server was out of sync, did a 'service ntp restart' and it worked.
[15:52] <MaWe_> how can i test if cloud-init and ntp are ok?
[15:53] <roaksoax> MaWe_: go to the MAAS UI, Under the nodes tab, go to Controllers
[15:53] <MaWe_> nameservers are configured and should work
[15:53] <roaksoax> access your controller and see the status of the services
[15:53] <roaksoax> make sure that ntp shows gree
[15:54] <mup> Bug #1663643 opened: Pod compose handles timeouts badly <pods> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1663643>
[15:54] <MaWe_> ntp is green
[16:04] <roaksoax> MaWe_: and the issue keeps happening ? cloud-init should just fix the clock-skew
[16:06] <MaWe_> it keeps happening :-(
[16:09] <MaWe_> sorry.. have to leave now, will reboot the machine and try it on monday. -- thanks for your help
[16:30] <mup> Bug #1663651 opened: [2.2, rev5710] MAAS has 'test' action, but it has nothing in it. <MAAS:New> <https://launchpad.net/bugs/1663651>
[16:30] <mup> Bug #1663652 opened: Maas with HA and remote rsyslog not work <MAAS:New> <https://launchpad.net/bugs/1663652>
[16:30] <bladernr> roaksoax, am I correct in thinking you can apply kernel parameters now based on tags? (e.g. tag=noacpi could apply the acpi=off parameter to the kernel)?
[16:31] <bladernr> roaksoax, and if so, does that only apply to the ephemeral, or is it also set when the deployed kernel is installed?
[16:46] <roaksoax> bladernr: you were always able to apply parameters based on tags
[16:46] <roaksoax> bladernr: it will apply them to deployed machines too
[16:51] <bladernr> ahhh, ok.  What I meant, I guess was that I just learned that it was possible (so new to me).  Thanks for confirming!!
[18:09] <mup> Bug #1663686 opened: [2.2] After machine is set 'Ready' (after commissioning), messages fail to post <MAAS:Triaged> <https://launchpad.net/bugs/1663686>


[04:44] <dupingping> https://bugs.launchpad.net/lightdm/+bug/1517309
[05:38] <pitti> smoser, slangasek: booting with systemd.log_target=console will make the logging visible to the console if you don't want it in the journal; systemd.log_level=debug only increases verbosity of systemd itself -- if you want also kernel debugging, use "debug" (the kernel reads that by itself)
[05:39] <pitti> logging to kmsg is also useful in some cases, mostly if the journal is broken
[05:40] <pitti> sarnold, jetsaredim: err, do you still see bug 1511376 with current images? I'm not aware of anything else right now that still creates broken /etc/mtab, what/how did you install?
[05:40] <pitti> and yes, you can ignore kdbus, it's not at all related
[05:40] <jetsaredim> pitti: it got sorted
[05:40] <jetsaredim> thanks
[05:41] <pitti> jetsaredim: still some installer problem?
[05:41] <jetsaredim> turns out systemd was complaining about a fstab entry for a mdadm device that had yet to be created in the boot cycle
[05:42] <pitti> that still sounds like a bug
[05:42] <jetsaredim> it was a user-created md
[05:42] <jetsaredim> if that matters
[05:43] <jetsaredim> I regularly have issues with the system every time it reboots having to go in and manually stop & re-assemble the dev
[05:43] <pitti> I mean, MD arrays are supposed to be auto-assembled at boot, and if fstab wants to mount something from it it should wait until that has happened
[05:43] <pitti> so apparently the waiting part works, but not the assembly
[05:43] <jetsaredim> it certainly waited
[05:43] <jetsaredim> yea
[05:43] <jetsaredim> not sure what's with my config i don't reboot the system that often so it only comes up about twice a year
[05:44] <jetsaredim> its like the auto-config that's supposed to happen on boot is just not smart enough to do it right
[05:45] <jetsaredim> when the system's finally up and I can login I literally just have to run "mdadm -S <dev>; mdadm --assemble <dev>" and all is right with the world
[05:47] <jetsaredim> which you'd *think* would work during boot too...
[07:13] <nils17>  Does any one have an idea: when executing the command (alt+f2)  gksudo xfce4-terminal I get the warning "granted permissions without ask for password"... do you know where this setting is stored? (to disable it)
[07:32] <dholbach> good morning
[07:35] <FourDollars> pitti: Could you help to review https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381625 ?
[07:38] <pitti> FourDollars: that looks more or less like a straight port of the upstream gnome-settings-daemon heuristics, right?
[07:38] <FourDollars> pitti: yes
[07:41] <pitti> replied
[07:42] <pitti> FourDollars: this is loads better than https://code.launchpad.net/~kaihengfeng/unity-settings-daemon/add-brightness-limit-mechanism/+merge/277416 :)
[07:42] <FourDollars> pitti: yup
[07:44] <FourDollars> pitti: Thx a lot. BTW, when will it be merged into lp:unity-settings-daemon if everything is OK?
[07:46] <pitti> FourDollars: it's CI train managed, so I guess you can just reuqest a landing
[07:48] <FourDollars> pitti: How can I request a landing?
[07:48] <pitti> FourDollars: there's a new system, https://requests.ci-train.ubuntu.com/
[07:48] <pitti> I haven't used it myself either yet, but hopefully not too different from the old spreadshet
[07:49] <pitti> otherwise the desktop team can certainly help you with that
[07:49] <seb128> that system is to do landings though
[07:49] <seb128> not to request somebody else to do one for you
[07:49] <pitti> right, but can't FourDollars request/do a landing?
[07:49] <seb128> and we do regular u-s-d landings when there are enough changes to justify one
[07:49] <pitti> ah, ok
[07:49] <seb128> pitti, dunno what team membership is needed
[07:49] <seb128> if you have upload rights you can
[07:50] <seb128> but FourDollars probably doesn't have upload rights on the desktop set
[07:50] <FourDollars> Yup, I don't have the upload rights.
[07:50] <pitti> seb128: I thought that was the purpose of the train?
[07:50] <pitti> most phone developers don't have archive upload rights either
[07:52] <seb128> right
[07:52] <seb128> I think there is a lp team you need to join though
[07:52] <FourDollars> Ha~ After I login https://requests.ci-train.ubuntu.com, there are many pages I can not access.
[07:52] <seb128> better to ask on #ubuntu-ci-eng
[08:23] <LocutusOfBorg1> dupingping, hi, you there?
[08:23] <LocutusOfBorg1> wrt your virtualbox pkg join request
[08:24] <dupingping> LocutusOfBorg1: yes, i'm here.
[08:24] <LocutusOfBorg1> why did you request to join?
[08:24] <LocutusOfBorg1> that team is well... empty
[08:24] <dupingping> debian virtualbox team?
[08:25] <LocutusOfBorg1> you asked to join to the ubuntu virtualbox team, not the debian one
[08:25] <LocutusOfBorg1> I maintain virtualbox, but I use the alioth debian infrastructure for doing it
[08:25] <LocutusOfBorg1> anyway, do you plan to contribute in virtualbox?
[08:25] <dupingping> yes, right.
[08:26] <dupingping> And what is launchpad.net url for join?
[08:27] <LocutusOfBorg1> https://alioth.debian.org/projects/pkg-virtualbox
[08:29] <dupingping> LocutusOfBorg1: I created a new account.
[08:30] <dupingping> It shows me, https://launchpad.net/~pkg-virtualbox-devel and "Debian Virtualbox Team" team.
[08:30] <dupingping> wow, I have been joined.
[08:30] <dupingping> thank you.
[08:30] <LocutusOfBorg1> yes, but there is nothing to do on launchpad
[08:30] <LocutusOfBorg1> you need to apply to alioth
[08:31] <dupingping> oh, yes.
[08:36] <dupingping> I logged in to alioth, LocutusOfBorg1
[08:41] <LocutusOfBorg1> before accepting you I would like to see some patches, or some work on virtualbox
[08:41] <LocutusOfBorg1> it is a really deep package, and *really* difficult to maintain
[08:42] <dupingping> yes, i'll show a patch on oracle i made.
[08:42] <LocutusOfBorg1> e.g. you might start with testing this https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1517161 :)
[08:42] <dupingping> can you see https://forums.virtualbox.org/viewtopic.php?f=37&t=74546&p=345693#p345693 ?
[08:42] <LocutusOfBorg1> "You are not authorised to read this forum."
[08:43] <dupingping> yes, perhaps, you are not a virtual box contributor on oracle?
[08:43] <dupingping> virtualbox 5.0.x's revision r58717 is my patch.
[09:23] <cpaelzer> smb and I were discussing about the proper use of debian/watch
[09:23] <cpaelzer> we wondered if it should be encoded in a way to refer to the latest "possible" tarball
[09:24] <cpaelzer> or the latest tarball to the currently packaged version
[09:24] <cpaelzer> e.g. if we have Package-2.0 - should it
[09:24] <cpaelzer> a) only fetch and report 2.0.x updates
[09:24] <cpaelzer> b) or any >2.0 updates
[09:24] <cpaelzer> rbasak (and others) ^^ ?
[09:36] <pitti> cpaelzer: if you package multiple major upstream series, restricting it to the current microversion of that series seems adequate
[09:44] <LocutusOfBorg1> hi folks, is the ci sleeping today?
[09:44] <LocutusOfBorg1> http://autopkgtest.ubuntu.com/packages/v/virtualbox/xenial/amd64/
[09:44] <LocutusOfBorg1> I don't see the tests going
[09:47] <FourDollars> pitti: I saw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381625 is changed to "Won't Fix" by you. Could you help to change it back to Confirmed?
[09:48] <pitti> FourDollars: ah, you can't? done
[09:48] <pitti> ("in progress")
[09:48] <FourDollars> pitti: I don't have the permission to do that.
[09:49] <FourDollars> pitti: In fact, I also want to fix it in trusty. But I don't have the permission to also affect trusty series too.
[09:51] <pitti> FourDollars: added
[09:51] <FourDollars> pitti: thx
[09:57] <cpaelzer> pitti: thx
[09:59] <rbasak> cpaelzer: it's entirely up to you. For an Ubuntu-only package there isn't anything that runs uscan automatically for you. So debian/watch is only as useful as your ability to run uscan. So make uscan do what you want :)
[10:01] <cpaelzer> rbasak, thanks++
[10:19] <FourDollars> pitti: Could you help to set https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 as a top approved?
[10:19] <pitti> FourDollars: done
[10:19] <FourDollars> pitti: Cool. Thx.
[10:40] <Laney> cjwatson: What's the status on the ppc64el/wily upgrade?
[10:41] <Laney> We have gtk+3.0 -> mir -> liburcu blockage coming up. :)
[10:43]  * Laney sees some comments on the ticket
[10:57] <cjwatson> Laney: waiting for IS to see if wily images work on arm64 this time, then I should be able to ask for ppc64el/production shortly after
[10:59] <Laney> 'k
[11:11] <cjwatson> Laney: ah, progress on the ticket so I've replied asking for ppc64el/production
[11:12] <Laney> cjwatson: Oh, great, thanks
[11:51] <dupingping> hi lightdm developers.
[13:46] <smoser> pitti, thanks for following up.
[13:46] <pitti> smoser: what? where?
[14:23] <Mirv> could a core-dev do a QA acked copy to xenial (train is not understanding our switch of one binary package to new source package, so publishing manually): ./copy-package --from=~ci-train-ppa-service/ubuntu/landing-005 --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b ubuntu-ui-toolkit - everything else is done
[14:24] <Mirv> ticket https://requests.ci-train.ubuntu.com/#/ticket/670
[14:48] <pitti> Mirv: done
[16:41] <MrBIOS> good morning, would anyone who is familiar with the casper/livecd boot process happen to be around? I’m trying to debug some stuff and not having much luck
[17:25] <MrBIOS> bdmurray: ping
[17:27] <bdmurray> MrBIOS: hi
[17:27] <MrBIOS> bdmurray: I wanted to ping you regarding an (old, sadly) casper ticket https://bugs.launchpad.net/ubuntu/+source/casper/+bug/504103
[17:28] <MrBIOS>  any reason why that’s gotten zero love in four years? :"(
[17:29] <bdmurray> MrBIOS: Is that really the question you want me to respond to?
[17:30] <MrBIOS> well, if there’s a known workaround, I’d happily employ that
[17:30] <MrBIOS> I’m unfamiliar with the Ubuntu bug triage process
[17:30] <MrBIOS> all I really want to do is accomplish an install
[17:31] <Laney> xnox: you want to take the mdadm merge off me?
[17:31]  * Laney spots the new maintainer :)
[17:31] <bdmurray> There are lots and lots of bugs and this one only affects a couple of people, based off the bug, and is something of a corner case.
[17:33] <bdmurray> Are you trying to install a desktop version of Ubuntu?
[17:35] <MrBIOS> bdmurray: yes, I’m definitely in corner-case-land
[17:36] <MrBIOS> deep into it. I should set up a fort
[17:36] <MrBIOS> out of curiosity, do you guys accept man page improvements? :)
[17:37] <bdmurray> MrBIOS: Of course we'd accept a fix.
[17:40] <MrBIOS> bdmurray: I’m also getting an error when scripts/casper-bottom/25adduser gets called, where the  step fails with “pwconv: failed to change the mode of /etc/passwd- to 0600” and I have no idea why. Is that a known issue? I see it a lot in google searches, but not as the focus of attention
[17:41] <MrBIOS> this is unfortunate, since I then have no way to log in to examine log files to figure out why things aren’t progressing further
[17:41] <bdmurray> What release are you installing and how did you create the usb stick?
[17:41] <MrBIOS> this is 16.04, and I DD’ed the ISO to the stick.
[17:42] <MrBIOS> the same thing happens with 15.10 and earlier though
[17:56] <tsg> micahg: can you please comment on https://bugs.launchpad.net/trusty-backports/+bug/1515710?  what is needed to resolve this - there are 3 openstack bugs that are pending on this request, so I can provide any help needed
[17:57] <tsg> micahg: the trusty and precise backports are more critical
[18:02] <Laney> cjwatson: https://launchpad.net/ubuntu/+source/liburcu/0.9.1-2/+build/8293095 excellent
[18:02] <cjwatson> Laney: liburcu built now; will just need a bit of proposed-NBS cleaning
[18:02] <Laney> hah
[18:02] <cjwatson> yep :)
[18:02] <cjwatson> ppc64el guests are wily now
[18:02] <Laney> thanks for getting that fixed
[18:02]  * Laney nods
[18:03] <cjwatson> np
[18:03] <Laney> maybe autopkgtest will be less extremely backed up by tomorrow morning
[18:03] <Laney> gtk's triggered tests have barely moved all day
[18:03]  * Laney floats some more clouds
[18:03] <slangasek> according to pitti the queue is about a day long currently
[18:07] <cjwatson> Laney: liburcu2 proposed-NBS cleaned up too.  so now it's just whatever remains from that library transition
[18:07] <cjwatson> (2 -> 4)
[18:08] <Laney> Yeah. I'll look when update_output.txt has something to say about the matter tomorrow
[18:08] <Laney> 'night
[18:59] <lpotter> is there any way to edit my comments on a bug in launchpad?
[18:59] <dobey> no
[19:17] <smoser> hey
[19:18] <smoser> is this a known issue
[19:21] <lpotter> awe: ping
[19:21] <awe> lpotter, pong
[19:22] <lpotter> awe: in regards to nm bearer plugin. upstream has been refactored a bit, so it might benefit to use that
[19:22] <lpotter> I thought it had already been updated to it
[19:23] <awe> lpotter, has the code been released by upstream yet?  or is it just part of their latest devel?
[19:23] <awe> I'm super new to the Qt codebase
[19:23] <awe> I only started looking at as I started chasing this bug
[19:23] <lpotter> I am sure it was released
[19:24] <awe> ok, I'll poke around this afternoon
[19:24] <awe> it'd be great if they've already fixed this match rule leak
[19:24] <awe> it looks to me like a ref count problem
[19:25] <awe> as I'm never seeing the match rules ever get released by QDBusConnectionPrivate
[19:25] <lpotter> well, I refactored all objects so the are derived from QDBusAbstractInterface
[19:26] <lpotter> the old code is pretty fugly
[19:27] <awe> lpotter, I think the current code does that
[19:28] <awe> eg. QNetworkManagerInterfaceAccessPoint does so
[19:29] <awe> and it's the obect that's not properly disconnecting a signal watch for "PropertiesChanged"
[19:29] <awe> it also apparently sends a "GetAll" in response to the "PropertiesChanged" signals
[19:29] <awe> which is kinda broken too
[19:31] <lpotter> hmm.. I must have wrong ubuntu repo or something. all I see is original really ugly code
[19:31] <awe> well.... I've actually downloaded the source package from the phone overlay PPA
[19:32] <awe> as I didn't want to hunt for the VCS
[19:32] <lpotter> upstream uses the property map from PropertiesChanged
[19:32] <awe> when you say upstream, do you mean the 5.5 release, or code in devel branch?
[19:33] <awe> I just cloned the git5 repo...
[19:33] <lpotter> should be 5.5 but I could be wrong. I've lost track of Qt releases
[19:33] <awe> this is a slippery slope
[19:33] <awe> lpotter, k
[19:34] <awe> I'll take a look this afternoon...  so close to solving this bug, which has a *huge* perf impact
[19:35] <lpotter> yes 5.5.0 release has the changes
[19:36] <awe> ok; I'll def compare our code to that branch then
[19:36] <lpotter> :q
[19:41] <micahg> tsg: commented
[19:45] <lpotter> awe: but then the problem will be those blocking dbus GetAll calls when those objects are created. Which cannot really be changed as QNAM depends on syncronous backends
[19:45] <awe> lpotter, so... in the bug I'm working on, it sounded like "blocking" was an ambiguous term
[19:45] <awe> are you describing "blocking IO"?
[19:45] <lpotter> blocking as it waits until is gets an answer
[19:45] <awe> or apparmor "blocking"?
[19:46] <awe> got it
[19:46] <awe> we're on the same page then
[19:46] <lpotter> :)
[19:46] <awe> Mirv mentioned something about "apparmor blocking"
[19:46] <lpotter> there's that too.
[19:47] <awe> I care less about that, as it's a confined app problem, and I'll let others solve it
[19:47] <lpotter> which is why I wrote and suggested the connectivity-api plugin
[19:47] <awe> I'm just trying to ensure the plumbing works when used by unity, maliit, ...
[19:47] <awe> and doesn't gum up the rest of the system
[19:47] <awe> we have a security team to worry about apparmor, and they're all smarter than me anyways...
[19:47] <awe> ;D
[19:48] <lpotter> :)
[19:48]  * awe hopes the qt submodules don't eat all his diskspace
[19:48] <lpotter> at least its not aegis
[19:50] <lpotter> because of app armor restrictions on phone, all thats really needed in bearer is connected/disconnected
[19:50] <awe> for confined apps you mean?
[19:51] <awe> because the system apps need to distinguish between connected 'wifi' vs. connected '3g'
[19:51] <awe> and I think every process also needs to know about flight-mode
[19:51] <awe> and/or individual 3g blocked, wifi blocked
[19:52] <lpotter> do they use QtBearerNetwork?
[19:52] <lpotter> I meant for things using QNetworkAccessManager and QNetworkRequest & friends
[19:53] <awe> it's a bit confusing, and I can't answer all of those questions directly
[19:53] <awe> as I don't know the code bases all that well
[19:53] <lpotter> if they use QNetworkConfigurationManager than yes, that connectivity-api will not be useful
[19:53] <awe> ( I typically work on ofono, NetworkManager, ... )
[19:54] <awe> lpotter, https://bugs.launchpad.net/ubuntu-rtm/+source/location-service/+bug/1480877/comments/68
[19:54] <awe> this doesn't include all system processes, but it mentions the ones that show up in my dbus scans
[20:01] <lpotter> cleanup code rely's on Qt's own object clean up. but if that is delayed due to parent not getting deleted for long time I can see thats a problem. with app armor on top those signals wont get disconnected straight away.
[20:02] <awe> so again... this is only when used from unity8 directly, which should be totally unconfined
[20:02] <lpotter> hmm maybe QDBus does things differently
[20:02] <awe> I'm assuming if the layer can add dbus signal match rules
[20:02] <awe> it can remove them
[20:02] <awe> if it can't
[20:02] <awe> it's badly broken
[20:02] <awe> I see the correct calls happening in the networkmanager plugin
[20:03] <awe> it's just that qtdbus doesn't seem to be removing the rules
[20:03] <awe> it looks like the rules are ref counted
[20:03] <awe> so someone's holding on to a ref somewhere
[20:03] <awe> I'm rebuilding with a bit more debugging added to qtdbus
[20:33] <lpotter> I think the logic in QNetworkManagerEngine::removeAccessPoint is wrong. Are you seeing the QNetworkManagerInterfaceAccessPoint d'tor getting called?
[20:37] <awe> yes
[20:37] <awe> Also, I enabled QDDBUS_DEBUG=1
[20:37] <awe> before starting  Unity
[20:38] <awe> I see a log message that tells me the DBusConnection.disconnect() function succeeded
[20:38] <lpotter> it looks like when an AP is known to the system, the accessPoint object will not get deleted when it is removed
[20:38] <awe> but what I don't see is a corresponding "Removing match rule..." from QDBusConnectionPrivate
[20:38] <awe> it looks like the intention is to reference count them
[20:38] <awe> and remove if/when someone calls disconnect()
[20:39] <awe> and the ref-count == 1
[20:39] <awe> the code in 5.4.1, doesn't explicitly disconnect in that destructor
[20:39] <awe> bottom line is NM is continually adding and removing AccessPoint objects
[20:40] <awe> so the plugin needs to track them, and adjust it's match rules on the fly
[20:40] <awe> otherwise we swamp the dbus daemon
[20:40] <awe> as the plugin just continues to add match rules till WiFi is disabled, or the phone dies and/or reboots
[20:40] <lpotter> I assumed that those got disconnected when it gets desctructed
[20:41] <awe> when what gets destructed? the AccessPoint object?
[20:41] <lpotter> yes. internally to QDbus
[20:41] <awe> I looked at the doc for DBusConnection and it doesn't mention auto-disconnect for signals anywhere
[20:42] <awe> well.. it's not working automatically, and it's not working if I try to explicitly disconnect either
[20:42] <awe> ;(-
[20:43] <lpotter> there is also a problem if two AP's have the same ssid
[20:43] <awe> also, I wrote a small QtCoreApplication and played around with connect/disconnect
[20:44] <awe> and was able to properly add a match rule for the same AP
[20:44] <awe> and then remove it by calling disconnect
[20:44] <awe> so the DBus code works
[20:44] <lpotter> so the engine is holding on to an object :)
[20:44] <awe> lpotter, yea... as previously discussed this is all no-op code
[20:45] <awe> thanks for all your thoughts on this
[20:45] <awe> I'll know more if my build ever finishes
[20:46] <awe> by the way, I diffed our code to 5.5.1 and 5.6
[20:46] <lpotter> I usually try to build only QNetwork library or plugin
[20:46] <awe> and there's very little different in qnetworkmanagerservice/enginer
[20:46] <lpotter> ok
[20:46]  * lpotter wonders where that repo is
[20:46] <awe> however there's quite a bit different in qdbusintegrator.cpp
[20:46] <awe> lpotter, the ubuntu repo?
[20:47] <lpotter> yes, with the newer plugin
[20:48] <awe> well, from what I can tell... our version of Qt isn't that different than the Debian package ( at least that's what it looks like from the debian/changelog )
[20:48] <lpotter> there doesnt seem to be one master-of-all
[20:48] <awe> I'm not sure it was worth us importing into a VCS
[20:48] <awe> but Mirv_ would know better than I
[20:49] <awe> again, I just grabbed the source package from the phone overlay PPA, and extracted it locally.  Some I working with quilt
[20:49] <awe> the base is 5.4.1+dfsg-2
[20:50] <awe> with the "dfsg-2" being what appears to be the Debian version
[20:50] <awe> I've got the upstream git5 repo cloned though, so that's what I'm using for comparison against our source package
[20:56] <lpotter> it's nearing chaos hour where kids wake up and go to school...
[20:56] <stgraber> awe: +dfsg means that the source tarball was repacked by the Debian maintainer to conform to the Debian Free Software Guidelines, so you'll probably be getting a fair amount of diff compared to upstream just for that
[20:57] <stgraber> awe: there typically is documentation as to how the dfsg tarball was generated in debian/ either in a README or as code in debian/rules
[20:57] <awe> stgraber, thanks!
[20:57] <lpotter> not sure I know how to grab the phone overlay PPA
[21:00] <awe> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
[21:01] <lpotter> thanks
[21:01] <awe> you can download the orig tarball, debian diff, and dsc files, and reconstruct with dpkg-source
[21:57] <tsg> micahg: thanks - will resubmit using requestbackport - thanks for your attention!


[00:51] -queuebot:#ubuntu-release- New binary: vtk7 [i386] (focal-proposed/universe) [7.1.1+dfsg2-1] (kubuntu)
[01:03] -queuebot:#ubuntu-release- New binary: vtk7 [amd64] (focal-proposed/universe) [7.1.1+dfsg2-1] (kubuntu)
[01:24] -queuebot:#ubuntu-release- New binary: vtk7 [s390x] (focal-proposed/universe) [7.1.1+dfsg2-1] (kubuntu)
[01:54] -queuebot:#ubuntu-release- New binary: vtk7 [ppc64el] (focal-proposed/universe) [7.1.1+dfsg2-1] (kubuntu)
[03:44] -queuebot:#ubuntu-release- New binary: vtk7 [armhf] (focal-proposed/universe) [7.1.1+dfsg2-1] (kubuntu)
[04:45] -queuebot:#ubuntu-release- New binary: vtk7 [arm64] (focal-proposed/universe) [7.1.1+dfsg2-1] (kubuntu)
[04:45] <RikMills> vorlon: might you consider removing the release versions of qgis and openorienteering-mapper for now to move the Qt transition along? 1st only has reverse recommends while the 2nd nothing
[04:46] <RikMills> I think the proj/rbase brokenness might take some time
[05:15] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.3-1 => 1.3.3-1] (core)
[05:15] -queuebot:#ubuntu-release- New binary: gmt [amd64] (focal-proposed/universe) [6.0.0+dfsg-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: gmt [s390x] (focal-proposed/universe) [6.0.0+dfsg-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: golang-github-containers-storage [s390x] (focal-proposed/universe) [1.13.2+dfsg1-2] (no packageset)
[05:16] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.3-1 => 1.3.3-1] (core)
[05:16] -queuebot:#ubuntu-release- New binary: gmt [i386] (focal-proposed/universe) [6.0.0+dfsg-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: golang-github-containers-storage [i386] (focal-proposed/universe) [1.13.2+dfsg1-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: gmt [ppc64el] (focal-proposed/universe) [6.0.0+dfsg-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: golang-github-containers-storage [ppc64el] (focal-proposed/universe) [1.13.2+dfsg1-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: golang-github-containers-storage [amd64] (focal-proposed/universe) [1.13.2+dfsg1-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: golang-github-containers-storage [arm64] (focal-proposed/universe) [1.13.2+dfsg1-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: golang-github-containers-storage [armhf] (focal-proposed/universe) [1.13.2+dfsg1-2] (no packageset)
[05:20] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.3-1 => 1.3.3-1] (core)
[05:20] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.3-1 => 1.3.3-1] (core)
[05:20] -queuebot:#ubuntu-release- New: accepted gmt [amd64] (focal-proposed) [6.0.0+dfsg-1]
[05:20] -queuebot:#ubuntu-release- New: accepted gmt [ppc64el] (focal-proposed) [6.0.0+dfsg-1]
[05:20] -queuebot:#ubuntu-release- New: accepted golang-github-containers-storage [amd64] (focal-proposed) [1.13.2+dfsg1-2]
[05:20] -queuebot:#ubuntu-release- New: accepted golang-github-containers-storage [armhf] (focal-proposed) [1.13.2+dfsg1-2]
[05:20] -queuebot:#ubuntu-release- New: accepted golang-github-containers-storage [ppc64el] (focal-proposed) [1.13.2+dfsg1-2]
[05:20] -queuebot:#ubuntu-release- New binary: gmt [armhf] (focal-proposed/universe) [6.0.0+dfsg-1] (no packageset)
[05:20] -queuebot:#ubuntu-release- New: accepted gmt [i386] (focal-proposed) [6.0.0+dfsg-1]
[05:20] -queuebot:#ubuntu-release- New: accepted golang-github-containers-storage [arm64] (focal-proposed) [1.13.2+dfsg1-2]
[05:20] -queuebot:#ubuntu-release- New: accepted golang-github-containers-storage [s390x] (focal-proposed) [1.13.2+dfsg1-2]
[05:20] -queuebot:#ubuntu-release- New: accepted gmt [s390x] (focal-proposed) [6.0.0+dfsg-1]
[05:20] -queuebot:#ubuntu-release- New: accepted golang-github-containers-storage [i386] (focal-proposed) [1.13.2+dfsg1-2]
[05:21] -queuebot:#ubuntu-release- New: accepted colored [amd64] (focal-proposed) [1.3.93-2]
[05:21] -queuebot:#ubuntu-release- New: accepted vtk7 [arm64] (focal-proposed) [7.1.1+dfsg2-1]
[05:21] -queuebot:#ubuntu-release- New: accepted vtk7 [i386] (focal-proposed) [7.1.1+dfsg2-1]
[05:21] -queuebot:#ubuntu-release- New: accepted vtk7 [s390x] (focal-proposed) [7.1.1+dfsg2-1]
[05:21] -queuebot:#ubuntu-release- New: accepted vtk7 [amd64] (focal-proposed) [7.1.1+dfsg2-1]
[05:21] -queuebot:#ubuntu-release- New: accepted vtk7 [ppc64el] (focal-proposed) [7.1.1+dfsg2-1]
[05:21] -queuebot:#ubuntu-release- New: accepted vtk7 [armhf] (focal-proposed) [7.1.1+dfsg2-1]
[05:22] -queuebot:#ubuntu-release- New binary: gmt [arm64] (focal-proposed/universe) [6.0.0+dfsg-1] (no packageset)
[06:14] -queuebot:#ubuntu-release- New binary: golang-github-openshift-imagebuilder [amd64] (focal-proposed/universe) [1.1.0-2] (no packageset)
[06:14] -queuebot:#ubuntu-release- New binary: golang-github-openshift-imagebuilder [i386] (focal-proposed/universe) [1.1.0-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: golang-github-containers-image [amd64] (focal-proposed/universe) [4.0.1-1] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: golang-github-openshift-imagebuilder [s390x] (focal-proposed/universe) [1.1.0-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: golang-github-openshift-imagebuilder [ppc64el] (focal-proposed/universe) [1.1.0-2] (no packageset)
[06:17] -queuebot:#ubuntu-release- New binary: golang-github-openshift-imagebuilder [arm64] (focal-proposed/universe) [1.1.0-2] (no packageset)
[06:17] -queuebot:#ubuntu-release- New binary: golang-github-openshift-imagebuilder [armhf] (focal-proposed/universe) [1.1.0-2] (no packageset)
[07:04] -queuebot:#ubuntu-release- New: accepted golang-github-containers-image [amd64] (focal-proposed) [4.0.1-1]
[07:04] -queuebot:#ubuntu-release- New: accepted golang-github-openshift-imagebuilder [armhf] (focal-proposed) [1.1.0-2]
[07:04] -queuebot:#ubuntu-release- New: accepted golang-github-openshift-imagebuilder [ppc64el] (focal-proposed) [1.1.0-2]
[07:04] -queuebot:#ubuntu-release- New: accepted golang-github-openshift-imagebuilder [arm64] (focal-proposed) [1.1.0-2]
[07:04] -queuebot:#ubuntu-release- New: accepted golang-github-openshift-imagebuilder [s390x] (focal-proposed) [1.1.0-2]
[07:04] -queuebot:#ubuntu-release- New: accepted golang-github-openshift-imagebuilder [i386] (focal-proposed) [1.1.0-2]
[07:04] -queuebot:#ubuntu-release- New: accepted gmt [arm64] (focal-proposed) [6.0.0+dfsg-1]
[07:04] -queuebot:#ubuntu-release- New: accepted golang-github-openshift-imagebuilder [amd64] (focal-proposed) [1.1.0-2]
[07:04] -queuebot:#ubuntu-release- New: accepted gmt [armhf] (focal-proposed) [6.0.0+dfsg-1]
[09:07] -queuebot:#ubuntu-release- New source: golang-1.13-race-detector-runtime (focal-proposed/primary) [0.0+svn332029-0ubuntu2]
[09:10] <LocutusOfBorg> please reject this one and consider the second version
[09:10] <LocutusOfBorg> (I added some more changelog entries)
[09:10] <LocutusOfBorg> mwhudson, ^^ FYI
[09:10] -queuebot:#ubuntu-release- New source: golang-1.13-race-detector-runtime (focal-proposed/primary) [0.0+svn332029-0ubuntu2]
[09:35] -queuebot:#ubuntu-release- New binary: cu2qu [amd64] (focal-proposed/universe) [1.6.6-4ubuntu1] (no packageset)
[10:10] -queuebot:#ubuntu-release- New: accepted cu2qu [amd64] (focal-proposed) [1.6.6-4ubuntu1]
[10:11] -queuebot:#ubuntu-release- New: rejected golang-1.13-race-detector-runtime [source] (focal-proposed) [0.0+svn332029-0ubuntu2]
[10:11] -queuebot:#ubuntu-release- New: accepted golang-1.13-race-detector-runtime [source] (focal-proposed) [0.0+svn332029-0ubuntu2]
[10:14] -queuebot:#ubuntu-release- New binary: golang-1.13-race-detector-runtime [amd64] (focal-proposed/none) [0.0+svn332029-0ubuntu2] (no packageset)
[10:15] -queuebot:#ubuntu-release- New: accepted golang-1.13-race-detector-runtime [amd64] (focal-proposed) [0.0+svn332029-0ubuntu2]
[12:32] -queuebot:#ubuntu-release- New binary: embree [amd64] (focal-proposed/universe) [3.6.1+dfsg-1ubuntu1] (no packageset)
[13:02] -queuebot:#ubuntu-release- New: accepted embree [amd64] (focal-proposed) [3.6.1+dfsg-1ubuntu1]
[17:14] -queuebot:#ubuntu-release- New binary: rust-combine [amd64] (focal-proposed/universe) [3.8.1-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: rust-combine [s390x] (focal-proposed/universe) [3.8.1-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: rust-combine [i386] (focal-proposed/universe) [3.8.1-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: rust-combine [ppc64el] (focal-proposed/universe) [3.8.1-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: rust-combine [arm64] (focal-proposed/universe) [3.8.1-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: rust-combine [armhf] (focal-proposed/universe) [3.8.1-1] (no packageset)
[18:24] -queuebot:#ubuntu-release- New: accepted rust-combine [arm64] (focal-proposed) [3.8.1-1]
[18:24] -queuebot:#ubuntu-release- New: accepted rust-combine [i386] (focal-proposed) [3.8.1-1]
[18:24] -queuebot:#ubuntu-release- New: accepted rust-combine [armhf] (focal-proposed) [3.8.1-1]
[18:24] -queuebot:#ubuntu-release- New: accepted rust-combine [ppc64el] (focal-proposed) [3.8.1-1]
[18:24] <vorlon> ginggs: hi, what's the rationale for relaxing the test precision on ppc64el for statsmodels?  why has the precision regressed, and why in a math package are we not concerned about this?
[18:24] -queuebot:#ubuntu-release- New: accepted rust-combine [amd64] (focal-proposed) [3.8.1-1]
[18:24] -queuebot:#ubuntu-release- New: accepted rust-combine [s390x] (focal-proposed) [3.8.1-1]
[18:33] <ginggs> vorlon: it seems 0.9.0 has always ftbfs on ppc64el in ubuntu
[18:34] <ginggs> the difference was very small, so i looked at the history of that file and saw they had tweaked those tolerances a few times
[18:36] <ginggs> i opened an issue upstream, and the response was "relaxing precision is fine, those are tight"
[19:03] <vorlon> ginggs: ok, ta
[19:04] <ginggs> vorlon: yw!
[20:05] <RikMills> vorlon: do you have an opinion on my last comment on the Qt transition?
[20:06] <RikMills> may be a bit soon for those measures, but then again 3 flavours have iso build fails due to this holding back
[20:06] <RikMills> granted that there is not huge stuff new in the isos
[20:07] <RikMills> well. kubuntu has a new destop shell version being held back
[23:37] <vorlon> RikMills: seems like a sensible recommendation, I need to take a look and confirm the details
[23:41] <vorlon> RikMills: done now


[17:49] <housecat> ^ looking into this, will reply in a bit, waiting for input from someone
[18:27] <housecat> ubottu: !-ubuntu+1
[18:27] <housecat> ubottu: !ubuntu+1
[18:28] <housecat> ubottu: !+ubuntu+1
 $curDevelLong is the codename for Ubuntu $curDevelNum - Support only in #ubuntu+1
[18:29] <housecat> ubottu: no, ubuntu+1 is <reply> $curDevelLong is the codename for Ubuntu $curDevelNum. For technical support, see #ubuntu+1. For testing and QA feedback and help, see #ubuntu-quality.
[18:33] <hggdh> housecat: thank you


[04:49] <zul> @schedule now
[06:14] <calc> doko: did you mean there is a current thread on dev@go-oo about modularization?
[06:51] <ogra> *yawn*
[06:52] <zul> evening
[06:53] <ArneGoetje> hi
[06:53] <TheMuso> Greetings.
[06:53] <calc> here
[06:53] <asac> hi all
[06:54] <bryce> heya
[06:55] <kirkland> howdy
[06:55] <cjwatson> guten Morgen
[06:55] <dholbach> hiya :)
[06:55] <bdmurray> hello
[06:57] <evand> hi
[06:58] <james_w> hi all
[06:59] <pitti> Good morning
[07:01] <cjwatson> Hi all; welcome to those of you visiting for 8.04.1 discussions
[07:01] <pitti> hardy is our rock!
[07:02] <cjwatson> As I mentioned by mail, the main thing I want to go through in this platform meeting is 8.04.1, though I have other odds and ends for afterwards
[07:02] <ogra> cjwatson, i just sent you another agenda item
[07:03] <doko> good morning
[07:03] <cjwatson> Most of you will already know that we're assigning more resources than usual to the point release this time round, and this will consist of a virtual team of about ten people under the direction of slangasek
[07:04] <cjwatson> Steve was on well-deserved holiday yesterday after the 8.04 release, so I don't know if he's had a chance to catch up and figure out what's going on with stable yet :-)
[07:04] <pitti> ah, that was in fact one of my main pressing questions: slangasek is now officially part of the SRU team, so I can bother him to review my own SRU uploads?
[07:05] <cjwatson> From platform, so far, evand and about half of asac will be on the 8.04.1 team; I'm still sniffing around for one more
[07:05] <slangasek> I've managed to process my mail with difficulty today - looks like there are one or two bugs to keep us busy for the point release
[07:05] <StevenK> Heh, "half of asac"
[07:05] <pitti> from desktop, it's seb128 and me (so far)
[07:05] <ogra> no half people there ?
[07:05] <slangasek> pitti: my understanding is that I'm to be officially part of the SRU team, but I'm not a member of the launchpad team yet
[07:05] <zul> from the server team its me and half of kirkland
[07:06] <pitti> slangasek: I don't think the team comes with any extra power, it's just the bug mail I think
[07:06]  * cjwatson looks at https://launchpad.net/ubuntu/+milestone/ubuntu-8.04.1 - "144 bugs targeted"
[07:06] <seb128> hi
[07:06] <pitti> slangasek: but someone should add you indeed
[07:06] <cjwatson> slangasek: *clicketyclick* fixed
[07:06]  * calc will be putting out a new OOo, but probably not working on other stuff unless asked
[07:06] <slangasek> cjwatson: thanks :)
[07:07] <cjwatson> Firefox 3's non-final state is one of the things I've seen in pretty much every 8.04 review so far, hence asac
[07:07] <cjwatson> (and we knew it was going to be that way, of course)
[07:07]  * slangasek nods
[07:07] <ogra> yeah, there are also massive threads about it on ubuntu-users
[07:08] <ogra> seems some people have problems running 2 and 3 in parallel
[07:08] <cjwatson> The target for package uploads being complete for 8.04.1 is about the first week of June, with the release itself then being early July, so plenty of time for testing and certification
[07:08] <asac> ogra: nobody claimed that thats really supported ;)
[07:08] <cjwatson> Are there any major issues people would like to raise that they think ought to be hoovered up for 8.04.1?
[07:09] <ogra> asac, right and -users is a madhouse anyway
[07:09] <pitti> cjwatson: do you know whether we'll get any list of 'hardware that should work with .1' again?
[07:09] <ogra> cjwatson, sound support
[07:09] <lool> It's not a major issue, but I need to mention the UME situation
[07:09] <slangasek> I think all the major issues I would raise are conveniently already milestoned ;)
[07:09] <pitti> pulseaudio's stuttering is driving me crazy, but it might just be me
[07:09] <slangasek> sound support is a big one that needs some attention
[07:09] <cjwatson> lool: that is on my list, I'll get to it in a moment
[07:09] <seb128> cjwatson: gvfs smb issues
[07:09] <lool> perfect, thanks
[07:10] <ogra> pitti, since crimsun dropped the ball we're pretty much floating wrt sound
[07:10] <cjwatson> pitti: I'm not sure, I'll check
[07:10] <zul> cjwatson: onn the server side we have a list of things we would like to see fixed or tweaked
[07:10] <slangasek> the new kernel scheduler works for most cases, but in the cases where it doesn't it really doesn't - I think the kernel team already has that in 'fix committed' now
[07:10] <ogra> nobody is *really deep* into it atm
[07:10] <TheMuso> Crimsun and I are looking at putting pulseaudio through dmix at this point, and testing is giving different results for different people from what I can gather.
[07:10] <lool> slangasek: Is that the commit in 2.6.25 by Ingo?
[07:10] <cjwatson> slangasek: cgroups?
[07:11] <ogra> TheMuso, do you know what redhat are doing wrt the pulse setup ?
[07:11] <slangasek> zul: can you please let me know if there are any of those bugs which aren't a subset of the 8.04.1 milestoned set?
[07:11] <slangasek> cjwatson: yes
[07:11] <slangasek> lool: no
[07:11] <cjwatson> seb128: that's bug 207072?
[07:11] <zul> slangasek: sure I can cross reference it
[07:11] <TheMuso> ogra: Using direct hardware access afaik. I plan on installing FC9 to have a closer look.
[07:11] <ogra> cool
[07:11] <pitti> one highly annoying thing is that gnome-screensaver doesn't accept your password after resuming; not sure if that's already milestoned
[07:11] <slangasek> I need to fix my own brown paper bag regarding pam logging :P
[07:12] <slangasek> pitti: hrm?  I haven't seen this at all
[07:12] <lool> Me neither
[07:12] <TheMuso> ogra: Not even sure what Fedora users do about flash and pulse, but I guess we won't really know till FC9 final is out.
[07:12] <ogra> pitti, i heard about keyboard issues after resume, that might be related
[07:12] <seb128> cjwatson: bug #209520 bug #223372 bug #207072
[07:12] <bryce> I've been looking at doing some quirk and pci id updates for various X drivers, and I think we might have a few more fixes for xrandr gui from redhat and suse that could be worth pulling in
[07:12] <pitti> slangasek: hm, happens on both my boxes (freshly installed final), so I didn't think it was a local glitch
[07:13] <seb128> right, fixing the xrandr capplet would be nice too, because I'm not sure it works for lot of people right now
[07:13] <pitti> anyway, it's on my list to track this down
[07:13] <ogra> TheMuso, they go for libflashsupport
[07:13] <slangasek> pitti: ok, please keep me informed; I would have expected a bug like that to have come to my attention by now if it were widespread, but even if it's not that sounds like a fairly important issue to try to pin down
[07:14] <TheMuso> ogra: Yeah so I guess ti comes down to how pulse/flashsupport behave for Fedora users.
[07:14] <pitti> slangasek: ok, I'll first get it filed, I think :)
[07:14] <ogra> TheMuso, but use nspluginwrapper all over the place, so it doesnt crash their browser
[07:14] <ogra> (people will just reload the page)
[07:14] <bryce> seb128: cloned (e.g. projector) should be fine for most people; dual-head layouts still needs work.  Not sure we're going to get that 100% though, but could be polished better.
[07:15] <seb128> bryce: ok, I might just have no luck with my setup then
[07:15] <slangasek> bryce: one of the reviews of hardy mentioned that the xrandr gui doesn't resize if you use it to scale the screen down to a size smaller than the window, making it difficult to make further changes; do you know if there's a bug about this?
[07:15] <cjwatson> I've asked TheMuso to be the third platform guy for .1, so hopefully he can spend some time smoothing out sound
[07:15] <calc> yea i saw that for low resolution displays
[07:15] <ogra> bryce, what about single head layouts that detect a tv or external VGA ? seems the external is always on (whch forces a floating gdm of 1024x768 on a 1280x800 screen here for me)
[07:16] <seb128> slangasek: there is a bug yes, I've been commenting on yet yesterday, no obvious way to solve the "dialog don't fit on 800x600 issues"
[07:16] <slangasek> seb128: well, there's a very large graphic that ought to be scalable downwards, in principle :)
[07:16] <bryce> slangasek: right, we actually did get it to fit in that resolution, but a button got added in at the last moment that bumped us up just enough.  That was a pretty non-standard resolution (740x400 iirc) so I don't know if it's worth SRUing, but I talked about it with james.
[07:16] <cjwatson> so I make the .1 team as follows: slangasek, asac, evand, TheMuso, pitti, seb128, bdmurray, ogasawara__, pedro, kirkland, zul
[07:16] <james_w> I thought it was ok in 800x600, it was just x400 that didn't work.
[07:16] <ogra> bryce, i ave seen that on different machines now, switching the external output off via xrandr fixes it though
[07:16] <ArneGoetje> can we put #215755 on the .1 list, please?
[07:17] <bryce> I think we should re-test on 640x480 though.  I *think* it should still fit ok, but if not maybe we should just shift where the button is located
[07:17] <TheMuso> When is Fedora 9 due?
[07:18] <seb128> james_w: might be, I use 800x600 as value we get bugs about app not fiting correctly on that usually
[07:18] <cjwatson> ArneGoetje: I've milestoned it speculatively, though it's outside the usual SRU criteria; I can see why it would be needed though
[07:18] <ogra> TheMuso, may 15th i think
[07:18] <asac> TheMuso: iirc 13th may
[07:18] <ArneGoetje> cjwatson: thanks
[07:18] <asac> ok ;)
[07:18] <ogra> or what asac says :)
[07:18] <calc> 14 days apparently
[07:18] <calc> whenever that is :)
[07:18] <TheMuso> Ok thanks.
[07:18] <bryce> ogra: the TV out interference bugs are usually easily quirkable; pass me bug ids and they should be easy to do that way
[07:18] <calc> yea may 13
[07:18] <cjwatson> lool mentioned mobile as an issue, and this was also on my list
[07:18] <slangasek> bryce: ah, right, I can't see much reason to worry about resolutions below 640x480; but then, the GUI should therefore probably not /expose/ resolutions lower than that if it's going to break the GUI itself :)
[07:19] <cjwatson> the mobile team is going to be releasing their hardy-based product somewhat later than hardy itself; looking at late May at the moment, I understand
[07:19] <lool> Yes
[07:19] <lool> We need to provide security support on it, and it's currently based on hardy + ume ppa
[07:19] <ogra> bryce, will do ... i added "/usr/bin/xrandr --output TV --off" to a gdm Init file for now, works around it as well :)
[07:19] <seb128> slangasek: note that you have to confirm the choice, so people shooting themself in the foot are really asking for it there
[07:19] <cjwatson> and they have raised it as an issue that their process is very complicated at the moment, involving PPAs and other weirdness all over the show
[07:20] <cjwatson> I'd like the .1 team to consider whether parts of this can be incorporated in the updates for .1
[07:20] <lool> To be in the sweet spot of maintainability, we would be happy with having everything in hardy, but some of our changes remain ppa only at the moment
[07:20] <cjwatson> perhaps at least those packages currently in the ume ppa that are also important in the regular archive
[07:20] <calc> apparently opensuse will have pulseaudio as well but isn't slated for release until mid june
[07:20] <cjwatson> I think there may be cases where a merge into the main archive just isn't appropriate yet
[07:21] <TheMuso> calc: Ok another one I need to check out, thanks.,
[07:21] <lool> That's true, it's certainly hard to reconcile the proposed changes with SRU requirements
[07:21] <lool> The changes might be lpia specific
[07:21] <calc> TheMuso: http://en.opensuse.org/Roadmap
[07:21] <lool> Or might be in purely mobile packages
[07:21] <TheMuso> calc: ok thanks again.
[07:22] <slangasek> right, I was about to say, if UME is still in the development run-up to a release, there are likely to be changes that don't really fit the SRU policy
[07:22] <lool> I think these are not disruptive to the normal behavior of hardy, but they do not fit in the allowed updates scenarii
[07:22] <cjwatson> at the very least, it'd make sense to consider cases where packages are being updated anyway
[07:22] <cjwatson> if changes are lpia-specific, the major risk is from changing the package *at all*, not so much from the diff itself
[07:22] <slangasek> and navigating the SRU requirements might be more of a hassle than using the PPA
[07:22] <cjwatson> IYSWIM
[07:22]  * slangasek nods
[07:23] <lool> I was hoping that some easy changes would be mergeable as trivial mobile bug fixes, but it's going to be administrativa for sure
[07:23] <lool> One issue with the SRU process is that it needs the reviewer to be able to test the package
[07:24] <cjwatson> lool: perhaps somebody could correlate the list of changes you have against the 8.04.1 milestone, and look for things that could slot in
[07:24] <lool> But with UME, we don't have a completely virtual solution (yet) and the Xephyr solution is a pain to setup
[07:24] <cjwatson> is there wiki documentation on the setup?
[07:24] <cjwatson> at least then it could be done if need be ...
[07:24] <pitti> lool: but there should be at least one other person with that hw in the team?
[07:24] <asac> me
[07:25] <StevenK> Bryce, too
[07:25] <lool> cjwatson: Ok; we didn't use the milestone too much yet; what needs to be done is to look one by one at the packages we carry in the ppa and see whether the changes can be merged into hardy
[07:25] <pitti> lool: traditionally, hw specific bugs are verified by the bug reporter/subscribers, and we collect a few of them
[07:25] <slangasek> lool: the SRU process doesn't require the reviewer to be on the sru team or an archive admin, though?  so presumably you'd have people within your own team who could do the validation
[07:25] <lool> pitti: Yes
[07:25] <cjwatson> lool: right, I mean packages that are already going to be updated for .1 for other (non-mobile) reasons
[07:26] <lool> Sure, we could do it within UME; I thought the sru team or archive admins had to be able to check, but UME testing is fine
[07:26] <pitti> TBH, that makes even more sense than ~sru-verification, since they just test a particular TEST CASE:, and not the entire package in production conditions)
[07:26] <lool> cjwatson: Yup, I understood
[07:26] <cjwatson> ok, further .1 meetings
[07:26] <lool> cjwatson: So should we check -proposed regularly to see whether a package is different in -updates and hardy?
[07:27] <cjwatson> it seems like it'll be valuable for the .1 team to occasionally sync up, but you're in the usual variety of timezones
[07:27] <cjwatson> one suggestion was to have shift meetings, so that at least there's some coordination even if it isn't whole-team
[07:27] <cjwatson> slangasek: but I'll leave you to carry this forward
[07:28] <cjwatson> lool: I think you guys may be too busy to poll; perhaps you can arrange some kind of notification system
[07:28] <lool> Are -proposed uploads sent to some -changes list?
[07:29]  * ogra thinks it should be responsibility of the uploader to take care
[07:29] <ogra> (for notification that is)
[07:29] <lool> I see them in hardy-changes I think
[07:29] <slangasek> cjwatson: hmm, do we have any scheduling tools available internally to make this easier? :)
[07:29] <lool> I guess I'll tell people to subscribe with a filter to that list so that they can see likely SRU candidates
[07:29] <slangasek> ogra: the uploader won't necessarily know that the UME team cares about the package in question
[07:30] <ogra> lool, but they might have to sit in -proposed for weeks
[07:30] <cjwatson> lool: hardy-changes, yes
[07:30] <ogra> sladen, oh, right
[07:30] <pitti> lool: yes, they go to -changes normally
[07:30] <ogra> err s/sladen/slangasek, sorry
[07:30] <cjwatson> slangasek: not a lot, unfortunately; when I've done it I drew out a big list of timezones and people so that I could do it by eye
[07:30] <lool> Ok
[07:31] <StevenK> slangasek: I'd suggest you ask davidm too, since we have this issue with the mobile team
[07:32] <slangasek> StevenK: thanks, I'll ask him
[07:32] <lool> Where will the 8.04.1 sync meetings be announced?
[07:32] <slangasek> I'll make sure they get on the fridge
[07:33] <lool> Thanks
[07:34] <lool> Just in case, it might be best to include me in the list of 8.04.1 people if that's the base for an email group or something
[07:34] <cjwatson> so on second thoughts, the other agenda item I had was just for one person, so I won't bore the whole team with it
[07:34] <cjwatson> any other business?
[07:34] <slangasek> lool: I'm happy to do that to keep you in the loop
[07:34] <lool> Thanks
[07:34] <bryce> thanks
[07:35] <lool> cjwatson: thanks for the meeting!  have a nice day
[07:35] <kirkland> cool, g'night!
[07:35] <asac> thanks
[07:35] <evand> thanks
[07:35] <pitti> thanks everyone
[07:35] <TheMuso> Thanks folks.
[07:35] <ogra> thanks
[07:36] <seb128> thanks guys
[07:36] <StevenK> thanks guys
[07:36] <james_w> thanks all
[07:36] <slangasek> thanks (i.e., "no other business" :)
[07:36] <ArneGoetje> thanks
[07:37] <cjwatson> ok then, adjourned; thanks all, good luck with .1!
[17:13] <emgent> @schedule rome
[17:13] <emgent> argh ubot..
[19:57] <stgraber> hey heno
[19:57]  * ogasawara__ waves
[19:58] <heno> hey all
[19:58] <pedro_> hello!
[19:58] <bdmurray> hi
[19:59] <davmor2> hello
[20:00] <heno> #startmeeting
[20:00] <heno> meh, no bot
[20:00] <heno> ok, agenda at https://wiki.ubuntu.com/QATeam/Meetings
[20:01] <heno> TOPIC - Setting up virtual images of standard upstream software for upstream bug testing
[20:01] <heno> I played a bit with this yesterday in vbox
[20:02] <heno> basically installed Debian testing
[20:02] <heno> anyone know how much debian changs Gnome and OOo?
[20:02] <heno> they obviously rebrand firefox
[20:03] <stgraber> I don't think they patch gnome a lot, you probably can take a quick look at their .diff.gz though
[20:03] <heno> the idea here is to make it easy to teat whether a bug exists upstream
[20:03] <pedro_> there's no a good way to determine that i think
[20:03] <pedro_> that's why i prefer to use jhbuild of trunk instead
[20:04] <heno> So: is offering Debian unstable images a good enough way to do this or should it be pure upstream?
[20:05] <heno> latest head builds
[20:05] <Crazyguy> if possible, latest gnome build definitely
[20:05] <bdmurray> I think pure upstream for OOo, firefox, and Gnome.  Having a debian image would be good for a lot of bugs though.
[20:06] <pedro_> yep it would be good for all the other software we have
[20:06] <davmor2> I think if you asking general public to test in vm then debian unstable is probably a good call
[20:06] <heno> firefox and OOo are fairly easy to install from upstream binaries I guess, what about Gnome?
[20:06] <pedro_> ouch
[20:06] <heno> heh
[20:07] <pedro_> is a bit complicated but not a lot
[20:07] <pedro_> and it will use a lot of space
[20:07] <RoAkSoAx> @schedule
[20:07] <heno> ok, so perhaps we can start with Debian unstable and see if we run into issues of it not being pure upstream enough
[20:08] <pedro_> ~750 only of source code
[20:08] <pedro_> ok
[20:09] <heno> It would be great if someone could take this on, but we'll get to that on agenda item 3
[20:09] <heno> TOPIC - Creating a test-control team to lead various test efforts with similar privileges as bug-control
[20:09] <pedro_> btw does debian have something like patches.ubuntu.com?
[20:10] <heno> This would include people who can admin the test tracker, who generally edit test cases, etc.
[20:11] <heno> perhaps also set priority of bugs
[20:11] <heno> it would be a restricted team like bug-control
[20:11] <heno> pedro_: don't know
[20:12] <heno> there is the ubuntu->debian project, utnubu or something
[20:12] <pedro_> ok will try to see what can i find out there, thanks
[20:13] <heno> thoughts on test-control? do we need this? will it be useful?
[20:13] <ogasawara> heno: is there a list of initial members for the test-control team that don't already have the above mentioned privileges?
[20:14] <heno> davmor2: are you in bug-control?
[20:14] <davmor2> No bug-squad
[20:14] <heno> there are the Xubuntu and Studio test people also
[20:15] <bdmurray> the test cases are just in the wiki though at the moment right?
[20:15] <heno> it's also a way to encourage people to do ore structured testing
[20:15] <cgregan> I think a defined group to manage these type of actions is a good idea. Especially as we grow. That being said, it would have to be managed so it did not become a bottleneck
[20:15] <stgraber> Won't that require to have that test-control team as a member of bug-control ?
[20:15] <heno> and learn more advanced techniques
[20:15] <heno> like setting up re-flashable disk images
[20:16] <heno> bdmurray: right, I'm not suggesting we limit access to editing them, just that it would be a typical task for team members
[20:17] <james_w> pedro_: no, they don't have patches.debian.org, but if they use a patch system patches.ubuntu.com can provide the individual patches in http://patches.ubuntu.com/by-release/extracted/debian/ which is probably quite useful for gnome
[20:17] <bdmurray> stgraber: for setting bug priority yes and I think the bug-control team requires some special knowledge that testers might not need
[20:17] <heno> stgraber: why, to set importance?
[20:17] <stgraber> heno: yep
[20:17] <pedro_> james_w: great, thanks!
[20:18] <bdmurray> I think setting bug importance could wait a while
[20:18] <heno> we can leave the right to set importance out, but it should be a restricted team
[20:19] <zul> @schedule montreal
[20:19] <stgraber> well, it has to be restricted, otherwise you are just describing our existing : "Ubuntu Testing Team" :)
[20:19] <stgraber> (that's currently AFAIK not used at all)
[20:19] <heno> the test tracker could get the info from LP in the future
[20:19] <heno> stgraber: right :)
[20:20] <heno> Sounds like we should define the purpose and scope a bit better before proceeding
[20:20] <stgraber> indeed
[20:20] <heno> I'll take it to the mailing list
[20:21] <heno> TOPIC - Additional QA team roles
[20:21] <davmor2> I think it is important for people to have a sense of motivation.  You see now across the whole spectrum of teams.  You get the base level team that anyone can join and then the elite who help the other and have more privileges
[20:21] <heno> see https://wiki.ubuntu.com/QATeam/Roles for my proposal
[20:21] <stgraber> I'm all for a restricted team showing that its members have been actively helping testing Ubuntu
[20:22] <stgraber> the "Ubuntu Testing Team" was useless mainly because it was opened to everyone and didn't give any additional privilege.
[20:23] <stgraber> davmor2: +1
[20:24] <heno> ok, so we are agreed on the principle, just need to settle the details :)
[20:24] <davmor2> :)
[20:24] <davmor2> sounds good :)
[20:24] <heno> davmor2's point is really also the motivation for the QA roles
[20:25] <heno> defining clear areas of responsibility that we ask people step up to
[20:25] <pedro_> mmm we need a KDE/Kubuntu guy
[20:25]  * pedro_ will ask yuriy about that
[20:25] <davmor2> heno: I think in the roles you missed asac for FF
[20:25] <stgraber> that Roles page looks really good, will be useful to redirect people asking who to contact regarding a specific area of QA
[20:26] <davmor2> Riddell
[20:26] <davmor2> he tends to sit in on the testing channel anyway
[20:26] <bdmurray> When I heard role I was thinking bug forwarder, bug triager, etc...
[20:26] <heno> I should link to the bug roles page - there is some overlap
[20:26] <stgraber> Installer bug contact would also be a good thing
[20:26] <stgraber> for debian-installer/ubiquity issues
[20:27] <heno> bdmurray: should we use a different term?
[20:27] <bdmurray> Nothing great comes to mind other than "lead"?
[20:27] <asac> i would love to give away the "mozilla bug role" to someone else who is more dedicated to bug work.
[20:27] <bdmurray> Well, that's not great
[20:27] <heno> I'm sure asac would love someone *else* to step up as FF QA lead :)
[20:27] <asac>  \o/
[20:27] <heno> ...
[20:28] <asac> i can provide the input and procedures, but doing the QA of my own stuff doesn't sound right
[20:28] <davmor2> stgraber: that would be evand
[20:28] <heno> davmor2: but as with asac he is the lead dev
[20:28] <heno> the QA lead should be a different person
[20:30] <heno> shall we decide on these one at a time and move them up to open positions/roles?
[20:30] <davmor2> Well myself evand and  xivulon (Agostino Russo) are all on pretty good terms, so I can probably take that on too.
[20:31] <heno> davmor2: ok, just note that we are trying to involve new people with this, so don't take them all :)
[20:31] <heno> So, in order:
[20:32] <heno> Kernel bug first-response
[20:32] <heno> ogasawara: please add whatever further role description is needed
[20:32] <ogasawara> sounds good to me :)  I'll beef up the description more
[20:32] <heno> the more detail about what it involves the better
[20:33]  * ogasawara nods
[20:33] <heno> * Test VM maintainer
[20:33] <heno> based on debian I think we decided
[20:34] <heno> I can flesh that one out
[20:34] <stgraber> what about some kind of Forum <-> QA team contact ?
[20:35] <heno> what would they do?
[20:36] <heno> sounds useful, but specifically
[20:36] <stgraber> make sure people reporting bugs or test results on the forums are either redirected to the proper ressource (Launchpad) or at least forward the bug/result to the right developper or open a report himself
[20:37] <heno> that sounds concrete enough
[20:37] <heno> and could request testing in the forum when needed
[20:37] <stgraber> yes, that too
[20:38] <heno> stgraber: will you flesh out the description for that?
[20:39] <heno> * Derivatives test coordinator (Xubuntu, Ubuntu Studio, etc.)
[20:39] <stgraber> sure
[20:39] <heno> perhaps we should hold off on the derivatives one as ISO testing season is now over
[20:40] <heno> we can't post them all at once anyway
[20:40] <stgraber> oh, about that, who's the project leader for Mythbuntu ?
[20:40] <heno> And let's add FF and perhaps OOo
[20:40] <stgraber> we don't have them on the tracker and I think it'd be a good idea to add them
[20:40] <bdmurray> asac: are getting Firefox 3.0 bugs upstream important now? and how time sensitive is it?
[20:40] <bdmurray> stgraber: superm1
[20:41] <stgraber> bdmurray: thanks, I'll ping him later
[20:41] <heno> the installer can perhaps wait as it's out of season now :)
[20:43] <heno> let's aim to have 2-3 of these posted before next week's meeting
[20:43] <heno> any other topics today?
[20:44] <stgraber> We can probably start with : test-vm, kernel bug and forum
[20:44] <stgraber> those aren't linked to ISO testing
[20:45] <stgraber> (not directly)
[20:45] <heno> ok
[20:45] <heno> 3
[20:46] <heno> 2
[20:46] <heno> 1
[20:46] <heno> #endmeeting
[20:46] <davmor2> still no bot :)
[20:46] <heno> Yeah, I'm still compelled to write that though :)
[20:47] <davmor2> :)
[20:47] <stgraber> yeah, 15min break before the next meeting :)
[20:52] <asac> bdmurray: sorry. have to run. we can talk about that tomorrow (well tomorrow is publich holiday here, so maybe friday)
[20:52] <bdmurray> asac: okay, you know where to find me.
[21:00]  * ogra jumps at the stage
[21:00] <ogra> anyone here ?
[21:01] <ogra> hmm
[21:01] <stgraber> yep
[21:02] <ogra> heh
[21:02] <ogra> so its you and me :)
[21:02] <stgraber> Laserjock was in #ubuntu-devel 3 minutes ago
[21:02] <ogra> lets wait another 5 min or so
[21:02] <ogra> yeah, saw him, but he said he has another meeting as well
[21:02] <stgraber> ah, right
[21:04] <ogra> so i''ll paste my list of proposed specs i would like to work on in intrepid, note that none of them are accepted or even put up on blueprints yet
[21:04] <ogra> colin has to nod off what i'm allowed to work on and we didnt have a meeting about it yet, so take that list with a grin of salt
[21:05] <LaserJock> it would be nice to have a set of community  goals as well, IMO
[21:05]  * ogra repeats for the recently joined
[21:05]  * nealmcb didn't know salt could grin, but likes the idea :-)
 so i''ll paste my list of proposed specs i would like to work on in intrepid, note that none of them are accepted or even put up on blueprints yet
 colin has to nod off what i'm allowed to work on and we didnt have a meeting about it yet, so take that list with a grin of salt
[21:06]  * ogra resisted the urge to fix the typo :)
[21:06] <ogra> * USB Key images by default (dd'able casper images for usb keys)
[21:06] <ogra> * WLAN Mesh networking support out of the box
[21:06] <ogra> * Easy touchscreen calibration
[21:06] <ogra> * Initramfs profiling by default
[21:06] <ogra> * Lightweight kernel flavor (core kernel flavour for minimal ram usage)
[21:06] <ogra> * edubuntu menu completion ui
[21:06] <ogra> * local content filter (finish willowng parental control, ufw integration)
[21:06] <ogra> * ltsp sound cleanup (adapt full pulseaudio support even for capturing)
[21:06] <ogra> * ltsp localapps (finish the proof of concept setup from gutsy)
[21:07] <ogra> for edubuntu mst intresting is the menu stuff and willowng finishing i guess
[21:07] <ogra> *most
[21:07] <stgraber> looks like a CMPC todolist if you remove the 2 ltsp items :)
[21:07] <ogra> willow and edubuntu-menus eare no cmpc items
[21:08] <ogra> and the others rather fall into general subnotebook and ressource reduction realm :)
[21:08] <ogra> i surely dont want to have another image like i have to maintain now for cmpc
[21:08] <ogra> they will stick on me eternally, i'd like to avoid that
[21:09] <ogra> LaserJock, so for the edubuntu-menu completion i thought about looking for a sceduling app as well to integrate with that
[21:09] <ogra> *scheduling
[21:10] <stgraber> 22:04 < LaserJock> yeah, I'm running to my advisor meeting
[21:10] <stgraber> 22:04 < LaserJock> I'll be back hopefully soon
[21:10] <stgraber> ogra: ^
[21:10] <ogra> well, willowng has lots of potential but misses the final bits
[21:10] <ogra> stgraber, yup, saw that
[21:10] <stgraber> ok
[21:11] <ogra> i'D also like to look into FF addons
[21:11] <ogra> for content stuff
[21:12] <stgraber> ok, from my side. My current planned changes for Intrepid are :
[21:12] <ogra> stgraber, oh, and the touchscreen spec is totally selfish ... i want my touchscreen to work on the new lappie ;)
[21:12] <stgraber>  * Integration of avahi with iTalc (already done in PPA)
[21:12] <ogra> not cmpc or edu related :)
[21:12] <stgraber>  * UI for key export/import
[21:13] <stgraber>  * Easy way to add it to the LTSP chroot (some users asked for that)
[21:13] <stgraber> and stability fixes
[21:13] <ogra> what exactly ?
[21:13] <stgraber> some users want ica to be running on the thin clients instead of the server
[21:13] <ogra> hmm
[21:13] <stgraber> so it uses less bandwidth and CPU power
[21:13] <ogra> that will actually use more bandwith
[21:13] <stgraber> the problem is that we'd need to add QT4, dbus and avahi
[21:14] <ogra> hum
[21:14] <stgraber> nope, the X traffic from a full screen demo eats more bandwidth than the VNC stream then uncompressed on the client
[21:14] <ogra> right, in this direction thats true
[21:14] <ogra> general vnc will eat more than just running in loopback mode
[21:15] <stgraber> I don't want that to be a default at all as I know some people can't afford dbus+avahi+qt in their chroot
[21:15] <ogra> anyway, we dont need to write the spec now :)
[21:15] <stgraber> so that'd be a well documented option
[21:16] <ogra> well, i think we will have dbus and hal in the chroot
[21:16] <ogra> qt only eats some space but wont do any harm to have
[21:16] <ogra> avahi is the only thing that makes me worried  bit
[21:16] <stgraber> ok, so we only have avahi left :)
[21:16] <ogra> *a bit
[21:17] <stgraber> this one is useful for the classroom generation stuff
[21:17] <ogra> indeed
[21:17] <ogra> but we should add a swich to the initscript or so
[21:17] <ogra> so you can start it by a lts.conf option
[21:17] <stgraber> indeed
[21:18] <stgraber> I plan to change my current launcher script to detect if we have ICA running on the client and only start it in gnome if we don't
[21:18] <stgraber> so having a switch in lts.conf will work just well
[21:18] <ogra> great
[21:18] <ogra> lets spec that precisely in prague :)
[21:19] <ogra> i'm not sure how far i will get with localapps
[21:19] <stgraber> yep
[21:19] <ogra> but i want something basic at least which seems to be easy to achieve
[21:19] <stgraber> I guess we'll need some kind of localapps support, it's been announced for a long time :)
[21:19] <ogra> scotties xrexecd is in the code already
[21:20] <ogra> where ?
[21:20] <ogra> i never announced any localapps support
[21:20] <stgraber> IRC mainly, every-time someone is asking for it :)
[21:20] <ogra> well, i usually say that there is a proof of concept but nobody working on it
[21:21] <stgraber> so currently the only problem to solve is the filesystem and printer stuff (with firefox for instance)
[21:21] <ogra> shorly after boston when scott was still around that might have been different out of the thrill :)
[21:21] <ogra> no
[21:21] <stgraber> so what's missing ?
[21:21] <ogra> the main issue for proper integration is transparently replacing menu items
[21:22] <ogra> and gconf
[21:22] <ogra> fs stuff should be easy
[21:22] <ogra> i know scottie has ideas and probably even some code i can call him and ask for stuff i guess
[21:23] <ogra> printer shouldnt be a big issue either
[21:23] <ogra> i'd like to start jetpipe from udev if possible
[21:23] <ogra> that wrapper can also set up a local printer the local app sees
[21:24] <ogra> (for the same device)
[21:24] <stgraber> and use CUPS to see the server's printers ?
[21:24] <ogra> anyway, lets not go to much into detail
[21:24] <ogra> right
[21:24] <ogra> IPP or so
[21:25] <stgraber> ok, so the main problem is to hack some gnome code to have a list of .desktop to start as localapps instead of running them on the server
[21:26] <ogra> well, i'D like to have it automated somehow
[21:26] <ogra> ldm can detect what X apps are installed in the chroot
[21:27] <ogra> so an rc.d script can dynamically copy launchers into an overlay dir where it modifies them
[21:27] <ogra> that goes hand in hand with the edubuntu-menus stuff
[21:28] <ogra> gconf will be trickier
[21:28] <ogra> the daemon runs in the session and not where the app sits
[21:30] <ogra> i'm running out of topics :)
[21:30]  * ogra waits for LaserJock to re appear
[21:31] <ogra> i sadly havent seen any specs from rich yet
[21:31] <ogra> so i cant tell anytig abut community
[21:31] <ogra> *anything
[21:31] <ogra> i know he wants finer grained categories for the addon
[21:32] <ogra> but thats the only thing i roughtly know about
[21:33] <ogra> johnny, any lans for sabayon in the next six months ?
[21:33] <ogra> *plans
[21:33] <johnny> i am not sure atm, i'm looking to get a *REAL* job
[21:33] <ogra> or does the gentoo ltsp5 port keep you to busy ? :)
[21:33] <johnny> i'm about done with that as much as i can
[21:34] <johnny> the rest should be easy
[21:34] <johnny> as long as i get somebody else to handle the initramfs situation :)
[21:34]  * ogra points johnny to http://www.ubuntu.com/employment
[21:34] <ogra> *again*
[21:35] <ogra> :)
[21:35] <johnny> the page has been updated, the first tme you pointed me to it, they were only looking for mobile
[21:35] <johnny> the positions listed still perhaps might be beyond my ability tho
[21:35] <ogra> you wont know if you dont try :)
[21:35] <johnny> other than the stable release engineer
[21:36] <johnny> i'm updating my resume atm actually
[21:37] <ogra> well, given that i can discuss the menu stuff with LaserJock directly off meeting and given that i mainly hold monologues ....
[21:38] <ogra> any other business ?
[21:38] <stgraber> not from me
[21:38] <ogra> going once
[21:38] <ogra> .
[21:38] <ogra> .
[21:38] <ogra> .
[21:38] <ogra> going twice
[21:38] <ogra> .
[21:38] <ogra> .
[21:38] <ogra> .
[21:38] <ogra> adjourned :)
[21:38] <ogra> thanks all
[21:39]  * ogra points LaserJock to #edubuntu for further edubuntu-menu discussions
[21:57]  * owh yawns.
[21:58] <soren> o/
[21:58] <sommer> yo
[21:58] <jdstrand>  \o
[21:58] <Keybuk> \|_|o
[21:59] <soren> Keybuk: Is that a guy who's fallen over?
[21:59] <jdstrand> heh
[21:59] <zul> hello
[21:59] <soren> Keybuk: Two legs up in the air and possibly missing an arm..
[21:59] <owh> o/
[22:00] <jdstrand> \|_/o_
[22:00] <soren> That looks painful
[22:00] <jdstrand> (there's another arm for you soren)
[22:00] <owh> Heh, jdstrand, that's the emergency recovery position :)
[22:00] <jdstrand> that looks like a face-plant
[22:00] <mathiaz> Allright guys - let's get started
[22:00] <jdstrand> 'oh no, I fell off my skateboard...'
[22:01] <soren> Aw... We were having so much fun!
[22:01] <mathiaz> soren: wait for UDS
[22:01] <soren> :(
[22:01] <mathiaz> #startmeeting
[22:01] <zul> no bot
[22:02] <soren> Oh, Seveas took mootbot with him, too?
[22:02] <mathiaz> oh well...
[22:02] <nealmcb> yoga on irc!!
[22:02] <mathiaz> Today's Agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[22:03] <mathiaz> Not a lot on it
[22:03] <mathiaz> how is everyone recovering from the release last week ?
[22:03] <jdstrand> great!
[22:04] <nealmcb> the mirrors and other servers seem less overwhelmed now....
[22:04] <nxvl> \o/
[22:04] <nealmcb> I hope they push bittorrent more next time in the release notes etc
[22:04] <mathiaz> There has been a steady flow of bug reported
[22:05] <mathiaz> I've looked through the samba ones
[22:05] <zul> mathiaz: ucf?
[22:05] <mathiaz> and it seems some people don't know how-to handle correctly questions asked by ucf
[22:05] <mathiaz> and this whole configuration file management
[22:06] <nxvl> the worst problem with server isn't that people download iso's
[22:06] <mathiaz> the other main issues are cannot access windows shares - mainly due to gvfs
[22:06] <nxvl> is that they update using update-manager/apt/aptitude
[22:06] <jdstrand> mathiaz: what is going on with that gvfs/samba/AD issue?
[22:06] <nxvl> and that brings the mirrors down
[22:06] <mathiaz> zul: have you seen other recurring bugs in server related software ?
[22:07] <mathiaz> jdstrand: which issue are you refering to ?
[22:07] <jdstrand> mathiaz: I haven't been following too closely, but heard of gvfs not being able to access AD and samba
[22:08] <zul> mathiaz: just some nut ones and apache2 dangling symlink for index.html
[22:08] <jdstrand> seemed it was pushed to gnome...
[22:08] <mathiaz> jdstrand: yeah - something like that - that's mainly a problem with gvfs
[22:09] <mathiaz> I discussed these bugs with seb128 and we aggreed to ask the reporters to test with smbclient
[22:09] <mathiaz> If it works with smbclient it's a problem with gvfs/nautilus-share and the bug should reassigned to the correct packages
[22:10]  * jdstrand nods
[22:10] <mathiaz> If smbclient doesn't work then it's a problem with samba
[22:10] <zul> mathiaz: that natutilius/smbclient one where you cant go 140 directories deep is interesting
[22:11] <mathiaz> zul: we'll have to do more debugging on that one.
[22:11] <mathiaz> So that's all that is on my radar for the post-release bugs
[22:11] <zul> mathiaz: yep
[22:11] <owh> zul isn't that just a maximum path length of 255 chars?
[22:11] <mathiaz> soren: how is it going on the virtualization front ?
[22:11] <soren> I've still got some fallout I need to get on top of.
[22:11] <zul> owh: probably
[22:11] <owh> zul: Which bug number?
[22:11] <soren> There's one update coming up in the next kernel update.
[22:12] <jdstrand> soren rocked the 'soft lockup' bug
[22:12] <soren> I'm looking into a few other things and picking stuff that's suitable for SRU's.
[22:12] <jdstrand> (that's the one)
[22:12] <soren> :)
[22:12] <mathiaz> soren: great !
[22:12] <mathiaz> zul: how do you track SRU bugs ?
[22:13] <mathiaz> zul: did you come up with a specific plan ?
[22:13] <zul> https://wiki.ubuntu.com/ServerTeam/StableReleaseTracker
[22:13] <mathiaz> For information, zul will be the contact point for SRU on hardy for 8.04.1
[22:13] <soren> mathiaz: I'm waiting to be told how to do it.
[22:14] <zul> It would be nice if people would review that and add to the list
[22:14] <soren> Last I heard it was a major cause of discussion in certain places.
[22:14] <mathiaz> soren: right
[22:14] <mathiaz> That's why zul is looking after this in the server team
[22:14] <soren> Oh. Er... Right, I thought you were asking me :)
[22:15] <soren> my bad.
[22:15] <mathiaz> soren: I guess you should use zul wiki page to keep track of SRUs
[22:15] <zul> soren: basically there was a kick off meeting last night/this morning about 8.04.1
[22:15] <soren> zul: Eh? Where? How? When? Who?
[22:15] <soren> What?
[22:15] <zul> soren: it was in the platform team meeting check the logs for #ubuntu-meeting
[22:16] <mathiaz> zul: what was the outcome of the meeting ?
[22:16] <zul> mathiaz: basically slangasek is leading the effort and there will be more meetings
[22:16] <soren> Ok, cool. I'll check the logs and see.
[22:17] <mathiaz> zul: ok. If enconter bugs that may be worth an SRU, should ping you ?
[22:17] <soren> zul: "this morning" is how many hours ago?
[22:17] <nxvl> zul: those meeting are community or canonical ones/
[22:17] <mathiaz> zul: so that you can have a look at it and decide if it's worth ?
[22:17] <kirkland> soren: 0600 UTC
[22:17]  * soren shakes his fist at timezones
[22:17] <zul> mathiaz: correct
[22:17] <mathiaz> nxvl: it was the platform meeting
[22:17] <zul> nxvl: community
[22:17] <soren> Fanks.
[22:17] <nxvl> mathiaz: as in i can attend to it?
[22:18] <nxvl> and where are this meetings announced?
[22:18] <mathiaz> nxvl: of course you can - the meeting was at 6:00 UTC -> translate that to your timezone :D
[22:18] <nxvl> mathiaz: here?
[22:18] <mathiaz> nxvl: yes - all the meetings are held in #ubuntu-meeting
[22:19] <nxvl> and where are they announced? on fridge?
[22:19] <owh> mathiaz: That meeting isn't showing on http://fridge.ubuntu.com/event
[22:19] <mathiaz> the fridge calendar isn't working properly now
[22:20] <owh> Hmm, was there any particular event that caused that and the bot to be borked for a while?
[22:20] <soren> The owner left.
[22:20] <owh> Ah
[22:21]  * owh guesses that there is more behind that simple statement.
[22:21] <mathiaz> Allright - that was all for the release fallout
[22:21] <mathiaz> Let's move on
[22:22] <mathiaz> [TOPIC] bug announcement in #ubuntu-server
[22:22] <mathiaz> soren added a bot to the #ubuntu-server
[22:22] <soren> \o/
[22:22] <mathiaz> and now NEW bugs are announced in the channel
[22:22] <owh> All bugs?
[22:22] <soren> Just server bugs.
[22:22] <mathiaz> owh: only the ones relevant to the server-team
[22:23] <mathiaz> I questionned whether it was usefull as it seems to generate clutter in the channel
[22:23] <soren> (defined as the ones that get announced on<EMAIL_ADDRESS>[22:23] <mathiaz> and I rely on email to get notified about new bugs
[22:23] <mathiaz> soren: and nealmcb thought it's a good idea
[22:24] <mathiaz> what are others' opinion on that ?
[22:24] <owh> mathiaz: My comment would be that if a bug comes past while you're online, you can have a squiz at it.
[22:24] <soren> Yeah. It's hugely helpful for my workflow. I use e-mail when I want to follow up or see history, but an almost real time notification about a new bug is *really* helpful for me.
[22:24] <jdstrand> I saw two bugs that I was able to tend to and close as a result
[22:24] <sommer> I'm all for giving it a try, unless the channel becomes too cluttered
[22:25] <owh> mathiaz: You can set your client to ignore it :)
[22:26] <mathiaz> sommer: agreed - let's give it a try
[22:26] <mathiaz> and see how things evolve
[22:27] <owh> Does your bot come with all the goodies of old soren?
[22:27] <soren> I'm not sure how to respond to that :)
[22:28]  * ajmitch wonders what goodies 'old soren' brings anyway
[22:28] <mathiaz> there are currently two bots in the channel
[22:28] <owh> soren: There was supposed to be a comma before your name :)
[22:28] <jdstrand> can we leave soren's 'goodies' out of this?
[22:29] <soren> Yes, can we? PLease? :)
[22:29] <nxvl> soren: have you test that your bot doesn't make double announce, then one from the bot and an eco from ubotu?
[22:29] <sommer> hehee goodies!
[22:29] <soren> nxvl: I've asked the owner of ubotto to disable the bugSnarfer magic.
[22:29] <soren> nxvl: That should get rid of the echo.
[22:29] <nxvl> :(
[22:30] <mathiaz> soren: great!
[22:30]  * nxvl can't live without ubotu :(
[22:30] <mathiaz> let's move on.
[22:30] <mathiaz> [TOPIC] UDS topics
[22:30] <soren> nxvl: Oh, but my new bot does the same.
[22:30] <nealmcb> who owns ubottu?
[22:30] <mathiaz> So UDS is in a couple of weeks from now
[22:30] <soren> jussi01
[22:30] <soren> Let's talk in #u-server afterwards.
[22:30] <mathiaz> so now is the time to get your ideas in blueprints and register them in LP
[22:31] <mathiaz> so that we can schedule sessions at UDS about these
[22:31] <nxvl> soren: :D
[22:31] <nxvl> mathiaz: 2 to be exactly
[22:31] <nxvl> mathiaz: i have an idea
[22:31] <nxvl> mathiaz: i talked to you some time ago
[22:32] <nxvl> but i whing it was to early
[22:32] <mathiaz> nxvl: right - there will be FOSSCAMP friday/saturday
[22:32] <mathiaz> and then UDS the following week
[22:32] <nxvl> yes
[22:32] <nxvl> i want to include on ubuntu a new tool
[22:32] <mathiaz> nxvl: register a blueprint and/or start a wiki page on w.u.c
[22:32] <nxvl> mathiaz: i have them
[22:32] <nxvl> mathiaz: i just need to work on them a little more and discuss it
[22:33] <mathiaz> nxvl: link ?
[22:33]  * nxvl searches
[22:34] <nxvl> https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-centralized-services-administrator
[22:34] <nxvl> found it
[22:34] <nxvl> it's like soren's blueprint for home servers (https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-easy-business-server)
[22:35] <nxvl> but more open i think
[22:35] <mathiaz> nxvl: right - it's a general concept that is floating around
[22:35] <nxvl> ok
[22:36] <nxvl> what i propose?
[22:36] <nxvl> i have the idea to develop a framework
[22:36] <nxvl> which will cary service-modules
[22:36] <mathiaz> nxvl: ebox is already a framework - couldn't it be used to implement what you wanna do ?
[22:36] <nxvl> so everyone can develop modules and have the service working on this tool
[22:37] <nxvl> mathiaz: yes, that was my next point
[22:37] <nxvl> as we have already ebox
[22:37] <nxvl> i was thinking to limit my propose to developing a curses interface for ebox
[22:38] <nxvl> what i don't really want to, is to install a web server on my firewall or file server
[22:38] <mathiaz> nxvl: why not - you'd have to look into the ebox framework and see if it can be used to achieve that
[22:38] <nxvl> but to have a tools where in which i can administrate and tune my services
[22:38] <nealmcb> nxvl: have you tried running ebox via links or w3m?
[22:38] <RoAkSoAx> you could also add support for LVS based clusters so that you just configure it in one server and replicate the configuration on other nodes of the cluster
[22:38] <nxvl> mathiaz: yes, that's why i'm proposing
[22:38] <RoAkSoAx> without having a tool to replicate like csync2
[22:39] <nealmcb> nxvl: then you wouldn't have to expose the port to the outside world
[22:39] <nxvl> RoAkSoAx: if it goes as i want to, everyone will be able to develop it separately and have it working for my propose or ebox without pain
[22:39] <nxvl> nealmcb: exactly
[22:39] <nealmcb> you'd just bind the apache port to localhost
[22:40] <nxvl> nealmcb: or use resources on a web server, which i can use on my $SERVICE
[22:40] <sommer> seems like one of the highest rated ideas on the brainstorm was for gui admin tools... just fyi
[22:40] <mathiaz> sommer: yes
[22:40] <nxvl> sommer: yep
[22:40] <nxvl> sommer: so we can just then develop UI
[22:40] <mathiaz> sommer: I went through brainstorm and extracted general tpocs
[22:40] <sommer> cool
[22:40] <mathiaz> sommer: *topics*
[22:41] <nxvl> so i was thinking on find a way to develop different UI's for ebox and develop them
[22:41] <mathiaz> sommer: they should be taken into account when scheduling session at UDS
[22:41] <mathiaz> nxvl: ok - I think we're getting into the implementation details
[22:41] <mathiaz> let's defear that to UDS
[22:41] <sommer> mathiaz: sure, I'm really interested in the ldap, kerberos, domain one :)
[22:41] <nxvl> yes
[22:42] <nealmcb> how many people have tried ebox out?  will it be hard to get into main?
[22:42] <nxvl> but i wanted to hear you opinion on this idea
[22:42] <mathiaz> nxvl: write down your suggestion in the wiki page
[22:42] <sommer> mathiaz: should there be a blueprint for documentation with regards to UDS?
[22:42] <RoAkSoAx> as an addon to nxvl, cluster management could be included out of the box!
[22:42] <mathiaz> sommer: yes - there should be a session about network authentication and identity management
[22:42] <nealmcb> sommer: sounds very helpful to me
[22:43] <mathiaz> sommer: I've asked for a documentation session
[22:43] <sommer> mathiaz: awesome, thanks
[22:43] <kirkland> mathiaz: sommer: I'm doing a blueprint on the Ubuntu Documentation Search, as well as an Ubuntu Manpages Website one
[22:43] <mathiaz> sommer: you should register a blueprint so that we can track it and start down to write ideas
[22:43] <mathiaz> sommer: such kirkland ^^
[22:44] <kirkland> mathiaz: https://blueprints.edge.launchpad.net/ubuntu-doc/+spec/ubuntu-documentation-search
[22:44] <sommer> should I just add to kirkland's or create a new one?
[22:44] <kirkland> sommer: i'd say create your own, and we'll link them together
[22:44] <kirkland> i'm going to create a separate one for the Manpages business
[22:44] <sommer> kirkland: cool, sounds good
[22:45] <mathiaz> sounds good to me
[22:45] <mathiaz> That's all I have
[22:45] <mathiaz> [TOPIC] Any other business
[22:45] <mathiaz> someone want to add something ?
[22:45] <nealmcb> how about delivering ibex as a virtual image?  would that be useful?
[22:46] <nxvl> nealmcb: how as a virtual image? as in qemu image?
[22:46] <nealmcb> yeah
[22:46] <mathiaz> nealmcb: you mean providing a qemu image
[22:47] <nxvl> what for?
[22:47] <nealmcb> faster and easier than running install on jeos
[22:47] <nxvl> mm
[22:48] <nxvl> i don't even know what jeos is, so i will step aside on this topic
[22:48] <mathiaz> nealmcb: could be interesting
[22:48] <nealmcb> I also heard folks wanting to deliver on usb sticks - not sure if that is ready-to-run or for the installer
[22:48] <mathiaz> nealmcb: I'd like to see a real use case for -server
[22:48] <mathiaz> nealmcb: I see it usefull on desktop to be able to do a test run
[22:49] <nealmcb> on amazon ec2 there are lots of folks packaging stuff up as images
[22:49] <mathiaz> nealmcb: for -server, you'd base a production server on this ?
[22:49] <mathiaz> nealmcb: I heard there is ubuntu-server on EC2
[22:49]  * mathiaz should look into EC2
[22:50] <nealmcb> if my existing server runs kvm or whatever, and along comes ibex with cool stuff, it would be nice to just load and go into an existing vm
[22:50] <mathiaz> nealmcb: right - so the use case would be to provide a kind of preview
[22:50] <nealmcb> I'm also talking about packaging _applications_ and test cases - like what dan talked about
[22:50] <mathiaz> nealmcb: so that people can poke around
[22:51] <nealmcb> mathiaz: or a basis for building other stuff on
[22:51] <mathiaz> nealmcb: right - that's a bigger plan
[22:51] <nxvl> nealmcb: but we will need to have an image for each service
[22:51] <nxvl> nealmcb: or you mean only base system?
[22:51] <mathiaz> nealmcb: right - that would fall under the Virtual Appliance Builder toolkit or something like
[22:51] <mathiaz> nealmcb: that
[22:51] <mathiaz> nealmcb: I'm sure soren has crazy ideas in that area :D
[22:52] <owh> On other topics, the server guide is *hard* to find.
[22:52] <soren> I do indeed.
[22:52] <nxvl> soren alway has crazy ideas
[22:52] <nxvl> :D
[22:52] <mathiaz> owh: it's listed on the main page of help.u.c
[22:53] <owh> Sigh, I missed that.
[22:53] <nealmcb> and it still says 2006 copyright iirc
[22:53] <mathiaz> nealmcb: yop
[22:53] <sommer> that was a good year :)
[22:53] <nealmcb> "recycle that old stuff"
[22:53] <nealmcb> but bits recycle well...
[22:54] <owh> nealmcb: But is that really true if the electrons change :)
[22:54] <mathiaz> I'm sure sommer will fix that for intrepid
[22:54] <nealmcb> I hope the docs can be on the site when ibex ships this time around
[22:54] <owh> nealmcb: That would be novel :)
[22:54] <mathiaz> Allright - time to wrap up
[22:54] <nealmcb> intrepid!
[22:55] <mathiaz> [TOPIC] #
[22:55] <mathiaz> Agree on next meeting date and time.
[22:55] <owh> Heh
[22:55] <mathiaz> same time, same place next week ?
[22:55] <sommer> o//
[22:55] <nxvl> o/
[22:55] <owh> +1
[22:57] <nealmcb> well I guess that was that....
[22:58] <sommer> nealmcb: the copyright isn't actually in the serverguide source, so I'll figure out how the html is built
[22:58] <owh> Strangely unfulfilling :_)
[22:58] <mathiaz> great - so see you all next week
[22:58] <mathiaz> same time, same place
[22:58] <sommer> mathiaz: thanks, later on all
[22:58] <mathiaz> #endmeeting
[22:59] <owh> Thanks mathiaz!
[23:04] <soren> \o/