[04:25] anybody know where I can get a static version of libpthread for the gcc-arm-4.5 compiler? === JaMa|Zzz is now known as JaMa|W [07:34] hi [07:40] compile some source packages, them need depend other package [07:40] where are there package depend table ? [08:15] asmcos: in debian/control? [08:16] asmcos: sudo apt-get build-dep $yourpackage might do the trick [08:17] asmcos: or you use pbuilder that automatically satisfies build dependencies in the chroot [08:26] oh [08:26] i can get list table? [08:26] about the depend [08:31] asmcos: grep-dctrl -n -s Depends Depends debian/control [08:31] asmcos: does ~ what you want [08:33] example [08:33] python-gtk depend gtk [08:33] gtk depend cario [08:33] cario depend xxx [08:34] so ,i need build python-gtk [08:34] i need build gtk first [08:35] i need the order === hrw|gone is now known as hrw [09:14] re [09:31] * XorA|gone finds the lack of positive feedback when booting ubuntu on beagle disturbing === XorA|gone is now known as XorA [10:08] XorA, ? [10:09] you dont get a splash screen ? [10:20] ogra: DVI is totally dead on release images [10:20] * XorA is finding debugging hard by heartbeat LED [10:23] ah, 3rd reboot I get splash [10:24] * XorA has no idea what it was doing [10:24] XorA, known issue, fix pending .... nicely nobody told us about the rewiring of the latest boards, so a kernel patch is missing [10:25] this is a beagle, not an XM [10:25] oh [10:30] ogra_ac: it seems to be just plain random if dvi comes up :-( [10:30] weird [10:31] sounds more like a HW issue to be honest [10:31] i havent seen or heard about such behavior yet [10:32] not an issue I saw on Angstrom :-( [10:32] * XorA hopes the dust on the board didnt break it [10:35] * XorA gives up and looks at some other toy [11:09] berco, ndec, alsa-utils should be all fixed now, please test [11:09] it also shouldnt matter if the state file exists or not now [11:10] ogra_ac: thanks. we will :) [13:31] ogra_ac: alsa-utils fails to install. I believe some scripts are run under sudo (sudo apt-get install) and it complains. http://pastebin.ubuntu.com/518025/ [13:32] berco, hmm, could you try on a panda ? i tested it here [13:32] didnt have such issues [13:32] ogra_ac: it's on a panda :) [13:33] how can that be ? [13:33] it reports the wrong device name [13:33] ogra_ac: I took the 10.10 .img and configured firewall + proposed, that's it [13:33] hmm [13:34] ogra_ac: let me check, maybe my mistake :) too many boards on my desk [13:34] your kernel definitely is to old [13:34] ogra_ac: I confirm it's on a panda but I didn't upgrade the kernel yet [13:34] ah [13:35] * ogra_ac sighs [13:35] ok so process is to upgrade kernel, i'll do it [13:35] i really dont see a way how to tell alsa-utils to make sure the kernel is new enough [13:35] i cant add a dependency for that [13:35] berco, well, it needs to work automatically [13:36] and we need the alsactl init call once [13:36] else the systems wont be initialized at all and the state file will just save the uninitialized state [13:36] ogra_ac: well in this case, alsa-utils needs to be fixed to depend on a kernel version [13:37] berco: you need to update from maverick-updates before doing the upgrade for maverick-proposed. [13:37] * ogra_ac will never let such stuff slip again into an update, working sound needs to become a requirement pre-release [13:37] ndec, the kernel he needs is also in proposed [13:37] thats my prob [13:37] berco, alsa-utils cant depends on a kernel [13:37] berco: did you run an upgrade, or just install alsa-utils? [13:38] ndec, the prob is that the new kernel will only be there after the upgrade [13:38] ndec: just installed alsa-utils. I was very basic and just read the email I received from Lauchpad [13:38] and als-utils will come in with the same upgrade *before* the kernel is running [13:38] ogra_ac: i see... catch 22 ;-) [13:38] yes [13:38] * ogra_ac curses [13:39] this sound stuff turns into an etarenal problem [13:39] *eternal [13:39] its all trivial ... but fixing it in an upgrade starts to seem impossible [13:39] probably persia has an idea [13:40] i'm clearly running out of ideas [13:41] ndec: ogra_ac: after the upgrade is "sudo flash-kernel" needed? or is it automatically done? [13:41] berco, its all automatic [13:41] waoh! nice :) [13:42] you should also get a notification on the desktop that a reboot is required after a kernel upgrade [13:43] ogra_ac: ok, upgrade is taking place... [13:43] ogra_ac: run the init at next boot instead of in postinst? [13:43] ndec, how ? [13:43] there are only two ways i can run the init [13:44] one is the postinst, the other is from the initscript ... if i run it from the initscrip i can only call it if no state file exists [13:44] else it would run every time and the state file would never restore the mixer settings [13:45] ndec, the core problem is that the driver (unlike all other drivers) needs the alsactl init call [13:47] ogra_ac: can it be called in alsa-utils? if file does not exist then call alsactl init [13:47] berco, thats what alsa-utils does already [13:48] berco, the file always exists if you rebooted once [13:48] the prob is that a) the call is needed at all and b) that we cant call the init on a totally virgin system (since we upgrade we dont know how often the user rebooted already) [13:49] ogra_ac: ok, I think I missunderstood the issue you were discussing. your pb is when the upgrade happens and file exists, tight? [13:49] yes [13:49] s/tight/right/ [13:49] thats what the postinst is supposed to solve [13:49] but i didnt take into account that kernel and alsa arrive at the same time [13:49] even a dependency wouldnt help since the kernel needs to be active first [13:50] (beyond the fact that i cant add a dep on kernel to alsa) [13:50] as nicolas said, its a catch 22 [13:51] but if you are able to notify reboot, it means you know that a kernel upgrade happened. You can just delete state file in this case [13:51] next boot it will be created correctly [13:51] the state file is created on shutdwon [13:52] i would have to do heavy hacks to upstart to not make that happen [13:52] not an option [13:52] hmm [13:52] the whole alsa setup is really not designed to kack around such driver probs in upgrades ... thats the prob [13:52] *hack [13:53] usually drivers properly initialize [13:53] so you dont need such a call [13:53] we need to get that definitely fixed for natty [13:54] in the driver ... [13:54] sadly i have no clue why it doesnt initialize :/ [13:58] ogra, I'm note quite sure what I'm supposed to have an idea about. Is it that you need to run `alsactl init` before asound.state exists, and once asound.state exists, you can never do this? [13:58] s/note/not/ [13:58] persia, i can do this [13:59] persia, new kernel is in proposed ... adding functionallity alsa needs ... alsa update is in proposed, needing the kernel features ... [13:59] persia, both updates arrive together, alsa needs to call alsactl init once to make the card work [13:59] but the init only works if the kernel is actively running [13:59] Ah, but the kernel needs to have already been updated before alsa-utils can be updated? [13:59] yes [13:59] Oh, updated && rebooted. [14:00] right [14:00] `alsactl init` is currently in postinst? [14:00] and in alsas initscript if no state file exists [14:00] the state file is created on shutdwon [14:01] i cant call aslactl init on every boot because that would reset the mixer settings [14:01] Ah, so it can't ever work: either you aren't running the new kernel *OR* you will clobber the user's mixer settings. Is that accurate? [14:02] right [14:02] one evil hack i can imagine is to put an initscript in place that checks the kernel version and the existence of a file we create once alsactl init was run [14:03] With the old notification system, there used to be a way to send an alert to the user that they needed to take action, and they could select there, so we could have a one-time thing that would reset based on user choice on first reboot. [14:03] I don't think that works with the new notificaiton system (no action support). [14:03] right, it wont work with the new system [14:04] That's not that evil a hack, it's basically how the old system worked, except that I'm not sure how to ask the user if they don't mind if we clobber their mixer settings. [14:04] its also still a myth to me why we need to call aslactl init at all [14:04] no other driver needs that [14:04] "myth"? "mystery"? [14:04] yes [14:05] Did mvo fix the debconf dialog bug? [14:05] not yet i think [14:05] i'm not even sure he works on it [14:05] Then I think we can't talk to the user in any sane way. [14:06] Which makes the choices 1) documentation or 2) break custom configurations once. [14:06] even if we could, what would we say ? [14:07] "It appears that your kernel doesn't have support for the SDP4430 audio interface, which is available on your computer. Would you like this to be set up at the next reboot? This will reset any mixer settings you may have adjusted." [14:08] Or something like that. [14:08] and then ? [14:08] how do we set them up at next boot ? [14:08] The user would answer "yes" or "no" and we'd use that information to clobber or not clobber the config. [14:08] that doesnt require a question [14:08] we can clobber the config [14:09] there was no sound support at all before [14:09] Have the postinst run a special script in /var/lib/ if it's present, and delete the script when the script has run once. [14:09] I don't like just clobbering the config very much, but that's easy to do. [14:09] i dont care about the config, since there never was a working one [14:09] we can just wipe it [14:09] Just force-delete asound.state and run `alsactl init` ONCE only after verifying correct architecture and kernel version. [14:10] right [14:10] Some folk may have working USB-audio or something. [14:10] how do i delete the state file ? [14:10] rm [14:10] at boot ? [14:10] after fs mount, obviously. [14:11] upstart cretaes it on shutdown so we need to rm it on boot [14:11] and do that only once [14:11] And only do that when we're clobbering. [14:11] if the file doesnt exist i dont need to do anything [14:11] have the entire thing in a script [14:11] alsactl init is run automatically on device init [14:11] have the script only get installed on panda [14:11] Have the script run only if a supporting kernel is available. [14:11] ugh [14:12] thats realy ugly and hackish [14:12] but unless we have a driver that dosnt need the alsactl init it might be the only option [14:12] Trigger it with something like [ -x ${SCRIPT} ] && "${SCRIPT}" && rm "${SCRIPT}" [14:12] USB [14:12] i dont really see yet how to have that only installed on pandas [14:13] Check for some signature prior to emplacing the script. [14:14] cp it from postinst ? [14:14] Maybe "/var/lib/alsa/SDP4430.cleanup" ? [14:14] alsa-utils turns into a very ugly thing through me [14:14] No, here-file it from postinst. [14:14] hmm [14:15] well, i need an upstart job too [14:15] Why? [14:15] not sure that can come from a here doc [14:15] because something needs to trigger the script [14:15] on boot [14:15] Just modify /etc/init/alsa-mixer-save.conf [14:16] ugh [14:16] thats only run on shutdown [14:16] Ugh, so you need two. Hrm. [14:16] right [14:17] You could add a udev rule that ran the script (if present) on SDP4430 load... :) [14:18] hmm [14:18] apropos udev rules [14:18] ogra@panda:~$ ls /dev/snd/ [14:18] by-path pcmC0D0p pcmC0D12c pcmC0D15c pcmC0D16p pcmC0D18c pcmC0D20c pcmC0D3p pcmC0D5p pcmC0D8c timer [14:18] controlC0 pcmC0D10c pcmC0D13p pcmC0D15p pcmC0D17c pcmC0D19c pcmC0D2c pcmC0D4p pcmC0D6p pcmC0D8p [14:18] pcmC0D0c pcmC0D11p pcmC0D14p pcmC0D16c pcmC0D17p pcmC0D1c pcmC0D2p pcmC0D5c pcmC0D7p pcmC0D9p [14:18] Good use of "apropos" ! Extra points. [14:18] where the heck do the devices get there ? [14:19] s/where/how/ [14:19] ALSA/ASoC [14:19] persia, nope [14:19] we dont create any devices under /dev/snd in maverick [14:19] paste me an lsmod? [14:19] all sound devices are in /dev directly on maverick [14:20] Not on my install. [14:20] persia, but on all others [14:20] Not on *any* of my installs. [14:20] persia, maverick dropped all udev rules that mangle sound device creation [14:20] And most of them are native-maverick rather than upgrades. [14:21] Use of /dev/snd isn't mangling. [14:21] they *have* to live in /dev [14:21] unless the kernel creates them directly in there [14:21] which afaik it doesnt [14:22] persia, grep snd /lib/udev/rules.d/* [14:22] nothing puts them there unless the kernel does it itself [14:22] I still think it's somewhere in /sbin/alsa-utils [14:23] But it wouldn't surprise me if the kernel put them there, really. [14:23] well, it must either be a udev rule or the kernel [14:24] I think "snd" ends up being part of DEV_BASENAME somehow [14:24] i dont have it on my ac100 [14:25] so it must be the kernel [14:25] since i have mavericks alsa [14:25] Quite possibly. [14:25] and mavericks udev [14:25] (talking about my SB play USB card though) [14:25] What happens if you plug that into the panda? [14:26] never tried ;) [14:26] and i'm to lazy to go upstaris atm [14:28] persia, i think i'll drop the whole posinst hackery and hack up /sbin/alsa-utils with a kernel check [14:28] that should DTRT [14:29] Don't. [14:29] http://paste.ubuntu.com/518046/ [14:29] You want the run-once functionality. [14:29] thats what we already have [14:29] i can just touch an additional file [14:30] check state file, check kernel, look for file [14:30] Do a here-file run-once script in the postinst. [14:30] then replace the -f call with [ -x "${SCRIPT}" ] && "${SCRIPT}" && rm "${SCRIPT}" [14:31] te -f call needs to stay [14:31] *the [14:31] thats for virgin installs [14:31] where no state exists [14:31] (natty) [14:32] (and where we indeed have the right kernel in advance) [14:33] Right, but stick that in the run-once script. [14:34] Actually, doesn't matter. Fresh installs can't have asound.state [14:34] And we're force-clobbering it anyway. [14:35] well, for natty my requirement is that the driver behaves properly [14:35] so i hope we wont need that hack at all there [14:35] but until thats the case this code stays wheer it is [14:35] the hack i will add now will be maverick only [14:36] hmpf [14:37] and a have to do a dpkg check [14:37] That's a bad place for the code: you end up running every boot. [14:37] Really, do a run-once script trick in place of the -f business. [14:37] Then in the run-once script do your dpkg-check, -f check, etc. [14:37] yes, like the other hacks in the preinit_levels_on_card() function [14:37] You can always exit 1 to get out without deleting it, and run it next time. [14:38] thats what this function is for, other cards use it too for hackish stuff [14:38] Oh, fine. [14:38] (mainly intel hda) [14:38] and powermac [14:38] so the natty side is ok here [14:38] the maverick one isnt [14:39] and i'm still not happy with the postinst run-once idea [14:39] i wonder if we cant get someone to instead fix the driver [14:39] but the call was just cancelled, so discussion of that has to wait until UDS [14:41] (at which point i wanted to have that completely fixed ... sigh) [14:42] Fixing the driver is *hard*, or we would have dropped all the stuff currently in place a month ago. [14:42] ndec, we need to discuss a lot of stuff next week (i had wished the call wasnt canceled today) [14:42] It's not like the way to solve it changed in that time: it just took that long for anyone to begin to fix the driver enough that we could start using it. [14:42] persia, there was no work since two weeks [14:42] since everyone thinks its fixed [14:43] I know. Still, the solution in place is the one we knew about 6 weeks ago. [14:43] which doesnt help [14:43] its half breeded [14:43] Anyway, point being that fixing it is *hard*. We need to have a better understanding of what is needed. [15:15] persia, hmpf ... another issue ... how would i know which kernel actually runs ? [15:15] uname only gets me everything up to the ABI version [15:15] dpkg-query -W -f='${Version}\n' linux-image-$(uname -r) [15:16] that gets me the installed version but doesnt tell me if it runs [15:17] i dont think there is a way to get the info i actually need === JaMa|W is now known as JaMa|Theater [15:24] ogra, I think you can't. [15:24] You can only tell if a given ABI is running. [15:25] Complain to the kernel team, if you like. [15:25] persia, nah, just found a way [15:25] ogra@panda:~$ cat /proc/version_signature [15:25] Ubuntu 2.6.35-903.15-omap4 2.6.35.3 [15:26] Yet another reason it's good to ask questions of the right folk :) [15:27] heh [18:45] ahoy there [18:45] guys, there's a server session scheduled early monday at UDS-N [18:45] I'd like some linaro people to attend to see where we can help, but it conflicts with our roundtable [18:45] could we move it around? [18:52] kiko, The schedule is still very dynamic. Subscribe your folks as "participation essential" to both sides of the conflict, and it ought mysteriously disappear. [18:52] I don't believe anyone likely to be active in this channel has special scheduling rights. [18:53] persia, well, I know, but in our case we can't easily add essential participants to our roundtable. I'll try though [18:53] Hrm. no idea. [18:54] You might ask in #ubuntu-locoteams : I don't know *why* the summit devs tend to chat about the code there, but it seems to be the place. [18:54] persia, I can move it manually? [18:54] if you say it's okay to have that in the second slot [18:54] If you can move stuff, but don't make other people conflict :) [18:55] done! thanks persia [18:55] * persia has a strong suspicion that humans should avoid trying to find a best-fit simultaneous schedule for ~300 participants, and register preferences instead [19:44] Doing a update from stock 10.10 image for OMAP4 (running on Pandaboard) -- is taking a loooong time.. any known issues? [19:47] Hundreds :) [19:48] :D [19:49] desktop update is smooth.. but on panda.. slow like a tortoise.. [19:49] But the two main factors you are hitting are 1) ports.ubuntu.com is painfully slow, and 2) there's something like 100 updates since release [19:50] Downloadding updates went pretty quick [19:50] (we released 3 weeks early, and it just isn't as polished as we like, but we used to release at the beginning of October, and will be in *much* better shape to ensure the next release isn't broken) [19:50] Installing is the slow part.. I guess it's the MMC card! [19:50] should use USB stick... that should speed things up [19:51] understand [19:51] Oh, if the download is done, yeah, it's the MMC being slow, and probably made slower by the dpkg/fsync thing combined with the FTL eraseblock management. [19:51] I see [19:52] dpkg breaks fairly spectacularly if the state on disk isn't accurate, so it ends up calling fsync all the time because it can't trust the filesystems (no transaction support). [19:53] But that means, essentially, no useful disk cache for dpkg operations, which makes slow storage painful (and moreso for managed flash, because each fsync ends up marking an eraseblock used, which means the FTL has to do all sorts of things) [19:53] I see.. thanks for give the details of what might be happening... [19:53] Just a guess though :) [19:54] Understand [20:35] persia, i got a new stereo BT headset ... [20:36] funnily its not found on the ac100 (while i see lots of phones from 300m distant neighbors) [20:36] persia, any idea what i should look for ? BT seems to be fine, BT audio doesnt [20:37] Heh. [20:37] ogra, Bring it to UDS. I'm not going to dig up a BT headset at 4:30 to test this with you today. [20:37] its a really cool one for music and calls [20:38] bah, slacker !!!! [20:38] ... i'll indeed bring it ;) [20:38] thanks for answering at that time :) [20:38] No, just need to proof-read and publish a bundle of specs and a couple documents before UDS. [20:38] what happened to the schedule ... the other channel reads funny [20:38] * persia isn't especially diurnal or anything :p [20:39] I'm not sure precisely. Everything went wonky, and I started using LP to look at specs. [20:40] well, seems in order again [20:40] my specs are still all there [20:40] and even at more convenient times now [20:41] * ogra_ac reboots to see if BT behaves differently if plugged at boot [20:41] Shouldn't, [20:47] ha [20:47] it helps if the headset isnt paired with my phone while searching for it [20:48] now how do i tell alsa about it ... hmm [20:55] yay, bluetooth music [20:55] So, you figured out you had to tell pulse, rather than ALSA? [20:56] well [20:56] its a bit tricky [20:56] i have to recompile the kernel with a hack to make the tegra card modular [20:56] then pulse doesnt eat 100%CPU [20:57] *then* i can let pulse start with dummy device [20:57] and *then* bt sound works [20:57] as well as my soundblaster USB card btw [20:57] heh. [20:57] intrestingly i have no volume control [20:58] i can control app volume in RB but no master in the panel or pulse [20:58] and mic input doesnt seem to work [20:58] Yes you do, but there's a bug that the default volume control doesn't actually control the volume of the output you are using. [20:58] This is most unexpected when you have a USB headset with HID volume buttons. [20:58] it works with the usb card [20:58] If you go into the detailed volume control and fiddle levels on the individual devices, it ought work. [20:58] more important is though that i get the mic working [20:58] i want to mumble with the headset [20:59] It works on whatever it thinks is default, which is fine for folks that only have one sound output (who are becoming an increasingly small proportion) [20:59] It's probably muted. [20:59] not in the UI [21:00] Try muting and unmuting. Sometimes the uninitialised state is incorrectly displayed. [21:01] hmm, i will try [21:01] * ogra_ac isnt sure if he can swithc from hifi to telephony mode without breaking RB [21:02] I doubt it: they are different BT profiles. Some hardware supports input and output with hifi, some requires a profile switch. [21:03] well, music stops if i switch to the telephony profile [21:03] heh, and RB paused properly [21:04] A profile switch ends up being like a hardware change, from pulse's perspective (as I understand it) [21:04] ah [21:05] hmm, no peaks on the meter [21:05] if i only knew where the mic sits in this gem of industrial design [21:06] its a jabra halo btw [21:06] You might want to chat about BT stuff in some channel baptistemm haunts, as he seems to be our current primary maintainer. [21:07] (although, like most sensible folk in his part of the world, he's probably not in front of his computer now) [21:07] yeah [21:07] its not urgent [21:07] i need the non NEON QT forst anyway [21:07] *first [21:08] else i cant run mumble [21:08] You know, some folk like NEON. [21:08] and that might still be bulding [21:08] You're the one on unsupported hardware. [21:08] good for them [21:10] we guarantee that nothing is built with NOEN in maverick [21:10] *NEON [21:10] a fix is already in proposed [21:12] well [21:12] still building it seems [21:12] https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0-0ubuntu4.1/+build/2012722 [21:12] i wonder if it will make it before i step on the plane [21:19] Who guarantees that? I'm certain it's not true. [21:20] I doubt it. qt4-x11 takes *forever*, and seems to die during build every once in a while (based on whackamole observations) [21:22] yeah [21:22] well, in any case that build is with -no-neon [21:22] if it succeeds i hope it's actually true :) [21:25] I'm surprised rbelem didn't have anything to say: I think he needs NEON to run at a decent speed on his n900 :) [21:26] well [21:26] it breaks all QT apps on dove [21:26] david was pretty upset [21:26] (and indeed on ac100 but thats rather less important) [21:27] Who uses Qt on dove? :) [21:27] no idea [21:27] but we guarantee that it works [21:27] That's what I thought. [21:27] Who? [21:27]