[01:47] <cwillu_at_work> rcn-ee, do you know if there was any zippy changes pulled in on rc4 or rc5?  I'm getting null pointer dereferences on most network activity on the zippy's ethernet
[04:12] <rcn-ee> Hey cwillu_at_work i need to still rework the zippy patches that were in 2.6.34 they don't apply cleanly to 2.6.35 yet (and they fix a lot of problems)
[04:23] <cwillu_at_work> ah, k
[04:23] <cwillu_at_work> did .33 have working zippy2?
[04:32] <pcacjr_at_home> does anyone know if ubuntu lucid works properly on the beagleboard C3 ?
[04:33] <cwillu_at_work> pcacjr_at_home, as far as c3's work properly, yes
[04:33] <pcacjr_at_home> cwillu_at_work, thanks mate
[04:33] <cwillu_at_work> there's some remaining instability on the ehci port, although it can be managed
[04:33] <rsalveti> pcacjr_at_home: yep :-)
[04:33] <rsalveti> pcacjr_at_home: trying ubuntu now?
[04:33] <pcacjr_at_home> rsalveti, yeah :-)
[04:34] <cwillu_at_work> pssst, buddy, wanna try a btrfs root? :)
[04:34] <pcacjr_at_home> rsalveti, afaik you used to install ubuntu lucid on that beagle you gave me
[04:34] <pcacjr_at_home> rsalveti, right ?
[04:34] <rsalveti> pcacjr_at_home: yep
[04:35] <rsalveti> but that's not a c3, it's a b5 I believe
[04:35] <pcacjr_at_home> rsalveti, great. so i'll give it a shot!
[04:35] <pcacjr_at_home> thanks
[04:35] <pcacjr_at_home> hm
[04:35] <rsalveti> you can still try lucid, but will be very slow
[04:35] <rsalveti> recommend you to try without gui
[04:35] <pcacjr_at_home> ok then
[04:35] <pcacjr_at_home> ;-)
[04:36] <cwillu_at_work> the b's only had 128mb ram, right?
[04:36] <rsalveti> yep
[04:36] <rsalveti> and just the usb otg
[04:36] <pcacjr_at_home> so no GUI though
[04:36] <cwillu_at_work> it might be livable if you put swap on a usb disk
[04:37] <cwillu_at_work> with gui, I mean
[04:37] <pcacjr_at_home> cwillu_at_work, but it'll get slow though...
[04:37] <pcacjr_at_home> anyways i don't even need GUI ;-)
[04:37] <cwillu_at_work> pcacjr_at_home, it gets slow even with 256mb :p
[04:37] <pcacjr_at_home> D'oh
[04:37] <pcacjr_at_home> :-)
[04:37] <rsalveti> if you don't need gui, then that's ok
[04:37] <cwillu_at_work> depends entirely on your working set
[04:39] <pcacjr_at_home> i see
[04:39] <pcacjr_at_home> thanks folks
[07:57] <rsalveti> rcn-ee: just to let you know that I pushed some commits at rootstock, and this will probably break your script and patches
[07:57] <rsalveti> will look at other bugs tomorrow
[07:57] <rsalveti> time to get some sleep now
[08:20] <hrw> morning
[08:26] <lag> Morning hrw
[08:51] <lag> hrw: Do you remember the SD -110 error bug?
[08:52] <hrw> timeout
[08:53] <hrw> iirc
[08:55] <lag> Was there a bug raised?
[08:56] <hrw> I had that few years ago in Zaurus
[08:57] <hrw> and at that time it ended with problematic card sent to RMK for checking on his hardwares. patches landed in kernel, card started working
[09:01] <lag> I'm getting it on Beagle
[09:01] <lag> It was a problem a few weeks ago
[09:01] <lag> I think mpoirier was working on it
[09:01] <lag> ogra: Can you remember if there was a bug report raised?
[09:13] <lag> Found it: bug 591941
[09:13] <ubot2> Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 135)" [High,In progress] https://launchpad.net/bugs/591941
[10:10] <ogra> +  * Append ${SUBARCH:+-$SUBARCH} to LOG filename for consistency.
[10:10] <ogra> +
[10:10] <ogra> + -- Loïc Minier<EMAIL_ADDRESS>Wed, 02 Sep 2009 09:23:59 +0200
[10:10] <ogra> lool, did you ever check what happened after that change ? ^^^
[10:26] <cooloney> amitk: i am looking at tony's linux-omap tree, do you know which branch shall i take a look
[10:27] <cooloney> amitk: if i wanna cherry pick some patches to enable panda in our Ubuntu master tree -omap flavor
[10:27]  * ogra wonders why you want to do that
[10:28] <ogra> it will work only half i guess and we have a properly working omap4 kernel on the omap4 images
[10:29] <amitk> ogra: because I want a mainline-only version of omap4
[10:29] <amitk> ogra: and because that is the future
[10:29] <cooloney> ogra: i also wanna ask amitk that question.
[10:30] <ogra> amitk, but what do we gain from it beyond confusion ?
[10:30] <cooloney> amitk: i think we can build a pure mainline omap4 version for our panda boards.
[10:30] <ogra> you wont be able to run the -omap images on -omap4 HW
[10:30] <ogra> since the boorloaders differ
[10:30] <cooloney> amitk: oh, sorry, not mainline, tony's upstream kernel
[10:31] <ogra> and -omap4 images will always install the -omap4 kernel by default
[10:31] <amitk> ogra: bootloader issue will be fixed upstream
[10:31] <ogra> amitk, it cant
[10:31] <amitk> ogra: I don't plan to use your images
[10:31] <ogra> there are HW constraints you cant work around in SW
[10:31] <ogra> it will only start working if DT is fully integrated
[10:32] <hrw> multiomap kernels were omap2/3 only?
[10:32] <ogra> and i'm not even sure about that for pandas vs blaze
[10:32] <amitk> cooloney: Tony's for-next branch is usually the one (I see it has support for Panda)
[10:32] <amitk> hrw: no, multiomap is omap2,3,4
[10:32]  * ogra guesses omap4 support is very rudimentary
[10:33] <amitk> ogra: I am not sure what the reach problem is with supporting panda with the mainline kernel?
[10:33] <amitk> ogra: could you expand?
[10:33] <ogra> amitk, 700 patches ?
[10:33] <amitk> ogra: here is where you don't understand what I'm trying to do
[10:33] <ogra> amitk, i doubt all the changes and patches we have on the current omap4 tree are in tonys branch
[10:34] <ogra> so the omap4 support will suck in the -omap kernel
[10:34] <amitk> ogra: I DONT CARE ABOUT YOUR DESKTOP IMAGE WITH ITS BELLS AND WHISTLES :)
[10:34] <ogra> amitk, i understand that
[10:34] <hrw> amitk: working serial is enough ;D
[10:34] <amitk> ogra: DONT CARE from the POV of what I'm trying to achieve. I do care about it otherwise, great work :)
[10:34] <ogra> but i fail to see any benefit before omap4 is properly integrated in -omap
[10:35] <amitk> hrw: exactly
[10:35] <cooloney> ogra: amitk just wanna a Ubuntu M 2.6.35 kernel which can supports omap4 hw
[10:35] <ogra> amitk, what do you gain by that if you *only* have a serial console
[10:35] <ogra> like you dont have MMC, USB, NIC or any other HW support
[10:35] <cooloney> amitk: ok, i am looking at it
[10:36] <amitk> ogra: that is where you are wrong. Mainline already supports basic omap4 features (uart, i2c, mmc).
[10:36] <hrw> ogra: once you got omap4 usb you will have nic support
[10:36] <ogra> stragne since not even our omap4 tree properly supports many of these
[10:36] <amitk> ogra: It helps us with device tree work, as one example
[10:36] <ogra> ah
[10:36] <ogra> that was an answer i was looking for :)
[10:37] <ogra> *some* kind of near future benefit :)
[10:38] <amitk> ogra: for linaro purposes it doesn't have to work perfectly - that is what your omap4 image is for. Having a mainline-only version allows us to experiment
[10:39] <amitk> so any development happening against mainline won't have to be thrown away
[10:39] <ogra> amitk, right, i did see more benefit from merging the omap4 branch step by step, thats why i was wondering about having a second code path
[10:40] <hrw> amitk: and we need pandas to have HW for tests
[10:40] <ogra> hrw, arm team is happy to help
[10:41] <ogra> if xyou need any verification that costs us just a "play around SD card" :)
[10:41] <cooloney> amitk: just a quick look at for-next branch of tony's tree.
[10:41] <amitk> ogra: we'll even supply dedicated SD cards for OMAP4 work ;)
[10:41] <hrw> ogra: plug card, reboot, pastebinit serial output
[10:41] <cooloney> it seems like tony merged several branches there and prepare it for next .36 merge window
[10:41] <ogra> amitk, you mean you send me one ?
[10:41] <ogra> cool !
[10:42] <amitk> :)
[10:42] <amitk> cooloney: right
[10:42] <hrw> writing 1.7GB to SD card takes eons
[10:42] <ogra> hrw, use a proper bs= value in dd
[10:42] <ogra> speeds up a lot
[10:42] <hrw> 20K is enough?
[10:42] <amitk> bs=1M works for me
[10:42]  * ogra uses 4k
[10:42] <cooloney> i'd say the Panda board patch is the same from our -omap4 branch
[10:42] <ogra> i found thats the fastest on my laptop
[10:43] <hrw> ah you laptop users...
[10:43] <hrw> I do dd from tmpfs to sd card
[10:43] <ogra> well, builtin SD reader is unbeaten :)
[10:43] <hrw> 77,698 s, 6,5 MB/s
[10:43] <amitk> cooloney: in any case, please pull from tony's tree rather than -omap4 tree (so we have the commit id)
[10:43] <hrw> ogra: my tower has builtin cf/sd/ms/something
[10:44] <ogra> ah
[10:44] <hrw> s/^7/27
[10:44] <hrw> and I use usb one anyway ;D
[10:44]  * ogra dislikes if his SD cards are named /dev/sdX
[10:44] <ogra> way to error prone if you have a /dev/sdX HDD
[10:45] <cooloney> amitk: that's not very hard. i can do that. but i found several serial port patches for omap2/3/4
[10:45] <hrw> I have sdh usually for sd card
[10:45] <amitk> cooloney: do only the minimal necessary to get serial port on panda with master branch
[10:45] <ogra> accidentially typo that tp /dev/sda and you have fun with restoring backups :)
[10:46] <amitk> cooloney: it should only be 2-3 patches at most
[10:46] <ogra> s/tp/to
[10:46] <amitk> lunch time
[10:47] <hrw> ogra: how to regenerate boot.scr?
[10:47] <hrw> needed to change res
[10:47] <ogra> do it from your desktop
[10:47] <hrw> I know - need command
[10:47] <ogra> copy it over, remove header, change cdmline and run mkimage
[10:47] <ogra> ah
[10:47] <hrw> got
[10:48] <ogra> mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <input file> boot.scr
[10:48] <hrw> I2C:   ready
[10:48] <hrw> and beagle stopped
[10:49] <ogra> in the installed system there is /boot/boot.script ... change it there and run sudo flash-kernel
[10:49] <hrw> ogra: http://hrw.pastebin.com/si5pstv6
[10:49] <ogra> sounde like you use a wrong x-loader or u-boot
[10:49] <hrw> I had 1.4.4 xloader before
[10:50] <ogra> yeah, you dont use MLO from the card
[10:50] <ogra> 1.4.4ss is thats in the archive
[10:50] <hrw> ok, user button helped
[10:50] <ogra> :)
[10:50] <ogra> 1.4.4ss is needed for XM support
[10:50] <ogra> so we default to that one
[10:50] <hrw> http://hrw.pastebin.com/c6piMtqb
[10:51] <ogra> huh ?
[10:51] <ogra> reading /casper/uImage ?!?
[10:51] <ogra> whats that !
[10:51] <hrw> http://hrw.pastebin.com/hMJ9kSrH is printenv
[10:52] <ogra> hrw, are you sure you used the shipped boot.scr from the SD vfat as a source ?
[10:52] <hrw> yes
[10:52] <ogra> printenv is ignored
[10:52] <ogra> we only use boot.scr
[10:52] <ogra> can you paste your original boot.scr ?
[10:53] <hrw> sure moment
[10:54] <hrw> http://hrw.pastebin.com/z0aTDHFk
[10:54] <hrw> booted script from memory now
[10:55] <hrw> it is resizing now
[10:55] <ogra> that boot.scr doesnt have any /casper/uImage in it
[10:55] <hrw> ogra: so it looks  like boot.scr was ignored
[10:56] <ogra> oh, you had lucid installed before
[10:56] <hrw> ogra: where is progressbar? I see "Resizing root filesystem please wait, this will take about ten minutes ..."
[10:56] <ogra> below that you should see dots appearing after a while+
[10:56] <hrw> ok
[10:56] <ogra> not sure how long that takes, i did my tests for the code with an image file
[10:56] <ogra> real SD might be slower
[10:57] <hrw> ogra: btw - "Resizing root filesystem. Please wait, this will take about ten minutes ..." would be better
[10:57] <hrw> ogra: 3x "sh: closing paren expected" and then there are dots shown
[10:57] <ogra> i need to rephrase it anyway
[10:57] <ogra> ouch
[10:57] <ogra> damned
[10:57] <hrw> ogra: would be nice to have [ 0/100% done] ........
[10:58] <ogra> thats rather complex code
[10:58] <hrw> ................shproblem\n...........shproblem\n........
[10:58] <ogra> for now i'm happy to have *anything*
[10:58] <ogra> yeah, thats busted
[10:58] <hrw> ogra: do you know how many dots will be printed?
[10:58] <ogra> yes
[10:59] <ogra> still it needs a math function
[10:59] <hrw> python has nice itertools
[10:59] <ogra> currently i'm just using the output of resize2fs directly
[10:59] <ogra> and i dont have much time to care for more
[10:59] <ogra> no pythin in initramfs
[10:59] <ogra> needs to be shell
[11:00] <hrw> ogra: resize2fs with "-p" option?
[11:00] <hrw> shproblem\n.....
[11:00] <ogra> yeah
[11:03] <hrw> 4th line of dots ended without shproblem
[11:05] <hrw> and nothing now
[11:10] <hrw> uf.
[11:10] <hrw> [932] mounted ext3 rootfs
[11:11] <ogra> http://paste.ubuntu.com/463956/ ... i dont see where a parenthesis is missing :/
[11:14] <ogra> i dont see where "shproblem\n" could come from
[11:15] <ogra> its a really dumb function that should parse the output 1:!
[11:15] <ogra> *1:1
[11:16] <ogra> hrw, if you are done i'd like to have /var/log/jasper.log from the system
[11:16] <hrw> [1313] oom killer
[11:17] <ogra> ureadahead ?
[11:17] <ogra> or plymouthd ?
[11:17] <hrw> and plymouth
[11:17] <ogra> both are normal
[11:17] <hrw> and udev shouts "no space left on device"
[11:17] <ogra> and are hopefully fixed already (not uploaded yet)
[11:18] <ogra> yeah, thats one i still have to resaerch
[11:18] <ogra> it writes to a tmpfs
[11:18] <ogra> and doesnt happen on second boot anymore
[11:18] <ogra> i suspect its caused by ureadahead eating all ram
[11:18] <hrw> ogra: how much time since boot to login? 1h or more?
[11:19] <ogra> which will be fixed with next ureadahead upload
[11:19] <ogra> 20min or so
[11:19] <ogra> depends on the size of your SD
[11:19] <ogra> the resizing actually takes 10min per 4G
[11:19] <hrw> 4GB card
[11:19] <ogra> right
[11:19] <hrw> 1489 segfaiult
[11:19] <ogra> i would have guessed so
[11:19] <hrw> oops from kernel
[11:20] <ogra> since you said you see the resizing msg at 11:57
[11:20] <ogra> now its 12:20
[11:20] <hrw> last sysfs: /sys/module/parport/initstate
[11:20] <ogra> yeah, known and fixed already
[11:20] <ogra> or in the process to be fixed
[11:20] <ogra> lag is working on it
[11:20] <hrw> fix commited but not fix released?
[11:20] <ogra> cups forcefully loads parport_pc
[11:21] <lag> What can I do you for?
[11:21] <ogra> the module code needs fixing to not segfault
[11:21] <lag> A have sent a patch upstream
[11:21] <ogra> lag you are already doing :)
[11:22] <ogra> hrw, any trace of oem-config already ?
[11:22] <ogra> i know its not fast but you should see some X by now
[11:23] <hrw> text console disappeared so maybe x11 tries to start
[11:23] <ogra> ah, great
[11:23] <hrw> got ugly x11 background
[11:23] <ogra> heh
[11:23] <hrw> looks like 3bit or few more
[11:24] <ogra> you changed the display defaultsd
[11:24] <hrw> from 1280x720 to 1280x800
[11:24] <hrw> my monitor is 16:10
[11:24] <ogra> should soon swithc to 24bit, the first one is 16
[11:24] <ogra> right before oem-config shows up it switches over
[11:27] <hrw> looks like mouse and keyboard were not detected in x11
[11:27] <ogra> hmm
[11:27] <ogra> C4 ?
[11:27] <ogra> or your old C3
[11:27] <hrw> C3 with working usb
[11:27] <hrw> I used keyboard in text console to unblank monitor
[11:28]  * ogra hasnt seen any kbd mouse issues in the maverick images on C4 yet
[11:28] <ogra> wait a bit, its probably just busy with swapping
[11:29] <hrw> ogra: how much ram omap3/4 needs to have to get normally working UNE? 2GB? 4GB?
[11:30] <ogra> htop shows about 200M used usually
[11:30] <ogra> we add a 512M swapfile
[11:30] <ogra> so you should have >700M
[11:30] <hrw> I would fetch/unpack/boot-to-x11/installirc/gettoirc/discusshere with angstrom/gnome in shorter time then I got here
[11:30] <ogra> actually more like 160-180 used
[11:30] <hrw> it took 35 minutes so far and still nothing usable
[11:31] <ogra> well, its like 15 with omap4
[11:31] <hrw> masacre
[11:31] <ogra> omap3 is just something thats nice to have
[11:31] <ogra> omap4 is the target arch we work for
[11:31]  * hrw wants omap5 with 4GB ram and 20MB/s storage
[11:31] <ogra> heh
[11:32] <ogra> on omap4 only the resizing is slow and thats caused by the bad MMC driver
[11:32] <hrw> bbc3 feels insanely slow when rootfs is on usb
[11:32] <ogra> i have some hope that will be solved for final
[11:32] <hrw> bbxm will give better behaviour due to more ram
[11:33] <hrw> and faster cpu
[11:33] <ogra> yeah, i'll still have to test that
[11:33] <hrw> panda will again give faster cpu and more ram
[11:33] <ogra> i havent had the time yet, i'll do some test installs at the sprint on XM
[11:33] <hrw> my lcd just blanked out. touching keyboard does not bring it back
[11:33] <ogra> while C3 and C4 should be "supported" i'd rather recommend a cmdline install for such users
[11:34] <ogra> i.e. install lucid netinst image and dist upgrade to maverick
[11:34] <hrw> may I reboot?
[11:34] <ogra> hrw, try it, it should kick you into oem-config again
[11:36] <ogra> mmc init;  fatload mmc 0 0x82000000 boot.scr; source 0x82000000
[11:36] <ogra> for your uboot prompt :)
[11:36] <hrw> bootscr got not loaded
[11:36] <hrw> thx
[11:36] <ogra> i'll provide a tool to blank NAND config for such cases
[11:36] <ogra> so it falls back to defaults
[11:37] <ogra> as soon as we have the NAND driver back in the lucid kernel
[11:37] <hrw> got plymouth
[11:37] <ogra> good
[11:38] <ogra> i wonder if we should force a reboot after resizing
[11:38] <ogra> though with screwed NAND that will be problematic
[11:40] <ogra> but would be a) good to verify the new partition table works fine and b) likely be faster to bring up oem-config
[11:41] <hrw>  plymouth disappeare
[11:41] <hrw> got ugly x11
[11:41] <ogra> mouse works ?
[11:42] <hrw> nope
[11:42]  * ogra blames the maverick kernel
[11:42] <hrw> sorry, works but very slowly
[11:42] <ogra> works for sure on C4
[11:42] <ogra> phew
[11:43]  * ogra blames I/O
[11:43] <hrw> now works normally - probably oom killed something
[11:43] <ogra> i guess it just swapped
[11:43] <ogra> while reading from SD at the same time
[11:45] <hrw> nicer background on screen (did not noticed when changed)
[11:45] <hrw> o... language chooser
[11:46] <hrw> but why 1280x720...
[11:46] <hrw> it does not fit on screen ;(
[11:46] <amitk> default cmdline param
[11:48] <hrw> the bad part is that this is ubuntu - I need to wait to end of oem-config to get possibility to login on vt1 ;(
[11:48] <ogra> hrw, jasper resets the resolution again, please file a bug that it should pick that up from an existing cmdline instead
[11:48] <hrw> ogra: bug on jasper?
[11:48] <ogra> hrw, not to the end, only to the end of the config tool
[11:48] <ogra> hrw, jasper-initramfs
[11:49] <ogra> hrw, you can switch to tty and log in once it started removing stuff
[11:50] <amitk> jasper?
[11:50] <ogra> hrw, how else than through something like oem-config would you set up the system ?
[11:50] <ogra> amitk, yes
[11:50] <amitk> what is it?
[11:50] <ogra> amitk, the little brother of casper AKA the "douchebag ghost" :)
[11:51] <ogra> amitk, it does the resizing of the rootfs partition and enables oem-config
[11:51] <hrw> ogra: oem-config has to fight against other processes to get some spare ram
[11:51] <ogra> and sets up fstab
[11:51] <hrw> press "Next", wait minute or two...
[11:51] <ogra> hrw, yes, its not fast
[11:51] <amitk> huh! and it is run on every install?
[11:52] <ogra> amitk, on first boot
[11:52] <amitk> aah I see, i missed the keywork: oem-config
[11:52] <ogra> oem-config == ubiquity witout partitioner
[11:52] <ogra> jasper does the partitioning step
[11:52] <amitk> ogra: when are we getting preinstalled images for arm this cycle?
[11:53] <hrw> amitk: we have them
[11:53] <ogra> amitk, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/
[11:53] <ogra> since some weeks :)
[11:53] <amitk> nice!
[11:53]  * amitk hugs ogra
[11:53] <hrw> amitk: you need 1.5h to get omap3 pass first boot
[11:53] <ogra> amitk, but they are no fun on beagle
[11:53] <amitk> why?
[11:53] <ogra> they are great on panda though
[11:53] <amitk> they are not really pre-installed?
[11:53] <ogra> amitk, resize2fs is slow, it swaps a lot for oem-config (which runs under X)
[11:53] <hrw> amitk: because they suxx if you do not have 1GB ram and 20MB/s read/write from rootfs
[11:54] <ogra> hrw, nonsense
[11:54] <ogra> 512M are plenty
[11:54] <ogra> i expect the XM to be nearly as good as panda
[11:54] <hrw> but 256M is definitelly far far far far too small
[11:54] <ogra> agreed
[11:54] <hrw> and I have 128MB beagleboard somewhere...
[11:54] <amitk> ogra: seems like my definition of a pre-installed image differs from what is provided. Why does it need to resize?
[11:54] <ogra> if i find the time i'll do preinstalled cmdline images
[11:55] <amitk> or rather, what?
[11:55] <ogra> amitk, because users dont want to download 4G
[11:55] <ogra> the rootfs is as small as possible on that image
[11:55] <ogra> and gets expanded to the full size of the SD
[11:55] <ogra> so it doesnt matter what SD card you use
[11:55] <hrw> ogra: Bug #605831
[11:55] <ubot2> Launchpad bug 605831 in jasper-initramfs (Ubuntu) "[omap3] Resolution should be taken from /proc/cmdline if provided (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/605831
[11:56] <ogra> thanks
[11:56] <amitk> eeeks
[11:56] <ogra> amitk, ??
[11:56] <hrw> amitk: but do not use card larger then 4GB - you will wait too long
[11:56] <amitk> the uncompression of rootfs
[11:56] <ogra> amitk, not uncompression
[11:56] <ogra> its just resizing
[11:56] <ogra> to use up all the spare space on the SD
[11:57] <ogra> amitk, a simple resize2fs
[11:58] <amitk> ogra: ok, and no chance of a 4G image for people that have the BW?
[11:58] <hrw> Scheiße
[11:58] <ogra> amitk, no, that would be a waste
[11:58] <amitk> this feels like 2 steps froward and 3 steps back
[11:58] <ogra> amitk, why
[11:58] <hrw> creation of users should be before 'configuring keyboard'
[11:59] <ogra> hrw, complain at the ubiquity maintainers
[11:59] <amitk> because it still takes 2 hrs to get ubuntu on a beagle
[11:59] <ogra> not my area :)
[11:59] <ogra> amitk, it takes 15min on a panda
[11:59] <amitk> ogra: which only 3 people have in this world outside TI :)
[11:59] <ogra> amitk, its not the design of jasper that makes the beagle slow
[12:00] <ogra> amitk, or the design of the image
[12:00] <amitk> i understand it is the IO
[12:00] <ogra> amitk, its the fact that beagle is to slow for a desktop image
[12:00] <ogra> its not even the IO
[12:00] <ogra> IO is fine for cmdline images
[12:00] <amitk> ogra: so you're saying it is memory-bound?
[12:00] <XorA> heh ubuntu got too fat for the beagle :-)
[12:00] <ogra> the fact that we dont special case omap43 images but build the same image for omap3 and 4 is what hits us
[12:01] <amitk> XorA: it would seems so
[12:01] <ogra> if we would provide cmdline images for omap3 that would be fine
[12:01] <ogra> but the XM will be as good as the panda here
[12:01] <ogra> so just for Cx boards i wont trash the netbook image
[12:02] <ogra> if i find the time to hack them up i'll provide special cmdline Cx images
[12:02] <amitk> ogra: wouldn't it be easier to partitions the SD card to use up the extra space?
[12:02] <ogra> if i dont, people have to live with that on Cx boards
[12:02] <ogra> amitk, surely faster but error prone
[12:02] <amitk> ogra: and some magic with aufs to unionise them
[12:03] <ogra> eeek !
[12:03] <amitk> lol
[12:03] <ogra> amitk, the prob is that i would need separate partitions for /tmp and the like
[12:03] <ogra> its not as easy as it seems
[12:03] <ogra> and the ten mins for the resizing are really not the prob
[12:04] <ogra> the prob is oem-config and the X session
[12:04] <amitk> ogra: IMHO, they are. It doesn't make for a great 1st experience
[12:04] <amitk> even the 10mins
[12:04] <amitk> on an OMAP4 board that nobody has
[12:04] <ogra> amitk, partitioning in ubiquity is a lot slower
[12:05] <ogra> like 20min on the C4
[12:05] <ogra> so i dont let that argument count
[12:05] <ogra> the lucid install takes over 2h
[12:05] <ogra> having a 10min resize action at bootup is really not a biggie
[12:06] <amitk> ogra: ok, let me restate my problem (I've been bitching out this for a long time, almost 2 years, you already know that)
[12:06] <ogra> having oem-config running for >1h is though
[12:06] <ogra> but thats improvable due to using a cmdline image
[12:06] <hrw> re
[12:06] <ogra> or at least oem-config in cmdline mode
[12:07] <ogra> (which is ugly but a possibility for C4 boards)
[12:07] <amitk> ogra: I want an image that I can dd onto a SD card (make assumptions of 4G card!), insert it in beagle and see it boot ubuntu. In under 5 mins.
[12:07] <ogra> amitk, go to linaro :P
[12:07] <ogra> though you have to manually partition the card etc
[12:07] <amitk> ogra: why? the dd image should take care of it. Make it a fixed 4G image
[12:08] <ogra> i wont maker assumptions and i wont get allowance to spend 32G on the builder machine for kubuntu and ubuntu images
[12:08] <ogra> why would i waste the space on an 8 or 16G card ?
[12:08] <hrw> ogra: provide tarballs of rootfs
[12:08] <ogra> hrw, thats not what ubuntu does ... go to linaro for such stuff
[12:09] <hrw> so I/amitk will grab tarball, unpack to card and boot
[12:09] <ogra> that all was discussed to an extend at UDS
[12:09] <hrw> kk
[12:09] <ogra> its a bit late to change an implemented spec now :P
[12:09] <amitk> *sigh*
[12:09]  * amitk prepares to wait another year
[12:09] <XorA> problem with UDS was 99% of people couldnt get that embedded != smaller PC
[12:10] <ogra> the choice we had was eithet debian-installer/ubiquity with a 2h installation or the current setp
[12:10] <hrw> so ubuntu requires: bbxm, igep2/512M, panda, blaze, touchbook/512M and nothing smaller
[12:10] <ogra> XorA, ubuntu doesnt do embedded
[12:10] <ogra> XorA, thats linaro
[12:10] <XorA> Linaro didnt exist then (apart from in the worlds worst kept secret)
[12:10] <ogra> hrw, if i dont provide cmdline images
[12:10] <amitk> I wonder if lool is interested in investigating this in Linaro
[12:10] <ogra> XorA, linaro did exist ... just not the name
[12:11] <hrw> I would not call beagleboard embedded - I have more embedded hardware
[12:11] <ogra> XorA, in fact the arm team wasnt allowed to have its own track at UDS because of linaro
[12:11] <hrw> XorA: there were Linaro meetings during uds
[12:11] <XorA> hrw: I know, but I didnt have an NDA that allowed me to know about them
[12:11] <XorA> even though I did
[12:11] <ogra> XorA, they were just called differently
[12:12] <ogra> XorA, all arm tracks at that UDS were linaro tracks
[12:12] <ogra> next UDS we'll have linaro and arm tracks and you will notice the difference between the approaches
[12:12] <ogra> ubuntu-arm is to bring ubuntu images onto arm devices that are powerful enough to run ubuntu
[12:13] <ogra> linaro is to make that restriction go away some day ;)
[12:13] <XorA> bah all this division makes my head hurt :-)
[12:14] <ogra> linaro does upstram and core work ... ubuntu-arm just operates in the limitations of ubuntu
[12:14] <ogra> if you look at the min reqs for installinf ubuntu on a PC, the same restrictions apply for ubuntu.arm for example
[12:14] <ogra> i.e. 384M and 600MHz or so
[12:15] <ogra> and a GL capable videocard
[12:15] <ogra> at least for the maverick netbook release
[12:15] <hrw> ogra: so omap3/4 does not fit - no 3d driver in ubuntu
[12:16] <ogra> none of these restrictions apply to linaro
[12:16] <hrw> linaro req armv7
[12:16] <ogra> and linaro works on getting ubuntu off these restrictions
[12:16] <XorA> hrw: they have a GL capable GFX card, ogra didnt say he needed drivers :-)
[12:16] <hrw> XorA: ah... right ;D
[12:16] <ogra> XorA, we'll have drivers at some point
[12:17] <XorA> GLES drivers yes
[12:17] <ogra> for sure for the panda ... and likely also for the beagle
[12:17] <XorA> they are on my desk at the moment
[12:17] <ogra> right
[12:17] <hrw> X11 just died here
[12:17] <ogra> linaros job is it to improve ubuntu in a way that it can run with these drivers
[12:17] <hrw> 1h23 minutes so far
[12:17] <ogra> like making clutter/unity work
[12:18] <XorA> clutter works :-)
[12:18] <ogra> or like making it work in less ram
[12:19] <ogra> amitk, give me a resize tool that operates faster than 10min per 4G
[12:19] <ogra> amitk, then you wont have to wait for another year ;)
[12:19] <ogra> or s/year/release/
[12:20] <hrw> ogra: will isntaller work if card will be in usb card reader?
[12:20] <amitk> ogra: it is probably worth an extension to ext4 fs to treat sparse files in a special way
[12:20] <ogra> hrw, only if the device manes persist
[12:20] <ogra> *names
[12:20] <hrw> ogra: so it is hardcoded to /dev/mmcblk0*?
[12:21] <ogra> amitk, we use ext3 ctrrently
[12:21] <ogra> hrw, yes, atm
[12:21] <hrw> sux
[12:21] <ogra> hrw, patches accespted
[12:21] <hrw> my SD card does 14MB/s in beagle usb
[12:22] <ogra> hrw, jasper can handle it, asac patched it to use usb, you will need the SD to boot though
[12:22] <ogra> thats tricky
[12:22] <hrw> ogra: boot from sd is easy. plug card, uboot reads kernel/initrd, unplug card, plug into card reader
[12:22] <ogra> inbetween initramfs died
[12:23] <hrw> ogra: unplug card *before* 'bootm'
[12:23] <ogra> you can indeed do that
[12:23] <ogra> but where would bootm come from then ?
[12:23] <hrw> resize would be much faster
[12:23] <ogra> in any automated way
[12:23] <hrw> ogra: did I said 'automated'?
[12:23] <ogra> note that we cant use NAND
[12:24] <ogra> XM, panda, blaze all dont have NAND
[12:24] <hrw> installing fbset on beagle = 5 minutes
[12:24] <hrw> including 1s to fetch package
[12:24] <ogra> right, thats something linaro can do
[12:25] <ogra> swithc to fbset if you like
[12:25] <ogra> i'm restricted to debian-installer functionallity which means wither to run debian-installer, ubiquity or oem-config
[12:25] <ogra> *either
[12:25]  * ogra gets tired of that discussion
[12:26] <ogra> we wont switch to something like fbset, we cant use amitk'S approach of using a fixed size image since it will not speed up oem-config, all discussions around the topic are moot
[12:27] <ogra> and i can only point out again that resizing isnt the slow part on the C4
[12:27] <hrw> now I have x11 with nice 80's X pointer and nice background
[12:28] <hrw> time to reboot
[12:28] <ogra> hrw, at gdm ?
[12:28] <hrw> I choosed to autologin
[12:28] <ogra> ah
[12:28] <ogra> which jasper version do you have installed
[12:28] <hrw> safer when keyboard will not work
[12:29] <hrw> ogra: the one which was in 'current' image
[12:29] <hrw> will tell more after reboot
[12:29] <ogra> (and please complain to the desktop team for forcefully using unity without even checking if there is GL support)
[12:29] <ogra> hrw, also i still need the jasper log :)
[12:30] <hrw> ogra: can I just ignore fact that I had someting on BB? I prefer to use it headless
[12:30] <ogra> sure
[12:30] <ogra> just install openssh-server
[12:31] <hrw> and enable autogetty
[12:31] <ogra> btw, japer 0.12 has a fix for the enforced unity session
[12:31] <ogra> if you have an older one, edit ~/.dmrc
[12:31] <Taalas> Does anyone know any documentation for getting ubuntu installed for i.MX25 from Freescale? I googled a lot but couldn't find anything.
[12:31] <ogra> desktop team ignores all non GL systems
[12:32] <hrw> Taalas: you need 9.10 for it
[12:32] <hrw> no.. 9.04
[12:32] <ogra> and your own kernel/bootloader
[12:32] <ogra> right, 9.04
[12:32] <hrw> 9.10 require i.mx3x
[12:33] <hrw> I **need** to enable serial console
[12:34] <hrw> boot takes eons without anything other then moving dots in plymouth
[12:34] <Taalas> I have Ubuntu 9.04 on my dev pc but I want to get Ubuntu on the i.MX25. Is there any possibility. For BeagleBoard I found some documentation which is working properly. But want it on i.MX25.
[12:34] <ogra> hrw, edit /boot/boot.script, run flash-kernel to change boot options
[12:35] <hrw> ok
[12:35] <ogra> Taalas, get a properly built kernel and bootloader setup, then see the channel topic for rolling a rootfs
[12:36] <hrw> argh... solaris machine which I used by serial terminal in 1995 was faster then beagleboard...
[12:37]  * ogra wonders why
[12:37] <amitk> Taalas: there is no out-of-box support for i.MX25 in ubuntu. You'll have to get your own kernel/bootloader and you could use the old 9.04 version of ubuntu on arm to create a rootfs
[12:38] <hrw> I enter "hrw" as login and half minute to get password prompt...
[12:38] <ogra> fun
[12:38] <ogra> lovely IO
[12:38] <Taalas> Oh perfect. Thank you for this. I will work through the documentation.
[12:39] <ogra> hrw, check if bootchart is installed, could be that the desktop team put it into the default seed :P
[12:39] <ogra> that will nearly grind your system to a halt
[12:39] <hrw> there is
[12:39] <ogra> heh
[12:39] <ogra> uninstall it
[12:40] <hrw> at least 'dpkg -l' lists is but I cant see status
[12:40] <ogra> ls /var/log/bootchart
[12:40] <hrw> I have about 8-10 chars outside of left frame of monitor
[12:40] <ogra> see if it captured
[12:40] <hrw> moment... I/O
[12:40] <ogra> and also check the processlist
[12:41] <hrw> dpkg --purge bootchart needs 20 minutes
[12:41] <ogra> there might be other crap running you dont really want
[12:41] <ogra> erm, you still have autologin enabled ?
[12:41] <ogra> it will likely still try to start unity
[12:41] <hrw> ogra: so can you check on panda (as it is a bit faster) what crap needs to be dropped and drop it from arm images?
[12:41] <ogra> sudo service gdm stop
[12:42] <hrw> sudo stop gdm
[12:42] <ogra> hrw, thats on my list
[12:42] <ogra> i havent touched the session stuff at all yet
[12:42] <ogra> waiting for the DX team to provide the new minimal panel
[12:42] <ogra> then i'll start shuffling seeds
[12:42] <hrw> eglibc cross build with all tests/chaeck/binary generation will end sooner then I will get bb working
[12:43] <ogra> heh
[12:43] <hrw> and eglibc tests needs eons
[12:43] <ogra> dont complain about alpha software !
[12:43] <ogra> :)
[12:44] <hrw> yep.. golden rule of ubuntu
[12:44] <hrw> install last release if you want to complain
[12:44] <ogra> the 2D session will be a lot lighter once i have removed everything we dont need
[12:45] <ogra> prob is that we still need to ship the unity session
[12:45] <hrw> but last release complains usually can go directly to /dev/null because devel release changes too much
[12:45] <ogra> we dont have a per subarch seed possibility and omap4 will use unity on the panda
[12:45] <hrw> complaining to dev release ends with "this is dev release, do not complain"
[12:45] <ogra> right
[12:45] <ogra> do not complain, file bugs :)
[12:46] <hrw> so as a developer I have to use maverick but as a user I need lucid.
[12:46]  * ogra uses lucid everywhere
[12:47] <ogra> apart from the dev boards i work with
[12:47] <hrw> ogra: I used sid since it was created
[12:47] <hrw> and it was better to use then maverick^Wubuntu-devel
[12:47] <ogra> sure
[12:48] <ogra> ubuntu development works differently than debian development
[12:48] <hrw> I know
[12:48] <hrw> lets get beta versions of everything, get it more or less working and pray^Whope for official stable releases before release
[12:48] <ogra> ans long as you develop features that are working acrtoss package sets it will always be more broken until a certain point
[12:49] <hrw> anyway - I have a board in basement which has 250KB/s rootfs
[12:49] <ogra> using the dev version of ubuntu after feature freeze is usually ok
[12:49] <ogra> i tend to wait until then to upgrade my systems
[12:49] <ogra> anyway
[12:50]  * ogra takes a break
[12:50] <ogra> and if you have the jasper.log at some point i'll try to find out why you had the weird output during resize
[12:50] <amitk> hrw: ubuntu is also a lot more aggressive wrt to the kind of changes in the core (e.g. rework of the entire boot sequence, plymouth, upstart, etc.)
[12:50] <amitk> debian takes a long time to get these (for good reasons, btw)
[12:54] <lool> ogra: The log file changes had been backed out
[12:54] <lool> Because they needed synchronisation in 3 places
[12:54] <lool> ogra: If these were pushed again, yes, I expect they need adaptations in other places
[12:56] <lool> amitk: I'd be happy to discuss image formats; asac did more work on this though; I'd like to understand how we stand nowadays, cause I was a bit at a loss with both our Ubuntu and Linaro images; I'd like to dig a bit deeper into this
[12:57] <asac> lool: amitk: whats the discussion on formats?
[12:58] <amitk> asac: pre-installed images for beagle, etc.
[12:58] <asac> amitk: want to have a call on that?
[12:58] <amitk> asac: IMHO, what is being provided in maverick doesn't give a good first experience to users
[12:58] <hrw> enough is enough!
[12:58] <amitk> asac: sure, mumble?
[12:58] <hrw> time to hack rootfs on desktop
[12:58] <asac> amitk: yes. can we do that in 1h?
[12:59] <amitk> asac: sure, ping me
[12:59] <asac> will do
[13:03] <hrw> bootchartd and gdm killed from rootfs, card plugged into BB, boot
[13:03] <hrw> plymouth oom again
[13:08] <ogra_cmpc> lool, well, it was syncronized in the other direction ... subarh is only added to the dir now, slangasek made that change,k what i was wondering was if you had ever tested that change, it cant have worked in lucid
[13:08] <ogra_cmpc> -k
[13:09] <ogra_cmpc> amitk, in linaro you dont have such images
[13:09] <amitk> ogra_cmpc: I'm pushing for them there too ;)
[13:09] <ogra_cmpc> so you wont have the resizing
[13:10] <ogra_cmpc> ah
[13:11] <amitk> I don't like our single minded devotion to 'installation' for everything. debian-installer is just not suitable for some devices.
[13:11] <ogra_cmpc> amitk, note though that you need to repartition the SD on boot in any case no matter if you resize or not
[13:11] <amitk> why?
[13:11] <ogra_cmpc> amitk, because of the CHS restriction x-loader/u-boot put on us
[13:12] <amitk> (I don't understand the science behind our installer, but it seems like rocket science)
[13:12] <ogra_cmpc> that needs to be adjusted to the actual values of the card to be proper
[13:12] <ppearse> Can anyone point me at a list of ARM boards supported by the maverick kernel?
[13:12] <amitk> ogra_cmpc: can't that be handled before we let the user dd the image?
[13:13] <ogra_cmpc> our installer is all built around dpkg which enfoces the debconf database on us to which the installer is a frontend (among other things it is)
[13:14] <ogra_cmpc> amitk, no, becuse the CHS value for an img file might totally differ from the physical setup of an SD card
[13:14] <amitk> mdz was talking about how the package manager we have currently is not suitable for distributing everything. Perhaps now is the time ;)
[13:15] <amitk> ogra_cmpc: even if we make severe assumption e.g. 4Gb SDHC card only?
[13:15] <ogra_cmpc> well, you would have to give that value in bytes :)
[13:16] <ogra_cmpc> 4GB isnt the point, the CHS value is attached to the exact size of the card
[13:17] <amitk> ogra_cmpc: sounds like some that can be programtically detected and programmed before we dd an image.
[13:17] <amitk> *something
[13:17] <ogra_cmpc> it will work but you will have a) an unclean partition table b) if the user ever touches the partition table your system will not boot anymore
[13:18] <amitk> but it will only take 5 minutes to redo it vs. 1.5hrs currently :)
[13:18] <ogra_cmpc> amitk, 1.5h ??
[13:19] <amitk> hrw's numbers
[13:19] <ogra_cmpc> amitk, how do you come to that value
[13:19] <ogra_cmpc> *resizing* takes 10min
[13:19] <amitk> I haven't tried the pre-installed image yet
[13:19] <ogra_cmpc> per 4G
[13:19] <ogra_cmpc> i was talking about resizing and partitioning above
[13:19] <hrw> amitk: 1.5h takes installation process. resizing ~10 minutes
[13:20] <ogra_cmpc> you are talking about oem-config slowness
[13:20] <amitk> I don't even want that
[13:20] <amitk> why do we want to configure usernames and timezones in that extremely slow way
[13:20] <ogra_cmpc> amitk, we dont
[13:21] <ogra_cmpc> amitk, on omap4 its a few min
[13:21] <ogra_cmpc> amitk, for omap3 we could switch to the cmdline version of OEM config
[13:22] <ogra_cmpc> amitk, but the final truth is that you simply do not want to use such a netbook image on HW like the C4
[13:22] <ogra_cmpc> i havent tested it yet but i'm pretty sure it will work similar well on the Xm as on the panda
[13:22] <amitk> ogra_cmpc: yet we provide those images :)
[13:23] <ogra_cmpc> amitk, we also provide minimal spec for running ubuntu on HW
[13:24] <lool> ogra_cmpc: Would you have a list of boards which are supported in maverick right now?
[13:24] <ogra_cmpc> the C4 simply doesnt match these specs
[13:24] <lool> ogra_cmpc: This is for ppearse
[13:27] <ogra_cmpc> lool, all beagles above rev B. (not fun with Cx but works as you can see in the dicssion above), and panda ... for final we plan blaze through changing the bootloader in the omap4 image, and we're about to anble dove images again
[13:28] <ogra_cmpc> lool, if you have an requirement for more omap3 boards, tell me and i'll look what i can do
[13:29] <ogra_cmpc> *enable
[13:38] <asac> ogra_cmpc: available?
[13:40] <ogra_cmpc> asac, for a call ?
[13:40] <ogra_cmpc> one sec
[13:40] <asac> ogra_cmpc: yep ... i will call you in 5 ;)
[13:40] <asac> we need to sync on something :-
[13:40] <asac> P
[13:46] <ppearse> ogra_cmpc:Thanx
[14:00] <lool> ogra_cmpc: thanks
[14:00] <lool> ogra_cmpc: I think IGEPv2 would be nice
[14:01] <ogra> lool, i'll check if it needs anything special then (bootloader/kernel)
[14:02] <amitk> ogra_cmpc: rtg is on it
[14:02] <ogra> yep, i know
[15:39] <Taalas> I created a rootfs with rootstock and my i.MX25 is booting into the system and now I have the login prompt on the LCD Touchscreen. But neither I can get a prompt on my serial console nor a keyboard plugged into the usb port is working. Anybody knows how to go on?
[15:40] <Taalas> I used following parameters to get it work sudo rootstock --fqdn imx25 --login hctm --password temppwd --imagesize 4G --seed build-essential, openssh-server, tsconf, ssh --dist jaunty --serial ttyS0
[15:41] <Taalas> also connecting via ssh is not working. The ethernet device is up
[15:41] <ukleinek> Taalas: --serial ttymxc0 maybe?
[15:42] <GrueMaster> Also, I don't think you want spaces in the --seed list.
[15:44] <Taalas> Hmm that might be the reason why the image size isn't increasing after I added some seeds...
[15:44] <Taalas> Ok rebuilding it one more time.
[15:58] <awayfar> Hey everyone.  I am involved in a good deal of native ubuntu compilation on the ARM, and I was wondering if anyone had suggestions for a multi-CPU ARM board I could use as a build machine.  Right now I'm compiling on my actual target, and would like to speed up the process as much as possible while sticking to the native arch.
[16:00] <GrueMaster> Haven't heard of any on the market as a released product yet.  TI Omap4 should be out in the near future, nVidia tegra is available on a limited developer basis (1 per, haven't heard of how well it works).  Don't know off hand of others that have public announcements.
[16:00] <lool> awayfar: Depends of your budget
[16:01] <lool> awayfar: I think the versatile express boards are nice, but they are really expensive
[16:01] <hrw> lool: A9 ones?
[16:01] <lool> the dove ones were nice in theory, but the early ones I got were unstable, I don't know if that's fixed, nor whether these are publicly available
[16:01] <ukleinek> awayfar: /me likes http://www.qnap.com/pro_detail_feature.asp?p_id=127
[16:01] <lool> hrw: Yes
[16:02] <lool> ukleinek: armv5 though
[16:02] <lool> awayfar: that's a good question, what architecture baseline do you need?
[16:04] <hrw> awayfar: which cpu/board you target?
[16:05] <lool> Death by a hundreds replies
[16:05] <hrw> we flooded his input buffers
[16:05] <awayfar> Wow, THANKS for all the replies!
[16:06] <awayfar> I read slow ;)
[16:06] <hrw> awayfar: now your time to answer ;D
[16:07] <awayfar> My budget is negotiable, since this is a corporate project, and my absolute ideal board would be multiple A9/OMAP4.
[16:08] <awayfar> My target is an OMAP4
[16:08] <hrw> awayfar: ok
[16:08] <hrw> pandaboard is not on market yet, no idea about blaze
[16:10] <lool> awayfar: OMAP4 isn't really widely available yet; versatile express has quad A9 + 1 GB of RAM, so quite a nice starting point
[16:10] <hrw> and good for build machine
[16:11] <hrw> hi prpplague dmart
[16:12] <prpplague> hrw: greetings earthling
[16:13] <awayfar> hrw: That sounds great.  Now, for a not-so-bright question; If I were to install Ubuntu on an A9, is that close enough to the OMAP4 to maintain compatibility?  I know the OMAP4 uses the A9, but I may as well ask...
[16:13] <lool> awayfar: What compatibility are you after?
[16:13] <GrueMaster> Everything but the kernel "should" work.
[16:14] <Taalas> ukleinek and GrueMaster thanks for your help. Worked out perfect
[16:15] <GrueMaster> Taalas: Good to hear.
[16:15] <orbarron> gm all
[16:25] <awayfar> All, thanks for the information.  I spoke with prpplague offline, and he helped sort me out.  Thanks again!
[19:27] <lool> ogra: Don't think https://bugs.launchpad.net/bugs/605972 is armel (it's jasper), right?
[19:27] <ubot2> Launchpad bug 605972 in jasper-initramfs (Ubuntu) "Need to set hostname to ubuntu during first boot. (affects: 1) (heat: 8)" [Medium,New]
[19:29] <GrueMaster> lool: It is jasper-initramfs.  Since it is only used on omap (currently) I tagged it as armel.
[19:29] <lool> It would be nice to keep the list of ubuntu-armel/armel bugs identical to the bugs specific to armel
[19:29] <GrueMaster> Anyways, the tag would have been put there by apport if I had filed using it.
[19:30] <lool> Yes, but I remove it when it's not armel specific
[19:30] <lool> Not a big deal, but since random other people (cough Linaro) will look at ARM bugs, I'd like them not to see jasper bugs
[19:32] <GrueMaster> If this bug can be shown to be reproducible on other architectures, I'll agree.  Until then, if it is seen on armel first, it gets tagged on armel.  Just following bug posting procedures laid out to me from earlier cycles.
[19:33] <GrueMaster> https://wiki.ubuntu.com/MobileTeam/BugWorkflow
[20:18] <ukleinek> Taalas: you're welcome


[07:25] <meena> And so it begins again! (I hope)
[09:04] <tribaal> hi all! I would need some pointers on how to get a more recent cloud-init version on CentOS (eg. CentOS 7.6). Is using a COPR repository the exepcted way to get the latest binairies or is there some kind of process to refresh the cloud-init package in CentOS base similar to Ubuntu's SRU?
[09:07] <meena> tribaal: which version are you getting from COPR?
[09:08] <meena> or, "would you be getting" … if you haven't dared to try yet.
[09:19] <tribaal> meena: the idea would be to have a centOS 7.6 with 19.3+
[09:20] <tribaal> but I don't know what the best way to do this would be (we'd probably update our default templates to include the right binaries ourselves if there's no SRU-like process for CentOS)
[09:25] <meena> tribaal: https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/ you'd get 19.4 if you https://docs.pagure.org/copr.copr/how_to_enable_repo.html#how-to-enable-repo `dnf copr enable @cloud-init/el-testing`
[09:26] <tribaal> meena: ack, thanks. That's not really "production" builds though, is it?
[09:28] <meena> tribaal: i don't know (anything about CentOS / Fedora etc… i haven't used them in a long time, and in $$jobs$$ we use RHEL)
[09:30] <tribaal> meena: ack - same here (but we us Ubuntu :) )
[09:30] <tribaal> so our Ubuntu templates have the latest and greatest but we'd need our centOS templates to have the latest/greatest as well
[09:30] <tribaal> and I'm not too sure how/where to look :)
[13:42] <Odd_Bloke> meena: tribaal: o/ Happy new year!
[13:43] <Odd_Bloke> I can't remember exactly the arrangement of our COPR repos, we'll have to wait for Ryan/Chad to help, I'm afraid.
[13:43] <meena> Odd_Bloke: happy monday
[13:54] <meena> Odd_Bloke: i'll need to quiz your brain some more wrt net refactor
[13:54] <meena> but, IIRC, i've written the ideas / questions down. now lemme just find the URL…
[13:55] <meena> 23:47 <meena> updates: https://hackmd.io/3-YBj1t9TAeKhmfLBQUjXQ?view#Revisiting-modules
[13:55] <meena> 27th of December.
[13:56] <Odd_Bloke> I haven't even opened my inbox yet, so I don't know how soon I'll get to it, but it's on my list now! :p
[14:09] <tribaal> Odd_Bloke: heya! happy new year to you too :)
[16:32] <blackboxsw> happy 2020 cloud-initers. Time to dig out from holiday emails
[16:37] <blackboxsw> tribaal: we (upstream cloud-init) don't work with distros directly, other than Ubuntu, to push upstream changes into the distribution. We rely on the distro vendors to vet cloud-init themselves. That said, I believe otubo is the right person to ask about how to coordinate updates into CentOS.   The cloud-init upstream team only provides a our COPR repos as a facility for CentOS users to check if more recent
[16:37] <blackboxsw> upstream versions of cloud-init help resolve bugs seen on the current (older) cloud-init in CentOS stock images.  Also note, upstream only publishes to https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/  when we are undergoing an SRU for ubuntu, so expect that the "el-testing" repo is fairly stable.
[16:38] <blackboxsw> we SRU cloud-init into Ubuntu every month or two.
[16:41] <tribaal> blackboxsw: ack, so I guess building our CentOS templates with a newer binary (for instance built in your COPR repo - or building one ourselves) might be what we end up doing
[16:41] <tribaal> blackboxsw: also: happy new year :)
[16:41] <blackboxsw> tribaal: definitely, for the short term and otubo may have pointers for feature-requesting an update of cloud-init into CentOS. I'm not sure where to start there.
[16:42] <blackboxsw> same to you 🎉
[16:42] <tribaal> otubo: out of curiosity - do you know/can you explain what the process of updating cloud-init in CentOS looks like? is it periodic? is it "whatever was current at the time of the CentOS release"?
[16:42] <blackboxsw> emoj snap for the win
[16:43] <tribaal> I mean updating in the base CentOS
[17:32] <ananke> I'm trying to locate where in the official documentation various config options are documented, specifically for 'users' section, and I must be missing something obvious. where can I find the canonical info on items such as the ones described here? https://www.zetta.io/en/help/articles-tutorials/cloud-init-reference/
[17:35] <smoser> its more than a bit obnoxious that you cannot attach tarballs to pull requests
[17:35] <smoser> https://github.com/canonical/cloud-init/pull/128
[17:36] <rharper> ananke: https://cloudinit.readthedocs.io/en/19.2/topics/modules.html#users-and-groups  and https://cloudinit.readthedocs.io/en/19.2/topics/examples.html#including-users-and-groups
[17:37] <smoser> oh. maybe ignore my noise
[17:37] <ananke> rharper: ahh, thanks! didn't realize the modules section expanded
[17:38] <rharper> ananke: well, the latest version doesn't do that, we have a bug to revert that back to the other releases
[17:38] <ananke> ohh, that would explain
[17:39] <blackboxsw> rharper: yeah I was finding the same.
[17:39] <rharper> https://bugs.launchpad.net/cloud-init/+bug/1852456
[17:39] <blackboxsw> user_groups docs get generated but not included for some reason
[17:39] <blackboxsw> thanks ryh
[17:39] <rharper> low hanging fruit
[17:39] <blackboxsw> yeah
[17:39] <ananke> yep, no wonder. I've been blindly fumbling through the search and menu
[17:40] <rharper> ananke: yeah, sorry for the trouble
[17:40] <rharper> blackboxsw: I don't think we should wait for powersj to sort out a better solution  as mentioned in the bug; we should re-add the Left-hand-side toc  as it was; it's *much* friendlier
[17:41] <powersj> rharper, blackboxsw +1
[17:41] <blackboxsw> smoser, I thought I saw github could allow tar.gz attachments https://github.com/dear-github/dear-github/issues/150#issuecomment-369744370
[17:42] <blackboxsw> testing that theory
[17:44] <blackboxsw> yeah test.tar.gz works, test.tar is rejected due to invalid file type
[17:45] <blackboxsw> and yeah, ridiculous that they'd support tar.gz, but not tar :P0
[17:51] <blackboxsw> Just published to focal [ubuntu/focal-proposed] cloud-init 19.4-16-gf8950d63-0ubuntu1 (Accepted)
[17:51] <blackboxsw> Inbox
[17:54] <blackboxsw> rharper:/Odd_Bloke I think we'll need to fix build-and-push script as we can no longer push branches direct to upstream (as they require review) https://trello.com/c/MdP53rtp/1239-github-upstream-release-script-build-and-push-needs-to-push-up-a-pr-for-review
[17:54] <smoser> blackboxsw: yeah, ignore my noise
[17:55] <blackboxsw> I've put up a PR for the upstream release (which was already dput and accepted by my build-and-push run) https://github.com/canonical/cloud-init/pull/151
[17:55] <blackboxsw> smoser:  no problemo..... but just this time my friend
[18:01] <smoser> i wont mess up again
[18:01] <blackboxsw> heh
[18:25] <Odd_Bloke> blackboxsw: Should we just disable branch protection on those branches?
[18:26] <Odd_Bloke> I'd prefer to have exactly the git commit used for the upload as tip of those branches, and I don't think any of GH's merging strategies would do that.
[18:26] <Odd_Bloke> (GH's rebase never fast-forwards even when it could IIRC.)
[18:36] <blackboxsw> Odd_Bloke: that's a good idea on branch protection disabling for ubuntu/devel at least. We can talk at a planning meeting in 1.5 hrs
[18:55] <Odd_Bloke> blackboxsw: Do we need to wait for a meeting?
[18:55] <Odd_Bloke> rharper: powersj: Thoughts on disabling branch protection on the ubuntu/* branches, so we can push the uploaded git revision directly?
[18:59] <powersj> Odd_Bloke, I'm good with that
[18:59] <powersj> not hearing any objections
[19:03] <blackboxsw> +1 Odd_Bloke
[19:03] <rharper> Odd_Bloke: +1 on allowing direct landing
[19:04] <blackboxsw> and Odd_Bloke earns a card :) https://trello.com/c/MdP53rtp/1239-github-upstream-release-script-build-and-push-needs-to-push-up-a-pr-for-review
[19:05] <blackboxsw> rharper: ananke powersj https://github.com/canonical/cloud-init/pull/153  for review of the doc fix in modules https://github.com/canonical/cloud-init/pull/153
[19:07] <blackboxsw> I added a TOC to the top of modules page. make doc seems to show all modules now, with links
[19:13] <Odd_Bloke> blackboxsw: Done. :)
[19:14] <ananke> thanks!
[19:14] <ananke> and looks like trello is back in working order too
[19:19] <blackboxsw> starting out the year right :). New year's resolutions and all
[19:31] <blackboxsw> Odd_Bloke: thanks, just pushed ubuntu/19.4-16-gf8950d63-0ubuntu1 to origin
[19:32] <blackboxsw> ubuntu/devel should represent the commitish that was uploaded
[19:34] <Odd_Bloke> Nice
[20:40] <ananke> am I just confused, or is the example backwards? 'Update apt database on first boot
[20:41] <ananke> from https://cloudinit.readthedocs.io/en/latest/topics/examples.html shows 'package_update: false
[21:03] <Odd_Bloke> ananke: It's not _wrong_ per se, in the sense that it's just illustrating how you would give this configuration option, but it is _definitely_ confusing, so we should address it.
[21:06] <ananke> Odd_Bloke: it's certainly very confusing, considering the very next example shows an option _adjusted_ to match the description
[21:06] <Odd_Bloke> Yep, agreed.
[21:06] <Odd_Bloke> ananke: Interested in proposing a fix?
[21:07] <ananke> certainly, I'm just not familiar with the procedure. do I have to actually do a PR?
[21:09] <ananke> on a side note, is there a way to use variables in cloud-init configs? not sure if YAML permits that
[21:11] <Odd_Bloke> ananke: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data details how to use Jinja for templating, is that what you're looking for?
[21:11] <Odd_Bloke> ananke: You'd need to submit a PR, and sign the CLA (which, unfortunately, involves having a Launchpad account).
[21:12] <ananke> indeed, it's close. I am looking for using it with runcmd, since I have to refer to a version number in multiple commands. I wasn't prepared for the entire config to be be a potential jinja2 template, but I think it will work
[21:13] <ananke> Odd_Bloke: I see. I'd love to, but I'm short on time to complete few other things, and getting those items lined up would put me behind. maybe later this week
[21:15] <ananke> hmm, I don't think the instance data will work though, since all I'm doing is supplying a single cloud init config file
[21:15] <Odd_Bloke> ananke: What do you mean by "config file"?
[21:15] <Odd_Bloke> cloud-init has several things that might be. :p
[21:16] <ananke> Odd_Bloke: good point. it's what I can provide with packer & multipass when an instance is launched
[21:17] <Odd_Bloke> ananke: That's user-data (at least for multipass), so I think you should be good.  But your best bet would be to try and see, if you can. :)
[21:17] <ananke> forgive my ignorance, still trying to wrap my head around how cloud-init works, and how we can leverage it
[21:17] <Odd_Bloke> No forgiveness necessary, we're more than happy to help. :)
[21:20] <ananke> is there an architectural diagram of cloud-init that would show the stages and what's being ingested at each one? or something that would differentiate between user and instance data (and if there are any other ones)
[21:22] <Odd_Bloke> ananke: https://github.com/canonical/cloud-init/pull/154 :)
[21:22] <Odd_Bloke> I'm not aware of such a diagram.
[21:22] <ananke> thanks!
[21:22] <Odd_Bloke> Once again, I agree that it would be very useful! :p
[21:22] <blackboxsw> just descriptive docs that I know of https://cloudinit.readthedocs.io/en/latest/topics/boot.html about what each stage does. differentation of user/meta/instance  data  https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html
[21:23] <ananke> the diagram here is somewhat helpful: http://fbrnc.net/blog/2015/11/how-to-provision-an-ec2-instance
[21:25] <blackboxsw> ananke: a brief overview of cloud-init from a presentation we gave in OSSEU https://events19.linuxfoundation.org/wp-content/uploads/2017/12/cloud-init-The-cross-cloud-Magic-Sauce-Scott-Moser-Chad-Smith-Canonical.pdf
[21:27] <ananke> blackboxsw: thank you, this looks great. exactly the high level stuff I need to get me oriented. I've been suffering from 'can't see the forest for the trees'
[21:28] <blackboxsw> ananke: also I forgot it's linked here too with other context https://cloudinit.readthedocs.io/en/latest/topics/faq.html#where-can-i-learn-more
[21:28] <ananke> cheers!
[21:28] <blackboxsw> surely
[22:19] <meena> packer can use cloud-init?
[22:45] <Odd_Bloke> meena: It depends on which backend you're using, I think, but yes.
[23:08] <ananke> meena: yes. you can pass the cloud-init config via its user_data or user_data_file options
[23:10] <ananke> it's certainly not something easy to figure out if you're not familiar with that nomenclature. none of its documentation mentions cloud-init outright
[23:12] <Odd_Bloke> rharper: On the Scaleway PR, is your intent that Louis step back and find a way to log better messages?  (It looks, to me, like a more general statement about what we should do as a project, but might read as a more specific request.)
[23:13] <rharper> Odd_Bloke: the latter; for now;
[23:13] <rharper> I'm I won't -1 the current change to the datasource; but we have other variants, DatasourceSmartOS does a if self._network_config is UNSET: self._network_config = None;
[23:13] <rharper> which might match better in Scaleway since they __init__() to self._network_config = None
[23:14] <rharper> it works out the same, but I was sort of ranting that we've not given datasources common methods for this non-datasource-specific scenario
[23:15] <rharper> I was quite surprised that it was set to UNSET until I walked through the logs and code
[23:15] <rharper> so I kind of want to make it clear in the future via the logs; and potentially have better methods around manipulation/checking of ds.network_config state
[23:39] <Odd_Bloke> Ack
[23:50] <meena> ananke: aaah. i was looking for it under the provisioning methods, and could not find it
[23:54] <ananke> meena: bingo. and it runs before any provisioners kick in
[23:55] <meena> cool cool
[23:57] <ananke> though I wish it had better integration with cloud-init, for example an easy way to tell packer to wait until cloud-init is done


[01:40] <geirdal> for creative Humans?
[01:45] <OvenWerk1> geirdal: creative dogs are allowed... or aliens (even illegal ones)
[01:46] <OvenWerk1> For Creative Creatures?   ;)
[01:46] <geirdal> Owenverk1: hehehehe
[01:47]  * OvenWerk1 thinks he has seen a video of a dog doing paintings not too long ago
[01:48] <OvenWerk1> https://www.youtube.com/watch?v=XrvOUWDetOs
[01:49] <geirdal> yes!


[00:41] <sebsebseb> Anyone about still?
[00:43] <penguin42> maybe
[00:44] <popey> yes
[00:44] <popey> :D
[00:45] <popey> what brings you here sebsebseb ?
[00:54] <sebsebseb> popey: bored earlier so joiend some channels, had to turn off computer, came back here
[00:55] <popey> ☺
[00:55]  * penguin42 has been watching videos from linux.conf.au and afew others
[01:14] <sebsebseb> popey: we don't need pm now :d
[01:14] <sebsebseb> popey: ok that's awesome if it's going rolling release
[01:15] <popey> it's under discussion
[01:15] <popey> but likely to happen
[01:15] <popey> can't see it not happening
[01:15] <sebsebseb> release schedules can cause such issues at itmes, when it comes to having certain things, as I know even more now as well since Mageia
[01:16] <penguin42> I guess many of us on home machines have treated it as a rolling anyway; as soon as the next version starts to arrive I start running it
[01:19] <sebsebseb> penguin42: yeah I used to do stuff like that to
[01:19] <sebsebseb> not run the final stable version for long, because I would be off using the alpah 1 of the next
[01:19]  * tashs is bored
[01:21] <penguin42> but for my work machine I previously used LTS (although currently on Quantal); not quite sure what I'll do if that moves to a rolling, I don't really want rolling for my work machine
[01:23] <sebsebseb> penguin42: I thought the idea was the LTS every two years
[01:23] <sebsebseb> and instead of versions in between a rolling
[01:24] <sebsebseb> penguin42: of course LTS's start get old as well after six months or so I guess :d
[01:25] <penguin42> sebsebseb: Yeh, I ran with 10.04 for a good 2 years on my work machine; I can't really justify screwing around with it too much
[01:26] <sebsebseb> penguin42: are you still running that now?
[01:26] <penguin42> sebsebseb: No, when I got a new laptop a couple of months ago I put Quantal on it; probably a mistake, I should have gone with Precise
[01:26] <sebsebseb> oh
[01:26] <penguin42> just on the basis I'm going to have to upgrade it again in a few months to keep upto date
[01:28] <penguin42> it's a bit of a fight getting everything to work by the time I've got dual monitor to work on Nouveau with adding/removing the monitor, and the magic of getting some of our internal programs to work
[02:22] <Klettbar> hi
[02:22] <Klettbar> > why in life we can not trust anyone?
[02:22] <Klettbar>  why is everyone ready to x..x the other
[02:29] <popey> wut?
[02:31] <sebsebseb> aww I can't trust you Klettbar  or  popey  or anyone here, maybe not even myself aww heh heh
[02:31] <popey> wut?
[02:31] <sebsebseb> well I did put anyone here, so I guess that includes me then to heh heh
[02:32] <sebsebseb> popey: don't know trying to make a joke out of whatever that was :d
[04:13] <RZAFC> Anyone know what this means? SYSLINUX 4.06  EDD 4.06-pre-7 Copyright (C) 1994-2010 H. Peter Anvin et al
[09:08] <redtape-AFK> Good Moaning.. whoops change  o'nick needed too !
[09:12] <AlanChicken> and mee
[09:20] <MrBojangles> AlanBell, my old friend.
[09:26] <redtape-renegade> Anything good on R4 atmo . ? on any other beeb radio channel ??
[09:27] <redtape-renegade> **or on any ..
[09:50] <einonm> I'm playing about on a nexus 7 with 13.04 desktop, since I've taken the effort to get multi boot working... It's not particularly stable, is 13.04 desktop on a touch screen device actually a Thing that anyone else is bothering to play with?
[10:27] <AlanBell> einonm: I think they were mainly using it for performance testing
[10:27] <AlanBell> the touch stuff is all QML with flingables
[10:29] <einonm> AlanBell: ok, thanks. I did assume unity would be a bit too hungry for a tablet...
[10:30] <AlanBell> well I am not sure it is really
[10:30] <AlanBell> the nice thing about compiz is the GPU does it all
[10:30] <MartijnVdS> \o/ gpu
[10:30] <AlanBell> the dash is only slow because it is blocking on slow scopes searching for things
[10:31]  * MartijnVdS remembers the first UDS where compiz was "a thing"
[10:31] <MartijnVdS> when wobbly windows on a cube desktop were the coolest thing ever ;)
[10:31] <AlanBell> tablets and ARM things like the raspberry pi have fairly good GPU capability
[10:31] <AlanBell> wobbly windows on a cube still is the best thing evar
[10:32]  * AlanBell is sad that we turn off all the cool stuff
[10:32] <MartijnVdS> AlanBell: I want a sound effect with the wobbling though
[10:32] <AlanBell> I want my 3d desktop I was promised in Jurassic Park
[10:32] <dwatkins> great, my network driver seems to be making my PC reboot after all
[10:32] <MartijnVdS> AlanBell: A UNIX system?  I'm learning to use Awesome with a tmux setup. Got irssi, elinks, mutt and vim all set up this morning
[10:40] <kvarley> Can anybody think of an open news apI? Bing search doesn't qualify, google's news api is depreciated.
[10:42] <einonm> kvarley: BBC news?
[10:42] <kvarley> einonm: Do they have an API/
[10:43] <kvarley> einonm: All the documentation I find is old. The best I can do with BBC News is get the RSS feed
[10:43] <einonm> I just remember seeing some custom displays showing BBC news things - http://www.bbc.co.uk/developer/technology/apis.html from a quick google, no news listed tho
[10:44] <einonm> probably RSS based, thinking about it
[10:44] <kvarley> Yeah, I'd seen this
[10:44] <kvarley> Might just write a scraper to get the RSS feed, translate to JSON and go from there
[11:05] <brobostigon> good morning everyone.
[11:08] <popey>  morning
[11:09] <brobostigon> morning his-popeyness
[11:09] <kvarley> einonm: Discovered the Guardian have a semi-decent API. :)
[11:14] <einonm> kvarley: should have guessed, free API's sound like something the Guardian would be into
[11:17] <MartijnVdS> they're into it a LOT
[11:47] <Azelphur> Serious Sam 3 is on special offer today, only £6, I picked it up (steam, native)
[11:49]  * dwatkins thanks for Debian bug contributors and installs the Realtek r8168 module
[11:49] <dwatkins> So far no crash, looks like my machine mis-identified the card and installed the wrong driver for the r8168, using the r8169
[11:51] <dwatkins> Should I log a bug? Looks like this is happening in other distros too.
[11:52] <dwatkins> full details here http://forums.linuxmint.com/viewtopic.php?f=49&t=80757#p469071
[11:57] <dwatkins> aha bug 839393 seems to address this
[14:10] <penguin42> hmph
[14:11] <popey> getting annoyed with GPU lockups now
[14:14] <penguin42> which gpu?
[14:25] <popey> sandybridge
[14:32] <penguin42> hmm there don't seem to be any face rec programs in the repos, and all the ones I can find on line seem to use opencv which kind of sucks for the free drivers
[14:32] <penguin42> oh hang on, no it doesn't
[14:32] <penguin42> I'm confusing opencl and opencv
[14:38] <mgdm> opencv is excellent
[14:41] <penguin42> not played with it yet
[14:57] <sebsebseb> Afernoon people
[14:57]  * penguin42 is an afternoon person - mornings are terrible
[14:58] <sebsebseb> penguin42: yeah I am not much of a morning person these days either, well unless I been up all night :D heh heh
[14:58] <sebsebseb> penguin42: ,but my sleeping isn't that bad at the moment so :d
[15:07] <penguin42> mgdm: I just had this idea of running face recognition over my browsers webcache
[15:17] <Darael> penguin42: That sounds like a terrible and wonderful idea.
[15:17] <penguin42> Darael: Exactly!
[15:18] <penguin42> Darael: What could possibly go wrong?
[15:18] <Darael> penguin42: Before thou saidst that, very little.  Now that thou *hast*...
[15:18] <Darael> Oh, dear.
[15:18] <penguin42> Darael: It's ok, Person-of-interest is on tonight
[15:18] <Darael> If anyone remembers when I was musing over Compiz providing both multiple desktops and multiple workspaces, I have at least worked out a way to switch desktops.  xdotool is a Useful Thing.
[15:19] <Darael> penguin42: ?
[15:19] <penguin42> Darael: oh, cop like program based around the idea of an all knowing machine that tracks everyones movements from cameras/communication etc
[15:20] <BigRedS> mutliple workspaces and multiple desktops? I'm going to have to ask what you mean by either :)
[15:21] <Darael> Workspaces are the Compiz version of what we often refer to as virtual desktops.  Desktops are essentially the same thing, but seperate, and they're what Metacity used (for example).  Compiz actually supports both, and allows one to configure the *number* of each, but provides no way to configure keyboard shortcuts (or any mechanism at all) for *switching* the latter.
[15:22] <Darael> Unhelpfully, both the GNOME config tools and CCSM have historically referred to their variant as "viewports", as well.
[15:22] <Darael> (workspaces go within desktops, if it helps)
[15:23] <Darael> I am given to understand the distinction dates back to fvwm.
[15:23] <BigRedS> oh lordy. This is all hiliariously more complex than I thought possible
[15:23] <penguin42> Darael: I think you're saying one of those terms means a single large surface
[15:24] <BigRedS> there's good reason I go nowhere near anything technical in the gui
[15:25] <Darael> penguin42: Um... not exactly, because Metacity (for example) traditionally treated desktops as a large surface, but Compiz did the same thing with workspaces.
[15:25] <Darael> Furthermore, one can name desktops but not workspaces...
[15:25] <penguin42> Darael: OK; so erm picking any one set of terminology; why do you want both ?
[15:26] <Darael> Because Reasons?
[15:26] <Darael> More seriously, a combination of because I can and because I want to know *why* Compiz supports desktops, but only partially.
[15:26] <penguin42> oh right, obviosuly...
[15:28] <penguin42> Darael: KDE also has two concepts of virutal desktops; but I don't think either end up as a single large surface these days
[15:29] <Darael> I find what looks like an unfinished implementation fascinating.
[15:30] <penguin42> Darael: It's one of those things which you wonder whether it's something that's still being worked on or a dead end
[15:30] <Darael> Quite.  Although it's been that way for several years, now...
[15:32] <Darael> I suppose it could be something to do with application segregation when using multiple monitors?
[15:44] <penguin42> hmm, I wonder if our OpenCV is packaged wrong - but I don't know enough about it - I build libface and it's looking in usr/share/OpenCV for something, we have an /usr/share/OpenCV but most stuff is actually in /usr/share/opencv
[16:24] <sebsebseb>
[17:34] <directhex> where are WEP keys stored in quantal?
[18:08] <einonm_> directhex: I think they used to be stored in gnome-keyring?
[18:13] <Darael> einonm_, directhex:  Ones available to all users are somewhere in /etc/NetworkManager, IIRC.  User-specific ones were in gnome-keyring the last I checked, but that was a couple of releases ago.
[18:18] <directhex> einonm_, WPA keys are
[18:20] <einonm_> directhex: It's probably easier these days just to crack a WPA key than hunt for the file...
[18:21] <Darael> einonm_: s/WPA/WEP/, surely?  WPA isn't *quite* that easy to break yet.  Especially with non-dictionary keys.
[18:57] <moreati> I've seen similar spam emails from 3 different yahoo email accounts in the last couple of days, which seems a large coincidence
[18:57] <moreati> but I haven't seen coverage to suggest a wider hack/compromise. Anyone heard anything?
[18:57] <penguin42> moreati: You can never tell where email has come from
[18:59] <moreati> penguin42: they came from addresses of people I know, and included other's that the sender knows. Whatever sent them had access to the address book of the sending account
[19:36] <popey> saw this and thought of gord http://www.youtube.com/watch?v=9ctigYpQSTU
[19:37] <Darael> Only in Japan.
[19:42] <penguin42> Darael: I've got to say that's one of the least-weird things I've seen come out of japan
[19:42]  * penguin42 is more surprised by how long they seem to be cooking the eggs for
[19:43] <Darael> penguin42: 'tis true.  There's been some *very* odd things out of Japan.
[19:43] <moreati> They were probably metric minutes
[19:44] <penguin42> that would be even longer!
[19:44] <popey> they were quite long minutes, I agree
[19:48] <penguin42> but if you add all up it was about 25mins - they'd be like rocks by then
[19:49] <penguin42> Darael: What I expect to see Japan producing is chickens bred to lay eggs in those shapes
[19:49] <AlanBell> like bonsai kittens?
[19:50] <Darael> penguin42: Biologically a PITA :P  Especially since the air-bubble will be in an unpredictable location at boiling time.
[19:50] <penguin42> AlanBell: Exactly!
[19:50] <Darael> (Yes, boring of me, I know)
[19:50] <moreati> penguin42: I think the second dunking was in cold water
[19:50] <penguin42> AlanBell: We don't see enough Bonsai kittens these days - heck there are generations of internet users now who've never even seen a bonsai kitten
[19:51] <penguin42> Darael: If you think it'd be a PITA just think of the chickens
[19:51] <Darael> penguin42: I meant for the chickens!
[23:02] <sebsebseb> 1 2 3 not much going on here
[23:02] <popey> ☺
[23:02] <popey> evening sebsebseb
[23:03] <sebsebseb> popey: yeah evening
[23:04]  * zleap is here
[23:04] <zleap> just listening to ubuntu podcast
[23:06] <sebsebseb> zleap: shhh don't tell popey what I just told,  how I don't tend to listen to it,  oh now he know hmm heh heh :d
[23:06] <zleap> lol
[23:07]  * popey shrugs
[23:07] <zleap> i am just putting the ubuntu full circle magazne on my external hdd
[23:07] <zleap> need to copy to a cd later for the computer group
[23:07] <popey> ~6000 people have listened to the latest episode
[23:07] <zleap> wow
[23:07] <sebsebseb> zleap: hmm I think I downloaded that once or twice
[23:07] <popey> well, have downloaded ☺
[23:07] <zleap> that is cool
[23:07] <popey> can't tell if they've listened
[23:07] <sebsebseb> PC Linux OS also has a magazine that's good, PDF, but again only downloade that like once or twice I think
[23:07] <popey> yeah, we get around 10K listeners per episode
[23:07] <zleap> i subscribe
[23:08] <sebsebseb> popey: I was there for your 100th episode Live I think it was
[23:08] <popey> heh
[23:08] <sebsebseb> popey: didn't know LInux Outlaws was on at same time though at the time, but ah well, and again for that one, only heard it properly like once maybe twice, and a bit of eisodes or whatever it was
[23:08] <sebsebseb> I find it hard to listen to podcasts in general
[23:08] <sebsebseb> since I would rather listen to music :d
[23:08] <sebsebseb> and they are so time consuming
[23:08] <popey> its not on the same time
[23:09] <popey> they record on monday, we recorded on tuesday last season, wednesday this season
[23:09] <popey> i listen to more podcasts than music
[23:09] <zleap> oddly on lubuntu i find k3b more relaiable than brassero whicjh is defalt for burning cds
[23:09] <popey> i dont think I've had a cd burn fail for years
[23:10] <sebsebseb> popey: zleap also with a podcast, espeically if the discussion isn't that interesting,  it's easy to end up being distracted by IRC or IM or whatever
[23:10] <sebsebseb> and then it's like uhmm
[23:10] <sebsebseb> what are they talking about?
[23:10] <sebsebseb> oh better go back, since dind't take stuff in properly
[23:11] <popey> depending on the podcast really
[23:11] <sebsebseb> zleap: that's not odd at all, same repos as normal Ubuntu
[23:11] <popey> for bbc comedy, i listen as I am cooking dinner on a friday night
[23:11] <sebsebseb> yeah or you do something away from computer, whilst listening for example yeah
[23:12] <sebsebseb> zleap: I like Brasero, but in general yeah it seems it can go wrong at times, and so realy K3B is better,  I like K3B to :)
[23:12] <sebsebseb> tend to burn stuff with Brasero recently, but it was more so K3B in the past
[23:14] <zleap> brassero doesn't work properly on my old desktop
[23:17] <popey> what happens?
[23:17]  * popey goes to make cheese on toast, brb
[23:39] <zleap> popey, it seems to hang for ages and the status bar just goes back and forth
[23:39] <zleap> i have just removed banshee
[23:43]  * popey boggles
[23:44] <AlanBell> huh, I appear to have removed skype
[23:45] <AlanBell> oh, thats why apt-get autoremove got rid of a load of cruft, it took skype out
[23:48] <AlanBell> and it is uninstallable on raring
[23:53] <popey> is it?
[23:54] <popey> http://paste.ubuntu.com/5583787/
[23:54] <popey> installs here
[23:57] <AlanBell> where did you get skype_<IP_ADDRESS>.0-0ubuntu<IP_ADDRESS>_amd64.deb from?
[23:57] <AlanBell> the multiarch thing from skype.com wants to install most of a 32bit operating system which apt-get autoremove trimmed out last week
[23:59] <AlanBell> hmm, partner repo
[23:59] <AlanBell> so that one, depends on skype-bin