| rsalveti | persia: mahmoh: http://paste.ubuntu.com/642981/ | 00:00 |
|---|---|---|
| rsalveti | using a usb-sata disk with a powered usb hub | 00:00 |
| mahmoh | persia: I know, I'm not scared, just don't want to get distracted | 00:01 |
| mahmoh | ah, 'cause hubs are supported! that's cheating | 00:01 |
| GrueMaster | Ok, I just got to a point where I could reboot with usb-sata attached, and u-boot detects it. | 00:02 |
| persia | u-boot can't tell if the hubs are in the SoC, on the board, or external. | 00:02 |
| rsalveti | you shouldn't connect a usb-sata disk directly, board doesn't have all the power to power it | 00:02 |
| mahmoh | GrueMaster: you're using a hub? | 00:02 |
| persia | GrueMaster, Excellent. thanks for confirming this is a problem with mahmoh's device. | 00:02 |
| GrueMaster | no | 00:02 |
| mahmoh | it's working on my board | 00:02 |
| mahmoh | GrueMaster: what's the model/make? | 00:03 |
| rsalveti | but don't know if u-boot is have the support to give more power to the device | 00:03 |
| rsalveti | - Interfaces: 1 Self Powered 100mA | 00:03 |
| mahmoh | ouch | 00:03 |
| rsalveti | directly it'd consume 500mA | 00:03 |
| rsalveti | let me try without a hub | 00:03 |
| mahmoh | ok, powered hub it is | 00:03 |
| GrueMaster | Hornettek Rhino. | 00:03 |
| GrueMaster | Using external power supply (panda doesn't have enough power to support otherwise). | 00:04 |
| mahmoh | gazoontite | 00:04 |
| rsalveti | mahmoh: yeah, that's the problem | 00:04 |
| mahmoh | ok | 00:04 |
| GrueMaster | http://www.hornettek.com/pcaccessory/index.php/25q-hdd-enclosure/usb-20/rhino | 00:05 |
| persia | I don't see anything in the u-boot USB code that would indicate it does power level negotiation, but I'm not that familiar with the codebase. | 00:05 |
| mahmoh | rsalveti: but wait, it works under linux though? | 00:05 |
| rsalveti | probably need to improve the usb protocol to do allow devices to request more power than the usual | 00:05 |
| GrueMaster | I bought 4 at Fry's. | 00:05 |
| rsalveti | mahmoh: yeah, but because on linux the kernel allows it to take 500mA | 00:05 |
| mahmoh | ok | 00:05 |
| mahmoh | looks bulletproof | 00:05 |
| rsalveti | so, it works, but you need to power it with a powered usb | 00:07 |
| GrueMaster | That would be the Defender model. http://www.youtube.com/watch?v=uOCVEVNU-PA | 00:07 |
| GrueMaster | It has a 5vdc plug. | 00:08 |
| rsalveti | persia: I don't think it does | 00:08 |
| persia | rsalveti, http://www.usb.org/developers/devclass_docs/batt_charging_1_1.zip has the info on the new shiny for granting up to 1.8A | 00:08 |
| GrueMaster | persia: USB2.0 or 3.0? Makes a difference. | 00:09 |
| persia | GrueMaster, Battery Charging was introduced as part of 2.0, and I believe it was grandfathered into 3.0, although I'll admit that I haven't been paying as much attention to USB as I did 5 years ago. | 00:10 |
| GrueMaster | Reason I say that is that the 2.0 plug can only handle x amps electrically, and that may be pushing the envelope. | 00:11 |
| persia | There's been something like 5 revisions of the plugs. | 00:11 |
| persia | But if the host isn't implemented with a plug that can handle that amperage, it isn't likely to be able to negotiate the higher amperage. | 00:12 |
| persia | Mind you, some idiot might have wired up a port to appear to handle charging without sufficient support, but the legion of iPod owners complaining about burned devices would likely be a sufficient source of complaint that we oughtn't care. | 00:14 |
| GrueMaster | Section 3.5 says the standard A connector is capable of 1500mA. | 00:15 |
| persia | (not to pick on the iPod specifically, but most of the USB power hardware I see in shops that supports higher amperages is labeled "supports iPod", rather than "supports Battery Charging Detection") | 00:15 |
| GrueMaster | A charger can push more if it has a port that can handle the load. | 00:15 |
| persia | Right. | 00:16 |
| persia | But that ought be limited at a level u-boot can't fiddle. | 00:16 |
| GrueMaster | My nook color pulls 1500 if it has the custom microusb cable. | 00:16 |
| persia | u-boot would fiddle the device registers to increase the level, but isn't likely to be able to reach higher than the device supports. | 00:16 |
| GrueMaster | At any rate, I don't know what current the panda can push out the usb ports. | 00:17 |
| persia | Supposedly 2A of the input power is expected to be used by the USB ports. Mind you, that's hearsay: I've seen no documentation about this. | 00:17 |
| GrueMaster | But it doesn't appear to be enough to handle these drives even with a USB Y cable. The drives are 160GB rated at 0.56A | 00:17 |
| persia | I suspect that the ports are likely rated at 1.5A each. | 00:17 |
| persia | Remember, if the negotiation doesn't happen properly, even a Y cable will only provide 200mA | 00:18 |
| GrueMaster | Ah. So definitely a u-boot issue. | 00:19 |
| GrueMaster | (kernel as well). | 00:19 |
| persia | Looks that way. Looks like u-boot doesn't support current negotiation, so if the device needs more than 100mA, then it just won't work. | 00:19 |
| GrueMaster | Explains my earlier headache. | 00:20 |
| persia | linux does have some current negotiation, at least up to the 500mA level. That said, it may be that the specific USB driver used here isn't implementing it correctly, or something. | 00:20 |
| NekoXP | check what is behind the ports | 00:20 |
| persia | I have no idea if linux can support battery charging: anecdotally folks don't seem to get fast-charge of their media players / phones / etc. from plugging them into Ubuntu, so I suspect it doesn't. | 00:20 |
| NekoXP | usually you have something like an ISL6185XXC there which will be rated for a particular current and for a particular overcurrent protection | 00:21 |
| persia | NekoXP, Is that something software detectable? | 00:21 |
| NekoXP | absolutely not | 00:21 |
| NekoXP | but the pandaboard schematics are available right? | 00:21 |
| persia | That's what I thought. | 00:21 |
| GrueMaster | persia: I have not seen an issue charging my cell from my desktop, so I think the kernel has *some* logic in it. | 00:21 |
| persia | GrueMaster, Does it charge as fast as if you attach it to a 1.5A 5V supply? | 00:22 |
| GrueMaster | Not sure. never really measured it, but it appears to be fairly decent. And I don't think my phone can pull that much. Need to look at the spec on micro usb. | 00:23 |
| persia | NekoXP, So, while board designers might do all sorts of things, do you think there's any risk in attempting to comply with the current negotiation specs all the way up to 1.8A in u-boot/linux? Would it be safe to rely on the hardware to simply not do what was asked if it hit it's limites? | 00:23 |
| GrueMaster | Something to test with my nook though. | 00:23 |
| persia | I've pushed 2.0A over microUSB, but that required special HW on both ends. | 00:24 |
| NekoXP | absolutely do not :D | 00:24 |
| NekoXP | 1.8A is way, way over the spec | 00:25 |
| persia | Which spec? | 00:25 |
| persia | According to Battery Charging Specification, it looks like a device can expect 5.25V at 1.8A assuming all negotiation is successful. | 00:26 |
| NekoXP | ONLY if the USB controller and the stuff behind it complies with the battery charging specification | 00:26 |
| NekoXP | which is a very complicated and kinda ass backwards spec | 00:26 |
| persia | Wouldn't a non-compliant implementation not respond to bit-banging to tell it to provide more than 1.5A (or, in practice, really 500mA)? | 00:27 |
| persia | (and yes, the spec is incredibly complicated) | 00:27 |
| NekoXP | I would assume that the panda pmic is supplying port power | 00:27 |
| NekoXP | so check if the pmic supports the BCS | 00:27 |
| NekoXP | and check that it supports it from a *we are the host* POV, instead of the "we are the device and you are charging your pandaboard's battery via the OTG port" which I am absolutely sure it would support | 00:28 |
| persia | Oh, panda almost certainly doesn't support BCS. | 00:28 |
| persia | But in terms of adding support for current negotiation to upstream u-boot, I'm unsure how much we care about a specific implementation. | 00:29 |
| NekoXP | it is entirely device specific | 00:32 |
| NekoXP | but consider this | 00:32 |
| NekoXP | if your system loaded and did not get past bootloader, why would you be plugging your iPhone into it | 00:33 |
| persia | Sure, but if the system loaded, and started the bootloader, I might want to load my OS off my USB optical drive.. Those usually require ~700mA to spin up. | 00:33 |
| NekoXP | but the maximum in the USB spec is 500mA | 00:34 |
| persia | Unless one implements BCS. | 00:34 |
| NekoXP | your CDROM drive will not comply with the BCS | 00:34 |
| GrueMaster | It will with a usb Y cable. | 00:34 |
| GrueMaster | 500ma per port. | 00:35 |
| persia | Hrm. I've seen a number of one-plug optical drives floating around, which only work when attached to newer platforms. I had presumed they were doing something like that. | 00:35 |
| persia | GrueMaster, But that doesn't require BCS compliance: just regular current negotiation (which u-boot also doesn't have) | 00:35 |
| NekoXP | a USB Y cable is not the battery charging specification | 00:35 |
| GrueMaster | Charging spec or not, the question remains of why I can't power a usb-sata drive with a usb Y cable. Charging my cell is very low on the list, but having working usb-sata is very high. | 00:38 |
| GrueMaster | (and I lost track of this thread when it diverged from that). | 00:38 |
| NekoXP | GrueMaster, quite possibly because at the end of the day the port power provided will never reach the levels you want | 00:38 |
| persia | GrueMaster, There's a bug in u-boot. It doesn't do *any* current negotiation. As a result, your Y-cable is only providing 200mA to your HD. | 00:39 |
| GrueMaster | 506mA? | 00:39 |
| persia | I'm curious if we want to implement BCS in u-boot. | 00:39 |
| NekoXP | for instance if you're using Freescale's MC13892 PMIC on a device, using ther VUSB regulator to provide port power, it will supply 100mA and that's it | 00:39 |
| persia | I think NekoXP is suggesting that this probably isn't a good idea. | 00:39 |
| GrueMaster | Is it a u-boot or platform issue? If u-boot, it is fixable. If the platform can't handle the load due to design, that's a different issue. | 00:40 |
| persia | NekoXP, Even if the software supports current negotiation? The port can never do 500mA? | 00:40 |
| GrueMaster | So, simple answer - hardware limitation. | 00:40 |
| persia | GrueMaster, Both, but in the specific instance of the panda, there is support for 500mA. | 00:40 |
| NekoXP | in the specific case of the board you're trying to make it work on you shouldn't need to NEGOTIATE for current | 00:41 |
| GrueMaster | persia: if the hw will support 500ma but u-boot doesn't support autoneg, that's a software issue. If the panda power regulator can't handle it, then it is hardware. | 00:41 |
| persia | What? | 00:41 |
| NekoXP | you simply have to configure the host controller, configure the port, turn VBUS on and initialize the device | 00:41 |
| persia | NekoXP, But USB 2.0 specifies that the device is supposed to *ASK* if it wants more than 100mA. | 00:42 |
| NekoXP | before you actually kick the device it cannot draw more than 100mA per spec anyway | 00:42 |
| persia | GrueMaster, For those definitions of "software" and "hardware", it's a software problem. | 00:42 |
| NekoXP | the descriptors will say whether it wants more | 00:42 |
| * GrueMaster will check back for an answer later. | 00:42 | |
| NekoXP | and if so the host can grant that by turning on the regulator | 00:42 |
| NekoXP | there's not really any protocol for it | 00:42 |
| persia | NekoXP, Right, but what we've discovered is that u-boot isn't lifting the power even when the descriptors request more. | 00:43 |
| GrueMaster | On a more immediate note, I just discovered panda (u-boot, kernel, whatever) doesn't like the SD to be removed, even when rootfs is on usb. | 00:44 |
| GrueMaster | Very odd. | 00:44 |
| NekoXP | GrueMaster, probably kernel | 00:45 |
| persia | GrueMaster, Did you boot kernel from SD, or from somewhere else? | 00:45 |
| NekoXP | there is an option to make the device a little persistent | 00:45 |
| NekoXP | i.e. assume it's there and if not, puke | 00:45 |
| GrueMaster | persia: Should be irrelevant as it isn't a mounted filesystem. | 00:45 |
| NekoXP | persia, USB "current negotiation" is down to physics, mostly | 00:46 |
| persia | GrueMaster, I think linux still uses the boot source as a backing store, if it can. I might be mistaken. | 00:46 |
| GrueMaster | Works fine on babbage3. | 00:46 |
| persia | NekoXP, Except the bit where the OS reads the descriptors and tweaks the regulator to push to 500mA, unless I misunderstood something (in which case, please tell me what I should have read) | 00:46 |
| persia | GrueMaster, Very odd. | 00:46 |
| NekoXP | a device will not draw more current than you can provide it, and it will not draw current unless you turn it on.. you plug in a USB stick, the USB host controller is providing capability of 500mA (or whatever) to the device 99.9% of the time. if this is controlled by some kind of regulator this voltage can be changed based on power management policy. The USB spec states that an unconfigured device may only draw 20mA suspended (which goes away the moment you | 00:48 |
| NekoXP | talk to it) 100mA otherwise. If you read a descriptor that says 500mA then you may turn your regulator up to 500mA, but in actual fact, most systems just leave it at 500mA and you have no choice really | 00:48 |
| NekoXP | if a device wants 1.8A then it will draw it if you supply it | 00:49 |
| NekoXP | the real problem with magnetic media, cdrom drives and so on is that they have a ridiculous need for spinup current, which spikes and is probably way way over the maximum most USB regulators provide. | 00:49 |
| NekoXP | as the device gets older, it actually needs more to spin up | 00:49 |
| NekoXP | from experience, most board designers don't bother to actually have a configurable regulator | 00:50 |
| NekoXP | it's on or it's off | 00:50 |
| persia | Aha. I think I understand then. So the panda apparently defaulting to 100mA unless told to act differently by software is a specific quirk of the implementation, and in general the practice is to pump 500mA while expecting 100mA draw unless something odd happens? | 00:51 |
| NekoXP | it supports 500mA or not. | 00:51 |
| NekoXP | yeah | 00:51 |
| NekoXP | and the reason it doesn't work is your disk is about 6 months old, it has some wear and tear, and the switcher behind the usb port can't handle a load spike as fast as the disk needs it | 00:51 |
| persia | I see. So, if my understanding of the issue is correct, we'd need panda-specific code in u-boot that checked stuff and turned up the regulators if appropriate. | 00:52 |
| NekoXP | possibly | 00:52 |
| persia | Mind you, u-boot needs to completely turn off USB before booting the OS, so just randomly cranking them probably isn't ideal. | 00:52 |
| persia | Do you happen to know that this sort of thing is not required for common i.MX51 and i.MX53 boards? | 00:53 |
| NekoXP | on the efika, vbus controls whether power is on or off | 00:54 |
| NekoXP | it's configured through the phy which some people consider weird | 00:54 |
| NekoXP | we just turn the damn thing on | 00:54 |
| NekoXP | and this always goes through a hub, which is always powered | 00:54 |
| persia | OK, so u-boot just scans USB, does it's thing, turns "off" the devices (but the hub is powered), and loads the OS? | 00:55 |
| NekoXP | if you don't twiddle vbus, the hub gets 20mA and it fucking likes it. that's actually not enough to bring the hub up. | 00:55 |
| persia | Right. I think I understand. Thanks. | 00:58 |
| NekoXP | oh, yeah | 01:03 |
| NekoXP | the other problem with disks is they actually need 12V supplies | 01:03 |
| NekoXP | and USB is 5V | 01:03 |
| persia | Depends on the disk. Lots of 2.5" and 1.8" disks work fine with 5V. | 01:03 |
| NekoXP | so there's some stuff on the board to get a12V supply from a 5V one and they kind of take time to work, and it reduces the current, and of course as THOSE components age.. they suck :D | 01:03 |
| NekoXP | depends on the disk, really | 01:05 |
| persia | Oh, indeed. | 01:06 |
| GrueMaster | I have yet to see a laptop sata drive that needs 12v. | 01:24 |
| * jburkholder got his pandaboard | 02:14 | |
| armelTest | hey anyone have probs with getting the build-essential packages? | 03:19 |
| armelTest | anyone here? | 03:21 |
| persia | armelTest, Lots of folk. | 03:28 |
| persia | For hich release are you having issues getting build-essential packages? | 03:28 |
| armelTest | 9.10 karmic | 03:29 |
| armelTest | any thoughts? | 03:30 |
| persia | Are you pointing at ubuntu-ports.ubuntu.com in your sources.list? | 03:30 |
| armelTest | idk brb | 03:31 |
| infinity | persia: By which you mean posts.ubuntu.com? | 03:33 |
| infinity | s/posts/ports/ | 03:33 |
| armelTest | yeah im waiting on this device to restart | 03:34 |
| persia | Well, considering your hostname and my hostname work equally well for karmic, I'm not sure it matters. | 03:34 |
| infinity | persia: Eh? ubuntu-ports.ubuntu.com doesn't exist. :P | 03:34 |
| infinity | ports.ubuntu.com/ubuntu-ports sure does, though. | 03:34 |
| persia | But it's after 29th April. | 03:35 |
| * persia gets confused | 03:35 | |
| armelTest | ummm can i just echo "deb http://ports.ubuntu.com/ubuntu-ports/" > /etc/apt/sources.list | 03:36 |
| persia | You could. | 03:36 |
| persia | But that this works is an accident. | 03:37 |
| infinity | Except that's wrong. | 03:37 |
| armelTest | huh? | 03:37 |
| armelTest | y? | 03:37 |
| persia | You want "deb http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse" | 03:37 |
| armelTest | ahhh | 03:37 |
| infinity | echo "deb http://ports.ubuntu.com/ubuntu-ports karmic main" > /etc/apt/sources.list | 03:37 |
| infinity | Oh, or old-releases, if karmic's been moved. Right. | 03:38 |
| persia | Except karmic will disappear from ports.ubuntu.com any day now | 03:38 |
| infinity | I just meant "wrong" in that it was missing the dist and component(s). :) | 03:38 |
| persia | It hasn't, but it's EOL, so there's no reason for it not to have moved. | 03:38 |
| persia | Hence my earlier confusion. | 03:38 |
| persia | armelTest, What is your hardware platform? | 03:39 |
| armelTest | arm7 | 03:39 |
| infinity | Be a little more specific. ;) | 03:39 |
| persia | Supports the ARMv7-A ISA? | 03:39 |
| armelTest | htc incredible | 03:39 |
| armelTest | android phone | 03:39 |
| armelTest | brb | 03:39 |
| armelTest | idk is there a way i could find out | 03:40 |
| persia | Well, EOL for the incredible and EOL for karmic match, but given that platform, I'd want to run natty. | 03:40 |
| armelTest | call me a dumb ass but what is natty? | 03:41 |
| infinity | Ubuntu 11.04 | 03:41 |
| persia | armelTest, Find out what? That you have a QSD8650? I used wikipedia. | 03:41 |
| infinity | I used htc.com, similar result. :P | 03:41 |
| armelTest | yes that is it :-) | 03:42 |
| infinity | And then I saw the word "Snapdragon" and died a little inside. ;) | 03:42 |
| armelTest | lol | 03:42 |
| persia | armelTest, So, karmic is EOL, and there's no support for it at all, plus it's slow and buggy. | 03:42 |
| armelTest | bad exp with a snappy | 03:42 |
| infinity | Nope, bad experiences with Qualcomm. I'll recover some day. | 03:43 |
| persia | From the command line, if you run `do-release-upgrade` you should get upgraded to something newer, shinier, and supported. | 03:43 |
| infinity | persia: (Which would just be lucid, going from karmic) | 03:43 |
| infinity | Though lucid runs fine on all my armel hardware here, with the possible exception of kernels. | 03:44 |
| infinity | And I assume he's running an Android kernel. | 03:44 |
| persia | infinity, Would it? The do-release-upgrade manpage is kinda unspecific about precisely where you end up from older systems. | 03:44 |
| infinity | Perhaps a bad assumption, but... | 03:44 |
| armelTest | yeah cyanogen 2.6.37.6 | 03:44 |
| infinity | persia: Only LTSes provide the option to jump to another LTS, everything else will upgrade to the next release. | 03:44 |
| infinity | persia: (In this case, his next release IS an LTS, but whatever) | 03:45 |
| persia | That's a bug in the manpage then, because it says "upgrade to the latest release", rather than the "next newer release". | 03:45 |
| armelTest | http://archive.ubuntu.com/ubuntu/dists/lucid/universe/binary-armel/Packages.gz404 Not Found [IP: 91.189.88.46 80], W:Failed to fetch | 03:45 |
| infinity | Well, if you run it over and over again, you'll get to the latest! ;) | 03:45 |
| infinity | But yeah, file a bug. | 03:45 |
| armelTest | ahhhhh!!!! | 03:46 |
| infinity | armelTest: No armel on archive. | 03:46 |
| infinity | Oh. | 03:46 |
| infinity | do-release-upgrade is confused. | 03:46 |
| persia | Hrm? I thought I fixed that all the way back to hardy! | 03:46 |
| infinity | I bet it would be unconfused if your sources.list said ports. | 03:46 |
| infinity | persia: Did you fix it for the old-releases case? | 03:46 |
| infinity | (Since there's special-case code for s/old-releases/archive/) | 03:47 |
| persia | infinity, I summarily rewrote deb lines in sources.list with what I thought was correct based on other conditions, excepting a whitelist (which didn't include old-releases) | 03:47 |
| infinity | Whacky. | 03:47 |
| persia | Aha, which special case might happen after my summary execution of random mirrors :( | 03:47 |
| infinity | armelTest: echo "deb http://ports.ubuntu.com/ubuntu-ports karmic main restricted universe multiverse" > /etc/apt/sources.list && do-release-upgrade | 03:49 |
| infinity | armelTest: 20 to 1 odds that doesn't trip the broken codepath. :) | 03:49 |
| armelTest | ok brb | 03:49 |
| armelTest | it may be working!!! | 03:51 |
| infinity | Such excitement over a "maybe". I like it. :) | 03:52 |
| armelTest | nope | 03:53 |
| armelTest | brb imma try something | 03:53 |
| persia | infinity, Any idea where that special-case lives? I don't see it in the update-manager or python-apt code, although I see lots of tests in update-manager to make sure it works. | 03:53 |
| infinity | persia: I didn't write it, so not entirely sure, I just know it's there somewhere. | 03:54 |
| infinity | persia: And might sometimes work. | 03:54 |
| persia | I'm certain it's there, or the tests would very clearly fail. | 03:54 |
| armelTest | root@localhost:/# do-release-upgradedo-release-upgradeChecking for a new ubuntu releaseDone Upgrade tool signatureDone Upgrade toolDone downloadingextracting 'lucid.tar.gz'authenticate 'lucid.tar.gz' against 'lucid.tar.gz.gpg'tar: Removing leading `/' from member namespcilib: Cannot open /proc/bus/pcilspci: Cannot find any working access method.Reading cacheChecking package managerPreparing the upgrade failedPreparing the system for | 03:56 |
| armelTest | blah | 03:56 |
| persia | Heh. Seems nobody ever tested do-release-upgrade from karmic. | 03:57 |
| persia | And, yep, it's marked in LP so that we can't update it. | 03:58 |
| persia | OK. Next method. | 03:58 |
| persia | Try "deb http://ports.ubuntu.com/ubuntu-ports/ lucid main restricted universe multiverse" as your sources.list | 03:59 |
| persia | Then try `apt-get update && apt-get dist-upgrade` | 03:59 |
| persia | This is more likely to break than do-release-upgrade, but also less prone to failures from the various bits trying to blunt the sharp edges. | 04:00 |
| armelTest | i can do the apt-get dist-upgrade on a seperate line | 04:08 |
| armelTest | i may run outta room | 04:09 |
| persia | That works too :) | 04:09 |
| armelTest | lol i only have an 8g sdcard and ummm its 82% full | 04:09 |
| persia | Hrm. That *might* work, but it might not. | 04:12 |
| persia | The packages will be upgraded in place, so they shouldn't take up that much room. | 04:12 |
| persia | That said, they all need to be downloaded first, so /var/cache/apt gets kinda full. | 04:12 |
| persia | Running `apt-get clean` will remove any cached package files you have, which may improve things. | 04:13 |
| armelTest | kewl i am learning so much! | 04:13 |
| armelTest | this is awesome. the only reason i wanna do this is so i can develop android apps while driving down the road... | 04:14 |
| infinity | I usually cheat and put /var/cache/apt on a NFS or SMB share when I'm upgrading devices with low space. | 04:14 |
| armelTest | that is really smart | 04:14 |
| persia | Android still doesn't have a self-hosted development environment? Oh my. | 04:15 |
| armelTest | it is upgrading! | 04:15 |
| infinity | persia: It's not meant to. | 04:15 |
| armelTest | well they have the ndk but i like using eclipse tho | 04:15 |
| infinity | persia: Though, I imagine at some point it will anyway. | 04:15 |
| * persia grumbles about silly people using embedded paradigms on perfectly reasonable general purpose computers | 04:15 | |
| armelTest | along with the jdk | 04:15 |
| infinity | (Maybe that point is now, noting the mention of an ndk) | 04:15 |
| armelTest | lol | 04:15 |
| infinity | persia: And preaching to the choir on that one. You have no idea how long I cursed Maemo failing at being perfectly self-hosting and for NO GOOD REASON, except that scratchbox broke it in subtle ways. | 04:16 |
| armelTest | what sux is you have to use vncviewer to load x | 04:16 |
| infinity | (Most things still built fine on Maemo itself, but sometimes things went pear-shaped due to SB breakage) | 04:17 |
| persia | infinity, even the Maemo that shipped with the n810 was self-hosting, if you recompiled everything in a sane environment once: it just needed a bootstrap. | 04:17 |
| infinity | persia: I think my N900 still has a Debian chroot with a full scratchbox environment IN THAT... Stop and think about that insanity for a second. | 04:17 |
| infinity | persia: "Self-hosting, if you re-bootstrap" doesn't quite qualify. ;) | 04:18 |
| persia | infinity, Consider a reinstall: http://wiki.ubuntu.com/ARM/N900 | 04:18 |
| armelTest | that is how linux runs on android chroot | 04:18 |
| persia | Beats failing to self-host because of design decisions in my book. | 04:18 |
| infinity | persia: That would be a better sell, if the URL worked. | 04:18 |
| armelTest | through busybox | 04:18 |
| infinity | Anyhow, off to dinner. | 04:19 |
| persia | https://wiki.ubuntu.com/ARM/n900 | 04:19 |
| infinity | armelTest: Good luck with your fiddling. | 04:19 |
| persia | armelTest, Oh, you don't run Ubuntu native? | 04:19 |
| armelTest | no its chroot | 04:19 |
| armelTest | i cant run native and still have my phone functionality | 04:20 |
| armelTest | which sux | 04:20 |
| persia | Lack or drivers? | 04:21 |
| armelTest | idk never really looked in to it really brb | 04:22 |
| persia | No worries. There's only drivers for a few baseband chipsets, and not so many dialers. | 04:24 |
| armelTest | https://wiki.ubuntu.com/Specs/AndroidExecutionEnvironment check this out | 04:24 |
| persia | Yeah, that got squashed. The mechanism by which it was supposed to work ended up being unmaintained by the Android folk. | 04:25 |
| armelTest | see what you can make outta it. im just a simple programmer just spreading my wings into other platforms | 04:25 |
| persia | NCommander and I should clean that up, and make it clear why it will/won't happen, but we keep putting it off because there is some good idea about how to do it which we don't get around to implementing. | 04:25 |
| persia | As it turns out, lots of other people are trying to do similar things, which may mean that we can eventually implement it just by adding a couple upstream packages and filing some minor bugs. | 04:26 |
| armelTest | xda has some good stuff on it but its greek to me right now | 04:30 |
| armelTest | can i just manually delete the stuff from /var/cache/apt? | 04:34 |
| persia | Better to use `apt-get clean` | 04:35 |
| persia | Otherwise apt can get confused and complain. | 04:35 |
| armelTest | oic | 04:35 |
| persia | apt-get clean will delete everything safe to delete in there. | 04:35 |
| armelTest | well ummm apt-get clean wont work because the dir is locked because its full | 04:35 |
| persia | Right. | 04:37 |
| persia | So, let's step back. Since this is only a chroot, we aren't quite as afraid of bricking the device. | 04:37 |
| persia | How did you construct the chroot? | 04:37 |
| armelTest | nope aint afraid of bricking | 04:37 |
| armelTest | hold on ill send you the script | 04:38 |
| persia | !paste | 04:39 |
| ubot2 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 04:39 |
| armelTest | kewl | 04:39 |
| armelTest | sorry son was trippin bout something | 04:46 |
| armelTest | lol | 04:46 |
| armelTest | http://paste.ubuntu.com/643036/ | 04:47 |
| persia | OK. From where did you get /sdcard/ubuntu/ubuntu.img ? | 04:49 |
| persia | I'm thinking it's probably easier to just replace that then try to upgrade, given the space. | 04:50 |
| armelTest | from xda-developers.com | 04:52 |
| armelTest | i could mount any image and chroot as long as i have the dirs right and the arc is arm | 04:54 |
| persia | OK. | 04:54 |
| armelTest | is that correct? | 04:54 |
| persia | So, I won't recommend any image that isn't hosted by Ubuntu, because I can't trust that it's really Ubuntu | 04:54 |
| * persia fails to say anything about http://forum.xda-developers.com/showthread.php?t=987740 | 04:54 | |
| persia | So, there's a few ways you can get a mountable image file using Ubuntu. | 04:55 |
| persia | 1) You can download one of the images, and then make it do what you want. | 04:55 |
| persia | 2) You can run rootstock to generate a local image (for development only) | 04:56 |
| persia | 3) You can run debootstrap yourself, and construct an image | 04:56 |
| persia | I'd be happy to explain any of those if you like :) | 04:56 |
| armelTest | intresting... i have heard of rootstock. i dont have another arm dev to make an image myself tho | 04:57 |
| persia | Most folk run rootstock on an i386 or amd64 machine, but you will want to have Ubuntu installed there. | 04:58 |
| armelTest | i do have an external 1tb | 04:59 |
| armelTest | u suppose i could install it on that the live/persistant boot and make an image | 05:01 |
| persia | Base images are usually less than 1GB. | 05:02 |
| armelTest | i am about to free up some space on my sd card... got vids of my son i can move over | 05:03 |
| persia | But they often need 2-3GB uncompressed space, so as long as you have more than 4G on that drive, you should be fine. | 05:03 |
| persia | Heh, that might let the upgrade work :) | 05:03 |
| armelTest | lol yeah if i didnt mess up this image by rm *.* in var/cache/apt | 05:04 |
| persia | (and running `apt-get clean` post-upgrade will regain most of the space the upgrade needs) | 05:04 |
| armelTest | only 1 way to find out... yeah the apt-clean didnt work | 05:04 |
| armelTest | apt-get clean | 05:04 |
| persia | Supposedly nothing in /var/cache is important. That said, while I expect apt to be fairly robust, I've not tried that. | 05:04 |
| persia | Does `apt-get update` work? | 05:05 |
| armelTest | brb gonna restart my phone | 05:05 |
| persia | You may need to repopulate apt's local cache of the available software sources before you can clean up. | 05:06 |
| armelTest | shit this is gonna take a min | 05:14 |
| armelTest | well my wife wants me to come be a husband... thanx for your help!!! | 05:16 |
| rsalveti | janimo`: can you trigger a rebuild of wacomtablet? this will fix the ftbfs for it | 05:58 |
| StevenK | rsalveti: Given back. | 05:59 |
| rsalveti | StevenK: thanks | 06:00 |
| rsalveti | StevenK: libtuxcap also need a rebuild | 07:52 |
| rsalveti | crtmpserver too | 08:00 |
| janimo` | rsalveti, given back, now that LP is writable again | 09:40 |
| lilstevie | is there a way of configuring the lid open sensor information? I am inverted | 10:38 |
| lilstevie | if I open the lid, it blanks the screen as per my powere management settings | 10:39 |
| LPhas | i'm quite unable to read information in launcpad.net, but is this package https://launchpad.net/ubuntu-omap4-extras-multimedia supposed to be available to natty ? | 11:45 |
| siji | Hi All | 11:49 |
| siji | Anyone tried XBMC on ubuntu arm ? | 11:50 |
| siji | hello | 12:24 |
| siji | My rootstock build is returning errors like | 12:24 |
| siji | I: Switching to Virtual Machine for second stage processing | 12:24 |
| siji | Segmentation fault | 12:24 |
| siji | W: Bad Bad Qemu, trying second stage one more time (LP #604872) | 12:24 |
| ubot2 | Launchpad bug 604872 in qemu-linaro "qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm" [Medium,Fix released] https://launchpad.net/bugs/604872 | 12:24 |
| siji | How to fix this | 12:25 |
| siji | ogra_, any idea ? | 12:32 |
| siji | friends ,my issue solved | 13:19 |
| siji | added qemu-arm-static | 13:19 |
| mahmoh | my io tests are still runnning on both boards, now init's behaving but the threaded io is really impacting performance (terminal interaction is slow at best) | 13:33 |
| mahmoh | cpu load is minimal, 4-30%, I guess that makes sense - I should check the scheduler though | 13:34 |
| ogra_ | note that we default to no-op on all our images | 13:35 |
| === zyga is now known as zyga-afk | ||
| janimo` | Preparation material for tomorrow's Ubuntu developer week, ARM FTBFS session. Feedback welcome :) https://wiki.ubuntu.com/ARM/FTBFS | 13:56 |
| mahmoh | well mine are set to cfg, oops, I need to check to see which kernel is getting loaded again | 13:59 |
| mahmoh | but the server kernel should be deadline scheduler ogra_ | 13:59 |
| mahmoh | ^ right Daviey? | 14:00 |
| ogra_ | mahmoh, thats something the image build scripts should do, if they dont on your images, files a bug | 14:00 |
| mahmoh | ack | 14:00 |
| ogra_ | for preinstalled we can be sure we are running on SD | 14:00 |
| ogra_ | for that no-op is the fastest | 14:00 |
| ogra_ | thats why we set it to no-op there by default, for server netinstall where you might install to rotary disks, the installer should select the scheduler based on the root device | 14:01 |
| mahmoh | agreed but netinstall should install the correct kernel after tasksel and the server kernel should be deadline, which I need to verify | 14:01 |
| mahmoh | so if I'm able to check - during - netinstall it'll | 14:02 |
| mahmoh | change the scheduler? | 14:02 |
| ogra_ | i doubt there is code for that yet | 14:02 |
| ogra_ | talk to NCommander | 14:03 |
| ogra_ | iirc on the netinst images the flash-kernel-installer udeb creates the kernel cmdline, it should get code to detect the root device and add the proper elevator option to the cmdline | 14:04 |
| mahmoh | makes sense, if it doesn't do that I'll file a bug | 14:04 |
| mahmoh | thx | 14:05 |
| amalgok | hello, I would like to know if I can find a Ubuntu for OMAP35x EVM | 14:39 |
| amalgok | more exactly for AM3517 | 14:39 |
| * ogra_ isnt sure we have a kernel supporting that, but userspace will definitely be fine | 14:41 | |
| amalgok | oh ogra, I've seen that you have built a Ubuntu for OMAP35x EVM | 14:44 |
| amalgok | but the link is dead | 14:44 |
| ogra_ | that was loooong ago | 14:48 |
| amalgok | haha okay | 14:49 |
| ogra_ | you should be able to just use the omap3 images but replace the uImage with yours | 14:49 |
| ogra_ | (and MLO/U-boot.bin) | 14:49 |
| amalgok | yeah I have my uImage | 14:49 |
| ogra_ | see wiki.ubuntu.com/ARM/OMAP | 14:50 |
| amalgok | also mlo and u-boot and x-loader | 14:50 |
| amalgok | but do you know how to create the SD card for an update of the system? | 14:50 |
| ogra_ | ?? | 14:50 |
| amalgok | I've followed this | 14:52 |
| amalgok | http://processors.wiki.ti.com/index.php/MMC_Boot_Format | 14:52 |
| ogra_ | ah, no, just create the SD like described on the ubuntu wikiw | 14:53 |
| amalgok | but I don't understant how to place my kernel and filesystem into the nand flash then (update) | 14:53 |
| amalgok | ah okay | 14:53 |
| ogra_ | then replace MLO, u-boot.bin and uImage on the first partition of the SD | 14:53 |
| amalgok | oh okay | 14:53 |
| ogra_ | the EVM only has 128M, right ? | 14:54 |
| ogra_ | you will most likely want the headless image with that | 14:54 |
| amalgok | 256 | 14:54 |
| ogra_ | yeah, still to low for an ubuntu desktop | 14:54 |
| amalgok | yeah I was thinking about :) | 14:54 |
| amalgok | hum | 14:55 |
| ogra_ | unity.-2d with idling desktop eats 148M here | 14:55 |
| amalgok | okay | 14:56 |
| ogra_ | gnome and xubuntu will be similar | 14:56 |
| ogra_ | KDE will use even more | 14:56 |
| ogra_ | lubuntu could work | 14:56 |
| amalgok | maybe Matchbox | 14:58 |
| amalgok | but don't know if Ubuntu support that | 14:58 |
| ogra_ | its in the archive | 14:59 |
| ogra_ | in universe | 14:59 |
| amalgok | I can't find a version of ubuntu without X11 | 15:01 |
| ogra_ | the headless image is what yxou want, just follow the wiki | 15:04 |
| amalgok | okay I'm trying | 15:06 |
| rsalveti | janimo`: thanks | 15:28 |
| rsalveti | LPhas: not yet, TI didn't release all multimedia components still | 15:42 |
| rsalveti | I know robclark is working on trying to get it all working, so soon we should have something :-) | 15:42 |
| rsalveti | once we get it integrated with gst and such, then normal applications will be able to decode using hw acceleration | 15:43 |
| robclark | rsalveti, display is in bad shape on 2.6.38.. I'm actually starting to work on 3.0.. | 15:49 |
| rsalveti | robclark: and how it's going with 3.0? | 15:49 |
| rsalveti | so we'll end up skipping natty, but luckly it'll work for oneiric :-) | 15:50 |
| rsalveti | and if we get sound working out-of-box it'd be a huge step forward ;-) | 15:50 |
| robclark | I had some issues w/ i2c initially, making DVI not work.. but I seem to have that working now | 15:51 |
| robclark | HDMI is a bit flakey... at least when you have kernel w/ PM enabled.. | 15:51 |
| rsalveti | robclark: hm, interesting | 15:51 |
| rsalveti | robclark: are you also porting the drm driver? | 15:52 |
| robclark | yes, of course ;-) | 15:52 |
| rsalveti | awesome :-) | 15:52 |
| rsalveti | robclark: and where are you publishing your work this time? | 15:52 |
| rsalveti | robclark: would be nice to integrate at the linaro tree once you think it's good enough | 15:52 |
| robclark | rsalveti, well, I'm trying to get display team to push the DSS patches.. and then once those are upstream I can push the drm driver | 15:55 |
| robclark | well.. soon it will have a TILER dependency too (for GEM), but I'll try and keep that separate.. | 15:56 |
| rsalveti | robclark: cool, even better :-) | 15:56 |
| brendand | is oneiric working with the pandaboard yet anyone? | 16:06 |
| ogra_ | sure | 16:12 |
| === zyga-afk is now known as zyga | ||
| GrueMaster | brendand: Alpha 2 server images work well, desktop is hit or miss (due to SD card variants). Current netinstall works as well. | 16:42 |
| GrueMaster | rsalveti: It looks like u-boot is generating two different mac addresses currently. 00:02:03:04:05:06 for bootp and then it looks for panda/pxelinux.cfg/C0A80045 for the pxe config. pxe should be looking for the file with the mac address. | 17:46 |
| GrueMaster | It may be doing a reciprical of the mac. Haven't checked. | 17:47 |
| rsalveti | GrueMaster: how it's getting to C0A80045? | 17:47 |
| rsalveti | probably | 17:47 |
| rsalveti | that's why this will be probably fixed once jcrigby fixes the mac address at u-boot level | 17:47 |
| GrueMaster | ok | 17:47 |
| GrueMaster | Grrr. Local mirror isn't syncing with ports.u.c properly. Can't do netinstall with local mirror. | 17:49 |
| rcn-ee_at_work | GrueMaster, i've had good luck with apt-cacher-ng .... | 17:50 |
| * ogra_ is approx fan | 17:51 | |
| GrueMaster | I'm using a combo of apt-mirror & ubumirror since karmic. Worked quite well until Tuesday. | 17:51 |
| ogra_ | ah, its the tuesday bug | 17:52 |
| GrueMaster | Fill me in. | 17:52 |
| ogra_ | a bug that shows up on tuesdays :) | 17:53 |
| GrueMaster | This is not Windows! | 17:53 |
| * ogra_ was just kidding ... no bug to point to | 17:53 | |
| ogra_ | heh | 17:53 |
| ogra_ | we had one where printing didnt work on tuesdays | 17:53 |
| ogra_ | its not impossible :) | 17:54 |
| GrueMaster | I heard that there was an issue with debootstrap earlier this week. | 17:54 |
| ogra_ | well, with udev and the new /run directory i think | 17:54 |
| ogra_ | but yeah, it breaks debootstrap | 17:54 |
| GrueMaster | I'm having to reinstall one system. Somehow the partitions did a role reversal. 1G rootfs, 156G swap. oops. | 17:55 |
| GrueMaster | Doing a netinstall from ports.u.c works. So I need to figure out what isn't getting mirrored. | 17:55 |
| GrueMaster | apt-mirror only copies debs & source, ubumirror is setup with a large list of excludes to skip old releases & arches I don't care about. Somewhere in there something is getting lost in translation. | 17:57 |
| ogra_ | https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28 | 18:00 |
| ubot2 | Ubuntu bug 255161 in cupsys "I am unable to print from open office, I tried reinstalling open office but it did not work. I use a brother mfc240c printer and I am running Hardy. Printing from other apps has not been an issue. (dup-of: 248619)" [Undecided,Invalid] | 18:01 |
| ogra_ | btw :) | 18:01 |
| ubot2 | Ubuntu bug 248619 in file "file incorrectly labeled as Erlang JAM file" [High,Fix released] | 18:01 |
| robclark | rsalveti, pvr Xorg driver is up and running on 3.0.. i2c still hitting "timeout waiting for bus ready" a lot, which is a bit inconvenient.. | 19:49 |
| rsalveti | robclark: cool, great progress | 20:31 |
| jeremiah | pmcgowan: ping | 20:47 |
| persia | jeremiah, He doesn't seem to be around just now. Is there a general question with which we can help? | 20:48 |
| ogra_ | persia, linux-ac100 is in NEW fyi | 20:55 |
| === arun__ is now known as arun_ | ||
| sgnb | it looks like all ocaml stuff started segfaulting recently on Ubuntu's armel... (whereas everything works fine in Debian) | 21:56 |
| persia | sgnb, Do you have a trace (or a bug with a trace)? | 22:00 |
| sgnb | persia: no, but have a look at https://launchpadlibrarian.net/75113357/buildlog_ubuntu-oneiric-armel.lwt_2.3.0-3_FAILEDTOBUILD.txt.gz | 22:03 |
| sgnb | (I don't have an Ubuntu armel box at hand) | 22:03 |
| persia | sgnb, Hrm. Indeed, that looks unpleasant. | 22:04 |
| sgnb | (same for postgresql-ocaml, ocaml-sqlite3, oasis...) | 22:05 |
| persia | Yeah, with that level, of segfaulting, I'd expect it for everything. | 22:05 |
| persia | Even works for Debian armhf, so unlikely to be an ISA issue. | 22:06 |
| persia | ( http://buildd.debian-ports.org/status/fetch.php?pkg=postgresql-ocaml&arch=armhf&ver=1.16.0-1&stamp=1309697444 by example) | 22:06 |
| ogra_ | bah, sigh, how many more languages are there | 22:08 |
| * ogra_ waits for apachelogger's spam on -changes to stop :P | 22:09 | |
| persia | I seem to recall that the answer was somewhere above 370 last time I tried to answer that question. That was a few years ago, so the number can only have increased. | 22:09 |
| sgnb | persia: but armhf is not native in Debian | 22:09 |
| persia | sgnb, Hrm? Does that affect how the buildd works? | 22:09 |
| sgnb | persia: I mean, ocaml doesn't generate native code for armhf (whereas it does for armel) | 22:10 |
| persia | ogra_, also, thanks for the wiki edit: I now have a happy glow. | 22:10 |
| sgnb | so the generic bytecode compiler/interpreter is used there | 22:10 |
| persia | sgnb, What sort of code does ocaml generate for armhf? Why isn't it native? | 22:10 |
| ogra_ | persia, heh, welcome, lets just hope an archive admin is bored enough to review the kernel now | 22:10 |
| sgnb | it generates a portable bytecode, with run with an interpreter written in C | 22:11 |
| persia | Without the ability to debootstrap, I'm unsure how much I care about the timing there. | 22:11 |
| apachelogger | lol | 22:11 |
| * ogra_ will land the flash-kernel bits and -meta tomorrow | 22:11 | |
| apachelogger | ogra_: couple more two come | 22:11 |
| persia | sgnb, Do you happen to know why it isn't native for armhf? | 22:11 |
| apachelogger | <50 ^^ | 22:11 |
| * ogra_ hugs apachelogger :) | 22:11 | |
| sgnb | persia: because it hasn't been activated | 22:11 |
| * apachelogger hugs ogra_ right back | 22:11 | |
| sgnb | (so never tried) | 22:12 |
| persia | sgnb, Hrm. Then it *could* be an ISA issue :( | 22:12 |
| sgnb | native code generated by ocaml compiler on arm always uses soft floats... would that be a problem? | 22:12 |
| persia | No, Ubuntu armel uses a softfloat ABI, but it's ARMv7 vs. ARMv4t for Debian armel, which means that some assembly isn't compatible. | 22:13 |
| ogra_ | but that would have been a prob since lucid | 22:13 |
| persia | Ubuntu armel is also compiled to thumb2 by default, rather than ARM, which has other knock-on effects in terms of allowable ISA and ABI interactions. | 22:14 |
| persia | ogra_, Depends what instructions are being excited. A new upstream version might have some improved optimisation, or changes to call semantics that could trigger something. Needs investigation. | 22:14 |
| * ogra_ blames toolchain or libc | 22:14 | |
| ogra_ | note that the old ocaml segfaults here | 22:15 |
| ogra_ | while building new ocaml stuff | 22:15 |
| sgnb | "old"? "here"? | 22:15 |
| ogra_ | in the build log you linked | 22:16 |
| persia | That's for lwt. | 22:16 |
| ogra_ | it calls /usr/bin/ocamlfoo | 22:16 |
| ogra_ | which segfaults durign execution | 22:16 |
| persia | Sure, but I'm not sure why that is necessarily "old". | 22:16 |
| ogra_ | its not a new upstream, it is what is in the archive right now | 22:17 |
| persia | Do you happen to know that no new upstream for ocaml-nox has entered the archive in oneiric? | 22:17 |
| ogra_ | no, i dont, do you happen to know it did ? | 22:17 |
| ogra_ | ;) | 22:18 |
| persia | I do. oneiric has 3.12.0, whereas natty only had 3.11.2 | 22:18 |
| sgnb | but stuff has been already compiled successfully with 3.12.0 in oneiric in the past | 22:19 |
| persia | That's extra annoying. | 22:19 |
| persia | Because it means that some library changed ABI without updating SONAME underneath ocaml. | 22:19 |
| persia | sgnb, Do you happen to know the *first* package that FTBFS due to ocaml segfaulting wildly? | 22:19 |
| sgnb | I think it is oasis | 22:21 |
| sgnb | (according to http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html ) | 22:21 |
| persia | ogra_, Do you know of any way to find stuff that built on 29th June? | 22:23 |
| ogra_ | not really, apart from checking -changes | 22:23 |
| persia | That's sources, not binaries. | 22:23 |
| persia | And 29th June was pre-DIF, so all the autosync stuff is invisible to -changes | 22:24 |
| persia | sgnb, I really don't expect you to have an answer, but do you happen to know the last package that worked? | 22:24 |
| sgnb | persia: my guess would be nurpawiki | 22:25 |
| sgnb | or ocaml-data-notation, maybe | 22:26 |
| sgnb | (based on what happend in Debian) | 22:26 |
| * persia goes to investigate that, with hope, wondering how one could possible find this | 22:26 | |
| persia | Ah, yeah, given the essentially random timing of autosync, I have no idea how reliable that might be (autosync is a manual process, which happens whenever an archive admin has ~10 minutes to kick it off, but not less than twice a week) | 22:27 |
| persia | nurpawiki build 2011-05-20 | 22:27 |
| persia | ocaml-data-notation failed 2011-06-28 with mp segfaults (unlreated failure). | 22:28 |
| persia | 2011-06-28 to 2011-06-29 is close enough I'll dig through the versions of build-depends, hoping to find a useful discrepancy | 22:29 |
| persia | libmpfr4 3.0.1-3 -> 3.0.1-4 | 22:32 |
| persia | libudev 171-0ubuntu3 -> 171-0ubuntu4 | 22:33 |
| persia | apt 0.8.14.1ubuntu7 -> 0.8.15ubuntu1 | 22:33 |
| persia | udev matching libudev | 22:33 |
| persia | apt-transport-https matching apt | 22:34 |
| persia | mprf4 looks like a no-op failed attempt to clean up how patches are applied in a format: 3.0 (quilt) package. | 22:36 |
| ogra_ | and the others dont look like they could make binaries segfault | 22:37 |
| ogra_ | (that worked before) | 22:37 |
| persia | udev is a cleanup on stopping udevd processes, which shouldn't even be used in a buildd chroot. | 22:38 |
| persia | No, but if I don't investigate, I'm not going to be confident :) | 22:38 |
| ogra_ | i think its some transient issue from something completely ocaml unrelated | 22:39 |
| ogra_ | i would have said libc but that doesnt match the timing | 22:39 |
| persia | I'm not convinced it's transient, as it has persisted for two weeks. | 22:39 |
| persia | Still, checking build-essential happens first, then specific build-depends (in part because I have to clean up my script to generate readable diffs for build-deps) | 22:39 |
| ogra_ | binutils was upgraded on the 18th ... doesnt fit either | 22:40 |
| sgnb | the first segfaulting command is "/usr/bin/ocamlfind query -format %v findlib"... maybe it's easier to test it in past snapshots? (à la git-bisect) | 22:40 |
| persia | apt change is large, but I can't see anything that should affect other binaries at runtime. | 22:41 |
| sgnb | oh! but ocamlfind itself changed meanwhile | 22:41 |
| sgnb | (1.2.6 -> 1.2.7) | 22:41 |
| persia | Indeed. 1.2.7+debian-1 failed, but 1.2.6+debian-1build1 succeeded. | 22:42 |
| ogra_ | aha, i though it didnt | 22:42 |
| sgnb | I cannot imagine how this could have an influence, though | 22:42 |
| persia | Maybe there was a misbuild. | 22:42 |
| sgnb | "misbuild"? | 22:43 |
| persia | Could "Make Camlp4 depend on Dynlink on every arch" affect the autodependency generators? | 22:43 |
| ogra_ | - add armel to native architectures; note that the Dynlink module is | 22:43 |
| ogra_ | not available in native code there: software using it should take care | 22:43 |
| ogra_ | of this new possibility | 22:43 |
| persia | Aha! That would be the issue then. | 22:44 |
| ogra_ | from the ocaml changelog | 22:44 |
| sgnb | this was way before | 22:44 |
| ogra_ | not sure thats the issue but it could | 22:44 |
| persia | Debian bug #630490 | 22:44 |
| ubot2 | Debian bug 630490 in libfindlib-ocaml "camlp4 depends on Dynlink on all architectures" [Important,Fixed] http://bugs.debian.org/630490 | 22:44 |
| ogra_ | debian bug #347270 | 22:44 |
| ubot2 | Debian bug 347270 in ocaml "ocamlopt produces buggy arm programs" [Important,Fixed] http://bugs.debian.org/347270 | 22:44 |
| ogra_ | oh, another intresting entry | 22:45 |
| ogra_ | add binutils-dev to Buid-Depends | 22:45 |
| persia | That's *OLD* | 22:45 |
| sgnb | yes, way before nurpawiki | 22:45 |
| persia | Oh, but not Fixed old :) | 22:45 |
| persia | But yeah, ocaml isn't the issue. | 22:46 |
| persia | Both the working and failed builds use ocaml 3.12.0-7 | 22:46 |
| ogra_ | thats what came into ubuntu on may 5th | 22:46 |
| ogra_ | afterwards the ocaml transition started | 22:46 |
| persia | Don't care. It's not different between oasis and ocaml-data-notation builds, so it is unlikely to be the cause of one failing and the other succeeding. | 22:47 |
| sgnb | the ocaml transition finished before stuff started segfaulting | 22:47 |
| ogra_ | yes | 22:47 |
| sgnb | (it finished with nurpawiki) | 22:47 |
| persia | Well, ocaml-data-notation was built in Ubuntu over a month after nurpawiki, but kinda :) | 22:48 |
| sgnb | it was not part of the "ocaml 3.12.0 transition" | 22:48 |
| persia | Ah. | 22:48 |
| sgnb | by "ocaml 3.12.0 transition", I mean "recompile everything because ABI changed" | 22:49 |
| persia | Right. | 22:49 |
| sgnb | after that, we continued updating things in Debian as usual | 22:49 |
| persia | Still, I'm suspecting findlib for now. | 22:49 |
| persia | But I don't see anything in the patch that is especially exciting. | 22:50 |
| persia | https://launchpadlibrarian.net/74281241/findlib_1.2.6+debian-1build1_1.2.7+debian-1.diff.gz | 22:50 |
| sgnb | the changes also look innocuous to me | 22:51 |
| sgnb | it might be that the generated assembly for the new version is somehow bugguy | 22:51 |
| persia | There's a number of "failed to remove" and "cannot stat" messages in the build log. | 22:51 |
| sgnb | OCaml code shouldn't segfault by itself | 22:52 |
| persia | Shouldn't or can't? It is native-compiled, right? | 22:54 |
| sgnb | I don't see the difference | 22:54 |
| sgnb | it is impossible in pure OCaml to do a segfault, it's a property of the language | 22:54 |
| sgnb | and ocamlfind looks like pure OCaml | 22:55 |
| sgnb | (I mean, except basic I/O) | 22:55 |
| sgnb | segfaults in ocaml programs usually comes from C code called from OCaml code | 22:56 |
| persia | That'd be can't :) | 22:57 |
| persia | Lesser languages aren't defined in a way that prevents such behaviours. | 22:57 |
| persia | But some *shouldn't*, because of how they work, for example python or java. | 22:58 |
| persia | Whereas something like C has neither sort of protection, and segfaults reliably. | 22:58 |
| persia | Aha! So, the new findlib build is whining about not being able to parse ${ocaml:Depends}. | 22:59 |
| sgnb | persia: you mean dpkg-gencontrol? | 23:00 |
| persia | Yes | 23:00 |
| sgnb | it doesn't matter | 23:00 |
| sgnb | it is a common warning | 23:00 |
| sgnb | and only related to build tools | 23:01 |
| sgnb | (I mean dpkg-dev) | 23:01 |
| persia | I thought that warning happened whenever one didn't handle the substr stuff properly. | 23:01 |
| sgnb | it happens when the variable is not defined | 23:02 |
| persia | But the package relationships are very similar between 1.2.6+debian-1build1 and 1.2.7+debian-1 : the latter adds a recommendation on libfindlib-ocaml-dev | 23:03 |
| sgnb | it does that even for shlib:Depends | 23:03 |
| persia | I'm of the opinion that one should only use variables in control that one defines, but I'm known for being kinda particular about things :) | 23:03 |
| sgnb | maybe, but that's not the point here | 23:04 |
| sgnb | if I had access to a faulty box, I would start running gdb on "ocamlfind query -format %v findlib" to see where exactly the segfault occurs | 23:04 |
| persia | Unfortunately, it seems findlib doesn't have a test suite that runs at build-time, so we can't know that the build worked (or didn't). | 23:04 |
| * persia tries to run debootstrap again, in vain hope, given the continued discussion in #ubuntu-devel | 23:06 | |
| persia | ogra_, In unrelated news, did you see my 0.0.0.0.0.0.0.0.1 package? Any suggestions to improve the README or change the package split? | 23:07 |
| ogra_ | well, i would at least add another 0 to the version | 23:08 |
| ogra_ | i saw your ping in the other channel, but havent looked yet | 23:08 |
| persia | Please don't. I tried to add enough that when upstream (you) decides to actually release code, there would be no change of conflict. | 23:08 |
| persia | s/change/chance/ | 23:09 |
| ogra_ | wsell, i would just take yours :) | 23:09 |
| ogra_ | the code surely needs cleanup, i didnt write it with a generic installer in mind | 23:09 |
| persia | Considering that the README isn't complete and talks about killing kittens, that -tools is missing one of the scripts, and all the other issues, I'd hope not directly. | 23:09 |
| ogra_ | and i cant imagine many ways to package it | 23:10 |
| ogra_ | you split it ? | 23:10 |
| ogra_ | what did you split into tools ? | 23:10 |
| persia | Surely. | 23:10 |
| ogra_ | it should eb a single package with three initrd files | 23:10 |
| persia | There's the stuff that belongs in the image, and the stuff that belongs on the machine used to create the image. | 23:10 |
| persia | Go look. | 23:10 |
| ogra_ | one in conf.d one in hooks and one ins scripts | 23:11 |
| persia | I think I have four scripts. | 23:11 |
| persia | Maybe five. | 23:11 |
| ogra_ | the one additional script isnt for the public ... it will be worked into debian-cd | 23:11 |
| persia | debian-cd is public :) | 23:11 |
| ogra_ | (the one that adds the md5sum file) | 23:11 |
| ogra_ | well, i meant as extra code | 23:11 |
| persia | But yeah, if you're sticking the control code into debian-cd, then -tools isn't useful. | 23:11 |
| ogra_ | sure it should be public | 23:12 |
| persia | Oh well. libc6 still doesn't install in the chroot :( | 23:12 |
| ogra_ | build natty and upgrade ;) | 23:12 |
| persia | Hrm. I wonder if my wrapper scripts can handle that. | 23:13 |
| persia | Maybe I'll just do a one-off upgrade of natty to test this one thing. | 23:13 |
| * persia grumbles at dpkg: error: failed to open '/var/lib/dpkg/status' for writing status database: Invalid argument on a natty->natty upgrade | 23:50 | |
| persia | sgnb, I get an immediate segfault return from `ocamlfind query -format %v findlib` on current oneiric/armel | 23:51 |
| persia | Any hints on what to check, or do you recommend digging through core? | 23:51 |
| sgnb | persia: run through gdb, and pinpoint where the segfault comes from | 23:57 |
| sgnb | (is it C code? is it assembler? is it a library?) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!