[10:49] <hrw> flash-kernel should die in pain
[10:59] <steev_> +1
[11:04] <ogra_> hrw, it already did, you are dealing with its dead corpse atm :) ... (there is a rewrite from lool that didnt make it into debian or ubuntu yet)
[11:12] <steev_> rewrite or refactor
[11:14] <hrw> one day I will get pissed enough and will write own tool
[11:15] <hrw> on mx53loco it does not takes care of boot.scr
[11:40] <zumbi> ogra_: the thing in experimental? are you syncing it in ubuntu anytime soon/
[11:41] <ogra_> not for precise, no
[11:41] <zumbi> for precise+1?
[11:41] <ogra_> we would like to but dont have the resources to fix each and every isssue
[11:42] <zumbi> ogra_: I would be happy if debian and ubuntu will sync f-k
[11:42] <ogra_> and there is a prob with the handling of the kernel cmdline .... all ubuntu images use root=UUID=*, it doesnt support that at all yet
[11:43] <ogra_> since there is a weird mechanism to have an initrd script for finding the rootfs partition ... we cant use that since we are working towards an (optional) initrdless boot
[11:43] <zumbi> ogra_: file a BR ? :)
[11:43] <ogra_> well, i would rather just like to submit a patch that fixes it ... but that requires that i have the time to actually look into it ...
[11:44] <ogra_> and due to the changes in ubuntu land (ubuntu-arm was dropped to make the actual ubuntu teams care more for arm stuff and not just dump their stuff on other teams) i'll be busy until release
[11:47] <zumbi> ogra_: ok, thanks, just syncing f-k would be nice
[11:47] <ogra_> i doubt a BR would help much here, simply because there is a conceptional difference between debian and ubuntu in this space ... it would be an ubuntu only thing, debian doesnt plan for initrd-less boots i think
[11:48] <ogra_> we cant sync the one in experimental yet ... have to looked at the diff ubuntu vs debian has in the *current* code ? there is tons of stuff to be proted
[11:48] <ogra_> *ported
[11:48] <zumbi> no, it does not, but it's nice to have initrd-less boots
[11:49] <ogra_> once we have time for that (i.e. beginning of P+1) we will look into it
[12:39] <steev_> starting from an ubuntu-core tarball, what's the proper way to add a normal user to the system?
[12:54] <NekoXP> steev_, useradd right?
[12:54] <steev_> NekoXP: i know how to useradd, i just want to add one "properly"
[12:55] <steev_> ala the way oem-config does it, guess i can look through oem-config's code
[13:26] <NekoXP> it uses useradd :)
[13:31] <steev_> yeah i guess that's the smartest move, i was considering just using oem-config itself but holy hell it wants 221MB on top of ubuntu-desktop, which seems retardedly stupid for some reason
[13:33] <steev_> not sure why oem-config-gtk would pull in kde but hey, who am i
[13:37] <ogra_> steev_, adduser (never use useradd manually)
[13:41] <ogra_> steev_, also, oem-config autoremoves itself and all its deps once it ran so these 200M are moot
[13:45] <steev_> ogra_: just find it odd that oem-config-gtk would require installing 200M (mootly) just to uninstall it a few minutes later
[13:46] <ogra_> well, there might be a bug, not sure
[13:46] <ogra_> it needs all tools for all possible config options though
[13:46] <ogra_> i.e. encryptions bits ... -gtk needs X indeed etc
[13:47] <ogra_> it sums up
[13:47] <ogra_> i would also not recommend using -gtk for minimal images, there is also a -debconf frontend
[13:48] <NekoXP> ogra_, okay you're right, adduser (but that calls useradd, and useradd exists on BSD so I picked that :)
[13:48] <steev_> ogra_: debconf was broken in maverick
[13:48] <steev_> so i've tried to avoid it
[13:48] <NekoXP> noooo.. it worked, we just avoided it because it wasn't the best solution
[13:48] <ogra_> maverick ? ... well, ubuntu-core was nonexistant in maverick :P
[13:48] <steev_> NekoXP: no, it didn't work properly
[13:49] <NekoXP> also having -debconf run was great but it didn't run on a serial console properly at all
[13:49] <ogra_> it runs by default on the preinstalled server images since natty iirc
[13:49] <NekoXP> steev_, I ran it tons of times, I even considered using it... the idea was ship a headless system with it but it never panned out because it refused to output on a serial console
[13:50] <steev_> NekoXP: i used it on a natty install and it utterly failed (that natty sdcard i used to have), i had to go with -gtk then
[13:50] <ogra_> all preinstalled server images default to a headless serial install ... so that issue is fixed since several releases
[13:50] <NekoXP> yeah it has been
[13:50] <steev_> if it's been fixed, then i'll give it a shot
[14:04] <NekoXP> steev_, in fact -debconf is the only backend that really works 'cos the gtk ones don't stop oem-configing when you're done :D
[14:35] <NekoXP> ugh this is just taking far too long
[14:42] <steev_> ogra_: mmm, shouldn't oem-config-gtk start before lightdm?
[14:42] <steev_> lightdm is starting and all i have is guest session, not exactly what i'm after.  adduser route it is
[14:48] <ogra_> steev_, you need to enable it before booting
[14:48] <ogra_> touch /var/run/oem-config iirc
[14:58] <steev_> ah whoops, forgot that step
[15:04] <steev_> ah, because /var/run is now a symlink to /run which doesn't exist
[15:06] <ogra_> well, i remembered wrongly ...
[15:06] <ogra_> it is /var/lib/oem-config/run
[15:06] <ogra_> (see the upstart script)
[15:06] <NekoXP> steev_, see the maverick installed oem-install script, it enables it before it unmounts the target
[15:07] <steev_> yeah, i remembered after i tried that stuff
[15:09] <ogra_> GrueMaster, could you attach a syslog of a failed preseed install to bug 924018 ?
[15:09] <ubot2`> Launchpad bug 924018 in ubiquity "Preseeding doesn't work with oem-config" [Medium,Confirmed] https://launchpad.net/bugs/924018
[15:15] <Person987> Hi all, I have a pandaboard where I've installed the "power button" hack on pins 12 and 8.  Connecting the two does make the pandaboard shut down and start up.  My question is, does it do a "safe" shutdown or is it basically like cutting power?
[15:15] <Person987> (using Ubuntu on the PandaBoard)
[15:33] <ogra_> Person987, probably ask in #pandaboard, we rarely do HW hacks in ubuntu :)
[15:36] <ppisati> GrueMaster: for when you are awake - http://people.canonical.com/~ppisati/lp861296/linux-image-2.6.35-903-omap4_2.6.35-903.31~3g1gsplit_armel.deb
[15:37] <ppisati> GrueMaster: M/omap4 that should fix the mmap() issue, please try it out
[15:40] <steev_> ogra_: it left ~70mb on the system; not horrible, but still a minor annoyance  i can live with it though, since i was just messing about
[15:41] <ogra_> that was with ubuntu-core as a base ?
[15:41] <steev_> yeah, ubuntu-core, then ubuntu-desktop were installed
[15:41] <ogra_> right
[15:42] <ogra_> not sure if you can call that a bug, oem-config was definitely never designed for something as weird as ubuntu-core :)
[15:42] <steev_> lots of libakonadi stuff, whatever that is
[15:42] <ogra_> kde libs
[15:42] <ogra_> intresting that you got them at all when you only installed oem-config-gtk
[15:43] <ogra_> (or oem-config-debconf fwiw)
[15:44] <steev_> well something oem-config-gtk deps on deps on something in the kde camp
[15:44] <ogra_> it shouldnt, it should only install the kde bits if you install i.e. the toplevel metapackage like oem-config
[15:44] <ogra_> if you explicitly just install -gtk or -debconf, nothing from kde should get pulled in
[15:46] <steev_> i'd say i wish i had done this on a faster sdcard, but that's one of my class 10s, so i wish i had done this on the ssd
[16:02] <steev_> ogra_: http://www.steev.net/files/oem-config-gtk.png
[16:07] <GrueMaster> steev_: Try "apt-get install oem-config-gtk ubiquity-frontend-gtk".  That should fix the dependency issue.  The problem is oem-config-gtk depends on ubiquity and ubiquity will pull in all frontends unless specified.
[16:08] <ogra_> oh, right
[16:08] <NekoXP> that's true
[16:08] <ogra_> i had thought about --no-install-recommends :)
[16:08] <ogra_> but GrueMaster's guess is the better one
[16:09] <steev_> of curiosity, why wouldn't you depend on ubiquity-frontend-gtk instead of ubiquity?
[16:09] <NekoXP> because ubiquity is the core installer
[16:09] <NekoXP> the frontend part is just the bit that shows the gui components
[16:10] <NekoXP> what it should do is oem-config-gtk depends on ubiquity-frontend-gtk which depends on ubiquity but ubiquity should NOT depend on frontends
[16:10] <NekoXP> that's the cause of the problem here right?
[16:17] <GrueMaster> ppisati: Test kernel for lp:861296 passed.