[00:06] mahfouz1: I'll file it as an enhancement request [00:06] it's currently win only [00:06] but they might make it optional on linux [02:28] micahg: yes, would be great, since they might stop some of the add-ons with that functionality [02:29] If it's not implemented in linux, then that functionality might get lost [05:51] hello there, i managed to install official mozilla firefox(from ubuntuzilla) and other mozilla based apps (songbird and flock) in ubuntu, but they dont follow my font settings; is there a way i can fix this¿¿ [05:52] xangua: we only support the Ubuntu versions [05:52] i also could see this problem in the mozilla testing build PPA [05:52] xangua: k, there are a few bugs for fonts in firefox-3.5 [05:53] which specific font setting? [05:53] half size? [05:53] antilasing [05:53] the font looks ugly :S [05:53] xangua: I think you should look at bug 379761 [05:53] Launchpad bug 379761 in fontconfig "MASTER - FF 3.5 font hinting does not honour gnome-settings" [Undecided,New] https://launchpad.net/bugs/379761 [05:54] micahg: thanks, i'll see it [05:54] xangua: there's also bug 67226 [05:54] Launchpad bug 67226 in firefox-3.5 "[karmic] Firefox 3.5 and openoffice do not stick to antialiasing render settings" [Low,Triaged] https://launchpad.net/bugs/67226 === \vish is now known as vish === asac_ is now known as asac [09:15] morning === BUGabundo_work is now known as BUGabundo_lunch === gandi_ is now known as gandi === BUGabundo_lunch is now known as BUGabundo_work [14:36] micahg: you around? [14:37] gnomefreak: yes [14:37] micahg: did you ask me about sunbird/seamonkey ~2-3 weeks ago? [14:37] yep [14:38] * micahg still needs to get the -dev packages right [14:38] micahg: ok cool, feel free to package them i have run into some personal problems and they wont be cleard up for atleast 3 more weeks. [14:38] gnomefreak: sorry to hear that [14:38] gnomefreak: I'm a little behind myself (TB3 isn't out yet ) [14:39] micahg: its ok it should be easly taken care of just have to wait until i can [14:39] ah [14:39] k [14:44] any plans on grabbing Debians instabird package to include in Lucid? [14:45] looks like Mike is asking -mentors(Debians) to test atm [14:48] gnomefreak: idk, I can ask asac [14:48] there's a lot to do this cycle already with the FF3.6 migration [14:48] micahg: ok thanks, if i see him i will ask him but not sure how long i will be here. i have a whole bunch of emails to clean up [14:49] micahg: ah [14:49] * micahg also has to package pyxpcom [14:51] 6 weeks to alpha 3 so I should be able to make it [14:51] cool [15:05] * BUGabundo_work hugs gnomefreak [15:22] asac: any ideas about http://pastebin.ubuntu.com/355243/ === yofel_ is now known as yofel [15:29] ccheney: yes. you lack the type definition somewhere [15:29] e.g. probably you have the typdef, but not the struct [15:39] asac: gnomefreak wanted to know if we were interested in instabird from debian [15:44] micahg: if it enters testing it probably automatically comes to us, doesnt it? [15:44] asac: it should before freeze, I was wondering if we needed to do anything special with it [15:46] asac: any reason Debian is still using icedove-* for extenstions? i thought this was going to be changed [15:47] or even ice*-* [15:47] gnomefreak: its a slow process [15:48] as long as no new get added i am happy [15:48] hi btw [15:48] hope you are all fine ;) [15:48] asac: ok. and hi :) [15:48] micahg: we will see once it arrives. if it fails to biuld/start we need to check [15:48] we shall see [15:48] asac: k [15:48] asac: the typedef for sockaddr_un ? [15:49] asac: not using bind dn to d/l a directory in TB is a minor issue on TB2, right? [15:50] * ccheney thinks he must have forgotten something important wrt C [15:51] ah nm i see why i got confused [15:51] its defined but at a lower level than glib [15:52] asac: nm [15:53] * ccheney needs to write code more often, he is getting too rusty [15:54] hmm even with adding the proper header it seems to not work :( [15:54] ccheney: whatever type is used in those lines [15:54] doesnt have the full struct there [16:01] was it Karmic that we are not renaming Shiretoko to firefox-3.5 or just Lucid? [16:01] gnomefreak: Jaunty [16:01] micahg: ok thanks [16:01] asac: yea appeard to be sockaddr_un which is in sys/socket.h but after including it still failed in the same way [16:01] and it they'll probably get migrated to firefox 3.6 anyways gnomefreak [16:02] ccheney: unlikely to be sockaddr_un if its in socket.h [16:03] oh i misread the contents of the header, i need more caffeine [16:03] looks like its linux/un.h actually [16:04] or sys/un.h [16:04] * ccheney does a test build and gets caffeine [16:05] micahg: why are we backporting 3.6 to stqable releases? [16:06] gnomefreak: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model [16:08] yipee that fixed it :) [16:11] asac: got time for anothe build failure? [16:11] micahg: thanks will look in a min [16:11] micahg: post it [16:12] ccheney: i would expect you wouldnt need to pull in anything that isnt in glib headers [16:12] so maybe they copied that header? [16:12] in glib2.0? [16:13] its included via gio/gnetworkingprivate.h [16:14] asac: /bin/sh: Syntax error: end of file unexpected (expecting "}") [16:14] right. so pull that in [16:14] micahg: thats a syntax error [16:15] ;) [16:15] right, http://launchpadlibrarian.net/37762020/buildlog_ubuntu-lucid-amd64.thunderbird-3.0_3.0.2~hg20100111r4629%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz [16:15] it's in TB3.0 and XUL1.9.3 [16:15] in lucid only [16:15] so my guess is a toolchain issue on amd64 [16:15] oh, and amd64 only [16:15] try to find if its a recent commit [16:15] thats causing this [16:17] ok will be AFK for a while. im sure i have hundreds of updates from the past month or so. [16:21] i'm confused as to how the get_type functions work [16:21] they look like this extern __typeof (g_inet_address_get_type) IA__g_inet_address_get_type __attribute((visibility("hidden"))) G_GNUC_CONST; [16:21] asac: they're different branches and the issue started the same day [16:21] that is the only referenced code i can find but i am not sure what that does but it doesn't look a function definition [16:22] * micahg guesses he should look at lucid uploads for that day :) [16:38] asac: is there a way to tell which file is failing? [16:38] * micahg can't find a common commit between the branches [16:41] micahg: i would think something in /build/buildd/thunderbird-3.0-3.0.2~hg20100111r4629+nobinonly/build-tree/mozilla/mozilla/modules/libpr0n/build [16:44] asac: yep, but those files haven't touched in quite a while [16:44] i think we need to reprduce it locally and keep the tree to investigate [16:45] ok, I'll have to do that later [16:45] it's lucid only though [16:45] can I ask pbuilder not to purge? [16:46] check what was uploaded since last build success [16:46] maybe sh [16:46] etc. [16:46] you shouldnt use pbuilder for core stuff for development/triaging [16:46] asac: there was a dash upgrade [16:46] just to try if clean build works [16:46] asac: I don't have lucid [16:46] setup a chroot [16:46] asac: k [16:47] debootstrap is your friend [16:47] asac: is there a bzr trick to build in a chroot? [16:47] so dash update feels like a good thing to look at [16:47] if you hvae it locally build fail you can try tro downgtrade [16:47] micahg: you mount your /home in chroot [16:47] then you can just use it as usually [16:48] bindmount [16:48] there is some wiki page how to setup a good chroot for development [16:48] you also need to bindmout more stuff like /proc /dev etc. [16:48] k, I'll look later [16:48] have to get ready for work now [16:49] kk [16:50] asac: BTW, I created a pyxpcom LP project [16:50] and made mozilla team the maintainer [16:50] sounds good [16:50] mainter? or owner? [16:50] maintainer [16:52] maintainer is owner I think [16:53] projects have maintainers/teams have owners AFAIK [16:57] ok ;) [17:17] asac I was told to ask you about MCP51 Ethernet in lucid [17:18] * BUGabundo_work ducks [17:18] doesnt work for me [17:20] we do not have any packages that recommend packages not in archives do we? [17:20] thunderstruck: we shouldn't...you have an example? [17:20] thunderstruck: oh, yeah, maybe [17:21] micahg: bug 506528 [17:21] possibly recommending debian versions of ff/tb [17:21] Launchpad bug 506528 in ubuntu "Please remove all recommends that we do not supply in archives" [Undecided,New] https://launchpad.net/bugs/506528 [17:21] * thunderstruck could use examples if we have any for mozilla [17:21] damnit === thunderstruck is now known as gnomefreak [17:22] much better :) [17:22] gnomefreak: I knew it was you anyways :) [17:22] * gnomefreak should fix that for irc [17:22] gnomefreak: well, when we remove something, we endeavour to migrate all rdepends [17:23] gnomefreak: I think you're better off filing specific bugs if you see something rather than a broad based bug like that [17:23] well it makes no sense that we have people go outside our repos since we do not support it and it may be hard for new users [17:23] gnomefreak: indeed, it's probably either something from a debian import or something legacy in most cases [17:24] micahg: i have no way to know them other than goiing through each package and trying to install them [17:24] gnomefreak: I suggest posting to the ubuntu-devel-discuss ML [17:24] IMHO its better to have people remove them during packaging [17:25] soryr [17:25] ubuntu-devel@lists.ubuntu.com [17:25] will do [17:25] no [17:25] that's not right... [17:25] hold on [17:26] asac: any idea about the weird IA get_type functions? [17:26] asac: i'm not sure what i am supposed to copy over and how to make the get_type functions to work [17:26] gnomefreak: no, I was right, I think [17:26] yep you were :) [17:26] k [17:34] ccheney: which one? [17:36] fta2: i marked https://code.edge.launchpad.net/~network-manager/network-manager-applet/network-manager-applet.head.daily as abandoned [17:36] so it doesnt show up in the active branch list [17:36] eg g_inet_address_get_type [17:36] so if you get troubles because of that just shoot [17:36] they seem to have no function body [17:36] usually those get defined by G_TYPE_DEFINE macros [17:36] search for those in .c files [17:36] rather G.*TYPE_DEFINE [17:37] well there is like this: [17:37] #define G_TYPE_INET_ADDRESS (g_inet_address_get_type ()) [17:37] and then [17:37] GType g_inet_address_get_type (void) G_GNUC_CONST; [17:37] but no body for the g_inet_address_get_type itself [17:37] it has some sort of weird IA_(blah) stuff but i don't understand how that stuff works [17:38] eg - extern __typeof (g_inet_address_get_type) IA__g_inet_address_get_type __attribute((visibility("hidden"))) G_GNUC_CONST; [17:38] that doesn't actually do anything does it? [17:38] except set the symbol as inivisible in gcc(?) [17:39] yes, that hides it [17:39] in another area i see: extern __typeof (g_inet_address_get_type) g_inet_address_get_type __attribute((alias("IA__g_inet_address_get_type"), visibility("default"))); [17:39] dont know what __typeof [17:39] that defines that g_inet_address_get_type is rather IA__g_inet_address_get_type [17:39] aka alias [17:41] ah so i need to copy both of those to my header? [17:41] and then it should just work i guess? [17:41] most likely [17:41] yes [17:41] both defs and the impl for IA___ [17:41] if there is any ... otherwise there must be a G_DEFINE.*TYPE or something in the ia_ source [17:41] i don't see any impl for the IA__ [17:42] hmm ok [17:42] as i said, thats generated by a macro [17:42] you can build with -save-temps [17:42] and see what gets created and try to find that [17:42] oh ok [17:52] _DEFINE_TYPE_WITH_CODE (GInetAddress, g_inet_address, G_TYPE_OBJECT, _g_networking_init ();) [17:52] ./gio/ginetaddress.c [17:53] ok [18:24] asac: what you tweeted is a feature [18:25] it only searches the beginning of URLs, not the title [18:25] really? [18:25] sucky then ;) [18:25] so if it's wiki.ubuntu.com/Whatever/Whatever [18:25] thats what i thought [18:25] if you search for Whatever it doesn't find anything [18:25] well. it definitly searches the url [18:25] but if you have whatever.blah.com it finds it [18:25] i can find stuff in the middle of urls at least [18:25] thats not true ;) [18:25] are you sure it's not the title of the page? [18:26] https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList [18:26] go to that page [18:26] afterwards you will find it by Thumb2 [18:26] hmm [18:26] oh so you say it searches the title? [18:26] just not the url? [18:26] correct [18:26] sec, I have the upstream bug [18:26] they do it for performance reasons [18:26] dont mind. firefox behaviour is definitly rockier ;) [18:27] FF fills in as it finds them iirc [18:27] ok [18:27] FF returns better results imo [18:27] * asac thinks that the performance isnt that great atm either [18:27] yes [18:27] ff rocks ;) [18:27] i often go back to it because i just cannot find the url in chromium ;) [18:28] but thanks for clarifying. [18:28] http://code.google.com/p/chromium/issues/detail?id=367&can=5&colspec=ID%20Stars%20Pri%20Area%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS#c7 [18:28] I was wondering that last week too because it drives me mad [18:28] thats the other annoying thing ;) [18:28] the URL of issues is always busted if you use find [18:28] you only have one "other" annoying thing? :p [18:28] and posting takes effort to strip it (of course different front) [18:29] yes, otherwise i am happy ... oh wait!! [18:29] there is this voip problem in combination with pulse ;) [18:29] that regularly gives me real pain and heart attacks [18:29] when i need to dial in somewhere and folks dont hear me etc. [18:30] so now i alwasy first call google search [18:30] I have been pretty lucky so far. [18:30] then if that works, dial in somewhere ;) [18:30] have you tried google search call service? [18:30] no I have some voice thing on my g1 that does that [18:30] where you go "I need to find the nearest pizza place" [18:31] sure its the same? [18:31] darn [18:31] yeah [18:31] ok [18:31] and it returns "Your request for finding carburators and marbles is pending." [18:31] i am happy ot have it to test my voip ;) [18:31] echo service always takes like a minute before i can test my own void [18:31] voice [18:31] 0018004664411 [18:31] thats the number ;) [18:33] the other thing most annoying is my internet sucking [18:50] fta2: btw, feel free to upload gyp to archive as often as you want ;) [18:50] like after landing of licenseing issues etc. [18:50] not that i need to tell you that ;) [19:25] asac, sure. btw, what's the status of the chromium review action point? [19:31] fta: i need all license full textx referred to in the whitelist [19:31] with that we are fine [19:31] MINUS [19:31] Ms-Pl [19:31] that license is GPL incompatible [19:31] aka illegal to distribute ... a [19:52] fta: so if you feel like it help on finding the full license texts somewhere is appreciated. will probably take another week otherwise : ... and i would love to just upload :) [19:58] there's a new beta available, i'm working with upstream to have the channels updated (there's a wrong DEPS file and/or a too strict gclient) [19:58] asac: will it be uploaded into Debian as well? [19:59] asac: I would love seeing it there as well [19:59] and`: once its went through our archive admins i will try. [19:59] but i guess that will get rejected in debian for a bit longer [19:59] or take a year to review ;=) [19:59] and`: you can help ;) [19:59] asac: sure [20:00] find the full license texts referred to in the whitelist of licnsecheck.pl [20:00] and make a file dep-5 file tail [20:00] with those [20:00] e.g. License: BSD (3-clause) [20:00] ... [20:00] http://pastebin.com/f5b903399 [20:00] thats the licensecheck with the whitelisted license [20:01] they are somewhere in the chromium orig ;) [20:01] we just need to prepare a dep-5 style file with them all [20:01] http://people.canonical.com/~asac/tmp/copyright.full -> that might give an good indication where to look for that in the source tarball ;) [20:01] asac: to summarize it: it's a pain :) [20:01] well. I went through massive pain already ;) [20:02] so a bit pain on other shoulders is acceptable ;) [20:02] its minor pain [20:02] yes, understood what you mean, did that with some GNOME packages but they had far less source files than chromium has :D [20:02] compared to going through all files like i did ;) [20:02] and`: you dont need to make the dep-5 file [20:02] i just need the License parts [20:02] e.g. [20:02] License: ... [20:02] FULL license text [20:02] we already have the actual copyright stuff [20:03] http://people.canonical.com/~asac/tmp/copyright.full [20:03] that was the main pain i went through [20:03] omg :D [20:03] and`: in the first paste there are like 20 licenses. those wee need to collect [20:03] somewhere [20:03] either in dep-5 or as individual files so we can generate the dep-5 [20:03] and append that to the copyright.full thin i posted [20:05] uploads to debian will definitly happen without testsuite and without -dbg package. at least until fta is uploader and can push th binaries through his big pipe :) [20:05] i dont feel like uploading 1G ;) [20:05] ccheney: all moving smoothlie? [20:05] asac: I can help with letting it through [20:05] yeah ;) [20:05] first help on the LICENSE files please [20:05] asac, aren't we supposed to just put links to the well known licenses, instead of the full texts [20:06] fta: we still need to add the short form for those that are in well known [20:06] but htose are not my concern [20:06] my concern are all the bsd variants and the bsd-like and stuff like that [20:06] there are plenty that arent in common :) [20:07] asac, why would you need to upload dbg? (there's no more testsuite debs btw) [20:07] but and` probably knows better what to do [20:07] fta: there is no testsuite debs anymore? [20:07] did we drop that? [20:07] great! [20:07] yes, months ago [20:07] or was that never there and my brain is choking [20:07] ok [20:07] and no -dbg? [20:07] i assume we probably want those [20:08] esp. in debian there is no dbgsym [20:08] asac: yes, don't fully count on me these days for doing it extra-fast, just finished holidays and need to prepare exams and stuff, so it will take some time : / [20:08] and`: do it in small chunk [20:08] each license you collect is a clear win ;) [20:08] we need this this week [20:09] otherwise world is going to die [20:09] lol [20:10] asac, dbg is there, but you don't upload that.. unless debian needs binary debs too?? [20:10] fta: yes, Debian uses binary uploads [20:10] so no -dbg ;) [20:11] 78.6MB (dbg) [20:11] uploading that would be simply crazy :D [20:11] testsuite-deb used to be 800MB++ [20:11] dbg [20:12] fta: when uploading it to Debian you need to make sure that those are not built [20:12] otherwise it will be harder to have it accepted [20:12] 80MB is not that big, openarena-data is way bigger [20:12] imho, -dbg is mandatory [20:13] otherwise, byebye crash reports [20:13] fta: debian needs them thats the point why i complaining ;) [20:13] you basically push all sources + all binaries for one arch + all [20:13] well, as long as chromium-browser doesnt directly depend on an 80 mb package, that's fine [20:13] thats why i refuse to do security updates in debian nowadays [20:14] they should fix their retarded system first [20:14] asac: well, binary uploads are a pain but prevents broken packages to get in [20:14] well. thats a dubious point [20:14] ppl don't test-build their packages and that's why we have tons of FTBFS [20:15] it also ensures that you never know whether your binary was actually biuld from clean source [20:15] so there's no way to have chromium in debian, not enough arch coverage [20:15] debian just sticks to old models [20:15] asac: DDs know how to build properly a package [20:15] then they should also know that they should test a package before uploading [20:15] so you can upload source only ;) [20:16] fta: why? [20:16] not enough arch coverage? [20:16] well, that's not a direct procedure, if you know you need to do a binary upload you *have to* build it before [20:16] what does that mean? [20:16] and`: yes, but if it fails you can just fix it and continue. or workaround and sign and upload :) [20:16] someone might say 'well, I'm sure it will build fine', he does a source upload and then another FTBFS [20:16] all happened [20:17] point is: binary only doesnt give you much [20:17] if the sources dont build the damange is zero [20:17] except wasting some buildd time [20:17] asac, the plethora of arches debian supports, we can't provide those binaries [20:17] -> which was reasonable at some point in the 90th ;) [20:17] fta: doesnt matter [20:17] you upload with any ... if it never built on an arch its not a problem that it fails [20:18] idea is that porters can then start on that [20:18] only a RC bug if it previously built on an arch, but then doesnt [20:18] asac: well, I don't think building a package is such a pain before uploading (it might be if you maintain huge packages, but that's not what normally happens) [20:18] as that would be a regression for usres on upgrades [20:18] building not, but uploading if you upload big packages [20:18] also building is a pain [20:18] yes, I agree with you on that [20:18] i would never be able to do security updates for mozilla in the same scala we do it in ubuntu [20:18] I never had huge packages so that's why I'm not complaining atm [20:19] like two branches to 5 releases [20:19] -> never [20:19] ;) [20:19] right. but once you see your dsl provider being flaky and the whole upload being for nothing because the dbg package doesnt finish ;) [20:19] you know what i mean [20:19] asac: well, forwarding the fix to Debian would be enough :) [20:19] also then you have to send a dcut upload to first remove stuff from the incombing queue [20:19] another paranoid thing in debian [20:19] they are scared that someone would overwrite your uploads ;) [20:20] and`: i sent patches for quite some time to debian folks for mozilla [20:20] they often didnt even have the time to test them [20:20] nor upload [20:20] security patches [20:20] how many years ago? :) [20:20] not so long [20:21] 9month or so [20:21] or 1 year at most [20:21] e.g. when firefox 1.5 went EOL for us [20:21] i stopped doing backports [20:22] and since my patches often didnt get uploaded and i refuse to do that for a bit over a year now because of said reasons [20:22] i stopped doing that [20:22] (also i dont like it anymore) [20:22] unfortunately I saw that you left your packages a bit unmaintained in Debian (e.g icedove et all), and I didnt get why you stopped [20:22] not really [20:22] icedove 2 is tbird 2 which was dead for ages [20:22] now we have 3 [20:23] if you say unmaintained because of no bug triage thats a different issue [20:23] i just refuse to proxy for loads of bugs [20:23] i did the same for ubuntu [20:23] I don't see an upload from you in Debian since some time aparts sponsoring, which is ok since you have tons of stuff to do [20:23] now we can connect bugs with upstream in ubuntu and let the users talk directly [20:23] but someone else might see it in a different view [20:23] and`: because icedove had no release [20:23] i stopped security updates because of said reasons [20:24] well, you didnt maintain icedove only [20:24] enigmail is same issue ;) [20:24] or was it the only package? [20:24] mostly ... i also helped on iceape and did security for all mozilla packages [20:24] including xulrunner etc. [20:25] I would love seeing you a bit more involved in Debian as you were in the past, but that will be mostly impossible [20:26] I understand your points, I just think that if you don't have the time to follow those packages anymore, orphaning them would have been the right choice [20:26] which packages [20:26] all packages are good ;) [20:26] icedove is fine [20:26] I saw some of them got orphaned [20:26] not sure what you are saying [20:26] which ones? [20:26] with cause: not properly maintained [20:27] they were orphaned by glandium [20:27] if I remember it right [20:27] he orphaned xulrunner [20:27] none of my packages i hope [20:27] then i wanted to take it so i can sync debian and ubuntu [20:27] and he said he didnt orphan it for real ;) [20:28] iceape got orphaned, but that was a joint effort of debian mozillateam [20:28] and the debian mozillateam is a joke, because it waas me and mike ... and mike being unwilling to coorporate since i joined ubuntu [20:28] made that void [20:28] anyway, recently there is now more stuff going on there [20:29] but mostly by extension team [20:29] 8 RC bugs in icedove and 4 on iceowl, more than 400 open bugs, well maybe the bug tracker needs to be refreshed / cleaned a bit removing fixed / old reports [20:29] but for sure it needs work, like bluez does atm [20:29] feel free to work on the bug tracker [20:30] bluez does not have a maintainer anymore and that's a big issue since every bluetooth interface depends on it [20:30] if folks file bugs against an old icedove version that will not have any fixes for sure its not my business ;) [20:30] 2.* is dead now isnt it? [20:30] its for ages practically dead [20:30] thats why it doesnt make sense to put work into it [20:31] sure, but I read that the maint is Ubuntu Mozilla Team so cleaning up the bug tracker should be a maintainer's work [20:31] right [20:31] iceowl is dead too [20:31] nly extension survives [20:31] 1.0b*\ [20:31] luckily the ext team seems a bit more active after some time, at least that [20:31] also the only way to get anyone contribute to mozilla stuff seems to be to do just nothing [20:32] yes, but extensions are easy and fun work [20:32] mozilla software is painful and you dont find anyone helping out ... [20:32] starting someone in doing mozilla-related work is a pain, I know [20:32] and that's why I don't see any new face here since 4 years [20:32] extensions are a good stepping stone, but the step is quite big [20:33] we have a bunch of people working on mozilla apps. since upload priv... are hard to come by in Debian it makes it a bit harder to find willing people (as far as i see it) [20:33] like check the qa page out: http://packages.qa.debian.org/i/icedove.html [20:33] 21 security vuln -> what a mess [20:33] gnomefreak: well, no one ever asked me to sponsor anything moz-ext related since now [20:33] why do i need to spend time and clean stuff up that others claim without knowing anything [20:34] gnomefreak: so I don't think it's a sponsoring / missing priv problem [20:34] and the non-maintainer upload was because i asked him to upload his minimal change ... another painful thing that QA says its a NMU just because someone else uploads it for you [20:35] asac: you can easily ignore the NMU error if you are sure you aren't hijacking the package :) [20:36] how ignore. the bug wasnt closed [20:36] just because of this [20:36] what a mess ;) [20:36] but you are right, i probably should just leave the whole project :) [20:36] and orphan all mozilla packages ;) [20:37] asac: well, I just would like to see some more Ubuntu ppl contributing back to Debian [20:37] but we saw how great that worked with iceape ... its gone [20:37] * micahg wonders if it's worth becoming a DD [20:37] and`: some do! [20:38] cyphermox: luckily you are right, some do :) [20:38] and`: i did the work everyone claimed to be impossible before i did it for years [20:38] i backported mozilla packages [20:38] before i was in debian, there was no security for firefox [20:38] now that i am not doing it anymore, it will work until upstream EOLs the branch [20:38] then good bye [20:38] asac: just think about the python mess in Debian, that's what I define *crazy* [20:38] when i did the whole patches, ensuring everything was there, i was still ranted at [20:39] bug 113201 [20:39] Launchpad bug 113201 in firefox "firefox spends lots of time hung" [Unknown,Confirmed] https://launchpad.net/bugs/113201 [20:40] asac, as LATEST.txt is still broken, i've extended g-o-s to accept stuff like CHANNEL=4.0.288.1 (in addition to CHANNEL={beta,Beta,dev,Dev}) [20:41] asac: I know that you alwais wanted to give back to Debian and I appreciate that, I just hope I gonna see your name again somewhen, I would feel happy, really [20:42] gnomefreak: do you need feedback? [20:45] micahg: for what? [20:45] for that bug? [20:46] micahg: no there was no title in my email for the bug [20:46] gnomefreak: k [20:46] wait yes i do [20:46] heh [20:46] i commented on the bug if anyone sees this in 3.5 3.6 [20:47] * gnomefreak thought i just did :( [20:47] * micahg usually lets upstream sort it out if it's open [20:47] they seem to be trying to figure out if it's fixed or not on 1.9.1 [20:48] but I wouldn't bother updating FF3.0 bugs to FF3.5 at this point since we might end up moving them again in 3 months [20:48] at least the triaged ones [20:48] k [20:48] the untriaged, go for it [20:49] gnomefreak: asac still has to decide which source package to use for ff3.6 [20:49] blocked on understanding what channels mohzilla will maintain [20:49] [reed]: any decision yet? [20:50] e.g. will you have stable/beta/dev like chrome? [20:50] i catched that in some discussion [20:50] <[reed]> hmm [20:50] but mconnor said it might be more complex/different when i last asked [20:51] micahg: im still going through >6000 emails. so far will exception to the 1 1/2 hour meeting i have been doing it all day [20:51] having such channels would definitly help us to pick the package names in a long term stable fashion [20:51] like firefox firefox-beta firefox-trunk [20:52] or firefox firefox-next firefox-dev firefox-daily [20:52] gnomefreak: I still have 4k unread and I go through it daily :) [20:53] just catching up from from dec 14th [20:53] s/just/still [20:56] asac: i think so, had a late lunch and now looking at it again [20:56] asac: it changed the failure in any case :) [20:57] which might mean progress ;) [21:09] be back i lost my glasses :( [21:10] dog food bag of all places [21:12] should we add a trunk build of enigmail for non-released tb versions? or please add trunk builds of it atleast in our daily PPA? [21:19] ok gone for the day. === micahg1 is now known as micahg