[13:40] <coolbhavi> hey dpm
[13:40] <coolbhavi> postman pushed :)
[13:40] <dpm> hey coolbhavi, thanks a lot that, I saw it :)
[13:41] <coolbhavi> :) no mention
[13:41] <dpm> coolbhavi, I haven't looked at the build yet, so you might have already done it. Would it be possible to push it to 12.10 too?
[13:43] <coolbhavi> dpm, yes ll place a request for forward copy on lp
[13:43] <dpm> coolbhavi, excellent, thanks :)
[13:46] <coolbhavi> dpm, requested. I hope it works
[13:48] <dpm> cool
[13:48] <coolbhavi> dpm, its copied now and waiting to be published on ppa
[13:49] <coolbhavi> but the problem is it got built with the same version number
[13:50] <coolbhavi> will have to see how extras work
[13:50] <coolbhavi> now
[13:50] <dpm> is this a problem? (sorry if it's an obvious question, I'm not an expert in Debian versioning)
[13:52] <coolbhavi> dpm, same version numbers different pockets might not be a problem as its targeting two different releases (as in case of a sync as an example where we copy the same  sources in debian release pocket to ubuntu release pocket)
[13:53] <dpm> ah, so it's probably not going to be a problem?
[13:53] <coolbhavi> mostly yes. but let me figure out how extras repos handle it
[13:58] <coolbhavi> its published from lp ppa now and cron does take some time to run and sync it across. will update you :-)
[14:16] <coolbhavi> hey cwayne :-)
[14:16] <cwayne> heya coolbhavi, hows it goin :)
[14:17] <coolbhavi> cwayne, its fine :-) how about you?
[14:17] <coolbhavi> maybe ajmitch is just waiting on an icon change
[14:17] <coolbhavi> to give a +1 :-)
[14:18] <cwayne> coolbhavi: im fine thanks :)
[14:18] <cwayne> coolbhavi: it's been changed :)
[14:18] <coolbhavi> cwayne, oh cool! link please...
[14:19] <cwayne> coolbhavi: heres the updated myapps stuff: https://myapps.developer.ubuntu.com/dev/apps/1690/
[14:19] <cwayne> and the codes been updated here:  lp:~cwayne18/ubuntu-app-reviews/unity-lens-github
[14:19] <coolbhavi> cwayne, thanks! I'll have a look and update it on the list
[14:20] <cwayne> coolbhavi: thanks!
[14:21] <coolbhavi> cwayne, no mention.. I'll have a look and update in a while
[14:22] <coolbhavi> dpm, firstly sorry for that because it happened due to me. Instead of targeting postman to quantal I left it as precise
[14:23]  * coolbhavi head-bangs
[14:30] <dpm> coolbhavi, hey, no need to apologize, thanks for getting it published in the first place!
[14:32] <coolbhavi> dpm, it was sort of routinised last cycle to target to precise while uploading apps. Will make a note to change it this cycle :)
[14:33] <dpm> coolbhavi, cool. Let me know how the quantal build works. Once Postman is in Quantal, I'll put the banner up
[14:34] <coolbhavi> dpm, quantal is built fine now in PPA
[14:34] <coolbhavi> sorry
[14:34] <coolbhavi> postman
[14:34] <coolbhavi> :)
[14:34] <coolbhavi> ll do some testing now
[14:37] <coolbhavi> ah it just directly copies the binaries in LP
[14:41] <coolbhavi> dpm, well it works fine from PPA but I am curious how extras handles it
[14:42] <dpm> coolbhavi, what do you mean by how extras handles it?
[14:43] <coolbhavi> dpm, the forward copy to quantal since the binaries have been copied exactly with the same version number
[14:44] <dpm> coolbhavi, in which way is then extras different from the main archive? Do you think different releases need different version numbers?
[14:48] <coolbhavi> dpm, nopes m just curious that when the sync happens it gets updated here: http://extras.ubuntu.com/ubuntu/dists/quantal/main/
[14:52]  * coolbhavi hopes that dpm inst confused now
[14:56] <coolbhavi> dpm, I'm sorry if I dwelled in too much on versioning :)
[14:57] <dpm> no worries, I like learning new things :)
[14:57] <dpm> IIRC the sync from the PPA to extras is hourly, right?
[14:58] <coolbhavi> yes
[15:08] <coolbhavi> cwayne, the new icon is simple and nice :)
[15:08] <cwayne> coolbhavi: thanks :)  im thinking ill keep that theme for my icons from now on
[15:09] <coolbhavi> cwayne, seems great for a lens :)
[15:09] <coolbhavi> brb dinner
[16:17] <coolbhavi> cwayne, it looks perfect now :)
[16:18] <cwayne> coolbhavi: thanks :)  i kept the result items as that icon, which is ok becuase they are links to that those peoples github repos :)
[16:18] <cwayne> coolbhavi: do i still need to wait for another +1?  i know theres been a change in voting
[16:19] <coolbhavi> cwayne, yes thats fine. I'll just ping andrew on list and wait for a while as he was interested in icon change
[16:20] <cwayne> coolbhavi: great, thanks!  is there any way to mark it to release to both precise and quantal?
[16:22] <coolbhavi> cwayne, If I get a chance to upload ll target to quantal since its the current stable release and backward copy to precise
[16:22] <cwayne> coolbhavi: great, thanks!
[16:26] <coolbhavi> dpm, yep postman has been synced to quantal release in extras :-)
[16:26] <coolbhavi> So please upload the banner lets see :-)
[16:28] <dpm> coolbhavi, excellent, thanks!
[16:29] <coolbhavi> dpm, download the gz from here and look at <fdopen> file: http://extras.ubuntu.com/ubuntu/dists/quantal/main/binary-i386/Packages.gz
[16:29] <coolbhavi> you ll see postman as installed there
[16:29] <coolbhavi> :-)
[16:30]  * cwayne still thinks we need a lens section of usc
[16:32] <coolbhavi> dpm, cwayne good night!
[16:32] <cwayne> you too coolbhavi
[16:33] <coolbhavi> ciao take care!


[01:49] <andschwa> I need some help. I'm looking for the global configurations so I can change SNAP_DATA and SNAP_COMMON for all my snaps (so I can install them to a separate drive).
[01:49] <andschwa> But my god, I've searched and searched. There's docs on what the environment variables are, but not how to set them for snapd.
[01:50] <andschwa> Should I really perhaps be looking at mounting my drive to /var/snap?
[01:56] <andschwa> This seems like a super straightforward thing to do.
[01:56] <andschwa> And I cannot find it.
[01:59] <andschwa> Is anyone here, or is everyone on "Rocket"?
[02:05] <andschwa> Is what I want to do against snappy's design or something?
[02:05] <andschwa> It doesn't seem like it, since it's all centered around environment variables set at runtime by snapd for a snap.
[02:05] <andschwa> So it seems almost explicitly setup such that you can change what snapd sets those variables to.
[02:06] <andschwa> Yet I cannot find it.
[04:25] <mup> PR # closed: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
[04:25] <mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3810, snapd#3812
[04:26] <mup> PR # opened: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
[04:26] <mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3810, snapd#3812
[06:24] <abeato> ogra_, do you know which is the current status of https://forum.snapcraft.io/t/updating-bootloader-assets-in-the-gadget-snap ?
[07:39] <mup> PR snapd#3759 closed: add spread test for wayland <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3759>
[07:41] <zyga-suse> good morning
[07:41] <zyga-suse> sorry for being late, I was the last one at breakfast, along with my sleepwalking daugther
[07:44] <zyga-suse> mvo: how are you doing today?
[07:45] <mvo> zyga-suse: hey, good morning. doing fine, how are you?
[07:45] <zyga-suse> pstolowski: hey, I think there's something you want to look into
[07:45] <zyga-suse> mvo: perhaps ^ before release
[07:45] <zyga-suse> mvo: downgrading from master to stable fails if you have any changes in flight that involves hooks
[07:46] <zyga-suse> because of the new hooks that don't have handlers
[07:47] <mvo>  zyga-suse hm, interessting. what does the error look like? can you pastebin the session?
[07:47] <pstolowski> zyga-suse, hey
[07:48] <zyga-suse> mvo: I _may_ I ran into it over weekend
[07:48]  * zyga-suse scrolls back
[07:48] <mvo> zyga-suse: thank you
[07:48] <zyga-suse> mvo: essentially this looks like the "CE cannot rollback" problem we had
[07:49] <mvo> zyga-suse: I'm mostly curious about the exact effect, if we really cannot rollback that is a problem
[07:49] <zyga-suse> mvo: aha, maybe that wording was too strong, I think the given change will fail but rollback as a whole will work (still just guessing)
[07:50] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[07:50] <mup> PR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
[07:51] <mvo> zyga-suse: yeah, if that is the case its bad but not a blocker for the release. still something we want to fix
[07:51] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[07:51] <mup> PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
[07:51] <pstolowski> zyga-suse, what do I do exactly to reproduce?
[07:51] <mvo> zyga-suse, pstolowski: please keep me updated :)
[07:51] <zyga-suse> pstolowski: wait, let me find it
[07:52] <zyga-suse> mvo: one more thing, I merged that PR with apparmor probing code
[07:52] <zyga-suse> mvo: I re-designed it after your comment
[07:52] <zyga-suse> mvo: please have a look if you like that
[07:55] <mvo> zyga-suse: you merged it and then re-designed it?
[07:55] <zyga-suse> mvo: no, I read your comment, re-designed and merged
[07:56] <mvo> zyga-suse: ok, I have a look. but I would prefer to look before it gets merged (two +1 and all that)
[07:57] <zyga-suse> mvo: it's very similar to your suggestion and I had +1 from jamie so I merged it but I'll wait for re-affirmation next time
[07:57]  * zyga-suse still looks for that hook info
[08:02] <zyga-suse> darn, where was that...
[08:06] <zyga-suse> pstolowski: sorry I cannot find it
[08:06] <zyga-suse> I think it was on IRC but you were already off
[08:06] <zyga-suse> but I cannot see it in my backlog
[08:07] <zyga-suse> pstolowski, the situation is as follows, start installing a snap using master, stop snapd and revert to stable
[08:10] <pedronis> I don't see many solutions here except changing the handling of hooks slightly in 2.26
[08:11] <zyga-suse> I think being more graceful, as if the task was done in 2.26 would be good
[08:11] <zyga-suse> essentially you cannot rely on the hook
[08:11] <zyga-suse> since old snapd may run it
[08:12] <zyga-suse> and if you want to rely, use assumes
[08:12] <pedronis> is the revert of core itself that explodes?
[08:12] <zyga-suse> I don't remember, I think it was not the core but then again, it may be
[08:12] <zyga-suse> and in that case it would be unfortunate
[08:14] <mvo> zyga-suse: I put some comments into the PR 3808, nothing criticial but worth considering IMO
[08:14] <zyga-suse> sure,
[08:16] <mvo> zyga-suse: don't get me wrong, I appreciate the work on this feature and I know its frustrating to wait for reviews :)
[08:18] <zyga-suse> mvo: the nil result is something I copied from Chipaca's PR
[08:18] <zyga-suse> mvo: I can undo that, I was just surprised that you can call methods on typed nil just fine
[08:18] <zyga-suse> mvo: and I did it here
[08:19] <mvo> zyga-suse: right, its fine, I was also surprised about it (haven't seen that pattern) and that is one good reason to have it in code review to spread the knowledge etc :)
[08:19]  * zyga-suse got a telemarketer call now
[08:19] <mvo> zyga-suse: do you remember what PR it was where Chipaca used this nil check pattern? curious to see how/why it was used there too
[08:19] <mvo> zyga-suse: meh, I hate those
[08:19] <zyga-suse> with a 500GB 3G/LTE data plan
[08:20] <zyga-suse> mvo: no, but maybe Chipaca remembers, it was very recent
[08:20] <zyga-suse> at 23euro / month
[08:20]  * zyga-suse is considering that
[08:20] <zyga-suse> they also bundle some crap laptop
[08:22] <mvo> Chipaca: do you think you could have a look at 3795? it probably also needs a review from niemeyer but if we are happy with the code that will help I think (we need gustavo mostly for the concecpt behind it)
[08:22] <mvo> Chipaca: its also short :)
[08:23] <zyga-suse> mvo: replied
[08:23] <zyga-suse> mvo: let me know if you want me to change the nil pointer thing
[08:24] <zyga-suse> man, clouds == crap network
[08:26] <pstolowski> zyga-suse, you mean install a deb with master, then revert to debs from the distro?
[08:27] <pstolowski> (pardon my ignorance, but I'm not sure if it should involve some images from edge etc.)
[08:29] <zyga-suse> pstolowski: I think just install edge and go to stable
[08:29] <zyga-suse> pstolowski: and have the right snap install pending
[08:40] <pstolowski> k
[08:40]  * mwhudson waves
[08:43] <zyga-suse> hey mwhudson
[08:49] <Chipaca> zyga-suse: mvo: good morning!
[08:49] <Chipaca> *technically* it's a national holiday here
[08:49] <zyga-suse> Chipaca: ohhh, nice
[08:49] <zyga-suse> so what are you doing here?
[08:49] <Chipaca> zyga-suse: having breakfast, and also i've been trying to snap a rather gnarly application
[08:50] <zyga-suse> +100
[08:50] <zyga-suse> I love trying to snap things
[08:50] <zyga-suse> to see how that feels like
[08:50] <zyga-suse> and to see what issues I run into
[08:50] <Chipaca> it's looking like i can't make this one work without either bases or layouts
[08:50] <Chipaca> and that assumes layouts lets me replace /lib
[08:54] <Chipaca> zyga-suse: mvo: which PR were you two discussing?
[08:57] <zyga-suse> Chipaca: remember when you showed me a PR where you did methods on nils?
[08:57] <zyga-suse> Chipaca: and I was surprised this is doable in go
[08:58] <Chipaca> yes
[09:00] <mup> PR snapcraft#1512 opened: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512>
[09:01] <zyga-suse> mvo: ^
[09:04] <ogra_> abeato, no idea, perhaps ask in the thread ?
[09:05] <pedronis> afaik it's been postponed
[09:05] <abeato> ogra_, ok, will do
[09:06] <mvo> Chipaca: context is my review of 3808, most specically https://github.com/snapcore/snapd/pull/3808/files#r135463240
[09:06] <mup> PR snapd#3808: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3808>
[09:07] <mvo> Chipaca: and was curious in what context you use it. in the context of this pr I was mostly wondering why not just return by-value but mostly I wanted some context as this is/was a new pattern for me
[09:07] <mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[09:08] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[09:10] <zyga-suse> mvo, Chipaca: please let me know if you want me to change that code, otherwise I'll move on to other work
[09:10] <mvo> meh, it looks like our update to github.com/snapcore/snapd/vendor/golang.org/x/sys/unix broke powerpc
[09:10]  * mvo looks
[09:10] <zyga-suse> aww, sucks
[09:10] <zyga-suse> mvo: btw, golang 1.9 had some support changes for that arch
[09:10] <zyga-suse> they dropped some older HW
[09:11] <pedronis> mvo: we updated it because of the golang/x/crypto update, I don't even think we needed it before
[09:11] <pedronis> fwiw
[09:13]  * pstolowski amazed by mvo's code review
[09:14] <zyga-suse> Chipaca: hmm, why doesn't logger.Noticef print stuff?
[09:14] <pstolowski> mvo, thank you for taking time & proposing the changes
[09:14] <pstolowski> !
[09:14] <mvo> pedronis: aha, thanks, that is good to know, I will investigate, its a bit of a bummer
[09:14] <zyga-suse> Chipaca: but it does later
[09:14] <zyga-suse> 2017/08/28 11:13:52.385942 daemon.go:275: started snapd/2.27.3+git744.gd34c3ddc6 (series 16; classic; devmode) opensuse/20170823 (amd64) linux/4.12.8-1-default.
[09:14] <zyga-suse> that's the first message I see
[09:14] <mvo> pstolowski: your welcome, my pleasure
[09:14] <zyga-suse> but before that I call noticef + println in another spot and only the println shows up
[09:14] <mwhudson> zyga-suse: 1.9 changed stuff around ppc64 big endian, which has never been an ubuntu architecture
[09:14] <mvo> zyga-suse: go-1.9> things we should land?
[09:14] <mvo> zyga-suse: in master I mean?
[09:14] <zyga-suse> mwhudson: ah, good
[09:14] <mwhudson> zyga-suse: this failure is about powerpc
[09:14] <mwhudson> i.e. 32-bit
[09:15] <zyga-suse> aha
[09:15]  * zyga-suse shuts up then
[09:15] <mwhudson> which stopped being an ubuntu architecture in ... zesty?
[09:15] <mwhudson> it ought to be possible to add gccgo / powerpc support to sys/unix, i never figured out how to do it thouh
[09:16] <mwhudson> (also didn't care overly much)
[09:16] <mvo> mwhudson: powerpc we probably still need to support because of 16.04, the failures look slightly nasty: http://paste.ubuntu.com/25416387/
[09:16]  * zyga-suse sees SetLogger
[09:16] <mwhudson> mvo: x/sys/unix just doesn't support powerpc at all
[09:16] <mvo> mwhudson: aha, great that you know more about this, so what are our options? can we avoid sys/unix somehow?
[09:16] <mwhudson> mvo: i don't know which bit of crypto is using it
[09:17] <Chipaca> mvo: sitting in the top of the tree, try: find -type f -name \*.go -print0 | xargs -0 perl -wne 'BEGIN{$n=0}; if ($n!=0) {$n=0; print "$ARGV: $f$ARGV: $_" if /if $v == nil/ }; if (/^func \((\S+) \*/) {$n=1; $f=$_; $v=$1}'
[09:17] <Chipaca> zyga-suse: where doesn't logger.Noticef print stuff?
[09:18] <mwhudson> mvo: support for other arches with gccgo has been added, so presumably the same can be done for ppc
[09:18] <zyga-suse> woah
[09:18] <zyga-suse> that's nice
[09:18] <Chipaca> zyga-suse: it might be trying to print stuff before it's initialised?
[09:18] <ogra_> mvo, i just noticed that the initramfs-tools-ubuntu-core deb is behind the git tree, androidboot is missing and there was no deb build after the unit tests branch landed ... if i push that to the PPA today do i disturb any release ?
[09:18] <zyga-suse> Chipaca: I patched an init() function in a module to call it
[09:18] <zyga-suse> Chipaca: I understand that during startup we actually init the logger
[09:18] <Chipaca> yes
[09:18] <zyga-suse> Chipaca: and I got the short end of the ordering stick
[09:18] <Chipaca> probably
[09:18] <zyga-suse> hmmm
[09:19]  * zyga-suse wants the user warning framework
[09:19] <zyga-suse> I could really use it now
[09:19] <Chipaca> zyga-suse: is this in debugging snapd?
[09:19] <zyga-suse> yes
[09:19] <zyga-suse> well
[09:19] <Chipaca> zyga-suse: just print it?
[09:19] <mvo> ogra_: thanks for checking, things should be fine today
[09:19] <zyga-suse> I want something more sticky
[09:19] <zyga-suse> jdstrand requested that we log that we are on partial apparomr
[09:19] <ogra_> mvo, ok, then i'll upload
[09:19] <zyga-suse> "prominently" logged
[09:20] <zyga-suse> Chipaca: I'll just print it with a comment
[09:20] <pedronis> so the failing test now is passing, so probably a bunch of other tests might start failing, will see
[09:21] <Chipaca> mvo: that pattern is used in our code in a few places where the expected use of a something includes it sometimes being nil
[09:22] <ogra_> so i built a wine snap last night ...
[09:22] <mvo> Chipaca: thanks, interessting, it escaped me so far
[09:22] <ogra_> and since wine currently only does i386 i actually had to build for i386 ...
[09:23] <Chipaca> mvo: so rather than having “artifact:=default; if thing != nil {artifact = thing.GetArtifact()}”, you move the check into GetArtifact
[09:23] <ogra_> and i must say i have never had such a painful experience with snapcraft :/
[09:23] <ogra_> (trying to build for i386 on amd64 host)
[09:24] <pedronis> Chipaca: mvo:  go does it by static typing, but it exists as pattern since smalltalk (maybe even earlier), afaik it is liked/disliked ever since though
[09:24] <Chipaca> ogra_: you know you can ship i386 binaries in an amd64 snap, yes?
[09:25] <Chipaca> maybe that wasn't your issue :-)
[09:25] <ogra_> Chipaca, but when buiolding from source you still need a i386 build env
[09:25] <Chipaca> anyway, i'll shut up now, seeing as how i'm not really working
[09:25] <mvo> Chipaca, pedronis: thanks, it makes perfect sense was mostly wondering a bit when/how to use it. thanks for your input on this :)
[09:25] <Chipaca> ogra_: “apt install build-essential:i386”?
[09:25] <ogra_> and i dont want the 79234846 build deps wine needs installed on my host ...
[09:25] <Chipaca> ah
[09:25] <ogra_> so i use cleanbuild
[09:26] <ogra_> and then things explode
[09:26] <ogra_> even using a plain lxd container as i386 system doesnt work properly
[09:26] <ogra_> (there is an unfixed bug in libc)
[09:26] <mwhudson> pedronis: smalltalk is a bit different though, messages sent to nil are all ignored, iirc?
[09:28]  * zyga-suse suffers terrible network
[09:28] <zyga-suse> just 2 days left
[09:28] <zyga-suse> I'll be home by Wednesday
[09:30] <pedronis> mwhudson: well, I was more referring to people adding implementation of things to nil
[09:30] <pedronis> which you can
[09:31] <mwhudson> ah
[09:31] <pedronis> (unless I'm totally misremembering this)
[09:31] <pstolowski> zyga-suse, - Run refresh hook of "core" snap if present (internal error: no registered handlers for hook "refresh")
[09:31] <pstolowski> zyga-suse, ^ is that what you saw when refreshing core from stable to edge and back to stable?
[09:34] <zyga-suse> yes
[09:34] <zyga-suse> that's what I saw
[09:34] <mup> PR snapd#3814 opened: interfaces: enable partial apparmor support <Created by zyga> <https://github.com/snapcore/snapd/pull/3814>
[09:34] <zyga-suse> pstolowski: is that a release blocker?
[09:37] <mvo> 3781 needs a second review, its very nice and not very long
[09:39] <pstolowski> zyga-suse, afaict we don't have this hook in release/2.27
[09:40] <pedronis> pstolowski: a blocker for 2.28
[09:40]  * zyga-suse looks at 3781
[09:40] <mvo> Chipaca: 3748 has a conflict
[09:40] <pstolowski> pedronis, oh, for 2.28 yes
[09:40] <pedronis> or for 2.27 if we decide we need to do something there
[09:41] <pedronis> it seems this a problem that will show up again and again with new hooks
[09:43] <pstolowski> yes
[09:44] <zyga-suse> pedronis, pstolowski: are you suggesting a 2.27.5 with some future-proofing for hooks in general?
[09:44] <zyga-suse> ahead of 2.28 release?
[09:44] <pedronis> I don't know
[09:44] <pedronis> I'm mostly musing
[09:47]  * zyga-suse nods
[09:48] <pstolowski> i'm not sure. i need to fully understand the problem. hook machinery is a little bit deceptive with the 'Optional' flag. clearly the registration of hook handlers is critical
[09:49] <zyga-suse> optional feels like "may fail"
[09:49] <zyga-suse> but we need to know it exists
[09:50] <zyga-suse> which poses a problem for each added hook
[09:50] <pstolowski> i have a feeling that the only way around this is to make a missing handler non-critical
[09:50] <pedronis> if it's optional and the hooks doesn't exist in the snap, we don't care if the hook is registered or not
[09:50] <pedronis> internally
[09:50] <pedronis> but I don't remember the internal details to know if this is easy or not to tweak that way
[09:51] <pedronis> it probably breaks abstractions
[10:22] <pstolowski> uh oh we have a logic like this in place already, but i think it has a bug
[10:38]  * tbr slaps chihchun_afk around a bit with a large and slimy trout. Dude, turn off your nick-changes.  I couldn't find the discussion
[10:44] <zyga-suse> ogra_: woot, thank you :)
[10:44] <ogra_> this is when moving to edge (for a test) and then trying to go back to beta
[10:45] <zyga-suse> mvo: ^ given this I would say we need to fix that for 2.28
[10:46] <pstolowski> ogra_, yeah, that's the issue i'm looking on. nb, you can of course snap revert core
[10:46] <ogra_> a revert would switch channels ?
[10:47] <mvo> zyga-suse: sounds like something we need to 2.28, yes. I understand pstolowski is looking into it(?)
[10:47] <pstolowski> ogra_, no, just mentioning, it won't fail that way
[10:47] <ogra_> right
[10:47] <pstolowski> mvo, yes, i think i've a fix
[10:47] <ogra_> it only fails when moving to edge and trying to go back though ...
[10:48] <ogra_> (i doubt it affects the beta/candidate or stable channels yet)
[10:48] <zyga-suse> ogra_: and by extension it will fail when CE will test rollback from 2.28
[10:48] <ogra_> right
[10:55] <fgimenez> hey mvo, looks like CE QA found an issue with 2.27.4, i've just forwarded you the message
[10:55] <mvo> Chipaca: http://paste.ubuntu.com/25416853/ is probably something we need to fix for 2.28
[10:56] <mvo> fgimenez: thanks, let me have a look
[10:56] <zyga-suse> fgimenez: can this be public somewhere please?
[10:57] <zyga-suse> mvo: also FYI, not for 2.28 (needs research first) but important as it breaks containers: https://bugs.launchpad.net/snapd/+bug/1712930
[10:57] <mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930>
[10:57] <fgimenez> zyga-suse: not sure better ask them, they are posting to<EMAIL_ADDRESS>maybe you can subscribe?
[10:58] <zyga-suse> fgimenez: I mean, I could do that but then again we have https://forum.snapcraft.io/t/in-progress-snapd-2-27-4/572 that everybody should post to
[10:59] <mvo> zyga-suse: hm, is this just changing the order of things (ideally switching two lines). or is there more work involved here?
[11:03] <fgimenez> zyga-suse: yeap, i already mentioned them about the forum and the release threads but don't know about how (or if) they make their test results public, they can explain better for sure :)
[11:05] <zyga-suse> mvo: not sure if this is just two lines :)
[11:06] <zyga-suse> mvo: could be trivial or very complex, I didn't look yet
[11:06] <mvo> ok
[11:06] <mup> PR snapcraft#1513 opened: lifecycle: outdated step should raise SnapcraftError <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1513>
[11:18] <mup> PR snapd#3815 opened: tests: install test-snapd-complexion on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3815>
[11:18] <mvo> Chipaca: trivial reproducer -^
[11:22] <zyga-suse> hmmmmmmm
[11:22]  * zyga-suse is unhappy about https://travis-ci.org/snapcore/snapd/builds/269141620?utm_source=github_status&utm_medium=notification
[11:22] <pedronis> mvo: I think it's an holiday for John
[11:22] <zyga-suse> is that just another bug in apparmor profile loading for tests
[11:22] <zyga-suse> or a real issue
[11:22] <zyga-suse> indeed
[11:22] <mwhudson> mvo: i wrote up that dput linter wrapper thing I talked about before https://gist.github.com/mwhudson/616499edb1191bd99c987bbbd8781ce9
[11:22] <zyga-suse> he is off
[11:22] <mvo> pedronis: oh, thanks
[11:22] <mvo> Chipaca: weeeh, sorry - you are off today? I won't bother you anymore
[11:23] <mvo> mwhudson: nice
[11:23] <zyga-suse> mvo: question, will we re-load snap-confine's apparmor profile before configuring core?
[11:45] <mup> PR snapd#3816 opened: hooks: do not error out when hook is optional and no hook handler is registered <Created by stolowski> <https://github.com/snapcore/snapd/pull/3816>
[11:45] <pstolowski> zyga-suse, mvo ^ this should fix the problem with hooks, but I only tested with unit test
[11:51] <mup> PR snapd#3817 opened: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <https://github.com/snapcore/snapd/pull/3817>
[11:54] <mup> PR snapcraft#1510 closed: ci: disable the travis deploy stage for docs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1510>
[12:12] <mup> PR snapcraft#1508 closed: schema: version should have a max length of 32 <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1508>
[12:52] <cachio> mvo, did you see the email I fw?
[12:52] <mvo> zyga-suse, spineau, jdstrand: so I think I have an idea about the problem with "sudo network-manager.nmcli d show eth0" getting denies on 2.27 - we enabled seccomp argument filtering for socket. and the profile has "#  socket AF_NETLINK - -" and I assume that nmcli uses the netlink socket
[12:52] <mvo> cachio: indeed I did and after a small panic I started debugging
[12:53] <cachio> mvo, ohhh, any finding?
[12:54] <mvo> cachio: yes, maybe, I think I need jdstrand to help me, but I suspect we need to enable socket AF_NETLINK at least for nmcli, maybe for more.
[12:55] <cachio> mvo, is this caused because the last change done for 2.27.4?
[12:55] <zyga-suse> mvo: there's a new set of netlink interfaces
[12:55] <zyga-suse> mvo: maybe those are sufficient there
[12:55] <zyga-suse> mvo: I wish we knew the values of other arguments but I suspect I can easily check that locally
[12:55] <zyga-suse> mvo: (if it is netlink or not)
[12:56] <zyga-suse> mvo: AFAIK it used KOBJECT_UEVENT but perhaps I'm wrong
[12:56] <spineau> mvo: like mmcli? that's the first one I can think of
[12:56] <zyga-suse> mvo: note that jamie is off today, I'll check it out after checking out one other thing
[12:56] <zyga-suse> mvo: if you can strace it on your machine and pastebin that it would be sufficient
[12:59] <spineau> zyga-suse: mvo: I'm still connected to our test device, if I can help you by providing more logs, just ask
[12:59] <zyga-suse> spineau: thank you, if you know how to run strace under snap confinement (not trivial) then please do that
[13:00] <zyga-suse> spineau: you need to edit the seccomp/apparmor profiles, allow extra stuff and run strace you get from the host somehow
[13:00] <zyga-suse> spineau: don't worry if you don't want to go through those hoops
[13:00] <spineau> zyga-suse: unfortunately, I'm still a snap newbie
[13:01] <mvo> zyga-suse: strace is not working for me, hangs
[13:01] <mvo> zyga-suse: when I enable AF_NETLINK things work
[13:01] <zyga-suse> mvo: strace needs some love, ok
[13:02] <mvo> zyga-suse: socket AF_NETLINK - -
[13:02] <mvo> zyga-suse: if that is part of the profile things work
[13:03] <zyga-suse> mvo: note that we don't have any interfaces that add that
[13:03] <zyga-suse> mvo: we have "socket AF_NETLINK - NETLINK_AUDIT" and similarly NETLINK_CONNECTOR
[13:03] <zyga-suse> we need to know which one is really required
[13:03] <zyga-suse> mvo: and perhaps consider an approach (new release of network-manager or a snap-id specific quirk)
[13:26] <willdeberry> so it seems that everything was passing, but since I have been rebasing just to keep things fresh, travis build now fails: https://github.com/snapcore/snapd/pull/3812
[13:26] <mup> PR snapd#3812: Expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
[13:34] <zyga-suse> mvo: offtopic
[13:34] <pedronis> niemeyer: will you create a tracker topic in the forum for the current PRs?
[13:34] <zyga-suse> mvo: I updated my x250 to zesty
[13:34] <zyga-suse> mvo: and ... the update removed xorg-input-all
[13:34] <zyga-suse> mvo: that was curious to debug
[13:35] <zyga-suse> mvo: apparently people ran into this too and I found lots of forum posts and what not
[13:35] <zyga-suse> mvo: so now things work
[13:35] <zyga-suse> mvo: when you don't have xorg-input-all and its deps you have GDM/lightdm with *no* keyboard interaction at all
[13:35] <zyga-suse> not even alt-ctrl-f2 to get out
[13:36] <niemeyer> pedronis: I'm on the fence about it.. I want to make sure we take it as an actual sprint if it's added, and given all the work on the release we may not be able to do it
[13:36] <zyga-suse> aha, so I know what is wrong with the spread setup, nothing, it looks like a very odd and curious apparmor behavior
[13:36] <niemeyer> pedronis: Perhaps we can kick it off once the release is clean?
[13:36] <pedronis> niemeyer: ok, just wondering because I start to have a bit of hard time finding/remembering what to review
[13:37] <niemeyer> pedronis: Aha, I see
[13:37] <niemeyer> pedronis: Let me create one then
[13:37] <mup> PR snapd#3818 opened: interfaces: fix network-manger plug <Created by mvo5> <https://github.com/snapcore/snapd/pull/3818>
[13:38] <mup> PR snapd#3819 opened: hooks: do not error out when hook is optional and no hook handler is registered (2.27) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3819>
[13:38] <mvo> 3260 needs a second review, tests are green now
[13:39] <mvo> zyga-suse: 3818 is maybe what we need to fix the nmcli issue, an early look  is appreciated, I mostly opened it to get spread tests running
[13:43] <zyga-suse> mvo: ack
[13:43] <pedronis> snapd#3817 needs quick a review (it's about the fakestore tests that were sill failing sometimes for me in autopkgtests)
[13:43] <mup> PR snapd#3817: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <https://github.com/snapcore/snapd/pull/3817>
[13:43] <zyga-suse> re-started something else and looking
[13:43] <niemeyer> Forgot to ask.. did we have any other issues on the testing infra after the Spread changes I did on Friday?
[13:43] <ogra_> wow, cool ...
[13:44] <ogra_> seems my wine snap really works with all exe installers i have lying around ... and all install just go fine to SNAP_USER_DATA
[13:44] <ogra_> *all installs
[13:45] <mvo> ogra_: thats very neat, wine is a nice snap to have
[13:45] <ogra_> well, needs --devmode
[13:45] <ogra_> (or --classic, but i didnt feel like making a classic snap)
[13:45] <ogra_> it wants to read / and /boot
[13:46] <mvo> makes one wonder why that :)
[13:46] <ogra_> but it it really cool that you can just install wine 2.15 next to the deb one
[13:46] <ogra_> because it can put .desktop files in place and such
[13:46] <ogra_> for apps it installs
[13:46] <mvo> yeah, also wine might be perfect for tracks, i.e. being able to install 2.0, 2.1, etc
[13:46] <ogra_> yeah
[13:47] <ogra_> i only did it out of curiosity ... but there is a snapcraft source tree now that someone can take and make something real out of it
[13:47] <ogra_> our forum doesnt work with the sippped wine IE :/
[13:47] <ogra_> *shipped
[13:48]  * mvo nods
[13:48] <ogra_> "your browser is to old" :P
[13:49] <ogra_> snapcraft.io itself and ubuntu.com work fine
[13:53] <mup> PR snapd#3817 closed: tests: wait more and more debug info about fakestore start issues <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3817>
[13:55] <zyga-suse> mvo: re, thank you for checking it is UEVENT
[13:55] <zyga-suse> let me look at something related and I will review this
[13:57] <mvo> zyga-suse: no real rush, I want to see the test results first, maybe its actually not working
[13:58] <zyga-suse> I commented
[13:59] <mvo> zyga-suse: aha, indeed, silly me, you are right. I will fix
[13:59] <zyga-suse> thanks!
[14:00] <zyga-suse> I checked other interfaces
[14:00] <zyga-suse> they all use permanent snippet but for slot
[14:00] <zyga-suse> for plug I think it's fine to keep this on connected
[14:07] <mup> PR snapcraft#1514 opened: docs: add github processed templates <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1514>
[14:11] <mup> PR snapd#2807 closed: snap: add new `snap switch` command <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2807>
[14:25] <mup> PR snapd#3820 opened: spread: don't set HTTPS?_PROXY for linode <Created by zyga> <https://github.com/snapcore/snapd/pull/3820>
[14:26] <zyga-suse> mvo: ^ trivial one
[14:31] <zyga-suse> tested locally
[14:33] <zyga-suse> mvo: looking at the ordering issue now
[14:33] <mvo> zyga-suse: great, thank you!
[14:34] <mvo> zyga-suse: I'm waiting for tests and I think 3818 will need a review from jamie as well, right?
[14:34] <zyga-suse> yes
[14:34] <zyga-suse> note that jamie is off today
[14:43] <niemeyer> pedronis: https://forum.snapcraft.io/t/review-sprint-3/1880
[14:49] <pedronis> niemeyer: thanks
[14:52] <niemeyer> pedronis: No problem.. tweaked the format slightly as apparently the recent changes in Discourse modified some of the old icons we were using, but still same thing
[14:52] <mup> PR snapd#3821 opened: tests: new regex used to validate the core version on extra snaps ass <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3821>
[15:08]  * zyga-suse moved indoors, too cold
[15:45] <soee> hi, i have installed an app via snap and have this: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[15:46] <soee> any idea what is wrong ?
[16:00] <zyga-suse> hey
[16:00] <zyga-suse> soee: let me try to help you
[16:00] <zyga-suse> soee: can you start by running "snap version" and pasting the result
[16:01] <Chipaca> mvo: ah! so on core we need to not do the snippets (and source complete.sh)
[16:01]  * Chipaca disappears again
[16:27] <cachio> pedronis, hey, any idea why this error could be happening runing tests on staging ?
[16:27] <cachio> error: cannot fetch snap signatures/assertions: circular assertions are not expected: account (canonical)
[16:41] <pedronis> cachio: sounds it's not using the right kind of snapd
[16:41] <pedronis> maybe reexec doing something wrong
[16:42] <pedronis> cachio: fwiw I used a correctly built snapd against staging on Friday and things worked
[16:42] <pedronis> snapd built from master
[16:43] <cachio> pedronis, how did you setup the tests?
[16:43] <cachio> pedronis, which variables did you use?
[16:44] <cachio> I want to replicate that into the sread-cron tests against staging
[16:44] <pedronis> cachio:  afair  the test setup should do the right thing, there are two part to this,  you need a snapd built with withtestkeys or withstagingkeys
[16:44] <pedronis> cachio: then you need SNAPPY_USE_STAGING_STORE=1
[16:45] <cachio> pedronis, I have that
[16:45] <cachio> export SPREAD_REMOTE_STORE=staging
[16:45] <cachio> it is traduced into  SNAPPY_USE_STAGING_STORE=1
[16:46] <pedronis> and DEB_BUILD_OPTIONS='nocheck testkeys' dpkg-buildpackage -tc -b -Zgzip
[16:46] <pedronis> the testkeys should do the other part
[16:47] <pedronis> I need a bit more details where this exactly is breaking? breaking early or in some specific test?
[16:48] <pedronis> anyway I need to go have dinner
[16:52] <cachio> pedronis, on those tests https://travis-ci.org/snapcore/spread-cron/builds/268521976#L1224
[16:52] <cachio> there are many tests failing for he same reason
[17:11] <pedronis> cachio: I'll look in my morning
[17:11] <cachio> pedronis, sure, tx
[17:11] <cachio> I am taking a look right now too
[17:13] <pedronis> notice that some are other platforms
[17:13] <pedronis> I mean != ubuntu
[17:13] <pedronis> I don't think it makes sense to run those tests against staging
[17:14] <pedronis> like that failure is for opensuse
[17:14] <pedronis> I don't know if it knows how to build a staging snapd
[17:16] <cachio> ok
[17:16] <cachio> pedronis, i'll change that too, thanks
[17:16] <pedronis> cachio: I mean until we understand more I would skip anything not ubuntu  for staging tests
[17:20] <cachio> pedronis, sure
[17:21] <pedronis> the main user of these tests would be store after a staging deployment
[17:21] <pedronis> I think they have been too flaky to use them tough :/
[17:24] <cachio> pedronis, yes, agree
[17:24] <cachio> most of them have been failing for a while
[17:25] <cachio> pedronis, I think staging should be used just to validate some specific stuff
[17:25] <cachio> pedronis, so it is easier to keep it in green
[17:44] <zyga-suse_> hmm
[17:44] <zyga-suse_> - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
[17:44] <zyga-suse_><EMAIL_ADDRESS>[17:44] <zyga-suse_> from upgrade/basic
[19:14] <stormmore> How difficult would it be to write a snap that can read /etc with making using --classic?
[19:34] <mup> PR snapd#3821 closed: tests: new regex used to validate the core version on extra snaps ass <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3821>
[19:41] <niemeyer> stormmore: With classic or without classic?
[19:42] <niemeyer> pedronis, zyga-suse_, cachio: Review board now has details on who's reviewing or needs to review
[19:43] <cachio> niemeyer, nice
[19:43] <stormmore> niemeyer: preferably without
[19:47] <niemeyer> stormmore: That needs an interface for the specific need you have.. many are already available, but it may need to be created as well if it's not yet there
[19:48] <niemeyer> stormmore: With classic, it's just a matter of opening the files.. nothing fancy to be done
[19:49] <stormmore> niemeyer: whats a good place to see a list of interfaces. I did look there as that was what I was suspecting but I didn't find one that would give even read-only (not sure that is going to be sufficient for my needs yet but gotta start somewhere) access to /etc from their desc
[19:50] <niemeyer> stormmore: No interface will give access to all of /etc
[19:50] <niemeyer> stormmore: Some will give access to specific bits inside /etc, according to their described purpose
[19:51] <stormmore> niemeyer: ah that is why I am probably leaning towards making this a classic snap (at least initially)
[19:51] <niemeyer> stormmore: Yeah, it's a fine way to get started
[19:52] <stormmore> niemeyer: thanks, just wanted to see if there was a "better way" but looks like I was on the right track
[20:00] <mup> PR snapd#3120 closed: [WIP] interfaces/hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3120>
[20:08] <zyga-suse_> niemeyer: wow, that's nice
[20:08] <zyga-suse_> WOW, way nicer than I expected :D
[20:10] <zyga-suse_> really nice work :)
[20:10] <zyga-suse_> niemeyer: I wonder what will happen when we have initial clashes in the team
[20:11] <niemeyer> zyga-suse_: Wow, thanks :)
[20:11] <niemeyer> zyga-suse_: You mean more than 26 reviewers? ;P
[20:12] <zyga-suse_> well, if we get another zygmunt, will we call him z^1 ;D
[20:12] <niemeyer> zyga-suse_: We already have clashes.. look closely
[20:13] <niemeyer> and apparently we also have a bug.. something is wrong with #3260.. looking
[20:13] <zyga-suse_> ah, indeed
[20:14]  * zyga-suse_ is happy that zygmunt is an uncommon word and his life is simple here
[20:19] <cachio> niemeyer, do you know which is the job to sync prod with staging stores?
[20:21] <pedronis> cachio: there's no such job
[20:22] <cachio> pedronis, ok, is it a manual procedura?
[20:22] <pedronis> yes, we typically add relevant snaps to staging
[20:22] <pedronis> staging store and prod store are fairly indepedent
[20:23] <cachio> ok, so I should download/upload the snaps
[20:23] <cachio> pedronis, I'll try that
[20:24] <pedronis> anyway probably another good reason to cut down staging tests
[20:25] <cachio> pedronis, yes
[20:25] <cachio> pedronis, if it is not automatic, it does not scale
[20:25] <pedronis> not sure how to do that though, spread doesn't have more tagging than manual
[20:25] <pedronis> skipping support is also missing, our skips atm ad hoc
[20:27] <pedronis> one approach could be just have a different suite and symlinks
[20:29] <cachio> pedronis, why we are running tests against staging?
[20:30] <cachio> pedronis, if there is not something new to test on there the best we can do is to remove those execution from spread-cron as you suggested
[20:30] <pedronis> cachio: ?  the idea was to run them each time one of the store services gets a new staging deploy ?
[20:31] <pedronis> that's what triggers runs
[20:31] <pedronis> to check that changes to the store don't break the contract with snapd
[20:31] <pedronis> that was the idea
[20:31] <cachio> pedronis, makes sense
[20:32] <pedronis> yes, it's a sound idea, the executation hasn't been amazing so far though, also probably too many not relevant tests
[20:32] <cachio> so, we just need to keep the databases synchronized
[20:32] <pedronis> and also the store has changed, so we need different checks
[20:32] <pedronis> cachio: ?
[20:32] <pedronis> don't think that's going to happen
[20:34] <cachio> pedronis, I mean, perhaps the solution is to add a job to keep both in sync
[20:34] <pedronis> we can add something that keeps some subset of snaps in sync
[20:34] <pedronis> but in general afaik there's no plan to keep them generally in sync
[20:35] <cachio> pedronis, otherwise always when we do a change in a snap we need to make that same change in staging
[20:35] <cachio> is it correct?
[20:35] <pedronis> that's how we did so far, yes
[20:36] <cachio> pedronis, ok
[20:37] <cachio> pedronis, what do you suggest, disable the staging jobs? or continue doing that sync manually? or start doing something to keep it on sync
[20:38] <pedronis> cachio: I think we need to take a step back and setup a meeting with the stakeholder interested in that
[20:38] <pedronis> it's not about what *I* suggest
[20:39] <pedronis> *stakeholders
[20:39] <cachio> pedronis, ok, makes sense, how are the interested stakeholders?
[20:39] <cachio> who
[20:39] <cachio> celso?
[20:40] <pedronis> I can ask tomorrow
[20:40] <cachio> pedronis, sure
[20:40] <cachio> let's talk about that tomorrow
[21:16] <niemeyer> Okay, figured the issue and fixed.. board updated again, with correct data.
[22:30] <mup> PR snapd#3760 closed: Allow snap-confine to be confined even with --disable-apparmor <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/3760>
[23:36] <mup> PR snapd#3260 closed: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3260>


[04:22] <joejaxx> @meeting
[04:22] <joejaxx> hmm
[05:49] <gnomefreak> @schedule new_york
[05:49] <Ubugtu> Schedule for America/New_York: 03 Oct 13:00: Community Council | 04 Oct 08:00: Edubuntu | 05 Oct 03:00: Ubuntu Development Team | 10 Oct 16:00: Technical Board | 11 Oct 16:00: Edubuntu | 12 Oct 11:00: Ubuntu Development Team
[05:53] <freeflying> @schedule Shanghai
[05:53] <Ubugtu> Schedule for Asia/Shanghai: 04 Oct 01:00: Community Council | 04 Oct 20:00: Edubuntu | 05 Oct 15:00: Ubuntu Development Team | 11 Oct 04:00: Technical Board | 12 Oct 04:00: Edubuntu | 12 Oct 23:00: Ubuntu Development Team
[07:13] <sharms> @schedule chicago
[07:13] <Ubugtu> Schedule for America/Chicago: 03 Oct 12:00: Community Council | 04 Oct 07:00: Edubuntu | 05 Oct 02:00: Ubuntu Development Team | 10 Oct 15:00: Technical Board | 11 Oct 15:00: Edubuntu | 12 Oct 10:00: Ubuntu Development Team
[07:15] <sivang> @schedule Israel
[07:15] <Ubugtu> Schedule for Israel: 03 Oct 19:00: Community Council | 04 Oct 14:00: Edubuntu | 05 Oct 09:00: Ubuntu Development Team | 10 Oct 22:00: Technical Board | 11 Oct 22:00: Edubuntu | 12 Oct 17:00: Ubuntu Development Team
[07:37] <GNAM> @schedule rome
[07:37] <Ubugtu> Schedule for Europe/Rome: 03 Oct 19:00: Community Council | 04 Oct 14:00: Edubuntu | 05 Oct 09:00: Ubuntu Development Team | 10 Oct 22:00: Technical Board | 11 Oct 22:00: Edubuntu | 12 Oct 17:00: Ubuntu Development Team


[01:12] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/less-public-bmp/+merge/150731
[01:17] <wgrant> StevenK: Sounds good
[01:17] <wgrant> Thanks for fixing those security adapters
[01:17] <wgrant> By deleting them
[01:20] <StevenK> Heh
[03:05] <StevenK> wgrant: Trying to render create_initialized_view(branch, '+index', rootsite='code')
[03:05] <StevenK> results in a large and angry traceback
[03:05] <StevenK> Due to breadcrumbs, from what I can see
[03:26] <StevenK> wgrant: http://pastebin.ubuntu.com/5572431/
[03:43] <wgrant> StevenK: Some views won't render like that
[03:43] <wgrant> I don't quite recall why
[03:44] <wgrant> webops: As lp_publish@pepo, could you run `LPCONFIG=ftpmaster-publish scripts/ftpmaster-tools/obsolete-distroseries.py -d ubuntu -s jaunty`?
[03:47] <StevenK> Hah
[03:47] <StevenK> wgrant: The pastebin is my success
[03:47] <wgrant> Oh, wrong chan
[03:47] <wgrant> StevenK: Right
[03:48] <wgrant> That's the usual workaround
[04:09] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/moar-preload-people-branch-index/+merge/150953
[04:10] <wgrant> StevenK: Why not just make hasSubscription not completely insane?
[04:11] <wgrant> Hm
[04:11] <wgrant> Also, is that the right method?
[04:12] <wgrant> Ah, it is
[04:12] <wgrant> But I think your change is still insane.
[04:12] <StevenK> wgrant: http://pastebin.ubuntu.com/5572472/
[04:13] <wgrant> StevenK: see DecoratedBranch.hasSubscription
[04:14] <StevenK> Argh
[04:14] <StevenK> Argh
[04:15] <StevenK> Hm
[04:15] <StevenK> I can probably delete that, then
[04:15] <wgrant> Delete what?
[04:15] <StevenK> DecoratedBranch.hasSubscription
[04:16] <wgrant> Not really.
[04:16] <wgrant> For one, your change to Branch.hasSubscription is wrong
[04:16] <wgrant> For another, it's not clear that it's valuable.
[04:16] <wgrant> I'd change your branch to just make DecoratedBranch.hasSubscription not crap
[04:17] <StevenK> wgrant: http://pastebin.ubuntu.com/5572479/
[04:17] <wgrant> StevenK: How does that change anything?
[04:18] <StevenK> self.subscriptions is a cached list, apparently
[04:18] <wgrant> Sure
[04:18] <wgrant> But it's exactly the same as what the method was doing before, except slower because there's no short-circuit
[04:18] <wgrant> So it'll just execute *more* queries.
[04:19] <StevenK> So I should do the personID check, then?
[04:19] <wgrant> Right
[04:19] <wgrant> That's how you would avoid making person queries.
[04:20] <StevenK> wgrant: http://pastebin.ubuntu.com/5572483/
[04:20] <wgrant> That looks more sensible.
[04:21] <StevenK> Tempted to remove the last three lines of the docstring for being wrong and causing more queries
[04:21] <StevenK> Well, the lines were wrong, they are not any more ...
[04:27] <StevenK> wgrant: MP updated.
[04:27] <wgrant> StevenK: r=me
[04:29] <StevenK> wgrant: And BMPs are very very unhappy on qas
[04:29] <StevenK> But I suspect that was known
[04:29] <wgrant> What do you mean?
[04:29] <StevenK> I tried to look at a few MPs on qas, and they OOPS due to librarian content
[04:30] <wgrant> Yes
[04:30] <wgrant> That's always been the case
[04:30] <wgrant> You have to create new ones
[05:06] <StevenK> wgrant: What do you think the plan is for bug 736014 ?
[05:06] <_mup_> Bug #736014: BugTask:+huge-vocabulary timeout <target-picker> <timeout> <vocabulary> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736014 >
[05:06] <StevenK> We've discussed it a few times, but then Branch and BMP ate my brain.
[05:09] <wgrant> StevenK: DistributionSourcePackageCache/DistroSeriesPackageCache
[05:09] <wgrant> (I believe those two parallel class names were designed to have the same acronym just to make me angry, since there's no other reason for one to have Source and one not)
[05:09] <StevenK> Those two classes make me sad
[05:21] <wgrant> z,cb 3
[05:21] <wgrant> bah
[05:22] <StevenK> Cat?
[05:22] <wgrant> Accidental Dvorak
[05:24] <lifeless> so thats what, 'f*ck u' ?
[05:25] <wgrant>  /win 3, but close enough
[08:16] <noodles775> Hi! Is anyone up for a small-ish review (190l): https://code.launchpad.net/~michael.nelson/launchpad/include-binary-size/+merge/150831
[08:34] <czajkowski> wgrant: StevenK what is the story with on call reviewer nowadays ?
[08:45] <lifeless> on what :P
[08:46] <lifeless> noodles775: you know buildbot is 30m or something now :)
[08:46] <czajkowski> lifeless: mornin'
[08:50] <noodles775> lifeless: no? wow. fwiw, the tests didn't seem to run correctly on my instance: http://paste.ubuntu.com/5572841/ (that's using `time ./bin/test`)
[08:55] <lifeless> noodles775: http://blog.launchpad.net/performance/parallel-testing-is-live
[08:56] <lifeless> noodles775: what size instance (machine RAM) ?
[08:56] <cjwatson> About 40m I think
[08:58] <noodles775> lifeless: it's an m1.small (2G), nothing else running on it (I just set it up for LP development yesterday)
[08:59] <cjwatson> I know wgrant said that adding hashes would be "probably overcomplicated", but cf. bug 1088527
[08:59] <noodles775> Wow - 40mins from 6hrs.
[08:59] <noodles775> Looking
[08:59] <_mup_> Bug #1088527: Needlessly asks for exact package name, file size, uploaded version <ca-escalated> <Developer registration portal:New for michael.nelson> <Launchpad itself:In Progress by michael.nelson> < https://launchpad.net/bugs/1088527 >
[09:00] <cjwatson> Err, sorry
[09:00] <cjwatson> cf. bug 1007195
[09:01] <cjwatson> is what I meant to say
[09:01] <_mup_> Bug #1007195: Librarian-backed HostedFile objects do not expose SHA-1 hash <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1007195 >
[09:01] <cjwatson> (Doesn't specifically have to be the SHA-1 of course; I think that was just what the librarian keyed off at the time or something
[09:01] <cjwatson> )
[09:02] <cjwatson> Anyway, don't let me get in the way by expanding the scope of your work, it was just in case it was trivial to allow for it
[09:03] <noodles775> cjwatson: sure - it should be trivial. So s/include_sizes/include_meta/ and add the the sha1 to the dict?
[09:07] <cjwatson> I guess something like that
[09:31] <lifeless> noodles775: sounds like there is a leak in there somewere, I'd use a bigger instance
[09:31] <lifeless> noodles775: lp's cloud test regime uses x1.xlarge IIRC
[09:32] <noodles775> lifeless: will do next time - I just fired this one up for this bug and normaly only use small for dev work. Thanks.
[10:17] <noodles775> lifeless, cjwatson: updated with your suggestions (except for HasLength). Thanks!
[11:07] <lifeless> noodles775: why not HasLength?
[11:09] <noodles775> lifeless: I commented on the MP, but http://paste.ubuntu.com/5572967/ (and I haven't updated lp's deps) (or am I missing something obvious?)
[11:13] <lifeless> 0.9.14 is quite old
[11:13] <lifeless> 0.9.29.is current, and 30 is about to come out
[11:13] <noodles775> Nice
[11:13] <lifeless> so should be as simple as dropping a dep in launchpad-dependencies and updating versions.txt
[11:13] <lifeless> gnight!
[11:13] <noodles775> G'night :)
[11:14] <lifeless> I can't see any incompat warnings in those releases
[11:15] <lifeless> there's a bunch of shiny improvements though, new matchers and more
[11:15] <lifeless> right, -> sleep.
[14:17] <noodles775> Would someone be able to send this branch to land for me? I've done updates after comments from RobC and ColinW: https://code.launchpad.net/~michael.nelson/launchpad/include-binary-size/+merge/150831
[14:18] <czajkowski> gmb: any idea how we take care of stuff like this now awadays
[14:22] <noodles775> Np, I can wait for one of the LP engineers - the branch isn't that urgent :)


[03:15] <ibeardslee> https://twitter.com/Biz_Dell_AU/status/257652934744088576
[03:22] <ojwb> sad
[03:23] <ojwb> dell used to be pretty good for linux a decade or so ago, at least in the uk
[03:24] <ojwb> wrong "it's" in their twitter branding too
[03:25] <ojwb> ibeardslee: did you look at the feed?  i think you got a form response...
[03:26] <ojwb> or at least there's a word for word identical response (aside from who it's to) just before yours
[07:08] <ibeardslee> ojwb: yeah that's what I think to .. but meh .. they should get it right
[08:46] <ibeardslee> grr the RPi comes with 512MB now
[09:30] <hads> I have one sitting in its static bag doing nothing.
[09:30] <hads> Bummer.
[18:48] <ibeardslee> morning
[19:31] <ajmitch> morning
[19:31] <chilts> morning
[20:44] <ibeardslee> Ubuntu + HDMI -> TV 'problem' .. resolution of tv doesn't seem to be right, and tv3 ondemand play full screen on the laptop, not the TV .. thoughts?
[21:25] <ojwb> morning
[21:26] <ojwb> ibeardslee: i've never managed to get my ubuntu laptop to work with the HDMI tv connection
[21:26] <ojwb> but i've nothing else that does HDMI to compare with, so it could be the TV or the cable
[21:26] <mwhudson> ibeardslee: did you see mjg59's blog post on this?
[21:31] <ibeardslee> mwhudson: No I haven't /me goes looking
[21:37] <ibeardslee> maybe I should just go with his last recommendation
[23:35] <fmarier> thumper: so i had a look at your django-browserid documentation bugs last friday
[23:36] <fmarier> and for one of them (browserid v. browserid-login), the problem is that you were looking at the master version of the code/docs but using the 0.6 version of the code (the lastest on PyPI)
[23:37] <fmarier> so that one will automatically be fixed next time there's a release
[23:38] <fmarier> thumper: the other one (the missing "url" in urls.py), I couldn't reproduce. it worked fine for me without it: https://github.com/fmarier/django-browserid-sample/blob/master/mysite/urls.py


[05:14] -queuebot:#ubuntu-release- New binary: tldjs [amd64] (disco-proposed/universe) [2.3.1-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: twms [amd64] (disco-proposed/universe) [0.06y-2] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: golang-github-gorilla-rpc [amd64] (disco-proposed/universe) [0.0~git20160927.22c016f-3] (no packageset)
[06:16] -queuebot:#ubuntu-release- New: accepted golang-github-gorilla-rpc [amd64] (disco-proposed) [0.0~git20160927.22c016f-3]
[06:16] -queuebot:#ubuntu-release- New: accepted tl-parser [arm64] (disco-proposed) [0.0.0+git20180215.f49077de-1]
[06:16] -queuebot:#ubuntu-release- New: accepted tl-parser [s390x] (disco-proposed) [0.0.0+git20180215.f49077de-1]
[06:16] -queuebot:#ubuntu-release- New: accepted twms [amd64] (disco-proposed) [0.06y-2]
[06:16] -queuebot:#ubuntu-release- New: accepted tl-parser [amd64] (disco-proposed) [0.0.0+git20180215.f49077de-1]
[06:16] -queuebot:#ubuntu-release- New: accepted tldjs [amd64] (disco-proposed) [2.3.1-1]
[06:16] -queuebot:#ubuntu-release- New: accepted tl-parser [ppc64el] (disco-proposed) [0.0.0+git20180215.f49077de-1]
[09:11] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-13.14~18.04.1]
[09:12] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-13.14~18.04.1]
[09:46] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1030.35] (kernel)
[11:44] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-43.46~16.04.1] (kernel)
[11:44] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-43.46~16.04.1] (kernel)
[12:22] -queuebot:#ubuntu-release- New binary: gau2grid [s390x] (disco-proposed/universe) [1.3.0-2] (no packageset)
[12:22] -queuebot:#ubuntu-release- New binary: gau2grid [ppc64el] (disco-proposed/universe) [1.3.0-2] (no packageset)
[12:23] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1030.35]
[12:25] -queuebot:#ubuntu-release- New binary: gau2grid [i386] (disco-proposed/universe) [1.3.0-2] (no packageset)
[12:26] -queuebot:#ubuntu-release- New binary: gau2grid [amd64] (disco-proposed/universe) [1.3.0-2] (no packageset)
[12:28] -queuebot:#ubuntu-release- New binary: gau2grid [arm64] (disco-proposed/universe) [1.3.0-2] (no packageset)
[12:28] -queuebot:#ubuntu-release- New binary: gau2grid [armhf] (disco-proposed/universe) [1.3.0-2] (no packageset)
[12:33] -queuebot:#ubuntu-release- New binary: neutron-vpnaas-dashboard [amd64] (disco-proposed/universe) [1.4.0-1] (no packageset)
[12:40] -queuebot:#ubuntu-release- New binary: modsecurity [ppc64el] (disco-proposed/universe) [3.0.2-1] (no packageset)
[12:45] -queuebot:#ubuntu-release- New binary: modsecurity [i386] (disco-proposed/universe) [3.0.2-1] (no packageset)
[12:45] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1026.27~16.04.1]
[12:45] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-43.46~16.04.1]
[12:45] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-43.46~16.04.1]
[12:46] -queuebot:#ubuntu-release- New binary: libedlib [amd64] (disco-proposed/universe) [1.2.3-3] (no packageset)
[12:46] -queuebot:#ubuntu-release- New binary: libedlib [i386] (disco-proposed/universe) [1.2.3-3] (no packageset)
[12:51] -queuebot:#ubuntu-release- New binary: modsecurity [amd64] (disco-proposed/universe) [3.0.2-1] (no packageset)
[12:51] -queuebot:#ubuntu-release- New binary: modsecurity [s390x] (disco-proposed/universe) [3.0.2-1] (no packageset)
[14:14] -queuebot:#ubuntu-release- New binary: modsecurity [armhf] (disco-proposed/universe) [3.0.2-1] (no packageset)
[14:19] -queuebot:#ubuntu-release- New binary: modsecurity [arm64] (disco-proposed/universe) [3.0.2-1] (no packageset)
[14:54] -queuebot:#ubuntu-release- New: accepted modsecurity [amd64] (disco-proposed) [3.0.2-1]
[14:54] -queuebot:#ubuntu-release- New: accepted modsecurity [armhf] (disco-proposed) [3.0.2-1]
[14:54] -queuebot:#ubuntu-release- New: accepted modsecurity [ppc64el] (disco-proposed) [3.0.2-1]
[14:54] -queuebot:#ubuntu-release- New: accepted modsecurity [arm64] (disco-proposed) [3.0.2-1]
[14:55] -queuebot:#ubuntu-release- New: accepted modsecurity [s390x] (disco-proposed) [3.0.2-1]
[14:55] -queuebot:#ubuntu-release- New: accepted modsecurity [i386] (disco-proposed) [3.0.2-1]
[14:55] -queuebot:#ubuntu-release- New: accepted gau2grid [amd64] (disco-proposed) [1.3.0-2]
[14:55] -queuebot:#ubuntu-release- New: accepted gau2grid [armhf] (disco-proposed) [1.3.0-2]
[14:55] -queuebot:#ubuntu-release- New: accepted gau2grid [ppc64el] (disco-proposed) [1.3.0-2]
[14:55] -queuebot:#ubuntu-release- New: accepted libedlib [amd64] (disco-proposed) [1.2.3-3]
[14:55] -queuebot:#ubuntu-release- New: accepted neutron-vpnaas-dashboard [amd64] (disco-proposed) [1.4.0-1]
[14:55] -queuebot:#ubuntu-release- New: accepted gau2grid [arm64] (disco-proposed) [1.3.0-2]
[14:55] -queuebot:#ubuntu-release- New: accepted gau2grid [s390x] (disco-proposed) [1.3.0-2]
[14:55] -queuebot:#ubuntu-release- New: accepted gau2grid [i386] (disco-proposed) [1.3.0-2]
[14:55] -queuebot:#ubuntu-release- New: accepted libedlib [i386] (disco-proposed) [1.2.3-3]
[15:45] -queuebot:#ubuntu-release- New binary: racon [amd64] (disco-proposed/universe) [1.3.1-1] (no packageset)
[19:09] -queuebot:#ubuntu-release- New: accepted racon [amd64] (disco-proposed) [1.3.1-1]
[23:22] -queuebot:#ubuntu-release- New binary: kamcli [amd64] (disco-proposed/universe) [1.1.0-2] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: pcc [amd64] (disco-proposed/universe) [1.2.0~DEVEL+20181202-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: pcc [i386] (disco-proposed/universe) [1.2.0~DEVEL+20181202-1] (no packageset)


[00:03] <penguin42> dtchen: I triggered it on the proposed kernel on a host with just 3 totem-xine's running
[00:04] <penguin42> dtchen: And that's with the resample trivial and default-fragment-size-msec = 5
[00:05] <dtchen> penguin42: ok.
[00:05] <dtchen> i have no love for realtek or sigmatel/idt
[00:06] <penguin42> anything else you want me to try while I'm here
[00:06] <dtchen> not unless you can compile gst-plugins-good from git head
[00:06] <penguin42> sure - point me at the sources
[00:07] <penguin42> although given xine's triggering it do you think that's relavent?
[00:07]  * maco hides her sigmatel and realtek based laptops from dtchen in case he gets the mallet
[00:08] <dtchen> sure
[00:08] <dtchen> it's a linux bug, but i have no idea [yet] why none of the conexants seem to be dropping
[00:09] <dtchen> i suppose i can ask for the changes to be reverted, but we're going to break some percentage of people
[00:09] <penguin42> dtchen: What's the symptoms they see?
[00:10] <dtchen> what you're seeing
[00:10] <penguin42> oh I see so we have a choice in breaking one or the other of us?
[00:10] <dtchen> of course, that's always how it works
[00:17] <penguin42> dtchen: The git from here: http://cgit.freedesktop.org/gstreamer/gst-plugins-good   ?
[00:19] <dtchen> penguin42: yes, but hold off on that
[00:19] <penguin42> oh, I've got it cloning anyway
[00:23] <penguin42> dtchen: My xine config says it's set for esd - although pactl list seems to show ALSA plugin
[00:37] <penguin42> dtchen: I'm going to bed in a few minutes, if there are any tests you can think of you want me to try just mail me at<EMAIL_ADDRESS>- although I very rarely do stuff during the week so it's a lot easier if I get something tomorrow if you want a quick answer
[00:47] <bcurtiswx> hey all, anyone know why jaunty wouldn't know how to handle media from a CD drive and halt the system
[00:48] <bcurtiswx> am i missing a library?
[00:48] <penguin42> ?
[00:48] <penguin42> what happens when you halt?
[00:48] <bcurtiswx> the system doesn't work
[00:48] <bcurtiswx> i move mouse to no avail
[00:48] <ror> bcurtiswx: does this happen with all discs? (could be a bad disc)
[00:48] <bcurtiswx> i can open and close my cd drive
[00:49] <bcurtiswx> ror: all disks
[00:49] <bcurtiswx> discs*
[00:49] <ror> and your system is fine up until the point where you put in a CD?
[00:49] <bcurtiswx> yup
[00:50] <penguin42> What did you install from?
[00:50] <bcurtiswx> i've tried data cd's, audio cd's, video DVD's,
[00:50] <ror> sounds very strange
[00:50] <bcurtiswx> i installed Jaunty i386 desktop
[00:50] <penguin42> from CD?
[00:50] <ror> next time it happens, try pressing ctrl+alt+F1
[00:50] <ror> that'll get you to a terminal at least
[00:50] <bcurtiswx> yup
[00:50] <bcurtiswx> live CD
[00:50] <bcurtiswx> even did a integrity check
[00:50] <ror> and try to take a copy of your /var/log/xorg.1.log (I think?)
[00:51] <ror> ah OK, I don't know much about live CDs so I'll shut up now :)
[00:51] <bcurtiswx> i've had this problem before (in Intrepid) and i installed some package and everything i put into the drive worked again
[00:51] <migbuntu> dtchen: i have the qosmio F50, we spoke a few hours ago.....
[00:51] <migbuntu> since i executed those comands the max sound decrease alote...
[00:51] <migbuntu> i have already checked the volume and is everything in max... i think it was the comands you told to execute...
[00:51] <migbuntu> i just wanted the subwoofer sound and now i barely can hear the front speakers sound...
[00:51] <migbuntu> is there anything i can do?
[00:51] <migbuntu> is there anyone how can help me?
[00:52] <ror> bcurtiswx, you'd probably be better off asking the main #ubuntu channel for support really
[00:53] <migbuntu> i did report the problem here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/374166
[00:53] <ubot4`> Launchpad bug 374166 in linux "HDA intel integrated subwoofer doesnt work" [Undecided,Incomplete]
[00:53] <dtchen> migbuntu: which commands?
[00:54] <migbuntu> dtchen:  the comands you told to.... the max sound decreased...
[00:54] <dtchen> which commands?
[00:55] <dtchen> ah
[00:55] <dtchen> you can sudo rm /etc/modprobe.d/sound.conf
[00:55] <dtchen> then, sudo /sbin/alsa force-reload
[00:55] <dtchen> anyhow, i'm out for an hour
[00:56] <penguin42> dtchen: Thanks for your help
[00:56] <migbuntu> dtchen: echo options snd-hda-intel model=toshiba-rx1|sudo tee -a /etc/modprobe.d/sound.conf
[00:56] <migbuntu> awk -F, '{print $1}' /sys/module/snd_hda_intel/parameters/model
[00:56] <migbuntu> sudo /sbin/alsa force-reload
[00:57] <migbuntu> dtchen: yes that one chould work... should i remove ....sound.conf???
[00:57] <migbuntu> dtchen: thanks once again....
[01:01] <migbuntu> i will restart my ubuntu... and tell if it will work...
[01:16] <sk8ingdom> I'm not sure if this is the correct place for this, but I have a problem I can't seem to find online. I have currently have two separate video cards working in jaunty each with their own x server. The problem is that when I use the menu on the right x server, it automatically opens programs on the left x server, thus rendering it useless.
[01:23] <migbuntu> it worked the sound level just is normal again... the subwoofer sound is the only thing missing... ill just wait for the solution...
[02:52] <bcurtiswx> ugh, i wish general users weren't able to change status messages in bugs
[02:53] <bcurtiswx> seems semi-rare (not too rare) that users will move their bugs off of triaged or incomplete to some random status they think is more appropriate
[03:13] <hggdh> yes, that happens... So we move it back to the correct status, and (ideally) used the occasion to tell them why we did it... part of the game, I guess
[05:18] <J_Wesker> hi I need an advice about a problem with Ubuntu
[05:19] <micahg> J_Wesker: this channel is for bug triaging, please try #ubuntu for support
[05:20] <J_Wesker> ok thanks
[07:01] <Hew> Don't you love it when you double-click a .crash file to report it, but instead apport itself crashes and produces its own .crash file? :-)
[07:03] <Hellow> XD
[07:20] <G__81> hi everyone
[10:13] <BioGuyver> Hi All, I think I have found a bug in the Server installation for raid disks but I would like to ask someone about it and find out more.
[10:13] <BioGuyver> Is here a good place?
[10:23] <Hew> BioGuyver: Possibly #ubuntu-server. Filing a bug report on the issue is probably the best first step, then it can be investigated/triaged.
[10:24] <BioGuyver> thanks
[10:25] <andol> BioGuyver: Checking existing bugs might also be a good idea.
[10:26] <BioGuyver> andol: Where is the best place to do this?
[10:28] <andol> BioGuyver: My best guess would be in the debian-installer and mdadm
[10:28] <andol> https://bugs.launchpad.net/ubuntu/+source/debian-installer
[10:28] <andol> https://bugs.launchpad.net/ubuntu/+source/mdadm
[10:29] <andol> Well, the second part (mdadm) kind of assumes software raid, which I'm not sure if you are refering to.
[10:29] <BioGuyver> it is software raid and mdadm so that looks good
[10:29] <BioGuyver> I'll have a poke around in there now.Thanks
[12:00] <BUGabundo> I can't file a bug on apport with apport
[12:00] <BUGabundo> grrr
[12:12] <dwg> gah
[12:14] <dwg> infuriating intel driver X bug
[12:14] <dwg> 374431
[12:16] <askand> I was just about to ask about intelbug too, but bug 349992
[12:16] <ubot4> Launchpad bug 349992 in xserver-xorg-video-intel "[i945 tiling] (Needs kernel 2.6.30-rc3) Low performance due to no A17 workaround" [High,Fix released] https://launchpad.net/bugs/349992
[12:16] <askand> It is marked as fix released because of 2.6.30 kernel now in karmic. However I strongly think this bug should be fixed in Jaunty aswell?
[12:25] <Hobbsee> askand: it probably won't be - uxa isn't the default, fortunately
[12:26] <Hobbsee> so it only affects those who specifically turn it on, and I can't imagine they'd backport the patches in such a case
[12:26] <Hobbsee> due to risk and such
[12:29] <Hobbsee> (afaik)
[12:59] <askand> Hobbsee: Bad intelperformance affects people who don't turn uxa on too. This man writes a good conclusion on the problem http://beranger.org/v3/wordpress/2009/05/04/jaunty-kernel-2630-fixes-the-intel-video/
[12:59] <askand> And he is using EXA
[13:01] <Hobbsee> hrm, i hadn't noticed it being that bad.
[13:04] <askand> Hobbsee: I think it depends on the card too, on my intellaptop it is barely usable
[13:05] <askand> Phoronix have an interesting article to how "Intel Linux Driver Kills The Netbook Experience" http://www.phoronix.com/scan.php?page=news_item&px=NzIyMA
[13:05] <Hobbsee> this is where i start to think apple has the right idea
[13:05] <Hobbsee> only run it on a specific subset of hardware, and then you can be certain it all runs, all the time
[13:06] <Hobbsee> rather than the whole "this affects some people, but not others, with seemingly the same hardware"
[13:07] <askand> Hobbsee: Indeed, but haven't you noticed any signs of bad preformance in Jaunty compared to Intrepid?
[13:07] <Hobbsee> askand: hrmm.  A couple - big pictures in firefox taking a few seconds to load, occasionally.  My video performance is streets ahead in jaunty.  Not sure on shredder, seeing as that's not official
[13:08] <Hobbsee> compiz is a little less snappy, perhaps
[13:08] <Hobbsee> in alt+tab
[13:08] <Hobbsee> otherwise, graphics-wise, no
[13:08] <Hobbsee> (standard dell 6400)
[13:09] <Hobbsee> 908 frames in 5.0 seconds = 181.448 FPS
[13:09] <Hobbsee> 964 frames in 5.0 seconds = 192.798 FPS
[13:10] <Hobbsee> hrm, which is apparently low
[13:10] <Hobbsee> apparently i don't run the highly graphics things
[13:12] <askand> Perhaps the bad performance is more noticable on already bad cards, I wouldn't think it's a very good card in my Asus EEE PC for example
[13:12] <Hobbsee> oh, i'd expect so
[13:12] <Hobbsee> (do they even have the 945gm's?)
[13:13] <Hobbsee> i'm just hoping ekiga or twinkle suddenly starts working again
[13:13] <Hobbsee> although others don't seem to have problems
[13:14] <askand> No, it's 915 in them I think, ekiga however works fine for me
[13:19] <Hobbsee> yeah, i know it works for everyone else.  It just doens't like me :-S
[13:19] <Hobbsee> didn't test intrepid's version, so it'll be interesting to see how jaunty's goes.
[13:26] <lifeless> Hobbsee:  you know the deal; you want it to work....do thyself
[13:27] <Hobbsee> lifeless: i've never been able to track down why it doesn't work.  But yes, i'll likely end up trying that route again
[13:27] <lifeless> the voip protocols are amazingly silly
[13:27] <Hobbsee> heh, indeed.
[13:27] <Hobbsee> actually, iirc, it was more a problem with my mic going nuts.
[13:27] <Hobbsee> or maybe that was the previous time
[13:28] <Hobbsee> no, this time, it was that it wouldn't even connect.  that's right
[13:28] <Hobbsee> will have to try again :)
[14:50] <bencrisford1> what command would give the name of a disk drive/burner?
[14:50] <bencrisford1> i couldnt see mine in lspci
[14:51] <penguin42> it's not in lspci because it's not directly connected to PCI
[14:51] <Nafallo> the name as in?
[14:52] <bencrisford1> like you get from an lspci for other hardware
[14:52] <bencrisford1> penguin42: what command would I run then?
[14:53] <penguin42> waht do you want the device like /dev/splat or do you want a name like 'Acme Drivemakers'
[14:53] <bencrisford1> basically someone has reported a bug to do with disk burning
[14:54] <bencrisford1> i was gonna tell them how to post their hardware name
[14:54] <bencrisford1> because it could be useful for develoeprs
[14:55] <bencrisford1> g2g, i posted what i knew
[14:55] <bencrisford1> bye
[18:02] <maxb> So.... anyone have any idea how I'd file a useful bug on "Audio is crackly from DVDs only?"
[18:03] <penguin42> only from DVDs?? No other audio playback - say rhythmbox?
[18:05] <maxb> Oddly, .mp3s play fine
[18:06] <maxb> even when playing in the same software as the DVDs which don't
[18:06] <penguin42> it might depend on CPU loading
[18:06] <maxb> also, the same problem occurs playing the DVDs in either totem or mplayer
[18:06] <maxb> hmm... possibility
[18:06] <penguin42> maxb: You might have this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/345627
[18:06] <ubot4> Launchpad bug 345627 in linux "Crackling / scratching noise using Pulseaudio" [Medium,Fix committed]
[18:07] <maxb> hmm
[18:07] <maxb> though that bug is targetted at jaunty
[18:08] <penguin42> what you on?
[18:08] <maxb> And my problem only started after upgrading to karmic
[18:08] <penguin42> ah ok
[19:10] <chaos2fu> are there someone here that are currently running ubuntu netbook remix and can help me to get the panels and the menus back in place?
[19:36] <elena09> hello
[19:36] <micahg> greetings
[19:36] <elena09> hibernate bug
[19:36] <elena09> at my tower
[19:49] <elena09> can't exit from Hibernate, lots of numbers repeating on the screen, indefinetely, after I moved the mouse
[19:51] <nellery_> elena09: please read https://help.ubuntu.com/community/ReportingBugs for reporting bugs
[19:52] <elena09> I thought you knew about that...
[21:21] <bcurtiswx> anyone know what mounts CD and DVD media in Jaunty?
[21:21] <BUGabundo> bcurtiswx: humm #ubuntu ?
[21:21] <bcurtiswx> im being ignored
[21:22] <bcurtiswx> one person said "its automatic"
[21:22] <bcurtiswx> thanks.. sherlock
[21:23] <BUGabundo> eheeh
[21:23] <BUGabundo> I guess nothing...
[21:23] <BUGabundo> you don't auto mount cds
[21:23] <BUGabundo> fstab should have a rule for it
[21:23] <BUGabundo> and the filemanager should have access to it
[21:23] <bcurtiswx> anything i insert into my cd/dvd drive ubuntu freezes
[21:23] <bcurtiswx> im just trying to find the culprit
[21:23] <bencrisford1> bcurtiswx: try typing mount into terminal
[21:23] <BUGabundo> if it is a media disc, then some apps can autostart
[21:25] <bcurtiswx> its probably just in need of a new drive... which sucks
[21:26] <bencrisford1> did typing 'mount' not work bcurtiswx?
[21:26] <bcurtiswx> it worked, but it just shows me what is mounted
[21:27] <bcurtiswx> brb
[21:28] <bencrisford1> oh
[21:31] <BUGabundo> dtchen: come on.... tell themuso that log scales is a bad thing!! lower then 60% is equal to MUTE
[21:33] <bcurtiswx> what dvd drives work best with ubuntu?
[21:34] <BUGabundo> heheh
[21:34] <BUGabundo> which one don't?
[21:35] <bcurtiswx> mine
[21:35] <bcurtiswx> Optiarc DVD RW AD-7173A
[21:36] <BUGabundo> ROFL
[21:38] <bcurtiswx> it causes ubuntu to freeze anytime i insert something into it
[21:39] <BUGabundo> bcurtiswx: could be a bad drive and causing kernel panic
[21:40] <BUGabundo> I've seen that with other devices
[21:40] <bcurtiswx> which is why im probably going to replace it
[21:40] <bcurtiswx> hance my question "which ones work best"
[21:40] <bcurtiswx> hence*
[21:40] <BUGabundo> any !
[21:43] <bcurtiswx> <looks for the "any" brand DVD drive> :P
[21:44] <BUGabundo> eheh
[21:44] <BUGabundo> any cheap but relliable
[22:43] <dtchen> BUGabundo: do you really expect upstream to agree? you might want to raise it there.
[22:44] <BUGabundo> dtchen: heh thanks for the input!
[22:45] <BUGabundo> dtchen: I do agree log is better then linear. but it's a diff use case and many users will find it hard to use (at beiggining)
[22:46] <dtchen> yeah, well, people are going to scream bloody murder at everything in karmic, then
[22:46] <scream> .
[22:47] <BUGabundo> dtchen: eheh here is mine THIS SUCKSSSS ehehe
[22:48] <BUGabundo> dtchen: if I lower to ~65% its MUTE, its no use for me
[22:48] <BUGabundo> and even at 100% its lower then ibex was
[22:48] <dtchen> that's a driver issue unless you can reproduce it w/o pa
[22:49] <BUGabundo> I can try removing auto spawn and try OSS or alsa to be sure
[22:49] <dtchen> i'm probably going to have to tag 345627 verification failed :(
[22:49] <BUGabundo> bug 345627
[22:49] <ubot4> Launchpad bug 345627 in linux "Crackling / scratching noise using Pulseaudio" [Medium,Fix committed] https://launchpad.net/bugs/345627
[22:50] <BUGabundo> dtchen: no true
[22:50] <BUGabundo> it *works* for some users
[22:50] <BUGabundo> lol
[22:50] <dtchen> yes, but it's known-broken for some users in 11.42 and introduces a regression for others in 12.43
[22:51] <dtchen> it's better to have known breakage than to introduce new regressions
[22:51] <BUGabundo> dtchen: be glad to only have 2 dupes and so few comments
[22:51] <dtchen> well, the problem is that this bug touches the _entire_ audio stack
[22:51] <BUGabundo> I guess you will have to have a spare kernel for those affected to whom a special kernel fixes it
[22:51] <dtchen> from the hardware+bios, linux, alsa-lib, pulseaudio, alsa-plugins, and apps
[22:51] <BUGabundo> like the one before release
[22:55] <dtchen> yeah, but that's a lot of overhead for me
[22:55] <dtchen> more importantly, people using such a kernel will not get support
[23:09] <BUGabundo> humm https://edge.launchpad.net/~ubuntuone-users is 404 duh


[03:00] <barry> #startmeeting
[03:00] <thumper> hi
[03:01]  * thumper just remembered
[03:01] <thumper> mwhudson just said he was lunching, so he may be around
[03:01] <barry> hmm.  seems like mootbot is dead.  guess we'll have to kick this oldschool
[03:01] <thumper> jml won't be with us today
[03:01] <barry> ok
[03:01] <barry> who else is here today?
[03:01] <thumper> spiv, jamesh: ping
[03:01] <thumper> barry: it'll be quick if just us
[03:02] <barry> indeed!  fine with me :)
[03:02] <barry> shall we wait a minute to see if anybody else shows up?
[03:02] <thumper> nah, lets go
[03:02] <barry> rock on
[03:02] <barry> next meeting?
[03:03] <thumper> now + 1 week
[03:03] <barry> works for me
[03:03] <thumper> next week I'll have mwhudson and jml in the same room as me
[03:03] <barry> sprinting?
[03:03] <thumper> yep
[03:03] <barry> cool, on code hosting?
[03:03] <thumper> with rockstar_ and abenley too
[03:03] <thumper> uh ha
[03:04] <barry> great!  where are you sprinting?
[03:04] <thumper> Dunedin, NZ
[03:04] <barry> oh, i bet that will be fun!
[03:04] <thumper> my town :-)
[03:04] <barry> :)
[03:04] <barry> cool... action items
[03:04] <barry>  * (continued) thumper to report on pending-reviews killer in LP
[03:04] <barry> :)
[03:04] <thumper> I did think about it
[03:04] <mwhudson> hi
[03:04] <thumper> but not yet written anything
[03:04] <thumper> on the plus side
[03:04] <barry> mwhudson: hi
[03:04] <thumper> we are making good progress on the review stuff
[03:05] <barry> very cool.  i'm looking forward to being able to do reviews in lp
[03:05] <mwhudson> sorry for being late
[03:05] <barry> there were two action items from ameu i think
[03:05] <barry> mwhudson: no problem
[03:06] <barry>  * barry drive to decision about multiline sequences
[03:06] <barry> i haven't written about that but i will before the ameu meeting
[03:06] <barry>  * we should all chip in and watch for lpreview plugin bugs
[03:06] <barry> i think that was a plea for all reviewers to help chip in to fix bugs in lpreviews
[03:06] <mwhudson> there was something about getting it added to sourcecode
[03:07] <barry> mwhudson: right, i don't know where that is, but i'll ask gmb on wednesday
[03:07] <barry> mwhudson: also, gmb's got this A/I:  * gmb to prod mwh again about the 800-line limit patch
[03:07] <mwhudson> i have this vague recollection of it failing because of a bzr bug, but it's very vauge
[03:07] <mwhudson> i don't think i've been prodded again
[03:07] <thumper> I don't want a hard limit enfoced by the plugin
[03:07] <thumper> that'd just annoy me
[03:08] <thumper> s/enfoced/enforced/
[03:08] <barry> thumper: there will definitely be an override
[03:08] <mwhudson> but yeah, what thumper said
[03:08] <barry> or maybe it'll just publicly shame you instead
[03:09] <barry> anyway.  i'm sure you and he can work that out :)
[03:09] <mwhudson> yeah
[03:09] <barry>  * Queue status
[03:09] <thumper> nice and pink
[03:10] <barry> i see jamesh still has our favorite at the #1 spot!
[03:10] <mwhudson> most of those branches are merged it seems
[03:10]  * barry forgot he's got to review allenap's branch
[03:10] <thumper> well, half
[03:10] <barry> yep.  good to see people taking the admonition to delete their reviewed branches to heart
[03:11] <barry> (he ways as an offender :)
[03:11] <barry> er, says
[03:11] <barry> any comments on the queue from you guys?
[03:12] <mwhudson> i think it's clear that when we do queue management in lp
[03:12] <mwhudson> we need to mark branches as merged automagically
[03:12] <thumper> mwhudson: my magic pqm bit will do that
[03:12] <thumper> mwhudson: but yes, agreed
[03:13] <barry> yes definitely
[03:13] <barry> we'll skip mentoring update
[03:14] <barry>  * Review process
[03:14] <barry>    * How to manage workload of reviewing (intellectronica, sinzui? gmb?)
[03:14] <barry> tho they're not here to defend themselves :)
[03:14] <mwhudson> move to australasia :)
[03:14] <Hobbsee> (mootbot probably won't be here anytime soon)
[03:14] <barry> Hobbsee: is mootbot moot?
[03:14] <Hobbsee> barry: something like that.
[03:14] <mwhudson> oh right, ubuntu irc drama
[03:15]  * barry was getting to like that little bot
[03:15] <barry> mwhudson: what that mean?
[03:15] <Hobbsee> mwhudson: yeah, that.
[03:15]  * thumper must have missed the drama
[03:15]  * barry too
[03:15] <Hobbsee> barry: things finally went kaboom.  ask me in #launchpad if you really want to know
[03:15] <mwhudson> uh, not sure what a good reference would be
[03:16] <mwhudson> there was a toy-throwing-out-of-pram incident
[03:16] <mwhudson> with the guy who runs/ran all the ubuntu bots
[03:16] <barry> prams are baby carriages right? :)
[03:16] <mwhudson> barry: yes
[03:16] <thumper> barry: right
[03:16] <barry> i think i get the picture!
[03:16] <barry> sigh
[03:16] <barry> anyway, moving on?
[03:17] <thumper> yeah
[03:17] <Hobbsee> barry: freenode decided to give trolls more rights than regular people, and allowed them to roam freely on the network, ignoring anything anyone else said.  oddly enough, people got sick of it.
[03:17] <Hobbsee> but yes, moving on.
[03:17] <barry> * comparing strings with `is` (stevea)
[03:17] <barry>    * overly broad `KeyError`s (stevea)
[03:18] <barry> these were two things stevea wanted me to bring up, though i'm sure y'all know about them
[03:18] <mwhudson> uh, comparing strings with is should be a shooting offense already
[03:18] <barry> he was reviewing a branch that had already been reviewed (for an rc i think) and noticed
[03:18] <barry> mwhudson: agreed!  i'm mildly surprised that got past a dev, but really suprised that got past a reviewer
[03:18] <thumper> barry: as in "foo is 'bob'" ?
[03:19] <barry> thumper: if foo is 'blah':
[03:19] <barry> yeah
[03:19] <thumper> barry: eww
[03:19] <thumper> ok, KeyError?
[03:19] <barry> so SteveA just wanted me to remind reviewers to catch those things :)
[03:19] <mwhudson> is there anything deep behind 'overly broad keyerror' ?
[03:19] <thumper> be specific, make a new exception thing?
[03:19] <barry> the keyerror one was a case where there was too much code in the try part
[03:20] <mwhudson> or is that "don't put too much code in ...
[03:20] <mwhudson> heh
[03:20] <barry> so that it wasn't clear which piece of code the keyerror was trying to catch
[03:20] <thumper> ok
[03:20] <barry> mwhudson: yep, the latter
[03:20] <mwhudson> k
[03:20] <barry> i.e. use a try/except/else or put the code after the try/except
[03:20] <barry> you guys get it
[03:21] <mwhudson> um
[03:21] <mwhudson> * How to manage workload of reviewing (intellectronica, sinzui? gmb?)
[03:21] <mwhudson> kind of got dropped
[03:21] <thumper> I guess I've sidestepped this
[03:21] <thumper> as it was brought up that team leads shouldn't do on-call reviewing
[03:22] <thumper> however I do still do reviews on request
[03:22] <thumper> and have been doing a number for abentley
[03:22] <thumper> and will do some for rockstar_
[03:22] <barry> mwhudson: i'm not sure exactly what intellectronica, et al wanted to say about that
[03:22] <mwhudson> fair enough
[03:22] <thumper> barry: I think it was that 20% seemed like a lot of time
[03:23] <barry> yeah.  in foundations we actually calculate you'll only spend 60% of your time actually coding per week
[03:23] <thumper> ha
[03:23] <thumper> if that high
[03:23] <barry> figuring a day for reviewing and a day for bullsh*t like email
[03:23] <barry> thumper: yeah, and team leads probably even less
[03:23]  * thumper smiles
[03:23]  * barry feels for flacoste
[03:24] <mwhudson> i think you can argue that reviewing is more important than your own coding tasks
[03:24] <thumper> yeah, I do
[03:24] <mwhudson> (there's more investment, and someone else is waiting on you)
[03:24] <thumper> also you learn by reviewing
[03:24] <barry> mwhudson: yep, definitely.  but it's human nature to feel like you're slacking on your other work too though
[03:24] <mwhudson> more realistic planning plz
[03:25] <thumper> barry: I understand that
[03:25] <thumper> part could be mitigated by having people realise the 60% thing more though
[03:25] <mwhudson> (this relates to the pqm/rc gripe thread)
[03:25] <thumper> so they don't expect to code 8hours a day
[03:25] <barry> mwhudson: we had an interesting experiment with planning poker for 1.2.4.  preliminary results indicate we under-estimate u/i work and over-estimate backend work
[03:25] <thumper> this does come back to the "heap of work" and "forced march" feel
[03:26] <barry> yep
[03:26] <thumper> barry: I agree with that
[03:26] <barry> we really need to find a way to avoid that
[03:26] <thumper> barry: I find that U/I work always takes ages
[03:26] <mwhudson> barry: interesting
[03:26] <thumper> barry: like the branch to redo project branches took about 4 days elapsed
[03:26] <barry> thumper: indeed, it's even worse if you have to grovel around in javascript
[03:27] <thumper> you think it is simple but then it is just a time sink
[03:27] <thumper> . o O (hmm.. two more pixels to the left I think..)
[03:27] <barry> thumper: in my experience, nothing's changed.  it was that way with u/i crap 20 years ago
[03:28] <mwhudson> i guess my summary is
[03:28] <thumper> ha, I realised the other day that I've had almost 20 years of professional programmign now :-(
[03:28] <thumper> and I still can't type
[03:28] <mwhudson> if you have too much 'real work' to do reviews, you have too much 'real work'
[03:28] <thumper> mwhudson: +1
[03:29] <barry> mwhudson: +1
[03:29] <mwhudson> i guess we need to make sure the reviewing is spread around fairly though
[03:29] <mwhudson> i guess you could gather some stats on that
[03:30] <thumper> we used to record number of hours a week doing reviews
[03:30] <thumper> how about we reinstate that somehow
[03:30] <barry> thumper: i still record that
[03:30] <thumper> ah, ok
[03:30] <mwhudson> i've always been rubbish at that
[03:30] <barry> but yeah, we don't collate that anymore.  otoh, after my ocr, i'm really unmotivated to do reviews (well, that aren't follow ons)
[03:32] <barry> any way, got anything else for me?
[03:32] <mwhudson> anyway, i guess we should see what the people who proposed the topic have to say
[03:32] <thumper> nothing from me
[03:32] <barry> mwhudson: yep, i'll summarize that after wednesday's meeting
[03:33] <barry> okay then...
[03:33] <barry> #endmeeting
[03:33] <barry> ha ha
[03:33] <barry> g'nite all!
[03:33] <mwhudson> bye & thanks
[03:34] <barry> thanks