[00:11] <slangasek> barry, stgraber: what's the "right" way to switch a phone configured for system updates into developer mode?
[00:19] <sergiusens> slangasek: stgraber told me to touch /data/.developer_mode and reboot
[00:19] <sergiusens> is rw after that
[00:19] <slangasek> ok
[00:19] <slangasek> I guess this should be documented somewhere prominent
[00:21] <slangasek> sergiusens: hmm, still ro for me
[02:11] <programmer_guy> Is this the correct room for asking questions about beginning ubuntu development?
[02:57] <JackYu> barry, hi, we created a separate /debian branch at https://code.launchpad.net/unity-china-video-scope.
[04:46] <pitti> Good morning
[05:35] <halfie> hi, which Wiki software does wiki.ubuntu.com run?
[05:35] <halfie> I don't think it is MediaWiki
[05:44] <pitti> halfie: MoinMoin
[05:57] <halfie> pitti, thanks1
[06:58] <dholbach> good morning
[07:38] <geser> are the mailing list archives (on lists.ubuntu.com) still up-to-date? I've an impression that they are missing recent mails (e.g. for ubuntu-devel)
[07:51] <ogra_> NCommander, nothing in ubuntu uses that machanism (it is error prone and binds you to the initrd) highbank uses the normal uboot setup and has the cmdline in its bootscr, please dont make it use the broken mechanism
[08:14] <stgraber> slangasek: it's /data/.developer_mode from recovery so /userdata/.developer_mode from the booted system
[08:38] <ev> anyone know if there are magic runes to teach bzr to handle renames as delete and add in its diff format? I'm trying to do bzr diff -c$revno > /tmp/package/debian/patches/foo.patch
[08:52] <StevenK> ev: --using /usr/bin/diff , since it will not handle renames
[08:52] <StevenK> You may have to pass --diff-options -urNP as well
[08:56] <ev> StevenK: that still gives me [08:57] <ev> (fwiw, I'm using  `bzr diff -c82 --using /usr/bin/diff --diff-options -urNP`)
[09:32] <ev> gave up and used cdbs-edit-patch :)
[09:33] <StevenK> ev: You are a terrible person for using CDBS tools.
[09:34] <ev> everything else whinged at me
[10:09] <ev> manish_: heads up. I've uploaded a-l-m 0.9.7-0ubuntu4 with the libwhoopsie-preferences0 move, so we can get ubuntu-system-settings with the diagnostics UI landed
[10:40] <ev> seb128, Laney: are you happy with https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385 at this point?
[10:40] <Laney> ev: I haven't rechecked the PK stuff yet but other than that yes
[10:40] <ev> whoop
[10:49] <doko> cjwatson, seb128: for long running builds like gtk+2.0, maybe glib2.0, would it make sense to have a staged build to not build the udeb's? also gtk should configure with --disable-cups for the staged build
[11:05] <cjwatson> doko: Not something I care about either way :)
[13:54] <pitti> Daviey: ah, so it seems you synced pyparsing instead of merging? can you add back the autopkgtest?
[14:14] <tseliot> pitti: any ideas as to what am I missing in my sbuild chroot if jockey complains like this? http://pastebin.ubuntu.com/5911268/
[14:30] <pitti> tseliot: no running system d-bus
[14:30] <tseliot> pitti: is there a way around it?
[14:33] <pitti> tseliot: if you start it as root, you can use --no-dbus
[14:33] <pitti> tseliot: otherwise, you have to start a bus
[14:33] <tseliot> pitti: excellent thanks
[14:33] <pitti> tseliot: like, dbus-launch and export DBUS_SYSTEM_BUS_ADDRESS=<the address that dbus-launch prints out>
[14:36] <tseliot> ok, good
[14:38] <dobey> dholbach: hey, can you take another poke at bug #1199017 please? I've got the issues fixed that you mentioned.
[14:39] <Daviey> pitti: yep, i'll add them.  Can i check that they were not already submitted to Debian?
[14:40] <pitti> Daviey: they were forwarded to debian bug 706317, but not applied yet
[14:40] <pitti> Daviey: so the sync dropped our test that we already had
[14:42] <Daviey> pitti: Right, I am going to email the debian last uploader asking him to apply it - he is keen for us to reduce delta where we can.
[14:43] <dholbach> dobey, cool
[14:53] <dholbach> dobey, good to go
[14:53] <dobey> dholbach: thanks!
[14:54] <dholbach> dobey, uploaded
[14:54] <dobey> great
[15:00] <roaksoax> cjwatson: howdy!! if you have the time could you please process crmsh from the saucy NEW queue (since it'
[15:00] <roaksoax> cjwatson: howdy!! if you have the time could you please process crmsh from the saucy NEW queue (since it's kinda blocking me ) Thanks!
[15:05] <cjwatson> roaksoax: I definitely don't have time at the moment, hopefully somebody else does, sorry ...
[15:06] <roaksoax> cjwatson: no worries :) thanks though!
[15:07] <roaksoax> Daviey: do you? :) It's blocking the whole update of the HA stack
[15:09] <Daviey> roaksoax: Looks like the call i was supposed to be in is canceled, so will do it now
[15:15] <Daviey> roaksoax: Hmm, did you know this is in Debian experimental ?
[15:15] <Daviey> roaksoax: You could just sync it, no?
[15:17] <Daviey> roaksoax: would be better if ./modules/singletonmixin.py was mentioned in debian/copyright as public domain... but if it got into Debian, you can do a sync.
[15:18] <Daviey> roaksoax: rejecting for now, can retrieve it later if i was mistaken.
[16:53] <roaksoax> Daviey: crmsh was synced form debian locally, added delta and uploaded, instead of requesting the sync to the system because it is broken
[16:53] <roaksoax> so I preferred to fix it adding the delta first
[17:10] <roaksoax> Daviey: ok I requested a sync from experimental, and it is in the new queue. If you could process it would be great
[17:18] <Daviey> roaksoax: Ah ok, done. Thanks.  Generally, it's easier to do it this way - as we trust Debian to be licence complaint, so takes less time on NEW review.
[17:19] <roaksoax> Daviey: yeah! I basically just grabbed their package and applied the delta to fix it, but yeah I guess I should have get it into the archives first
[17:21] <roaksoax> Daviey: thanks though :)
[19:07] <roaksoax> cjwatson: quick question. If I'm dropping binary packages 'b' and 'c' from a 'x' source that also provides a binary 'a' (b and c had a Dependency on 'a'), should I make 'a' provide 'b' and 'c', or shall they just be gone?
[19:08] <roaksoax> cjwatson: a more particular example, ocfs2-tools shipped ocfs2-tools, ocfs2-tools-pacemaker, ocfs2-tools-cman, so the -cman, -pacemaker are no longer needed/supported, and I'm dropping them. So should ocfs2-tools 'Provide' the -pacemaker, -cman for some reaason or that's not really necessary?
[19:53] <ari-tczew> hello
[19:54] <ari-tczew> I'd like to sync a package, but the remaining delta is only bump B-D on one package. Nevertheless package from unstable builds fine, without that bump. Can I request a sync?
[19:56] <ScottK> What does debian/changelog tell you was the reason for the bump?
[20:10] <genii> Sorry to bother but... is there a way to make dhclient -n   <interface> actually work instead of referring the user to usage syntax?
[20:15] <genii> It used to sort-of work in dhcp3-client ( it would still actually modify stuff though) , in isc-dhcp-client it doesn't work at all.
[20:23] <ari-tczew> ScottK: * debian/control: depending on eina >= 1.7.7
[20:23] <ari-tczew> that's all
[20:24] <ScottK> Probably.  I'd request the sync and let a sponsor review, I guess.
[20:24] <ari-tczew> ok
[20:25]  * genii just examines dhclient.c to see what's going on
[21:40] <cjwatson> roaksoax: it only really matters at all if anything else depends on b and c; and even then it would depend on the details
[21:40] <cjwatson> roaksoax: there's certainly no rule that you must replace removed binary packages with a Provides
[21:44] <roaksoax> cjwatson: awesome! thanks for the info
[23:26] <jbicha> smoser: cloud-init tries to depend on the uninstallable python-jsonpatch
[23:26] <jbicha> https://launchpadlibrarian.net/145863443/buildlog_ubuntu-saucy-i386.cloud-init_0.7.3~bzr849-0ubuntu1_UPLOADING.txt.gz