=== apachelogger is now known as fdsafdsafdsafdsa === fdsafdsafdsafdsa is now known as darthlulu === darthlulu is now known as apachelogger [08:59] 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] Launchpad bug 690370 in linux-ti-omap4 (Ubuntu) "Strange out of memory on pandaboard (affects: 1) (heat: 10)" [Undecided,New] [09:31] rsalveti: Around? [09:31] mkimage is moving from uboot-mkimage to u-boot; this might impact things like flash-kernel, cdimage and other code [09:32] 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] I'm fixing that now, so it will break on all arches [09:59] lool: so now each arch will have to install u-boot package just to have uboot-mkimage? [10:03] 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] my head hurts [10:04] lool: add uboot-mkimage binary package to u-boot source package [10:05] hrw: This would be a delta with Debian [10:05] hrw: I'm not sure how smooth upgrades will be, but I suspect that we need a dummy transitional package here [10:06] So this should probably be raised to Debian [10:06] albeit we could add the transitional package on our own [10:06] lool: or make it and raise it with patch and transitional package? [10:06] Yup [10:06] hrw: Would you like to do this? [10:08] would have first to check packages [11:21] lool: looks like uboot-mkimage should be transitional indeed [11:21] I just built both [11:24] hrw: you built both? I don't understand what you built [11:25] 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] u-boot and uboot-mkimage ones for amd64 [11:29] Ok; one open question is how to name the package [11:29] Sorry, ignore that [11:29] I'm confused with another issue [11:29] (which is that mkimage should be split out of u-boot) [11:30] ok [11:49] lool: hi [11:49] lool: our image is broken for quite a while, since dec 14 because of that [11:50] the package was removed from the archive, without fixing the u-boot one first [11:50] rsalveti: I think I've uploaded almost all fixes except for jasper-initramfs where I've sent a merge request [11:50] rsalveti: But I can't commit to jasper-initramfs [11:50] lool: I discussed that at #ubuntu-release yesterday [11:51] rsalveti: Ok; did the discussion raise any other required changes than the ones I prepared? [11:51] lool: and then we need to move this u-boot to main [11:51] as it's on universe currently [11:51] lool: nops, my only problem was that our image is currently broken because of that [11:52] mainly because of jasper [11:52] 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] rsalveti: I'm happy to upload the jasper-initramfs change if you vouch for it [11:52] 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] lool: I believe ogra is the only one that can write to the bzr branch [11:56] rsalveti: Yes; that's why I only sent a merge request [11:56] 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] rsalveti: Ok; will merge then [12:00] rsalveti: Uploaded, happy to hear how it works in Ubuntu images [12:00] lool: ok, then we should ask someone to bump it to main [12:02] rsalveti: Ping archive admins; tell them u-boot-linaro is already in main [12:02] rsalveti: ah sorry it's not [12:02] rsalveti: but tell them uboot-mkimage was in main and wa sa fork ;-) [12:09] hrw: If you're preparing a transitional package for mkimage, I'd love sponsoring it today while I still remember about this! :) [12:10] let me first find good example [12:10] lool: patch for u-boot acceptable? [12:10] hrw: Yup [12:10] hrw: debdiff would be ideal [12:17] 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] guerby: sure, just checking the bug [12:18] guerby: did you get anything at the uart? [12:18] guerby: if not, then just reboot it, nothing interesting at the logs :-) [12:18] rsalveti, nothing on serial (just unresponsive login prompt), I killed screen and relaunched, nothing [12:18] ops :-( [12:18] rsalveti, ok I'm power cycling [12:19] hm, weird that not even a kernel trace [12:20] rsalveti, may be there are bootargs to tell the kernel to be more verbose? [12:20] guerby: what are your current boot args? [12:21] it could be that you had 'quiet' on it [12:22] 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] rsalveti, also I noticed the board LEDs were both off after the freeze [12:23] but quiet just set the log level to warning, you should have seem at least some error [12:23] guerby: yeah, meaning that the board was dead [12:23] one led is the heartbeat [12:24] the other is the mmc activity [12:24] rsalveti, I had top and tail -f /var/log/messages running through ssh, plus screen on the serial and I saw nothing [12:24] rsalveti, ok thx === zyga is now known as zyga-coffee [12:25] nothing is bad :-( [12:26] lool: http://pastebin.com/g49n8Jde [12:27] rsalveti, I'm relaunching my bootstrap script [12:28] ok [12:35] rsalveti, do you think that my sysctl -w vm.overcommit_memory=2 could have an impact? [12:36] I also have echo 0 > /proc/sys/kernel/randomize_va_space [12:37] guerby: but that shouldn't freeze the kernel that way [12:37] it's probably another bug === zyga-coffee is now known as zyga [13:45] * rsalveti lunch [14:45] can someone take a look at bug 688010? [14:45] 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] it is armel only and I provided patch which solves problem [14:46] hi robclark [14:47] howdy hrw [14:52] robclark: is there a kernel for panda which finally gives mem=1G stable? [14:53] hrw: unsure.. I know some folks are using L24.11 kernel with 1G (minus the hole left for syslink).. [14:53] but I don't know if that means it's fixed, or just that they haven't had problems.. [14:54] hi... is there a libgles2-sgx-omap4-dev package? [14:54] (and L24.11 kernel doesn't work with the L24.9 versions of syslink, ducati, etc from 10.10...) [14:54] or... where can i get the headers for sgx gles2? [14:55] 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] although I don't know if those are packaged in any way.. [14:55] robclark: you mean... the mesa headers? [14:56] I guess so.. but I've never tried.. [14:56] the mesa package that contains the headers conflicts with sgx packages [14:56] assuming mesa headers aren't weird in some way [14:57] demarchi: http://www.khronos.org/registry/gles/ [14:58] you can download manually the headers.. perhaps there is a better way, with some deb package, but I don't know [14:58] maybe vstehle or rsalveti or someone like that has some idea [15:06] robclark: demarchi: mesa headers should be fine [15:07] demarchi: libgles1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev [15:07] 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] as we don't want people complaining that built the package against it but only works when using the sgx libs [16:10] rsalveti: What happened to u-boot-omap4 in maverick? [16:11] rsalveti: did it get removed? did another u-boot source supersede it? u-boot-linaro maybe? [16:11] lool: yeah, we're only using the u-boot-linaro [16:12] lool: can you please file a MIR bug later? [16:12] I want to get this issue with u-boot fixed so we can generate arm images again [16:18] rsalveti: LP #692613 [16:18] Launchpad bug 692613 in u-boot (Ubuntu) "[MIR] u-boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/692613 [16:18] rsalveti: I was filing it, which is why I was asking [16:18] lool: cool, thanks [17:59] 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] rOxx: Sounds like you have some proxy between you and ports.u.c [18:01] yes i have configured a proxy [18:02] rOxx: Can you use wget to download the .deb package? [18:03] @gruemaster yes wget is available [18:04] 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] @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] @gruemaster now i have the file on my beagleboard. i saved the file with the firefox download manager :-) [18:08] is this method ok ? [18:08] 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] 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] 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] rOxx: I can just tell you it's related to your proxy :-) [18:10] 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] @gruemaster i have downloaded the file via wget. it works fine [18:19] 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] restarting is just as good as logging out/logging in. [18:22] 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] ok gruemaster and lool, thanks for your help, i go to my neighbour and test it without a proxy connection [19:09] 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] cdc-acm [21:22] 15:45 < hrw> can someone take a look at bug 688010? [21:22] 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] 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] 0x0d? not 0x0c? [21:42] yes, 0x0d [21:44] 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] a wha? [21:45] 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] so the embedded device is using the gadget framework and is loading the g_serial module (and using acm) [21:46] 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] to which I'm trying to connect* [21:49] 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] 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] gn