[17:03] <SpamapS> ahhh, the hum of UDS
[17:03] <SpamapS> o/
[17:05] <SpamapS> pong
[17:05] <SpamapS> .org backslash foo
[17:05] <smoser> hello, mr SpamapS
[17:07] <achuni> aha
[17:09] <SpamapS> what is your launchpad username? You need to be in ~ubuntu-etherpad
[17:10] <geofft> is there a link to a good technical description of juju for those of us who haven't been paying attention?
[17:10] <geofft> I'm afraid "DevOps distilled" just confuses me more
[17:10] <SpamapS> I believe archive refresh frequency was increased during the P cycle
[17:12] <SpamapS> The Packages file could be versioned, and the Release file would only point to one version that is already known to exist
[17:13] <SpamapS> Release file contains hashes for Packages.gz , Packages.gz and Release are not updated at the exact same time.
[17:16] <med_> geofft, https://juju.ubuntu.com/   Juju provides service orchestration.
[17:16] <med_> geofft, you could possibly ask for more tech info in #juju-dev
[17:16] <med_> https://juju.ubuntu.com/Documentation
[17:17] <med_> https://juju.ubuntu.com/docs/faq.html
[17:18] <geofft> med_: the Documentation page is helping a bit, thanks.
[17:19] <SpamapS> $ wc -l /var/lib/apt/lists/mirrors.kernel.org_ubuntu_dists_precise_Release
[17:19] <med_> geofft, also, feel free to ask those type of questions on #ubuntu-server. I probably should have referenced it first.
[17:19] <SpamapS> 492 /var/lib/apt/lists/mirrors.kernel.org_ubuntu_dists_precise_Release
[17:22] <SpamapS> This problem presents itself in web development as well. Think of the network of Ubuntu mirrors as a CDN .. when yahoo wants to update an image, they do so by appending a query string to the URL which forces CDN caches to re-fetch it from origin...
[17:25] <SpamapS> the format on the archive may not need to change
[17:25] <SpamapS> o/
[17:25] <SpamapS> NO
[17:25] <SpamapS>  077178d834ac0195a9141ed0aa8568f684776dc57d33edf3e6b38c9a2543f256          1677114 main/binary-amd64/Packages.gz
[17:26] <SpamapS> can become $MIRROR/main/binary-amd64/Packages.gz?hash=077178d834ac0195a9141ed0aa8568f684776dc57d33edf3e6b38c9a2543f256
[17:26] <SpamapS> o/
[17:26] <SpamapS> o/
[17:26] <SpamapS> o/
[17:26] <SpamapS> o/
[17:26] <SpamapS> ^^
[17:26] <SpamapS> ^^
[17:26] <smoser> reading now dummy
[17:26] <smoser> :)
[17:26]  * SpamapS takes a deep breath
[17:27] <SpamapS> Sorry I had a local interruption when you guys responded
[17:27] <SpamapS> ?
[17:27] <rbasak> So we would add a new by-hash/07717...256 symlink which points to the correct versioned Packages.gz file. That's all.
[17:27] <SpamapS> why do we need a new file?
[17:28] <SpamapS> It does mean you may still get a fail, but you just need to fetch again.
[17:29] <SpamapS> its not dynamic respondse
[17:29] <SpamapS> its just avoiding caching the wrong file
[17:32] <SpamapS> yes its a much tinier window though
[17:34] <smoser> SpamapS, on a very dumb object store it is different.
[17:35] <SpamapS> smoser: I'm only avoiding problms in the intermediate caches. Are you saying S3 would interpret the query string to mean something?
[17:35] <smoser> as its a different path. you're suggesting that the web service will know to cut off ?.*. but thats an assumption (i'm not sure if it is true with s3 or not)
[17:36] <SpamapS> smoser: understood, they may just make that a static lookup and not chop it off.
[17:37] <smoser> s3 does seem to chop ?.* off
[17:38] <SpamapS> rbasak: I made that assertion incorrectly btw, pdiff doesn't solve the problem :-/
[17:43] <SpamapS> are there issues w/ symlinks in S3?
[17:44] <tumbleweed> presumably copies aren't a problem
[17:44] <smoser> there are no symlinks in s3.
[17:44] <smoser> you just have to load additional files.
[17:44] <tumbleweed> we're only talking about symlinks for Packages  files...
[17:44] <SpamapS> right ok so its just a second stored copy
[17:44] <smoser> right.
[17:48] <SpamapS> 6 minutes. Actions?
[17:51] <SpamapS> I'd suggest moving those Actions to the top of the etherpad, hard to find in there
[17:51]  * SpamapS goes afk
[18:04] <xnox> [TOPIC] Plans for Python 3.3 (and 3.4) availability
[18:04] <xnox> Plans for Python 3.3 (and 3.4) availability
[18:04] <xnox> http://summit.ubuntu.com/uds-q/meeting/20416/foundations-q-python33/
[18:22] <xnox> anyone knows where is the link to Barry's way of building python2 & python3 packages from the same debian source package?
[18:23] <jtaylor> http://wiki.debian.org/Python/LibraryStyleGuide probably
[18:25] <xnox> jtaylor: thanks a lot
[18:50] <udsbotu> uds-grand-ballroom-c: 5 minutes left in this session!
[18:51] <udsbotu> uds-grand-ballroom-c: 4 minutes left in this session!
[18:51] <xnox> udsbotu: stop spamming us ;-)
[18:51] <udsbotu> xnox: I am only a bot, please don't think I'm intelligent :)
[18:52] <udsbotu> uds-grand-ballroom-c: 3 minutes left in this session!
[18:53] <udsbotu> uds-grand-ballroom-c: 2 minutes left in this session!
[18:54] <udsbotu> uds-grand-ballroom-c: 1 minute left in this session!
[18:55] <udsbotu> uds-grand-ballroom-c: This session has ended.
[19:01] <brendand> hi!
[19:01] <timchen119> o/
[19:02] <josephliu> o/
[19:10] <brendand> o/
[19:11] <brendand> it's worth pointing out that we do test the *reader*, just not with the specific mmc format
[19:13] <brendand> how often do we see *only* mmc cards not working?
[19:26] <brendand> also, does it achieve 3.0 speeds
[19:26] <brendand> ?
[19:41] <brendand> you don't need to drop them to test that
[19:43] <roadmr_uds> brendand: the synthesizing event is a good proposal :)
[19:54] <udsbotu> uds-gb-c: 5 minutes left in this session!
[19:55] <udsbotu> uds-gb-c: 4 minutes left in this session!
[19:56] <udsbotu> uds-gb-c: 3 minutes left in this session!
[19:57] <udsbotu> uds-gb-c: 2 minutes left in this session!
[19:58] <udsbotu> uds-gb-c: 1 minute left in this session!
[19:59] <udsbotu> uds-gb-c: This session has ended.
[22:03] <zyga> hello
[22:03] <ppetraki> hi
[22:03] <spineau> hello !
[22:06] <SpamapS> o/
[22:18] <zyga> hey cr3!
[22:20] <ppetraki> o/
[22:21] <roadmr_uds> zyga, ppetraki : got questions or comments?
[22:21] <ppetraki> roadmr_uds, ny, thanks
[22:22] <roadmr_uds> do let me know if there are questions or comments so I can alert people here
[22:22] <zyga> I'm interested to hear more about what's described, are there any slides too?
[22:23] <roadmr_uds> zyga: yes, cgregan has slides
[22:23] <zyga> I have one general comment but that's something that can happen after the session: I strongly believe that checkbox and lava should be one project, one strong libaray of tools that don't need to duplicate internals, but that's not the topic of this session
[22:23] <zyga> s/libary/library/
[22:23] <ppetraki> I'm still on the fence as to how much either project offers in addition to autotest
[22:23] <roadmr_uds> zyga: exactly :) we'll mention that in a moment
[22:25] <roadmr_uds> zyga, ppetraki : for the moment you can look at this, it's the basics of the architecture (though cgregan's slides are nicer)
[22:25] <roadmr_uds> http://people.canonical.com/~cr3/checkbox-core/submit.html
[22:25] <ppetraki> as an integrator, you'll want to be able to leverage existing "batteries included" frameworks like autotest and  LTP, and then focus on my custom product.
[22:32] <zyga> cr3: lava has the same problem
[22:34] <roadmr_uds> zyga: grown too complex and people don't find it easy to contribute?
[22:34] <zyga> roadmr_uds, no, actually, started too specific and hard for non-linaro to consume
[22:34] <zyga> roadmr_uds, it's getting community (yay) slowly
[22:35] <zyga> roadmr_uds, but I always felt that we should put equal effort on random developers using it and being interested and special custom cases needed for linaro
[22:35] <zyga> even if that costs us tons of time (like 50%)
[22:36] <zyga> and non arm support (as we currently just start to get x86 support via community contributions)
[22:36] <zyga> roadmr_uds, we started a process to simplify a few things in lava for both users and potential contributors alike
[22:36] <ppetraki> I wish QA folks would blog their tricky feats more, its a bit of an art to harness something and not create massive amounts of new code, that's just as complicated as the software you're trying to test.
[22:37] <zyga> yeah, blogging is usef, but then again, when you have a really cool and useful product others do that for you
[22:37] <zyga> we're just not there yet
[22:37] <zyga> it's not like I need to read blog posts about github to know it's useful or how to use it
[22:42] <zyga> to the speaker: lava had similar concerns
[22:42] <zyga> for test developers
[22:42] <zyga> and integrators
[22:42] <zyga> that were running tests on their machine
[22:42] <zyga> and did not want to hang the kernel on purpose
[22:42] <zyga> like powe management tests
[22:43] <zyga> so we were considering adding a flag that would mark a test as unsafe
[22:43] <zyga> (in the test meta data)
[22:43] <ppetraki> fwts has a sane test case organization
[22:43] <zyga> so running on my workstation, I would not easily just run certain tests while exploring
[22:43] <zyga> what is fwts?
[22:43] <ppetraki> ACPI focused test suite
[22:44] <zyga> (lava considers tests a free market, there is no taxonomy there, test is just a brand, you install it by name and then you can run it)
[22:44] <spineau> https://wiki.ubuntu.com/Kernel/Reference/fwts
[22:45] <ppetraki> might be a nice use case for cb-core to harness fwts
[22:46] <roadmr_uds> ppetraki: checkbox already uses fwts for some tests
[22:48]  * zyga is here ;-)
[22:50] <zyga> (the dispatcher is now slowly being integrated in the lava-core)
[22:50] <zyga> but essentially yes, it's one thing that sits next to your devices
[22:50] <zyga> maas is interesting, I feel that lava could benefit form that as we essentially need to do maas for arm dev boards today
[22:51] <zyga> (sadly arm dev kits are not server grade hardware that was designed for this)
[22:54] <zyga> cr3: do you have anything that looks at the overall tests plan before it even allocates the hardware, to check if it makes sense?
[22:55] <udsbotu> uds-gb-c: 5 minutes left in this session!
[22:55] <zyga> especially if you have many-machine tests (I'm not sure as I got confused by the discussion)
[22:56] <udsbotu> uds-gb-c: 4 minutes left in this session!
[22:57] <udsbotu> uds-gb-c: 3 minutes left in this session!
[22:58] <spineau> Fork-exec cr3
[22:58] <udsbotu> uds-gb-c: 1 minute left in this session!
[22:58] <zyga> cr3: do you have a time to chat today?
[22:59] <udsbotu> uds-gb-c: This session has ended.
[23:00] <ppetraki> thanks guys
[23:01] <roadmr_uds> zyga: I'll tell him so he can try to find you (cr3, that is) heh
[23:01] <roadmr_uds> bye folks!
[23:01] <zyga> roadmr_uds, thanks
[23:01] <spineau> bye
[23:01] <zyga> I can hear you :
[23:02] <zyga> it's not late, I just changed the timezone and I pretend it's early
[23:02] <zyga> :)
[23:02] <zyga> ok
[23:02] <zyga> sure, I just want a quick chat
[23:02] <zyga> but it can be anytime
[23:02] <zyga> just prefer early in the week
[23:02] <zyga> as it can spawn more discussion later
[23:07] <zyga> 6 7 8 9 10...
[23:54] <udsbotu> uds-gb-c: 5 minutes left in this session!
[23:55] <udsbotu> uds-gb-c: 4 minutes left in this session!
[23:56] <udsbotu> uds-gb-c: 3 minutes left in this session!
[23:57] <udsbotu> uds-gb-c: 2 minutes left in this session!
[23:58] <udsbotu> uds-gb-c: 1 minute left in this session!
[23:59] <udsbotu> uds-gb-c: This session has ended.