[03:52] <lifeless> bryceh_: hey, https://bugs.launchpad.net/launchpad/+bug/617695 seems either stalled or done, I can't tell.
[04:51] <tilgovi> anyone have experience with git-dpm?
[05:03] <twb> What provides /etc/mailcap ?  It's mentioning vim instead of vi, which is wrong for the vim-tiny that ubuntu-minimal pulls in.
[05:08] <geofft> twb: looks like mime-support
[05:08]  * twb digs
[05:08] <twb> Ah, "update-mime"; I was looking for "update-mailcap"
[05:08] <geofft> you may or may not be able to do something with update-mime? yeah
[05:09] <twb> OK, problem solved
[05:10] <twb> Broken file is /usr/lib/mime/packages/vim-common
[05:33] <twb> http://bugs.debian.org/654674 FYI
[06:29] <micahg> doko: all the gcc builds except for i386 look hung
[06:30] <doko> no, yellow usually takes 12h
[06:31] <micahg> ah, ok
[06:31] <doko> but we maybe can kill the snapshot build on powerpc, it will fail anyway
[06:47] <pitti> Good morning
[07:00] <bryceh_> lifeless, the code is finished and landed, but got feature flagged off so is unusable :-(
[07:10] <lifeless> bryceh_: why did that happen?
[07:14] <bryceh_> lifeless, I think curtis wanted to review the UI in more detail, but I think he's been tied up on other stuff
[07:16] <lifeless> nab him next week
[07:17] <StevenK> Even if the flag is only turned for a small team
[07:17] <bryceh_> lifeless, I had a follow on branch (https://code.launchpad.net/~bryce/launchpad/component-in-bug-filing-links) but it's kinda hard to test without having the config branch available so having it disabled stalled that work.
[07:18] <lifeless> I would say just turn it on, its new stuff not changes to existing UI, so might be horrible but unlikely to regress anything
[07:18] <lifeless> but, if sinzui wanted it off, I don't want to second guess him
[07:19] <bryceh_> lifeless, my hope was to get the bugtracker forwarding feature escalated on the stakeholder roadmap so I could get more active help at getting this done, but of course that hope's been dashed ;-)
[07:23] <bryceh_> lifeless, right, it's new UI in an out of the way corner I think few users go to, but for certain bugtrackers with lots of packages (e.g. gnome) it makes for a rather long list of links and buttons.  I'm sure curtis could think of a more attractive way to show it.
[07:25] <lifeless> perfect enemy good etc
[07:25] <lifeless> anyhow, nab him, and I'm sure he'll unblock it somewhat
[07:43] <bryceh_> lifeless, certainly.  In any case thanks for looking into it.
[07:55] <bryceh_> lifeless, I notice you've marked it down to low priority?
[07:55] <lifeless> bryceh_: I have to downgrade 900 bugs
[07:56] <lifeless> bryceh_: this reflects accurately the project opinion of the bug I think; you can of course hack on it yourself; and if you escalate it, its importance will increase (a lot :P)
[08:00] <bryceh_> lifeless, ...
[08:00] <lifeless> bryceh_: ?
[08:01] <bryceh_> lifeless, I've got my own separate tools for doing bug upstreaming for X.  Reason I've been working on this was because I understood it was functionality folks wanted to see integrated in launchpad itself.
[08:01] <lifeless> bryceh_: we do
[08:02] <lifeless> bryceh_: LP is *big*; fpr the 'high' category of bugs we want ~ 6 months work; with the changes happening thats about 1/4 what it was before
[08:03] <lifeless> bryceh_: if you think this thing is worth bumping a different one from, from the perspective of canonical sponsored work on LP, thats fine - just put it back to high, explain why, and I'll try to find something else to bump
[08:06] <lifeless> bryceh_: e.g. for remote bug tracker stuff, we have the following defects - offhand -
[08:06] <lifeless>  - archived debugs don't work
[08:06] <lifeless>  - savannah.nongnu.org doesn't work
[08:06] <lifeless>  - other instances od debugs don't work
[08:06] <lifeless>  - mantis doesn't work
[08:06] <lifeless>  - sourceforge doesn't work
[08:06] <bryceh_> lifeless, wow
[08:06] <lifeless>  - comment push cannot be disabled without disabling watches
[08:07] <lifeless> bryceh_: so I'm looking at a lot of bugs and making the best assessment I can; I will get it wrong - like I say above, if this is one of those cases, say so (in the bug please) and I will correct
[08:12] <bryceh_> lifeless, okay. Well this goes along with the bug forwarding feature, which has already been escalated.  I think there's little harm in  this bug waiting until that feature work bubbles back up in priorities.
[08:15] <lifeless> bryceh_: I think you should get the stuff done so far fully live, having inventory on the shelf sucks
[08:39] <bryceh_> lifeless, yes, I totally 100% agree
[08:40] <bryceh_> lifeless, I guess basically I've been stuck not knowing *how* to get it fully live.
[08:41] <bryceh_> lifeless, also btw since I'm merely a community guy now I don't have powers for setting launchpad bug priorities or anything fancy like that anymore
[08:42] <lifeless> bryceh_: so, getting it live - put a request on launchpadproductionstatus to turn the flag on
[08:42] <lifeless> bryceh_: unless sinzui asked you not to or whatever
[08:42] <lifeless> bryceh_: Would you like to be in ~canonical-launchpad-emeritus ?
[08:43] <bryceh_> lifeless, maybe?  I don't know what that is
[08:43] <lifeless> a group for ex-lp engineers that are still at cnaonical
[08:43] <lifeless> grants bugsupervisor
[08:43] <lifeless> will grant review etc when I figure out how not to spam the team
[08:44] <bryceh_> ok, sounds useful
[08:45] <lifeless> the presumption is you are still tacking the broad project so that this is useful :)
[08:45] <lifeless> right, you should have bugsupervisor now
[08:45] <bryceh_> lifeless, thanks
[08:46] <bryceh_> lifeless, ok past EOD for me, hopefully I can catch curtis next week.  I think it's going to be a busy week for me.
[08:48] <lifeless> likewise :)
[09:11] <micahg> jamespage: hi, I've got a build failure with a new java package that I'm not sure how to fix, I tried adding the build dependency it seems to want, but I get the same failure, the build works fine with network access (it must be downloading something) https://launchpad.net/~micahg/+archive/ftbfs-test/+build/3064946, this is needed for an FTBFS depwait in precise
[09:14] <jamespage> micahg: lemme take a look
[09:52] <jamespage> micahg: see http://paste.ubuntu.com/793582/
[09:52] <jamespage> basically it can't generate the javadoc because it can't find the artifacts it just built
[09:52] <micahg> ah, so I was still missing stuff
[09:53] <jamespage> micahg: well its a fault in the packaging really - it should use 'install' rather than 'package' to ensure that the jars are deployed into the local maven repository during the build process
[09:53] <micahg> jamespage: oh, is that it?
[09:54] <jamespage> micahg: setting DEB_MAVEN_BUILD_TARGET := install in debian rules should resolve the issue
[09:54] <micahg> jamespage: thanks!, will try that
[09:55] <jamespage> BTW I got that error message by building offline locally and then looking at the txt file that the error message refers to.
[09:55] <micahg> jamespage: BTW, is there a guide anywhere to fix Java FTBFS?
[09:55] <jamespage> micahg: nope
[09:55] <micahg> jamespage: do I still need the javadoc-plugin build dependency?
[09:58] <jamespage> micahg: I already see libmaven-javadoc-plugin-java as a build-dep in Debian? not sure why you had to add that...
[09:59] <micahg> jamespage: ah, indeed it is, I guess I couldn't see it when trying to fix this the first time at 3AM :)
[10:08] <frafu> Hi,
[10:08] <frafu> As you probably know, Onboard is the onscreen keyboard shipping by default with Ubuntu. We are considering porting it to python 3. Could anybody please tell me whether python 3 will be available on the Ubuntu 12.04 LiveCD? Could anybody please tell me whether there is any reason concerning Ubuntu to not port Onboard to python 3? Thanks in advance.
[10:13] <brendand> frafu - it will be there
[10:13] <brendand> as for reasons not to port it. ? maybe someone else has something to say
[10:14] <brendand> frafu - you can always check http://cdimage.ubuntu.com/daily-live/current/precise-desktop-i386.manifest for a package list
[10:17] <brendand> frafu - i guess you could find some required modules aren't yet ported to python3 i guess
[10:25] <frafu> brendand: Thanks for the reply and the link to the list with the packages of the current LiveCD. It will be useful to check whether the required dependencies are also available. If anybody sees a reason to not port it (assuming all dependencies are available on the LiveCD), please let me know.
[11:50] <iceroot> the contact for universe-packages is ubuntu-sponsors? or is that handled on a different way?
[11:53] <pitti> ubuntu-sponsors sponsors all components
[11:54] <iceroot> all? so i guess "main" is not called a component? or am i wrong?
[11:55] <geser> iceroot: "main" is a component but ubuntu-sponsors isn't limited on any specific component
[11:56] <pitti> iceroot: IOW, ubuntu-sponsors is fine for universe
[11:57] <iceroot> hm maybe not the right channel for that but i have sometimes the problem about putting the responsable team on cc on LP, so in universe i always choose sponsors, for the rest i am doing a depper search (like ubuntu-kernel-team, lubuntu-desktop)
[12:01] <Laney> You can use ubuntu-sponsors if you have something to be sponsored for any package, except security updates for which you should use ubuntu-security sponsors. That makes it appear on http://reports.qa.ubuntu.com/reports/sponsoring/.
[12:21] <iceroot> Laney: thank you for the info
[12:49] <TLE> pitti: hallo, since there are no language packs in the build queue: https://launchpad.net/ubuntu/oneiric/+builds?build_text=&build_state=pending&arch_tag=all I guess we are good to go for oneiric lang pack testing?
[12:49] <pitti> TLE: yes, since yesterday already
[12:50] <TLE> pitti: great thanks
[12:50] <pitti> TLE: will do the natty -updates copying now
[12:50] <TLE> pitti: great
[14:07] <pitti> cjwatson: our current i386 alternate now has both the pae and the regular kernel, which is why it exploded so much; seed error, or on purpose?
[14:07] <cjwatson> error
[14:08] <cjwatson> I think
[14:08] <cjwatson> I'll check and sort it out, thanks for the heads-up
[14:08] <pitti> thanks
[14:37] <Laney> how often does the sponsorship queue run?
[14:37] <Laney> (and when)
[14:37] <pitti> feels like every 20 minutes or so
[14:42] <Laney> k
[14:58] <pitti> seb128, cjwatson: FYI, http://people.canonical.com/~pitti/tmp/oneiric-precise2012-01-05-cdsize.txt is a cleaned up output of oneiric vs. today's precise amd64 CD size analysis
[14:58] <seb128> pitti, thanks
[14:58] <pitti> so 9.1 MB delta from package growth, 10 MB net delta from removed/added packages
[14:59] <pitti> adding python 3.2 is +5.9 MB, that's known
[14:59] <pitti> I'll check fonts-nanum, it was supposed to replace the old unfonts, but I don't see that on the removal list
[14:59] <seb128> pitti, I will look at the gtk2 one, I wonder if that's the "don't bzip the changelogs, news, etc" to workaround that gzip md5sum between archs bug
[15:00] <pitti> seb128: hm, hardly -- we don't even install most of those
[15:00] <seb128> but that seems a bit much to be that
[15:00] <pitti> seb128: but anyway, thanks
[15:00] <pitti> geoip-database (Δ 0.2 MB - 20110709-1: 3.3 MB   20111220-1: 3.5 MB)
[15:00] <pitti> that's an interesting growth
[15:00] <cjwatson> Is it?  Probably just more data?
[15:00] <pitti> I'll take the evince growth, too
[15:01] <pitti> cjwatson: haven't looked at it yet; but 200 kB -> 3.3 MB seems quite radical
[15:01] <pitti> could be that our previous package didn't actually ship any data or so :)
[15:01] <cjwatson> Uh, that output says 3.3 MB -> 3.5 MB.
[15:01] <pitti> argh, *headdesk*, of course
[15:01] <pitti> *blush*
[15:02] <pitti> I just phear the moment when Sweetshark uploads the new LibO :)
[15:03] <seb128> cjwatson, do you know if there is any chance gparted would go to gtk3 this cycle btw? it's keeping the gtk2 bindings on the CD, dropping those would win some space as well
[15:03] <pitti> seb128: the two libjavascriptcoregtk versions are probably a splitout from webkit? all the more reason to drop the gtk2 webkit
[15:04] <cjwatson> seb128: sorry, I don't know
[15:04] <seb128> cjwatson, no worry, I was just checking in case
[15:04] <cjwatson> I did file an upstream bug and upstream followed up a bit
[15:04] <cjwatson> I don't remember the current status though, you can probably check bugzilla as well as I can :)
[15:04] <seb128> cjwatson, yeah, I checked bugzilla, it's not very encouraging ;-)
[15:04] <cjwatson> (sorry, have so far done one out of five things planned for today ...)
[15:05] <seb128> cjwatson, I asked in case you had extra infos compared to what is in bugzilla
[15:05] <seb128> no worry
[15:05] <cjwatson> I don't, no
[15:05] <seb128> ok
[15:05] <seb128> pitti, no clue about libjavascriptcoregtk
[15:07] <pitti> seb128: rdepends of libwebkitgtk-1.0-0
[15:12] <pitti> cjwatson: I did a test install on my mini 10, and bcmwl fails; turns out that we only install l-headers-3.2.0-7-generic, not -pae; want me to fix the seeds, or do you want to?
[15:21] <cjwatson> pitti: I just did, independently :)
[15:21] <pitti> cjwatson: thanks
[15:25] <psusi> cjwatson: how's the workload?  just wandering if you'll have time to review my parted merge soonish ;)
[15:25] <cjwatson> psusi: Probably not this week I'm afraid
[15:26] <cjwatson> Remind me next week?
[15:26] <cjwatson> pitti: Oh god, -generic being on i386 images is a germinate bug
[15:26] <cjwatson> (Not the headers, but image and installer bits)
[15:27] <cjwatson> Kernel-Version isn't scoped properly
[15:33]  * cjwatson edits the warty seeds, as the only seeds relying on this germinate bug :-)
[15:33] <psusi> cjwatson: sure
[15:33] <pitti> cjwatson: ... in case we want to release 4.10.1 :)
[15:34] <pitti> "The Vintage Edition Release"
[15:35] <cjwatson> call it OCD ...
[15:39] <cjwatson> this bug goes back to germinate r25!
[15:39] <cjwatson> (currently at r470)
[15:41] <pitti> cjwatson: it affects package names where one is a prefix of another one?
[15:41] <pitti> probably not a very common case indeed
[15:41] <cjwatson> No
[15:41] <cjwatson>  * Kernel-Version: foo-generic
[15:42] <cjwatson>  * /^.*-modules-.*-di/ [amd64]
[15:42] <cjwatson>  * Kernel-Version: foo-generic-pae
[15:42] <cjwatson>  * /^.*-modules-.*-di/ [i386]
[15:42] <cjwatson> The Kernel-Version in force for the last line is in fact "foo-generic foo-generic-pae"
[15:42] <cjwatson> This is bogus
[15:50] <cjwatson> ... and this is truly painful to fix because germinate only keeps a record of that per-seed right now and indeed processes it long after it's forgotten exactly where in the seed it is
[15:55] <cjwatson> I may be able to bodge it
[16:28] <apw> cjwatson, am seeing a 'grep: input file '/boot/grub/grub.cfg.new' is also the output' for each grub menu update on P, known ?
[16:33] <cjwatson> apw: I did notice that but I haven't investigated it yet
[16:33] <apw> cjwatson, is there a bug, or shall i do the honours
[16:38] <cjwatson> I'm not up to date on grub2 bugs
[16:38] <cjwatson> feel free to file one, worst case I dup it
[16:38] <cjwatson> even better, fix it :)
[16:38] <apw> cjwatson, no worries, i'll do that
[16:41] <jibel> apw, bug 911225
[16:43] <apw> UpgradeStatus: Upgraded to precise on 2009-02-07 (1060 days ago)
[16:43] <apw> time traveling machine it seems
[16:43] <seb128> zul, slangasek: could you look at bug #911888 and make sure it doesn't get ignored? it seems a new issue with samba, we got 3 bugs about it this week
[16:49] <hallyn> jdstrand: on bug 912007, should I just add '/dev/dm* r' to /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper ?
[16:50] <zyga> has anyone seen james hunt recently?
[16:51] <jdstrand> hallyn: I have been thinking about that. I think it would be better to add deny rules like we do for /dev/mapper/ and /dev/sd*
[16:52] <jdstrand> hallyn: that will silence the non-fatal denial without giving away more access
[16:52] <stgraber> zyga: sure, though maybe you didn't notice he changed his nick for jodh
[16:52] <hallyn> grr, compiz keeps crashing
[16:52] <zyga> jodh, oh
[16:52] <zyga> stgraber, many thanks :)
[16:52] <zyga> stgraber, nice article about network interfaces btw :)
[16:52] <zyga> jodh, hi, do you have a minute?
[16:52] <hallyn> jdstrand: so adding the deny rule will stop the log msg?
[16:53] <stgraber> zyga: thanks!
[16:53] <jodh> zyga: hi
[16:53] <hallyn> i see - i missed the /dev/sd entry when i looked before.  makes sense.  thanks.
[16:53] <zyga> jodh, I'd like to get some advice from you on what a good "daemon/service" looks like upstart wise
[16:53] <jdstrand> hallyn: yes. apparmor is deny by default with logging. an explicit deny rule will deny without logging. 'audit deny' will deny and log again
[16:54] <zyga> I'm making some changes to celery (distributed queue for django and friends) and I'll be making sure celery plays nice with upstart
[16:54] <jodh> zyga: does this cover it? http://upstart.ubuntu.com/cookbook/#daemon-behaviour
[16:54] <zyga> is there anything I need to especially do to be "good" as a service from upstart's point of view?
[16:54] <zyga> let me check and get back to you
[16:54] <hallyn> jdstrand: now if only we had a working udd tree this is the kind of thing i'd queue up for the next upload.  but i'm afraid if i don't push this now i'll forget about it
[16:55] <hallyn> guess i need to just keep a list.
[16:55] <zyga> jodh, unrelated question, is 1.3 going to be backported to oneiric or is it just for precise+
[16:55] <hallyn> jdstrand: anyway i'll add that, thanks
[16:55] <jodh> zyga: we're on 1.4 now :)
[16:55] <jdstrand> hallyn: thanks!
[16:55] <zyga> I meant 1.4
[16:56] <zyga> especially the new features for process containment
[16:56] <jodh> zyga: I'm not aware of any current plan to do this.
[16:56] <zyga> ok, thanks
[16:57] <zyga> jodh, quickly looking at the link you provided I don't see any references to current working directory and logging
[16:58] <jodh> zyga: daemons are free to handle those particular attributes as they wish. Upstart provides the chdir+chroot stanzas. conventionally, daemons use syslog but if they want to speak to stdout/stderr they can as of Upstart 1.4.
[17:00] <slangasek> seb128: I defer to zul; I don't believe that samba 3.6.1 is releasable in general
[17:00] <seb128> slangasek, ok thanks
[17:04] <zyga> jodh, is it your recommendation that services daemonize themselves?
[17:36] <cjwatson> pitti,apw: linux-image-generic is ending up in there because linux Depends: linux-image Depends: linux-image-generic
[17:36] <cjwatson> pitti,apw: I think that linux-image should Depends: linux-image-generic-pae on i386 now; do you agree?
[17:38] <apw> cjwatson, does linux-image really still have a place, i had thought it was really a transitional package
[17:38] <apw> perhaps it is time for it to just go away
[17:39] <cjwatson> apw: It's definitely not a transitional package.  It was always a dependency-only package
[17:40] <cjwatson> Transitional packages are those which used to have real contents and are now dependency-only
[17:40] <cjwatson> I think we ought to change it anyway to help the upgrade path
[17:40] <apw> cjwatson, ahh i mean transition in the sense we used to use linux-image, then we got flavours so we added linux-image-<flavour> and those do the mappings
[17:40] <cjwatson> In fact it's probably the simplest way to get the upgrade path right
[17:40] <cjwatson> No, that isn't the cas
[17:40] <cjwatson> e
[17:41] <apw> if its meant to be the default flavour then it should point to -pae
[17:41] <cjwatson> We never had linux-image depending on a contentful kernel image package directly
[17:41] <cjwatson> The original semantics were that it was a per-architecture sensible choice of default if such a choice existed
[17:41] <apw> ok, then yes under that definition it should point to the recommended kernel
[17:42] <apw> cjwatson, shall i make that change happen?
[17:42] <cjwatson> yes please :)
[17:42] <apw> cjwatson, ack
[17:44] <cjwatson> pitti: http://bazaar.launchpad.net/~cjwatson/germinate/trunk/revision/471 *sweat*
[17:45] <apw> cjwatson, is there any tracking bugs for the generic generic-pae default change?
[17:47] <cjwatson> apw: bug
[17:47] <cjwatson> ere
[17:47] <cjwatson> apw: bug 897786
[17:49] <cjwatson> erk, cdimage is still using germinate 1.11
[17:53]  * cjwatson upgrades that and crosses his fingers
[17:59] <SpamapS> hmm.. is there something like apt-cacher-ng already in main?
[18:00] <SpamapS> juju makes use of it, but I don't want to Recommend: apt-cacher-ng if we can drop something else in.
[18:02] <apw> cjwatson, ok meta fixes are committed
[18:20] <RoAkSoAx> adam_g: yeah still failing
[18:23] <chrisccoulson> lamont, if i kill a PPA build, will it save the log for me? https://launchpad.net/~chrisccoulson/+archive/mozilla-test/+build/3070682 has progressed past the part of the build that i'm interested in, and don't really want to wait for the whole thing to finish
[18:23] <chrisccoulson> (but i do want to see the log)
[18:29] <RoAkSoAx> cjwatson: howdy... was just wondering if you've seen a grub-installer failure (for now in amd64) with error "main-menu[494]: (process:27699): Wrong number of args: mapdevfs <path>"
[18:29] <RoAkSoAx> cjwatson: full syslog: http://paste.ubuntu.com/794026/
[18:47] <slangasek> mvo: ping
[18:49] <cjwatson> RoAkSoAx: No, that's new to me.  I'll need a syslog of an installation run with DEBCONF_DEBUG=developer on the kernel command line.  (Make sure not to use a valuable password.)
[18:51] <mvo> slangasek: pong
[18:58] <RoAkSoAx> cjwatson: adam_g just filled Bug #912431
[18:58] <jtaylor> TheMuso: hi, have you spoken with the debian espeak maintainer about multiarching?
[18:59] <jtaylor> if we could get it multiarched there too we don't have to maintain a diff for espeakup
[19:26] <jtaylor> nevermind, we need a diff for the new pulse dep anyway
[19:40] <RoAkSoAx> cjwatson: ok, just posted the syslog with debcof debug output in lp bug #912431
[19:54] <apw> cjwatson, ok found the grub issue (the grep error I was seeing) and pushed up a branch for it, the other thing i've not looked at yet
[19:56] <lamont> chrisccoulson: let me go stab that build in a way that will give you a log
[19:56] <chrisccoulson> lamont, it's ok. it's finished now :)
[19:56] <lamont> chrisccoulson: actually, I see that it finished
[19:56]  * lamont was lunching with his daughter
[20:33] <TheMuso> jtaylor: I have access to the Debian git repo for espeak, and I put my work into the git repo for Debian.
[20:33] <TheMuso> jtaylor: Espeak is maintained by pkg-a11y, and I am on that team, so have access to their git repos on alioth.
[20:33] <jtaylor> TheMuso: so the same update planned to be done in debian soon too?
[20:34] <TheMuso> jtaylor: I can poke a member of the pkg-a11y team who is a DD to upload it if its urgent, otherwise it will be uploaded when one of them gets around to it.
[20:35] <TheMuso> I generally just do work on both our packaging and Debian's, and they haven't complained yet, so this seems to work well for us.
[20:38] <TheMuso> jtaylor: Oh for espeakup as well, I could get that into the git repo for you if you'd like.
[20:43] <jtaylor> I have no real connection with the package, I just fixed the last ftbs
[20:43] <jtaylor> and the new espeak upload breaks it again
[20:43] <TheMuso> Ah ok.
[20:44] <jtaylor> I'll just wait a bit for the update in debian
[20:44] <TheMuso> Do you have your work for espeak somewhere, i.e the changes needed to make it build again? If not, enver mind, I'll take a look myself.
[20:44] <jtaylor> one issue is the espeakup udeb, as espeak now needs pulse the udeb pulls in a nono-udeb
[20:45] <jtaylor> I'll upload a branch that fixes it in a moment
[20:47] <TheMuso> Ok.
[20:49] <semiosis> hi all, i've got a solution for an ubuntu-specific bug in a package we get from debian.  how can I go about contributing the fix to the ubuntu packaging?  it's really simple, just replacing an initscript with an upstart job.
[20:50] <semiosis> https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/876648
[20:50] <jtaylor> TheMuso: lp:~jtaylor/ubuntu/precise/espeakup/sync-and-fix-ftbs
[20:52] <jtaylor> TheMuso: and here the diff against debian: http://paste.ubuntu.com/794209/
[20:53] <arges> is there a wiki on how to create a backport of a package for testing? i have pbuilder-dist set up on my machine, but not sure if that's the right tool.
[20:53] <smoser> cjwatson, around ?
[20:54] <smoser> or anyone who would know what debug info i should collect for bug 912492
[20:54] <TheMuso> jtaylor: Thanks, will get that uploaded and into Debian for you today.
[20:54] <jtaylor> its not needed as long espeak is not update
[20:54] <jtaylor> also the pulse udeb issue should be checked
[20:55] <TheMuso> Ok.
[20:57] <broder> arges: you should check out backportpackage in ubuntu-dev-tools
[20:57] <TheMuso> jtaylor: Actually, I think there are grounds for not linking libespeak.a against pulse at all, since libespeak.a is statically linked against espeakup.
[20:58] <TheMuso> jtaylor: So I'll fix the espeak packaging so that pulse is only used in the shared lib.
[20:58] <TheMuso> And then adjust your espeakup diff accordingly and upload both.
[20:58] <arges> broder, awesome. i'll check that out
[20:59] <semiosis> can anyone point me in the right direction to contribute an ubuntu specific change to a package we import from debian?
[21:02] <micahg> semiosis: if you likes VCSs: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
[21:03] <semiosis> micahg: thank you! sure I like VCSs
[21:04] <semiosis> i'm basically already at "request merge" i just have no idea how to go about doing that.
[21:04] <micahg> ah, ok
[21:05] <semiosis> i have already contributed the fix to the upstream project, now its just a matter of updating the ubuntu packaging to use it (an ubuntu upstart job instead of the debian initscript)
[21:05] <semiosis> i even have a ppa with the fix already included :)
[21:05] <semiosis> after much testing, i think its ready for primetime
[21:05] <micahg> ah, so you just need the info at the bottom of that page then
[21:06] <semiosis> micahg: thanks so much I think i can have this done today :D
[21:07] <micahg> great!
[21:17] <chrisccoulson> hi cnd, you around?
[21:18] <cnd> chrisccoulson, yep
[21:18] <chrisccoulson> cnd - i've just restart my precise box after doing the first upgrade in a while, and noticed that edge scrolling no longer works on my touchpad
[21:19] <chrisccoulson> cnd - i have "2 finger scrolling" enabled in control center, which i think is the default. but, isn't it meant to fall back to edge scrolling when 2 finger isn't suported?
[21:19] <cnd> chrisccoulson, unfortunately, that's not the case
[21:19] <chrisccoulson> it doesn't seem to be doing that now (i have to actually select edge-scrolling in control-center to make it work)
[21:19] <chrisccoulson> oh?
[21:19] <cnd> IIRC, you can do both at the same time, if you twiddle with options in xinput
[21:19] <cnd> but the GTK configuration dialog doesn't allow that flexibility
[21:20] <cnd> it does exactly what it says
[21:20] <cnd> if you select two touch scrolling, it won't do edge scrolling
[21:20] <chrisccoulson> cnd - wasn't 2 finger scrolling enabled by default before though?
[21:21] <cnd> chrisccoulson, we looked into it
[21:21] <cnd> but the GTK configuration dialog was one reason we couldn't enable it by default out of the box
[21:21] <cnd> so it was put on the back burner
[21:22] <chrisccoulson> hmmm, i wonder what's changed then? i've had to manually enable edge scrolling now :/
[21:22] <chrisccoulson> maybe this is seb128's fault ;)
[21:22] <seb128> chrisccoulson, !!!
[21:22] <chrisccoulson> seb128, is it fixed yet???
[21:23] <seb128> lol
[21:23] <seb128> chrisccoulson, wait, you will see ;-)
[21:23] <chrisccoulson> heh
[21:25] <arges> broder, ok i'm getting the same result previously when just using pbuilder-dist and the .dsc.  It says it needs newer versions of  cdbs and debhelper.  Do I need to backport those packages first and use those? or is there a repo i can add?
[21:28] <broder> arges: usually the best thing to do in that case is figure out why the required versions of cdbs/debhelper are so high, modify the packaging so it doesn't need features from those versions, and then drop the build-dependency to whatever is in the release you're backporting to
[21:28] <broder> that's not something that can be automated
[21:33] <arges> broder, ok gotcha
[21:36] <cnd> chrisccoulson, I thought edge scrolling was the default, maybe upstream gtk changed it?
[21:45] <chrisccoulson> cnd, hmm, i'm confused now. it doesn't look like the default has changed
[22:01] <Daviey> Anyone else noticed mountall/upstart core dump on boot?
[22:02] <TheMuso> Daviey: Is this after the most recent mountall update? If so, not yet, as I haven't updated yet.
[22:02] <bryce> Daviey, nope, I just updated this morning.  I got several crash notices but not upstart or mountall
[22:03] <Daviey> there is NOW a pending mountall update which wasn't on my local mirror when i last updated :)
[22:03]  * Daviey tries it
[22:14] <slangasek> Daviey: ehm, that sounds rather serious - which process is the one doing the dumping?
[22:15] <smoser> has anyone seen bug 912492 ?
[22:15] <smoser> it does not seem system specific for me
[22:15] <hallyn> smoser: yeah adam_g reported the same bug
[22:16] <hallyn> smoser: bug 912431
[22:16] <Daviey> slangasek: I'm not exactly sure...
[22:17] <slangasek> Daviey: are you able to boot in spite of the crash?
[22:17] <Daviey> slangasek: i'm not exactly getting much data out.
[22:19] <smoser> i'd say thats critical as critical can get
[22:21] <Daviey> slangasek: only to rescue mode.
[22:23] <Daviey> slangasek: http://bootie.daviey.com/~dave/erk/
[22:23] <Daviey> i'm not /certain/ it's mountall, but did happen at the same time.
[22:24] <slangasek> Daviey: please try booting with --no-log added to the kernel commandline
[22:26] <Daviey> slangasek: to single user mode, or normal boot?\
[22:26] <slangasek> normal
[22:26] <Daviey> ok
[22:27] <slangasek> and after testing that way, you might want to delete /etc/udev/rules.d/86-hpmud-hp_laserjet_professional_p1566.rules...
[22:35] <slangasek> Daviey: so, that should've done the job; did it?
[22:40] <Daviey> slangasek: sorry for the slow RTT, yes - it got me to a functioning desktop
[22:40] <slangasek> ok
[22:41] <slangasek> please file a critical bug against upstart
[22:41] <Daviey> wilco
[23:14] <Daviey> slangasek: bug 912558
[23:15] <slangasek> pitti: has bug #901038 been reproduced by anyone else?
[23:16] <slangasek> pitti: the symptom is quite suspect; one doesn't get "upstart not running" on a 12.04 system...
[23:16] <slangasek> Daviey: thanks