[13:47] <spineau> Hello
[13:49] <ogasawara> spineau: hi, assuming you'll be in the hangout -> https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en
[13:49] <ogasawara> spineau: no hurry though
[13:50] <zyga> hi
[13:53] <ogasawara> ara: fyi https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en
[13:56] <ara> ogasawara, thanks
[14:01] <sfeole> hi
[14:05] <roadmr> hello! could someone please share the hangout link with me?
[14:06] <sfeole> roadmr: according to the url above it's : https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en
[14:06] <spineau> https://docs.google.com/drawings/d/1PayxVkGOICZXlaaq1Cln0FcMW2LfiJOF-jTmIm6x79Q/edit?usp=sharing
[14:07] <roadmr> sfeole: thanks!
[14:07] <sfeole> roadmr: the url in above the video
[14:07] <sfeole> :)
[14:49] <spineau> https://plainbox.readthedocs.org/en/latest/author/index.html
[14:58] <zyga> woot
[14:58] <zyga> great session spineau
[14:59] <roadmr> \o/
[14:59] <ara> ogasawara, feel free to end the broadcast
[14:59] <ara> spineau, thanks for the session!
[14:59] <ogasawara> ara: yep, done.  thanks
[14:59] <spineau> great session thanks everyone
[15:06] <cjwatson> Hangout URL?
[15:07] <KaleoF> same question
[15:09] <dbarth> lool: ping? if you're running the hg, can you make sure to send me the link and to zaspire as well for the cordova aspects
[15:10] <KaleoF> anybody listening? :)
[15:10] <dbarth> lool: and alex-abreu as well obviously
[15:11] <cjwatson> Hello?  The hangout URL should just be pasted into channel
[15:11] <cjwatson> Who's running this session?
[15:11] <lool> ??
[15:11] <cjwatson> ogasawara,slangasek: ^-
[15:11] <cjwatson> ?
[15:11] <KaleoF> nobody is running it it seems :)
[15:11] <lool> pmcgowan: are you running it?
[15:11] <ogasawara> yeek, is there a core 1 now, I thought we only had a core 2 session this slot
[15:12] <slangasek> ogasawara: someone stuck a non-core session in our track
[15:12] <lool> KaleoF: I'm happy to lead the discussion
[15:12] <cjwatson> ogasawara: it's on the appdev track but overflowing into a core "room"
[15:12] <pmcgowan> lool, sorry which?
[15:12] <pmcgowan> I am on another call
[15:12] <ogasawara> ah, my bad then
[15:12] <lool> pmcgowan: System framework for apps
[15:12] <slangasek> ogasawara: can you run it?  I have upstart roadmap right now
[15:12] <lool> KaleoF: let's take it
[15:12] <ogasawara> https://plus.google.com/hangouts/_/76cpiq0bih9a1oa0r2ojicncv4?authuser=0&hl=en
[15:12] <pmcgowan> lool, oh, sorry please carry o without me, I just logged the bp
[15:12] <ogasawara> slangasek: yep, firing up now
[15:13] <lool> KaleoF: joining?
[15:13] <lool> asac: joining?
[15:14] <lool> cjwatson: you joining?
[15:14] <cjwatson> yes, just cleaning up from firefighting
[15:14] <lool> sergiusens: you want to join?
[15:15] <KaleoF> https://plus.google.com/hangouts/_/76cpiq0bih9a1oa0r2ojicncv4?authuser=0&hl=en
[15:16]  * ogra_ is listening in
[15:28]  * ogra_ remembers that asac had an opinion aboout frameworks and support cycle too 
[15:29] <sergiusens> ogra_, yeah, that's what lool is saying without giving names ;-)
[15:29] <ogra_> ah
[15:29] <ogra_> heh
[15:30]  * ogra_ is getting distracted by IRC pings
[15:30] <lool> sergiusens: I did name asac!
[15:30] <ogra_> sorry
[15:40] <lool> err I have lost the hangout
[15:40] <lool> did I do anything wrong?
[15:42] <ogra_> i still see you
[15:42] <sergiusens> ogra_, he dropped off for a bit :-)
[15:43] <ogra_> ah
[15:47] <ogra_> lool, i think asac said he wanted to be able to support forever
[15:48]  * ogra_ doesnt see how thats tecnically possible ... but i know that was the desire
[15:49] <lool> ogra_: right, I passed that on into the hangout
[15:49] <ogra_> k
[15:49] <lool> but I expected, this is not an universally shared opinion
[15:49] <ogra_> yeah
[16:03] <ogasawara> https://plus.google.com/hangouts/_/7ecpj4qupqkej6sm9o4gmh48eo?authuser=0&hl=en
[16:03] <ogasawara> there doesn't appear to be a blueprint for this next session
[16:06] <satoris> The link should be live, please join. :)
[16:07] <lool> which packages is thi sabout?
[16:07] <nuclearbob> yes
[16:07] <satoris> Any.
[16:11] <doko> -fuse-ld=gold
[16:11] <lool> So isn't that solved by cross-compilation on x86?
[16:11] <lool> (the slowness of ARM)
[16:11] <jtaylor> dpkg-buildflags
[16:12] <doko> jtaylor, ?
[16:12] <jtaylor> DEB_MAINT_LDFLAGS_APPEND or something
[16:12] <jtaylor> assumes the package supports overriding them of course
[16:20] <jtaylor> but those are few extreme cases
[16:26] <jtaylor> doesn't it also go over the alternatives system?
[16:26] <jtaylor> hm no it doesn't
[16:27] <doko> jtaylor, maybe change the dpkg-buildflags default for LDFLAGS
[16:28] <doko> or upload a changed binutils to a ppa and use that one for test builds
[16:33] <jtaylor> for package build that should only be relevant if ccache is also enabled, normally compilation dwarfs the time spent in make
[16:33] <doko> DEB_BUILD_OPTIONS=parallel=8
[16:35] <jtaylor> there are examples for parsing it in the policy
[16:38] <jtaylor> you can share the cache between buildd
[16:38] <jtaylor> its useful for the stable CI tests, where the compiler doe not change often
[16:39] <jtaylor> not for ubuntu+1 main archivee builds
[16:39] <doko> jtaylor, sure? at least it's something which currently is not supported
[16:40] <jtaylor> the manpage states it as supported to share cache
[16:40] <jtaylor> never tried it
[16:42] <jtaylor> its even more significant if autoreconf is used, thats even slower than configure
[16:43] <doko> sure, then just start multiple buildds on one machine
[16:44] <jtaylor> documentation builds are also mostly single process
[16:44] <jtaylor> e.g. all the python doc builds
[16:47] <jtaylor> can'T load on buildds be used to get a statistic?
[16:47] <jtaylor> if only one job is run per buildd
[16:53] <satoris> ogasawara: feel free to close down the stream now. Thanks.
[17:57] <ogasawara> for anyone interested https://plus.google.com/hangouts/_/7ecpj63sbfnc04m21g2t72g88k?authuser=0&hl=en
[18:00] <sforshee> ogasawara: fyi I've already closed bug #1247784. It's already enabled in trusty, the bug was just complaining about it not being enabled in the mainline builds.
[18:00] <udsbotu> Ubuntu bug 1247784 in linux (Debian) "please enable CONFIG_RT2800USB_RT3573 in kernel 3.12" [Unknown,New] https://launchpad.net/bugs/1247784
[18:01] <ogasawara> sforshee: awesome, thanks
[18:02] <ogasawara> for any late joiners -> https://plus.google.com/hangouts/_/7ecpj63sbfnc04m21g2t72g88k?authuser=0&hl=en
[18:14] <dannf> +1 no gray area. that's not necessarily a +1 for either version though.
[18:15] <ogasawara> https://wiki.ubuntu.com/KernelTeam/Specs/TrustyKernelDeltaReview
[18:15] <dannf> just makes it easier for me to talk to partners by saying "use this versin" or "we will make a decision at this time"
[18:15] <dannf> (where "this time" is a specific date/milestone)
[18:17] <bunubunu> show
[18:21] <smb> minus probably the pieces of imsm as you (just for me ) said
[18:21] <jtaylor> will enabling transparent anonymous huge pages by default be considered for 14.04?
[18:21] <jtaylor> currently its only madvise
[18:22] <sforshee> ext4 should be able to mount ext[23], right?
[18:22] <apw> sforshee, yeah hsould be, and that is the point of the request
[18:22] <infinity> sforshee: I like this theory.
[18:22] <cking> sforshee, we need to benchmark it and see how well it performs
[18:22] <infinity> I have lots of ext3 and ext2 around so...
[18:25]  * cking up to check it out
[18:25] <arges-uds> keep up the good work everybody
[18:26] <arges-uds> : )
[18:27] <jtaylor> :(
[18:30] <cking> it's a wrap
[18:33] <apw> jtaylor, hey sorry your Q had scrolled off the top of my window, so we missed it.  feel free to come over to #ubuntu-kernel and make a case -- we don't stand on ceremony much
[18:37] <ogasawara> jtaylor: yeek, sorry we missed that
[18:38] <ogasawara> jtaylor: ogasawara@sharkbay:~/ubuntu-trusty/debian.master/config$ grep -rn "TRANSPARENT_HUGEPAGE" *
[18:38] <ogasawara> config.common.ubuntu:2170:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
[18:38] <ogasawara> config.common.ubuntu:6143:CONFIG_TRANSPARENT_HUGEPAGE=y
[18:38] <ogasawara> jtaylor: ^^ although I'm seeing that enabled in trusty
[18:38] <jtaylor> < moving to -kernel
[18:58] <janimo> slangasek, hi, who is setting up the next hangout?
[18:58] <slangasek> janimo: bdmurray is
[18:58] <slangasek> for core1
[18:58] <janimo> thanks
[19:03] <rsalveti> hangout link?
[19:04]  * ogra_ twiddles thumbs
[19:04] <bdmurray> ocsOBsEp4
[19:04] <rsalveti> bdmurray: ? :-)
[19:04] <ogra_> secret language
[19:04] <bdmurray> http://youtu.be/4-ocsOBsEp4
[19:04] <ogra_> keeps the NSA out
[19:04] <ogra_> :)
[19:04] <tvoss_> slangasek, can you join the go session on the hangout?
[19:04] <rsalveti> right, I want the hangout one :-)
[19:05] <ogra_> yeah
[19:05] <rsalveti> but thanks anyway
[19:05] <slangasek> tvoss_: hum, I'm running a separate call
[19:05] <tvoss_> slangasek, okay
[19:05] <sergiusens> tvoss_, was the go session moved btw?
[19:05] <tvoss_> sergiusens, nope
[19:05] <cjwatson> the hangout URL isn't super-secret (unlike previous UDSes), should just be pasted here
[19:05] <rsalveti> sergiusens: that's in client-2
[19:05] <slangasek> tvoss_: if doko is around (i.e., not currently having network problems), he should be there
[19:05] <ogra_> sergiusens, don't go ... stay !
[19:05] <bdmurray> https://plus.google.com/hangouts/_/7acpja7ujvguc5nn4l8il5e2c4?authuser=0&hl=en <- this one then?
[19:05] <sergiusens> rsalveti, yeah, I'm just sad I have a conflict with this one now :-)
[19:06] <rsalveti> sergiusens: yeah :-(
[19:06] <cjwatson> ah, perfect
[19:06] <sergiusens> whereas I originally didn't see the conflict
[19:06] <sergiusens> so I was thinking one of these sessions was moved
[19:06] <cjwatson> (mind you I might just watch the youtube stream for now)
[19:06] <ogra_> janimo, ...
[19:06] <ogra_> janimo, your session ... join the hangout
[19:07] <rsalveti> bdmurray: thanks
[19:07] <bdmurray> yep, sorry about that
[19:12] <victorp> rsalveti: is it just question of flicking a compile flag or is there a more deep reason for it
[19:12] <victorp> i.e. x86 = desktop version and not optimise for mobile or something
[19:12] <achiang> is the streaming youtube broken for anyone else?
[19:12] <tsdgeos_uds> victorp: thing is, you can flip a switch and get either opengl or opengles, but not sure what you get is co-installable
[19:13] <victorp> achiang:wfm
[19:13] <achiang> (or just me :-/)
[19:13] <sarnold> achiang: wfm
[19:13] <tsdgeos_uds> victorp: speaking Qt-wise
[19:13] <victorp> tsdgeos_uds:fair enough
[19:13] <tvoss_> cjwatson, can you come to the go on the client side session?
[19:14] <rsalveti> victorp: yeah, that's why we only have gl for desktop and gles for armhf, just because it was the easier to support it
[19:14] <tsdgeos_uds> QUESTION can you guys confirm that, only GLES for Mir? somehow Gerry told me today that EGL+OpenGL should workt oo
[19:14] <tsdgeos_uds> on the desktop
[19:16] <xnox> yeah, a few projects use EGL api provided by OpenGL. (there are code tutorials online on how to do that)
[19:16] <xnox> (we do want GLES on the virtualbox / goldfish-emulators because GLES is accelerated)
[19:17] <alf_> tsdgeos_uds: Mir internally uses GLES2 for compositing etc, but clients are free to use either desktop GL or ES 1.0/2.0
[19:17] <tsdgeos_uds> alf_: ah, thanks :-)
[19:19] <victorp> janimo:do we know for sure that x86 android BSP provide GLES vs GL?
[19:20] <janimo> victorp, not sure what the emulator target provdes
[19:20] <janimo> AOSP 4.4 is GLES 2.0 by default, so I do not think plain GL is suppored
[19:20] <ogra_> since the emulator runs android i would expect it to be GLES
[19:21] <victorp> no one from AMD or Intel in the room? :)
[19:21] <ogra_> victorp, well, the mobile intel CPUs use PVR ... which means largely the same as maguro
[19:22] <ogra_> (galaxy nexus)
[19:22] <victorp> ogra_:good point
[19:22] <ogra_> (or pandaboard ...)
[19:22] <ogra_> and i would expect the emulator to emulate something along these lines ... so we shold be safe
[19:24] <achiang> so if android/x86 supports GLES... how does that relate to the open question about GL vs GLES backend for Qt?
[19:24] <achiang> janimo: rsalveti ogra_ ^^
[19:24] <ogra_> achiang, Qt on the desktop uses GL
[19:25] <ogra_> achiang, so there is an assumption that x86 == GL
[19:25] <achiang> ogra_: yes, i understand that
[19:25] <achiang> ogra_: but we want Qt + x86 + android to use GLES
[19:25] <achiang> right?
[19:25] <janimo> achiang, it means QT on x86 has to build for LES not GL s it does now
[19:25] <ogra_> achiang, while the assumption for Qt in touch is Qt == GLES
[19:25] <ogra_> achiang, we need QT on all arches to use GLES
[19:25] <achiang> vs Qt + x86 + desktop == GL
[19:25] <ogra_> there is no distinction
[19:26] <achiang> ogra_: ok, i missed the session yesterday. what did upstream say to that yesterday?
[19:26] <ogra_> no idea
[19:26] <achiang> or not upstream, but folks like scottK
[19:26] <ogra_> i had a session i ran that conflicted
[19:26] <xnox> we want qt with whichever GL that is accelerated.
[19:26] <victorp> rsalveti:is there an impact on libhybris
[19:26] <ogra_> achiang, well, no matter what ScottK said, there are vendors using Qt that will expect GL ... i.e. Skype as an example
[19:27] <xnox> most of the time it is GLES on armhf, and GL on intel.
[19:27] <xnox> but
[19:27] <janimo> achiang, it seemed it will be possible to build two sets of binaries for GL and GLES on x86
[19:27] <xnox> atom itel, virtualbox/android, goldfish/qemu are GLES accerated.
[19:27] <achiang> janimo: oh! ok, that solves our problems then
[19:27] <ogra_> right, we will have to maintain a fork
[19:27] <victorp> janimo: I think that is another one that would be good to build it and see what happends
[19:27] <ogra_> to have both
[19:27] <sergiusens> janimo, mute yourself :-)
[19:27] <xnox> it would be nice, if unity8 could use EGL with OpenGL, for convergence with desktop later on.
[19:27] <victorp> ogra - ah
[19:27] <sergiusens> your auto mute isn't working
[19:28] <victorp> ogra_ you dont think that upstream would have an interest on have Qt running on x86 android in the future?
[19:28] <ogra_> victorp, not with hybris
[19:28] <xnox> victorp: they have that now. but it's compile time option.
[19:28] <ogra_> hybris is considered a hack by most upstreams
[19:28] <victorp> xnox:right, so not really a fork
[19:29] <ogra_> victorp, no, but our maintenance burden
[19:29] <victorp> ogra_: or you meant a fork for hybris?
[19:29] <ogra_> victorp, we will need two sets of binaries
[19:29] <xnox> victorp: right, ti's just at the moment we will have duplicate binary packages, e.g. qt-gl qt-gles, etc.
[19:29] <victorp> xnox:ack
[19:29] <achiang> xnox: can we get that with the same source package/
[19:29] <achiang> ?
[19:29] <ogra_> and we need to maintain the second set
[19:29] <ogra_> achiang, yes
[19:29] <sarnold> hybris -felt- like a hack when I MIR reviewed it. I'd love to be rid of it.
[19:29] <xnox> achiang: should be possible. more maintainance burden, but yes.
[19:30] <achiang> ogra_: xnox: in the archive, or in a PPA somewhere?
[19:30] <xnox> victorp: achiang: but further down the line, it doesn't look like GLES is comming to desktop (but one vendor)
[19:30] <victorp> sarnold , realistically , we are very far from that
[19:30] <ogra_> sarnold, wont happen though :)
[19:30] <xnox> achiang: only in the archive.
[19:30] <ogra_> achiang, in the archive indeed
[19:30] <achiang> xnox: ok, that works for me,thanks
[19:30] <janimo> xnox, maybe less main burden if we do not want to apply all fixes to two sets of sourcs?
[19:30] <xnox> victorp: achiang: so one day we will need unity8 on top of OpenGL for normal powerful desktops/laptops.
[19:30] <ogra_> why would we put something we need tio support officially in a PPA
[19:31] <victorp> ogra_:so we dont think linhybris will be a problem porting to x86
[19:31] <ogra_> xnox, only if Mir supports that :)
[19:31] <victorp> rsalveti ^^
[19:31] <achiang> ogra_: well my question (about archive) was another way of asking, "is 2 binary packages an official solution"
[19:31] <xnox> can people assign some people to make mir/unity8 work on top of EGL powered by OpenGL ?
[19:31] <rsalveti> victorp: nops, should work (and afaik it was already tested with x86)
[19:31] <xnox> delaying that work, will only bite us later.
[19:32] <ogra_> xnox, how hard would it be to build the android package for x86 too ?
[19:32] <xnox> ogra_: i'll try that today.
[19:32] <xnox> ogra_: should be ok, unless something is not ported, then I'll come back with build failures.
[19:33] <ogra_> k
[19:33] <xnox> ogra_: rsalveti: package supports dynamically additional targets =)
[19:33] <rsalveti> xnox: right
[19:33] <achiang> ogra_: do we need a WI for actually publishing stuff on cdimage?
[19:33] <xnox> (it autogenerates install files et.al.)
[19:33] <ogra_> achiang, nahg
[19:33] <xnox> rsalveti: oh yeah, i want to do this with kitkat only =)
[19:33] <janimo> achiang, ogra_ we need WI for anything that has to be done imho
[19:34] <rsalveti> xnox: yeah
[19:34] <achiang> xnox: mmm... :-/
[19:34] <asac> rsalveti: you are right i think on not investing on 4.2 for x86. we want to focus on armel and do the x86 when brining up 4.4. in january or so
[19:34] <asac> armhf:)
[19:34] <victorp> rsalveti:that sounds reasonable, I guess x86 android support must have come a long way from 4.2 :)
[19:34] <rsalveti> victorp: yeah
[19:34] <rsalveti> asac: yup
[19:35] <xnox> rsalveti: ogra_: do we want x86-virtualbox, or x86-goldfish, or both?
[19:35] <ogra_> asac, well, depends how you look at it, android *is* armel ;)
[19:35] <ogra_> rootfs is armhf
[19:35] <asac> xnox: i assume goldfish if thats the thing that gives us SIM card emulation etc. :L)
[19:35] <xnox> asac: correct. goldfish is the same emulator as currently demoed used with armhf.
[19:35] <asac> ogra_: yeah i know... didnt replace... just add :)
[19:35] <asac> just kidding
[19:36] <ogra_> :)
[19:36] <asac> xnox: right. i believe we want that
[19:36] <xnox> asac: virtualbox is known to be much faster (native speed)
[19:36] <asac> if it comes for free then i dont mind. otherwise, lets first get the "right" thing done :)
[19:36] <xnox> rsalveti: asac: goldfish/x86 supposedly can do kvm speed.
[19:36] <xnox> but that's unknown.
[19:36] <rsalveti> right
[19:36] <xnox> ok,
[19:36] <asac> afaik google feels its super fast now
[19:36] <xnox> if virtualbox is removed, then goldfish only.
[19:36] <asac> so i wont worry too much :)
[19:38] <xnox> rsalveti: ogra_: by the way goldfish i386 kernel is in the linux-goldfish already.
[19:38] <ogra_> neat
[19:38] <xnox> ..
[19:39] <xnox> wow =) if gles finally comming to desktop, than that's great! But i don't think that's available on the desktop already.
[19:39] <ogra_> it should be
[19:39] <rsalveti> xnox: cool
[19:41] <xnox> rsalveti: hm, we are building "cm_goldfish-eng" at the moment, and there is no "cm_goldfish-x86-eng" target, only the google's "full-eng" / "full_x86-eng". So some enabled needs to be done.
[19:41] <xnox> at adding the device tree.
[19:41] <rsalveti> xnox: did you check 4.4?
[19:42] <xnox> janimo: =)
[19:42] <xnox> rsalveti: ah, not yet.
[19:42] <xnox> rsalveti: do we want to move to android's "full-eng" / "full_x86-eng" builds then?
[19:43] <rsalveti> xnox: probably
[19:43] <janimo> xnox, it is full-eng I thik indeed
[19:43] <xnox> rsalveti: the cm_goldfish target was easier at the time.
[19:43] <xnox> rsalveti: janimo: in that case I'll need to look into switching to that one.
[19:43] <xnox> (needs products tweaks, et. al.)
[19:46] <ogra_> bdmurray, you can stop the recording
[19:46] <ogra_> thanks :)
[19:46] <bdmurray> yep
[19:46] <xnox> janimo: rsalveti: yeah best to move to #ubuntu-touch.
[19:47] <xnox> =)
[19:47] <tsdgeos_uds> thanks for the session guys
[19:47] <psusi> crap, did I miss it?
[19:47] <tsdgeos_uds> rsalveti: lol the "i need to follow up with the qt folks" was cut :D
[19:47] <psusi> did yuo discuss the CONFIG_EXT[23]=n?
[19:49] <ogra_> psusi, it think thats not actually x86 emulator specific
[19:50] <ogra_> bring it up tomorrow, there is a general emulator session iirc
[19:50] <psusi> ogra: eh?  has nothing to do with emulation?
[19:50] <tyhicks> psusi: you're an hour late
[19:50] <ogra_> psusi, though i think we actually want to keep ext2 for performance reasons (the loop  mounted images are a lot faster with that)
[19:50] <tyhicks> psusi: the kernel topics session was an hour ago
[19:51] <ogra_> oh, kernel ...
[19:51] <psusi> ohh shoot
[19:51] <rsalveti> we're only using ext4 now
[19:51] <ogra_> rsalveti, sure ?
[19:51] <xnox> psusi: CONFIG_EXT[23]=n definatly wrong session =) this was emulator for ubuntu touch on x86 session.
[19:51]  * ogra_ hasnt checked ... i thought the initrd still uses ext2 
[19:51] <psusi> yea, I'm trying to get the ext2/3 drivers disabled in the kernel... ext4 driver will handle those filesystems instead and do a better job of it and give a smaller kernel
[19:52] <rsalveti> ogra_: oh, talking about rootfs, sorry
[19:52] <ogra_> yeah, we dont care about that kernel :)
[19:52] <psusi> ;)
[19:52] <ogra_> ours are all android based
[19:52] <ogra_> (who cares about desktops nowadays :P )
[19:52] <rsalveti> problem is using rw when you have an ext2 fs :-)
[19:53] <ogra_> yeah
[19:53] <psusi> damn daylight savings... never can remember if I'm -4 or -5
[19:54] <tyhicks> psusi: here's what you're looking for: http://www.youtube.com/watch?v=SrMTosj1Ikg#t=972
[21:51]  * fabio slaps alex-abreu around a bit with a large trout