/srv/irclogs.ubuntu.com/2018/04/16/#snappy.txt

mupPR snapcraft#1943 closed: Release/2.39.2+18.04 (DO NOT MERGE) <do-not-merge-yet> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1943>04:00
mupPR snapcraft#2078 opened: Release/2.41+18.04 <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2078>04:18
pbekzyga: thanks a lot for your patience. so the most common way for a download tool like https://github.com/pbek/lmdownload is to tell the user that they only can download files to their home folder if they are installing the snap package?04:34
mborzeckimorning05:10
=== King_InuYasha is now known as Son_Goku
zygagood morning05:44
mborzeckizyga: hello05:44
zygapbek: I'm not sure I understand, is the download tool itsel a snap?05:45
zygahey :)05:45
* zyga is a bit hurt today :)05:45
pbekgood morning, zyga05:45
pbekyes, the tool downloads pdfs to the current folder and is snapped05:46
pbekhttps://github.com/pbek/lmdownload/blob/develop/snap/snapcraft.yaml05:46
pbekbut of course downloading just works in the /home folder when the tool is started as snap05:47
zygapbek: you can check if you are in /var/lib/snapd/void, if so, tell the user to do something else05:47
zygapbek: that directory is used if the original working directory cannot be represented in a snap05:48
zygamvo: some good news, the leak is gone05:49
zygamvo: but the case is not fully cloesd, we need to talk to the kernel team05:49
pbekzyga: strange, the tool never told me that it was in that directory (I print out the directory where the tool wants to strore the pdf file). the directory was always the one I really was in bash, but I got a write permissions error when I was storing the file. the tool is written in go05:51
zygapbek: it only does so if it is in a directory that cannot be represented05:51
zygapbek: it may be in a directory that is represented but cannot be written to05:51
pbekzyga: ok, I can output a more propper error message then,  but I cannot get around the fact that the tool can only write to the home-folder while in snap confinement, right?05:54
zygapbek: that's correct05:54
zygapbek: snaps should wite to $SNAP_USER_DATA or $SNAP_USER_COMMON05:55
pbekthank you again for your patience, zyga!05:55
zygapbek: eventually you may use xdg portals to write to more places05:55
pbekyes, I found that out already (and am using using it for storing settings)05:55
mvozyga: hey, good morning. yeah, I saw the mail05:55
mupPR snapd#5050 opened:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5050>06:37
* zyga tries to get through his inbox today06:40
mupPR snapd#5051 opened: snap,wrappers: address review feedback from #5043 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5051>06:54
mupPR snapd#5044 closed: 'system' nickname for 'core' in snap get/set (2.32) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5044>07:01
mupPR snapd#5045 closed: overlord/snapstate:  poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5045>07:02
pstolowskimorning07:16
zygahey pawel07:20
* zyga spent all of saturday and sunday outdoors, walking and biking a lot07:20
zygaand now endures the pain in all kinds of places :)07:20
mborzeckiif anyone feels like doing some reading https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/500107:25
zygamborzecki: yeah07:27
mborzeckibtw. i think there's a bug in nm, some signal not emitted at the right time/place07:28
mborzeckiat least when switching connection to metered from the cli, you don't see the Metered property changed on the main NM object07:28
mborzeckihad to restart NM and then it got updated07:28
ackkhi, is there a fix for the pip error when building a python package with snacraft: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmp7036_63f', '/home/ack/canonical/src/gitlptools/parts/gitlptools/install/usr/bin/python3', '-m', 'pip']' returned non-zero exit status 107:32
zygamborzecki: replied07:39
mborzeckizyga: good points07:39
kalikianagood morning07:40
zygaPharaoh_Atem: snap-confine package contains all kinds of things in fedora07:41
zygaPharaoh_Atem: we should really disband that package and move those files over to snapd07:42
mborzeckidisband ;) reminds me of civ07:43
zygamborzecki: ha, yeah07:50
zygadisband militia in 2050 :)07:50
=== mborzeck1 is now known as mborzecki
Chipacamoin moin08:14
mborzeck1wow, my network is flaky today08:15
zygamvo: I will update the GitHub release page08:16
zygaalthough I plan to skip the .1 and .2 tarballs08:16
zygajust go to .408:16
zygaI will use it to make the openSUSE release now08:16
=== mborzeck1 is now known as mborzecki
pedronismvo: hi, are you going to create .5 today?08:19
mvopedronis: yes, I will do that hopefully ready around lunch time. do you have anything pending?08:29
pedronisno08:30
pedronisI saw you merged the doMountSanp/readInfo stuff08:31
zygapedronis: can you update https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954 to include the latest status of that issue please08:32
mvopedronis: yeah, I looked over it and it looked like a good idea to have it08:33
pedronisI'll update it in a bit08:36
mborzecki#3 is wontfix, #4 has had some error-catching fixes, #5 is almost fixed right?08:36
mborzeckiany prs needing reviews?08:50
zygaCan you look at my trespassing pr08:52
mborzeckizyga: #4889 ? already did08:53
mupPR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>08:53
zygaAh, then no idea :-)08:53
mborzeckizyga: btw. it needs deconflicting08:53
zygaOh thanks. I’ll do that shortly08:53
mborzecki#4983 needs a second review09:05
mupPR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>09:05
Chipacacan't linux mint run classic snaps?09:12
mborzeckiis there a way to tell what type of confinement is supported by the system, other than running `snap debug confinement` ?09:14
pedroniszyga: updated09:17
zygathanks!09:17
Chipacamborzecki: what do you mean?09:18
Chipacamborzecki: http snapd:///v2/system-info | jq .result.confinement09:20
Chipacamborzecki: ?09:20
mborzeckiChipaca: when you run `snap debug confinement` you actually see the confinement mode supported on the host (strict|partial), but I don't see a way to get this information using cli and not 'debug' command (which is hidden btw)09:20
Chipacamborzecki: AFAIK there isn't09:22
Chipacamborzecki: i mean, not via 'snap'09:22
Chipacamborzecki: maybe we want it in 'snap version' or sth?09:22
Chipacamborzecki: (what for?)09:23
mborzeckiChipaca: when the user runs hello-world.evil they will on unconfined system they will see the message 'If you see this line the confinement is not working correctly, please file a bug', but they may not have confinement in the first place09:23
Chipacamborzecki: 'please file a bug with your distribution' :-p09:24
mborzeckii was thinking that we could update the message with eg. 'Try running snap version to check if your system supports confinement blah blah'09:24
Chipacamborzecki: why not make .evil run 'snap debug confinement' or equivalent itself?09:25
mborzeckiChipaca: hm doable, but snap debug is hidden (or pretends to be at least), snap version would be nicer, https://paste.ubuntu.com/p/JRn57pP99Q/09:26
Chipacamborzecki: is this on arch btw?09:26
mborzeckiChipaca: yes09:27
Chipacamborzecki: is there any info we could put next to 'arch' in the output of 'snap version'?09:33
Chipacai know it's rolling, but maybe, the time of the last update?09:34
Chipacadunno09:34
Chipacamborzecki: we could add confinement to distro info instead of as a new line if the new line is frowned on09:34
mborzeckiChipaca: - ?09:34
mborzeckiChipaca: https://paste.ubuntu.com/p/CGJZ9XPnSv/09:36
Chipacamborzecki: aw :-) ok09:37
zygaIMO putting this on the distribution version is silly09:38
zygalet's just do it properly09:38
zygaconfinement: seccomp(...), cgroup(device, freezer), namespace(mount), apparmor(...)09:38
Chipacazyga: note that that's not exposed via system info yet09:41
Chipaca+1 to it or something like it if it were09:41
mupPR snapd#5050 closed:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5050>09:42
mborzeckizyga: seccomp(...) as in actions?09:42
zygayeah, some version details there09:42
mborzeckihmm maybe we should have a separate `snap confinement` command or some --verbose switch to snap version, this is getting a bit verbose09:49
mborzeckithen we could print apparmor features, seccomp actions, available cgroups (those that are mounted), and namespaces (those listed under /proc/$$/ns of snapd daemon)09:50
zygamvo: updated https://github.com/snapcore/snapd/releases/tag/2.32.409:57
zygamborzecki: I think we have too many commands but I agree we should have some way to s how this09:57
zygamborzecki: I doubt most users will undertstand more than I said initially on a single-line confinement value09:58
mborzeckiok, so maybe `confinement: (strict|partial)` in snap version is all that we need09:58
mvozyga: thanks! .5 is rolling forward09:59
pedronismvo: so .5 doesn't include 5051 ?10:01
mupPR snapd#5052 opened: cmd/snap: handle distros with no version ID <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>10:02
mborzeckiChipaca: ^^10:02
mvopedronis: no, I think its fine, its cosmetic but if you feel strongly about it I can include it too10:02
zygamvo: that's odd, we had that patched before10:04
Chipacamborzecki: +110:04
zygaah10:04
zygaI see what the patch does now10:04
zygamvo: ping me when .5 tarball is up10:04
popeycorediddledan: you havint trouble with irccloud today?10:05
popeycorefails to launch here on core stable, and I just get 3 dots in the screen constantly10:05
pedronismvo: mostly fearing a bit of confusion  about the log,  and if we need to do a .610:06
* zyga does /o\10:06
zygawhy would we need a 6?10:06
pedronisexactly, we don't know10:06
pedronisthat's how that stuff happens10:06
mvozyga: what is odd?10:09
zygamvo: nothing, I misunderstood the output10:09
zygamvo: - vs ""10:09
mvopedronis: ok, I will pull it into release/2.32 just in case we need a .610:09
mvopedronis: it does make sense10:09
zygamvo: https://github.com/snapcore/snapd/pull/505310:09
mupPR #5053: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>10:09
mvozyga: ta, I have a look. .5 is available in the ppa, one sec, I look for a direct link for you10:10
zygamvo: FYI I have tested jj's fix and it's stable over extended periods of time10:10
zygamvo: oh, neat10:10
zygajust push the tag, I'll do the rest :)10:10
mvozyga: tag is pushed as well10:10
mupPR snapd#5051 closed: snap,wrappers: address review feedback from #5043 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5051>10:10
mupPR snapd#5053 opened: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>10:10
mvozyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8990918/+listing-archive-extra has the build10:10
zygaSon_Goku: good morning10:10
popeycorediddledan: must have been corrupted config, removed and reinstalled the snap and it's fine \o/10:12
mupPR snapd#5054 opened: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>10:12
mupPR snapd#5055 opened: release: 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5055>10:15
zygamvo: https://github.com/snapcore/snapd/releases/tag/2.32.510:20
zygacan you please check if I got the refresh/stop mode bits right10:21
zygamvo: .5 failed to build for ppc10:23
mvozyga: looking, I suspect a stray failure10:23
zygapedronis: https://bugs.launchpad.net/snappy/+bug/176406910:24
mupBug #1764069: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:New> <https://launchpad.net/bugs/1764069>10:25
* zyga -> walk10:32
zygapopey: notepad++ looks bad on high-dpi system10:32
zyganot sure if there's anything we can do to tell wine" hide"10:32
zyga"hidpi"10:32
popeyIndeed10:32
popeyWe don't pass through pixel doubling in some apps10:33
popeynot just WINE10:33
Chipacapopey: do you know what we need to pass through?10:37
popeyi dont think there is anything we can do for WINE, but for some other apps, Wimpress mentioned looked bad on his hidpi machine, i think he knows10:37
* Chipaca tries to make a joke about sulphites, and fails10:38
mupPR snapd#5052 closed: cmd/snap: handle distros with no version ID <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>10:46
mborzecki5052 for 2.32 in case we do a .6 release? ;)10:46
Chipacamborzecki: too much regression potential10:48
Chipaca:-p10:49
pedroniszyga: afaict that's a DNS problem10:49
zygaOk10:53
pedronismvo: this changelog line looks strange:   daemon: support 'system' as nickname of the core snapchange it is10:59
pedronis+      possible to do:10:59
pedronischange it is ...  seems spurious11:00
mborzeckipedronis: my fault, i tend to include how the command output looks like in the commit messages11:03
pedronisI'm not sure, the whitespace is wrong either way11:04
mvopedronis: yeah, the whitespace there is incorrect. good catch11:08
mvopedronis: look like the script that generates them has a bug there, I look into it11:08
mupPR snapd#5056 opened: cmd/snap: make confinement mode part of `snap version` output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5056>11:16
* Chipaca trundles off in search of something to lunch11:17
zygare11:23
* zyga works on .5 release for opensuse11:23
=== pstolowski is now known as pstolowski|lunch
Chipacazyga: .6 is where it's at11:25
* Chipaca runs11:25
zygaChipaca: what?!?11:25
zygaare we doing a .6 now11:25
zygais this what "eventually released" software is like?11:26
pedronis.5.4.3.2.111:32
mborzeckiapproximating towards 2.3311:33
zygaChipaca: should we use LazyUnmount= in our .mount units?11:34
pedroniseffectively :)11:34
pedronis(that was about approx 2.33)11:34
cachiomvo, should I start testing .5 or I should wait for a .6?11:35
pedroniscachio: I don't think we plan a .6 atm11:35
cachiopedronis, ah, ok11:36
cachiothanks, I'll run beta validation for .5 in that case11:36
cachiomborzecki, hey, amazon linux image is ready11:37
cachiobut you just can use it11:37
cachioif you use this spread11:37
zyga2.32.4 is building for all opensuse systems now11:37
cachiomborzecki, https://github.com/snapcore/spread/pull/5711:37
mupPR spread#57: Adding preserve option for systems to keep the default image size <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/57>11:37
cachiomborzecki, beasuse the filesystem cannot be resized11:37
mborzeckicachio: what's the system name in spread.yaml?11:38
cachiomborzecki, basically it is not possible to shrink xfs filesystems11:38
cachio            - amazon-linux-2-64:11:39
cachio                workers: 111:39
cachio                preserve: true11:39
cachiomborzecki, you can add that11:39
cachiowith that branch11:39
mborzeckiok11:41
cachiomborzecki, I'll going the the kinesiology now, I'll explain better during the standup11:41
mborzeckicachio: i'll try to run it, thanks11:41
cachiomvo, there is not changelog for 2.32.4 -> 2.32.511:42
zygacachio: I made "some" changelog11:45
zygacachio: https://github.com/snapcore/snapd/releases/2.32.511:45
zygaCaelum: I updated snapd twice to 2.32.4 and now to 2.32.511:51
zygaCaelum: let me know if you run into any issues11:51
zygaCaelum: although this release should be very stable now11:51
zygamvo: maybe I could look at updating the debian package11:58
zygaPharaoh_Atem: I will have a small selinux patch for you to review soon11:59
zygadoes anyone know what networkd-dispatcher is for?12:01
zygamvo: how is our upload to bionic like?12:02
zygamvo: can we upload .5 now?12:02
zygaand similar question about xenial SRU12:02
mborzeckioff to get the kids12:03
popeymborzecki: when you return - did you have any luck with nvidia on 18.04? I got from zyga  that it's somewhat of a lost cause?12:08
zygapopey: with classic snaps12:09
zygapopey: otherwise it should work12:09
zygapopey: with classic snaps it can work but the snap needs to understand the particular layout of the host12:09
popeyThis needs documenting somewhere.12:09
zygapopey: yes, no disagreement there12:13
zygamvo: when we have more bases and more core18 things12:15
zygamvo: I was thinking that we should drop the "series 16" line from snap version12:16
zygawe could show it on core devices12:16
zygaand actually show the name of the bootable base12:16
zygaI think right now it's not a very useful/informative thing12:16
mupBug #1764069 changed: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:Invalid> <https://launchpad.net/bugs/1764069>12:18
zygamvo: hey, is issue #5 solved with 2.32.5 now?12:18
mupPR snapd#4833 closed: tests: add a detector for kernel bug https://pad.lv/1755563 <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4833>12:20
zygamvo: given that #5043 is for 2.32.x, do you still plan to make additional release (that is, .6)?12:23
mupPR #5043: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode <Critical> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5043>12:23
mvozyga: reading backlog now12:28
mvocachio: http://people.canonical.com/~mvo/core-changes/html/beta/2.32.4r4443_2.32.5r4486.html <- that looks ok (modulo missing space)12:30
pstolowski|lunchSon_Goku: hey! I've proposed go-udev https://bugzilla.redhat.com/show_bug.cgi?id=1567819 but just got a comment there that go packaging has been revamped? haven't yet looked at the guidelines12:31
mvozyga: 5043 has lnaded in .5, no?12:32
mvozyga: or what am I missing?12:32
* kalikiana lunch12:32
zygamvo: has it? the branch is open12:33
zygaah12:33
zygasorry12:33
zygaI mean 505412:33
zygamvo: I think my question was about the status of the forum post, if issue #5 is fixed let's mark it as solved12:34
mvozyga: checking12:34
Son_Gokupstolowski|lunch, I think he's talking about this new form: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/blob/master/f/golang-gopkg-yaml.spec12:34
mvomup #505412:35
mupPR #5054: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>12:35
zygamvo: offtopic, remember those 100s of threads? my bionic shows 11 threads in .512:35
mvozyga: 5054 is just cosmetic, but given the amount of questions about it I should have included it. its now in release/2.32 so *if* there is anohter one it will be in12:35
mvozyga: I do remember that12:35
zygamvo: understood now, thanks12:35
pstolowski|lunchSon_Goku: okay, i'll dig into the new guideline after lunch12:35
mvozyga: thank you! so the 100s threads I don't see on my two bionic machines12:36
mvozyga: so not sure what is going on there12:36
Chipacahuh, gnome software has a 'restart and install' button12:36
mvozyga: #5 *should* be fixed in beta but I hope to get confirmation from a real world test case later today12:36
mvoChipaca: for installing updates?12:36
zygaChipaca: yes, for some years now :)12:37
mvocachio: thanks for the sru validation!12:37
Chipacamvo: I'm guessing what it describes as firmware is a bios update12:37
zygaChipaca: it's a very old systemd/fedora/pkgkit feature12:37
mvocachio: also yeah beta validation for .5 sounds great!12:37
zygait's not related to firmware12:37
zygait's related to a mode where all updates are downloaded but not installed, the machine reboots and goes into a special boot mode where systemd installs all updates and reboots back to normal mode12:38
Son_Gokupstolowski|lunch, guideline in question is documented here: https://fedoraproject.org/wiki/More_Go_packaging12:39
Chipacazyga: I don't open gnome-software often (i've only recently had enough memory to keep it installed at all)12:39
mvozyga: what is the link to the 18.04 post again? then I can update #512:41
zygamvo: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/495412:41
mvozyga: ta!12:42
mvozyga: funny pr 4954 is also a fix for 2.32 as is the above forum topic (ok, maybe not that funny). i update it now12:43
mupPR #4954: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4954>12:43
mvozyga: updated, thanks you12:44
zygamvo: we have new pam and netplan12:46
mvozyga: yeah, changelog looks mostly harmless12:48
zygayes12:48
=== pstolowski|lunch is now known as pstolowski
kalikianare13:32
popeyzyga: to be clear, the snap which I am having trouble with is _not_ a classic snap.13:32
mborzeckiarch updated to 2.32.513:36
popeyI'll speak to snapcraft chaps, as it could be that.13:36
mborzeckipopey: still mame thing?13:37
popeyyeah13:37
mborzeckii posted the logs from friday in the LP bug report13:37
popeyyou mentioned rpath, but I dont know what *I* am doing wrong here13:37
popeyyeah, I saw.13:37
pstolowskiniemeyer: will you have some time to talk about hotplug after your current meeting?14:04
tyhicksmvo, zyga: hello! would you all be alright with the apparmor memory leak bug (bug #1750594) being fixed in the first SRU kernel of 18.04 or do you feel it is urgent enough that the 18.04 kernel be respun again before the release?14:29
mupBug #1750594: Eventual OOM with profile reloads <AppArmor:Fix Committed> <https://launchpad.net/bugs/1750594>14:29
zygatyhicks: I think it's not that critical, it only affects systems that run our test suite as far as we are aware14:30
mupPR snapcraft#2074 closed: Release changelog for 2.41 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2074>14:30
zygait's annoying but not user-critical from my POV14:30
zygamvo: ^14:30
zygatyhicks: will live kernel patches fix it?14:30
tyhicksthat's my understanding of the bug, as well14:30
tyhickszyga: no, we don't plan to do a livepatch for it14:30
tyhickswe'd really only want to respin if it affected installs or made the out of box experience bad but, AFAIK, this bug doesn't show up in normal use cases14:31
mvotyhicks: hi, in a meeting right now14:32
mvotyhicks: let me reply as quick as I can14:32
tyhicksthanks14:32
niemeyerpstolowski: I'm just off and have a few minutes before lunch.. can you talk now?14:35
pstolowskiniemeyer: yes14:36
niemeyerpstolowski: Ok, standup then14:36
=== deanman_ is now known as deanman
mupPR snapd#5057 opened: tests: bring back one missing test in snap-service-stop-mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5057>14:47
Chipacaniemeyer: 10MB unaccounted for after creating a bolt db. Will continue digging.14:53
ChipacaRSS of a simple thing goes from 4MB to 14MB14:53
niemeyerChipaca: That sounds very promising14:54
niemeyerChipaca: One data point worth gathering is what happens if we open that same file in RO mode14:55
Chipacaniemeyer: 8MB rss14:57
pstolowskipedronis: hey, will you find some time this week to make another pass on iterface hooks PR? i've addressed your last comments14:57
niemeyerChipaca: Unaccounted or total? That is, 4 to 12, or 4 to 8?14:58
Chipacaniemeyer: actually 10MB if the code to create it is still there, just not used14:58
Chipacaniemeyer: total14:58
* Chipaca needs to step away for a bit, will bbl14:58
Chipacaniemeyer: time.Sleep -> 4MB, ro bolt: 8MB, ro bolt and rw code unused: 10MB; rw bolt: 14MB15:02
* Chipaca afk15:02
cachiomvo, https://paste.ubuntu.com/p/Z59BDC4VWq/15:04
cachiorunning beta validation for 64 bits15:04
cachiomvo, it is like the system was rebooted after line 5315:05
cachiobut it shouldn't15:05
mvocachio: yeah, this is stange, anything in syslog?15:06
mborzeckiChipaca: hacked a small tool that prints package sizes (*.a that end up in the binary, unless go does some lto at the end) https://gist.github.com/bboozzoo/a363e591075cb4d4faae39b4066ac41115:06
cachiomvo, this is from syslog15:06
cachiomvo, I already saw that doing refresh from stable too15:07
cachiosimilar problem15:07
mvocachio: uh uh15:08
mvocachio: is this on a core device? or 16.04?15:08
cachiomvo, from journalctl https://paste.ubuntu.com/p/DsqmKfDGNv/15:09
cachioit is core-16-6415:10
cachioa vm15:10
mvothis is very uncommon15:10
mvoApr 16 14:31:53 localhost.localdomain snapd[993]:  ERROR cannot open snap: open /tmp/snapd-sideload-pkg-105860667: no such file or directory15:10
mupPR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>15:10
cachiomvo, yes, first time I see this15:10
mvocachio: confusing15:12
cachiomvo, this has more info https://paste.ubuntu.com/p/2ty37JM39W/15:13
mvocachio: yeah, more info but still very confusing. I wonder what change from .4 -> .5 might cause this :(15:15
niemeyerChipaca: Hmm.. are we keeping the file open? If we close the database and discard the structure, does the extra RSS memory go away?15:15
oSoMoNthe latest build of the chromium snap on launchpad failed automated review in the store ("checksums do not match"), is that a known issue with the store/snapcraft, or could it be just that specific snap?15:15
mvocachio: is it reproducible?15:15
niemeyerChipaca: If it doesn't, that must be a bug15:15
niemeyerChipaca: If it does, then we should probably just do that for the release15:15
cachiomvo, I don't know15:15
cachioI'll try15:15
mvocachio: thank you!15:15
niemeyerChipaca: Or at least keep it RO, if it impacts runtime of advice too much15:16
mvocachio: it looks very fishy, is this in a VM ? or on real HW?15:16
* niemeyer lunch15:16
cachiomvo, it is a vm15:16
mvocachio: hm, hm, then that is double confusing15:16
mvocachio: I was wondering if there might be some HW issue that triggered the reboot but not in a VM15:17
mvo(usually)15:17
cachioin parallel I was running i38615:17
cachioand it worked fine15:17
mvocachio: it *might* be the oom issue but given that we have not seen that beforre on non !i386 its unlikely15:17
mvocachio: ok, cool. at least that is good to know15:17
oSoMoNI just rebuilt the chromium snap again on launchpad, and got the same error (checksums do not match) : https://code.launchpad.net/~chromium-team/+snap/chromium-snap-stable/+build/19303315:36
oSoMoNknown issue?15:36
oSoMoNah, apparently it is bug #176364115:37
mupBug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>15:37
oSoMoNhowever the bug says that this shouldn't happen with snapcraft 2.40, but the chromium snap is built on LP and the log says it's using snapcraft 2.40 (deb)15:42
mupPR snapcraft#2079 opened: repo: catch error updating the package cache <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2079>15:42
Caelumzyga: nice, will look in a bit, and also post to factory list15:43
zygaThanks!15:51
pedronismvo: that's the new checking code in doMountSnap15:54
mupPR snapd#5055 closed: release: 2.32.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5055>15:55
mvopedronis: oh, so it already caught a case where things did not quite work correctly?15:57
mupPR snapd#5058 opened: packaging: fix incorrectly auto-generated changelog entry for 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5058>15:57
pedronismvo: maybe, or we are misunderstanding something15:57
mvocachio: -^15:58
cachiomvo, not yet15:58
mvopedronis: cool, I need to leave in a wee bit to play hockey but I will read backlog, would be great to learn if we introduced a regression15:59
cachioworking on that15:59
mvocachio: thank you15:59
sergiusenszyga, jdstrand any insight on https://paste.ubuntu.com/p/ZP6R7WM4Kz/ ?15:59
mvocachio: just wanted to let you know that pedronis  has an idea where the error comes from but its not clear yet if it is just making an existing error visible or if its something new15:59
cachiomvo, ok16:00
cachiomvo, perhaps it is not new but it is cannot be reproduced easily16:00
cachiomvo, I'll make many executions today to see if I can reproduce it16:01
cachiomvo, pedronis  I'll keep you updated in case I find something16:01
mvocachio: thank you!16:02
mvocachio: thanks to pedronis we have much improved error checking around this area of code now, so maybe it surfaces something that existed before. I will read backlog, need to play hockey now16:03
cachiomvo, nice, enjoy it16:03
mvocachio: thank you! yeah, I am excited16:04
pedroniscachio: it's strange because it seems we are rebooting in the middle of installing a local snap16:10
pedronisChipaca: what happens if we reboot when installing a local snap?  it seems the snap is copied into /tmp, but tmp will be cleared on reboot16:11
pedroniscachio: am I misreading that there's a reboot going on at the start of that test?16:13
pedroniscachio: do we have a bug about stopping refreshes during some of the core tests?16:14
* kalikiana eod16:17
=== JanC_ is now known as JanC
cachiopedronis, I don't think so, but let me re-check16:19
Chipacapedronis: AFAIK it fails if it happens before the (snap.Container).Install, otherwise it succeeds16:28
Chipacapedronis: (that's the bit that copies the local snap into /var/lib/snapd/snaps iirc)16:28
pedronisit seems we are hitting the scenario in a test16:28
Chipacahehe16:28
pedronisbut I'm not sure why there is rebooting going on though16:29
pedronisChipaca: do you agree that there is some system restarting going on here:  https://paste.ubuntu.com/p/DsqmKfDGNv/ ?16:30
pedronisthere's too much starting, early, stuff and systemd talking about early boot stuff16:31
Chipacaniemeyer: we are not keeping the file open, and we do a commit and close on the db16:31
pedronisChipaca: another theory is that snapd and the test starts before the cleaning of tmp happens16:31
Chipacaniemeyer: the only reason snapd uses boltdb is to write that databse, having it ro is like not having it16:31
niemeyerThat's pretty awkward. Why would the memory stay resident16:32
Chipacapedronis: looking16:32
pedronisbu that makes sense only if tmp is not a tmpfs16:32
Chipacaniemeyer: MAGIC16:32
niemeyerChipaca: I guess Go's GC16:32
niemeyerChipaca: There is (was?) a method in the runtime package to "encourage" the GC to give memory back to the system16:33
Chipacapedronis: no that doesn't look like early boot stuff16:34
Chipacapedronis: it looks like snapd starts, and systemd says 'ok i'm done'16:34
Chipacaniemeyer: runtime.GC()?16:34
niemeyerChipaca: No, that just kicks the GC.. let me check16:36
pedronisChipaca: but we are after a reboot, right?16:36
pedronisChipaca: otherewise there would not be that Reached target stuff16:37
Chipacaniemeyer: runtime/debug's FreeOSMemory?16:37
niemeyerYes!16:37
cachiopedronis, now error on i386 https://paste.ubuntu.com/p/hkxVgZDZgk/16:38
pedronisI don't see an "error" in that log16:39
Chipacaniemeyer: it helps a little (14 -> 12 for rw, 10->9 for ro w/unused rw)16:40
cachiopedronis, this is for 64 bits https://paste.ubuntu.com/p/5MHzmfjJP8/16:40
cachiopedronis, no errors16:41
cachiobut suddenly rebooted16:41
pedronisah16:41
pedronisso we are getting reboots16:41
cachiopedronis, yes16:41
pedronisI don't see anything about "core" in those logs16:42
pedronisnot sure what would provoke reboots16:42
pedronisthat is new16:42
pedronisI understand why reboot would make other things fail16:42
pedronisbut not what make us reboot16:42
* pedronis -> dinner16:42
Chipacablame spectre16:49
oSoMoNjdstrand, have you seen my comment on bug #1763641 ? If I read the bug correctly I shouldn't be seeing this error with snapcraft 2.40, but I am16:50
mupBug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>16:50
oSoMoNI ran reviews-tool from edge on the snap and got no such error16:50
zygasergiusens: did corebird work before?16:56
zygaPAM got updated recently but I don’t think we’d break abi16:56
diddledanI might have told the build to not prime libkrb516:58
pedroniszyga: we are getting random reboots on .517:13
pedroniscachio: we didn't see these reboots with .4 ?17:13
zygaHmmmm17:14
zygaWhat do we know?17:14
cachionot for beta scenario at least17:14
zyga.5 has new PAM and nplan17:14
diddledandanke popey17:14
popeyI didnt know we had source-checksum!17:15
popeyTIL17:15
diddledaninorite17:15
cachiopedronis, I just saw some problems but for factory release to beta17:15
zygaChangelog from for .5 is not extensive, mainly new API and a bugfix17:15
zygaIs there any chance this is caused by new stop restart mode17:16
* Chipaca afk17:16
cachiopedronis, zyga perhaps something else in the beta image it is causing this17:16
cachionew kernel17:16
zygaOh17:16
zygaWhich one?17:16
zygaI will be home soon17:18
zygapedronis: who reported this and how?17:21
pedroniscachio17:21
pedronisrunning the validation17:21
cachiozyga, at least for dragonboard there was a new one17:21
cachiopedronis, there are 2 scenarios, first is to create a beta image  and run  the tests for that image17:22
cachiolast execution I didn't see any error17:22
cachiopedronis, this time I saw this reboot17:22
cachiopedronis, but it is not failing 100% of the cases17:23
cachioso, perhaps the same error was present in the previous validation and I did not reproduce it17:23
cachiobut today first exec I saw the errror17:24
cachiofor core-16-6417:24
cachioand core-16-32 worked properly17:24
cachio100% pass17:24
zygacachio: on what hardware?17:25
cachiothen I rexecuted both and both failed17:25
cachioI am running those on vms17:25
pedronisprobably worth trying  a couple runs with .4 I suppose17:25
zygaSo amd64/kvm17:25
pedronisto see if it's really .517:25
zygaYes17:25
zygaLet’s test .4 in the same host17:25
cachiook17:26
cachioI'll do that17:26
zygaThank you17:26
pedronisof course if it's new kernel we need to separate that somehow17:27
zygaIt could also be the oom bug17:29
pedronisdoes it provokes reboots though?17:30
zygaIt is disabled on 32bit systems but also happens on 64 big systems the same,  just takes longer17:30
pedronisor only errors?17:30
zygaIt eats all ram over time till kernel crashes17:30
zygaWith swap it’s a slow painful death17:30
zygaWithout swap it is quick and clear17:30
zygaAs an option we can do .6 with one of my workarounds17:32
diddledanfor the coders among us, Brenden Eich on Javascript's evolution: https://www.youtube.com/watch?v=3-9fnjzmXWA17:47
ogra_there are coders among us ?17:54
* popey steps back17:57
kyrofaYes, but I heard the word "javascript" and ran17:58
diddledan:-p17:58
* zyga looks at the reboot issue17:59
zygapedronis, cachio: we have a forum thread for the problem?17:59
cachiozyga, no yet18:09
cachiozyga, I'll create it18:10
zygathank you18:10
zygathe pastebin I read looks very weird, I doubt that's OOM18:15
zygait looks like we really trigger a graceful shutdown shomehow18:16
zygacachio: does it happen in one spot or in some random place during testing18:16
cachiothe pattern that I saw in the syslog is18:17
cachiohttps://paste.ubuntu.com/p/DVJNqD5yHP/18:18
cachioin all the cases I saw something like this before the reboot18:18
nacchow can i change the owner of a snap in the store18:19
cachiozyga, and then this18:20
cachiohttps://paste.ubuntu.com/p/vTM3bYx2Ph/18:20
cachioI am running now 16-2.32.4 to see if I can reproduce it18:21
cachiozyga, I thinks  2/3 cases happened installing snapd18:23
cachiosnaps18:23
* zyga dinner, I will check soon18:23
nacci specifically need to adjust the ownership of git-ubuntu, git-ubuntu-stable and git-ubuntu-beta away from my user18:26
sergiusensnacc: to canonical, snapcrafters or another individual user?18:41
popeynacc: post on the forum in the store category18:45
kyrofaHey niemeyer, I can't get the LXD backend of spread to ever work for 17.10 or 18.04, they always end up failing with "2018-04-16 19:01:30 Discarding lxd:ubuntu-17.10 (spread-8-ubuntu-17-10), cannot connect: cannot connect to lxd:ubuntu-17.10 (spread-8-ubuntu-17-10): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain"19:06
kyrofaAny ideas?19:06
om26erpopey: up ?19:09
popeyom26er: yo!19:09
om26eroh boy you are always online, cool.19:09
om26erpopey: sublime is broken and I hope we can land its fix ASAP.19:10
om26erwe do have it published in edge channel but it won't start19:10
popeyok, let me take a look now.19:10
popeyoh, it's classic. Are you on nvidia?19:10
om26erpopey: no, Intel19:11
popeyok, lemme see19:11
popeyok, merged your PR, lets see what that builds19:14
om26ergreat stuff.19:14
om26erthanks popey19:14
popeynp19:14
zygacachio: any news19:17
cachioI ran 2.32.4 and I didn't see any error yet19:18
cachiozyga, I am re-executing now19:18
zygacan you upload the manifest19:19
cachioI created images using candidate19:19
cachiochannel19:19
cachioand ran the tests19:19
cachiozyga, but no errors yet19:19
cachiozyga, the same it is failing 66% of the times on beta19:19
zygacachio: so mvo suggested some ideas19:19
zygacan you upload the manifests somewhere19:19
cachiozyga, sure19:20
zygamvo said it would be in /usr/share/dpkg/snap* something19:20
zygaalso how big is the image19:20
zygacan you upload the failing image as you got it now19:20
cachiozyga, sure19:21
zygathanks!19:21
cachioit is also very easy to generate it19:21
cachioand faster19:21
cachiowith my wifi it could take long to upload19:21
cachiozyga, clone git@github.com:sergiocazzolato/validator.git19:21
cachioand then run19:21
cachio./create.sh beta pc-amd6419:22
cachio./create.sh beta pc-i38619:22
zygatrying19:22
cachiothat will be faster19:22
zygawhich ubuntu-image are you using?19:23
zygafrom deb/snap19:23
zygaand which version19:23
cachiodeb19:23
cachioubuntu-image 1.3+16.04ubuntu219:24
zygaI'm on 1.3+18.04ubuntu219:25
zygabut I'll make an image and try this way first19:25
zygaif my image works can you upload your image19:25
zygawe can compare binary stuff inside19:25
cachiozyga, sure19:25
zygamaybe overnight19:26
zygaso we can analyze tomorrow19:26
niemeyerkyrofa: I think there is a patch from Saviq that fixes that, from long ago.. sorry for not having merged it yet.. will try to have a look today still19:31
kyrofaniemeyer, ah, excellent, okay thank you19:31
zygacachio: my dpkg.list from /usr/share/snappy/dpkg.list http://paste.ubuntu.com/p/JWPqJFWH7D/19:31
zygacachio: can you check if you have the same one19:31
zygacachio: I'm running kernel 4.4.0-121-generic19:32
kyrofaYep, that looks like it19:32
cachiook19:32
zygacachio: are you running the same thing on your test machine?19:39
cachiozyga, checking19:40
cachiozyga, the kernel is the same19:42
cachiozyga, same19:43
cachiothe list is the same19:43
zygaok, thanks19:43
cachiozyga, I am running again now19:43
mvocachio: I just chatted with zyga and he told me about the reboot issues (and you did so as well earlier). I just checked, might be worth running with the kernel from stable, looks like the kernel in beta got released just today20:01
cachiomvo, you mean the kernel snap?20:02
zygayes20:03
mvocachio: yes20:03
cachiolet me cehck that20:03
mvocachio: I was just looking at the things that changed recently and noticed that this might be something20:03
mvocachio: I will also run the testsuite against a freshly build image to see if I can find any clues20:04
cachiomvo, I just created a new image 20 minutes ago20:04
cachioand I am running again against this new one20:04
cachioso far no errors20:05
cachiomvo, but just 31/199 yes20:05
cachioyet20:05
cachiomvo, I am in i386 and I have  pc-kernel  4.4.0-120.144  111   beta      canonical  kernel20:06
cachiothere is a new one in beta20:07
cachio4.4.0-121.14520:07
cachioI'll regenerate also i386 image to see if the problem persist20:07
mvocachio: thanks. I just build an amd64 image, is that correct?20:10
mvocachio: aha, nice if you have an i386 image with an older kernel its interessting to see if the new kernel changes anything20:10
cachiomvo, :(20:11
cachioI just delete it20:11
cachiooverwrite it20:11
mvocachio: no worries20:12
om26erpopey: https://github.com/snapcrafters/sublime-text/pull/1020:26
mupPR snapcrafters/sublime-text#10: Remove architectures stanza as it breaks auto builds <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/10>20:26
om26er...and this https://github.com/snapcrafters/android-studio/pull/20 (though not urgent)20:29
mupPR snapcrafters/android-studio#20: remove architectures stanza <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/20>20:29
popeyom26er: merged both20:30
popeythank you!20:30
om26ersuper!20:31
om26erwe probably need to define some kind of "trust" chain (equivalent of MOTU/Core dev ?), so that we don't always have to bug you to get things landed.20:33
popeythere are others who have access :)20:33
om26erapart from Martin, ev and you ? talking about snapcrafters repos only20:36
popeyyeah, currently the three of us20:36
om26erits generally difficult to get a hold of flexiondotorg20:36
popeyhe's Wimpress  now :)20:37
om26erev, I am not sure if he hangs around here.20:37
popeyhe doesn't20:37
om26eraah20:37
popeyhe hates irc20:37
popeylike, passionately :)20:37
WimpressIt is I20:37
WimpressAnd popey will burn in the embers of the heat death of the universe for being a lying #&$%20:38
om26eralright, its the two of you then ;-)20:38
mvocachio: tests with stable kernel still going strong, I had one issue with python3 /nsap/network-bind-consumer/x1/bin/consumer eating all cpu and producing log messages I think we need to ensure in the relevant test that we kill it20:38
WimpressI see the reference to hating IRC was not attributed to me.20:39
Wimpress#carryon20:39
om26erpopey: Wimpress still when snaps take over the world, MOTU/Core dev like access may be necessary.20:39
cachiomvo, which is the test?20:39
popeyom26er: well, ideally these would all be gone from snapcrafters and owned upstream :)20:39
om26ernot today, but hopefully soon -__-20:39
popey:)20:39
cachiomvo, I am rnnning refresh scenario too20:40
cachiomvo, let's see how it goes20:40
mvocachio: I'm not sure what test triggers this, just noticed20:41
cachiomvo, ok, I'll check it20:41
om26erpopey: sublime text is good now20:42
om26er\o/20:42
om26erzyga: ^ its in edge20:42
zygathanks!20:42
zygamvo: I have a helper snap for redirecting systemctl20:42
popeyom26er: alias works too?20:43
om26erpopey: yep, subl20:43
popeywow, that launches fast20:43
popeyom26er: released. thanks so much for all your work on this!20:43
popeySorry it took so long.20:43
popeyhttps://snapcraft.io/sublime-text20:44
mvocachio: and I noticed sometihng interessting too, when I log into the VM while the test is running I see a "system is going gown" message, so there is a planned reboot triggered by a test, for me the planned reboot message starts at 22:38 and the following tests run then http://paste.ubuntu.com/p/d3xsB4KQMP/ so one of these tests triggers a change that includes core/kernel which triggers the reboot20:44
om26erpopey: no problem, lets see if the upstream wants it now20:44
cachiomvo, weird20:45
popeymaybe wait till we promote it and get more installs :)20:45
cachioI didn't see any reboot scheduled20:45
cachiowell, there is a reboot schedulet but for a really long time20:45
cachiowhich should not be affecting the testst20:46
om26ersure20:46
mvocachio: if you ssh into the machine, do you get Broadcasting messages as well?20:46
cachiomvo, no20:46
cachioI just saw in the logs20:46
cachioin the vm I didn't see any broadcastig message20:46
zygamvo, cachio: sudo snap install systemctl-redirector --beta20:54
cachiozyga, what's this?20:54
zygathen touch /var/log/systemctl.fake.log20:54
zygathen sudo /snap/systemctl-redirector/current/bin/install20:55
zygathen run all tests20:55
zygain the end collect the log file20:55
zygathis logs all invocations of systemctl20:55
mupPR snapd#5059 opened: tests: add pending shutdown detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/5059>20:55
zyga(reboot and all kinds of systemctl commands)20:55
zygamvo: ideas for improvement welcome20:55
mvozyga: thanks, I also pushed the above pR to break when we detect something that triggered a shutdown20:57
zygayeah20:57
zygalooks good20:57
mvozyga: lets attack it from multiple angles20:57
mvocachio: iif you cherry pick the change from 5059 into your tree hopefully this also gives you an error when the shutdown is triggered20:58
mvocachio: when running -debug maybe it gives us clues20:58
zygacachio: if you run tests with this snap installed and with the install script invoked we should collect more info about what is going on20:58
cachiomvo, zyga, ok20:58
cachioI'll run it now20:59
mvota20:59
zygathanks20:59
mvoI will soon need to crahs :/20:59
mvobut I start the tests now to see if I also notice anything20:59
zygame too20:59
mvoand also login the VM to see any wall messages20:59
cachiowith the last kernel seems to be working better20:59
cachioI didn't see any reboot yet}20:59
zygacachio: I refreshed the systemctl-redirector snap to improve the log messages21:02
cachiook, I'll start a run in 10 minutes21:04
cachiozyga, could you reproduce the error?21:04
cachiowith the new kernel snap?21:04
zygaI didn't run full test run yet21:05
cachiozyga, I regenerated the image with the new kernel snap and I couldn't reproduce it anymore21:05
cachiozyga, wait21:06
cachioI did :)21:06
zygadid you install and configure my snap on your VM21:07
cachiozyga, https://paste.ubuntu.com/p/KMR33JvpyG/21:08
cachionot for this run21:08
cachioI'll do it for next one21:08
zygaApr 16 20:45:41 localhost kernel: [ 3071.152512] modprobe: page allocation failure: order:7, mode:0x208002421:09
mupPR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>21:09
cachiozyga, because if I install it during execution it is gonna be deleted on reset21:09
cachiozyga, yes21:09
zygaon reset?21:09
zygaah21:09
zygasnaps are removed :/21:09
zygalooks like we ran out of ram21:09
cachiozyga, I am configuring vms with -m 150021:09
cachiozyga so far it was enough21:10
zygacachio, mvo: the allocation that failed was for 524288 bytes21:11
zyganot a lot21:11
zygait looks like we ran out of ram, plain and simple21:11
mvozyga: I also run with a 1500m VM, interessting21:11
zygacachio: which kernel is that?21:11
mvoI keep it running21:11
zyga4.421:13
cachiozyga, pc-kernel                         4.4.0-121.145  113   beta21:13
zygaright, I see21:14
zygaguys, I need to go to sleep21:14
zygacachio: before you EOD write what you know on the forum21:14
cachiozyga, sure21:14
cachiozyga, go to bed :)21:14
zygaThank you. Good night!21:16
mvozyga, cachio I need to crash as well, I will keep the tests running and check in my morning, I run with beta kernel and the shutdown detection patch from the PR above21:17
* mvo waves21:17
kyrofanacc, any idea why building git-ubuntu on arm64 would fail unable to find ffi.h? libffi-dev seems to be in stage-packages21:37
kyrofaDoes it need to be a build-package as well?21:38
kyrofaNot sure how this is setup21:38
nacckyrofa: log?21:43
kyrofanacc, https://pastebin.ubuntu.com/p/mGjrtbBdfJ/21:45
kyrofanacc, note that this worked fine on amd6421:50
nacckyrofa: otp, looking now21:51
kyrofaNo problem21:51
nacckyrofa: i have no idea :/21:54
nacckyrofa: i've never tried to build on arm6421:54
kyrofanacc, ah, that's what I was going to ask21:54
kyrofaOkay, that's not unusual21:54
=== sergiusens_ is now known as sergiusens

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!