[02:51] <cfhowlett> BET: now that CrackBerry has risen from the grave, people will demand that UbuPhone be ported ...
[03:08] <xsacha> cfhowlett: too late
[03:08] <xsacha> cfhowlett: http://forums.crackberry.com/blackberry-10-dev-alpha-f270/ubuntu-phone-components-running-bb10-761899/
[03:09] <cfhowlett> Wow.  Just wow.  and I thought the ihackintosh crowd was fanatically zealous ...
[03:11] <cfhowlett> ah well.  I do like the form factor.  If/when BB goes belly up, perhaps a few million of those surplus units would make a nice hacking hobby or *whisper mode on* perhaps canonical might consider the purchase of an OEM
[03:12] <xsacha> cfhowlett: you can already get playbook tablets for under $100
[03:12] <xsacha> they are pretty decent.. i saw a 16GB go for $42 on ebay, brand new
[03:12] <xsacha> has a dual-core omap4, two cameras, stereo speakers, 1GB RAM and all that jazz
[03:12] <xsacha> and they will get bb10 soon too
[03:15] <xsacha> nice to dev on to. i have gcc on it. ssh access is already on by default and it comes with all the standard unix utils
[03:15] <cfhowlett> refresh my memory: playbook?  lenovo?
[03:15] <xsacha> blackberry
[03:16] <xsacha> they have been giving away 1000s of them, so they are dirt cheap
[07:05] <mattlgroff_> Is there any sort of Maps or Navigation Core App planned?
[12:12] <ptl> besides the galaxy nexus, how can I see which other models will support Ubuntu Phone? Because the galaxy nexus does not have the quad-core or 2GB RAM required for the full ubuntu phone experience
[12:12] <ptl> and will be obsoleted soon
[12:15] <popey> ptl: we haven't announced which models will be supported yet.
[12:21] <ptl> popey: only the low-end ubuntu phone, galaxy nexus, but why not a high-end too?
[12:22] <ptl> :S
[12:22] <ptl> I'd like to tinker on it within the high-end spectrum
[12:22] <ptl> with the galaxy nexus I will be confined to low-end
[12:22] <popey> as I said, we haven't confirmed phone models yet
[12:22] <ptl> :( ok
[16:00] <sivang> kalikiana: where's the lp branch I need to go over? ;)
[16:00] <sivang> kalikiana: waht happend to your mic ? :)
[16:05] <kalikiana> sivang, I created a team, you should be getting a notification
[16:06] <kalikiana> the branch is https://code.launchpad.net/~kalikiana/u1db-qt/trunk
[16:06] <kalikiana> for some reason, launchpad refuses to take it as the default branch.. trying to fix it
[16:34] <Andy80> jppiiroinen, hi :) do you know what I have to add (and how) to be able to use <remotelinux/linuxdevice.h>? Because I've added as "#include <remotelinux/linuxdevice.h>" but then I get a compilation error: ../qt-creator/src/plugins/projectexplorer/devicesupport/idevice.h:36:27: fatal error: QAbstractSocket: No such file or directory
[16:36] <EuroElessar> hi all, I'm interested if Ubuntu Phone use telepathy for im?
[18:46] <jppiiroinen> Andy80: you are missing QT+=network from your project file etc
[18:47] <wrbishop> Will the code work on both the Galaxy Nexus i9250 and i515?
[19:38] <Darkenvy> Hello
[19:39] <lazowik> hi
[19:39] <Darkenvy> I am currently in the market for a new phone and want to look at compatible ubuntu phones
[19:39] <lazowik> development is done on Galaxy Nexus
[19:40] <lazowik> and that's all we know for now
[19:40] <Darkenvy> I have a few questions: do we have a list of supported phones? does ubuntu always run on top of android? and I know its a ARM build, so where is the official place to obtian the release for this development?
[19:40] <Darkenvy> Ahhh
[19:40] <lazowik> nope, Ubuntu for Android shares the kernel with running android
[19:40] <lazowik> but Ubuntu Phone runs by itself
[19:41] <lazowik> it might use android kernel and/or drivers
[19:41] <Darkenvy> I see
[19:41] <Darkenvy> I have AT&T, the Galaxy Nexus isnt with ATT
[19:41] <wrbishop> Will the code work on both the Galaxy Nexus i9250 and i515?
[19:42] <lazowik> LTE?
[19:42] <lazowik> not sure
[19:42] <Darkenvy> I think the best question to ask right now, and I can come back later, is can I set up a virtual machine?
[19:42] <Darkenvy> They have x86 builds of Android. So I can install ubuntu on top of that
[19:43] <lazowik> you want virtual machine on android?
[19:43] <Darkenvy> no
[19:44] <Darkenvy> I am asking where can I download this version of ubuntu for android?
[19:44] <lazowik> oh
[19:44] <lazowik> builds for galaxy are to be delivered late February
[19:44] <Darkenvy> (because then I can install it on top of a virtual machine on my home computer to try before I do my compatible phone hunt)
[19:44] <sivang> kalikiana: did not get a notif about a team, for some reason, let me re-check
[19:44] <Darkenvy> so we don't have the builds yet?
[19:44] <lazowik> nope
[19:44] <Darkenvy> :O
[19:44] <Darkenvy> :'O
[19:44]  * Darkenvy cries *
[19:45] <lazowik> if they were avaible it would make conciderably more fuzz at media
[19:45] <sivang> kalikiana: ah, got it!
[19:45] <Darkenvy> Soooo only galaxies supported?
[19:45] <Darkenvy> ATT doesnt have galaxies
[19:45] <Darkenvy> well we have the SIII
[19:46] <lazowik> and you can't take anything I say for granted
[19:46] <lazowik> everything I know I've read on internet
[19:46] <lazowik> but I think that when the code will be avaible devs at XDA will make some magic
[19:47] <lazowik> you know, geeks like bleeding-edge new stuff
[19:47] <Darkenvy> oh yea :P
[19:47] <lazowik> once I run ICS on HTC Hero...
[19:47] <Darkenvy> Ive been waiting for ubuntu on smartphones for ages
[19:47] <lazowik> me too
[19:48] <Darkenvy> thanks guys! ill be around
[19:48] <Darkenvy> ^^
[19:48] <lazowik> no problem
[19:48] <lazowik> well, this Ubuntu Phone seems already more developed than Ubuntu for Android
[19:49] <Darkenvy> wait I thought ubuntu phone was ubuntu for android
[19:49] <Darkenvy> you just said it runs on top of android
[19:49] <lazowik> nope
[19:49] <lazowik> it's not the same
[19:49] <lazowik> ubuntu for android runs alongside android
[19:49] <Darkenvy> is ubuntu for android old development of soemthing else?
[19:49] <Darkenvy> oh
[19:49] <Darkenvy> so what will ubuntu phone be? its own OS without android?
[19:50] <lazowik> http://www.ubuntu.com/devices/android
[19:50] <lazowik> http://www.ubuntu.com/devices/phone
[19:50] <lazowik> compare
[19:50] <scram> XDA has a thread that explains it all
[19:50] <Darkenvy> oh I've been to both those pages. I thought it was one in the same
[19:51] <Darkenvy> so the ubuntu phone is the full desktop device :O
[19:51] <lazowik> it really depends
[19:52] <lazowik> if the phone is capable, then yes
[19:56] <scram> https://www.youtube.com/watch?v=sLtcj7FdIYA&feature=youtube_gdata_player
[20:09] <Avedo> hi
[20:09] <Avedo> I've a problem installing qt-components-ubuntu it says that some dependencies e.g. libqt5core5 are unmet
[20:11] <Andy80> jppiiroinen, done, but it's not enough http://pastebin.com/1sPL35k8 it's bothering about lot of missing deps and I don't know how to add them, any idea?
[20:13] <Avedo> I stumbled across this error following the instructions at http://developer.ubuntu.com/get-started/gomobile/
[20:28] <jppiiroinen> Andy80: you are missing the qtc pri files from your pro file
[20:29] <jppiiroinen> Andy80: for example for that Remote Linux you would need to include http://qt.gitorious.org/qt-creator/qt-creator/blobs/master/src/plugins/remotelinux/remotelinux.pri
[20:40] <Andy80> jppiiroinen, most important I'm missing how to include/import/create those .pri files :P when I created the plugin there were a lot automatically imported, but I don't know for example how to add that one you said
[20:44] <jppiiroinen> Andy80: for example madde plugin includes this file from its pro file, and this file contains the pri files for the other plugins http://qt.gitorious.org/qt-creator/qt-creator/blobs/master/src/plugins/madde/madde_dependencies.pri like for the remotelinux
[20:50] <Andy80> jppiiroinen, got it, thanks :) btw I think I should move my plugin inside the QtCreator source folder.... because else includes like this won't work: include(../../plugins/remotelinux/remotelinux.pri)
[20:51] <jppiiroinen> Andy80: that's why i have a script, which i could share with you
[20:52] <jppiiroinen> Andy80: i will just have to check it thru first
[20:52] <jppiiroinen> a sec
[20:52] <Andy80> ok, thanks :)
[20:52] <jppiiroinen> have to see what it actually does :p
[20:56] <jppiiroinen> Andy80: i gave a thought and i think that what would be the easiest is that you would do a symbolic link or a bind mount
[20:56] <jppiiroinen> the script which i had actually downloaded the qtc source code and did that more or less
[20:57] <jppiiroinen> but for sure, you need to develop the plugins inside the qtc source tree otherwise it will be tricky
[20:58] <Andy80> well... as long as I can keep pushing only the plugin files on bazaar is good
[20:58] <Andy80> but I think it's doable
[21:06] <Andy80> jppiiroinen, ok moved. I'm fixing deps and other stuff.... let's see if I can compile now :)
[21:07] <MostHated> has anyone been able to run qt creator and properly view a project using ubuntu via a virtual machine?
[21:09] <Andy80> jppiiroinen, almost :P http://pastebin.com/CH8y6GGS not working yet
[21:16] <jppiiroinen> Andy80: include this http://qt.gitorious.org/qt-creator/qt-creator/blobs/master/src/qtcreatorplugin.pri and see if that helps
[21:18] <Andy80> jppiiroinen, like this: include(../../qtcreatorplugin.pri) ?
[21:18] <jppiiroinen> jep
[21:18] <Andy80> I had but it said it was already included...
[21:18] <jppiiroinen> ok
[21:18] <Andy80> so I removed...
[21:18] <alo21> hi.... How can I know when a project will be open?
[21:18] <Andy80> because I've this include($$QTCREATOR_SOURCES/src/qtcreatorplugin.pri)
[21:18] <Andy80> include($$QTCREATOR_SOURCES/src/plugins/coreplugin/coreplugin.pri)
[21:19] <Andy80> and probably they conflicts
[21:21] <jppiiroinen> i have had both of those in a single pro without issues
[21:21] <jppiiroinen> include(../../qtcreatorplugin.pri)
[21:21] <jppiiroinen> include(../../plugins/coreplugin/coreplugin.pri)
[21:21] <jppiiroinen> include(../../libs/utils/utils.pri)
[21:22] <jppiiroinen> this is my wild guess which could contain the missing libs
[21:23] <Andy80> I try all :P
[21:23] <jppiiroinen> it could be that the utils.pri is not required as the coreplugin might include it
[21:24] <jppiiroinen> but anyway, the issues which you have is about those things
[21:25] <jppiiroinen> Andy80: i will have to get some hours of sleep :) ..i will be online tomorrow, in about 8h or so
[21:25] <Andy80> ok... give me some minutes because I'm a bit busy with a thing...
[21:25] <Andy80> ah ok :)
[21:25] <Andy80> see you tomorrow then :)
[21:27] <Andy80> and thanks again :)


[00:06] <anakron> hi all
[00:08] <anakron> someone can look this bug? https://bugs.launchpad.net/ubuntu/+source/pwman3/+bug/299130
[00:50] <savvas> dpkg: error processing /var/cache/apt/archives/python-wxgtk2.8_<IP_ADDRESS>-0ubuntu4_amd64.deb (--unpack): trying to overwrite `/usr/lib/python2.6/dist-packages/wx/__version__.py', which is also in package python-wxgtk2.6
[00:50] <savvas> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[00:51] <savvas> python-wxgtk2.8 breaks when python-wxgtk2.6 is already installed
[00:51]  * savvas files a bug :P
[00:53] <anakron> :O your first bug
[00:53] <anakron> XD
[00:56] <savvas> anakron: for today? yeah hehe
[00:56] <savvas> :)
[00:57] <anakron> :)
[00:57] <anakron> im a little bit angry with some packagers
[00:57] <anakron> :@
[00:58] <anakron> i like to fix some bugs with desktop file problems, but some of them have like 9 errors if you look it with desktop-file-validate
[00:59] <anakron> some entries duplicated ... i could go
[00:59] <JontheEchidna> Aren't upstreams generally responsible for .desktop files?
[01:00] <JontheEchidna> Although I suppose the packagers should report the problems upstream in the first place...
[01:00] <anakron> in one desktop file an icon  path sets an xml file
[01:00] <anakron> ...
[01:00] <anakron> yes i think too
[01:00] <anakron> but, trying to fix a bug, i found some others
[01:01] <Amaranth> an icon path sets an xml file?
[01:02] <anakron> yes
[01:02] <anakron> XD
[01:02] <savvas> anakron: there are more serious problems with .desktop files: http://groups.google.com/group/linux.debian.devel/browse_thread/thread/6f38b567c5684a60?pli=1
[01:07] <anakron> :O
[01:11] <savvas> :p
[02:02] <ScottK> Also some .desktop files predate the FDO spec.
[02:31] <fabrice_sp> Hi. How can I see why a package in Debian does not exist in Ubuntu? It's mig (http://packages.debian.org/lenny/mig)
[02:32] <fabrice_sp> weird: it's in Ubuntu, but it does not appear through packages.ubuntu.com
[02:33] <ajmitch> that generally happens if it failed to build
[02:33] <fabrice_sp> ajmitch, that's what I was looking for ;-) Thanks
[02:34]  * ajmitch can't recall where build logs are on LP now
[02:35] <fabrice_sp> you're right: there is a cyclic dependency between mig and  gnumach
[02:35] <ajmitch> that doesn't surprise me, given the intent of mig
[02:35] <StevenK> https://bugs.edge.launchpad.net/ubuntu/+source/mig/+bug/174851
[02:35] <fabrice_sp> (mig build depends on gnumach, but gnumach depends on mig?!)
[02:35] <ajmitch> why do you want it?
[02:35] <fabrice_sp> was just looking for all FTBFS to try to fix them
[02:35] <ajmitch> ah
[02:36] <ajmitch> ignore that one then :)
[02:36] <fabrice_sp> yep :-)
[02:36] <ajmitch> unless you really feel inspired to port ubuntu to the hurd
[02:36] <fabrice_sp> (already ignore some of them :-) )
[02:36] <fabrice_sp> hmmm, not really! :-)
[02:41] <Amaranth> shouldn't those packages be removed from ubuntu then?
[03:17] <pschulz01> anyone have a package which is a good example of 'debconf' settings?
[03:17] <pschulz01> s/have/know of/
[03:21] <dtchen_> pschulz01: just about any of the output from `apt-cache rdepends debconf|grep -v debconf-` should be a starting point
[03:25] <pschulz01> dtchen_: Ta.. 'adduser' seems to be a good (simple) one, and postfix gets a little more complicated.
[04:04] <ScottK> The postfix package combines a number of complex advanced packaging techniques and has accumulated some cruft over the course of the decade it's existed.  Probably not the best sample.
[04:12] <dtchen_> ScottK: hi, do you mind sponsoring both debdiffs for bug 336100, please?
[04:13]  * ScottK looks
[04:18] <ScottK> dtchen_: Is the man page the only thing that conflicts between the two packages?
[04:20] <dtchen_> ScottK: yes, but it doesn't make much sense to only remove the conflicting man page
[04:21] <dtchen_> kirkland made a similar fix for sysvconfig
[04:21] <ScottK> It seems odd that we patch service into sysvinit
[04:22] <ScottK> And then don't use the other one.
[04:24] <ScottK> dtchen_: From reading the man pages it looks like the chkconfig supports a status-all command that the sysvinit-utils one does not.
[04:30] <dtchen_> ScottK: unless i'm misreading sysvinit's debian/patches/94_service.dpatch, it does
[04:31] <ScottK> dtchen_: I thought it provided service, but not service-all.  I'm kind of tired though, so I might be misreading it.
[04:33] <dtchen_> there's no mention of service-all in either, but status-all is properly supported/compatible
[04:33] <ScottK> Sorry , status-all was what I meant.
[04:33] <ScottK> Did I mention I was tired ....
[04:34] <rgreening> o/ ScottK
[04:35] <ScottK> Heya rgreening.
[04:35] <rgreening> your not the only tired one. I think 4 hrs sleep in 2 nights
[04:37] <ScottK> dtchen_: Uploaded.  Thank you for your contribution to Ubuntu.
[04:37] <rgreening> ScottK: got any small jobs that need done. emphasis small... :)
[04:38] <ScottK> Plenty of Python bugs yet to squash.
[04:38] <rgreening> throw one at me
[04:38] <ScottK> rgreening: Are you on Jaunty?
[04:38] <rgreening> yes
[04:39] <ScottK> Then apt-cache rdepends python2.4 and pick anything not related to zope.
[04:39] <rgreening> ok. i'll look
[04:39] <ScottK> The only ones I've specifically looked and and not done already don't qualify as small.
[04:40] <rgreening> lol
[04:40] <dtchen_> ScottK: thanks
[04:51] <rgreening> ScottK: ok, I'll take a look at balder2d
[04:52] <ScottK> Great.
[04:56] <rgreening> no p0romises :)
[04:56] <rgreening> hehe
[04:57] <rgreening> ScottK: though, if I have luck like I did for the last python fix, who knows.
[04:57]  * ScottK is off to bed.
[04:57] <ScottK> I can look at it tomorrow if no one else does.
[05:33] <superm1> dtchen_, is there a particular reason you're holding off requesting sponsorship to get bug 336965 resolved since you have a solution ready?
[05:34] <superm1> (like trying to convince kernel team to upload with a PREEMPT enabled kernel to solve the problem etc)
[05:47] <dtchen_> superm1: i already raised the possibility of enabling PREEMPT for -generic in jaunty with members of the kernel team
[05:47] <dtchen_> superm1: the proposal was disapproved
[05:48] <dtchen_> superm1: (it was deemed too late in the devel cycle to enable such a kernel config option)
[05:48] <dtchen_> (...nevermind that it used to be enabled many releases ago...)
[05:49] <TheMuso> Well if its any ocmfort, we are not the only ones who don't have it enabled.
[05:49] <dtchen_> superm1: so - the only other option is to disable glitch-free again
[05:49] <TheMuso> comfort
[05:49] <dtchen_> TheMuso: right
[05:50] <dtchen_> i'm not interested in laying blame anywhere. i've been given operating parameters by the kernel team, so i'll work within them.
[05:50] <dtchen_> if i wanted politics, i would have chosen another project ;)
[05:51] <dtchen_> disabling glitch-free isn't really a bad option. i'll continue hacking away at PA to not eat so many resources, but i'm not going to drastically alter its behaviour. lennart would have my skull.
[05:52] <dtchen_> anyhoo, it's Z time
[06:07] <Laibsch> rgreening: can you upload packages?
[06:28] <rgreening> not yet.
[06:28] <rgreening> ask me after March 13th MOTU meeting :)
[06:29] <TheMuso> Laibsch: WHat would you like looked at?
[06:35] <Hobbsee> bugs--
[06:36] <Laibsch> TheMuso: thanks
[06:36] <Laibsch> bug 335891, for example
[06:37] <Laibsch> should be ready to upload
[06:38] <Laibsch> furthermore, python-4suite-xml and python-kaa-metadata need to be made compatible with python 2.6, they depend on python < 2.6
[06:39] <Laibsch> It could be that unlike many other packages, it is not a simple recompile job
[06:40] <Laibsch> I tried simply recompiling python-4suite-xml yesterday and it failed: https://launchpad.net/~r0lf/+archive/ppa/+build/890212
[06:41] <Laibsch> It is lacking one of the new python options, but I did not get around to retrying, yet
[06:46] <TheMuso> Laibsch: uploaded the audacious debdiff, don't  have time for the others sorry.
[06:49] <Laibsch> TheMuso: great, thanks
[06:49] <Laibsch> One more to cross off
[06:56] <didrocks> hello there
[06:57] <slytherin> hi all. anybody here with acer laptop with atheros wireless card?
[07:07] <rgreening> ScottK: I have a working balder2d. Seems to behave just fine with python2.6 build dep.
[07:07] <rgreening> ScottK: I'll submit a bug report for sponsoring later.
[07:11] <AnAnt> superm1: dkms is in Debian's NEW & BYHAND since 2 weeks !
[07:12] <superm1> AnAnt, ah wonderful!
[07:12] <superm1> i'm not sure what BYHAND is
[07:12] <superm1> but NEW is good news
[07:12] <AnAnt> superm1: something like Ubuntu's queue (the stage after REVU)
[07:13] <superm1> AnAnt, great.  i'm hoping the packaging is very similar (or identical) to the Ubuntu packaging, but if not i'll have to work with those guys to come to a consensus
[07:15] <AnAnt> superm1: http://ftp-master.debian.org/new/dkms_<IP_ADDRESS>-1.html
[07:15] <AnAnt> superm1: although I dunno how to get the diff.gz !
[07:15] <superm1> AnAnt, i can already tell there is some delta there
[07:15] <AnAnt> superm1: it's not on debian mentors
[07:15] <superm1> i'll try to get ahold of the pieces and examine tomorrow
[07:17] <AnAnt> btw, someone is making a package for cnetworkmanager (controlling NetworkManager under console)
[08:07] <Toadstool> good morning!
[08:08] <Hobbsee> morning Toadstool!
[08:08] <Toadstool> hey Hobbsee!
[08:49] <maxb> BYHAND is an unusual process where a package build submits arbitrary files as part of the upload for manual attention of the Debian ftp-masters, e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405925
[09:31] <savvas> should we remove bmpx package as well?
[09:31] <savvas> "The bmpx package has been removed from Debian so we are closing the bugs that were still opened against it."
[09:39] <savvas> pochu: here? should I file a bug report for bmpx removal? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517588
[09:39] <savvas> eh?
[09:40] <savvas> "RM: bmpx -- RoM; unmaintained upstream, uses outdated libraries"
[09:40] <savvas> :P
[09:40] <pochu> savvas: I guess so, unless somebody objects
[09:40] <savvas> ok :)
[10:08] <eMerzh> Hi all, if a motu want to review my package at http://revu.ubuntuwire.com/p/sqliteman i'll be glad to correct if there is errors :)
[10:09] <savvas> https://bugs.edge.launchpad.net/ubuntu/+source/bmpx/+bug/337659
[10:40] <_ruben> any hints on how to prevent stuff like this from happening: dpkg-shlibdeps: warning: dependency on libcairo.so.2 could be avoided if "debian/open-vm-tools/usr/lib/open-vm-tools/plugins/vmusr/libresolutionSet.so" were not uselessly linked against it (they use none of its symbols).
[10:40] <_ruben> im guessing its the fault of the software itself which does unnecesary linking?
[11:01] <directhex> _ruben, it typically means the app is using "pkg-config --libs foo" and that's pulling in things it doesn't strictly needf
[11:02] <directhex> e.g. "pkg-config --libs libavcodec" will link against libvorbisenc, even if not needed by the app
[11:03] <_ruben> directhex: ic .. im guessing it might have something to do that the package has both cli and gui parts (seperate packages), and that the deps might be set too "global" ..
[11:03] <_ruben> checking for gtk+-2.0 >= 2.4.0 (via pkg-config)... yes
[11:04] <_ruben> gonna be a bitch to hunt this down (im merging an upstream release of open-vm-tools, for personal use)
[11:35]  * _ruben kicks pkg-config around a bit
[12:14] <_ruben> i give up .. pkg-config seems to pull stuff out of its ass (or perhaps something else all together)
[12:18] <pochu> _ruben: I think that's because some library is using Libs: when it wants Libs.private:
[12:19] <_ruben> pochu: which would be something that's far beyond my current packaging skills :)
[12:20] <pochu> _ruben: well, that's an upstream issue, although upstreams usually don't care about that
[12:20] <pochu> _ruben: you can ignore the warning if you want
[12:20] <_ruben> pochu: upstream of the affected libs?
[12:21] <siretart> pochu: pkg-config is clearly underdocumented, so many upstreams write broken or at least suboptimal .pc files
[12:21] <_ruben> pochu: well, unless im seeing things wrong, it results in unneeded dependencies
[12:21] <siretart> the best we can do is to send fixes for broken .pc files upstream
[12:23] <pochu> siretart: agreed
[12:23] <pochu> siretart: there are some bugs/patches for pkg-config to document *.private
[12:23] <pochu> but not merged yet though
[13:14] <goshawk> RainCT: setting up pbulder-intrepid as you said..
[13:15] <AnAnt> Regarding debian bug #411851 , I tried the pm-utils hook script but it didn't work, does Ubuntu something else other than pm-utils for suspend/resume ?
[13:20] <goshawk> is it possible to install a package in a pbuilder environment for testing purposes? if yes, how?
[13:21] <RainCT> goshawk: Yes, pbuilder --login
 but my package is outside the chroot
 i can't see it from there
 i mean inside the chroot
[13:22] <RainCT> goshawk: you can use --bindmounts to share a directory between the host and the chroot, but be warned that this will delete everything inside the directory that you tell it (at least cowbuilder does)
[13:22] <directhex> or
[13:22] <directhex> or or or
[13:22] <directhex> cp foopkg /var/cache/pbuilder/build/*/tmp/
[13:23] <directhex> ^_^
[13:23] <geser> after pbuilder login
[13:23] <goshawk> so i inject the package into the chroot environment
[13:23] <RainCT> goshawk: so you can do something like:  mkdir /tmp/test; pbuilder --login --bindmounts /tmp/test; cp <files> /tmp/test
[13:23] <RainCT> directhex: uhm, right :)
[13:23] <goshawk> i used your wrapper scripts pbuilder-intrepid for it, does it accept --login? it seems no Error: «--login» is not a recognized argument.
[13:23] <directhex> goshawk, or use OTHERMIRROR and a PPA
[13:23]  * RainCT remembers that
[13:24] <RainCT> goshawk: then just   pbuilder-intrepid login
[13:25] <goshawk> i copied the package into the chroot like directhex said :)
[13:25] <goshawk> thx
[13:27] <goshawk> no auto completition for pbuilder-dist login, isn't it?
[13:28] <RainCT> nope
[13:28] <RainCT> it's a minimal environment, so it hasn't much :)
[13:28] <goshawk> i had to install the package with dpkg -i and then apt-get install -f for depends
[13:29] <RainCT> (you can install additional stuff doing   pbuilder-jaunty login --safe-after-login   installing it, and logging out, but don't put much place into it or it may interfere with builds)
[13:30] <RainCT> goshawk: That's right. You can also use "gdebi <file>.deb", which installs dependencies, but I'm not sure if that in the chroot
[13:32] <slytherin> quadrispro: geser: Thanks for working on the libdvdread transitions. :-)
[13:32] <goshawk> phone
[13:36] <elmargol> I have 2 git branches... and i like to import some changed lines... is there an easy way to do it?
[13:59] <rgreening> morning ScottK
[13:59] <rgreening> I seem to have balder2d python fixed
[13:59] <rgreening> just need to file proper bug
[14:00] <ScottK> OK.  Let me know and I'll take a look.
[14:00] <ScottK> rgreening: Or just pastebin me the debdiff
[14:01] <rgreening> sure
[14:01] <rgreening> 1 sec
[14:03] <rgreening> ScottK: try this http://paste.ubuntu.com/126280/
[14:04]  * ScottK looks
[14:05] <ScottK> rgreening: Did you test it works with 2.6?
[14:05] <rgreening> yeah. got it insalled here. ran and played the game. tried a bunch of options. went to fullscreen
[14:05] <rgreening> all seemed fine to me.
[14:05] <rgreening> got killed a lot
[14:06] <rgreening> :)
[14:06] <ScottK> OK.
[14:06] <ScottK> Why did you use just patch and not dpatch (dpatch is a lot less effort to integrate)?
[14:08] <rgreening> never played with dpatch
[14:08] <ScottK> rgreening: ^^^
[14:08] <rgreening> ^^
[14:08] <rgreening> :)
[14:09] <rgreening> patch was copy/paste from the cookbook.
[14:09] <ScottK> OK.  Interesting.  I've never actually seen someone do it that way before.
[14:09] <rgreening> I had tried quilt, but got some errors. I went to lowest common denominator...
[14:10] <rgreening> hehe
[14:10] <ScottK> There is some argument in a case like this for just inline the changes and let MoM handle it.
[14:10] <rgreening> old school from a new guy
[14:10] <ScottK> ;-)
[14:10] <ScottK> Also since it's not a K* program I wouldn't have put kubuntu in the patch name.
[14:12] <rgreening> doh
[14:12] <geser> ScottK: as you touched bmpx in the last days: any reason to keep it in Ubuntu? there is a removal request for it (bug #337659) I tend to confirm it
[14:12] <rgreening> ScottK: force of habit
[14:12] <rgreening> which I am trying to break by coming here :)
[14:12] <ScottK> geser: I just touched it for transition reasons.  I know of no reason not to remove it.
[14:13] <ScottK> rgreening: Fair enough.
[14:13] <directhex> i'm sleepy. falling asleep at my desk! zzzzzzzzzz
[14:13] <rgreening> well, I remembered the maintainer field ScottK heh
[14:13] <ScottK> rgreening: Also we don't put the maintainer change in debian/changelog.  It's actually Ubuntu Policy done to all packages, so no need to mention it.
[14:14] <ScottK> Yes, excessively.
[14:14] <directhex> update-maintainer!
[14:14] <rgreening> oh... new command for me
[14:14] <directhex> there we go, my sole reason for contributing to debian & syncing is becaise i suck at running update-maintainer so this way causes less admonishment from sponsors
[14:15]  * Laney fluffles directhex
[14:15] <Laney> lots of lib syncs I see
[14:15] <ScottK> rgreening: Also ~ppa1 in the revision ...
[14:15] <rgreening> of course, I was testing it local.
[14:15] <directhex> Laney, yes, slomo went nuts this morning, and meebey did a few last night
[14:15] <Laney> \o/
[14:15] <rgreening> was going to change in the bug
[14:15] <directhex> Laney, one or two more i can file once the mirror push is done
[14:16] <rgreening> too quick sending debdiff
[14:16] <rgreening> ScottK: let me redo the deb dif...
[14:16] <ScottK> rgreening: No need.  I've been editing as I go along and all this stuff is minor.
[14:16] <rgreening> patch is missing something
[14:17] <rgreening> 1 sec
[14:17] <rgreening> maybe...
[14:17] <rgreening> nm.
[14:17] <rgreening> Im still asleep
[14:18] <rgreening> its all good
[14:21] <rgreening> ScottK: i'm still sending a proper diff... to ensure I got it corrected. Call it lerning by doing it over.
[14:21] <ScottK> rgreening: OK.  I'll look at it, but I'm already test building.
[14:22] <rgreening> ScottK: http://paste.ubuntu.com/126284/
[14:22] <rgreening> think I got it all this time
[14:24] <ScottK> I think so.
[14:24] <ScottK> rgreening: Next question: Does this go back to Debian?
[14:24] <rgreening> I think it's fairly innocous
[14:24] <rgreening> so it surely can
[14:26] <ScottK> Does Debian have Python 2.6 yet?
[14:26] <rgreening> that, I do not know.
[14:26] <ScottK> rgreening: Uploaded:  Thank you for your contribution to Ubuntu.
[14:26] <rgreening> yw.
[14:26] <rgreening> one less python package to worry about
[14:27] <ScottK> rgreening: rmadison -u debian python2.6 is an easy way to find out.
[14:27] <goshawk> RainCT: done
[14:27] <rgreening> I'll try another one in a bit. I assume there are sill some available to work on.
[14:27] <rgreening> ok
[14:27] <rgreening> ty ScottK
[14:28] <rgreening> hmm... rmadison doesn't appear to be reporting anything here ScottK. silently returns nothing.
[14:28] <goshawk> RainCT: and gdebi is not good in pbuilder, it carries on a lot of libgtk stuff and can make the pbuilder image dirty...
[14:28] <ScottK> rgreening: Great.  What I'd do with this is file it as a wishlist bug in Debian BTS and caveat the bug as ... when you get 2.6.....
[14:29] <rgreening> ok
[14:29] <ScottK> rgreening: I'd just send the patch, not the patch system stuff.
[14:29] <rgreening> good enough
[14:29] <rgreening> rmadison doesnt seem to work
[14:29] <rgreening> 4 me
[14:29] <ScottK> It looks like they Debian maintainer is also upstream, so I expect they'll just do a new release or something
[14:29] <ScottK> rmadison for Ubuntu is extremely slow.
[14:29] <rgreening> it just returns immediately with nothing
[14:31] <ScottK> In the case of Debian for python2.6 that's correct as they don't have it.
[14:31] <ScottK> Try it with 2.5
[14:31] <maxb> Why is Ubuntu's rmadison so slow? Is it just that people.ubuntu.com is overloaded?
[14:31] <rgreening> ScottK: ah
[14:31] <ScottK> maxb: Because it integrates with Launchpad I believe.
[14:31] <maxb> hmm
[14:32] <rgreening> ScottK: that works better
[14:32] <jpds> ScottK: It uses a mirror of the archive at people.u.c
[14:32] <ScottK> jpds: OK.  Then maybe maxb is right.
[14:32] <ScottK> It is painful, so if someone could figure a faster way ....
[14:32]  * maxb wonders how easy it would be to set up an external rmadison driven off the Packages/Sources files
[14:32] <jpds> http://people.ubuntu.com/~ubuntu-archive/madison.cgi
[14:34] <POX_> ScottK: FYI: python2.6 has the same maintainer in Ubuntu and Debian
[14:35] <ScottK> POX_: Yes, I'm aware.  I'm guessing he's just waiting for some transition to clear or something for Debian.
[14:36]  * POX_ wonders why the python2.6 transition is not made by Debian guys as clearly they have more manpower
[14:37]  * ScottK doesn't wonder.
[14:37]  * ScottK just fixes ....
[14:37] <geser> POX_: more manpower doesn't imply that Debian moves faster than Ubuntu
[14:37] <POX_> isn't syncing easier?
[14:38] <POX_> geser: yeah, python2.5 transition was made faster than in Ubuntu (no, packages with broken memory allocation doesn't count :P)
[14:38] <geser> POX_: usually syncing is easier, but due to FF we might need to patch them anyway
[14:47] <bddebian> Heya gang
[14:47] <sistpoty|work> hi bddebian
[14:47] <bddebian> Hi sistpoty|work
[14:51] <mok0> POX_: Debian guys are busy fighting over python-central
[14:55] <POX_> mok0: no, we're not. python-support will be used, I'll make sure of it
[14:56] <POX_> read debian-python logs, nobody else wants python-central, even doko isn't complaining
[14:56] <geser> Hi bddebian
[14:56] <doko> POX_: ?
[14:56] <mok0> POX_: kk
[14:56] <mok0> POX_: ah :-)
[14:56] <POX_> doko: you didn't reply on<EMAIL_ADDRESS>[14:57] <doko> POX_: be assured, I will. to your posting as well
[14:57] <POX_> it's too late :-(
[14:58] <ScottK> Depends on for what.  If he's got more good issues, then either you need to make Joss fix them or go back and reconsider.
[14:59] <POX_> it's always ok to report bugs, of course
[15:02] <bddebian> Heya geser
[15:19] <quadrispro> fabrice_sp__: i'm working on the tellico merge
[15:21] <quadrispro> fabrice_sp__: I think it couldn't be a good idea drop khelpcenter from Recommends field, I would prefer replace it with khelpcenter4
[15:21] <quadrispro> what do you think about this?
[15:39] <quadrispro> fabrice_sp__: package builds fine, let me know what you think about the point above, going away for some minutes
[15:44] <rgreening> Scottk: submitted bug to debian for balder2d
[15:44] <ScottK> Great.
[16:00] <cristi> hey again! so, i registered in launchpad, i read the packaging guide and tried the hello example. what should i do next in order to be able to contribute to ubuntu with packages?
[16:05] <savvas> er... I think the translations /usr/share/locale are missing from gdebi-core
[16:05] <DktrKranz> ScottK, sistpoty|work, nhandler: MC asked for motu-release charter to be published. Preliminary draft was here https://wiki.ubuntu.com/MOTU/MotuReleaseCharter, could we arrange to make a final version soon?
[16:05] <ScottK> Without actually admitting that MC has such authority to demand it, I don't see why not.
[16:06] <ara> cristi: you could have a look to the bugs listed as bitesize (https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize). These are sometime easy to fix
[16:06] <savvas> cristi: try providing debdiff patches to bitesize (easy) bugs: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[16:06] <savvas> darn :P
[16:06] <sistpoty|work> DktrKranz: looks good to me
[16:07] <cristi> ara, savvas thank you, i'll give it a look
[16:15] <savvas> Is the default locale dir /usr/share/locale or /usr/share/locale-langpack ?
[16:17] <savvas> ScottK: do you happen to know? ^
[16:19] <huats> geser: hey
[16:19] <huats> I am taking care finally of the python-webkit update
[16:19] <huats> and thus I will deal with the 2.6 transition needed
[16:20] <ScottK> savvas: No.
[16:21] <savvas> ok, thanks
[16:22] <savvas> I guess I should figure out a way to provide it for both in the program
[16:23] <savvas> probably /usr/share/locale is for the application and /usr/share/locale-langpack for the language packs
[16:34] <jdong> groan why do USB optical mice need to go into power saving mode and dim the optical circuitry?
[16:34] <jdong> it's not like that 5V/100mA LED is an atrocious waste of power and worthy of mouse lag on idle...
[16:35] <cristi> uhm, is this ok in the packaging guide? cp hello-2.1.1.tar.gz hello_2.1.1.orig.tar.gz  there is no hello-2.1.1.tar.gz, but only the .orig
[16:35] <cristi> what should i do copy the .orig ? is this what was meant?
[16:36] <jdong> if you already have the orig then you are okay
[16:36] <jdong> all that step says is that your orig should be named like hello_2.1.1.orig.tar.gz
[16:36] <jdong> the underscore before the version, .orig. before the tar.gz
[16:36] <cristi> jdong ah ok, thanks
[16:52] <cristi> how deep should my c++ knowledge be in order to fix bugs or make packages?
[16:53] <ScottK> cristi: None is sufficient.
[16:53] <ScottK> From a programming perspective if you have a bit of shell, that's enough.
[16:53] <ScottK> It's often useful if you do have more, but there's plenty to do if you don't.
[16:54] <cristi> ScottK can you give an example of such a bug that doesn't require cpp ?
[16:55] <ScottK> Currently we're going through a Python transition.  So we need to update a bunch of packages.
[16:55] <ScottK> Virtually none of those (and it's a lot of packages) need any programming.
[16:56] <ScottK> I did 4 today that just needed a recompile test and a no-change upload to build in the new environment.
[16:56] <cristi> ScottK i see
[16:56] <ScottK> Some of them need changes in their debian/rules or in postinsts scripts.
[17:27] <RainCT> niiice, geany now has highlighting for debian/rules :)
[17:38] <mok0> RainCT: emacs has highlighting for debian/control :-P
[17:39]  * RainCT will write a patch for that :P
[17:45] <hggdh> could a MOTU please tell me what is wrong on http://revu.ubuntuwire.org/p/libpst (lintian warning)?
[17:46] <mok0> hggdh: it doesn't look like anything's wrong
[17:46] <hggdh> mok0, why the warning, then?
[17:46] <mok0> hggdh: what warning?
[17:46] <mok0> hggdh: pastebin it
[17:47] <hggdh> mok0, http://revu.ubuntuwire.com/revu1-incoming/libpst-0902260309/lintian
[17:49] <mok0> hggdh: that's ok, original-maintainer is an ubuntu-specific field that lintian doesn't know about
[17:49] <hggdh> mok0, thanks
[17:50] <geser> but the version is wrong
[17:50] <eMerzh> if some motu want to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman
[17:50] <hggdh> geser, ?
[17:51] <geser> hggdh: it should be 0.6.27-0ubuntu1 instead of only -1 (that's reserved for Debian)
[17:52] <hggdh> geser, thanks, will correct
[17:54] <hggdh> ah, if I add an Ubuntu extension to the version, lintian does not complain anymore about original-maintainer in .dsc
[18:03] <RainCT> Is someone around who hasn't debootstrap intalled?
[18:05] <maxb> I'm sitting at a usb-creator intrepid installation upgraded to jaunty, if that helps
[18:06] <RainCT> maxb: Does dpkg -l | grep debootstrap return something?
[18:07] <maxb> uhm, I'm quite likely to have installed it manually
[18:09] <geser> RainCT: checked in a jaunty chroot: no output and the return value is 1
[18:10] <RainCT> geser: OK. Can you please check if directory /usr/share/debootstrap/scripts/ exists?
[18:10] <RainCT> I guess no, but just to be sure :)
[18:11] <geser> RainCT: ls: cannot access /usr/share/debootstrap/scripts/: No such file or directory
[18:11] <RainCT> geser: great, thanks
[18:13] <RainCT> ok, bug #334848 is fixed now :)
[18:33] <Brucevdk> Question, I'm trying to upload a package to a PPA. I've already sent the orig.tar.gz and now it's complaining that I'm trying to send a new orig.tar.gz that is different from the one already uploaded (which was associated with a failed build). That's the point though, I don't actually want to change the version number or anything. Is it possible to delete the orig.tar.gz or work around this?
[18:34] <Brucevdk> Maybe this belongs in #launchpad
[18:35] <RainCT> Brucevdk: delete the package, wait some days and try uploading it again
[18:35] <Brucevdk> RainCT: days :'(
[18:36] <RainCT> Brucevdk: not sure if you have to wait that much or it'll work right away
[18:36] <Brucevdk> RainCT: well, I'll do this, but if there are any other options I wouldn't mind hearing about them ;-)
[18:51] <Laibsch> RainCT: Thanks a lot!
[18:52] <RainCT> Laibsch: no problem :)
[18:54] <Laibsch> ScottK: Do you know of a simple way to find packages still depending on python < 2.6?
[18:54] <Laibsch> I'm sure, there is some dpkg or apt magic to get such a list
[18:55] <james_w> Laibsch: take a look at grep-dctrl
[18:55] <ScottK> It's not simple, but grep-dctrl is the tool you want to weild.
[18:55] <james_w> dctrl-tools is the package
[18:55] <Laibsch> alright, I think I used it once or twice in the past
[18:56] <Laibsch> I'll see about that python-4suite-xml package first
[18:56] <james_w> "grep-dctrl -FDepends -sPackage "python (<< 2.6" < /var/lib/apt/lists/*source*" might do it
[18:56] <Laibsch> It's the last one that is actually still bothering me
[18:56] <Laibsch> personally
[18:56] <ScottK> python-xml needs doing.
[19:05] <Laibsch> The package I'm trying to fix calls setup.py twice in debian/rules
[19:05] <Laibsch> Once for config
[19:05] <Laibsch> Once for build
[19:06] <Laibsch> Do I need to add "--install-layout=deb" to both calls?
[19:06] <Laibsch> I assume it should be sufficient for "build" only
[19:08] <Laibsch> Actually, setup.py is called much more often, when do I need to add the install-layout thing?
[19:09] <ScottK> install
[19:10] <Laibsch> ScottK: I assume, I should add it for install_html, too, though, right?
[19:10] <ScottK> Probably not.   You just want it when it's installing the python bits, but I'd build it and then check the resutls.
[19:16] <Laibsch> yes
[19:17] <Laibsch> the only problem is, the package took three hours to fail the build yesterday ;-)
[19:18] <Brucevdk> I feel for you, Estimated build start: in 3 hours :'(
[19:19] <Laibsch> oh
[19:19] <Laibsch> that would be the results in only after 6 hours!
[19:20] <Laibsch> actually, it says the build is only estimated to start in 4 hours here!
[19:32] <quadrispro> fabrice_sp: I'm sponsoring your application, keep up the good work ;)
[19:32] <bobbo> is there a list of packages that still need to be fixed for the Python 2.6 transition?
[19:32] <quadrispro> bobbo: hi!
[19:33] <bobbo> hey quadrispro :)
[19:34] <quadrispro> bobbo: I remember you was coming in Italy some week ago
[19:35] <Laibsch> bobbo: python-xml was mentioned here
[19:35] <Laibsch> I'm also working to get such a list from dpkg-ctrl
[19:35] <superm1> Laibsch, i'm looking at it right now
[19:35] <Laibsch> I failed so far
[19:35] <superm1> Laibsch, i think i might have it under control
[19:35] <Laibsch> superm1: cool, thanks
[19:38] <superm1> Laibsch, actually it looks like i was beat
[19:38] <superm1> RainCT, got it
[19:38] <superm1> thanks RainCT :)
[19:39] <ScottK> That should unblock quite a number of things.
[19:40] <superm1> ScottK, not fully - only in terms of apt letting them through.  see my mail to ubuntu-devel ML.  all packages using python-xml are still going to be broke.
[19:40] <ScottK> Right.  Forgot about that.
[19:41] <ScottK> superm1: I suspect doko would advise switching to a different/not deprecated XML library.
[19:42] <superm1> ScottK, well can't force upstreams to do that necessarily
[19:42] <Laibsch> if anybody with a bit of RAM in their build machine feels like trying to build https://launchpad.net/%7Er0lf/+archive/ppa/+files/python-4suite_1.0.2-7ubuntu1.dsc I'd appreciate it
[19:42] <ScottK> True, but in many cases we can patch our way around it.
[19:42] <Laibsch> the PPA will take another couple of hours to start
[19:43] <superm1> ScottK, is there anything that's close to API compatible with PyXML in the first place?
[19:44] <ScottK> superm1: It depends on what part of pyxml you're using.  Some bits are in Python itself, others can be found in other packages, some bits are unique to pyxml
[19:44] <ScottK> We tried, and failed once to push it all the way out of the archive.
[19:44] <fabrice_sp> quadrispro, thanks ;-)
[19:44] <superm1> ScottK, looks like xml.dom, xpath, htmllib
[19:45] <ScottK> It was a while ago I looked at these, so I don't recall....
[19:45] <superm1> and there's some comments that "The Python SGML based HTML parser is unusable (it finds tag starts/ends in the worst way possible" in the code, so not too reassuring
[19:59] <Zarel> Hi, everyone. The warzone2100 package in the intrepid repositories is very out of date - it's 2.1.0-beta4, and 2.1.1 has already been released. Since this is beta -> stable, nearly all the changes have been [important] bugfixes, so is there any chance someone could go and update it?
[19:59] <Zarel> -> http://packages.ubuntu.com/intrepid/warzone2100
[20:11] <fabrice_sp> Zarel, before being able to have it in Intrepid, we need to have it in Jaunty. Actual version for Jaunty is 2.1.0-1...
[20:12] <Zarel> fabrice_sp: Can we at least get 2.1.0-1 into Intrepid, then?
[20:13] <fabrice_sp> we are in Feature Freeze, so we need a good reason to upgrade it :-)
[20:13] <Zarel> fabrice_sp: It's a bugfix release, no new features?
[20:13] <Zarel> Is that a good enough reason?
[20:13] <Zarel> Also, it's stable rather than beta.
[20:14] <fabrice_sp> Zarel, yeah, but in this case, you have to compare the version that we will have in Jaunty and the latest one, so its stable with stable
[20:14] <fabrice_sp> I also have to check if no new features are there
[20:15] <Zarel> What do you mean by "compare the version"?
[20:15] <fabrice_sp> it seems to be a fix only release, you're right
[20:16] <fabrice_sp> so I'll try to compile the version in Debian, and if it works, I'll fill a sync request
[20:16] <Zarel> Thanks.
[20:17] <fabrice_sp> Zarel, do you volunteer to test it?
[20:17] <fabrice_sp> :-D
[20:17] <Zarel> Define "test"
[20:18] <fabrice_sp> install the version I will put in my ppa, and check it's working fine
[20:19]  * fabrice_sp builds warzone2100 2.1.1-1
[20:19] <Zarel> I only have three installs of Ubuntu - one of them I don't have package installation permissions, and the other two are VMs which aren't fast enough to run Warzone. Sorry. :/
[20:20] <Zarel> I can verify that sound apparently doesn't work on a default install of Warzone in Ubuntu. We've gotten lots of bug reports about that. :P
[20:21] <fabrice_sp> You're upstream?
[20:21] <Zarel> Depends on your definition of "upstream". For most definitions, I'd say yes.
[20:22] <fabrice_sp> k. Nice game by the way!
[20:22] <Zarel> Thanks.
[20:24] <fabrice_sp> it builds fine. I'll fill the sync request
[20:25] <directhex> isn't warzone an old strategy game from the 90s? or am i misremembering
[20:25] <Zarel> directhex: 1999, to be exact.
[20:25] <Zarel> It was open-sourced in 2004.
[20:26] <directhex> oh, neato
[20:30] <fabrice_sp> directhex, if you're interested in sponsoring the sync, I'll give you the bug number as soon as it appears ;-)
[20:30] <directhex> fabrice_sp, i'm not a motu
[20:32] <fabrice_sp> just in case some MOTU or U-C-D is interested in warzone2100: bug #337915
[20:35] <Zarel> Eheh, 2.1.1 isn't that big of a deal - it only had one bugfix from 2.1.0, and that was only for Macs.
[20:36] <fabrice_sp> Zarel, yes. It seems to be quite stable ;-)
[20:36]  * fabrice_sp installing version 2.1.1
[20:41] <fabrice_sp> working fine, even with sounds ;-)
[20:42] <Zarel> :D
[20:42] <Zarel> Good sign.
[20:42] <fabrice_sp> yep :-)
[20:45] <_16aR_> Hello
[20:45] <fabrice_sp> hello _16aR_
[20:45] <_16aR_> When we compile for amd64, does the CFLAGS enables old i686 function like MMX, etc ?
[20:45] <_16aR_> or we must enable them into the debian/rules ?
[20:46] <RainCT> fabrice_sp: sync request ack'd
[20:46] <_16aR_> by the way, how can we help for package stabilisation in jaunty ?
[20:46] <fabrice_sp> thanks RainCT ;-)
[20:47] <RainCT> No problem. I'm off now, see you tomorrow :)
[20:47] <fabrice_sp> CU! bye
[20:47] <fabrice_sp> _16aR_, you can check http://qa.ubuntuwire.com/
[20:48] <fabrice_sp> and check rcbugs, for example
[20:49] <_16aR_> ok fabrice_sp, thanks
[20:50] <fabrice_sp> you're welcome ;-)
[21:25] <quentusrex> Hello
[21:25] <quentusrex> Anyone here use kvm?
[21:26] <quentusrex> or libvirt?
[21:30] <directhex> a little
[21:44] <jpds> quentusrex: Might want to try #ubuntu-virt too. :)
[21:44] <quentusrex> jpds: I'm in there too :)
[21:45] <quentusrex> directhex: would you be interested in helping to backport libvirt 6.1 to intrepid?
[21:45] <quentusrex> or even to hardy?
[21:45] <directhex> quentusrex, i can test on intrepid, but not hardy. and i have too much on my plate to help do it
[21:46] <quentusrex> yeah, I can test on intrepid as well
[21:46] <quentusrex> I'm not too skilled on how to package for ubuntu yet...
[21:47] <Amaranth> cody-somerville: how does one get to talk in #xfce-dev?
[22:04] <khashayar> Hey folks, does anyone here have a couple of minutes to review pencil (http://revu.ubuntuwire.com/details.py?package=pencil)? We really need it for ubuntu studio (we're going to file exceptions).
[22:09] <cody-somerville> Amaranth, like that
[22:20] <TheMuso> c
[22:45] <ripps> Is it possible to modify functions in a debian/rules file that's been inherited from a include?
[22:46] <ripps> I'm trying to add dpatch support, but the file is practically only includes from cdbs.
[22:46] <ScottK> There's a cdbs rule for dpatch you can use.
[22:47] <ScottK> Don't try and add it by hand.
[22:47] <ripps> okay, thanks
[23:08] <POX_> doko: make sure you don't have "/local" somewhere in distutils.cfg (another user complained about it)
[23:08] <orci> hi all, sorry again if wrong place but wiki.ubuntu.com is having problems
[23:13] <ScottK> POX_: I had that once and it just needed the layout-deb magic added.
[23:13] <ScottK> orci: This is the wrong place.  I suspect #canonical-sysadmin.
[23:13] <POX_> /usr/local or /local?
[23:14] <ScottK> Oh.
[23:14] <ScottK> Nevermind.
[23:14] <ScottK> /usr/local
[23:14] <POX_> maybe I misunderstood him, though
[23:14]  * POX_ goes to bed
[23:14] <orci> ScottK-desktop, OK thanks
[23:47] <mrooney> hello motu friends, what are we doing with bugs resulting from the python 2.6 upgrade such as bug #338004, where python < 2.6 is required
[23:52] <james_w> mrooney: ah, that's where we just haven't got to it yet
[23:52] <james_w> there are people tracking those down and fixing them
[23:52] <james_w> I thought you were referring to a bug about a package now working when run under python2.6
[23:53] <mrooney> james_w: ah so a package which explicitly requires << python 2.6 will be noticed, ones that don't declare that are the ones to announce?
[23:54] <james_w> mrooney: yeah, in general
[23:54] <james_w> we can search for the former
[23:54] <james_w> the latter might be very subtle
[23:54] <mrooney> james_w: right you couldn't automatically detect that except by running some tool to find common upgrade issues on all the python packages
[23:56] <ajmitch> especially when the failures end up being in things like wxpython
[23:56] <mrooney> ajmitch: oh, has that happened
[23:56] <mrooney> I have a wxPython app in Jaunty
[23:57] <ajmitch> things like that have happened, wxpython was just an example of a complicated steaming mess :)


[00:45] <LinDol_> hi all
[00:46] <LinDol_> have a great weekend. :)
[07:34] <LinDol> hi all
[09:12] <Noskcaj> darkxst, Could you leave a testimonial for me? https://wiki.ubuntu.com/Noskcaj
[09:37] <Noskcaj> darkxst, Has it got to late to try and force upower through with a separate upower-0.99 package?
[09:45] <darkxst> Noskcaj, its worth a try
[09:45] <darkxst> though indicator-power still needs porting
[09:47] <darkxst> Noskcaj, I will add  a testimonial
[09:47] <darkxst> but can't do it now, when is your meeting?
[09:47] <Noskcaj> darkxst, 6th of Oct, probably
[09:47] <Noskcaj> I need day light savings back
[09:48] <darkxst> ok, will get to it during the week sometime
[09:48] <Noskcaj> great
[09:50] <darkxst> Noskcaj, also re upower, gnome-desktop is still a mess, don't know if that will even happen now this cycle ;( So I will try backport power pluging to g-s-d/u-s-d
[09:50] <Noskcaj> We still need bluez5 for desktop to really work don't we?
[09:50] <Noskcaj> but thanks
[09:51] <darkxst> Noskcaj, thats not really urgent, everything 3.12 is working fine with bluez4 and a few reverted commits
[09:56] <darkxst> Noskcaj, many of the Canonical devs (including charles) are tied up with the phone rtm
[23:36] <vw72> what version of gnome-shell will be in UG14.10?
[23:37] <ahoneybun> vw72: I know 3.12 is in the beta
[23:37] <vw72> I saw that but didn't know if it was finalized or not. I ask because the 3.13.x gnome-shell seems pretty stable and 3.14 will be just a month before 14.10
[23:38] <vw72> If UG ships 3.12, is it safe to assume that 3.14 will be put into a ppa?
[23:42] <ahoneybun> yea 3.14 most likely will be on a ppa
[23:45] <vw72> excellent!


[08:05] <guiverc> https://fridge.ubuntu.com/2022/11/23/ubuntu-weekly-newsletter-issue-762/
[08:14] <guiverc> uwn 762 shared twitter, (reddit),, (telegram)
[12:49] <guiverc[m]> (I forgot fb for uwn sorry)
[22:00] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 762 @ https://fridge.ubuntu.com/2022/11/23/ubuntu-weekly-newsletter-issue-762/ (by guiverc)
[22:00] -SwissBot:#ubuntu-news- ::Fridge:: Announcing the results of the Ubuntu Membership Board Elections @ https://fridge.ubuntu.com/2022/11/23/announcing-the-results-of-the-ubuntu-membership-board-elections-2/ (by guiverc)
[22:00] -SwissBot:#ubuntu-news- ::Fridge:: Extended call for Ubuntu Technical Board candidates @ https://fridge.ubuntu.com/2022/11/23/extended-call-for-ubuntu-technical-board-candidates/ (by guiverc)


[01:05] <fta> jdstrand, i can't create a guest os for kvm because of apparmor
[01:06] <fta> jdstrand, operation="open" pid=11396 parent=1 profile="libvirt-16b5a997-ff4f-a3bf-94a4-1841414ab5cf" requested_mask="::rw" denied_mask="::w" fsuid=0 ouid=1000 name="/data2/qemu-vms/foo.iso"
[05:09] <jdstrand> fta: actually, that should be bug #453335 and the iso is readable
[05:09] <jdstrand> fta: it should still work (it certainly does here)
[05:10] <jdstrand> fta: I'm giong offline, but if you are having problems, please add apparmor deny messages and any other pertinent info to that bug
[05:15] <jdstrand> fta: let me clarify. when you create a new vm using the iso, if you see the guest boot the iso, then everything is ok despite that error (ie the guest clearly can read the iso)
[05:17] <jdstrand> fta: if the guest doesn't boot at all, try disabling apparmor by adding 'security = "none"' to /etc/libvirt/qemu.conf, then do 'sudo /etc/init.d/libvirt-bin restart'. if the guest still doesn't boot, it isn't apparmor. if it does, then please add info to the bug
[05:17] <jdstrand> fta: (boot the iso that is)
[05:21] <micahg> jdstrand: I just gave you another apparmor/ff bug
[08:20] <eagles0513875> morning guys
[10:08] <nikolam> hi.
[10:08] <nikolam> I think Seamonkey2 is ready to be included in Ubuntu for testing.
[10:09] <nikolam> What do you think (it is ar RC at the present and it works just fine)
[14:47] <fta> jdstrand, hi, if it's not apparmor, i don't know what's wrong then. i create a vm from an iso, it creates the volume, puts some files in it, then it wants to reboot, but after reboot, i see the bios, then nothing, black screen with a cursor
[14:48] <nikolam> seamonkey leaks after few hours of use, and leaks very bad
[14:48] <fta> jdstrand, i had a guest os on that box before, it was working fine, but it can no longer boot. that's why i want to create a fresh one. maybe it's another problem..
[14:49] <nikolam> 1.1.17 and previous 1.1x
[14:53] <eagles0513875> fta: i find that i have bugs that surface in a vm that dont on my duelboot on my laptop
[14:53] <eagles0513875> you cant accuratly trust vms it seems like
[14:54] <fta> it used to work just fine.
[14:55] <eagles0513875> i have random lockups on my vbox vm with karmic fully updated where the mouse dont work
[14:56] <nikolam> eagles0513875, i think karmic is not released yet.
[14:56] <nikolam> please go to #ubuntu+1
[14:56] <nikolam> and do report a bug about
[14:57] <eagles0513875> nikolam: tyvm i know bout that channel im just saying is vms will give bugs that a duel boot wont
[14:57] <nikolam> eagles0513875, https://help.ubuntu.com/community/ReportingBugs
[14:57] <nikolam> and create launchpad account so you can report bugs in future
[14:58] <eagles0513875> nikolam: that mouse bug is a known bug from what i was told in +1 and i already have one
[14:58] <eagles0513875> i have been using kubuntu for quite some time fyi
[14:59] <nikolam> eagles0513875, sorry, I was thinking I am on #xubuntu, sorry
[14:59] <eagles0513875> its ok nikolam
[14:59] <eagles0513875> fta: you have a duel boot machine you can test on
[15:04] <fta> eagles0513875, i don't have any dual boot machines. i've been using linux only for a very long time
[15:05] <eagles0513875> same here but im finding the mouse issue only surfaces on my vm not on duelboot itself
[15:05] <eagles0513875> if there is anything i can teset let me know
[15:25] <jdstrand> fta: I'd look in the list of open bugs in libvirt and see if others are having the same problem. while I wrote the apparmor security driver for it, I'm not the maintainer and not sure what the problem could be
[15:25] <jdstrand> fta: feel free to open a new bug or bring it up in #ubuntu-virt
[15:25] <jdstrand> micahg1: ack
[15:27] <fta> jdstrand, ok. i guess i'm stuck for today then
[15:27] <jdstrand> sorry :/
[15:28] <jdstrand> fta: the way you described it, it sorta sounds like a guest/kvm interaction issue. you could try starting the guest without libvirt with kvm, and then with qemu to try to narrow down the problem
[15:34] <fta> kvm does the same, and qemu complains about missing /dev/kqemu
[15:35] <jdstrand> fta: so it is a kvm bug
[15:35] <jdstrand> fta: kirkland is who deals with those
[15:36] <jdstrand> fta: with qemu, try with '-no-kvm'
[15:39] <fta> no such option
[15:39] <fta> -no-kqemu ?
[15:39] <fta> it boots in loop
[15:45] <jdstrand> fta: I don't know why it is complaining about /dev/kqemu, since it isn't available in karmic. possibly another bug
[16:17] <fta> micahg1, just added you to my bot watchers list for umd (moz daily ppa) and usd (songbird daily)
[16:18] <fta> micahg1, let me know if you want to receive the FTBFS emails, i can relay them to you
[19:18] <micahg> fta, thanks
[19:22] <fta> micahg, you should have received 2 emails
[19:24] <micahg> got them
[19:32] <fta> there are a few things to check in those emails, like verify that new tarballs are not too big/small compared to the previous ones; check the reasons when the title doesn't say OK, etc..
[21:33] <BUGabundo> g'nuit guys


[06:37] <RAOF> Man, don't double-tap <tab> in gdb...
[06:38]  * RAOF 's console scrolls through the 2MB or so of symbol names
[06:39] <tvoss_> RAOF, verbosity for the win :)
[06:40] <RAOF> Ahem.
[06:40] <RAOF> Create the pipe *before* you fork()
[06:40] <RAOF> And we win!
[06:43] <RAOF> And with that, EOD!
[06:45] <RAOF> Turns out that std::future is a quick way to large symbols.
[06:47] <duflu> RAOF: Not enough bytes in your life?
[06:47] <duflu> Later
[12:07] <anpok> is anybody of you succesfully using sbuild to build mir?
[12:08] <anpok> for armhf
[12:09] <anpok> i just got weird cmake problems - i get cmake messages like successfully found pkg-config \n egl found and then on the next line pkg-config not found (found version 0.26) and glesv2 not found...
[12:13] <anpok> http://paste.ubuntu.com/6802564/
[12:44] <kgunn> anpok: are you following this https://lists.launchpad.net/ubuntu-phone/msg05556.html
[12:46] <anpok> yes, but I also followed the configuration steps from here https://wiki.ubuntu.com/SimpleSbuild
[14:52] <kgunn> anpok: i tried week before last and i was actually able to build...but then failed the build's unit test run
[14:53] <kgunn> hmmm, kinda looks like the chroot might not have set up correctly?
[14:53] <kgunn> only a guess
[15:00] <alan_g> Hmm, I just tried cross-building and got "/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/arm-linux-gnueabihf/libpthread.so.0 inside" whatever that means
[15:09] <alan_g> ... but zapping the "partial-armhf-chroot" fixes it
[15:09] <dandrader> is that a known problem? https://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/713/console
[15:10] <dandrader> "tests/acceptance-tests/test_protobuf.cpp:104:35: error: inheriting constructors are not supported"
[15:11] <alan_g> dandrader: I thought that was supported now
[15:11]  * alan_g wonders which clang version this is
[15:14] <anpok> clang-3.2
[15:15] <alan_g> dandrader: not a known problem, but that C++ support is fairly recent in clang. 3.4 definitely supports it.
[15:16] <dandrader> alan_g, that failed in https://code.launchpad.net/~dandrader/mir/SwitchingBundlePrint/+merge/202447. so the code is already there. maybe CI changed its clang version?
[15:18] <alan_g> dandrader: maybe. Or maybe the node is out of date. I guess #ubuntu-ci-eng can tell us
[15:18] <dandrader> alan_g, should I ask them or will you do it?
[15:18] <alan_g> I can
[15:18] <dandrader> alan_g, ok, thanks!
[15:26] <alan_g> mterry: do you know which branches were involved in robert_ansell's failed attempt to get USC working without a filesystem endpoint? I'm suspecting the problem was lp:1271655 but can't find his code.
[15:28] <mterry> alan_g, hmm, let me dig.  I remember they all had similar names
[15:28] <alan_g> mterry: thanks
 alan_g, hmm, let me dig.  I remember they all had similar names
 alan_g, at least lp:~robert-ancell/lightdm/private-mir-connection and lp:~robert-ancell/unity-system-compositor/private-mir-connection
 alan_g, I think only those two...
 alan_g, at the time I also had to grab mir/devel, but that's in trusty now
[15:38] <mterry> alan_g|tea, ^ sorry, had irc issue
[15:42] <alan_g> mterry: thanks
[15:54] <anpok> kgunn: yes .. just redoing the chroot resolved it..
[16:28] <alf_> alan_g: I pushed the branch with the problematic tests at lp:~afrantzis/mir/mir-output-capture-basic-client-api
[16:29] <alan_g> alf_: I'll take a look - which test is the problem?
[16:30] <alf_> alan_g: bin/mir_acceptance_tests --gtest_filter=MirOutputCaptureTest.* hangs in MirOutputCaptureTest.gets_valid_egl_native_window
[16:30] <alf_> alan_g: but MirOutputCaptureTest.gets_valid_egl_native_window by itself runs
[16:31] <alan_g> alf_: ack. Building
[16:31] <alf_> alan_g: the last two tests MirOutputCaptureTest.create_and_release_contact_server and MirOutputCaptureTest.gets_valid_egl_native_window are similar
[16:31] <alf_> alan_g: you can get the same effect if you run either twice (with --gtest_repeat)
[16:32] <alf_> alan_g: Removing "delete capture;" from src/client/mir_output_capture_api.cpp alleviates the problem (but causes a leak, of course)
[16:34] <alan_g> alf_: I can reproduce the hang (in first incantation above)
[16:36] <alf_> alan_g: The apparrent cause of the hang is the display server not stopping when told to do so, i.e., it seems that the main loop just ignores(?) our stop() call. Pressing ctrl-c unblocks it somehow
[16:36] <alf_> s/apparrent/apparent/
[16:37] <alan_g> alf_: OK - just looking at where the threads are at
[16:41] <alan_g> Hmm. exiting the debugger seems to unblock too
[16:43] <alf_> alan_g: it's really weird... it's even more weird that removing the "delete capture" as mentioned above "fixes" the problem... I can't see the connection (unless it is a timing issue?)
[16:44] <alan_g> alf_: weird just means there's a fact we're missing
[16:50] <kgunn> alan_g: wanna have a chat now about the potential release process changes
[17:01] <alan_g> dandrader_: fginther & cjwatson figured out what happened.
[17:15] <dandrader> alan_g, great!
[17:17] <kdub> alan_g, with ~vanvugt/mir/fix-1271853, would you be okay with me top-approving?
[17:18] <alan_g> kdub: yes, you have the right.
[17:19] <kdub> alan_g, :D was just checking if that needs-info was a blocker
[17:19] <alan_g> kdub: it would be nice to know
[17:37] <xnox> Saviq: i've mixed a bug in cmake, and mir & unity8 cross-building works once again out of the box.
[17:37] <xnox> s/mixed/fixed/
[17:38] <ogra_> dont mix the fixes :)
[17:47] <mterry> kdub, I'm running mir/devel on my mako with USC.  USC is crashing with "error binding buffer to texture".  Any clues?
[17:50] <kdub> mterry, new to me
[17:54] <mterry> kdub, it happens because eglCreateImageKHR returns EGL_NO_IMAGE_KHR in mga::Buffer::bind_to_texture()
[17:54] <mterry> kdub, this doesn't happen with trusty mir
[17:56] <kdub> mterry, let me try something
[18:08] <anpok> xnox: i thought it work again but now I got that message: make[1]: Leaving directory `/«PKGBUILDDIR»/obj-arm-linux-gnueabihf'
[18:08] <anpok>    dh_install -O--parallel -O--fail-missing
[18:09] <anpok> dh_install: usr/lib/arm-linux-gnueabihf/libmirserver.so.13 exists in debian/tmp but is not installed to anywhere
[18:09] <anpok> dh_install: missing files, aborting
[18:09] <anpok> make: *** [binary] Error 255
[18:09] <anpok> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
[18:09] <xnox> anpok: with mir or unity8?
[18:10] <xnox> anpok: i've compiled mir_0.1.3+14.04.20140108-0ubuntu1_armhf.build as in the archive
[18:10] <xnox> anpok: http://paste.ubuntu.com/6804190/
[18:10] <xnox> anpok: sounds like a packaging change is needed of whichever revision shows that bug above.
[18:11] <anpok> ah
[18:11] <anpok> building a mir branch
[18:12] <anpok> i think i have mixture of abi verison 13 and 14
[18:15] <kdub> mterry, i see...
 Unsupported buffer format: 3.
[18:15] <kdub> this is probably a regression of some sort
[18:15] <kdub> i havent been tinkering in this area lately, not sure what it could be at the moment
[18:15] <mterry> Yar.  Is this from that alpha patch?
[18:16] <kdub> it might be, lets try backing it out and seeing if that helps
[18:18] <kdub> mterry, i can try in about...
[18:18] <kdub> 30 min
[18:18] <mterry> kdub, I'll give it a go
[18:19] <kdub> mterry, at any rate, i think that robotfuel has some scripts for firing up a server and checking a client against it
[18:19] <kdub> we should improve those to fire a server, nested server, and client
[18:19] <mterry> robotfuel, ^ pretty please  :)
[18:20]  * robotfuel looks at backlog
[18:20] <mterry> robotfuel, especially since we're about to enable nested mode
[18:20] <mterry> by default
[18:20] <kdub> because I don't think we have a full test for nested
[18:20] <kdub> in the CI process
[18:20] <robotfuel> what are you trying to run?
[18:20] <robotfuel> mterry: what are you trying to run?
[18:21] <kdub> ./mir_demo_server -f /tmp/socket1 & ./mir_demo_server --host-socket /tmp/socket1 -f /tmp/socket2 & ./mir_demo_client_egltriangle -m /tmp/socket2
[18:21] <mterry> robotfuel, so the problem I hit is using nested mode.  I'm trying to run unity-system-compositor (USC) and it crashes with "error binding buffer to texture".  But kdub was just saying that we don't have good test coverage for nested mode in general (which allows such regressions to slip in)
[18:21] <mterry> robotfuel, so apparently you have a nice script for testing that may benefit from adding a nested server
[18:22] <kdub> robotfuel, i'm just suggesting once we get the problem we're seeing fixed, we should improve the CI to protect the nested server from regressions
[18:22] <robotfuel> mterry: yes we could easily add a test for that. let me give you a link to the current one.
[18:22] <kdub> which me or another mir team member could help with :)
[18:22] <kdub> robotfuel, thanks
[18:28] <robotfuel> mterry: there is this https://bazaar.launchpad.net/~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir-mediumtest-runner.sh and this  https://bazaar.launchpad.net/~chris.gagnon/+junk/mir-demo-runner/view/head:/bin/mir-demo-tester
[18:40] <robotfuel> mir-demo-tester is in a all the way finish because I thought shell bindings for subunit were going to land, but they haven't yet. https://code.launchpad.net/~thomir/subunit/trunk-add-cmd-line-script
[18:40] <robotfuel> s/is in/isn't
[18:49] <mterry> robotfuel, I'm less interested in running the script myself than just making sure a nested server gets added to it to avoid regressions in the future.  Something like kdub's line above:
[18:49] <mterry> ./mir_demo_server -f /tmp/socket1 & ./mir_demo_server --host-socket /tmp/socket1 -f /tmp/socket2 & ./mir_demo_client_egltriangle -m /tmp/socket2
[18:50] <robotfuel> mterry: does that automatically stop the server when it's finished?
[18:51] <mterry> I doubt it
[18:57] <kdub> mterry, filed a bug https://bugs.launchpad.net/mir/+bug/1272041
[18:58] <mterry> kdub, awesome.  I'm compiling a version of mir just before the alpha bits landed for testing.  But compiling takes a while
[19:00] <kdub> mterry, okay :) (also, you know of cross-compile-chroot for mir?)
[19:00] <mterry> kdub, I've cross compiled with pbuilder before, but it's not much faster
[19:00] <kdub> not much use for packages, but if you're working in a mir-only world for some problems, its a real time saver
[19:01] <kdub> well, thats an emulated cross compile, the script does a native cross compile
[19:01] <kdub> eg, a toolchain that runs on x86 that produces armhf libs
[19:01] <mterry> hmm.  I'm so wedded to the packaging workflow, but that sounds tempting
[19:03] <kdub> mterry, yeah, i just thought I'd throw it out there
[19:13] <kdub> mterry, lp:mir/devel rev 1328 is the culprit
[19:14] <mterry> kdub, aha
[19:15] <mterry> kdub, yup, that's the alpha patch I was going to test
[19:15] <mterry> anpok, ^
[19:16] <mterry> bug 1272041
[19:29] <anpok> re
[19:30] <anpok> xnox: yes thanks for parsing the error message
[19:36] <anpok> mterry: that happened on n10?
[19:37] <mterry> anpok, mako (n4)
[19:47]  * mterry goes to gym for a bit
[21:25] <mterry> anpok, any luck?  Any testing I can help with?
[21:42] <rsalveti> kdub: so it seems mir is working mostly fine with flo (nexus 7 - 2013), I have just one critical issue atm
[21:42] <rsalveti> kdub: after mir/powerd turns the screen off, nothing can turn the screen on again
[21:43] <rsalveti> so the rendering keeps working, but screen is constantly off
[21:43] <rsalveti> had to disable powerd to have unity8/mir working with it
[21:43] <rsalveti> and this also happens when running mir_demo_server_basic
[21:44] <rsalveti> it works fine first time you run it, but it seems it turns the screen off automatically when you stop it
[21:44] <rsalveti> so next time you run the screen will be completely off, as it fails to turn on the screen again
[21:45] <rsalveti> kdub: I'm just uploading the image I got here, will have the link ready in a few
[21:45] <kdub> rsalveti, cool, its encouraging mir works
[21:50] <kdub> rsalveti, taking a late lunch, be back shortly
[21:52] <rsalveti> kdub: ok
[22:08] <anpok> mterry: kdub already has a solution which i can only verify to work on none n4 devices - lp:~andreas-pokorny/mir/fix-1272041
[22:10] <mterry> anpok, ooh, will test
[22:16] <rsalveti> kdub: flash http://people.canonical.com/~rsalveti/aosp/flo/, then http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140123.1/trusty-preinstalled-touch-armhf.zip via recovery
[22:17] <rsalveti> kdub: the android container takes ~1 min to load, still investigating why, and current mir will be broken because of hwcomposer 1.2, so if you want a working unity8 just use my ppa: https://launchpad.net/~rsalveti/+archive/ppa
[22:17] <rsalveti> and make sure to disable powerd as well
[23:04] <kdub>  rsalveti thanks