[00:41] <Majost_> Is there a way to delete a PPA so that I can rename myself?
[00:41] <Majost_> its empty anyway, so I wont be loosing any data
[00:41] <Majost_> losing rather
[00:45] <Noldorin> launchpad bzr is down at the moment?
[00:46] <thumper> Noldorin: what do you mean exactly?
[00:47] <thumper> Majost_: https://answers.edge.launchpad.net/soyuz/+faq/569
[00:49] <Noldorin> thumper, i'm suddenly getting a nasty error when trying to push.
[00:50] <thumper> Noldorin: what error?
[00:50] <Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr push lp:ir
[00:50] <Noldorin> cdotnet --no-strict
[00:50] <Noldorin> bzr: ERROR: Connection error: Could not resolve 'edge.launchpad.net' (11004, 'ge
[00:50] <Noldorin> taddrinfo failed')
[00:51] <wgrant> Your DNS resolution is broken.
[00:51] <Noldorin> thumper, not to worry. my dns server is down :P
[00:51] <Noldorin> yeha
[00:51] <Noldorin> just realised that lol
[00:51] <thumper> Noldorin: :)
[00:52] <thumper> Noldorin: how are you finding vs2010?
[00:52] <Noldorin> cheers anyway
[00:52] <Noldorin> thumper, pretty good. i wasn't too impressed with beta 1, but beta 2 has proven stable enough to use for daily work
[00:52] <Noldorin> the testing framework is actually pretty nice
[00:52]  * thumper nods
[00:53] <Noldorin> the editor has some more eye candy and a few more helpful features.
[00:53] <Noldorin> and i hear the RC is blazing fast, which is what i'm really looking forward to.
[00:53]  * Noldorin is about to upgrade now
[01:25] <wgrant> Can I change the default sort order of bugs from heat to something that sucks less?
[01:25] <wgrant> Like, say, most recently changed. That was actually useful.
[01:28] <spm> gawd yes - esp when it comes to tracking down persons who futz with bugs....
[01:37] <thumper> spm: got a minute for a quick call?
[01:37] <spm> thumper: sorta, yes. am doing U1 madness atm, but yeah...
[01:37]  * thumper waits for spm to skype up
[01:38] <spm> skype me baby. skype. me.
[01:55] <hggdh> what should be done with a real spam comment in a bug? Open a question for the admins to deal with the user?
[01:56] <hggdh> c.f. https://bugs.edge.launchpad.net/ubuntu/+bug/363691/comments/7
[02:01] <spm> hggdh: ta, will delete.
[02:02] <hggdh> cool, thank you
[02:11] <micahg> spm: should answers be filed for such things?
[02:12] <spm> micahg: that's the preferred method, yes; I'm just a tad distracted so went for the easy option today.
[02:12] <micahg> spm: k, I get htem on occasion, so good to know
[02:13] <spm> micahg: sure; just create a new request and we'll deal with em. it's still a painful process atm. but we live in hope.
[02:13] <wgrant> spm: Why's it painful? Isn't there a trivial API call now?
[02:16] <spm> wgrant: well. most "this is spam requests" are via a URL link above. anything that sends me away from the obvious place - eg the webbrowser that is now showing that page, is QED painful. need to login to server; setup env; call horrible cmd line webbrowser; run suitable magic copying correct places from above. my 2c, the sql method is simpler.
[02:16] <spm> it may be a trivial api call; but the use of that is awful.
[02:16] <wgrant> spm: Sounds like you need a few lines of Greasemonkey to display a link on the comment in the browser.
[02:17] <spm> probably... an admin viewable only button would be nice too. :-)
[02:17] <wgrant> That oo.
[02:17] <wgrant> +t
[02:18] <Peng> Is it just me or does the puller use an excessive number of HTTP connections?
[02:18] <lifeless> Peng: are you asking if it pulls excessively?
[02:18] <lifeless> Peng: what would you consider excessive?
[02:18] <Peng> lifeless: No, I mean the number of TCP connections seems oddly high.
[02:19] <Peng> Not dangerously -- my web server has only turned it away once -- but still.
[02:19] <Peng> It's hard to be sure, because I don't track that information, and it's usually pulling several branches at once.
[02:21] <Peng> Hmm, the one time I counted 6 TCP connections at once, it was checking 5 branches.
[02:25] <spm> Peng: ahh. yes. it does. there should be abug for that....
[02:40] <Laibsch> LP still oopses when I try to convert bug 464060 even a few weeks after I initially reported the issue.  Today's oopses: OOPS-1507A219 and OOPS-1507L246
[02:43] <thumper> Laibsch: that stinks of a missing index
[02:44] <thumper> hmm...
[02:44] <thumper> no staying power
[02:45] <spm> Peng: found it.  When's the next performance review cycle?
[02:49] <lifeless> spm: the 360' ;)
[02:50] <spm> lifeless: clearly you *were* a sysadmin. such evil. impressive. :-D
[02:50] <Peng> It mirrors most of my branches at about the same time because whenever something breaks and it stops mirroring them, I click all the "Try again" buttons at once. :D
[02:51] <lifeless> spm: its like riding a bike
[02:52] <spm> Peng: Ah Ha!  Right. Fix coming up. /me goes to suspend pengs account....
[02:53] <Peng> spm: I'm usually not the one who broke my branches, though. :P
[02:53] <spm> heh
[02:58] <ojwb> hi, I just got a timeout error from launchpad
[02:58] <ojwb> but the error page oddly tells me:
[02:58] <ojwb> "Our edge server has a lower timeout threshold than launchpad.net, so we can catch those before they hit a wider audience. As a member of the Launchpad Beta Testers team, you're more likely to experience them. If this is blocking your work, you can disable redirection."
[02:58] <ojwb> AFAIK (and launchpad seems to agree) I'm not a member of that team
[02:58] <Peng> ojwb: Were you on https://*.edge.launchpad.net/ or https://*.launchpad.net/?
[02:59] <Peng> IIRC that page always says you're on edge, even when you're not.
[02:59] <ojwb> "(Error ID: OOPS-1507F245) " and "(Error ID: OOPS-1507G246)"
[02:59] <ojwb> I wasn't on edge
[03:01] <ojwb> Peng: it's a bit confusing if it always says that - I wondered if I'd somehow been added to that team
[03:01] <wgrant> Yes, the logic used to display that message is reversed.
[03:01] <wgrant> It has been for several months.
[03:01] <wgrant> But nobody has fixed it yet.
[03:01] <Peng> Oh, there is logic, but it's reversed? Funny. :)
[03:03] <wgrant> Bug #403863
[03:06] <nigelb> hm, LP down?
[03:07] <wgrant> nigelb: Looks OK to me.
[03:07] <ojwb> not for me
[03:07] <nigelb> wgrant, probably jut a random failure.  Let me refresh again
[03:08] <ojwb> not down for me, I mean, just to be clear
[03:12] <nigelb> hehe, it works fine now.  It was some random failure.  :)
[10:30] <bunjee> Hi Guys.
[10:30] <bunjee> I'm currently downloading the sources of Launchpad through the installer, and this seems to be rather slow, I'm stuck at 33760 or something and it freezes from time to time
[10:30] <bunjee> Can we download them from another place?
[10:35] <geser> can someone with access to the gina logs (bigjools?) please look why gina didn't pull the "clxclient" package from Debian unstable? LP Debian "mirror" has 3.6.1-1 while Debian unstable has 3.6.1-1.1 (uploaded on 2010-02-05)
[11:19] <jml> ronoc, hi :)
[11:20] <jml> ronoc, so, you're trying to merge lp:~cjcurran/wasilla/indicator-sound-default-sink-trace/ into its parent lp:indicator-sound and it's not working
[11:20] <jml> ronoc, what's the error you're seeing?
[11:20] <ronoc> yep
[11:20] <bigjools> geser: no errors in the gina log, I'll check the mirror process
[11:20] <ronoc> on launchpad it says - branch is not mergeable into lp:indicator-sound
[11:21] <jml> ronoc, oh. hmm. I think I know this.
[11:22] <jml> ronoc, Launchpad, for reasons that escape me now, only allows you to merge branches that are in the same project, or the same package, or merge between upstreams and their packages
[11:22] <jml> ronoc, indeed, there may even be a bug filed for this...
[11:22] <ronoc> ahh okay
[11:23] <ronoc> jml: so if i push this branch to :~cjcurran/indicator-sound would it work then
[11:24] <jml> ronoc, yes, that's right.
[11:25] <ronoc> jml: thx will try that now
[11:29] <jml> ronoc, https://bugs.edge.launchpad.net/launchpad-code/+bug/446716 is probably the most relevant bug for you
[11:30] <ronoc> jml: thx
[12:19] <maxb> If there's a LOSA around with a spare moment, could you look at https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred and tell me why it's disabled?
[12:20] <mthaddon> maxb: I think you'd need to ask jelmer about that
[12:21] <lool> Hey there, perhaps related to the above, the Launchpad bzr mirror of https://buildd.debian.org/git/packages-arch-specific.git/ wasn't updated in the last days and I'm waiting on a Pas commit to enable building of valgrind on armel
[12:21] <jelmer> hi maxb, mthaddon
[12:21] <maxb> mthaddon: jelmer doesn't know. I think he even has a Launchpad question open asking why
[12:21] <lool> https://code.launchpad.net/~cjwatson/packages-arch-specific/sid / lp:packages-arch-specific is the branch I'd like to see updated with the latest commits
[12:21] <jelmer> mthaddon: The web UI doesn't allow me to change whether that mirror is enabled
[12:21] <jelmer> maxb: There's an open bug on launchpad-code
[12:21] <maxb> Could it be to do with differing bzr format between launchpad and the remote end?
[12:22] <mthaddon> jelmer: nothing in the web UI for me either
[12:22] <wgrant> lool: It says "Contact cjwatson for updates."
[12:22] <lool> Oh actually the branch says "contact cjwatson"
[12:22] <lool> wgrant: Ack
[12:22] <lool> Sorry about that
[12:23] <lool> Thanks all!
[12:26] <maxb> If no one knows why it's disabled, what's the appropriate next step?
[12:31] <mars> Good morning Launchpad
[12:39] <mars> bunjee, we used to have the sourcecode as a tarball, but I can't find the download page.
[12:39] <mars> might have been too much out of date
[12:39] <wgrant> It has indeed been removed.
[15:10] <kwwii> can anyone tell me how to add upload bits to for another user on our private ppa?
[15:11] <mars> bigjools, ^ ?
[15:15] <noodles775> kwwii: You need to be a member of the team that owns the private ppa to have upload rights. So you could sign their upload?
[15:17] <noodles775> kwwii: or did you mean how can you grant them access to upload themselves? If so, add them to the owning team (if that's what you really want).
[15:20] <kwwii> noodles775: I want them to be able to upload without help from me ;)
[15:20] <kwwii> noodles775: I'll check on the team stuff and see if I can figure it out, thanks
[15:21] <bigjools> kwwii: you can add upload rights for a person outside the team using the API
[15:21] <bigjools> or just add them to the PPA team
[15:26] <kwwii> bigjools: the person I want to have upload rights is already on the team
[15:26] <bigjools> kwwii: then they already have upload rights
[15:26] <kwwii> bigjools: ok, then there must be something else wrong, thanks
[15:27] <bigjools> kwwii: ok let me know if I can assist
[16:29] <jamalta> hi, i'm having an issue pushing to a bzr branch but it's an error i hadn't seen before
[16:29] <jamalta> http://paste.ubuntu.com/376946/
[16:29] <jamalta> any clue what it could mean?
[16:32]  * mars looks
[16:33] <mars> jamalta, have you successfully pushed to that branch before?
[16:36] <mars> jamalta, that looks like a simple permissions problem: what is your username?  Are you a member of the ~zeitgeist team?
[16:36] <jamalta> mars: yes
[16:36] <jamalta> no, but i'm the maintainer of that project
[16:36] <jamalta> jamalta is the username
[16:37] <jamalta> and by yes, i meant i have been able to push to that branch before
[16:38] <jamalta> mars: oh wait, yeah i get why now
[16:38] <jamalta> sorry
[16:38] <mars> jamalta, out of curiosity, what was the solution?
[16:39] <jamalta> mars: i haven't fixed it yet
[16:39] <jamalta> but i just realized the branch is owned by ~zeitgeist and i'm not a part of the team anymore
[16:41] <mars> If you do not want to wait to join the team you could just push it to ~jamalta/zeitgeist-project-website/trunk instead
[16:41] <jamalta> mars: right letm e try that
[16:42] <mars> later they will have to merge your changes, or give you team access.  But at least the code will be online for others to review.
[16:43] <jamalta> yeah
[16:43] <jamalta> i think i may just take ownership of that branch instead and make mine the trunk
[16:43] <thekorn> jamalta, I can make you member of the team, if you like
[16:44] <jamalta> thekorn: i think seif wants to create a zeitgeist webstie team
[16:44] <jamalta> instead
[16:44] <thekorn> ah ok
[16:45] <dnjl> hi, i've got a problem with launchpad builds: http://launchpadlibrarian.net/39221345/buildlog_ubuntu-hardy-i386.libvirt_0.7.6-2ubuntu0~dnjl0~hardy0_FAILEDTOBUILD.txt.gz
[16:45] <dnjl> it complains about unmet dependencies udev (>=111-0ubuntu1) and initramfs-tools (>=0.85eubuntu24). But in hardy there are already newer versions available (udev >=117 and  initramfs-utils >=0.85eubuntu36).
[16:45] <dnjl> What is the problem and how can I resolve this?
[16:45] <mars> bigjools, ^ ?
[16:45] <bigjools> otp, one sec
[16:46] <mars> bigjools, unless someone else from soyuz has a sec to help dnjl?
[16:46] <bigjools> noodles775 perhaps
[16:46] <dnjl> the same happens in intrepid - but in jaunty+ it works
[16:59] <dnjl> re
[17:07] <geser> dnjl: the "problem" is that there is somewhere a (version) conflict in the dependency-chain for lvm2 (but apt only lists the top-most package)
[17:09] <kwwii> bigjools: I simply cannot figure this out...a member of the team can see the ppa page, etc but when he uploads a package it accepts it but does not show it in the ppa list
[17:10] <bigjools> kwwii: https://answers.edge.launchpad.net/soyuz/+faq/227
[17:14] <dnjl> geser: mmh, well - but which lvm2 package? - there is no additional package source containing lvm2
[17:14] <dnjl> mmh, i will do a new test installation...
[17:14] <geser> dnjl: trying to find this out right now
[17:15] <dnjl> kk
[17:26] <jcastro> Lord help me I need to register the sprint for the next UDS in launchpad and I have no idea where the UI for that could possibly be
[17:26] <mars> jcastro, looking.  It may have moved in the 3.0 site re-design.
[17:27] <elmo> jcastro: https://blueprints.launchpad.net/sprints/+new ?
[17:27] <mars> elmo, did you find a link, or hack the url? :)
[17:28] <mars> ah, I see a link: https://edge.launchpad.net/sprints, on the lower right-hand side.  Not the most visible place.
[17:28] <elmo> mars: it's linked off https://blueprints.launchpad.net/ubuntu in a portlet on the right, below the 'Register a blueprint' one
[17:34] <geser> dnjl: found the problem: qemu-kvm: Breaks: udev (< 136-1) but 117-8ubuntu0.2
[17:35] <geser> dnjl: qemu-kvm 0.12.2-0ubuntu6.1~dnjl0~hardy2
[17:37] <dnjl> geser: ah, well - thanks! How can I resolve this myself in future?
[17:38] <dnjl> or does anyone know a good dependency-analyzing-tool?
[17:39] <james_w> dnjl: chdist in devscripts can help with this task
[17:40] <geser> dnjl: I used a pbuilder, setup all used repos and tried to install the build dependencies like mention in the changelog, got the error message, added the mentioned package (here udev) to the list of to be installed packages until you get the to real error
[17:43] <dnjl> james_w, geser: thanks very much!
[18:17] <Lns> Hi all
[18:23] <Lns> I had an idea the other night.. are there any facilities for something of a "virtual ppa" ? What I mean is, maybe a PPA URL that simply 'contains' an administrated list of other PPAs..kind of like a ppa group
[18:29] <maxb> Lns: No, there aren't. I can't imagine any truly useful uses which wouldn't be big holes in the apt gpg signing scheme
[18:29] <akheron> https://launchpad.net/~petri/+archive/ppa/+files/jansson_1.2.orig.tar.gz gives 404 even though it's in .changes and there's a link to it in package details page
[18:31] <Lns> maxb: well I haven't thought through the GPG signing, but just think of being able to point to a single central "virtual ppa" that could be administrated on the back-end, who could add/delete PPAs from it and not have to touch the possibly hundreds of servers' sources.list(.d)
[18:31] <Lns> would save a lot of admin time and headache
[18:32] <Lns> as long as it's secure and verifiable, of course!
[18:33] <maxb> Lns: Well, consider this: *either* you require that the owner of the virtual PPA sign off manually on every package change ... in which case you can achieve that by copying packages into the new PPA ... *or* you let it all happen automatically, in which case you have to have complete trust in _every_ included PPA.
[18:34] <Lns> hmm
[18:34] <maxb> Also... if you have means to roll out updates to those servers, you have means to roll out changes to the sources.list :-)
[18:34] <Lns> Wouldn't there be a way to verify GPG keys in LP itself for the vppa?
[18:35] <Lns> before it links new versions perhaps?
[18:35] <Lns> maxb: True, but it's an extra step that could be avoided :)
[18:35] <maxb> It's not a question of verifying keys. It's a question of trusting the union of uploaders to all subscribed PPAs
[18:35] <Lns> true
[18:35] <Lns> I definitely see the security concern
[18:35] <Lns> kinda trusting someone's brother's friend type of thing
[18:36] <maxb> Lns: So make a package containing /etc/apt/sources.list.d/Lns-favourite-ppas.list and install that on all your servers :-)
[18:36] <Lns> maxb: hehe, i guess that's a good workaround!
[18:39] <Lns> I dunno, it was just a thought I had the other night. I work with the edubuntu / ltsp communities and there are a lot of PPAs around that help out stuff with those, was just thinking of a neat way to consolidate that kind of thing
[19:17] <mars> akheron, that is odd.
[19:18] <mars> akheron, If no one can help before tomorrow, consider pinging bigjools or noodles about it.  It is evening for them, but they should be online again ~14h from now.
[19:35] <geser> akheron: http://ppa.launchpad.net/petri/ppa/ubuntu/pool/main/j/jansson/jansson_1.2.orig.tar.gz works, so it looks like only the web ui has a problem with it
[19:46] <akheron> geser: yep
[19:46] <akheron> mars: ok
[19:47] <mars> akheron, as you and geser said, looks like a web UI bug.  Would you mind filing a bug in Launchpad for it? https://launchpad.net/launchpad/+filebug
[21:34] <mars> good night everyone!
[21:38] <thumper> night mars
[22:44] <ahasenack> I wonder why a failed PPA build eats up that version/revision number. It was never published (because the build failed), so why blacklist that version and revision number?
[22:45] <geser> ahasenack: but the source was published
[22:46] <ahasenack> does this error mean that upstream at some point released a different tarball under the same version? "File puppet_0.25.4.orig.tar.gz already exists in puppet, but uploaded version has different contents."
[22:46] <ahasenack> geser: thanks
[22:47] <maxb> It means that differing tarballs have come into existence. You'll have to evaluate whether it was upstream's fault or not
[22:47] <ahasenack> to bypass this I need to download the file from LP and use that one in the upload then, right?
[22:47] <ahasenack> and bump the release, of course
[22:48] <wgrant> First work out where the second one came from, and which one is right.
[22:49] <geser> is keyserver.ubuntu.com having issues again? it takes pretty long to respond
[23:02] <ahasenack> I'm glad release numbers are cheap


[00:21] -queuebot:#ubuntu-release- New binary: scalapack [arm64] (focal-proposed/universe) [2.1.0-2] (no packageset)
[01:18] -queuebot:#ubuntu-release- New: accepted fluidsynth [amd64] (focal-proposed) [2.1.0-1]
[01:18] -queuebot:#ubuntu-release- New: accepted fluidsynth [armhf] (focal-proposed) [2.1.0-1]
[01:18] -queuebot:#ubuntu-release- New: accepted fluidsynth [ppc64el] (focal-proposed) [2.1.0-1]
[01:18] -queuebot:#ubuntu-release- New: accepted pathspider [arm64] (focal-proposed) [2.0.1-2.1]
[01:18] -queuebot:#ubuntu-release- New: accepted pathspider [ppc64el] (focal-proposed) [2.0.1-2.1]
[01:18] -queuebot:#ubuntu-release- New: accepted scalapack [ppc64el] (focal-proposed) [2.1.0-2]
[01:18] -queuebot:#ubuntu-release- New: accepted fluidsynth [arm64] (focal-proposed) [2.1.0-1]
[01:18] -queuebot:#ubuntu-release- New: accepted fluidsynth [s390x] (focal-proposed) [2.1.0-1]
[01:18] -queuebot:#ubuntu-release- New: accepted scalapack [arm64] (focal-proposed) [2.1.0-2]
[01:18] -queuebot:#ubuntu-release- New: accepted fluidsynth [i386] (focal-proposed) [2.1.0-1]
[01:18] -queuebot:#ubuntu-release- New: accepted scalapack [s390x] (focal-proposed) [2.1.0-2]
[01:18] -queuebot:#ubuntu-release- New: accepted pathspider [armhf] (focal-proposed) [2.0.1-2.1]
[01:18] -queuebot:#ubuntu-release- New: accepted pathspider [amd64] (focal-proposed) [2.0.1-2.1]
[01:18] -queuebot:#ubuntu-release- New: accepted scalapack [amd64] (focal-proposed) [2.1.0-2]
[01:18] -queuebot:#ubuntu-release- New: accepted pathspider [s390x] (focal-proposed) [2.0.1-2.1]
[01:18] -queuebot:#ubuntu-release- New: accepted scalapack [armhf] (focal-proposed) [2.1.0-2]
[03:24] -queuebot:#ubuntu-release- New: accepted fwupd [amd64] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.1]
[03:24] -queuebot:#ubuntu-release- New: accepted fwupd [armhf] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.1]
[03:24] -queuebot:#ubuntu-release- New: accepted fwupd [arm64] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.1]
[03:24] -queuebot:#ubuntu-release- New: accepted fwupd [i386] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.1]
[03:59] -queuebot:#ubuntu-release- New binary: fwupd-signed [amd64] (bionic-proposed/main) [1.2~ubuntu18.04.1] (no packageset)
[04:00] -queuebot:#ubuntu-release- New binary: fwupd-signed [arm64] (bionic-proposed/main) [1.2~ubuntu18.04.1] (no packageset)
[04:00] -queuebot:#ubuntu-release- New binary: fwupd-signed [i386] (bionic-proposed/main) [1.2~ubuntu18.04.1] (no packageset)
[04:00] -queuebot:#ubuntu-release- New binary: fwupd-signed [armhf] (bionic-proposed/main) [1.2~ubuntu18.04.1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New: accepted fwupd-signed [amd64] (bionic-proposed) [1.2~ubuntu18.04.1]
[05:14] -queuebot:#ubuntu-release- New: accepted fwupd-signed [armhf] (bionic-proposed) [1.2~ubuntu18.04.1]
[05:14] -queuebot:#ubuntu-release- New: accepted fwupd-signed [arm64] (bionic-proposed) [1.2~ubuntu18.04.1]
[05:14] -queuebot:#ubuntu-release- New: accepted fwupd-signed [i386] (bionic-proposed) [1.2~ubuntu18.04.1]
[05:30] -queuebot:#ubuntu-release- New binary: mumps [s390x] (focal-proposed/universe) [5.2.1-2] (no packageset)
[05:42] -queuebot:#ubuntu-release- New binary: mumps [ppc64el] (focal-proposed/universe) [5.2.1-2] (no packageset)
[05:46] -queuebot:#ubuntu-release- New binary: mumps [amd64] (focal-proposed/universe) [5.2.1-2] (no packageset)
[06:24] -queuebot:#ubuntu-release- New binary: mumps [arm64] (focal-proposed/universe) [5.2.1-2] (no packageset)
[06:38] -queuebot:#ubuntu-release- New: accepted mumps [amd64] (focal-proposed) [5.2.1-2]
[06:38] -queuebot:#ubuntu-release- New: accepted mumps [ppc64el] (focal-proposed) [5.2.1-2]
[06:38] -queuebot:#ubuntu-release- New: accepted mumps [arm64] (focal-proposed) [5.2.1-2]
[06:38] -queuebot:#ubuntu-release- New: accepted mumps [s390x] (focal-proposed) [5.2.1-2]
[07:43] <RikMills> morning.
[07:43] <RikMills> if anyone is around to take a look at https://code.launchpad.net/~rikmills/britney/i386-kf5-badtest/+merge/376824
[07:43] <RikMills> that would be great
[09:15] <seb128> hey there, can someone skip the virtualbox results to let libvncserver migrate? the virtualbox issue is something kernelish, it's not a libvncserver created problem
[10:17] -queuebot:#ubuntu-release- Unapproved: gzip (eoan-proposed/main) [1.10-0ubuntu3 => 1.10-0ubuntu3.1] (core)
[10:18] <rbalint> vorlon, infinity the d/rules change was accidental, it was needed in focal to fix ftbfs
[11:00] -queuebot:#ubuntu-release- Unapproved: rejected gzip [source] (eoan-proposed) [1.10-0ubuntu3.1]
[11:12] -queuebot:#ubuntu-release- New binary: sphinx-copybutton [amd64] (focal-proposed/none) [0.2.5-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- Unapproved: accepted gzip [source] (eoan-proposed) [1.10-0ubuntu3.1]
[11:23] -queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (eoan-proposed) [0.9.4git20190712-0ubuntu4.1]
[11:34] <Laney> vorlon: Don't think so, the last change in there is your and prior to that is from dd_street but we already had that.
[11:34] <Laney> Worth directly investigating I'd say
[11:40] -queuebot:#ubuntu-release- Unapproved: libreoffice (eoan-proposed/main) [1:6.3.3-0ubuntu<IP_ADDRESS> => 1:6.3.4-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[11:55] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (disco-proposed) [3:15.1.1-0ubuntu1.1]
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (disco-proposed) [0.7.12-1ubuntu5.1]
[12:06] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.7]
[12:15] -queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [<IP_ADDRESS>-0ubuntu1]
[14:19] <blackboxsw> morning/afternoon folks. infinity or sil2100 if someone has a chance today. We have the cloud-init SRU verification complete for X , B D and E (19.3.41) per bug #1854872 that needs final review.
[14:35] <marcustomlinson> sil2100: hey! sorry to bug you, if you have time today could you please have a look at my libreoffice sru in eoan?
[14:37] <marcustomlinson> sil2100: it's been built in a ppa, autopkgtests for all arches pass, and manual testing pass too
[17:07] <sil2100> o/
[17:07] <sil2100> blackboxsw, marcustomlinson: ok o/
[17:08] <marcustomlinson> sil2100: thank you!
[17:13] -queuebot:#ubuntu-release- New binary: flowblade [amd64] (focal-proposed/none) [2.4-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: htslib [amd64] (focal-proposed/universe) [1.10-2] (no packageset)
[17:15] <sil2100> blackboxsw: ok, looking good, releasing o/
[17:16] -queuebot:#ubuntu-release- New binary: htslib [ppc64el] (focal-proposed/universe) [1.10-2] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: htslib [arm64] (focal-proposed/universe) [1.10-2] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: htslib [armhf] (focal-proposed/universe) [1.10-2] (no packageset)
[17:33] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu16]
[17:33] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu16]
[17:33] -queuebot:#ubuntu-release- New: accepted flowblade [amd64] (focal-proposed) [2.4-1]
[17:33] -queuebot:#ubuntu-release- New: accepted htslib [arm64] (focal-proposed) [1.10-2]
[17:33] -queuebot:#ubuntu-release- New: accepted htslib [ppc64el] (focal-proposed) [1.10-2]
[17:33] -queuebot:#ubuntu-release- New: accepted htslib [amd64] (focal-proposed) [1.10-2]
[17:33] -queuebot:#ubuntu-release- New: accepted sphinx-copybutton [amd64] (focal-proposed) [0.2.5-1]
[17:33] -queuebot:#ubuntu-release- New: accepted htslib [armhf] (focal-proposed) [1.10-2]
[17:50] -queuebot:#ubuntu-release- Unapproved: glib2.0 (eoan-proposed/main) [2.62.2-2~ubuntu19.10.1 => 2.62.3-2~ubuntu19.10.1] (core)
[18:00] <sil2100> marcustomlinson: at first I was a bit worried about the new noto-extra dep as it's in universe, but then I noticed it's actually a new recommends, phew
[18:01] <marcustomlinson> :)
[18:41] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (eoan-proposed) [1:6.3.4-0ubuntu<IP_ADDRESS>]
[19:03] <marcustomlinson> thanks sil2100!
[19:19] -queuebot:#ubuntu-release- Packageset: Added gcc-10-cross to i386-whitelist in focal
[19:19] -queuebot:#ubuntu-release- Packageset: Added gcc-10-cross-ports to i386-whitelist in focal
[20:51] <cyphermox> vorlon: can you let util-linux through focal-proposed, as mentioned on Friday, ocfs-tools s390x has a RM bug (from tinoco) and openjdk-* has always failed
[20:54] -queuebot:#ubuntu-release- Unapproved: poppler (eoan-proposed/main) [0.80.0-0ubuntu1 => 0.80.0-0ubuntu1.1] (desktop-core, ubuntu-server)
[20:58] <vorlon> cyphermox: I had responded to this on Friday; the openjdk-13 failure was an actual regression that mattered (failed vs neutral) and that has now been resolved
[20:58] <vorlon> cyphermox: openjdk-14 looks like a progression in -proposed, so yes I'll hint around that
[20:58] <cyphermox> I never saw your response, sorry
[21:20] <blackboxsw> sil2100: Thanks a ton! I see rmadison agrees that cloud-init is released
[21:34] -queuebot:#ubuntu-release- Packageset: Removed libdevel-globaldestruction-perl from i386-whitelist in focal
[22:04] -queuebot:#ubuntu-release- Packageset: Added xmlstarlet to i386-whitelist in focal
[22:38] <mwhudson> vorlon: bump livecd-rootfs/i386 hint in focal?
[22:39] <mwhudson> vorlon: or is there some change we should be making so this test stops failing?
[22:58] <vorlon> mwhudson: per the comment in the hint file, the test ought to be changed to test building of the image actually supported on i386 (launchpad-buildd)
[22:59] <mwhudson> vorlon: can i run the i386 autopkgtest locally? do i need to get autopkgtest from focal or something?
[23:00] <vorlon> mwhudson: lp:~ubuntu-release/autopkgtest/+git/development has the code to support -a i386
[23:00] <mwhudson> vorlon: ok
[23:11] -queuebot:#ubuntu-release- New binary: st-console [amd64] (focal-proposed/none) [1.1.4-3] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: st-console [ppc64el] (focal-proposed/none) [1.1.4-3] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: st-console [arm64] (focal-proposed/none) [1.1.4-3] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: st-console [armhf] (focal-proposed/none) [1.1.4-3] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: st-console [s390x] (focal-proposed/universe) [1.1.4-3] (no packageset)


[00:35] <chilicuil> Hi there, I'm trying to automate an install setup, via netboot + preseed, I'd like to reuse the /home partition, is there any way to accomplish this?
[05:16] <cleary> hi folks - anyone awake?
[05:17] <cleary> just wanted to introduce myself, and see if there's any life here for support
[05:18] <cleary> I'm looking at using ubiquity-dm as a base idea for an in-house distro config wizard
[05:18] <cleary> it's going to be quite a steep curve, was hoping that there were some people I could actually bounce ideas off
[05:22] <cleary> during my big debugging session today, I found that if some process has locked the debconf database, ubiquity-dm throws an exception, and ubiquity.conf (upstart) script exits with a return code of 0
[05:22] <cleary> ie silently, so I was finding it would start maybe 2 times in 5, depending on how the timing went
[05:28] <cleary> ...everyone's asleep
[05:28] <cleary> is there a better time?
[05:29] <cleary> I'm on australian eastern standard +10/11h
[05:41] <hychen> when ubiquity runs, it locked the debconf database , you can run another process which uses debconf database , such as apt-get
[05:42] <hychen> s/can/can't/
[05:43] <cleary> hi hychen - yeah I understand this
[05:44] <cleary> it gets tricky though, and I appreciate that this is moving outside the scope of "ubuntu"
[05:44] <cleary> but if something else beats it to the lock
[05:44] <cleary> it still exits cleanly
[05:45] <hychen> does any thing shows in /var/log/installer/debug?
[05:45] <cleary> I anticipate this is unlikely to be a situation ubuntu distro will find themselves in
[05:46] <cleary> hychen: yes, I've identified the issue, which was a company init script
[05:47] <cleary> I'm preparing a little patch for the upstart script to at least not fail silently
[05:47] <cleary> my python foo is not up to doing anything deeper in ubiquity-dm/debconfcommunicator
[05:47] <cleary> (wrt to error handling)
[05:48] <cleary> while this will provide little value immediately
[05:48] <cleary> it may save a few hours debugging in the future for someone
[05:50] <cleary> ...I have a history of difficulties with patches for ubuntu livecd components
[05:51] <cleary> I'm here to try and learn how to do it better/make contact with people who are involved
[05:59] <hychen> you can talk with cjwatson who is involved in ubiquity development. he lives in U.K.
[06:03] <cleary> hychen: great - what sort of times does he come online?
[06:04] <cleary> +usually
[06:04] <hychen> maybe 2 hours later? I am not very sure.
[06:06] <cleary> ok, I'm about to finish work here, my nights for the next week are full though. I will leave this client logged in overnight though
[06:09] <cleary> as a general info thing, we currently run about 200 desktops here on an ubuntu based livecd platform. My new interest in ubiquity is due to the transition from 11.04 -> 12.10 as our base
[06:10] <cleary> I've tried to get in touch with colin before to talk about livecd build methods, but didn't get any response
[06:11] <cleary> I'm planning to publish mine, which are based on the pyfll tool used by the aptosid project - forked to use casper instead of their homegrown liveinitramfs
[06:12] <cleary> ...working through the removal of company specific hacks, and sane packaging is proving the sticking point
[06:13] <cleary> it's all part of my education though - my biggest issue is having a community to interract with
[06:15] <cleary> I don't know if it's timezones or what, but I struggle to get a peep out of most irc project support channels I go to (with hundreds of nicks)
[06:16] <hychen> I usually prefer to use mailing list to contact people do not live in the time zone as mine.
[06:17] <cleary> fair enough, as may be apparent from this chat, I'm a bit unstructured
[06:18] <cleary> I find I make a lot of mistakes which are harder to correct quickly via email
[06:18] <cleary> ...something to get good at I suppose
[06:18] <cleary> hychen what's the list for this project?
[06:19] <hychen> 1https://lists.ubuntu.com/mailman/listinfo/Ubuntu-installer
[06:19] <hychen> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-installer
[06:20] <cleary> thanks, I'll try to get some semblance of point to my ramblings and drop something on there
[06:20] <cleary> I appreciate your time, goodnight
[06:20] <hychen> np, :)
[08:38]  * infinity wonders if he cares enough to try to sort out a good way to parallelise d-i builds.
[09:57] <xnox> cleary: sure, if the db is locked ubiquity process will exit with a non-zero code and the upstart job will fail to start.
[09:57] <xnox> cleary: you can see that in the /var/log/upstart/ubiquity.log
[09:58] <xnox> cleary: the way ubiquity is usually customised to become a configuration wizard is either by (ab)using oem-config mode of ubiquity (where the install has finished already and the end user is customizing their own machine)
[09:58] <xnox> cleary: or by writting additional ubiquity plugins and rebuilding the cd with updated ubiquity.
[09:59] <xnox> cleary: the easiest way to update the livecd is to extract and bindmount the squashfs from the cd, chroot into it, make any changes one needs and the remaster the squshfs and the cd.
[09:59] <xnox> cleary: it is described on the wiki
[12:34] <davmor2> Hey guys this mornings cd the Who are you? page isn't accepting text entry
[12:37] <davmor2> nor is the Keyboard layout page
[12:42] <davmor2> cjwatson: whose best to talk to about this now?
[12:45] <cjwatson> Not sure, let me see if I have time to sync an image before UDS starts
[12:45] <xnox> davmor2: is that on nexus7?
[12:45] <xnox> davmor2: or on desktop?
[12:46] <xnox> there are bugs with compiz/ubiquity/onboard stealing focus from each other and hence not typing properly
[12:47] <davmor2> xnox, cjwatson: Desktop Raring 64bit, On a Lenovo Y580 ideapad, with secureboot and UEFI, selecting the install option from the efi menu.  I have a video of what I get uploading currently I'll share it in a minute
[12:48] <davmor2> I'll try a desktop and install from there next
[12:49] <xnox> davmor2: if you can get internet up, it would be nice for you to try to install metacity and then stop lightdm from tty1 and start ubiquity job again. To see if there is keyboard input when running under metacity instead of compiz.
[12:52] <davmor2> xnox: so drop into tty install metacity, then sudo service lightdm stop, and then do I need to start metacity or just run ubiquity?
[12:53] <xnox> davmor2: stop lightdm; stop ubiquity; pkill -9 X; apt-get install metacity; start ubiquity
[12:53] <davmor2> xnox, cjwatson: http://ubuntuone.com/7OWyqUhmkKeS64gopn5HoQ that's the video
[12:54] <davmor2> xnox: right give me a couple of seconds then
[13:01] <davmor2> xnox: bingo that's worked now
[13:14] <xnox> davmor2: cjwatson: i ponder we should revert to metacity for now in raring and eventually switch to mir.
[13:15] <davmor2> xnox, cjwatson: do you want me to file a bug for this?
[13:15] <xnox> davmor2: bug 1093050
[13:15] <ubot2`> Launchpad bug 1093050 in ubuntu-nexus7 "compiz dies during oem-config and steals the focus so that input fields are unusable" [High,Confirmed] https://launchpad.net/bugs/1093050
[13:16] <xnox> davmor2: do you by any chance have `ls /var/crash/*.crash` something for compiz?
[13:16] <xnox> davmor2: it would be interesting if you can upload a compiz crash from there to somewhere.
[13:20] <davmor2> xnox: meh I have installed the system, the only crash I have is whoopsie (I'm looking at you ev ).  I'll keep a hold of the cd and I can reinstall, but I'm coming down to Bluefin Tomorrow so I need to prep this machine now.  On friday I'll redo and see if I get a crash report on the failed to install system for you
[13:21] <davmor2> xnox: or I might try it on a box that isn't coming down to London tomorrow, later.
[13:25] <xnox> davmor2: I'm based in london. I can come it tomorrow (although I was not planning) to play around with that machine?
[13:26] <xnox> davmor2: or is that too much bricks to bring in for you? =))))
[13:26] <davmor2> xnox: it's the machine I'm bringing.  I'll need to do some work there which is why I'm going into bluefin
[13:27] <davmor2> but you can certainly have a play in the afternoon
[13:29] <xnox> davmor2: ok. Ping me tomorrow =)
[13:29] <davmor2> xnox: will do
[14:32] <ev> davmor2: whoopsie is crashing on you?
[14:32] <davmor2> ev: on install
[14:32] <ev> davmor2: please make sure you file that one
[14:32] <ev> on errors.u.c
[14:33] <davmor2> ev: Already known bug apparently
[14:33] <davmor2> ev: triaged iirc
[14:33] <ev> okay
[14:35] <xnox> davmor2: bug number?!
[14:39] <davmor2> xnox: I'm just hunting it now
[14:39] <davmor2> xnox, ev: bug #1124293
[14:39] <ubot2`> Launchpad bug 1124293 in whoopsie (Ubuntu) "whoopsie crashed with SIGSEGV in nm_state_change()" [Medium,Triaged] https://launchpad.net/bugs/1124293
[14:39] <ev> oh yes, that one
[14:40] <davmor2> ev: I can file a fresh one if you want
[14:40] <ev> I think it was fixed
[14:40]  * ev digs
[14:40] <davmor2> ev: it says triaged not fixed
[14:46] <ev> davmor2: it was fixed in 0.2.14
[14:46] <ev> thanks for pointing me at the bug
[14:46] <ev> I've closed it out
[14:46] <davmor2> ev: glad to of helped
[14:47] <ev> :)
[14:47] <davmor2> ev: you in bluefin tomorrow?
[14:47] <ev> yup
[14:47] <ev> will you be here?
[14:57] <xnox> ev: yes, he will be.
[14:59] <ev> wonderful
[21:44] <cleary> hi xnox - thanks for the info
[21:45] <cleary> regarding the live cd changes, I have a 'mastering' approach for that (I make my own from scratch, per se) - it's about a 4 min build process which is quicker than any remaster I've ever done
[21:46] <cleary> for the ubiquity plugins, an apt search yields mythbuntu-live-autostart
[21:46] <cleary> I've also seen the ubiquity-slideshow-kubuntu - are these examples of ubiquity plugins worth having a look at?
[21:56] <superm1> cleary: the mythbuntu ones aren't updated for python3 yet
[21:56] <superm1> cleary: but they are certainly representative of what you can do with ubiquity plugins
[21:57] <cleary> superm1: thanks for that - having a poke through it now :)
[21:57] <cleary> s/it/them
[21:58] <superm1> cleary: sure.  i also have put a fair deal of work into two plugins in dell-recovery
[21:58] <superm1> they're quite a bit more intense in the work they do
[21:58] <cjwatson> superm1: Um, I thought I'd done the Python 3 port last year/
[21:58] <cjwatson> ?
[21:59] <cjwatson> see revision log in https://code.launchpad.net/~mythbuntu-dev/mythbuntu/mythbuntu-live-autostart
[21:59] <superm1> cjwatson: for dell-recovery yes, mythbuntu stuff not entirely functional right now
[21:59] <cjwatson> yeah, I thought I'd done it for mythbuntu too
[21:59] <superm1> i was actually just testing them on raring and hitting some problems
[21:59] <cjwatson> is there a bug with logs?
[21:59] <cjwatson> I mean if you prefer to just fix it then be my guest, it's just a surprise that it's broken in a py3-specific way :)
[22:00] <superm1> well they're broke I suspect because mythbuntu-common didn't come to python3 yet and can't with some dependencies that aren't python3 yet
[22:00] <cjwatson> Ah
[22:01] <superm1> but i didn't review the logs closely, just noticed that when i was bringing some of our other tools up to python3 hitting those problems
[22:02] <superm1> the two big ones are python-mysqldb and python-pexpect.  pexpect forked and has a fork that supports python3 but mysqldb upstream just says they're working on it, so we'll see what's best approach
[22:03] <cjwatson> do you really need pexpect?  there are often other ways ...
[22:03] <cjwatson> IIRC anyway
[22:04] <cleary> superm1: realistically, my requirements are basic. If there's code available for your dell ones, I wouldn't mind having a look for curiousity sake
[22:04] <superm1> yeah i think pexpect i'll come up with something else clever, it was just convenient when it was added
[22:04] <superm1> cleary: lp:dell-recovery
[22:04] <cleary> ta
[22:05] <cjwatson> right, time to not be on the computer for a while, shock horror
[22:07] <cleary> superm1: are you a dell employee?
[22:07] <superm1> cleary: yeah
[22:08] <cleary> very interesting :)
[22:09] <cleary> we're big dell fans here - we are a large wine company (3 wineries) with their head office operating off a farm in rural australia
[22:09] <cleary> dell is the only company that honours their next-business-day support options on desktops
[22:09] <cleary> ...out here at least
[22:10] <superm1> great to hear :)
[22:10] <cleary> the linux offerings, while a bit meagre, are also something we're actively supporting
[22:10] <cleary> can't complain about lack of support, but then not support anyone who does something
[22:11] <superm1> unfortunately australia gets grouped with APJ, so you will probably miss out on the offerings we generally make in the US and Europe as they happen
[22:12] <cleary> yeah we have noticed that, ultimately it's not a big drama for us
[22:12] <cleary> I'm maintaining an in-house distro anyway
[22:13] <cleary> we still make a point of buying ubuntu pre-installed where we can - get those sales numbers up
[22:13] <cleary> I'm not sure the demand here is even a blip on the rest of sales, but once again
[22:13] <cleary> we have to support where we can
[22:15] <cleary> I've got coffee to get and training to do - I'll duck off for a bit. Thanks for the chat/info
[22:16] <superm1> well thanks for the support where you can :)
[23:15] <xnox> cleary: plugins as in see /usr/lib/ubiquity/plugins/*
[23:15] <xnox> cleary: or lp:dell-recovery


[04:47] <c|oneman> lxpanel is freaking shit compared to the Win98 start menu
[04:48] <c|oneman> where’s “open file location” and other useful right-click menus?
[04:55] <guiverc> c|oneman, please mind the language...
[05:46] <guiverc> c|oneman, i really have no idea what you're asking.  right click menu's vary on what application is running, openbox if wallpaper, pcmanfm if file manager, etc options can be disabled; so if disabled/changed fewer, or more may show..
[05:48] <c|oneman> I mean the “start menu” , this is complaint I have with all Desktop Environments. I can’t do enough with the application shortcuts
[05:50] <c|oneman> I guess it’s just “open file location” no in Windows 10, they mangled it there too...
[05:52] <guiverc> LXDE is pretty much on life-support (by raspberry pi folks); it was replaced with LXQt for Lubuntu; LXDE used the old GTK+2 toolkit from long-ago (gnome2), thus little effort went into it. It wasn't until 18.10 that the switch to LXQt was finally made (using Qt5 toolkit)
[06:02] <c|oneman> would you say it’s time to quit lubuntu on 32-bit?
[06:07] <guiverc> I have Lubuntu on a t43 (old thinkpad), which is supported until 2021-April.   I also tried later Lubuntu 18.10/19.04 on it & it was nice; alas x86 support is best with 18.04; 2021-April is still awhile into the future.
[06:12] <guiverc> ^ 18.04 LTS (from 2018-April with 3 years = 2021-April; 5 years applies only to Ubuntu with gnome)
[08:08] <Sealronis> hello
[08:09] <Sealronis> i need an advice
[08:13] <Sealronis> i have a pc, that has 1gb ram and i installed lubuntu 19 there, it is slow and lagging. I tryed to change memory swapping number from 60 to 90 or 100 but that helped only a little to none. That computer has 64-bit architecture and i installed 64 bit lubuntu there, but now im thinking i could try 32 bit and maybe older version. Some people say that
[08:13] <Sealronis> they have run lubuntu on 128-256mb ram, so with correct configuration and maybe older version i should be able to run it on 1gb too
[08:15] <Sealronis> On my main PC i also have this bug where lubuntu starts loading, number of ( OK ) colored text lines go and stops on ( OK ) GNOME Desktop loaded, i assume its because i installed another display manager - lightDM i think its name was and gdm3 and the original one and they must be conflicting, so i guess i need to reinstall new lubuntu.
[08:16] <Sealronis> But the pressing problem is with the 1gb ram computer in about an hour or two i need to install new OS on that pc, so people can use it. Its a public computer.
[08:28] <diogenes_> Sealronis, you can install whatever minimal system you want but, as soon as you open firefox, your ram is dead, ff takes 1Gb+ memory, so with 2Gb ram, you should use a different browser like dilla, epiphany.
[08:29] <Sealronis> asdas
[08:30] <Sealronis> diogenes_, How can i install and use older system version? When i do apt-get update && apt-get upgrade will it install OS to the newest version and slow my pc down again?
[08:31] <Sealronis> I should have started sentence with "Thanks!":(
[08:31] <Sealronis> :)
[08:32] <diogenes_> Sealronis, it will update the current system only.
[08:32] <diogenes_> !upgrade
[08:32] <diogenes_> err
[08:35] <Sealronis> Thats great!
[08:35] <Sealronis> Are older versions supported by Ubuntu repositories still? Can i get newest versions of the apps and use them in say lubuntu 10.0 as well as in lubuntu 19.0?
[08:36] <diogenes_> searnope.
[08:36] <Sealronis> ?
[08:37] <diogenes_> Sealronis, nope, lubuntu is 3 years support.
[08:38] <Sealronis> how do i use older system then ?
[08:39] <diogenes_> you can use it but you can't update, no security, nothing.
[08:41] <Sealronis> if i want libre office, chromium or as you said some other browser, gimp - can i use those?
[08:41] <Sealronis> on 10.0
[08:42] <Sealronis> i dont know what is security and you said i can update it will update only my system
[08:42] <diogenes_> only the older versions.
[08:42] <Sealronis> oh older versions...
[08:43] <Sealronis> how do i know if they will be good enough>
[08:43] <Sealronis> can i make them on public pc and know that they will work properly on all sites people need to go?
[08:46] <Sealronis65> Asd
[08:47] <Sealronis65> Asd
[08:49] <Sealronis65> Trying
[08:50] <Sealronis> Miccheck
[08:52] <Sealronis> Now should be good
[09:00] <Sealronis> Ok i will try 16.04 version which browsers you recommend you said?
[09:02] <diogenes_> dillo, epiphany.
[09:04] <Sealronis> Thanks!!
[19:10] <belmari> belmari
[19:10] <tomreyn> yes that's you


[01:45] <Arkuz> hello
[01:54] <maxolasersquad_h> Hello
[01:57] <Arkuz> How are you?
[01:57] <maxolasersquad_h> Rockin', how about yourself.
[02:08] <Arkuz> Not bad
[02:08] <Arkuz> I'm traveling to miami next week
[02:08] <maxolasersquad_h> Sounds like fun.  Are you going to visit the Linux bar while there?
[02:10] <Arkuz> Maybe
[02:10] <Arkuz> I'll be there for 3 years
[02:11] <maxolasersquad_h> Oh.  We've got a pretty lively crew down there.
[02:14] <Arkuz> Cool.
[02:14] <Arkuz> What do you do for fun out here?
[02:14] <Arkuz> I'm from Germany btw
[02:14] <maxolasersquad_h> Me?  Nothing, I live in Tallahassee.
[02:14] <maxolasersquad_h> I'm about 8 - 10 hours away from Miami.
[02:15] <maxolasersquad_h> The Everglades are pretty awesome.
[02:23] <maxolasersquad_h> I was just showing off the awesome mapping efforts in Germany via OpenStreetMap.
[13:43] <dantalizing> morning
[15:12] <DammitJim> do you guys know a good source of C programming for listening on the serial port?
[20:46] <maxolasersquad> DammitJim: https://raw.github.com/WedgeCoop/IS4C/master/pos/is4c/rs232/scannerscale.c
[20:47] <maxolasersquad> This reads incoming data from an RS232 port and pareses it.
[20:47] <maxolasersquad> Its for reading barcodes comming form a grocery scanner.


[03:54] <Terry_Guo> Hi there, I want to enable my ppa for armhf, but the build will take 10+ hours. can I do this? Thanks.
[08:13] <czajkowski> davmor2: it's never my fault any more :)
[08:14] <czajkowski> Terry_Guo: no it needs to be under 4 hrs
[14:56] <psusi> so.. apport removes the original core dump once it retraces it... how can I pry it out of launchpadlib?  the stack trace just isn't enough, I need to poke around the core a bit
[14:56] <dobey> i don't think you can
[14:58] <psusi> is there someone here with god powers who can? ;)
[14:59] <cjwatson> pretty sure it's actually DELETEd from the db
[15:00] <cjwatson> IIRC you need to get apport not to retrace that next time, and wait for another report.  ask pitti/bdmurray
[15:00] <dobey> yeah, afaik, deleted attachments are gone for good
[15:02] <psusi> you sure?  it feels like it works the way private bugs do... no subscription, no access
[15:03] <psusi> the bug link redirects you to some restricted url with a magic cookie
[15:03] <cjwatson> if you have a link I can take a look
[15:03] <cjwatson> (to the bug)
[15:03] <psusi> https://bugs.launchpad.net/bugs/1231288/+attachment/3841761/+files/CoreDump.gz
[15:04] <cjwatson> I see no redirect
[15:04] <cjwatson> That's just a plain "no such object"
[15:05] <psusi> also one of the dups had its core dump removed and no full stack trace done and was marked as a dup... but based on the limited stacktracetop, it isn't a dup
[15:05] <psusi> right... you don't get the redirect because the file has been removed from the report...
[15:05] <cjwatson> for that you will have to ask apport people
[15:06] <psusi> click on the stacktracetop and you get a redirect
[15:06] <cjwatson> it's not part of Launchpad
[15:06] <cjwatson> psusi: there's no stacktracetop in bug 1205815 ...
[15:06] <psusi> err, ThreadStacktrace
[15:06] <cjwatson> apart from the plain-text mention in the description
[15:06] <cjwatson> ditto
[15:06] <cjwatson> I bet if you reload in a different tab you'll find it's not there
[15:07] <psusi> ohh, the redirect seems to be different now that I made the report public... it had restricted in the hostname or something before
[15:07] <psusi> and a cookie as a & parameter
[15:08] <cjwatson> private objects tend to be in the restricted librarian, yes.  but in this case, it's inaccessible because it's been deleted (by apport-retrace), not because of any privacy setting.
[15:09] <psusi> is there somewhere the apport people hang out?
[15:10] <cjwatson> (at least I believe so.)
[15:10] <cjwatson> psusi: #ubuntu-devel - I already suggested talking to pitti
[15:11] <cjwatson> can't find the deletion code in the retracer right now.  hopefully I'm not misremembering.
[15:11] <cjwatson> (in a meeting)
[15:14] <cjwatson> oh yes, found it
[15:14] <cjwatson>                 if a.title == 'CoreDump.gz':
[15:14] <cjwatson>                     try:
[15:14] <cjwatson>                         a.removeFromBug()
[15:14] <cjwatson> which deletes the LFC reference immediately
[15:15] <psusi> right... removes the reference from the bug report... but it is still burried somewhere in the librarian right?  just no reference to it any more
[15:16] <cjwatson> it is I suppose possible that it hasn't been GCed yet, but since it's private you can only get at it through the webapp, and the webapp isn't going to let anyone have it since it isn't referenced from anywhere with any sharing enabled ...
[15:16]  * psusi misses the old netware salvage utility... find those unlinked files and recover those babies
[15:17] <cjwatson> wgrant might know if there's a way, but my suspicion is that you're out of luck
[15:19] <cjwatson> but, removed at 07:39, and librarian-gc runs at 10:15
[15:19] <cjwatson> I suspect it's already eaten your lunch
[15:27] <kirkland> is there any way to post something at the top of my projects' Answer pages that says "Please stop asking questions here and go to AskUbuntu!" ?
[15:28] <smartboyhw> kirkland, wow, what happened?
[15:28] <smartboyhw> (/me thinks you can only make it in the description of your project, BTW0
[15:33] <kirkland> Hmm, okay, looks like I can disable answers... I really just want to leave a symlink to the other location
[15:51] <dpm> hi all, would anyone know what this error coming from a package on the core apps PPA could be? It seems the amd64 and i386 builds succeeded, but the armhf one had a chroot problem? -> http://pastebin.ubuntu.com/6159236/
[16:24] <dobey> dpm: try to rebuild the failed arm build. looks like it was a problem setting up the chroot
[16:25] <dpm> thanks dobey, will give that a go
[16:37] <cjwatson> dpm: IS has fixed the failure and I'm mass-retrying everything affected now.
[16:39] <dpm> thanks cjwatson
[22:22] <harlowja> a qq for any launchpad experts if anyone is around
[22:22] <harlowja> is there a way to have a blueprint in launchpad span multiple projects?
[22:28] <lifeless> harlowja: no
[22:28] <harlowja> durn


[00:06] <_mup_> Bug #810808 was filed: Formula install hook never completes <Ensemble:New> < https://launchpad.net/bugs/810808 >
[07:56] <kim0> Morning all
[11:51] <DigitalFlux> Morning kim0 :)
[11:52] <kim0> DigitalFlux: Morning o/
[11:52] <DigitalFlux> what is the status of deploying Ensemble's formulas into LXC ?
[11:52] <kim0> an experimental branch exists .. however it's certainly not 'ready'
[11:52] <kim0> you can play freely on ec2 however .. launch micro instances :)
[11:53] <DigitalFlux> i'm guessing this one https://code.launchpad.net/~clint-fewbar/ensemble/lxc-container ?
[11:53] <kim0> yeah should be
[11:53] <DigitalFlux> yeah, that's my plan for today
[11:53] <kim0> what are you going to be working on
[11:53]  * DigitalFlux need to find where to configure ensemble to use micro instances ..
[11:53] <DigitalFlux> The Trac formula
[11:53] <kim0> oh I see
[11:53] <DigitalFlux> https://bugs.launchpad.net/principia/+bug/795480
[11:53] <_mup_> Bug #795480: Formula needed: Trac <bitesize> <Principia Ensemble:New for ahmedelgamil> < https://launchpad.net/bugs/795480 >
[11:53] <kim0> yaay \o/
[11:54] <kim0> let me help with configuring the t1.micro thing
[11:54] <DigitalFlux> kim0: please, go ahead
[11:55] <kim0> DigitalFlux: check out http://fewbar.com/2011/06/so-what-is-ensemble-anyway/
[11:55] <kim0> search for m1.small
[11:55] <kim0> You need to add     default-instance-type: m1.small
[11:55] <DigitalFlux> Ahh, that was a long article :)
[11:55]  * DigitalFlux checking ..
[11:55] <kim0> to ~/.ensemble/environments.yaml
[11:55] <kim0> in your case .. it would be t1.micro of course
[11:55] <DigitalFlux> hehe, looks like i already did that before :)
[11:55] <kim0> cool :)
[11:55] <DigitalFlux>     default-instance-type: t1.micro
[11:55]  * kim0 nods
[11:55] <DigitalFlux> ok neat ..
[11:56]  * DigitalFlux coding his first Ensemble formula :)
[11:56] <kim0> \o/
[11:56] <kim0> DigitalFlux: feel free to grab me any time once you have a question
[11:56] <DigitalFlux> kim0: i will indeed :), Thanks kim0
[12:03] <kim0> RoAkSoAx: morning o/
[12:07] <DigitalFlux> kim0: hmm, here is some point that i want to discuss
[12:07] <kim0> RoAkSoAx: I see you haven't added your cool session yet to https://wiki.ubuntu.com/UbuntuCloudDays/Timetable .. please add one today :) Thanks
[12:07] <kim0> DigitalFlux: shoot
[12:08] <DigitalFlux> kim0: so i looked over the current principia formulas
[12:08] <DigitalFlux> like in case of checking the wordpress formula
[12:08] <DigitalFlux> i see that not all the underlying components are obvious
[12:08] <kim0> like ?
[12:09] <DigitalFlux> where the web server layer is not that shiny here
[12:09] <DigitalFlux> you just install the wordpress package
[12:09] <DigitalFlux> i understand that this may get apache with the default config
[12:09] <DigitalFlux> but is this the perfect way to go .. from the prespective of code reuse ?
[12:10] <DigitalFlux> or will it better to create a separate apache formula and relate it to the wordpress formula ?
[12:10] <kim0> ah .. we just had this discussion yesterday :)
[12:10] <kim0> good question indeed
[12:10] <kim0> so basically .. Ensemble should be getting settable parameters soon
[12:10] <DigitalFlux> I think we're talking about CM vs. packaging here ..
[12:11] <kim0> which would let you choose which web server for example you'd like to use
[12:11] <DigitalFlux> setting the standards in this for Ensemble from the early beginning will solve a lot of formula 'styling' in the future BTW !
[12:11] <kim0> the need is recognized .. the code is already sitting in review queue
[12:11] <kim0> good catch however
[12:12] <DigitalFlux> aha, awesome
[12:13] <DigitalFlux> wow, lots of hooks in mysql :)
[12:13] <DigitalFlux> my expectation is that the mysql formula will have the largest amount of hooks around :)
[12:13] <kim0> DigitalFlux: yes it is growing :)
[12:14] <kim0> DigitalFlux: you only need to worry about db-relation only for starters
[12:15] <DigitalFlux> kim0: well, i originally check it in order to know how it 'automatically' creates and hands random passwords for WP
[12:15]  * kim0 nods
[12:15] <DigitalFlux> kim0: I guess i should do that for Trac/SVN integration ..
[12:15] <kim0> although the beautiful part .. is you don't have to understand it
[12:15]  * DigitalFlux nods
[12:22] <DigitalFlux> Okie
[12:22] <DigitalFlux> How can i set some service config 'parameters' for some formula that should be deployed
[12:22] <DigitalFlux> like where i'm creating a Trac project here, how can i set it's name ?
[12:23] <hazmat> good morning
[12:24] <kim0> hazmat: Morning o/
[12:24] <kim0> DigitalFlux: that's the configuration stuff I talked about earlier, the one that is not ready yet .. for now hardcode some names
[12:24] <DigitalFlux> kim0: i see, ok, good to know, Thanks
[12:26]  * kim0 can't wait for the config-set stuff to land either ;)
[12:29] <hazmat> bug 810765
[12:29] <_mup_> Bug #810765: if a formula in a repo has invalid metadata, it can stop any deploy from the repo. <Ensemble:New> < https://launchpad.net/bugs/810765 >
[12:41] <_mup_> ensemble/deploy-tolerates-broken-formulas-bug-810765 r276 committed by<EMAIL_ADDRESS>[12:41] <_mup_> repository.find ignores invalid formula metadata.
[12:49] <DigitalFlux> I guess there is no Ubuntu EC2 images that can boot on instance-store micro-size, right /
[12:49] <DigitalFlux> ?
[12:49] <hazmat> DigitalFlux, there are
[12:49] <DigitalFlux> only EBS ..
[12:50] <hazmat> oh.. instance-store
[12:50] <hazmat> DigitalFlux, ensemble tries to use ebs for all ec2 instances
[12:50] <hazmat> it should work with instance-store instances though
[12:50] <DigitalFlux> hazmat: aha, i was just booting an instance manually for testing some stuff ..
[12:51] <hazmat> you have to specify the image in default-image-id in environments.yaml
[12:51] <DigitalFlux> lets use the ebs then ..
[12:51] <DigitalFlux> hazmat: yeah, did that, Thanks :)
[13:16] <hazmat> morning niemeyer, fwereade
[13:16] <niemeyer> hazmat: Yo!
[13:16] <fwereade> hazmat: heyhey
[13:17] <fwereade> how's it going?
[13:17] <niemeyer> Man, there's a beep-beep-beep going on here that is driving me crazy
[13:18] <fwereade> hazmat: thanks for the review
[13:18] <fwereade> hazmat: did you get a chance to think over my response?
[13:18] <hazmat> fwereade, np, parts of it still digesting
[13:18] <hazmat> as far i can see even though bootstrap code is reusable, it still needs modification on a per provider basis
[13:19] <hazmat> at least to set the attribute
[13:19] <hazmat> i'm still recovering from a bit of a cold the last few days.. i'll be glad when its gone
[13:19] <fwereade> agreed, but that attribute does actually differ across providers
[13:19] <RoAkSoAx> kim0: howdy! Yeah I'll do this weekend as I'm still unsure on what to do
[13:19] <fwereade> the actual logic -- start a machine with specific variables if there isn't one running already -- is completely generic
[13:20] <hazmat> fwereade, niemeyer last day of the sprint, any conclusions on cobbler integration?
[13:20] <fwereade> and I'm concerned that if we subclass FooLaunchMachine every time we will end up with noticeable duplication
[13:20] <fwereade> hazmat: we have something that runs for andres
[13:21] <hazmat> fwereade, it doesn't need a subclass of launch machine to avoid the pre callback
[13:21] <fwereade> I need to make sure I can duplicate it on my machine before I go
[13:21] <fwereade> and then there'll be a fair amount of work before it's production-ready
[13:21] <fwereade> but it feels like a good first sprint to me :)
[13:21] <fwereade> hazmat: please explain
[13:21] <hazmat> fwereade, cool, so there's another branch that does the cobbler integration?
[13:22] <hazmat> fwereade, the bootstrap has the launch class, it can instantiate, get the variables, modify, and invoke start machine
[13:22] <fwereade> hazmat: at the moment we have lp:~ensemble/ensemble/bootstrap-cobbler
[13:23] <fwereade> hazmat: strongly disapprove of that approach, it makes it hard to change LaunchMachine without changing Bootstrap
[13:23] <hazmat> fwereade, their already intimately connected
[13:24] <hazmat> try changing the scripts output of launchmachine and you have to change them both
[13:24] <fwereade> hazmat: fair point
[13:24] <fwereade> hazmat: I have a half-formed idea that says that would be best addressed by making machine_data/variables more structured
[13:25] <hazmat> its already invoking a public method of launchmachine, this just swithes it to another, cleanups up the data passing, and avoids pushing callback logic manipulating variables into multiple places
[13:25] <fwereade> hazmat: so I *think* it's a data-format connection more than a code-flow connection
[13:26] <fwereade> hazmat: well: it makes it call 2 methods, instead of passing one callback into one method
[13:26] <fwereade> (good point about the unnecessary post_ callback, ty for that)
[13:27] <hazmat> passing callbacks arounds obscures flow, its better to just invoke the method, consume the value, and invoke another method
[13:28] <fwereade> hazmat: my issue is that that means duplicating the existing flow in LaunchMachine.run
[13:28] <fwereade> if we change that, we also have to change bootstrap
[13:29] <fwereade> however, if bootstrap is just using run on its own, which is tested separately, we can be confident that changes to LM that don't affect the interface to run won't affect bootstrap
[13:29] <hazmat> fwereade, it means simplifying the flow in launch_machine.run. imo.. it removes the callback parameter insertion into the deferred chain
[13:30] <hazmat> fwereade, start_machine is also a public method on LM, and tested
[13:30] <fwereade> hazmat: ok, so the choice is between 2 simple flows, in different places, that have to stay the same; or one slightly-more-complex flow in just one place
[13:31] <hazmat> fwereade, re the same, as i said, their already fairly intimately connected, simplifying the flow doesn't change that
[13:33] <fwereade> hazmat: would your perception of the connections be different if variables was a custom object instead of a class?
[13:34] <fwereade> hazmat: because I think the intimacy of that connection is a result of the unstructured nature of that data
[13:35] <fwereade> hazmat: (besides, I thought you were the one arguing for a simpler flow? I'm advocating a slightly more complex flow that eschews duplication)
[13:35] <kim0> RoAkSoAx: okie thanks :)
[13:36] <hazmat> fwereade, no re custom object, i think i've already stated why.. its the callback param to mutate data in a particular order that i take issue with
[13:36] <hazmat> fwereade, we're talking about a single line of duplication
[13:36] <hazmat> and we're removing several lines of complexity and the callback parameters
[13:36] <fwereade> hazmat: well, 2 lines -- I agree it's not really a big issue
[13:37] <fwereade> hazmat: but I've already removed one callback
[13:38] <fwereade> so you seem to be arguing that:
[13:38] <fwereade>         if pre_start_machine is not None:
[13:38] <fwereade>             launch_chain.addCallback(pre_start_machine)
[13:38] <fwereade> is excessively complex, and is better addressed by duplicating a simple flow
[13:38] <fwereade> hazmat: is that an accurate statement of your position?
[13:40] <niemeyer> hazmat: What's that callback param that mutates data in particular order?
[13:41] <hazmat> fwereade, i'm saying that variables = lm.get_machine_variables(); modify_variables(variables); do_something_with_variables();... is cleaner than.. do_something_else(modify_variables_callback)
[13:41] <fwereade> hazmat: in isolation, yes
[13:42] <niemeyer> hazmat, fwereade: Where's that logic?
[13:42] <niemeyer> Just want to follow it
[13:42] <hazmat> niemeyer, common.launch.LaunchMachine.run
[13:42] <fwereade> ensemble.providers.common.launch
[13:42]  * niemeyer looks
[13:43] <niemeyer> I agree with hazmat, I think
[13:43] <niemeyer> Whoever runs run() can do anything before and after it, if needed
[13:44] <niemeyer> hazmat: Is that your point?
[13:44] <hazmat> niemeyer, well i this case the before part is manipulating data internal to that method, the after part callback was already removed
[13:45] <niemeyer> hazmat: So what's your suggestion to address that data?
[13:45] <hazmat> i'm saying the bootstrap can just get the data using the public api of the launchmachine, manipulate it, and call the start_machine api of it
[13:45] <fwereade> niemeyer: but it's not soing stuff before run
[13:45] <fwereade> niemeyer: it's before start_machine
[13:46] <fwereade> hazmat: I think I may be starting to be convinced
[13:46] <niemeyer> fwereade: Yeah, got it
[13:46] <fwereade> hazmat: but I'm still concerned that a change to LaunchMachine.run would require a non-obvious change to Bootstrap
[13:47] <niemeyer> Well..
[13:47] <niemeyer> Hmm
[13:47] <hazmat> fwereade, run shouldn't have any subclass responsibility, they need to implement start_machine.. and changes to the data would incur a need to change.. we need to trust the api we construct, not create holes in them so that the provider can hide from the consumer
[13:48] <niemeyer> That whole machine_data blob of unstructured data is pretty sad, to be honest
[13:48] <hazmat> agreed
[13:48] <niemeyer> Who owns the data?
[13:48] <hazmat> both cloud-init and the provider
[13:48] <niemeyer> If you invert it, get_machine_variables within LaunchMachine will have to take into consideration that someone else is setting packages
[13:49] <hazmat> its constructed from api params, ensemble config, cloud-init defaults, and provider details
[13:49] <niemeyer> hazmat: Not really.. no one owns it.. we just pass it around, and everyone sticks the data in as if it was fine
[13:49] <fwereade> IMO changes to the data are a red herring here, and we can all agree that a more structured solution would make life easier
[13:49] <niemeyer> This should really be a proper object, rather than a dictionary
[13:50] <fwereade> (ok, the whole purpose of the code is to change the data, but it's the control flow we're debating)
[13:50] <niemeyer> fwereade: It is relevant.. if you just invert the order, it will break the logic
[13:50] <fwereade> niemeyer: yes... I don't think I said otherwise
[13:51] <niemeyer> fwereade: You said it was a red herring.. I'm just saying it's relevant
[13:53] <niemeyer> So, yeah.. I suggest we don't address this change right now..
[13:53] <niemeyer> We'll have to change the way in which these methods alter the data
[13:54] <niemeyer> and if we do this, we should really be using a structured object which has add_packages() methods and the such
[13:54] <niemeyer> so that we don't have to worry about who's doing what in which order
[13:55] <hazmat> niemeyer, it doesn't really effect the discussion at hand.. because the underlying data here is ordered
[13:55] <niemeyer> I also agree with fwereade that it's a good thing we have a single place for the run() logic that starts a machine.
[13:55] <hazmat> and its a discussion of the implementation used to effect that ordering, either hidden behind a callback from the consumer, or explicitly ordered by the consumer
[13:56] <niemeyer> Actually
[13:56] <niemeyer> Hmm
[13:56] <fwereade> niemeyer: precisely, I don't know how run() is going to change in the future but I don't want to have to keep Bootstrap's reimplementation i sync
[13:57] <hazmat> the actual api contract for the provider is start_machine, which is the same in either case.. the only purpose of run is to provide data before start_machine
[13:57] <hazmat> bootstrap just does the same
[13:57] <hazmat> imo
[13:58] <hazmat> instead of obscuring flow with a callback only used by bootstrap, just make bootstrap provide the params
[13:58] <fwereade> hazmat: that hadn't been my perspective but perhaps you're right
[13:58] <niemeyer> hazmat: No, the contract is really run
[13:58] <fwereade> hazmat: I'd seen the get_machine_variables and start_machines methods as public just because we expect them to be overridden
[13:58] <niemeyer> hazmat: Hopefully the whole LaunchMachine thing can go away, and bootstrap should actually use provider.start_machine
[13:59] <niemeyer> hazmat, fwereade: All these variables that are being set in the pre_start_hook should really be injected upfront
[13:59] <niemeyer> hazmat: Passed to the method
[14:00] <daker> hello
[14:00] <niemeyer> That would make it a single interface, without any ordering issues
[14:00] <daker> i need some help! http://paste.ubuntu.com/644790/
[14:00] <niemeyer> daker: Hey!
[14:00] <fwereade> niemeyer: but for that we do need a more structured machine_data
[14:01] <fwereade> basically just for the ordering of scripts
[14:01] <niemeyer> fwereade: Not necessarily.. as long as we change get_machine_variables within LaunchMachine to take into consideration that there's pre-exisitng data that may be meaningful, instead of blindly killing everything
[14:01] <fwereade> which I freely stipluate is a mess, and has giant flashing lights saying "this will bite us in the future"
[14:01] <niemeyer> Which was my original point
[14:01] <fwereade> niemeyer: ah, I see
[14:02] <fwereade> niemeyer: but without structured machine_data I think we're still just shuffling the points at which we assume too much around the code
[14:03] <hazmat> niemeyer, its not just pre-existing data, its data that needs to merged in particular order.. the underlying data structure here is a list, the bootstrap needs to have some of its elements added prior to the end of any machine .. to ensure the zk tree is initialized prior to the machine agent firing
[14:03] <RoAkSoAx> daker: try: $PYTHONPATH=`pwd` ./bin/ensemble shutdow
[14:03] <niemeyer> hazmat: Yeah.. which is a terrible terrible interface
[14:03] <RoAkSoAx> daker: try: $PYTHONPATH=`pwd` ./bin/ensemble shutdown
[14:03] <hazmat> fwereade, niemeyer alternatively we could just have this as a flag to get machine variables
[14:04] <niemeyer> hazmat: and why I'm suggesting we don't touch this before we actually want to fix it properly
[14:04] <hazmat> and pass that bootstrap flag to launchmachine.run or provider.start_machine
[14:04] <niemeyer> hazmat: This, specifically, should _really_ go away:
[14:04] <niemeyer>         scripts = vars_out["scripts"]
[14:04] <niemeyer>         machine_agent_script = scripts.pop()
[14:04] <niemeyer>         scripts.extend([
[14:05] <hazmat> niemeyer, agreed
[14:05] <hazmat> niemeyer, the best way to do that atm is to unify the data construction
[14:05] <hazmat> and parameterize it with a bootstrap flag
[14:05] <niemeyer> hazmat: That sounds pretty good, actually
[14:05] <hazmat> it exists the way it does due to its origin as a subclass method
[14:05] <daker> RoAkSoAx, doesnt' work :/ No such file or directory
[14:06] <niemeyer> fwereade: ?
[14:06] <daker> RoAkSoAx, http://paste.ubuntu.com/644795/
[14:06] <fwereade> hazmat, niemeyer: I think so... I was opposed to making B an LM subclass, because it isn't and LM... but I think it's fine to have LM know how to construct a zk instance specifically
[14:07] <fwereade> yep, I think I like that a lot
[14:07] <hazmat> cool
[14:07] <fwereade> make that change and propose again?
[14:08] <fwereade> we maintain machine_data ickiness but at least it's all in one inheritance tree ;)
[14:08] <hazmat> fwereade, make that change, and just add a comment to the mp to that effect, i'll have  a look and approve
[14:08] <hazmat> fwereade, and it also gets rid of the callback param
[14:08] <fwereade> cool, thanks very much
[14:08] <fwereade> indeed :)
[14:08] <fwereade> I was never proposing the callback as a perfect solution... just, to my mind, the least worst of the ones we'd considered :)
[14:09] <fwereade> much appreciated
[14:09] <hazmat> fwereade, np, thanks for discussing
[14:09]  * daker <= SOS
[14:10] <hazmat> daker, your installing ensemble from bzr?
[14:10] <hazmat> daker, we generally recommend people not developing ensemble code to just the ppa which is updated daily
[14:10] <hazmat> daker, in this particular case its a PYTHONPATH issue
[14:11] <daker> there was one from a ppa an i removed it
[14:11] <RoAkSoAx> daker: remove the $ from $PYTHON....
[14:11] <daker> RoAkSoAx, ah
[14:11] <hazmat> daker, RoAkSoAx suggestion looks good to me
[14:11] <hazmat> with the $ removed
[14:11] <daker> works thanks hazmat RoAkSoAx
[14:16] <fwereade> hazmat, niemeyer: it crosses my mind that then the get_instance_id_command method then moves to LaunchMachine
[14:20] <hazmat> fwereade, sounds good.. perhaps renamed get_bootstrap_instance_id()
[14:21] <hazmat> one less provider subclass responsibility on bootstrap.. bootstrap becomes a true generic.. you could even move the launch class to the provider itself and make bootstrap truly generic
[14:22] <hazmat> i guess bootstrap goes away entirely then
[14:22] <hazmat> as a separate command cls
[14:29] <fwereade> hazmat: precisely, I was abut to write exactly that before I got distracted :)
[14:29] <fwereade> hazmat: and you may be right about it going away entriely
[14:29] <fwereade> hazmat: cool :)
[14:30] <niemeyer> Woohay things going away entirely
[14:31] <fwereade> there's nothing quite so nice as deleting code :)
[14:31] <fwereade> anyway all that will have to wait until I have a working cobbler environment
[14:31] <fwereade> which I need before I go away from andres
[14:31] <fwereade> but I think we have a plan :)
[14:34] <fwereade> hazmat, niemeyer: although that actually implies a common MachineProvider base class with a .bootstrap() method
[14:34] <fwereade> ...which then implies that actually a *lot* of methods can be defined on the base class
[14:34] <niemeyer> fwereade: Hm?
[14:34] <niemeyer> fwereade: I don't see how one thing implies the other
[14:35] <fwereade> niemeyer: hmm, perhaps not, just a sec
[14:39] <fwereade> niemeyer: agreed, not implied; we'll see how it looks when we have 2 implementations
[14:41] <jcastro> kirkland: I agree (wrt. figuring out who is working on what in principia)
[14:42] <kirkland> jcastro: well, that, and an easy way to see what's currently in principia
[14:42] <kirkland> jcastro: an equivalent of apt-cache search
[14:42] <jcastro> kirkland: any idea when the whole repository will get hooked up?
[14:42] <jcastro> (heh, that's exactly what I was going to ask, apt-cache search)
[14:43] <niemeyer> jcastro: I've heard Launchpad is going to land the needed changes this week
[14:43] <niemeyer> jcastro: Work starts immediately
[14:43] <jcastro> oh, perfect, that's great timing.
[14:43] <niemeyer> jcastro: and yeah, we'll have ensemble search :)
[14:43] <niemeyer> Oh, and it's Friday.. maybe it's even there arleady
[14:44]  * robbiew notes we need to sort out "principia" as a name
[14:44] <kirkland> jcastro: dunno, SpamapS was on that
[14:44] <jcastro> ok I'll ping him when he's around
[14:44] <jcastro> robbiew: I thought we're just going with "ensemble formulas"?
[14:44] <jcastro> and "ensemble core"?
[14:48] <robbiew> jcastro: well the thread didn't really conclude...so maybe I'll do that now
[14:48] <robbiew> ;)
[14:52] <daker> kim0, check now https://code.launchpad.net/~daker/ensemble/small-fix/+merge/68038
[14:53] <robbiew> jcastro: not so sure we need an "Ensemble core"..."Ensemble" is fine, imo
[14:53]  * jcastro nods
[14:56]  * kim0 disk seems to be dying
[14:58] <lynxman> hey guys *waves*
[14:58] <lynxman> is there anywhere that we'll keep versions of Ensemble in a tar archive?
[14:58] <lynxman> finishing my macports implementation of the Ensemble client :)
[15:04] <hazmat> lynxman, you mean like a release of ensemble. or a release of formulas?
[15:06] <lynxman> hazmat: release of ensemble, the port need somewhere to download a tar from
[15:07] <m_3> lynxman: awesome... tons of devs on mac using ubuntu in the cloud
[15:07] <lynxman> m_3: that's the idea :) hit first and hit nicely
[15:07] <hazmat> lynxman, any chance it could construct one on the fly with a bzr export?
[15:07] <lynxman> hazmat: hmm you'll be making my life miserable doing that :)
[15:08] <lynxman> hazmat: that would mean installing bzr then pulling and so forth, completely foreign to how ports works
[15:08] <hazmat> lynxman, atm we don't have a release.. is my only concern.. i think we where planning on having one in the next few months to coincide with the release of oneiric
[15:08] <hazmat> lynxman, right.. but there are ports that pull from vcs i thought?
[15:08] <lynxman> hazmat: yes but they do nasty stuff
[15:08] <hazmat> niemeyer, release time? ^
[15:08] <lynxman> hazmat: just saying it out loud :)
[15:09] <hazmat> niemeyer, this actually dove tails nicely with what robbiew was mentioning about setting some sort of more stable weekly release
[15:09] <niemeyer> hazmat: robbiew was talking about the sync into Oneiric, IIRC
[15:09] <lynxman> hazmat: oh, that's true
[15:09] <niemeyer> hazmat: We can do a weekly release, though
[15:10] <robbiew> right...and sync them into Oneiric ;)
[15:10] <lynxman> niemeyer: would be okay to get a tar.gz in the ensemble project for the last milestone?
[15:10] <lynxman> niemeyer: that would be easy for me to parse
[15:11] <niemeyer> lynxman: We can do tarballs for sure.. what do you mean by last milestone?
[15:11] <niemeyer> robbiew, hazmat: Yeah, good point
[15:12] <hazmat> lynxman, trunk is stable so we can cut directly from it
[15:12] <niemeyer> robbiew, hazmat: My point was just that we don't need release tarballs to sync
[15:12] <robbiew> ack
[15:12] <niemeyer> robbiew, hazmat: But might be interesting to be more careful about what is going into Oneiric either way
[15:12] <SpamapS> does setup.py produce a good dist output?
[15:12] <lynxman> niemeyer: I mean looking at the ensemble project page, right now last milestone is capetown
[15:12] <lynxman> niemeyer: something like that
[15:12]  * SpamapS just emailed the list with his weekly release plans
[15:12] <niemeyer> SpamapS: bzr export --format=.tar.gz
[15:13] <SpamapS> niemeyer: *OH* right.. thats much simpler. :)
[15:13] <niemeyer> lynxman: CUrrent one is Dublin
[15:13] <niemeyer> lynxman: WE should update it
[15:13] <lynxman> niemeyer: so.. dublin :)
[15:13] <hazmat> SpamapS, it should
[15:13] <niemeyer> lynxman: It's pretty old
[15:13] <SpamapS> niemeyer: at this point, with Oneiric 3 months away, would it make sense to make the next milestone "orlando-2" ?
[15:13] <niemeyer> lynxman: I mean, the last one
[15:14] <niemeyer> lynxman: I'd recommend bzr export --format=.tar.gz
[15:14] <SpamapS> or austin? :)
[15:14] <niemeyer> lynxman: To get going
[15:14] <hazmat> next release name.. startswith 'E', dublin release ends at the end of july afaicr
[15:14] <niemeyer> SpamapS: We'll need something with an E :-)
[15:14] <SpamapS> oh you guys have *got* to stop using the cities we're in
[15:14] <SpamapS> that is *CONFUSING*
[15:14] <SpamapS> I remember now you explained that already
[15:14] <hazmat> dublin was coincidence
[15:15] <niemeyer> SpamapS: It's actually the opposite
[15:15] <lynxman> niemeyer: yeah, the thing is that I can either curl a tar from somewhere (what I was asking at first) or go around doing a whole bzr export, was asking which is better for you guys
[15:15] <niemeyer> SpamapS: Canonical should stop putting sprints in our milestone names!
[15:15]  * SpamapS votes for Entendre as the next release name.. 'ensemble entendre' has a nice french comedic ring to it
[15:15] <niemeyer> SpamapS: ;-)
[15:15] <lynxman> SpamapS: maybe Ecublens? It's a nice city in the French part of Switzerland ;)
[15:16] <lynxman> http://maps.google.com/maps?hl=en&q=ecublens%2C%20ch
[15:17] <lynxman> it's where the EPFL is based
[15:18] <SpamapS> Ooo I like lynxman's
[15:18]  * SpamapS dreams of swiss beer and pretzls
[15:20] <lynxman> niemeyer: so you prefer a bzr branch then... just from trunk?
[15:22] <SpamapS> niemeyer: to lnxman's point, it would be prudent to start branching trunk when a new milestone is started...
[15:22] <niemeyer> lynxman: Just while we don't have actual releases, that would be preferable
[15:22] <lynxman> niemeyer: okay, will try to make it that way, thanks
[15:22] <SpamapS> Once there are releases.. it will be critical... but yeah, w/o a release, they're just points in time.
[15:22] <niemeyer> SpamapS: Not necessarily.. milestones are more organizational than anything else
[15:22] <niemeyer> SpamapS: Weekly releases with proper tagging should be enough
[15:23] <SpamapS> should we just tag w/ the date? 0.5.2011.07.15 ?
[15:25] <niemeyer> SpamapS: Probably just a sequence number on the version itself might be fine
[15:25] <niemeyer> SpamapS: We always have the date out of the revision information
[15:25] <SpamapS> I actually like the way it works now.. 0.5+bzrXXX
[15:25] <SpamapS> because its very clear how to go get that release
[15:25] <niemeyer> SpamapS: Well, we might also do this
[15:25] <niemeyer> SpamapS: Using the revision number
[15:25] <niemeyer> SpamapS: 0.5.XXX
[15:26] <SpamapS> thats what XXX is
[15:26] <SpamapS> oh
[15:26] <SpamapS> the only reason I don't like that, is that its pretending to be a release
[15:26] <niemeyer> LOL
[15:26] <niemeyer> SpamapS: It's not just pretending.. ;)
[15:26] <SpamapS> or at least, pretending to be more of a release than the 0.5 already is pretending
[15:26] <niemeyer> SpamapS: It _is_ a release
[15:27]  * SpamapS thinks a massage is a nice release too.. :)
[15:27] <SpamapS> yeah.. its really not that important...
[15:27] <SpamapS> Oh I was thinking on one other thing..
[15:27] <SpamapS> how about dropping the debian dir from the trunk and nesting the Ubuntu packaging for the daily builds?
[15:28] <SpamapS> Would be good to have a single place for packaging maintenance.
[15:28] <hazmat> SpamapS, sounds good to me.. the ec2-build script should probably get yanked then
[15:29] <SpamapS> hazmat: is that used anymore?
[15:42] <hazmat> SpamapS, nope
[16:04] <kim0|backup> Alright folks .. my disk drive decided to die now, seems like I'll begin a badblocks party .. I'm off next week, so may not be online all the time. see you soon
[16:12] <negronjl> SpamapS, niemeyer, hazmat, m_3, anyone:  why is this happening.  I need help on this.  https://pastebin.canonical.com/49825/
[16:13] <SpamapS> negronjl: IIRC, there's a bug where if any of the formulas in your repository have bad metadata, none of them are deployable.
[16:13] <negronjl> SpamapS:  I fixed that already.  this is different.
[16:13] <SpamapS> oh
[16:13]  * SpamapS waits for the second timeout-refresh of pastebin
[16:13] <jimbaker> negronjl, we really need the debug log to see what's going on
[16:14] <SpamapS> maybe the start hook failed?
[16:14] <SpamapS> or is still running?
[16:14] <jimbaker> negronjl, also, i think it would be best if we used paste.ubuntu.com
[16:14] <negronjl> jimbaker.   ahh...let me re-do it all with debug-hooks, debug-log and pastebin.ubuntu.com ... I'll be back
[16:15] <jimbaker> negronjl, i don't think you need debug-hooks yet :)
[16:15] <SpamapS> negronjl: you can just ssh to the box and look at the formula.log
[16:15] <negronjl> SpamapS:  re-doing it.  I'll get all that info in a minute.
[16:16] <SpamapS> negronjl: /var/lib/ensemble/units/cloudfoundry-server-0/formula.log
[16:16] <jimbaker> negronjl, SpamapS is right... that's all debug-log is doing is aggregating the logs together
[16:17] <jimbaker> in fact one problem with debug-log is that it misses some log info... but as far as i know, just very early in the agent startup process now
[16:17] <niemeyer> negronjl: Best way to find out is log in the machine and read the log
[16:17] <negronjl> niemeyer:  doing that now :)
[16:17] <negronjl> I'll paste it back in a minute
[16:17] <niemeyer> negronjl: We have to create a neat way to just find out the recent logs
[16:17] <niemeyer> negronjl: Not really hard.. just need to put it in place
[16:17] <niemeyer> negronjl: Would be tremendously helpful in these cases indeed
[16:18] <SpamapS> some helpers would do that
[16:19] <SpamapS> sudo 'ensemble-admin tail-logs' would work
[16:20] <jimbaker> SpamapS, sounds like an after the fact debug-log
[16:22] <jimbaker> SpamapS, in general i always run debug-log, might be nice if we made it easier to use, eg, ensemble bootstrap --debug to start debugging immediately
[16:22] <m_3> can debug-log take an arg for unit?
[16:23] <jimbaker> however, the debug log was never designed to be more than a simple solution for formula dev. some sort of log collection tool would be nice to have integrated at some point (to bring back some previous discussion we've had)
[16:24] <SpamapS> m_3: yeah
[16:25] <SpamapS> jimbaker: if it were changed to a ring buffer and always done.. then debug-log would just tap into the ring buffer and keep tailing it.
[16:25] <jimbaker> m_3, it's quite flexible: ensemble debug-log --help http://paste.ubuntu.com/644868/
[16:25] <SpamapS> jimbaker: think 'dmesg'
[16:27] <m_3> ok, didn't register that include/exclude took unit-names
[16:28] <m_3> think maybe the solution to _that_ problem is more coffee
[16:30] <negronjl> Here is the pastebin for the formula.log:  http://pastebin.ubuntu.com/644870/
[16:32] <negronjl> jimbaker, SpamapS, niemeyer, hazmat, m_3:  http://pastebin.ubuntu.com/644870/
[16:41] <niemeyer> negronjl: Can't see any issue there
[16:41] <niemeyer> negronjl: 2011-07-15 16:24:39,240: statemachine@DEBUG: unitworkflowstate: transition state (installed -> started)
[16:41] <niemeyer> negronjl: It actually says it went into started
[16:43] <negronjl> niemeyer:  hence the question and confusion.  here is what I get when I run ensemble status:  http://pastebin.ubuntu.com/644872/
[16:43] <m_3> looks like it started the transition from installed->started, but never completed the transition
[16:43] <m_3> your start hook is not returning?
[16:43] <m_3> what's it look like?
[16:44] <negronjl> m_3:  it returns just fine when I do it manually
[16:44] <niemeyer> negronjl: Hmm
[16:44] <m_3> niemeyer: is that a correct interp of the log?
[16:44] <niemeyer> negronjl: It actually looks like the log is partial
[16:44] <niemeyer> negronjl: 2011-07-15 16:24:39,241: hook.executor@DEBUG: Running hook: /var/lib/ensemble/units/cloudfoundry-server-0/formula/hooks/start
[16:45] <niemeyer> negronjl: There's no "Hook complete" there
[16:45] <niemeyer> negronjl: Can you paste your start hook please?
[16:45] <negronjl> niemeyer:  sure....give me a sec
[16:46] <negronjl> http://pastebin.ubuntu.com/644886/
[16:46] <negronjl> niemeyer:  ^^
[16:47] <niemeyer> negronjl: Can you please ps auxw on the server and see if "vcap start" is still running?
[16:47] <negronjl> niemeyer:  checking
[16:47] <m_3> background that puppy
[16:48] <m_3> or really, prob better off putting into a real upstart script to daemonize properly
[16:50] <negronjl> m_3:  thinking of just adding that all powerful & at the end of bin/vcap start :D
[16:51] <niemeyer> negronjl: Was it running?
[16:52] <negronjl> niemeyer:  still checking as I had shutdown so now, I'm re-deploying
[16:52] <niemeyer> negronjl: It at least looks like so from the output in the log
[16:52] <m_3> negronjl: quick enough to try just a background... sometimes it's not enough to kick your controlling term though
[16:52] <niemeyer> negronjl: It ends without any other feedback about the hook
[16:52] <niemeyer> negronjl: or transitions
[16:52] <niemeyer> negronjl: Just "echo" something after the command is run, just to be sure
[16:53] <negronjl> niemeyer:  just what i did.  added echo something at the end.  deploying now...waiting..
[17:05] <SpamapS> W00t!
[17:05] <SpamapS> http://www.oscon.com/oscon2011/public/schedule/detail/18367
[17:07] <m_3> looks like fun
[17:08] <negronjl> hey SpamapS, you're famous now :D
[17:08] <niemeyer> SpamapS: Wow, sweet
[17:10] <niemeyer> Heading to lunch, biab
[17:11] <robbiew> SpamapS:  *\o/*
[19:10] <niemeyer> robbiew: Man, that looks like a cheer leader
[19:11] <m_3> pom-poms ftw
[19:19] <negronjl> SpamapS: ping
[19:21] <robbiew> niemeyer: it was ;)
[19:22] <niemeyer> *\o/*
[19:22] <niemeyer>   |
[19:22] <niemeyer> ____
[19:22] <niemeyer> Arg.. Almost
[19:22] <niemeyer> *\o/*
[19:22] <niemeyer>     |
[19:22] <niemeyer> LOL
[19:23] <niemeyer> I can't type
[19:23] <niemeyer> *\o/*
[19:23] <niemeyer> __|__
[19:23] <niemeyer> Sorry.. back to work
[19:23] <_mup_> Bug #811226 was filed: Ensemble needs to enable backing storage <Ensemble:New> < https://launchpad.net/bugs/811226 >
[19:23] <kirkland> jcastro: would you mind confirming https://bugs.launchpad.net/ensemble/+bug/811226 ?
[19:23] <robbiew> *\o/*
[19:23] <robbiew>    /^\
[19:23] <_mup_> Bug #811226: Ensemble needs to enable backing storage <Ensemble:New> < https://launchpad.net/bugs/811226 >
[19:24] <kirkland> robbiew: um, you're a cheerleader who was severed at the waist?
[19:24] <robbiew> that was the skirt
[19:24] <robbiew> lol
[19:24] <kirkland> robbiew: :-)
[19:25] <SpamapS> negronjl: pong, sup?
[19:25] <negronjl> SpamapS: https://bugs.launchpad.net/principia/+bug/811228
[19:25] <_mup_> Bug #811228: mysql formula user names sometimes exceed 16 characters <Ensemble Formulas:New> < https://launchpad.net/bugs/811228 >
[19:25] <negronjl> SpamapS:  mysql usernames sometime exceed the max number of characters (16)
[19:25] <SpamapS> negronjl: ahh, adam_g was working on that
[19:26] <negronjl> SpamapS:  Is there a bug number?
[19:26] <SpamapS> negronjl: or rather, his recently submitted shared db functionality solves it .. and I think we can solve it for all cases.
[19:26] <SpamapS> negronjl: no it was just something he found while working on the openstack stuff.
[19:27] <SpamapS> negronjl: an easy fix is just to generate the username semi-randomly.
[19:27] <SpamapS> like, use the first 8 chars of the service name, and then 8 random chars.
[19:27] <negronjl> SpamapS:  ahh...a bug number on these ( and probably any issues ) would have prevented me from debugging and duplicating the work that adam may already be working on
[19:27] <negronjl> SpamapS:  I submitted a patch tht uses uuid and uses the last 12 digits
[19:28] <negronjl> SpamapS:  that way is more random than just chopping the service name or something silly like that.
[19:29] <SpamapS> negronjl: I'd err on the side of using pwgen rather than uuid .. the only reason being I don't know what the randomness guarantees of the first 12 chars of the uuid generator are... but I do know them for pwgen.
[19:29] <SpamapS> negronjl: But anyway, if you have a patch, you can push it yourself, as you're a composer.
[19:30] <negronjl> SpamapS:  I know, I was just being polite by bringing it to your attention and take the oportunity to complain about the lack of a bug from adam_g about the same issue that I was working on :)
[19:30] <negronjl> SpamapS:  I'll look into pwgen
[19:32] <SpamapS> negronjl: Ah.. ok.. just making sure you know.. I don't want people to think I'm special in this regard. :)
[19:32] <SpamapS> I think at this point you've written more formulas than anybody else.
[19:41] <jsalisbury> negronjl, I'm starting to play with ensemble.  Does the current version only run against EC2?  Or can I have my own OpenStack cloud, say on a VM, that I can use for testing/playing with ensemble?
[19:48] <kirkland> negronjl: SpamapS: what's the context of the pwgen comment?
[19:50] <niemeyer> jsalisbury: It runs against EC2 ATM, but if you set up OpenStack and use the EC2 API it "should" work
[19:50] <niemeyer> jsalisbury: We haven't put time on testing it yet, but any reasons for it not to work are bugs we want to fix in the short term
[19:50] <niemeyer> jsalisbury: So if you're interested in getting that in place, just poke us with issues you find and we'll give a hnad
[19:51] <jsalisbury> niemeyer, great, thanks.  Then I can possible get two birds with one stone ;-)
[19:51] <niemeyer> jsalisbury: Definitely :)(
[19:51] <niemeyer> :)
[19:51] <jsalisbury> niemeyer, thanks!
[19:51] <kirkland> jsalisbury: that would be muy awesome :-)
[19:52] <jsalisbury> kirkland, :-)
[19:55] <jsalisbury> niemeyer, Would running OpenStack on a VM or single box be a valid test?  It's not very 'Real world', but the interaction with ensemble should be the same, correct?
[19:56] <niemeyer> jsalisbury: Indeed
[19:56] <jsalisbury> niemeyer, great
[19:58] <adam_g> jsalisbury: this exists: https://bugs.launchpad.net/ensemble/+bug/805554  but i haven't tested myself, and figured it would "just work"  if you find the same, pleas confirm
[19:58] <_mup_> Bug #805554: Ensemble from ppa does not work with nova. <Ensemble:Incomplete> < https://launchpad.net/bugs/805554 >
[20:02] <jsalisbury> _mup_, boo.  I guess I can try to confirm that one.
[22:48] <niemeyer> Alright, I'm taking off for now.. see you all later
[22:53] <robbiew> SpamapS: http://paper.li/OnXcloud/1291324328#!art-entertainment
[22:54] <robbiew> heh...apparently my tweet of your OSCON talk got picked up by some paper.li publisher
[22:55] <robbiew> Onxcloud...created by OnX Enterprise Solutions...www.onx.com...never heard of them
[22:55] <robbiew> canadian...maybe zul has :P
[23:16] <hazmat> SpamapS, awesome re oscon
[23:17] <negronjl> SpamapS: you around?
[23:30] <SpamapS> negronjl: here now, sup?
[23:38] <negronjl> SpamapS:  nm.  I figured it out.
[23:38] <SpamapS> negronjl: silence is golden. ;)


[02:16] <pleia2> knome: ok, I'm away from home this week anyway, limited time
[08:40] <Unit193> flocculant: How did the x-d-s/systemd/dbus-user-session stuff go?
[10:23] <knome> pleia2, sure, np, just that you don't feel the rush to go moderate with your limited time ;)
[11:19] <flocculant> Unit193: well - I crashed out and had to grab systemd from -proposed to get it to work the other morning
[11:19] <flocculant> no desktop - no nothing
[11:19] <flocculant> but since then it's been fine
[11:19] <flocculant> I'd guess as long as you've got systemd 231 it should be ok
[11:20] <flocculant> obviously I had x-d-s from ppa as well
[11:44] <flocculant> fwiw latest x-d-s installed ok too
[17:06] <flocculant> so many vm's running I've confused myself - not sure which is a resize or manual test \o/
[17:12] <knome> lol
[17:17] <flocculant> bluesabre: so we've got smoketests done for 14.04.5 twice mostly, I'll wait see if we get any from other people before marking them
[21:01] <knome> bluesabre, ochosi, Unit193: https://twitter.com/BitSortierer/status/760431546948001792
[21:07] <ochosi> without having tested it, sounds reasonable if true
[21:09] <knome> i have no idea either, just forwarding
[21:12] <Unit193> http://paste.openstack.org/show/NVCj1m6bcqCfiqbb4Syu
[21:13]  * knome shrugs :)
[21:55] <Unit193> flocculant: Indicators are broken actually.
[23:53] <bluesabre> evening all
[23:54] <Unit193> Howdy.
[23:54] <bluesabre> knome: indeed, sounds reasonable