[00:00] <markh> there's your problem :)
[00:00] <disturbedsaint> its hg :/
[00:00] <disturbedsaint> ill uninstall
[00:00] <markh> well
[00:00] <markh> just work out how it got on your sys.path
[00:00] <disturbedsaint> was comparing hg with bzr :P
[00:01] <markh> but yeah, this channel will be unlikely to adise you to *not* uninstall hg ;) :)
[00:01] <disturbedsaint> :P
[00:02] <markh> it looks like tortoise's installer or something is broken - tbzr should not interfere with a stand-alone python install :(
[00:02] <markh> s/tortoise/hg/
[00:02] <markh> ack :) s/tbzr/hg/ too -  I think I'll give up :)
[00:07] <disturbedsaint> I guess thg's install is broken then, since it does somehow add itself to sys.path
[00:07] <disturbedsaint> when I just run a python shell though it's not there
[00:09] <markh> strange
[00:09] <markh> maybe the python.dll from that dir is found before any others?
[00:10] <markh> if that dir is before system32 on PATH I could see that happening...
[00:10] <disturbedsaint> will have a look,
[00:10] <disturbedsaint> in the trace it says bin path =  C:\Program Files\TortoiseHg
[00:11] <disturbedsaint> you're right I guess "C:\Program Files\TortoiseHg;C:\Program Files\TortoiseSVN\bin;C:\Python25"
[00:13] <markh> hrm - bin path should include \windows\system32 - all should work if you move that before hg
[00:13] <markh> or uninstall hg :)
[00:13] <disturbedsaint> yeah :P
[00:13] <disturbedsaint> will do!
[00:13] <disturbedsaint> bad behaviour! :P
[00:14] <markh> for my interest, why are you playing with sources instead of just the binaries?  you hoping to hack a little?
[00:14] <Peng_> Maybe you should take this up with the hg guys too to get that side of it solved.
[00:14] <disturbedsaint> yeah I'd like to get the latest version
[00:14] <disturbedsaint> +I don't mind to do a little trial&error/editing here and there to make it work
[00:15] <disturbedsaint> Can't fix a lot (yet, still want to learn more bout python) but can at least file bugs and test
[00:15] <markh> yeah - its possibly just their installer.  I'm not sure I'll get to finding and subscribing to their mailing lists etc
[00:16] <markh> ultimately we will be replacing that code with c++ anyway, so it should be less of a problem.
[00:16] <markh> and hopefully 'ultimately' means 'in the next couple of months'
[00:17] <disturbedsaint> you also know c++ or is someone else going to do the codeing?
[00:17] <markh> i know it too
[00:17] <disturbedsaint> I can file a bug for hg btw
[00:18] <markh> are you sure you didn't manually add that dir to your PATH?
[00:18] <disturbedsaint> the hg dir?
[00:18] <markh> if not, I guess the bug should say "please ensure you add yourself to the end of PATH, not the start"
[00:18] <disturbedsaint> 100% sure I didnt do that myself
[00:18] <markh> yeah
[00:19] <markh> cool
[00:19] <markh> and say "the problem is that python COM objects rely on pythonxx.dll being found on PATH, and if the hg one is found before the one in system32, COM objects will use the incomplete hg python modules and likely fail"
[00:20] <disturbedsaint> k
[00:20] <disturbedsaint> will do, thx!
[00:22] <disturbedsaint> yeay! I've go overlayed icons now!
[00:22]  * disturbedsaint = happy :)
[00:27] <Peng_> Ehh..
[00:29] <markh> woohoo :)
[00:34] <disturbedsaint> markh I've submitted a "bug" btw with the icon for the systray
[00:35] <markh> yeah, I saw that, thanks.
[00:35] <disturbedsaint> it's not included and seems to be hardcoded to "C:\Python25\Lib\site-packages\bzr.ico"
[00:35] <markh> its "hard-coded" to the parent of bzrlib
[00:35] <disturbedsaint> couldn't find where it was set in the sources
[00:35] <markh> if bzrlib is run from a source build it works
[00:36] <disturbedsaint> ah ok, thats why I couldn't find it
[00:36] <markh> somewhere like fixup_icon in tbzrlib\*.py
[00:36] <markh> its possible to use bzr from a source tree - just set PYTHONPATH to point at that too.  Then the icon will work.
[00:37] <markh> Note that all "help" links will also fail in source builds as we can't locate the built bzr docs.
[00:37] <disturbedsaint> I see, will do that
[00:37] <disturbedsaint> k
[00:37] <markh> (but at least it says "sorry - can't locate the docs in a source build" :)
[00:37] <disturbedsaint> also noticed the 3 links from the traymenu don't do anything
[00:37] <disturbedsaint> help/settings/about
[00:38] <markh> they should.  check .bzr.log
[00:39] <markh> you have the qbzr plugin installed?
[00:40] <markh> note that for debugging, it might be useful to exit the taskbar process, then manually execute 'python tbzrcache.py -v' - that will re-run the taskbar program, but show output on the console as well as logging it.
[00:40] <disturbedsaint> thats easier indeed
[00:40] <disturbedsaint> and I dont have qbzr atm because of the clean install :/
[00:40] <beuno> lifeless, it is
[00:41] <beuno> I sent you the traceback a few days ago
[00:41] <markh> you won't get too far without it.
[00:41] <beuno> probably wan't a good idea not to report it
[00:41] <beuno> Peng_, pong!
[00:41] <disturbedsaint> ok :) will fix that tomorrow, time to go to bed, quiet late already
[00:42] <disturbedsaint> Thanks a lot for your help!
[00:42] <markh> cheers!  good night!
[00:42] <disturbedsaint> thx
[00:43] <disturbedsaint> have a nice day!
[00:43] <disturbedsaint> bye!
[00:43] <markh> you too
[00:43] <Peng_> beuno: Hahaha, hi.
[00:47] <Peng_> beuno: Um..a few days after the abstract_paths stuff, Googlebot started causing lots of errors like 'NoSuchId: The file id "<whatever>" is not present in the tree None.'I guess it was finding links to files in revisions where they didn't exist? Do you think that could have happened?
[01:01] <beuno> Peng_, well, my guess would be that it was still lookinf for file IDs
[01:01] <beuno> although, those URLs should probably be valid...
[01:02] <Peng_> Hmm
[01:03] <Peng_> You're right. At least one example was with a file ID.
[01:04] <beuno> Peng_, I will do some tests and see if I broke fileids
[01:04] <beuno> I shouldn't of
[01:05] <Peng_> Euhh.
[01:06] <Peng_> One of the requests that bombed was for /annotate/811/some/path?file_id=totally_different_file_id
[01:07] <fullermd> It's reaching into the future and handling the result from 'bzr cp'.
[01:08] <Peng_> fullermd: It's not handling it very well. :P
[01:08] <Peng_> How do you check the file ID of a path?
[01:08] <fullermd> No, _it's_ handling it fine.  It's not Google's fault your version of bzr is too old   :p
[01:08] <lifeless> beuno: I filed a bug with the fix
[01:08] <lifeless> beuno: you broke it :)
[01:09] <Peng_> lifeless: Who broke what?
[01:09] <Peng_> Are we talking about me?
[01:09] <Peng_> (I mean, my issue)
[01:09] <fullermd> Colonel Mustard, in the library, with the wrench.
[01:10] <lifeless> beuno: loggerhead's search facility
[01:10] <Peng_> Oh.
[01:16] <beuno> lifeless, I did?  aw...
[01:16] <beuno> I'll merge it in tomorrow
[01:16] <beuno> thanks
[01:16] <lifeless> beuno: [(foo)] != [(foo,)]
[01:16] <beuno> now, I need some sleep to manage the halloween alcohol  :)
[01:17]  * beuno waves
[01:17] <lifeless> be
[01:17] <lifeless> bye
[01:21] <Peng_> G'night.
[10:30] <gour> what 1.9 format brings?
[10:40] <gour> will 1.9 remove some of the old formats?
[10:42] <luks> bzr doesn't remove all formats
[10:43] <luks> old
[10:45] <AfC> Well, as long as we can get rid of the gawdawful mess that is present in the help of `init` and `init-repo`, what is silently supported doesn't matter. But right now that is the very first impression one has of bzr, and it howls.
[11:21] <Odd_Bloke> I think the first impression one has of bzr is whatever the tutorial you're following tells you.
[11:24] <gour> still, looking at plethora of formats is not encouraging...
[11:26] <Odd_Bloke> No, that's true.
[11:30] <gour> some months ago, shortly after moving to bzr, i asked the same question and all what changed is some new formats :-)
[13:43] <jelmer> gour, I really think we should move to using a rich root format as default..
[13:44] <jelmer> gour, that eliminates half of the formats for the future
[13:44] <gour> jelmer: i agree. the present situation is messy...too many formats
[13:45] <gour> the 'old' formats should become 'hidden'
[13:48]  * gour is doing sys-upgrade which brings python-2.6
[14:09] <AnMaster> hm?
[14:09] <AnMaster> pack-0.92?
[14:10] <AnMaster> yeah why haven't the default format changed from that yet (in 1.8 which is what I have)
[14:16] <gour> and we got new '1.6' formats
[18:00] <rocky> how is python2.6 support with bzr 1.9 ?
[18:03] <LarstiQ> rocky: afaik all known 2.6 issues were released in 1.8
[18:03] <rocky> oh cool
[18:03] <LarstiQ> ehm, fixes for those issues
[18:03] <LarstiQ> rocky: so I expect 1.9 to be all dandy
[18:03] <rocky> jelmer: which version of bzr-svn for bzr 1.9 ? :)
[18:35] <ronny> hmm, how much better is bzr v1.9?
[18:55] <fullermd> .1 obviously.
[19:31] <lifeless> Peng_: how are you liking btrees?
[20:10] <LarstiQ> ronny: any area in specific?
[20:11] <LarstiQ> ronny: it has things I care about, but you might not.
[20:11] <ronny> LarstiQ: speed, repo size?
[20:11] <ronny> hmm
[20:11] <ronny> sometimes i wish bzr had a monotone-style branching ui with updates to specific revisions
[20:12] <LarstiQ> ronny: btree indices in format 1.9, pack optimizing for size more (possibly 25%), less memory usage for checkout, annotate fast path
[20:13] <LarstiQ> ronny: I'm unfamiliar with monotone I'm afraid, other than using it as part of the OpenMoko build
[20:13] <ronny> LarstiQ: branches can have multiple heads, and one can easyly move the dirstate to previous revisions within that branch
[20:14] <LarstiQ> ronny: just the dirstate, or does that also work well for daggy fixes?
[20:14] <ronny> of course well for dagy fixes
[20:15] <LarstiQ> ok, so what's the ui like?
[20:15] <ronny> mtn up -r the_rev_i_want; edit; commit;merge
[20:15] <ronny> btw, it works the same in hg
[20:16] <LarstiQ> how far would you be along to that if you had up -r?
[20:16] <fullermd> mtn's allowing multiple heads on a branch is what makes daggy fixing work so well there.
[20:16] <fullermd> Without that, it's a whole lot more work.
[20:16] <LarstiQ> (ie, hg, in the case of two heads, automatically merges them with an unqualified merge iirc)
[20:16] <fullermd> (now, you don't _actually_ need to support multi-headed branches to do it per se, but you have to hack up something near indistinguishable)
[20:17] <ronny> LarstiQ: hu? hg doesnt auto-merge multiple heads
[20:17] <LarstiQ> ronny: I mean, you don't have to specify what you want to merge, if you say you want to merge, and have two heads
[20:17] <LarstiQ> ronny: is that wrong?
[20:17] <ronny> LarstiQ: ah, ok thats right
[20:18] <LarstiQ> that latter part might be a bit troublesome
[20:18] <LarstiQ> oh, but no
[20:19] <LarstiQ> it could work nicely if you had a :other-head style thing
[20:19] <fullermd> Well, it works in mtn since that's all that 'merge' does.
[20:20] <LarstiQ> fullermd: right, bzr already has a meaning for just 'bzr merge'
[20:21] <luks> hm, committing to an "outdated" tree and updating only the tree parent id (not the branch) seems like an interesting idea
[20:21] <fullermd> Well, I haven't put much thought into the best way to represent it in bzr.  I mean, we can't even update -r yet...
[20:22] <luks> it would be basically like a local commit in a bound branch
[22:19] <LarstiQ> jam: hmm, your file_log plugin breaks selftest in an interesting way
[22:21] <LarstiQ> jam: not that that is relevant anymore, but it tries to load 'bzrlib.plugins.file_log.', which then gets to 'module = getattr(module, '')', and suprisingly module doesn't have a '' attribute.
[23:44] <rod__> hi, i'm trying to do 'bzr ls --kind=directory --non-recursive mybranch/some/folder' to list the contents of a directory in a branch, but it doesn't return any results.  i know this seems like a very basic question, but i can't find much help by searching for it.  thanks


[09:51] <kensho> hi
[04:22] <Sorbus> hi
[07:44] <getoo> i have a little problem , i had my laptop on hybernate , now the sound wont work , i even restarted the box , same thing
[07:44] <getoo> any suggestions


[00:16] <infinity> Odd_Bloke: *poke*
[04:01] <infinity> pitti: I thought you didn't consider the lxc runners good enough to give accurate results for migration purposes.
[04:01] <infinity> pitti: Though, I geuss if you're tracking always-failed per-arch, then the lxc ones can just have more failures for now.
[04:01] <infinity> pitti: I'm mildly concerned about the armhf tests holding up the show just due to speed now, though.
[04:02] <infinity> pitti: Especially since we used to optimise this by triggering x86 tests while armhf was still building.
[04:21] <pitti> Good morning
[04:21] <pitti> infinity: right, with jenkins we just tracked failures/regressions per package, hence ppc/arm (which have a lot more failures) couldn't be used for regression tracking; now we can
[04:22] <pitti> infinity: the speed is actually fine -- armhf finished the gcc5 triggered tests (~ 350) in about the same time as amd64+i386
[04:22] <pitti> and ppc64 is even faster, as I run two tests in parallel per VM
[07:49] <Odd_Bloke> infinity: Hm?
[07:53] <infinity> Odd_Bloke: Oh, I wanted to chat with you about doing powerpc cloud images, but we can do that when I'm not heading to bed.
[07:53] <infinity> Odd_Bloke: I figure it'll be 99% "do what ppc64el does", and 1% "ask Adam, cause WTF."
[07:54] <Odd_Bloke> infinity: :D
[07:54] <Odd_Bloke> That sounds pretty reasonable.
[07:54] <infinity> Odd_Bloke: What TZ (ish) are you working in?
[07:55] <Odd_Bloke> infinity: BST.
[07:55] <infinity> Odd_Bloke: And if the answer is "I started now, so now plus 8 hours", do you have time to stick around a bit after that to chat when I wake up?
[07:55] <infinity> Odd_Bloke: If not, we'll catch up another day.
[07:55] <Odd_Bloke> infinity: Yeah, that should be fine.
[07:55] <infinity> Odd_Bloke: Kay, cool.  I'll be back in 6 or 7 hours for meetings, but will try to remember to poke you. :P
[07:56] <Odd_Bloke> infinity: :)
[08:33] <zzarr> hello! I get this error trying to build an application for my phone (MX4 Ubuntu Edition) "Unknown module(s) in QT: bluetooth"
[08:33] <zzarr> it compiles fin on my desktop machine
[08:35] <zzarr> fine*
[08:43] <pitti> zzarr: missing a qml-module-qtbluetooth or perhaps libqt5bluetooth5 build dep or so? (sorry, no clue about Qt, but usually missing build deps is the reason)
[08:45] <zzarr> but where are they missing, and how do I install them?
[08:45] <doko> barry, sure. you touched it last ;)
[08:49] <pitti> coreycb, jamespage: mind having a look at the wily failure in http://autopkgtest.ubuntu.com/packages/n/neutron/ ?
[08:50] <pitti> sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:mysql
[08:50] <pitti> missing dependency or something such?
[08:51] <pitti> coreycb, jamespage: it coincides with https://launchpad.net/ubuntu/+source/sqlalchemy/1.0.8+ds1-1ubuntu3 , thus britney rightfully held that back: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sqlalchemy
[08:52] <pitti> neutron itself is also FTBFS
[09:57] <jtaylor> doko: is there a reason our bash uses its on memory allocator and not the one from glibc?
[10:09] <tseliot> pitti: is this a known problem with systemd in wily? (it happens in my sbuild chroot) http://pastebin.ubuntu.com/12204790/
[10:12] <pitti> tseliot: hm, not known to me; but that's in dpkg's unpack stage
[10:15] <tseliot> pitti: oh, right
[10:18] <rbasak> pmcgowan: could you comment on bug 1471903 please? ogra_ wanted you to have an opportunity to comment before we go ahead and upload the proposed fix there to Wily, since we want the fix to end up in the vivid-overlay PPA.
[10:18] <rbasak> bdmurray: ^^
[10:19] <rbasak> pmcgowan: my attempt at a summary is in comment #27
[10:26] <pmcgowan> rbasak, reading
[10:28] <ogra_> rbasak, ah, thanks, i was about to ping pat :)
[10:50] <pitti> arges, tjaalton: could I bribe you to look at the SRUs in bug 1489045? trivial thing, but it would unblock some infrastructure work
[11:02] <pitti> caribou: some cleanup to do for bug 1464201; otherwise this looks good, thanks!
[11:02] <caribou> pitti: anything you want me to do for that cleanup ?
[11:02] <pmcgowan> rbasak, ogra_ comment added
[11:02] <ogra_> thanks !
[11:02] <pitti> caribou: I followed up to the report
[11:03] <pitti> caribou: shoudl mostly be "put the .init back and correct the merge changelog"
[11:03] <pitti> caribou: and drop some unnecessary delta if you want (but this is just a suggestion)
[11:04] <caribou> pitti: sure, just comment in the bug & I'll fix that up
[11:04] <pitti> caribou: I did already
[11:05] <caribou> k
[11:10] <caribou> pitti: looks like the usage of imjournal.so needs some investigation
[11:11] <caribou> pitti: there are mentions of performance hit when using it instead of imuxsock
[11:11] <pitti> caribou: yeah, not a blocker for the FFE, just a question
[11:11] <caribou> pitti: let me look in to it
[11:11] <pitti> let's first get the new version in and look at this separately
[11:12] <caribou> pitti: their page says "The journal provides imuxsock with a copy of all “classical” syslog messages, however, it does not provide structured data"
[11:13] <caribou> pitti: so *maybe* this means that the basic journal data it picked up
[11:13] <pitti> oh, it is
[11:13] <pitti> it's just not totally reliable when there's a flood of messages
[11:13] <coreycb> pitti, neutron autopkgtests should be ok with 1.0.8+ds1-1ubuntu4, uploaded last night.  I'll look into the ftbfs.
[11:27] <pitti> coreycb: the tests do use sqlalchemy 1.0.8+ds1-1ubuntu4 and fail with that
[11:27] <coreycb> pitti, oh I thought you said they were using 1ubuntu3
[11:27] <pitti> coreycb: no, just that they started failing with this version
[11:27] <coreycb> pitti, ok I'll look
[11:27] <pitti> coreycb: sorry for the misunderstaning
[11:28] <pitti> coreycb: thanks!
[11:28] <coreycb> pitti, np!
[11:34] <zzarr> hello! if I compile a project based on QtQuick for a Ubuntu kit, where's the executable located (on my Ubuntu Phone in this case)?
[11:35] <mitya57> zzarr: you probably want #ubuntu-touch or #ubuntu-app-devel
[11:35] <zzarr> mitya57, thanks
[11:42] <doko> jibel, online?
[12:09] <jibel> doko, I am online
[12:10] <rbasak> pmcgowan: thanks!
[12:11] <rbasak> sil2100, ogra_, bdmurray: so who's sponsoring this? Is everyone happy with sil2100's debdiff in comment #11?
[12:12]  * rbasak notes that the changelog entry needs a bug reference
[12:17] <tjaalton> pitti: done
[12:22] <sil2100> rbasak: I'm happy with it, and I know bdmurray and infinity were too
[12:22] <sil2100> Not sure who's ACK would we still need
[12:22] <pitti> tjaalton: cheers!
[12:23] <ogra_> sil2100, well, note that pmcgowan asks that the overlay PPA has an override for the change
[12:23] <ogra_> beyond that, yeah, someone should just upload :)
[12:23] <sil2100> Wait, why?
[12:23] <tjaalton> arges: fyi ^, acked the dkms sru's already
[12:24] <sil2100> The point of it is having that on our stable phones so that we can get proper reports
[12:24] <ogra_> sil2100, well, effectively we need to re-work apport so we can drop the lists again ... perhaps we can live with the bloat until the next OTA
[12:25] <ogra_> (and have sommeone fix apport)
[12:25] <sil2100> pmcgowan: hey! You don't want the change for including apt lists of -updates and -security in the images? Why?
[12:25] <ogra_> sil2100, seen the mail from john ?
[12:25] <ogra_> regading image size ...
[12:26] <ogra_> the rootfs will soon ship the infrastructure for desktop apps ... they are supposed to be executed in a chroot or container ... we will need to ship another 50-100M for that infrastructure (minimal chroot etc)
[12:26] <sil2100> ogra_: it still should be ok, the difference is small - I understand the point, but holding off this change won't make much difference
[12:26] <ogra_> we can really not waste space like that
[12:27] <ogra_> sil2100, the difference is 50-60M
[12:27] <ogra_> note that we used to wipe these package lists
[12:27] <ogra_> not sure when or how they were added
[12:27] <rbasak> I thought that since we're already shipping the lists for the release pocket, the difference for -updates and -security is actually much smaller?
[12:27] <pmcgowan> sil2100,this pointed out we previously added 66MB we did not expect
[12:27] <sil2100> ogra_: no it's not
[12:27] <ogra_> rbasak, that we ship them at all is the main buug
[12:27] <pmcgowan> right
[12:28] <sil2100> I checked that it's basically 5 MB more
[12:28] <sil2100> ogra_: didn't you see my comment?
[12:28] <ogra_> the original build scripts from the OEM team had code that forcefully removed them
[12:28] <pmcgowan> sil2100, te issue is the lists should not be installed at all
[12:28] <ogra_> and all our size measurements we did in malta were based on a rootfs without them
[12:28] <sil2100> pmcgowan: right, but that's a separate bug anyway
[12:28] <ogra_> and these size measurements are the base for our parittioning scheme
[12:28] <sil2100> Since we ship them right now anyway
[12:29] <mdeslaur> tkamppeter: how can I test ippusbxd?
[12:29] <rbasak> I don't think anyone disagrees with that. The question is about what we do right now.
[12:29] <pmcgowan> sil2100, but thats how we want to fix it for next stable update
[12:29] <ogra_> sil2100, yes, as i said, someone needs to fix apport asap to not require them
[12:29] <pmcgowan> we dont need to fix it in proposed I'd say
[12:29] <pmcgowan> we just want the real fix
[12:29] <ogra_> rbasak, right now we want this fix to land to not hold back other images
[12:30] <sil2100> ogra_, pmcgowan: is bdmurray working on the fix?
[12:30] <ogra_> but for the phone we want a plan that makes us go back to a sane size
[12:30] <pmcgowan> sil2100, no one is yet, I just filed a separate bug
[12:30] <ogra_> sil2100, no idea, someone has to though
[12:30] <sil2100> Ok, thanks
[12:30] <pmcgowan> sil2100, and I added it to ota7 list
[12:31] <ogra_> pitti, on that note (see backlog above) are there any plans for apport in snappy ?
[12:31] <ogra_> i guess a fix for the phone could be designed in a way that it also helps running apport on snappy
[12:57] <pitti> ogra_: we haven't really talked about that yet; i. e. what kind of error reporting do we actually want from snappy? Just for the snappy OS itself, or for any of the apps? the latter surely shouldn't be Ubuntu bugs, but go somewhere else? etc.
[12:58] <ogra_> pitti, well, snappy on the phone and snappy personal will surely want to use some kind of automatic error reporting ... and there we cant rely on apt lists locally
[12:58] <pitti> ogra_: if we remove dpkg and /var/lib/dpkg/* we stop being able to associate a binary to a package; so if that's what we conceptually want, we could still file bugs against teh "snappy" project, but we can't associate them to their real packages any more
[12:59] <pitti> ogra_: hm, we only need the apt lists to determine the origin, no? mapping a path to a package should just require the dpkg db
[12:59] <ogra_> pitti, and that lists issue already hits us ahrd on the phone today ... so having a plan that can also work on snappy would be good
[13:00] <ogra_> pitti, well, i'd go even further and say we could us a remote locatiojn for that data where we bind psckage lists to specific image versions
[13:00] <pitti> ogra_: that doesn't need to be done on the client side, though
[13:00] <rbasak> Could you just ask Launchpad? It has this information available already via publishing history, right?
[13:00] <barry> doko: :)
[13:01] <pitti> ogra_: on the client, specifying the executable path and channel/image number should be sufficient?
[13:01] <pitti> and resolving that to a package could then even be done in launchpad/on the retracers, etc.
[13:01] <ogra_> yeah
[13:02] <pitti> (probably not in LP itself, but the retracers could post-process reports)
[13:12] <cjwatson> rbasak: soooort of, but that often doesn't quite match up to image building for various reasons; more reliable to keep manifests
[13:17] <rbasak> OK
[13:32] <Laney> tyhicks: hi, do you have a bug # to track removing the GetConnectionAppArmorSecurityContext porting?
[13:32] <Laney> erm, that sentence made more sense before it got through my fingers
[13:32] <Laney> you know what I mean :)
[13:34] <pitti> apw: is this uninstallability known? http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#linux-meta
[13:40] <mdeslaur> slangasek: weren't you going to upload a new edk2?
[13:45] <apw> pitti, why _it_ that uninstallable, there is a linux-image-virtual-lts-utopic
[13:47] <pitti> but http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_output.txt says it's not installable
[14:00] <apw> oh ... its an arch thing
[14:03] <apw> pitti, ok that is plain wrong and has been plain wrong since it was first released by the looks of it
[14:03] <pitti> apw: I guess we just never paid attention to britney uninstallables in stables so far?
[14:03] <pitti> Laney: \o/ congrats!
[14:03] <apw> pitti, i guess not, anyhow, i'll get a bug filed and someone to fix 'er up
[14:04] <Laney> pitti: wily is open for breakage again :)
[14:04] <pitti> Laney: britney has lots of shiny! :)
[14:05] <caribou> pitti: Just uploaded changes for LP: #1464201
[14:16] <apw> pitti, bug #1489487
[14:23] <tyhicks> Laney: bug #1489489
[14:23] <tyhicks> Laney: I need to add more source packages that are affected and need to provide an example of how to switch over but at least we have a placeholder now
[14:28] <Laney> tyhicks: ok, it'd be nice if we could do this for 15.10 if possible
[14:28] <Laney> if it's easy maybe I can help
[14:40] <tyhicks> Laney: I doubt 15.10 is possible
[14:41] <Laney> why?
[14:44] <tyhicks> Laney: I don't have much time to devote to it at the moment
[14:45] <tyhicks> Laney: if individual project maintainers want to jump in and make the changes based on the examples that I provide, then it may be possible
[14:46] <tkamppeter> mdeslaur, run "ippusbxd -d -n -N -P 60000" on the command line. This runs ippusbxd without presence of a printer but opening the port.
[14:46] <tkamppeter> mdeslaur, see "ippusbxd -h", "-N" is the no-printer mode for development and debugging.
[14:50] <mdeslaur> tkamppeter: ah! great, thanks
[15:10] <mdeslaur> tkamppeter: ah, my ippusbxd is too old to have those options...it's the vivid cups-filters package
[15:10] <mdeslaur> tkamppeter: do you have the required hardware to test the update in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages ?
[15:15] <tkamppeter> mdeslaur, I have the hardware, so tell me whatever steps I have to do (probably with Vivid as Wily uses the new ippusbxd).
[15:16] <mdeslaur> tkamppeter: install the cups-filters binaries from that ppa on vivid, and see if ippusbxd still works, that would be an enormous help
[15:20] <pitti> cjwatson: britney itself (at least not britney2-ubuntu) doesn't "do" the copy from -proposed to -release, it just computes the set of packages that it can migrate, right? do you know what does that?
[15:20] <pitti> sil2100: ^
[15:21] <cjwatson> pitti: Start from lp_import in britney1-ubuntu (which wraps britney2-ubuntu)
[15:21] <cjwatson> pitti: promote-to-release is in lp:ubuntu-archive-tools
[15:21] <pitti> cjwatson: ah, in britney1
[15:22] <pitti> so britney2 writes HeidiResultData, britney1's ./britney calls promote-to-release
[15:23] <sil2100> \o/
[15:23]  * sil2100 looks at that
[15:23] <sil2100> cjwatson: thanks!
[15:24] <pitti> cjwatson: cheers
[15:25] <sil2100> How did I miss that, sometimes I feel like a blind guy
[15:25]  * pitti hasn't touched britney1 at all yet, didn't know it either
[15:26] <tkamppeter> mdeslaur, I have tested and the security fix seems to be OK.
[15:26] <mdeslaur> thanks tkamppeter! very much appreciated
[15:26] <tkamppeter> mdeslaur, but can you please also apply also this (functional, not security) fix:
[15:26] <tkamppeter> https://github.com/tillkamppeter/ippusbxd/commit/3facde24a3b74168047dcd564bf609fd9911edcb
[15:26] <cjwatson> To be fair it is a baroque setup, but I was trying to make it as close to the deployed setup in Debian as possible (and theirs had accreted over time)
[15:27] <tkamppeter> mdeslaur, it is a simple patch, without it most printers are not able to print but only allow access to their web config interface.
[15:28] <tkamppeter> mdeslaur, Wily already has this fix as it uses the 1.22 release.
[15:28] <mdeslaur> tkamppeter: we don't usually include fixes in security updates, but I'll include this one
[15:28] <mdeslaur> tkamppeter: thanks
[15:28] <tkamppeter> mdeslaur, thanks.
[15:31] <slangasek> mdeslaur: yeah, but I wasn't in a hurry :) I have another patch pending from dannf for proper arm64 vm support, but he also tells me that something's funny with the arm64 build when cross-built
[15:31] <slangasek> dannf: ^^ any progress on that?  and do you happen to have checked that rebuilding the existing package with gcc-5 works?
[15:31] <mdeslaur> slangasek: ok...I have some updated libosinfo and virt-manager packages...but libvirt needs your edk2 packages to detect the firmware properly
[15:32] <mdeslaur> slangasek: so I guess we need to publish these all together under the same FFe
[15:32] <dannf> slangasek: yes, same package rebuilt w/ gcc5 fails. i'm doing a gcc bisect, but having to skip a lot of build failure revs
[15:32] <dannf> slangasek: one workaround would be to force gcc-4.9 for now
[15:32] <slangasek> mdeslaur: I don't think the edk2 side needs an FFe fwiw
[15:33] <mdeslaur> hrm, mine does :P
[15:33] <slangasek> dannf: that's no workaround, there is no cross gcc-4.9 in Debian ;)
[15:33] <slangasek> I would have to back out that change
[15:33] <dannf> slangasek: right - well, bisection continues - hopefully that'll find the root cause
[16:17] <bdmurray> seb128: While https://errors.ubuntu.com/bucket/?id=failed%3A/usr/lib/i386-linux-gnu/libgtk-3-0/gtk-update-icon-cache-3.0%3A11%3Ai686%3A/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1%2B6d08%3A/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1%2B4b49%3A/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so%2Bff4 has failed to retrace do you have any ideas what the problem may be?
[16:18] <seb128> bdmurray, no idea no
[16:25] <tkamppeter> Is there some system facility which "corrects" file ownerships and permissions in Ubuntu, for example out of a cron job?
[16:29] <dobey> tkamppeter: no
[17:21] <Odd_Bloke> infinity: I have a hard EOD in about 90 minutes, if you still want to talk powerpc images today.
[18:06] <dannf> slangasek: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1489560
[18:22] <slangasek> dannf: so as you assigned this to edk2 rather than gcc, does that mean you think it's a bug in edk2?
[18:40] <dannf> slangasek: i have no idea, though i'd lean towards a gcc regression. marked as impacting both now.
[18:48] <bdmurray> Riddell: Do you have any plans to fix the ubuntu-release-upgrader test failure? http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/wily/amd64/
[19:49] <doko> barry, do you have an estimate what still needs to be done for python3.5 as the default? honestly I'd like to see this for 15.10, even if it breaks some stuff, so we have something stable in preparation for the next LTS
[19:59] <barry> doko: i was just chatting w/ slangasek about that.  i need to do an updated review of main + seeded packages that ftbfs or fail dep-8 w/py35 as default.  my biggest concern frankly is django and its ecosystem.  a safer route is to keep 3.5 as supported for 15.10 and do the switch to default as soon as x opens
[20:03] <doko> barry, sure, but that won't expose 3.5 that much to users and developers
[20:04] <doko> ohh, and I should better run python3.5 in the autopkg tests for python3.5, and not 3.4 ...
[20:07] <barry> doko: that's true, but i think we've done a really good job of getting upstreams on the py35 bandwagon just by doing our transition.  also: what's the plan for 3.5 as support or default in debian?
[20:08] <doko> barry, finishing GCC 5 first according to the release team ... and I'm not the only python3-defaults maintainer
[20:09] <barry> doko: right.  perfectly reasonable to finish gcc5 first.  is there an eta for that?
[20:10] <doko> barry, 1-2 months, that's what the release team things. but how does this relate to making 3.5 the default for 15.10?
[20:11] <juliank> If somebody wants to try APT 1.1 in wily, the PPA builds that now: https://launchpad.net/~deity/+archive/ubuntu/sid (yes, the name is wrong, sid is tracking HEAD, which is currently experimental)
[20:11] <doko> juliank, mvo is back from vacation, hint, hint ;-P
[20:12] <barry> doko: doesn't much, mostly curious.  i think we're probably not in bad shape for debian to go to 3.5.  as for ubuntu, let me see what other main+seeded packages still need love
[20:13] <juliank> doko: Sure. But APT 1.1 is post-wily stuff, so the PPA allows people to test it anyway
[20:13] <doko> barry, I can start the next test rebuild with 3.5 as the default, but then you would have to identify the 3.5 related ftbfs
[20:13] <doko> ahh, ok
[20:14] <barry> doko: would that be much different from the ~pythoneers/py35asdefault ppa?
[20:14] <doko> barry, it would be recent, and for all archs
[20:15] <barry> doko: it would be good data then
[20:15] <doko> ok, planning for it
[20:16] <juliank> I'll soon release python-apt 1.0~beta4 though, that one is targeted at wily.
[20:16] <slangasek> doko: I disagree that it's better to have 3.5 as default in 15.10 when we know it will break packages; especially since we're past FF and barry has already signalled via the mailing list that we're not switching, I think it's more effective to focus on the known issues i.e. build failures) between now and 15.10 release, and get these fixed via Debian
[20:20] <doko> slangasek, ohh, didn't see that. but I disagree on the breakage thing. sure, there is django, but we don't know about anything else
[20:32] <slangasek> doko: there are still a large number of build failures in the py35default ppa
[20:35] <doko> slangasek, afaics the ppa wasn't updated
[20:36] <barry> i have a script to sync the archive to the ppa
[20:37] <barry> which i just again ran 15m ago :)
[20:59] <bdmurray> Riddell: I'll fix ubuntu-release-upgrader
[21:04] <ochosi> hey everyone
[21:04] <ochosi> who's currently in charge of ubiquity?
[21:05] <ochosi> is it cyphermox?
[21:15] <Unit193> Thought so.
[21:18] <cyphermox> yo?
[21:33] <Riddell> bdmurray: I uploaded to vivid-proposed, awaiting ubuntu-sru approval
[21:33] <Riddell> bdmurray: oh but I've not seen the test failure
[21:34] <ochosi> cyphermox: just wondering whether another ubiquity release was planned for 15.10 because there is a xubuntu-relevant bugfix in trunk that would be nice to have (aka commit 6307)
[21:43] <Logan> slangasek: looks like the Debian maintainer renamed the gtkglextmm shared library package for G++ 5 - should we pull that in?
[21:49] <cyphermox> ochosi: yes, there will be an upload soon :)
[21:51] <slangasek> Logan: I would say yes
[21:52] <ochosi> cyphermox: awesome - thanks!


[14:44] <_gpg_> hello everybody
[14:45] <_gpg_> anyone know if it's possible (really tried lot of things)/ and how to dynamically change the view delegates of a list view please ?
[14:46] <_gpg_> i've a ListModel containing my data, different components that displays these data in different ways and a ListView, i'd like to change ListView delegate on demand
[14:46] <_gpg_> looks to be a very comon use case however there's no clean solution


[00:55] <mars> zobi1, best ask a question directly to the Translations team.  They can tell you more about the system:  https://answers.edge.launchpad.net/rosetta/+addquestion
[10:54] <Lord-Readman> Chris mate, its doing well http://impoll.net/cgi-bin/v.cgi?p=10231&r=9
[11:27] <magcius> Does Launchpad send an email to the project owners when a branch is linked?
[11:27] <wgrant> magcius: Linked to what?
[11:28] <magcius> If I "register a branch" with a project, will it/how would I send a message to the appropriate person?
[11:29] <wgrant> magcius: It won't notify them, unless they have subscribed to the RSS feed. If you want to request that they merge it, you could click 'Propose for merging'.
[11:30] <magcius> wgrant, ahhhh
[11:30] <wgrant> That will email the default reviewer for the target branch.
[11:30] <magcius> I'm still a bzr noobie, is a bzr merge like a git pull?
[11:30] <wgrant> Yes.
[11:30] <magcius> or does bzr pull have the same semantics too
[11:31] <wgrant> pull will bring the target's tip to the same as the source's, if the source has a superset of the target's revisions.
[11:32] <wgrant> But otherwise you need to merge.
[11:33] <magcius> when in normal practices will that not be the case?
[11:33] <magcius> i.e. can you do bzr pull --rebase like git?
[11:33] <magcius> Or is there something equivalent at all?
[11:33] <wgrant> It will not be the case when there have been commits on trunk since it was last merged into the branch.
[11:33] <wgrant> There is bzr-rebase, but it is not normally used.
[11:34] <wgrant> Rewriting history is frowned upon.
[11:34] <magcius> git pull --rebase isn't really rewriting history
[11:34] <wgrant> Doesn't it rebase the branch on top of trunk?
[11:35] <magcius> it's basically, 'find the common revision, undo and store everything from then as patches, pull, then apply the patches'
[11:35] <magcius> which is very useful if you have local commits for fixes or have applied patches that are not upstream]
[11:35] <wgrant> bzr rebase can do that easily.
[11:35] <wgrant> But it is not often done.
[11:36] <Meths> magcius: Until you merge patches from other people to send upstream, then rebasing reassigns credit for patches and is a bad thing (tm)
[11:36] <magcius> Meths, why would it do that?
[11:36] <siretart> magcius: the 'undo, store and redo' part is a typical case for "rewriting history"
[11:36] <magcius> Meths, doesn't bzr store both an author and committer?
[11:37] <magcius> (I swore it did, because I saw both in the log)
[11:37] <wgrant> It does.
[11:37] <magcius> So would a rebase re-assign both the author and committer?
[11:38] <Meths> magcius: Sorry, thought git did this.  Not bzr.
[11:38] <magcius> Meths, nope.
[11:39] <Meths> hmmm, okay.  Have to reread why Linus hates rebasing so much...
[11:39] <magcius> he does?
[11:39] <magcius> rebasing isn't something you usually do in upstream repos
[11:40] <magcius> but it's useful when merging in other changes since the histories have diverged
[11:40] <magcius> siretart, well my branch is a branch and I don't think it's quite that bad to rewrite history just so I can get latest changes. Is there a "better" way in the terms of bzr?
[11:41] <Meths> Ah, after rereading it's nothing to do with history rewriting, my bad.
[11:41] <magcius> Meths, link?
[11:41] <Meths> http://kerneltrap.org/Linux/Git_Management
[11:42] <siretart> magcius: you could try 'bzr merge' folowed by 'bzr revert --forget-merges'
[11:42] <magcius> siretart, bzr merge lp:upstream-branch ?
[11:43] <wgrant> That will forget the wrong merges.
[11:43] <wgrant> magcius: Why do you want to rewrite history?
[11:43] <siretart> wgrant: he wants 'git pull --rebase' semantics
[11:43] <magcius> wgrant, mainly to keep my commits on top so I can deal with them easily.
[11:43] <magcius> wgrant, and it's an easier fix if they go wrong to fix *my* commits instead of *their* code
[11:44] <siretart> magcius: I haven't followed bzr development closely lately, but AFAIUI looms and pipes are designed for this use cases
[11:44] <wgrant> looms are indeed for this sort of thing.
[11:44] <magcius> eek...
[11:44] <wgrant> pipes are handy too.
[11:44] <magcius> is that like git stash?
[11:44] <wgrant> No.
[11:44] <magcius> or git branches?
[11:44] <siretart> no
[11:45] <magcius> link to a simple introduction?
[11:45] <siretart> https://edge.launchpad.net/bzr-loom
[11:45] <magcius> and is it an external plugin, and will everybody need it installed?
[11:45] <wgrant> Also https://launchpad.net/bzr-pipeline
[11:45] <magcius> oops
[11:46] <magcius> on my system the "Download" button is cut off
[11:46] <magcius> the background, that is
[11:46] <siretart> since you 'pull --rebase', you don't want that branch published anyways, so only you need to have that plugin installed
[11:47] <magcius> Is there any reason the latest announcement is for the release of 1.3, but the download is 2.0?
[11:48] <magcius> http://imgur.com/hP9qO.png
[11:48] <magcius> I think your sliding door needs extra length.
[11:50] <magcius> eek, the "convert everything to a loom" does not really seem suitable for registering a branch
[11:50] <wgrant> Hm?
[11:50] <magcius> wgrant, a reply to which
[11:51] <magcius> They don't really explain the terminology.
[11:51] <magcius> A "loom" is a repo/branch?
[11:51] <magcius> A thread is a set of patches?
[11:51] <wgrant> A loom is a stack of threads.
[11:51] <wgrant> A thread is sort of a mini-branch
[11:51] <wgrant> So within a loomified branch, you have a stack of threads.
[11:52] <wgrant> As the bottom thread you might have trunk,
[11:52] <wgrant> Then above that you have a thread for each of your patches.
[11:52] <magcius> and each thread has a superset of the history of the one below it?
[11:52] <wgrant> So you can version your patches, while keeping them separately on top of trunk.
[11:52] <wgrant> Yes.
[11:52] <magcius> hmm
[11:52] <magcius> So I can add patches to any thread at one point?
[11:52] <wgrant> pipeline is similar, except that it uses a stack of actual branches.
[11:53] <wgrant> "at one point"?
[11:53] <magcius> any point in time
[11:53] <wgrant> Right.
[11:53] <wgrant> You can switch between threads and commit to each of them.
[11:53] <magcius> So if I add something to a thread below another, the thread above will share that history too?
[11:54] <magcius> i.e. get that commit too
[11:54] <wgrant> Right.
[11:54] <wgrant> As you move up the loom, the changes will be merged up.
[11:55] <magcius> What exactly is quilt then?
[11:55] <wgrant> quilt is unrelated to bzr.
[11:55] <magcius> I know
[11:55] <wgrant> But it's similar. It's a stack of patches.
[11:56] <magcius> What is it implemented on top of?
[11:56] <magcius> (I can't find anything with a simple search)
[11:56] <wgrant> Probably just patch.
[11:56] <magcius> I mean, what tool? Darcs? Monotone?
[11:56] <wgrant> None.
[11:56] <wgrant> It doesn't use a version control system.
[11:57] <magcius> Okay, so where can I find it?
[11:57] <wgrant> quilt maintains an unversioned series of patches.
[11:57] <wgrant> apt-get install quilt
[11:57] <magcius> eek, I'm not an ubuntu user
[11:57] <wgrant> (or your favourite operating system's package manager)
[11:57] <wgrant> http://savannah.nongnu.org/projects/quilt
[12:01] <magcius> alright, thanks
[12:01] <magcius> I'm also looking at Stacked Git
[12:02] <magcius> which seems to provide a similar thing. I thank you for informing me of this, I really, really like the idea.
[12:02] <wgrant> It's hopefully a bit less ugly than rebasing.
[12:04] <magcius> Although I'm quite disappointed it needs a conversion to a loom to work, is there a way to push the current thread as a regular branch?
[12:06] <lifeless> magcius: bzr init <target>; bzr push target
[12:06] <magcius> where target is?
[12:06] <lifeless> magcius: or bzr export-loom will push all threads to a bunch of adjacent branches
[12:07] <wgrant> The question was truly perfectly timed.
[12:08] <magcius> lifeless, oh, so when it converts to a loom it *converts to a loom*
[12:09] <lifeless> I don't have any context here
[12:09] <magcius> So much that bzr init works and somehow magically doesn't destroy history in the loom and magically destroys history in the bzr branch
[12:09] <lifeless> so you'll need to fill me in a bit
[12:11] <lifeless> certainly neither loomify or init will destroy history
[12:16] <lifeless> magcius: well, I'm off to bed; I don't know what issue you encountered, but please do file a bug or ask a question or something.
[12:20] <AlanBell> hi, I have a PPA question
[12:20] <AlanBell> I have packaged a python upstream project http://lpod-project.org in my PPA
[12:20] <AlanBell> following the python packaging guide (or trying to)
[12:20] <AlanBell> it built for Karmic which is great, how do I get it to build for Lucid/Jaunty?
[12:21] <AlanBell> ppa:alanbell/lpod lpod-python is the package
[12:23] <Laney> AlanBell: for lucid, try copying the package — https://help.launchpad.net/Packaging/PPA/Copying
[12:24] <magcius> Hmm... I just took a look at the new OpenSuSE Build System... is Canonical planning something similar?
[12:25] <magcius> https://build.opensuse.org/
[12:25] <wgrant> magcius: Similar to what aspects of it?
[12:25] <wgrant> Launchpad does very similar things already.
[12:25] <magcius> wgrant, the fact that you can create packages for a bunch of distributions.
[12:26] <wgrant> Launchpad does that for Ubuntu, but I do not know of plans to do it for any others.
[12:26] <magcius> RPM-based systems (RHEL, Fedora, OpenSuSE, Debian, Ubuntu)
[12:26] <magcius> er
[12:26] <magcius> I forgot I had said that
[12:26] <magcius> disregard the RPM-base
[12:26] <magcius> d
[12:37] <AlanBell> The following source cannot be copied:
[12:37] <AlanBell> * lpod-python 0.9-1ubuntu3 in karmic (same version already has published binaries in the destination archive)
[12:37] <wgrant> AlanBell: Copy the binaries too.
[12:37] <AlanBell> however it lets me do it if I copy the binaries
[12:37] <AlanBell> isn't that bad?
[12:38] <wgrant> Probably not. Remember that Lucid started off a complete binary+source copy of Karmic.
[12:38] <wgrant> And most of Lucid's binaries are still the same as Karmic's.
[12:38] <wgrant> You'll have to test if it works, but it probably will.
[12:38] <AlanBell> ok, well I will give it some testing
[15:58] <geser> what's the best/easiest way to check if I've an anonymous or non-anonymous login to the LP API?
[16:23] <DexterLB> can I use lp for projects that are not software? e.g. blender movies etc? And use bzr to upload the blend files?
[17:32] <patx2> can i delete my ppa on launchpad? if not can i delete the packages in it?
[17:38] <patx2> ah nvm i found it
[18:00] <davidstrauss> I apparently need this branch upgraded to update the import: https://code.launchpad.net/~davidstrauss/hiphop-php/trunk
[18:01] <davidstrauss> I can't seem to upgrade it from the shell like I normally can.
[18:02] <davidstrauss> mars: ^^
[20:43] <rye> Is there any protection from spammers posting the ads to bug reports at Launchpad?
[20:52] <kermiac> hi. is anyone around who can look into https://answers.edge.launchpad.net/launchpad/+question/101807
[20:53] <kermiac> we are currently discussing this spammer in #ubuntu-bugs
[21:15] <kermiac> sorry to be persistant but, is anyone around who can help with another spammer? I am currently cleaning up the mess they have made so far
[21:15] <kermiac> https://answers.edge.launchpad.net/launchpad/+question/101807
[21:17] <lifeless> have you tried to speak to them?
[21:20] <kermiac> lifeless: no, I haven't. Normally I would try to speak to them first but it REALLY seems like this is the same spammer we had just over a week ago with the nospammail.net email address. Also the LP account name say a lot "fail2ban"
[21:20] <lifeless> fail2ban is a package name
[21:21] <lifeless> we get lots of folk that fanboy packages they are interested in
[21:21] <lifeless> not saying you're wrong
[21:22] <lifeless> but please try to speak with them
[21:22] <lifeless> I wish that LP subscribed non-QA folk to bugs they touch
[21:22] <lifeless> so that you could reply to the bug and be sure they would see the reply
[21:23] <kermiac> ok. point taken, but I am currently cleaning up a lot of old bugs that they are changing - adding tags, changing status, removing upstream tasks, etc. Seems exactly like https://answers.edge.launchpad.net/launchpad-registry/+question/100682
[21:23] <lifeless> suspension is a big hammer
[21:23] <lifeless> they are definitely misguided
[21:23] <lifeless> but they aren't adding advertising
[21:24] <lifeless> nor are they swearing or being otherwise clearly hostile
[21:24] <kermiac> with them having a "nospammail.net" email address, I don't believe they would get the email even if I did contact them.
[21:24] <lifeless> your belief is wrong :)
[21:24] <lifeless> to get an address active on LP, it has to receive email
[21:24] <kermiac> ok, ty for the discussion lifeless. I will try to contact this user
[21:25] <lifeless> because the LP address activation process involves LP sending them an email and them clicking on a unique link contained in the mail
[21:26] <kermiac> That would normally be the first thing I do, but this seems to be the same person. But I understand your point about suspension being a big hammer. I will try to contact this user, although I don't believe it will have any effect
[21:27] <idnar> nospammail.net is a real mail hosting provider
[21:27] <idnar> (apparently)
[21:28] <lifeless> its working on the misguided theory that spammers have an economic motive to ignore 'probably bogus' addresses.
[21:28] <kermiac> I thought it was simply a redirect service. obviously I was wrong
[21:34] <kermiac> ok, I have contacted the user to see if that helps http://ubuntu.pastebin.com/f65721765
[21:34] <kermiac> ty for the discussion
[21:35] <lifeless> thanks
[21:51] <aboSamoor> where can I know the list of the bugs sorted by the number of the people affected ?
[21:52] <lifeless>  don't think the web ui permits that; you can sort by number of dups though, or bug heat (which is similar)
[22:56] <wgrant> aboSamoor, lifeless: You've been able to sort by 'number of users affected' for a few months now.
[23:01] <wgrant> lifeless: While poking around in launchpadlib overnight, I discovered how launchpad.projects manages to act like a dict.
[23:02] <wgrant> lifeless: It's a hack in launchpadlib to construct URLs manually, with hardcoded names and URL patterns for a few top level collections.
[23:03] <lifeless> wgrant: can you apply that to series ?
[23:04] <wgrant> lifeless: You probably could, but the infrastructure would need a bit of work, and it is a horrible hack that probably should be avoided so as to encourage a proper fix.
[23:04] <wgrant> lifeless: To be clear, these names and patterns are hardcoded inside launchpadlib's code itself, not the WADL.
[23:48] <lifeless> wgrant: that makes sense to me though
[23:48] <lifeless> wgrant: getFoo(arg) -> foo[arg]
[23:48] <lifeless> wgrant: as a compilable pattern
[23:48] <wgrant> lifeless: It really does.
[23:49] <wgrant> But that'll need WADL changes, which probably means leonardr.
[23:49] <lifeless> why?
[23:49] <lifeless> I mean, can't we just observe that there is a getFoo
[23:49] <wgrant> lifeless: How do I tell launchpadlib which method to call?
[23:49] <wgrant> And which arguments to pass to it?
[23:52] <lifeless> getFoo(name) => __getitem__(name)
[23:52] <lifeless> on a 'foo'
[23:53] <wgrant> lifeless: And export a method named '__getitem__'?
[23:53] <lifeless> eys
[23:54] <wgrant> Ew.
[23:54] <lifeless> why ew?
[23:54] <wgrant> Exposing names like that.
[23:54] <lifeless> wgrant: uhm, __getitem__ is []
[23:55] <wgrant> It seems better (and reasonably easy) to a method decorator that tells the WADL generator to mark it as the default getter.
[23:55] <wgrant> lifeless: Yeah, I know.
[23:55] <lifeless> wgrant: I'm not saying put __getitem__ in the wadl
[23:55] <lifeless> I'm saying in the client side, use 'getFoo' to instruct the creation of a foo with a __getitem__
[23:55] <lifeless> assume the definition is fine, fix the compiler
[23:56] <wgrant> lifeless: where do I get the string 'getFoo' from?


[04:29] <jamesh> is there a recommended way of building packages from snapshots of the upstream VCS?
[05:13] <superm1_> now with the topic saying that PPA appears to not be accepting uploads, does that mean it just "appears", or that it literally isn't?
[05:24] <RAOF> superm1_: It isn't.
[05:24] <superm1_> that's a shame.
[05:24] <superm1_> but also would explain my confusions
[05:24] <RAOF> Or, at least, if it is it's accepting them in a totally useless way (not building them, for example)
[05:25] <superm1_> i pushed several packages over and over thinking that soyuz was just eating them
[06:20] <jtv> Hello 'padders
[06:21] <jml> hello
[06:21] <jtv> jml: good night
[06:22] <jml> jtv: :)
[08:19] <carlos> morning
[08:46] <StevenK> Is there any status update on PPA uploads? I uploaded something large to the ubuntu-mobile PPA this morning, and I'd rather not redo it
[08:51] <BjornT> StevenK: i think you'll have to wait for cprov or bigjools to come online.
[09:49] <poolie> hi, is there any plan to track the number of downloads from the file download feature
[10:06] <ubotu> New bug: #182795 in rosetta "Import queue UI too slow" [High,Confirmed] https://launchpad.net/bugs/182795
[10:09] <mpt> poolie, bug 121058
[10:09] <ubotu> Launchpad bug 121058 in launchpad "Show a download count for project admins on downloads page" [Wishlist,Confirmed] https://launchpad.net/bugs/121058
[10:10] <poolie> thanks, got it
[10:57] <jordi> bigjools: topic lists the date for the previous devel meeting
[10:57] <bigjools> jordi: heh not my fault but thanks, I'll fix it
[10:58] <jordi> bigjools: just informing the last modifier ;)
[10:58] <jordi> thanks
[10:58] <bigjools> jordi: I realised :)
[11:17] <geser> cprov: Hi, can you check where the checkstyle binary packages went? checkstyle may got moved to universe short before the fix for the arch:all bug.
[11:19] <cprov> geser: give me a minute
[11:19] <geser> sure
[11:19] <cprov> geser: I have to deal with other issue before, then I will check it for you.
[11:33] <pochu> If a bugzilla bug was closed with status RESOLVED and resolution OBSOLETE, is it right if a bug task in Launchpad says Invalid, or should I file a bug about it? Looks to me like the right status should be Fix Released.
[11:36] <intellectronica> pochu: i think INVALID is correct, since OBSOLETE in bugzilla means that it wasn't released, no?
[11:37] <pochu> Maybe the bug wasn't closed properly, but in this case the bug is fixed in VCS.
[11:37] <pochu> http://bugzilla.gnome.org/show_bug.cgi?id=488825
[11:37] <ubotu> Gnome bug 488825 in gst-plugins-bad "ffdemux_flv: Element doesn't implement handling of this stream" [Normal,Resolved: obsolete]  - Assigned to<EMAIL_ADDRESS>[11:38] <pochu> Look at comment #7
[11:38] <pochu> He said something like "It's already fixed in VCS, so closing as OBSOLETE"
[11:42] <intellectronica> pochu: yeah, which basically means - this bug is invalid, because it's no longer relevant
[11:47] <pochu> intellectronica: alright then. I'd have closed as fixed, and since I don't know bugzilla very much I was wondering whether it was ok. Thanks for looking :)
[11:48] <intellectronica> pochu: that's part of the problem with bugzilla - it's hard to know how to interpret all those different options, and different people use them for different purposes :)
[11:51] <pochu> :)
[12:07] <cprov> geser: I'm resurrect the mentioned binary publication, https://edge.launchpad.net/ubuntu/hardy/i386/checkstyle/+index. Let me know if there are others.
[12:07] <Hobbsee> hey cprov
[12:08] <cprov> Hobbsee: hey, how is it going ?
[12:08] <geser> cprov: thanks
[12:08] <Hobbsee> cprov: it's going OK.  i haven't killed anyone yet today.
[12:08]  * Hobbsee has been preparing her bigger cellar.
[12:10] <cprov> I'm not sure, it's exactly a "good to know" news, but fine :)
[12:10] <ubotu> New bug: #182822 in launchpad "latest-bugs.atom feed is incorrectly named" [Undecided,New] https://launchpad.net/bugs/182822
[12:11] <Hobbsee> cprov: you of course know that the bigger cellar is because the older one is full?
[12:12] <bigjools> charming
[12:13] <Hobbsee> heh, sorry :)
[12:15] <geser> Hobbsee: do one want to know with what you've filled it?
[12:16] <Hobbsee> geser: probably safer not to know.  but the answer should be reasonably obvious anyway
[12:31] <ubotu> New bug: #182828 in launchpad "launchpad should tell users that "Launchpad" is a trademark" [Medium,New] https://launchpad.net/bugs/182828
[12:37]  * rjek shudders.
[12:38] <rjek> What's the usual lead time on somebody testing and OKing a CVS import to launchpad?
[12:39] <kiko> rjek, usually a day, but I know that mwh is on vacation. what project is yours?
[12:39] <Hobbsee> oh goody, ppa got fixed
[12:39]  * Hobbsee ponders throwing kde4libs at it
[12:39] <rjek> kiko: wxLua.
[12:40] <ubotu> New bug: #182830 in malone "Linking package to bug report doesn't suggest checking upstream" [Undecided,New] https://launchpad.net/bugs/182830
[12:41] <kiko> rjek, let me check
[12:46] <rjek> kiko: It's not my project, but I created it on launchpad as I want to use bzr to branch from it.
[12:46] <kiko> rjek, yeah, I totally want to get this import going
[12:46] <kiko> rjek, I'll email tim to get it sorted by tomorrow
[12:47] <rjek> kiko: Thanks!
[12:49] <rjek> Also, bug: https://code.launchpad.net/~launchpad-stop-whinging/gniggle/gniggle <-- there is no email address in the changes whose author is entirely set as "<email address hidden>"
[12:50] <rjek> (the author string for those changes is "rjek" [branch was imported from svn.])
[13:02] <kiko> rjek, I think it's just because we have no way of asserting identity based on the string.
[13:03] <rjek> kiko: Well, it correctly obscures the email address part of the arbitary-string-username of the very latest changeset.
[13:03] <rjek> (and succeeds in not obscuring any other part of it)
[13:04] <rjek> But something appears to make it think that "rjek" is an email address.
[13:04] <kiko> rjek, hmm, weird
[13:49] <Kmos> https://edge.launchpad.net/ubuntu/hardy/+source/scim-bridge/0.4.14-1ubuntu1
[13:49] <Kmos> launchpad didn't close the bug report automatically
[13:54] <BjornT> Kmos: the .changes file doesn't seem to include headers for closing that bug: http://launchpadlibrarian.net/11322955/scim-bridge_0.4.14-1ubuntu1_source.changes
[13:57] <Kmos> BjornT: You didn't see this? "LP: #181029" ?
[13:57] <Kmos>  scim-bridge (0.4.14-1ubuntu1) hardy; urgency=low
[13:57] <Kmos>  .
[13:57] <Kmos>    * debian/rules:
[13:57] <Kmos>      + Remove empty po/scim.pot before building to make pkgstriptranslations
[13:57] <Kmos>        happy (Fix FTBFS; LP: #181029).
[13:59] <BjornT> Kmos: launchpad doesn't parse that text, though. launchpad looks at the Launchpad-bugs-fixed header, which the client is supposed to add.
[14:00] <Kmos> BjornT: so that's a problem of the uploader.. :)
[14:00] <Kmos> BjornT: thanks for the explanation
[14:01] <geser> Kmos: the question is why the necessary header wasn't written into the .changes file
[14:01] <geser> LP: #xxx should be enough for it
[14:02] <Kmos> geser: Need to ask ZhengPeng Hou about it
[14:03] <Kmos> maybe he uses an old ubuntu ?
[14:03] <Kmos> or even debian and not ubuntu.. lol
[14:26] <Kmos> cprov: i think the package mythbuntu-common, got the same problem of checkstyle, when moving to universe.
[14:26] <cprov> Kmos: let me check
[14:26] <Hobbsee> that's still in NEW
[14:27] <Kmos> Hobbsee: ah ok, thanks =)
[14:27] <Hobbsee> last i checked, anyway
[14:27] <Kmos> Successfully built  (NEW)
[14:27] <Kmos> should be in NEW
[14:27]  * Hobbsee pondered going thru it, but thought that having to find an archive admin to send it to !main made it not worht it.
[14:28] <rulus> hmm, how do I upload a file to appear under the 'Download project files' section?
[14:28] <Hobbsee> cprov: do i want to ask what happened that broke PPAs yesterday?
[14:29] <cprov> Hobbsee: no, you don't ;)
[14:29] <Hobbsee> cprov: yes i do.  please tell :)
[14:29]  * Hobbsee is curious
[14:29] <Hobbsee>  /query if you like
[14:30] <cprov> Hobbsee: ignorance is bless in this case, let's pretend it never happened, ok ?
[14:31] <Hobbsee> hehe, OK :)
[14:37] <BUGabundo> hi there
[14:37] <BUGabundo> how can I generate a po/pot file?
[15:35] <carlos> BUGabundo: hi
[15:35] <carlos> BUGabundo: is it for an application you are working on? or something else done by other developers?
[15:37] <BUGabundo> we are a team of developers, carlos
[15:38] <BUGabundo> and we are trying to use launchpad/roseta
[15:38] <BUGabundo> for translations...
[15:38] <carlos> BUGabundo: what do you use right now to handle translations?
[15:38] <BUGabundo> but before that, I guess I need to generate a pot file to upload to launchpad
[15:38] <carlos> or isn't your application able to be translated?
[15:38] <carlos> right, if you use gettext, that's easy, but then, I guess you would know how to get a .pot/.po file
[15:38] <BUGabundo> our strings right now are in Portuguese via a MySQL table
[15:39] <carlos> hmm, is your application a web application ?
[15:39] <BUGabundo> gettext? ok, I'll look it up on apt-get
[15:39] <BUGabundo> yes it is... and also a offline app
[15:39] <BUGabundo> the prolog part of it
[15:40] <carlos> BUGabundo: we have a requirement of having the source code available with a free/open software license
[15:40] <BUGabundo> check it out
[15:40] <BUGabundo> https://launchpad.net/easygate
[15:40] <carlos> BUGabundo: so you will need to release the web application code in that way if you want to use Launchpad
[15:41]  * carlos checks
[15:41] <BUGabundo> still working out the use of bazaar...
[15:41] <BUGabundo> some devs on windows other on ubuntu (gutsy and hardy)
[15:41] <carlos> BUGabundo: you don't really need to use gettext, but it would help you to handle imports/exports (and also, to handle all localisation parts of your application)
[15:42] <carlos> there are other projects that use a set of scripts
[15:42] <BUGabundo> so, if I dump the mysql table
[15:42] <carlos> to convert their own file format to/from .pot/.po file format
[15:42] <BUGabundo> then run gettext, ill get a pot file?
[15:43] <carlos> no, you will need to use your own script
[15:43] <carlos> gettext extracts strings from source code
[15:44] <BUGabundo> hummm
[15:44] <BUGabundo> that's going to be tuffer
[15:44] <carlos> but, AFAIK sql output is not handled
[15:44] <BUGabundo> since there is code in OpenGL, c#, c++, prolog
[15:44] <BUGabundo> lolol
[15:44] <BUGabundo> the mysql table already has the string, one per line
[15:44] <BUGabundo> * row
[15:45] <carlos> hmm, does openGL have its own language? I didn't know
[15:45] <BUGabundo> nope
[15:45] <carlos> anyway, C# and C++ are already handled by gettext
[15:45] <BUGabundo> we're using c++ for it
[15:45] <BUGabundo> ahh great
[15:45] <carlos> I'm not sure about prolog though
[15:46] <BUGabundo> as I said, prolog will interact with the mysql bd, and coded with c++
[15:47] <BUGabundo> maybe I can just make a small c# script to use the MySQL table and gettext
[15:48] <carlos> where do you have the message IDs used to get the strings from MySQL ?
[15:48] <carlos> in C# and C++ or also inside prolog code?
[15:48] <BUGabundo> c++ for the prolog UI
[15:48] <BUGabundo> and c3 for the website
[15:48] <BUGabundo> plus the OpenGL UI
[15:48] <carlos> think about source code
[15:49] <carlos> not about the front-end
[15:49] <BUGabundo> ok
[15:49] <carlos> gettext has a program that extract strings directly from your source code and an API to retrieve translations on run time
[15:49] <BUGabundo> I've never used gettex
[15:49] <BUGabundo> so I don't really know how it works
[15:50] <BUGabundo> and how does it exports the translation strings, so I can input them into the bd again?
[15:50] <carlos> don't worry, that's why I'm asking you so much to see whether it would help you or if it's not really useful, to see whether you just need a script to export/populate your database
[15:50] <carlos> oh, so you want your strings always in your database?
[15:50] <carlos> then gettext doesn't fit your use case
[15:51] <BUGabundo> humm
[15:51] <BUGabundo> ok
[15:51] <carlos> and thus, you will need a set of strings that generate the .po files from what you have in your database, and another script that gets a .po file and applies it to your database
[15:51] <BUGabundo> lets start from the beginning
[15:51] <BUGabundo> I already have some strings on the BD
[15:52] <BUGabundo> now I can dump them, and I need a away to get them on Launchpad
[15:52] <BUGabundo> so our dev plus a few other guess can help translate
[15:52] <BUGabundo> what's the format of the pot(po files?
[15:52] <carlos> BUGabundo: ok, so you will need to do it yourself with a script
[15:52] <BUGabundo> *pot/po
[15:53] <carlos> let me check for the file format description...
[15:54] <BUGabundo> thanks carlos
[15:56] <carlos> BUGabundo: http://www.gnu.org/software/gettext/manual/html_chapter/gettext_10.html#index-file-format_002c-_0040file_007b_002epo_007d-56
[15:56]  * BUGabundo opening site
[15:56] <carlos> BUGabundo: the only difference between a .pot and a .po file is that a .pot file doesn't have any translation
[15:57] <BUGabundo> ok, thanks
[15:57] <carlos> np
[15:59] <carlos> BUGabundo: I need to leave now, but as a hint, msgid should be the English text to be translated, that way translators have an easy way to see string changes and fix the translations. It's not a must, but that makes translators life more easy
[15:59] <carlos> BUGabundo: if you have any other question danilo or jordi would also help you a bit
[15:59] <BUGabundo> thanks a lot.
[15:59] <BUGabundo> I'll read that site and see what I can get out of it
[16:00] <carlos> ok, good luck :-)
[16:20] <ubotu> New bug: #182895 in rosetta "Add support for the new comment type in gettext #|" [Undecided,New] https://launchpad.net/bugs/182895
[16:25]  * Hobbsee wonders about how one goes about removing all their launchpad knowledge
[16:25] <oojah> Lobotomy?
[16:26] <Hobbsee> heh
[16:26] <BUGabundo> Hobbsee: dumps it on a DVD+r and then types sudo rm -rf /usr/local/launchpad
[16:26] <Hobbsee> maybe
[16:26] <Hobbsee> ah, right
[16:26] <Hobbsee> moving to debian would be another wya, i guess.
[16:27] <Hobbsee> or do stuff on other projects instead
[16:28]  * Hobbsee --> bed
[16:29] <BUGabundo> good nite Hobbsee
[16:39] <BUGabundo> how was lunch, salgado?
[16:39] <salgado> BUGabundo, delicious! :)
[16:40] <BUGabundo> ehehe
[16:40] <BUGabundo> anything good?
[16:54] <BUGabundo> hum that bad, enh, salgado?
[17:07] <salgado> BUGabundo, no, it was good. rice, beans, salad, chicken... the usual brazilian lunch
[17:08] <BUGabundo> eeheheh
[17:22] <doko> do uploads to ppa's curently work?
[17:25] <BUGabundo> look at the # sbject
[17:25] <BUGabundo> lolol
[17:25] <BUGabundo> it should...
[17:28] <mpt> salgado, you're making me hungry
[17:29] <BUGabundo> eheh mpt
[17:29] <BUGabundo> you should taste our Leitão (small pig)
[18:18] <jordi> kiko!
[18:32] <kiko> jordi!
[18:32] <kiko> wow, long time no see
[18:33] <jordi> yeah dude
[18:34] <jordi> how are things?
[18:38] <kiko> jordi, busy but great. was in israel for the end of the year, then spent a week in germany and prague, and am now back here
[18:38] <kiko> in london
[18:38] <kiko> wed I fly home
[18:45] <jordi> kiko: woa
[18:46] <jordi> kiko: dude I go to Germany/Prague/Budapest next week
[18:46] <jordi> any recommendations?
[18:48] <mpt> Goooooooooooooooooooooooooood evening Launchpadders!
[18:48] <kiko> EVEN1ng
[18:49] <kiko> jordi, wow, take lots of warm clothing
[18:49] <kiko> jordi, it's nice but freezing there
[18:50] <jordi> I can expect that
[18:50] <jordi> great
[18:50] <jordi> what did you do/see?
[18:52] <kiko> jordi, so, I went to the castle, and the jewish museum
[18:52] <jordi> how cold is freezing?
[18:52] <jordi> well below 0?
[18:53] <kiko> no!
[18:53] <kiko> but there was snow on the ground and it wasn't melting very fast!
[18:53] <jordi> ugh, snow
[18:54] <jordi> boots, then.
[19:30] <ubotu> New bug: #182948 in launchpad "Poppy daemon has no logging" [Undecided,New] https://launchpad.net/bugs/182948
[23:51] <ubotu> New bug: #183009 in malone "nomination listings on a bug page are odd" [Undecided,New] https://launchpad.net/bugs/183009