[00:00] barry: Hit the edit icon next to 'duplicate of ...' [00:01] StevenK: oh, *and* delete the bug number then hit the check box. :) but thanks! [00:01] barry: Well, yeah, but I thought once I got you over the hurdle of *finding* the link, you could figure out the rest. :-) [00:02] StevenK: i put my 10,000 monkey-clone army on it and they shakespeare'd it in 300ms [00:10] slangasek: is there a bug open for the targoniness of booting 64-bit kernels on a 32-bit CPU? [00:11] slangasek: afaict, the kernel itself just enters a hlt loop and doesn't display _anything_. [00:11] kees: bug #983825? [00:11] Launchpad bug 983825 in gfxboot-theme-ubuntu (Ubuntu) "Present helpful message when booting 64-bit medium on 32-bit machine" [Medium,Triaged] https://launchpad.net/bugs/983825 [00:11] perfecto [05:02] Good morning [05:09] pitti: morgen! === Whoopie_ is now known as Whoopie === tkamppeter_ is now known as tkamppeter [06:49] good morning === smb` is now known as smb === kenws_ is now known as kenws === ritz is now known as ritz|nomNomNom [09:49] ahasenack: having any luck with the patched unity-2d i told you? Too soon to declare victory maybe? [09:49] tsdgeos: yeah, too soon [09:49] oki :-) === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [11:52] ev, hey, just curious but is there somewhere where we can get news about the status of your work on whoopsie, the db, etc? [11:53] seb128: actually, let me forward you an email I sent about it to my team soliciting input [11:53] would be excellent to hear your thoughts [11:53] ev, thanks ;-) === _salem is now known as salem_ === greyback is now known as greyback|lunch === doko_ is now known as doko [12:29] jibel: about 983981, is this pure lucid, or lucid-updates? [12:32] bug 983981 [12:32] Launchpad bug 983981 in update-manager (Ubuntu) "Lucid -> Precise main failed to upgrade: ERROR: pycompile:Requested versions are not installed dpkg: error processing python2.7-minimal installed post-installation script returned error exit status 3" [High,New] https://launchpad.net/bugs/983981 [12:32] lucid updates [12:32] doko, ^ [12:35] jibel, but not for any update, correct? [12:42] doko, correct. Only the test referenced in the report fails. [12:43] jibel, are the tarballs for the chroots available somewhere? === greyback|lunch is now known as greyback [13:00] Mirv: new ddtp stuff uploaded [13:29] RAOF, heyo. Got a moment to talk about X and keyboard layouts? [13:30] I'll say yes. [13:30] RAOF, I'm seeing "key types not defined" when trying to have xkbfile X extension use the "fr oss" layout [13:30] What does it mean for a map to not have it's key types defined? [13:30] RAOF, (this is bug 960096) [13:30] Launchpad bug 960096 in ubiquity (Ubuntu) "Live session started with wrong layout" [High,Triaged] https://launchpad.net/bugs/960096 [13:30] Hm. I don't know at the moment. Let me check [13:31] but if you do look at the bug, look only at the last few comments. Several flaws have been glommed into the same bug report [13:31] I'm working on the most recent one [13:33] should i not get a "Waiting for Approval" mail for something i uploaded to oneiric-proposed? [13:33] dobey: yes, you should [13:34] hrmm, i haven't gotten one, and i uploaded it last night [13:35] ubuntuone-storage-protocol_2.0.1-0ubuntu1_source.changes [13:37] dobey: it's not in unapproved for oneiric so it probably got lost somewhere [13:37] bdmurray: iso tracker updated published, bug search should be working fine now with duplicates [13:37] stgraber: should i just rm the .upload file and try again? [13:39] dobey: yep [13:39] ok [13:40] says successfully uploaded again. hopefully it worked this time === dholbach_ is now known as dholbach [13:42] Oh, wow. [13:42] mterry: The XKB protocol is quite impressive [13:43] RAOF, in a good way? :) [13:43] In a bloodymindedly baroque way. [13:44] Also, it supports keys in radio groups for some reason. [13:45] On the off-chance you'd like to map your keyboard such that exactly one of 'a', 'b' or 'c' is considered to be pressed at any one time. [13:46] The protocol specification is also a light-weight 107 page PDF, plus appendicies. [13:47] * RAOF has thus far managed to avoid looking too closely at the direction of XKB in the hope that it'd go away if he didn't make eye contact. [13:47] mvo: I just noticed Bug #984906. If you end up doing another update-manager upload, I would appreciate it if you could include the fix for it as well. [13:47] Launchpad bug 984906 in update-manager (Ubuntu) "update-manager-kde short description wrong" [Low,New] https://launchpad.net/bugs/984906 [13:50] mterry: I'll take a longer gander at it tomorrow; 10pm beckons. [13:50] RAOF, OK. thanks! [13:50] mvo: ok, great! Debian itself has had apparently problems that the translations haven't been uploaded for some while, but at least now it should be up-to-date what Debian has on its servers [13:52] apparently some unicode problem was just now found [14:01] ScottK, do you know why pycompile in lucid still has DEFAULT_VERSION = (2, 5) ? [14:01] No. [14:06] mvo: Very quick (with the commit for the bug fix). Thanks. [14:07] ScottK: sure, that was a tiny one, thanks for the report and the irc ping [14:07] Should help the production metrics for the week.... === carif_ is now known as carif [14:35] hi guys..... just made a package for a software of ours [14:35] http://paste.kde.org/459398/ [14:35] so basically are these warnings safe to ignore? [14:35] especially the ones regarding cannot find lib needed for [14:36] (basically vsxu_artiste, vsxu_player, vsxu_server are all dependant on libvsxu , and i ve specified that in the control file) [14:47] stgraber: ugh. it's telling me the signer doesn't have upload rights now. i guess something got mucked up when we made the packageset for precise for u1 stuff, and now i can't upload to the older ubuntus? [14:48] dobey: that could be, ppu are for all releases but package sets are per release [14:48] dobey: as we created the ubuntuone packaget set in precise, you probably lost your upload rights to older releases in the process [14:49] stgraber: ugh. any way to fix it? or will i have to just do merge proposals now for all the packages in older ubuntus? [14:52] dobey: launchpad doesn't let me create a copy of the package set in oneiric apparently ... [14:53] hmm [14:53] dobey: I can do a temporary hack to let that one in though, what's the source package name? [14:54] stgraber: well i have a few more packages to do as well, and was expecting to have to do a proposal for at least one. i guess i'll just do it for all. i guess this also explains why my bug nominations weren't automatically approving on a couple packages for the older ubuntus as well [14:54] stgraber: hrm, why can't you create it? [14:55] stgraber@castiana:~/data/code/ubuntu-archive-tools$ python edit_acl.py create -P ubuntuone -S oneiric -p developer-membership-board [14:55] stgraber: and i'll have to do similar SRUs for natty and probably lucid soon as well, so don't want to keep wasting time with temporary hacks [14:55] Package set ubuntuone already exists [14:55] stgraber@castiana:~/data/code/ubuntu-archive-tools$ python edit_acl.py add -P ubuntuone -S oneiric -p ubuntu-ubuntuone-dev [14:55] There was a 404 error: [14:55] No such package set (in the specified distro series): 'ubuntuone'. [14:55] Laney: ^ [14:55] sounds buggy [14:55] edit_acl.py create IIRC [14:55] oh, /me reads again [14:55] that was in his first paste [14:55] odd [14:55] I guess you could namespace it as a workaroudn [14:56] I probably could but then we might end up with both in Q as LP seems to do some weird things when creating a new series... [14:56] I recall bugs around initialising packagesets [14:57] check with #lp? [14:57] well, I have a couple of "critical" bugs opened for a few months regarding the packageset table being a bit of a mess [14:58] I would guess/hope that it only uses sets in n to initialise n+1, but … [15:00] it doesn't ;) [15:00] that's what caused most of our existing bugs [15:01] micahg: Would you or some other mozillateamish person please look at esteid-browser-plugin in the New queue and see if it's now something that's supportable from your POV? [15:01] all I can suggest is that you seek counsel from a Launchpad developer about the best way to proceed [15:01] I've been meaning to fix that initialisation bug [15:02] it should be easy [15:02] did you at least make sure that the data in P is clean? [15:02] for ubuntuone, it should be, it's a new package set [15:02] there's some duplication [15:02] I can't remember the details [15:02] for some of the other packagesets, no, we have a ton of duplicates [15:03] I meant for all package sets - I knew it was broken but I haven't had a chance to go through and sanitise it [15:03] we should probably try to clean that up before we open Q [15:03] I got a few fixed by the Launchpad guys, then they filed another bug to get that table cleaned up and nothing happened since [15:03] yeah, fixing the init code and cleaning up the current mess before Q would be good [15:03] can't we clean it up by hand? [15:04] not with edit_acl [15:04] how come? [15:04] the API does checks that the DB doesn't ;) [15:04] bah [15:04] but I suspect that cleaning things up requires manual attention [15:05] cjwatson: bug 887185 [15:05] Launchpad bug 887185 in Launchpad itself "ArchivePermission allows duplicated rows" [Critical,Triaged] https://launchpad.net/bugs/887185 [15:05] cjwatson: and the initial question: https://answers.launchpad.net/launchpad/+question/177449 [15:05] so when trying to fix from the API, I get "NotOneError" so only someone with direct DB access can fix it [15:06] we could relax that for removal [15:06] that would probably be better than db hackery [15:06] that'd work, then we can cleanup the current mess with edit_acl [15:06] I have to do RC stuff first though [15:07] but I think I can look at this [15:07] ah, the packageset creation part is an edit_acl bug, I'll fix that one [15:07] it checks for existing packageset but without giving a distroseries [15:08] ok [15:08] makes sense given what I was doing when I wrote that [15:16] dobey: fixed for oneiric [15:17] stgraber: thanks [15:17] nice [15:18] stgraber: can we get it fixed for natty and lucid as well? [15:18] dobey: are you uploading to these two today? [15:19] it takes me time to create the new packageset as I need to do it by hand depending on what packages were there (no magic copy function), so I'm happy to do it but won't spend the extra time until it's needed ;) [15:19] stgraber: probably not today no [15:20] implement the copy function :P [15:22] Laney: almost tempted to do it, then ask LP not to do any copying when creating a new series and just use edit_acl for it ;) [15:22] heh [15:22] I was thinking that it would be useful when we create new sets in future [15:22] cjwatson: actually, would that be easier? ^ :) [15:23] I think I can implement a new "copy" function to edit_acl that takes a packageset and two series and just re-create it [15:23] hm, not sure, the init stuff was partly for derived distributions and I don't know what they wanted here [15:23] I think it would be *quicker* to fix the bug at hand and then consider such a redesign afterwards [15:30] ok. well i'll ping again when i need to upload to natty and lucid. thanks again stgraber! [15:32] dobey: np [15:52] [160199.816023] [Hardware Error]: Machine check events logged [15:52] ruh roh [15:54] dobey: natty and lucid done (I added a copy function quickly ;)) === zyga is now known as zyga-food [16:05] cjwatson: I just filed a merge proposal for that do_create distroseries fix and to add a basic do_copy === Quintasan_ is now known as Quintasan [16:26] * slangasek hugs didrocks for his gnome session [16:26] * didrocks hugs slangasek back :) [16:27] Not sure you saw the discussion but it was hot ;) [16:27] didrocks: the one on #ubuntu-release, I saw :) [16:27] yeah ;) [16:27] I missed it again :( [16:29] tsdgeos: no backtraces yet, looking promising [16:29] tsdgeos: but no logging either, so that code wasn't triggered [16:29] wow.. I went like, a whole week without a dist-upgrade and now I have 600 packages to update. [16:30] andreas__: ok, so the code didn't really do anything useful [16:30] * SpamapS probably should uninstall some packages :-P [16:31] ahh.. the gnome 3.4.1 bump is the source of most of it :-P === andreas__ is now known as ahasenack [16:51] need an opinion on bug 981130 .. [16:51] Launchpad bug 981130 in ceph (Ubuntu Precise) "python-ceph Depends on librgw1, which is no longer built" [Undecided,New] https://launchpad.net/bugs/981130 [16:51] its a small python library. [16:51] with three modules.. [16:51] only one of them needs librgw1 [16:52] should we just not install the module that needs rgw1 .. or just drop the dep on librgw1 and ship a module that won't work? [16:56] stgraber: cool. thanks much! [17:02] SpamapS: I vote for only shipping working stuff. [17:02] seb128, why did you reassign 960967 to libjpeg8? [17:03] doko, I though it was the lib jtransform_execute_transform() and providing do_rot_270() [17:03] doko, where the segfault happens [17:04] doko, I guess I was wrong, where should it go? [17:04] doko: sorry I have probably missed your reply to the argparse issue, will it still be fixed? [17:05] jtaylor, it is fixed [17:05] seb128, libjpeg is built from jpeg-turbo [17:05] doko: oh I don't have -proposed enabled yet, thanks [17:05] doko, oh ok, I was unsure, I picked the wrong one [17:05] doko, I'm fixing it [17:06] too many libjpeg* ;-) [17:07] seb128, and it appears to be a duplicate [17:07] ScottK: me too.. discussing w/ upstream what the best course is [17:07] OK. [17:08] doko, could well be, I didn't check for duplicates [17:08] doko, it has a picture example included though which might be useful [17:10] ScottK: at this point, chrisccoulson needs to review esteid-browser-plugin [17:10] micahg: OK. Thanks. chrisccoulson? [17:10] (it's in new again in case you missed it) [17:17] Hi all! === Nafallo_ is now known as Nafallo [17:22] pitti: what do you think of bug #937249? [17:22] Launchpad bug 937249 in apport (Ubuntu) "apport-gtk crashed with SIGSEGV in composite_line()" [High,Confirmed] https://launchpad.net/bugs/937249 === zyga-food is now known as zyga-afk === deryck is now known as deryck[lunch] [18:13] apachelogger: here? [18:19] hmm... any ubuntu packagers here? [18:20] saidinesh5: well, it's a channel for ubuntu developers so it's a possibility that some ubuntu packages sit here ;) [18:20] saidinesh5: it's better to ask the actual question [18:21] heheh .. well basically ..... i just created a debian/* stuff for a project that i m involved with [18:21] so basically it is split up into (libvsxu , libvsxu-dev , vsxu-artiste, vsxu-player,....) [18:22] (everything depends on libvsxu) [18:22] so 1) should i have to include the lib/*.so in the libvsxu-dev.install also ? [18:23] or just making it depend on libvsxu is enough? [18:30] ? [18:41] saidinesh5: typically *.so.* should go in the runtime packages and *.so should go in the -dev packages [18:41] *.so being symlinks to *.so.* in any sane upstream package [18:45] cjwatson: you mean *.so.* is like *.so.version? === deryck[lunch] is now known as deryck [19:06] saidinesh5: that's what I mean, yes [19:07] * saidinesh5 should probably edit some CMakeFiles for this now [19:07] cjwatson: could you also take a look at the ppa i ve created and the recipie i m trying to make? [19:12] cjwatson: CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE): [19:12] Could NOT find OpenGL (missing: OPENGL_gl_LIBRARY) [19:13] slangasek, cjwatson: re bug 924079. i've read the bug and cjwatson's post (which seems to have no follow ups?). what needs to be done here? are you looking for someone to verify that if the patches were sru'd that it solves the problem? there still seems to be the issue of abi breakage though, right? [19:13] Launchpad bug 924079 in apt (Ubuntu Oneiric) "do-release-upgrade fails to upgrade from Oneiric to Precise" [High,Triaged] https://launchpad.net/bugs/924079 [19:13] what should i include so that that builds? [19:13] barry: cjwatson's suggestion today was that this might be better done as a release-upgrader-specific backport, like we did for lucid [19:14] barry: I don't know if that's a better answer than trying to SRU patches to apt; mvo's your expert :) [19:14] slangasek: yeah, sorry mumble was so problematic today ;) [19:15] :) [19:17] slangasek: i'll look into it and make sure to follow up with mvo in the morning (he appears to be off-line right now) [19:17] barry: ack [19:20] but libgl and stuff should be installed because of libglfw-dev ...shouldnt they? [19:22] saidinesh5: sorry, I'm not going to have time to look at your package (especially if it's cmake, which I don't speak at all) - just offering general advice [19:22] cjwatson: ah its okay.. basically i m just a little confused about the package dependancy... [19:23] barry: I vaguely remember that mvo put together a non-ABI-breaking patch for that, too, but I don't have a record of it, so perhaps chase that up [19:23] barry: it may ultimately need to be an SRU to apt - I'm just worried about timing, mostly [19:23] like it says it cant find OpenGL libs. but libglfw-dev should pull libgl and friends ...... isnt it? [19:24] saidinesh5: my first guess would be that the upstream build system is buggy and can't cope with libraries installed in multiarch locations (e.g. /usr/lib/x86_64-linux-gnu/), but it may not be that [19:24] you'll need to look into whatever logs it gives you (if any) in detail [19:25] cjwatson: ack [19:25] * saidinesh5 checks [19:26] libxrandr2 (>= 2:1.3.0-3), libc6 (>= 2.1.3), libgcc1 (>= 1:4.1.1), libglfw2 (>= 2.6), libpng12-0 (>= 1.2.0), libjpeg8 (>= 6b1-1), libglew1.6 (>=1.6.0) [19:26] bleh [19:26] they should have been -dev libs [19:27] are those Depends or Build-Depends? [19:28] i put them as Build-Depends [19:28] right, that would be wrong [19:28] also micromanaging :) you don't need to build-dep on the C library ... [19:29] Ahh ya... [19:29] in most cases you probably shouldn't version the build-deps either, unless you know you require API (not ABI) added in that version [19:29] note that runtime depends don't necessarily correspond to sensible minimum versions on build-depends [19:31] Ahh cool that answers my next questioN! :D [19:33] cjwatson: if i include libglfw-dev will that install the needed headers for libglfw? (like libgl1-mesa-dev etc..) ? [19:34] (like libglfw depends on libgl) [19:51] doko, same error on upgrade with DEFAULT_VERSION = (2, 6) I collected a bit more informations with debug enabled. I'll update the report. === xnox_ is now known as xnox [20:15] saidinesh5: don't know offhand, look at its dependencies and that should say [20:15] hmm.... looking into it cjwatson :) [20:37] bryceh: I don't suppose bug #966868 resembles the X-racing-drm bug of yours? [20:37] Error: Launchpad bug 966868 could not be found [20:37] oh hush [20:41] slangasek, hmm, looking [20:44] someone needs a name for when you're investigating one bug and notice three other unrelated bugs along the way... [20:45] bryceh: normal debugging? [20:45] bryceh: yak shaving? :) [20:46] there we go [20:47] slangasek, anyway, yeah it seems to be crashing trying to open the intel device driver. could be same bug [20:47] er, same issue [20:47] ok [20:49] slangasek, i915 got initialized around 6.4-6.5 sec; if you can tell when plymouth was firing you can see if it was before or after that. that'd be more definitive [20:52] bryceh: yeah, I don't have timestamps for that by default [20:52] slangasek, adding plymouth:debug might make some timestamps show up. (sudo xdiagnose, first option) [20:52] yep [20:52] actually, no, even then we don't get timestamps [20:58] slangasek, #4 in that stack looks like libdrm code [20:59] dunno if its the same libdrm code as that other intel bug though. [21:12] slangasek, posted comment on the bug. I think escalating to Intel would be the logical next action. === salem_ is now known as _salem [21:12] bryceh: if the raciness is due to an Ubuntu sauce patch? (or is that now upstreamed?) [21:15] slangasek, I think so. They actually do care about ensuring their stuff works with Ubuntu. === highvolt1ge is now known as highvoltage [21:16] ok [21:16] slangasek, if nothing else they may be able to give advice [21:16] what's the escalation path? do we need apw looped in? [21:17] I usually escalate and then bring apw in once I get some feedback from upstream [21:17] ok [21:17] I'm happy to be part of the conversation if it helps [21:18] slangasek, I'd expect so [21:24] slangasek, fwiw I do think that we'll get a flame back telling us not to run the kernel i915 this way. but we'll see. [21:24] :) [21:26] slangasek, you'll need to manually sub yourself to https://bugs.freedesktop.org//show_bug.cgi?id=48894 because bugzilla sucks [21:26] Freedesktop bug 48894 in Driver/intel "plymouthd crashed with SIGABRT in __assert_fail_base()" [Major,New: ] [21:27] * slangasek searches for the 'subscribe' button because bugzilla sucks [21:28] put your email addy in cc [21:28] you might have to register first [21:28] nah, am registered, just couldn't remember the next step :) [21:29] bryceh: how much do you know about the kernel events that we get for drm devices [21:29] ? [21:48] slangasek, not much, I generally don't play at that level too often [21:49] slangasek, past experiences tinkering in libdrm has left me with a general dread of this part of the stack [21:49] Ugh, I never know where to ask this [21:49] UDD ... [21:49] bryceh: ;) [21:49] what do I do when merge-upstream decides to rename .. everything [21:49] SpamapS, turn to drink? [21:49] SpamapS: dput and let the importer sort it out. [21:50] ScottK: I have staged changes. :-/ [21:50] so my only recourse is to apply those manually w/ patch [21:50] which is what I've done [21:50] but.. that *sucks* [21:50] bryceh: so the "Best" fix is still to just have a reliable event that the upstart jobs can key off of... I'm wondering if there actually is a different event already that meets this need, or if not, how we should fix it so there is [21:50] What's more important: The history or the brain cells lost figuring out the right UDD way to do it? [21:50] SpamapS: what branch, what command? [21:51] slangasek: lp:ubuntu/juju [21:51] slangasek: have tried both from a tarball and from the upstream branch.. [21:51] it decised that the directory 'juju' is in conflict [21:51] heh [21:51] which would be.. the entire program :-P [21:52] that suggests past branch divergence [21:52] Possibly [21:52] what's the command I should run to try to reproduce this? [21:52] slangasek: bzr merge-upstream lp:juju [21:53] hmm, revision 1.1.11 doesn't help... imported an upstream tarball without merging the branch [21:53] SpamapS: is there also a tarball to merge at the same time? [21:53] the "proper" answer is to merge both, not either/or [21:53] slangasek, yeah an event seems like a better solution. the suggestion yesterday to hack a sleep loop into libdrm hasn't been sitting well with me. [21:53] slangasek: bzr export from the juju trunk to a tarball produces the same result, because thats basically what merge-upstream does anyway [21:54] SpamapS: so there isn't a pre-existing tarball? [21:54] are you *creating* one as part of this upload? [21:54] bryceh, do i need to take that patch to upstream on the morrow and see waht they make of it? perhaps they'll have some better ideas [21:54] slangasek: yes [21:54] slangasek: 0.5+bzr531 has never been uploaded [21:54] SpamapS: ok, so you should do the bzr export first to get your tarball, then reinject it with the merge-upstream [21:55] slangasek: thats what I tried. *same* result. [21:55] ok [21:55] because thats exactly what merge-upstream does IIRC [21:55] apw, I think so, yes. If you have the link still handy I can post it to them now [21:55] SpamapS: give me a minute for my terminal to catch up with us then :) [21:58] slangasek: I don't know why I seem to be the only one who runs into all the UDD weirdness. :-P [21:58] bryceh, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commitdiff;h=6d74feca6235b463ade4ecddd1dfdb73d30a2ff7;hp=e29a4668d7441aa88d8015da51674a7e8159312b [21:58] SpamapS: well for starters, I've never seen this message before from bzr merge: [21:58] bryceh, thats what we are using to prevent the crash [21:58] Exporting upstream branch revision kapil.thangavelu@canonical.com-20120415230912-d0itvlx1i2ft0c41 to create the tarball [21:58] so the juju branch seems special :) [21:58] slangasek: haha ok [21:59] bryceh, so ... drop me an email with wherever we are at so i can follow up in the am [21:59] * SpamapS hates being special [21:59] hm, so if someone reports a broken do-release-upgrade, but because they had left processes running (causing deluser to fail), do we call that invalid, or should the pkg upgrade deal with it gracefully? [22:00] apw, add yourself to cc on https://bugs.freedesktop.org//show_bug.cgi?id=48894 [22:00] Freedesktop bug 48894 in Driver/intel "plymouthd crashed with SIGABRT in __assert_fail_base()" [Major,New: ] [22:00] SpamapS: so what's astonishing to me is not that there was a directory conflict, but that the *contents* of those directories seem to be entirely disjoint [22:00] $ diff -uNr docs* | diffstat [22:00] [...] [22:01] 37 files changed, 4685 insertions(+), 78 deletions(-) [22:01] SpamapS: why does the upstream branch look nothing like the current UDD branch? [22:02] slangasek: thats about right.. lots of features landed [22:02] apw, added you to the cc [22:02] slangasek: though thats not the same diffstat I see in the branch doing 'bzr diff -c 519..531' [22:03] slangasek: would it be better to back up to 0.5+bzr504-0ubuntu1 (r10) ? [22:04] well, let's see [22:04] slangasek: I have to step AFK for 15 minutes .. will be back ASAP [22:09] bryceh: someone want to tell fd.o they're not in UTC? :P [22:09] slangasek, OMG don't you dare [22:10] you like all incoming bugzilla mail being sorted 7 hours in the past? :) [22:10] slangasek, that's a quick path to getting flamed by mithrandir [22:10] heh [22:10] seriously, hang out on #freedesktop a while [22:10] I'm happy for them to use UTC for their timezone setting [22:10] as long as they set their friggin' clocks right [22:12] slangasek, I recommend raising the issue with him by pinging it (but don't mention what the ping is about). he loves that. [22:13] hahaha [22:13] bryceh: I have to be careful; if I taunt him too much, he'll make upstart in Debian a metapackage depending on systemd [22:17] slangasek: in bug 984693 update-notifier was just finishing up correct? [22:17] Launchpad bug 984693 in msttcorefonts (Ubuntu) "ttf-mscorefonts-installer also installs Flash" [Undecided,New] https://launchpad.net/bugs/984693 [22:18] bdmurray: yes, apparently they had the package installed already but the trigger hadn't done its job yet [22:18] slangasek, o_O [22:18] slangasek, you're gonna get me banned off freedesktop! [22:20] ;) [22:23] slangasek: back [22:23] slangasek, got a little feedback from jbarnes on the bug [22:23] slangasek: so, is there some version missing from the graph in that branch? [22:23] SpamapS: well, the version you pointed me at failed the same way [22:23] looking at the history now [22:24] SpamapS: has this merge-upstream *ever* worked for you, when pulling from the branch? [22:24] hey... [22:25] how can i make my system not multiarch ? [22:25] because sure enough, these main directories were added separately in the two branches [22:25] i'm looking for 'apt-get update' to not get i386 lists or show packages. [22:25] smoser: you can nuke /etc/dpkg/dpkg.cfg.d/multiarch; but this will make some software uninstallable for you [22:25] slangasek: I think so. But its hard to recall frankly. I have a lot of merge-upstream issues [22:26] slangasek, i'm ok with that. thank you. [22:26] SpamapS: 'bzr log -n0 juju' shows a completely different history for the directory on the ubuntu branch vs. the upstream branch [22:27] SpamapS: so you can do one of two things: 1) merge from the tarball only, which shouldn't fail like this; 2) port your local changes over on a one-time basis and nuke all of the .moved directories, which gets you in sync with the upstream branch going forward [22:27] slangasek: I think at some point I did an upload w/o committing.. so the importer grabbed it instead. Perhaps thats the issue? [22:28] well, the first commit by you on the UDD branch is revno 7 [22:28] before that they were auto-imported [22:28] ok [22:28] I like the idea of nuking and getting back on track [22:29] but *none* of the UDD branch history shows the history of the upstream branch... so what you're seeing now is the inevitable result of trying to merge two branches without shared history [22:29] but I'm not sure what that means.. so you're saying back up to the last uploaded version, merge upstream, fix .moved dirs, then manually patch in my changes? [22:29] with or without the "Back up" part [22:30] ok, and would just bzr rm'ing the .moved dirs suffice? [22:30] or maybe just 'bzr resolve *.moved' [22:30] (which you have to do anyway; I don't remember if the resolve also rm's in this case) [22:30] it doesn't [22:31] have to rm first [22:31] there are issues with that approach though [22:31] the 'examples' dir, for instance, has no README file now.. but the upstream version definitely does have that README file [22:32] ah, really? [22:32] yeah, its like only things that got touched are there [22:32] hmmmm [22:32] frankly I'm ready to just build a .dsc as I see fit, and let the importer handle it. [22:33] well, that's fine too [22:33] and approximately equivalent to doing a merge-upstream *without* referencing the upstream branch [22:33] I suspect if I --overwrite with all the things after the last upload uncommitted, that would do it, right? [22:33] heh, the importer hates --overwrite [22:33] slangasek: I get the same problem whether I merge-upstream lp:juju or an exported tarball tho. [22:33] if you leave it as-is, the importer will move your branch aside [22:34] slangasek: it wouldn't care if I used --overwrite to get it back to a state it knows about though, right? [22:34]