| wat | so | 02:48 |
|---|---|---|
| wat | ubuntu mobilwe | 02:48 |
| wat | mobile* | 02:48 |
| wat | when will it be available ?_? | 02:48 |
| wat | An iPhone flash for it would be hella cool' | 02:48 |
| lool | Morning | 08:30 |
| lool | asac: Hey, around? | 09:24 |
| lool | asac: I tested langpacks and they work with up-to-date midbrowser and xulrunner; however some strings are missing (e.g. Characted Encoding in the menu) | 09:25 |
| lool | Also parts of the Extensions dialogs aren't translated, but I don't know whether these were translated in the past | 09:26 |
| lool | I have language-pack-gnome-fr 1:8.04+20080527.0ume2 and language-pack-gnome-fr-base 1:8.04+20080527 | 09:27 |
| lool | asac: On an unrelated topic, you might recall I poked you for comments on an evolution-rss patch; did I miss your reply? | 09:28 |
| asac | lool: err, i think i replied in the bug | 09:43 |
| asac | lool: did you upgrade the language-pack-base and language-pack packages as well? which version do you have there? | 09:44 |
| lool | asac: language-pack-fr 1:8.04+20080527 and language-pack-fr-base 1:8.04+20080527 | 09:46 |
| asac | those are too old | 09:47 |
| asac | hmm | 09:48 |
| asac | no | 09:48 |
| asac | look good | 09:48 |
| asac | what version do you see for xulrunner translation in the addons dialog? | 09:48 |
| lool | asac: 1.9 | 09:49 |
| lool | asac: I don't have any language-pack-fr or language-pack-fr-base in ppa | 09:49 |
| asac | lool: true 1.9.0.1 it should be though | 09:50 |
| asac | what is in /usr/lib/xulrunner-addons/extensions/langpack*fr*/install.rdf ` | 09:50 |
| asac | ? | 09:50 |
| asac | as version? | 09:50 |
| lool | em:version="1.9" | 09:51 |
| asac | should be 1.9.0.1 | 09:51 |
| asac | please check if you have all from -updates | 09:52 |
| lool | The only French langpack is language-pack-gnome-fr AFAICS | 09:52 |
| asac | you need language-pack-fr and language-pack-fr-base | 09:52 |
| lool | asac: Ah you want me to try the hardy-updates version of the langpacks? | 09:52 |
| asac | you need them yes | 09:55 |
| asac | is that an issue? | 09:55 |
| lool | asac: It's fine if these weren't forked for ume | 09:56 |
| lool | I have language-pack-fr 1:8.04+20080708 now | 09:56 |
| lool | asac: Extension version is good now, but most items in the menu aren't translated anymore | 09:58 |
| lool | Only "Encoding" is, the rest isn't (e.g. "new tab") | 09:58 |
| lool | Oh I upgraded language-pack-gnome-fr but shouldn't have | 09:59 |
| lool | asac: I think we need a language-pack-gnome-fr update in ppa | 09:59 |
| asac | yes. i think all lang-packs need to be updated. | 09:59 |
| asac | i have a call in a minute. will ping you when back | 09:59 |
| lool | Ok | 09:59 |
| lool | asac: Everything is fine now | 10:01 |
| lool | asac: So we just need a refresh of language-pack-gnome-* in ppa AIUI | 10:01 |
| asac | yes. we just need to put the midbrowser bits from ppa into the lates from -updates | 10:02 |
| lool | asac: I'm happy to follow your instructions for the update as to allow me to repeat this for the next langpack updates | 10:02 |
| asac | look in mozilla.tar.gz in ppa version | 10:03 |
| asac | there is midbrowser/extensions directory | 10:03 |
| asac | that one needs to be added to mozilla.tar.gz of -updates one | 10:03 |
| * lool gets http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/m/midbrowser/midbrowser_0.3.0release-1~8.04.1.dsc and http://archive.ubuntu.com/ubuntu/pool/main/l/language-pack-gnome-fr/language-pack-gnome-fr_8.04+20080708.dsc | 10:04 | |
| lool | Oh the data/mozilla.tar.gz from ppa's language-pack-gnome-fr | 10:05 |
| asac | yes | 10:05 |
| lool | asac: Kyle did some changes as well in ume2 | 10:06 |
| lool | * Replace grabanddrag.jar and modify chrome.manifest accordingly to add | 10:06 |
| lool | grabanddrag fr (French) translations. | 10:06 |
| lool | Do we need to repeat these as well? | 10:06 |
| asac | those should be in mozilla.tar.gz alrewady | 10:06 |
| asac | if you use the latest from ppa | 10:06 |
| lool | asac: And you're repeating this for all langs? | 10:07 |
| asac | yes | 10:08 |
| asac | thats simple. just copy the usr/lib/midbrowser directory from ppa mozilla.tar.gz to new one | 10:08 |
| asac | i think there even is no mozilla.tar.gz in new -gnome langpacks | 10:09 |
| asac | so you can just copy it over | 10:09 |
| asac | but take care that only usr/lib/midbrowser directory tree is in there | 10:09 |
| lool | Ah some are ume1, I'll need to do this properly it seems | 10:11 |
| lool | There are some differences in the tarballs, but I don't think they matter | 10:13 |
| lool | drwxr-xr-x asac/asac 0 2008-06-10 22:39 ./usr/ | 10:13 |
| lool | drwxr-xr-x asac/asac 0 2008-06-10 22:39 ./usr/lib/ | 10:13 |
| lool | drwxr-xr-x kyle/kyle 0 2008-06-10 22:39 usr/ | 10:13 |
| lool | drwxr-xr-x kyle/kyle 0 2008-06-10 22:39 usr/lib/ | 10:13 |
| asac | shouldnt matter | 10:14 |
| * lool pushes langpacks | 10:28 | |
| asac | uh | 10:30 |
| asac | rock | 10:30 |
| asac | lool: do they work? | 10:30 |
| lool | asac: Well I see everything translated in the menu, and I see a midbrowser (fr) extension in the list | 10:34 |
| lool | version 0.3.0 | 10:34 |
| lool | asac: is there a particular string I could use to check whether this works? | 10:34 |
| asac | if the menu is completely translated | 10:34 |
| asac | and the preferences dialog as well | 10:34 |
| asac | then all should be fine | 10:34 |
| lool | Yes, both of these are translated | 10:35 |
| asac | lool: to QA this, go to every tab in the preferences. | 10:39 |
| asac | if nothing is broken it should be fine | 10:39 |
| asac | ask kylem to verify that there are no regressions for him maybe | 10:39 |
| lool | asac: Oh I wanted to tell you about that: kyleN confirmed yesterday evening that he used your instructions for customer builds | 10:41 |
| lool | Not for the ppa | 10:41 |
| asac | look at ppa ... it was him uploading the last ones ;) | 10:41 |
| asac | but well. i dont get why he didnt upload to ppa though | 10:41 |
| lool | I don't think he cares directly about the ppa, nor are USG people pulling directly from it into their builds -- they snapshot from time to time and review the package updates | 10:41 |
| lool | asac: Yes, I saw him as uploader of some updates, I don't reconcile the two things though | 10:42 |
| lool | 22:22 < kyleN> lool.updating langpacks? first I herd of it | 10:42 |
| lool | 22:22 < kyleN> heard | 10:42 |
| lool | 22:23 < kyleN> I did some manual modifications to get a required build out | 10:42 |
| lool | 22:23 < lool> 12:25 < asac> lool: i told kylem how to update them before i left for the summit | 10:42 |
| lool | 22:24 < kyleN> lool, he meant me, but what I did was a one time update needed for a custom project | 10:42 |
| lool | asac: On another topic, persia wondered whether liferea would need an update at the same time as xulrunner >= 1.9.0.1; I suggested that probably not as liferea wasn't updated in hardy-security/-updates | 10:53 |
| lool | asac: But in the end we thought we would double-check with you :-) | 10:53 |
| asac | lool: if its not in "Breaks:" then it shouldnt be required from what i can tell | 10:55 |
| lool | asac: Great | 10:56 |
| lool | asac: Re: GNOME #541872 thanks for your comment, I didn't see it as I wasn't subscribed to the bug, sorry; I am now | 10:59 |
| ubottu | Gnome bug 541872 in general "crash in Evolution Mail and Calendar:" [Blocker,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=541872 | 10:59 |
| asac | lool: try to start it ;) | 11:00 |
| asac | (liferea) | 11:00 |
| === ogra_ is now known as ogra | ||
| lool | asac: Yeah it WFM | 11:14 |
| asac | lool: the patch? | 11:17 |
| lool | asac: liferea | 11:19 |
| asac | ah | 11:25 |
| persia | Team meeting in #ubuntu-meeting in 5 minutes | 12:56 |
| persia | Err. 4 :) | 12:56 |
| lool | persia: So you wanted to clear up my thoughts on squashfs support in ubiquity? | 14:02 |
| persia | lool: Re: GTK support for em: That actually doesn't help very much: it makes apps bigger in high-DPI environments. | 14:02 |
| persia | Getting proper resolution independence is about creating guidelines for size, and checking the current environment for display. | 14:03 |
| persia | As an example, if I've a 596 x 480 viewport (default Ubuntu viewport at 640x480), I need to pick a size for a terminal that fits there, which means picking the right font size, etc. | 14:04 |
| ogra | right | 14:04 |
| lool | persia: I think GTK support for em is just the start | 14:04 |
| ogra | we need a 480px min height policy :) | 14:04 |
| persia | If I then define the window decoration in "em" units, I have even less to play with when I'm using a 200DPI device. | 14:04 |
| lool | persia: It will force Gtk+ application writers to think about their UI size-independence, and move them away of pixel driven UI sizes | 14:05 |
| lool | The point here is that you can nicely "scale the application by changing the font size" | 14:05 |
| persia | lool: Well, not being pixel driven helps, but swapping pixels for ems is actively harmful for the high-dpi low-resolution environment. | 14:05 |
| lool | This is a huge step forward IMO | 14:05 |
| ogra | but if the window has a min height of 600px set you dont gain much | 14:06 |
| persia | Yeah, at least is means there is some thought involved. | 14:06 |
| lool | It moves the problem to "scaling ems" for us, which can be done centrally | 14:06 |
| lool | The kludge will be much smaller to maintain :-) | 14:06 |
| ogra | or graphics content forces the 600px | 14:06 |
| persia | True, although I wouldn't want everyone to become as myopic as I from looking at the results :) | 14:06 |
| persia | Anyway, about the installer. | 14:06 |
| lool | Anyway, there's no perfect solution; you can have a 24" screen in front of you, or at the other end of a room, and you will have different requirements for the displayed size of apps and fonts | 14:07 |
| persia | Basically, if the HW has sufficient secondary storage to support expected regular use without unionfs, it makes life *lots* easier not to install that. | 14:07 |
| persia | So, for 4G+ devices (based on Ubuntu Desktop HW requirements), it's best to just copy the contents of the squashfs onto a target partition on the device. | 14:07 |
| persia | That gives us small size increase for updates, simplified support matrix, compatibility with alternate metas for people who want to switch between -mid and -mobile, etc. | 14:08 |
| persia | But, for devices without that much secondary storage, such a model quickly becomes unsuitable. Just unpacking the livecd takes about 2G. | 14:09 |
| persia | With the smaller seed, we can probably take that down to 1.5G, but it's still insufficient for basic use. | 14:09 |
| persia | (not enough space for user data) | 14:09 |
| persia | So, we'd need to have a squashfs. | 14:09 |
| lool | persia: Ack; that's actually the reason hardy's images install squashfs | 14:10 |
| lool | (in UME) | 14:10 |
| persia | It's not reasonable to ask these devices to build such a squashfs at install time, because it's painfully time consuming, and requires lots of disk space somewhere. | 14:10 |
| persia | (Yes, I wanted to do it that way, but I was unable to find any believeable reason it would work) | 14:10 |
| persia | So, the trick is to use the squashfs used on the installer image itself. | 14:11 |
| ogra | right | 14:11 |
| lool | Sure, I came so far | 14:11 |
| ogra | which is since we use livefs.sh for building it already configured in an ideal way | 14:11 |
| persia | So, what one does is to copy the install image livefs onto the device, and construct it as a unionfs. | 14:11 |
| lool | Agreed; that's the only way I imaginated it as well | 14:12 |
| ogra | ubiquity currently only supports the 4G case | 14:12 |
| persia | Where this gets tricky is that the configuration of the livefs for the install image, for the installed image, and the contents of the root filesystem for the >4G case are all subtly different. | 14:12 |
| ogra | (copy content) | 14:12 |
| ogra | huh ? | 14:12 |
| ogra | they arent | 14:13 |
| persia | Yes they are. Hold on... | 14:13 |
| ogra | only the fs setup is | 14:13 |
| ogra | you need to have the copy/setup unionfs etc stage before the config stage | 14:13 |
| persia | config stage? | 14:13 |
| ogra | then ubiquity can do everything the same way in both cases | 14:13 |
| ogra | applying the config | 14:14 |
| ogra | for the target content | 14:14 |
| persia | ubiquity doesn't apply a config: it just copies the contents of the live image. | 14:14 |
| ogra | and configures /target according to your preseeding | 14:14 |
| lool | So I still think we can do the same thing in the two cases | 14:14 |
| persia | ogra: Except you don't run most of d-i, because you've already got that in the livefs. | 14:15 |
| lool | Instead of formatting and copying files to the new partitions, you partition, setup unionfs, and copy only differing files over | 14:15 |
| ogra | right | 14:15 |
| persia | lool: Well, not quite, because you need to support the reset-to-original-state use-case. | 14:15 |
| ogra | rm -rf /cow/* ? | 14:15 |
| persia | Anyway, please object when I get to that point, rather than getting ahead :) | 14:16 |
| ogra | and reapply the defaults | 14:16 |
| persia | So, the first interesting difference is between the installer livefs and the installed filesystem for the >4G case. | 14:16 |
| persia | ubiquity has a hook to remove the things one doesn't want post-install, such as ubiquity itself. | 14:16 |
| ogra | and unused langpacks | 14:17 |
| persia | (it's a little odd to have a "click here to install" button on an installed system) | 14:17 |
| persia | Yes, and unused langpacks, and other bits. | 14:17 |
| ogra | right, we need to exclude that in livefs.sh | 14:17 |
| ogra | and apply at bootime | 14:17 |
| lool | persia: Sure | 14:17 |
| lool | That's all possible in the target fs in the same way i would guess | 14:17 |
| lool | You might want to exclude this from the original squashfs though | 14:18 |
| persia | Right, it's just python to adjust the final image before first boot. | 14:18 |
| ogra | right | 14:18 |
| ogra | that should be handled by the image builder | 14:18 |
| persia | Where this gets especially interesting is when you consider the same situation for the 2G case. | 14:18 |
| persia | The same model doesn't work, because the stuff to be removed would only be marked unused in the overlay, and get restored when the overlay is wiped on device reset. | 14:19 |
| ogra | the image builder should a) build a squashfs without these contents for us ... b) set up a unionfs at buildtime c) copy all langpacks and ubiquity inot that | 14:19 |
| ogra | and then copy cow.img and squashfs.img into the dd'able image | 14:19 |
| persia | You're getting ahead again :) Precisely. | 14:20 |
| ogra | (btw we use aufs now, no uniofs available anymore, we should adjust our wording ;) ) | 14:20 |
| ogra | persia, the above works for both models | 14:20 |
| persia | The last interesting thing is that the squashfs to be deployed in the 2G case should have an initramfs pre-configured to continue to use squashfs as it gets adjusted. | 14:21 |
| lool | persia: Why would you reset the overlay? | 14:21 |
| persia | This then needs to be adjusted to not look that way in a final state in the >4G case. | 14:21 |
| ogra | right | 14:21 |
| ogra | but thats a single initramfs script | 14:22 |
| persia | lool: To restore the device to "factory settings". It's an OEM requirement that is commonly used in consumer devices. | 14:22 |
| ogra | well, have a spare partition where you tar up the content of /cow | 14:22 |
| persia | Personally, I find it useless, but since it's not that hard to do if we're fiddling around to handle splitting out ubiquity and langpacks, etc. anyway, there's no reason not to do it. | 14:22 |
| ogra | the reset funtion wipes /cow and extracts the tar back | 14:22 |
| ogra | no magic | 14:22 |
| persia | Mind you, I'm never likely to get a <4G device again (even the thing I use for a phone as >4G), but for those that do... | 14:23 |
| ogra | we need something like mem=256M dfor disks in the kernel :P | 14:23 |
| persia | ogra: No magic, as long as we make sure that the squashfs as deployed exactly matches the environment we want on device reset. | 14:23 |
| * ogra is joking indeed | 14:23 | |
| ogra | persia, my expectation would be that we can offer install to external devices .. so you could install to a 2G USB key | 14:24 |
| ogra | for testing purposes | 14:24 |
| ogra | all that is done by my classmate installer already we can steal code from there as we want | 14:24 |
| ogra | (the same counts for the image building process, all the above exists) | 14:25 |
| ogra | sadly the installer is 100% shell ... so for ubiquity that needs lots of adjustment | 14:25 |
| persia | ogra: Absolutely: it's not for testing purposes, but rather for support of various devices. I've two different devices that have very small flash as primary secondary storage and moderate sized secondary secondary storage. I'd probably want /boot on the flash, but install to the HD or slower flash (depending on which of my devices is being considered) | 14:25 |
| persia | That means having the ability to use a partition tool and install to arbitrary partitions on the target device, including, if so desired, USB keys. | 14:26 |
| lool | persia: That 'reset to factory settings' feature is new to me, and seem completely orthogonal | 14:26 |
| ogra | for 2G we shuld have a fixed partitioning scheme anyway | 14:26 |
| persia | lool: orthogonal to what? | 14:26 |
| persia | Essentially, implementation only means that we don't leave a crufty /cow at install time. | 14:27 |
| persia | (or rather, immediately post-install) | 14:27 |
| lool | persia: Orthogonal to squashfs installation | 14:27 |
| persia | Not leaving a mess seems more technically correct to me anyway. | 14:27 |
| persia | lool: Remember that the filesystem as viewed from the installer is not the same as the filesystem as viewed from the installed system (or oughtn't be). | 14:28 |
| lool | To me it just sound like in both the squash and non-squash cases you need to record the initial state of the system in the less space possible to allow restoring to this factory state | 14:28 |
| persia | To do this, we either need to double-layer the installer image, or fake deletion on the target device. | 14:28 |
| persia | In the non-squash case, there is no "reset" option available. | 14:28 |
| persia | Anything more complicated than wiping /cow isn't worth doing. | 14:29 |
| lool | persia: Sure, so we have state A: booted live system for installation, state B: initially installed system, state C: current system, and you want a way to reset from C to B; this is orthogonal to whether B and C are squashfs based or not | 14:29 |
| persia | lool: No. | 14:29 |
| lool | Just like the way state A is implemented, except that if it's not squashfs based, it's hard to generate | 14:29 |
| persia | In the squashfs case, you should be able to get from C to B by clearing the overlay. In the non-squashfs case, you need to somehow track initial system state. | 14:30 |
| lool | I disagree | 14:30 |
| lool | You make up that requirement | 14:30 |
| lool | There's no reason you need to implement restore to factory by clearing the overlay | 14:30 |
| persia | lool: You'd rather that the initially installed system in the squashfs case required addition information to be in place in the overlay to work cleanly? | 14:30 |
| lool | You can have a double overlay and you lose no space | 14:31 |
| lool | That is, install squashfs read-only on partition 1, setup an overlay for state B in partition 2, and setup partition 3 as user overlay | 14:31 |
| persia | OK. Do you agree or disagree with the statement that the initially installed system should have only that information that is required to be installed. | 14:31 |
| lool | You can clear partition 3 to restore to factory | 14:32 |
| lool | I don't understand your question | 14:32 |
| persia | Right. | 14:32 |
| persia | OK. My contention is that in the squashfs case, the initial overlay should be compeltely empty. | 14:32 |
| lool | I don't think you need that requirement | 14:32 |
| persia | Maybe not, but is it better to have it be non-empty? | 14:33 |
| lool | It's desirable that it be small, but it wont be empty unless the squashfs is what gets used initially | 14:33 |
| persia | So, we make the squashfs be what gets used initially, no? | 14:33 |
| lool | I think generating the squashfs is out of the question, and having zero customization would mean creating one CD per install | 14:33 |
| lool | Well we should make it as close as possible (by excluding ubiquity for instance), but we wont ever make it exactly what gets installed unless there are no installation options | 14:34 |
| persia | Well, there's oem-config... | 14:34 |
| lool | Typically, I don't see how you'll manage to not install the langpack in some target overlay, unless you have on squashfs for language | 14:35 |
| persia | True. I don't imagine any sane end-users will ever use the squashfs option. I'm only bothering to consider it because ogra wants it for cmpc stuff. | 14:35 |
| lool | Well it's an interesting option for devices with little disk space | 14:36 |
| lool | I find it challenging to support, and hence interesting | 14:36 |
| ogra | i dont want to see any cmpc ever again | 14:36 |
| persia | As a result, I don't mind only having one langpack, as from an OEM perspective, devices should be pre-installed with the language for the target market. | 14:36 |
| lool | ogra: haha | 14:36 |
| ogra | what makes you think i would want it for cmcp :) | 14:36 |
| ogra | but i am sure yu will still find devices with 2G disks out there | 14:36 |
| persia | ogra: OK. You pointed out that things like cmpc needed it. Perhaps "want" is too strong a word. | 14:37 |
| lool | ogra: http://images.google.fr/images?q=classmate+pc | 14:37 |
| ogra | *like* :) | 14:37 |
| persia | (don't click that) | 14:37 |
| lool | It's work safe I promess! | 14:37 |
| ogra | heh | 14:37 |
| ogra | MY EYES ! | 14:37 |
| persia | you clicked, didn't you. | 14:37 |
| lool | Before building a squashfs aware installer, we should find some cmpc-protection goggles for ogra | 14:38 |
| persia | Right, which is why the plan is to first finish the non-squashfs aware installer, and then look at the possibility of having one. | 14:38 |
| lool | persia: That's a reasonable way of ordering your priorities if you ask me | 14:39 |
| ogra | persia, i couldnt resist :) | 14:39 |
| persia | lool: Mind you, I won't complain if other things get in the way of a squashfs installer, but if one is done, I think it ought be optimised for the OEM case, as I feel very strongly that the price of disks and flash is low enough that most end-users would prefer a larger device if available, especially the class of end-users that would install an alternate OS. | 14:40 |
| persia | (and larger devices *are* available: lots of 10G stuff out now, and 20 is becoming less uncommon) | 14:40 |
| lool | persia: That's a sensible way to present it; however you need to consider the possibility of preinstalling Ubuntu on the devices too | 14:41 |
| lool | Typically, our USG team might have interest in such support | 14:41 |
| persia | For flash devices, it's still 4/8/16/32 (and mostly 4/8), but those are still 4. | 14:41 |
| persia | lool: Sure. The USG team would be an example of a target audience who would need an OEM-optimised installer. | 14:41 |
| * ogra likes to note *again* that the squashfs installer exists already as cmpcinstaller ... its work of one afternoon to rip out the cmpc cpecifics there ... its not gtk based but if we need t it can be used worst case | 14:41 | |
| persia | For the >4G case, it's more interesting to look at the ways that e.g. System76 or Dell do installs. | 14:42 |
| persia | ogra: There's MIC too, so using the cmpc installer isn't *worst* case. | 14:42 |
| ogra | heh | 14:43 |
| lool | Hmm we'll need some MIC goggles too | 14:43 |
| * persia has arranged for a special MIC visor, and is willing to be responsible for all the necessary looking at it whilst trying to make it less likely to be used. | 14:44 | |
| persia | Anyway, I need to prep for my next meeting. Any last minute questions about the ideas for squashfs installers? | 14:45 |
| persia | (or catch me another day) | 14:45 |
| lool | persia: I think we covered the side questions | 14:47 |
| lool | persia: Thanks! | 14:47 |
| persia | lool: Happy to share: it's been something I've thought a lot about, but don't have much code for, so can't just reference something. | 14:48 |
| ogra | go coding ! | 14:49 |
| ogra | :) | 14:49 |
| === asac_ is now known as asac | ||
| === cprov is now known as cprov-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!