[00:09] <slangasek> cjwatson: feel free to redirect to jibel, who's not currently online :)  The u-m autopkgtest is failing on amd64, apparently because it's managing to be run while the dependencies aren't consistent on amd64 in -proposed.  What's the right fix for this? https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-update-manager/ARCH=amd64,label=adt/37/
[00:20] <slangasek> psusi: so, if I change the version number field, the kernel rejects the partition table ;)
[00:20] <psusi> slangasek, ohh fudge... you also have to update the crc ;)
[00:22] <slangasek> hm!
[00:22] <slangasek> well
[00:22] <slangasek> that will be a challenge, won't it
[00:22] <slangasek> considering android's dd doesn't even want to write to a block device
[00:25] <slangasek> https://bugs.launchpad.net/touch-preview-images/+bug/1190792
[00:25] <slangasek> oops, ECHAN
[00:26] <slangasek> psusi: right, so I'm even less enthusiastic now about doing this all by hand rather than being able to use parted for the task ;)
[00:27] <slangasek> however, I did manage to reset the bit to 0, so the N7 is bootable again
[00:27] <psusi> slangasek, then I'd say just comment out the version check in parted and build a local version for hacking purposes ;)
[00:27] <slangasek> mmmk
[00:28] <slangasek> psusi: but you won't want these patches in the Ubuntu build, I take it
[00:28] <slangasek> because this is code that's meant to be part of the Ubuntu Touch bootstrap
[00:28] <psusi> well, it would be a dirty hack that you would have to key to the dmi of the device or something, and wouldn't be accepted upstream that's for sure
[00:29] <slangasek> what about a patch to support writing only to the alternate gpt?
[00:30] <psusi> I don't think so
[00:30] <slangasek> blah
[00:31] <psusi> I think if you really want ubuntu's parted to work on this thing it would take a dmi specific hack to notice that the existing partition is this screwed up thing with version 0 and mo primary, and set a flag to remember to write it back with 0 version and only to the backup
[00:32] <psusi> that really is terribly dirty of them not to have a primary at all... should at least have it located somewhere else
[00:33] <psusi> then at least it would be somewhat sane for parted to find the backup, and just note that hey, the primary is in a weird place, but otherwise looks valid, so ok... I'll leave it there
[00:33] <slangasek> well, arguably the kernel patch they have declares that this *is* the primary gpt
[00:34] <slangasek> ... and it just happens to be located in the defined location of the alternate gpt :P
[00:34] <psusi> I think the error gdisk gave would be different if that were the case
[00:34] <psusi> you can tell for sure by looking at the value of mylba and altlba in the header...
[00:35] <slangasek> my_lba: FF EF D1 01; alternate_lba:  00 00 00 00
[00:36] <slangasek> er, sorry
[00:36] <slangasek> my_lba: EF EF D1 01  00 00 00 00; alternate_lba: 01 34 00 00  00 00 00 00
[00:38] <psusi> there was someone who was working on a patch lately that had to do with arm needing u-boot in sector 2 so the primary needed relocated
[00:38] <slangasek> so that translates to 30535663, which is 17 sectors before the end of the disk?
[00:38] <slangasek> (30535680 total sectors)
[00:38] <slangasek> 16 sectors, rather
[00:38] <psusi> but that at least still had a pmbr and primary header in sectors 0-1, and the table started in sector 3 instead, which is odd, but valid
[00:39] <psusi> hrm.. it should be the last sector of the disk I thought?
[00:40] <slangasek> dunno
[00:40] <slangasek> this gives me a whole lotta zeroes: dd if=/dev/block/mmcblk0 of=/data/gpt-primary.img bs=512 count=4 skip=30535663
[00:41] <slangasek> is there some reason that would be offset from somewhere other than sector 0?
[00:42] <psusi> no, all offsets have to be relative to the start of the device
[00:42] <slangasek> well, then I guess that field's invalid too ;)
[00:43] <slangasek> I wonder what I'll find at offset 13313?
[00:43] <psusi> you sure you are looking at the right fields?  one of them sure as shit should be the block number where you actually found the thing, which you said before was the last sector of the drive ;)
[00:43] <slangasek> 00000600   45 46 49 20  50 41 52 54  00 00 00 00  5C 00 00 00  EFI PART....\...
[00:43] <slangasek> 00000610   30 21 A2 EE  00 00 00 00  FF EF D1 01  00 00 00 00  0!..............
[00:43] <slangasek> 00000620   01 34 00 00  00 00 00 00  00 3C 00 00  00 00 00 00  .4.......<......
[00:43] <psusi> and if it didn't, it looks like the kernel would reject it
[00:44] <slangasek> FF EF D1 01 -> 30535663, which is 16 sectors short
[00:45] <slangasek> and the kernel is booted with gpt_sector=30535679
[00:46] <psusi> that is weird
[00:50] <slangasek> yeah, and I can confirm that this kernel has a check for my_lba == lba
[00:50] <slangasek> is is_gpt_valid()
[00:50] <slangasek> (branch 'grouper' on git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git, fwiw)
[00:51] <slangasek> oh, y'know what
[00:52] <slangasek> I'm not sure how, but I got the hex->dec conversion wrong
[00:52] <slangasek> FF EF D1 01 -> 30535679 after all
[00:52] <slangasek> so - yes, it claims to be the primary gpt, not the alternate
[00:53] <slangasek> and the address given for the alternate GPT is empty
[00:54] <psusi> iirc, that's actually what the alt is supposed to look like... it says my_lba = wherever it's at, and the alt points to the *other* copy
[00:55] <slangasek> oh, then how can you tell the difference between the primary and the alt anyway?
[00:56] <psusi> whether you found it at the beginning of the disk, or (end of disk, or what the primary says is alt_lba)
[00:56] <psusi> so if the primary was just in an odd place, but the backup was at the end, then you could at least find the primary by what the backup says is the alt, and at least decide the situation is sane, just weird
[00:57] <psusi> but it looks like this guy just flat how has no primary
[00:58] <slangasek> it has the "primary", which is at the end, which is where the kernel argument says to look for it
[00:58] <slangasek> I don't see the point in calling it an alternate when it's not an alternate to anything
[00:58] <psusi> kernel argument just says find *one* here... not which it is
[00:59] <psusi> the other thing about the backup is that the header follows the table, instead of the other way around.. but really, which one is which is just semantics
[01:03] <slangasek> well, but that's convention; the GPT header *could* point anywhere for the GPT entries, and in the case of a GPT header in the last sector, it will always point somewhere earlier
[01:04] <psusi> right... and in this case, it points to the normal location of 0, only there isn't another header there
[01:04] <psusi> err, wait... no...
[01:04] <slangasek> nah, it points to 13313, which is empty
[01:05] <psusi> ahh... man... this just gets weirder and weirder...
[01:05] <psusi> they bothered pointing it somewhere, but didn't actually put a copy there
[01:23] <slangasek> psusi: ok, so as near as I can tell, libparted doesn't actually care about the version field either
[01:23] <slangasek> it only objects if the value is too new
[01:25] <psusi> weird.. looks to be that way
[01:26] <psusi> I wonder why it's rejecting it then...
[01:26] <slangasek> dunno, checking now
[03:47] <stgraber> @pilot out
[05:28] <pitti> Good morning
[05:29] <pitti> bdmurray: traditionally we have done it for alpha-2, but with our changed devel process that doesn't apply much any more; I'll ask the team TLs (Daviey, seb128, cjwatson) later today when they are online, and also ev
[06:15] <tjaalton> anyone know what 'unix-zany' refers to on libpam-cracklib's pam-config Conflicts?
[06:57] <dholbach> good morning
[07:05] <pitti> hey dholbach, guten Morgen
[07:17] <dholbach> hey pitti
[07:34] <infinity> seb128: Hey, guess whose compiz has crashed twice in the last two days? :/
[07:35] <seb128> infinity, not me!
[07:35] <infinity> seb128: :P
[07:36] <seb128> infinity, I think Trevinho fixed the issue, but there was no bamf landing since...
[07:36]  * infinity loves how it resizes and scatters all his windows.
[07:36] <seb128> sil2100, ^ do you know what's blocking that fix to land?
[07:38] <sil2100> seb128, infinity: hi! Sadly, bamf is part of the indicator stack, and it would be safest to land both unity and indicators together, since otherwise there is a chance things might get broken
[07:38] <seb128> sil2100, what is blocking unity and indicator from landing? ;-)
[07:38] <sil2100> And we still had a lot of regressions in Unity due to HUD, but I guess there's a chance that today we'll be able to land
[07:38] <seb128> sil2100, oh, and hey ;-)
[07:38] <seb128> great!
[07:39] <sil2100> Let me just check the stacks status right now, I'm hoping for the best :)
[07:45] <didrocks> sil2100: hey! FYI, as you forced the merge of indicator-datetime yesterday, everything was stuck this morning (as libical is still not in the release pocket)
[07:45] <didrocks> sil2100: so I added -proposed to the daily-build ppa (but we'll still need to convince upstream to add it to their CI)
[07:47] <sil2100> didrocks: wait, so -proposed was not enabled for daily-build as well?
[07:47] <sil2100> didrocks: my understanding was that it was missing from CI, but not from our PPA
[07:47] <didrocks> sil2100: no, I didn't know that was possible, just checked this morning with infinity and enabled
[07:48] <didrocks> sil2100: that's why https://jenkins.qa.ubuntu.com/job/cu2d-indicators-head-2.1build/216/console took so long
[07:48] <didrocks> (however libdbusmenu FTBFS)
[07:49] <didrocks> hum, seems to be a failure to upload, lauchpad issue then
[07:49] <didrocks> launchpad*
[07:58] <zyga> barry: is your python3 dbus tree in active development?
[08:02] <didrocks> sil2100: so, I guess for libdbusmenu, you would need to retry the build in launchpad and then rerun with "foo" to take it into account
[08:04] <sil2100> didrocks: ACK, will do that, since I'm anyway doing the stackzz now
[08:05] <tvoss> pitti, can you jump over to #ubuntu-mir? got a question around logind/systemd
[08:07] <seb128> tvoss, he said he had to go out for some errands half an hour ago, he might not be back yet
[08:07] <tvoss> seb128, okay, thanks
[08:42] <cjwatson> slangasek: That update-manager autopkgtest run predated the proposed-migration integration; it should probably just be retried, which perhaps jibel can take care of (I'm not sure whether me abusing adt-britney to do so would have strange side-effects)
[08:45] <jibel> cjwatson, retrying update-manager
[08:46] <cjwatson> Thanks
[08:47] <cjwatson> jibel: Did you get anywhere with making the jenkins integration return running autopkgtests?  I'm waiting to see that working properly before announcing this work
[08:49] <jibel> cjwatson, I'm on it this morning, expect something early afternoon.
[08:49] <cjwatson> Brilliant
[09:47] <m4n1sh> ev: looks like there is a segfault due to some weird reason. I have updated the MP with the backtrace. Even rico had the same segfault, but none of these segfaults happen on clean VMs. but they crash when used on regular installs (being used for some long time)
[09:47] <ev> m4n1sh: yeah, I saw the MP. Working through it myself, but temporarily pulled over to some deployment work
[09:47] <m4n1sh> ev: no issues, just thought of asking in case you were free. Anyway I need to sleep
[09:48] <ev> m4n1sh: enjoy :) I'll have something done for you to review in your morning
[09:54] <pitti> tvoss: I'm back
[09:54] <tvoss> pitti, hey there, can you hop over to #ubuntu-mir, we have got some systemd questions about seat management
[11:10] <asac> cjwatson: i assume there has been quite some discussion in debian etc. about maintainerscripts. do you remember a good overview what classes of things are done in maintainerscripts in practice?
[11:11] <asac> from top of my head i see: initrd and bootloader poking, dkms, VM/bytecode compile, apt migration hacks/magic ... anything big missing?
[11:12] <ogra_> alternatives ...
[11:12] <ogra_> diversions ?
[11:14] <cjwatson> asac: I don't really have an overview.  The main class of things you're missing is things that are handled by debhelper autoscripts, typically system integration hooks of various kinds
[11:14] <cjwatson> So things like updating icon caches when icons are installed
[11:14] <cjwatson> Lots and lots and lots of special cases, e.g. generating sshd host keys
[11:15] <cjwatson> Configuration file migration between versions
[11:15] <cjwatson> Adding system users
[11:16] <pitti> in a nontrivial number of cases, also configuring servers to the user's wishes (debconf)
[11:16] <pitti> (postfix, databases, wordpress, ...)
[12:14] <maxb> asac: everything to do with dynamically created system users/groups
[12:15] <Laney> doko: are you looking at p11-kit?
[12:17] <doko> Laney, no, not yet
[12:19] <doko> Laney, do you want to?
[12:19] <Laney> not particularly :-)
[12:19] <asac> cjwatson: pitti: maxb: thx!! guess have a good picture now
[12:19] <asac> ogra_: ^^
[12:19] <asac> u2
[12:20] <ogra_> :)
[12:21] <maxb> asac: In particular, chowning of files to dynamically created users happens in maintainer scripts too (since they can't be shipped that way in the package tarball since the users may not exist at unpack time)
[12:21] <maxb> Which surprised me when I encountered it at first
[12:21] <asac> maxb: what class of packages does system user/group shuffling? i feel thats mostly server stuff, right?
[12:22] <cjwatson> Nah, all sorts of things, anything that needs a degreee of isolation by way of a dedicated user for instance
[12:22] <cjwatson> e.g. whoopsie
[12:23] <cjwatson> I mean, server packages yes, but I don't think it can really be pigeonholed
[12:23] <maxb> libuuid is one of the more unexpected ones which does it
[12:23] <cjwatson> click-package is notably not server right now and does it :)
[12:24] <cjwatson> avahi-*, colord, dbus, hplip, pulseaudio, speech-dispatcher, ...
[12:24] <xnox> cups
[12:24] <cjwatson> virtualbox, wpasupplicant, bluez, lightdm
[12:24] <xnox> any daemon one might be running, and not as root
[12:25] <xnox> samba
[12:25] <cjwatson> only the server side of samba I think
[12:37] <xnox> ok.
[12:47] <jibel> cjwatson, r195 makes 'collect' return the list of running tests.
[12:49] <cjwatson> jibel: Great, thanks.  Deployed.  Let's see how it does on the next run ...
[12:50] <jibel> cjwatson, when you announce this work, could you mention that uploaders will be notified on first failure and I'll turn this feature on? Or you prefer if I do it separately
[12:56] <cjwatson> jibel: Oh, is that ready at the IS side?
[12:57] <Laney> oh yay, that sounds cool
[13:00] <pitti> yes, ATM these mails go to a list, jibel, and me
[13:00] <jibel> cjwatson, yes, it is since a week or so and tested it works. For the moment the blamee is copied in the notification message. There a variable to change to add it to the list of recipients.
[13:01] <cjwatson> jibel: If it's ready to enable, go for it
[13:01] <Laney> does it blame the right person for rdep breakage?
[13:04] <zyga> barry: ping
[13:04] <jibel> Laney, it blames the uploader of the package that broke, if the package is broken because of an rdep, I have no way to automatically identify the source of the breakage.
[13:05] <pitti> I guess he means if we upload libfoo to -proposed, this triggers the test of the rdep bar
[13:06] <pitti> if bar fails, then the uploader of libfoo shold be notified
[13:06] <xnox> and how is uploader calculated? e.g. for syncs from debian & sponsored uploads.
[13:06] <jibel> pitti, that'd mean for example it'd blame doko for all the broken packages depending on python or libc ;)
[13:08] <doko> never!
[13:08] <pitti> jibel: well, if a new python3.3 breaks ubiquity, that would be kind of right?
[13:08] <pitti> or libc breaks apache, or what not
[13:08] <doko> libc -> infinity
[13:09] <xnox> pitti: but it's me who has irc highlights for "ubiquity" =) ubiquity -> ubuntu-installer team
[13:10]  * xnox would still blame bar, apache, ubiquity, etc. As that's the person who TIL and should either fix it or punt it to the rdep uploader.
[13:11] <barry> zyga: in a meeting
[13:11] <zyga> barry: ok, when can I ping you next?
[13:11] <jibel> pitti, that's very difficult to determine the cause automatically. For example if symbols are deprecated in a lib and a package depending on this lib fails because warning are considered errors, then the uploader of the lib shouldn't be notified, should he?
[13:11] <barry> zyga: 50m
[13:11] <pitti> xnox: then perhaps notifying both? if I upload a new pygobject that breaks ubiquity, then first and foremost I are to blame
[13:12] <pitti> it's still a matter of investigation and negotiation whether ubiquity should be adjusted to a new API or whatever, of course; same with glib or python
[13:12] <xnox> pitti: maybe =)
[13:12] <zyga> pitti: or maybe you can help me instead
[13:12] <zyga> pitti: I wrote some very cool code for python3-dbus, I was looking for some upstream devs to help me upstream it
[13:13] <pitti> jibel: I think he should be, to know why/that his package won't land in saucy in the usual 30 minute timeframe
[13:13] <zyga> pitti: I improved over the basic code to add support for properties with introspection, in a generic manner
[13:13] <pitti> zyga: I'm not a python-dbus developer I'm afraid
[13:13] <zyga> pitti: I'm about to work on ObjectManager interface
[13:13] <zyga> ok, thanks
[13:14] <pitti> zyga: hm, wouldn't that fit better with using the Gio (introspected) bindings, not python-dbus?
[13:15] <zyga> pitti: gio? gobject introspection?
[13:15] <zyga> pitti: we're not using any gobject code in our app and the bindings could very well offer native python equivalent
[13:16] <pitti> zyga: then perhaps you mean something else with ObjectManager than I do
[13:16] <pitti> (as that's a GDBus concept in my world)
[13:16] <zyga> pitti: I meant the std dbus interfaces: org.freedeskto.DBus.{Properties,ObjectManager}
[13:16] <jibel> pitti, also when several rdeps are tested simultaneously, we do not trigger a package test with depA then depB and depA+depB but just depA+depB, in that case we don't know which is responsible for the breakage, who should be notified?
[13:16] <pitti> zyga: ah, ok
[13:16] <zyga> pitti: python3-dbus does not support exporting propeties (you have to code everything manually)
[13:16] <pitti> jibel: I think we shold notify all affected packages
[13:16] <zyga> pitti: nor object manager (which is a recent addition IIRC but simplifies stuff a lot)
[13:17] <pitti> jibel: even if the problem is in the rdep, one point of that notification is to tell that your upload won't land in Ubuntu without further investigation
[13:18] <pitti> effing powerpc -- you skip one failing test case, now the next one fails !?
[13:19] <ev> has policykit changed in some subtle way? I would expect perm = Polkit.Permission.new_sync('com.ubuntu.apport.root-info', None, None); print perm.get_can_acquire(); to return True.
[13:20] <pitti> $ pkcheck --action-id com.ubuntu.apport.root-info --process $$
[13:20] <pitti> Authorization requires authentication and -u wasn't passed.
[13:20] <pitti> with --allow-user-interaction it indeed succeeds
[13:23] <pitti> ev: polkit hasn't really changed in saucy, just that it switched from CK to logind for session tracking; the client-side behaviour shold be identical
[13:23] <ev> pitti: it's entirely my fault
[13:24] <ev> was running through a shell not in a desktop session
[13:24] <ev> and failed to recall why that obviously wouldn't work :)
[13:24] <pitti> oh, do we only allow active sessions?
[13:24] <ev> it appears so
[13:24] <pitti> hm, no, we don't
[13:24] <pitti>       <allow_any>auth_admin</allow_any>
[13:24] <pitti>       <allow_inactive>auth_admin</allow_inactive>
[13:24] <pitti>       <allow_active>auth_admin</allow_active>
[13:25] <pitti> sounds like it still requires the calling process to be in _some_ session
[13:29]  * pitti goes to debug suspend, away from IRC for a bit
[14:24] <stokachu> xnox: should i ping ftpmaster again? i havent seen any activity since youve uploaded it
[14:25] <xnox> stokachu: package count in NEW: 245 - see http://ftp-master.debian.org/new.html
[14:25] <stokachu> ah
[14:25] <xnox> stokachu: i would not hold my breath.
[14:26] <xnox> stokachu: you are more than half way up the list =)
[14:26] <stokachu> xnox: lol ok ill keep my eye on this list
[14:34] <zyga> barry: reping
[14:37] <barry> zyga: hi.  i think i'm recovered from my kernel panic now :)  what's up?
[14:39] <zyga> barry: I was looking at someone to contact wrt python3-dbus
[14:39] <zyga> barry: I recall you have a repo on github with that, is that correct?
[14:40] <zyga> barry: I wrote a number of improvements over the stock thing, I've got working @dbus.service.propery + Get/GetAll/Set + Introspection XML
[14:40] <barry> zyga: long ago merged into their trunk
[14:40] <zyga> barry: and I'm writing ObjectManager code
[14:40] <zyga> barry: I would like to contribute that all upstream
[14:41] <barry> zyga: awesome.  simon is very responsive to contributions.  i'm also happy to take a look if you do a pull request
[14:41] <jamespage> is there a nice way to detect as an upstart event when all network interfaces configured in /etc/network/interfaces have been started?
[14:42] <zyga> barry: how can I get in touch with simon and where is the real upstream repo for that?
[14:44] <barry> zyga: let me track some stuff down for you
[14:45] <zyga> barry: thanks a lot!
[14:53] <barry> zyga: oy, it's been a long time since i poked at this.  http://cgit.freedesktop.org/dbus/dbus-python/
[14:53] <barry> zyga: https://bugs.freedesktop.org/index.cgi
[14:53] <zyga> barry: thanks a lot!
[14:53] <zyga> barry: I'll see how my code stacks on top of that
[14:54] <barry> zyga: probably the best thing to do is to file a bug against dbus-python with the feature request.  simon usually responds pretty quickly.  you can also probably dig up his @debian.org address for direct contact
[14:55] <zyga> I'll start with the bug report
[14:55] <zyga> cool, my first contribution upstream :)
[14:56] <barry> zyga: \o/  send me the bug url and i'll subscribe
[14:58] <zyga> barry: ok
[14:59] <seb128> cjwatson, sorry to bother you about that again, but we have having an hard time to have a grasp on what we should check for/verify/do to be able to move signon-ui from saucy-proposed to saucy
[14:59] <seb128> kenvandine, ^ moving the discussion here
[14:59] <zyga> barry: looking at https://bugs.freedesktop.org/enter_bug.cgi I don't see python-dbus, just dbus, is that the appropriate component
[15:00] <barry> zyga: yes, i think so.  here for example is one of my still open bugs: https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&email1=barry%40python.org&field0-0-0=bug_status&type0-0-0=notequals&value0-0-0=UNCONFIRMED&field0-0-1=reporter&type0-0-1=equals&value0-0-1=barry%40python.org&list_id=312978
[15:00] <barry> oh lovely
[15:00] <barry> https://bugs.freedesktop.org/show_bug.cgi?id=55594
[15:01] <barry> zyga: so product dbus component python
[15:02] <zyga> barry: got it, filing bug now
[15:02] <kenvandine> seb128, actually let me see if i can make it buildable on powerpc too
[15:03] <seb128> kenvandine, it will not work, that's cheating... :p
[15:03] <kenvandine> well it still has the non-qml code path there
[15:03] <kenvandine> so if i don't build with use-webkit2 config it might work
[15:04] <seb128> cool
[15:04]  * kenvandine sets up a ppc pbuilder
[15:05] <seb128> kenvandine, have no fear ;-)
[15:11] <zyga> barry: https://bugs.freedesktop.org/show_bug.cgi?id=65900
[15:13] <cjwatson> seb128: I'll have a look at it after this call
[15:13] <seb128> cjwatson, thanks
[15:13] <cjwatson> You caught me pretty near EOD yesterday
[15:19] <barry> zyga: subscribed, thanks
[15:20] <zyga> barry: thank you!
[15:29] <pitti> seb128, cjwatson, Daviey, ev: What is your feeling about turning on apport crash reports in Launchpad for saucy? and when?
[15:29] <pitti> I get pinged about that from time to time
[15:29] <cjwatson> I'm agnostic on that
[15:30] <seb128> pitti, no strong opinion either, somebody was asking about it last week I think (bdmurray iirc) so maybe it's time for that?
[15:32] <pitti> we can certainly say at some point "errors.u.c. is the thing", depends on how intensive we want to deal with crash reporters this cycle?
[15:33] <zyga> hmm, working on upstream python-dbus requires dbus-1.6, I guess I need to try saucy or something recent
[15:34] <barry> zyga: rolling releases! :)
[15:35] <pitti> zyga: saucy loves you!
[15:35] <barry> or maybe now they should be called sauntering systems
[15:43] <zyga> pitti: I'm on 12.04 again, since my daily work is really only about 12.04
[15:43] <zyga> pitti: I guess vagrant is the way forward for me :)
[15:47]  * psusi can't wait for HAL to die
[15:51] <sil2100> Hi guys, hm, we seem to get some strange errors on the indicator stack when we enabled -proposed
[15:51] <sil2100> RuntimeError: the sip module implements API v10.0 but the PyQt4.QtGui module requires API v9.2
[15:51] <sil2100> Do you think it might be related to some recent changes in -proposed? Or unrelated?
[15:52]  * sil2100 would need someone from the AP team
[15:53] <xnox> sil2100: new upstream release of sip4 was uploaded 3 hours ago, it is possible that python-qt4 needs a rebuild.
[15:53] <sil2100> oh
[15:53] <sil2100> xnox: hm, thanks for the info
[15:53] <sil2100> didrocks: ^
[15:53] <didrocks> cjwatson: this is what happens when enabling -proposed for running the tests, not sure how we can safely get transitions while avoiding those ^
[15:53] <sil2100> ;/
[15:55] <cjwatson> you could check installability before starting the test
[15:55] <rbasak> infinity: any progress on bug 1187722 please? If not, can we apply a less complete workaround to dpkg-shlibdeps to get the golang FTBFS through?
[15:55] <cjwatson> and treat uninstallability separately from test failures
[15:55] <xnox> didrocks: well, case in point python-qt4 is missing a dep8 test which depends on sip4 which would catch the above problem and present sip4 from migrating to -release. So actually -proposed is not the problem here. As saucy-release is borked as well at the moment.
[15:55] <didrocks> cjwatson: it's installable though
[15:55] <cjwatson> if it's uninstallable and busted that's a problem in itself!
[15:55] <cjwatson> er, installable and busted
[15:55] <infinity> rbasak: The fix needs to be in golang (well, and dpkg-shlibdeps, but that's trivial), not something we just "work around".
[15:56] <didrocks> cjwatson: yep, but still this kind of issue will block our testing anyway, I have no idea how we can fallback to a safer bet in that case
[15:56] <xnox> didrocks: we do know that uploading foo can break tests of rdeps bar. and either foo or bar needs fixing.
[15:56] <infinity> rbasak: If we just work around it, half the archive will end up with a dependency on libsfgcc1. :P
[15:56] <didrocks> xnox: not in proposed, after proposed, right
[15:56] <rbasak> infinity: for now, why can we not just assume that if "readelf -A" returns nothing, then the binary's ABI is the same as the host ABI? I understand this breaks for multiarch cross-compile, but that's an edge case on top of an edge case.
[15:57] <xnox> didrocks: but you will not be able to land. as you have to land via proposed. so a safer bet is to fix python-qt4 asap, and add measures to prevent this breakage in the future.
[15:57] <xnox> sil2100: didrocks: where are the logs for this API version missmatch?
[15:57] <infinity> rbasak: We could just fix golang.  It's not rocket science to do so.  This isn't quite something worth panicking over yet, is it?
[15:59] <sil2100> xnox: you mean, from our side?
[15:59] <Laney> where did you see that message?
[15:59] <xnox> sil2100: i mean the full log where " implements API v10.0 but the PyQt4.QtGui module requires API v9.2" error is visible.
[16:00] <sil2100> xnox: one moment
[16:00] <didrocks> xnox: right, but just enabling -proposed for the first time shows that we are getting an issue, I'm not sure if it's bad luck or that will make the tests failing too regularly
[16:00] <rbasak> infinity: we'll have less time to test any other issues caused by the 1.1 bump. Given that the built binary works, I'd prefer to see it in the archive. But it's a good question. I'll try and find out if there's a reason we should fix it sooner. So that I understand the situation right, are you saying that my workaround would work, but you'd prefer to only put it in if we need golang into saucy sooner?
[16:00] <xnox> didrocks: sip4 migrated to saucy-release, so by enabling -proposed you saw the issue 3h earlier.
[16:01] <didrocks> xnox: right, but it's just one issue, on potentially a lot :)
[16:01] <infinity> rbasak: Your workaround could have unintended side effects.  As noted, if we just ignore the HF bits entirely, half the archive will end up depending on libsfgcc1.  This isn't a theory, it happened once and I had to rebuild after fixing dpkg-shlibdeps. :P
[16:01] <xnox> didrocks: of course. but testing against release pocket, then uploading into -proposed pocket, then failing testing in -proposed, and blocking release is much longer, than doing it in -proposed straight away.
[16:02] <didrocks> xnox: depends, we have a lot of components to land everyday, if the instability for us to retry too much, that's not going to scale
[16:02] <xnox> didrocks: as there were initial teething problems with just daily landing, there will be teething problems with using -proposed. But we can flag them up, resolve and minimise to gain an overall improvement.
[16:02] <infinity> rbasak: But the workaround is also a waste of time when we could just fix the problem.  I only diagnosed this on Friday night, and spent most of Monday in a hospital, 1 working day seems like a pretty short timescale to go from "oh, hey, look, a bug" to "we need hackish workaround now".
[16:03] <rbasak> Sorry, I didn't realise your perception on the problem was so short. I'd been looking at it since before I filed the bug a couple of weeks ago.
[16:03] <didrocks> xnox: the only issue with using -proposed is that it's not one time breakage, it can be regular breakages :)
[16:04] <cjwatson> didrocks: Well, it's a classic velocity vs. quality trade-off; but I don't know how we can do effective quality checks if we aren't testing at least some things from -proposed
[16:04] <cjwatson> didrocks: Perhaps the CI tests should have -proposed enabled in apt sources, but pinned in apt preferences such that it's only used when necessary
[16:04] <cjwatson> didrocks: That way transitions would be possible in a useful way but you wouldn't pull in *everything* from -proposed
[16:04] <cjwatson> didrocks: However I agree with xnox that in this case it seems to have made no practical difference
[16:04] <rbasak> infinity: can I help with the fix? Or shall I leave it to you? I'm not sure I understand the specifics of the ELF header change you're using (as opposed to the eabi section tags), but am happy to catch up.
[16:05] <cjwatson> Or very little, anyway
[16:05] <Laney> Seems weird to be having this argument when it wasn't actually a problem with proposed
[16:05] <didrocks> cjwatson: in that case, we are quite stuck, as there is the sip transition (until qt4 is fixed), and indicator-datetimes can't be tested with new libical, right
[16:06] <cjwatson> But the sip transition is in release, so you'd have been stuck anyway.
[16:07] <cjwatson> And if sufficient attention had been paid, this could have pointed out that (it sounds like) sip4 is missing a Breaks field and we could have caught that before it affected users ...
[16:07] <infinity> Hrm.  I haven't had a kernel panic in a long time.  That was exciting.
[16:07] <didrocks> cjwatson: ah ok, I missed that one (I thought it will transition soon, just not yet)
[16:09] <cjwatson> Damnit, I want 'dak rm -Rn' for this signon-ui thing
[16:09] <didrocks> cjwatson: I think I a Ken who will be really interested as well :)
[16:09] <cjwatson> seb128: Were we going to rebuild empathy without signon support on powerpc to simplify this?
[16:10] <cjwatson> seb128: (I could take care of that if it would help - the fewer dependencies I need to trace by hand the better)
[16:10] <seb128> cjwatson, if that helps we can
[16:10] <seb128> cjwatson, we are bit lost on where to start
[16:10] <seb128> looking at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/signon-ui/signon-ui is hard
[16:10] <cjwatson> I'm starting by tracing the rdeps back with checkrdepends -a powerpc
[16:11] <cjwatson> Unfortunately it doesn't distinguish Depends and Recommends, so some manual checks too
[16:11] <cjwatson> And for each binary package working out what tearing out all binaries from that package on that architecture will do, recursively
[16:11] <seb128> quite tedious :/
[16:11] <xnox> didrocks: sil2100: let me fix the python-qt4 problem.  We'll re-launch our machinery then
[16:12] <cjwatson> seb128: I'll sort out empathy now
[16:12] <seb128> cjwatson, would it help if we start by building empathy without uoa support on ppc?
[16:12] <seb128> cjwatson, ok, thanks, let me know if we can do anything to help
[16:12] <seb128> kenvandine, ^
[16:12] <cjwatson> seb128: Yep, that was my plan
[16:13] <kenvandine> cjwatson, great, thanks!
[16:23] <ev> mpt, bdmurray: a heads up. We're going to have to purge reports from the database that don't have a DistroRelease field. I'll have it increment a counter for the day period that these were written, so we have some history of how many such (bogus) reports we were getting
[16:24] <ev> (in a critical disk space situation on the cluster)
[16:24] <mpt> ev, how much time will that buy? :-)
[16:26] <ev> mpt: barely any
[16:27] <ev> suggestions welcome on how we can further define a bogus report that can be sent to the abyss
[16:27] <ev> this is in parallel to bringing up some more nodes in production
[16:27] <cjwatson> kenvandine: Something like http://paste.ubuntu.com/5777580/ look vaguely right?  I'm going to test that shortly
[16:27] <ev> to further spread the load
[16:29] <kenvandine> cjwatson, close
[16:29] <kenvandine> +  DEB_CONFIGURE_EXTRA_FLAGS += --enable-ubuntu-online-accounts=yes
[16:29] <kenvandine> you want that to be =no for powerpc
[16:29] <kenvandine> unless you meant ifneq
[16:30] <cjwatson> I have that on the wrong side of the if, indeed
[16:30] <cjwatson> Is that the right set of build-deps to disable, and is removing that set of binary packages correct?
[16:31] <kenvandine> cjwatson, ues
[16:31] <kenvandine> yes even
[16:40] <sil2100> kenvandine: can you approve some changelog-modding branches?
[16:43] <sil2100> kenvandine: https://code.launchpad.net/~sil2100/bamf/add_bug_number/+merge/170134
[16:43] <sil2100> kenvandine: https://code.launchpad.net/~sil2100/gnome-control-center-unity/add_bug_number/+merge/170114
[16:46] <kenvandine> sil2100, sure
[16:47] <sil2100> kenvandine: thanks!
[16:47] <kenvandine> np
[16:49] <kenvandine> seb128, to get signon-ui to build on ppc, even without qtdeclarative, we'd need libqt5webkit5-dev for powerpc
[16:50] <kenvandine> which isn't available for powerpc either :/
[16:50] <seb128> kenvandine, :-(
[16:50]  * kenvandine scratches the goal of building signon-ui for ppc
[16:50] <seb128> so we just need to kick uoa use out of desktop on ppc
[16:50] <kenvandine> seb128, yes
[16:51] <cjwatson> Now if cdbs would stop being appalling I might be able to disconnect empathy from this
[16:51] <kenvandine> it isn't useful anyway, since we only show the settings panel in unity
[16:51] <xnox> sil2100: didrocks: rebuilding python-qt4 resolves the sip api missmatch error. I have added an autopackage test in python-qt4 to literary do "python -c 'from PyQt4 import QtGui' " thus if sip breaks python-qt4 in the future, we would know about it straight away. It's building at the moment: https://launchpad.net/ubuntu/+source/python-qt4/4.10.1-1ubuntu2 so once that is published and the new autopkgtest pases it should be green light to restart everyt
[16:51] <xnox> hing that has failed.
[16:51] <didrocks> xnox: excellent, thanks! :)
[16:51] <cjwatson> For clarity I consider removing signon-ui from powerpc to be agreed and will do it; I'm just trying to minimise the complexity
[16:52] <seb128> cjwatson, +1
[16:52] <kenvandine> cjwatson, +1
[16:52] <kenvandine> thanks!
[16:52] <kenvandine> cjwatson, i just took a stab and making it easier to deal with... but failed
[16:53]  * cjwatson nods
[16:54] <xnox> didrocks: i wonder if it makes sense to check reverse-dependancy autopkg tests for green light, before starting CI. As if reverse-dependancies are borked, there is little point in testing something higher up in the dependancy chain.
[16:54]  * xnox is not entirely sure about that atm.
[16:55] <cjwatson> Looks like setting DEB_ARCH_PACKAGES this way doesn't work - may have to settle for the crappy explicit list of architectures
[16:57] <AugustVento> test
[17:00] <AugustVento> when i start ubuntu ,it give me some message, "[    15.117693] INFO @wl_cfg80211_attach : Registered CFG80211 phy"
[17:01] <AugustVento> i just know, it about wireless hardware, how to fix it ,or hide that message
[17:03] <sarnold> AugustVento: you can set the loglevel kernel command line parameter to show only messages of a certain importance and higher: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
[17:03] <bdmurray> ev: there is also that extra data in Counters for release source package crash counts
[17:04] <bdmurray> ev: we only "need" two weeks of data so stuff before that could go
[17:04] <AugustVento> ok sarnold ,i try it.
[17:08] <bdmurray> pitti: I don't think errors is ready to be the thing until we have those server side hooks
[17:09] <slangasek> pitti: yay, thanks for the g-s-d fix
[17:19] <sil2100> xnox: thanks! Do you have any reverse-feedback on when it would be released? I would love to know when I can re-build stuff
[17:20] <lool> cjwatson: I think you can just pass -Npkg in some arg that gets passed to dh_*; digging that up
[17:22] <cjwatson> lool: There's no way to get cdbs to pass it to dh_listpackages, but I suppose it's possible that DH_OPTIONS := -Nblah would help
[17:22] <lool> cjwatson: Yeah, I think that's what I used
[17:22] <cjwatson> The problem is make doesn't re-export to $(shell)
[17:22] <cjwatson> Which is apparently a well-known bug
[17:22] <ev> bdmurray: noted, thanks!
[17:22] <cjwatson> dh doesn't suffer from this because it doesn't use $(shell) in that way
[17:23] <ev> first looking at the Stacktrace CF, which most certainly doesn't need ProcEnviron and friends
[17:23] <xnox> sil2100: just wait until https://launchpad.net/ubuntu/+source/python-qt4/4.10.1-1ubuntu2 is published in release. Probably in 2h-3h or so. python-qt4 is huge to build.
[17:24] <sil2100> Uuuh ;)
[17:24] <sil2100> Ok!
[17:24] <lool> maybe DEB_DH_BUILDDEB_ARGS is enough; I can't find a package doing this anymore
[17:25] <sil2100> I'll re-run stuff in that time then, keeping an eye on that
[17:25] <andyrock> Laney, hey I got a fix for the nautilus crash
[17:26] <andyrock> do you want me to update your .patch or add a new one?
[17:26] <seb128> andyrock, update the patch
[17:27] <seb128> andyrock, submit upstream as well please ;-)
[17:27] <andyrock> seb128, maybe I can change the name?
[17:28] <andyrock> seb128, nautilus 3.8 can't have that issue
[17:28] <andyrock> seb128, they refactored "a bit"
[17:28] <cjwatson> lool: The problem is that cdbs runs each package independently with -p
[17:29] <cjwatson> Rather than doing single bulk runs with -a/-i
[17:33] <seb128> andyrock, oh ok, just update the patch in a way that fix it and write as a comment that it's fixed upstream in 3.8
[17:35] <xnox> cjwatson: i would have thought, it should be possible to filter the internal cdbs DEB_ARCH_PACKAGES and DEB_INDEP_PACKAGES to exclude whichever one you don't need. The rest of cdbs machinery works against packages from that list.
[17:35] <andyrock> seb128, i still need to check that nautilus 3.8 is not affected hang on
[17:35] <xnox> but i'm not entirely sure, didn't have to do anything like that before.
[17:36] <seb128> andyrock, ok
[17:36] <seb128> cjwatson, just port it to dh9 ;-)
[17:36] <xnox> .... or that =)
[17:42] <cjwatson> seb128: No, it runs into https://savannah.gnu.org/bugs/?10593
[17:42] <cjwatson> Er
[17:42] <cjwatson> xnox: No, it runs into https://savannah.gnu.org/bugs/?10593
[17:43] <seb128> speaking of make we should maybe update our version one cycle ;-)
[17:44] <cjwatson> it's deliberately held back
[17:44] <cjwatson> the new version breaks a LOT apparently
[17:45] <lool> cjwatson: adding -Npkg before or after -ppkg should still skip it (seems to work with dh_listpackages); I can't find a package doing that, but DEB_DH_BUILDDEB_ARGS += -Npkgname would possibly work
[17:46] <lool> you probably would have to skip dh_install and dh_builddeb at least; I don't see anything simpler with cdbs right now
[17:48] <lool> seb128, kenvandine: Believe it or not, some IBM folks stepped up to port v8 to powerpc!  :-)  they are based on a newer version than the one in the qtwebkit source we have, and they have 88% of the tests passing
[17:48] <seb128> lool, nice ;-)
[17:48] <lool> https://github.com/andrewlow/v8ppc/blob/master/README.md
[17:48] <lool> they are based on a september snapshot, qtjsbackend-opensource-src has an april 2012 snapshot
[17:48] <seb128> lool, though qtdeclarative is moving to its own js engine as you said
[17:48] <seb128> so not sure how useful that will be
[17:49] <lool> seb128: yeah, but that's probably longer term
[17:49] <lool> it might mean that qtdeclarative does *not* support powerpc in the end  :-/
[17:50] <lool> IIUC from Zoltan qtdeclarative could be built against multiple JS engines so far, and that was a source of headache and they weren't performing well given the constraints on QML objects
[17:50] <lool> a new JS engine might perform better, but might have its own set of features/bugs and the JIT might only be ported to this or that architectures
[18:09] <cjwatson> lool: I've tried a few variations and nothing works.  TBH I'm fed up and am just going to hit it with "Architecture: amd64 armhf arm64 i386" ...
[18:09] <cjwatson> I only have so much time to spend on this
[18:14] <lool> cjwatson: sorry  :-/  I know it aint fun to reverse engineer the cdbs weirdnesses
[20:52] <gotwig> how can I install a glib schema with autotools
[21:00] <tedg> Hello, looking for an archive admin.
[21:00] <tedg> Need to add a new package to daily builds, and apparently it has to be whitelisted?
[21:01] <tedg> Not sure exactly, first time :-)
[21:01] <tedg> The package is upstart-app-launch
[21:06] <infinity> tedg: Pulled the new configs.
[21:06] <tedg> infinity, Cool, thanks!
[21:12] <Laney> andyrock: you still here? nautilus 3.8 definitely does still have that crash
[21:13] <Laney> I filed it upstream; see https://bugzilla.gnome.org/show_bug.cgi?id=702546
[21:46] <tjaalton> slangasek: hey, what does 'unix-zany' mean on libpam-cracklibs pam-auth-update config?
[21:50] <slangasek> tjaalton: that's a good question... that looks like an example that leaked into production ;)
[21:50] <tjaalton> hehe
[21:50] <tjaalton> yeah I thought so :)
[21:51] <tjaalton> so I'll drop it from the file for libpam-pwquality then..
[21:55] <slangasek> tjaalton: yeah, probably should :)
[22:23]  * Noskcaj is away: school


[01:39] <Qwertie> Ubuntu touch uses mir right?
[02:34] <dobey> Qwertie: yes
[02:35] <dobey> unity8 is based on mir
[05:20] <cc> is there any application about "Contacts blacklist"?
[05:21] <cc> ubuntu phone
[05:21] <cc> mei zu pro 5
[07:32] <Tims_Tech> Could someone help me with creating a stock device tree?
[09:48] <krowv> I’m trying to use phablet-dev-bootstrap -c phablet
[09:48] <krowv> keep getting this error: ERROR:phablet-dev-bootstrap:Error while trying to sync repository
[09:48] <krowv> is a repo down or something?
[09:53] <Tims_Tech> krowv, yes
[09:54] <krowv> well that would explain it
[09:54] <Tims_Tech> yes
[09:54] <Tims_Tech> I tried today too
[09:55] <krowv> just successfully built AOSP for my nexus 4, and now was moving onto building Ubuntu Phone from source.   Guiess it’ll have to wait.
[09:55] <Tims_Tech> yep
[09:55] <Tims_Tech> I need to make a device tree for AOSP first
[09:55] <Tims_Tech> we have cm11
[09:55] <Tims_Tech> but I can't use that one.
[09:56] <TheKit> Tims_Tech, do you have cm12?
[09:56] <Tims_Tech> nope
[09:56] <Tims_Tech> cm11
[09:57] <Tims_Tech> ad cm12 is done but doesn't work on the HN version, the H is lucky though
[09:57] <krowv> So is Ubuntu Phone still based off of 4.4.2_r1?
[09:57] <Tims_Tech> I think
[09:57] <Tims_Tech> yes
[09:58] <krowv> ultimately I’m trying to make Ubuntu Phone work on a Galaxy S4.
[09:58] <Tims_Tech> possible
[09:58] <Tims_Tech> :P
[09:58] <Tims_Tech> but you need a AOSP device tree
[09:58] <krowv> doesn’t seem like it should be to horrible if I can get AOSP to run on it.
[09:58] <TheKit> or if you have CM12, you can try with UBPorts tree
[09:58] <Tims_Tech> The cm11 and cm12 device trees are very
[09:58] <Tims_Tech> the same
[09:58] <Tims_Tech> :P
[09:59] <krowv> I’m confused.  is their an ubuntu based off of CM?  Or are you just talking about using CM
[09:59] <TheKit> Ubuntu is based off AOSP
[09:59] <Tims_Tech> yes
[09:59] <Tims_Tech> but it was based of CM
[09:59] <TheKit> there is unofficial tree based of CM (UBports)
[10:00] <krowv> interesting
[10:00] <Tims_Tech> I want to build Ubuntu touch by myself so I dont want UBports
[10:00] <Tims_Tech> :P
[10:01] <Tims_Tech> need to eat lunch
[10:01] <krowv> Tims_Tech: what would be the difference?
[10:01] <Tims_Tech> krowv, doing things by yourself gives you a feeling :P
[10:01] <TheKit> well, UBports also involves building it by yourself
[10:02] <krowv> I’m all about building things myself to learn…   I did just build AOSP from source and install on a Nexus 4.  I’ve also installed Ubuntu Phone on my Nexus 4 as well.  now I’m trying to build it from source.
[10:02] <krowv> and now I just learned about UBports, so checking that out.
[10:02] <TheKit> Nexus 4 is fine from AOSP, as it's supported
[10:04] <krowv> So what is the relationship between the UBPorts project and Ubuntu Phone itself?
[10:05] <TheKit> UBPorts is based on Ubuntu Phone, but they ported changes from Ubuntu's AOSP tree onto CM12 tree
[10:06] <krowv> So its an independent group but working somewhat in parallel.
[10:06] <krowv> sounds simmilar to the CM <—> AOSP relationship itself
[10:10] <applemuncy> Hi, I'm also in the just starting to build ubports. Every choice is falling over with different compile errors.
[10:28] <Tims_Tech> so ubports
[10:28] <Tims_Tech> are a dev team
[10:28] <Tims_Tech> :P
[10:29] <applemuncy> It seems a one man team  : )  mariogrip
[10:29] <Tims_Tech> hmm
[10:30] <Tims_Tech> he is pretty good with developing
[10:30] <Tims_Tech> so I want to join :P
[10:30] <Tims_Tech> :P
[10:30] <applemuncy> And he must be busy doing other things.
[10:30] <Tims_Tech> :P
[10:30] <Tims_Tech> why? applemuncy
[10:30] <applemuncy> Why?
[10:31] <Tims_Tech>  applemuncy> And he must be busy doing other things.
[10:31] <Tims_Tech> why?
[10:31] <Tims_Tech> or what do you mean?
[10:32] <applemuncy> I mean, he hasn't been active on ubports a few months now.
[10:32] <Tims_Tech> hmm
[10:33] <applemuncy> I've only been looking into ubports myself a few weeks.
[10:33] <Tims_Tech> hmm
[10:34] <Tims_Tech> I would love to join and learn from his dev skills
[10:34] <applemuncy> So it seems ubports is running on autopilot : )
[10:35] <applemuncy> Yes, he seems very good.
[10:35] <Tims_Tech> I will mail him and ask if he wants to idk join my irc channel .
[10:37] <krowv> So what all is involved porting to new hardware?  I’m asking because I’m trying to eventually make Ubuntu Phone work on a Samsung Galaxy S4.
[10:38] <krowv> It seems like I can build AOSP for it, then loading ubuntu phone shouldn
[10:38] <krowv> t  be that hard.
[10:38] <Tims_Tech> but
[10:38] <krowv> Am I missing something huge?
[10:38] <Tims_Tech> you need a device tree
[10:38] <Tims_Tech> stock
[10:38] <Tims_Tech> :P
[10:38] <Tims_Tech> and I have NO IDEA how to create one
[10:39] <Tims_Tech> krowv, can you help me>?
[10:40] <krowv> Not sure what you mean by device tree.
[10:41] <applemuncy> I'm also getting the message "Trying dependencies-only mode on a non-existing device tree?"
[10:44] <Tims_Tech> applemuncy, that is not a problem
[10:44] <Tims_Tech> it says it all the time
[10:45] <applemuncy> Thanks, good to know.
[10:45] <Tims_Tech> applemuncy, np
[10:45] <Tims_Tech> :P
[10:53] <applemuncy> When I try to build aosp_shamu-eng, lunch creates a local_manifests directory with roomservice.xml
[10:56] <applemuncy> Oops, lost Tim.
[10:57] <TheKit> krowv, basically you need to build patched Android base (AOSP or CM, whatever) which is going to be run inside LXC container
[10:57] <TheKit> and then make sure different components of Ubuntu run (for example, Mir is pretty troublesome on new devices)
[12:10] <tims_techlaptop> DAMNIT
[12:10] <tims_techlaptop> ubuntu touch is based of android 5.0 :(
[12:10] <TheKit> no
[12:11] <TheKit> there are 4.4, 5.1 and 6.0 trees
[12:23] <tims_techlaptop> TheKit, srsly?
[12:23] <tims_techlaptop> COOL
[12:23] <tims_techlaptop> :D
[12:23] <tims_techlaptop> TheKit, but how to create ubuntu touch from cm11 sources then?
[12:53] <tims_techlaptop> ow nvm
[12:53] <tims_techlaptop> I can create AOSP with cm11 sources
[12:53] <tims_techlaptop> will try
[12:53] <tims_techlaptop> and then
[12:53] <tims_techlaptop> I CAN do that
[13:45] <TheKit> tims_techlaptop, you can't
[13:45] <TheKit> but you can port patches from Ubuntu AOSP tree onto CM11 tree if you really want
[13:46] <tims_techlaptop> TheKit, ?
 I can create AOSP with cm11 sources
[13:47] <tims_techlaptop> yep
[13:47] <tims_techlaptop> I need to recreate the device tree
[13:47] <tims_techlaptop> but
[13:47] <tims_techlaptop> I can use most of it
[13:50] <applemuncy> Speaking of lunch, I wonder if I did the right thing?
[13:51] <applemuncy> I fallowed the install instructions on ubuntu touch.
[13:51] <applemuncy> then after running . build/envsetup.sh
[13:52] <applemuncy> I went to run lunch, but it wasn't installed.
[13:53] <applemuncy> So did an apt-get to install lunch.  Was that the right thing to do?
[14:03] <tims_techlaptop> hmm applemuncy
[14:03] <tims_techlaptop> depends
[14:06] <applemuncy> So I'm reading though envsetup.sh
[14:07] <applemuncy> Does it provide the lunch normally?
[14:07] <tims_techlaptop> yes
[14:07] <tims_techlaptop> normally
[14:07] <tims_techlaptop> which linux distro are you on?
[14:07] <applemuncy> Ahhh
[14:07] <applemuncy> Ubuntu 16.04
[14:08] <tims_techlaptop> me too :D
[14:08] <tims_techlaptop> it should just work
[14:09] <applemuncy> I often have multiple xterms open. Maybe I tried to run lunch in one I had not run envsetup.sh in.
[14:10] <tims_techlaptop> applemuncy, yes
[14:10] <applemuncy> I see that envsetup.sh is very powerful.
[14:11] <tims_techlaptop> yepppppp
[14:11] <applemuncy> Does things I did not expect.
[14:11] <tims_techlaptop> applemuncy, ur learning fast
[14:12] <applemuncy> Nope, I'm digging on Linux 20 years now. Still don't know it all  : )
[14:12] <applemuncy> So not a fast learner.
[14:12] <tims_techlaptop> applemuncy, I am 14 :P
[14:12] <tims_techlaptop> I am the new gen
[14:12] <tims_techlaptop> lol
[14:13] <applemuncy> I been meeting some amazing teenagers in my local makerspace.
[14:15] <applemuncy> Glad to meet you Tim  : )
[14:15] <tims_techlaptop> np :P
[14:15] <tims_techlaptop> I mean
[14:15] <tims_techlaptop> oops
[14:15] <tims_techlaptop> glad to meet you too applemuncy
[14:16] <tims_techlaptop> :P
[14:16] <tims_techlaptop> applemuncy, I live i nthe Netherlands, you>
[14:16] <tims_techlaptop> ?
[14:16] <tims_techlaptop> in**
[14:17] <applemuncy> Indiana, USA
[14:17] <tims_techlaptop> :P
[14:17] <tims_techlaptop> how old are you?
[14:17] <applemuncy> 68  : )
[14:17] <tims_techlaptop> :D
[14:18] <tims_techlaptop> applemuncy, are you male or female?
[14:18] <applemuncy> I'm a guy
[14:18] <tims_techlaptop> me too
[14:18] <tims_techlaptop> :P
[14:18] <applemuncy> Male, that is.
[14:18] <tims_techlaptop> yep
[14:18] <tims_techlaptop> I am the new generation
[14:18] <tims_techlaptop> I learn fast
[14:18] <tims_techlaptop> lol
[14:18] <tims_techlaptop> :P
[14:18] <tims_techlaptop> ;)
[14:19] <applemuncy> Yes, indeed.
[14:19] <tims_techlaptop> I started with creating roms 3 weeks back
[14:19] <tims_techlaptop> :P
[14:19] <tims_techlaptop> I am fast
[14:19] <tims_techlaptop> :P
[14:19] <applemuncy> Early access to the Internet makes a big difference.
[14:19] <tims_techlaptop> yep
[14:19] <tims_techlaptop> :P
[14:22] <applemuncy> Sad to need to do real life now.  I'm be back!
[14:22] <tims_techlaptop> bye :P
[16:31] <ahoneybun_> https://www.youtube.com/watch?v=sdfDRqRi_eI&index=27&list=PL02HDVnTgIcpnnRo8PRZDJnxILA2IHIpI
[16:32] <ahoneybun_> Win 10 Phone to Desktop
[16:35] <Tims_Tech> that is old news ahoneybun_ :)
[16:35] <ahoneybun_> this video is new
[16:35] <ahoneybun_> so they do a few things that Ubuntu did first
[22:46] <krowv> I’m using Ubuntu 16.04.  For building from source can I use the version of phablet that comes with 16.04?  Or do I need to add the phablet-tools PPA?


[00:00]  * mwhudson attempts to figure out how releases on launchpad work these days
[00:01] <jelmer> Tak: it's sometimes mentioned in the NEWS file
[00:01] <jelmer> Tak: I'm not seeing anything on Lucid
[00:03] <Tak> I thought maybe there was a change in the embedding api, or that I've been Doing It Wrong in a way that just didn't break before (md-bzr), but then a google search is gives hits for similar issues with a fair number of python apps
[00:03] <Tak> (not that I couldn't still be doing it wrong)
[00:04] <Tak> cool, so the api change was 2.1.0b1 - thanks
[00:04] <defn> hi everyone.  I am new to bzr and I have a question...  Basically I have this external "branch" which hooks into a larger repository externally -- i would like to do development on my branch locally and then "commit" only to my branch on the remote shell
[00:04] <defn> how does one go about "committing" to a branch
[00:04] <defn> if you have any suggestions for doing local development and then getting those changes under version control please let me know
[00:10] <jelmer> defn: I'm not sure I understand what you're trying to do
[00:11] <defn> jelmer: me either! :)
[00:11] <Tak> jelmer: btw, I'm seeing the filehandle leak on both sid and osx 10.6
[00:11] <jelmer> defn: you'd like to do a partial checkout of a remote repository basically?
[00:11] <jelmer> Tak: I'm not claiming it doesn't exist on lucid, just saying I haven't seen it yet :-)
[00:11] <jelmer> s/seen/noticed/
[00:11] <jelmer> 'morning Ian!
[00:11] <igc_> hi jelmer
[00:13]  * Tak nod
[00:23] <defn> jelmer: hmm, im just sort of confused on how my repo was setup initally -- let me do some digging for how it was created and then let me rephrase :)
[01:17] <poolie> hi
[01:17] <jelmer> moin poolie
[01:18] <poolie> hi there
[01:27] <igc_> hi poolie
[01:28] <poolie> hi
[01:33] <igc_> poolie: Windows installers built and uploaded for 2.0.5 and 2.1.1 over the weekend
[01:33] <poolie> yay
[01:34] <poolie> how hard/easy would it be to do a 64-bit windows build?
[01:34] <poolie> people have asked a few times
[01:35] <poolie> jelmer, igc_: i think my mail about plugin compatibility was too braindumpy; nobody replied yet
[01:36] <lifeless> poolie: I haven't seen it
[01:36] <poolie> but what would you two think about 1- having a blacklist in bzrlib to make it more symmetric
[01:36] <lifeless> but it sounds like something I'd have an opinion on
[01:36] <poolie> heh, it does, doesn't it :)
[01:36] <poolie> 2- making the failure less noisy
[01:37] <fullermd> I fear that sort of blacklist.  It's got a neon sign above it saying "Ask Me About Being Out Of Date"
[01:38] <lifeless> fullermd: depends how its phrased and populated
[01:38] <lifeless> fullermd: if it was 'plugin X < Ver-Y is bust' then its not stale daya
[01:38] <lifeless> < very-Y will stay bust
[01:38] <lifeless> s/day/data
[01:38] <poolie> right
[01:39] <poolie> it may be that we add the faciliity and don't make use of it
[01:39]  * fullermd confiscates lifeless's 'y' key for rampant misuse.
[01:39] <lifeless> poolie: I don't know how quiet you want to go. I think a broken plugin should be listed on every invocation of bzr.
[01:39] <poolie> we could put it only in 'bzr plugins'
[01:39] <lifeless> even though its noisy, its an aberrant situation.
[01:39] <lifeless> and crucially its not easily discoverable
[01:39] <poolie> we may just substitute wonders about why something broke though
[01:39] <poolie> right
[01:40] <poolie> so i think the main thing is to only be giving warnings if the plugin actually would not work
[01:40] <lifeless> hmm
[01:40] <lifeless> we could
[01:40] <poolie> ie eliminate both type I and II errors
[01:40] <lifeless> if exiting with non-zero (e.g. NotBranchError, NoSuchCommand etc)
[01:40] <lifeless> also show broken plugins
[01:40] <fullermd> That could get irritating in the case where the user can't do much about it though.
[01:41] <poolie> mm
[01:41] <lifeless> 'svn:///host/path is not a branch\nWarning: plugin bzr-svn failed to load. See ~/bzr.log for details.'
[01:41] <fullermd> They can wind up with nothing to do but set whatever that env var is to disable a plugin, which then becomes an eternally-encysted part of the env.
[01:41] <lifeless> fullermd: so, if they are running a non-installed bzr, they can set BZR_PLUGINS_PATH to control the plugins, without disabling just-one
[01:42] <fullermd> I was thinking more the case of running an _installed_ bzr, with installed b0rked plugins.
[01:42] <lifeless> fullermd: so, a sysadmin fail ?
[01:43] <fullermd> In a hard or soft sense, yes.
[01:43] <fullermd> I tried fixing such things, but I ran out of bullets   :)
[01:43] <lifeless> poolie: anyhow, I think both your 1 and 2 could be good
[01:43] <lifeless> though I haven't [yet] read the mail to know the context.
[01:44] <lifeless> fullermd's concern about staleness of data would be something to cater for in the blacklist design.
[01:56] <igc_> poolie: I'm yet to read it sorry
[01:57] <igc_> poolie: I scanned it and it had good ideas IIRC
[02:15] <igc_> poolie: no opinion on 64-bits builds currently
[02:28] <GungaDin> how can I merge just a couple of directories into a branch?
[02:29] <bob2> with difficulty
[02:30] <bob2> (assuming the changes are in changesets that altered other files)
[02:30] <bob2> you can merge + revert the bits you don't want (but then the other bits will never be merged)
[02:31] <lifeless> huh
[02:31] <lifeless> easy
[02:31] <lifeless> bzr emrge branch/dir1
[02:31] <lifeless> bzr merge --force branch/dir2
[02:31] <lifeless> bzr commit
[02:31] <lifeless> note though, that like *all* partial merges, it won't be recorded as a merge.
[02:34] <mbohun> what is the proper way to rename/move A.c to B.c and B.c to A.c ?
[02:35] <Peng> "bzr rename"?
[02:35] <fullermd> Use an intermediate name and 3-step it.
[02:35] <fullermd> Or use the `bzr xor` trick...    ;>
[02:35] <Peng> Oh. You can't do it in one step?
[02:36] <fullermd> How would you?
[02:36] <Peng> Err, sorry.
[02:36] <Peng> I was thinking, like, commit wise. Some VCSes don't let you do something like that in one revision.
[02:37] <mbohun> that's what i m wondering, though my example was a bit retarded in fact i have to version of the same html page: index.html and index2.html (index.html being the default) - now i want to swap them so index2.html is going to be the default index.html
[02:37] <fullermd> bzr mv index.html tmp ; bzr mv index2.html index.html ; bzr mv tmp index2.html
[02:38] <lifeless> Peng: one commit is fine.
[02:38] <fullermd> You can do it all in one rev, sure.  I've...  well, I've never done that, but I've moved a file and then created a new file with the old name a lot.
[02:38] <mbohun> fullermd: thanks
[02:39] <Guest87486> Hiya  an a Sunday nite! If I 'bzr branch aRepo', then 'bzr mv aRepo/someDir aRepo/newDir', does 'bzr merge aRepo' automagically put changes under version control in the original source's aRepo/someDir in the *renamed* aRepo/newDir?
[02:40] <lifeless> Guest87486: I don't know quite what you're asking.
[02:40] <lifeless> Guest87486: but I want to know that you can't branch a repo. Youc an only branch a branch.
[02:43] <Guest87486> lifeless: I'm just trying to understand if bzr is smart enuf to put changes originally meant for "aRepo/someDir" into the directory I renamed it as "aRepo/newDir".
[02:44] <lifeless> Guest87486: yes
[02:46]  * igc_ out for a few hours
[02:47] <lifeless> Guest87486: (yes, bzr is smart enough)
[02:48] <Guest87486> lifeless: I just started with version control in general, and bzr in particular.  pretrry amazing once you start to get the hang of it!  Thanks.
[02:58] <tommytb> hi, what is the submit branch shown in branch.conf?
[02:59] <fullermd> It's the default location used for certain operations (send and merge at least, I think)
[03:00] <tommytb> any way to move it back to trunk?  (i messed up my repository when trying out my first branching operation)
[03:01] <fullermd> Using something like `merge --remember` would reset it.  You could manually edit it in the branch.conf.
[03:03] <tommytb> branch.conf also has some of my commit messages in it
[03:03] <tommytb> what does merge --remember do?  i don't want to mess things up more
[03:03] <fullermd> It shouldn't....    oh, maybe qbzr's uncommit hook stashes them there.
[03:04] <fullermd> `merge --remember xyz` does pretty much the same thing as `merge xyz`, except that it stores xyz as the remembered location.
[03:04] <fullermd> Without --remember, it will only save it if there isn't already a saved one.
[03:10] <tommytb> the submit branch is set to a branch I manually deleted, which is causing me some errors.  I have nothing to merge
[03:10] <fullermd> What errors is it causing you?
[03:11] <fullermd> The stored location is just used as a default location for certain commands when you don't specify one explicitly.  Aside from that, it's pretty much cosmetic; it doesn't imply any lower-level link between the branches.
[03:11] <tommytb> when i open my trunk it says in bzr explorer "Not a branch: ~/project/trunk/branch1
[03:12] <fullermd> Mmm.  Explorer is off my turf.  That's igc_'s baliwick, but he's away right now.
[03:12] <fullermd> You could just manually delete the line wholesale from the branch.conf.
[03:13] <lifeless> right
[03:13] <lifeless> also please file a bug on bzr-explorer at bugs.launchpad.net/bzr-explorer
[03:15] <tommytb> deleting the submit branch=...  line from branch.conf seemed to work
[03:15] <tommytb> should i also delete the line below it that just says [commit data]?
[03:16] <tommytb> i have a question on launchpad bzr-explorer already
[03:16] <lifeless> about this?
[03:16] <tommytb> ya
[03:16] <fullermd> Probably not...   I assume those are saved uncommit messages or something.  Might as well leave 'em alone without a good reason to fiddle.
[03:32] <tommytb> ok, thx, i think its fixed
[03:33] <tommytb> does anyone know what the colored circles indicate in bzr explorer when viewing your log history? One of my branches is colored pink and one is colored sky blue.
[03:36] <fullermd> I think it uses some heuristic to guess which branch different revs came from, and colors them based on that.  I'm not sure it has any deeper meaning.
[05:01] <GungaDin> can bzr apply patches?
[05:02] <mwhudson> GungaDin: yes, bzr help patch i think
[05:02] <mwhudson> hm
[05:02] <GungaDin> thx
[05:02] <Peng> If you just have a plain diff, you can use the usual 'patch' command...
[05:02] <mwhudson> maybe that's from some plugin actually...
[07:27] <parthm> I am trying to run 'bzr log' with bzr from trunk. but thats failing with api not compatible error. version and st work and pull says there is nothing to pull http://pastebin.com/Hbgt3KRM
[07:28] <parthm> am i missing something?
[07:28] <vila> hi all ! (new DST here for those who care :)
[07:28] <vila> parthm: upgrade or disable your plugins until they update their checks against bzrlib API
[07:30] <parthm> vila: ah ok. so a plugin probably updated the log command. it works fine with --no-plugins. thanks.
[07:31] <vila> parthm: just loading the plugins (even without modifying log) can trigger that
[07:31] <parthm> vila: i should have thought of that earlier :)
[07:33] <davidstrauss> How can I change the path to Python that Bazaar uses?
[07:33] <lifeless> davidstrauss: an installed bzr ?
[07:33] <lifeless> davidstrauss: or running from source?
[07:34] <davidstrauss> lifeless: Either, preferably installed
[07:34] <davidstrauss> lifeless: I need to run Bazaar under Python 2.6 for bzr-svn support for one use.
[07:34] <davidstrauss> user*
[07:34] <lifeless> well
[07:35] <lifeless> you'll need to installed it under python 2.6
[07:35] <lifeless> unless you're using packages, which should have instaleld it under all versions
[07:35] <lifeless> the #! line at the top of /usr/bin/bzr controls the interpreter used to run bzr
[07:35] <lifeless> but you can also do 'python2.6 /usr/bin/bzr ....'
[07:38] <davidstrauss> lifeless: Running the "python2.6 /usr/bin/bzr" complains about not having bzrlib in the PYTHONPATH
[07:39] <lifeless> davidstrauss: then its not installed for python2.6
[07:40] <lifeless> davidstrauss: is it ubuntu packages that you've installed it with ?
[07:40] <lifeless> or something else?
[07:40] <davidstrauss> lifeless: This is with the Four Kitchens Yum repo packages for RHEL/CentOS
[07:41]  * Peng declares dealing with plugin API compatibility the most annoying thing ever.
[07:44]  * fullermd waves at vila.
[07:45] <davidstrauss> lifeless: I think I figured it out.
[07:45]  * vila waves back !
[07:47] <lifeless> davidstrauss: I don't know anything about CentOS python package sorry
[08:06] <poolie> lifeless: teddybear about apport
[08:06] <poolie> with my current fix for bug 528114 we can get ubuntu-bug sending the crash files to lp again
[08:06] <poolie> but there are two drawbacks
[08:07] <poolie> firstly they are filed against the ubuntu package when they're probably upstream bugs
[08:07] <poolie> secondly they are private by default, pending retracing
[08:07] <poolie> and there seems to be a long delay there
[08:08] <igc1> back
[08:08] <igc1> with a running system this time :-)
[08:14] <lifeless> poolie: hi
[08:14] <lifeless> poolie: uhm, some apport is better than no apport
[08:14] <poolie> yeah that was basically the question
[08:14] <lifeless> poolie: what caused the issue? Have you corresponded with pitti ?
[08:14] <poolie> previously; not today
[08:14] <poolie> i think i just need to fix a larger bug
[08:15] <lifeless> well yes, I know previously :)
[08:15] <lifeless> pitti is up , I saw him in another channel; might make sense to have a hallway chat with him about this now.
[09:56]  * igc1 dinner
[10:27] <writer> Hi everyone
[10:27] <writer> Is it okay to use bzr on a low-bandwidth connection ?
[10:28]  * writer is on a 512 Kbps connection, and getting 'bzr: ERROR: Connection error: while sending GET /ikarus.dev/.bzr/repository/indices/a2ff5c6db2537db1740e0e9ba5216e52.six: [Errno 4] Interrupted system call' with bzr 2.1.0-2 on Arch GNU/Linux
[10:29] <lifeless> thats not going to be your connection per se
[10:29] <lifeless> perhaps there is an intercepting proxy at your ISP or something
[10:30] <lifeless> bzr is usable with lower speed connections than yours
[10:30] <writer> lifeless: there is not any, AFAIK, and I'm getting download speeeds like 2KB/s, 1KB/s and then also get spikes like 67KB/s, 22KB/s
[10:40] <Peng> Wait a minute. "Interrupted system call"? As in EINTR?
[12:01] <Altreus> Hey, I accidentally forgot to specify files to commit. Can I un-commit?
[12:01] <Altreus> oh
[12:01] <Altreus> uncommit heh
[12:02] <Altreus> I didn't expect that to be there :o
[14:46] <igc1> night all
[16:40] <ronj> Hello. It's impossible for me to to even a simple bzr branch, I always get http://pastebin.com/mrm62Bd1 . However, 1. my public key is in ~/.ssh/launchpad_id_rsa.pub, 2. It matches what LP outputs when I click on  "SSH keys<EMAIL_ADDRESS>and 3. I tried removing it from LP and reimporting it. Help!
[16:41] <ronj> Using Ubuntu 9.10 x86 with bzr 2.0.2
[16:42] <ronj> And I forgot to mention: it used to work. I don't know what caused it no now fail
[16:59] <davertron> hi guys, i currently have a bzr branch that's pack-0.92 that i want to convert to rich-root-pack so i can pull; how can I do this?
[17:00] <jelmer> davertron: bzr upgrade --rich-root-pack
[17:00] <jelmer> davertron: or, alternatively -- 'bzr upgrade --2a' if you're on bzr >= 2.0
[17:00] <davertron> jelmer: is that a pretty safe avenue?
[17:00] <davertron> jelmer: should i worry about the possibility of a corrupted branch or anything like that?
[17:00] <jelmer> davertron: yeah, though I'd really recommend using 2a if you can - it's much faster
[17:01] <davertron> jelmer: looks like i'm using 1.13.1
[18:19] <bendj> For remote access, I know I can use bzr+ssh or sftp.  What's the _difference_ between the two?  When should I use which?  Does it matter?
[18:20] <LeoNerd> sftp uses a dumb filesystem on the other end; namely the SFTP server
[18:20] <LeoNerd> bzr+ssh shells in to the remote server, runs bzr, and uses it as a smart agent
[18:20] <bendj> LeoNerd: so bzr+ssh is a better opt, it seems
[18:20] <LeoNerd> bzr+ssh costs more in terms of resources on the server, but the smart agent can help reduce network usage or roundtrips
[18:21] <LeoNerd> Can be. Depends on your setup
[18:21] <LeoNerd> between my desktop and my server I use sftp, because my server is a celeron 333 with 784MiB of RAM accessible over a 100Mbit LAN with <1msec of latency.
[18:21] <LeoNerd> sftp is finished well before that celery has even fork()+exec()'ed a python process.
[18:24] <bendj> LeoNerd: Thanks for the explain!
[18:34] <IslandUsurper> does anybody know if horizontal scrolling with the mouse wheel doesn't work in qbzr because of qbzr or Qt itself?
[18:37] <IslandUsurper> I'm using a touchpad, but I know that's not the problem because Chrome and Firefox scroll horizontally when I use it
[18:43] <luks> IslandUsurper: where in qbzr?
[18:43] <luks> it works for me in qdiff
[18:43] <luks> (using a touchpad)
[18:44] <luks> also works in qlog
[18:49] <IslandUsurper> luks, well, I was looking at qdiff
[18:49] <IslandUsurper> However, I'm using Windows
[18:55] <luks> ah, can't test on windows right now
[18:56] <IslandUsurper> when I get home, I guess I can test it on Linux
[19:09] <maxb> Hi, I've just found a crash in qbzr owing to lazy-importing bzrlib.revision.NULL_REVISION. Is lazy-importing a constant ever the right thing to do?
[19:19] <salgado> vila, around?  can you have a peek at https://answers.edge.launchpad.net/launchpad/+question/105604?
[19:19] <salgado> (I just ran 'bzr get lp:vm' and it worked just fine)
[20:28] <mwhudson> jam: does that loggerhead merge proposal have any particular bzr version requirements?
[20:34] <GaLiLe0> we are looking for a version control system for our developers to install on their machines. Some dev work is done directly on a web server though. can Bazaar integrate directly to keep a backup of files on a remote web server?
[20:45] <beuno> GaLiLe0, you have a plugin called "bzr-upload" which will just upload the working tree
[20:47] <GaryvdM> Hi all.
[20:47] <jelmer> hey Gary
[20:47]  * GaryvdM came to find bailix
[20:47] <GaryvdM> Hi Jelmer
[20:48] <GaryvdM> \o/ Built qbzr inno installer under wine :-)
[20:49] <GaryvdM> Bye - rebooting to test in windows....
[21:04] <beuno> jam, ping
[21:08] <thumper> jelmer: we have some fun problems with bzr-git
[21:08] <thumper> jelmer: in particular the size of the cache for the incremental kernel import
[21:13] <jam> hi beuno
[21:13] <jam> mwhudson: I'm sure it does, I don't know it offhand, probably bzr 2.1?
[21:13] <jam> maxb: it would be reasonable to lazy-import the module
[21:14] <beuno> jam, 1) You rock! Thank you for the loggerhead branch.  2) Is it compatible with previous bzr'z?
[21:14] <jam> but yeah, the constant is bad
[21:14] <jam> beuno: prob bzr 2.1
[21:14] <beuno> ah, mwhudson already asked that  :)
[21:14] <jam> beuno: actually, I see "KnownGraph" in one of my bzr 2.0 branches, let me look closer
[21:15] <jam> KnownGraph was introduced in bzr 1.18
[21:15] <mwhudson> sounds ok to me then
[21:15] <beuno> me too
[21:15] <mwhudson> ps: does someone want to maintain loggerhead instead of me?
[21:15] <jam> however, KnownGraph.get_parent_keys is in 2.1, but not 2.0
[21:16] <mwhudson> i don't feel like i've been doing a very good job lately
[21:16] <mwhudson> jam: ah
[21:17] <beuno> I vote for Peng
[21:17] <jam> let me see if there is a way to work around it in an obvious manner
[21:18] <jam> mwhudson: both the C and python versions expose self._nodes which is the internal graph
[21:18] <GaryvdM> jam: I've bumped qbzr min required bzrlib version due to that.
[21:19] <jam> however, the objects in there aren't identical wrt the C vs python versions
[21:19] <jam> so it isn't great to grab that
[21:19] <jam> I could certainly write (ugly) code that would work under all versions
[21:19] <jam> if 2.0 compatibility is important
[21:20] <jam> (pure python stores a reference-by-key , Pyrex stores a reference-to-the-node)
[21:21] <beuno> jam, I think we can just say that the next release of LH only works with 2.1
[21:21] <beuno> and it's twice as fast  :)
[21:22] <jam> well, this isn't the history cache loading, just the generation without-cache step
[21:22] <jam> I'm toying with ideas about how to handle a graph data store that isn't "1 rev-at-time" while also not being "all revs, all the time"
[21:22] <jam> I plan on writing something up for the list
[21:23] <beuno> I think the first hit is usually what gives people the impression it's slow
[21:23] <jam> though honestly, the loggerhead code doesn't really need to be calling "self._load_whole_history_data()" all the time
[21:23] <jam> which could help a lot
[21:23] <jam> The main page doesn't seem like it uses most of that data
[21:23] <mwhudson> jam: i think hazmat has been working on that
[21:24] <jam> mwhudson: assuming that is the same Kapil that was posting to canonical-tech, that is actually what inspired me to look into this code
[21:25] <hazmat> jam, mwhudson i just removed it from a views that where obvious, i'm not  going to be actively pushing it, my knowledge of bzr internals is pretty rudimentary
[21:25] <jam> however, his discussion was "use chameleon, disable all the stuff that seems to be O(history)"
[21:25] <hazmat> jam, thanks for having a look at that
[21:25] <jam> vs, how keep the info, without having to load the *entire* history
[21:25] <hazmat> i checked out your branch, it does seem to better on the cache computation
[21:26] <hazmat> but yeah.. that's an accurate summary :-)
[21:26] <jam> mwhudson: so, other than pushing data into production, and letting people bang on it, what sort of testing does loggerhead have?
[21:26] <jam> specifically, if I just started hacking in 'history.py' to make it not load the whole graph
[21:26] <mwhudson> jam: yeah, that's about it
[21:26] <jam> how would I find out where the gotchas are
[21:26] <mwhudson> jam: i don't know
[21:27] <jam> code-inspection it is, I guess
[21:27] <mwhudson> the code makes me very sad in general
[21:27] <jam> btw, there is one other part of my patch I didn't mention, which is the "try: import loggerhead.app.branch" stuff
[21:27] <mwhudson> there's not actually that much code at least
[21:27] <jam> for some reason on my machine, "try: import loggerhead" succeeds
[21:27] <jam> but "try: import loggerhead.apps.branch" fails
[21:27] <mwhudson> oh yes
[21:27] <mwhudson> that end of things is all screwed up too :/
[21:28] <jelmer> thumper: Hi
[21:28] <thumper> jelmer: on a call right now, with you shortly
[21:29] <jam> anyway, with that patch "bzr serve --http" works for me, so I'm happy enough with it :)
[21:29] <jelmer> thumper: If it's a stand-up, mwhudson knows about it :-)
[21:30] <jam> mwhudson: what is "cache_key", it seems to be BranchWSGIApp.friendly_name, but that still doesn't help much
[21:30] <jam> is it ~ the path on disk?
[21:32] <jam> and, IIRC, the mapping in the sql data structure is "branch_tip_revision => revision_graph_of_whole_ancestry" right?
[21:32] <jam> (so the data currently stored cannot be parsed in anything less than all history)
[21:34] <mwhudson> jam: it's supposed to identify the branch
[21:34] <jam> mwhudson: in theory this could also be applied to your valid concern about the branch => ancestry table
[21:34] <jam> since that is O(branches*ancestry)
[21:36] <poolie> jam, hi?
[21:36] <jam> hi poolie
[21:36] <poolie> shall we talk?
[21:36] <jam> are you off DST yet?
[21:36] <poolie> not yet, next weekend
[21:36] <poolie> so it's 7:30 here
[21:36] <jam> poolie: I have nothing to say to you :)
[21:36] <jam> sure
[21:37] <jam> poolie: how about skype?
[21:37] <poolie> sure
[21:37] <thumper> vila: thanks for jumping in on that question
[21:38] <vila> thumper: I'm ill, so don't hope too much either :-/ I just woke up after falling alseep instead of dining (to give you some idea ;-)
[21:39] <jam> poolie: I logged in, but I don't see you on skype yet
[21:39] <poolie> likewise
[21:39] <thumper> vila: sorry you're feeling crap, get well soon
[21:41] <vila> thumper: no worries, I'm rarely ill and it rarely last long :) (crossing fingers, killing some chicken, etc)
[21:47] <maxb> I love qbzr. Not only is it an amazing tool, but I'm repeatedly astonished by how fast bugs are turned around. <4 hours filed->fixed in this case :-)
[21:52] <GaryvdM> maxb: I was doing the release, and it was a easy thing to fix.
[21:53] <GaryvdM> maxb: Thanks for the bug report.
[21:54] <maxb> You deserve the praise - this isn't the first time I've had a bug turnaround measured in hours :-)
[21:54] <GaryvdM> maxb: However, we do have our share of old bugs, and open bug seems to grow all the time :-~
[21:55] <maxb> So do all projects, I fear
[21:55] <lifeless> moin
[21:56] <GaryvdM> moin lifeless
[22:12] <poolie> can someone review my apport mp?
[22:17] <GaryvdM> jelmer: If I want to add an entry to debian/changelog, but I am not going to be uploading, should I just exclude the -- Gary... line?
[22:24] <jelmer> GaryvdM: Just include it - whoever will actually do the upload will change it to their name
[22:25] <GaryvdM> jelmer: Ok thanks
[23:07] <Boingo> Hello everyone.  I am still a bit new to bzr and trying to get my head wrapped around how I should best use it.  In my case, I have a distributed team work on a base project (PHP website).  Most of the work goes into the base product.  But, from time to time, we need to branch and create specific version for a client.  Most of the changes are cosmetic, CSS, images, etc.  Some are code changes.  Either way, we would like to be able to track the changes in th
[23:11] <timClicks> is there an equivalent to bazaar explorer for Gtk+?
[23:13] <GaryvdM> timClicks: olive, which is a part of bzr-gtk
[23:13] <timClicks> GaryvdM: ty
[23:15] <GaryvdM> timClicks: You can also configure bzr explorer to use the bzr-gtk dialogs, but it will still require that you have qt installed (which i guess is what you don't want)
[23:16] <timClicks> well, I'm fine mixing and matching but used a Windows machine for checking out some code yesterday
[23:16] <timClicks> and was really impressed by Bazaar Explorer
[23:16] <timClicks> and wanted to have something that easy for my Ubuntu machine
[23:17] <GaryvdM> timClicks: bzr explorer/qbzr will honner your gnome styles, if thats whats important
[23:18] <GaryvdM> timClicks: see http://doc.bazaar.canonical.com/explorer/en/visual-tour-gnome.html
[23:24]  * timClicks didn't realise that bazaar explorer was available for GNOME
[23:30] <GaryvdM> timClicks: bzr explorer is built with qt. (qt!=kde)
[23:30]  * timClicks nods
[23:30] <timClicks> understood
[23:31] <timClicks>  I actually thought it was a native MS Windows app
[23:31] <GaryvdM> Oh
[23:31] <timClicks> things make much more sense now
[23:38] <jrib> Hi, how does one start bazaar explorer in OS X?  I installed the desktop bundle and qt libraries (things like bzr qinit work ok from a terminal)
[23:39] <GaryvdM> jrib: run bzr explorer
[23:40] <GaryvdM> jrib: there is allready a bug for adding a application shortcut
[23:41] <jrib> GaryvdM: hmm, I'm getting "bzr: ERROR: unkown command "explorer"".  I installed 2.0.1 + desktop bundle
[23:43] <GaryvdM> jrib: thats odd. Do you see explorer under bzr plugins ?
[23:43] <jrib> GaryvdM: bzr plugins | grep -i explore    returns nothing
[23:45] <jrib> GaryvdM: it is possible that I installed bzr some other way and now installed the bundle on top of it (I don't use OS X and am just trying to get some simple instructions down for a colleague).  bzr currently points to /usr/local/bin/bzr
[23:45] <GaryvdM> jrib: sorry - I don't own a mac. Not sure
[23:46] <jrib> GaryvdM: ok, thank you.  In any case, it's clear now that if I did have explorer installed it should be listed under bzr plugins, right?
[23:46] <GaryvdM> jrib: yes
[23:47] <GaryvdM> jrib: If you have pyqt installed, then you should be able to just put bzr-explorer in the plugins dir
[23:47] <GaryvdM> Not sure where that would be though
[23:52] <jrib> GaryvdM: thanks, copying it to the plugins folder was sufficient.  Now I have to redo it without using a terminal to explain it to my friend :)
[23:53] <GaryvdM> jrib: Not sure why + desktop bundle did not work for you.
[23:54] <GaryvdM> I ran it on a family members mac once, an it worked for me