#ubuntu-mobile 2007-06-01 <Mithrandir> mdz: should I or you or somebody else approve the specs that have been completed? <mdz> Mithrandir: last I saw, they were all still drafting <lool> the "cleanup" one might be marked as started now that Mithrandir has started writing nice copyrights :) <Mithrandir> mdz: some of them are pending approval, at least the ones I fixed up yesterday. <Mithrandir> and I was planning on nagging the drafters for the rest of them today, since we need to get the project plan done. <Mithrandir> unsure if approval-by-committee is going to work well. <mdz> Mithrandir: agreed re: committee <mdz> Mithrandir: would you take responsibility for reviewing and approving them? <mdz> the ones you didn't write, at least <Mithrandir> yes, I can do that. Somebody else will have to approve mine. <mdz> I can do yours if you like <Mithrandir> yes, please. <mdz> just send me a list <Mithrandir> email or IRC? <mdz> or set me as the approver (though you'd need to subscribe the team to keep them on the team specs page) <Mithrandir> https://blueprints.launchpad.net/ubuntu/+spec/mobile-app-framework https://blueprints.launchpad.net/ubuntu/+spec/mobile-build-infrastructure are the ones I'm drafting. <bspencer> what is deb-src vs. deb in the sources.list file? <Mithrandir> hi bob <bspencer> howdy <bspencer> this channel is quiet. I should change that <Mithrandir> deb-src is what apt-get source uses; deb is what apt-get install uses. <Mithrandir> certainly, more sound is welcome. :-) <bspencer> thx <bspencer> I don't know the nicks yet <bspencer> who is asac? Is that adilson? <Mithrandir> Asac is Alexander Sack, the mozilla maintainer <bspencer> ah, I knew I recognized it <Mithrandir> Adilson is another of the mobile people, Adilson Oliveira <Mithrandir> I am, as you might remember, Tollef Fog Heen <bspencer> yes. just hovered over your nick. <bspencer> going to miss you in CA <bspencer> late there? 11:30pm? <Mithrandir> 23:38 <bspencer> :) <Mithrandir> so pondering sleep soonish * tko is still in the middle of trying to arrange flights <Mithrandir> yeah, it's unfortunate I can't be there, but trying to rearrange a vacation would just be too insane. <tko> hmm, anything before 04:00 isn't late... :-P <bspencer> tko are you there all week? <tko> bspencer: trying to <tko> not sure where I'll be staying but I should have the flights booked <bspencer> I just got a hotel yesterday. Everything takes time. <Mithrandir> bspencer: it's good to see you around here, I was kind worried we lost contact. :-/ <bspencer> sorry. my bad <Mithrandir> no need to feel bad, I'm just happy we've caught up again <bspencer> actually I joined a few times at home but the proxy settings at work weren't obvious and I was lazy to get it sorted out <tko> I just hope we can manage decent transportation.. I gathered everyone else has a car <bspencer> tko, true. But if you need a ride from your hotel we can pick you up <bspencer> it isn't Europe, no good city-transportation <Mithrandir> ideally, you should stay in the same place, since, as everybody knows the hallway track is the most important one. :-) <bspencer> I think it might be hard with the late timing. Some of the places I tried only had exective suites left <bspencer> but we'll have the late-night-eating track anyway <tko> bspencer: yeah, I know, I've been to CA once before.. before that I was to boston and the difference is quite noticeable <bspencer> east coast cities seem to have come to the realization that they need to be organized to accomodate everyone. West coast cities are still in denial <tko> I'm so spoiled by the public transportation in helsinki area :) <bspencer> I love the European trains <bspencer> just spent a month in Germany, Engl, Italy with my wife last summer. It was great. <Mithrandir> I'm wondering if we'll be able to have a mobile sprint in late august or so <Mithrandir> do you think that would be doable? <bspencer> very <bspencer> on your side of the ocean? <bspencer> we could do something after GUADEC for a day, perhaps. I think Rusty and i will be there. (UK) <Mithrandir> I'd need to actually book the office, but we have a proper office in Millbank, London, UK with facilities which I'm fairly sure we could use. <bspencer> Either there or Zermatt would be fine with me ;) <Mithrandir> hehe. :-) <Mithrandir> zermatt sounds good too, do you have a facility there? <bspencer> not yet. <Mithrandir> I can mail the list and see if there's interest in having a sprint in the UK in late august? We'd need to agree on the dates, maybe early september would be better <bspencer> if it isn't adjacent to GUADEC then I would say in Sept and it could be anywhere. Make it convenient for you because it will be the same difference for us. <bspencer> Is Sept cutting too close to release? <bspencer> I've never been to Norway <Mithrandir> I like Norway. :-P <Mithrandir> we had a sprint here this winter, it was good. <Mithrandir> not so much in the way of bandwidth trouble, etc. <Mithrandir> early sept is not too bad wrt release, but august might be better. <Mithrandir> I'd be happy to host it here, but it'll cost a bit more than london, and is more hassle to get to than London <bspencer> hmm.. cost more than London? Inconceivable <bspencer> that place is expensive (at least London was for a US tourist) <bspencer> hotdog = 2.50 pound = $5 USD. <Mithrandir> Oslo is.. quite expensive too. <tko> I got the impression Norway is quite expensive, even compared to finland <Mithrandir> and here we'd have to use a business hotel to have conference rooms and such, while in London we could use the Canonical offices. <bspencer> I see. Why not your house? :) <bspencer> s/house/mansion <Mithrandir> it's a flat. :-) We could use my father's cabin, it can fit some more people. <Mithrandir> but yes, I could possibly arrange meeting space in Oslo too, depending on how many we'd be. <Mithrandir> I'll mail the list and we'll see what people think. <bspencer> maybe we can sort that out on the mailing list. Intel would have max 5 I think. <bspencer> but maybe after next week we can discuss too, depending on needs (kernel, UI, apps, etc.) <Mithrandir> sounds good. #ubuntu-mobile 2007-06-04 <alienseer23> hello, I was looking for a linux flavor to install on my palm TX (or to just find out more info on this concept) when I ran across this here Ubuntu project. Q: is this going to be an Ubuntu flavor that will install onto devices such as my Palm TX???? I really hope so, ad if so, what is the best way I can keep tabs on this project as it develops? <Mithrandir> alienseer23: it might eventually be, but I don't think we are targetting whatever cpu architecture your palm has as an initial goal. <lucasr> hi <lool> Mithrandir: I wonder about the -dbg package name for hildon-thumbnail: shouldn't it use something more generic than libhildon-thumbnail0-dbg, perhaps hildon-thumbnail-dbg? <Mithrandir> I prefer to change it as little as possible from what upstream uses, but otherwise agreed. * Starting logfile irclogs/ubuntu-mobile.log <Mithrandir> agoliveira: you're working on -l10n-mr, right? <agoliveira> -mr? I saw this -mr package. I was checking out hildon-fm-l10n to see if this package is part of it. Is there a -mr somewhere else? <agoliveira> Mithrandir: and the actual strings seens to match. <Mithrandir> hildon-fm-l10n-mr is what I meant <agoliveira> Mithrandir: Yes, I tought you meant that but I didn't find something named like this on maemo svn so I tought it was the name of one package inside hildon-fm-l10n or hildon-fm-l10n-2.0 <Mithrandir> it's a binary package name, yes. <agoliveira> Mithrandir: or that someone messed up with the dependency name as the strings seens to match. <Mithrandir> are you comitting the fixes needed to make -fm-l10n build or should I? <agoliveira> It will biuld right out of the box but the binary package names do not match the hildon-fm dependency so I'm checking if there is somehting that I missed or if someone just messed with the names as I said before. <Mithrandir> no, it won't. <Mithrandir> are you building on gutsy? <agoliveira> Oh, sorry. <agoliveira> No, it really won't. I did some changes on friday. <agoliveira> Mithrandir: Ok, it will compile now but the binary packages does not match the dependency as I said. Give me a few minutes to try to understand what's happening. <Mithrandir> if you did any changes on Friday, you forgot to push them to the bzr branch. <Mithrandir> make sure what you have is a checkout and not a separate branch <agoliveira> Mithrandir: No, the matter was that there was no import on LP so I had to wait it to be imported before branch it. <Mithrandir> ah, ok. <agoliveira> It happens late friday so I only had it done today. The branch I creted there now is fresh. <agoliveira> Mithrandir: I just commited the change so it compiles nicelly now. I'll now figure out what's the deal with the dependency name. I'll just grab a coffee (it's cold in here today :) ). <Mithrandir> cheers. <agoliveira> Mithrandir:Found it. It's actually comming from somehting called haf-marketing-release which is a metapackage that agregates all the l10n stuff. Great isn't it? <Mithrandir> indeed <Mithrandir> I need to go soonish, but if you can manage to have -fm installable by tomorrow, that'd be excellent. Please do tell me what stuff you need uploaded, or just update the TODO list with them <agoliveira> Mithrandir: Don't worry. I believe I can handle it. The only matter is that I'll need to import the rest of the l10n stuff a bit later. <agoliveira> Mithrandir: as soon this is done, hildon-fm should be ok and we can go for hildon-desktop. Yeay! :) <Mithrandir> exactly. :-) <agoliveira> Mithrandir: Going lunch now. Later. <lucasr> hei <tko> lucasr: how far did we get with our hildon roadmap? migrate to gnome.org, make a stable release, do something about l10n <lucasr> tko, someting like this :-) <tko> no betas or rcs? :) <lucasr> tko, rcs? <tko> release candidates <lucasr> tko, I think the gnome release is good example of how we would organize our releases <lucasr> tko, so, yes, there will probably be rcs <lucasr> :-) <agoliveira> Mithrandir: IIRC, a few days ago you got a bzr push stuck, right? How did you fix it? <Mithrandir> bzr break-lock <agoliveira> Nope. No deal :( <Mithrandir> you need to give it an URL too <agoliveira> oops :P <agoliveira> Worked. Thanks. #ubuntu-mobile 2007-06-05 * Starting logfile irclogs/ubuntu-mobile.log <Mithrandir> tko: who would be a good person to talk with about hildon and translations? <Mithrandir> osso-gwcompat should be in now. <Mithrandir> agoliveira: do you have any idea how much work it'd be to move to the official bluez interfaces? <agoliveira> Mithrandir: I'ts hard to say as I don't have experience on this but for the looks I would say that won't easy. Bluetooth is quite a messy stuff. <Mithrandir> hmm <agoliveira> Mithrandir: and there is some things there, related to proprietary part I guess, that won't make much sense to me but, as I said, I don't have experience with bluez. <Mithrandir> me neither. :-) <agoliveira> Mithrandir:This is something needed, no doubt, but we should check with Nokia to see if they have something already in place, maybe even Intel has something but they didn't say anything about it also. <Mithrandir> nokia seemed to want to transition, but nothing firm yet. <agoliveira> Mithrandir:BTW, after the small "anouncement" I did yesterday, I was contacted by Bob Sinclair (Intel) asking me if he could already use the packages, if he could help, etc. I didn't say anything yet but I believe he can access LP if he wants grab the sources right? <Mithrandir> yes, the branches are publically available. <agoliveira> Fine, I'll tell him that he can jump in from there then. <Mithrandir> as for helping out, I would prefer if people started by contributing by either sending patches to the mailing list or branching off into their own space on launchpad before we give them commit access <Mithrandir> I'm happy being easy on the requirements, but just giving it out completely freely is something I would like to avoid. <agoliveira> Understood. <agoliveira> And it's Bob Spencer. Bob Sinclair is a musician :) <Mithrandir> oh, Bob Spencer is a member of the team, I thought <agoliveira> Yes, he is already. <daniels> Mithrandir: so, you guys doing anything interesting with x? <Mithrandir> daniels: not linda89@example.com. <Mithrandir> we're so far basically just working on getting hildon into ubuntu. <Mithrandir> fixing all kinds of minor and major stuff, like.. completely wrong debian/copyrights and such <daniels> Mithrandir: no surprise there. <daniels> the package quality is ... variable. <Mithrandir> yes, some bits are quite good, some not so much. <Mithrandir> you don't happe to know who'd be the right person to chat with about l10n infrastructure? <daniels> i have no idea, tbh <daniels> i'd probably have to ask the same people you would <Mithrandir> ok, I'll just mail maemo-developers and see what comes of it. <daniels> they don't lurk on m-d; you'd have to talk to nokians directly <daniels> they're sort of part of the corporate machinery <Mithrandir> hm, ok. <Mithrandir> we're open, but not really, and not always, and not all bits. <agoliveira> Mithrandir: got it now? ;) <agoliveira> That's *the* single major complain the maemo developpers have. <Mithrandir> the openness, or lack thereof? <agoliveira> the lack of it. * Mithrandir nods <Mithrandir> in that respect, we have a much better job <daniels> not a discussion i'm really keen to get into, but yeah, talk to your nokia contacts to find the l10n people. <agoliveira> indeed <Mithrandir> s/better/easier/, sorry. <tko_> Mithrandir, I know something about l10n.. <tko_> Mithrandir, as I mentioned yesterday, our roadmap is something along the lines of 1) migrate to gnome.org, 2) make stable release, 3) fix po <Mithrandir> ok <Mithrandir> what's blocking those and how can I/we help? <Mithrandir> we're basically trying to answer the question whether we can use malone to translate hildon for gutsy or if that's not feasible. <daniels> hopefully we can move off logical strings soon, too <tko_> well, migration is currently blocking on accounts, then on svn repositories, then on us penetrating the firewall for commit access.. stable release is just blocking on fixing all bugs :) <Mithrandir> daniels: logical strings, as in msgid "sfil_li_folder_root" <Mithrandir> I presume <tko_> and we can't really touch the l10n during this development cycle <daniels> Mithrandir: right <Mithrandir> ok. <tko_> Mithrandir, if malone could display the en_GB string instead of the logical id, it should be simple to use <Mithrandir> gutsy is October, so not feasible for then. <Mithrandir> sorry, not malone, but rather rosetta <tko_> I was wondering about that... <Mithrandir> I'm making a mess of all words today. <Mithrandir> I can ask the rosetta people if that's feasible. <tko_> but figured you must know better :-P <daniels> tko_: well, you have irc now, which is an improvement, so surely svn can't be too far off ;) <Mithrandir> svn-over-irc. <Mithrandir> :-P <tko_> daniels, well, I'm abusing jabber irc transport, which is a bad argument as I really shouldn't be running jabber either :-P <tko_> svn over dns <Mithrandir> ip-over-dns is working quite well, but I suspect you'll get angry employers that way. <daniels> Mithrandir: there are ways to bust tunnels out <Mithrandir> it sounds like rosetta should be able to handle this way of doing translations, so we can use it for gutsy. <lool> Hmm some bzr branches are in an old format and bzr complains about it <lool> Working tree format 3 is deprecated and a better format is available. <lool> e.g. hildon-thumbnail <Mithrandir> just run bzr upgrade and you should be fine <Mithrandir> ideally, hildon-thumbnail shouldn't ship the .bzr directory in the tar.gz at all <lool> Mithrandir: I mean on bazaar.launchpad.net <lool> At least when I bzr co all branches, only some display the "obsolete format" error <Mithrandir> hm <lool> Do you want a list? <Mithrandir> weird. <Mithrandir> that's just your working tree. <Mithrandir> hildon-thumbnail is that way? <lool> I doubt it's local, otherwise I would get the warning on all checkouts <lool> BTW, I'm bootstrapping a pkg-maemo on alioth <lool> And wrote a script to checkout all bzr branches of the ubuntu-mobile team as "/ubuntu" <Mithrandir> bzr co sftp://bazaar.launchpad.net/~ubuntu-mobile/hildon-thumbnail/ubuntu/ hildon-thumbnail ; cd hildon-thumbnail ; bzr status doesn't make it whine here <lool> http://paste.debian.net/29679 <lool> Mithrandir: It's with a bzr tarball from upstream installed in my home <lool> Mithrandir: Ah, it might have been interrupted in a previous run <haary> What browser will Ubuntu mobile use? <Mithrandir> haary: custom gecko/xulrunner-based, most likely. <lool> Mithrandir: Right; I wiped everything, and now it's fixed; sorry for the noise <Mithrandir> lool: ah, ok. Good. :-) <Mithrandir> you had me confused for a bit <lool> Yeah, I was confused too <haary> Oh, I thought it would be something based on Gtk Webcore, since gecko is pretty bloated <lool> Is there some kind of mailing list for tarball releases in maemo? <tko_> lool, we don't do tarball releases... :-] <tko_> lool, we've requested one for hildon on gnome.org but it'll take time <lool> I'll use http://repository.maemo.org/pool/sardine/main/source/libo/libosso/ as download URL for libosso then <lool> I can't help but smile as I cross Johan Bilien in the ChangeLog mouarf <tko_> mmm? <lool> tko_: We were in the same school and even association <lool> via.ecp.fr <lool> http://via.ecp.fr/via/historique/index.html <tko_> ah <lool> Hmm the maemo version numbers conflict with the Debian ones <lool> I wonder whether Debian packages should use -1ubuntu3debian1 now :) <lool> mdz: Hmm, I think you uploaded mce-dev, but I can't find anything in the ubuntu branch of "mce-dummy"; is this on purpose? <mdz> lool: I just synced it unmodified from the maemo repository, since it didn't require any changes (it's trivial) <lool> Ok, thanks <mdz> I've added it to TODO by way of documentation <bobux> agoliveira, what time zone are you in? Is it the same as east coast US? <agoliveira> bobux: I don't know, what's US timezone? :) Seriously, I'm at gmt -3. <bobux> I'm pdt, 9:38am now <bobux> you just back from lunch, so 12:38pm? <agoliveira> 13:43 actually. <bobux> I was thinking we were the same but you are working at my 4am <bobux> good to know. thx <bobux> I saw your comment above on LP access and am doing that today <agoliveira> In Brazil it's mostly GMT -3 but some parts are -2 and even -1 IIRC. <agoliveira> Nice to know :) <lool> I cleaned mce-dummy a little; would someone be so kind to have a look at the changes, tell me whether they are not too intrusive, and perhaps merge some in the ubuntu branch? bzr.debian.org/bzr/pkg-maemo/mce-dummy/debian/ <daniels> a diff might be nice, being somewhat easier to review than a bzr branch. <tko> daniels: you wouldn't mind a git branch though, would you? :) * lool tried bzr diff on two remote branches just for fnu <daniels> tko: it would be easier than bzr (given that git lets you clone new repositories with 'old' versions; i couldn't clone postr with edgy's bzr, which sucks horribly), but would still definitely prefer a diff. <lool> http://people.dooz.org/~lool/debian/mce-dummy-diff.patch <tko> diff is easier, true.. shouldn't the bzr web thingamagic be able to produce a diff between arbitrary revisions? <lool> Who should I talk to to get such cleanups in the upstream SVN? <lool> Individual maintainers? <tko> lool: bug in bugzilla and individual maintainers I'd say, at least until we get the hildon mailing list running <tko> lool: IIRC we don't have debhelper 5 yet so that part might become annoying to us if we can't apply the whole patch <lool> tko: Oh yeah; but not bumping debhelper is going to be a pain for all packages, especially those providing -dbg packages :-/ <lool> tko: Is there a chance to get an updated debhelper <daniels> yeah, debhelper 5 is an enormous pain, and not solved anytime soon. <lool> aha <daniels> lool: no, and you're still stuck with dpkg 1.13.19 in the devkits. <tko> and as you may have noticed we're not too good at the finer details of packaging either so chances of us tweaking the necessary bits to fit for debhelper 4 are bitty slim <lool> I wonder whether we should refrain from updating debian/compat in this case <tko> daniels: fer was saying something that sdk guys were quick to agree on getting debhelper 5 as it's apparently needed for python bindings <daniels> lool: thanks for the diff. looks fine, modulo dh5. <lool> The thing is, debhelper 4 is out of my memories; I don't know what expectations I have which would be broken in v4 mode <tko> :) <daniels> tko: ah, nice. i argued with them about that and dpkg for a while, got nowhere. <lool> For example, I don't recall whether it's ok to wrap build-deps in DH 4 <tko> daniels: sdk != si <daniels> lool: no --print-missing (or whatever), --dbg-package semantics reversed (i.e. use --dbg-package=libfoo1 to get libfoo1-dbg) <daniels> tko: yes, both teams. :) <lool> daniels: Yeah, that kind of stuff <lool> Hmm daniels, you said it's unlikely to be very soon, and tko you mentionned is a requirement for python <tko> I'm still sort of wondering if we could get canonical maintain our build environment and tools and such :) <lool> Until when can you get debhelper 5, and how to help? <daniels> tko: if only <lool> tko: hehe <daniels> lool: we don't know, and there's nothing you can do to help, sadly <daniels> dinnertime, bbl <tko> lool: I meant currently the python packaging requires debhelper 5, we need to either get it, or make it work with v4 <lool> tko: I don't know whether it's for sale, but I suppose it could help Nokia save money on that part of the maintenance <lool> tko: Python stuff has changed a lot recently; I am not sure what you mean with "python packaging", but restraining your python packages to the old mode of dh_python sounds awful <tko> I've gone through the pain of downgrading some packaging, so yes, I know <tko> but still, in cases, if you want something to happen this year... <lool> tko: Is it discussed internally in Nokia? <lool> Or are there people one can talk to, to explain that upgrading debhelper should be self thanks to its concept of compat modes? <tko> lool: not actively that I know of (would require some higher level business decision) individuals complain occasionally but eventually resign <tko> on debhelper specifically I believe daniels has most recent experience <lool> Hmm where's mce-dev in SVN? <lool> I see mce-dummy Provides mce-dev, but it's not the good mce-dev it seems * lool goes offline this evening & <tko> lool: it probably isn't in svn (not all teams use stage) <mdz> lool: I don't think I found it in svn <mdz> I only noticed it by accident <mdz> it's essentially a stripped-down version of the proprietary mce package <agoliveira> Indeed. mce-dev is not there, just mce-dummy because of the dependency IIRC. <mdz> agoliveira: no, there are three MCE packages <mdz> mce (the proprietary one), mce-dummy (in svn) and mce-dev (in the archive) <tko> IIRC mce-dummy is historical because it was needed to satisfy mce dependency, but it was later superseded by the real thing <mdz> I pulled in the latter <agoliveira> I meant in the stage svn. <agoliveira> Weird, I don't recall to have other one. <agoliveira> linda89@example.com. <happycube> -mtune=pentium seems wrong... the A100 series are pentium-m which is k6 <happycube> *P6/ppro <tko> hmm, I just realized I'll be in SF at the same time as apple is organizing their conference. I wonder if I could somehow sneak that into my visit and get nokia pay for it :-P <tfheen> tko: debhelper 4 is acceptable to us if that makes it easier for you guys to merge our changes. <happycube> ubuntu mid can work on something trackpad-based like the asus eee right? <happycube> that looks like a *very cheap* laptopized MID <happycube> also there needs to be provision for not wearing holes in the SSD's that all this gear uses ;) <tko> tfheen: at the moment it would, but fer was trying to get debhelper updated. hard to say how/when that'll go #ubuntu-mobile 2007-06-06 <PepperDog> Hi! I'd like to compile a kernel module for Ubuntu Mobile. Can anyone guide me ? <PepperDog> Anyone compiled a kernel module on Ubuntu ? <PepperDog> any kernel developers here? <lool> tko_, mdz: Ack, thanks <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? <lool> Mithrandir: ^^^ <lool> I suppose we can mail fer who I understand has a clue about whether DH 5 is likely or not <Mithrandir> well debhelper < 4 is deprecated, debhelper 4 is fine. <daniels> if dh5 does happen, it's almost certainly not going to be soon enough anyway. <lool> Mithrandir: We're close to 6 from what I've seen in Debian's DH changelog entries <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? <lool> Plus, there's the question of Python and dbg packages :-/ <Mithrandir> indeed. <daniels> lool: months. <lool> That's a pity; I don't think it makes sense to restrain to DH 4 stuff for months; what do other think? <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 <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) <daniels> no-one enjoys carrying it. i didn't enjoy changing every single x package to use dh4 instead of 5. <lool> mdz: Was outo also taken verbatim? <mdz> lool: I believe so, yes <mdz> daniels: oh, hello <daniels> mdz: good afternoon <daniels> (i'm here more or less out of curiousity, rather than official capacity, fwiw.) <lool> mdz: Added to the wiki; thanks <tko_> oh, we've been trying to kick outo out.. was it needed somewhere? <lool> Perhaps someone can check the linda89@example.com/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 <lool> tko_: It's in the deps of libosso-test <mdz> lool: might be a good thing to add to TODO <tko_> I wonder if libosso-test is up to date <lool> Is there a wiki page documenting the deprecated modules in the Ubuntu Wiki? <mdz> lool: deprecated modules? <lool> The upstream deprecated stuff such as hildon-libs, outo... <Mithrandir> lool: we don't like .la files either, so we'd be happy to take that. <Mithrandir> lool: I am planning to make a status page too and merge TODO into that, but I just haven't had time yet. <lool> mdz: Added the review of the bzr branch to TODO <lool> Mithrandir: Good for *.la files; the other *.la files might already refer to it though <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? <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 <lool> Oh right, bugzilla, that was the thing <lool> Super slow though <daniels> lool: you've just got to make sure it's assigned to a real developer, rather than to maemo qa. <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 <daniels> lool: cool, thanks <daniels> lool: ditching .la files is definitely on the agenda <daniels> lool: we've already done it with some parts of the distro <lool> Cool; did you so by stripping dependency_libs? <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 <lool> Hmm that's not anchored; bad me <daniels> er, no, we just did the iterative process of rebuilding from the bottom up, as we did in ubuntu as well. <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 <lool> So it's a too step approach, but you don't have to start by the leaf libs <daniels> right <lool> s/too/two <lool> Weird, why does libosso have all the autotools generated files in SVN <lool> 29 modules have a configure out of 43 modules with configure.ac <tko_> we require that dpkg-buildpackage on svn export works, and people couldn't be bothered to run autogen or similar in debian/rules <lool> I see; thanks <Mithrandir> is that a policy decision or would you take patches to run autogen.sh if configure doesn't exist? <tko_> depends on maintainer <tko_> it was their decision originally <Mithrandir> ok <Mithrandir> and you don't have / want to use sticks to make them adjust to a common policy? <daniels> Mithrandir: that process is incredibly heavyweight <Mithrandir> ugh, ok. <Mithrandir> this is part of why you guys want to move onto gnome.org or is that something else? <lool> gnome.org does not have many policies either; mostly some release policies TTBOMK <lool> But at least all GNOME modules do not have autotools files in SVN :) <Mithrandir> they don't have a policy against generated files in revision control? <lool> Mithrandir: I'd say nobody would have had this idea just because no other module does os <lool> so <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. :) <lool> Hehe <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. <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. <Knowledge> So does this mean that the n770 and N800 might get ubuntu? <Knowledge> and while linda89@example.com I keep my hx4700? <happycube> right now i think this is targeted for x86-based ultramobiles <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. <lool> Hmm should osso-af-settings really be Arch: all? <lool> It ships files in /usr/lib/pkg-config <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 <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? <horaceli> lool, could you please share with me what GTK+ base are you use right now? <bspencer> agoliveira -- want to introduce you to horaceli <lool> horaceli: Right now I don't need Gtk <lool> horaceli: The first modules _I_ have touched until now build with stock Gtk from Debian/Ubuntu <bspencer> horaceli, what problems are you seeing. what version of gtk do you have? <horaceli> wait for a moment, I am searching the build log. <mdz> bspencer: good morning! <agoliveira> bspencer: Hi Bob. We are alreayd in touch. <bspencer> agoliveira, ah, ok. <mdz> bspencer: good to see you on the channel <agoliveira> bspencer: I told him already that he needs to use Gutsy repositories. <agoliveira> mdz: He's being around already ;) <bspencer> yes, he was building hildon-1 but had conflict with gtk. <horaceli> look, I tried to build up hildon-1 today, getting the source from launchpad.net. <horaceli> and got the error message that HILDON_GTK_INPUT_MODE_NUMERIC is not defined in src/hildon-date-editor.c <agoliveira> horaceli: I understood that you tried to build it on Feisty, right? The stock gtk there will not work. <horaceli> hi, agoliveria, this is horace who sent you email yesterday <horaceli> yes <agoliveira> Don't you prefer to install Gutsy and grab the packges directly from there? It will be easier. <horaceli> s/look/lool <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. <horaceli> I would like to, just currently our pdk is currently based on Feisty and have no Gusty in my hand right now. :-) <bspencer> mdz, does henrik omma come around ubuntu-mobile? <lool> horaceli: Hmm I could build hildon-1 fine here <lool> I'm on Debian/sid <agoliveira> horaceli: We are going to change this as all our work is based on Gutsy. <lool> horaceli: How did you get and build the source, and when did you get it? <horaceli> agoliveira, that is good. i will try to get Gusty installed on my workstation and have a try tomorrow <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. <horaceli> lool, check out the source by bazaar from launchpad.net, <horaceli> and I did this 14 hours ago <lool> horaceli: How did you build it? dpkg-buildpackage? <horaceli> lool, did you build up hildon-1 with 'MAEMO_GTK' defined? <lool> horaceli: Can you run "dpkg-checkbuilddeps" from your checkout? <lool> horaceli: I just build using the regular process, either debuild or dpkg-buildpackage <mdz> bspencer: I haven't seen him around, but he's certainly on #ubuntu-devel and would come over if you asked him <mdz> bspencer: his nick is 'heno' <bspencer> thx <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 <horaceli> lool, I guess I might use the different way. what I did is to do './autogen.sh --prefix=/usr ...' and then 'make' <horaceli> lool, HILDON_GTK_INPUT_MODE_NUMERIC is defined by maemo guys in gtkenums.h and switched on/off by MAEMO_CHANGES. <horaceli> and hildon-date-editor.c used it <lool> horaceli: Basically, you shouldn't worry about the way the package is built internally <lool> horaceli: You should build packages, and this involves dpkg-buildpackage or debuild as interfaces <lool> horaceli: For example in your case, I suspect debian/rules passes adapted configure flags, such as --without-maemo-gtk <horaceli> lool, i am checking the rules. thank you for the advice <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 <horaceli> it just reminded me. <horaceli> 'cause I built it up successfully by running './debian/rules binary' <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. <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 <horaceli> agoliveira, I agree <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 <lool> horaceli: You can install them from the archive directly then; no need to build them I suppose <lool> Ah soryr, feisty nm <bspencer> lool, agoliveira, can't we build a gutsy chroot environment inside feisty? <lool> bspencer: Sure, I think so <bspencer> I thikn I was shown how to do this already <bspencer> by tollef <lool> bspencer: If you really want a _chroot_, you can use debootstrap to create a feisty chroot and then dist-upgrade to gutsy <agoliveira> bspencer: Yes you can. Personally, I prefer vmware. <bspencer> horaceli, you should use project builder to get you a build environment. It builds the gutsy stack for you. <bspencer> or you can update your system to gutsy * lool . o O ( Hmm what's project builder ) <horaceli> bspencer, i am not sure gusty has already in our project builder or not <horaceli> so i preferred to install it and have a try <bspencer> horaceli, I'll check with rusty. That is the purpose of it anyway. I'll chat with you tomorrow when you get in. <horaceli> I can install it to a UMPC <horaceli> ok <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 <horaceli> bspencer, so you have already got the gusty source? <lool> bspencer: Ah, is this from maemo or from Intel? <horaceli> lool, from Intel <bspencer> horaceli, we've been using the ubuntu packages. <lool> Internal use only? <bspencer> lool, just until we can get legal stamp <bspencer> big company, long delays <bspencer> but that is in the works. <horaceli> bspencer, yes, I know, just we are based on feisty now, right? <lool> So I suppose it'll end up in Ubuntu too! :) <bspencer> lool, we would like that, if it is acceptable or something better. <bspencer> doesn't show up <lool> It permits some cool "Mise en abme" situations, where you install ubuntu where you install project builder where you install ubuntu <bspencer> :) <bspencer> lool, debootstrap was the tool tollef showed me. thanks for the reminder <lool> If you _just_ want to build packages, then I suggest you go for pbuilder though <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 <lool> It's not suited to launch commands under a gutsy environment and display them on feisty though <bspencer> lool, ok. that sounds like what "mock" does in FC (our previous life) <lool> hehe <lool> Kind of <bspencer> lool, but it will create a clean environment (gutsy) and then build your package <lool> mock is a pbuilder + debootstrap kind of think <lool> But yeah, that's the spirit <bspencer> "pbuilder create" doesn't create a full chroot environment? <bspencer> meaning, a chroot with all the dependent packages <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 <lool> I'm using the later mode which permits building multiple packages at once and is very fast to setup clean chroots <lool> mock will not really restore a clean chroot each time, it installs and uninstalls packages <lool> Anyway, mock does not handle Debian packages and pbuilder does not handle rpm packages, so... :) <bspencer> got it. thanks. <lool> bzr.debian.org/bzr/pkg-maemo/hildon-thumbnail/debian/ available for review <mdz> lool: where did these debian branches come from? <lool> Hmm I created these <mdz> is someone working on packaging maemo natively for Debian? <mdz> lool: oh <mdz> why not put them on launchpad then? <lool> To be able to grant commit access to Debian Developers :-) <mdz> you can grant commit access to anyone with an email address and an ssh key on Launchpad <mdz> so both Debian developers and Ubuntu developers <lool> Ok, let's say it was symetry and independence <mdz> I don't think non-DDs can have access to bzr.d.o <lool> Sure, they simply need to create an account on alioth <lool> And http:// is anonymous <mdz> as you like. it would be nice to at least register the branches in launchpad so that we can get email notifications etc. <lool> Ah that would be nice indeed <tfheen> mvo: that's hard for me, given that I don't have such a system <tfheen> bspencer: hiya <bspencer> howdy <tfheen> good to see you guys around here <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? <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 <tfheen> agoliveira: ok, good. Prod me when -plankton is there? <bspencer> tfheen, thx. Well done on the "making us feel welcome" effort <lool> tfheen: Ok; do you think I should push to ubuntu-mobile branches directly then? (I'm not an Ubuntu dev BTW) <tfheen> bspencer: good to hear, if there's anything more you need from us, please tell us. <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. <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? <lool> tfheen: Oh that's exactly what I wanted; perfect <bspencer> great. I know charlie is working on schedule and stuff to get to you. We can discuss tomorrow. <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. <tfheen> bspencer: excellent <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 <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. <mdz> bspencer: I've received the schedule from Charlie and glanced at it, but haven't digested it yet <lool> Grrr the symlinks in the osso-gwconnect tarball are not nice <lool> http://paste.debian.net/29785 <agoliveira> tfheen: Are we ok with the conference tomorrow? <agoliveira> lool: I saw a lot of links to specific versions of autotools over hildon files. Just replace for the default ones looks fine. <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 <lool> s/pointers/links <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 <tfheen> lool: I think we just have done an automake --copy --force -a to get rid of those <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. <bspencer> tfheen, ok, let us know and we'll see if we can come <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 <tfheen> lool: hmm, ok. <tfheen> lool: wonder why our packages built fine, then <lool> tfheen: You're in native mode I think <tfheen> bspencer: July 9th through 13th are the dates. <tfheen> lool: point, we are. <bspencer> when is guadec? <tfheen> week after <tfheen> I'm going to guadec for the first couple of linda89@example.com. <bspencer> good -- maybe we could come the last couple of days of the sprint. <tfheen> that'd be good. <lool> Hmm and osso-gwconnect is missing build-deps too; I think it misses the whole autotools saga as it runs autogen <tfheen> hm, I thought I taught it not to do that <lool> tfheen: Perhaps the files were not bzr added after your bootstrap then? <tfheen> maybe, and that machine is behind said horrible network so I can't check until tomorrow <lool> (Proposed bzr.debian.org/bzr/pkg-maemo/osso-gwconnect/debian/ for merge on the wiki / TODO) <tfheen> cheers <lool> Weird, libhildonmime is newer in SVN than in the archive <lool> (at maemo.org) <tko> it's strange that trunk is more recent than latest release? <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 <tko> well, we're not so picky about what we put in changelogs... :) <lool> Heh <lool> (TODO += bzr.debian.org/bzr/pkg-maemo/libhildonmime/debian/ ) <tfheen> yay. :-) <lool> I'm at hildon-fm now; then I'll attach the hildonhelp tree <lool> s/attach/attack <lool> BTW, is there a bzr command to wipe all files in a checkout which are not versionned? <tfheen> rm $(bzr unknowns) ? <lool> (For some reason, even maintainer-clean doesn't get rid of files in my libhildonmime) <lool> tfheen: Looks good; thanks! <lool> aha, hildon-file-chooser-dialog.c:38:37: error: gtk/gtkfilechooserutils.h: No such file or directory <lool> So I have to upload Debian's Gtk now :-P <tfheen> yup, it unfortunate. * lool goes for dinner & <mvo> tfheen: ok, thanks. I added it as "i.86-.*-linux-gnulp lpia" I hope that is appropriate. easy enough to fix (buildlib/systemtable) <tfheen> mvo: yup, thanks. <mvo> its in my bzr tree, I plan a upload for a new apt for friday or monday <tfheen> cheers. <tfheen> having it Friday would be great. <agoliveira> Yes, should be fine. Use the build tools as I said. <lool> Cool, maemo folks started merging the patch I sent against libosso with the upstream fixes <lool> All *.c, *.h, and Makefile.am changes tfheen, agoliveira, and I did were merged! :) <agoliveira> lool: Nice :) <agoliveira> lool: That's the spirit of free software! <lool> jonnylamb: Heya <lool> jonnylamb: So, as a starter, there's some info on the Ubuntu Wiki pages <lool> https://wiki.ubuntu.com/MobileAndEmbedded/TODO for example is the TODO <lool> (Well, see topic) <lool> Most packages but not all are bzr based; you can find them on https://code.launchpad.net/~ubuntu-mobile/ <jonnylamb> Indeed :) <lool> The Debian branches are on bzr.debian.org and have a mirror of the ubuntu branches <jonnylamb> I was looking around on stage.maemo.org even today, amd noted how the packaging could be cleaned up! <jonnylamb> Oh, is pkg-maemo using bzr? <lool> I was suggested to file bugs in the maemo bugzilla to send packaging and other fixes <lool> jonnylamb: Nope, but the SVN is imported in BZR and the packages use BZR <lool> It seems plenty of upstream folks use git too <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? <lool> Something like that <lool> Except sending back packaging fixes is probably not top priority versus getting things working <jonnylamb> Have maemo requested packaging goes back upstream? <lool> No <lool> One big problem is that they are currently stuck with Debhelper 4 <jonnylamb> Oh, this same code is being used by them to create their ARM debs for the actual devices, right? <lool> Upstream, yes <lool> But the bzr branches is for Ubuntu / Debian <lool> s/is/are <jonnylamb> Of course, sorry I missed the point for a second there! <lool> Time to go to bed it seems <jonnylamb> Okay, so current _debian_ branches are on bzr.debian.org ? <lool> Correct <jonnylamb> And follow the TODO list on the Ubuntu wiki? <lool> Debian branches are catching up on the progress of the Ubuntu branches :) <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 <jonnylamb> Haha, I see! <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? <jonnylamb> s/bit/big/ <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 <jonnylamb> Ah okay. <lool> jonnylamb: Sure, just ask around; people should be nice here :) <jonnylamb> Where would *you* like me to start poking around in the Debian branch? <lool> jonnylamb: What do you run, Debian or Ubuntu? <jonnylamb> Debian! You met me on #gnome-debian, after all! <lool> Hehe, there are plenty of Ubuntu-runners on #gnome-debian :) <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 <lool> If you like, you can try building packages locally from the Debian branches and/or review the existing packages <lool> You should start in the order mce-dev, libosso, libhildon (hildon-1), osso-af-settings, hildon-thumbnail, libhildonmime <lool> You should be able to build all this by bzr co + debuild -i #ubuntu-mobile 2007-06-07 <Mithrandir> the relationship between https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide and https://wiki.ubuntu.com/MobileAndEmbedded/UserInterface is the former is for all apps, while the latter is
{'channel': 'ubuntu-mobile', 'month': 6}