[00:36] <smoser> bigjools, roaksoax were you discussing the api creds for commissioning environment?
[00:36] <smoser> or how we should make ipmi calls home
[00:36] <smoser> ?
[00:37] <bigjools> smoser: we didn't, just talked about packaging
[00:37] <bigjools> AFAIK commissioning already posts back to the metadata service, so is there any reason we can't extend that api to handle power details?
[00:38] <smoser> it just seems like a patch to me
[00:38] <smoser> but, no. other than that no reason.
[00:39] <smoser> ie, a simple fix for "here, you can update *this* token of information"
[00:39] <smoser> which will later be extended with "and *this* token too"...
[00:39] <smoser> but i do agree that it is the simplist "right now" fix
[00:53] <bigjools> indeed
[01:11] <smoser> bigjools, is htat something you can have soon ish ?
[01:11] <smoser> ie, like so that roaksoax and i can bang on fleshing it out tomrrow?
[01:12] <bigjools> smoser: sure, I'll get it done in a few hours
[01:12] <smoser> thank you. you rock.
[01:12] <bigjools> smoser: any special requirements?
[01:12] <bigjools> other than "I want to set power parameters"
[01:12] <smoser> nah. we just need to be able to call home with that info from the commissioning envrionment.
[01:12] <smoser> i'll probably just extend the hackish client tha tis sent down in user-data right now.
[01:13] <bigjools> smoser: is it ok to do it in the existing "signal" call? or do you want a separate one?
[01:13] <smoser> well, signal is easier
[01:13] <smoser> but just seems more hackish :)
[01:13] <bigjools> yeah :)
[01:13] <bigjools> also, what's the plan for powering up enlisted nodes?
[01:14] <smoser> well, dont know.
[01:14] <smoser> Davieys' idea was reasonable.
[01:14] <smoser> in enlistment you'd (at least in an otion) sit and wait for "ready"
[01:14] <smoser> ie, poll on the server "am i ready for commission?"
[01:14] <smoser> ...
[01:14] <smoser> and then when you are, reboot
[01:14] <bigjools> it was, but it wasn't liked by a certain person
[01:15] <smoser> oh.
[01:15] <smoser> hm..
[01:15] <smoser> well, then.
[01:15] <bigjools> yeah
[01:15] <smoser> th eonloyy other hting is to call home in enlistment
[01:15] <smoser> only other thing
[01:15] <smoser> what other options do we have?
[01:15] <smoser> either a.) not power off
[01:15] <bigjools> can existing power params be discovered without changing anything in enlistment?
[01:15] <smoser> maybe
[01:15] <smoser> roaksoax, would know more
[01:15] <smoser> we can poke
[01:15] <smoser> i really have to run
[01:15] <bigjools> that's what I always assumed would happen
[01:15] <bigjools> ok, cya
[01:56] <roaksoax> bigjools: during enlistment we can't
[01:56] <bigjools> roaksoax: :(
[01:56] <roaksoax> bigjools: unless you give that unauth access :)
[01:57] <bigjools> roaksoax: why doesn't the enlistment env have the creds?
[01:57] <roaksoax> bigjools: the power settings are under a NodeAdminForm validation,
[01:57] <bigjools> it's the same env as commissioning AFAIK?
[01:57] <roaksoax> bigjools: I don't think it would make sense to send admin creds during enlistment
[01:57] <bigjools> true
[01:57] <bigjools> so two things:
[01:58] <bigjools> 1. you *can* detect existing power params in enlistment?
[01:58] <bigjools> 2. we can change the enlistment api to take power params
[01:58] <roaksoax> bigjools: i can do that and I always wanted that
[01:58] <bigjools> so, let's do it :)
[01:58] <roaksoax> that's my personal preference
[01:59] <roaksoax> bigjools: however, Daviey and smoser saw better usage of those in commissioning rather than enlistment
[01:59] <roaksoax> smoser: ^^
[01:59] <bigjools> that will complicated the existing setup
[01:59] <bigjools> complicate*
[01:59] <roaksoax> ah he is gone
[02:00] <bigjools> Daviey wanted to leave the node powered up and poll
[02:00] <roaksoax> bigjools: you'll have to talk to Daviey on that regards
[02:00] <bigjools> but that was disliked...
[02:00] <roaksoax> yeah well
[02:00] <roaksoax> bigjools: the idea behind doing it during commissioning is that commissioning is the step were all the configuration is being made
[02:00] <roaksoax> enlistment is all about discovery
[02:01] <roaksoax> so while auto-detecting IPMI is also discovery, we also might need to do setup
[02:01] <roaksoax> so that's why it was preferred to be in commissioning rather than enlistment
[02:01] <bigjools> sure
[02:02] <bigjools> so does this mean that we can't reliably auto detect power params in enlistment?
[02:02] <roaksoax> needless to say, my personal preference has always been in enlistment due to the fact that once we click on "Accept&Commission" the nodewill be turned on automatically
[02:02] <roaksoax> bigjools: *personally* I'd love it to have it done during enlistment
[02:03] <bigjools> well if it can be done, I don't see why we don;t just do it
[02:03] <roaksoax> bigjools: that's why I explained the reasons above
[02:03] <roaksoax> bigjools: you should really discuss this with Daviey :)
[02:03] <bigjools> it will be the minority use case because most people will use some sort of discovery module to poke in new nodes on the api
[02:03] <bigjools> roaksoax: I will!
[02:03] <bigjools> I did already in fact but I'll revisit
[02:04] <bigjools> so roaksoax, do you have more time to talk packaging?
[02:04] <roaksoax> bigjools: so if we are going to have unauth access for enlistment, we might aswell have an aunauth mehotd for power settings on an update
[02:04] <roaksoax> so we can do it in commissioning
[02:04] <roaksoax> (at least that's what could be argued)
[02:04] <roaksoax> bigjools: and yes... I'm taking a break from homework :)
[02:05] <bigjools> heh, ok
[02:05]  * bigjools back in 2 mins
[02:05] <roaksoax> k
[02:08] <bigjools> back
[02:09] <roaksoax> bigjools: ok, shoot :)
[02:10] <bigjools> roaksoax: so the upgrade scenario
[02:10] <bigjools> I moved the massive postinst from maas to maas-region-controller
[02:11] <bigjools> that will probably break it
[02:11] <roaksoax> bigjools: ok, that needs to be cleaned up, and i think some stuff should be passed to maas-cluster-controller
[02:11] <roaksoax> yeah
[02:11] <bigjools> well I imagine post if it heads back to maas?
[02:12] <bigjools> most of*
[02:13] <roaksoax> well there's upgrade stuff that i think it is not longer needed
[02:13] <bigjools> ok
[02:13] <roaksoax> i need to evaluate that though
[02:13] <roaksoax> bigjools: btw: I think this is missing, though I don;t like having to symlink that config in maas-common http://paste.ubuntu.com/1227767/
[02:13] <bigjools> all the stuff comparing versions will fail
[02:14] <roaksoax> bigjools: not really
[02:14] <bigjools> well maas-region-controller won't have ancestry
[02:14] <bigjools> how can it compare?
[02:15] <roaksoax> bigjools: it won't be run
[02:15] <roaksoax> bigjools: becuase it is a first install of that binary package
[02:15] <roaksoax> so it enters as a new install
[02:15] <roaksoax> not an upgrade
[02:15] <bigjools> exactly my point :)(
[02:16] <roaksoax> bigjools: so when we install, it will run this: if [ "$1" = "configure" ] && [ -z "$2" ]; then
[02:16] <roaksoax> right?
[02:16] <roaksoax> so it will do initial configuration of everything
[02:16] <bigjools> yep
[02:16] <roaksoax> bigjools: when we upgra maas-region-controller, it will run this: elif [ "$1" = "configure" ] && dpkg --compare-versions "$2" gt 0.1+bzr266+dfsg-0ubuntu1; then
[02:17] <roaksoax> bigjools: which is where the comparing version stands
[02:17] <roaksoax> so big part of that I think might no longer be needed
[02:17] <roaksoax> i just need to make sure it's not before I drop it completely
[02:17] <roaksoax> i had in mind dropping most of it anyway
[02:20] <bigjools> will this break:
[02:20] <bigjools> elif [ "$1" = "configure" ] && dpkg --compare-versions "$2" gt 0.1+bzr266+dfsg-0ubuntu1; then
[02:21] <bigjools> ah should be ok
[02:21] <bigjools> however
[02:22] <roaksoax> it will be ok
[02:22] <bigjools> I still think upgrading from 12.04 will break since it'll think it's installing from scratch
[02:22] <bigjools> (pushed up your last diff)
[02:22] <roaksoax> bigjools: no wont break, it will simply install everything as if it was new
[02:23] <bigjools> so why are there postinst sections comparing versions then?
[02:23] <bigjools> ie a special upgrade case
[02:24] <bigjools> or are you saying that install from scratch will work even if there's an existing DB etc?
[02:24] <roaksoax> bigjools: cause for example, we were upgrading from package XYZ to ABC, and ABC needed W to be configured, but since XYC didn't have it, we need to configure it in upgrade
[02:24] <roaksoax> but we don't need it if we are upgrading from ABC
[02:25] <roaksoax> bigjools: yeah it won't install a new DB, i think it will just change the password
[02:25] <bigjools> that's not useful :(
[02:25] <roaksoax> bigjools: it will change the psasword and update the config files
[02:25] <roaksoax> bigjools: so it should be good
[02:26] <roaksoax> bigjools: i'll have to test it TBH
[02:26] <roaksoax> bigjools: if you wnat, do this. Push a package to a PPA< fire up a cnaonistack instance. install maas and upgrade from that PPA
[02:26] <roaksoax> and see what happens :)
[02:26] <bigjools> roaksoax: ok :)
[02:27] <bigjools> I'll build something in the testing PPA
[02:27] <bigjools> could do with a cow image with maas installed on 12.04, would speed things up
[02:27] <roaksoax> bigjools: not maas-maintainers/testing please :)
[02:27] <bigjools> roaksoax: bah spoilsport :)
[02:28] <bigjools> maas-maintainers/experimental then
[02:28] <roaksoax> bigjools: i have sabdlf's lab using MAAS from maas-maintainers/testing
[02:28] <bigjools> !
[02:28] <bigjools>  /o\
[02:28] <bigjools> roaksoax: I'd be tempted to make a ppa called sabdfl-garage!
[02:28] <roaksoax> he wnaqted to test the quantal stuff I think
[02:29] <roaksoax> lol
[02:29] <bigjools> deadly serious
[02:30] <roaksoax> hehe but that's simplyt latest trunk
[02:30] <roaksoax> pre-package split
[02:38] <roaksoax> alright i'm off for the night
[02:38] <roaksoax> nigth
[02:39] <bigjools> roaksoax: ok thanks for the help
[02:39] <bigjools> I'll test and let you know results
[02:39] <bigjools> roaksoax: oh if you are still there ...
[02:40] <bigjools> is there an easy hack to make get-orig-source automatically use my local trunk instead of lp:maas ?
[02:41] <roaksoax> bigjools: uhmmm you could simply package your local branch
[02:41] <bigjools> I just hacked rules for now but it'd be nice if you could set an override
[02:42] <roaksoax> bigjools: I don't know TBH how to override it easily
[02:42] <bigjools> no worries
[02:42] <bigjools> go to bed :)
[02:42] <roaksoax> bigjools: i wish I could go to bed
[02:42]  * roaksoax doing homework
[02:43] <bigjools> ah those days ...
[02:43] <roaksoax> yeah!! can't wait them to be over :)
[07:25] <jam> _rvba, allenap: (when you wake up) I'd like to add a test that if you update a tag with invalid data, the transaction is properly aborted, and the data stays consistent.
[07:26] <jam> I was able to manually do transactions in a test by inheriting TransactionTestCase
[07:26] <jam> however, for an API test, the transactions are done by the middleware
[07:26] <jam> (which seems to handle everything is committed or nothing on a single API request.)
[07:26] <jam> is it reasonable to just skip that test and assume the transaction works properly?
[07:26] <jam> maybe jtv ^^
[07:27] <jtv> hi jam
[07:27] <jtv> By "invalid data" here you mean malformed data?
[07:28] <jam> jtv: the Tag definition field needs to be a proper XPATH string.
[07:28] <jam> we currently validate that at the point where we go around updating the nodes that match the tag
[07:28] <jtv> By the way, the regular test case turns commit() into a no-op and probably abort() as well.  I guess there are probably other ways to establish that changes have been aborted.
[07:28] <jam> and I want to make sure that we don't mutate any nodes => tag associations.
[07:29] <jtv> You're keeping the tags as a field on the node?
[07:29] <jam> jtv: in test_api.py if I do a POST with invalid data, I either: get an uncaught DatabaseError, or I catch that in my TagHandler, and raise ValidationError. If I raise VE, then I can't 'reload_object()' because the DB is in 'I want you to rollback' state.
[07:29] <jam> jtv: we have a node_tags table
[07:29] <jam> (many to many)
[07:30] <jtv> Ah good
[07:30] <jtv> jam: by "invalid data" here, you mean malformed data?
[07:30] <jam> jtv: right, the user tries to update a tag to a definition that is improperly formed.
[07:30] <jam> syntactically invalid, I guess.
[07:30] <jtv> Yeah, malformed.
[07:30] <jam> '/node/foo' is valid XPATH, 'node@id=bar' is not.
[07:31] <jam> node[@id=bar] is the proper syntax, etc.
[07:31] <jtv> I'm asking just because I'm not too familiar with the details, so there might conceivably be other notions of validity.
[07:31] <jam> So I *could* do LBYL and do a check that the syntax is valid before I do any further work.
[07:31] <jam> But it feels YAGNI, vs just doing the work and assuming if there is a problem it will get rolled back.
[07:31] <jtv> LBYL?
[07:31] <jtv> Ah
[07:31] <jtv> nm
[07:31] <jam> Look Before You Leap
[07:32] <jtv> Agreed -- the database does exactly what you want here, might as well build on that.
[07:32] <jam> (Right now to update the node <=> tag association on new definition, I delete all the old values, and then repopulate with new values)
[07:32] <jam> jtv: so the question is, the testing infrastructure doesn't have TransactionMiddleware running (that I can tell)
[07:32] <jam> which is where the real API is getting transaction + rollback.
[07:33] <jam> (AFAICT)
[07:33] <jtv> Nasty idea for a test: store some malformed data, attempt trivial database access, verify that it fails.
[07:33] <jam> jtv: self.assertRaises(DatabaseError, reload_object, tag) ?
[07:33] <jtv> For example!  Just as long as there is no doubt whatsoever that the test won't have affected the object.
[07:34] <jtv> You could also assert that Node.objects.all().count() fails.
[07:34] <jam> jtv: well, I have *another* test which goes directly to the Tag attributes, and does the transaction logic itself.
[07:34] <jam> the real key is if somone removes TransactionMiddleware, I don't have a failing test.
[07:34] <jam> and potentially get inconsistent data in the DB on posting invalid definitions.
[07:35] <jtv> And the test does remove the middleware, because it stubs out commit/abort and runs its own transaction.  Gotcha.
[07:35] <jtv> Hmm.
[07:36] <jam> I don't know if we have any tests at a higher level (Selenium-ish) that runs the real server and we can poke at.
[07:36] <jam> Like maybe something for diogo?
[07:36] <jtv> Actually, isn't it enough to test that malformed data raises a database error?
[07:37] <jtv> Of course if somebody makes database changes prior to the insertion _and_ someone takes away the transaction management, YASEF.
[07:38] <jam> jtv: well, we already mutate the db before we find the error
[07:38] <jtv> :(
[07:38] <jam> tag.node_set.clear()
[07:38] <jam> for node in raw("""xpath_query""): tag.node_set.add(node)
[07:39] <jam> jtv: hence the 'I could LBYL' and issue a semi-bogus query
[07:39] <jam> like 'raw("""xpath_query(%s, <dummy />)""")'
[07:39] <jtv> Or document in big letters that nobody should take away transaction management.  It seems a silly thing to do at any rate.
[07:40] <jam> jtv: I agree it would be silly to switch to autocommit.
[07:41] <jtv> So testing for this does feel a bit like checking your car for seatbelts: it's sort of a static shared assumption.
[07:46] <jam> jtv: well, it is a bit of "I'm definitely assuming X, can I test that X is still present"?
[07:46] <jam> jtv: and as for seatbelts, there are lots of places I've been that don't have them (taxis tend to tuck them under the seat in many countries I've visited)
[07:46] <jtv> The way django is designed, I see neither a good way of setting it in stone nor a good way of testing it.
[07:47] <jtv> I deliberately spoke of "your" car, not a taxi -- some drivers here cut them off.  :)
[07:47] <jtv> (And yes, I'm making some guesses there)
[07:47] <jam> :)
[07:48] <jam> jtv: I imagine pull it down so the bell doesn't ring, and then cut it off?
[07:48] <jtv> Don't know.  It's not something you ask about, or try for yourself.
[07:48] <jtv> They may point out that you don't need them, since they have all the proper talismans and statuettes.
[07:49] <jtv> Leading cause of blindness resulting from vehicle accidents, apparently.
[07:49] <jtv> If you do get one of those in your eye, people will probably tell you how lucky you are -- without the Ganesh statue you'd probably have been killed in the accident.
[07:50] <jam> Interestingly, this last year in the US, suicide overcame car accidents as the leading cause of accidental death (not counting health issues, etc)
[07:51] <jtv> Suicide is counted as accidental death?  I had no idea the country's problems ran _that_ deep.
[07:52] <jtv> I mean, no wonder the financial system collapses with that kind of accounting.
[07:52] <jam> jtv: 'injury related death'
[07:52] <jam> http://vitals.nbcnews.com/_news/2012/09/25/14101794-suicide-now-kills-more-americans-than-car-crashes?lite
[07:52] <jtv> Jokes aside, it's shocking.
[07:52] <jam> not 'accidental'
[07:54] <jam> sure, though car accidents killed something like 40,000 people, but heart disease kills about 600,000
[07:54] <jtv> I guess nobody there worries much about terrorism any more then, if more Americans get killed by themselves than by terrorism?
[07:54] <jam> jtv: I've read a lot of Schneier, and worrying about terrorism is stupid (but publicly funded) in the US.
[07:55] <jam> I think more people die to pigs than to terrorism.
[07:55] <jtv> Is that the little table at the beginning of the book?
[07:55] <jam> jtv: something like that I think. I know more people die to pigs than to sharks, which was in that table.
[07:56] <jam> The bit I read was that the US has an official policy that if a death rate is more than 1:1Million, then it is worth doing something about it. And even in 2001 it didn't reach 1:1M death rates due to terrorism.
[07:57] <jam> but we sure spent a lot of money on it.
[08:05] <jam> morning mgz
[08:08] <jam> mgz: I'm guessing you missed the cat with myself and j-t-v about testing the transaction logic. Want to do a quick standup on Mumble before we join red squad?
[08:15] <melmoth> stoopid question of the day: when i pxe boot a node, what is the difference between the "enlist" and the "local" choice ?
[08:26] <dannf> enlist will register it into maas' database - local will tell it to boot from the local disk
[08:26] <dannf> melmoth: ^
[08:27] <melmoth> ok. thanks.
[08:27] <melmoth> i felt it was this, but was surprise to see my node enlisted when choosing local (but this is because there was nothing on the drive, so it pxe boot anyway)
[08:34] <mgz> jam: sorry, missed the poke, will read log later
[08:35] <jam> np
[08:35] <jam> we can chat after the standup, too
[08:43] <jam> mgz: I'm back on mumble when you get back to your machine :)
[08:45] <mgz> migration complete :)
[08:45] <mgz> 's one way of getting exercise in the morning...
[08:49] <melmoth> grumble.. hitting one problem i had lots of time.. once a node has booted, its name is note resolbable
[08:50] <melmoth> and the entry in /var/lib/misc/dnsmasq.leases for its mac mention "ubuntu" instead of its name
[08:50] <melmoth> any idea what to do when one is experiencing this ?
[08:52] <melmoth> ohh, this time, restarting dnsmasq and rebooting the node seems to have "fixed it".
[11:54] <jam> mgz: so what did you think about the tests I put up? (I imagine you are currently away at lunch?)
[11:57] <mgz> nearly but not quite
[12:11] <jam> mgz: https://code.launchpad.net/~jameinel/maas/tags-exposing-nodes/+merge/126438
[12:18] <rbasak> Daviey, roaksoax: ping. I've just realised that maas-enlist is going to need to send MAAS the subarchitecture for ARM support, eg. armhf/highbank instead of armhf. This will need an SRU to 12.04. Currently it uses architecture=armhf, but changing this would break old MAAS installs. So I think I need to add architecture=armhf&subarchitecture=generic, which should work. MAAS doesn't seem to complain about extra fields. Thoughts?
[12:18] <rbasak> er, architecture=armhf&subarchitecture=highbank, or architecture=amd64&subarchitecture=generic
[12:18] <rbasak> For backwards compatibility new MAAS can just assume subarchitecture=generic if it is not specified
[12:19] <Daviey> rbasak: I actually thought we were sending the subarch!
[12:19] <Daviey> rbasak: so i agree with that direction, and thought it was done
[12:19] <rbasak> Oddly, no. archdetect returns the exact string we need ("$arch/$subarch")
[12:19] <rbasak> It's a shame maas-enlist filters out the second component!
[12:20] <Daviey> yeah
[12:20] <rbasak> It currently does arch=`archdetect | cut -d'/' -f1`
[12:20] <rbasak> And I can't cut that out, since then older MAAS installs will use a more recent SRU'd maas-enlist and then break
[12:20] <rbasak> I'll just have to add a whole other field
[12:21] <rbasak> Daviey: will the SRU be OK?
[12:22] <Daviey> rbasak: ideally... we do this IMO.. If it doesn't post the subarch, server-side assumes generic
[12:22] <Daviey> and SRU in conjunction.
[12:22] <rbasak> Daviey: and to confirm, you mean subarch in a separate field?
[12:23] <Daviey> rbasak: I don't know.
[12:23] <rbasak> ok
[12:26]  * rbasak has filed https://bugs.launchpad.net/ubuntu/+source/maas-enlist/+bug/1056816
[12:57] <smoser> rbasak, dailies should show up in the next hour or so
[12:57] <rbasak> smoser: awesome. Thank you!
[12:57] <smoser> both quantal and precise.
[12:59] <smoser> qemu-arm-static is freaking slow.
[12:59] <smoser> amazing.
[13:00] <smoser> but slow
[13:21] <smoser> https://maas.ubuntu.com/images/ephemeral/daily/precise/20120924/
[13:28] <rbasak> rvba: having some piston trouble with the subarch stuff. I'm trying to add a subarchitecture= field to the api that maas-enlist calls. Except that it doesn't seem to work because it's tied a model so ignores any extra fields. http://paste.ubuntu.com/1228451/
[13:28] <rbasak> (or at least I think it's why)
[13:29] <rbasak> any ideas?
[13:32] <mgz> rbasak: is your subarch branch up anywhere yet? just want to see what you've changed for the constraint
[13:34] <rbasak> mgz: I haven't touched the constraint yet
[13:35] <rbasak> still figuring out how the whole thing will work
[13:35] <rbasak> I think I've got most of the pieces except this problem with maas-enlist
[13:35] <mgz> rbasak: I can do that then if you tell me what the architecture field will contain
[13:35] <rbasak> mgz: it'll be armhf/highbank, armhf/armadaxp, i386/generic or amd64/generic
[13:36] <rbasak> and these strings shoudl be available as ARCHITECTURE.i386, ARCHITECTURE.amd64, ARCHITECTURE.armhf_highbank, etc
[13:36] <rbasak> (from maasserver.enum)
[13:36] <mgz> rbasak: thanks, I'll put sometime like that up for consideration
[13:36] <rbasak> but maas-enlist is usingi an API that is heavily tied to the node model
[13:37] <rbasak> And since I'm not adding a subarchitecture field to node, this is being a massive pain for me
[13:37] <rbasak> piston doesn't seem to support additional fields that aren't in the model, unless I'm missing something
[13:37] <rbasak> (I hope I am)
[13:53] <_rvba> rbasak: Looks like you're manually changing query_data['architecture'] so it should be ok… what's the error exactly?
[13:54] <rbasak> Piston/0.2.3rc1 (Django 1.4.1) crash report: Method signature does not match. Resource does not expect any parameters.
[13:54] <rbasak> (across multiple lines)
[13:54] <rbasak> create_node never gets called
[13:54] <rbasak> But only if I have a subarchitecture key in the POST data
[13:54] <rbasak> WIthout it, everything works normally
[13:54] <rbasak> THe only place that seems to define allowed fields is the fields tuple, and I've added subarchitecture to that
[13:54] <_rvba> Looks like the request does not get properly routed if subarchitecture is there.  Which is weird.
[13:54] <rbasak> So the only other thing I can think of is that it's tied to the Node model, and that doesn't define subarchitecture
[13:55] <_rvba> create_node should be called even if the form has a problem with what's in request.data.
[13:55] <rbasak> I don't think it's the form with the problem
[13:55] <rbasak> I think it's piston
[13:56] <_rvba> Piston does not do much.  I don't see how it can get in the way.  I think it's simply hiding the error.
[13:57] <rbasak> I raised a ValidationError in create_node to check
[13:57] <rbasak> It gets raised and I get its output over HTTP if I don't use subarchitecture
[13:57] <rbasak> WHen I use subarchitecture I get this other error instead
[13:57] <rbasak> So I'm certain that create_node never gets called if subarchitecture is set
[13:57] <rbasak> THe problem has to be in the new method or in piston
[13:58] <_rvba> Can you paste the result of 'bzr diff'?  I'll have a look.
[13:58] <rbasak> I'm working on top of my highbank patchset
[14:02] <rbasak> _rvba: https://pastebin.canonical.com/75335/ should bring you up to where I am, but it does include other patches
[14:02] <rbasak> _rvba: they shouldn't affect this issue though
[14:07] <_rvba> rbasak: sorry to be thick but how can I apply that kind of patch to my tree?
[14:07] <rbasak> rvba: sorry. Use patch -p1
[14:07]  * rbasak finds it a bit bizarre that bzr uses -p0
[14:08] <_rvba> Thanks.
[14:08] <_rvba> rbasak: what's the failing test?
[14:08] <rbasak> _rvba: I don't have one / haven't tried tests
[14:09] <rbasak> _rvba: the problem occurs when I actually fire MAAS up and try and enlist with a patched maas-enlist
[14:10] <rbasak> _rvba: I'll see if I can add an appropriate test. Looks like it shouldn't be too ahrd
[14:11] <_rvba> rbasak: ok, let's see if I can recreate your problem by modifying an existing test.
[14:13] <smoser> jtv, around ?
[14:13] <jtv> hi smoser
[14:13] <smoser> maas daily ppa yesterday successfully wrote a dhcpd.cofn file.
[14:13] <smoser> but that seems broken now.
[14:14] <jtv> Yeah, Julian and I went over some problems earlier
[14:15] <smoser> so it was knowingly broken?
[14:15] <smoser> it worked yesterday
[14:15] <jtv> Not knowingly, but we saw breakage and fixed it.
[14:15] <jtv> Although...
[14:15] <_rvba> rbasak: '/'.join('b','a') is not correct.  '/'.join(['b','a'])
[14:15] <jtv> Ah yes, smoser: I remember now -- the dhcpd.conf wasn't being written for a very different reason than the other problems.
[14:16] <smoser> but it was being written yesterday.
[14:16] <smoser> i'm almost certain.
[14:16] <jtv> The task to do so never arrived at the cluster controller, because of changes in routing.
[14:16] <jtv> Those routing changes are very recent.
[14:16] <jtv> And difficult to get entirely right without some trial and error.
[14:16] <_rvba> rbasak: that's in http://paste.ubuntu.com/1228526/.  Also, if '/' in given_subarch blows up if given_subarch is None.
[14:17] <rbasak> _rvba: ok, I'll fix that and retest
[14:17] <rbasak> _rvba: but I don't think it's getting that far anyway. Let me see...
[14:18] <rbasak> _rvba: urgh. Looks like it is
[14:18] <rbasak> _rvba: sorry
[14:26] <mgz> my new api test case if failing with a 400 response and this text:
[14:26] <mgz> Piston/0.2.3rc1 (Django 1.4.1) crash report:
[14:26] <mgz> Method signature does not match.
[14:26] <mgz> Resource does not expect any parameters.
[14:26] <mgz> what is it really trying to tell me?
[14:26] <mgz> allenap: ^ any ideas?
[14:28] <allenap> mgz: diff?
[14:29] <allenap> mgz: I'll be back in ~10 minutes.
[14:30] <mgz> allenap: <http://pastebin.ubuntu.com/1228548/>
[14:30] <mgz> the other tests are fine, just writing this at the api level weirded up
[14:37] <mgz> gah, nose I hate you.
[14:49] <allenap> mgz: How very odd.
[14:50] <mgz> so, it's an error from inside acquire.. just not a useful one
[14:50] <mgz> is there some way to make tests show the traceback in that case?
[14:50] <allenap> Gah! 2FA just to download the plain text.   I image it's frustrating for you but here is the explanation: we are working towards having the tasks routed correctly when multiple cluster controllers are connected but this will obviously require some changes to the packaging.  And splitting up the existing package into 2 (one for the region controller and one for the
[15:43] <_rvba> cluster controller) is still WIP.  Hence the routing problem.
[15:44] <smoser> when you break something like that you cost lots of people time.
[15:44] <_rvba> smoser: not sure if you're interested in that kind of solution but this: http://paste.ubuntu.com/1228681/ should fix the problem.
[15:45] <_rvba> And I could say that not having the proper package structure is costing us a lot of time too.
[15:45] <smoser> really?
[15:45] <smoser> so you're complaining that you broke somethign that worked (in the packaging)
[15:46] <smoser> and it no longer works
[15:46] <smoser> ok
[15:46] <_rvba> I'm not complaining.  I'm trying to explain to you why that mistake was made.
[15:49] <_rvba>  smoser: I did not touch the packaging precisely because the whole structure is being changed (from one package to two packages).  That's exactly why there is friction.
[15:53] <smoser> _rvba, sorry for ranting. its just frustrating when i'm trying to test something and the daily ppa regresses.
[15:54] <_rvba> smoser: I understand… and I think I'm used to you being grumpy now.  Well, sort of :).
[15:57] <smoser> well, i wanted to find a link for grumpy old man
[15:57] <smoser> but the best i could find was http://www.hulu.com/watch/271896
[15:57] <smoser> and you probably can't see that.
[15:57] <_rvba> Indeed, I can't.
[15:58] <_rvba> roaksoax: may I ask how it the packaging work going?  I'm asking because I'm making changes upstream that will require some packaging changes but I can't do that while you're refactoring the whole structure (at least I think I can't).
[15:58] <_rvba> s/how it/how is/
[15:59] <roaksoax> _rvba: we are working on it with bigjools
[15:59] <roaksoax> what type of changes are you making?
[16:00] <_rvba> Tasks are now routed to the queue named after nodegroup.uuid.  So the invocation of celeryd needs to be done with "-Q name-of-the-queue".
[16:01] <_rvba> But this means that the script Jeroen has done needs to be started in an upstart job, that a proper UUID needs to be generated, etc.
[16:02] <_rvba> smoser: http://craigmcn.ca/wp-content/uploads/2012/09/old-man.jpg maybe?
[16:03] <smoser> https://www.google.com/search?q=dana+carvey+grumpy+old+man&hl=en&safe=off&tbm=isch&prmd=imvnso&source=lnms&sa=X&ei=LCdjUIffM_K70QGRooDADw&ved=0CAcQ_AUoAQ&biw=1259&bih=799
[16:05] <_rvba> roaksoax: do you have an ETA for a first version?  I'm trying to figure out if I need to do something to cope with the current package (something I would have to undo when the new structure will be in place) or not.
[16:06] <roaksoax> _rvba: hoping that this friday we have sometihng
[16:06] <_rvba> roaksoax: all right, thanks.
[16:07] <roaksoax> allenap: ping
[16:07] <roaksoax> allenap: https://pastebin.canonical.com/75364/
[16:09] <roaksoax> allenap: let me know when you see it, it's kinda critical to resolve :)
[16:14] <roaksoax> _rvba: how does the templating work for if statements?
[16:15] <roaksoax> _rvba: such as {{ if node.distro_series >= {'quantal' }}
[16:16] <roaksoax> can i use variables?
[16:16] <_rvba> Yes you can :).  I'll see if I can find an example but the doc is here: http://pythonpaste.org/tempita/.
[16:18] <roaksoax> thanks )
[16:18] <roaksoax> :)
[16:19] <_rvba> roaksoax: here is a completely stupid example I just wrote: http://paste.ubuntu.com/1228724/
[16:20] <_rvba> roaksoax: that template language is very permissive, any python syntax variable.field, dict['element'] should work all right.
[16:20] <roaksoax> _rvba: cool thanks
[16:22] <roaksoax> _rvba: http://paste.ubuntu.com/1228732/
[16:24] <_rvba> roaksoax: I think you want to use {{server_url}} instead of http://{{server_host}}.
[16:24] <_rvba> The server_url should contain http or https.
[16:25] <_rvba> We don't want to hardcode 'http' anywhere.
[16:25] <roaksoax> _rvba: ok cool, though if the error above gets fixed we will use tftp instead
[16:26] <_rvba> right
[16:27] <_rvba> roaksoax: that's not valid : {{if node.distro_series in {'quantal'} }}
[16:28] <_rvba> roaksoax: hold on, I'll find the correct syntax.
[16:28] <roaksoax> _rvba: it is, just tested it
[16:29] <_rvba> roaksoax: ah indeed, you're right, my mistake.
[16:53] <mgz> so, these get_blah_or_404 methods seem like a bad idea to me
[16:54] <mgz> at least using the django helper does, because the user just gets, as the response body "Not Found"... with no indicaton of *what* wasn't found or why
[16:56] <mgz> shouldn't there be at least an ObjectNotFound exception class with code httplib.NOT_FOUND but takes (type, field=None, value=None) so we can give errors like "Tag with name 'foo' is not found" instead?
[17:09] <smoser> rbasak, the images tested ok for me on intel and daily ppa
[17:10] <smoser> wait. for quantal they did.
[17:10] <smoser> i just uploaded the precise fix.
[17:25] <rbasak> smoser: \o/
[17:25] <rbasak> smoser: thank you!
[17:25] <smoser> i'll rebuild precise
[17:25] <smoser> but you should test also
[17:25] <smoser> roaksoax, do you know how i could convince maas to boot quantal ephemeral images?
[17:26] <roaksoax> smoser: yes
[17:26] <roaksoax> smoser: src/maasserver/models/config.py set it there
[17:27] <roaksoax> smoser: i need to add an option to modify that in "Settings" view
[17:29] <rbasak> smoser: I'll test tomorrow morning
[17:30] <rbasak> smoser: so where do I need to test from? maas.ubuntu.com daily?
[17:30] <rbasak> smoser: and for precise? or would you like the result of a quantal test first?
[17:31] <smoser> precise will fail
[17:31] <smoser> well, actually might pass. i'm not sure how it worked.
[17:31] <smoser> but resolvconf didn't get written
[17:32] <smoser> i'll start a new precise build right now
[17:32] <roaksoax> smoser: ok so for ipmi, we want to create a new user and a random pass right?
[17:34] <smoser> hm..
[17:34] <smoser> well i would suggest that is oen path.
[17:34] <smoser> and that collecting is another
[17:35] <roaksoax> huh?
[17:36] <smoser> roaksoax, so in the "let maas do it all" case, you would then assume access to the ipmi and you'd want to set up a user, pass, and then tell maas about that.
[17:36] <smoser> but there is also the case where you would just want that collected and reported to maas.
[17:36] <smoser> but not changed.
[17:36] <smoser> (i think)
[17:38] <roaksoax> smoser: right, so I had that in mind at first, though Daviey mentioned that we should simply assume that every time we commission, we should configure it as if it was unconfiguraed
[17:39] <smoser> i guess that is not unreasonable.
[17:40] <roaksoax> smoser: what could be done is simple "If maas use already exists, then collect info"
[17:41] <smoser> warning: grave ignorance about to be exposed
[17:41] <smoser> so.. if we boot, collect/set ipmi password and user and IP and such
[17:42] <smoser> then we give the system to a potentially malicous user
[17:42] <smoser> why would that not be granting them access to the same credentials
[17:42] <smoser> and thus the ability to not be nice
[17:43] <roaksoax> right but we are with the assumption that the credentials are set by the administrator and is a random password that should be hidden on the WebUI
[17:44] <smoser> roaksoax, i'm confused.
[17:44] <smoser> i'm saying the occupant of the system
[17:44] <smoser> can then just read them from the system
[17:44] <smoser> or create new ones
[17:45] <roaksoax> smoser: right, but that's the same case when an admin manually creates ipmi credentials
[17:45] <smoser> well, yes.
[17:46] <smoser> except for i would suspect that after doing so the admin would then disallow access
[17:46] <roaksoax> or when no other than the defalt ones have been created
[17:46] <smoser> but if we disallow access, then your "redeploy" scenario requires some sort of manual intervention.
[17:47] <roaksoax> smoser: right, so this is tricky to resolve
[17:47] <smoser> would this work ?
[17:48] <smoser> for our deployment/re-deployment systems.
[17:48] <smoser> we create one se of credeitians with 'ubuntu:ubuntu' that is admin
[17:48] <smoser> with those credentials, you can open up access from the system itself
[17:48] <smoser> then enlist/commission with maas (which will disallow access from the system)
[17:49] <smoser> then you can reset to "ready" with the 'ubuntu:ubuntu' creds
[17:49] <smoser> (from the network interface, rather than from the system itself)
[17:49] <roaksoax> smoser: right, but that means that we would have to pre-configure ipmi
[17:50] <smoser> right. but in our test labs we would have to do that.
[17:50] <roaksoax> and i thought, or so I was told, that the idea here is to simply plug in a server, detect ipmi, configure it and that's it
[17:50] <smoser> hm..
[17:51] <roaksoax> so we cannot rely on having someone pre-configuring IPMI
[17:51] <roaksoax> smoser: but either way, IPMI cards have a default user/password
[17:51] <roaksoax> which is supposed to be enabled
[17:51] <roaksoax> by default always
[17:51] <roaksoax> so the idea is to create a user/pass for maas:XYZ
[17:52] <roaksoax> and tell that to MAAS so it can start/stop machines
[17:54] <roaksoax> smoser: btw.. I can't see an option to disable BMC access of a machine itself
[17:54] <roaksoax> there's only lan channel
[17:56] <smoser> doesn't that seem broken?
[17:56] <roaksoax> smoser: well, that's IPMI settings themselves
[17:56] <roaksoax> there's no option ot disable local BMC access
[17:57] <smoser> doesn't that seem broken?
[17:57] <smoser> and our entire system based on the fact that we could do that?
[17:57] <roaksoax> yeah
[17:58] <roaksoax> well, we can maybe restrict access to such tools on sudoers to the ubuntu user?
[17:59] <roaksoax> smoser: but to me... the root user is the one who has access to every piece of hardware
[17:59] <roaksoax> smoser: and it is the same case with the BMC
[18:00] <roaksoax> smoser: so in reality, if we argue that it is broken, we can argue the same thing with every piece of hardware attached to the system
[18:00] <roaksoax> restricting local bmc access would be as restricting access to a HD for a root admin
[18:00] <roaksoax> s/admin/user
[18:01] <smoser> well, thats not really true.
[18:02] <smoser> generally you can disbale access to the bios from the OS
[18:02] <smoser> which would stop the OS from changing boot-order or such things
[18:02] <smoser> which is essentially what we want to do here.
[18:02] <smoser> if my OS is compromised, i'd still like to be able to use my hardware.
[18:04] <roaksoax> smoser: right, but an ipmi card is a piece of hardware
[18:04] <roaksoax> not a BIOS
[18:04] <roaksoax> smoser: so if your OS is compromised, i'd still like to be able to use IPMI
[18:05] <roaksoax> or access the BMC
[18:33] <roaksoax> smoser: lp:~andreserl/+junk/autodetect-ipmi
[18:34] <roaksoax> smoser: ok so instead of doing most of the --commit stuff by commands, a template can be used and written as a file, so we just do 1 commit
[18:38] <smoser> rbasak, precise image daily image should be good now.
[18:38] <rbasak> smoser: thank you!
[18:41] <smoser> roaksoax, bug 1: /bin/python
[18:57] <smoser> roaksoax,
[18:58] <smoser> you said /usr/share/pyshared/maasserver/models/config.py and change DISTRO_SERIES.precise to DISTRO_SERIES.quantal, right?
[18:58] <smoser> and then i sudo restart maas.pserv
[18:58] <smoser> but it still gives me precise
[18:58] <roaksoax> smoser: restart apache2
[20:34] <smoser> roaksoax, https://code.launchpad.net/~smoser/maas/trunk.import-ephem-fix/+merge/126543
[20:37] <roaksoax> smoser: done
[20:45] <smoser> thanks
[20:45] <smoser> verified that i can boot quantal ephenmeral
[20:45] <roaksoax> smoser: awesome!
[23:59] <smoser> bigjools, 'https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1055935' works for you?
[23:59] <smoser> i have failed on several attempts
[23:59] <bigjools> smoser: yes I had it working yesterday after I fixed the upstart file


[00:01] <MrChrisDruif> Aloha
[21:40] <MrChrisDruif> mhall119; have you heard anything from willcooke?
[21:52] <mhall119> not recently, no
[22:14] <MrChrisDruif> He was talking the other day about a meeting
[22:18] <MrChrisDruif> mhall119; ping me tomorrow about this, lets get this thing active again. Just like Phone & maybe even Tablet...


[03:00]  * ahoneybun trys to find typos in the docs and fails so far
[03:28] <ahoneybun> is there no mascot icon for 14.10 yet?
[16:36] <dsmythies> ahoneybun: the mascot icon is typically very very late in the cycle. I.E. not yet. Myself, I think it could be, and should be, much earlier in the cycle.
[16:42] <dsmythies> The same is true for changes that will require new screenshots.
[18:32] <ahoneybun> dsmythies: I'm not on utopic so I cannot take ss yet
[18:33] <ahoneybun> but I were needed to I would
[20:06] <ahoneybun> what is a letterhead?
[20:53] <dsmythies> ahoneybun: Typically corporate stationary for letters is pre-printed with the compnay logo, address, phone number, website URL, ... That is called letterhead.
[20:54] <dsmythies> ahoneybun: In the context of the the desktop docs I think they are talking about a template whereby the "letterhead" portion would be printed automatically and as a starting point, with the actual letter content added by the user.
[20:56] <dsmythies> ahoneybun: my point with SS comment was that is not yet time anyhow.
[21:10] <ahoneybun> dsmythies: just was wondering since the docs do not talk about it but I think now it might not matter


[07:16] <xubuntu47w> Hi all!
[07:17] <xubuntu47w> Looking for a solution for thunar crashes when cut and paste files. Any help?
[07:23] <flocculant> xubuntu47w: assuming you're up to date, then it's a known issue which isn't fixed yet
[07:28] <xubuntu47w> It's a nasty bug, i am desperate
[07:36] <flocculant> yes - we know that, yes - I understand
[07:39] <flocculant> you could always try a different file manager see if that helps you, something like pcmanfm perhaps
[07:47] <xubuntu47w> Thanks flocculant, I thinking to try Caja from Mate Desktop to remember the old-good nautilus
[09:19] <Aavar_> Hi. I am hoping someone can help me with the installation of Xubuntu. I have started the installation, and I am unsure if it is installing or not. I see the terminal window in the botom of the screen and it is listing warning messages and it has been doing so for a few hours. Is this normal?
[09:36] <flocculant> Aavar_: no - it's not
[10:11] <Aavar_> flocculant: Do you know what I can do about it? It says "detecting file systems". The only other (maybe related) issue I had was that it cant unmount /cdrom (probably because I don't actually have a cd-drive and is booting from a partition on a different harddrive.
[10:14] <olspookishmagus> hello, every time I open a new roxterm window it creates a 112x84 window which is really small, how do I tamper with this?
[10:43] <knome> Aavar_, the /cdrom issue you mention should not block the installation
[10:44] <olspookishmagus> answer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821357
[10:45] <Aavar_> knome flocculant: Could this be related to the partitions?
[10:46] <flocculant> Aavar_: what are you doing? installing from iso on a different partition?
[10:46] <Aavar_> flocculant: Yes I am installing from a partition on to another (on the same disk).
[10:47] <knome> Aavar_, did you select to use a custom partition setup when installing?
[10:47] <flocculant> Aavar_: not sure then tbh - I've only ever used grub to boot the iso
[10:47] <Aavar_> knome: Yes I did.
[10:48] <knome> i've done that once or twice, but it's years ago, so i totally don't remember the details
[10:48] <knome> do you have any possibility to just dumping the ISO on a USB disk or something?
[10:48] <knome> bbabl
[10:49] <Aavar_> knome: The reason why I am booting from a partition on the harddrive is that this computer does not like to boot from usb-drives (old Macbook)
[11:26]  * mladen-online is new to xubuntu and to IRC. What a day !
[11:28] <knome> congratulations
[11:33] <mladen-online> thanks knome. I really can't use facebook.
[11:48] <mladen-online> sorry guys but I just can't remember the name of the application the displays your system details on the desktop. Can help ?
[11:48] <bazhang> conky
[11:49] <mladen-online> eureka ! Thx
[11:49] <bazhang> ubuntuforums has a superb guide for this
[11:49] <bazhang> 'conky beginners guide'  <--- first hit
[11:50] <mladen-online> what's ubuntu forums ? a irc hannel ?
[11:50] <bazhang> an online help forum
[11:50] <mladen-online> ok
[12:11] <knome> !conky | bazhang
[12:11] <knome> bazhang, just added the factoid for future use
[12:13] <bazhang> great call knome thanks
[12:14] <mladen-online> thanks ubottu. I was exactly looking for this. I just installed conky via terminal and the default aspect looks so bad, it nearly made me blind
[12:15] <bazhang> thats a bot
[12:15] <mladen-online> really ? wouaw
[12:15] <mladen-online> does the bot understand what i say ?
[12:16] <bazhang> sure hope not
[12:16] <mladen-online> how do i distinguish bots from humans ?
[12:18] <mladen-online> maybe by their speach that sound like google ? lol
[12:30] <knome> mladen-online, uBOTtu
[12:31] <knome> basically bots should only respond to specific calls, eg. in this case, the line starting with "!conky" (without the quotes)
[12:32] <knome> bbl
[12:32] <mladen-online> okay
[12:33] <mladen-online> !ubottu hi
[12:34] <mladen-online> :'(not polite
[12:35] <mladen-online> ah my syntax is incorrect
[12:35] <mladen-online> !hi
[12:35] <mladen-online> :)polite !
[12:37] <mladen-online> okay. I am installing some helpful applications and updates on my new xubuntu install. But before going further I would like to create a LVM picture of my PC. Do you know how to do that ?
[12:43] <mladen-online> have to go. bye :)
[13:41] <Aavar_> I managed to install XUbuntu to the drive, but it won't boot when I select it at boot time. As mentioned earlier this is a Mac. How can I fix this?
[13:41] <choki> sorry i dont know, maybe you ask in #ubuntu
[13:42] <choki> did you choose the mac iso?
[13:42] <flocculant> Aavar_: might help to know exactly what 'happens'
[13:46] <Aavar_> flocculant: of cource... my bad. It shows an error. "Non-system disk. Press any key to reboot"
[14:34] <flocculant> Aavar_: sorry - was afk there. Not going to be of much help, with *my* experience that is - troubleshooting apple issues is not something I am much use with
[14:34] <flocculant> have some (more) patience and see who else pops up
[15:16] <Aavar_> flocculant: okey. Thank you anyway :)
[16:21] <flocculant> Aavar_: you might want to ask 'question' periodically, this being irc ...
[18:44] <ax562> hello hello hello
[20:35] <Sandeira> Anyone see my Question in #Xubuntu-offtopic ?
[20:37] <MR-DOS> what was your question
[21:14] <tmsbrg> what input system does Xubuntu 16.04 use? The kind of software like ibus, except it's not ibus
[21:20]  * mladen-online is back on hexchat
[21:21] <mladen-online> the graphics are a little sad, but new interresting functionalities
[21:22] <mladen-online> so, as said before, first day on IRC. Also first day on xubuntu. Which is nice btw
[21:23] <tmsbrg> Xubuntu really is nice
[21:24] <mladen-online> I'm looking for a software that allows me to flash a microcontroller
[21:24] <mladen-online> I used to have flash magic, but that's only for windows or mac
[21:24] <mladen-online> and I'd like to avoid vine
[21:24] <mladen-online> any idea ?
[21:25] <mladen-online> bang ! tough question for a first day !
[21:27] <tmsbrg> sorry, i don't flash microcontrollers every day. Actually I never do
[21:27] <tmsbrg> what I do every day however is type " on top of letters which I'm now unable to due to what seems like an input system bug
[21:27] <mladen-online> yeah. that's not a funny thing to do. That's understandable
[21:29] <mladen-online> actually I'm trying to fix a keyboard (for music) : M-audio Axiom Pro 61 keys, that doesn't boot
[21:33] <mladen-online> Maybe you have ever heard about a small program written in python, called : miniterm.py
[21:33] <mladen-online> ?
[21:33] <mladen-online> Does that ring your bell ?
[21:35] <mladen-online> I saw a guy on youtube, using this to talk to his microcontroller from a linux OS
[21:36] <mladen-online> but not really user friendly. That's why I ask on this channel if any of you know a software to program microcontrollers from linux
[21:44] <tmsbrg> the answer to my question apparently was XIM
[21:46] <tmsbrg> and installing ibus fixed my bug of not being able to type things like ï with the altgr dead keys input method
[21:48] <Unit193> tmsbrg: It used to be shipped by default, but there was some big problems with it.
[21:48] <tmsbrg> there were? I know it used to be, because I used to always use it. Never had problems with ibus myself though
[21:49] <tmsbrg> well except https://bugzilla.mozilla.org/show_bug.cgi?id=1138159 but I solved that
[21:52] <tmsbrg> maybe I should report this, but I just installed Xubuntu, and in the install menu I picked US international AltGr dead keys (the best keyboard layout for international programmers), tested it and it worked fine (press altgr+" and then i to get ï, press " to get regular ", no dead key); but then when Xubuntu was installed it broke. Pressing altgr+" wasn't a dead key anymore (and neither was regular "), so I couldn't type ï etc.
[21:52] <tmsbrg> just installed 16.04 that is


[21:43] <OvenWerks> are there any ways of prioritizing what an OOM event kicks out?
[21:45] <OvenWerks> killing part of the DE seems like the worst solution as it pretty much kills everything. But that is what I have had happen a few times. Using 23.04.
[21:45] <OvenWerks> of course it may be FF causing a crash in one of the DE componants...
[22:01] <OvenWerks> Ok, might be fixed sinse. I think this line in syslog spells it out: kernel: [396310.220870] kwin_wayland[7870]: segfault at 7f38958ca104 ip 00007f39271add91 sp 00007ffe835b4070 error 6 in libpipewire-0.3.so.0.365.0[7f392715d000+5a000] likely on CPU 1 (core 1, socket 0)
[22:02] <OvenWerks> It seems pipewire has segfaulted when wayland called it.
[22:02] <OvenWerks> (or wayland segfaulted whilst using a pw lib call.)
[22:04] <OvenWerks> studio doesn't (or didn't for 13.04) use wayland. So not worth a bug.
[22:05] <OvenWerks> I still think it is FF connected because it happened when starting FF. (which opens a lot of stuff all over)
[22:48] <Eickmeyer> OvenWerks: Just saw this.
[22:49] <Eickmeyer> Pipewire in 23.04 was... buggy.
[22:49] <Eickmeyer> Didn't know until after release.
[22:50] <Eickmeyer> By then it was too late, and even then the implementation felt hurried.
[22:54] <Eickmeyer> What's happening is, anytime a snap is opened (for the first time), it does a real fast squashfs decompression which takes quite a few CPU interrupts. Side effect is it steps on everything. I've noticed it causes xruns in jackd2, not so much in PW, but the PW in 23.10 is much more solid.
[22:55] <Eickmeyer> I have, in fact, brought this before the Ubuntu Desktop team, and they at least made a note of it.


[00:16] <daker> anyone got something about writing a browser with python & webkit ?
[04:10] <Zeike> does anybody have the link to the ppa with the latest tex stuff?
[05:17] <godbyk> ?mppa
[05:17] <godbyk> d'oh. bot's not listening.
[07:38] <ubuntujenkins> ?mppa | Zeike
[07:38] <quickshotdevs> Zeike: The manual team has a latex PPA  you can add it by running these commands in a terminal(Applications → Accessories → Terminal):  sudo add-apt-repository ppa:ubuntu-manual/ubuntu-manual then    sudo apt-get update    sudo apt-get install ubuntu-manual-tex
[07:38] <Zeike> ubuntujenkins: thanks!
[07:39] <ubuntujenkins> no problem sorry it took so long
[07:39] <Zeike> no worries
[11:55] <daker> hello everybody
[12:08] <thorwil> hi daker
[12:22] <thorwil> the one thing that really bothers me with eclipse is the project handling. it's actually a riddle how to open a project that is not in your current workspace dir
[13:31] <Nevon> Hey vish and thorwil, are either of you there? I was recommended by Benjamin to get in touch with you. I need some help making a non-sucky favicon for my new site, if you're up for it.
[13:32] <thorwil> Nevon: what is your new site (about)?
[13:32] <Nevon> It's a personal website/portfolio type of thing.
[13:32] <Nevon> I can show you if you're interested.
[13:34] <humphreybc> thorwil: doooo it
[13:39] <vish> ooh , non-sucky needed ;)
[13:45] <Nevon> thorwil gave me a couple of ideas to work from, so now I at least have something to get me started.
[13:45] <Nevon> The biggest problem was that I couldn't come up with any good ideas.
[14:48] <daker> humphreybc, anything about the new design ?
[14:48] <humphreybc> daker: Nope, my last exam was today though so I'll be working on the design a lot next week. Just waiting on icons from Vish
[14:49] <daker> ko
[14:58] <daker> US vs Slovenia
[15:13] <daker> haha Solvenia 1
[16:15] <vish> humphreybc: i'm not sure what the larger icons on side are supposed to mean > http://www.flickr.com/photos/humphreybc/4695964476/sizes/l/in/set-72157624139515783/
[16:16] <vish> doesnt seem to make sense with the philosophy page
[16:17] <vish> the watermarks^
[16:48] <flan> Has anyone seen ubuntujenkins recently?
[16:57] <nisshh> flan: not since yesterday
[16:57] <daker> he was here this morning  i think
[16:58] <nisshh> daker: yea he might have been, i wasnt on thismorning so i dont know
[16:59] <nisshh> bye all
[17:26] <flan> Ah. Well, if anyone sees him before I do, please let him know I'm available for help with creating a test workflow setup.
[17:26] <flan> Thanks.
[17:42] <thorwil> godbyk: i replied to Daniel Schury on the list and directly to him, with link to your answer to him in the list archive
[22:15] <ubuntujenkins> evening all
[22:17] <Zeike> hi, ubuntujenkins
[22:17]  * ubuntujenkins now has to play the how long untill he loses wifi game
[22:17] <ubuntujenkins> heyy Zeike
[22:17] <Zeike> I hate that game =\
[22:19] <ubuntujenkins> so do i also have the added factor of i can't reconnect as it means waking the whole house and getting shouted at
[22:40] <_ubuntujenkins> hey i don't see godbyk
[22:42] <_ubuntujenkins> is anyone there?
[22:42] <_ubuntujenkins> |ping
[22:43] <_ubuntujenkins> !welcome
[22:43] <manualbot> Hi! Welcome to #ubuntu-manual! Feel free to ask questions and help people out. The channel guidelines are at https://wiki.ubuntu.com/IRC/Guidelines . Enjoy your stay!
[22:51] <ubuntujenkins> !ping
[22:51] <manualbot> pong
[22:52] <ubuntujenkins> yey
[23:17]  * ubuntujenkins is in windows because ubuntu wifi ddoes not reconnect but windows does
[23:34] <ubuntujenkins> night all


[01:19] <LLStarks> chrisccoulson, i can't get google reverse image search to work on any linux browser. can you confirm?
[01:23] <LLStarks> nvm, you can brute force it with the extension
[18:55] <chrisccoulson> m_conley, is there any reason why messagingmenu-extension only shows mail boxes in the menu whilst doing a notification?
[18:55] <chrisccoulson> (rather than all the time)
[18:55] <chrisccoulson> i'm not sure if that's clear in the spec, but other applications show items in there all the time, and then request attention when they get new items
[18:56] <m_conley> chrisccoulson: oh, I think that was me misunderstanding the spec
[18:56] <m_conley> chrisccoulson: I actually think that makes the implementation easier
[18:56] <chrisccoulson> m_conley, that's ok. i can fix that
[18:56] <m_conley> chrisccoulson: having the folders display all the time
[18:56] <m_conley> chrisccoulson: thanks! :D
[22:00] <jdstrand> fta: I am looking at your apparmor denials. the lightdm one is easy enough, but the others seem to be related to printing while running evince under sudo? does that sound right? do you have a reproducer?
[22:14] <fta> jdstrand, i just opened a pdf, no printing involved, not even a preview
[22:14] <jdstrand> ok, I'll try to reproduce
[22:39] <micahg> ugh, I just realized that dh_python2 will make mozilla-devscripts not backportable due to the python-all-dev dep :(
[22:40] <chrisccoulson> we don't need to backport it do we?
[22:40] <micahg> no, not really
[22:41] <micahg> but I was tried to be considerate of the fact for Debian, and I guess I goofed, er, maybe not, Debian squeeze meets the build-dep, so I guess we're good
[23:06] <chrisccoulson> m_conley_away, oh, i figured out bug 797680
[23:06] <ubot2> Launchpad bug 797680 in globalmenu-extension ""thunderbird -addressbook" and "thunderbird -compose" open a window without putting the menu in the panel" [High,Triaged] https://launchpad.net/bugs/797680
[23:06] <chrisccoulson> it's a really easy problem to solve :)
[23:43] <fta> micahg, M13 in beta
[23:45] <micahg> fta: yep, which version builds with gcc-4.6?
[23:45] <fta> M14
[23:45] <micahg> k


[14:52] <greg-g> yeah, chanserv "protects" the channel, I forget what exactly, part of what I did when I registered it oh so many years ago
[15:25] <Scary_Guy> lol
[15:25] <Scary_Guy> "around 10 minutes" and over an hour later...  par for the course I guess
[16:36] <cmaloney> heh


[19:44] <Oranger> mhall119: No meeting today ?
[19:48] <balloons> Oranger, there you are :-)
[19:48] <balloons> come into #ubuntu-touch-meeting


[05:56] <pitti> Good morning
[05:56] <Unit193> Heya.
[07:03] <pitti> tyhicks, kirkland: *sigh*, more trouble with ecryptfs swap: bug 1453738
[07:03] <pitti> it seems for the past several years we have set up unencrypted or broken swap and nobody noticed :/
[07:06] <pitti> except that this bug is worse, as we unintentionally use unencrypted swap
[07:19] <Mirv> something has just killed i386 building? https://launchpadlibrarian.net/208901928/buildlog_ubuntu-wily-i386.webbrowser-app_0.23%2B15.10.20150610-0ubuntu2_BUILDING.txt.gz happens on multiple sources
[07:19] <Mirv> "dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None died with signal 11"
[07:19] <Mirv> and i386 only
[07:20] <Mirv> all cmake though
[07:21] <Mirv> all I know is that they built on Wednesday at least
[07:25] <Mirv> it seems cmake specific, but I don't see anything recent related to that uploaded
[07:44] <Frantique> hello all
[07:45] <Frantique> guys, why it is so slow to give a review to the updated packages on developer.ubuntu.com?
[07:47] <zzzdeb> hello, is there any way i can create a deb package that makes a delay at install?
[07:48] <Frantique> zzzdeb: perhaps a sleep in preinstall script?
[07:49] <Frantique> or in postinstall, depending on the needs, ofcourse
[07:53] <Mirv> actually, I had a successful build 13h ago, and now those cmake i386 failures
[07:54] <caribou> I need some help with a merge :
[07:54] <caribou> I have fixed all conflicts from grab-merge and trying to build the source pkg
[07:55] <caribou> turns out that apparently one of the source in the tarball has been modified by grab-merge
[07:55] <caribou> is it to be expected ?
[07:55] <caribou> i.e. one patch from the previous version is applied in the merged output
[08:02] <Mirv> caribou: I'm not sure if I understand the context, but you might want to change the source version number (if the source is not actually same anymore), or unapply the patch if it has been accidentally applied and should actually be in debian/patches and only applied at build time
[08:03] <Mirv> Frantique: you could try asking on #ubuntu-app-devel regarding the review
[08:03] <caribou> Mirv: that's what I'm doing atm. I got the pristine source from the tarball & crafting a quilt patch to keep the modification applied
[08:03] <caribou> Mirv: I am just surprized that MoM didn't flag that as a conflict
[08:05] <Frantique> Mirv: thanks
[08:11] <zyga> cjwatson: hey, do you know who I can ping to get tarmac reviews?
[08:11] <zyga> cjwatson: I sent out an introductionary merge request a few days ago but without any response
[08:11] <zyga> cjwatson: I'm working on more changes locally to actually do stuff but I'm worried with the lack of response so far
[08:35] <LocutusOfBorg1> Hi ubuntu sponsors, your opinion on bug 1297849 ?
[08:35] <LocutusOfBorg1> seems that syncing network-manager* stuff from debian might be the easiest solution, at least for wily
[08:46] <Mirv> infinity: we believe the gnutls broke all i386 cmake builds https://launchpadlibrarian.net/208901967/buildlog_ubuntu-wily-i386.unity8_8.02%2B15.10.20150603.1-0ubuntu2_BUILDING.txt.gz
[08:46] <Mirv> sil2100: ^
[08:46] <Mirv> that's the only thing that matches the timing, and it seems gnutls is somehow used by cmake at least
[09:01] <Mirv> sil2100: infinity1: confirming i386 building without an issue without -proposed, so I filed bug #1464569
[09:15] <cjwatson> zyga: if it were me I would try the last three or four people from the intersection of (has committed to trunk, is in the team that can do so)
[09:16] <zyga> cjwatson: thanks
[09:16] <sil2100> Mirv: thanks!
[09:16] <sil2100> infinity1: we'll have to do something with the new gnutls28 as it's really breaking stuff
[09:17] <cjwatson> Does a straight cmake rebuild fix things?  (Would be quick to try locally, I expect)
[09:18] <cjwatson> Or possibly a curl rebuild
[09:51] <LocutusOfBorg1> cjwatson, sil2100 Mirv
[09:51] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1462934
[09:52] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1459685/comments/9
[09:52] <LocutusOfBorg1> ^^^^
[09:52] <LocutusOfBorg1> unfortunately it has been uploaded before gnutls, not after :)
[09:53] <LocutusOfBorg1> You might look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784009 too
[10:01] <sil2100> Oh :)
[10:01] <sil2100> LocutusOfBorg1: thanks!
[10:01] <LocutusOfBorg1> I mentioned in the merge request, but not enough loudly ;)
[10:01] <LocutusOfBorg1> sorry for the confusion
[10:02] <LocutusOfBorg1> thanks to you!
[12:20] <zyga> cjwatson: hey, did you see my question about ppa and code exporter earlier
[12:21] <zyga> cjwatson: I'm curious if the restriction not to export bzr branches from launchpad-based git branches
[12:21] <cjwatson> zyga: I think you were offline when I tried to reply
[12:21] <cjwatson> zyga: Where do PPAs come into it?
[12:22] <zyga> cjwatson: is intentional or a tech limitation
[12:22] <zyga> cjwatson: and what is the recommended way to get ppa packages built from git repos
[12:22] <zyga> cjwatson: perhaps, I had some issues with my machines latelty
[12:22] <zyga> cjwatson: they are built from recipes
[12:22] <zyga> cjwatson: from bzr branches
[12:23] <cjwatson> zyga: And indeed, there is such a restriction on code imports at the moment (historically, it was to prevent circular imports from other bzr branches on LP), which we'll lift soon
[12:23] <cjwatson> zyga: Recipes are on the to-do list, which I'm pretty sure I've told you before, we don't have a "recommended way" yet
[12:24] <zyga> cjwatson: that makes sense, so the recommended way will be to use bzr exportrs for recipes?
[12:25] <cjwatson> There will probably be a transitional period when LP-git-to-LP-bzr imports work but recipes don't yet
[12:25] <cjwatson> But we do intend to make recipes work for git too
[12:26] <zyga> cjwatson: oh, I must have missed that, thank you
[12:27] <cjwatson> The import limitation dates from bug 820069
[12:28] <cjwatson> Well, and a similar thing in the codeimport worker
[12:29] <cjwatson> Which is rather older, 2007-era
[13:38] <rbasak> shaderslayer: test docker.io backport packages at https://launchpad.net/~docker-maint/+archive/ubuntu/staging. I will review and upload for SRUs soon.
[15:00] <shaderslayer> rbasak: thanks!
[15:00] <rbasak> shaderslayer: please let us know how you get on
[15:01] <shaderslayer> will do :)
[15:02] <shaderslayer> rbasak: oh, would have been nice to have armhf packages too
[15:02] <rbasak> shaderslayer: can you rebuild locally OK? The PPA just isn't enabled for armhf that's all.
[15:03] <rbasak> shaderslayer: when we upload to Ubuntu you'll get armhf
[15:03] <shaderslayer> rbasak: yeah, I reckon we'll do that
[15:28] <infinity> sil2100: Ugh.  Who turned off proposed in that silo to make the package build?  That's not helpful.
[15:33] <arges> hallyn: does lxc by default set any cgroup.cpu.* settings?
[15:33] <arges> hallyn: n/m i can just lxc-info it
[15:47] <hallyn> arges: nope
[15:48] <arges> hallyn: thanks, yea see it now
[15:51] <barry> pitti: are you still around?  q re: adt-run
[16:27] <sil2100> infinity: we did that, the unity8 was required for a landing
[16:27] <infinity> sil2100: ...
[16:27] <sil2100> infinity: it's eaisly reproducible in anything ;p!
[16:28] <sil2100> Mirv reproduced it with some strange package in his PPA
[16:28] <infinity> sil2100: That's not the point.  Those PPAs have proposed enabled for a reason.
[16:28] <infinity> sil2100: Skipping past transitions in proposed means the transitions never finish (and can even regress).
[16:28] <infinity> sil2100: Was unity8 in *wily* that important that it couldn't wait for a proper fix?
[16:29] <sil2100> infinity: ok, sorry about that then, we didn't know it depended actually on anything that was in transition, it was a dual landing so it required landing to both places, wily first even
[16:30] <sil2100> Since we thought that the problem was in a dependency of a dependency
[16:30] <infinity> sil2100: Might be a process failure if "dual landing" implies "hack around breakage in the devel series".
[16:30] <infinity> sil2100: It may well have not caused an issue, I haven't checked, but generally, turning off proposed is a Bad Thing.
[16:31] <infinity> sil2100: And I keep running into silo PPAs where it's been turned off and never back on, which is also irksome.
[16:31] <sil2100> infinity: noted, well, having proposed enabled also includes additional risks, especially when you land to the overlay without proposed-migration, since you could basically build against a broken library that would be dropped
[16:31] <sil2100> So it's a double-edged sword anyway
[16:32] <sil2100> infinity: I have re-enabling the PPA to use -proposed in my daily-doings, so this one wouldn't be forgotten
[16:33] <infinity> sil2100: Anyhow, I'd argue the process needs revision to match the SRU process.  SRUs require "fix in devel", but that really just means "uploaded, so we don't lose the code change", not "uploaded, built, and migrated" or anything.
[16:33] <infinity> sil2100: dual landing should likely be similar.  The goal is to not lose the change, not to force people to hack around temporary problems just to get B landed before A.
[16:43] <sil2100> infinity: right... sadly right now the dual landing required landing both at once
[16:44] <sil2100> We *could* release just one, but only after removing binaries of the other from the PPA
[16:44] <sil2100> Which sucks a bit
[16:44] <sil2100> But yeah, dual-landings is a quick helper thing
[18:00] <smoser> infinity, i suspect you know if anyone... is there a way that i can disable initramfs update that would happen as a result of 'apt-get install' operation ?
[18:01] <smoser> strikov and i are wanting to avoid that as we know we're going to haev to update ourselves. and just want to save some time.
[18:02] <cjwatson> The standard way we use in various places is to divert it aside temporarily and replace with a trivial wrapper.  See livecd-rootfs for example.
[18:02] <ogra_> mv  /usr/sbin/update-initramfs /usr/sbin/update-initramfs.real && ln -s /bin/true /usr/sbin/update-initramfs
[18:02] <ogra_> (and revers it after update)
[18:03] <cjwatson> Please use dpkg-divert instead.
[18:03] <cjwatson> I gave a pointer already which is better.
[18:03] <ogra_> yeah, sorry, i was typing :)
[18:03] <cjwatson> You don't want your work to be undone if an initramfs-tools upgrade happens to arrive.
[18:04] <ogra_> indeed, thats just a quick hack ... diverting is the proper way
[19:15] <DreadPirateBob> Getting a failure on launchpad in my PPA. bzr bd -- -k <parentkeyid> is signing with <subkeyid>. dput succeeds, but the build fails because it doesn't recognize the key.
[19:15] <DreadPirateBob> Anyone know how to get this working?
[19:15] <DreadPirateBob> barry maybe? (Hi Barry)
[19:22] <DreadPirateBob> Nevermind. Confusing output, but not an error.
[19:23] <barry> DreadPirateBob: ok... and hi!
[19:25] <DreadPirateBob> backportpackage showed the right thing, so I was confused
[19:53] <cjwatson> DreadPirateBob: You mean the complaint about being unable to check the signature on the .dsc?
[19:56] <cjwatson> Or possibly the one about the public key for the archive on ppa.launchpad.net being unavailable.  Either way, we should suppress both of those when we get round to it, but at least it's only cosmetic.
[20:04] <DreadPirateBob> This was two fold: when I ran bzr bd -S -- -k<myparentkey>, when it got to the signing part, it prompted me for the subkey. Then dput verified using the subkey, and then showed a warning in the build log that the key could not be verified.
[20:05] <DreadPirateBob> but the subkey is not shown in the launchpad ui
[20:10] <DreadPirateBob> probably just a display setting.
[20:37] <meles> I'm havin a problem when trying to get my ambient light sensor working. I would need the value of /sys/class/backlight/acpi_video0/max_brightness which is not found. Instead I have /sys/class/backlight/intel_backlight/max_brightness. Is there any way to link it?
[20:41] <shadeslayer> does anyone know how to switch to the gold linker for a package?
[21:07] <shadeslayer> -fuse-ld=gold for now I guess :3
[21:33] <cjwatson> DreadPirateBob: Right, anything you see in the build log about key verification is cosmetic and should be silenced; Launchpad does all the verification well before it gets to the point of building the source package, and doesn't need to do it again there, but we haven't made all the warnings shut up :-)


[06:37] <LocutusOfBorg> vorlon, thanks fixing them up
[06:37] <LocutusOfBorg> FYI this one loooks deeeeeeead? https://launchpad.net/ubuntu/+source/alsa-plugins-extra/1.1.0-1ubuntu1
[06:38] <LocutusOfBorg> please kill it with fire!
[07:33] <sil2100> o/
[07:33] <sil2100> Released some bionic packages and will be spinning first candidate images for 18.04.6 shortly
[11:10] <RikMills> release team: could I perhaps get an ack on LP: #1943376
[11:11] <RikMills> we have done a similar FFe at this stage for quite a few releases now without major issue
[11:12] <RikMills> kde devs also tend to tell us if there are any issue that crop up that need an extra upstream patch
[11:12] <RikMills> sil2100 laney perhaps?
[11:13] <RikMills> I am not sure tsim0nq2 is around to do a delegated ack on it, hence asking you
[11:20] <ricotz> hello, please take a look at https://bugs.launchpad.net/ubuntu/+source/expat/+bug/1943133
[11:20] <ricotz> RikMills, hi :)
[11:21] <RikMills> o/
[11:29] <sil2100> Done
[11:29] <sil2100> Oh, and expat too? Looking
[11:34] <RikMills> sil2100: thank you :)
[11:35] <sil2100> ricotz: hey! Left a comment on the FFe bug, could you take a look?
[11:49] <ricotz> sil2100, hi, I added a note
[12:37] -queuebot:#ubuntu-release- Unapproved: nvidia-settings (focal-proposed/main) [470.57.01-0ubuntu<IP_ADDRESS> => 470.57.01-0ubuntu<IP_ADDRESS>] (i386-whitelist, ubuntu-desktop)
[13:21] -queuebot:#ubuntu-release- Unapproved: accepted procps [source] (focal-proposed) [2:3.3.16-1ubuntu2.3]
[13:32] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.6] (20210913.1) has been added
[14:19] <bdmurray> sil2100: Have you looked at the Bionic desktop iso being oversized?
[14:27] <sil2100> Not yet!
[14:27] <sil2100> Can you take a look if there's anything suspicious?
[14:27] <sil2100> I'll build the other images now
[14:45] <bdmurray> sil2100: python3-click and python3-coloroma are new on the bionic-desktop iso but they shouldn't be very large
[15:18] <sil2100> bdmurray: ok, do you know how much bigger the images got? Since maybe the kernels got bigger etc.
[15:18] <sil2100> I don't think it's anything super suspicious tho, at least not instantly
[15:18] <sil2100> The limit was probably quite low for bionic
[15:19] <bdmurray> ubuntu/daily-live: bionic-desktop-amd64.iso oversized by 314124800 bytes<PHONE_NUMBER>)
[15:19] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.6] (20210913) has been added
[15:19] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.6] (20210913) has been added
[15:23] <sil2100> huh, that's quite a lot, I wonder
[15:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.6] (20210913) has been added
[16:12] <bdmurray> sil2100: Is there something more I should look at than diffing manifests?
[16:13] <sil2100> I guess checking .list might be good, since that's what's in the pool on the image I suppose
[16:13] <bdmurray> I looked there too and that was uninteresting
[16:51] <vorlon> juliank: heh, bad German translation somewhere in grub-land, "EFI Boot* variables" is mistranslated as "EFI-Start* variables"
[16:51] <vorlon> (LP: #1943471)
[16:51] <vorlon> sorry, "Variablen"
[16:58] <vorlon> https://translations.launchpad.net/ubuntu/impish/+source/grub2/+pots/grub/de/+translate?batch=10&show=all&search=Cannot+read+EFI not sure how to ensure my suggestion gets accepted
[17:18] <juliank> vorlon: meh, wfm
[17:18] <juliank> vorlon: sounds like how Debian would translate it
[17:19] <juliank> vorlon: start is more German than boot
[17:19] <juliank> :F
[17:19] <juliank> :D
[17:19] <juliank> Sigh typo
[17:27] <juliank> vorlon: I now get it, it's supposed to be a glob pattern
[17:59] <bdmurray> blackboxsw: bug 1938043 is available for verification
[18:14] <vorlon> juliank: right :)
[18:29] <vorlon> ick @ gtk4 no-change rebuild causing a binary package to be dropped
[22:59] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.6] (20210913.1) has been added
[22:59] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.6] (20210913.1) has been added
[22:59] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.6] (20210913.1) has been added
[22:59] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.6] (20210913.1) has been added
[22:59] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.6] (20210913.1) has been added
[22:59] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.6] (20210913.1) has been added


[09:54] <AtomicSpark> Anyone awake? :)
[09:56] <jpds> AtomicSpark: Possibly.
[09:58] <AtomicSpark> Ha. You tricksters! I was trying to grab the bzr of the server guide and the wiki's example was for kubuntu. :3
[09:58] <AtomicSpark> It's way too late/early to be that observant.
[09:59] <AtomicSpark> So the wiki says I can edit something and then submit it? Does that mean there is a public upload access that is... reviewed?
[10:01] <jpds> AtomicSpark: Bzr branches for the ubuntu-docs are at https://code.edge.launchpad.net/ubuntu-docs
[10:02] <jpds> AtomicSpark: Which wiki are you referring to?
[10:02] <AtomicSpark> Yes I found that. Just removed the 'k' ;)
[10:02] <AtomicSpark> Somewhere around https://wiki.ubuntu.com/DocumentationTeam/Mentoring
[10:03] <jpds> bzr branches → reviewed, wiki.u.c → open to edits from all.
[10:04] <AtomicSpark> so how do i submit my edit for review? do i just bzr update?
[10:05]  * AtomicSpark isn't used to bzr
[10:05] <jpds> AtomicSpark: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/using_bazaar_with_launchpad.html
[10:05] <AtomicSpark> i figured update was one way. just updated my local checkout.
[10:07] <jpds> AtomicSpark: I suggest you read: http://doc.bazaar.canonical.com/bzr.2.0/en/mini-tutorial/index.html too.
[10:08] <AtomicSpark> My question is more what to do, rather than how to use bzr. Am I supposed to checkout the file I want to work on and then push for review? Or is that type of access only avalable to members?
[10:09] <jpds> AtomicSpark: You have to push it to a separate branch on Launchpad and then submit a merge proposal for it.
[10:09] <AtomicSpark> Hmm.
[10:09] <jpds> AtomicSpark: An example of mine being: https://code.edge.launchpad.net/~jpds/launchpad/fix_176396/+merge/16082
[10:11] <AtomicSpark> That makes sense.
[10:11] <jpds> (This one is for launchpad though, not the docs.)
[10:11] <AtomicSpark> In theory, it's the same thing. :)
[10:11] <jpds> Yep.
[10:20] <AtomicSpark> Do i need to retain the paths of the original branch? Let's say I want to edit karmic/serverguide/C/file.xml, do I need to have the path karmic/serverguide/C in my branch? or just the file.xml?
[10:20] <jpds> Either one. :)
[10:21] <jpds> AtomicSpark: Did you create your own branch first by branching lp:ubuntu-docs?
[10:21] <AtomicSpark> Yes.
[10:22] <jpds> Groovy.
[10:22] <AtomicSpark> I was just going to create another and just copy the relevant file over.
[10:22] <jpds> AtomicSpark: You can do that with: bzr branch ubuntu-docs my-branches-for-changes .
[10:44] <AtomicSpark> jpds: So I assume you find it easier to have a global launchpad project and just do individual branches for bugs? probably is the easiest way to go about it. might even be de facto!


[11:51] <geppy> socomm: Thanks!
[11:57] <phosphorgreen> hello all
[11:57] <Mr_Elendig> hi
[11:57] <phosphorgreen> does anyone here have experience with wu-imapd
[11:58] <phin> hey, is there a way to get the trash BACK on the desktop?!
[11:59] <rempresent> my graphics card isn't working as fast, or it seems like it is chuggy, how can i go about diagnosing this?
[11:59] <handsome_b> hello everybody