/srv/irclogs.ubuntu.com/2011/02/10/#ubuntu-arm.txt

=== ApOgEE__ is now known as ApOgEE
=== asac_ is now known as asac
rsalvetiworking sgx driver for natty published at https://launchpad.net/~tiomap-dev/+archive/omap-trunk04:15
rsalvetisame version as currently used at maverick, but ported to make it work with natty's xorg04:16
=== pan1nx is now known as info
=== info is now known as pan1nx
=== marvin24_ is now known as marvin24
loolrsalveti: cool09:48
ndecrsalveti: thanks for pushing the DDK update for natty!10:01
janimoogra, in the natty platform seed  I see dove, is that still needed there?10:12
janimoalso what is the difference between platform.natty and ubuntu.natty seeds? I saw no overview of the relationship between various ubuntu.seed branches10:13
ograjanimo, in the seeds we can keep it in case a platform comes back you dont need to redo the whole seeding10:17
ograwe dont build images for such platforms so it shouldnt do any harm apart from a bit bit-rotting10:18
ograjanimo, also forget about seeds10:18
janimoogra, right but I was hoping version control software was a better fit for keeping such legacy bits around10:18
janimoI find almost all the scripts in the area of image building have a lot of unnecessarey baggage10:18
janimomaking them harder to understand10:19
ograjanimo, i had a chat with lool yesterday, they use the same low level seed and have a policy that no bootloader should be installed, we would break it for them10:19
janimoogra, so no bootloaders in the seeds?10:19
janimook, I'll add them in livecd-rootfs then10:19
ograno10:19
ograjust have a line in the upgrade script that apt-get installs them ... we dont need them seeded, you need the latest version from the archive anyway10:20
ograone check of the script should be that -updates is enabled, then get the last versions from there and drop the binaries in place10:21
janimoogra, yes but they will not be upgraded ifg they are not in the image initally10:21
ograthe version we would seed would be the original one installed anyway10:21
janimoogra right, but then updates would be automatic10:21
ograwhy do we need automated updates here ?10:22
janimoogra, if the script needs to bring them the user cannot be notified when an update is there10:22
janimoautomated fetch not install10:22
ograwe dont want to actually encourage users to upgrade their bootloader, we just need a tool for the case where we tell them to upgrade10:23
janimowell suppose we have a bugfix, how to propagete to users so they stop complaining about it? I think it shold be like a regular bugfix via apt10:23
janimoogra, ok10:23
ograi.e. we dont need notification here10:23
janimoogra, in this case apt-get installing it just to put it on the 1st partition is strange.10:24
janimoanyway I'll do wahtever t tajkes to have some script working for omap3/410:24
janimowithout too much fanciness :)10:24
ograwell, if you prefer to pull the deb and extract it, i wouldnt object10:25
ograand if you have a convincing reason to have it on the image in advance, feel free to convince me, i was on that page before my discussion yesterday ;)10:27
ograyay, my new mobile just arrived10:27
janimoogra, well for easy of install and not bothering with extra step, plus to notufy users automatically. And if it can be done from livecd-rootfs withoiut touching the seeds what is the drawback?10:27
loologra: Well, it's not a policy that no bootloader should be installed  :-)10:28
ograah, i thought it was turned into some kind of policy10:28
loolit's just that we decided that the bootloader did not have to be part of the rootfs, even more so if it's not upgraded automatically (which we certainly don't want)10:28
ograjanimo, what i see as a compelling reason to have it installed is that you easily can find out the version10:28
janimolool, we also decided that updates would not be automatic, but up to the user10:29
loolhowever this is not implemented, and I believe that current images still install a bootloader .deb, this is a limitation of our image writing tools which will be fixed once we implement what we call hwpack v210:29
loolhttps://wiki.linaro.org/Platform/Specs/11.05/HardwarePacksV210:29
loolI personally recommend *not* shipping the bootloader with apt/deb if you can avoid it because "updates" of this file wont make any sense (wont actually get the bootloader update, and might result in the rootfs hosting a bootloader which might not work when put to use)10:30
ogralool, yes, but you still get an easy way to check the version, might be helpful for i.e. apport reports of a kernel crash10:32
ograi know its doesnt necessarily show the running version10:33
loolIt doesn't represent the real version10:34
loolit's just a random piece of data10:34
loolBTW the point I was making yesterday was about network-dependency10:35
loolSince you're going to want a fresher version of the bootloader to install because yours is borken, then you necessarily have access to an archive (since you can apt-get update to it), so why not instead apt-get install it when needed, and not install it by default in the first place?10:36
loolI didn't read the spec, so I don't understand how you'd actually boot your board which has a broken bootloader to upgrade it though10:36
janimolool, no provision for fixing that. So even if update is made easy, one still needs some technical skill to restore10:37
loolPerhaps one way this would work is from your x86 laptop, putting your rootfs SD card into it and updating the bootloader; if you really need to run ARM code, you could use qemu-arm-static, but I think you could avoid it10:39
ograthats a different scenario10:39
loolThis would also allow the "download image from ubuntu.com, write to SD, update bootloader on SD, boot on recent hardware" use case10:39
ograthe point is to be able to apply fixes, not tro make unbootable systems boot10:40
loolWhat kind of fix?10:40
ograinitialization errors of single bits of the hw that the bootloader has by release time for example10:40
loolWhy can't this be done in linux?10:41
ograbecause it might be a more ugly patch or it might not be possible to do it after boot10:41
ograthe omap4 display issue we had would not have been solvable in the kernel for example10:41
loolSo how would you do it with another bootloader?10:42
loole.g. in production, with a lightweight bootloader10:42
ograit was an x-loader fix that initialized the HW10:42
loolI might not know the specific of this bug, it just seems odd that hardware state would belong into u-boot10:42
ograit wasnt u-boot but x-loader10:43
loolIf x-loader/u-boot work enough to start a kernel, then it seems to be the kernel could fixup stuff10:43
ograif you set a voltage wrong and the kernel cant adjust it, you cant fix it differently10:43
loolWhy wouldn't the kernel be able to adjust?10:43
lool(I am really ignorant here)10:43
ograbecause there is no interface to do so10:43
* ogra needs to vanish for a moment10:44
=== XorA|gone is now known as XorA
rsalvetimorning12:01
rsalvetilool: ideally the kernel should handle everything, and the x-loader/u-boot would just bring up the board12:06
rsalvetibut is not the case atm12:06
rsalvetix-loader is still important, and still setting things that the kernel expects to be ready once it boots12:07
rsalvetithat's why in the last cycle we needed a x-loader update to have a feature working fine12:07
loolYup12:07
rsalvetiso the system is working, is booting12:07
rsalvetibut not properly working regarding some feature12:08
rsalvetithat x-loader, for example, initialize, then we need a way to update it12:08
rsalvetias we can easily brick the board with automatic updates, we decided to provide a tool for the user12:08
rsalvetiand notify him once we have new updates12:08
rsalvetiso he can run this tool, and update the core boot files12:08
rsalvetihaving both installed at the images can make the work a lot easier12:09
loolHmm the notification part is harder12:09
rsalvetiat least to identify the version, and also to notify the user12:09
loolDo we expect this to happen frequently?  It would make sense to invest in having the init done by linux instead of x-loader12:09
rsalvetiwell, it happened frequently with maverick12:09
loolIt sounds a bit like a BIOS update, but you can't even check which version of the BIOS you're using!12:10
rsalvetiand because of the short time frame to have a working 2.6.38, I'd not expect to have the kernel properly setting up everything12:10
rsalvetiyou can only check by the binaries, or by the package metadata, if it's installed at the system12:11
loolThis is very indirect12:11
rsalvetitrue12:12
loolbinaries > if you mean the ones on the boot partition, that's ok, but the one in the rootfs that would sound bad12:12
rsalvetithe ones at the boot partition12:12
loolI'm not up-to-date on flash-kernel stuff ATM; is the boot partition always mounted, or mounted when needed?12:12
rsalvetimounted when needed12:12
loolYou're going to want some kind of permanently installed package to raise the notification; perhaps a sensible one would be jockey12:13
looljockey could mount this partition ro when starting (ouch, but eh) and check MLO for a specific version12:13
loolthen <insert here some magic> you decide that an update is needed; jockey does the x-loader package download if needed and run a x-loader flashing wrapper; question is whether x-loader package stays installed o rnot12:14
lool*or not12:14
rsalvetiwe don't want to run the update automatically12:15
loolJockey prompts you12:15
rsalvetiwe want the user to run the flashing tool12:16
rsalvetithat can work12:16
loolit probably needs some adaptations to deal with this, but that would seem to give a good starting platform; maybe pitti would have more comments there12:16
rsalvetijanimo: ^12:16
loolWe might not have a text UI for jockey12:17
loolonly Gtk+ and Qt based ones12:17
rsalvetihm, we would need to run this procedure in text mode too12:18
rsalvetias we'll have the minimal image12:18
loolthe actual flashing script should probably be implemented in flash-kernel, but with special care to advertize this as extremely dangerous brick-your-device feature12:18
loolYou could have documentation for text mode12:18
loolrun flash-kernel --flash-bootloader12:18
rsalvetiguess that's ok12:19
loolTechnically, you could use package upgrades to trigger flashing, but it's not really a direction that seems reasonnable  :-.12:19
lool:-/12:19
janimolool, I was also thinking of adding it to flash-kernle as it makes packagihng and coding easier. I am not sure if this does not take it further away from debian and the original intention of the package12:19
janimobut, yes I would rather have it in flash-kernel that a separate source package for one script12:20
looljanimo: Currently flash-kernel has knowledge of where your bootloader lives (SD vs flash); that's the only non-installer place which has this, so it seems sensible12:20
janimolool, actually for OMAP flash-kernel needs to be told the partition in a config file ia UBOOT_PART12:20
loolIn general, I think flash-kernel needs to be modernized substantially, but it's a lot of work12:20
janimoso it's not like it autotdetecta anything12:20
janimolool, otherwise it assumes NAND12:21
looljanimo: I know, but it has code to parse flash-kernel.conf and stuff, doesn't it?12:21
rsalvetibut the conf is there by default already12:21
rsalvetiif the user installed by using our image12:21
rsalvetinot completely safe, but ok12:21
loolYou wouldn't want to have another tool reading this kind of data; it's very Ubuntu specific and I'd like to keep it flash-kernel-specific; if it spreads to other packages we're bound to lots of pain12:21
janimolool, sure, I am for using flash-kernel, just pointing out that the code in case was not some complex piece12:21
janimolool, true12:22
loolIt's really not about complexity, it's rather that I find this dirty enough  :-)12:22
loolthis whole flash-kernel.conf was quickly thrown together some years ago, and never architectured, sent to Debian or anything12:22
loolI could easily take the blame for this though12:23
janimolool, actually flash-bootloader may not be enough. I think we;d want to update xloader and uboot independently.12:23
janimoso maybe have flash-bootfile  /path/to/opaquefile12:23
janimoor flash-uboot, flash-xloader options12:23
rsalvetiflash-bootloader should be fine12:23
janimohowever this make it very omap specific12:23
rsalvetiyou can check both before updating12:23
rsalvetiand updating what needs to be updated12:23
rsalvetix-loader is omap specific12:23
janimorsalveti, makes sense, but maybe the user would only want to update one12:23
rsalvetiand also part of the booting procedure12:24
rsalvetithe normal user would not update it independently12:24
janimoso no GUI, agreed?12:24
loolI think it's best if you know what you're doing; flash-kernel --install-to-boot /usr/lib/x-loader:MLO && flash-kernel --install-to-boot /usr/lib/u-boot:u-boot.bin sounds much uglier than flash-kernel --spl --tpl or flash-kernel --bootloaders=spl,u-boot12:24
rsalvetiprobably doesn't not even know about x-loader/u-boot12:24
loolYou basically don't want to leave any room for hacks or abuses with this kind of stuff12:25
rsalvetiyup12:25
loolotherwise someone is going to suggest flash-kernel --install-to-boot boot.scr in some documentation12:25
janimoboth of these contradicotry approaches make sense12:25
janimodepends who are we targeting and which is more useful in general12:25
rsalvetijanimo: gui just to warn the user12:25
rsalvetiaobut the update12:25
looland then the seas will rise, cities will collapse, mountains will fall12:26
janimorsalveti, I think we still need to decide whether these belong to the preinstalled image or not, at least ogra seems to have doubts about the latter12:26
looljanimo: Why no GUI?  :-)12:26
rsalveti:-)12:26
loolI mean, perhaps I'm thinking it wrong, but to me you're trying to distribute an user-friendly Ubuntu for OMAP4 which does the right thing12:26
janimolool, no extra GUI I mean. If it cannot be part of update-manager or some other apt-related I'd rather us not have a special gui for this12:26
looljanimo: why not part of jockey?12:27
looljockey will popup and tell you that you bought a proprietary graphics card and that you can't get any boingboing effects without clicking "Install these binary stuff"12:27
janimolool, no experience with jockey, but party because I;d like to first figure out somethig that works and then see if it can be imporved, before touching too many different packages initially12:27
loolgnome-power-manager will tell you "This battery has been recalled, contact your manufacturer"12:28
janimolool, yes but that is already running and does this as an extra. We'd not run a dameon specifically to watch for updates12:28
janimothat's wha update-manager does12:28
looljanimo: Sure; these are kind of orthogonal, but in general user experience is better designed top-down (apple) than bottom-up (linux :-)12:28
janimolool, true as well, but we are talking about a rpocedure which requires running a cmdline app12:29
loolYou can implement the flash-kernel plumbing first obviously12:29
janimowhich if goes wrong needs expert intervention anyway -VFAT formatting, copying of blobs etc12:29
janimolool, right, the core operation first and see how it can be improved12:29
loolupdate-manager delivers package updates, or recommends dist upgrades; don't think it deals with special general-purpose hooks like jockey kind of does; I don't know where you'd put the data12:29
* lool thinks jockey could also be used to install the powervr stuff12:30
janimolool, that is why the solution (until yesterday that is) involved having the packages installed so dpkg post install hooks can be used for this purpose12:30
* janimo does not know about the powervr use case12:30
loolit's technically feasible to decide to do upgrades from package hooks, but I would find that disturbing and risky12:31
rsalvetilool: jockey could work fine with pvr, I believe12:31
rsalvetiat least would make sense12:31
lool(because you'd have to protect the action by some debconf prompt which are considered evil and would have to fail by default, and because it would create a perception that you have x-loader 1.2.4 when in fact you have some random other version and it doesn't necessarily get installed)12:32
loolthe jockey case also makes it more obviously optin than upgrade your system and it might not boot12:32
janimolool, well technically it is just as risky as upgrading kernel/initrd no? If update gets broken it does not boot. And we would not push broken boot loaders to the archive12:33
rsalvetijanimo: well, kind of12:34
janimosure if jockey is better suited for this it can be used, I just have no experience with it12:34
rsalvetithe user can still try something at the u-boot prompt12:34
rsalvetiif we break x-loader, nothing will show at the uard12:34
rsalveti*uart12:34
rsalvetiand the user will cry and screen12:34
janimorsalveti, but if a user can work with uboot prompt via serial he can surely copy two files on the MMC VFAT partition?12:36
rsalvetijanimo: probably not12:36
rsalvetiwe have cases that the user only uses uart to see what's happening12:36
rsalvetiand log-in into the system12:37
janimoI see this spec as a convenience use-case not one that makes regular users do expert things because of a wrapper12:37
rsalvetibut don't have proper technical background for other stuff12:37
rsalvetiyup, we should focus on the simple user, that just want his system to be fixed12:38
looljanimo: I tend to agree that it would be best if we had a way to offer booting older kernel / initrd, or passing cmdline options; not visible by default, but to be able to maintain multiple kernels on a system12:38
loolbut the difference is that we know the kernel is going to see some security updates, while the bootloader shouldn't ever need an upgrade if we don't really need it12:39
loolit should basically get out of the way; think of it as firmware12:39
loolI have devices where in theory I have source of the bootloader, but I didn't build it myself and I doubt I'd be able to replace a broken bootloader; in fact, if I flash a broken bootloader there is zero way to recover12:39
loolit might not be true on SD, but because the solution will involve flash-kernel etc. it would be best to have safety nets in place and not do it unless really needed12:40
loolFor instance, you might want to decide to only upgrade the bootloader if people are running a specific board12:40
janimolool, you mean variants of beagle or rather beagle vs panda?12:41
loolboth12:42
janimoright now I guess all variant will get a new package being in the same source package even if only one gets a fix12:42
loolso you're upgrading the bootloader even when not strictly needed?  sounds bad12:42
janimolool, no, the opposite, was just needing calrification12:43
lilstevielool: not even jtag13:01
apwogra, yo ... seems that the linaro qemu images have hit the archive.  this ought to mean we can emulate omap3 correctly now, which might mean that versatile kernels are no longer needed for arm as they are used for qemu only ... what are your thoughts?15:34
apwogra, i am a little concerned about the interaction between a lucid host and this though15:34
rsalvetiapw: well, at least with rootstock (that uses versatile) I'll test with omap 3 and see how it goes15:35
rsalvetibut it should work fine, as linaro is already using qemu with the omap 3 kernel15:35
apwrsalveti, that sounds good ...15:35
rsalvetidon't know if we have any other use for versatile15:36
rsalvetimaybe ogra knows15:36
apwrsalveti, there is a bug open which might make sense to report the outcome of any testing15:36
apwbug #71511315:36
ubot2Launchpad bug 715113 in linux "Drop versatile support" [Undecided,New] https://launchpad.net/bugs/71511315:36
rsalvetiapw: sure, will do15:36
ograapw, we were just discussing it in the meeting :)15:36
persiaAnd in -kernel15:37
apwheh and here, and ... yeah i am suggesting the bug for any position statements or testing :)15:38
janimoapw, the bug I filed is part of a spec of the arm team, so they are at least partly aware of the situation :)15:40
janimoapw, there are some bugs still with various corner cases but the linaro devs are on them and fix qemu relatively fast15:41
rsalvetiyup15:43
rsalvetiso we should be safe with the qemu-linaro and omap 315:43
persiaConcern is for folks running a complex environment: for example lucid amd64 hosts running natty/arm buildds under qemu15:44
rsalvetippa should be enough for that15:45
persiaI'd prefer a proper backport to a PPA: I know lots of folks who don't trust PPAs, for a number of fairly well-argued reasons.15:47
janimopersia, sure but those special cases should not block removing versatile from natty right15:49
janimo?15:49
persiaI don't see any special reason to block the removal.15:50
persiaThat said, it's probably worth filing a backports bug for qemu-linaro once it's known good.15:51
ograNCommander, bug 708661 and bug 70865916:00
ubot2Launchpad bug 708661 in libqtgconf "[MIR] please include libqtgconf in natty main" [High,Incomplete] https://launchpad.net/bugs/70866116:00
ubot2Launchpad bug 708659 in libqtbamf "[MIR] please include libqtbamf in natty main" [High,Incomplete] https://launchpad.net/bugs/70865916:00
ograsee the last comments16:00
=== davidm_ is now known as Guest87808
=== Amaranth_ is now known as Amaranth
robclarkbtw, anyone aware of ppa w/ firefox-4.0 for arm?21:09
robclarkppa:ubuntu-mozilla-daily/ppa doesn't seem to build for arm..21:09
persiamicahg, Hey.  firefox-4.0 in the mozillateam PPA doesn't build for ARM.  Are there any backports available, or other ways to get it for maverick?22:28
micahgpersia: we might be able to throw it in maverick-backports22:29
persiaIs there a good version suitable for -backports?22:29
persianatty looks like beta1122:29
persiarobclark, Was there a specific version you wanted/needed?22:29
micahgwell, actually, the problem with throwing it in -backports is I don't want to replace the current version in Maverick yet22:31
micahgI'll have to see, maybe I can get a native PPA for firefox22:32
micahgor maybe an ARM enabled PPA22:33
micahgalso, is there a specific timeframe (i.e. you need a version now, or just want Firefox 4 on maverick at some point)22:34
persiaWithout the completion of https://launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster ARM PPAs are tricky :(22:34
persiaI'm just asking you as the most knowledgeable person I know because robclark asked earlier.22:34
persiaI don't know the detailed requirements.22:34
micahgok, it would be nice to know what the use case is, that might help how it's implemented22:35
robclarkpersia, just something recent 4.0 beta22:39
persiamicahg, ^^22:39
robclarksupposedly there should be some performance improvements..22:39
micahgrobclark: can I ask what the use case is?22:39
robclarkwe just want to do some benchmarking w/ our xorg driver22:39
robclarkbrowsing the web ;-)22:39
robclarkscrolling performance and stuff like that22:40
micahgrobclark: I'm wondering maverick vs natty22:40
robclarkahh, maverick preferrably..22:40
robclarkI'm running mostly maverick right now22:40
micahgrobclark: do you specifically need a PPA, or is this just for you?  I could build debs for you on ARM22:41
micahgrobclark: chrisccoulson suggested just grabbing the natty debs22:46
persiaDo they install cleanly on maverick?  I thought there've been a few ABI transitions.22:47
chrisccoulsoni can't think of any reason it wouldn't work22:47
micahgpersia: we use mostly internal libs for Firefox, so there shouldn't be an issue22:48
chrisccoulsonremember, firefox uses bundled copies of pretty much everything except gtk and libc22:48
chrisccoulsonand those don't break ;)22:48
chrisccoulsoni might be wrong, but it *should* work on maverick22:48
robclarkmicahg, doesn't need to be a PPA..22:48
robclarkoh, are there natty debs22:49
* persia grumbles about internal libraries, grumbles more about firefox security, and finds a hole in the sand in which to insert head.22:49
chrisccoulsonpersia - it's not really a problem for firefox, it gets frequent security updates anyway (more frequently than any of our system libraries)22:50
persiaNo moving the sand away from my eyes: I don't want to know :)22:51
chrisccoulsonheh22:51
chrisccoulsonin addition to that, there are other benefits to using bundled libraries22:51
ograout of shampoo ?22:51
chrisccoulsonone of them being that we can submit crash reports directly to mozilla22:51
chrisccoulsonso they have visibility of linux crashes, which is a very important part of their QA22:52
* ogra heard of birds that prefer sand, i didnt know it was polular in japan22:52
* persia is emulating an ostrich22:54
ograjapanese ostrich ?22:54
persiaSure.  Any ostrich.  If I can't see the problem, it doesn't exist, and won't eat me.22:56
robclarkhmm, wget + dpkg -i http://launchpadlibrarian.net/62913574/firefox_4.0~b10%2Bbuild1%2Bnobinonly-0ubuntu2_armel.deb didn't seem to result in anything workable..22:58
robclarkalthough I guess there are probably some other deb's I need to install?22:58
robclarkone 10mb .deb file seems a bit small for firefox22:58
GrueMasterrsalveti: After resolving a few local issues, I finally got around to getting the latest beaglexm image up.  Seeing a kernel oops on kswapd.  System runs, but this is not a good thing to have.  Filing a bug now.23:03
rsalvetiGrueMaster: ok23:03
persiarobclark, What sort of error did you get trying to install?23:06
robclarkpersia, it installed fine.. but just crashes on startup..23:06
persiaheh.23:07
robclarkbut I guess there are probably other deb's I need to install, so maybe I ended up with some 3.6/4.0 hybrid..23:07
persiaThe dependencies should have prevented that.23:07
persiachrisccoulson, micahg: maybe you could fix the dependencies, or build a maverick backport?23:07
chrisccoulsoni really need arm hardware to test this stuff on ;)23:09
micahgyeah, it's going to need a backport as the depends are versioned based on natty23:09
chrisccoulsoni've been debugging an arm build failure with upstream today, but i've got absolutely no way of testing this23:09
robclarkahh23:09
robclarkwell, I have the setup to test deb's on maverick if that helps at all ;-)23:09
chrisccoulsoni just press the button and hope people say if it doesn't work ;)23:09
chrisccoulsoni can test builds ok on the porter boxes, but they don't have an X display ;)23:10
persiachrisccoulson, You might ask if anyone else in mozillateam has ARM hardware :)23:10
micahgchrisccoulson: I can test stuff on ARM23:11
chrisccoulsonthat doesn't really solve my problem though (having no way of testing it myself) ;)23:11
micahgchrisccoulson: I might be able to set up the machine so you can test23:11
* persia imagines a video camera and robotic key-presser.23:12
* micahg is thinking more along the lines of VNC ;)23:13
chrisccoulsonheh :)23:13
loolpersia: Hey there; did you build an efikamx .deb as of late?23:14
loolpersia: I checked the linaro-mx51 one, and it has efikamx enabled in the config, but I bet it misses tons of patches23:14
persialool, I'm working on one.  I have a current tree, but kernel packaging is *hard*23:16
persia(it's sascha + rtp + ubuntu sauce)23:16
loolpersia: Ok; jcrigby has a script to generate linaro-foo sources from a common git tree, not sure if that helps23:17
persiaI've looked at that, and it doesn't quite do what I want.  I care about d-i integration, etc.23:17
looldebian.linaro/scripts/mkflavourbranches in git.l.o:ubuntu/linux-linaro-natty.git23:17
loolpersia: Ok; what do you do instead?23:18
persiaI've been working off the variations abogani used for the -lowlatency kernel to get an idea how to package it.23:19
loolOk23:19
persiaBasically, creating debian.foo and fiddling the scripts to pull the right bits together.23:19
looludebs should in theory be possible with linaro kernels, but I'd expect them to be disabled by default23:19
persiaThat said, I'd much prefer to use a linaro-imx51 kernel, if you guys are happy to produce one with all the d-i bits and Ubuntu sauce.23:20
persiaLast time I looked at the Linaro kernel packages, they were disabled by default: looked mostly like replacement kernels to test stuff, targeting folk who were capable of initialising their own bootloader, rather than the "Insert card, hold key, reboot" crowd.23:21
loolpersia: apparently our mx51 kernel spits udebs out23:21
loolhttps://launchpad.net/ubuntu/+source/linux-linaro-mx51/2.6.37-1002.5/+buildjob/218358823:21
loolpersia: efikamx is definitely enabled in the config I'm looking at23:21
persiaOh, heh.  I was looking at the linaro wiki, and I should have looked at LP :)23:21
loolCONFIG_MACH_MX51_EFIKAMX=y23:21
loolbut not sb, not in upstream yet23:21
persiaHas anyone tested it?23:21
loolNo; I have that in mind since beginning of this week23:22
loolpersia: u-boot-linaro just gained efikamx as well23:22
persiaI have patches for SB, but I'm honestly much more interested in MX.23:22
loolfrom upstream23:22
persiaOh, excellent.  Then I'll stop fiddling with a kernel: no point :)23:22
GrueMasterrsalveti: Bug 71676123:22
loolstill in NEW though23:22
ubot2Launchpad bug 716761 in linux-meta "Page allocation failures during system boot on beagleXM" [Undecided,New] https://launchpad.net/bugs/71676123:22
loolpersia: Well, I don't have it yet  :-)23:22
persiaAre you moving to 2.6.38 soon?23:22
loolpersia: did you care about efikamx or sb?23:22
loolpersia: dunno23:22
persiaI mostly care about MX.  SB would be nice, but most of the folk I know have MX rather than SB.23:23
loolpersia: patches > basically our gatekeeper is npitre and I guess he will take stuff which is going upstream23:23
loolI'm a bit lazily waiting for u-boot-linaro-efikamx to be published to propose a hwpack23:23
persialool, By "going upstream" do you mean for-linus, for-rmk, or for-sascha?23:24
looleventually going upstream  :-)23:24
persiaAh, so for-sascha patches are acceptable?  That's not so bad then.23:24
loolI don't think there's a set limit; it's basically good enough quality and eventually ending in mainline via variou trees23:24
persiaWhat timezone is npitre?23:24
loolI would think patches from Sacha's tree would be acceptable, and hope that for-sascha patches stand a chance  :-)23:25
loolEastern Canada IIRC23:25
loolpersia: best is email rather than IRC23:25
persiaAh.  That makes it tricky :)23:25
loolpull request is ideal, preferably based of a linux tree23:25
loolwell it's his EOD now, he might be around still23:26
persiaI'd need to find somewhere to put a git tree :)  Most of the interesting stuff I have is quilt.23:26
persiaBut I'll try to merge the quilt stuff against linaro-imx51, and make either a tree or a sequence of mail-formatted patches available, and send to npitre.23:26
persiaThat'll be *heaps* easier than me pretending to be a kernel developer.23:27
loolpersia: You can send him a patch series or you can host the patches as regular files23:43
loolpersia: he has access to canonical hosts too23:43
persiaThe hard part is trying to sort which patches are interesting, really.23:46
loolyeah23:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!