[00:16] <mwhudson> https://launchpadlibrarian.net/174134069/buildlog_ubuntu-utopic-arm64.scrub_2.5.2-2_FAILEDTOBUILD.txt.gz <- this just means "pls update config.guess" right?
[00:17] <infinity> mwhudson: Yep.
[00:19] <infinity> mwhudson: Fixing.
[00:19] <mwhudson> infinity: how can i make that happen?
[00:19] <mwhudson> oh cool
[00:19] <mwhudson> (not that i'm completely sure this is relevant to me today but it's the end of this branch of the rabbit hole)
[00:26] <infinity> mwhudson: Fixed in utopic-proposed.
[00:26] <infinity> Well, soonish.
[00:26] <mwhudson> infinity: will something that's depwaiting on that automagically try again ?
[00:26] <mwhudson> eventually
[00:26] <infinity> mwhudson: Yeah.
[00:26] <infinity> mwhudson: Though if you identify that something, we can certainly force the issue earlier.
[00:26] <mwhudson> of course the builds that didn't depwait out failed so eh
[00:27] <mwhudson> infinity: https://launchpad.net/ubuntu/+source/libguestfs/1:1.26.1-1ubuntu1
[00:27] <mwhudson> cp: cannot open '/boot/vmlinuz-3.13.0-24-generic' for reading: Permission denied
[00:28] <mwhudson> this seems like the sort of thing that is well known about guestfs (even i know about it!)
[00:28] <mwhudson> apw: i presume you're asleep like a sensible person?
[00:29] <infinity> mwhudson: That's a fundamentally broken thing with that package...
[00:29] <mwhudson> yeah
[00:29] <mwhudson> i recall upstream was not very sympathetic to ubuntu's position...
[00:29] <infinity> mwhudson: Andy and I have spent some time talking about it, but if you have good ideas to make it less stupid before he fixes it, go nuts. :P
[00:29] <mwhudson> i have no ideas, but running tests that rely on that being readable is not going to work...
[00:30] <infinity> It's not tests.
[00:30] <infinity> It's trying to copy the *&!% kernel into its resulting binary.  I think.
[00:30] <mwhudson> oh
[00:30] <mwhudson> pff
[00:30] <infinity> Or maybe I'm tihnking of a different broken package.
[00:30] <infinity> Anyhow, it's all bad.
[00:31] <mwhudson> this one is a test i think
[00:32] <infinity> Well, that's less bad.
[00:32] <infinity> Err, are you sure?
[00:32] <infinity> supermin is trying to build a filesystem.
[00:32] <infinity> And copy the kernel over.
[00:33] <mwhudson> it's from running make -C /build/buildd/libguestfs-1.26.1/debian/build-python3.4 quickcheck
[00:33] <mwhudson> i think?
[00:33] <mwhudson> i might be mis-reading
[00:33] <infinity> Oh, it might be a check from the POV of libguestfs.  But the bug is in supermin.
[00:34] <infinity> You could not run that test that uses supermin, but I don't think that really gets you anywhere interesting, if it's meant to be used in conjunction.
[00:34] <mwhudson> all i was trying to do was install python-guestfs because the openstack install guide said do :-)
[00:34] <mwhudson> *to
[00:51] <psusi> infinity, poke ;)
[00:52] <infinity> psusi: Ow.
[00:52]  * psusi hands infinity the rubber chicken
[00:53] <psusi> how's that thar util-linux going?
[00:53]  * infinity slaps psusi with it, in anticipation of his next question.
[00:53] <infinity> Guess I should have typed that a bit faster.
[00:54] <infinity> psusi: It's coming along.  I've enlisted others.
[00:54] <psusi> lol... ok... any estimates?  half way done or what?
[00:55] <infinity> No estimates.  It'll happen and it won't miss either upcoming release.
[00:55] <infinity> Estimates just seem to be an invitation for people to be extra annoying.  But it's being worked on, not forgotten.
[00:56] <psusi> ok... it's pretty slow going isn't it?
[00:57] <infinity> I haven't done the "take work time to JFDI" bit yet.  That might be coming soon.
[00:57] <psusi> *lots* of patches in there
[01:00] <psusi> did I already ask you this?  what do you think of the /etc/mtab -> /proc/mounts migration?  something we want to do for utopic?
[01:00] <infinity> psusi: I believe slangasek had strong feelings about why that can't happen.
[01:00] <infinity> psusi: WRT network filesystems.
[01:01] <psusi> hasn't debian sorted that all out by now?  they made the migration some time ago now
[01:01] <infinity> Erm, they did?
[01:03] <psusi> afaics from upstream, you just need to link the mount helpers against libmount and it takes care of stashing the extra parameters in utab instead
[01:04] <infinity> Well, we'll cross that bridge when we get to it.  But the "they did?" comment was me looking at a sid chroot.
[01:04] <infinity> Where, if Debian has "migrated", I would expect to see an /etc/mtab -> /proc/mounts symlink, which isn't there.
[01:04] <infinity> So, they didn't migrate very hard, if they did. :P
[01:05] <psusi> hrm... I think the way they did the migration was kind of goofy... its' there in a fresh vm install
[01:13] <infinity> psusi: Right, so it happens on boot (every boot!) via /lib/init/mount-functions.sh, called by /etc/init.d/checkroot.sh
[01:14] <psusi> yea.. it should be done in postinst instead
[03:52] <slangasek> infinity: heh; yes, Debian migrated /etc/mtab to /proc/mounts, without cleaning up the migration bugs.  There's still an open bug report from me against util-linux about this, Debian bug #702935.
[04:01] <infinity> slangasek: Ta.
[04:02] <slangasek> infinity: so recasting psusi's question as "can we do this migration in Ubuntu that there's currently an open RC bug about in Debian on a package I'm keen to adopt?"... ;)
[04:03] <infinity> slangasek: Right, I think the way forward is to clean this up in Debian while I'm cleaning up util-linux in general, and then make it work in Ubuntu.
[04:03] <slangasek> sure
[05:16] <pitti> Good morning
[05:18] <Unit193> Howdy.
[05:25] <Unit193> pitti: I suppose you saw https://lists.debian.org/debian-devel/2014/05/msg00469.html and it's pointless for me to link?
[05:29] <pitti> Unit193: no, I'm not on d-devel; shim will *not* work with > 204 at the moment
[05:29] <pitti> that requires quite some work with cgmanager and systemd-shim first
[05:29] <Unit193> Yes, he stated that in a follow-up. :)
[07:03] <dholbach> good morning
[07:32] <tsdgeos> tkamppeter: is there any chance we can get http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3c4cfba8 into our gs 9.14 packages?
[08:13] <Mirv> pitti: hey, ubuntuone-credentials autopkgtest is failing for everything and doing a bit of blocking, is there a possibility you could glance at that?
[08:14] <pitti> Mirv: looks like a missing test dependency at first, yes
[08:14] <pitti> Mirv: I'll have a look
[08:16] <Mirv> thank you!
[08:16] <tkamppeter> tsdgeos, I can do, no problem.
[08:16] <tsdgeos> tkamppeter: great :)
[08:18] <pitti> Mirv: meh, ubuntuone-credentials' autopkgtest is rather useless
[08:20] <pitti> and I can't push to the branch either
[08:20] <pitti> *grumble*
[08:22] <pitti> Mirv: yep, the test is right -- the package really is FTBFS (checked in sbuild)
[08:25] <pitti> Mirv: filed bug 1318947 to track this; checking with adding pkg-config as build dep
[08:27] <Mirv> pitti: ok, good. yeah, I actually suspected that since the phone stuff tends to develop so fast the rarer updated packages start FTBFS:ing at times.
[08:27] <Mirv> when I was preparing Qt 5.2, I ran into many of such that failed to build even against the archive version
[08:27] <pitti> so adding pkg-config build dep helps; I'll let this build finish and then propose a merge
[08:28] <pitti> debian/tests/control is also rather messy, cleaning this up along the way
[08:33] <pitti> Mirv: https://code.launchpad.net/~pitti/ubuntuone-credentials/fix-ftbfs/+merge/219308
[08:51] <Mirv> pitti: thanks, I tested it now.
[08:52] <pitti> Mirv: I tested in sbuild and adt-virt-qemu
[08:52] <pitti> Mirv: this should also get a ps-jenkins bot approval, right?
[09:00] <Mirv> pitti: I think it should, still, even if the automerger would be disabled for the component because the CI Train process is used instead.
[09:01] <Mirv> dbarth is the lander for ubuntuone-credentials
[09:01] <Mirv> dbarth: https://code.launchpad.net/~pitti/ubuntuone-credentials/fix-ftbfs/+merge/219308 would need to go in
[09:02] <pitti> oh the days when we could just upload these trivial fixes..
[09:02] <pitti> :)
[09:03] <Laney> I still would, and then propose the merge back ;)
[09:03] <pitti> well, it would be nice if people who can upload the package could also commit to the branch
[09:08] <caribou> Laney: remember bug 1296755
[09:08] <caribou> Laney: two tasks are for the -backports pocket (one of which is Quantal)
[09:09] <Laney> caribou: kind of!
[09:10] <caribou> Laney: I uploaded debdiffs for all tasks, though I think that the Quantal one should be dropped; it is EOL in 3 days
[09:11] <Laney> I suppose we can let that slide, yeah
[09:12] <caribou> Laney: well the debdiff is there anyway; I'll resubmit the sponsors & see what the sponsor decides
[09:12] <Laney> backports aren't handled by the sponsors
[09:12] <caribou> Laney: well as I understood, it needs to get to saucy first
[09:13] <Laney> You don't actually need a debdiff for those, assuming the package is identical between saucy and -backports
[09:13] <caribou> Laney: who does worry about -backports ?
[09:13] <Laney> the backporters team
[09:13] <caribou> Laney: ah, ok
[09:13] <Laney> So it'll get into saucy-proposed, then you say "yes I built/installed/ran this on precise and it works" and a copy gets uploaded to precise-backports
[09:14] <Laney> No need for a debdiff unless you need changes over saucy
[09:14] <caribou> Laney: ok, thanks for the details
[09:15] <Laney> np!
[10:08] <dbarth> Mirv: ok, i may add it to my silo; almost done with regression testing
[10:11] <Mirv> dbarth: no need, already taken care of! we needed the packaging fix to unbloc other landings.
[10:32] <shadeslayer> bdmurray: ping
[10:34] <shadeslayer> bdmurray: regarding those crashes in kde-telepathy-contactlist, upstream has pushed a fix here http://quickgit.kde.org/?p=ktp-contact-list.git&a=commitdiff&h=d254bb9779ddf186de33e9482c8668d223339bb5&hp=221d08672a932a2b1cbca3e8eaf46c5465f6d63f , do you reckon I should SRU that or just wait for their next point release which I intend to get SRU'd
[10:34] <shadeslayer> the way that they're triggered is if you have a broken dbus service file for mission-control
[10:40] <ajnas> hello
[10:41] <ajnas> anybody out there?
[10:47] <Ajnas_> helo
[10:48] <tkamppeter> tsdgeos_, ghostscript 9.14~dfsg-0ubuntu2 with the LCMS patch released.
[10:48] <tsdgeos_> :)
[11:11] <shadeslayer> cjwatson: ping
[11:14] <shadeslayer> cjwatson: could you shed more light on your cdimage stuff + PPA association? Does that mean one could provide ISO's which have certain PPA's enabled? Because Kubuntu was thinking of doing that for 14.10 ( have 2 ISO's , one with regular KDE 4 and one with Plasma 5 + KDE Frameworks 5 )
[11:14] <shadeslayer> the latter being provided by a PPA
[11:16] <cjwatson> shadeslayer: I'm not making any promises about how much we can open it up for wider use, because there are resource limits
[11:16] <shadeslayer> cjwatson: right
[11:17] <cjwatson> shadeslayer: And, while the livefs parts of your example would be technically handleable by what I'm doing, there are other things involved in building ISO images with PPAs (i.e. the stuff that goes into the pool) that aren't currently on my list to handle
[11:20] <ogra_> you could just resort to build kubuntu-phone instead ;)
[11:25] <cjwatson> shadeslayer: so, um, the short answer is "maybe" - but I don't think I can make any promises and it may need somebody who cares about this to roll up their sleeves and get involved with the infrastructure
[11:26] <cjwatson> also expanding this by very much is likely to end up blocked on prodstack4 (an IS project) due to librarian disk space limitations
[11:44] <cjwatson> pitti: ubuntu-purchase-service looks like another one of the same species as ubuntuone-credentials?
[11:45] <pitti> cjwatson: right; I'll do a similar MP
[12:23] <mapreri> zequence: I sent you an email some days (7?) ago about xscreensaver. do you mind reply or tell me here your opinion about? otherwise I'll go ahead and drop the ubuntu delta
[12:24] <shadeslayer> cjwatson: ack
[12:29] <mapreri> pitti: anyhow, looking at the changelog seems like the original different split was needed to gain 5 MB on the CD iso (dapper age), so not really useful now :) (just, fyi)
[12:45] <pitti> mapreri: right, because we don't install it at all any more
[12:48] <dobey> Mirv: how about giving the people who actually maintain a project a chance to review an MP before approving it and landing it via CI train?
[12:48] <pitti> cjwatson: https://code.launchpad.net/~pitti/ubuntu-purchase-service/fix-ftbfs/+merge/219361
[12:48] <pitti> Mirv: ^ FYI
[12:48] <dobey> gah
[12:49] <dobey> pitti: why are you removing allow-stderr?
[12:49] <Mirv> dobey: it was a packaging only fix that was needed to unblock other packages, and it could be reverted if wanted then later on
[12:49] <pitti> dobey: as long as these tests don't do anything, they don't need all this noise?
[12:49] <dobey> pitti: the tests do do things
[12:49] <Mirv> dobey: but that ^ ubuntu-purchase-service now blocks 3 packages as well, so it'd be nice to get landed too
[12:49] <pitti> the test is literally just a "set -ex"
[12:49] <pitti> dobey: no, it's a totally empty script except for a "set -ex"
[12:50] <dobey> pitti: the tests are run by the build, which can dump stuff to stderr
[12:50] <dobey> pitti: there's no point in running "make check" and then immediately running "make check" again in the build tree
[12:50] <pitti> dobey: yes, but the build can do that as much as it wants; the build is *not* a test
[12:50] <pitti> (in autopkgtest terms)
[12:50] <pitti> dobey: yes, I agree
[12:50] <pitti> dobey: the point is, an autopkgtest should check the *installed* package, not the build tree
[12:50] <pitti> so you don't need to run make check in an autopkgtest in the first place
[12:51] <dobey> pitti: uh, but it was causing failures before when the build was happening in the autopkgtest, and stderr had things
[12:51] <pitti> something like "make check-installed", or just a small smoketest calling the binaries, etc.
[12:51] <pitti> dobey: well, perhaps you had something in debian/tests/run-tests (which, contrary to its name, doesn't do anything)?
[12:52] <pitti> with set -x being active, any command there would cause stderr
[12:52] <dobey> i don't think so
[12:52] <dobey> but whatever, if autopkgtests start failing, this is probably why :)
[12:52] <pitti> so it's basically the same asa bug 1316416
[12:52] <pitti> dobey: no, it's not; I tested it locally (also with ubuntuone-credentials)
[12:52] <pitti> and if they fail because of stderr, that'd be an autopkgtest bug
[12:52] <dobey> ok
[12:52] <pitti> dobey: but right now they fail because the pacakge is FTBFS
[12:53] <pitti> (new qt stack, some build dep dropping pkg-config dependency; I didn't check and it doesn't matter much)
[12:53] <dobey> an empty run-tests is the only way i've found to make autopkgtests work
[12:55] <pitti> dobey: well, the way to make an autopkgtest work would be to have a test that checks the installed package :)
[12:55] <pitti> we already run the tests against the build tree during package build, so that's not that useful to repeat
[12:55] <dobey> yes, but uploading a new build-dependency doesn't force a rebuild of everything that depends on it
[12:55] <pitti> aside perhaps from issues like these when the pacakge becomes FTBFS due to changes in the build deps
[12:56] <dobey> so we have to rebuild in autopkgtests ot catch such breakage
[12:56] <pitti> dobey: yes, that's correct
[12:56] <dobey> which sadly apparently doesn't actually block the thing being uploaded from migrating to archive
[12:56] <dobey> but eh
[12:56] <pitti> (in some way it's also an abuse as it doesn't scale to the relatively few test machines that we have, but as long as not too many packages do it it's ok)
[12:57] <pitti> dobey: yeah, that bug got finally fixed yesterday
[12:57] <pitti> dobey: (not blocking stuff that causes regressions in autopkgtests)
[12:57] <dobey> yay
[12:57] <dobey> though now it matters much less for me, because no more u1 client
[12:57] <pitti> yeah, that was one of the most annoying/critical issues there and rendered the whole thing fairly useless
[12:59] <dobey> and if i could get beuno go give us proper oauth2 for sso, it would make life all that much better
[13:02] <beuno> but beuno hates nice things.
[13:03] <dobey> but it's so webby
[13:05] <beuno> dobey, I'll throw it into the developer pit next week, so what comes out
[13:07] <seb128> barry, coming to the upgrade testing call?
[13:10] <doko> Mirv, I didn't look how much in sync the qt5* packages are compared to Debian. But please could you make sure the symbols files are ok?  The Debian maintainer doesn't want to fix these before 4.9 is the default
[13:17] <barry> seb128: yes. sorry.  will try to get g+ working
[13:32] <nandersson> Hi, there seems to be a dependency problem in package samba-common-bin. Package has hard dependency: samba-common (= 2:4.1.6+dfsg-1ubuntu2), but there is already another package released internally with suffix version that breaks that dependency
[13:32] <nandersson> If dep was (>= .... it would surely work
[13:32] <nandersson> but as it is (= ... it doesn't
[13:40] <nandersson> If you run "sudo apt-cache show samba-common-bin | grep Depends" you'll see there are conflicting depends inside the package
[13:45] <cjwatson> nandersson: In what Ubuntu release, trusty or utopic?
[13:46] <nandersson> trusty
[13:46] <nandersson> I get error when realmd tries to install samba-common-bin (and it is strange becuase package is already installed)
[13:47] <cjwatson> nandersson: There's a samba-common-bin 2:4.1.6+dfsg-1ubuntu2.14.04.1 along with the updated samba-common version, and that Depends: samba-common (= 2:4.1.6+dfsg-1ubuntu2.14.04.1)
[13:47] <cjwatson> So it looks fine to me.  Check that you don't have held packages or some other issue that's causing apt to hold back some of the upgrade
[13:48] <nandersson> When I run realm I get "samba-common-bin: Depends: samba-common (= 2:4.1.6+dfsg-1ubuntu2) but 2:4.1.6+dfsg-1ubuntu2.14.04.1 is to be installed
[13:49] <cjwatson> Right, you're just restating what you said earlier :)
[13:49] <cjwatson> Try "sudo apt-get dist-upgrade" first and see what that says
[13:50] <nandersson> ...I have a couple of packages there - I'll try to install them.
[13:50] <nandersson> :)
[13:50] <cjwatson> Then "apt-cache policy samba-common-bin" should show 2:4.1.6+dfsg-1ubuntu2.14.04.1 as the candidate version
[13:51] <nandersson> yes, it does
[13:59] <nandersson> It looks like it is PackageKit that reports the problem
[14:04] <nandersson> hrmm...I'll re-roll this one
[14:40] <kentb> if I want to pull in a bunch of recent security patches for a universe package (openwsman) is it best to open individual bugs for each one or can I incorporate them in one fell swoop?:  https://github.com/Openwsman/openwsman/commits/638b9c8acfa6ded84c94c01e137c61c29d65d62e/src
[14:40] <kentb> (this is for 14.04)
[14:41] <mdeslaur> kentb: file a bug, attach a debdiff to it, and then subscribe ubuntu-security-sponsors
[14:41] <mdeslaur> kentb: you can do them all in the same bug
[14:41] <kentb> mdeslaur, ok
[14:41] <kentb> cool. thanks!
[14:41] <mdeslaur> np
[14:48] <OdyX> tkamppeter: Did you see Debian's #748028 ? You probably want to fix that in cups-filters' upstream.
[14:57] <arges> tkamppeter: hi. can you add an SRU template to bug 1315864, so I can approve hplip? thanks
[15:21] <tkamppeter> arges, the SRU is not needed as separate SRU, as this problem was introduced to Trusty by the SRU of bug 1311697. There I have already announced that the SRU is broken and should not be tested and uploaded a corrected SRU package. So please approve that corrected package (hplip 3.14.3-0ubuntu3.2) into -proposed.
[15:22] <arges> tkamppeter: well the changlog indicates that it fixes both of those bugs 1315864 and 1311697, so does the changelog need to be corrected?
[15:24] <sil2100> dobey: hi! Could you take a look at this merge? It will fix some of the problems in the -proposed pocket: https://code.launchpad.net/~pitti/ubuntu-purchase-service/fix-ftbfs/+merge/219361
[15:25] <dobey> sil2100: done
[15:26] <sil2100> dobey: that was fast! Thanks
[15:28] <zequence> mapreri: I missed that mail. I'll have a look at it.
[15:28] <Saviq> xnox, just posted a current upstart assert in libnih: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1319083
[15:28] <Saviq> (still private)
[15:28] <dobey> slangasek: is https://bugs.launchpad.net/ubuntuone-storage-protocol/+bug/1307549/comments/2 acceptable as a test case? i'm not sure of a particularly good general test case for that though, "install current version and ensure ubuntuone-client connects to the server, install new version and ensure ubuntuone-client still can connect to the server" will work but doesn't point out a specific failure (as deployement of new cert on 
[15:30] <tkamppeter> OdyX, for me this builds without warnings or errors on my 64-bit Ubuntu Trusty system, but anyway it is not correct to have two different types here. I will correct pdf.h to size_t to have them both the same. Thanks for the report.
[15:31] <tkamppeter> arges, this is because I have fixed it in Utopic first and then copied the changelog to the Trusty fix.
[15:32] <mapreri> zequence: thanks
[15:34] <arges> tkamppeter: ok. so trusty never had the problems shown in 1315864 since that package never made it past -proposed. So sounds like that bug should be removed from the changelog for the trusty upload.
[15:37] <tkamppeter> OdyX, cups-filters fixed upstream in BZR rev. 7203, which will make part of 1.0.54. How urgent is the fix, should I release 1.0.54 quickly?
[15:38] <OdyX> tkamppeter: no, doesn't seem to urgent. Pointing the bug to the fix would be nice though.
[15:45] <tkamppeter> arges, how to proceed then? Should I reupload with the wrong bug number removed (then you would need to reject the current 3.14.3-0ubuntu3.2 to make space for a corrected one) or will you simply put the current one into -proposed?
[15:48] <tkamppeter> OdyX, I have answered the bug report now.
[15:56] <bdmurray> ev: is there a design decision behind bug 1319099?
[15:59] <arges> tkamppeter: do you mind re-uploading with that bug number removed? I'll reject the current one. Thanks!
[16:03] <ev> bdmurray: commented - not by design
[16:04] <bdmurray> ev: thanks
[16:05] <ev> sure thing
[16:05] <ev> bdmurray: don't know if you saw, but Chipaca landed the imei code
[16:06] <tkamppeter> arges, no problem.
[16:10] <bdmurray> ev: no, thanks for that. How does recoverable_problem get called? Is it by an individual package?
[16:10] <tkamppeter> arges, package is corrected and re-uploaded now.
[16:11] <ev> bdmurray: as in generating a recoverable problem using that program? Yeah, any software can call it and feed report data over stdin
[16:11] <ev> ted has simplified this recently by adding support for it in libwhoopsie
[16:11] <ev> it's like we have a developer community for the error tracker :D
[16:11] <arges> tkamppeter: great! I'll review it when I see it in the queue.
[16:11]  * ted needs to finish the test for that…
[16:12] <ted> bdmurray, The code in that MR is used by a few projects already. You could look at url-dispatcher to see how it does it.
[16:13] <ted> bdmurray, We file a recoverable error on programs that send us bad URLs.
[16:13] <ted> (well, except for click packages. Someday. Someday.)
[16:14] <bdmurray> ted: I'd guess the whoopsie change needs fixing for bug 1316763.
[16:16] <ted> bdmurray, I'm not sure if that's wrong or right. Sometimes we want to see a problem across programs.
[16:17] <ted> bdmurray, I'd say it's displayed wrong though :-)
[16:54] <nandersson> Happy 1400000000 everyone!
[16:54] <nandersson> http://coolepochcountdown.com/
[16:55] <Unit193> Wow.
[16:56] <dobey> how is that a countdown?
[16:56] <nandersson> :D yeah
[16:56] <nandersson> should be a countup
[16:56] <ogra_> nitpickers
[16:57] <dobey> whoever owns that site should make it use a 32-bit int and make it an actual countdown to the end of time in 2038
[16:58] <dobey> and then have it restart at 0, like it's 1970 all over again, just like the mayan calander crushed our hopes and dreams
[17:01] <nandersson> haha :D Yeah, lots of people trying to solve the 2038-bug
[17:04] <dobey> i really just wanted to watch the chaos of the end of civilization in 2012. but alas. c'est la vie.
[17:36] <bdmurray> how can I manually set a hostname on a phablet?
[17:37] <bdmurray> I want to add something to /etc/hosts and its read-only
[17:38] <popey> bdmurray: interesting, i set the hostname on mine
[17:39] <bdmurray> popey: well its not really the devices hostname rather I want to map daisy.staging.ubuntu.com to a different ip
[17:39] <popey> oh ☹
[17:40] <popey> seems that might be a candidate for being in writable/
[17:40] <popey> ogra_: ^
[17:40] <bdmurray> I was going to manually try that but its read-only too :-(
[17:41] <ogra_> hmm
[17:41] <bdmurray> I mean /etc/system-image/writable-paths is read-only
[17:41] <ogra_> yeah, thats on purpose
[17:41] <ogra_> you would have to add the entry to the lxc-android-package ...
[17:43] <bdmurray> ogra_: do you have any other ideas?
[17:43] <ogra_> well, that would be the proper way ...
[17:44] <ogra_> for a quick hack: mouont -o remount,rw / ... make your changes ... mount -o remount,ro /
[18:12] <dobey> slangasek: btw, i see you accepted the ubuntuone-client into precise-proposed. can you also accept the one for saucy-proposed?
[18:44] <michagogo|cloud> If anyone who knows how to do Ubuntu packaging etc. has a few minutes and wants to do something small, Bug #1314616 would be a good choice.
[18:50] <sladen> michagogo|cloud: we'd probably prefer to follow whatever solution is made in Debian
[18:51] <sladen> michagogo|cloud: and so keep it upstream where possible
[18:52] <sladen> michagogo|cloud: there may also be better ways of solving the issue (a dummy package is one option; but there might be other solutions too)
[18:52] <michagogo|cloud> sladen: debian solves it by keeping the software in unstable only, where it can be updated
[18:53] <michagogo|cloud> In fact, the bitcoin package was already removed and blacklisted from syncing starting in trusty
[18:53] <ogra_> sladen, there was a related mailing list discussion on ubuntu-devel-discuss
[18:53] <ogra_> upstream asked for this ... packages will be maintained in a PPA by them instead
[18:54] <michagogo|cloud> sladen: Did you read the discussion I linked?
[18:54] <michagogo|cloud> (in the bug)
[18:56] <michagogo|cloud> ogra_: hm, was there a discussion on that ML? Got a link (or a date)?
[18:57] <michagogo|cloud> Also, the PPA has been around, maintained, and recommended for a long time
[18:57] <michagogo|cloud> But we still occasionally get people in #bitcoin trying to run 0.3.24 :-/
[19:06]  * sladen adds some high-level context
[19:17] <hjd> Hm... I saw that elementary failed to build on http://qa.ubuntuwire.com/ftbfs/, because it waits for libemotion-dev. That belongs to this source package (http://packages.qa.debian.org/e/efl.html) which seems to only be in Debian, not Ubuntu.
[19:18] <hjd> Though I can't find efl on the sync blacklist (http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt) or any other reason why it hasn't been synced. Does anyone know?
[19:35] <Unit193> Looked at the blacklist, and systemd-ui is on there.  Reason was that we use upstart and systemd unavailabile, which has changed in utopic.
[19:37] <hallyn> bdmurray: fwiw i'm aware there are a slew of sru's ripe for validation;  i'm hoping to spend time tomorrowm orning going through them (libvirt,cgmanager,kvm,and a kernel one at least)
[20:14] <Logan_> Unit193: I beat you to it :P
[20:14] <Logan_> Bug 1318776
[20:15] <Logan_> oh, and I could've answered hjd's question, but s/he left :(
[20:15] <Unit193> Logan_: Oh dang you!  Stinking snipers everywhere. ;)
[20:15] <Logan_> literally did it last night, haha
[20:15] <Logan_> I've been going through the blacklist and finding outdated stuff
[23:34] <sarnold> Laney: the ubuntu codesearch looks unhappy, "502 Bad Gateway" :(