[08:59] <guerby> rsalveti, ok second freeze this night. no blinking LED, nothing on the serial console even after reconnecting, I added some info on https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/690370
[08:59] <ubot2> Launchpad bug 690370 in linux-ti-omap4 (Ubuntu) "Strange out of memory on pandaboard (affects: 1) (heat: 10)" [Undecided,New]
[09:31] <lool> rsalveti: Around?
[09:31] <lool> mkimage is moving from uboot-mkimage to u-boot; this might impact things like flash-kernel, cdimage and other code
[09:32] <lool> The u-boot import doing this happened on the 7th, but failed to build on most arches (except amd64) due to LDFLAGS breaking the u-boot host build
[09:32] <lool> I'm fixing that now, so it will break on all arches
[09:59] <hrw> lool: so now each arch will have to install u-boot package just to have uboot-mkimage?
[10:03] <lool> hrw: Yes; uboot-mkimage used to be built from an old fork of the u-boot source tree, so it's an improvement, but I would have preferred if we had a separate package instead
[10:04] <lool> my head hurts
[10:04] <hrw> lool: add uboot-mkimage binary package to u-boot source package
[10:05] <lool> hrw: This would be a delta with Debian
[10:05] <lool> hrw: I'm not sure how smooth upgrades will be, but I suspect that we need a dummy transitional package here
[10:06] <lool> So this should probably be raised to Debian
[10:06] <lool> albeit we could add the transitional package on our own
[10:06] <hrw> lool: or make it and raise it with patch and transitional package?
[10:06] <lool> Yup
[10:06] <lool> hrw: Would you like to do this?
[10:08] <hrw> would have first to check packages
[11:21] <hrw> lool: looks like uboot-mkimage should be transitional indeed
[11:21] <hrw> I just built both
[11:24] <lool> hrw: you built both?  I don't understand what you built
[11:25] <lool> hrw: I filed a bug in Debian to request a transitional package BTW; I'm happy if we add it in Ubuntu first though
[11:27] <hrw> u-boot and uboot-mkimage ones for amd64
[11:29] <lool> Ok; one open question is how to name the package
[11:29] <lool> Sorry, ignore that
[11:29] <lool> I'm confused with another issue
[11:29] <lool> (which is that mkimage should be split out of u-boot)
[11:30] <hrw> ok
[11:49] <rsalveti> lool: hi
[11:49] <rsalveti> lool: our image is broken for quite a while, since dec 14 because of that
[11:50] <rsalveti> the package was removed from the archive, without fixing the u-boot one first
[11:50] <lool> rsalveti: I think I've uploaded almost all fixes except for jasper-initramfs where I've sent a merge request
[11:50] <lool> rsalveti: But I can't commit to jasper-initramfs
[11:50] <rsalveti> lool: I discussed that at #ubuntu-release yesterday
[11:51] <lool> rsalveti: Ok; did the discussion raise any other required changes than the ones I prepared?
[11:51] <rsalveti> lool: and then we need to move this u-boot to main
[11:51] <rsalveti> as it's on universe currently
[11:51] <rsalveti> lool: nops, my only problem was that our image is currently broken because of that
[11:52] <rsalveti> mainly because of jasper
[11:52] <lool> rsalveti: asac/doko removed me from ~ubuntu-mir for some reason, so I can't approve this, but it would be a trivial MIR to bump u-boot to main
[11:52] <lool> rsalveti: I'm happy to upload the jasper-initramfs change if you vouch for it
[11:52] <lool> I just can't commit it to Bzr, so would either comment out the Vcs-Bzr or move it to the UDD branch
[11:56] <rsalveti> lool: I believe ogra is the only one that can write to the bzr branch
[11:56] <lool> rsalveti: Yes; that's why I only sent a merge request
[11:56] <rsalveti> and as we need it to get our image working, I believe it should be ok to just fix the package at ubuntu
[11:56] <lool> rsalveti: Ok; will merge then
[12:00] <lool> rsalveti: Uploaded, happy to hear how it works in Ubuntu images
[12:00] <rsalveti> lool: ok, then we should ask someone to bump it to main
[12:02] <lool> rsalveti: Ping archive admins; tell them u-boot-linaro is already in main
[12:02] <lool> rsalveti: ah sorry it's not
[12:02] <lool> rsalveti: but tell them uboot-mkimage was in main and wa sa fork   ;-)
[12:09] <lool> hrw: If you're preparing a transitional package for mkimage, I'd love sponsoring it today while I still remember about this!  :)
[12:10] <hrw> let me first find good example
[12:10] <hrw> lool: patch for u-boot acceptable?
[12:10] <lool> hrw: Yup
[12:10] <lool> hrw: debdiff would be ideal
[12:17] <guerby> rsalveti, I've left my pandaboard in freeze state in case you want me to do something, if not let me know I'll power cycle it
[12:17] <rsalveti> guerby: sure, just checking the bug
[12:18] <rsalveti> guerby: did you get anything at the uart?
[12:18] <rsalveti> guerby: if not, then just reboot it, nothing interesting at the logs :-)
[12:18] <guerby> rsalveti, nothing on serial (just unresponsive login prompt), I killed screen and relaunched, nothing
[12:18] <rsalveti> ops :-(
[12:18] <guerby> rsalveti, ok I'm power cycling
[12:19] <rsalveti> hm, weird that not even a kernel trace
[12:20] <guerby> rsalveti, may be there are bootargs to tell the kernel to be more verbose?
[12:20] <rsalveti> guerby: what are your current boot args?
[12:21] <rsalveti> it could be that you had 'quiet' on it
[12:22] <guerby> rsalveti, text ro elevator=noop vram=32M mem=768M root=UUID=b5d2dfb1-270c-4966-abe6-dfe7a2a17efd fixrtc smsc95xx.macaddr=32:57:F8:93:E1:CD
[12:23] <guerby> rsalveti, also I noticed the board LEDs were both off after the freeze
[12:23] <rsalveti> but quiet just set the log level to warning, you should have seem at least some error
[12:23] <rsalveti> guerby: yeah, meaning that the board was dead
[12:23] <rsalveti> one led is the heartbeat
[12:24] <rsalveti> the other is the mmc activity
[12:24] <guerby> rsalveti, I had top and tail -f /var/log/messages running through ssh, plus screen on the serial and I saw nothing
[12:24] <guerby> rsalveti, ok thx
[12:25] <rsalveti> nothing is bad :-(
[12:26] <hrw> lool: http://pastebin.com/g49n8Jde
[12:27] <guerby> rsalveti, I'm relaunching my bootstrap script
[12:28] <rsalveti> ok
[12:35] <guerby> rsalveti, do you think that my sysctl -w vm.overcommit_memory=2 could have an impact?
[12:36] <guerby> I also have echo 0 > /proc/sys/kernel/randomize_va_space
[12:37] <rsalveti> guerby: but that shouldn't freeze the kernel that way
[12:37] <rsalveti> it's probably another bug
[13:45]  * rsalveti lunch
[14:45] <hrw> can someone take a look at bug 688010?
[14:45] <ubot2> Launchpad bug 688010 in ubuntu-netbook-default-settings (Ubuntu) "Missing dependency on gconf2 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/688010
[14:46] <hrw> it is armel only and I provided patch which solves problem
[14:46] <hrw> hi robclark
[14:47] <robclark> howdy hrw
[14:52] <hrw> robclark: is there a kernel for panda which finally gives mem=1G stable?
[14:53] <robclark> hrw: unsure..  I know some folks are using L24.11 kernel with 1G (minus the hole left for syslink)..
[14:53] <robclark> but I don't know if that means it's fixed, or just that they haven't had problems..
[14:54] <demarchi> hi... is there a libgles2-sgx-omap4-dev package?
[14:54] <robclark> (and L24.11 kernel doesn't work with the L24.9 versions of syslink, ducati, etc from 10.10...)
[14:54] <demarchi> or... where can i get the headers for sgx gles2?
[14:55] <robclark> demarchi: I'm not a GL expert, but I think the idea is that you should be able to compile things with generic headers from khronos..
[14:55] <robclark> although I don't know if those are packaged in any way..
[14:55] <demarchi> robclark: you mean... the mesa headers?
[14:56] <robclark> I guess so.. but I've never tried..
[14:56] <demarchi> the mesa package that contains the headers conflicts with sgx packages
[14:56] <robclark> assuming mesa headers aren't weird in some way
[14:57] <robclark> demarchi: http://www.khronos.org/registry/gles/
[14:58] <robclark> you can download manually the headers..   perhaps there is a better way, with some deb package, but I don't know
[14:58] <robclark> maybe vstehle or rsalveti or someone like that has some idea
[15:06] <rsalveti> robclark: demarchi: mesa headers should be fine
[15:07] <rsalveti> demarchi: libgles1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev
[15:07] <rsalveti> at least for omap 3 packages we don't put the headers by default because of the soname mess around the sgx library
[15:08] <rsalveti> as we don't want people complaining that built the package against it but only works when using the sgx libs
[16:10] <lool> rsalveti: What happened to u-boot-omap4 in maverick?
[16:11] <lool> rsalveti: did it get removed?  did another u-boot source supersede it?  u-boot-linaro maybe?
[16:11] <rsalveti> lool: yeah, we're only using the u-boot-linaro
[16:12] <rsalveti> lool: can you please file a MIR bug later?
[16:12] <rsalveti> I want to get this issue with u-boot fixed so we can generate arm images again
[16:18] <lool> rsalveti: LP #692613
[16:18] <ubot2> Launchpad bug 692613 in u-boot (Ubuntu) "[MIR] u-boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/692613
[16:18] <lool> rsalveti: I was filing it, which is why I was asking
[16:18] <rsalveti> lool: cool, thanks
[17:59] <rOxx> hello, i want to install the gcc compiler on my beagleboard running with ubuntu 10.10. but i have problems with the "failure http://ports.ubuntu.com/ubuntu-ports/pool/main/g/gcc-defaults/gcc_4.4.4-lubuntu2_armel.deb 416 Request Range Not Satisfiable" i tried to install the gcc compiler with aptitude, apt-get and synapsys. But everytime i got the same message. anyone can help me?
[18:00] <lool> rOxx: Sounds like you have some proxy between you and ports.u.c
[18:01] <rOxx> yes i have configured a proxy
[18:02] <GrueMaster> rOxx: Can you use wget to download the .deb package?
[18:03] <rOxx> @gruemaster yes wget is available
[18:04] <GrueMaster> so, "wget http://ports.ubuntu.com/ubuntu-ports/pool/main/g/gcc-defaults/gcc_4.4.4-lubuntu2_armel.deb" will download the file without error?  Very odd.
[18:05] <rOxx> @lool i have configured the proxy in the Preferences -> network proxy > there manuell proxy config -> entered the proxy data and apply system wide. is this correkt ?
[18:07] <rOxx> @gruemaster  now i have the file on my beagleboard. i saved the file with the firefox download manager :-)
[18:08] <rOxx> is this method ok ?
[18:08] <GrueMaster> rOxx: After setting the system wide proxy, did you log out/log in?  That is the only way to ensure the setting gets carried through to all apps that use system environment settings (i.e. bash shells).
[18:10] <lool> rOxx: I'm not sure it's enough/correct, nor whether it's because your proxy is being used or is not being used
[18:10] <GrueMaster> rOxx: using wget as I indicated is a way of testing the underlying environment that apt-get relies on.  If wget fails, then we can go further.  using firefox, while effective in retrieving the file, doesn't help test apt-get issues (other than basic network connectivity).
[18:10] <lool> rOxx: I can just tell you it's related to your proxy  :-)
[18:10] <lool> rOxx: apt directly talking to ports.u.c works fine, and there are no mirrors, so it's necessarily either your setup being incomplete, or apt misbehaving with your proxy, or your proxy misbehaving
[18:18] <rOxx> @gruemaster i have downloaded the file via wget. it works fine
[18:19] <rOxx> after i changed the proxy settings, i didnt log out, but today i have restarted the system after changing the proxy settings. is this the same ?
[18:21] <GrueMaster> restarting is just as good as logging out/logging in.
[18:22] <GrueMaster> I'm running "apt-get install gcc" here on my beagleXM running 10.10, and have not seen a problem (although I do not have a proxy).
[18:23] <rOxx> ok gruemaster and lool, thanks for your help, i go to my neighbour and test it without a proxy connection
[19:09] <cipher> is anyone familiar with whether or not acm-mode defines a specific use of newline characters? I'm playing with an embedded device that is using the g_serial gadget and by default it uses ACM. I'm not famliar enough with ACM to know whether that standard makes mention of newline treatment. I actually don't want any special newline treatment at all.
[19:09] <cipher> cdc-acm
[21:22] <hrw> 15:45 < hrw> can someone take a look at bug 688010?
[21:22] <ubot2> Launchpad bug 688010 in ubuntu-netbook-default-settings (Ubuntu) "Missing dependency on gconf2 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/688010
[21:23] <cipher> has anyone tried using usbser.sys and found that it inserts spurious carriage returns (0x0d) when the serial device is actually just sending newline (0x0a) ?
[21:24] <hrw> 0x0d? not 0x0c?
[21:42] <cipher> yes, 0x0d
[21:44] <cipher> it seems like when I use my os x machine and configure it to use the gadget serial device as a null modem this problem doesn't exist
[21:44] <NullMoogleCable> a wha?
[21:45] <cipher> it presents an option as Vendor: null modem on os x system preferences and opens up options for the baud rate which was what gave me a good feeling that it would work fine on osx without a custom driver
[21:45] <cipher> so the embedded device is using the gadget framework and is loading the g_serial module (and using acm)
[21:46] <cipher> and the windows box to which I'm trying to connected the embedded device using the usb OTG port is configured to use usbser.sys as stated in the linux kernel documentation
[21:46] <cipher> to which I'm trying to connect*
[21:49] <cipher> so when I go echo -ne "\n" > /dev/ttyGS0 on the arm box and receive on the os x usb host I just get 0x0a whereas on the windows host I get 0x0a 0x0d or maybe it's 0x0d 0x0a... either way it's putting something in there that shouldn't
[23:21] <guerby> rsalveti, hmm freeze again after about 7 hours of compile, no message on serial. Let me know if you think of something useful I could do
[23:23] <guerby> gn