[00:33] <dcordes> a pity nobody is able to help
[00:33] <dcordes> wondering if this is the correct place for such question. topic recommends bugtracker but I'm not sure if the problem is not on my side.
[00:39] <michaelh1> dcordes: Hi.  Fire away.  I'm new to this but you never know :)
[00:42]  * dcordes is wondering if the channel has any logs
[00:42] <dcordes> michaelh1: hi
[00:46] <michaelh1> dcordes: what was the problem?
[00:47] <dcordes> michaelh1: in my karmic rootstock built rootfilesystem only root can make use of networking
[00:48] <michaelh1> dcordes: what do you mean 'make use of'?  Ping?  dhclient?
[00:49] <dcordes> the network is setup by networkmanager perfectly well
[00:49] <dcordes> it is a usb ether device which is in a net with dhcp server
[00:49] <dcordes> nm pulls device up and obtains ip
[00:49] <dcordes> as root I can ping and everything
[00:49] <dcordes> with the user I can do nothing
[00:51] <michaelh1> As a user, what happens if you start a shell and then run 'ifconfig'?
[00:52] <dcordes> let me check
[01:13] <dcordes> michaelh1: sorry for the delay
[01:13] <dcordes> michaelh1: I was using the network connection on different machine
[01:14] <dcordes> michaelh1: so, running ifconfig with the unprivileged user shows both interfaces as expected
[01:14] <dcordes> eth0 lo
[01:16] <michaelh1> dcordes: and eth0 has the correct IP address?  What is the address, and what is the address of your gateway?
[01:18] <dcordes> michaelh1: hehe typing from the device now
[01:18] <dcordes> ipv6
[01:21] <michaelh1> Sorry, what do you mean by 'ipv6'?
[01:25] <dcordes> michaelh1: inet6 address
[01:26] <dcordes> michaelh1: anyway the connection is there
[01:26] <michaelh1> And as root you can ping the gateway (or other machine), but as a user you can't?
[01:29] <dcordes> michaelh1: right
[01:34] <michaelh1> Hmm.  How about web or similar, in case ICMP is blocked for normal users
[01:34] <michaelh1> Such as 'telnet google.com 80' as root vs as the user?
[01:36] <dcordes> installing telnet
[01:36] <dcordes> new uSD card is too slow
[01:38] <dcordes> michaelh1: ok as root I can  connect with user I get Name or service not known.
[01:39] <michaelh1> dcordes: weird.  How are you switching back and forth between user and root?  Do you log in as user then sudo the root commands?
[01:40] <dcordes> yep
[01:41] <michaelh1> dcordes: extra weird.  I'm afraid that I don't know.  I assume that something is blocking user level access to the network, but I don't know what.
[01:41] <michaelh1> Sorry.
[01:41] <dcordes> hm that is the big question
[01:41] <michaelh1> One suggestion is to try an IP address instead, especially if you have a localhost service such as SSH.
[01:41] <dcordes> ok to exclude dns problem
[01:43] <dcordes> michaelh1: lol trying to ping the Gateway IP I get permission denied as user
[01:43] <michaelh1> Yip.  If you can't get a TCP connection direct to an IP then, well, ...
[01:44] <michaelh1> Not surprising.  I think Windows 7 does the same to non-priviledged accounts
[01:45] <dcordes> should I downgradde to vista ?
[01:45] <dcordes> somebody got cortex-a8 vista rootfs ?
[01:45] <dcordes> sorry ^^
[01:51] <dcordes> let's see if the problem i gone in lucid rootfs
[01:51] <dcordes> thanks.
[04:39]  * mozzwald is away: sleepytimes
[05:43]  * mozzwald is away: sleepytime
[08:15] <hrw> morning
[09:44] <zumbi> hi
[09:45] <hrw> hi zumbi
[12:04] <lool> GrueMaster: Hey there, I understand you test maverick omap3 kernels on beagles regularly; how stable is the mini-USB port for you as a host port?
[13:00] <kai> lool: there's a big difference between different beagle revisions for the kernels I tried
[13:00] <kai> lool: but arguably I didn't try kernels from maverick, just the stuff rcn-ee builds
[13:01] <ogra> kai, thats massively different :)
[13:02] <kai> ogra: I'm still sure that the fact that the same kernel behaves different on two different beagle revisions means this can happen as well for other kernels
[13:02] <ogra> indeed
[13:02] <lag> sebjan: ping
[13:03] <kai> notably, otg seems more stable on revB
[13:03] <sebjan> lag: pong
[13:03] <lag> Hi sebjan
[13:03] <lag> sebjan: bug 592295
[13:03] <ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/592295
[13:04] <lag> I believe this to be a regression issue imposed on us by one of your colleagues
[13:04] <kai> arguably it's been running fine for quite a while now
[13:04] <ogra> lag, i belive thats the wrong package it's filed against
[13:05] <lag> sebjan: Mythri P K <mythripk@ti.com>
[13:05]  * kai re-lurks
[13:05] <ogra> should be linux-ti-omap4
[13:05] <lag> ogra: More than likely
[13:05] <lag> ogra: I didn't know that exists
[13:05] <ogra> since june 18th
[13:06] <sebjan> lag: yes, Mythri is a colleague from TI
[13:07] <lag> He commented out the shutdown code
[13:07] <lag> I believe this was a slap-dash method to get HDMI working, but it has problems
[13:08] <lag> If an HDMI device is plugged in, but not switched on the console is flooded and the system becomes inoperable
[13:10] <ogra> hmm, did OOo actually just finish on the buildd or did it just fail
[13:10]  * ogra notices it just vanished from https://edge.launchpad.net/builders
[13:11] <lag> What do you think sebjan?
[13:11] <sebjan> lag: right, this is what I understand from the bug description
[13:11] <lag> Correct
[13:11] <lag> So, would you like me to fix it, or should I contact your colleague?
[13:12] <sebjan> lag: the best would be to discuss with my colleague. I will get in touch with him and then come back to you.
[13:12] <lag> Great, thanks
[13:12] <ogra> aha, OOo failed due to openjdk issues
[13:19] <hrw> hi robclark
[13:19] <robclark> gm hrw
[13:20]  * robclark needs coffee
[14:37] <sebjan> ogra: Hi! I am looking at your u-boot-omap4 package, and am wondering how to generate various u-boot binaries from this package (corresponding to various config files for example)? Is there a nice way to do that?
[14:38] <ogra> no, saldy all ways to do that are ugly
[14:38] <ogra> i will add bits and pieces to build the 3630sdp u-boot after the alpha2 release
[14:39] <ogra> you will have to do multiple build runs to clean and reconfigure the environment
[14:39] <ogra> its pretty complex
[14:41] <berco> Is it recommended for debian packages under Ubuntu to comply with source format 3.0? http://wiki.debian.org/Projects/DebSrc3.0
[14:41] <directhex> berco, depends on how easily you want to backport them, and not really an ARM question
[14:42] <sebjan> ogra: ok... then I was thinking of making a different rules file, which run succesively (clean / configure / make / cp binary). That's not clean, but would be working, right? (I do not plan to release this package)
[14:43] <ogra> sebjan, that would work, but its gross :)
[14:43] <sebjan> ogra: or would there be another approach, not too complex that would make it also?
[14:43] <ogra> i dont know one, you will definately need multiple runs
[14:43] <berco> directhex: i'm packaging for arm platform. Original software was not using any packaging. So this is the first debianization of the source code
[14:43] <ogra> the qemu-kvm package might be an example to steal from
[14:44] <ogra> berco, up to you, really, i rarely use 3.0 for me new packages ... its definately not mandatory to use 3.0 format
[14:45] <berco> ogra: thanks. I raise this question as lintian was complaining about 1.0
[14:47] <ogra> why was it doing that ?
[14:47] <ogra> i.e. where did you define 1.0 ?
[14:47] <berco> ogra: i didn't define 1.0. I think it was just reported as a warning
[14:48] <ogra> weird
[14:48]  * ogra has never seen such a warning
[14:48] <berco> 1.0 is used by default whne no debian/source/format file
[14:49] <directhex> the warning is because the default may change in the future
[14:49] <directhex> so explicitly saying 1.0 prevents unexpected surprises
[14:50] <ogra> oh, so you got "missing-debian-source-format", not that 1.0 is wrong
[14:50] <berco> yes
[14:50] <berco> plus some message about I should use 3.0 instead
[14:51] <ogra> well, the warning will go away if you "mkdir -p debian/source && echo '1.0' > debian/source/format"
[14:52] <ogra> it will change at some point, but not now
[14:52] <ogra> no need to worry about it for the moment
[14:52] <berco> ogra: thanks for the recommandation. As with 3.0 no more .diff file is generated. Instead it is a patch file
[14:53] <ogra> yeah
[15:01] <gsnedders> So trying to cross-compile with enviroment mainly built with apt-cross, I have a build script that wants to use sdl-config, which doesn't exist there. Any idea what to do?
[15:01] <hrw> apt-cross libsdl-dev?
[15:02] <gsnedders> hrw: That doesn't give sdl-config
[15:02] <hrw> ah.. dpkg-cross drops it
[15:02] <gsnedders> Indeed
[15:03] <hrw> gsnedders: does not sdl support pkg-config?
[15:04] <gsnedders> Ah, it does
[15:05] <gsnedders> That'll work, thanks
[15:36] <lag> sebjan: Did you have any luck in speaking with Mythri?
[15:37] <sebjan> lag: yes, he shall be contacting you soon
[15:38] <lag> Brilliant, thanks for you help sebjan
[15:38] <sebjan> lag: np
[15:55] <sumitsemwal> sebjan: lag: Mythri is a lady-colleague from TI.. :)
[15:56] <sebjan> sumitsemwal: oups, I just had email contact so far... Thanks for correcting :)
[15:56] <lag> sumitsemwal: I haven't said anything to the contrary
[15:56] <lag> :)
[15:57] <sumitsemwal> sebjan: np :) - difficult to make out with our names.
[15:58] <sumitsemwal> lag: ofcourse - it was just fyi :P
[15:59] <lag> :D
[16:12] <ndec> mpoirier: hi
[16:23] <mpoirier> ndec: sorry I didn't see you ping.
[16:25] <ndec> mpoirier: no pb.
[16:26] <ndec> mpoirier: so what do you want to discuss?
[16:27] <mpoirier> why did your team selected to load syslink in upstart rather than "/etc/modules"
[16:27] <ndec> mpoirier: we didn't decide anythin yet...
[16:27] <ndec> mpoirier: i asked you the question to know what the right approach should be
[16:27] <ndec> mpoirier: and you mentioned that kernel had some automatic way to do that.
[16:28] <mpoirier> ndec: ok... but how did upstart got entangled in this then ?
[16:28] <ndec> ndec: because i thought it would do the job since i could make a script that would run right after boot
[16:29] <mpoirier> ndec: I understand.
[16:29] <ndec> mpoirier: so what do you propose? you mentioned a way to get an event from kernel? i am not sure i understand what you meant.
[16:30] <mpoirier> ndec: I was under the impression that your team had some temporary solution and was looking for the right way of doing this.
[16:30] <ndec> mpoirier: right now, our driver is built statically in the kernel, but this will change, this is why we need that.
[16:31] <mpoirier> ndec: the problem is to insert the module when the system boots.
[16:31] <ndec> mpoirier: yes
[16:31] <mpoirier> /etc/modules is generally how to do this.
[16:31] <mpoirier> from there, inserting the module  will generate uevent, which udev is listening for.
[16:31] <ndec> mpoirier: is that okay if I modify /etc/modules from a package?
[16:32] <mpoirier> good question - I will look in to that.
[16:32] <mpoirier> this is exactly why I wanted to have a live conversation with you.
[16:32] <mpoirier> once the module is installed, do you need to kick applications ?
[16:33] <mpoirier> deamon or some other program ?
[16:33] <ndec> mpoirier: potentially yes
[16:33] <mpoirier> ok.
[16:33] <mpoirier> we can do that with udev rules.
[16:33] <mpoirier> most rules already do that anyway.
[16:34] <mpoirier> I will look into  modifying /etc/modules froma package and will get back to you.
[16:35] <mpoirier> if we can, we have a solution.
[16:35] <ndec> mpoirier: ok. thx
[16:35] <mpoirier> otherwise I' keep looking.
[16:37] <sebjan> mpoirier: for my understanding, there is an init script doing some modprobes on the modules listed into /etc/modules?
[16:38] <lool> Yes, but this aint terribly good
[16:38] <lool> The better interface is udev events, especially if this is some kind of bus or device interface or device
[16:39] <lool> For instance, the ACPI BIOS parser will emit events for the various ACPI devices found with codenames and udev translates that to inserting the proper modules
[16:39] <ndec> lool: in this specific case it's a device on the platform bus.
[16:39] <lool> That also allows triggering extra things when e.g. a new bus or a new device shows up, so if you syslink needs to be scanned from userspace, that might be a better solution
[16:40] <lool> ndec: Do you have a way to detect that device?
[16:40] <ndec> lool: well, it's embedded in OMAP4, so it's always there
[16:40] <mpoirier> lool: that is what I'm after...
[16:40] <mpoirier> lool: do you think we could put it in the platform devices ?
[16:40] <lool> Hmm if it's always there, why would people want to build it as a module?
[16:41] <lool> mpoirier: That seems sensible
[16:41] <ndec> lool: because it's always there on OMAP4, not OMAP3
[16:41] <lool> ndec: always there on OMAP4 and never there on OMAP3?
[16:41] <ndec> lool: yes
[16:41] <lool> platform device might make sense indeed
[16:42] <ndec> lool: it is a platform device already in the kernel. is there an api in kernel we can use to generate those events?
[16:43] <lool> I dont know
[16:45] <ndec> lool: mpoirier: sebjan: http://www.linuxtopia.org/online_books/opensuse_guides/opensuse11.1_reference_guide/sec_udev_kernel.html in fact it looks like the events are generated automatically by the kernel. if I look at /var/log/udev I can see them
[16:46] <mpoirier> lool: I only used platform devices with statically linked drivers - have you experienced with modules ?
[16:46] <lool> ndec: If you're looking at creating your own udev events, I think it's the uevent API, thinks like uevent_foo add_uevent_var() and such
[16:47] <ndec> mpoirier: see above. looks like the udev event is generated automaticlly
[16:47] <lool> I'm just a kernel fanboy, I'm afraid I'm not an authoritative source for anything
[16:48] <mpoirier> ndec: I will look at your link...
[17:01] <tgardner> ndec, davidm asked me to talk to you about module loading. Have you had your questions answered ?
[17:02] <ndec> tgardner: hi. we were just discussing about this with mpoirier
[17:02] <ndec> tgardner: currently it's still not answered.
[17:03] <tgardner> ndec, I understand that you want to have a video device module loaded. Is it a probable device?
[17:03] <ndec> tgardner: i have a platform device on my h/w (OMAP4), and I want to build the driver for it as a module, and I want the module to be loaded at boot time.
[17:03] <tgardner> i.e., does it have a discoverable device ID?
[17:04] <ndec> tgardner: can you confirm if udev events are generated when calling platform_device_add from the kernel?
[17:04] <ndec> tgardner: I don't know for the discoverable device ID. it's something embedded in OMAP4.
[17:05] <tgardner> ndec, well, the simplest thing to do is to add the module name to /etc/modules, then run update-initramfs
[17:05] <tgardner> it'll get loaded on the next boot cycle
[17:05] <ndec> tgardner: but I thought it would not be eleguant to update /etc/modules from a package.
[17:05] <ogra> tgardner, can you also provide a proper solution from the kernel ? :)
[17:06] <tgardner> ograonly if its a discoverable device
[17:06] <tgardner> ogra^^
[17:06] <ogra> isnt there some function that walks devices that can be used ?
[17:07] <ogra> how is that normally done on non PCI systems ?
[17:07] <davidm> ogra, only if the device is discoverable
[17:07] <tgardner> given that this is ARM, its probably just a well known memory area. This is the issue that the device map stuff is attempting to solve.
[17:08] <tgardner> ogra: when the PCI platform driver is loaded it grovels the PCI bus, sending discover events to udev
[17:08] <ndec> tgardner: when is the udev event generated? right now I have the module built in statically in my kernel, and I can see udev event at boot time for it.
[17:08] <ogra> tgardner, right, i was hoping there is something similar for the platform bus
[17:08] <ndec> b
[17:09] <tgardner> ndec, ogra: so, is this a platform driver, or a simple driver?
[17:09] <ogra> platform i think
[17:09] <ndec> tgardner: platform driver
[17:09] <tgardner> ndec, then I assume your platform driver is initiating the udev event?
[17:09] <tgardner> (when its built in)
[17:10] <ndec> tgardner: i guess so, but i don't know how it's being generated.
[17:10] <ndec> tgardner: I am calling platform_device_add() and then platform_driver_register()
[17:10] <ogra> either will generate the event
[17:11] <ogra> s/either/one of them/
[17:12] <tgardner> ndec, so its a chicken and egg problem. its the platform driver that emits discovery events, right? so how does the platform driver get loaded? Usually they are built-in, but in this case it _must_ be a  module, right?
[17:12] <mpoirier> tgardner: and this is what I'm trying to find...
[17:12] <tgardner> ok, then the solution is to add it to /etc/modules
[17:12] <mpoirier> if platform drivers can work with  loadable modules.
[17:13] <tgardner> ogra: is /etc/modules considered a conf file wrt to debian policy?
[17:13] <ogra> i dont think so
[17:13] <ndec> tgardner: don't think so. there are 2 separate things: the platform device and the platform driver. my feeling is that the udev event is made then the platform device is added. so this is call must be in the kernel at boot. but the platform driver registration can be in the module
[17:13] <ogra> its also no prob to modify it from our first boot tool in the images
[17:14] <ogra> it just doesnt feel right at all
[17:15] <tgardner> ogra, well, the _right_ thing to do is to build the dang thing into the kernel, but that doesn't seem to be a choice.
[17:15] <ogra> or make the HW discoverable by the kernel somehow
[17:15] <ogra> so it can be loaded dynamically
[17:15] <ndec> tgardner: that would then mean that if we have a generic ARM kernel, it would need to have all platform drivers... that looks wrong to me.
[17:16] <tgardner> ndec, have you tried building these drivers as modules, then modprobe them sometime after boot to see if they do what you expect?
[17:16] <ndec> tgardner: no
[17:16] <ogra> tgardner, the fec NIC driver on the imx51 platform was a platform driver iirc
[17:16] <ogra> that used to work fine
[17:17] <ogra> and was dynamically loaded
[17:17] <tgardner> ogra: I thought that was a simple ethernet driver
[17:17] <ogra> yes
[17:17] <ogra> but hooked into the platform bus
[17:17] <ogra> we had to patch NM to accept platform devices to make it work at all
[17:18] <tgardner> where is the source for this stuff?
[17:18] <ogra> so i wonder if what worked there might be applicable to ndec's case
[17:18] <ogra> should be in our imx51 tree
[17:18] <tgardner> not the FEC, but the other platform driver
[17:18] <ogra> oh, the OMAP4 one ?
[17:18] <tgardner> yeah
[17:18] <ogra> not sure thats in our kernel tree already
[17:18] <ogra> but if so, its in the omap4 tree
[17:19] <ogra> ndec should be able to tell
[17:19] <tgardner> unless it was part of Bryan's pull request
[17:19] <ndec> tgardner: in the omap4 branch. in the ubuntu kernel. in drivers/dsp/syslink
[17:19] <tgardner> ndec, cool, lemme take a look
[17:22] <Hellwarrior> HI
[17:22] <Hellwarrior> hey anyone in here familiar with the i.mx31
[17:24] <davidm> Hellwarrior, we don't support the iMX31, it is not an ARMv7 sorry
[17:24] <Hellwarrior> oh would you know where I can go to ask??
[17:25] <GrueMaster> Hellwarrior: I believe debian would work with it.  check their channels.
[17:26] <Hellwarrior> okay
[17:26] <davidm> That was my thought too
[17:26] <GrueMaster> I know the chumby is based on that proc.
[17:27] <davidm> I "think" it's an ARMv5 or v6 but not sure, just know for sure it's not a v7
[17:27] <Hellwarrior> just basically I am trying to open up a bin file to view its contents with no luck I ran it thru a tool I found on the freescale site and it spit it out a .s19 file
[17:27] <Hellwarrior> not sure where to go from there
[17:28] <Hellwarrior> actually I think it runs an arm 11 core
[17:29] <Hellwarrior> basically I took a .bin update file a converted it into that s19 file but not sure how to view its contents
[17:38] <davidm> ARm 11 core would be ARMv6 then
[17:42] <davidm> Sorry I don't know anything about .s19 files
[18:22] <cwillu_at_work> rcn-ee, was out of the office last week;  thanks for looking into that though
[18:23]  * cwillu_at_work looks forward to the latest shiny kernel
[20:26] <ogra_cmpc> NCommander, [20:26] <ogra_cmpc> Tue Jun 29 20:23:29 BST 2010
[20:26] <ogra_cmpc> http://acorn.buildd/~buildd/LiveCD/maverick/ubuntu-netbook-omap/current/livecd.ubuntu-netbook.ext3:
[20:26] <ogra_cmpc> 20:23:29 ERROR 404: Not Found.
[20:32] <tgardner> ndec, mpoirier: I sent some patches to Bryan Wu that modularize the syslink drivers. Lets see what he thinks about it.
[20:33] <mpoirier> tgardner: do you see any problem with a package modifying /etc/modules ?
[20:33] <tgardner> mpoirier, dunno, I gotta look up policy on that.
[20:34] <lool> mpoirier: It would seem you have less risky alternatives before going to that, like adding a new upstart job which loads your module
[20:34] <tgardner> mpoirier, I'm pretty sure its part of initramfs-tools
[20:34] <lool> tgardner: module-init-tools.postinst seems to create it here
[20:35] <tgardner> lool, ah, thats the place
[20:35] <ogra_cmpc> as i said, its no prob to modify it
[20:35] <ogra_cmpc> we can do that on first boot of the image
[20:35] <tgardner> lool, I'll let Bryan figure it out since he has the HW
[20:35] <ogra_cmpc> tgardner, he doesnt
[20:35] <lool> I personally tend of think of it as an user configuration file and would keep away from touching it automatically; I suppose you could technically arrange to add stuff to it, but that doesn't seem terribly nice
[20:37] <ogra_cmpc> lool, we did that before for psaux or lp modules
[20:37] <ogra_cmpc> i dont see a prob with adding stuff to it before a user can even touch it
[20:38] <lool> fuse-utils does something along the lines of adding stuff to /etc/modules
[20:38] <lool> It poses challenges such as actually allowing an user to disable that behavior (disabling the module loading)
[20:38] <ogra_cmpc> not anymore since jaunty or so
[20:39] <ogra_cmpc> as you said, its a user config file, so a user can remove the line we add
[20:39] <lool> I really recomment a trivial upstart job instead myself, but it seems we're only discussing workarounds when the fix to emit an event and process it from the kernel is already known
[20:39] <ogra_cmpc> right
[20:39] <lool> ogra_cmpc: The package has to be careful to honor that when its upgraded though
[20:39] <lool> anyway
[20:39]  * lool => &
[20:40] <ogra_cmpc> lool, no package involved, jasper can do it
[20:40] <ogra_cmpc> thats the reason we have it :)
[21:08]  * ogra_cmpc is desparate
[21:33] <armin76> ogra_cmpc: mariachi? :D
[23:44] <rcn-ee> cwillu_at_work, what you went on a vacation? ;)