[01:55] <nedstark> will the system tray and application menu be built in to unity 8?  they are basic functionality and we have to install them from ppa on unity 7.
[11:12] <dandrader> tsdgeos, got time for a review? https://code.launchpad.net/~dandrader/unity8/splashRotation/+merge/297318
[11:14] <tsdgeos> dandrader: not sure i'm the best to review that to be honest
[11:15] <dandrader> tsdgeos, you have dealt with this "rotates own contents" mode that camera uses before
[11:15] <tsdgeos> i have
[11:17] <tsdgeos> i'll see if i have a look this afternoon i guess
[11:31] <tsdgeos> pstolowski: have you seen this timeouts in unity-api before? https://launchpadlibrarian.net/265153188/buildlog_ubuntu-vivid-arm64.unity-api_7.115+15.04.20160614-0ubuntu1_BUILDING.txt.gz
[11:32] <tsdgeos> that branch passes fine here locally :/
[11:39] <dandrader> dednick, pushed a commit to the mir-0.24-compatibility branch: http://bazaar.launchpad.net/~mir-team/qtmir/mir-0.24-compatibility/revision/508
[12:05] <dandrader> tsdgeos, do you use run.sh?
[12:08] <dednick> dandrader: ta
[12:11] <dednick> wondering why qtmir depends on mirclient :/
[12:18] <tsdgeos> dandrader: haven't for a while
[12:18] <dandrader> tsdgeos, I don't see much sense in this bug: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1519250
[12:19] <dandrader> tsdgeos, run.sh doesn't even work in my desktop... I fankly don't completely understand what this script does
[12:19] <tsdgeos> it starts unity8
[12:19] <tsdgeos> with some evnvars
[12:19] <dandrader> tsdgeos, through a upstart session
[12:19] <tsdgeos> yep
[12:19] <tsdgeos> it's bascailly like doing
[12:19] <tsdgeos> start unity8
[12:20] <tsdgeos> with the local unity8
[12:20] <tsdgeos> and some paths changed
[12:28] <dandrader> tsdgeos, do you have any idea what brings in the qtubuntu (qtubuntu-android I guess) package into phone image?
[12:28] <dandrader> tsdgeos, is it some package dependency or is it "seeded" into the image?
[12:29] <tsdgeos> dandrader: ubuntu-touch
[12:30] <tsdgeos> apt-cache rdepends qtubuntu-android
[12:30] <dandrader> tsdgeos, ah, handy command
[12:32] <tsdgeos> dandrader: faenil: i found out why right edge verticall scrolling doesn't work
[12:32] <tsdgeos> it's scrolling the next scope :D
[12:32] <dandrader> tsdgeos, so a problem with nested flickables?
[12:33] <tsdgeos> don't know yet
[12:33] <tsdgeos> i can't reproduce it on the unity7 desktop
[12:34] <tsdgeos> wonder if it's a bug somewhere in mir, qtmir, qtubuntu or what
[12:34] <tsdgeos> i tried https://code.launchpad.net/~dandrader/unity8/pixelAlignedWindow/+merge/295262 just in case but wasn't it
[12:34] <tsdgeos> the cursor part, not the window part
[12:50] <faenil> tsdgeos: haha :)
[12:50] <faenil> tsdgeos: I wonder why scrollwheel scrolls the current one then :)
[12:51] <tsdgeos> different paths i guess
[12:51] <faenil> yeah
[13:12] <tsdgeos> dandrader: ping
[13:13] <tsdgeos> the mouse events are screenPos=QPointF(0,227) on the left and screenPos=QPointF(540,227) on the right
[13:13] <tsdgeos> which means the window is 541 wide
[13:14] <tsdgeos> that's why the mouse click goes to the wrong thing
[13:14] <tsdgeos> the window is really 540 wide
[13:14] <tsdgeos> any idea how to debug why the cursor sends 540 instead of 539 when on the right hand side?
[13:19] <dandrader> tsdgeos, pong
[13:20] <tsdgeos> would UbuntuInput::dispatchPointerEvent what i want?
[13:20] <tsdgeos> dandrader: ↑↑↑↑
[13:21] <dandrader> tsdgeos, first check what MirSurfaceItem gets. and its dimensions
[13:22] <tsdgeos> dandrader: in unity8?
[13:22] <dandrader> tsdgeos,  yes
[13:22] <dandrader> tsdgeos, and also the TouchGate in SurfaceContainer.qml, which forwards events to the MirSurfaceItem behind it
[13:23] <dandrader> tsdgeos, actually, to check what MirSurfaceItem gets you have to go to qtmir. not unity8
[13:24] <dandrader> tsdgeos, but if you want to start investigating on the client side then yeah qtubuntu would be the place...
[13:45] <tsdgeos> dandrader: is touchgate involved in mouse clicks too? (i.e non touch)
[13:46] <dandrader> tsdgeos, right, it is not
[13:47] <tsdgeos> oki
[14:04] <tsdgeos> dandrader|afk: so the item is 540 width but still gets a click on pos 540
[14:04] <tsdgeos> http://paste.ubuntu.com/17324581/
[14:25] <tsdgeos> dandrader: https://code.launchpad.net/~aacid/unity8/dont_let_mouse_outside_item/+merge/297342
[14:50] <dandrader> tsdgeos, approved. although there two small improvements you could make
[14:50] <tsdgeos> sure
[14:56] <dandrader> mterry, remember that ubuntu-keyboard packaging dependency on qtubuntu? that was the only way to have it working:
[14:56] <dandrader> mterry, http://bazaar.launchpad.net/~dandrader/ubuntu-keyboard/mirSurfaceInputBounds/revision/480
[14:56] <dandrader> mterry, otherwise it was forcing instalation of qtubuntu-desktop on the phone
[14:57] <dandrader> mterry, looks like this "Provides: qtubuntu" isn't worth much...
[14:58] <tsdgeos> dandrader: done
[14:58] <dandrader> tsdgeos, thanks
[15:00] <tsdgeos> dandrader: xvfbtestSpreadDelegate seems to be failing in your branch
[15:00] <tsdgeos> splashRotation
[15:00]  * dandrader checks
[15:01] <dandrader> tsdgeos, indeed :/
[15:03] <dandrader> oh, the refactoring broke those tests because they're poking into internals to check state
[15:07] <dandrader> tsdgeos, fixed
[17:58] <mterry> josharenson, I added a comment about SVG vs PNG for the greeter session icons in your sessions-model branch
[17:58] <mterry> josharenson, I wish we had chosen SVG from start, but this may be a good time to switch to it
[17:58] <mterry> josharenson, mostly just for coloring ease, but also for scalability
[17:58] <josharenson> mterry: I hope you want me to use SVG's cause they are the only thing cooler than pngs
[17:58] <josharenson> ok
[17:58] <josharenson> mterry: Are the svgs available somewhere
[17:58] <mterry> josharenson, nope!
[17:58]  * josharenson reads the comment first
[17:58] <josharenson> oy
[17:59] <mterry> josharenson, but I realized old icons are white.  And we now have a white background with greeter-box
[17:59] <mterry> josharenson, the visual mockups I have use a gray, and ideally would follow theme as Design tweaks it in future
[18:00] <josharenson> mterry: I bet I could find someone who would make those icons svgs in 24 hours for like $20
[18:00] <mterry> josharenson, I think there are command line tools for that
[18:00] <josharenson> mterry: I didn't realize those formats could be converted...
[18:00] <mterry> josharenson, not directly, but... algorithms
[18:00] <josharenson> mterry: so a rasterized image to svg?
[18:00] <josharenson> these are simple I suppose?
[18:01] <mterry> josharenson, yeah.  raster to vector
[18:01] <mterry> josharenson, maybe?  might be able to do 'unknown' and 'ubuntu' ourselves
[18:01] <josharenson> mterry: you're crazy! ok I'll take a look
[18:01] <mterry> josharenson, since ubuntu is literally just our logo
[18:01] <mterry> josharenson, and unknown is a circle
[18:01] <mterry> josharenson, now there's a trick to make an svg icon themable, let me find that
[18:01]  * josharenson knows enough about inkscape to make those he supposes
[18:04] <mterry> josharenson, we may not need to do gnome and kde yet, don't need to block on that immediately
[18:05] <mterry> josharenson, hmm
[18:06] <mterry> josharenson, Icon's docs suggest we don't need to use svg to get colorization
[18:06] <mterry> josharenson, if we set an Icon {} object's keyColor to white
[18:06] <mterry> josharenson, and the color to the color we want
[18:06] <mterry> josharenson, let me test
[18:06] <mterry> josharenson, svg may still be a wise change, but if we can avoid the work now...
[18:08] <mterry> josharenson, yup, that works.  OK, cancel worrying about svgs for now.  I'll include this change in my merge-greeter-box branch


[10:30] <reqa> Hi, I can't log in to https://blueprints.launchpad.net/openstack using my Ubuntu One account (Error ID: OOPS-9933b18eeda9d3450cbb92620c79428c). I tested with Firefox and Chrome. I accepted only essential cookies. I didn't see anything obvious (OAuth redirect issue) in the Firefox network console. I can login normally at https://login.launchpad.net directly, but that doesn't get me accepted at the blueprints site.
[10:31] <reqa> Hi, I can't log in to https://blueprints.launchpad.net/openstack using my Ubuntu One account (Error ID: OOPS-9933b18eeda9d3450cbb92620c79428c). I tested with Firefox and Chrome. I accepted only essential cookies. I didn't see anything obvious (OAuth redirect issue) in the Firefox network console. I can login normally at https://login.launchpad.net directly, but that doesn't get me accepted at the blueprints site. -- Any hints what I could
[10:31] <reqa> check?
[10:32] <cjwatson> reqa: it's probably an issue with your account - I suggest emailing<EMAIL_ADDRESS>and quoting that error ID
[10:33] <reqa> thx
[14:57] <schopin> Hi folks! We're seeing a few builds on arm64 that are taking waaaaaay too long (acl2 and llvm-toolchain-14, maybe other). Is that a know problem?
[15:00] <juliank> acl2 has been running 10 times longer than last run (16h last run vs running since Apr 1 now9
[15:03] <cjwatson> It's probably still the case that the arm64 farm includes a fair variety of underlying hardware
[15:03] <cjwatson> We'd talked about disabling the oldest generation or making it armhf-only or something, but I'm not sure where that work sits
[15:17] <schopin> I'm guessing Colin is right, but would it be possible to have confirmation of that hypothesis? :)


[16:31] <belak> I've been trying to change a few things in ubiquity and I was wondering how I can change the text of the english language for the install? I'm helping with an ubuntu derivitive and we'd like it to say Thank you for installing X in stead of Ubuntu at the end of the install in the box that asks you to reboot. I found the file in source, debian/ubiquity.templates. but how would I go about replacing the default?
[20:21] <ubuntu-installer> Does anyone know how to install Ubunto-Server image from local NFS server?
[20:23] <ubuntu-installer> I try to mount exported directory from NFS as local /CDROM for ubuntu-server installation. But, failed.
[21:34] <ubuntu-david> My Ubuntu-Server LiveCD is hosted on one of Ubuntu machine and export as directory by NFS. I am using Pxelinux to boot mini from local Server as well. But, I cannot mount exported directory from Local NFS Server directory as /CDROM. My Installation is stopped at try to load package from /CDROM. Is this possible? If yes, pleaes tell me how to do this.


[01:57] <xnox> mwhudson:  which one of the casper bugs?
[01:57] <mwhudson> xnox: i meant https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1867065 but i've tried to reproduce now
[01:58] <mwhudson> xnox: i do think that checking md5sums by default maybe be a bad experience over usb2...
[01:58] <xnox> mwhudson:  it actually is this https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1867130
[01:58] <xnox> mwhudson:  it was beautiful with ubuntu-logo theme, but it is not with spinner, because regressions.
[01:58] <mwhudson> xnox: ah
[01:58] <xnox> mwhudson:  i have action to look at all other regressions too
[01:59] <mwhudson> xnox: cool!
[01:59] <xnox> mwhudson:  the top 4 bugs on https://bugs.launchpad.net/ubuntu/+source/plymouth/+bugs?orderby=-id&start=0
[05:31] <alkisg> Hi, running pam-auth-update regenerates /var/cache/debconf/templates.{dat,dat-old} with NO changes and this wastes 34 MB RAM in live boots like LTSP or casper
[05:31] <alkisg> This was reported in LP bug #43706, but it was never resolved properly, only worked-around
[05:31] <alkisg> Should I report a bug in debconf and/or pam, or is it by design and I should just apply a workaround in LTSP?
[06:53] <rbasak> alkisg: sounds to me that you're reporting something different from what was fixed in bug 43706.
[06:53] <alkisg> rbasak: "we're also storing two copies of them (templates.dat and templates.dat-old). "
[06:54] <alkisg> That bug has 3 subissues, I'm talking about that one
[06:54] <rbasak> alkisg: the bug says that was fixed by removing dat-old?
[06:54] <rbasak> alkisg: I suggest that you start by filing a new bug that covers only one issue
[06:54] <rbasak> alkisg: but also, please suggest a patch!
[06:55] <alkisg> rbasak: right, while cjwatson was planning to see why the template was being written in the first place, that plan got aborted and a simple workaround "rm" was implemented, to save half the space (the copy, not the original .dat which also takes tmpfs space)
[06:56] <alkisg> rbasak: but is it considered a bug? If debconf is supposed to rewrite the database even when there are no changes, then... it's not a bug, it's a "feature", and I only need to do a similar workaround in ltsp
[06:56] <rbasak> It sounds like a valid unfortunate interaction in your use case
[06:57] <rbasak> In general, people are willing to consider changing design when these things happen
[06:57] <rbasak> Depending on the implications involved
[06:57] <rbasak> The only way to find out is to file a bug with an explanation and a concrete proposal to change it, and see what happens, IMHO.
[06:58] <rbasak> This is just speaking from experience in working in our ecosystem. I can't speak for casper/pam-auth-update/debconf.
[06:59] <alkisg> To phrase is at a small question/issue: "Running pam-auth-update regenerates /var/cache/debconf/templates.dat with no changed content. Should I report this as a bug, and where?"
[06:59] <alkisg> If this will be accepted as a valid issue, then sure I could spend a few days and try to pin point it
[07:00] <alkisg> But spending a few days to get "nah it's by design" isn't a good investment of time; so I was just looking for an initial yes/no answer from someone with more debconf knowledge than me
[07:00] <rbasak> I think it's a perfectly valid question.
[07:01] <rbasak> Without knowing the internals it sounds like a reasonable thing to be changed.
[07:01] <alkisg> Thank you, I'll start by reporting it to launchpad/debconf
[07:01] <rbasak> I wouldn't know if it's pam-auth-update or debconf without reminding myself of the debconf shell API again.
[07:02] <alkisg> From what I see, pam-auth-update just opens/closes debconf, it doesn't have much control over it
[07:02] <alkisg> So just by a tiny first look, I think it's debconf, not pam
[07:02] <rbasak> Then I agree that debconf would be a good place to start. It can always be changed.
[07:08] <alkisg> Reported LP bug #1867315
[07:09] <rbasak> Thanks!
[07:09] <alkisg> Thank you too, as always :)
[07:13] <rbasak> alkisg: looks like https://git.launchpad.net/ubuntu/+source/debconf/tree/Debconf/DbDriver/File.pm might be the right place to fix this maybe?
[07:14] <alkisg> rbasak: yes, editing that file bypasses the issue
[07:14] <alkisg> I think somehow the dirty flag is set while it shouldn't
[07:14] <rbasak> That looks like a valid bug then
[07:15] <alkisg> I'm not even sure if templates.dat should be "Readonly" by debconf or not... are postinst programs supposed to write there, or is it extracted by some external script...
[07:15] <alkisg> If I set it to Readonly, again problem solved, but I've no idea if it's a valid approach
[07:15] <alkisg> In /etc/debconf.conf
[07:16] <rbasak> New templates would get added as new packages are installed, I guess?
[07:16] <rbasak> So speaking system-wide, having it read-only would be wrong I think.
[07:16] <alkisg> Yes, but does debconf handle that as part of opening/closing it, or an external tool (like update-initramfs) is supposed to regenerate everything? Dunno
[07:16]  * rbasak isn't sure
[07:17] <alkisg> It feels weird if any program that calls debconf open templates in write mode
[07:17] <rbasak> Now you appear to have two bugs :-)
[10:58] <xnox> cjwatson:  we have some broken XB-Cnf-* metadata on a few binary packages across a few releases, and the packages in question are expensive to SRU (python2.7 python-defaults python3.6 python3-defaults python3.7 python3.8) and some of them have no outstanding plans to SRU. Are there any archive publishing side that I could fix? I.e. something like priority-override, but arbitrary header override? Or for
[10:58] <xnox> example could I do some custom cases in the command-not-found-extractor?
[10:59] <xnox> mvo is not in the channel. Can't remember who else touched cnf-extractor, maybe Laney?
[11:02] <Laney> well I do have access to the thing
[11:02] <Laney> but it's probably more of an mvo question
[11:17] <cjwatson> xnox: If they're wrong in the release pocket, then we pretty much just have to deal with that anyway, since we aren't going to republish release pockets for reasons short of legal threats
[11:18] <cjwatson> xnox: The extractor supplies Commands-* files on the side, but I don't believe it does other fields (ICBW).  There's no arbitrary field override mechanism
[11:19] <xnox> Thank you! this is very useful.
[11:19] <xnox> Yeah, i need to drop headers & add headers, i guess SRU it is.
[12:53] <ahasenack> cpaelzer: rbasak rafaeldtinoco: ok to sync postfix.3.4.10-1? diff: https://paste.ubuntu.com/p/43Cw8dNth9/
[12:53] <ahasenack> upstream release notes: http://www.postfix.org/announcements/postfix-3.4.10.html
[13:17] <rafaeldtinoco> ahasenack: /me checks
[13:19] <cpaelzer> damn you beat me by a minute rafaeldtinoco :-)
[13:20] <rafaeldtinoco> hihi
[13:20] <cpaelzer> ok 2
[13:21] <rafaeldtinoco> ahasenack: +1
[13:21] <ahasenack> thx
[13:21] <ahasenack> well, you both can look
[13:21] <ahasenack> I don't mind
[13:22] <ahasenack> any concerns cpaelzer ?
[13:22] <ahasenack> other than the current breakage in focal I assume?
[13:22] <ahasenack> debian ci hasn't run it yet
[13:30] <cpaelzer> ahasenack: I haven't looked at it since rafaeldtinoco did
[13:30] <cpaelzer> if you want me to I can ...
[13:47] <ahasenack> thanks, synced
[14:38] <coreycb> jamespage: I'd like to bump pyroute2 from 0.5.7 to 0.5.9. there are a lot of updates in 0.5.9, and while it's not specifically an openstack dep it is mostly an openstack dep. hard to tell if it is just a bug-fix release.
[14:39] <coreycb> anyway that is what openstack ussuri currently has for upper-constraints
[15:32] <mpt> Anyone know where I could find a browsable list of all Universe packages in 16.10 LTS? <https://packages.ubuntu.com/xenial/> lists them by pocket and by Section, but not by repo
[15:34] <marcoagpinto> mpt: 16.10 isn't LTS
[15:34] <marcoagpinto> only 16.04
[15:34] <marcoagpinto> only .04 versions are LTS
[15:34] <mpt> Sorry, 16.04 LTS, you’re quite right
[15:39] <mpt> I don’t see a list of them at <https://launchpad.net/ubuntu/xenial> either
[15:42] <coreycb> hello release team, I've uploaded a new point release for python-pyroute2. it's mostly an openstack dependency (dhcpcanon and pathspider are not openstack) and gets us up to the desired upper-constraint version that neutron etc need.
[18:04] <pyusr> hmm... maybe python should define an /usr/bin/python2_or_3 so  scripts that do "#!/usr/bin/env python" like poetry, can work on systems that don't have python 2 by default (like new ubuntu versions) ?
[18:06] <cjwatson> pyusr: https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040918.html
[18:06] <pyusr> can anybody move along this SRU ? https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766
[18:11] <pyusr> nice, but I'm ont sure what happens, if today in focal I run something with "#!/usr/bin/env python" what will happen by default ?
[18:13] <cjwatson> my understanding is that focal deliberately doesn't have /usr/bin/python for a while in order to shake out issues
[18:13] <cjwatson> but this is only second-hand.  you can try it yourself
[18:15] <pyusr> don't have it, but I'm wondering what about thousands of scripts like this that will stop working: https://python-poetry.org/docs/
[18:15] <pyusr> tons of workflows will be broken
[18:16] <pyusr> (stuff outside the apt echo system)
[18:16] <cjwatson> OK, I'm out of here, have told you everything I can
[18:46] <smoser> pyusr: python2or3
[18:46] <smoser>  https://gist.github.com/smoser/8904199bb8f00a90dd04
[18:47] <pyusr> that script exists in ubuntu 20.4?
[18:48] <smoser> no. but it could.
[18:48] <smoser> but as you can see... referenced is 14.04
[18:48] <smoser> the right answer, imho, in 2020 is to not have /usr/bin/python
[18:48] <pyusr> and what about the thounsands of workflows outside of the apt ecosystem which will stop working?
[18:49] <smoser> and it seems honestly wrong to me, and just silly to have /usr/bin/python be python3
[18:49] <pyusr> I tried following this today, and ofcourse it borked... https://python-poetry.org/docs/
[18:49] <pyusr> everyscript that has #!/usr/bin/env python will stop working
[18:50] <smoser> well, imo those things asked to be interpreted by python2
[18:50] <pyusr> poetry as you can see in that page supports both 2 and 3
[18:50] <smoser> and trying to execute them through python3 is not right.
[18:50] <pyusr> you are wrong
[18:50] <pyusr> tons of stuff support both
[18:50] <pyusr> and #!/usr/bin/env isn't expressive enough for that
[18:51] <pyusr> again, check that, one of the biggest packages
[18:52] <smoser> pyusr the biggest argument i have for breaking 'python' is to avoid the same problem in 6 years with python4
[18:52] <smoser> the python community learned nothing from the same thing that happend to perl between perl4 and perl5
[18:52] <pyusr> yeah, so didn't ubuntu, it's already 2 month that ubuntu 16.04 (which is still LTS supported) doesn't work with virtualenv and python2 ... and nobody is in a hurry to fix it
[18:52] <smoser> but, anyway... somethign like python2or3 i think would be a nice way to say "this works in python2 or 3"
[18:53] <pyusr> tons of people CI broke over night
[19:01] <rbasak> pyusr: you'll be able to install the python-pointing-to-python2 package
[19:02] <rbasak> pyusr: oh, sorry, it'll be called python-is-python2-but-deprecated
[19:02] <rbasak> If you install that, your legacy scripts will work
[19:02] <pyusr> rbasak: will it inform me that when I try to run a script with #!/usr/bin/env python ?
[19:02] <rbasak> No.
[19:03] <rbasak> See https://www.python.org/dev/peps/pep-0394/ for more background on this
[19:03] <pyusr> so again, tons of workflow will be broken
[19:03] <rbasak> There's distro-wide consensus that python should eventually point to python3
[19:03] <rbasak> This is not an Ubuntu-only choice.
[19:03] <pyusr> yeah, but lots of noobs use ubuntu
[19:03] <pyusr> they will be confused
[19:04] <rbasak> People learning Python also get confused when "python" doesn't work or gives them some old version.
[19:04] <rbasak> Unfortunately there's no solution that will work for everyone.
[19:05] <pyusr> windows 10 opens the windows store with python installation when you type python in command promopet
[19:15] <pyusr> rbasak: I think ther eis, the OS should provide /usr/bin/python2or3
[19:16] <pyusr> and scripts should rely on it if they support both
[19:17] <rbasak> pyusr: great - I suggest you follow the upstream process of getting PEP 394 amended with that suggestion.
[19:18] <pyusr> PEP does not enforce OS but Python itself
[19:31] <pyusr> ok, better solution, "/usr/bin/env" in ubuntu should check if /usr/bin/python does not exist (and someone wants /usr/bin/env python) it should bring up a warning about what to do ?
[19:33] <pyusr> how does one go about offering that ?
[19:36] <tumbleweed> It's hard to imagine /usr/bin/env changing, to help Python users
[19:37] <pyusr> tumbleweed: there are gonna be tons of noobs that will start crying with 20.4 LTS
[19:37] <pyusr> why not improve their experience ?
[19:37] <tumbleweed> it's not /usr/bin/env's job to do that
[19:38] <pyusr> you understand that https://github.com/python-poetry/poetry/issues/2183 <-- this is a tip of the iceberg ?
[19:38] <pyusr> and thats a very popular package, think about all the abandond scripts people use daily that will stop working, and they will get a criptic message they will need to google ?
[19:39] <tumbleweed> yeah, the end of python 2 is a lot of pain for everyone
[19:39] <tumbleweed> I'm saying that this specific solution sounds like a non-starter
[19:40] <rbasak> The problem is that unless you put in a python2or3 command into every existing distro and release that people use, it's of little use.
[19:40] <pyusr> rbasak: I'm offering a different solution now
[19:40] <rbasak> I don't think it's appropriate to patch or redirect /usr/bin/env.
[19:40] <pyusr> the main issue is #!/usr/bin/env python gives a criptic error /usr/bin/env: 'python': No such file or directory
[19:41] <pyusr> it does not say "Python 2 is not installed on the system":
[19:41] <rbasak> And in any case it won't help scripts that don't /usr/bin/env.
[19:41] <rbasak> pyusr: in any case, I don't think somebody with no credentials and no prior track record is going to be able to appear on this channel and convince us to do anything this major.
[19:41] <pyusr> most scripts do, and those who don't maybe the error will be better "/usr/bin/python" no such file or directory
[19:42] <rbasak> That's why I said you should focus on getting consensus upstream.
[19:43] <pyusr> I don't even know how I can find someone to fix ubuntu 16.04 virtualenv to work...
[19:43] <rbasak> Or at least a mailing list
[19:43] <rbasak> pyusr: have you proposed a patch?
[19:43]  * rbasak needs to go
[19:43] <rbasak> I appreciate that you care
[19:43] <rbasak> But the way to get things done in this ecosystem is to present working solutions and build consensus to use them
[19:43] <pyusr> there is an SRU patch waiting for a month
[19:43] <rbasak> IRC doesn't really work for that.
[19:44] <rbasak> pyusr: link please?
[19:44] <pyusr> https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766
[19:44] <tumbleweed> pyusr: and I field that SRU, and rbasak has commented on it
[19:44] <rbasak> Ah
[19:44] <pyusr> tumbleweed: ahh, cool
[19:44] <rbasak> I reviewed that the other day, yes
[19:45] <rbasak> (well, I didn't, since I don't think I'm sufficiently qualified)
[19:45] <tumbleweed> :P
[19:45] <tumbleweed> yeah, was hoping to get doko's attention
[19:45] <rbasak> I pinged doko about that earlier ^
[19:45] <rbasak> :)
[19:45] <pyusr> rbasak: that bug is ongoing for 2 month already :(  It makes me wonder how has it not surfesed enough
[19:45] <pyusr> surfaced
[19:46] <rbasak> pyusr: right - only one person marked affected
[19:46] <rbasak> Trust me - when it affects a large number of people, the noise is noticeable :)
[19:46] <pyusr> I discovered the bug, told my friend about it, he linked me to his buildbots of pypy stoped working
[19:46] <pyusr> so he formated the machine to 18.04
[19:47] <pyusr> rbasak: maybe people stoped using system python with CI with stuff like pyenv, asdf
[19:47]  * rbasak does really need to go now
[19:47] <pyusr> laters
[19:47] <pyusr> tumbleweed: you don't think a better error msg on /usr/bin/env is a good idea ?
[19:49] <tumbleweed> I'd talk to the coreutils upstream - this is a common use for /usr/bin/env, and the error message could be improved to help users
[19:49] <tumbleweed> I don't think the best approach is to be Python-specific, though
[19:50] <pyusr> maybe like ubuntu has that autofigure out which package to recommend on error
[19:50] <pyusr> and link that into /usr/bin/env errors
[19:50] <tumbleweed> using /usr/bin/env to find a program on PATH is a total abuse of the purpose of it... but it's probably 90% of what it's used for, these days
[20:23] <pyusr> also, shouldn't nvidia-drivers for ubuntu (16.04) check that HWE is neabled ?
[20:23] <pyusr> instead of borkign the system
[20:28] <vorlon> objection, assumes facts not in evidence


[00:12] <thumper> oh ffs
[00:13] <thumper> lbox choked on this: https://code.launchpad.net/~thumper/juju-core/consolidate-bootstrap-state/+merge/172701
[00:13] <thumper> bigjools: you like go, care to review?
[00:14] <bigjools> thumper: I LOVE go
[00:14] <bigjools> thumper: but I might have to pass, I'm not really working today
[00:14] <thumper> bigjools: oh?
[00:15] <thumper> :(
[00:15] <thumper> neither is wallyworld
[00:15] <bigjools> it's easier to ask for forgiveness than to block ;)
[00:28] <thumper> bigjools: ha, not blocked
[00:44] <thumper> davecheney: what does it mean for a struct to embed an interface?
[00:45] <davecheney> thumper: type S struct { io.Reader }
[00:45] <davecheney> ^
[00:45] <thumper> yeah, or similar
[00:45] <thumper> in this particular instance it is environs.Environ
[00:46] <davecheney> it's a shorthand for having to type out all the methods in the io.Reader interface
[00:46] <thumper> and it only defines some methods
[00:46] <thumper> what about the methods it doesn't define?
[00:46] <thumper> you don't normally type out methods inside a struct
[00:46] <thumper> I know about embedding an interface in an interface
[00:46] <davecheney> that is correct
[00:46] <thumper> but this is different
[00:46] <davecheney> yeah, interface inside interface really just is short hand
[00:47] <davecheney> so, by embedding an io.Reader inside S this method is automatically crated
[00:47] <davecheney> type (s *S) Read(...) { return s.Reader.Read(...) }
[00:47] <davecheney> there actually is not forwarding method
[00:48] <davecheney> but the world behaves as it is is
[00:49] <thumper> ...
[00:49] <thumper> oh
[00:49] <thumper> so we can implement an interface
[00:49] <thumper> without implementing all the interface
[00:49] <thumper> I get it now
[00:50] <bigjools> what happens when an unimplemented method is called?
[00:50] <davecheney> well ... yues
[00:50] <davecheney> S.Reader is nil
[00:50] <bigjools> so, boom?
[00:50] <davecheney> so S.Read will blow up unless something has been assigned to S.Reader
[00:55] <bigjools> isn't this dangerous?
[00:56] <davecheney> i'm not really sure what you're trying to do
[00:56] <davecheney> thumper
[00:57] <thumper> davecheney: it isn't me, it is me understanding our existing code
[00:57] <davecheney> ok
[00:57] <thumper> we have a test that is testing bootstrap and has a fake environment
[00:57] <thumper> it only implements the functions it cares about
[00:57] <thumper> and passes the test structure through as an environs.Environ
[00:58] <thumper> seems to work
[00:58] <davecheney> yup
[01:22] <bigjools> davecheney: any luck working out go-curl with Go1?
[01:38] <davecheney> bigjools: we need at least version 1.0.2 to make it work
[01:38]  * davecheney finds issue
[01:39] <davecheney> bigjools: https://bugs.launchpad.net/gwacl/+bug/1196811
[01:39] <bigjools> k
[01:48] <thumper> omg...
[01:48] <thumper> we are going to have some work cut out with HA state
[01:48] <thumper> there is a lot of code that assumes one and only one state server
[01:48]  * thumper passes that problem on to a future self
[04:02] <thumper> davecheney: what's the practicle difference between path.Join and filepath.Join?
[04:02] <thumper> practical
[04:07] <thumper> grrr
[04:07] <thumper> freaking import loops
[04:47] <davecheney> thumper: path is an ideal path, filepath is OS specific
[04:47] <thumper> davecheney: so which should we be using? filepath?
[04:48] <davecheney> if it is a filesystem path, filepath
[04:48] <davecheney> if it is an ideal path, a url, use path
[05:27] <jam> thumper: I'm looking at your branch, btw.
[05:28] <thumper> jam: oh, ok
[05:28] <thumper> jam: there are two
[05:28] <jam> thumper: pratical matters, 'filepath' will create '\' in names on Windows, "path" never will
[05:28] <jam> I would point you towards using 'path' as a default unless there are strong reasons not to.
[05:28] <jam> I had to audit a bunch of places recently to get a client on win32 to work
[05:29] <jam> thumper: so while I agree with dfc's comment, I would add to it "if in doubt, use path"
[05:29] <jam> as those generally still work on all platforms.
[05:30] <jam> The only things I've found that need '\' are: dir (because it uses / to indicate argument flags), and the actual executable that you are spawning
[05:35] <jam> thumper: for https://code.launchpad.net/~thumper/juju-core/consolidate-bootstrap-state/+merge/172701
[05:36] <jam> I'm a little unsure about having a LoadProviderState function that returns a list of instances
[05:36] <jam> 'state' sounds like an object to me
[05:52] <thumper> jam: sorry, afk now and not wanting to think too deeply.  We could change it to be LoadProviderInstances
[05:52] <thumper> it never was a "state" type thing
[05:52] <thumper> just one instance id
[05:52] <thumper> and later more than one
[08:03] <jam> mgz_: I did try manually merging and just running the ec2 tests on go-bot, and it failed for me.
[08:03] <jam> I'm running them now to make sure it runs fine without your patch.
[08:04] <jam> My guess is that the patch introduces a bad setup/teardown which causes a test to hang
[08:04] <jam> and thus gets killed after 5min
[08:04] <jam> With -gocheck.v I see this: http://paste.ubuntu.com/5839627/
[08:05] <jam> without the merge, I see this: http://paste.ubuntu.com/5839628/
[08:05] <jam> So I'm pretty sure BootstrapMultiple is the culprit
[08:07] <jam> except running just "go test -gocheck.v -gocheck.vv -gocheck.f BootstrapMultiple" passes the test.
[08:07] <jam> makes me wonder if there is a timing related issue
[08:07] <jam> one test not cleaning up in time for the other test to have a clean slate.
[08:10] <jam> hmmm... picked the wrong test.
[08:10] <jam> I saw the one that was skipped, but we have 2 skipped.
[08:10] <jam> I need the one after BootstrapWithDefaultSeries
[08:30] <jam> jtv: poke
[08:30] <jam> not sure if you are still around
[08:30] <jtv> Hi jam
[08:30] <jam> I'd like to see one more test for https://codereview.appspot.com/10905043/, but I can help you add if if you need.
[08:30] <jtv> About to go into my standup!
[08:30] <jam> specifically, lets test this against all environs, so we all do the same thing.
[08:41] <jam> mgz_: so the full run without your patch is: http://paste.ubuntu.com/5839699/
[08:42] <jam> that would mean TestDestroy is what is failing.
[08:43] <jam> running it by itself with -gocheck.vv passes, though with: http://paste.ubuntu.com/5839700/
[09:07] <jam> jtv: when you're back, I think I've reviewed all your branches.
[09:07] <jam> (my personal queue has emptied)
[09:08] <jtv> jam: just out of the call & looking at your review.  Thanks for running the tests as well; it's been taking me ages to get a cloud instance set up for that.
[09:08] <jtv> (My working machine is an i386 installation, so can't run all of the tests)
[09:09] <jtv> fwereade: is https://codereview.appspot.com/10869043/ to your satisfaction with the explanation & added comment?
[09:09] <jam> jtv: I didn't actually run the tests for your patches. I'm going over a failing submission from mgz.
[09:09] <jam> jtv: but I certainly can on request :)
[09:09] <jtv> oh
[09:09] <jtv> Well, I'm trying to run tests.  :)
[09:09] <jam> mgz_: mgz_: http://paste.ubuntu.com/5839754/ is the test suite with danilos' patch. It almost looks like CheckEnvironmentsOnConnect is running too fast. So it is starting up and stopping and then another thread gets stuck waiting for stuff to come up.
[09:10] <jam> jtv: and the bot will run all the tests when it goes to land
[09:10] <jtv> jam: I wonder if the review changes to my branch could be handled in a separate branch… I've already started on a new branch and with colocation this sort of thing is very awkward.  I think it's been costing us a lot.
[09:10] <jtv> oh nm, my current code can wait.
[09:11] <jam> jtv: do you use a lightweight checkout or cobzr?
[09:11] <jam> bzr commit/bzr shelve; bzr switch works pretty well for me.
[09:12] <jtv> Yes.
[09:12] <jam> jtv: as for the original question, yes you could do it in a followup.
[09:12] <jtv> Thanks.
[09:14] <jtv> jam: I did wonder why 10ns is too short  a timeout — why wait at all?  Really the only reason I didn't set zero was that that number might have a special meaning.
[09:14] <jam> fwereade: just a mechanical rename change: https://codereview.appspot.com/10906043/
[09:14] <jam> jtv: if you are dealing with goroutines
[09:15] <jam> you might need a sleep
[09:15] <jam> because they are not preemptive
[09:15] <jam> and if the timeout is too short, it will just return "false" immediately
[09:15] <jtv> I was told even time.Sleep(0) would yield.
[09:15] <jam> and never give the other goroutine a slice to do its init/etc.
[09:15] <jam> jtv: I looked at AttemptStrategy
[09:15] <jam> it always retruns 1 time without sleeping
[09:15] <jam> and then if now + delay < end it won't ever sleep
[09:16] <jam> jtv: http://paste.ubuntu.com/5839772/
[09:16] <jam> if I havent set end yet, just return true
[09:16] <jam> once it is set
[09:16] <jam> if now + delay > end return false
[09:16] <jam> no sleep
[09:16] <fwereade> jam, a suggestion -- NotifyWatcher is an interface, EntityWatcher is an implementation of that interface? don't actually need to export entityWatcher
[09:16] <jam> so we could set Total up
[09:17] <jam> and Delay to 9
[09:17] <jam> sorry, to 0
[09:17] <jtv> So this makes our tests invisibly timing-dependent?  Bummer.
[09:17] <jam> jtv: well, the current codebase is far more timing dependent than I would like
[09:17]  * jtv sad
[09:18] <jam> fwereade: that would be possible, but does it benefit us to call the public interface something else in its private implementation ?
[09:18] <jam> fwereade: seems more like a case of "so what watchers do I have, oh this entity thing..."
[09:18] <fwereade> jam, I think so, because eg CleanupWatcher has Changes() <-chan struct{}
[09:19] <jam> fwereade: so I guess it depends on what your thoughts on why some things should be a NotifyWatcher (significant detail is that it has a Changes that returns no content), and entityWatcher whose significant detail is that it watches a document.
[09:20] <fwereade> jam, it might be a dumb idea -- but ISTM that the document watching is very much an implementation detail
[09:21] <fwereade> jam, we could go either way, I think, either have N types for N different watchers -- MachineWatcher, UnitWatcher, ServiceWatcher, blah, blah
[09:22] <fwereade> jam, or just categorize them all by what sort of data they send and save a load of boilerplate at the API level
[09:22] <fwereade> jam, the middle ground where we categorize by implementation seems a bit off though
[09:22] <jam> fwereade: if they don't have a functional difference, I'd like to go with the NotifyWatcher at API level.
[09:22] <fwereade> jam, yeah, that's what I'm thinking
[09:24] <fwereade> jam, but it may as well be what we expose in state as well
[09:25] <jtv> jam: thanks for explaining the timing issue by the way.  The code I based this on just set the timings to 0.01e9 and 0.25e9, without documentation — with this knowledge looked more like a deliberate trap than proper software engineering.
[09:26] <jam> jtv: there was a discussion about what was 'right', I think we want to go with 10*time.Millisecond rather than 0.01e9
[09:26] <jam> we've used it in most of the other places
[09:26] <jam> though the discussion at the time was "I perfectly understand that the field is in Nanoseconds and find the shorter scientific notation more readable"
[09:27] <jam> jtv: I don't know if it was clear, you don't have to fix DummyProvider in your patch
[09:27] <jam> I was just offering ways in which it might have been hanging.
[09:27] <jtv> Ah yes, the if-normal-people-can-read-this-I-won't-be-elite argument...  :/
[09:27] <jtv> I hadn't gotten to that point yet — still documenting the timing issue.  :)
[09:28] <jtv> Because really, I don't care a hoot what the timing should be, just that it be clear _why_ it is what it is.
[09:28] <jtv> Exactly so that this conversation (or worse, ill-advised code change) doesn't have to happen again.  :-)
[09:29] <jam> jtv: yeah, I personally find the attempt strategy's logic a bit odd. So that the actual time you sleep isn't >= Total, but instead >= Total-Delay
[09:30] <jtv> These things do get hairy if you want to get them right... sometimes the accounting gets a bit weird if you also want it to include the time spent doing the accounting itself and such.
[09:31] <jtv> But I'm merrily staying out of that for now, just documenting what the crucial factors are that should urgently have been documented originally.
[09:31] <jam> jtv: yeah, and is the statement meaning "I want to wait no more than X" or "I want to wait at least X"
[09:31] <jtv> Good one.
[09:32] <jam> fwereade: also, you didn't LGTM the upgrader-api branch
[09:32] <jam> I think I responded to your requests
[09:33] <jtv> Most of these things most readers won't need or want to care about — the arrogance of assuming that the reader will want to spend their time grokking the author's life work and deep thoughts is just stunning.  Writing "0.01e9" for "integer numer of nanoseconds" is only clear to the author, or someone who went to all that trouble.
[09:34] <jam> fwereade: there is also some confusion as bits of the API code just copy & pasted the state code, which isn't quite what we want. I think there having an interface for NotifyWatcher might make it clearer that API probably wants to share the interface, but not the implementation.
[09:34] <fwereade> jam, yeah, I'm just doing a last pass on the upgrader now
[09:35] <fwereade> jam, and, yeah, if API code is copy-pasting state code someone's doing it wrong
[09:35] <fwereade> jam, which bits in particular?
[09:37] <jam> fwereade: state/api/watcher.go
[09:37] <jam> looks very cut & pasted
[09:37] <jam> with newEntityWatcher et al
[09:39] <fwereade> jam, yeah, I agree that should be using the interface
[09:40] <fwereade> jam, but it's not quite cut and pasted, it's more a translation layer
[09:40] <fwereade> jam, which inevitably bears some resemblance, it is true
[09:41] <jam> fwereade: well, I think it started out as a C&P and then was a bit adapted. However, I think a lot of the internals aren't actually relevant.
[09:41] <jam> fwereade: note that there are no *callers* of newEntityWatcher in API
[09:41] <jam> which is how I know it is a C&P
[09:41] <fwereade> jam, I think it was more not-actually-deleted than C+P
[09:42] <fwereade> jam, however it does rather imply that nobody got around to finishing the tests for stuff like the machiner api
[09:43] <fwereade> jam, which would/should be using that code for the machine watch
[09:43] <fwereade> jam, well, never got round to actually finishing the client side of the api, actually
[09:43] <fwereade> jam, nothing to do with the tests
[09:44] <jam> fwereade: much of the client side is definitely unimplemented :)
[09:44] <jam> or :'( depending on your POV
[09:44] <fwereade> jam, heh
[09:45] <fwereade> jam, so anyway AFAIK in that file entityWatcher is good, lifecycleWatcher is crack (but easily fixable) and environConfigWatcher should never have been implemented
[09:46] <fwereade> jam, (LW drops events -- we could fix it either by coalescing (hard work) or flip-flopping between reads from in and writes to out (easier, probably smarter too))
[09:48] <jam> fwereade: how does it drop changes?
[09:48] <jam> because it switching what "out" to use?
[09:48] <jam> it looks like it is coallescing
[09:48] <jam> or is it that it just ends up with "Latest"
[09:49] <jam> even if it got a set/unset/set ?
[09:49] <fwereade> jam, LW reads from in and overwrites changes
[09:49] <fwereade> jam, if it hasn't already been sent on to out
[09:50] <fwereade> jam, switching outs is great
[09:50] <jam> fwereade: "ids, err = w.merge(ids, ch);"
[09:50] <jam> fwereade: isn't that merging rather than overriding?
[09:50] <fwereade> jam, state/api/watcher.go?
[09:50] <jam> fwereade: ah, state/watcher.go
[09:51] <fwereade> jam, AFAIK state.LifecycleWatcher is ok (although I do need to land those branches)
[09:51] <jamespage> jam, fwereade: hey guys
[09:51] <jam> hi jam
[09:51] <jam> jamespage: ^^ :)
[09:51] <jamespage> lol
[09:51] <fwereade> jamespage, heyhey
[09:51] <jamespage> so  - golang versions
[09:51] <jamespage> right now we have version 1 in 12.04
[09:52] <jamespage> 1.0.2 quantal->raring
[09:52] <jamespage> and 1.1.1 sometime in saucy
[09:52] <jam> jamespage: sure. and we *really* want something >= 1.0.2 in P
[09:52] <jam> but even the patched 1.0.2 isn't great
[09:53] <jamespage> so the version 1 in 12.04 is no good anyway you look at it - why?
[09:53] <fwereade> jam, jamespage: yeah, if we're stuck with 1.0.x we'd really like 1.0.3
[09:53] <Daviey> jam / fwereade: Can you pinpoint exactly why 1 isn't suitable?
[09:54] <davecheney> jamespage: the version in P won't build the gwacl (azure) support package that julian is working on
[09:54]  * davecheney scrobbles for issue
[09:54] <davecheney> https://bugs.launchpad.net/gwacl/+bug/1196811
[09:54] <jam> davecheney: and I think your SSL connection problems are also related to the 1.0.2+backported changes.
[09:55] <jam> jamespage: ISTR that go1 has other problems with HTTP support.
[09:55] <Daviey> Didn't we have a work around for the go-curl issue?
[09:55] <jam> I'm 70% sure that it just won't pass the juju-core test suite for even juju-core 1.10
[09:56] <fwereade> jam, jamespage, davecheney: yeah, in practice we see the tools bucket response hang up if we use 1.0.2, right?
[09:56] <jam> Daviey: IIRC, the original problem is that go SSL support internally doesn't support renegotiating the connection. Which the workaround was to depend on go-curl
[09:56] <jam> which has a different cgo related failure
[09:56] <Daviey> The reason jamespage and myself are exploring this, is that we may have pushback and other complexities bringing back a newer golang.. So we want to be certain it's our best effort.
[09:56] <davecheney> fwereade: jam i think we had this problem as early as Altanta but didn't have the time to investigate properly
[09:57] <jam> Daviey: "pushback on newer golang" even for 1.0.3 ?
[09:57] <Daviey> Well, we might attack that differently TBH
[09:57] <jam> AFAIK, we could live with 1.0.3 because that is what we are ensuring support for. We would like 1.1+ because go authors have themselves stopped support for the 1.0 branch
[09:58] <jam> (so there will never be a go 1.0.4)
[09:58] <fwereade> Daviey, and just to confirm (I guess this is a stupid question) there's no way we can build it for P without tools distributed in P?
[09:58] <davecheney> jam: and there are bugs in 1.0.3
[09:58] <davecheney> loooots of ugs
[09:58] <davecheney> bugs in the http library
[09:58] <Daviey> 1.0.3 might be fit for a point release SRU to precise, but considering it seems that much iternal stuff is changing.. personally (as an SRU member), i am uncomfortable with that based on what i currently know
[09:58] <jam> davecheney: fewer than in go 1.0 :)
[09:58] <Daviey> fwereade: We /can/, but it would piss some people off.
[09:59] <davecheney> Daviey: i can attest to the commitment of the Go authors to backwards compatibilty
[09:59] <jam> Daviey: the SRU idea is that we don' want to break people that are using the existing thing, or introduce regression in what is working for them. I *think* 1.0.3 is a sufficiently-better-than-1.0 for parties that are using golang on P
[09:59] <davecheney> we have a tool which runs as part of every single CI build that valdiates we never depricate or change a symbol that existed at Go 1.0
[09:59] <fwereade> Daviey, more or less than changing the golang version in P? because being able to use the same golang version across the board would be very handy...
[10:00] <Daviey> davecheney: Well, anyone else using Go in 12.04 has had to work their app based on known issues that we are talkign about now.  The thing that worries me is that we change the known broken behaviour, and it regresses their stuff.
[10:00] <fwereade> Daviey, and if we piss people off either way I'd prefer to devote our efforts towards the one that works better for us...
[10:00] <Daviey> unless the workarounds are known to also work with a known good version?
[10:00] <davecheney> Daviey: that is fair
[10:00] <jamespage> fwereade, thats some of the challenge: saucy will get 1.1.1 soon-ish making that immediately inconsistent with earlier releases
[10:00] <davecheney> i do not have reliable stats on the various install paths for Go
[10:00] <davecheney> many many people were using Gustavo's PPA versions
[10:00] <davecheney> they have been quite surprised that they disappeared
[10:01] <Daviey> Which is a good reason PPA's are dangerous to depend upon.  The primary archive we are duty bound to support by promise.
[10:01] <Daviey> Anyway...
[10:01] <davecheney> Daviey: certainly, i am in no way arguing the rightness or wrongness of that approach
[10:02] <davecheney> only offering a data point that main was not the only way people get Go on P
[10:02] <Daviey> If it takes a few hours to have dual toolchain support in Go, that is better time spent than jamespage and myself fighting with the rest of the distro team to force something in.
[10:02] <Daviey> Soo. if we can evaluate feasibility of dual support, it gives us more merrit eithetr way
[10:03] <jam> Daviey: I know you can set GOPATH and compile with more than 1 go binary
[10:03] <jamespage> support for 1.1.x and 1.0.x
[10:03] <jamespage> ?
[10:03] <Daviey> If it's going to be super hard, and lots of time - we have documented reasons why backporting the newer version is Superior
[10:03] <jam> (I've done it from time to time)
[10:03] <jam> I'm not sure how you turn that into builtin support for more than one version.
[10:03] <Daviey> jamespage: Yeah, i am hoping we can build for 1.0 and 1.X concurrently
[10:04] <jamespage> so client tooling works for 12.04 -> current dev release right
[10:04] <Daviey> Oh!
[10:04] <Daviey> then is backporting a newer golang a theoretical problem?
[10:05] <Daviey> solve a  theoretical problem, rather?
[10:05] <jam> jamespage: "client tooling works" ?
[10:05] <jamespage> sorry - that was misleading
[10:06] <jamespage> so that the juju-core package is either building against lastest 1.0.x golang or latest 1.1.x golang
[10:06] <jamespage> in the distro backports pocket which is how we are proposing to distribute this officially for precise
[10:06] <jam> jamespage: today we can build with 1.0.3 and 1.1.1
[10:06] <jamespage> OK - Daviey: I think the right thing is to get the 1.0.x version consistent across 12.04->13.04
[10:07] <jamespage> we are only 1 release away from next LTS at which point most people will start to use 14.04 anyway
[10:09] <Daviey> jamespage: Are you suggesting we pursue an SRU, or the backport track for 1.0.x?
[10:09] <Daviey> To confirm, everyone thinks we do indeed need a newer golang available in 12.04?
[10:09] <jam> Daviey: to build Main package with a tool, doesn't that tool need to be an SRU?
[10:09] <Daviey> jam: it's not main, so that isn't an issue
[10:10] <davecheney> Daviey: yes, precise is essentially the only release that matters for Juju until we reach the next LTS
[10:10] <fwereade> Daviey, yes, we do
[10:10] <Daviey> jam: There is likely going to be some push back on the prospect of backporting a toolchain package.
[10:11] <jam> fwereade: https://codereview.appspot.com/10906043/ updated to make NotifyWatcher an interface{} which is implemented by entityWatcher.
[10:11] <Daviey> fwereade / davecheney: Right.. Would you mind outlining the specific reasons why "1" isn't suitabl.. just so jamespage and I have some things we can use to support this
[10:11] <jam> well, once lbox propose finishes
[10:11] <davecheney> Daviey: 1 ? you mean the current version in P ?
[10:12] <Daviey> Yeah
[10:12] <davecheney> in addition to the problems of http bugs that affects P, Q and R
[10:12] <davecheney> it also contains bugs that prevents our windows azure support from compiling
[10:12] <Daviey> davecheney: Do you have commits to hand that fixe these issues?
[10:13] <davecheney> Daviey: to fix https://bugs.launchpad.net/juju-core/+bug/1196811 ?
[10:13] <Daviey> (or bugs)
[10:13] <davecheney> there is no bug for the http issues with juju 1.11.2
[10:13]  * davecheney creates one
[10:13] <Daviey> yeah
[10:13] <jamespage> Daviey, re SRU or backport - probably SRU
[10:14] <jamespage> and we should probably try to get a MRE for golang at some point in time
[10:14] <Daviey> davecheney: Do you know how this was fixed in golang >=1.0.2?
[10:14] <davecheney> i'm sure it's already been discussed, but there is an open issue where the builders do not use packages from backports
[10:14] <Daviey> davecheney: Yep, that isn't a blocker
[10:14] <davecheney> Daviey: no, i only reproduced the problem this afternoon
[10:15] <davecheney> the 1.11.2 breakage is not reproducable using the upstream go  1.0.2 release
[10:15] <jam> davecheney: btw, have you tried building 1.0.2 from source? One argument I read in the past was that the Ubuntu package of 1.0.2 backports a change that actually broke things.
[10:15] <davecheney> only our version of 1.0.2 shipped in Q and R
[10:15] <davecheney> jam: see just above
[10:15] <jam> davecheney: yeah, you hit enter before me :)
[10:16] <Daviey> jamespage: Before being confident in processing an SRU, it would probably have to be raised with the TB first - "intent to MRE, with a trial SRU first".. and Some decent assurance we won't screw people using the current version.
[10:18] <davecheney> Daviey: https://bugs.launchpad.net/juju-core/+bug/1197326
[10:18] <_mup_> Bug #1197326: environs/ec2: juju 1.11.2 cannot bootstrap when built with go 1.0.2-2 <juju-core:New> <https://launchpad.net/bugs/1197326>
[10:18] <davecheney> I am looking for older bugs, we've had this problem before but didn't pick the the cause before now
[10:22] <jam> fwereade: "no idea how this charm". It is part of JujuConnSuite, *way* too much stuff gets added there. :). Though all that code is going to get overhauled anyway as the client-side API is finished up.
[10:24] <jam> mgz_: are you around yet? https://codereview.appspot.com/10906043/ could use your rubber stamp
[10:26] <fwereade> jam, ha. yes, JujuConnSuite is a monster (and actively dangerous in some ways... it sets up both client-only and server-only state)
[10:27] <jam> fwereade: a lot of that Upgrader code existed because I thought I needed a Unit to test, and to have a unit you need a service and a service needs a charm, etc.
[10:27] <jam> (Upgrader test code)
[10:28] <jam> fwereade: fwiw, I side-tracked for NotifyWatcher, but I'll be on Upgrader-client-API and Upgrader-Worker as the next things in the pipe.
[10:28] <jam> fwereade: as a question there. rog made it so that we start the state worker if we query the api and see a job that requires it.
[10:28] <fwereade> jam, no worries, it's pretty clearly going to be useful imminently, I'm not complaining about it
[10:28] <jam> However, when we start StateWorker, it just starts jobs immediately.
[10:29] <jam> Is it supposed to be looking at the list?
[10:29] <jam> I'm trying to sort out how I switch UpgradeWorker from state to API and whether I'm missing something vs just starting it like it is today
[10:33] <jam> fwereade: also, what needs to be done to land  your 'remove TxnRevno' patch?
[10:33] <jam> fwereade: I need to tweak the Upgrader watcher, and I'd like to depend on your change.
[10:34] <jam> davecheney: what package would you like me to run on go-bot? I don't want to upgrade to 1.1.1 until we know we can get it into P, but we certainly need >go1 (go-bot runs on P)
[10:35] <davecheney> jam: the only thing I can suggest is whatever ships in the series the bot is running
[10:37] <fwereade> jam, sorry, phone
[10:38] <fwereade> jam, I just need to remove certain appendages from certain other parts of myself and maybe get a second LGTM on the prereq -- that will happen today
[10:39] <fwereade> jam, I think you need to remove Upgrader from the stateWorkers list, not start as a state worker, and start it as a api worker -- but I guess you'reasking for somethingmore?
[10:40] <fwereade> jam, I think that the list is just about figuring out when we no longer need a state connection
[10:47] <jam> fwereade: well, roge mentioned something about asking the API for what jobs to run
[10:48] <jam> fwereade: as for 2 LGTMs... when we are 4 people down, it is really hard to get enough reviews to maintain velocity.
[10:48] <fwereade> jam, ah, yes, that does make sense -- we should always start an API connection and get jobs from that
[10:48] <fwereade> jam, and figure out workers from jobs
[10:48] <jam> fwereade: right, it seems to start the API connectio, get a list of jobs, and then does nothing but start a StateWorker.
[10:48] <jam> which hard-codes the workers it runs.
[10:49] <fwereade> jam, but this is just dickery that pushes back starting just one freaking job with an api connection
[10:49] <fwereade> jam, which is all I have cared about for like th last month
[10:49] <fwereade> jam, and which somehow has not happened
[10:50] <fwereade> jam, and which is why we have all these half done workers
[10:50] <jam> jtv: point of clarification: "make([]foo, 0, 10)" creates a slice with len(0) and cap(10). So you don't have 'nil's on the end.
[10:50] <jam> fwereade: acked
[10:51] <fwereade> jam, once we have that tracer bullet landed I thinkit will be much easier to trim away the ther bits
[10:54] <jam> fwereade: btw, bot tells me you were right about the charm not being there. I had copied it from somewhere else, apparently I wasn't running what I thought I was...
[10:54] <fwereade> jam, ha, at least JujuConnSuite's a bit less awful than I feared ;p
[11:05] <jam> fwereade: api client discussion. Should state/api/upgrader/* take objects that are 'state/*' objects, or should they be "state/api/params/*' objects?
[11:05] <jam> I know we have to use state/api/params on the wire to the apiserver
[11:05] <jam> but what should the client interface be?
[11:05] <jam> state/* so that the API code looks like the existing raw state code?
[11:06] <jam> or state/api/params code so it looks closer to what will actually be sent to the APIServer ?
[11:06] <fwereade> jam, params please
[11:06] <jam> fwereade: k
[11:06] <fwereade> jam, before too long, hopefully, the only thing that knows about state will be the api
[11:07] <jam> fwereade: so one thing I was thinking about. Shouldn't state/* be the only things that touch the db, and state/apiserver/* be using the state/* apis?
[11:07] <fwereade> jam, is that not the case today?
[11:07] <fwereade> jam, it's certainly the intent
[11:08] <jam> fwereade: well, it wasn't true as I was implementing Pinger, but I'm not sure about the existing code.
[11:08] <jam> and I'm realizing I was wrong there, so it could have just been me.
[11:08] <jam> Upgrader does
[11:08] <jam> and the Machiner code I've looked at does
[11:09] <fwereade> jam, does touch the DB?
[11:09] <fwereade> jam, or does hide it? :)
[11:09] <jam> fwereade: Upgrader and Machine* seem to use state calls, *not* DB calls
[11:10] <fwereade> jam, good-oh :)
[11:10] <jam> Pinger as I was writing it was copying presence and using DB calls, but I was slowly working that out.
[11:10] <fwereade> jam, ah, got you, cheers
[11:11] <jam> fwereade: also, state/api/upgrader/* presents a single-object interface?
[11:11] <fwereade> jam, but the existing SetAgentAlives should give you Pingers already, right?
[11:11] <jam> rather than the multi-way at state/apiserver/upgrader/* ?
[11:12] <fwereade> jam, I am agnostic there -- if you're rewriting enough of the upgrader worker I'm fine using direct API calls
[11:12] <jam> fwereade: there is no API for SetAgentAlive
[11:12] <fwereade> jam, the bigger the worker the more concerned I am that we maintain the appearance/semantics of the state api
[11:12] <jam> there is pinger_test.go, but it just tests that a disconnect can be noticed, which is true, but not quite reality.
[11:13] <jam> fwereade: I'd like the api/* code to be reasonably consistent. If we want single-object or multi-object there, now is the time to decide
[11:13] <jam> I'd personally like to push multi-object as far down as we can.
[11:13] <jam> But I think api/machine/* is all single-object
[11:13] <fwereade> jam, if you're arguing consistency I think we have to go single
[11:13] <fwereade> jam, because we do not want to rewrite all the workers
[11:13] <fwereade> jam, long-term I would kinda like to move away from that
[11:14] <jtv> jam: ah thanks — I wasn't aware of the third argument, or had forgotten.
[11:14] <fwereade> jam, but the current plan is to wrap them in a thin layer to minimise reimplementation burden of the original workers
[11:14] <jam> jtv: anyway, it is a hint, not a requirement.
[11:15] <jtv> It does make it a lot easier.  Thanks again.
[11:17] <jam> fwereade: machiner.SetStatus() takes an args that is an array
[11:17] <jam> ah stupid, I'm in apiserver
[11:17] <jam> of course it does
[11:20] <fwereade> jam, yeah, the idea is just to fix what we send over the wire so it's a bit more flexible but to maintain the interface
[11:20] <fwereade> jam, on the client side
[11:21] <fwereade> jam, when it's really no more costly to fix the worker I have no qualms about doing so early
[11:21] <fwereade> jam, at least the various facades are split up so we can drop the domain object style code one facade at a time
[11:21] <fwereade> jam, sane?
[11:22] <jam> fwereade: seems ok to me
[11:25] <fwereade> jam, hell, cath popped out and is not back yet, and laura's getting a bit screamy, I might have to skip standup today
[11:26] <jam> k
[11:49] <jam> jtv: you need to import "time" at the top of polling_test.go
[11:49] <jtv> Yes I know, thanks
[11:50] <jam> jtv: sorry if I came across as bugging. I just try to inform people about bot results since they don't seem to poll it themselves.
[11:50] <jtv> No it's fine, really.  I appreciate it.
[11:50] <jtv> It's just that I happened to be already on it.  :)
[11:54] <jtv> jam: if people aren't noticing their landing failures, that may mean they've got too much work in-flight, which in turn might mean that the process needs tweaking.
[11:56] <jtv> For example, if branches take too long to complete when the "real" work is already done, people  will work around the blockage by taking on additional work.
[12:44] <fwereade> jam, I think I'm going to land https://codereview.appspot.com/10798043, would you just cast a quick eye over it on general principles please?
[12:44] <jam> fwereade: Upgrader.Tools currently returns the desired Tools for a given agent. But we don't have an API to get the *actual* current tools for an agent.
[12:45] <fwereade> jam, do we need that in the API?
[12:45] <jam> fwereade: I don't know. I know I expected it as part of testing
[12:45] <fwereade> jam, state has Unit and Machine.AgentTools
[12:46] <fwereade> jam, I don't think it's necessary tbh -- all your testing of what-actually-happened should probably be against independent state instances regardless, right?
[12:47] <jam> fwereade: offhand Upgrader.Tools sounds like something that could just return the desired tools. Vs a Machine.Tools that should return the current running tools.
[12:47] <jam> so we're probably fine.
[12:47] <jam> It was just a moment of surprise
[12:47] <fwereade> jam, cool
[12:49] <jam> fwereade: still LGTM
[12:52] <jam> fwereade: ran into something interesting. It seems you cannot embed types in api/params
[12:52] <jam> if you do, they don't get serialized back properly by rpc.jsoncodec
[12:52] <jam> direct server tests don't notice,because you test the object being returned
[12:52] <jam> but client-side tests notice
[12:52] <jam> the data isn't on the wire
[12:52] <fwereade> jam, aww, wtf
[12:55] <jam> fwereade: http://paste.ubuntu.com/5840230/
[12:55] <jam> Without that change to api/params/params.go I was getting Error == null, but no JSON content for the embedded AgentTools fields.
[13:01] <fwereade> jam, that's really unhelpful :/
[13:02] <fwereade> jam, ah, apparently it's fixed in 1.1
[13:02] <fwereade> jam, although that is of limited value to us :/
[13:02] <jam> fwereade: depends how the conversation goes :)
[13:08] <jam> fwereade, mgz_: If you have the time this is the changes to get client-side Upgrader up and running: https://codereview.appspot.com/10711044/
[13:08] <mgz_> looking
[13:09] <fwereade> jam, cool, just a mo
[13:10] <jam> mgz: fwereade: I'm off for today, but I'd love to get feedback before I start work tomorrow.
[13:10] <fwereade> jam, np
[13:11] <jam> I might even stop by tonight.
[15:27] <arosales> Is it correct to state the only valid option to add-unit in juju-core  is "-n"
[15:28] <arosales> "add-unit -c" or "add-unit --count"  to look to be supported
[15:32] <fwereade> arosales, -n/--num-units are all we implemented it seems -- if we should have --count as well, would you open a bug please?
[15:33]  * fwereade needs to head out a bit early today, will see you all later
[15:33] <arosales> fwereade, thanks for the info and will do re: --count
[15:49] <mgz> if its just an alias, do we actually want that versus just a deprecation in python/unsupported notice in juju-core?
[15:49] <mgz> potentially there are scripts that use it, but we need some paths for updating the commandline interface
[16:04] <jam> mgz: did you get a chance to look at upgrader-api-client?
[16:04] <mgz> jam, yeah, commenting now
[16:04] <jam> thx
[16:07] <mgz> jam: lgtmed
[20:55] <thumper> morning folks
[21:29] <thumper> small victory
[22:08]  * thumper chucks some stuff away
[22:08] <thumper> harder to get it merged than I care about
[22:08] <thumper> not worth the effort right now
[23:21]  * thumper feels like he is missing a step somewhere
[23:43]  * thumper is unblocked
[23:44] <thumper> I hate, *hate* having to guess why something works...
[23:44]  * thumper adds some doc


[12:09] <Burgwork> then approach canonical with said plan
[12:09] <Burgwork> figure out who is going to keep it, etc.
[12:09] <Riddell> I'm sure I've seen jono talking about getting event boxes available
[12:12] <Burgwork> Riddell: right, but having a plan is stilla  good idea
[12:15] <Riddell> Burgwork: by the way, isn't the fridge story you posted a bit unprofessional?  it looks a lot like ubuntu et al are slagging off kubuntu
[12:16] <Burgwork> Riddell: nah, nixternal and I wrote it up
[12:16] <Burgwork> after nixternal only did a Kubuntu story
[12:17] <Riddell> it's not as bad as the guadec web page having a comment that does slag off KDE admittadly :)
[12:17] <Burgwork> well, the akademy page from 2006 said "the free desktop"
[12:17] <Burgwork> which I remember pointing out to you
[12:18] <Riddell> mm hmm
[12:18] <Riddell> and what does it say at the top of http://www.gnome.org/ ?
[12:19] <Burgwork> right, that is because gnome.org is being revamped
[12:19] <Burgwork> there wsa a time when gnome and kde didn't admit their existance
[12:20] <Riddell> which doesn't mean guadec should allow comments on their web pages that just slag off kde
[12:24] <Burgwork> which page is it?
[12:26] <Riddell> http://www.guadec.org/GUADEC2007/
[12:26] <Burgwork> right, that comment is from a user
[12:26] <Burgwork> I suspect that those comments are not moderated
[12:27] <jenda> I'd like to make it a Canonical-independent community effort.
[12:28] <jenda> I don't insist however ;)
[12:28] <Riddell> Burgwork: they are, that page had spam on it a while ago and someone deleted that
[12:28] <Burgwork> jenda: the shipping costs on that thing are going to be huge
[12:28] <Burgwork> Riddell: hmm, I will pass the comment along
[12:28] <jenda> Burgwork: true
[12:29] <jenda> Burgwork: but they'll be a _fraction_ of the price, and I think the receiving team could try and foot that particular expense.
[12:30] <Riddell> Burgwork: thanks
[12:30] <Burgwork> no worries
[12:31] <Burgwork> the fridge post was a joke and nixternal and I chatted about it a bunch
[01:39] <jenda> okeydoke
[01:40] <jenda> I've got the draft of what i'd like said in our session...
[01:40] <jenda> I'll be sending it out by email.
[01:54] <jenda> sent
[01:54] <jenda> please give feedback :)
[08:40] <jenda> poningru: ping
[08:40] <jenda> why do people have to be asleep when I need them ;)
[08:40] <jenda> poningru: Could you take the reins of the MT session in the Ubuntu Open Week once I'm gone?
[08:41] <jenda> poningru: use the email I sent (and any corrections that may appear between now and then) for reference, voice and devoice speakers as needed.
[08:42] <jenda> poningru: anyone who the mail was sent to should be voiced when they ask to, and if I left someone out - decide authoritatively :)
[08:43] <jenda> poningru: one more thing - and if it falls apart and silent, it'll be your fault ;)
[08:43] <jenda> (besides it being my fault for not being there in the first place)
[08:48] <Tm_T> =)
[08:54] <mdke> jenda: I seem to have killed that thread about french add-ons to the UWN, no replies :(
[08:56] <poningru> jenda: hmm?
[08:56] <poningru> oh ok
[08:57] <poningru> damn I guess I will start planning after tomorrow morn's exam
[09:03] <jenda> poningru: hehe, I've got one too
[09:03] <jenda> mdke: hmm
[09:04] <jenda> mdke: might be, but I agree with what you wrote there.
[09:04] <mdke> oh
[09:04] <jenda> mdke: consider the silence an acquiescence ;)
[09:04] <jenda> now its up to the UWN team to decide what they want to do with that issue.
[09:04] <jenda> Burgwork, beuno?
[09:05] <jenda> (somerville?)
[09:05] <jenda> others? :)
[09:05] <poningru> ok I have to go to sleep
[09:05] <poningru> I will work on this stuff tomorrow
[09:05] <jenda> poningru: nighty night
[09:05] <poningru> and email it out
[09:05] <jenda> coolio
[09:05] <poningru> nn
[09:05] <jenda> I'll get back to it at 14:00 UTC - 4 hours before the showdown, methinks
[09:05] <jenda> good night
[09:06] <poningru> wait.. isnt this on wednesday?
[09:06] <poningru> oh by tomorrow I meant tuesday
[09:06] <poningru> since its still 0305 tuesday morn here
[09:06] <poningru> so yeah test in like 6 hours
[09:07] <poningru> I'll work on this stuff tomorrow as in after that exam
[09:07] <poningru> nn
[09:07] <jenda> hehe
[09:07] <jenda> ok
[09:07] <jenda> nn :)
[09:07] <jenda> I might be available for the next 12 hours or so
[09:07] <jenda> (12-15)
[09:08] <jenda> but will try not to be.
[10:38] <juliux> jenda, hi, today an other book arrived here
[10:39] <jenda> great! :)
[10:39] <jenda> what condition?
[11:00] <juliux> jenda, not new not bad
[11:03] <jenda> ok, that's good enough ;)
[11:03] <jenda> truth be told, if it were individual pages in a plastic bag, it would have to do ;)
[11:04] <jenda> (individual _torn_ pages and not even all of them ;))
[11:04] <jenda> BTW, is it a bad thing that I noticed thta the weather applet is showing it's raining before I noticed the actual rain out the window?
[12:40] <jenda> yay, two more shirt orders.
[02:24] <Tm_T> jenda: :)
[02:25] <Tm_T> jenda: what shirts you did provide?
[02:29] <MenZa> Tm_T: juliux provides shirts, not jenda ;)
[02:29] <Tm_T> aah
[02:29] <MenZa> He's got polo shirts, regular t-shirts and business shirts
[02:30] <MenZa> All with Ubuntu logo embroids
[02:30] <MenZa> T-shirts are 10 euros, polos are 15 and business shirts 20 euros each.
[02:30] <Tm_T> yup, have to remember poke him, we will need business shirts at some point this summer (and ofcourse later)
[02:30] <MenZa> :D
[02:30] <Tm_T> MenZa: thanks
[02:34] <MenZa> np :)
[02:35] <MenZa> He's juliux AT ubuntu DASH de DOT org
[03:00] <jenda> Tm_T: correct ;)
[03:00] <jenda> Tm_T: I'm the sticker and poster guy, for now.
[03:00] <jenda> I might work on 'roughcut' shirts later on...
[03:06] <Tm_T> I haven't found single mention of Ubuntu yet :(
[03:06] <jenda> Tm_T: you aren't allowed to say that!
[03:06] <Tm_T> jenda: I didn't say, just thinking out loud ;)
[03:07] <Tm_T> maybe I can dub "Ubuntu" in someway ;--P
[03:08] <jenda> To be honest, you aren't even allowed to think that ;)
[03:09] <Tm_T> damned!
[03:09] <Tm_T> stop reading my mind!
[03:12] <jenda> :)
[03:17] <Vorian> :)
[03:26] <jenda> hello meatballhat :)
[03:26] <jenda> I've noticed there's been some work on the wiki ;)
[03:26] <meatballhat> jenda: halllllooooo :)
[03:27] <meatballhat> still workin' too ... for a few minutes
[03:27] <jenda> might be because it's law that I study...
[03:27] <jenda> anyway, I better get back to it.
[03:27] <Vorian> jenda
[03:28] <Vorian> hey
[03:28] <Vorian> jenda
[03:28] <jenda> _
[03:28] <jenda> '_'
[03:28] <Vorian> ^.^
[03:28] <jenda> _`
[03:28] <Vorian> *_*
[03:29] <jenda> _
[03:29] <jenda> Macrons ftw ;)
[03:29] <elkbuntu> o.O
[03:30] <Vorian> jenda
[03:30] <Vorian> relax
[03:30] <Vorian> take some time off
[03:31] <Vorian> lol
[03:36] <jenda> Vorian, why are there no people responding in the UWN section on the forums?
[03:36] <Vorian> I don't know....
[03:36] <Vorian> hmmm
[03:37] <Vorian> maybe it's signature time jenda
[03:37] <jenda> hmm?
[03:39] <Vorian> UWN forum link in your (our) signature's on the forum
[03:42] <Vorian> jenda, if it makes you feel better, I just replied :)
[03:58] <meatballhat> jenda: taken a peep at the DIY Design Spec yet?
[04:10] <jenda> meatballhat: nope
[04:10] <jenda> meatballhat: mind if I don't till tomorrow? :)
[04:12] <jenda> bah, I looked ;)
[04:12] <meatballhat> heeheehee
[04:12] <meatballhat> it ain't done yet, but Troy's sure whipping me into shape  ;-)
[04:13] <jenda> "Mark is a gazillionaire with too much on his plate."
[04:13] <jenda> Whahahaaahaa
[04:13] <jenda> :D
[04:14] <jenda> meatballhat: how did you know he had a 7-yo niece?
[04:18] <jenda> meatballhat: it's a foreign language to me, but I trust you know what you're doing :)
[04:20] <meatballhat> heeheehee ...  I'm just slappy  ;-)
[05:37] <jenda> juliux: got 8 shirt orders to date :)
[05:37] <juliux> jenda, cool
[05:37] <jenda> I'll try to make them pay in advance - if they do, I'll be able to pay you in advance too.
[05:37] <juliux> great
[05:40] <MenZa> :D
[05:40] <MenZa> How many am I on, juliux?
[05:40] <MenZa> 6?
[05:41] <juliux> MenZa, dk == 6, de==10
[05:41] <juliux> MenZa, oh now dk == 9
[05:42] <MenZa> :D
[05:42] <MenZa> awesome
[05:42] <MenZa> cz?
[05:43] <juliux> i didn't get an mail from cz and nl ;)
[05:43] <MenZa> haha
[05:43] <MenZa> jenda: :D
[05:43] <juliux> they colleting it first and then they send me an e-mail
[05:43] <MenZa> that's fine
[05:43] <juliux> so it is for me easier then for the dk team;)
[05:43] <MenZa> heh
[06:10] <jenda> MenZa: I'll be picking them up in a bunch, so no reason to bombard jules with individual requests.
[06:11] <juliux> jenda, +1
[06:11] <jenda> And besides... you're giving the poor guy a hard time. We win.
[06:11] <jenda> :)
[06:11] <juliux> i think we need a real race ;)
[06:12] <jenda> hehe
[06:12] <jenda> juliux: can I pay in beers? :)
[06:12] <juliux> jenda, no, i don't like cz beer
[06:12] <jenda> damn you :)
[06:12] <jenda> not even the Pilsner?
[06:12] <juliux> no
[06:13] <jenda> :)
[06:13] <juliux> i am coming from northern germany, we drin jever, becks, holsten and flensburger
[06:13] <juliux> s/drink/drin
[06:41] <boredandblogging> beuno, you there?
[06:42] <beuno> boredandblogging: hey
[06:46] <beuno> jenda: just replied to your email
[06:46] <beuno> I'm off to lunch
[06:46] <beuno> but I'll hang around here all day
[06:46] <jenda> coolio, thx
[06:46] <jenda> I'll try to be gone for what's left of the day ;)
[06:46] <jenda> but you know me.
[06:46] <beuno> hahah
[06:47] <beuno> ok, well, email works too
[07:03] <jenda> beuno: you mean the first one you sent?
[07:03] <jenda> I didn't get another.
[07:09] <jenda> got it.
[07:09] <jenda> Nope, no wiki, sorry.
[08:54] <Tm_T> juliux: ping
[08:54] <juliux> Tm_T, pong
[08:55] <Tm_T> juliux: any pics of business shirt?
[08:55] <juliux> Tm_T, not yet
[08:56] <Tm_T> juliux: ok, one of our local marketing team fellows asked, we prolly like to get ~5 of them at some point
[08:56] <juliux> Tm_T, as you can read on my forums post i need the orders befor the 1 may
[08:56] <juliux> Tm_T, we will only order t-shirts and poloshirt for stock
[08:57] <Tm_T> juliux: auts, forum post in where? I haven't used forums much really
[08:58] <juliux> Tm_T, what is your e-mail adress? i can send you an e-mail which summaries everything
[08:58] <Tm_T> juliux<EMAIL_ADDRESS>[08:59] <juliux> Tm_T, you have mail
[09:00] <MenZa> /win 14
[09:01] <Tm_T> juliux: thanks
[09:02] <MenZa> ;/