[01:14] <IntuitiveNipple> Is there a tool on end-user (not developer/build) PCs to determine the package architecture in use (i386/amd64/ppc) ?
[01:24] <crimsun> IntuitiveNipple: do you mean a friendly version of dpkg --print-architecture?
[01:24] <IntuitiveNipple> Yes. I kinda found a way: ARCH=$(apt-get -v | head -n1 | cut -d" " -f 4)
[01:24] <crimsun> err, I don't know if I'd recommend the latter over the former ;-)
[01:25] <IntuitiveNipple> Something that will 'just work' on a user PC that hasn't had dev tools installesd
[01:25] <crimsun> well, dpkg will always work if it's a standard Ubuntu system.
[01:25] <IntuitiveNipple> It's only for some instructions for a bug report for users to download a correct .deb from a PPA
[01:25] <crimsun> (and pretty much Debian, too)
[01:25] <crimsun> is the Ubuntu release at least 9.10?
[01:26] <crimsun> if so, why not just recommend using add-apt-repository?
[01:26] <IntuitiveNipple> To avoid adding the PPA to apt sources since there's *lots* in there, I'm just giving some instructions including some 'wget ...' lines and wanted to ensure they're generic
[01:27] <crimsun> I'm not sure why you would recommend doing that instead of getting the necessary package into the repo proper
[01:28] <IntuitiveNipple> Because it is for testing, and the package I've put in my PPA is in the process of going into the repos. It's on Debian mentors right now
[01:28] <crimsun> what is the oldest supported Ubuntu version for your target package?
[01:28] <IntuitiveNipple> Lucid
[01:29] <crimsun> really, it makes more sense to use dpkg --print-architecture
[01:29] <crimsun> that is its function, after all
[01:30] <IntuitiveNipple> Oh kick me! I was misreading 'dpkg' as one of the dev tools, not the generally available tool, doh *blush*
[01:30] <IntuitiveNipple> yeah, so, that'd work :p
[01:30] <IntuitiveNipple> I knew I'd done it before but couldn't find it when I needed it
[06:40] <wzssyqa> how pbuilder use packages in /var/cache/result as rep?
[08:55] <desrt> is it too late to have a new package pulled from debian for lucid?
[08:56] <desrt> http://packages.debian.org/source/sid/zeromq
[09:21] <geser> desrt: yes (unless you have a really good reason to get an exception)
[10:24]  * sebner giggles at Maverick Meerkat
[13:40] <ScottK> LucidFox: Are you using the quassel Qt packages on Lucid?
[13:43] <ScottK> Is there anyone that cares about evolution-mapi, it looks like it may have to be removed from Lucid.
[13:44] <LucidFox> ScottK> No, I don't have them installed
[13:44] <ScottK> OK.
[13:47] <LucidFox> What's the matter?
[13:53] <ScottK> LucidFox:  bug 553906
[15:24] <ari-tczew> please sponsor bug 262235
[16:04] <ari-tczew> bdrung: thanks for sponsoring obexd, could you get sponsorship @ bug 262235 as well?
[16:15] <bdrung> ari-tczew: please add the required information to both of these bugs.
[16:21] <bdrung> ari-tczew: borked date
[16:21] <bdrung> Sat, Sun
[16:21] <cnd> I've got a fix for a gnome-settings-daemon bug (bug 484186), I've linked to a branch, but when I go to nominate it for a release it says there's no release manager
[16:22] <cnd> is this the right approach?
[16:24] <bdrung> cnd: you don't nominate a bug for the development release. nomination is for stable release updates.
[16:24] <cnd> bdrung: ok
[16:30] <dutchie> Hi, I'm looking at fixing bug 541951 by applying the supplied patch, but I'm not sure how to deal with the .tar.bz file in lp:ubuntu/firefox. Could anybody point me in the right direction?
[16:31] <micahg> dutchie: I think this is being discussed in #ubuntu-mozillateam ATM
[16:31] <dutchie> oh, does that exist?
[16:31] <dutchie> I'll go and ask there
[16:31] <ari-tczew> bdrung: so do I need to reupload revision?
[16:32] <bdrung> ari-tczew: yes, would be nice
[16:33] <ari-tczew> bdrung: after this, do you will upload?
[16:34] <bdrung> ari-tczew: i will check it and probably upload it
[17:09] <ari-tczew> bdrung: reuploaded
[17:29] <bdrung> ari-tczew: you could push a new revision instead of reuploading
[17:31] <ari-tczew> bdrung: I asked: reupload? you: yes...
[17:31] <bdrung> ari-tczew: "upload" interpreted as general term. ;)
[17:32] <bdrung> but anyway
[17:36] <bdrung> ari-tczew: done
[17:38] <ari-tczew> thanks
[18:23] <AJ_> Hello
[18:24] <AJ_> I need to know how do I get the Ubuntu package manager to know that a new version to my software is available and it needs to update it
[18:26] <AJ_> Is there something i need to specify in my debian package
[18:26] <AJ_> ???
[18:27] <nigelb> no
[18:28] <AJ_> So I have a debian package which can be downloaded and installed
[18:28] <nigelb> is it going to be in ubuntu/debian or in a ppa?
[18:30] <AJ_> its on a website
[18:30] <AJ_> just like google chrome
[18:30] <nigelb> as a deb?
[18:30] <AJ_> yes
[18:31] <nigelb> in that case, you cannot have package manager show that there is a new version, sorry
[18:33] <AJ_> So how does google chrome does it
[18:33] <AJ_> ??
[18:33] <nigelb> I haven't tried, so I dunno.  probably someone else knows the answer
[18:34] <AJ_> Doe anyone know the answer
[18:35] <azeem> AJ_: google chrome just checks back with google whether there's a new version I guess
[18:37] <AJ_> But i can see google chrome on synaptic package manager listing
[18:37] <AJ_> so this means package manager checks to see if a new version is available
[18:38] <nigelb> package manager checks only if a line is added to your sources.list file
[18:39] <azeem> AJ_: do you have a special chrome APT repository activated in synaptic?
[18:40] <AJ_> How do I check that
[18:43] <AJ_> so when i open synaptic package manager and i search for chrome it gives me a list entry with google-chrome-beta   installed-version        current -version         description
[18:44] <nigelb> AJ_, go to system > Administration > software sources
[18:44] <nigelb> in the second tab, see if there are more than 2 lines
[18:45] <AJ_> yes there is a google listing available there
[18:45] <nigelb> ah, so thats how you get updates to chrome via package manager
[18:45] <nigelb> you need to have an apt repository
[18:45] <AJ_> aha
[18:46] <AJ_> how do i manage to do that
[18:46] <azeem> as a user or as a developer?
[18:46] <AJ_> having an apt repository for my application
[18:46] <azeem> it's probably easiest to have a PPA
[18:46] <AJ_> as a developer
[18:46] <azeem> and publish/advertise it to your users
[18:46] <nigelb> +1 to the PPA suggestion
[18:47] <AJ_> ok
[18:47] <AJ_> is there a good tutorial available for setting up PPA
[18:47] <nigelb> help.launchpad.net should have some
[18:48] <AJ_> ok
[18:48] <AJ_> will check it out
[18:48] <AJ_> thanks a ton guys for ur help
[18:49] <jcastro> AJ_: the chrome deb works by dropping a google sources.list in /etc/apr/sources.list.d
[18:50] <jcastro> that should bet /etc/apt I mean
[18:50] <nigelb> jcastro, yeah, thats what we figured out too.  He's going to set up a PPA for his app :)
[19:40] <stevecrozz> what's the name of that tool that helps you update debian/control?
[19:41] <nigelbabu> stevecrozz, what do you want to update?
[19:41] <stevecrozz> nigelbabu: I'm building an experimental package from an existing one, i was going to add a dependency for one thing
[19:42] <nigelbabu> stevecrozz, no, I meant what do you want to update in debian/control..
[19:42] <stevecrozz> the dependencies
[19:43] <nigelbabu> ah, you have to do that manually I guess
[19:43] <stevecrozz> nigelbabu: ok, what about the changelog? isn't there a util for that?
[19:44] <nigelbabu> dch -i
[19:44] <stevecrozz> ah that's right, thanks
[19:44] <nigelbabu> and to update maintainer 'update-maintainer'
[19:53] <stevecrozz> nigelbabu: I'm updating nginx to add http://projects.unbit.it/uwsgi/wiki/RunOnNginx
[19:54] <stevecrozz> so I need to add a new line to debian/rules, which needs to reference uwsgi
[19:54] <stevecrozz> do I need to build a package for uWSGI also? or should I just copy the uWSGI source files into the nginx source folder?
[19:55] <nigelbabu> stevecrozz, sorry, I don't know enough to help you.. hang around and see if others can help
[21:47] <mcurrington> Hello. Who maintains the package irssi? In apt-cache show it tells me "Ubuntu Core Developers"
[21:49] <ScottK> That would be who it is.  In Ubuntu almost all packages are team maintained
[21:49] <arand> mcurrington: "aptitude changelog irssi" and see who does the most changing?
[21:50] <mcurrington> Thanks
[22:42] <stevecrozz> after uploading a package with dput is there anything special I need to do to get the builder to build it?
[22:44] <chrisccoulson> stevecrozz, no, as long as it was accepted
[23:46] <sistpoty> Laney: mind taking a look at bug #550191? Especially if we should follow debian and drop haskell support on ia64
[23:49] <Laney> sistpoty: you can fix that by syncing hmake
[23:50] <Laney> assuming it builds
[23:50] <sistpoty> Laney: *nod*, haven't checked it yet, still on my list ;)
[23:54] <Laney> sistpoty: I should look at the remaining packages
[23:54] <Laney> we are close now
[23:54] <Laney> I saw your bugs about the doc package renaming not providing an upload path, that's disappointing
[23:55] <Laney> s/upload/upgrade/
[23:56] <sistpoty> Laney: actually I only found that out since that lead to a FTBFS in ubuntu... the arch:all package with the old name was still available and got drawn in, however it had a versioned dep on haddock that couldn't get fulfilled
[23:56] <Laney> urgh
[23:57] <sistpoty> Laney: I don't think the upgrade path is too much of a problem though, it'll only mean that the new -doc package won't get upgraded to, however it doesn't result in installation failures
[23:57] <Laney> sistpoty: Yes, it's not a big problem, just a bit careless.
[23:57] <sistpoty> well, things happen, like /me preparing an upload before dinner, uploading it after dinner and forgetting to change anything but changelog :)
[23:58] <Laney> haha
[23:58] <Laney> I wonder when pandoc will be finished
[23:58] <sistpoty> yeah, it's starting to get late for lucid


[14:12] <X-warrior> I have this file http://pastebin.com/XvGs8NZp in one server it works, but in another it doesn't.  But if I execute the script part by hand... it works. Ideas on what could be the problem?


[06:57] <MTecknology> wow.. it's unreal how busy the kernel ML is
[07:22] <amitk> MTecknology: lkml?
[07:33] <MTecknology> amitk: on lists.ubuntu.com
[07:33] <MTecknology> amitk: and the bugs running through ~ubuntu-kernel-team
[07:35] <amitk> yeah, it has certainly grown over time
[07:37] <MTecknology> I decided to hop out of ~ubuntu-kernel-team and hop into teams that are more specific to my interest - probably not a big deal considering the lack of involvement I've had.
[07:38] <MTecknology> I aimed too high - tried to do too much stuff - and now I have simple projects that are over a year old and still unreleased :(
[07:40] <MTecknology> ok.. nappy time
[08:24] <apw> drew212, yes if your touchpad is missing a bug is needed
[08:28] <ikepanhc> apw: about bug 634702
[08:28] <ubot2> Launchpad bug 634702 in linux (Ubuntu) "Kernel 2.6.35-19 fails to boot Lenovo S10-3 (affects: 1) (heat: 8)" [Critical,In progress] https://launchpad.net/bugs/634702
[08:29] <ikepanhc> I believe the new module intel_idle is the root cause
[08:29] <apw> ikepanhc, interesting
[08:29] <ikepanhc> but dont know much about the module, any idea who we shall ask?
[08:30] <smb> I guess it would be something to bring up on the acpi mailing list
[08:30] <ikepanhc> The S10-3 use N450 as CPU
[08:30] <smb> Maybe cc Len Brown
[08:30] <apw> well if we have proven its the cause, like via black-listing, then acpi list sounds good, and the authors of course
[08:30] <smb> good morning btw... :)
[08:31] <apw> moin
[08:31] <ikepanhc> good morning .eu :)
[08:31] <ikepanhc> will write to Len Brown
[08:31] <ikepanhc> you guys have any N450 machine?
[08:31] <smb> ikepanhc, But don't forget linux-acpi, I want to watch the thread. ::)
[08:31] <apw> ikepanhc, i would email the authors of the commit which adds it
[08:32] <apw> cc: acpi and len, its the authors who are most likely to have a clue
[08:32] <ikepanhc> I wonder it happens on all N450 machine or only S10-3
[08:32] <smb> Hm, No I only have old 270s
[08:32] <apw> ikepanhc, i would not be supprised if it is all, perhaps a search for those symptoms may help
[09:16] <kengyu> ikepanhc, iirc, samos is N450?
[09:47] <jmg> hi all
[09:47] <jmg> i need to do an instruction trace on the kernel
[09:48] <jmg> what debugger should i use?
[09:48] <jmg> kdb and kgdb dont seem to be in the repos
[10:02] <jmg> hmm
[10:02] <jmg> hi balbir
[10:20] <balbir> jmg: hi
[10:21] <jk-> jmg: what are you looking to do?
[10:21] <jk-> (ie, what would you like to trace? or do you want to step through a particular function?)
[10:21] <jmg> get an instruction trace for usb-storage operations
[10:22] <jmg> so i can figure out what instructions to use in a tool im writing
[10:23] <jmg> the instruction trace for overwriting a file would get me a long way
[10:23] <apw> sounds like you want a usb trace more than an instruction trace
[10:24] <jmg> i cant read usb
[10:24] <jmg> if i could, that would help
[10:29] <apw> there is some way to trace usb traffic
[10:29] <jmg> yeah i saw it
[10:29] <jmg> debugfs
[10:29] <smb> https://wiki.ubuntu.com/Kernel/Debugging/USB
[10:30] <TeTeT> are there any known USB problems in the Lucid kernel, especially on T61/x61? A customer reports problems on 3G (USB), printers (USB) and wonders if there's a known issue
[10:31] <smb> TeTeT, Vaguely known at most. I think I remember some reports but not really details
[10:31] <smb> And it depends an "problems"
[10:31] <smb> problem not being detected at all or traffic problems
[10:32] <TeTeT> smb: problem as in arbitrarily happening losses of devices, e.g. 3g no longer working, printing not possible
[10:33] <TeTeT> smb: I try to get more details from the customer, but they have themselves problems collecting detailed information from the field
[10:35] <smb> TeTeT, Those rather not known and may be device specific or not. Can you make sure problems are reported for each device (if it is not something like all usb traffic is broken after some time)
[10:35] <TeTeT> smb: yes, will file bug reports as soon as I get enough details
[10:37] <jmg> ok the usb trace
[10:37] <RAOF> Hm.  How can I work out what's the most recent commit in the drm-intel kernel PPA build?
[10:39] <RAOF> Or, more specifically, how can I tell whether the commits that should fix bug #600453 have landed in there.
[10:39] <ubot2> Launchpad bug 600453 in linux (Ubuntu) "[arrandale] [i915] DELL E6510: blank screen on boot (Intel GPU) (affects: 16) (heat: 143)" [High,Confirmed] https://launchpad.net/bugs/600453
[10:42] <jmg> i cant read it :(
[10:44] <apw> RAOF, there is a COMMIT file in the newer result directories which have the commit id which was built
[10:45] <apw> RAOF, the latest build is in 'current' always
[10:45] <cking> apw, where is the list of current kernel team bugs for maverick?
[10:47] <smb> cking, https://wiki.ubuntu.com/Kernel/Tagging
[10:49] <jmg> f***ing usb, how does it work?
[10:56] <apw> jmg, heh now that is is a big question
[10:56] <smb> jmg, Have you looked at the link I posted?
[10:56] <apw> not sure what you think you'll find from an instruction level trace thats going to be easier to understand
[10:56] <smb> (assuming you have problems getting the trace)
[10:56] <apw> i thought there was a library for interacting with usb devices
[10:57] <apw> libusb i think is the one, perhaps that would have documentation too
[11:03] <jmg> smb: yes
[11:05] <jmg> libusb is what i will use to write my tool
[11:05] <jmg> one i know what to send
[11:06] <jmg> once*
[11:08] <jmg> maybe i should just read the usbms spec heh
[11:21] <apw> cking, bouncy?
[11:50] <apw> mjg59`, just saw your backlight writeup, has the kernel side stuff hit mainline>
[11:50] <apw> (it sounds like a very sane approach to the moras)
[12:16]  * apw lunches
[12:33] <mjg59`> apw: Not yet
[12:51]  * smb is back
[12:54] <apw> mjg59`, ta for the info, very interesting none the less
[12:59] <DrKenobi> Hi! I'm looking the log of the meeting about bug triage of last Saturday. Where can I find it?
[13:03] <smb> http://irclogs.ubuntu.com/2010/09/11/%23ubuntu-classroom.html
[13:03] <smb> DrKenobi, ^
[13:06] <DrKenobi> smb, thanks! great! I think it would be great to have this link at https://wiki.ubuntu.com/Kernel/BugTriage/Summit/Maverick It would be helpfull
[13:07] <smb> DrKenobi, I guess you will have the power to do that. ;-)
[13:08] <DrKenobi> I can? OK, I'll try. Just a basic question: this is automatically generated, or someone has to copy/paste?
[13:09] <smb> These are automatically generated daily by channel (I guess limited to ubuntu channels)
[13:10] <smb> This channel is there as well
[13:11] <DrKenobi> Great. I knew the chat the channels history (log?) was stored, but I never found it. Thanks.
[13:30] <mjg59`> apw: Needs to go through Richard Purdie's tree, and I think he's stuck in Portland at the moment
[13:49] <n1ght0wl> hey guys.
[13:50] <n1ght0wl> i saw strange kernel oopses with maverick kernel tag 2.6.35-20.29 from ubuntu-maverick repository built on ubuntu-lucid on x86_64.
[13:50] <n1ght0wl> kernel oops can be achived by running lshw command which in most cases hangs and cannot be killed using kill -9.
[13:53] <apw> n1ght0wl, yes that one we know about, the fix should be in the -21.30 kernel when it hits the archive
[13:54] <n1ght0wl> apw: thanks.
[13:54] <n1ght0wl> apw: is there any url related to this problem?
[13:56] <n1ght0wl> is this it?
[13:56] <n1ght0wl> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636679
[13:56] <ubot2> Launchpad bug 636679 in linux (Ubuntu) "[119903.693261] BUG: unable to handle kernel NULL pointer dereference at 00000008 (affects: 1) (heat: 6)" [Undecided,New]
[13:59] <n1ght0wl> thanks alot guys!
[14:16] <apw> tgardner, ok talked to cjwatson and it seems that now that linux-libc-dev is bumped to -803 we cannot upload anything (for armel) which is lower than that, full stop
[14:16] <apw> tgardner, the recommendation is therefore to bump the abi component for linux-libc-dev above that for the maverick master
[14:17] <apw> tgardner, he has given me some techniques to use for that, so am going to try them out
[14:17] <apw> what a mess
[14:21] <tgardner> apw, I think we need a bodge in the rules that checks for master which is the only branch that should build linux-libc-dev
[14:22] <apw> tgardner, yeah i am also liking that idea ... explode on build
[14:22] <apw> i'll do that as well
[14:31] <apw> ogasawara, fyi armel maverick is failing, know what it is and am working on it
[14:49] <cnd> pgraner, what's the status on the firmware updates?
[15:58] <pgraner> cnd, no status yet, keep with what we have for now
[15:59] <cnd> pgraner, you're killing me :)
[17:32] <tgardner> apw, I have 2.6.36-rc4 amd64 natty kernels on tangerine.buildd:~rtg/natty/kern if you'd like to experiment with your i915 issues
[17:50] <apw> tgardner, sounds interesting
[18:28] <sconklin> apw, ogasawara: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/629711
[18:28] <ubot2> Launchpad bug 629711 in linux (Ubuntu Maverick) (and 2 other projects) "[Maverick] Removing external display on Vostro 3500 corrupts the screen (affects: 1) (heat: 8)" [High,Triaged]
[18:33] <ogasawara> sconklin: thanks, looks like that patch just landed in 2.6.36-rc4 and Cc'd stable
[18:33] <sconklin> ogasawara: cool. That was in the queue for the bugchat we didn't have today, so I wanted you to know
[18:33] <ogasawara> sconklin: I'm going to wait a few days and hope the <IP_ADDRESS> stable lands so we can rebase Maverick before freeze
[18:33] <ogasawara> sconklin: so we might get it for free, regardless I'll build them a test kernel with the patch
[18:34] <apw> ogasawara, just waiting on the last test build before i ship you the ti-omap-disaster patches
[18:35] <ogasawara> apw: cool, I was going to apply you patch and re-upload to get armel building again as well as having the kernel rebuilt against the latest gcc
[18:37] <Sarvatt> apw: regarding the mainstream kernels, comedi should be fixed now  - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=10022a0675a8f8722068d956a798f1fddb02e71c
[18:37] <apw> Sarvatt, in theory the patches should self-stop applying
[18:38] <Sarvatt> oh, nice!
[18:38] <Sarvatt> not sure if it was even still being applied, i just noticed it upstream
[18:39] <apw> if you look at that one, its gone ... all by itself ... http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc4-maverick/
[18:39] <Sarvatt> awesome :)
[18:39]  * apw pats self on the back, the first time its worked :)
[18:53] <kees> smb: when do you want to do the next kernel security update?
[18:54] <smb> kees, want? (must be a trick question) We likely want the current lucid proposed in updates
[18:54] <kees> smb: heh. I guess I mean "when would it be best?" :P
[18:56] <smb> kees, I guess so. :) I will have a look at the sru status tomorrow and then its probably worth starting to pass some processing on to bjf and sconklin this time.
[18:56] <kees> okay, cool
[19:01]  * apw wanders off to gte some food in
[19:03]  * tgardner lunches
[19:03]  * smb wander towards eod
[19:06] <bjf> ogasawara: am doing some patchwork cleanup
[19:06] <bjf> ogasawara: i'm looking at "musb: move usb_add_hcd to the core init code from gadget code (v2)" by Bryan Wu which you have under review
[19:07] <bjf> ogasawara: was it really a pull request or just a discussion?
[19:09] <ogasawara> bjf: I think it was just a discussion and last I remember bryan was still waiting for feedback
[19:09] <bjf> ogasawara: can I also mark the "xsave" patches as rejected?
[19:09] <ogasawara> bjf: not till kernel freeze
[19:10] <ogasawara> bjf: as it was dependent on them getting us test cases by kernel freeze if I'd consider applying to maverick or not
[19:10] <ogasawara> bjf: for lucid SRU they're a nack
[19:10] <ogasawara> s/lucid/maverick
[19:11] <bjf> ogasawara: ah, your waiting for the winged pigs to appear
[19:11] <ogasawara> bjf: exactly :)
[19:11] <ogasawara> bjf: so I'll mark them as rejected on thurs
[19:11]  * cking calls it a wrap
[19:11] <bjf> np
[19:50] <smoser> apw, jjohansen says there is some kernel/upstart bug that is related to bug 606373
[19:50] <ubot2> Launchpad bug 606373 in linux-ec2 (Ubuntu Maverick) (and 3 other projects) "cloud-init output does not get to console when booted with pv-grub and ramdisk (affects: 1) (heat: 73)" [Undecided,New] https://launchpad.net/bugs/606373
[19:50] <smoser> do you happen to know that bug number ?
[19:51] <apw> bug #554172
[19:51] <ubot2> Launchpad bug 554172 in upstart (Ubuntu Maverick) (and 5 other projects) "system services using "console output" not starting at boot (affects: 208) (dups: 16) (heat: 924)" [Medium,Fix released] https://launchpad.net/bugs/554172
[19:51] <apw> smoser, ^^
[19:52] <smoser> danke
[19:53] <jjohansen> yeah
[20:15]  * ogasawara lunch
[20:41] <jjohansen> -> Lunch
[21:54]  * jjohansen -> running errand back in a bit
[22:08] <bjf> ogasawara: i'm confused by lbm version numbers I'm seeing
[22:08] <ogasawara> bjf: for which release?
[22:08] <bjf> ogasawara: lucid
[22:09] <bjf> ogasawara: if I bring up the "Synaptic Package Manager" and type in "linux-backports-modules-alsa" in the "Quick search" box ..
[22:09] <bjf> ogasawara: I see modules with the description of "Backported drivers for alsa-driver snapshot"
[22:10] <bjf> ogasawara: as well as "Ubuntu supplied Linux modules for version 2.6.32 ALSA snapshots."
[22:10] <bjf> ogasawara: 2.6.32-25.22 is what I just recently uploaded and was built, I don't know what these "<IP_ADDRESS>.27" versioned packages are
[22:11] <ogasawara> bjf: that looks like the meta package version
[22:11] <bjf> ogasawara: there is a lbm meta package?
[22:12] <ogasawara> bjf: the linux-meta package generate lbm meta packages
[22:12] <bjf> huh
[22:23] <bhuey> got an nvidia module crash
[22:23] <bhuey> softirq hang
[22:26] <bhuey> trying to file a bug report is a pain
[22:26] <bhuey> anybody ?


[17:35] <mike802> hi, i'm trying to run the command cat wordpress.sql | sudo mysql --default-extra-file=/etc/mysql/debian.cnf
[17:36] <mike802> and i'm getting ERROR at line 1: Unknown command '\b'
[17:37] <mike802> i can't find any typos in the files that the wordpress section of the ubuntu server guide had me type up, but i'll keep looking
[17:39] <tomreyn> \b is a backspace
[17:40] <RoyK> perl -pe 's/\b//g' -i file.cnf
[17:41] <tomreyn> mike802: when you run    head -n2 wordpress.sql    does this output contain any sensitive content, anything you could not share with us?
[17:41] <mike802> it's all sql statements, create database etc
[17:41] <tomreyn> mike802: on those 2 lines?
[17:42] <RoyK> there shouldn't be \b in an sql file
[17:42] <tomreyn> anyways, it doesn'T answer my question.
[17:42] <mike802> well, when i saved the file the system asked me to create an encryption key
[17:42] <mike802> which i have to type in to open the file
[17:42] <RoyK> mike802: did you try the perl command above? make a backup first
[17:42] <tomreyn> what's the output of "file wordpress.sql"
[17:42] <mike802> brb
[17:43] <tomreyn> RoyK: not a good idea if it's encrypted
[17:43] <tomreyn> (but yeah, backup.)
[17:43] <RoyK> tomreyn: indeed
[17:43] <RoyK> tomreyn: but perhaps it's just gzipped or something and has the wrong extension
[17:43] <mike802> the head -n2 command just returns encrypted characters
[17:44] <mike802> :x
[17:44] <RoyK> what did 'file' say?
[17:44] <RoyK> (what does the fox say)
[17:44] <mike802> puttyputty
[17:44] <mike802> ::::|||~~~~~  putty putty
[17:45] <tomreyn> mike802: well if the sql file is encrypted then you can't just feed it into the mysql command like this
[17:45] <mike802> oh, weird.  i'll try deleting and making a new one
[17:45] <tomreyn> you'll need to find out how to decrypt it on the shell.
[17:45] <tomreyn> or export it unencrypted where it comes from
[17:45] <mike802> i'm just gonna ctrl+c the key bit
[17:46] <RoyK> mike802: if it's encrypted, the backup job must have done that
[17:46] <mike802> i'm typing this up from the ubuntu server guide web page
[17:46] <mike802> https://help.ubuntu.com/lts/serverguide/wordpress.html.en
[17:49] <mike802> awesome, thank you
[17:49] <mike802> weird
[17:52] <muhaha> How do I run systemctl --user enable pulseaudio && systemctl --user start pulseaudio under root? It does not work for root , I need to run in userspace. (Failed to connect to bus: No such file or directory)
[17:59] <muhaha> nvm, it should be started under user


[03:03] <jthan> Do you have to reset vixie-cron for new jobs to take effect? I feel like that's a "no"
[03:09] <jthan> I put a script in /etc/cron.hourly just to test it out.. it's supposed to put the output in a log file in my home directory. Did that earlier - nothing in there as of now.
[03:11] <InHisName> Is the cron job processor running.  (not sure of real name)   If its not running, then all the scripts in the pc just lay about and do nothing.
[03:13] <jthan> jonathan@berkley ~ $ /etc/init.d/vixie-cron status * status: started
[03:16] <jthan> I miss helping people troubleshoot issues in #ubuntu
[03:16] <jthan> ha
[03:16] <jthan> or in here, for that matter
[03:17] <InHisName> Is there a config file ?   If so be sure its set to check and run 'hourly' 'daily' etc.   I had similar problem with cron on ubuntu in not running correctly out of the box.
[03:27] <jthan> Sure - it's in the crontab
[09:24] <JonathanD> Morning.
[09:30] <rmg51> Morning
[09:41] <JonathanD> hey rmg51
[09:41] <rmg51> yo
[10:26] <InHisName> yo-yo
[15:48] <ChinnoDog> So, Amazon has this free cloud server offering but it only lasts a year. Anyone know what it will cost after that for those resources?
[16:34] <ChinnoDog> $19.82
[16:36] <ChinnoDog> Per server. They give you two of them.
[16:37] <ChinnoDog> That is a pretty sweet deal
[16:52] <Joe_CoT> ChinnoDog, it's actually pretty cheap to pay for. I kept the microserver
[16:53] <Joe_CoT> I paid $82 for 3 year reserved, and pay $7 a month. so 9 and change a month
[16:54] <ChinnoDog> I hadn't looked real closely at how the reserved one work
[16:54] <ChinnoDog> So, that works out pretty well for you then
[16:56] <ChinnoDog> Joe_CoT: explain how to get the best price on reserved
[16:57] <ChinnoDog> I see $82 for medium utilization micro upfront cost
[16:57] <Joe_CoT> you buy the reserved upfront, and then pay the lower reserved monthly price
[16:58] <ChinnoDog> What is the light/medium/high utilization about? The upfront/hourly differential based on how many hours it will be powered on?
[16:58] <Joe_CoT> that I have no idea about.
[16:58] <Joe_CoT> when I bought reserved the utilization thing wasn't there
[17:01] <ChinnoDog> I figured it out
[17:01] <ChinnoDog> It is what I said. If you assume your Ubuntu server will be on 24/7 then use heavy utilization prices for maximum cost savings
[17:03] <Joe_CoT> ah
[17:03] <Joe_CoT> yeah, I pay $5 a month for the server apparently, the other 2-3 dollars is bandwidth
[17:12] <ChinnoDog> I think I may need to switch so I can develop EC2 expertise
[17:14] <ChinnoDog> Joe_CoT: how can a micro instance have EBS storage only? Where is the operating system stored?
[17:14] <Joe_CoT> it's stored on EBS
[17:15] <ChinnoDog> That is a strange place to store the operating system
[17:38] <adom> guess whos back
[17:39] <adom> *two thumbs* this guy
[17:59] <ChinnoDog> ?
[18:45] <InHisName> afternoon
[20:01] <adom> there we go
[20:02] <adom> havent dicked with my screen sessions in awhile
[20:02] <adom> hi everyone!
[20:02] <JonathanD> Hi adom
[20:02] <adom> o/
[20:05] <adom> still in Erie, any more Erie-ites join in here?
[21:34] <jthan> DUH ME
[21:38] <MutantTurkey> Duh
[21:39] <MutantTurkey> what
[21:39] <MutantTurkey> jthan: ?
[21:39] <MutantTurkey> he's alive?
[21:39] <MutantTurkey> who told me he got killed in a freak llama accident?
[21:43] <jthan> I was complaining yesterday that my script wouldn't run
[21:43] <jthan> But I didn't ever make it executable -_-
[23:05] <InHisName> execute that son of a gun!  he didn't run!
[23:57] <lou__> hi all
[23:57] <lou__> does anyone know how I can check if openjdk6 is being used by ubuntu


[08:08] <acheronuk> mwhudson or tianon: no hurry, but it would be great if eoan container were available reasonably soon
[08:09] <acheronuk> would be nice to set up eoan as devel series on Kubuntu CU that is all, which I need those for
[08:10] <acheronuk> ^ docker containers
[09:00] <{xmb}> hello, which package contains the pre-creating of /services by daemontools | svscan, i installed daemontools-run and the others but it isnt running by default
[09:02] <{xmb}> i mean i look for a package that runs itself as daemon and creates the /services dir in which services get started by svscan by daemontools
[09:04] <infinity> {xmb}: (a) daemontools-run is not part of the default (or even supported) Ubuntu setup, (b) this is not a support channel, try #ubuntu
[09:06] <{xmb}> i code, thats why i thought -devel
[09:07] <{xmb}> i had it there, default 18 apt entries nothing special
[09:07] <{xmb}> maybbe it was a debian box, .., but i dont think so
[09:07] <{xmb}> i cannot test currently, but ok thanks will try in ubuntu
[16:44] <tsimonq2> @pilot in
[16:44] <tsimonq2> Morning, I'll do this for a few minutes.
[16:45] <teward> yer off by a few hours, it ain't morning no more :P
[16:45] <tsimonq2> It's 11:45 AM. :P
[16:46] <CarlFK> it's always morning on the internet
[16:47] <tsimonq2> ^
[16:47] <teward> by that same argument, it's always evening on the internet and never morning.
[16:48] <teward> :P
[16:53] <tsimonq2> I'm assuming someone in here would know; the ESM folks might want to be aware of bug 1823444.
[16:54] <tsimonq2> I'm not sure if that's something they support; it wouldn't hurt to look.
[16:56] <tsimonq2> vorlon: I'm not 100% comfortable reviewing a resolvconf patch, do you have the cycles to take a look at this since you have non-tsimonq2 TIL on bug 1825194? :)
[16:57] <sarnold> woah a patch pilot
[16:57] <tsimonq2> And with that, that's the queue.
[16:57] <tsimonq2> @pilot out
[16:57] <vorlon> tsimonq2: yes it's still in my inbox
[16:57] <teward> sarnold: not any more it isn't
[16:57] <tsimonq2> sarnold: See the backlog from Saturday to today ;)
[16:57] <teward> there is no patch pilot xD
[16:57] <tsimonq2> vorlon: Thanks! Much appreciated.
[16:57] <tsimonq2> sarnold: You even have an item here https://lists.ubuntu.com/archives/ubuntu-devel/2019-April/040665.html ;) ;)
[16:57] <sarnold> tsimonq2: looks like a busy weekend :)
[16:57] <tsimonq2> Yep :D
[16:58] <sarnold> tsimonq2: I'm pretty sure one of the new guys will pick that one up
[16:58] <tsimonq2> sarnold: Sounds good, just making sure it's on someone's radar.
[17:10] <teward> sarnold has a number of things on the radar, including that huge mailman3 packageset :P
[17:29] <GunnarHj> tsimonq2: Thanks for sponsoring and for the tip about the -v option! Will try that next time.
[17:30] <tsimonq2> GunnarHj: No problem :D
[17:35] <GunnarHj> tsimonq2: Great work with the sponsoring queue, btw. Much appreciated!
[17:35] <tsimonq2> GunnarHj: Thanks :)
[23:56] <tomreyn> sarnold: I just started an edit war with you on https://help.ubuntu.com/community/EOL - ;-) Let me know what you think
[23:57] <sarnold> tomreyn: was it released at all? I thought about deleting the line entirely but couldn't find the blog post I wanted to find so I gave up :)
[23:59] <tomreyn> sarnold: oh i didn't actually check whether there was a release. i simply listed all the flavours which were once (amongst those three LTS releases listed on this page) an official release, and added this note for every release where those were not official


[19:10] <ibeardslee> morning
[20:33] <ajmitch> morning
[20:45] <ibeardslee> hads: #zareason
[20:46] <chilts> morning
[20:46] <chilts> is that for zareasonnz or general zareason?
[20:46] <chilts> am just curious :)
[20:48] <ibeardslee> general, but at the moment Earl is in NZ, there are a few NZ people in there
[20:48] <ibeardslee> most discussion is around the android on the zatab
[21:11] <thumper> morning
[21:18] <mwhudson> morning


[00:09] <perrito666> sinzui: news?
[01:21] <perrito666> ok, something is very very broken with aws
[01:45] <waigani> axw: do you mean just setting state-server: true in tests where it is set to false?
[01:45] <axw> waigani: yes, the ones where it matters anyway
[01:45] <axw> leaking details of the dummy provider into the command is not great
[01:46] <axw> AFAIK, the state-server thing is just there to speed up the tests
[01:46] <axw> but if we need it, then the tests should change
[01:46] <waigani> axw: yeah for sure, it's ugly. I assumed the state-sever was set to false in tests for a reason
[01:47] <axw> waigani: there's lots of wrong in the code, don't be afraid to question it ;)
[01:47] <waigani> axw: so you're saying the state-server setting should be deprecated?
[01:48] <axw> no, just change it to true for the tests where we run the bootstrap command
[01:48] <axw> alternatively, do the TODO now... not sure which one is less work really
[01:49] <waigani> sigh
[01:49] <waigani> kludges are less work ;)
[01:49] <waigani> I had to look that up
[01:49] <axw> yes, often less work in the short term
[01:49] <waigani> and found this image: http://en.wikipedia.org/wiki/Kludge#mediaviewer/File:Miles_Glacier_Bridge,_damage_and_kludge,_1984.jpg
[01:50] <axw> lol
[01:50] <waigani> sums it up pretty nicely haha
[01:50] <waigani> I should put that on my coding profile ;)
[02:43]  * wwitzel3 flips his desk
[02:48] <axw> wwitzel3: what'cha doing?
[02:49] <wwitzel3> trying to get rsyslog rotation for all-machines.log working
[02:49] <axw> ah, fun times
[02:49] <wwitzel3> since all day
[02:49] <wwitzel3> :/
[02:50] <wwitzel3> I was in bed attempting to go to sleep and I was have weird dreams about rsyslog in human for bullying and taunting me.
[02:50] <wwitzel3> s/for/form
[02:50] <wwitzel3> lol
[02:51] <axw> well, that's not cool...  I don't recall having personified a software package before
[02:51] <wwitzel3> haha, happens to me all the time
[02:52] <axw> did it look like this guy? https://plus.google.com/+RainerGerhards
[02:52] <axw> :)
[02:53] <wwitzel3> though my favorite dream was I was travel through code and I kept hitting this unhandled exception (which was the same one that was happening in production). And when I woke up I had instant thought of how to fix it and got it resolves in 5 minutes.
[02:53] <menn0_> axw: bad news... the "State remove setmongopassword" change is what's causing this CI blocker: bug #1355320
[02:53] <axw> god damnit
[02:53] <menn0_> axw: I've been bisecting my way through recent changes and that's the one
[02:53] <axw> thanks menn0_
[02:54] <axw> I'll take it over if you like
[02:54] <menn0_> sure
[02:54] <menn0_> I'll update the ticket with the best repro details I have
[02:54] <menn0_> give me a few minutes to see if I can simplify them a bit further
[02:55] <axw> menn0_: thanks
[03:09] <axw> weird, I'm certain I tested this...
[03:10] <waigani> menn0_: how do you bisect your way through the changes?
[03:11] <menn0_> axw: after issuing ensure-availability did you wait for the new state servers to hit "started"?
[03:12] <axw> menn0_: pretty sure I did, but it was a little while ago and my memory isn't great
[03:12] <menn0_> I'm seeing the new machine agents getting stuck in pending because they can't connect to the API
[03:12] <axw> yeah, I see the same thing now
[03:15] <menn0_> axw: I've updated the ticket and assigned it to you. All yours!
[03:16] <axw> menn0_: thanks
[03:16] <menn0_> waigani: the process I used is:
[03:16] <menn0_> reproduce the problem with master
[03:16] <menn0_> use git log to see the changes between 1.20.1 and master
[03:17] <menn0_> git checkout <some rev in between>
[03:17] <menn0_> git install ./..
[03:17] <menn0_> try to reproduce the problem
[03:17] <menn0_> does it exist?
[03:17] <menn0_> no: the problem revision is after this on
[03:17] <menn0_> yes: the problem revision is before this one (or it IS this one)
[03:17] <menn0_> you can do a straight binary search
[03:18] <menn0_> but if you have some idea of where the problem lies, like in this case, you can be a bit smarter about picking revs to narrow it down more quickly.
[03:19] <menn0_> keeping good notes on what you've done helps a lot too
[03:19] <waigani> menn0_: ah right, thanks for the explanation
[03:20] <menn0_> if the reproduction steps were completely automated (which they can be but I didn't bother) then you could get "git bisect" to do all the work for you.
[03:21] <menn0_> what i've described is exactly what it does
[03:23] <menn0_> actually, looking at the docs "git bisect" can also be used to assist with manual searches. I should have used it.
[03:23] <menn0_> previously I've only ever used "git bisect run" which does automated searching
[03:24] <waigani> menn0_: yeah I was thinking that should be able to be automated
[03:26] <menn0_> waigani: the fiddly part in this case is writing some code to wait at the right times and parse the status output
[03:27] <menn0_> waigani: all doable though and I'm sure the helper functionality in juju-ci-tools would help too.
[03:28] <waigani> menn0_: setting up a process that could automatically find the offending commit for a CI bug would save us a lot of time
[03:28] <waigani> potentially reverting it too
[03:29] <menn0_> I think a semi-automatic process is probably best
[03:29] <menn0_> the CI tests often fail for infrastructure related reasons
[03:30] <waigani> right, well it could add suspicious commits to the bug comments
[03:30] <menn0_> you wouldn't want these to trigger reverts or long running investigations
[03:30] <menn0_> yes
[03:36] <stokachu> is there any examples where juju actions are being used in practice?
[03:37] <menn0_> axw: you associated bug 1347715 with the "don't enter upgrade mode unnecessarily" PR
[03:37] <axw> menn0_: yep
[03:37] <menn0_> that PR wasn't intended to solve that bug :)
[03:38] <axw> menn0_: see the latest error message at the bottom of the bug
[03:38] <axw> that LP bug has morphed
[03:38] <axw> the latest one was due to "upgrade in progress"
[03:38] <menn0_> all that PR does is allow the machine agent workers to start up a little faster, and avoid some unnecessary log noise
[03:39] <menn0_> I can see how it might help with that bug
[03:39] <menn0_> but I wonder if that's the whole story
[03:39] <menn0_> if it is then, great
[03:39] <stokachu> there doesnt seem to be an action-set either is this feature not complete yet?
[03:39] <menn0_> but I'm not sure
[03:40] <axw> stokachu: still a work in progress AFAIK
[03:40] <stokachu> axw, ok cool
[03:42] <menn0_> axw: is it worth reverting 3b6da1d429bff627a636ca4512c1ae8230f26539 or do you think you'll have this sorted quickly
[03:42]  * menn0_ would like to get CI unblocked
[03:44] <axw> menn0_: I guess it's no big deal to revert it in the mean time
[03:44] <axw> I'll do that...
[03:45] <jcw4> stokachu: yes, it's still in-progress
[03:45] <jcw4> stokachu: bodie_ is primarily working on action-set and action-get
[04:15] <axw> menn0: reverted
[04:15] <menn0> axw: yep, saw that. cheers
[04:15] <menn0> axw: does the bug get marked as "Fix committed" now?
[04:16] <axw> menn0: yeah I've done that
[04:16] <axw> I'll keep looking into it tho
[04:16] <menn0> cool
[04:16] <menn0> of course
[04:16] <axw> this is one time where I really wish I hadn't rebased
[04:17] <axw> pretty sure I tested it and it all worked, then I rebased and it's broken since then
[04:19] <menn0> axw: so you think it's some interaction with this change and some other change that got rebased in?
[04:20] <axw> I think so
[04:20] <menn0> axw: in other news, that manual provider problem is still there despite the "don't enter upgrade mode unnecessarily" change
[04:20] <axw> sigh
[04:20] <axw> all good news today :)
[04:21]  * menn0 reopens the bug
[04:21] <axw> hold up
[04:21] <axw> it's still publishing?
[04:21] <axw> menn0: ^^
[04:21] <axw> or did you test it manually?
[04:21] <axw> eh, never mind
[04:21] <axw> hadn't refreshed
[04:22] <menn0> http://juju-ci.vapour.ws:8080/job/manual-deploy-trusty-ppc64/523/
[04:26] <menn0> axw: shall I take 1347715 for a bit?
[04:27] <axw> menn0: that'd be great, thank you
[04:27] <menn0> axw: cool
[04:27] <menn0> I need to go out and pick up some furniture but I'll keep going with it once I'm back
[05:26] <menn0> axw: I'm back but need to deal with the kids for a bit
[05:26] <axw> menn0: no worries
[05:26] <menn0> I'll continue with this manual provider issue later this evening
[05:27]  * axw hopes it isn't something else he's broken
[06:25] <axw> menn0: I'm getting "auth fails" even without my change
[06:25] <axw> :/
[06:41] <axw> hrm, 2nd shot worked
[06:41]  * axw scratches head
[08:16] <mattyw> morning all
[08:26] <TheMue> heya
[08:26] <dimitern> morning
[08:28] <voidspace> TheMue: morning
[08:28] <voidspace> dimitern: morning
[08:55] <menn0> axw: I'm back again (kids were a nightmare to get to bed)
[08:56] <axw> menn0: heya. fun :(
[08:56] <axw> menn0: so I've reworked my previous PR and got something working now
[08:56] <axw> ignore my comment from before, I think I hadn't uploaded the right tools
[08:56] <menn0> axw: ok that's good to hear
[08:57] <menn0> axw: let me know if you need a review
[08:57] <axw> the problem with the old one was that mongo.SetAdminMongoPassword was also doing Login straight after
[08:57] <dimitern> so is anyone working on the blocker bug https://bugs.launchpad.net/juju-core/+bug/1355324 ?
[08:57] <axw> menn0: it can wait, it's well after EOD there...
[08:57] <axw> not I
[08:58] <menn0> dimitern: no I don't think so
[08:58] <menn0> other blockers have been keeping us busy
[08:58] <dimitern> menn0, how about the other one assigned to you?
[08:58] <voidspace> launchpad won't even show me the bug
[08:59] <dimitern> voidspace, oh, which one?
[08:59] <voidspace> I don't think it's my internet  being rubbish this time
[08:59] <voidspace> 1355324
[08:59] <voidspace> page won't load
[08:59] <dimitern> voidspace, :( aw
[08:59] <voidspace> just launchpad being slow I think
[08:59] <menn0> voidspace: weird. it's working for me
[08:59] <voidspace> odd
[09:00] <menn0> I'm going to look at #1347715 for a bit longer
[09:00] <menn0> but someone else might have to take over depending how far I get with it
[09:03] <mattyw> voidspace, I'm having trouble with lp, canonical.com and ubuntu.com this morning
[09:03] <mattyw> voidspace, you on bt?
[09:03] <voidspace> mattyw: over here in Romania? I doubt it :-)
[09:03] <voidspace> mattyw: don't know who the isp is to be honest
[09:04] <voidspace> but today most of the internet works well, which is better than previous days, *except* for launchpad
[09:04] <mattyw> voidspace, cool - how long you there for?
[09:04] <voidspace> I'll try canonical.com and ubuntu.com as well
[09:04] <voidspace> mattyw: till the end of August
[09:04] <voidspace> mattyw: visiting wife's family
[09:04] <mattyw> voidspace, nice, hope you have a great time
[09:04] <voidspace> canonical.com loads fine
[09:04] <voidspace> mattyw: thanks
[09:05] <voidspace> mattyw: I'm mostly working
[09:05] <voidspace> mattyw: we're taking a week at the end of August to visit seaside and mountains though
[09:05] <voidspace> should be good
[09:05] <voidspace> yep, launchpad not loading for me at all at the moment
[09:05] <voidspace> tried two browsers
[09:11] <voidspace> I wonder if it's a dns issue, I can't ping it either
[09:13] <mattyw> voidspace, I was able to get to canonical.com by changing dns servers but everything else is down for me
[09:43] <menn0> axw: well this looks like a problem. using the manual provider:
[09:43] <menn0> 2014-08-12 09:36:54 INFO juju.mongo open.go:104 dialled mongo successfully on address "<IP_ADDRESS>:37017"
[09:43] <menn0> 2014-08-12 09:36:54 DEBUG juju.worker.logger logger.go:45 reconfiguring logging from "<root>=DEBUG" to "<root>=WARNING;unit=DEBUG"
[09:43] <menn0> 2014-08-12 09:36:55 ERROR juju.worker runner.go:219 exited "machiner": machine-0 failed to set status started: cannot get machine 0: EOF
[09:43] <axw> menn0: yep, but what would be causing the EOF?
[09:44] <menn0> that's the last thing in the machine-0 log following bootstrap
[09:44] <axw> I saw it, but it's not a very enlightening error message ;)
[09:44] <menn0> I'm going to crank up the log level during bootstrap and see what I can see
[09:44] <axw> cool
[09:44] <menn0> the error happens after the root logger goes to WARNING
[09:44] <axw> ah right
[09:45] <axw> yeah, I just set my environments' logging-config="<root>=DEBUG"
[09:45] <menn0> and I might have to do the bisect thing again to see if I can track down the rev
[09:46] <menn0> this one has been broken for a while so there could be a lot of revs...
[10:00] <mattyw> folks - is someone able to help me out with a couple of things around the unit type?
[10:00] <mattyw> ^^ it appears (at least in some tests) that the CharmURL in a unit doesn't have a value (== nil)
[10:01] <menn0> axw: alright
[10:01] <menn0> now I have a nice long panic
[10:01] <axw> menn0: cool
[10:02] <axw> I have to run
[10:02] <perrito666> morning
[10:02] <menn0> axw: no problems
[10:02] <menn0> I need to stop soon too
[10:02] <axw> menn0: if you get sick of looking at that, can you please attach the panic to the bug and I'll take a look tomorrow
[10:02] <menn0> axw: I'll try to get someone else to look in the mean time too
[10:03] <menn0> but I will add everything I have to the bug either way
[10:03] <axw> cool
[10:38] <TheMue> dimitern: a cable technician just came, could be that I’m a bit later at our hangout
[10:38] <dimitern> TheMue, ok, np
[10:50] <voidspace> dimitern: are we postponing?
[10:50] <dimitern> voidspace, let's wait for TheMue a few minutes
[10:50] <voidspace> dimitern: sure
[10:56] <TheMue> dimitern: I’m there, are you done?
[10:57] <voidspace> TheMue: we didn't start
[11:24] <menn0> right... I'm done
[11:24] <menn0> who wants to take over this CI blocker: 1347715
[11:24] <menn0> I've done a lot of the legwork. There's repro instructions and other findings attached to the ticket.
[11:25] <menn0> I'm pretty close but I haven't quite nailed the actual bug yet.
[11:43] <menn0> no takers regarding the above?
[11:51] <tasdomas> could somebody take a look at https://github.com/juju/juju/pull/490 ?
[11:52] <mgz> menn0: I read through the bug, did you narrow down when it was introduced, or not get that far yet?
[11:52] <menn0> mgz: well as per my last comment, it's definitely since 1.20.2
[11:52] <menn0> but I haven't narrowed it further than that
[11:53] <menn0> given that we have a fair simple repro, git bisect could help?
[11:54] <mgz> yeah, just a bit slow, right, as it involves reprovisioning a machine?
[11:54] <mgz> or can you do it on a dirty one?
[11:54] <menn0> focussing on changes that involved the manual provider might also help narrow things down more quickly
[11:54] <menn0> no you don't need to reprovision
[11:54] <menn0> because it's the manual provider
[11:54] <menn0> just make sure you do a juju destroy-environment --force --yes after each run
[11:55] <menn0> that's pretty good at getting rid of most of the previous run
[11:55] <menn0> it's not exactly fast (the bootstrap still takes a while) but it's manageable
[11:56] <menn0> limiting the upload series to just trusty also helps a bit
[11:56] <menn0> it's midnight. I really need to go to bed
[11:57] <mgz> menn0: okay, good night
[11:57] <menn0> have a good one
[11:59] <fwereade> tasdomas, LGTM
[12:20] <tasdomas> fwereade, thanks
[13:41] <fwereade> natefinch, ping -- when you have a moment I'd like to chat about transactions
[13:41] <natefinch> fwereade: how about now? :)
[13:42] <fwereade> natefinch, perfect :)
[13:42] <fwereade> natefinch, in irc for a bit in case anyone else sees something ineresting go past?
[13:42] <natefinch> fwereade:  sure
[13:42] <fwereade> natefinch, basically I'm worried about interactions between the two systems as we switch
[13:43] <natefinch> fwereade: yep
[13:43] <fwereade> natefinch, (oh wait, it might actually not be a problem, let's keep going for a bit)
[13:43] <fwereade> natefinch, in particular, assertions
[13:44] <fwereade> natefinch, now I think that we will write to every affected document --including those we just assert on -- as part of a transaction
[13:44] <fwereade> natefinch, if that's the case I think we're good
[13:44] <fwereade> natefinch, the problem isn't at crossover time
[13:44] <fwereade> natefinch, it's with using toku on its own
[13:45] <fwereade> natefinch, in particular, assertions about particular document states
[13:45] <fwereade> natefinch, I think that within any transaction we need to write to any document on whose state we depend
[13:47] <natefinch> fwereade: I haven't actually done a lot of research into how toku transactions work.... do you not get a consistent view of the database once you enter a transaction?  Or only the ones that you write to?
[13:47] <fwereade> natefinch, and that, best-case, this is going to lead to frequent document deadlocks
[13:48] <fwereade> natefinch, consistent state doesn't help though, I think
[13:48] <natefinch> ahh right, if someone else changes the doc out from under you
[13:48] <fwereade> natefinch, it's about needing all that state to still satisfy certain conditions when the txn lands
[13:48] <natefinch> right
[13:49] <fwereade> natefinch, writing to the document will help there, it pulls it into the transaction if you like
[13:49] <fwereade> natefinch, but I think it *seriously* increases the already-present risks of deadlock in the DB
[13:50] <fwereade> natefinch, I read docs X and Y, you read Y and X
[13:50] <natefinch> right
[13:50] <natefinch> classic deadlock
[13:51] <natefinch> fwereade: have you read up on their transactions?  I don't feel qualified to talk about them without doing some reading.  I'd just been doing some testing to make sure it was even possible to use their DB.... but hadn't actually researched the way their transactions worked.  hazmat had done the work there, I believe.
[13:52] <fwereade> natefinch, I've read like 1 small white paper
[13:52]  * natefinch is reading the white paper now
[13:54] <fwereade> natefinch, so anyway -- I think it will work fine with mgo txns underneath, for a given value of fine, if not actually very performant
[13:54] <fwereade> natefinch, although
[13:55] <hazmat> fwereade, its mvcc fwiw
[13:55] <hazmat> consistent reads, so a simple query satisifes mgo conditions
[13:56] <hazmat> fwereade, more of concern is the use of write hotspots in the current codebase
[13:56] <fwereade> hazmat, are you thinking more of "presence" or of things like service documents?
[13:56] <hazmat> fwereade, service docs
[13:57] <fwereade> hazmat, right, I think those things are a nexus of fuckery in either txn system
[13:57] <hazmat> fwereade, they exist due to async gc ? or..
[13:58] <hazmat> fwereade, latent gc can use simple queries afaics.. i tended to regard them as offshots of the extant txn sys in conjuction w/  lifecycle management
[13:58] <fwereade> hazmat, well service documents get cleaned up with the last unit to be removed from a dying service
[13:58] <fwereade> hazmat, but that's managed by a refcount on the service document
[13:59] <hazmat> fwereade, why not just a async gc cleaner job in the state server?
[13:59] <Beret> wallyworld, any update on that flag to prevent a failed bootstrap from tearing itself down?
[14:00] <hazmat> fwereade, doesn't that mean machine loss of last unit leaves to stuck service otherwise?
[14:01] <hazmat> minus using destroy-machine --force to try and post clean up after the fact from the api server
[14:01] <fwereade> hazmat, no? when a unit gets removed either by the machine agent or by forced removal of the machine, the last one cleans up anything that depends on it
[14:01] <fwereade> hazmat, or indeed "yes" depending on perspective
[14:02] <natefinch> Beret: we've been fighting some critical bugs lately, and most of the team leads were on a sprint last week, so it hasn't gotten done yet, AFAIK.  But I think it could be done this week if we have someone free to work on it.
[14:03] <Beret> natefinch, ok, thanks
[14:03] <natefinch> Beret: we'll try to get it in... it's something we want for ourselves, too.
[14:03] <Beret> natefinch, it's not more important than real bugs, I just wanted to make sure it hadn't gotten in and we just didn't know it
[14:03] <fwereade> hazmat, to step back a moment
[14:03]  * hazmat nods
[14:03] <hazmat> meeting.. bbiab
[14:04] <fwereade> hazmat, in either txn system, our performance is largely dependent on the areas of document space touched by a given txn -- thus designing db operations that minimise overlap is important either way
[14:04] <hazmat> fwereade, agreed
[14:05] <fwereade> hazmat, we have occasionally done a really poor job of designing these things in the past
[14:05] <fwereade> hazmat, but now we have schema changes we have a path to mitigate these, and we can expect to see benefits from doing this in *either* system
[14:06] <fwereade> hazmat, however, we won't be able to eliminate overlaps
[14:07] <fwereade> hazmat, our job is structuring things such that overlaps are (1) rare and (2) not too disruptive
[14:09] <fwereade> hazmat, and I am at the moment mainly thinking about the impact on how we actually have to write code
[14:10] <fwereade> hazmat, natefinch: so if we wrap a mgo txn in a toku txn...
[14:12] <fwereade> hazmat, natefinch: let's pretend for a moment we get all our info from a consistent snapshot, and craft a txn assuming the truth of that stuff, and then we execute that txn
[14:13] <fwereade> hazmat, natefinch: only when we execute that txn do we hit the docs and grab the locks, and if we deadlock at that point we may have trouble
[14:14] <fwereade> hazmat, natefinch: if the txn runner fails out for this reason, what exactly is the impact on the code trying to craft the txn and retry in the face of contention?
[14:16] <fwereade> hazmat, go back to the beginning of the whole set of operations and start crafting txns again from scratch?
[14:17] <fwereade> hazmat, in particular I fear *that* is going to be a major source of gray goo transactions that end up locking large chunks of the DB, deadlocking, failing out, and doing the same thing over and over again
[14:18] <fwereade> natefinch, sorry, I am also interested in your thoughts on the above
[14:18] <natefinch> hah ok
[14:18] <natefinch> I was going to give my thoughts anyway ;)
[14:18] <fwereade> natefinch, just realised I'd stopped badging you at some point
[14:20] <fwereade> (but that doesn't mean I'm going to stop badgering you, ho ho)
[14:20]  * fwereade looks shamefaced
[14:20] <natefinch> haha
[14:21] <natefinch> fwereade: I gotta run in a couple minutes unfortunately..... but... do we need mgo transactions if we have toku transactions?  Can we just stop using mgo transactions?
[14:22] <fwereade> natefinch, yes, *but* that's a lot of stuff to rewrite rather than wrap
[14:22] <natefinch> right
[14:22] <fwereade> natefinch, there will certainly be things that are easier to do in a pure-toku world
[14:22] <natefinch> yep
[14:23] <fwereade> natefinch, I'm just worried that mixing the two will actually have a pathologically awful impact
[14:23] <natefinch> I gotta run, sorry, I'll keep thinking and will read the channel history.. Back in an hour-ish
[14:23] <fwereade> natefinch, cheers, take care
[14:24] <hazmat> fwereade, per the acid doc, we could divert mgo transactions to toku
[14:27] <fwereade> hazmat, I can sort of see it but it's a bit fuzzy in my mind
[14:27] <fwereade> hazmat, we still have to do what I said, I think?
[14:27] <fwereade> hazmat, we can be a bit more proactive about writing to docs to take their locks a bit earlier than we could otherwise
[14:28] <fwereade> hazmat, and I daresay we can convert failure to do so into ErrRefresh, and make all the transactions handle it?
[14:29] <fwereade> hazmat, but wouldn't we have to actually start a fresh toku txn *anyway*?
[14:30] <fwereade> hazmat, so in a multi-step toku operation, if the Nth step fails we back *everything* out and start again?
[14:33] <fwereade> hazmat, heh, maybe even track and try to grab locks on everything we thought we needed last time through?
[14:34] <fwereade> hazmat, it all feels potentially *really* yucky
[14:40] <fwereade> natefinch, more blithering above ^^
[14:44] <hazmat> fwereade, sorry still in meeting, bbiab
[14:44] <fwereade> hazmat, np, I'm around for a bit I think
[16:01] <natefinch> fwereade: back
[16:23] <fwereade> natefinch, I need to be off soon, but read back and see if anything resonates or inspires a response
[16:24] <fwereade> natefinch, just type at me in here if I'm gone, I'll see it soon
[16:26] <hazmat> fwereade, sorry my meeting ran over time.. and into another meeting.. i'll capture notes for discussion tomorrow if your not around in a bit
[16:29] <hazmat> fwereade, nutshell locks are implicit with mods to a doc in a txn.. basically we just take a op runner and do it in toku txn (begin, end txn) with catch on lock and retry behavior.
[16:30] <natefinch> fwereade: no problem.  Trying to do a few things at once here.   I don't know that grabbing locks early has any effect in toku... if two threads are both trying to grab locks early, it doesn't really buy us much.  My preference would be to just make the code straightforward and do what it's supposed to do, and if something else gets into the DB first, the TX will have to retry.
[16:30] <hazmat> fwereade, re backout, its implicit at that commit, failed lock is rollback, and error to app to handle, at which point we retry similiar to runner loop now
[16:30] <hazmat> there is no grabbing a lock, its implied by writing to a doc during a txn.
[16:31] <fwereade> hazmat, natefinch: ok, this sounds broadly sane, I am worried that we have some funky layering issues to work around wrt actually managing rollbacks
[16:31] <natefinch> that's certainly possible
[16:31] <fwereade> hazmat, natefinch: well I am contending that we do need document locks for those docs that in mgo/txn we would assert on
[16:31] <fwereade> hazmat, natefinch: but that we will have to lock them ourselves by, as you say, writing to them in a transaction
[16:32] <hazmat> fwereade, we don't because we're operating in a mvcc world with implicit write level locks.
[16:32] <fwereade> hazmat, right
[16:32] <hazmat> ie read committed, or serialized if preferred (both options avail)
[16:32] <fwereade> hazmat, which is great for ensuring that conditions hold for the documents we're writing
[16:32] <hazmat> fwereade, right.. toku should be a nice runner for the extant mgo transactions since conditions are explicitly specified and re-runnable
[16:32] <natefinch> fwereade: right... my reading of MVCC is... you don't have to worry about basing your behavior on reads that get out of date, because if they get out of date, one of the two transactions aborts and retries
[16:34] <fwereade> hazmat, natefinch: so once you start a transaction, toku tracks everything you read? and aborts your txn if someone writes to one of those docs?
[16:34] <fwereade> hazmat, natefinch: that's the only way I could see it aborting a transaction in that situation
[16:35] <hazmat> fwereade, again depends on isolation level.. read serialized you'll read the copy that was current at the time of txn begin
[16:35] <hazmat> fwereade, read committed, means you read other docs current as of the time of read
[16:35] <hazmat> as opposed to our read dirty model now.. ie. read partially committed state
[16:36] <fwereade> hazmat, natefinch: I don't see how either read serialized *or* read committed actually helps us -- I'm not interested in either of those two states
[16:36] <hazmat> rephrasing .. current == latest commmitted revision of the doc
[16:37] <hazmat> fwereade, their rather important .. but perhaps we should take a step back.. what's the concern?
[16:37] <fwereade> hazmat, if I have a txn that should only go ahead if a property continues to hold for some doc not in the txn
[16:38] <fwereade> hazmat, then it's philosophically impossible for me to read a document in either of those situations and be certain that it can't change under me
[16:38] <fwereade> hazmat, but if I *write* to that document I can
[16:38] <fwereade> hazmat, because I take a lock
[16:39] <fwereade> hazmat, and guarantee the failure of either myself or the other txn that wanted to write it
[16:39] <fwereade> hazmat, (sucks if that one just wanted to read it too, but anyway)
[16:39] <fwereade> hazmat, making sense?
[16:39] <hazmat> fwereade, serializable would give you that semantic
[16:40] <fwereade> hazmat, ok, so that does take locks on read?
[16:40] <fwereade> hazmat, (hopefully happy smart read locks not nasty actually-triggering-serialization write locks?)
[16:40] <hazmat> fwereade, it does.. but it may not cover every use case.. ie inserting new doc in collection.. since your asserting a negative read
[16:41] <fwereade> hazmat, yeah, we depend on that a bit
[16:41]  * hazmat attention is gripped by tosca meeting
[16:42] <fwereade> hazmat, natefinch: ok, modulo d- asserts, we sound like we'll be fine with the serializable level
[16:43]  * fwereade needs to go out anyway
[16:43] <fwereade> thanks for clearing that up, I didn't get that impression from the descriptions
[16:43] <fwereade> I guess we need to be careful about what we *do* read when we're in a txn then..?
[16:44] <natefinch> fwereade: well, generally you don't just read stuff for no reason.  You read stuff because the logic depends on the contents
[16:44] <fwereade> natefinch, ok, but sometimes you read an easy-to-express superset of what you need and extract in code
[16:44] <hazmat> fwereade, it maybe we need to do separate collection level locks for insert
[16:44] <natefinch> it's funny, Toku has an office in Lexington.. I could like, drop down there and say hi
[16:45] <fwereade> natefinch, if that's going to quietly take a bunch of locks we should be aware of it
[16:45] <natefinch> fwereade: that's true
[16:45] <hazmat> fwereade, i'd like to define the common scenarios and patterns we have
[16:46] <fwereade> hazmat, I can live with that, I'm just fretting because I want to be sure we've got answers for all these things ;)
[16:46] <hazmat> and then verify solutions.. common idioms for them with tokumx
[16:46] <fwereade> hazmat, that would probably be the smart thing to do, indeed -- natefinch, are you ok to try to build those up?
[16:46] <fwereade> natefinch, would be happy to discuss in more detail
[16:46] <fwereade> natefinch, ...but not now
[16:47]  * fwereade disappears in a puff of smoke
[16:47] <hazmat> fwereade, natefinch should i setup a call for tomorrow?
[16:47] <natefinch> fwereade: see ya
[16:47] <natefinch> fwereade: yeah
[16:47] <hazmat> fwereade, cheers
[16:48] <hazmat> done
[17:01] <jcw4> mgz, cmars fix for lp-1355521 https://github.com/juju/juju/pull/500 , ptal
[17:03] <mgz> jcw4: you can jfdi that through if you want
[17:03] <ericsnow> natefinch: one-on-one?
[17:03] <jcw4> mgz: tx
[17:06] <jcw4> mgz tx again :)
[17:07] <mgz> :)
[17:12] <natefinch> ericsnow: sorry, coming
[17:31] <wwitzel3> woohoo! I'm down to permission issues
[17:41] <wwitzel3> victory is mine!
[17:50] <natefinch> wwitzel3: nice!
[17:53] <perrito666> sinzui: I would prett much guess that the cause for restore to no longer finish is https://github.com/juju/juju/commit/55a9507924dea63658598361797ec864b9879e84#diff-d41d8cd98f00b204e9800998ecf8427e
[17:54] <wwitzel3> natefinch: yeah, the outchannel command cannot take arguments, so you have to do it as a script. also if outchannel encounters a non-zero exit code from the script, it assumes the channel is bad and stops sending to it. Until you restart/reload.
[17:54] <natefinch> huh ok, so your script wasn't returning 0 I guess?
[17:54] <wwitzel3> natefinch: and lastly, the logrotate conf itself, must have the right set of permissions.
[17:55] <wwitzel3> natefinch: right, it wasn't because of a permission issue, which was just being thrown away
[17:55] <natefinch> ahh
[17:55] <sinzui> perrito666, I just got permission to merge my log recovery changes. The next runs of the recovery tests will try to get logs from that machine that restore created
[17:56] <sinzui> perrito666, yes, the commit does look like it relates to the vague error in the jenkins console
[17:56] <wwitzel3> natefinch: so it had 3 issues, but I just had to discover them in the right order.
[17:57] <wwitzel3> natefinch: for example, at first I was calling logrotate as my command and passing it arguments ... logrotate was being called and returning 0 so logging continued, but the actual conf wasn't being passed.
[17:58] <perrito666> voidspace: care to shed some light on the commit?
[17:58] <perrito666> it has your name
[17:58] <wwitzel3> natefinch: then finally burried in the documentation for outchannel I found an small italic note about the fact outchannel command can't take any arguments.
[17:59] <wwitzel3> oh and the issue with logrotates default state file path, that was easy though once I was actually able to start getting debug output from the rsyslog outchannel executing the command.
[17:59] <natefinch> yeesh
[18:00] <natefinch> I think you should write all that up and put it on juju-dev, so that someone else has a chance of understanding everything later.... and actually, a big comment in the code about it wouldn't hurt either.
[18:01] <wwitzel3> natefinch: so the rsyslog cert and key, live in the log folder even though they aren't logs.
[18:01] <natefinch> or in the docs somewhere... something
[18:01] <natefinch> wwitzel3: nice
[18:01] <wwitzel3> natefinch: so I assume it is ok for the logrotate.conf to live there too?
[18:02] <wwitzel3> natefinch: also the logrotate helper script that runs logrotate with the juju conf.
[18:03] <wwitzel3> natefinch: yeah I was planning to document the behavior of outchannel and ref the docs as well as the permission requirements for the logrotate.conf and state file.
[18:04] <wwitzel3> natefinch: since I also need to document the existence of all-machine.log.1 and the max size, etc..
[18:04] <natefinch> ahh yep, definitely
[18:04] <natefinch> and yeah, we can put more stuff in there if there's already non-logs in there
[18:05] <tych0> h
[18:23] <hazmat> wwitzel3, you get your rsyslog issues resolved?
[18:53] <wwitzel3> hazmat: yep, thanks :)
[19:13]  * sinzui kicks CI to test ha and restore now
[19:15] <natefinch> sinzui: I have a possible fix for the other bug too
[19:15] <natefinch> sinzui: https://github.com/juju/juju/pull/501
[19:18] <natefinch> perrito666, ericsnow, wwitzel3: one of you want to review? ^^  really simple change with a test and everything.  I don't actually know why the code worked before and then suddenly stopped working, but at the very least this is a change that won't break anything and has a test to make sure it continues working.
[19:19] <natefinch> super simple change
[19:19] <ericsnow> natefinch: sure
[19:20] <natefinch> test verified to panic on the old code, just like in comment #18 here: https://bugs.launchpad.net/juju-core/+bug/1347715
[19:20] <natefinch> (and test verified not to panic with the new code)
[19:21] <natefinch> aside:  I wish the comments on launchpad bugs were anchors, so I could do <bug-url>#comment-18 and have it jump directly to the comment. Instead the comment numbers just open up a separate window with no context which is completely useless.
[20:48] <thumper> morning folks
[20:53] <thumper> sinzui: you around?
[20:54] <sinzui> I am
[20:56] <thumper> sinzui: what's the tl;dr on CI status?
[20:57] <sinzui> thedac, 2 blockers, natefinch's fix for 1 is queue to play in the next hour
[20:58] <natefinch> thumper: here's the fix... though I admittedly don't know why it worked before: https://github.com/juju/juju/pull/501
[20:58] <sinzui> thumper, my effort to get more logs from the failed restore tests also failed. no new data
[20:58]  * thumper takes a quick look
[20:58]  * sinzui wishes --debug didn't leak certs, keys, users, and passwords
[20:59] <natefinch> sinzui: me too
[20:59] <natefinch> I gotta run
[20:59] <natefinch> good luck everyone, and good night
[21:00] <thumper> sinzui: so the remaining CI failure is a restore one?
[21:01] <sinzui> thumper, yes https://bugs.launchpad.net/juju-core/+bug/1355324
[21:01] <sinzui> thumper, the test is playing right now. I hope to ssh in at the right moment and cat the logs
[21:01] <thumper> kk
[21:13] <waigani> thumper: welcome back!
[21:13] <menn0> thumper, waigani: good morning
[21:13] <thumper> o/
[21:13] <waigani> morning :)
[21:16]  * thumper headdesks
[21:51] <sinzui> perrito666, I added logs to bug 1355324. Tomorrow I am going to investigate redirecting all stderr to a private location on disk to try --debug
[21:59] <perrito666> sinzui: the rev I pointed is the culprit, it appears that we no longer have mongo listening on StatePort and therefore restore can not connect to It I need to get voidspace or fwereade to find out more about it
[22:00] <thumper> perrito666: why isn't mongo listening?
[22:00] <sinzui> perrito666, okay. that right, I have too much going on to keep my work list clear
[22:00] <perrito666> thumper: I dont think its not listening, we are no long publicizing the port I believe
[22:01] <perrito666> thumper: https://github.com/juju/juju/pull/449/files
[22:01] <sinzui> thumper, we agreed some months ago that nothing is allowed to talk to mongo directly...but restore does
[22:01] <ericsnow> perrito666: from the PR it sounds like it's not even listening on external ports
[22:02] <perrito666> ericsnow: I really need to dig more into this otherwise I am talking in educated guesses
[22:03] <thumper> ah...
[22:03] <thumper> didn't I see a change where mongo only listened internally?
[22:03] <ericsnow> perrito666: https://github.com/juju/juju/pull/449#issuecomment-50825367
[22:03] <thumper> like only on localhost?
[22:03] <ericsnow> perrito666: "I've also confirmed that with current master I can telnet to port 37017, and that with this branch I can't."
[22:03] <perrito666> not even a day running ubuntu on this machine and I already have unity behaving oddly.. that must be a record for a fresh install
[22:03] <thumper> ericsnow: that's the one
[22:04] <perrito666> thumper: sounds to me that not even, which puzzles me a bit unlessss
[22:04] <perrito666> api is using direct connection
[22:04] <perrito666> I dont know if direct is the right name
[22:04] <ericsnow> perrito666: yeah, that's what I find weird
[22:04] <ericsnow> thumper: yep, that's the PR for the changeset that broke restore
[22:05] <perrito666> thinkpads ability to swap fn/ctrl on the bios is marvelous
[22:06] <thumper> ericsnow, perrito666: simplest thing IMO is to revert PR 449
[22:07] <thumper> and take a fresh look later at closing the port
[22:07] <thumper> better than trying to work out now how to selectively open it
[22:09] <perrito666> I guess there is no other option, also by doing this I can get the original author to grep again for the use of StatePort :p
[22:10] <ericsnow> perrito666: yeah, tell him about that grep thing ;)
[22:12] <ericsnow> thumper, perrito666: +1 on reverting
[22:12] <ericsnow> (too bad another blocker will show up before I have a chance to merge anything tomorrow <wink>)
[22:15] <perrito666> ok, let me have a late evening snack and Ill propose the revert
[22:15] <perrito666> btw, did I mention I have the eating habits of a hobbit?
[22:40] <perrito666> so, to revert we do a reverse pr or use the "sorry I screwed up, please undo" feature from github
[22:44] <thumper> perrito666: um... there is a github feature?
[22:44] <thumper> perrito666: I'd have just done a reverse PR
[22:44]  * thumper goes to make a coffee
[22:44] <perrito666> thumper: I saw github offering me to undo with a button the other day
[23:02] <thumper> waigani: standup hangout time
[23:11] <perrito666> how do I reference a ticket/pr on a pr description
[23:11] <perrito666> ?
[23:16] <perrito666> sinzui: or anyone
[23:16] <perrito666> the $$fixes tag is to be added into the $$merge or in the pr description?
[23:17] <sinzui> perrito666, fixes-nnnnn
[23:17] <sinzui> perrito666, in a comment by itself or with other text
[23:17] <perrito666> sinzui: yup, but, that is to be added into the pr body or into the merge comment?
[23:17] <perrito666> my question is, will that trigger the merge?
[23:17] <sinzui> merge comment perrito666
[23:18] <sinzui> perrito666, it doesn't trigger a merge.
[23:18] <sinzui> perrito666, $$merge$$ to trigger the merge and fixes-nnnnnn ti explain why the merge is valid
[23:19] <perrito666> tx sinzui
[23:19] <perrito666> ok anyone ptal https://github.com/juju/juju/pull/503
[23:29] <ericsnow> I'm signing off, but if anyone is able, ptal @ https://github.com/juju/utils/pull/16 https://github.com/juju/utils/pull/19 https://github.com/juju/juju/pull/462 https://github.com/juju/juju/pull/453
[23:29] <sinzui> perrito666, I just discovered the first comment is not a comment according to github api. I can see ericsnow is the first comment, and my test comment is the second
[23:30] <perrito666> sinzui: that is why I did not add the $$ fixes part, I will add it in the merge comment
[23:40] <sinzui> perrito666, okay. I am a little disappoint because I think it is nice to state in the first comment why the branch should be merged :/
[23:52] <menn0> testing... please ignore: bug 1347715
[23:52] <mup> Bug #1347715: Manual provider does not respond after bootstrap <bootstrap> <ci> <regression> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1347715>
[23:52] <menn0> \o/ (fixed!)
[23:53] <perrito666> thumper: that is not going to work
[23:53] <perrito666> you did not add the $$fixes-###$$


[00:00] <bryce> ah ok
[00:00] <bryce> I've got new versions I should upload... maybe I'll request bug reporters test them and then upload monday
[00:01] <Sarvatt> vbox nvidia bcmwl so far, found a fix for vbox in svn that i put up a bug about, still trying to load the darn page with the nvidia patch that people say is working to try that out
[00:01] <bryce> oh wow, today's DebianImportFreeze.  bummer
[00:01] <Sarvatt> wow
[00:03] <Sarvatt> http://www.nvnews.net/vbulletin/attachment.php?attachmentid=37305&d=1245688007
[00:04] <Sarvatt> works, woohoo
[00:06] <bryce> looks quite simple too
[00:07] <Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?t=134779
[00:07] <Sarvatt> will have to see if theres any problems with it later though, compiled it remotely
[00:12] <bryce> weird, nvnews.net isn't loading for me
[00:12] <Sarvatt> yeah it took almost an hour for that page to load
[00:12] <bryce> ah must be popular ;-)
[01:48] <Sarvatt> 1028 objects
[01:48] <Sarvatt> 145694720 object bytes    after 4 hours of compiz running, memory leak is for sure gone here
[01:54] <bryce> cool
[01:54] <bryce> I'm finalizing a script to request retesting on most of the -intel bugs
[02:45]  * hyperair grumbles about modprobe hanging and an oops on the .31 kernel
[02:45] <hyperair> =(
[02:45] <hyperair> i can't even boot it
[02:45] <jbarnes> Sarvatt: I'm up to ~1G of objects
[02:45] <jbarnes> well over 3000
[02:46] <hyperair> jbarnes: on which kernel/mesa?
[02:46] <Sarvatt> wow
[02:47] <Sarvatt> mesa 7.6.0~git20090624.bc5c40d7-0ubuntu0sarvatt ?
[02:47] <jbarnes> kernel from today
[02:47]  * jbarnes gets versions
[02:47] <jbarnes> 2.6.30-10-generic
[02:48] <jbarnes> how do I get full version info?
[02:48] <jbarnes> dpkg -l truncates things
[02:48] <jbarnes> dpkg -S doesn't show full version info
[02:49] <jbarnes> 7.6.0~git20090623.4f1e141c-0ubuntu0sarvatt
[02:49] <jbarnes> apt-cache policy I gues
[02:49] <Sarvatt> oh you're on x64 arent you
[02:49] <Sarvatt> it took 24 hours for the darn x64 0624 to build
[02:50] <Sarvatt> in 0623 i was just cherry picking 2 of the memory leak fixes from 7.5 branch, but 0624 has the merge of 7.5 into 7.6 so maybe there was something else in there
[02:50] <Sarvatt> http://launchpadlibrarian.net/28299189/mesa_7.6.0~git20090623.4f1e141c-0ubuntu0sarvatt_7.6.0~git20090624.bc5c40d7-0ubuntu0sarvatt.diff.gz
[02:52] <Sarvatt> actually, i wonder if me using      Option  "SwapbuffersWait"       "false" has something to do with it too, i've never ever seen gem_objects staying so low
[02:53] <jbarnes> no that doesn't affect object creation
[02:58] <Sarvatt> interesting that Always free image offsets memory when re-initializing texture image fields. and Also release direct rendering resources in glXDestroyGLXPixmap. werent enough to fix the leak then if it ends up being fixed for you in the 0624 one like it is for me
[02:59] <jbarnes> just upgraded, I'll check tomorrow
[03:00] <Sarvatt> 945?
[03:00] <jbarnes> gm45
[03:00] <jbarnes> err g45
[03:09] <hyperair> jbarnes: you need a .31 kernel to fully avoid the gem object leak thing, from my experience =\
[03:10] <hyperair> jbarnes: well i'm actually using a kernel labelled as 2.6.30-sarvatt5
[03:11] <Sarvatt> that was june 21st linus git
[03:13] <Sarvatt> guess i could reboot to the ubuntu kernel to see if thats true, i dont think it is though..
[03:18] <Sarvatt> 144 objects
[03:18] <Sarvatt> 50532352 object bytes
[03:18] <Sarvatt> i used to get over 300mb just starting compiz
[03:21]  * RAOF should make nouveau-kernel-source's get-orig-source do something more smart than cloning a kernel repository and throwing almost all of it away.
[03:42] <Sarvatt> not much more of an option right now is there? seems to be in a transition stage
[03:49]  * hyperair has it at ~300M most of the time
[04:04] <Sarvatt> now that is an amazing amount of new email from ubuntu-x-swat :)
[04:07] <Sarvatt> 453 objects
[04:07] <Sarvatt> 78503936 object bytes --- 50 minutes later opening and closing stuff with compiz on under 2.6.30-10
[04:11] <Sarvatt> switched to gnome-shell to see how leaky this is these days, clutter had some problems not long ago
[04:13] <bryce> Sarvatt, scary thing is I haven't run the script I mentioned yet...
[04:15] <Sarvatt> 852 new mails now, lets see how many after the intel bug script of doom :D
[04:21] <bryce> hehe
[04:21] <bryce> actually it'll be even worse
[04:21] <bryce> now I have -fglrx and -nvidia scripts too
[04:21] <bryce> just doing the final dry runs now, and will be unleashing them soon
[04:22] <bryce> we're probably going to get a lot of feedback over the next week or so; hopefully it's mostly "looks like it's fixed now".
[04:23] <Sarvatt> well at least its not right after a big change breaking things like the mesa update, would have lost that crash trend in the noise :D
[04:23] <bryce> yeah
[04:23] <bryce> also I figure it's good to get -nvidia and -fglrx tested before the new kernel hits
[04:24] <bryce> after that we're gonna have to wait a good bit of time before we can have folks retest
[04:28] <bryce> bug 363467 is the first one notified so far
[04:47] <Sarvatt> anyone used gnome-shell? would like to figure out a way for it to use external gconf schemas so i can change the settings around, menus just a bit too big on a netbook
[04:49] <Sarvatt> oh sheesh, first link on google has a hack around for it
[04:58] <bryce> heh
[04:58] <bryce> 99  bugs changed for  fglrx-installer
[04:59] <Sarvatt> 100 more new emails :D
[04:59] <Sarvatt> beat me to it
[05:00] <bryce> just wait... the -intel and -nvidia scripts are still running
[05:03] <bryce> I'm probably seriously choking up launchpad's email server
[05:14] <Sarvatt> would it help any to come up with a symptoms list of changes for -intel in new kernel revisions to match in the scripts? like .31-rc2 has suspend/resume fixes, hdmi detection, tv problems, an agpgart module order fix, 31-rc1 has gem pae support, a cursor corruption on resume fix, displayport, tv/vga detection fixes
[05:16] <bryce> 160  bugs changed for  nvidia-graphics-drivers-180
[05:17] <bryce> yeah that'd totally help
[05:24] <bryce> 126  bugs changed for  xserver-xorg-video-intel
[05:56] <hyperair> there's an rc2 already?
[06:49] <Sarvatt> nah just new stuff since rc1
[09:52] <RAOF> OK.  These intel freezes are becoming increasingly frequent and annoying.
[10:55] <Ng> RAOF: with what? karmic+KMS with dpms disabled is proving to be extremely reliable atm :)
[10:55] <Ng> (although I am a kernel behind and had to disable dpms ;)
[10:55] <RAOF> Ng: Karmic+KMS.  There was a week or so where this combination was silky smooth.  Now, not so much.
[10:57] <Ng> RAOF: where are you seeing the freezes?
[10:57] <RAOF> Resume now almost always fails, and now random lockups during regular useage are getting more frequent.
[10:57] <Ng> huh
[10:58] <Ng> I'll play with -10 over the weekend, but I can't risk my stability today ;)
[10:58] <Ng> (I'm doing a very careful karmic dance on my work laptop)
[18:46] <yoasif> hey guys... how can i best report a problem with the nouveau drivers (not working on my machine(
[19:11] <Sarvatt> hooo boy 2.6.31-rc1 in karmic now :D the bugs are going to go nuts with all of the things that cant build against it, no nvidia and i imagine ati blobs, bcmwl, vbox
[19:50] <Sarvatt> hmm, linux-libc-dev now replaces libdrm-dev even though libdrm-dev ships more things than linux-libc-dev does
[19:50] <Sarvatt> (on the drm side)
[19:52] <Sarvatt> guess it shouldnt be a problem because it pulls libdrm-dev later than linux-libc-dev on the PPAs? or am I going to have to add a Replaces: linux-libc-dev again to libdrm-dev to compile things
[19:56] <Sarvatt> looks like thats an old change i just noticed so it shouldnt matter because things are working :D
[20:16] <Sarvatt> bryce: i updated intel-gpu-tools on edgers, saw someone asking you about a newer version earlier but i closed whatever channel it was so i dont remember the name
[20:20] <Sarvatt> Depends: libpciaccess0 (>= 0.10), libdrm-intel1 (>= 2.4.9), libc6 (>= 2.4), libdrm2 (>= 2.3.1)
[20:20] <Sarvatt> hmm it doesnt need that libdrm2 depend
[20:21] <Sarvatt> guess it doesnt matter, everyone with libdrm-intel1 is going to have it
[20:31] <bryce_> Sarvatt: cool
[20:32] <bryce_> Sarvatt: if you'd like to prepare a debdiff of that I'll sponsor it straight away for you
[20:32] <Sarvatt> oh i just packaged it quickly and didnt even make an orig.tar.gz, how would you want it to be named? the version is still 1.0.1 but theres git updates past it
[20:33] <bryce_> ah interesting
[20:34] <bryce_> version would be 1.0.1+gitBLAH-0ubuntu1, but let's check first if debian has packaged it
[20:34] <Sarvatt> 1.0.1+git20090626-0ubuntu1 and add all the changes to the changelog?
[20:35] <Sarvatt> i looked there first and couldnt find it, where did you merge it from debian at?
[20:35] <Sarvatt> anholts intel-gpu-tools-debian?
[20:36] <bryce_> yeah
[20:36] <bryce_> oh right, hasn't been accepted into debian yet
[20:36] <bryce_> yes that looks like a good version number
[20:36] <Sarvatt> yeah he hasnt updated intel-gpu-tools-debian yet, i used debian/ from your package
[20:37] <bryce_> ok
[20:37] <Sarvatt> i also added a git log > ChangeLog and installed it in debian/rules dh_installchangelogs, should i skip that step?
[20:37] <bryce_> no that's good
[20:38] <bryce_> in fact if you include the ChangeLog you probably don't need to mention much in debian/changelog... just keep to important highlights
[20:39] <bryce_> jcristau: any reason you guys aren't including intel-gpu-tools?  should we be sending our debian/ changes upstream for it?
[20:40] <Sarvatt> tar --exclude=debian --exclude=debian/* --exclude=.git --exclude=.git/* -cf - intel-gpu-tools | gzip -9 >intel_gpu_tools_1.0.1+git20090626.orig.tar.gz
[20:40] <Sarvatt> would that be the correct name for the orig.tar.gz?
[20:41] <Sarvatt> oh sorry intel-gpu-tools
[20:41] <Sarvatt> intel-gpu-tools_1.0.1+git20090626.orig.tar.gz
[20:47] <bryce_> that may be fine; I usually split it up into several steps
[20:47] <bryce_> mv $dir intel_gpu_tools_1.0.1+git20090626 ; rm -rf .git debian/ ; gzip -9 ...
[20:47] <bryce_> that way the directory is named correctly.  However I suspect it may not matter
[20:48]  * bryce_ is happily closing many bugs from replies to yesterday's bug spam
[20:52] <jbarnes> hm things seem a little better so far
[20:52] <jbarnes> ~2700 objects weighing in at around 400M
[20:54] <Sarvatt> 971 objects 271MB here on the 2.6.30-10 kernel so it wasnt -31 specific at least in my case
[20:55] <Sarvatt> bryce: http://sarvatt.com/downloads/intel-gpu-tools_1.0.1+git20090626-0ubuntu1.debdiff   https://edge.launchpad.net/%7Esarvatt/+archive/ppa/+sourcepub/660025/+listing-archive-extra
[20:58] <Sarvatt> jbarnes: here is the diff between 0623 and 0624 incase you want to track down where the fix was, anything that doesnt say cherry-pick in the changelog was new https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+files/mesa_7.6.0~git20090623.4f1e141c-0ubuntu0sarvatt_7.6.0~git20090624.bc5c40d7-0ubuntu0sarvatt.diff.gz
[20:59] <Sarvatt> i pulled Always free image offsets memory when re-initializing texture image fields. and Also release direct rendering resources in glXDestroyGLXPixmap. into 7.6 by hand in the 0623 one so it wasnt those unless they needed other changes to go with it as well
[21:00] <Sarvatt> all the ones that say (cherry picked from commit x) in the changelog were already in 7.6 i mean
[21:04] <Sarvatt> i need to turn part messages back on, you probably werent even here when i said all that jbarnes :D
[21:04] <jbarnes> heh yeah I crashed right after looking at my mem usage
[21:04] <jbarnes> I think virtualbox grabbed my input and didn't give it back
[21:05] <jbarnes> I'm on 624 now
[21:05] <jbarnes> the changelog was big so I didn't bother looking through it
[21:05] <Sarvatt> yeah sounds like things are better now but still crap on 0623, thats a heck of alot of objects though
[21:06] <Sarvatt> 911 objects
[21:06] <Sarvatt> 278081536 object bytes  after 17 hours uptime with compiz
[21:07] <jbarnes> 965 render probably generates lots of objects
[21:07] <jbarnes> you're on 945 right?
[21:07] <Sarvatt> yeah 945GME, aspire one netbook
[21:08] <Sarvatt> woohoo 7.5-rc4 mesa, that was sorely needed
[21:09] <Sarvatt> they pulled in like 50 intel fixes and updates after rc3
[21:12] <Sarvatt> would texture tiling increase object size? it was disabled on 965+ in the 0624 one but not 0623
[21:12] <jbarnes> only slightly on 965
[21:12] <jbarnes> 945 is the one that really bloats with texturing
[21:15] <bryce_> 7.5-rc4 - sweetness
[21:17] <Sarvatt> surprised it wasnt the 7.5 release
[21:17] <bryce_> kees has uploaded a fixed read-edid package that works on amd64 :-)
[21:20] <Sarvatt> bryce_: i noticed you did the dri.pc install differently, the way we've been doing it on the hook was taken from debian-experimental mesa 7.5 by adding usr/lib/glx/pkgconfig/dri.pc usr/lib/pkgconfig/ to libgl1-mesa-dev.install, just aheads up whenever you guys merge 7.5 into the ubuntu branch
[21:20] <Sarvatt> reworking the hooks in auto-xorg-git now to cope with all these changes :)
[21:21] <bryce_> ok
[21:28] <Sarvatt> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=commit;h=537f3e7a1ef969b191f3d751f17563ab620d3676
[21:33] <Sarvatt> ah they probably want to update the 7.5 release note docs before final :D
[21:34] <bryce_> Sarvatt: cool, we can drop our change in favor of those when we update
[21:48] <Sarvatt> i should have learned my lesson about not updating things until PST work hours are over :D
[21:50] <Sarvatt> can only upload new full source packages if the commit id is numerically higher or i fudge the version with a .r1 between +gitxxxx and the 8 digit commit id :D
[21:51]  * Sarvatt jumps to japan real quick where its the 27th.
[22:26] <Sarvatt> bryce_: did you see 2.6.31-11.13 up on karmic-changes? incoming bugs from anything building modules using the old net_device api, block layer, i2c or agpgart not working anymore (nvidia and fglrx especially)
[22:30] <bryce_> yeah I've adopted the practice with ppas to always append a ~1 or something
[22:30] <bryce_> the times when I've failed to do it always end up being the times when I end up needing to do a ~2 ;-)
[22:31] <bryce_> Sarvatt: yeah jj mentioned .31 was in flight
[22:37] <Sarvatt> i'm going to be surprised if xserver 1.6.2 gets released before karmic at the rate things are going, much less a 1.7 branch starting..
[22:38] <Sarvatt> with XI2 <IP_ADDRESS> every input driver needs updating to work with it and they've only updated evdev mouse synaptics acecad and joystick so far a week or so after that came out
[22:39] <Sarvatt> ThJaeger fixed up wacom to work with it and sent me a package for the PPA that works good
[23:08] <Sarvatt> superm1: are you around?
[23:09] <Sarvatt> regarding your bug here https://bugs.edge.launchpad.net/bugs/385658
[23:09] <Sarvatt> the problem is xserver-xorg-video-nv has the pci id installed for your GeForce 9200M GS device, but the PC wants to use the IGP instead
[23:09] <Sarvatt> which isnt supported
[23:11] <Sarvatt> I can make a patch for xserver so it falls back to vesa for all 084x and 086x nvidia devices which would fix it in the case of not having an xorg.conf and -nv not installing pci ids, but its kind of tricky while we are installing pci ids with the driver
[23:13] <Sarvatt> nv works fine for the 9200M GS device though, i dont know what the preferred solution would be because its a really tricky situation
[23:14]  * hyperair groans
[23:14] <hyperair> ccache rocks, right up til the point where you end up with truncated files in .ccache because your comp overheated and died, and ext4 likes leaving truncated files around
[23:15] <Sarvatt> bryce_: do you have any ideas on how we should handle the situation there in that bug?
[23:16] <Sarvatt> superm1: if you have a machine to test it on, can you try using xorg-edgers to see how it handles it? the -nv driver in there does not install pci ids
[23:16] <bryce_> hmm
[23:16] <Sarvatt> all 084x and 086x nvidia devices dont work in -nv, but its binding -nv to it because the 9200M GS does work fine but the PC is a hybrid and wants to use the IGP to save power by default
[23:17] <bryce_> Sarvatt: regarding xserver 1.7, well good to have the head's up on it, sounds like we want to wait a bit longer.  Maybe we could formalize your ppa a bit more for enterprising souls to test with, but I don't know of much in 1.7 that's a must-have for karmic
[23:19] <Sarvatt> they pulled the dri2 updates into server_1_6_branch so there isnt much more in 1.7 on the graphics side IMO
[23:19] <Sarvatt> there is a list of proposed pulls from master into 1.6 branch that we could look into adding to 1.6.2 in karmic http://www.x.org/wiki/Server16Branch
[23:20] <Sarvatt> the front buffer rendering fixes and dri2proto 2.1 were what i was worried about that lead to me making the PPA for master in the first place
[23:22] <Sarvatt> yeah my PPA needs some work to get testing done, alot more components build now and i havent reviewed the patches to see why things dont apply, if they were upstream or just need refreshing or didnt apply at all anymore due to changes
[23:23] <Sarvatt> its just centered around a works for me scenario and doesnt take into account that people might actually use xephyr or kdrive and such :D
[23:24] <bryce_> yeah at some point during the release cycle I'll shift focus to xserver crash bugs, and agreed we should look into pulling patches from that proposed branch
[23:26] <bryce_> hopefully if there's no 1.7 in time we at least see a 1.6.2 out.
[23:26] <Sarvatt> i dont think xserver 1.6.2 is far off from release, kpackard was saying he wanted to get it out the door that day in #xorg-devel last week but didnt happen, they pulled the dri2 stuff into 1.6 branch post <IP_ADDRESS>1 that we have though
[23:26] <Sarvatt> sorry keithp :)
[23:28] <Sarvatt> superm1's bug is tricky, does anyone know if there is no pci id file but an xorg.conf exists if the internal xserver detection mechanisms will work similar to not having an xorg.conf in that situation?
[23:28] <Sarvatt> because if so adding a switch and case check for 0840 and 0860 id's to make them default to vesa in xserver will work
[23:28] <Duke`_> Sarvatt: no new mesa 7.5 build for jaunty? (last one is from june 22nd)
[23:29] <Sarvatt> i just uploaded a new one!
[23:29] <Sarvatt> did it not take?
[23:29] <Duke`_> Sarvatt: ah yes I got it!
[23:29] <Sarvatt> mesa - 7.5.0~git20090626+mesa-7-5-branch.2d865034-0ubuntu0sarvatt
[23:29] <Duke`_> I checked 10 minutes ago and there was nothing :p
[23:29] <Sarvatt> :)
[23:29] <Sarvatt> lol yeah it was building
[23:30] <Duke`_> thx!
[23:30] <Sarvatt> no worries!
[23:30] <Sarvatt> sorry i'm a little negligent about updating jaunty
[23:30] <bryce_> Sarvatt: I'm looking at superm1's bug currently...
[23:31] <Sarvatt> if i could get him to confirm it works right when nv.ids isnt installed it'd be a _really_ simple fix
[23:31] <bryce_> the 170_primary_pci_video_device.patch patch jerone said fixed it in jaunty is still present in karmic...
[23:31] <Sarvatt> the patch that actually fixed it in jaunty was default_to_vesa
[23:31] <bryce_> Sarvatt: think he's in texas so maybe he's off work at happy hour or something ;-)
[23:31] <Sarvatt> ahh
[23:31] <bryce_> ahh
[23:32] <bryce_> jinx
[23:32] <Sarvatt> :D
[23:32] <Sarvatt> 0840 and 0860 ids need to  be explicitly defaulted to vesa instead of nv really bad
[23:32] <bryce_> ok
[23:33] <Sarvatt> they already are by the nv.ids not matching but it screws up when its a hybrid and the unused device actually is supported by nv
[23:33] <Sarvatt> (since its the first device out of the two)
[23:33] <bryce_> *&$^ hybrids
[23:36] <bryce_> ;-)
[23:37] <Sarvatt> how fedora does it -- they dont install ids, and they add a check for 084x and 086x devices in hw/xfree86/common/xf86AutoConfig.c in xserver and tell it to use vesa if those match
[23:37] <Sarvatt> instead of "case 0x10de: case 0x12d2:   driverList[0] = "nv";	break;" which matches nvidia unconditionally, they have it doing
[23:38] <Sarvatt> http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/F-11/xserver-1.6.1-nouveau.patch?view=markup
[23:38] <Sarvatt> easier that way
[23:38] <Sarvatt> too much to paste :D
[23:38] <bryce_> looking
[23:38] <Sarvatt> the bottom part
[23:39] <Sarvatt> top part is just to shut up a nouveau AIGLX error in xorg.0.log because there is no dri for nouveau
[23:39] <bryce_> right
[23:40] <Sarvatt> doesnt help he works for dell and they have a thing for these silly hybrids that the x people refuse to work with :D
[23:40] <bryce_> yeah sure we could do something like that
[23:40] <Sarvatt> thats only going to fix it if the nv.ids isnt installed though
[23:40] <Sarvatt> as far as i can see
[23:41] <Sarvatt> because it'll still try to use nv because the not in use device is matched as supporting in nv.ids
[23:41] <Sarvatt> it might _just work_ magically if the nv.ids isnt installed and the driver can do its detection methods instead of getting matched in the id's and forced though
[23:41] <Sarvatt> which is what i'm unsure of
[23:42] <bryce_> yeah, might be worth experimenting with
[23:42] <bryce_> I'm really not certain how we should handle *.ids for karmic
[23:42] <bryce_> guess we need to come to a decision on that
[23:42] <Sarvatt> i'll copy -nv from edgers without the nv.ids install and ask him to try that
[23:43] <bryce_> if we're going to drop *.ids processing, then we may as well move ahead with that now, so we can get stuff straightened out by alpha-3
[23:43] <bryce_> ok
[23:43] <Sarvatt> ids are really bad if you ask me in some instances because every driver seems to handle it differently in the post pciaccess world, dropping nv.ids from -nv is going to open up ALOT more chips working right with -nv
[23:43] <bryce_> if we're going to keep .ids's for karmic, then maybe we need to look into improving the heuristics to account for the hybrid hardware better
[23:44] <Sarvatt> but it looks like ati handles ids being installed fine because they add everything to a table that can extract it right
[23:44] <bryce_> can we drop .ids support on a per-driver basis?
[23:44] <bryce_> maybe we should do it for -nv first to test the waters?
[23:44] <Sarvatt> -nv has a ton of case checks for supported cards and doesnt add them to the table that 01_gen_pci_ids.diff pulls the ids from
[23:46] <Sarvatt> plus debian has dropped pci id installs globally in every driver that i've seen and is working to fix the server detection methods instead of using that hack
[23:46] <bryce_> mm
[23:46] <Sarvatt> tjaalton and jcristau are the ones to ask really, i'm not knowledgeable enough about it to give an opinion on it, just seeing the problem in -nv with it gone and it looks like dropping it in -nv helps alot
[23:51] <Sarvatt> i _really_ think this bug is bogus and the patch should be dropped from -nv by the way https://bugs.edge.launchpad.net/bugs/321613
[23:52] <Sarvatt> (9100m G falls under 0840 and 0860 that dont work in -nv that fedora explicitly makes use vesa in that patch i linked above)
[23:54] <Sarvatt> i'll copy nv without the nv.ids installed to an empty ppa and ask people to try it to get some feedback on dropping nv.ids in karmic for that driver
[23:55] <Sarvatt> its just mainly a problem on the livecd's IMO, who uses -nv outside of that situation? :D
[23:57] <bryce_> Sarvatt: processing your intel-gpu-utils package now... all looks good, only (picky) detail is to indent the second bullet point (about the changelog) one level since it's a ubuntu change since the last version
[23:58] <bryce_> anyway, other than that all looks good... upload sponsored :-)
[23:59] <Sarvatt> oh, I cut and pasted that from your changelog!