[12:29] if you have no configs the natural layout would be [12:29] ~/bzr/upstream-package-1.ubuntu [12:29] ~/bzr/upstream-package-2.ubuntu [12:29] ~/bzr/upstream-package-1.upstream [12:29] ~/bzr/tarballs/ [12:30] Mhm... [12:30] to safe space you can make a bzr repo out of bzr directory [12:30] in this way bzr/upstream-package-1.upstream and /bzr/upstream-package-1.ubuntu would share the .bzr directory [12:31] but afaik you have to make a repo out of bzr dir before branching initially [12:31] like [12:31] bzr init-repo ~/bzr === Jazzva is lost... [12:31] yeah sorry [12:31] i will stop now [12:31] :) [12:32] No problem... I just need some time to get used to bzr :)... [12:32] sure ... maybe read that again in a few days ;) [12:32] Yeah, I noticed that usually works :)... [12:32] the most unfortunate thing is that bzr builddeb gives you meaningless default error messages too often [12:33] Noticed... A lot of unmet deps :/... [12:33] if you get some error you don't understand its most likely that bzr doesn't find the orig.tar.gz [12:33] ah [12:33] Then I used bzr-buildpackage --builder '...' and everything seemed nice :) [12:33] yes [12:33] it should work without builder [12:34] however your main root needs all depends installed then [12:34] Mhm... === kujub [n=kurt@p549B196D.dip0.t-ipconnect.de] has joined #ubuntu-mozillateam [12:34] anyway ... for signing i have to use --builder as well :) [12:35] Well, I'll try to work it out with --builder option and see if it looks right :). [12:35] sure [12:41] Jazzva: i get lintian warnings when building your package ... maybe you want to look into these as well [12:41] Now running lintian... [12:41] W: gnome-voice-control source: debian-rules-ignores-make-clean-error line 43 [12:41] W: gnome-voice-control: non-standard-dir-in-usr usr/libexec/ [12:41] W: gnome-voice-control: file-in-unusual-dir usr/libexec/voice_control_applet [12:43] Hmm, saw them now... [12:43] Jazzva: why do you ship updated config.sub config.guess in diff? [12:43] is that a glitch or intended? [12:43] Glitch... [12:43] Wait [12:44] There is a part in debian/rules where he updates config.sub and config.guess... debhelper made it and I didn't know it was wrong :/... [12:44] hmm [12:44] ok [12:45] I'll see if config.sub and configu.guess get changed during building and if they don't, I'll delete that part from debian/rules [12:45] Though I suppose they don't... at least they shouldn't... [12:45] Jazzva: you can keep it in debian/rules [12:46] did you keep that diff out of bzr? [12:46] Umm, I don't think I understand the question... [12:47] not important [12:47] its ok to keep it i guess [12:48] But I think it's not needed if config.sub and .guess don't change... [12:48] well they change [12:48] this instruction exists to make porters life easier i guess [12:49] so if you are on debian kbsd you automatically get your architecture infos pulled in [12:49] which might not be merged into mainline autotools [12:49] yet [12:49] Hmm, saving initial c.g and c.s, running configure and make, and then diffing old and new c.g and c.s should show if they change... [12:49] What's kbsd? [12:49] debian with gnu libc + kernel from freebsd [12:49] a port [12:50] Ok. [12:50] So, it should stay in rules then? [12:50] yes keep it [12:50] if you commit config.* updates to bzr, please do so in a separate checkin [12:51] ok i am off for tonight ;) [12:51] sleep [12:51] cu [12:51] First to add debian/* and then config.*? [12:51] yes for instance [12:51] Ok, thanks :)... [12:51] I'll see what I can do with this :). [12:51] Good night [12:51] sure [12:52] thanks === Admiral_laptop [n=Freddy@adsl-68-72-98-66.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam === Admiral_laptop [n=Freddy@adsl-68-72-98-66.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam === red_herring [n=rj@c-24-14-245-251.hsd1.il.comcast.net] has joined #ubuntu-mozillateam === Admiral_laptop [n=Freddy@adsl-68-72-98-66.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-mozillateam === Admiral_Chicago_ [n=FreddyM@adsl-68-72-98-66.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam [02:53] asac: are you back from your weekend getaway? === gnomefreak has work for us to figure out this week sometime. firefox-trunk 20070803 failed to build with an error we had in sunbird i have paste i think, 20070804 failed on trunk-fsh patch [02:57] but i will see you tomorrow if i get a chance im on babysitting duty for next 2 days [02:57] SAVE MEEEEEEEEEEEEEE [02:57] ;) [02:59] gnomefreak: baby sitting is not fun :) [03:45] gnomefreak: Babies can be cool :)... Well, some of them. I hope you had luck... [03:46] As for asac, he's gone to sleep... === Admiral_Chicago_ [n=FreddyM@adsl-68-72-98-66.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam === Admiral_Chicago [n=FreddyM@adsl-68-72-98-66.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam [09:27] well ... here i am :) === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-mozillateam === kujub [n=kurt@p549B320B.dip0.t-ipconnect.de] has joined #ubuntu-mozillateam [12:25] Hey, asac... Good morning :). Got my mail? [12:25] morning [12:26] Jazzva: yes ... whats the question ;) ? [12:26] BTW, if you read it... Can I make an initial release with a patch :)? [12:26] for what? [12:26] for that libexec thing? [12:26] yes, please do a patch [12:26] Uh-huh [12:27] Ok :) [12:27] make it use pkglibdir [12:27] not libexec dir [12:27] but maybe confirm in #ubuntu-desktop where this applet binary has to go [12:27] Will do :)... [12:28] Jazzva: as long as you don't diverge a lot, and you document your changes properly in changelog/bzr commit ... then i am fine if you don't use a patchsystem ... though in general patchsystems are preferred over just carrying changes in the diff.gz [12:29] Well, I read about them... dpatch sounded not so hard, so I meant to use it... [12:30] sure ... maybe use quilt [12:30] i prefer it over every other system [12:30] but its your choice [12:30] maybe use different ones for different packages ... so you find what you like most [12:31] Hmm, ok... Will try :). === Fujitsu [n=fujitsu@ubuntu/member/fujitsu] has joined #ubuntu-mozillateam [12:32] asac: You rang? (re. bug #128116) [12:32] Launchpad bug 128116 in network-manager "NM loops indefinitely with `old_dev has_link? 1' when connecting to one particular network" [Undecided,New] https://launchpad.net/bugs/128116 [12:33] (yes, I have quite some degree of technical skills) [12:34] Hi Fujitsu [12:34] yeah [12:34] Fujitsu: maybe it helps if you set essid manually to "" before you try to connect? [12:36] asac: I'm at home at the moment; I can try in about 12 hours. [12:36] ok [12:36] probably i am in bed then though ;) [12:36] but give it a try [12:37] Will do. [12:37] Thanks for looking into this. [12:40] sure [12:40] need testers :) [12:40] for every chipset i personally don't posess [12:44] If you need anything from me, I can be found in... pretty much any #ubuntu-*, although I mostly sit in -devel and -motu. [12:45] k [12:45] for now testing what i asked would be a good start [12:45] if it doesn't help i would need to do a test session with wpa_supplicant manually et al [12:46] Doing it manually works fine. [01:15] asac: Hmm, I suppose "FATAL: Could not load /lib/modules/2.6.20-16-generic/modules.dep: No such file or directory" reported by bzr-builddeb is no biggie, right? :) (since the package builds and you said that bzr-builddeb will report some error messages) [01:16] Reported when running pbuilder, when the build-deps unpack... [01:24] asac: Configuration requires scrollkeeper-config, which is provided in scrollkeeper package, so I put it as a build-dep. But, then it stays in the final .deb, so I though I should remove it (it's in /var/lib/scrollkeper/). Since it needs it in installed state too, do I need to put it in package deps, or will it be determined with ${misc:Depends}? [03:07] Nevermind... I think I figured that one :). Took a look at deskbar-applet.'s files. [03:11] ok im here im just looking for something atm [03:13] asac: let me know when you have time there are a few things i stated above and there is one thing strange that really bothers me about the 20070803 build [03:14] what is it? [03:15] trunk-fsh is giving me issues but im looking at the failed hunks atm. on the 0803 build debian/tmp was empty [03:16] gnomefreak: well ... did i push something to trunk recently? [03:17] not that i know of extcpt what we did last week or week before [03:18] what was that? [03:19] looking [03:19] i thnk just removing patches and stufff [03:19] i did apply something that was a preview [03:20] if i checked that in then we have troubles [03:20] i fixed the firefox-trunk-install applications.in and freind [03:20] and --disable-airbag [03:21] i see no reason as to why autoconf.mk.in should fail other than removing something that isnt in the file at all [03:21] oh wait [03:21] https://code.launchpad.net/~mozillateam/firefox/trunk [03:28] anyway the 2 hunks failed should apply without problem === gnomefreak not understanding why. the mozilla/unix/Makefile.in should apply since everything in patch is after the endif and endif is last statement in file. so everything is add on. and the autoconf.mk.in looks fairly sane to me there are a few things that might be going wrong but i dont see it applied in patch at all [03:31] applied in file at all [03:31] hmm [03:32] i doubt that patch refuses to apply if the patch applies cleanly :) [03:41] brb smoke [03:41] gnomefreak: i have one more thing todo ... right after uploading a network-manager bomb :) [03:41] then i can look at trunk [03:41] if not today, then tomorrow [03:41] gnomefreak: paradiso doesn't just build right :) ? [03:46] asac: i havent tempted it yet since its the same debian dir im gonna assume no [03:46] maybe thats it [03:47] should not be the same debian dir [03:47] as the trunk contains this funky all-in-wonder-fix-all-make-install patch [03:47] the patch adds stuff to end of the file endif being the end of file and you have what looks like deleted things and added things but there is nothing to delete after endif in file [03:47] which is definitly the reason for the empty debian/tmp dir [03:47] ah ok [03:48] trunk had empty debina/tmp and doesnt have that patch [03:48] but without that patch our future isn't bright [03:48] as you remember ... we just crash ;) [03:48] yes [03:48] i remember :) [03:48] the funny thing about this make install patch is that it works [03:48] if your just run make install DESTDIR=/tmp/somedir [03:48] it will install it properly in that place [03:49] but it doesn't do that for us when run through dpkg-buildpackage -rfakeroot [03:49] ... as a matter of another mystery [03:49] gnomefreak: just try on the failed build tree (where debian/tmp is empty) [03:49] right, could the dpkg-* package have changed in gutsy and thats why it fails [03:49] if you run make install DESTDIR=debian/tmp [03:49] it should be thgere [03:49] i really doubt it [03:49] asac: i dont have one anymore [03:50] its something else wierd going on [03:50] the one that failed i cleaned and changed date for build [03:50] no dies at patches [03:50] now. [03:50] well ... adapt trunk-fsh [03:50] you know how [03:50] goto build-tree/mozilla [03:50] quilt push -f [03:50] fix the conflicts [03:50] quilt refresh --diffstat -U8 [03:50] then see that quilt pop -a [03:51] + quilt push -a works [03:51] if it does [03:51] then just build [03:51] ok after phonecall [03:51] Umm... sorry to get in, but what about DESTDIR=$(CURDIR)/debian/tmp? [03:51] what do you mean? [03:51] (maybe I'm just talking non-sense, though) [03:51] This: if you run make install DESTDIR=debian/tmp [03:51] yeah ... it should be the same [03:52] but we use cdbs for firefox package [03:52] so its just done automagically [03:52] Oh... ok [03:52] :) [03:52] but you see what it runs on command line [03:52] if you run that manually it just works [03:52] but it appears to fail when build through debian/rules [03:53] Don't know CDBS, but you sure it will add $(CURDIR)? (well, it sounds logically to build in current dir) [03:55] asac: By the way, I fixed (probably) all what you said for gnome-voice-control and uploaded :) [03:56] Jazzva: ok i will pull in the background [03:56] asac: Thanks... [03:56] Jazzva: your checkin commands are not really verbose [03:56] makes it hard to review ;) [03:57] just give your commits the credits they deserve by using a verbose commit message next time [03:57] asac: I looked at this deskbar-applet (packaged using CDBS) and it passed "DESTDIR=$(CURDIR)/debian/deskbar-applet" to make [03:57] what did you do to debian/rules? [03:57] asac: Sorry... Will do :) [03:57] i don't see that from comment [03:57] Fixed the "no target to run 'clean'" by adding if [ -f Makefile ] ;... [03:58] And removed the /var/lib/scrollkeeper that gets added [03:58] ok, document that please next time [03:58] Ok... [03:58] as here is the conflict http://pastebin.mozilla.org/182092 looks like the full patch hunk [03:58] Jazzva: you changed the configure line as well? [03:58] asac: Just wanted to say that [03:59] --libexecdir=/usr/lib/... [03:59] Jazzva: thats wrong [03:59] this patch is almost usless without these hunks in it iirc there is only 3 hunks [03:59] Jazzva: please fix the makefile.am [03:59] not the libexecdir [03:59] Hmm, well, that's what I got as advice from pitti :/... [03:59] use pkglibdir instead of libexecdir [03:59] hmm [03:59] When I asked in #ubuntu-desktop... [03:59] hmm [03:59] ok [04:00] maybe --libexecdir is pkglibdir for us by definition? [04:00] no idea [04:00] does cdbs pass that argument as well? [04:01] What do you mean? [04:02] well ... if cdbs passes --libexecdir to configure ... then its fine imo [04:02] Well, it seems to me it would pass to configure if you would add it :/... But I don't know cdbs :) [04:03] yes of course ... i just ment if cdbs passes it by default then its probably policy ... if not its a hack ;) [04:03] Lemme see how they did it in deskbar-applet :) [04:04] right [04:04] Hmm, no mention of "libexecdir" in their debian/rules... [04:04] so ... look in Makefile.am of the applet binary [04:05] how do they define the programs? [04:07] What do you mean? How do they define where it's gonna install? [04:08] will ... in gnome-voic ... [04:08] there is in src/Makefile.am: [04:08] libexec_PROGRAMS = voice_control_applet [04:08] if you change that to pkglib_... it will automatically get installed to proper directory [04:10] No mention of that in deskbar-applet, but they use this: "deskbarbindir = $(libdir)/deskbar-applet" [04:12] hmm [04:12] yeah [04:12] use pkglib then [04:12] e.g. patch Makefile.am [04:12] or keep --libexecdir= ... whatever you want [04:12] i don't really care [04:12] :) [04:13] Umm... well, what's better? :) [04:14] both are equal ... though fixing makefile looks more like the proper solution [04:14] but keep --libexecdir [04:14] ok lets look at the checkin for a minute :) [04:15] http://pastebin.mozilla.org/182097 [04:15] you see how you tackle multiple things in one commit? [04:15] e.g. independent things [04:15] Mhm... [04:15] Oooh, so you wanted me to upload thing by thing :)? [04:16] wish there was an automatic way to resolve conflicts :( can we add that to quilt ;) j/k i know we cant [04:16] For example: edit debian/control - upload - edit debian/rules - upload... Something like that? [04:29] Jazzva: update debian/control debian/bleh and so on than commit debian/control commit debian/bleh and so on than once everything is goo bzr push example sftp://gnomefreak@bazaar.launchpad.net/~jazzva/package/name [04:29] bzr commit [04:29] asac: did you tar up the granparadiso a7 tarball yet? [04:29] for bar bd [04:29] bzr bd [04:29] gnomefreak: Understood... :) [04:29] Jazzva: yes ... distinct commits [04:29] per feature ... as i outlined yesterday ... boosts readability of branch history [04:29] Now I see what you meant yesterday :)... [04:29] this is assuming you have branch made already [04:29] asac: by the looks of it and im not sure how this is but both hunks (autoconf and makefile.in) fail on whole hunks :( [04:29] atleast thats what im seeing pre conflicts [04:29] yes ... merge them [04:29] resolve conflicts et al [04:29] is there an sutomatic way of doing that? [04:29] refresh patches [04:29] sutomatic automatic [04:29] gnomefreak: hehe ... no ... as outlined above ... push quilt patch ... resolve conflicts manually ... refresh [04:29] gnomefreak: you remember ... i am sure ;) [04:29] asac: i do but if whole hunk in patch is failing do i remove that part of patch or add the patch to file [04:29] patch file manually [04:29] see the pastebin link i gave you for one of the outputs (conflicts [04:29] gnomefreak: well ... if the hunk fails you have to ensure that its done upstream now ... otherwise the hunk has to be inserted to proper place [04:29] the parts of the hunk are not in the files that should be patched yet [04:29] quilt push -f [04:29] should bring conflicts in files [04:29] otherwise push just complains [04:29] and it did i pasted one of them for you to see [04:29] http://pastebin.mozilla.org/182092 [04:29] it states it 2 times over [04:29] do i just add the parts with + or all of it as none of it is in file atm [04:34] what is that paste about? [04:34] there isn't any conflict [04:34] can you paste the conflicted file? [04:34] or the parts that conflicts + some context [04:34] gnomefreak: do you see what that hunk does? [04:34] it renames some targets to use -trunk- [04:35] inside [04:35] just quilt push -f [04:35] and use -trunk as well for those that are in the patch [04:37] that is the conflict file [04:37] really? [04:38] yes [04:38] i mean the file itself [04:38] both are like that [04:38] it contains conflicts marked [04:38] look into that [04:38] not the .rej file [04:38] that is the .rej [04:38] yeah ... look in the real file [04:38] k [04:38] do you see those places? [04:38] in that file? [04:39] opening both atm [04:40] ok in the makein.mk file i see some of the lines but the changes are not present [04:40] example makein.mk file ends with libs:: vms/mozilla.com vms/install.com vms/getinfo.com $(INSTALL) $? $(DIST)/bin [04:40] endif [04:41] the .rej file starts with ** 62,125 **** endif [04:41] ifdef MOZ_ENABLE_GTK [04:41] the endif in rej is the last line of the in.mk file [04:41] so none of the lines for that hunk are in the file at akk [04:41] all [04:42] gnomefreak: you have to look in the files that have conflicts [04:42] makein.mk is not known to me [04:42] :) [04:42] makefile.in.mk [04:42] he? [04:42] you mean Makefile.in ? [04:42] yes [04:43] well [04:43] but yes sorry makefile.in [04:43] gnomefreak: is there pkg_config_files [04:43] somewhere in that Makefile.in [04:43] nope just PACKAGE_FILE = unix.pkg [04:44] total file including license is only 56 or 57 lines [04:45] none of the lines http://pastebin.mozilla.org/182092 are in the makefile.in file except the starting endif that is last line in makefile.in [04:46] http://pastebin.mozilla.org/182109 is the full makefile.in [04:46] thats what im not getting how does it fail on something that hasnt been patched upstream if it passed prior to new release [04:47] by the looks of it nothing in the failed hunks has been patched upstream [04:48] gnomefreak: thats obviously the wrong Makefile.in [04:48] asac: its the one the failure gave me [04:48] well .. .what directory is that from? [04:48] build/unix/Makefile.in [04:48] hmmmmmm [04:49] maybe just saw somehting [04:49] but i could be wrong [04:49] nope not what i was thinking [04:50] +++ mozilla/build/unix/Makefile.in2007-07-23 11:53:23.000000000 +0200 [04:50] that is from patch itself [04:50] so from what i can tell its the right file [04:51] is it possible they patched a different file to use your patch? [04:53] if i look in build-tree/mozilla/patches it shows our patches i guess that is when i tried to build it added them [05:02] hmmm [05:06] @schedule new_york [05:06] Schedule for America/New_York: 07 Aug 11:00: Kernel Team | 08 Aug 08:00: Edubuntu | 09 Aug 11:00: Ubuntu Development Team | 10 Aug 00:00: MOTU Team | 11 Aug 13:00: Xubuntu Developers | 14 Aug 11:00: Ubuntu Server Team meeting [05:07] gnomefreak: hmmm ... have you looked in bonsai? [05:07] maybe they have changed that file lately [05:07] no i lost net connection yesterday and forgot to do that today [05:12] hmmmmmm [05:12] makefile.in search within lastweek shows nothing [05:12] atleast not in CVS [05:14] asac: making orig for granparadiso a7 will upload so you can check sanity before i use it to build [05:18] autoconf/mk/in has had 2 changes recently looking at them atm [05:19] asac: hmmmm this is interesting [05:25] hmmmmmm it looks like it changed but im not sure of date [05:26] http://bonsai.mozilla.org/multidiff.cgi [05:26] but no dates [05:26] seems they dont use -trunk anymore [05:35] still doesnt make any sense as the parts they changed our patch -the mozilla line and + our line all is the same by the looks of it, all changes made to autoconf.mk.in are already in the file we have === cwong1 [i=chatzill@nat/intel/x-538148c1b45adcef] has joined #ubuntu-mozillateam [05:35] asac: hi.. [05:36] hmmm [05:36] benjamin%smedbergs.us: -mrelibdir= $(mredir)/lib but our patch keeps that line maybe that would be our conflict [05:37] asac: sorry, I was busy fighting other battles last Thursday and Friday and not being able to sync up with u [05:45] cwong1: hi [05:46] cwong1: yes ... that should be fine [05:46] asac: I ran into a problem with the Patch to nswindows.cpp. It caused a core dump. [05:47] how do you know? [05:47] that its because of that patch? [05:47] asac: I ran it without the pach and the browser works find in the hildon enviorment. [05:47] s/find/fine/ [05:48] and otherwise it crashes? [05:48] asac: yes [05:48] reproducible? [05:48] asac: yes [05:48] but i ran it as well afaik [05:48] hmm [05:48] asac: have u try bring up the about box and then hit the escape key to close it. That should do it for sure. [05:49] does it happen outside hildon as well? [05:49] ha think i fixed it [05:49] asac: I believe so [05:49] ok let me try [05:50]