[01:15] <Roguehorse> added more to the gallery:  http://www.roguehorse.net/gallery.html
[01:15] <darthrobot> Title: [Scott DuBois - Gallery]
[01:26] <Roguehorse> One thing I can say ... my condition may have be in bad straights now ... but I didn't let iot stop me from "living"
[01:27] <Roguehorse> it
[16:37] <akk> Lenovo survey where you can pick Linux as an OS option: http://blog.lenovo.com/en/blog/retro-thinkpad-survey-4-miscellaneous
[16:37] <darthrobot> Title: [Retro ThinkPad Survey 4: Miscellaneous | Lenovo]
[16:37] <akk> Spread the word ...
[16:44] <Roguehorse> akk: interesting, thanks!
[19:02] <Roguehorse> published a new post: https://www.linkedin.com/pulse/rights-scott-dubois?trk=prof-post
[19:02] <darthrobot> [999] Title: [Error reading title]


[18:24] <Ankman> http://www.webupd8.org/2014/04/ubuntu-1410-codename-revealed-utopic.html
[18:26] <Ankman> systemd is coming...
[19:49] <IdleOne> Seriously? My post to the Ubuntu facebook page are still moderated?


[03:02] <lfitz> if i put the new kernel uImage-2.6.34 in the boot directory and extract the kernel modules to the root fs, will that successfully update the kernel?
[03:03] <lfitz> ..and try to reboot?
[03:04] <lfitz> or is there docs on how to upgrade the kernel on a sheevaplug?
[08:30] <sebjan> lag: Hi! I just look at the syslink patch applied by Tim, and I don't see the modalias, nor the module_init(). Did you test this patch? I do not expect it to be functional...
[08:31] <lag> What do you mean you don't see them?
[08:34] <lag> Sebjan?
[08:34] <sebjan> lag: in the patch applied on the top of the tree, there is not the MODULE_ALIAS code for example
[08:35]  * lag looks
[08:35] <cooloney> sebjan: that's true, please follow the email thread started from lag
[08:36] <cooloney> lag: in you v1 patch, there is MODULE_ALIAS code
[08:37] <cooloney> lag: but in the v2 patch which is in Maverick now, there is no such code
[08:37] <cooloney> lag: i guess sebjan is asking this
[08:37] <sebjan> correct :)
[08:37] <cooloney> lag: btw, thanks a lot for email me the blob file
[08:37] <lag> cooloney, sebjan: You're correct, I'll add it as a separate patch right now
[08:38] <cooloney> lag: great, man
[08:38] <sebjan> lag: we also need the module_init(), right?
[08:38] <lag> Why do you need that?
[08:39] <sebjan> lag: for the omap4_syslink_init function to be called on startup? Or the __init does it?
[08:40] <hrw> morning
[08:41] <lag> sebjan: The device_initcall(omap4_syslink_init); does it
[08:47] <lag> sebjan: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4-syslink
[08:48] <lag> Sorry about that. I did a git reset --mixed <sha1>
[08:48] <lag> Added omap4-common.c and must have missed off ipc_drv.c
[08:49] <lag> It was still in my tree though, hence when I tested it, it worked
[09:02] <sebjan> lag: no problems. By the way, we shall stick with syslink drivers static right now, as we are seeing issues when using them as modules. We are investigating that, and will send an update when this will be fixed (then we can activate syslink drivers as modules)
[09:03] <lag> No problem - keep me posted
[09:05] <sebjan> lag: yes, sure!
[09:27] <lag> sebjan: Can you have a look at the patch on the mailing list please
[09:27] <lag> sebjan: If it's okay can you ack it as well?
[09:30] <sebjan> lag: done
[09:32] <lag> sebjan: Thanking you!
[10:34] <ogra> sebjan, i still see hangs with the recent panda kernel
[10:41] <ogra> a lot less frequent, but they happen
[10:45] <lag> ogra: Must be userspace ;)
[10:45] <lag> My kernel works flawlessly
[10:45] <lag> :)
[10:46] <ogra> the archive kernel ?
[10:46] <ogra> installed from the package
[10:49] <lag> Nope
[10:50] <lag> But it will be the latest Maverick kernel won't it?
[10:51] <lag> I'm in the process of flahsing my SD card with the latest archive
[10:51] <ogra> ok
[10:52] <lag> ogra: If one thing (within the kernel) is crashing continuously, raise a bug report and I'll take a look
[10:53] <ogra> lag, here is another one to play with bug 603062
[10:53] <ubot2> Launchpad bug 603062 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "oops in parport_pc_probe_port function of parport_pc module (affects: 1) (heat: 8)" [Medium,New] https://launchpad.net/bugs/603062
[10:55] <lag> The new image still doesn't work with my monitor :(
[10:55] <lag> And there's no console output either
[10:56] <ogra> the image should start in console mode by default
[10:56] <ogra> we dont use splash during resizing yet
[10:57] <lag> I have nothing
[10:57] <lag> Uncompressing Linux... done, booting the kernel.
[10:57] <lag> It's been like this for 5mins
[10:57] <ogra> thats serial
[10:57] <lag> Do you think it's resizing?
[10:57] <lag> Yeah
[10:57] <ogra> we dont use serial on ubuntu images
[10:57] <lag> And nothing on the monitor
[10:57] <lag> Zero
[10:57] <lag> Ziltch
[10:57] <lag> Nada
[10:58] <ogra> do you know a cmdline that works for you ?
[10:58] <ukleinek> lag: try enabling DEBUG_LL and DEBUG_LL_CONSOLE
[10:58] <lag> ukleinek: From within the kernel?
[10:58] <ukleinek> lag: make menuconfig
[10:58] <ogra> ukleinek, note that ubuntu images dont have console= settings by default
[10:58] <lag> fdr editconfigs ;)
[10:59] <ogra> breaks the splash
[10:59] <lag> Still nothing ...
[10:59]  * lag whistles
[10:59] <ogra> lag, lets try to find a cmdline that works for everyone
[11:00] <ogra> there wont happen anything, if your monitor doesnt init it wont do that later either :)
[11:00] <lag> I have a cmdline that works for me
[11:00] <ukleinek> lag: add a printch(c) to emit_log_char
[11:00] <lag> What will happen if I restart the board during the resizing process?
[11:00] <ogra> you will have to re-dd
[11:00] <ogra> the filesystem will be corrupted
[11:00] <lag> Grrrrrrrrrrrrr
[11:00] <lag> What if I wait
[11:01] <lag> It will take the same amount of time
[11:01] <ogra> it will move on and start X to configure the system eventually
[11:01] <ogra> which you likely wont see if the framebuffer doesnt work
[11:02] <ogra> dd the image newly, mount the first partition and add your cmdline changes to boot.scr
[11:02] <ogra> (before booting it for the first time)
[11:02] <ogra> dont forget mkimage
[11:03] <ogra> it would be good if we can find the smallest common denominator that makes all monitors work
[11:04] <ogra> or if TI can fix the EDID code (preferred indeed)
[11:06] <hrw> 1024x768 should work
[11:06] <ogra> well, depends on your monitor
[11:06] <ogra> mine cant do non widescreen modes on the HDMI port afaik
[11:07] <ogra> but i'll try
[11:07] <hrw> XGA was default beagleboard resolution
[11:11] <ogra> lag, what are the options you use
[11:11] <lag> setenv bootargs omapdss.hdmimode=0 omapdss.hdmicode=4 vram=15M, omapfb.vram=0:5M noinitrd mem=512M root=/dev/mmcblk0p2 rootwait ro ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
[11:12] <ogra> omapfb.vram=0:5M ?!?
[11:12] <ogra> thats definately to less
[11:12] <lag> TI told me to use it
[11:12] <lag> Well that works
[11:12] <lag> But 32 and 8 work for me also
[11:13] <ogra>  vram=15M is also to less for our kernel
[11:13] <lag> setenv bootargs omapdss.hdmimode=0 omapdss.hdmicode=4 vram=32M, omapfb.vram=0:8M noinitrd mem=512M root=/dev/mmcblk0p2 rootwait ro ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
[11:13] <ogra> we enable all possible output devices
[11:13] <ogra> can you try without omapfb.vram=0:8M ?
[11:13] <lag> Well your cmdline doesn't work for me so ...
[11:13] <lag> I can
[11:13]  * ogra will try omapdss.hdmimode=0 omapdss.hdmicode=4 on his monitor
[11:14]  * ogra just tried  omapdss.hdmimode=0 omapdss.hdmicode=35, that makes the board crash once X is up
[11:15] <ogra> and cuts of 60% of the bottom of the screen on my monitor
[11:17] <ogra> lag, also i dont get why mem=512M would work for you
[11:17] <ogra> i was clearly told that will cause issues and hard locks
[11:18] <lag> Probably because I'm not running a GUI
[11:18] <lag> What was it again 468?
[11:18] <ogra> well, robclark said thats reserved ram for the coprocessor
[11:18] <ogra> i dont think that should harm X
[11:18] <ogra> or have any influence
[11:18]  * lag shurgs
[11:18] <lag> It just does
[11:18] <lag> What is the correct value?
[11:19] <lag> 463>
[11:19] <lag> ?
[11:19] <hrw> 463
[11:19] <ogra> right
[11:19] <lag> I'm using a kernel with TI's hack in it at the moment
[11:20] <ogra> sigh, the last crash trashed my SD
[11:20] <lag> Let me build my own and I'll try it out
[11:20] <ogra> lag, that doesnt help at all
[11:20] <ogra> please use the same kernel we all use
[11:20] <lag> ogra: I'm working with both
[11:21] <lag> I have other things going on too :)
[11:21] <ogra> me too
[11:22] <lag> So, I need to be running both kernels
[11:22] <ogra> but it doesnt help the images if you dotn use and improve the image kernels
[11:22] <lag> Doesn't the daily builds use the latest Maverick kernel anyway?
[11:22] <ogra> the one in the archive
[11:22] <ogra> which is behind the git tree
[11:23] <lag> Where is it built from?
[11:23] <ogra> the git tree
[11:23] <ogra> but its not built every day
[11:24] <ogra> tim builds it from kernel.ubuntu.com from cooloneys tree afaik
[11:24] <ogra> every few weeks
[11:25] <ogra> with mode=4 i get a small square in the top left corner of my monitor
[11:25] <ogra> i dont think any of these options will help, TI needs to fix the EDID detection code properly
[11:26] <ogra> its bad enough that we have to use *any* cmdline options
[11:27] <lag> ogra: http://paste.ubuntu.com/460578/
[11:27] <lag> Try some more
[11:27] <lag> See what works for you
[11:27] <ogra> well, what else works for you ?
[11:27] <lag> I don't know yet
[11:27] <ogra> doesnt help if i try all of them
[11:27] <lag> What do I have to mkimage on?
[11:28] <lag> do*
[11:28] <ogra> the edited boot.scr
[11:28] <lag> How do you do that?
[11:28] <lag> I've only done uInitrd and uImage
[11:28] <ogra> sudo mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.scr <mountpoint of first partition>/boot.scr
[11:28] <ogra> the first boot.scr needs to be plain text (no uboot header)
[11:29] <ogra> thats the one you edited
[11:29] <lag> I only have the one with the header on
[11:29] <lag> Should I just take that off?
[11:29] <ogra> yeah
[11:29] <ogra> just delete it in vi
[11:30] <ogra> mkimage adds it again
[11:30] <lag> vi? pfft
[11:30] <ogra> well, or use: strings  <mountpoint of first partition>/boot.scr >./boot.scr
[11:30] <ogra> but that might leave cruft at the top line
[11:31] <ogra> lag, can you try omapdss.hdmicode=6 ? thats one i could imagine all HDMI monitors should be able to do
[11:32] <ogra> err. line 6
[11:32] <ogra> thats code 28 indeed
[11:33] <lag> 4 sort of works
[11:33] <lag> I can see it
[11:33] <ogra> 4 doesnt work here
[11:33] <lag> But it's out of range of my monitor
[11:33] <lag> And is shakey
[11:33] <ogra> well, it draws on the screen but is unusable
[11:34] <lag> Running /scripts/local-bottom ...
[11:34] <ogra> 640x480n is nothing we can run the desktop in
[11:34] <ogra> you wont be able to reach any of the buttons in the apps
[11:35] <lag> I'll try 28 when it's finished doing 'its thing'
[11:35] <lag> It doesn't matter anyway - my keyboard doesn't work!
[11:35] <lag> Grr
[11:36] <lag> no space left on device?
[11:37] <lag> It's a 16GB card?
[11:37] <ogra> it didnt resize
[11:37] <lag> Why not?
[11:37] <ogra> MMC issues i guess
[11:37] <lag> But it resizes yours?
[11:37] <ogra> GrueMaster reported similar issues with some SD cards
[11:37] <lag> I did get the parport segfault though
[11:37] <ogra> it resizes the five i have here for testing
[11:38] <lag> Do you have a 16GB SDHC card there?
[11:38] <ogra> GrueMaster seems to have a similar card to yours, please check with him (once he is up) if you got the same
[11:38] <ogra> no
[11:38] <ogra> my biggest one is 8G
[11:38] <lag> SDHC?
[11:38] <ogra> yes
[11:38] <lag> Odd
[11:39] <lag> Can I resize it manually?
[11:39] <hrw> error -110?
[11:39] <ogra> no
[11:39] <lag> Nope
[11:39] <lag> Different bug
[11:39] <ogra> can you plug the card into your pc and check for /var/log/jasper.log please
[11:40] <ogra> it should have error messages
[11:40] <ogra> where exactly do you get the "no space left on device" errors btw
[11:40] <ogra> any particular process thats causes them ?
[11:41] <ogra> code 28 doesnt work here either btw
[11:41] <ogra> chops off the bottom half of the screen
[11:44] <ogra> lag, where do you get the no spaxce messages ?
[11:44] <lag> On the monitor
[11:44] <ogra> if its udevd thats a tmpfs issue (udev writes to a tmpfs)
[11:44] <ogra> haha
[11:45] <lag> ;)
[11:45] <lag> I can't remember what it was doing now
[11:45] <ogra> hmm
[11:45] <lag> It could have been udev
[11:45] <ogra> well, then only jasper.log can tell
[11:45] <lag> The screen has gone now
[11:45] <ogra> does X start ?
[11:45] <lag> Nope
[11:45] <ogra> the timeframe was also way to short
[11:45] <ogra> resizing 16G will likely take about 15min
[11:46] <hrw> you guys are insane with that resizing
[11:46] <ogra> so please get me the log so i can see what went wrong
[11:46] <ogra> hrw, why ?
[11:46] <ogra> hrw, compared to a 2-3h install its quite reasonable
[11:47] <hrw> ogra: cant I fetch tarball which will be unpacked to card?
[11:47] <ogra> plus you need an additional target device
[11:47] <ogra> hrw, that will be as messy as a rootstock image
[11:47] <ogra> you will never get a proper ubuntu install that way
[11:48] <ogra> it will be something "ubuntu alike"
[11:48] <hrw> so now I get 512MB image to dd on card which will start with initrd which will resize that 512MB to whole card?
[11:49] <ogra> you get a 1.4G image and yes, initrd is essential for a proper ubuntu image
[11:49] <lag> ogra: 28 from the cmdline is still out of range
[11:49] <lag> However
[11:49] <lag> When I do: echo 28 | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing
[11:49] <lag> It looks great
[11:49] <ogra> oh
[11:49] <ogra> hmm
[11:49] <hrw> why I can install x86(-64) with 1CD but arm needs >2CD?
[11:50] <ogra> hrw, because x86 uses a squashfs and a full installer
[11:50] <ogra> our image is bz2 and needs to be uncompressed before dd
[11:50] <ogra> and is fully preinstalled
[11:50] <lag> hrw: Our boards don't have CD drives :)
[11:50] <ogra> well, they have SD slots
[11:51] <lag> Yes, hence why we use entire images
[11:51] <ogra> which we used before in a similar way to CD drives
[11:51] <ogra> so you had to install a live image to USB from SD card
[11:51] <lag> Our full install takes 5 mins. How long does X86 take?
[11:51] <ogra> a) the installation can take 2-3h depending on the card
[11:52] <ogra> b) you need to use the SD as a "boot floppy" on boards like panda
[11:52] <ogra> so you need to trash the installation media at the end of the install
[11:52] <ogra> very very ugly
[11:52] <lag> Yup
[11:52] <ogra> x86 takes between 20 and 40min
[11:52] <ogra> with a speedy CD drive
[11:53] <ogra> it copies the 2G from the squashfs to the HDD
[11:53] <ogra> and then removes bits
[11:54] <ogra> in our images the resizing takes the longest time, after that its relatively speedy since only oem-config runs
[11:54] <ogra> sadly resizing takes at least 10min
[11:55] <ogra> lag, anything intresting in the jasper.log file ?
[11:55] <lag> It was trashed
[11:55] <ogra> gah
[11:55] <lag> I trashed it
[11:55] <lag> I am re-running
[11:56] <ogra> what you can do is to add break=bottom on the cmdline, that will give you a busybox shell
[11:56] <ogra> jasper.log lives in /dev/.initramfs/jasper.log there
[11:57] <ogra> you can ctrl-d out of that shell and booting moves on
[11:57] <ogra> (works also with break=top or premount, depending where you want to inspect the initramfs)
[11:57] <lag> Just tested 28 with the archive kernel
[11:57] <lag> Nada
[11:57] <lag> Got to reflash now :(
[11:57] <ogra> sad
[11:58] <ogra> we really need TI to fix that properly then
[11:58] <ogra> fiddling with cmdline options in the default install is ugly anyway
[11:58]  * ogra prefers to not have more than "quiet splash root=UUID=..."
[11:59] <ogra> and ro
[12:02] <lag> Well I have direct contact with the video people at TI ...
[12:02] <ogra> robclark is resident here too :)
[12:03] <lag> Is robclark video people?
[12:03] <ogra> yep
[12:04] <lag> Cool - let's bother him :)
[12:04] <lag> Where is he based?
[12:04] <ogra> tx
[12:10]  * ogra played with /sys/devices/platform/omapdss/display0/custom_edid_timing
[12:10] <ogra> sadly i have the same issue as with setting modes on cmdline
[12:10] <ogra> screen isnt fullscreen
[12:11] <ogra> i either have a small square at the top left of the monitor or the screen extends beyond monitor size
[12:12]  * ogra wishes DVI would just work
[12:13] <lag> :(
[12:13] <ogra> hmm
[12:13] <ogra> DVI does work
[12:14] <ogra> well, the HDMI->DVI cable from my beagle does at least
[12:14] <ogra> weird
[12:14] <lag> ogra: .initramfs doesn't exist
[12:14] <ogra> but same effect
[12:15] <ogra> /dev/.initramfs/
[12:15] <ogra> init mounts it under /dev
[12:15] <ogra> its a tmpfs
[12:16] <lag> Oh okay
[12:16] <lag> I'll try dropping into a Busybox shell then
[12:16]  * lag is reflashing
[12:16] <lag> This sucks
[12:17] <ogra> aha, DVI doesnt work on boot at all
[12:18] <ogra> well, it does, but puts the screen to weird ranges
[12:20]  * ogra takes a break
[12:43]  * lag pounces on robclark!
[12:43] <robclark> hi lag
[12:43] <lag> Hey robclark
[12:43] <hrw> hi robclark
[12:43] <lag> How are you this afternoon/morning?
[12:43] <robclark> hi hrw
[12:44]  * robclark is just finishing my coffee
[12:44] <lag> Can you type and drink? :)
[12:44] <lag> Or would you like me to wait for you to finish?
[12:44] <robclark> no, I can type
[12:46] <lag> We're having video issues
[12:46] <robclark> uh-oh
[12:46] <lag> I have an LG FLATRON W2261VP
[12:47] <lag> I have tried omapdss.hdmicode=*
[12:47] <robclark> what resolution?  If it could do 1920x1080 then, in theory, it shouldn't even need any bootargs..
[12:48] <hrw> robclark: thats 22" so rather not fullhd
[12:48] <lag> And depending on what '*' is, I either receive shakey text and the monitor say "out of range"
[12:48] <lag> Or I get nothing
[12:48] <lag> Yes, it does 1920x1080
[12:48] <lag> Or should do
[12:49] <robclark> hmm..  in the printk's from the HDMI driver you should see what resolution the driver *thinks* the monitor can do
[12:49] <lag> But it doesn't
[12:49] <lag> With no args, the monitor just goes to sleep
[12:49] <robclark> but I think the driver still has troubles with some monitors..
[12:49] <lag> We don't have access to the boot-up messages with this kernel
[12:50]  * lag flicks to another kernel
[12:50] <robclark> hmm... ok.. that is a bit inconvenient
[12:50] <lag> It does the same thing on my kernel
[12:50] <robclark> although to be honest, I'm not a display driver guy..
[12:51] <robclark> if you could get a log of the boot msgs, we send that to me<EMAIL_ADDRESS>and I'll loop in display driver team
[12:51]  * robclark thinks what is really needed is to get the display driver team access to more monitors to test with
[12:51] <lag> I am in direct contact with Mythri
[12:51] <robclark> ok, perfect
[12:52] <lag> But things are slooooooooow over email
[12:52] <robclark> she knows the HDMI driver more than I..
[12:52] <robclark> ok.. I'll try to pester them to get on IRC..
[12:53] <lag> That could be a good thing
[12:53] <lag> I think she's in the far east though isn't she?
[12:53] <robclark> yes
[12:53] <lag> And would have gone home by now?
[12:53] <cwillu_at_work> lag, afaik, the trouble with higher resolutions is that the driver can't keep up the refresh rate
[12:53] <robclark> well, most of them work rather late.. so probably still in the office now
[12:54] <cwillu_at_work> it's pretty much up to the monitor whether it will still work at that point
[12:54] <lag> cwillu_at_work: So where do we go with this?
[12:55] <cwillu_at_work> lag, working from memory here, having spoken to folks before on this.
[12:55] <cwillu_at_work> hang on a sec, let me check my logs
[12:55] <lag> The odd thing is, a mode that doesn't work on the cmdline using omapdss.hdmicode will work using: echo * | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing
[12:56] <lag> And it will work perfectly then?
[12:56] <cwillu_at_work> oh, really?
[12:56] <lag> Yeah! What gives?
[12:56] <lag> But that's no good for be, as I'm working on boot-up code
[12:57] <cwillu_at_work> what does .hdmicode= do that a normal omapdss command line doesn't?
[12:57] <lag> me*
[12:57] <lag> That's what I'm looking for now
[12:57] <lag> ;)
[12:57]  * lag is on it
[12:57] <cwillu_at_work> omapfb.mode=dvi:1024x768MR-16
[12:57] <cwillu_at_work> is what I'm usually doing
[12:57] <cwillu_at_work> although usually 1280x1024 or 1600x900
[12:57] <lag> I'm using hdmi
[12:58] <hrw> cwillu_at_work: on beagleboard?
[12:58] <cwillu_at_work> same thing
[12:58] <cwillu_at_work> yes
[12:58] <cwillu_at_work> oh, are we not talking beagles?
[12:58] <lag> Nope
[12:58] <hrw> cwillu_at_work: they talk about pandaboard
[12:58] <lag> I have Beagle working
[12:58] <cwillu_at_work> I'd still imagine it's the same thing though
[12:58] <hrw> cwillu_at_work: panda can do fullhd-60
[12:58] <cwillu_at_work> just <somethingelse>:1280x1024MR-16 instead of DVI:
[12:59] <cwillu_at_work> especially if it works echoing to the sysfs
[13:00] <cwillu_at_work> I might be out on the road with my boss today, I'll find out in an hour.  If not, I'm interested in spelunking into the relevant dss code today :)\
[13:04] <lag> cwillu_at_work: I just tried your args - the monitor just stuck its fingers up at me and went to sleep
[13:04] <cwillu_at_work> does it report the refresh rate it's getting before it goes to sleep?
[13:05] <cwillu_at_work> and did you try any other options re: the dvi: bit?
[13:05] <lag> Yes
[13:06] <lag> dvi and hdmi
[13:06] <lag> Just did this: echo 40 | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing
[13:06] <lag> And it appeared
[13:06] <lag> Looking perfect
[13:06] <lag> Grrrrrrrrrrr
[13:06] <robclark> lag, hmm, so setting it via bootargs seems broken?
[13:07] <lag> Correct
[13:08] <hrw> 'TI: please fix your drivers'
[13:08] <lag> :)
[13:14] <robclark> btw, for those who haven't already noticed:  #pandaboard
[13:14] <hrw> lag: http://marcin.juszkiewicz.com.pl/2009/06/12/ti-please-fix-your-usb/
[13:14] <lag> Does anyone have a keyboard and mouse attached to their Panda?
[13:15] <robclark> lag: yup
[13:15] <cwillu_at_work> lag, come to think of it, there should be another file in that folder with the names for each display
[13:15] <cwillu_at_work> try doing a "cat *", and see if anything shows up
[13:15] <lag> hrw: How funny!
[13:15]  * robclark has to run.. be back later
[13:16] <lag> EDID-Informationcat: driver: Is a directory
[13:16] <lag> 1
[13:16] <lag> cat: hpd_enabled: Input/output error
[13:16] <lag> cat: mirror: No such file or directory
[13:17] <lag> hdmi
[13:17] <lag> cat: rotate: No such file or directory
[13:17] <lag> cat: subsystem: Is a directory
[13:17] <lag> 0
[13:17] <lag> 148500,1920/88/148/44,1080/4/36/5
[13:17] <lag> DRIVER=hdmi_panel
[13:17] <lag> 1
[13:17] <lag> cat: wss: No such file or directory
[13:17] <lag> Whoops
[13:18] <cwillu_at_work> so, my suspicion is that hdmi or hdmi_panel is the right invocation then
[13:18] <cwillu_at_work> also, I really really hate it when it takes a million years to page an app back into memory when I have 2gb of ram being wasted on cache
[13:19] <cwillu_at_work> (and don't tell me to set swappiness, that's useless as a long term proposition)
[13:19] <lag> cwillu_at_work: Tried both of them ... nothing
[13:20] <cwillu_at_work> boo.
[13:20] <cwillu_at_work> k, I'll poke you in a couple hours if I'm not driving out to the middle of nowhere
[13:21] <lag> I'm going to have a poke around in the driver in the meantime
[13:46] <mythripk> lag, I heard from Rob that you had some more issues in HDMI..
[13:49] <lag> lag == lee
[13:49] <lag> :)
[13:49] <lag> We've been chatting
[13:50] <mythripk> did you try out the timing values i suggested over mail ?
[13:50] <lag> Yes
[13:50] <lag> They worked when I use sysfs
[13:50] <mythripk> ie the custom_edid_timing right?
[13:50] <lag> They don't when I use them on the kernel cmdline
[13:50] <lag> Correct
[13:51] <lag> I don't see why my monitor should be different to any other
[13:51] <mythripk> ok ie when you use omapdss.hdmicode= and omapdss.hdmimode=
[13:51] <lag> Beagleboard works out of the box
[13:51] <lag> Yes, they don't work
[13:51] <mythripk> it would not be , can you please share the log ?
[13:52] <lag> The most I can get from them is a fuzzy screen and my monitor saying "out of range"
[13:52] <lag> When I use which settings?
[13:52] <mythripk> any , where you are getting fuzzy screen and monitor giving "out of range "
[13:53] <mythripk> also what is the timing value that you set with beagle ?
[13:53] <lag> I have no idea
[13:53] <lag> I'll try to find out for you
[13:54] <lag> Also, my monitor doesn't turn itself on
[13:54] <mythripk> no that's fine , log would help , but the same command line i sent for 640 and 480 ie vga setting worked ?
[13:54] <lag> I have to turn it off, then on again to get my fuzzy screen
[13:54] <mythripk> with the vga setting too ?
[13:55] <lag> Here is fuzzy screen settings: http://paste.ubuntu.com/460620/
[13:55] <ogra> mythripk, the problem is that we need something that works generally on the ubuntu images
[13:55] <lag> Nothing has 'worked' - some have been better than others
[13:56] <ogra> there is no way to adjust boot options for every monitor
[13:57] <ogra> preferably by autodetection and without any boot parameters, though if thats not possible, a bootarg with the smallest common denominator that makes it work on all monitors would also work
[13:58] <mythripk> currently the default setting is for 1080p setting but you could pass the boot args , the setting that will definitely work on All Tv's would be VGA resolution according to HDMI spec , I could make it as default
[13:59] <mythripk> Lag didnt VGA resolution work for you ? From your mail i was under the impression that it did.
[13:59] <ogra> VGA is to small for our desktop
[14:00] <lag> Which number was that?
[14:00] <mythripk> omapdss.hdmicode=4 and omapdss.hdmimode=0
[14:00] <ogra> and causes weird effects on some monitors ... i.e. mine doesnt expand to the full monitor size, i get a square in the top left corner of the screen
[14:00] <lag> That's the fuzzy screen setting that I use
[14:01] <mythripk> ogra , ya VGA is too small but that is the only setting that by default is supported by all TV's and then
[14:01] <lag> mythripk:
[14:01] <lag> ubuntu@beagleboard:/sys/devices/platform/omapdss$ cat display0/timings
[14:01] <lag> 61714,1280/80/48/32,720/3/13/5
[14:01] <lag> ubuntu@beagleboard:/sys/devices/platform/omapdss$ cat display1/timings
[14:01] <lag> 13500,720/12/68/64,574/5/41/5  .
[14:02] <lag> From the Beagle
[14:02] <ogra> mythripk, 1024x768 would work for us ...
[14:03] <mythripk> ok then can you set omapdss.hdmicode=16 and omapdss.hdmimode=0 ?
[14:03] <ogra> that gets me the above described effect
[14:03] <ogra> doesnt expand to the full screen size
[14:04] <ogra> not sure what it does for lag's monitor
[14:04] <ogra> or for GrueMaster's who also has display issues
[14:05] <lag> Checking
[14:05] <mythripk> http://omappedia.org/wiki/Bootargs_for_enabling_display this has explanation as to what you code you could use for all the DVI settings ,  How to read and set EDID timings for HDMI  section , you could modify the omapdss.hdmimode and code correspondingly for bootargs
[14:05]  * lag 's monitor stuck its fingers up at him and went to sleep
[14:06] <mythripk> with 16 and 0 ?
[14:07] <ogra> mythripk, is there any chance that works automatically at some point ?
[14:07] <ogra> the EDID data should have all possible modes the monitor can handle or not ?
[14:07] <ogra> so if you can read it you shoudl be able to switch to a valid mode
[14:07] <mythripk> Lag From the pastebin theEDID is read and being set correctly : EDID Content 256                                                                                EDID TIMING DATA FOUND                                                                                Hdmi_code = 4 mode = 1
[14:08] <mythripk> ogra, yes the EDID has all the values supported by the monitor , but from the log tha lag sent me earlier its NULL , i was actually surprised
[14:08] <lag> I think "Hdmi_code = 4 mode = 1" is coming from my boot args
[14:08] <lag> Although mode should be 0?
[14:09] <ogra> mythripk, aha :)
[14:09] <mythripk> yes are you setting omapdss.hdmimode=0? in the bootargs?
[14:09] <lag> I am
[14:10]  * ogra sees "How to enable HDMI in hot-plug detect mode" ...
[14:10] <ogra> i wonder if we could enable that by default in our kernel
[14:11] <ogra> are there any drawbacks when defaulting that value to 1
[14:11] <ogra> ?
[14:11] <lag> I just tried setting omapdss.hdmimode=0 and leaving the code - nothing
[14:12] <mythripk> ogra , I sent a patch to lag to default put it in hot plug detect mode as he was sync lost digit earlier , through sysfs you could use  echo 1 > /sys/devices/platform/omapdss/display2/hpd_enabled again from http://omappedia.org/wiki/Bootargs_for_enabling_display
[14:13] <mythripk> lag , could you please try with another monitor ? or is it the same behavior with all ?
[14:13] <ogra> mythripk, right, i saw that
[14:13] <lag> The only other HDMI device I have is my TV downstairs 42"
[14:13] <ogra> mythripk, but it seems like something really userfriendly to enable by default if it doesnt disturb other functionallity
[14:21] <mythripk> ogra, yes we could actually read the first block of EDID and set the timings which we currently are not doing today , for some samsung TV's not working
[14:22] <ogra> hmm
[14:22] <ogra> i have no issues with my samsung monitor
[14:22] <ogra> and apparently i'm the only panda user in the ubuntu team who doesnt have display issues ... which is funny :)
[14:22] <mythripk> we have identified that we were setting AVI checksum wrong that resulted in some samsung TV's not working There is a patch available for that
[14:22] <mythripk> good to hear :)
[14:23] <ogra> so we should include your patch :)
[14:24] <mythripk> that would solve the issues seen in some samsung TV's that enforce strict AVI checksum
[14:24] <ogra> great, lag can we add that ?
[14:25] <mythripk> Lag already has the patch
[14:25] <ogra> right, i just want to make sure it ends up in our tree :)
[14:54] <lag>
[14:54] <lag>
[14:54] <lag>
[14:54] <lag> Oh my word!
[14:54] <lag> Sorry about that - computer went crazy!
[14:54] <lag> I blame the OS
[14:54] <lag> Right, I've tried it on a different monitor
 Lag already has the patch: I do?
[15:05] <lag> ogra: Where's mythripk gone?
[15:25] <robclark> lag, I guess mythripk has gone home now
[15:25] <lag> np
[15:25] <lag> I'm going to try and debug it myself anyway
[15:26] <lag> Who needs expert knowledge? Pfft ...
[15:26] <lag> :)
[15:26] <robclark> heheh
[15:49] <jussi> hrm, why do these packages have {a} and {u} after them?
[15:50] <jussi> The following NEW packages will be installed:
[15:50] <jussi>   libdbus-1-dev{a} libeet-dev libeet-doc{a} libeet1{a} libhal-dev   libhal-storage-dev libjpeg62-dev{a}
[15:50] <jussi> The following packages will be REMOVED:
[15:50] <jussi>   freepats{u} gstreamer0.10-ffmpeg{u} gstreamer0.10-plugins-ugly{u}
[15:51] <hrw> {a} == automatically installed
[15:52] <hrw> as dependency for other packages
[15:53] <jussi> and {u}?
[15:56] <hrw> do not remember
[15:57] <GrueMaster> ogra: I heard my name, but am too fuzzy (ENOCOFFEE) to see what you wanted.  What can I do to help this morning?
[16:01] <lool> jussi: {a} automatically installed {u} will purge
[16:01] <lool> IIRC
[16:02] <lool> Or rather automatically uninstalled
[16:02] <lool> {up} is when they also get purged I think
[16:48] <jussi> lool: thanks. also, weird question of the day,will maemo packages work on an ubuntu install?
[16:50] <hrw> jussi: no
[16:50] <hrw> jussi: you need to recompile them
[16:50] <hrw> some of maemo5 libraries are not available in ubuntu
[16:50] <jussi> ahh
[16:51] <hrw> some are closed even
[16:51] <jussi> Im just trying to find a working "media centre" for arm jaunty - xbmc, enna, moovida etc and it seems impossible to find...
[16:51] <hrw> what hardware?
[16:52] <jussi> enna has maemo pkgs, hence the question
[16:52] <jussi> imx51 based
[16:52] <hrw> imx51... run maverick or lucid then
[16:52] <jussi> no, cant unfortunately.
[16:53] <lool> jussi: You can create a maemo chroot and run it from an Ubuntu install
[16:53] <lool> jussi: Which maemo packages do you mean specifically?
[16:54] <jussi> lool: stuff in here: http://packages.geexbox.org/pool/main/
[16:54] <lool> jussi: It might be that some binaries require opengles though
[16:55] <lool> jussi: Dunno
[16:58] <sebjan> lag: I just tested the last syslink auto-load patches, and they fail in loading the modules. I don't see the syslink_ipc event in the logs, so I suspect the omap_syslink_init function to not be called... Could you make a check please?
[16:59] <lag> Of course
[16:59] <lag> Which logs are you looking in?
[16:59] <lag> grep syslink /var/log/udev
[17:04] <lag> sebjan?
[17:04] <sebjan> lag: yes, into this log
[17:05] <lag> Okay, re-compiling now
[17:27] <ogra_cmpc> GrueMaster, we had a TI display person around and were talking about display probs, i only mentioned your name there
[17:28] <lag> sebjan:
[17:28] <lag> KERNEL[946685538.408904] add      /devices/platform/syslink_ipc (platform)
[17:28] <lag> UDEV_LOG=3
[17:28] <lag> ACTION=add
[17:28] <lag> DEVPATH=/devices/platform/syslink_ipc
[17:28] <lag> SUBSYSTEM=platform
[17:28] <lag> MODALIAS=platform:syslink_ipc
[17:29] <lag> SEQNUM=726
[17:29] <GrueMaster> ok
[17:29] <sebjan> lag: shall I understand that you get the uevent? and the modules loaded?
[17:30] <lag> No, because I have a read-only file system at the moment
[17:30] <lag> Hang on
[17:31] <sebjan> lag: at least 'dmesg | grep syslink' ouputs something (from the omap4_syslink_init function)?
[17:33] <lag> Hmmm... no?
[17:34] <lag> Perhaps I am working on stagnant logs
[17:34] <lag> I'll look into it
[17:37] <GrueMaster> lag: do we have any mainline kernels for arm?  Or do I need to pull source and build my own?
[17:38] <lag> GrueMaster: We have images in the archive
[17:38] <lag> GrueMaster: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
[17:39] <GrueMaster> I'm aware of those.  I test those.  I'm looking for a mainstream kernel package to verify bug 601226 as affecting upstream.
[17:39] <ubot2> Launchpad bug 601226 in linux-ti-omap4 (Ubuntu Maverick) (and 3 other projects) "Unable to handle kernel NULL pointer dereference in ppdev module (affects: 2) (dups: 1) (heat: 16)" [Medium,Triaged] https://launchpad.net/bugs/601226
[17:40] <ogra_cmpc> GrueMaster, there is only the TI branch for panda
[17:40] <ogra_cmpc> no mainline
[17:41] <GrueMaster> ogra_cmpc: This bug also affects Beagleboard.  I made your bug a duplicate of mine, as it is the same issue.
[17:41] <ogra_cmpc> GrueMaster, you could indeed build from the ti git tree on gitorious.org
[17:41]  * ogra_cmpc isnt sure its the same issue
[17:41] <ogra_cmpc> GrueMaster, oh, thats parport_pc ?
[17:42] <ogra_cmpc> why doesnt your report say that
[17:42] <lag> sebjan: Something strange is going on
[17:42] <GrueMaster> It did.  plars just changed it.
[17:43] <GrueMaster> And I filed my bug last week before I had an omap4 image or system.
[17:43] <sebjan> lag: sorry I need to go now, can we talk tomorrow?
[17:44] <ogra_cmpc> GrueMaster, mumble ... mine even points to the function having the issue, i dont get why he changed it
[17:44] <lag> sebjan: Of course
[17:45] <sebjan> lag: ok, talk to you tomorrow then


[17:00] <akgraner> highvoltage, will you have time for a call today?
[19:08] <akgraner> highvoltage, nhandler pleia2 nigelb Pendulum (as well as everyone else)  - Just talked to Jono about UWN - and some of the issues, not enough volunteers, etc - He is going to help promote UWN and help make the process easier etc...
[19:09] <akgraner> we went through the wiki pages and I'll be blogging later as well as email to the mailing list and some personal emails to folks
[19:11] <akgraner> Also I am concerned that maybe I have been to harsh, formal, ridged, in my expectations  - sorry about that
[19:12] <pleia2> thanks akgraner, I do worry that we'll get an influx of new volunteers that we'll find difficult to herd them, but hopefully the improvements to the docs and process will make this less of a problem :)
[19:12] <akgraner> I hope I never made anyone feel guilty or worried over no being able to help from one week to the next etc...
[19:12] <pleia2> being able to point newcomers to a doc and say "ok, you do this" is superhelpful
[19:13] <akgraner> pleia2, jono and I talked about suspending publication til December
[19:13] <akgraner> re-org'ing the docs/wiki's
[19:13] <pleia2> not a bad idea
[19:13] <akgraner> to make it easier for newcomers
[19:14] <akgraner> he also chuckled at my check list - I think it was hide that wiki from all but the publishing editors - even if it is all the steps that looks daunting
[19:14] <akgraner> (sorry about that  - I was just trying to make sure no step was over looked or not explained)
[19:16] <akgraner> also rotating publishing editors - so no one person is always the one publishing it - but having someone just over see the process incase of a bus (or fire :-D)
[19:17] <akgraner> does all that make sense to you all?
[19:17] <cody-somerville> http://en.wikipedia.org/wiki/Bus_number <-- we need to increase our bus number. :)
[19:18] <akgraner> Jono and I also talked about making it Ubuntu Newsletter and making it a bi-weekly publication
[19:18] <akgraner> I told him I would blog about it and email the team and go from there
[19:19] <akgraner> I just want everything open and transparent as possible
[19:19] <pleia2> all sounds good
[19:19] <akgraner> and newcomers know that this is an easy place to start should they choose to
[19:23] <akgraner> I need to get back to paid work for a while - but let me know if there is any input to these suggestions as I'll blog and email everyone after work
[19:23] <akgraner> Thanks y'all....:-D
[19:24] <akgraner> p.s - I'll try and remember to add all the suggestions from the blog post to the meeting agenda for December - someone poke me if I forget
[19:33] <akgraner> pleia2, nhandler et all - any reason you all can think of that Joeb454 can't just post and publish his community interviews straight to the Fridge/ubuntu-news.org
[19:34] <akgraner> with author status he can only manage his posts
[19:35] <akgraner> and it would eliminate an extra step of him posting to his blog the pleia2 reposting to the fridge
[19:35] <pleia2> we would essentially be adding him as a fridge editor, I think he should go through the process the rest of us do
[19:35] <pleia2> add him, but have one of us review them before posting
[19:35] <pleia2> for the first few posts, at least
[19:37] <akgraner> ok I'll have him ping an editor to review them :-)
[19:37] <akgraner> thanks
[21:16] <nhandler> akgraner: I also don't think it is a bad thing having them posted elsewhere first (that is how most stories are done). That way, people can choose to follow those interviews without having to subscribe to the planet/fridge
[21:16] <akgraner> he was just trying to avoid posting twice since he is now doing to other interview series
[21:17] <akgraner> two even
[21:17] <akgraner> he just wanted to make sure they made it to the planet - this would also keep an editor from have to copy it all over - that's all :-)
[21:18] <nhandler> Well, I have no objections to him getting access (after some training), but I would still be in favor of posting them on both blogs
[21:19] <akgraner> as the goal of the new site was to allow for content posted to Fridge by trusted sources - I was thinking it would be a great test case for the contributor and author users
[21:19] <akgraner> since we are trying to make it easier for people to contribute :-)
[21:20] <pleia2> I'd say it's ultimately up to Joe, we don't want to steal his interview series if he wants them on his blog
[21:20] <pleia2> but if is goal has always just been to get them to planet, cool
[21:21] <akgraner> yep he asked me if that was ok...which is why I posted the question earlier
[22:17] <nhandler> akgraner: Well, even if we are a portal with a dedicated box that pulls the latest interview (do you think that might be useful?), I would still like the original version to be on his blog (but that is just my opinion). Like I said, I have no issue with him getting access after training to do the reposting himself if he wants
[22:17] <nhandler> And if he is interested, I have no problem mentoring him (I've worked with him before)
[22:30] <akgraner> it's not a big deal either way :-)
[22:30] <nhandler> Yep
[22:31] <akgraner> he's cool with posting in both places as well as poping in the channel and pinging an editor to review his posts


[13:28] <rivimey> Using netplan, I need to add specific IP addresses when ppp0 connects. Is there an equivalent to 'ip-up' in network scripts?
[13:31] <rivimey> alternatively, can networkd be told to do something like that directly?
[13:35] <slyon> rivimey: netplan doesn't support hooks natively. But you can instruct networkd-dispatcher to do it for you: https://netplan.io/faq/#use-pre-up%2C-post-up%2C-etc.-hook-scripts
[13:35] <rivimey> Thanks
[13:36] <rivimey> I wish it supported (at least to some degree) ppp connections, such as mine over pppoe :-)
[13:59] <slyon> yes, that'd be the proper solution to this problem. We have a whishlist item for this feature: https://bugs.launchpad.net/netplan/+bug/1769034


[04:17] <mup> Bug #1870042 changed: maas network connectivity check fails <MAAS:Expired> <https://launchpad.net/bugs/1870042>
[04:23] <mup> Bug #1870042 opened: maas network connectivity check fails <MAAS:Expired> <https://launchpad.net/bugs/1870042>
[04:29] <mup> Bug #1870042 changed: maas network connectivity check fails <MAAS:Expired> <https://launchpad.net/bugs/1870042>
[04:38] <mup> Bug #1870042 opened: maas network connectivity check fails <MAAS:Expired> <https://launchpad.net/bugs/1870042>
[04:41] <mup> Bug #1870042 changed: maas network connectivity check fails <MAAS:Expired> <https://launchpad.net/bugs/1870042>
[08:56] <mup> Bug #1881547 opened: pxe power on <MAAS:New> <https://launchpad.net/bugs/1881547>
[08:59] <mup> Bug #1881547 changed: pxe power on <MAAS:New> <https://launchpad.net/bugs/1881547>
[09:05] <mup> Bug #1881547 opened: pxe power on <MAAS:New> <https://launchpad.net/bugs/1881547>
[09:57] <mup> Bug #1881555 opened: UI stuck in error state after error loading machine <ui> <MAAS:New> <https://launchpad.net/bugs/1881555>
[10:12] <mup> Bug #1881203 changed: SnapStore and Snap Blocks Install more Apps  <MAAS:Invalid> <https://launchpad.net/bugs/1881203>
[10:15] <mup> Bug #1881203 opened: SnapStore and Snap Blocks Install more Apps  <MAAS:Invalid> <https://launchpad.net/bugs/1881203>
[10:21] <mup> Bug #1881203 changed: SnapStore and Snap Blocks Install more Apps  <MAAS:Invalid> <https://launchpad.net/bugs/1881203>
[10:24] <mup> Bug #1881203 opened: SnapStore and Snap Blocks Install more Apps  <MAAS:Invalid> <https://launchpad.net/bugs/1881203>
[10:27] <mup> Bug #1881203 changed: SnapStore and Snap Blocks Install more Apps  <MAAS:Invalid> <https://launchpad.net/bugs/1881203>
[10:27] <mup> Bug #1881560 opened: Poor UX for adding machine that's network booted into MAAS <ui> <MAAS:New> <https://launchpad.net/bugs/1881560>
[10:33] <mup> Bug #1881560 changed: Poor UX for adding machine that's network booted into MAAS <ui> <MAAS:New> <https://launchpad.net/bugs/1881560>
[10:33] <mup> Bug #1881203 opened: SnapStore and Snap Blocks Install more Apps  <MAAS:Invalid> <https://launchpad.net/bugs/1881203>
[10:36] <mup> Bug #1881203 changed: SnapStore and Snap Blocks Install more Apps  <MAAS:Invalid> <https://launchpad.net/bugs/1881203>
[10:36] <mup> Bug #1881560 opened: Poor UX for adding machine that's network booted into MAAS <ui> <MAAS:New> <https://launchpad.net/bugs/1881560>
[11:06] <mup> Bug #1881577 opened: Conflict error when MAAS tries to add user with same email address <MAAS:New> <https://launchpad.net/bugs/1881577>
[13:12] <mup> Bug #1881595 opened: RBAC denial of machine deployment considered lacklustre <MAAS:New> <https://launchpad.net/bugs/1881595>
[13:15] <mup> Bug #1881595 changed: RBAC denial of machine deployment considered lacklustre <MAAS:New> <https://launchpad.net/bugs/1881595>
[13:18] <mup> Bug #1881595 opened: RBAC denial of machine deployment considered lacklustre <MAAS:New> <https://launchpad.net/bugs/1881595>
[13:21] <mup> Bug #1881595 changed: RBAC denial of machine deployment considered lacklustre <MAAS:New> <https://launchpad.net/bugs/1881595>
[13:24] <mup> Bug #1881595 opened: RBAC denial of machine deployment considered lacklustre <MAAS:New> <https://launchpad.net/bugs/1881595>
[15:59] <d0ugal> ltrager: also here :)
[17:45] <mup> Bug #1878311 changed: Power and Pod drivers need way to accept private keys and certificates <ui> <MAAS:Invalid by ltrager> <https://launchpad.net/bugs/1878311>
[17:57] <mup> Bug #1878311 opened: Power and Pod drivers need way to accept private keys and certificates <ui> <MAAS:Invalid by ltrager> <https://launchpad.net/bugs/1878311>
[18:00] <mup> Bug #1878311 changed: Power and Pod drivers need way to accept private keys and certificates <ui> <MAAS:Invalid by ltrager> <https://launchpad.net/bugs/1878311>
[20:18] <mup> Bug #1881655 opened: Can't deploy focal KVM hosts <MAAS:New> <https://launchpad.net/bugs/1881655>
[21:00] <mup> Bug #1881663 opened: Unable to have two devices with same names but different domains <MAAS:New> <https://launchpad.net/bugs/1881663>
[21:06] <mup> Bug #1881663 changed: Unable to have two devices with same names but different domains <MAAS:New> <https://launchpad.net/bugs/1881663>
[21:12] <mup> Bug #1881663 opened: Unable to have two devices with same names but different domains <MAAS:New> <https://launchpad.net/bugs/1881663>
[21:15] <mup> Bug #1881663 changed: Unable to have two devices with same names but different domains <MAAS:New> <https://launchpad.net/bugs/1881663>
[21:18] <mup> Bug #1881663 opened: Unable to have two devices with same names but different domains <MAAS:New> <https://launchpad.net/bugs/1881663>
[21:21] <mup> Bug #1881664 opened: Support multiple device types <MAAS:New> <https://launchpad.net/bugs/1881664>
[21:21] <mup> Bug #1881665 opened: Machine-specific token for use to create devices <MAAS:New> <https://launchpad.net/bugs/1881665>


[03:34] <bvb> Well, I ended up using the 2.6.35 maverick build, and I've got vga_switcheroo running nicely or else lying to me. I was wondering, though: from reading through the wiki, it appears that the 'mainline' builds do not have the Ubuntu modifications. Would that be why the boot splash doesn't show up, or did I break something else? Also, any thoughts on what that kernel would do to a Synaptics touchpad?
[03:37] <RAOF> bvb: Mainline builds do not have the Ubuntu sauce, yes.  This shouldn't prevent the boot splash from showing up; that's likely to be configuration problems.
[03:40] <bvb> RAOF: OK, that's what I thought. I guess I'll poke around and see if I did something else to the boot splash ... although I may end up just waiting for the "official" build next month, as I'm about to start school and the thing works just fine otherwise.
[09:07] <ericm|ubuntu> lag, regarding 601226, any update on a suitable patch being upstreamed?
[09:55] <ericm|ubuntu> lag, ping
[14:46] <hallyn> asking here bc i don't know particularly where else to start - if i run a lucid livecd .iso in kvm -with '-vga cirrus' and play solitaire, it works fine.  With maverick, it hangs almost immediately.  Anyone know which driver to look at for regressions?  (both are on the same maverick host, so it may be kvm bug, but some kernel driver change seems to be triggering it in any case)
[14:47] <hallyn> it's making testdrive of maverick images pretty much unusable...
[15:00] <tgardner> hallyn, just ran a maverick daily on a lucid host (but I didn't specify a -vga option)
[15:07] <hallyn> tgardner: it only happens from a livecd (once it's installed it's fine), and only with -vga cirrus.  and i guess it may just be a memory thing, bc with 1G ram tossed at the VM, it's still going after awhile
[15:08] <tgardner> hallyn, the default is 386MB right?
[15:08] <hallyn> but really, 356M should be enough !
[15:08] <tgardner> 384*
[15:08] <hallyn> tgardner: yeah
[15:09] <hallyn> tgardner: at least, in testdrive, which is how i ran into it again
[15:09] <tgardner> hallyn, how are you passing the -vga option? Lucid testdrive doesn't like it as a CL option
[15:09] <hallyn> (mind you, there was an old bug about this, and I guess it fell off the radar bc i must usually not use cirrus)
[15:09] <hallyn> hm
[15:10] <hallyn> just as '-vga cirrus' at the end of the cmdline
[15:10] <hallyn> my whole cmdline:
[15:10] <hallyn> kvm -m 384 -smp 2 -cdrom /home/serge/.cache/testdrive/iso/ubuntu_maverick-desktop-i386.iso -drive file=delme.img,if=virtio,cache=writeback,index=0 -boot d -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
[15:11] <tgardner> oh, you're running kvm directly.
[15:11] <tgardner> lemma see if it faults on a Lucid host
[15:13] <hallyn> tgardner: it's rough, i know, but the most reliable way to reproduce is to pull up games->solitaire and move cards aroudn really fast
[15:14] <tgardner> ah, so it actually boots up OK, but doesn't wedge until you start messing with it
[15:17] <hallyn> tgardner: right
[15:18] <tgardner> well, at least its really freaking slow with 384M
[15:18] <hallyn> becoming more and more convinced it's just a memory leak.  This time i got it to kill the window manager, then restart it but in a very messed-up state
[15:20] <tgardner> hallyn, do you have sufficient network on the guest that you can ssh in and look at slab info?
[15:23] <tgardner> hallyn, oh yeah, sudden death when just starting solitaire.
[15:24] <hallyn> tgardner: i can try that
[15:27] <hallyn> tgardner: lol, no sshd on liveiso
[15:28] <tgardner> hallyn, what a PITA
[15:28] <hallyn> yup
[15:30] <hallyn> tgardner: fwiw the bug where i first saw this was https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/595427
[15:30] <ubot2> Launchpad bug 595427 in qemu-kvm (Ubuntu) "VM locks up, vmsvga_fifo_run: Unknown command 0xffffff in SVGA command FIFO (affects: 3) (heat: 58)" [Medium,Confirmed]
[15:32] <tgardner> hallyn, so, you could go ahead and install using 1GB RAM, then reboot with 384M on the kernel command line (after installing openssh-server) in order to watch slabinfo
[15:33] <hallyn> tgardner: no, the problem is that only the liveiso does it
[15:34] <tgardner> I just saw that in the bug report
[15:34] <hallyn> now, maybe that's bc the liveiso is dd'd to ram so we really have even less ram available?
[15:34] <tgardner> thas curious
[15:34] <hallyn> yup
[15:39] <tgardner> hallyn, I'll bet that would eventually happen on an installed KVM instance. It likely just takes a lot longer because there is a swap partition.
[15:50] <hallyn> tgardner: all right, lemme test that with swapoff...  i won't have results until after lunch break though
[15:50] <hallyn> tgardner: but that would be intresting.  hadn't thought of that
[15:53] <tgardner> hallyn, ack
[16:23] <ogasawara> JFo: just wanted to do a quick check for open maverick beta work items...
[16:23] <JFo> k
[16:23] <ogasawara> JFo: kernel-maverick-bug-handling - "Kernel Triage Summit: set schedule and communicate to all involved" ... I assume an announcement will go out relatively soon?
[16:24] <JFo> hmmm, should have already, but I think that was during the time I was having issues sending mail from my old laptop
[16:24] <JFo> will send again today
[16:24] <JFo> sorry about that :-/
[16:24] <ogasawara> JFo: cool, no worries.  mark er DONE after you send.
[16:25] <ogasawara> JFo: also, kernel-maverick-tracing-support - "Arsenal scripts for common ftrace uses" ... should I postpone that one or will you have time to get to it this cycle?
[16:26] <JFo> will do
[16:26] <JFo> not sure about the ftrace stuff
[16:26] <JFo> I have what I need
[16:26] <JFo> but I am not sure I'll get it done this cycle
[16:26] <JFo> that will probably be best set to postponed
[16:27] <JFo> I'll mark it such
[16:27] <ogasawara> JFo: k sounds good as it seems you have a pretty full plate looking at your remaining work items.
[16:27] <JFo> yeah, tons of stuff in the wings
[16:33] <ogasawara> jjohansen: I'm going to remove the kernel-maverick-apparmor blueprint from the weekly IRC meeting agenda, as you've finished all the work items.
[16:34] <ogasawara> jjohansen: same for the kernel-maverick-pv-ops-ec2-kernel blueprint.
[16:57] <jjohansen> ogasawara: thanks
[17:00] <smb> JFo, bug call?
[17:00] <JFo> indeed
[17:00] <JFo> 1 moment
[17:10] <ogra> argh ...
[17:10] <ogra> tgardner, please make sure nobody accepts the omap4 kernel ... we dont have any bootloader support for ES2.0 hardware at all, it needs to wait until after beta
[17:11] <tgardner> ogra, well, its still pending awaiting archive love. how do I make sure its not accepted?
[17:12] <ogra> just dont say yes if any release manager asks you about it .... :)
[17:21] <tgardner> ogra, it generally just happens without any interaction from me
[17:22] <ogra> hmm
[17:26] <ogra> i wonder if its safet to reject the upload then and keep away from it until after beta ...
[17:26] <ogra> if the new binary ends up in the images we're screwed
[17:26] <ogra> *safer
[17:26] <tgardner> ogra, maybe slangasek will help you.
[17:37] <ogra> tgardner, would you be very unhappy if you had to upload it again after beta ?
[17:38] <tgardner> ogra, no problem. it only takes a few minutes.
[17:38] <ogra> seems there is no way to tag a package for all release managers to not accept it, the safest is to reject the package, but that requires a new upload
[17:38] <ogra> ok
[19:12]  * tgardner lunches
[19:45] <hallyn> tgardner: installing, running with -m 384, doing swapoff, I'm not reproducing the hang
[19:46] <tgardner> hallyn, dang
[19:47] <hallyn> if i move a card really fast it'll hang for a half second, but that's it.  I suppose I can just keep cranking down the ram, but...
[19:48] <JFo> <-lunch finally...
[20:25] <sconklin> JFo: five boxes of hardware on the way to you
[20:25] <JFo> yep, I got the tracking numbers earlier :-)
[20:26] <sconklin> I just dropped them off
[20:26] <JFo> cool
[20:26] <JFo> what all is there?
[20:27] <sconklin> For some reason, the fedex account would only let me schedule a pickup in London, and that wasn't going to work for me :)
[20:27] <JFo> heh
[20:31]  * jjohansen -> lunch
[21:08] <jcrigby> tgardner, who can I beg to approve the linux-linaro kernel that you uploaded this morning?
[21:09] <jcrigby> tgardner, we would like to build a beta rc tomorrow
[21:09] <tgardner> jcrigby, hang on, I'm looking for the archive admin schedule
[21:09] <jcrigby> tgardner, thx
[21:10] <tgardner> https://wiki.ubuntu.com/ArchiveAdministration#Archive days
[21:10] <tgardner> jcrigby, so, being Monday, I'd say slangasek could help out
[21:10] <jcrigby> doh!
[21:11] <tgardner> assuming that schedule is still accurate
[21:20] <slangasek> tgardner: unapproved queue is the responsibility of the release team, not the archive team; but conveniently it's cold outside today so I'm wearing both hats
[21:21] <tgardner> slangasek, hmm, that is a fine distinction that is utterly lost on this poor kernel developer
[22:30] <sconklin> does anyone know which package supplies the git_lib python module? It's imported in one of Stefan's scripts and I can't find it
[22:31] <tgardner> no clues here
[22:41] <jjohansen> sconklin: python-git I think
[22:41] <sconklin> jjohansen: I installed that but no go.
[22:42] <sconklin> it's ok, it;s time to stop for the day anyway and I'll ask Stefan tomorrow. - thanks!
[22:42] <jjohansen> hrmmm, -enoclue
[23:09] <jcrigby> tgardner, if we wanted to produce multiple linux-linaro source packages so we could get parallel builds.  Would I have separate git trees that are identical except for flavour or would you want some script that tweeked the source and ran debuild -S n times?


[00:58] <cjwatson> xnox: Almost anything is more straightforward than that
[01:22] <wgrant> xnox: Oh, nice, WSGIProxy is exactly what I thought we'd have to implement.
[03:40] <pitti> Good morning
[03:41] <Unit193> Howdy, pitti.
[03:41] <RAOF> pitti: Aloha!
[03:42] <pitti> RAOF: ah, I forgot to check again yesterday
[03:42] <pitti> RAOF: so, it built fine
[03:42] <pitti> RAOF: it took over 2 hours, and at some point it just dropped off my brain
[03:42] <pitti> RAOF: do you want the debs/log/etc., or is "it builds" enough?
[03:42] <RAOF> It builds is good for me.
[03:43] <RAOF> Let me push a tag for you to upload.
[03:54] <RAOF> pitti: debian/1.2.1-1 should be good to go to unstable. Let's get this transition on the road!
[03:54] <pitti> RAOF: ah, soname bump?
[03:55] <pitti> RAOF: hm, gbp-pull gives me nothing new
[03:55] <RAOF> To git+ssh://git.debian.org/git/collab-maint/colord
[03:55] <RAOF>    3045b6b..3719f1b  master -> master
[03:55] <RAOF>  * [new tag]         debian/1.2.1-1 -> debian/1.2.1-1
[03:56] <pitti> ok, so I was just blind, or gbp-pull didn't show me the new tag
[03:56] <RAOF> pitti: Yeah, a bunch of deprecated symbols got dropped in the 1.2 series, making it libcolord2 et al.
[04:02] <pitti> RAOF: quite impressive that on my box creating a profile takes ~ 20 seconds where on mips it takes about half an hour; I wasn't aware that these mips boxes were *that* slow..
[04:04] <RAOF> It turns out that you can do a lot of computation with billions of transistors!
[04:08] <infinity> pitti: Which mips box is that?
[04:08] <pitti> infinity: gabrielli.debian.org (the porter box)
[04:08] <infinity> pitti: The Cavium machine is pretty peppy, except for crappy I/O.
[04:08] <pitti> ah, I stopped at the first "mips porterbox" on the db.d.o. page
[04:08] <infinity> pitti: And gabrielli is the machine I was thinking of.
[04:08] <infinity> pitti: Maybe I only think it's peppy, cause I build with -j16
[04:09] <pitti> infinity: I built with -j8, but doesn't help much with colord as it doesn't parallelize the calculation
[04:09] <infinity> The individual cores certainly aren't screamers (they're not meant to be, it's essentially a switch in a desktop case)
[04:09] <pitti> it has 16 cores
[04:09] <RAOF> infinity: Yeah, profile generation is explicitly serial, as each profile takes over a GiB of memory to compute.
[04:09] <pitti> infinity: yeah, I used to have one of these d-link linux routers, they were quite nice to hack on
[04:09] <infinity> RAOF: Ow.
[04:10] <pitti> RAOF: uploaded
[04:10] <RAOF> So the relevant performance indicator is IPC :)
[04:10] <RAOF> Times clockspeed, obviously.
[04:10] <RAOF> pitti: Much ta.
[04:11] <infinity> pitti: I'd love someone to talk me into doing an Ubuntu MIPS port some day, but we'd need a whole lot of gabrielli-sized machines to make it go, I suspect.
[04:11] <infinity> At least, to provide the same SLA people are currently used to in LP and whine about when it degrades. :P
[04:11] <RAOF> Virtualise it on prodstack! :P
[04:12] <pitti> the internet of ubuntus!
[04:13]  * RAOF loves how his copyright line doesn't fit in 80 characters
[04:20] <infinity> RAOF: Get a shorter name.
[04:49] <Noskcaj> Can someone please review https://code.launchpad.net/~noskcaj/libgweather/3.12.2
[05:00] <Noskcaj> cjwatson, Mind if i take the unzip merge?
[06:12] <dpm> hi wgrant, pitti is currently working on generating utopic langpacks for the phone, but as per the schedule we set up in LP, the next export is not due until Wednesday next week. In order not to have to wait until then, would it be possible to run a one-off export of translations for utopic today?
[06:13] <dpm> We've done this in the past, e.g. when we needed exports outside of the crontab for a release, but I don't know the procedure for requesting these nowadays
[06:15] <pitti> hey dpm
[06:16] <dpm> morning pitti :)
[06:16] <pitti> dpm: I refined the script to calculate source packages shipped on touch now, just committed to langpack-o-matic; now I'll work on generating langpacks based on that
[06:16] <dpm> excellent!
[06:16] <pitti> dpm: I think we don't do the -base/update split for touch
[06:17] <pitti> it makes little sense with image based updates
[06:17] <dpm> yes, I agree
[06:17] <dpm> pitti, do we have to change all universe packages in the list to be imported to LP? Can we determine beforehand which ones we need to import translations for?
[06:18] <pitti> dpm: not necessary for building langpacks; they'll just contain the bits from main and with X-Use-Ubuntu-Langpacks (or whatever that magic key was)
[06:19] <pitti> dpm: I suppose we could download all binaries from that pastebin, check if they have anything in /usr/share/locale; all which have mo files are candiates for importing
[06:22] <dpm> pitti, yes, but ultimately to have meaningful langpacks, well need the X-Use-Ubuntu-Langpacks (can't remember the exact name, either :) for their .mo files to be in the export to be fed to langpack-o-matic. So at some point, we'll either have to mark all the universe ones with X-Use-Ubuntu-Langpacks or do an initial filtering (e.g. with your latest suggestion) and only mark those that make sense to be imported
[06:23] <pitti> right
[06:23] <pitti> dpm: but then we should also strip them
[06:23] <pitti> otherwise langpacks wouldn't have much effect
[06:24] <pitti> (only for new languages)
[06:24] <dpm> pitti, yes, but that's what X-Use-Ubuntu-Langpacks does already, IIRC - it strips them, imports the translations and then LP exports those
[06:25] <dpm> or were you suggesting something else?
[06:25] <pitti> dpm: ah right, just checked; I thought we also had something like "export translation tarballs, but don't strip"
[06:26] <pitti> but I think we export tarballs for all builds
[06:26] <dpm> pitti, ah, no, I don't think we have a "don't strip" option
[06:27] <dpm> pitti, what do you mean by "all builds" in this context?
[06:28] <pitti> dpm: I mean, I think we export _translations.tar.gz for all universe packages, we just don't strip them or export them from LP
[06:29] <dpm> pitti, ah, I didn't know that. Where are these universe translations tarballs exported to?
[06:30] <pitti> dpm: to LP translations, as usual
[06:32] <dpm> oh, you mean they're generated as part of the package build, right? So you're saying you could use that to feed to langpack-o-matic instead of the big weekly Launchpad export?
[06:33] <pitti> dpm: no, not at all; I'm saying we merely need to mark these packages as X-Use-Ubuntu-Langpacks:, and it should be all good then
[06:33] <dpm> ok, gotcha
[06:34] <pitti> dpm: so your web app shows that we have some 20 languages with coverage >= 70%; that might be a good set to start with?
[06:35] <dpm> pitti, yeah, once we get this up and running, I think I'd like to set the percentage to 80 or even 90%, but right now, 70% should be good to initially get some more languages in. Can langpack-o-matic do this calculation and filtering based on coverage %?
[06:36] <pitti> dpm: not at the moment, but I'll teach it
[06:36] <dpm> :)
[06:36] <pitti> dpm: not that simple to get the absolute number of translatable strings though, so it might need some handholding
[06:37] <pitti> dpm: i. e. if I just look at a set of .po files, then I don't see the ones which don't have any translations at all
[06:37] <pitti> dpm: I suppose your web app compares with the .pots ?
[06:39] <dpm> pitti, yes, I use the .pots to get the total, but currently all apps in that list are checked out to a local branch to calculate the stats, so I have access to the .pot files. However, langpack-o-matic could have some other options if it cannot access the .pot files directly
[06:40] <pitti> dpm: I need to check whether the LP exports contain the pots
[06:40] <dpm> - Read the template stats from the daily LP translations data dump in JSON at http://people.canonical.com/~dpm/data/ubuntu-l10n/
[06:41] <dpm> - Use the LP Translations API - It's not complete, but the templates part is available. I can't recall if it does more than just listing template names per source package, though
[06:41] <pitti> dpm: ah, nice
[06:41] <pitti> dpm: i. e. in http://people.canonical.com/~dpm/data/ubuntu-l10n/trusty-potemplate-stats.json
[06:41] <dpm> pitti, exactly
[06:41] <pitti> dpm: that would mean that accounts-service has 10 translatable strings?
[06:42] <dpm> I've got an RT open to get the utopic stats
[06:42] <pitti> and apt 624
[06:42] <dpm> pitti, indeed
[06:42] <pitti> ok
[06:42] <pitti> dpm: so the stats will be skewed a bit as we ship e. g. apt and gdb on the phone although they aren't "visible"
[06:43] <pitti> dpm: implementing that will take some time, perhaps we start with a fixed list of language codes
[06:43] <pitti> based on your web app
[06:43] <pitti> it won't change every other week anyway
[06:43] <dpm> +1
[06:44] <wgrant> dpm, pitti: Export is running.
[06:44] <pitti> wgrant: cheers
[06:45] <dpm> awesome, thanks wgrant
[06:45] <debfx> ScottK, Laney: do we still need to enforce that trusty->precise backports end up in saucy too? is precise->saucy a supported upgrade path?
[06:46] <dpm> pitti, I'd use only the totals for the packages that we're considering as part of the UI. I've ran my stats webapp for source packages to calculate the distro translation coverage in the past, and I use the "priority" field to determine if it's a template whose translations are visible. E.g. anything with a priority <= 100 I'm not counting towards the total number of strings
[06:47] <dpm> and those priorities are set in LP, generally I go through the templates when we open translations and set them all up and tweak them afterwards if needed
[06:48] <dpm> pitti, a third option would be for me to add an API to my web stats to return the language coverage for each language
[06:48] <dpm> s/language/translation/ coverage
[06:56] <pitti> dpm: downloading a single .json file sounds fine to me
[06:58] <dholbach> good morning
[06:58] <dpm> pitti, yes, whatever works best for you. I've also checked that you can get the string count from the LP API, so just to confirm, this is also an option you could use. https://launchpad.net/+apidoc/devel.html#translation_template
[06:58] <dpm> "message_count"
[08:16] <mitya57> Mirv: Good to know that!
[08:16] <Laney> debfx: nope, indeed not
[09:00] <cjwatson> Noskcaj: Would prefer to do it myself, thanks.
[09:00] <Noskcaj> ok. I'll cancel my merge proposal then
[09:01] <cjwatson> In general I don't need help with my merges unless explicitly requested
[09:02] <Noskcaj> ok
[09:03] <infinity> doko: Did you see my binutils ping?  You dropped my delta from http://launchpadlibrarian.net/173790298/binutils_<IP_ADDRESS>40425-0ubuntu1_<IP_ADDRESS>40425-0ubuntu2.diff.gz
[09:04] <infinity> doko: Which is why the lintian testsuite is failing again.
[09:04] <infinity> doko: You may also have dropped it from Debian, I didn't check.
[09:05] <doko> infinity, ouch. will reapply it
[09:06] <infinity> doko: Ta.
[09:07] <infinity> doko: Should probably add an autopkgtest that does the same thing as the lintian test (attempt to link -lm to a simple test program using ld directly) to make sure it doesn't regress.
[09:10] <ogra_> xnox, seeing your mail exchange with janimo ... didnt we say the non RTM devices will keep loop mounting ? so for these a proper image name definitely makes sense
[11:19] <pitti> infinity, cjwatson: do you know, do we still need pre-depends: for packages using xz compression? (it's the default now, but I'm also wondering about precise)
[11:19] <pitti> ${misc:Pre-Depends} ought to take care of that?
[11:20] <cjwatson> I think it was lucid-to-precise updates that needed that
[11:21] <pitti> ok, thanks; these days dpkg doesn't generate any misc:Pre-Depends, but I guess it can't hurt to add it anyways
[11:21] <pitti> context: langpack builds (so far they've been using bzip2, but that's now marked as deprecated)
[11:21] <cjwatson> dpkg wouldn't anyway, it was debhelper
[11:22] <cjwatson> I think it dropped them a little while back
[11:22] <cjwatson> But yeah, for anything at all recent there's no need to keep them now
[11:22] <pitti> ack, thanks
[11:22] <cjwatson> Maybe for precise it's simplest to leave them as bz2
[11:24] <pitti> I just tested it under precise, seems to work just fine
[11:24] <pitti> build/install/lintian/etc.
[11:24] <infinity> lucid didn't support xz.
[11:24] <infinity> So the pre-depends is needed on packages in precise.
[11:24] <infinity> It's not needed in trusty.
[11:25] <infinity> pitti: ^
[11:25] <pitti> infinity: thanks
[11:28] <cjwatson> Right, even for packages in -updates, because otherwise we break lucid-to-precise upgrades which will likely have -updates enabled during the upgrade.
[11:28] <cjwatson> If dh_installdeb or whatever it was DTRT in precise then ${misc:Pre-Depends} would be simple enough.
[11:29] <pitti> no, it doesn't seem to do that, it just sets it to empty
[11:30] <pitti> so I bumped the existing manual pre-dep now
[11:30] <cjwatson> I guess it can't know since the compression method is set in options to dh_builddeb, which is too late to do anything to the control file.
[11:35] <dpm_> pitti, it seems that the langpack export was pretty quick this time. We've now got the first full langpack available at: https://translations.launchpad.net/ubuntu/utopic/+language-packs :)
[11:35] <pitti> dpm_: oh, wow! that's just the *perfect* timing
[11:35] <dpm_> :)
[11:35] <pitti> dpm_: I just started downloading the latest trusty langpack for testing my recent langpack-o-matic stuff on real data :)
[11:36] <dpm_> aha!
[11:36] <pitti> (so far I've just written test cases with the mini-tarballs in tests/)
[11:36] <pitti> dpm_: cool, so utopic langpack time, too :)
[11:36] <dpm_> \o/
[11:37] <pitti> wgrant: and yes, that was mighty fast -- whatever you did, rock!
[11:42] <pitti> ouch -- the whole unpack and import of the full translation tarball takes ~ 15 s on my machine, ~ 2 h on germanium; yay tmpfs..
[11:44] <pitti> dpm_: http://paste.ubuntu.com/7594256/
[11:45] <pitti> ogra_: ^ FYI: first iteration of -touch langpack is ~ 800 kB for German (which should have fairly good coverage), whereas the regular langpack is 3.6 (not including -gnome)
[11:45] <pitti> 3.6 MB, I mean
[11:45] <ogra_> wheee !!!!
[11:45]  * ogra_ hugs pitti
[11:46] <pitti> ogra_: and dpm determined we'll need some 20 or so (all languages with >= 70% coverage)
[11:46] <ogra_> well, as many as we can ship ...
[11:47] <ogra_> but that will reduce our size massively ... awesome news
[11:49] <pitti> ogra_: there's still room for optimization here -- e. g. this ships translations for gdb, apt, etc. (see http://paste.ubuntu.com/7594256/)
[11:49] <pitti> and OTOH it does'n yet have many apps (we need to mark those in universe which we want to get included in langpacks and stripped)
[11:49] <pitti> but it's a first ballpark figure
[11:49] <pitti> anyway, time for lunch :)
[11:49] <dpm_> pitti, that's awesome, thanks! I think that's good for the initial ones, but do you think we could do some further filtering in the next iteration? I see things such as colord, gdebi, libgweather-locations and others that we could probably drop.
[11:49] <ogra_> ah, well, we want to get the devices in the hands of developers ...
[11:49] <ogra_> i think it makes sense to keep that stuff in for now
[11:50] <ogra_> (gdb, apt etc)
[11:50] <pitti> dpm_: yes, absolutely
[11:50] <mlankhorst> chrisccoulson: I've added a hack to the bug report in case you want to use nouveau, but I think it's too ugly to even propose it as a sru :P
[11:52] <dpm_> cool. pitti, also, could you add 'ca' to the list of langpacks generated? It's the locale I'm testing on (apart from zh_CN), but I'll make sure it gets to 70% before the stats are updated tomorrow :)
[11:52] <pitti> dpm_: I currently built all, I still need to add a --languages feature
[11:52] <dpm_> ah, perfect
[11:52] <pitti> or implement --min-coverage etc.
[11:55] <chrisccoulson> mlankhorst, oh, it doesn't support gl from more than one thread. that kinda sucks :/
[11:56] <mlankhorst> chrisccoulson: the hack I wrote probably works though :P
[11:57] <mlankhorst> but yeah I'd have to make things thread-safe in a cleaner way
[12:04] <chrisccoulson> mlankhorst, I also need to implement the missing bits to make chromium's GPU blacklist work in oxide, so that we could disable the GL compositor and webgl
[12:05] <chrisccoulson> that would mean the only thread accessing gl would be the rendering thread for the qml scenegraph
[12:05] <mlankhorst> chrisccoulson: the hack makes nouveau thread safe enough not to crash
[12:05] <chrisccoulson> but that's a fair bit of work and I was hoping not to do it yet :/
[12:05] <chrisccoulson> yeah, the issue is that it's not me with the crash (I don't have nvidia hardware)
[12:06] <mlankhorst> Laney: can you test?
[12:06] <Laney> test what?
[12:06] <mlankhorst> Laney: hack from https://bugs.launchpad.net/nouveau/+bug/1309044
[12:09] <mlankhorst> but it requires libdrm 2.4.54 first, just grab it from debian or utopic
[12:09] <Laney> i'm on utopic already
[12:09] <Laney> do you have a package?
[12:09] <mlankhorst> no, just the diff, let me build one..
[12:09] <Laney> it's okay
[12:09] <Laney> assuming it applies
[12:10] <Laney> i thought you could reproduce this yourself though
[12:10] <mlankhorst> yeah :p
[12:10] <mlankhorst> but no idea if this breaks other things or not
[12:12] <Laney> mlankhorst: erm what is this a patch to? :(
[12:13] <mlankhorst> mesa
[12:13] <mlankhorst> but I'm upgrading my chroot, just give me a bit
[12:14] <Laney> it's okay, building now
[12:18] <pete-woods> sil2100: hi, I've done the testing for the HUD stuff in silo #9, I don't think and landing folks want to hit the publish button, though, because the status still makes it look like the build failed
[12:22] <Laney> mlankhorst: trying ...
[12:24] <chrisccoulson> mlankhorst, is there an easy, reliable way to detect that nouveau is being used?
[12:24] <mlankhorst> yes, but I would rather not add blacklists
[12:25] <sil2100> pete-woods: hey! Let me take a look at that, maybe it needs a small push from our side
[12:26] <chrisccoulson> mlankhorst, as a stop-gap, making the webbrowser-app abort is probably better than the whole machine locking up :)
[12:26] <mlankhorst> chrisccoulson: though in that case I would prefer only adding certain nouveau versions, not blacklist newer nouveau entirely
[12:27] <Laney> mlankhorst: I had some weird flickering when I logged in
[12:27] <Laney> WHAT HAVE YOU DONE
[12:28] <mlankhorst> no idea
[12:28] <Laney> actually I have it all the time
[12:28] <mlankhorst> yeah I've noticed, no idea about it yet :/
[12:28] <Laney> haha
[12:28] <Laney> why did you get me to run it if you knew?
[12:28] <mlankhorst> might be that flush I removed on swapbuffers, but hey i told you it was hacky :P
[12:28] <Laney> oh god
[12:28]  * Laney babbles
[12:40] <pete-woods> sil2100: thanks :)
[13:05] <jdstrand> jamesh: hey, for bug #1303962, does this policy look reasonable:
[13:05] <jdstrand> # Allow communications with mediascanner2
[13:05] <jdstrand> dbus (send)
[13:05] <jdstrand>      bus=session
[13:05] <jdstrand>      path=/com/canonical/MediaScanner2{,/**},
[13:05] <ScottK> debfx: I'd say no.
[13:06] <jdstrand> the {,/**} specifies an alternation such that both path=/com/canonical/MediaScanner2 and path=/com/canonical/MediaScanner2/<something else> matches
[13:12] <pitti> ogra_: TBH, repeating where things changed in the changelog seems pretty obsolete to me; after all, that's all in the individual commits?
[13:12] <pitti> ogra_: of course, the commit logs need to be useful; i. e. explain *why* something was done, not just *how*
[13:13] <ogra_> pitti, i just want somethig descriptive so that one of the landers can understand the change
[13:13] <pitti> ogra_: yeah, summaries still help to find affected packages, of course; but I think having all the details in debian/changelog is too noisy
[13:13] <ogra_> ist fine to have a caption referring to the feature across the ten packages it spans
[13:13] <pitti> ogra_: or did you actually mean bzr changelogs?
[13:14] <pitti> if these suck, then yes, big fail
[13:14] <ogra_> pitti, i mean debian changelogs ...
[13:14] <pitti> (but they always implicitly have the "where")
[13:14] <ogra_> well, bzr changelogs are usually not much better
[13:14] <ogra_> the debian changelog is assembled from them in CI
[13:15] <pitti> ogra_: ah right, with CI train debian changelog == MP "commit changelog", meh
[13:15] <ogra_> pitti, my mail is more towards the upstream devs that arent familiar with packaging ... i havent seen malformed changelogs from experienced packagers yet
[13:16] <ogra_> if your MP commit mesage only says "hey, new feature added !!!! i rock" ... thats not helpful
[13:16] <pitti> ogra_: heh, I don't think it's inherently related to packaging; more like "did that developer ever have to go through the pain of researching commits from some years ago" :)
[13:16] <pitti> yes
[13:16] <pitti> so in git terms, the one-line summary should be in the debian/changelog, the detailled 20-line description shouldn't
[13:17] <pitti> but right, we don't have the detailled 20-line description with our approach (at most in the individual commits of each merge)
[13:19] <ogra_> well, even a *proper* one liner would help
[13:20] <ogra_> most of the time its not even that
[13:25] <jamesh> jdstrand: currently everything is hanging off a single object path, so the /** bit isn't strictly necessary.  You could also lock it down by the interface name too if you want.
[13:26] <jamesh> jdstrand: it looks like that policy would work though.
[13:32] <jdstrand> jamesh: I'll lock it down more like you said. if we need to refine, it is easy enough to do
[13:32] <jdstrand> jamesh: thanks!
[13:35] <shadeslayer> pitti: wut https://jenkins.qa.ubuntu.com/job/utopic-adt-kapptemplate/3/console
[13:36] <mlankhorst> Laney: so no crashes then?
[13:36] <Laney> mlankhorst: it didn't crash
[13:36] <mlankhorst> :D
[13:36] <Laney> but
[13:36] <Laney> I couldn't really interact with it
[13:36] <mlankhorst> why?
[13:36] <Laney> because it was flickering so much
[13:37] <mlankhorst> ai
[13:37] <mlankhorst> ok so needs more thought then
[13:50] <pitti> shadeslayer: yep, will restart; we had to reboot the ppc64el boxes, and jenkins as the pain that it is vomits on that for the x86 boxes too
[13:50] <shadeslayer> heh
[13:51] <pitti> this affected some 5 other tests too, all restarted now
[13:51] <Laney> is that why I got a failure for a test which actually passed?
[13:51] <pitti> le sigh, *want jenkins go away*
[13:51] <pitti> Laney: yes
[13:52] <Laney> nod
[14:14] <xnox> pitti: not only i get shutdown-hang, a basic lxc container fails to boot as well *sigh*
[14:15] <pitti> xnox: darn; the code looks rather correct to me, so I guess it's hanging someplace else now? :-(
[14:16] <xnox> pitti: let me go the traditional route and upload remaining fixes for tasks & try concurrent boot without changing sysv-init at all.
[14:16] <xnox> cause that suppose to work (or at least did in limited sense)
[14:17] <xnox> and the fact that startpar is not producing any logs anywhere is annoying. (and even it's stdout/stderr is slurrped up by the rc script)
[14:23] <pitti> dpm_: actually, with http://people.canonical.com/~dpm/data/ubuntu-l10n/utopic-potemplate-stats.log the percentage cutoff is not that hard to do; how reliable/up to date are these json files in general?
[14:24] <pitti> dpm_: with that file I'll add the numbers of all templates that we have in the package list, and with msgfmt --statistics I can add the number of translated strings, the rest is simple division and comparison
[14:25] <dpm_> pitti, they're pretty good, and they are updated once a day. As an alternative, you can use the LP API to get instant stats if we need it to be more frequent.
[14:25] <pitti> dpm_: nah, that's totally fine
[14:25] <pitti> thanks
[14:26] <dpm_> pitti, that sounds good to me. If you're looking for a pure python solution, you might want to use polib instead of the cli gettext tools
[14:26] <bdmurray> mvo: bug 1309447 failed the verification for the SRU. I posted the traceback I received.
[14:27] <pitti> dpm_: not installed on macquarie, I guess I'll just keep the existing msgfmt call (it's already calling that anyway for normalization)
[14:27] <dpm_> ok, sounds fine, then
[14:28] <mvo> bdmurray: thanks, let me have a look
[14:44] <mlankhorst> pmcgowan: oh btw, i checked and bug https://bugs.launchpad.net/checkbox-gui/+bug/1318584 is not a regression from trusty
[14:45] <shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kate/ < doesn't seem to have actually run the tests?
[14:45] <shadeslayer> https://jenkins.qa.ubuntu.com/job/utopic-adt-kate/ARCH=i386,label=adt/2/console
[14:45] <pmcgowan> mlankhorst, hmm? meaning its busted on earlier stuff?
[14:46] <pitti> shadeslayer: it could certainly do with some more verbosity..
[14:46] <shadeslayer> kbuildsycoca4 running... < kdeinit starts, but then nothing
[14:46] <mlankhorst> pmcgowan: yeah, trusty crashes in the same way, and I diffed the qplatformscreen.cpp file against 5.2.1, didn't find any changes
[14:46] <shadeslayer> klauncher: Exiting on signal 1 < that's from shutdown I kdeinit4_shutdown think
[14:47] <shadeslayer> pitti: btw locally my hook seems to run them
[14:47] <pitti> shadeslayer: perhaps this is missing some xvfb-run etc. magic?
[14:47] <shadeslayer> http://paste.ubuntu.com/7595244/
[14:47] <pmcgowan> mlankhorst, I assume the concern is trusty since thats what is used for preinstalls
[14:49] <mlankhorst> it looked to me like the concern was it being a regression that prevented 5.3.0 from landing..
[14:51] <pitti> mkdir failed: : No such file or directory
[14:51] <pitti> trying to create local folder /home/shadeslayer: Permission denied
[14:51] <pitti> shadeslayer: ^ something seems wrong in your hook?
[14:52] <mlankhorst> pmcgowan: from the qplatformscreen.cpp documentation
[14:52] <mlankhorst>     Reimplement in subclass to return the pixel geometry of the screen
[14:52] <mlankhorst> \fn QRect QPlatformScreen::geometry() const = 0
[14:52] <shadeslayer> pitti: http://paste.ubuntu.com/7595266/ < afaict that comes from kdeinit
[14:53] <pmcgowan> mlankhorst, no the concern aiui is validating trusty images with the test tool
[14:54] <pitti> shadeslayer: ah, this probably still keeps your $HOME although it runs as user pbuilder
[14:54] <shadeslayer> most likely
[14:54] <pitti> shadeslayer: btw, adt-run has a -s/--shell-on-fail option which you might want to use
[14:55] <pitti> shadeslayer: ah no, it's currently broken with --output-dir, so not yet :/ (and --tmp-dir is obsolete)
[14:55] <shadeslayer> pitti: the hook gives me a shell on fail :)
[14:55] <shadeslayer> see lines 31-33
[14:55] <pitti> shadeslayer: anyway, I suppose this needs to be checked in schroot or qemu to see what's going on
[14:55] <pitti> shadeslayer: right, that's what I was looking at
[14:56] <mlankhorst> pmcgowan: hm might be found with valgrind..
[14:57] <mlankhorst> if object was already destroyed
[14:57] <shadeslayer> uf :P
[14:57] <shadeslayer> seems like so much work
[14:59] <pitti> shadeslayer: well, what is this test supposed to do?
[14:59] <pitti> shadeslayer: the essence is that it calls dh_auto_test
[14:59] <shadeslayer> yep
[14:59] <pitti> shadeslayer: you really want to do that during build instead
[15:00] <pitti> that doesn't test the installed pacakges at all
[15:00] <pitti> and also explains why nothign is being tested in CI as there is no built tree
[15:01] <pitti> shadeslayer: (it doesn't have build-needed); but you really shouldn't run tests against the built tree in an autopkgtest anyway :)
[15:01] <pitti> shadeslayer: so that same appraoach in debian/rules override_dh_auto_test seems just fine
[15:01] <pitti> (and dropping the autopkgtest, or replacing it with something that actually tests the installed package)
[15:01] <shadeslayer> so I wonder why debian does it this way
[15:02] <pitti> shadeslayer: I know, it's a rampant error which apparently keeps spreading via copy & paste :(
[15:02] <pitti> shadeslayer: may I point to https://lists.debian.org/debian-devel-announce/2014/05/msg00004.html ?
[15:03]  * shadeslayer looks
[15:05] <shadeslayer> pitti: cheers, I'll collaborate with debian
[15:05] <pitti> shadeslayer: many thanks!
[15:29] <xnox> stgraber: https://launchpadlibrarian.net/177016056/buildlog.txt.gz this looks odd (during recipe build now)
[15:30] <stgraber> xnox: hmm, yeah, that's weird... I did put a breaks + replace in there didn't I?
[15:30] <xnox> stgraber: you did, but it's unpacking a weird upstart at the same time.
[15:31] <stgraber> xnox: ah, yeah, I guess that may break if using the upstart from the PPA maybe, if it has a version higher than the break but still has 01-upstart-lsb
[15:32] <xnox> stgraber: right, let me fix that. However, that shouldn't have happened as we use latest packaging.... which has the right commit dropping the hook.
[15:32] <cjwatson> Yeah, it'll always dist-upgrade from the archive in question first
[15:34] <xnox> right, last build of upstart into ppa for utopic used packaging revision 1562 and thus still has the hook, which now prevents building new upstart into ppa via recipe.
[15:35] <xnox> will delete upstart from PPA, check the recipe and re-trigger the build.
[15:37] <pitti> dpm_: so I implemented the "count number of translated strings" in langpack-o-matic now; turns out that we ought to remove quite a number of really poor langpacks for regular Ubuntu, too: http://paste.ubuntu.com/7595543/
[15:37] <pitti> dpm_: even with a really low cutoff like 5% we can get rid of a lot of noise (where there are only 5 strings translated in the whole Ubuntu..)
[15:38] <xnox> stgraber: cjwatson: ha, recipe uses trusty packaging instead of utopic.
[15:39] <xnox> which i think happens on each distro-series branch. lp:ubuntu/upstart recipe branches become lp:ubuntu/(devel-1)/upstart
[15:39] <dpm> pitti, that'd work for me if that helps managing language packs. I'm not too worried about it, as for me the priority would be to get more languages in the CD rather than reducing the number of langpacks in the archive. But if it helps removing cruft, wfm, yes
[15:40] <pitti> dpm: yeah, I implemented it for the 70% threshold for the touch packs, but it has that nice side effect :)
[15:40] <pitti> if we reduce the buildd load and archive overhead from 800 to 600 packages that's already something
[15:41] <dpm> :)
[15:42] <cjwatson> pitti: it's much more manageable with cross-architecture builder pooling now, anyway
[15:42] <pitti> cjwatson: right, but it's also Packages.gz size etc.
[15:42] <cjwatson> so we can build 16 language packs at a time in parallel and *blam*
[15:43] <cjwatson> Yeah
[15:43] <pitti> certainly not a huge saving, but we'll get that for free
[15:44] <pitti> and with that, good bye everyone! see you on Tuesday (swap day tomorrow, Pentecost on Monday)
[15:51] <bdmurray> mvo: do you have any plans to upload aptdaemon? bug 1324833
[15:53] <mvo> bdmurray: I had no plans, but I can do it tomorrow
[16:18] <hallyn> BenC: sorry on bug 1321365, i'll be testing a 1.2.5 candidate with that fix today
[16:19] <BenC> hallyn: Thanks. I’m working on testing libvirt fully. Tryign 1.2.5 right now (if you have wip src package, please let me try it too)
[16:19] <BenC> hallyn: I’ll let you know if I run into any other issues
[16:19] <BenC> hallyn: But please backport that fix to trusty too
[16:19] <hallyn> BenC: zul will push it to ppa:zulcss/libvirt-testing momentarily
[16:20] <hallyn> BenC: yes, will do.  i was going to wait for 1.2.5 but at this point forget that.  lemme check check other pending srus,
[16:20] <hallyn> yeah that's the only one i have listed for trusty
[16:20] <hallyn> say is saucy eol yet?
[16:25] <zul> BenC:  just doing a local test build first
[16:43] <hallyn> stgraber: hey, if you're around, would you midn looking at the libvirt pkg i pushed to trusty-proposed?  it's urgent for ben, a 2-line fix;  it's not in utopic yet only bc we're still testing the huge and painful 1.2.5 merge there.
[16:44] <hallyn> stgraber: and BenC is blocked without it
[16:44]  * hallyn shoulda just pushed the two-line fix originally, instead of trying to save the build farm some effort :)
[16:45] <stgraber> hallyn: ok, I'll take a look
[16:46] <stgraber> hallyn: minor nitpicking, why did you use ubuntu13.1.1 instead of ubuntu13.2? :)
[16:47] <hallyn> stgraber: bc ubuntu13.1 is still in utopic for a day <shrug>  i bikeshedded for 2 mins then figured this seemed safest
[16:47] <hallyn> happy to change it back :)
[16:47] <hallyn> will look neater in the end
[16:48] <stgraber> hallyn: nah, I'll accept it as is, the version is not wrong, it's just unusual ;)
[16:49] <stgraber> hallyn: accepted
[16:50] <hallyn> stgraber: thanks
[17:24] <BenC> error: Failed to create domain from vir1.xml
[17:24] <BenC> error: internal error: cannot load AppArmor profile 'libvirt-ffcc0d49-cf2d-48f7-bb59-fb60731b3c59'
[17:24] <BenC> hallyn: Any ideas on that?
[17:24] <BenC> This is using the 1.2.5 in zul’s  ppa
[17:24] <BenC> zul: ^^
[17:26] <zul> BenC:  no thats new to me
[17:28] <BenC> zul: This references an lp bug http://stackoverflow.com/questions/12069297/create-virtual-machine-using-libvirt-error-related-to-apparmor
[17:29] <BenC> zul: The workaround doesn’t apply to my xml though. It’s already raw
[17:29] <zul> BenC:  that version didnt have the device-tree fix since I havent uploaded it to my ppa yet hallyn is uploading a new fix
[17:30] <BenC> zul: I have that fixed locally, so that’s not the issue
[17:30] <zul> BenC:  then its another issue
[17:33] <hallyn> BenC: i've pushed the fix against 1.2.2 to both utopic and trusty-proposed.  you can grab the binaries from trusty-proposed
[17:33] <BenC> hallyn: Thanks
[17:46] <BenC> hallyn: Thanks
[17:46] <BenC> zul: No messages from apparmor in syslog when this happens
[17:46] <BenC> I even disabled apparmor and it still errors the same
[17:47] <hallyn> BenC: you get this with the 1.2.2 version as well?
[17:47] <BenC> hallyn: I can’t use 1.2.2 because it doesn’t configure the pci correctly, but no, I didn’t see this error there
[17:48] <BenC> It showed that it successfully loaded/removed the apparmor profiles for the guest too
[17:53] <hallyn> what patch do you need to configure teh pci correctly
[18:01] <bdmurray> pitti: have you seen the updated comments in bug 1259829 regarding some other models?
[18:07] <BenC> zul: If I set security_driver = "none" in libvirt/qemu.conf, and teardown apparmor, I can start vms with no issue
[18:07] <jamespage> gaughen, btw firefly is in -updates now
[18:08] <BenC> zul: When that error happens, virt-aa-helper isn’t even being called, so it fails even before that point in the code
[18:08] <zul> hallyn: ^^^
[18:14] <BenC> zul, hallyn: Something in virDomainDefFormatInternal() is erroring out (and it isn’t printing an error to syslog, so that limits the possibilities)
[18:22] <gaughen> jamespage, excellent
[18:23] <BenC> zul, hallyn: Here’s a FAQ: Not having a <uuid></uuid> in the xml causes that error
[18:26]  * hallyn mumbles something about xml
[19:25] <Unit193> henrix: Hello, are you alive there?