[00:14] bug 331841 [00:14] Launchpad bug 331841 in gwibber "Please bump the gwibber version in both branches" [Undecided,New] https://launchpad.net/bugs/331841 [11:38] james_w: help ... do you know this: http://paste.ubuntu.com/120546/ [11:38] major breakage ;9 [11:38] is that builddeb doing that to me? [11:39] oh loom [11:39] yeah, upgrade loom [11:39] reading NEWS.Debian for the update of bzr-builddeb is probably a good idea for you [11:39] james_w: i am up-to-date in jaunty [11:39] it's not in jaunty is it? [11:40] james_w: not sure ... i had a package installed. thought it was from archive [11:40] james_w: yes. i will look in NEWS. i had to downgrade builddeb [11:40] on my other system [11:40] why? [11:40] seems it doesnt understand --export-upstream* properly anymore [11:40] in jaunty [11:40] let me look in NEWS [11:41] yeah [11:41] it's gone away [11:41] because it was broken [11:41] james_w: it worked well for me (finally) [11:41] i used merge = TRue [11:41] and export-upstream-revision= [11:41] (but not export-upstream) [11:42] so when i needed tarball i could specify --export-upstream=. [11:42] keeping stuff with warning for one cycle would be nice ;) [11:42] err [11:42] could you tell me a bit more about what you wanted to do with it, then I can make builddeb work better for you [11:43] james_w: i just want to have info to produce upstream tarballs on the fly in my try [11:43] yeah, I would have liked to have done that, but using it would just lead to trouble [11:43] tree [11:43] just like i had with --export-upstream= [11:43] ok [11:43] (i filed a bug about that ... which would have made that perfect for me) [11:43] but now i migrated a bunch of branches there [11:43] and the feature is gone [11:44] i have 2.1~0ubuntu1 [11:44] and bzr help builddeb still tells me about --export-upstream [11:44] https://bugs.edge.launchpad.net/bzr-builddeb/+bug/317111 [11:44] Ubuntu bug 317111 in bzr-builddeb "export-upstream should not export upstream tarball when a proper orig.tar.gz is available from other sources" [High,Fix committed] [11:44] that's yours [11:44] yeah [11:44] I think I know how to fix your case [11:45] I kind of forgot about merge mode [11:45] james_w: well. currently export-upstream seems to be broken [11:45] or removed (according to you) [11:46] ok the initial issue i had with bzr st is gone ... seems it was intermediate while upgrades were running [11:46] I think adding an "export-upstream" command is the way to fix this [11:46] james_w: my branches are not always full sources [11:47] james_w: i cannot use merge-upstream [11:47] then you can invoke that as you like, without having to first find the combination of configuration options that makes it work for you [11:47] e.g. i used it for the new network manager branches [11:47] which are just debian tree [11:47] worked great [11:47] sure [11:47] I want to fix it [11:47] so i could easily still the right revision into the tree [11:47] ok [11:47] so what should i do for now? [11:47] making this change made merge-upstream much much better, so I don't regret it [11:47] hold back the upgrade? [11:47] give me a few hours? [11:48] sur3e [11:48] sure [11:48] ;) [11:48] I'll include the command in the next upload [11:48] james_w: can you still honour the export-upstream-revision = config? [11:48] as you were essentially simulating such a command [11:48] that would be great [11:48] i adde that info now in a bunch of branches [11:48] my current thought is this [11:48] upstream-branch = foo [11:49] to allow it to be remembered [11:49] ok [11:49] bzr export-upstream [BRANCH] [11:49] and the revision? [11:49] which takes a -r option [11:49] and creates a tarball for you [11:49] can you support legacy support for my config? [11:50] I didn't want to support legacy in that upload, as it would have led to odd behaviour [11:50] but I imagine I can in this upload [11:50] james_w: its just the -revision info that i want [11:50] i didnt add export-upstream = in most cases [11:50] why do you want it to be stored in the config file? [11:50] james_w: because then the branch is mostly self maintained [11:50] i want to commit the revision info right in the tree when i bump changelog [11:51] got it [11:51] seems like a valid use case [11:51] great ;) [11:51] let me think about it for a bit [11:51] I want to see if we can make it work even better for you [11:52] would you want it to change the changelog at all? [11:52] not by default it seems [11:53] but perhaps an option to write the revision to the config file and bump the changelog would be nice [11:53] james_w: would be ... but its not required. [11:53] sure [11:53] james_w: maybe if i do bzr merge [11:53] but for debian only trees [11:53] i dig the revision info on my own anyway [11:53] I'll get it working for you first, then we can make it better [11:53] (its usually not the tip) [11:54] bzr export-upstream --remember-revision -r 246 BRANCH [11:54] james_w: i want to publish the revision info [11:54] so i would probably need a bzr commit after that? [11:55] yeah [11:55] for me the revision is tightly associated with the current tree [11:55] so its not somethig i just want locally (like parent branch) [11:55] that would write the revision id to the config file, and also add a new changelog stanza [11:55] hmm [11:55] not sure it's the right thing though [11:55] james_w: we could do that. [11:56] but i usually i just open new changelog upstream revision [11:56] and document the revision change in the same commit [11:56] like "* new upstream snapshot (revid:xxxx) [11:56] "open new changelog upstream revision" what does that mean? [11:56] - update .bzr-builddeb/default.conf [11:56] " [11:56] yeah [11:56] james_w: yes, but everybody has his own format for that [11:57] if we can standardize that it would be great [11:57] merge-upstream does things like this for you in full source mode, so having it for merge mode may help you [11:57] sometimes i say: "new upstream snapshot" ... but on other times i say : "new upstream release xxx" [11:57] but I'll leave all that for later improvements, and fix it for you first [11:57] yeah. [11:57] just tell me when there is something to test for me ;) [11:58] sure [11:58] i can then see how it feels [11:58] and complain or cheer ;) [11:58] are you happy to test from bzr? [11:58] why not [11:58] k, makes it easier for me :-) [11:58] if i can just branch it in .bazaar/plugins [11:58] its good [11:58] yeah [11:58] do .bazaar/plugins checkouts win over global things? [11:58] or does it check for higher version when having conflicting plugins? [11:58] (just curious) [11:58] .bazaar/plugins wins [11:59] good [11:59] so even if its lower [11:59] thats the same for mozilla [11:59] thought a bit whether it would make sense to chnage that [11:59] but probably profile should win [11:59] I'll need an FFe for this, so I'll report a bug later you can make some noise on [12:00] james_w: heh. you could even make bzr bd try export-upstream [12:00] when the other download options fail ;) [12:00] just an idea [12:00] james_w: its regression bug [12:00] not sure if that needs a FFe [12:00] ;) [12:00] :-) [12:01] but well i can state that in the bug [12:01] "all my magic branch wizardry broke" ;) [12:01] perhaps you are right about bd [12:01] having it beat the other options was definitely the wrong thing [12:01] yeah. i think woudl be elegant. e.g. factor out export-upstream to its own clean operation and then make use of it [12:02] if there is not arball [12:02] however, it can lead to problems anyway [12:02] that's the reason it's gone really [12:02] sure. but in most casese you have the archives you will upload to in your sources [12:02] if not you have to figure on your own [12:02] it was too easy to shoot yourself in the foot [12:02] I'll consider it though [12:02] yeah ;) [12:02] the solution was not to add export-upstream = . [12:02] to default.conf [12:03] and only run --export-upstream if you didnt find a tarball [12:03] worked well ;) [12:03] but it also fails in that a -2 upload won't be accepted [12:04] if the .orig.tar.gz was from export-upstream the second time [12:04] it's harder to hit now that it doesn't overwrite [12:04] but it is still an issue [12:04] but anyway, everyone should use full source branches and merge-upstream anyway :-) [12:05] hehe [12:05] james_w: the main problem is what i had now [12:05] james_w: upstream moves branches and then you can trash everything [12:06] james_w: so i went back to debian only tree for NM [12:06] just sounds more "long-term sustainable" [12:06] unfortunately i must admit [12:06] "upstream moves branches" [12:06] what do you mean by that? [12:06] yes. NM main branch went to git [12:06] and the openvpn branches were moved to their own svn tree [12:07] ah, so all revision ids changed [12:07] yes [12:07] and the svn -> git migration was a lethal injection obviously [12:07] with no proper bzr-git yet [12:09] james_w: that reminds me of the git archive issue [12:10] james_w: currently i cannot use git archive to produce tarballs [12:10] that one is fixed :-) [12:10] because bzr bd sees a file on top [12:10] ah good [12:10] maybe i didnt see because i downgraded [12:10] yeah [12:10] before trying to use that kind of tarball [12:10] greawt then ;) [12:22] asac, what java plugin is good on amd64? i'm fighting remotely with a dead server and the admin web site in that IBM box needs java. I can't access it from home so i need to setup java remotely on a trusted desktop [12:24] fta: i dont think there is much choice [12:24] use the latest ice tea thing ... [12:25] there is no java plugin with javascript integration though (e.g. oij) [12:25] so if the java stuff wants to communicate with website its not going to work on amd64 [12:25] nm, i figured out how to avoid java [12:26] the kernel is spitting insanities in loop [12:27] basically, out of memory everywhere, and no way to reclaim anything [12:48] fta: hmm so gwibber team build also failed? [12:48] yes, jaunty [12:48] they silently push python2.6 and python is still 2.5 [12:49] +ed [12:50] i just re-triggered the bot => gwibber_0.9.1~bzr246-0ubuntu1~daily2 [13:30] lol, bug 31589 :) [13:30] Launchpad bug 31589 in launchpad-foundations "Attempting to set redirection_url to a tuple instead of a string in login machinery" [Medium,In progress] https://launchpad.net/bugs/31589 [13:30] no [13:30] lol, bug 331589 :) [13:30] Launchpad bug 331589 in alsa-utils "system beep in jaunty is the most annoying sound known to man" [Medium,Fix released] https://launchpad.net/bugs/331589 [13:49] asac, fta: do you ever make use of "bzr bd --use-existing"? [13:50] nope [13:50] what is that? [13:50] last bzr regressed? http://paste.ubuntu.com/120589/ [13:51] you need to upgrade loom [13:51] the option makes it not extract the upstream tarball again [13:53] just wondering if I have to preserve that [13:54] do you mean it's equiv to moving to build-area/foo and doing dpkg-buildpackage -nc ? [13:54] james_w: --use-existing? is that like --quick? [13:54] that didnt help for me as it somehoe rebuild everything even if i use debuild -nc [13:55] if --quick would work that way it would be great [13:55] it deletes debian from the last build directory, then re-exports your branch in to it [13:55] then builds the result [13:56] deletes debian = remove the stamps, so it forces a rebuild [13:56] oh, didn't think of that [13:56] I've never really used it myself [13:57] if you don't delete debian it won't work if you delete a file though [13:57] indeed [13:57] but that is probably rarer [13:57] what I want to do is make the build-dir default to .. as well [13:58] gasp [13:58] but that means using tempdirs to build in, rather than pkg-version directories [13:58] that means polluting my branches repository [13:58] how so? [13:58] with tons of files i really don't care about [13:59] when i need disk space, i just rm -rf build-area [13:59] if it's now in .. relative a packaging branch, i will no longer be able to do that [13:59] I said default [14:00] i have ~200 branches [14:00] but I don't really see what you mean by "tons of files" [14:00] it would make it work the same way as not using bzr and just calling "debuild" [14:01] well, i have my aliases already [14:01] bdm = bd --merge --dont-purge --result-dir=../build-area [14:01] bdn = bd --native --dont-purge --result-dir=../build-area [14:01] ppa = "bd --merge --build-dir=../ppa --builder='dpkg-buildpackage -rfakeroot -S -sa -kB6EE20E8'" [14:01] ppa2 = "bd --merge --build-dir=../ppa --builder='dpkg-buildpackage -rfakeroot -S -sd -kB6EE20E8'" [14:01] ppan = "bd --native --build-dir=../ppa --builder='dpkg-buildpackage -rfakeroot -S -sa -kB6EE20E8'" [14:02] so i don't mind [14:03] my bot forces --result-dir too [14:04] why not set "merge" and "native" in the config file so that anyone can build them without figuring that out? [14:05] and the latest version will mean you don't have to use --builder anymore [14:05] i don't expect others to build with bzr bd [14:06] "bd --merge --build-dir=../ppa -- -S -sa -kB6EE20E8" will work [14:06] and i'm not very in sync with all the new bzr goodies :P [14:22] asac, https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=gwibber [14:25] fta: thanks. you could have reused the version btw. [14:26] fta: can you ask seb politely if he has some cycles to look at it now? [14:26] i wanted but cjwatson asked me to bump it [14:26] at least inform him that there is a new [14:26] ok [14:26] doesnt really matter. its easier for archive admin to spot which to take [14:26] if you bump version [14:26] ok ... preparing for a call [14:27] bb in ~1h [14:42] Hi, there is a patch up that fixes this bug: [14:42] https://bugzilla.mozilla.org/show_bug.cgi?id=404314 [14:42] Mozilla bug 404314 in XUL "when I click on a menu instead of click and hold it randomly selects a menu item and activates it" [Normal,Assigned] [15:30] i'm sick of this crappy sound. [15:30] dtchen, do you think my issues with p-a are caused by a crappy driver or crappy h/w ? [15:31] fta: have you tried the workaround? [15:31] to make it speech free or what ever its called? [15:31] ? [15:31] what is that? [15:31] humm [15:31] glitch free? [15:32] there's a mail from crisum and the muson on the lists about it [15:32] yeah that's it [15:33] "3 revisions were removed from the branch." (gwibber trunk). gasp, my bot will probably hate that [15:33] eheh [15:33] oh I saw that ryan bumped the gw vers [15:34] so its should now be higher [15:34] as you wished [15:35] yep, my description was a bit confusingn, 0.9 vs 0.9.1, ryan used 0.9.1 while 0.9 would have made more sense, my bad [15:35] -n [15:35] eheh [15:36] i'm not caching the upstream branch for gwibber, good, my bot will cope with the removal [15:37] /me looking for a better sound card... so many: http://www.rue-montgallet.com/prix/75012/comparer/114/Cartes-son/?i1=698&f1=2759&i2=700&f2=2760&i3=701&f3=&i4=702&f4=&mq=0&pxmin=0&pxmax=0&od=nom&show=1&nbf=4 [15:43] no "works well with ubuntu" list? [15:46] eheh [15:46] did your current got fried yesterday? [15:47] no [15:48] but i keep having issues on this desktop since p-a entered ubuntu, while on my other desktop and my laptop, it's fine (well, sort of) [15:48] keep your eyes open when NM ubuntu2 gets on your system [15:48] it might break your carrier detect [15:49] escalate to me if you suddenly cannot connect to wired anymore ;) [15:54] i don't have the osd notifs, should I? [15:54] fta: yes [15:54] do you have notify-osd installed? [15:54] nope [15:54] but i'm up-to-date [15:54] fta: install it ;) [15:54] maybe you nuked something else [15:55] like ubuntu-desktop [15:55] ii am not sure how that is supposed to get pulled in [15:55] ahhhhhhh asac? really [15:55] ? [15:55] oh right, i no longer have ubuntu-desktop [15:56] I'll have to look at it [15:56] and inform users on +1 [15:56] yah I lost ubu-deskt twice now! [15:56] yeah. if you removed ubuntu-desktop there is no guaranteey you really track the ubuntu desktop experience [15:56] similar if you uninstall firefox package you wont get auto migrated to firefox-3.1 [15:57] The following packages will be REMOVED: [15:57] gnome2-user-guide restricted-manager restricted-manager-core scrollkeeper [15:57] fta: not srue. i think the restricted manager is now called jockey [15:57] asac: but UM -d should make sure its there [15:57] might be that its just a normal removal [15:57] due to control hints [15:57] BUGabundo: i am not sure about that. ask mvo. there might be reason to not pull that in again [15:57] fta: what ever you do, DON'T force anything [15:57] parcial installs suck [15:57] i even think so. if you opted out of ubuntu-desktop there is no reason to force it on you gain [15:58] UM should never ofer them [15:58] asac: yeah I have to ask him [15:58] BUGabundo: lol, i'm not a noob ;) [15:58] already did, but did not get a reply [15:58] partial upgrades are ok [15:58] yestreday [15:58] you just shouldnt confirm upgrade if there are a bunch of removals you dont understand ;) [15:59] http://paste.ubuntu.com/120629/ [15:59] too much crap in there [15:59] seems fine to me [15:59] lololol [15:59] how long have you been without U-deskt? [16:01] apparently a long time ago [16:01] already got mvo on +1 [16:01] trying to get this strait [16:01] fta@ix:~ $ zgrep ubuntu-desktop /var/log/dpkg.log* [16:01] fta@ix:~ $ L /var/log/dpkg.log* | head -1 [16:01] -rw-r----- 1 root adm 120156 2008-03-30 15:20 /var/log/dpkg.log.12.gz [16:01] fta@ix:~ $ [16:01] you should go to network-manager ;) [16:01] ehehehehehehehe [16:02] so probably more than a year ago [16:02] anyway ... justinstall notify-osd for now;) [16:02] folks on +1 should use ubuntu-desktop though [16:02] yeah [16:02] but a few of us lost it [16:02] trying to clear that out with mvo [16:03] thats a good time to learn ;) [16:03] n-m for an always wired desktop /w fixed ip is useless [16:03] works for me (TM) [16:03] if it discover it's the same network [16:03] avahi magic ?! [16:03] i don't need that [16:04] i will just cherry pick what i need from the list [16:04] yeah I do that too, when it fails [16:04] app-install-data-partner ? hmm [16:05] asac: fta mvo said UM should install ubu-deskt! [16:06] then you lost it after upgrading to jaunty ;) [16:06] fta probably used apt-get dist-upgrade ;) [16:06] yeah [16:07] he shouldn't [16:07] lol [16:07] no, maybe i removed it to prevent n-m from trashing my prefs at each reboot [16:07] "that's not the Recommend way on Ubuntu" [16:07] according to the Wiki [16:07] lol [16:09] mobile-broadband-provider-info on my desktop, no thanks [16:12] ok, 29 instead of 54 [16:19] asac, it's not transparent at all and it's not using my prefs [16:19] metacity [16:19] fta: did you fix the gwibber team build? (me desparately wants the new thing due to annoyance) [16:20] fta: yes metacity needs still some fixes. [16:20] but it works at least (first it didnt show anything) [16:20] fta: metacityy also supports a bit composite ... you can try to enable that [16:20] but i guess its still lacking support [16:21] fta: ask macslow about his plans [16:21] i know, but i don't want composite for my other windows [16:21] it's slower for no benefit [16:21] yeah. ask him [16:21] ;) [16:22] i can't read the text, white on black but too small, and it disappears too fast [16:22] the time my eyes move and focus on the notif, it's gone [16:22] yeah. tell that him ;) [16:22] and file bugs [16:22] bugs bugs [16:22] :) [16:22] thats the important part. notify-osd [16:30] i wish someone fixes bug 328932 soon [16:30] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/328932/+text) [16:36] fta: it says its fixed since 13 hours [16:37] This bug was fixed in the package libsdl1.2 - 1.2.13-4ubuntu3 [16:37] really? [16:37] Great work Luke! Thanks for fixing it. All games work again on my machine after I installed the update. [16:37] yes [16:37]