[02:08] <peepsalot> anyone have an idea how to deal with unresponsive byobu on a server?  it seems to have frozen and unfortunately I have run byobu-enable so it always loads into byobu session(and hangs) when I attempt to logon.  is there anything i can do without rebooting?
[02:10] <peepsalot> gah, nevermind it became responsive again, after 10minuts or something.  really weird
[02:15] <ra> peepsalot, you could get the pid in top or htop and kill the process, then restart. i use tmux
[02:16] <peepsalot> the thing was I couldn't get into any shell at the time when it was frozen
[02:17] <peepsalot> also afaiui byobu is just a frontend for tmux anyways
[02:23] <ra> ctrl-f6 should force kill a window
[02:31] <JanC> byobu is a configuration for tmux or screen
[02:32] <JanC> calling it a frontend is technically wrong  :)
[02:33] <JanC> and my guess would be that something was delaying login or something like that?
[02:33] <JanC> or shell startup?
[02:34] <JanC> or the system was overloaded
[02:35] <JanC> peepsalot: ^^^
[02:38] <peepsalot> well, i do keep it busy with work: 49.94 load on 48 threaded cpu(s) :)    but i've never noticed any responsiveness issues like that before
[02:39] <peepsalot> it happened while I was in the middle of doing a search of scrollback in a tmux window
[02:40] <peepsalot> which only keeps 100k lines in the worst case
[02:41] <JanC> I/O overload can do that, I guess, or when you get into a swap storm
[02:41] <peepsalot> 0 swap usage though, i got ram to spare
[02:42] <peepsalot> only about 33% ram used
[02:42] <JanC> if you were logged in remotely, it could also have been a network issue
[02:44] <ra> peepsalot, you might try byobu-disable and start it from the terminal to see if the hang reproduces that way
[02:46] <peepsalot> it was over ssh (on my LAN), but even when I went to the physical computer to try logging into virtual console, it was hanging upon login (because that would connect to the same byobu session since that's what "byobu-enable" configures it to do)
[02:47] <JanC> it might be a login/authentication/PAM issue
[02:48] <JanC> I've seen that happen on a heavy I/O load too
[02:51] <peepsalot> well, anyways its better now, not sure I could reproduce it if I tried (i've already been doing more scrollback finds and nothing like that is happening now), just an odd hiccup that hopefully won't occur again soon
[03:05] <ra> peepsalot, re my first reply about the pid, you can alt-f2, alt-f3 to open a new tty and kill the process
[03:09] <peepsalot> ra, i couldn't login from those at the time... because byobu/tmux was stuck churning on something, and login goes directly to byobu session
[03:12] <ra> so try byobu-disable and start it from the terminal to see if that changes anything
[03:14] <ra> peepsalot, but you did try alt-f2?
[03:15] <JanC> login would have to happen before byobu starts on a new virtual console
[04:34] <kinghat> is my zfs mirror pool mounting automatically to the server?
[04:36] <kinghat> what i mean is i can see its mount point and its working fine but i dont see it setup in my fstab.
[04:38] <kinghat> and i just added another drive to the system and formatted it to ext4 and it shows up in the disk list, im guessing i need to manually give it a mount point?
[06:07] <blackflow> kinghat: ZFS doesn't use fstab unless you explicitly set up mountpoints in legacy mode. zfs-mount.service mounts datasets that aren't in legacy mode.
[15:25] <kinghat> so I would just need to make it auto mount manually?
[15:30] <tomreyn> if you're alking to someone specifically, be sure to mention their nickname.
[15:30] <tomreyn> otherwise, provide context.
[15:41] <kinghat> tomreyn: nobody in particular and its just an added drive to my server. i had forgotten how my pool was mounted since it was set and forget.
[15:42] <kinghat> since i dont think i will be adding the drive to the pool and just using it for backup i need to figure out how to get it to auto mount like a regular drive
[15:43] <kinghat> unless zfs also does backup stuffs?
[15:58] <blackflow> kinghat: you're asking confusing questions.
[15:59] <kinghat> probably
[15:59] <blackflow> ZFS datasets are mounted either by zfs-mount.service -- which looks at datasets mountpoint attribute -- or by legacy mounts via fstab (for which mountpoint=legacy at the dataset attribute)
[16:00] <kinghat> ya im guessing mines via zfs-mount.service.
[16:00] <blackflow> so if you want a dataset mounted, you should specify its mountpoint= attribute. if it's "legacy", then you need to use fstab.
[16:01] <kinghat> i have a zfs mirror pool that is mounted and working fine. i added another drive, formatted it and noticed it doesnt automatically have a mount point.
[16:01] <blackflow> kinghat: "formatted it" ?
[16:01] <kinghat> i think i want to use the drive as a backup drive that gets backed up to from multiple locations everyday.
[16:02] <blackflow> you're not answering my questions. how did you "format" the drive (the terminology doesn't exist for ZFS)
[16:02] <kinghat> blackflow: i did mkfs.ext4 /dev/sdc
[16:02] <blackflow> and that has to do with your ZFS questions... what? lol
[16:02] <kinghat> it was previously formatted with ntfs
[16:04] <blackflow> so if you want an ext4 filesystem mounted at boot, you need to add it to fstab.
[16:04] <kinghat> it doesnt. i was confused as to why/how the zfs pool/drives were mounted as i couldnt remember setting them up. i just addeded a drive, formatted it, and noticed its not auto mounted anywhere on the system.
[16:04] <kinghat> yes
[16:04] <blackflow> fstab or write a proper systemd .mount unit  (fstab is converted to them at run time anyway)
[16:04] <kinghat> figured thats what i needed to do something like that.
[16:06] <blackflow> ZFS is a completely different beast from traditional filesystems. It's a whole fs+volumes+raid+snapshots+compression+encryption+.... kind of kitchen sink solution, with a set of services, its own specific concepts and idisyncrasies
[16:07] <blackflow> ext4 is just a passive filesystem, nothing else, no services, no volume management, no raid, but latest versions methinks can do encryption.
[16:30] <kinghat> blackflow: if i didnt want to add the new drive as a 3rd mirror and wanted to use it as a backup drive, does zfs have something for that as well or just use something like rsync?
[16:34] <blackflow> kinghat: you can send ZFS snapshots at block-level to another drive, or over the network to <wherever>
[16:34] <kinghat> what if im sending other data from another drive to said backup drive?
[16:35] <kinghat> as well*
[16:35] <blackflow> kinghat: but consider what you're asking. if you're gonna add a third drive to the same chassis, that's hardly a backup. you can add a hot spare to your existing pool, or simply increase redundancy by creating a 3-way mirror
[16:35] <blackflow> you can rsync files from other filsystems, and use zfs snapshots send|recv for ZFS filesystems
[16:36] <blackflow> snapshots are moved between datasets, so you can have   rpool/backups-for-zfs ,   rpool/backups-for-others     and then you send|recv to backups-for-zfs, and use rsync under backups-for-others
[16:37] <RoyK> kinghat: something like this? https://xkcd.com/1718/
[16:46] <kinghat> lel


[08:02] <tjaalton> is everyone on ~ubuntu-archive able to ack packages from NEW?
[08:54] <apw> they have the priviledge (afaik) but they would be expected to only ack thinks they feel confident reviewing
[09:51] <tjaalton> ok
[11:20] <jamespage> arges, hey the kilo stable update for vivid is ready to go apart from https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1451691
[11:20] <jamespage> I'd really like to get it out today if possible
[13:25] <arges> jamespage: k i'll take a look
[13:39] <arges> jamespage: did you verify bug 1381450 ?
[13:40] <jamespage> arges, lemme check
[13:48] <jamespage> arges, yeah - that's good as well
[13:49] <arges> jamespage: cool.
[13:56] <jamespage> arges, urh - I just noticed that build failure on trove
[13:57] <arges> jamespage: yikes, did you just re-upload/rebuild?
[13:58] <jamespage> arges, i think it was a racey test - I hit rebuild to check
[13:58] <jamespage> arges, tbh we can hold back on designate and trove if you want
[13:58] <jamespage> arges, https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1451691 will fixup the ftbfs for designate
[13:59] <arges> jamespage: ok. plus trove has only been in -proposed for 4 days.
[14:14] <arges> jamespage: can you check through bug 1449744. openstack-trove/designate were skipped
[14:14] <arges> jamespage: can you ensure manila, neutron-vpnaas are released in wily too?
[14:15] <jamespage> arges, yes - I'll get zul todo whatever he did with the others
[16:57] <sil2100> Hello release team! I temporarily disabled the image importer, I want to release a new ubuntu-touch image


[00:24] <Ponch0> hey guys so I installed 13.04 gnome remix, I added a ppa for the new gnome web browser - did sudo update & and upgrade - and gdm wouldn't start being a noob that I am, I had to reinstall - in that case what are my options? I was able to get into the terminal with f1
[00:25] <Ponch0> gdm wouldn't start after restart that is.
[00:25] <Ponch0> i had the mouse cursor
[00:26] <darkxst> Ponch0, did you use 'dist-upgrade'?
[00:27] <Ponch0> Also - one more question - what is a staging PPA I can add that will keep me up to date with gnome 3 staging
[00:27] <Ponch0> nope just 'upgrade'
[00:27] <darkxst> Ponch0, you must do 'dist-upgrade'!
[00:27] <Ponch0> that will keep me up to date with gnome 3 updates without adding that unity gunk.
[00:27] <darkxst> staging ppa is for things that still have regressions and/or known issues
[00:27] <Ponch0> oh than the 'stable' ppa?
[00:28] <Ponch0> oops on the upgrade - good to know for future reference I probably installed lightdm and there was some type of conflict.
[00:28] <darkxst> Ponch0, just run it now, it should fix things
[00:28] <Ponch0> I already reinstalled the system I have to set everything up again hehe.
[00:29] <darkxst> oh
[00:29] <Ponch0> I couldn't get on the computer to look up what I could do - it was my only option.
[00:29] <Ponch0> I couldn't get to the part where it asked me for login.
[00:31] <Ponch0> so is there a PPA I could add that will add the stable gnome apps - it seems pretty bare which I guess isn't a bad thing.
[00:31] <Ponch0> and stable updates? or is that already covered?
[00:31] <darkxst> Ponch0, gnome3 PPA is stable
[00:31] <Ponch0> and if I add that - it won't mess up my install with some unity gunk right?
[00:32] <darkxst> Ponch0, why would we have unity gunk in a gnome3 ppa?
[00:33] <Ponch0> lol because somehow I just ended up without being able to log in by just adding the gnome web browser ppa
[00:33] <Ponch0> but now I know that wasn't the reason.
[00:35] <Ponch0> darkxst: anyway thank you for answering my seemingly silly questions.
[00:36] <darkxst> np
[00:39] <Ponch0> so a quick recap - I should never do "sudo apt-get update && sudo apt-get upgrade" but rather "sudo apt-get update && sudo apt-get dist-upgrade"??
[01:01] <darkxst> jbicha, ok to copy updated g-c-c to staging?
[01:06] <jbicha> darkxst: I didn't test it, but I trust your judgment
[01:06] <jbicha> you have to have a hard-coded list of possible external panels?
[01:07] <darkxst> that is only for the launchers
[01:07] <jbicha> and things work fine if those external panels aren't installed?
[01:07] <darkxst> actual .so panels get loaded dynamically.
[01:08] <darkxst> jbicha, sure, it will just ignore any entry it can't find the desktop file for
[01:12] <darkxst> the only other alternative was to bring back the gmenu code, and scan all desktop files.
[01:13] <darkxst> and that is overly complicated and messy code.
[01:14] <jbicha> it might be better; that way we can tell apps that only provide external launchers to ship a separate .desktop with NotShowIn=Unity; and the settings panel with NotShowIn=GNOME;
[01:14] <jbicha> gufw (gui-ufw) is another one
[01:15] <jbicha> myunity was one but that only lasted a few months
[01:21] <darkxst> yeh I got gufw in the patch already
[01:22] <jbicha> oh it doesn't need to be renamed to match the new naming convention?
[01:26] <darkxst> no, launchers dont need to have a specific name format, since they are just read from the list.
[01:31] <jbicha> ok
[01:36] <jbicha> darkxst: there's an interesting patch at https://bugzilla.gnome.org/show_bug.cgi?id=692253 I don't think I'll be able to look into it at the moment
[01:56] <jbicha> darkxst: you're not on saucy yet are you?
[01:56] <darkxst> yeh
[01:57] <jbicha> I might have broken gnome-shell 3.6 by uploading gjs today
[01:58] <darkxst> gjs 1.36?
[01:58] <jbicha> yes
[01:58] <darkxst> 3.6 works fine with that, however there was one redundant line in the JS that needed to be removed
[01:58] <darkxst> not sure if that was fixed upstream
[02:02] <darkxst> jbicha, http://paste.ubuntu.com/5621204/
[02:04] <jbicha> darkxst: do you want to make a debdiff for that?
[02:04] <darkxst> sure
[02:10] <darkxst> jbicha, http://pastebin.com/rutneiZR
[02:15] <jbicha> cool, gnome-control-center works
[02:21] <jbicha> darkxst: thanks, good night
[02:22] <darkxst> np, good night
[04:32] <Ponch0> Hello, so my ubuntu software center is crashing again, I cannot open it or rather I open it and it immediately closes. So i purged it and tried to reinstall it - here's what popped up and i'm not sure what it means http://pastebin.com/TxD80K9D
[07:33] <darkxst> ricotz, are we using gnome region panel (or language selector) in 3.6 g-c-c? I don't remember
[10:37] <user> Please help me. How can I install ubuntu gnome with efi?
[11:47] <Mattish91> hello
[11:47] <Mattish91> any one else but me who got troubbles with gnome updates_
[11:47] <Mattish91> ?|
[11:48] <Mattish91> hello?
[11:49] <Mattish91> anyone here??
[11:49] <darkxst> what troubles?
[11:49] <darkxst> did you do a dist-upgrade?
[11:50] <Mattish91> Yes, and then updated gnome to gnome 3.8
[11:50] <Mattish91> now i cant login due to a gnome error
[11:50] <darkxst> can you paste the error?
[11:50] <Mattish91> its just Cant load gnome
[11:51] <Mattish91> so i wont be able to login
[11:51] <darkxst> and you did a 'apt-get dist-upgrade' after installing the ppa?
[11:52] <Mattish91> yes
[11:52] <Mattish91> also apt-get update
[11:52] <Mattish91> before
[11:52] <darkxst> Mattish91, I need to see logs
[11:52] <Mattish91> how do i get those? im on a live usb atm
[11:52] <darkxst> ~/.cache/gdm/session.log
[11:53] <Mattish91> ok 1 sec
[11:53] <darkxst> /var/log/gdm/*
[11:54] <Mattish91> im not allowed to see any logs in that folder, should i change the permissions?
[11:54] <darkxst> sudo -s
[11:55] <Mattish91> the folder is empty :S
[11:55] <darkxst> are you using gdm?
[11:57] <Mattish91> yes, i had to update the folder :S
[11:57] <Mattish91> what file did you need?
[11:57] <darkxst> start with :0-greeter.log
[11:57] <Mattish91> can i send that file or do i need to copy it?
[11:58] <darkxst> Pastes to http://paste.ubuntu.com
[11:58] <darkxst> also ~/.cache/gdm/session.log (if things got that far)
[11:59] <Mattish91> :o-greeter.log http://paste.ubuntu.com/5622390/
[12:00] <darkxst> could be a glx problem, what graphics card do you have?
[12:00] <Mattish91> Nvidia Geforce gt 555M
[12:01] <darkxst> nvidia blob or nouveau?
[12:02] <Mattish91> have no idea
[12:02] <Mattish91> what does that mean? :P im from sweden, im sorry :P
[12:03] <darkxst> propriety driver? or open source driver?
[12:04] <Mattish91> i dont know, havn't been asked to install any graphics driver, i guess open source then?
[12:04] <darkxst> probably
[12:05] <darkxst> try install 'nvidia-current'
[12:05] <Mattish91> is there any way to install drivers from a live usb or do i have to re install? it doesnt matters what i do, i dont have anything important in the distro.
[12:06] <darkxst> sudo apt-get install nvidia-current
[12:06] <darkxst> then reboot
[12:06] <Mattish91> well i got E: Unable to locate package nvidia-current
[12:08] <darkxst> oh you might need to enable multiverse or something
[12:08] <Mattish91> ok
[12:10] <Mattish91> multiverse should be enabled, still got E: Unable to lacate package nvidia-current
[12:11] <darkxst> sorry its in restricted
[12:11] <Mattish91> now it's working,restarted terminal and got it installing
[12:12] <Mattish91> thanks for your help, ill try to restart now then :)
[16:12] <sweeze> anyone having trouble getting empathy to connect to aim/yahoo (haze) accounts w/ the staging ppa enabled? ( https://bugs.launchpad.net/ubuntu-gnome/+bug/1174369 )
[16:21] <FrozenFire> Is it possible to disable notifications of Empathy contacts coming online/going offline?
[16:22] <FrozenFire> That's my biggest beef with Empathy and the notification system on gnome-shell, because the notification area blocks the most important part of my screen.


[05:24] <Mirv> hmm why does my updated mako just flickr and crash unity8...
[05:36] <Mirv> (54)
[07:07] <didrocks> hey Mirv, how was your week-end?
[07:27] <Mirv> hi didrocks, fine (and long!)
[07:27] <didrocks> heh, I hope you enjoyed your Friday!
[07:27] <didrocks> did you go outside?
[07:27] <didrocks> like, were they fireworks and such?
[07:30] <Mirv> I did go outside, but not that far away. there aren't permissions for "fireworks at will" (like in the New Year), so there would have been only some in some more official festivities places.
[07:31] <didrocks> yeah, I guess so… ;)
[07:33] <didrocks> Mirv: did you suffer from issues with latest upstart-app-launch?
[07:33] <didrocks> Mirv: there is an ABI transition, so it should have picked other packages as well
[07:37] <Mirv> didrocks: so it seems I have some other problem, I just have unity8 flickering and crashing when I try to open it.
[07:37] <Mirv> even after I downgraded the upstart-app-launch
[07:37] <Mirv> and yes upstart-app-launch has the bump now
[07:39] <Mirv> maybe a time for phablet-flash -b to be sure I'm seeing this on image 54
[07:41] <didrocks> Mirv: yeah, sounds like a phablet-flash -b time :)
[07:41] <didrocks> can you keep me posted?
[07:41] <didrocks> Mirv: FYI, I just reuploaded an url-dispatcher for the soname libupstart change
[07:41] <didrocks> Mirv: we don't want the hazardous commit in :)
[08:53] <Mirv> ok full flash seems to fix whatever problem I had
[08:56] <sil2100> Mirv: ok, good to know - my device is still flashing
[08:58] <didrocks> FYI, I've uploaded url-dispatcher from sil2100's branch and disabled automatic rebuilds
[08:59] <sil2100> didrocks: thanks!
[08:59] <sil2100> didrocks: hm, maybe we should change the driver of content-hub btw.?
[08:59] <sil2100> didrocks: since from what I see only Ken has the power to top-approve there right now, which is tragic ;/
[08:59] <didrocks> sil2100: yeah, sounds legit, we will need to ping Ken for it
[09:14] <sil2100> didrocks: do you think it would be wise to switch the driver now to phablet-team (for now), I can do the switch and move trunk to that team so we can approve the ted's branch
[09:22] <didrocks> sil2100: that would be good, but we need Ken to change the driver
[09:22] <sil2100> didrocks: why? I see I can do that as well on LP, strangely
[09:23] <didrocks> sil2100: oh, if you can, please do then :)
[09:25] <Mirv> sil2100: didrocks: if I recall correctly, the driver doesn't actually matter that much, the only thing that matters is that under which user/team the trunk branch is set to be pushed
[09:26] <didrocks> Mirv: yeah, I guess it is the case
[09:26] <sil2100> didrocks: I re-target ted's branch in a moment as well!
[09:27] <didrocks> great ;)
[09:28] <sil2100> didrocks: can you approve? Would feel silly to do it myself ;p https://code.launchpad.net/~ted/content-hub/ual2/+merge/198210
[09:29] <didrocks> done
[09:38] <Mirv> sil2100: I can also run all of the upstart-app-launch tests if you have other stuff to do, since I'm relatively far already
[09:39] <sil2100> Mirv: my device is free right now, so if there are some big tests that you still didn't run, I can pick those up
[09:40] <popey> didrocks: FOUND IT!
[09:40] <popey> https://bugs.launchpad.net/unity-mir/+bug/1234538
[09:40] <didrocks> popey: ok, sounds like the same bug that is getting to be fixed by upstart-app-launch, let's cross fingers :)
[09:40] <Mirv> sil2100: well click tests are todo, there are some slow ones there.. dropping_letters_app ubuntu_rssreader_app calendar_app music_app ubuntu_terminal_app ubuntu_clock_app ubuntu_calculator_app ubuntu_weather_app ubuntu_filemanager_app ?
[09:40] <Mirv> I'm running unity8 + webbrowser, they're quite slow
[09:40] <popey> bug 1243665 also related
[09:41] <popey> so yeah
[09:41] <popey> hope so
[09:41] <Mirv> all others run so far
[09:41] <sil2100> Mirv: ok, then I'll prepare for some click-package testing to make things move faster
[09:43] <Mirv> updating landing plan as I go
[10:07] <sil2100> Mirv: doing the same, working now on calendar-app
[10:14] <sil2100> hmmm, many calendar-app failures, re-running to make sure what's up
[10:22] <Mirv> sil2100: I've now finished running all except those click tests I listed. so when/if you're happy with your results (compared to the dashboard), feel free to publish
[10:22] <Mirv> sil2100: I tend to re-run those single failing tests to see if they work alone
[10:22] <sil2100> Mirv: could you run calendar-app tests on your device?
[10:22] <Mirv> instead of rerunning the whole suite over and over
[10:22] <Mirv> sil2100: ok, doing in a moment
[10:23] <sil2100> Mirv: yes, but here I get 14 failures, that's like almost all tests
[10:32] <sil2100> Mirv: all the other tests look good so far
[10:33] <sil2100> Mirv: hm, filemanager also resulted with a lot of tests
[10:33] <sil2100> Mirv: it looks to me that sometimes it is unable to start the app for testing, resulting with only a white screen instead of the application
[10:34] <sil2100> Mirv: do you have the same on your device?
[10:34] <sil2100> Re-running the test usually fixes the issue
[10:35] <sil2100> Not sure if this can be upstart related?
[10:35] <sil2100> didrocks: ^
[10:36] <sil2100> The tests are then failing with: "RuntimeError: Could not find autopilot interface for click package 'com.ubuntu.filemanager_filemanager_<IP_ADDRESS>' after 10 seconds." and there is a white screen on my device
[10:40] <didrocks> sil2100: really weird, doesn't sounds like upstart, right?
[10:40] <didrocks> sil2100: did you try to downgrade?
[10:41] <sil2100> didrocks: yes, running the tests with content-hub downgraded, should have results soon
[10:41] <sil2100> I mean
[10:41] <sil2100> upstart
[10:41] <sil2100> ....
[10:45] <Mirv> sil2100: I got only 2 failures in calendar-app
[10:46] <sil2100> Ok...
[10:47] <Mirv> sil2100: and no I haven't seen white screen instead of application kind of thing. now running filemanager.
[10:47] <Mirv> I simply ran phablet-config autopilot --dbus-probe enable + phablet-click-test-setup + phablet-test-run now for these click tests
[10:47] <sil2100> Mirv: I see it's unrelated, with downgraded upstart I see the same ;/
[10:48] <sil2100> Mirv: I would say, let's release
[10:49] <Mirv> sil2100: well I'll run this test still and since everything seems to be fine at here end, I'll release after that?
[10:49] <sil2100> Indeed :) Thanks!  I guess all other tests went fine here, not counting those times I had to re-run in the white-screen case
[11:10] <Mirv> didrocks: 3 failures, same as #54. so publishing now.
[11:11] <sil2100> \o/ upstart-app-launch, content-hub and unity-mir + the url-handler that's in daily-release
[11:11] <sil2100> I mean
[11:11] <sil2100> url-dispatcher
[11:11] <Mirv> didrocks: or actually, after this http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Misc./job/cu2d-misc-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_upstart-app-launch_0.3+14.04.20131209-0ubuntu1.diff
[11:11] <sil2100> Damn, so many typos today...
[11:16] <didrocks> Mirv: did you check that there is no common files shipped between -1 and -2?
[11:17] <didrocks> Mirv: I'm afraid the -dev are shipping the same files without replaces:, right?
[11:17] <didrocks> oh, nm, there is the replaces
[11:17] <didrocks> Mirv: +1 then
[11:18] <didrocks> Mirv: remember that url-handler needs to be uploaded manually
[11:18] <didrocks> url-dispathcer*
[11:18] <sil2100> ;)
[11:21] <didrocks> Mirv: still around?
[11:21] <didrocks> sil2100: in case, can you publish them?
[11:21] <sil2100> didrocks: sure, what should I do with url-dispatcher though?
[11:21] <didrocks> I think we are already really late to get something promoted tonight
[11:21] <didrocks> sil2100: I'll upload it
[11:22] <Mirv> didrocks: ok, thanks, but sil2100 is apparently doing it now
[11:23] <sil2100> content-hub and unity-mir I publish as well
[11:24] <Mirv> sil2100: thanks!
[11:24] <Mirv> url-dishandler
[11:24] <sil2100> didrocks: as a formality: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Unity8/job/cu2d-unity8-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-mir_0.2+14.04.20131209-0ubuntu1.diff and http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Services/job/cu2d-services-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_content-hub_0.0+14.04.20131209.1-0ubuntu1.diff ACKed? :)
[11:25] <didrocks> sil2100: +1
[11:26] <sil2100> Ok, published, just url-dispatcher left - but I guess didrocks has it covered already
[11:26] <didrocks> uploaded
[11:38] <didrocks> sil2100: I don't see content-hub
[11:41] <sil2100> didrocks: oh, hm, stack is red, wait
[11:41] <sil2100> Shit
[11:41] <didrocks> sil2100: can we ensure we look at the stacks when publishing them? ;)
[11:41] <didrocks> so that we don't end up in situations where things are not published
[11:41] <didrocks> (or looking at -changes)
[11:41] <sil2100> but but it rarely ever happens that suddenly cu2d reds our a force publish
[11:42] <sil2100> bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/content-hub/" and relative path "../../../+branch/content-hub/"
[11:42] <didrocks> yeah, but better to care rather than being worry
[11:42] <Mirv> sil2100: that error is maybe because of the content-hub owner?
[11:42] <didrocks> seems like it can't merge back?
[11:42] <sil2100> Is it because of my re-targetting branch?
[11:42] <Mirv> "The lp-propose command returned an error."
[11:42] <didrocks> probably yeah
[11:42] <sil2100> Will a redeploy of the stack help?
[11:43] <didrocks> sil2100: depends, does the bot and you have access right to the redeploy one?
[11:43] <didrocks> retargeted*
[11:43] <sil2100> The retargetted one is in ~phablet-team, so it should be fine
[11:43] <didrocks> ok, so redeploy
[11:43] <didrocks> with -U
[11:43] <didrocks> not -US
[11:46] <sil2100> didrocks: if I force-publish content-hub from the stack now after the redeployment, it won't force a rebuild of the package, just push the one that's in the PPA now, right?
[11:47] <didrocks> sil2100: yep
[11:51] <sil2100> didrocks: ok, this time it went through
[11:51] <sil2100> didrocks: noting down to make sure stacks get published when publishing
[11:55] <didrocks> sil2100: thanks!
[12:06] <cjwatson> Mirv: Could you re-trigger https://code.launchpad.net/~canonical-qt5-edgers/+recipe/ubuntu-keyboard-daily-qt52 ?  I'd like to see how it gets on with the new chroot.
[12:14] <Mirv> cjwatson: retriggered... after ~15 reloads (LP timeouts on recipe pages are really bad)
[12:14] <Mirv> https://code.launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+recipebuild/603481
[12:15] <cjwatson> thanks, let's see
[12:18] <sil2100> Mirv: oh! You haunted by this as well?
[12:19] <Mirv> cjwatson: looks good now!
[12:19] <Mirv> sil2100: dejavu... :D
[12:20] <cjwatson> Mirv: excellent
[12:21] <cjwatson> so just stupid handling of forced removals of packages in the chroot, not failed :any support at all
[12:22] <Mirv> ok then. this is at a good time since I'm about to have a lot more recipe builds against Qt 5.2 right now, and others might have been affected as well.
[12:24] <Mirv> sil2100: I'd guess your similar issue might be resolved now too
[12:27] <sil2100> Mirv: yay, although it's no longer an issue, the guys found a workaround for that
[12:30] <didrocks> cjwatson: hum, I'm not really sure to understand something in the build-dep wait
[12:30] <didrocks> https://launchpad.net/ubuntu/+source/url-dispatcher/0.1+14.04.20131209.1-0ubuntu1/+build/5317569
[12:31] <didrocks> -> but rmadison libupstart-app-launch2-dev
[12:31] <didrocks> says it's published in -proposed
[12:31] <didrocks> I'm sure I'm missing an obvious typo mistake…
[12:31] <cjwatson> it's in universe
[12:31] <didrocks> oh right
[12:31] <cjwatson> url-dispatcher source is in main and can only use binaries in main
[12:31]  * didrocks promotes
[12:31] <didrocks> yeah yeah
[12:31] <didrocks> sorry for the ping
[12:31] <cjwatson> I'll move it
[12:32] <didrocks> thanks cjwatson :)
[12:32] <cjwatson> it should auto-retry (eventually)
[12:33] <cjwatson> oh dear, why the new build-dep on liblttng-ust-dev?
[12:33] <didrocks> I guess it's a question for tedg once he's around
[12:34] <cjwatson> that'll need to be made architecture-specific - see "apt-cache showsrc ust | grep ^Architecture"
[12:34] <cjwatson> (please don't make it [!arm64] - make it a subset of the positive architectures supported by ust instead)
[12:35] <didrocks> oh, so we'll have url-dispatcher blocked in proposed I guess?
[12:36] <didrocks> as it will be in dep-wait
[12:37] <cjwatson> yes
[12:39] <didrocks> cjwatson: why not this !arm64 btw?
[12:39] <didrocks> but rather listing explicitely
[12:39] <cjwatson> Two reasons
[12:39] <cjwatson> Firstly, it's silly not to use the same terms that ust itself does, since the url-dispatcher restriction is a direct consequence of the list of packages supported by ust
[12:39] <cjwatson> Secondly, we'll have another new port shortly which is also not in ust's list
[12:40] <didrocks> cjwatson: ok, I'll use the same list than for ust (including debian ones then)
[12:40] <didrocks> thanks cjwatson
[12:40] <cjwatson> It should also make it easier to visually spot discrepancies in future
[12:40] <cjwatson> (you could put a comment above it in the control file, e.g.)
[12:40] <didrocks> (already there ;))
[12:40] <cjwatson> heh, ok
[12:43] <didrocks> (uploaded)
[12:50] <didrocks> cjwatson: in fact, it's upstart-app-launch which deps on ust
[12:51] <didrocks> cjwatson: so, I just uploaded that one (in addition, to url-dispatcher)
[12:51] <cjwatson> ok
[12:51] <didrocks> what's the best way to unblock those in britney once built? I think I need to rebuild all reverse-build-deps of upstart-app-launch
[12:51] <didrocks> but should I keep them as arch: any and we remove the binaries on other archs to help britney?
[12:51] <didrocks> or should I list the arch for all of them?
[13:00] <didrocks> cjwatson: ok, I guess I'm going to list then
[13:01] <cjwatson> didrocks: I don't understand.  Why would we remove them?
[13:01] <cjwatson> Confused.
[13:02] <didrocks> cjwatson: so, upstart-app-launch is going to dep on a subset of archive it was building against before (so no arm64 for instance) because of ust
[13:02] <didrocks> I guess as the list is written in debian/control, britney will let go it through
[13:02] <cjwatson> No
[13:02] <didrocks> ah?
[13:02] <cjwatson> Why can't upstart-app-launch continue to build on arm64, just without ust?
[13:03] <didrocks> ok, for that, we'll need upstream support I guess then
[13:03] <didrocks> which is then going to block an image promotion
[13:03] <didrocks> I understood you wanted Architecture: <list>
[13:03] <cjwatson> No, I was expecting Build-Depends: liblttng-ust-dev [list]
[13:04] <cjwatson> But it's a question.  Is this truly mandatory now or can it have a sensible fallback?
[13:04] <didrocks> cjwatson: let me look at the code
[13:04] <sil2100> The new ust in the archive seems to cause some trouble for us? Or the troublesome part is the upstart dependency here?
[13:04] <cjwatson> upstart-app-launch, not upstart
[13:04] <cjwatson> Nothing to do with the new ust either
[13:04] <cjwatson> Please read the scrollback
[13:05] <sil2100> Right, by upstart I mean upstart-app-launch, just was saving up typing time
[13:05] <cjwatson> Please don't do that :P
[13:05] <sil2100> Ok, so the new dep then ;)
[13:05] <cjwatson> didrocks: if it's truly mandatory, adding an explicit architecture list achieves nothing and we should remove the binaries
[13:06] <cjwatson> didrocks: And indeed the changes you uploaded were largely pointless, I'm afraid
[13:06] <didrocks> cjwatson: it sems to me
[13:07] <cjwatson> didrocks: If you'd given me an opportunity to review the diffs :P
[13:07] <didrocks> cjwatson: it seems to be mandatory
[13:07] <cjwatson> Then it might as well just dep-wait
[13:07] <didrocks> cjwatson: well, sorry, I was assuming that britney parsed debian/control to take decisions
[13:07] <cjwatson> An explicit architecture list is just something that needs to be kept in sync in future
[13:07] <cjwatson> No, it doesn't, and this is well-documented
[13:07] <cjwatson> https://wiki.ubuntu.com/ProposedMigration gives the full list of criteria
[13:08] <didrocks> cjwatson: yeah, I read the page but didn't read back
[13:08] <cjwatson> I'd actually recommend reverting those changes again if liblttng-ust-dev is mandatory
[13:08] <cjwatson> They mean that if ust is ported to arm64 in future, url-dispatcher and upstart-app-launch will need changes in sync, while they otherwise wouldn't
[13:08] <didrocks> cjwatson: agreed, but i'll just prepare that in trunk
[13:08] <didrocks> without re-releasing
[13:08] <didrocks> if you don't mind
[13:08] <cjwatson> sure
[13:08] <didrocks> ok, so, I guess once upstart-app-launch is built, what is needed is:
[13:09] <didrocks> * promote the new binaries to main
[13:09] <didrocks> (if not done already)
[13:09] <didrocks> * removing the arm64 and powerpc?
[13:09] <cjwatson> what has powerpc got to do with anything, aside from your vendetta against it? :P
[13:09] <didrocks> * doing that removal for all deps of libupstart-app-launch*
[13:09] <cjwatson> ust builds on powerpc
[13:10] <didrocks> cjwatson: sorry, it was too much at the end of the list for my brain to catch it :)
[13:10] <didrocks> so yeah, arm64 only
[13:11] <cjwatson> I'm looking through its rdeps
[13:12] <didrocks> cjwatson: content-hub, url-dispatcher and unity-mir IIRC
[13:12] <cjwatson> ugh, painful
[13:12] <cjwatson> I'm not going to rely on memory ...
[13:12] <cjwatson> there are indicators and such too
[13:12] <didrocks> for ust itself, right
[13:12] <cjwatson> I wish upstream had discussed this with foundations first
[13:13] <didrocks> yeah, going to be painful :/
[13:13] <cjwatson> removing architectures is an annoying thing to do
[13:13] <didrocks> agreed
[13:15] <didrocks> cjwatson: can I help for anything?
[13:18] <cjwatson> don't think so, I'm just chasing the dep chain
[13:18] <didrocks> ok, revert done in trunks FYI for the arch: list thing
[13:22] <cjwatson> didrocks: there is one thing - I'm going to need to remove unity-greeter-session-broadcast/arm64, but it only has a run-time dependency on upstart-app-launch, not a build-dep
[13:23] <cjwatson> didrocks: so if I remove it it'll just reappear on the next upload
[13:23] <didrocks> cjwatson: ok, so for this one, I need to change the binary dep to list archs
[13:23] <cjwatson> didrocks: do you think it could have an artificial build-dep on upstart-app-launch instead?  that's usually better than a hardcoded arch list
[13:24] <didrocks> cjwatson: with a comment, I think that could do it, I'll get you something to review
[13:24] <cjwatson> didrocks: or maybe on a less intrusive binary package
[13:24] <cjwatson> didrocks: libupstart-app-launch2-dev?  shame there's no unversioned -dev package there
[13:24] <cjwatson> didrocks: upstart-app-launch itself is quite heavyweight for a b-d, it depends on click/click-apparmor
[13:25] <didrocks> cjwatson: yeah, I already had that discussion with tedg, hard to get them agreeing on what we need for a -dev
[13:25] <didrocks> cjwatson: ok, doing on libupstart-app-launch2-dev
[13:25] <cjwatson> ok, thanks
[13:25] <cjwatson> I've removed url-dispatcher and its rdeps
[13:25] <didrocks> thanks :)
[13:25] <cjwatson> so I think just upstart-app-launch and unity-greeter-session-broadcast are left
[13:26] <didrocks> upstart-app-launch has just been published I guess
[13:26] <didrocks> (seeing it in rmadison)
[13:26] <cjwatson> I wasn't waiting for that anyway
[13:26] <cjwatson> since I'm removing things from trusty, it doesn't matter
[13:26] <didrocks> indeed
[13:27] <cjwatson> hopefully systemtap/ust will get ported to arm64 soon - I see there's upstream work in progress on it
[13:27] <didrocks> ah, excellent, so the consideration to dep on ust will be valid or better to still chat with ted?
[13:27] <cjwatson> it's still a roadblock to new ports; I still think it should be optional
[13:28] <cjwatson> it's a heavyweight and complex piece
[13:28] <cjwatson> which is hard to port
[13:28] <didrocks> cjwatson: ok, I'm noting to talk to ted then
[13:28] <cjwatson> thanks
[13:30] <didrocks> cjwatson: how about that description? https://code.launchpad.net/~didrocks/unity-greeter-session-broadcast/add-upstart-app-launch-build-dep/+merge/198259
[14:00] <didrocks> ok, so seems the only blocker is out of date on arm64: libupstart-app-launch1, libupstart-app-launch1-dev, upstart-app-launch, upstart-app-launch-tools (from 0.3+14.04.20131126-0ubuntu1)
[14:01] <didrocks> not sure if you've done the removal or not already (maybe pending publication, but rmadison says the binaries are still around on arm64 in trusty pocket)
[14:28] <cjwatson> didrocks: r=me (for whatever that's worth)
[14:28] <cjwatson> didrocks: I haven't done the removal, am waiting for unity-greeter-session-broadcast to land
[14:29] <didrocks> cjwatson: you mean, in trunk or in archive? is that blocking? (we have an image build depending on it)
[14:29] <didrocks> cjwatson: like, if I land it in trunk, I can ensure that we are going to publish the next version with it (in tonight's landing)
[14:30] <didrocks> just want to get an image build and promoted
[14:31] <cjwatson> didrocks: trunk would be fine
[14:31] <didrocks> cjwatson: ok, I top-approved
[14:48] <didrocks> fginther: can you give a kick for https://code.launchpad.net/~didrocks/unity-greeter-session-broadcast/add-upstart-app-launch-build-dep/+merge/198259? image build is depending on that
[14:52] <didrocks> ah merged :)
[14:52] <didrocks> cjwatson: ok, so upstart-app-launch binaries and unity-greeter-session-broadcast are the last ones I guess ^
[14:52] <didrocks> (should be all good now)
[14:55] <sil2100> \o/
[14:57] <cjwatson> didrocks: removed
[14:58] <didrocks> thanks cjwatson and sorry for the trouble, I'm watching the transition and may annoy you or lool for an image build (I don't see the button on cdimage yet)
[15:00] <cjwatson> it's on iso.qa, not on cdimage
[15:03] <didrocks> cjwatson: I'll try to sync up with stgraber asap to know where this tool is
[15:03] <cjwatson> didrocks: http://iso.qa.ubuntu.com, log in
[15:03] <didrocks> (done)
[15:03] <cjwatson> should be usual sso
[15:04] <didrocks> I don't see anything
[15:04] <didrocks> You are currently on: Ubuntu ISO Testing
[15:04] <didrocks> and then, nothing
[15:04] <cjwatson> then select "Trusty Daily" on the front page
[15:04] <cjwatson> check "Ubuntu Touch armhf", scroll to the bottom, check that it says "Request a rebuild" under "Rebuilds", press "Update rebuild status"
[15:05] <didrocks> in the actions, I only have "passed with no bugs", "subscribe", "unsuscribe"
[15:05] <didrocks> I logged in checking the touch release team
[15:05] <didrocks> let me logout and retry
[15:06] <didrocks> cjwatson: confirming I don't see any Rebuilds section on http://iso.qa.ubuntu.com/qatracker/milestones/308/builds/58757/testcases
[15:08] <cjwatson> try http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
[15:08] <cjwatson> you shouldn't actually *click* on Ubuntu Touch armhf
[15:08] <cjwatson> just check the checkbox beside it
[15:08] <didrocks> cjwatson: ah ok, yeah, you're right, was just one path to deep
[15:08] <didrocks> sorry for being so dummy…
[16:17] <rsalveti> didrocks: how are we in terms of merging/landing new stuff in the archive?
[16:17] <rsalveti> didrocks: are we still in a soft freeze to be able to promote an image?
[16:17]  * rsalveti wants to land a new hybris and ofono
[16:17] <didrocks> rsalveti: we are in hell :)
[16:18] <didrocks> rsalveti: yeah, I just kicked an image build, for the promotion candidate
[16:18] <didrocks> rsalveti: I would prefer before we promote it we don't take risks please
[16:18] <didrocks> we had enough collisions… :/
[16:19] <rsalveti> ok, will get the code in trunk and available in a ppa for now, will ping you again tomorrow then
[16:21] <didrocks> rsalveti: let's really cross fingers we can promote this time…
[16:21] <rsalveti> seems it's really easy to reproduce bug 1258655 with latest image
[16:22] <rsalveti> not sure if we want to fix that first before promoting a new image
[16:22] <rsalveti> it's kind of a blocker for dogfooding imho
[16:22] <rsalveti> I could get unity8 to crash a bunch of times in a row
[16:25] <didrocks> rsalveti: last comment from Saviq told it's not a regression compared to latest promoted image
[16:25] <rsalveti> didrocks: right, but it seems way easier to reproduce it now
[16:25] <rsalveti> I was using the phone for a few minutes and could make it crash a few times already
[16:25] <rsalveti> the issue was probably there already
[16:26] <didrocks> yeah, just easier to trigger hum…
[16:26] <rsalveti> but something changed with latest unity8 that made it easier to be triggered
[16:26] <didrocks> rsalveti: I would still be in favor of promoting (if the tests pass), we still have no unity8 fixes for it and have big issues unfixed in current images
[16:26] <didrocks> rsalveti: however, putting that one on top of Saviq's team list
[16:26] <didrocks> does it sound ok for you?
[16:57] <rsalveti> didrocks: yeah, can easily trigger that
[16:58] <didrocks> rsalveti: ok, let's do that then, promoting but keeping that on top of unity8's team list
[16:59] <rsalveti> didrocks: yeah, can easily trigger the bug with r54
[16:59] <didrocks> be more relax on the power button-side! :)
[17:00] <rsalveti> yup, sounds fine
[17:00] <didrocks> joke apart, at least, we'll unleash the flood gate for people to push more updates
[17:00] <rsalveti> didrocks: did we fix the lack of video carousel?
[17:00] <didrocks> rsalveti: yeah, this one is supposed to be fixed
[17:01] <didrocks> I think there is no carousel if you have few videos (as I have)
[17:01] <didrocks> but robru tested with more
[17:01] <rsalveti> and the issue that made us unable to start videos from the lens
[17:01] <didrocks> (and this is by design)
[17:01] <rsalveti> let me test :-)
[17:01] <sil2100> didrocks: meeting!
[17:01] <didrocks> rsalveti: please do retest, yeah ;)
[17:01] <didrocks> kenvandine: coming?
[17:02] <kenvandine> didrocks, doh! yeah...
[17:02] <rsalveti> didrocks: no carousel
[17:02] <didrocks> no robru
[17:02] <didrocks> rsalveti: and you do have enough videos to get the carousel?
[17:02] <rsalveti> but can at least launch the video now
[17:02] <rsalveti> didrocks: well, I always had carousel with 4 videos
[17:03] <didrocks> rsalveti: seems it's the official design
[17:03] <didrocks> from what Saviq told
[17:03] <rsalveti> what is the minimum amount of videos needed?
[17:03] <didrocks> I can dig back the bug report
[17:03] <didrocks> one sec
[17:03] <Saviq> didrocks, 6
[17:03] <Saviq> rsalveti, ↑
[17:03] <rsalveti> hm, interesting, let me try that
[17:03] <Saviq> bug #1226288
[17:03] <didrocks> thanks Saviq!
[17:06] <Laney> can we have notify-osd released please?
[17:07] <didrocks> Laney: again a new release?
[17:07] <Laney> hmm?
[17:07] <Laney> is it a problem?
[17:07] <rsalveti> Saviq: yay, working fine :-)
[17:08] <didrocks> Laney: just trying to ask for a reason :)
[17:09] <Laney> Fixes a double g_source_remove() or two
[17:09] <didrocks> Laney: ok, we'll do it
[17:10] <Laney> the autopkgtest fails which blocks migration of some stuff
[17:10] <Laney> actually, let me double check that passes now
[17:11] <didrocks> Laney: robru is doing it now
[17:11] <Laney> ok
[17:15] <robru> Laney, is notify-osd trunk ready for release? or is there an MP i should wait for?
[17:15] <Saviq> rsalveti, cool
[17:16] <popey> hm, i tried to install an app on #55 and it download failed
[17:16] <popey> [unity-scope-click] - DEBUG: click-scope.vala:176: action started: download_failed
[17:17] <Laney> robru: it got merged, but just give me 5 minutes to check it fixes the tests
[17:17] <Laney> would be annoying to have to go around again if not
[17:17] <robru> Laney, ok
[17:17] <popey> 2013-12-09 17:14:09,845 - DEBUG - "Fatal error: /home/phablet/.local/share/ubuntu-download-manager/Downloads/com.ubuntu.developer.doflah.realtai_0.1_all.click failed to install.
[17:18] <popey> Cannot install /home/phablet/.local/share/ubuntu-download-manager/Downloads/com.ubuntu.developer.doflah.realtai_0.1_all.click: Cannot acquire permission to write to /opt/click.ubuntu.com; either run as root with --user, or use "pkcon install-local" instead
[17:19] <popey> drwxr-xr-x 133 dnsmasq ssh 8192 Dec  2 20:57 click.ubuntu.com
[17:19] <popey> wut
[17:22] <Laney> robru: ya, looks good
[17:22] <robru> Laney, ok, on it
[17:22] <Laney> merci
[17:23] <sergiusens> fginther, do you have a minute to discuss the status of android image builders with jenkins?
[17:23] <fginther> sergiusens, sure
[17:25] <sergiusens> fginther, bascially need something like the builder for building ubuntu touch as we had before
[17:26] <sergiusens> fginther, but to build a different branch from the repo to detect breakages
[17:26] <popey> bug 1259253
[17:27] <fginther> sergiusens, what's in the branch?
[17:27] <sergiusens> fginther, a git branch
[17:27] <sergiusens> fginther, well, a bundle of git repos on a different branch; it's for android
[17:28] <sergiusens> fginther, the branch is just a different android version with our patchset on top
[17:29] <fginther> sergiusens, don't we already have some jobs that almost do this? is this just a matter of updating them?
[17:29] <fginther> at least the build part
[17:29] <sergiusens> fginther, yeah, that was my question; we used to have ubuntu-touch-image (the jenkins job); which had a specific assigned builder
[17:30] <sergiusens> fginther, the builders are sort of hardcoded to the job as we don't want to repo sync ~10GB from scratch all the time
[17:31] <fginther> sergiusens, so we did retire some of the machines we were using for these jobs
[17:31] <fginther> sergiusens, but we should be able to identify replacements and get them setup
[17:31] <sergiusens> fginther, sounds good; need a formal request somewhere?
[17:32] <fginther> sergiusens, yes, please: https://bugs.launchpad.net/ubuntu-ci-services-itself/+filebug
[17:32] <fginther> sergiusens, do you have a timeline for when this is needed?
[17:34] <sergiusens> fginther, end of year at the most I think; I'll get back to you on that one (or add it to the bug report
[17:34] <fginther> sergiusens, thanks
[17:34] <sergiusens> thanks to you too :-)
[17:35] <popey> sergiusens: why did the uid for clickpkg change? see second comment on https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1259253
[17:35] <popey> it will break app apps for anyone upgrading to #55
[17:36] <popey> s/apps/upgrades and installs/
[17:39] <robru> sil2100, are you tinkering with url-dispatcher? i just saw it has a yellow prepare job; if you're working on it i'll leave it with you; otherwise i can fix it
[17:40] <sergiusens> popey, the clickpkg user is dynamically created on rootfs build
[17:40] <popey> odd that the users have moved about UIDs
[17:41] <popey> we shouldn't let that happen IMO
[17:41] <sergiusens> popey, I guess that's why android uses hardcoded uids
[17:41] <popey> ☻
[17:41] <popey> any idea which bit of the toolchain I should move that bug to? It's clearly not ubuntu-download-manager at fault
[17:42] <sergiusens> popey, we were supposed to move away from hard coded UIDs but this system image stuff would need us to rethink some stuff
[17:42] <sergiusens> popey, livecd-rootfs would be my guess; but this could probably be fixed with an update hook for the writable parts
[17:43] <sergiusens> cjwatson, any thoughts on clickpkg uid changing across image updates? ^^
[17:43] <cjwatson> system image update hook sounds appropriate
[17:43] <cjwatson> I don't want to give it a fixed uid - it's the wrong trend
[17:44] <cjwatson> adduser --system is the right thing to be using here
[17:44]  * popey fettles the description of that bug
[17:44] <cjwatson> and even if I did give it a fixed uid, it'd still be a different one and we'd need to solve the same problem anyway
[17:44] <sergiusens> agreed
[17:49] <cjwatson> it's clearly not ubuntu-download-manager, indeed.  loath though I am to care about this, maybe click should be shipping a system-image hook, seeing as it owns the clickpkg user
[18:00] <popey> moved it to livecd-rootfs for now. bug 1259253
[18:03] <cjwatson> popey: definitely not
[18:03] <popey> heh
[18:03] <cjwatson> that's several layers above anything that can do anything about it
[18:03] <popey> knock yourself out ☻
[18:04] <cjwatson> I've moved it to click, but won't get to it today
[18:04] <popey> ok, thanks.
[21:15] <rsalveti> bfiller: maybe you know already, but the only crash in 55 is from the dialer app: http://ci.ubuntu.com/smokeng/trusty/touch/mako/55:20131209.1:20131203/5356/dialer-app-autopilot/
[21:15] <rsalveti> cyphermox: robru: are we promoting 55?
[21:16] <cyphermox> rsalveti: I don't know, are we?
[21:16] <rsalveti> seems there are still some missing tests for mako
[21:16] <robru> rsalveti, no idea. i was only working on notify-osd, which is desktop only
[21:16] <cyphermox> which?
[21:16] <robru> today
[21:16] <cyphermox> rsalveti: which? I'm not sure how we'd be involved :)
[21:16] <rsalveti> cyphermox: probably tomorrow only then, didrocks was taking care of it
[21:16] <cyphermox> ok
[21:17] <cyphermox> besides pushing the button, I guess it's up to QA
[21:17] <rsalveti> yeah
[21:17] <cyphermox> didrocks didn't mention any manual testing we should have been doing
[21:17] <rsalveti> he wants to promote 55 (iirc), so maybe some more manual testing (dogfooding) with it should be good
[21:18] <bfiller> rsalveti: need to get boiko to take a look
[21:20] <cyphermox> hrm
[21:20] <cyphermox> rsalveti: didrocks did mention dogfooding
[21:21] <cyphermox> let's split what's missing and we can do the testage.
[21:21] <cyphermox> robru: ^?
[21:41] <popey> rsalveti: i wouldn't promote 55 with bug 1259253
[21:45] <rsalveti> oh, crap
[21:46] <popey> rsalveti: Has it been promoted?
[21:47] <rsalveti> popey: no, but I wanted it to be :-)
[21:47] <popey> heh
[21:49] <plars> popey, rsalveti : pity, the automated tests looked so awesome :)
[21:50] <popey> Well maybe once the mythical mir fix lands we'll get a clean green sheet and we can promote that
[21:50] <popey> #hopeful
[21:51] <robru> cyphermox, yeah I can do some testing. what ya need?
[21:52] <rsalveti> yeah
[21:54] <cyphermox> robru: perhaps nothing after all
[21:54] <cyphermox> so, what do we do with this image?
[22:14] <Laney> how do we get adt-britney to notice that there's a new version of notify-osd which passes its autopkgtest?
[22:18] <cyphermox> Laney: good question. I'd usually ask jibel or pitti about this stuff
[22:22] <Laney> ok, would rather not force - bugs like this happen fairly regularly so would be good to fix
[22:33] <thomi> fginther: if we'd like some CI config changes... is the best thing to file a bug? or talk to someone here directly?
[22:34] <fginther> thomi, lets talk about it first
[22:34] <thomi> fginther: OK, so the first thing is we'd like the full autopilot test suite to be run daily, on amd64 & i386.
[22:35] <thomi> pretty soon we'll have the test suite so it can be run on a phone as well, but we're not there yet
[22:36] <thomi> fginther: I imagine it's already being run *somewhere*, it's just not very visible to us at the moment
[22:36] <fginther> thomi, ack, we can get amd64 and phone added w/o too much trouble
[22:36] <thomi> fginther: maybe leave phone off the list for a while, we're not ready for that
[22:37] <thomi> but we need to know where to go to see the results.
[22:37] <thomi> and I'll make sure the team knows to look at them
[22:37] <fginther> thomi, right, just trying to convey that i386 isn't something we've been doing for autopilot tests
[22:37] <fginther> thomi, so we have no platform configured for that combination
[22:37] <thomi> fginther: I see. I guess maybe it's time to drop i386 support?
[22:37] <thomi> I see
[22:38] <thomi> well, OK, so lets go with amd64 today, amd64 + phone later
[22:38] <fginther> thomi, ok, we'll make i386 a stretch goal
[22:38] <thomi> ok :)
[22:38] <thomi> fginther: the second thing we'd like is for the CI system to block merges that lower the unit test coverage.
[22:39] <thomi> I've already worked out what commands are needed to run the tests and produce the XML coverage report, so I can send that to someone if it makes it easier.
[22:40] <thomi> not sure if it works like this, but if it's easy to make jenkins show the coverage numbers (perhaps a graph) somewhere that would be sweet as well, but if not, as long as we block MPs that regress test coverage we'll be happy :)
[22:40] <fginther> thomi, right. the way we enable coverage for cmake projects isn't going to work here...
[22:40] <thomi> yeah
[22:41] <fginther> thomi, if jenkins is aware of code coverage, it can do a trend graph and it has some facilites for failing on coverage metrics
[22:41] <fginther> will need to review what's easily doable
[22:41] <fginther> thomi, any thing else?
[22:41] <thomi> ok. Can you get back to me on that when you have some time? number 2 is less urgent than number 1.
[22:42] <thomi> fginther: also, while I remember, could you please invite nuclearbob to the subunit  & dashboard meeting? (https://www.google.com/calendar/render?eid=aGd1bDJhNjY3OTZlb3V1bmVoaWhjanAybzRfMjAxMzEyMDlUMjEwMDAwWiB0aG9taS5yaWNoYXJkc0BjYW5vbmljYWwuY29t&sf=true&output=xml)
[22:42] <fginther> thomi, will do on both items
[22:42] <thomi> thanks man, I'll owe you... several :)
[22:42] <fginther> thomi, I'll create a bug in momento
[22:53] <fginther> thomi, can you review https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1259334 and add the details for collecting code coverage?
[22:53] <thomi> fginther: yup, will add the info this afternoon


[08:01] <kim0> Morning everyone
[08:06] <TeTeT> hi kim0
[08:08] <kim0> TeTeT: Hey o/ Morning
[09:30] <koolhead11> hi all
[09:32] <kim0> hey :)
[09:35] <koolhead11> hi kim0 TeTeT
[09:37] <TeTeT> hi koolhead11
[14:25] <hazmat> fwereade, how's the spring location?
[14:39] <niemeyer> Hey there
[14:40] <niemeyer> Part of the team is sprinting in Ensemble this week
[14:41] <niemeyer> So apologies if conversations feel a bit confusing, in advance
[14:41] <niemeyer> Feel free to join in, though :)
[14:42] <robbiew> :)
[15:04] <smoser> RoAkSoAx, so... the preseed file that we were starting with (which i believe is incomplete at this point) is orchestra/./provisioning-server/etc/orchestra/ubuntu-orchestra-client.seed
[15:06] <RoAkSoAx> smoser: ok. That's not in the archives yet I presume
[15:07] <RoAkSoAx> so we'll have to build that from source
[15:09] <RoAkSoAx> smoser: would it be possible for you to do a small howto of the things you were doing so we can work that from here?
[15:09] <smoser> well, its not exactly what we want anyway
[15:09] <smoser> right. thats what i'll work on.
[15:09] <smoser> getting you a running system and doc on how its working
[15:10] <RoAkSoAx> smoser: cool, I'm setting up my own cobbler /orchestra server here
[15:10] <smoser> RoAkSoAx, http://paste.ubuntu.com/641956/ is an example of a late_command
[15:11] <_mup_> ensemble/expose-provision-machines r281 committed by<EMAIL_ADDRESS>[15:11] <_mup_> Stubs for directly testing open_close_ports_on_machine
[15:12] <smoser> that is generated with ./update-latecmd oneiric-amd64-preseed.cfg update-latecmd from lp:~smoser/+junk/cobbler-devenv/
[15:12] <_mup_> ensemble/expose-provision-machines r282 committed by<EMAIL_ADDRESS>[15:12] <_mup_> Merged trunk
[15:13] <RoAkSoAx> smoser: ok cool
[15:21] <jcastro> niemeyer: do you have any slides from any ensemble presentations you might have done? I'm making a collection.
[15:21] <smoser> RoAkSoAx, http://paste.ubuntu.com/641966/ would be how i think preseed might look for us.
[15:22] <RoAkSoAx> smoser: right, all those variables are provided by cobbler, orchestra, or ensemble?
[15:23] <smoser> i'm not sure about EXTRA_PACKAGES
[15:24] <smoser> but the idea is that we will start hte installer from ensemble and pass it ks_args to populate ENSEMBLE_LATE_COMMAND
[15:24] <RoAkSoAx> smoser: ahh I see, so those are ks_args then
[15:29] <negronjl> Hi guys:  Regarding ensemble and standard AMIs ( Bug: 791501 ).  I have two questions:  Is it released in the ppa already and, how do I specify the AMI/size ?
[15:37] <_mup_> Bug #808854 was filed: need a skeleton for a cobbler provider <Ensemble:New> < https://launchpad.net/bugs/808854 >
[15:37] <jimbaker`> negronjl, as i understand it, the ppa should be built against trunk; bug 791501 is marked released and the code is in there
[15:37] <_mup_> Bug #791501: Ensemble should use standard amis and the ppa <Ensemble:Fix Released by hazmat> <Principia Ensemble:Triaged> < https://launchpad.net/bugs/791501 >
[15:38] <negronjl> jimbaker':  thx.  How do I specify AMI/size for ensemble to use ?
[15:38] <jimbaker`> re the way to specify it: default-instance-type and default-ami
[15:38] <jimbaker`> (i was on vacation last week, so i haven't had a chance to use it)
[15:39] <fwereade> hazmat, sorry I missed you, I kinda forgot IRC existed this morning :)
[15:39] <hazmat> indeed, that's it, ensemble is configured entirely through cloud-init with the new branch, it no longer uses pre-built images
[15:39] <negronjl> jimbaker':  thx
[15:39] <hazmat> so any standard ubuntu ami (natty or latter due to cloud-init  fixes)
[15:39] <hazmat> er. 10.10 should work
[15:40] <negronjl> hazmat:  Is there a way to dynamically specify the AMI/size when deploying a formula with ensemble?
[15:40] <hazmat> fwereade, no worries, just looking over the orchestra skeleton branch
[15:40] <negronjl> hazmat:  ie:  ensemble deploy <formula> <AMI> <size>
[15:40] <hazmat> negronjl, not atm
[15:41] <jimbaker`> hazmat, negronjl - that would be something that the stack concept should be handle
[15:41] <negronjl> hazmat:  then I would use the default-instance-type and default-ami in the ~/.ensemble/environment.yaml file ?
[15:41] <jimbaker`> able to handle
[15:41] <jimbaker`> negronjl, correct
[15:41] <hazmat> negronjl, yeah.. at the moment's that the only expose way of configuring them
[15:41] <fwereade> hazmat it's smal, but I bet it's got some sort of problem :p
[15:42] <negronjl> thx hazmat and jimbaker'
[15:42] <hazmat> negronjl, tests ;-)
[15:43] <negronjl> hazmat:  I'll be testing today.  I'll report back
[15:44] <m_3> hazmat: do we have to add a default-ami line to environment.yaml?
[15:44] <m_3> hazmat: I've been having problems with the new AMIs in r268
[15:51] <hazmat> m_3, hmm are you on oneric or natty?
[15:52] <hazmat> m_3, it should default to the natty image
[15:52] <hazmat> m_3, what sort of issues are you seeing?
[15:55] <m_3> hazmat: the ami (ami-06ad526f) is coming up, but any ensemble command stays in "...will wait"
[15:56] <m_3> hazmat: let me try on natty locally first... then I'll ping you
[15:59] <hazmat> m_3, i just verified it, i do see the wait problem, the agents on the bootstrap machine are running though.. i'm investigating
[16:01] <Daviey> o/
[16:09] <kim0> Daviey: o/
[16:12] <m_3> hazmat: same behavior for natty and lucid (don't know about oneiric yet)... both default to same ami(^^)
[16:12] <hazmat> m_3, i'm testing a patch right now
[16:12] <m_3> hazmat: cool... I'll grab coffee... lemme know if I can help
[16:19] <_mup_> ensemble/test-using-system-zookeeper r261 committed by<EMAIL_ADDRESS>[16:19] <_mup_> Minor styling changes from review.
[16:19] <niemeyer> fwereade: Can you please merge this and see if it works for you: lp:~niemeyer/ensemble/test-using-system-zookeeper
[16:19] <Daviey> hey kim0
[16:19] <niemeyer> fwereade: That's just SpamapS' branch with stylistic fixes
[16:19] <niemeyer> fwereade: If it does I'll commit to trunk
[16:20] <hazmat> niemeyer, jimbaker could you guys look at this trunk trivial diff, it looks like i missed a shelved commit when merging the sans-ami branch.. https://pastebin.canonical.com/49564/
[16:21] <jimbaker> hazmat, looking
[16:21] <hazmat> m_3, that diff is the fix for the issue your seeing
[16:21] <fwereade> niemeyer, works fine for me
[16:22] <niemeyer> hazmat: +1
[16:23] <m_3> hazmat: I'll apply it locally and give it a spin
[16:26] <_mup_> ensemble/trunk r269 committed by<EMAIL_ADDRESS>[16:26] <_mup_> Merged branch test-using-system-zookeeper from Clint [a=spamaps] [r=hazmat,niemeyer]
[16:26] <_mup_> This enables tests to be run using the system installed ZooKeeper.
[16:26] <_mup_> Note: I've applied irrelevant style changes to the original branch.
[16:26] <jimbaker> hazmat, looks good to me too
[16:29] <RoAkSoAx> smoser: any luck?
[16:29] <m_3> hazmat: that worked... thanks!
[16:29] <niemeyer> jcastro: I don't have any useful slides myself.. the talk from last week was in pt_BR, and the ones before are out-of-date and in a crazy format
[16:30] <smoser> no. working on it right now.
[16:30] <jcastro> ok, I'm organizing a bunch now
[16:30] <smoser> will focus on gettin gthat to you.
[16:30] <jcastro> PSA: If anyone has ensemble slides send them my way
[16:30] <niemeyer> jcastro: bcsaller, Nick Barcet, and Davie Duffey had good ones, though
[16:30] <hazmat> m_3, yeah.. i missed that one, it should have been part of the sans-ami merge. glad its working for you.
[16:30] <jcastro> I've got Nick's already, I'll check with the other 2, thanks!
[16:31] <_mup_> ensemble/trunk r270 committed by<EMAIL_ADDRESS>[16:31] <_mup_> [trivial] Fix bootstrap initialization with ensemble ppa installation [r=jimbaker,niemeyer]
[16:31] <_mup_> This was a missing commit from the sans-ami merge. It allows for any ensemble-admin cli within
[16:31] <_mup_> the path to be used instead of hardcoding it to /usr/local.
[16:31] <niemeyer> jcastro: David's was not specific to Ensemble, though
[16:31] <niemeyer> jcastro: Not sure if it'd be useful
[16:31] <niemeyer> jcastro: It had an awesome video cut out from a screencast
[16:31] <RoAkSoAx> smoser: thanks!
[16:31] <niemeyer> jcastro: Which I found handy to reuse
[16:31] <jcastro> niemeyer: even raw material will be useful
[16:37] <kim0> does anyone know if that hadoop formula can be used today, as is
[16:37] <kim0> thinking about coming up with some cool demo for it
[16:38] <m_3> kim0: let's coordinate... I'm working on similar demos
[16:40] <kim0> m_3: sure thing
[16:41] <kim0> well basically the simple plan for me was for every working formula, I'd blog an article about it and perhaps a screencast. And I'll try to push to the interested communities
[16:41] <kim0> m_3: ofc there's enough cool demos for everyone :) if you think you'll be doing lots of those, then perhaps let's coordinate with bugs?
[16:41] <niemeyer> Folks, we'll attempt to run through the normal procedure here in the sprint
[16:42] <m_3> kim0: we should certainly cover http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-node-cluster/
[16:42] <kim0> m_3: btw, where do you blog, I'd like to add you to cloud.ubuntu.com
[16:42] <niemeyer> including branches, merge proposals, reviews, etc
[16:43] <m_3> kim0: but the single/multi in one tutorial... it'd be great if we could get him to repoint to an ensemble-based demo as "the" getting-started
[16:43] <niemeyer> as one exception, we'd like to run with one review for the bits which are specific to Orchestra support
[16:43] <niemeyer> (rather than changing existing logic)
[16:43] <kim0> m_3: I hope the ensemble formula is gonna make it way much simpler than this :D
[16:43] <niemeyer> So that we can run a tighter loop here
[16:43] <niemeyer> E.g. for stuff like this: https://code.launchpad.net/~fwereade/ensemble/cobbler-integration/+merge/67568
[16:44] <kim0> m_3: probably once we have a dead simple article demo'ing that, we can point him, he'll surely add that
[16:44] <niemeyer> hazmat, bcsaller, jimbaker: Is that alright?
[16:44] <m_3> kim0: blog.markmims.com, but it's still under construction atm
[16:44] <jimbaker> niemeyer, +1
[16:44] <kim0> m_3: once you have a cloud tag, give me the rss I should add
[16:45] <m_3> kim0: dude, it'd totally be simpler for that getting started guide
[16:45] <niemeyer> hazmat, bcsaller, jimbaker: Even then, you should feel free to come over and review the logic, before or after merging
[16:45] <kim0> m_3: so the formula is ready? do we have like a readme of what needs to be done to get to crunching map/red jobs ?
[16:45] <niemeyer> We'll be happy to address any points
[16:45] <m_3> kim0: I want some more interesting ones too though
[16:46] <kim0> m_3: is it a good idea to create a spreadsheet now to track cool demos we can think of ?
[16:47] <kim0> I was thinking more like, as each formula is done, I'd figure out a cool demo for it
[16:47] <kim0> but if you have ideas, let's write'em down
[16:48] <m_3> kim0: nope... those forms not ready yet... I'll devote some time today to test juan's formulas out and add a readme
[16:48] <m_3> kim0: spreadsheet yes, definitely
[16:48] <kim0> m_3: that would be awesome :)
[16:48] <kim0> m_3: cool then .. creating it
[16:48] <niemeyer> fwereade: Re. XML-RPC on Twisted: http://twistedmatrix.com/documents/current/web/howto/xmlrpc.html
[16:50] <hazmat> niemeyer, that sounds good
[16:51] <niemeyer> Cool, thanks
[16:51] <Daviey> Is twisted really needed for this?
[16:51] <kim0> Here's a spreadsheet to track cool demo ideas for formulas that are being written http://j.mp/peTAKG
[16:51] <kim0> m_3: jcastro ^
[17:07] <niemeyer> Daviey: It's not needed for anything in theory, and I hope we manage to simplify things quite a bit in the near future
[17:07] <niemeyer> Daviey: But we do have to use Twisted right now for implementing that
[17:07] <niemeyer> Daviey: Not using Twisted for XML-RPC blocks every other activity in the system
[17:12] <Daviey> niemeyer: it's like 4 xmlrpc calls?
[17:12] <Daviey> blocking for <0.05s is a big deal?
[17:16] <niemeyer> Daviey: It's a remote call, and it stops every other activity in the system.. if it takes longer for whatever reason, nothing else works.
[17:16] <niemeyer> Daviey: This is the price for using Twisted.. I very much want to get rid of it, but we can't be in the middle
[17:23] <niemeyer> We're stepping out for lunch
[17:25] <Daviey> have fun
[17:50] <_mup_> ensemble/security-principal-def r269 committed by<EMAIL_ADDRESS>[17:50] <_mup_> security principals for ensemble
[18:16] <_mup_> ensemble/security-principal-def r270 committed by<EMAIL_ADDRESS>[18:16] <_mup_> principal identity token database.
[18:19] <_mup_> Bug #808935 was filed: ensemble needs principals and way to store/retrieve principal identity tokens <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/808935 >
[18:58] <negronjl> guys:  running ensemble r270 from ppa.  I have modified my environment.yaml by adding default-instance-type: m1.large and default-ami: ami-4eab5127 (oneiric).  I then run ensemble bootstrap and I get: http://pastebin.ubuntu.com/642099/
[18:58] <negronjl> any help would be appreciated.
[19:00] <negronjl> a simple search for ami-06ad526f finds it at:  /usr/share/pyshared/ensemble/tests/test_utils.py  in case that makes a difference.
[19:01] <niemeyer> negronjl: hazmat would be the right person to help you
[19:01] <negronjl> niemeyer:  thx.
[19:01] <negronjl> hazmat: ping
[19:01] <hazmat> negronjl, looking
[19:01] <niemeyer> hazmat: Danke
[19:01] <negronjl> hazmat:  thx
[19:03] <hazmat> negronjl, that paste is to the environments.yaml? the instance launched is not the ami specified?
[19:03] <negronjl> I'm not following.
[19:03] <hazmat> negronjl, i'm trying to understand what the problem is
[19:03] <_mup_> ensemble/expose-provision-machines r283 committed by<EMAIL_ADDRESS>[19:03] <_mup_> Explicit direct testing of corner cases in open_close_ports_on_machine
[19:03] <negronjl> hazmat:  Here is what I did.
[19:04] <negronjl> hazmat: I am running natty btw.
[19:04] <negronjl> hazmat:  I modified my environment.yaml file by adding the default-instance-type and default-ami values
[19:04] <negronjl> hazmat:  after I saved the file, I ran "ensemble bootstrap"
[19:04] <negronjl> hazmat: ...and got the error I pasted.
[19:05] <negronjl> hazmat:  that's all I have done so far.
[19:05] <hazmat> negronjl, ah.. i see i missed that at the bottom of the pastebin, i thought it was just the environment.yaml content
[19:06] <negronjl> hazmat:  no worries.  I appreciate the help :)
[19:06] <niemeyer> fwereade, RoAkSoAx: For reference, this is the cobbler/remote.py file which contains the server-side XML-RPC API: http://j.mp/cobbler-remote
[19:10] <hazmat> negronjl, the setting is 'default-image-id'
[19:11] <negronjl> hazmat:  ahh.. that may be it....let me change/try again.
[19:11] <negronjl> hazmat:  heh....look at that...it seems to be working so far.
[19:11] <negronjl> hazmat:  thx for the help
[19:11] <hazmat> negronjl, cool
[19:11] <hazmat> np
[19:16] <hazmat> negronjl, it looks like we led you astray on irc re the param name, but  fwiw it is documented correctly here https://ensemble.ubuntu.com/docs/provider-configuration-ec2.html
[19:16] <negronjl> hazmat:  cool.. no worries.  I'm just glad it's working now.  Thanks for the help
[19:21] <_mup_> Bug #808969 was filed: determine the instance type at deploy <Ensemble:New> < https://launchpad.net/bugs/808969 >
[19:34] <_mup_> ensemble/expose-provision-machines r284 committed by<EMAIL_ADDRESS>[19:34] <_mup_> Comments/docstrings
[19:41] <_mup_> ensemble/expose-provision-machines r285 committed by<EMAIL_ADDRESS>[19:41] <_mup_> Test some corner cases
[19:59] <_mup_> ensemble/expose-provision-machines r286 committed by<EMAIL_ADDRESS>[19:59] <_mup_> Cleanup
[19:59] <_mup_> ensemble/expose-provision-machines r287 committed by<EMAIL_ADDRESS>[19:59] <_mup_> Merged trunk
[20:02] <niemeyer> hazmat: As a heads up, we're attempting some refactoring work on the EC2 provider
[20:02] <hazmat> niemeyer, great
[20:03] <hazmat> niemeyer, based on what clint already did?
[20:03] <_mup_> ensemble/expose-provision-machines r288 committed by<EMAIL_ADDRESS>[20:03] <_mup_> PEP8
[20:03] <niemeyer> hazmat: The first few branches may not be entirely obvious, because it's just untangling things
[20:03] <hazmat> SpamapS, not sure if those branches are pushed re refactoring
[20:03] <hazmat> niemeyer, sounds good
[20:04] <niemeyer> hazmat: We hope to move some bits to a common place til the end of the day
[20:04] <niemeyer> hazmat: No, it's not based on Clint's work.. we're hacking the EC2 provider itself to extract logic out of it
[20:04] <niemeyer> hazmat: Hopefully the bootstrap logic inside it will get very thin
[20:05] <hazmat> niemeyer, sounds good
[20:12] <niemeyer> hazmat: SpamapS work will be most useful to us once get past that initial phase, because it has very good hints about how to structure the work with relation to the cobbler interaction
[20:12] <_mup_> ensemble/expose-provision-machines r289 committed by<EMAIL_ADDRESS>[20:12] <_mup_> Properly guard against topology state changes
[20:15] <jimbaker> niemeyer, sounds good about ec2 refactoring - will be useful for the ec2 firewall mgmt piece i have queued up
[20:15] <niemeyer> jimbaker: Likely
[20:18] <_mup_> ensemble/expose-provision-machines r290 committed by<EMAIL_ADDRESS>[20:18] <_mup_> Removed debugging statements
[20:30] <_mup_> Bug #809005 was filed: inconvenient EC2Operation inheritance <Ensemble:New> < https://launchpad.net/bugs/809005 >
[20:38] <_mup_> Bug #809007 was filed: Modify provisioning agent so that port changes are made against a machine <Ensemble:In Progress> < https://launchpad.net/bugs/809007 >
[20:49] <niemeyer> hazmat: ping
[20:53] <_mup_> ensemble/expose-status r265 committed by<EMAIL_ADDRESS>[20:53] <_mup_> Merged trunk & resolved conflict
[21:04] <_mup_> ensemble/expose-status r266 committed by<EMAIL_ADDRESS>[21:04] <_mup_> Fix open-ports output in ensemble status to report [] if service is exposed but the service unit has no open ports
[21:12] <hazmat> niemeyer, pong
[21:12] <niemeyer> hazmat: Hye
[21:13] <niemeyer> hazmat: Curious about a test problem here
[21:13] <hazmat> niemeyer, shoot
[21:13] <niemeyer> hazmat: I suspect it may be caused by a left-over/unfinished branch, but not sure
[21:13] <hazmat> niemeyer, what's the failure?
[21:13] <niemeyer> hazmat: test_watch_user_callback_invocation_delays_node_watch
[21:13] <niemeyer> hazmat: ensemble/state/tests/test_relation.py
[21:13] <hazmat> hmm
[21:13] <niemeyer> hazmat: See the assertions at the end of the test?
[21:14] <hazmat> niemeyer, seems to work fine on trunk
[21:14]  * hazmat looks over the test
[21:14] <niemeyer> hazmat: That "state: connected" string doesn't seem to be anywhere
[21:14] <niemeyer> hazmat: I suspect you may have a local uncommitted change in your txzookeeper branch
[21:14] <hazmat> niemeyer, update your txzk
[21:14] <niemeyer> hazmat: Already did
[21:14] <hazmat> hmm
[21:14] <niemeyer> hazmat: let me confirm I don't have paths mixed up
[21:15] <niemeyer> hazmat: fwereade sees the same issue, FWIW
[21:15] <hazmat> niemeyer, hmm my python path is pointing to a txzk branch..
[21:15] <niemeyer> hazmat: Uh oh
[21:15] <niemeyer> :)
[21:15] <hazmat> yeah.. i was trying to make sure ensemble trunk ran with the branch before i merged.. investigating
[21:15] <_mup_> ensemble/trunk r272 committed by<EMAIL_ADDRESS>[21:15] <_mup_> merged expose-status [r=niemeyer,hazmat][f=767414]
[21:15] <_mup_> Modifies "ensemble status" to report whether a service is exposed, and
[21:15] <_mup_> if so, the open ports for each of its service units, if any.
[21:16] <niemeyer> hazmat: Well, that's exactly what is happening!  ensemble trunk runs with the branch before you merged. 8-)
[21:17] <hazmat> niemeyer, what revno do you have for txzk
[21:17] <hazmat> niemeyer, it works fine for me with rev 42 of trunk
[21:18] <hazmat> on txzk
[21:18] <hazmat> hmmm
[21:19] <niemeyer> hazmat: Well, something funky just happened
[21:20] <niemeyer> hazmat: I checked it moments ago, on revision 42, and ClientEvent wasn't changed
[21:20] <jimbaker> hazmat, niemeyer - i saw this problem this morning, it went away with the update to txzkookeeper trunk
[21:20] <niemeyer> hazmat: I've updated back to 40 to test, and now updated to 42, and it is there
[21:20] <niemeyer> hazmat: Super weird
[21:20] <hazmat> niemeyer, trial doesn't clear out stale pyc files, not generally an issue..
[21:20] <niemeyer> hazmat: Let me check with fwereade's branch before he touches it
[21:21] <hazmat> k
[21:22] <niemeyer> hazmat: No game.. he's using the package, so the issue is expected
[21:22] <niemeyer> hazmat: Just so you don't think I'm crazy, this is from my history:
[21:22] <niemeyer> ..eeper-bzr/trunk]% bzr update
[21:22] <niemeyer> Tree is up to date at revision 42 of branch bzr+ssh://bazaar.launchpad.net/~ensemble/txzookeeper/trunk
[21:23] <niemeyer> hazmat: I could reproduce the bug after that..
[21:23] <hazmat> niemeyer, i believe you.. although they have some good rum in miami i hear ;-)
[21:23] <hazmat> perhaps the universal answer confused the issue
[21:23]  * hazmat looks for a towel
[21:25] <jimbaker> i just cleaned up pyc files in trunk txzk and ensemble, our test suite still works fine for me
[21:25] <niemeyer> hazmat: :-)
[21:25] <niemeyer> hazmat: So, we need to fix that package.. will look at that
[21:26] <niemeyer> jimbaker: Sweet, thanks for confirming
[21:29] <_mup_> Bug #809030 was filed: [ReOpen] Ensemble should use standard amis and the ppa <Ensemble:New> < https://launchpad.net/bugs/809030 >
[21:29] <niemeyer> hazmat: Did you enter the date by hand?
[21:29] <hazmat> niemeyer, ? what date
[21:30] <niemeyer> hazmat: The changelog one in txzookeeper
[21:30] <hazmat> niemeyer, i did
[21:30] <_mup_> ensemble/trunk r43 committed by<EMAIL_ADDRESS>[21:30] <_mup_> Add seconds to the changelog date. (/me looks at hazmat)
[21:30] <hazmat> niemeyer, it looked like the other lines, but it still doesn't like it
[21:30] <niemeyer> hazmat: "date -R" is what you want
[21:30] <kirkland`> hazmat: hi, could we get https://bugs.launchpad.net/ensemble/+bug/791501 reopened?  the fix doesn't appear to be working for us ...
[21:30] <jimbaker> niemeyer, when you have a chance, my branch debug-log-relation-settings-changes has been waiting for a review for 2.5 weeks (i made all changes that hazmat requested)
[21:30] <_mup_> Bug #791501: Ensemble should use standard amis and the ppa <Ensemble:Fix Released by hazmat> <Principia Ensemble:Triaged> < https://launchpad.net/bugs/791501 >
[21:30] <kirkland`> hazmat: it seems that LP has recently disabled the ability to reopen bugs in projects :-)
[21:31] <kirkland`> hazmat: in the mean time, we've filed https://bugs.launchpad.net/ensemble/+bug/809030 as a placeholder
[21:31] <_mup_> Bug #809030: [ReOpen] Ensemble should use standard amis and the ppa <Ensemble:New> < https://launchpad.net/bugs/809030 >
[21:31] <niemeyer> jimbaker: Ok.. it will wait for at least another one, sorry about that
[21:31] <hazmat> kirkland`, k, i'll try it out now
[21:31] <jimbaker> niemeyer, np. this should be a pretty useful branch for formula developers, so just wanted to get merged in :)
[21:32] <niemeyer> jimbaker: Yeah, I know.. I still want to check it out for sure, but it's also a low priority feature.. this week we really have to get orchestra cranking
[21:32] <jimbaker> niemeyer, ok
[21:36] <hazmat> niemeyer, fwereade re the ec2op refactoring, i feel like i'm missing the point about what value this brings
[21:36] <hazmat> could one of you elaborate on where you going
[21:36] <niemeyer> hazmat: Hehe :-)
[21:36] <niemeyer> hazmat: I anticipated that
[21:36] <hazmat> niemeyer, all i see is
[21:36] <hazmat> 56	-            d = self.ec2.describe_instances(instance_id)
[21:36] <hazmat> 57	+            d = self._provider.ec2.describe_instances(instance_id)
[21:37] <hazmat> which is a little unclear as far refactoring towards orchestra
[21:37] <niemeyer> hazmat: We need higher bandwidth
[21:37] <hazmat> or others
[21:37] <niemeyer> hazmat: Yeah, I know
[21:37] <niemeyer> hazmat: Which is why I've briefed you
[21:38] <hazmat> niemeyer, skype | google+ ?
[21:38] <niemeyer> hazmat: Google+
[21:38] <niemeyer> Anyone else want to join?
[21:41] <kirkland> hazmat: try "what" out now?  changing the state of the bug?
[21:41] <kirkland> hazmat: or launching ami's?
[21:42] <hazmat> kirkland, launching amis
[21:42] <hazmat> kirkland, going to do this meeting, and i'll check back in on it
[21:42] <kirkland> negronjl: what version of ensemble do you test the ami launching?
[21:43] <kirkland> hazmat: let me check with negronjl to see which version he tested
[21:43] <negronjl> kirkland, hazmat:  latest ensemble ppa ( r270 )
[21:43] <kirkland> hazmat: which rXXX do you want us to test, specifically?
[21:43] <negronjl> kirkland, hazmat: 0.5+270-0ensemble1~natty1
[21:44] <kirkland> hazmat: also, could you check that we're configuring it correctly?  it's possible that we have a bad configuration
[21:44] <hazmat> kirkland, un momento, doing a chat with niemeyer
[21:45] <kirkland> hazmat: k
[21:47] <negronjl> kirkland, hazmat:  the config that I am using:  http://pastebin.ubuntu.com/642192/
[22:07] <niemeyer> hazmat: Oh, btw, before you leave, would you be able to have a quick look at the branch?
[22:07] <niemeyer> hazmat: Should be pretty much a trivial now that you have the context
[22:09] <niemeyer> hazmat: Btw, txzookeeper package updated..
[22:09] <niemeyer> hazmat: It was the missing seconds indeed
[22:14] <hazmat> niemeyer, sure
[22:14] <hazmat> re quick look at the branch
[22:19] <hazmat> niemeyer, done
[22:23] <hazmat> kirkland, negronjl it's working for me.. using the same config.. all m1.large oneiric instances.. http://ec2-174-129-90-179.compute-1.amazonaws.com/wp-admin/install.php
[22:23] <hazmat> well same param names and same ami and machine size
[22:24] <hazmat> kirkland, negronjl what problems are you seeing? your on the latest rev, so that should all be good
[22:28] <hazmat> niemeyer, thanks re seconds
[22:28]  * hazmat wanders off to dinner
[22:30] <negronjl> hazmat:  i am unable to deploy any formulas at all.
[22:35] <niemeyer> hazmat: no worries
[22:36] <niemeyer> negronjl: What problem are you seeing there?
[22:36] <negronjl> niemeyer:  I don't see anything at all.. nothing happens.
[22:36] <negronjl> ensemble deploy <formula>
[22:36] <negronjl> then ensemble status
[22:36] <negronjl> and status is always null
[22:36] <adam_g> hey guys, stumbling in here late but it i can confirm 0.5+270-0ensemble1~natty1 doesn't deploy
[22:37] <adam_g> it bootstraps the first node fine
[22:37] <negronjl> ensemble ssh <machine> hangs as well
[22:37] <adam_g> but deploying nodes does not use the new userdata
[22:37] <niemeyer> adam_g: new userdata?
[22:38] <adam_g> one sec
[22:39] <adam_g> niemeyer: the userdata that cloud-init uses to install and bootstrap ensemble on the stock ubuntu AMIs
[22:40] <adam_g> from ensemble boostrap: http://paste.ubuntu.com/642216/
[22:40] <adam_g> from ensemble deploy: http://paste.ubuntu.com/642217/
[22:40] <niemeyer> adam_g: Hmm
[22:41] <hazmat> it shouldn't be doing the bzr stuff there
[22:41] <adam_g> i believe hazmat committed something last week to produce userdata from the first pastebinit, to allow ensemble to bootstrap stock AMIs
[22:41] <adam_g> but 'deploy' is still producing it in the way pre-commit
[22:42] <niemeyer> Ok, understood
[22:42] <hazmat> adam_g, are you using an existing environment perhaps?
[22:42] <hazmat> hmm
[22:42] <niemeyer> hazmat: MACHINE_ID=1.. probably not
[22:43] <adam_g> hazmat: perhaps i am? http://paste.ubuntu.com/642225/
[22:43] <hazmat> the "bzr up" line isn't in trunk (rev 270) anymore is why i ask
[22:44] <adam_g> hazmat: im using the enviornmnet ensemble originally generated, with a new default-image-id
[22:44] <adam_g> ill wipe my environment and try again.. strange, though, 'ensemble bootstrap' brought up the first node as expected
[22:44] <hazmat> adam_g, but you've shutdown and bootstrap since then?
[22:44] <adam_g> hazmat: yup. bootstrap'd for the first time this week after upgrade
[22:45] <hazmat> bootstrap on existing environment is a no-op.. the environment has to be shutdown and then bootstrap again to get a fresh install
[22:45] <hazmat> negronjl, perhaps the same applies for you? i was able to shutdown/bootstrap/deploy formulas/add-relations with trunk (r270)
[22:46] <hazmat> using the ppas for the ensemble install on the environment nodes
[22:46] <negronjl> hazmat:  I did:
[22:46] <negronjl> hazmat:  ensemble shutdown
[22:46] <negronjl> hazmat:  updated environment.yaml
[22:46] <negronjl> hazmat:  ensemble bootstrap
[22:46] <negronjl> hazmat:  ensemble deploy <whatever>
[22:46] <negronjl> hazmat: waited a while
[22:47] <negronjl> hazmat:  ensemble ssh < machine >
[22:47] <negronjl> hazmant:  nothing
[22:48] <hazmat> negronjl, if you ec2-describe-instances can you login into the machine directly?
[22:48] <hazmat> i'm curious if the machine and unit agent are running
[22:48] <adam_g> negronjl: can you pastebinit /var/lib/cloud/instance/scripts/runcmd?
[22:48] <negronjl> hazmat:  bootstrapping now
[22:49] <adam_g> hazmat: i see the same as juan. i can ssh directly, there is nothing installed or running
[22:49] <negronjl> hazmat:  waiting for bootstrap to complete
[22:49]  * hazmat checks the ppa
[22:50] <negronjl> hazmat:  do you want me to ssh into the bootstrap instance or try to deploy and then check that ?
[22:50] <hazmat> negronjl, the service unit instance (post deploy)
[22:50] <negronjl> hazmat: ok.  waiting
[22:50] <niemeyer> hazmat: Please note txzookeeper was _just_ updated.. if they were using the PPA, it was out of sync with Ensemble trunk
[22:52] <hazmat> looks like the current ppa rev is 272 (updating)
[22:53] <negronjl> hazmat:  upgrading ensemble to latest ppa
[22:53] <negronjl> hazmat:  the bootstrap process on the previous attempt timed out.
[22:53] <hazmat> i'm running through the same steps with the latest
[22:53] <hazmat> negronjl, the bootstrap is waiting on the remote end, so i'm not clear what its timing out on
[22:54] <hazmat> negronjl, you mean the command just hangs?
[22:54] <hazmat> that would imply a problem connecting to ec2
[22:54] <negronjl> hazmat:  ensemble returned a time out error ( took longer than 30 seconds )
[22:54] <negronjl> hazmat:  bootstrapping now
[22:55] <negronjl> hazmat:  bootstrapped.  should I deploy something now ?
[22:55] <hazmat> negronjl, yes
[22:55] <negronjl> hazmat:  trying to deploy tomcat6.   waiting
[22:56] <hazmat> negronjl, i've been using the example formulas as a known working base set
[22:56] <negronjl> hazmat:  that's ok.  If this one doesn't provide definitive results, I can try one of the included ones.
[22:57] <hazmat> "2011-07-11 18:56:36,260 ERROR SSH forwarding error: @@@@@@@"
[22:57] <hazmat> strange
[22:58] <negronjl> hazmat: I now have an instance.  What should I do now ?
[22:58] <hazmat> negronjl, does it show up in ensemble status?
[22:58] <negronjl> hazmat:  it does
[22:58] <negronjl> hazmat:  after the upgrade.  it seems to be working now.
[22:59] <negronjl> hazmat:  let me do some testing .... hold on
[22:59] <hazmat> negronjl, k
[22:59] <hazmat> negronjl, i'm going to grab dinner but i'll be back shortly
[22:59] <negronjl> hazmat: ok
[23:00] <negronjl> brb
[23:08] <negronjl> back
[23:10] <hazmat> negronjl, how'd it go?
[23:10] <negronjl> hazmat:  so far, it seems good. but, I am having issues with aws/ec2.  two of my instances are still pending.
[23:13] <adam_g> after upgrade, cloud-init stuff looks consistent across boostrap + deploy'd nodes.
[23:14] <adam_g> i too ran into a timed out instance, but it may be ec2 related. it also took an unusually long time to provision the instance
[23:14] <negronjl> ditto that.  ec2 is having issues
[23:17] <negronjl> hazmat:  it's all working well for me now.
[23:17] <hazmat> negronjl, great
[23:18] <negronjl> hazmat:  thx for the patience and help :)
[23:18] <hazmat> negronjl, np
[23:40] <hazmat> adam_g, afaics your bug and patch are against an older version of the codebase
[23:40] <hazmat> adam_g, is your local ensemble from the ppa?
[23:41] <hazmat> ensemble doesn't do bzr up anymore.. it either does the bzr checkout, or defaults to installing from ppa on the environment machines. it looks like your local installation might be out of date
[23:42] <adam_g> hazmat: yeah, that was last week before you committed the sans-AMI stuff
[23:43] <hazmat> adam_g, ah.. gotcha
[23:43] <hazmat> adam_g, are you still having issues running with oneric images?
[23:45] <adam_g> hazmat: nope, that last upgrade ~30mins ago seems to fix the issues i was seeing
[23:45] <hazmat> adam_g, great
[23:47] <_mup_> Bug #809070 was filed: ensemble should allow execution of formula specific/defined hooks <Ensemble:New> < https://launchpad.net/bugs/809070 >


[00:06] <mjg59> cetex: Event, by and large
[00:06] <mjg59> Some devices won't deliver battery level without polling
[00:26] <lamont> if I want to tell the kernel to just flat out ignore the do-not-fragment field, is that just a sysctl? or ?
[00:37] <cetex> mjg59: thanks. I'm wondering since it takes about a minute before a battery shows up in acpi on my laptop.
[00:38] <cetex> mjg59: the laptop has 2, one internal and one pluggable, when i remove the pluggable one it disappears within a couple of seconds. when i plug in a new one it takes slightly over a minute before it shows up.
[00:39] <mjg59> Shows up in the UI, or shows up in sysfs?
[00:41] <cetex> i replaced the battery within 10 seconds, and this is from syslog:
[00:41] <cetex> Feb 28 21:51:50 kernel: [ 9633.140290] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking
[00:41] <cetex> Feb 28 21:53:01 kernel: [ 9704.235534] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking
[00:41] <mjg59> Sounds like the firmware
[00:42] <mjg59> But also possibly a Linux bug in dealing with the firmware
[00:42] <cetex> battery firmware?, bios/uefi?
[00:42] <mjg59> ACPI
[00:42] <cetex> hm, right.
[00:43] <cetex> so, file a bug somewhere?, i believe i'm running the latest firmware. (going to doublecheck this weekend though)
[00:43] <cetex> err, bios and stuff.
[00:46] <cetex> tried it again. seems to take exactly one minute..
[00:46] <cetex> hm
[00:47] <cetex> pluged it in on 01:44:45, appeared 01:45:46.
[00:50] <cetex> shouldn't be an issue usually, i switched batteries today when i had ~3minutes left in total, i plugged the battery in, and in slightly less than one minute the os shutdown causing me to loose some work. (i'll remember to switch earlier in the future though)
[01:02] <cetex> i'll look into it some more tomorrow. will probably be back. ping me if anyone would happen to be interested.. ;)
[22:43] <miseria> "El Tiempo no agrada a todo el mundo, libre albedrio, quien seria yo si pudiera hacer lo que el tiempo no puede?" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*