/srv/irclogs.ubuntu.com/2017/05/26/#snappy.txt

mupPR snapd#3403 opened: Sync packaging from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3403>02:16
mupBug #1693664 opened: Snapd won't install anbox, Character error <Snappy:New> <https://launchpad.net/bugs/1693664>02:38
=== chihchun_afk is now known as chihchun
Chipacamo'in peeps08:17
ChipacaI've got a meeting at the boys' school today so I'll be gone for a chunk of the morning, starting in about 15 minutes08:18
Chipacashout if you need me for something before i'm gone08:18
pedronisChipaca: hi, I'll look at your branches08:22
Chipacapedronis: appreciated as always08:22
Chipacapedronis: one of them went up in the middle of a store outage yesterday, so everything was red. I redid travis, but the others i'd have to repush if needed08:23
Chipacaok, i'm off, will bbl (nominally in 2h)08:40
fgimenezhi pedronis, we are still getting crete-key timeouts on ubuntu-16.04-32 (haven't seen it failing on other systems) https://travis-ci.org/snapcore/spread-cron/builds/236217996#L196009:04
fgimenezin the same run https://travis-ci.org/snapcore/spread-cron/builds/236217996#L1960, also -3209:04
pedronisfgimenez: not sure why, otoh it would be ok to run those test only on classic amd6409:13
fgimenezpedronis: ok, should we wait for more errors to make sure it only timeouts on i386? if not i can propose a PR for disabling them now09:16
pedronisfgimenez: let's wait a bit more09:17
fgimenezpedronis: ok thx09:17
pstolowskihmm i'm getting '- Run configure hook of "core" snap (run hook "configure": 2017/05/26 11:13:09.680326 cmd.go:93: DEBUG: core snap (at "/snap/core/current") is older ("2.26.3+git212.34125a5~ubuntu16.04.1") than distribution package ("1337.2.26.3"))' locally with one of the spread tests; is this something to be worried about or a problem with my local env?09:55
pedronispstolowski: it means what you have outside is older than what you have inside, but I cannot read that message, is it failing or just a debug message09:58
pstolowskipedronis, failing09:59
pedronispstolowski: anyway it's failign for other reasons that you don't see09:59
pedronisthat bit is just debugging09:59
pedronisafaict10:00
pstolowskisomething weird with versions - i think this starts failing at:10:01
pstolowskiSetting up snapd (1337.2.26.3) ...10:01
pstolowski+ MATCH unknown10:01
pstolowski+ snap --version10:01
pstolowskierror: pattern not found, got:10:01
pstolowskisnap    1337.2.26.310:01
pstolowskisnapd   1337.2.26.310:01
pstolowskiseries  1610:01
pstolowskiubuntu  16.0410:01
pstolowskikernel  4.4.0-78-generic10:01
pstolowski+ MATCH unknown10:01
pstolowski+ /usr/lib/snapd/snap-confine --version10:01
pstolowskierror: pattern not found, got:10:01
pstolowskisnap-confine 1337.2.26.310:01
pedronispstolowski: were is match unknown coming from10:03
pedronisI see only one very early in prepare.sh10:04
pedronisthat should kill the whole run10:04
pstolowskipedronis, the spread test i'm running is not doing that explicitely, so must be part of some general preparations10:11
pedronismaybe building is failing10:11
fgimenezpstolowski: pedronis i've seen that "MATCH unknown -> pattern not found" previously, it is expected to fail if i read correctly https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L96, probably the error is somewhere else10:13
pedronisyes, it should day saying that something is weird10:13
pedroniswith the built snapd10:13
pedroniss/day/die/10:15
* pedronis lunch10:15
pstolowskii'm trying on linode now10:17
pstolowskibut not sure if that's relevant at all10:17
pstolowskihmm same error on linode10:39
fgimenezpstolowski: do you have a complete error log?10:41
pstolowskifgimenez, http://pastebin.ubuntu.com/24665653/10:43
fgimenezpstolowski: if the problem is not related to yur branch it should be easy to reproduce, trying that now10:46
pstolowskifgimenez, this is failing on a new spread test I added in my branch. but I see no direct relation to my test yet, it's just installing a test snap as any other test, and modifies its config11:17
fgimenezpstolowski: something seems to be making the prepare step to fail, i can't reproduce locally, also fwiw the automated execution after the new core was published to edge this morning was good, i've retriggered it and has already passed successfully the prepare stage https://travis-ci.org/snapcore/spread-cron/builds/236247437 (this executes from master)11:24
* Chipaca returns from the dead11:34
Chipacasee, even when i pad these things out i fail to account for the time it takes :-(11:34
Chipacapedronis: thank you for the reviews! I'll get on them in a bit11:34
ogra_abeato, oh ... one other thing about the androidboot support, why /writable/androidboot ... i thought we agreed to have an actual /boot/androidboot/  partition available ?11:35
ogra_abeato, you could use that directgly11:36
fgimenezpstolowski: mmm i'm getting a different error locally from master http://paste.ubuntu.com/24665927/11:37
=== chihchun is now known as chihchun_afk
abeatoogra_, using the current userdata partition makes our life easier, and I do not see any advantage in using a separate partition that might not be always available12:10
abeatoogra_, we can be flexible though and contemplate both cases12:11
ogra_abeato, well, it will require changes to snapd i guess ... since it looks at /boot/<bootloader> (i think ... perhaps i'm wrong though)12:11
ogra_to decide what way of mangling it needs to use for the cdmline on updates12:12
abeatoogra_, no, no need for changes to snapd, it is transparent for it, so in fact the decision depends on system specific parts12:12
ogra_i'm really not sure this is still the case ... but in the past it looked for the mounted /boot partition to detect the right bootloader path12:12
ogra_ok, then we're fine i guess12:13
abeatoogra_, it just searches for files in /boot/xxx12:13
ogra_ok12:13
fgimenezpstolowski: looks like i had some leftover files that were making the build to fail, this is from a clean master http://paste.ubuntu.com/24666236/ all seems to be fine12:21
pstolowskifgimenez, thanks for checking12:50
niemeyerHellos12:58
niemeyerChipaca, fgimenez, pstolowski: Stand up?13:01
fgimenezniemeyer: omw13:01
Chipacaniemeyer: omw indeed13:02
mupPR snapd#3402 closed: many: error types should be called FooError, not ErrFoo <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3402>13:14
abeatoogra_, something else that I'd like to do is to add a modified klicb package in snappy PPA with https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+attachment/4881283/+files/add-reboot-argument-support.patch13:22
mupBug #1692494: klibc does not support reboot arguments <patch> <klibc (Ubuntu):New> <https://launchpad.net/bugs/1692494>13:22
abeatoogra_, even if we land in arty we still need that13:22
ogra_abeato, did you talk to upstream yet13:22
ogra_(infinity ... )13:23
abeatoogra_, nope, where does he hang around?13:23
* abeato tries ubuntu-desktop13:24
ogra_abeato, #ubunru-devel13:24
ogra_*ubuntu13:24
abeatook13:25
ogra_(he's foundations ... really not a desktop guy :) )13:25
ogra_if we could SRU it right away we'd not need the PPA ... i woudl prefer that13:26
pedronisniemeyer: snapd#3350 , not blocking my current work but would be good to have some feedback, it was planned for the next release13:35
mupPR snapd#3350: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <https://github.com/snapcore/snapd/pull/3350>13:35
niemeyerpedronis: +113:35
Son_Gokuanyone able to merge snapd#3403?13:42
mupPR snapd#3403: packaging/fedora: sync packaging from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3403>13:42
Son_Gokuthe stupid failure is just Linode being awful13:42
niemeyerSon_Goku: I've restarted the integration tests13:47
Son_Gokuniemeyer: I'd hope they pass, since it's all dead code to Travis13:48
Son_Gokuwe don't have any Fedora CI yet13:48
niemeyerSon_Goku: I always hope they pass as well13:48
niemeyerfgimenez: Small comment in #340113:53
niemeyersnapd#340113:53
mupPR snapd#3401: tests: move static and unit tests to spread task <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3401>13:53
fgimenezniemeyer: thx on it13:54
niemeyerfgimenez: Let's please fix on a follow up.. this is taking 6 minutes out of everything else13:54
mupPR snapd#3401 closed: tests: move static and unit tests to spread task <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3401>13:54
fgimenezniemeyer: sure, i'll prepare it13:55
ogra_kalikiana, you are currently working on the cross stuff iirc ... do you know if there is already a way to use arch specific tags in "build-packages:" in snapcraft.yaml ? (i.e. i want to make gadgets build uboot from source, if i build it on an amd64 system i need gcc-arm-linux-gnueabi installed, on native builds i dont)13:57
ogra_(i cant find anything in the docs about that)13:58
niemeyerfgimenez: Thank you!14:00
sergiusensogra_: that should iirc work, but for it to work automatically in launchpad there's this https://github.com/snapcore/snapcraft/pull/125314:04
mupPR snapcraft#1253: go plugin: cross-compilation support <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1253>14:04
sergiusensspecifically https://github.com/snapcore/snapcraft/pull/1253/files#diff-e405f18ae8c707ccb3d5ea4e828718c9R20214:04
* ogra_ checks (we can move to rocket, i just asked there btw)14:06
sergiusensogra_: don't multi post :-P14:07
ogra_:P14:07
sergiusensniemeyer: can I have uour thoughts on https://forum.snapcraft.io/t/version-script-helpers/648?u=sergiusens ?14:07
ogra_sergiusens, hmm, not really what i want ... that only reacts to --target-arch14:08
niemeyersergiusens: Sure, just let me finish a review and will be there14:09
sergiusensthanks, shouldn't take much of your time, but mostly to make sure I captured your suggestion correctly14:13
mupPR snapd#3403 closed: packaging/fedora: sync packaging from Fedora Dist-Git <Created by Conan-Kudo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3403>14:34
niemeyercachio_: Reviewed the spread PR.. it's looking pretty good, thanks. Just a few details and should be mergeable.14:43
cachio_niemeyer, sure14:44
niemeyersergiusens: Replied, thanks for poking14:49
Chipacapedronis: is there any case where a snap can have a local revision but also a snapid?14:50
ogra_snap download ... then you sideload ?14:51
Chipacaogra_: you get the revision from the assert14:51
ogra_ah14:51
pedronisChipaca: well, a snap can have a revision (as in SideInfo) with a snap id and some without,  a revision with both would be an incosistent state though14:52
ogra_Chipaca, well, do i get the assert if i sideload (and dont snap ack it)14:52
Chipacaogra_: if you don't have the assert, you don't get the snap id14:53
ogra_ok14:53
pedronisChipaca: just pointing out it's a per revision/SideInfo property, is not global14:53
Chipacabut i don't know what happens if you mix n match; going to try that now14:53
Chipacapedronis: right, but they're at the same level14:53
Chipacathey're both in the sequence, not in the snap14:54
pedronisyes14:54
pedroniseach one should be consistent, if you manage to have both it's a bug14:54
Chipacapedronis: basically i'm wondering about this bit of code that sets revision to 0 before checking snapid14:54
pedronisChipaca: where?14:54
Chipacapedronis: in master i think this is store.ListRefresh14:55
pedronisstore?14:55
pedronisor snapstate?14:56
Chipacapedronis: store/store.go14:56
Chipacathat's where ListRefresh lives14:56
pedroniswell, the we check SnapID a line below14:56
pedronisI think that code is a bit non-sense14:57
pedronisit's not there like that to deal with a real case14:57
Chipacapedronis: maybe i should change it to do the same thing in both cases14:57
Chipacawhile i'm here14:57
pedronisjust continue14:58
pedronisworks for me14:58
Chipacathat is, if !revision.Store() || snapID == ""14:58
pedronisyou could log in one14:58
pedronisof the two14:58
pedronisanyway14:58
Chipaca“found a snap with rev<0 and snapID != ""! get out the champagne!”14:58
Chipaca:-p14:58
Chipacapedronis: thank you14:59
pedronisChipaca: fwiw I think it's from before we fully understood things14:59
Chipacayeah... before...14:59
Chipacabecause now we totally understand things, yes?14:59
pedronisChipaca: we have a way to install a local unasserted revison on top of a store one, I don't think we have a way to do the reverse though15:00
pedronissnap refresh foo will hit that code15:00
pedronisChipaca: I didn't tell you what "things" are15:01
pedronis:)15:01
Chipacapedronis: right, but it doesn't matter if a previous revision had a revision and a snapid; it's only current that matters15:01
pedronisexactly15:01
pedronisthat's why we don't have a way to do that15:02
pedronisyou need to snap remove --revision yourself out of that corner15:02
pedronisI think right now15:02
pedronisassuming revision there works with local ones15:02
pedronis(I don't know if we test for that)15:02
Chipacapedronis: would panicing be appropriate in those cases?15:08
pedronisno15:08
pedronispanicing is if the non-sense is so big that we cannot really go forward15:08
pedronishere we can ignore it15:08
pedronisnot great15:08
pedronisbut also no dead snapd trying to refresh either15:09
pedronisChipaca: there's no panic in store atm, except in init()15:12
pedronisChipaca: I think most our panics are either lock related, some early initialisation or early order of ops, or related to marshaling/unmarshaling from state15:14
pedronisor wrong types being passed around15:16
pedronis(the latter is something our tests should catch)15:16
Chipacahah! just realised15:30
Chipacathis test class is still called "UbuntuStoreRepository" :-D15:31
pedronisChipaca: yes, the tests are still using old names sometimes, I would do a separate PR to fix that though15:33
Chipacaaww15:34
Chipacaalright15:34
pedronisChipaca: search and replace together with real change don't mix well15:34
Chipacapedronis: you are absolutely correct15:35
=== chihchun_afk is now known as chihchun
pedronisreworking the retry code I noticed that indeed we don't retry DNS errors16:19
=== chihchun is now known as chihchun_afk
niemeyercachio_: Another pass on the spread PR, and then it GLTM16:55
niemeyerLGTM even16:55
niemeyerpedronis: Nice, glad that one is simple to fix.. I was afraid it might be something more involved16:55
kyrofaGood-lookin?16:55
niemeyerkyrofa: GLTM! ;)16:58
pedronisniemeyer: well, it might be complicated, for now I find the point where to log them, we might need to look at some examples from spread test run to decide what to do17:49
pedroniss/I find/I found/17:49
kyrofaAnyone here know anything about squashfuse?17:50
niemeyerpedronis: That sounds very close to what cachio_ is working on already.. one of the errors there was precisely a DNS error17:50
kyrofaMaybe I should go to the lxc channel17:51
pedronisniemeyer: I mean examples once we have the log with the exact internal error17:53
pedronisniemeyer: there's a bit of a russian dolls of errors going on (like for connreset)17:53
niemeyerpedronis: Yeah, DNS should be easy to reproduce locally17:54
niemeyercachio_: ^17:54
niemeyercachio_: Spread PR is in17:54
niemeyer(second point unrelated to first point, sorry for confusing points :))17:55
niemeyerI'm taking a break18:26
Chipacai'm taking a beer18:29
Chipaca¯\_(ツ)_/¯🍺18:29
niemeyerChipaca: Sounds like a much better idea18:30
Chipacaniemeyer: it's 1930 here so it's allowed18:30
niemeyerChipaca: I should try.. the reviews might become much more colorful18:32
niemeyerAnyway, biab18:33
Chipacaniemeyer: no reviews after beer18:33
Chipacaor during, for that matter18:33
=== Sir_Gallantmon is now known as Son_Goku
cachio_niemeyer, how do you usually connect to linode to see tho nodes that are running and their info?19:57
cachio_niemeyer, do you use user/pass in the web page?19:57
niemeyercachio_: Yes, to maintain the provide maintenance when necessary I use the administration panel.. when using spread, I don't do that though19:58
cachio_niemeyer, because I need a way to monitor nodes, I am trying to reproduce the reboot timeout issue19:58
cachio_niemeyer, do you have credentials to share with me?19:59
niemeyercachio_: You can just try to connect to them/ping as usual.. is this not working?19:59
niemeyercachio_: I don't at this time19:59
niemeyercachio_: What happens when you connect to the machine?20:00
cachio_niemeyer, I couldn't repproduce the issue yet20:00
cachio_niemeyer, I created a specific test for that and I am gonna run it now20:00
niemeyercachio_: Okay, so to get started I suggest opening a  terminal to the machine20:01
niemeyercachio_: The web interface won't be doing much better than that20:01
cachio_niemeyer,20:01
cachio_ok20:01
niemeyercachio_: Then monitor if the machine is rebooting at all, or if it's stuck20:01
niemeyercachio_: If it gets stuck at a point where there's no network, then please ping me and I'll try to see via the console20:02
cachio_ok20:02
cachio_niemeyer, apart of this one, I want to raise an issue for the econnreset test20:03
cachio_niemeyer, should I create a forum topic? or go to launchpad?20:03
niemeyercachio_: Depends a bit on the content/context.. you already have two topics on the forum for "chasing unreliable tests" and "dealing with flaky tests".. perhaps one of these is a good starting point?20:06
cachio_niemeyer, ok20:07
cyphermoxniemeyer: is there a way I can bring up a bug (fixed by SRU in ubuntu classic) to attention for ubuntu-core? it would require an update of the core snap20:59
cyphermoxhttps://bugs.launchpad.net/netplan/+bug/167274020:59
mupBug #1672740: Netplan replug function is incompatible with ath9k_htc module <verification-needed> <netplan:Fix Released by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1672740>20:59
niemeyercyphermox: Device category in the forum might be a good place21:04
cyphermoxthere's already a bug in launchpad, isn't there a real bug tracker?21:04
niemeyercyphermox: Sorry, I'm not sure of what you're actually looking for.. Launchpad is a real bug tracker.. the forum is a good place to talk. What are you looking for?21:15
cyphermoxreporting the bug to you.21:15
cyphermoxthere is a bug in launchpad already, that affects ubuntu classic; it also needs an update of the core snap21:15
kyrofaalso-effects snappy?21:16
cyphermoxit's the snappy project? I wasn't sure as there's also "ubuntu-core".21:18
kyrofacyphermox, haha, I'm not familiar with that one. I typically use snapd for snapd-specific things (interfaces, etc.), and snappy for larger system things (e.g. core snap, image issues)21:20
kyrofa(but just because that's what I do doesn't mean it's the right thing, either)21:20
kyrofacyphermox, note that the core snap is also used on classic, so another vote for snappy over ubuntu-core21:21
dakerhello, does anyone know if there is an nginx snap available ?21:27
kyrofadaker, not standalone that I know of, no. Typically it's bundled21:28
dakerkyrofa: do you have a .snapcraft of it ?21:28
kyrofadaker, all I've got myself is apache21:28
dakerkyrofa: hmm, ok thanks21:29
zygao/21:57
zygaany news on the error spike?21:57

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