=== liam_ is now known as Guest35623
[00:26] <slangasek> doko_: I'll go ahead and upload it
[00:28] <geofft> Hi folks. Almost any use of LD_AUDIT on amd64 on Precise/Quantal causes a segfault due to a bug in libc6 that's been fixed upstream
[00:28] <geofft> The patch is fairly tiny (it just checks for null, mostly). Is it reasonable to expect an SRU for this?
[00:28] <geofft> This bug makes latrace, for instance, completely useless
[00:28] <infinity> geofft: Is there a bug filed?  With a pointer to the upstream fix?
[00:29] <infinity> geofft: Expecting an SRU for something I haven't heard of until today is probably wishful thinking.  But I can certainly include it in my next SRU round if I know about it.
[00:29] <geofft> Not yet. Just wanted to check it was worth doing so, or whether libc6 is too scary to be worth doing non-security SRUs for
[00:29] <geofft> inifinity: Yeah, I'm totally happy to file a bug then describing it. Thanks!
[00:29] <sarnold> hey geofft :)
[00:30] <geofft> Oh, bad phrasing on my part, "expect" = "expect that a bug will be useful", not "expect it'll automatically get fixed"
[00:30] <geofft> hi sarnold!
[00:30] <infinity> geofft: File a bug and point me to it.  I do SRU glibc occasionally, as you can spot from the changelog.
[00:31] <infinity> geofft: I won't SRU *just* for minor bugs like that, but if there are some easy cherrypicks I can do to make pepole happy at the same time as fixing more serious bugs, I'll do it.
[00:31] <geofft> Do you want the standard SRU format [Impact] etc.?
[00:31] <slangasek> yes :)
[00:31] <infinity> geofft: If you're willing to do the full SRU template, go nuts.  Saves me the effort.
=== freeflying_away is now known as freeflying
[00:41] <slangasek> doko_: well, or I would upload it, except it doesn't pass its test suite
[00:41] <slangasek> which is puzzling, because the error is obvious, the test is looking for a file in the build dir that it needs to look for in the source dir
[00:48] <slangasek> doko_: the tests are broken with glib2.0 (>= 2.37.2), there's some goofy g_test_get_filename() function here that doesn't work.
[00:50] <slangasek> which relies on setting G_TEST_SRCDIR, which nothing does.
=== freeflying is now known as freeflying_away
[01:01] <geofft> infinity: Filed LP #1243473. Let me know if you need more detail.
[01:01] <ubottu> Launchpad bug 1243473 in eglibc (Ubuntu) "LD_AUDIT is broken on amd64" [Undecided,New] https://launchpad.net/bugs/1243473
[01:01] <geofft> Relatedly, LD_AUDIT is the awesomest thing ever, and latrace is like ltrace that actually works. (Well, modulo that bug.)
[01:03] <em> what kernel is the latest ubuntu using?
[01:07] <sarnold> em: saucy's kernel version in the package name is 3.11.0-12.19
[01:09] <sarnold> em: "Ubuntu 13.10 includes the 3.11.0-12.19 Ubuntu Linux kernel which was based on the v3.11.3 upstream Linux kernel. " https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes
[01:10] <infinity> geofft: That should be enough, thanks.
[01:11] <sarnold> geofft: cool, thanks for the fun new tool recommendation :)
[01:14] <slangasek> doko_: ok, pango1.0 uploaded finally
=== _salem is now known as salem_
=== salem_ is now known as _salem
[01:49] <Logan_> doko_: Are you around?
[01:50] <Logan_> Or cjwatson?
[01:50] <infinity> Logan_: Just ask your question...
[01:51] <Logan_> Bleh, okay. Thought it merited their specific attention for specific reasons. :P Is 14.04 deriving from unstable or testing? Because doko_'s email says that syncs are running from unstable.
[01:51] <Logan_> But I thought LTS releases derive from testing.
[01:52] <infinity> It's from unstable.  Now that we have proposed-migration, syncing from testing doesn't buy us much, and tends to just slow us down.
[01:52] <Logan_> Alright, cool. https://wiki.ubuntu.com/LTS should be updated, then.
[01:52] <Logan_> Why is ubuntu-dev-tools's syncpackage script defaulting to syncing from testing, then?
[01:53] <infinity> Because someone didn't get the memo, I suspect.
[01:53] <infinity> I'll fix that.
[01:55] <Logan_> It doesn't seem that it was specifically set to that for trusty. I wonder if there's a config in there for every x releases deriving from testing.
[01:55] <infinity>             if ubu_info.is_lts(ubu_info.devel()):
[01:55] <infinity>                 dist = 'testing'
[01:55] <infinity> That bit just needs to go away.
[01:55] <Logan_> Oh, yup.
[01:56] <Logan_> Want me to file a bug, or are you going to handle it?
[01:57] <infinity> I'll fix it right now.  But for now, you can just use '-d unstable'
[02:01] <infinity> Oh, xnox already fixed it.  Which is why I can't find the bits in bzr. :P
[02:02] <infinity> Logan_: It's correct in bzr, it's just not been uploaded yet.  I assume bdrung will get around to pushing it to Debian and syncing soon.
[02:03] <Logan_> Okay, awesome. Thanks for your help, Adam!
[02:03] <infinity> Or maybe I'll upload it to Debian now, so more people don't end up confused.
[02:03] <infinity> bdrung: Were you planning an ubuntu-dev-tools upload to sid?  Mind if I do one?
[02:04] <Logan_> You might cause a conflict! :P
=== freeflying_away is now known as freeflying
=== ION is now known as ion
=== freeflying is now known as freeflying_away
[05:18] <Noskcaj> Is it ok to merge stuff from unstable now, due to proposed-migration?
=== freeflying_away is now known as freeflying
[05:41] <sarnold> Noskcaj: yes, that was discussed a few hours ago, and syncing from unstable is now the new desired state
[05:41] <Noskcaj> sarnold: ok, thanks for the info.
[05:41] <sarnold> Noskcaj: ubuntu-dev-tools's syncpackage script has apparently been fixed in bzr already, just not re-packaged yet
[05:42] <pitti> Good morning
[05:43] <sarnold> morning pitti :)
[05:43] <ScottK> Noskcaj: Unless someone is known to be inactive, up until DIF you should check with the last person to touch a merge before doing it.
[05:43] <ScottK> pitti: Your upower patch worked great.  I look forward to testing the SRU when it's ready.
[05:43] <ScottK> Thanks.
[05:43] <pitti> ScottK: nice; I'll prepare one today then
[05:43] <sarnold> ScottK: DIF?
[05:43] <ScottK> Debian Import Freeze.
[05:44] <sarnold> thanks :)
[05:46] <pitti> doko_: there's also a bug for it, debian bug 724842
[05:46] <ubottu> Debian bug 724842 in src:cracklib2 "cracklib2: FTBFS: error connecting to "www.oasis-open.org" (Connection timed out)" [Serious,Open] http://bugs.debian.org/724842
[05:46] <Noskcaj> ScottK: don't worry, i have asked myself ;)
[06:15] <Noskcaj> smb: Do you plan to upload a newer dahdi-linux any time soon?
[06:16] <Noskcaj> pitti: bug 1079605
[06:16] <ubottu> bug 1079605 in initramfs-tools (Ubuntu) "[FFe] Please sync with the latest 0.113 from Debian testing" [High,Triaged] https://launchpad.net/bugs/1079605
[06:16] <pitti> doko_: fixed cracklib uploaded to Debian, will autosync
[06:16] <pitti> Noskcaj: yeah, infinity wanted to have a look at some point, but I guess he was busy
[06:18] <Noskcaj> ok, thanks for the info
[06:18] <pitti> Noskcaj: we have a quite a large delta, and some of it is hopefully not required any more, etc.
[06:18] <pitti> Noskcaj: so if you feel like looking into it and making a first assessment of our delta, please feel free :)
[06:19] <Noskcaj> pitti: I would have no idea where to start
[06:19] <pitti> Noskcaj: ah, that's fine; I thought you asked because you considered doing the merge
[06:20] <Noskcaj> Not for something that big, i was just checking that it hadn't been forgotten
[06:22] <Noskcaj> That said, if anyone has merges for me to do, i've finished with all the packages that are in my name
[06:25] <pitti> Noskcaj: if you want to steal some of mine, I'd be in your debt :) (but perhaps avoid aptdaemon)
=== iahmad_ is now known as iahmad
=== jamesh__ is now known as jamesh
[06:49] <pitti> ScottK: upower SRU uploaded and bug updated for SRU, FYI
[06:52] <geofft> Agh, I'm confused about multiarch. Why do libc6-i386 and libc6:i386 both exist?
[06:53] <slangasek> geofft: libc6:i386 is just the native build of libc6 for i386.  libc6-i386 is a "biarch" (or "multilib") build of libc6, packaged for amd64, because some things aren't yet solved using multiarch
[06:53] <slangasek> like, the compiler itself
[06:55] <geofft> So I legitimately need both? OK
[06:56] <slangasek> you legitimately need both if you have packages installed that depend on each :)
[07:05] <Noskcaj> My requestsync keeps breaking, so would someone mind syncing visp and osgearth?
[07:10] <bkerensa> software-properties-gtk seems to be epic broken in trusty
[07:10] <bkerensa> its crashing pretty rapidly
[07:11] <Noskcaj> bkerensa: It didn't open for me last time i tried
[07:11] <bkerensa> Noskcaj: exactly it didnt open and whoopsie dialog popped up
[07:12] <bkerensa> a quick look in syslog now shows a line a second of software-properties-gtk crashing and whoopsie sporadically trying to report it
[07:12] <bkerensa> looks like there is not software-properties-gtk candidate for trusty either
[07:12] <bkerensa> aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/trusty
[07:12] <bkerensa> thats the issue
[07:14] <Noskcaj> pitti: I've merged gpgme1.0 for you, have you got time to review the branch?
[07:14] <pitti> Noskcaj: sure
[07:15] <Noskcaj> plus you should be safe to sync visp
[07:15] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/gpgme1.0/1.4.3/+merge/192293
[07:15] <Noskcaj> I'll try and work on psqlodbc now
[07:18] <pitti> Noskcaj: oh, did the DD take the autopkgtest fix?
[07:19] <pitti> Noskcaj: ah no, visp needs a merge
[07:19] <Noskcaj> pitti: Looks like it from the changelog
[07:19] <pitti> Noskcaj: plus, it never built on i386 for us due to a test failure
[07:20] <cjwatson> what entry in the Debian visp changelog suggests that they took our change?
[07:20] <pitti> Noskcaj: nope, I filed debian bug 726983 much later
[07:20] <ubottu> Debian bug 726983 in visp "visp: autopkgtest failure due to stderr output from test program" [Normal,Open] http://bugs.debian.org/726983
[07:21] <cjwatson> even a cursory debdiff makes it clear they didn't.  Please put more effort into verification or else don't request syncs
[07:21] <cjwatson> otherwise you're throwing away other developers' work
[07:21] <Noskcaj> crap, i was looking at a different package as well, i am sorry for wasting yourtime
[07:25] <pitti> Noskcaj: gpgme uploaded, thanks
[07:26] <bkerensa> Noskcaj: I found the problem its python-apt well slangasek found it :) but I am going to fix it
[07:26] <Noskcaj> thanks bkerensa
[07:26] <Noskcaj> pitti: no problem, i shouldn't have copy/pasted the chagelog though
[07:27] <pitti> Noskcaj: oh, copy&pasting them is fine in general (everyone does that anyway), it just sometimes needs some trimming for the slightly different context
[07:31] <Noskcaj> pitti: gpgme is FTNFSing, give me a minute to disable the bad (gnupg2) test
[07:31] <Noskcaj> *FTBFS
[07:48] <pitti> Laney: can you please add an autopkgtest override for bzr-builddeb? This has never worked, and is now blocking python-apt from propagating (new version fixes a lot of things due to the added trusty template)
[07:48] <pitti> bkerensa: ^ FYI
[07:49] <bkerensa> :D
=== freeflying is now known as freeflying_away
[08:06] <Noskcaj> pitti: It might be better if you fix the ftbfs for gpgme1.0 since my only fix is disable dh_auto_test (which fully works)
[08:07] <Laney> pitti: okay, but "never worked"> someone should look into that, of course
[08:07] <pitti> Laney: yes, of course; but it shouldn't block the propagation
[08:07] <pitti> Laney: once the sync/build/binNEW rush settles down a bit, I'm planning to go through/fix/poke people all of the failures
[08:08] <Laney> well, it's correct that it does as that is how the integration is specified
[08:09] <Laney> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-bzr-builddeb/
[08:09] <Laney> why can't I see the details in the jobs?
[08:09] <Laney> can in trusty
[08:11] <pitti> Laney: right, but bzr-builddeb was failing in saucy, and it's not the new python-apt which breaks bzr-builddeb
[08:12] <pitti> Laney: hm, I don't know why the later saucy builds are broken in that way
[08:18] <Noskcaj> cody-somerville: Do you plan to keep maintaining catfish in debian?
[08:18] <Noskcaj> If so, it really needs an upload. if not, please file a wnpp bug
[08:18] <didrocks> pitti: ah, bzr-builddeb was already failing?
[08:19] <didrocks> we don't have that traced, I was trying to reproduce… (but can't on my installed saucy machine)
[08:19] <didrocks> and yeah, python-apt doesn't change a thing tried
[08:20] <didrocks> Laney: pitti: I was tracking it as this is one of the last piece blocking us to resume releasing things to trusty
[08:20] <didrocks> (we can't run the tests as add-apt-repository is failing as we don't have latest python-apt)
[08:20] <bkerensa> Has trusty patch pilots officially kicked off yet?
[08:20] <pitti> didrocks: you mean bzr-builddeb or p-apt?
[08:20] <pitti> didrocks: ah, so p-a
[08:21] <didrocks> yeah, p-a
[08:22] <bdrung> infinity: i can do the upload now. do you want to add yourself and do the upload to unstable?
[08:31] <Laney> I added the force-badtest
[08:32] <Laney> but I don't think I'm a fan of "it wasn't me that broke the tests, so let's ignore them"
[08:32] <Laney> We should have noticed when they started failing in saucy and fixed it then
[08:32] <Laney> Not that I can actually reproduce the failure under run-adt-test :(
[08:53] <pitti> no? I can
[08:54] <Laney> I got it in a plain chroot
[08:54] <Laney> missing python-distro-info test-dep but then there's one more failure
[08:59] <ogra_> pitti, Laney i guess bug 1243573 is for one of you :)
[08:59] <ubottu> bug 1243573 in Ubuntu system image "Timezone setting is gone after upgrade to Ubuntu Touch touchy" [Undecided,New] https://launchpad.net/bugs/1243573
[08:59] <Laney> Ubuntu Touch touchy
[08:59]  * Laney blinks
[08:59] <ogra_> haha
[09:04] <pitti> bug in our "synced" system-image writable-files mode?
[09:05] <ogra_> pitti, probably, i didnt research it, there were so many errors with that upgrade
[09:06] <ogra_> (apps all vanished, system-image-cli didnt allow me to switch channels etc)
[09:07] <pitti> ogra_: (followed up to the bug)
[09:08] <ogra_> thx
[09:08] <bdrung> where to report recipe build failures to (that are caused by the build infrastructure)?
[09:08]  * ogra_ guesses against launchpad
[09:09] <cjwatson> bdrung: launchpad-buildd
=== freeflying_away is now known as freeflying
[09:09] <bdrung> thanks
[09:09] <cjwatson> bdrung: but check the existing reports, there are a few standard ones in there that are blocked on host upgrades
[09:10] <Laney> ogra_: I think the upgrade wiped out more than it should have
[09:10] <Laney> I lost my accountsservice settings too
[09:10] <ogra_> my U1 account stayed
[09:10] <Laney> e.g. greeter background and it showed me the first run tutorial
[09:10] <ogra_> and my wallpaper too
[09:11] <ogra_> same for language
[09:11] <Laney> I said greeter backgroudn on purpose
[09:11] <Laney> the unity background stayed, and that is in gsettings
[09:11] <ogra_> all apps were gone for me ...
[09:11] <Laney> also had a new SSH host key, but I can't remember if that's expected when using phablet-flash
[09:13] <popey> Laney: you lost data when going from saucy to trusty?
[09:14] <Laney> my home directory is intact
[09:14] <bdrung> cjwatson: i found the bug already reported: it is bug #1089615
[09:14] <ubottu> bug 1089615 in launchpad-buildd "Source builds fail for packages with "3.0 (quilt)" format and unapplied patches" [Low,Triaged] https://launchpad.net/bugs/1089615
[09:15] <ogra_> popey, i lost all apps here, data stayed
[09:15] <popey> hmm
[09:15] <ogra_> (i didnt have to newly log in to G+ but had to reinstall the app)
=== psivaa is now known as psivaa-afk
=== freeflying is now known as freeflying_away
[09:37] <Laney> pitti: argh, finally got it
[09:38] <Laney> If you don't have libalgorithm-merge-perl installed then dpkg-mergechangelogs generates conflicts in some situations when it doesn't if you have it installed
[09:38] <Laney> One of which is in the bzr-builddeb testsuite
[09:39] <Laney> It's a Recommends of dpkg-dev
[09:39] <pitti> Laney: ah, so somehow libalgorithm-merge-perl made it into my VM test, but not into your's?
[09:40] <Laney> I must have had both python-distro-info and libalgorithm-merge-perl installed for the tests to succeed, but the jenkins VMs didn't
[09:41] <Laney> so there's a difference somewhere between run-adt-test and those
[09:41] <pitti> so they need to become test deps?
[09:41] <Laney> in terms of dep installation
[09:41] <Laney> and that, yes (well, I'm not sure if libalgorithm should actually be a real dep?)
[09:42] <Laney> It's an implementation detail of dpkg-dev, but bzr-builddeb relies on calling that program to merge changelogs
[09:44] <pitti> ah, so that's what one would need to uninstall to get back the old conflict markers
[09:45] <Laney> old ones?
[09:45] <pitti> I find that automatic changelog merging often sorts wrongly, and it's much less obvious what it damaged
[09:45] <Laney> you mean within one entry?
[09:46] <pitti> no, I mean it mis-sorts the older ubuntu entries in between the debian ones
[09:47] <cjwatson> I often let it merge but then use "bzr shelve --destroy" to throw away the mis-sorting / other changes
[09:47] <pitti> (often, anyway)
[09:47] <cjwatson> particularly for changelogs in very old packages that contain misformatted junk at the bottom but I don't think it makes sense to reformat that in an Ubuntu delta
[09:47] <pitti> but then again, it's been a while since I actually used bzr for merging, so maybe that got fixed
[09:49] <Laney> Oh, well the testsuite allegedly checks for that
[09:49] <Laney> Anyway, I'll just add them as test-deps I think
=== freeflying_away is now known as freeflying
[09:57] <cjwatson> pitti: FYI I rejected entangle as it was mistakenly uploaded to saucy.  Not sure whether you get notified as the sponsor
[09:58] <alexbligh> Is there a way to make specific files in a .deb that are in /etc **NOT** conffiles? I have a directory similar to a .d directory which contains a bunch of stuff put there by the package and also a bunch of stuff put there by users. I don't want to delete the directory on package removal or I'll lose the user's stuff (so I don't really want to symlink out of /etc). However, I do want the individual files the pack
[09:58] <alexbligh> age installed to be removed (because the new version tends to install other files with slightly different names). What's the best way to do this?
[09:58] <pitti> cjwatson: argh, thanks; autofingers still need readjustment..
[09:58] <pitti> cjwatson: reuploaded to trusty
[09:58] <cjwatson> alexbligh: Use dpkg-maintscript-helper's tools to manage the upgrade changes
[09:59] <cjwatson> alexbligh: And keep them as conffiles
[09:59] <pitti> cjwatson: yes, I got a rejection mail
[09:59] <alexbligh> cjwatson, are they on Lucid?
[09:59] <cjwatson> alexbligh: (note that you can use debian/foo.maintscript to make this fairly easy; see dh_installdeb(1))
[09:59] <cjwatson> alexbligh: It would be quicker for you to check than me, if you have a setup
[09:59] <alexbligh> cjwatson, thanks, will do.
[10:00] <cjwatson> alexbligh: But apparently not; on lucid the correct thing to do is to simulate the same actions by hand in maintainer scripts
[10:00] <cjwatson> (carefully)
[10:01] <alexbligh> cjwatson, complete brainfart here, target is Precise these days. Not enough tea.
[10:01] <cjwatson> precise has dpkg-maintscript-helper so it's all much easier
[10:01] <cjwatson> https://wiki.debian.org/DpkgConffileHandling if you need to backport to earlier releases
[10:03] <alexbligh> cjwatson, thanks once more
[10:06] <shadeslayer> tseliot: ping
[10:06] <mardy> didrocks: hi! Any idea why this is failing? https://code.launchpad.net/~mardy/signon/packaging/+merge/190911
[10:07] <shadeslayer> tseliot: I was looking at https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1224098 and preinst.in seems a bit weird to me, line 19-20
[10:07] <ubottu> Ubuntu bug 1224098 in nvidia-prime (Ubuntu) "xserver wont start after nvidia-prime installation" [Undecided,Confirmed]
[10:07] <shadeslayer> -s returns true if the file exists and size is greater than zero, but then there's a ! before it ... why?
[10:09] <didrocks> mardy: reusty is not there yet, we are working on it
[10:11] <tseliot> shadeslayer: let me have a look
[10:11] <shadeslayer> ack
[10:16] <tseliot> shadeslayer: it's obvious a bug (some leftover I assume)
[10:16] <tseliot> *obviously
[10:16] <shadeslayer> ack :)
[10:16] <shadeslayer> tseliot: want to sponsor a upload ? :D
[10:17] <shadeslayer> also, shouldn't checking -s suffice?
[10:18] <tseliot> shadeslayer: I'll request an SRU for precise and saucy and upload. I'll need some help testing the fix (so that the SRU team can approve it)
[10:18] <tseliot> yep
[10:18] <tseliot> that's why I said "leftover"
[10:18] <shadeslayer> roger roger
[10:19]  * shadeslayer goes back to looking at bugs
[10:20] <infinity> pitti: I'll be doing a bi-directional merge of initramfs-tools in the next week or two.  It's high on my list.
[10:21] <pitti> infinity: ah, you can do changes in Debian, too? convenient
[10:21] <infinity> bdrung: I did a bzr snapshot upload of ubuntu-dev-tools to Ubuntu, but whenever you do the Debian upload, you can just sync over that.
[10:21] <infinity> pitti: I should hope I can, I've been upstream for it since it was written.
[10:21] <bdrung> infinity: okay, i will do the debian upload now. do you want to SRU that fix to saucy?
[10:22] <infinity> (Granted, not a very active upstream since maks took over)
[10:22] <infinity> bdrung: I'm not terribly picky about SRUing it back, since I run the devel release, but if you want to push it back to saucy and maybe precise, go nuts.
[10:28]  * pitti sets up trusty LP apport retracers
=== freeflying is now known as freeflying_away
[11:05] <tseliot> shadeslayer: are you available to test a package locally?
[11:06] <shadeslayer> tseliot: not the nvidia-prime one :P
=== doko_ is now known as doko
[11:06] <shadeslayer> because I don't have a nvidia card
[11:06] <shadeslayer> I just noticed the bug in another channel, and decided to investigate
[11:06] <tseliot> shadeslayer: oh, never mind then
=== MacSlow is now known as MacSlow|lunch
[11:46] <mdeslaur> infinity: how did you fix mysql on arm64?
[11:46] <cjwatson> mdeslaur: was it an ICE or similar?
[11:47] <mdeslaur> cjwatson: yeah
[11:47] <cjwatson> mdeslaur: some of the builders have reliability issues; looks like he gave it back on birch, which is the best of them
[11:48] <mdeslaur> cjwatson: ah, cool. good to know, thanks
[11:48]  * mdeslaur gives birch a cookie
[11:48] <cjwatson> (birch has heat issues or something else that means we sometimes have to power it down for a bit, but it at least doesn't have random segfaults ...)
[11:49] <mdeslaur> cjwatson: what kind of hardware are they?
[11:50] <cjwatson> can't answer here just yet I'm afraid
=== psivaa-afk is now known as psivaa
[12:41] <cjwatson> OK, I think the remaining bits of the Perl 5.18 transition (aside from waiting for builds and a few more no-change uploads) are (a) libdr-tarantool/i386 FTBFS (b) gdal FTBFS (c) libmongodb-perl FTBFS
[12:54] <ScottK> pitti: upower SRU verified.  Thanks again for the quick turnaround.
[12:54] <pitti> ScottK: nice, thanks
=== MacSlow|lunch is now known as MacSlow
=== _salem is now known as salem_
=== freeflying_away is now known as freeflying
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== freeflying is now known as freeflying_away
=== liam_ is now known as Guest50369
[17:38] <ScottK> cjwatson: Just to double check before I accept this, you're OK with a grub2 SRU to fix the Kubuntu UEFI problem, right?  http://launchpadlibrarian.net/154805913/grub2_2.00-19ubuntu2_2.00-19ubuntu2.1.diff.gz
[17:41] <slangasek> are Kubuntu the only ones setting GRUB_DISTRIBUTOR?
[17:44] <ScottK> slangasek: I think Studio might have done so too,  but (and I didn't follow the details) there's some partial Kubuntu specific support for this already, so it's an easy fix, but for other flavors it'd be more complex.
[17:44] <slangasek> mmk
[17:45] <ScottK> I know Colin discussed it with shadeslayer  and apachelogger  before fixing in trusty, but (IIRC) he said the Kubuntu team needed to do the SRU.
[18:14] <gdos> !bug 1243839
[18:14] <ubottu> bug 1243839 in dwww (Ubuntu) "does not install completely. " [Undecided,New] https://launchpad.net/bugs/1243839
[18:16] <gdos> !bug 1243859
[18:16] <ubottu> bug 1243859 in dhelp (Ubuntu) "does not install completely (similar to #1243839)" [Undecided,New] https://launchpad.net/bugs/1243859
[18:40] <doko> barry, any update on the component mismatches?  from my side we should make sure that both pypy and python-cffi build on arm64 before promoting it
[18:42] <barry> doko: i agree with that.  i haven't done anything on it yet.  maybe tomorrow
=== salem_ is now known as _salem
[20:07] <slangasek> bah, why does top in trusty clear the screen on exit?  who thought that was a good idea? :P
[20:20] <slangasek> ev: so I have a strange issue here with apport; the crash file that I've managed to generate for unity8 on goldfish is missing a 'Package' field, which means apport-retrace will refuse to process it
[20:20] <slangasek> ev: have you heard of such a bug, or do you have any idea what might cause it?
[20:22] <ev> slangasek: have you run it through apport-cli yet?
[20:22] <ev> something needs to call add_package_info or whatever the function is
[20:22] <ev> whoopsie-upload-all will do this as well
[20:23] <slangasek> hmm, is that something that needs to be run on the target system, I guess?
[20:24] <slangasek> or at least, on some system where /usr/bin/unity8 exists
[20:25] <geofft> isn't this the -R option to apport-retrace?
[20:25] <geofft> apport-retrace --gdb doesn't work for me on /var/crash files, but --gdb -R does
[20:25] <slangasek> well, since I'm cross-retracing it, I don't want it to wind up with package information from my host system
[20:26] <slangasek> (particularly since unity8 isn't installed at all)
[20:29] <slangasek> ev: so running apport-cli on it on the target system seems unlikely to finish any time soon
[20:30] <slangasek> geofft: and -R seems to be insufficient, it still complains about the missing Package field
[20:30] <ev> slangasek: yeah, you need to collect the additional data (via apport-cli or whoopsie-upload-all) on the phone itself
[20:30] <slangasek> ev: hmm, challenging. :)
[20:31] <ev> :) sorry
[20:32] <slangasek> ev: yeah, apport-cli doesn't want to finish here (dies with 'Killed'), probably running out of memory
[20:32] <ev> eep
[20:32] <slangasek> perhaps I should spin up an emulator with a touch more than 90MB of RAM
[20:32] <ev> emulator? is that actually working for touch stuff?
[20:33] <slangasek> ev: no, if it were working I would not be trying to get a backtrace from unity8 ;)
[20:33] <cjwatson> ScottK: Yes, I'm fine with it.  It'll need a grub2-signed upload afterwards.
[20:33] <slangasek> but I do have a shell on it
[20:33] <ev> :D
[20:33] <slangasek> and am trying to get us to the next step
[20:33] <ScottK> cjwatson: Thanks.
[20:43] <stgraber> slangasek: based on what I'm seeing on real devices, I gues you'd need at least 512MB to have the emulator emulate something vaguely close to reality
[20:43] <slangasek> quite possible :)
[20:43] <slangasek> in fact, maybe trying to run it in 96MB of RAM is why unity8 segfaulted ;)
[20:44] <slangasek> interesting, updating the config did not cause it to run with more RAM
[20:44] <stgraber> considering it's taking almost 200MB on a physical device, that'd be a safe bet ;)
[20:44] <slangasek> xnox: do you know how to get more than 96MB of RAM out of goldfish?
[20:48] <slangasek> ah, guess it's just -memory
[20:48] <rampageRipper> hello world,has anyone saved this page: books4electricians.blogspot.com?
[21:09] <slangasek> cjwatson: what does the click run-user hook do on startup?  I'm seeing it do a whole lot of nothing here on goldfish and blocking the session startup, and I'm wondering if that's overall emulator slowness or miscellaneous system brokenness or what
[21:12] <cjwatson> slangasek: It runs user hooks, which among other things is necessary to make .desktop files for preinstalled apps work properly
[21:12] <cjwatson> slangasek: It shouldn't be doing anything especially exotic - you can look at the hooks in /usr/share/click/hooks/ with "User-Level: yes"
[21:13] <slangasek> ok
[21:13] <cjwatson> Which should be click-desktop, content-hub, upstart-app-launch-desktop at the moment (and click-desktop basically arranges to stub itself if upstart-app-launch-desktop is present)
[21:13] <slangasek> well, now I just hung the emulator by running 'sync'
[21:13] <slangasek> so yay
[21:13] <cjwatson> I don't know what content-hub does
[21:14] <slangasek> right, it's the content-hub that was runnnig
[21:14] <slangasek> I wound up killing it to see
=== Sweetshark is now known as NSA
=== NSA is now known as Sweetshark
[21:32] <ScottK> cjwatson: Who has to take care of uploading grub2-signed?
[21:36] <cjwatson> ScottK: anyone really
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
[23:20] <saiarcot895> What exactly is a debdiff? Is it just the diff of the sources?
[23:36] <infinity> saiarcot895: Yeah, it's a diff between two source packages.
[23:36] <infinity> saiarcot895: Or, that's the most common use of the tool and the term.  You can also debdiff binaries, which is handy. :)