[10:55] <bac> morning gmb
[10:55] <bac> hi frankban.  welcome back.  hope you had fun.
[10:56] <frankban> hi bac, thanks, and yes, the EuroPython was cool
[10:56] <gmb> Hi bac.
[10:57] <gmb> Also: hi frankban; I forgot you were back this morning.
[10:57] <bac> gmb: can we call you Graham Green(e) now?
[10:57] <gmb> Arf.
[10:57] <bac> buh dump dump
[10:57] <bac> though i do quite like his books
[10:57] <gmb> Ah.
[10:58] <gmb> So you mean the writer. good.
[10:58] <gmb>  There's a few of them :)
[10:58] <bac> ah, yes
[10:58] <bac> oh, i don't know the others
[10:58] <gmb> bac, Native American actor for a start.
[10:58] <gmb> Also a British comedian
[10:58] <bac> though i think i have tried to read 'brighton rock' about three times and never can finish
[11:11] <gmb> bac, frankban: Can one of you take a gander at https://code.launchpad.net/~gmb/lpsetup/death-to-doctests-in-subcommands/+merge/114393?
[11:22] <bac> gmb: you have a conflict in the MP
[11:22] <gmb> Crap.
[11:23] <gmb> Forgot to merge trunk.
[11:24] <bac> gmb: btw, i've claimed the review
[11:25] <bac> gmb: can you do a very quick review for me?  https://code.launchpad.net/~bac/lp-tarmac-configs/tarmac-approvers-list/+merge/114397
[11:25] <gmb> bac, Sure.
[11:25] <bac> gmb: please vote but do not approve the MP.  that way it will be self-testing
[11:25] <gmb> bac, Fixed conflicts and pushed.
[11:25] <gmb> bac, Okay.
[11:26] <bac> gmb: why not add the cleanup of the file in the setUp?
[11:27] <gmb> bac, Because not all the tests create the file. The cleanup will then error because the file doesn't exist.
[11:27] <bac> gmb: also, i think if you make one big mask by ORing together all of the expected file modes and then XOR with the actual file mode you can do the test in one go.
[11:28] <gmb> bac, Ah, good point. I'll try that.
[11:28] <bac> gmb: gotcha
[11:28] <gmb> bac, I've voted to Approve.
[11:29] <bac> gmb: also, the text conflict you just fixed may break your tests.  i removed the insertion of the trailing \n.  even if your tests don't break, you could remove the strip() and ensure the contents are the same.
[11:33] <gmb> Noted, thanks.
[12:08] <gary_poster> frankban, welcome back!
[12:08] <frankban> gary_poster: thanks, it's good to be back
[12:08] <gary_poster> bac benji frankban gmb, http://tinyurl.com/yellowsquad
[12:15] <gmb> https://tbe.taleo.net/NA3/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=501
[12:45] <gmb> Przemysław Pająk
[12:54] <gmb> gary_poster, https://tbe.taleo.net/NA3/ats/requisitions/RequisitionView.jsp?act=view&id=502&et=REQU&actionId=1.
[12:54] <gmb> I don't think you're on it as a hiring manager, though, so you might need to ping Alice.
[12:54] <gary_poster> Oh ok thanks gmb
[12:55]  * gmb -> lunch
[14:00] <bac> gary_poster: for testing purposes, would you vote 'Approve' on this MP that graham has already reviewed?  https://code.launchpad.net/~bac/lp-tarmac-configs/tarmac-approvers-list/+merge/114397
[14:00] <gary_poster> bac, done
[14:01] <bac> thanks
[14:25] <gary_poster> bac, dunno if you saw frankban's blessing for removing public and private key args to inithost.  I made a card.  Probably easy to do (or you could fold it into your current work, if that makes sense)
[14:25] <bac> great
[14:55] <frankban> gary_poster: have you found something about -s not returning a flat list?
[14:55] <gary_poster> frankban, no sorry, on calls
[14:56] <frankban> gary_poster: np
[15:32] <gary_poster> frankban, if, as a non-root user, you pass multiple steps to a command that must switch to root access, and it works, just move on.  I looked for the email and it didn't help.  What I just said is what I remember
[15:32] <frankban> gary_poster: ok cool
[15:41] <bac> hi frankban, if i add 'ignore-files=disabled*' to the lpsetup setup.cfg file then nosetest does not report the test failures and complains about distribute.  i've poked at it but cannot figure out why it is unhappy.  thoughts?
[15:46] <bac> were we all aware, where 'we' == 'us' - 'me', that the handler listing was order-dependent?
[15:51] <bac> hi benji, in the README.rst file for pocket-lint you specify sinzui's ppa.  it appears in the normal repos so is there any reason to require the ppa version, other than shininess?
[15:52] <benji> bac: it may be that in flailing about to find the right package name I got confused and believed that it was only in sinzui's ppa.  If it is available in the regular places, then that is fine too.
[15:52] <bac> cool
[15:52] <benji> We can delete the PPA bit or make that a sidebar ("If you want an ultra-fresh version of pocketlint, get it from...")
[16:06] <frankban> bac: same error here, if the goal is to ignore TestCase.disabled_* tests you can try to add to setup.cfg: exclude=handle_testing|disabled_ . Ignoring whole files is broken here too :-/
[16:06] <bac> frankban: i'd wanted to disable whole test files
[16:07] <bac> frankban: chmod +x works, but it is very easy to overlook
[16:16] <frankban> bac: interesting, it seems to work if you comment the line with-doctest=1 (in setup.cfg). Could you confirm?
[16:18] <bac> frankban: yes, it works for me the same way.  i note that passing --with-doctest on the command line causes the same problem
[16:19] <bac> in conjuction with ignore-files
[16:34] <bac> gary_poster: can you sanity check this diff for my unbreaking lpsetup branch?  http://pastebin.ubuntu.com/1086450/
[16:35] <gary_poster> bac, on call; looking
[16:41] <frankban> bac: that distribute error is not print by nose, it's present in distribute_setup.py#153
[16:42] <frankban> * not printed
[16:42] <bac> frankban: yes, but it is odd it is triggered dependent on the nose options
[16:47] <frankban> bac: it works for me if I add "where=lpsetup" to setup.cfg (or -w arg)
[16:51] <bac> frankban: that is odd
[16:51] <bac> thanks for looking into it
[16:53] <frankban> np, and I agree it's odd
[17:05] <gary_poster> bac, why did you remove sinzui's ppa?
[17:05] <gary_poster> I think it is still necessary
[17:05] <gary_poster> (remove from README)
[17:05] <bac> pocket-lint is in the precise repo, i'm pretty sure
[17:06] <gary_poster> bac, was not for me
[17:06] <gary_poster> maybe I installed it with wrong name or something
[17:06] <bac> Package: python-pocket-lint
[17:06] <bac> Versions:
[17:06] <bac> 0.5.30-0ubuntu1 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_precise_universe_binary-i386_Packages) (/var/lib/dpkg/status)
[17:07] <gary_poster> ok bac, dunno.  I just had to do this in the past few days.  no idea.
[17:07] <gary_poster> not worrying about it
[17:07]  * bac just trying to streamline
[17:08] <bac> gary_poster: i'm reverting my vm to the clean snapshot and will then try a install-lxc.
[17:08] <gary_poster> ok
[17:09] <bac> well, i have reverted but i'm not bringing my baseline vm up-to-date.  i think it was pre-release precise so i have lots of packages to install
[17:15] <gary_poster> bac, I have only skimmed so far (looks good) but Karyn tels me I have to take lunch and have a break, and she is right
[17:15] <gary_poster> I'll review and ping when I return of that's ok
[17:15] <gary_poster> if
[17:27] <bac> gary_poster: enjoy your lunch.  is it really 1:30?
[17:40] <benji> why did we move initialize_lxc into init-host?  that seems like an odd thing to want
[18:27] <gary_poster> bac, yeah, it was.  Been busy.  BTW, I am skeptical that it will accomplish anything, but you might want to look in on #launchpad-dev
[18:28] <gary_poster> benji, the biggest driver for that move is the data center.
[18:29] <bac> gary_poster: who was that masked man/woman?
[18:29] <gary_poster> benji, in the data center, the webops people will not have root in the lxc host
[18:30] <gary_poster> but they will (hopefully) have root in the container
[18:31] <benji> hmm, but "normal" people won't want that, right?  wouldn't that be better as a seperate subcommand?
[18:31] <gary_poster> Therefore, making init-host able to initialize the Launchpad "host" even when it is an LXC container gives them the maximum amount to share with us
[18:31] <gary_poster> beyond that, technically it is initializing the Launchpad host whenever it is an LXC container
[18:32] <gary_poster> benji, notice that it will only happen if it is running in LXC (call_initialize_lxc I think?)
[18:32] <benji> ah! that's different
[18:32] <gary_poster> And everyone should want it when their Launchpad host is an LXC container
[18:33] <gary_poster> bac, I dunno.  Laura mentioned that we were looking for juju help, on the basis of our "please help!" section in the blog
[18:33] <gary_poster> this person replied that they would help with juju
[18:33] <benji> oh, so there is some mechanism in the framework that constructs function names from step names and calls "call_initialize_lxc" and uses that to determine if the step should be called or not
[18:33] <gary_poster> At the least we applied indirect pressure to SpamapS ;-)
[18:34] <bac> benji: yep
[18:34] <gary_poster> if they exist
[18:34] <benji> that's... irritating <0.5 wink>
[18:35]  * benji hasn't enguaged in frational winkery in quite a while, it's refreshing
[18:37] <gary_poster> bac, I missed Bulgaria in my search :-P
[18:38] <gary_poster> sorry bac.  I meant gmb, ^^^
[18:38] <bac> gary_poster: i'm sure i should understand that
[18:38] <bac> oh
[18:38] <bac> maybe not
[18:38] <gary_poster> :-) it was re candidate search
[18:38] <bac> bulgaria might be a new country for us
[18:39] <bac> as will PR...sort of
[19:18] <gmb> gary_poster, Is the TL call still on the conference no., or is it a hangout these days?
[19:19] <gary_poster> gmb, hangout.  I'm the whatever it is today, so I'll include you in the ping with the url
[19:19] <gmb> Thankee.
[20:33] <gary_poster> bac, finally, to http://pastebin.ubuntu.com/1086450/ :
[20:34] <gary_poster> docstring in line 202 maybe should include note that the command is desired to go away?  Maybe?  Wdyt
[20:34] <bac> gary_poster: cool.  my testing revealed some problems.  re-doing
[20:34] <gary_poster> bac, oh ok
[20:34] <gary_poster> should I wait
[20:34] <bac> gary_poster: proper MP is up, if you're interested
[20:34] <gary_poster> sure bac
[20:34] <bac> no, they were trivial (but fatal)
[20:34] <gary_poster> ok cool
[20:34] <bac> cannot test install-lxc due to lp-setup in container from package issue
[20:35] <bac> i made a card for that
[20:36] <bac> gary_poster: https://code.launchpad.net/~bac/lpsetup/fix-inithost-install-lxc/+merge/114486
[20:37] <gary_poster> lp-setup in container from package: bac, right, thanks.  (There is a temporary work around fwiw, which involves running individual steps and installing the code manually inbetween starting the container and running all the commands in the container)
[20:38] <gary_poster> (and I have a hack in mind to make this work in the future)
[20:38] <bac> gary_poster: i'm doing the workaround
[20:38] <gary_poster> cool
[20:40] <bac> gary_poster: my tarmac branch didn't land b/c rockstar's tarmac was broken.  he's taking care of it now.
[20:41] <gary_poster> bac, heh, great
[20:41] <bac> yummy tarmac chow
[20:44] <gary_poster> bac, make_launchpad has install arg.  Does anyone ever not pass True to it?
[20:44] <gary_poster> AFAICT no
[20:44] <gary_poster> which suggests a cleanup :-)
[20:45] <gary_poster> Is there a compelling reason to separate setup_launchpad and make_launchpad?  unclear.  don't care a lot though.
[20:47] <gary_poster> As already mentioned, I think IWBNI finish-inithost had a docstring (and help text?) that indicated that it was slated for eventual removal
[20:49] <gary_poster> bac, install_lxc should not include inithost.SubCommand.initialize_lxc_step
[20:49] <gary_poster> that is run in the lxc container for this story, when we run setup_lxc (which calls inithost in the container)
[20:50] <bac> gary_poster: IWBNI?
[20:50] <gary_poster> it would be nice if
[20:50] <bac> oi
[20:51] <gary_poster> :-)
[20:51] <gary_poster> bac, otherwise looks good to me
[20:51] <bac> gary_poster: ok.  you noting that stuff in the MP?
[20:51] <gary_poster> bac, yes
[20:52] <bac> thanks for the suggestions
[20:52] <gary_poster> thank you!  Nice to have this working again
[20:55] <gary_poster> bac, review made
[20:55] <bac> gary_poster: wait, i think finish-init-host is hosed
[20:55] <gary_poster> bac, ok
[20:55] <gary_poster> bac, could it be inithost.SubCommand.initialize_lxc_step ?
[20:55] <bac> it is running locally, not in the container.  no one calls it in the container as far as i can tell
[20:55] <gary_poster> As I said, that shoud not be run
[20:55] <gary_poster> oh
[20:56] <gary_poster> yes, that needs to be run with ssh in the container.  Sorry for missing that.
[20:59] <bac> gary_poster: well it needs to run in the 'host', whether that is the container or your 'real' machine
[20:59] <gary_poster> bac, right.  for install-lxc, it needs to be run in the container, I mean
[21:00] <bac> gary_poster: right, but if you are running the steps manually you can't do it unless we add a wrapper
[21:00] <gary_poster> why bac?  I don't understand.  Woud quick call help?
[21:00] <gary_poster> l
[21:01] <bac> sure
[21:01] <gary_poster> bac, I'm in yellowsquad


[14:06] <RikMills> quick :)
[15:29] <Pricey> RikMills: Just think of all you could have gotten away with...
[15:30] <Pricey> RikMills: And instead, you decided only to call me such a filthy name.
[16:00] <teward> ^ i think that was abuse-of-command
[16:00] <teward> nevermind, just an ops call without any details :p
[16:04]  * dax grumbles about PM spammers
[16:05]  * teward gives dax some tea
[16:06]  * teward then disables PMs globally and solves that problem instantly
[16:07] <dax> i'd grumble about how i'm generally advised to not set umode +g on myself too, except these PM spammers seem to ignore freenode/staff/* cloaked users ;)
[16:07] <teward> dax: are these 'spammers' registered?
[16:07] <dax> (unless i've just been lucky so far)
[16:08] <teward> 'cause I just use +R and never get that spam lol
[16:08] <dax> teward: today's weren't, but recent ones have been, but i'm not sure if same person or different
[16:11] <teward> just disable PMs globally in the IRCd, it'll solve the problem xD
[16:11] <teward> *shot*
[16:29] <dax> lol. we set +R by default on connect during the worst of it a year or two ago. it did indeed mostly solve the problem ;)
[16:30] <RhinosF1> Dax, does Freenode have a shared channel pm only?
[16:30] <dax> RhinosF1: no
[16:31] <RhinosF1> Dax: k , I also use that on another network
[16:34] <teward> dax: forcing a blood sacrifice on every registration would also help to stem the problem of spammy regs
[16:34] <teward> :P
[16:34] <teward> just saying.
[21:15] <wxl> is ubot93 brokeded?
[21:18] <Unit193> No?
[21:18] <hggdh> broakered?
[21:19] <wxl> i just issued a factoid to which it didn't respond to in the channel but did in a msg
[21:20] <Unit193> Seems fine to me.
[21:31] <genii> Isn't that the default behaviour if other bots in the channel take precedence?
[21:31] <Unit193> It's what happens if you call too many things at once, or call the factoid twice in a short duration.


[06:35] <dpm> good morning all
[06:37] <popey> morning
[06:41] <svij> good morning!
[06:50] <dholbach> hey :)
[06:56] <dpm> hey all
[07:14] <davidcalle> Morning all and happy snappy-playpen day! o/
[13:30] <dpm> svij, I see you're up to asking the difficult questions on the snapcraft list :)
[13:31] <svij> dpm: sure
[13:32] <dpm> :)
[13:32] <svij> it's not like I should do something more important right now, rather than playing with snappy… :/
[13:36]  * dholbach goes to pick up his niece from kindergarten - bbiab
[13:48] <svij> sigh, I don't often write on to a mailinglist, but I kinda always get answers to me, rather than to the list. First a guy named "Mark Shuttleworth" and now anotheron /o\
[13:59] <Kilos> hehe
[13:59] <Kilos> tough life svij
[14:02] <dpm> jose, mhall119, ubuconla call?
[14:03] <svij> Kilos: yeah. ;)
[14:13] <dpm> jose, seems you're away, let us know when you want to talk and we can have a hangout then
[14:13] <CutsBothWays> #Ubuntu-onAir
[14:14] <CutsBothWays> Is anyone putting up a video link to get the showing going (I.e. a countdown timer) ?
[14:14] <CutsBothWays> I take it it's Alan Pope and mhall119 , today ?
[14:14] <CutsBothWays> BRB.
[14:16] <CutsBothWays> Huh, It's a heat-wave here !
[14:16] <CutsBothWays> Hello ? dpm ?
[14:16] <mhall119> hi CutsBothWays
[14:16] <mhall119> I don't know who's on today's Q&A
[14:16] <dpm> o/
[14:16] <CutsBothWays> the count-down timer ?
[14:17] <mhall119> actually, I don't think we're doign a Q&A today, as we're all doing the snappy-playpen live hackathon
[14:17] <CutsBothWays> Is that on the calendar - "postponed" , or didnm't yuou bother , again ?
[14:18] <mhall119> didn't remember, sorry :)
[14:18] <CutsBothWays> Your loosing members 'cos of these anti-trello project management failings.
[14:18] <CutsBothWays> but that's Ok.
[14:19] <dpm> yesterday we discussed doing a review of the playpen actually
[14:20] <CutsBothWays> is that on the calendar, dpm ?
[14:20] <popey> happy to do Q&A with mhall119 :)
[14:20] <CutsBothWays> i.e. Are you letting ppl/users/ viewers know ?
[14:20] <popey> yes, we get the message CutsBothWays
[14:20] <CutsBothWays> I don't.
[14:21] <popey> constantly needling us doesn't actually help
[14:21] <CutsBothWays> how can I help, (sometimes bad feedback is better than good feedback)?
[14:22] <dpm> CutsBothWays, we acknowledge the fact that we've not updated the calendar at times, but if you look at the number of videos in the youtube channel, that's been the exception. Constructive criticism is always helpful, but always in a respectful tone
[14:22] <CutsBothWays> it's just too hot to do anything with 'buntu atmo.
[14:22]  * CutsBothWays changes it's tone.
[14:24] <dpm> thanks :)
[14:24] <CutsBothWays> It's just like, the Fair-trade shops, when the decided to get on-line and out of the 'ghetto', having shops.
[14:24] <CutsBothWays> **they
[14:25] <CutsBothWays> But the don't update their customers/members, no ?
[14:25] <dpm> popey, are you up to doing a playpen review at the q&a today, then. mhall119 and I did it last week IIRC, but happy to join too
[14:25] <dpm> sorry, that was meant to be a question
[14:25] <dpm> can't type
[14:25] <jose> dpm, mhall119: hey, sorry guys, have time now?
[14:25] <jose> at least for a quick briefing
[14:25]  * CutsBothWays slides dpm a coffee.
[14:26] <popey> happy to do Q&A, had my head down so not sure I can summarise playpen as well as you :)
[14:26] <CutsBothWays> Is playpen like sand-boxing ?
[14:26] <dpm> thanks CutsBothWays :)
[14:27] <dpm> popey, would you mind setting up the hangout? Happy to join
[14:27] <popey> sure
[14:28] <dpm> or if anyone else wants to, also welcome :)
[14:28] <dpm> jose, wfm up until top of the hour, mhall119? ^
[14:29] <jose> \o/
[14:29] <mhall119> yeah, let's jump back in
[14:29] <dpm> ok, cool, see you at the same hangout :)
[14:30] <dpm> CutsBothWays, the Q&A will be a good opportunity to learn about it :)
[14:32] <popey> created, tweeted
[14:32] <popey> +'ed
[14:34] <dpm> thanks!
[14:36]  * popey mutes snappy notifications for a bit
[14:36] <CutsBothWays> Have put it on G+ ?
[14:36] <popey> 15:32 < popey> +'ed
[14:36] <popey> ^ yes
[14:38] <CutsBothWays> Ah right, sometimes your pronounication is too monosyllabic to a Tee. But I like it.
[14:38] <CutsBothWays> **pronuniciation
[14:39] <CutsBothWays> Ubuntu is about expression & enunciation !
[14:41] <CutsBothWays> [App Idea.] Enu_buntu - the expression of ubuntu ! The snappy App that allows enuniciation in Ubuntu ...
[14:43] <CutsBothWays> I'm getting too side-ways, I'm outta here ..
[17:28] <dpm> mhall119, it seems I'm having some connectivity issues, but it seems that d.u.c is down?
[17:28] <mhall119> dpm: there's a major outage in the datacenter atm
[17:29] <dpm> ok
[18:30] <jose> davidcalle: and looks like the package is on its way - thanks!


[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is bac.
[15:00] <bac> good morning
[15:00] <bac> me?
[15:00] <bac> anyone else?
[15:00] <salgado> me
[15:01] <bac> sinzui, danilos, gary_poster, flacoste, deryck, noodles775: ping
[15:01] <flacoste> me
[15:01] <gary_poster> yup me sorry
[15:01] <noodles775> me (sorry)
[15:01] <gary_poster> was here seconds before your good morning
[15:01] <gary_poster> will cal trops
[15:01] <gary_poster> call troops
[15:01] <sinzui> me
[15:01] <bac> EdwinGrubbs: ping
[15:02] <EdwinGrubbs> me
[15:02] <mars> me
[15:02] <leonardr> me
[15:02] <bac> gmb: ping...can you find your TL?
[15:02] <bac> hmm, no bug types around at all
[15:03] <gmb> me
[15:03] <adeuring> me
[15:03] <abentley> me
[15:04]  * noodles775 calls jelmer in (as he's started as a mentat).
[15:04] <bac> thanks noodles775
[15:04] <bac> [topic] agenda
[15:04] <MootBot> New Topic:  agenda
[15:04] <bac> * Roll call
[15:04] <bac>  * Agenda
[15:04] <bac>  * Outstanding actions
[15:04] <bac>  * Mentoring update
[15:04] <bac>  * New topics
[15:04] <bac>  * Peanut gallery
[15:05] <danilos> bac, hi, I have a call now (when have we changed the time of the meeting?)
[15:05] <bac> danilos: we changed a few weeks ago after discussion here
[15:05] <danilos> bac, I guess that was the week when I was sprinting then
[15:05] <bac> danilos: sorry if you didn't get updated
[15:05] <bac> danilos: can you make it next week?
[15:06] <bac> [topic]  Outstanding actions
[15:06] <MootBot> New Topic:   Outstanding actions
[15:06] <danilos> bac, no worries, we'll work something out (I might change the phone call time for next week)
[15:06] <bac> [topic] thumper/mwh to bring up issues with launchpadlib testing on ML.
[15:06] <MootBot> New Topic:  thumper/mwh to bring up issues with launchpadlib testing on ML.
[15:06] <bac> we we discussed the work leonardr did for automating launchpadlib tests, thumper and mwhudson had some concerns
[15:07] <bac> michael did bring it up on the list but as far as i could tell it was unresolved.
[15:07] <leonardr> well, i know there were concerns about automatically creating launchpadlib objects
[15:07] <bac> leonardr or gary_poster do you have any update on possible changes?
[15:07] <leonardr> i landed a branch that takes that out. you now have to create your own launchpadlib object
[15:08] <gary_poster> bac, leonardr addressed all concerns to my knowledge.  It is cooler and more flexible now
[15:08] <bac> leonardr: great
[15:08] <leonardr> there were also concerns about using the sampledata users, which i also addressed
[15:08] <leonardr> there's a helper function that will create an oauth access token for any user
[15:08] <leonardr> so you can create a dummy user and then give them an access token if you want
[15:08] <leonardr> i think that was it
[15:08] <bac> leonardr: is it easy to create an object for anonymous access?
[15:09] <leonardr> bac: i haven't tried it, but Launchpad.login_anonymously() should work in the pagetests just as it does in real life
[15:09] <bac> ok, good.
[15:10] <leonardr> one thing we could add to make things nicer is a url alias for 'the launchpad instance accessible to the testrunner'
[15:10] <leonardr> which is http://api.launchpad.dev/ (not https)
[15:10] <bac> what do we want to do going forward?  start requiring lplib tests for new API changes?  what about coverage for existing methods?
[15:10] <bac> i approved some API changes yesterday but didn't require a lplib test.  i think we should.
[15:11] <leonardr> bac, did you require a test at all?
[15:11] <bac> leonardr: the webservice test was updated to show the new field
[15:11] <bac> that was all
[15:11] <gary_poster> From Foundations' perspective, my main interest is in tests verifying that our critical clients work with the specified webservice version
[15:11] <leonardr> certainly if it's something that requires a test (and doesn't need to be tested by hacking HTTP requests) an lplib test is better than a webservice() test
[15:12] <leonardr> we thought of two ways to do what gary says, and i don't think we've decided on one (not that we have to go all one way or the other)
[15:12] <gary_poster> And from a general perspective, I'm a string +1 on using launchpadib directly now that we have it.  Leonard wrote one (yesterday) that caught a problem that would not have been otherwise caught.
[15:12] <gary_poster> argh
[15:12] <gary_poster> strong
[15:13] <leonardr> the first way is to write a launchpadlib test every time we make a change in (eg.) 2.0 that doesn't bleed through to earlier versions
[15:13] <leonardr> make sure that 1.0 still has the old behavior, and 2.0 has the new
[15:13] <leonardr> the other way is to get our critical clients to expose their launchpadlib test suites, and run them as part of the launchpadlib test suite
[15:14] <leonardr> the apport developers are working on this now. if we run apport's launchpadlib tests as part of launchpad's tests (just as we run launchpadlib's launchpadlib tests) we'll know when we make a change that breaks apport
[15:14] <abentley> I think the second way more directly supports gary_poster's interest.
[15:15] <bac> leonardr: that effort is great and something i assume foundations will pursue.  but as reviewers we need to decide how to handle testing of changes to API functionality.  it sounds like you're in favor of using lplib tests over the older web service tests.
[15:15] <leonardr> bac: yes, unless you're writing a test that needs to send a specific http request
[15:16] <leonardr> in which case webservice() is better
[15:17] <bac> that sounds good to me.  the web services tests will require updating when new fields are exposed but the actual tests should be lplib.
[15:17] <gary_poster> abentley: (agree, and Francis and I have talked about different ways we can attack that.  I suspect that the first way will be appropriate sometimes, particularly for API calls that are heavily used, but this hasn't been hardened yet.)
[15:18] <bac> anything else on this topic?
[15:18] <bac> [topic]  * bac to restart discussion on community reviewer/committers after feedback from elmo
[15:18] <gary_poster> not from me
[15:18] <MootBot> New Topic:   * bac to restart discussion on community reviewer/committers after feedback from elmo
[15:18] <abentley> gary_poster, it can be very difficult to predict what kind of changes will break clients.  Some will accidentally depend on bugs, for example.
[15:18] <gary_poster> abentley: agreed.
[15:19] <bac> i've been unable to get an opinion from legal about community reviewers/committers but got a strong one from elmo.  i'll share that with the list and start the discussion again.
[15:20] <bac> apologies for dragging this out.
[15:20] <bac> [topic] peanut gallery
[15:20] <MootBot> New Topic:  peanut gallery
[15:20] <bac> any new topic to discuss?
[15:20] <bac> oh, wait, backup.
[15:20] <noodles775> Just an update that Jelmer has started reviewing on Thurs...
[15:20] <bac> [topic] mentoring update
[15:20] <MootBot> New Topic:  mentoring update
[15:20] <noodles775> :)
[15:21] <noodles775> as a mentat.
[15:21] <bac> welcome jelmer to the meeting and as a reviewer mentat.
[15:21] <bac> noodles775:  thanks for doing the mentoring
[15:21] <jelmer> thanks Brad
[15:21] <noodles775> bac: np!
[15:22]  * wgrant wonders in which direction elmo's opinion was.
[15:22] <bac> so everyone bring lots of good reviews to jelmer on thursdays
[15:22] <noodles775> Yeah, particularly some non-soyuz ones!
[15:22] <bac> so, back to the peanut gallery.  are there any other topics?
[15:23] <bac> 3
[15:23] <abentley> I am having trouble remembering to attend this meeting
[15:23] <abentley> And part of it is because it's no longer a weekly meeting.
[15:24] <flacoste> it's not weekly anymore?
[15:24] <abentley> Instead of notifying people when it's *not* happening, maybe we could notify people when it *is*?
[15:24] <bac> abentley: would you prefer a regularly scheduled meeting even if there isn't much going on or the disruption of occassionally canceled ones?
[15:24]  * noodles775 just assumes it is on, unless there's notice.
[15:24] <abentley> flacoste, it's been cancelled due to lack of agenda frequently.
[15:26] <abentley> noodles775, bac: I find the routine helps me remember.
[15:26] <bac> abentley: but if you're around at this time, and keep your calendar free for the hour, is it a burden if we just ping you to join?
[15:26] <abentley> bac, no, that's fine on my end.
[15:27] <bac> abentley: i understand routine is nice.  but i figured saving the team from showing up when there isn't much to discuss outweighs it.  and others have commented they like the idea.
[15:27] <bac> abentley: and you're at a disadvantage b/c you have no other team members to check to see if you're around...
[15:28] <abentley> abentley, true.
[15:28] <abentley> bac, true
[15:28] <bac> if there's nothing else let's call it a meeting.
[15:28] <bac> thanks for coming
[15:28] <bac> #endmeeting
[15:28] <MootBot> Meeting finished at 09:28.
[15:28] <noodles775> Cheers bac
[22:31] <bac> hi thumper, mwhudson, rockstar -- up for a reviewers meeting?
[22:31] <mwhudson> alright
[22:31] <thumper> bac: if it's quick, I have something on soonish
[22:32] <bac> thumper: let's do quick, then
[22:32] <bac> in the ameu meeting we had a very brief conversation
[22:32] <bac> we talked about the issue michael raised on the list wrt launchpadlib
[22:33] <bac> it sounds like leonard has addressed all of your concerns.
[22:33] <bac> he provides helpers for creating credentials for a user and getting an object and logging in anonymously is easy
[22:34] <bac> we agreed that new API functionality should be tested with new lplib tests, which are preferred over the webservice tests
[22:34] <bac> of course the old tests will need to be kept up-to-date when new things are exported, unless a test is completely replaced
[22:35] <bac> other than that, i am supposed to reopen the discussion about community reviewers/committers based on info i've gotten from IS
[22:35] <bac> that, in a nutshell, was the meeting.
[22:35] <bac> of course it took us closer to 30 minutes to get all that out
[22:35] <bac> y'all have anything else?
[22:36] <thumper>  what is the result of the email from is?
[22:37] <bac> for many of the reasons we brought up in our internal discussion, elmo does not want to allow commit rights to a branch that automatically goes into production/edge
[22:38] <thumper> but happy for reviews?
[22:38] <bac> he thought it'd be ok if we create an intermediate branch that accepts contributions from some community members but must be reviewed by a canonical employee before deployment
[22:38] <bac> thumper: i'll need to review his email to refresh my memory on the reviewer issue
[22:38] <thumper> ok
[22:38] <mwhudson> bac: yeah, i'm happy with the launchpadlib test scaffolding now
[22:38] <bac> iirc he was not in favor of a single external reviewer.
[22:38] <bac> mwhudson: great
[22:39] <bac> i think there is great value in having community reviewers, even if they do need a second pair of eyes
[22:39] <bac> anyway, let me formulate a proposal and get it out on the list
[22:40] <bac> that's all i've got
[22:40] <thumper> I've nothing to add
[22:40] <bac> ok.  well let's call it a meeting then so you can get to your next one.
[22:40] <bac> later.
[22:43] <mwhudson> thanks bac


[08:34] <mehjari> hi, can anyone help setting up gui in ubuntu server 18.04? i get to remote desktop screen where it shows me "xrdp - just connecting" popup with session dropdown having multiple options.. i tried alll of them but nothing seems to work :(
[08:43] <mehjari> "systemctl status xrdp-sesman.service" shows this line "ExecStop=/usr/sbin/xrdp-sesman $SESMAN_OPTIONS --kill (code=exited, status=1/FAILURE)"
[08:43] <mehjari> i am not sure if it is relevant
[09:56] <tomreyn> mehjari: a GUI is usually the main difference between a server and a desktop (there can be others, such as different hardware, workloads etc.) Do you really need a GUI on your server, or could you also manage it on a remote shell?
[09:59] <tomreyn> another option would be webmin, a web UI for managing systems. experienced system administrators would usually also frown at this, but might prefer it over a GUI.
[09:59] <mehjari> tomreyn, i am trying to start a vagrant box in Ubuntu server, it is giving me SSH retry error. some online forums suggested that i should check what is the status of VirtualBox UI at that point, is there any popup etc.
[09:59] <mehjari> therefore, as much as i hate installing GUI on server, i have to try GUI.
[10:02] <rbasak> mehjari: I don't know about VirtualBox, but if you were using libvirt+KVM instead, then you could run virt-manager on a different box and connect it to the running libvirt instance on the server to see what the problem is - so no GUI needed on the server itself.
[10:02] <rbasak> Does VirtualBox not have support for something like that?
[10:05] <cpaelzer_> rbasak: mehjari: I think you can expose the display
[10:05] <cpaelzer_> like you'd expose VNC on libvirt
[10:05] <cpaelzer_> and you can then attach to that
[10:05] <cpaelzer_> yeah, this looks good https://www.techrepublic.com/article/how-to-connect-to-a-virtualbox-vm-desktop-remotely/
[10:06] <cpaelzer_> just the first hit on search engine, I did not try it myself
[10:06] <cpaelzer_> that would allow to see early boot of the guest and such
[10:06] <cpaelzer_> and IIRC virtualbox can control all on cmdline as well
[10:06] <cpaelzer_> although I don't know hot to enable the remote display feat there I'm sure that can be found
[10:09] <mehjari> if vbox is stuck at the popup "enable SLAT2" or VTIX technology in BIOS (which i want to rule out), the it doesn't show up with controlvm cli api as far as i can tell
[10:09] <mehjari> i am not sure if they have logs which can reflect the state of UI at certain point
[10:10] <mehjari> the Ubuntu VM is in Azure, and MSFT is charging monies, so i wanted a quick solution.. -.-
[10:12] <Greyztar> hello,is it normal that with snap apparmor isnt working,this is not on Ubuntu though but on Debian,just wonder in general if apparmor isnt ment to work on other installs with snap?
[10:13] <Greyztar> and also is it so that apparmor is sort of the sandboxing function of apps?
[11:03] <tomreyn> mehjari: in case this is still relevant, some folks in #vbox tend to be rather responsive.
[11:05] <tomreyn> Greyztar: /join #snappy
[11:06] <Greyztar> tomreyn: thanks i looked for #snap but didnt find any
[11:50] <mehjari> tomreyn, thanks, will sync with vbox. :)
[14:53] <Ussat> Well, looks like Canonical might get a new customer....have a call scheduled with a SA today to disscuss Landscape
[16:32] <teward> landscape is fun.  :P
[16:32] <teward> (I use it for all my new servers now xD)
[16:50] <lordcirth> teward, Isn't it expensive? Or is there a community version?
[16:52] <teward> lordcirth: it does get expensive yes.  (In this case I already have seats)
[16:52] <teward> (and those're fixed-price not per-minute)
[16:54] <RoyK> most of what landscape does is easily achivable with simple scripts
[16:54] <RoyK> or packages already available in ubuntu
[16:55] <RoyK> so just setup your ansible playbook to add that to your machines and - well - no problem
[18:29] <rbasak> https://pastebin.ubuntu.com/p/dPQx4RyyzF/
[18:29] <rbasak> How can I figure out what's using all that memory?
[18:29] <rbasak> Is that a kernel memory leak?
[18:30] <lordcirth> rbasak, highly unlikely.  My system has 32G, but it's thrashing.
[18:30] <rbasak> https://pastebin.ubuntu.com/p/RD7sqVCQFR/
[18:30] <rbasak> No swap, but I added some to give me some headroom.
[18:31] <lordcirth> I see. Are you running any network filesystems, or anything which would keep a lot of files open?
[18:31] <rbasak> No
[18:31] <lordcirth> rbasak, also, what Ubuntu version and kernel version?
[18:32] <rbasak> 4.4.0-139-generic with livepatch
[18:32] <rbasak> 16.04
[18:32] <rbasak> I could just reboot
[18:32] <rbasak> But I don't like doing that
[18:32] <rbasak> Because I'd like to fix the problem for next time too
[18:32] <rbasak> This is a desktop btw.
[18:32] <lordcirth> rbasak, what's your uptime?
[18:32] <rbasak> 175 days
[18:32] <lordcirth> That's pretty long for a desktop
[18:32] <lordcirth> What graphics drivers?
[18:32] <JanC> maybe the live patching messed something up?
[18:33] <rbasak> AMD
[18:33] <rbasak> My graphics setup is pretty non-standard, so a leak there could be likely.
[18:33] <rbasak> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM] (rev 81)
[18:33] <lordcirth> Updating your graphics drivers without a reboot can cause all sorts of problems.
[18:33] <rbasak> I'd just like to know how to pin the leak down to something, if there's any such mechanism possible.
[18:34] <lordcirth> That's beyond my skills. But I'd consider 175 days uptime on a desktop unreasonable and just reboot it
[18:34] <JanC> also, this isn't the proper channel to discuss desktop issues maybe  ;)
[18:34] <OerHeks> sudo canonical-livepatch status --verbose # gives fixes ""  ?
[18:34] <lordcirth> True, I didn't even notice
[18:35] <rbasak> JanC: yeah, maybe :)
[18:35] <rbasak> I don't need any desktop specific answer
[18:35] <JanC> maybe the kernel people can give some pointers
[18:35] <rbasak> Just some help grokking kernel memory information, which isn't desktop specific
[18:35] <rbasak> smem, etc
[18:37] <OerHeks> if status says livepatch:  state: applied, you need to reboot anyway, and run ful-upgrade, there might be more kernels and patches waiting...
[18:38] <OerHeks> 175 days ... awesome
[18:38] <sarnold> rbasak: wow; are those counts going up over time?
[18:39] <rbasak> sarnold: AFAICT, yes.
[18:39] <OerHeks> rbasak, what is the output for inodes: df -i
[18:40] <rbasak> OerHeks: looks OK. I don't want to paste that (privacy) but apart from snap loopback devices (squashfs), the highest IUse% is 36% for /, so I don't think it's that.
[18:41] <OerHeks> oke, just checking.
[18:41] <rbasak> I appreciate the thought :)
[18:42] <OerHeks> then livepatch should be the culprit, AFAIK, waiting
[18:42] <rbasak> Earlier I sent SIGSTOP to firefox and snap related process, so I can't run livepatch right now.
[18:42] <rbasak> (since they were causing the thrashing)
[18:43] <rbasak> I could resume the snap ones I guess now that I've added swap
[18:43] <rbasak> I'm quite sure rebooting will fix the issue, but I'd prefer to find bugs before I remove all the evidence :)
[18:43] <JanC> it might be useful to talk to the kernel and graphics devs
[18:45] <rbasak> Hmm.
[18:45] <rbasak> "canonical-livepatch status" hangs, but I don't know if I caused that by interfering with it earlier.
[18:46] <TJ-> rbasak: can you scan /proc/[1-9]*/pagemap to discover where the memory is allocated?
[18:46] <rbasak> TJ-: I don't think it's allocated to any process
[18:46] <rbasak> TJ-: based on smem output from https://pastebin.ubuntu.com/p/svVbxh7k9m/ earlier
[18:47] <sarnold> rbasak: can you get bcc tools on this system? https://github.com/iovisor/bcc/blob/master/tools/memleak_example.txt
[18:48] <sarnold> rbasak: if not, perf trace can probably do a similar job, but these are nice tools :)
[18:48] <rbasak> sarnold: is that packaged? :)
[18:50] <OerHeks> https://github.com/iovisor/bcc/blob/master/tools/memleak.py
[18:50] <OerHeks> easy peasy
[18:52] <TJ-> rbasak: ah, does "smem -w" confirm its kernel mem ?
[18:53] <rbasak> Looks like it is packaged but only from Bionic :-/
[18:53] <rbasak> TJ-: right - it's under 'kernel dynamic memory'
[18:55] <sarnold> rbasak: hey it is! :D bpfcc-tools
[18:55] <sarnold> rbasak: haha, thanks, I hadn't realized it'd been packaged up yet.
[18:57] <TJ-> rbasak: "smem -m | tail" might help a bit more
[18:58] <rbasak> Biggest is <anonymous>                                120    38624  4634930
[18:58] <rbasak> What are the units?
[18:59] <TJ-> "smem -m | head -1" :) == " Map                                       PIDs   AVGPSS      PSS "
[18:59] <rbasak> I did look there! Those aren't units I understand.
[18:59] <TJ-> The unshared memory (USS) plus  a  process's  proportion  of  shared  memory  is
[18:59] <TJ->        reported as the PSS (Proportional Set Size).  The USS and PSS only include physical memory usage
[18:59] <TJ-> "man smem"
[19:00] <rbasak> Those still aren't units!
[19:00] <TJ-> rbasak: not my fault!
[19:00] <rbasak> OK, but my question still stands then :)
[19:01] <TJ-> rbasak: I'd guess kB the same as free reports?
[19:02] <rbasak> TJ-: as long as it's not "pages" or something, then that's only ~5G so not my leak :(
[19:03] <TJ-> rbasak: it is infuriating when it doesn't say
[19:03] <rbasak> Agreed!
[19:04] <TJ-> rbasak: use "-k" it shows the units
                                120    36.0M     4.2G
[19:05]  * TJ- hugs the man-page
[19:05] <TJ-> rbasak: so no help there then
[19:05] <compdoc> so gay
[19:05] <TJ-> compdoc: if you are, so what?
[19:09] <rbasak> I backported Bionic's bpfcc to Xenial.
[19:09] <rbasak> But I get
[19:09] <rbasak> $ sudo /usr/sbin/memleak-bpfcc -o 60000
[19:09] <rbasak> /virtual/main.c:18:1: error: could not open bpf map: Invalid argument
[19:09] <rbasak> is maps/stacktrace map type enabled in your kernel?
[19:09] <rbasak> It might be time to give up.
[19:09] <rbasak> Thanks to everyone for trying :)
[19:12] <OerHeks> :-)
[19:23] <mwheeler-> I just did a fresh install of lanscape on ubuntu 16.04, and when I try to register computers, they won't register and there's a "missing/invalid csrf token" error in the server logs.. google search turns up nothing.. any ideas?
[19:25] <OerHeks> maybe a strict setting in firefox/chrom(ium), https://get.todoist.help/hc/en-us/articles/208951085-CSRF-token-error-messages
[19:26] <mwheeler-> OerHeks: the weird thing is that I get the error when trying to register a computer with the landscape-config command
[19:26] <mwheeler-> so landscape client can't talk to landscape server .. getting CSRF error
[19:27] <TJ-> mwheeler-: are you having to go through a proxy?
[19:27] <mwheeler-> nope, no proxy, and both client and server are on the same L2 subnet
[19:27] <mwheeler-> they're VMs on the same host
[19:33] <TJ-> can you tell if the token is missing, or invalid - the latter could mean multiple connections causing confusion, the former I'm not sure what
[19:34] <mwheeler-> good question.. I didn't pay that close attention to the tcpdump.. I'm blowing away the VM right now and rebuilding it just to see if there was something screwy with it.. it was my general "use and abuse" server when I needed to test something
[19:35] <TJ-> mwheeler-: it sounds like the kind of error coming up from a library, most likely Python
[19:37] <mwheeler-> TJ-: yeah, in the log message I see zopepublication.py .. so it is likely further down in the stack than landscape
[19:42] <TJ-> mwheeler-: "zope" look to be the underlying framework they're using
[19:43] <mwheeler-> yep
[19:43]  * TJ- recalls trying Zope some years ago and running away, scared
[19:43] <mwheeler-> I feel that way about most web frameworks
[20:02] <JanC> CSRF token issues might be a result of an ad blocker or such (blocking cookies or whatever)


[16:00] <robbiew> o/
[16:00] <ev> hiya
[16:01] <doko> hi
[16:01] <cjwatson> hi
[16:03] <robbiew> surbhi and barry are on vacation
[16:03] <robbiew> anyone seen Keybuk today?
[16:03] <robbiew> mvo: joining?
[16:03] <ev> nope
[16:03] <mvo> hello
[16:05] <robbiew> okey dokey then
[16:06] <robbiew> let's start with the lightning round
[16:06] <robbiew> ev?
[16:07] <ev> I've been working on sorting out the KDE frontend to ubiquity, per Riddell's request.  Also fixing remaining bugs and UI issues before we hit freeze tomorrow.
[16:07] <ev> (done)
[16:07] <robbiew> doko>
[16:07] <doko> * OOo update for maverick, some bug fixes, backport for lucid
[16:07] <doko> * last round of python updates, 2.6.6 release, some 2.7 support
[16:07] <doko> * updating openjdk, integrate patches in icedtea
[16:07] <doko> * updates for lucid-proposed
[16:07] <doko> will be at OOoCon next week
[16:08] <doko> (done)
[16:08] <robbiew> thnx...cjwatson?
[16:08] <cjwatson> done: CD boot menu updates for Kubuntu; lots and lots of fiddly GRUB-on-EFI debugging; ported EFI boot support from Fedora to cdrkit; trying to clear up beta bugs (e.g. #600782, #602273, #604087, #604765)
[16:08] <cjwatson> todo: finishing off last pieces of GRUB integration onto CDs for EFI; getting linearfb kernel driver merged upstream; more beta bugs (esp. #544139)
[16:09] <robbiew> thnx
[16:09] <robbiew> and last, but not least...mvo
[16:09] <mvo> one vacation last week, working on software-center and the new apt this week
[16:09] <mvo> (done)
[16:09] <robbiew> thnx
[16:10] <mvo> apt-0.8 hit maverick btw with (disabled by default) multiarch
[16:10] <cjwatson> ... shame about dpkg, eh?
[16:10] <mvo> :)
[16:11]  * robbiew checks https://bugs.launchpad.net/ubuntu/maverick/+bugs?field.milestone=27563
[16:11] <robbiew> things seem fine there
[16:12] <robbiew> mvo question about buy something spec
[16:12] <robbiew> who owns the work items at the top
[16:13] <mvo> if not otherwise labeled its probably me :/
[16:13] <robbiew> add code to aptdaemon to add auth tokens to /etc/apt/auth.conf: TODO
[16:13] <robbiew> add code that apt-get updates only the newly added source code line to aptdaemon Installing the app: TODO
[16:13] <robbiew> release upgrade handling: ensure ppa is updated to the new release (if possible): TODO
[16:13] <robbiew> release upgrade handling: ensure that purchased apps do not get removed if no longer downloadable: TODO
[16:13] <robbiew> and "detect if OAuth ubuntu-sso tokens are revoked: TODO"
[16:14] <mvo> I update the status, sorry that its so messy
[16:14] <robbiew> heh..no worries
[16:14] <mvo> the upgrade releated ones are only needed in N
[16:14] <robbiew> but thanks
[16:14] <mvo> the oauth stuff got moved to ubuntuone ;)
[16:14] <robbiew> okay, so feel free to POSTPONE items if need be
[16:14] <mvo> thanks, will do
[16:14] <robbiew> heh...works for me
[16:14] <robbiew> thanks
[16:15] <robbiew> http://people.canonical.com/~pitti/workitems/maverick/canonical-foundations-ubuntu-10.10-beta.html
[16:15] <robbiew> is VERY misleading
[16:15] <robbiew> as there is a bunch of arm stuff in there that's not ours
[16:16] <robbiew> cjwatson: have we pretty much done all we can for foundations-m-btrfs-support?
[16:17] <cjwatson> at this point, I think so; cmason replied on grub-devel today apologising for having taken so long and reiterating an intent to review
[16:18] <cjwatson> I think we still need to hear from hpa
[16:18] <cjwatson> (formally, that is)
[16:18] <cjwatson> so by the time all that lands, I think it's unfortunately going to be too late for maverick
[16:18] <robbiew> ugh...well, it's not our fault so...it is what it is
[16:18] <cjwatson> surbhi's patches are the de facto ones that will be in the review queue as soon as the legalities are sorted out
[16:18] <robbiew> ack
[16:19] <robbiew> ev: did you catch the email thread about us taking over the wubi site?
[16:19]  * robbiew changes topics
[16:19] <ev> yes, was IS contacted about that?
[16:19] <robbiew> nah, I haven't done that yet
[16:19] <ev> okay
[16:19] <ev> it was always the plan, but as ago says, we never got to it
[16:19] <robbiew> wanted to wait until you got back, to make sure we can
[16:19] <ev> so I'm happy to see it happen
[16:20] <robbiew> ah..cook
[16:20] <robbiew> cool
[16:20] <robbiew> ev: so what do we need to get this done
[16:20] <robbiew> hosting space and a web address?
[16:21] <ev> indeed
[16:21] <ev> or actually
[16:21] <ev> perhaps this should go to MT and the design team?
[16:21] <ev> and thus whatever they need from IS to get it done
[16:22] <robbiew> hmm...yeah, I suppose they can setup the webpage
[16:22] <robbiew> all we need is a place to upload to
[16:22] <ev> I'd suggest talking to Iain about it
[16:22] <robbiew> ack
[16:23]  * robbiew will send out email on yearly objectives today...hopefully
[16:23] <robbiew> they are *supposed* to be in by this friday...but oh well
[16:23] <robbiew> :)
[16:24] <robbiew> ev: mvo: doko: cjwatson: have you all booked UDS Natty travel?
[16:24] <mvo> yep, ready for nutty
[16:24] <cjwatson> ... no.  I'll get that done
[16:24] <doko> mvo: for what?
[16:25] <doko> have to do this too
[16:25] <robbiew> mvo: heh
[16:25] <SergioMeneses> hie
[16:25] <robbiew> deadline is quickly approaching
[16:25] <ev> robbiew: I'm in talks with Amity for it.  Trying to get there a little early (cheaper than flying direct on Saturday) so I can drive down and see nearby family.
[16:25] <robbiew> ev: ok, thnx for the info
[16:26] <robbiew> ev: I assume you'll be stopping by for the release sprint, right?
[16:26] <ev> robbiew: given that I mostly work out of millbank, I'm sure I can make the trip to the other side of the office ;), but yeah, wouldn't miss it.
[16:27] <robbiew> heh
[16:27] <robbiew> smartass
[16:27] <robbiew> thnx
[16:27] <ev> haha
[16:28] <robbiew> and last but not least, cjwatson can you drive the beta release next week?
[16:28] <robbiew> or do I need to pull in pitti and/or slangasek to assist
[16:28] <cjwatson> I'll be around, so yes I should be able to
[16:28] <cjwatson> will skat be around as well?
[16:30] <robbiew> I think it's skaet now
[16:30] <robbiew> and yes...most definitely
[16:31] <robbiew> I think "skat" was just to close to "dung"
[16:31] <robbiew> lol
[16:32] <ev> heh
[16:32] <robbiew> oh yeah...and I'm narrowing done the list of candidates
[16:33] <robbiew> got 2 so far, waiting on feedback from ev and cjwatson on the last 2 in the pipeline...depending on the feedback, I may speak to them...otherwise, I'll choose from the 2 I have
[16:33]  * robbiew wants this decided asap
[16:34] <robbiew> that's it for me?
[16:34] <robbiew> anything else from anyone else?
[16:35] <robbiew> guess not
[16:35] <robbiew> thnx mvo, cjwatson, ev, and doko
[16:35] <mvo> thanks!
[16:35] <ev> thanks!
[16:35] <doko> thx
[16:35] <mvo> back to rushing in the remaining stuff before beta-freeze
[16:36] <robbiew> heh
[17:48] <marjo> QA Team Meeting 1700 UTC in #ubuntu-quality
[17:48] <nigelb> @now
[20:03] <highvoltage> hi! Anyone around for Edubuntu meeting?
[20:04] <alkisg> Hi all
[20:04] <highvoltage> hey alkisg
[20:05] <highvoltage> I'm low on energy today so I won't blabber as much as usual :)
[20:05] <highvoltage> stgraber and I worked on a new Edubuntu website
[20:06] <highvoltage> it's not complete yet, but it's up already and I believe it's an improvement on the old site already: http://edubuntu.org/
[20:06] <alkisg> Is that the drupal theme you bought?
[20:06] <highvoltage> I put quite some effort in the screenshots page so far, I think it's quite nice
[20:07] <highvoltage> alkisg: yep, I simplified it a bit and stgraber fixed a few bugs, so it's not quite like the original anymore
[20:07] <alkisg> Looks very elegant
[20:07] <alkisg> Is it easy to make it liquid?
[20:07] <highvoltage> yes I hope that it will be elegant with a strong hint of fun when it's done
[20:08] <highvoltage> I don't know, I'll look into it, liquid would be nice
[20:08] <alkisg> ...but probably the ones that have e.g. 1920x1080 will be using some scaling in firefox already, so no big deal I imagine...
[20:08] <highvoltage> yesterday I did a search on youtube for edubuntu... found a bunch of really interesting edubuntu videos. I created an edubuntu youtube channel and added most of them as favourites to the channel
[20:09] <highvoltage> alkisg: and at that resolution you'd probably not run your browser full-screen anyway
[20:09] <alkisg> Heh, I don't think it's http://www.youtube.com/edubuntu, right? :D
[20:10] <highvoltage> http://www.youtube.com/user/edubuntuproject
[20:10] <highvoltage> yeah, edubuntu was already taken :-/
[20:10] <highvoltage> (by somethign not at all edubuntu related)
[20:11] <alkisg> Well if he's using edubuntu, I imagine he'd be glad to give it to the project..
[20:11] <highvoltage> I guess it couldn't hurt trying :)
[20:13] <highvoltage> on the technical side of things, our daily build currently doesn't install (ubiquity is crashing) and a few times I tried to boot the disc it wouldn't boot, but I think that's not restricted to us atm
[20:13] <highvoltage> that's pretty much all from my side :)
[20:13] <alkisg> How's the live ltsp stuff going?
[20:15] <highvoltage> alkisg: I'm going to spend some time on that over the next few days and try to get it at least in a working state. at the moment it's pretty much useless, and I won't be extremeley happy if we had to revert to how we did it in Lucid
[20:16] <alkisg> highvoltage: if you need any help / debugging etc, ping me
[20:16] <highvoltage> alkisg: thanks! I'm sure I'll need you for that :)
[23:48] <UndiFineD> highvoltage, there OOo screenshots missing


[12:02] <Trevinho> where should I report a bug against the ddebs repo?
[12:06] <seb128> Trevinho, https://bugs.launchpad.net/ddeb-retriever/
[12:06] <Trevinho> ack thanks
[14:39] <kanashiro> doko_, I recall you mentioning a golang issue in your +1 maintenance report form last week and I am wondering if it might be related to this regression on non-amd64 architectures I am getting: https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/arm64/g/golang-github-containers-image/20210530_134115_5e38b@/log.gz