User1: User8 you might want to pull http://codebrowse.launchpad.net/~ubuntu-mobile/hildon-1/ubuntu/revision/tfheen%40err.no-20070514124620-1g8ub8curvba3c9w?start_revid=tfheen%40err.no-20070515135628-9qyogkww7ziss69s into upstream hildon-1
User2: User1 hi
User1: hiya mdz
User2: User1 how is hildon-1 coming along?
User1: I asked kyle to take a look at it last night, I'm not sure if he's done so yet.
User1: I try not to NEW my own packages.
User2: let's ask someone more likely to be awake, we've no time to waste
User1: I'll get seb to do it
User2: pitti? keybuk? seb128?
User2: ok
User3: User2 pong
User1: User3 could you please wave hildon-1 through NEW?
User1: if it's not too crackful for you
User2: with review of course :-)
User3: looking at it now
User3: User2 of course ;)
User4: User1 can you explain to me what you meant by that? I'm not familiar with the local jargon yet ;)
User1: User4 crackful?  We have a bad habit of referring to various kind of unclean solutions, bugs and such as crack.
User1: also excessive bling
User3: User1 is that "libhildon"?
User3: (there is no "hildon-1" to NEW)
User1: sounds right, yes.
User1: it's called hildon-1 in svn, so I got confused.
User4: User1 No, sorry, I meant "wave hildon-1 through NEW?"
User3: User1 hum, the source package has debian/build full
User3: looks wrong to me
User1: User3 ugh, yes, clean doesn't really clean properly. :-/
User1: User4 oh, sorry.  NEW is a queue where all new packages (both source and binary) end up for a bit of manual review.
User3: why is there 3 changelog?
User3: (you might want to update Maintainer though that's a detail)
User1: says in the header of the ChangeLog, it's from before it was renamed.
User3: debian/copyright is minimalistic (no mention of who packaged it, no "On Debian GNU/Linux systems... etc"
User3: User1 the package is a has no orig.tar.gz, is that on purpose?
User1: I'm not sure where the upstream tarballs are stored; it's from an SVN snapshot
User3: hum
User4: User3 IIRC, there's no tarballs in there :(
User3: User1
User3: $ dpkg -c libhildon1-dev_1.0.5-1ubuntu1_i386.deb | grep 1.so
User3: lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon-1.so -> libhildon-1.so.0.5.0
User3: lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon_1.so -> libhildon-1.so
User3: that's weird
User1: two copies even
User1: oh, no, I can't read.
User3: yes, how come?
User3: $ dpkg -c libhildon1_1.0.5-1ubuntu1_i386.deb | grep so
User3: -rw-r--r-- root/root    330988 2007-05-16 13:59 ./usr/lib/libhildon-1.so.0.5.0
User3: lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon-1.so.0 -> libhildon-1.so.0.5.0
User3: lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon_1.so.0 -> libhildon-1.so.0
User3: lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon_1.so.0.0.0 -> libhildon-1.so.0.0.0
User3: there is one lib using -1
User3: and one using _1
User1: yeah, strange, I'll fix those problems then reupload.
User3: the package is a mess :/ Are the 2 libs required?
User3: ok, thanks
User3: the libs duplications and debian/build shipped with the source should be fixed
User3: out of this the packaging is quite ugly but that's not a stopper
User1: yes, I agree it's ugly, but it blocks the rest of the stack.
User4: User3 Don't worry. If you think this one is a mess, wait until you see the others :)
User5: hello all..
User3: hi bintut
User4: User5 hi
User5: i'm thinking of installing an embedded linux on my network appliance but i don't know what distribution to use, package management to use, etc..
User5: hello seb128, agoliveira..
User5: honestly, i don't have any experience with embedded linux.. i am into big servers..
User5: but since i have a network appliance here, i want to give it a try..
User5: i am thinking if it really needs to have a package management for an embedded linux installed to a network appliance
User5: just like having .deb for debian based system or .rpm for rpm based system
User6: ogra actually managed to install edubuntu in an intel classmate PC i guess that can be dscribed roughly as embedded as well, but on a different note
User5: does it make sense having a package management on an embedded linux?  what is the plan for this project?
* bintut waves to jsgotangco
User6: User5 hello, how is singapore :)
User5: User6 nice..
User5: anyone here knows the plans for the ubuntu mobile distribution?  will you be using a package management on this distro?
User6: User5 for what its worth, ubuntu embedded is starting off with hildon so it gives you a hint about package management
User5: User6 what's hildon?
User6: maemo's UI
User5: User6 does this mean that the ubuntu mobile is targeting nokia internet tablet?
User4: User5 No, the idea is to use in other platforms, initially x86 btw.
User5: User4 ok.. i have here a via based processor network appliance..
User5: User4 which is an x86 machine
User4: User5 So should be no problem when it's done
User5: User4 are you using the .deb package management for the ubuntu mobile?
User4: User5 the packages are being created.
User4: User5 but as it will be a version of Ubuntu, the package management will be the same as usual.
User5: User4 are you using a package management for the ubuntu mobile?
User5: User4 ok.. so, that will be a .deb packages
User4: User5 Yep
User5: User4 basically, embedded devices runs on a read only mode.. any idea on how will the embedded devices be able to update the packages if in case there will be an update to a certain package?
User4: User5 this wasn't discussed yet IFAIK.
User5: User4 i have here a 256mb cf disk..
User4: User5 actually we don't have much designed yet as the project start last week only.
User1: one option would be to use jffs or similar and not have / be read-only.
User5: User4 i was also thinking of adopting the openembedded project but i was confused if i have to use a package management or not since what i think is that whenever you apply the updates to your embedded device, you have to re-flash your cfdisk
User4: User5 not necessarely.There's a lot of differnt ways to do it, deppending on your application.
User5: because, even apt and it's dependencies eats disk spaces
User4: User5 Sure. You can also have 2 partitions, one ro and one rw just for that.
User5: User4 but cfdisk doesn't survive for a frequent write to it
User1: with a write-levelling file system, that should not be very much of a problem.
User5: unless, using a host machine with a bootstrap to build the embedded OS first then from there dd the image to a cfdisk in such a way to update the system itself
User4: Indeed. It's being some time that cf's have a very good MTBF
User1: as long as you turn off atime and such you should be fairly good
User5: anyway, i will subscribe to the mailing list to get an update to this development
User1: sounds good
User4: A few years ago there was (is?) a special kind of CF called DiskOnChip that has an special hardware-level levelling system but I think most of the cf's today have it as well.
User4: I still have a few around as they we used a lot on PC/104s.
User7: Hello gang :-)
User4: tuxmanic: Hi
* tuxmaniac is Aanjhan working in a German MNC in INDIA as a Embedded Software developer, an ardent Ubuntu fan. Main job at workplace is to interface mobile devices with the Automotive Multimedia Devices. Hope I can contribute to this project initiated by the Ubuntu Community
User1: User7 what are you currently using for the UI layer in your work?
User7: Mithrandir, custom widgets
User7: Mithrandir, none from the FOSS world. We write widgets from scratch to suit customer requirements
User1: ahkay, is there interest in changing that?
User4: tuxmanic: using what as base?
User4: tuxmanic: Ah, sorry. I meant if you use something like GTK, Qt, etc.
User4: User7 ...X primitives :)
User7: agoliveira, no
User1: User3 just uploaded a new libhildon, it should make you cry slightly less
User3: User1 looking
User1: cheers.
User3: User1 that one looks fine, you ship .bzr to the src though
User3: User1 do you want to fix it or should I accept this version?
User1: yes, I noticed slightly too late, I'll try to remember next time.
User3: k, I accept it then
User3: User1 hum, libhildon1 Depends on osso-sounds-ui which is not available
User1: I should fix that
* bintut waves to all... gtg now..
* tko adds one more channel to the idle list :)
User8: w 45
User8: err, sorry
User8: User3 about the hildon-1 lib mess...
User8: yes, the '_' symlink is totally useless
User8: unfortunately, we needed it because of certain integration issues on our side
User8: you don't want to know more ;)
User8: in any case, you prolly want to remove it from your build
User3: we did
User3: but thanks for the information ;)
User9: well MDK you don't want to know details about our python packages :)
User8: yes
User8: I dont ;)
User10: I think you guys don't want to know about packaging :)
User3: User8 do you plan to look at what we change? or is there a place where you want to get cleanup patches, etc?
User8: User3 I'm following your bzr repos
User10: User3 is there an rss feed to subscribe to?
User8: User3 and yes, we're definitelly interested in the changes
User10: User8 packaging included? :)
User3: User10 not that I know, but you can look happens in bzr ;)
User3: +what
User8: User10 always willing to learn something new ;)
User10: guess I have to do it web1.0 way then
User2: User10 I thuoght there was an RSS feed available, but can't find it now that I look
User10: User2 so it wasn't just me then :)
User10: User2 I found the mail subscription though
User2: yes, there is that
User1: User8 if you're happy with just pulling patches out of our bzr branch, that's great.  If you prefer to get them some other way, tell us so we can post them to bugzilla, etc.
User1: User8 also, do you have release tarballs somewhere?  Having the packages be native ones is inefficient and slightly ugly.
User10: User1 no, we don't generally do tarball releases
User10: User1 it's basically just extra overhead since we need debian packages anyway
User1: hmkay.  It'd be nice for us, but I guess we can make do without them
User10: we know, and we've been talking about doing 'real' upstream maintenance for hildon
User10: but we're big and slow :)
User10: in the early ages I was actually maintaining gtk 'upstream' code and the debian packaging separately and that was just painful
User1: depends on your VCS, I think
User10: and your debian package, I think.. gtk was in tarball + patches mode
User10: hct to the rescue! (?)
User1: tarball + patches is utterly crackful.
User1: I'm hoping we'll have the necessary infrastructure to make working with something a bit like tarball + patches, but without the pain (basically, orig tree + feature branches + integration branch) soon
User10: when debconf was in finland there was this presentation about the hypothetical packaging tool that would do all the magic...
User1: yes
User1: this is an implementation of something along those lines.
User10: oh cool. not that I'd been paying much attention but it kind of seemed to fade away
User1: you were at dc5?
User10: yep. I live/work close by
User10: used to study at hut
User1: I was there for NUCCC in, hmm, 2002? and then again for debconf 5
User1: really nice campus
User2: User1 unless the tarballs are large enough that repeated uploads are inconvenient, native seems like the way to go for now
User1: User2 agreed, it's more of a nice to have.
User2: in fact I think it's preferable to stay native if possible, since all you need is the bzr repository, no need to find and fetch the tarball in order to do an upload
User1: it's hardly ever impossible to stay native. :-)
User1: I'm thinking we should avoid having the .bzr in the upload, though I'm not sure about that either.
User10: how inconvient is it to have debian/ directory in upstream? I've understood it's pretty annoying in the tarball, but what about vcs?
User1: it matters less there, especially with bzr's good merge capabilities.
User2: User1 yes, I think we should avoid .bzr in the source tarball
User2: I use DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\{arch\}|\.arch-ids|\.arch-inventory|\.bzr|\.bzrignore|\.shelf)(?:$|/)' -ICVS -I.svn -I\{arch\} -I.arch-ids -I.arch-inventory -I.bzr -I.bzrignore -I.shelf -uc -us"
User1: oh well, bedtime.  See you all on Friday since tomorrow is a doubly public holiday here in .no.
ubuntu-mobile
Ubuntu IRC