[00:05] <barry> lifeless: bug 661508
[00:05] <_mup_> Bug #661508: code hosting doesn't handle looms <Loom:New> <Launchpad Bazaar Integration:New> <Ubuntu Distributed Development:New> <https://launchpad.net/bugs/661508>
[03:04] <LPCIBot> Project db-devel build (70): STILL FAILING in 3 hr 45 min: https://hudson.wedontsleep.org/job/db-devel/70/
[03:04] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11707,
[03:04] <LPCIBot> 11708, 11709 included.
[03:24] <LPCIBot> Project devel build (117): STILL FAILING in 3 hr 40 min: https://hudson.wedontsleep.org/job/devel/117/
[03:24] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=652134] Updates imported branches on
[03:24] <LPCIBot> products to display upstream information and present as
[03:24] <LPCIBot> EXTERNAL codehosting_usage.
[03:24] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=655567] Merge
[03:24] <LPCIBot> wire-up-filter-subs-bug-655567 into devel.
[03:24] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=652142] Fixes the message displayed to
[03:24] <LPCIBot> users on product code pages with no branches;
[03:24] <LPCIBot> previously users without configuration rights were told they could set
[03:24] <LPCIBot> things up when they couldn't.
[03:24] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=660873] The BugzillaAPI and LPPlugin
[03:24] <LPCIBot> ExternalBugTrackers will no longer OOPS when a Bugzilla doesn't
[03:24] <LPCIBot> return an alias for a bug.
[03:24] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][bug=660628] Make update-image work smoothly on Lucid
[06:55] <LPCIBot> Project db-devel build (71): STILL FAILING in 3 hr 50 min: https://hudson.wedontsleep.org/job/db-devel/71/
[06:55] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11710,
[06:55] <LPCIBot> 11711, 11712, 11713, 11714 included.
[07:22] <cody-somerville> What do folks think of function annotations in Python?
[08:25] <LPCIBot> Project db-devel build (72): STILL FAILING in 1 hr 30 min: https://hudson.wedontsleep.org/job/db-devel/72/
[08:25] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11715,
[08:25] <LPCIBot> 11716, 11717, 11718, 11719, 11720 included.
[10:05] <lifeless> cody-somerville: what do you mean?
[10:07] <cody-somerville> lifeless, Simply curious what folks think about it and its potential future use in the Launchpad codebase
[10:07] <lifeless> cody-somerville: I mean, 'what do you mean by 'function annotations in python'
[10:07] <lifeless> cody-somerville: I parsed the rest of the sentence ok :)
[10:08] <lifeless> but I can think of,oh, 3? more? things you could mean by function annotations in python
[10:08] <cody-somerville> I'm referring to PEP 3107, http://www.python.org/dev/peps/pep-3107/
[10:11] <lifeless> oh
[10:11] <lifeless> world of pain
[10:13] <nigelb> heh
[10:44] <jml> not having to worry about backwards compatibility is a beautiful thing
[10:46]  * wgrant looks around for someone to EC2 four branches.
[10:50] <jml> wgrant: hi
[10:51] <wgrant> jml: The first four on https://code.edge.launchpad.net/~wgrant/launchpad/+activereviews, if you could.
[10:52] <wgrant> The first has failed eight times now... so if it doesn't work this time, it surely must the next.
[10:53] <jml> :)
[11:00] <jml> wgrant: wheels are in motion, I'll let you know when they've all detached.
[11:01] <wgrant> jml: Thanks.
[11:01] <wgrant> Hopefully it won't hit that Windmill thread leak.
[11:15] <jml> wgrant: if it's just that, I'll submit directly to PQM
[11:15] <jml> two are running, two failed to initialize properly, restarting those
[11:15] <jml> also, I don't know how I'd live without XXX comments
[11:17] <wgrant> Oh?
[11:18] <jml> whenever I'm writing code, I think of things it could do, problems it has and paths that I'm not sure about
[11:18] <jml> I could either stare and dither for a while, or I could write a XXX comment and get on with it
[11:19] <wgrant> Ah, yes.
[11:19] <jml> turns a stack of interrupts into a queue
[11:19] <wgrant> I thought you were complaining about my branches.
[11:19] <jml> no, not at all
[11:19] <jml> I'm sneaking in some naughty work on my twisted testing support for testtools
[11:19] <jml> but now I'm going
[11:19] <wgrant> Heh.
[11:20] <wgrant> Thanks for sending those off.
[11:22] <jml> np
[18:07] <LPCIBot> Project devel build (118): STILL FAILING in 4 hr 12 min: https://hudson.wedontsleep.org/job/devel/118/
[19:01] <lifeless> jml: ping
[21:38] <LPCIBot> Project db-devel build (73): STILL FAILING in 4 hr 12 min: https://hudson.wedontsleep.org/job/db-devel/73/
[21:52] <LPCIBot> Project devel build (119): STILL FAILING in 3 hr 45 min: https://hudson.wedontsleep.org/job/devel/119/
[21:52] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][no-qa] Start de-duplicating the apt-ftparchive and
[21:52] <LPCIBot> native publishing tests, and add more thorough index generation tests.
[21:52] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac,
[21:52] <LPCIBot> stevenk][ui=none][bug=655648] test_ftparchive now works on maverick.
[21:52] <LPCIBot> - Landed by bac.
[21:52] <LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][bug=629921] Treat an empty PPA package name
[21:52] <LPCIBot> filter as if it were absent. - Landed by henninge.
[21:52] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=653122] BugSubscriptionSubscribeSelfView is
[21:53] <LPCIBot> now a LaunchpadFormView.
[22:04] <wgrant> jml: Thanks.
[22:04] <wgrant> jml: That testrunner failed without any failed tests thing just seems to appear sometimes.
[23:35] <lifeless> wgrant: is there a bug with a test run log file?
[23:37] <LPCIBot> Project parallel-test build (4): STILL FAILING in 1 hr 58 min: https://hudson.wedontsleep.org/job/parallel-test/4/
[23:38] <wgrant> lifeless: I don't know of one, but I may have missed it.
[23:38] <lifeless> oh wwow
[23:38]  * wgrant looks and files.
[23:38] <lifeless> canonical.testing.layers.LayerIsolationError: App server died in this test (status=241):
[23:39] <lifeless> lp.code.windmill.tests.test_branch_bugspeclinks.TestBranchBugLinks.test_inline_branch_bug_link_unlinkfirefox-bin: Fatal IO error 11 (Resource temporarily unavailable) on X server :99.0.
[23:39] <wgrant> Nice.
[23:39] <lifeless> WARNING: A test appears to be hung. There has been no output for 600 seconds.
[23:39] <lifeless> Forcibly shutting down the test suite
[23:39] <lifeless> Process group 6323 will be killed
[23:39] <lifeless> Sending signal 15 to process group 6323
[23:39] <lifeless> Sending signal 2 to process group 6323
[23:39] <lifeless> Sending signal 1 to process group 6323
[23:39] <lifeless> Sending signal 9 to process group 6323
[23:39] <lifeless> Process group 6323 is now empty.
[23:39] <wgrant> It gets violent quickly.
[23:40] <lifeless> I'm going backwards
[23:42] <wgrant> lifeless: Bug #661931
[23:42] <_mup_> Bug #661931: make check sometimes fails on EC2 without test failures <Launchpad Foundations:New> <https://launchpad.net/bugs/661931>
[23:42] <wgrant> Log attached.
[23:43] <lifeless> wgrant: bb failure
[23:43] <lifeless> wgrant: forwarded the bits to the list
[23:44] <lifeless> wgrant: thanks for the bug
[23:44] <wgrant> lifeless: The one that gmb just fixed by reverting his broken merge?
[23:45] <lifeless> wgrant: ah, he must have reverted it after I ec2landed my branch ><
[23:45] <wgrant> Yes, that one.
[23:45] <wgrant> He replied to the thread an hour or so ago.
[23:45] <wgrant> And it was reverted around 20 minuts ago.
[23:45] <lifeless> blah
[23:46] <lifeless> thanks
[23:46] <jml> fwiw, the exit code checker in remote.py could be removed if it's not helpful
[23:46] <jml> I kept it in there just in case
[23:46] <wgrant> Ah, hi jml.
[23:47] <wgrant> jml: Should I get that branch ec2'd again, or do we believe the subunit output?
[23:47] <jml> wgrant: hi
[23:47] <wgrant> One of the others that landed overnight had that same failure a couple of times last week.
[23:48] <jml> wgrant: what does the subunit output say?
[23:48] <wgrant> jml: No failures.
[23:48] <jml> hmm.
[23:48] <wgrant> Oh.
[23:49] <wgrant> There is a LayerIsolationError.
[23:49] <wgrant> I hate threads.
[23:50] <jml> hatred leads to anger, anger leads to twisted, twisted leads to awesome
[23:51] <wgrant> Heh.
[23:51] <wgrant> http://paste.ubuntu.com/514687/ is the error. I wonder if the same one appeared last week
[23:51]  * wgrant looks.
[23:51] <lifeless> wgrant: what thread did gmb comment in?
[23:51] <lifeless> wgrant: I canna see it
[23:52] <jml> I wonder why it didn't get recorded as a failed test
[23:52] <jml> wgrant: in any case, I'm too tired to judge sensibly about your branch.
[23:52] <wgrant> lifeless: The buildbot failure at Sat, 16 Oct 2010 22:38:21 +0100
[23:53] <wgrant> lifeless: The failure email and his reply went to both me and<EMAIL_ADDRESS>[23:53] <wgrant> His reply was slightly over an hour ago.
[23:57] <jml> g'night guys


[09:03] <SirDMZ> Ok, so i've built a new pbuilder and the kernel still FTBFS in that. http://pastebin.com/KAhXkKMF
[11:54] <karooga> Hi anyone familiar with vmebus?
[12:38] <zyga> hey, are the new 3.13-based kernels for precise and trusty being released via some fast track this time around?
[13:54] <zyga> bjf: hey
[13:54] <zyga> bjf: the man I wanted to talk to
[13:55] <bjf> zyga, what's up?
[14:13] <rtg> kamal, could you have a look at https://lists.ubuntu.com/archives/kernel-team/2014-July/046963.html ? it is affecting 3.13 stable.
[14:15] <kamal> rtg, ok, will do
[14:17] <rtg> kamal, it has regressed kirkland's orange box (if you need a tester)
[14:19] <kamal> rtg, ack.  looks like upstream has a fix in the works -- I'll see what we can do for 3.13-stable asap
[14:20] <rtg> kamal, I couldn't find the upstream patch in linux-next, so its still pretty green
[14:20] <kamal> rtg, yes
[15:03] <kirkland> kamal: rtg: yes, please I need that fix in trusty-updates ASAP, urgently
[15:03] <kirkland> kamal: rtg: I'm happy to test
[15:25] <rtg> apw, do you have patches for https://bugs.launchpad.net/bugs/1354397 ?
[15:26] <apw> rtg, ahh i am working on that one, slowly, as the list i have which is in another bug, fails to apply like at the first hurdle
[15:26] <rtg> apw, are they for Trusty or Utopic ?
[15:27] <apw> rtg, for trusty at least, i started on friday and flushed the context
[15:37] <rtg> smoser, do you have any reproducers for https://bugs.launchpad.net/bugs/1354459 ? Maybe we can get IBM to have a look.
[16:02] <smoser> rtg, it fails ~ 20% of time maybe
[16:02] <smoser> boot fails.
[16:02] <smoser> maybe only 10% .
[16:02] <rtg> smoser, just idling ?
[16:02] <smoser> well, boot is hardly idling
[16:03] <smoser> it doesnt make it up to the point where it is doing anything useful.
[16:03] <rtg> smyes, but otherwise
[16:03] <smoser> i think i've seen it fail both in d-i kernel and in iscsi remote root boot.
[16:04] <rtg> smoser, does it happen on more then one ? I think there are some OPAL version differences
[16:04] <smoser> i have onyl really tried doing install and such to one machine.
[16:04] <smoser> so my sample set is a bit small
[16:04] <rtg> infinity, ^^ have you seen any bare metal problems ?
[16:05] <rtg> smoser, we have a bunch of these machines, so I'm surprised the issue is not more widespread
[16:07] <infinity> rtg: No, but I don't do a lot of bare metal testing (yet).
[16:07] <rtg> infinity, ok, I thought we had.
[16:08] <infinity> rtg: We almost entirely run in VMs.  This needs to change, obviously.
[16:08] <infinity> rtg: And will change a bit as host LE KVM starts working, so we can run Ubuntu on Ubuntu.
[16:08] <rtg> infinity, do you anticipate installing more bare metal machines soon ?
[16:08] <rtg> when KVM starts working I assume
[16:09] <infinity> rtg: Over the coming weeks, perhaps.  It's not an urgency for me, yet, though it should be for the cert people pretty soon.
[16:09] <smoser> rtg, infinity it is important, its "supported" for maas.
[16:09] <infinity> rtg: But yes, once we have a working KVM solution, the plan would be to flatten all the machines we have and run Ubuntu on all of them.
[16:10] <smoser> and is not entirely un-useful either. u
[16:10] <smoser> it can be useful for lxc host.
[16:10] <smoser> to run ppc64el "bare metal".
[16:10] <infinity> smoser: Sure, it's useful for some usecases (whole machine use, or lxc), but neither of those is currently my use-case.
[16:10] <infinity> smoser: But my use-case should be getting fixed pretty soon.
[16:11] <smoser> infinity, you are not the only person ;)
[16:11] <infinity> smoser: I know I'm not, but Tim was asking if *I* do a lot of bare metal, and the answer is currently no.
[16:11] <infinity> smoser: Other people should definitely be testing it more.
[16:11] <infinity> smoser: And one of those people will soon be me.
[16:12] <rtg> smoser, have the cert folks started on bare metal yet ?
[16:12] <smoser> rtg, i believ they have started.
[16:58] <rtg> kamal, https://bugs.launchpad.net/bugs/1354469 looks like another 3.13 stable regression
[17:07] <apw> rtg, that is the driver update you did isn't it?
[17:08] <rtg> apw, a staging driver ? I don't remember that
[17:08] <rtg> lemme look again
[17:10] <rtg> apw,ah, it was ppisati
[17:10] <apw> nominally it was "us" at least
[17:19] <rtg> kamal, nm about bug #1354469. I found an upstream patch and have sent it to the k-team list.
[18:03] <kamal> rtg, but should I really never-mind?  that seems like a good candidate for 3.13-stable anyway, doesn't it?
[18:03] <rtg> kamal, I don't think those patches came in via stable, but I have not checked.
[18:04] <kamal> rtg, not tagged for stable, but sounds like maybe it should be
[18:04] <kamal> *have ben
[18:04] <kamal> *have been   (sigh)
[18:05] <rtg> kamal, IIRC the rtl8821ae patches were backports proposed by ppisati.
[18:06] <kamal> rtg, ok I'll take stock and bug him
[18:11] <rtg> kamal, just checked. there are no updates in your 3.13 stable for drivers/staging/rtl8821ae/rtl8821ae, so I'm sure this is not your problem.
[18:11] <kamal> rtg, excellent -- thanks!
[18:18] <retabell> just filled a bugreport
[18:18] <retabell> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1355318
[20:07] <zartoosh__> HI using ubuntu 14.04 I get this error. BUG: Bad page map in process sshd  pte:01000000 pmd:23ed32067
[20:11] <apw> zartoosh__, that would be unexpected, you should file a bug against linux when it occurs
[20:13] <zartoosh__> apw, thanks for your reply, should I file that against linux kernel, or ubuntu kernel. Please advise? thx
[20:14] <apw> ubuntu kernel in the first instance, if it proves to be upstream we can move it up then
[20:14] <apw> zartoosh__, file the bug and report the number here, as that sounds like something needing investigating
[20:19] <zartoosh__> apw thank you will do, last question:  that what number ?
[20:19] <apw> the bug numbre
[20:28] <zartoosh__> apw thank you.
[21:03] <henrix> ~/quit


[04:22] <pitti> Good morning
[07:06] <dholbach> good morning
[07:07] <shadeslayer> eeeppp
[07:08] <shadeslayer> dholbach: hi!
[07:08] <shadeslayer> cjwatson: DVD images for Kubuntu 12.04 are missing :(
[07:08] <shadeslayer> dholbach: could you review a sqlite transition diff?
[07:09] <dholbach> I'm not sure I'm an expert, but sure
[07:11] <shadeslayer> dholbach: http://paste.kde.org/538790/
[07:13] <dholbach> hum, how did it offer a -sqlite2 and -sqlite3 package before?
[07:14] <shadeslayer> dholbach: I don't understand ...
[07:14] <dholbach> ah no, nevermind
[07:16] <dholbach> hum, I do wonder though why we need libsqlite0-dev and libsqlite3-dev as build-deps
[07:17]  * shadeslayer checks logs
[07:18] <shadeslayer> dholbach: checking for SQLite 2 driver headers... /usr/include/
[07:19] <shadeslayer> seems like something requires it
[07:19] <dholbach> isn't that the plugin which is removed?
[07:19] <shadeslayer> that's from the old logs
[07:19] <dholbach> aha
[07:21] <shadeslayer> ( oh cool, linuxplumbersconf uses summit )
[07:25] <shadeslayer> oh, that's wrong ...
[07:25] <shadeslayer> dholbach: I assumed libsqlite-dev will pull in libsqlite3-dev
[07:25] <shadeslayer> so that'll need fixing in the control file
[07:26] <bkerensa> gnight folks!
[07:26] <dholbach> shadeslayer, I'm just doing a test-build without libsqlite0-dev
[07:26] <shadeslayer> right :)
[07:29] <dholbach> ah no, seems necessary
[07:30] <dholbach> dh_install: gambas2-gb-db-sqlite3 missing files (usr/lib/gambas2/gb.db.sqlite3.*), aborting
[07:30] <dholbach> weird
[07:30] <shadeslayer> indeed
[07:30] <shadeslayer> I was looking at the configure output myself
[07:30] <shadeslayer> and since I made it dep on libsqlite-dev, it worked ( since that pulls in libsqlite0-dev which the package picks up as sqlite3 )
[07:34] <shadeslayer> dholbach: gb.db.sqlite3/configure seems like magic
[07:38] <cjwatson> shadeslayer: on holiday and very shortly off-net - somebody else can work it out
[07:38] <shadeslayer> sure
[07:39] <shadeslayer> it seems like everyone who would know how to fix this is on a holiday :P
[11:40] <ev> @pilot in
[11:41] <Daviey> jelmer: hey, are there plans to fix debian bug 634848 ?
[11:42] <jelmer> Daviey: not that I'm aware of
[11:43] <jelmer> Daviey: (I'm not involved with python-debian upstream)
[11:43] <Daviey> jelmer: oh, sorry.. i thought you were
[12:08] <larsweb> i am trying to assign a group write-access to a folder using the "setfacl" tool. but it doesnt seem to work? does anyone know this?
[12:16] <xnox> larsweb: support is in #ubuntu or askubuntu.com this is developer channel =)
[12:22] <hyperair> this is weird. how does chromium-browser even build?
[12:23] <hyperair> it just bails out saying "tar: This does not look like a tar archive"
[12:24] <xnox> hyperair: which one? the one in the archive or the one from daily ppa?
[12:24] <xnox> the former crashes, the later ftbfs/out-of-date
[12:24] <xnox> s/later/latter/
[12:27] <hyperair> xnox: the archive one.
[12:27] <hyperair> chromium-browser-18.0.1025.168~r134367
[12:27] <hyperair> i don't even know how i have the binary installed -- i unpack it, there's a tarball inside the source directory, which is unpacked
[12:28] <hyperair> and then the debian/rules doesn't even attempt to unpack the tarball
[12:31] <hyperair> aha, it looks like i can force this to work by running debian/rules pre-build
[12:39] <xnox> hyperair: i'd expect you to use 20.0.1132.47~r144678-0ubuntu5 or is this for precise?
[13:37] <mterry> mvo, ping about https://code.launchpad.net/~mterry/update-manager/stop-update/+merge/120318  - I'd like to get it in this next week before UIF
[13:42] <mvo> mterry: sure, let me have a look
[13:49] <xnox> mvo: what's the best way to submit patches to debtagshw? debian BTS + CC you for review?
[13:50] <mvo> xnox: yeah
[13:51] <mvo> xnox: I can commit them to git
[13:51] <mvo> xnox: out of curiosity, what is the patch about?
[13:51] <xnox> mvo: python3 support
[13:52] <xnox> mvo: i need to add dep8 test runner and i will submit
[13:53] <mterry> mvo, we've got time before UIF for me to add a test
[13:53] <mterry> mvo, I'll try to do that if I fail for some reason, will merge to make UIF
[13:54] <mvo> mterry: cool
[13:54] <mvo> xnox: please note that I will need py2 support for s-c as it looks like xapian will not make it for py3
[13:55] <xnox> mvo: it supports both =)
[13:55] <mvo> xnox: sweet
[13:55] <xnox> mvo: 2.6 or better required including all the way through 3.X =)
[15:47] <Andy80> dholbach: hi! Maybe there is a typo here https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative or I'm just noob (more probable). I try to branch some packages and I always get the error that the branch doesn't exist. For example: bzr branch ubuntu:libboost1.46-dev
[15:47] <Andy80> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/libboost1.46-dev/".
[15:47] <dholbach> ah, that's a binary package name, not a source package name
[15:48] <dholbach> apt-cache showsrc <package>      should tell you which source package it belongs too
[15:48] <dholbach> good point
[15:49] <Andy80> dholbach: another possible problem.... even if you do: apt-cache showsrc libboost1.46-dev - you can get: W: Unable to locate package libboost1.46-dev
[15:50] <dholbach> are you on precise?
[15:50] <Andy80> dholbach: I suspect because that particular version is only available in quantal
[15:50] <Andy80> and not in precise
[15:50] <Andy80> yes
[15:50] <Andy80> do I need Quantal to fix those packages? If yes I can't do :(
[15:50] <dholbach> ah no, it should exist in precise too
[15:50] <Andy80> maybe with a different version
[15:50] <dholbach> ah, do you have a deb-src line enabled in /etc/apt/sources.lists?
[15:51] <dholbach> or in software-properties you need to check 'sources'
[15:51] <dholbach> otherwise apt only knows about binary packages :)
[15:51] <Andy80> let me check...
[15:51] <Andy80> good point
[15:52] <dholbach> I'll see if that's covered in our docs
[15:54] <dholbach> filed bug 1041256
[15:55] <Andy80> dholbach: ok, my fault... it was because of the sources not enable. Now I get a loooooong output for the command: apt-cache showsrc libboost1.46-dev
[15:55] <Andy80> which one is the line that I need?
[15:55] <dholbach> the first one
[15:55] <Andy80> cool
[15:56] <Andy80> yeah! It's branching :)
[15:57] <dholbach> fantastico :)
[15:57] <Andy80> at least I'm testing the whole procedure/howto ;)
[15:58] <Andy80> by the way nice job! It's exactly what we need to make people start contributing
[15:59] <dholbach> yeah, let's see how it goes :)
[16:03] <Andy80> ok now I feel even more stupid :D I can't find the typo in the debian/control ;) you say "libboost1.46-dev (binary): unused-override spelling-error-in-description" but there are many descriptions... and I cannot find the "unused-override"
[16:04] <dholbach> haha ok, sorry - my mistake (again)
[16:04] <dholbach> lintian finds mistakes in packages
[16:05] <dholbach> you can override some of the warnings with a lintian-override
[16:05] <dholbach> it seems in this case an override was added, but it's not needed
[16:06] <Andy80> I still don't get it... it's because I don't know this "lintian-override". Which line is "bugged" in this case? And how should it be?
[16:08] <dholbach> it's a bad example I picked for the list - basically it went like this: at some stage there was a mistake in the package, lintian complained, the maintainer felt it was not a problem, so they added an override, so lintian would not complain any more - it seems like this problem in the past is gone now
[16:08] <dholbach> so the override is not needed any more
[16:09] <dholbach> there's a line in debian/rules where the spelling-error-in-description override is added - that line can be safely removed
[16:09] <dholbach> Andy80, I'm afraid you picked one of the harder problems :)
[16:10] <dholbach> but I just checked - this line can be removed
[16:13] <dholbach> have a great weekend everyone
[16:13] <dholbach> and good luck Andy80 - I'm sure there are others in here who can help you out if you should get stuck
[16:13] <Andy80> dholbach: while you were checking the problem I worked and committed the second one https://code.launchpad.net/~andreagrandi/ubuntu/quantal/kdevelop-custom-buildsystem/typo-fix/+merge/121223 :D
[16:14] <dholbach> great
[16:14] <dholbach> see you around! :)
[16:14] <Andy80> yeah I keep going :) it's easy ;)
[16:18] <Andy80> arghh..... I always get the weird problems...
[16:18] <Andy80> I saw another typo after I ran bzr lp-propose
[16:19] <Andy80> and I tried to run it again and I get this: bzr: ERROR: There is already a branch merge proposal: https://code.launchpad.net/~andreagrandi/ubuntu/quantal/kdevelop-custom-buildsystem/typo-fix/+merge/121223
[16:21] <Andy80> oh it's ok now
[16:33] <SpamapS> so, as an nvidia user, do I just have to wait until Nvidia drops new drivers to dist-upgrade?
[16:33] <SpamapS> (in quantal)
[16:35] <xnox> Andy80: by the way, boost1.46 is superseeded by boost1.49 in quantal.
[16:36] <xnox> Andy80: 1.46 is pending removal in quantal.
[16:37] <Andy80> xnox: oh... well... just refuse the mp
[16:41] <Andy80> ok, dinner time, I'll continue it later
[16:46] <infinity> xnox: http://paste.ubuntu.com/1164755/
[16:54] <xnox> infinity: damn it!
[16:54] <xnox> infinity: I am off to give ben a kick
[16:55] <infinity> xnox: Did you miss having build-deps in the transition tracker?
[16:55] <infinity> xnox: Might make some sense, from the POV of possible ORed false positives, but in the above case, only two of those are ORed deps (and should be fixed anyway), and the rest aren't.
[16:56] <xnox> infinity: I was fixing some of these in Debian, where there are errorous build-deps on a "libboost1.42-dev | libboost-dev"
[16:56] <xnox> infinity: will adjust the tracker to make it right.
[16:57] <infinity> This could be why I never use trackers.
[16:57] <infinity> And just trust the archive to not lie to me when I ask it questions.
[16:57] <infinity> Questions like "yo, archive, does stuff still depend on this thing that I want to remove?"
[16:57] <infinity> And it's all like "dude, don't do it, you have so much to live for."
[16:58] <infinity> And it all goes downhill from there.
[16:58] <infinity> Until the archive and I share a case of beer and reminisce about old times.
[16:58]  * xnox is taking notes on effective AA
[17:20]  * xnox ponders how mumble ever manages to work at all
[17:23] <ogra_> it steals unicorns and pixie dust from btrfs
[17:23] <ogra_> thats why btrfs never gets finished btw
[17:27] <Debolaz> Of course, the real reason is that they have no goals.
[17:27] <ogra_> the unicorns ?
[17:28] <Debolaz> Yes.
[17:43]  * penguin42 notes that a unicorn as a goalee would be messy; it would always catch the ball on it's horn
[18:02] <xnox> infinity: you have now send me down the path of taking (!) patches from asterisk to fix (!!) zeroc-ice for (!!!) java7 compat to merge (!V) mumble to remove (V) boost.
[18:04] <micahg> xnox: welcome to being a core dev :)
[18:06] <infinity> xnox: It's not too late to remove yourself from the group.
[18:07] <ogra_> infinity, !
[18:23]  * xnox decisions decisions decisions
[18:48] <Andy80> what does this command exactly: bzr bd -- -S      ?
[18:50] <micahg> Andy80: builds a source package from a bzr branch
[18:50] <slangasek> Andy80: it creates a temporary bzr export of your current branch (including any uncommitted changes) to a temp directory in ../build-area, then invokes dpkg-buildpackage with any arguments after the -- (in this case, -S, which means "only do a source build")
[19:17] <Andy80> micahg, slangasek I found it in this contest https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative - so basically after I execute "bzr lp-propose" I also execute those two command to send the package to Debian, right?
[19:17] <slangasek> Andy80: what two commands?
[19:18] <slangasek> ah, bzr bd -- -S + submittodebian?  yes; the first is not actually part of sending it to Debian, it only verifies the source package can be built; you should also verify that your *binary* package builds before submitting to Debian
[19:19] <Andy80> yes
[19:19] <slangasek> Andy80: so I think you should run 'bzr bd' without the -S at all, here
[19:19] <Andy80> ah ok
[19:19] <Andy80> luckly I haven't sent it yet
[19:19] <Andy80> it's still building :(
[19:19] <Andy80> I'm on a slow netbook...
[19:21] <Andy80> and... that "submittodebian" does all work :P ? I mean the submitting...
[19:22] <slangasek> it automates as much of it as it can, then drops you into an editor so you can compose the bug report to Debian
[19:22] <pedahzur> hallyn: around?
[19:24] <Andy80> slangasek: it looks like something went wrong (executing: bzr bd) http://pastebin.com/Gtx9G835
[19:26] <pedahzur> soren: around?
[19:26] <slangasek> Andy80: yes; that command tries to build the package, and you need to have the build dependencies installed to build the package
[19:27] <slangasek> Andy80: let me have a closer look at that wiki page; maybe I'm sending you down a wrong path
[19:27] <Andy80> slangasek: yeah, I understand the missing deps, but... wasn't there a method to automatically install all the deps before building the package?
[19:27] <slangasek> Andy80: have you gone through http://developer.ubuntu.com/packaging/html/getting-set-up.html ?
[19:27] <slangasek> i.e.: have you set up pbuilder?
[19:28] <Andy80> I should have..... let me check (I don't remember if I did it on this netbook or on the office PC)
[19:28] <slangasek> Andy80: so you should be able to run 'bzr bd --builder=pdebuild'
[19:28] <slangasek> and that should take care of the dependencies for you
[19:30] <Andy80> slangasek: ok it looks like I didn't run pbuilder-dist. On my office PC it was ok, here I get this: andrea@andrea-1215P:~/Documents/sviluppo/Ubuntu/gambas2$ pbuilder-dist pangolin create
[19:30] <Andy80> Warning: Unknown distribution "pangolin". Do you want to continue [y|N]? n
[19:30] <slangasek> pangolin isn't the distribution name; the name is 'precise'
[19:31] <Andy80> oh sorry -.-
[19:31] <Andy80> how I'm stupid -.-
[19:32] <Andy80> ok... it's getting stuff ;)
[19:33] <hallyn> pedahzur: what's up?
[19:33] <Andy80> so I'll run 'bzr bd --builder=pdebuild' and it will build the package for "precise"
[19:33] <slangasek> Andy80: I believe that's correct
[19:35] <pedahzur> hallyn: I added the PPA from https://launchpad.net/~ubuntu-virt/+archive/backports, but trying to upgrade qemu-kvm tells me seabios and vgabios are too old.  Did I do something stupid, or do I need to raise a bug to have seabios and vgabios backported as well?
[19:35] <pedahzur> hallyn: Sorry if I got the wrong channel to discuss this. Will happily move it if I need to.
[19:37] <hallyn> pedahzur: d'oh, if i created that then yes i should have backported those too.  i'll do that.
[19:37] <pedahzur> hallyn: Ah...OK...my sanity *is* in tact. :)
[19:37] <pedahzur> hallyn: Shall I raise a bug, or is that needed?
[19:39] <hallyn> pedahzur: no need.  thanks for bringing it up!
[19:40] <xnox> Andy80: although it's a pain, I do $ bzr bd -S; and then use pbuilder-dist $series build $package.dsc
[19:40] <pedahzur> hallyn: you're welcome. Thanks for responding quickly!
[19:40] <slangasek> xnox: however, 'bzr bd -S' can also fail due to missing build-dependencies
[19:40] <slangasek> as you probably know :)
[19:40] <xnox> Andy80: because with pdebuild a package can escape and nuke stuff in your home dir =/
[19:40] <slangasek> orly
[19:41] <xnox> slangasek: pdebuild builds source package locally, so it can also fail ;-)
[19:41] <slangasek> ah
[19:41] <slangasek> silly thing
[19:41] <slangasek> right, so we should scrap all references to pbuilder in the guide and replace them with sbuild immediately ;)
[19:43] <Andy80> xnox: so if I already have the .dsc, I do: pbuilder-dist precise build gambas2_2.23.1-1ubuntu6.dsc
[19:43] <Andy80> ?
[19:43] <slangasek> yep
[19:44] <Andy80> let's try...
[19:45] <Andy80> and it will get the deps automatically?
[19:45] <jbicha> sbuild wasn't too difficult to set up
[19:45] <xnox> slangasek: sbuild can also operate on the unpacked tree & escape *gasp*
[19:45] <Andy80> yes it's getting...
[19:45] <xnox> slangasek: clearly we should switch to yum & RPM
[19:45] <xnox> ;-)
[19:46] <slangasek> xnox: what packages are you building that you haven't already audited debian/rules on to make sure they don't rm -rf ~ ? :)
[19:46] <slangasek> you can certainly configure schroot to not bind-mount things you're worried about, if that's the issue
[19:47] <xnox> slangasek: not sure, there were some funny onces with<EMAIL_ADDRESS>in the change-by field. Do you know who that is?
[19:47] <slangasek> xnox: a dastardly rogue
[19:48] <xnox> slangasek: i think I got bitten by modifying packaging & adding patches.... only to have the build-dir purged and loosing my changes.
[19:48] <xnox> nothing too serious.
[19:49] <hallyn> pedahzur: I just blindly pushed them without a local build first (dependencies looked innocent).  They *should* build fine in a few mins
[19:49] <pedahzur> hallyn: seabios is already there...wow...that was fast!
[19:53] <slangasek> xnox: ah :)
[19:54] <pedahzur> hallyn: I see the packages listed now...do you know how long does it take to update the packages indexes?  Even after 'update' apt is still complaining.
[19:55] <pedahzur> (impatient, aren't I?)  :)
[19:57] <SpamapS> hm, why would quantal's argparse.py be different from debian unstable's?
[19:58] <SpamapS> http://paste.ubuntu.com/1165051/
[20:01] <slangasek> SpamapS: possibly because later versions of the package in Debian sid are including pulls of the release branch from the upstream VCS
[20:02] <xnox> sbuild-build-depends-lo-menubar-dummy : Depends: libboo-dev but it is not installable
[20:02] <xnox> boo sbuild boo =)
[20:02] <xnox> s/libboo/libboost/
[20:04] <hallyn> pedahzur: unfortunately the ppas are lower priority for the builders than the archive.  (naturally)
[20:04] <hallyn> i'd expect 20 mins or so, but some days it can be hours
[20:05] <pedahzur> hallyn: Ah...just because it's listed doesn't mean it's built. Gotcha.
[20:05] <pedahzur> hallyn: but it is here: http://ppa.launchpad.net/ubuntu-virt/backports/ubuntu/ :)
[20:05] <pedahzur> But not yet listed in http://ppa.launchpad.net/ubuntu-virt/backports/ubuntu/dists/precise/main/binary-amd64/Packages  Weird.
[20:06] <SpamapS> slangasek: ah, ok, well it seems horribly broken in sid
[20:06] <hallyn> i need to reboot into q for a test.  bbl
[20:06] <pedahzur> hallyn: So I take it the builders "sweep" the pools to generate the package indexes?
[20:06] <slangasek> SpamapS: probably warrants an RC bug against the package?
[20:07] <infinity> pedahzur: Err, there's only source there, not binaries.
[20:07] <pedahzur> hallyn: Ah!  The sources are in place, not the debs.
[20:07] <infinity> pedahzur: But I'll give the builds a bit of a bump.
[20:07] <pedahzur> hallyn: Yeah, sorry...was reading too fast when I was looking at pools.
[20:07] <pedahzur> hallyn: Again: thank you very much!  I'll be sure to bug you if seabios and vgabios have unresolved dependencies. :)
[20:08] <pedahzur> hallyn: Wow, they have no install-time deps...that simplifies things.
[20:49] <xnox> a package fails due to -fpermissive.... while using gcc-4.7?!
[21:03] <pedahzur> hallyn: Packages built, and they are installed. And there's the 1920x1080 screen option I was after in Windows. Thank you so very much!  It is greatly appreciated!
[21:21] <hallyn> pedahzur: this was in relation to an open bug, right?  can you comment on it so i can act on the email?  (i assume this means i get to find a patch to cherrypick that fix whatever was broken)
[21:22] <pedahzur> The version of vgabios installed did not have the 1920x1080 mode defined.  I had not opened a bug for it.  There *might* be an open bug for it.
[21:23] <pedahzur> hallyn: ^^
[21:23] <hallyn> ah.  yeah, rings a bell
[21:23] <hallyn> ok.  thanks.
[21:23] <hallyn> ttyl


[12:50] <Capum321> hello
[12:50] <Capum321> what is gtk? does lxde run on gtk?
[12:52] <hateball> !gtk
[12:53] <leszek> Capum321: yes lxde applications are mostly using GTK
[17:04] <Sertou> Good day. Just installed Lubuntu 16.10 and have run into a small problem: clicking and holding down a menu while dragging down to a command doesn’t work.
[17:05] <Sertou> Clicking and releasing the menu to pop down the menu, then clicking the menu item works
[17:05] <Sertou> Clicking and releasing the menu to pop down the menu, then clicking the menu item works
[17:05] <Sertou> Clicking and releasing the menu to pop down the menu, then clicking the menu item works.
[17:05] <Sertou> whoa, sorry for the spam
[17:06] <Sertou> Has anyone run into this and maybe solved it?
[17:08] <Sertou> crickets... Ok, thanks. Have a good one.
[18:53] <Capum321> hello
[18:57] <Capum321> whats a good featured GUI for tesseract, one could recommend to me? some are listed here https://github.com/tesseract-ocr/tesseract/wiki/User-Projects-%E2%80%93-3rdParty but i don't know of them
[18:58] <genii> !info yagf
[19:00] <Capum321> genii are you familiar with it?
[19:01] <genii> I used it maybe 4-5 years ago but not since
[19:01] <Capum321> is it up to date?
[19:03] <genii> If it was that far out of date it would have already been removed from the repositories as an abandoned program with no maintainer
[19:09] <Capum321> i see
[19:27] <dust> at the software updater if u open details console output is bugges
[21:42] <chalmondley> I don't know how this works or what an irc channel is but....has anyone found their windows partition just stops working?
[22:04] <casa> hi everyone
[22:04] <casa> I'm using Lubuntu
[22:05] <casa> I want to meet a OS programmer (not only Unix and Linux)
[22:05] <casa> I want to collaborate with programmer for make original sounds
[22:06] <casa> I compose and produce somethings for opensource programs
[22:06] <casa> but I want to know a programmer for OS...maybe here there aren't OS programmer
[22:06] <casa> ?!?
[22:07] <casa> btw I really love Lubuntu and I'm trying to install to every friend I have xD it is difficult but slowly everyone will use Lubuntu or Ubuntu OS
[22:08] <casa> I hope I find someone interested in this way..for music and originale sound design
[22:08] <casa> I'm always here...my email is<EMAIL_ADDRESS>[22:08] <casa> on skype: jacopotore
[22:09] <casa> hope to find someone...really love Art and Computer <3
[22:12] <krytarik> casa: #lubuntu-devel and the corresponding mailing list (http://lists.ubuntu.com/lubuntu-devel) would be a better place for this.
[22:13] <casa> really?
[22:13] <casa> Thank you so much
[22:13] <krytarik> This is user support.
[22:13] <casa> xD ok
[22:13] <casa> sorry
[22:13] <krytarik> No problem.


[03:01] <salim> Anyone has an idea on the wireless display issue?
[06:03] <garybot> hello Ubuntu :]
[14:41] <kotof> hi
[15:51] <leaftype> I keep trying to get the M10 FHD to reflash, and it fails on waiting to renter recovery mode
[15:52] <leaftype> The device boots to system recovery, but the desktop never sees this
[15:56] <dobey> leaftype: are you using the correct recovery.img file when flashing with ubuntu-device-flash?
[15:56] <leaftype> dobey, I was using the recommended channel: ubuntu-device-flash touch --channel=ubuntu-touch/stable/bq-aquaris-pd.en --bootstrap
[15:57] <leaftype> teh channel I found from https://wiki.ubuntu.com/Touch/ReleaseNotes/OTA-14
[15:57] <dobey> leaftype: the factory recovery is locked. you need the recovery image from https://wiki.ubuntu.com/Touch/Devices#Working_with_ubuntu-device-flash
[15:57] <dobey> the recovery-frieza.img for M10 FHD, and you have to pass it to ubuntu-device-flash with --recovery-image arg
[15:59] <leaftype> alright, thanks. So ubuntu-device-flash --recovery-image ~/Downloads/revovery-frieza.img ?
[16:00] <dobey> yes
[16:00] <dobey> along with the other args for flashing the device, at the same time
[16:05] <leaftype> sweet, it's getting further than before. BTW, why does it still require the channel in the command to work, if it's using an image?
[16:07] <dobey> the recovery isn't the system image, it's just for the recovery to enable flashing
[16:07] <dobey> to enable adb in recovery to flash
[16:10] <leaftype> ah, thanks! This lets me give an answer on askubuntu as well :)
[16:15] <brunch875> guys, where does the ubuntu touch development discussion happen? Such as interface decisions... is it posible to spectate those?
[16:17] <leaftype> woo! brand new fresh install working :D
[16:19] <brunch875> good job, leaftype!
[16:25] <pmcgowan> brunch875, you mean snap interfaces?
[16:28] <brunch875> pmcgowan: I'm just wondering where the developers debate how they're going to implement snap, among other things. The mailing list I'm on has anouncements mixed with a lot of "I'm leaving ubuntu" whine.
[16:29] <pmcgowan> brunch875, there is a snapcraft mailing list where this mainly happens
[16:29] <pmcgowan> and in the PRs on github
[16:29] <pmcgowan> and on #snappy
[16:30] <brunch875> thanks!
[16:30] <brunch875> is there anything else not just exclusive to snappy, but for the ubuntu phone in general?
[16:32] <dobey> brunch875: you can watch MPs on unity8 and various projects i guess.
[16:32] <pmcgowan> brunch875, there is nothing else, we likely need to do a better job of informing that mailing list of the snap work, but the updates from sil2100 cover much of it
[16:32] <dobey> brunch875: for the large part of it, we're mostly "just do it" rather than a lot of discussion about it
[16:32] <brunch875> ah, I see!
[16:32] <pmcgowan> also true
[16:33] <dobey> there's a lot of work that needs to be done, and we know the general direction, so a lot of it is just fixing things to align with that and work in the snap world
[16:33] <brunch875> just what I needed, thanks! :)
[16:34] <dobey> i suppoise once we have a decently functioning u8 snap on top of ubuntu-core snap on x86, we'll start working on how to get the android bits working under that and flashable onto a device of some sort
[16:35] <brunch875> convergence sounds pretty close!
[16:35] <brunch875> exciting times
[16:38] <nhaines> dobey: I have interpreted "a device of some kind" as "my Nexus 7" and have emailed OMGUbuntu with the appropriate incindiary headline.  :)
[16:43] <dobey> i'm pretty sure there is no way that snaps will ever be flashed onto my nexus 7 :)
[16:43] <dobey> can't even flash current ubuntu images onto it, and android on it is even horrible
[16:46] <nhaines> dobey: OTA-14 (and the last rc-proposed updates) were pretty pleasant.
[16:47] <dobey> nhaines: 2012 n7 is not
[16:48] <nhaines> dobey: oh, no, of course not.  I was thinking the 2013 n7.
[16:49] <brunch875> the whole "android bits" bother me to no end. If only installing ubuntu was like on the pc...
[16:51] <nhaines> brunch875: yes, well, the unfortunate result of ARM's lack of standardization.  :)
[16:51] <brunch875> Are there no efforts to fix this issue?
[16:53] <dobey> brunch875: get a fairphone i guess?
[16:55] <nhaines> brunch875: there cannot be: most of the hardware used in commercial phones have no source drivers.
[16:55] <brunch875> is the fairphone more flashing-friendly?
[16:55] <brunch875> oof, so expensive
[16:56] <dobey> the fairphone i think is supposed to have all open source drivers or something, so theoretically it could be run without the android bits
[16:57] <dobey> but i could be wrong on that
[16:57] <brunch875> I'm definitely getting one of those then
[16:57] <dobey> ubports has a fairphone2 port
[16:58] <dobey> would probably be a good place to start with figuring things out, but really, the short answer is no. google probably has enough clout to do it, but they don't seem to want to either
[17:01] <brunch875> I wish the european union did something about this... buying a new phone to upgrade the linux kernel sounds insane to me
[17:03] <nhaines> brunch875: you wish the EU to require all hardware manufacturers to develop and release open source Linux drivers for their hardware?
[17:03] <brunch875> well, at some point; yes.
[17:04] <brunch875> I want a rampage in Stallman's name, but the current situation is bad
[17:04] <brunch875> I don't want a rampage*
[17:29] <nhaines> brunch875: I could live with such a rampage.  :)
[18:05] <dobey> nhaines, brunch875: well, it will certainly be interesting to see how the law suit against d-link pans out
[18:06] <brunch875> dobey: could you link me about this?
[18:07] <brunch875> what d-link lawsuit?
[18:07] <dobey> https://www.consumer.ftc.gov/blog/ftc-sues-d-link-over-router-and-camera-security-flaws
[18:08] <brunch875> thanks


[02:50]  * ASUS-tek cheers
[02:51]  * ASUS-tek good morning every one from south Asia and visvera to others :P


[00:04] <gamerchick02> howdy all. who's upgraded to 13.10 i've not yet but i will next week.
[00:27] <jrwren> i did, but just my home server.
[00:31] <greg-g> I did a dist-upgrade on my debian unstable machines, does that count? :P
[00:33] <jrwren> i dunno, did they make a release recently which would make unstable more unstable?
[00:40] <ColonelPanic001> Shhh.


[05:49] <mlankhorst> oh seems that aaronp took notice of that patch breaking optimus on nvidia drivers
[05:53] <mlankhorst> and has some patches too, nice
[11:06] <darkxst> hey, will the new pointer barrier events (in libxi) be landing in Saucy?
[11:26] <mlankhorst> darkxst: yeah but it depends on xserver 1.14 landing first
[11:27] <darkxst> mlankhorst, oh of course, forgot for a moment my X is from staging...
[11:28] <mlankhorst> :-)
[11:31] <mlankhorst> darkxst: just grab the libxi from staging, it's a bit of a problem atm because precise will eventually have to support both
[11:32] <darkxst> mlankhorst, oh I have xi from staging, but barriers are not working
[11:33] <mlankhorst> do you have xfixes from staging too?
[11:34] <darkxst> yes
[11:34] <mlankhorst> odd, it should work on 1.14
[11:34] <darkxst> maybe I need to rebuild mutter against those though
[11:35] <tjaalton> the problem is unity though, we need to be careful not breaking it while pushing new crap in saucy :)
[11:36] <darkxst> tjaalton, sure understand.
[11:36] <mlankhorst> tjaalton: and the problem in precise is going to be even more fun to solve
[11:39] <darkxst> ah yes, rebuild against staging packages fixes it
[11:39] <mlankhorst> :-)
[11:50] <tjaalton> mlankhorst: oh yeah :/
[11:50] <mlankhorst> I want to talk to some unity devs, I was thinking of doing a mean trick to support both api's in 1 program
[11:52] <darkxst> mlankhorst, why not backport the new barriers? they are much nicer than the old ones
[11:52] <tjaalton> darkxst: problem is it breaks unity
[11:52] <tjaalton> which depends on the old api
[11:52] <tjaalton> so it needs to be fixed to somehow support both
[11:52] <mlankhorst> darkxst: because backporting something from the input stack is not trivial
[11:53] <tjaalton> the staging ppa has a version that supports only the new api
[11:54] <darkxst> so I guess there is more to it than just the barriers then?
[11:55] <mlankhorst> it's done at a different level
[11:55] <tjaalton> that's enough to break things :)
[12:02] <darkxst> yeh I don't follow the X stack that closely, but I have seen both the barrier patches in Xfixes
[12:08] <mlankhorst> darkxst: yeah the new one is also in libXI though
[12:09] <darkxst> yeh I know the events come from XI
[12:09] <mlankhorst> if it was easy to backport I may have done so for raring :)
[20:55] <jcristau> Sarvatt: care to add a line about #628758 to mesa:debian-experimental's changelog so it gets closed on upload? :)
[20:56] <Sarvatt> jcristau: was just about to push that :)
[20:56] <jcristau> great
[20:56] <jcristau> thanks
[21:15] <Sarvatt> oh eww, silly me thought it was like launchpad and bugs go under the source package name making http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mesa;dist=unstable a really small list, but the motherload is filed under libgl1-mesa-dri :)
[21:21] <jcristau> Sarvatt: bugs.debian.org/src:mesa should be the full list
[21:22] <jcristau> (or, replace pkg=mesa with src=mesa in your url)
[21:22] <Sarvatt> oh thanks, that helps a lot
[21:26] <jcristau> Sarvatt: oh, also<EMAIL_ADDRESS>doesn't reach the submitter, you need to cc them explicitly
[21:27] <jcristau> (yes, that sucks)
[21:47] <Sarvatt> jcristau: ahhh heck, I'm making a mess of the bugs, sorry about that :)
[21:47] <Sarvatt> didn't realize you guys shipped /etc/drirc, when i brought it up when it first got added everyone was opposed to it :)
[21:49] <jcristau> no worries
[21:57] <Sarvatt> fix never got cherry-picked to 8.0 branch
[21:58]  * Sarvatt switches to mutt to do anything on bugs.debian.org from now on, gmail is a nightmare with it :)