[00:45] what are some good books or sites to get into gtk+ and c++ [02:00] 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] I'm working on the video drivers now, but I need a stable build environment. Moblin doesn't provide that yet. [02:01] 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] GrueMaster: Intrepid is decent in my experience, but probably no fglrx [02:02] 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] don't care about fglrx. [02:02] I heard from various places that powervr drivers would land near november or end 2008 [02:03] I think around beagleboard for one [02:03] yes, that's my understanding too. They want to convert the drivers from the TTM model to the new GEMS model. [02:03] 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] Same as the GMA9xx desktop video. [02:04] hmmm. [02:05] 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] GrueMaster: libdrm | 2.3.0-4ubuntu1 | hardy | source [02:06] libdrm | 2.3.1-0build1 | intrepid | source [02:07] 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] 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] the kernel drm is definitely different, but I think it it was backwards compatible (until 2.6.27, that is). [02:08] I can run tests once I get the kernel modules built. For now, I need a kernel to build and test with. [02:09] GrueMaster: You have the details for the ubuntu tree? [02:09] 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] 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] Err .27 [02:10] I've tried updating a hardy build environment, but the kernel is still missing. [02:10] And it's derived from upstream .27 [02:10] ok [02:10] It's also time to stop work here [02:10] 'night/evening [02:10] See you. [02:53] what are some good books or sites to get into gtk+ and c++ [02:59] cam i use glade while configuring the gui? [03:17] 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] look im new to this and im sorry if i am asking too many stupid questions [03:21] i think a may have started with something with a steep learning curve [03:21] but im trying [03:25] not to be smart or anything but i dont see anything about glade in the topic, faq, web site [03:25] smp4488: There are no stupid questions, just some for which the answer lies elsewhere :) [03:26] 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] ooooh [03:27] i thought you meant this channel [03:27] my fault [03:28] im trying to get my head around this gtk+ programming [03:29] 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] 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] gotcha [03:32] i want to help out but it seems like im getting in too deep and not doing much for anyone [03:32] even though i do enjoy it [03:32] 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] lol we will see about that [03:35] so is intrepid mobile based on the the new ubuntu beta? [03:39] Well, not precisely "based on", but more "part of", and it's an Alpha. Anyway, I'll explain more when you come back. === alek_desk_ is now known as alek_desk === alek_desk_ is now known as alek_desk [10:51] 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] 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] amitk: So you reproduce with a rename alone [10:57] 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] amitk: Do you have a test case to reproduce the issue? Could we poke aufs' upstream with it? [10:59] 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] amitk: I thought of an upstreamable test case such as test.c doing stat64(), rename() etc. [11:01] amitk: Are you reproducing on your desktop? [11:01] lool: kvm [11:01] Are you reproducing with 2.6.27? :-) [11:01] ogra gets the issue on his 2.6.27 system [11:02] But as you say, the union mount args are relevant as the desktop live CD works [11:02] apparently [11:02] lool: yes, latest intrepid update on my desktop [11:03] and you indeed changed my script to use aufs instead of unionfs for te merged mount [11:03] *the [11:03] hmm http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg560731.html [11:04] wow [11:04] you are awesome ... i surely googled for 1h yesterday and didnt find anything useful [11:06] well the resolution was not that great. But I have a feeling upstream knowns about similar problems from before. [11:07] he talks about an older version of aufs, is ours up to date ? [11:08] loic said yesterday it wasnt changed at least beween hardy and intrepid [11:09] i am just checking that [11:09] I can't download the patch from http://article.gmane.org/gmane.linux.file-systems.aufs.user/1291 [11:10] http://article.gmane.org/gmane.linux.file-systems.aufs.user/1270 exactly the same bug indeed [11:12] does anybody remember cvs commadline? :-/ I need to get pserver:anonymous@aufs.cvs.sourceforge.net:/cvsroot/aufs [11:12] yeah [11:13] (no for cvs though, i'm a copy paster for that) [11:13] *sigh* ... [11:14] * ogra accidentially installed libgstreamer-dev with the patch ... tons of -dev libs getting installed [11:14] amitk: cvs login is probably optional [11:15] amitk: Just cvs co -d:pserver:anonymous@aufs.cvs.sourceforge.net:/cvsroot/aufs co aufs [11:15] amitk: Sorry, drop the first "co" [11:15] 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] 64 files changed, 8948 insertions(+), 3369 deletions(-) [11:17] (between intrepid's aufs and upstream's) [11:19] there are also two versions of aufs in the cvs co [11:19] i guess aufs25 is the devel version [11:20] amitk: Not as bad, but almost: 64 files changed, 7344 insertions(+), 2444 deletions(-) [11:22] 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] amitk: Are you trying out with tip? [11:26] lool: yes [11:40] lool: ogra: this looks to have been fixed upstream from the changelog. [11:40] 20080728 [11:40] - 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] amitk, yay [11:43] lool: atleast you remember the cvs command :) [11:51] 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] StevenK: Actual first error I get is: [11:53] cc1: warnings being treated as errors [11:53] mobile-basic-home-plugin.c: In function ‘launch_app’: [11:53] mobile-basic-home-plugin.c:471: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [11:54] 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] 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] amitk: Excellent! Please let me know if you end up pushing it, and I'll construct a new image locally. [11:59] lool: That matches the previous results. After that, lots more declared and not defined functions, right? [11:59] lool: I have a patch for mobile-basic-home-plugin.c:471. [11:59] lool: inline function is the one I can't solve [11:59] StevenK: That's a libhildonwm issue; it should list these functions as extern inline in the public headers [11:59] I solved it with -Wno-error [11:59] *cough* [12:00] But we should report it upstream [12:00] StevenK: Just append -Wno-error in the debian/rules cflags [12:00] Well there are none which is against policy since you should build with -O0 or -O2 dependning on debug flag [12:01] lool: It lists them as extern inline in /usr/share/libhildonwm/libhildonwm/hd-wm.h Is that not the right place? [12:01] persia: There's a comment explaining why they do so [12:01] 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] (mind you if pygobject had been doing the same I wouldn't have chased the x86-64 crasher for a full day) [12:02] It's fine when you're within libhildonwm and the function is actually reachable (inline-able) [12:03] 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] 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] Or they should be dropping these functions from the API completely [12:04] hi [12:04] But anyway, these API discussions are not very interesting for mbf which doesn't even use these [12:04] i have question [12:04] i try to use moblin image creator [12:04] You don't really want to build something like mbf with -Werror [12:04] (imo) [12:04] The xulrunner 1.9 macros wont even allow this [12:05] i do : load project : open file mic.tar.bz2, but whe finish i can't see the project and the target ? [12:06] StevenK: Does that unstuck you? [12:07] StevenK: I can provide the write() "fix" if you like [12:07] (which is absolutely hideous since there's no mean to bubble up the error anyway) [12:08] lool: I have the write fix as a patch [12:08] lool: $(MAKE) CLFAGS += -Wno-error [12:08] ? [12:08] StevenK: http://paste.ubuntu.com/43303/ [12:09] StevenK: I would set the CFLAGS in debian/rules [12:09] It should pick them up it seems [12:10] mobile-basic-flash-0.44/configure.ac:CFLAGS="$CFLAGS -Wall -ansi -Wmissing-prototypes -Wmissing-declarations -Werror -std=c99 -rdynamic" [12:11] Wouldn't it be better to patch s/-Werror/-Wno-error/ rather than declaring both? [12:12] StevenK: http://paste.ubuntu.com/43308/ [12:12] StevenK: configure.ac overrides your CFLAGS though; it should really be CFLAGS="blah $CFLAGS" to start with [12:13] persia: I think upstream should only use -Werror for their pre-release QA or for dev trees, not in released tarballs [12:13] 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] 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] 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] StevenK: Anything else I can do for you? [12:14] 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] I'm not sure we always do [12:15] 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] lool: But we call ./autogen.sh in the configure-stamp rule ... [12:15] Which is IMO a bad idea but heck [12:16] Yeah, it's debatable, but as long as we're doing it anyway ... :) [12:16] persia: Hmm good point, the autogen run is correctly unconditionnal here [12:16] For instance there's no autoconf bdep [12:16] Most bdeps aren't versionned [12:17] RIght. In the conditional case, it might make more sense to hack it in debian/rules. [12:17] upstream doesn't provide any m4 files, so you need to bdep on all packages providing m4 macros in configure.ac [12:17] etc. etc. [12:17] autotools during build with such an upstream tarball is a bad idea, but then we don't even have autotoolized released tarballs [12:19] 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] I wish Keybuk would read this perfect example of the theory I was explaining some days ago [12:27] 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] That said, it does rely on a well-behaved upstream, or it's just shooting oneself in the foot. [12:28] I'm in the camp who thinks it's too complex for people to get right [12:36] 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] Meeting in #ubuntu-meeting in 9 mns [12:56] hi persia i have one question please [12:58] for aigo mid p8860 we need to modify the install.cfg and install.sh , if we want to install correctly UME [13:01] Meeting in #ubuntu-meeting [13:19] amitk: I git-cvspimpported http://people.ubuntu.com/~lool/git/aufs.git/ [13:19] amitk: 4350c42ec737e187a710e38a4b20dcbe840fe4c4 is more recent than the claimed date of fix, but interesting [13:22] lool: yeah. it looks like we are going to get the latest aufs into intrepid [13:23] the 25 one? [13:23] amitk: It would be nice to import aufs with history into the ubuntu tree if you ask me :-) [13:24] amitk, can you join us in #ubuntu-meeting? I'd like to get the status of the aufs bug into the record [13:24] lool: yes the 25 one [13:25] that is the one that is supported for kernels 2.6.25+ === asac_ is now known as asac [16:32] where can i find the last version of idctouch drivers for aigomid p8860 ? [16:34] Celtiore: That's a tricky question. I think you're the only aigomid user who's usually here. Google might help. [16:35] thanks you [16:35] 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] (I think) [16:35] 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] about desktop background, with last img , we can easily change it :) [16:42] Celtiore: I've not tried on the intrepid dailies, but it's easy on the 8.04.1 image. [16:43] yes i try the 8.04.1 [16:43] but no network, no touchscreen :( [16:45] Oh. Hrm. That's incredibly annoying. [16:45] ian_brasil suggested you could import background images to 7.10, but I don't know how. [16:46] 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] ok [16:48] but i have a lot of pictures with the desktop manager background [17:14] Celtiore: Actually, there seems to be a bug in the dailes that prevents the changing of the desktop background. [17:14] I've no good advice for you today. Sorry :) [17:15] np persia === suihkulo1ki is now known as suihkulokki [19:21] 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 === robr___ is now known as robr === robr___ is now known as robr === robr____ is now known as robr [23:30] anyone around?