[07:30] <PepperDog> Hi! I'd like to compile a kernel module for Ubuntu Mobile. Can anyone guide me ?
[07:33] <PepperDog> Anyone compiled a kernel module on Ubuntu ?
[07:44] <PepperDog> any kernel developers here?
[10:19] <lool> tko_, mdz: Ack, thanks
[10:20] <lool> tfheen: So, keeping DH 4 suggests to postpone the "cleanup" spec, or at least to filter heavily the cleanups we allow; what do you think?
[11:45] <lool> Mithrandir: ^^^
[11:46] <lool> I suppose we can mail fer who I understand has a clue about whether DH 5 is likely or not
[11:46] <Mithrandir> well debhelper < 4 is deprecated, debhelper 4 is fine.
[11:46] <daniels> if dh5 does happen, it's almost certainly not going to be soon enough anyway.
[11:47] <lool> Mithrandir: We're close to 6 from what I've seen in Debian's DH changelog entries
[11:49] <lool> daniels: Do you have a time estimate in case there would be some motivation for DH5?  Would it be at least weeks, at least months?
[11:49] <lool> Plus, there's the question of Python and dbg packages  :-/
[11:50] <Mithrandir> indeed.
[11:51] <daniels> lool: months.
[11:53] <lool> That's a pity; I don't think it makes sense to restrain to DH 4 stuff for months; what do other think?
[11:53] <Mithrandir> on one hand it would be good to be able to push bits back into maemo, on the other hand it'll be easier for maemo to grab our changes if we make the transitions now
[12:07] <lool> (I would usually stand in favor of spending time to push things upstream, but I find the DH 4 burden a bit too heavy to carry for months)
[12:07] <daniels> no-one enjoys carrying it.  i didn't enjoy changing every single x package to use dh4 instead of 5.
[01:32] <lool> mdz: Was outo also taken verbatim?
[01:33] <mdz> lool: I believe so, yes
[01:33] <mdz> daniels: oh, hello
[01:34] <daniels> mdz: good afternoon
[01:34] <daniels> (i'm here more or less out of curiousity, rather than official capacity, fwiw.)
[01:35] <lool> mdz: Added to the wiki; thanks
[01:36] <tko_> oh, we've been trying to kick outo out.. was it needed somewhere?
[01:37] <lool> Perhaps someone can check the changes at bzr.debian.org/bzr/pkg-maemo/libosso/debian and merge some for Ubuntu?  There are a couple of upstream things, and not too much Debian specificities; I think you just want to revert the "Do not ship *.la files" change
[01:37] <lool> tko_: It's in the deps of libosso-test
[01:38] <mdz> lool: might be a good thing to add to TODO
[01:38] <tko_> I wonder if libosso-test is up to date
[01:38] <lool> Is there a wiki page documenting the deprecated modules in the Ubuntu Wiki?
[01:38] <mdz> lool: deprecated modules?
[01:39] <lool> The upstream deprecated stuff such as hildon-libs, outo...
[01:41] <Mithrandir> lool: we don't like .la files either, so we'd be happy to take that.
[01:41] <Mithrandir> lool: I am planning to make a status page too and merge TODO into that, but I just haven't had time yet.
[01:41] <lool> mdz: Added the review of the bzr branch to TODO
[01:42] <lool> Mithrandir: Good for *.la files; the other *.la files might already refer to it though
[01:44] <lool> tko_: Should I best mail the maintainer to merge upstream changes into maemo (e.g. AM_MAINTAINER_MODE, EXTRA_DIST = debian/*, ...), a maemo list, or ping you?
[01:48] <tko_> lool, bug + mailing the maintainers would be nice. it depends on the individual how quickly he might react. and the bugs make it easier to track from outside
[01:48] <lool> Oh right, bugzilla, that was the thing
[01:49] <lool> Super slow though
[01:51] <daniels> lool: you've just got to make sure it's assigned to a real developer, rather than to maemo qa.
[03:25] <lool> daniels: Thanks; I filed a tracker bug, bug #1516, and a libosso bug with an overview of all changes as bug #1517; I hope the maintainer will suggest a nice way to exchange fixes
[03:27] <daniels> lool: cool, thanks
[03:29] <daniels> lool: ditching .la files is definitely on the agenda
[03:29] <daniels> lool: we've already done it with some parts of the distro
[03:29] <lool> Cool; did you so by stripping dependency_libs?
[03:30] <lool> This is what I use in gtk+2.0 and similar GNOME packages: sed -i "/dependency_libs/ s/'.*'/''/" debian/$(DEV_PKG)/usr/lib/*.la
[03:30] <lool> Hmm that's not anchored; bad me
[03:30] <daniels> er, no, we just did the iterative process of rebuilding from the bottom up, as we did in ubuntu as well.
[03:31] <lool> The idea is that you can strip dependency_libs in all packages at once, it wont break anything (except static linking), and when that's over, you can remove all *.la files
[03:31] <lool> So it's a too step approach, but you don't have to start by the leaf libs
[03:31] <daniels> right
[03:31] <lool> s/too/two
[03:36] <lool> Weird, why does libosso have all the autotools generated files in SVN
[03:37] <lool> 29 modules have a configure out of 43 modules with configure.ac
[03:49] <tko_> we require that dpkg-buildpackage on svn export works, and people couldn't be bothered to run autogen or similar in debian/rules
[03:50] <lool> I see; thanks
[03:54] <Mithrandir> is that a policy decision or would you take patches to run autogen.sh if configure doesn't exist?
[03:54] <tko_> depends on maintainer
[03:55] <tko_> it was their decision originally
[03:58] <Mithrandir> ok
[03:58] <Mithrandir> and you don't have / want to use sticks to make them adjust to a common policy?
[04:02] <daniels> Mithrandir: that process is incredibly heavyweight
[04:02] <Mithrandir> ugh, ok.
[04:02] <Mithrandir> this is part of why you guys want to move onto gnome.org or is that something else?
[04:06] <lool> gnome.org does not have many policies either; mostly some release policies TTBOMK
[04:06] <lool> But at least all GNOME modules do not have autotools files in SVN :)
[04:06] <Mithrandir> they don't have a policy against generated files in revision control?
[04:07] <lool> Mithrandir: I'd say nobody would have had this idea just because no other module does os
[04:07] <lool> so
[04:08] <daniels> i'm not part of the sardine stuff: i have git repos with no generated files at all in them.  so i'm perhaps not the best person to ask. :)
[04:09] <lool> Hehe
[04:32] <Mithrandir> agoliveira_lunch: can you make sure hildon-fm and hildon-fm-l10n are good to upload?  I think they are and would like to get them in today so I was planning on uploading tonight.
[04:33] <Mithrandir> agoliveira_lunch: also, if you know of anything that needs fixing in hildon-desktop, please fix or tell me so we can get it too in.
[04:49] <Knowledge> So does this mean that the n770 and N800 might get ubuntu?
[04:49] <Knowledge> and while I'm at it...should I keep my hx4700?
[04:54] <happycube> right now i think this is targeted for x86-based ultramobiles
[05:42] <agoliveira> Mithrandir: hildon-fm* should be fine as well as hildon-desktop itself. Just a warning that it does not have much pratical use so far without hildon-theme-plankton which I'm working on.
[05:59] <lool> Hmm should osso-af-settings really be Arch: all?
[05:59] <lool> It ships files in /usr/lib/pkg-config
[06:09] <lool> bzr.debian.org/bzr/pkg-maemo/hildon-1/debian and bzr.debian.org/bzr/pkg-maemo/osso-af-settings/debian are up for review too; added to the TODO page
[06:10] <mvo> hi. I'm just adding a lpia architecture to apt, could someone please paste the output of config.guess for a lpia system here?
[06:11] <horaceli> lool, could you please share with me what GTK+ base are you use right now?
[06:11] <bspencer> agoliveira  -- want to introduce you to horaceli 
[06:11] <lool> horaceli: Right now I don't need Gtk
[06:11] <lool> horaceli: The first modules _I_ have touched until now build with stock Gtk from Debian/Ubuntu
[06:12] <bspencer> horaceli, what problems are you seeing.  what version of gtk do you have?
[06:13] <horaceli> wait for a moment, I am searching the build log.
[06:17] <mdz> bspencer: good morning!
[06:17] <agoliveira> bspencer: Hi Bob. We are alreayd in touch.
[06:18] <bspencer> agoliveira, ah, ok.
[06:18] <mdz> bspencer: good to see you on the channel
[06:18] <agoliveira> bspencer: I told him already that he needs to use Gutsy repositories.
[06:18] <agoliveira> mdz: He's being around already ;)
[06:19] <bspencer> yes, he was building hildon-1 but had conflict with gtk.  
[06:19] <horaceli> look, I tried to build up hildon-1 today, getting the source from launchpad.net.
[06:20] <horaceli> and got the error message that HILDON_GTK_INPUT_MODE_NUMERIC is not defined in src/hildon-date-editor.c
[06:20] <agoliveira> horaceli: I understood that you tried to build it on Feisty, right? The stock gtk there will not work.
[06:20] <horaceli> hi, agoliveria, this is horace who sent you email yesterday
[06:20] <horaceli> yes
[06:21] <agoliveira> Don't you prefer to install Gutsy and grab the packges directly from there? It will be easier.
[06:21] <horaceli> s/look/lool
[06:22] <agoliveira> As a matter of fact, I'll take a few CDs with me next week and I'll be glad to prepare an envioroment for the intel guys.
[06:23] <horaceli> I would like to, just currently our pdk is currently based on Feisty and have no Gusty in my hand right now. :-)
[06:23] <bspencer> mdz, does henrik omma come around ubuntu-mobile?
[06:23] <lool> horaceli: Hmm I could build hildon-1 fine here
[06:23] <lool> I'm on Debian/sid
[06:24] <agoliveira> horaceli: We are going to change this as all our work is based on Gutsy.
[06:24] <lool> horaceli: How did you get and build the source, and when did you get it?
[06:25] <horaceli> agoliveira, that is good. i will try to get Gusty installed on my workstation and have a try tomorrow
[06:25] <agoliveira> horaceli: As I told you, you can install a Feisty CD and just change the apt sources and update. I sugest you do it in a separate enviromment like chroot or vmware. I prefer vmware actually.
[06:25] <horaceli> lool, check out the source by bazaar from launchpad.net, 
[06:25] <horaceli> and I did this 14 hours ago
[06:26] <lool> horaceli: How did you build it?  dpkg-buildpackage?
[06:26] <horaceli> lool, did you build up hildon-1 with 'MAEMO_GTK' defined?
[06:26] <lool> horaceli: Can you run "dpkg-checkbuilddeps" from your checkout?
[06:26] <lool> horaceli: I just build using the regular process, either debuild or dpkg-buildpackage
[06:27] <mdz> bspencer: I haven't seen him around, but he's certainly on #ubuntu-devel and would come over if you asked him
[06:27] <mdz> bspencer: his nick is 'heno'
[06:27] <bspencer> thx
[06:28] <mdz> bspencer: I'm not sure how late he usually works, but I was on a conference call with him less than 30 minutes ago
[06:28] <horaceli> lool, I guess I might use the different way. what I did is to do './autogen.sh --prefix=/usr ...' and then 'make'
[06:29] <horaceli> lool, HILDON_GTK_INPUT_MODE_NUMERIC is defined by maemo guys in gtkenums.h and switched on/off by MAEMO_CHANGES.
[06:30] <horaceli> and hildon-date-editor.c used it
[06:31] <lool> horaceli: Basically, you shouldn't worry about the way the package is built internally
[06:32] <lool> horaceli: You should build packages, and this involves dpkg-buildpackage or debuild as interfaces
[06:32] <lool> horaceli: For example in your case, I suspect debian/rules passes adapted configure flags, such as --without-maemo-gtk
[06:33] <horaceli> lool, i am checking the rules. thank you for the advice
[06:33] <mvo> tfheen: could you please paste the output of config.guess on a lpia system for me? support in apt is ready, I just want to be sure that I got it right 
[06:33] <horaceli> it just reminded me.
[06:33] <horaceli> 'cause I built it up successfully by running './debian/rules binary'
[06:35] <agoliveira> horaceli: Unless you have a very good reason to try to compile the packages yourself, I strongly suggest that you work the same way we do, using Gutsy and debian tools or we are risking duplicate efforts and raise conflicts between the results.
[06:35] <lool> horaceli: Actually, it depends on what you want to do with the package; if it is to verify you can build it, debian/rules binary is fine, if you're planning to develop some feature in this source, you might want to call lower level commands manually I suppose
[06:36] <horaceli> agoliveira, I agree
[06:40] <horaceli> lool, yes. what I wanted to do is to get all the hildon components installed in feisty first ( I will move to Gusty tomorrow) and get hildon desktop running
[06:41] <lool> horaceli: You can install them from the archive directly then; no need to build them I suppose
[06:41] <lool> Ah soryr, feisty nm
[06:41] <bspencer> lool, agoliveira, can't we build a gutsy chroot environment inside feisty?
[06:41] <lool> bspencer: Sure, I think so
[06:41] <bspencer> I thikn I was shown how to do this already
[06:42] <bspencer> by tollef
[06:42] <lool> bspencer: If you really want a _chroot_, you can use debootstrap to create a feisty chroot and then dist-upgrade to gutsy
[06:42] <agoliveira> bspencer: Yes you can. Personally, I prefer vmware.
[06:43] <bspencer> horaceli, you should use project builder to get you a build environment.  It builds the gutsy stack for you. 
[06:44] <bspencer> or you can update your system to gutsy
[06:44] <horaceli> bspencer, i am not sure gusty has already in our project builder or not
[06:44] <horaceli> so i preferred to install it and have a try
[06:45] <bspencer> horaceli, I'll check with rusty.  That is the purpose of it anyway.  I'll chat with you tomorrow when you get in.
[06:45] <horaceli> I can install it to a UMPC
[06:45] <horaceli> ok
[06:45] <bspencer> lool, project builder is a simple tool to create an ubuntu-mobile stack in a chroot environment and then allow a user to easily create a USB or ISO image for their device
[06:45] <horaceli> bspencer, so you have already got the gusty source?
[06:46] <lool> bspencer: Ah, is this from maemo or from Intel?
[06:46] <horaceli> lool, from Intel
[06:46] <bspencer> horaceli, we've been using the ubuntu packages.
[06:46] <lool> Internal use only?
[06:46] <bspencer> lool, just until we can get legal stamp
[06:46] <bspencer> big company, long delays
[06:46] <bspencer> but that is in the works.
[06:47] <horaceli> bspencer, yes, I know, just we are based on feisty now, right?
[06:47] <lool> So I suppose it'll end up in Ubuntu too! :)
[06:47] <bspencer> lool, we would like that, if it is acceptable or something better.
[06:47] <bspencer> doesn't show up
[06:48] <lool> It permits some cool "Mise en abme" situations, where you install ubuntu where you install project builder where you install ubuntu
[06:48] <bspencer> :)
[06:49] <bspencer> lool, debootstrap was the tool tollef showed me.  thanks for the reminder
[06:50] <lool> If you _just_ want to build packages, then I suggest you go for pbuilder though
[06:50] <lool> It provides a high level interface to "just build" packages and maintain your chroot, basically "pbuilder create" the first time, "pbuilder update" regularly and "pdebuild" to build packages
[06:51] <lool> It's not suited to launch commands under a gutsy environment and display them on feisty though
[06:51] <bspencer> lool, ok.  that sounds like what "mock" does in FC (our previous life)
[06:51] <lool> hehe
[06:51] <lool> Kind of
[06:51] <bspencer> lool,  but it will create a clean environment (gutsy) and then build your package
[06:51] <lool> mock is a pbuilder + debootstrap kind of think
[06:52] <lool> But yeah, that's the spirit
[06:52] <bspencer> "pbuilder create" doesn't create a full chroot environment?
[06:52] <bspencer> meaning, a chroot with all the dependent packages
[06:53] <lool> It does, but it's different in that it will either 1) create a tarball of the chroot and unpack it each time you need to build something (you can build multiple things in parallel though) or 2) use a special hack called cowdancer which will intercept writes below a tree and create copy on write of files
[06:53] <lool> I'm using the later mode which permits building multiple packages at once and is very fast to setup clean chroots
[06:54] <lool> mock will not really restore a clean chroot each time, it installs and uninstalls packages
[06:54] <lool> Anyway, mock does not handle Debian packages and pbuilder does not handle rpm packages, so... :)
[06:56] <bspencer> got it.  thanks.
[07:15] <lool> bzr.debian.org/bzr/pkg-maemo/hildon-thumbnail/debian/ available for review
[07:32] <mdz> lool: where did these debian branches come from?
[07:32] <lool> Hmm I created these
[07:32] <mdz> is someone working on packaging maemo natively for Debian?
[07:32] <mdz> lool: oh
[07:32] <mdz> why not put them on launchpad then?
[07:33] <lool> To be able to grant commit access to Debian Developers  :-)
[07:33] <mdz> you can grant commit access to anyone with an email address and an ssh key on Launchpad
[07:33] <mdz> so both Debian developers and Ubuntu developers
[07:34] <lool> Ok, let's say it was symetry and independence
[07:34] <mdz> I don't think non-DDs can have access to bzr.d.o
[07:34] <lool> Sure, they simply need to create an account on alioth
[07:34] <lool> And http:// is anonymous
[07:35] <mdz> as you like. it would be nice to at least register the branches in launchpad so that we can get email notifications etc.
[07:36] <lool> Ah that would be nice indeed
[07:50] <tfheen> mvo: that's hard for me, given that I don't have such a system
[07:59] <tfheen> bspencer: hiya
[08:01] <bspencer> howdy
[08:03] <tfheen> good to see you guys around here
[08:03] <lool> tfheen: Did you take a look at some of the branches I published already?  Perhaps if they contain fixes of interest for Ubuntu, I can push some of these changes directly to ubuntu-mobile in the future?
[08:04] <tfheen> lool: no, sorry, I have been utterly swamped.  I'd be fine trusting your judgement on what's appropriate for ubuntu and what's not
[08:05] <tfheen> agoliveira: ok, good.  Prod me when -plankton is there?
[08:06] <bspencer> tfheen, thx.  Well done on the "making us feel welcome" effort
[08:06] <lool> tfheen: Ok; do you think I should push to ubuntu-mobile branches directly then? (I'm not an Ubuntu dev BTW)
[08:07] <tfheen> bspencer: good to hear, if there's anything more you need from us, please tell us.
[08:07] <tfheen> bspencer: I'm working with mdz on getting a set of goals for next week's sprint ready, I'll send it to you guys once it's ready.
[08:08] <tfheen> lool: I'd like to just review the branches first, and assuming they're fine I'm happy to accept you into the ubuntu-mobile team on launchpad.  Sounds good?
[08:08] <lool> tfheen: Oh that's exactly what I wanted; perfect
[08:08] <bspencer> great. I know charlie is working on schedule and stuff to get to you.  We can discuss tomorrow.
[08:08] <tfheen> lool: and then you can later make calls as to whether something is suitable for ubuntu or not.  If you're unsure, I or somebody else is around and happy to help you out.
[08:09] <tfheen> bspencer: excellent
[08:10] <lool> tfheen: The changes which would not be suitable for Ubuntu are basically setting the Maintainer and the version number; I don't expect much more to differ, we discussed *.la files already
[08:10] <agoliveira> tfheen: No problem. Right now I'm having a weird coredump caused by hildon-theme-slicer related to a invalid pointer when it tries to parse some files to build -plankton but I'm on it.
[08:10] <mdz> bspencer: I've received the schedule from Charlie and glanced at it, but haven't digested it yet
[08:12] <lool> Grrr the symlinks in the osso-gwconnect tarball are not nice
[08:12] <lool> http://paste.debian.net/29785
[08:12] <agoliveira> tfheen: Are we ok with the conference tomorrow?
[08:13] <agoliveira> lool: I saw a lot of links to specific versions of autotools over hildon files. Just replace for the default ones looks fine.
[08:14] <lool> agoliveira: Yeah; but these files are currently not kept in bzr, and I'm trying to build as non-native, so it made the build rules think the files were available, but these were dangling pointers
[08:14] <lool> s/pointers/links
[08:14] <tfheen> agoliveira: thanks, yes the conference tomorrow is still on, I would have sent a mail to the mobile list if my email wasn't stuff ATM
[08:16] <tfheen> lool: I think we just have done an automake --copy --force -a to get rid of those
[08:16] <tfheen> bspencer: also, we're having a sprint downtown london in July; you (as in, your team) is welcome.  Again, I'll send an invite as soon as my email is back.
[08:17] <bspencer> tfheen, ok, let us know and we'll see if we can come
[08:17] <lool> tfheen: The thing is, if I try to build even the ubuntu bzr branch in non-native, it will get upstream's "configure" script and hence decide not to run autogen
[08:18] <tfheen> lool: hmm, ok.
[08:18] <tfheen> lool: wonder why our packages built fine, then
[08:18] <lool> tfheen: You're in native mode I think
[08:18] <tfheen> bspencer: July 9th through 13th are the dates.
[08:18] <tfheen> lool: point, we are.
[08:18] <bspencer> when is guadec?
[08:18] <tfheen> week after
[08:18] <tfheen> I'm going to guadec for the first couple of days at least.
[08:18] <bspencer> good -- maybe we could come the last couple of days of the sprint.
[08:19] <tfheen> that'd be good.
[08:21] <lool> Hmm and osso-gwconnect is missing build-deps too; I think it misses the whole autotools saga as it runs autogen
[08:22] <tfheen> hm, I thought I taught it not to do that
[08:24] <lool> tfheen: Perhaps the files were not bzr added after your bootstrap then?
[08:24] <tfheen> maybe, and that machine is behind said horrible network so I can't check until tomorrow
[08:26] <lool> (Proposed bzr.debian.org/bzr/pkg-maemo/osso-gwconnect/debian/ for merge on the wiki / TODO)
[08:26] <tfheen> cheers
[08:38] <lool> Weird, libhildonmime is newer in SVN than in the archive
[08:38] <lool> (at maemo.org)
[08:43] <tko> it's strange that trunk is more recent than latest release?
[08:44] <lool> tko: Well there are two versions with "unstable" instead of UNRELEASED in the changelog; so I would have expected to see at least one in the archive
[08:44] <tko> well, we're not so picky about what we put in changelogs... :)
[08:48] <lool> Heh
[08:54] <lool> (TODO += bzr.debian.org/bzr/pkg-maemo/libhildonmime/debian/ )
[08:54] <tfheen> yay. :-)
[08:55] <lool> I'm at hildon-fm now; then I'll attach the hildonhelp tree
[08:55] <lool> s/attach/attack
[08:56] <lool> BTW, is there a bzr command to wipe all files in a checkout which are not versionned?
[08:57] <tfheen> rm $(bzr unknowns) ?
[08:57] <lool> (For some reason, even maintainer-clean doesn't get rid of files in my libhildonmime)
[08:57] <lool> tfheen: Looks good; thanks!
[09:01] <lool> aha, hildon-file-chooser-dialog.c:38:37: error: gtk/gtkfilechooserutils.h: No such file or directory
[09:01] <lool> So I have to upload Debian's Gtk now :-P
[09:02] <tfheen> yup, it unfortunate.
[09:16] <mvo> tfheen: ok, thanks. I added it as "i.86-.*-linux-gnulp     lpia" I hope that is appropriate. easy enough to fix (buildlib/systemtable)
[09:25] <tfheen> mvo: yup, thanks.
[09:25] <mvo> its in my bzr tree, I plan a upload for a new apt for friday or monday
[09:26] <tfheen> cheers.
[09:26] <tfheen> having it Friday would be great.
[09:41] <agoliveira> Yes, should be fine. Use the build tools as I said.
[10:43] <lool> Cool, maemo folks started merging the patch I sent against libosso with the upstream fixes
[10:43] <lool> All *.c, *.h, and Makefile.am changes tfheen, agoliveira, and I did were merged! :)
[10:49] <agoliveira> lool: Nice :)
[10:50] <agoliveira> lool: That's the spirit of free software!
[12:08] <lool> jonnylamb: Heya
[12:08] <lool> jonnylamb: So, as a starter, there's some info on the Ubuntu Wiki pages
[12:08] <lool> https://wiki.ubuntu.com/MobileAndEmbedded/TODO for example is the TODO
[12:09] <lool> (Well, see topic)
[12:09] <lool> Most packages but not all are bzr based; you can find them on https://code.launchpad.net/~ubuntu-mobile/
[12:09] <jonnylamb> Indeed :)
[12:09] <lool> The Debian branches are on bzr.debian.org and have a mirror of the ubuntu branches
[12:10] <jonnylamb> I was looking around on stage.maemo.org even today, amd noted how the packaging could be cleaned up!
[12:10] <jonnylamb> Oh, is pkg-maemo using bzr?
[12:11] <lool> I was suggested to file bugs in the maemo bugzilla to send packaging and other fixes
[12:11] <lool> jonnylamb: Nope, but the SVN is imported in BZR and the packages use BZR
[12:11] <lool> It seems plenty of upstream folks use git too
[12:13] <jonnylamb> Okay, let me get this straight: we're getting the upstream stuff from maemo. They currently have debian/ directories. We're aiming to clean up the packaging and send the packaging (and of course any bug fixes) back upstream?
[12:13] <lool> Something like that
[12:13] <lool> Except sending back packaging fixes is probably not top priority versus getting things working
[12:13] <jonnylamb> Have maemo requested packaging goes back upstream?
[12:14] <lool> No
[12:15] <lool> One big problem is that they are currently stuck with Debhelper 4
[12:15] <jonnylamb> Oh, this same code is being used by them to create their ARM debs for the actual devices, right?
[12:15] <lool> Upstream, yes
[12:15] <lool> But the bzr branches is for Ubuntu / Debian
[12:16] <lool> s/is/are
[12:16] <jonnylamb> Of course, sorry I missed the point for a second there!
[12:16] <lool> Time to go to bed it seems
[12:16] <jonnylamb> Okay, so current _debian_ branches are on bzr.debian.org ?
[12:16] <lool> Correct
[12:17] <jonnylamb> And follow the TODO list on the Ubuntu wiki?
[12:17] <lool> Debian branches are catching up on the progress of the Ubuntu branches :)
[12:17] <lool> And I'm listing them on the TODO of the Ubuntu wiki because I basically do some cleanups which are cleanups for Ubuntu as well
[12:17] <jonnylamb> Haha, I see!
[12:18] <jonnylamb> Okay, I'm going to have to have a bit scout about this and then if I have any other questions, may I just ping you?
[12:18] <jonnylamb> s/bit/big/
[12:18] <lool> But currently the flow is 1) maemo works upsteam 2) ubuntu branched the maemo svn to try to boostrap maemo and will send its fixes at some point 3) debian (well, me) branched the ubuntu branches to also bootstrap maemo and sends its fixes to both ubuntu and maemo
[12:19] <jonnylamb> Ah okay.
[12:19] <lool> jonnylamb: Sure, just ask around; people should be nice here :)
[12:19] <jonnylamb> Where would *you* like me to start poking around in the Debian branch?
[12:20] <lool> jonnylamb: What do you run, Debian or Ubuntu?
[12:21] <jonnylamb> Debian! You met me on #gnome-debian, after all!
[12:21] <lool> Hehe, there are plenty of Ubuntu-runners on #gnome-debian :)
[12:22] <lool> jonnylamb: Ok, so currently binary packages are available in gutsy, which makes it easier to get some maemo bits; on the Debian side of things, I didn't upload anything yet as I wanted to go a bit further in the bootstrap
[12:22] <lool> If you like, you can try building packages locally from the Debian branches and/or review the existing packages
[12:23] <lool> You should start in the order mce-dev, libosso, libhildon (hildon-1), osso-af-settings, hildon-thumbnail, libhildonmime
[12:23] <lool> You should be able to build all this by bzr co + debuild -i