[00:23] <fta> hm, is it just me or is X no longer listening on :0 but on :1 by default???
[00:30] <JanC> it's on :0 for me (on maverick)
[00:35] <fta> me too, but on natty, i have :1.0 now
[00:36] <BUGabundo> how can I check?
[00:36] <BUGabundo> declare -x DISPLAY=":0.0"
[00:39] <fta> look at the X process
[00:39] <fta> mine looks like /usr/bin/X :1 -br -verbose  ...
[00:39] <BUGabundo> bugabundo@BluBUG:~$ psx X
[00:39] <BUGabundo> root       992  6.4  0.8<PHONE_NUMBER>2 tty7     Rs+  Nov04   9:02 /usr/bin/X :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-O7awzM/database -nolisten tcp vt7
[00:40] <fta> hm
[00:40] <fta> well, i fixed flappy to auto-detect that
[00:40] <BUGabundo> fta: dear... YOUAREDOINGITWRONG :p
[10:50] <chrisccoulson> hi dpm. so, we're likely to get a FF4.0 beta 7 release soon, at which point, i'd like to get it in to natty
[10:51] <chrisccoulson> which means we'll need to start getting the language packs updated :)
[10:52] <dpm> hey chrisccoulson, we were thinking of releasing the first language packs at alpha-1, would that be earlier? Even then, I think it should be fine, we'd only need to talk to pitti to get the natty langpacks builds started
[10:54] <chrisccoulson> dpm - yeah, that should be ok
[10:55] <dpm> chrisccoulson, so langpacks in alpha-1 should be ok? - If not, it's just a matter of pinging me and pitti when you need them
[10:55]  * dpm <-- early early lunch
[10:56] <chrisccoulson> dpm - yeah, i think that's ok. it means that there'll be a couple of weeks where firefox is not localized, but i don't think that's an issue in a pre-alpha version
[10:56] <chrisccoulson> i guess only really hardcore and insane people are running natty right now ;)
[10:57]  * gnomefreak is insane than ;)
[10:57] <chrisccoulson> lol
[10:57] <chrisccoulson> and me
[10:57] <chrisccoulson> :)
[11:02] <gnomefreak> xul192 seems to still be hanging, just using dpkg --con.... but i have not done all the other updates yet
[11:02] <gnomefreak> gnomefreak@Development:~$ sudo dpkg --configure -a
[11:02] <gnomefreak> Setting up xulrunner-1.9.2 (<IP_ADDRESS>~hg20101021r34694+nobinonly-0ubuntu1~umd1) ...
[11:03] <gnomefreak> 2.0 same way. let me worry abot it more when i am fully up to date
[11:03] <gnomefreak> ah i see 13 was posted so im going to guess that is what fixes it
[11:09] <gnomefreak> clicompanion is kind of cool even though it is targeted towards new users
[11:39] <gnomefreak> chrisccoulson: please tell me the xul192.13 fixed the stalling issue
[11:39] <gnomefreak> for me it is stalling still
[11:41] <gnomefreak> well i guess not since it is still stalled out
[11:55] <nikolam> How to stop freaking indexing of messages on Thunderbird 3.0? I am on Notebook an it is eating my battery, using 100% cpu !
[11:56] <gnomefreak> nikolam: it is in the preferences
[11:56] <nikolam> I think It is because I used Third mail database (imap, local copy) with newer TB and older is now freaking out, making new index
[11:56] <nikolam> ok gno
[11:56] <nikolam> gnomefreak, ok
[11:57] <nikolam> it is "enable global search indexer I suppose
[11:59] <gnomefreak> micahg: yes
[11:59] <gnomefreak> damn
[11:59] <gnomefreak> nikolam: yes
[12:09] <gnomefreak> chrisccoulson: yeah xul192 is still stalling during set up
[12:09] <gnomefreak> im going to assume so does 2.0 and icedtea
[12:09] <gnomefreak> !aptlock
[12:09] <ubot2> If an APT front-end crashed and your database is locked, try this in a !terminal: « sudo fuser -vki /var/lib/dpkg/lock;sudo dpkg --configure -a »
[12:12] <gnomefreak> any workaround yet?
[12:15] <gnomefreak> i havent been here in weeks and it is still an issue, might i suggest looking into the bug, or at least point me to where to report PPA bugs
[12:25] <gnomefreak> yep 2.0 same bug
[12:25] <gnomefreak> apparmor + browser errors
[12:29] <gnomefreak> Errors were encountered while processing: xulrunner-1.9.2 xulrunner-2.0 icedtea-plugin xulrunner-2.0-gnome-support
[12:44] <gnomefreak> i thought we updated apport with our PPA hooks at one point but i guess not
[12:58] <gnomefreak> chrisccoulson: micahg bug 671394 (not sure who is working on this or even if it was a known issue
[12:58] <ubot2> Launchpad bug 671394 in ubuntu-mozilla-ppa-bugs "Xulrunner-1.9.2 and xulrunner-2.0 stall out on configuring (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/671394
[14:30] <fta> jdstrand, mdeslaur: hi. bug 671420 + http://people.ubuntu.com/~fta/chromium/7.0.517.44~r64615/
[14:30] <ubot2> Launchpad bug 671420 in chromium-browser (Ubuntu Natty) (and 3 other projects) "7.0.517.41~r62167 -> 7.0.517.44~r64615 security update (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/671420
[14:30] <jdstrand> fta: ack. thanks!
[14:31] <jdstrand> mdeslaur: I've got it
[14:34] <mdeslaur> fta, jdstrand: cool, thanks
[14:40] <fta> dpm, hi, the 1st batch of translations landed in the chromium daily ppa
[14:40] <fta> dpm, i had a problem with a translator turing <!-- x --> into <!- x ->, making the xml parser in grit fail
[14:41] <fta> dpm, so i now check all the strings for xml errors before i accept them during the gettext->grit convertion. it's slower but it's better than an ftbfs
[14:43] <fta> -turing+turning
[14:43] <dpm> fta, yeah, I think it's a good idea. Launchpad does the checking for gettext format variables, but with xml and other formats it cannot.
[14:44] <fta> dpm, how should i report such errors?
[14:44] <dpm> fta, what do you mean, to translators?
[14:46] <fta> dpm, yep. last output (still ugly), looked like this: http://paste.ubuntu.com/526344/
[14:46] <fta> (would be nice to have bug 669831 fixed shortly)
[14:46] <ubot2> Launchpad bug 669831 in rosetta "obsolete translations exported to the branch (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/669831
[14:47] <dpm> fta, there are several possibilities: send a list with the errors to the launchpad-translators LP mailing list, or send them to the relevant teams. Launchpad translations teams are always named as lp-l10n-CC, where CC is the country code. You can get each team's e-mail address through the Launchpad API
[14:48] <dpm> https://translations.edge.launchpad.net/+groups/launchpad-translators
[14:49] <dpm> as per the bug, I'd recommend poking danilo, jtv and henninge next week (I think today they're either away or already reached EOD)
[14:49] <dpm> I already did some poking myself as well :)
[14:51] <fta> dpm, i don't have much luck with launchpad bugs in general, i have a dozen opened for months/years, none moved a bit
[15:01] <jdstrand> fta: I uploaded chromium to security-proposed. the packages were perfect. thanks so much! :)
[15:02] <fta> excellent
[15:04] <fta> jdstrand, in case you didn't notice, in it, there are security fixes for webkit and libvpx, we should have those in our system packages, right?
[15:05] <jdstrand> fta: I did see you and mdeslaur discuss that, yes. we will provide fixes for those as part of our normal processes
[15:05] <fta> jdstrand, great
[15:53] <fta> damn, the python difflib module produces patches incompatible with hardy's patch command
[15:59] <fta> micahg, chrisccoulson: umd is failing on ff4.0. could you please stop doing the uudecode stuff and all the pre-builds to a later step. they are executed in my server now
[16:00] <chrisccoulson> urgh, that's not intentional :/
[16:00] <fta> ..and i don't have all the necessary deps installed (i shouldn't)
[16:00] <chrisccoulson> sorry about that
[16:00] <fta> n-p
[20:06] <chrisccoulson> hmmm, 200 xpcshell test failures on firefox with gcc-4.5
[20:07]  * chrisccoulson cries
[20:07] <micahg> chrisccoulson: we can wait another week to get it in, no worries
[20:07]  * micahg can push to PPA first
[20:12] <chrisccoulson> oh, the test failures are mostly crashes
[20:12] <chrisccoulson> interesting
[20:42] <chrisccoulson> woah, 1 of the crashtests triggers a huge memory leak in firefox too
[20:42] <chrisccoulson> 5GB of swap and counting....
[23:42] <BUGabundo> oias o/
[23:42] <BUGabundo> seems trunk has a fix for firefox chrashs
[23:42] <BUGabundo> YAY


[19:41] <PabloRubianes> daker, hello, have a minute for a PM?
[19:41] <daker> hi PabloRubianes
[20:12] <JoseAntonioR> popey: ping
[20:14] <popey> JoseAntonioR: pong
[20:14] <JoseAntonioR> hey, wanted to know if you got to do the domain transfer to canonical
[20:14] <JoseAntonioR> s/canonical/IS
[20:15] <popey> not yet, will chase in the morning
[20:17] <JoseAntonioR> ok, thanks! :)
[22:20] <jcastro> bkerensa: I bet they're revving for Haswell
[22:20] <jcastro> but that's a guess
[23:19] <bkerensa> jcastro: yeah hopefully but when I asked (I was going to buy one the other day) they said they are no longer selling them in the U.S.
[23:19] <bkerensa> :(
[23:19] <bkerensa> hopefully it was a confused CSR
[23:20] <bkerensa> Haswell would be worth waiting for though


[05:49] <Kilos> morning all
[06:18] <magespawn> good morning
[06:19] <Kilos> hi magespawn FusionSparc
[06:19] <Kilos> morning inetpro
[06:19] <Kilos> ohi thatgraemeguy
[06:24] <FusionSparc> Morning
[06:24] <thatgraemeguy> morning
[06:44] <inetpro> good mornings everyone
[07:19] <magespawn> whats up Kilos ?
[07:19] <Kilos> mainly busy in garden and yard magespawn
[07:19] <Kilos> dubbletjies everywhere
[07:20] <Kilos> only weeds maintain fine on min rain
[07:41] <magespawn> in some places grass is a weed
[07:53] <dlPhreak> Greets
[07:55] <superfly> ohi
[07:56] <dlPhreak> Kilos, magespawn, superfly how are you?
[07:57] <Kilos> ok ty
[07:57] <Kilos> hi superfly
[08:01] <superfly> hi dlPhreak, I'm alright
[08:05] <dlPhreak> That's cool superfly, what are you up to?
[08:07] <superfly> dlPhreak: working
[08:10] <dlPhreak> superfly: heavy days haha
[08:14] <unlaudable> client managed to lose there entire /usr/share directory
[08:21] <superfly> unlaudable: wow 0_o
[08:34] <Private_User> morning all
[09:12] <magespawn> hi dlPhreak
[09:12] <magespawn> unlaudable: no way to recover?
[09:13] <magespawn> hi Private_User
[09:13] <Private_User> hi magespawn
[09:16] <dlPhreak> magespawn: hello
[09:17] <unlaudable> managed to reinstall yum by downloading manually from repos, and did a yum update, it was quite old so there were a lot of updates, so most stuff got reinstalled...
[09:17] <unlaudable> seems to be ok now
[09:17] <unlaudable> rpm --force first  for the yum and yum-utils pkgs
[09:17] <unlaudable> Clearos
[09:17] <magespawn> has anyone heard of NetworkMiner? http://www.netresec.com/?page=NetworkMiner
[09:18] <Kilos> i hear fedora is dropping yum for some new thing
[09:18] <Kilos> or did i dream it
[09:18] <unlaudable> probably could of pointed the repo baseurl at the deprecated directory and done a yum reinstall...
[09:18] <unlaudable> yes
[09:18] <unlaudable> dnf
[09:19] <Kilos> ya that
[09:19] <unlaudable> Dandified Yum
[09:19] <Kilos> ill stick to apt
[09:19] <unlaudable> it's more clever, like it can download and install downloaded packages while its still downloading the rest
[09:42] <anton_may> halo all
[09:46] <Kilos> hi anton_may
[11:24] <unlaudable> figuredout all the missing packages with rpm -V
[11:24] <unlaudable> running yum reinstall on them all... then should be as good as new...
[11:24] <unlaudable> I hope
[17:26] <Kilos> hmm...
[18:28] <superfly> hi Kilos
[18:29] <Kilos> hi superfly we dont have a dseignated leader hey
[18:29] <Kilos> designated
[18:29] <superfly> Kilos: in what way?
[18:29] <Kilos> like egypt has a council
[18:30] <superfly> no, not sure why we need one
[18:30] <Kilos> we used to have one, i forget his nick now
[18:31] <Kilos> we decided we dont need one i think as everyone jumps in when needed
[18:32] <Kilos> maybe other locos arent a bunch of friends like us
[18:53] <inetpro> oom Kilos is our council
[18:53] <inetpro> good evenin
[18:53] <Kilos> nee nee
[18:53] <Kilos> hi inetpro wb
[18:54] <inetpro> hmm... did he go somewhere?
[18:59] <Kilos> well
[18:59] <Kilos> he is rather quiet
[18:59] <Kilos> busy i spose
[18:59] <Kilos> i get busy as well
[19:00] <Kilos> after 9pm im busy sleeping
[19:02] <Kilos> night all.sleep tight
[19:12] <inetpro> ai!


[00:48] <cody-somerville> lol
[00:48] <cody-somerville> Just got this error trying to instantiate a Launchpad object:
[00:49] <cody-somerville> TypeError: __init__() takes at least 4 arguments (4 given)
[00:59] <poolie> :)
[00:59] <poolie> wow
[01:07] <nigelb> Morning!
[01:13] <poolie> hi nigel
[01:13] <nigelb> o/
[01:13] <nigelb> *yawn*
[02:46] <StevenK> nigelb: Diff against target: 2522 lines (+1091/-1038) 8 files modified
[02:49] <nigelb> StevenK: You, sir, are a master :-)
[02:52]  * StevenK still needs to find someone to review it ... :-)
[02:53] <nigelb> Too bad you're OCR today :P
[02:54] <StevenK> I'm so not self reviewing a branch with a 2,500 line diff.
[02:54] <nigelb> lol
[02:54] <nigelb> Look for victims like wgrant :P
[02:58] <StevenK> nigelb: lp:~nigelbabu/launchpad/create-description-5283 is still hanging around, do you need that tossed through ec2 again?
[02:58] <nigelb> StevenK: There's a conflict
[02:58] <nigelb> Working on it today after breakfast and coffee.
[02:58] <nigelb> (Just need to create new sample data again
[02:58] <nigelb> )
[02:58] <StevenK> Like fun you do.
[02:59] <nigelb> :D
[02:59] <StevenK> Sample data needs to die, not be created.
[02:59] <nigelb> Well, sure.
[03:00] <nigelb> I don't want to break all dev machines though.
[03:00] <nigelb> But, what's the alternative to sampledata?
[03:00] <StevenK> Hm? How does no sampledata break dev machines?
[03:00]  * StevenK actually reads the diff.
[03:01] <nigelb> I thought there were legacy tests depending on sample data.
[03:02] <StevenK> I can't see a conflict in the MP
[03:02] <StevenK> And your target should be db-devel
[03:02] <nigelb> I'm pretty sure there's a conflict.
[03:02] <nigelb> I landed a db patch right before this
[03:02] <nigelb> anyway, 20 minutes and I'll post it again :)
[03:02] <StevenK> Uh? That branch *is* the DB patch?
[03:17] <sinzui> StevenK, I added a UI branch that extends the DSP vocab branch I have in review.
[03:18] <StevenK> sinzui: I have reviewed your first branch.
[03:18] <StevenK> sinzui: My mega-branch is up for review
[03:18] <sinzui> fab I will do that now
[03:30] <lifeless> nigelb: you -never- need to add sample data
[03:31] <lifeless> nigelb: you may need to tweak existing (but better to update the test that used it to not use it)
[03:31] <nigelb> lifeless: I only need to run make sampledata and do the replacement thing.
[03:48] <sinzui> nigelb, there are two sampledatas
[03:49] <nigelb> normal and dev?
[03:49] <StevenK> Testing and dev, right
[03:49] <StevenK> I think
[03:49] <sinzui> one (sampledata) is for tests and was frozen 2.5 years ago. No additions, but removals are okay. The other is sampledata-dev and it provides the data for your browser. It is good to provide sane data to look at Lp
[03:50] <StevenK> sinzui: FSVO 'sane'
[03:50] <StevenK> The publication records in sampledata are *wrong*
[03:50] <sinzui> yes!
[03:50] <nigelb> sinzui: "additions" in terms of adding new data or adding new fields?
[03:50] <StevenK> The former
[03:50] <sinzui> note in my last MP I gave instructions to populate the DSP table with proper data
[03:57] <StevenK> sinzui: I'd like to chat tomorrow about my denorm garbo job, by the way.
[03:57] <sinzui> okay
[03:57] <StevenK> It is just making no progress at all.
[03:58] <StevenK> If it isn't postgres backups, it's replication lag, and if it isn't those two, it's process-death-row.
[04:00] <lifeless> StevenK: is pdr doing long transactions ?
[04:00] <StevenK> lifeless: So before Dapper was cashiered out of the librarian, p-d-r took about 30 seconds. Now it takes 90 minutes.
[04:01] <StevenK> And we haven't done any work on it due to lol-maintaince.
[04:02] <StevenK> lifeless: But to be fair, p-d-r is a long third behind slony, backups and replication lag
[04:05] <lifeless> StevenK: ok, so it was fast enough that noone at the time considered one big xaction a problem, and now its not ;)
[04:05] <StevenK> lifeless: We probably need to just fix what it is choking over, TBH.
[04:06] <StevenK> Our represtantion of the archive is not clean in our prod db.
[04:27] <mwhudson> lifeless: so there is exactly one test that breaks if LaunchpadTestRequest sets up a real feature controller
[04:27] <mwhudson> (it's testMemcachedWorking (canonical.testing.ftests.test_layers.ZopelessTestCase), excitingly)
[04:46] <sinzui> StevenK, I could remove the maintainer. We are showing the maintainer because it is assumed that that is the person/team that will like be working with a private bug that you report
[04:47] <sinzui> StevenK, We are showing all the binary package names in the expanded details so that you can see why the source package matched
[04:47] <StevenK> I just think there is more useful information to show besides the maintainer.
[04:47] <sinzui> StevenK, we do not plan to distinguish between package, the bugs about assign to a package make it clear users do not want to think about source and binary
[04:48] <StevenK> sinzui: Oh, is it supposed to be an icon rather than the word?
[04:49] <sinzui> Just the word, to be consistent with the case when we show project group, project, and distribution in target pickers
[04:49] <StevenK> Right
[04:50] <sinzui> Since we are going to show all the binary names, I think the maintainer is the big issue here.
[04:50] <sinzui> StevenK, That value changes if the uploader changes right?
[04:51] <StevenK> Which property of bpr/spr are you using?
[04:53] <sinzui> StevenK, dsp.currentrelease.maintainer.displayname
[04:54] <sinzui> That is the SPR for the current series
[04:55] <StevenK> If maintainer is pulled from the source package itself, it's going to be "Ubuntu Core Developers" for an awful lot of the archive.
[04:58] <sinzui> StevenK, that is interesting. If I were reporting a bug in a future private distro derived from oneiric, are "Ubuntu Core Developers" the group who will be seeing the bug besides the private distro owners?
[04:58] <lifeless> mwhudson: win
[04:59] <StevenK> sinzui: Perhaps. We haven't designed private distros yet. :-)
[04:59] <sinzui> We may need to fix the dsp bug supervisor role/policy which is an old bug
[04:59] <nigelb> Ok, breakfast has been had. Now to finish off those MPs.
[05:00] <sinzui> StevenK, Do you want me to remove the maintainer? Force it to None so that it can be discusses at a later time, or keep it as it is?
[05:01] <StevenK> sinzui: I like the idea of removing it so we can discuss it later.
[05:01] <sinzui> I will remove it
[05:02] <sinzui> StevenK, do you need any more information?
[05:03] <StevenK> sinzui: I think that's it.
[05:03] <sinzui> thanks. I will do this now.
[05:10] <mwhudson> argh everything is horrible
[05:10]  * mwhudson gives up for today
[05:11] <nigelb> Launchpad - "argh everything is horrible"
[05:12] <StevenK> Sounds right to me.
[05:14] <nigelb> grar
[05:14] <nigelb> I should redo this entire branch.
[05:15] <StevenK> It sometimes comes to that.
[05:15] <StevenK> bzr di > /tmp/foo ; cd .. ; rm -rf <branch>
[05:15] <nigelb> hrm. Ouch
[05:15] <nigelb> I deleted that as well.
[05:16] <StevenK> The fact that I typed it quickly is in no way a sign of how often I do that ...
[05:17] <nigelb> I did, however, save the db patch file.
[05:17] <nigelb> So, if I'm not mistaken, all is not lost :D
[05:17] <StevenK> If the branch is still on LP, you can grab it again
[05:18] <nigelb> It is \o/
[05:18] <nigelb> DVCS++
[05:18] <nigelb> Reminds of the poor soul in this one http://programmers.stackexchange.com/questions/112270/small-company-15-developers-doesnt-use-managed-source-version-control-is-thi
[05:20] <StevenK> nigelb: Cold sweat.
[05:21]  * StevenK resubmits his MP, due to the diff going from 243 lines to 2788 ...
[05:23] <nigelb> when I add a column, do I force default NULL or do I just leave it alone?
[05:24] <nigelb> ohwait. This has db ack.  I should not be worrying about this.
[05:26] <nigelb> help -> http://paste.ubuntu.com/702588/
[05:27] <StevenK> bin/py doesn't exist, run make
[05:27] <nigelb> ah
[05:28] <nigelb> grr
[05:28] <nigelb> Getting distribution for 'txlongpollfixture==0.1.3'.
[05:28] <nigelb> make: *** [/home/nigelbabu/launchpad/lp-branches/create-description-5283/bin/py] Error 1
[05:28] <StevenK> rf-get
[05:28] <nigelb> already started :)
[05:28] <StevenK> Or update your download-cache
[05:28] <StevenK> Either way, blame Red Squad
[05:28] <nigelb> I was about to say #blame-bigjools but that works :D
[05:29] <StevenK> Right, I think that MP is squared away until the previous pipe lands and wgrant re-surfaces.
[05:31] <nigelb> Is he off this week?
[05:32] <StevenK> No, just today.
[05:32] <nigelb> He should be online in an hour :P
[05:33] <StevenK> Perhaps. I know what he's doing today, and he may not be.
[05:33] <nigelb> Ah.
[05:34] <nigelb> Do you both live in the same city btw?
[05:34] <StevenK> No, wgrant is in Melsbum.
[05:35] <nigelb> And you?
[05:35] <StevenK> Sydney
[05:35] <nigelb> AH
[06:57] <wgrant> StevenK: Is the refactoring pipe reviewed?
[07:03] <poolie> stub, if you can also give any suggestions on how to improve bug 868021 i'd appreciate it
[07:04] <_mup_> Bug #868021: +affectingbugs times out <affectsmetoo> <bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/868021 >
[07:04] <stub> poolie: I've already added some reworked queries there.
[07:04] <poolie> :)
[07:04] <stub> poolie: Bringing a 9s query down to subsecond. I haven't gone over the OOPS report now it should have synced.
[07:07] <poolie> really 868021?
[07:07] <poolie> the other similar one, 866100, we tried your queries and they're generally good but intermittently slow
[07:08] <poolie> perhaps in a way that varies by db server
[07:11] <stub> Sorry, thinking of the other bug
[07:11]  * stub looks
[07:11] <StevenK> wgrant: The pre-req branch was +1'd by Curtis.
[07:11] <StevenK> wgrant: I had to resubmit the second branch because of it, so it needs your +1 again.
[07:12] <stub> poolie: I suspect fixing Bug 866100 would address Bug 868021 too
[07:12] <_mup_> Bug #866100: bug search with affects_me=on times out <affectsmetoo> <bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/866100 >
[07:12] <_mup_> Bug #868021: +affectingbugs times out <affectsmetoo> <bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/868021 >
[07:12] <wgrant> StevenK: Ah, great. Will hopefully look later tonight.
[07:13] <poolie> stub, yes i wasn't sure whether it made sense to split them or not
[07:13] <StevenK> wgrant: I'm in no rush, since I want the pre-req to land first.
[07:13] <poolie> but since the conversation was getting a bit long i thought i would split
[07:14] <stub> poolie: separate bugs could be fine, but I'd tackle the simpler case first.
[07:15] <poolie> and 866100 is simpler?
[07:15] <poolie> ok great
[07:19] <stub> poolie: 866100 is simpler because I've done diagnosis :-)
[07:20] <stub> poolie: I'm just assuming 868021 may be fixed as a side effect, as the trigger condition is the same (bugaffects clause)
[07:25] <nigelb> StevenK: lol, wgrant did come online in about 1.5 hours :D
[07:27] <wgrant> Indeed!
[07:51] <allenap> nigelb: Your download-cache is out of date.
[07:51] <nigelb> allenap: yeah, fixed that.
[07:51] <allenap> nigelb: Cool :)
[07:53] <bigjools> morning everyone
[07:54] <nigelb> Hello bigjools!
[07:54] <bigjools> hey nigelb
[07:56] <nigelb> Hrm
[07:56] <nigelb> someone changed 2010 to 2010-2011 in current.sql
[07:56] <nigelb> Is a better fix to fix whatever generates newsampledata.sql?
[08:01] <mrevell> Hello
[08:02] <nigelb> Hey mrevell :)
[08:25] <nigelb> StevenK: ohai, still around?
[08:29] <StevenK> nigelb: Barely
[08:30] <nigelb> StevenK: oh. I was just about to put that MP into your queue. Nevermind, I'll catch the euro train :)
[08:48] <nigelb> allenap: Hi, OCR'ing today? :)
[08:54] <allenap> nigelb: My day is tomorrow... let me see who's on call...
[08:56] <allenap> nigelb: danilos is down for the EU slot today (jtv too, but he's away). Aaron is on later. If it's something small I don't mind taking a look though.
[08:57] <nigelb> allenap: bah, right. My bad. I looked at Thu instead of Wed.
[08:58] <nigelb> Its an approved db patch which I couldn't land because of conflicts - https://code.launchpad.net/~nigelbabu/launchpad/create-description-5283/+merge/76818
[08:58] <nigelb> I made one extra change in database/schema/Makefile
[09:27] <danilos> allenap, thanks for the reminder :)
[09:30] <danilos> nigelb, btw, why did you not just merge the db-stable instead of starting from scratch?
[09:31] <nigelb> danilos: Well, I screwed up massively :D
[09:31] <danilos> nigelb, right, but in this case, I'd have to ask you to make a new merge proposal and get patches reviewed again, because we can't tell if they are the same or not
[09:32] <nigelb> ahhh.
[09:32] <nigelb> db review?
[09:32] <danilos> nigelb, yeah, db review as well
[09:32]  * nigelb does that.
[09:34] <nigelb> *faceplam*
[09:34] <nigelb> why did I just delete the branch.
[09:34] <danilos> nigelb, btw, did you use "bzr push --overwrite" for this?
[09:34] <nigelb> danilos: I did.
[09:35] <danilos> nigelb, right, well, that makes any merge proposals you've got invalid since you are changing the branch history behind LP's back :)
[09:35] <danilos> nigelb, whoops :)
[09:35] <nigelb> danilos: Ah. Drat. Anyway, its nicer this way.
[09:36] <danilos> nigelb, nicer? if you are refering to "bzr push --overwrite", it's not, just a simple "bzr merge lp:~launchpad-pqm/launchpad/db-stable && resolve conflicts && bzr ci -m 'Merge db-stable.'" is the best thing to do
[09:37] <danilos> nigelb, the thing you did was basically rebasing, bzr doesn't require that at all :)
[09:37] <danilos> nigelb, and your revision will end up as one revision when it's finally merged anyway
[09:37] <nigelb> well, at some point of cleaning this up, I lost of track of what I was doing.
[09:38] <nigelb> But yeah, noted for next time.
[09:38] <nigelb> stub: hi, around?
[09:38] <nigelb> stub: Need a re-ack of a db patch because I messed it up :)
[09:39] <danilos> nigelb, I am sorry to cause you more work :/
[09:40] <nigelb> danilos: heh, np. I think I shot myself in the foot there :D
[09:48] <nigelb> https://code.launchpad.net/~nigelbabu/launchpad/create-description-5283/+merge/78220
[11:55] <nigelb> mrevell: around?
[11:56] <mrevell> I certainly am nigelb
[11:56] <nigelb> mrevell: I was reading about Open Badges, it certainled seemed interesting to think of LP giving out badges for certain things - http://openbadges.org/About/
[11:56] <nigelb> *certainly
[11:57]  * mrevell looks
[11:57] <mrevell> Hmm, interesting.
[11:57] <G> nigelb: do systems like that really do anything though?
[11:58] <nigelb> G: Well, this is the first such system.
[11:58] <G> nigelb: I can understand in the context of Four Square, but in software development, I'm not sure
[11:58] <nigelb> Its about showing your achivements in learning/coding.
[12:03] <G> nigelb: the way I personally see it (and this is my own warped mind) but I think that sorta stuff is just 0 value fluff
[12:03] <nigelb> G: Well, karma is 0 value as well.
[12:03] <nigelb> I'd like to able to show off my skills
[12:03] <nigelb> Like coderwall
[12:03] <nigelb> Or like stackoverflow
[12:59] <nigelb> Hrm, what does fixing bug 184737 involve?
[12:59] <_mup_> Bug #184737: No tag autocomplete or official list in +filebug extra options <bugtag> <filebug> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/184737 >
[13:00] <nigelb> I think there's some code I can reuse from the tag autocomplete in the bug's index page
[13:27] <nigelb> gary_poster: tech-debt helps. I often look into it for bugs to fix :)
[13:27] <gary_poster> nigelb, cool :-)  please reply with that note then
[13:32] <nigelb> Whoever did the logpoll documentation has a *lot* of patience.
[13:32] <nigelb> The diagram is ascii is pretty awesome
[13:32] <rvba> nigelb: ;)
[13:39] <deryck> Hi adeuring.  I didn't ping for the standup.  I assumed you weren't around until top of the hour.  Sorry.
[13:39] <deryck> adeuring, just noticed you here :)
[13:39] <adeuring> deryck: ok, I'll join
[13:40] <deryck> adeuring, oh, we're done now.
[13:40] <adeuring> deryck: yeah, noticed that too :) no problem
[13:40] <deryck> adeuring, I was apologizing for not inviting you in. :)
[13:58] <deryck> abentley, adeuring -- ready for skype?
[13:58] <adeuring> deryck: yes
[13:58] <abentley> deryck: yes
[13:58] <deryck> restarting… you guys don't show for me
[13:59] <abentley> deryck: I've had that plenty.  Just call me anyway.
[13:59] <deryck> abentley, we don't hear you.  hear us?
[14:00] <abentley> deryck: yes.
[14:00] <abentley> deryck: grr
[14:01] <deryck> abentley, should we drop you and add you back?
[14:01] <abentley> deryck: sure.
[14:03] <mrevell> Hey sinzui?
[14:37] <danilos> sinzui, hi, did you ever figure out the oneiric librarian problem?
[14:37] <sinzui> no I did not
[14:53] <sinzui> matsubara, http://pastebin.ubuntu.com/702790/ the top 12 bugs
[14:53] <matsubara> thanks sinzui
[15:05] <deryck> abentley, mumble?
[15:34] <bac> abentley: are you OCR today?
[15:38] <sinzui> gary_poster, I do not think anything should high in launchpad-results. cr3 created it we may maintain it, but we never hack on it
[15:38] <timrc> approximately how long do the code updates on staging take?
[15:38] <timrc> and is there a notification system for updates so I can plan around it?
[15:38] <gary_poster> sinzui: oh, we maintain it?  I thought this was kind of an odd triaging experiment for traiging someone elses code
[15:39] <gary_poster> where "odd" means "I don't care for it" :-)
[15:39] <sinzui> oh, we do not maintain it
[15:40] <gary_poster> timrc, I'm not sure, but IIRC staging is having a long outage because of some db issues
[15:40] <gary_poster> where long means 24 hours AFAIK
[15:40] <sinzui> gary_poster, This is a case of community vs organisation. Like most canonical project groups. ours is intended to be what we own. but anyone can add their project to someone elses project group.
[15:40] <timrc> noooo
[15:40] <gary_poster> normally I assume updates are similar to qastaging: just a few minutes
[15:40] <sinzui> gary_poster, The consequence of this is that we are triaging their bugs.
[15:40] <sinzui> This is bad
[15:41] <gary_poster> agreed sinzui
[15:41] <sinzui> ~launchpad-results needs to do this, maybe he should remove this project from our project group
[15:42] <gary_poster> sinzui, if we want the policy of "just triage other peoples bugs as low" I guess that is fine with me, though I think that policy should be publicized.    I'll make arbitrary decisions."  I thought Francis spoke with Marc about this already and for some reason they agreed it would stay where it is
[15:43] <sinzui> okay
[15:44] <gary_poster> but I really just agree with you: I wish it were not
[15:44] <cr3> sinzui: someone suggested that maybe launchpad-results shouldn't be under ~launchpad, but there was a wiki page about projects related to launchpad saying otherwise. I've been meaning to touch base with lifeless about it but haven't gotten around to it
[15:44] <gary_poster> cr3, the only reason I care in this case is that it means we triage your bugs, because we are supposed to drive the count to zero
[15:44] <gary_poster> So I stomp on you
[15:45] <gary_poster> And don't like it :-(
[15:46] <sinzui> cr3, This is a common problem. The problem is that project groups look like communities, but all the code implies it is organisations. We are still discussing the removal of groups
[15:47] <cr3> gary_poster: since this is a recurring problem, I could remove launchpad-results being "part of" launchpad-project and maybe we could change that again later
[15:48] <gary_poster> bigjools, you around?  I've tried to figure out what to do with https://bugs.launchpad.net/launchpad/+bug/868366 but simply don't understand enough.  Could you let me know what you think about triage?
[15:48] <_mup_> Bug #868366: Diff from current Ubuntu version to current Debian version pending sync missing from +localpackagediffs page <Launchpad itself:New> < https://launchpad.net/bugs/868366 >
[15:48] <cr3> done, I hope that helps a bit drive your bug count to zero... a good source of inspiration for me too :)
[15:49] <gary_poster> cr3, thank you. :-) we drive *triage* count to zero every day, which is what this is about.  sadly, not so much for the bug count
[15:49] <cr3> gary_poster: an unfortunate side effect is that your drive was a bit contagious being part of your group :)
[15:49] <bigjools> gary_poster: sure thing
[15:49] <gary_poster> cr3 lol
[15:49] <gary_poster> thanks bigjools
[15:50] <cr3> gary_poster: I agreed to try and adhere to your policy of driving the triage to zero for launchpad-results but I don't quite have the same level of vanguard as your team :(
[15:50] <gary_poster> cr3, you are a team of 1 for this, right?  Understandable, I think.
[15:51] <cr3> gary_poster: an army of 1! :)
[15:51] <gary_poster> :-)
[15:54]  * gary_poster must go babysit during lunch. :-)  biab
[15:55] <abentley> bac: theoretically, but we have three job interviews today, so I haven't been able to do any.
[15:57] <deryck> abentley, Skype time.
[15:58] <abentley> deryck: online.  Even if it doesn't look like it.
[16:00] <abentley> deryck: had to restart skype.  b
[16:00] <abentley> deryck: back online.
[16:14] <sinzui> jcsackett, mumble?
[16:14] <jcsackett> sinzui: sure.
[16:34] <deryck> abentley, he called me on regular skype
[16:34] <deryck> abentley, adeuring adding you back now
[16:34] <abentley> deryck: cool
[16:34] <adeuring> ok
[17:04] <timrc> has any one experienced random failures with syncSources()? I tried syncing a package between two ppas it failed the first time and succeeded the second time.
[17:04] <timrc> this is on production
[17:05] <timrc> http://paste.ubuntu.com/702853/
[17:05] <timrc> it looks like a BadRequest exception was raised
[17:07] <timrc> hm, actually, there is an oddity and so now I'm leaning towards a bug in my code
[17:07] <timrc> wait, was looking at wrong ppa, back to thinking it's a problem with launchpad
[17:23] <sinzui> gmb r=me
[18:17] <lifeless> yawn, morning
[18:18] <lifeless> cr3: hi
[18:20] <cr3> lifeless: hola senor
[18:20] <lifeless> you invoked me earlier ;)
[18:21] <cr3> lifeless: you might've noticed I mentionned your name earlier, do you think launchpad-results should be a "part of" launchpad-project?
[18:21] <cr3> lifeless: the problem we've encountered is that the ~launchpad folks are driving bug triage to zero more quickly than me, so the bugs for launchpad-results are appearing on your radar
[18:21] <lifeless> cr3: given your goals, definitely :) - that is, becoming a component, with ui in the main tree, backend as a microservice etc.
[18:22] <lifeless> cr3: what makes that a problem ?
[18:22] <lifeless> (it sounds like a benefit to me :))
[18:22] <cr3> lifeless: the "radar" part seems to be a problem where folks on launchpad have felt the need to set the status to triaged but feeling uncomfortable doing so on behalf of a project they are not familiar with
[18:23] <cr3> lifeless: it has more than benefited me, it has actually inspired me to keep up with the same level of bug management as launchpad, but I'm afraid about the making others uncomfortable part which makes me uncomfortable as a result :)
[18:24]  * lifeless blinks
[18:24] <lifeless> cr3: the lp CHR gets uncomfortable ?
[18:24] <cr3> lifeless: CHR?
[18:24] <lifeless> the rota
[18:25] <lifeless> (the folk doing bug triage do so on a rota basis, sharin the load around)
[18:25] <cr3> lifeless: still lost me, rota == person on rotation, ie vanguard?
[18:25] <cr3> lifeless: it seems like they're seeing bugs against launchpad-results and the general reaction is: wtf!
[18:25] <lifeless> ok
[18:25] <lifeless> have you read https://dev.launchpad.net/BugTriage ?
[18:27] <cr3> lifeless: I think I did but I'll read it again. I remember at some point I read something and agree to follow the same process as launchpad, not to make you guys happy as much as because it would benefit the launchpad-results project to follow such a process :)
[18:27] <lifeless> righto
[18:27] <lifeless> so the next question was, have you been happy with the results of the lp team doing triage in -results ?
[18:27] <cr3> lifeless: however, I haven't been quite as fast at triaging bugs as the CHR. there's also the importance of bugs to consider, "high" just for launchpad-results might mean something different than "high" for the launchpad project as a whole
[18:27] <lifeless> e.g. are they identifying high/critical/low for you sensibly ?
[18:28] <cr3> lifeless: I've been happy and I've tried to return the favour as best I can, but there's also the above mentionned problem about importance that might need some tweaking
[18:28] <lifeless> cr3: I think we want to avoid having different rules; but the rules in BugTriage should be broadly compatible.
[18:29] <lifeless> cr3: if (say) most of the time the triager gets it right, and you need to tweak some to be accurate - thats fine [that happens within LP too]
[18:29] <cr3> lifeless: ok, so "high" would mean the same to all of us: likely to get attention within the next six months, no matter which team actually does the fixing
[18:30] <lifeless> yes; the folk doing triage are expected to be *broadly* aware of projects underway across LP (otherwise we could use a bot and make everything not-critical low :P)
[18:31] <cr3> lifeless: sounds good to me, I removed launchpad-results from launchpad-project earlier but I'll add it again. thanks for making sense of all this! :)
[18:31] <lifeless> so I don't think we would want - or be able to sustain - different rules for -results. OTOH I think the same rules should work for -results :)
[18:31] <lifeless> cr3: have you announced on -dev that it was part of -project, and the consequences? (Or would you like Francis or I to do so ?)
[18:32] <cr3> lifeless: perhaps I should do that myself so that I could answer most questions as a result
[18:33] <cr3> thanks for offering though, it makes the project feel welcome :)
[18:34] <lifeless> good!
[18:40] <lifeless> flacoste: did you see http://h30565.www3.hp.com/t5/Feature-Articles/Innovate-or-Suffer-Slow-Brain-Asphyxiation/ba-p/499 ?
[18:41] <flacoste> lifeless: i saw, didn't read it yet though
[18:42] <lifeless> worth a quick read, I think you'll nod in agreement all the way through; some nice physiological references connected to reward programs.
[18:42] <lifeless> flacoste: you may want to chase those for your upcoming task ;>
[18:53] <flacoste> lifeless: i actually start researching the issue, and found the evidence-based management work of Pfeffer and Sutton very interesting
[19:11] <sinzui> jcsackett, gary_poster is bragging about his madd html5 cross-domain scripting skillz. Maybe you want to talk to him about bug 823471 and get his comments on to the bug
[19:11] <_mup_> Bug #823471: privacy ribbon does not appear on secondary sites <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/823471 >
[19:12]  * gary_poster snorts
[19:12] <jcsackett> sinzui: did you just actually use "mad skillz"?
[19:12] <jcsackett> :-P
[19:12] <sinzui> My fingers did
[19:12] <jcsackett> sure, blame it on the fingers. :-P
[19:13] <jcsackett> gary_poster: you likely to be free tomorrow morning-ish to talk about cross-domain scripting?
[19:14] <gary_poster> jcsackett, on call, and not quite clear on what you want, but happy to talk later.  Sure, sounds good.  It would be late morning--I have a call at 9 and one at 10, so 10:30 or 11
[19:14] <jcsackett> works for me. i'll ping you tomorrow then. :-)
[19:14] <gary_poster> cool jcsackett, I look forward to it
[20:34] <sinzui> lifeless, may I call you on skype?
[20:34] <lifeless> sinzui: I will ping you in ~5, gotta wrap ELOCAL with the cats.
[20:34] <sinzui> okay
[20:42] <lifeless> sinzui: ping
[20:43] <sinzui> calling
[21:37] <lifeless> sinzui: ping
[21:46] <lifeless> sinzui: I am back, should you wish to continue
[21:46] <lifeless> sinzui: I am going to start digging into updating LP for the latest round of oops changes, so just call me on skype whenever
[22:09] <mwhudson> any reviewer around? https://code.launchpad.net/~mwhudson/launchpad/unconditionally-endInteraction-after-test/+merge/78324
[22:10] <mwhudson> i guess abentley is no longer on call, seeing as he is not online any more
[22:14] <StevenK> mwhudson: r=me
[22:14] <StevenK> mwhudson: Sorry, I was waiting for the diff to update.
[22:14] <mwhudson> ah right yeah
[22:14]  * lifeless closes the window
[22:15] <mwhudson> the update was removing exactly two empty lines :-)
[22:15] <mwhudson> thanks!
[22:16] <mwhudson> i wonder why ec2 test remangles the postgres config each time
[22:16] <mwhudson> surely that could be done in the image?
[22:16] <mwhudson> ah well
[22:24] <lifeless> sinzui: (hi)
[22:24] <sinzui> lifeless, hi. wgrant and I will want to talk to you on skype shortly
[22:24] <lifeless> ok
[22:28] <micahg> so, I need to have multiple teams be non-members so as to not grant upload rights, is the only way to do this currently to make a single team containing the others set as owner?
[22:28] <wgrant> micahg: The owner of a PPA primarily indicates upload rights.
[22:29] <wgrant> micahg: If people should not have upload rights, they are not the owner.
[22:29] <micahg> wgrant: sorry, this is for the archive, not PPA
[22:30] <micahg> owner of a team w/upload rights  doesn't grant upload rights to the archive
[22:30] <wgrant> "I need to have multiple teams be non-members so as to not grant upload rights"
[22:30] <micahg> right :)
[22:30] <wgrant> I'm confused.
[22:30] <wgrant> Just don't add them to the team?
[22:30] <micahg> wgrant: so, these teams need to administer, but not gain rights
[22:31] <micahg> example: DMB and Edubuntu Council can approve edubuntu-dev, but neither team should have upload rights to the edubuntu packageset
[22:32] <wgrant> You'll need to create a new team, right.
[22:42] <micahg> is it worth filing a bug for a feature request to have multiple non-member admins?
[22:52] <lifeless> sinzui: I am here when you want me
[22:53] <sinzui> lifeless, I will start dinner near. wgrant and wallyworld_ will be ready in about an hour
[22:56] <lifeless> kk
[23:05] <lifeless> stub: how goes slonyI-2?
[23:08] <stub> Migration process all thought through. Mulling over how to best do the migration script so it runs with as little modification on production after testing on staging.
[23:08] <lifeless> woo
[23:08] <wgrant> We're not just going to dump and rebuild the slaves?
[23:08] <wgrant> s/dump/nuke/
[23:09] <stub> We could, or we could make use of the Slony-ii 2.0 feature that lets us skip that.
[23:09] <lifeless> what are the tradeoffs?
[23:09] <stub> 'subscribe, and btw. all the data is already there and up to date so no need to recopy it'
[23:10] <wgrant> Oh.
[23:10] <stub> lifeless: If we rebuild the slaves, they are freshly packed. But better to do that one at a time after the update anyway.
[23:10] <wgrant> Didn't know it could do that.
[23:11] <lifeless> stub: if a slave is not identical, will slony as a whole barf, or just that node ?
[23:11] <lifeless> stub: (at the first inconsistent update, I mean)
[23:11] <stub> lifeless: We won't know about it until the first inconsistent update, at which point that slave will stop replicating.
[23:11] <lifeless> ok
[23:12] <wgrant> But that's no worse than would happen if it were inconsistent already.
[23:12] <stub> The migration scripts are more complex though, as we will be dealing with all 7 nodes instead of just the 2 master nodes.
[23:13] <wgrant> Will we have to run SSO from a detached slave for the duration, or can we install it live?
[23:13] <stub> SSO has some sort of read only mode it uses, and the downtime should only be a minute or two anyway.
[23:13] <wgrant> Right, but it presumably needs an accessible slave :)
[23:14] <stub> I dunno. It always seemed problematic before and we do so few updates to that system it is always new and exciting.
[23:14] <wgrant> Heh.
[23:15] <stub> Might be pulling stuff in from cache.
[23:15] <wgrant> I don't know what the SSO SLA is these days.
[23:15] <wgrant> I suspect its availability hardly exceeds Launchpad's new process, though.
[23:20] <lifeless> hmm, need a new storm code drop
[23:20] <lifeless> not today.
[23:21] <wgrant> 0.19's about to be released, did you see?
[23:22] <wgrant> lifeless: Also, set_up_tacfile_logging is terribly buggy and responsible for a number of poppy-sftp issues.
[23:22] <wgrant> So any attempt to remove it would be most welcome.
[23:23] <wgrant> Oh, 0.19 is actually out now.
[23:24] <StevenK> They've actually made a storm release?
[23:25] <wgrant> Not quite a year since the last one.
[23:25] <lifeless> sure, I've made some notes about how in the bug
[23:25] <lifeless> I think a good twisted component is the first step
[23:26] <lifeless> .
[23:38] <StevenK> wgrant: You were saying something about parent class ordering for my branch?
[23:39] <wgrant> Oh right.
[23:42] <wgrant> Bear with me, Optus is only routing some of the DC subnets.
[23:43] <wgrant> StevenK: BasePesronEditViewWidget? Why not just put it in BasePersonEditView?
[23:43] <wgrant> Otherwise it should be something about checking renames, not BasePersonEditViewWidget.
[23:44] <StevenK> Because TeamEditView also needs it
[23:44] <wgrant> Also, remember that the MRO is first base class to last.
[23:44] <wgrant> So you probably want that setUpWidgets mixin early in the base list.
[23:44] <StevenK> And I wasn't sure about the schema set in BasePersonEditView
[23:45] <StevenK> wgrant: So if you think using BasePersonEditView is okay for both, I'm happy to try it.
[23:45] <wgrant> I'm not sure what's in it.
[23:46] <wgrant> But the current name is silly, and it would be handy if we didn't have a dozen base classes shared between those views when we only need one.
[23:46] <StevenK> A schema, fields, action_save and next_url
[23:52] <wgrant> StevenK: Perhaps a PersonRenameFormMixin?
[23:53] <StevenK> wgrant: I've put it into BasePersonEditView, what could possibly go wrong.
[23:54] <StevenK> Bah
[23:54] <StevenK> BasePersonEditView defines field_names as [], and TeamFormMixin as a large array


[06:27] <nacc> rbasak: with the importer-rework branch as of right nonw, the ipsec-tools reimport is down to 35 minutes pretty consistently
[07:49] <lordievader> Good morning
[10:34] <cpaelzer> rbasak: could it be that if something is only pushed in -security the importer misses it?
[10:34] <cpaelzer> rbasak: take a look at iscsitarget in trusty
[10:35] <cpaelzer> nacc: ^^
[10:39] <rbasak> cpaelzer: could be. But we're in the middle of quite a bit change in logic around how the importer picks up on changes, and the importer is still running the old code currently. So let's see if the problem remains after we've landed our changes :)
[10:39] <rbasak> We don't currently have tests for this area of code (not yet faking Launchpad publications for testing)
[10:40] <cpaelzer> rbasak: is there abug on the rewrite that I could register a "please test this after the rewrite" on?
[10:45] <cpaelzer> rbasak: I know we have a set of known to import with issues - I assume you'll look at those
[10:45] <cpaelzer> just would want to add that there
[10:45] <cpaelzer> so that we remember
[10:49] <rbasak> cpaelzer: we don't have a bug for the rewrite. It's part of our "LP beta" milestone. We could create a bug, but would it be better to have a bug for this distinct issue?
[10:49] <cpaelzer> I'm fine to open one
[10:49] <cpaelzer> it is mostly a reminder to check
[10:49] <rbasak> It's a good idea
[12:25] <ali1234> right, who can tell me exactly why unattended-upgrades is not doing anything on my 16.04 server?
[12:26] <ali1234> it runs twice every day but never installs anything
[12:27] <ali1234> if i run it manually with --dry-run it outputs a list of packages to upgrade, in all other cases it outputs nothing
[12:28] <ali1234> that is, when run automatically
[12:28] <ali1234> actually, last thing it outputs is "allowed origins:..."
[14:32] <jamespage> coreycb: btw I'm tending the addtional backports needed for Queens UCA...
[14:37] <coreycb> jamespage: ok
[15:42] <nacc> rbasak: it depends on timing
[15:42] <nacc> cpaelzer: --^
[15:49] <nacc> cpaelzer: rbasak: so ... i'm not 100% on this, but this is my theory: iscsitarget was published on 7/17. It's possible we missed that evet. We don't catch it up again, because it's no longer published. The linear script walker would catch this, but the version we ran didn't look in older releases (the new one does for all active series).
[15:49] <nacc> so i thinnk it's fix released a la the new scripts
[15:52] <nacc> cpaelzer: were you asking re: LP: #1732918 ?
[17:42] <faekjarz> Hi! I'm anoyed, is it normal to take over 3 minutes to draw all the lines, at about 0.3 - 0.5 lines per second, of a "dmesg" on an ASPEED AST2400? Can i accellerate this? …modprobe …somethingsomething
[17:58] <faekjarz> …i'm not even doing IPMI (iKVM) over a slow connection …i'm directly connected to the box (VGA & USB) …this is my 1st time using a mobo with an Aspeed AST2400 BMC / GPU …is this normal?
[18:00] <nacc> faekjarz: not sure why that'd be an ubuntu issue?
[18:01] <nacc> faekjarz: do you know the BMC can dispaly faster? BMCs are not often about speed (ime)
[18:03] <faekjarz> nacc: because i'm not sure what distros include what drivers, and because i'm using Ubuntu …tadaah, here i am, asking whether i might have missed modprobing something
[18:04] <nacc> faekjarz: i meant, do you know it's not a hardware limitation?
[18:06] <faekjarz> i'm not sure, it's my 1st time using an A-"SPEED" thing (it's an Asus P10S-M) …seems like a misnomer, haha …i'm just double-checking
[18:13] <faekjarz> maybe i sould specialise in Aspeed based boards and enjoy all the free waiting time while getting paid for tech support
[18:15] <BlessJah> is AWS image naming convention ducumented anywhere?
[18:15] <nacc> Odd_Bloke: rcj: --^ maybe you know?
[18:16] <BlessJah> related: https://bugs.launchpad.net/cloud-images/+bug/1458825
[18:18] <nacc> BlessJah: is that bug actually accurate. I do't see the term "root store" on that URL.
[18:32] <BlessJah> nacc: there is "Instance type" field in image locator, it takes values listed in the bug
[18:32] <BlessJah> And the AMI name has cryptic "ebs-ssd": ubuntu/images/ebs-ssd/ubuntu-xenial-16.04-amd64-server-20171026.1
[18:33] <BlessJah> It's more or less obvious what it means, but there is lot of other images that do not follow the convention.
[18:34] <nacc> BlessJah: i'd say the bug needs to mention that, imo. Right now it says the "cloud images" download pages ... and then gives a URL that is not about AMIs.
[18:34] <nacc> BlessJah: if the issue is with the AMIs, that should be specified in the bug, right now it reads like the cloud-images page is wrong.
[19:51] <BlessJah> I'll talk to Faux to get that clarified.
[19:51] <nacc> BlessJah: not super urgent, i suppose :)
[19:51] <BlessJah> And what about thr documentation regarding image name conventions?
[19:51] <nacc> BlessJah: i mean your request might be orthogonal to that bug report
[19:52] <nacc> BlessJah: i pinged who i thought might help, i'd just wait
[19:52] <nacc> BlessJah: i'm not personally involved
[19:53] <nacc> rbasak: fyi, running the gnome-shell import locally from beta/edge snap, it does what it should (braches are being updated) so i assume cpaelzer did a skip-applied import
[19:53] <BlessJah> nice try, you're already knee-deep in this
[19:53] <nacc> BlessJah: :)
[19:53] <BlessJah> ;>
[19:54] <nacc> smoser: --^ do you possibly know?
[19:54] <nacc> smoser: how the AMIs get named and why they are named as they are
[19:58] <smoser> BlessJah: well, if you want to convert the values we have on cloud-images.ubuntu.com to whatever amazon's official values are just use DescribeImages on the image
[20:00] <BlessJah> I want to know how what different names (image/milestone/image-dev) mean and what filter to write to get image I want
[20:02] <smoser> BlessJah: well, milestone ?
[20:02] <smoser> i think you mean label
[20:02] <smoser> what is image-dev ?
[20:07] <BlessJah> prefixes for trusty: ubuntu/images/ubuntu-trusty-..., ubuntu/images/ebs/ubuntu-trusty-..., ubuntu/images/ebs-ssd/ubuntu-trusty-..., same for ebs-io1, ubuntu/images-testing/ubuntu-trusty-...,
[20:07] <BlessJah> but yes, there is no -dev
[20:07] <smoser> ah
[20:07] <smoser> ignore taht
[20:08] <nacc> lol
[20:08] <nacc> smoser: did you see the bug referred to above?
[20:08] <smoser> yeah.
[20:08] <nacc> smoser: ok, just wanted to check
[20:09] <BlessJah> ubuntu/images/ubuntu-xenial- ubuntu/images/hvm-ssd/ubuntu-xenial- ubuntu/images/hvm-instance/ubuntu-xenial- ubuntu/images/ebs-ssd/ubuntu-xenial- ubuntu/images-testing/ubuntu-xenial- ubuntu/images-testing-dev/ebs-ssd/ubuntu-xenial-
[20:09] <BlessJah> xenial, that's where I've seen dev
[20:11] <BlessJah> some documentation somewhere explaining why images have names that they have and a promise that convention won't suddenly change, would be nice to have that
[20:12] <smoser> http://paste.ubuntu.com/25983212/
[20:12] <smoser> dont use names.
[20:12] <smoser> use the stream data.
[20:13] <smoser> sstream-query  --keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg  --max=1  "--output-format=%(release)s  %(label)s  %(root_store)s  %(virt)s  %(id)s"  http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:aws.sjson  region=us-east-1  release~(trusty|xenial|zesty|bionic)
[20:13] <smoser> or i guess easier if you use https
[20:13] <BlessJah> How do I glue that to terraform?
[20:15] <smoser> i'm sorry i dont know.
[20:15] <smoser> but that is how you "find the right ami".
[20:16] <smoser> the only variables currently supported (xenial+) are
[20:17] <BlessJah> What is that data stream thing?
[20:17] <smoser> root_store=(instance|ssd) virt=(pv|hvm)
[20:17] <smoser> it is "simplestreams" format. which is horribly documented.
[20:18] <smoser> i'm the author, so its ok for both you and i to say that.
[20:18] <nacc> https://help.ubuntu.com/lts/serverguide/cloud-images-and-uvtool.html ahs some mention
[20:18] <smoser> but that is how we publish data bout clouds
[20:18] <nacc> and there is a launchpad project
[20:18] <smoser> and that is how juju finds image ids
[20:18] <BlessJah> what was wrong with tags and naming conventions?
[20:19] <smoser> a.) naming conventions and you parsing strings sucks (and as you can see over 10 years that kind of fell apart).
[20:19] <smoser> b.) we publish data on all public clouds on ubuntu.com
[20:20] <BlessJah> I get that it's very convenient for juju devs, but it breaks other tools like terraform
[20:20] <smoser> we definitely could tag on amazon, an there might have developed conventions there over time
[20:20] <smoser> so there is some convetion on tags ?
[20:20] <smoser> and that only works on amazon
[20:20] <smoser> not on azure
[20:21] <smoser> or gce or bobs-cloud
[20:21] <nacc> oooh bobs-cloud
[20:21] <nacc> like bobs-burgers
[20:21] <nacc> i'd cloud there
[20:21] <smoser> there are definitely improvements (very much so for doc) that we could make and should  make.
[20:22] <smoser> but we set out to provide information about getting ubuntu wherever you need it.
[20:22] <smoser> the data is available over https or http with gpg signatures inline.
[20:23] <nacc> the poitn being it's not contingent on the cloud provider to be consistent with ubuntu
[20:23] <nacc> ubuntu is consistent with itself :)
[20:23] <smoser> BlessJah: is there some convention for tagging images now ?
[20:23] <smoser> that terraform can read ?
[20:24] <BlessJah> smoser: terraform uses same API as other tools
[20:25] <BlessJah> BTW, it's hilarious how AWS is inconsistent with itself, like when API filter for name accepts globs anchored at both beggining and end, while search in browser uses regexes instead
[20:26] <smoser> You can parse our names on amazon, but really, doesn't it make more sense to *not* ?
[20:26] <smoser> and have sane well formed data ?
[20:35] <BlessJah> It's not about parsing to extract information, but knowing what string will give me latest, production grade image.
[20:46] <smoser> BlessJah: well how is that done for other images?
[20:47] <smoser> i updated that bug
[20:47] <smoser>  ami-0309a879
[20:47] <smoser> oops
[20:47] <smoser> paste fail
[20:47] <smoser> https://bugs.launchpad.net/cloud-images/+bug/1458825
[20:48] <smoser> BlessJah: we *did* originally start out with a well formed naming convention on EC2.
[20:49] <smoser> but bucket limitations , ebs, many different things ultimately made changes necessary and inconsistent. but we have tried to provide that data in a consistent format over http on cloud-images.ubuntu.com
[21:04] <sveinse> I'm running 16.04 on a server, and I'm constantly bothered with that smbd requires a manual restart for samba to work
[21:05] <sveinse> systemctl status smbd reports active (exited) with status=0, and the logs simply sais "* Starting SMB/CIFS daemon smbd", "...done" and then its out.
[21:05] <sveinse> Restarting smbd fixes everything
[21:05] <sveinse> Familiar to anyone?
[21:06] <sarnold> does journalctl or /var/log/*samba* something have more details?
[21:09] <sveinse> sarnold: ah, yes it does. "no network interfaces found", then "No sockets available to bind to." and a subsequent stacktrace and coredump
[21:09] <sarnold> sveinse: eww :)
[21:09] <sveinse> that kinda explains it thou
[21:09] <sarnold> sveinse: but at least you've got something to work with.
[21:10] <sarnold> jeeze, what an impenetrable page.. https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
[21:11] <sarnold> sveinse: I think, try the systemctl to change the samba service, "to include After=network-online.target and Wants=network-online.target."
[21:12] <sveinse> My turn to eww: samba is still started through /etc/init.d, so it does not help to change the systemd start prereqs :(
[21:12] <sveinse> Anyone knows if the upcoming 18.04 LTS will have changes this?
[21:12] <sveinse> I'm willing to live with this until the next LTS arrives
[21:13] <sveinse> sarnold: thanks
[21:16] <sarnold> sveinse: well, at least -a- debian samba package has some smb.service, nmbd.service, etc files, http://sources.debian.net/src/samba/2:4.6.7%2Bdfsg-1/debian/rules/#L176
[21:16] <nacc> sveinse: i'm 99% sure the init.d script source lsb-functions, which then switches to systemd
[21:17] <sarnold> sveinse: .. and if kind of looks like that version should be in the next LTS
[21:19] <sveinse> Yeah, I'm looking at the package manifest for my samba. I'm having 2:4.3.11+dfsg-0ububut<IP_ADDRESS>, and it does not have any native systemd units it seems
[21:20] <nacc> samba: /lib/systemd/system/samba.service
[21:20] <nacc> sveinse: --^
[21:21] <sveinse> nacc: yup, that is in the newer packages, right?
[21:21] <nacc> that's in xenial.
[21:21] <sveinse> wierd. what version is that?
[21:21] <nacc> sveinse: i don't know what 'manifest' you were referring to?
[21:22] <sveinse> nacc: heh, mine. That is list of the files installed the package, dpkg -L samba
[21:22] <nacc> sveinse: i'm going off the apt-file output
[21:23]  * nacc spins up a container
[21:23] <nacc> can't trust anyone
[21:23] <nacc> sveinse: samba.service is admittedly not the same as smbd.service
[21:24] <sveinse> nacc: my /lib/systemd/system/samba.service is a symlink to /dev/null :O
[21:24] <nacc> sveinse: which means it's been masked
[21:25] <nacc> (iirc)
[21:26] <nacc> hrm, and can't enable it because the inits cript has no runlevels
[21:28] <nacc> sveinse: ok, nmbd.service and smbd.service are generated
[21:28] <nacc> sveinse: which means they can be ordered
[21:28] <nacc> *i thikn
[21:28] <sveinse> /lib/systemd/system/samba.service is owned by the samba package. Reading samba.preinst and .postinst, shows that it is apparently is doing init.d manipulation and not any .service stuff
[21:29] <sveinse> which is wierd, if you're getting other results
[21:29] <nacc> sveinse: what other results?
[21:29] <nacc> sveinse: i agree samba.service is masked
[21:29] <nacc> sveinse: smbd.service and nmbd.service exist
[21:29] <nacc> they are generated
[21:30] <sveinse> nacc, you mentioned nmbd.service and smbd.service. On my system they don't exist, neither in /lib/systemd nor /etc/systemd
[21:30] <nacc> sveinse: i just said, agai, they are generated
[21:30] <sveinse> nacc: so, what version are you getting in your container?
[21:30] <nacc> not on the filesystem
[21:30] <nacc> they still exist and are systemd services
[21:31] <sarnold> oh my
[21:31] <nacc> see `man systemd-sysv-generator`
[21:32] <sveinse> nacc: oh, yes, ah, yes yes. systemd makes services out of init.d items, true. That is the service I need to restart to get smbd working
[21:32] <nacc> sveinse: right, and i think above you were just saying you need to order it? or sorry, missig context
[21:33] <sarnold> I was suggesting it needed to be ordered
[21:33] <nacc> sarnold: ah ok
[21:33] <nacc> so the problem is smbd starting before network?
[21:33] <sveinse> nacc: for some reason, systemd starts smbd too soon when network isn't available yet (so it coredumps), so I wonder how I can order it when it does not have a service file
[21:34] <sarnold> after seeing https://anonscm.debian.org/cgit/pkg-samba/samba.git/commit/?id=61eaeba2a7a2df61b681b4ea545811569de421d0 earlier I assumed we had systemd unit files for samba...
[21:34] <nacc> i think we do now
[21:34] <nacc> but not in xenial
[21:34] <nacc> so it might need a bug
[21:34] <sarnold> sveinse: it -coredumps- on interface-not-available?
[21:34] <sarnold> that sounds like another bug report too, heh
[21:36] <sveinse> sarnold: I get this in /var/log/samba/log.smbd, https://bpaste.net/show/7e92863d2661
[21:37] <sveinse> but no core in the mentioned directory (perhaps ulimit is too low)
[21:37] <sarnold> sveinse: hrm. I'm _guessing_ that they chose to dump core on a huge number of issues, just so they could have something to debug with :)
[21:37] <sarnold> sveinse: apport might have eaten the core
[21:39] <nacc> sveinse: pulling up the git repo so i can try help a bit better
[21:40] <nacc> 2:4.4.4+dfsg-1 is when it was fixed in debian
[21:41] <nacc> https://git.launchpad.net/~usd-import-team/ubuntu/+source/samba/commit/?id=28a135855171ad2b00821c23e5b4e6b589cd7e1b
[21:42] <nacc> presumably exactly for this problem
[21:42] <nacc> as those are all After=network.target
[21:42] <sarnold> .. which might be before the network is online
[21:42] <sarnold> did samba switch to IP_FREEBIND or whatever the option is?
[21:43] <nacc> sarnold: above my pay grade
[21:43] <nacc> ahasenack: --^
[21:43] <nacc> (i thinkn he's out right now, though)
[21:43] <sarnold> nacc: and with the weather as nice as it is right now, this might be the last we see the sun until july 5th
[21:43] <nacc> sarnold: yeah
[21:44] <nacc> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
[21:45] <nacc> so it seems like *maybe* that hsould be network-online.target
[21:45] <sveinse> nacc: yes, seems it would
[21:45] <nacc> sveinse: the "right" fix (least sensitive/invasive) for 16.04 is to put the right headers i the lsb file
[21:45] <nacc> with a $network depedency
[21:45] <nacc> which will translate to a Wants/After network-online.target
[21:46] <sveinse> You guys think its safe to pick a backported samba in a production server?
[21:46] <nacc> no
[21:46] <nacc> :)
[21:46] <sveinse> (horrible question)
[21:46] <nacc> but i also don't think it's safe to run samba ;)
[21:46] <sveinse> tell that to all the win guys who think they rule the world
[21:46] <nacc> sveinse: intneresting
[21:47] <nacc>  /etc/init.d/smb *does* have $network
[21:47] <nacc> err, smbd and nmbd
[21:48] <sveinse> Our router is handing out DHCP IPs, even to servers with "fixed" IP. Could it be that assumption? Because $network in that context is when ip is up, not when dhclient has done it's job, right?
[21:49] <nacc> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ syas $network gets intnerprted by systemd to mean wait on network-onlinne.target
[21:49] <sveinse> horrible failure mode from smbd thou
[21:49] <sarnold> that could sure explain why you see it and yet we're not over-run with this complait on irc every day...
[21:50] <nacc> sveinse: ah but yeah, that could imply you are in network-online already
[21:50] <nacc> before you actually are :)
[21:51] <nacc> sveinse: check `systemd-analyze critical-chain smbd.service`
[21:51] <nacc> see if it is ordered correctly
[21:51] <sveinse> interestingly its after network-online.target
[21:51] <sarnold> nacc: nice :)
[21:52] <nacc> yeah
[21:52] <nacc> so it did it "right"
[21:52] <nacc> the issue is your system thought it was 'online' before it was, for some meaning of 'online' and 'think'
[21:53] <nacc> well, 'thought', but conjugated
[21:53] <sveinse> yes
[21:53] <sveinse> well, then it's time to argue with the router infra guys about why I need to set a fixed ip and not run dhcp :D
[21:54] <nacc> sveinse: i guess you could trawlt he log and see 'when' you got "Reached target Network is Online" and see if it is correct
[21:56] <sveinse> hmm. the journal does not mention "online", but systemd-analyze said it happened at 24.227s. I wonder if I can get journal -b0 to dump with entries in seconds since startup rather than using wall clock
[21:58] <nacc> sveinse: hrm, my journalctl does show the line
[21:58] <nacc> sveinse: in a 16.04 lxd
[21:59] <sveinse> nacc: It does. My bad. grep online does not find "Online"
[21:59] <nacc> sveinse: ah :)
[22:00] <nacc> sveinse: if you don't mind, before you EOD, can you check if there is a bug for the samba systemd units as they currently are (ref the commit i gave above) and that it's a behavior change to depend on network.target when 16.04 depended on network-online.target (implicitly via $network)
[22:00] <sveinse> network online is 1 second after getting dhcp address.
[22:01] <sveinse> now here is an interesting thing: I see that nmbd starts after network online. But smbd starts well before network online and "network"
[22:01] <nacc> sveinse: even in the critical chain output?
[22:02] <sveinse> https://bpaste.net/show/44fad5355fa9
[22:03] <nacc> that's after nmbd.service
[22:03] <sveinse> Do I read that smbd is depending on nmbd?
[22:03] <nacc> so if nmbd.servic is after nnetwork-online, so is smbd :)
[22:03] <nacc> sveinse: top-level is the one you asked for, then each little down is a dependency
[22:03] <nacc> smbd.service depended on nmbd.service depended on network-online.target depended on ...
[22:04] <nacc> and if you depend on something (in this parlance) we mean it started after
[22:05] <sveinse> snipping parts of the journal logs: https://bpaste.net/show/722f3f847e68
[22:08] <nacc> very strange
[22:08] <nacc> i suppose it's possible for systemd to start a unit twice and only emit the second one
[22:08] <nacc> but that would imply you've done some local config to force smbd to start
[22:08] <sveinse> nacc: not deliberately...
[22:09] <nacc> sveinse: hrm, i genuinely don't know
[22:09] <nacc> sveinse: i would file a bug -- it feels like something is wrong, but i don't know what
[22:09] <nacc> i would file against both samba and systemd, tbh
[22:10] <nacc> sveinse: that log does imply a race, for some reason, between dhclient starting and finishing and smbd starting
[22:10] <nacc> sveinse: which does read like ad ependnecy on network rather than network-online
[22:10] <sveinse> I've got /etc/init.d/samba AND smbd and nmbd. Do you have this in your container?
[22:11] <nacc> sveinse: yeah
[22:11] <sveinse> ok, thanks
[22:11] <nacc> samba is like the meta-service
[22:11] <nacc> it makes sure smbd and nmbd are running
[22:11] <nacc> oh and samba-ad-dc
[22:12] <sveinse> yes, you'll see that in the journal paste as well. In proper relationship to "network online"
[22:12] <nacc> yeah
[22:13] <nacc> it's clearly a bit of a thundering herd there
[22:13] <nacc> all that gets logged in the same secod :)
[22:13] <nacc> and given logging, it's also possible we are seeing weird output that is not related to the actual order
[22:13] <nacc> i mean it coudl be racy writing to the journal
[22:19] <sveinse> nacc: isn't the journal race safe? I.e. it writes the entries "mutex"-wise in the order they're received?
[22:19] <sveinse> but granted, the services might be out of orders over the cpu cores
[22:25] <nacc> sveinse: i'm not sure, i meant simply that i'm not sure what guarantees the order things are written is the order in which they are received
[22:26] <nacc> e.g., it might have receive 4 parallel service starts
[22:26] <nacc> those all get shown as starting, in some order, because ... well, we can't read parallel
[22:26] <nacc> but they really all started simultaneously
[22:26] <nacc> i don't trust the timestamps of the journal to tell me that :)
[22:27] <sveinse> nacc: no, agreed
[22:28] <sveinse> the timebox for fixing this thing is up soon, but what exactly do you want me to do with this? I suppose report it, but with what data?
[22:29] <nacc> sveinse: yeah, `ubuntu-bug samba`, with whatever you can summarize out of the above
[22:29] <nacc> ahasenack: should see this in his backlog whenn he's back too
[22:29] <nacc> sveinse: i'm out for a while, so he's likely to be the one to help
[22:31] <sveinse> heh, ubuntu-bug samba asks "How would you best describe your setup?" 1) I am running a Windows File Server, 2) I am connecting to a Windows File Server, C) Cancel... Eeehh. None of the above. :P
[22:32] <nacc> sveinse: it *might* just be easier to do a https://bugs.launchpad.net/ubuntu/+source/samba/+filebug
[22:32] <nacc> sveinse: and maybe mentio that the above options are a bit limited :)
[22:47] <sveinse> nacc: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1733011
[23:00] <nacc> sveinse: thakns
[23:00] <sveinse> nacc: thanks yourself
[23:01] <sveinse> Now I need to fix something else
[23:01] <nacc> sveinse: yeah that's *really* weird, but you did a good job summarizing it ...
[23:19] <drab> is there some kind of very small ubuntu based distro to be used for rescue?
[23:19] <drab> (I know I asked about this already, bust still looking)
[23:19] <drab> damn small linux seems discontinued, ubuntu is huge (1.5GB)
[23:19] <drab> ideally I'd use mini.iso, but it doesn't provide a bootable system, only install (same for server)
[23:40] <gun1x> is docker foss ?
[23:45] <nacc> gun1x: a question for docker, presumably.
[23:46] <gun1x> nacc: nevermind, found my answer


[00:01] -queuebot:#ubuntu-release- Unapproved: libjcat (focal-proposed/main) [0.1.3-2~ubuntu20.04.1 => 0.1.4-ubuntu1~20.04.1] (no packageset)
[00:04] -queuebot:#ubuntu-release- Unapproved: libjcat (impish-proposed/main) [0.1.3-2build1 => 0.1.4-ubuntu1~21.10.1] (core)
[00:20] -queuebot:#ubuntu-release- New binary: mir [amd64] (jammy-proposed/main) [2.7.0-0ubuntu1] (ubuntu-desktop)
[00:20] -queuebot:#ubuntu-release- New binary: mir [s390x] (jammy-proposed/main) [2.7.0-0ubuntu1] (ubuntu-desktop)
[00:22] -queuebot:#ubuntu-release- New binary: mir [ppc64el] (jammy-proposed/main) [2.7.0-0ubuntu1] (ubuntu-desktop)
[00:48] -queuebot:#ubuntu-release- New binary: gcc-11-cross [amd64] (jammy-proposed/main) [11ubuntu1] (i386-whitelist, ubuntu-desktop)
[00:52] -queuebot:#ubuntu-release- New binary: mir [arm64] (jammy-proposed/main) [2.7.0-0ubuntu1] (ubuntu-desktop)
[00:53] -queuebot:#ubuntu-release- Unapproved: fwupd (impish-proposed/main) [1.5.11-0ubuntu2 => 1.7.5-3~21.10.1] (core)
[00:55] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.5.11-0ubuntu1~20.04.2 => 1.7.5-3~20.04.1] (core)
[01:09] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.4] has been marked as ready
[02:17] <dbungert> vorlon: since you brought it up special, I wanted to share that I found the problem commit in graphicsmagick and have a debdiff  LP: #1962210
[02:31] <vorlon> dbungert: ok - need sponsorship then?
[02:36] -queuebot:#ubuntu-release- New sync: libsoup3 (jammy-proposed/primary) [3.0.4-2]
[02:54] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.4] has been marked as ready
[04:42] -queuebot:#ubuntu-release- New binary: mir [riscv64] (jammy-proposed/main) [2.7.0-0ubuntu1] (ubuntu-desktop)
[05:16] -queuebot:#ubuntu-release- Unapproved: fwupd-signed (impish-proposed/main) [1.42~ubuntu21.10.1 => 1.42~ubuntu21.10.2] (core)
[05:18] -queuebot:#ubuntu-release- Unapproved: fwupd-signed (focal-proposed/main) [1.27.1ubuntu6 => 1.27.1ubuntu7] (core)
[07:53] -queuebot:#ubuntu-release- New: accepted gcc-11-cross [amd64] (jammy-proposed) [11ubuntu1]
[07:53] -queuebot:#ubuntu-release- New: accepted mir [arm64] (jammy-proposed) [2.7.0-0ubuntu1]
[07:53] -queuebot:#ubuntu-release- New: accepted mir [riscv64] (jammy-proposed) [2.7.0-0ubuntu1]
[07:53] -queuebot:#ubuntu-release- New: accepted mir [amd64] (jammy-proposed) [2.7.0-0ubuntu1]
[07:53] -queuebot:#ubuntu-release- New: accepted mir [s390x] (jammy-proposed) [2.7.0-0ubuntu1]
[07:53] -queuebot:#ubuntu-release- New: accepted mir [ppc64el] (jammy-proposed) [2.7.0-0ubuntu1]
[07:54] -queuebot:#ubuntu-release- New: accepted gavodachs [amd64] (jammy-proposed) [2.5.3+dfsg-1]
[07:54] -queuebot:#ubuntu-release- New: accepted libsoup3 [sync] (jammy-proposed) [3.0.4-2]
[07:57] -queuebot:#ubuntu-release- New binary: libsoup3 [amd64] (jammy-proposed/none) [3.0.4-2] (no packageset)
[07:57] -queuebot:#ubuntu-release- New binary: libsoup3 [s390x] (jammy-proposed/none) [3.0.4-2] (no packageset)
[07:58] -queuebot:#ubuntu-release- New binary: libsoup3 [ppc64el] (jammy-proposed/none) [3.0.4-2] (no packageset)
[08:03] -queuebot:#ubuntu-release- New binary: libsoup3 [arm64] (jammy-proposed/none) [3.0.4-2] (no packageset)
[08:03] -queuebot:#ubuntu-release- New binary: libsoup3 [armhf] (jammy-proposed/none) [3.0.4-2] (no packageset)
[08:48] -queuebot:#ubuntu-release- New binary: libsoup3 [riscv64] (jammy-proposed/universe) [3.0.4-2] (no packageset)
[09:20] -queuebot:#ubuntu-release- Unapproved: ovn (focal-proposed/main) [20.03.2-0ubuntu<IP_ADDRESS> => 20.03.2-0ubuntu<IP_ADDRESS>] (no packageset)
[11:07] -queuebot:#ubuntu-release- New: accepted libsoup3 [amd64] (jammy-proposed) [3.0.4-2]
[11:07] -queuebot:#ubuntu-release- New: accepted libsoup3 [armhf] (jammy-proposed) [3.0.4-2]
[11:07] -queuebot:#ubuntu-release- New: accepted libsoup3 [riscv64] (jammy-proposed) [3.0.4-2]
[11:07] -queuebot:#ubuntu-release- New: accepted libsoup3 [arm64] (jammy-proposed) [3.0.4-2]
[11:08] -queuebot:#ubuntu-release- New: accepted libsoup3 [s390x] (jammy-proposed) [3.0.4-2]
[11:08] -queuebot:#ubuntu-release- New: accepted libsoup3 [ppc64el] (jammy-proposed) [3.0.4-2]
[11:10] -queuebot:#ubuntu-release- New: accepted qcoro [riscv64] (jammy-proposed) [0.4.0-1]
[11:16] <RikMills> we are in FF, but autosync is still running. is that intended?
[11:25] -queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.103-0ubuntu5~20.04.5 => 0.103-0ubuntu5~20.04.6] (core)
[12:14] <cjwatson> RikMills: That seems surprising per the release schedule, certainly.  I've put auto-sync into dry-run mode now
[12:14] <cjwatson> (somebody else can always re-enable it if there's some discussion I was unaware of)
[13:20] <xnox> amurray:  i don't have an opinion on that; i.e. if we need to update britney / adt-cloud; or if we should proactively revert those restrictions. It's just something i have noticed.
[13:21] <xnox> amurray:  surely many other packages use that restriction in debian now, and we sync them, and thus should be able to handle and support correctly.
[15:16] <laney> xnox: amurray: it's supposed to be skipped, semi-implied in the name but that restriction really exists just to add extra triggers to the Testsuite-Triggers https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst#L302
[16:45] -queuebot:#ubuntu-release- New binary: elscreen [amd64] (jammy-proposed/universe) [1.4.6-7] (no packageset)
[17:40] -queuebot:#ubuntu-release- New binary: node-winston-compat [amd64] (jammy-proposed/universe) [0.1.5-2] (no packageset)
[17:41] -queuebot:#ubuntu-release- New: accepted elscreen [amd64] (jammy-proposed) [1.4.6-7]
[17:41] -queuebot:#ubuntu-release- New: accepted node-winston-compat [amd64] (jammy-proposed) [0.1.5-2]
[17:53] <rbasak> Am I correct in assume that the release team is happy for mariadb-10.6 to be fixed in the archive, and metapackages switched over from 10.5 to 10.6, despite feature freeze?
[17:53] <rbasak> Or do you want more details in an FFe bug?
[17:54] <rbasak> mariadb-10.6 currently FTBFS but Otto has fixes and is testing them in Debian currently.
[17:54] <rbasak> After that he plans to upload to unstable and I expect to sync it in.
[17:56] <vorlon> rbasak: yes that's ok
[17:56] <rbasak> Thanks!
[17:56] <vorlon> bdmurray: did disabling auto-sync get missed in the FF checklist?
[17:57] <vorlon> (discussion in scrollback)
[17:57] <rbasak> Otto is expecting "Sunday or early next week" for a Debian upload and I'll sync after that
[18:19] -queuebot:#ubuntu-release- New binary: rust-byte-unit [amd64] (jammy-proposed/universe) [4.0.13-1] (no packageset)
[18:19] -queuebot:#ubuntu-release- New binary: rust-byte-unit [ppc64el] (jammy-proposed/universe) [4.0.13-1] (no packageset)
[18:20] -queuebot:#ubuntu-release- New binary: rust-concurrent-queue [amd64] (jammy-proposed/universe) [1.2.2-1] (no packageset)
[18:20] -queuebot:#ubuntu-release- New binary: rust-concurrent-queue [ppc64el] (jammy-proposed/universe) [1.2.2-1] (no packageset)
[18:22] -queuebot:#ubuntu-release- New binary: rust-byte-unit [s390x] (jammy-proposed/universe) [4.0.13-1] (no packageset)
[18:22] -queuebot:#ubuntu-release- New binary: rust-concurrent-queue [s390x] (jammy-proposed/universe) [1.2.2-1] (no packageset)
[18:23] -queuebot:#ubuntu-release- New binary: rust-byte-unit [arm64] (jammy-proposed/universe) [4.0.13-1] (no packageset)
[18:23] -queuebot:#ubuntu-release- New binary: rust-gtk4-sys [amd64] (jammy-proposed/universe) [0.3.1-1] (no packageset)
[18:23] -queuebot:#ubuntu-release- New binary: rust-byte-unit [armhf] (jammy-proposed/universe) [4.0.13-1] (no packageset)
[18:25] -queuebot:#ubuntu-release- New binary: rust-concurrent-queue [arm64] (jammy-proposed/universe) [1.2.2-1] (no packageset)
[18:25] -queuebot:#ubuntu-release- New binary: rust-gtk4-sys [ppc64el] (jammy-proposed/universe) [0.3.1-1] (no packageset)
[18:25] -queuebot:#ubuntu-release- New binary: rust-concurrent-queue [armhf] (jammy-proposed/universe) [1.2.2-1] (no packageset)
[18:26] -queuebot:#ubuntu-release- New binary: rust-ouroboros-macro [amd64] (jammy-proposed/universe) [0.14.0-1] (no packageset)
[18:27] -queuebot:#ubuntu-release- New binary: rust-ouroboros-macro [ppc64el] (jammy-proposed/universe) [0.14.0-1] (no packageset)
[18:32] -queuebot:#ubuntu-release- New binary: sagetex [amd64] (jammy-proposed/universe) [3.6+ds-2] (no packageset)
[18:33] -queuebot:#ubuntu-release- New binary: rust-gtk4-sys [s390x] (jammy-proposed/universe) [0.3.1-1] (no packageset)
[18:35] <Eickmeyer> vorlon: Can I assume the most recent image build failure was a temporary failure? It looks like it.
[18:35] <Eickmeyer> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/ubuntustudio/+build/329694
[18:36] -queuebot:#ubuntu-release- New binary: rust-gtk4-sys [arm64] (jammy-proposed/universe) [0.3.1-1] (no packageset)
[18:36] -queuebot:#ubuntu-release- New binary: rust-ouroboros-macro [s390x] (jammy-proposed/universe) [0.14.0-1] (no packageset)
[18:37] -queuebot:#ubuntu-release- New binary: rust-gtk4-sys [armhf] (jammy-proposed/universe) [0.3.1-1] (no packageset)
[18:39] <cjwatson> Eickmeyer: Yeah, I've seen a report of that before and it's odd - it should be using archive-team.internal there rather than people.canonical.com, and I think there may be some kind of infrastructure issue causing it not to do so
[18:40] <cjwatson> Not precisely a temporary failure but not ubuntustudio's problem to fix
[18:40] -queuebot:#ubuntu-release- New binary: rust-ouroboros-macro [armhf] (jammy-proposed/universe) [0.14.0-1] (no packageset)
[18:40] <Eickmeyer> cjwatson: Yeah, that's what I thought. At least we've got some awareness though. Kinda spooks me when I see that because of our squashfs overfill issues we've had.
[18:40] <RikMills> same issue for kubuntu iso this morning
[18:40] <cjwatson> It's unrelated to squashfs overfill
[18:41] <cjwatson> RikMills: do you have a link?
[18:41] <Eickmeyer> Yeah, I figured, that's why I asked. I know what it looks like when squashfs > 4G. We tend to see a lack of image built without error when that happens.
[18:41] <RikMills> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/kubuntu/+build/329581
[18:42] -queuebot:#ubuntu-release- New binary: rust-ouroboros-macro [arm64] (jammy-proposed/universe) [0.14.0-1] (no packageset)
[18:42] <cjwatson> Thanks, that's useful since it eliminates it being one of the 60 new builders we added on Wednesday
[18:42] <cjwatson> Could still be an issue specific to lcy02
[18:42] <Eickmeyer> lcy02 has been kindof a bad bot lately, eh?
[18:42] <cjwatson> ?
[18:43] <Eickmeyer> Nvm, just an expression.
[18:43] <cjwatson> It's mostly excellent, just a couple of leftover oddities
[18:43] <Eickmeyer> Gotcha.
[18:43] <cjwatson> It might also be related to upgrading the base images to focal
[18:43] <cjwatson> There's some quite fiddly stuff in launchpad-buildd to ensure that hostname --fqdn works right inside containers
[18:44] <Eickmeyer> Ah, yes. The ol' fixing oddities after a major upgrade thing.
[18:44] <cjwatson> It doesn't *look* wrong but I likely need to dig
[18:45] <Eickmeyer> Yeah, I get that. :)
[18:45] <RikMills> mainline ubuntu failed as will this morning, but worked on a retry it seems
[18:45] <RikMills> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/ubuntu
[18:45] <cjwatson> Having a public livefs causing this is useful though - the previous report was from a private livefs, which is a lot more cumbersome for me to deal with, so thanks
[18:45] <RikMills> *as well
[18:45] <cjwatson> I was really hoping you weren't going to tell me it worked on a retry ...
[18:45] <cjwatson> Oh wait, I think you're misreading that
[18:45] <cjwatson> amd64 != arm64
[18:46] <RikMills> oh, yes
[18:46] <RikMills> sorry
[18:46] <RikMills> I forgot about that on ubuntu
[18:46] <cjwatson> I don't understand why the previous build worked though, since that was also on lcy02 and focal base
[18:47] <RikMills> xubuntu worked: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/xubuntu
[18:47] -queuebot:#ubuntu-release- New binary: rust-byte-unit [riscv64] (jammy-proposed/universe) [4.0.13-1] (no packageset)
[18:48] <RikMills> that was only 3hrs before the kubuntu fail
[18:59] -queuebot:#ubuntu-release- New binary: precious [amd64] (jammy-proposed/universe) [0.1.3-2] (no packageset)
[19:01] -queuebot:#ubuntu-release- New binary: precious [ppc64el] (jammy-proposed/universe) [0.1.3-2] (no packageset)
[19:01] -queuebot:#ubuntu-release- New binary: rust-concurrent-queue [riscv64] (jammy-proposed/universe) [1.2.2-1] (no packageset)
[19:07] -queuebot:#ubuntu-release- New binary: rust-ouroboros-macro [riscv64] (jammy-proposed/universe) [0.14.0-1] (no packageset)
[19:09] -queuebot:#ubuntu-release- New binary: rust-gtk4-sys [riscv64] (jammy-proposed/universe) [0.3.1-1] (no packageset)
[19:20] -queuebot:#ubuntu-release- New binary: rust-libhandy-sys [riscv64] (jammy-proposed/universe) [0.8.0-1] (no packageset)
[19:33] -queuebot:#ubuntu-release- New: accepted precious [amd64] (jammy-proposed) [0.1.3-2]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-concurrent-queue [riscv64] (jammy-proposed) [1.2.2-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-libhandy-sys [riscv64] (jammy-proposed) [0.8.0-1]
[19:33] -queuebot:#ubuntu-release- New: accepted precious [ppc64el] (jammy-proposed) [0.1.3-2]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-ouroboros-macro [riscv64] (jammy-proposed) [0.14.0-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-gtk4-sys [riscv64] (jammy-proposed) [0.3.1-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-byte-unit [riscv64] (jammy-proposed) [4.0.13-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-gtk4-sys [armhf] (jammy-proposed) [0.3.1-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-ouroboros-macro [amd64] (jammy-proposed) [0.14.0-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-ouroboros-macro [armhf] (jammy-proposed) [0.14.0-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-ouroboros-macro [s390x] (jammy-proposed) [0.14.0-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-gtk4-sys [arm64] (jammy-proposed) [0.3.1-1]
[19:33] -queuebot:#ubuntu-release- New: accepted rust-ouroboros-macro [arm64] (jammy-proposed) [0.14.0-1]
[19:33] -queuebot:#ubuntu-release- New: accepted sagetex [amd64] (jammy-proposed) [3.6+ds-2]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-gtk4-sys [s390x] (jammy-proposed) [0.3.1-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-ouroboros-macro [ppc64el] (jammy-proposed) [0.14.0-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-byte-unit [arm64] (jammy-proposed) [4.0.13-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-byte-unit [s390x] (jammy-proposed) [4.0.13-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-concurrent-queue [armhf] (jammy-proposed) [1.2.2-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-concurrent-queue [s390x] (jammy-proposed) [1.2.2-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-gtk4-sys [ppc64el] (jammy-proposed) [0.3.1-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-byte-unit [armhf] (jammy-proposed) [4.0.13-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-concurrent-queue [ppc64el] (jammy-proposed) [1.2.2-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-concurrent-queue [arm64] (jammy-proposed) [1.2.2-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-gtk4-sys [amd64] (jammy-proposed) [0.3.1-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-byte-unit [amd64] (jammy-proposed) [4.0.13-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-concurrent-queue [amd64] (jammy-proposed) [1.2.2-1]
[19:34] -queuebot:#ubuntu-release- New: accepted rust-byte-unit [ppc64el] (jammy-proposed) [4.0.13-1]
[20:18] <vorlon> rbasak: and do you have any insight into mariadb-10.5/armhf autopkgtests falling over and blocking perl? https://autopkgtest.ubuntu.com/packages/m/mariadb-10.5/jammy/armhf
[20:20] <vorlon> (if this becomes the last blocker I'll probably ignore the failures)
[20:21] <vorlon> seems related to the fact that mariadb-plugin-rocksdb doesn't exist on armhf
[20:22] <vorlon> newer mariadb-10.5 in impish-security than jammy-proposed :/
[20:31] <doko> vorlon: ocaml is also connected with perl and python. I'll do level 10 tonight, maybe you can continue with that later today. https://people.canonical.com/~ubuntu-archive/transitions/html/ocaml.html
[20:32] <vorlon> doko: I don't see where it's connected based on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#perl but I'm not sure that output is reliable / exhaustive, do you have a pointer?
[20:33] <doko> libguestfs
[20:33] <vorlon> thanks
[20:34] <doko> at least, maybe more
[20:34] <vorlon> that also depends on ruby though
[20:34] <vorlon> and I'm not sure where we're at with that one
[20:34] <vorlon> oh, ruby is blocked by ocaml ;P
[20:34] <vorlon> ok, I will certainly have a look
[20:41] <ahasenack> languages: fight!
[20:41] <ahasenack> (programming languages)
[21:07] -queuebot:#ubuntu-release- New sync: slic3r-prusa (jammy-proposed/primary) [2.4.0+dfsg-2]
[22:26] -queuebot:#ubuntu-release- Unapproved: bolt (focal-proposed/main) [0.8-4ubuntu1 => 0.9.1-2~ubuntu20.04.1] (desktop-core, ubuntu-server)
[22:43] -queuebot:#ubuntu-release- Unapproved: cloud-init (impish-proposed/main) [21.4-0ubuntu1~21.10.1 => 22.1-14-g2e17a0d6-0ubuntu1~21.10.1] (core, ubuntu-cloud)
[22:56] -queuebot:#ubuntu-release- New binary: qcoro [amd64] (jammy-proposed/universe) [0.4.0-3ubuntu1] (no packageset)
[23:03] -queuebot:#ubuntu-release- New: accepted slic3r-prusa [sync] (jammy-proposed) [2.4.0+dfsg-2]
[23:07] -queuebot:#ubuntu-release- New: accepted qcoro [amd64] (jammy-proposed) [0.4.0-3ubuntu1]
[23:32] -queuebot:#ubuntu-release- New binary: slic3r-prusa [amd64] (jammy-proposed/universe) [2.4.0+dfsg-2] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: slic3r-prusa [s390x] (jammy-proposed/universe) [2.4.0+dfsg-2] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: slic3r-prusa [ppc64el] (jammy-proposed/universe) [2.4.0+dfsg-2] (no packageset)
[23:57] <cjwatson> Eickmeyer: I think I know what's going on, although we won't be able to get it fixed until next week at this point.  cloud-init sometimes fails to talk to the metadata service when the instance boots (I think possibly it needs to be bounced on some of the compute nodes), and has some fallback behaviour that's inappropriate for this environment and results in the instance coming up with ...
[23:57] <cjwatson> ... incorrect /etc/hosts
[23:58] <cjwatson> Can fix by (a) getting the relevant sysadmins to get the metadata service in question going again and also (b) changing the buildd VM image so that it just refuses to boot rather than having this fallback
[23:59] <cjwatson> Well, either of those two would fix it although with only (b) we'd end up with degraded resets so you'd get more builders cleaning or disabled than usual


[09:18] <alan_g> racarr: I think I know what I missed. Working on a quick fix. (But it opens up a whole load of simplifications to qtmir that I'm trying to resist for now.)
[09:48] <alan_g> racarr: I've not had time to test and have a hospital appointment - but I've pushed what I think is a fix to port-to-msh-Shell
[10:10] <alf_> racarr: How is the 0.11 release going? Asking because I need 0.11 to be released so I can release some Mesa fixes/changes.
[10:10] <alf_> racarr: (Good morning!)
[14:01] <alf_> racarr: duflu: @mir abi broken, we knew about this and since mir_connection_platform_operation was not (and couldn't have been) in use, we chose to ignore it. What changed?
[14:03] <duflu> alf_: I lost track... ask racarr
[14:18] <racarr> alf_: It was a series of confusions because we had a crash moving a client from .10 to .11 so it was like
[14:18] <racarr> oh ABI must be broken
[14:18] <racarr> so then we ran compliance checker and its like
[14:18] <racarr> ok yeah ABI broken
[14:18] <racarr> then at the end of the day we realized it wasn't in use ( I was mistakingly imaginging the mesa EGL platform using it forgetting the fds were preauthed)
[14:19] <alf_> racarr: yes, all external code (i.e. XMir) still uses the mesa_connection_drm_* functions
[14:20] <alf_> racarr: and mesa doesn't use mir public client functions at all directly