[00:27] hi, i'm trying to build a snap which includes a opencv program accessing an openni2 camera. wondering if someone has any hints on getting setting the permissions so the snap thing gets access to the hardware. is there any way to define this in snapcraft? I found this here https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ but it seems to be old documentation from when snap was called snappy. is there an equivalent to sudo [00:27] snappy hw-assign webcam-demo.canonical /dev/video0 or better something to define udev rules for a snap? [00:33] there is a v4l plug/interface [00:35] you put plugs: [camera] in your snapcraft.yaml [00:35] then you connect it after installing it [00:36] something like sudo snap connect camera [00:45] the problem is that camera doesn't show up as a /dev/video device. i think openni uses libusb to access the camera directly [00:56] then you are out of luck because there is no interface for that yet [00:56] bug 1598266 [00:56] Bug #1598266: Cannot read/write to usb device [libusb][hidapi] [00:58] Bug #1607265 changed: Ubuntu-core downloads before querying store for missing snap [01:09] hm ok. that makes it pretty hard to use in robotic applications then. thanks for the link that explains at least that snappy hw-assign got removed. [01:10] you can always run in devmode until it gets implemented [01:10] i'm waiting on the same stuff [01:15] is there anything else other than "confinement: devmode" i need change to get it working. i have udev rules to get the camera working in the normal system. [01:22] yes you have to sudo snap install --devmode [01:41] Note: sudo is only needed if you're not logged in ;-) [01:43] logged in to what? [02:41] thanks, it seems to be working in devmode now === chihchun_afk is now known as chihchun [03:28] PR snapd#1614 opened: Update documentation of /v2/system-information GET result [04:01] has anyone tried the example mosqitto at https://github.com/snapcore/snapcraft/tree/master/demos/mosquitto. after I install the app, it seems there is no output. [05:14] liuxg: What output are you expecting? [05:15] qengho, I did not see any output from running http://paste.ubuntu.com/21857552/. it could possible that the broker is not ready before the publish app is running [05:16] qengho, I can see the output of the broker at http://paste.ubuntu.com/21857599/, it seems that it is running. the subscriber is not running as well. [05:16] liuxg: Ah. [05:18] qengho, this is the output of the subscriber http://paste.ubuntu.com/21857694/. I think it is good to define the order of the running services in snapcraft since some of the apps depending on the some of of services. [05:22] liuxg: "not found" seems weird. [05:24] qengho, i did not install the snapd from the proposed channel. I just install it from the normal channel.my snapd version is like http://paste.ubuntu.com/21858068/ [05:25] qengho, I think it could be possible that broker should be running first, then subscriber/publisher [05:27] liuxg: I don't think you're seeing the systemctl message correctly "No such file or directory" is a big deal. [05:27] That's not an app failure. That's a systemd failure, right? [05:29] qengho, I am not quite sure about that. it is weired to me. [05:30] liuxg: systemd could not reach down into the app to find out how and why it failed to find something. systeemd itself(!) couldnot find something. [05:34] qengho, OK. does it mean that it is a bug somewhere? [05:35] liuxg: Yes. Probably snapcraft.yaml [05:35] qengho, do you how I can install the latest snapd 2.11 version? [05:36] Though, I thoughsnapcraft catchesthis problem. [05:36] qengho, maybe I file a bug against snapcraft? [05:37] [5~Sure. [05:37] qengho, thanks. my colleague got the latest https://paste.ubuntu.com/21858180/ snapd version. How can I install it without installing the latest xenial-proposed? thanks [05:39] liuxg: you need the deb file. [05:39] qengho, where can I find the debian file? [05:39] liuxg: And you need luck that it doesn't pull new deps. [05:39] How should I know? [05:40] qengho, what is your version of it? [05:40] liuxg: If it's in Y, you can use "APT pinning" to upgrade only it. Google will help. [05:41] qengho, ok. thanks [05:41] liuxg: I'm stale because I can't afford to break anything right now. [05:42] qengho, yeah, I am using the stable as well :) [05:46] qengho, I just reported a bug at https://bugs.launchpad.net/snapcraft/+bug/1608794 [05:46] Bug #1608794: snapcraft mosquitto demo got "not-found (Reason: No such file or directory)" [05:55] liuxg: is your colleague with snapd YC? [05:55] qengho, yes [06:01] PR snapcraft#706 opened: Added "camera" plug into the example [06:24] qengho, sorry, I made mistake in running the mosquitto demo app. the "subscribe" and "publish" are both apps instead of daemon. they both need to run using commands. now, the demo works fine as expected :) [06:30] Bug #1608807 opened: create-user fails to create user [06:35] hey hey [06:36] good morning dholbach! [06:36] hey didrocks [06:37] when I open a file dialog from a snapped program it starts in $USER/snap/snapname/x1 [06:38] Is there a way to have it start in $HOME so the user doesnt have to navigate there each time the app is used? [06:38] trijntje: there is no env variable AFAIK pointing to user's $HOME, $HOME in the snap is in $USER/snap/snapname// as you told [06:38] maybe a discussion to trigger on the ML? [06:39] (ask niemeyer about his thoughts on this) [06:42] didrocks: Ok thanks, I thought so. Maybe add a soft link to home in the snap folder itself? You can set HOME for most programs, but then it will try to put configs and data in there which is not allowed [06:45] trijntje: that's exactly the issue, worth raising it IMHO :) [06:48] didrocks: I'll put it on the ML later today, I'll just wait a bit for niemeyer to respond [06:49] yeah, let's see :) [07:08] PR snapd#1614 closed: Update documentation of GET /v2/system-information result === hikiko is now known as hikiko|afk [07:55] ogra_: good morning [07:55] ogra_: we (cyphermox and i) have been having some fun with ubuntu-core images that don't dhcp [07:55] ogra_: do you know anything about any problems like this? [07:56] (sometimes they do dhcp... just not very often) [08:13] trijntje: You can do HOME=/home/$USER so long as you tell the app not to use it for . files. That's what I do in neovim. [08:13] XDG_ variables point inside the snap folders [08:15] That is a big assumption about home dir. Be careful. Convention is not law. [08:16] Law very often is based on convention ;-) [08:21] Alternate suggestions welcome, I'm really just tweaking things as I go along as many things aren't established === JanC is now known as Guest77763 === JanC_ is now known as JanC [09:44] PR snapd#1615 opened: overlord/snapstate, daemon: support for multi-snap refresh [09:48] mwhudson, i see the firstboot setup stuff panic in syslog, and i noticed that i sometimes dont end up with a /etc/network/interfaces.d/eth0 ... which i think the firstboot job sets up [09:48] so yeah, that usually results in not getting dhcp requests [09:52] ogra_: hm, what does that panic look like? [09:54] Aug 2 02:55:41 localhost systemd[1]: snapd.firstboot.service: Main process exited, code=exited, status=1/FAILURE [09:54] Aug 2 02:55:41 localhost systemd[1]: Failed to start Run snappy firstboot setup. [09:54] hm informative [09:55] oh is error: cannot read seed yaml: /var/lib/snapd/seed/seed.yaml related? [09:58] hmm maybe [09:58] PR snapd#1616 opened: tests, integration-tests: implement the cups-control manual test as a spread test [09:58] ogra_: what is supposed to create seed.yaml? [10:01] mwhudson, ubuntu-devcie-flash i think [10:02] (or in the new worldorder perhaps "snap prepare-image" [10:02] ) [10:02] ogra_: ah so maybe my bootleg ubuntu-device-flash is too old? [10:02] mwhudson, is that syslog or journald ? i thin journald doesnt show the panic [10:02] ogra_: syslog [10:02] k [10:02] i don't see an actual panic though [10:02] in my case :-) [10:02] and is that real HW ir kvm ? [10:02] *or [10:02] kvm [10:03] interesting ... i see the panic all the time [10:03] i come from the server space, none of these toys :-) [10:03] lol [10:03] http://people.canonical.com/~mvo/all-snaps/16/ ... thats the latest udf [10:04] it seems to have issues when you use any local snaps though ... works fine with snaps from the store [10:04] * mwhudson bangs head on desk [10:05] the seed.yaml actually describes the preinstalled and existing snaps ... when you boot like that, does snap list show you anything ? [10:06] no [10:06] right [10:06] i have noticed the oddness where on a system like this when you run snap install hello-world, the first thing it does is install the ubuntu-core snap [10:06] yeah [10:07] which given what you said is not surprising [10:07] well, the feature comes from the desktop... [10:07] not sure if it should even kick in here [10:07] you dont have a kernel or gadget snap either ... [10:07] (i mean, you have thgem, but snapd doesnt know) [10:11] hmmm [10:11] this is all interesting but seems unrelated to networking, on looking at the code [10:12] ogra_: what panic do you see, do you have one lying around to pastebin? [10:12] is there a way to patch an app on-the-fly when snappying it? [10:15] mwhudson, http://paste.ubuntu.com/21754413/ [10:16] ogra_: wee [10:16] and this is the seed.yaml i end up when sideloading ubuntu-core http://paste.ubuntu.com/21762356/ [10:16] not sure if the two are actually related though [10:21] heh so i make an image to test this and of course it dhcp's this time [10:21] heh [10:23] ppisati_: Not formally, no. You'd have to add your own build scripts. [10:23] Unless you count environment variables. [10:27] ogra_: so yeah, on an image that got networking there is /e/n/i.d/eth0, on one that did not there is not [10:27] right [10:28] Chipaca, do you happen to know what is supposed to create /e/n/i.d/eth0 nowadays ? === hikiko|afk is now known as hikiko [10:29] (i know we forcefully disable cloud-init network setup currently because snapd used to be supposed to create it, perhaps thats not the case anymore ? ) [10:29] it sure looks like snapd is trying to create it [10:29] k [10:29] i wonder if it is supposed to change though [10:29] ogra_: `snap firstboot` creates it [10:30] could this be a race with whatever populates /sys/class/net/eth* ? [10:30] ok [10:30] mwhudson, hmm, that would be the NIC module [10:30] looks from the code that the only reason EnableFirstEther would return without writing a file is no /sys/class/net/ thingies [10:31] probably firstboot should wait til module-init-tools (or however systemd calls it) has run [10:31] ogra_: mwhudson: snapd.firstboot.service is run before network-pre.target which might be bad [10:32] in that the whole early boot ordering is a nightmare [10:32] early for snappy that is [10:32] :-) [10:32] kalikiana: what you mean "Unless you count environment variables"? [10:33] well, snappy is also special in the initrd setup ... we dont ship each and every NIC module in the world like a classic install would [10:33] so module loading actually only happens after the rootfs is fully set up [10:33] which is a lot later than in classic [10:33] Chipaca: should i file a bug at launchpad.net/snappy saying 'firstboot does not always create populate /e/n/i.d' or something like htat? [10:33] ogra_: mwhudson: could you post the output of `systemd-analyze --system plot` somewhere? [10:34] I'm assuming this is in an all-snaps system [10:34] yes [10:34] good :-) [10:34] ppisati_: You can supply a wrapper that tweaks the environment as needed, maybe affects modules loaded by the binary, or even edits use-writable files during launch. [10:34] Chipaca: can you remind me how to run kvm so that i get the tty on stdin/stdout, not in a window? [10:34] kalikiana: nope, a wrapper in this case won't cut it [10:34] Chipaca: also a non-custom ubuntu-core snap would make this easier... [10:35] mwhudson: -nographic ? [10:35] ppisati_: Personally I would aim for solving everything through config values - if the snapped binary has no option to let you snap it properly, it can probably be added [10:35] oh wait, i have a sufficiently un-custom snap i think [10:35] hi guys, I'm wondering what happend to the support of assiging udev rules to allow a snap to access certain hw devices as described in https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ [10:36] has this support gone away with 16.04 and snapcraft? [10:36] how would I allow my snap to access multiple cameras and other hw devices like sensors connected via iio? [10:36] Chipaca: oh heh, right [10:37] mwhudson: if this is to get the output of analyze, note it's an svg [10:37] Chipaca: oh [10:37] ppisati_: In the short term you can of course simply fork whatever it is and patch that before you consider upstreaming (as I did because I required new options in neovim's build) [10:37] kalikiana: yeah, i see what you mean [10:37] Chipaca: i guess i can scp after running dhclient manually... [10:38] :-) [10:38] thank you [10:38] of course now my images are consistently managing to dhcp by themselves [10:38] kalikiana: i'm actually snaping two apps: midnight command (so i can probably tweak some stuff with ./configure --... there) and a second unrelated python scrpt based app (that requires the patching too) [10:38] let's see [10:39] mwhudson: oh, wait, this is a "sometimes yes sometimes no" problem? have you checked journalctl for circular deps? [10:39] otherwise yeah timing probably [10:39] meaning the deps are wrong one way or another [10:39] on my working system the firstboot job runs ~2sec before network-pre [10:40] Chipaca: i did look in journalctl but not specifically for that, how does it show up? [10:40] mwhudson: in angry red (if your term supports it), search for "cyclic" [10:41] Chipaca: nothing like that [10:41] i've just had a terrible thought [10:41] which is that i didn't see this with -nographic [10:42] a difference with nographic is that you don't see grub and so have to wait 2 seconds for the default to be taken [10:42] whereas with kvm in a window i can be impatient and hit return early [10:43] kalikiana: The app I'm snapping looks for .dot files and folders in$HOME, so I have to set $HOME to the snapdir. Ideally, we would have something for every snap that takes care of this, so we don't have to modify every app ;) [10:46] Chipaca: http://people.canonical.com/~mwh/plot.svg [10:48] wow [10:48] your boot takes awfully long [10:49] mwhudson: and that time it worked? [10:49] mwhudson: (i'm assuming you remove the stampfile or start from pristine every time) [10:49] nearly 5sec longer than mine here [10:50] actually if the stampfile is there systemd would not even run it, so yeh [10:50] Chipaca: no that was a failed boot [10:50] Chipaca: i've been re-running udf between boots [10:50] oooh, what is sys-subsystem-net-devices-eth0.device [10:50] well not a failed boot but a failed to network boot [10:52] mwhudson: can you edit the firstboot service file? [10:52] mwhudson: by copying it to /etc/systemd/system for example [10:53] mwhudson: and change it to be After: network-pre.target Before: snapd.service networking.service [10:53] PR snapcraft#702 closed: Use the new snapcraft.io mailing list as contact information [10:53] Chipaca: it's nearly 2300 here so... [10:53] * ogra_ notes he definitely does not have sys-subsystem-net-devices-eth0.device on a successfully booted setup [10:53] Can anyone build the plank snap from the snappy playpen? It asks me for my git.launchpad.net credentials but fails anyway. I want to take a look at how the mime types are defined in the final snap https://github.com/ubuntu/snappy-playpen/tree/53d3668ab6dc1a5c711f9c5e2deddd6abd59482b/plank [10:53] oh [10:53] wait, i do [10:53] mwhudson: aw [10:53] mwhudson: get out of here then :-) [10:53] Chipaca: let's give it one shot [10:55] hoping that one's not cyclic :-/ [10:58] Chipaca: seems to have worked! [10:58] of course it sometimes worked anyway, but eh [10:59] mwhudson: go to bed, more tomorrow [10:59] Chipaca: feel free to talk to cyphermox about this when he wakes up :-) [10:59] and if there isn't a tomorrow, not going to bed won't fix it either [10:59] (if you are still around then) [10:59] heh [10:59] i like your plan though [10:59] * mwhudson zzz [11:19] I'm reading the terms on the ubuntu snap store, and it says "App(s): one or more applications or content items owned by you which you submit through the Developer Site and any associated screen shots and marketing materials provided by you. " [11:20] what about snapping software that you are not the owner of, like most open source projects? [11:21] Chipaca: final thought, this will all change when netplan takes over the world i guess! [11:21] Chipaca: i need to talk to someone about that, definitely not right now though [11:21] mwhudson: i can't hear you because you are asleep [11:23] mwhudson, depends if pitti plans to backport everything to 16.04 :) [11:23] (and i mean everything ... ) [11:56] trijntje: Teach the app XDG_ variables. Other than that what else would you do? Bind-mount . files to fool the snapped executable? [11:58] kalikiana: no, the app respects XDG_ variables, but then we tell it that its home is in $USER/snap/mysnap/x1. So when we then go to open a file, the file dialog starts there, instead of in /home/$USER [12:11] trijntje: Which is why I would map HOME=/home/$USER [12:27] so how does one include config files into our snap that's not in the same directory as our snapcraft file? [12:28] stokachu: Where do those files come from? A subfolder? Or a separate repository? [12:29] kalikiana: https://github.com/conjure-up/conjure-up is my current directory structure, snapcraft/snapcraft.yaml holds that metadata and etc/conjure-up.conf holds the config [12:29] i want to make sure etc/conjure-up.conf ends up in my snap user data directory [12:31] stokachu: Afair it must be in the read-only bit first, then the wrapper could determine if it exists and create/copy it on startup [12:31] You could use the copy plugin to make sure it's in there [12:32] i tried the copy plugin but i don't know where to copy the config from while int he build [12:33] i have to do weird stuff with the requirements.txt file, requirements: parts/conjure/src/requirements.txt [12:33] i dont understand why it doesn't just pick it up during the build [12:34] stokachu: Copy is relative to the snapcraft.yaml, so files: etc/conjure-up.conf: etc/conjure-up.conf should work [12:34] kalikiana: snapcraft/snapcraft.yaml is the location [12:34] and doing ../etc/conjure-up.conf: etc/conjure-up.conf doesn't work [12:35] Oh, I see [12:35] i could just move the snapcraft.yaml but i want to understand how to grab those files regardless of location of snapcraft.yaml [12:35] like what if snapcraft.yaml was a different repo from the source [12:36] stokachu: I think in theory you could use copy with the same git repo and get it from there, although I've not tried it [12:36] is there any replacement for giving access to devices in snappy 16.04 (was possible via assign: rules: -kernel: foo in 15.04), is there anything planned? [12:36] or why was it removed in the first place? [12:36] stokachu: ie. if you specify source, it won't look at the snapcradft folder [12:36] kind of makes it not usable for IoT devices anymore [12:37] kalikiana: ok ill play with that a bit [12:39] zyga, r u there? [12:39] can you specify multiple plugins for a single part? [12:41] is there something like source-sha256: or how would I make a validation of the upstream source fetched? [12:42] if source is upstream tarball, or do I need to just download the source locally and validate manually? [12:45] stokachu: No. But snapcraft should be smart enough to re-use it and not re-download. [12:45] kalikiana: it rechecks out the git source it looks like [12:46] stokachu: Hrm. I'd say that's a bug. [12:46] verifying now with a clean install [12:47] There's one bug about deb packages being pulled in by multiple parts so there might be other flaws in the caching. [12:47] sergiusens: ^ do you know if this is the case [12:51] hmm, the snap shows /etc/conjure-up.conf but conjure-up.shell doesn't see that file at all [12:52] by default snapd doesnt set up XDG_DATA_DIRS [12:52] so "teaching" the app about them doesn't actually help very much [12:52] so in my snapcraft.yaml where do i copy those files too? [12:53] right now it's etc/conjure-up.conf: etc/conjure-up.conf [12:54] this is my current yaml https://gist.github.com/battlemidget/1bb079992272b96e85ab2ac135a0d541 [12:54] that seems reasonable? [12:55] im guessing it's not reasonable? since it doesn't work [12:55] you need to make the app look for $SNAP/etc/conjure-up.conf [12:55] by changing the source code if necessary [12:56] so we have to basically code our applications to be snap specific? [12:56] no [12:56] you just have to code them with a command line option that allos you to specify the location of the config file [12:57] all good software already does that since years... [12:57] cwayne: I'm using your snapcraft.yaml to try to build atom 1.9 that came out today [12:57] same with directory structure since years... [12:58] yes, XDG_DATA_DIRS has been around for a long time [12:58] stokachu: So what doesn't work? Is the file in the snap? [12:58] the file is in the snap [12:58] but not when i run conjure-up.shell [12:58] unsquashfs list the file [12:59] ahoneybun: are you hitting any issues? i know didrocks cleaned mine up quite a bit [12:59] not sure yet still building [12:59] I used your snap to make mine lol [13:00] or try to [13:00] the problem is this https://github.com/conjure-up/conjure-up/blob/master/conjureup/app.py#L185 [13:01] so if conjure-up.shell shows files in /etc, why doesn't my file show up there even though is specifically told it to copy there [13:02] because that is not what copy plugin does [13:02] copy plugin copies a file in to your snap [13:02] cwayne: IIRC, yours should work without devmode [13:02] stokachu: If they are in the snap, where are they? .shell should see anything that is in there once it's installed [13:02] ali1234: if it's in the snap why isn't it in the shell? [13:03] what do you mean "in the shell"? [13:03] https://www.irccloud.com/pastebin/V9HfBlV2/ [13:03] kalikiana: ^ [13:03] ali1234: conjure-up.shell [13:03] because snaps arent uncompressed over /? [13:04] ali1234: are you asking me if they are? [13:04] stokachu: As the code looks for ../etc/conjure-up.conf maybe you need a subfolder in there [13:04] no [13:05] your code looks for /etc/conjure-up.conf and ../etc/conjuse-up.conf. the file will actually be at /snap/conjure-up/xn/etc/conjuse-up.conf [13:05] didrocks: nope, cause it tries to call nohup [13:05] for some reason [13:06] mm an error [13:06] ali1234: so that goes back to using $SNAP to figure out where the file is [13:07] stokachu: yes, exactly [13:07] cwayne: http://pastebin.ubuntu.com/21888796/ [13:07] ali1234: even if i give it a cli option to poitn to the config file [13:07] I used the one from playpen [13:07] it still requires $SNAP [13:07] stokachu: then you use the cli option from within your wrapper script [13:08] and where do i edit that file? [13:08] in the apps section? [13:08] yes [13:08] command: conjure-up [13:08] command: mywrapper conjure-up [13:08] just the relative path to the config? [13:08] oh i see [13:08] i have to create another file to do this [13:08] yes [13:09] see for example the desktop-launcher [13:09] https://github.com/snapcore/snapcraft/tree/master/demos? [13:09] you could also do it by just supplying arguments [13:09] where is that example [13:09] https://github.com/ubuntu/snapcraft-desktop-helpers [13:10] so you could probably just do command: conjure-up -c [13:10] if conjure-up accepted a -c option [13:10] ali1234: can i do conjure-up -c $SNAP/etc/conjure-up.conf [13:10] yes [13:11] i didnt realize $SNAP was translated in the snapcraft.yaml file [13:11] or do i still need the wrapper? [13:11] $SNAP isn't know until install time [13:11] ok so still need the wrapper [13:11] no, you don't [13:11] maybe not for this [13:11] but you might need it for something else [13:11] depends what problem you run into next? [13:12] how do i know where the conjure-up.conf file is located if i just wanted to do it in the snapcraft.yaml? [13:12] you write $SNAP [13:12] snapcraft.yaml copies it into the shell script it generates automatically [13:12] hey kyrofa, do you expect your godeps PR to land soon? https://github.com/snapcore/snapcraft/pull/691 [13:12] PR snapcraft#691: Add godeps plugin [13:12] look at /snap/bin/conjure-up [13:12] it is a shell script [13:12] i see [13:13] ali1234: https://gist.github.com/battlemidget/1bb079992272b96e85ab2ac135a0d541#file-snapcraft-yaml-L12 can i do something liek this? [13:13] when you run a snap it is shell scripts inside shell scripts [13:13] yes if you add that command lne option to conjure-up [13:13] yea i will [13:13] just curious on that part with snapcraft [13:14] ali1234: kalikiana: this clears up a lot, thanks for putting up with my questions [13:14] you can also do it with a wrapper script, which is neater if you need a lot of arguments and environment variables [13:14] it is just up to your personal preference [13:14] ali1234: yea I will probably end up doing that [13:17] ahoneybun: that looks like an issue within atom itself somehow [13:17] as its failing to run its own bootstrap script.. === mhall119_ is now known as mhall119 [13:40] sergiusens: kyrofa: can one of you let me know when my patch is in a snapcraft release? I'd like to propose my packaging configs to upstream Arduino, but can't until it "just works" [13:42] PR snapd#1511 closed: overlord: actually run hooks [13:45] cwayne: interesting, I was sure it was it was working, did you talk with the security team about ideas to circumvent that? [13:45] nope [13:45] cwayne: another way, we can set -f by default, this shouldn't call nohup? [13:45] didrocks: i think i tired that, but didnt change anything [13:48] interesting, I was sure to have run atom unconfined from the latest playpen [13:48] but I might be wrong [13:48] or have bad memory :p [13:48] but otherwise, open a bug and try to talk about it on the ML with the security guys for ideas [13:48] (but the answer might just be "fix upstream" :p [13:54] didrocks: is there some better way to achieve this, without putting a wrapper in a wrapper? http://paste.ubuntu.com/21893086/ [13:55]