[09:03] <Mithrandir> MDK: 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
[01:36] <mdz> Mithrandir: hi
[01:40] <Mithrandir> hiya mdz
[01:41] <mdz> Mithrandir: how is hildon-1 coming along?
[01:41] <Mithrandir> I asked kyle to take a look at it last night, I'm not sure if he's done so yet.
[01:41] <Mithrandir> I try not to NEW my own packages.
[01:42] <mdz> let's ask someone more likely to be awake, we've no time to waste
[01:42] <Mithrandir> I'll get seb to do it
[01:42] <mdz> pitti? keybuk? seb128?
[01:42] <mdz> ok
[01:47] <seb128> mdz: pong
[01:47] <Mithrandir> seb128: could you please wave hildon-1 through NEW?
[01:48] <Mithrandir> if it's not too crackful for you
[01:48] <mdz> with review of course :-)
[01:48] <seb128> looking at it now
[01:48] <seb128> mdz: of course ;)
[01:48] <agoliveira> Mithrandir: can you explain to me what you meant by that? I'm not familiar with the local jargon yet ;)
[01:49] <Mithrandir> agoliveira: crackful?  We have a bad habit of referring to various kind of unclean solutions, bugs and such as crack.
[01:49] <Mithrandir> also excessive bling
[01:50] <seb128> Mithrandir: is that "libhildon"?
[01:50] <seb128> (there is no "hildon-1" to NEW)
[01:50] <Mithrandir> sounds right, yes.
[01:50] <Mithrandir> it's called hildon-1 in svn, so I got confused.
[01:51] <agoliveira> Mithrandir: No, sorry, I meant "wave hildon-1 through NEW?"
[01:51] <seb128> Mithrandir: hum, the source package has debian/build full
[01:51] <seb128> looks wrong to me
[01:52] <Mithrandir> seb128: ugh, yes, clean doesn't really clean properly. :-/
[01:52] <Mithrandir> agoliveira: oh, sorry.  NEW is a queue where all new packages (both source and binary) end up for a bit of manual review.
[01:52] <seb128> why is there 3 changelog?
[01:53] <seb128> (you might want to update Maintainer though that's a detail)
[01:53] <Mithrandir> says in the header of the ChangeLog, it's from before it was renamed.
[01:55] <seb128> debian/copyright is minimalistic (no mention of who packaged it, no "On Debian GNU/Linux systems... etc"
[01:58] <seb128> Mithrandir: the package is a has no orig.tar.gz, is that on purpose?
[01:59] <Mithrandir> I'm not sure where the upstream tarballs are stored; it's from an SVN snapshot
[02:01] <seb128> hum
[02:01] <agoliveira> seb128: IIRC, there's no tarballs in there :(
[02:01] <seb128> Mithrandir: 
[02:02] <seb128> $ dpkg -c libhildon1-dev_1.0.5-1ubuntu1_i386.deb | grep 1.so
[02:02] <seb128> lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon-1.so -> libhildon-1.so.0.5.0
[02:02] <seb128> lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon_1.so -> libhildon-1.so
[02:02] <seb128> that's weird
[02:02] <Mithrandir> two copies even
[02:02] <Mithrandir> oh, no, I can't read.
[02:02] <seb128> yes, how come?
[02:02] <seb128> $ dpkg -c libhildon1_1.0.5-1ubuntu1_i386.deb | grep so
[02:02] <seb128> -rw-r--r-- root/root    330988 2007-05-16 13:59 ./usr/lib/libhildon-1.so.0.5.0
[02:02] <seb128> lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon-1.so.0 -> libhildon-1.so.0.5.0
[02:02] <seb128> lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon_1.so.0 -> libhildon-1.so.0
[02:02] <seb128> lrwxrwxrwx root/root         0 2007-05-16 13:59 ./usr/lib/libhildon_1.so.0.0.0 -> libhildon-1.so.0.0.0
[02:03] <seb128> there is one lib using -1
[02:03] <seb128> and one using _1
[02:03] <Mithrandir> yeah, strange, I'll fix those problems then reupload.
[02:03] <seb128> the package is a mess :/ Are the 2 libs required?
[02:03] <seb128> ok, thanks
[02:03] <seb128> the libs duplications and debian/build shipped with the source should be fixed
[02:04] <seb128> out of this the packaging is quite ugly but that's not a stopper
[02:04] <Mithrandir> yes, I agree it's ugly, but it blocks the rest of the stack.
[02:05] <agoliveira> seb128: Don't worry. If you think this one is a mess, wait until you see the others :)
[02:09] <bintut> hello all..
[02:09] <seb128> hi bintut
[02:09] <agoliveira> bintut: hi
[02:10] <bintut> 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..
[02:10] <bintut> hello seb128, agoliveira..
[02:10] <bintut> honestly, i don't have any experience with embedded linux.. i am into big servers..
[02:11] <bintut> but since i have a network appliance here, i want to give it a try..
[02:11] <bintut> i am thinking if it really needs to have a package management for an embedded linux installed to a network appliance
[02:12] <bintut> just like having .deb for debian based system or .rpm for rpm based system
[02:12] <jsgotangco> 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
[02:12] <bintut> does it make sense having a package management on an embedded linux?  what is the plan for this project?
[02:13] <jsgotangco> bintut: hello, how is singapore :)
[02:13] <bintut> jsgotangco: nice..
[02:14] <bintut> anyone here knows the plans for the ubuntu mobile distribution?  will you be using a package management on this distro?
[02:14] <jsgotangco> bintut: for what its worth, ubuntu embedded is starting off with hildon so it gives you a hint about package management
[02:15] <bintut> jsgotangco: what's hildon?
[02:15] <jsgotangco> maemo's UI
[02:17] <bintut> jsgotangco: does this mean that the ubuntu mobile is targeting nokia internet tablet?
[02:18] <agoliveira> bintut: No, the idea is to use in other platforms, initially x86 btw.
[02:20] <bintut> agoliveira: ok.. i have here a via based processor network appliance..
[02:21] <bintut> agoliveira: which is an x86 machine
[02:21] <agoliveira> bintut: So should be no problem when it's done
[02:21] <bintut> agoliveira: are you using the .deb package management for the ubuntu mobile?
[02:22] <agoliveira> bintut: the packages are being created.
[02:22] <agoliveira> bintut: but as it will be a version of Ubuntu, the package management will be the same as usual.
[02:22] <bintut> agoliveira: are you using a package management for the ubuntu mobile?
[02:23] <bintut> agoliveira: ok.. so, that will be a .deb packages
[02:23] <agoliveira> bintut: Yep
[02:24] <bintut> agoliveira: 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?
[02:24] <agoliveira> bintut: this wasn't discussed yet IFAIK.
[02:25] <bintut> agoliveira: i have here a 256mb cf disk..
[02:25] <agoliveira> bintut: actually we don't have much designed yet as the project start last week only.
[02:26] <Mithrandir> one option would be to use jffs or similar and not have / be read-only.
[02:26] <bintut> agoliveira: 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
[02:27] <agoliveira> bintut: not necessarely.There's a lot of differnt ways to do it, deppending on your application.
[02:28] <bintut> because, even apt and it's dependencies eats disk spaces
[02:29] <agoliveira> bintut: Sure. You can also have 2 partitions, one ro and one rw just for that.
[02:29] <bintut> agoliveira: but cfdisk doesn't survive for a frequent write to it
[02:30] <Mithrandir> with a write-levelling file system, that should not be very much of a problem.
[02:31] <bintut> 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
[02:31] <agoliveira> Indeed. It's being some time that cf's have a very good MTBF
[02:32] <Mithrandir> as long as you turn off atime and such you should be fairly good
[02:33] <bintut> anyway, i will subscribe to the mailing list to get an update to this development
[02:33] <Mithrandir> sounds good
[02:33] <agoliveira> 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.
[02:34] <agoliveira> I still have a few around as they we used a lot on PC/104s.
[02:35] <tuxmaniac> Hello gang :-)
[02:35] <agoliveira> tuxmanic: Hi
[02:40] <Mithrandir> tuxmaniac: what are you currently using for the UI layer in your work?
[02:40] <tuxmaniac> Mithrandir, custom widgets
[02:41] <tuxmaniac> Mithrandir, none from the FOSS world. We write widgets from scratch to suit customer requirements
[02:42] <Mithrandir> ahkay, is there interest in changing that?
[02:42] <agoliveira> tuxmanic: using what as base?
[02:42] <agoliveira> tuxmanic: Ah, sorry. I meant if you use something like GTK, Qt, etc.
[02:43] <agoliveira> tuxmaniac: ...X primitives :)
[02:43] <tuxmaniac> agoliveira, no
[02:46] <Mithrandir> seb128: just uploaded a new libhildon, it should make you cry slightly less
[02:46] <seb128> Mithrandir: looking
[02:46] <Mithrandir> cheers.
[03:05] <seb128> Mithrandir: that one looks fine, you ship .bzr to the src though
[03:05] <seb128> Mithrandir: do you want to fix it or should I accept this version?
[03:05] <Mithrandir> yes, I noticed slightly too late, I'll try to remember next time.
[03:05] <seb128> k, I accept it then
[03:10] <seb128> Mithrandir: hum, libhildon1 Depends on osso-sounds-ui which is not available
[03:12] <Mithrandir> I should fix that
[07:42] <MDK> w 45
[07:42] <MDK> err, sorry
[07:43] <MDK> seb128: about the hildon-1 lib mess...
[07:43] <MDK> yes, the '_' symlink is totally useless
[07:44] <MDK> unfortunately, we needed it because of certain integration issues on our side
[07:44] <MDK> you don't want to know more ;)
[07:44] <MDK> in any case, you prolly want to remove it from your build
[07:46] <seb128> we did
[07:46] <seb128> but thanks for the information ;)
[07:46] <ferulo> well MDK you don't want to know details about our python packages :)
[07:46] <MDK> yes
[07:47] <MDK> I dont ;)
[07:49] <tko> I think you guys don't want to know about packaging :)
[07:49] <seb128> MDK: do you plan to look at what we change? or is there a place where you want to get cleanup patches, etc?
[07:50] <MDK> seb128: I'm following your bzr repos
[07:51] <tko> seb128: is there an rss feed to subscribe to?
[07:51] <MDK> seb128: and yes, we're definitelly interested in the changes
[07:51] <tko> MDK: packaging included? :)
[07:51] <seb128> tko: not that I know, but you can look happens in bzr ;)
[07:51] <seb128> +what
[07:51] <MDK> tko: always willing to learn something new ;)
[07:51] <tko> guess I have to do it web1.0 way then
[08:11] <mdz> tko: I thuoght there was an RSS feed available, but can't find it now that I look
[08:12] <tko> mdz: so it wasn't just me then :)
[08:12] <tko> mdz: I found the mail subscription though
[08:15] <mdz> yes, there is that
[09:53] <Mithrandir> MDK: 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.
[09:54] <Mithrandir> MDK: also, do you have release tarballs somewhere?  Having the packages be native ones is inefficient and slightly ugly.
[09:58] <tko> Mithrandir: no, we don't generally do tarball releases
[09:58] <tko> Mithrandir: it's basically just extra overhead since we need debian packages anyway
[09:58] <Mithrandir> hmkay.  It'd be nice for us, but I guess we can make do without them
[09:59] <tko> we know, and we've been talking about doing 'real' upstream maintenance for hildon
[09:59] <tko> but we're big and slow :)
[10:00] <tko> in the early ages I was actually maintaining gtk 'upstream' code and the debian packaging separately and that was just painful
[10:01] <Mithrandir> depends on your VCS, I think
[10:01] <tko> and your debian package, I think.. gtk was in tarball + patches mode
[10:02] <tko> hct to the rescue! (?)
[10:03] <Mithrandir> tarball + patches is utterly crackful.
[10:04] <Mithrandir> 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
[10:05] <tko> when debconf was in finland there was this presentation about the hypothetical packaging tool that would do all the magic...
[10:05] <Mithrandir> yes
[10:05] <Mithrandir> this is an implementation of something along those lines.
[10:06] <tko> oh cool. not that I'd been paying much attention but it kind of seemed to fade away
[10:06] <Mithrandir> you were at dc5?
[10:07] <tko> yep. I live/work close by
[10:07] <tko> used to study at hut
[10:08] <Mithrandir> I was there for NUCCC in, hmm, 2002? and then again for debconf 5
[10:08] <Mithrandir> really nice campus
[10:43] <mdz> Mithrandir: unless the tarballs are large enough that repeated uploads are inconvenient, native seems like the way to go for now
[10:44] <Mithrandir> mdz: agreed, it's more of a nice to have.
[10:45] <mdz> 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
[10:46] <Mithrandir> it's hardly ever impossible to stay native. :-)
[10:46] <Mithrandir> I'm thinking we should avoid having the .bzr in the upload, though I'm not sure about that either.
[10:51] <tko> how inconvient is it to have debian/ directory in upstream? I've understood it's pretty annoying in the tarball, but what about vcs?
[10:55] <Mithrandir> it matters less there, especially with bzr's good merge capabilities.
[11:20] <mdz> Mithrandir: yes, I think we should avoid .bzr in the source tarball
[11:20] <mdz> 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"
[11:27] <Mithrandir> oh well, bedtime.  See you all on Friday since tomorrow is a doubly public holiday here in .no.