/srv/irclogs.ubuntu.com/2019/05/29/#snappy.txt

mupPR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>01:54
mupPR # closed: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2514, snapcraft#2518, snapcraft#2527,01:54
mupsnapcraft#2539, snapcraft#2544, snapcraft#2560, snapcraft#2564, snapcraft#2569, snapcraft#2570, snapcraft#2571, snapcraft#2574, snapcraft#2575, snapcraft#257601:54
mupPR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>01:54
mupIssue # closed: core18#56, core18#86, core18#89, core18#117, core18#12902:04
mupPR # closed: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#12702:04
mupIssue # opened: core18#56, core18#86, core18#89, core18#117, core18#12902:05
mupPR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#12702:05
mupPR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#3802:08
mupPR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>02:08
mupPR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>02:08
mupPR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,02:09
mupsnapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905,02:09
mupsnapd#6909, snapd#6913, snapd#6919, snapd#6922, snapd#6923, snapd#692402:09
mupPR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#3802:09
mupIssue # opened: core18#56, core18#86, core18#89, core18#117, core18#12902:09
mupPR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#12702:09
=== iMadper is now known as iMadper|AAFFFKKK
=== iMadper|AAFFFKKK is now known as WhatsGoingOn
mborzeckimorning06:07
mborzeckizyga: when you're around, can you take a look at #6924?06:24
mupPR #6924: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6924>06:24
zygaHey06:30
zygaSure06:30
mborzeckizyga: thanks06:33
mborzeckizyga: spent a while rebuilding go toolchain and sprinkling soem debug messages around the linker06:33
mborzeckizyga: actually, quite an interesting exercise06:33
zygaI'm sure :)06:39
zygaI'm thinking about taking today off06:39
zygaI'm not feeling very well06:39
zygamy back is not happy today06:39
mborzeckizyga: day off is always a good idea06:44
mborzeckiok, got some comments to address in my PRs06:47
mupPR snapd#6924 closed: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6924>06:48
mborzeckimvo: hi, and thanks!06:48
mvomborzecki: hey, good morning and thank *you* :)06:56
mvomborzecki: nice fix and it unblocks another pr iirc?06:56
mborzeckimvo: yes, the one from jdstrand06:56
mborzeckimvo: about user.LookupGroup()06:56
mvomborzecki: ha! two even, how nice is that :)06:56
mborzeckimvo: other distros build with PIE enabled and that's enough to trigger the use of external linker06:57
zygahey mvo06:58
zygaI'm not feeling good, my back is acting up06:58
zygaI was thinking about taking that swap day  today if you don't mind06:58
mvozyga: sure07:02
mvozyga: get well!07:02
zygaI'll exercise a bit more today, that usually helps07:02
=== pstolowski|afk is now known as pstolowski
pstolowskiheyas07:05
mborzeckipstolowski: hey07:06
mupPR snapd#6909 closed: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6909>07:27
mborzeckizyga: so, are you off today? :)07:28
mborzeckipstolowski: fwiw, i keep gofmt from 1.10 around for 'changes' like you had07:30
pstolowskimborzecki: good idea, thanks07:31
zygamborzecki: yeah, though I may send a patch for ! bug now that no blockers remain07:36
mupPR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,07:45
mupsnapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871,07:45
mupsnapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#692307:45
mupPR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,07:46
mupsnapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871,07:46
mupsnapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#692307:46
mborzeckihttps://paste.ubuntu.com/p/YhDjqdmxnK/ 'Catalog update is doing verbose http logging (it should not).' huh?07:50
mborzeckia race of some sort?07:51
pstolowskipedronis: hey, can you merge master in #6841?07:58
mupPR #6841: overlord: make changes conflict with remodel <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6841>07:58
pedronispstolowski: it's now based on 6855, that needs to go in first07:59
pstolowskiok, looking at it now08:02
mborzeckipedronis: mvo: do you think we need an experimental flag for gadget update for a while?08:18
mvomborzecki: I don't think so, its up to the vendor to use it and they should know what they do (but pedronis may be of a different opinion)08:22
pedronismborzecki: is opt in anyway also in most cases there is no user to make that decision per machine08:22
mborzeckipedronis: mvo: sounds fair08:23
pedronismborzecki: if you are worried though about bugs in the opt in logic, we can have a flag for a bit08:24
ChipacaThere was an unexpected problem serving your request // Please try again and contact us if the problem persists including EAC6:168A1:B024F2C:10BFCA12:5CEE42BE in your message08:29
Chipaca^^ github OOPSing08:29
Chipacafun fun08:29
Chipacamvo: I was trying to add a comment to #6804: in all new code we really should be calling Context() on the *http.Request instead of adding context.TODO()s08:30
mupPR #6804: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6804>08:30
mvoChipaca: oh, thanks, let me fix this08:31
pedronisyes, github is not having good days08:32
mupPR snapd#6925 opened: devicestate: disallow removal of snaps used in booting early <Created by mvo5> <https://github.com/snapcore/snapd/pull/6925>08:32
mvoChipaca: should I still keep the todo as is or adjust?08:34
Chipacamvo: where?08:34
Chipacamvo: I meant: in searchStore, instead of ctx := store.WithClientUserAgent(context.TODO(), r.Header.Get("User-Agent")), do ctx := store.WithClientUserAgent(r.Context(), r.Header.Get("User-Agent"))08:36
mvoChipaca: yeah08:37
Chipacaah ok08:37
mvoChipaca: I did that :) mostly wondering about the "//TODO" above08:37
mvoChipaca: if that is still accurate (enough)?08:37
Chipacamvo: heh :)08:37
Chipacamvo: no, it's no longer accurate (if it ever was :) )08:38
mvoChipaca: glad that I asked :)08:38
mvoChipaca: suggestions? or shall I simply remove it08:38
Chipacamvo: what's 'the common layer that calls the handlers'?08:38
Chipacamaybe i'm misunderstanding something08:38
pedronismvo: Chipaca: notice that my proposal was ctx := store.WithClientUserAgent(r.Context(), r)08:39
Chipacapedronis: where?08:39
pedronisChipaca: my signature is not what mvo implemented08:39
Chipacaah08:40
pedronisChipaca: mvo: it seems my missed that Request now has Context08:40
Chipacapedronis: mvo's is probably a lot easier to test :)08:40
mvopedronis: oh, did I misread, let me double check08:40
pedronisChipaca: marginally08:40
pedronisChipaca: notice that I'm not proposing to make that thing take only Request08:41
mvopedronis: indeed, silly me!08:41
* mvo needs more tea08:42
pedronisChipaca: mvo: as I was saying, I missed that Request now has Context, so the my other todo is not relevant anymore for now, until there is something we would like to stick everywhere, though UA might be almost that08:42
mvopedronis: cool, I will update the PR and also use your suggested signature08:43
pedronisChipaca: my todo was about doing something in Command.ServeHTTP08:44
pedroniswe might want to do that anyway08:47
Chipacapedronis: ah08:54
Chipacapedronis: I didn't know they were your TODOs :)08:56
mvopedronis: you mean something like http://paste.ubuntu.com/p/sDv8YcrNBc/ ?08:56
pedronismvo: yes, something like that08:56
zygamborzecki: https://github.com/snapcore/snapd/pull/692608:56
mupPR #6926: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>08:56
mupPR snapd#6926 opened: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>08:57
pedronismvo: then the rest of the work would teach store to take more contexts, and use r.Context more08:57
mvopedronis: do you think its worth doing the above pastebin with the rest of the work? or do you think we should hold it? either way is fine for me08:57
pedronismvo: I don't think it's a blocker for this PR08:57
pedronisI still think is not the best use of your time to work on this :)08:58
mvopedronis: yeah, I know :(08:58
mvopedronis: I stop and get to the other things08:58
pedronismvo: need to look quickly but this one can problably land and Chipaca can pick up ther others/from there09:02
mvopedronis: yeah, that would be cool09:02
mupPR snapd#6759 closed: osutil: now that we require golang-1.10, use user.LookupGroup() <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6759>09:29
mborzeckiyay09:32
pedronispstolowski: Chipaca: mvo: thank for the reviews to my remodel PR, I'll try to clean it and land it today, worst case it will happen on Monday09:32
mvopedronis: yeah, its super close, its really nice to see how things fit together. given how complicated this topic is it was a joy to read09:38
Chipacapedronis: today is eow for you?09:46
pedronisChipaca: yes09:47
Chipacapedronis: nice09:47
mupPR snapd#6804 closed: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6804>09:56
pedronisChipaca: so if you need something in particular to be unblocked let me know10:02
Chipacapedronis: you self-requested a review on #6848 so if you had the time to do that it'd be nice10:10
mupPR #6848: introduce healthstate, run check-health post-(install/refresh/try/revert) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6848>10:10
Chipacathat'd unblock its followup10:10
pedronisChipaca: it's on my list of trying to get to it today10:11
pedronisChipaca: worst case  there's the context/snap-client-user-agent stuff to pick up10:14
pedronisChipaca: mvo has a couple more PRs open about that, I think there is still a bit more todo10:14
Chipacapedronis: and cohort-in-info10:14
pedronisChipaca: yes, that too10:14
Chipacapedronis: and context-in-all-the-things10:14
Chipaca:)10:15
Chipacapedronis: i'm not going to be bereft of things to do10:15
pedronisfor the latter, it would be best if my PR landed10:15
pedronisgiven it has tests/signature changes in snapstate10:16
pedronispstolowski: do you have PR  about --startup for timings ?10:16
Chipacanoted10:16
pedronis*a PR10:16
mupPR snapcraft#2577 opened: [cli] Add --destructive-mode to clean <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2577>10:17
pstolowskipedronis: oh yes i have, forgot to propose it. probably needs some small deconflicting now, will do10:18
pstolowskithanks for reminding10:18
pedronispstolowski: np10:18
pedronispstolowski: btw before 2.40 it would be good to have a forum topic with some explanation of snap debug timings and maybe example output from a pi or something10:21
pstolowskipedronis: yes, i need to repeat my test, have some old samples10:22
pedronisthank you10:22
zygamvo: https://github.com/snapcore/snapd/pull/692610:47
mupPR #6926: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>10:47
zygaand that's my contribution of the day10:47
zygaI'm really swapping now10:47
mupPR snapd#6927 opened: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>10:48
mvozyga: thank you!10:51
* pstolowski lunch11:03
mborzeckitests that look at journalctl seem to fail erratically on opensuse 1511:03
mwhudsonmvo: hey i should tell you about the things i had to do to make your "build empty package on powerpc" hack actually work :)11:10
mwhudsonmvo: (mostly this https://github.com/tianon/debian-runc/commit/22d7b5c648bcac9969d6d02067b0eddcc52af4af )11:10
mvomwhudson: oh, interessting11:11
mvomwhudson: you are using it (or something similar) in some other package ?11:12
mwhudsonmvo: yeah, runc11:12
mwhudsonmvo: i think you also need to fix the build deps11:13
mvomwhudson: yeah, just noticed the ftbfs in the ppa, slightly sad about this11:15
mvomwhudson: I have a look, should I apply your patches basicly?11:15
mwhudsonmvo: well the things i remember are: check for build-arch as well; fix build deps11:16
mwhudsonmvo: the other stuff i did was add a preinst that yelled at the user but well11:16
mwhudsonmvo: the whole change to build the empty package is https://github.com/tianon/debian-runc/compare/70957b315f82170dc2ab7085d39c23835c0fa996...xenial11:18
mvomwhudson: nice, thank you! I check it out and update the snapd packaging11:18
mwhudsonmvo: thanks for the basic idea :)11:19
mvomwhudson: my pleasure! hm, `golang-1.10-go [!powerpc]` does not work?11:19
mwhudsonmvo: i think it does actually, i forgot you can do that :)11:19
mvomwhudson: cool, thanks! I will give it a go11:20
mupPR snapd#6928 opened: packaging: fix build-depends on powerpc <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6928>11:29
cachiomvo, hi11:34
mvohey cachio11:34
mvocachio: finally, we have 2.39.1 in beta :)11:34
cachiomvo, yes, finally11:34
cachiomvo, :)11:34
cachioabout that, changes not generated on https://people.canonical.com/~mvo/core-changes/html/beta/11:35
mvocachio: aha, yeah, I think its just slow, let me give it a gentle kick11:35
cachiomvo, ah, ok, tx11:35
popey_Chipaca: want a fun bug? :)11:40
popey_Chipaca: run (exactly as written) snap install go --classic --channel=12/stable11:40
popey_(a typo, so it presents a list of channels that do actually exist)11:40
popey_the list is sorted incorrectly, with 1.10 and 1.11 coming before 1.1211:41
popey_Chipaca: https://paste.ubuntu.com/p/t3Z9kbpMny/11:42
=== ricab is now known as ricab|lunch
mupPR snapd#6929 opened: gadget: record gadget root directory used during positioning <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6929>11:51
mborzeckioff to pick up the car and heading home11:52
mborzeckiback for standup11:52
zygamvo, pedronis: what can cause settle not to converge?12:00
pedroniszyga: where? it depends, malformed changes, too little timeout and missing EnsureBefore, tasks that retry12:03
zygaso, there's a test that reliably fails when I build a suse package12:04
zygaI added some debugging to show tasks and changes,12:05
zygaall changes and tasks are done:12:05
zygathe test is managers_test.go:3511: mgrsSuite.TestHappyDeviceRegistrationWithPrepareDeviceHook12:05
zygaI added this patch as otherwise debugging is pretty hard12:06
zygaDEBUG patch https://www.irccloud.com/pastebin/hGnLDEOP/12:06
zygawhen the test fails the output is:12:06
zygafailing test output https://www.irccloud.com/pastebin/PHXiVyeZ/12:06
pedronisare they clean though?12:09
pedronissettle wait for clean too12:09
pedronisnot that I remember it should matter here12:09
zygagood hint, checking12:09
pedronisalso print if you hit the done clause at all12:10
pedronisor not12:10
zygapedronis: curious12:14
zyganone of the tasks or changes are clean12:14
zygaso we must be running the cleanups, correct?12:15
zygalooking at the debug log that contains errors from failed cleanup tasks...12:18
zygadoh12:21
zygait's all a big fluke12:21
zygaGOPATH messed up12:21
jdstrandzyga: fyi, I'm not sure about jj's plans, but I got tasked on something with priority today (a USN publication) and will not be looking at the apparmor issue (or other PRs) until that is done (targetting eod today)12:41
zygajdstrand: that's okay12:43
zygajdstrand: note, thre's no apparmor issue12:43
zygajdstrand: it was a bug in our test setup12:43
jdstrandzyga: oh, does jjohansen know that?12:43
zygaI said so yesterday but based on what you just said I must have been vague12:43
zygajjohansen: ^ please don't look at the apparmor bug jdstrand mentioned, it's not a bug, test setup was wrong12:43
zygasorry for not communicating that clearly before12:44
jdstrandzyga: maybe I was slow on the uptake but jjohansen wasn't. jjohansen, no apparmor issue ^12:44
jdstrandpinged him just in case12:44
mupPR snapd#6930 opened: tests: make more robust how we check the journal log is ready to start a test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6930>12:53
zygahmmmmm12:58
zygasomething totally bogus is going on12:58
zygaTestHappyDeviceRegistrationWithPrepareDeviceHook is not present in 2.39.112:59
zygayet that test fails12:59
zygasomething along the way is getting snapd master?12:59
zygamvo: uh13:00
zygamvo: 2.39.1 tarballs are wrong?13:00
zygamvo: it's master, not a .1 branch13:00
zygamvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in master13:00
zygamvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in the 2.39.1 branch13:00
zygamvo: and grep for it in the tarball!13:00
zygawe need a .213:00
mvozyga: I took the tarballs down and will investigate13:03
mvozyga: I have had a bit of a heart attack but it seems https://github.com/snapcore/snapd/blob/release/2.39/overlord/managers_test.go#L3511 shows that we have this TestHappyDeviceRegistrationWithPrepareDeviceHook - or are you saying things changed there?13:10
zygaoh my god, I'm sorry, I was on 2.*29* not 3913:11
zygaso the bugs I saw are real but the tarbralls are okay13:11
zygasorry for the red flag13:11
mvozyga: thanks13:12
=== ricab|lunch is now known as ricab
zygapedronis: I debugged the issue now13:23
zygaosc build sets a proxy and we choke on that13:23
zygabetter debug log https://www.irccloud.com/pastebin/Pws7SmMF/13:23
albertosottilepedronis: I read your answer about the Syncplay classic confinement13:24
albertosottileFrom a technical point of view, we would need access to the binary and to a TCP port on localhost from both VLC and Syncplay13:24
albertosottileYour solution would rule out mpv and all users that do not use snap VLC, though13:25
zygapedronis: this is with this patch https://github.com/zyga/snapd/commit/b6e38391e35d1634375a0675e6050e8192aa2cf613:30
zygamvo: whatever causes this I will adjust the unit tests to run in an offline network namespace13:38
zygamvo: so we will not hit this by surprise the next time13:38
mvozyga: thank you!13:39
mvo6926 is green and needs a second review13:53
pedronisalbertosottile: hi, I understand, but I'm very reluctant to give classic to this, so we are looking at options, there is also a mpv snap I think, but is didn't reach stable yet13:55
albertosottilepedronis: we understand your concerns, and we also would like to address them13:58
albertosottilehowever, we invested a lot of time in preparing a snap for Syncplay and we do not see a way to avoid the use of classic confinement in a short time and/or without noticeable drawbacks...13:59
pedronisabeato: I understand, but even if we granted classic temporarily (which is not very common), it's definitely the case that a story how to get out of that as soon as possible is valuable. We are really relucant to give classic to anything that serves outside requests, that guideline hasn't really changed/varied14:08
pedronissorry, albertosottile ^14:08
pedronismvo: did you do something strange with 6899, I got a strange email about it, listing tons of commits14:09
mvopedronis: no idea why you got an email but I did update "20" to master and updated this PR to master as well14:10
mvopedronis: should be all normal in this PR again though14:10
pedronisI see, seems github already the merge14:11
pedronisfor this case14:11
pedronisat least in terms of email14:11
pedroniss/already/unrolled/14:11
albertosottilepedronis: to be honest, I did not find this guideline written somewhere in the documentation. The description of the classic confinement basically says that the app would be allowed to run as close as possible as unrestricted14:11
mvopedronis: so no harm except this stange email?14:11
albertosottileI understand your concerns, but Syncplay is a seven years old software with a good user base on Linux14:12
mupIssue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#1514:14
mupPR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#3014:14
mupIssue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#1514:17
mupPR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#3014:17
Chipacapedronis: would it be reasonable to expose snapstate.switchSummary (given it's dupe'd in daemon right now), and if so would that be a reasonable name for it?14:19
mupPR snapcraft#2576 closed: [legacy] catkin plugin: remove default rosdistro <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2576>14:21
mupPR snapd#6931 opened: tests: force removal to prevent restore fails when directory doesn't exist on lp-1801955 test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6931>14:33
pedronisChipaca: we could but it's a bit unclear where it should live14:44
Chipacapedronis: or I could grab it from the task :-)14:49
mborzeckimvo: https://github.com/snapcore/snapd/pull/6927 failed building the package on sid14:51
mupPR #6927: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>14:51
mupPR snapd#6932 opened: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>15:04
mupPR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>15:11
mupPR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>15:11
mupPR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>15:11
mupPR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>15:12
mupPR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>15:12
mupPR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>15:12
pedronisChipaca: did a pass on 684815:13
Chipacapedronis: thanks15:15
zygamvo: draft https://github.com/snapcore/snapd/pull/693215:16
mupPR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>15:16
zygait fails, I'll see what to do about the failures15:16
mvozyga: woah15:18
mvozyga: nice15:18
mvocmatsuoka: re uc20> I pushed a hack that should avoid the stray reboot, with that you should be unblocked for the tmpfs work15:19
mvocmatsuoka: its a pr against your core-build git repo15:19
cmatsuokamvo: ack, thanks!15:29
* cachio lunc15:32
* cachio lunch15:32
pedronispstolowski: looked at #692315:50
mupPR #6923: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6923>15:50
zygapedronis: FYI, I opened a draft PR that reproduces two unit test failures when network is isolated15:51
pedroniszyga: thanks, at this point I will look on monday morning15:51
zygathanks, hopefully by then it will be all fixed :)15:52
pstolowskipedronis: thanks!15:52
pedroniszyga: maybe, anyway please don't hack the tests to much to fix them. At least the one you shown before should have a couple line fix15:54
pedronisjust a matter of finding the right couple lines15:54
zygayeah, I'm sure that's true15:54
pedronisactually not, the code is eager there15:57
pedronismmh16:07
mvocmatsuoka: mostly fyi - I started with launchpad.net/snap-core2016:07
pedroniszyga: I commented in the PR about the 2nd16:10
zygathanks!16:10
=== pstolowski is now known as pstolowski|afk
Et0hPedronis/jdstrand: Hi, I've been a core Syncplay developer since 2013. We do our best to be responsive to user feedback, and so we've been trying to add Snapcraft support in line with the requests that we have received. It'd be great if you could help make this happen so that our shared userbase who want to use Syncplay via Snapcraft can do so and I am grateful for you exploring this with my16:27
Et0hcolleague albertosottile. As far as I can see the only way to accommodate this functionality would be for Syncplay to be granted Classic status or something equivalent. Anything you can do to progress this matter would be appreciated.16:27
jjohansenjdstrand, zyga: thanks, I was down the rabbit ole on the other bug I was trying to finish first yesterday, so I didn't spend much time on this yet.16:43
mupPR snapd#6933 opened: [RFC] snapd: ensure GOMAXPROCS is at least 2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6933>16:57
=== ricab is now known as ricab|bbl
cachiomvo, hey https://paste.ubuntu.com/p/t7ZwjJzW6F/17:10
cachioat some point running beta validation for i386 it starts showing errors saying17:10
cachioCannot allocate memory17:11
mvocachio: woah, interessting17:13
mvocachio: reproducible?17:13
cachioyes17:13
cachiomvo, I ran twice the suite17:14
cachioboth times failed with same error17:14
mvocachio: woah, ok - who much mem does this vm have?17:14
cachiobut on different tests17:14
cachio2GB17:14
cachiosame as usuar17:14
cachiousual17:14
mvocachio: should be plenty17:14
cachioKiB Mem :  2012832 total,  1218820 free,   272520 used,   521492 buff/cache17:14
cachiothis is the mem after the test17:15
cachioon debug session17:15
mvocachio: can you run something like "snap version" or does that also fail? in the debug shell?17:16
cachioI'll add some debug info to see the memory when it fails17:16
cachioit works well now17:16
cachiothe memory is not full anymore17:17
mvocachio: thanks. please keep poking, the diff looks innocent bug of course something external might have changed. if its persists, please mail maciej with instructions how to reproduce and ask him to look at this in his morning (cc me just in case)17:17
cachiomvo, sure, thanks17:18
mvocachio: the diff between 2.39 and 2.39.1 looks super harmless so we need to check if something else (like go or gcc or whatnot) have changed17:18
mvocachio: thanks, I have dinner now but will read backlog, keep me posted! and thanks for digging into this17:18
cachiomvo, np, please enjoy dinner17:18
mvothanks!17:19
cachiomvo, https://paste.ubuntu.com/p/m2KsWxNpJ5/17:22
cachioI can reproduce it even havng more than 1GB of memory free17:22
cachio:(17:22
jdstrandjjohansen: phew, glad to hear. I hadn't yet either (and I was planning to do a deep dive)17:48
jjohansenjdstrand: then again maybe not, that rabbit hole involves no-expr-simplify17:48
jjohansen:)17:48
mupPR snapd#6926 closed: tests: stop using ! for naive negation in shell scripts <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6926>17:53
cachiozyga, hey, about the PR #693017:53
mupPR #6930: tests: make more robust how we check the journal log is ready to start a test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6930>17:53
cachiodid you read my comment?17:53
jdstrandjjohansen: uh oh :)18:00
=== ricab|bbl is now known as ricab
mvocachio: what version of the kernel do you have?18:41
mvocachio: what kernel snap revision?18:41
cachiomvo, hold on, I need to create the image18:42
mvocachio: is it always the apparmor profile where it fails? maybe the kernel changed, last kernel change is ~2 weeks18:42
mvocachio: old - in stable - this would match18:42
cachioallways in apparmor profile18:43
mvocachio: the packaging changes also look harmless18:43
cachionow I am running stable + beta core18:43
mvocachio: if you have the kernel revno of the 2.39 validation that might give us clues18:45
mvocachio: might also be interessting to test with the beta kernel just for the kicks18:45
mvocachio: also the output of cat /proc/meminfo is interessting18:46
cachiomvo, https://paste.ubuntu.com/p/drGFsBDV2K/18:46
cachio0B kernel?18:46
pedronismvo: cachio: also reminder that now ubuntu-image stable has --snap support18:46
pedronisfor that kind of tweaking18:46
cachiopedronis, yes, I am using that18:47
mvocachio: I suspect its not really "out-of-memory", I suspect its "out of a certain kind of memory", in the past we had something like "lowmem" in meminfo that we low, everything else was fine18:47
mvocachio: would be great to know if the error is kernel dependent18:48
cachiomvo, ok, I'll continue working with this18:48
mvota18:48
cachiomvo, sure18:48
cachioI'll test that18:48
mvota18:51
* cachio afk19:00
=== harrisj_ is now known as harrisj

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