[11:30] <jonnylamb> There are two branches for each maemo module on Launchpad, "ubuntu" and "trunk". Am I right in thinking that trunk is automatically merged with each svn commit on the maemo.org end; and the ubuntu branch is simply a branch of trunk, for the purpose of cleaning up the package for Ubuntu?
[12:27] <Mithrandir> jonnylamb: that is correct.
[12:27] <Mithrandir> the trunk is an import of svn to bzr
[12:45] <jonnylamb> Mithrandir: Thanks.
[12:45] <jonnylamb> Why do you do that though?
[12:46] <jonnylamb> Why are you taking each commit?
[12:46] <jonnylamb> Why not just use the releases?
[12:49] <Mithrandir> because preserving history is important
[12:49] <Mithrandir> and working without the support from a revision control system is horrible
[12:51] <jonnylamb> Oh I think I understand now. You're merging in changes only when a release comes out? Only this way, the bzr history is lovely and full of changes made to maemo svn?
[12:52] <jonnylamb> I was "worried" you were packaging and _releasing_ stuff that was trunk material, i.e. not necesserily stable.
[01:04] <mdz> jonnylamb: we are packaging trunk in many cases, yes
[01:04] <mdz> jonnylamb: but we are not releasing until October
[01:06] <jonnylamb> Is the reason of using this vcs-imports method to keep history even on the stage.maemo.org side? As in keeping track of all their commits?
[01:09] <mdz> jonnylamb: it's so that we can maintain our own distributed branches
[01:10] <mdz> it's like being able to work inside svn, but without requiring accounts etc.
[01:10] <mdz> so we have all the benefits of revision control but the flexibility of decentralization
[01:36] <lool> Hi there
[01:36] <lool> I'm sorry I couldn't attend the meeting, I would have loved offering my help on a couple of things such as Gtk bits
[01:37] <lool> I discussed some implementation details with seb128 and other folks
[01:41] <lool> Hmm I see agoliveira already found about g_key_file_free() instead of g_free()
[01:44] <Mithrandir> yeah, he did
[01:44] <Mithrandir> according to a mail he sent me yesterday, the theme builder now works
[01:56] <Mithrandir> oh, docs, why do you hate me so?
[01:57] <tko_> gtk-doc problems?
[01:58] <Mithrandir> make run in the top level directory doesn't run make docs
[01:58] <Mithrandir> which makes dh_install quite unhappy.
[01:58] <tko_> I thought I hacked my way around that
[01:59] <tko_> hmm, no, I did the hack in hildon-1
[01:59] <lool> Mithrandir: I simply passed --disable-gtk-doc here  O:-)
[01:59] <Mithrandir> lool: I made debian/rules call make doc too
[01:59] <Mithrandir> hm, why is the --disable-gtk-doc there?  That might explain it
[02:00] <tko_> because we don't have recent enough gtk-doc
[02:00] <Mithrandir> but we do
[02:00] <lool> --disable-gtk-doc instructs to not build doc at make time, but disted tarball should use --enable-gtk-doc and ship the pre-built docs
[02:00] <lool> You don't want to build the doc on each build, except if you're running autogen
[02:01] <Mithrandir> hmm
[02:01] <Mithrandir> shouldn't just the normal make rules govern that?
[02:01] <lool> Not sure what you mean
[02:02] <lool> Hmm where's the gtkdocize call in autogen?
[02:02] <Mithrandir> why is this a configure flag rather than just having a rule in the Makefile that rebuilds the docs if the sources have changed?
[02:02] <Mithrandir> no gtkdocize call there
[02:02] <lool> Mithrandir: There's such a rule _if_ you pass --enable-gtk-doc I think
[02:02] <Mithrandir> oh, ok.
[02:03] <Mithrandir> then I think passing --enable-gtk-doc should be fine.
[02:03] <lool> Well, only if you autogen
[02:03] <Mithrandir> -fm does that automatically at first.
[02:03] <lool> If you don't want to autogen, you should prebuild the docs oo
[02:03] <Mithrandir> why shouldn't they be built as part of the package?
[02:04] <lool> The gtk-doc rules are using autotools convention which suggest that they should be make disted
[02:04] <lool> For example, dist-hook, maintainer-clean-local, etc.
[02:05] <Mithrandir> we can change it later if we think that makes sense; I'll just pass --enable-gtk-doc for now.
[02:05] <lool> It's a choice the gtk-doc developers made that their gtk-doc.make will help you _produce tarballs_ with doc, but not produce tarballs which build doc
[02:05] <lool> Mithrandir: Ok, but be aware that it wont possibly clean properly
[02:06] <Mithrandir> true, make distclean doesn't clean it.
[02:07] <lool> Exactly
[02:07] <Mithrandir> but the package builds that way, which I think is more important.
[02:08] <lool> I would personally call autogen.sh in this case
[02:08] <lool> But right, the important thing is to get forward :)
[02:08] <Mithrandir> I'm tempted to say "this wouldn't be a problem if we had proper upstream releases", something I'm confident will happen sometime soonish.
[02:08] <lool> I concur fully
[02:09] <lool> Exactly like striping the debian/ out is currently a pain because I'm using non-native mode; this will disappear with upstream tarball releases
[02:09] <lool> I wonder why it build for me here though
[02:10] <lool> Haha, I passed --enabled-gtk-doc :)
[02:10] <lool> Do like I say, not like I do
[02:11] <Mithrandir> haha. :-)
[02:12] <lool> Ah I recall why now; this debian/rules did not have a special autogen.sh section
[02:12] <Mithrandir> config.status: if [ ! -x configure ] ; then ./autogen.sh; fi
[02:12] <Mithrandir> with a newline after the first :
[02:13] <lool> Yeah, but no "configure" rule lke some others
[02:13] <lool> with flags passed to autogen.sh
[02:13] <Mithrandir> ah, point.
[03:00] <Mithrandir> tko_: is there any reason not to let hildon-fm depend on hildon-fm-l10n with a specific version number rather than using the mr / mr0 /mrX approach?
[03:15] <tko_> I don't recall the details why the packaging was done the way it was. presumably because depending on virtual package doesn't install any concrete one
[03:16] <Mithrandir> which is why you'd have something like Depends: hildon-fm-l10n-english | hildon-fm-l10n and have all the different hildon-fm-l10n-XX packages provide the former.
[03:16] <Mithrandir> the former = hildon-fm-l10n in this case
[03:23] <Mithrandir> dpkg-deb: Bygger pakken libhildondesktop0 i ../libhildondesktop0_0.0.14-2ubuntu2_i386.deb.
[03:23] <Mithrandir> \o/
[03:25] <mdz> Mithrandir: !
[03:26] <Mithrandir> no idea if it installs yet, but we're getting there.
[03:55] <bintut> what filesystem do you use for the upcoming ubuntu-mobile?
[06:23] <tko> btw, I just realized I've been doing tarball releases of sapwood since the beginning..
[06:23] <tko> it is causing me some extra pain :)
[06:34] <lool> tko: Do you know how the move to gnome.org is going?
[06:34] <tko> http://live.gnome.org/Hildon/MigrationToGnome
[06:35] <lool> Great; looks good
[06:35] <tko> basically the order was 1) accounts, 2) svn, 3) bugzilla
[06:36] <lool> I see
[06:36] <tko> once we have svn enabled on gnome side, we still need to get svn dump from our side and also get a hole in the firewall
[06:37] <lool> I wonder how the vcs-import switch will happen; promises some fun :)
[06:37] <lool> tko: Ah for SSH I suppose
[06:37] <tko> oh right, and then we're waiting for jdub to set up hildon mailing list
[06:38] <tko> yep
[06:38] <tko> our firewall is a bit paranoid
[06:39] <inz> slight understatement ;)
[07:09] <jonnylamb> May I ask /why/ you're moving to gnome.org?
[07:50] <tko> we want to make hildon less strongly tied with nokia and run it as a true upstream project
[08:01] <tko> btw, who's coming to CA next week? me and moises could use a ride
[09:16] <lool> tko: Is there an IRC chan where mdk is around?
[09:16] <lool> tko: Or perhaps you can fix the weird "AC_ARG_ENABLE " alone on line 117 of libhildon/hildon-1?
[09:19] <tko> lool: I suppose he'd be here or #maemo when he's online, but I'll try fixing it (don't have a checkout here)
[09:19] <lool> tko: Ok, I've fired bugzilla now; want a bug?
[09:19] <tko> lool: give me a minute to finish the checkout..
[09:19] <lool> tko: Right, I see him in the backlog now; thanks
[09:20] <lool> Is there a way to tell the SVN rev from the bzr rev?
[09:20] <lool> This is how bzr log looks: http://paste.debian.net/29986
[09:21] <tko> lool: that would be r11820 but I don't know how you'd get it
[09:21] <tko> bzr-svn maybe?
[09:23] <lool> bzr-svn hung for me when I tried importing haf's SVN; after taking some 1.5 GB RAM + swap, it encountered some incomprehensible error
[09:23] <lool> So I've given up there :-/
[09:23] <lool> tko: I wish it would be visible in the log just like in git-svn
[09:23] <tko> git-svn had no problems with gtk :)
[09:23] <lool> hehe
[09:24] <tko> (our gtk.. I didn't feel like waiting to mirror the whole upstream)
[09:24] <lool> bzr-svn is supposedly transparently integrated, and I have it installed and didn't see anything in the log
[09:24] <lool> (You're supposed to use bzr "normally", for example "bzr branch svn://...")
[09:26] <lool> bzr viz is quite nice
[09:30] <jonnylamb> Certainly is!
[09:30] <jonnylamb> Is there anything like this for git?! :D
[09:31] <lool> gitk I guess
[09:33] <lool> It's cute too; too bad it's not in Gtk
[09:34] <inz> How can they name it gitk, if it's not Gtk?-)
[09:34] <lool> It's in tk :)
[09:35] <tko> lool: committed
[09:35] <jonnylamb> gitk looks damn ugly, but it does the job.
[09:35] <inz> lool, uh, then I guess it's acceptible ;)
[09:35] <lool> tko: thanks!
[09:36] <lool> tko: I'll file a bug directly next time; it's WE after all :)  I was mostly curious as to whether you were using a private IRC channel, but seems not
[09:37] <tko> lool: if we were it would be somewhere in the intranet :)
[09:37] <tko> remember, we're only moving towards being an upstream project :)
[09:44] <Knowledge_> Ubutu Mobile + n800 = dream machine...
[09:44] <Knowledge_> if the mobile version is anything like the desktop version...
[09:50] <tko> Knowledge_: what is lacking in the software shipped with n800 ?
[09:51] <Knowledge_> tko: honestly nothing, I love it...I just like modding stuff....
[09:51] <tko> :)
[09:51] <Knowledge_> I'm not one of those "ohhh the 770/n800 are so terrible because I can't run apache on it"....yadda yadda...I bought it because of what it was advertised to do...and it does that flawlessly....
[09:51] <tko> there's always hex editor.. :-P
[09:52] <tko> I thought someone already ported apache.. or some other web server atleast (forgot the name)
[09:54] <Knowledge_> oh...well you get what I mean...there's people on the iTt forums that whine and whine cause the device doesn't suck their....well, I'm pretty sure you know what I'm getting at
[09:55] <tko> yeah, I know
[09:55] <Knowledge_> I love the device...
[09:55] <Knowledge_> barely use it and it's still the best $400 I've ever spent
[10:09] <lool> tko: lighthttpd perhaps
[10:10] <lool> or lighttpd either
[10:10] <tko> lool: no, it was some other indian IIRC
[10:22] <tko> cherokee
[10:30] <lool> Ah right
[10:30] <lool> I was thinking about a project hosted in India
[12:00] <jonnylamb> What does "mce" stand for?
[12:01] <jonnylamb> Forgive me, "Mode Control Entity". However, I'm a little unsure on what it is/it does ?
[12:01] <jonnylamb> It seems to be mentioned, but not documented here: https://lists.ubuntu.com/archives/ubuntu-mobile/2007-May/000098.html