[00:01] <delinquentme> so beagle boards run ubuntu ... how does one take a beagleboard and begin putting specific code on it? is it a USB connection?
[00:01] <delinquentme> and its run in the linux environment right?
[00:02] <scientes> delinquentme, yeah it has a RW sd card
[00:02] <scientes> delinquentme, but binaries have to be compiled for ARM, x86 binaries wont run
[00:03] <delinquentme> and this can be written in any language that can compile to ARM?
[00:03] <scientes> correct
[00:03] <scientes> or any interpreted language, that has interpreter support on ARM
[00:04] <delinquentme> and how about the operation ... that code simply polls over and over ?
[00:04] <scientes> and to be apecific armv7, which is what ubuntu targets
[00:04] <scientes> delinquentme, linux is "tickless"
[00:04] <delinquentme> its running *inside* the ubuntu operating system right? much like any language I run on my laptop ubuntu system
[00:04] <scientes> so it only wakes up to meet the next deadline, if it doesn't get an interrupt
[00:05] <scientes> yes it is the same ubuntu you run on your laptop, but recompiled for arm
[00:05] <scientes> debian GNU/Linux did most of the porting work/troubleshooting
[00:05] <delinquentme> and the code would be automatically read from the SD card?
[00:06] <scientes> but armv7 hardfloat transition has been helped by ubuntu
[00:06] <scientes> delinquentme, its just ext4 filesystem like you use on your hard drive
[00:06] <scientes> so it has files just the same, and with the same layout
[00:06] <scientes> delinquentme, you can actually run the beagleboard software on your laptop, using qemu-arm
[00:06] <scientes> or qemu-arm-static
[00:07] <delinquentme> so If i've got a desktop which connects to the beagleboard via ethernet ... and I want the beagle to issue machine commands to MCs that branch off of it
[00:08] <scientes> " machine commands to MCs that branch off of it"
[00:08] <scientes> i have no idea what you are saying here
[00:08] <delinquentme> the beagle runs whatever compiled arm and would then issue commands via that beagleboard software to those branch MCs
[00:08] <scientes> you can run all the same server software on e arm that you can run on x86
[00:08] <scientes> postfix, dovecot, postgresql, etc
[00:09] <scientes> now, the beagleboard is not the fastest arm board
[00:09] <delinquentme> basically the beagle controlling a number of attached MCs
[00:09] <scientes> what is a MC?
[00:09] <delinquentme> microcontroller
[00:09] <scientes> specifically.....?
[00:09] <delinquentme>  ( sorry ) but yeah I'm trying to use the beagle to run steppers and the like
[00:10] <delinquentme> been looking at this one : http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/DM00037955.pdf
[00:10] <delinquentme> ~ 13 of those
[00:10] <scientes> well that has yet another arm cpu inside of it
[00:11] <scientes> however it has too little ram and flash to run linux
[00:11] <delinquentme> oh yeah im not trying to run linux on those
[00:11] <delinquentme> those are what controls the steppers and the sensors etc
[00:11] <delinquentme> which then geed information back to the beagle
[00:11] <delinquentme> geed = feed*
[00:12] <scientes> is that black on the bottom audio?
[00:12] <scientes> and the top usb is just the power (5v)?
[00:12] <scientes> "one audio DAC" yeah, audio
[00:13] <delinquentme> i think theres also a 5v in
[00:14] <scientes> seems to me that you use the "SWD" to communicate to it
[00:15] <scientes> "digital accelerometer and digital
[00:15] <scientes> microphone, one audio DAC with integrated class
[00:15] <scientes> D speaker driver, LEDs and push buttons and an
[00:15] <scientes> USB OTG micro-AB connector.
[00:15] <scientes> "
[00:15] <scientes> so i guess that is what it does
[00:15] <delinquentme> how to check if it can run communications over the micro usb
[00:15] <scientes> well since it says that all that is needed, it probably can
[00:15] <scientes> what do you want to do with it?
[00:16] <delinquentme> make a liquid handling robot
[00:16] <delinquentme> it has a number of modular cores
[00:16] <scientes> that thing seems to be audio-oriented
[00:16] <scientes> microphone and mono audio out
[00:17] <delinquentme> yeah I'm not really sure how the MC industry works
[00:17] <scientes> "digital microsoft" (does that mean it has a ADC ?)
[00:17] <delinquentme> like it can send signals and thats all I really need
[00:17] <delinquentme> i could probably go much simpler TBH
[00:17] <scientes> gcc supports compiling firmware IIRC
[00:17] <scientes> its the arm-non-gnueabi target for armv5+
[00:17] <scientes> *none
[00:17] <delinquentme> but I dont have the capability to design printed circuit boards ... so i need to buy something thats already assembled
[00:19] <scientes> and it only has one usable button
[00:19] <delinquentme> so yeah just write come C code .. compile it with GCC stick it on a MC like that and let it poll for commands from the beagle
[00:19] <delinquentme> yeah I don't really see myself using anything other than a reset button
[00:19] <scientes> well, event-based would sure be nicer
[00:20] <scientes> delinquentme, you can do that without any MC
[00:20] <scientes> you can do that with a seial port
[00:20] <scientes> or even a usb keyboard/mouse
[00:21] <delinquentme> well for programming it I can attach it however
[00:21] <scientes> but yeah that board is designed for audio uses, it doesn't seem applicable for you
[00:23] <delinquentme> how does one go about finding a good board for an application?
[00:23] <scientes> all the IC vendors have huge lists
[00:23] <delinquentme> ( i'm kind of expecting there to be a tool like new egg where there are drop downs and I select the chips and things I want on it
[00:23] <scientes> freescale, marvell, broadcom
[00:23] <scientes> newark
[00:23] <delinquentme> and these are all programmed effectively the same way?
[00:24] <scientes> well im still not sure what youwant/are trying to do
[00:25] <scientes> arduino is pretty hot these days
[00:25] <delinquentme> true but they're also super costly
[00:26] <scientes> so is the beagle board
[00:26] <delinquentme> ahh yeah that might help :D  .. I've got 2 steppers, 1 linear string pot, 1 linear actuator and 2 physical switches
[00:26] <scientes> compared to, like, the rasberri pi
[00:28] <scientes> delinquentme, how about this: http://www.st.com/stonline/stappl/productcatalog/app?page=productSelectorPage
[00:30] <delinquentme> oooooo
[00:30] <scientes> http://www.freescale.com/webapp/sps/site/application.jsp?code=APLSTEMOT
[00:34] <delinquentme> DSC ?
[00:34] <delinquentme> Digital Signal Controller
[00:36] <delinquentme> actually I should totally be able to email customer support @ these places and just be like
[00:36] <delinquentme> "this is what I need"
[00:36] <delinquentme> does u have?
[00:36] <delinquentme> also!
[00:36] <delinquentme> these are all chips .. is there a name used for the units when they're already attached to a board?
[00:38] <scientes> yeah ive come across that prob too
[00:38] <scientes> i dont really have an answer for you
[00:40] <delinquentme> haha im glad im not nuts :D
[00:40] <delinquentme> scientes, what do you do with all this coolness
[00:40] <delinquentme> specifically ubuntu arm chips?
[00:41] <scientes> well i actually dont have a armv7 comp yet
[00:41] <scientes> i only have the sheevaplug
[00:41] <scientes> which is armv5, running debian
[00:42] <scientes> but i really want a armv7, or better yet armv8 + quad core
[00:42]  * scientes wants to experiment with big.LITTLE too
[00:42] <delinquentme> OOo the sheevaplug
[00:42] <delinquentme> thats like mischief no?
[00:42] <scientes> its kinda old now
[00:43] <delinquentme> is this like PHD research scientes ?
[00:44] <delinquentme> you can basically hook that sheevaplug up to something and just let it sniff away at wireless packets
[00:46] <scientes> the one i have doesn't have wifi
[00:47] <scientes> but considering its size and power consumption that sort of use would certainly be feasable
[00:47] <scientes> and a good fit for the device
[00:47] <scientes> it also has gigabit ethernet, so you could access it remotely at high speed
[02:08] <pnphi> configure: error: "PAM libraries not found"
[02:08] <pnphi> how to fix ?
[02:11] <pnphi> configure: error: "PAM libraries not found"  how to fix ?
[02:13] <scientes> pnphi, what piece of software?
[02:14] <pnphi> i'm building the package gdm
[02:15] <twb> This error is coming from ./configure ?
[02:16] <pnphi> no , dpkg-buildpackage -aarmel
[02:16] <scientes> pnphi, could be systemd-logind's pam module
[02:17] <scientes> try turning off systemd
[02:18] <pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
[02:18] <pnphi> and this problem
[02:19] <twb> pnphi: pastebin the full transcript
[02:19] <pnphi> detail ?
[02:25] <infinity> I assume you're missing libpam-dev.
[02:26] <twb> infinity: I thought dpkg-buildpackage would, like debuild, bitch about missing dependencies before getting to that point
[02:26] <infinity> It does.
[02:26] <twb> So he's doing something silly.
[02:26] <twb> And the pastbin will tell us what
[02:26] <infinity> But he may well either (A) have built with -d, or (B) be building sources with bad build-deps.
[02:27] <twb> Nod
[02:28] <infinity> (When you call debuild, it's dpkg-buildpackage that's bitching; debuild is only a very thin wrapper around it)
[02:58] <pnphi> checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2
[02:59] <pnphi> I don't know to fix this problem
[02:59] <pnphi> !!!
[03:00] <scientes> pnphi, PASTE
[03:02] <pnphi> checking for pam_start in -lpam... no
[03:02] <pnphi> configure: error: "PAM libraries not found"
[03:02] <pnphi> make: *** [debian/stamp-autotools] Error 1
[03:02] <pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
[03:02] <pnphi> E: Failed autobuilding of package
[03:03] <scientes> pnphi, did you install libpam-dev?
[03:04] <pnphi> yes
[03:04] <scientes> pnphi, paste dpkg -L libpam-dev
[03:04] <pnphi> libpam0g-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[03:04] <scientes> pnphi, paste dpkg -L libpam0g-dev
[03:04] <twb> infinity: I realize that; I just don't remember which bits are still debuild-specific
[03:06] <pnphi> yes
[03:10] <pnphi_> so what else ?
[03:10] <pnphi_> dpkg -L libpam0g-dev
[03:10] <pnphi_> usr/share/doc/libpam0g-dev
[03:10] <pnphi_> usr usr/share usr/share/doc usr/share/doc/libpam0g-dev usr/share/doc/libpam0g-dev/examples usr/share/doc/libpam0g-dev/examples/vpass.c usr/share/doc/libpam0g-dev/examples/modules usr/share/doc/libpam0g-dev/examples/modules/pam_secret.c.gz usr/share/doc/libpam0g-dev/examples/modules/Makefile usr/share/doc/libpam0g-dev/examples/xsh.c.gz usr/share/doc/libpam0g-dev/examples/check_user.c usr/share/doc/libpam0g-dev/examples/agents usr/s
[03:10] <twb> pnphi_: http://paste.debian.net
[03:11] <pnphi_> what is it ?
[03:11] <twb> pnphi_: you put your text there, hit "submit" and copy the resulting link here, rather than pasting the original text here
[03:11] <twb> This is called a "pastebin", it stops us going insane
[03:13] <pnphi_> ok
[03:14] <pnphi_> paste.debian.net/163365/
[03:17] <pnphi_> http://paste.debian.net/163366/
[03:17] <pnphi_> Log of build and result of "dpkg -L"
 checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2
[03:20] <scientes> specifically -lpam
[03:20] <scientes> there is no pam.h....doesn't -lpam require pam.h?
[03:21] <pnphi_> i don/t understand
[09:23] <janimo`> ogra_, hi, which packages needed to be touched to get unity-3d gles working? nux, compiz+unity?
[09:24] <janimo`> I'd like to to do a GLES rebuild for x86 and touch the minimum numer of packages locally
[09:27] <ogra_> nux, unity, compiz and compiz-plugins-main
[09:27] <ogra_> just grab the packages in precise, they are ready
[09:27] <ogra_> you will need to change the arch checks etc
[09:28] <janimo`> ogra_, and all of them need an extra config option passed, none do runtime detection right?
[09:28] <ogra_> right
[09:28] <janimo`> ogra_, thanks!
[09:28] <ogra_> talk to alf_ for a different patch set
[09:29] <janimo`> ogra_, for now the ones in precise are fine if they actually work with gles
[09:29] <ogra_> iirc the new one they have in linaro can run with GL and GLES enabled
[09:29] <ogra_> not sure when you have to select or if its automatic at all though
[09:29] <janimo`> ogra_, ah they already hae packages for that, I'll ask him then
[11:43] <LetoThe2nd> infinity: ping
[11:45] <infinity> LetoThe2nd: pong?
[11:45] <LetoThe2nd> infinity: ogra told me ask you:
[11:45] <LetoThe2nd> any ideas why http://paste.pocoo.org/show/582316/ goes bi***ing about some dependency issues concerning linux-libc-dev:i386 and linux-libc-dev in a clean 12.04 chroot, and if you just re-run it, everything is fine? dependency solver problem?
[11:46] <infinity> LetoThe2nd: Temporary annoyance with a transition.  If you add precise-proposed to your sources.list, it'll be happy.
[11:46] <infinity> LetoThe2nd: Should be resolved in ~5 hours when gcc-4.6 is built everywhere, and I can promote gcc and eglibc to release.
[11:46] <LetoThe2nd> infinity: ahkay. nothing urgent, so will probably be sorted out soon?
[11:46] <LetoThe2nd> i see, thx then.
[11:46] <ogra_> infinity, compiz-plugins-extra (universe) is FTBFS on all arms with the new GLES compiz, should we leave it that way, or upload a package that has the arm arches dropped for final release ? (i dont think anyone ever cared in a port to GLES for these plugins)
[11:47] <infinity> ogra_: Ugh, really?  Is it not a simple fix?
[11:47] <infinity> rsalveti: Hey, wake up and come be helpful.
[11:48] <ogra_> i dont think linaro ever touched that package (not needed for unity) and afaik all GL->GLES switches need heavy patching
[11:48] <infinity> ogra_: Dropping the arches isn't necessary, but fixing it would be nice.
[11:48] <ogra_> (more than just a config option)
[11:48] <infinity> Needs heavy patching for plugins?  That seems wrong.
[11:49] <ogra_> well, even in our normal compiz build on arm we have to disable more than half of the plugins
[11:49] <ogra_> because the functions arent patched yet, i doubt its fixable in time for release and i also doubt linaro will ever care for these plugins
[11:49] <infinity> Letting it be FTBFS is fine.  As you note, it's universe.
[11:50] <infinity> We just need to remove the stale binaries.
[11:50] <ogra_> right, and makes SRUing a possible fix easier
[11:50] <infinity> And wow, compiz-plugins-main-gles2.patch is extensive.
[11:50] <ogra_> i still try to catch alf_ or rsalveti to find out if they ever plan to fix that
[11:50] <ogra_> right
[11:50] <infinity> What an awful architecture compiz is...
[11:50] <ogra_> well, compared to the compiz patch its still small :)
[11:51] <infinity> The GNOME people really got this right with cogl.
[11:51] <ogra_> well, we should just switch to Qt
[11:51] <ogra_> unity-2d ftw
[11:51] <ogra_> but i promised kaleo to not rave about that for a year :)
[11:51] <infinity> Heh.
[11:52] <infinity> I prefer 2d anyway.
[11:52] <infinity> To each their own, though.
[11:52] <ogra_> yeah, and it shouldnt be to hard to get all the functions in that 3D has
[11:52]  * ogra_ completely reinstalled his ac100 this weekend from ubuntu-core 
[11:53] <ogra_> using lxde now
[11:53] <ogra_> so much more free ram !
[11:53] <ogra_> (needed a reinstall to switch to hf)
[11:54] <ogra_> using -core as a base it a big pain in the butt though ...
[11:54] <infinity> Well, yes.
[11:54] <infinity> It has no installer. :P
[11:55] <ogra_> yeah
[11:55] <ogra_> well, and getting the bootloader setup working by hand isnt really fun
[11:55] <LetoThe2nd> <3 debootstrap
[11:55] <infinity> I'd suggest feeding core to linaro-image-tools (which works really well), but I assume they have no ac100 target.
[11:55] <ogra_> LetoThe2nd, -core is essentially debootstrap --minbase
[11:55] <ogra_> iirc
[11:55] <ogra_> yeah, ac100 is spethial
[11:56] <LetoThe2nd> ogra_: ah yea.
[11:56] <infinity> I don't mind my ac100 with unity-2d, but the RAM starvation does hurt.
[11:56] <ogra_> the prob with the ac100 is to get it to a point where you can use the wlan for further install ... thats a real PITA starting from core
[11:56] <infinity> I had some builds failing on it because of that.
[11:56] <ogra_> right, with lxde my system now uses 75MB with the idling desktop
[11:57] <infinity> ogra_: Hahaha.  Yeah, my first ac100 install was from core, and involved a whole lot of wgetting and dpkg -i, and head-scratching.
[11:57] <ogra_> thats half of what unity-2d uses
[11:57] <infinity> I don't really know what posessed Toshiba to only put 512MB on the thing.
[11:57] <ogra_> adnroid
[11:57] <infinity> If they wanted to be competitive with crappy Atom netbooks, they all have 1G.
[11:58] <fhilly> Hi All
[11:58] <ogra_> i dont think that was the plan with the ac100
[11:58] <infinity> Yeah, I suppose it was Android-specific.
[11:58] <infinity> But even Android breathes more easily with 1G.
[11:58] <ogra_> its more like a POC of using android on netbooks
[11:58] <ogra_> well, it is using 2.1 in the original setup ... that doesnt need much ram ... and has not many apps :)
[11:59] <infinity> It's the one thing I'd change about my phone, if I could (and the only reason I might look for upgrades)
[11:59] <fhilly> anyone have detailed documentation on the architecture and packages on Ubuntu core rootfs?
[11:59] <LetoThe2nd> hrhrhrhr
[11:59] <ogra_> theer should be a manifest file in the download dir
[11:59] <infinity> Is there?
[11:59] <ogra_> that has the packagelist
[11:59] <ogra_> infinity, if there isnt ... it *should* :)
[11:59] <infinity> Oh look, I do publish the manifest.
[12:00] <infinity> Go me.
[12:00] <ogra_> (there is)
[12:00] <ogra_> fhilly, http://cdimage.ubuntu.com/ubuntu-core/daily/current/ ...
[12:01] <ogra_> and http://cdimage.ubuntu.com/ubuntu-core/releases/ for released images
[12:01] <fhilly> thanks ogra, I assume there is detailed information in there?
[12:01] <ogra_> fhilly, well, there are the manifests and you can see which arches it is built for
[12:02] <fhilly> how about rootstock? is it still maintained?
[12:02] <ogra_> no
[12:02] <fhilly> thanks ogra
[12:02] <ogra_> hmm, that remonds me i should probably file a removal bug for the package
[12:02] <fhilly> ok, if I want to get involved in the building process of the Ubuntu core rootfs, is there any specific root advised?
[12:03] <ogra_> we use live-build (config files for that are in livecd-rootfs) to roll it
[12:03] <ogra_> just take a look at the source of these
[12:03] <infinity> ogra_: I'll happily remove rootstock right now, no need for a bug.
[12:03] <ogra_> infinity, go for it !
[12:03] <infinity> ogra_: But I think you should do something about the LP project too.
[12:04] <ogra_> yeah, i'll kill it
[12:04] <fhilly> ok thanks a lot
[12:04] <ogra_> or at least mark it inactive or so
[12:04] <ogra_> there are some good code snippets in rootstock i wouldnt like to lose
[12:05] <ogra_> (the fifo to serial interaction with qemu for example to do stuff scripted inside a VM)
[12:05] <fhilly> well, I have tried ubuntu-core rootfs on x86, however I believe there is "sudo" package missing, as the user will not be able to install anything including "sudo" unless unlock the files system as sudo or su user
[12:05] <ogra_> fhilly, thats on purpose
[12:06] <ogra_> ubuntu-core is to *build* images on top (or as an easy to use base for a chroot), not actually to use it as an install base ...
[12:07] <infinity> sudo would be kinda useless given that there's also no user.
[12:07] <infinity> rootstock | 0.1.99.4-0ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc
[12:07] <infinity> rootstock-gtk | 0.1.99.4-0ubuntu1 | precise/universe | all
[12:07] <LetoThe2nd> infinity: one could make an alias called "medo" that root himself can use.
[12:07] <infinity> ogra_: ^--- That rootstock?
[12:07] <ogra_> the typical usecase is for something like embedded IVI systems (car entertainment) where you wont even have a user account  thats accessible by the ednuser
[12:07] <ogra_> \o/
[12:07] <ogra_> infinity, yeah
[12:08] <ogra_> funny, i didnt know we built it for armel/armhf ...
[12:08] <fhilly> forgive my ignorance but can you tell me why? as in the short explanation of it, it says after you finish you can use pat-get, how can we use apt-get if we don't have sudo? I am new to community stuff and I am trying to get involve so I know I am asking too much
[12:08] <fhilly> ok I see
[12:08] <LetoThe2nd> ogra_: haven't you noticed all the people in #pandaboard who asked about starting from -core because the sound of the name suggested a more minimal image to them?
[12:09] <infinity> And it is a minimal image.
[12:09] <infinity> It just also has no installer.
[12:09] <fhilly> lets say I want to build Ubuntu distro for ARM (beagle board) can I do it based on Ubuntu -core rootfs, or there is a better way of doing things?
[12:09] <ogra_> well, it is
[12:09] <ogra_> but you need to do a ton of things manually depending on your usecase
[12:09] <infinity> ogra_: Removed, should be gone in the next publisher run.
[12:10] <ogra_> fhilly, well, i would just use one of the official beagle images from ubuntu for that
[12:10]  * ogra_ hugs infinity 
[12:10] <fhilly> is there any detailed documentation about it? guys I see you know everything about it, instead of me asking you, I could just read and get back to you if I have any questions
[12:10] <ogra_> if you want a minimal install on your beagle, use the server image
[12:11] <ogra_> see https://wiki.ubuntu.com/ARM/OMAP for instructions etc
[12:12] <ogra_> if you want even more flexibility, use the netinstall SD card image
[12:12] <fhilly> orga_ I am trying to get as much information as I can, as I would liek to be part of the community at one point, and contribute. it is not about the BeagleBoard only
[12:12] <ogra_> (falsely called netboot on that wikipage) ... but nore that you nedd a network connection wired up for thet indeed
[12:13] <ogra_> well, just hang out in this channel ... thats already a good step to being involved in the community ;)
[12:13] <LetoThe2nd> fhilly: and, hint: tabcompletion for nicks works in any sane IRC client :)
[12:14] <fhilly> ok thanks LetoThe2nd
[12:14] <fhilly> it works
[12:15] <fhilly> as a starting point for me, where can I start contributing? in terms of anything I could do?
[12:15] <LetoThe2nd> oO( purge errors out of omappedia/elinux *duckandrun* )
[12:15] <ogra_> http://qa.ubuntuwire.org/ftbfs/ ... you could for example have a look at all packages that only fail on armel/armhf
[12:16] <ogra_> or weed through launchpad and look for bugs that the ubuntu-arm team is subscribed to
[12:16] <fhilly> then try to fix it, and report back?
[12:16] <ogra_> if you have HW you can help testing images right before milestone (or final) releases
[12:16] <ogra_> right
[12:16] <fhilly> ok
[12:17] <fhilly> I have BeagleBoard XM rev: C4 and BeagleBone
[12:17] <fhilly> any testing procedures?
[12:18] <janimo`> infinity, !! I started using a caching proxy and it's great! apt-cacher-ng
[12:18] <janimo`> which year are you welcoming me into?
[12:19]  * ogra_ uses approx 
[12:20] <janimo`> I just picked this one as at one point in one of the mailing lists it was mentioned it more or less works out of the box
[12:21] <janimo`> and it indeed does, besides putting a line in apt.conf
[12:21] <ogra_> approx as well and i find it easier to configure for special cases like ports.u.c
[12:21]  * infinity just has a local Ubuntu and Debian mirror.
[12:22] <infinity> ... running on an i.MX53
[12:22] <ogra_> http://www.grawert.net:9999/ubuntu-ports ... :)
[12:22] <ogra_> thats my laptop
[12:22] <janimo`> ... uphill
[12:22] <ogra_> (as long as i dont take it with me indeed (which i really rarely do since i have the ac100))
[12:27] <fhilly> how can I test the images before release? where can I get them from? can I subscribe to get notifications?
[12:34] <LetoThe2nd> fhilly_: they're all up on the servers
[12:35] <LetoThe2nd> fhilly_: http://cdimage.ubuntu.com/daily-preinstalled/current/ for example
[12:36] <morphis> LetoThe2nd: you know with which tool the images are build? live-build?
[12:37] <LetoThe2nd> morphis: no idea.
[12:37] <morphis> infinity: you know how they are build?
[12:38] <infinity> Which images?
[12:38] <infinity> But yes, we use live-build to create live/preinstalled filesystems.
[12:39] <morphis> infinity: the images you can download from here: http://cdimage.ubuntu.com/daily-preinstalled/current/
[12:39] <ogra_> fhilly_, for testing you can subscribe to teh images you want to be notified about on http://iso.qa.ubuntu.com/
[12:40] <infinity> morphis: live-build to create the filesystem, and then some hackery on top of that to make it bootable.
[12:40] <morphis> infinity: means installing system dependent files (fstab,kernel-modules, ...)
[12:41] <ogra_> kernel modules come from the kernel package ... fstab and HW sepcific bits usually come from the installer
[12:41] <infinity> And creating a FAT filesystem, and populating it with a bootloader and kernel, and...
[12:41] <fhilly_> ogra_, LetoThe2nd thanks
[12:41] <morphis> infinity: ok
[12:46] <fhilly_> what do I have to do? just install them? do something specific? run scripts? or just work as normal?
[15:32] <djszapi> Hey! Is it okay if the daemon part of my project is started automatically by an upstart job put into the /etc/init/ folder with the ubuntu desktop version ? Is there a better interface for that like we had /etc/init/apps on Harmattan ?
[15:57] <pnphi> i don't know to fix this problem
[15:57] <pnphi> checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2
[15:58] <ogra_> pnphi, just add the right dependency to your packge (or if you dont build a package, make sure to have the right -dev package installed that gives you the pam headers
[15:58] <ogra_> )
[15:59] <pnphi> detail ?
[15:59] <ogra_> djszapi, i dont know /etc/init/apps, but upstrart is surely a proper way to start daemon processes
[16:00] <ogra_> pnphi, well, its your project, you should know what deps you need to build whatever you build there
[16:00] <djszapi> ogra_: start on runlevel [23] or [12345] ?
[16:00] <pnphi> so...i install deps of package
[16:00] <pnphi> !!!
[16:00] <ogra_> well, usually runlevels are moot anyway :) all debian and ubuntu systems default to 2
[16:01] <pnphi> what runlevel ?
[16:01] <ogra_> (so [2 3<9 should be good)
[16:01] <ogra_> err
[16:01] <ogra_> [2 3]
[16:02] <pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
[16:03] <pnphi> what the err ?
[16:03] <ogra_> read your build log it should say
[16:04] <djszapi> ogra_: runlevel 5 means for instance "Start the system normally with appropriate display manager. ( with GUI )"
[16:04] <ogra_> djszapi, it doesnt
[16:05] <djszapi> ogra_: http://en.wikipedia.org/wiki/Runlevel#Typical_Linux_runlevels
[16:05] <ogra_> (nmot sure where you got that line from, but on debian based systems runlevel 2-5 are identical)
[16:05] <ogra_> 1 is singleuser, 6 is reboot
[16:07] <ogra_> (and 0 is halt)
[16:07] <djszapi> read the link.
[16:07] <pnphi> configure.ac:3: warning: AC_INIT: not a literal: http://bugzilla.gnome.org/enter_bug.cgi?product=gdm if [ -e ./Makefile.am ]; then cd . && automake-1.11  ; fi configure.ac:3: warning: AC_INIT: not a literal: http://bugzilla.gnome.org/enter_bug.cgi?product=gdm data/greeter-autostart/Makefile.am:10: `%'-style pattern rules are a GNU make extension automake-1.11: cannot open < gnome-doc-utils.make: No such file or directory make: *** 
[16:07] <pnphi> oh my god
[16:07] <djszapi> and I have the desktop version of ubuntu on my pandaboard.
[16:07] <ogra_> how would reading thge link change anything ?
[16:07] <djszapi> the linux runlevels are defined in there...
[16:08] <ogra_> no, they arent ... someone wrote up how the runlevels on his fedora box look like i guess
[16:09] <ogra_> first of all, runlevels are moot, upstart is event based and only retains the runlevel concept for backwards compatibility ... if you develop something from scratch i would rather tie to an even than to a runlevel ....
[16:10] <ogra_> and second, i onlycan repeat (for the last time now) runlevels 2-5 are identical on debian based systems)
[16:10] <djszapi> what would you recommend to me, if my goal is to run my binary during the bootup ?
[16:11] <ogra_> rsalveti, poke ... seems compiz-plugins-extra FTBFS with the new compiz
[16:11] <djszapi> that is the trigger event.
[16:11] <rsalveti> ogra_: oh well, let me check
[16:11] <ogra_> rsalveti, well, i didnt expect anyone to have a patch or so, just wanted to make sure i'm right
[16:11] <ogra_> its a universe package etc etc blah blah ...
[16:12] <rsalveti> plugins-main is the one needed, this extra might not be useful in the end
[16:12] <ogra_> djszapi, well, what does your daemon do ? i.e. for a network based service i would tie to a network-up event for something related to HW i would tie to a udev event
[16:12] <djszapi> start on runlevel [23] stop on runlevel [!23]
[16:12] <djszapi> I had the impression I should do something like that for this goal.
[16:13] <rsalveti> janimo`: there's a runtime detection for unity for gles as well
[16:13] <ogra_> rsalveti, yes, thats what i thought, just wanted to look if you guys possibly have a patch
[16:13] <djszapi> ogra_: listening to the serial port, and act accordingly for the incoming data.
[16:13] <djszapi> so prolly udev.
[16:13] <rsalveti> janimo`: /usr/lib/nux/unity_support_test -p
[16:13] <rsalveti> ogra_: I'll check
[16:13] <ogra_> djszapi, well, either use the runlevel or take a look if there is a udev event when the serial device shows up
[16:25] <pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
[16:25] <pnphi> @ @
[16:26] <ogra_> read the log, find the error, fix it :)
[16:38] <janimo`> rsalveti, yes, ran that already and works fine, still unity still crashes on logon
[16:39] <djszapi> ogra_: I am unsure if there is an udev event for that.
[16:58] <smplman> are there any updates on SGX for omap3?
[17:10] <ben_> Out of interest.
[17:10] <ben_> Does the l-cache actually destroy back to back compatibility with prior programs?
[17:10] <ben_> Because it forces ARM into a modified Harvard Architecture...
[17:11] <ben_> Take for example the case where you write over and instruction, but the l-cache keeps a prior version and then executes the prior version.
[17:11] <ogra_> djszapi, so just take [23]
[17:11] <ben_> You have to force the cache to clear...
[17:11] <djszapi> ogra_: might fail if udev is not up yet
[17:12] <djszapi> since connecting to the serial port depends on the udev
[17:12] <ogra_> udev comes up in initrd
[17:12] <djszapi> so it is guaranteed my binary would be run later ?
[17:12] <ogra_> and i think also before the runlevels start
[17:13] <ogra_> ogra@horus:~$ grep "start on" /etc/init/udev.conf
[17:13] <ogra_> start on virtual-filesystems
[17:13] <djszapi> so ?
[17:13] <ogra_> yup ... udev comes up with /proc, /sys and friends
[17:13] <ogra_> way before anything cares for runlevels
[17:16] <djszapi> fine :-)
[17:16] <djszapi> does the kernel care about the proper respawning ? Say, I open the serial port while launching the daemon, and I would ideally close the serial port while stopping.
[17:16] <djszapi> what if the daemon dies, and there is a respawning ?
[17:17] <djszapi> there is a proper serial port close and then open again ?
[17:19] <ogra_> no, not the kernel ... init does (well upstart in our case)
[18:01] <djszapi> ogra_: is "stop on runlevel [!23]" fine for stopping ?
[19:27] <recur> is there an arm equivalent to dmidecode ?
[19:31] <infinity> recur: That would imply there was such a thing as device tables on ARM.
[19:31] <recur> Hi infinity
[19:31] <recur> ah, so I'm completely out of luck then :)
[19:31] <infinity> Pretty much.
[19:31] <recur> I wanted to programmatically get my hardware serial, but I've used dmidecode for that in the past.
[19:31] <recur> thanks for the info!