| fta | dtchen, seems it was recommended by the pulse author | 00:04 |
|---|---|---|
| === asac_ is now known as asac | ||
| === micahg1 is now known as micahg | ||
| === ripps_ is now known as ripps | ||
| === debfx_ is now known as debfx | ||
| asac | [reed]: one issue i just noted looking at ffox 3.6 is this: http://people.canonical.com/~asac/tmp/Namoroka_Choose_User_Profile.png | 10:50 |
| asac | that utf issue ... its the same for all "..." ... also in the menus | 10:50 |
| asac | is that known? | 10:50 |
| asac | [reed]: same for all ... in UI: http://people.canonical.com/~asac/tmp/Namoroka_HomeDots.png | 10:52 |
| asac | fta: still building: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+packages ;) | 12:48 |
| asac | 15h ++ | 12:48 |
| fta | asac, heheh | 13:22 |
| asac | fta: those 10 minutes for each test ... is 10 minutes really needed? how often is that run? | 13:27 |
| asac | like if its run 10 times, we might be able to reduce build time everywhere considerably by moving it to 3 minutes ;) | 13:27 |
| asac | how did you guess that time? | 13:27 |
| fta | it's to avoid the FTBFS after 4h of inactivity when a given test is blocked on a network access. | 13:30 |
| fta | but it's just a timeout, not a running time, like if the test completes in 3 sec, that's 3 sec, not 10 min | 13:32 |
| fta | maybe it's not enough for arm | 13:32 |
| fta | if you don't have a restricted env like in the builders, you could remove the timeout and see how long those tests really need | 13:33 |
| fta | asac, ^^ | 13:34 |
| asac | hmm | 13:46 |
| asac | ok | 13:46 |
| asac | fta: but how likely is it that it will take 10 minutes? | 13:46 |
| fta | some take several minutes | 13:46 |
| asac | k | 13:48 |
| fta | asac, http://paste.ubuntu.com/333128/ | 13:50 |
| fta | asac, "Started 17 hours ago" ??? wtf, didn't it take 9h the 1st time? | 14:56 |
| asac | no | 14:57 |
| asac | it took 9h after fixing the first build failure | 14:57 |
| asac | e.g incremental from there on | 14:57 |
| fta | oh | 15:06 |
| fta | i see it failed on karmic in opts_check_SSE2.cpp | 15:06 |
| fta | skia | 15:06 |
| fta | what did you do to make that work? | 15:07 |
| fta | oh, armv7=1 | 15:07 |
| fta | so why set that on lucid only?? | 15:08 |
| fta | asac, ^^ | 15:08 |
| fta | posted my evo patch | 15:14 |
| fta | uh? https://edge.launchpad.net/~fta/+oauth-tokens | 15:25 |
| asac | fta: because only on lucid we support armv7 and higher only | 16:07 |
| asac | on karmic we still support older chips | 16:07 |
| asac | so we cannot use armv7 there | 16:07 |
| asac | otherwise stuff would die when starting it on older target platforms | 16:08 |
| fta | hm, i have no solution to offer then, upstream clearly supports only v7 | 16:13 |
| fta | someone has to port it :P | 16:13 |
| asac | fta: if they would only support v7 ... then they should add that as a default ;) | 16:14 |
| asac | anyway | 16:14 |
| asac | yes. | 16:14 |
| asac | i think the problem you see above is what armin76 complained about | 16:14 |
| asac | already | 16:14 |
| fta | afaics, it's coming from android | 16:15 |
| asac | lucid is main target. just wanted to see if karmic works out of box | 16:15 |
| asac | once i have hardware i will try to port it (or maybe cross compiler setup) | 16:15 |
| asac | android definitly targets older arm versions | 16:15 |
| asac | armv7 is quite new and there is not much hardware out there yet | 16:15 |
| asac | most stuff is armv5 afaik and v6 | 16:15 |
| asac | like iphone etc. | 16:15 |
| fta | ompiling /build/buildd/chromium-browser-4.0.261.0~svn20091201r33442/build-tree/src/sconsbuild/Release/obj/skia/skia/__/third_party/skia/src/opts/SkBlitRow_opts_arm.o | 16:16 |
| fta | /tmp/ccRUIN1V.s: Assembler messages: | 16:16 |
| fta | /tmp/ccRUIN1V.s:131: Error: thumb conditional instruction should be in IT block -- `moveq ip,#8' | 16:16 |
| fta | scons: *** [/build/buildd/chromium-browser-4.0.261.0~svn20091201r33442/build-tree/src/sconsbuild/Release/obj/skia/skia/__/third_party/skia/src/opts/SkBlitRow_opts_arm.o] Error 1 | 16:16 |
| fta | it failed on lucid too | 16:16 |
| asac | ok | 16:16 |
| asac | thats adding CFLAGS=... | 16:17 |
| asac | one second | 16:17 |
| asac | supposed to be in toolchain by default | 16:17 |
| asac | for now we have to add it | 16:17 |
| asac | https://wiki.ubuntu.com/ARM/Thumb2 | 16:17 |
| asac | so adding -Wa,-mimplicit-it=thumb to CFLAGS and CXXFLAGS is needed | 16:17 |
| asac | just for lucid | 16:17 |
| asac | or someone should port this properly to arm ;) | 16:18 |
| asac | thumb2 | 16:18 |
| asac | but implicit-it is fine for now | 16:18 |
| fta | will also report that upstream.. | 16:18 |
| asac | thx | 16:19 |
| asac | fta: the wiki page above has details ... you can hand them | 16:19 |
| asac | https://wiki.ubuntu.com/ARM/Thumb2 | 16:19 |
| asac | that one | 16:19 |
| asac | and maybe | 16:19 |
| asac | https://wiki.ubuntu.com/Mobile/ARMv7AndThumb | 16:20 |
| asac | which has a few typed slides with more details | 16:20 |
| asac | thx | 16:22 |
| asac | fta: will you add the implicit-it=thumb to CFLAGS/CXXFLAGS for lucid+arm or should i commit it? | 16:23 |
| fta | just let me get the 1st answer from upstream (it's earlier for them) | 16:23 |
| asac | ok. as long as its in tomorrows daily i am fine | 16:24 |
| asac | but implicit-it is almost certainly the only thing we can do for now ;) | 16:24 |
| asac | will be changed in toolchain in a week or two so this will just go away | 16:24 |
| fta | yep, it's too late for today, it's past 25 | 16:24 |
| asac | its 24 ;) | 16:24 |
| asac | hehe | 16:24 |
| fta | 24:51 | 16:24 |
| asac | ok ping me if you want me to add those flags ;) (though i am not sure how to best inject that for scons) | 16:25 |
| fta | will do, don't worry | 16:26 |
| fta | hm, metacity crashed twice today because of chromium | 16:30 |
| === mac_v_ is now known as mac_v | ||
| ccheney | asac: do we want binary package names or the source for the runtime rdepends? | 16:36 |
| ccheney | eg something like this: zcat Packages.gz | grep-dctrl -n -F Depends xulrunner-1.9 -s Source | sort -u | 16:38 |
| asac | ccheney: i think sources is what we need to know | 16:38 |
| asac | but if we have binaries first we can later compress them | 16:38 |
| ccheney | ok, yea its easy to find out either of them | 16:39 |
| ccheney | just change -s Source or -s Package | 16:39 |
| asac | right. i think having list of binaries is good still | 16:40 |
| asac | so we know if its a plugin etc. without looking up | 16:40 |
| ccheney | ok | 16:40 |
| asac | so both ;) | 16:41 |
| ccheney | ok | 16:41 |
| fta | hu, grep-dctrl, nice :) | 16:41 |
| * ccheney running mirror dists now :) | 16:42 | |
| asac | innovative commands can ease the task ;) | 16:42 |
| ccheney | yea | 16:43 |
| fta | asac, apparently, your theme work-around for evo is not enough.. or has been reverted (karmic), i jsut double-clicked on an att, and evo looped, 100% cpu, 100% mem :( | 16:43 |
| asac | fta: backtrace :/ | 16:43 |
| asac | we can then see if it was reverted or never committed to trunk or whatever | 16:43 |
| asac | or maybe a new engine that was forked _before_ applying it | 16:44 |
| asac | or maybe something unrelated :-P | 16:44 |
| fta | lol, it was completely frozing the box, i had to go to a console and kill it | 16:44 |
| asac | fta: lucid? | 16:44 |
| fta | no, karmic | 16:44 |
| asac | hmm | 16:44 |
| asac | if its a regression, check what packages came recently | 16:44 |
| asac | we should nail that down (if it is) | 16:44 |
| fta | strangely, i no longer have anything in /var/crash | 16:44 |
| asac | fta: we disable apport by default for release | 16:45 |
| asac | otherwise we would get covered in bugs ;) | 16:45 |
| fta | oh, how can i re-enable that? | 16:46 |
| fta | [1473971.334865] totem-plugin-vi[11482]: segfault at 6863732f ip 007ce645 sp 07398ec0 error 4 in libxcb.so.1.1.0[7c6000+1c000] | 16:46 |
| fta | [2163811.388737] totem-plugin-vi[15733]: segfault at 0 ip 009bf645 sp 046edec0 error 4 in libxcb.so.1.1.0[9b7000+1c000] | 16:46 |
| fta | [2173254.714962] totem-plugin-vi[14326]: segfault at 21 ip 03828d36 sp 030d3ec0 error 4 in libX11.so.6.2.0[37e8000+12a000] | 16:46 |
| fta | hm, no evo, no metacity, no ff | 16:46 |
| fta | strange | 16:46 |
| asac | there is a gconf setting afaik | 16:46 |
| asac | let me check | 16:46 |
| asac | hmm | 16:47 |
| asac | no manpage either ;) | 16:47 |
| asac | ccheney: remember how to enable/disable apport? | 16:48 |
| fta | /etc/default/apport | 16:48 |
| asac | oh ;) | 16:48 |
| asac | right. enabled= .-P | 16:48 |
| === yoasif__ is now known as yoasif_ | ||
| fta | asac, http://code.google.com/p/chromium/wiki/LinuxChromiumArm | 16:57 |
| ccheney | asac: we need to track for updates/backports/etc also right? | 17:01 |
| asac | fta: were most of the dev stuff in the ia32-libs package for chromium? | 17:03 |
| asac | ccheney: to be safe we need to check updates and security ... backports just a brief check i guess | 17:04 |
| ccheney | asac: ok | 17:04 |
| fta | asac, eh? | 17:04 |
| fta | ia32-libs is dead | 17:04 |
| fta | i mean, no longer needed | 17:05 |
| === yoasif_ is now known as yoasif | ||
| asac | fta: right. just wondered how many extra packages you needed | 17:18 |
| asac | in your chromium ia32 package | 17:18 |
| asac | folks complained that they cannot build mozilla stuff that way | 17:18 |
| asac | and hoped i could say: check what fta did ... maybe extend it a bit and there you go ... | 17:18 |
| fta | asac, what do they want to build? my chromium ia32 package was just a kind of addon to ia32-libs, to add the missing bits for each distro | 17:21 |
| fta | but it was empty for karmic | 17:21 |
| fta | asac, https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/487141 | 17:31 |
| ubottu | Ubuntu bug 487141 in nspluginwrapper "[Patch included] NPN_GetStringIdentifiers implementation is broken" [Undecided,New] | 17:31 |
| ccheney | asac: should it only be checking for xulrunner-1.9* or any xulrunner? | 17:38 |
| ccheney | asac: for eg dapper | 17:38 |
| * ccheney got a hit on sun-java5 but needs to look at the actual record still | 17:40 | |
| fta | http://paste.ubuntu.com/333333/ :) | 19:25 |
| ccheney | asac: i got the list together for binary packages, should i stick in the ubuntu wiki, or somewhere else? | 19:30 |
| * ccheney put it in https://wiki.ubuntu.com/xulrunner-list | 19:31 | |
| bdrung | asac: were there a reason why xpi.mk is maintained in mozilla-devscripts and not in a separate package? the main purpose of mozilla-devscripts is for packaging mozilla apps and not mozilla extensions. why not splitting them up? | 22:02 |
| fta | bdrung, just because it was easier that way, m-d was already there, and xpi was just one file | 22:55 |
| bdrung | fta: now we have more files ;) src/xpi* | 22:56 |
| bdrung | fta: would it be useful to split them? | 22:56 |
| fta | i don't really think it's necessary, and it would mean re-applying for the new package to be accepted, and changing all the build-deps | 22:58 |
| fta | i don't see any benefit | 22:59 |
| bdrung | fta: linux philosophy: one tool (here: package) for one purpose | 22:59 |
| fta | would be like splitting devscripts, why? it's a collection of scripts | 23:00 |
| fta | all are mozilla related, so it makes sense to keep them grouped | 23:00 |
| bdrung | xpi* is extension oriented. so we have the mozilla app group and the xul extension group | 23:01 |
| fta | it's small, you want to make it even smaller | 23:03 |
| fta | asac, i've committed the thumb2 arm cflag, but i didn't test it, the syntax may be a problem GYP_DEFINES="foo bar release_extra_cflags=-Wa,-mimplicit-it=thumb" .. i'm not sure gyp will parse the a=b=c correctly | 23:05 |
| fta | with a comma in between | 23:05 |
| bdrung | fta: k, you convinced me | 23:10 |
| fta | great :) imho, it's less work to keep it like it is | 23:11 |
| asac | fta: hmm. maybe "foo bar release..:='....'" | 23:30 |
| asac | bdrung: its went to be a collection of devscripts | 23:30 |
| asac | no reason to split it up | 23:30 |
| fta | we'll see, that would be the next try | 23:30 |
| asac | mozilla-devscripts basically should have all stuff from xulapp.mk, over xpi.mk to package-up.mk and so on ... | 23:31 |
| fta | asac, i'm respinning ucd right now (today's failed) so feel free to grab it in a few minutes so it builds during the night | 23:32 |
| asac | with '' ? | 23:32 |
| asac | thx | 23:32 |
| bdrung | asac: can you have a look at my changes to m-d? | 23:33 |
| asac | for me more compressed has always to be balanced with readability ;) | 23:34 |
| fta | asac, nope, if it works like i think it works, '' would be passed as they are and wrong, but we'll see | 23:34 |
| asac | like unifying xpath expressions to one | 23:35 |
| asac | might be a good excersize, but doesnt gain anything | 23:35 |
| bdrung | asac: speed! | 23:37 |
| asac | neglectable for this i would think ;) | 23:37 |
| bdrung | asac: it's faster. we use lazy evaluation for all those install.rdf magic is evaluated multiple times. | 23:38 |
| bdrung | it sums up to some seconds. | 23:38 |
| asac | people feel more important if their build takes a few minutes than just a few second ;) | 23:39 |
| bdrung | asac: maybe it would be useful to put all the xpi-recommends stuff into an separate script (maybe dh_xul-ext?) | 23:39 |
| bdrung | asac: i have a testsuite here with many extensions and i am impatient :P | 23:40 |
| asac | te permission fixup looks ok. | 23:40 |
| asac | a bit too much explicitly imo. but i think thats ok unless i get a great other idea ;) | 23:40 |
| bdrung | asac: the maintainer can disable it, if it is too strict. | 23:41 |
| asac | i know ;) | 23:42 |
| bdrung | but the normal ext contains no file, which needs the exec bit. | 23:42 |
| asac | right. thats why i even wonder why we would to look for !# | 23:43 |
| asac | other approach woudl be to make all stuff not executable ... | 23:44 |
| bdrung | because i found one example for it | 23:44 |
| asac | yes. but thats an exception | 23:44 |
| asac | which is fine and for which we have those vars | 23:44 |
| bdrung | asac: that's not enough. there are files with 777 (stupid *** user) | 23:44 |
| bdrung | *** = otherOS | 23:45 |
| asac | bdrung: my suggestion is: make everything 644. period. and add explicit whitelist feature | 23:45 |
| asac | but i guess you want a full on/off knob ;) | 23:45 |
| bdrung | yes. i want to have a working default for all packages, that i know. (and some knobs for unknown freeking packages) | 23:46 |
| asac | sure. i think its better to start with knobs for the cases we know and extend if needed. to some degree one has to be vain :) ... like: freeking unknown packages should adapt a bit or wait to be supported ... rather than having big "force/unforce everything flags" | 23:48 |
| bdrung | asac: do you have an idea where to put the config files (debian bug 558490)? my idea: symlink defaults/preferences/*.js to /etc/xul-ext/$package.js | 23:48 |
| ubottu | Debian bug 558490 in mozilla-devscripts "adblock-plus / xul-ext-adblock-plus: move configuration to /etc" [Normal,Open] http://bugs.debian.org/558490 | 23:48 |
| asac | bdrung: at best we would ship exactly one .js file that is empty by default that the admin can modify | 23:49 |
| asac | and not link the whole preferences dir to /etc/.. etc. | 23:50 |
| bdrung | how should this work? | 23:50 |
| asac | its plain wrong to allow users to change the "base" defaults | 23:50 |
| asac | so basically three layers is what is wanted for packages like firefox etc: | 23:50 |
| asac | 1. base defaults -> shipped in package, not modifiable | 23:50 |
| asac | 2. admin defaults -> shipped in /etc/ ... one config file is enough | 23:51 |
| asac | 3. user defaults -> in user profile | 23:51 |
| asac | so mozilla doesnt support those three steps yet | 23:51 |
| bdrung | so we are talking about 2. | 23:51 |
| asac | yes. | 23:51 |
| asac | at least not everywhere | 23:51 |
| asac | so xulrunner has a special directory called "syspref" | 23:51 |
| asac | that is loaded after the defaults/preferences/ ... | 23:51 |
| asac | but that doesnt exist for extensions | 23:52 |
| asac | so for extensions we can trick by choosing a filename that comes first in alpabetic order | 23:52 |
| asac | like: | 23:52 |
| asac | /usr/share/ubufox/defaults/preferences/000system.js | 23:52 |
| asac | that file can be modified by admins ... and they can go back to factory defaults still by simply cleaning the config file | 23:52 |
| asac | its linked to | 23:53 |
| asac | /etc/firefox-3.0/pref/ubufox.js | 23:53 |
| asac | ls -l /usr/lib/firefox-3.6b5pre/defaults/syspref/ | 23:54 |
| asac | thats the admin dir for firefox for instance | 23:54 |
| asac | checkout the defaults/pref directory ... there is so many config | 23:54 |
| bdrung | why have we firefox in the path? what is with an package, that works in firefox and thunderbird? | 23:54 |
| asac | and if users do a single merge error on package update they might screw full firefox | 23:54 |
| asac | thats why it is bad to put all those configs up to editing | 23:54 |
| asac | bdrung: its probably a bug | 23:55 |
| asac | atm ubufox only supports firefox | 23:55 |
| asac | and i didnt want to add /etc/ubufox | 23:55 |
| asac | and we didnt have /etc/xul-ext ... yet | 23:55 |
| asac | anyway. the idea should be not to link all the .js, but carefully add one .js link to the file the admin can later on tweak | 23:56 |
| asac | not sure how to best do it ;) | 23:56 |
| asac | maybe ls the dir | 23:56 |
| bdrung | but for the future? where should be the config file in /etc? | 23:56 |
| asac | bdrung: whatever the debian extension team is happy with | 23:57 |
| asac | could be /etc/ubufox | 23:57 |
| asac | or /etc/xul-extensions/ubufox/... | 23:57 |
| asac | or /ext/xul-extensions/ubufox.js | 23:57 |
| bdrung | can you write a mail to the mailing list? | 23:57 |
| asac | (if we have a strict one config-file policy) | 23:57 |
| asac | is there an thread where this should go? | 23:58 |
| bdrung | i have to go to sleep now. | 23:58 |
| asac | me too ;) | 23:58 |
| asac | so wont do it today anyway | 23:58 |
| bdrung | i checked some extensions. they had only one js file for configuration. | 23:58 |
| asac | yes. but that shouldnt be linked there | 23:58 |
| asac | that one should always stay in the original place | 23:58 |
| asac | so the user can always easily go back to factory defaults | 23:59 |
| asac | by wiping his /etc/ file | 23:59 |
| asac | its really messy to fight with the config file system for users. and users find instructions to change them and then fail to merge them and then get huge bustage and then cause support headache ;) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
