[06:43] <dholbach> good morning
[07:01] <fgimenez> good morning
[08:32] <Chipaca> mo'in
[09:13] <Chipaca> sergiusens: when you're around, could use a hand reviewing the grub branches
[09:13] <Chipaca> getting "does not look like a tar" when using udf
[09:14] <Chipaca> in other news, feeling much better \o/, and all my house smells delicious because i'm cooking up some chile :)
[09:14] <Chipaca> ogra_: how're your teeth?
[09:16] <ogra_> Chipaca, i woke up with nearly no pain at all but a golfball on my jaw :/ ...
[09:16] <Chipaca> ogra_: so you've gone to see a dentist
[09:16] <Chipaca> ogra_: right?
[09:17] <ogra_> yeah, i fear i have to
[09:17] <Chipaca> ogra_: dude, that's an abscess. you want that sorted asap.
[09:17] <ogra_> yes
[09:18] <ogra_> i fear there is not much to sort but get rid of the tooh
[09:18] <Chipaca> they can turn really nasty. don't google it, just go :)
[09:18] <Chipaca> ogra_: forget the tooth, it's the ball of rotten pus inches from your brain you should be worrying about now :D
[09:19] <ogra_> if i open my mouth it is further away though :)
[09:19] <ogra_> (it is the lower jaw)
[09:19] <Chipaca> oh, that's alright then
[09:19] <ogra_> no, not, but not as dangerous :)
[09:20] <Chipaca> true, true
[09:20]  * Chipaca decides not to look up statistics
[09:22] <ogra_> lol
[11:00] <sergiusens> Chipaca: which branch gives you that?
[11:01] <sergiusens> Chipaca: does not look like a tar means an improper download maybe
[11:01] <Chipaca> sergiusens: or maybe i'm using --device-part wrong
[11:01] <Chipaca> sudo ~/canonical/goget-ubuntu-touch/src/launchpad.net/goget-ubuntu-touch/udf core rolling --device-part=generic-amd64_1.1_all.snap --channel edge -o wily.img --developer-mode
[11:02] <sergiusens> Chipaca: you are
[11:02] <sergiusens> Chipaca: that's supposed to be --oem generic-amd64_1.1_all.snap
[11:02] <sergiusens> :-P
[11:02] <Chipaca> d'oh
[11:07] <Chipaca> sergiusens: it worked!
[11:07] <Chipaca> here, let me pastebin it because it's loverly
[11:07] <Chipaca> http://pastebin.ubuntu.com/11767162/
[11:07] <Chipaca> sergiusens: ^
[11:08] <Chipaca> sergiusens: (it was supposed to panic, right? :-p )
[11:09] <Chipaca> sergiusens: and you've got a data race
[11:09] <sergiusens> Chipaca: is that the last branch or one in between?
[11:09] <Chipaca> sergiusens: the last one
[11:11] <sergiusens> Chipaca: can you run godeps -u dependencies.tsv and rebuild?
[11:11] <Chipaca> sergiusens: udf itself?
[11:11] <sergiusens> Chipaca: yes
[11:12] <Chipaca> sergiusens: but that'll fail, because i updated snappy manually to point at the branch you mention
[11:12] <Chipaca> sergiusens: won't it?
[11:13] <sergiusens> Chipaca: oh, don't use that snappy branch, it's irrelevant to u-d-f; it just needs to be on the image for updates on a running system
[11:13] <sergiusens> Chipaca: it probably needs another merge from trunk
[11:14] <sergiusens> Chipaca: and thanks, I will try with that branch in the meantime and figure out what's broken
[11:14] <Chipaca> i'd pulled trunk and merged that branch, but anyway, rebuilding now
[11:15] <sergiusens> Chipaca: yeah, this line doesn't feel right launchpad.net/snappy/partition.(*Partition).BootloaderDir(0xc208059700, 0x0, 0x0)
[11:16] <sergiusens> Chipaca: which is most likely the developer mode stuff that landed
[11:16] <Chipaca> sergiusens: i'll wait for you to fix then?
[11:17] <sergiusens> Chipaca: I would want all the other developer-mode branches to land first; just godeps it
[11:17] <sergiusens> no need to wait
[11:17] <Chipaca> k
[11:17] <Chipaca> sergiusens: forwards, or back?
[11:18] <Chipaca> ah, you mean the godeps you suggested above
[11:18] <Chipaca> which i've already done
[11:18] <Chipaca> but still got the error
[11:18] <Chipaca> because merge
[11:18] <Chipaca> bzr revert'ed and trying again
[11:21] <Chipaca> sergiusens: i have good news, and bad news :)
[11:21] <Chipaca> the good news is that i think it worked :)
[11:21] <Chipaca> the bad news is i build udf with -race
[11:22] <Chipaca> and it's not happy
[11:22] <Chipaca> http://pastebin.ubuntu.com/11767220/
[11:34] <sergiusens> Chipaca: oh thanks, now I have something fun to do today!
[11:57] <Chipaca> sergiusens: you're welcome!
[11:57]  * Chipaca turned his sarcasmeter off
[12:01] <sergiusens> Chipaca: oh, I am indeed happy :)
[12:28] <zyga> hey, who'd like to work with me to create a snap out of network manager
[12:29] <zyga> I tried to get started with deb2snap but it's not possible to handle n-m yet
[12:29] <zyga> and I kind of wonder what approach to use
[12:30] <zyga> should I built nm and its dependsncies myself
[12:30] <zyga> or try to reuse the existing packaging
[12:30] <zyga> then I wonder how to bridge network hardware to n-m
[12:30] <zyga> (and keep it dynamic so I can plug hardware later and still see it)
[12:30] <zyga> and how to start all the deamons that nm needs
[12:30] <zyga> and how to integrate that with udev on the device
[12:31] <zyga> sergiusens, ogra_: ^^ any hints?
[12:39] <verterok> morning
[12:49] <zyga> ogra_: for networking, I remember what you said earlier about not depending on the core, for testing (wired) networking, should we bundle network tools (ifconfig, ping) or would you consider that to be an overkill
[12:51] <ogra_> zyga, no idea, thats an "architect" question ...
[12:52] <zyga> ogra_: who should I ask?
[12:52] <ogra_> dunno
[12:52] <ogra_> lool, tvoss or ricmm perhaps
[12:52] <zyga> lool: ^^
[12:53] <ogra_> i guess the low level bits will be in the image ... but something as high level as NM might have to become a framework or some such
[12:53] <ogra_> and it isnt even clear if we keep the if* tools or perhaps switch to systemd's network management daemon
[12:54] <zyga> ogra_: hence I want to understand how we should rewrite our network tests
[12:54] <lool> zyga: you should bundle network tools, yup
[12:55] <zyga> lool: during testing we'll also reconfigure networking
[12:55] <lool> that's ok
[12:55] <zyga> lool: will systemd undo/change any of our changes?
[12:55] <lool> zyga: not systemd
[12:56] <lool> zyga: it's using ifupdown ATM
[12:56] <lool> only eth0 comes up automatically
[12:56] <zyga> yes, I know but I recall that you want to move
[12:56] <zyga> and ifupdown is rather static
[12:56] <zyga> but systemd might be more proactive (I don't know)
[13:01] <lool> zyga: we aren't there yet though
[13:33] <tomconte> Hi guys, do you know what is the status of Snappy images on Azure? I tried to create a few VMs and they all hang at 'Provisioning' time
[13:35] <mvo> utlemming: do you know if there is a issue with azure right now? see tomconte questions one line above
[13:35] <mvo> tomconte: utlemming may know, but he is US timezone so the answer might be delayed
[13:36] <tomconte> NP thanks! the image I tried was something like Ubuntu-15.04-Snappy-core-amd64-edge-201506190757-94-en-us-30GB
[13:47] <elopio> hey sergiusens, I could use adt-run from trusty passing the ip of the testbed.
[13:47] <elopio> can you paste the error you are getting please?
[13:52] <sergiusens> elopio: I got logged out, I can try again
[13:56] <sergiusens> Chipaca: hey, forgot to send this your way https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/downloadRace/+merge/262851
[13:57] <sergiusens> mvo: thanks for getting those MPs in
[13:57] <mvo> sergiusens: hey, have you tested the lp:~sergiusens/livecd-rootfs/byeByeDebbie ? i.e. will apparmor work?
[13:57] <mvo> sergiusens: yw!
[13:58] <sergiusens> mvo: only manually tested; I can do some more live testing than more than hello-world
[13:58] <sergiusens> with more than*
[13:59] <sergiusens> mvo: btw, using the partition.new code in developer mode checks broke u-d-f :-P
[13:59] <mvo> sergiusens: *cough* sorry for that, do you want me to do a branch?
[14:00] <mvo> sergiusens: if hello-world works, thats probably good enough
[14:00] <sergiusens> mvo: no, no worries, it just caught me by surprise :-)
[14:02] <elopio> fgimenez: I changed the hangout name (once again) to not bother davmor2
[14:02] <elopio> in case you are in the other one.
[14:03] <fgimenez> elopio, np, one minute
[14:04] <davmor2> elopio: now I'm going have to beat you for bothering me again,  Consider yourself beaten ;)
[14:04] <elopio> davmor2: you asked for it
[14:05] <sergiusens> mvo: btw, ubuntu-snappy is failing to build
[14:21] <jdstrand> mvo: re byebyeDebbie-- we are talking about dpkg being gone right? /var/lib/dpkg/info/* will still be part of the readonly rootfs?
[14:37] <sergiusens> mattyw: I found your issue, well there's two actually, one is preventing the install
[14:38] <sergiusens> mattyw: if you introduce a security-override, aside from the apparmor entry you need to provide a seccomp one as well
[14:38] <sergiusens> mattyw: additionally, the apparmor profile has a read_path with a relative path, not sure why
[14:40] <sergiusens> mattyw: wrt seccomp, https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Seccomp
[15:05] <mattyw> sergiusens, thanks for looking into it, I know very little about apparmor and seccomp - this is my introduction to them :)
[15:15] <Chipaca> fgimenez: so!
[15:16] <Chipaca> fgimenez: i am become help
[15:16] <fgimenez> Chipaca, yes thx! :) let me paste the latests results...
[15:17] <sergiusens> mattyw: we all do, but luckily jdstrand knows some more, in any case the wiki has a simple yaml example for seccomp. You might also do an initial try on not requiring this apparmor override at all
[15:18] <fgimenez> Chipaca, well, before of that, i'm creating the chroot with 'mk-sbuild --arch=armhf wily' is that ok?
[15:18] <mattyw> sergiusens, juju trys to read /etc/os-release - I was getting app armour errors when trying to run it
[15:18] <sergiusens> mattyw: I see little sense in checking the release there as I guess you enable features depending on that entry and that probably means you toggle a lot of apt stuff which is just not there
[15:18] <Chipaca> fgimenez: sounds about right :)
[15:19] <mattyw> sergiusens, that's likely true, but I thought I'd try to get it working in snappy as is, then go back and re examine - it's a good excuse to learn about apparmor etc
[15:19] <sergiusens> Chipaca: fgimenez are you going to do native qemu driven builds?
[15:19] <Chipaca> fgimenez: what are we building, btw?
[15:20] <sergiusens> mattyw: right, just add the leading slash there ;-)
[15:21] <mattyw> sergiusens, that's just a plain bug, thanks for spotting it :)
[15:21] <fgimenez> sergiusens, Chipaca i'm trying to build the snappy debs including the test ones using sbuild, not sure if that implies native qemu
[15:21] <Chipaca> fgimenez: using sbuild, yes, it involves qemu
[15:21] <sergiusens> elopio: in any case ./run-checks is broken for me on trusty when adt is installed
[15:22] <Chipaca> at least, i think so
[15:22] <Chipaca> fgimenez: or it might not! let me to the sbuild here too
[15:22] <sergiusens> Chipaca: it does if doing native (qemu-static-$arch)
[15:23] <sergiusens> err qemu-$arch-static
[15:23] <Chipaca> sergiusens: “The auto-cross-builder runs in a fairly strict mode: in particular, it does not have qemu-user-static installed in either the host filesystem or the build chroots (previous incarnations did, but that is less useful for porting to new architectures)”
[15:23] <sergiusens> it may fail plenty
[15:24] <fgimenez> Chipaca that might explain the error i'm finding, i've read somewhere about it being related to qemu... anyway, here it is: http://paste.ubuntu.com/11768227/
[15:24] <fgimenez> sergiusens, ^
[15:24] <Chipaca> ah!
[15:24] <Chipaca> yes
[15:24] <Chipaca> yes, that's qemu
[15:24] <Chipaca> failing
[15:24] <elopio> sergiusens: I didn't try that directly because I have trusty in a kvm, and I can't create another inside as ./run-checks does.
[15:24] <elopio> what I did was to take our branch that passes an ip and port instead of installing the image in a vm.
[15:25] <sergiusens> elopio: oh, the bzr bd part of run-checks is what is bad
[15:26] <elopio> if your error is building the image, I can try trusty from a live cd. If it is on adt-run, I should be able to reproduce it this way.
[15:26] <sergiusens> elopio: it ignores what platform you are on so a 15.04 snapshot would be built with wily (or trusty or *) deps when it need be built with vivid ones
[15:26] <Chipaca> fgimenez: so. You're needing the armhf package to install it in the image?
[15:26] <elopio> sergiusens: ah, that's because of your customized builder in bazaar conf.
[15:27] <elopio> or not.
[15:27] <sergiusens> elopio: it doesn't matter; if I remove that, it would build on trusty but it needs to have been built on a wily system
[15:27] <fgimenez> Chipaca, yes, until we are able to get the image from the branch we should be able to compile them to install in the boards, what would be a good approach for that?
[15:28] <elopio> sergiusens: we can specify a --builder in bzr bd to select those options.
[15:28] <Chipaca> fgimenez: which are the packages you need?
[15:29] <elopio> and we also copied your flag for receiving debsDir, so if you want to build the debs on your own, you just pass the dir.
[15:29] <sergiusens> elopio: right, if I build the debs on my own that means it can't really be part of run-checks, can it?
[15:30] <sergiusens> elopio: the only thing my bazaar.conf does is define a builder ;)
[15:30] <sergiusens> elopio: but it fails to understand -uc and -us
[15:31] <fgimenez> Chipaca, we need the ubuntu-snappy packages from a branch, including the tests one to be installed on the boards http://bazaar.launchpad.net/~fgimenez/snappy/cross-compile-debs/view/head:/debian/control for instance
[15:31] <sergiusens> elopio: and it's something that needs to be built in to run-checks (passing --builder) so we all run the same thing
[15:31] <elopio> sergiusens: that's because the -uc -us are for debuild, and you are using sbuild.
[15:31] <elopio> if we always pass --builder debuild -- -uc -us it could work.
[15:32] <elopio> what I don't know is how to tell debuild to build for vivid or wily.
[15:32] <sergiusens> elopio: yeh, but I'm saying that using --builder debuild is the wrong thing to do ;-)
[15:32] <sergiusens> elopio: and the best way to convince you of that is to get you to run your main system on trusty ;-)
[15:32] <fgimenez> Chipaca, ideally we should be able to build an image with them installed, so that we don't need to install them in a writable partition with dpkg (urgh), this is until we get there
[15:33] <elopio> trusty, ugh... :)
[15:33]  * Chipaca building a chroot by hand
[15:34]  * Chipaca wonders whether making a snappy to build amrhf snaps would win him brownie points
[15:34] <elopio> sergiusens: we could always use --builder sbuild. But then we have to document on the README the schroots that we need.
[15:34] <elopio> I see no problem about that.
[15:43] <sergiusens> elopio: I'll create a branch for that as this basically blocks me from testing anything easily
[15:43] <elopio> I wonder if this would be easier with .dsc or .changes.
[15:52] <Chipaca> well
[15:52] <Chipaca> seems we have a broken wily build right now?
[15:52] <Chipaca> src/launchpad.net/snappy/cmd/snappy/cmd_login.go:27:2: code in directory /tmp/cross-compile-debs/obj-x86_64-linux-gnu/src/code.google.com/p/go.crypto/ssh/terminal expects import "golang.org/x/crypto/ssh/terminal"
[15:55] <elopio> sergiusens: thanks.
[15:56] <elopio> fgimenez: either the test finishes before the reboot and it never happens, or it receives the segkill.
[15:56] <elopio> the only option I see is to do the reboot outside of the test binary.
[15:56] <elopio> we can do that with a wrapper script, and leaving a file /tmp/needs-reboot or something.
[16:05] <fgimenez> elopio, sounds good, it can play well with adt-run
[16:08] <fgimenez> Chipaca, i saw something similar, in my case it was looking for dependencies in /usr/share/gocode (which belongs to root) instead of the defined $GOPATH, don't know if it might be related
[16:09] <Chipaca> fgimenez: i got to the point where it got building, but then failed on some bits that don't work for cross-compiling. i'll retry in a bit
[16:09] <Chipaca> fgimenez: is it bad if i skip the package build tests?
[16:09] <Chipaca> that is, i don't run the tests during package build of this package
[16:10] <fgimenez> Chipaca, i think so, elopio? ^
[16:11] <elopio> Chipaca: not if you are running from ./run-checks.
[16:12] <elopio> when you ./run-checks, it will run the tests, and then run them again during the bzr bd.
[16:12] <Chipaca> yep
[16:12] <Chipaca> except i was hoping to not have to get the tests to pass inside a bodged up chroot :)
[16:21] <fgimenez> Chipaca, elopio leaving, will catch up tomorrow
[16:48] <Chipaca> sergiusens: is there a way to make dh_golang specify -ldflags?
[16:55] <sergiusens> Chipaca: no, I wish there were
[16:55] <sergiusens> Chipaca: I also wanted to do some neat tricks with package building for autogen'ed stuff
[16:59] <Chipaca> sergiusens: this will make my evil plan of compiling snappy with musl a lot harder
[17:03] <sergiusens> Chipaca: heh, if dh_golang had prov and build in different steps it would be rather easy though
[17:03] <sergiusens> Chipaca: btw https://code.launchpad.net/~sergiusens/snappy/seccomp/+merge/262880
[17:04] <sergiusens> oh snap, my fingers copied an extra line there :-P
[17:05] <sergiusens> there we go
[17:10] <cyphermox> elopio : just checking, do you know if today's snappy personal EFI image booting properly now?
[17:11] <elopio> cyphermox: I didn't know it wasn't booting properly before. I haven't touched personal yet.
[17:11] <cyphermox> Ah, OK. sergiusens suggested you'd know :-)
[17:12] <Chipaca> sergiusens: +1
[17:12] <Chipaca> and i'm off to have glorious, glorious dinner
[17:12]  * Chipaca 's been smelling it all day
[17:13] <elopio> Chipaca: mmm, enjoy.
[17:13] <sergiusens> cyphermox: oh, you meant personal?
[17:13] <sergiusens> cyphermox: we don't qa personal, that's on the personal team
[17:13] <elopio> cyphermox: I can give it a try. I think I just need to build ubuntu-device-flash from source.
[17:13] <elopio> s/source/trunk.
[17:13] <sergiusens> elopio: it's in wily now fwiw
[17:14] <elopio> sergiusens: ah, that's good. Thanks.
[17:14] <sergiusens> elopio: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.25-0ubuntu1
[17:15] <elopio> sergiusens: what does that personal-oem contains?
[17:15] <cyphermox> sergiusens : sorry, I wasn't clear enough, I mean the same image that seb reported didn't boot successfully in UEFI
[17:16] <cyphermox> I can just as well test it myself later if having it working isn't an omg-fire :-)
[17:18] <sergiusens> cyphermox: ok, so I have no efi machine, it's just a seb thing :-)
[17:19] <cyphermox> OK. Well it can be tested with qemu and OVMF, but I'll play with it tonight :-) I don't want to distract you from more important things
[17:22] <elopio> cyphermox: that sounds interesting, and something we should automate somewhere.
[17:22] <elopio> I'll make a card to test with https://wiki.ubuntu.com/UEFI/OVMF
[17:24] <elopio> sergiusens: if we run the selftests on an image with personal-oem and a qemu with ovmf, do you think we should put that in lp:snappy ?
[17:26] <cyphermox> Elopio : I can share with you the qemu options to use
[17:27] <elopio> cyphermox: yes, please.
[17:27] <elopio> https://trello.com/c/I1BSZ6iV/130-run-tests-for-snappy-personal-and-uefi-boot
[17:32] <tomconte> utlemming: Hi, do you know what is the status of Snappy images on Azure? I tried to create a few VMs and they all hang at 'Provisioning' time
[17:32] <utlemming> tomconte: which image?
[17:33] <tomconte> utlemming: the image I tried was something like Ubuntu-15.04-Snappy-core-amd64-edge-201506190757-94-en-us-30GB
[17:33] <utlemming> tomconte: there is a bug with Snappy on Azure that needs to be fixed, that we have been trying to clear. I'm waiting for feedback from Microsoft.
[17:34] <utlemming> tomconte: but, yeah, I am waiting that situation. The issue is that the /writable partition is not being seen at boot.
[17:34] <utlemming> s/waiting/watching/
[17:36] <tomconte> utlemming: I can try to help, could you forward me the issue or add me to the email loop ?
[17:36] <tomconte> utlemming: I am from Microsoft :)
[17:38] <utlemming> tomconte: yeah, let me see if I can dredge up the bug report on it
[17:57] <sergiusens> Chipaca: do you have a minute for a hangout?
[18:16] <Chipaca> sergiusens: now i do
[18:17] <Chipaca> elopio: https://goo.gl/photos/73DdNVzZYeEa1ZMb9
[18:20] <rsalveti> sergiusens: elopio: so let's target the next stable release for july 10, since next week we're going to have a new kernel
[18:20] <rsalveti> so target for first RC could be july 6
[18:22] <rsalveti> elopio: would probably be good to do another round of bug triaging as well, so we can target possible fixes or backports we can still work on during next week
[18:25] <rsalveti> https://launchpad.net/snappy/+milestone/15.04.2 with the date
[18:30] <Chipaca> sergiusens: am going to be around for a while, but am officially breaking out the beer in a few
[18:33] <sergiusens> Chipaca: ok, just wanted to talk about _$version and the future
[18:36] <sergiusens> Chipaca: https://plus.google.com/hangouts/_/canonical.com/days_of_future_past
[19:26] <elopio> rsalveti: great, thanks.
[19:50] <sergiusens> rsalveti: the problem with google docs instead of VCS is that it's hard for people to spot the updates ;-)
[20:25] <marcoceppi> hello! I have a raspberrypi2 and I'm trying to figure out how to flash it...
[20:26] <marcoceppi> I found this: http://people.canonical.com/~platform/snappy/raspberrypi2/ but I have no idea what I'm doing
[20:29] <sergiusens> marcoceppi: http://developer.ubuntu.com/en/snappy/start/#snappy-raspi2
[20:29] <sergiusens> marcoceppi: with the images you found there
[20:29] <marcoceppi> sergiusens: thanks!
[20:30] <sergiusens> alecu: kyrofa do you know how eaasy or hard it is to see changes in a google doc? I was udating here and there
[20:32] <alecu> sergiusens: we can only see the revision history if we have Edit permission
[20:33] <alecu> sergiusens: "File->See revision history..."
[20:33] <sergiusens> alecu: then yiu shall get them!
[20:34] <sergiusens> alecu: there!
[20:34] <alecu> sergiusens: the history view is not great, but it aggregates changes that happened close in time, so it's possible to understand what was changed.
[20:34] <alecu> sergiusens: I'll try reloading, thanks.
[20:35] <alecu> sergiusens: looks good, thanks.
[22:22] <rsalveti> sergiusens: Chipaca: elopio: what are we missing for https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 ?
[22:23] <elopio> rsalveti: one review.
[22:23] <rsalveti> sergiusens: Chipaca: can either of you guys take another round of review for that branch ^?
[22:24] <Chipaca> rsalveti: sure
[22:24] <Chipaca> rsalveti: in the morning :)
[22:24] <rsalveti> Chipaca: sure :-)
[22:25] <Chipaca> elopio: for future reference, it's likely i would have reviewed it by now if it weren't asking for a review from mvo explicitly
[22:25] <Chipaca> or more likely, at least :)
[22:26] <elopio> Chipaca: I added mvo just this morning, thinking that a direct ping to somebody would speed things up ;)
[22:26] <Chipaca> elopio: orly?
[22:26] <Chipaca> elopio: my apologies then!
[22:28] <marcoceppi> getting an error when trying to boot on the ubuntu matchbox rpi2
[22:28] <marcoceppi> systemd failes to load default taget: no such file or directory,?
[22:31] <marcoceppi> https://lh3.googleusercontent.com/kbsG4MKVxq6SbdiCHgKnf1ttfZcSdBUf-f4RAYn1W3dF=w1342-h993-no