[00:44] <bdmurray> @pilot out
[06:43] <pitti> Good morning
[06:58] <Noskcaj> pitti, Would you mind giving me a motu testimony? https://wiki.ubuntu.com/Noskcaj#MOTU
[06:59] <pitti> barry: https://jenkins.qa.ubuntu.com/job/trusty-adt-system-image/16/? \o/
[07:00] <pitti> barry: the new test looks great, just what a package/integration test should be
[07:00] <pitti> barry: i. e. let the unit test handle the fine details during package build, and at integration time just make sure that your packages ship everything that they need and the main use case works
[07:57] <dholbach> good morning
[08:55] <soren> hallyn_: No clue, sorry.
[10:53] <evfool> hey seb128
[11:03] <seb128> evfool, hey
[11:03] <evfool> seb128: glad to see that GTK 3.10 will land in 14.04, and that some app updates might also land, wanted to know whether there's any other criteria for an app to be updated beside NOT HAVING headerbars
[11:04] <seb128> evfool, well, no real defined criteria, just "it's a LTS cycle, please be careful/don't get crazy"
[11:05] <seb128> do you have anything specific in mind?
[11:05] <evfool> seb128: in the context of system monitor we had minor UI tweaks+headerbar support, but I would be trying to add a compile option to compile without headerbar support (with standard menubar), and would like to know whether that'd be fine
[11:05] <seb128> evfool, yes, that would be great
[11:06] <Laney> you can detect it at runtime
[11:06] <seb128> we just need the app to not look so different from everything else
[11:06] <seb128> evfool, right, runtime might be better
[11:06] <Laney> https://wiki.gnome.org/HowDoI/AlternateMenubarLayout
[11:06] <seb128> so gnome-shell user can get the headerbar
[11:07] <evfool> seb128: ok, right then, I'll go with Laney's advice and do that
[11:07] <seb128> and the app still looking 'normal' under other desktops
[11:07] <seb128> evfool, excellent, thanks!
[11:07] <Laney> rocking, nice one
[14:31] <sergiusens> wgrant, hey, ubuntu:lxc-android-config seems to be out of sync, I've been forwarded to you; is there anything we can do about it?
[14:32] <sergiusens> jamespage, hey, in case you were wondering. wrt to my golang issue yesterday; it was actually a bug in dh-golang; I've logged a bug and a simple patch upstream
[14:33] <wgrant> sergiusens: http://package-import.ubuntu.com/status/lxc-android-config.html#2013-10-24%2002:27:29.212426 suggests that the changelog is corrupt
[14:33] <wgrant> It could probably ignore that, except it crashes because the warning code can't handle non-ASCII characters...
[14:36] <wgrant> It would possibly work if I hacked udd to just suppress all warnings from debian.changelog, but I'm not sure if that would have unforeseen consequences.
[14:37] <hallyn_> hm, a boot with !quiet !splash seemed to show 2 precious seconds in a 8 (now 10) second boot were spent 'scanning for btrfs filesystems'
[14:37] <sergiusens> wgrant, we can get barry to port that to python3 :-)
[14:38] <sergiusens> wgrant, let me see if I can fix that warning in the changelog whatever it is
[14:39] <wgrant> sergiusens: Possibly, but it might be looking at a changelog in an old version of the package
[14:39] <wgrant> I don't have time to look right now, I'm afraid.
[14:39] <sergiusens> ack, I'll just use plain sources for now then
[14:39] <sergiusens> thanks anyways
[14:47] <xnox> hallyn_: right, at the moment if you have btrfs-tools installed, it gets copied into initramfs unconditionally (even if there are no btrfs pools attached to the system / it boots off non-btrfs)
[14:53] <hallyn_> xnox: yuck.  if i'm not booting from btrfs, seems like something that could get pushed back to mountall...
[14:57] <xnox> hallyn_: override / purge / dpkg-divert the btrfs-tools initramfs hooks.
[14:58] <jamespage> sergiusens, excellent
[14:58] <jamespage> sergiusens, have you done any from scratch packaging using dh-golang yet? I have some stuff to work on this cycle but in the new year
[15:00] <sergiusens> jamespage, yes actually,I've packaged gocheck; it's in debian new; I also have a packaging branch for usensord (our sensors interface for touch) under review
[15:00] <jamespage> sergiusens, excellent!
[15:00] <jamespage> sergiusens, I'm due to break out some of the bundled source dependencies from juju
[15:01] <sergiusens> jamespage, well, the good thing is that it's not that hard to package :-)
[15:01] <jamespage> sergiusens, does dh-golang actually build anything? or does it just package up the source code
[15:01]  * jamespage has not looked in detail yet
[15:03] <sergiusens> jamespage, it builds main packages
[15:04] <sergiusens> jamespage, for packages it just sets up a by convention /usr/share/gocode GOPATH and installs there
[15:04] <jamespage> right
[15:05] <sergiusens> convention is, for those packages just append the -dev
[15:05] <hallyn_> xnox: well that box (the only one that boots fast anyway) doesn't actually have any btrfs, so i had just wantd the manpages once :)
[15:05] <xnox> hallyn_: purge it & use manpages from manpages.ubuntu.com (there  is even a command line utility to fetch / read manpages from there)
[15:06] <xnox> ... with added bonus of choosing which release to read the manpage for.
[15:06] <sergiusens> jamespage, there's already a couple of packaging branches you can use to inspire yourself http://anonscm.debian.org/gitweb/?a=project_list;pf=pkg-go/packages
[15:07] <sergiusens> jamespage, and the general convention which is a light read: https://wiki.debian.org/MichaelStapelberg/GoPackaging
[15:27] <pitti> slangasek, stgraber, xnox: I updated https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming with cking's summaries
[15:27] <pitti> slangasek, stgraber, xnox: so I think on the phone we all agree that "discard" is the way to go
[15:28] <pitti> slangasek, stgraber, xnox: what's your feeling on the desktop? I still tend towards the cron job, but I'm happy to see that "discard" is not as bad a performance eater as I feared
[15:29] <stgraber> pitti: yep. I think I already have a branch for it somewhere, just need to push it I guess :)
[15:29] <pitti> stgraber: a branch for what?
[15:29] <stgraber> pitti: discard on phone
[15:29] <pitti> stgraber: oh, right, nevermind
[15:29] <pitti> [stgraber] modify phone initramfs-tools to apply discard option: TODO
[15:29] <xnox> stgraber:  pitti: ok, i have a branch for mountall that fixes remounting if options are different, but it needs fixing. so if you want to enable it on touch now, do it in the initramfs-tools-ubuntu-touch by manually specifying that option.
[15:30] <pitti> xnox: it's not urgent enough to warrant temporary workarounds on the phone which will be obsolete soon, IMHO
[15:30] <stgraber> xnox: yeah, my plan was to do it directly at initial mount in the initrd
[15:30] <xnox> stgraber: good.
[15:30] <hallyn_> xnox: i don't like using a browser when i don't have to :)
[15:31] <hallyn_> is there a scope for manpages.u.c?
[15:31] <pitti> stgraber, xnox, slangasek: so I guess I'll go write that cron job now, as we want that either way
[15:31] <xnox> hallyn_: there is a cli util to fetch & man -l the manpage.
[15:31] <xnox> hallyn_: no idea about scopes.
[15:32] <pitti> slangasek: oh, and once we have a decision, BP approval would be nice (or some comment what's still missing); TIA!
[15:32] <stgraber> pitti: so my main concern about using fstrim is small SSDs but I guess if we run it daily it may be fine
[15:34] <stgraber> pitti: I actually had the case yesterday where I accidently filled my mediacenter's SSD twice when copying some stuff around (32GB SSD but playing with 1080p movies...)
[15:36] <pitti> wgrant: oh! https://translations.launchpad.net/ubuntu/trusty/+language-packs
[15:36] <pitti> wgrant: thanks
[15:36] <pitti> seb128: ^ FYI
[15:36] <infinity> pitti: Didn't cking have all sorts of benchmarks and numbers about trim and discard?
[15:36] <seb128> pitti, great!
[15:36] <pitti> infinity: right; as I said I just put his conclusions into the BP
[15:37] <infinity> pitti: Oh, heh, I didn't read far enough back. ;)
[15:37] <davidcalle> hallyn: not sure if it's what you are looking for, but if you have the manpages package installed, try searching the Dash for "manpages:dpkg"
[15:37] <infinity> pitti: If discard is the right answer on phones, why wouldn't it be on desktops?  What's the reasoning there?
[15:38] <pitti> infinity: desktops usually have much bigger hard drives, and you are much more likely to create and remove lots of files there
[15:38] <hallyn_> davidcalle: ah, interesting, thanks.  now, it would be better if it also searched manpages.ubuntu.com :)
[15:38] <hallyn_> (and if 'man:' was a shortcut :)
[15:38] <infinity> davidcalle: That really needs... What hallyn_ just said.
[15:39] <infinity> davidcalle: The "man: as a shortcut" bit, not the remote search bit.
[15:39] <infinity> (Though the latter might also be neat)
[15:40] <infinity> Then again, "Ctrl-Alt-T ; man dpkg" is actually faster, since the silly GUI man reader is slow.
[15:40] <hallyn_> rbasak: is your next uvtool upload also going to fix launching apport every time an xception is raised bc you use a bad cmdline arg?
[15:40] <hallyn_> infinity: agreed
[15:40] <davidcalle> I know... hallyn_, infinity, the keyword issue can be fixed manually in the config file (/usr/share/unity/scopes/code/manpages.scope)
[15:41] <hallyn_> infinity: the conv started because i said i installed btrfs-tools to ge tthe manpages, so i thought the scope might search manpages.u.c...  *there* the scope woudl e faster than launching a browser or installing the pkg :)
[15:41] <infinity> hallyn_: Yeahp, indeed.  The remote search would be handy.
[15:41] <hallyn_> infinity: except, of course, for the fact that you have to hit ctrl-alt-t 2 or 3 times to get it to work :)
[15:41] <infinity> hallyn_: I... Do?
[15:41] <rbasak> hallyn_: I'd love to know how to fix that.
[15:41] <infinity> Works fine here.
[15:42] <davidcalle> hallyn_, good point. Now, waiting for someone to provide an API for manpages.u.c ;)
[15:42] <hallyn_> infinity: not on any of my laptops
[15:42] <infinity> hallyn_: Weird.  It's my most typed sequence of keys here, I'd know if it was goofy for me.
[15:42] <infinity> hallyn_: Your laptops hate you.
[15:42] <hallyn_> infinity: true.  all hw hates me.
[15:42] <infinity> hallyn_: Oh.  But do you still have Alt bound to the HUD?
[15:42] <hallyn_> no, windows
[15:43] <hallyn_> rbasak: i bet stgraber knows how
[15:43] <rbasak> hallyn_: bug 1245641. Perhaps s/whoopsie/apport/.
[15:43] <infinity> hallyn_: That's one of the few non-stock things I do, I relocate the HUD shortcut to something I never use (F12, I think?), so it doesn't abuse my Alt.
[15:43] <hallyn_> oh, hud
[15:43] <hallyn_> right
[15:43] <hallyn_> infinity: lemme try that, thanks!
[15:44] <hallyn_> yup, that's definately better
[15:44] <hallyn_> course my laptops still hate me, now they'll just catch on fire to spite me
[15:49] <hallyn_> rbasak: BUT, i'm creating and desroying vms with uvt-kvm.  this is a good start :)  now i need to get it running on precise.
[15:52] <wgrant> pitti: Oh, that finally worked. A pleasant surprise.
[15:52] <rbasak> hallyn_: it's in the cloud-tools pocket. My latest upload fails the test suite because the test I'm using is too new for Precise. I need to fix it. But you could disable tests, I suppose. I probably should make nocheck work as well :-/
[15:54] <stgraber> @pilot in
[15:56] <hallyn_> rbasak: i'd recommend making '-l ubuntu' the default for uvt-kvm ssh
[15:56] <rbasak> hallyn_: I'd never considered that, but it sounds reasonable - thanks.
[15:57] <mitya57> barry: re jquery-* packages that coverage depends on: I think it may make sense to file a MIR for them.
[15:58] <mitya57> barry: nose now also dep-waits on them, and fails to build without them (debian #726695)
[15:58] <mitya57> what do you think?
[16:01] <barry> mitya57: yeah, looks like that probably makes sense.  would you be able to do that?
[16:01] <barry> (file the MIR that is)
[16:02] <mitya57> barry: can't file it right now, but will do
[16:02] <mitya57> in fact, those jquery plugins are already in main as part of our current coverage tarball
[16:02] <barry> mitya57: awesome, thanks.  are you planning to do a sync for python-coverage from sid also?
[16:03] <mitya57> barry: I'm not sure if we can drop the Breaks:
[16:03] <barry> mitya57: s/sync/merge/ ? :)
[16:04] <mitya57> Yes :)
[16:04] <mitya57> But it'll be in sync again after trusty release
[16:04]  * barry nods
[16:04] <barry> mitya57: if you're planning on doing it, i'll just wait for the mp :)
[16:06] <mitya57> barry: actually, I looked again at the changelog and it seems we don't need the breaks
[16:06] <mitya57> it was added because python-coverage used to ship python3 module
[16:06] <mitya57> but the precise version is python2-only
[16:07] <mitya57> ... and we don't support upgrades from q/r to t
[16:07] <barry> mitya57: is that the only delta we carry?
[16:08]  * barry is in a meeting and can't look right
[16:08] <barry> now
[16:09] <mitya57> barry: last time I checked I decided that jquery stuff and breaks: were the only delta
[16:09] <mitya57> But I'll check that again before filing a sync request
[16:09] <barry> mitya57: thanks!
[16:09] <mitya57> you are welcome :)
[16:15] <brendand> i'm having a weird issue with tagging bugs via launchpadlib
[16:16] <brendand> if i get a bug via one of its subtasks then i can't update its tags and save it
[16:16] <brendand> if i get it directly via lp.bugs then it works
[16:19] <doko> barry, reportlab is ready for 3.x upstream. needs a bit of messaging, and maybe packaging from a separate source for now. but should be ready later this year or in January
[16:19] <cjwatson> brendand: Sounds like bug 254901.
[16:20] <barry> doko: fantastic news, thanks!
[16:21] <brendand> cjwatson, i saw that one before :) but this isn't it
[16:21] <brendand> cjwatson, lets say i have a task
[16:21] <brendand> cjwatson, that task has a .bug attribute
[16:22] <brendand> cjwatson, that is the parent bug
[16:22] <cjwatson> if it isn't that bug then I don't know sorry
[16:23] <brendand> cjwatson, if i update the tags like 'bug = task.bug; bug.tags = bug.tags + ['new']; bug.lp_save()' then it doesn't add that tag in launchpad
[16:23] <cjwatson> sometimes foo = lp.load(foo.self_link) is needed for odd reasons I generally don't bother to track down :)
[16:23] <brendand> cjwatson, maybe
[16:24] <brendand> cjwatson, i think i have a workaround anyway. but i'll try that
[16:31] <tedg> jodh, Is there any way to set multiple environment variables at once using the Upstart DBus interface?
[16:31] <tedg> Seems that setenv can only do one at a time.
[16:31] <jodh> tedg: limited to 1 at a time atm, but feel free to raise a bug request :)
[16:32] <tedg> jodh, Heh, okay.  Let me see if switching from shelling out initctl to using DBus saves me enough time.
[16:41] <seb128> bdmurray, hey, I just uploaded https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=webkit, I would appreciate a review if you can get it in today ... that should fix s-c being very unstable/hitting Xerrors
[16:41] <bdmurray> seb128: okay.  I was looking at your software-properties-gtk merge proposal yesterday and commented on it
[16:42] <seb128> bdmurray, I saw, thanks for that
[16:42] <seb128> I think mvo still wanted to understand how those packages could have no candidate
[16:42] <seb128> I didn't manage to end up in that situation
[16:42] <seb128> e.g I tried installing a driver from restricted and drop the source
[16:42] <bdmurray> What I was suggesting was that with a fresh install all packages will have no candidate.
[16:42] <seb128> but you still get a candidate for the locally installed version in those cases
[16:43] <bdmurray> As apt-get update hasn't been run.  Well a fresh install with no internet connectivity.
[16:43] <seb128> well, you have no candidate but you wouldn't have drivers listed in the Ui either then
[16:43] <seb128> that bug happens when a driver is listed and has no candidate
[16:43] <seb128> didrocks suggested it might be people e.g installing nvidia drivers from the nvidia run install script
[16:43] <seb128> e.g out of the packaging system
[16:44] <seb128> but I couldn't test that, they installer checks for hardware and bails out if you have an nvidia card matching the driver
[16:44] <mdeslaur> xnox: mind if I steal your php5 merge?
[16:45] <bdmurray> seb128: I could query the crashdb to see if all of the instances have an origin of unknown if that would help
[16:47] <bdmurray> hmm, those four instances I've looked at have wl in NonfreeKernelModules
[16:47] <seb128> bdmurray, they don't, I've been through a few on https://errors.ubuntu.com/problem/55c1babf9ec1556365267f9ae7de740aec64d777 ... a good part have, but that doesn't seem the only case where it happens
[16:48] <seb128> bdmurray, see e.g https://errors.ubuntu.com/oops/5a0f326a-62e4-11e3-86e6-e4115b0f8a4a
[16:48] <bdmurray> well okay, if you need more information just let me know
[16:49] <xnox> mdeslaur: yes please, go ahead.
[16:49] <seb128> bdmurray, will do, thanks
[16:50] <seb128> bdmurray, if you have any idea what might happen to trigger the issue/manage to reproduce it, it would be useful
[16:50] <seb128> bdmurray, mvo wanted a sources.list and apt info from somebody having the bug to understand it
[16:50] <seb128> the patch I made should stop the reports but wouldn't fix the underlining reasons
[17:09] <pitti> stgraber, xnox: I think http://people.canonical.com/~pitti/scripts/fstrim now checks everything we agreed to in the discussion, and I tested it with various scenarios
[17:09] <pitti> review/comments appreciated!
[17:11] <xnox> pitti: what's the plan for lvm/mdadm? should i be enabling trim on those by default as well? but then fstrim script above will ignore them?
[17:12] <pitti> xnox: why will it ignore them?
[17:12] <pitti> xnox: ah right, due to hdparm
[17:13] <pitti> xnox: I'll investigate this tomorrow; if fstrim can "look through" them, then all is well (but we need to ignore "not supported" errors from it); otherwise I wouldn't know how to call fstrim on those
[17:13] <pitti> xnox: I certainly hope that fstrim works on those
[17:13] <pitti> (or discard)
[17:13] <pitti> so, experimenting with this is interesting indeed
[17:14] <xnox> pitti: i believe there is lvm2.conf option to enable trim support and then one can trim volumes and it propagates, or some such.
[17:15] <xnox> pitti: why libgirepository1.0-dev depends on gobject-introspection package? and why is libgirepository1.0-dev is not multiarch-arch same?
[17:15] <pitti> xnox: GI is currnetly not multiarch capable
[17:16] <pitti> to make that, /usr/lib/girepository-1.0/ would need to be moved to the <arch> directory, and libgirepository be taught about that
[17:16] <pitti> xnox: as for the dependency, I'm not sure
[17:16] <pitti> xnox: doesn't look immediately necessary, I just don't know how many packages rely on having the g-ir-compiler etc. being pulled in through it
[17:16] <pitti> xnox: as usually you need the tools as well
[17:18] <xnox> pitti: right, but at the moment i can install libgirepository-dev (and or compile/link against it) for a single arch at the time, sans installing gojbect-introspection (or installing it for other architectures)
[17:18] <xnox> pitti: or have it installed when I don't require / planning to run gobject-introspection at all.
[17:18] <xnox> this is blocking cross-building & bootstrapping. I'll look into what fallout this may cause, and look into transitioning.
[17:19] <xnox> pitti: as usually if something is using tools from gobject-introspection, it should be directly depending on it (per policy) instead of relying on transitive dependencies.
[17:19] <pitti> xnox: i. e. gobject-introspection should be M-A: foreign
[17:19] <xnox> pitti: that is also true.
[17:20] <xnox> pitti: (despite not yet being able to do cross-arch introspection, but it's ok)
[17:20] <xnox> we know it's broken, but at least it should be installable.
[17:20] <pitti> xnox: well, the tools ought to work for a foreign architecture
[17:20] <pitti> it's the library which needs its lookup paths adjusted to multiarch
[17:20] <xnox> i believe last time cjwatson was looking into this, they didn't.
[17:21] <pitti> xnox: oh, because they wouldn't find the right libgirepository-1.0-1
[17:22] <xnox> pitti: for now, i've dropped bogus dependency on libgirepository-dev and i'm unblocked =) this can be revisitted later.
[17:23] <pitti> xnox: ack
[17:24] <seb128> xnox, do you plan to fwd those accounttservice changes to Debian?
[17:24] <xnox> seb128: yes
[17:24] <seb128> good
[17:24] <seb128> xnox, thanks
[17:24] <xnox> seb128: btw why are we at -0ubuntuX ?
[17:24] <pitti> xnox: actually, if we drop the static lib, the only thing which is arch specific in -dev is the pkgconfig
[17:24] <pitti> xnox: and multi-arching that ought to be rather easy
[17:25] <seb128> xnox, because our upstream version is newer than the one in debian?
[17:25] <xnox> seb128: ah, horum. yeah i see.
[17:32] <cjwatson> pitti: AFAIK gobject-introspection needs to (a) be converted to use AC_COMPUTE_INT and friends to get type sizes on the target architecture (b) be treated somewhat like pkg-config - that is, you need a version of g-i built for your host arch but aimed at a different target arch
[17:32] <cjwatson> or like a cross-compiler I suppose
[17:32] <cjwatson> it's not at all trivial sadly
[17:33] <cjwatson> the tools will produce wrong answers for a foreign architecture right now, or at least would last time I looked
[17:36] <dobey> cjwatson: hey! are you a reasonable person to poke about extras.ubuntu.com? it doesn't have trusty archives yet, and so do-release-upgrade bails on the index files not being available from what i can tell
[17:37] <cjwatson> no
[17:37] <cjwatson> IIRC it's managed by the app review board
[17:38] <dobey> ah ok
[17:43] <tarpman> dobey: bug 1244050 (and bdmurray's comment there)
[17:45] <dobey> right
[17:46] <dobey> tarpman: which doesn't help me immediately. and there are still two separate issues
[17:48] <slangasek> the ARB is defunct in practice; I don't believe we're going to see extras.u.c in trusty, which reduces the number of issues to 1
[17:48] <slangasek> (i.e., having do-release-upgrade not care)
[17:53] <xnox> slangasek: i think last time we've tricked highvoltage into copying a package into a new pocket and removing, to get the indexes generated for the new codename, but obviously not have any packages published.
[17:53] <slangasek> yes; but there's no reason we should do that if it's defunct
[17:54] <xnox> cjwatson: the linaro anaylysis seems to say that output can be made architecture agnostic, and that it is the same if the register widths are the same (sans couple of issues e.g. gl vs gles)
[17:54] <xnox> cjwatson: https://wiki.linaro.org/PeterPearse/GobjectIntrospection
[17:54] <xnox> cjwatson: i'd rather introspection data become arch:all then building cross-gir-scanners
[17:55] <slangasek> "if the register widths are the same"?
[17:55] <xnox> slangasek: between HOST and BUILD arches.
[17:55] <slangasek> what madness is masked by that innocent conditional?
[17:55] <slangasek> ok, but what's a "register width"?
[17:55] <xnox> slangasek: i'm quoting https://wiki.linaro.org/PeterPearse/GobjectIntrospection
[17:56] <slangasek> so I would assume that means word size
[17:56] <xnox> slangasek: i'm guessing that i386 gir/types files happened to be same as on armel, sans gl/gles.
[17:56] <cjwatson> xnox: I'm not sure I was ever convinced by Peter's analysis, and I did mine after his
[17:56] <slangasek> which means we can't usefully build arch: all typelibs
[17:56] <xnox> slangasek: i would think word size was meant as well.
[17:56] <cjwatson> xnox: I'm pretty sure he analysed one specific pairing and got reasonably lucky, rather than analysing the underlying issues.
[17:56] <slangasek> since arch: all builds on i386, and nowadays most of what we're crossing is for 64-bit (e.g., arm64)
[17:57] <xnox> slangasek: if we could push the size out of typelib and define it for target architecture elasewhere.
[17:57] <cjwatson> xnox: So, no, sorry, I don't credit the Linaro analysis here.
[17:57] <xnox> surely we do know the sizes for default types and G types for glib and thus we don't need to encode it everywhere, and instead use a symantic value.
[17:58] <cjwatson> This is what AC_COMPUTE_INT etc. is for.
[17:58] <cjwatson> Let us not get into the insanity of hardcoding type sizes ...
[18:01] <cjwatson> girparser.c appears to intentionally flatten the integer types (gint, glong, etc.) into the basic types (gint32, gint64, etc.).  I don't know why and it would seem worth looking into before doing anything about it
[18:04] <cjwatson> I agree it would be better if typelibs could be arch-indep, but I don't know how difficult it is to get there from here, and I'm also concerned about architecture-dependent code in the thing being analysed
[18:36] <shadeslayer> backportpackage seems to be broken?
[18:37] <shadeslayer> http://paste.ubuntu.com/6562770/
[18:40] <tarpman> shadeslayer: should it be -u telepathy-kde/ppa ?
[18:41] <shadeslayer> huh
[18:41] <shadeslayer> ppa: used to work before
[18:42] <tarpman> er, ppa:telepathy-kde/ppa
[19:38] <wookey> what magic /win 18
[19:38] <wookey> doh
[19:55] <Noskcaj> Can someone take a look at the new version of  libhugetlbfs? It adds fully arm (inc. arm64) support
[19:55] <Noskcaj> doko, I think you where the last uploader
[21:27] <bdmurray> hallyn_: I think you typoed the bug number (1235649) in your cgroup-lite upload to precise's proposed queue
[22:10] <hallyn_> do
[22:12] <hallyn_> h
[22:16] <hallyn_> bdmurray: that was meant to be bug 1257857
[22:16] <hallyn_> bdmurray: shall i re-upload, or can you fix that in-stream?
[22:17] <bdmurray> hallyn_: no, I can't at least as far as I know.
[22:17] <hallyn_> ok, will re-push, thanks
[22:18] <hallyn_> (pushed)
[22:28] <stgraber> @pilot off
[22:28] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[22:28] <stgraber> @pilot out
[22:41] <tarpman> hi, would some kind sru person let me know the status of accountsservice in precise-proposed? it's been there (and verified) for a while. just wondering whether it's "keep waiting" or needs attention from anyone
[22:43] <dobey> "a while" is < 7 days?
[22:43] <tarpman> that short? I must have misread something, my apologies
[22:51] <xnox> tarpman: it's stuck because only one of the two bugs is verified.
[22:51] <xnox> tarpman: from http://people.canonical.com/~ubuntu-archive/pending-sru.html
[22:51] <xnox> tarpman: it's sru for bug #1004515 and bug #1067414
[22:52] <xnox> tarpman: while first one is verify the second one is not.
[22:52] <xnox> ah, they are duplicates.
[22:52] <xnox> tarpman: right, i've marked the duplicate bug as verification-done
[22:53] <tarpman> xnox: thank you!
[22:53] <xnox> bdmurray: is that correct behaviour that duplicate bugs are considered by pending-sru report? (one duplicate of the other, yet one was verification done and the other one was still needed)
[22:54] <xnox> tarpman: it should become green and good to go, after next report regeneration.
[22:54] <tarpman> xnox: much appreciated :)
[22:56] <bdmurray> xnox: pending-sru looks at the changelog to see which bugs are fixed and I'd expect duplicate consolidation to be done before a package was uploaded to -proposed
[22:57] <xnox> bdmurray: ok.
[23:00] <bdmurray> xnox: well I guess something should be done to the report to identify SRU bugs that have been marked as a duplicate as people do crazy things
[23:01] <xnox> bdmurray: well, i don't think it happens that often, does it?
[23:02] <bdmurray> xnox: no, so I'll make it a wishlist thing
[23:03] <xnox> bdmurray: it could print #102 (#99, #83), #83, #79. where in the brackets are bug numbers of duplicates.
[23:03] <xnox> bdmurray: since e.g. regression comment might be on the duplicate, instead of master bug.... then also it would be easier to spot if changelog has listed duplicate bugs.
[23:04] <bdmurray> xnox: that'd be a crazy long list
[23:04] <xnox> =/
[23:04] <xnox> yeah, for crazy bugs it would be.
[23:05] <xnox> bdmurray: then #bug (#masterbug), if #bug happens to be marked as duplicate? that would be at most double the bug references.
[23:05] <xnox> (if all changelog mentioned bugs became dupes)
[23:05] <bdmurray> xnox: I was thinking about just changing the color if it is a duplicate becasue that is wrong
[23:06] <xnox> oh, nice. that would be lovely.
[23:08] <bdmurray> but then we'll have some angry fruit salad
[23:12] <xnox> bdmurray: i pick 50 shades of gray