[00:00] bug 427295 [00:00] micahg: ^^ [00:00] ;) [00:00] Launchpad bug 427295 in firefox-3.5 "Firefox 3.5 does not allow me to search with the search box" [Undecided,Confirmed] https://launchpad.net/bugs/427295 [00:00] gnomefreak: ^^1 [00:00] ah [00:00] yes [00:00] gnomefreak: is that the bug you are seeing? [00:00] are you seeing it atm? [00:02] ok guess thats the final bug i will be focussing on after all is done ;) [00:03] 'aslooking but sounds like it [00:03] just have to find the profile with which i could reproduce that issue [00:09] 3.6~b2~hg20091016r32516+nobinonly-0ubuntu1~umd1 <<< bot problem? fta asac [00:10] why? [00:10] thats a firefox ~b2 build [00:10] hg20091016 [00:10] i think we have breakage [00:11] micahg provided a branch and most likely i failed to apply it :/ [00:11] is that the story? [00:11] - thunderbird-3.0 (3.0~hg20091017r4190+nobinonly -> 3.0~hg20091019r4193+nobinonly) [60.10MB (+0kB, +0.00%)] [00:11] I think so [00:11] today [00:12] yep, that should be fixed in the proposed merge [00:12] looks fine to me: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages?field.name_filter=thund&field.status_filter=&field.series_filter=karmic [00:12] lol, 3.6, not tb3, n-m [00:12] yeah [00:13] too late for me, i seriously need some sleep [00:13] fta: gooooo [00:13] d night ;) [00:13] yeah, thanks [00:14] altohough I think my ff build will fail now :) [01:15] micahg: so did you check xulrunner-1.9 in universe/main too? [01:15] not yet [01:15] micahg: ok. [01:16] micahg: but firefox-3.0 was done, right? can you comment your findings in the bug? [01:16] at best the firefox-3.0 ones for now ;) [01:17] done [01:18] I tried to build 3.6~b1 with m-dev 0.12 [01:18] didn't work too well [01:18] micahg: yeah better use the latest m-dev [01:18] I backported it to Jaunty [01:19] hmm [01:19] micahg: well. you just need the orig.tar.gz [01:19] you can produce that in karmic if its bad in jaunty m-dev [01:19] though it should work afaik [01:19] not sure though because of tip/default etc. [01:19] but i thought the hg stuff worked for a while and we didnt change how its integrated in pacakge [01:20] but maybe fta redid something i didnt see ;) [01:20] it might not have been the m-dev script [01:20] but I figured it was easy enough to backport [01:20] k [01:20] micahg: daily ppa has no backport for that afaik [01:21] and works too ;) [01:22] hmm [01:22] mist be somethign else [01:22] micahg: seahorse-plugins depends on ffox? thought on xulrunner ;) [01:23] oh [01:23] hmmm [01:23] hehe [01:23] ok so that means you alredy checked main for xulrunner? [01:23] e..g just universe and sources missing? [01:23] yeah [01:23] or did you search sources? [01:23] I search sources in main [01:23] ok ... so binaries and sources+binaries from universe still missing for xul-1.9 [01:24] Fixed [01:27] asac: hmm...seems to be working with the new m-dev [03:30] asac: ff3.6build1 and xul1.9,2build1 built fine [03:39] asac. micahg. are there any outstanding firefox bugs that need testing or fixing? [03:39] *for karmic [03:52] hmm [04:15] ... [04:16] idk [04:18] I still have about 180 bugs to triage :) [04:22] what about this one? [04:23] https://bugs.edge.launchpad.net/firefox/+bug/438868 [04:23] Launchpad bug 438868 in firefox "Address bar autocomplete doesn't always work" [Unknown,Confirmed] [04:23] i hate this bug because i run into every day. [04:23] and so will joe windows-user [04:23] when he tries karmic [04:27] that's one of the ones I need to get to [04:28] does it happen after an upgrade? [04:29] nevermind...it's already upstreamed [05:22] micahg, link? [06:00] LLStarks: it's in the bug === micahg1 is now known as mciahg === mciahg is now known as micahg [06:45] asac: I added tasks for all the depends I found in universe [08:21] asac: I found a quick bug that might be worth throwing in ... bug 448683 [08:22] Launchpad bug 448683 in firefox-3.5 "change slovak translation of menu entry" [Low,Triaged] https://launchpad.net/bugs/448683 [09:35] micahg: is that list complete? [09:35] micahg: are those main or universe? [09:35] I checked main already [09:35] that's universe [09:35] should be it [09:36] whats going on with prism [09:36] idk [09:37] oh, BTW, when I build 3.6b1+build1, it built with the official branding [09:38] asac: ^^ [09:39] ok, time for sleep [09:39] night [09:39] thx [11:54] * asac merged micahs ffox 3.6 branch [12:01] <|eagles0513875|> hey asac [12:02] hi [12:04] <|eagles0513875|> how goes it in the office this week [12:12] <|eagles0513875|> be back from home [12:17] asac, are you doing devhelp update? [12:18] asac, I did it for debian already [12:18] saw your name on the package's page [12:18] assigned to devhelp [12:36] av`: devhelp == new tarball? [12:36] is that gnome? [12:42] asac, yes [12:43] av`: bug 451864 ? [12:43] Launchpad bug 451864 in devhelp "Please sync devhelp 2.28 from debian sid" [Wishlist,New] https://launchpad.net/bugs/451864 [12:43] or something newer? [12:43] should be it [12:47] asac, why they give you GNOME stuff to do? [12:49] why do you think they gave it to me? [12:49] at some point i ported it to xulrunner 1.9 [12:49] since then i more or less take care if it needs new porting [12:50] asac, seahorse-plugins failed to build [12:50] you enabled ephy plugin --> enabling epiphany plugin... [12:50] but you deleted the depends [12:50] annoying [12:50] of course it fails trying to find gecko to really build the plugin [12:52] sure [12:52] had it right here. but then robert prepared the update and i took it which reverted the configure flags thing [12:52] iu shouldnt take care for credits in future [12:52] av`: so i just dropped the --enable-gecko ... thats ok? [12:53] asac, which credits? [12:54] asac, -with-gecko=libxul-unstable is a bit non-sense [12:54] if you remove ephy stuff and you leave that [12:54] it will fail for sure [12:54] let me test build [12:54] now i remember ... you said that it will auto detect the that there are no build deps [12:55] but that doesnt work [12:55] the --disable-epiphany is even needed ;) [12:55] in debian wasnt needed [12:55] fixing that now [12:55] k [12:55] yeah [12:55] i think it would work without disable on buildds [12:55] but if there is gecko it will still take it [12:55] exactly [12:55] maybe ubuntu still has gecko [12:56] asac, did you upload this latest revision? [12:56] well. things should never be automagic [12:56] always put in --disable-epiphany [12:57] otherwise your local builds will differ from real builds [12:57] asac, I've removed gecko thing in rules [12:57] let's see [13:02] asac, and anyway it will auto-detect that there ano B-Ds only if the configure flag --gecko-... is removed [13:02] if you leave it you asks configure to find gecko bits [13:02] but the B-D is not there [13:03] yes. the fault was on my side not dropping it [13:03] just saying that not adding --disable-epiphany is also wrong [13:04] well, it depends [13:04] it won't fail the build [13:04] no. but it will pick up gecko if you have it on your disk [13:04] which is also wrong ;) [13:05] if a package doesnt work ... it shouldnt be build [13:05] asac, if you disable gecko and remove the flag [13:05] it will say ephipanu plugin disabled [13:06] that's what we want [13:06] av`: not if you ahve xulrunner-1.9-dev installed [13:06] av`: you need to do --disable-epiphany [13:06] i just tried it [13:06] i expect a reasonable upstream build system to not build epiphany if there is no epiphany--dev installed [13:06] but they look for gecko and then flip it on [13:09] asac, pretty bad then [13:09] removing epiphany-dev should do the work with a correct configure run [13:09] av`: no. thats the point ;) [13:09] i dont have epiphany-dev installed [13:09] hmm i have [13:09] so yeah [13:09] that's it :) [13:09] anyway... all the automagic is painful [13:10] explicit flags for the world ;) [13:10] nevermind [13:10] I'm building it on my buildd [13:10] to check [13:10] av`: its already uploaded [13:10] and accepted [13:10] if it fails again i will resign from my job [13:10] ;) [13:12] av`: so devhelp might have a chance as its not on CD [13:13] asac, yeah, seb told me it's not really needed atm [13:16] asac, it ftbfs again [13:16] asac, jk :P [13:17] av`: dont do that :-Ü [13:17] i am completely overworked ... hung over and what not atm [13:17] ehehe :) [13:17] so these kind of jokes make me jump out of window [13:17] lol [13:17] sorry then :) [13:17] https://edge.launchpad.net/ubuntu/+source/seahorse-plugins/2.28.1-0ubuntu3 [13:18] asac, if it would really ftbfs I would have done it for you so you could have moved to something else [13:18] but worked [13:18] but seriously. i think for next release i should create a bunch of pbuilder tarballs and actualyl test something [13:18] yep [13:18] av`: well. the problem would not to do it, but that release managers will kill me ;) [13:18] :D [13:18] slangasek probably didnt sleep for the whole night and waits for all the bits to be there so he can fire up the ISO run [13:19] and i stressed him completely by my xulrunner/firefox etc. uploads today [13:19] yeah, so another ftbfs on seahorse-plugins wouldnt be accepted by him [13:20] it probably would [13:20] but i am not sure i would get anything in after that [13:20] like a High importance bug in network-manager -> blocked ;) [13:20] you can basically always argue that high importance bugs in apps are not important for the whole release [13:20] especially at this time [13:20] but everything went fine, good work [13:20] going to study now [13:20] av`: thx. [13:21] see ya late night [13:21] av`: btw, i think your work is improving quite a lot [13:21] since you came back :) [13:21] just wanted to say that ... but forgot yesterday [13:21] asac, thanks a lot, I'm doing a focused work and yeah, it's going great so far [13:21] i think your work got better when you switched to the most recent nick name [13:22] lol [13:22] not really sure you are still the same ;) [13:22] like a butterfly ;) [13:22] maybe im not the old bluekuja [13:22] the new one ;) [13:22] I'm his transformation [13:22] yeah :) [13:22] meta-morphosis [13:23] ttyl [13:23] yeah, it happened for a human [13:23] not only for animals then :) [13:23] cya later [13:23] have a nice day [13:23] u2 [13:34] back [14:25] hey bdrung [14:26] eagles0513875: hi [14:26] how are you [14:28] busy. the term started again [14:30] trust me i know the feeling of being back in lectures :( [14:30] 3rd week and already have 3 tests one down 2 to go this week [15:33] asac. bug 438868 is probably compiz related [15:33] Launchpad bug 438868 in firefox "Address bar autocomplete doesn't always work" [Unknown,Confirmed] https://launchpad.net/bugs/438868 [16:29] LLStarks: yes. thats what i thought [16:29] bdrung: term? university? [16:30] asac: yes [16:31] have fun [16:31] 3g is good during lectures ;) [16:31] i won't ;) [16:31] ... if you lost the wifi password ;) [16:31] LAN is even better. [16:32] download with GBit ;) [16:32] GBit/s === bdmurray_ is now known as bdmurray [16:33] nah. 3g is much better i tell you ;) [16:33] especially when everone has lan + wifi ... [16:33] ;) [16:48] asac: how fast is 3g? [16:48] quite good [16:49] normally you get like 300k [16:49] down [16:49] and up is almost the same [16:49] sometimes much more [16:49] and sometimes ... especially if you are in a train its far less [16:51] the good is that you can use it almost everywhere [16:51] so no need to bother about stationary behaviour [16:54] free-flying mode possible ;) [17:43] mac_v: did you drop nm-device-active icon from last theme? [17:43] or was that link shuffeling? [17:43] something must have changed [17:43] 18:41 < NoelJB> ** (nm-applet:2390): WARNING **: Icon nm-active-device missing: Icon 'nm-active-device' not present in theme [17:44] that was seen during upgrade [17:44] could be that its harmless - but could be pretty bad [17:45] asac: i dont think there was ever an icon by that name. that icon is for what device? [17:46] mac_v: well. that icon must exist if nm-applet complains about it ;) [17:46] its odd though [17:46] asac: i meant in humanity theme :) [17:46] mac_v: maybe you guys shipped a link to that and now you retargetted that link? [17:47] mac_v: this guy uses human theme [17:48] is that humanity-icon-theme? [17:48] bug # ? [17:48] mac_v: no bug. its hot. was pinged in nm while that guy updated his sytstem [17:48] with todays theme [17:48] well... with todays updates ;) [17:49] its definitly transitional . just want to understand why that icon was there before ... and was used ... and now is gone [17:49] i dont remember any icon or symlink being made as "nm-active-device" [17:49] only explain i have is that you guys shipped nm-active-device ... linked it maybe as nm-device-wired ... and now moved the nm-device-wired link somewhere else [17:49] mac_v: who did todays changes? [17:50] i got it too now [17:50] upgraded to todays theme [17:50] ** (nm-applet:3496): WARNING **: Icon nm-active-device missing: Icon 'nm-active-device' not present in theme [17:51] there was no humanity had an update today , the latest is 0.4.1ubuntu5 [17:51] asac: i think the icon is a new name from nm applet which humanity doesnt have [17:51] asac: 300 kB/s or kBit/s? [17:52] there was no humanity update today* [17:55] mac_v: ok its really applet. sorry for the alarm ;) [17:55] bdrung: i never use bits [17:55] a byte is the minimum full data unit i consider ;) [17:55] ;) [17:55] asac: what is that icon for? is it a new naming where -active- is used for panel and ... [17:55] bdrung: its pretty decent. when secondary home had broken wifi i used it as primary work connection for a few weeks ;) [17:55] even uploading mozilla stuff etc. [17:56] asac: yes really fast then (compared to dsl, wlan) [17:56] and uploads were not much slower than normal dsl [17:56] asac: but lan at the university is still faster [17:56] bfiller: from german mirror i usually get like 1100K down and just 180K up [17:56] hehe [17:56] sure [17:56] but you cannot be in free-flying mode [17:56] ;) [17:56] asac: even so why isnt the nm applet falling back to the default icons from hicolor? i think nm didnt ship the icon too ;) [17:57] freedom is more important than speed ;) [17:57] mac_v: its something unrelated [17:57] phew :) [17:57] mac_v: its happening when a icon gets removed from disk that is already opened etc. [17:57] nothing to do with fallback [17:57] would be a theme "fallover feature" [17:57] sounds like an interesting idea ;) [17:58] asac: i only need a fast server to test the speed there (the maximum was 8 MB/s) [18:00] i think fta uploads chromium in like 3 seconds ;) [18:00] asac: that's fast [18:01] yes ;) [18:01] bdrung: he told me that the rotating dput thing in terminal causes CPU to peak ;) [18:01] wow [18:01] which i find ... interesting ;) [18:02] * asac wants that problem ... would promise to fix it ;) [18:02] ;) [18:02] bdrung: so finland folks hav a right to get 100Mbit/s by law by 20015 [18:02] 2015 [18:03] bdrung: deutsche telkom reiterated a year ago that they think copper is the future [18:03] by 20015 we have 100 Mbit/s, too :p [18:03] i wouldnt be so sure ;) [18:03] i wanted to kill myself when i read that telekom statement :) [18:03] actually kill someone else ;) [18:04] asac: please don't. let someone other do that ;) [18:05] hehe [18:06] asac: hopefully we have 30 Mbit/s at home next year [18:09] i wanted to go for kabeldeutschaldn when i move to a new home [18:09] i definitly deny to be a customer of DTAG again even if they have the 50 thing ;) [18:10] also i have this inner feeling that dsl is a major problem in my life ... ;) so i am looking forward to do something else [18:10] i just remember me sitting here and replugging modems/routers all the time ... or just getting hourly resets etc. [18:14] asac: there's no xulrunner metapackage AFAICT [18:15] micahg: whats the context? hi ;) [18:16] hi, depends on xulrunner (>=1.9~ [18:16] xulrunner refers to 1.8 [18:17] micahg: hmm. which packages did i close that way? [18:17] can you reopen them? [18:18] * asac had hoped that this mess is over [18:18] xulrunner-dev points to 1.9 [18:18] I mean 1.9.1 [18:19] conkeror and galeon [18:19] micahg: indeed. what a mess [18:20] wonder why i mixed that up ;) [18:20] wee only hav e-dev as meta package for xulrunner [18:21] asac: also, did you get my not about 3.6 building with official branding [18:21] *note [18:21] micahg: email? i didnt even look at email today :/ [18:21] * asac feels miserable ;) [18:21] no [18:21] in here [18:21] oh [18:21] * asac scrolls up [18:21] 3.6b1+build1 built with official branding [18:22] if no mail i should really get whats going on here ;) [18:22] it was about 9 hours ago [18:22] micahg: hmm. ok. [18:22] is that ok? [18:22] micahg: so in the past we shipped betas as official branding [18:22] ok [18:22] that was when firefox-3.0 was out [18:22] but now we stopped doing that for 3.5 [18:22] does mozilla ship betas as official branded? [18:23] my guess is that the rules script changes were done on 3.5 branch only [18:23] and need to be also applied to 3.6 and 3.7 branches [18:23] can you check that? [18:23] yeah [18:23] It says (alpha) in the menu [18:23] micahg: unclear. i am sure they did for 3.0 betas. but not so sure about 3.5. but we definitly do not do that anymore [18:23] ok [18:24] I was wondering why I was so lucky to have FIrefox 3.6 :) [18:24] micahg: essentially, now that final is out, we need to review _all_ changes that were committed to 3.5 branch and check that everything is also on 3.6 branch [18:24] i think we also made changes how the .desktop files are treated etc. [18:24] so before doing that we shouldnt look at these things in the branches directly [18:24] rather first be sure we have everything in sync ;) [18:25] also identify why things were just committed there [18:25] so we can learn how to better do it in future ... e.g. almost every time we should commit everything first to current highest version branch [18:25] then to next ... and then eventually to current default ubuntu brnch [18:26] jdstrand: btw, i think we get worst timing again [18:26] jdstrand: afaik sec update is 28th. so lets hope they do another respin or something ;) ... though i think its unlikely its going back for a full other week [18:27] so mabe 28th is best if we want to update same day ... or friday is best if we want to update three days after. [18:27] but given how huge this update is we might want to wait a full week ;) [18:28] asac, are you glad that that bug is compiz related? [18:28] [reed]: is nss/nspr you talked about in .4 or .5? [18:28] LLStarks: why would i be glad about a bug [18:28] LLStarks: i am not the person that is happy when bugs go somewhere else [18:29] i prefer them to stay in my domain of expertise because thats where i can best help [18:29] glad, as opposed to something more profound and deeply-ingrained in the code [18:29] asac: hmmm... I think friday has to be the way to go. otherwise we are messing with CD respins, especially if there are regressions [18:29] LLStarks: i am glad that you could track down [18:29] jdstrand: friday is day-after-release? [18:30] asac: yeah [18:30] jdstrand: ok. and since we have soyuz we are not blocked by ugly archive copies or something? [18:30] asac: if it is super serious, then I advise talking to slangasek [18:30] asac: no-- soyuz is not an issue [18:31] jdstrand: i dont think talking to slangasek will change anything on whether we can or cannot do that ;) [18:31] jdstrand: i definitly dont want to put the update out on wed [18:31] and thu is release ... so fri sounds quite good [18:32] alright, good. :) [19:02] jdstrand, i'm still stuck with my kvm. and #ubuntu-virt is desperately quiet :( [19:03] asac, acroread (from the partner repo) installs tons of copies of the pdf plugin: http://paste.ubuntu.com/297683/ [19:04] asac, .. but nothing in our xul dir [19:04] fta: i think the mozilla location also works [19:05] shouldnt be installed in all those 3.* versions [19:05] oh [19:05] thats a link thing right? [19:05] odd [19:05] yeah [19:05] dpkg -L ? [19:05] it does. i just wanted to remove the plugin (i prefer the system/external pdf viewer for the web) [19:06] fta: most plugins dirs are a link there [19:06] so its probably two or even just one copy [19:06] i guess three: firefox/ ... mozilla/ ... and firefox-addons/plugins [19:06] what is /usr/lib/firefox-minefield/plugins/nppdf.so [19:06] ? [19:07] why do you have a firefox-minefield [19:07] ? [19:08] http://paste.ubuntu.com/297686/ [19:08] i think it's in postinst [19:08] firefox-minefield is from m-d, my upstream nightly repacks [19:10] fta: is that upstream nightly repack in a branch? or are you really repacking the upstreamtar.gz thigns=? [19:11] the latter [19:11] urgh [19:11] in postinst? [19:11] oh now [19:11] please tell me its in firefox-addons/plugins ;) [19:11] oh no [19:11] so much dirt :( [19:11] fta@ix:~ $ pastebinit /var/lib/dpkg/info/acroread.postinst [19:11] http://paste.ubuntu.com/297690/ [19:12] hmm cannot see where they copy it in the firefox folders [19:12] that's acroread jaunty, as there's no version for karmic :( [19:13] still [19:13] where are the .so things coming from [19:13] also ... whats going on with the icons [19:13] why is that needed in postinst [19:13] i use acroread (even if i hate non free stuff) because evince takes too much cpu, and the rendering is ugly (both text and pictures) [19:14] fta: do you have a link to the .dsc at hand? [19:14] http://archive.canonical.com/ubuntu/pool/partner/a/acroread/ [19:14] anyway [19:14] http://archive.canonical.com/ubuntu/pool/partner/a/acroread/acroread_9.1.3-1jaunty1.dsc [19:15] i think all the versioned firefox things arent a problem [19:15] at least there is a link [19:15] so it would overwrite the firefox-addons location multiple times [19:17] ouch [19:17] acroread-9.1.3$ ls [19:17] AdbeRdr9.1.3-1_i386linux_enu.deb debian [19:17] no. i will not proceed down that road ;) [19:18] * asac forgets what he just saw [19:19] fta: ask kirkland and/or soren in #ubuntu-server then. I saw them earlier [19:19] fta: though someone else might be able to help in there too [19:20] jdstrand, i guess i should just file a bug :( http://paste.ubuntu.com/297586/ [19:20] fta: possibly, but they may know about it already [19:21] but i have no error to paste for the boot failing, other that it doesn't work, i have no other info [19:21] fta: I vaguely recall seeing a bug regarding Windows and kvm [19:22] fta: soren and kirkland are the ones who maintain kvm and libvirt in Ubuntu. they should be able to help [19:22] does *bsd work well with kvm too? [19:22] asac: it certainly used to, though I haven't tried recently [19:23] I had openbsd in a vm and I believe kees had freebsd (6?) in there [19:23] good. probably worth trying to get netbsd on that ;) [19:23] heh, you picked the one I don't know about :P [19:23] heh. i like netbsd best (based on a real low amount of work i did) [19:24] i tried all and when i ended up in issues netbsd was always quiet obvious by reading scripts etc. [19:24] imo freebsd tried to introduce more smartness ... which seems to more difficult [19:24] possibly unsurprisingly, I was a fan of openbsd [19:24] hehe [19:24] yeah. i found openbsd to be a a bit unobvious too [19:24] ;) [19:24] but last time i really used it was a bit ago ;) [19:25] I've been phasing out my obsd installs in favor of ubuntu. I down to maintaining one obsd machine [19:25] s/I/I'm/ [19:25] jdstrand: right. now i remember why i didnt like openbsd ;) ... it wasnt possible to tune the uptime ;) [19:25] jdstrand: like here: http://www.jwsdot.com/tuptune/#freebsd [19:26] thats the dumpest thing i ever did ;) [19:26] openbsd resets the tcp timestamps for each connection [19:26] heh [19:26] so no uptime with nmap ;) [19:27] "The good of NetBSD is that the 2 Hz timestamp ticker is able to produce really great values like 5 years or something." ;) [19:27] not even sure if thats still true [19:28] wow. if they can go 5 years without a CVE in the kernel, that is pretty impressive [19:28] granted, all the BSDs have far fewer CVEs in their kernels [19:28] jdstrand: i think its 8 years or something at max [19:29] if you dont have any port open [19:29] and by far, I mean *far* [19:29] when was the last tcp/ip exploit? [19:29] like in 2.2? [19:29] (on linux) [19:29] there was an sctp one relatively recently [19:30] but I don't recall offhand [19:30] but it you can get a user account on a system with a local root exploit, that is nearly as good [19:30] (eg, bad cgi/php script...) [19:31] sure [19:31] most of the linux CVEs are DoS [19:31] yeah. but there must be a http server without a vulnarability that allows you to exploit a normal html static load ;) [19:31] local DoS [19:32] yeah [19:32] and a local DoS is kinda like 'so?' [19:32] it is easy enough to do that without an 'exploit' [19:32] i assume a local DoS is usually a memleak in kernel? [19:32] at least a real dos ... wouldnt htink that just overload can be a Dos [19:33] it's usually stuff that'll make it oops [19:33] ah ok [19:33] yeah. but thats a real issue on a multi-user system ;) [19:35] sure. but a user can do an overload type of thing to achieve something similar [19:35] jdstrand: is there a thing like ulimit for CPU? [19:36] guess VM ;) [19:36] ulimit -a [19:37] oh ;) [19:37] cpu time (seconds, -t) unlimited [19:37] err ... is that an absolute value? per-process? [19:38] I don't consider resource exhaustion interesting. I was just saying that if you can perform a resource exhaustion attack, and you can make the kernel oops, there isn't a tremendous practical difference [19:39] New package: synce-multisync-plugin (universe) [0.9.0-4.1 → 0.9.0-6ubuntu1] [19:39] odd package name ;) [19:40] * asac off ... will check later for things === asac_ is now known as asac [20:20] oh, apt-pinning for a PPA doesn't seem to work right [20:21] asac: http://packages.ubuntu.com/karmic/prism [20:21] xulrunner-1.9.1-dom-inspector Package not available [20:23] hmm [20:23] apt-pinning is working in aptitude, but not in update-manager [20:26] jdstrand, fyi, i just file bug 456602 [20:26] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456602) [20:28] fta: cool, I'll try to confirm it [20:28] asac: ugh [20:29] ugh [20:29] you made a ff3.0 package in ff.35? [20:29] lol, i typed guess instead of guest [20:29] micahg: sorry ... what do you mean? [20:29] http://pastebin.com/f327d82ca [20:29] so yes. i think i invented a non-existing abrowser-3.0 ;) [20:29] yes [20:29] oh, we can edit comments now [20:29] but that caused bug 456598 and possibly more [20:30] micahg: thats a transitional package ... thats the way to ensure that users dont get stuck with something old, not supported, not working etc. [20:30] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456598) [20:30] micahg: transitaional packages is: you put in the empty package into the new source that is supposed to take over [20:30] that transitaional package depends on what the new installed package should be [20:30] yes, but in this case, I think a transitional for ff3.0 uis a bad idea [20:30] and you add provides: oldpackage, replaces: oldpackage (<=newversion) [20:30] it'll screw with depends [20:30] and stuff [20:31] micahg: not sure [20:31] what you mean [20:31] https://launchpad.net/bugs/456598 [20:31] Launchpad bug 456598 in mozvoikko "incorrect Breaks statement forces removal because of newer firefox-3.5" [Undecided,New] [20:31] who are all those poor "Also notified" people? i pitty them, zillions of emails a day [20:32] fta: subscribers of the package [20:32] so if you subscribe to the whole package you get listed thre [20:32] fta: but its per package ... you can also do that on "ubuntu" i think [20:32] but thats a bad idea ;) [20:32] micahg: afaik mozvoikko does not work in firefox-3.5 [20:33] asac: well, then the package itself has an incorrect control file [20:33] most likely [20:33] and apparently the user was using it in 3.5 [20:33] asac, i see the same names in ff, libvirt, kernel, lp, whatever, i guess they are bug control or something [20:33] i mean ... the breaks probably wasnt added there for nothing [20:33] it breaks 3.0 [20:34] micahg: if mozvoikko was fixed the breaks should have been dropped [20:34] or just crazy [20:34] micahg: mozvoikko breaks 3.0? [20:34] yes [20:34] that's the problem [20:34] it should break 3.0 << 3.1~ [20:34] not in general [20:34] and the transitional package has 3.0 [20:34] thats a mozvoikko bug then [20:34] I wonder how many other packages like that? [20:34] i would think not many [20:35] we ensured that everything was transitioned [20:35] transitional ff3.0 seems counterintuitive [20:35] no [20:35] thats the _only_ way [20:35] transitional ff makes sense [20:35] no [20:35] firefox-3.0 can be installed alone [20:35] fta: how much ram do you have? [20:35] we cannot not transition them [20:35] mozvoikko works with ff-3.5 [20:35] heikki: sure. [20:35] fta: and did the iso boot or you saw the error before the iso booted? [20:36] the Breaks: was simply a packaging bug [20:36] even my bug ;) [20:36] :) [20:36] could you fix it? [20:36] jdstrand, i have 2GB of RAM + 6GB of swap, i tried with 512M and 1.5G, same result [20:37] afaik it is not necessary to have that Breaks-field, is it? [20:37] fta: did the iso boot? ie, did you start install and then later see the error, or did it error out after storage completed? [20:38] jdstrand, the libvirt error is when installing.. the thing in text mode asking you to accept the license, choose the partitioning. it seems to work fine until it asks to reboot [20:38] heikki: yes. thats true. i think when i added that i was not sure if the template install.rdf makes the right thing [20:38] fta: http://www.mail-archive.com/fedora-list@redhat.com/msg51978.html [20:38] heikki: so good point. [20:38] heikki: oh [20:38] heikki: so what is generated as minVersion? [20:39] isnt that 3.0? [20:39] the shutdown part produces the error, then nothing. if i manually start the resulting vm, i see nothing past the bios [20:39] fta: https://bugzilla.redhat.com/show_bug.cgi?id=500968 [20:39] problem i think was that it was 3.0, but the binary was not compatible with 3.0 because its built against xulrunner 1.9.1 [20:39] MOZVOIKKO_FF_MIN = 3.0a9pre [20:39] fta: I'll update the bug [20:40] heikki: yeah. so i will just patch that [20:40] file mozvoikko.config [20:40] fta: you said this works with jaunty? [20:40] ok, thanks [20:41] bugzilla.redhat.com bug 500968 in libvirt "virt-manager traceback on shutdown of qemu-kvm -no-acpi guest" [Medium,Closed: duplicate] [20:41] um, i'm not sure if that file is used at all, there is also a setting MOZVOIKKO_FF_MAX = 3.0 [20:41] heikki: http://paste.ubuntu.com/297760/ [20:41] does that look ok? [20:42] heikki: huh. for me that max is 3.6a1pre [20:42] oh, wait.. [20:42] could be some old version then... [20:42] jdstrand, yes, i've used several VMs created with that same ISO file on the same H/W. it was fine. i stopped using those VMs for a while, but I recently needed to use them again, my old VMs refused to boot, then i tried to create new ones, and here i am [20:42] yes it is 3.6a1pre [20:43] so your paste looks good [20:43] heikki: ok.. i changed tbird and sm too [20:43] randomly took 3.0b2 ... as i think that was already against 1.9.1 branch [20:43] for sm i used 2.0b1 ... also imo 1.9.1 branch build [20:43] fta: do you remember when sm and tb switched to 1.9.1? [20:43] micahg, asac: ff 3.5 FTBFSed [20:43] is 3.0b2 and 2.0b1 a good guess? [20:44] thunderbird doesn't use xulrunner for a spellchecking [20:44] ugh [20:44] daily? [20:44] upstream landed something? [20:44] thats odd [20:44] thought they are in build3 freeze or something [20:44] heikki: tbird 3? [20:45] afaik it won't work yet [20:45] heikki: http://paste.ubuntu.com/297766/ thats the thing i will land [20:45] doing a quick test build and then uploading [20:45] micahg: actually you are somewhat right about the ffox-3.0 transitional package ... the initial plan was to not do that [20:46] looks good [20:46] micahg: but we found out that _all_ packages are marked as manually by germinate ... so all CD install would have got stuck [20:46] that was not the plan ;) [20:46] so we go for good old transitional packages [20:46] a tad late in cycle of course [20:46] but usually you just do it and then fix all the rdepends [20:46] asac, http://hg.mozilla.org/comm-central/log/3645d6bc085b/mail/config/version-191.txt [20:47] 2009-01-07 [20:47] ok a1pre [20:47] hmm [20:47] well, no [20:47] well b2pre is probably good guess [20:47] that's the 3.0 / 3.1 split [20:47] or are we even not ahead of that? [20:47] ah ok [20:48] 3.1 is using moz-central, so 1.9.3 now [20:48] heikki: ok seems that min version is honored, but max version not [20:49] heikki: like http://paste.ubuntu.com/297769/ [20:49] fta: whats the current tbird version? b3? [20:49] I think that upstream has left it for a packager to decide [20:49] hmm seems we are at 3.0pre [20:49] 3.0pre [20:49] yeah [20:49] good so 3.0b2 is at least not higher ;) [20:50] heikki: micahg: uploaded [20:51] thanks. [20:53] welcome. good that it was spotted ;) [20:53] * asac gett a bit more confident that important issues somehow bubble up and are not missed [20:56] sigh awesomebrowser patch _again_ [20:56] have to check how to get rid of that somewhat [20:56] fta: micahg: oh [20:56] i know whats going on [20:56] we have to drop a patch [20:56] feel free [20:57] i had to prepatch the branding fixes i committed to the branding branch [20:57] less patches is always good for us [20:57] hehe [20:57] yeah. well that was just thzere for today [20:57] i will create the karmic branch now [20:57] and then uncommit from .head [20:57] err uncommit ;) ... remove i mean [20:57] yeah (not uncommit plz) [21:22] jdstrand, *sigh* [21:23] and there's not even a ppa up to the task [21:28] asac: did you see the issue with prism? [21:28] micahg: no [21:28] i assume it doesnt work at all [21:29] depends on xul-1.9.1-dom-inspector [21:29] whcih doesn't exist [21:29] heh [21:29] i have to check that [21:29] prism should have been updated in karmic [21:29] should I file a bug? [21:29] maybe we can do that in this turn [21:30] asac: do you need a bug to remind you? [21:30] xul-1.9.1-dom-inspector should exist, otherwise, if you drop xul 1.9 for the archive, dom-inspector would be lost [21:30] micahg: bugs only remind me by new mail ;) [21:30] micahg: but i think we need a bug [21:30] ok [21:30] I'll file one [21:31] fta: well. dom-inspector is gone from upstream source [21:31] micahg: thx [21:31] micahg: if you want to can do the update too ... but we probably should check that it actually works while we are at it [21:31] really? hm, maybe, i don't remember [21:31] fta: yes. they dropped it ... and put it in an independent projet ... just like pyxpcom [21:31] update prism, or a new package without the depends? [21:31] or it was constantly broken [21:31] cant remember anymore, but explicitly dropped it [21:32] micahg: well. first try if a new package works with 1.9.1 at all [21:33] asac: is this high or critical? [21:33] micahg: dont know. i think high is high enough ;) [21:33] critical is probably more like: if you install it wipes your hard-disk ;) [21:33] well, package won't install in karmic now [21:33] so isn't that critical for the package? [21:34] there are no strong definitions imo [21:34] i guess its probably quite critical for the package ... yes [21:34] though removal of data would be worse ;) [21:34] its a personal thing [21:35] whatewver you want ;) [21:35] fact is: we have to fix this [21:35] yes [21:35] and high is high enough to justify an upload in freeze [21:35] I can test tonight [21:35] thx [21:35] its no real hurry. universe fixes canstill be done [21:35] just main is done now [21:35] high is correct :) [21:36] didnt know there is a "correct" ;) [21:36] I checked in the -bugs channel :) [21:36] k [21:36] probably good for a second opinion [21:36] the importance is kind of mixed thing in ubuntu [21:37] asac: there is a wiki page [21:37] usualy its "package" importance ... until you milestone and target for release [21:37] then its more like "how bad is it for the whole release" [21:37] actually, should I assign the prism bug to me? [21:37] yeah, importance seems to be distro wide [21:38] micahg: sure. in case you find that you cannot follow up, just reassign to me :) [21:38] I originally thought it was package wide [21:38] and ping ;) [21:38] ok [21:38] so, I'll look at it tonight [21:38] my personal word is: dont take importance too serious ;) [21:38] just rough estimate is good enouhg ... it should suite your own worklist workflow [21:38] and not confuse others ;) [21:39] fta: should i keep the 3.1 name for .karmic branches? [21:39] and we fix that in one run ? [21:40] or start using 3.5 now and we fix the others later? [21:40] fta: oh also ... i saw that the branding branch for abrowser is kind of hard coded in mozclient [21:40] asac, we should rename asap [21:40] can we move that to the package itself ? [21:40] now i created a -3.5 branch [21:41] but bot still pulls from non veresioned [21:41] which is ok atm, but we should fix that before we bust our security updates [21:41] "branding branch for abrowser", i think we only have 1 for the 3 firefox [21:42] fta: thats not possible [21:42] fta: they changed branding entities [21:42] so i had to fix that [21:42] luckily we had one for 3.0 already [21:42] and its also used in mozclient [21:42] and i expect them to change branding entities again in future ... so we need major version branches [21:43] https://code.edge.launchpad.net/~mozillateam/firefox/awesome-browser-branding-3.5 [21:43] https://code.edge.launchpad.net/~mozillateam/firefox/awesome-browser-branding-3.0 [21:43] https://code.edge.launchpad.net/~mozillateam/firefox/awesome-browser-branding [21:43] but http://paste.ubuntu.com/297801/ [21:44] fta: oh cool. so its in the package [21:44] grewat [21:44] * asac needs to commit that before doing the .karmic branch [21:44] so awesome-browser-branding-3.5 is not used [21:44] fta: atm. es. [21:44] fta: but 3.0 is used [21:44] and since i had to fix the non versioned branch now [21:44] i made a -3.5 branch [21:46] asac, rename all the branches in lp, i'll rename in the bot [21:47] fta: one second [21:47] currently pushing this commit [21:47] then lets do it [21:47] fta: only .head branches ... ;) [21:47] yes [21:47] and the new .karmic branch will be 3.5 [21:47] ok [21:48] fta: ok i have an up-to-date copy ... so i am safe ;) [21:48] please do 3.6 too [21:48] yes [21:49] and .head.daily too [21:49] ok renamed firefox-3.1.head to firefox-3.5.head [21:49] renamed firefox-3.2.head to firefox-3.6.head [21:49] https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.6.head [21:49] https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.head [21:50] looking at dailies now [21:50] ok done [21:50] https://code.edge.launchpad.net/~ubuntu-mozilla-daily/firefox/firefox-3.5.head.daily [21:50] https://code.edge.launchpad.net/~ubuntu-mozilla-daily/firefox/firefox-3.6.head.daily [21:50] thats all= [21:50] ? [21:52] ok me prepares .karmic branches [21:53] I wish you could throw '/me' in the middle of a sentance [21:56] shit [21:56] can someone try to branch the karmic branch? [21:56] https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.karmic [21:56] sure [21:57] it's huge [21:57] done [21:57] Branched 489 revision(s). [21:57] good [21:58] Standalone tree (format: 1.6) [21:58] asac: I think the icons that tb2-gnome-support uses have changed in karmic [21:58] i got this: http://paste.ubuntu.com/297808/ [21:58] zr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set [21:58] dont know if i want to file abug ;) ... probably should [21:58] hm [21:59] ok .karmic branch lowered version [22:00] so now xulrunner [22:01] hm, i still have an old firefox-3.1-qt.head branch [22:01] and an even older firefox-4.0.head [22:01] yeah [22:01] maybe mark as abandoned for now? [22:01] in launchpad? [22:01] and rename?` [22:02] like firefox-4.0.head.thatbecame.3.1.abandoned [22:02] or [22:02] watching my 100+ branches locally [22:02] fta: remote is more important to get rid of clutter ;) [22:02] for us at least :) [22:02] not sure how many living-dead branches i have though [22:03] i'm concerned by my --remember, if i just push, i will recreate the old branches [22:03] like things that havent been touched for 130 weeks ;) [22:03] i assume those are obviously abandoned [22:03] lp:~mozillateam/iceape/debian-1.1.x 1 Development 2007-04-24 11:42:11 CEST [22:03] 130 weeks ago [22:03] 78. * New security/stability upstream rel... [22:03] lol [22:03] fta: at best go through all branches you have locally and push --remember to some randome location that isnt a real location [22:04] hmm [22:04] debian's license-anal attitude doesn't make sense. [22:04] shouldnt matter as long as you dont just do --force [22:04] LLStarks: Ubuntu's license schema is a little more open [22:05] LLStarks: it doesnt make sense based for projects with some goals ... if your goal is to provide an always free distribution that cannot disappear because it gets sued and so on [22:05] then it makes sense [22:05] also debian isnt really that strict [22:05] they have non-free [22:05] there are other distros with _only_ free stuff [22:05] if you say they are anal because they dont let in licenses that conflict [22:05] then its plain wrong [22:06] its illegal to ship stuff that uses GPL and is itself licensed whatever else ... i [22:06] f its incompatible its illegal ;) [22:06] ubuntu has a similar attitude to licensing [22:06] only big difference is that we allow non-free icons in [22:06] yet we love mozilla's public license and binary graphic stacks [22:06] under the assumption that they can be easiyl replaced [22:06] and we allow Firefox in main :) [22:07] LLStarks: somewhat yes. but MPL is really a mess [22:07] its not really feasible to require you to keep your stuff 6 month online [22:07] what happens if you dont have money anymore or something happens with your hosting etc. ;) [22:07] would people have a ****-fit if we shipped abrowser? [22:07] or the world blows up [22:08] LLStarks: not sure. we intentionally didnt choose iceweasel [22:08] not because we think its wrong for debian. but because we think there is too much wrong understanding about why and what caused this [22:08] like: mozilla thinks that debian wanted to ship low-quality ;) [22:09] mozilla == mozilla community folks [22:09] and the world thinks something that is highly biased by misinformation [22:09] they might have read a slashdot article or a bunch of rants etc. ;) [22:16] asac: is that menu translation worth throwing in? [22:18] micahg: prism? [22:18] bug 448683 [22:18] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/448683) [22:18] * micahg kicks ubottu [22:18] bug 448683 [22:18] launchpad is really bad mood today [22:18] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/448683) [22:19] https://launchpad.net/bugs/448683 [22:19] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/448683) [22:19] identi.ca is also in bad shape :/ [22:19] cannot send a dent through webinterface [22:19] change slovak translation of menu entry in firefox-3.5 [22:20] hmm [22:20] micahg: for karmic? [22:20] yeah [22:21] can you tag that as karmic-updates ... and since thats afe enough we can also add it to the branch already ... maybe verify that this guy is really LP admin of slovak [22:21] i might do another upload of trivial stuff [22:21] so we can stack that alrewady [22:22] in worst case it goes out in sec update [22:22] tag == milestone ;) [22:24] BUGabundo: hi buga [22:25] ;) [22:25] BUGabundo: so ... i heard that a huawei linux patch landed? [22:25] i duped your bug ... was that uploaded yet? [22:25] duped your duped bug ;) [22:25] asac: done [22:26] micahg: proposed against .head or .karmic? [22:26] boas noites [22:27] hey asac [22:27] bonas evening [22:27] asac: let me check bug mail [22:27] k [22:27] I read the linux bug two days ago [22:27] idk, I didn't do anything yet? [22:27] very *very* nasty bug [22:27] yes. but i thought it was fixed and i duped your bug into that [22:27] micahg: no [22:27] if we go GOLD without a fix [22:27] micahg: https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.head ... https://code.edge.launchpad.net/~mozillateam/firefox/firefox-3.5.karmic [22:28] micahg: imo its enough if you propose it against .head and tell that you want a cherry-pick to .karmic [22:28] ok, so you want me to make a branch for it? [22:28] at best add your name like [...] in .head changelog so the cherry pick will automatically do the right thing [22:28] micahg: no ... just propose the .desktop update against .head [22:28] the reported is a member of the slovak translators [22:28] and say that you want it to be cherry-picked to .karmic [22:28] ok, a merge request? [22:29] micahg: thats the usual way [22:29] ok [22:29] we should talk about a better way soon i guess ;) [22:29] that's what I was asking [22:30] So I assigned to em [22:30] me [22:30] yeah [22:30] micahg: so basically we want this everywhere [22:30] not sure if we have translations for 3.7/3.6 at all [22:30] asac: probably [22:30] I'll check [22:30] but if .desktop has it we should follow the rule of thumb to not land something on branches if it isnt landed on more experimental branches [22:30] at least for the desktops [22:30] yes [22:46] grrr, karmic ships with a 2~3 months old libvirt, 2 upstream releases late [22:48] where are our package bzr branches? [22:50] good question [22:50] maybe code.launchpad.net/ubuntu/package ? [22:50] fta: you just need to find a bug that was fixed [22:50] usually the branches get auto attached there [22:50] well ... fixed in upload ,) [22:50] checking ffox upload [22:50] something a bit older [22:51] https://edge.launchpad.net/bugs/236853 [22:51] Launchpad bug 236853 in firefox-3.5 "firefox crashed with SIGSEGV in NSSRWLock_LockRead_Util()" [High,Fix released] [22:51] i expected something like http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/libvirt [22:51] fix uploaded end of sep [22:51] launchpad doesnt like me ;) [22:51] slow [22:51] fta: yes. there are brnaches [22:51] lp:ubuntu/jaunty-proposed/firefox-3.5 [22:51] https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/jaunty/firefox-3.5/jaunty-proposed [22:51] hah [22:51] ~ubuntu-branches [22:52] https://code.edge.launchpad.net/~ubuntu-branches/ [22:52] that must be huge ;) [22:52] guess launchpad goes down now ;) [22:52] wow [22:52] 1 → 100 of 179152 results [22:52] too bad [22:52] one cannot step down ... like [22:52] https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/ [22:52] or https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/karmic [22:53] found it, https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/karmic/libvirt/karmic [22:53] yeah [22:53] now we understand ;) [22:53] !libvirt [22:53] Sorry, I don't know anything about libvirt [22:53] !firefox [22:53] firefox is the default web-browser on Ubuntu. To install the latest version, see https://help.ubuntu.com/community/FirefoxNewVersion Installing plugins: https://wiki.ubuntu.com/FirefoxPlugins - See also !firefox-3.5 [22:54] that should probably also have the launchpad and the branch page [22:54] and also respond to source package names ;) [22:54] !source karmic [22:54] Sorry, I don't know anything about source karmic [22:54] !source firefox [22:54] Sorry, I don't know anything about source firefox [22:54] !libvirt source [22:54] Sorry, I don't know anything about libvirt source [22:54] hmm [22:54] !package firefox [22:54] Sorry, I don't know anything about package firefox [22:54] !package firefox-3.0 [22:54] Error: I am only a bot, please don't think I'm intelligent :) [22:54] !info firefox [22:54] ah [22:54] ok [22:54] that one i mean [22:54] firefox (source: firefox-3.5): meta package for the popular mozilla web browser. In component main, is optional. Version 3.5.3+build1+nobinonly-0ubuntu4 (karmic), package size 71 kB, installed size 128 kB [22:54] hehe [22:54] !info libvirt [22:54] Package libvirt does not exist in karmic === BUGabundo1 is now known as BUGabundo [22:54] !info libvirt0 [22:54] libvirt0 (source: libvirt): library for interfacing with different virtualization systems. In component main, is optional. Version 0.7.0-1ubuntu12 (karmic), package size 395 kB, installed size 1040 kB [22:55] asac: just got a strange pop up [22:55] !info libvirt/source [22:55] Package libvirtsource does not exist in karmic [22:55] and nm-applet blew [22:55] BUGabundo: yes [22:55] BUGabundo: thats a daily bug [22:55] soemthing about not albe to find necessary resources [22:55] ok [22:55] debian has 0.7.1 and they already moved to policykit [22:55] we targetted it for karmic-updates [22:55] one second [22:55] i need 0.7.2 [22:55] reported :) [22:55] today [22:55] i got it NoelJB got it ... now you [22:55] guess its High [22:55] ;) [22:56] bug 456468 [22:56] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456468) [22:59] bug 456468 [22:59] Launchpad bug 456468 in network-manager-applet "upgrade triggers nm-applet "resource not found" ... missing icon "nm-applet-device"" [High,Triaged] https://launchpad.net/bugs/456468 [22:59] bots like me better :) [22:59] subbing [23:00] asac: your patch got accepted :) [23:02] micahg: which one? [23:02] the one? [23:02] ;) [23:02] one liner [23:02] mozilla bug 521780 [23:02] Mozilla bug 521780 in Add-ons Manager "extension upgrade with a moved location breaks extension manager" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=521780 [23:02] good [23:03] well. i was sure it was [23:03] wouzld [23:03] ;) [23:03] so, I know what I'm working on, asac, you're fixing the FTBFS for ff3.5 daily? [23:04] micahg: yes right now [23:04] ;) [23:04] thx for remidng [23:04] ok [23:07] done [23:07] rev 490 [23:08] asac: this FF annoying yellow bar about restarting FF, is *annoying* [23:09] BUGabundo: I think it's supposed to be :) [23:09] its ANNYOING [23:09] I already pressed the cross [23:09] I don't want to hear more about it!!! [23:09] BUGabundo: screenshot [23:09] BUGabundo: if you get that ... you are close to getting a bad firefox ... so better restart [23:10] the warning does what its supposed to do ... it stays there [23:10] ;) [23:10] uploading [23:10] if you dont restart your ffox will go bad [23:10] http://dl.getdropbox.com/u/112892/Screenshot.png [23:10] yes [23:10] restart [23:10] ;) [23:10] more i cant say ;) [23:10] know your rights! [23:11] well. if you dont restart soon worst thing is that in some rare occasions you might even loose data [23:11] asac: I hope you didn't delete debian/patches/series :X [23:11] :x [23:11] or end up with otherwise corrupted data in profile etc [23:11] shit [23:11] micahg: i will uncommi and fix comment [23:11] sorry ... bad practice ... i know [23:12] how come will we ship karmic with 78 outstanding merges and 255 updated merges just for main?? [23:13] restarting FF [23:14] asac: better ;) [23:17] fta: i think there is no general answer [23:17] fta: i will try to figure out if this cycle something went wrong in our process [23:17] but lots of outstanding merges are most likely packages maintained here [23:18] like network-manager [23:18] asac: where can I find tagged builds from mozilla? [23:18] not sure if someone blacklisted it from that list already [23:18] good question [23:18] http://ftp.mozilla.org/pub/mozilla.org/firefox/ [23:18] i would think there [23:18] releases? [23:18] maybe [23:18] mostlikely [23:18] but not sure [23:18] [reed]: ^^ ? [23:19] hmm. i know there are build3 builds out there for 3.5.4 [23:19] but no folder like that [23:19] micahg: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.4-candidates/ [23:19] so here http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ [23:19] ah [23:19] seems they put candidates there [23:20] so I need to respin my 3.6b1 [23:20] not sure if they keep them around though [23:20] build2 is out [23:20] micahg: if you made a build1 ... then yes. [23:20] I do the same process? [23:21] micahg: so if you simulate what we would do in a "normal" security/stability update you would just flip the text you added in current topmost changelog [23:21] but besides from that follow same procedure [23:21] e.g. not a full new release [23:21] changelog-wise [23:21] but not sure if you have branches at all for those [23:21] but I get-orig-source again like alst time? [23:21] yes [23:21] ok [23:21] just with new tag [23:21] got it [23:21] micahg: check out how i document security stability updates in stable branches like .jaunty etc. [23:22] i think for beta build1,2,3 it should be similar [23:22] https://merges.ubuntu.com/main-trend.png [23:22] not stability/security update of course ;) but rather "beta release build1 (FIREOFX_...BUILD1) [23:23] our libvirt is too different from debian, too much work for me just to try if it fixes my problem :( [23:24] DO I add a new comment or just edit the current one, since it's not official? [23:28] micahg: what i meant above is that you edit the build1 comment [23:28] ok [23:28] open it with UNRELEASED again [23:28] edit [23:28] upload ;) [23:28] adjust version of course [23:29] it should say unreleased? [23:29] so if you previously had like 3.5.1+build1-0ubuntu6 ... you would go to [23:29] 3.5.1+build2-0ubuntu1 [23:30] micahg: well. if things go to anywhere official we close changelogs. as they might potentially get released. if you want to simulate that process, then you close it for the upload [23:30] but reopen in case build2 comes ... because that basically means that the build1 got never released [23:30] well, I changed unreleased to karmic since I needed to upload [23:30] so process is: "release" a +build1 to some staging area [23:30] in case that gets officially released later upstream we copy that to the real release area [23:30] in case it doesnt we upload +build2 to t he staging area [23:31] same game [23:31] thats why build2 is not a new changelog entry [23:31] I didn't make a bzr branch for it [23:31] because build1 never hits the release channel ... just staging [23:32] micahg: right. for upload you always need to release (technically) [23:32] ok [23:32] just wanted to make sure I didn;t mess something up [23:33] no. if you do it in your ppa and dont do a branch you want to get into .head [23:33] then you cannot do much wrong [23:33] except choosing a wrong version [23:34] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446146 still no updates :( [23:34] Launchpad bug 446146 in linux "Huawei E169 USB dongle not working with kernel 2.6.31-12.40" [Medium,Fix committed] [23:34] oh ok [23:34] so it was really just committed [23:34] too bad [23:34] BUGabundo: its a karmic-updates bug [23:34] will get released in first kernel SRU [23:34] which i would think will happen pretty soon after release [23:34] asac: SO BAD :( [23:35] SRU is really bad [23:35] anyone using livecds won't have internet [23:35] well. thats the process [23:35] I hope they fix ath9k [23:35] so how are those users expected to upgrade? [23:35] its like a big boat ... driving through a whole with high speed [23:35] so you cannot really stop at some point or change a different route [23:36] micahg: what ath9k issues do you see? [23:36] regular disconnects (like NM disconnects) ... or regular packet loss? [23:36] wireless disconnects semi-frequently still [23:36] or bad state and need reboot [23:36] need to modprobe -r and add back after suspend [23:36] disconnects like: really drops or package loss? [23:36] both [23:37] asac: for me and lot of users [23:37] it warrants the ship date to be changed [23:37] its a critical bug [23:38] BUGabundo: maybe go poke #ubuntu-kernel [23:38] they wont do a kernel upload before release i think [23:38] problem is that we release time based [23:38] let me update the bug then [23:38] asac: it's a critical bug [23:38] that has risks and has benefits [23:38] should be considered [23:39] it is considered [23:39] its fix committed [23:39] leaving users stranded without internet [23:39] is not a solution [23:39] it is not considered to hold back the release [23:39] ok [23:39] i cannot say thats right or wrong :) ... answer is that i dont know [23:39] so bye bye internet [23:39] i know that if one is struck by a bug [23:39] me and many other users depend on 3G modems [23:39] then its critical for one self [23:40] I haven't been able to access intenet on my laptop for 3 weeks now [23:40] BUGabundo: so basic idea is that you upgrade with jaunty on ... and all the updates get automatically installed. [23:40] asac: last release was after freeze [23:40] BUGabundo: so in theory it could be added to release notes [23:40] they could upload another fix [23:40] prob here is no updates! [23:40] those with net to get updates will get the newer kernel too [23:40] as long as it is available as soon as release [23:41] the prob here is users on livecd installing a fresh system [23:41] the problem with the kernel is that you cannot just upload it and hope all is fine [23:41] so if you upload it and everything breaks its a mess [23:41] its a real huge overhead to do a release [23:41] firefox is a huge overhead too for security updates [23:41] lots of testing [23:41] but by far not as much that you need on a kernel [23:42] so you upload that and then all different hardware testing and all stuff needs to be rerun etc. [23:42] and QA has to stop ...s tart from scratch [23:42] all vedded and community tested images, trashed [23:42] I understand that [23:42] its not easy ... not saying that there is no potential improvement ;) [23:43] if it can't be done on time [23:43] it should be delayed [23:43] I know its bad pub [23:43] I know pleanty of ppl are counting on it [23:43] but a critical bug for a big subset of users [23:43] is not acceptable [23:43] yes. but problem is that all hardware that doesnt work or regressed will be critical for whoever has that hardware [23:43] so you woul dhave to fix _all_ hardware regressions [23:43] its a 3 week bug [23:43] thats not possible [23:43] an huge regression [23:44] for the hardware affected [23:44] yes. [23:44] the closer you get to release the higher threshold you get on things that will be considered release critical [23:45] i agree that its not obvious what would hold back a release [23:46] 10% users affected enough? [23:46] asac: is this ok for a changelog entry? * Test release of 1.9.2 beta 1 build 2 (FIREFOX_3_6b1_BUILD2) [23:46] how about all the bad pub?? [23:46] micahg: yes. [23:46] its not something that can be fixed _after_ install!!! [23:46] BUGabundo: users usually boot livecd [23:46] if that device does not work you know that you cannot use it [23:46] and no net there [23:47] so you wouldnt install [23:47] how many will test 3G there before install? [23:47] if I give a CD to someone [23:47] if you upgrade ... you know that upgrading on first day is proably a bad idea - just out of common sense [23:47] they install it [23:47] and endup without net [23:47] I know, 2 years ago [23:47] we didn't even had support for it :) [23:47] BUGabundo: you give a CD to someone to test. they test it and if it works for them well they install it [23:47] but now, we depend on it [23:47] thats how it should be imo [23:48] BUGabundo: yes. its a problem. as i said, all hardware regression is critical for those that have that hardware [23:48] if we follow through with what you would like we would never release [23:48] because every new kernel version will hav hardware regressions [23:48] I know [23:48] BUGabundo: you can fix after install with a wired connection [23:49] so thats why if it doesnt really matter when you release [23:49] we would need to look at "how much hardware regressed" [23:49] compre that to jaunty [23:49] yes. and in worst case most people will be able to get net somewhere [23:49] wifi from friend/neighbour [23:49] or lan [23:49] in internet cafe [23:49] opf course annoying [23:50] but checkout what happens if you give a random guy to install a pure windows [23:50] on a blank system [23:50] they will have no net ...m aybe no keyboard, nothing ;) [23:50] ugly vga graphics card. ;) [23:51] so user has to go to internet cafe and download all kind of drivers ... on a separate machine and then copy that somehow over ;) [23:51] not saying thats something we should compare with [23:51] just that we should compare same things [23:51] and not forget what how good/bad other things are [23:51] still we should have an idealistic goal ... zero bugs [23:52] asac: currently at 70k+ open :) [23:52] asac: I've entered my view on the bug :) [23:52] lets hope for the best [23:52] but what any OS needs is not a "easy way to get a perfect install on random hardware you found or build together" [23:52] BUGabundo: yeah [23:53] continue .... it needs "mass factory installs of LTS" ... ;) [23:55] asac: can I use the same tarball for xulrunner and firefox? [23:56] micahg: no [23:56] ok [23:56] micahg: well. its probably the same inside [23:56] but i wouldnt rely on it [23:56] needs knowledge of the mozclient details [23:56] ok, I'm building a new one for firefox [23:56] micahg: you could help fixing the LOCAL_BRANCH feature for mercurial [23:56] so you can just have one local branch [23:56] ;) [23:57] maybe someday [23:57] hehe [23:57] right [23:57] where is that, in mozclient? [23:57] or in actual hg? [23:57] micahg: you can do ./debian/rules get-orig-source ... LOCAL_BRANCH=/path/to/local/clone/of/hg/or/git/or/bzr/tree ;) [23:57] so it will not get the initial clone from the remote location [23:57] rather update the existing checkout/clone [23:58] and use that to prepare orig [23:58] much faster [23:58] ;) [23:58] micahg: oh "where" ;M) [23:58] its in Mercurial.pm [23:58] or something [23:58] yes, but in m-dev? [23:59] micahg: yes [23:59] ther eis a mozclient/ directory in source [23:59] is there a bug for it? [23:59] i had it on my personal todo list [23:59] let me check [23:59] asac, there's a bug in my LOCAL_BRANCH code in m-d, remember? [23:59] yes [23:59] thats what i am talking about [23:59] oh, ok