[00:40] <ali1234> my favourite is the "reservoir dogs" episode with o'brien going undercover
[00:42] <ali1234> http://memory-alpha.wikia.com/wiki/Honor_Among_Thieves_(episode)
[01:50] <ARW387> ▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETbiorn: andylockran czajkowski james_w` yaiyan lubotu3` Laney Laurenceb twinsen^wee nhandler Oli ali1234 Myrtti aptanet Dave mcs_ popey webpigeon pendulum organic ubot9 acheronuk tomred Nafallo BobMottram[m] KrimZon_2 foobarry StevenR_ m0nkey_ Seeker` evildespot daf
[01:50] <ARW387> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETbdupgjnumq: SuperMatt acheronuk evildespot Laney arsenip webpigeon tomred ali1234 StevenR_ daftykins Myrtti zmoylan nhandler popey KrimZon_2 hazrpg foobarry mcs_ flexiondotorg DJones Darkstar_ m6lpi BobMottram[m] ubot9 aptane
[01:51] <ARW387> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETnfzec: popey arsenip Cueball andylockran foobarry StevenR_ Darkstar_ tomred yaiyan SuperMatt GregKNicholson[m organic higgins czajkowski ubot9 ujjain lubotu3` acheronuk nhandler evildespot flexiondotorg twinsen^wee pendulum zleap BobMo
[01:51]  * m0nkey_ sighs
[02:02] <kazz556> ▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETpvdtmd: ahayzen BobMottram[m] ujjain nhandler NET||abuse Chrisfu Nafallo pendulum ikonia 92AACJTTI ali1234 Hirppa evildespot Lcawte Darkstar_ m6lpi Azelphur twinsen^wee aptanet Chaser WillMoogle directhex Laurenceb ilbelkyr chrisccoulson stryx` Unit193 StevenR_ xnox GregKNic
[02:02] <kazz556> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETsstxfzwn: Lcawte StevenR_ ikonia pendulum 92AACJTTI dogmatic69 lubotu3` stryx` m6lpi organic mcs_ Cueball Chrisfu BobMottram[m] diddledan GregKNicholson[m Chaser ali1234 NET||abuse Laurenceb WillMoogle Nafallo twins
[09:13] <Nafallo> o/
[09:13]  * Nafallo looks for brobostigon
[09:18] <SuperMatt> morning all
[09:18] <SuperMatt> I'm moving in to my last week at work :)
[09:28]  * brobostigon spots Nafallo
[09:29] <Nafallo> brobostigon: no keep-alive this morning? :-)
[09:30] <brobostigon> nope, :)
[09:33] <foobarry> do processes stopped with ctrl-Z consume memory resources? i guess so
[09:37] <SuperMatt> They will still hold on to the memory they already had
[10:04] <foobarry> yep, just checked , thx
[10:04] <foobarry> assumed so
[10:16] <SuperMatt> All right dudes, you have to entertain me during my last week
[10:23] <foobarry> microbit 8.50 from ebay
[10:23] <foobarry> QES
[10:23] <foobarry> QED
[10:24] <SuperMatt> Don't know what that is
[10:29] <zmoylan> a microbit is a tiny cpu with a few k of ram and few k of storage.  it was designed for school kids and all kids in uk schools were given one.
[10:32] <SuperMatt> I see
[10:32] <SuperMatt> wouldn't arrive in time, and I don't want to put more pain on the postal and courrier services
[10:38] <brobostigon> maplins sell them i believe.
[10:41] <SuperMatt> oh, well there is a maplin close to me
[11:19] <foobarry> they are wasted on kids
[11:20] <foobarry> they have accelerometers, GPIO and other bits on me
[11:20] <foobarry> them
[11:21] <SuperMatt> hmmm, sounds like it could be fun to tinker with
[12:08] <foobarry> oh and they can communicate with other micro bits on RF frequencies
[12:11] <brobostigon> and can be battery powered.
[12:14] <SuperMatt> got a display and wifi?
[12:26] <brobostigon> 5x5 led matrix, bluetooth(no wifi).
[12:28] <SuperMatt> dang, I want something with wifi
[12:28] <SuperMatt> and a bigger screen
[12:29] <foobarry> pi zero w?
[12:29] <foobarry> with blinkt
[12:29] <SuperMatt> probably something like that would go down nicely
[12:29] <foobarry> thinking of getting the redmi 5 phone on release
[12:29] <foobarry> to replace moto g 1st gen
[12:30] <foobarry> althoug i like the screen size of the moto g
[12:30] <foobarry> everything seems bigger now
[17:00] <daftykins> nasty train derailment in the US :( http://www.kiro7.com/news/local/train-derails-onto-i-5-in-pierce-county-all-lanes-blocked/665619813
[17:26] <diddledan> dang
[17:33] <diddledan> apparently the train only started service today?
[17:35] <daftykins> well i fear it won't be finishing it
[17:35] <daftykins> also saw a claim the track in that area was recently 'upgraded' to handle higher speeds


[12:16] <CardinalFang> aquarius, did you see my message yesterday about d-c pairing and couch?
[12:16] <CardinalFang> aquarius, you used "put", not "put_record".
[12:17] <CardinalFang> I haven't run the code, but I think that's not right.
[12:34] <aquarius> CardinalFang, I agree, it's not right; that code fails before it gets that far because of the 401 problem
[12:35] <aquarius> CardinalFang, how did you guys get on after I left?
[12:35] <CardinalFang> aquarius, well, I'm up early to get code out the door, if that tells you anything.
[12:36] <CardinalFang> aquarius, nothing new to report.
[12:36] <CardinalFang> aquarius, except statik merged some branches.
[12:36] <aquarius> kk
[12:37] <aquarius> want me to work on some of the stuff with you?
[12:37] <aquarius> is there anything you're doing that I can pick up?
[12:46] <aquarius> CardinalFang, or have you basically done it all? :)
[12:48] <CardinalFang> aquarius, hmm.  I've done nothing with actually getting oauth tokens, so "pairing storing oauth tokens".  Also, I plan to move some that code of yours yesterday into the desktopcouch.pair.couchdb_pairing.couchdb_io so it can be shared with the local stuff where possible.
[12:49] <aquarius> CardinalFang, hang on, I didn't quite follow that
[12:50] <CardinalFang> aquarius, ignore the second sentence for now.
[12:51] <aquarius> so...the things that you were doing, as I understand it, are: have the pairing app exchange oauth tokens as part of the on-the-wire protocol, and the daemon which starts and maintains continuous replication. If I read you right, you're working on the second (the daemon) but not the first (the pairing app)?
[12:53] <CardinalFang> aquarius, we need to get/generate oauth tokens for every pairing, as I understand it (which is really not at all!).  If you can make the function that gets the token from U1 (?), I can make the pairing tool exchange them.  Yes, I'm doing 2.  If you will do 1a, I'll also do 1b.
[12:55] <aquarius> ok. I've already done the code which initially generates the oauth token and stores it in the ini file; I'll write a function which can extract that token from the ini file so you have access to it
[13:01] <CardinalFang> Grr.  0800.  Must take the kid to the babysitter.    :(  I really must read up on oauth one day.
[13:02] <aquarius> kk (which pieces specifically?)
[13:03] <CardinalFang> Er, if I knew that, I might not need any comment.  There are three, or two opaque numbers, yes?
[13:03] <aquarius> right, so you want to know what the consumer key and token and token secret and etc mean? gotcha
[13:04] <CardinalFang> Yes.   Morning, all!
[13:05] <thisfred> best dog toy ever: ice cubes
[13:06] <aquarius> hey thisfred
[13:07] <aquarius> any word from jchris?
[13:07] <thisfred> aquarius: none: he wasn't online as far as I could tell yesterday, and on the mailing list nothing specific to our cause yet
[13:07] <thisfred> still going through
[13:18] <aquarius> kk
[14:24] <thisfred> aquarius: so, no mail from chris, and he's not on the channel now. jan____ is away, but we need to verify that this issue is treated with some sense of urgency, since you're blocked by it (correct?)
[14:25] <aquarius> correct
[14:27] <thisfred> ok, I don't know who on the #couchdb channel we can speak to about this, jason also isn't there. SteveA should we mail/call couch.io?
[14:27] <thisfred> rehi CardinalFang
[14:28] <aquarius> re CardinalFang. function to get oauth tokens now in a branch for approval
[14:29] <CardinalFang> Rgr.
[14:30]  * thisfred reviews as well
[14:43] <CardinalFang> aquarius, "oauth_token_secretsx" ?
[14:44] <aquarius> pants
[14:45] <thisfred> aquarius: your oldest branch, I'd like to review it, or is it obsolete by now?
[14:45] <aquarius> CardinalFang, fixed
[14:45] <aquarius> thisfred, which one?
[14:45] <thisfred> aquarius: if not, could you fix the conflict?
[14:45] <thisfred> aquarius:  lp:~sil/desktopcouch/create-oauth-tokens-startup
[14:46] <aquarius> kk, willfix the conflict
[14:46] <thisfred> awesome
[14:51] <thisfred> aquarius: also a conflict on your other branch(es) probably the same
[14:51] <aquarius> yeah, same one, I suspect
[14:51] <aquarius> I hate resolving conflicts
[14:52] <thisfred> the quickest way to resolve conflicts is not to generate them
[14:52] <aquarius> well, er, yeah :)
[14:52]  * thisfred runs away before aquarius rips off his arm and beats him over the head with it
[14:52] <aquarius> but that ship has sailed, I fear :)
[14:53]  * CardinalFang high-fives thisfred.
[14:53] <aquarius> aha, you two are in cahoots against me, are you? I see how it is
[14:54] <thisfred> aquarius: you're gonna hate me even more: the changes that are conflicting I have mostly undone on my latest branch...
[14:54] <thisfred> perhaps we should land that first
[14:54] <aquarius> land that first, I suggest
[14:55] <aquarius> since I am now confused by which bits need to happen where
[14:55] <thisfred> the conflicts will still exist but they'll be smaller
[14:56] <thisfred> I did a lot of hoop jumping to make the tests work, and then when the port was readable from the log, I had to unjump some
[14:56] <thisfred> or was able to, I should say
[14:59] <statik> me
[15:00] <CardinalFang> aquarius, outside that type, that branch looks good to me.
[15:02] <CardinalFang> MEETING BEGINS
[15:02] <CardinalFang> If you're here for the stand-up meeting, say "me".   Some reviews/merges.
[15:05] <statik> TODO: desktopcouch 0.3 release for feature freeze today. Nag urbanape and rodrigo about compat testing with couchdb-0.10
[15:05] <statik> BLCK: nope
[15:05] <statik> dobey, show us the way!
[15:05] <rodrigo_> me
[15:05] <dobey> ☭ DONE: Fixed overactive Fatal Error, Started prefs dialog
[15:05] <dobey> ☭ TODO: Finish prefs dialog, OAuth
[15:05] <dobey> ☭ BLCK: None.
[15:05] <dobey> teknico: bongiorno!
[15:05] <teknico> DONE: completed and landed a branch that improves the handling of login failures from our Funambol Server API code to the Funambol DS server, reviewed one more markgsaye's branch, fought with rabbitmq
[15:05] <teknico> TODO: working on the contacts CRUD web ui
[15:05] <teknico> BLOCKED: rabbitmq-server not starting anymore, but being solved
[15:05] <teknico> next: aquarius
[15:05] <aquarius> ⚀ DONE: various smallish desktopcouch branches
[15:05] <aquarius> ⚁ TODO: piston oauth in snowy; get DC0.3 done
[15:05] <aquarius> ⚂ BLOCKED:  couchdb patch which lets OAuth read users from the ini file doesn't seem to work
[15:05] <aquarius> In all the world there is only one rodrigo_
[15:05] <rodrigo_> • DONE: Submitted tomboy package with U1 as default sync server. Submitted branch to fix notes UI in production, and kept looking at it, because it's not clear it fixed it
[15:05] <rodrigo_> • TODO: Add more tests in couchdb-glib test suite. More openSUSE packaging. Add social services accounts config to about-me. Talk to Ara about writing mago tests for evo-couchdb. Propose couchdb-glib/evo-couchdb for GNOME 2.29. Store UUIDs for postal addresses. Conflict resolver tool in pair tool. oAuth authentication and signing of all couchdb-glib requests. Finish adding URLs to contact records in evo-couchdb. Add changes notificatio
[15:05] <rodrigo_> • BLOCKED: none
[15:05] <CardinalFang> DONE: Reviews yesterday. (But I'm on-call-reviewer *today*.  Dang.)  Replicator nearly finished.  Needs testing.
[15:05] <CardinalFang> TODO: Finish replicator.  Make pairing-tool exchange OAuth noise.  Also, grudgingly review today's branches and mark them all "Disapprove".
[15:05] <CardinalFang> BLOCKED: None
[15:05] <rodrigo_> nobody next, right?
[15:06] <rodrigo_> ah, missed CardinalFang :)
[15:06] <CardinalFang> teknico, How can we help?
[15:06] <dobey> he missed himself i think
[15:06] <teknico> CardinalFang, statik is valiantly taking care of the problem, thanks :-)
[15:07] <CardinalFang> Good man, statik.
[15:07] <CardinalFang> Okay, MEETING ENDS
[15:07] <teknico> dobey, e bonanotte ai sonatori ;-)
[15:08]  * CardinalFang is glad no one read his TODO.
[15:08] <dobey> bonanotte? little early for that, eh? :P
[15:08] <thisfred> you sleep with the fishes
[15:09] <aquarius> let's take it to the mattresses
[15:14] <urbanape> dangit
[15:14] <urbanape> DONE: Proposed an apparently broken branch for multi-downloads.
[15:14] <urbanape> TODO: Test bindwood against new CouchDB package.
[15:14] <urbanape> BLOCK: None
[15:14] <CardinalFang> urbanape, we sang arias of sadness at your absence from our meeting.
[15:16] <CardinalFang> aquarius, leave the oauth, take the canonical. So, oauth info is client-relative, not server-relative?  I get one set of credentials and use that single group of four values to talk to all paired hosts?
[15:16] <aquarius> no
[15:16] <aquarius> it's server-relative
[15:17] <aquarius> each server has its own set of keys
[15:17] <aquarius> think of the keys as being a multi-item password, basically
[15:18] <aquarius> so when you pair machine A with machine B, machine A needs to get its own keys (by calling the function), and then pass those keys to B (down the connection established by pairing).
[15:18] <aquarius> B then stores those keys in a paired-server document on B, with server: A
[15:19] <CardinalFang> aquarius, Right.  So  get_oauth_tokens()  is server end, for transmission at pair-time?  I store those somewhere and then retrieve them for a particular host at replication time.
[15:20] <aquarius> yes. Machine A calls get_oauth_tokens when another machine wants to pair with it, so it knows its own tokens and can give them to the other server
[15:20] <dobey> crap, i think i may have just lost DNS
[15:20] <dobey> sigh
[15:20] <dobey> my network is being really annoying
[15:20] <statik> CardinalFang, your TODO is why I offered to take reviews for you ;)
[15:20] <aquarius> the other server stores those tokens in a paired serve record, and then when the other server starts up replication, it reads the paired server record for A to know which tokens it needs to pass to A as part of the replication process
[15:21] <CardinalFang> statik, :)
[15:25] <statik> aquarius, thisfred: any news from couch.io on the oauth patch? If I merge lp:~sil/desktopcouch/not-so-random into desktopcouch and include it in a release today, will that break evolution-couchdb, bindwood, and quickly?
[15:26] <thisfred> statik: I see no one online that I know is couch.io to ask. Re: the breaking, I defer to aquarius' wisdom
[15:27] <aquarius> erm, let me check
[15:27] <aquarius> yes. It will break everything.
[15:28] <aquarius> Because it specifies that a valid user must be used for all access, and it is currently not possible to access couch as a valid oauth user if that user is specified in the ini file :(
[15:30] <CardinalFang> I think we need a flag-day when we change both at once.  We may need code that shuts down running couchdb servers in the preinst.
[15:33] <CardinalFang> aquarius, so, just to make sure, do we need python-couch package to take OAuth info as a key for instantiating client.Server objects, or does couchdb daemon read remote oauth stuff on-demand from its INI file?
[15:34] <CardinalFang> ^key^parameter
[15:34] <aquarius> CardinalFang, desktopcouch.records understands how to look up oauth tokens from the keyring to access the local desktopcouch, so you don't need to do anything
[15:34] <aquarius> if you use desktopcouch.records, that is
[15:35] <CardinalFang> Good, good.
[15:35] <aquarius> if you don't use dc.records, then you get to sign your requests yourself
[15:35] <aquarius> the stuff to make dc.records understand oauth and get the keys is lp:~sil/desktopcouch/dc-records-oauth
[15:47] <statik> aquarius, i wonder how much work it will be to make bindwood work with this oauth stuff
[15:55] <thisfred> brb dist-upgrade wants a reboot
[16:00] <aquarius> statik, there are already oauth libraries for JS
[16:00] <aquarius> bindwood will have to get the keys, of course, and do the signing itself (this is what happens when you don't use desktopcouch.records), but that's relatively easy.
[16:01] <aquarius> might need another shell-out-to-python to get the keys, thougth
[16:01] <statik> makes sense
[16:03] <statik> aquarius, should we ship a slightly modified version of your branch that doesn't turn oauth on, but makes it very easy to uncomment a line or something in order to enable oauth for testing? then we could do the changes needed in bindwood, evolution-couchdb, etc. in an orderly way, and finally flip the switch to turn on oauth
[16:03] <statik> i'm kinda worried about breaking the world with the next desktopcouch release, and how to coordinate the introduction of oauth
[16:07] <aquarius> We can do that, and I've been debating it in my head
[16:07] <aquarius> Question: is shipping DC0.3 without auth and then turning auth on (by uncommenting the line) after freeze a break of the freeze?
[16:10] <aquarius> statik, introducing oauth is essentially going to break the world for people who are not using dc.records. I can't think of a way around that.
[16:11] <aquarius> because they'll have to start authenticating when they were not before.
[16:12] <CardinalFang> Should we get 0.3 client out the door with trying auth, and then make 0.4 require auth?
[16:13] <statik> thats what i'm thinking
[16:13] <statik> 0.3 should let people integrate with auth
[16:13] <statik> and 0.4 should require it
[16:13] <CardinalFang> or, break things as soon as possible, since we may not be able to avoid breakage for people subverting us and doing it their onw way.
[16:14] <statik> since we are waiting on the revised COUCHDB-478 patch to even allow desktopcouch to work correctly with the OAuth, I don't see how we can require it just yet
[16:15] <statik> i'm all for getting the oauth code in so we can all be integrating with it
[16:20] <aquarius> the problem is..."integrating with auth" is hard if it's diabled
[16:20] <aquarius> disabled
[16:20] <aquarius> so I think that putting it out without auth being required is the same thing as there not being any auth at all
[16:21] <aquarius> hrm. I don't know what happens if you oauth-sign a request incorrectly when you didn't need to sign it at all
[16:22] <aquarius> and...your couch is visible on the network, and unauthenticated.
[16:22] <aquarius> which is Ungood
[16:22] <statik> aquarius, it's the same as there not being any auth at all for a normal user, but for a developer integrating they could tweak the local.ini to enable auth, right?
[16:23] <aquarius> they could, as long as that developer is prepared to break every app that talks to DC that they're not working on, like, say, bindwood
[16:24] <aquarius> statik, but I am beginning to think that it's a good idea to do what you're suggesting
[16:24] <aquarius> I did not think that having working oauth would take this long :(
[16:25] <thisfred> still none of the usual suspects online on #couchdb. I think jan____ is en route to Dublin
[16:26] <statik> aquarius, cool! i always wonder whether my ideas are crazy. when you start to agree with me, then I *know* they are. so, how should we do this? should I merge all your pending branches into desktopcouch, then you do one more to comment out the auth, then I release 0.3?
[16:27] <statik> CardinalFang, do you have an in-progress branch that needs to go into desktopcouch 0.3?
[16:27] <aquarius> disabling oauth means two things: comment out one line in the ini file, and then tell dc.records to not oauth-sign requests. I'm not even sure if we need to do the second
[16:27] <CardinalFang> statik, Yes!
[16:28] <aquarius> I have to go pick up my daughter and then have dinner with her and so on, so I'll be gone for about four hours, but then I'll be back.
[16:28] <CardinalFang> aquarius, Can we make records try without oauth on failure?
[16:28] <aquarius> CardinalFang, could do, but I'd be inclined to not do that
[16:28] <aquarius> since that's extra code we write now and then remove in 0.4
[16:30] <statik> aquarius, i hope we don't need to do the second
[16:31] <statik> if i send an oauth-signed request to something that doesn't require oauth, i would hope it just ignores the extra header
[16:31] <aquarius> I think that's what happens. I think.
[16:31] <joshuahoover> jblount, urbanape: either of you ever see an error in the web ui that says something along these lines: "this file is already being created by somebody else"
[16:31] <statik> cool, we have a plan. could thisfred do the branch to comment out the ini file so you don't have to work so late tonight aquarius?
[16:33] <thisfred> aquarius: could start on that right now, so I can ask you if I run into unforeseens...
[16:33] <thisfred> when you get back
[16:34] <aquarius> yes
[16:34] <thisfred> ok, starting on that
[16:34] <aquarius> I think that all you should need to do is remove the [couch_httpd_auth] require_valid_user = true part from create_ini_file
[16:34] <aquarius> but I have not tested this.
[16:35] <aquarius> that way there will still be an admin account and so on
[16:35] <aquarius> this will, I should note, not affect people who already *have* an ini file with that in
[16:35] <aquarius> but I think it's reasonable to get those people to delete the ini file
[16:35] <thisfred> excellent, I' try, test and deliver
[16:37] <statik> joshuahoover, you can ask gafton about that, i bet its from a stale upload reservation in the updown server
[16:38] <aquarius> right, off to get Niamh from second day of dance school :)
[16:38] <aquarius> bbl
[16:38] <joshuahoover> statik: thanks...just found a previous bug with the same issue
[16:52]  * statik runs tarmac-lander on desktopcouch
[16:54]  * dobey runs to get lunch
[16:58] <thisfred> aquarius: (running commentary, ignore until you're back) [admins] section *does* need to go in addition to require_valid_user, or we get the 401s. with those two sections commented out, the tests all run. Now merging all open branches into this to see if it doesn't break anything else.
[17:04] <thisfred> done
[17:08] <thisfred> prop0wzed
[18:20] <urbanape> pfibiger, https://code.launchpad.net/~urbanape/ubunet/tooltips-for-long-filenames/+merge/10674
[18:22] <statik> hi thisfred, i've got a conflict when trying to merge lp:~sil/desktopcouch/not-so-random
[18:23] <statik> thisfred, should I just merge your noauth branch instead, and that will pull in the others?
[18:24] <urbanape> statik, I updated my system (including CouchDB) and Bindwood still seems to run okay. I get no errors messages in my JS console (well, not about connecting to Couch, anyway)
[18:25] <statik> urbanape, fantastic! desktopcouch 0.3 will have optional oauth, and then later on we'll make it mandatory. that should give you a window to fix bindwood to support oauth
[18:28] <thisfred> statik: exactly
[18:28] <urbanape> I saw that exchange earlier
[18:29] <thisfred> statik: I merged them all into mine and resolved the conflicts
[18:29] <statik> thisfred, that is the best news i have gotten all day!
[18:29] <thisfred> the conflicts are on all 3 of aquarius' branches
[18:29] <statik> urbanape, thanks for testing bindwood and for the tooltips!
[19:06] <statik> thisfred, i'm pushing a 1-line branch now that fixes a problem with writing the bookmark file
[19:07] <statik> lp:~statik/desktopcouch/fix-bookmark
[19:07] <thisfred> statik: will review and then I have to go pick up my stuffs
[19:07] <statik> thisfred, awesome. hope all your stuff arrived safely!
[19:08] <thisfred> there's nothing fragile or very expensive in there. If the CDs are ok, I'm ok :)
[19:10] <thisfred> statik the tests pass but there's no proposal to +1 or is there?
[19:10] <statik> thisfred, i'm just proposing it now, one sec i'll paste the link
[19:13] <statik> https://code.edge.launchpad.net/~statik/desktopcouch/fix-bookmark/+merge/10677
[19:16] <Mandrew> hello how to ad files to the ubuntuone folder
[19:18] <thisfred> statik: I approved and approved
[19:19] <statik> ta
[19:21] <Mandrew> know one knows how to ad folders to ubuntuone?
[19:21] <dobey> Mandrew: on the desktop?
[19:21] <Mandrew> on the computer
[19:22] <dobey> right, but with the local desktop client, or via the web browser?
[19:22] <Mandrew> i didnt find any awnsers in the faq
[19:22] <Mandrew> on the desktop
[19:22] <dobey> locally you just put new folders in ~/Ubuntu One/My Files (though soon that will just be ~/Ubuntu One)
[19:23] <Mandrew> i tried to drag n drop into the ubuntuone folder it dint like that :)
[19:24] <dobey> you need to put it in "~/Ubuntu One/My Files" currently
[19:24] <thisfred> gotta go, be back in a couple hours
[19:24] <Mandrew> thanks m8 you solved my probz
[19:25] <Mandrew> Dobey yr d man
[19:40] <urbanape> apropos my somewhat stalled multi-download branch: do we preserve permissions on files in U1?
[19:44] <Mandrew> is there anyone that knows if there is possible to get a email adress that look like this<EMAIL_ADDRESS>or some like it?
[19:44] <statik> urbanape, i don't think we touch permissions
[19:45] <statik> Mandrew, email addresses like that are available for Ubuntu members or developers
[19:46] <Mandrew> can i become a member or how does that work?
[19:48] <statik> Mandrew, absolutely you can. membership is available to anyone who makes a significant and sustained contribution to the ubuntu community. You can contribute in any number of ways. There is a lot more information available here: https://wiki.ubuntu.com/Membership
[19:48] <statik> one good way to become a member is by working with the nearest LOCO team
[19:48] <Mandrew> nice work ill check it out
[19:49] <Mandrew> loco team?
[19:49] <statik> it's the name for local community teams of ubuntu advocates
[19:49] <statik> they do all kinds of different work, from training to marketing to programming to answering questions in the forums
[19:49] <Mandrew> is there one here in sweden?
[19:51] <statik> yes. https://wiki.ubuntu.com/LoCoTeamList
[19:52] <Mandrew> man your the greatest thanks alot m8
[19:52] <statik> happy to help, good luck with ubuntu
[19:53] <urbanape> statik, how do we not handle permissions? What happens on a second machine or on a shared machine? Do we stamp files with some default permission?
[19:53] <Mandrew> im new to ubuntu and linux but i just love it the concept with it
[19:54] <statik> urbanape, maybe i gave a wrong answer...chipaca or verterok or mentalguy would know for sure
[19:55] <verterok> urbanape: we don't handle permissions :)
[19:58] <statik> urbanape, dunno if you saw my comments in the other channel about zipstream - i can help get that set up as a 3rd party sourcedep if you want
[20:01] <urbanape> statik, we're not using the bare ZipStream.
[20:02] <urbanape> I had to munge it a lot
[20:02] <urbanape> there's probably room for a generalized solution that we can contribute back. I'd be happy to work on that.
[20:02] <statik> ah, even more fun. so we still need to maintain it as a separate lib, and send those patches back to spideroak
[20:02] <urbanape> yes
[20:03] <urbanape> okay, that's no problem.
[20:03] <urbanape> What I'll do then is to extract the bits that deal with the file selection (via the checkbox) and propose that separately.
[20:03] <urbanape> I think it'd be nice to get the zipstream stuff generalized and contributed back.
[20:03] <urbanape> and let someone else maintain it.
[20:04] <jblount> urbanape: In case I was clear when I was looking at it, I pretty much want to make babies with that branch. It makes me _very_ happy.
[20:04] <urbanape> yeah, I was silly not to have actually tried to open the resulting files.
[20:04] <urbanape> I just saw that the proper files were in the zip archive and were non-zero length.
[20:04] <jblount> urbanape: :), that's what dumb reviewers (like me) are for!
[20:04] <urbanape> but yeah, gibberish.
[20:07]  * jblount goes back to long meetings with limited breaks
[20:12]  * CardinalFang yells at twisted/dbus and its main-loop madness.
[20:30]  * aquarius returns
[20:32] <aquarius> ...to discover that all his branches have been rejected. Nobody loves me.
[20:32] <aquarius> :)
[20:33] <aquarius> statik, so...what remains to be done for DC0.3 now?
[20:33] <statik> aquarius, rejected and merged via thisfreds branch where he fixed up the conflicts
[20:33] <statik> dvcs ftw
[20:33] <statik> aquarius, i think we need a branch from CardinalFang, then we do the release
[20:33] <aquarius> yep. he's a lovely Dutch hero, yes he is
[20:33] <aquarius> omg it's done?
[20:34]  * aquarius breathes a mighty sigh of relief
[20:34] <statik> aquarius, don't take my word for it
[20:34] <statik> thisfred did the branch we talked about before you left
[20:34]  * aquarius grins
[20:34] <dobey> aquarius: you decided on "Gangsta Rap Made Me Do It"?
[20:34] <statik> and CardinalFang says hes working on something mysterious, it's connecting to my machine
[20:34] <aquarius> CardinalFang, how are you getting on with stuff? Need any help?
[20:34] <aquarius> dobey, Cop Killer. :)
[20:35] <dobey> aquarius: do you have to sing also?
[20:35] <statik> and the syncdaemon team is making AMAZING progress, with bandwidth throttling and resumable uploads and downloads
[20:35] <aquarius> dobey, I do not. I wouldn't want to embarrass all those professional singers at stage school by being way better than them
[20:36] <statik> and dobey is making a ui that everyone will love
[20:36] <aquarius> blimey, we're gonna rock harder than Ayers Rock for karmic. Coolness.
[20:36] <dobey> aquarius: oh. you totally should have picked "Still Alive" then
[20:36] <dobey> aquarius: the credits song for Portal
[20:37] <aquarius> one of the reasons that I'm looking forward to being out of crunch for the freeze is that I might get a chance to play Portal ;)
[20:38] <dobey> heh
[20:38] <aquarius> although I don't thin kthere's a wii port :(
[20:39] <dobey> doesn't look like it
[20:39] <dobey> but you can buy it on steam and play under wine
[20:40] <aquarius> plays under wine? nice.
[20:41] <dobey> i believe so
[20:41] <dobey> i have it on 360, so i can't confirm yet
[20:42] <dobey> however, i have been tempted to buy the awesome deal that valve had for all their games on steam
[20:42] <dobey> which is to say "every valve game, ever made, all for $100"
[20:44] <dobey> i think it was $100
[20:44] <dobey> whatever it was, it was a great deal
[20:44] <aquarius> that's pretty cheap
[20:44] <dobey> yeah
[20:44] <dobey> considering L4D is still like $50 in the box
[20:44] <aquarius> although when I (infrequently) play games it's on the wii; that's why I bought a wii :)
[20:45] <dobey> i bought a wii for the cool toys
[20:45] <dobey> (wii fit)
[20:47] <CardinalFang> aquarius, It's going.  Struggling with DBus weirdness.
[20:48] <aquarius> I'm happy to chip in if you'd like me to, elsewise I shall log off for the night
[20:49] <CardinalFang> aquarius, I think just trying will take less time than synching with you would.  Thanks though.
[20:50] <CardinalFang> aquarius, G'night.
[20:50] <aquarius> no worries :)
[20:50] <aquarius> I cherish my status as an impediment to progress ;)
[20:50] <aquarius> if you don't manage to finish (thisfred, statik, this applies to you too) drop me a mail with anything you'd like me to pick up on in the morning
[20:52] <CardinalFang> Rgr.
[21:05] <dobey> grr, gtk+
[21:07] <dobey> joshuahoover: btw, the applet no longer has the --signup/-s option. passing it is harmless, but it's not necessary :)
[21:08] <joshuahoover> dobey: ah, thanks :)
[21:11] <joshuahoover> dobey: is there an issue with the client crashing on startup?
[21:11] <joshuahoover> dobey: i'm seeing quite a few of those being filed within the past 5 days now
[21:12] <dobey> yes and no
[21:13] <dobey> joshuahoover: some of them are fixed by the branch i landed this morning
[21:13] <joshuahoover> dobey: very good...is there something i should look for in the logs that will tell me/clue me in that it's the same issue you fixed?
[21:13] <dobey> joshuahoover: others have python traces from syncdaemon, which seem to be the cause of failure
[21:14] <dobey> joshuahoover: if it doesn't have the syncdaemon-exceptions.log, it's probably just the fact that syncdaemon is being slow at start-up, and would be "fixed" by my branch from this morning
[21:14] <dobey> but that isn't in the nightlies/beta yet
[21:15] <dobey> and that bug is #414635
[21:15] <joshuahoover> dobey: good, i'll use that as the one to link others to
[21:31] <joshuahoover> dobey: i'm seeing quite a few that have this as the last line in their syncdaemon-exceptions.log: State START_CONNECTING can't handle the SYS_SET_CAPABILITIES_ERROR event ...you think this is unrelated to the bug you submitted a fix for?
[21:32] <dobey> it is a separate issue
[21:32] <dobey> pick one, mark the others a duplicate of it, and assign it to chipaca :)
[21:34]  * Chipaca hugs dobey
[21:34]  * Chipaca embraces dobey, even
[21:34]  * Chipaca extends dobey
[21:34] <Chipaca> et cetera
[21:35] <dobey> heh
[21:36] <joshuahoover> dobey: heh...got ya...thanks!
[21:36] <dobey> https://updown.ubuntuone.com/5d6e8680-5da0-4aff-9330-42caa0399a85
[21:39] <statik> dobey, i LOVE it! ship it
[21:43] <dobey> sigh
[21:43] <dobey> well now i have to hook it up
[21:49] <thisfred> and we're back, with 24 boxes of crap in the otherwise empty living room! :)
[21:54] <verterok> dobey: ping
[21:54] <dobey> verterok: hi
[21:54] <verterok> dobey: hi
[21:55] <verterok> dobey: I'm finishing the dbus api for bandwidth throttling, and re-realized that dbus don't support dict with multiple types :/
[21:56] <verterok> dobey: I was trying to  return a int as the value, to make your life easier
[21:57] <dobey> well, it supports {sv} no?
[21:57] <Chipaca> yeah, a{sv} works
[21:57] <dobey> using a variant for the value?
[21:57] <dobey> (although that is annoying
[21:57] <verterok> dobey: yes, but v don't support NoneType :p
[21:58] <verterok> dobey: so, what do you think of not including the key:value when it's disabled (None)?
[21:58] <dobey> verterok: what about a separate set of methods for enabled/disabled?
[21:59] <dobey> verterok: or returning a negative value for disabled?
[21:59] <verterok> dobey: whatever that makes you and the UX team happy :)
[22:00] <verterok> dobey: using perl isn't an option ;)
[22:01] <dobey> i wouldn't say perl
[22:02] <dobey> and we don't have time to rewrite in C
[22:02] <verterok> dobey: so: {download_limit:<int>, upload_limit=<int>}, with int: -1:off, 0-n: on?
[22:03] <dobey> ok
[22:04] <dobey> verterok: hrmm, though separate enable/disable might be better
[22:04] <verterok> dobey: what are we going to do with 0, that would just stop using the network :/
[22:04] <dobey> verterok: not use the network. it's the correct behavior :)
[22:04] <verterok> dobey: ok, that was the output of get_updown_limit (or something)
[22:05] <dobey> verterok: right, but as preferences, it would be nice if i set it, and those settings were saved, independent of me enable/disable the feature
[22:05] <dobey> verterok: i presume these settings are getting stored in ~/.config/ubuntuone/syncdaemon.conf ?
[22:06] <verterok> dobey: no
[22:06] <verterok> dobey: there is no work on syncdaemon side, I'm just starting
[22:06] <dobey> s/are/will be/ then :)
[22:06] <verterok> dobey: also, syncdaemon don't have persistent mechanism for preferences :O
[22:07] <dobey> verterok: you don't have configglue.write()?
[22:07] <verterok> dobey: we don't have the plumbing to do that
[22:07] <dobey> verterok: so i have to keep track of the settings, and hope syncdaemon doesn't get started without the applet?
[22:09]  * dobey doesn't like where this is going :(
[22:09] <dobey> and it's already 5 pm :-/
[22:10] <verterok> dobey: good point
[22:11] <verterok> dobey: I don't think the applet should track syncdaemon settings, as you pointed out, that will be a mess if SD is restarted
[22:12] <dobey> i wasn't even thinking about it restarting out from under the applet, but yeah, that's even worse :)
[22:12] <dobey> "I set it to use 128K/s, but now it's using 2M/s"
[22:12] <dobey> fun!
[22:13] <verterok> dobey: yes, a *lot* of fun
[22:16] <verterok> dobey: btw, configglue don't have a configglie.write method :(
[22:17] <dobey> configglue doesn't have any way to save settings?
[22:17] <dobey> sounds like it needs more glue
[22:17] <verterok> dobey: no, or at least I can't find it
[22:19] <dobey> :-/
[22:20] <dobey> does it give you a ConfigParser object?
[22:20] <verterok> dobey: no, an OptionParsr one :(
[22:20] <dobey> :/
[22:21] <verterok> dobey: exactly
[22:21] <dobey> can you create a ConfigParser and just cache the throttling settings?
[22:22] <verterok> dobey: also, we shouln't store all the options configglue load at startup, as some are CLI options
[22:22] <dobey> right
[22:22] <verterok> dobey: ok, let's file a bug about this, looks like it wants it's own branch
[22:22] <verterok> dobey: IMO syncdaemon should support this
[22:23] <dobey> it kind of has to
[22:23] <verterok> so, let's keep with what we'r doing now, it's bug not a feature...right ;)
[22:23] <dobey> otherwise the throttling config is entirely useless :)
[22:24] <dobey> "doesn't save my settings" is a pretty big bug, yeah :)
[22:25] <verterok> dobey: :)
[22:26] <verterok> dobey: I'm filling the bug ATM
[22:26] <dobey> great
[22:29] <verterok> dobey: bug #418882
[22:30] <dobey> hooray
[22:30]  * dobey waits for the conspiracy theory stories
[22:31] <verterok> dobey: ?
[22:32] <dobey> verterok: about how we had a bug about settings not being saved, before we had a release with settings :P
[22:35] <verterok> dobey: heh
[22:35] <dobey> statik: https://code.edge.launchpad.net/~dobey/ubuntuone-client/config-preferences/+merge/10699 <- feel free to approve :)
[22:36] <verterok> dobey: we can blame beuno :p
[22:36]  * dobey totally blames the design team
[22:37] <verterok> heh
[22:38]  * dobey wonders how long it will take to redraw 1000 frames in SVG


[18:20] <qense> I updated an old blog post and now it's showing up on Planet Ubuntu. Is there a way to get it off?
[18:24] <jpds> No.
[18:30] <qense> that's a shame
[18:30] <qense> How long has this bug been around?
[18:36] <jpds> Since, forever?
[18:37] <qense> probably


[05:35] <cpaelzer> ahasenack: only saw this now, already answered on #server
[08:02] <cpaelzer> slangasek: the bump to bridge-utils 1.5.9ubuntu2 to 1.5.15ubuntu1 https://launchpad.net/ubuntu/+source/bridge-utils
[08:02] <cpaelzer> slangasek: made it having Conflicts: ifupdown (<< 0.8.17)
[08:02] <cpaelzer> but that is https://launchpad.net/ubuntu/+source/ifupdown not available in Ubuntu
[08:03] <cpaelzer> just relaized that this on a dist-upgrade made me having
[08:03] <cpaelzer> The following packages will be REMOVED:
[08:03] <cpaelzer>    ifenslave ifupdown
[08:03] <cpaelzer> so it effectively became mutually exclusive until ifupdown is updated as well
[08:03] <cpaelzer> slangasek: Intentional (I don't think so) or is a new ifupdown already being made?
[08:08] <cpaelzer> xnox: ^^ as your TZ is much closer, if you know some team-plans on this let me know
[12:06] <rbasak> bdmurray: could you glance at bug 1623125 please/ What are your SRU verification expectations there for Artful?
[12:21] <ahasenack> Laney: hi, do you have the secret sauce somewhere that preps ppc64 images for autopkgtest? I'm hitting https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1630909
[12:22] <ahasenack> or it "just works" with the ppc cloud images we have?
[12:28] <Laney> ahasenack: I don't know that anyone has ever tried it with qemu like that
[12:28] <Laney> We boot a cloud image and then do things to it over SSH
[12:28] <ahasenack> Laney: how does it get console access in the cloud case? ssh?
[12:28] <ahasenack> ah
[12:30] <xnox> ahasenack, to be honest, i believe locally we should stop using -- qemu provider too; and instead use ssh setup as well.
[12:30] <xnox> ahasenack, and like use $ multipass launch bionic; and use multipass shell into it.
[12:30] <Laney> that'd be good, SSH setup scripts all over
[12:31] <xnox> or lxd, but again with ssh.
[12:31] <xnox> or uvt-launch thing, again with ssh.
[12:31] <ahasenack> Laney: xnox: I'll try ssh
[12:32] <ahasenack> that might be better also because it's how migrations use it, and the bug I'm trying to reproduce is happening only there so far
[12:40]  * rbasak looks forward to xnox writing an openssh dep8 test :-)
[12:41] <cjwatson> there is one already?
[12:41] <xnox> http://autopkgtest.ubuntu.com/packages/openssh ?
[12:41] <rbasak> I mean in terms of using ssh to get to autopkgtest hosts as above.
[12:41] <rbasak> Will that not interfere?
[12:41] <xnox> you know you can start a second server....
[12:42] <xnox> plus we have cloud image testing framework which tests that "ssh comes up" and "is available on default ports" with the "right keys" every day, on all releases =)
[12:42] <cjwatson> openssh's regression tests start a server on a high port
[12:42] <rbasak> My point is that you have to special case handling for that in the test because of the test environment, which is ugly, and probably the reason pitti did it via qemu where possible in the first place.
[12:42] <xnox> that was not the reason at all.
[12:43] <cjwatson> they won't care about sshd running on the host
[12:43] <rbasak> cjwatson: a openssh dep8 test might reasonably want to check that installing openssh-server results in a listening daemon on the default port.
[12:43] <xnox> at first tests were in schroot; then in lxd/lxc containers; then qemu - to break testbed, which became inflexible and unreliable; then started to use the cloud - because that gives one a "machine" more reliably.
[12:44] <cjwatson> rbasak: I think you need a better example, because as the openssh maintainer I'm not going to do that precisely because it would be bloody awkward :)
[12:45] <rbasak> Sorry. I didn't mean to suggest that xnox's suggestion was necessarily bad. Just that it results in some reasonable-to-write tests being awkward to write!
[12:46] <xnox> rbasak, it doesn't, and at the end of the day the cloud test bed is a lot better than the qemu provider one.
[12:46] <rbasak> It really depends on what you're trying to test.
[12:47] <cjwatson> that sort of thing would be awkward for other reasons - it's often useful to be able to debug autopkgtests in ad-hoc environments, where in practice sshd is very often running
[12:47] <xnox> rbasak, and specifically, src:systemd tests used to pass in qemu runner; but not over ssh; due to logind killing and closing ssh connections prematurely due to to systemd regression =/
[12:47] <cjwatson> so this is already a thing that in practice one wants to avoid
[12:47] <xnox> that was not at all fun to chase down.
[12:47] <rbasak> That's the sort of thing I mean.
[12:47] <rbasak> In those cases, the qemu running is clearly better.
[12:47] <rbasak> runner
[12:47] <xnox> that's not what we can use in production
[12:48] <cjwatson> if I were writing a "does installing openssh-server start the server usefully" test then I'd nobble the port.
[12:48] <cjwatson> it's just not pragmatic otherwise.
[12:48] <rbasak> The more infrastructure there is in the guest for the sake of the test execution environment, the less we can effectively test the low level stuff.
[12:49] <rbasak> I'm just saying there's a downside to using cloud images for autopkgtest.
[12:49] <rbasak> Not that we shouldn't do it that way in general.
[12:49] <cjwatson> I think in practice this is already a downside that tests have to assume is a possibility.
[12:49] <rbasak> I'm not sure if it's worth the effort, but a dep8 Restriction to say "really I need qemu" might be reasonable.
[12:50] <rbasak> (well, not "no qemu" specifically, but "as pure an environment as possible")
[12:50] <rbasak> (well, not "qemu" specifically, but "as pure an environment as possible")
[12:50] <xnox> we used to run tests on phones and tablets, bare metal, with provisioning over ADT
[12:51] <xnox> i beleive there is a MAAS runner too (or maybe I am imagining things)
[12:51] <xnox> in practice, we do not have infrastructure to run tests on smaller guest assist than we currently do.
[12:53] <xnox> it's not just the console access; we also need ability to transfer files in and out of an instance, to collect artefacts and push files onto it.
[12:54] <xnox> using serial tty + an assistance VM to mount the disk on, could be a cloud solution, but that would increase our quota usage per test.
[12:54] <xnox> rbasak, there have been suggestions to use lxd containers runner for !isolation-machine tests, because it's faster and most things do not need full thing (e.g. most of ruby/php/perl/python tests)
[12:55] <xnox> with lxd runner, you can have a lot less things running inside the guest, as one has direct filesystem access & out of bound shell
[13:01] <rbasak> Makes sense
[13:02] <rbasak> Assuming it works.
[13:02] <rbasak> The s390x environment change had quite a bit of fallout :-/
[13:03] <rbasak> Do we have any policy / extra thoughts on conffile changes in SRUs?
[13:04] <rbasak> bug 1661869 seems reasonable to me. The point of the SRU would be to change conffiles though.
[13:13] <xnox> rbasak, well, only in status. It used to be "SKIP" which britney interpreted as "PASS", and britney got all confused when "SKIP" -> "FAIL"
[13:13] <xnox> an oversight in britney to not account for "SKIP" state
[13:31] <mdeslaur> slangasek: mind if I merge python-django?
[13:34] <rbasak> sil2100: I'm looking at bug 1466926. I had some concerns and then read your comment that confirmed my thoughts. I'd appreciate your opinion given the responses to your comment.
[13:35] <rbasak> It seems to me that we should accept the SRU, but we need to take extra care. Do you agree, and any thoughts on what we could do to mitigate please?
[13:35] <rbasak> cpaelzer: FYI ^
[13:37] <rbasak> Any opinion on a wholesale update to 2.4.29 for example, if everything in http://www.apache.org/dist/httpd/CHANGES_2.4 sounds acceptable to SRU?
[13:38] <rbasak> Would that reduce or increase the risk do you think?
[13:38]  * rbasak goes to get lunch
[13:54] <cpaelzer> rbasak: the feedback I read ont he bug so far seemed to answer the question sil2100 had - => yes it is important
[13:54] <cpaelzer> I haven't looked at all at doing a while minor release update
[13:55] <cpaelzer> I thought SRU-wise unless under MRE we prefer backporting the actual fix
[13:55] <cpaelzer> 2.4.18->2.4.29 sounds a lot (too much IMHO)
[13:58] <rbasak> cpaelzer: we don't have strictly have MREs any more, though we do use the same quality criteria as before. If the changes are all acceptable for an SRU and we are confident about the quality then we can do it.
[13:58] <rbasak> cpaelzer: I ask because for a more complex change, if there are interactions with the rest of the codebase we don't understand well, then we might be taking less risk taking all upstream changes, IYSWIM.
[13:58] <rbasak> cpaelzer: depends on how deeply we understand this diff.
[13:59] <rbasak> But yeah it's a trade-off against regressions caused by other changes.
[13:59] <rbasak> I wondered where how you ad sil2100 judge this.
[13:59] <rbasak> I wondered how you and sil2100 judge this.
[14:04] <rbasak> juliank: based on https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1750465/comments/10, are you suggesting I should hold on processing slangasek's SRU upload?
[14:05] <juliank> rbasak: I'm not sure what he did precisely, I only saw the bug messages.
[14:06] <rbasak> juliank: http://launchpadlibrarian.net/361447927/plymouth_0.9.2-3ubuntu17_0.9.2-3ubuntu18.diff.gz is his artful SRU upload.
[14:06] <juliank> That should be correct anyway.
[14:06] <juliank> And it probably fixes the bug even if we don't know the exact reason yet...
[14:07] <rbasak> OK. If you and slangasek both agree on what we should land, I'm happy :)
[14:07] <rbasak> I'll accept assuming all the other SRU bits look OK.
[14:09] <rbasak> Thank you for looking
[14:17] <sil2100> rbasak: well, I didn't judge anything, I mean this SRU just felt a bit risky considering the merits
[14:18] <sil2100> rbasak: to me this SRU was still undecided
[14:18] <sil2100> rbasak: but when I looked at it back then I was leaning more into the reject territory - although I didn't see the later comments yet
[14:20] <rbasak> sil2100: sure, I got that part. By "judge" I'm asking for your opinion now :)
[14:22] <mdeslaur> slangasek: too late
[14:30] <ahasenack> Laney: hi, I pushed another gvfs build to https://launchpad.net/~ahasenack/+archive/ubuntu/gvfs-test-fixes-1713098/+packages with the FORCE flag set, as suggested in the upstream bug
[14:33] <Laney> ahasenack: ok, is it published?
[14:34] <ahasenack> Laney: yes
[14:34] <Laney> cool
[14:34] <ahasenack> Laney: gvfs - 1.36.0-1ubuntu2~ppa1
[14:34] <Laney> you want 10 test runs on ppc64el or something?
[14:34] <ahasenack> that would be fine
[14:35] <Laney> going
[14:57] <slangasek> cpaelzer: sorry, I didn't notice the added conflicts.  I had not planned to merge newer ifupdown, but if there's a conflicts then we should probably look at doing so
[14:58] <slangasek> mdeslaur: no objections to merging python-django, did you find one that builds better than the one already in -proposed?
[14:58] <mdeslaur> slangasek: It did build, I think it was a python change that got reverted
[15:04] <rbasak> xnox: why is it worth making all dovecot users download new binaries just to fix the dep8 test?
[15:05] <Laney> ahasenack: https://paste.ubuntu.com/p/kNcRc4Dd3c/ looks like that worked, just one trash failure
[15:06] <ahasenack> Laney: we can't be sure, we never saw the failure from ppa tests, did we?
[15:07] <ahasenack> at least it didn't introduce a new error
[15:07] <Laney> there's no reason it would be any different
[15:07] <Laney> to the archive
[15:08] <ahasenack> it's the same build farm?
[15:09] <Laney> yes, it is an almost identical codepath except there's some extra stuff to set up the PPA
[15:09] <ahasenack> Laney: how about this control ppa then, it's gvfs unchanged: https://launchpad.net/~ahasenack/+archive/ubuntu/unchanged-gvfs
[15:09] <cpaelzer> ahasenack: that is probably the easiest one line way to get what you asked for slowing down the guest
[15:09] <cpaelzer> ahasenack: sudo cpulimit -l 50 -p $(ps aux | grep $(virsh dominfo b-test | awk '/^UUID:/ {print $2}') | grep -v grep | cut -f2 -d" ")
[15:09] <cpaelzer> b-test being the guest name
[15:09] <cpaelzer> ahasenack: I don't expect you want to slow I/O do you?
[15:09] <Laney> that PPA has a superseded version
[15:10] <Laney> we have enough results for gvfs anyway no?
[15:10] <cpaelzer> there is also libvirty way - but you run qemu directly right?
[15:10] <cpaelzer> you can take out the inner bulk with the pid of any qemu you run
[15:10] <ahasenack> Laney: yeah, it's the one from before your version bump. I can bump it to match the archive (minus ~ppaN)
[15:10] <ahasenack> cpaelzer: I'm using libvirt now (uvt-kvm)
[15:10] <cpaelzer> ah I see
[15:10] <cpaelzer> then just a sec
[15:10] <ahasenack> cpaelzer: didn't see anything about limits in virt-manager, my gui :)
[15:11] <ahasenack> Laney: as we are still experimenting, it would be super if we could see the failure from a ppa build, and then the lack of failures from a ppa build (which we do already)
[15:12] <sil2100> rbasak: ah! Then I misunderstood ;) I'll read up the rest and comment
[15:12] <Laney> ok, if you want
[15:12] <Laney> just trying to save some CO2 from the atmosphere
[15:12] <cpaelzer> ahasenack: read "blkiotune" for disk and "CPU Tuning" for cpu in https://libvirt.org/formatdomain.html
[15:13] <ahasenack> can you trigger it from that ppa, or the fact that it's older prevents that?
[15:13] <ahasenack> cpaelzer: ok, thx
[15:13] <ahasenack> the dep8 error was happening with that version as well
[15:14] <cpaelzer> ahasenack: or just use my cmdline above
[15:14] <cpaelzer> this is one of the cases (debuging and qucik and dirty) where it beats the complex lbivirt config
[15:14] <Laney> ahasenack: it needs to be newer
[15:14] <ahasenack> Laney: ok, I'll fix that
[15:15] <Laney> we could just run against the archive's gvfs
[15:15] <Laney> this is a bit of a waste of compute imo
[15:17] <slangasek> juliank: thanks for the follow-up comment on the apt+plymouth trigger mess... why do you say that base-files must be fully configured before bash is unpacked?  I don't see that in the dependencies (bash Depends: base-files, it doesn't Pre-Depends:), and I didn't see any logs that showed this
[15:17] <ahasenack> Laney: ok, would you be ok with uploading with that force patch then?
[15:17] <Laney> ahasenack: to the archive?
[15:18] <ahasenack> yeah
[15:18] <Laney> I think you should comment upstream
[15:18] <Laney> I thought it was only meant to be an experiment
[15:18] <Laney> but if he decides to commit that change then we can
[15:18] <juliank> slangasek: I don't say that, I say that apt configured base-files as can be seen in the log. But it probably put it into triggers-awaited state instead of installed, and plymouth-... into triggers-pending, since we configure with --no-triggers
[15:19] <slangasek> juliank: ok, I didn't see that in the logs I skimmed, sorry for overlooking
[15:19] <ahasenack> Laney: ok
[15:19] <slangasek> juliank: but yeah, triggers-awaited or something makes sense
[15:19] <ximion> doko: thank you for uploading LDC 1.8 to -proposed! I didn't dare to file a FFe for it, but having it is very beneficial
[15:19] <ximion> Please tell me if there is anything I can help with (the transition in Debian so far is flawless, only libundead needed a minor change)
[15:32] <jbicha> ximion: maybe you need to file a binnmu bug since ldc migrated to Testing without the rebuilds happening https://release.debian.org/transitions/html/auto-ldc.html
[15:33] <nacc> slangasek: for seeding ruby, if i seed ruby-full (which depends on ruby and ruby-dev), will it be sufficient? That seems to be the upstream ruby recommendation on Ubuntu, and then we'd "simply" need to promote ruby-defaults again?
[15:35] <ximion> jbicha: some packages got binNMUs... I am still not sure when I should ping the release team explicitly for a transition, sometimes they just do it automatically, and sometimes I need to file a bug
[15:35] <ximion> and explicit bug is nicer in this case, I guess (only 4 more packages need to be rebuilt though)
[15:36] <slangasek> nacc: you could also just seed ruby, which seems more correct semantically; and ruby-dev will be pulled in automatically by virtue of our rule that promotes associated -dev packages
[15:36] <slangasek> nacc: it depends on whether ruby-full is something you want to recommend users install
[15:36] <nacc> slangasek: i'm being asked specifically that ruby-full (which upstream docs) be in main (by rbasak, dpb)
[15:36] <nacc> slangasek: right
[15:36] <nacc> slangasek: i would prefer 'ruby' as well, as it makes more sense to me
[15:36] <jbicha> ximion: the only rebuilds that happened were because new uploads were done in Debian
[15:37] <jbicha> ximion: in this case a bug would help since it appears that the new "shared" naming allowed ldc to migrate to Testing when it normally wouldn't
[15:37] <ximion> jbicha: agreed, I'll file one later today
[15:38] <nacc> dpb1: do you want it under "Other" or should I make a new "Ruby" section? We have no other interpeters in supported-misc-servers or supported*server (which is a metaseed currently)
[15:38] <dpb1> nacc: +1 on ruby
[15:38] <ximion> although I guess what allowed LDC to migrate was britney's ignore-cruft setting - the LDC upload didn't make anything uninstallable with the old cruft still in the archive, so it migrated
[15:39] <dpb1> nacc: I don't think it matters on what section
[15:39] <nacc> dpb1: given they are all from the same source package, i don't think anyone is really going to notice which binary is actually in main, tbh
[15:39] <dpb1> ok
[15:40] <dpb1> the binary will "pull in" the source as supported, I take it
[15:40] <nacc> dpb1: the source will need to be in main for any of its binaries to be in main
[15:41] <dpb1> k
[15:41] <slangasek> the source is always pulled in via the binary.  so it's a question of which binary packages you want to represent as supported
[15:41] <nacc> slangasek: right
[15:41] <dpb1> I think ruby makes the most sense, no argument
[15:42] <nacc> dpb1: given that we might add more to this list, I'll add a section for Language Interpeters, ack?
[15:42] <dpb1> nacc: sounds good
[15:44] <nacc> dpb1: seed pushed
[16:12] <xnox> rbasak, because it is a regression versus release pocket, that a security upload introduced; which trips up all other pending-srus which are reverse-deps of dovecot; there is no better way then SRUing this, to insure that next upload (security or updates) will fix this issue
[16:12] <xnox> rbasak, it's not like there is a VCS for next-artful upload of dovecot, which ever that might be.
[16:19] <nacc> slangasek: urgh, LP: #1757344, segfault in 'frontend' -- that's debconf?
[16:21] <slangasek> nacc: it's debconf-ish.  the segfaulting frontend may not be debconf code itself
[16:21] <slangasek> (since debconf is pretty vanilla perl)
[16:22] <nacc> slangasek: yeah, that's what i thought
[16:22] <nacc> slangasek: i guess it could be the normal update-manager frontend?
[16:22] <nacc> slangasek: but, in this case, it's (presuambly) not a bug in php, but in that frontend?
[16:22] <slangasek> nacc: update-manager's frontend is the debconf gnome frontend.  But yeah, a frontend crash is unlikely to be php's fault
[16:23] <nacc> slangasek: alright, i'll add a task once i figure out what they were using
[16:36] <rbasak> xnox: VCS for next-artful upload> as an aside, I think we should have that kind of thing
[16:36] <rbasak> xnox: but I'm not happy impacting users for what is fundamentally a developer issue that doesn't impact users.
[16:41] <xnox> rbasak, e.g. even if we commit this to "-proposed" next time there is a CVE -security will not take it, they take -updates only, no?
[16:42] <xnox> rbasak, i think the right thing to do, is to upload this sru.
[16:42] <xnox> on the grand scheme of things it is miniscual to the kernel every three weeks.
[16:43] <xnox> rbasak, and it's been less than two weeks
[16:43] <xnox> rbasak, and it does show security team did not run autopkgtest of dovecot itself, before uploading security upload.
[16:45] <rbasak> I believe the security team generally look at -proposed and make a decision
[16:45] <rbasak> Sometimes I've seen them incorporate a verification-done upload to -proposed that hasn't finished aging, for example
[17:11] <bdmurray> andyrock: Are you still about?
[17:14] <andyrock> bdmurray: hey hey
[17:14] <andyrock> what's up?
[17:14] <bdmurray> andyrock: hey, I was you software-properties change got uploaded. One idea I might not have explained clearly was using distro-info so we don't need this line.
[17:14] <bdmurray> channel='edge', # Remove this once bionic is officialy supported.
[17:15] <bdmurray> Although what does "officially supported" mean? 18.04.1 or 18.04 or some other date?
[17:15] <andyrock> officially supported by "livepatch"
[17:15] <bdmurray> Okay so the last one!
[17:16] <andyrock> yeah livepatch devs told me that before release bionic should be supported in stable canonical-livepatch snap
[17:17] <andyrock> we can upload a small fix later
[17:17] <andyrock> should be a small one
[17:17] <andyrock> at least we can test it right now
[17:17] <bdmurray> Right, my hope was to avoid that as an SRU but it sounds like it may not be possible.
[17:18] <andyrock> yeah the problem is that it's not possible to query canonical-livepatch and ask "is this release supported?"
[17:18] <andyrock> we need to address this in the future
[17:19] <bdmurray> Okay, that's fine - just wanted to make sure it was considered.
[21:16] <mwhudson> xnox, cjwatson, cyphermox: are any of you awake and willing to talk to me about partition alignment requirements?
[21:16] <mwhudson> (for subiquity reasons)