[07:50]  * apw grumbles about waking up too early
[08:21]  * smb couldn't be bothered before
[08:22] <eagles0513875> hey guys
[08:22] <eagles0513875> morning apw
[08:24] <apw> mornig
[08:26] <eagles0513875> how goes it
[08:27] <apw> busy as always
[08:35] <smb> apw, So compat_vdso is only i386 and is said only to be needed with old (<2.3.3 glibc) which is ok in hardy (2.7.x). Normal boot in a vm looks ok and the testcases then pass. Just want to start up one instance to be even more convinced.
[08:35] <apw> smb, sounds good, perhaps we can get one of the buildd peeps to test one
[08:36] <apw> really when we push a hardy kernel into -proposed that should happen every time
[08:36] <smb> apw, Questrion is whether they run anything i386
[08:37] <apw> probabally not, but worth asking, if not then we really are off the worry pile
[08:37] <smb> Right, seeing it depends on libc, the version being ok, being able to boot already got me off it quite a bit
[08:38] <smb> Just for completeness I will do a domU and push that kernel to ec2. If that all works I just push out the change for review
[09:04] <apw> smb, sounds good to me
[09:41] <apw> cking, moin
[09:45] <cking> apw, hiya
[09:47] <eagles0513875> apw: has the 2.6.38-9 natty kernel been rolled out as an update yet
[09:58] <Tommeh> eagles0513875: it's been superceded
[09:58] <eagles0513875> on natty O_O by what though
[09:58] <Tommeh> 2.6.38-10-generic
[09:58] <eagles0513875> for natty or for the next release
[09:58] <Tommeh> I'm still on Natty
[09:59] <Tommeh> I might have proposed enabled...
[09:59] <RAOF> I suspect eagles0513875 means <IP_ADDRESS>, rather than 2.6.38-9?
[09:59] <Tommeh> Ah, my mistake, if so
[09:59] <eagles0513875> ya thats what i meant sry
[10:00] <apw> eagles0513875, no -9 had regressions and was replaced with -10
[10:00] <Tommeh> Though, <IP_ADDRESS> is the latest 'stable' as per lkml...
[10:01] <Tommeh> And twitter.com/gregkh
[10:01] <alex3f> hi, experiencing g #397096 in up-to-date natty, does anyone know something about it?
[10:01] <Tommeh> "#Linux <IP_ADDRESS> kernel released. Last 2.6.38 kernel, it is now end-of-life, move to .39-stable."
[10:03] <eagles0513875> apw: how come my netbook then in the ppa that had 9 in it is still on 9 and has not been upgraded
[10:03] <apw> eagles0513875, which ppa are you using
[10:04] <eagles0513875> apw: let me look it was the one you gave me when i was having atheros wifi issues
[10:04] <eagles0513875> pre-proposed apw
[10:06] <apw> eagles0513875, no idea why you haven't got an update unless you don't also have -proposed enabled
[10:06] <apw> as the version in the pre-proposed ppa is
[10:06] <apw> linux - 2.6.38-10.44pre201106070902
[10:06] <eagles0513875> let me cfheck
[10:07] <eagles0513875> apw: proposed would be pre-released-updates in software sources
[10:08] <eagles0513875> now i got it apw :D
[11:29] <eagles0513875> apw: im upgrading my netbook to the ocelot lol
[11:30] <apw> eagles0513875, good luck with that!
[11:33] <eagles0513875> hows it looking so far
[11:33] <apw> eagles0513875, not really running anything other than the kernel myself
[11:33] <ogra_> shaky :)
[11:35] <eagles0513875> great thank god i have nothing on this netbook lol
[11:35] <eagles0513875> if a reinstall is in order so be it
[11:41] <ogra_> not *that* shaky :)
[11:42]  * ppisati -> out to get some stuff
[11:44] <cking> apw, how long does it take to build a debug kernel package - it's taking forever in dpkg
[11:44] <apw> 15mins or so
[11:45] <apw> on tangerine
[11:45] <cking> owchy ouch ouch ouch
[11:45] <apw> unless you _need_ them you can turn them off
[11:45] <cking> I _need_ it - otherwise I would not be needlessly burning CPU cycles :-(
[11:45] <cking> why is it *so* slow?
[11:45] <apw> then, forever yes, its .5GB and dpkg has to compress it
[11:46] <cking> ah
[11:46] <cking> parallelized compression is required
[11:47] <ogra_> you complain about 15min for a ddeb build
[11:47]  * apw suspects about an hour on armel
[11:47] <cking> at least
[11:47]  * ogra_ thiks we really need to force cking into a 6month arm team rotation to develop more patience :P
[11:47] <cking> noooooooooooooooo
[11:48]  * cking pretends to forget his ARM knowledge
[11:48] <ogra_> heh
[11:56] <cking> heh, takes less time to download than to create
[13:06] <apw> herton, the mvl-dove rebase ... as it is you guys who put in the final tracking bug and actually close the release i suspect you are going to want to do that rebase... i've spent some time sorting out the rebase script so it works the same as the update-to-natty-master we use in the natty and maverick backports
[13:07]  * ogra_ doesnt get why we still have to maintain that kernel ...
[13:08] <herton> apw: hmm ok, isn't ppisati running the script and pushing that to us?
[13:14] <apw> herton, well we can do that, but its one of those silly round trips currently
[13:14] <apw> he makes the open branch, pushed it, you close it for lucid
[13:15] <apw> then he has to pull it, move it into maverick and push it again, then you have to change the tracking bug and check it and push it
[13:15]  * ogra_ shakes his head
[13:15] <apw> as its a direct 100% copy of whats in lucid, it doesn't seem that sensible to ping-pong it like that ... to me anyhow
[13:16] <herton> what you say makes sense. Is the script update-from-lucid-mvl-dove ?
[13:32] <ppisati> herton: yes, it's that done
[13:33] <ppisati> herton: i did the lucid->maverick once
[13:33] <ppisati> herton: but it's not only about this script... ufff...
[13:33] <ppisati> wait
[13:35] <ogra_> we should really drop the maverick dove kernel ... it doesnt fulfill any purpose or has any users
[13:37] <apw> ogra_, dunno mate, but when we talked before it had support for 18m and so we had to support it
[13:38] <ogra_> apw, not for dove ...
[13:38] <apw> ppisati, i pushed an updated script to the branch which actually works ...
[13:38] <ogra_> the maverick dove support we did was solely for oem to make sure userspace works on dove ... the kernel they use is totally uncompatible to ours
[13:38] <apw> herton, yes thats the one
[13:39] <apw> ogra_, but it seems to be marked as supported in the support matric
[13:39] <ppisati> apw: ok
[13:39] <apw> ppisati, i tried to use it this morning and it ate my tree, so i fixed it up
[13:39] <ogra_> apw, userspace ... i'll talk to david next week if we can drop the maverick dove kernel
[13:39] <ogra_> lucid is still supported for 18 months though, there you are right
[13:39] <ppisati> i remeber i had to do some git reset and then launching the script
[13:39] <apw> ogra_, ok thanks, mostly its 100% the same as lucid, so
[13:40] <ppisati> but if it works out of the box now, is much better
[13:40] <ogra_> but having to go on with dove once lucid on arm is EOL is just insane
[13:40] <apw> ppisati, right should just work now, it was always meant to
[13:40] <apw> ogra_, indeed a fair point
[13:42] <apw> ppisati, i feel that if it works as well as the lts ones, and it should, then it might be most expediant for herton to run it just cause he closes the lucid one and verifies that
[13:42] <ppisati> herton: btw, what was the problem yesterday with the lucid/mvl-dove kernel? i mean, the create-tracker script
[13:42] <ppisati> apw: ack
[13:43] <herton> ppisati: the kernel tools looks at the git branch, and looks for changelog at debian.<branch name>, well that was the problem I had
[13:43] <herton> just renamed the branch to what it was expecting
[13:44] <apw> herton, which tools do that, really they should look at debian/debian.env to find out the 'branch name'
[13:45] <herton> apw: create-release-tracker, which uses ktl/debian.py
[13:45] <apw> herton, i think that should be fixed to use debian/debian.env if it exists
[13:45] <apw> and actually now that karmic is gone if there isn't one then its debian
[13:46] <herton> yep, or having a possible command line switch to override
[14:14] <ppisati> regarding the buglink in the commit message of cve patches
[14:14] <ppisati> some of them point to a real but ticket
[14:15] <ppisati> e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601226
[14:15] <ubot2> Ubuntu bug 601226 in linux-fsl-imx51 "Unable to handle kernel NULL pointer dereference in ppdev module" [Undecided,In progress]
[14:15] <ppisati> others point to the tracker bug of the release that contained that fix
[14:15] <ppisati> e.g.
[14:15] <ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/731226
[14:15] <ubot2> Ubuntu bug 731226 in linux "Lucid update to <IP_ADDRESS>.14 stable release" [Undecided,Fix released]
[14:15] <ppisati> but i guess we want just the first case, right?
[14:17] <alex3f> hi: #397096 happens with 2.6.38-10, but with 2.6.38-9 does not, on my machine
[14:20] <herton> ppisati: I think it should point to the cve tracking bug?
[14:21] <tgardner> ppisati, CVE patches that we develop or integrate should have their own bug report, whereas stable updates are batched in one giant bug report. We often get CVE patches via stable updates, so we just need to mark the stable update tracking bug as having a CVE vulnerability.
[14:22] <ppisati> tgardner: ok
[14:22] <ppisati> tgardner: so the one pointing to a tracker bug, means we got them via stable update
[14:23] <tgardner> ppisati, when you notice that a stable update solves a CVE, you should also note it in the changelog.
[14:23] <tgardner> ppisati, yes
[14:24] <tgardner> ppisati, apw has developed a script that pairs stable updates and CVE commits from mitre.org and has cleared out some of our backlog of CVE notices.
[14:24] <ppisati> tgardner: ok, but then that particular patch that i cherry pick won't poing to "real" launchpad bug page, and thus i cannot add any $release/$branch to it
[14:25] <ppisati> s/poing/point/
[14:26] <ppisati> tgardner: i mean, you told me that every CVE entry that i pushed should have the correspective $release/$branch in the launchpad bug page
[14:26] <apw> tgardner, ok the 'final' 3.0 / <IP_ADDRESS>.0 kernel / meta are built in my red ppa: https://edge.launchpad.net/~apw/+archive/red/+packages (as ~pre2) as its irrevocable if i get it wrong i wonder if you might review the packages produced for numbering etc
[14:26] <ppisati> tgardner: but what if they point to a cve tracker?
[14:26] <apw> ogra_, ^^
[14:26] <tgardner> ppisati, if you're doing a wholesale rebase against master then you can likely just add a package task (linux-fsl_imx51) to the original stable update tracker bug. Otherwise you should create a new stable update tracker bug.
[14:26] <ppisati> sorry, tracker bug
[14:27] <ppisati> tgardner: ok
[14:28] <tgardner> apw, looking...
[14:29]  * tgardner wonders if pgraner is in a noisy air-conditioned space
[14:29] <apw> meant to be around now i think
[14:30] <ppisati> tgardner: and for every bug that get a new launchpad bug, i should push again to update the buglink, right?
[14:30] <tgardner> apw, the east coast is having a heat wave, so it might be  good place to be.
[14:30] <tgardner> ppisati, yeah. you can just edit the commit logs and I can reset to your HEAD
[14:31] <apw> tgardner, a heads up ... i've respun all the update-to-foo scripts in the lts-backports and in the maverick/mvl-dove branch to basically be the same script and fixed up a bunch of issues
[14:32] <apw> tgardner, and i have been wondering if we should rename the files to debian/scripts/misc/update-to-my-upstream
[14:32] <tgardner> apw, do they now all have a common ancestor in the debian repo ?
[14:32] <apw> in all of them, so that there is a trivial way to tell if the branch has scripted updates and you know already what it is called
[14:33] <tgardner> apw, never mind. ack to your last comment.
[14:33] <apw> tgardner, good point, will do that now
[14:33] <apw> i'll start a thread on u-k-t for that, so that stable is aware ...
[14:35] <apw> tgardner, can we turn the emerald raid into jbos and try raiding it higher ... wonder if that might help
[14:35] <tgardner> apw, I tried that on my emerald. didn't seem to make a difference
[14:35] <apw> so its just a crap controller, thats poor
[14:35] <tgardner> i.e., I exposed both drives as used LVM
[14:36] <tgardner> s/as/and/
[14:38] <apw> poor indeed, hrmph
[14:39] <tgardner> apw, push your packaging changes to oneiric master-next so I don't have to download the whole source package from your PPA.
[14:44] <apw> tgardner, got any other solid use cases for overlayfs other than livecd ?
[14:45] <apw> tgardner, trying to help shore up the request to merge
[14:45] <tgardner> apw, hmm, its not really my domain of expertise :)
[14:55] <ppisati> uhm
[14:59] <apw> tgardner, other than the closing commit the master-next branch is up to date on linux
[14:59] <apw> tgardner, and linux-meta master-next has the latest bits
[15:04] <ppisati> apw: i can't switch to master to find the sha since i'm in a rebase in fsl-imx51 but
[15:04] <ppisati> apw: http://markmail.org/message/dy5bldezg6e55tl7#query:+page:1+mid:4oi2w3bs76nwuxxw+state:results
[15:04] <ppisati> apw: the buglink points to CVE 3875 and not 3876
[15:05] <ppisati> apw: but in any case, both of them are not that commit
[15:05] <ppisati> wait
[15:05] <ppisati> apw: 3876 is the correct one, nevermind
[15:05] <apw> ppisati, ok
[15:06] <ogra_> apw, what exactly did you want me to see when you pointed upwards ?
[15:06] <apw> some patches fix more than one but get applied for hte first
[15:06] <apw> ogra_, i suspect i wanted ogasawara to see something
[15:06] <ogra_> heh
[15:06] <ogra_> k
[15:06] <ppisati> apw: yeah, i was fooled by the but description, thought it was the commit msg
[15:06] <ppisati> s/but/bug/
[15:06]  * ogasawara scrolls back
[15:06] <apw> ogasawara, ok the 'final' 3.0 / <IP_ADDRESS>.0 kernel / meta are built in my red ppa: https://edge.launchpad.net/~apw/+archive/red/+packages (as ~pre2) as its irrevocable if i get it wrong i wonder if you might review the packages produced for numbering etc
[15:07] <ogasawara> apw: yep, will look right now
[15:07] <apw> tgardner, ok i've pushed the close out as well for master-next on ubuntu-oneiric for completeness
[15:07] <apw> once you two are happy i'll hit the upload buttons
[15:08] <smb> O_o how many zeros?
[15:08] <apw> smb, 5
[15:09] <apw> smb, 5 digits on meta, as <IP_ADDRESS>.5 < <IP_ADDRESS> ... so for meta we need to use 3 digits till we decide and for the kernel we need to use 2, in order to keep our options open
[15:10] <tgardner> apw, update Vcs-Git to point to the correct repo
[15:10] <apw> ahh right will do
[15:11] <amitk> 5 digits!
[15:11] <tgardner> apw, well, it looks right as far as I can tell.
[15:11] <amitk> I though Linus wanted to reduce one digit
[15:11] <tgardner> apw, the meta package bodge should work
[15:12] <tgardner> amitk, 5 digits is just for meta package versioning
[15:12] <smb> Seems in order to reduce we need to increase before being done
[15:12] <apw> amitk, the meta package has alays had 5, it may reduce to 4 if we stick with the 2 digit kernel numbering
[15:13] <apw> amitk, a number of tools are just not expecting the version number to stop being 3 digits, like ps, top, depmod
[15:13] <apw> and till those are fixed we are in a difficult plac
[15:13] <amitk> x.y.z-abi.upload
[15:13] <apw> thats the kernel numbering
[15:13] <apw> which is x.y-abi.upload in the current package
[15:13] <smb> apw, Oh right, meta was always strange. It just was not that obvious without that many zeros
[15:13] <apw> we are hedging out bets
[15:13] <amitk> I small step for Linus, I giant step.....
[15:14] <amitk> :)
[15:14] <ogasawara> apw: looks good here
[15:14] <amitk> s/I/One
[15:14] <apw> our bets, by taking the side which allows us to upgrade to the other, for the kernel 3.0 -> 3.,0.0 just fine and not the other way, for meta <IP_ADDRESS>.5 -> <IP_ADDRESS> but not the other, so we are splitting our selves for now
[15:15] <smb> FYI: It seems all recent proposed uploads of the kernel images strangely ended up in the universe of proposed...
[15:15] <apw> as in not in main ?
[15:15] <smb> linux-image-2.6.35-30-server | 2.6.35-30.53 | maverick-proposed/universe | amd64
[15:15] <smb> piti is trying to fix
[15:16] <apw> nothing is going right is it
[15:16] <ogasawara> weird, how did that happen
[15:16] <smb> maybe another we fix lp issue...
[15:17] <smb> But that was the thing I noticed yesterday about uninstallable kernels
[15:17] <smb> Just thought that to be delay on my side
[15:18] <apw> ogasawara, fyi, if you have broken history and printchanges doesn't work (like it doesn't as we switch 2.x -> 3.0) you can now do fdr prev_release=2.6.39-3.10 insertchanges to override the search
[15:18] <apw> (on the oneiric tree)
[15:18] <ogasawara> Oooo nice
[15:19]  * apw got sick of doing it by hand
[15:21] <apw> tgardner, was that the only issure or are you still poking
[15:22] <tgardner> apw, nah, I'm on to a support escalation bug.
[15:22] <tgardner> so, I guess I'm done
[15:22] <apw> tgardner, fun
[15:22] <smb> hopefully not _that_ bug again...
[15:23] <tgardner> smb, nope, its one of your DRM stable updates methinks. time will tell.
[15:23] <smb> yiek
[15:37] <bjf> tgardner, which kernel is that escalation bug against?
[15:37] <tgardner> bjf, lucid
[15:38] <apw> bjf, sconklin, quick heads up, i've updated the update-from* scripts in the lts backport branches ... makes them quicker and easier on your repositories
[15:38] <cking> just like to say that systemtap rocks
[15:39] <apw> bjf, sconklin, i have also fixed up the one on the maverick mvl-dove so that it actually just works like the ones on the lts branches
[15:39] <bjf> apw, thanks
[15:40] <smb> sforshee, bjf With that escalation bug. Be extra careful about versions. At least for the last few proposed uploads things seemed to have gone into proposed/universe instead of proposed/main
[15:40]  * ogasawara back in 20
[15:51] <brendand> sconklin - i'm wondering why the tracking bugs for Maverick and Natty SRU's haven't been invalidated yet - aren't they being respun?
[15:51] <bjf> brendand, working on it
[15:52] <bjf> brendand, at this very moment as a matter of fact
[15:52] <brendand> bjf - correct me if wrong, but can't they be invalidated as soon as it's known there will be a replacement?
[15:53] <bjf> brendand, yes
[15:53] <apw> git show Ubuntu-lts-2.6.38-10.44
[15:55] <apw> tag Ubuntu-lts-2.6.38-10.44
[15:55] <apw>     UBUNTU: Ubuntu-2.6.38-10.44
[16:20] <CarlFK> what is this?  [    1.356136] acpi device:4e: hash matches
[16:20] <CarlFK> I have 2 HP EliteBook 8530w laptops.  3 firewire EC cards work on one but not the other.  I am trying to look for differences.  I booted both, dmesg>d.txt, diff, that line is in one but not the other.
[16:24] <apw> CarlFK, that is a piece of debugging which only has meaning if you had suspend debugging turned on, suspended and then hard booted out of suspend.
[16:24] <apw> CarlFK, any other time it appears it is just random fluke... litereally some part of your clock matched something in the kernel and triggered that message
[16:25] <BenC> CarlFK: sounds more like the other fw card is just broken...does it even show in lspci and does the driver detect it?
[16:25] <CarlFK> it suspend debugging turned on in oneiric ?
[16:26] <BenC> CarlFK: and does the card work in another system?
[16:26] <CarlFK> BenC: 3 cards, they all work in one but not the other
[16:26] <CarlFK> and actually 3 cards work in 1, not work in 3 other boxes.
[16:26] <BenC> CarlFK: I'm a little ambiguous on what you mean...
[16:26] <CarlFK> 3 cards are all same make/model.
[16:27] <BenC> And they all work on one computer, but not another computer?
[16:27] <CarlFK> BenC: you should be becuase it doesn't make sense :)
[16:27] <CarlFK> yep.
[16:27] <CarlFK> thus my quest for what makes the one box special
[16:27] <BenC> CarlFK: and the other computer has the same kernel, same mobo, same cpu, etc?
[16:27] <CarlFK> yep
[16:27] <BenC> Then sounds like the other computer is broken :)
[16:28] <abogani> same BIOS version?
[16:28] <BenC> maybe reset the BIOS
[16:28] <CarlFK> I don't want to mess with the box where they work.  else I may never get it back to that state, which would make me sad :)
[16:28] <BenC> But if you're not seeing any difference in dmesg other than that one line, it sounds like the BIOS is POSTing the same, else you'd see difference values for the PCI detection
[16:29] <BenC> CarlFK: reset the BIOS in the box that doesn't work
[16:29] <BenC> Or at least check the BIOS versions to see if they match
[16:29] <CarlFK> BenC: not a bad idea
[16:30] <CarlFK> biosdecode is the same on both, but it doesn't print much - not sure what that proves.
[16:35] <CarlFK> bios reset, fw (firewire) still broken.
[16:36] <apw> CarlFK, not by default you have to ask for it on the kernel command line
[16:38] <tgardner> apw, When installing a 3.0 kernel on Natty I get this message (as expected): 'dpkg: dependency problems prevent configuration of linux-image-3.0-0-generic:
[16:38] <tgardner>  linux-image-3.0-0-generic depends on module-init-tools (>= 3.13-1ubuntu1)'
[16:39] <tgardner> this is gonna cause a huge pain in the ass for LTS backports.
[16:39] <tgardner> unless we update m-i-t in Lucid
[16:39] <apw> tgardner, yes either we'll have to use 3.0.0 there (as has been suggested) or we have to fix m-i-t in lucid
[16:39] <apw> probabally the same patch could be applied, ie not update it much
[16:39] <apw> and then have the right dependancy on the backoprt
[16:40] <tgardner> apw, right, just something to keep in mind when you make the final version decision
[16:40] <apw> tgardner, and the kernel won't boot if you install it without the right tools
[16:40] <apw> yep i have a lits of known problem packages..
[16:40] <apw> tgardner, do we have cross compilers for oneiric yet?
[16:41] <apw> (for tangerine chroots)
[16:41] <tgardner> apw, should be.
[16:41] <apw> make[4]: arm-linux-gnueabi-gcc: Command not found
[16:41] <tgardner> lemme check, I'm sure I saw that upload go by
[16:42] <apw> i386 seems to have half of it, no gcc frontends
[16:43] <tgardner> apw, still seems borked: The following packages have unmet dependencies:
[16:43] <tgardner>  gcc-arm-linux-gnueabi : Depends: gcc-4.6-arm-linux-gnueabi (>= 4.6.0-8) but it is not going to be installed
[16:43] <apw> bah, ok thanks
[16:43] <bjf> kees, smb, can you each add a comment to bug 788843 giving your input on there being a regression or not
[16:43] <ubot2> Launchpad bug 788843 in linux "linux: 2.6.24-29.90 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/788843
[16:45] <smb> bjf, done
[16:47] <tgardner> apw, try again. I updated and the package problems magically disappeared.
[16:50] <smb> seems apw also disappeared magically. :-P
[16:50] <apw> tgardner, looks better thanks
[16:50] <apw> tgardner, did you do amd64 as well?
[16:51] <tgardner> apw, both
[16:51] <apw> tgardner, excellent
[16:56] <smb> Grrr... so have all my window decorations after unity-window segfaulted...
[16:56] <apw> smb, run unity again on VT1
[16:57] <smb> apw, That helped. Ta
[17:03] <tgardner> wtf is up with launchpad today? it times out on everything
[17:03] <smb> tgardner, They updated it
[17:04] <tgardner> smb, well, its freaking unuseable
[17:05] <bjf> tgardner, the topic in #launchpad seems to indicate they are aware of an issue and are working it
[17:07] <smb> Hrmpf, as useful as unity shitting its pants just because I try to use a java-ikvm
[17:13] <apw> tgardner, its been broke for most of the last 20 hours, no idea why the don't roll it back
[17:45] <tgardner> apw, whoo hah! [ubuntu/oneiric] linux 3.0-0.1 (Accepted)
[17:45] <tgardner> let the carnage begin.
[17:45] <apw>  /me waits for all the fallout
[17:45] <apw> :)
[17:45] <apw> yeah
[17:47] <apw> right that'll take some hours so i am going to go drink some bubbles :)
[17:47] <tgardner> apw, cheers. see you in a week
[17:51] <apw> tgardner, have fun!
[17:53] <herton> apw, ppisati: I run the updated script to update maverick mvl-dove, worked fine. I'm preparing it for pushing to the repo/create packages.
[17:55] <CarlFK> why are these different?  < yenta_cardbus 0000:86:09.4: ISA IRQ mask 0x0cb8, PCI irq 22 > yenta_cardbus 0000:86:09.4: ISA IRQ mask 0x0c98, PCI irq 22
[17:59] <kees> bjf: done
[18:01] <bjf> kees, thanks
[18:02] <kees> np :)
[18:04] <smb> tgardner, will I run into you when I try to apply my cve patch to hardy?
[18:06] <tgardner> smb, figuratively speaking ?
[18:07] <smb> tgardner, or virtually. I was about to commit it but I saw some activity there.
[18:07] <tgardner> smb, I've pushed apw's CVE patch, so you should be OK
[18:08] <smb> tgardner, Ok cool. Just wanted to avoid both of us trying to push at the same time. :)
[18:38] <kees> apw: fwiw, I've added linux-lts-backport-natty to uct.
[18:43] <bjf> tgardner, apw, the carnage has began, i have script failure due to version regex
[18:56]  * tgardner --> lunch
[19:41]  * tgardner --> server room
[19:42]  * jjohansen reboots :\
[20:05]  * jjohansen -> lunch
[20:19] <tgardner> bjf, is this indicative of an LP timeout ?
[20:19] <tgardner> rtg@lochsa:~/ubuntu/ubuntu-lucid$ ~/kteam-tools/stable/create-release-tracker
[20:19] <tgardner> https://bugs.launchpad.net/bugs/795219
[20:19] <tgardner> Traceback (most recent call last):
[20:19] <tgardner>   File "/home/rtg/kteam-tools/stable/create-release-tracker", line 281, in <module>
[20:19] <tgardner>     app.main()
[20:19] <tgardner>   File "/home/rtg/kteam-tools/stable/create-release-tracker", line 237, in main
[20:19] <ubot2> Ubuntu bug 795219 in linux-fsl-imx51 "linux-fsl-imx51: 2.6.31-609.26 -proposed tracker" [Medium,In progress]
[20:19] <tgardner>     t.assignee = self.lp.launchpad.people[taskAssignments[task]]
[20:19] <tgardner> AttributeError: can't set attribute
[20:19] <bjf> tgardner, no, that can be an indication that you need to update your lpltk
[20:20] <tgardner> bjf, how do I do that ?
[20:20] <tgardner> bjf, it wasn't in a package, was it ?
[20:20] <bjf> no
[20:21] <bjf> you have to get the bzr repo and then run the setup.py script as root
[20:21] <bjf> i have a package in my ppa if you want to try it
[20:21] <bjf> tgardner, ^
[20:21] <bjf> https://launchpad.net/~brad-figg/+archive/kteam
[20:21] <bjf> tgardner, ^
[20:29]  * ogasawara lunch
[21:10] <sconklin> tgardner: what are you doing with the fsl-imx tracking bug? Almost all status changes are automated and should be made by the bot, and if anything, you should be changing prepare-package after it's built in a PPA? I'm confused
[21:12] <tgardner> sconklin, I didn't do anything but create it. LP is so freaking slow today that I haven't been able to make _any_ state changes.
[21:15] <sconklin> tgardner: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/795219 perhaps it's issues with timeouts and LP UI that caused the status changes while you were trying to poke at it, sorry for griping, but that's the way it looked
[21:15] <ubot2> Ubuntu bug 795219 in linux-fsl-imx51 "linux-fsl-imx51: 2.6.31-609.26 -proposed tracker" [Undecided,In progress]
[21:15] <bjf> tgardner, did the script complete? non of the assignements got done so i'm thinging it blew up
[21:15] <tgardner> bjf, sconklin: no, the script didn't complete, not did the package install correctly.
[21:15] <tgardner> nor*
[21:16] <tgardner> then I got distracted chatting w/Pete
[21:16] <bjf> sconklin, i think that one is going to need some human love
[21:16] <sconklin> tgardner: oh, yeah I hate when that happens. I usually just invalidate everything in the bug nd keep rerunning the script until it all completes. It's too easy to screw it up when you do stuff manually.
[21:16] <sconklin> I'll fix it up.
[21:17] <tgardner> sconklin, cool. I'm outta here. see you next week.
[21:17] <sconklin> and eventually I'll write a "validate and fox" script
[21:17] <sconklin> later!
[21:17] <lifeless> tgardner: sorry!
[21:17] <lifeless> (it is, quite literally, all my fault)
[21:17]  * tgardner thinks lifeless is buying beers next time :)
[21:18] <lifeless> well, other folk have done a heap on the things we've improved - I am not taking their credit :) - but I will wear all the blame
[21:18] <tgardner> its been working well until this morning (for me at least)
[21:19] <lifeless> tgardner: so we add.d...
[21:29] <jcastro> jjohansen: any luck with the wireless on the 3.0 kernel?
[21:30] <jjohansen> jcastro: haven't tried yet.  I was going to try to give it a run tonight
[21:31] <jcastro> jjohansen: either way I'm going to snag a dongle before ireland, and possibly bring a backup laptop on top of that.
[21:31] <jjohansen> jcastro: yeah, definitely
[21:32] <bjf> jcastro, one laptop, 2 partitions: part 1: natty; part 2: oneiric
[21:33] <jcastro> bjf: the driver causes hard lockups in both.
[21:33] <bjf> ouch
[21:34] <jcastro> jjohansen: don't bother putting an intel card in the minipci-e slot, I already tried that, heh.
[21:35] <jjohansen> jcastro: :(  For dublin I was actually considering just getting a new battery and bringing my x61t
[21:36] <jjohansen> its a better machine to work from anyways
[21:47] <jcastro> jjohansen: our bug got duped to this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/749871
[21:47] <ubot2> Ubuntu bug 749871 in linux "Attempt to Use Realtek RTL8192CE Wireless Causes Computer to Freeze" [Undecided,Confirmed]
[21:47] <jcastro> but I have an RTL8188CE, should that matter?
[21:53] <jjohansen> jcastro: it might I am not sure, but it might. I need to dig more into the rtl drivers, and what the diff versions are
[21:53] <Sarvatt> they have a newer driver for RTL8188CE than RTL8192CE on their website, might be worth a try - http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true
[21:55] <jjohansen> Sarvatt: indeed, thats one of the reasons I need to dig more into what drivers to what chipset etc
[21:55] <Sarvatt> err guess i was looking at RTL8188CE-VAU
[21:57] <jcastro> Sarvatt: I couldn't get the linux one building in oneiric.
[21:57] <jjohansen> Sarvatt: the point being they do have newer stuff, and I need to dig into the whole mess
[22:51] <sconklin> apw: still not drinking beer?


[14:59] <dkessel> hello. i have an ubuntu cloak but i am not a member of the launchpad team "ubuntu cloaked people". is there a way to fix that?
[15:04] <IdleOne> dkessel: it took about 3 months for me to get mine in the mail
[15:05] <IdleOne> maybe it was 4
[15:05] <IdleOne> the certificate that is
[15:05] <dkessel> IdleOne: ok... so it may arrive any day now ;D
[15:05] <IdleOne> /may/
[15:06] <IdleOne> let me check why you are not in the cloaked people group if i can
[15:06] <dkessel> or in may :)
[15:06] <IdleOne> hehe
[15:11] <IdleOne> doesn't appear like you were ever added to that team, probably just a mistake. Pici Tm_T hggdh can you add https://launchpad.net/~dkessel to ~ubuntu-irc-cloaks
[15:12] <IdleOne> I could do it but I am technically no longer on the IRCC and I shouldn't being adding people to teams even though I can.
[15:14] <hggdh> IdleOne, dkessel: just a sec
[15:16] <hggdh> dkessel: done
[15:16] <IdleOne> thank you hggdh
[15:16] <dkessel> thank you hggdh, IdleOne
[15:16] <hggdh> you are all welcome :-)
[15:16] <IdleOne> so yeah, the certificate might take some time depending on where sabdfl is in the world and stuff
[15:20] <hggdh> IdleOne: can we have a quick chat?
[15:20] <IdleOne> sure


[01:28] <rbasak> pitti: I think everything is built now. Please could you retest everything listed as a regression in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5? I just tried myself, but I don't seem to be able to reach anything via batuan.
[02:34] <ari-tczew> cyphermox: Well, I think I'm ready with libcapi20-3 transition. I did a rebuild on all reverse depends. I'll look later whether are they all build fine.
[03:37] <infinity> rbasak: Still around?
[03:37] <infinity> rbasak: It's awfully late, so I'm going to assume no.
[03:38] <infinity> rbasak: Anyhow, I'm going to assume you tested this spamassassin change and it works, but if it had been me, I would have also commented out the line in 50_scores.cf
[03:41] <infinity> rbasak: All accepted.  Please verify ASAP, happy to fasttrack this once you sure it both solves the bug and doesn't otherwise break anything.
[03:58] <rbasak> infinity: thanks. I'll verify after sleep. I did consider commenting out 50_scores.cf, but if I did that I'd also want to do the translations, and tested that it works across all releases without any warnings or anything by just doing the definition.
[03:59] <rbasak> I suppose in part it's because testing across all releases is tedious, so I started with the minimal, and that worked, so I didn't feel the need to go further.
[06:44] <pitti> Good morning
[06:45] <pitti> rbasak: yes, my retry button finger was busy last night and this morning :)
[07:07] <pitti> rbasak: there are still a few regressions; e. g. jmespath.php looks like a victim of the same patch regression that hit systemd and glibc: debian bug 776257
[08:09] <dholbach> good morning
[08:45] <LocutusOfBorg1> hi dholbach !
[08:48] <LocutusOfBorg1> hi all
[08:49] <dholbach> hi LocutusOfBorg1
[09:00] <mlankhorst> can I get libepoxy promoted to main for trusty?
[09:01] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/libepoxy/+bug/1342605 was the bug for utopic, but I need it in main for xorg-server-lts-utopic
[09:03] <mitya57> pitti, jibel: vivid-adt-software-properties fails since Jan 20th, but for some reason it blocks pyqt5 which got built only yesterday
[09:03] <mitya57> Please do something :)
[09:05] <pitti> well, best would be to fix software-properties :)
[09:05] <pitti> I'll look at it later, it also blocks gtk+3.0
[09:53] <jibel> pitti, it seems it's failing because the path to dbus-launch is wrong
[10:01] <pitti> jibel: oh, indeed
[10:03] <mitya57> pitti, jibel: it probably needs to add dbus-x11 to Depends
[10:09] <pitti> mitya57: yeah; running test locally now, will upload if that works
[10:23] <cjwatson> rbasak: You need to switch to the new company VPN; the old batuan one is AFAICT essentially dead/broken as of the end of last year.
[10:24] <rbasak> cjwatson: I thought it might be that. Thanks!
[10:24] <rbasak> pitti: Thanks - I'll follow up.
[10:25] <mlankhorst> doko__: hm mesa 10.4.2 fails to build against llvm 3.6
[10:25] <pitti> mitya57, jibel: software-properties uploaded
[10:26] <mitya57> thanks :)
[10:43] <hallyn> arges: hi, on your next sru stint could you please take a look at 1404388?  its fix has been baking for awhile...
[10:52] <mlankhorst> doko__: I've grabbed some patches from git, but I would prefer to skip to 10.5 first
[10:54] <mlankhorst> still, it seems to build, no idea if it really runs..
[11:26] <mlankhorst> crash crash
[11:42] <mlankhorst> tons of stuff failing that failed before, I'll try with master..
[12:26] <mlankhorst> slightly better there, maybe I missed some backports :-/
[12:50] <mlankhorst> definitely did.. grabbed 1 more and llvm-3.6 works a lot better now
[12:54] <doko> mlankhorst, cool, looks promising
[12:54] <mlankhorst> seems to have no regressions in llvmpipe compared to 3.5
[13:13] <mlankhorst> I'll have to test i386 to be sure
[13:51] <Riddell> mvo: I wonder if you could help me and harald with a apt resolver problem
[14:02] <Bluefoxicy> https://lkml.org/lkml/2015/1/23/688
[14:02] <Bluefoxicy> this is also going on on linux-mm
[14:03] <Bluefoxicy> http://marc.info/?l=linux-mm&m=142242638202925&w=2
[14:04] <Bluefoxicy> .... oh.  Rik van Riel's response isn't on the archives yet
[14:04] <Bluefoxicy> "The Android low memory killer does exactly what you want, and for very much the same reasons.
[14:04] <Bluefoxicy> See drivers/staging/android/lowmemorykiller.c"
[14:05] <Bluefoxicy> Trying to get the reclaim code un-stupided so the computer doesn't just thrash like hell when you've eaten 99% of your RAM and have no space for page cache
[14:10] <xnox> didrocks: your emails came out as attachments, instead of inline =/
[14:10] <xnox> unless my mail client is acting silly
[14:11] <pitti> no, same here; but that's ok? avoids line wrapping and is easier to save?
[14:13] <xnox> no idea if the standard is attachments or inline. I guess i like inline only, and most other people send things like that as well.
[14:13] <xnox> surely one syncs mailbox as mbox / maildir anyway thus they are already saved. (well integrators usually do)
[14:14] <didrocks> xnox: yeah, did that to avoid line wrapping
[14:15] <didrocks> xnox: did that last time as well, didn't seem to have been a biggy
[14:16] <xnox> meh fair enough.
[14:18] <Bluefoxicy> static inline?
[14:34] <arges> hallyn: sure thing
[14:41] <arges> hallyn: hey we just need bug 1393548 verified to release that fix, its whats been blocking it
[14:44] <mlankhorst> doko: ok seems that on 32-bits llvm 3.5 -> llvm 3.6 has no regressions, just some fixes.. presumably from a commit that fixes unaligned access
[14:47] <flexiondotorg> cyphermox, Hi
[14:47] <flexiondotorg> cyphermox, What are the next steps for me to get Ubuntu MATE being built officially?
[14:48] <flexiondotorg> cyphermox, I see some of the merge proposals are approved but not merged yet.
[14:48] <flexiondotorg> cyphermox, How do I go about get me meta package integrated?
[14:59] <hallyn> arges: oh, feh.  thanks
[15:04] <cyphermox> flexiondotorg: yes, I'm fixing this in a bit, as soon as I'm done with what I'm currently working on
[15:05] <cyphermox> flexiondotorg: is your metapackage prepared already? I could take a look
[15:06] <flexiondotorg> cyphermox, Sure - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/ppa/+packages
[15:06] <cyphermox> great
[15:07] <flexiondotorg> cyphermox, It's called ubuntu-mate-meta. You want version 1.118~15.04~12
[15:07] <cyphermox> ack
[15:07] <flexiondotorg> cyphermox, I realise I need to clean up the version number for import.
[15:08] <flexiondotorg> cyphermox, Source is here - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-meta
[15:08] <cyphermox> thanks
[15:29] <xnox> cyphermox: you do know how to correctly do meta package updates?
[15:29] <xnox> as in merge into seed branch, pull package, run update, upload.
[15:29] <xnox> they are semi-automatic
[15:38] <rbasak> pitti: all the remaining issues for php5 now are the dpkg symlink problem. Not sure what to do about that.
[15:41] <pitti> rbasak: yeah, me neither; this is currently being discussed with patch upstream
[15:41] <pitti> rbasak: we could revert the security fix for the time being of course;
[15:45] <cyphermox> xnox: I know how to do it, but this would be a new package
[15:49] <pitti> hm, just got a bug report: "I am running Ubuntu 12.05, and most things work fine."
[15:49] <pitti> where can I download it? :-)
[15:49] <ogra_> linaro ?
[15:49] <ogra_> :)
[15:51] <xnox> cyphermox: =/ i've never done a new seed from scratch. as there are a few bits that need to happen elsewhere in the infra to get it working
[15:51] <cyphermox> one step at the time, we'll make it work. I'm not worried
[15:52] <rbasak> barry: around? I'm helping matsubara with bug 1412545. A reporter is asking about an embedded copy shipped in virtualenv.
[15:53] <rbasak> barry: do you know about how the unvendoring and wheel stuff works, please? Does this need a rebuild of pip and then a rebuild of virtualenv to update virtualenv with a fix?
[15:55] <cyphermox> flexiondotorg: one of the next steps I'd propose is to try to get more uploads sponsored, so that you can eventually get upload rights to at least some of the MATE packages, this would help you get stuff done.
[15:55] <flexiondotorg> cyphermox, Agreed.
[15:56] <flexiondotorg> cyphermox, Right now I am hoping to get all the "infrastructure" stuff completed. Then start to address the package uploads.
[15:56] <cyphermox> very well. I'm happy to sponsor things if you need
[15:57] <flexiondotorg> cyphermox, Great. dholbach has also sponsored stuff in the past.
[15:57] <flexiondotorg> I'll start preparing the few packages that require upload. Basically, settings and artwork.
[15:57] <flexiondotorg> I'll need a day or so to get round to that.
[15:57] <barry> rbasak: okay, you are either screen capturing me or reading my responses to LP: #1415028
[15:58] <barry> rbasak: and unfortunately, i do know how all that works ;)
[15:58] <barry> or in trusty's case, doesn't work
[15:58] <cyphermox> flexiondotorg: you may want to start working on ubiquity-slideshow-ubuntu-mate if it's not already prepared :)
[15:58]  * rbasak reads
[15:59] <flexiondotorg> cyphermox, Already done.
[16:00] <cyphermox> great
[16:00] <flexiondotorg> I've submitted a merge proposal which has been merged.
[16:00] <barry> rbasak: basically, this was all fixed in debian, and inherited in ubuntu, but not until *after* trusty.  pyvenv is deliberately broken in trusty because it violates debian policy. virtualenv violates it too, but that wasn't discovered until after trusty.  so trusty's virtualenv works by accident.  this is all done correctly in jessie, and thus inherited by ubuntu post-trusty.  i talk to *a lot* of people about this
[16:00] <flexiondotorg> However, it has not been built.
[16:00] <rbasak> barry: understood, thanks. I didn't know about the other bug there.
[16:00] <flexiondotorg> cyphermox, If you can trigger a build that would be helpful because I have translator who can't work on it until it is built.
[16:00] <flexiondotorg> *translators
[16:01] <cyphermox> ok
[16:01] <barry> rbasak: i've changed my opinion on what should be done.  i now mostly agree this should be fixed properly in trusty (essentially what jessie/vivid has) but that's a lot of work and a lot of sru'ing
[16:01] <rbasak> barry: so I'm mentoring some people on my team on Ubuntu development, and matsubara is tackling 1412545. I think I'll just go through and SRU python-urllib3 and not bother matsubara with the virtualenv of things, if that's OK.
[16:02] <barry> rbasak: so first, i want to see if i can get some resources to do that work, then discuss on u-d@ to see if the stack of sru's we'd need would actually get approved.  this includes adding things like python-wheel which didn't show up in debian until after trusty
[16:02] <rbasak> I can leave a bug task open in that bug for virtualenv.
[16:02] <rbasak> OK
[16:03] <barry> rbasak: i think that's reasonable.  probably as a workaround, you can create the virtualenv, and then `pip install --upgrade urllib3`
[16:03] <barry> which would pull the newer version from pypi
[16:06] <rbasak> Thanks - we'll put that in the bug.
[17:48] <bdmurray> cyphermox: Can you have a look at bug 1410573?
[18:00] <rbasak> infinity: bug 1412830 verified, if you want to fast track it.
[18:00] <infinity> rbasak: Thanks.
[18:02] <infinity> rbasak: Will release now.  If it breaks my mail server on upgrade, I will return and yell at you. ;)
[18:03] <rbasak> infinity: my mail server will get the update too :)
[18:03] <infinity> rbasak: Right, I'll be sure not to yell at you via email if it's broken, then.
[18:03] <rbasak> :-)
[19:21] <xnox> lol
[21:24] <bdmurray> cyphermox: this SRU upload seems to have an accidental change - https://launchpadlibrarian.net/195843293/gnome-bluetooth_<IP_ADDRESS>-0ubuntu4.1_<IP_ADDRESS>-0ubuntu4.2.diff.gz
[21:24] <cyphermox> oh. opps, that's true
[21:25] <bdmurray> cyphermox: okay, rejecting then. let me know when there is another one to review.
[21:25] <cyphermox> sure, it will be in a second
[21:27] <cyphermox> bdmurray: thanks, should be good now. I just uploaded it with the correction
[21:30] <bdmurray> cyphermox: it looks the same to me
[21:31] <cyphermox> gah
[21:32] <cyphermox> ah, no?
[21:32] <cyphermox> anyway, not the changelog issue
[21:32] <cyphermox> are we both looking at http://launchpadlibrarian.net/196059612/gnome-bluetooth_<IP_ADDRESS>-0ubuntu4.1_<IP_ADDRESS>-0ubuntu4.2.diff.gz?
[21:32] <bdmurray> -+	<device oui="7C:1E:52:" type="mouse" name="Microsoft Touch Mouse" pin="0000"/>
[21:32] <bdmurray> ++	<device oui="7C:1E:52:" pin="0000"/>
[21:33] <cyphermox> that's on purpose
[21:33] <cyphermox> 7C:1E:52: devices aren't necessarily mice or calling themselves Microsoft Touch Mouse
[21:33] <bdmurray> that's not called out in the changelog
[21:33] <cyphermox> ugh, I see
[21:34] <bdmurray> so I thought it was an error because the last SRU did the opposite
[21:34] <cyphermox> take three
[21:34] <cyphermox> yes
[21:34] <cyphermox> it is most likely an error anyway to revert the previous SRU
[21:43] <cyphermox> bdmurray: please reject it
[21:43] <cyphermox> I'm sorry for wasting your time with this
[21:45] <bdmurray> cyphermox: no problem, so what's the plan for gnome-bluetooth then?
[21:46] <cyphermox> to really fix that upload
[21:46] <cyphermox> I've re-done it
[21:46] <cyphermox> triple-checked the debdiff
[21:46] <cyphermox> I think it should be good this time :)
[22:55] <cyphermox> flexiondotorg: have you built any kind of almost-daily image somewhere instead of your 14.10 images?


[12:03] <braddr> sounds like a potential pain, testing wise.
[12:04] <fabbione> yes
[12:04] <fabbione> indeed
[12:04] <fabbione> but the first thing i will do is to test your combination
[12:04] <fabbione> if i can reproduce it, i know what i need to tell people to do :)
[12:05] <fabbione> because the point is that the UP kernel is well.. UP
[12:05] <fabbione> it doesn't use anything of the SMP code if not to detect how many CPU's are available on the system
[12:05] <fabbione> and that's done parsing the OBP devicetree
[12:06] <fabbione> the test i did on your machine was to disable thread 0 of core 1
[12:06] <fabbione> (your booting CPU basically)
[12:07] <fabbione> because your CPU has no core+
[12:07] <fabbione> core0 even
[12:07] <fabbione> but the ALOM and OBP do some magic cpu virtual remapping
[12:07] <fabbione> so even if in reality the code is running on core1 thread0, the kernel sees it as cpu0
[12:07] <fabbione> that might be buggy
[12:09] <fabbione> braddr: all the cpu's are born as 8 cores
[12:09] <braddr> ah
[12:09] <fabbione> the 6/4 core models are 8 core where 8 - $x core did fail
[12:09] <fabbione> so they get disabled in hw
[12:10] <fabbione> if you do a showcomponent in the ALOM you can see it
[12:10] <fabbione> the first block of MP/CPU0/.. are the core/thread set
[12:10] <fabbione> the second block (8 entries) are the 4 dual bus for memory access
[12:10] <fabbione> MB/CPU0/R0/D1 iirc
[12:11] <fabbione>     MB/CMP0/P0
[12:11] <fabbione>  <- core0 thread0
[12:11] <braddr> so, barring remapping, cpu p0-3 and 20-31 were disabled
[12:11] <fabbione> you don't have that
[12:12] <fabbione>     MB/CMP0/CH0/R0/D0 <- memory
[12:12] <fabbione> basically yes. the 4 cores that did not pass the test have been disabled
[12:12] <fabbione> that's also why (as you can see) there are "holes"
[12:13] <fabbione> one thing that did puzzle me also was the ALOM POST process
[12:14] <braddr> so, on your and david's sytems, at least one of them has 0-3 disabled?
[12:14] <fabbione> in both your machine and my machine i did disable the booting CPU
[12:14] <fabbione> and the POST was still running on it..
[12:14] <fabbione> so that's what triggered a bell
[12:14] <fabbione> nope.. on all our machines there is a core0/thread0 working
[12:15] <fabbione> david has 1x8 and 1x6
[12:15] <fabbione> i have 1x6 and 2x8
[12:15] <fabbione> but all with core0
[12:15] <fabbione> your is "special"
[12:15] <fabbione> eheh
[12:15] <fabbione> but we will figure it
[12:16] <fabbione> it might as well be a case we don't handle properly OR a combination of bugs
[12:16] <fabbione> we will see soon hopefully
[12:16] <braddr> it'll get sorted out, I have no doubts.
[12:16] <fabbione> yepos
[07:59] <braddr> hark.. is that the sound of a jet passing overhead or did someone just turn on my t2000? :P
[07:59] <fabbione> morning braddr :)
[08:01] <braddr> g'morning
[08:02] <braddr> brb.. my windows desktop's networking is acting all screwy.. gonna reboot.
[08:08] <braddr> what's on the testing block for today/tonight?
[08:09] <fabbione> david has a possible workaround for your problem, but i think he is actually eating to power up brain and brainstorm on a proper solution
[08:10] <fabbione> i just woke up and i am going to test another fix on your box
[08:10] <fabbione> "another possible fix"
[08:16] <fabbione> boot.img-debian-sparc <- tsk ;)
[08:16] <fabbione> debian doesn't support Niagara :D
[08:17] <braddr> hey, fire me. :)
[08:18] <braddr> notice the date on that file?
[08:19] <fabbione> nah.. i was just teasing :P
[08:19] <braddr> I know
[08:30] <fabbione> these are the moments in which i wish gzip could fork on N cpu's
[08:30] <braddr> heh
[08:30] <braddr> yup.. lots of cpu's just don't help single threaded apps.
[08:39] <fabbione> about to boot the new image..
[08:40] <fabbione> you can go in console read only mode if you like
[08:40] <fabbione> boot.img-fabbione-9 <-
[08:42] <fabbione> oh well
[08:42] <braddr> kablooie
[08:43] <fabbione> crap
[08:45] <braddr> shouldn't need to be that verbose.. just boot net mem=1024k should be enough
[08:45] <fabbione> DOUBLE TYPO
[08:45] <fabbione> go fabion!
[08:45] <braddr> er.. 1024m
[08:45] <fabbione> it depends on the tftpd you are using
[08:46] <fabbione> tftp-hpa doesn't support broadcast
[08:46] <fabbione> so you need to specify the tftp server address
[08:46] <braddr> It's been working fine for me forever. :)
[08:46] <fabbione> it doesn't here and never did
[08:46] <fabbione> might be my anal firewall
[08:48] <fabbione> THERE WE GO
[08:48] <braddr> I wasn't watching, but just saw the screen reset.
[08:48] <fabbione> i am at the language selector
[08:49] <braddr> yup.. I see. :)
[08:49] <fabbione> is there an extra disk i can use to test an install?
[08:49] <fabbione> i would like to make sure that it doesn't crash later
[08:50] <braddr> drop to a shell and mount the large partition?
[08:50] <braddr> I definitly don't have a spare disk, but I'm thinking that it'd be fine to reinstall on disk1
[08:50] <fabbione> ok.. give me a few minutes to get to the partitioner
[08:50] <fabbione> otherwise we can't mount anything
[08:51] <braddr> might be quicker to just boot that disk. :)
[08:51] <braddr> on the other hand.. gotta get that far to do an install for real anyway
[08:52] <fabbione> yeah i think i am going to check a couple of more things before we do the install
[08:55] <fabbione> yeps.. ok it's reproducible
[08:55] <fabbione> let see what's the watermark for the issue to appear
[08:56] <braddr> want me to take control for a sec and check that disk for wipe-ability?
[08:56] <fabbione> in a few minutes
[08:56] <fabbione> if that's ok with you
[08:56] <braddr> take your time
[08:56] <fabbione> thanks
[08:57] <fabbione> this mem thing opens a completely new frontier :)
[08:57] <braddr> the amount of memory seems to be a factor?  Bizarre.
[08:57] <fabbione> i have 8GB too
[08:57] <fabbione> and it works
[08:58] <fabbione> it might be a very complex combination at this point
[08:59] <fabbione> 2g boots
[09:06] <braddr> kablooie
[09:07] <fabbione> yeps
[09:07] <fabbione> that's good..
[09:07] <fabbione> it was expected
[09:10] <braddr> if this goes well.. try 8G-1M or -1k even
[09:10] <fabbione> yeah
[09:13] <braddr> interesting
[09:13] <fabbione> yes
[09:15] <braddr> oh, sure, return to bisecting.
[09:15] <fabbione> yeps
[09:16] <fabbione> it might even be 7G+1m
[09:16] <fabbione> hem
[09:18] <braddr> stick with bisecting.. it won't take that many steps to figure out.
[09:18] <fabbione> yeah i know
[09:18] <fabbione> i forgot the m at the end
[09:19] <braddr> and thus the upper bound has been changed.
[09:20] <braddr> er, lower bound
[09:20] <fabbione> yeps
[09:20] <fabbione> except i keep forgetting the m :)
[09:20] <braddr> what's it default to, bytes?
[09:21] <fabbione> kb iirc
[09:21] <braddr> 7680-8191..
[09:22] <fabbione> no worries.. that one is normal because i did interrupt the boot
[09:22] <braddr> pick a number, any number.. where will the tip over point land.
[09:22] <fabbione> 7936m <- 7.75G
[09:25] <braddr> 7936-8192.. I'll put my money on 7999/8000 for no good reason. :)
[09:26] <fabbione> 8064 now :)
[09:26] <fabbione> it might even be bad ram
[09:26] <fabbione> in UP used for something and it crashes
[09:27] <fabbione> in SMP used by some init tables that are not used once init is done
[09:27] <fabbione> that would be ironic
[09:28] <braddr> that would be hilarious and certainly ironic.
[09:28] <braddr> I certainly haven't done much that stresses memory to hell and back.
[09:29] <fabbione> 8064 is good
[09:29] <braddr> 8064-8191.. so much for my first pointless guess
[09:29] <braddr> time for easier numbers.. 8100
[09:30] <fabbione> that would be.... 8064+64
[09:30] <fabbione> 8128 ?
[09:30] <fabbione> yeah
[09:30] <fabbione> i am pretty sure this will work too
[09:34] <fabbione> last 32M :)
[09:34] <braddr> 8128-8191, running out of midpoints.
[09:35] <fabbione> for your blog -9 is just the dapper kernel from git with security fixes and stuff
[09:35] <fabbione> -10 that i am about to boot after the bisect had DEBUG_BOOTMEM on
[09:36] <braddr> on bellevue: ~braddr/.www/t2000/boots.txt -- I just made it world writable, so you can edit
[09:38] <fabbione> nah i am not going to edit www please :)
[09:38] <fabbione> so this one boots too
[09:38] <braddr> well, you've been testing stuff when I'm not around, so it might be worth making notes.  I just made that one file writable
[09:39] <braddr> I'll add this block though
[09:39] <fabbione> oh i didn't do much before..
[09:39] <fabbione> this is realtime debugging ;)
[09:39] <fabbione> but i need a short break
[09:40] <braddr> -9 git as of what date or id?
[09:41] <braddr> -10 is -9 + debug_bootmem?
[09:41] <braddr> anything to note about -8 and boot.img-dapper-orig?
[09:42] <braddr> I think -8 was just current as of that day, but I'm not sure about that
[09:43] <fabbione> -8 is old
[09:43] <fabbione> -dapper-orig is just the acutal dapper kernel.
[09:43] <fabbione> -9 is just git as of yesterday
[09:43] <fabbione> no special id
[09:43] <fabbione> -10 is -9+DEBUG_BOOTMEM
[09:44] <fabbione> i didn't boot -10 yet
[09:44] <fabbione> we are still booting -9
[09:44] <braddr> I saw.  Where are we with the memory boot ranges?
[09:45] <fabbione> 8176
[09:45] <fabbione> booting now
[09:45] <braddr> highest good ?
[09:45] <fabbione> davem suspects that we are sharing a page with some firmware stuff and everything goes bad
[09:45] <fabbione> that's the bisect
[09:46] <fabbione> and it works
[09:46] <fabbione> so it's lower bound now
[09:46] <braddr> okey
[09:46] <fabbione> so next is....
[09:46] <fabbione> 8182
[09:46] <fabbione> no
[09:46] <fabbione> 8184
[09:49] <fabbione> there
[09:50] <braddr> sorry.. not paying attention to the boot attempts, updating the blog of what I've been doing with the box and the testing you've been doing.
[09:50] <fabbione> bah
[09:51] <fabbione> 8184 does error
[09:51] <fabbione> and i forgot m again
[09:51] <fabbione> so lower mark 8176 and higher mark is 8184
[09:51] <braddr> a hah.. new top end point!
[09:55] <fabbione> new top 8180
[09:55] <fabbione> 8176 - 8180
[09:55] <braddr> down to a 4m range
[09:57] <fabbione> Check cable and try again
[09:57] <fabbione> Link Down
[09:57] <fabbione> Timed out waiting for Autonegotation to complete
[09:57] <fabbione> what have you done?
[09:57] <fabbione> it went up again.. brrr
[09:57] <fabbione> scary
[09:57] <braddr> odd.. nothing, but it retried and made it
[09:58] <braddr> nothing interesting on that side
[09:59] <fabbione> ok 8178 is good
[09:59] <fabbione> 8178 - 8180
[09:59] <braddr> last boot!
[09:59] <fabbione> nope...
[09:59] <fabbione> we need to get down to kb
[09:59] <braddr> well, unless you wanna dip into the k's.
[09:59] <braddr> heh
[09:59] <fabbione> 8179
[10:00] <fabbione> well ideally we need to find the page that's making this issue
[10:00] <fabbione> a boundary of 4k would do
[10:01] <braddr> get the page and have the kernel dump the entire thing before the crash and if possible as part of the oops or whatever that die point is
[10:01] <fabbione> the problem is that we can't dump the page
[10:02] <fabbione> as soon as we access that page the hypervisor blocks the system
[10:02] <fabbione> that's the error we are getting
[10:02] <fabbione> we need to understand what is there and why
[10:02] <braddr> oh
[10:02] <braddr> slip the guy a bit of valium, he's obviously a little too high strung.
[10:02] <fabbione> 8179 is good
[10:03] <fabbione> so now.. some maths :)
[10:04] <fabbione> 8375296 - 8376320
[10:04] <fabbione> range in kb
[10:04] <braddr> 2 boots to establish an acceptable good and bad value?
[10:04] <fabbione> we will bisec that now :)
[10:04] <fabbione> it's just one mega
[10:05] <fabbione> so now it is 8179+512k
[10:07] <fabbione> i think we found it :)
[10:08] <fabbione> wow.. it doesn't even break!
[10:08] <braddr> for a definition of we that has you doing all the work.
[10:09] <fabbione> so low mark is still 8375296
[10:09] <fabbione> highmark is 8375808
[10:09] <fabbione> let's try in the middle
[10:09] <braddr> worth repeating the last try?
[10:09] <fabbione> yes, but not now
[10:09] <fabbione> i want to test lowmark+256k
[10:10] <fabbione> if it still hangs, i want to test passing a known to work mem in kb
[10:10] <fabbione> we need to make 100% sure we are not hitting other bugs, like MB = 1000kb instead of 1024
[10:11] <fabbione> i am pretty sure it's done in 2^ values
[10:11] <fabbione> but you may never know ;)
[10:11] <braddr> all we need is a good boot to see it in the boot output
[10:15] <fabbione> it's hanging again
[10:15] <fabbione> waits a few secs..
[10:15] <braddr> wait.. is this the -10 kernel?
[10:15] <fabbione> -9
[10:15] <fabbione> we didn't boot 10 at all
[10:15] <braddr> ok.. just checking
[10:15] <braddr> this is the symptom we used to see with bootmem I tink.
[10:15] <fabbione> yeps it hangs
[10:16] <fabbione> probably because we are scraping the same page
[10:16] <fabbione> bootmem does basically clean all mem allocation
[10:16] <fabbione> oh neat
[10:17] <fabbione> sc> reset doesn't the trick without poweroff/poweron
[10:18] <fabbione> now i am booting with 8179 in kbytes
[10:18] <fabbione> just to make sure we are converting it properly
[10:18] <braddr> hrm.. my notes are insufficient
[10:18] <fabbione> and guess what.. we are not
[10:18] <braddr> try it in m again
[10:18] <fabbione> yeps
[10:19] <fabbione> actually
[10:19] <braddr> I was seeing this sort of boot hang with my hand built kernels, and I don't have enough notes on the differences.  I did get one of them too boot and I want to say that bootmem was one of the differences, but I'm not confident enough in that memory.
[10:19] <fabbione> i think mem is in bytes..
[10:19] <fabbione> let me check
[10:20] <braddr> it was definitly hanging to the point of needing to reset it
[10:20] <braddr> just append a k
[10:20] <braddr> remove the doubt
[10:21] <fabbione> mem=nn[KMG]
[10:21] <fabbione> it doesn't say the default
[10:21] <fabbione> so i guess it's bytes
[10:21] <fabbione> this is 8179m in k
[10:21] <fabbione> score
[10:23] <fabbione> so the last boots were just wrong
[10:23] <braddr> ok.. so there's insufficient checking for minimum memory somewhere in early bootup. :)
[10:23] <fabbione> 8375296 - 8376320
[10:23] <fabbione> 8375296 (8179) = good
[10:24] <fabbione> 8376320 (8180) = booting now....
[10:26] <fabbione> math is not an opinion in these cases ;)
[10:26] <braddr> sure sure.. but as I get older, I'm starting to believe more and more that hardware can be spiteful.
[10:26] <fabbione> hehe
[10:26] <fabbione> see.. boom
[10:27] <braddr> yup
[10:27] <fabbione> 8375808k (8179+512k) = booting now..
[10:28] <fabbione> ehhe
[10:28] <fabbione> yeah i will spend MAX another hour debugging
[10:28] <braddr> I was gonna grab a subway sandwich or something before the closed, but that was 90 minutes ago.. oops.
[10:28] <fabbione> it's sunday, i am tired and i want to get ready for the F1 race :P
[10:28] <fabbione> subway rocks!
[10:28] <braddr> they're not bad.. good for the sandwich category.
[10:29] <fabbione> yeps
[10:29] <braddr> back shortly
[10:29] <fabbione> sure
[10:30] <fabbione> bang
[10:30] <fabbione> new highmark :)
[10:30] <fabbione> lowmark= 8375296 (8179)
[10:30] <fabbione> highmark= 8375808k (8179+512k)
[10:34] <fabbione> 8375552 (8179+256k) = good
[10:38] <fabbione> 8375680 (8179+386k) = ahhhh new abort
[10:38] <fabbione> i think we got it
[10:39] <fabbione> that one just stops booting
[10:39] <fabbione> Booting Linux...
[10:39] <fabbione> Program terminated
[10:39] <fabbione> so it's hitting something
[10:42] <fabbione> the limit seems to be 8375552 (8179+256k) = good
[10:43] <fabbione> that + 128 = stops immediatly
[10:43] <fabbione> that + 64 = init the console and stops
[10:43] <fabbione> clearly we don't catch the hypervisor error that early in the boot
[10:44] <fabbione> bang bang
[10:44] <fabbione> we are there
[10:50] <fabbione> summary:
[10:50] <fabbione> from mem=1024m to mem=8375552k (8179m+256k) is all good.
[10:50] <fabbione> 8375552k + 32k  = hangs hard at Booting Linux...
[10:50] <fabbione> 8375552k + 64k  = init the console and abort "Program terminated"               8375552k + 128k = "Booting Linux...\nProgram terminated"
[10:50] <fabbione> 8375552k + 256k = as above
[10:50] <fabbione> 8375552k + 512k = boots but stops at the hypervisor error we knew about.
[10:50] <fabbione> i am switching to -10
[11:00] <fabbione> http://people.ubuntu.com/~fabbione/t2k-memboot-results.txt
[11:11] <fabbione> ok i am done for today :)
[11:12] <braddr> good progress
[11:12] <fabbione> i guess we are pretty close now
[11:12] <braddr> I look forward to hearing with davidm has to say about it
[11:13] <fabbione> yeah he went to sleep not too long ago
[11:13] <fabbione> so it will be not before tomorrow
[11:13] <fabbione> i think i will try booting the bootmem kernel on my machine to see the diff
[11:13] <fabbione> but later :)
[11:14] <braddr> have a good rest of the weekend
[11:14] <fabbione> thanks
[11:14] <fabbione> good night


[01:39] <leonel> ScottK: jdstrand Ok  I'll work on the big patch   today  been a  busy  day
[01:40] <leonel> ScottK: jdstrand  I'll ping  you when  it's done  but I'm busy  right now, I'll start ASAP
[01:46] <jdstrand> leonel: I wont be able to get to it until monday or tuesday, so no huge rush
[01:46] <jdstrand> leonel: thanks for your work on this! :)
[02:23] <jdstrand> dendrobates: no hangs in gutsy installer on hardy kvm
[02:24] <jdstrand> dendrobates: 7 installs completed.  I updated the bug accordingly
[02:28] <nxvl> jdstrand: i'm just installing a hardy box with alternate image
[02:28] <nxvl> jdstrand: did you need me to test something?
[02:51] <nxvl> jdstrand: on tty1 it seems to be still configuring cpio, but on tty4 it's installing several packages
[03:30] <jdstrand> nxvl: if you happen to see bug #217815, please add notes to the bug
[03:31] <nxvl> jdstrand: already did :D
[03:31] <nxvl> jdstrand: while there where happening
[03:32] <nxvl> alternate install on kvm is really slow
[03:32] <nxvl> i started almos 1 hour ago
[05:04] <rlanham> what is the command in terminal to tell what users are logged in?
[05:05] <bipolar> who
[05:06] <rlanham> I had a Root login warning email with an IP I did no recongize, is there anyone to see what was last done on the server?
[05:29] <ere4si> I've just setup my first cli server - but I want to run it headless and can't log in via ssh - can I set it up to auto login?
[05:30] <sommer> ere4si: did you install openssh-server?
[05:31] <ere4si> sommer: nope - will that let me login via ssh?
[05:31] <sommer> ere4si: heh, sure will... by default ubuntu only has ssh client installed
[05:32] <ere4si> sommer: thnx!
[05:32] <sommer> the theory being that not every admin may want ssh access
[05:32] <sommer> ere4si: np
[05:42] <ere4si> works like a charm - thnx again sommer
[05:42] <sommer> ere4si: heh, you're welcome
[05:52] <ere4si> how can i change tty's via ssh?
[05:55] <sommer> ere4si: I don't think there's is a literal way, but I usually just open anotehr ssh session
[05:56] <sommer> ere4si: you can also look into the screen command... does sorta the same thing, only better in some instances
[05:57] <ere4si> sommer: I think the extra ssh session should be all I need :) thnx
[05:58] <sommer> ere4si: np, if you're using gnome-terminal, konsole, or xfce-terminal you can just open another tab :)
[07:56] <buzzsaw> good evening
[07:57] <Jeeves_> Morning
[08:00] <buzzsaw> i was looking for information on how to configure my apache installed by LAMP do you by chance know of a tutorial on it?
[08:23] <LMJ> hello buzzsaw
[08:23] <LMJ> should like I can help you to configure your apache
[08:23] <LMJ> what you wanna do ?
[08:24] <LMJ> but there is also #apache who could be helpful, just in case
[08:34] <WaVeR> Morning ツ
[08:35] <LMJ> morning
[09:00] <buzzsaw> LMJ, i got it thanks :-)
[09:00] <buzzsaw> just got it figured out
[09:27] <Theo_> <?php
[09:27] <Theo_> $drive = $_POST['drive'];
[09:27] <Theo_> shell_exec('eject $drive');
[09:27] <Theo_> echo("$drive has been ejected.");
[09:27] <Theo_> ?>
[09:27] <Theo_> even if $drive is cdrom1 it always ejects cdrom. Why does it do this?
[13:28] <matrix> help me
[13:31] <Jeeves_> Hmm? :)
[13:35] <hubuntu_> is python support activated under installation?
[13:35] <hubuntu_> or is python at all available in the standard install?
[13:36] <hubuntu_> hardy server RC
[13:38] <Deeps> i believe so, as apt(itude) depends on it
[13:41] <hubuntu_> after the base system is installed it is available :)
[13:41] <hubuntu_> indeed
[13:42] <hubuntu_> thanks.. :)
[14:25] <hubuntu_> what package shall I use for netkit-inetd ? The BSD one or inetutils?
[14:26] <hubuntu_> I'm making a http://www.howtoforge.com/ubuntu_pxe_install_server
[14:27] <zul> bsd one
[14:28] <hubuntu_> thanx
[14:50] <hubuntu_> bsd is giving trouble.. what the difference within the 2 zul?
[14:52] <fromport> i've got the pxe setup working and am using the bsd version: openbsd-inetd
[14:55] <hubuntu_> I'll try again then..
[14:56] <hubuntu_> netstat -uap is not giving me: udp        0      0 *:tftp
[14:56] <hubuntu_> but: udp        0      0 *:bootp
[14:56] <hubuntu_> is that ok?
[14:57] <hubuntu_> with the bsd one I get both, with the internet one I get bootp and ip6 support for tftp...
[14:58] <fromport> # netstat -uap|grep tftp -> udp        0      0 *:tftp                  *:*                                 2835/inetd
[15:56]  * delcoyote hi
[16:43] <rlanham> morning everyone
[17:01]  * fromport goes for dinner ;-)
[18:17] <burzum> hi
[18:18] <burzum> Ive tried to compile php 5.2.5 on dapper because theres no new php version in the repo, at least it installed php5-cli but without the extensions... Ive tried to revert it by aptitude purge php5-cli and reinstall it but its still php 5.2.5 any ideas how to get the old version back?
[18:33] <theuser1> using g4l ghost for linux to make image file backup for my ext3 partition having the ubuntu os, error message i get is  unable to read from image block 0  ,       g4l uses   partiimage   and that uses  the dd comand i   think.....              any help?
[18:39] <theuser1> using g4l ghost for linux to make image file backup for my ext3 partition having the ubuntu os, error message i get is  unable to read from image block 0  ,       g4l uses   partiimage   and that uses  the dd comand i   think.....              any help?
[18:43] <theuser1>  can any one recomend an easy to use utilitiy that can make image of a partition for backup and can support compression?
[21:00] <nikku> hello.
[21:01] <nikku> join #ubuntu
[21:01] <nikku> crap.


[02:16] <craigbass76> When typing mythsetup in a command line, I get a command not found.  WHen in the initial screen, I see a General menu option, but not a capture card option.  Am I up the creek?
[02:17] <craigbass76> Wondering if there's a config file I can edit instead, since I guess Mythbuntu didn't detect my card.
[02:20] <Patrickdk> there is no config file
[02:20] <Patrickdk> there is no mythsetup
[02:20] <Patrickdk> there is a mythtv-setup
[02:22] <craigbass76> Aha...


[12:17] <dandrader> bregma, can I assume that a GeisTouch will have the same ID as its XInput2 counterpart?
[12:37] <bregma> dandrader, I can't guarantee it, the GEIS touchId is the same as the Frame touchId but I can't guarantee that's transitive with the X touchId
[12:46] <Satoris> I have to leave early, but today I have been refactoring and adding tests to the secret project.
[12:50] <bregma> ah, Friday
[12:51]  * bregma thinks about making an espresso to fill his empty cup
[14:15] <tvoss> chromium patch love, utouch-frame backend work, secret project
[14:15] <bregma> before I bring up some dbus-backend tests for geis I'm trying to figure out a nice way to simplify existing tests, they're a bit of a pain
[14:16]  * tvoss notices that bregma didn't have a coffee for standus today
[14:16] <dandrader> Finished mocking up Xlib and XInput2 for utouch-geis testing. Works beautifully. Now I've started to tidy up things and write the actual regression test for https://bugs.launchpad.net/bugs/984069
[14:17] <tvoss> dandrader, do you have the mocks reusable or are they tightly integrated with geis?
[14:17]  * bregma swirls the dregs of a fine melange spice coffee from Arrakis
[14:18] <dandrader> tvoss, they're reusable, but made for geis needs
[14:18] <bregma> I hope they're reusable so they can be used with frame and grail tests
[14:18] <dandrader> so they're not mocking up all of Xlib
[14:18] <dandrader> just what geis and frame uses
[14:18] <tvoss> dandrader, ack .. will take a look at it then
[14:18] <tvoss> dandrader, might have questions though :)
[14:19] <tvoss> cnd, standup?
[14:19] <cnd> right, thanks :)
[14:19] <dandrader> bregma, grail tests could use the utouch-frame generic backend that tvoss is cooking up as well
[14:19]  * bregma passes cnd some spice coffee to help his eyes open
[14:19] <cnd> I'm going to fix up the geis deltas patch, then look for more bugs to work on
[14:26] <cnd> bregma, dandrader: reviews of the xorg-gtest patches would be appreciated :)
[14:26] <dandrader> cnd, about that x11 mock up project that you mentioned the other day. The one that Robert Ancell started. Seems to be an absolute overkill for our needs. https://launchpad.net/xig
[14:27] <cnd> dandrader, overkill isn't necessarily a bad thing
[14:28] <dandrader> I didn't spend enough time to understand it properly. but seems quite complex
[14:29] <cnd> dandrader, are you trying to say that you think it's not designed well, and we shouldn't integrate with it?
[14:29] <cnd> or?
[14:36] <dandrader> cnd, Can't really tell right now as I didn't spend enough time to understand it properly. It's just my feeling against adding more complexity than needed. the mocking I did is pretty simple and it's sufficient.
[14:37] <dandrader> most functions are empty implementations
[14:37] <cnd> dandrader, the tradeoff is that we might end up reimplementing similar things multiple times
[14:37] <cnd> I'm a big fan of reuse and extending existing projects
[14:39] <cnd> dandrader, I'd feel better if you have concrete reasons why we shouldn't integrate with xig
[14:39] <cnd> we could then give feedback to robert too
[14:39] <bregma> for a proper mock Xlib I would want to be able to capture real X events to a file and be able to send them through the mock object to reproduce operations in a controlled way
[14:40] <cnd> bregma, that would be rather difficult
[14:40] <bregma> I'm just sayin' that's what I would want
[14:40] <cnd> because of things like window IDs
[14:40] <cnd> at a certain point, you're better off using the real implementation
[14:41] <cnd> dandrader, would you mind doing a more in depth look at xig and writing up your conclusions?
[14:42] <bregma> is that project on lp?
[14:42] <cnd> bregma, xig?
[14:42] <cnd> https://launchpad.net/xig
[14:42] <bregma> super, thanks
[14:42] <dandrader> cnd, I can do it after I'm done with https://bugs.launchpad.net/bugs/984069
[14:43] <cnd> dandrader, will that require merging in your xi mocks?
[14:43] <dandrader> yes :)
[14:44] <cnd> ugh
[14:44] <cnd> I would rather we made full decisions up front about this
[14:45] <bregma> sounds like a good sprint-time discussion
[14:45] <cnd> dandrader, an xorg-gtest based test would get us over the hump for this specific bug
[14:45] <cnd> and then we can look more closely at the X mocks
[14:46] <dandrader> I would rather not use xorg-gtest for this. Besides, I have the mock ready right now.
[14:46] <dandrader> Why start it over with an xorg-gtest approach?
[14:46] <cnd> there's a real cost with multiple implementations of the same thing
[14:47] <dandrader> the mock is small, it's simple to remove it
[14:47] <cnd> dandrader, maybe we can work out a deal
[14:47] <cnd> we can merge your mock, but one of your tasks is to do a more formal look at xig
[14:48] <cnd> and either redevelop the mock in xig if it is suitable
[14:48] <cnd> or provide sufficient reasoning why we shouldn't
[14:48] <dandrader> there's a real cost in integration tests that are slow to run and are unreliable since they break easily because they depend on several external factors
[14:48] <cnd> all that can be fixed
[14:49] <cnd> even the slowness for the most part
[14:49] <cnd> the way we do the tests right now we insert delays where we don't "really" need them if we write the tests properly
[14:49] <dandrader> cnd, sure. your deal was my suggestion. dig into xig after I'm done with bug 984069
[14:50] <cnd> dandrader, let's aim to have things ready to discuss at the sprint
[14:50]  * bregma hates artificial delays
[14:50]  * bregma spent too many years doing realtime to have likes for usleep()
[14:51] <cnd> there's two places where we generally have delays in our tests:
[14:51] <cnd> device init waits
[14:51] <dandrader> cnd, to tell the truth I don't even know how to test bug 984069 with xorg-gtest. With the mock I send Xinput2 events with specific window and device coords. Then I can easily check which of the coords showed up on the other side, in Geis events
[14:51] <cnd> and polling for more events
[14:52] <cnd> dandrader, you can send a gesture event from a touchscreen evemu recording
[14:52] <cnd> and check that the coordinates match known good values
[14:52] <cnd> for the device waits, we can listen for XIHierarchyChanged events
[14:52] <cnd> instead of waiting X seconds
[14:53] <cnd> and for the polling for more events, we probably should just break the loop when we get the gesture end event we're looking for
[14:53] <bregma> most of what's in the geis integration tests is slapped together quickly so I could forcus on functionality rather than pukka tests
[14:53] <cnd> yeah
[14:53] <bregma> I am turning my attention to improving the tests today
[14:53] <cnd> I do the same in grail and frame though
[14:53] <cnd> it's not just you :)
[14:53] <bregma> because it is hurting me avery time I look at one
[14:54] <cnd> bregma, I'm beginning to think that xorg-gtest should have an event processor and dispatcher
[14:54] <cnd> so we don't reimplement the same event loop in every test
[14:54] <bregma> perhaps, but it will take some though to make it usefully generic
[14:54] <cnd> yeah
[14:54] <cnd> that's why I haven't done it yet :)
[14:55] <bregma> I would start by refactoring the geis tests to see if we can identify what can be further refactored upstream into xorg-gtest
[14:55] <cnd> yep
[14:55] <cnd> the other thing I might tackle today is that when the env shuts down we SIGTERM/SIGKILL the x server but we don't wait for it to actually die
[14:55] <cnd> I think this is causing race conditions in the geis tests
[14:56] <cnd> where the next test starts before the previous test is finished
[14:56] <bregma> I would think the OS should really take care of that sort of thing
[14:56] <bregma> perhaps the X server is a special case because of all the wacky external stuff it does
[14:57] <bregma> like all the DBus stuff it ssems to do (ever run strace -f on it?)
[14:58] <bregma> cnd, your comments on bzr/git sure poked a sore spot
[14:58] <cnd> there's a not insignificant amount of time between the server being sent SIGTERM and it actually completing shut down
[14:58] <cnd> yeah...
[14:59] <cnd> but it's inevitable, there are people ingrained on bzr and git
[14:59] <bregma> it's a religious issue for many
[14:59] <bregma> I was playing with git-bzr-ng yesterday....  sweet
[15:00] <cnd> yeah
[15:01] <cnd> bregma, the one from termie's github repo?
[15:01] <bregma> yes
[15:01] <bregma> it's not package for Debian or Ubuntu
[15:01] <cnd> it still has some rough edges though
[15:02] <cnd> but it definitely helps
[15:05] <cnd> bregma, if I want to listen for both drags and pinches, I create separate filters for them and add them to one subscription?
[15:08] <bregma> yes:  filter terms are ANDed, subscription filters are ORed
[15:08] <cnd> k
[15:08] <bregma> I repeat that to myself a lot because I always muck it up
[15:12] <cnd> bregma, what's the easiest way to determine what type of a gesture a geis 2 frame is?
[15:13] <cnd> it looks like it would be easy if I could get the gesture class of a frame
[15:13] <cnd> but that doesn't seem possible
[15:14] <bregma> the only way is to call geis_frame_is_class(), which means you need to remember all the classes as they are reported
[15:14] <cnd> bregma, should we be adding a geis_frame_get_class() call?
[15:15] <bregma> a frame can be classified more than one way
[15:15] <cnd> ahh
[15:16] <bregma> in theory there could be a ..._get_classes() call
[15:16] <cnd> if I have both a pinch and a drag going on for the same subscription, will I just get one set of frames?
[15:16] <bregma> that's the way it's supposed to work
[15:16] <cnd> ok
[15:17] <bregma> I believe it does work that way, but I don't think there's a test to prove it
[15:23] <bregma> dandrader, do you have a branch with your mock X available?
[15:25] <dandrader> bregma, lp:~dandrader/utouch-geis/lp984069
[15:28] <bregma> thanks -- I think you're right, this is exactly what we need, but I think it should be a completely separate project, it's got potential uses outside uTouch
[15:28] <bregma> that can be done later
[15:29] <bregma> xig wouldn't help use
[15:29] <bregma> *us*
[15:41] <cnd> bregma, why wouldn't xig help us?
[15:43] <bregma> as far as I can tell by reading the code, xig is a glib wrapper around Xlib that comes with a mock xserver
[15:44] <bregma> it would help us if we rewrote utouch to use gobjects
[15:45] <cnd> ok
[15:45] <bregma> we should maybe get Robert to join us for a chat at the sprint or at UDS, if he's not busy, and share
[15:46] <cnd> yeah
[15:46] <bregma> or maybe the whole idea of a mock xlib is worthy of a session at UDS?
[15:46] <cnd> I worry a bit about creating lots of test frameworks for X, when we might move off it soonish
[15:46]  * bregma backs away slowly from a project that could consume small cities
[15:47] <cnd> yeah, that's my concern too
[15:48] <cnd> I do sort of feel the need for a mock is lessened if we make the integration tests work well
[15:49] <bregma> is there some way we could change evemu so it doesn't need root privs?
[15:49] <cnd> yes, it's actually quite easy
[15:49] <cnd> however, it's quite the security hole
[15:50] <cnd> bregma, put this: http://paste.ubuntu.com/938453/ in /etc/udev/rules.d/99-user-input.rules
[15:50] <cnd> and change the group to whatever makes sense for you
[15:51] <cnd> then restart
[15:51] <cnd> or chmod/chown the files for the current session
[15:52] <cnd> with that and the fix currently in upstream xorg-gtest master you can run tests as the normal user without having to switch to a VT
[15:53] <cnd> biab
[16:53] <cnd> bregma, with the xorg-gtest patch I just sent out, I'm able to run through a full geis test suite without issue
[16:55] <bregma> I'll test it out locally -- do you need a reviewed-by or anything?
[16:56] <cnd> yes
[16:56] <cnd> for all four patches sent to the list
[16:56] <bregma> righty-o
[16:56] <cnd> thanks
[16:57] <cnd> I wish there was a version of the wait* syscalls that took a timeout value
[16:57] <cnd> it seems silly that there isn't
[16:58] <cnd> and registering a signal handler for SIGCHLD in a library seems bad
[16:59] <bregma> well, having a mainline in a library is a bit unusual, too
[16:59] <cnd> bregma, you mean having main()?
[16:59] <cnd> it's optional, so you don't have to use it if you don't want
[16:59] <bregma> I knwo, but it's weird to me
[16:59] <cnd> yeah
[16:59] <cnd> but it does make things easier
[17:00] <bregma> that's why SDL does it on windows
[17:00] <bregma> just, you know, a data point
[17:15] <cnd> bregma, with some simple changes we can drop the geis2 tests from over a minute to 18 seconds :)
[17:16] <cnd> http://paste.ubuntu.com/938581/
[17:44] <bregma> cnd, why do you think delta-radius should be geometric rather than arithmetic?  Doing it that way doesn't feel quite right on a touchscreen.
[17:44] <cnd> bregma, the radius value is geometric now
[17:45] <cnd> it feels right to me, too
[17:45] <cnd> when I pinch in unity
[17:46] <bregma> I mean geometric doesn;t feel right
[17:46] <bregma> then again, gestures no longer work in eog
[17:46] <bregma> I wonder when that happened
[17:46] <bregma> hmmmm
[17:46] <AlanBell> !ping
[17:47] <cnd> bug 986215
[17:47] <cnd> welcome lubotu3 :)
[17:47] <bregma> skynet is here
[17:48] <cnd> bregma, why does geometric not feel right?
[17:48] <cnd> we discussed this a while back
[17:48] <cnd> though on irc, where records are harder to find :(
[17:48] <bregma> it just doesn't feel... right
[17:48] <bregma> I guess it's just subjective
[17:49] <bregma> I don't recall any discussion on radius delta being geometric
[17:49] <bregma> actually, it feels right for touchpads
[17:49] <cnd> there's also hand size to take into account
[17:50] <cnd> which geometric handles inherently
[17:50] <AlanBell> !ping
[17:51] <AlanBell> quick botswap, I sent the wrong one in
[17:51] <bregma> perhaps it's mostly a matter of training, geometric is not broken, just not how I expect it to behave on a touchscreen
[17:51] <bregma> I admit it's really really subjective
[17:52] <cnd> the problem is if you have arithmetric, you'll have to do thresholds that are based on each individual device size
[17:52] <cnd> and resolution
[17:52] <bregma> very true
[17:52] <cnd> and some devices can't provide accurate values for both :)
[17:53] <bregma> yes, pain is to be had there
[17:53] <cnd> I honestly felt like the pinch threshold in unity before this change was good for the magic trackpad
[17:53] <cnd> but too high for the touchscreen
[17:53] <cnd> I had to really work to trigger it on behemoth
[17:53] <cnd> now it feels much more natural on both
[17:54] <cnd> it was also near impossible on my netbook, but now it is impossible because my netbook is only semi-mt :(
[17:56] <bregma> well, it's not really that big of a deal for me and perhaps if necessary in the future we can make this a tuning point
[17:56] <cnd> yeah
[18:11] <cnd> ubotu
[18:11] <cnd> ubot5, ubotu
[18:11] <cnd> ubot5, es
[18:13] <cnd> !es
[18:13] <cnd> dandrader, just for you:
[18:13] <cnd> !pt
[18:14] <cnd> ubot5, thanks!
[18:14] <dandrader> :)
[19:56] <dandrader> what's the problem people have with resubmitting a proposal? for me it's the most natural way to do precisely that. otherwise verdicts for an earlier version of the path (like "needs fixing") will still list there
[19:57] <dandrader> s/path/patch
[20:03] <cnd> dandrader, earlier reviews can be overwritten by later reviews, and the log tells you what has changed over time
[20:03] <cnd> the problem with resubmissions is that the interleaving of the code and the reviews are lost
[20:04] <cnd> but I don't know how to best handle the situation where you add new stuff to an existing approved proposal
[20:06] <cnd> dandrader, can you provide more detail on why a gtest test won't work for your geis proposal?
[20:06] <cnd> I don't understand why it can't be used
[20:07] <dandrader> cnd, it can be used. but I would have to disentangle it from xorg-gtest and the optional compilation of integration tests
[20:07] <cnd> dandrader, I think we should do that then
[20:08] <cnd> gtest is supposed to be the "preferred" testing framework for product strategy
[20:08] <dandrader> sure. I was just too lazy to fight with autotools to do that disentanglement work. :)
[20:09] <cnd> heh
[20:12] <dandrader> was reading canonical-tech mailing list. about the bzr situation: it's a bittersweet feeling. It's sad to see a project being ramped down but it's great to see that Git is eventually coming on board :)
[20:13] <dandrader> oops
[20:21] <cnd> hmm... google mock is really c++ only
[20:22] <cnd> maybe keeping the xinput mock simple and hand made is best
[20:22] <cnd> dandrader, I'm wondering if we should do something a bit fancy:
[20:22] <cnd> make the mock optionally take evemu recordings
[20:22] <cnd> and generate xinput events from them
[20:23] <cnd> at compile/runtime we could then switch between integration and unit testing
[20:23] <cnd> well, integration with the kernel and X server vs just everything above the X server
[20:25] <isforinsects> Are there any tests it would be helpful for me to run on a macbook4,2 for 12.04?
[20:26] <dandrader> cnd,  what do you mean exactly by "making the mock optionally take evemu recordings". It will read the recordings and produce XInput2 events out of them, thus still doing everything in the same process?
[20:27] <dandrader> (probably not but one can always hope)
[20:27] <cnd> yes, that's what I mean
[20:27] <dandrader> awesome!
[20:27] <cnd> it means adding a lot of code to the mock
[20:27] <cnd> but it would mean we no longer depend on a kernel and X server unless we want to
[20:28] <cnd> isforinsects, you can verify that the unity gestures are working: https://wiki.ubuntu.com/Multitouch#Supported_Gestures
[20:32] <dandrader> google mock also reallies heavily in classes having mostly virtual methods (if I'm not mistaken) for the mocking magic to work. I really don't like that requirement
[20:33] <cnd> yeah, I think I remember tvoss saying he looked at it too, and it wouldn't work for the utouch stuff
[20:33] <isforinsects> cnd: Checked them out, and they are supported. Are those configurable anywhere?
[20:33] <cnd> isforinsects, no
[20:33] <cnd> hopefully they don't need any configuration :)
[20:36] <isforinsects> That's an odd opinion. None of these are things that I find useful. I respect that your opinion might be the majority. but I can imagine that no one else wants desktop pagination, app switching, or tab switching as gestures
[20:36] <cnd> isforinsects, oh, do you mean configurable as to what gesture corresponds to what action?
[20:37] <cnd> the answer is still that it's not configurable, but really that's a Unity issue
[20:37] <cnd> a design issue
[20:37] <isforinsects> Oh yeah. If you meant what delta values trigger things, I completely trust other's judgement in that.
[20:37] <cnd> ok
[20:37] <isforinsects> I've built unity before, do you know where they're defined in the code?
[20:39] <cnd> isforinsects, we are basically implementing the unity multitouch specification: https://docs.google.com/a/canonical.com/Doc?docid=0AU5sFuLRpCpBZGZra2pqY2pfMTU3MmhwbXczcWQ1
[20:39] <cnd> if you have input on the designs, and whether there should be configurability, then you will want to ask the unity and/or design team
[20:39] <cnd> there's a mailing list for it
[20:39] <cnd> the problem is there are lots of lists and I don't know which is correct :)
[20:40] <cnd> dandrader is the person working on implementing them though
[20:40] <cnd> looks like he just left for the day
[22:21] <bregma> cnd, do you have a xorg-gtest repo with your patches already applied (they're not in http://cgit.freedesktop.org/~cndougla/xorg-gtest)?
[22:21] <bregma> or is the daily PPA up-to-date with the patches already applied?
[22:33] <cnd> oh, I haven't pushed them to my repo
[22:33] <cnd> I'll do that right now
[22:33] <cnd> bregma, pushed
[22:33] <cnd> they're in the fixes branch
[22:35] <bregma> thanks
[22:41] <bregma> well, I still seem to need the delay in the StartUp() function because the server isn't always ready when I am
[22:53] <cnd> bregma, do you mean in the fixture SetUp methods?
[22:55] <cnd> if so, what's the output you get
[22:55] <cnd> the xorg-gtest environment setup should have waited until a client can open the connection to it
[23:03] <bregma> I get tests randomly failing without it, not sure why without deeper delving
[23:03] <bregma> if I run each test standalone, it passes
[23:04] <bregma> I'll dig deeper
[23:07] <cnd> I'm upgrading my transformer and will test there too
[23:07] <cnd> if you need a slow machine to cause problems, it should be slow enough :)
[23:52] <bregma> heh, the problem seems to be the evemu file creation is taking a long time, it has nothing to do with the X server startup
[23:53] <bregma> fortunately, the solution to that is pretty obvious
[23:54] <bregma> .. XIHierarchyChanged events


[02:02] <Kentrel> Is Aptitude a better tool to fix messed up packages. It's offering me solutions. Should I take them?
[02:18] <Frim> I ran the self test, and it said that the disc was ok.  Is there a way to install Ubuntu 12.10 without the language packs?
[02:26] <Frim> 	I ran the self test, and it said that the disc was ok. Is there a way to install Ubuntu 12.10 without the language packs?
[04:41] <holstein> Frim: sure.. just dont install the language packs
[04:41] <holstein> or, install and remove what you dont want
[04:42] <holstein> Frim: i usually just install, and select *not* to install updates or anything extra during the install process
[04:42] <holstein> just install from the disc, and then after install i get languge packs or codecs or upgrades
[05:38] <Gone> thanks..I'll try that
[14:31] <JonEdney> Hey everyone.  I have /home and / on seperate partitions.  If I put the 12.10 CD back in to re-install, and select reformat for / but not /home, would that reinstall 12.10, but leave my homedir alone?
[17:22] <scribawf> Facebook fails to run games need update for flash but have latest, any help on this? Please


[00:07] <Somebody> Hi. I'm trying to install a program that has the installer for linux but when I try to opens I get this message: Oracle JRE 8 update 11 or later to run application. Please manually update java and ensure it is the first java available in your system patch
[00:08] <Somebody> I have been trying to install but when I got to my terminal I get this: El paquete «oracle-java12-installer» no tiene un candidato para la instalación
[00:08] <Somebody> Any suggestions to fixed that?
[00:09] <Somebody> I am Using UbuntuStudio 19.10
[00:19] <Somebody> This works: sudo apt install openjdk-12-jre I was trying 11. Thanks
[12:33] <tarzeau> trebmuh: do you have an idea how ubuntu studio would add stuff cheesecutter, protracker, fasttracker2 ?
[12:33] <tarzeau> are there plans to add olive-editor and flowblade (video section)?
[12:33] <tarzeau> hiveltyracker, klystrack, bambootracker also are missing i guess?
[12:34] <tarzeau> and grafx2 (fun to see pikopixel.app added though)
[12:34] <tarzeau> and cenon.app not
[12:34] <tarzeau> any chance to get fonts-league-spartan and fonts-inter added? (among i've got a bunch of other great fonts)
[12:35] <tarzeau> tutka ?
[12:41] <trebmuh> no idea at all
[14:35] <bliter> Milkytracker
[14:42] <bliter> Deluxepaint code source are available ^^ https://computerhistory.org/blogs/deluxepaint-computer-history-museum-software-license-agreement/
[15:34] <bliter> Hivelytracker 1.8 available on AROS ^^
[15:54] <Eickmeyer> bliter: What are you going on about?
[15:55] <Eickmeyer> tarzeau: trebmuh isn't involved in the project anymore, and hasn't been for some time.
[15:55] <Eickmeyer> Though, he's welcome to return if he wants. ;)
[15:58] <Eickmeyer> bliter: I meant to tell you this earlier, but you weren't around: Just because something is open source does not mean it can be added to Ubuntu Studio. 1) We don't have the manpower to package everything, and 2) the product licence MUST be compatible with GPL.
[15:58] <Eickmeyer> bliter: Additionally this is the absolute wrong way to request these things. Please use the mailing list for such discussion. Thank you.
[15:59] <Eickmeyer> !support
[15:59] <Eickmeyer> what the...
[15:59] <Eickmeyer> !offtopic
[16:00] <bliter> I just share some ideas, information, some software from other platforms would have their place on Ubuntu Studio, and it lacks others ... style, a manager, editor of SYSEX for synthesizers ...
[16:00] <bliter> Ah, ok...
[16:01] <Eickmeyer> bliter: Then use the mailing list. We can't add anything that is incompatible with the GPL, and we lack the manpower to package everything you're requesting. I've checked the licenses, on those, and while they are open source, they are not compatible with the GPL.
[16:01] <Eickmeyer> bliter: Also, I'm leery of increasing the ISO size.
[16:02] <bliter> thank you very much for guiding me on the right track
[16:02] <Eickmeyer> bliter: You're welcome.
[16:43] <trebmuh> Eickmeyer, to be precise, I've have never been directly
[16:53] <Eickmeyer> trebmuh: Ah.
[22:47] <bee94> hello