[00:45] <smp4488> what are some good books or sites to get into gtk+ and c++
[02:00] <lool> GrueMaster: Everything points at 2.6.27; my understanding is that the choice of 2.6.27 isn't challenged anymore for the main distro, and the only thing which could keep linux-lpia for Ubuntu MID to 2.6.26 would be Intel drivers only available for 2.6.26 and not working with .27
[02:01] <GrueMaster> I'm working on the video drivers now, but I need a stable build environment.  Moblin doesn't provide that yet.
[02:01] <lool> GrueMaster: I hope the psb drivers will work with the in kernel drm in 2.6.26 or 27 though, or add a new drm
[02:01] <lool> GrueMaster: Intrepid is decent in my experience, but probably no fglrx
[02:02] <GrueMaster> It currently is the same psb driver we know and love.  My understanding is there is going to be a rewrite, but that is after intrepid.
[02:02] <GrueMaster> don't care about fglrx.
[02:02] <lool> I heard from various places that powervr drivers would land near november or end 2008
[02:03] <lool> I think around beagleboard for one
[02:03] <GrueMaster> yes, that's my understanding too.  They want to convert the drivers from the TTM model to the new GEMS model.  
[02:03] <lool> GrueMaster: The drm is going to be a serious issue: we don't have the ppa anymore, and we can't up to a git snapshot of libdrm just for psb  :-/
[02:03] <GrueMaster> Same as the GMA9xx desktop video.
[02:04] <GrueMaster> hmmm.
[02:05] <GrueMaster> I'll have to look at the libdrm code and see what is new.  If the new stuff can be isolated to psb, but the library still remain compatible, will that work?
[02:06] <lool> GrueMaster:     libdrm | 2.3.0-4ubuntu1 |         hardy | source
[02:06] <lool>     libdrm | 2.3.1-0build1 |      intrepid | source
[02:07] <lool> GrueMaster: I think psb in kernel and the libdrm we used in hardy builds (in the ppa) was from a quite different upstream tree
[02:07] <lool> Anyway, it's pretty clear that we would love if the drivers work with intrepid's libdrm and will see what to do if it doesn't :)
[02:08] <GrueMaster> the kernel drm is definitely different, but I think it it was backwards compatible (until 2.6.27, that is).
[02:08] <GrueMaster> I can run tests once I get the kernel modules built.  For now, I need a kernel to build and test with.
[02:09] <lool> GrueMaster: You have the details for the ubuntu tree?
[02:09] <GrueMaster> I'll look you up again tomorrow.  Wife is telling me it's time to go home.  I don't have the details for Intrepid.
[02:10] <lool> GrueMaster: If you're choosing what to base on, you can grab our 2.6.26 tree which is called ubuntu/ubuntu-intrepid on kernel.ubuntu.com
[02:10] <lool> Err .27
[02:10] <GrueMaster> I've tried updating a hardy build environment, but the kernel is still missing.
[02:10] <lool> And it's derived from upstream .27
[02:10] <GrueMaster> ok
[02:10] <lool> It's also time to stop work here
[02:10] <lool> 'night/evening
[02:10] <GrueMaster> See you.
[02:53] <smp4488> what are some good books or sites to get into gtk+ and c++
[02:59] <smp4488> cam i use glade while configuring the gui?
[03:17] <persia>  smp4488: For the first question, #gtk+ is probably a better channel.  The answer to the second question is in the /topic for that channel.
[03:21] <smp4488> look im new to this and im sorry if i am asking too many stupid questions
[03:21] <smp4488> i think a may have started with something with a steep learning curve
[03:21] <smp4488> but im trying
[03:25] <smp4488> not to be smart or anything but i dont see anything about glade in the topic, faq, web site
[03:25] <persia> smp4488: There are no stupid questions, just some for which the answer lies elsewhere :)
[03:26] <persia> I thought the /topic for #gtk+ said something like "Do use glade, but don't use glade to generate source code".  Are you sure?
[03:27] <smp4488> ooooh
[03:27] <smp4488> i thought you meant this channel
[03:27] <smp4488> my fault
[03:28] <smp4488> im trying to get my head around this gtk+ programming
[03:29] <persia> smp4488: Right.  While this channel may be able to help with some questions specifically about gtk+ programming for something Ubuntu Mobile specific, most of your general questions are probably better answered there.
[03:30] <persia> I don't mean to put you off, it's just that the GTK+ folk know how to program gtk+ better than the Ubuntu Mobile folk.
[03:31] <smp4488> gotcha
[03:32] <smp4488> i want to help out but it seems like im getting in too deep and not doing much for anyone
[03:32] <smp4488> even though i do enjoy it
[03:32] <persia> smp4488: IF you're enjoying it, it's worth doing.  At some point you'll get something together you want to share with everyone else :)
[03:33] <smp4488> lol we will see about that
[03:35] <smp4488> so is intrepid mobile based on the the new ubuntu beta?
[03:39] <persia> Well, not precisely "based on", but more "part of", and it's an Alpha.  Anyway, I'll explain more when you come back.
[10:51] <lool> amitk: I checked a patch Colin King wrote for hardy's lum (unionfs) as I was told the fixes to unionfs might be relevant for aufs, but saw not much similarity
[10:54] <amitk> lool: I have confirmed colin's comment about it happening on the rename syscall. But I also saw it atleast once in the open syscall
[10:55] <lool> amitk: So you reproduce with a rename alone
[10:57] <amitk> lool: scratch the previous comment regarding open, I think that is because I Ctrl-C'ed out of strace. So it is waiting on /var/lib/apt/lists/lock I think
[10:58] <lool> amitk: Do you have a test case to reproduce the issue?  Could we poke aufs' upstream with it?
[10:59] <amitk> lool: testcase is what you guys have. kvm mid.img; apt-get update. Upstream will require more info regarding the fs layout and the union mounts though.
[11:00] <lool> amitk: I thought of an upstreamable test case such as test.c doing stat64(), rename() etc.
[11:01] <lool> amitk: Are you reproducing on your desktop?
[11:01] <amitk> lool: kvm
[11:01] <lool> Are you reproducing with 2.6.27?  :-)
[11:01] <lool> ogra gets the issue on his 2.6.27 system
[11:02] <lool> But as you say, the union mount args are relevant as the desktop live CD works
[11:02] <ogra> apparently
[11:02] <amitk> lool: yes, latest intrepid update on my desktop
[11:03] <ogra> and you indeed changed my script to use aufs instead of unionfs for te merged mount 
[11:03] <ogra> *the
[11:03] <amitk> hmm http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg560731.html
[11:04] <ogra> wow
[11:04] <ogra> you are awesome ... i surely googled for 1h yesterday and didnt find anything useful
[11:06] <amitk> well the resolution was not that great. But I have a feeling upstream knowns about similar problems from before.
[11:07] <ogra> he talks about an older version of aufs, is ours up to date ?
[11:08] <ogra> loic said yesterday it wasnt changed at least beween hardy and intrepid
[11:09] <amitk> i am just checking that
[11:09] <lool> I can't download the patch from http://article.gmane.org/gmane.linux.file-systems.aufs.user/1291
[11:10] <lool> http://article.gmane.org/gmane.linux.file-systems.aufs.user/1270 exactly the same bug indeed
[11:12] <amitk> does anybody remember cvs commadline? :-/ I need to get pserver:anonymous@aufs.cvs.sourceforge.net:/cvsroot/aufs
[11:12] <ogra> yeah
[11:13] <ogra> (no for cvs though, i'm a copy paster for that)
[11:13] <ogra> *sigh* ... 
[11:14]  * ogra accidentially installed libgstreamer-dev with the patch ... tons of -dev libs getting installed
[11:14] <lool> amitk: cvs login is probably optional
[11:15] <lool> amitk: Just cvs co -d:pserver:anonymous@aufs.cvs.sourceforge.net:/cvsroot/aufs co aufs
[11:15] <lool> amitk: Sorry, drop the first "co"
[11:15] <lool> cvs -d :pserver:anonymous@aufs.cvs.sourceforge.net:/cvsroot/aufs co aufs
[11:16]  * amitk thinks back to when he last used cvs or svn for that matter
[11:17] <lool>  64 files changed, 8948 insertions(+), 3369 deletions(-)
[11:17] <lool> (between intrepid's aufs and upstream's)
[11:19] <amitk> there are also two versions of aufs in the cvs co
[11:19] <amitk> i guess aufs25 is the devel version
[11:20] <lool> amitk: Not as bad, but almost:  64 files changed, 7344 insertions(+), 2444 deletions(-)
[11:22] <amitk> tim will be coming online shortly. Let me talk to him about updating. The file we care about most is i_op_ren.c
[11:23] <lool> amitk: Are you trying out with tip?
[11:26] <amitk> lool: yes
[11:40] <amitk> lool: ogra: this looks to have been fixed upstream from the changelog.
[11:40] <amitk> 20080728
[11:40] <amitk> - bugfix: deadlock in rename(2), au_cp_dirs(), reported by Cyril Brulebois, Klaus Knopper and Martin Tscholak.
[11:42]  * lool forgot that it's cvs annotate, not cvs blame
[11:42] <ogra> amitk, yay
[11:43] <amitk> lool: atleast you remember the cvs command :)
[11:51] <persia> amitk: It's something we'll be able to pull for the next intrepid update?  I suspect it's that which is causing most of my failures, as just about everything I'm trying to do involves rename() at some point.
[11:53] <lool> StevenK: Actual first error I get is:
[11:53] <lool> cc1: warnings being treated as errors
[11:53] <lool> mobile-basic-home-plugin.c: In function ‘launch_app’:
[11:53] <lool> mobile-basic-home-plugin.c:471: error: ignoring return value of ‘write’, declared with attribute warn_unused_result
[11:54] <amitk> persia: I don't see a reason that we shouldn't update to the latest CVS (barring livecds breaking). Since I didn't do the original aufs inclusion into ubuntu, I'll just ask if it is ok and then push a patch later today.
[11:56] <lool> StevenK: The next one is /usr/include/libhildonwm/libhildonwm/hd-wm.h:373: error: inline function ‘hd_wm_reset_last_active_window’ declared but never defined
[11:58] <persia> amitk: Excellent!  Please let me know if you end up pushing it, and I'll construct a new image locally.
[11:59] <persia> lool: That matches the previous results.  After that, lots more declared and not defined functions, right?
[11:59] <StevenK> lool: I have a patch for mobile-basic-home-plugin.c:471.
[11:59] <StevenK> lool: inline function is the one I can't solve
[11:59] <lool> StevenK: That's a libhildonwm issue; it should list these functions as extern inline in the public headers
[11:59] <lool> I solved it with -Wno-error
[11:59] <lool> *cough*
[12:00] <lool> But we should report it upstream
[12:00] <lool> StevenK: Just append -Wno-error in the debian/rules cflags
[12:00] <lool> Well there are none which is against policy since you should build with -O0 or -O2 dependning on debug flag
[12:01] <persia> lool: It lists them as extern inline in /usr/share/libhildonwm/libhildonwm/hd-wm.h  Is that not the right place?
[12:01] <lool> persia: There's a comment explaining why they do so
[12:01] <lool> Basically these are getter/setter to access properties; it's just like a pointer deref, but they wrapped them in functions because of the type checking it provides
[12:02] <lool> (mind you if pygobject had been doing the same I wouldn't have chased the x86-64 crasher for a full day)
[12:02] <lool> It's fine when you're within libhildonwm and the function is actually reachable (inline-able)
[12:03] <lool> But no app can use these functions with such headers definitions, unless it has access to a PIC version of the .a file and doesn't mind linking statically
[12:03] <lool> What upstream should be doing is having some kind of "ifdef WITHIN_HILDONWM_BUILD" flag which sets these functions as extern inline in this case, but regular functions otherwise
[12:04] <lool> Or they should be dropping these functions from the API completely
[12:04] <Celtiore> hi
[12:04] <lool> But anyway, these API discussions are not very interesting for mbf which doesn't even use these
[12:04] <Celtiore> i have question
[12:04] <Celtiore> i try to use moblin image creator
[12:04] <lool> You don't really want to build something like mbf with -Werror
[12:04] <lool> (imo)
[12:04] <lool> The xulrunner 1.9 macros wont even allow this
[12:05] <Celtiore> i do : load project : open file mic.tar.bz2, but whe finish i can't see the project and the target ?
[12:06] <lool> StevenK: Does that unstuck you?
[12:07] <lool> StevenK: I can provide the write() "fix" if you like
[12:07] <lool> (which is absolutely hideous since there's no mean to bubble up the error anyway)
[12:08] <StevenK> lool: I have the write fix as a patch
[12:08] <StevenK> lool: $(MAKE) CLFAGS += -Wno-error
[12:08] <StevenK> ?
[12:08] <lool> StevenK: http://paste.ubuntu.com/43303/
[12:09] <lool> StevenK: I would set the CFLAGS in debian/rules
[12:09] <lool> It should pick them up it seems
[12:10] <lool> mobile-basic-flash-0.44/configure.ac:CFLAGS="$CFLAGS -Wall -ansi -Wmissing-prototypes -Wmissing-declarations -Werror -std=c99 -rdynamic"
[12:11] <persia> Wouldn't it be better to patch s/-Werror/-Wno-error/ rather than declaring both?
[12:12] <lool> StevenK: http://paste.ubuntu.com/43308/
[12:12] <lool> StevenK: configure.ac overrides your CFLAGS though; it should really be CFLAGS="blah $CFLAGS" to start with
[12:13] <lool> persia: I think upstream should only use -Werror for their pre-release QA or for dev trees, not in released tarballs
[12:13] <lool> persia: That said, yes it would work to patch the -Werror, but then you end up patching configure.ac and running autoconf while it's way easier to add -Wno-error at the end of the CFLAGS
[12:14] <persia> lool: I agree, which is part of why I suggest a patch: it's something that legitimately belongs upstream, rather than being a packaging artifact.
[12:14] <lool> You spend your time the way you like, but I wouldn't want to maintain patches I'll have to refresh on every new upstream forever :)
[12:14] <lool> StevenK: Anything else I can do for you?
[12:14] <persia> But we already run ./autogen in the build, so I don't see the extra cost, but it's not important enough to debate :)
[12:15] <lool> I'm not sure we always do
[12:15] <lool> If you build on your host once, then the autogen results will be kept in the diff; but right we run autofoo anyway
[12:15] <persia> lool: But we call ./autogen.sh in the configure-stamp rule ...
[12:15] <lool> Which is IMO a bad idea but heck
[12:16] <persia> Yeah, it's debatable, but as long as we're doing it anyway ... :)
[12:16] <lool> persia: Hmm good point, the autogen run is correctly unconditionnal here
[12:16] <lool> For instance there's no autoconf bdep
[12:16] <lool> Most bdeps aren't versionned
[12:17] <persia> RIght.  In the conditional case, it might make more sense to hack it in debian/rules.
[12:17] <lool> upstream doesn't provide any m4 files, so you need to bdep on all packages providing m4 macros in configure.ac
[12:17] <lool> etc. etc.
[12:17] <lool> autotools during build with such an upstream tarball is a bad idea, but then we don't even have autotoolized released tarballs
[12:19] <lool> For instance there isn't any libgconf2-dev bdep but the build relies on the AM_GCONF_SOURCE_2 macro in /usr/share/aclocal/gconf-2.m4
[12:19] <lool> I wish Keybuk would read this perfect example of the theory I was explaining some days ago
[12:27] <persia> lool: I'm actually in the camp of people who believe we should run autofoo at build time.  More than once a simple give-back has solved issues that otherwise would have required source changes.
[12:27] <persia> That said, it does rely on a well-behaved upstream, or it's just shooting oneself in the foot.
[12:28] <lool> I'm in the camp who thinks it's too complex for people to get right
[12:36] <persia> lool: And I suspect we can both find lots of examples.  In the meantime, I suspect we'd do best to review each package separately, depending on how well upstream did their work, we can do it my way or your way.
[12:51] <lool> Meeting in #ubuntu-meeting in 9 mns
[12:56] <Celtiore> hi persia i have one question please
[12:58] <Celtiore> for aigo mid p8860 we need to modify the install.cfg and install.sh , if we want to install correctly UME
[13:01] <lool> Meeting in #ubuntu-meeting
[13:19] <lool> amitk: I git-cvspimpported http://people.ubuntu.com/~lool/git/aufs.git/
[13:19] <lool> amitk: 4350c42ec737e187a710e38a4b20dcbe840fe4c4 is more recent than the claimed date of fix, but interesting
[13:22] <amitk> lool: yeah. it looks like we are going to get the latest aufs into intrepid
[13:23] <lool> the 25 one?
[13:23] <lool> amitk: It would be nice to import aufs with history into the ubuntu tree if you ask me  :-)
[13:24] <davidm> amitk, can you join us in #ubuntu-meeting?  I'd like to get the status of the  aufs bug into the record
[13:24] <amitk> lool: yes the 25 one
[13:25] <amitk> that is the one that is supported for kernels 2.6.25+
[16:32] <Celtiore> where can i find the last version of idctouch drivers for aigomid p8860 ?
[16:34] <persia> Celtiore: That's a tricky question.  I think you're the only aigomid user who's usually here.  Google might help.
[16:35] <Celtiore> thanks you
[16:35] <persia> Also, you were asking earlier about MIC: if you need to modify install.cfg and install.sh, you can do that once you've created your target, but before you build your image.
[16:35] <persia> (I think)
[16:35] <persia> If that doesn't work, you'll need to grab the MIC source and hack it, or loopmount the result image, and modify it.
[16:42] <Celtiore> about desktop background, with last img , we can easily change it :)
[16:42] <persia> Celtiore: I've not tried on the intrepid dailies, but it's easy on the 8.04.1 image.
[16:43] <Celtiore> yes i try the 8.04.1
[16:43] <Celtiore> but no network, no touchscreen :(
[16:45] <persia> Oh.  Hrm.  That's incredibly annoying.
[16:45] <persia> ian_brasil suggested you could import background images to 7.10, but I don't know how.
[16:46] <persia> Let me check the desktop background tool in the dailes quickly: it might be OK, but I know there are a couple bugs that cause the dailes to crash, so they certainly aren't recommended for real use.
[16:48] <Celtiore> ok
[16:48] <Celtiore> but i have a lot of pictures with the desktop manager background
[17:14] <persia> Celtiore: Actually, there seems to be a bug in the dailes that prevents the changing of the desktop background.
[17:14] <persia> I've no good advice for you today.  Sorry :)
[17:15] <Celtiore> np persia 
[19:21] <lool> ogra: Hey!  Don't know how busy you are: did you send out a list of packages relevant for the mobile seed only?  I still need to do this for mid, and wondered how you compiled yours
[23:30] <smp4488> anyone around?