[05:12] <soee> acheronuk: what are the plans for Plasma 5.7 in Kubuntu ?
[05:14] <soee> i have user asking about backports and i'm not sure what to say: https://plus.google.com/110954078302330754910/posts/fnozssdEnwY
[05:14] <acheronuk> on XX stage and see if we can get it working with Qt 5.6.1 without messing up other qt dependant packages I think?
[05:17] <soee> acheronuk: but do we started it on YY maybe or it all is just waiting ?
[05:20] <acheronuk> already started somewhat in advance of ubuntu getting their official Qt 5.6.1 packages landed in YY. There is Qt 5.6.1 in frameworks staging ppa for YY, but causes breakages so far
[05:21] <soee> ok, thanks :)
[05:21] <acheronuk> as BluesKaj found out when they tried the ppa! eeek
[07:40] <yofel> lp 1530523 - seriously o.O
[07:41] <yofel> (last comments)
[07:41] <soee> rolf ;)
[07:41] <yofel> I wonder if we can put a trigger for that into the manager
[07:42] <soee> yofel: btw. do we have this folder widget fix in Xenial?
[07:42] <yofel> not yet, I have the package prepared, but I have yet to do the paperwork
[07:42] <soee> we had just user on #kubuntu that did not know how to install system from live session :/
[07:43] <yofel> .1 is ~2 weeks away, any other issues than those 2 that we really should look into?
[07:43] <yofel> (install related)
[07:43] <soee> hmm
[07:44] <soee> the broken slideshow is only related to YY right ?
[07:44] <soee> *in ubiquity
[07:45] <yofel> yes
[08:37] <jimarvan> good morning busy bees! :)
[08:40] <soee> hiho
[09:07] <yofel> soee: the issue here might be rather simple: 16.04 does not install apt-xapian-index, all previous versions did
[09:08] <soee> so only this ? :D
[09:09] <soee> it is in kubuntu meta package ?
[09:09] <yofel> it isn't. I guess whatever installed it in the past went away and nobody noticed it vanishing
[09:10] <soee> so maybe it was some aprt of Ubuntu meta packages?
[09:10] <yofel> might've been part of base, yeah
[09:10] <yofel> I think there was some talk about xapian and python3, so that might've been why it got removed
[09:11] <yofel> let me add it to desktop-recommends for yakkety, then we can check tomorrow there
[09:11] <soee> so for kubuntu and neon it should go for respective meta packages ?
[09:11] <soee> Riddell: ^
[09:12] <yofel> IMO yes, making the driver manager depend on it would sound more correct, but it technically depends on a working index, not the generator
[09:12] <yofel> question is how much of a difference that really is
[09:14] <soee> yofel: could we have this fixed for 16.04.1 ?
[09:15] <yofel> yes, enough time if it works in yakkety
[09:16] <soee> ah nice :) so next of most annoying bugs will be gone
[09:18] <yofel> actually, I'll add the dep in both places for yakkety. the driver manager is useless without the index, and I'm not convinced that it's the only thing that needs it
[09:19] <soee> uhm, i do not know the internals :)
[09:25] <lordievader> Good morning.
[09:37] <yofel> ok, I added the dep to the wrong package, qapt is what actually needs it
[09:38] <soee> :P
[09:38] <yofel> well, the meta change stands though
 Thats interesting valorie reported warnings about the xapian index when testing muon. I couldn't reproduce them myself
[09:52] <yofel> rick and others already did tons of debugging if you look at the report. Nobody actually realized that xapian was simply missing until last week though
 What is the name of the missing package?
[09:53] <yofel> apt-xapian-index
[09:55] <yofel> TBH, plasma-discover could probably also use a dep on it
[10:06] <BluesKaj> Hey folks
[10:09] <soee> https://www.youtube.com/watch?v=e5nv7vrud_M
[10:13] <clivejo> yofel I added some changes to the git-clone-all script, wil you review - https://git.launchpad.net/~kubuntu-packagers/+git/kubuntu-automation/commit/?id=d4a4b50e4b0dbd8c78b6bfe8133b96b8f3f68f99
[10:14] <yofel> Kloning? ^^
[10:15] <clivejo> also can you show me the command you use to involve  ubuntu-archive-upload
[10:15] <clivejo> just a silly joke
[10:15] <yofel> the readme should have that
[10:15] <clivejo> like Kopy
[10:15] <clivejo> the command in the readme wont work
[10:15] <yofel> I think the changes are fine, you will have to fix do-all do work with that scheme
[10:16] <yofel> *to work
[10:16] <clivejo> dont use do-all any more
[10:17] <clivejo> always use that looping command you showed me
[10:17] <yofel> it should still work..
[10:17] <clivejo> shouldnt be difficult to fix
[10:17] <yofel> -            if not os.path.exists(workdir + '/' + package):
[10:17] <yofel> +            if not os.path.exists(workdir + '/git/'):
[10:17] <yofel> shouldn't that be if not os.path.exists(workdir + '/' + package + '/git/'):
[10:19] <clivejo> I couldnt get that bit to work
[10:20] <clivejo> if not ?
[10:21] <clivejo> surely it should be if it exists
[10:21] <clivejo> not if not
[10:21] <BluesKaj> well, had to install Xenial finally...Yakkety daily images are still broken, errored out with message saying missing or corrupted files, installation is aborting
[10:22] <clivejo> the logic confused me
[10:25] <BluesKaj> guess the only path to Yakkety for me is do-release-upgrade -d , but now I'm having second thoughts
[10:29] <clivejo> did the error message say what files are missing/corrupted?
[10:31] <clivejo> well I have xapian installed on my system
[10:31] <clivejo> which is probably why I didnt see the errors valorie mentioned
[10:31] <BluesKaj> clivejo,  no files were named
[10:32] <clivejo> driver manager still not working
[10:32] <clivejo> run sudo update-apt-xapian-index
[10:32] <clivejo> and driver manager works!
[10:34] <clivejo> looks like that index needs refresh at runtime
[10:34] <BluesKaj> running out of dvd-rw disks for this old pc, it's not usb boot capable and they're becoming difficult to find lately
[10:39] <clivejo> slhk: are you Carlos?
[10:43] <clivejo> Rick_Timmis: do you remember Carlo Vanini IRC nick?
[10:45] <yofel> clivejo: the point of the check is to list *missing* repositories
[10:50] <slhk> clivejo: hi, yes it's me
[10:50] <clivejo> my memory always lets me down
[10:50] <clivejo> I sent you a wee email, did you get it?
[10:51] <slhk> I've been away some time... ;)
[10:51] <clivejo> I noticed you havent made any commits in a while, is everything ok?
[10:52] <slhk> clivejo: please see bug #1579834
[10:55] <clivejo> I’m afraid my understanding of Xapian is non-existent
[10:55] <clivejo> yofel: does that make sense to you?
[10:56] <clivejo> I assume the driver manager is calling for a xapian update via dbus?
[10:56] <clivejo> but thats not happening?
[10:56] <yofel> this has little to do with xapian, than with python-glib
[10:57] <slhk> exactly, it silently fails because of the wrong import
[10:57] <yofel> patch looks fine to me, so make a debdiff and request sponsorship
[10:57] <clivejo> slhk: and this causes the driver manager to just sit there doing nothing?
[10:58] <yofel> no, that's the dbus endpoint not even being there I think
[10:58] <yofel> although that would make it hang as well
[10:58] <slhk> clivejo: yes, it wait for xapian to complete, but that never happens and it doesn;t get an error either
[10:59] <clivejo> slhk: we also noticed that on some installs apt-xapian-index isnt even installed
[11:00] <clivejo> do you have any idea what used to pull it in?
[11:00] <clivejo> and what package would be best to pull it in, in future?
[11:00] <yofel> might've been muon actually, that only recently got thrown out of the default install
[11:01] <clivejo> that makes sense
[11:01] <slhk> not sure if you need it, there is another script which is called over dbus. I don't recall the name right now
[11:02] <slhk> /usr/share/apt-xapian-index/update-apt-xapian-index-dbus
[11:02] <yofel> that is also in 'apt-xapian-index', but yeah, that's broken as well
[11:02] <yofel> so FWIW, have have 2 issues here, and both need fixing
[11:04] <slhk> I see 1 issue: update-*-dbus is broken, wich is the other one?
[11:04] <yofel> that not even being installed
[11:04] <slhk> ok
[11:04] <clivejo> the actual package isnt getting instaled
[11:04] <clivejo> on newer systems
[11:04] <clivejo> on newly installed systems
[11:05] <yofel> I'm working on that, you can wrap up a debdiff for the import issue so someone can upload it
[11:05] <clivejo> yofel: you are putting a dependancy on qapt?
[11:06] <yofel> for yakkety I put a recommends on kubuntu-desktop and libqapt3, and a dep on kubuntu-driver-manager
[11:06] <yofel> need to check if plasma-desktop also should have one
[11:06] <yofel> erm, plasma-discover
[11:06] <yofel> for xenial I'm still pondering what I'll do
[11:07] <clivejo> is acheronuk about?
[11:08] <slhk> yofel: it takes me some time to make the debdiff, I don't have the source around anymore and I'm leaving in 20min, maybe tonight?
[11:08] <yofel> hm, discover seems to work ok without an index
[11:09] <yofel> slhk: sure, I don't have much time right now either
[11:09] <slhk> maybe Discover is using appstream?
[11:09] <yofel> that it probably does
[11:10] <yofel> ok, so that's fine, so only the driver manager and qapt need fixing
[11:11]  * yofel wonders if plasma-discover 5.7 finally has a not-so-broken-looking UI
[11:14] <soee> yofel: http://i.imgur.com/whVecJY.png
[11:14] <yofel> soee: still ok if you make the window smaller?
[11:15] <yofel> but that's ok so far
[11:15] <soee> http://i.imgur.com/ba3GdxE.png
[11:16] <soee> IMO those windows should behave like responsive websites
[11:17] <yofel> they should. I guess the rating improved, but the popularity count still looks bad
[11:17] <soee> still i think that discover looks bad
[11:18] <soee> this slider at the top uses to much space,
[11:18] <acheronuk> clivejo: about for approx 5 mins now, back late this afternoon or early evening
[11:18] <clivejo> no prob
 Is there a core meeting tonight?
[16:47] <acheronuk> clivejo: core what?
 Its like a pre podcast teaming
 Meeting
[16:50] <acheronuk> wow. last one was nearly a month ago! time flies
[16:52] <ahoneybun> yep acheronuk your free and encourged to join
 Did Simon manage to get Freeciv snapped?
[17:02] <acheronuk> clivejo: don't see it in the 'playpen' or snap find
 Be interesting to see it working
 Today is new podcast?
 Or next week because I am a bit confused :
 :)
[17:33] <ahoneybun> today
[17:35] <acheronuk> meeting? podcast? or both?
[17:40] <jimarvan> hmm dont' see anything on the calendar
[18:01] <ahoneybun> me neither but Rick_Timmis says it is going on
[18:01] <clivejo> what time?
[18:01] <ahoneybun> should be now I think
[18:02] <clivejo> the core or podcast?
[18:02] <ahoneybun> core
[18:02] <ahoneybun> podcast is in 1hour
[18:02] <clivejo> well Im in BBB
[18:40] <Rick_Timmis> Kubuntu podcast in BBB at 19:00 UTC
[18:57] <Rick_Timmis> ovidiuflorin: Ping - We're Panicin
[19:02] <jimarvan> :D
[19:02] <jimarvan> youtube is not live yet?
[19:06] <acheronuk> not here
[19:13] <ahoneybunn> https://www.youtube.com/watch?v=QFnG9kBdY9M show
[19:16] <ahoneybunn> #KubuntuPodcast
[20:08] <jimarvan> how are we with the staging packaging? :D
[20:22] <jimarvan> aaron refreshing
[20:23] <soee> :)
[20:27] <BluesKaj> So far my luck with the YY daily images has not been good, Think I'll put off installing it again until there's a chance of success. Sticking with Xenial in the meantime.
[20:28] <soee> keep it in VM for some future tests of Plasma, Frameworks or Apps
[20:29] <BluesKaj> no , I prefer to install to a partition, theat's the real world
[20:30] <BluesKaj> anyway time for other things now ...later, take care
[20:32] <clivejo> grrrrr I cant get this ubuntu-archive-upload script to work
[20:56] <soee> wee 2 of my bugs reported for Plasma 5.7 are already fixed :)
[20:57] <soee> and even systray icons will be higher than now :)
[20:57] <acheronuk> YY daily inage has error deleting files at end of install, but it seems to boot the install afterwards
[21:15] <acheronuk> ^^^ http://i.imgur.com/9sR2q6L.png
[21:16] <soee> :D
[21:16] <jimarvan> so much fun :)
[21:17] <soee> indeed
[21:22] <acheronuk> ubiquity crash http://paste.ubuntu.com/18659933/
[21:23] <acheronuk> but VM runs on reboot
[21:49] <yofel> Jul  6 21:13:03 kubuntu kernel: [  877.878748] dpkg[22434]: segfault at 18 ip<PHONE_NUMBER>73c8b9 sp 00007ffd3e2d4ca0 error 4 in dpkg[55839372a000+45000]
[21:49] <yofel> wait what?
[21:50] <acheronuk> Seem s like LP: 1599174
[21:51] <yofel> looks like it
[22:02] <valorie> strange, I reported the bug, a browser started up so I could login etc., but FF seems to have no memory of that
[22:03] <valorie> and yet my install seems to be working great
[22:09] <valorie> so what needs testing is only ppa:kubuntu-ppa/staging-plasma and kubuntu-ppa/staging-kdeapplications ?
[22:09] <valorie> err, landing-plasma
[22:09] <clivejo> ppa:kubuntu-ppa/ppa-landing
[22:10] <clivejo> apps 16.04.3 available in 5 hours!
[22:10] <valorie> and kdeapplications?
[22:10] <acheronuk> yes apps one as well
[22:10] <valorie> or should I wait for that
[22:10] <clivejo>  kubuntu-ppa/staging-kdeapplications
[22:10] <clivejo> noooo dont wait
[22:10] <acheronuk> clivejo: yes, I just got that email!
[22:11] <clivejo> I need to figure out how to tag these
[22:11] <acheronuk> the packaging in git?
[22:11] <clivejo> I want to tag all of them before doing anything else
[22:11] <clivejo> acheronuk: yes
[22:12] <clivejo> well want to do a release to yakkety of FW 5.23 and Plasma 5.6.5 before starting on 5.7
[22:13] <clivejo> apps I guess could wait for .3
[22:14] <mamarley> I have been running 5.23 and 5.6.5 on Yakkety on several systems for quite some time now with no problems. :)
[22:14] <acheronuk> :)
[22:14] <clivejo> mamarley: yeah, Im actually really looking forward to yakkety
[22:14] <clivejo> its very stable
[22:14] <clivejo> if we can get it into the archive!
[22:14]  * mamarley is looking forward to Plasma 5.7 and Qt 5.6. :)
[22:15] <clivejo> and if that kubuntu driver manager bug can be fixed
[22:15]  * clivejo dances
[22:15] <clivejo> I give up!
[22:16] <acheronuk> the installer icon seemed fixed on the iso today
[22:16] <valorie> key question: when you dance, do you use your hands?
[22:16] <valorie> :-)
[22:17] <valorie> I'm happy with how fast the VM is
[22:18] <acheronuk> VMs seem much less laggy than they used to.
[22:20] <valorie> good grief, how do I start yakuake now?
[22:21] <acheronuk> don't use it, so pass
[22:21] <valorie> ok, rebooting after upgrade
[22:21] <valorie> oh my
[22:22] <jimarvan> ? :)
[22:22] <valorie> I can't imagine life in the cli without my yak
[22:22] <acheronuk> I've tried it, but somehow didn;t get on with it
[22:23] <valorie> it's much easier to use when f-12 pops it up and down
[22:23] <jimarvan> clive that driver bug
[22:23] <jimarvan> comes from ubuntu right?
[22:24] <valorie> on my travel lappy, I have to use alt-f-12 or so
[22:24] <valorie> not as convenient
[22:25] <valorie> huh, qa site won't let me file a report
[22:32] <clivejo> which bug?
[22:36] <valorie> after a reboot after full-upgrade with landing, all is well
[22:36] <valorie> now doing apps
[22:41] <clivejo> valorie: remove them after you install
[22:41] <clivejo> just so you dont forget
[22:41] <valorie> thanks for the reminder
[22:47] <valorie> ok, all upgraded
[22:47] <valorie> anything in particular needs testing?
[22:47] <clivejo> everything
[22:48] <valorie> snapshotting while I'm at it
[22:48] <clivejo> for docs?
[22:49] <valorie> amarok seems to run fine
[22:49] <valorie> snapshotting the vm, I mean
[22:50] <valorie> the qa page won't let me leave any feedback
[22:50] <valorie> http://iso.qa.ubuntu.com/qatracker/milestones/360/builds/124740/testcases/1300/results#add_result just sits there
[22:50] <valorie> oops, I needed to go to the store
[22:50] <valorie> I wonder if I still have time
[22:51] <valorie> ttyl


[07:55] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: libxfce4util 4.17.2 released<EMAIL_ADDRESS>[18:04] -SwissBot:#xubuntu-devel- ::platform:: Promote frr, demote quagga @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=567161b6b8eb16c42001a691c2f55667797dd932 (by Andreas Hasenack)
[18:30] -SwissBot:#xubuntu-devel- ::platform:: Promote wireguard-tools (LP: #1950317) @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=8dfaa4f516284127e99e259bc78a7f0129e7a484 (by Andreas Hasenack)


[10:02] <j__> hi
[10:03] <j__> there is an upstart developper availlable ?
[10:03] <soren> j__: It's much easier for everyone if you just ask your question.
[10:05] <j__> I've actualy an instablility of upstart
[10:06] <j__> I don't have the same comportement at each boot
[10:07] <soren> comportement?
[10:08] <j__> comportment/behavior
[10:08] <soren> ok.
[10:10] <soren> You realise you need to provide some more information, right? "Something doesn't work" isn't quite enough to fix anything.
[10:13] <j__> I agree
[10:13] <j__> I create some script like that
[10:14] <j__> start on network and dbus_started
[10:14] <soren> "like that"?
[10:15] <j__> first the script do not start and sometimes I've an dbus_started evend failed
[10:15] <j__> I've 3 scripts
[10:16] <soren> Ah, I've just noticed Keybuk isn't around. It's probably him you want to pester.
[10:16] <j__> one that emit dbus_started
[10:16] <j__> when dbus is available
[10:17] <j__> on other that emit network when the network is configured
[10:17] <j__> and a deamon script that start when the both are done
[10:19] <j__> Am I doing something wrong?
[10:21] <soren> Not sure. You should ask Keybuk.
[10:22] <soren> Ah, he's off today. He should be around tomorrow, though.
[10:27] <j__> ok
[10:28] <j__> soren: did you have mode complex example with and for updstart script?
[14:07] <j__> re
[14:08] <j__> soren or other I'm currently builiding the last upstart from bazar
[14:08] <j__> and I've this error
[14:09] <j__>  /bin/install -c -m 644 'errors.h' '/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/image//usr/include/nih/errors.h'
[14:09] <j__>  /bin/install -c -m 644 'inotify.h' '/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/image//usr/include/nih/inotify.h'
[14:09] <j__>  /bin/install -c -m 644 'test.h' '/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/image//usr/include/nih/test.h'
[14:09] <j__> make[2]: Leaving directory `/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/work/upstart-0.3.9/nih'
[14:09] <j__> make[1]: Leaving directory `/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/work/upstart-0.3.9/nih'
[14:09] <j__> Making install in upstart
[14:09] <soren> How is that an error?
[14:09] <j__> /bin/sh: line 17: cd: upstart: No such file or directory
[14:09] <j__> make: *** [install-recursive] Error 1
[14:09] <soren> Ah.
[14:11] <j__> any idea?
[14:14] <soren> File a bug?
[14:15] <soren> ..or wait for Keybuk to show up tomorrow. :)
[16:38] <ion_> That sounds like a bug in the gentoo packaging.


[17:46] <genii-around> Hey guys. I think we can help get more than 54 people signing this. http://www.change.org/en-CA/petitions/bell-canada-crtc-stop-bell-canada-cellpipe-7130-vdsl-8-00-forced-modem-rental-fee
[20:33] <IdleOne> genii-around: signed it.
[20:45] <genii-around> :)
[20:57] <IdleOne> I also pay that $8 rental fee
[21:02] <genii-around> The main problem is that Bell contracted Cellpipe to make a draft VDSL2 modem which has nonstandardized protocol. And then on the DSLAM side they used matching linecards.


[08:44] !LoRez:*! It appears the routes for one of our main rotation servers has gone bye-bye.  It's been pulled from the rotation until the situation is resolved.  Thanks for frying(!?!?) freenode ;)


[00:00] <robclark> GrueMaster: not sure which kernel you are on.. but one obvious thing to sanity check... some recent defconfig from kernel-omap4.git had VRAM defaulting to zero.. so if you didn't give some bootargs you wouldn't get any framebuffers
[00:00] <robclark> you could try something along lines of: vram=8M omapfb.vram=0:8M
[00:00] <robclark> (for example)
[00:01] <GrueMaster> robclark: I'm using the same bootargs as I was for 2.6.34.  vram=12M omapfb.mode=dvi:1280x720MR-16@60.  And this is on the beagleboard (omap3).
[00:01] <robclark> ahh.. ok.. that should be not the issue then
[00:02] <GrueMaster> This is kernel 2.6.35-6.  It is scheduled to hit the pools on Friday.
[00:03] <robclark> do you even get the penguin at bootup?   Or nothing at all on dvi?
[00:03] <GrueMaster> Nothing on dvi.  See my error post a few lines back.
[00:04] <GrueMaster> rebooting to 2.6.34 kernel is fine.
[00:06] <robclark> hmm, is kernel config not enabling any DSS devices?
[00:07] <robclark> I think it does not go thru this loop at all:  for_each_dss_dev(dssdev) { ... }
[00:08] <robclark> make menuconfig, and then Drivers -> Graphics -> OMAP2/3/4... -> and then hopefully there is some DVI option
[00:10] <GrueMaster> Not sure.  Let me check the output against 2.6.34
[00:30] <GrueMaster> Maybe it has something to do with "# CONFIG_OMAP2_DSS_RFBI is not set"?  I haven't tweaked the kernel in several years (since 2.4.xx times).
[00:30] <GrueMaster> But I did see that in the config.
[00:31] <GrueMaster> nevermind.  same in 2.6.34
[00:33] <GrueMaster> Interesting.  I'm reviewing my bootlogs from earlier 2.6.35 test kernels, and I am seeing the same error in 2.6.35-RC1 raw kernel (no ubuntuisms).
[01:13] <GrueMaster> ogra_cmpc: What's the score?
[01:14] <Martyn> My bamboo board was DOA
[01:14] <Martyn> -sigh-
[01:14] <GrueMaster> which one is that?
[01:21] <ojn> AMCC 440EP eval board?
[05:07] <NCommander> damn it, just missed Martyn
[05:35] <Belvadi> any softkey pad application available for arm...
[07:58] <ogra> NCommander, so your gobject-introspection "fix" ...
[07:59] <NCommander> ogra: yes?
[07:59] <ogra> NCommander, did you check the dependencies and what changed in them between 0.6.12-1 and 0.6.12-1ubuntu1 ?
[07:59] <NCommander> ogra: dyfet did.
[07:59] <ogra> since this is not a gobject-introspecion issue but an issue with any build dep
[08:00] <ogra> i'd rather see us fixing the real issue than changing the code that didnt change before the breakage
[08:00] <ogra> looking at the deps i'd suspect glib
[08:00] <ogra> bison, flex and friends didnt change between the two uploads
[08:00] <NCommander> ogra: we need gobject-introspection fixed, you've already said that, I'm glad to hunt for the actual cause of the breakage, but I'm happy to work around it
[08:01] <NCommander> ogra: dyfet said he checked it
[08:01] <ogra> i'm not sure it wont break it on all other arches
[08:01] <NCommander> ogra: I threw it in a PPA, built on everything
[08:01] <ogra> you are changing XML that hadnt changed
[08:01] <NCommander> (devirtualized PPA)
[08:01] <NCommander> I only changed the XML to reflect the changed vairable names in the C code
[08:01] <ogra> yes, but does that change work on all other arches ?
[08:02]  * ogra wouldnt even know how to verify that
[08:02] <NCommander> ogra: I ran the test suite on all arches
[08:02] <ogra> in any case something in a dep changed, just hacking variable definitions in the gobject code doesnt seem like an appropriate fix
[08:02] <ogra> i'm not talking about the test suite
[08:02] <ogra> but about the binaries using the code
[08:03] <ogra> telepathy for example
[08:03] <NCommander> ogra: I didn't change any code expect code used in the test suite
[08:03] <ogra> was seb128 pulled into the discussion by dyfet as i asked ?
[08:03] <NCommander> ogra: I didn't see any communication from dyfet to seb128. I was waiting for him to show up to pin ghim on desktop
[08:04] <ogra> hmm, i asked dyfet a week ago at the meeting to discuss it with seb :/
[08:04] <ogra> (and agin this week)
[08:26] <hrw> morning
[08:41] <Belvadi> dialpad application in ubuntu avaliable..
[12:07] <ogra> NCommander, do you remember the former name of the "source" commnad in old u-boot ?
[12:07] <ogra> seems enabling hush shell didnt get me source
[12:08] <NCommander> ogra: TI's u-boot might predate that command being added
[12:08] <ogra> its 1.1.4
[12:08] <NCommander> Marvell was 1.3.4
[12:08] <ogra> gah
[12:08] <ogra> thats really bad
[12:08] <NCommander> your trying to execute the boot.scr, right?
[12:08] <ogra> yep
[12:08] <NCommander> do imi *offset* where you loaded it
[12:09] <NCommander> see if panda's u-boot recongizes it as a boot script
[12:09] <ogra> PANDA # imi 0x80300000
[12:09] <ogra> ## Checking Image at 80300000 ...
[12:09] <ogra>    Image Name:   Ubuntu boot script
[12:09] <ogra>    Image Type:   ARM Linux Script (uncompressed)
[12:09] <ogra>    Data Size:    163 Bytes =  0.2 kB
[12:09] <ogra>    Load Address: 00000000
[12:09] <ogra>    Entry Point:  00000000
[12:09] <ogra>    Verifying Checksum ... OK
[12:09] <NCommander> hrm
[12:09] <ogra> PANDA #
[12:09] <ogra> yep
[12:09] <NCommander> possible autoscr
[12:10] <NCommander> that might have been the old command for source
[12:10] <NCommander> (it shouldbe in help)_
[12:10] <ogra> nope
[12:10] <ogra> its not
[12:10] <ogra> (in help)
[12:11] <ogra> i see test and other hush commands
[12:12] <NCommander> crap
[12:12] <NCommander> its possible that its just not implemented
[12:12] <NCommander> Which means we're screwed
[12:13] <NCommander> (partially)
[12:13] <ogra> i see "go" but that hangs x-loader if i run it
[12:13] <NCommander> it wouldn't be super-difficult to backport a the necessary commands
[12:13] <NCommander> go is used for jumping to an offset
[12:14] <ogra> yeah
[12:14] <NCommander> autoscr is there on blaze?
[12:14]  * NCommander hasn't checked
[12:14] <NCommander> (or source)
[12:15] <ogra> hmm, gumstix uses 1.1.4 and has autoscr
[12:16] <NCommander> sounds like something went horribly wrong
[12:16]  * NCommander grabs the source
[12:29] <ogra> aha ... i see (~CFG_CMD_AUTOSCRIPT...
[13:00] <ogra> PANDA # help
[13:00] <ogra> ?       - alias for 'help'
[13:00] <ogra> autoscr - run script from memory
[13:00] <ogra> I WIN !!!
[14:43] <mpoirier> GrueMaster ?
[15:22] <GrueMaster> mpoirier: pong.  Still waking up, though.
[15:22] <mpoirier> GrueMaster: good morning.
[15:22] <mpoirier> your beagle board, it is a C4 ?
[15:23] <mpoirier> I assume so.
[15:25] <GrueMaster> Yes.  Store bought, as it were.
[15:26] <mpoirier> did you upgrade your MLO and u-boot ?
[15:27] <mpoirier> or are they stock ?
[15:27] <GrueMaster> I believe I am running what is on ogra's image.
[15:28] <mpoirier> do me a favor please.
[15:28] <mpoirier> boot the board (power cycle) and give me the date you get on the very first line that come up on the screen.
[15:28] <mpoirier> mine is:
[15:28] <mpoirier> Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
[15:31] <GrueMaster> same
[15:31] <GrueMaster> That's the xloader
[15:31] <mpoirier> yes, indeed.
[15:32] <GrueMaster>
[15:32] <mpoirier> please confirm that you have used the USB EHCI on this board.
[15:32] <GrueMaster> Huh?
[15:32] <mpoirier> the normal looking USB port, next to the SD card slot.
[15:33] <GrueMaster> of course.  That's how I have keyboard, mouse, ethernet, etc.
[15:34] <mpoirier> davidm set me a C4 two weeks ago and USB did not work off the box.
[15:34] <mpoirier> Ok I'm thinking, hw failure happens...
[15:34] <GrueMaster> I'm fully hooked up here.  Only thing not in use is the otg port.
[15:34] <GrueMaster> and svideo.
[15:34] <mpoirier> Yes, don't use OTG.
[15:34] <mpoirier> so I purchase one from Sparkfun and got it yesterday...
[15:34] <mpoirier> it too has a problem with USB.
[15:35] <GrueMaster> I'm aware of that.
[15:35] <mpoirier> that is interesting - aware of what ?
[15:35] <mpoirier> USB problems with bb  ?
[15:35] <GrueMaster> Bug #566645
[15:35] <ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 2) (heat: 64)" [High,Confirmed] https://launchpad.net/bugs/566645
[15:35] <mpoirier> indeed, OTG is not in yet.
[15:36] <mpoirier> But both my C4 boards, USB EHCI is not responsive.
[15:36] <mpoirier> I was wondering if you were seeing the same thing...
[15:36] <GrueMaster> Are you running with a powered hub?
[15:36] <davidm> mpoirier, two boards with fail sound funny, perhaps your USB hub is not working with the hardware?
[15:37] <mpoirier> It does work when hooked up to the C2 board...
[15:37] <GrueMaster> Where are you powering your board from?
[15:37] <mpoirier> power supply, not OTG.
[15:38] <GrueMaster> ok.
[15:38] <mpoirier> I'm wondering if u-boot isn't doing something special to enable the port.
[15:38] <mpoirier> Something I wouldn't have.
[15:38] <mpoirier> two failure on two boards, this isn't right.
[15:39] <GrueMaster> I have my system booting the uboot from nand when I am running lucid.  It is the stock uboot.  When I am running maverick, it runs a newer version.  Both work fine with USB.
[15:40] <mpoirier> The maverick uboot, it is on SD card ?
[15:41] <GrueMaster> yes.
[15:42] <mpoirier> Please email it to me...
[15:42] <rsavoye> is there another channel for non ARM ubuntu netbook issues ?
[15:43] <GrueMaster> Actually, just pull down ogra's test image.  http://projects.gnome.org/NetworkManager/developers/
[15:43] <GrueMaster> rsavoye: #ubuntu-mobile
[15:43] <rsavoye> thanks
[15:43] <GrueMaster> or #ubuntu-desktop may help
[15:44] <rsavoye> I was trying to get a USB install to a Sylvania G netbook to work, it can't find vesa
[15:49] <ogra> GrueMaster, #ubuntu-mobile is dead
[15:50] <ogra> netbook issues go to #ubuntu-desktop or for the efl version to us
[15:50] <rsavoye> it may be dead, but there is a pile of people
[15:51] <ogra> yes, we're in the process of either closing it or finding a new adopter
[15:51] <ogra> the ubuntu mobile team doesnt exist anymore
[15:52] <rsavoye> ah... that;s right
[16:14] <GrueMaster> mpoirier: if you have any kernel testing that needs to be done, just ping me and I can test in my environment.  I would like to test fixes to some of these critical  bugs as soon as they are available, instead of waiting for the next kernel bump.
[16:14] <mpoirier> very well.
[16:16] <GrueMaster> BTW, the daisy chain fix works well, thanks & kudos.
[16:16] <amitk> was it just removing CPU_IDLE from the Kconfig?
[16:17] <mpoirier> this is just a big hack and shouldn't be considered to be the real thing.
[16:17] <mpoirier> removing CPU_IDLE just avoids touching the flaky code.
[16:18] <GrueMaster> Sometimes it is things like this that need to be done to keep the rest of the teams moving forward while a real fix is pursued.
[16:19] <mpoirier> I have no problem with doing that either..,,.
[16:19] <GrueMaster> It enables people like me to find and report new and annoying bugs.  :P
[16:19] <mpoirier> but the real fix is still eluding me.
[16:20] <mpoirier> and all this time that I'm not fixing other problems...
[16:20] <ogra> mpoirier, ask koen in #beagle, probably he knows about it and has a patch
[16:20] <ogra> he is a great source of information if it comes to kernel issues with omap :)
[16:20] <mpoirier> ogra: you seems to know something I don't...
[16:21] <ogra> lag, what was your trick to make HDMI or DVI work on omap4 ?
[16:21] <amitk> push it in harder?
[16:21]  * ogra remembers you talked about that a while ago
[16:21] <lag> It doesn't
[16:21] <ogra> It doesn't ?
[16:21] <lag> It doesn't work
[16:22] <lag> FBAR
[16:22] <ogra> neither of the ports ?
[16:22] <lag> Neither
[16:23] <lag> DVI isn't meant to work
[16:23] <ogra> robclark, didnt you say there was a trick to make HDMI/DVI work on the panda ?
[16:23] <lag> HDMI just doesn't
[16:23] <lag> There was a hack to make it work with HDMI/DVI converter
[16:23] <lag> But I haven't tried that, as I don't have the cable
[16:24] <prpplague> lag: you hdmi isn't working?
[16:24] <lag> Correct
[16:24] <prpplague> lag: which kernel release are you using?
[16:24] <prpplague> lag: L24.7 ?
[16:24] <armin76> real men use serial
[16:24] <prpplague> armin76: hehe indeed
[16:25] <armin76> prpplague: gimme omap4!
[16:25] <ogra> prpplague, we're all using the ubuntu kernel
[16:25] <lag> Serial works like a peach
[16:25] <ogra> prpplague, which should be based on something newer than L24.7 afaik
[16:25] <ogra> lag, serial doesnt help with images :)
[16:25] <robclark> ogra: I'm not sure if DVI is up yet.. HDMI works well (at least on the monitor that I have)
[16:26] <robclark> for L24.7 kernel, you need some bootargs so you have more than 0MB for framebuffer..
[16:26] <prpplague> the HDMI inteface can be used with a DVI monitor with no problems
[16:26] <robclark> yup
[16:26]  * armin76 tests :D
[16:26] <robclark> fyi: vram=8M omapfb.vram=0:8M
[16:26] <ogra> thats all ? no resolution ?
[16:26] <prpplague> lag: most likely you need to allocate some mem for the framebuffer per robclark 's suggestion
[16:26]  * ogra tries
[16:26] <prpplague> ogra: for hdmi it will autodetect the best resolution
[16:27] <ogra> sweet !
[16:27] <prpplague> ogra: for dvi you will need to specify the mode and resolution
[16:27] <ogra> yeah
[16:27] <lag> Sounds good
[16:27] <ogra> my monitor has both
[16:27] <prpplague> lag: if you are using the hdmi but with a dvi monitor your will need to specific some additional bootargs
[16:28] <lag> I'm not
[16:28] <lag> I'm using real HDMI
[16:28] <lag> Once my kernel is up again, I'll try those extra args
[16:28] <lag> :)
[16:29] <prpplague> lag: ahh ok
[16:29] <lag> Could that be the source of the "SYNC_LOST_DIGIT" messages I receive?
[16:29] <lag> They swap my system rendering it unusable
[16:29] <lag> but 592295
[16:29] <lag> Doh!
[16:29] <lag> bug 592295
[16:29] <ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/592295
[16:30] <ogra> omapfb omapfb: failed to allocate framebuffer
[16:30] <ogra> omapfb omapfb: failed to allocate fbmem
[16:30] <ogra> omapfb omapfb: failed to setup omapfb
[16:30] <ogra> omapfb: probe of omapfb failed with error -12
[16:30] <ogra> hmm
[16:31] <robclark> ogra: someone was seeing that yesterday
[16:31] <robclark> Can you post your .config?
[16:31] <ogra> and i see the SYNC_LOST_DIGIT message too at the end of the boot
[16:31] <prpplague> robclark: i was about to ask the same
[16:31] <lag> ogra: One is fine
[16:31] <lag> It's expected
[16:31] <lag> 10,000 is not
[16:31] <robclark> From looking at code, I think that error comes if the kernel is somehow built w/o any DSS drivers enabled..
[16:33] <ogra> robclark, http://pastebin.com/HeBHjaAS
[16:35] <robclark> ogra:  hmm.. that looks somewhat ok..  CONFIG_OMAP2_DSS_HDMI=y
[16:35] <robclark> hmm
[16:36] <ogra> the monitor is definately initialized but i dont see any output
[16:36] <prpplague> ogra: do cat /dev/urandom > /dev/fb0
[16:37] <ogra> i have no shell atm
[16:37] <prpplague> ogra: oh
[16:37] <robclark> actually, ogra, I think your error is different from one yesterday.
[16:37] <prpplague> ogra: why not?
[16:37] <lag> ogra: How many messages do you get?
[16:37] <robclark> try change CONFIG_OMAP2_VRAM_SIZE=4 to CONFIG_OMAP2_VRAM_SIZE=8
[16:37] <ogra> lag, only one
[16:37] <lag> That's fine then
[16:37] <lag> No problem
[16:38] <robclark> 4mb is not sufficient for 1920x1080x4byte/pixel
[16:38] <ogra> prpplague, because i dont have a rootfs atm :)
[16:38] <prpplague> oh
[16:38] <lag> 		/* When we enable digit output, we'll get an extra digit
[16:38] <lag> 		 * sync lost interrupt, that we need to ignore */
[16:38] <ogra> robclark, so it reads the EDID of my monitor and automatically takes the highest res. it finds ?
[16:38] <prpplague> ogra: so how are suppose to know if the hdmi is working?
[16:38] <prpplague> ogra: correct
[16:38] <ogra> prpplague, kernel messages on tty0
[16:39] <lag> first frame  as it takes long time to decode but it later recovers*/
[16:39]  * lag tries again
[16:39] <lag> first frame  as it takes long time to decode but it later recovers*/
[16:39] <lag> Grr
[16:39] <prpplague> ogra: you are trying to run the hdmi as the console?
[16:39] <robclark> ogra..  yeah..  but it should reduce the framebuffer size if it doesn't have enough mem..
[16:39] <lag> first frame  as it takes long time to decode but it later recovers*/
[16:39] <ogra> prpplague, indeed
[16:39] <prpplague> ahh
[16:39] <robclark> so you should see some resolution like 1920x540
[16:40] <lag> first frame  as it takes long time to decode but it later recovers*/
[16:40] <robclark> but maybe after some limit it gives up at trying to resize the framebuffer
[16:40] <lag> /*commenting below code as with 1080P Decode we see a sync lost digit for
[16:40] <lag> first frame  as it takes long time to decode but it later recovers*/
[16:40] <lag> Got it
[16:40] <lag> Stupid leading /
[16:40] <ogra> robclark, hmm, my monitor might not do such odd resolutions in HDMI mode
[16:40] <robclark> hmm, ok.. that could be the issue I suppose
[16:41] <prpplague> ogra: can you pastebin your bootlog?
[16:41] <ogra> if i boot with serial console i can grab it, yes
[16:41] <ogra> one sedc
[16:41] <ogra> *sec
[16:42] <ogra> http://paste.ubuntu.com/454514/
[16:42]  * prpplague looks
[16:45] <prpplague> ogra: edit your .config file, turn off DSI and set the number of framebuffers to 1
[16:46] <prpplague> ogra: also turn on the omap2 fb debug support
[16:46] <ogra> well, i wont compile any kernels now :)
[16:46]  * ogra is busy working on images, but i'll file a bug for the kernel team to fix it
[16:47] <prpplague> ogra: oh
[16:47] <prpplague> ogra: is the kernel source for what you are using available somewhere?
[16:47] <ogra> i usually dont touch kernels if i can avoid :)
[16:48] <prpplague> ogra: ahh
[16:48] <ogra> https://edge.launchpad.net/ubuntu/maverick/+source/linux-ti-omap4/2.6.34-900.1
[16:48]  * prpplague looks
[16:48] <ogra> cooloney maintains it, lag gives him a hand
[16:48]  * prpplague downloads and builds
[16:49]  * prpplague needs a brake from the mailing list flame wars
[16:49] <ogra> heh
[16:50] <prpplague> jkridner1: morning
[16:50] <prpplague> ogra: i'll have a look at the build and test
[16:51] <ogra> thanks
[16:52] <hrw> hi prpplague
[16:53] <prpplague> hrw: greetings
[16:55] <hrw> ogra: why mem=463M?
[16:55] <ogra> hrw, thats in the u-boot defaults, i just kept them
[16:55] <prpplague> hrw: the blaze/sdp team were using that value, i never did get an answer for why
[16:56] <ojn> prpplague: i thought it was for legacy reasons, to set memory aside for dspbridge crap?
[16:56] <ojn> I ran our machines just fine without mem= on the bootargs
[16:56] <prpplague> ojn: ahh, that might be true
[16:56] <hrw> prpplague: maybe they had problem with second 512M?
[16:57] <prpplague> hrw: the blaze/sdp doesn't have a second 512M
[16:57] <hrw> thats why
[16:57] <ojn> no
[16:57] <ojn> u-boot passes the amount of memory in the proper atags, no need for bootargs.
[16:58] <ogra> well, its in the panda u-boot defaults
[16:58] <ojn> we had 1GB working too (well, 768MB, highmem support was busted back when I tried it last).
[16:58] <ojn> ogra: Should be bug reported, probably.
[16:58] <ogra> but i'll remove it in the ubuntu package if its not needed
[16:58] <ogra> well, in ubuntu we use boot.scr everywhere to set bootargs so i dont really care
[16:58] <prpplague> ojn: on which platform?
[16:59] <ojn> prpplague: custom boards
[16:59] <ojn> (4430-based)
[16:59] <robclark> prpplague and all:  463M is the value for 512M boards..  some memory needs to be reserved for coprocessors
[17:00] <robclark> in future, syslink will reserve this at boot time using normal kernel memory allocation APIs..
[17:00] <robclark> but that isn't implemented yet
[17:01] <prpplague> robclark: ahh dandy
[17:03] <robclark> btw, is there already u-boot/x-load patches for 1gb panda?
[17:05] <mpoirier> GrueMaster: where do I get ogra's test image ? The one you are testing with.
[17:05] <ogra> mpoirier, people.canonical.com/~ogra/jasper/
[17:06] <ogra> mpoirier, note that updating the kernel doesnt work automatically yet
[17:06] <ogra> and that it uses .34 still
[17:06] <hrw> ah.. toys
[17:06] <mpoirier> i'm only interested in the u-boot.
[17:06] <prpplague> robclark: no not yet
[17:06] <mpoirier> will I find it in there ?
[17:06] <GrueMaster> Oops.  Sorry about that.  wrong link in the copy buffer for some reason.
[17:06] <prpplague> ogra: kernel building now
[17:07] <GrueMaster> Use ogra's link.  There are only two files there.
[17:07] <ogra> mpoirier, uboot is in the image
[17:08] <mpoirier> ogra: ok thanks.
[17:09] <GrueMaster> mpoirier: You can mount the boot partition with sudo mount cmdline-maverick-armel+omap3.img mnt/ -o loop,offset=$((32256))
[17:09] <GrueMaster> Saves time from having to write the image to SD.
[17:09] <mpoirier> I would have just mounted the image.
[17:13] <hrw|gone> have a nice rest of day
[17:14] <ogra> mpoirier, oh, i mis-read above, you want u-boot ?
[17:14] <mpoirier> I just need uboot.
[17:15] <ogra> https://edge.launchpad.net/ubuntu/+source/u-boot-omap3/2010.3git20100531-0ubuntu1/+build/1767190
[17:15] <ogra> just dpkg -x the .deb
[17:16] <mpoirier> ogra; thanks.
[17:16] <mpoirier> ogra:  the cmdline-maverick-armel+omap3.img image, what format is it ?
[17:17] <GrueMaster> It is a SD image.  2 partitions.
[17:17] <ogra> its a two partition img to dd to the SD card
[17:17] <mpoirier> yes, but if I want to mount it live on my file system...
[17:17] <mpoirier> a simple mount -o loop fails.
[17:17] <mpoirier> using "file" on the image yields:  x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 63, 144522 sectors; partition 2: ID=0x83, starthead 0, startsector 144585, 867510 sectors, code offset 0x0
[17:18] <mpoirier> haven't seen that before.
[17:18] <GrueMaster> Then you need to find the starting byte of each partition (parted will give you this) and mount with -o loop,offset=<start byte>.
[17:18] <prpplague> ogra: definetly some weirdness going on with that kernel soruce
[17:18] <mpoirier> ogra: ok.
[17:18] <ogra> prpplague, well, its an ubuntu kernel with the TI patches on top
[17:18]  * prpplague digging into it
[17:18] <ogra> prpplague, afaik sebjan maintains it on the TI side
[17:18] <GrueMaster> mpoirier: I'll send you a link on how to do this.
[17:19] <GrueMaster> http://wiki.edseek.com/guide:mount_loopback
[17:20] <mpoirier> GrueMaster: I just got it with the offset command you sent me above.
[17:20] <mpoirier> I get it now.
[17:22] <prpplague> ogra: interesting, straight out of the box with the defconfig, the kernel fails to compile
[17:23] <ogra> indeed
[17:23] <ogra> you need to build it like a debian package
[17:23] <ogra> it runs various scripts to assemble the different config snippets
[17:24] <jkridner1> hi prpplague.  I should free up here shortly and can swing by if you let me know where you are at.  still don't have the LCD. :(
[17:24] <prpplague> huh? you don't use the defconfigs?
[17:24] <ogra> prpplague, no
[17:24] <prpplague> jkridner1: E-2126 , just down from geralds office
[17:24] <prpplague> hmm
[17:25] <ogra> prpplague, there is an ubuntu (non arch specific) config and there is an arch specific one
[17:25] <ogra> must be somewere in the debian dir, i guess soemone from the kernel team can explain it better than me
[17:26] <ogra> to build it you definately need to run "fakeroot debian/rules <whatever target you want to build>"
[17:26] <prpplague> ogra: i'll dig around and see what i can find
[17:26] <ogra> debian/rules is the makefile
[17:26] <prpplague> ogra: guess we need to know how to test the ubuntu kernels
[17:26] <ogra> prpplague, we'll soon have daily images
[17:26] <ogra> so you can just install the image and regulary upgrade the kernel
[17:27] <prpplague> ogra: well i don't like not knowing, i just assumed ubuntu built the kernel just like the rest of the world, hehe
[17:27] <prpplague> ogra: i mainly do kernel dev
[17:27] <ogra> it builds it slightly similar to debian
[17:27] <prpplague> ogra: so i need to be able to hack
[17:28] <ogra> well, the kernel team maintains it in a git tree like any other kernel dev does :)
[17:28] <ogra> just the build process is different since its wrapped in packaging stuff
[17:29] <prpplague> i'm sure there is a doc somewhere that describes the process
[17:30] <ogra> right
[17:32] <ogra> prpplague, https://help.ubuntu.com/community/Kernel/Compile i think
[17:32]  * prpplague looks
[17:33] <ogra> "Build the kernel (when source is from git repository, or from apt-get source)"
[17:33] <ogra> thats the section you want
[17:34] <prpplague> yea, reading over that now
[17:34] <ogra> you need beefy hardware though (we do not cross compile)
[17:35] <prpplague> yea looks there are some "multi-boot" issues
[17:35] <prpplague> testing
[17:38] <prpplague> ok, here is the bit
[17:38] <prpplague> ogra: they have the DPI picodlp enabled in the config
[17:38] <ogra> ouch
[17:39] <ogra> probably a blaze leftover
[17:39] <ogra> lag, ^^^
[17:39] <prpplague> ogra: so if you have that enabled along with the HDMI, you need to change the number of framebuffers to 2 instead of 1, and in addition you need to allocate enough memory for both, 16 is probably enough, but a safe value is 32
[17:40] <ogra> lag, can you take care that cooloney gets that info ?
[17:42] <mpoirier> GrueMaster: moving to ogra's u-boot fixed my USB EHCI issue - thanks.
[17:42] <ogra> great :)
[17:46]  * prpplague retests with the common config
[17:47] <davidm> mpoirier, both boards are working now?
[17:47] <GrueMaster> interesting.
[17:48] <GrueMaster> Must be a u-boot<>kernel combination issue.  I haven't tried the new kernels on the old system.
[17:54] <mpoirier> davidm
[17:55] <prpplague> good lord that common image is giant
[17:57] <mpoirier> davidm: both boards are working now.
[18:01] <prpplague> ogra: yea looks like the same issue with the common config, they have 3 different dss drivers enabled, DSI, DPI and HDMI, but only have 2 framebuffers allocated
[18:02] <prpplague> ogra: easiest is to just use 32MB for the framebuffers, that should work fine
[18:05] <sebjan> prpplague: we want to have a single kernel image/defconfig for both blaze and panda, so we need to have picodlp activated, right? Are there changes to apply to the config according to you?
[18:06] <prpplague> sebjan: assuming i am using the right config per the instructions, the vram needs to be increased to a min of 16, preferable to 32
[18:07] <ogra_cmpc> well, we have enough ram, 32 should be doable
[18:08] <sebjan> ... and in case we want to use the serial only ;), we can force a lower value in command line then, right?
[18:09] <ogra_cmpc> no idea if there is a cmdline override :)
[18:10] <prpplague> sebjan: correct
[18:10] <ogra_cmpc> does the vram value override the kernel default ?
[18:11] <prpplague> ogra_cmpc: on the command line it does
[18:11] <prpplague> sebjan: i emailed you the config i am using
[18:12] <ogra_cmpc> ah, great, so you only need to change boot.scr
[18:14] <sebjan> prpplague: great thanks, I'll take this change
[18:24] <prpplague> sebjan: np


[02:21] <zul> hey
[02:26] <jbailey> Wow, really musn't leave this long between merges of initramfs-tools
[02:26] <zul> oh dear i have the hiccups
[02:27] <jbailey> The merged version only has 908 lines of diff now.  *sigh*
[02:28] <zul> only?
[02:28] <Keybuk> heh
[02:28] <Keybuk> that's quite an improvement
[02:29] <Keybuk> what are the major changes?  did we take the /etc/mkinitramfs => initramfs-tools change?
[02:29] <jbailey> Yup
[02:29] <jbailey> Alot of it was that they went through and cleaned up quoting.
[02:29] <jbailey> We pushed hook scripts out to various packages.
[02:30] <jbailey> (I've taken all of the quoting changes now.  yay debdiff)
[02:32] <Keybuk> cool
[02:33] <jbailey> Alot of the stuff that's in the Debian version is actually things from us.
[02:34] <jbailey> So while there would be subtle things like quoting changes.
[02:34] <jbailey> Or places where tab/8 spaces was different, they code was the same.
[02:34] <Keybuk> ok, so we shouldn't expect much to change?
[02:34] <jbailey> Right.
[02:35] <jbailey> There's a new noresume feature.
[02:35] <jbailey> And whee, the machine booted fine.
[02:39] <jbailey> Keybuk: An interesting change is that rather than doing touch /dev/.initramfs-tools, it now does > /dev/.initramfs-tools
[02:39] <BenC> kernel-package uploaded aswell
[02:39] <jbailey> So you can always fetch more info from there.
[02:39] <jbailey> Also, it fixes the ramdisk size for /dev at 10M
[02:40] <jbailey> Adds cryptroot support
[02:42] <jbailey> Apparently works with lilo better now.
[02:42] <BenC> zul: I'd be interested to know if the new kernel-package handles your xen stuff well
[02:42] <BenC> zul: I can send you a .deb if you need it
[02:43] <zul> BenC: it doesnt work that great with the patch that we had, it didnt make the vmlinuz and when i tried making the kernel-image it wanted to make linux-xen0
[02:43] <zul> debian doesnt use kernel-package for the xen0 kernels
[02:44] <zul> other than that i been doing make and make install for the modules and vmlinuz
[02:46] <jbailey> whee, accepted.
[02:46] <jbailey> Off to spend the rest of the evening with my wife and sister-in-law.
[02:47] <zul> if the kernel-package sees CONFIG_XEN then it wants to build the linux-xen0 image
[02:49] <BenC> zul: I didn't port the xen stuff, just relying on the support already in kernel-package 10.x
[02:49] <zul> BenC: i know :)
[02:49] <BenC> you could just install the debian kernel-package, and for xen, it should be same
[02:49] <BenC> ok :)
[02:50] <zul> true...i havent tried the kernel-package since
[02:50] <DarkMageZ> can anyone confirm if r8169 exists in dapper's k7-26?
[02:52] <crimsun> /lib/modules/2.6.15-26-686/kernel/drivers/net/r8169.ko
[02:52] <crimsun> I don't see why -k7 would differ.
[02:53] <cjb> likewise /lib/modules/2.6.15-23-k7/kernel/drivers/net/r8169.ko
[02:53] <cjb> (which is k7 but not 26.)
[02:55] <DarkMageZ> yeah, i did test the box against -23 (which it still has hanging around). hmm, i'll have to do more testing when i get back to work... thanks
[02:56] <crimsun> -rw-r--r-- root/root     37174 2006-07-07 14:24 ./lib/modules/2.6.15-26-k7/kernel/drivers/net/r8169.ko
[02:57] <DarkMageZ> yeah, i brought one of those cards yesterday and it just didn't work. i'll check over for me making noob mistakes and try again :) cyas
[03:00] <cjb> Speaking of this stuff, is there a reason I'm not getting grub runs after kernel installs, after upgrading to edgy?
[03:00] <cjb> .. or initrds made.
[03:00] <zul> er....known bug
[03:03] <cjb> Ah, thanks.
[08:54] <fabbione> BenC: i think we are going to readd gfs1 to the kernel together with gfs2
[08:55] <fabbione> RH just realized that they can't kill one for the other without at least a 5 years overlap for transitioning :)
[09:09] <zul> heh...redhat
[09:41] <BenC> fabbione: ok
[09:41] <fabbione> BenC: in any case i will do the merge if required
[09:41] <fabbione> so you don't need to worry about it really...
[10:02] <zul> bbl...im going back to bed
[12:17] <Keybuk> anyone awake?
[12:17] <Keybuk> who cares about ia64?
[12:17] <lifeless> heh
[12:17] <lifeless> academically, or pragmatically ?
[12:17] <Keybuk> either :p
[12:18] <lifeless> well, I care, not that I ever do anything about it ;)
[12:18] <fabbione> Keybuk: what's the problem?
[12:18] <Keybuk> fabbione: asm/errno.h is missing from l-k-h
[12:19] <fabbione> Keybuk: that would be jbailey's fault..
[12:19] <Keybuk> in fact, /usr/include/asm is missing entirely
[12:19] <fabbione> Keybuk: i have not time to fix it right now. Neither i have my machine up at the moment
[12:20] <fabbione> i have to finish the rh-c-s merge first
[03:31] <zul> hi ho
[03:48] <mjg59> BenC: Keybuk: Someone's complaining that since the dapper kernel update, the kernel can't find their root filesystem
[03:50] <mjg59> Oh, scratch that, he's being confusing about timing
[03:51] <msemtd> mjg59: I'm confused!
[03:51] <mjg59> msemtd: Ah, you're in here too
[03:51] <mjg59> Excellent
[03:51] <msemtd> yup - looking for Keybuk!
[03:53] <mjg59> Right
[03:53] <mjg59> So was the machine running the released version of dapper previously?
[03:54] <msemtd> yes - it's been dapper for a few weeks
[03:54] <msemtd> I upgraded from breezy
[03:54] <mjg59> msemtd: Ok. There have been no udev updates during that time period.
[03:54] <mjg59> So it's certainly not a udev issue.
[03:55] <msemtd> the upgrade went well
[03:55] <msemtd> I was assuming my rpoblem was simillar to some of the others' who report a simillar hang
[03:56] <zul> is it sata?
[03:56] <msemtd> ...although I only have a single IDE HDD with / & swap
[03:56] <mjg59> msemtd: The "hang" is what happens when you don't have a device node for your root file system
[03:56] <mjg59> There are various reasons why that could happen
[03:57] <mjg59> It could be udev fucking up, or it could be the kernel fucking up
[03:57] <mjg59> In this case it sounds more like a kernel issue than a udev one
[03:57] <msemtd> ...or both! :)
[03:57] <msemtd> yeah - it followed a kernel upgrade
[03:57] <msemtd> but now the older kernels won't find root either
[03:59] <msemtd> I could keep trying different root=/dev/xxx from grub
[04:01] <msemtd> mjg59: should I boot with break=top ?
[04:01] <mjg59> msemtd: That would be a good start
[04:02] <msemtd> what to I need to do to load the device driver module following that?
[04:02] <mjg59> modprobe module_name
[04:02] <msemtd> I suppose that's IDE
[04:02] <mjg59> Depends on what sort of controller you have
[04:02] <mjg59> There's probably a specific module
[04:02] <mjg59> What sort of motherboard chipset?
[04:03] <msemtd> it's onboard ide SiS
[04:03] <mjg59> Ah, hang on
[04:03] <mjg59> Do break=premount
[04:03] <mjg59> Rather than break=top
[04:03] <mjg59> Then the module should be loaded
[04:03] <mjg59> Sorry, break=mount
[04:03] <mjg59> Then go into /dev and see what hd* nodes there are
[04:04] <msemtd> ok, break=mount - look in /dev - goddit
[04:04] <msemtd> hmm, will I have a shell by then?
[04:04] <msemtd> BusyBox?
[04:04] <msemtd> ...from initrd?
[04:12] <Keybuk> mjg59, msemtd: hmm?
[04:12] <mjg59> msemtd: Yup
[04:13] <msemtd> Keybuk: sorry - I thought my boot problem was udev
[04:13] <msemtd> I have the root file system not found following linux-image-2.6.15-26-686 upgrade
[04:14] <msemtd> ...hangs at "Waiting for root file system" then gives up on /dev/hda1 and gives me a BusyBox shell
[04:16] <msemtd> tried acpi=off noapic irqpoll etc (my usual workarounds :) )
[04:18] <msemtd> tried reinstalling older kernels but whilst chrooted from a knoppix 2.6 kernel so dunno if that'd screw things up
[04:34] <msemtd> why would older kernels (that previously worked) fail to boot when reinstalled? I sit because grub is pointing to a different udev device?
[04:34] <msemtd> s/I sit/Is it/
[04:42] <mjg59> Grub's configuration won't have changed
[04:47] <msemtd> the apt-get install will have run grub-update won't it?
[04:52] <mjg59> Yes. That doesn't change the grub configuration.
[04:52] <mjg59> Unless your config was already broken before you installed the kernel
[04:53] <msemtd> I think the grub config is fine - each new kernel I apt-getted whilst under knoppix got added
[04:54] <mjg59> But until you do the test, we're going to have no idea
[04:54] <msemtd> true - I'll be trying tonight
[06:12] <msemtd_> mjg59: ok, at home now - I did break=mount and there are no hd entries at all
[06:14] <mjg59> msemtd_: can you cat /proc/modules and look for anything with sis in?
[06:15] <msemtd_> ok one mo...
[06:15] <msemtd_> no, nothing with sis in it
[06:16] <BenC> anything with ata in it?
[06:17] <msemtd_> um, no - we have commoncap and capability, softcursor, etc.
[06:20] <msemtd_> is there something I could modprobe?
[06:20] <msemtd_> ide_generic?
[06:24] <mjg59> You could try that
[06:26] <msemtd_> wahay! I now have /dev/hdaxxx
[06:28] <mjg59> Right
[06:28] <mjg59> Can you do
[06:30] <mjg59> grep 0x0101 /sys/bus/pci/devices/*/config
[06:30] <mjg59> Sorry
[06:30] <mjg59> grep 0x0101 /sys/bus/pci/devices/*/class
[06:30] <mjg59> And then go to the directory with a match and do
[06:30] <mjg59> cat vendor
[06:30] <mjg59> cat device
[06:33] <msemtd_> sorry, mjg59 I'll have to get back to this one - got to sort the kids out
[06:33] <mjg59> Ok
[06:34] <Keybuk> BenC: we're not going with .18, right?
[06:36] <msemtd_> vendor is 0x1039 device is 0x5513
[06:36] <BenC> Keybuk: no
[06:38] <mjg59> msemtd_: Hm. Odd. sis5513 should bind to that
[06:38] <mjg59> msemtd_: Can you do rmmod ide_generic; modprobe sis5513
[06:38] <Keybuk> BenC: GregKH has some more random sysfs changes happening, I assume those are for .18 or .19 and didn't go into .17
[06:39] <BenC> nothing scary in .17 that I'm aware of
[06:39] <Keybuk> aye, /sys/class in .17 is still just class_dev
[06:39] <msemtd_> mjg59: hmm, says "neither ide port enabled"!
[06:41] <mjg59> msemtd_: Right. Interesting.
[06:41] <msemtd_> mjg59: ah it seems ide0 and ide1 are taken!
[06:41] <mjg59> msemtd_: Is ide_generic unloaded?
[06:42] <msemtd_> sorry - i'll get back to this later
[06:42] <mjg59> Ok
[06:42] <Keybuk> BenC: any particular reason for the conservative kernel choice?  bad experience with dapper?
[06:43] <mjg59> Keybuk: We have no especially good idea when 2.6.18 will be released
[06:56] <BenC> Keybuk: not only that, but I didn't want to be chasing upstream kernel bugs+fixes for most of the release cycle
[06:58] <BenC> when we did dapper, .15 was opened right before dapper started, and I knew we'd have 3 months of settling after .15 was released
[06:59] <BenC> .18 was opened shortly after edgy started, and we'd probably only have 6 weeks max after .18 was released before edgy released
[07:23] <Keybuk> seems fair
[07:45] <jbailey> BenC: And that's assuming that any work gets done in August on 2.6.18, which I think unlikely.
[07:45] <jbailey> Summers are great for development when it's mostly students.  Crap when it folks with spouses, kids, and vacation time who hack for a living.
[07:51] <BenC> jbailey: Sorry, I missed most of what you said...was outside in the swimming pool with my kids, and then played some volleyball  ;)
[07:52] <Keybuk> BenC: we're so not fooling for your "I have a life outside of work" pretence
[07:59] <zul> heh
[08:02] <jbailey> BenC: *lol*
[08:15] <BenC> hehe
[08:24] <BenC> no sign of Mith, but I'm sure he will allow an exception for a new kernel, given that the current kernel wont boot after install
[08:34] <mdz> BenC: did you re-enable that workaround for my VIA sound IRQ problem?  I can't use 2.6.17 until that's back
[08:45] <BenC> mdz: crap, I forgot to include it before upload...I'll get it in and have a pre-knot-1 kernel for you
[08:58] <BenC> 309M    .xchat2/xchatlogs/
[08:58] <BenC> think maybe I need to prune that
[08:59] <zul> a bit
[09:12] <BenC> sweet
[09:12] <BenC> fabbione: New pbbuttonsd handles keyboard backlighting on my pb now!
[09:19] <fabbione> BenC: yes i saw it!
[09:21] <BenC> it's using a different hueristic than macosx does though
[09:21] <BenC> on osx, if you were in complete darkness, the keyboard lights were actually a bit dimmer than if you were in partial light
[09:21] <BenC> it got brighter, then dimmer as the light decreased
[09:21] <fabbione> BenC: yes, there is a sensor on the keyboard that enable/disable backlight automatically in MacOS
[09:22] <fabbione> yeah
[09:22] <fabbione> MacOS was either on/off or manual
[09:22] <fabbione> the new psbuttunds is more smooth
[09:22] <BenC> macosx was smoother for me
[09:22] <fabbione> hmmm
[09:22] <BenC> it was automatic
[09:22] <fabbione> i will check again...
[09:22] <fabbione> it's rare i work in the dark anyway
[09:23] <BenC> same here, but it's nice when the light is as the threshold where the black-on-grey keys are hard to read
[09:23] <fabbione> ehhe yeah
[09:24] <fabbione> i am off to watch a movie.. later :)
[09:25] <BenC> jbailey: ping
[09:25] <BenC> later
[10:57] <BenC> jbailey: dpkg-deb: building package `linux-kernel-headers' in `../linux-kernel-headers_2.6.17-5.7_powerpc.deb'.


 "Hello, I'm new to Xubuntu and..." <- Your release details is always helpful.  You can use `dpkg -i <package>` to install a *deb* package... but that will require all *depends* requirements for thee package to be already installed OR you adjust the command to install them as well.  You can also use `apt` to install a already downloaded package (*give a filepath instead of simple package name*) which has the capacity to attempt to
[01:19] <guiverc[m]> download the requirements (packages needed to meet the *depends* rules) for you if they're available in your pre-added sources.
[08:31] <nikolam> I have a mousepad process, using 100% of one core and not visible anywhere on Xfce desktop.
[08:31] <nikolam> I have put machine into standby and back before and it resumed from suspend this morning.
[08:32] <nikolam> What would be the best way of debugging that 'undead' mousepad and ret it's debug information?
[08:37] <anonymous> hi
[11:45] <nikolam> I attached with gdb on 'mousepad' process that was left on, after standby/resume with large cpu usage, now doesn't use large cpu time anymore but is still alive and can't see it in X session
[11:45] <nikolam> Any suggestion how to debug it, catch info, before killing it, to get debug data why it is still on ?
[11:53] <nikolam> Ok, I just killed it, maybe another time.
[14:19] <nikolam> https://pastebin.com/9e5MsDWL


[04:31] <tjaalton> hasty llstarks
[04:31] <tjaalton> synaptics probably just needs a bump
[04:33] <tjaalton> bryce: did you upload -intel?
[04:37] <tjaalton> apparently so according to #ubuntu-kernel, so push git too :)
[04:59] <bryce> tjaalton, ahem, it's both uploaded and pushed; check again
[04:59] <tjaalton> thanks :)
[05:00] <tjaalton> oh, minutes before my ping, the commit email was just slow to arrive then
[05:01] <bryce> ah.  odd, I pushed it a while ago maybe an hour or so
[05:02] <bryce> anyway, 10pm on a friday night, time for no more working
[05:02] <tjaalton> yeah, cool
[05:02] <tjaalton> 8am saturday, just checking we get the fixes in
[05:03] <tjaalton> hmm no plymouth update yet
[05:03] <bryce> grr
[05:04] <tjaalton> it'd need a lightdm upload still, but having this in now wouldn't hurt
[05:04] <tjaalton> well *dm
[05:05] <bryce> ickle did the triage request-for-retest on all the mesa gpu lockup bugs.  So our bug graph is looking very good right now
[05:06] <bryce> http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-raring-workqueue.svg
[05:06] <tjaalton> yeah I poked him about it yesterday
[05:06] <bryce> aha
[05:06] <tjaalton> or more like just notified we got 9.1.1 in
[05:06] <bryce> I banged down the xserver bugs a bit this week.  Looks like you've been very active too.
[05:07] <tjaalton> I did some blob triage
[08:57] <mlankhorst> morning
[09:03] <llstarks> morning
[09:23] <tjaalton> llstarks: synaptics just needs a version bump on the ppa
[09:24] <llstarks> intel too
[09:25] <tjaalton> yeah
[09:26] <tjaalton> intel uploaded now
[09:27] <llstarks> should be interesting getting a proper xserver and -modesetting from staging and then targetting nvidia-319 from edgers without pulling in everything else
[09:27] <tjaalton> huh, synaptics is there and a newer version too than is in raring now
[09:28] <llstarks> i'm not booted into ubuntu atm, i can get you a list of conflicts
[09:28] <tjaalton> https://launchpad.net/~canonical-x/+archive/x-staging
[09:28] <tjaalton> unless it didn't actually build against the new xserver
[09:29] <llstarks> probably not, apt wanted to hold everything back or uninstall
[09:29] <tjaalton> uploaded
[09:29] <tjaalton> just in case
[09:31] <llstarks> i'll try later today, need to pass out. thanks
[22:23] <Sarvatt> ugh this new gmail interface.. didn't realize i was top posting and quoting the entire bug when responding to bugs.debian.org :P
[22:37] <llstarks> thunderbird bro
[22:59] <llstarks|temp> tjaalton: that apt log i promised http://pastebin.com/DAE43C5v


[07:04] <MooDoo> hello all
[13:34] <dholbach> balloons, davidcalle, popey: are you guys hanging out for the docs day?
[13:34] <popey> yes, can do, finishing off current meeting
[13:34] <balloons> ahh yes, omw
[13:37] <davidcalle> dholbach, omw
[13:43] <popey> sorry, overrunning
[16:51] <czajkowski> pleia2: anyone in the valley you know may might be interested in http://www.meetup.com/Couchbase-Silicon-Valley/events/223898914/ tonight
[16:55] <pleia2> czajkowski: alas, not keen on spending 2 hours commuting down to the valley again today
[16:55] <pleia2> tiiired
[16:59] <czajkowski> pleia2: nods I know not you, but others :)
[17:00] <czajkowski> now aiming for 2 a month, 1 in our mission st office and 1 out in MV
[17:00] <czajkowski> as we know people dont like to commute :)
[18:28] <balloons> so I just joined a google hangout from my ubuntu phone. Pretty cool
[18:28] <balloons> recieving audio and video worked, but not sending audio or video :-(
[18:30] <popey> blimey


[18:37] <maco> :(((((( the person who runs the labs at school just said that regardless what my professor and the TAs said im not allowed to switch lab sessions because of uds
[18:44] <czajkowski> oh dear
[18:44] <czajkowski> maco: whats that gonna mean for you ?
[18:45] <maco> i dont know
[18:45] <maco> gonna try to get the prof to overrule her, but if he cant... itd mean choosing between uds and failing
[18:45] <czajkowski> maco: do you need to be at the lab
[18:45] <czajkowski> as in if you miss it do you fail your year?
[18:45] <maco> yes, if i miss a lab, i fail the class
[18:46] <czajkowski> oh that is bad
[18:46] <czajkowski> we used to be ale to miss at least 2 a semester
[18:46] <czajkowski> as you know things come up and people are ill
[18:47] <maco> so can we... except i registered late because the class was full
[18:47] <maco> by  the time i joined the class, 2 were done with
[18:47] <maco> so im not allowed to miss any
[18:47] <czajkowski> ;(
[18:47] <czajkowski> seems a bit ott, but unfortunate
[20:20] <maco> woo! permission obtained. told her the prof gave permission a month ago and showed her the email from canonical about UDS, and she signed off on it
[20:24] <AlanBell> phew!
[20:45] <dinda> maco and anyone who might know anyone who can code iPad/iPhone apps:  I know someone looking for a freelance developer to work on education apps
[20:45] <maco> dinda: i know an apple employee who i think still does iphone apps on the side
[20:47] <hypatia> dinda: i know someone who does that full-time
[20:47] <dinda> hypatia: excellent, anyone feel free to send them my way and I'll forward to my friend


[05:52] <pitti> thomi: hm, what's the official way to run an autopilot test in-tree now?
[05:52] <pitti> $ PYTHONPATH=. python -m autopilot.run run autopilot.tests.functional.test_introspection_features.IntrospectionFeatureTests.test_window_geometry
[05:52] <pitti> $ python3 -m testtools.run discover autopilot.tests.functional.test_introspection_features
[05:52] <pitti> both of these fail
[05:52] <pitti> and there is no bin/autopilot any more which DTRT
[05:52] <thomi> pitti: yes, that test fails, veebers found that today, and he's looking at it :)
[05:52] <thomi> pitti: DTRT?
[05:52] <pitti> thomi: no, I mean it doesn't even start running the tests
[05:53] <pitti> thomi: I wanted to see what's wrong with it as I recently touched it, but I don't know how to run a test
[05:53] <pitti> thomi: "autopilot" uses the system-installed ap, that doesn't work as it's way too old in trusty
[05:53] <pitti> I need to run it from within the tree
[05:53] <thomi> pitti: well, you don't need to set PYTHONPATH, but aside from that, what you're doing is correct
[05:54] <thomi> pitti: also, the system autopilot in trusty should work fine
[05:54] <thomi> pitti: I think maybe there's something funny happening on your system?
[05:54] <pitti> thomi: http://paste.ubuntu.com/6719045/
[05:54] <pitti> thomi:
[05:54] <pitti> $ autopilot run autopilot.tests.functional.test_introspection_features.IntrospectionFeatureTests.test_window_geometry
[05:54] <pitti>     from autopilot.testresult import AutopilotVerboseResult
[05:54] <pitti> ImportError: cannot import name AutopilotVerboseResult
[05:54] <pitti> ^ that's a change in trunk which isn't in trusty yet
[05:55] <thomi> pitti: oh wait - sorry - I forgot I built & installed it from source :-/
[05:55] <pitti> thomi: trusty has 20131125, that's fairly old
[05:55] <thomi> sorry :)
[05:55] <pitti> thomi: np; hence I wonder how to run it out of the tree now
[05:55] <pitti> thomi: i. e. the equivalent of bin/autopilot [...]
[05:55] <thomi> this works for me:
[05:55] <thomi> python3 -m autopilot.run run autopilot.tests.functional.test_introspection_features.IntrospectionFeatureTests.test_window_geometry
[05:55] <thomi> as does python 2
[05:56] <pitti> I get above pastebin error (AttributeError: 'module' object has no attribute 'functional')
[05:56] <thomi> http://pastebin.ubuntu.com/6719052/
[05:56] <pitti> with both py 2 and 3
[05:56] <thomi> O.0
[05:56] <thomi> and your CWD is inside the lp:autopilot checkout location?
[05:56] <pitti> thomi: yeah, that's the error I wanted to get and investigate
[05:57] <pitti> thomi: yes, I'm in the root dir of the lp:autopilot checkout
[05:57] <thomi> hmmmm
[05:57] <pitti> thomi: ok, but that's the official command?
[05:57] <pitti> then I'll investigate what's wrong with that
[05:57] <thomi> pitti: yeah
[05:57] <pitti> (we should add that to README)
[05:58] <pitti> thomi: even tox.ini says "autopilot run", which again uses the system installed ap, right?
[05:58] <thomi> pitti: no, because tox installs into a virtualenv
[05:58] <thomi> pitti: but the tox config is broken on trusty for some reaon
[05:58] <thomi> *reason
[05:58] <thomi> if you happen to find the problem.... you know what to do :)
[05:59] <pitti> thomi: yeah, I just wanted to make sure I'm actually using the right command this time; thanks
[05:59] <thomi> yeah. generally, 'tox <test_id>' should do what you want
[06:00] <pitti> aah!
[06:00] <pitti> $ sudo apt-get install python3-fixtures python-fixtures
[06:01] <pitti> of course that error message made it *absolutely clear* that the "fixtures" module was missing
[06:01] <thomi> isn't that a dependency on python-autopilot & python3-autopilot?
[06:01] <pitti> (not!)
[06:01] <pitti> thomi: it is apparently fairly recent (not in trusty yet)
[06:02] <pitti> thomi: anyway, the test_window_geometry WFM
[06:02] <thomi> pitti: the failures are specific to desktop configuration
[06:02]  * pitti looks at code to get some ideas what could go wrong
[06:02] <thomi> the test assumes that the desktop starts at 0,0
[06:03] <thomi> and also assumes that there's only one screen configured
[06:03] <thomi> and further assumes that applicaiton geomentry will always be wholly within the desktop area.
[06:03] <thomi> all in all, not a great test :)
[06:03] <pitti> I enabled my internal monitor, still works
[06:03] <pitti> I moved it to the left of my primary monitor, still works
[06:04] <pitti> (I tested these cases back then)
[06:04] <thomi> hmmm
[06:04] <pitti> but I guess it's related to that, I'll have a closer look and follow up to the bug
[06:04] <thomi> if you can't reproduce, then veebers or I can take a look - at least we have a reproducer already :)
[06:09] <pitti> thomi: followed up
[06:10] <pitti> thomi: so apparently I don't understand what the window geometry says, or there is actually a bug somewhere that it sometimes ends up being negative
[06:13] <thomi> yeah, me too
[06:13] <thomi> there's something screwy going on, for sure
[06:13] <thomi> anyway, I gotta go eat dinner.
[06:13] <thomi> might be on later, but probably not
[06:14] <thomi> talk to you tomorrow!
[06:17] <DanChapman> Good Morning
[06:28] <pitti> hey DanChapman
[06:28] <DanChapman> pitti hey :-) how are you?
[06:29] <pitti> DanChapman: I think only ints and strings are matched on the server (libautopilot-gtk/qt, inside the application) side; any other properties (like float) are matched on the client (i. e. autopilot) side
[06:29] <pitti> or more complicated selects
[06:29] <pitti> in those cases, the whole widget (set) is transmitted over D-BUS, and ap filters the result
[06:30] <pitti> DanChapman: quite fine, thanks! and you?
[06:34] <DanChapman> pitti, ahh  ok I see, that makes sense. I mentioned to jibel yesterday about how in the autopilot log of the failed tests that there is an "atk_object_set_parent: assertion 'ATK_IS_OBJECT (accessible)' failed" right before the segfault. COuld it be a Gtk/Atk bug causing our crashes?
[06:35] <DanChapman> pitti, awesome, Yes I'm really good thanks
[06:35] <pitti> DanChapman: in principle, yes; if something before that code corrupts the stack, then anything is possible
[06:36] <pitti> i. e. we need to find out what calls set_parent() and why it's calling that on an invalid object
[06:37] <pitti> DanChapman: oh, is that really an assertion failure, or a CRITICAL?
[06:37] <pitti> DanChapman: an assertion failure should terminate ubiquity, with SIGABRT
[06:38] <pitti> CRITICALs are merely printed out and then the program continues, unless you run ubiquity with G_DEBUG=fatal-criticals
[06:38] <DanChapman> pitti its a CRITICAL
[06:38] <pitti> that's useless for debugging where a critical happens, but of course inconvenient if there are lots of other criticals before that
[06:38] <pitti> sorry, s/useless/useful/
[06:54] <DanChapman> pitti, I see so it might not be that then, I just find it strange it being the last thing that occurs before the segafult.
[06:54] <pitti> DanChapman: oh, it certainly might be that
[06:54] <pitti> DanChapman: i. e. it's well worth investigating why that critical happens
[07:36] <elfy> morning
[11:35] <pitti> jibel: hm, wazn unhappy again? I already retried on i386, amd64 works fine (http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-shotwell/ARCH=i386,label=adt/61/console)
[11:35]  * pitti logs in and check
[11:38] <pitti> jibel: indeed, I can reproduce with "./auto-package-testing/bin/run-adt-test -sU -a i386 shotwell"
[11:38] <jibel> pitti, there is no particular activity on this machine
[11:38] <pitti> with -a amd64 it works
[11:38] <jibel> pitti, I'll reprovision the base vm
[11:38] <pitti> broken i386 base image?
[11:39] <pitti> jibel: OOI, how do you do that? run prepare-testbed, or trigger the jenkins job?
[11:40] <jibel> pitti, either trigger the job trusty-adt-setup-testbed or run $HOME/auto-package-testing/bin/prepare-testbed -r trusty $ARCH
[11:40] <pitti> jibel: ok, I can do the latter (unless you already do)
[11:42] <jibel> pitti, it is running
[11:42] <pitti> jibel: I see you started prepare-testbed for amd64 (but that's the good one)
[11:42] <pitti> jibel: ack, thanks; I'll retry shotwell and spamassassin after that
[11:42] <jibel> pitti, I'll redo both
[11:42] <jibel> archs
[11:58] <jibel> pitti, vms have been rebuilt and shotwell is running on i386
[11:59] <pitti> that's http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-shotwell/ARCH=i386,label=adt/61/console ?
[11:59] <pitti> looks fine
[11:59] <pitti> jibel: merci
[12:00]  * pitti kicks spamassassin, too
[15:03] <elopio> good morning QA.
[15:04] <knome> morning
[15:04] <cgoldberg> morning elopio
[15:11] <elfy> afternoon :p
[15:18] <balloons> xnox, ping
[15:18] <xnox> balloons: hey!
[15:19] <balloons> xnox, so playing with the emulator finally :-) I noticed a few things.. 1) It's REALLY slow for me 2) The core apps don't seem to be a part of the base image you are using
[15:20] <xnox> balloons: 1) emulator is slow, it's a single core 700 Mhz cpu 2) like what ?
[15:20] <balloons> I'm mostly concerned about #2. Should I need to install them? Your run script runs things like weather and calc, but they aren't on my image
[15:32] <xnox> balloons: i'm still confused what you are missing. my scripts as posted latest are to do automated autopilot testing.
[15:33] <xnox> balloons: for general instructions of using emulator see https://wiki.ubuntu.com/Touch/Emulator ; which is ./build-emulator-sdcard.sh & ./run-emulator.sh
[15:33] <xnox> balloons: you should have mostly everything as a normal device, with same sets of apps etc.
[15:33] <xnox> balloons: what's missing? what's different?
[15:44] <balloons> xnox, sorry, got dc'd for a min. I followed your instructions.. I'll try again from the top. The resulting images were simply missing the core apps and I don't know why
[15:44] <rvr> elopio: Good morning
[15:44] <balloons> browsing, dialer, friends.. all there.. no core apps like weather or calc tho
[15:45] <xnox> balloons: which instructions?
[15:45] <balloons> from your email
[15:45] <xnox> balloons: can you give me a link to the post?
[15:46]  * xnox sent many emails with different instructions.... =)
[15:46] <xnox> balloons: or title of the email post.
[15:46] <balloons> https://lists.launchpad.net/ubuntu-phone/msg05784.html
[15:46] <xnox> balloons: none of that should be used to "play with emulator" or "use it"
[15:47] <xnox> balloons: that's only for automated, hand-off, execution of autopilot tests.
[15:47] <balloons> I'm trying to run core apps tests.. I tried the steps to do that and it failed.
[15:47] <xnox> balloons: if you want to start emulator and use it, please see https://wiki.ubuntu.com/Touch/Emulator#Instructions
[15:48] <balloons> xnox, right.. I don't care about using the emulator, I was looking to reproduce test runs.. then run my own
[15:48] <xnox> balloons: do you have logs of the failures?
[15:48] <balloons> xnox, do you build the sdcard before you run your tests?
[15:48] <xnox> balloons: it does everything.
[15:49] <balloons> ok, that's what I did then..
[15:49] <balloons> if I provision again, will it wipe the old stuff..
[15:49]  * balloons looks
[15:50] <xnox> balloons: calculator autopilot tests can crash the emulator at the moment, what else have you tried. friends pass, dialer partioally passes. weather should be ok as well, let me run that one now.
[15:52] <balloons> xnox, after taking a boot to boot, the loop checking for unity status goes on forever.. that's how every test ended
[15:52] <balloons> anyways, trying again.. let's see what happens
[15:52] <rvr> elopio: https://bugs.launchpad.net/ubuntuone-credentials/+bug/1248576
[15:53] <xnox> balloons: i should add watchdog for that. basically sometimes some click hooks fail in the emulator and thus unity8 never starts =(
[15:53] <rvr> elopio: I'm getting a similar bug in another test. Did you discover why StateNotFoundError happens?
[15:54] <elopio> rvr: in that case, it seems QML doesn't find a module.
[15:54] <elopio> so the window is actually missing the component you are looking for.
[15:54] <elopio> take a look at the QML errors to see if that's your case.
[16:00] <balloons> xnox, ok, same thing happens. Here's the log: http://paste.ubuntu.com/6721438/
[16:01] <balloons> currently, the emulator displays unity with the intro screen
[16:01] <xnox> balloons: the log does tell you what's wrong.
[16:01] <xnox> balloons: "error: more than one device and emulator" over and over and over again =)
[16:01] <balloons> yes :-)
[16:02] <balloons> lol.. I do have a device plugged in
[16:02] <balloons> d'oh
[16:02] <xnox> balloons: maybe you want to fix that =) as raised in the email thread....
[16:02] <balloons> it was the tablet, didn't even notice.. I'm sorry
[16:11] <xnox> balloons: <testsuite errors="1" failures="0" name="" tests="15" time="613.245">
[16:11] <xnox> balloons: so weather app does work.
[16:12] <balloons> xnox, seems to be running.. is there an easy way to get logs, or should I simply redirect output?
[16:12] <xnox> balloons: just wait for it to finish.
[16:12] <xnox> balloons: you will have logs, as done by phablet-test-run in the "clientlogs/" folder at the end.
[16:12] <balloons> perfect, ty. I ran the full run-tests.sh so this looks like it's going to be quite a bit
[16:17] <xnox> balloons: and will most-lickely fail a lot and get your emulator stuck =)
[16:17] <balloons> hah.. maybe I should quite while I'm ahead
[16:18] <elfy> or be quiet or quit :p
[16:18] <elfy> good day to you  balloons :)
[16:19] <knome> hallo
[16:24] <balloons> howdy elfy and knome
[16:26] <knome> xubuntu people, they come in numbers
[16:27] <balloons> always in a pack :-)
[16:42] <elfy> balloons - we hunt in packs
[16:42] <elfy> slickymaster is sneaking round the back to catch you out
[16:43]  * balloons looks around nervously
[16:45] <pitti> hey balloons
[16:45]  * slickymaster thinks that balloons should always be afraid... very afraid
[16:46] <slickymaster> and looking over his shoulder
[16:46] <balloons> hey pitti
[16:47] <pitti> balloons: your prodding sufficiently convinced me about bug 1033932, I just committed a fix :)
[16:47] <balloons> oO pitti !
[16:47] <pitti> http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2746
[16:47] <balloons> that's excellent news!
[16:48] <pitti> I really wasn't aware that we have so many "crash on logout" cases; I almost never get those
[16:48] <balloons> last cycle was especially bad for me.. this cycle hasn't been so bad. not seen many
[16:49] <balloons> it seems like the longer I run the same install the more buildup I get, the more I see them :-)
[16:50] <balloons> so pitti plans to SRU this at all? This should hit trusty at least soon
[16:50] <pitti> balloons: let's let it bake in trusty for a bit; the bug has a precise task
[16:50] <pitti> balloons: yes, stgraber is working on fixing apport for containers, then we'll land this in trusty (by next week)
[16:50] <balloons> ofc.. not rushing anything out, heh ;-)
[16:51] <balloons> still, that's very good news. This should really help out trsuty
[17:04] <slickymaster> balloons, DanChapman, can I ping you guys in something offtopic?
[17:04] <DanChapman> slickymaster, sure :-)
[17:04] <balloons> indeed
[17:05]  * DanChapman waves to balloons
[17:05]  * balloons waves back
[17:05] <slickymaster> I'm applying for ubuntu membership so I would like your testimonials if you think I'm worthy
[17:06] <slickymaster> balloons, DanChapman ^^^
[17:06] <DanChapman> slickymaster, I'd be more than happy too :-)
[17:07] <slickymaster> thanks, DanChapman. I sure appreciate it
[17:07] <slickymaster> DanChapman: my wiki page is https://wiki.ubuntu.com/slickymaster
[17:08] <DanChapman> slickymaster, cool I will get that done :-)
[17:08] <slickymaster> DanChapman: once again, thanls
[17:08] <slickymaster> *thanks
[17:28] <balloons> xnox, ok, so last question :-) If I wanted to run an arbitrary lp branch in the emulator, can I do it? If not, can we get it added?
[17:29] <xnox> balloons: there is no support for that at the moment, so patches welcome.
[17:29] <balloons> xnox, k, I'll give it a whirl
[17:29] <xnox> balloons: it will most-likely be patches to phablet-test-run
[17:29] <xnox> balloons: or options to run-test.sh
[17:30] <balloons> I want to let phablet-test-run do it.. so with that it should be simple on your end eh?
[17:30] <xnox> balloons: right, yeah anything that phablet-test-run supports is easy.
[18:08] <cgoldberg> slickymaster, nice work on wiki page.  I want to get mine together and apply also
[18:09] <slickymaster> thanks cgoldberg. I trully hope that you'll manage to be successful
[18:10] <slickymaster> cgoldberg: if you'll need any help, just ping me
[18:12] <DanChapman> jibel, you still about?
[18:13] <elfy> balloons: slickymaster is going for membership - he might not mention it to you ;)
[18:13] <balloons> elfy, indeed. I'm on it :-)
[18:13] <elfy> :p
[18:14] <cgoldberg> if most of my contributions to Ubuntu (besides being a fanatic user since Warty) are as a Canonical employee, do those count?
[18:15] <slickymaster> cgoldberg: I think elfy would be the best person to address that question
[18:15] <slickymaster> elfy: ^^
[18:16]  * elfy read the question and has no answer - balloons might have, being one
[18:17] <elfy> not sure I could think of any reason why not - but I've never had anything to do with the membership boards
[18:17] <balloons> contributions are contributions :-) The keys are sustained contributions and testimony from people about said contributions :-)
[18:18] <elfy> that
[18:18] <cgoldberg> fair enough
[18:36] <DanChapman> xnox, does the size of a disk image affect whether you get the auto-resize options. I'm using a 40G win7.qcow2 image and I only have the options to erase it or 'something else'
[18:37] <xnox> DanChapman: auto-resize option is tricky, it depends on many things.
[18:39] <xnox> DanChapman: so first the drive needs to be big enough for two fit two OS, second the original OS needs to be "defragmented enough" to be able to shrink, then shrinking should be possible (so Windws may not be suspsended / hybernated / mix hybernated / quick start disabled), there should be enough primary partitions left if MBR is used (some OEM configurations use up all primary partitions).
[18:39] <xnox> DanChapman: so there are plenty of reasons why auto-resize may not be offered.
[18:39] <xnox> DanChapman: at the moment there is no good logging in ubiquity to log why autoresize was not available.
[18:40] <xnox> DanChapman: also we at times fail to detect Windows 7  / WIndows 8 which also leads ubiquity into believing there "is a large data partition of unknown stuff, not sure what to do with" [18:42] <popey> xnox: related: http://askubuntu.com/a/401543/612 - saw this on AU recently. check out the screenshot of his partitions..
[18:43] <xnox> popey: well bdmurray wants to remove all upgrade options from inside ubiquity =)
[18:44] <xnox> popey: as "upgrade manager is the only support option"
[18:47] <DanChapman> xnox, ok I see thanks, it seems this could be quite tricky to get an image to work with the ubiquity tests then. THis image has sda1 -> ntfs MBR and sda2 -> ntfs, It detects its windows 7 ok i'll try a larger disk image
[18:47] <popey> xnox: makes sense
[20:29] <balloons> Letozaf_, evening to you
[20:29] <Letozaf_> balloons, hello
[20:33] <Letozaf_> balloons, howzit ?
[20:33] <balloons> Letozaf_, getting into using the emulator to run tests
[20:34] <balloons> since it runs so much slower, it can show finicky tests
[20:34] <Letozaf_> balloons, but is it better to test on a device or on the emulator ?
[20:35] <Letozaf_> balloons, saw the email about emulator but was wondering to use it as I have a device
[20:35] <balloons> Letozaf_, device is much faster testing if you have it :-) But if I can't reproduce the issue, the emulator might be helpful
[20:36] <Letozaf_> balloons, so it's better to have it just in case of need
[20:36] <balloons> Letozaf_,right.. and for example I'm looking at these failures; http://ci.ubuntu.com/smokeng/trusty/touch/maguro/114:20140106:20131223.2/5905/ubuntu-clock-app-autopilot/642628/ and http://ci.ubuntu.com/smokeng/trusty/touch/maguro/114:20140106:20131223.2/5905/calendar-app-autopilot/
[20:36] <balloons> they seem to only happen on the slow maguro device
[20:38] <Letozaf_> balloons, oh I see, so if one does not have that device he can use the emulator to reproduce it
[20:38] <balloons> Letozaf_, potentially yes :-) That's the idea
[20:40]  * DanChapman has just come across 'indicator-pitti', haha BRILLIANT!
[20:41] <Letozaf_> balloons, well maybe I can try this emulator too, then :)
[20:42] <balloons> Letozaf_, give it a whirl: https://lists.launchpad.net/ubuntu-phone/msg05784.html
[20:42] <balloons> Just make sure you unplug any devices from your pc first
[20:42] <balloons> or it won't work and you'll scratch your head like me
[20:43] <balloons> it will take 5 mins or so to boot
[20:43] <Letozaf_> balloons, thanks for telling me, had my device attached just now :P
[20:44] <balloons> lol.. trust me I spent awhile confused
[20:48] <Noskcaj> DanChapman, lolwut. Was that his fanclub again?
[20:48] <Letozaf_> balloons, the emulator started, but suppose I will have to wait for it to boot
[20:49] <balloons> Letozaf_, yes, it takes a bit.. no worries
[20:49] <Letozaf_> balloons, ok
[21:02] <Letozaf_> balloons, I get a ubuntu-phablet login:  but no tests start :?
[21:05] <balloons> keep waiting
[21:05] <balloons> lol
[21:05] <Letozaf_> balloons, ok :)
[21:12] <balloons> Letozaf_, it work?
[21:13] <Letozaf_> balloons, I'm a bit confused.. after some logs on the screen got another ubuntu-phablet login: now
[21:13] <balloons> what did you run?
[21:13] <Letozaf_> balloons, but in the emulator screen is still black
[21:14] <Letozaf_> balloons, I ran ./scripts/run-tests.sh
[21:14] <balloons> run-all takes 1.5 hours
[21:14] <Letozaf_> balloons, what ?
[21:14] <balloons> yes, looks like it iterated
[21:14] <balloons> you can find the logs in the clientlogs subfolder of the directory
[21:14] <balloons> so, now to run something specific do it like this
[21:14] <Letozaf_> balloons, wow I better stop it and try to run just one test
[21:15] <Letozaf_> balloons, ok tell me
[21:15] <balloons> ./scripts/run-test.sh click com.ubuntu.calendar calendar_app
[21:15] <balloons> or even just one test: ./scripts/run-test.sh click com.ubuntu.calendar calendar_app.tests.test_monthview.TestMonthView.test_monthview_go_to_today_prev_year
[21:15] <balloons> that's a 10 min task, hah :-p
[21:16] <Letozaf_> balloons, but now first I must shut it down and restart it with that script, right ?
[21:16] <balloons> yep
[21:17] <balloons> just end the current process
[21:18]  * Letozaf_ is running the calendar test now
[21:23] <balloons> it fails :-)
[21:24] <Letozaf_> balloons, yes the emulator closed and got emulator-arm: no process found
[21:24] <Letozaf_> balloons, ended just now
[21:24] <balloons> ohh.. that's no good
[21:25] <Letozaf_> balloons, :( what a pitty was curious to see it
[21:25] <balloons> it can fail, it's still wip.. but I've had good success
[21:25] <balloons> try again
[21:25] <balloons> if the emulator itself died you mena
[21:25] <Letozaf_> balloons, ok
[21:25] <balloons> the test should run, just fail to pass is all
[21:25] <Letozaf_> balloons, I will try it again, didn't see anything on the emulator
[21:32] <Letozaf_> balloons, the test does not run on my box:
[21:32] <Letozaf_> Removing directory /tmp/tmplRjlEL
[21:32] <Letozaf_> + /home/letozaf/autopilot-tests/touch-emulator/scripts/run-autopilot-tests.sh -s emulator-5554 -a calendar_app.tests.test_monthview.TestMonthView.test_monthview_go_to_today_prev_year -Q -S
[21:32] <Letozaf_> error: device not found
[21:33] <balloons> weird
[21:33] <Letozaf_> balloons, my device is not attached to my PC :)
[21:35]  * Letozaf_ is trying agai
[21:35] <Letozaf_> again
[21:36] <balloons> :-)
[21:41] <Letozaf_> balloons, sorry same error :(
[21:46] <Letozaf_> balloons, it's late for me now, be back tomorrow
[21:46] <balloons> Letozaf_, sorry to hear that
[21:46] <balloons> thanks for trying.. but you got to see the run-all work I suppose :-)
[21:46] <balloons> so it's another option
[21:47] <Letozaf_> balloons, what, where ?
[21:47] <balloons> Letozaf_, the initial run output stuff
[21:47] <Letozaf_> balloons, how do I do that ?
[21:47] <balloons> check clientlogs
[21:47] <balloons> the 1.5 hour run you did.. run-tests :-)
[21:48] <Letozaf_> balloons, ooooh!
[21:48] <Letozaf_> balloons, well maybe tomorrow I will try that and start early :)
[21:49] <Letozaf_> balloons, bye see you tomorrow
[21:49] <balloons> Letozaf_, ciao


[12:48] <Guest54916> I need help getting my system to function.
[13:05] <Marlon> Hello everyone. I gave up Windows and got down to work with Ubuntu Studio (I work on audio, mostly). The thing is, when I installed 14.04 I was no longer able to configure Ardour - Jack ir order to record sound. The signal enters Ardour (no specific track, just all of them) and I can't see how it's coming in...
[13:05] <Marlon> on Ubuntu Studio 13.10, only an armed track would receive the signal...
[13:06] <Marlon> I figured I could fix it watching Conections in Jack, but I can't...
[13:07] <Marlon> I'm a begginer, but I want to show my partners that Linux is a professional choice (they're always telling me we should go back to Windows...)
[13:12] <cfhowlett> Marlon I don't know - ask in #opensourcemusicians
[13:14] <Marlon> thank you ;)
[15:48] <antonio_> hi
[16:03] <chris_> hello
[16:03] <holstein> o/
[19:27] <Winko> Hi there, anyone problems, after the upgrade of the 64 bit 13.10 > 14.04, with starting up nekobee? Regards, Winko
[19:30] <GridCube> !details | Winko
[19:33] <Winko> Nekobee won't startup as a single instrument, but it works under Qtractor (macbook 5.1/EFI(refind)/64 bits/upgrade 13.10>14.04).


[15:00] <ItzSwirlz> o/
[15:02] <rafaeldtinoco> o/
[15:02] <rafaeldtinoco> do we have quorum ?
[15:03] <sil2100> o/
[15:03] <ItzSwirlz> o/
[15:04] <rafaeldtinoco> looks like we're short on quorum, nobody with action items is here (but me, and I will carry my things over)
[15:05] <rafaeldtinoco> let me know if you want me to open the meeting or we can just postpone this one
[15:05] <sil2100> I think we should be good on postponing?
[15:05] <rafaeldtinoco> sil2100:yep, +1
[15:05] <rafaeldtinoco> ill update agenda
[15:06] <Laney> rafaeldtinoco: any update on the packageset stuff?
[15:06] <Laney> I'm being reminded of it now as I'm having to sponsor stuff that I "shouldn't" according to those new rules ;-)
[15:08] <rafaeldtinoco> Laney:hum.. im running pkgset changes 1 every week
[15:08] <rafaeldtinoco> Laney:is that what you're referring to ?
[15:08] <rafaeldtinoco> or the group with new rights for oem
[15:09] <Laney> nein
[15:09] <Laney> we talked about modifying the algorithm wrt exceptions
[15:09] <rafaeldtinoco> ah ok, no then..
[15:10] <rafaeldtinoco> I still need to catch up with that, was looking for a 2/3 "softer" days
[15:10] <Laney> okey
[15:10] <rafaeldtinoco> Laney:sorry ? =\
[15:13] <Laney> no worries!