[00:54] <Sarvatt> lol man, I feel like an idiot
[00:54] <Sarvatt> i've been trying to get that ati gallium patch working right, but every time i changed it i only installed xserver-xorg-video-ati so i wasn't even testing the new changes :)
[01:00] <Sarvatt> so the little one line change works, here i was rewriting it all
[01:25] <Sarvatt> yep patch looks good to go, can't seem to break it. sent it to dri-devel and xorg-devel
[01:43] <m3ga> i'm trying to boot lucid on a tablet device but something during boot screws up the graphics. i've tried booting with 'single' and 'text' on the kernel command line but that doesn't help.
[01:43] <m3ga> i suspect something in the kernel initialisation is tweaking something it shouldn't.
[01:44] <m3ga> if i put init=/bin/bash on the command line i get a prompt and can remount the usb-key rw. but i'd like to fix this.
[01:44] <m3ga> any clues on how to move forward?
[01:45] <RAOF> m3ga: Try with “nomodeset” on the kernel command line.  That'll disable kernel modesetting, which should stop the kernel touching your display hardware quite so much.
[01:47] <m3ga> RAOF: bingo. I have a login prompt. thanks!
[01:47] <RAOF> m3ga: What hardware is that?  Could you please file a bug?
[01:48] <m3ga> its a 'hanvon B10' tablet. what package should i log a bug against?
[01:49] <m3ga> nice tablet btw. 1.3G Celeron. all intel devices. pretty sure the graphics is *not* gma500.
[01:49] <RAOF> Run “ubuntu-bug linux”.  That'll file a bug against the kernel, which is the problem here.
[01:49] <m3ga> cool. will do.
[02:11] <m3ga> RAOF: false alarm. i was booting the karmic kernel by mistake. the lucid kernel does the right thing even without 'nomodeset'.
[02:13] <Sarvatt> pretty sure its because it has an lvds without a lid so the old karmic kernel just thought there were no screens, they fixed that in .32
[02:14] <m3ga> ah, that makes sense
[02:15] <Sarvatt> i was writing patches for an insane amount of similar chinese knockoff intels with the same problem and was glad they changed the default.. crappy bioses :)
[02:15] <m3ga> now getting a kernel message '[drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 27'
[02:15] <m3ga> is that a crappy bios? :-)
[02:16] <Sarvatt> can just ignore it unless things are broken?
[02:16] <m3ga> ignoring for now
[02:23] <m3ga> RAOF: this is the hardware : http://www.hanvon.com/en/products/touchpad/touchpad_B10.html
[02:56] <Sarvatt> m3ga: can you sudo lspci -vvnn | pastebinit ?
[02:56] <Sarvatt> just curious, looks like a fun toy :)
[02:57] <m3ga> Sarvatt: give me half an hour or so
[03:02] <Sarvatt> most likely the wufu just isnt supported yet without external drivers, vendor id 05E1 prodict id 0100 are the important parts, looking now
[03:19] <bjsnider> wufu?
[03:24] <Sarvatt> m3ga: the drivers are pretty nasty, overwrites policykit, disables your sources and makes you only use their mirror in taiwan, and they only have modules for karmic even though it says its for lucid
[03:27] <Sarvatt> i went over the blobs in the there but it doesnt look like any wifi chipset i know about
[03:28] <Sarvatt> m3ga: just google 3dsp wifi linux and see if you can find any guides, better off just replacing it with anyther card though :)
[03:29] <Sarvatt> Thanks a lot for you using our products. We would like to provide source code to you! but it will be very hard to maintain and support due to its complicacy. and I believe the day we open source code will come soon.
[03:29] <Sarvatt> i like that response :)
[03:42] <Nafai> Hi guys :)
[03:42] <Nafai> so something I upgraded in the last couple of days is causing nvidia-settings to segfault on startup
[03:43] <Nafai> but even after installing the dbgsym package, the gdb backtrace may not be that useful :(
[03:43] <Nafai> http://gist.github.com/438631
[03:51] <bryceh> Nafai, lynx or meerkat?
[03:51] <Nafai> lynx
[03:52] <bryceh> alright, couldn't even begin to guess, sorry
[03:52] <bryceh> I guess, figure out what it was you upgraded and try downgrading it.  ;-)
[03:57] <Nafai> :)
[04:02] <Sarvatt>  nvidia-settings --no-config work?
[04:03] <Nafai> Nope, same problem
[04:03] <Sarvatt> http://ddebs.ubuntu.com/pool/main/n/nvidia-settings/
[04:05] <Nafai> already have that installed :(
[04:11] <Sarvatt> can ya grab debug packages for all of the rest of the depends too and get a bt full?
[04:12] <Sarvatt> i can't reproduce on stock lucid, got any wacky gtk related ppa's enabled? :)
[04:12] <Sarvatt> oh
[04:12] <Sarvatt> ** (nvidia-settings:3303): CRITICAL **: menu_proxy_module_load: assertion `dbusproxy != NULL' failed
[04:12] <Sarvatt> yep its gtk
[04:13] <Sarvatt> iget the same segfault it looks like with geany if i have indicator-appmenu open
[04:14] <Nafai> ah, that probably is it
[04:14] <Nafai> I can do a ppa purge on that
[04:17] <Sarvatt> nvidia-settings is open source btw if you want to figure out why - http://cgit.freedesktop.org/~aplattner/nvidia-settings/tree/
[04:27] <m3ga> Sarvatt: what kind of crack must they be smoking to think that replacing the normal sources.list is acceptable?
[04:30] <Sarvatt> its to stop you from upgrading away from their policykit replac...err rootkit
[04:33] <m3ga> i'm currently evaluating this for the company i work for. if it works out we'd be buying them in lots of 1000
[04:34] <m3ga> i'll come back to wifi after i get X working
[04:36] <Sarvatt> x isnt working?
[04:36] <Sarvatt> well the touchscreen most likely has problems
[04:37] <Sarvatt> RAOF: i'm kind of confused by mesa/LLVM
[04:37] <Sarvatt> i mean, it looks like llvm support is all or nothing
[04:37] <Sarvatt> i see the llvm symbols in the libs and stuff, but llvm isn't getting pulled in as a dep?
[04:37] <RAOF> Well, it certainly wanders all through the code.
[04:38] <RAOF> That seems odd, unless a lot of llvm is inline or something.
[04:39] <Sarvatt> not to mention it looks like enabling llvm makes the gallium stuff x86/SSE2 only so not really compatible with i686 we have going? i dunno
[04:39] <RAOF> Really?  Wow.
[04:39] <RAOF> Well, we could always… build mesa _yet_ another time :)
[04:41] <Sarvatt> i enabled llvm in edgers because it was supposed to speed up swtcl chipsets with r300g but i think i'll back that out for sure.. :D
[05:08] <Sarvatt> i think i hate the nvidia-graphics-drivers build system more than mesa's and it's nothing but shuffling around files...
[05:42] <superm1> Sarvatt, i thought tseliot spent a lot of time cleaning it up the last cycle
[05:43] <superm1> what's janky about it now?
[07:16] <Sarvatt> oh I don't know, the 53 nested variable maze in the rules is fun to maintain when they completely redo the package layout upstream :)
[07:17]  * Sarvatt tries to figure out what PIPE_CAP_DEPTHSTENCIL_CLEAR_SEPARATE is why its busted on nouveau
[07:31] <RAOF> Sarvatt: How far through the fun of forward-porting the intel 2.7 DDX to 1.9 did you get?
[07:32] <Sarvatt> /usr/lib/dri-gallium totally breaks glx over ssh
[07:33] <Sarvatt> good question, i dont remember
[07:33] <Sarvatt> let me try to find where i was working on it
[07:34] <RAOF> Because I was talking to (I think!) ickle in #intel-gfx, and he suggested that an essentially-equivalent task was to add a non-GEM codepath for the current DDX, and that he wasn't averse to participating in such an enterprise.
[07:36] <Sarvatt> sheesh i've got 2663 directories in my git packaging directory, i know i was working on it in a stupid subdirectory like temp8/ or something too
[07:36] <RAOF> Yay organisation! :)
[07:37] <RAOF> Also, there's some more nvidia-graphics-drivers goodness in the xorg apport script now, attempting to detect manually-installed nvidia drivers and grabbing the appropriate logs for forwarding them upstream.  Feel free to suggest improvements.
[07:38] <Sarvatt> why not just make it run nvidia-bug-report and attach those logs? :)
[07:43] <RAOF> Because nvidia-bug-report is a little bit evil.  Particularly - it'll always dump the log in the current directory, whatever that might be.  Also, it's less easy to get at the data in nvidia-bug-report.log.gz
[07:47] <Sarvatt> i can't find anything, guess I didn't do more than 2.8.0 :(
[07:47] <Sarvatt> or i trashed it already
[07:48] <Sarvatt> ah i remember now, i was going through the list then i found http://cgit.freedesktop.org/~airlied/xf86-video-intel/ and got caught up messing with that
[07:48] <RAOF> Is that a 2.2 DDX + patches?
[07:51] <Sarvatt> yeah from RHEL, backported a crapload of kernel changes for new hardware to UMS
[07:51] <Sarvatt> i got kind of discouraged about 2.7.1 because I remembered that was the peak of intel driver crappiness :)
[07:52] <bryceh> peak?
[07:52] <Sarvatt> yeah jaunty!
[07:52] <Sarvatt> i mean both EXA and UXA completely blew and it wasn't hardly usable
[07:52] <bryceh> yep
[07:53] <RAOF> I don't think I _had_ an intel graphics card for Jaunty.
[07:53] <Sarvatt> oh jaunty was 2.6
[07:53] <Sarvatt> http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-14462-8152-19051
[07:54] <bryceh> right, 2.6.  *shudder*
[07:57] <RAOF> Right.  Let's crash i965_dri.so and see if I can't get a better backtrace this time…
[07:58] <RAOF> Gah.  Alternatively, it could be a bug that only appears when not built with -O0
[08:03] <bryceh> Sarvatt, mm - http://people.ubuntu.com/~fta/ppa-dashboard/ubuntu-mozilla-daily--ppa.html
[08:03] <Sarvatt> oh he's been changing that, looked different last i saw it
[08:06] <Sarvatt> oo he released the source! https://code.edge.launchpad.net/~fta/+junk/ppa-dashboard.trunk
[08:10] <RAOF> So, gaussian blur on a GM45 does not provide the world's most responsive desktop environment.
[08:12] <hyperair> 965 doesn't like it either
[08:12] <Sarvatt> i dont even like any blur with ambiance/radiance RGBA
[08:12] <hyperair> rather, it doesn't like any kind of blurring.
[08:15] <RAOF> So, now lets see if using the version built with -O2 segfaults.
[08:18] <Sarvatt> python-launchpadlib in jaunty doesn't support anonymous login :(
[08:22] <Sarvatt> http://sarvatt.com/dashboard/
[08:22] <bryceh> Sarvatt, jaunty?
[08:22] <bryceh> Sarvatt, might be a newer version in a ppa
[08:23] <Sarvatt> yeah latest ubuntu I can run on my VPS since upstart doesn't work in openvz
[08:23] <bryceh> oh bummer
[09:08] <bryceh> yay lp #589811 is fixed
[09:08] <ubot4> Launchpad bug 589811 in xorg-server (Ubuntu Maverick) (and 2 other projects) "My email address is in Xorg.0.log so users email me directly for support (affects: 1) (heat: 281)" [High,Fix released] https://launchpad.net/bugs/589811
[09:28] <Sarvatt> lol
[09:29] <Sarvatt> i dont even see email that isn't labeled anymore because i've got so much like that, got too trigger happy subscribing to bugs for awhile there too :)
[09:31] <Sarvatt> dont think i'll get around to refreshing the lcdfilter patch in cairo, 13 hunks failed
[09:32] <RAOF> Isn't it 1am or somesuch ungodly time where you are?
[09:32] <Sarvatt> and it doesn't build with gcc-4.5 apparently, boo!
[09:32] <Sarvatt> 4:31
[09:32] <Sarvatt> :)
[09:33] <Sarvatt> debian isn't packaging cairo-perf with this, think i'll add that
[09:34] <Sarvatt> people are going to complain if i upload cairo without the lcdfilter patch though :(
[09:34] <Sarvatt> maybe not so much since firefox bundles cairo
[09:34] <seb128> our firefox bundles the lcdfilter patch though
[09:35] <seb128> we got lot of complain when we didn't have it
[09:35] <Sarvatt> yeah thats what I mean, wont be that big a deal since crappy firefox was the big complaint :)
[09:35] <seb128> lol
[09:43] <Sarvatt> what was the trick you guys use to regenerate 99_autoreconf.patch?
[09:44] <hyperair> autoreconf -vfi?
[09:44]  * hyperair doesn't like autoreconf patches, they're bulky.
[09:49] <Sarvatt> yeah same here, just all the darn desktop packages use it. i found it in an old log, cdbs-edit-patch
[09:51] <seb128> Sarvatt, cdbs-edit-patch 99_autoreconf.patch
[09:51] <seb128> autoreconf
[09:51] <seb128> rm -r autom4te.cache
[09:51] <seb128> exit
[09:52] <seb128> Sarvatt, we are moving to run autoreconf in the rules this cycle
[10:22] <Sarvatt> so source format 3 packages get their patches applied at source extraction time? this build kept failing because git checkouts don't work since they weren't applying the patches, plus the clean rule completely doesn't actually clean it
[10:22] <Sarvatt> clean rule does         rm -f *-stamp, stamps are *-stamp-*
[10:58] <Sarvatt> ok no lcdfilter patch is not an option, this is horrible :)
[11:44] <maxb> Sarvatt: The (slightly odd to me) convention that bzr-builddeb is encouraging is to keep the *patched* source package under version control
[11:45] <Sarvatt> oh joy...
[13:34] <tseliot> Sarvatt: have you tested nvidia 195 with kernel 2.6.35? (note I haven't had the time to test and rebuild the driver yet)
[13:37] <Sarvatt> no, i've only tested 256.29 but people are saying 195.24 works with a no change rebuild against the new server. i've noticed a bug where nvidia-current was getting installed on non nvidia with a dist-upgrade once it's providing xserver-xorg-video-7 though, i think the only reason it's not happening to people now is because xserver-xorg-core breaks nvidia-current
[13:37] <Sarvatt> i dropped the provides in x-updates
[13:38] <tseliot> Sarvatt: I fail to see why that would happen
[13:38] <Sarvatt> it's easy to test, boot an alpha 1 livecd and sudo apt-get update && sudo apt-get dist-upgrade on non nvidia once it's rebuilt in the archives and it'll offer nvidia-current
[13:39] <Sarvatt> i cant figure it out either
[13:39] <Sarvatt> been trying to for weeks
[13:39] <Sarvatt> it happened when i moved xorg-edgers to 1.8 too
[13:40] <tseliot> I'll have to check the xserver package then
[13:40] <Sarvatt> when it's rebuilt i'll boot the livecd and do a simulated install and try to figure it out some more
[13:41] <Sarvatt> also nvidia_supported no longer works with nvidia-256, i had to hardcode the modaliases from the last working one :(
[13:41] <tseliot> Sarvatt: another thing: do you know if we have this patch in Maverick? http://bugs.freedesktop.org/attachment.cgi?id=35383
[13:42] <tseliot> I'll rework nvidia_supported too, as soon as I have some time to look at the nvidia package
[13:43] <Sarvatt> yes we do
[13:44] <Sarvatt> there's an ordering issue somewhere screwing up nvidia-current but i am completely stumped about it
[13:45] <tseliot> ordering issue?
[13:46] <Sarvatt> yeah the order its trying to resolve packages with dist-upgrade is wacky with xserver-xorg-core having breaks on the old abi's
[13:46] <tseliot> aah, ok
[13:47] <Sarvatt> if you have a machine that hasn't updated to xserver 1.8 yet, you can add the x-updates ppa and try a dist-upgrade and see what it offers to see what i'm talking about
[13:48] <Sarvatt> i just went through it all again yesterday but i guess ya weren't in the channel
 The following NEW packages will be installed:
   baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-session-common gnome-system-log libprotobuf6 libprotoc6 libx11-xcb1
   libxcb-dri2-0 linux-headers-2.6.35-2 linux-headers-2.6.35-2-generic linux-image-2.6.35-2-generic nvidia-current nvidia-settings
[13:49] <Sarvatt> thats on a fresh install of alpha 1 with fglrx installed doing a dist-upgrade
[13:49] <tseliot> that definitely doesn't look good
[13:49] <Sarvatt> with x-updates enabled
[13:50] <Sarvatt> with edgers I pinned it down to xserver-xorg-video-nv being screwed up and if i purged that it stopped trying to offer nvidia-current
[13:51] <tseliot> how did xserver-xorg-video-nv cause the system to install nvidia-current?
[13:51] <tseliot> shouldn't it be replaced by nouveau instead?
[13:52] <tseliot> note: I haven't installed maverick or created any maverick chroot yet
[13:59] <Sarvatt> hmm
[14:00] <Sarvatt> i wonder if its because xserver-xorg-video-nv provides xf86-video-driver-riva128 and it thinks that has video abi 6 early in the dependency resolution
[14:01] <Sarvatt> thats the only thing i can think of, kees had a similar problem earlier where he couldn't upgrade xserver-xorg-core because it thought something was providing xserver-xorg-video-6 still until he purged -nv
[14:02] <Sarvatt> if you dist upgrade while something provides video-6 the first thing it does is try to remove video-all
[14:03] <Sarvatt> so xserver-xorg-video-all | xserver-xorg-video-7 can get fulfilled for xserver-xorg
[14:04] <Sarvatt> i bet thats it actually, i'll test it out today
[14:04] <tseliot> good, let me know how it goes
[18:04] <ripps> I'm having trouble using my webcam with any gstreamer based client
[18:04] <ripps> I have a backtrace, would the fact I'm using xorg-edgers interfere?
[18:18] <johanbr> ripps, there are apparently xv issues with recent gtk
[18:19] <johanbr> you can try launching cheese with "XLIB_SKIP_ARGB_VISUALS=1 cheese"
[18:22] <ripps> johanbr: ah that works. I've got a ton of wrappers for that in my bin/. There needs to be a better way to handle the argb incompatibilities
[18:22] <johanbr> I'm sure people are working on it
[18:25] <ripps> I guess I'll create some wrappers for cheese and empathy
[18:53] <ripps> woot! looks like wacom-dkms successfully worked when upgrading kernel.
[18:54] <ripps> Let's reboot and see if it really worked.
[19:30] <ripps> lol, it looks like rbga is being disabled again for gtk
[20:28] <Sarvatt> kinda funny, I was actually enjoying RGBA themes now :) don't understand why they weren't enabled by default though, the only thing we got from all that seemed to be crashes?
[20:37]  * Ng wonders if there is any visibility of issues relating to USB input devices locking up
[20:38] <Ng> I've not seen it myself, but someone mentioned it to me in context of http://ubuntuforums.org/showthread.php?t=1497247
[20:40] <Sarvatt> Ng: you're evil, i actually read that.. :)
[20:41] <Ng> how is that evil?
[20:41] <Ng> I never go to the forums other than when people are talking about issues to me
[20:41] <Sarvatt> it's scary how much bad info is contained in one thread
[20:42] <Sarvatt> "my mouse doesn't work" "reinstall nvidia" "intel 8xx is broken change to vesa fix your mouse"
[20:42] <Sarvatt> noone even gave any details of their hardware :)
[20:44] <Sarvatt> like is it locking up after suspend, or after multiple plug ins or anything?
[20:45] <Sarvatt> its almost guaranteed the problem will be in dmesg when it happens
[20:47] <Sarvatt> Ng: did that flickering screen problem ever get fixed?
[20:48] <seb128> Sarvatt, "the only thing we got from all that seemed to be crashes?"
[20:48] <seb128> Sarvatt, we needed to land the change to know about those
[20:49] <seb128> Sarvatt, we also allow other teams to pick up and land themes etc
[20:49] <Ng> Sarvatt: I don't think so, but I've not been paying lots of attention to it
[20:50] <Sarvatt> oh, I mean the CSD/RGBA stuff was completely transparent to me from a user's perspective, the only thing I noticed with it enabled was the crashes until I found out I could manually enable RGBA in the theme
[20:51] <Sarvatt> i think less people would be complaining if they could actually see it in action :)
[20:51] <Sarvatt> because it shut me up from complaining once i did
[20:52] <seb128> right
[20:52] <seb128> well we need both, we need to know about issues and we need to get it used
[20:52] <seb128> seems to design team doesn't have a theme ready to use yet
[20:52] <seb128> and we collected technical issues we needed to know about now
[20:52] <seb128> so we turn it off until we have time to work on those
[20:53] <seb128> it's likely going to be back on after alpha2
[20:53] <Sarvatt> i've been using ambiance with rgba and it looks great
[20:53]  * Sarvatt nods
[20:53] <Ng> Sarvatt: I'll see if I can get the affected person to check dmesg when it happens and file a bug
[20:54] <seb128> in practice bratsche does our gtk work and is busy on the appmenu work now
[20:54] <Sarvatt> poke me if you can, I'll help :)
[20:54] <seb128> that should land in alpha2 for UNE
[20:54] <seb128> once that's working he will be back on rgba work
[20:54] <seb128> then we will enable it again
[20:54] <seb128> we don't win anything out of crashes right now
[20:59] <Sarvatt> cairo 1.9.8 checks out good on R600 at least - http://sarvatt.com/downloads/cairo/tests/
[20:59] <Sarvatt> couldn't run the pdf tests because they need poppler >= 13.2
[21:35] <Sarvatt> apw: do you know if 586 is going to continue being the default target for the i386 kernel in maverick?
[21:36] <Sarvatt> i imagine our binutils/gcc using i686 are already making userspace incompatible with the few processors that 586 supports that 686 doesn't
[21:40] <apw> Sarvatt, i would have thought so
[21:40] <apw> if it hasn't already of course
[21:42] <ripps> what exactly is the reason for the switch to i686?
[21:43] <apw> ripps, as i understand it its time for a clean break so we can take advantage of the newer features
[21:44] <ripps> apw: what kind of features?
[21:44] <apw> ripps, we are optimising for h/w that is almost non-existant, the majority case is i686 and above... they are paying a penaltiy for a very very few systems
[21:45] <apw> and as those systems are very old already and can stay on lucid for 3 years, now was deemed the time to make a change if we were
[21:45] <apw> but as for the politics, it was not my decision, nor was i present when it was made
[22:01] <Sarvatt> i for one am super happy about the change :)
[22:53] <geser> RAOF: do you know if moving glx.h from /usr/include/GL/glx.h to /usr/include/glx.h in maverick was intended? this seems to break some other software which checks for GL/glx.h
[22:54] <jcristau> sounds like a bug
[22:55] <geser> then the last mesa upload broke it
[22:56] <geser> mesa 7.8.1-1ubuntu has it installed in /usr/include/GL/glx.h, the same 7.8.1-2 from Debian experimental but 7.8.1-3ubuntu1 in maverick installs it now in /usr/include/glx.h
[22:57] <Sarvatt> argh
[22:57] <Sarvatt> http://sarvatt.com/downloads/mesa-modified-third.txt
[22:57] <Sarvatt> indeed it does
[22:58] <Sarvatt> want to yell at me yet jcristau? :)
[22:59] <jcristau> not unless you insist
[22:59] <jcristau> shit happens
[23:00] <Sarvatt> hmm, maybe that wasnt the most recent file list
[23:00] <Sarvatt> dri.pc is screwed up in origin/ubuntu too
[23:00] <geser> looks like the changes to mesa-common-dev.install dropped the GL directory:
[23:00] <geser> -usr/include/GL/gl.h
[23:01] <geser> +dri/usr/include/GL/gl.h usr/include
[23:01] <geser> and so on for the other files
[23:02] <Sarvatt> yeah that should be dri/usr/include/GL/gl.h usr/include/GL :(
[23:03] <Sarvatt> the merge was all screwed up, didnt fix up the new locations
[23:05] <Sarvatt> yay more mesa test builds incoming :)
[23:20] <Sarvatt> ugh, yeah I see why, there was something strange with the build in that other things from debian/tmp/dri needed the extra path in the .install but mesa-common-dev was the exception
[23:20] <Sarvatt> dri/usr/include/EGL usr/include works for libegl1-mesa-dev but mesa-common-dev needs dri/usr/include/GL/gl.h usr/include/GL
[23:21] <Sarvatt> adding dri/usr/include/EGL usr/include/EGL to libegl1-mesa-dev made it install to usr/include/EGL/EGL
[23:22] <Sarvatt> test building to be sure and will fix up the ubuntu branch's bad merge after if noone else gets them :D
[23:26] <shadeslayer> Sarvatt: bug 594863 regarding the above issue
[23:26] <ubot4> Launchpad bug 594863 in mesa (Ubuntu) "glx.h moved, causes FTBFS in other packages (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/594863
[23:27] <Sarvatt> it'll be fixed soon if you didn't read the scrollback :)
[23:28] <Sarvatt> there's a lot more messed up in the ubuntu package than just glx.h
[23:30] <RAOF> Gah!
[23:31] <bryceh> good morning raof
[23:31] <RAOF> bryceh: Good morning
[23:32]  * RAOF adds “test that things can build against it” to the set of pre-mesa upload checks.
[23:33] <Sarvatt> did you even merge anything?
[23:33] <Sarvatt> it doesnt look like you did, weird
[23:34] <jcristau> i try to debdiff against the previous changes file usually.  but sometimes i don't have that, and sometimes i miss stuff
[23:35] <RAOF> I use git for that; I diff against debian-experimental and origin/ubuntu.
[23:41] <Sarvatt> how did you merge?
[23:42] <RAOF> With git.
[23:42] <RAOF> You wouldn't have seen it, because I didn't push until just then.
[23:43] <RAOF> I'll be back in ~15 minutes.  Need to shift to to my brother's house which _isn't_ being rewired today.
[23:43] <Sarvatt> i mean what commands did you use? whatever you did didn't actually go through?
[23:43] <Sarvatt> oh ok
[23:47] <Sarvatt> http://sarvatt.com/downloads/files-five.txt
[23:49] <Sarvatt> looks right to me


[00:19] <niemeyer> davecheney: :-)
[00:19] <niemeyer> davecheney: Are you using cobzr?
[00:19] <niemeyer> davecheney: It may help
[00:20] <niemeyer> davecheney: It's really boring to use GOPATH without it
[00:33] <niemeyer> Alright, calling a day I am
[00:33] <niemeyer> Have a good night/day all
[00:34] <davecheney> niemeyer: yes, alias bzr=cobzr
[00:35] <davecheney> will cobzr close (ie, remove from my local branch list) branches that have been submitted ?
[06:38] <TheMue> morning
[06:38]  * davecheney waves
[06:38]  * TheMue waves back
[06:38] <davecheney> i heard tell there is a pastebin for canonical
[06:38] <davecheney> the public one
[06:38] <TheMue> davArrived in the right timezone? ;)
[06:39] <davecheney> yesterday was not pretty
[06:39] <TheMue> davecheney: Yes
[06:39] <davecheney> walked around like a zombie til 5pm
[06:39] <davecheney> then gave in to the inevitable
[06:39] <TheMue> http://paste.ubuntu.com/
[06:40] <davecheney> TheMue: http://paste.ubuntu.com/988455/
[06:40] <TheMue> davecheney: Funnily this time I had almost no problems. But I slept a lot during flight.
[06:40] <davecheney> what do you think of that?
[06:40] <davecheney> the logic is, watch /environment
[06:41] <davecheney> get the *ConfigNode, pass config.Map() to this function, receive Environ
[06:42] <TheMue> davecheney: Loks straight.
[06:43] <TheMue> Looks
[07:18]  * davecheney shakes his fist at the interface{}'s being passed around everywhere
[07:19] <davecheney> well, mainly inside environs/config.go
[07:22] <TheMue> davecheney: Hehe, indeed, anonymous interfaces are always some kind of double-edged.
[07:23] <davecheney> dummy.Open expect a schema.MapType, but ec2,Open expects a *providerConfig
[07:24] <davecheney> I can't see a way to reconcile the two
[07:24] <davecheney> apart from changing environProvider.ConfigCheck() to coerce everything to a map[string]interface{}
[07:26] <davecheney> ohh, it's actually worse than that
[07:31] <TheMue> davecheney: I hope Roger is around soon. This is his playground.
[07:37] <davecheney> OK: 6 passed
[07:37] <davecheney> i got it to pass, but it is really ugly
[07:47] <TheMue> davecheney: Now that it's working it's time to make it elegant. ;)
[07:50] <davecheney> in the face of interface{}, little can be done
[07:52] <davecheney> but I think I pushed some of the nastyness out of sight
[07:54] <davecheney> TheMue: https://codereview.appspot.com/6215045
[07:55] <davecheney> just checking it over before i send it out
[08:07] <davecheney> halo rog
[08:07] <davecheney> i'm just finishing up
[08:07] <davecheney> check out https://codereview.appspot.com/6215045
[08:07] <rog> davecheney: hi there
[08:07] <rog> davecheney: am very bleary!
[08:07] <davecheney> took far too long (read most the day)
[08:07] <davecheney> to produce that
[08:07]  * rog looks
[08:07] <davecheney> but hopefully it's a faithful representation of what we discussed last week
[08:08] <rog> davecheney: cool.
[08:08] <rog> davecheney: what time of day is it for you?
[08:08] <davecheney> 18:06
[08:08] <davecheney> so i'd better go and make the dinner
[08:08] <davecheney> and tackle the mountain of washing up that sam left for me
[08:09] <TheMue> rog: Heya
[08:09] <rog> davecheney: ok :-)
[08:09] <rog> TheMue: mornin'
[08:09] <TheMue> davecheney: You got my comment. Mostly looks good.
[08:10] <rog> davecheney: i thought we were going to use Setter/Getter or something like that
[08:12] <davecheney> Open can't take a getter, the value of attributes is provider specific
[08:12] <davecheney> it spent most the day bashing my head on that
[08:12] <davecheney> ok, going afk for a few hours at least
[08:12] <rog> davecheney: ok, have fun.
[08:12] <rog> davecheney: washing up, yeah!
[08:13] <rog> davecheney: BTW i was suggesting to pass a Getter to Check, not Open.
[08:17] <TheMue> rog: Too late. (lol)
[08:17] <TheMue> rog: Seen on the log that you yesterday asked for running Ubuntu in a VM.
[08:17] <rog> TheMue: yeah
[08:18] <rog> TheMue: was just wondering if my crash scenario was specific to me only...
[08:18] <TheMue> rog: Oh, tell me more.
[08:19] <rog> TheMue: ok, if you don't mind your VM crashing, try this: echo /dev/*/tun*
[08:20] <TheMue> rog: Maybe later on a copy. ;) So you play around with the tunneling?
[08:20] <rog> TheMue: yeah, but i couldn't get it working, and i don't know why.
[08:20] <rog> TheMue: that was on the plane.
[08:21] <TheMue> rog: That can't work.
[08:21] <rog> TheMue: what can't work?
[08:21] <TheMue> rog: Tunnels are below earth, not 10.000 feet above. (scnr)
[08:21] <rog> :-)
[08:22] <TheMue> rog: But what did you expect by echoing directly on the devices?
[08:22] <rog> TheMue: i expected it to tell me what files were in /dev
[08:23] <rog> TheMue: i ended up posting a stackoverflow question: http://stackoverflow.com/questions/10583601/how-should-the-tunattachfilter-ioctl-be-called
[08:23] <TheMue> rog: Never used echo for it, only ls.
[08:24] <rog> TheMue: you'd get the same behaviour if you passed the same argument to ls
[08:24] <rog> TheMue: echo is nice because it prints all the names on one line
[09:07] <TheMue> rog: attributes in config are always a map[string]interface{}? I already wondered about the usage of interface{} here.
[09:08] <rog> TheMue: they only happen to be a map[string]interface{} if the yaml is written correctly.
[09:08] <TheMue> rog: So I would define a type Attributes map[string]interface{} with setter/getter and Check(*EnvironChecker) (or something like that).
[09:08] <rog> actually....
[09:08] <rog> i think they're usually map[interface{}
[09:09] <rog> ] interface{}
[09:09] <rog> TheMue: don't you like my Getter/Setter idea?
[09:09] <TheMue> rog: Could live with that too, even if it's very generic.
[09:09] <TheMue> rog: Get and Set on Checker?
[09:10] <rog> TheMue: the idea is that you should be able to pass a *ConfigNode to EnvironProvider.Check
[09:10] <rog> TheMue: you saw my comment, right?
[09:10] <TheMue> rog: Only a quick look so far.
[09:10] <rog> TheMue: https://codereview.appspot.com/6215045/diff/13/environs/open.go#newcode36
[09:13] <TheMue> rog: So your idea is to pass anything where you can "get" a value by key from as an input to the checker? Am I right?
[09:13] <rog> TheMue: yes
[09:13] <TheMue> rog: Sounds good.
[09:14] <rog> TheMue: and it also works the other way around
[09:14] <TheMue> rog: Yes
[09:14] <rog> TheMue: an environ config can be saved directly to a config node
[09:14] <TheMue> rog: So if it later will be something else and not the config node it's no problem.
[09:14] <rog> TheMue: yes
[09:14] <TheMue> +1
[09:15] <rog> cool
[09:17] <TheMue> rog: Got this one http://shop.canonical.com/product_info.php?products_id=708 at UDS. Now here in the cold and wet Germany it's really useful.
[09:18] <rog> TheMue: doesn't look like it'll keep out the rain much :-)
[09:19] <TheMue> rog: No, but it keeps warm. Thankfully there's no rain inside my house. ;) And it's dry enough for the way to the car.
[09:19] <rog> :-)
[09:58] <fwereade> TheMue, rog: I *did* sleep well last night but I'm feeling the aggregate effect of too many weird days... taking a swap day today
[09:58] <rog> fwereade: ok, good plan
[09:58] <rog> fwereade: enjoy the day!
[09:58] <TheMue> fwereade: OK, enjoy it.
[09:58] <fwereade> rog, cheers :)
[09:58] <fwereade> TheMue, cheers also :)
[09:58] <TheMue> ;)
[13:51] <niemeyer> Heya!
[13:59] <TheMue> niemeyer: Heya.
[14:15] <niemeyer> TheMue: How're things?
[14:16] <TheMue> niemeyer: Fine, just working on relations. And you?
[14:17] <rogpeppe> niemeyer: yo!
[14:18] <niemeyer> TheMue: I'm waking up after a rough night where the jetlag ruled out, and getting on some reviewing
[14:18] <niemeyer> rogpeppe: Heya!
[14:19] <TheMue> niemeyer: Yeah, adjusting the inner clock back is hard. And you've been there almost two weeks.
[14:20] <Aram> I have a 26 hour biological clock, it's terrible.
[14:20] <rogpeppe> niemeyer: https://codereview.appspot.com/6145043/ is feeling a bit neglected :-)
[14:21] <niemeyer> rogpeppe: The whole queue is feeling neglected
[14:21] <rogpeppe> niemeyer: i think that might be one of the older items...
[14:22] <niemeyer> rogpeppe: I'm sure some of them are older than the others :)
[14:22] <niemeyer> rogpeppe: My day will be pretty much just reviews today
[14:23] <niemeyer> Except for lunch and a meeting I have in about 1h
[14:24] <niemeyer> rogpeppe: Will do a quick pass on this one now.. hopefully we can get it in now
[14:24] <rogpeppe> niemeyer: thanks!
[14:26] <niemeyer> rogpeppe: version.ToolsPath makes no sense to me
[14:26] <rogpeppe> niemeyer: where do you think it should go?
[14:26] <rogpeppe> niemeyer: i was duplicating it all over the place
[14:27] <niemeyer> rogpeppe: If anywhere, this should live within environs.ToolsPath
[14:27] <rogpeppe> niemeyer: that could make sense. let me check.
[14:27] <niemeyer> rogpeppe: Although, maybe it should be a function instead, and let the implementation details off
[14:28] <niemeyer> rogpeppe: environs.GetTools(env)
[14:30] <niemeyer> Aram: Ouch :)
[14:30] <rogpeppe> niemeyer: i'm not sure that's right
[14:30] <rogpeppe> niemeyer: the tools path is independent of the provider
[14:30] <rogpeppe> niemeyer: i think
[14:31] <rogpeppe> niemeyer: otherwise we've documented the interface to PutFile wrong.
[14:31] <niemeyer> rogpeppe: Not sure I see what you mean.. environs is not environment-specific either
[14:31] <rogpeppe> niemeyer: ah, so you'd have environs.PutTools too?
[14:32] <Aram> niemeyer: yeah, basically only once every 13 days I wake up when I should. All the other days I feel jet lagged. I compensate with caffeine, heh.
[14:32] <Aram> maybe that makes it worse.
[14:32] <niemeyer> rogpeppe: Don't we have that already?
[14:33] <rogpeppe> niemeyer: UploadTools, yeah.
[14:33] <rogpeppe> niemeyer: but without ToolsPath, it's difficult to test that the correct file has been written, because we don't know its name.
[14:33] <niemeyer> Aram: I bet it does indeed :)
[14:34] <niemeyer> rogpeppe: We only have to know its name once, in a single test
[14:34] <niemeyer> rogpeppe: If UploadTools works as it should, everything is else may rely on that
[14:35] <niemeyer> rogpeppe: We can test that DownloadTools (?) gets the same content that UploadTools supposedly uploaded, for example
[14:35] <niemeyer> rogpeppe: We don't have to test the path for that
[14:35] <rogpeppe> niemeyer: i'm still not happy about cmd_test.go knowing about the underlying path name.
[14:36] <niemeyer> rogpeppe: I just pointed out that it doesn't have to..?
[14:36] <niemeyer> rogpeppe: I'm happy with PutTools and GetTools as well, btw
[14:36] <niemeyer> rogpeppe: Probably more sensible for GetFile/PutFile
[14:37] <rogpeppe> niemeyer: yeah, i tend to agree
[14:37] <rogpeppe> niemeyer: even though the flag is called --upload-tools
[14:37] <rogpeppe> maybe it might be better named --put-tools in fact
[14:37] <niemeyer> rogpeppe: Yeah, that's fine.. the language on the command line has to be more sensible for the user instead
[14:37] <niemeyer> rogpeppe: --upload-tools feels more clear in that sense
[14:37] <rogpeppe> niemeyer: ok
[14:38] <rogpeppe> niemeyer: ok, i'll see how it goes without ToolsPath
[14:38] <niemeyer> rogpeppe: Thanks.. I'll be here for about 20 mins more before lunch
[14:41] <rogpeppe> niemeyer: one thought: nothing is ever going to use GetTools except tests.
[14:42] <rogpeppe> niemeyer: hmm, update will, i suppose.
[14:42] <niemeyer> rogpeppe: Curious.. I wonder what's the purpose of uploading a file we never download :-)
[14:42] <rogpeppe> niemeyer: we use wget and tar...
[14:42] <niemeyer> rogpeppe: That's done for bootstrap only
[14:42] <rogpeppe> niemeyer: when else do we download tools?
[14:43] <rogpeppe> niemeyer: update will, i think, so i think it seems ok to me.
[14:43] <niemeyer> rogpeppe: Yep
[14:43] <niemeyer> rogpeppe: Whenever we have Go code running that wants to download tools
[14:44] <niemeyer> rogpeppe: Updating has to do that
[14:44] <rogpeppe> niemeyer: yeah
[14:44] <rogpeppe> niemeyer: i'll still need to verify against tar xz though
[14:44] <niemeyer> rogpeppe: Yeah, once, though
[14:48] <rogpeppe> oh darn
[14:48] <rogpeppe> niemeyer: GetTools won't work without support for ListFiles in Environ
[14:48] <rogpeppe> niemeyer: and even that's not quite there, as we've got a two-tier system.
[14:50] <niemeyer> rogpeppe: I don't understand how we can have ToolsPath in version and can't have a function instead
[14:50] <rogpeppe> niemeyer: because GetTools doesn't get a particular version - it searches for the latest appropriate version.
[14:50] <niemeyer> rogpeppe: So ToolsPath is equally bogus
[14:50] <rogpeppe> niemeyer: ToolsPath gives the path for the *current* tools. that's why i put it in version.
[14:51] <niemeyer> rogpeppe: Ugh.. that's not great
[14:51] <niemeyer> rogpeppe: Let's have ListFiles in the environment then, and have GetTools
[14:52] <rogpeppe> niemeyer: we'll need two ListFiles-type functions (or one with a bool arg) because we need to be able to look in private storage first before failing over to public storage.
[14:53] <rogpeppe> niemeyer: perhaps ListFiles(private bool) ([]string, error)
[14:53] <niemeyer> rogpeppe: That sounds like yet another great reason to have GetTools.. this is unrelated to ListFiles in the environment
[14:53] <rogpeppe> niemeyer: really?
[14:53] <rogpeppe> niemeyer: which bucket would ListFiles list?
[14:53] <niemeyer> rogpeppe: Well, maybe it could be.. thinking
[14:54] <niemeyer> rogpeppe: ListFiles should list the files in the environment
[14:54] <niemeyer> rogpeppe: That has a very well defined meaning
[14:54] <rogpeppe> niemeyer: so how do we list the files in the public bucket so we can use publicly uploaded tools?
[14:54] <niemeyer> rogpeppe: Which is in theory unrelated to anything about how-do-I-get-public-tools
[14:55] <niemeyer> rogpeppe: That's a good question for which we need a good answer.. it doesn't invalidate the former point, though
[14:55] <rogpeppe> niemeyer:  the environment knows about both, so i'd put that logic into the environment. if it's not in the environment, then we need some way of extracting info about the public bucket from it
[14:56] <rogpeppe> s/i'd/i/
[14:56] <niemeyer> rogpeppe: Please explain "the environment knows about both"
[14:56] <rogpeppe> niemeyer: the names for both the private and public buckets are stored in environments.yaml
[14:57] <rogpeppe> niemeyer: and they're environment-specific
[14:57] <niemeyer> rogpeppe: You're putting statements as if they were true as you go, but it feels to me like the implementation of these details is actually still undefined
[14:58] <rogpeppe> niemeyer: ok. i'm happy to refactor.
[14:58] <niemeyer> rogpeppe: It is not true that the public files are environment-specific, for instance
[14:58] <rogpeppe> niemeyer: i'm not sure how we'd specify mutable storage in a provider-independent way though.
[14:59] <niemeyer> rogpeppe: All the environments for a given provider, or even for multiple providers, may share files
[14:59] <rogpeppe> niemeyer: oh, is the list-bucket functionality provider-independent?
[14:59] <niemeyer> rogpeppe: It is also not necessarily true that they are stored in environments.yaml either
[14:59] <niemeyer> rogpeppe: Since we'll have defaults
[15:00] <niemeyer> rogpeppe: It may be.. and it doesn't even have to be a bucket, for example
[15:00] <rogpeppe> niemeyer: what we need is some generic "container-like" functionality, i think
[15:01] <rogpeppe> niemeyer: if we want to go in this direction
[15:01] <niemeyer> rogpeppe: I think we can actually have an interface that defines a public-files thingy (name to be defined), and have a HTTP(S) consumer implementation for that
[15:02] <niemeyer> rogpeppe: I *suspect* we can use that single implementation with every provider we know about so far
[15:02]  * rogpeppe doesn't know about anything other than s3
[15:02] <niemeyer> rogpeppe: Then, we can have a env.PublicFilesThingy() or similar
[15:03] <niemeyer> rogpeppe: Which in pretty much all cases does
[15:03] <rogpeppe> niemeyer: and PrivateFilesThing() ?
[15:03] <niemeyer> rogpeppe: I suspect the env itself is a PrivateFilesThing
[15:03] <rogpeppe> ew
[15:04] <rogpeppe> niemeyer: that seems a little icky
[15:05] <rogpeppe> niemeyer: i'm not sure why PublicFiles and PrivateFiles wouldn't be symmetrical
[15:05] <niemeyer> rogpeppe: env.PublicFilesThingy() will return TheBasicHTTPPublicFilesThingy(defaultURL or configURL) for pretty much all providers
[15:05] <niemeyer> rogpeppe: Because they are not in real life.. the environment manages storage of its own files.. the public files is managed by someone else
[15:05] <niemeyer> rogpeppe: There's nothing icky about that to me
[15:06] <niemeyer> rogpeppe: Although, I'm fine to have PrivateFilesThingy if you prefer that
[15:06] <rogpeppe> niemeyer: i'll think about it.
[15:06] <niemeyer> rogpeppe: It sounds sane to me as well
[15:06] <rogpeppe> Environ.Files vs Environ.PublicFiles ?
[15:07] <rogpeppe> niemeyer: then the file interface can be simply be: interface {Put(...) error; Get(...) error; List( ...) ([]string, error)}
[15:07] <rogpeppe> niemeyer: because we won't need to disambiguate
[15:08] <niemeyer> rogpeppe: I'm happy with that.. feels very clean
[15:08] <rogpeppe> niemeyer: i'll see how it looks
[15:08] <niemeyer> rogpeppe: Happy with PrivateFilesThing too
[15:08] <niemeyer> rogpeppe: Btw, we need a name :)
[15:08] <niemeyer> rogpeppe: I'll have lunch, and try to come up with some suggestions
[15:08] <rogpeppe> niemeyer: Storage?
[15:08] <rogpeppe> niemeyer: ok, enjoy
[15:08] <rogpeppe> !
[15:09] <niemeyer> rogpeppe: Sounds great
[15:09]  * niemeyer => lunch
[16:13]  * niemeyer_ is back
[16:13] <niemeyer_> rogpeppe: How does it feel?
[16:14] <rogpeppe> niemeyer_: it's looking quite nice
[16:14] <rogpeppe> niemeyer_: http://paste.ubuntu.com/989159/
[16:14] <rogpeppe> niemeyer_: it feels like another piece of the puzzle has dropped into place
[16:16] <rogpeppe> niemeyer_: what do you think?
[16:18]  * niemeyer_ reads
[16:19] <niemeyer_> rogpeppe: Looks very good indeed
[16:19] <niemeyer_> rogpeppe: A couple of suggestions:
[16:19] <rogpeppe> niemeyer_: cool.
[16:19] <niemeyer_> rogpeppe: Let's not get into the S3 prefix madness
[16:19] <niemeyer_> rogpeppe: Let's call it a dir
[16:20] <rogpeppe> niemeyer_: ok. i started with that.
[16:20] <rogpeppe> niemeyer_: but it's hard to do proper dirs with s3
[16:20] <niemeyer_> rogpeppe: I thougth it was trivial?
[16:20] <rogpeppe> niemeyer_: List(prefix="e", separator="/") will return "elephant" AFAIR
[16:21] <rogpeppe> (if "elephant" exists, of course)
[16:21] <niemeyer_> rogpeppe: What will "e/" return?
[16:21] <rogpeppe> niemeyer_: good point - just always append a /
[16:22] <niemeyer_> rogpeppe: The only reason to not do that would be efficiency I guess
[16:22] <niemeyer_> rogpeppe: In the sense we could list precisely what we want, if possible
[16:22] <niemeyer_> rogpeppe: This might be enough of a reason to implement the prefix-based stuff
[16:22] <rogpeppe> niemeyer_: if we know precisely what we want, then why are we doing a LIST?
[16:22] <niemeyer_> rogpeppe: "foo-*
[16:23] <rogpeppe> niemeyer_: i don't think we should worry.
[16:23] <rogpeppe> niemeyer_: we're not going to have *that* many versions.
[16:23] <rogpeppe> niemeyer_: and if we do, we can partition the dirs
[16:23] <niemeyer_> rogpeppe: It may be useful to avoid returning 100s of tools from the public storage, actually
[16:23] <niemeyer_> rogpeppe: tools-<major>.*
[16:24] <rogpeppe> niemeyer_: in which case, why not make tools-<major> a directory?
[16:24] <rogpeppe> niemeyer_: as you said, the S3 prefix stuff is madness
[16:25] <niemeyer_> rogpeppe: Well, we can make it saner.. we'd not support varied separators, or distinguish common prefixes in separate lists
[16:25] <rogpeppe> niemeyer_: not quite whether to go for "/" or "" as the root directory.
[16:25] <rogpeppe> niemeyer_: i don't see the need for the abstraction - you've persuaded me. prefix might not be as easy to implement in other providers
[16:25] <rogpeppe> niemeyer_: directories are sufficient
[16:25] <niemeyer_> rogpeppe: I can't see how that would possibly be the case
[16:26] <rogpeppe> niemeyer_: if the provider actually uses a directory-like structure, prefix matching will be harder to do efficiently.
[16:26] <rogpeppe> niemeyer_: (we'd need to do it client-side)
[16:27] <niemeyer_> rogpeppe: Anywhere we can list a directory, we can filter it out with three lines (for+if+append)
[16:27] <rogpeppe> niemeyer_: exactly. but then we'll be getting the inefficiency we're trying to remove by using the prefix abstraction.
[16:27] <rogpeppe> niemeyer_: and using a directory will be the same efficiency in both cases.
[16:27] <niemeyer_> rogpeppe: We'll be getting the inefficiency you're suggesting we'd have all the time
[16:28] <niemeyer_> rogpeppe: Yes, the same *inefficiency* in both cases..
[16:28] <rogpeppe> niemeyer_: not if we store tools as tools-$MAJOR/$MINOR-$PATCH.tgz
[16:28] <niemeyer_> rogpeppe: Which means filtering it out by hand, client side, in both cases..
[16:28] <niemeyer_> rogpeppe: Not sure about what you're arguing for, to be honest
[16:28] <rogpeppe> the above
[16:29] <rogpeppe> niemeyer_: note the "/" between major and minor versions
[16:29] <rogpeppe> niemeyer_: then we can just List("tools-$MAJOR")
[16:29] <niemeyer_> rogpeppe: Ok, but this naming isn't great
[16:30] <rogpeppe> niemeyer_: no?
[16:30] <niemeyer_> rogpeppe: "tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz" then
[16:30] <rogpeppe> niemeyer_: why does it need to have the same pattern on the provider as on disk?
[16:30] <niemeyer_> rogpeppe: Because I don't want to wget 1.2.tar.gz
[16:31] <rogpeppe> wget tools/2/1.2.tgz seems ok to me.
[16:31] <niemeyer_> rogpeppe: Sorry, 1.2.tar.gz isn't a proper file name
[16:32] <rogpeppe> niemeyer_: but anyway, all this is premature optimisation - we can change it all later trivially.
[16:32] <rogpeppe> niemeyer_: i think we've shown that we don't need prefix matching to do this efficiently
[16:32] <rogpeppe> niemeyer_: and i'm ok with the redundant major version too
[16:33] <rogpeppe> niemeyer_: by the time we've got hundreds of versions, we'll have upgrade and we can change the schema on the fly :-)
[16:33] <niemeyer_> rogpeppe: No, let's do it now please.. the need is obvious, the implementation trivial
[16:34] <niemeyer_> rogpeppe: You can pick either.. tools/tools-$MAJOR.$MINOR.PATCH.tar.gz + prefix <OR> tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz + dir
[16:34] <rogpeppe> niemeyer_: ok.
[16:34] <rogpeppe> niemeyer_: i vote for the latter.
[16:35] <niemeyer_> rogpeppe: Cool, let's go with it then
[16:37] <rogpeppe> niemeyer_: any other suggestions?
[17:01] <rogpeppe> right, off for the day. see y'all tomorrow.
[17:05] <niemeyer> What the heck
[17:06] <niemeyer> Google+ Hangout has f* up my connection permanently..
[17:06] <niemeyer> I had to reboot and reconnect the router..
[17:07] <niemeyer> I wonder if the Hangout servers are DoSing me somehow
[17:10] <Daviey> I wonder if he had the 'DoS me' option enabled in Advance pref's?
[17:20] <ahasenack> hi guys, niemeyer tells me his internet is down for good
[17:21] <ahasenack> hazmat, jimbaker, others: ^^^
[17:22] <hazmat> ahasenack, thanks for relaying
[17:22] <ahasenack> hazmat: 3g is also down, not just adsl, so it must be something more serious in that region
[17:23] <hazmat> indeed, that's uncommon
[17:23] <jimbaker> interesting
[17:24] <niemeyer> Okay
[17:24] <niemeyer> Something funky is happening with the local ISPs
[17:24] <niemeyer> Managed to get in via 3G now
[17:25] <ahasenack> maybe everybody is playing diablo 3 ;)
[17:25] <niemeyer> ahasenack: That might explain it
[17:27] <TheMue> niemeyer: Who may be interested in a possible bug in relation.py in the current implementation?
[17:27] <niemeyer> TheMue: Ben, Jim, or Kapil
[17:27] <niemeyer> TheMue: Everybody would be *interested* though, but one of them will have to look at the code
[17:28] <TheMue> niemeyer: I'm not sure if it's a bug, but I think it's worth a look.
[17:28] <TheMue> jimbaker: Still around?
[17:31] <hazmat> TheMue, what's up?
[17:32] <TheMue> hazmat: Ah, heya.
[17:32] <TheMue> hazmat: Please take a look at relation.py at line 91.
[17:34] <hazmat> TheMue, yeah.. thats suspect its only checking one endpoint
[17:34] <TheMue> hazmat: I think service_id has to be service_relation.internal_service_id().
[17:34] <TheMue> hazmat: Yep, that's what I thought. Especially inside the loop.
[17:35] <hazmat> TheMue, it should be service_relation.service_id
[17:35] <hazmat> er. internal_service_id
[17:35] <TheMue> hazmat: The service id is stored in _service_id. So you have to use the accessor.
[17:35] <TheMue> hazmat: Yeah
[17:36] <jimbaker> TheMue, still around, but looks like hazmat has got you covered
[17:36] <TheMue> jimbaker: Heya. Yes, hes has. ;) Thx.
[17:37] <hazmat> bzr blame suggests otherwise ;-)
[17:38] <hazmat> jimbaker, trivial http://paste.ubuntu.com/989322/
[17:40] <jimbaker> hazmat, looks like a check to ensure we are not seeing inconsistent topology. iirc this was a bug fix to fix looping tests
[17:40] <hazmat> jimbaker, it looks it was part of the initial impl
[17:41] <hazmat> jimbaker, updated trivial w/ test http://paste.ubuntu.com/989333/
[17:44] <hazmat> jimbaker, okay.. given lack of objections.. adding to trunk.. the failure without the change is InternalTopo..Error instead of StateChanged
[17:44] <jimbaker> hazmat, ok, got context - it just looked like all the other checks we have added to avoid InternalTopologyError, so along the same lines
[17:44] <jimbaker> hazmat, +1
[17:46] <hazmat> thanks TheMue
[17:47] <niemeyer> rogpeppe: ping
[17:48] <TheMue> hazmat: np, happy to help
[18:08] <niemeyer> mthaddon: ping
[19:03] <TheMue> So, I'm off. Good night.
[19:06]  * hazmat meanders off for food
[20:39] <flaviamissi> do you guys have any intention of implementing an api for juju?
[20:58] <hazmat> flaviamissi, definitely
[21:12] <hazmat> flaviamissi, there's a very rough draft extant in http://bazaar.launchpad.net/~hazmat/juju/rest-api-spec/files/head:/source/drafts/
[21:33] <flaviamissi> hazmat: great! it would be very useful, I'll take a look at it, maybe I can help on that
[21:34] <hazmat> flaviamissi, great, comments welcome, its basically in three parts, a REST api, an HTTP command api corresponding to the CLI, and websocket notification mechanism.
[21:37] <flaviamissi> hazmat: yeah, I'm reading the spec now, is anyone working on that?
[21:39] <hazmat> flaviamissi, there's an experimental branch that someone through together, but its probably not going in as is. there's some drive to have this done for 12.10 to support other activities though.
[21:40] <hazmat> flaviamissi, the experiment is attached to https://bugs.launchpad.net/juju/+bug/804284
[21:41] <flaviamissi> hazmat: great, thank you
[21:41] <hazmat> flaviamissi, that's a client side rest api though..
[21:42] <hazmat> ie. its not deployed as part of juju
[21:43] <flaviamissi> hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju?
[21:43] <hazmat> flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet
[21:43] <flaviamissi> hazmat: ok
[21:44] <flaviamissi> hazmat: that's for the python version, right?
[21:44] <hazmat> flaviamissi, it is
[21:45] <hazmat> flaviamissi, at this point feedback on the spec would be the most helpful, ie. making sure we're covering appropriate use cases and functionality
[21:45] <flaviamissi> hazmat: I can do that
[21:45] <hazmat> negronjl, where would you want to take jrapi?
[21:48] <davecheney> 'sup 'sup
[21:52] <negronjl> hazmat:  what do you mean ?
[21:54] <negronjl> hazmat:  If it serves a purpose, let's use it.  If anyone comes up with something better, we can use that ...
[21:54] <negronjl> hazmat: but, until something better shows up, I am playing with jrapi
[21:56] <hazmat> negronjl, sure, but trying to figure out where it goes from here.. ie do we evolve it add tests, match it to spec and try to merge it, or do we end up with a separate official project that gets merged.
[21:57] <flaviamissi> hazmat: the spec looks really good, looks like all cases are covered, but I'll take another look later
[22:01] <niemeyer> flaviamissi: There was some mixup there..
[22:02] <niemeyer> <flaviamissi> hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju?
[22:02] <niemeyer> <hazmat> flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet
[22:02] <niemeyer> flaviamissi: hazmat intended to say that, yes the goal is to have the API deployed as part of juju
[22:03] <flaviamissi> niemeyer:  hmmm
[22:03] <flaviamissi> niemeyer: that makes more sense to me :)
[22:03] <niemeyer> flaviamissi: It's one of the next major features that will come
[22:03] <niemeyer> flaviamissi: After the port is done
[22:04] <flaviamissi> niemeyer: so, the plan is not have the api for the python version?
[22:05] <niemeyer> flaviamissi: Yes, Python is in maintenance mode, and we're working on getting the port done in time for 12.10
[22:05] <flaviamissi> niemeyer: great
[22:06] <flaviamissi> I'm leaving, we chat more later
[22:07]  * niemeyer => dinner too
[22:11] <hazmat> niemeyer, doh.. yeah.. totally it should be deployed as part of juju
[22:11] <hazmat> that was unclear
[22:11] <hazmat> async response communication  fail
[22:26] <negronjl> hazmat:  Can you make the spec available to me?
[22:26] <negronjl> hazmat:  I'm up for using this API of course but, the final decision on that I believe it to be yours
[22:27] <hazmat> negronjl, its publicly pushed to docs and editable by charmers
[22:27] <hazmat> negronjl, http://bazaar.launchpad.net/~hazmat/juju/rest-api-spec/files/head:/source/drafts/
[22:27] <negronjl> hazmat:  I'm up for modifying/merging jrapi
[22:27] <hazmat> negronjl, testing would be key
[22:28] <negronjl> hazmat:  I agree on testing... I can start adding some testing to the project as well... Let me take a moment to read the spec in full...
[22:28] <hazmat> negronjl, i am as well.. realistically this month i don't have much spare time,  i'd like to get the spec approved and rolling though before then.
[22:29] <negronjl> hazmat:  ok.  Not sure what the next step on this is .... Has the spec been approved by the powers that be ?
[22:30] <hazmat> negronjl, no.. its in decent shape, but needs some polish
[22:30] <hazmat> and some parts need to be flushed out a lot more
[22:30] <hazmat> like auth
[22:31] <negronjl> hazmat: I see.  Well.  I want to take some time to read the specs.  This will give me more information to come up with more intelligent questions.
[22:31] <negronjl> hazmat: I can get back to you with some feedback tomorrow.  Does that work for you ?
[22:31] <hazmat> negronjl, sounds good
[23:29] <SpamapS> jimbaker: can you please reference bug numbers on all commits to trunk!
[23:30] <SpamapS> jimbaker: I need a bug report for every change or we cannot SRU to 12.04.1
[23:31] <SpamapS> jimbaker: trivials included, though r536 actually doesn't look trivial *at all*
[23:52] <hazmat> SpamapS, its like 5 lines
[23:52] <SpamapS> its not about the size
[23:52] <SpamapS> I need to understand why its ok to update the stable release with it.
[23:52] <hazmat> SpamapS, its nothing something thats needed in practice, it still raises an error in either csae
[23:52] <hazmat> just cleans up the error to something intended for the user instead of an internal error
[23:52] <SpamapS> we have to justify every change
[23:53] <SpamapS> so, Low priority change, that was not on the galapagos list
[23:53] <SpamapS> I think I need to fork a 12.04.1 branch and only pull in High bug fixes
[23:53] <hazmat> SpamapS, indeed it came out of of a porting comment
[23:53] <hazmat> from frank while looking at the relation code
[23:53] <SpamapS> I'm going to be pushing 535 into precise-proposed tomorrow
[23:53] <hazmat> SpamapS, i can back it out.. if need be
[23:54] <hazmat> just put it on the unfettered branch
[23:54] <SpamapS> Then we have to verify all 4 bugs fixed then it goes to precise-updates.
[23:54] <SpamapS> I plan to keep trickling in the galapagos bugs as they're comitted
[23:54] <SpamapS> hazmat: if it has a reasonable test case, impact statement, and regression potential is Low, then we can leave it
[23:54] <SpamapS> just document it with a bug
[23:54] <hazmat> all those things are true
[23:55]  * hazmat adds a bugs
[23:55] <SpamapS> yeah I figure as much. Just have no way of knowing that w/o a bug #
[23:55] <SpamapS> We can go nuts w/ commits again after June 6, but for just this month.. lets fix bugs. :)
[23:55] <SpamapS> hazmat: I want to get acls in. Can we do that without breaking the world?
[23:56] <SpamapS> crap its 45 minutes later than I wanted to EOD today.. :-P
[23:56] <hazmat> SpamapS, define breaking the world ;-)
[23:56] <hazmat> hmmm
[23:56] <hazmat> SpamapS, actually we could
[23:57] <hazmat> SpamapS,  its done at the connection level, so we can detect support and activate it without too much trouble.
[23:57] <hazmat> just switch the security policy from acl to the noop
[23:57] <SpamapS> hazmat: I think all we need to do is make the secret arg to the agents optional
[23:57] <hazmat> ah... mixed mode envs
[23:57] <SpamapS> hazmat: existing bootstrapped envs will just work w/o acls
[23:58] <hazmat> newer client with older env isn't too bad
[23:58] <hazmat> newer agent with older env could work
[23:58] <SpamapS> and we'll make a note that if you upgrade the provisioning agent, you have to re-bootstrap or something
[23:58] <hazmat> it would apply generically to all of them
[23:58] <hazmat> er... all agents
[23:59] <SpamapS> I don't want to support mixed mode
[23:59] <SpamapS> I just want to make sure existing bootstrapped envs with juju-origin: distro can continue to add-unit and deploy
[23:59] <hazmat> well then we need the upgrade/consistent version stuff that rog is doing on the go version
[23:59] <hazmat> SpamapS, that is mixed mode
[23:59] <SpamapS> um, ok