=== Ursinha_ is now known as Ursinha === chihchun_afk is now known as chihchun [07:14] good morning [08:34] morning [08:34] can one have apt parallel to snappy? [08:50] Good morning all; happy Wednesday, and happy Frappe Day! 😃 [08:56] good morning [09:02] Chipaca: hello, I came back on Bug #1496319 :) [09:02] bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 [09:04] Chipaca: problem was adding custom Udev string as hw-assign parameter. Is there a way to check whether Udev is tested enough for this? [09:05] Hi all, we are still trying to execute Snappy on parallella board. Based on porting guilde, we have take beagebone rootof and our own kernel. After some configuring u-boot, we have managed to load system. [09:05] But after that we failed to login by “ubuntu/ubuntu”, because of system after first boot sets /var/lib/extrausers/shadow like ubuntu:!$6$tOIJ… [09:06] After removing “!” we can successfully login into system. But mount command shows that root mounted in “rw” mode. And seems like not all mount points mounted properly. [09:10] ogra2, ogra_ : you are our last chance :) [09:15] lool: you around? [09:16] mwhudson: did you see pitti's reply on bug 1487010? [09:16] bug 1487010 in golang (Ubuntu) "please upload new package to reenable go's race detector on wily" [Undecided,In progress] https://launchpad.net/bugs/1487010 [09:16] Chipaca: yup [09:16] clobrano: i'd ask security people [09:16] lool: you've ported snappy to some odd places :) [09:16] lool: any hints for soffokl here? [09:16] Chipaca: thanks [09:17] soffokl: are you using our initrd snippets? [09:18] soffokl: http://kernel.ubuntu.com/git/rtg/snappy-tools.git/ has a tool to create the device tarball from kernel .debs [09:18] clobrano: most of 'em are at something like utc-5 though [09:19] * clobrano checking UTC-5 [09:19] Chipaca: it's not a problem, I can wait :) [09:25] soffokl, and you used ubuntu-device-flash to create this image ? [09:25] an ogra! [09:25] * Chipaca faints [09:25] well, inofficial still :) [09:25] :) [09:26] (but bored as hell) [09:26] lool, we have tried to use beagleboneblack initrd, but then our kernel failed to load. [09:26] then youur kernel is likely missing bits that snappy needs [09:27] soffokl: you need to have the right modules and options, either builtin modules or in the initrd [09:27] nah [09:27] you shouldnt need modules [09:28] ogra_: either builtin or as modules :-) [09:28] if you use the same config we use on the beagle or on the rpi images you will have everything you need to mount the readonly root and the overlays [09:28] ogra_, yes, we have created image with "sudo ubuntu-device-flash core 15.04 -o my-snappy.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=./device.tar.xz" [09:28] i have booted both with module-less initrds [09:29] ogra_, which config you mean? [09:29] soffokl, well, you need to create your onwn oem snap ... with the right bootloader, vmlinuz and initrd [09:29] biezpal, the kernel config :) [09:30] ogra_, where can we get the "correct" kernel config? [09:32] we are using our own kernel for parallella and seems like it doesn't have required for snappy bits.. [09:32] ppisati, ^^ doo you have a link for biezpal [09:33] biezpal: kernel version? [09:33] 3.10, 3.14 or 3.18? [09:34] or perhaps 4.2 ? [09:34] :) [09:34] *drums* [09:34] 4.2 would be awesome [09:34] ppisati, 4.2.0 :D [09:35] soffokl, note that a readonly root is normal ... only a few selected bits are writable via bind mounted dirs and files, that is what the initrd is needed for [09:35] (it sets up the bind-mount-farm) [09:36] biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_packaging [09:36] biezpal: look at the UBUNT: [Config] commits [09:36] biezpal: they all touch files in [09:36] ogra_, thanks, we are keep reading about oem snap [09:37] biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/configs/snappy?h=snappy_packaging [09:37] biezpal: cherry-picks these commits [09:37] biezpal: then [09:37] biezpal: $ ARCH=arm ./scripts/kconfig/merge_config.sh arch/arm/configs/YOURCONFIG_defconfig arch/arm/configs/snappy/*.config [09:38] biezpal: and you should get a config able to boot snappy [09:38] soffokl, note that we switched to use a uboot.env file for the environment, but the old uEnv.txt and snappy-system.txt stuff should still work to get something to do a first boot (just rollback and update wont, but thhats a second step for porting) [09:40] ppisati, ok, thanks for helping.. [10:17] yesterday i tried updating one of my test boxes to stable 6, it failed with the message that ubuntu-core was sideloaded. Is that expected? [10:23] ogra_: Hey, are you using predictable network interface names with rpi2 image? If so, how did you enable it, kernel parameter only? [10:23] longsleep, i'm actually suppressing them via kernel cmdline option corrently [10:24] net.ifnames=0 [10:25] that keeps the old naming scheme [10:25] ogra_: Ah - but that is the default in ubuntu isnt it? [10:25] not sure if we use it elsewhere [10:26] ogra_: net.ifnames=1 is working to some level for me, but i was wondering if the interfaces should still be eth0 and wlan0 [10:26] well.... snappy config ubuntu-core defaults to eth0 currently [10:27] right, but aside from that, i was kind of expecting crazy interface names with that change [10:27] yeah [10:27] depends on your HW [10:28] mhm ok, USB wifi is getting wlan0 names, works fine as long as you do not replace the USB device with another one [10:29] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ [10:29] seems you are lucky and fall inot category 5 on that 1-5 list [10:30] mhm [10:31] this means the hardware does not provie 1, 2 or 3 or i am doing something wrong [10:31] right ... or you have a udev rule in place already [10:31] i did at least expect it to use 3 [10:32] ogra_: why do you not use it on the rpi2? just because ubuntu-core defaulting to eth0? [10:32] yeah, and i get a really weird name based on the mac address (4) [10:32] oh [10:32] yeah 4 would be bad [10:33] (which i shouldnt according to that doc) [10:33] well, maybe it is enabled in the systemd build somwhere [10:33] iirc Chipaca said all that works fine in rolling ... never tried that [10:34] i added this hack to rpi specifically for 15.04 images [10:34] mmh? [10:34] i was probably lying, whatever it was [10:34] 's a good bet [10:34] lol [10:34] anyways, i am basically fine with getting 5 - but i have some issues when an active USB wifi is removed and replaced, something is not released then and then [10:35] mhm, from my testing setting the kernel parameter to 0 is the same as the default behavior without the parameter [10:35] (stable channel though) [10:35] funny [10:36] is that on a first boot ? [10:36] yes [10:36] (wont work on subsequent ones since the udev rule exists) [10:37] when i remove the udev rule and reboot without the parameter it creates it again [10:37] same is when booting with 0 as value [10:37] when booting with 1, the udev rule is not created [10:38] yeah [10:38] but your kernel simply provides the old naming [10:40] is this about the creation of the file for the first ethernet card? [10:40] ogra_: oh, so this thing depends on the kernel as well, i thought it would be systemd only [10:40] well, that is what the wikipage says [10:41] Chipaca: it is about the interface names and the udev rule stores all ethernet devices ever connected to the host [10:41] * longsleep checks the wiki again [10:41] 5. Classic, unpredictable kernel-native ethX naming (example: eth0) [10:41] kernel-native [10:41] ah [10:42] but i had nothing to do with that :) [10:42] all i did touching that was creation of the first-boot file for the first ethernet device [10:42] ogra_, we are successfully loaded with initrd, thanks again :) [10:42] ogra_: right, but any kernel should be the same right? [10:42] which just looks for eth* and en* [10:42] i'm pretty sure you worked on a snappy specific bug for it :) [10:42] right [10:42] Chipaca: what file is that? [10:42] soffokl, \o/ [10:42] longsleep: /etc/networ/interfaces.d/{ethname} [10:43] Chipaca: ah, well you should probably extend this to also support wl* [10:43] in the course where we discussed that bug it turned out that rolling and 15.04 behaved differently [10:43] which led me to use the kernel cmdline option on rpi stable [10:44] i see [10:44] mhm funny that i do not seem to be required to use the cmdline option though [10:44] i agree abouth the wl* thing though [10:44] longsleep: wl is wifi, sin't it? [10:44] Chipaca: yeah [10:44] yep [10:45] isn't that more complicated? [10:45] buut if you are unluckly it could also be wifi0 [10:45] :P [10:45] * ogra_ has seen such devices before [10:45] really [10:45] oh my [10:45] * Chipaca <- il ne sais rien [10:45] sait* [10:45] rm -fr .... [10:45] lol [10:45] * ogra_ removes the french [10:46] :D [10:46] or, D: [10:46] let me get our friends out of france first! [10:46] heh [10:46] wifi is more complicated true, i am currently providing wpa config in /etc/writable/wpa_supplicant.conf [10:46] did not find any better writable mount to put it [10:47] there might be a network-manager framework at some point in the future [10:47] that should make it easier to just supply a snappy confg yaml for your setup [10:47] longsleep: you can't configure it via the interfaces.d thing in config? [10:48] only to a certain extend [10:48] Chipaca: not if you want to be able to configure multiple networks [10:48] wifi config works fine via /e/n/i ... but not for the higher level encryptions [10:48] longsleep: i don't think multiple networks blocks this [10:48] i.e. enterprise WPA and such [10:48] ogra_: yeah, those always tripped me up :) [10:49] Chipaca: what is not blocked by multiple networks? [10:49] normal personal WPA2 works fine via the file [10:49] only for a single ssid [10:49] i never tried multiple :) [10:49] if you want roaming or have it auto pick the stronges signal it will not [10:50] ah [10:50] =t [10:50] so, let's call it "basic support" [10:50] :) [10:50] and my WIFI APs here can properly use ESSID for roaming [10:50] hehe all right [10:51] (using the same SSID for all and have them send roaming info to the client about strenght etc) [10:51] ogra_: mhm so you say i should avoid using a wpa config file mhm - not sure - then i need a way to store multiple ssid/password combinations some place else and apply them from some place else [10:51] but thats sadly an AP feature you dont find in the home user HW [10:52] right, and only works for a single logical network [10:52] yeah [10:52] * longsleep thinks wpa-confi option is the way to go for everyone [10:52] nah [10:52] snappy even shipts wpa_passphrase to create it [10:52] :) [10:52] -t [10:52] nmcli via snappy config from your oem snap is the way to go [10:53] nmcli oh my [10:53] * longsleep was hoping to avoid that [10:53] once there is a NM framework we ship by default [10:54] NM offers evereything we need for GSM, LAN and WLAN [10:54] and whatever else [10:54] does NM also offer link detection? I added a new comment to https://bugs.launchpad.net/snappy/+bug/1498631/comments/10 yesterday, as dhcp is running forever even if there is no link on eth0 [10:54] Launchpad bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [High,In progress] [10:54] yes, it should [10:55] Now the waiting is fixed with the release from yesterday but the dhcp keeps running and running [10:55] (plug a cable into your laptop ... it will DTRT) [10:55] oh, i did some brief research about ifplugd and and did not like it very much [10:55] is that dhclient ? [10:55] yes dhcclient is started for eth0 [10:56] no matter if plugged or not [10:56] that should have a timeout option we can add i think [10:56] mhm but what when you plug it after that timeout was reached? [10:56] i think -1 ... [10:56] that is there [10:56] but that will only make it try once [10:57] oh [10:58] it should try only once for the duration of the timeout that was defined in dhclient.conf [10:58] mhm it does have some kind of interval [10:59] (RaspberryPi2)ubuntu@localhost:~$ grep ^time /etc/dhcp/dhclient.conf [10:59] timeout 300; [10:59] so it should stop after 5min [10:59] No working leases in persistent database - sleeping. [10:59] and after some time it will try again [10:59] ok maybe i was not patient enough [11:00] nope its not me [11:00] it just started again [11:01] ogra_: 10:54:53 sleeping [11:01] ogra_: 11:00:33 DHCPDISCOVER [11:01] uhm [11:01] i did nothing with that device in the meantime [11:01] just journalctl [11:02] pitti, any idea why that happens ? "dhclient -1 " should not make it restart, no ? [11:02] or i'm reading the manpage wrong ... sounds like a bug [11:03] ogra_: well then i am reading the manpage wrong as well [11:03] ogra_: exit with code 2 :) [11:03] right [11:03] hi, anyone with some snappy/Ubuntu Core presentations ? [11:04] i am out for lunch now, i will dig more on this later [11:04] daker, i know sergiuens held a talk, but i dont know where his slides are ... (and he is off until tomorrow) [11:05] ogra_: ok, i will ask him tomorrow [11:05] http://summit.ubuntu.com/ubuconla-2015/meeting/22539/hola-snappy/ [11:06] ogra_: ^ that one? [11:06] oh, right [11:07] you might need to pipe it through skype though to get it in a sane language [11:07] *g* [11:07] Chipaca: thanks [11:08] daker: depending on your language, here's another one in not-english: https://speakerdeck.com/svij/snappy-ubuntu-core [11:08] svij: thanks! [12:09] ppisati, err ... why do we default to "powersave" in the kernel config, thats really bad ... (first: that makes booting slow, second: we have a userspace job that forces it to ondemand after boot) [12:10] can we please set this back to performance by default so the boot doesnt get slowed down = [12:10] ? [12:11] (we can discuss making the usespace job configurable to then default to powersave after boot or some such) [12:19] * Chipaca goes to lunch, while pondering the genius of http://bennyhillthis.com/ [12:30] ogra_: so the dhclient is still trying to get an address for the not connected eth0, so i think we can say that it does not stop [12:32] longsleep, right, i think thats a bug .... seems pitti didnt see my ping above :) [12:32] ogra_: I didn't get to it yet; sorry, being flood-pinged [12:32] i would expect it to stop doing that if -1 is used and a timeout is set in dhclient.conf [12:32] ok let me add it to the tracker then [12:33] perhaps something external restarts dhclient and doesnt respect "exit 2" though [12:33] ogra_: no, the pid of that dhclient did not change since 2 hours [12:34] wow [12:34] yeah, then it sounds like dhclient doesnt even exit [12:34] I didn't follow scrollback, but -1 doesn't (seem to) be "try once and immediately exit", just "try once" (as documented) [12:34] so it might stay around until it actually succeeds? [12:35] yet it stays around and flodding logs all 5 minutes with DHCPDISCOVER on eth0 lines [12:35] s/yet/yes [12:36] pitti, well, the manpage says it does try once for the duration of the timeout thats defined in dhclient.conf [12:36] so that sounds like a bug then [12:36] and then it does an "exit 2" [12:37] let me add a new bug separate from 1498631 [12:37] * pitti runs "sudo dhclient -1 -v -i lxcbr0" (which can't succeed) and lets that sit for 5 mins [12:38] * pitti gets grumpy, changes timeout to 30s and re-runs [12:38] hehe [12:38] what kind of ridiculous default is "5 mins" anyway [12:39] we live in an impatient world :) [12:39] 5 mins == broken [12:39] No DHCPOFFERS received. [12:39] and exits with 0 (!) after 30 s [12:39] Maybe its only with a lease file? [12:39] After No DHCPOFFERS received it logs No working leases in persistent database - sleeping. [12:39] I do have a /var/lib/dhcp/dhclient.leases [12:40] right, I get the same [12:40] mhm [12:40] Old leases are kept around in case the DHCP server is unavailable when dhclient [12:40] is first invoked (generally during the initial system boot process). In that [12:40] event, old leases from the dhclient.leases file which have not yet expired are [12:40] tested, and if they are determined to be valid, they are used until either they [12:40] expire or the DHCP server becomes available. [12:40] ogra_: powersave is our default on every kernel/arch [12:40] so that sounds plausible [12:40] ogra_: how much do we gain in boot time going to performance? [12:41] mine does not exit - the pidfile got created at 10:25 utc and it still has that pid [12:41] longsleep: so does it log that it's re-using old leases then? [12:41] pitti: no there are no leases [12:41] (lease file is empty) [12:41] its the first boot actually, and it never had a link on eth0 [12:42] ppisati, a few seconds ! [12:43] ppisati, who decided to drop performance in our main kernels ?!? [12:43] thats an essential boot speed bit [12:43] (worked out around lucid by keybuk) [12:43] ogra_: let me check [12:44] CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y [12:44] phew ! [12:44] we still have that in wily's amd64 kernel at least [12:44] is that different on other kernels? [12:44] seems like [12:44] well, in snappy kernels [12:44] and /etc/init.d/ondemand should change it to something else after 1 min [12:44] yeah [12:45] we want full CPU and IO throughput until we are booted [12:45] and after that switch to ondemand [12:45] if we want to switch to something else in snappy thats fine, but only after booting please [12:45] FWIW, needing something like /etc/init.d/ondemand seems silly; I'd have thought the kernel's default scheduler would be clever enough by now [12:46] I mean, even with ondemand/powersave it should go to full CPU if there's load; doesn't it? [12:46] pitti: yep [12:46] pitti: it just tries to go down quicker [12:47] ppisati: right, I'm not advocating to keep "performance" all the time; I'm just asking why "ondemand" all the time is worse [12:47] if there is demand (and there obviously is during boot) it should certainly be as fast? [12:48] ogra_: i was wrong, the default is still PERFORMANCE [12:48] i think keybuk found that it takes a bit to scale up [12:48] ppisati, good [12:49] ogra_: tough in that rpi2 kernel was powersave [12:49] ogra_: let me check another thing [12:49] pitti, so you run without full performance for a second or two during boot [12:49] jdstrand: ping [12:49] here it is [12:49] arch/arm/configs/bcm2709_defconfig:CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y [12:50] which costs precious CPU throughput at a point where you dont want to lose it [12:50] ogra_: that was the default governor from the rpi config [12:50] ppisati, oh, please change that asap [12:50] we want ondemand after boot and performance during boot [12:50] ogra_: let me check 4.2 [12:50] now i understand why it boots so sluggish [12:50] ogra_: and i'll push a a new kernel for 3.19 [12:50] jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273683 [12:51] ppisati, why ? we dont use 3.19 anywhere anymore :) [12:51] snappy is 4.2 everywhere since last image [12:51] ogra_: i'm still using it :) [12:51] jdstrand: marked "work in progress" because i still need to add code that uses it, but that's the crypto bits done for your guys to take a look [12:51] ppisati, ogra_ : Added the dhcp issue as bug #1503680 [12:51] bug 1503680 in Snappy "dhclient for eth0 does never exit and retries dhcp foerever" [Undecided,New] https://launchpad.net/bugs/1503680 [12:52] oh, drat, prerequisites [12:52] and in snappy we run cloud-init during boot *before* the ondemand governor is used ... and cloud-init is python ... which is ultra slow on ARM in itself [12:52] longsleep, thanks ! [12:52] jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273684 <- fixed prereq's [12:56] CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y is the default on 4.2 rpi2 too [12:56] so it was just a 3.19 thing [12:57] ogra_: when you were referring to slowness, did it apply to 4.2 too? [12:57] ogra_: because it's correct there [12:58] ppisati, i didnt measure it recently ... in my initial images it was really slow (1-2min to boot) .... with the last image i mostly booted remote [12:58] i have to prepare a new rpi image this week (nobody told me we'd release a new stable one this week, i thought that was planned for teh 17th) [12:59] i'll do some stopwatching :) [12:59] ogra_: cool [13:00] any reason why opencryptoki is in ubuntu-core stable? I just added bug #1503681 [13:00] bug 1503681 in Snappy "opencryptoki.service fails to start" [Undecided,New] https://launchpad.net/bugs/1503681 [13:01] longsleep, weird, thats fixed [13:01] * ogra_ wonders if mvo did test on all ARM arches before doing that rushed release yesterday :/ [13:02] mhm the image i created yesterday has it installed [13:02] longsleep, its a duplicate in any case, let me find the bug [13:02] https://bugs.launchpad.net/snappy/+bug/1500020 [13:02] Launchpad bug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] [13:03] let me compare it [13:03] ah, and i didnt milestone it so that mvo could have found it because asac didnt create a milestone [13:03] Chipaca: ok, I added it to the card [13:03] i fixed it in wily [13:03] ogra_: I ran on bbb and did not touch raspi [13:03] s/to the/to a/ [13:03] jdstrand: g'morning :) [13:03] Chipaca: hi! [13:03] ogra_: oh, in a meeting right now, but I can check right after that [13:03] mvo, right, but there are plenty bugfixes missing seemingly ... i asked asac for a milestone and he missed creating one during the sprint [13:04] so the open bugs are all not milestoned [13:04] Chipaca: it will likely be a couple of days-- sarnold is swamped with other reviews [13:04] Chipaca: hey, do you know who implemented socket* and listen-stream? [13:04] mvo, but therer are some regressions due to stuff that was added for amd64 [13:04] jdstrand: the chipacacentric worldview is disappointed [13:05] jdstrand: mvo iirc [13:05] ok thanks [13:05] mvo: I know you're in a meeting. after the meeting when its convenient, can you ping me re socket* and list-stream? [13:05] listen* [13:06] ogra_: i see, well the comment says that the writable path should be added, it has not been added for ubuntu-core 6 - at least the one i got [13:06] longsleep, yeah, thats broken [13:07] ogra_: ubuntu-core 6 has 0.6.15 of ubuntu-core-config - thats why - fixed in 0.6.29 [13:07] longsleep, thats correct, as i said there is a bunch of regressions that werent fixed [13:08] (and vivid has 0.6.15, which is correct too) [13:08] ok good, so how can i close 1503681 as duplicate [13:09] ah found it [13:09] longsleep, done [13:09] ok thanks :) [13:17] ogra_: do you have bugs already for the regressions? [13:17] jdstrand: ok, I will ping you [13:17] mvo, i have to dig them up, bug 1500020 is definitely one [13:17] bug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] https://launchpad.net/bugs/1500020 [13:18] i had three, i think i closed two of them already [13:18] all regessions from the last additions of packages for the amd64 images [13:19] we definitely need to improve our milestone process for bugs ... perhaps just create ten in advance in LP or so so that doesnt get forgotten [13:36] jdstrand: back [13:36] mvo: hi! [13:37] ogra_: yeah, this time the sprint made the timing really awkward [13:37] mvo: I am writing up some documentation and noticed the new socket* and listen-stream directives for services. can you give me a two sentence summary of the feature? [13:38] (just so we are on the same page-- I think I know what's going on from the docs, but I have followup questions) [13:38] jdstrand: hm, it allows socket activated daemons with snappy [13:39] jdstrand: the patch comes from kickinz1 for docker [13:39] I see [13:39] jdstrand: I think its somewhat documented in meta.md [13:39] mvo: listen-stream says "The full path of the stream socket". is this a named socket? [13:39] * jdstrand was looking at https://developer.ubuntu.com/en/snappy/guides/package-metadata/ [13:40] uh, its poorly documented in docs/meta.md - but at least its mentioned [13:41] jdstrand: it can be both a path or a abstract socket with @foo [13:41] jdstrand: or a port (haven't tested that though) [13:42] mvo: are there any checks to make sure that a named path falls within the app-specific directories? does the abstract socket use namespacing? (eg, if pkgname is foo, check that abstract matches @foo_...) [13:42] jdstrand: its essentially what SYSTEMD.SOCKET(5) is doing [13:42] jdstrand: no checks currently, no [13:42] ok, so I can make some review tools checks for those [13:43] basically, I'll say its ok if it matches the app-specific TMPDIR or SNAP_APP_DATA_PATH [13:43] and I'll do what I suggested for the abstract socket [13:43] mvo: does that sound reasonable? [13:43] jdstrand: yes! [13:43] jdstrand: thanks a lot! [13:43] ok [13:44] now, for the bit that really concerns me: socket-user and socket-group [13:44] we don't assign UIDs or GIDs [13:44] how are these supposed to work? [13:45] jdstrand: welllllll they work for docker because there is a docker user on the image, but they don't work for anything else right now [13:45]