[00:24] <blackboxsw> smoser: rharper release 18.3 branch
[00:24] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254
[00:24] <blackboxsw> then I can push an MP for cosmic
[00:25] <blackboxsw> will check back in a couple hours
[01:08] <smoser> blackboxsw: ah. ok. i had thought throw snapshot into cosmic
[01:08] <smoser> and then tomorrow do a release.
[01:14] <smoser> blackboxsw: i think if the goal is just to upload to cosmic with a 18.3, then lets wait til morning before we tag.
[01:14] <smoser> that will get us a nightly c-i run on trunk also.
[01:24] <smoser> blackboxsw: i went ahead and kicked off a 'Build Now' for each recipe
[01:24] <smoser>  https://code.launchpad.net/~cloud-init-dev/+recipes
[01:24] <smoser> so we'll have daily archive up to date shortly with master (a670eb81)
[01:24] <smoser> with fingers crossed that there are no keyserver demons lurking
[01:26] <smoser> alright. landing https://code.launchpad.net/~cloud-init-dev/+archive/ubuntu/daily/+packages
[01:26] <smoser> and i'm going to take off on that note.
[02:30] <blackboxsw> sounds good scott
[15:05] <smoser> ok... as a form of version control http://paste.ubuntu.com/p/tcj3QhSmGD/
[15:05] <smoser> that is skip_by_date as a decorator, i plan to try to put it into curtin soon.
[16:03] <smoser> rharper: https://code.launchpad.net/~smoser/curtin/+git/curtin/+merge/348282
[16:03] <smoser> oops.
[16:06] <rharper> hehe
[16:15] <blackboxsw> smoser: so SRU and https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254
[16:15] <blackboxsw> shall I push an 18.3 tag to upstream to get CI to work there and get that landed?
[16:16] <blackboxsw> and we cut a cosmic, xenial artful bionic set of merges?
[16:48] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348254
[17:27] <blackboxsw> hrm ok smoser rharper , I've bungled/missed something with pushing my tags and trying to push 18.3 to origin(upstream).
[17:27] <smoser> ok
[17:27] <blackboxsw> I think I've pushed 18.3 tag to our common repo for cloud-init
[17:27] <blackboxsw> git tags --list shows it when I have master checked out. yet git log --decorate doesn't decorate the proper commit with the tag name
[17:28] <smoser> i think a rebase happened or something....
[17:28] <blackboxsw> I do see the tag decorating my specific branch release/18.3
[17:29] <smoser> probably in your merge review thing
[17:29] <smoser> upstream/master is differant than the tag
[17:29] <smoser> i can fix or you can, but essentially
[17:29] <smoser> git checkout master
[17:29] <smoser> git reset --hard 18.3
[17:29] <smoser> git push upstream master --force
[17:30] <smoser> or probalby that is just
[17:30] <smoser> git push upstream 18.3:master --force
[17:30] <smoser> or something
[17:31] <blackboxsw> ok worked. I'll sort what review-mps did/does as it merges the branch locally (giving us a different commitish I think).
[17:31] <smoser> right
[17:31] <smoser> what it could do is
[17:31] <smoser> git merge --ff-only
[17:31] <blackboxsw> right, I think.
[17:32] <smoser> if there was 1 new commit and that worked, it could do that.
[17:32] <smoser> other wise, it woudl rebase and squash like it does.
[17:32] <blackboxsw> yeah multicommits we'd have a problem as we are squashing
[17:32] <blackboxsw> yeah
[17:32] <blackboxsw> ok will add that to review-mps today. single commit --ff-only option
[17:33] <smoser> i think i'd just have it do it if it could
[17:36] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348300 is up
[17:38] <smoser> ok. before we do that lets get the release into launchpad
[17:38] <smoser> blackboxsw: can you take a quick glance at changelog for highlights ?
[17:38] <smoser> ah. i knwo. hackmd link coming.
[17:39] <smoser> https://hackmd.io/lIMTEWtaSpGgrleLM0pJBQ
[17:39] <smoser> blackboxsw: ^
[17:52] <blackboxsw> checking
[17:54] <smoser> blackboxsw: just sent.
[17:54] <smoser> you were too slow :)
[17:54] <smoser> no big deal.
[17:55] <blackboxsw> heh, nice. my coffee machine was too slow you mean
[17:55] <blackboxsw> is it worth me scripting all bugs mentioned in changelog to the given milestone?
[17:56] <smoser> ?
[17:56] <blackboxsw> per the "35 launchpad.net issues" fixed
[17:56] <smoser> oh. i did that sort of
[17:56] <smoser> and updated that doc
[17:56] <blackboxsw> we could target them to https://launchpad.net/cloud-init/+milestone/18.3
[17:56] <blackboxsw> so they'd show there
[17:56] <blackboxsw> too
[17:57] <smoser> we could do that. and i guess do that in lp-bugs-released.... i dont know.
[17:57] <blackboxsw> as a point of reference in the future for stuff that was fixed
[17:57] <blackboxsw> yeah I was thinking lp-bugs-released extension
[17:57] <smoser> i'm going to run the lp-bugs-released script now.
[17:57] <smoser> is that ok ?
[17:57] <blackboxsw> +1
[17:57] <smoser> k
[17:57] <blackboxsw> I have a tweak for specific bug series task. I think which might help as the SRU progresses
[17:58] <blackboxsw> a tweak to only target the specific bug distro-series task rather.
[17:58] <smoser> ?
[17:59] <smoser> the lp-bugs-released only does upstream
[17:59] <smoser> right?
[17:59] <blackboxsw> right, but it could do individual series tasks too per something like https://launchpad.net/cloud-init/+milestone/18.3
[18:00] <blackboxsw> WIP patch obviously. I was just peeking at it.
[18:00] <blackboxsw> oops bad paste
[18:00] <blackboxsw> http://paste.ubuntu.com/p/k6tTxnzTrN/
[18:01] <smoser> i just fixed the "version "
[18:01]  * blackboxsw gets merge proposals for xenial,artful, bionic together now (and filing an SRU bug)
[18:01] <blackboxsw> smoser: you haven't filed an SRU bug yet have you?
[18:03] <smoser> no.
[18:04] <blackboxsw> ok filing
[18:05] <smoser> bug mail coming in 5....
[18:05] <smoser> 4, 3, 2, 1
[18:06] <smoser> blackboxsw: ok. on that note, i have to run. i'll be back in later and can do uploads for sru then.
[18:06] <blackboxsw> ok thanks man
[18:06] <smoser> i think release is all done now.
[18:07] <blackboxsw> dragging the trello card
[19:16] <blackboxsw> smoser: I pushed minor changes into new-upstream-snapshot
[19:17] <blackboxsw> to account for debian/changelog containing xenial-proposed instead of xenial
[19:32] <blackboxsw> 3 branchs for SRU upload review tied to this card smoser https://trello.com/c/8jshO6oa/847-sru-183-to-xenial-artful-and-bionic
[19:32] <blackboxsw> *branches*
[19:47]  * blackboxsw needs to tweak artful and xenial branches there. we need to disable OpenstackLocal.network_config by default
[19:48] <blackboxsw> as it is configurable to "apply_network_config: true" in datasource config
[19:48] <blackboxsw> and we don't want to change artful/xenial behavior... maybe bionic too? WDYT rharper smoser
[19:49] <rharper> right, I think we played some games with the names in the datasource class when we did this with AzureDatasource
[19:50] <blackboxsw> rharper: the way I wrote DataSourceOpenstack.network_config property we now check if ds_cfg.get('apply_network_config') == False: return None. This renders fallback config (which is what xenial->bionic do today)
[19:51] <blackboxsw> question I have is, should bionic continue to only render fallback config :/?
[19:51] <rharper> yes
[19:51] <blackboxsw> ok will apply a patch for those releases
[19:51] <blackboxsw> to adjust the default behavior to fallback for all 3 series
[19:52] <rharper> let me think on it a bit too;  IIUC, we could run "faster" but only render fallback config
[19:52] <rharper> which wouldn't change functionality, just the speed, right ?
[19:52] <rharper> where as in cosmic, we could read network_data.json over metadata service at local and render that instead of fallback
[19:54] <blackboxsw> correct on all counts. we could either patch to remove DataSourceOpenstack.network_config subclassed property altogether (to run faster and retain exact current behavior).   OR -
[19:54] <blackboxsw> we could patch Openstack.network_config to default to apply_network_config == False  if not provided, thereby allowing someone to override that and react to network_data.json if they want (a little slower as we check a config option value before rendering fallback config)
[19:55] <blackboxsw> I think we want the 2nd choice on Xenial-Bionic as it is a useful feature to turn on if someone wants it
[19:55] <blackboxsw> though I think they'd have to turn it on in their images, not user-data
[19:56] <rharper> yes; I'm included to keep fallback rendering for OS metadata service in Xenial -> Bionic, but run at local if we can
[19:56] <blackboxsw> ok good deal
[19:56] <rharper> that produces a speedup ( \o/ ) without a change in function
[19:56] <rharper> let's see if smoser agrees
[19:56] <blackboxsw> yeah exactly, local timeframe == speedup
[20:29] <robjo> blackboxsw: I was going to take a look at lp#1733226 and thought this may not lead too far down the rabbit hole, but turns out that dhclient stuff appears to be splattered across data sources and other parts of the code
[20:29] <robjo> so I need some guidance and maybe this is too big of a project to start on late Wednesday afternoon and better wait for THursday morning
[20:46] <blackboxsw> bug #1733226, yeah that's a not easy to start late Wedneday robjo : /
[20:47] <blackboxsw> yeah the context hander and sandboxed environment with dhclient vs wicked is potentially a bit of a dig
[20:48] <robjo> OK, I'll ping you another day
[20:49] <blackboxsw> hrm, so was this Openstack  robjo ?
[20:49] <blackboxsw> could you cloud-init collect-logs and add the tarfile?
[20:49] <robjo> I do not know, I can ask in the bug report I do not know the reporter
[20:50] <blackboxsw> or Ec2/Azure maybe? those are the 3 major datasources that use it currently
[20:51] <robjo> Lets see if we get an answer
[20:52] <blackboxsw> it may be as simple as just replaceing dhclient with wicked, but there is lease processing etc.. and I haven't looked at how wicked stores dhcp-related conf etc. (I'm guessing that's in my immediate future)
[20:56] <blackboxsw> sounds good robjo, yeah we need to fix this for SLES it seems as this EphemeralDHCPv4 context manager is the direction most datasources are oging
[20:56] <blackboxsw> *are going
[20:56] <robjo> Well, I'll do leg work, but the idea of having to change 3 data sources and then doing so for others potentially in the future is not very appealing, seems there should be an abstraction ;)
[20:57] <blackboxsw> robjo: yeah it's all in cloudinit.net.dhcp maybe_perform_dhcp_discovery
[20:57] <blackboxsw> might want to extend it to accept network_util='dhclient' default
[20:57] <blackboxsw> which could be overridden with wicked I suppose
[20:58] <robjo> Found that file, but also saw in the azure datasource I think (via grep) what looked like hard coded info about lease info
[20:59] <blackboxsw> ohh yeah, yuck right. hardcoded dhcp lease path
[20:59] <robjo> given the we're "special" :rolling_eyes: maybe this should not be distro independent, but I suspect major surgery is required to make this distro dependent
[21:00] <blackboxsw> though that datasource already does a switch on util.is_FreeBSD to tweak expected lease_file path on different distros
[21:03] <blackboxsw> hrm maybe distro could announce default network_cmd, we also have to solve this for a netplan-only world too, as dhclient is not really a mandatory command in newer ubuntu series.
[21:04] <blackboxsw> so this is a type fix that is on our radar, just hadn't tried tackling it yet because we didn't need to... yet.
[21:04] <robjo> network_cmd would probably be a dict then if we want to support the lease monitoring part we'd need at least dhcp_client_cmd,dhcp_client_options, lease_info
[21:07] <robjo> and interface
[21:07] <blackboxsw> could be, I'm kindof leaning toward the idea that maybe_perform_dhcp_discovery should be smart enough to detect valid dhclient commands and make a sane choice based on present of the utility so that we don't continue to bloat the Distro classes. but it'll require a bit more thought for the use-cases
[21:07] <blackboxsw> *based on presence/absence of the utility*
[21:08] <blackboxsw> I liked what you did w/ ifconfig vs ip stuff
[21:08] <blackboxsw> it feels like it contains that logic in a single place local to where it is being used (even though it's kindof distro related)
[21:10] <blackboxsw> but again, I'm not certain this EphemeralDHCPv4 solution is strictly compatible with a systemd networkd -only world.
[21:10] <blackboxsw> one idea we were tossing around was to write our own tiny python dhclient which opens a socket to do the dhcp discovery
[21:11] <blackboxsw> all we are attempting to do is sniff a lease on the primary nic if available.
[21:11] <blackboxsw> this may be time for us to queue that work :
[21:11] <blackboxsw> this may be time for us to queue that work :/
[21:12]  * blackboxsw and socket programming from python. not a well used muscle.
[21:12] <robjo> The advantage of ifconfig/ip transition is that ip options are universal, but for the dhcp stuff distros, staring with SLES have clearly diverged and it appears there may be further drift, so having "smart" handling in one place may lead to lots of if-elif-elif code
[21:13] <robjo> well getting a dhcp request out in and off itself is not all that difficult, what I don't know what effect that has on subsequent requests
[21:14] <robjo> For example when AWS added ipv6 and wicked sent out options the dhcp server didn't understand they just didn't respond
[21:15] <robjo> so no lease :(
[21:15] <robjo> presumably a cloud-init implementation of get_dhcp_lease() would not send any option or only a minimal set
[21:16] <robjo> but then what does the dhcp server do when the next request comes from the same origin, does it just return what it already handed out and ignore other options that might be sent along?
[21:16] <robjo> I have no idea how that works
[21:18] <robjo> And maybe this topic is too big for IRC and e-mail and we should beat on it during the summit
[21:18] <blackboxsw> correct, cloud-init's get_dhcp_lease()  would be a dumb/simple dhcp-discovery packet without any custom options. It'd blindly return a dict of whatever lease options the response gave.   Generally the dhcp server ends up giving out the same IPs on previous discovery if the lease time hadn't expired I believe. (as it's how it's currently working in ec2/openstack.
[21:18] <blackboxsw> agreed, it's a big topic. I think you are right.
[21:19] <blackboxsw> I'll add it to the list of potential topics
[21:19] <blackboxsw> currently I have the following:
[21:19] <blackboxsw> topic ideas:
[21:19] <blackboxsw>  - move SLES & openSUSE to sysconfig renderer
[21:19] <blackboxsw>  - hotplug network stuff (one-shot stuff)
[21:19] <blackboxsw>  - cloud-init as a daemon for repeatable calls, expedited boot runs
[21:19] <blackboxsw>  - wicked support for EphemeralDCHPv4
[21:20] <blackboxsw> as we get closer that list will probably grow into a hackmd doc we can all comment on that we will send to the mailinglist
[21:21] <robjo> David already had a preliminary agenda, I take it you'll coordinate with that ;)
[21:23] <blackboxsw> yeah if I have to ;)
[21:33] <rharper> blackboxsw: another alternative that we've discussed multiple times but never dig to the bottom is replacing dhclient with cloud-init dhcp client in python itself; then Ephemeral would not have to depend on dhclient which may or maynot be present, etc
[21:33] <rharper> so, in the agenda, maybe replace wicked string with 'EphermalDHCP alternatives to isc-dhcp client'
[21:34] <rharper> we've the same issue in Artful/Bionic/Cosmic though we pull the dhclient in now; really that shouldn't be in there as networkd procides a dhcp client as well
[21:42] <robjo> I added a short summary to bug #1733226
[21:42] <robjo> having a cloud-init get_dhcp_lease() is included as option 4
[22:04] <smoser> blackboxsw: thanks for remembering about the datasource local in bionic.
[22:04] <smoser> i think we should bite the bullet there.
[22:04] <blackboxsw> yeah a quick grep of RELEASE_BLOCKER
[22:05] <blackboxsw> we need to retire/remove the snap modules too :/
[22:05] <blackboxsw> the old snappy etc.
[22:05] <blackboxsw> but not critical
[22:05] <smoser> yeah, that snot a big deal.
[22:05] <smoser> hm...
[22:05]  * blackboxsw is wondering how best to cherry pick the ubuntu/xenial/debian/patch/openstack* into ubuntu/artful which has no patches dir...
[22:06] <blackboxsw> was trying ./debian/cherry-pick, but it falls over because there is no existing debian/patches/series file
[22:06] <blackboxsw> wondering if I manually do the work in artful and then cherry pick to bionic (which also has no patches subdir/series
[22:08] <smoser> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348309
[22:08] <smoser> that has fail build right now
[22:08] <smoser> shoot.
[22:09] <blackboxsw> bah have to fix unit tests too :/
[22:11] <smoser> lets think.
[22:12] <smoser> one thing we generally want to do is update the ubuntu/ branches right after we land something like this
[22:12] <smoser> so that our daily builds would have been doing this sense it weent in.
[22:13]  * smoser shoudl have remembered that and done something then
[22:20] <blackboxsw> the following would work for ubuntu/xenial I think http://paste.ubuntu.com/p/mNNQgwTPcT/
[22:20] <blackboxsw> it tweaks the unit test which will fail (after debian/patch applied) to present the right ds_config setting True
[22:28] <smoser> blackboxsw: i'll give this a good think tomorrow. would like to get an sru upload in, but want to think it though.
[22:29] <blackboxsw> yeah I was thinking there's probably not enough time to talk through the options.
[22:29] <blackboxsw> I'll fix xenial so we have a strawman on the approach, to shoot down if need be
[22:29] <blackboxsw> artful/bionic are bogus, so I'll pull them,
[22:32] <blackboxsw> ok pushed xenial again, will let CI run it's course
[22:33] <blackboxsw> gotta take a break
[22:53] <blackboxsw> ok xenial mp is at least in good enough shape for discussion about the approach for patching desired openstack behavior https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348309
[23:21] <blackboxsw> rharper: do we need to change behavior of ntp/chrony on xenial->bionic with this upcoming SRU?
[23:21] <blackboxsw> per bug #1749722
[23:22] <blackboxsw> I think not, but wanted to be sure


[08:32]  * Chipaca goes for coffee
[08:32] <Chipaca> actually, let's make that a whole breakfast
[08:58] <jam> morning Chipaca, enjoy your breakfast
[11:04] <facubatista> ¡Muy buenos días a todos!
[11:16] <jam> morning facubatista
[11:17] <facubatista> hola jam
[11:49]  * Chipaca harrumphs some more
[13:16] <facubatista> jam, please remember my https://github.com/canonical/charmcraft/pull/76
[13:16] <mup> PR charmcraft#76: Store upload <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/76>
[13:16] <facubatista> crodriguez, hola! please let's work on your charm when you have some minutes, thanks!
[13:16] <jam> facubatista, indeed, I have it open, just ran into some issues so didn't get a review completed
[13:17] <facubatista> jam, no rush, thanks!
[13:17] <crodriguez> morning facubatista ! I sent you an invite for a meeting later today. I'm in the field/sales sprint all day before that
[13:18] <facubatista> crodriguez, ah, oh, wonderful, thanks!
[13:18] <crodriguez> :)
[18:45] <crodriguez> facubatista: did you lose connection?
[18:50]  * facubatista totally lost internet for ~30s
[19:11] <crodriguez> haha
[19:12] <crodriguez> is charmcraft build taking templates into consideration? I added a template folder under my charm root, but it is not copied over when I deploy the charm
[19:17] <crodriguez> also, it creates only the 3 mandatory hook names. It is not creating config-changed, etc.
[19:24] <facubatista> crodriguez, we're not including "templates", we need to fix that
[19:24] <crodriguez> yeah, I opened https://github.com/canonical/charmcraft/issues/80
[19:24] <facubatista> I wonder if we should provide a "--include" option to let devs include whatever they want
[19:25] <crodriguez> I wonder why it wouldn't just include every folder you include in your charm, maybe only excluding what is excluded by .gitignore
[19:25] <facubatista> (which could be annotated in the charmcraft.yaml file, so no need to specify it always)
[19:26] <facubatista> crodriguez, but there's stuff one would want to avoid: the tests, for example, which may have fixture files that may make the zip large
[19:26] <crodriguez> ah we can configure the build with a charmcraft.yaml file ? interesting
[19:26] <facubatista> crodriguez, we WILL be able to :)
[19:26] <facubatista> sorry, we're yeat too young :p
[19:27] <crodriguez> haha until today I just deployed directly the charm without building and it was working fine. I guess charm build is necessary for dependency packages though
[19:27] <facubatista> crodriguez, regarding the hook names, it's included what's needed for the pre-dispatch jujus (and the operator framework will take care of the rest)
[19:28] <crodriguez> well if config-changed fails, I run debug-hooks, go into my unit, and want to re-run the hook. But the hook doesn't exist so it is really confusing
[19:29] <facubatista> mmm... maybe the operator framework is not creating them because all works through the dispatch mechanism? (not really using hooks)
[19:29] <facubatista> crodriguez, which juju do you have?
[19:29]  * facubatista brb
[19:30] <crodriguez> 2.8.1-bionic-amd64
[19:37] <facubatista> right, it's using dispatch
[19:37] <facubatista> jam, Chipaca, how do you trigger a "hook" using dispatch?
[19:38] <facubatista> crodriguez, I *think* it's by doing: JUJU_DISPATCH_PATH=hooks/config-changed ./dispatch
[20:20] <crodriguez> why is it not just existing in the /hooks folder like for all the reactive charms? this changes completely the troubleshooting experience
[20:22] <crodriguez> re:templates , could we just add templates in CHARM_OPTIONAL ? https://github.com/canonical/charmcraft/blob/master/charmcraft/commands/build.py#L38 Does this handle folders or only files?
[20:31] <facubatista> crodriguez, yes, if you add templates in CHARM_OPTIONAL it will work
[20:32] <facubatista> the question is what we *really* need... "templates" for sure, but what else?
[20:33] <crodriguez> hum that could be decided by reviewing existing charms
[20:34] <crodriguez> like reactive charms
[20:34] <facubatista> crodriguez, FWIW, we have https://github.com/canonical/charmcraft/issues/39
[20:38] <crodriguez> ok yeah, my bug might be a duplicate then. It would be nice if a decision was taken soon though, because this pretty much prevents me from using charmcraft build rn. I might just do a PR for templates only until that broader question is resolved
[20:47] <facubatista> Chipaca, let's talk about this ↑ in tomorrow's standup, please :)
[21:06]  * facubatista eods


[08:47] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/cleanup-bfjo/+merge/183396
[08:48] <StevenK> wgrant: You say, as I closed my browser
[08:53] <StevenK> wgrant: Would be nice if it didn't kill the entire build farm when deployed, but it's an excellent cleanup
[08:54] <wgrant> StevenK: I've wanted to change the slave cookie for 3 years :)
[08:54] <wgrant> Now is as good a time as any.
[08:55] <StevenK> wgrant: Because it's wrong, broken, just unlikeable?
[08:57] <wgrant> StevenK: It has delusions of relevance to security, contains unnecessary information which complicates the implementation, and its opacity complicates debugging.
[11:09] <cjwatson> wgrant,StevenK: Thoughts on posting http://blog.launchpad.net/?p=4146&preview=true ?
[11:10] <cjwatson> (In particular, anything else that's worth mentioning there?)
[11:10] <cjwatson> It's fairly heavily biased towards the things I've been involved with, I expect
[11:21] <wgrant> cjwatson: Sounds sensible. I think you got most of the concrete improvements.
[11:28] <cjwatson> Thanks.  Published.
[11:28] <cjwatson> (http://blog.launchpad.net/general/launchpad-build-farm-improvements)
[11:29] <wgrant> :)
[12:03] <xnox> \o/ cool stuff =)


[06:50] <xranby_ac100> whats the best way to determine at runtime if my code are running on a armel or armhf system?
[06:51] <xranby_ac100> i find myself in the situation that i have two librarys one armel and one  armhf and i must determine which of the two to open at runtime from a no-c based language
[06:52] <twb> compile an hf binary, if it crashes you're on soft float :P
[06:52] <xranby_ac100> well .. hehe
[06:52] <xranby_ac100> yes i was trying to avoid the crash at library load
[06:53] <twb> IIRC you can have hf and sf processes coeexisting on the same system
[06:53] <twb> Maybe the kernel has to support hf, but that would be all (that and the hardware, obviously)
[06:53] <twb> Hmm, I think I'm running a hf chroot without kernel support...
[06:54] <twb> /proc/cpuinfo isn't helpful
[06:54] <twb> Oh, yes, there's vfp in the feature list, that's hf right?
[06:54] <xranby_ac100> the kernel are identical so i cant ask it
[06:54] <xranby_ac100> vfp can be in the feature list on armel as well
[06:55] <xranby_ac100> its only the userspace abi that are different
[06:55] <twb> Hang on, are you saying that you have only one of the libraries installed on any given system?
[06:55] <xranby_ac100> i have a java application and i have   two native librarys one armel and one armhf
[06:56] <twb> I thought you were saying you had a mix of hardware, some hf and some sf
[06:56] <xranby_ac100> i have to determine at runtime which one to load
[06:56] <xranby_ac100> if i pick the wrong one i crash
[06:56] <xranby_ac100> the java application itself are platform independent and can run unmodified on armhf and armel so i cant figure out this part at compile thime
[06:58] <xranby_ac100> i assume python have similar issues
[06:59] <xranby_ac100> say you got python code that needs to load a native library
[06:59] <xranby_ac100> can gcc produce fat binarys?
[07:00] <twb> I don't know
[07:00] <xranby_ac100> if so then i would be able to load a fat binary with both armel and armhf
[07:38] <sveinse> I'm running natty and lately I'm always forced to run "sudo update-binfmts --enable qemu-arm" when I'm about to run armel code on intel. Is there a change in policy of late regarding this since it's constantly disabled?
[07:55] <twb> sveinse: one moment
[07:56] <twb> http://wiki.debian.org/QemuUserEmulation talks about how to do that
[07:56] <twb> IME it's always on, but I don't think I've tried it under precise...
[07:57] <twb> Pretty sure I was doing it under oneiric without troubles
[08:02] <sveinse> twb, I've been running qemu armel binfmt emulation for a while (years). It's just very lately that I need to run update-binfmts after _every_ boot to enable to execute armel binaries
[08:03] <twb> New one on me
[08:37] <ppisati> ogra_: could you test daily image for panda?
[08:43] <ppisati> janimo`: could you test daily image for panda?
[08:47] <ogra_> ppisati, i think pgraner did already (he asked questions about some desktopish apps in #ubuntu-release)
[08:52] <ppisati> ogra_: i've a problem with my test monitor here, could you double check?
[08:52] <ogra_> well, i'm currently busy with ac100 testing but later today i can probably test panda
[09:34] <ppisati> ok, so it's ether the video output of my board or my lcd...
[10:41] <ppisati> ogra_: not even P/omap4 beta1 gives me any vide output, so i'm realy starting to thing it's problem with my panda or with my lcd...
[10:41] <ppisati> *think
[10:41] <ogra_> did you try the other video output ?
[10:42] <ppisati> yes
[10:42] <ppisati> no output at all
[10:42] <ppisati> i tried with 3 different kernels
[10:42] <ppisati> and two preinstalled images
[10:43] <ppisati> among which the beta1
[10:43] <ppisati> no i'll do a last test with an O image
[10:43] <ppisati> after that i'll declare my panda badly wounded
[10:43] <ashiswin> hey guys, does anyone know which channel I can discuss general ARM processor stuff?
[10:45]  * ogra_ would try #linaro, there are at least a lot of arm employees in there
[10:47] <ashiswin> thanks ogra_ :)
[11:24] <ppisati> no video output even in O
[11:24] <ppisati> nice
[11:25] <ogra_> try another cable :)
[11:25] <ogra_> and power on the monitor ;)
[13:28] <jimerickson> got video ouput on my pandaboard ES with the latest image. thanks guys!
[13:34] <ogra_> great
[13:47] <martinald> hi guys
[13:48] <martinald> playing around with ARM in qemu
[13:48] <martinald> i've got a basic fluxbox install starting
[13:48] <martinald> but i can't seem to find a way to increase the oclour depth and/or resolution
[13:48] <martinald> i'm using the framebuffer driver AFIAK; anyone got any ideas?
[14:25] <Riddell> still getting my monitor/graphics driver issue (bug 961133) but found a new HDMI monitor that it does work with but only with HDMI output and only at 600x800 resolution
[14:26] <ubot2> Launchpad bug 961133 in linux "No video output from Ubuntu Desktop ARM Images on my Pandaboard to my DVI monitor" [Medium,Confirmed] https://launchpad.net/bugs/961133
[14:26]  * Riddell wonders why this channel exists instead of using #ubuntu-devel
[14:52] <hrw> Riddell: question is rather 'why you joined here instead of asking on #ubuntu-devel'
[14:52] <Riddell> hrw: because I think there is a need for arm communications still, that's why I've been arguing for an ubuntu-arm mailing list
[14:56] <hrw> there was ubuntu-mobile for that
[14:56] <hrw> and finally got dropped in favour of ubuntu-devel
[14:57] <Riddell> yes, so it's inconsistent
[15:00] <Riddell> robclark: I'm to nudge you towards bug 961133 again, still broken with my monitor (but worked with oneiric and works with that 3.3 one you showed me at) but works with an HDMI monitor at 640x480 resolution
[15:00] <ubot2> Launchpad bug 961133 in linux "No video output from Ubuntu Desktop ARM Images on my Pandaboard to my DVI monitor" [Medium,Confirmed] https://launchpad.net/bugs/961133
[15:03] <janimo`> Riddell, I think ARM  emails should be good for ubuntu-devel if they are developer oriented. ARM should get more and more widespread so bringing it in the discussions more visibly can't hurt
[15:05] <Riddell> what do I need to test omap (not omap4) images?
[15:05] <GrueMaster> A beaglexm platform.
[15:12] <ogra_> even though it might be funny to see kubuntu oin a beagle C4 or A8 *g*
[15:32] <Riddell> GrueMaster: so that's a beagle board?
[15:32] <Riddell> ogra_: what's funny about that?
[15:33] <GrueMaster> Riddell: http://beagleboard.org
[15:33] <ogra_> Riddell, A has 128M, C has 256M ... both will oops at some point running a full desktop
[15:34] <ogra_> you dont want to test kubuntu on that :)
[15:34] <Riddell> ogra_: so how do you test ubuntu desktop images?
[15:34] <ogra_> oh and they are 400 and 600 MHz
[15:34] <ogra_> Riddell, we use beagle XM, as GrueMaster stated
[15:34] <GrueMaster> Riddell: beagleXM.  See above link.
[15:34] <ogra_> 1GHz/512M
[15:35] <ogra_> any former revisions arent really for desktop use
[15:35] <ogra_> (XM is the "current" one)
[15:36] <Riddell> and while I'm asking what do you use to test mx5 and ac100?
[15:36] <ogra_> ac100 is teated on an ac100 :)
[15:36] <ogra_> mx5 is the freescale quickstart board
[15:36] <GrueMaster> Freescale Quickstart for mx5.
[15:37] <Riddell> and they're dev board that look a bit like this pandaboard?
[15:37] <GrueMaster> Although any you buy now are highly likely to not work due to a usb bug.
[15:37] <ogra_> Riddell, apart from the ac100 they all are dev boards
[15:37] <GrueMaster> yes, very similar in size.
[15:37] <ogra_> (ac100 is the little netbook i run around with at events)
[15:38] <Riddell> ah nice
[15:38] <ogra_> they are not produced anymore but you can get them chap at ebay or so
[15:38] <ogra_> like between 100 and 150€
[15:38] <Riddell> so why do we have images if they're not commercially interesting?
[15:39] <ogra_> because there is a big community for it
[15:39] <Riddell> that's very generous of us :)
[15:39] <ogra_> and the majority uses ubuntu on that device
[15:40] <ogra_> no, thats very helpful for us, the devs among them help with ubuntu on arm since thats a device they actually *use*
[15:40] <ogra_> opposed to a dev board ...
[15:40] <Riddell> ah hah
[15:41] <ogra_> we tend to get a good amount of bugs (and sometimes also fixes) from that side
[15:42] <Riddell> ogra_: where do bugs appear in arm?  linux sure and I know there are compiler errors if you don't do your real vs double right in qt but what are the other gotchas?
[15:42] <ogra_> well, sound servers that down work properly with alsa ... desktop bugs you dont encounter during a short test but that show up after a while of actually using an image etc
[15:43] <ogra_> just do give two examples
[15:43] <Riddell> I guess unity-2d gets more of a workout on arm
[15:43] <Riddell> that name makes me cringe each time I use it
[15:44] <ogra_> well, we're working on 3D for panda at least
[15:45] <ogra_> i should have a patch from linaro readily packaged next week or so for compiz
[15:45] <ogra_> so you can use 3D then
[15:46] <ogra_> but i doubt it will be fun to use ... will still be slow and slightly buggy
[15:46] <ogra_> its a start at least :)
[15:48] <Riddell> I have graphics accelaration on this pandaboard
[15:49] <Riddell> I don't see any need for unity-"3d" just overhead as far as I can tell
[15:49] <ogra_> on oneiric
[15:49] <ogra_> there is no driver for precise yet
[15:49] <Riddell> hmm I have fancy shadows on my windows which I can turn off when I tell kwin not to use accelaration
[15:49] <ogra_> sure
[15:49] <ogra_> SW rendered composite
[15:50] <ogra_> works even on xfbdev drivers ;)
[15:50] <ogra_> especially if the system can donate one core to all the SW stuff
[15:50] <Riddell> mm
[15:50] <ogra_> there are no drivers installed by default
[15:51] <ogra_> for oneiric they are in the TI PPA
[15:51] <ogra_> for precise they sit in NEW and wait for being moved to multiverse
[15:51] <GrueMaster> For precise, I think they are in -proposed, but I know they are at least waiting for beta freeze to lift before hitting the pool.
[15:52] <GrueMaster> Oh, new.
[15:52] <Riddell> -proposed isn't open, we haven't released yet
[15:52] <ogra_> -proposed is open
[15:52] <GrueMaster> I had thought they had enabled proposed for stuff to flow into during the freeze.
[15:52] <ogra_> compiz was built there during the freeze
[15:52] <Riddell> that's early
[15:52] <ogra_> right
[15:53] <ogra_> it is to avoid archive skew through package sets with close dependencies
[15:53] <GrueMaster> Makes sense.  Keep stuff flowing withouth disrupting beta.
[15:53] <ogra_> so they can be uploaded and built and once the freeze is lifted the binaries just get copied
[15:53] <Riddell> clever these archive admins
[15:59] <infinity> Riddell: We're getting more clever, anyway. :P
[16:24] <prpplague> GrueMaster / ogra_ any of you guys heard of anyone running ubuntu-arm over on some of the slower arm920's ? i.e. s3c2440?
[16:25] <ogra_> nope
[16:25] <GrueMaster> We only support armv7 core.  If they support it, our stuff should run.
[16:25] <infinity> Would be a neat trick, since they're not v7.
[16:25] <infinity> And GrueMaster beat me to it.
[16:26] <prpplague> ahh ok
[16:26] <ogra_> i think we had some back in jaunty or karmic though
[16:26] <prpplague> i'll probably look at some angstrom builds them, thanks
[16:26] <infinity> prpplague: Or Debian.
[16:26] <ogra_> ++
[16:29] <infinity> Someone still needs to retroactively rename all of the ARM core designs and ISAs to not confuse people.
[16:30]  * ogra_ votes for "frank" ... or "bill"
[16:30] <infinity> There.
[16:30] <ogra_> heh


[00:46] <Dubaco> https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/988111 do i need to include more details?
[00:46] <ubot2> Launchpad bug 988111 in iptables "bbc iplayer cannot stream for longer than 1 hour in ubuntu but can stream in Windows" [Undecided,New]
[00:48] <Dubaco> anyone know how to report a bug against blutooth not working
[00:50] <dlentz> Dubaco, probably: ubuntu-bug bluez
[01:01] <Dubaco> i tried to run this command "sudo hcidump -XYt > $HOME/hci.log " as part of the bug report it doesnt work as it cant find hcidump
[01:40] <hggdh> Dubaco: sudo apt-get install bluez-hcidump
[01:56] <Daekdroom> Does apport-collect work for a bug report filed against nvidia-graphics-drivers?
[04:13] <nathwill> g'day! if someone has the time, it seems as though the bug 529759 should be marked as "Won't Fix", but I don't have authorization to set this status.
[04:13] <ubot2> Launchpad bug 529759 in gwibber "The reply function is duplicated" [Medium,Incomplete] https://launchpad.net/bugs/529759
[11:59] <trijntje> Hi all, virtualbox just caused a hard reboot on 12.04, what log files should I inspect so find out whats going on?
[12:49] <nik90> seb128, regarding https://bugs.launchpad.net/unity/+bug/988264, I have replied to the bug report
[12:49] <ubot2> Launchpad bug 988264 in unity "Is user account an application or a system management tool?" [Low,Incomplete]
[12:49] <nik90> If you run the applications such as Backup, DateAndTimeSettings using the Dash, they appear in the recent apps section considering that they are applications. However if you use them from the System Settings they do not appear in the recent apps section. But nonetheless, these are considered as applications.
[12:50] <seb128> nik90, I still don't understand your issue on this bug
[12:50] <seb128> nik90, how is "user account" different?
[12:50] <nik90> seb128, as you said when you run datetime from the dash, they appear in the recent apps as they should
[12:51] <nik90> seb128, however if you try running datetime from the system settings they do not appear in the recent apps section
[12:51] <seb128> neither do user account
[12:51] <nik90> seb128, exactly none appear if you run them from the system settings...but is that the desired behaviour?
[12:51] <seb128> yes
[12:51] <nik90> ok...in that case the bug is then invalid
[12:52] <seb128> if you go to system settings, browse the 15 icons, you don't want your dash being flooded with those 15 icons do you?
[12:52] <nik90> true
[12:52] <nik90> I think the user Sandra in the bug report is also not aware of this
[12:52] <seb128> ok, so yes, I would say that's not a bug, I'm not sure what disturbed you to start ;-)
[12:53] <nik90> no, I was not sure about the desired behavior which is why i asked
[12:53] <seb128> I will let the reported a chance to comment before closing though
[12:53] <seb128> nik90, well you can suggest the behaviour should change but the current one seems fine to me
[12:53] <nik90> seb128, I am fine with the current behavior
[12:53] <seb128> if you run a specific system settings from the dash you probably want a record that you ran it from there
[12:53] <nik90> I have one last question
[12:54] <seb128> if you open system settings and browse across all icons you probably don't want that to "spam" the dash
[12:54] <seb128> sure?
[12:54] <nik90> If you click on a launcher icon, the icon blinks to show that it is launching...
[12:54] <nik90> however when you open a link in thunderbird which then open its in firefox, the firefox icon does not pulse to indicate this.
[12:54] <nik90> is this a bug?
[12:56] <seb128> not sure, that seems a design question, I'm not a designer ;-) I think I cross bugs doing similar suggestions though, maybe check the open bugs
[12:56] <nik90> ok
[12:56] <nik90> I'll try to find those
[12:56] <nik90> thnx
[12:56] <ogra_> for me the icon wiggles here if a new page opens in the BG
[12:57] <nik90> ogra_, the icon wiggles only if firefox is already open
[12:57] <nik90> but if firefox is not open, then it should pulse to indicate that the link is being opened in firefox
[12:57] <nik90> which it doesnt
[12:57] <ogra_> ah, yeah, i never have the case that FF isnt open :)
[12:57] <nik90> haha
[12:59] <seb128> nik90, bug #919869 for example
[12:59] <ubot2> Launchpad bug 919869 in unity "launcher does not pulse if a pinned app is started from dash" [Medium,Triaged] https://launchpad.net/bugs/919869
[12:59] <nik90> oh yup that is it...
[13:00] <nik90> It just needs one more case scenario...pulse also does not happen when called from within another application
[13:01] <seb128> nik90, well it's rather "when not started by a click on the launcher icon"
[13:01] <nik90> seb128, yeah I think that should cover all case :)
[13:02] <nik90> I'll update it
[14:09] <somethinginteres> Hi all, got a strange bug happening. All my applications are working etc but searching for them in dash produces nothing. Only shows files.


[03:00] <barry> #startmeeting
[03:00] <MootBot> Meeting started at 21:00. The chair is barry.
[03:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[03:00] <barry> hello and welcome to this week's asiapac reviewer's meeting.  who's here today?
[03:01] <barry> jml, mwhudson, thumper ping
[03:02] <jml> barry: hi!
[03:02] <mwhudson> wow
[03:02] <barry> hi!
[03:02] <barry> mwhudson: yeah ;)
[03:02] <jml> barry: you've caught mwhudson and I in the middle of QA.
[03:02] <jml> barry: but let's do the dance.
[03:02] <barry> jml: i'm sure it'll be short
[03:03] <jml> :)
[03:03] <barry> i have no new agenda items, and nothing that interesting for action items or queue status
[03:03] <barry> so let me just ask you guys how things are going :)
[03:04] <mwhudson> ok i guess
[03:04] <jml> things are going pretty good.
[03:04] <mwhudson> i'm still hardly reviewing any !code branches
[03:04] <jml> one thing that's worth talking about is meeting time.
[03:04] <barry> mwhudson: yeah, do you have any ideas about what we can do about that?
[03:04] <jml> (because DST is hitting us and leaving you)
[03:04] <barry> jml: i'm open to changing the time
[03:04] <jml> barry: you should move to Australia.
[03:05] <barry> jml: we'll see nov 4th
[03:05] <jml> barry: that would solve the !code problem :)
[03:05] <barry> btw, we leave dst on 2-nov
[03:05] <mwhudson> barry: dunno, i'll be overlapping more with the us people as the dst things happen
[03:05] <jml> *nod*
[03:05] <jml> barry: meeting time is whatever is better for you.
[03:06] <jml> barry: it's 3pm in NZ right now and 1pm here, so there's a lot of leeway for an earlier meeting.
[03:06] <mwhudson> so i guess i could/should make sure that i get involved with reviews on, say, thursday mornings
[03:06] <barry> 10pm local time is not too bad, but i haven't worked out what that will be for you after the clock dance
[03:07] <barry> so after 2-nov i'll be utc-5, what will you be?
[03:07] <jml> UTC+11 and UTC+13
[03:07] <mwhudson> same as now
[03:07] <jml> same as now
[03:07]  * jml adds uselessly
[03:07] <barry> lol
[03:08] <barry> so it means that after 2-nov we'll be meeting nz 4pm and jml 2pm? or do i have that backward ;)
[03:08] <mwhudson> that's right
[03:08] <mwhudson> er
[03:08] <mwhudson> no
[03:08] <mwhudson> ah heck, too hard for me
[03:08]  * barry has brain hurty
[03:09] <jml> barry: http://timeanddate.com/worldclock/meetingtime.html?month=11&day=12&year=2008&p1=263&p2=264&p3=240&p4=-1&iv=0
[03:10] <mwhudson> thanks jml :)
[03:10] <barry> jml: yeah, thanks! :)
[03:10] <barry> utc 0300 would probably work for me
[03:10] <mwhudson> fine with me
[03:11] <jml> Fine by me too.
[03:11] <barry> [AGREED] after 2-nov we'll switch to 0300 utc
[03:11] <MootBot> AGREED received:  after 2-nov we'll switch to 0300 utc
[03:12] <barry> mwhudson: let's brainstorm about getting you !code reviews at epic
[03:12]  * jml too
[03:12] <mwhudson> barry: ok
[03:12] <jml> barry: the issue also goes in the other direction.
[03:12] <barry> jml: right, on both oints
[03:12] <barry> points even
[03:13] <jml> cool.
[03:13] <barry> cool.
[03:13] <jml> that's it from me.
[03:13] <barry> mwhudson: anything?
[03:13] <jml> oh, there is an awesome branch that improves the code review ui, but it failed to land for 2.1.10.
[03:14] <barry> jml: :(
[03:14] <jml> keep watching edge though.
[03:14] <barry> jml: that's all i watch :)
[03:14] <jml> :)
[03:14] <barry> my email-any-user branch failed to land (3 times i might add)
[03:14] <jml> :(
[03:14] <mwhudson> my bzr merges kept disappearing!
[03:14] <barry> jml: watch edge! :)
[03:14] <jml> barry: this failure was entirely due to the branch being so big that the conflicts became unmanageable.
[03:15] <mwhudson> (i guess i should chase that with the losas...()
[03:15]  * barry sighs
[03:16] <barry> well, i guess that's it
[03:16] <barry> #endmeeting
[03:16] <MootBot> Meeting finished at 21:16.
[03:16] <jml> barry: cool. thanks.
[03:16] <barry> thanks guys and i'll see you in a few days
[03:16] <jml> barry: I look forward to it :)
[03:16] <barry> mao!
[03:16] <mwhudson> see you soon!
[03:17] <jml> I had forgotten about mao
[03:27] <thumper> crap
[03:27] <thumper> DST
[03:36] <mwhudson> hi thumper


[07:40] <reisei> hello! I have strange issue: on shutdown, after unmounting devices I got this messages, that repeats in cycle: http://pastebin.com/fLM84Y2G Can you advice me, what's wrong with my configuration?
[08:13] <apw> reisei, that is a device which has not been shutdown correctly by the looks of it, i assume this is an arm device
[08:16] <apw> dupondje, as it doesn't seem to be in stable as far as i can tell you'd need to file a bug to track it
[08:18] <smb> mornings
[08:18] <apw> smb, moin
[08:21] <reisei> apw: yep, you're right.
[08:21] <ppisati> moin
[08:21] <dupondje> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/946928
[08:21] <ubot2`> Launchpad bug 946928 in linux "sysfs: can not remove 'bsg', no directory" [Undecided,New]
[08:22] <apw> ppisati, seen anything with arm boards not halting right, with errors from interrupts after 'System halted.' ?
[08:22] <reisei> apw: ppisati MUSB if off, btw
[08:23] <ppisati> nothing lately
[08:23] <ppisati> reisei: which board?
[08:24] <reisei> ppisati: variscite
[08:24] <apw> dupondje, what did you do to trigger this, i'd be supprised if anyone hit it
[08:25] <ppisati> reisei: variscite? omap3? omap4?
[08:26] <dupondje> Mar  4 23:08:39 laptop-jl kernel: [19951.765869] sd 17:0:0:0: [sdb] Attached SCSI disk
[08:26] <dupondje> this was just before ...
[08:26] <dupondje> hit it 2 times even yesterday :p
[08:27] <reisei> ppisati: omap4460
[08:27] <ppisati> reisei: kernel version?
[08:27] <apw> dupondje, attaching and detaching external USB disks ?
[08:27] <dupondje> apw: yea seems so
[08:28] <dupondje> it doesn't break anything anyway
[08:28] <dupondje> but less spam in console is always good :D
[08:29] <reisei> ppisati: 3.1
[08:29] <ppisati> reisei: wow, 4460 on pci module? http://www.variscite.com/products/item/76-var-som-om44-ti-omap4460
[08:29] <dupondje> anyway gtg now
[08:30] <dupondje> and its raining like hell :(
[08:31] <ppisati> reisei: btw 3.1 didn't have all the necessary bits to support 4460
[08:31] <reisei> ppisati: yep.
[08:31] <ppisati> reisei: 3.1 vanilla or linaro? and, in case of linaro, which tree?
[08:31] <reisei> ppisati: what do you mean by bits?
[08:31] <ppisati> reisei: i mean support for freq scaling and dvfs
[08:32] <ppisati> reisei: without these, the cpu overheats quickly
[08:32] <reisei> ppisati: linaro, but it's somehow fixed by developer of that module
[08:32] <ppisati> reisei: if it's the 3.1 tilt tree, then you should be ok
[08:32] <reisei> ppisati: how can I check it?
[08:32] <ppisati> try booting a 4460 panda board
[08:33] <ppisati> with that kernel
[08:33]  * apw bounces for a new kernel ...
[08:33] <apw> wish me luck
[08:33]  * smb already got that
[08:34] <ppisati> i updated yesterday my laptop and it was ok, except for a garbled lightdm
[08:35] <smb> Have not noticed that here, but maybe there was a change in today changing that
[08:35] <ppisati> smb: well, i'm on unity2d so could be a 2donly issue
[08:35] <smb> ppisati, Is lightdm not always 2d?
[08:35] <reisei> ppisati: I don't have an 4460 panda, just an old one :-)
[08:36] <ppisati> smb: uhmm... good point... actually i get the garbled screen after i logged in but before the desktop is all setup
[08:37] <ppisati> reisei: uhmmm.. our kernels are tailored toward a set of boards, could be that you have to tweak some settings
[08:37] <ppisati> reisei: do you always get this panic?
[08:37] <ppisati> reisei: do you have a screenshot?
[08:37]  * ppisati -> coffee++
[08:38] <smb> ah... think that sounds like have that for as far as I can remember (more or less) with nvidia or ati
[08:38] <reisei> ppisati: Reboot goes well. Only on halt. I have dmesg log: http://pastebin.com/fLM84Y2G
[08:45] <ppisati> reisei: it seems it's a known issue -<EMAIL_ADDRESS>[08:45] <ppisati> reisei: you should look for any changes in that driver within latest linus. rmk or omap tree
[08:45] <ppisati> reisei: or simply ask agreen since he mantains that tree and maybe he already faced that problem
[08:46] <apw> BAH just had a graphics lockup, the old hang when pulling the launcher out of the side
[08:55] <reisei> ppisati: ok, thank you!
[10:27]  * smb wonders whether <super>+<alt>+<cursor> stopped moving the window in focus for other people too (ctrl+alt+shit+cursor right now... wonder was it really that before changing it to something involving super?)
[10:32] <brendand> smb - same here. unity help says super+alt is the correct one
[10:32] <brendand> smb - when i try that it does something in xchat, but not to the window
[10:33] <pkh> i've just upgraded to the beta and the kernel doesn't appear to support dmraid out of the box -- is this a bug or did I miss something out in the upgrade?
[10:33] <pkh> i'm back and running with the kernel from before the upgrade fine, but thought I shoudl report it anyway.
[10:34] <smb> Well I remember that there was someone saying they would do yomething about those keys (either change shift+super to something not hurting or completely revert). Just not sure whether it really was a three finger press before...
[10:36] <smb> pkh, Hm, I thought I did an upgrade test with a dmraid setup and it worked. But yes, please report it (if possible with dmesg from the failure and for comparision from before)
[10:36] <pkh> k, will do -- report where though?
[10:37] <smb> pkh, Launchpad bug report.
[10:37] <pkh> k, will get on it.
[10:37] <smb> ubuntu-bug linux  (or dmraid) one of those we can change it later
[10:37] <smb> pkh, ^
[10:39] <pkh> ah, just relised that i don't think i'll be able to get a dmesg -- root is on dmraid, with new kernel I get left with that limited shell.
[10:40] <apw> pkh, you might be able to mount a usb stick within it
[10:40] <pkh> k, will ahve a play tonight and send whatever I can get hold of thought
[12:15]  * ppisati -> out for lunch
[14:02]  * tgardner reboots tangerine for kernel upgrade...
[14:13]  * smb just checked dmraid with the latest kernel and it still seems to work (at least for non-root usage)...
[14:20] <brendand> if an sd card reader is connected on the scsi bus, is there any way to tell that it's an sd card reader?
[14:22]  * cking --> back in 25-30 mins
[14:37] <htorque> hello everyone! would any kernel hacker with working systemtap be so nice and run the following as a user (user must be in groups 'stapdev' and 'stapusr'):
[14:37] <htorque> stap -e 'probe vfs.read {printf("read performed\n"); exit()}'
[14:38] <htorque> this fails for me on ubuntu and works on fedora, and i'd like to know if others see this too.
[15:03] <tgardner> ogasawara, ppisati, apw: Precise arm* chroots on gomeisa are borken, so use tangerine. its something to do with qemu.
[15:03] <ogasawara> tgardner: ack
[15:05] <ogasawara> how is it I just learned I can cherry-pick a range of commits now
[15:08] <ppisati> cool, latest kernel hangs on omap3
[15:09] <tgardner> ogasawara, is that something new with the latest git ?
[15:09] <ogasawara> tgardner: I think so.  it's awesome.  now if only I could do an interactive cherry-pick...
[15:10] <ppisati> tgardner: afaik arm precise chroot have always been broekn due to a qemu bug
[15:10] <ppisati> tgardner: they never worked
[15:10] <tgardner> ogasawara, can you filter based on a directory or file ? e.g., git log prettyprint=online -- fs/ecryptfs
[15:11] <tgardner> ppisati, its a host issue. works fine on tangerine (which is precise).
[15:11] <ppisati> tgardner: ok
[15:11] <ogasawara> tgardner: yep
[15:12] <tgardner> ogasawara, so, something of the form 'git cherry-pick v3.2..HEAD -- fs/ecryptfs' ?
[15:13] <ogasawara> tgardner: hrm, dunno about that.  /me tests
[15:17] <ogasawara> tgardner: yep, that works
[15:17] <tgardner> ogasawara, cool, stands to reason.
[15:18] <tgardner> ogasawara, hmm, I wonder what it does about merge commits ?
[15:19] <ogasawara> tgardner: I assume it'll vomit some type of conflict that'll need resolved
[15:19] <tgardner> prolly
[15:20] <ogasawara> tgardner: but for the most part, it's much easier to sync patches from P to Q now
[15:20] <tgardner> yep, I can imagine
[15:21] <tgardner> ogasawara, I assume you noticed I rebased sometime over the weekend ?
[15:21] <ogasawara> tgardner: I did, thanks.
[15:21] <cking> tgardner, my last ecryptfs patches probably need the SOB and buglink popped in to the patch before applying it to Natty - my fail to pop them in
[15:21] <tgardner> ogasawara, I've been running it on one of my problematic wifi laptops. it seems to work pretty well..
[15:22] <tgardner> cking, already taken care of
[15:22] <cking> ta
[15:22]  * cking will try to do it right next time..
[15:22] <tgardner> cking, I figured its best not to annoy you with minutiae
[15:23] <cking> :-)
[15:23]  * smb had been assuming tgardner would do so, too
[15:23] <tgardner> cking, besides, I have the magic bjf/herton script that will munge any patch with aplomb.
[15:24] <cking> ah, nice one
[15:24] <tgardner> cking, kteam-tools/maintscripts/maint-modify-patch
[15:27] <tyhicks> cking: Judging by all the eCryptfs-related SRU work you've done on the kernel-team mailing list recently, me slapping on the 'Cc<EMAIL_ADDRESS>tag isn't cutting it.
[15:27] <tyhicks> cking: What can I do differently to help make sure these types of patches don't get lost?
[15:28] <tgardner> tyhicks, some of these went onto Natty which is no longer a supported stable kernel.
[15:28] <cking> tyhicks, I suspect that if they don't apply cleanly then don't land in stable
[15:28] <tyhicks> cking: Right, but gregkh's scripts automatically alert me that something marked for stable didn't apply. I've only ignored 1 of those emails and that was a year or 2 ago.
[15:28] <cking> and as tgardner said, for the Natty these need some love and attention
[15:29] <tyhicks> So when I feel something is important enough to mark it for stable, should I also send it to the kernel-team ML after Linus takes it in?
[15:29] <tgardner> tyhicks, that couldn't hurt
[15:30] <tyhicks> tgardner: Sounds good - that is trivial for me to do
[15:33] <cking> tyhicks, fortunately the list of outstanding patches for me to test and SRU is quite small now
[15:34] <tyhicks> cking: Great! Thanks for all of the work you've done on that!
[15:34] <cking> np
[15:35] <tyhicks> cking: Hopefully I can change my workflow up a little where backports for certain releases don't get lost in the shuffle
[15:35]  * cking nods
[15:36] <tyhicks> (going forward)
[15:38] <brendand> herton, bjf - we're trying to get the oneiric SRU done asap. could be tomorrow or maybe wednesday though
[15:39] <bjf> brendand: huh
[15:45] <brendand> bjf, last week was supposed to be the regression testing week. we're a little behind due to a few recent issues with our test systems
[15:58]  * ogasawara back in 20
[15:58]  * apw dispairs at the total inequality of computation on gomisa ... how can i have 1/5th of the build threads that leann does and yet get 1% of the forward progress
[15:59] <apw> why do her threads get priority
[15:59] <ogasawara> apw: they love me more :)
[16:02] <smb> bjf, I wonder whether you are currently more successful in getting cobbler to update images. Whenever I run cobbler-ubuntu-import it obscurely fails and leaves a tmp-* distro around (upgraded to precise)
[16:04] <bjf> smb, i'll send you my runes
[16:06] <smb> bjf, Thanks. But beside that, is that a known breakage? IOW do they (server-team) know about it if yes?
[16:09] <apw> ogasawara, i have been thinking about it and monitoring your builds and i cannot fathom it
[16:09] <apw> ogasawara, i am starting to believe your priority is based on len(username) its about the only thing that makes sense to me
[16:11] <apw> cking, how is your build progressing ?
[16:11] <apw> cking, will you tell me when it completes
[16:11] <cking> apw, like ogasawara has 90% of the cycles and I'm left with the crumbs
[16:12] <cking> scheduler has US <-> UK biasing controls?!
[16:12] <apw> len(ogasawara) > len(cking)
[16:12] <cking> len(cking) > len(apw) WIN
[16:13] <Sarvatt> there's always tangerine, but it builds kernels 3-4x slower than gomeisa does after it got upgraded to precise :)
[16:14] <ohsix> any one reason?
[16:14] <cking> all the cycles are being used by the HUD
[16:14] <Sarvatt> it used to take 11 minutes vs gomeisa's 9 when it was on lucid, now that its on precise its 31 minutes
[16:15] <apw> Sarvatt, that is positivly awsome ...
[16:15] <apw> tgardner, do we still have a .32 kernel avail on tangerine ?
[16:15] <cking> any physical changes on that box?
[16:16] <apw> ogasawara, are your builds done ?
[16:16] <Sarvatt> i noticed it first being slow on jan 20th but i hadn't built a kernel since december before that, tgardner said it was upgraded to precise in budapest
[16:16] <tgardner> apw, its a precise user space
[16:18] <ogasawara> apw: yep, they finished while I was away
[16:19] <apw> ogasawara, perplexing your entire builds fitted into the last 1/3rd of mine, which took enormously longer than normal
[16:19] <apw> i cannot fathom what the hell is wrong with the scheduling
[16:20] <ogasawara> apw: something is definitely amiss as I seem to always get priority, even when you've already been building ahead of me
[16:20] <apw> tgardner, indeed, and was thinking perhaps a .32 kernel might let us see who is to blame for the performance loss Sarvatt is reporting
[16:21] <apw> ogasawara, you use a higher concurrency for sure, but i don't seem to get a proportionate slice, and that i cannot figure
[16:21] <ohsix> Sarvatt: i'd be interested in the cause of the slowdown if you find out; they did some io stuff that was supposed to alleviate a lot of suck from .32-3.2
[16:24] <tgardner> apw, otp
[17:02] <slangasek> herton: kees has uploaded your patch to udev for DM_COOKIE handling, after we discussed it yesterday at the global jam - thanks for the patch :)  Have you sent it to udev upstream?
[17:03] <herton> slangasek, cool. Not sent upstream already, will take a look
[17:03] <herton> s/already/yet/
[17:04] <kees> it'd need to go with the timeout patch too
[17:05] <herton> hmm indeed. apw, did you try to send the timeout patch, I think we would need to send both
[17:05] <kees> apw: looks like while viro says i_uid should be valid, I think calling vfs_stat is the right fix for yama. I'll send a patch
[17:06] <apw> herton, i did try, they said the kernel should not do that (emit events in the middle of handling one from udev) and they wen't going to take it
[17:07] <apw> kees, if i_uid is meant to be valid (and i agree that is what al says) then why is what you are doing wrong as it is?
[17:07] <herton> ok, so probably they will reject the DM_COOKIE patch also...
[17:08] <herton> which depends on the timely patch
[17:08] <apw> herton, i would expect them to, but trying to send it again (both indeed together if that makes sense) may not be pointless
[17:08] <kees> apw: seemed easier than trying to plumb the logic into overlayfs, especially in the face of it maybe being a problem with other filesystems in the future.
[17:48] <htorque> hi all! anyone here using systemtap?
[17:53] <apw> kees, and the cost of calling stat there?
[17:57] <cking> htorque, I tested systemtap on Precise with some kernel stap scripts last week
[17:57] <tgardner> ogasawara, pushed a patch to ubuntu-precise-meta. please give it a quick looksee.
[17:57] <ogasawara> tgardner: ack
[17:58] <tgardner> smb, does VNC console access to a Xen VM require X components ?
[17:58] <htorque> cking: you don't have it currently running i guess? i can't seem to get it to work as unprivileged user and wanted to know if it's just my setup or if it fails for other ubuntu users too (as the same steps work on fedora)
[17:58] <tgardner> bug #944582 argues that xen-kbdfront should be included  in the virtual flavour
[17:59] <ubot2`> Launchpad bug 944582 in linux-meta "xen-kbdfront module should be provided by linux-image-virtual or linux-virtual" [Undecided,New] https://launchpad.net/bugs/944582
[17:59] <htorque> like running this as user (which must be in groups 'stapusr' and 'stapdev'): stap -e 'probe vfs.read {printf("read performed\n"); exit()}'
[17:59] <tgardner> cking, is there a yama switch that you have to flip ?
[17:59] <cking> htorque, I always run it using sudo
[18:00] <htorque> cking: that's working here too
[18:00] <smb> tgardner, On the guest I don't think so. The host, not sure, I did not by itself install things but never checked
[18:01] <smb> tgardner, the kbdfront would likely be good for console... I'll look at it
[18:01] <tgardner> smb, can you offer your opinion in the bug?
[18:01] <cking> htorque, I need to load the .ddebs for /me to try it out, let me find a box where I can test this..
[18:03] <smb> tgardner, Right, we should put that into the main package. Not sure why it is in extras...
[18:03] <htorque> cking: that would be great (if it's no trouble to you).
[18:04] <cking> it will take me a little while to set up (my ISP is rate throttling me at the mo)..
[18:04] <tgardner> smb, ok, will do
[18:05] <htorque> cking: yeah, downloading the 650 mb is no joy. :-(
[18:05]  * cking nods
[18:05] <smb> tgardner, Ah ok, would have send out a patch to change it otherwise
[18:05] <tgardner> smb, its precise, I'll just do it.
[18:05] <smb> tgardner, ack
[18:07] <smb> tgardner, Either you were so quick or its already there but in the wrong place
[18:08] <tgardner> smb, haven't done anything yet....
[18:08] <kees> apw: that's the concern -- it's a bit expensive. semi-related -- why add the yama_permissions() function instead of using vfs_permissions()?
[18:08] <apw> i am not adding yama_permissions ?
[18:08] <apw> kees, ^^
[18:10] <apw> kees, this is coming from someone doing a touch 1; chmod 444 1; ln 1 2 ... within an overlayfs and yama barfing ... its std higher level permissions
[18:13] <smb> tgardner, I did a quick package check, it seems its there in precise but not in oneiric
[18:20] <tgardner> smb, the path is wrong in oneiric. I'll send an SRU patch
[18:20] <smb> tgardner, Bah, seems a type hit us. I sent a quickly whipped up patch to mailing list
[18:21] <smb> tgardner, Nearly the same time
[18:21] <smb> :)
[18:21] <smb> tgardner, But yes, seems in Precise it is correct but it is wrong for Oneiric
[18:22] <tgardner> smb, go ahead and send yours. I'll work on the meta package description updates
[18:22] <smb> tgardner, Just hit the list
[18:24] <kees> apw: the yama_permissions call from last year is what I mean -- why create that instead of using vfs_permissions ?
[18:26]  * apw can't even find vfs_permissions now, let alone then <-- kees
[18:26]  * kees goes looking
[18:28] <kees> apw: ah! sorry -- inode_permission
[18:29] <apw> that does a lot more than you already did, an i wasn converting 'generic_permission()' to somethign correct in the face of a permissions op
[18:30] <kees> what about do_inode_permission()? that's nearly identical.
[18:30] <apw> i worry slightly that you are in a LSM op, and you call that you are calling security_inode_permission
[18:30] <kees> do_inode_permission avoids that, but is static.
[18:30] <apw> do_inode_permission is definatly what it means, but as you say not exported
[18:30] <apw> i think i'd refer back to you and ask what did you mean to check what permissions
[18:30] <kees> okay, so I'll leave yama as-is, and for Q, we can remove the yama link restrictions in favor of upstream
[18:31] <apw> as its always possible inode_permission is right
[18:31]  * apw makes a note that overlayfs should be using it too
[18:31] <apw> bah
[18:31] <kees> it was unrelated to the overlayfs issue -- It was just a question I'd been meaning to ask you from when I converted the Yama link restrictions to the upstream VFS layer link restrictions
[18:32] <apw> yeah an it is an unrelated note to self
[18:32] <apw> that i adeded half that routine to overlayfs, and possibly i should using it
[19:18] <apw> with a minor success under his belt, and having not figured out why everyeone gets prio i am giving up ... till tommorrow
[20:03] <cking> htorque, I suspect you may need to configure systemtap-server to get it working w/o root privilege, but I'm darned if I can get it working at the moment, I'll give it a another try tomorrow
[20:24] <dupondje> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/946928 , 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3 is the commit id in upstream? http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3
[20:24] <ubot2`> Launchpad bug 946928 in linux "sysfs: can not remove 'bsg', no directory" [Medium,Triaged]
[20:25] <jsalisbury> dupondje, yes, it appears to be in the linux-stable tree.  You should see it if you run the following in the linux-stable src tree:
[20:25] <jsalisbury> git show 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3
[20:26] <jsalisbury> dupondje, that commit is also in Precise.
[20:27] <dupondje> lets see
[20:31] <dupondje> jsalisbury: the commit is not there in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=tree;hb=HEAD
[20:35] <jsalisbury> dupondje, hmm, interesting.  The commit is reported with git log, but it looks like the following is indeed not it ~block/bsg.c:
[20:35] <jsalisbury> -       sysfs_remove_link(&q->kobj, "bsg");
[20:35] <jsalisbury> +       if (q->kobj.sd)
[20:35] <jsalisbury> +               sysfs_remove_link(&q->kobj, "bsg");
[20:35] <jsalisbury> dupondje, I'll do some further research and update the bug.
[20:35] <tgardner> jsalisbury, you need to use --contains, e.g., 'git describe --contains 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3'
[20:38] <jsalisbury> tgardner, ahh, that makes sense.  So that means the patch is in v3.3-rc4, but not in linux-stable.
[20:38] <tgardner> jsalisbury, correct
[20:38] <jsalisbury> tgardner, I wasn't aware the linux-stable tree would have commits for the mainline tree.
[20:39] <tgardner> jsalisbury, well, of course it would. for example, 3.2 stable has all of the mainline commits up through v3.2. everything on top of that would be stable commits with a different SHA1
[20:40] <dupondje> just cherry pick it :)
[20:40] <tgardner> dupondje, already done
[20:41] <dupondje> great
[20:42] <jsalisbury> tgardner, So any commit to the mainline tree will automatically show up in a 'git log' run against the linux-stable tree, even if it isn't applied to linux-stable yet?  And when the commit is applied, it gets a new SHA-1?
[20:43] <dupondje> tgardner: jsalisbury: changed bug to Fix Commited! thx
[20:43] <jsalisbury> dupondje, thanks
[20:44] <jsalisbury> tgardner, hmm, ok.  I can see all the tags up to v3.3-rc6 in the linux-stable tree.
[20:44] <tgardner> jsalisbury, its relative to the branch that its on, and perhaps how you've populated your repo. for example, if you've ever done a 'git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master', then you'll have _all_ of mainline regardless if the object is in a branch.
[20:45] <tgardner> jsalisbury, its likely thats what greg k-h has done
[20:45] <jsalisbury> tgardner, ok, I understand now.
[20:48] <tgardner> dupondje, don't put URLs to gitdiff in a bug because the SHA1s are not immutable until the final kernel freeze before release.
[20:49] <dupondje> oh didn't know
[20:49] <dupondje> anyway :)
[20:55] <jsalisbury> tgardner, Unless I'm searching wrong, I looks like the commit is not in 3.2.8, but it is in 3.2.9
[20:55] <jsalisbury> tgardner, I run this command under both branches:
[20:55] <jsalisbury> git log --pretty=oneline | grep 'bsg: fix sysfs link remove warning'
[20:55] <htorque> cking: thanks, that's the only thing left for me to try. it's working under fedora though.
[20:55] <jsalisbury> tgardner, but I only see the commit when on the 3.2.9 branch.
[20:56] <cking> htorque, I suspect it is some user space foo config that we're missing
[20:57] <smoser> smb, ping
[20:58] <htorque> cking: would just be nice to know that foo and document it somewhere (ideally at both wikis). especially with user-space probing you want to be able to run stuff as normal user.
[20:59] <tgardner> jsalisbury, you're looking at linux-3.2.y ? I'm not seeing it there.
[20:59] <cking> htorque, i agree
[21:00] <jsalisbury> tgardner, Yes, my .git/config file points to:  url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[21:00] <htorque> anyways, thanks again for trying. :-)
[21:00] <jsalisbury> tgardner, maybe I'll blow it away and re-clone it.
[21:00] <cking> htorque, I can't promise I can figure it out immediately, the workaround is run it with sudo for the moment I suppose
[21:00] <tgardner> jsalisbury, there are a number of branches in that repo. make sure you have 'git checkout -f linux-3.2.y'
[21:01] <jsalisbury> tgardner, ahh, maybe that's what I'm doing wrong.  I was getting the branches with git checkout v3.2.8 and git checkout v3.2.9
[21:01] <htorque> cking: sure, no need to promise anything. it's good enough to know that it's no 'layer 8' issue for now. ;-)
[21:02] <tgardner> jsalisbury, if you don't already have that branch, then 'git checkout -b linux-3.2.y remotes/origin/linux-3.2.y'
[21:02] <jsalisbury> tgardner, not with the linux- prefix
[21:03] <jsalisbury> tgardner, do you happen to know the difference between the v3.2.8 and linux-3.2.y tags?
[21:04] <jsalisbury> tgardner, where v3.2.8 can be v3.2.N
[21:04] <tgardner> jsalisbury, linux-3.2.y is a branch in which the tag v3.2.8 exists
[21:04] <jsalisbury> tgardner, doh, right.
[21:05] <jsalisbury> tgardner, so I was looking at the v3.2.9 tag in the master branch or linux-stable.
[21:05] <tgardner> jsalisbury, yep
[21:06] <jsalisbury> s/or/of/
[21:07] <jsalisbury> tgardner, And the master branch in linux-stable contains the mainline commits as well?  That's why I was seeing that commit.
[21:08] <tgardner> jsalisbury, yes, it probably _is_ Linus' master branch. I haven't looked too close.
[21:08] <jsalisbury> tgardner, thanks for the help.  I think I have my head on straight now :-)
[21:08]  * jsalisbury plans on studying all the branchs and trees closer.
[21:09] <tgardner> jsalisbury, do a 'git branch -a' to see all of the remote branches in the linux-stable repository
[21:09] <jsalisbury> tgardner, perfect, thanks!
[21:13] <jsalisbury> tgardner, The linux-stable repository is making much more sense now.  Thanks for all the info.
[21:13] <tgardner> jsalisbury, anytime
[21:13]  * jsalisbury owes tgardner one more beer :-)
[21:15] <cking> mmm. beer
[21:19]  * tgardner thinks it good to have beer favors
[21:53]  * tgardner -> EOD
[23:29] <GrueMaster> sconklin: Are you online?  Questions on this power amp meter.
[23:31] <sconklin> GrueMaster: I'm just barely still here, what's up?
[23:31] <GrueMaster> I am failing in my attempts to get meaningful power from this atx harness.
[23:32] <GrueMaster> I can get decent readings from a Via ITX board, but not on this arm board.  I have vamp'd into the 3.3v, 5v, and 12v power lines.
[23:33] <sconklin> Do you get any readings at all? Are they all pretty high and don't show variation when the load changes?
[23:33] <GrueMaster> The other issues is the closest I have to an electronics store is Ace Hardware, so connectors are hard to come by.
[23:33] <sconklin> (high is a relative term)
[23:33] <GrueMaster> The best reading I have seen is on 5v, but it is ~0.0000045 amps when booting.
[23:34] <GrueMaster> For reference, a panda is drawing 1.5 amps.
[23:34] <sconklin> when you are cutting into the power supply lines to measure current, are you sure you're cutting all the other lines with the same voltage?
[23:34] <sconklin> You have to get it down to one supply wire and measure that
[23:35] <GrueMaster> Yes.  All Orange (for example) are cut, and each group is twisted together and crimped into a connector, female on one side, male on the other.
[23:35] <GrueMaster> I knew that.
[23:36] <sconklin> I figured you did, but the symptom of very low current measurement is consistent with not having all the supply lines cut
[23:36] <GrueMaster> Only wires left are common (black), +3.3v Sense, Power on, and power good.
[23:37] <GrueMaster> I'm going by http://en.wikipedia.org/wiki/ATX#Power_connection_to_the_motherboard
[23:37] <GrueMaster> Using the 20/24 pin connector for reference.
[23:37] <sconklin> what's the board? It's possible that the current draw is really low if you're booting from flash compared with something else, for example
[23:38] <GrueMaster> For this initial test, Marvell Dove (from pre-Maverick).
[23:38] <GrueMaster> But even my beagle (omap3) draws 0.5 amps on power-up.
[23:39] <sconklin> yeah I would expect something like that. microamps is not in the ballpark
[23:39] <GrueMaster> The Marvell board is about the size of a full atx board.
[23:39] <GrueMaster> The kill-a-watt on the other side of the PS is showing more amps than that.
[23:40] <GrueMaster> Even given power drain.
[23:40] <GrueMaster> I have also used a power supply tester to check amp loads.
[23:40] <sconklin> I suppose it's possible that the meter fuse is blown for current measurement
[23:41] <sconklin> have you moved it back to another board that gives a sane reading?
[23:41] <GrueMaster> Yes.  Both Panda and Via ITX boards give sane readings.
[23:42] <GrueMaster> Of course, after my last test, half the wires came out of their crimp connectors so I have to redo that.  PITA.
[23:42] <sconklin> and the board uses 12V and 5V and 3.3V lines? and you're measuring the 5V line?
[23:42] <GrueMaster> I have measured all three lines.
[23:43] <GrueMaster> 5v is the only one that actually registered with the meter.
[23:44] <GrueMaster> The only other thing I can think of is that the board is drawing from what ever power seems better.  But there aren't enough electronics on the board to do in-line voltage regulating.
[23:44] <sconklin> I don't know what to tell you. The meter is working, because you tested it against another board
[23:45] <GrueMaster> Yes, and it works well on other boards.
[23:45] <sconklin> Inserting the meter shouldn't cause any changes in where it takes power from, so nothing should change
[23:45] <GrueMaster> Very frustrating.
[23:45] <sconklin> and it boots and runs, right (I have to ask)
[23:46] <GrueMaster> I'm going to rebuild the harness with the connectors soldered in so they don't fall apart.  Then I will try powering with them all unplugged to see if the board is drawing power via osmosis or something.
[23:46] <sconklin> You could try opening the return line (black), and that will measure the return current for all the supply voltages. But that's a lot of wires.
[23:47] <GrueMaster> Yes, I am monitoring it via serial console every time.
[23:47] <sconklin> you've invented free energy.
[23:48] <GrueMaster> I thought of chopping black, but I am limited by what I have available.  There are 8 black wires, and I have no easy way to put a connector in between.  I don't want to fry anything (even though I am using a board we don't care about).
[23:50] <GrueMaster> I'll rebuild the cable and go forward.  I might have missed a power line, but not one of the main ones.  I'm positive about that.
[23:50] <sconklin> ack, let me know
[23:50] <GrueMaster> If this doesn't work, tomorrow I make a day trip to Fry's.


[17:36] <krishnan> i would like to contribute to the ubuntu documentation
[17:37] <krishnan> i would like to contribute to the ubuntu documentation. please tell me how can i proceed?