[03:41] <Logan_> Noskcaj: If a Debian (or Ubuntu) UDD branch is broken, you can use grab-merge to do it traditionally.
[03:41] <Logan_> (re: your comment on rygel on MoM)
[03:42] <Logan_> If it's too much of a pain to generate the proper debdiffs for a merge bug (believe me, I don't even bother), let me know, and I can just upload a merge.
[03:45] <Noskcaj> Logan_, Could you? It's as much effort to review rygel as it is to merge
[03:46] <Logan_> Sure.
[03:46] <Logan_> Just keep the patch, right?
[03:46] <Noskcaj> yep. thanks
[03:46] <Logan_> No worries. Feel free to ask me to do it in those kinds of situations.
[03:50] <Noskcaj> Should only be a few more days before i get MOTU anyway.
[03:50] <Noskcaj> I'll just have to try and wake up early on monday, since applying by email doesn't work
[03:58] <Logan_> Noskcaj: There's some weird thing going on with quilt.
[03:59] <Logan_> I'm perplexed.
[04:05] <Noskcaj> Is it possible to have a package dropped from main?
[04:07] <Noskcaj> xchat-gnome, xchat-gnome-indicator, and xchat-indicator in this case
[04:11] <Noskcaj> xchat-indicator is seeded in xubuntu and studio, the other two in nothing
[04:11] <Noskcaj> They have no main reverse-depends
[04:57] <Logan_> Noskcaj: Yes. For an example of a bug for demotion to universe, see Bug 1243235.
[04:57] <Logan_> Just subscribe ~ubuntu-archive.
[05:02] <Noskcaj> ok
[05:11] <pitti> Good morning
[05:12] <Snow-Man> morning. :)
[05:53] <Orrin_Fox> Hello there everyone.
[06:04] <Orrin_Fox> so I was thinking of helping out with ubuntu core.
[07:05] <Unit193> mvo: Poooooke. :)
[08:03] <dholbach> good morning
[08:17] <dbarth> doko: hey, good morning
[08:18] <dbarth> i'm looking for some tips to accelerate arm builds and thought you could have some with the packages you're maintaining
[08:18] <dbarth> do you have a magic formula?
[08:44] <dholbach> @pilot in
[09:29] <doko> dbarth, sorry, did skip the dark arts lessons at school
[09:30] <Laney> slacker
[09:33] <ogra_> dbarth, cant you do it in universe directly ? the distro builders are faster than the PPA ones
[09:34] <dbarth> hi
[09:34] <dbarth> doko: eh ;)
[09:35] <dbarth> ogra_: well, that's for developer builds, for oxide
[09:35] <ogra_> dbarth, right ... it wont help you for local builds indeed, but generally the distro builders are a lot faster than using PPAs for uploads
[09:35] <dbarth> ie, ways to have either a way to cross-build or spread on 2-3 phones to speed tihngs up maybe
[09:36] <doko> dbarth, isn't chrisccoulson building this anyway in a ppa on a regular basis?
[09:36] <ogra_> and i dont see a reson why youo couldnt do development uploads to universe, given we expect oxide to be ready by release
[09:36] <dbarth> doko: he is, but he can't wait on the ppa to do his own development, as its a 10h round trip every time
[09:37] <dbarth> ogra_: how faster are they? ie, if ppa builds take 10h or so
[09:37] <dbarth> can that be a 3 or 4x factor?
[09:37] <ogra_> PPAs = pandas ... (or even qemu builders) ... distro builders = highbank ... iirc 4x faster than panda
[09:37] <dbarth> hmm
[09:38] <dbarth> sounds interesting indeed
[09:38] <chrisccoulson> ogra_, which ones are used for canonical-arm-dev/ppa?
[09:38] <dbarth> do you have one of those to loan? ;)
[09:38] <ogra_> chrisccoulson, pandas
[09:38] <dbarth> hey chrisccoulson
[09:38] <chrisccoulson> dbarth, i might have cross-builds working next week anyway ;)
[09:38] <ogra_> c-arm-dev is a non virtual PPA ... these are all pandas
[09:38] <ogra_> public PPAs are qemu iirc
[09:39] <cjwatson> We have no panda builders any more
[09:40] <cjwatson> Thank goodness
[09:40] <ogra_> oh then c-arm-dev is also qemu
[09:40] <cjwatson> The non-virtual PPAs are Calxeda nodes
[09:40] <cjwatson> Virtual ARM PPAs are qemu-user
[09:40] <cjwatson> canonical-arm-dev is devirt, so builds on Calxeda
[09:40] <ogra_> oh, i thought we held back calxeda for PPAs
[09:40] <cjwatson> No
[09:40] <ogra_> ok
[09:41] <ogra_> dbarth, then my statement is moot, sorry
[09:41] <cjwatson> Don't use Pandas for building even if you do find one under a rock
[09:41] <chrisccoulson> i guess that means 12 hours is about as fast as we're going to get
[09:41] <doko> dbarth, afaik he is using the non-virtualized ppa's. the last time I looked at least qt didn't use parallel builds, so that would be the first thing to improve if hd didn't already
[09:41] <cjwatson> I would expect Calxeda (e.g. canonical-arm-dev) to be lots faster than qemu-user in virtual PPAs
[09:42] <ogra_> chrisccoulson, right ...
[09:43] <cjwatson> ogra_: you'd probably notice if we were still building things on Pandas, because you'd be seeing random one-bit errors in builds
[09:43] <ogra_> yeah, i gave up building on pandas ages ago ... chromebook FTW :)
[09:43] <ogra_> USB 3.0 ++
[09:43] <dbarth> and distcc,icecc,whatevercc?
[09:45] <dbarth> i mean chris could spawn 1-2 cloud instances to get more cores to crunch the build
[09:45] <dbarth> dev. builds, not necessarily ppa builds
[09:48] <cjwatson> if you happen to have an ARM cloud in your back pocket then by all means ...
[10:01] <dbarth> cjwatson: i imagined the cores would run a cross gcc/g++
[10:02] <dholbach> @pilot out
[10:10] <cjwatson> dbarth: I would expect that cross-building would be significantly faster already without having to bother with distcc etc.
[10:11] <dbarth> ok
[10:12] <dbarth> well chrisccoulson let's see when you get cross-builds working then
[10:12] <dbarth> thanks all for the feedback
[10:20] <xnox> dbarth: which package?
[10:24] <xnox> dbarth: looking at lp:oxide - it neither has ./debian/ nor is using CMake
[10:25] <xnox> dbarth: at the moment, one needs to use at least cmake or autotools-based build-systems to have cross-compilation support.
[10:25] <xnox> dbarth: is lp:oxide our upstream project?
[10:25] <xnox> or a fork of something upstream?
[10:28] <cjwatson> well, or a simple build system where you can just tell it the compiler to use and it gets on with it.  oxide probably isn't a simple enough package for that though
[10:34] <xnox> cjwatson: looking at lp:oxide it looks like qmake(?!) wrapped around chromium buildsystem.  Oh, I see lp:~chrisccoulson/oxide/cmake looks promising.
[10:50] <xnox> looks like chromium / oxide / cmake should be easy, just needs a few exports for arm-cross for gyp.
[10:50] <xnox> https://code.google.com/p/chromium/wiki/LinuxChromiumArm
[11:14] <lesshaste> hi... I reported https://bugs.launchpad.net/ubuntu/+source/scratch/+bug/1270194 but am a little worried there may be no ubuntu maintainer
[11:17] <brendand> dholbach, hey - sorry to ping you directly, but i have a question about MOTU
[11:18] <brendand> dholbach, do you know do we still need to go through the process if the package we want in universe replaces one already in universe?
[11:20] <lesshaste> apt-cache show scratch shows
[11:20] <lesshaste> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[11:20] <lesshaste> Original-Maintainer: Miriam Ruiz <little_miry@yahoo.es>
[11:20] <lesshaste> does this mean there is no specific maintainer any more?
[11:21] <jpds> lesshaste: As is the case with all Ubuntu packages.
[11:22] <jpds> lesshaste: That bug should be forwarded to the programmer authors.
[11:22] <brendand> lesshaste, probably pointless to package scratch now
[11:22] <brendand> lesshaste, scratch have converted to pure web implementation
[11:22] <brendand> lesshaste, see - http://scratch.mit.edu/
[11:26] <jibel> pitti, similar problem to espeak with libcups2-dev
[11:26] <jibel> dpkg: error processing /var/cache/apt/archives/libcups2-dev_1.7.1-2_amd64.deb (--unpack):
[11:26] <jibel>  unable to move aside `./usr/include/cups/i18n.h' to install new version: Invalid cross-device link
[11:26] <pitti> meh
[11:29] <pitti> jibel: from which version? precise/quantal/saucy?
[11:30] <jibel> pitti, P > T amd64 with all of main
[11:30] <jibel> bug 1272285
[11:31] <pitti> jibel: ah, so in precise /usr/include/cups/i18n.h/ was a directory, too
[11:33] <lesshaste> brendand, oh..what about http://scratch.mit.edu/scratch2download/ ?
[11:34] <brendand> lesshaste, oh i didn't know about that - interesting
[11:34] <brendand> lesshaste, but that's an air application anyway
[11:34] <lesshaste> jpds, ok.. I don't know how to forward it to them
[11:35] <brendand> lesshaste, so i doubt it's equivalent to the debian package
[11:35] <lesshaste> brendand, you mean it can't be packaged for legal reasons on ubuntu?
[11:35] <lesshaste> brendand, or that it just hasn't been yet
[11:35] <jpds> lesshaste: It uses an [old?] platform from Adobe.
[11:36] <lesshaste> yes... AIR 2.6.0 for Linux
[11:36] <brendand> jpds, i think air is still actively supported (might be wrong)
[11:36] <brendand> jpds, although it seems the linux version is not supported
[11:36] <lesshaste> "Note: Beginning June 14 2011, Adobe AIR is no longer supported for desktop Linux distributions. Users can install and run AIR 2.6 and earlier applications but can't install or update to AIR 2.7"
[11:37] <lesshaste> http://helpx.adobe.com/air/kb/install-32-bit-air-linux.html
[11:38] <lesshaste> how annoying :(
[11:39] <lesshaste> "Adobe's efforts are focused on supporting operating systems that are most important to its customers, and that demonstrate the greatest opportunity for future growth for its partners and developers"
[11:39] <lesshaste> that is... no more linux
[11:41] <lesshaste> in any case..2.6 works apparently (http://orkultus.wordpress.com/2013/03/23/installing-adobe-air-2-6-on-64bit-linux-mint-ubuntu/)
[11:44] <darkxst> lesshaste, AIR was a disaster no matter which way you look at, we arent really loosing anything by not having it
[11:44] <brendand> lesshaste, adobe don't support ios or android
[11:48] <Laney> tjaalton: Looks like your adding of libnss3-nssdb broke multi-arch upgrades/installs: libnss3:i386 : Depends: libnss3-nssdb:i386 but it is not installable
[11:49] <lesshaste> darkxst, it's just a pain that scratch doesn't work
[11:49] <lesshaste> darkbasic, given that a) it is free b) linux is free and c) it is for kids
[11:49] <lesshaste> bregma, i have no idea why mit went for this solution
[11:51] <darkxst> lesshaste, even if it was supported, it still wouldn't work most likely!
[11:51] <lesshaste> darkxst, why is that?
[11:52] <tjaalton> Laney: on debian? aiui the current version ftbfs'd on !amd64, since it's racy
[11:52] <tjaalton> the build
[11:52] <darkxst> lesshaste, it was always broken
[11:52] <Laney> tjaalton: ubuntu
[11:52] <tjaalton> oh i see now
[11:52] <tjaalton> I'll have a look..
[11:52] <Laney> it's in trusty release
[11:53] <Laney> I noticed because dist-upgrade is complaining ...
[11:53] <tjaalton> well there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736061 but it's not clear where the actual bug is
[11:56] <tjaalton> would Multi-Arch: foreign fix it?
[11:59] <mitya57> Can somebody please reject mikutter from Saucy SRU queue? I forgot to update the Maintainer field...
[11:59] <tjaalton> Laney: i'll test that and upload if so
[12:00] <MacSlow> seb128, there you go ... https://code.launchpad.net/~macslow/notify-osd/notify-osd.fix-1092905/+merge/203047
[12:01] <seb128> MacSlow|lunch, hey, thanks! let me test that ;-)
[12:02] <MacSlow|lunch> seb128, :)
[12:02] <seb128> MacSlow|lunch, enjoy your lunch!
[12:02] <MacSlow|lunch> thx
[12:03] <mitya57> pitti: Can you please remove python-imaging autopkgtest? That package has been renamed to pillow.
[12:03] <pitti> mitya57: I already did a while ago
[12:03] <pitti> ah, not from public jenkins
[12:04] <Laney> tjaalton: okay, if it's technically correct to do that (I don't know) then that should work
[12:04] <pitti> mitya57: yep, I'll file a request, thanks for pointing out
[12:04] <mitya57> Thanks.
[12:05] <tjaalton> Laney: aiui it tells that a foreign-arch package fulfills the dep, in this case the libnss-nssdb:amd64 for libnss:i386
[12:05] <tjaalton> *libnss3:i386
[12:05] <Laney> yes
[12:06] <Laney> so it's whether libnss3:i386 can work with libnss-nssdb:amd64
[12:08] <tjaalton> well
[12:08] <tjaalton> actually, libnss3-nssdb could probably be arch:all
[12:09] <tjaalton> since http://stackoverflow.com/questions/15024658/are-sqlite3-databases-are-platform-independent
[12:11] <dholbach> brendand, is your question resolved?
[12:11] <tjaalton> meh, it is arch:all
[12:11] <Laney> You still need the annotation
[12:17] <knome> seb128, the lp:xubuntu-docs/precise branch seems to be as it should
[12:18] <seb128> knome, do you have any idea what went wrong there?
[12:18] <knome> seb128, well, the original bug is fixed... we now have the 12.04 *content*
[12:18] <knome> seb128, but some image files are missing, and some css files aren't updated
[12:18] <seb128> knome, I apt-get sourced the precise version and applied the debdiff from the bug on it, then did debuild -S ...
[12:18]  * knome looks at the debdiff
[12:19] <seb128> knome, is that a regression? not that diff can't include binary changes, like images
[12:20] <knome> i was looking for the .css file changes, and it does look like the debdiff is faulty
[12:20] <knome> seb128, yep, it's a regression
[12:20] <seb128> knome, ok, well, if you get a non buggy debdiff feel free to ping me and I can sponsor that one
[12:21] <knome> seb128, i'm not a very technical person myself, but i'll delegate that to somebody; do you want the new debdiff against 11.10.0 or 12.04.0?
[12:22] <seb128> knome, either works
[12:22] <knome> seb128, ok, cheers
[12:22] <seb128> whatever is easier
[12:22] <Peace-> i would like create a package that will overwirte bashrc from canonical  is there a way to do that ?
[12:22] <seb128> knome, yw, sorry for not catching those issues before sponsoring
[12:22] <knome> seb128, np, that happens
[12:22] <Peace-> i need to do that with skel ?
[12:42] <tjaalton> Laney: looks like adding M-A: foreign works
[12:42] <Laney> tjaalton: neat
[12:43] <brendand> dholbach, no
[12:44] <dholbach> brendand, ok... so you want to replace a package that is already in the archive
[12:44] <dholbach> brendand, can you elaborate?
[12:45] <dholbach> brendand, the package will have the same name but different contents later on? is it like an update? or you add a patch to it? or what exactly happens?
[12:46] <brendand> dholbach, no it's changing name. checkbox-qt is the existing package. checkbox-gui is the new one
[12:46] <brendand> dholbach, it will provide the same type of functionality
[12:47] <brendand> dholbach, different implementation and updated ui
[12:47] <dholbach> brendand, will it be built from the same source and it's just the binary package (.deb package) name which changes?
[12:47] <dholbach> ok
[12:47] <dholbach> sure that's possible
[12:48] <dholbach> just make the changes in checkbox trunk and ask for it to be uploaded as usual (https://wiki.ubuntu.com/SponsorshipProcess) - basically file a bug with ubuntu-sponsors subscribed
[12:50] <ggvaberi> hello. Can anyone tell from where gsettings read data? for example icon-theme. where is real database? is it text/xmp data or some binary in cash?
[12:56] <geser> dholbach: brendand should also add a transitional package (with the old name), right?
[12:57] <brendand> geser, how does that work?
[12:57] <brendand> geser, i haven't heard the term transitional package before
[13:00] <geser> brendand: the old package (checkbox-qt) just depends on checkbox-gui and is otherwise empty. This ease the transition for people who have the old one already installed.
[13:01] <brendand> geser, oh right
[13:01] <geser> brendand: see also https://wiki.debian.org/Renaming_a_Package
[13:26] <MacSlow> seb128, I've pushed a more robust version of the fix... have another look.
[13:35] <kentb> xnox: is there anything else you need from me to help clean up sblim-sfcc on trusty?
[13:35] <xnox> kentb: bah, didn't look at your last .dsc yet. Let me diff it and upload.
[13:35] <xnox> kentb: i think it was all good.
[13:36] <kentb> xnox: ok. no problem. thanks.
[13:39] <seb128> MacSlow, thanks, commented on it
[13:40] <popey> bug 1272338
[13:41] <popey> anyone else seeing lots of memory use from xorg on intel?
[13:41] <popey> i recently upgraded to 16GB in my laptop, glad I did!
[13:41] <xnox> kentb: uploaded. I really shouldn't read sponsorship request emails on my phone ;-)
[13:42] <kentb> xnox: heheh. thanks!
[14:01] <pitti> doko: FYI, py3.4 autopkgtest runs done; raw logs are at http://people.canonical.com/~pitti/tmp/autopkgtest-py34/, I'll analyze them now
[14:14] <MacSlow> seb128, I digged deeper into the whole defaults_get_top_corner() ... looks like it's just a one-line change after all... please test it again. Looks good here (even desktop-environment neutral)
[14:14] <seb128> MacSlow, thanks for looking a bit more, let me test that
[14:20] <seb128> MacSlow, works fine here, and I like that version better I've to say ;-)
[14:20] <MacSlow> seb128, sure... I knew you can't resist the charms of a one-line change ;)
[14:20] <seb128> hehe
[14:26] <MacSlow> seb128, you'll also top-approve it?
[14:27] <seb128> MacSlow, yes, just giving it a try out of Unity first
[14:27] <MacSlow> seb128, ah ok sure
[14:48] <seb128> Riddell, hey, did you see my ping about calligra/needing a rebuild for new poppler the other day?
[14:51] <Riddell> seb128: yeah I'm onto it now
[14:51] <seb128> Riddell, thanks ;-)
[14:51] <Riddell> seb128: there's a new release of calligra I'm packaging and it's a beast of a package so still sorting out the new/removed files
[15:37] <sergiusens> jamespage, hey, by any chance, will you or did you package launchpad.net/go-dbus/v1 ?
[15:37] <jamespage> sergiusens, neither I'm afraid
[15:38] <sergiusens> jamespage, I'll take that then :-)
[15:38] <jamespage> sergiusens, is your work targetted to ubuntu main?
[15:39] <sergiusens> jamespage, this one should eventually land in main
[15:39] <sergiusens> jamespage, it's for phone/touch stuff so yes
[15:39] <jamespage> sergiusens, well its probably pertinent to talk about go toolchain then
[15:39] <jamespage> we've been having quite a bit of discussion around that for juju-core -> main this cycle
[15:40] <sergiusens> jamespage, gcc versus go?
[15:40] <jamespage> sergiusens, you got it
[15:40] <sergiusens> jamespage, I'm just using the default tbh; and I saw you did a dual thing
[15:41] <jamespage> sergiusens, the plan for supporting juju-core is to use gccgo - which is working ok
[15:41] <jamespage> main driver is server platforms that don't have golang-go support
[15:42] <jamespage> sergiusens, right now the juju-core package still bundles its dependencies - still not convinced go libraries are stable enough for general release in distro
[15:42] <jamespage> *that might not apply everywhere....
[15:42] <sergiusens> jamespage, are you using dh-golang?
[15:42] <jamespage> sergiusens, no
[15:43] <sergiusens> jamespage, right; we have dbus-go embedded into our tree currently
[15:43] <sergiusens> jamespage, but all others I've pushed to debian
[15:43] <jamespage> sergiusens, yeah - i saw - nice work
[15:43] <sergiusens> ty
[15:43] <jamespage> I started on mgo and gnuflags but I'm not pushing that hard due to bundling stuff
[15:44] <sergiusens> jamespage, ok, I'll check on doing the compiler select with dh-golang
[15:44] <sergiusens> for libs it's not really important yet luckily :-)
[15:45] <jamespage> sergiusens, right now is golang-go; I've got a gccgo-go package in progress which provides the go tool built just using gccgo
[15:45] <jamespage> so the idea is you can swap golang-go for gccgo-go and it *just works*
[15:46] <sergiusens> that would indeed solve all our problems sans a rebuild if we don't provide both :-)
[15:50] <pitti> doko: ok, done; I sent the results to u-devel@, you are CCed; https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3.4 doesn't look too bad, but it's some work
[15:58] <doko> pitti, thanks. python-csb already always fails with 3.3, aptdaemon is ftbfs in -proposed
[15:59] <doko> didn't check for the others
[15:59] <pitti> doko: yes, I didn't file a bug for -csb
[15:59] <pitti> doko: there are a lot of failures which are unrelated to the -3.4 change
[16:04] <kentb> can someone please have a look at my debdiff for openwsman to make sure I got transitional packages correct as well as the 'breaks' and 'replaces' directives?  Thanks in advance:  https://bugs.launchpad.net/ubuntu/+source/wsmancli/+bug/1272059/comments/6
[18:05] <dobey> anyone else still using evolution? it is *very* crashy on trusty :(
[18:06] <seb128> tedg is (I thinkà
[18:06] <seb128> )
[18:06] <tedg> Yeah, I am.  And it is more crashy.
[18:06] <dobey> (not to mention the other UX bugs i've already filed against it)
[18:07] <seb128> dobey, do you file your bugs upstream?
[18:07] <jtaylor> pitti: how was the py3.4 default test performed?
[18:07] <seb128> I doubt anyone is looking at evolution bugs for Ubuntu, you probably have a better chance upstream if you want to report issues
[18:07] <jtaylor> symlinkin py3.3 to py3.4?
[18:07] <dobey> no, i filed them in launchpad
[18:07] <dobey> i have no idea if they're upstream bugs or not
[18:08] <seb128> we have very little distro patching in evo nowadays
[18:08] <dobey> and for the crashing, i just clicked the "send this error report" button
[18:10] <seb128> dobey, do you have a link to the error pages for those?
[18:10] <seb128> https://errors.ubuntu.com/?release=Ubuntu%2014.04&package=evolution&period=month is quite small
[18:11] <dobey> seb128: no, i never got any link from the apport ui or anything. and i don't know what the traceback was
[18:12] <seb128> dobey, you can go to gnome-control-center -> privacy, there is a link to your reported errors webpage
[18:12] <dobey> and my /var/crash is empty
[18:12] <seb128> though e.u.c summary is not really nice
[18:12] <seb128> you just get a list ids
[18:12] <dobey> seb128: i can't do that, because i removed zeitgeist
[18:12] <seb128> you need to click through to find the ones you need
[18:13] <seb128> dobey, $browser 'http://errors.ubuntu.com/user/'$(printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum)
[18:13] <seb128> dobey, that should do it :p
[18:14] <dobey> well that's empty page
[18:14] <dobey> thanks a lot apport :(
[18:15] <seb128> dobey, sorry, xchat-gnome segfaulted
[18:15] <dobey> seb128: empty page
[18:15] <mdeslaur> I can't believe how broken this new xchat-gnome is
[18:15] <dobey> it's almost as bad as evolution, i bet
[18:15] <seb128> mdeslaur, oh, you found as well?
[18:15] <seb128> mdeslaur, I'm pondering reverting the update, I didn't have issues for ages with the old one
[18:16] <mdeslaur> yeah, it's not properly handling the channel positions, it's scrolling windows when loading scrollback, etc.
[18:16] <mdeslaur> seb128: I would agree with that, this one is _really_ broken to the point of almost being unusable for the time being
[18:16] <dobey> irssi is your friend
[18:17] <mdeslaur> dobey: haha, good one :)
[18:17] <dobey> wtf, i just did ubuntu-bug on a .crash file, and chose "send this error report" but there is no .upload file in /var/crash for it
[18:18] <seb128> dobey, we didn't re-enable apport yet
[18:19] <dobey> seb128: then why is it popping up?
[18:19] <seb128> it's whoopsie which is
[18:19] <seb128> we didn't enable report to launchpad if you prefer
[18:19] <seb128> just to e.u.c
[18:19] <dobey> then where the heck are my "error reports" going?
[18:20] <seb128> e.u.c
[18:20] <seb128> dobey, http://launchpadlibrarian.net/153485340/apport_2.12.5-0ubuntu1_2.12.5-0ubuntu2.diff.gz
[18:20] <dobey> apparently not, based on the product_uuid-based url
[18:20] <seb128> dobey, revert that change if you want to enable the reporting to launchpad
[18:21] <dobey> how do i know if it actually made it to e.u.c or not?
[18:21] <seb128> not sure, that's a question for ev
[18:21] <seb128> the command I copied earlier wfm
[18:21] <mdeslaur> ok, that's it... /me switches back to old xchat-gnome
[18:22] <dobey> seb128: i get an otherwise empty page with it
[18:22] <seb128> mdeslaur, can you open a bug listing your issues, so we can assign to "Jackson Doak" who did the update
[18:22] <dobey> just the "Error tracker" at the top and <address> bits at the bottom
[18:22] <seb128> dobey, yeah, well that's about as much I know about whoopsie/e.u.c, you need ev or bdmurray
[18:22] <dobey> and nothing in between
[18:23] <sarnold> mdeslaur: < seb128> mdeslaur, can you open a bug listing your issues, so we can assign to "Jackson Doak" who did the update
[18:23] <mdeslaur> I did, one sec
[18:23] <seb128> shrug
[18:23] <seb128> mdeslaur, the indicator integration is also borked
[18:23] <mdeslaur> sarnold, seb128: bug 1272455
[18:23] <mdeslaur> I think reverting it would be best for now
[18:24] <mdeslaur> fixing these issues is likely to be a substantial task
[18:24] <seb128> mdeslaur, yeah, the indicator doesn't clear the count as it should and when you click on a channel with a wrong status it segfaults
[18:24] <seb128> mdeslaur, do you want to do the revert? just take the previous version and bump the changelog to new+revert
[18:25] <mdeslaur> seb128: sure
[18:25] <seb128> shrug
[18:25] <seb128> it doesn't even scroll correctly to the bottom of a channel when new messages are added
[18:25] <seb128> mdeslaur, thanks
[18:28] <bdmurray> dobey: in the upper right hand corner does it say "logged in as "?
[18:28] <dobey> bdmurray: no
[18:29] <dobey> now it does, and still empty list
[18:29]  * mdeslaur chuckles at insane xchat-gnome version
[18:31] <mdeslaur> 1:0.30.0~git20131003.d20b8d-2ubuntu11+really0.30.0~git20110821.e2a400-0.2ubuntu13
[18:31] <mdeslaur> lol
[18:31] <bdmurray> dobey: I'll look at the server logs to see if there is an oops at all.  Does /var/log/syslog show the crash being uploaded by whoopsie?  Is there a .uploaded file corresponding to the crash in /var/crash?
[18:31] <tarpman> mdeslaur: that must be some kind of record
[18:31] <dobey> bdmurray: there's no uploaded file, no
[18:31] <mdeslaur> I'm still thinking about it :)
[18:32] <bdmurray> dobey: this week I uploaded a new version of whoopsie that fixed when crash files were uploaded (every 2 hours vs immediately)
[18:32] <seb128> mdeslaur, how that version could be uploaded is behind me
[18:32] <seb128> mdeslaur, not the version number, but the buggy xchat-gnome code
[18:32] <seb128> mdeslaur, I'm using it for 15 min and it's already driving me nuts
[18:33] <cjwatson> I'm still confused at why people think abbreviated git sha-1s are a sensible thing to put in version numbers, given that they are NOT MONOTONICALLY INCREASING
[18:33] <mdeslaur> If anyone has an idea for a sane version, I'm all ears :)
[18:33] <cjwatson> if you need a sequence number in case you upload more than one snapshot on the same day, use .1 .2 etc.; if you want to store the git sha-1 somewhere, put it somewhere other than your version ...
[18:33] <cjwatson> mdeslaur: it's obviously not your fault :)
[18:34] <dobey> bdmurray: how am i supposed to guess when it will be uploaded exactly?
[18:34] <xnox> seb128: i've switched to pure xchat with xchat-indicator long time ago. it actually integrates into unity better than xchat-gnome, imho.
[18:34] <xnox> seb128: poke the uploader about it =)
[18:34] <bdmurray> dobey: if you restart whoopsie it will do an initial scan for .crash files and upload it then
[18:34] <seb128> xnox, how so?
[18:35] <seb128> xnox, the upload is dholbach (sponsoring), the updater has been poked through assigned launchpad bug ;-)
[18:35] <xnox> seb128: it actually picks up font sizes for me at least =) and messaging menu / (n) on the icon works properly, and i've uploaded useful functional patches to xchat ;-)
[18:35] <xnox> there is a new fork of xchat as well, haven't tried it yet.
[18:36] <xnox> xchat is kind of like xemacs 21 ;-)
[18:36] <seb128> xnox, launchpad/messaging menu integration works fine with xchat-gnome
[18:36] <xnox> and back then, xchat-gnome was crashing for me a lot =/ whereas xchat is rock-solid for me.
[18:36] <seb128> I didn't have an xchat-gnome segfault in years
[18:37] <seb128> well, both options are good ones, choice for everyone ;-)
[18:37] <mdeslaur> yeah, the last bad one was the copy/paste thingy
[18:37] <mdeslaur> but I think that's solved now
[18:37] <seb128> iirc it is
[18:38] <jdstrand> @pilot in
[18:39]  * mdeslaur considers (1:0.30.0~git20131003.d20b8d-2ubuntu1+really20110821ubuntu13)
[18:48] <seb128> mdeslaur, just do "(1:0.30.0~git20131003.d20b8d-2ubuntu1+revert)" ;-)
[18:49] <dobey> bdmurray: hmm, restarted whoopsie service and still no upload afaict
[18:54]  * mdeslaur fights with orig tarball
[18:55] <mdeslaur> seb128: how the heck do I handle the orig tarball?
[19:01] <bdmurray> dobey: hmm, I'm looking into whoopsie now thanks
[19:01] <dobey> bdmurray: ok, thanks
[19:03]  * mdeslaur tries 1:0.30.0~git20131003.d20b8d+really20110821-0.2ubuntu12
[19:10] <mdeslaur> seb128: uploaded
[19:30] <kentb> slangasek: (or any AA for that matter) kirkland and I worked on some fixes for wsmancli / openwsman and there are some new openwsman binaries in the trusty upload queue.  If we could get those promoted before Monday that'd be much appreciated. Thanks in advance.
[20:19] <bdmurray> dobey: thanks again for bringing that up, I discovered the problem
[20:21] <dobey> bdmurray: is it server side? or client?
[20:22] <bdmurray> dobey: its apport - bug 1272505
[20:22] <dobey> bdmurray: ah ok. i'll wait for the update then
[21:29] <tester56> has anyone an idea how to block a user from recording audio? (disallow access to microphone)
[21:48] <tarpman> jdstrand: replied to your comment on #976100 (not sure it emailed you, looks like you aren't subscribed)
[21:52] <jdstrand> tarpman: ack
[22:37] <jdstrand> @pilot out