[00:03] <asac> i wish i could finally upgrade to intrepid :)
[00:03] <fta> asac, why ? and why can't you ?
[00:06] <asac> still 8.04.1
[00:06] <asac> voluntold
[00:06] <asac> ;)
[00:07] <asac> fta: the prism build system ... whats the sate?
[00:07] <asac> state
[00:07] <asac> is it usable for other xul apps already?
[00:09] <fta> i don't remember where i left it. i changed the build system for the new mozclient
[00:09] <fta> i pushed my last changes with a comment "It's still a work-in-progress"
[00:11] <asac> fta: is latest build system in prism branch?
[00:11] <asac> or somewhere else?
[00:12] <fta> it's in, but still not called. I needed to finish updating the packaging 1st, but i was in a hurry, so i committed that as it was.. then i forgot to return to it
[00:13] <asac> k
[00:13] <asac> ill look at it briefly now ;)
[00:14] <asac> where is prism maintained?
[00:15] <asac> we use full-source bzr trees for it?
[00:15] <asac> my setting up a sync or something
[00:15] <asac> s/my/by/
[00:17] <asac> fta: can you set mozillateam as driver for prism project in LP?
[00:17] <asac> https://edge.launchpad.net/prism
[00:18] <fta> done
[00:18] <asac> thx
[00:19] <asac> fta: http://svn.mozilla.org/projects/webrunner/trunk/ thats the tree?
[00:19] <fta> damn, DebianImportFreeze next week; so soon
[00:19] <fta> yes
[00:20] <asac> fta: well. given that debian is in essential freeze already, I dont think its a great loss
[00:21] <fta> there are tons of merges pending, noone seems interested
[00:23] <asac> fta: yeah we got harangued about that just in the meeting :)
[00:24] <fta> asac, as for prism, let me finish the build system and put the package back in shape. if you want to help, i'd prefer you spend your time on the missing bits (desktop env and such)
[00:24] <asac> fta: yeah ... i want to get that build system ripped out somehow
[00:25] <asac> wonder how that can be best achieved
[00:25] <fta> ripped out ?
[00:25] <asac> shipped independent in a way that xul apps that need mozilla build system can just be build without duplicating it
[00:26] <fta> could be part of xul sdk
[00:26] <asac> rememeber that windows folks dont really have a concept of -dev packages ... so xul apps usually will build in full xulrunner source
[00:26] <asac> we dont want that obviously
[00:26] <asac> fta: thats my idea
[00:27] <asac> the lamest answer would be to ship it as a bzr directory tarred up or something in /usr/share/xulrunner-devel-1.9/
[00:27] <asac> or we just provide it as a merge base in bzr
[00:28] <asac> fta: we could also ship it just as a directory tree ... and provide cdbs like make rules that do the magic
[00:28] <asac> like copying over the configure :(
[00:29] <asac> i face(d) the same problem with enigmail
[00:29] <asac> but never really came to fixing it
[00:30] <fta> it's a mess atm. we need most of build/* and config/* but those files are heavily dependents on variables from configure.. and configure is project specific
[00:30] <asac> yeah
[00:30] <asac> but thats how it is :)
[00:30] <asac> maybe we can do some magic so build/ and config/ reside somewhere else :)
[00:31] <asac> fta: what is still project specific in configure?
[00:32] <asac> i see that you need to patch configure if you need new build deps
[00:33] <asac> fta: anyway. lets first get the initial build system ready in prism
[00:33] <fta> there are far too many deps in the main configure
[00:34] <asac> fta: but arent the normal deps that xulapps need more or less fixed?
[00:34] <fta> and some deps are missing too, for ex clucene if we xulify flock
[00:36] <fta> or media / media-core if we xulify songbird
[00:36] <asac> i think we work for 3.1 here. so we could help improving the main configure.in if that is what we really want
[00:37] <asac> xul apps could provide .m4 files or something
[00:37] <fta> and why would all those xulapps need to drag gnome, gtk, hal/dbus and friends ?
[00:37] <asac> if they need non-default deps
[00:39] <asac> fta: do you have a built biuld-tree on your disk?
[00:39] <fta> eh?
[00:40] <asac> fta: i think the base requirements of xulrunner are ok to be dragged in
[00:40] <asac> OTOH ... hmm
[00:41] <fta> prism used to have no binary to build at all (before 0.9), build-deps were really small
[00:45] <asac> fta: please run a find -type d on dist/include/ in a build tree
[00:45] <asac> why is our top level include dir of xulrunner not structured like that?
[00:46] <asac> thats one of the requirements to allow mozilla build system to include headers dependeing on REQUIRES in Makefile.in for instance
[00:47] <asac> fta: is it that we deliberately replace that directory after make install with a link ... or is that structure not shipped at all by make install?
[00:47] <fta> that's not one of our changes, it's the default make install
[00:48] <asac> right ... i knew that they do some linking ... but i think we do _more_ linking somewhere
[00:48] <asac> or is it just the bin/ directory that we re-linked?
[00:48] <asac> but good
[00:49] <asac> we probably should look into it. /usr/include/ hierarchy should stay like now though as its much better for pkg-config style build systems that way
[09:58] <fta> asac, strange, all my intrepid builds failed yesterday: https://edge.launchpad.net/~fta/+archive/+builds?build_text=&build_state=all
[09:58] <fta> asac, but they are fine locally
[09:59] <asac> fta: flock succeeded 7 h ago
[09:59] <fta> nope, it's hardy
[09:59] <asac> ah
[10:01] <fta> quilt?
[10:01] <asac> fta: maybe ... or maybe the tarball is empty?
[10:01] <asac> fta: consider to push the retry button
[10:02] <asac> hmm ... only /dev/null patches failed, right?
[10:02] <asac> fta: maybe your .diff.gz contains the removal of those?
[10:08] <fta> it's something else: http://launchpadlibrarian.net/15421359/buildlog_ubuntu-intrepid-i386.xulrunner-1.9.1_1.9.1~a1~hg20080618r15424%2Bnobinonly-0ubuntu1~fta1_FAILEDTOBUILD.txt.gz
[10:09] <Wellark> asac: ping
[10:09] <Wellark> I'm not working on nm 0.7 directly. atleast not at the moment
[10:10] <Wellark> I'm creating mobile broadband configuration assistant for NM, see www.kaijanmaki.net/blog for more information
[10:13] <Wellark> I'm doing standalone development currently, but NM integration begins on week 30
[10:21] <asac> Wellark: so you are Antii ?
[10:21] <Wellark> asac: yes.
[10:21] <asac> Wellark: great to meet you!
[10:22] <Wellark> happy to meet you, too!
[10:22] <asac> Wellark: how can we leverage your configuration assistant?
[10:22] <asac> e.g. how does it play together with NM 0.7
[10:23] <Wellark> it's supposed to be integrated with NM 0.7 starting from week 30
[10:23] <asac> Wellark: so upstream?
[10:23] <Wellark> yes.
[10:23] <asac> in Dan's svn?
[10:23] <asac> oh cool
[10:24] <asac> Wellark: what state is it?
[10:24] <asac> is it backend only or UI too?
[10:24] <Wellark> I'm working with the UI currently.
[10:24] <Wellark> it's still in heavy developement
[10:25] <Wellark> there is nothing you can test, yet.
[10:25] <asac> Wellark: oka
[10:25] <asac> y
[10:26] <fta> asac, it's no longer moving to build-tree for embedded tarballs. seems like a cdbs issue
[10:27] <Wellark> asac: after couple of weeks there will be a test run of the assistant itself, without NM..
[10:28] <fta> asac, nope, quilt. I have 0.46-4.1, the builder has 0.46-5
[10:29] <asac> Wellark: so its a standalone application right now?
[10:30] <asac> fta: yeah.
[10:30] <Wellark> asac: yes, because of the early state of development
[10:31] <asac> Wellark: is there a feature document or roadmap?
[10:32] <asac> projectplan?
[10:32] <asac> (found th elink)
[10:33] <Wellark> project plan is downloadable through my blog (there's link on side panel)
[10:33] <Wellark> Appendix B has the development schedule
[10:37] <Wellark> and then there is this site: http://live.gnome.org/NetworkManager/MobileBroadband
[10:38] <asac> Wellark: so will the assistant also cover "update/modify" config use-case or just "new" config?
[10:40] <asac> otherwise looks great
[10:40] <Wellark> update/modify will be done using the standard connection editor
[10:41] <fta> debian bug 485835
[10:41] <asac> will yo uallow the user to select whether he has a flatrate subscription so NM can auto roam to 3g?
[10:41] <Wellark> this assistant only provides an easy and automated way of filling the needed information
[10:41] <ubottu> Debian bug 485835 in quilt "please do not run quilt in $(DEB_SRCDIR)" [Normal,Closed] http://bugs.debian.org/485835
[10:41] <asac> Wellark: ok
[10:41] <asac> Wellark: imo the facilities should also be included in the connection editor panel
[10:41] <asac> e.g. selecting providers by country
[10:42] <Wellark> well, that's one possibility.
[10:44] <asac> fta: so that change breaks tarball.mk builds?
[10:44] <fta> yes, badly
[10:44] <asac> does cdbs use DEB_SRCDIR?
[10:44] <fta> we do
[10:45] <fta> debian bug 485142
[10:45] <fta> debian bug 485163
[10:46] <ubottu> fta: Error: Could not parse data returned by Debian: timed out (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485142;mbox=yes)
[10:46] <fta> lol
[10:46] <ubottu> fta: Error: Could not parse data returned by Debian: timed out (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485163;mbox=yes)
[10:46] <asac> debian is down
[10:46] <asac> i cannot get the mbox thing
[10:47] <fta> * patchsys-quilt.mk: don't try to apply patches in $(DEB_SRCDIR) but in
[10:47] <fta>     current directory. This is best for compatibility with the upcoming "3.0
[10:47] <fta>     (quilt)" source package format and the two only packages which are
[10:47] <fta>     affected by this change have already been fixed (see #485142, #485163).
[10:47] <fta>     Closes: #485835
[10:47] <asac> fta: we do?
[10:47] <asac> by accident?
[10:47] <fta> no, we need to for embedded tarballs
[10:47] <asac> yeah
[10:47] <asac> well its a cdbs thing i think
[10:48] <fta> yes
[10:48] <fta> patchsys-quilt.mk from quilt is a cdbs thing
[10:48] <fta> so now, we need to redo all our patches from curdir :(
[10:49] <asac> na
[10:49] <asac> thats a bug
[10:49] <fta> that's bullshit :(
[10:49] <asac> i mean they breach cdbs
[10:49] <fta> https://edge.launchpad.net/ubuntu/intrepid/+source/quilt/0.46-5
[10:51] <asac> fta: can you paste the new patchsys-quilt.mk somwhere?
[10:51] <fta> i need to update-n-break my chroot
[10:52] <asac> i think hte real fix is to add a new variable DEB_QUILT_BASEDIR ?= $(CURDIR) ... so we can override it
[10:52] <asac> imo we should go back to
[10:53] <asac> DEB_SRCDIR and the two guy who asked fr that change should use DEB_QUILT_BASEDIR
[10:53] <fta> http://paste.ubuntu.com/21352/
[10:59] <asac> Wellark: so good news is that we will get 0.7 in intrepid
[11:00] <asac> Wellark: upload should happen in 1 week i hope ... from there i on we will certainly ride the trunk development as we want all fixes :)
[11:00] <asac> Wellark: so the freeze that brought up this isnt relevant for your work
[11:01] <asac> everything that is in that is worthwhile to have till august, will be in release
[11:01] <asac> Wellark: we have a bunch of 3G independent things to do still, so if you want to help you are welcome :)
[11:02] <Wellark> asac: great! if everything goes well, the assistant is solid by the FeatureFreeze
[11:02] <asac> Wellark: rock
[11:02] <asac> Wellark: do you know when 0.7 is supposed to be final?
[11:02] <asac> (realistically speaking i mean)
[11:02] <Wellark> no, sorry.
[11:02] <asac> doesnt matter most likely anyway
[11:03] <asac> (for us)
[11:03] <asac> 0.6.6 has to go
[11:03] <asac> thats for sure
[11:03] <Wellark> yes. the relevent question is "when will NM 0.7 be maintainable"
[11:19] <asac> Wellark: maintainable in which way?
[11:22] <Wellark> never mind. :)
[11:32] <gnomefreak> asac: what package would this be filied under? occurs only with wireless connection with the mode wpa2-personal (AES),
[11:34] <asac> gnomefreak: most likely the driver package
[11:34] <asac> what chipset is it?
[11:34] <gnomefreak> he doesnt say
[11:34] <gnomefreak> it on the hotmail login bug i want him to file a new report with all info sice he can login with wired but not wireless
[11:34] <asac> we need a full syslog then (taken after he reproduced this issue=
[11:37] <gnomefreak> thanks update him on bug report
[11:58] <fta2> asac, if you have time to fix quilt, feel free
[12:00] <rzr> hi
[12:01] <rzr> I am about to release a debian package (in sid)
[12:01] <rzr> and will import it in intrepid
[12:01] <rzr> I was wondering if I can Use the LP:# hook in debian/changelog
[12:02] <rzr> errm
[12:02] <rzr> I meant If I can mix Debian Closes and Ubuntu LP: in the same release
[12:02] <rzr> am I clear ?
[12:36] <fta2> asac, the idea of DEB_QUILT_BASEDIR is not backward compatible. I don't think this regression is a valid reason to fork the branches between hardy and intrepid
[12:36] <fta2> or to stop doing debs for hardy
[12:37] <asac> fta2: my idea is to make DEB_QUILT_BASDIR=$(DEB_SRCDIR) by default and let the other projects that really need to patch outside fix it on their own
[12:54] <fta2> asac, basically, that would mean reverting http://git.debian.org/?p=collab-maint/quilt.git;a=commitdiff;h=ae6bc12cf0d4ebffc2563074843b3e4ee59ca71b and asking the 2 guys to set DEB_SRCDIR to CURDIR
[12:57] <asac> fta2: yes, but replace DEB_SRDIR with QUILT_SRDIR
[12:58] <asac> and then using QUILT_SRCDIR ?= $(DEB_SRCDIR)
[12:58] <asac> with DEB_SRCDIR ?= .
[13:16] <asac> s/2 guys to set DEB_SRCDIR/2 guys to set QUILT_SRCDIR/
[13:17] <fta2> i've fixed it in my ppa so i can retrigger the builds. http://paste.ubuntu.com/21374/
[13:18] <fta2> http://paste.ubuntu.com/21375/
[13:19] <asac> fta2: thats also in icedove i guess, right?
[13:19] <asac> fta2: ugh
[13:19] <asac> i have DEB_TAR_SRCDIR
[13:19] <asac> why dont we have that in the other packages?
[13:20] <asac> we should go for that
[13:20] <asac> if it stil lworks :)
[13:21] <asac> so it doesnt break embedded tarball builds, but just cdbs + quilt + unpacked sources with top level dir?
[13:21] <fta2> http://paste.ubuntu.com/21377/
[13:21] <asac> yeah ... xul should even work with the "embedded" tarball code we have there
[13:22] <fta2> it does
[13:39] <asac> @time
[14:06] <fta2> https://edge.launchpad.net/~ubu4ever/+archive/+build/643728  ???
[14:19] <fta2> http://hackademix.net/2008/06/19/firefox-3-untimely-security-advisory/
[14:28] <armin76> rofl
[14:30] <armin76> asac: thoughts about the bug i filed? mozilla bug 440075
[14:42] <asac> armin76: not sure :)
[14:43] <asac> requires to look in the code
[14:43] <asac> not sure how those clipboard things are handled differently
[14:43] <asac> maybe its because in one case its just ascii content and in the other its of content type URL or something
[14:43] <asac> but wel ... thats not really concrete enough to go anywhere
[14:48] <fta2> the intrepid amd64 ppa builders are fucked up, badly
[17:13] <rzr> hi
=== fta_ is now known as fta