=== Guest5314 is now known as med_
[01:18] <michi> robru: ping
[01:29] <slangasek> xnox: I see that ogre-1.8 hard-codes a dependency on libboost1.55; is there a reason it doesn't depend on current libboost?  Is it because boost leaks into its abi?
[01:29] <slangasek> robru: ^^
[01:33] <slangasek> hmm, so grep-dctrl -w doesn't match packages with multiarch qualifiers after them.  Bug, or misfeature?
[01:39] <slangasek> oops, no, I'm talking nonsense; -w works correctly and I had a failure elsewhere
[01:49] <robru> michi: pong
[01:49] <michi> robru: never mind, figured it out...
[01:49] <michi> Thanks anyway!
[01:49] <robru> michi: hehe, you're welcome
[03:17] <ted> Is there a doc somewhere on using live-build
[03:18] <ted> I've tried the docs, which didn't really get me anywhere. And now I've got lp:livecd-rootfs
[03:18] <ted> But that's not really making my life easier.
[03:18]  * ted thought this was gonna be easy… last week
[09:32] <doko> slangasek, why the transition for hunspell? it only has references to the new libstdc++, but no new cxx11 symbols
[10:15] <davmor2> infinity: for when you get on could you add netboot to the 14.04.3 test run please, I'll test it in the meantime so it is out of the way :)
[10:17] <doko> slangasek, ahh, because we don't avoid renames when there are references to cxx11 symbols in libstdc++ only
[11:05] <cjwatson> ted: https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html might be helpful
[14:19] <davmor2> infinity, slangasek: so a friend did a do-release-upgrade on his server and got 14.04.3 that shouldn't happen should it?
[15:00] <slangasek> doko: is hunspell one that I transitioned?  I don't find hunspell listed at https://people.debian.org/~doko/logs/gcc5-20150701/
[15:02] <doko> ahh, no, seb 128. was maybe on the list, because it was uploaded to the ppa
[16:42] <robru> slangasek: morning! so i see http://people.canonical.com/~ubuntu-archive/transitions/html/tinyxml-g++5.html is quite a bit shorter, what should I do next?
[16:57] <slangasek> robru: take a look at the next package on the list that you haven't already looked at :)
[17:00] <robru> slangasek: so eg bullet has red Xs on all arches but when I click through to the log it's all green: https://launchpad.net/ubuntu/+source/bullet/2.83.5+dfsg-1build1 I'm a bit confused
[17:00] <slangasek> robru: yes; that's an annoying bug in the transition tracker, it appears to not get the right results when wily has a binary package depending on the lib, but wily-proposed no longer has that binary
[17:01] <slangasek> Laney might have more insight there
[17:01] <slangasek> but, it's a bug in the report, not in the package
[17:02] <robru> slangasek: ok so the green builds on lp are authoritative.
[17:03] <robru> slangasek: so does cegui need to be rebuilt again? you mentioned last night that you fixed the libsilly bug but the cegui build log shows the same failure
[17:04] <slangasek> robru: no, the red x doesn't say whether the package is /built/ it's supposed to say whether the package has been /transitioned/.  The transition tracker only tells you "this is the latest version of the package in the archive, and the last built binary still depends on the old library" (which is false here).  Launchpad tells you "the latest version of the package built successfully".  To get the
[17:04] <slangasek>  true answer you have to check the set of binary ...
[17:04] <slangasek> ... packages built by that latest version and see that they don't actually depend on the library
[17:05] <slangasek> robru: I fixed libsilly in Debian, which causes a delay for it getting fixed in wily-proposed since it takes time before the package can be synced from Debian.  I've synced libsilly now, it's being built, and I'll requeue cegui-mk2 once the build-dep is available
[17:05] <robru> ah ok
[17:05] <robru> slangasek: so it looks like the next one is gazebo. seems you didn't rebuild that one?
[17:07] <slangasek> robru: you already looked at crtmpserver?
[17:07] <robru> slangasek: it was green in lp ;-)
[17:08] <slangasek> robru: which does not tell you that the transition is done
[17:08] <slangasek> wow, we have log4cplus, log4cxx, and log4cpp? brilliant
[17:09] <slangasek> robru: I've just checked the archive; 'apt-cache show crtmpserver-libs' shows that the package still depends on the wrong tinyxml package after a rebuild, which means the package needs manual changes
[17:10] <robru> slangasek: then how did the build succeed? lol
[17:10] <slangasek> robru: that's what you need to look at
[17:24] <slangasek> xnox: fwiw your mygui migration missed the references to the binary package names in the .symbols files
[17:34] <infinity> davmor2: People should be getting 14.04.3 in lsb_release by now, yes.  ISOs are built from updates, so base-files already says .3
[17:34] <infinity> stgraber: Can we manually add the "netboot" cases somehow?  I don't want to reupload d-i just to make them show up. :P
[17:35] <stgraber> yep, one sec
[17:37] <stgraber> infinity: ^
[17:47] <infinity> davmor2: And stgraber sorted out your netboot needs.
[17:47] <infinity> stgraber: Ta.
[18:01] <davmor2> infinity: phew :)
[18:02] <slangasek> doko: I have a build failure showing C++ ABI incompatibilities in the ois package, which wasn't in your list; do you have some idea why? https://launchpad.net/ubuntu/+source/cegui-mk2/0.7.6-3.3build1/+build/7759424
[18:06] <doko> slangasek, not yet rebuilt ois.
[18:06] <doko> maybe it failed to build
[18:06] <slangasek> ok
[18:12] <doko> slangasek, and in general for any library with a transition in it's b-d's the list may be incomplete
[18:12] <slangasek> ok
[18:13] <infinity> davmor2: Can you try to hunt down some community folks for the flavours that don't appear to have any results yet?
[18:14] <davmor2> infinity: I can
[18:14] <infinity> davmor2: Barring any last minute show-stoppers, I think these will be the final images (I might respin powerpc/ppc64el server for one package update, but if I do, the rest won't get touched)
[18:14] <davmor2> infinity: nice
[18:15] <davmor2> infinity: so far so good too :)
[18:31] <davmor2> infinity: apparently #ubuntu-gnome don't test a release once it is out only new releases /me shrugs shoulder at that one
[18:32] <infinity> davmor2: Huh?
[18:32] <infinity> davmor2: I suspect you're talking to the wrong people, then.
[18:32] <infinity> darkxst: *poke*
[18:33] <infinity> darkxst: 14.04.3 testing? :)
[18:33] <davmor2> infinity: that's what I'm assuming :)
[18:33] <Laney> slangasek: I don't know more - it's supposed to deduplicate but maybe gets that wrong
[18:34]  * Laney is away for the rest of the week but put a quick update on the pad
[18:34] <davmor2> infinity: xubuntu's guy is <flocculant> and it sounds like he is just starting
[18:34] <Laney> if nobody else does I'll work on moar icu stuff next
[18:35] <infinity> davmor2: There's something unsettling about that IRC nick...
[18:36] <davmor2> infinity: I've asked him to join this channel incase there are critical issues.
[18:36] <davmor2> stgraber: have you got anyone for testing edubuntu?
[18:37] <stgraber> davmor2: highvoltage said he'd look into it
[18:37] <davmor2> stgraber: awesome thanks
[18:39] <slangasek> Laney: not sure what 'deduplicate' would mean here; the right rule should be "new source package exists, has binaries on this architecture, and none of those binaries depend on the old lib"
[18:40] <slangasek> if it's doing anything at all, it appears to be doing something else
[18:41] <davmor2> infinity: and that leave mythbuntu and I've no idea on them :)
[18:41]  * tgm4883 checks backlog
[18:41] <tgm4883> davmor2: what do we need to do?
[18:42] <tgm4883> davmor2: oh, 14.04.3 testing already?
[18:42] <davmor2> tgm4883: yeap
[18:42] <tgm4883> davmor2: is release tomororw?
[18:42] <davmor2> tgm4883: http://iso.qa.ubuntu.com/qatracker/milestones/344/builds
[18:42] <davmor2> tgm4883: it is
[18:43] <tgm4883> davmor2: on it
[18:44] <davmor2> tgm4883: thanks
[18:54] <davmor2> infinity: the gnome and xubuntu guys are both having issues with zsync is there anything that can be done about it?
[18:54] <infinity> davmor2: I suppose that depends on what the issue is.
[18:55] <infinity> davmor2: But I've heard good things about wget.
[18:55] <davmor2> <octoquad> cdimage.ubuntu.com: Connection timed out
[18:55] <davmor2> <octoquad> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-gnome/trusty/daily-live/20150805/trusty-desktop-amd64.iso.zsync
[18:55] <cjwatson> That sounds not terribly related to zsync per se.
[18:55] <infinity> Yeah, that's more of a network issue.
[18:56] <infinity> It works when you can connect to it (just tried here).
[18:56] <infinity> Lemme see if it works if I down the VPN.  Maybe someone's broken something.
[18:57] <davmor2> infinity: yeap struggling to connect from my server
[18:57] <infinity> Works here with and without VPN.
[18:57] <infinity> So, not much I can personally do.
[18:58] <davmor2> flocculant> davmor2: our cdbuild log has for the last 2 days had "ssh: connect to host goldenapple.canonical.com port 22: Connection timed out"
[18:58] <infinity> But if they grab some traceroutes and throw them at #canonical-sysadmin, someone might be able to help.
[18:59] <cjwatson> davmor2: that would just mean that our internal list of cdimage mirrors to trigger is out of date with the ones that are actually current
[19:00] <cjwatson> it's not going to cause the kind of error shown above
[19:01] <davmor2> hmmm I can't actually connect to cdimages at the moment
[19:01] <infinity> davmor2: Which cdimage IP(s) can people not connect to?
[19:02] <infinity> davmor2: There might be something to escalate here on our end.
[19:15] <tgm4883> davmor2: do you guys have a list of who to contact for flavors?
[19:16] <infinity> tgm4883: There's the manifest, which has a couple of contacts for each.
[19:16] <infinity> http://iso.qa.ubuntu.com/qatracker/series/42/manifest
[19:17] <infinity> Perhaps davmor2 wasn't aware of that. :)
[19:17] <infinity> davmor2: ^
[19:17] <davmor2> infinity: nope jibel normally handles all of this :)
[19:17] <davmor2> and balloons I guess
[19:18] <tgm4883> ok cool, I am on there
[19:19] <davmor2> infinity: oh so you test netboot do you ;)
[19:19] <infinity> davmor2: I'm "responsible" for it.
[19:19] <infinity> davmor2: Those are the "who owns it" names, not the "who tests it".
[19:19] <davmor2> infinity: ah fair enough :)
[19:20] <infinity> davmor2: And I do test it a fair bit.  Just usually not much on x86, since you guys cover that well.
[19:20] <davmor2> infinity: awesome I was kind getting concerned about test the arm stuff :)
[19:21] <bladernr_> has 14.04.3 released yet?  the archives say yes ;-)
[19:21] <bladernr_> bladernr@klaatu:~/Downloads/atsuya$ cat /etc/os-release |grep VERSION
[19:21] <bladernr_> VERSION="14.04.3 LTS, Trusty Tahr"
[19:22] <tgm4883> Mythbuntu testing done
[19:25] <infinity> bladernr_: Consider it an easter egg.
[19:25] <infinity> bladernr_: The ISOs are built from the archive, so base-files gets updated before the "official" release happens.
[19:26] <bladernr_> infinity: that's what I thought, thanks for confirming my suspicions (for a brief moment, I was afraid I had -proposed active)
[19:27] <davmor2> infinity: http://paste.ubuntu.com/12009049/ and http://paste.ubuntu.com/12009039/ so it looks like something is flakey on the www
[19:28] <infinity> davmor2: I have no way of knowing which IP that second attempt was.
[19:29] <infinity> davmor2: This is more likely one cdimage frontend that has an issue, given that you can get to another one just fine and they all live on the same network, I believe.
[19:29] <davmor2> infinity: that's what I'm assuming
[19:29] <infinity> Although, now that I say that, I only get one DNS response.  I could have sworn there were a few.
[19:29] <infinity> Maybe it's a server-side round-robin...
[19:30] <infinity> Ahh, yes it is.
[19:31] <infinity> And, indeed, goldenapple looks bust.
[19:33] <infinity> davmor2: So, the good(?) news is that if they wait a few minutes, they'll get the other IP.  Probably.
[19:33] <infinity> davmor2: But yeah, reporting to IS to either fix the lame machine or take it out of DNS.
[19:33] <davmor2> infinity: announced it on #canonical-sysadmin no vanguard though
[19:34] <infinity> davmor2: I whined in #is-outage@canonical, someone will notice.
[19:34] <davmor2> infinity: :)
[19:34] <davmor2> infinity: you've done this before I can tell :)
[19:42] <slangasek> dpatch!  dieeeee
[19:52] <slangasek> doko: I see gdal built; should spatialite be given back?
[19:53] <doko> slangasek, no, postgis needs to be published first (built without gdal as well)
[19:53] <slangasek> ok
[19:57] <infinity> davmor2: IS is pulling goldenapple out of DNS rotation to investigate, so things should clear up "soon".
[19:57] <davmor2> yay
[20:11] <slangasek> doko: postgis looks published
[20:13] <doko> slangasek, the one thing I'm not late on is the archive ... https://launchpad.net/ubuntu/+source/spatialite/4.3.0-1build2
[20:13] <slangasek> hah, ok
[20:14] <slangasek> sorry I got confused and was looking at gdal instead of spatialite
[20:16] <doko> yes, after that I have to restore postgis and gdal
[20:17] <doko> aptitude now built, and libreoffice rebuilt. would be nice if desktop images cold be tried
[20:27] <doko> slangasek, openimageio has b-d on g++-4.9. can you rebuild that, and rename if necessary?
[20:42] <infinity> davmor2: Curious.  netboot/arm64 has no defined tests.  Perhaps someone should copy and paste the default one in there.
[20:42] <infinity> davmor2: Not that it matters deeply, we "release" netboot regardless.
[20:43] <infinity> (And it's not actually tied to point releases)
[20:43] <slangasek> doko: do you have a pointer to scripts that will tell me if it needs a rename?
[20:44] <doko> slangasek, objdump -T | grep cxx11 ...
[20:44] <slangasek> ok
[20:44] <doko> once you built the package
[20:44] <davmor2> infinity: so the tests we run are as follows on netboot, install desktop, install server.  Once you are happy that both install and run pass the tests as that covers them all
[20:44] <doko> now looking at  openexr
[20:45] <davmor2> yay finally got vmware player to work \o/
[20:45] <infinity> davmor2: !x86 should just be the install minimal case (as it is for ppc)
[20:45] <infinity> davmor2: I'm just inept at manipulating iso tracker testcases, so was suggesting that a QA type (*cough*) might want to make arm64 netboot look like ppc netboot.
[20:46] <davmor2> infinity: talk to jibel I have no idea how it works and doubt I have access either
[20:48] <infinity> davmor2: Heh.
[20:48] <infinity> stgraber: ^ :P
[20:49] <davmor2> infinity: don't forget I used to work with the iso.tracker before it was the iso.tracker :)
[20:49] <davmor2> infinity: in those days you wrote out steps in wikipages
[20:50] <infinity> davmor2: I've intentionally avoided learning how it works, cause I'm afraid I'll forget something useful if I do.
[20:51] <davmor2> infinity: https://fm-coresites-assets.s3.amazonaws.com/whitelines_new/wp-content/uploads/2014/11/homer-simpson-every-time-i-learn-something-new1.jpg
[20:51] <infinity> davmor2: Exactly that.
[20:53] <stgraber> infinity: all the netboot links seem busted, not really feeling like fixing them all now
[20:53] <stgraber> those that work don't point to -updates, so you're still going to get the wrong thing
[20:54] <infinity> stgraber: I'm less concerned about the links.  Honestly, if people testing don't know how to find the thing they're testing, I question the quality of their test results too.
[20:57] <stgraber> infinity: should be all better now
[20:58] <infinity> stgraber: Probably don't need the desktop ones for armhf/arm64 (at least, not as mandatory)
[20:58] <infinity> Pretty sure the desktop is broken on at least one of them. :P
[20:58] <slangasek> doko, xnox: so uhd ftbfs with type conversion errors.  I understand the message but have no idea how to fix.  Anyone with C++ chops want to take a look?  https://launchpad.net/ubuntu/+source/uhd/3.7.3-1ubuntu1/+build/7764394
[20:59] <slangasek> (nothing changed in the code here, just in the language spec apparently)
[21:01] <Laney> slangasek: I mean that it's meant to be able to handle partial suites and if it doesn't then it'll be a bug
[21:02] <slangasek> I thought we pre-merged the packages files for it so it didn't have to handle the partial suites at all
[21:02] <Laney> until it got upstream support for that, yes
[21:03] <slangasek> doko: I see spatialite is done building
[21:03] <doko> yes, will revert my gdal removals ...
[21:03] <slangasek> cheer
[21:03] <slangasek> s
[21:04] <doko> and its 11pm here
[21:05] <slangasek> doko: do you want me to take care of gdal?
[21:05] <doko> no, uploading
[21:06] <slangasek> haha, libcec2->libcev5, oops
[21:06] <slangasek> guess I should fix that script
[21:08] <infinity> slangasek: Close enough.
[21:08] <infinity> Oh neat.  Massive thunderstorm just came out of nowhere.  If I stop talking for a while, I'm probably not dead, but my electricity might be.
[21:14] <Laney> oho, just seen who the maintainer of lucene++ is
[21:19] <doko> bah, all the buildds blocked ...
[21:21] <Laney> juju add-unit buildd
[21:21] <slangasek> this etherpad is making me angry
[21:21] <slangasek> having to reconnect between every single edit
[21:22] <doko> yes, annoying
[21:29] <cjwatson> Laney: soon :-/
[21:30] <doko> infinity, could you have a look at https://launchpadlibrarian.net/213711445/buildlog_ubuntu-wily-powerpc.openexr_2.2.0-1ubuntu2_BUILDING.txt.gz ?
[21:31] <cjwatson> doko: suspect that would be rather more useful if it catted test-suite.log on failure
[21:32] <cjwatson> dear scalingstack, actually update your images so that I can finally get gem2deb to build, kthx
[21:32] <Laney> make check VERBOSE=1 # iirc
[21:32] <cjwatson> yes
[21:32] <doko> anyway, too tired now, and travelling tomorrow
[21:33] <cjwatson> well I use VERBOSE=1 dh_auto_test in my packages but same deal
[21:33] <cjwatson> oh, there we go, at least lgw01 is upating
[21:33] <cjwatson> *updating
[21:33] <cjwatson> yep, both
[21:33] <cjwatson> reset spree!
[21:33]  * Laney wonders if the new debhelper maintainers would add that
[21:40] <cjwatson> I guess now would be a bad time for a mass give-back of dep-waits
[21:40] <cjwatson> maybe tomorrow
[21:41] <infinity> cjwatson: I have no problems with doing it now.  It's not going to block .3 in any way.  Or are you more concerned about accidentally making the C++ transition worse instead of better?
[21:42] <cjwatson> I'm more worried about backing up the build queues even worse while people are actually waiting for stuff.
[21:42] <cjwatson> Kind of a pain if you're trying to push through a multi-layered transition.
[21:43] <infinity> cjwatson: The only queue currently is arm64.  It'll drain soonish.  I can do a mass give back of -FDC after that.
[21:43] <cjwatson> -D is the one that bothers me because of the wrongness of 132's dep-wait handling.
[21:44] <infinity> cjwatson: Wrongness of dep-wait handling implies that F might also be D in disguise, though.
[21:44] <cjwatson> But I guess some of them probably ended up as failures.
[21:44] <cjwatson> Yeah.
[21:44] <infinity> cjwatson: Hence I was just going to do the lot.
[21:44] <cjwatson> https://launchpad.net/ubuntu/+source/gem2deb/0.20.2/+build/7742800 \o/
[21:45] <cjwatson> cue something else exploding now that something with build profiles might manage to make it through to wily ...
[21:45] <infinity> cjwatson: Does your cargo-cult mean we don't need scary SRUs, or do we still need that for other bits of infra?
[21:45] <cjwatson> We might need it for other bits.
[21:45] <infinity> cjwatson: They're still on my TODO, but my TODO has been pretty gross.
[21:45] <cjwatson> I have a suspicion germinate is going to be sad.
[21:45] <cjwatson> I'll sort it out tomorrow if so.
[21:45] <infinity> cjwatson: Kay.  I'm more comfy with trusty having the "final" version of the implementation anyway.
[21:46] <infinity> cjwatson: The half-baked one we shipped is asking for trouble.
[21:46] <cjwatson> precise is more questionable, but we can put stuff in infra-only PPAs/CAT/blah.
[21:46] <infinity> For precise infra, I'd prefer backports, yes.
[21:47] <cjwatson> My cargo-cult plus my changes to Launchpad to use python-debian instead (and the fact that LP uses a python-debian from PyPI rather than the archive) make it less scary.
[21:47] <infinity> If we cared about precise users and profiles, I'd say the patches that were floated that flat-out ignore profiles would be the better SRUs.
[21:47] <cjwatson> It's possible we can get away without changing python-apt in precise.
[21:48] <infinity> I'd really rather not have precise infra at all, but wishes and reality so rarely align.
[21:48] <cjwatson> Sadly the edict about trusty on metal makes that a long-term project.
[21:49] <infinity> cjwatson: Well, we're already running a backport of trusty's apt/python-apt on ftpmaster, I assume that can be true of any infra that needs it.
[21:49] <infinity> cjwatson: So, SRUs to trusty and a re-backport should serve us.
[21:49] <cjwatson> ftpmaster shouldn't actually need it though.
[21:50] <infinity> cjwatson: No, but it has a backport was my point. :)
[21:50] <cjwatson> LP no longer uses those bits of python-apt, and if germinate goes wrong it can be worked around.
[21:50] <cjwatson> Right, true, though that was safe for ftpmaster because we had a very clear idea of which bits of apt/python-apt it needed.
[21:50] <infinity> I don't remember why it has a backport.  source cachine?
[21:50] <cjwatson> Yes.
[21:50] <infinity> caching*
[21:50] <cjwatson> Which actually hasn't been SRUed to trusty yet.
[21:50] <cjwatson> I think.
[21:50] <infinity> Oh.  That should be fixed.
[21:51] <infinity> I think we've verified that in the field quite successfully by now. :P
[21:51] <cjwatson> Every so often I try but get gazumped by a security update or something.
[21:52] <infinity> gazumped = trumped by a gazelle?
[21:52] <cjwatson> https://en.wikipedia.org/wiki/Gazumping
[21:52] <infinity> I refuse to believe this is actually a word.
[21:54] <infinity> Oh, it's yiddish.  Suddenly, it all makes sense.
[21:54] <slangasek> infinity: it's only UK english, it doesn't count
[21:54] <cjwatson> wiktionary thinks it's possibly derived from Hebrew via Yiddish
[21:54] <cjwatson> Yeah, that
[21:56] <slangasek> dear Internet I demand that you have created  a "gazumpty dance" parody for my viewing pleasure
[21:56] <slangasek> Internet I am disappoint
[21:57] <Daviey> oh dear, rule #34.
[21:57] <infinity> slangasek: A cross between the humpty dance, the Horah, and possibly hamsterdance?
[21:57] <slangasek> pretty sure that's not covered by rule #34, but ymmv
[21:58] <slangasek> infinity: that would work
[21:58] <infinity> slangasek: I'll get right on it after the point release.  Please register a domain.
[22:37] <darkxst> infinity, I have not heard of any issues (other than zsync problems)
[22:38] <infinity> darkxst: Kay.  We're just a bit sparse on test results in the tracker. :)
[22:38] <infinity> darkxst: Granted, you have until tomorrow to tell me it's all good.  But you probably have until a few hours from now to tell me it's horribly broken so we can fix it. :P
[22:40] <infinity> utlemming: (Not that I care if you are or aren't on the tracker, but) are you guys on track for a 14.04.3 cloud release tomorrow?
[22:40] <infinity> utlemming: I realise you "release" every 23 minutes anyway, perhaps we should stop pretending you do point releases. :P
[22:41] <darkxst> infinity, the previous build should have been mostly complete
[22:41] <utlemming> infinity: we do informal point releases....just a pointer switch anyway
[22:41] <utlemming> infinity: but we only pretend because otherwise people ask "where's dot whatever"
[22:41] <infinity> utlemming: Yup.  Even long time users don't really seem to understand that a "point release" is really just a moment in time in the archive.
[22:42] <infinity> utlemming: With the exception of installation media, of course, but as you spin your images constantly, that's a bit of a non-issue for you.
[22:42] <infinity> utlemming: Anyhow, original question, then, do you have things you've tested and will be happy to bless as ".3" tomorrow?
[22:42] <utlemming> infinity: yes, we do
[22:42] <darkxst> infinity, but looking, seem i386 testing has been sparse
[22:43] <infinity> utlemming: Excellent.  Thanks.
[22:43] <utlemming> infinity: we're good on our end and will have something to call .3
[22:44] <infinity> utlemming: For bonus points, I fixed that live-build bug you forgot to SRU, so your images should not have a broken initctl/dpkg-whateveritwas anymore. :P
[22:45] <utlemming> infinity: oh, nice, thank you kindly :)
[22:45] <infinity> utlemming: Assuming you're using the archive live-build, and not still a fork.  I can't keep track.
[22:46] <utlemming> infinity: depends on the release. We started using upstream with live-builders for Vivid
[22:46] <infinity> utlemming: "upstream" meaning Ubuntu, or pulling in a newer Debian version?
[22:46] <infinity> utlemming: If you need a new version, I wouldn't be at all opposed to you helping to merge it in Ubuntu.  Hint, hint.
[22:47] <utlemming> infinity: upstream for Ubuntu. For Vivid and later, we use launchpad builders
[22:47] <utlemming> infinity: hint noted
[22:47] <infinity> It's one of the ugliest merges, because upstream insists on renaming functions and variables every seven minutes. :/
[22:47] <infinity> So pretty much none of our patches ever forward-port without excessive alcohol and tears.
[22:48] <utlemming> infinity: I noticed...its one of the reasons we dropped our fork. I don't think normal excessive alcholo is strong enough for that merge. You need genuine absynthe for that.
[22:51] <infinity> utlemming: Hallucination might help, I agree.
[23:22] <darkxst> infinity, quick test of 14.04.3, just booted to a VT
[23:22] <infinity> darkxst: i386?
[23:22] <darkxst> (into fresh installed system) gdm was never even started
[23:22] <darkxst> infinity, amd64
[23:23] <infinity> darkxst: That's... Curious, given that you had solid tests on the previous image.
[23:23] <infinity> And nothing really should have changed to break you.
[23:23]  * infinity grabs a gnome image.
[23:23] <darkxst> infinity, second boot worked fine
[23:23] <infinity> darkxst: ...
[23:23] <infinity> darkxst: Is it possible your computer hates you?
[23:24] <darkxst> infinity, its Vmware
[23:24] <infinity> So, yes.
[23:24] <infinity> darkxst: I have no vmware to test, but I'll spin it up on qemu and see if I can reproduce.  If not, I'm blaming vmware.
[23:25] <infinity> Oh, hey, I have a spare laptop here, I can even test real hardware.
[23:25] <infinity> Which is slightly more important to get right.
[23:28] <darkxst> infinity, vmware is not a buggy pos like vbox
[23:28] <infinity> darkxst: Heh.  No, but all three of the common virt solutions seem to have their own special quirks.
[23:28] <infinity> darkxst: Anyhow, I'm grabbing an ISO to see what I can see.
[23:29] <infinity> My life tonight is nothing but testing, I think.
[23:29] <infinity> And chicken.  I need to eat all the chickens.
[23:30] <slangasek> with or without avian flu?
[23:31] <infinity> slangasek: Not actually picky at this point.  A neighbor is frying chicken, and I'm starving.  The combination of those two truths isn't leading to rational thought.
[23:31] <slangasek> alrighty then
[23:32] <infinity> Aaaand, 92% into this download, I realise I'm downloading wily, not trusty.
[23:32] <infinity> Derp.
[23:34] <infinity> The important thing is that my mom says I'm smart.
[23:35] <slangasek> ok how is gdal less installable now than it was two hours ago?
[23:36] <infinity> slangasek: So, I'm no expert, but I'm going to go with "something changed".
[23:36] <slangasek> hmm maybe I should dist-upgrade that chroot
[23:51] <infinity> darkxst: Anything special about your install?  I'm just doing default clicks through on a laptop and on a qemu VM right now.
[23:52] <darkxst> infinity, no it was just defaults
[23:57] <infinity> darkxst: qemu version rebooted to gdm first shot.  Still waiting on the real metal install to finish being a slowpoke.
[23:57]  * infinity realises he has no idea how to use gnome-shell...
[23:59] <infinity> darkxst: Real laptop install rebooted into gdm too.
[23:59] <infinity> darkxst: So, either you have a racy bug that sucks to reproduce, a vmware-specific bug, that install just plain failed somehow, or your computer hates you.
[23:59] <infinity> darkxst: Not sure which explanation is more pleasant.