| asac | Mook_sb: yeah. thats kind of tough ... but interesting | 00:02 |
|---|---|---|
| asac | and yeah. seems like they want to shake off all reuses of their platform | 00:03 |
| asac | i am not sure they want. but this way will probably mean there is no chance for embedders or even other xulapps to keep up to speed | 00:04 |
| asac | but its also consequent ... and i personally accepted that this will happen | 00:05 |
| micahg | they're having trouble with their own apps keeping up SM/TB | 00:05 |
| micahg | I guess that's why everyone's migrating away from GRE | 00:06 |
| asac | i guess TB will survive a bit longer | 00:07 |
| asac | than SM | 00:07 |
| micahg | well, the SM team is hyped up about the new release | 00:08 |
| micahg | they plan on launching soon | 00:08 |
| asac | hyped up? | 00:08 |
| asac | ah | 00:08 |
| asac | ok | 00:08 |
| micahg | very excited | 00:08 |
| asac | sure. the problem is that last release was from same branch as ffox 2.0 | 00:09 |
| asac | so it took till now to get the new release done | 00:09 |
| asac | granted, there was quite some work done too (not just porting) | 00:09 |
| asac | but now they hear that they need to get things ready for 1.9.2 ... :) | 00:09 |
| micahg | yeah, well, we're kinda in the same boat as they are in terms of migration (granted our migration is a little easier) | 00:10 |
| asac | easier? | 00:12 |
| asac | cool | 00:12 |
| asac | i have need help porting hardy to 3.6 | 00:12 |
| asac | ;) | 00:12 |
| micahg | are we going to try to do that? | 00:13 |
| asac | and yes. we sit in the same boat ... but more on the outside ;) | 00:13 |
| mconnor | Tb3 is pretty awesome, fwiw | 00:13 |
| asac | yes it is | 00:13 |
| asac | only thing is mem consumption | 00:13 |
| asac | but the new search rocks ;) | 00:13 |
| asac | the UI is a bit inconsistent ... i would think in the long run the main mailvinwdow will move more in a similar direction | 00:14 |
| asac | micahg: we kind of have to | 00:14 |
| asac | reinvent ourselve. tracking full upstream releases | 00:14 |
| micahg | because it's LTS? | 00:15 |
| asac | somehow ... dont ask me how now | 00:15 |
| asac | micahg: yes. 1.5 years to go when 3.0 goes eol | 00:15 |
| asac | but same for jaunty | 00:16 |
| asac | but i think hardy is a bit tougher | 00:16 |
| micahg | yes, but jaunty has 3.5 already | 00:16 |
| asac | micahg: jaunty doesnt have 3.5 | 00:16 |
| micahg | yes it does | 00:16 |
| asac | it has a preview ... | 00:16 |
| micahg | in universe | 00:16 |
| asac | yes. its not a so big issue to move the app | 00:16 |
| micahg | it's the same app with the branding turned off | 00:16 |
| asac | but we also have other embedders that use the same rendering engine | 00:17 |
| asac | we probably have to port all apps that have remote content exposure | 00:17 |
| micahg | ugh | 00:17 |
| asac | thats probably the minimum set we can argue. and all apps that are in main of course | 00:17 |
| micahg | that means backporting what we jsut did for karmic to jaunty | 00:17 |
| micahg | and hardy | 00:17 |
| asac | micahg: only that in hardy there are more apps ;) ... asa webkit is almost non-existing ;) | 00:17 |
| asac | and in jaunty too | 00:18 |
| asac | i think hardy has the most | 00:18 |
| asac | with intrepid having no real difference | 00:18 |
| asac | and jaunty slightly less because webkit started to grow | 00:18 |
| asac | but epiphany in main is a mess | 00:18 |
| asac | the 1.9.1 port will be not so nice ;) | 00:18 |
| asac | and epiphany-webkit is not feature complete enough to just drop that in as a forced replacement | 00:19 |
| micahg | what is debian doing with this stuff? | 00:19 |
| asac | they probably will surrender. usually i gave them all the backports i made | 00:19 |
| asac | and even did the uploads | 00:19 |
| asac | now they ride the upstream minor updates | 00:19 |
| asac | but major updates will be a tough thing for them | 00:20 |
| asac | if not impossible | 00:20 |
| micahg | asac: http://browsing.justdiscourse.com/2009/10/08/debug-version-of-prism-1-0b2-for-ubuntu/ | 00:20 |
| asac | so debian will be back where they were when i startred to do security support for mozilla like a bunch of years ago ... no security support | 00:20 |
| micahg | ugh | 00:20 |
| asac | maybe we can help them with our patches | 00:20 |
| micahg | what will they do with epiphany htough | 00:21 |
| asac | but its even tougher for them | 00:21 |
| asac | they also need to get all archs properly working | 00:21 |
| asac | micahg: epiphany is gecko ... so they dont have suport. in future its webkit so thats ok | 00:21 |
| micahg | no, I meant epiphany in debian | 00:21 |
| asac | i think they will not release mozilla at all | 00:21 |
| asac | or go the same road as we do | 00:22 |
| asac | no r-depends | 00:22 |
| asac | and major updates | 00:22 |
| asac | micahg: yes. in debian its also gecko ... and if they cannot support xulrunner its automatically not supported | 00:22 |
| asac | but debian does only support "1 year" after relase of stable | 00:22 |
| asac | so they will be off the hook sooner than we will ;) | 00:23 |
| asac | one thing is clear. in lucid we need to have everything in place so we can ride the usptream releases for 3 years ;) | 00:23 |
| micahg | well, easiest is to go back to just "firefox" and push every update | 00:24 |
| asac | yes. but we need to get all the xulrunner consumers with remote access out of the archive too | 00:24 |
| micahg | but then you can't package extensions | 00:24 |
| asac | just firefox isnt good enough | 00:24 |
| asac | i am not cared about firefox | 00:24 |
| asac | that will sort out on its own | 00:24 |
| asac | just the rest | 00:24 |
| micahg | ah | 00:24 |
| asac | but i guess we just need to be harder about killing apps that use gecko | 00:24 |
| micahg | I was wondering, why are you trying to get more extensions in the archive anyway? | 00:25 |
| asac | e.g. removing from archive | 00:25 |
| micahg | if we can't reliably update them during the release cycle | 00:25 |
| asac | we could ;) | 00:25 |
| asac | a matter of resources | 00:25 |
| asac | but basically the idea is: if they work at release time | 00:25 |
| asac | they shouldnt stop working while release is maintained | 00:26 |
| asac | so they deliver a "stable" experience | 00:26 |
| asac | stable in the sense that you know the bugs and you dont get new bugs tomorrow | 00:26 |
| micahg | yes, but stuff like noscript where they find new vulnerabilities all the time | 00:27 |
| micahg | don't get updated | 00:27 |
| asac | thats a mistake | 00:27 |
| asac | and needs fixing | 00:27 |
| micahg | version in archive 1.9.2.8-1ubuntu1 latest: 1.9.9.11 | 00:27 |
| micahg | can you automate extension building from amo? | 00:28 |
| micahg | s/you/we/g | 00:28 |
| micahg | like we do the dailies | 00:28 |
| micahg | but maybe weekly instead of daily | 00:28 |
| asac | in general i agree that we should balance work spend on maintenance vs. new extensions | 00:28 |
| asac | and stop doing new if the maintenance is too much | 00:28 |
| asac | micahg: we started on having auto syncs ... yes. | 00:29 |
| asac | micahg: we have a set of scripts that basically already does that | 00:29 |
| asac | it just needs to be plumbered together | 00:29 |
| dtchen | fta: yeah, the SDL bit is known. I'm going to look at it this evening (in an hourish). | 00:29 |
| asac | that was one of the plans that ended up short before the end ;) | 00:29 |
| asac | micahg: https://code.edge.launchpad.net/~mozillateam/firefox-extensions/med-auto-scripts | 00:30 |
| asac | micahg: what that does is it syncs the registered extension ids and detects if there are newer xpis than what is currently in branch | 00:30 |
| asac | or something | 00:30 |
| asac | i think whats missing is the branch updating | 00:30 |
| asac | but maybe thats even there too | 00:30 |
| * micahg wants to know how to recruit more triagers for bugs... | 00:31 | |
| asac | thats a communication thing. | 00:31 |
| asac | more blocking | 00:31 |
| asac | reporting status | 00:31 |
| micahg | oh, also, should update my 3.6b1 test build to not use system sqlite? | 00:32 |
| asac | micahg: if it still works it measn that your version is high enough | 00:32 |
| asac | you should just have the right minversion in debian/rules | 00:32 |
| asac | at least atm | 00:32 |
| micahg | no, because of the compile flags that reed pointed out | 00:33 |
| asac | if we go back to all in-source, w can probably do that | 00:33 |
| asac | ah. maybe. i will upload the update tomorrow | 00:33 |
| asac | to security ppa and then to -proposed for some baking for hardy-jaunty | 00:33 |
| micahg | ok | 00:34 |
| asac | micahg: i fixed tb3 head ... i think ... did you see what was wrong with 1.9.3 patches? | 00:58 |
| micahg | asac: I thought it was cairo that was the issue with 1.9.3 | 00:59 |
| asac | yeah | 01:00 |
| asac | ok | 01:00 |
| asac | then all is fixed | 01:00 |
| asac | the patches applied and its building here | 01:00 |
| asac | good | 01:00 |
| micahg | asac: https://edge.launchpad.net/builders/bohrium | 01:11 |
| asac | hanging? | 01:28 |
| micahg | yeah | 01:31 |
| micahg | I'm trying to figure out who to contact | 01:31 |
| micahg | it's that build machine | 01:31 |
| micahg | that's why we didn't have a build yesterday though | 01:32 |
| asac | hmm | 01:38 |
| asac | micahg: in #launchpad | 01:38 |
| asac | ask there | 01:38 |
| asac | maybe there is someone on duty | 01:38 |
| asac | otherwise i can ask around tomorrow | 01:38 |
| asac | now dropping out | 01:38 |
| micahg | already did | 01:38 |
| micahg | night | 01:39 |
| asac | oh. no answer? | 01:39 |
| micahg | not yet | 01:39 |
| asac | ok if noone ansewrs just drop a line ... enjoy! | 01:42 |
| micahg | ok | 01:42 |
| jcastro | micahg: when you post that a bug is reported upstream in mozilla please do an "also affects project" and paste the bug in the url field | 03:35 |
| micahg | jcastro: what are you referring to? | 03:36 |
| micahg | If I have the bug I add it | 03:36 |
| jcastro | https://bugs.edge.launchpad.net/firefox/+bug/448686 | 03:36 |
| ubottu | Launchpad bug 448686 in firefox-3.5 "CSS table borders do not display" [Medium,Triaged] | 03:36 |
| micahg | weird | 03:36 |
| micahg | I usally do | 03:37 |
| jcastro | I just linked it, I have a report that goes through bugs with comments with links in comments that aren't link, to catch them. :D | 03:37 |
| jcastro | it's ok it's my job to catch the ones that get away | 03:37 |
| micahg | was 1AM | 03:37 |
| jcastro | but I find that some people never know about the feature so I always follow up. | 03:37 |
| * micahg knows | 03:37 | |
| micahg | I also add them for people if I catch it | 03:37 |
| jcastro | I am currently working with the lp guys to make it not so annoying to do though | 03:37 |
| jcastro | <3 awesome | 03:37 |
| micahg | well, you don't want to entirely automate it | 03:38 |
| jcastro | oh no | 03:38 |
| jcastro | it won't be automated for sure | 03:38 |
| jcastro | but something inlineable so you don't have to do a page load I think would be much easier | 03:38 |
| micahg | yeah | 03:39 |
| micahg | perhaps a flag next to a bugwatch if the upstream project is labeled | 03:42 |
| micahg | s/labeled/set | 03:42 |
| jcastro | yeah | 03:43 |
| jcastro | and I think "also affects project" is confusing | 03:43 |
| jcastro | there should be a specific "link to an upstream bug project" or something | 03:43 |
| micahg | jcastro: well, there's 2 functions for it | 03:44 |
| micahg | 1 is to mark upstream | 03:44 |
| jcastro | yeah, I think that's the problem | 03:44 |
| micahg | 2 is to mark another project affected | 03:44 |
| jcastro | but we'll see what UI people say | 03:44 |
| micahg | LP UI team is reluctant to add more buttons | 03:44 |
| * jcastro nods | 03:44 | |
| jcastro | I'm going to have a session about this at UDS, so if you have any feedback or concerns feel free to just mail me | 03:45 |
| jcastro | I am going to video some people upstreaming bugs to get more data, etc. | 03:45 |
| * micahg wishes he could attend UDS | 03:46 | |
| mconnor | intriguing | 04:14 |
| markey | hey all | 05:54 |
| markey | lately there have been no Chromium nightly updates | 05:55 |
| markey | anyone happen to know why? | 05:55 |
| === micahg1 is now known as micahg | ||
| micahg | really? | 05:57 |
| micahg | I thought I got an update | 05:57 |
| micahg | maybe not :) | 05:58 |
| micahg | markey: daily is broke :) | 05:58 |
| micahg | wanna fix it? | 05:58 |
| markey | not really, I'm not much of a packager :) | 05:59 |
| markey | what's borked with it? | 05:59 |
| micahg | idk | 05:59 |
| nilleb | hello everybody | 08:09 |
| nilleb | i'm here again about the problem I discuted yesterday w/ asac | 08:09 |
| nilleb | well, | 08:09 |
| nilleb | I think I got it | 08:09 |
| nilleb | the apparmor profile for FF is wrong in karmic. | 08:10 |
| nilleb | this statement is true for users on an active directory domain, that has been joined, for example, with likewise-open | 08:10 |
| nilleb | for these users, the home directory looks like /home/DOMAIN/user | 08:11 |
| nilleb | and this, IMHO, prevents FF from setting a lock on the .parentlock file. | 08:11 |
| nilleb | well, now the evidences of this misbehavior: | 08:12 |
| nilleb | Oct 22 11:13:52 ly-qa-bellinux kernel: [ 8549.052195] type=1503 audit(1256202832.201:81): operation="file_lock" pid=6085 parent=5539 profile="/usr/lib/firefox-3.5.*/firefox" requested_mask="wk::" denied_mask="k::" fsuid=1893211406 ouid=1893211406 name="/home/ESKERCORP/bellin-salarin/.cache/event-sound-cache.tdb.f1b0a25408a48159af64e77c486e058d.i486-pc-linux-gnu" | 08:12 |
| nilleb | I think I'm going to open a log, I will file it against mozilla-firefox | 08:12 |
| nilleb | and apparmor | 08:12 |
| nilleb | (log=bug report) | 08:12 |
| asac | hmm | 09:48 |
| asac | jdstrand: ^^^ | 09:48 |
| asac | http://paste.ubuntu.com/299642/ | 09:49 |
| asac | jdstrand: ^^ | 09:49 |
| asac | apparmore ;) | 09:49 |
| jdstrand | asac: already responded to his bug | 09:49 |
| jdstrand | bug #458846 | 09:49 |
| ubottu | Launchpad bug 458846 in apparmor "apparmor prevents firefox from starting for an user who belongs to an Active Directory domain (dup-of: 447292)" [Undecided,Won't fix] https://launchpad.net/bugs/458846 | 09:49 |
| ubottu | Launchpad bug 447292 in apparmor "AppArmor does not allow access when @{HOME} is not /home" [Low,Won't fix] https://launchpad.net/bugs/447292 | 09:49 |
| asac | ah ;) | 09:50 |
| jdstrand | he simply needs to read https://wiki.ubuntu.com/DebuggingApparmor#Adjusting%20Tunables | 09:50 |
| asac | jdstrand: isnt it way too early? | 09:50 |
| asac | ;) | 09:50 |
| asac | i mean ... i just got up :-P | 09:50 |
| jdstrand | asac: yeah-- dog woke me up and then I couldn't get back to sleep | 09:50 |
| asac | (a tad late i agree) | 09:50 |
| asac | heh | 09:50 |
| asac | ok ... feels like i should get a dog soonish ;) | 09:50 |
| jdstrand | heh | 09:51 |
| jdstrand | just don't get a male | 09:51 |
| jdstrand | :) | 09:51 |
| asac | yeah. my girl wants a girl ;) | 09:51 |
| jdstrand | I'm sure some males are fine. ours is stubborn and a digger (wakes us up scratching his bed) | 09:51 |
| micahg | asac: I don't understand the difference between LIBXUL_SDK and SKIP_COPY_XULRUNNER | 09:56 |
| asac | micahg: SKIP_COPY_XULRUNNER? | 09:57 |
| asac | isnt that a patch by us? | 09:57 |
| asac | micahg: so bascially if you build a libxul-sdk based aplication and want to ship it | 09:58 |
| asac | you need to ship it side by side with xulrunner ... | 09:58 |
| asac | unless you are a distributor that knows that there is xulrunner on system | 09:58 |
| asac | thats when you SKIP_COPY_XULRUNNER | 09:58 |
| asac | i guess LIBXUL_SDK Is clear? | 09:59 |
| micahg | i would think | 09:59 |
| asac | so if you build mozilla apps with --with-libxul-sdk | 09:59 |
| asac | it means it will just use the system xulrunner | 09:59 |
| asac | and not build the full xulrunner on its own | 09:59 |
| asac | thats why SKIP_COPY_XULRUNNER comes into play | 10:00 |
| micahg | why do you need SKIP_COPY_XULRUNNER if you're building with LIBXUL? | 10:00 |
| asac | e.g. if you dont build xulrunner you need to copy it if you want to ship a bundle with everything | 10:00 |
| micahg | why 2 variables? | 10:01 |
| asac | 10:58 < asac> micahg: so bascially if you build a libxul-sdk based aplication and want to ship it | 10:01 |
| micahg | that's what I don't get | 10:01 |
| asac | 10:58 < asac> you need to ship it side by side with xulrunner ... | 10:01 |
| asac | 10:58 < asac> unless you are a distributor that knows that there is xulrunner on system | 10:01 |
| asac | 10:58 < asac> thats when you SKIP_COPY_XULRUNNER | 10:01 |
| asac | thats what i tried to explain i nthose lines | 10:01 |
| micahg | i saw | 10:01 |
| asac | hmm | 10:01 |
| micahg | but I don't understand | 10:01 |
| micahg | I thought building with libxul-sdk implies system xul | 10:01 |
| asac | micahg: xulrunner is not only made for distros | 10:01 |
| asac | so thin kabout windows | 10:02 |
| micahg | oh | 10:02 |
| asac | if you build a xulapp .... with libxul-sdk | 10:02 |
| micahg | I think I get it | 10:02 |
| asac | you want to ship something that works | 10:02 |
| micahg | one is for building and one is for running | 10:02 |
| asac | so you need the full xulrunner copy | 10:02 |
| asac | thats what it does by default | 10:02 |
| asac | and thats why one needs to explicitly SKIP that on linux distro packages | 10:02 |
| asac | micahg: yes. if you do --wit-libxul-sdk it will build against that ... and in the end copy the full xulrunner | 10:03 |
| asac | so you have it in the same tree and can ship a complete solution that works independently of the system | 10:03 |
| asac | yes. what you said is about right | 10:03 |
| micahg | so I messed up the patches...I'm trying again now | 10:07 |
| micahg | ok, so there's a ifdef SYSTEM_LIBXUL in there now | 10:17 |
| asac | yeah | 10:18 |
| micahg | where we had LIBXUL_SDK | 10:18 |
| micahg | should I update our patches with the upstream CONSTANT? | 10:18 |
| asac | micahg: if that constant is now used ... why not | 10:20 |
| asac | micahg: so SKIP_COPY_XULRUNNER imo was also defined elsewhere | 10:21 |
| asac | iirc | 10:21 |
| asac | but its there for ages, so i am not sure | 10:21 |
| asac | to give you a 100% sure answer i would have to read the code. but if you think the upstream constant is a better way, then propose it and i will check | 10:21 |
| micahg | ugh | 10:22 |
| micahg | something's not right | 10:22 |
| micahg | LIBXUL_SDK is still used | 10:23 |
| micahg | I think this is too much for me at this hour | 10:25 |
| micahg | I'll try again when I get up | 10:26 |
| asac | hehe | 10:31 |
| asac | micahg: yes. try to take a step back ... and then lets seee | 10:31 |
| asac | micahg: what are you doing actually? | 10:31 |
| micahg | fixing the patches as they no longer cleanly apply | 10:32 |
| asac | oh ok ... ffox ... right | 10:33 |
| asac | LIBXUL_SDK will be used for sure | 10:33 |
| micahg | no | 10:33 |
| micahg | prism | 10:33 |
| asac | i dont think this will ever get removed | 10:33 |
| asac | thought the SKIP_COPY_XULRUNNER was removed by something else | 10:33 |
| asac | micahg: oh yeah. | 10:34 |
| asac | micahg: lets check that when you wake up | 10:34 |
| asac | i am then in weekend mode and can probably give better input ;) | 10:34 |
| micahg | ok | 10:34 |
| asac | bdmurray: hey ;) | 14:52 |
| asac | bdmurray: can you give cyphermox the intro wiki page for bugcontrol and add him to that team once he confirms he understands? he is NM team member and needs to be able to work on bugs ;) | 14:53 |
| fta | asac, how do i add a tab in a bzr branch? | 16:23 |
| fta | tag | 16:23 |
| asac | fta: for package releases? | 16:25 |
| asac | fta: basically same approach as we do ... release commit ... just use decommit -r -e | 16:25 |
| asac | that will do the right thing and allows you to be more concrete | 16:25 |
| asac | i think we should adjust debcommit code to be more of the format that we use in mozillateam | 16:25 |
| asac | it just says: "relesaing x.1.2-0ubuntu2" | 16:25 |
| asac | while it should say "releaseing x.y.a.s. to karmic" ... at least | 16:26 |
| asac | fta: otherwise its just bzr tag 1.2; bzr push | 16:26 |
| asac | if you do an upstream release | 16:26 |
| fta | could it be done afterwards? i mean, adding tags to older revisions? | 16:26 |
| asac | fta: sure | 16:28 |
| asac | i think you can do bzr tag -r xxx TAGNAME | 16:28 |
| asac | yeah | 16:28 |
| asac | you can do that accoreding to bzr help tag | 16:29 |
| asac | you can see all tags with bzr tags | 16:29 |
| asac | or delete tag with bzr tag --delete TAGNAME | 16:29 |
| fta | would be nice to be able to commit with a user specified date too. so i can re-create a branch for a 15y+ project i'm still working on | 16:30 |
| asac | fta: is that in svn or cvs? | 16:31 |
| asac | they are easy to import | 16:31 |
| asac | and dates etc. shouuld be fine then | 16:31 |
| asac | i think | 16:31 |
| asac | otherwise set date before commit ;) | 16:32 |
| fta | no, nothing, no vcs at all, i just have my old tarballs and changelogs | 16:32 |
| asac | <hackalert/> | 16:32 |
| asac | hmm | 16:32 |
| asac | yeah. sounds like a plugin | 16:32 |
| asac | e.g. tarball-series import | 16:32 |
| asac | not existing. just saying that that should probably be done as s plugin | 16:33 |
| asac | fta: bzrtools ... bzr help import | 16:37 |
| asac | Purpose: Import sources from a directory, tarball or zip file | 16:38 |
| asac | Usage: bzr import SOURCE [TREE] | 16:38 |
| asac | This command will import a directory, tarball or zip file into a bzr | 16:38 |
| asac | tree, replacing any versioned files already present. If a directory is | 16:38 |
| asac | ... | 16:38 |
| asac | might be worth a try | 16:38 |
| asac | though not with date tweakage | 16:38 |
| asac | not sure how smart it is | 16:38 |
| asac | but maybe give the tarball an old timestamp and see if it uess that ;) | 16:38 |
| asac | import does not commit on its own though | 16:40 |
| asac | fta: i think should be easy to do | 16:49 |
| asac | let me see | 16:50 |
| * asac pulls bzr bzr | 16:50 | |
| asac | grr ... branch format outdated | 16:50 |
| fta | bug 443028 | 17:43 |
| ubottu | Launchpad bug 443028 in evolution "evolution hangs when trying to open/save attachments in an email with 2 ppt attachments" [Medium,Incomplete] https://launchpad.net/bugs/443028 | 17:43 |
| fta | cool, i'm not alone | 17:43 |
| === dpm is now known as dpm-afk | ||
| asac | fta: great. thats a start | 18:02 |
| asac | fta: i will write the timestamp patch for bzr ;) | 18:02 |
| asac | but it took 1h or so to convert my bzr branch to a format so i can pull the latest ;) | 18:02 |
| fta | not sure it's the same freeze, i don't have logs for mine | 18:02 |
| asac | so if you wait till tomorrow you can use bzr import + bzr commit | 18:02 |
| fta | they happen only on my x64 box | 18:03 |
| asac | fta: can you get a threaddump if it freezes? | 18:03 |
| fta | i should try, but i'm at home (32bit) | 18:03 |
| fta | seems virtualbox can't do d3d10, too bad | 18:07 |
| fta | no aero with W7 | 18:07 |
| asac | hmm | 18:14 |
| asac | yeah | 18:14 |
| fta | funny, d3d is in fact using the wine driver | 18:19 |
| fta | Rejected: File gwibber_2.0.0~bzr476.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. | 18:24 |
| fta | i wonder if the bot should be smarter and 1st look at the archives before calling get-orig-sources | 18:24 |
| fta | or if it's a marginal case for dailies | 18:25 |
| fta | (not worth the efforts) | 18:25 |
| asac | fta: http://pastebin.com/f72bb14ce | 18:35 |
| asac | fta: i am not sure. i had the feeling that we get a bit often rejections because of bad version in some way | 18:35 |
| fta | yes, but here it's different | 18:36 |
| asac | isnt it the "if on top there is released, it should bump version rather than lowering"? | 18:36 |
| asac | fta: the patch above works great for me ... e.g. | 18:36 |
| asac | /home/asac/local_bzr/bin/bzr commit --commit-time='2009-10-16 08:59:00 +0100' | 18:36 |
| fta | a --commit-from-reference=some_file would be nice too | 18:37 |
| fta | er, --commit-time-from-reference | 18:37 |
| fta | similar to 'touch -r' | 18:37 |
| asac | ah | 18:38 |
| asac | yeah well ;) | 18:38 |
| asac | you can wrote a wrapper for now | 18:38 |
| asac | like ls -l /path/to/tarball -> make date | 18:38 |
| asac | use that to commit after bzr import /path/to/tarball | 18:38 |
| asac | fta: i think that should rather in a "import-and-commit" ;) | 18:38 |
| asac | i will think about it ... now that i am the bzr master ;) | 18:39 |
| fta | lol | 18:39 |
| asac | fta: can you open a wishlist but for the --commit-date thing against bzr upstream so i can request a merge? | 18:39 |
| fta | not sure i can change upstream bug status | 18:46 |
| fta | or is wishlist a tag? | 18:47 |
| fta | nope, it's "importance", i can't change that | 18:48 |
| fta | asac, ^^ bug 459276 | 18:50 |
| ubottu | Launchpad bug 459276 in bzr "user specified commit date" [Undecided,New] https://launchpad.net/bugs/459276 | 18:50 |
| asac | heh yeah | 18:54 |
| fta | tb3/chromium/o3d red | 19:11 |
| fta | songbird too | 19:11 |
| fta | gwibber out | 19:11 |
| fta | not a good day for dailies :P | 19:12 |
| gnomefreak | anyone else notice that the folders with mail in them in tbird3 are not bold anymore? | 19:28 |
| gnomefreak | started a week or 2 ago i think | 19:28 |
| gnomefreak | bug 339149 | 19:30 |
| ubottu | Launchpad bug 339149 in thunderbird "Thunderbird add on lightning 0.9. Cannot add task " [Undecided,Invalid] https://launchpad.net/bugs/339149 | 19:30 |
| asac | hmm | 19:31 |
| asac | havent opened tbird for a fe wdays | 19:31 |
| asac | not sure if its more than a week | 19:31 |
| gnomefreak | i dont recall date or timeframe but it has been a little while | 19:32 |
| asac | not sure. maybe you didnt subscribe those folders for auto updates or someting? | 19:32 |
| gnomefreak | what do you mean? they get new mails in them | 19:33 |
| gnomefreak | if i leave mail in the folders without reading them they turn bold/black when i reopen tbird3 but i have to have looked in folder before closing | 19:34 |
| asac | my folders are bold | 19:36 |
| thunderstruck | damnit | 19:36 |
| asac | you can subscribe explicitly to certain folders by right clicking etc. | 19:36 |
| thunderstruck | asac: default theme? | 19:36 |
| asac | yes | 19:36 |
| === thunderstruck is now known as gnomefreak | ||
| gnomefreak | what do i choose to subscribe after right clicking on folder? | 19:37 |
| asac | fta: tb still red | 19:37 |
| asac | ? | 19:37 |
| asac | did i forget to push my fix ;)? | 19:37 |
| asac | hmm | 19:38 |
| fta | asac, probably | 19:47 |
| fta | good, next chromium should be green, upstream fixed the bug for me ;) good upstream.. compared to others | 19:47 |
| fta | (no name) | 19:48 |
| gnomefreak | seems that FF3.5 3.6 and 3.7 can use search again | 19:48 |
| mconnor | fta: harsh :P | 19:48 |
| gnomefreak | i hope green == build succeded | 19:49 |
| fta | mconnor, let's face the truth, some upstream are more cooperative than others and are more willing to keep downstream build green | 19:50 |
| fta | buildS | 19:50 |
| mconnor | fta: if your builds reported to our systems, I bet it'd be easier | 19:51 |
| fta | gnomefreak, lol, yeah | 19:51 |
| gnomefreak | ;) | 19:51 |
| fta | mconnor, I don't want to fight on this but experience proved that each time we had a build failure, we had to write the patch ourselves, submit it, and wait weeks if not months (not to say forever) to get it in, and we had to refresh it many times in the meantime. | 19:55 |
| mconnor | fta: bug #s? | 19:56 |
| fta | (but i wasn't targeting moz in my initial peak) | 19:56 |
| mconnor | I don't want to fight on it, I want to figure out how real any of this is | 19:56 |
| fta | mconnor, no bug in particular but i've built moz stuff hundreds of times since 2007 | 19:57 |
| mconnor | it's hard to change stuff when I can't see how we're failing :-/ | 19:58 |
| fta | i also agree we're not very good at upstreaming our downstream patches | 19:58 |
| === asac_ is now known as asac | ||
| mconnor | process issues are just like bugs, saying they're there without STR means I can't fix it! | 19:59 |
| micahg | asac: I'm going to try prism again in about 20 minutes | 20:03 |
| Mook_sb | I guess songbird at least knows where we're failing? :( (--enable-system-sqlite, in the most recent case) | 20:21 |
| [reed] | fta: you're horrible at upstreaming your patches | 20:33 |
| [reed] | end of story ;) | 20:34 |
| [reed] | iirc, my stats show: Debian is first. Red Hat is next. openSUSE is third. | 20:34 |
| fta | [reed], you're so horrible at accepting patches or even critics that i no longer bother even filing bugs | 20:36 |
| fta | end of story | 20:36 |
| micahg | ugh | 20:37 |
| micahg | can't we all just get along ;) | 20:37 |
| micahg | asac: can I drop the use 1.9 only patch in prism? | 20:42 |
| [reed] | mconnor: 513067, 471359, 466250, 478871, 463872, 423334, 417345 all have various issues where upstream (Mozilla) didn't take the time to help, took too long, didn't care, or some other issue (this is from a quick read, so I may have missed something). | 20:45 |
| mconnor | fta: feel free to cc me on anything where there's inaction, I can still hit people with a hammer ;) | 20:48 |
| micahg | asac: are you therE? | 21:05 |
| micahg | fta, can you help me with an error? | 21:10 |
| micahg | fta: asac did commit the patch for TB3 yesterday | 21:19 |
| micahg | according to the logs | 21:19 |
| fta | micahg, checking | 21:22 |
| fta | today's error is "checking for libnotify >= 0.4... Package libnotify was not found", fix is easy | 21:23 |
| micahg | ok, I'm still wresling with prism | 21:23 |
| micahg | fta: can you help me with this: http://pastebin.com/f127c38a2 | 21:27 |
| fta | fixed tb3 | 21:29 |
| micahg | oh, you already fixed tb3 | 21:29 |
| micahg | I was oging to trade you :) | 21:29 |
| fta | micahg, what did you change compared to my branch? (prism) | 21:29 |
| micahg | added libasound build dep, change to xul-1.9.1, drop 1.9 only patch | 21:30 |
| micahg | daily build is failed as well, but I think that was a patch | 21:30 |
| fta | prism daily failed? | 21:32 |
| asac | micahg: yeah. we need kind of a system-libnotify patch | 21:32 |
| asac | err... magic for debian/rules i mean | 21:32 |
| fta | for prism? | 21:33 |
| asac | for tb3 | 21:33 |
| micahg | I thought prism daily's been failed | 21:33 |
| fta | er? we just need a build-dep | 21:33 |
| micahg | asac: fta fixed tb3 | 21:33 |
| fta | for prism, i don't know, i need to see your changes | 21:33 |
| asac | cool | 21:34 |
| micahg | ok, I'll push a branch up | 21:34 |
| fta | pastebin a bzr diff | 21:34 |
| micahg | http://pastebin.com/f1f0a4d35 | 21:40 |
| micahg | brb | 21:40 |
| fta | micahg1, hm, at 1st glance, it should work | 21:46 |
| micahg | fta: any ideas, I've got about another hour before I have to quit | 21:48 |
| BUGabundo | boas noites o/ | 22:10 |
| fta | micahg, for some reason, the build system is broken, configure correctly creates prism/installer/Makefile from the .in, but not prism/Makefile | 22:21 |
| fta | BUGabundo, ola | 22:21 |
| micahg | ok, so what do I do | 22:22 |
| BUGabundo | olá fta | 22:22 |
| BUGabundo | did you manage to use shared folders on VB? | 22:23 |
| fta | micahg, a trick could be to patch prism/makefiles.sh but there's probably a better way | 22:23 |
| micahg | I don't know too much about the make files | 22:23 |
| micahg | I guess I can try to patch it up sat night | 22:23 |
| fta | something changed in the build system. | 22:24 |
| fta | asac, ^^, any idea? | 22:24 |
| BUGabundo | dtchen: FYI my sound seems really nice now! even keeps volume settings post reboot :) | 22:26 |
| fta | BUGabundo, for me, it regressed in the last few days. it used to be fine post reboot, now it's ever mute or very low | 22:27 |
| BUGabundo | :( | 22:27 |
| fta | BUGabundo, do you have h/w acceleration in vbox? (dx9 or better) | 22:34 |
| BUGabundo | no idea | 22:34 |
| BUGabundo | haven't tested it | 22:34 |
| fta | you have no windows guest? | 22:35 |
| BUGabundo | yes | 22:35 |
| BUGabundo | at work | 22:35 |
| asac | have to check prism | 22:55 |
| asac | tb3 failed again? | 22:56 |
| fta | yep, but fixed, again | 22:56 |
| asac | k | 22:56 |
| fta | for prism, allmakefiles.sh changed a lot | 22:57 |
| fta | it's from xul | 22:57 |
| fta | seems best to just patch prism/makefiles.sh | 22:57 |
| fta | but keep use_xul_1.9_only.patch (just updated to 1.9.1) | 22:58 |
| asac | k | 22:59 |
| asac | lets first see whats up ;) | 22:59 |
| asac | all makefiles.sh in prism/ is done by us? | 23:02 |
| asac | seems to be just buggy | 23:02 |
| asac | ok | 23:02 |
| asac | got it | 23:02 |
| asac | hmm micahg is not there | 23:02 |
| asac | ;) | 23:02 |
| asac | dont really want to take all work away from him ;) | 23:02 |
| asac | fta: isnt the prism/makefile.sh from the prism svn? | 23:02 |
| fta | it is | 23:05 |
| asac | ah but the makefile isnt? | 23:05 |
| asac | hmm | 23:05 |
| asac | should be in there | 23:05 |
| asac | then makefile.sh is indeed just buggy ;) | 23:06 |
| asac | odd ... not sure how allmakefiles.sh finds all the other Makefiles | 23:06 |
| asac | just the top level one is needed | 23:06 |
| asac | ok seems to go down through SUBDIRS or something | 23:07 |
| asac | and prism/installer isnt there | 23:07 |
| asac | yeah ;) | 23:07 |
| asac | so after that mozilla-devscripts xpi.mk needs another change and then all should be fixed ;) | 23:08 |
| dtchen | fta: interesting -- does clearing out ~/.pulse* help? | 23:11 |
| BUGabundo | dtchen: do you have the time to help joaopinto with audio probs with games? | 23:14 |
| fta | asac, lol, 3rd failure: checking for cairo >= 1.8.8 freetype2 fontconfig... Requested 'cairo >= 1.8.8' but version of cairo is 1.8.6 | 23:14 |
| asac | oh no ;) | 23:14 |
| asac | hmm... i thought i bumped cairo | 23:14 |
| asac | oh wait | 23:14 |
| fta | jaunty | 23:14 |
| asac | i didnt bump it there because i didnt see the failure | 23:14 |
| asac | in tb | 23:15 |
| dtchen | BUGabundo: if they're SDL-based games, I have a review of the latest upstream changes to the ALSA backend queued for this weekend. | 23:15 |
| asac | and the other failure was on 1.9.3 | 23:15 |
| asac | maybe means we will see the same cairo bump | 23:15 |
| asac | in 1.9.2 tomorrow | 23:15 |
| asac | most likely | 23:15 |
| fta | dtchen, could you put the sdl fixes in the ppa? | 23:15 |
| dtchen | BUGabundo: but I really, really need to focus on some PA bugs first. | 23:15 |
| dtchen | fta: yes, that is the plan | 23:15 |
| fta | dtchen, also, if you have a fix for choppy sound in virtualbox | 23:15 |
| BUGabundo | thanks dtchen | 23:16 |
| BUGabundo | I'll let him know | 23:16 |
| dtchen | fta: do you have a reliable test case for vbox? | 23:16 |
| dtchen | I can't reproduce it locally using vbox 3.0.8, but... | 23:16 |
| fta | vbox karmic, W7 as guest | 23:17 |
| dtchen | ok, I'm not sure how I would reproduce that unless there's a free version of W7 | 23:18 |
| dtchen | anyhow, head-down PA hacking for some hours now. | 23:18 |
| dtchen | bbl | 23:18 |
| BUGabundo | dtchen: there's a RC _free_ | 23:21 |
| BUGabundo | for 6 months or so | 23:21 |
| micahg | fta, so I should modify the use_xul_1.9_only to 1.9.1? | 23:23 |
| fta | yes | 23:23 |
| fta | because otherwise, it will take a random xul, it should use the one it has been built with | 23:24 |
| micahg | ok | 23:25 |
| micahg | I'll update that tomorrow night | 23:25 |
| micahg | what do I have to fix with prism/makefiles.sh | 23:25 |
| asac | micahg: back | 23:25 |
| asac | add prism/Makefile | 23:25 |
| asac | thats a plain bug in prism build system | 23:25 |
| asac | and i remember now that i already complained to plasticmillion about it when i last looked | 23:25 |
| asac | he promissed to fix it ;) | 23:25 |
| micahg | ok, so I make a patch to do that, right? | 23:26 |
| asac | yes. then next there is a problem of how mozilla-devscripts xpi.mk is used | 23:26 |
| asac | you have to fix it by not using a refractor.xpi:: rule approach | 23:26 |
| asac | but rather copying the .xpi to top level dir after the cdbs build | 23:26 |
| asac | so i would say in binary-post-build:: or something like that | 23:26 |
| fta | 4th try for tb3 :P | 23:27 |
| asac | micahg: so you see the refractor.xpi:: thing? | 23:28 |
| asac | remove that and use common-post-build-arch:: | 23:29 |
| asac | just put the copy of the .xpi there | 23:29 |
| asac | that should work | 23:29 |
| micahg | in rules? | 23:29 |
| micahg | asac: there are 3 lines there? | 23:29 |
| micahg | i remove them all? | 23:30 |
| asac | micahg: its just the wrong rule ... the action is right | 23:30 |
| asac | so the :: line replace that as i said | 23:30 |
| micahg | ok | 23:31 |
| fta | tb3 probably shifted to a fresher xul | 23:31 |
| asac | refractor.xpi:: build/prism zip -d dist/xpi-stage/refractor.xpi prism/\* cp -f dist/xpi-stage/refractor.xpi . | 23:31 |
| asac | not sure why there is a zip -d | 23:31 |
| asac | i thought that that was already done by the prism build system | 23:31 |
| asac | maybe drop that line too | 23:31 |
| asac | and only cp -f | 23:31 |
| asac | fta: sure that 1.9.2 didnt just land that cairo bump in between? | 23:32 |
| asac | would be naturally ... first land on trunk | 23:32 |
| asac | then to 1.9.2 | 23:32 |
| fta | 5 new reqs since yesterday | 23:32 |
| asac | then on 1.9.1 :( | 23:32 |
| asac | yeah | 23:32 |
| asac | err | 23:33 |
| asac | i thought just libindicate > 0.4 | 23:33 |
| asac | and this cairo thing as well as the other | 23:33 |
| asac | so 3 ;) | 23:33 |
| micahg | asac, I'm adding a patch to prism called add_makefil | 23:33 |
| micahg | add_makefile.patch | 23:33 |
| fta | asac, libindicate, libiw-dev, cairo, mesa-common-dev | 23:33 |
| asac | micahg: fix_prism_makefile_sh ;) | 23:33 |
| asac | use what you want | 23:33 |
| asac | just document it and send it upstream | 23:34 |
| asac | so he doesnt forget to appl that | 23:34 |
| micahg | ok | 23:34 |
| fta | the later is for WebGL, which is only in 1.9.3 (iirc) | 23:34 |
| asac | fta: libiw-dev? | 23:34 |
| asac | do they ship a libiw now in-source? | 23:34 |
| fta | no | 23:34 |
| asac | god help me :) | 23:34 |
| asac | but libiw-dev was a requirement for quiet some time | 23:35 |
| asac | for geolocation | 23:35 |
| asac | oh it was optional | 23:35 |
| asac | but we had it i thought | 23:35 |
| asac | if not it was my fault to sync it to the other branches | 23:35 |
| asac | mesa-common-dev sounds a bit scary too | 23:35 |
| asac | but could be something freaky ;) | 23:35 |
| asac | but common-dev sounds a bit coards | 23:35 |
| asac | coarse | 23:35 |
| fta | $ grep -c libiw-dev */configure.in | 23:35 |
| fta | mozilla-1.9.1/configure.in:0 | 23:35 |
| fta | mozilla-1.9.2/configure.in:1 | 23:35 |
| fta | mozilla-central/configure.in:1 | 23:35 |
| asac | not sure why libiw-dev would be in there | 23:37 |
| asac | thats a package name | 23:37 |
| asac | not a lib | 23:37 |
| asac | or header or .pc file name | 23:37 |
| asac | iwlib.h | 23:37 |
| asac | thats the check | 23:38 |
| asac | the libiw-dev is just a error message | 23:38 |
| micahg | asac: does libasound2 need to be an install-dep as well as a build dep? | 23:38 |
| asac | micahg: why? | 23:38 |
| asac | not sure why that would be | 23:38 |
| fta | asac, that's what we have in xul | 23:38 |
| asac | we have that | 23:38 |
| asac | yes | 23:38 |
| asac | but why are you saying they bumped the lower verison | 23:38 |
| fta | no, just cairo | 23:39 |
| asac | ok | 23:39 |
| fta | i said new reqs | 23:39 |
| asac | 00:33 < fta> asac, libindicate, libiw-dev, cairo, mesa-common-dev | 23:39 |
| fta | not reqs for new versions | 23:39 |
| asac | k | 23:39 |
| asac | but we had libiw-dev for 1.9.1 branch | 23:39 |
| asac | checkout the control | 23:39 |
| asac | i forgot to add it then | 23:39 |
| asac | if its not on the other branches | 23:39 |
| asac | micahg: why do you think it needs libasound2? | 23:40 |
| asac | thats what looked odd when i looked at your branch | 23:40 |
| fta | $ grep libiw-dev xul*head/debian/control | 23:40 |
| fta | xulrunner-1.9.1.head/debian/control: libiw-dev, libiw-dev (>= 29-2ubuntu6) [sparc powerpc] | 23:40 |
| fta | xulrunner-1.9.2.head/debian/control: libiw-dev, | 23:40 |
| fta | xulrunner-1.9.3.head/debian/control: libiw-dev, | 23:40 |
| asac | yes | 23:41 |
| micahg | asac: will you be on sometime between UTC 00:00 and UTC 12:00 on Sunday? | 23:41 |
| asac | thats true | 23:41 |
| asac | the sparc/powerpc is needed everywhere | 23:42 |
| asac | micahg: i can also finish the prism stuff if you don thave time | 23:42 |
| asac | no problem at all | 23:42 |
| asac | just push your branch and i can add this on top | 23:42 |
| asac | i will even keep you as changelog owner ;) | 23:42 |
| micahg | asac: it quit on it when I was trying to build | 23:43 |
| asac | odd | 23:43 |
| micahg | well, that's why I"m wondering if you'll be on sometime sunday | 23:43 |
| micahg | I can finish it sat night | 23:43 |
| asac | yeah | 23:43 |
| asac | seems its needed | 23:43 |
| asac | you need to add it as build dep | 23:43 |
| asac | not as dep | 23:43 |
| micahg | ok, I have build-dep on libasound2-dev | 23:44 |
| asac | it will automatically be detected and expanded in ${shlibs:Depends} | 23:44 |
| asac | yes | 23:44 |
| asac | if that name xists | 23:44 |
| asac | maybe its just libasoúnd-dev | 23:44 |
| asac | i would hope | 23:44 |
| asac | at least if the binary is libasound2 ... | 23:44 |
| micahg | nope | 23:44 |
| micahg | there is no ${shlibs:Depends} | 23:44 |
| micahg | ok asac, so ping me when you get on Sunday morning | 23:45 |
| micahg | hopefully I'll be done :) | 23:45 |
| asac | ok | 23:46 |
| asac | micahg: we need a shlibs:Depends | 23:46 |
| micahg | ok, I'll add it | 23:47 |
| asac | for the Depends: of the package that shipps the .sp files | 23:47 |
| asac | .so files | 23:47 |
| micahg | just for the prism main package, right? | 23:47 |
| asac | i would think so | 23:47 |
| micahg | ok | 23:47 |
| asac | whatever file ships the .so files ... (binary componanets) | 23:47 |
| micahg | ok | 23:47 |
| asac | needs that | 23:47 |
| micahg | got it | 23:47 |
| micahg | and I have plenty of time sat night to fix this | 23:47 |
| asac | actually i think all need ${shlibs:Depends} and ${misc:Depends} | 23:47 |
| micahg | it's a lot harder than I thought, but good practice | 23:47 |
| asac | for binary all misc:Depends alone should be enough | 23:47 |
| asac | yeah | 23:48 |
| asac | prism is a mess | 23:48 |
| micahg | for what songbird will need :) | 23:48 |
| asac | well not a mess | 23:48 |
| asac | just broken | 23:48 |
| asac | and mozilla buildsystem is kind of not obvious | 23:48 |
| asac | if you have not worked with it | 23:48 |
| asac | yeah. | 23:48 |
| asac | usualyl things are easy ... like rebase etc. | 23:48 |
| asac | then they become a bit harder ...and go back to easy.... but then there are weeks where there are tough things only ;) | 23:49 |
| micahg | gtg | 23:49 |
| micahg | tty on sunday | 23:49 |
| fta | asac, i still need to move tb3 out of umd... | 23:57 |
| fta | debian 296963 | 23:59 |
| ubottu | Debian bug 296963 in kernel-image-2.6.10-1-k7 "USB mouse continuously disconnecting" [Important,Closed] http://bugs.debian.org/296963 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!