[09:30] <teddy-dbear> Morning peoples, critters and everything else
[15:31] <ChinnoDog> I don't understand how 21.04 handles nVidia drivers. The nvidia app isn't installed and the Additional Drivers app has the radio button selected that says they were manually installed. I can't choose a different one.


[09:33] <CIA-37> debian-installer: cjwatson * r1479 ubuntu/debian/changelog: releasing version 20101020ubuntu40
[19:50] <maxb> Hrm. It looks like grub-probe assumes the incorrect path for any md devices created during the natty installer, causing the grub-install call to fail
[20:32] <CarlFK> if my netboot installer append has BOOTIF=01-00-14-22-94-06-6a  should I also need netcfg/choose_inter
[20:32] <CarlFK> face=eth0 ?
[22:35] <v12> hi, i'm having trouble using the alternate installer from USB.  i have grub installed and launch the installer from USB via loopback.  it fails with "searching for Ubuntu installation", and more specifically "cdrom mount failed".  i do not have a boot=... parameter in the kernel line.  how do i tell the installer where its root is?
[22:36] <v12> or, put another way, what is the appropriate boot=... directory for the alternate installer?
[22:39] <v12> topic points to 404 webpage (~scott).  bad sign...
[22:55] <cjwatson> CarlFK: nope, the default (=auto) should do
[22:55] <cjwatson> hm, that link is definitely stale - it was for performance measurements
[22:56] <CarlFK> cjwatson: on a dell laptop whos wifi shows up as eth0, the default gave me "pick an interface"
[22:56] <cjwatson> CarlFK: oh, right, it won't be marked as seen.  use netcfg/choose_interface=auto then
[22:57] <cjwatson> v12: you should definitely never need to tell the installer where its root is by hand
[22:57] <CarlFK> cjwatson: ah, got it.  thanks.  was thinking there was a bug.  will try auto, that sounds sane.
[22:57] <cjwatson> v12: that's sufficiently so that I'm not even sure how one might tell it ...
[22:58] <cjwatson> I don't believe we pass root= normally
[22:58] <cjwatson> boot= is nonexistent AFAI
[22:58] <cjwatson> K
[22:58] <CarlFK> cjwatson: you mind looking at bug 728710 - this has been annoying me for a few releases.  just now got to reporting it but it seems to be slipping into a crack.
[22:58] <ubot2> Launchpad bug 728710 in debian-installer "d-i apt-setup/local0/repository not working" [Undecided,New] https://launchpad.net/bugs/728710
[22:59] <cjwatson> CarlFK: ask me when I haven't just got back from the pub :)
[22:59] <cjwatson> v12: what version of Ubuntu is this?
[22:59] <CarlFK> roger that :)
[23:00] <cjwatson> v12: if it's earlier than natty, cdrom-detect/try-usb=true might help
[23:00] <v12> cjwatson: it's Natty.  i omitted "auto"  i'll try that
[23:01] <v12> is there somewhere i can check for the "auto" logic?  i'm not sure where to browse the source
[23:01] <cjwatson> v12: the auto bit wasn't directed at you
[23:01] <cjwatson> and won't help you
[23:01] <v12> ahh
[23:02] <cjwatson> CarlFK: the snippets of syslog you've posted there aren't very useful - they just describe the bit where d-i is processing the preseed file into the debconf database, not the bit much later on when it actually tries to use them.  could you attach a full DEBCONF_DEBUG=developer syslog?
[23:02] <v12> does the iso need to be in a root directory?  mine is in /boot/isos/natty.iso
[23:02] <CarlFK> cjwatson: will do
[23:03] <cjwatson> v12: let me check
[23:03] <cjwatson> v12: oh, you're doing it that way?  you actually need something a bit different
[23:03]  * cjwatson hunts down the doc link
[23:05] <cjwatson> https://help.ubuntu.com/11.04/installation-guide/i386/boot-usb-files.html
[23:06] <lifeless> cjwatson: oh hai
[23:06] <cjwatson> you can set up a similar boot entry with grub of course, although that describes syslinux
[23:06] <lifeless> cjwatson: could I grab a couple of tips about grub2 & dmraid ?
[23:06] <cjwatson> I suspect the standard loopback.cfg bits may only work properly with the desktop cd
[23:06] <cjwatson> lifeless: maybe, see above comment about just being back from pub
[23:07] <lifeless> cjwatson: heh; I am doing nose following, I hopefully just need broad advice
[23:07] <lifeless> cjwatson: I've filed a bug 803658 about this. the tl;dr version is:
[23:07] <ubot2> Launchpad bug 803658 in grub2 "grub-install /dev/mapper/isw_$UUID_$NAME0 failing with ICH10R raid 1+0" [Undecided,New] https://launchpad.net/bugs/803658
[23:07] <lifeless> dmraid 1+0  (striped layered on mirrored)
[23:08] <lifeless> grub-probe errors out 'cannot find a grub drive for ...'
[23:08] <cjwatson> what's the device.map look like?
[23:08] <cjwatson> if you have one
[23:08] <lifeless> inside the target?
[23:08] <cjwatson> /boot/grub/device.map in whatever filesystem namespace grub-install is running in, yes
[23:09] <lifeless> no such file
[23:09] <cjwatson> ok, failure to autodetect is a bad sign, but two things
[23:10] <lifeless> cjwatson: I wanted to check my understanding, which is that grub will happily read the bios provided mapped array at boot, and that its just a logic failure figuring this out in the prober
[23:10] <cjwatson> (a) figure out what grub-probe command is being run (sh -x /usr/sbin/grub-install <args>, check somewhere near the end), run it with -vv and attach output to bug
[23:10] <v12> cjwatson: says nothing about how to tell the iso not to worry about the CD. i am already booting the kernel in /install.amd/vmlinuz
[23:11] <v12> whoops i mean /install/
[23:11] <cjwatson> (b) you may be able to work around this by creating /boot/grub/device.map (grub-mkdevicemap can create a skeleton); an entry in device.map constitutes a promise that the BIOS can read from that drive
[23:11] <cjwatson> v12: those directions instruct you to use a different build of the installer which has different logic in this area
[23:11] <v12> unfortunately i am trying to use efi
[23:12] <cjwatson> that shouldn't particularly matter
[23:12] <cjwatson> you'll have to translate the boot instructions into grub-speak, certainly, since syslinux won't work
[23:13] <cjwatson> lifeless: yes, at boot time grub should be able to read from anything that the BIOS INT 13h facilities provide
[23:13] <lifeless> cjwatson: attached
[23:14] <lifeless> cjwatson: perhaps grub2 has the same broken filtering that parted does for raid 1+0
[23:14] <cjwatson> it won't be the same as such, but may produce similar results; I agree it's a logic failure in grub-probe
[23:15] <cjwatson> in general we need to probe the root device in order to figure out which modules to build into the core image
[23:16] <lifeless> the probe seems to entirely ignore the array0 device (dm-2)
[23:17] <cjwatson> I *think* an explicit device.map entry should work around this; it doesn't particularly matter what you call it, I'd just use (hdN) where N is one greater than the last entry in what grub-mkdevicemap produces
[23:18] <v12> cjwatson: how does the alternate installer get used for USB?  has anyone done it before?
[23:19] <cjwatson> v12: follow the directions I provided, using the hd-media image
[23:19] <cjwatson> or else, it should be possible to boot the alternate installer by running isohybrid on the ISO and then writing it directly to the entire USB disk
[23:19] <cjwatson> (whether that will work on EFI I don't recall)
[23:19] <lifeless> cjwatson: it still errors on probe
[23:20] <lifeless> same error
[23:20] <v12> aha i'll look for the hd-media image...
[23:20] <cjwatson> lifeless: exactly what line did you put in device.map?
[23:21] <lifeless> I'll paste to the bug (not ircing from that machine)
[23:22] <lifeless> cjwatson: is there now
[23:22] <cjwatson> we certainly seem to need logic in find_partition_start for striped devices
[23:24] <cjwatson> lifeless: if you could attach the output of 'dmsetup table' as well, I can probably attack this tomorrow; I'm afraid it requires a greater level of alertness than I possess right now
[23:24] <lifeless> attached.
[23:25] <lifeless> I'll poke around a bit
[23:25] <lifeless> thanks!
[23:25] <cjwatson> this is partly arising from the need to map partitions onto their offsets from the start of the disk
[23:26] <lifeless> the partition table isn't accurate?
[23:26] <cjwatson> it is, but we do this in order to be able to map partition devices onto their containing disk devices
[23:26] <cjwatson> which is actually startlingly difficult to do in the general case
[23:26] <lifeless> cjwatson: I can imagine - in the striped case it seems impossible to me
[23:26] <cjwatson> shouldn't be, we can get all the links from device-mapper's table
[23:27] <lifeless> cjwatson: doesn't htat imply grub having to reimplement the stripe logic?
[23:27] <cjwatson> since the "containing disk" that we care about is the striped device, not either mirrored device
[23:27] <cjwatson> I don't think so, at least not much, but I'll have to look tomorrow
[23:27] <lifeless> cjwatson: I'm probably misunderstanding the direction of containing there ;)
[23:27] <lifeless> but its late for you
[23:28] <cjwatson> yeah, I don't think I'm being very clear
[23:28] <cjwatson> anyway, bed :)
[23:28] <lifeless> I'll see if I can wipe my disk out at least twice before lunch
[23:28] <cjwatson> sorry not to be able to solve immediately
[23:28] <lifeless> de nada
[23:28] <lifeless> now if I can just remember how to get debian/patches applied
[23:28] <cjwatson> I don't think I've seen the striped case before.  might need to set something up in a vm
[23:28] <lifeless> to build normally
[23:28] <cjwatson> debian/rules patch
[23:28] <cjwatson> in the case of grub2
[23:28] <lifeless> thanks!
[23:29] <cjwatson> (which 'debian/rules build' does for you, but 'debian/rules build/grub-pc' doesn't - that's a bug)
[23:30] <CarlFK> cjwatson: thanks for =auto.  worked as advertised
[23:37] <cjwatson> CarlFK: oh good


[09:26] <dimitern> hey GUI team ;)
[09:27] <dimitern> I'm trying to import a bundle in the GUI and getting "Error generating changeSet
[09:27] <dimitern> There was an error generating the changeSet. See browser console for additional information"
[09:27] <dimitern> there's nothing in the console log of the browser
[09:28] <dimitern> frankban, fabrice, (others eu-based?) ^^
[09:29] <frankban> dimitern: weird that there is nothing in the console
[09:29] <frankban> dimitern: could you please paste me the bundle?
[09:29] <dimitern> frankban, yeah - it's https://jujucharms.com/mediawiki-scalable/10
[09:30] <dimitern> frankban, I've modified it slightly for a demo - the only changed thing is adding constraints; the YAML is valid (used yamllint.com) - http://paste.ubuntu.com/12623296/
[09:30] <frankban> dimitern: uhm... if I just click add to demo in that page the uncommitted state is generated correctly
[09:31] <dimitern> frankban, here's my test env: https://<IP_ADDRESS>/
[09:31] <dimitern> frankban, 23351c36e3b1df5d7dc256673a2203e9
[09:31] <frankban> dimitern: so I believe that the GUI server does not know about the spaces constraints
[09:31] <dimitern> frankban, ah :/ too bad
[09:32] <dimitern> frankban, can I patch it somehow for the demo?
[09:32] <frankban> dimitern: do you need to deploy the GUI as part of the demo or is it already set up?
[09:33] <dimitern> frankban, I need some way to both show the deployment and deploy the bundle, and I didn't want to use juju-deployer
[09:33] <dimitern> frankban, I deployed the gui first --to 0
[09:33] <frankban> dimitern: ok, but the juju-gui charm is deployed pre-demo right? so that you can hack on it before the demo
[09:34] <dimitern> frankban, yes, absolutely
[09:35] <frankban> dimitern: ok, let me deploy it in a local env so that we can try this
[09:35] <dimitern> frankban, I even plan to deploy the bundle before the demo and just show the gui and poke with the CLI a bit
[09:36] <dimitern> frankban, local env won't work for the spaces constraints - they're ignored everywhere but on amazon for the moment
[09:36] <dimitern> frankban, and you need to use 1.25 or master
[09:36] <frankban> dimitern: I don't want to deploy the bundle myself, I just want to make it load as uncommitted state
[09:36] <dimitern> frankban, ah, got you ok
[09:42] <dimitern> frankban, fwiw spaces constraints have exactly the same format as tags - comma-delimited,using ^ to indicate "not"
[09:52] <frankban> dimitern: ok
[09:52] <frankban> dimitern: I was able to ave that bundle imported as uncommitted state
[09:52] <frankban> dimitern: first: juju ssh juju-gui/0 sudo nano /usr/local/lib/python2.7/dist-packages/jujubundlelib/validation.py
[09:53] <frankban> dimitern: use the editor to update _CONSTRAINTS so that it includes a 'spaces', line
[09:53] <frankban> dimitern: then restart the gui server: juju ssh juju-gui/0 sudo service guiserver restart
[09:53] <frankban> dimitern: at this poijt your bundle should work
[09:53] <frankban> point even
[09:54] <dimitern> frankban, awesome! thanks - will try it now
[09:54] <frankban> dimitern: cool
[09:56] <dimitern> frankban, it did import fine after this! thanks again :)
[09:57] <frankban> dimitern: yes, we should update bundlelib and make a new charm release with that little change. is spaces constraints for 1.26?
[09:57] <dimitern> frankban, it's for 1.25 even
[09:59] <frankban> dimitern: ok, I'll add a card, good that we found this hack for next week
[09:59] <dimitern> frankban, yeah, a bit last-minute, but you know how it is with such demos :)
[10:01] <frankban> dimitern: heh, all good
[10:03] <dimitern> frankban, hmm.. there might be more needed btw - i'm watching the deployment as it happens and it seems the spaces constraints were not applied
[10:03] <frankban> dimitern: uhm... that's the GUI side
[10:04] <dimitern> frankban, could it be because the gui adds machines first and then deploys --to them, rather than using ServiceDeploy API ?
[10:06] <dimitern> frankban, I've exported the current bundle from the GUI and indeed the constraints from the bundle are not there - http://paste.ubuntu.com/12623497/
[10:06] <frankban> dimitern: let me check the resulting bundle changes
[10:07] <dimitern> frankban, ok
[10:11] <frankban> dimitern: ok so the bundlelib does not handle service constraints, but only machine constraints :-/
[10:12] <dimitern> frankban, right, is there another lib to modify then?
[10:13] <frankban> dimitern: so the server side fix is easy enough, not sure about the client side JavaScript
[10:13] <dimitern> frankban, just running: juju add-machine --constraints spaces=dmz did the right thing from the CLI
[10:14] <frankban> dimitern: in your bundle, can you add spaces to machines rather than services?
[10:14] <dimitern> frankban, yes - I'll try now
[10:24] <dimitern> frankban, I tried importing this bundle - it worked, but still the machine didn't end up in the right place (i.e. spaces constraints were ignored) - http://paste.ubuntu.com/12623583/
[10:25] <frankban> dimitern: ok trying
[10:27] <frankban> dimitern: ok these are the corresponding changes and they look reasonable (spaces is in there): http://paste.ubuntu.com/12623599/
[10:28] <dimitern> frankban, yeah - the machine constraints look sane, but the service it seems it's not supported - that's fine, as long as the machines end up in the right place
[10:28] <frankban> dimitern: in the javascript console, network tab, you should be able to see the websocket requests made by the GUI (there is a WS filter), I am bootstrapping another env
[10:29] <frankban> dimitern: service constraints are not currently handled
[10:29] <frankban> dimitern: that's a current limitation of the GUI
[10:29] <frankban> dimitern: I mean, the changes do not include service constraints, and this needs to be changed
[10:29] <dimitern> frankban, ok, I'm looking at the network log + ws filter
[10:30] <dimitern> frankban, if we can make at least the machine constraints work, it will be great
[10:30] <frankban> dimitern: the machine constraints should already work
[10:31] <dimitern> frankban, but not for spaces=..
[10:31] <dimitern> frankban, unless I need to patch some other place?
[10:31] <frankban> dimitern: let's see what's sent to the server
[10:33] <dimitern> frankban, I see no WS requests.. let me try destroying and re-deploying the last bundly
[10:33] <dimitern> bundle
[10:35] <frankban> dimitern: to check ws requests we can also try the following: juju set juju-gui builtin-server-logging=debug
[10:35] <dimitern> frankban, I've seen the api WS after refreshing the page, committing now and will see what happens
[10:36] <dimitern> frankban, I've added the logging before this
[10:37] <frankban> dimitern: juju ssh juju-gui sudo tailf /var/log/upstart/guiserver.log
[10:38] <dimitern> frankban, there's quite a lot, let me paste it
[10:39] <frankban> dimitern: note that it will include passwords
[10:39] <dimitern> frankban, yeah, hence - paste.c.c - https://pastebin.canonical.com/140855/
[10:40] <frankban> dimitern: that does not seem to include the deployment calls
[10:42] <dimitern> frankban, what should I look for? Type: ChangeSet ?
[10:42] <frankban> dimitern: AddMachines?
[10:43] <dimitern> frankban, just a sec
[10:43] <dimitern> frankban, not found - let me check earlier in the log
[10:46] <dimitern> frankban, this is the full log so far - https://pastebin.canonical.com/140857/
[10:46] <dimitern> frankban, no addmachines
[10:47] <dimitern> frankban, oops sorry
[10:48] <dimitern> frankban, it seems I've hit a js exception which left the gui paused in the debugger, so the change set was not committed, doing it now
[10:48] <frankban> dimitern: ok client -> juju: {"Type":"Client","Request":"AddMachines","Params":{"MachineParams":[{"Jobs":["JobHostUnits"],"Series":"trusty","Constraints":{}}]},"RequestId":13}
[10:48] <frankban> dimitern: I've found the bug, and that's a GUI bug
[10:48] <frankban> dimitern: the constraints are empty there
[10:48] <dimitern> frankban, ah! ok
[10:49] <dimitern> frankban, yeah, sound like a bug
[10:49] <frankban> dimitern: can you confirm that no constraints are applied (not just the spaces one)
[10:52] <dimitern> frankban, yes - none of the services deployed by the gui have any output from juju  get-constraints <svc>
[10:52] <frankban> dimitern: so the GUI server return a change with constraints (after the  little hack). the GUI has those constraints in its internal uncommitted state, but when turning the uncommitted state into actual API calls the GUI does not send the constraints to AddMachines
[10:52] <dimitern> frankban, nailed it then :)
[10:52] <frankban> dimitern: yes looking at the code I can confirm that constraints are ignored by the AddMachine client call
[10:54] <frankban> dimitern: so we have two GUI bugs (service constraints are ignored server side by the bundlelib, machine constraints are ignored client side by the GUI). I am sorry about that, so the deployer (or quickstart) could be an option at this point
[10:55] <dimitern> frankban, hmm - wait a sec - is the gui using "AddMachines" client API or "AddMachinesV2" ?
[10:55] <frankban> dimitern: {
[10:55] <frankban>         Type: 'Client',
[10:55] <frankban>         Request: 'AddMachines',
[10:55] <frankban>         Params: {MachineParams: machineParams}
[10:55] <frankban>       }
[10:56] <frankban> dimitern: so facade version shoudl be 0, the request is Client.AddMachines
[10:56] <dimitern> frankban, yeah, actually it doesn't matter - both end up calling the same backend method on the apiserver
[10:56] <dimitern> frankban, so AFAICS it constraints are present in machineParams they are honored
[10:57] <dimitern> s/it/if/
[10:57] <frankban> dimitern: they are not, but we can try the ultimate hack
[10:57] <dimitern> frankban, :) sure?
[10:58] <frankban> dimitern: so... juju set juju-gui juju-gui-debug=true
[10:58] <frankban> dimitern: this is required so the GUI is served from non-minified files that we can edit on the unit
[10:59] <dimitern> frankban, ok, done
[10:59] <frankban> dimitern: now edit the /var/lib/juju-gui/juju-gui/build-debug/juju-ui/store/env/go.js file on the GUI unit
[11:00] <dimitern> frankban, I'm there
[11:00] <frankban> dimitern: search for "_addMachines:"
[11:01] <frankban> (without quotes)
[11:01] <dimitern> frankban, yeah - the method I presume?
[11:01] <dimitern> @method _addMachines
[11:02] <frankban> dimitern: add "Constraints: param.constraints," after Series in the machineParam definition
[11:02] <dimitern> frankban, done and saved - restart guiserver or just refresh the gui?
[11:02] <frankban> dimitern: just refresh the GUI should be sufficient
[11:03] <frankban> dimitern: hard refresh is better (shift + referesh)
[11:04] <dimitern> frankban, I even did ctrl+shit+f5 for good measure - now adding a machine with some constraints via the gui
[11:05] <dimitern> frankban, ..aaand it seems it worked! - I can see r3.xlarge spinning up after adding mem=16000
[11:05] <frankban> dimitern: now we should try it with a bundle
[11:06] <dimitern> frankban, yep, but first let me destroy all but the gui first..
[11:10] <dimitern> frankban, ok all is nice and clean now - redeploying the modified bundle with machines constraints specified..
[11:13] <dimitern> frankban, will it screw things up if I use machine ids like "1", "2", in the bundle? I mean - my last machine ID is 14, so should I change the to: - "X" and machines: "X" to use the next ID 15 etc?
[11:14] <frankban> dimitern: the machine ids in the bundle are not related to the identifiers in the actual environment, it's just a way to assign units to machines
[11:15] <dimitern> frankban, ah, cool!
[11:15] <frankban> dimitern: so you should always be able to use 1, 2 etc.
[11:15] <frankban> dimitern: at least that's how we intended it in the spec, hope that the GUI reflects that :-)
[11:18] <dimitern> frankban, ok, here goes nothing ... fingers crossed and all - committing .. :)
[11:18] <frankban> dimitern: now it's a good moment to tailf guiserver logs
[11:19] <dimitern> frankban, hmm.. ok - will do - it's doing fine for now though..
[11:20] <frankban> dimitern: \o/
[11:22] <dimitern> frankban, hmm.. not really - constraints are still ignored AFAICS - checking the logs now
[11:23] <dimitern> frankban, yeah - AddMachines still has empty constraints
[11:24] <frankban> dimitern: okso they are passed when ading machines manually, but they are still ignored when deploying an uncommitted state
[11:25] <dimitern> frankban, right, so can we fix this? sorry I'm taking so much of your time for this BTW, it's really appreciated - even if we can't fix the above, it should still be possible to do the demo by first manually adding machines and then deploying the bundle's units to them
[11:26] <frankban> dimitern: investigating
[11:26] <rick_h_> frankban: dimitern only half read the traceback, would this work with your branch frankban ?
[11:27] <rick_h_> frankban: dimitern 1 to work around the gui issues and two to perhaps follow a shorter path on the future work?
[11:27] <frankban> rick_h_: my branch?
[11:27] <rick_h_> frankban: bundle deployment branch
[11:29] <dimitern> rick_h_, hey there :) btw this is actually the first time I'm using the gui for more than 2m :)
[11:29] <frankban> rick_h_: machine constraints should work, not the services ones because the changes format reflects the one used by the GUI, and I have cards for fixing that
[11:29] <rick_h_> dimitern: sorry it's not going magically for you :/
[11:29] <rick_h_> frankban: ok figured I'd ask
[11:29] <frankban> rick_h_: but it's worth trying. my impression is that dimitern was trying to use the GUI, otherwise also the deployer would probably work
[11:30] <rick_h_> dimitern: this is part of the fun of keeping up with core features when we miss/don't have the support through all the tool chain unfortunately
[11:30] <dimitern> rick_h_, it's totally fine, not complaining :)
[11:30] <rick_h_> frankban: well for a demo in front of sabdfl I'd like to avoid using the deployer if at all possible
[11:30] <rick_h_> frankban: and if it could use the upcoming stuff that makes him smile...mega win
[11:30] <dimitern> rick_h_, +1 me too
[11:31] <dimitern> frankban, rick_h_, guys, I need to step out for ~30m, will ping you when i'm back
[11:32] <frankban> rick_h_: +1
[11:33] <rick_h_> frankban: if the gui can be made to work that's all good as well
[11:35] <frankban> rick_h_: I've found the problem with the API call, and now machine constraints work with the hack I described above if you manually add a new machine. they are still ignored if you use ecs. I checked and ecs.changeSet includes the correct args as returned by the GUI server, so we'll need to investigate where we loose them
[11:36] <rick_h_> frankban: understand.
[12:14] <frankban> dimitern: oh wait
[12:14] <frankban> dimitern, rick_h_ actually go.js handles machine constraints, I didn't see the if (param.constraints) {
[12:14] <frankban>           machineParam.Constraints = self.prepareConstraints(param.constraints);
[12:14] <frankban>         }
[12:31] <dimitern> frankban, rick_h_, I'm back now
[12:32] <dimitern> frankban, so then change another method?
[12:35] <frankban> dimitern, rick_h_ so basically this is fixed in pyramid-fork (not ready to use)
[12:35] <frankban> dimitern, rick_h_ looks like we need to backport https://github.com/juju/juju-gui/pull/821
[12:36] <urulama> frankban: is this the only branch needed to be backported?
[12:36] <frankban> dimitern: so basically the change that needs to be done in go.js is not the one I suggested, but the one at https://github.com/juju/juju-gui/pull/821/files. so add a bunch of lines at the beginning of prepareConstraints
[12:37] <frankban> dimitern: could you please try to copypasta those lines?
[12:37] <dimitern> frankban, I see.. ok I'll try this diff from the PR now
[12:37] <frankban> dimitern: the diff will not apply
[12:38] <frankban> dimitern: the pyramid-fork branch has a very different file structure
[12:38] <frankban> dimitern: copypaste is your only options, and it's just those lines in the PR
[12:38] <frankban> dimitern: you only need the changes in go.js, other stuff are tests and makefile
[12:39] <frankban> urulama: yes that's the only brancvh to be backported for now, but then you'd need a gui release
[12:39] <frankban> urulama: let's see if the hack works
[12:39] <dimitern> frankban, yeah, I'll cherry pick it manually and add the lines
[12:40] <frankban> dimitern: cool, let me know how it goes
[12:40] <urulama> frankban: ok, let's see. we have some gui bugs to fix, so it can land alongside those
[12:40] <dimitern> frankban, sure, will be 1/2h perhaps - need to eat something :)
[12:41] <frankban> urulama: this is actually a big bug, meaning machine constraints are not applied when deploying bundles. it didn't hit us because there are not so many bundles with constraints
[12:41] <urulama> frankban: did you already add a defect card for this?
[12:42] <frankban> urulama: it's a task in urgent
[12:42] <urulama> kk
[12:44] <frankban> urulama: what we need after seattle is 1) update jujubundlelib so that it sends service constraints and it allows "spaces" as a constraint 2) update the GUI ecs to reflect the changes in jujubundlelib, 3) release jujubundlelib and the GUI 4) update bundlechanges as well 5) update guibundles to use newer bundlechanges and to send the service constraints
[12:45] <urulama> frankban: maybe someone can pick it up even during Seattle
[12:45] <frankban> urulama: 1) might include other changes, since we are modifying the protocol, I have cards for all the changes we want to make
[12:45] <urulama> frankban: cool, ty
[12:46] <frankban> urulama: yes, but I'd like to have a pre-impl call with the implementer before
[12:49] <frankban> urulama: these are the changes I'd like to make to jujubundlelib/bundlechanges protocol: 1) support service constraints, 2) in addService changes, make the charm argument a placeholder pointing to the correspondig addCharm change, 3) remove the num_unit argument from addUnit changes, since it will always be 1 unit, 4) maybe s/deploy/addService in the addService method, for consistency
[12:50] <urulama> frankban: how come 3) will always be 1?
[12:51] <frankban> urulama: because each addUnit change only adds a single unit
[12:51] <frankban> urulama: so if you want to add 10 units you get 10 addUnit changes back
[12:53] <urulama> frankban: ah, ok, misread that num_unit as part of bundle yaml ...
[12:53] <urulama> frankban: multitasking ftw :)
[12:53] <urulama> frankban: ok, noted. this can probably wait till end of Seattle
[12:54] <frankban> urulama: I think so
[14:07] <dimitern> frankban, it *almost* worked :)
[14:08] <dimitern> frankban, {"Type":"Client","Request":"AddMachines","Params":{"MachineParams":[{"Jobs":["JobHostUnits"],"Series":"trusty","Constraints":{"arch":"amd64","cpu-cores":1,"cpu-power":300,"mem":3840,"root-disk":8192}}]},"RequestId":21}
[14:08] <frankban> dimitern: so now the constraints are passed, all but the spaces one correct?
[14:08] <dimitern> frankban, spaces are not included though - the bundle has this line: constraints: "arch=amd64 cpu-cores=1 cpu-power=300 mem=3840 root-disk=8192 spaces=dmz"
[14:09] <frankban> dimitern: I would not expect anything different ;-)
[14:09] <dimitern> frankban, right - could it be because it's not a string but an array?
[14:09] <frankban> dimitern: is it?
[14:10] <dimitern> frankban, well, as json it should be serialized the same way as "tags=foo,^bar" (IIRC "tags: ["foo", "^bar"]")
[14:10] <frankban> dimitern: how the server expects spaces to be passed?
[14:10] <frankban> dimitern: so the comma separated string is not ok?
[14:10] <dimitern> frankban, nope, it should work the same I guess..
[14:11] <dimitern> frankban, I can't see any specific handling for "tags" or "networks" (I wouldn't expect it for the latter, but at least the former is useful)
[14:12] <frankban> dimitern: there is
[14:12] <frankban> dimitern: so first I think we should add "spaces" to the genericConstraints list in go.js
[14:13] <frankban> dimitern: the in prepareConstraints there is a piece of code like http://pastebin.ubuntu.com/12624766/ and we should do the same for spaces if we need to send an array
[14:14] <dimitern> frankban, trying it now
[14:15] <frankban> dimitern: something like http://pastebin.ubuntu.com/12624773/ I guess
[14:20] <dimitern> frankban, \o/ !! it worked
[14:20] <frankban> dimitern: wheeee
[14:20] <dimitern> frankban, I think this gives me enough to prepare for the demo - just let's summarize what was needed in order to get there:
[14:21] <frankban> dimitern: well, that was not straightforward, apologies for that, really!
[14:21] <dimitern> frankban, no, it's fine, seriously - we should sync-up more often with you guys and use the gui a *lot* more
[14:22] <dimitern> frankban, would it work if I just patch go.js with the last 2 changes ? (i.e. not touch guiserver ?)
[14:22] <frankban> dimitern: you still need to allow spaces in validation.py
[14:23] <dimitern> frankban, I guess since service cons are not used, it's not worth specifying them in the bundle for services, just machines?
[14:23] <dimitern> (I have them in both places now)
[14:23] <frankban> dimitern: so the bundle should only include machine constraints
[14:23] <dimitern> frankban, exactly
[14:23] <frankban> dimitern: service constraints are ignored
[14:24] <dimitern> frankban, yeah
[14:24] <frankban> dimitern: still you'll need to add 'spaces' to _CONSTRAINTS in validation.py, because I believe the same function is used to validate service and machine constraints
[14:24] <dimitern> frankban, I see, ok
[14:24] <dimitern> frankban, and also enable the juju set juju-gui juju-gui-debug=true
[14:25] <frankban> dimitern: then you need to apply the changes in go.js, excluding the one I suggested intiially, just the backport and the two most recent ones
[14:25] <frankban> dimitern: yes, otherwise the minified files are server, and your changes do not have effect
[14:25] <frankban> (go.js changes)
[14:26] <frankban> dimitern: so, for sanity, I'd suggest to 1) deploy the GUI 2) apply the juju-gui-debug=true option 3) change validation.py and go.js and 4) restart the GUI server
[14:27] <dimitern> frankban, sweet - all written down in my notes, will retry the whole thing from scratch tomorrow, just to make sure it's fine
[14:27] <frankban> dimitern: since we are not planning to release a GUI before seattle, you could script that as well 1) deploy 2) set 3) scp 4) ssh
[14:28] <frankban> dimitern: sure, and you'll find me here tomorrow
[14:29] <dimitern> frankban, sweet! thanks a million for all your help! :)
[14:29] <frankban> my pleasure


[13:48] -queuebot:#ubuntu-quality- Builds: Netboot amd64 [Xenial 16.04.4] (20101020ubuntu451.22) has been added
[13:48] -queuebot:#ubuntu-quality- Builds: Netboot armhf [Xenial 16.04.4] (20101020ubuntu451.22) has been added
[13:48] -queuebot:#ubuntu-quality- Builds: Netboot powerpc [Xenial 16.04.4] (20101020ubuntu451.22) has been added
[13:48] -queuebot:#ubuntu-quality- Builds: Netboot s390x [Xenial 16.04.4] (20101020ubuntu451.22) has been added
[13:48] -queuebot:#ubuntu-quality- Builds: Netboot arm64 [Xenial 16.04.4] (20101020ubuntu451.22) has been added
[13:48] -queuebot:#ubuntu-quality- Builds: Netboot ppc64el [Xenial 16.04.4] (20101020ubuntu451.22) has been added
[13:48] -queuebot:#ubuntu-quality- Builds: Netboot i386 [Xenial 16.04.4] (20101020ubuntu451.22) has been added


[06:29] <jose> pleia2: I'll have to grab a copy myself!
[07:08] <pleia2> sure :)
[20:01] <velzy> hello all
[20:03] <velzy> could really use some help, if anyone is aroud....i simply cannot get samba working for some reason
[20:04] <velzy> have tried everything i can find online, but i'm stumped
[20:04] <blitz> is the main support channel not being useful?
[20:05] <velzy> nope
[20:05] <velzy> everyone is directing me to the obvious instructions, but i'm well passed that
[20:06] <blitz> how about the samba specific support channel
[20:06] <blitz> ubuntu-samba
[20:06] <velzy> oh!
[20:06] <velzy> didnt see that exists
[20:06] <blitz> bad joke :3
[20:06] <velzy> thank you
[20:06] <velzy> oh haha damn, i was so excited haha
[20:06] <blitz> there might be a #samba though lol
[20:07] <velzy> haha good point
[20:07] <velzy> i'll investigate


[22:24] <LukasM[m]> Craig: Netplan is modifying system wide configuration, so you cannot do that without root privileges, neither through dbus nor otherwise.


[00:00] <Joe_knock> apologies
[00:00] <Joe_knock> there was no other word to use.
[01:28] <Guest67771> Hi running Ubuntu 12.04 server at home, and I recently switched static IP addreses. Since that time, Webmin won't work - it just shows unable to connect. Would anyone have troubleshotting tips for me - the internet is all good?
[01:31] <pmatulis_> Guest67771: webmin isn't supported by ubuntu
[01:31] <pmatulis_> !webmin
[01:32] <Guest67771> Ok....is there another tool to manage scheduled cron jobs?
[02:10] <dw1> crontab -e will load a text editor
[02:11] <dw1> crontab --help
[02:11] <dw1> man crontab
[02:11] <dw1> oh he left. wups
[05:17] <hellinterim> What does ubuntu server normally assign the dev device name to usb externals?
[05:19] <sarnold> hellinterim: /dev/sd* -- perhaps the biosdevname package changes the names..
[05:24] <hellinterim> i just installed fuse. Was that needed lol because I see sdc now.
[05:25] <sarnold> the /dev/sdc block device should have existed without fuse; but perhaps the filesystem that is on the block device needed fuse to be mounted
[05:26] <hellinterim> it's ext3
[05:26] <hellinterim> hmm well anyway. thanks. cya
[07:40] <lordievader> Good morning.
[07:43] <achab> 'morning
[07:44] <lordievader> Hey achab, how are you?
[07:46] <achab> fine thanks, and you?
[07:46] <lordievader> Doing well here too.
[12:17] <Macer> hm
[12:17] <Macer> where exactly does lxc get its address from when using dhcp?
[12:17] <Macer> because i am getting an old dns that i no longer wish to use when the container starts
[12:18] <Macer> but the old dns seems persistent even tho i have no idea where it is grabbing it from
[13:42] <pmatulis_> Macer: by default, from dnsmasq
[13:44] <pmatulis_> there is a network bridge set up (lxcbr0), viewed with 'ip addr show lxcbr0' and 'sudo brctl show'
[15:21] <Macer> pmatulis_: yeah i disabled that
[15:21] <Macer> i figured it out tho. thanks anyways ;)
[15:22] <Macer> so far i have set up quite the little ubuntu server
[15:22] <Macer> the contianers are great
[15:42] <pmatulis_> Macer: yep
[15:42] <pmatulis_> using them now myself
[18:06] <azim> hi
[18:08] <wastl> hi
[18:08] <lordievader> o/
[18:25] <Macer> well. this ubuntu server is coming along quite well :)
[18:25] <Macer> i even have tv tuners in it lol
[20:24] <luttermann84> So... While trying to provision a server using MaaS, apt complained that the Packages file was gone! And it seens to be right, only Packages.bz2 and Packages.gz are avalible! What to do now?!
[20:34] <Patrickdk> run apt-get update
[20:36] <luttermann84> Patrickdk: it's kind of hard in the pxe booted environment, it shuts down becaouse of the error from apt.. and it properly wouldn't solve the problem that apt is looking for a nonexistent file.
[20:36] <Patrickdk> oh, in there
[20:50] <hxm> i want to send emails using smtp, does not exists a script for do that with TLS support?
[20:50] <hxm> i dont mind which programming language it is
[20:50] <hxm> i just found many that wont work
[21:01] <bekks> hxm: So setup a mail server.
[21:01] <hxm> i did but I want send authed
[21:02] <bekks> So configure your mailserver to do so.
[21:02] <luttermann84> hxm: what is it you want to achieve?
[21:03] <hxm> bekks: you didnt understand what I said
[21:03] <hxm> luttermann84: send an email from a background process with a smtp with tls
[21:03] <bekks> I perfectly did. But you didnt answer my question.
[21:04] <hxm> the mailserver is working, I can send emails from any mail desktop client, is all these scripts I found which fail with tls
[21:06] <luttermann84> The best way is proberly to use the local mta on the system to relay the messages, if you are connecting to the local machine you don't need tls, and you can use the mail command.
[21:09] <hxm> yea, but is the backup server, and I wanted to use the main server as a normal client, but surely I will need to do that
[21:09] <hxm> btw goal real madrid
[21:10] <luttermann84> hxm: what?
[23:06] <SCHAAP137> sup


[11:18] <jk44> hi, i have noticed a possible bug in upstart
[11:19] <jk44> i wrote this job :
[11:19] <jk44> console output
[11:19] <jk44> pre-start script
[11:19] <jk44> 	echo "**UPSTART : ************* launching RCS ********** "
[11:19] <jk44> end script
[11:19] <jk44> script
[11:19] <jk44> 	echo "avant exec"
[11:19] <jk44> 	exec /etc/init.d/rcS
[11:19] <jk44> 	echo "apres exec"
[11:19] <jk44> end script
[11:19] <jk44> post-start script
[11:19] <jk44> 	echo "will try to launch runlevel 3"
[11:19] <jk44> 	echo "done rlv 3"
[11:19] <jk44>
[11:19] <jk44> 	echo "gona launch rcS"
[11:19] <jk44> end script
[11:19] <jk44> and post start is executed before exec script
[11:20] <Keybuk> incorrect
[11:20] <Keybuk> post start is executed alongside the exec script
[11:21] <jk44> ok, it explain what i get
[11:21] <Keybuk> which wins is dependant on such matters as your kernel, and possibly the one that outputs first is running second, and it's the console buffer that's fooling you
[11:21] <Keybuk> post-start makes most sense when the process run by exec is not immediately redy
[11:21] <Keybuk> you can use the post-start script to poll the daemon until it's accepting connections
[11:22] <Keybuk> the job won't be marked running until the post-start script exits
[11:22] <jk44> ok, thk very much
[11:22] <jk44> another dub question :
[11:23] <jk44> when a job fail starting, how can i recover, (as it has not failed)
[11:23] <jk44> and start the other jobs ?
[11:23] <jk44> is "started failed or started"
[11:23] <jk44> the solution ?
[11:24] <jk44> i am trying that, but quite unsuccessfully
[11:29] <Keybuk> start on stopped JOB failed
[11:30] <Keybuk> the stopped event for the job will include the argument "failed", and will include arguments and environment saying what failed, etc.
[11:30] <Keybuk> http://upstart.ubuntu.com/wiki/JobFailedEvent
[11:30] <Keybuk> ^ see that
[11:30] <Keybuk> e.g.
[11:30] <Keybuk> stopped apache failed
[11:30] <Keybuk>   EXIT_SIGNAL=SIGSEGV
[11:31] <jk44> ok, sorry for bothering with such uninterresting question ^^, i had not very well understood the doc (poor english :s)
[11:34] <Keybuk> that's ok
[11:34] <Keybuk> the docs aren't great yet
[02:38] <AlexExtreme> hmm
[02:38] <AlexExtreme> this is weird
[02:38] <Keybuk> hmm?
[02:39] <AlexExtreme> i've got some native jobs written for LFS
[02:39] <AlexExtreme> (just playing around)
[02:39] <AlexExtreme> it boots fine
[02:39] <AlexExtreme> apart from somewhere a bash syntax error gets printed
[02:39] <AlexExtreme> it says the syntax error is in /dev/fd/7 every time
[02:40] <AlexExtreme> i can't figure out why
[02:40] <Keybuk> heh
[02:40] <Keybuk> /dev/fd/7 is the name of the shell script upstart executes if it's > 1024k or so
[02:41] <AlexExtreme> strange
[02:42] <Keybuk> why?
[02:42] <AlexExtreme> i have no job even 2kb
[02:42] <Keybuk> that's a little more unusual
[02:42] <Keybuk> oh, sorry, 1024 bytes
[02:42] <Keybuk> not K
[02:42] <Keybuk> I always do that
[02:42] <Keybuk> 1K
[02:42] <AlexExtreme> ah
[02:42] <AlexExtreme> that limits it to 2 jobs
[02:44] <Keybuk> (the /dev/fd thing is because upstart makes a pipe on which it arranges the script to be executed; and that's the trick to passing it to sh as a file)
[02:44] <AlexExtreme> k
[02:44] <AlexExtreme> the weird thing though, is that i get no "job failed" message from upstart
[02:44] <Keybuk> passing it on "standard input" would mean the script couldn't use exec < or things like that
[02:44] <Keybuk> and passing it in the arguments could exceed available space
[02:49] <AlexExtreme> ah, got it
[02:49] <AlexExtreme> stupid type
[02:49] <AlexExtreme> *typo
[02:50] <Keybuk> dunno why it doesn't fail
[02:50] <Keybuk> maybe you've got a set +e in there?  or an ||/&&, or it's part of an if, etc.
[02:51] <AlexExtreme> yeah, it was part of a ||
[06:35] <AlexExtreme> now *that's* what i call optimization
[06:35] <AlexExtreme> http://www.alex-smith.me.uk/files/bootchart-ud.png
[06:35] <AlexExtreme> :D
[06:37] <ion_> :-)
[07:38] <tale> AlexExtreme, I'm not an upstart expert, but that distro wouldn't do much, right?
[07:39] <AlexExtreme> the boot sequence does actually run more stuff, just it seems that bootchart missed some stuff
[07:39] <AlexExtreme> currently it boots to a text-based multiuser system with networking and ssh
[07:40] <tale> ah
[07:40] <tale> what are some of the fastest boot times you guys are getting with the latest development code?
[07:41] <AlexExtreme> that is the fastest boot i have ever got with any init system
[07:44] <tale> but, what about a normal ubuntu install?
[07:44] <AlexExtreme> i haven't tried with ubuntu, since i don't use it ;)
[07:44] <tale> what distro do you use?
[07:44] <tale> I assumed ubuntu since most distros don't use upstart
[07:45] <AlexExtreme> frugalware atm


[01:53] <pleia2> tsimonq2: need help with the last two?
[01:54] <tsimonq2> pleia2: whoops, somehow I ended up watching Linux Sucks 2016 by Bryan Lunduke for the third time...I'm on it!
[01:54] <pleia2> lol
[01:54] <tsimonq2> seriously
[01:54] <tsimonq2> :D
[02:14] <pleia2> tsimonq2: thanks!
[02:15] <tsimonq2> pleia2: the EXCESSIVE use if the & sign is bugging me, as soon as you save it on the wiki, I'm fixing it
[02:15] <tsimonq2> :P
[02:16] <tsimonq2> *of
[02:16] <pleia2> saved
[02:16] <tsimonq2> YAY!
[02:16] <tsimonq2> 7. of. them.
[02:17] <tsimonq2> saved
[02:17] <pleia2> Unit193: link check? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue457
[02:18] <Unit193> Aha, great timing.
[02:18] <pleia2> :D
[02:18]  * tsimonq2 also checks links
[02:19] <Unit193> pleia2: You're good.
[02:19] <pleia2> thanks :)
[02:20] <tsimonq2> FWIW same here
[02:21] <pleia2> ok, sent off to editors
[02:21] <pleia2> now I get to go fold laundry
[02:22] <tsimonq2> pleia2: voluntell your cat to help XD


[16:00] <roaksoax> o/
[16:00] <arosales> hello
[16:00] <hallyn> o/
[16:01] <zul> heylo
[16:01] <lynxman> o/
[16:01] <smb> \o
[16:01] <jimbaker> hi
[16:01] <roaksoax> #startmeeting
[16:01] <meetingology> Meeting started Tue May 29 16:01:44 2012 UTC.  The chair is roaksoax. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:01] <Daviey> hey-ol-a
[16:02] <roaksoax> so let's get started
[16:02] <roaksoax> [TOPIC] Review ACTION points from previous meeting
[16:02] <utlemming> o/
[16:02] <roaksoax> zul talk to arosales and jamespage offline about SRU tracker
[16:02] <zul> in progress
[16:02] <roaksoax> zul: any updates about the SRU tracker?
[16:02] <arosales> roaksoax: I am syncing up with zul and jamespage
[16:02] <arosales> deciding on which tool to use
[16:03] <arosales> zul or possibly Ursinha's
[16:03] <arosales> so in progress
[16:03] <roaksoax> arosales: awesome!
[16:03] <jamespage> o/
[16:03] <Ursinha> we're talking about it tomorrow :)
[16:03] <roaksoax> [ACTION] zul to sync up with arosales and jamespage.
[16:03] <meetingology> ACTION: zul to sync up with arosales and jamespage.
[16:03] <roaksoax> zul: zul to also pull Ursinha into SRU tracker talks --> I'm guessing that's stillk in progress too
[16:03] <arosales> roaksoax: correct :-)
[16:04] <zul> yay
[16:04] <roaksoax> alright, let'/s move on
[16:04] <roaksoax>  email arosales/Daviey if interested in ubuntu-mir membership
[16:04] <roaksoax> who's displayed their interes in becoming part of the ubuntu-mir team?
[16:04] <roaksoax> or should the question be, have all the interested people emailed arosales and/or Daviey ?
[16:04] <arosales>  I am also sync'ing up with Ursinha on blueprint management (ie tracking blueprint changes)
[16:05] <hallyn> ruh roh
[16:05] <arosales> I didn't receive any mails on interest for ubuntu-mir team
[16:05] <Daviey> me neider
[16:05] <roaksoax> alright, so people I believe you have a chance to offer yourselves and become part of the ubuntu-mir team
[16:06] <Daviey> lets defer it again.
[16:06] <roaksoax> moving on
[16:06] <arosales> roaksoax: can we give it one additional week for follow up and then close on it next week?
[16:06] <roaksoax> arosales: sure!
[16:06] <arosales> thanks
[16:06] <roaksoax> [ACTION] email arosales/Daviey if interested in ubuntu-mir membership
[16:06] <meetingology> ACTION: email arosales/Daviey if interested in ubuntu-mir membership
[16:06] <roaksoax> alright, moving on
[16:07] <roaksoax> [TOPIC] Quantal Development
[16:07] <roaksoax> Release Bugs - http://reports.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html
[16:07] <roaksoax> bug #888123
[16:07] <roaksoax> jamespage: any updates?
[16:08] <jamespage> nope
[16:08] <jamespage> work on the underlying issue is on hold ATM
[16:08] <roaksoax> ok
[16:08] <roaksoax> bug 974584
[16:08] <jamespage> not mega urgent at this point in time unless someone wants to merge erlang
[16:08] <hallyn> working with debian maintainer
[16:09] <roaksoax> awesome!
[16:09] <roaksoax> bug #920197
[16:09] <roaksoax> zul: any updates?
[16:09] <zul> roaksoax: pending SRU team
[16:10] <roaksoax> awesome!
[16:10] <roaksoax> bug #1001846
[16:10] <roaksoax> we were waiting for more input, and we got it. It should be taken care of this week
[16:10] <Daviey> \o/
[16:11] <roaksoax> bug #880339
[16:11] <roaksoax> still incomplete
[16:11] <roaksoax> comments point to a might be related bug
[16:12] <roaksoax> bug #993291
[16:13] <roaksoax> jamespage: any updates ^^?
[16:13] <jamespage> yeah - I need to take a look at that still
[16:13] <jamespage> so no
[16:13] <roaksoax> alright!
[16:13] <roaksoax> so let's move on to blueprints
[16:13] <roaksoax> Blueprints - http://status.ubuntu.com/ubuntu-precise/ubuntu-server.html
[16:13] <arosales> how are folks doing with getting work items documented?
[16:14]  * rbasak hasn't started yet :-/
[16:14] <rbasak> It's on my todo list
[16:14]  * m_3 too
[16:14] <arosales> The release team would like to start setting topics and tread lines by tomorrow
[16:14] <roaksoax> we also need to update the above link as they quantal BP's are not yet listed
[16:14] <Daviey> So.. Started going through the ones with myself as approver... and they are taking good shape.
[16:14] <Daviey> Still needs a little more detail on some.
[16:14] <smoser> that url above should probably have been http://status.ubuntu.com/ubuntu-quantal/ubuntu-server.html
[16:14] <hallyn> Daviey: note the user-ns and device-ns ones are not yet approved
[16:14] <roaksoax> ah daa
[16:14] <hallyn> (I marked them 'Review')
[16:15]  * roaksoax dumbd
[16:15] <arosales> The list I am looking at for q for server
[16:15] <arosales> https://blueprints.launchpad.net/~ubuntu-server/+specs?role=drafter
[16:15] <arosales> at least for blueprints we need to get work items on, prioritize, and approve for work this cycle
[16:15] <Daviey> The links i supplied in last weeks meeting are probably of use.
[16:16] <roaksoax> ok, so all of us should finish writing our BP's, make sure the WI are docmented so that they can get approved and we can start working on them
[16:16] <Daviey> http://ubuntuserver.wordpress.com/2012/05/23/server-team-20120522-meeting-minutes/
[16:16] <Daviey> Read Quantal Development
[16:16] <roaksoax> Specs currently under consideration are at https://blueprints.launchpad.net/~ubuntu-server/+specs?role=drafter. If a spec is missing, let Daviey know.
[16:17] <roaksoax> Blueprints which $user is responsible for driving to Approved state can be found at https://blueprints.launchpad.net/~$user/+specs?searchtext=servercloud-q&role=assignee. Please set those which require review to Review state.
[16:17] <arosales> So is EOD wednesday too soon to have the blueprints ready for approval?
[16:17] <roaksoax> Yes from my part
[16:17] <roaksoax> s/part/side
[16:17] <m_3> yes
[16:17] <Daviey> Hmm
[16:17] <rbasak> Daviey: can we please get the typo fixed on ubuntuserver.wordpress.com? It's embarrassing. I don't want to be associated with that site!
[16:18] <Daviey> rbasak: Do you want to drive it's migration to ubuntuserver.org, canonical hosted?
[16:18] <Daviey> [ACTION] ^
[16:18] <meetingology> ACTION: ^
[16:18] <roaksoax> [ACTION] rbasak to drive migration to ubuntuserver.org
[16:18] <meetingology> ACTION: rbasak to drive migration to ubuntuserver.org
[16:18] <roaksoax> thank you rbasak :)
[16:18] <Daviey> thanks rbasak
[16:19] <Daviey> So.. Lets re-cap of the process...
[16:19] <arosales> Thursday an better for folks completing blueprint work item documentation?
[16:19] <Daviey> When you think your spec is ready for review, please mark them 'Review'
[16:20] <Daviey> arosales & myself with significant help from jamespage and smoser will either give feedback, or Approve
[16:20] <Daviey> So.. We can start that ASAP.. so please get your blueprints into a state where you can mark them Review ASAP, and we can start getting them rolled out
[16:20] <Daviey> Sound good?
[16:21] <roaksoax> [ACTION] To finish BP documentation and mark them Review
[16:21] <meetingology> ACTION: To finish BP documentation and mark them Review
[16:22] <Daviey> (ASAP :)
[16:22] <roaksoax> so I guess the silence means all of us agree
[16:22] <roaksoax> [ACTION] To finish BP documentation and mark them Review ASAP!
[16:22] <meetingology> ACTION: To finish BP documentation and mark them Review ASAP!
[16:22] <zul> suuuure :)
[16:22] <jamespage> +1
[16:22] <roaksoax> ok, let's move on
[16:22] <arosales> it would be nice for trend line setting, and tracking if we could have the bulk of work item documentation this competed by this week :-)
[16:22] <roaksoax> indeed!
[16:23] <roaksoax> alright, so we also have merges to take care of
[16:23] <roaksoax> [LINK] http://people.canonical.com/~davewalker/delta.html
[16:23] <roaksoax> LINK: http://people.canonical.com/~davewalker/delta.html
[16:23] <roaksoax> please take care of your merges, so go wild and have fun
[16:24] <roaksoax> anyone else has anything to discuss?
[16:24] <Daviey> Please feel free to open sync/merge bugs to track assignment. :)
[16:24] <Daviey> ^ optional
[16:24] <roaksoax> ok, so there doesn't seem to be anything else. Let's move on then
[16:24] <roaksoax> [TOPIC] Ubuntu Server Team Events
[16:25] <roaksoax> any event where we will be particupating that's coming soon?
[16:26] <roaksoax> I guess there isn't
[16:26] <roaksoax> moving on
[16:26] <roaksoax> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[16:26] <roaksoax> hggdh: o/
[16:27] <roaksoax> uhmm it seems that hggdh is not around, so let;s come back t him later
[16:27] <roaksoax> [TOPIC] Weekly Updates & Questions for the Kernel Team (smb)
[16:27] <roaksoax> smb: o/
[16:27] <smb> yessir! :)
[16:27] <smb> Beside of other pieces here and there, a quick test on the libvirt merge and most time spent on trying to reproduce bug 999755 without having a simple test case. This was unsuccessful but since someone posted exactly what was their reproducer I could confirm this to be no problem restricted to VMs. So now I can try out some variations locally.
[16:27] <smb> ..
[16:28] <roaksoax> awesome
[16:28] <roaksoax> smb: anything else you'd like us to be aware of?
[16:29] <Daviey> smb: Anything on the xen front?
[16:29] <smb> smoser, and utlemming are already away of -virtual going away
[16:29] <Daviey> going away?
[16:29] <smb> away -> aware
[16:29] <Daviey> Where is this documented ?
[16:29] <rbasak> It was mentioned at UDS IIRC
[16:30] <smb> Should be somewhere in the uds flavours track
[16:30] <smoser> we were aware.
[16:30] <Daviey> That should probably be documented somewhere more expressive
[16:30] <smoser> but that didn't stop it from breaking things./
[16:30] <smoser> smb spoke to me about it.
[16:30] <smb> Daviey, where would such a place be?
[16:31] <Daviey> smoser: so it's your fault i didn't know?  noted. :)
[16:31] <utlemming> On our side, it is being tracked as Bug #1005551
[16:31] <Daviey> smb: probably -server ML
[16:31] <smoser> well, probably -devel actually.
[16:31] <smoser> its not just -server
[16:31] <rbasak> https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-kernel-version-and-flavors
[16:31] <smb> OK, I can check and send out a specific "warning" about that
[16:32] <utlemming> I'm working on cleaning up the fallout for the build process, but it will require packaing changes and build process changes.
[16:32] <Daviey> smb: thanks!
[16:32] <Daviey> utlemming: if it's significant, better track it on a blueprint :)
[16:33] <utlemming> Daviey: ack
[16:33] <roaksoax> alright, should that be all, let's move on
[16:34] <roaksoax> [TOPIC] Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:34] <roaksoax> rbasak: o/
[16:34] <rbasak> Nothing to report, although you may be interested in some ARM server news: http://www.theregister.co.uk/2012/05/29/dell_copper_arm_server/ . Any questions for me?
[16:35] <roaksoax> i guess there's not
[16:35] <zul> copper is shiney
[16:36] <roaksoax> anotherone hgere : http://www.marketwatch.com/story/dell-unveils-programs-to-enable-the-arm-based-server-ecosystem-and-accelerate-development-and-testing-of-arm-based-applications-and-solutions-2012-05-29
[16:36] <roaksoax> ok, so moving on
[16:36] <roaksoax> [TOPIC] Open Discussion
[16:36] <roaksoax> anyone has anything for us?
[16:37] <smoser> i've got one
[16:37] <roaksoax> I just want to publicly congratulate smoser :)
[16:37] <smoser> rbasak, and i would like to solicit bids for https://bugs.launchpad.net/ubuntu/+source/apt/+bug/972077
[16:37] <Daviey> Yeah... So.
[16:37] <smoser> by solicit bids, i mean "any one interested in doing this ?"
[16:37] <zul> lol
[16:37] <Daviey> Smoser has been declared the Infrastructure team Tech Lead.  Three cheers for smoser
[16:37] <Daviey> o/
[16:37] <zul> yay!
[16:37] <jamespage> \o/
[16:37] <roaksoax> \o/
[16:37] <smb> \o/
[16:37] <Ursinha> :D
[16:37] <jamespage> congrats smoer
[16:37] <smoser> rbasak, is interested, but is time limited, and if someone else wants to take a whack at it, we have an idea of a proof of concept that we'd like to implement
[16:38] <lynxman> \o/
[16:38] <jamespage> or even smoser
[16:38] <Daviey> Now.. Any hard questions related to Infra, please feel free to tax smoser.
[16:38] <Ursinha> congrats smoser
[16:38] <arosales> congrats smoser
[16:38] <lynxman> smoser: you're da man
[16:38] <utlemming> all praise to smoser!
[16:38] <m_3> *\o/*
[16:38] <roaksoax> congrats Mr. Moser
[16:38] <smoser> (yes, thanks for the congrats, NOW BACK TO THE MEETING!)
[16:38] <smoser> :)
[16:38] <Ursinha> lol
[16:38] <SpamapS> hody
[16:38] <SpamapS> howdy even
[16:38] <roaksoax> smoser: Open Discussion :)
[16:38] <Daviey> SpamapS: just in time.
[16:38] <zul> congrats captain oh my captain...my sparkle in my eye
[16:38] <rbasak> congrats smoser!
[16:38] <smoser> so, if anyone would want to take a look at implementing the apt client side of our proposed fix, please feel free to ping me.
[16:39] <jamespage> o/
[16:39] <roaksoax> [ACTION]: Anyone interested in taking care of bug #972077 to ping smoser
[16:39] <meetingology> ACTION: : Anyone interested in taking care of bug #972077 to ping smoser
[16:39] <jamespage> Bug Triage Process - I sent an email to ubuntu-server last week
[16:39] <roaksoax> alright, no other subject to bring to the table?
[16:39] <jamespage> please could people have a read and provide feedback - thanks
[16:40] <rbasak> I think I need to follow the process that jamespage has documented and then make a note of any bugs I get stuck on and why
[16:40] <jamespage> rbasak, that is a fine way to debug it!
[16:40] <rbasak> jamespage: deubg? You want me to file bugs on the triage process? And how should we triage those bugs?
[16:41] <rbasak> :-)
[16:41] <jamespage> lol
[16:41] <roaksoax> lol
[16:41] <roaksoax> alright, if there's nothing more
[16:41] <roaksoax> I guess we can end this
[16:41] <roaksoax> [TOPIC] Announce next meeting date and time
[16:41] <roaksoax> same time/place
[16:41] <roaksoax> (June 5th)
[16:42] <roaksoax> thank you all
[16:42] <roaksoax> #endmeeting
[16:42] <meetingology> Meeting ended Tue May 29 16:42:05 2012 UTC.
[16:42] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-29-16.01.moin.txt
[16:42] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-29-16.01.html
[16:42] <arosales> roaksoax: thanks for chair'ing
[16:42] <roaksoax> my pleasure
[16:43] <jamespage> ttfn
[16:59] <bjf> o/
[16:59] <jsalisbury> #startmeeting
[16:59] <jsalisbury> ##
[16:59] <meetingology> Meeting started Tue May 29 16:59:44 2012 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:59] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:59] <jsalisbury> ## This is the Ubuntu Kernel Team weekly status meeting.
[16:59] <jsalisbury> ##
[16:59] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[16:59] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Precise
[16:59] <jsalisbury> # Meeting Etiquette
[16:59] <jsalisbury> #
[16:59] <jsalisbury> # NOTE: '..' indicates that you are finished with your input.
[16:59] <jsalisbury> #       'o/' indicates you have something to add (please wait until you are recognized)
[16:59] <jsalisbury> Roll Call for Ubuntu Kernel Weekly Status Meeting
[17:00] <ppisati> o/
[17:00] <cking> o/
[17:00] <arges> o/
[17:00] <henrix> o/
[17:00] <kamal> o/
[17:00] <sconklin> o/
[17:00]  * smb rushes in
[17:00] <jsalisbury> [TOPIC] ARM Status (ppisati)
[17:00] <ppisati> Q/omap4: Ubuntu-3.4.0-201.3 is out, with hdmi and jack audio support. Some of the new features (like video and audio offloading to gpu/dsp) will have to wait until 3.5rcX hits master, since we need CMA and dma-map support (already present in linus vanilla).
[17:00] <sconklin> only fools rush in
[17:00] <ppisati> ..
[17:00] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:00] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:00] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:02] <jsalisbury> We can come back to this topic.
[17:02] <jsalisbury> [TOPIC] Status: CVE's (sconklin)
[17:02] <sconklin> == 2012-05-29 (weekly) ==
[17:02] <sconklin> Currently we have 88 CVEs on our radar, with 2 new CVEs added this week.
[17:02] <sconklin> See the CVE matrix for the current list:
[17:02] <sconklin> [LINK] http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:02] <sconklin> Overall the backlog has increased slightly slightly this week:
[17:02] <sconklin> [LINK] http://people.canonical.com/~kernel/status/cve-metrics.txt
[17:02] <sconklin> [LINK] http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt
[17:02] <sconklin> ..
[17:03] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Precise/Oneiric/Natty/Lucid/Hardy (bjf/herton/henrix)
[17:03] <bjf> Here is the status for the main kernels, until today (May  29):
[17:03] <bjf>
[17:03] <bjf>  * Hardy    - 2.6.24-31.101 - No change this cycle
[17:03] <bjf>  * Lucid    - 2.6.32-41.90  - Testing; Single CVE
[17:03] <bjf>  * Natty    - 2.6.38-15.60  - Testing: 7 CVEs
[17:03] <bjf>  * Oneiric  - 3.0.0-21.35   - Verification; 2 stable upstream releases (approx. 111 commits)
[17:03] <bjf>  * Precise  - 3.2.0-25.39   - Verification; 2 stable upstream releases (approx. 271 commits)
[17:03] <bjf>
[17:03] <bjf> Current opened tracking bugs details:
[17:03] <bjf>  * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:03] <bjf>
[17:03] <bjf> For SRUs, SRU report is a good source of information:
[17:03] <bjf>  * http://people.canonical.com/~kernel/reports/sru-report.html
[17:03] <bjf>
[17:03] <bjf> Future stable cadence cycles:
[17:03] <bjf>  * https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock
[17:03] <bjf>
[17:03] <bjf> ..
[17:03] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:04] <kamal> o/
[17:04] <ogasawara> jsalisbury: o/
[17:04] <jsalisbury> kamal, go ahead
[17:04] <kamal> An old colleague of mine, Dave Taht, is a member of the http://www.bufferbloat.net/ group.  Some of their work will be landing in the 3.5 kernel (codel and fq_codel - a new active TCP queue management algo).
[17:04] <kamal> Dave would like to be in contact with someone on the Ubuntu kernel team to talk about configuration and usage issues for that stuff.  Shall I direct him to anyone in particular?  Is there a networking point-person?
[17:04] <kamal> ..
[17:05] <apw> kamal, i'd say just get him to send email to kernel-team@
[17:05] <tgardner> kamal, he can start with me or apw
[17:05] <tgardner> kernel-team@ works as well
[17:05] <kamal> ok, two names + the kernel-team@ list   :-)    that'll do  :-)  thanks.
[17:05] <tgardner> ..
[17:05] <jsalisbury> ogasawara, shall I move back to your topics?
[17:05] <ogasawara> jsalisbury: yes please
[17:06] <jsalisbury> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:06]  * ogasawara had a bit of a crisis
[17:06] <ogasawara> [LINK] http://status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team-quantal-alpha-1.html
[17:06] <ogasawara> || apw         || hardware-q-kernel-config-review || 4 work item   ||
[17:06] <ogasawara> ||             || hardware-q-kernel-delta-review  || 3 work items  ||
[17:06] <ogasawara> ||             || hardware-q-kernel-versions-and-flavors || 1 work item ||
[17:06] <ogasawara> || smb         || hardware-q-kernel-config-review || 1 work item   ||
[17:06] <ogasawara> ||             || hardware-q-kernel-delta-review  || 1 work item   ||
[17:06] <ogasawara> || ppisati     || hardware-q-kernel-config-review || 1 work item   ||
[17:06] <ogasawara> || jk-         || hardware-q-kernel-config-review || 2 work items  ||
[17:06] <ogasawara> || ogasawara   || hardware-q-kernel-config-review || 1 work item   ||
[17:06] <ogasawara> ||             || hardware-q-kernel-delta-review  || 1 work item   ||
[17:06] <ogasawara> || cking       || hardware-q-kernel-delta-review  || 3 work items  ||
[17:06] <ogasawara> || jjohansen   || hardware-q-kernel-config-review || 2 work item   ||
[17:06] <ogasawara> || kernel-team || hardware-q-kernel-config-review || 10 work items ||
[17:06] <ogasawara> ||             || hardware-q-kernel-versions-and-flavors || 2 work items ||
[17:06] <ogasawara> If your name is in the above table, please review your Alpha-1 work
[17:06] <ogasawara> items.  If anyone has a spare cycle, feel free to take one of the work
[17:06] <ogasawara> items assigned to the team.
[17:06] <ogasawara> ..
[17:06] <ogasawara> Last week we uploaded the 3.4.0-3.8 Quantal kernel.  This included an
[17:06] <ogasawara> updated AppArmor patch set and misc config updates and bug fixes.
[17:06] <ogasawara> Please note that Alpha-1 is next Thurs June 7.  I'll intend to upload a
[17:06] <ogasawara> final Alpha-1 kernel early next week, ie Monday.
[17:06] <ogasawara> We've also began providing the 12.10 kernel for 12.04.  We welcome any
[17:06] <ogasawara> early adopters to plaes install, test, and let us know your feedback.
[17:06] <ogasawara> It is available from the following PPA:
[17:06] <ogasawara> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[17:06] <ogasawara> Important upcoming dates:
[17:07] <ogasawara>  * Thurs Jun 7 - Alpha 1 (~2 weeks)
[17:07] <ogasawara> ..
[17:07] <ogasawara> s/~2 weeks/~1 week/
[17:07] <jsalisbury> Anything from anyone else?
[17:07] <jsalisbury> Thanks everyone
[17:07] <jsalisbury> #endmeeting
[17:07] <meetingology> Meeting ended Tue May 29 17:07:51 2012 UTC.
[17:07] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-29-16.59.moin.txt
[17:07] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-29-16.59.html
[17:07] <cking> thanks jsalisbury
[17:08] <kamal> thanks jsalisbury
[17:08] <herton> jsalisbury, thanks