=== Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === zz_chihchun is now known as chihchun === chihchun is now known as zz_chihchun [08:07] so I boot ubuntu-12.04 on my pandaboard [08:07] and it gets to X, but I don't seem to have any sort of a window manager running [08:07] I can right click on the desktop to get a small context menu [08:07] but no more menus. [08:10] ok, if I run gnome-terminal from ssh, that seems to work [08:10] I guess it is just the launcher that is broken/not running. [08:11] <[mbm]> what session are you trying to use? if you're running a *dm you can set the session on the login screen [08:15] the default one. [08:15] I also set it up to not have a login screen, evidently? [08:16] what is the default these days, unity? [08:32] <[mbm]> lightdm [08:37] ps says lightdm is in fact running. === doko_ is now known as doko [09:57] I see (in backlog) that so far we do not got chromebook users here [09:57] hrw, waiting for mine :) [09:58] ogra_: you still use ac100? [09:58] sure [09:59] i didnt use it much at UDS but always had it with me [09:59] i doubt the chromebook will change that, lets see [11:19] janimo, did you upload the kernel to raring yet ? [11:19] * ogra_ doesnt see it in any queue [11:23] ogra_, not yet [11:24] I wonder if I should keep both quantal and raring branches in git [11:25] well, essentially the difference should just be in the changelog entry [11:25] i.e. the distro name [11:26] http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM4330 [11:26] oh, wow [11:27] i didnt know our wlan chip also has an FM radio builtin [11:27] i noticed that NM offers WIMAX .... [11:29] <[mbm]> hmm never thought of chromebook; figured they would be locked down and only run chromeos [11:29] janimo: Better to keep both branches, in case there is a reason to folk based on SRU vs. development release in the future. [11:29] i think they already offer an ubuntu image [11:30] persia, there wont be SRUs [11:30] I heard they took extra effort to make it easy to replace the OS in the Chromebook [11:30] as soon as we have working raring images we'll mainly care for raring only [11:30] ogra_: Why not? [11:30] ogra_: You will. Maybe someone else cares. It's not like an extra git branch is that much overhead. [11:30] and will ask people to either upgrade or do a fresh install off an "alpha" [11:31] <[mbm]> I remember there was a pc bios for the early chromebooks, just haven't heard anything about the latest [11:31] (and if apw's new system for universe kernel management happens, it would be nice to be prepared to match it) [11:31] persia, for only a handfull of chars difference ? [11:31] i think it is :) [11:31] its really only the distro name in the changelog entry that should differ [11:31] It is? I find it more work to *delete* a branch than leave it there, if there are no changes for it. [11:31] uploads should go simultaneously to both places [11:32] until we abandon one of them [11:33] * persia grumbles about policies and compliance and best practices and bows to the inevitable pragmatism that comes when folk believe they have limited developer resources [11:33] but currently even an empty package in raring would help me, starting images is blocked on missing a kernel atm [11:33] haha [11:33] Why didn't the quantal kernel get copied over when raring opened? [11:33] because it doesnt exist in quantal [11:34] Ah. That's a good reason. It's so good that I don't care if there's a quantal branch anymore. [11:34] we started working on that three weeks before release [11:34] and the release team had better stuff to do than reviewing new kernels at that time [11:35] So, in fact, there *shouldn't* be any SRUs: just raring backports. [11:35] just PPA uploads in fact [11:35] Why not backports? [11:35] well, if someone from the backports team wants to care [11:36] the 12.10 image is largely a throw away thing [11:36] its heavily hacked in many places and should only serve as a demo [11:36] the "real thing" will be the raring image [11:37] ogra_: As I understand it, arranging a backport consists of running `requestbackport packagename` and confirming the test result. But if the image itself is hacked, rather than just the kernel, yeah, nobody should run quantal. [11:38] the image has -updates,-security and -backports enabled anyway and we dont encourage people to enable them [11:38] in fact it will break your desktop since yesterday [11:38] For a demo, that's probably best. [11:39] I'll stop heckling for now, as the answer to everything will be the same :) [11:39] (since there is a new unity that overrides our version in the PPA and no intend to update the PPA package) === Sv is now known as sv [11:58] persia, do i read that right that this license allows redistribution as long as nobody sues broadcom because we distributed it ? https://android.googlesource.com/platform/hardware/broadcom/wlan/+/43362466e68ebaed8b7ca5eaf5c9cede8b7a0f57/bcmdhd/firmware/LICENSE.TXT [11:59] janimo, ^^^ that sounds like we could use it legally [11:59] to me at least [11:59] ogra_, pftt, but I wanted to sue Broadcom! [11:59] haha [11:59] ogra_, I will wait till kernel-team/legal whoever gives a verdict :) [12:00] yeah, i added a ling to it to the bug [12:00] *link [12:00] * janimo installs bash-completion on the nexus7 [12:02] brave ! [12:06] ogra_: I don't read it quite that way. [12:06] :( [12:07] 2.3(b) makes me think that it's unsuitable for mirroring [12:07] Check with the mirrors team, but I suspect it needs to be distributed a different way. [12:08] sigh [12:08] Because mirrors distribute Ubuntu under the assumption that they accept no liability in doing so. [12:08] well, i wonder if thats true for all the closed bits we have [12:08] The above does not represent legal advice: if actually intending to distribute this software, confer with your own counsel and counsel for any organisations providing hosting services [12:09] I don't propose to do an audit :) [12:09] * persia gets in enough trouble for reading licenses already [12:10] The provision in 3.2 to promptly report all bugs fails the desert-island test for DFSG too, although the word "reasonable" might be sufficient to make it pass. [12:11] well, i doubt linux-firmware is anywhere close to DFSG anywaqy [12:11] I do like the wording of 3.3 though: it doesn't actually discriminate against field of endeavour, but not for lack of trying :) [12:12] I did review chunks of linux-firmware at some point in the past, and most of it was only modification-restricted. [12:12] I didn't review all of it, and this was enough years ago that much has probably changed, so you could be right today. [12:13] i think it had a real audit at some point [12:13] beyond developers [12:13] Mind you, modification-restriction makes it non-DFSG-free, but the rest of the tests pass. [12:13] heh [12:14] its hard to modify binary blobs anyway [12:14] The question to ask when being told that is "on whose behalf"? The license you showed me is likely suitable for Canonical to distribute it if Canonical wants, but may not be acceptable to some mirrors. [12:14] Um, no. That'S why xxd is shipped by default. [12:16] Anyway, I have a warm bed I wish to use. Ask an archive admin for an official Ubuntu opinion, or ask the mirrors team for a hint if you don't want to bother the archive admins yet. [12:16] yeah, i asked at the bug, lets see what the kernel team thinks [12:16] sleep well ! === satellit_ is now known as satellit_e [12:41] janimo, so rtg asks us to not ship it in linux-firmware at all but in our kernel package [12:41] (there was just a discussion on #ubuntu-kernel) [12:41] ogra_, ok. But that has little to do with legality to distribute right? [12:42] right, just with "pfft its a special device, come back if more people use it" [12:42] or something along these lines [12:43] apparently linux-firmware is mostly generated by looking at the mainline kernel and checking for MODULE_FIRMWARE() calls [12:43] if ours does show up there at some point it will be auto-included [12:43] (or at least attempted to) [12:44] ogra_, I thought this broadcom chip combo was also in quite a few x86 machines [12:44] i thought so too [12:45] and theoretically http://linuxwireless.org/en/users/Drivers/brcm80211 should actually work for us [12:45] (the SDIO driver) [12:45] but anyway, we can include it in the kernel [12:45] ogra_, is that in 3.1? [12:45] practically i didnt get it to work, though that might be totally my fault [12:45] having a newer kernel would help in many regards I think [12:45] janimo, in staging iirc === yofel_ is now known as yofel [14:04] janimo, btw, i think our kernel really has a math problem, most numbers i see seems to be doubled up ... i.e. these 600M ram used in hatp, or the charging time in upower -d output [14:04] *htop [14:06] ogra_, where can you see the alternate/real numbers? [14:14] does anyone running Android on nexus7 see ambient light having any effect on screen brightness? I keep changing the light or even covering what I think is the sensor aperture but nothing changes [14:25] janimo: I'll ask our team, I think a few have personal devices [14:30] carif: janimo has some questions about the ambient light sensor in Android [14:30] janimo: carif is still running Android [14:32] mfisch, janimo, pl walk me through the test you want? Shine some light on tne n7 and see if it changes brightness? [14:32] carif, well I have no idea what it would take for it to change brightness. That's the issue I see, I don't see a difference in brightness even if it is set to automatic [14:34] janimo, i have the brightness setting to be automatic and about midway for the slider [14:34] carif, I can adjust it manually if automatic is not on though [14:34] janimo, very good, so you're asking the question what changes the brightness when automatic is actually set? [14:35] carif, yes [14:35] my experiment in covering the sensor or shining a lamp on the tablet do not seem to have an effect [14:35] or if there is one it is unnoticable [14:37] janimo, i confirm your experiment, i don't know what makes the brightness change however [14:37] carif, ok thank for the confirmation [14:37] I'll check on another android device too later [14:40] janimo, no idea, but i simply cant belive we eat over 600M nor are the estimated hours for charging (18h in the beginning, after 4 it dropped to 9h) in upower -d right [14:41] to me everything seems doubled up [14:41] ogra_, so maybe bugs in battery level reporting and memeory measurements are known to not be very accurate :) [14:42] i also see a constant load of 2.xx [14:42] but nothing that produces it [14:42] and iirc marvin24 once added as fix for to high load reporting to the ac100 tree [14:42] (or nvidia did and he merged it) [14:44] ogra_, never heard of this before. If it happened in ac100 then hopefully we can fix it too [14:51] janimo, bug 985661 [14:51] Launchpad bug 985661 in linux (Ubuntu) "High load average" [Medium,Triaged] https://launchpad.net/bugs/985661 [14:51] I can confirm that following commit is responsible: "sched: Fix nohz load accounting" [14:51] SHA: 3a50863f6706ece7719a68be0ae57957164a0f0c [14:52] (comment #35) [14:52] though that claims the breakage was originally added in a 3.2 kernel [14:53] ogra_, I think our 3.1 tree has backports of several commits [14:53] http://thread.gmane.org/gmane.linux.kernel/1310462 [15:04] * marvin24 can't remember fixing something like this [15:08] well, i think it might just have been mentioned in #ac100 [15:08] or i saw it in a erge in the changelog osr so [15:11] xnox, the resultimg images from the tools look good, i havent flashed one yet but what the tools produce seems to definitely be fine [15:13] -rw-rw-r-- 1 ogra ogra 1,7M Nov 7 16:13 test2.img [15:13] -rw-rw-r-- 1 ogra ogra 6,0G Nov 7 16:12 test.img [15:13] test2 is the sparse one (both are empty) [15:14] hmm, producing the saem with ext2simg instead of using img2simg gets it even smaller [15:14] err, no, bigger [15:14] misread [15:29] ogra_: I'd like to add an autopkgtest for it. Does the test_* utility do anything useful? [15:29] no idea [15:29] ogra_: does it simply need an ext4 image - which can be created on the fly? [15:29] ack [15:29] ogra@anubis:~/Desktop/nexus/builder/tmp$ test_ext4fixup -3 5 rootfs_test.img [15:29] error: ext4_parse_sb: superblock magic incorrect [15:29] test_ext4fixup: ext4fixup failed!\n [15:30] hmm... [15:31] well, that one was built with img2simg [15:31] likely not the right tool for ext4 images if there is edxt2simg ;) [15:32] xnox, so, hmm ... it even fails with an image properly created using make_ext4fs [15:35] interesting so what does test_* thingy suppose to do then? =P [15:35] heh, i wonder that too [15:35] i like that it so nicely adds a \n :) [15:37] in any case the image size isnt acceptable that i get with ext2simg === chihchun is now known as zz_chihchun [15:45] hey guys [15:45] yo ! [15:46] dholbach, welcome to ARM :) [15:46] hello ARM hippies :) [15:46] This channel sure has gotten busier since UDS. :P [15:46] heh, yeah [15:47] infinity, we lost Grue though [15:47] he went away grumpy yesterday [15:48] bugs 297368 and 1049935 are tagged 'mobile' but are not nexus7 related - do you think it'd make more sense to use a more specific tag than 'mobile'? [15:48] Launchpad bug 1049935 in modemmanager (Ubuntu) "Crash on connecting Sierra Wireless mobile hotspot" [Low,Incomplete] https://launchpad.net/bugs/1049935 [15:48] Launchpad bug 297368 in gnome-phone-manager (Ubuntu) "Sony-Ericsson W910i Not Supported in USB Mode" [Undecided,New] https://launchpad.net/bugs/297368 [15:48] I was just reviewing the bug filing instructions on https://wiki.ubuntu.com/Nexus7 [15:49] achiang, ^^^ [15:49] dholbach, I think it should be up to you, you know best practices better and what makes sense globally for ubuntu [15:49] is someone regularly triaging https://bugs.launchpad.net/ubuntu/+bugs?field.tag=mobile and adding the ubuntu-nexus7 task? [15:49] mobile was the initial tag but it may have been misused at times [15:49] dholbach, these tags are most likely 4 years old or older from the original ubuntu-mobile team [15:49] I don't care too much :) [15:49] I was just wondering when I went through the list [15:49] we used to use that tag before we got renamed to -arm [15:50] luckily enough it's just 2 out of 12 bugs [15:50] they should all be invalidated actually [15:50] so theoretically we could just leave things as they are and untag the two I mentioned [15:50] ++ [15:50] ok, WFM [15:51] dholbach: as for triaging, we do triage bugs, but mostly in the ubuntu-nexus7 project. [15:51] we could start triaging that tag though [15:52] maybe running a script which spits out a list of bugs which are 1) against Ubuntu with tag 'mobile' and 2) not in the ubuntu-nexus7 project might help [15:52] just so we don't overlook bugs filed by testers [15:59] achiang, well, i thought the idea was to have the tag in raring through apport/ubuntu-bug [15:59] right [16:00] ubuntu-bug [16:00] who is signed up for that WI? :) [16:00] so future bugs will definitely carry it [16:00] might be me [16:00] still wading through WIs this week :) [16:01] achiang, though we should probably reconsider the choice of "mobile", we might come across some old LPIA cruft :) [16:01] ogra_: i don't think i suggested it... ;) [16:01] * achiang twitches re: lpia [16:02] someone suggested it in the discussion [16:02] cant remember who that was [16:02] is anyone interested in a way to see the 'top' entry for a specific binary? [16:06] surely you'd get that from "ps aux | grep name" [16:07] or some variant [16:12] NexoXP - well yeah, exactly. but it's nowhere near that short [16:13] NekoXP, problem is top only accepts PIDs to filter the list [16:13] top -p `ps aux | grep $1 | head -n1 | awk '{print $2}'` [16:14] point taken [16:14] infinity, debuild creates a new orig.tar.gz by default if there is no orig. Can it be told to use one of the other compression methods [16:14] brendand, pgrep ? :) [16:14] infinity, I just debuild out of the git tree with no orig at all so far [16:15] janimo: Erm, if there's no orig, it builds natively. But yes, I'm pretty sure you can tell it to compress the native package differently in debian/source/options [16:15] infinity, thank. I'll check that out [16:15] janimo: (Only if using a v3 source format, I suspect) [16:15] infinity, yes just switched linux-nexus7 to 3.0 to see how it works [16:15] and tought of taking advantage of alternate compressions [16:15] janimo: did you look into the "Dim screen to save power" bug also or just the ambient light bug [16:16] mjust the ambient one as I have a WI to enable the get the light sensor in the kernel working [16:18] ok [16:26] " Your Amazon.co.uk order of "Samsung Chromebook Wifi (L..." has been dispatched" [16:26] \o/ [16:28] wow [16:49] ogra_: ping re: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1065644 - do we have a theory that it is an nvidia driver problem or a plymouth problem? [16:49] Launchpad bug 1065644 in ubuntu-nexus7 "plymouth causes a hard reset of the nexus" [Critical,Confirmed] [16:50] achiang, well all i know is that nvidia recommends to remove plymouth completely because it breaks your system [16:50] we dont really know which side of the fence is at fault, but i have a WI somewhere to research that [16:50] ogra_: hm, so known issue for them [16:50] right [16:51] its prominently in their usage docs on developer.nvidia.com [16:51] (for tegra2/3) [16:52] achiang, i'll do some debugging and add inof to the bug once i'm through the image build stuff [16:52] *info [16:53] ogra_: np, just going through some of my WIs [16:53] right, i did the same today :) [16:53] ogra_: btw, how do you find your WIs? /me has never really used blueprints before [16:54] you can check the blueprints you are involved in on your presonal LP page [16:54] ok, i've done that [16:54] what i personally do though is to just take my personal schedule on summit.u.c [16:54] but i have to go through the blueprints and then troll for WIs? [16:54] and go through the sessions i attended [16:54] there's no way to automatically see my WIs? [16:54] ojnce your WIs are proper and the specs are approved you can use status.ubuntu.com though [16:55] ah [16:55] its just inconvenient during the approval phase [16:55] later it gets easy [16:55] hm, i don't appear here - http://status.ubuntu.com/ubuntu-raring/people.html [16:56] your team isnt on there i guess [16:56] achiang: do you have workitems on blueprints that are "accepted for raring" in the series goal? [16:57] ah, i was looking at this one -- https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-tablet-desktop-convergence-divergence which does not have it [16:57] right, it might needs at least one WI in an approved spec for even generating a report [16:57] ok [16:58] http://status.ubuntu.com/ubuntu-raring/u/ogra.html definitely has something for me already [16:58] unrelated question: if we're not going to have alphas, when do we expect to start generating dailies? :) [16:59] ah, no, it doesnt need to be approved, needs to be "accepted for raring" i think [16:59] achiang, asap [16:59] I see x86 already has dailies so we should too. ogra is probably waiting for my kernel upload :) [16:59] achiang, i would like to get going this week but fiurst need a kernel package ... that takes a bit [16:59] achiang: we have dailies. and we are meant to have a fully working set every two weeks. [16:59] ogra_: ok, thanks [16:59] re firmware I still want to know whether we can ship it [17:00] janimo, well, for more than that ... [17:00] I mean we were told by rtg not to put it in linux-firmware [17:00] but yeah, kernel is one blocker [17:00] achiang: so we don't have alphas just many more littlealphas [17:00] but that does not mean we can put it anywhere for that matter [17:00] janimo: we are meant to have a bi-weekly testing senergy on a known set. [17:01] janimo, well, i think the other fw i found in the generic android wlan tree has a looser licence [17:01] we might be able to ship that, someone has to test if it actually works though :) [17:01] xnox: ogra_: which blueprint talks about installer support in ubiquity? [17:01] it claims to be for 4330 [17:02] achiang: huh? ubiquity is the installer.... [17:02] achiang, https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-ubiquity [17:02] achiang: or are you after usb-creator? [17:02] xnox: sorry, me english no good, but ogra_ figured out what i was asking ;) [17:02] xnox, i bet he meant nexus :) [17:02] ack. [17:02] achiang, thats for oem-config though [17:03] https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-usb-creator-fastboot-support [17:03] is the installation/flashing [17:03] ogra_: ah, ok. i'm just trying to close out as WONTFIX - https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072681 [17:03] Launchpad bug 1072681 in ubuntu-nexus7 "ubuntu-nexus7-installer should have some logging" [Medium,Confirmed] [17:03] heh [17:04] achiang, i commented [17:04] brendand surely has a point there ... and its easy to add logging to the traball extraction [17:05] ogra_: no, he was talking about our zenity installer, not tarball-installer [17:05] ah [17:05] well, usb-creator does logging already i think [17:05] ogra_: brendand ran into issues with our zenity installer at UDS, but eventually got it working [17:05] so does oem-config [17:05] but the tarball installer should surely get some [17:05] ogra_: right, and we won't invest anymore time into the zentiy installer [17:06] ogra_: sure, file a new bug then. :) [17:06] k, just close that one then [17:06] already done, we spent another 5m talking about it. ;) [17:06] i wont file a bug, i'll just implement it with the first upload :) [17:06] oh come on ... you manager you [17:06] :P [17:07] :) [17:12] does charging the nexus take extremely long for anyone else or is it just me ? [17:13] ogra_: yes, but it's quicker if you use "official" cable & plug. [17:13] probably these 18h it showed me initially were actually correct ... it definitely hangs on the charger since i started my workday [17:13] xnox, i do [17:13] its at 41% [17:13] hmm =/ [17:13] after a fukll workday [17:14] also I found that the connectors on the nexus are not that good. E.g. the headphones fall-out and the charger disconnects often. [17:14] ubuntu@nexus7-roccos:~$ upower -d|grep state [17:14] state: fully-charged [17:14] ubuntu@nexus7-roccos:~$ upower -d|grep percentage [17:14] percentage: 41.4464% [17:14] ubuntu@nexus7-roccos:~ [17:15] OH ! [17:15] janimo, there is something wrong here [17:15] so I have a weird question, has anyone ever seen any sd cards that actually support trim or secure trim or is this just one standard that got stuck on eMMC? [17:15] * ogra_ guesses thats ckings work [17:18] ogra_, mine is not fully charged but either charging or discharging depending on whether the cable is plugged in or not [17:18] ogra_, but probably a bug indeed [17:18] janimo, well, if you keep the cable plugged it should at some point go to 100% [17:18] sure [17:18] in a few hours I guess [17:18] and not think it is fully charged and report 41% :) [17:19] 6.0 according to upower [17:19] and i'm pretty sure after more than 8h charging it should be at 100% it surely was with the former kernel [17:20] i think chraging it to 100% never took me more than 2h actually [17:20] so i guess cking has to revisit it :) [17:20] any reason I should not use xc compression on the kernel package (besides compressing it being sloow) ? [17:20] infinity, ^ ? [17:20] bootspeed [17:21] oh, the package [17:21] ogra_, the source package [17:21] not vmlinuz [17:21] * ogra_ doesnt care [17:21] ogra_, I am not sure whether build servers can handle it, whether it is all stable etc [17:21] 60M vs 100M for the sourece tarball [17:21] well, someone has to try it anyway :) [17:22] i think we have some xz packages already though [17:22] and havent seen issues about it on arm [17:22] iirc xnox had a list in the xz packages session ;) [17:22] * ogra_ remembers some font package [17:25] heh, so my percentage jups back and forth between 41.4464% and 41.4364% [17:25] doesnt move beyond that [17:27] it's trying to converge to 42, of course [17:27] janimo: We have lots of xz source packages, infrastructure all deals with it fine. [17:27] well, if it wouldnt go down to .4364 all the time i would tend to belive that [17:28] janimo: It may take longer to decompress at build time, but meh. [17:29] ogra_, it does converge on 42 but due to miscalibration you see the values shifted a bit [17:30] well, i'm pretty sure it sits at 41.xxxx% since more than 1h ... and it thinks its fully charged, if the kernel thinks the same its very unlikely to ever go beyond [17:30] ogra_, having android dual boot now to see what it says would sure be handy [17:30] are there sys files that can be read, do they say the same thing? [17:31] you wont find uppower in android : [17:31] :) [17:31] /sys/devices/platform/tegra-i2c.4/i2c-4/4-0055/power_supply/battery/ [17:31] janimo: with source package - go ahead as much as you want =) [17:32] xnox, alright :) [17:32] janimo: ubiquity, libreoffice and emacs all do that ;-) [17:32] ah, I'm in good company then [17:32] libreoffice is hardly "good company". [17:32] my sarcasm key ain't working [17:33] janimo, i'm pretty sure it is caused by d017332e756ba9294679c453431bf39507fd176e in our tree [17:33] I thought that's what AltGr was for. [17:33] Alternative Grin, or something. [17:33] mine is remapped to Facebook Like [17:34] it wasnt like that in the -6 kernel [17:34] ogra_, that is cking's patch to fix reporting [17:34] janimo: Damnit, I nearly have a beverage->laptop incident, thanks. [17:34] so maybe it had side effects [17:34] janimo, right [17:34] s/have/had/ [17:34] infinity, I must try harder next time [17:34] janimo: If you want to buy me a new laptop, carry on trying. [17:34] janimo, wait until you two are in a hangout together so you can record it [17:34] ogra_: did you test flashing nexus7 with fs-utils now? [17:35] * xnox is pondering if it's safe to flash my own nexus using those =) [17:35] infinity, what model doth your heart desire? [17:35] xnox, no, and i want to back up my rootfs first ... soo many chganges i dont want to lose already [17:35] janimo: A T430s to replace my T420s wouldn't hurt my feelings. [17:35] i'll keep that bit for tomorrow [17:36] ogra_: interesting, how do I back it up? [17:36] with fast boot? [17:36] xnox, i think ext2simg is a no go, the image is around 100M bigger than with make_ext4fs [17:36] *sigh* [17:37] xnox, i do boot into the initrd with usb hub attached, on the hub i have kbs and usb key ... then i just dd /dev/mmcblk0p9 into an image file on the usb key [17:37] ogra_, maybe the mkfs part does things differently by not emulating what make_ext4fs does? [17:38] janimo, yeah, i think it compresses bits of the filesystem [17:38] *filesystem meta data [17:38] does things that e2fsutils cannot do? That would be strange, but I know too little about these tools [17:39] same here [17:39] ogra_: was slangasek suggesting some other way of creating sparse images? [17:39] but slangasek asked me to look into the possibility to only use ext2simg and stick to our existing sparse img creation we already have [17:39] at the closing plenery. [17:39] dd if=/dev/zero of=test.img bs=1M seek=6144 count=0 [17:40] mkfs.ext4 test.img [17:40] then i loop mount and cp the tarball into it [17:40] and then: ext2simg test.img rootfs_test.img [17:41] thats largely the way we discussed (and the way debian-cd and friends etc use) [17:41] ack. [17:44] ogra@anubis:~/Desktop/nexus/builder/tmp$ ls -lh rootfs_test.img [17:44]