/srv/irclogs.ubuntu.com/2017/06/23/#snappy.txt

mupPR snapcraft#1367 closed: catkin plugin: add support for ROS Lunar <Created by kyrofa> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1367>01:04
mupPR snapcraft#1332 closed: cli: provide a whoami command <Created by sergiusens> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1332>02:34
mupPR snapcraft#1363 closed: tests: use pyramid as a router for the fake servers <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1363>04:55
mupPR snapd#3517 opened: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <https://github.com/snapcore/snapd/pull/3517>05:40
fgimenezgood morning mvo, i'm already running the core-revert stable -> edge -> stable test but it seems to get stuck after the first refresh, this will be addressed by snapd#3517, is that correct?07:36
mupPR snapd#3517: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <https://github.com/snapcore/snapd/pull/3517>07:36
fgimenezmvo: the error i get is "Jun 23 07:15:00 localhost snap[1685]: cannot open cookie file /var/lib/snapd/cookie/snap.network-managercannot stat /var/lib/snapd/seccomp/bpf/snap.network-manager.networkmanager.bin: No such file or directory"07:45
fgimenezmvo: fwiw we got a new edge core built from the edge ppa this morning, maybe there are bits in there that shouldn't be part of 2.26.last08:10
=== chihchun_afk is now known as chihchun
mvofgimenez: thank you, I was able to reproduce, the cookie error is a red herring, the real issue is that we have a race, I think #3517 will fix it08:52
fgimenezmvo: great thank you, let me know if i can be of any help08:58
mvofgimenez: no worries, I just need reviews09:00
* zyga waves from Poland09:13
mvozyga: welcome home!09:16
zygamvo: hey, thank you :)09:16
zygahow are things?09:17
zygaI'm pretty sleepy but eager to wake up, the plane was delayed by two hours and departed after midnight...09:17
zygabut it's all behind us now, the day awaits09:17
mupPR snapd#3516 closed: asserts: implement FindManyTrusted as well <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3516>09:17
mvozyga: things are good09:17
mvozyga: if you want to review stuff, 3517 might be an interessting one09:18
zygayes, I think that's a good use of my time today09:18
mvozyga: 3512 as well09:18
mvozyga: I think I will merge the shellcheck ones with a single reivew only, those are pretty mechanical and tests ar efine09:18
mvozyga: 3514 is an easy win09:19
zygamvo: am I reading 3512 right that it will re-exec tools on distros that don't reexec?09:20
zygamvo: I think this is very undesirable and will break if used today09:20
mupPR snapd#3511 closed: tests: shellcheck improvements for unit tasks <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3511>09:20
mvozyga: unless I made a mistake it should not do this. it will look at the running snapd, if that is re-execed it will use the reexecd path09:21
zygamvo: ah, ok, let me read that in detail09:21
zygamvo: but that should be good09:21
mupPR snapd#3514 closed: wrappers: add SyslogIdentifier to the service unit files <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3514>09:21
pstolowskizyga, hey! :)09:21
mvozyga: the code could actually be even simpler, it could just always use $dirname("/proc/self/exe")+tool-name09:22
pstolowskifgimenez, ping09:22
mvozyga: but I think that would break some tests so the way its written now should be ok09:22
zygapstolowski: hey :)09:22
zygamvo: mmmm, indeed09:22
fgimenezhey pstolowski and zyga :)09:22
zygahey fgimenez :)09:22
zygamvo: nice way to solve the current symlink issue btw09:23
pstolowskifgimenez, hey, advice needed09:23
fgimenezzyga: how was your trip?09:23
mupPR snapd#3509 closed: tests: shellcheck improvements for tests/nested tasks <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3509>09:23
mvozyga: thank you!09:24
fgimenezpstolowski: sure, how can i help?09:24
pstolowskifgimenez, i'd like to create a spread test for revert-hook that I implemented; looking at our revert spread test, we use test-snapd-tools from the store and then switch to the fake store to simulate refresh, so that we can revert. but for my test I need a new custom snap with revert hook inside09:25
pstolowskifgimenez, so question is, how to do that with minimum hassle09:26
zygafgimenez: exhausting, the trafic on costa brava was very heavy in anticipation of the holidays09:27
zygafgimenez: the plane was delayed because of thunderstorms in France09:27
zygafgimenez: plus lots of stress with packing everything on the very last moment09:27
zygafgimenez: but it's all over now so that's all behind me :)09:28
=== chihchun is now known as chihchun_afk
fgimenezpstolowski: we have been creating the test snaps required by specific tests and, when needed, uploading them to the store under the shared account, i think in this case that should be the right thing to do09:29
pstolowskifgimenez, sounds good. I think it would be fine to add this new hook to test-snapd-tools; this hook will be a simple one liner that e.g. drops a file somewhere so I can verify it was run. what do you think?09:31
fgimenezzyga: that's the spirit! :) happy to hear that all went well after all, also tonight is "noche de san juan", good moment to burn the old and embrace new things :)09:31
pstolowskifgimenez, btw, i'm going to Spain for my vacation in ~3 weeks, reportedly close to where zyga lived ;)09:32
* zyga stops reviews for a moment and goes to make coffee09:34
fgimenezpstolowski: it's a very beautiful place, you'll enjoy for sure :)09:34
pstolowskifgimenez, :)09:35
fgimenezpstolowski: about test-snapd-tools i'd personally prefer to have an specific snap for this test, something like test-snapd-with-configure, test-snapd-with-revert in this case, so that the purpose of each one is clear09:37
niemeyerHeya09:37
pstolowskifgimenez, ok, fine by me09:38
pstolowskiniemeyer, hey!09:38
pstolowskifgimenez, do we use our tests/lib/snaps/ as a source for building these snaps for the real store?09:38
niemeyerzyga: Happy to hear the move went fine, despite the unavoidable stress it entails :)09:39
zyganiemeyer: hey!09:41
zyganiemeyer: yes, it's all good now09:41
zyganiemeyer: kids are running around the place re-discoveing early childhood items09:41
mvozyga: 3464 probably needs a merge of master to make spread work09:44
oSoMoNwhat happens when a snap previously published in the store with strict confinement gets an update that declares classic confinement? will the update be applied silently?09:45
ppisati'Snap 'ubuntu-core' for 'powerpc' cannot be found in the 'edge' channel.'09:49
ppisatiwe have a ppc64el ubuntu-core but no powerpc? how come?09:49
mvozyga: a quick look at 3517 would be great, then I can (hopefully) merge and get a new core over lunch for the nested tests10:02
zygamvo: ack, looking10:12
zygamvo: I have spotty network here, I need to fix it (after the sprint) so don't feel discouraged if I dissapear for a moment10:13
niemeyerzyga: Lots of nostalgia :)10:16
niemeyermvo: Just trivials on snapd#351210:16
mupPR snapd#3512: cmd: avoid using current symlink in InternalToolPath <Created by mvo5> <https://github.com/snapcore/snapd/pull/3512>10:16
mvoniemeyer: nice, thank you10:17
mvoppisati: I think we don't have powerpc because we can not (or could not back then) build snaps for powerpc10:17
niemeyermvo: np, review queue looks quite nice today actually :)10:18
niemeyerfgimenez: Didn't we decide to drop the static tests from within Travis?10:18
niemeyermvo, fgimenez: Btw, any more issues on Linode?10:19
niemeyerIt's sort of amazing that we managed to have a bug on our end and a bug on their end on the same week10:19
mvoniemeyer: linode was fine for me in the last few hours10:19
mvo(including last night)10:19
niemeyermvo: Phew10:19
fgimenezniemeyer: afaik they are moved to a spread task let me check10:20
niemeyerfgimenez: That's what I thought as well, but looking through logs recently they seemed to be back10:20
fgimenezniemeyer: i've seen some authentication errors like "ssh error 2017-06-22 16:39:58 Discarding linode:debian-unstable-64 (Spread-04), cannot connect: cannot connect to linode:debian-unstable-64 (Spread-04): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain"10:21
mvoniemeyer: indeed :)10:21
zygamvo: two nitpicks on 351710:21
niemeyerfgimenez: Ok, but that's from yesterday.. there was a real bug on the Linode side this time around10:21
niemeyerfgimenez: They fixed it late yesterday10:21
mvosure, I will reply inline, thanks a bunch10:22
fgimenezniemeyer: great, about the static checks they are currently run here https://github.com/snapcore/snapd/blob/master/tests/unit/go/task.yaml#L1710:22
mvozyga: atoi(getenv("not-exist")) will segfault :) atoi crashes when oyu feed it a NULL10:22
fgimenezniemeyer: and travis only runs spread https://github.com/snapcore/snapd/blob/master/.travis.yml#L2210:23
zygamvo: I meant under the first if10:23
zygamvo: just on the line I commented10:23
niemeyerfgimenez: Okay, it must have been some old code that hasn't merged back from master in a while then10:23
niemeyerfgimenez: Thanks for checking10:23
zygamvo: or just use variables and be less fancy, I wanted to avoid the repeated getenv and atoi10:23
mvozyga: aha, ok10:24
mvozyga: I'm inclinded to merge and do a followup mostly to avoid waiting for the tests again, is that ok with you?10:24
mvozyga: i.e. when I return from lunch I want to have a new core snap :)10:24
zygamvo: certainly, I can follow up as well if you want10:25
zygamvo: small bite for the troubled voyager10:25
mvozyga: sure, even better10:25
fgimenezniemeyer: np, thank you, another weird error from linode this morning "cannot boot linode:ubuntu-16.04-32 (Spread-50): linode disk /dev/sda not ready to boot. Please contact support." https://travis-ci.org/snapcore/spread-cron/builds/246018927#L66910:25
mupPR snapd#3517 closed: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3517>10:25
niemeyerFFS10:27
niemeyerfgimenez: This is the CI infra bug week10:27
fgimenezniemeyer: :) and the ssh issue seems to be still around, this build has it and is currently running https://travis-ci.org/snapcore/snapd/builds/246132571#L90810:28
zyganiemeyer: about that, did you see those scaleway 128GB ram 64 core VMs that are on sale now?10:29
zyganiemeyer: I wonder if we could get really solid arm server spread tests this way10:29
niemeyerfgimenez: Thanks, will look into the console to see if it's the same issue and reopen the ticket10:29
zyganiemeyer: not pi-like tests, just serious arm server snapd10:29
niemeyerzyga: The problem with arm is that in general we want to test the actual device10:29
zyganiemeyer: it _is_ the actual device, this is not the old arm but the new big-iron arm that is not device specific10:30
niemeyerzyga: That's why those magic SD muxes are so interesting10:30
zyganiemeyer: modern x86_64 server10:30
zyganiemeyer: just with arm now :)10:30
niemeyerzyga: Sorry, I don't get the point10:30
zyganiemeyer: we test x86 extensively in VMs10:31
zyganiemeyer: and we test arm on hardware (IOT devices)10:31
niemeyerzyga: Do you mean this 128GB RAM and 64 core server is actually a Raspberry Pi behind the scenes?10:31
niemeyer:P10:31
zyganiemeyer: but we don't have any automated ARM tests like we do for x86 because we don't have arm server hardware (with virtualization and everything)10:31
zyganiemeyer: I'm saying we could run the very same suite of tests we use on x86 VMs on that arm system for better coverage10:32
niemeyerzyga: Yeah, and that's what I meant above10:32
zygaplus, it's beefy and on sale10:32
zyganiemeyer: arm is not just the pi's10:32
niemeyerzyga: The problem is that this doesn't really solve the question of whether the supported devices are broken or not10:32
zyganiemeyer: yes and I'm not saying it does10:33
niemeyerzyga: Yes, it's one more testing platform, that will need custom kernels, custom gadgets, custom everything10:33
zyganiemeyer: no, no custom kernels10:33
niemeyerzyga: Unless someone is working with us to support that, we can't just add more platforms10:33
zyganiemeyer: arm servers use one kernel10:33
zyganiemeyer: all acpi and standards based like x86 servers10:33
niemeyerzyga: That hasn't been my experience with anything arm10:33
zyganiemeyer: because you deal with non server hardware10:34
niemeyerzyga: Ok, so which of our kernels will this use?10:34
zyganiemeyer: stock ubuntu kernel for aarch6410:34
* zyga has to fix his wifi, signal dropping every few seconds10:35
* zyga -> brb10:35
niemeyerzyga: Okay, so classic Ubuntu rather than Ubuntu Core10:37
zyganiemeyer: yes, I'd start with that10:41
=== chihchun_afk is now known as chihchun
* Chipaca ~> lunch11:09
zygamvo: https://github.com/snapcore/snapd/pull/351811:13
mupPR snapd#3518: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>11:13
mupPR snapd#3518 opened: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>11:14
mvozyga: ta11:14
VamsiHi. I had previously asked about a web app store for snaps. And I was suggested to use snapweb. I am facing a problem with snapweb though. I am able access my Ubuntu desktop using the web app store on a browser on the same PC. But I am unable to access my raspbery pi (running on ubuntu core) from the browser on the PC :|11:15
mupPR snapd#3519 opened: arch: the kernel architecutre name is armv7l instead of armv7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3519>11:15
VamsiAlso if it helps, both the PC and the pi are on the same network.11:15
zygaVamsi: what kind of error are you seeing?11:17
zygamvo: +111:17
zygamvo: consider merging my branch too if we lost that slot anyway11:18
mvozyga: ta11:18
Vamsizyga: the browser says that the accsess token is invalid.11:18
zygaVamsi: I see11:19
zygaunfortunately I don't know much about snapweb internals11:19
Vamsibut it accepts the access token from the PC though.11:19
* Chipaca ~> really lunch11:21
* zyga knows the feeling very well Chipaca :)11:22
zygamvo: reviewed 351211:24
zygamvo: let me know if you want me to change that11:24
zygamvo: otherwise I'll work on base updates11:24
mupPR snapd#3520 opened: asserts: add enterprise-store assertion type <Created by atomatt> <https://github.com/snapcore/snapd/pull/3520>11:30
* zyga focuses on base snaps11:34
=== chihchun is now known as chihchun_afk
=== ahoneybun_ is now known as ahoneybun
niemeyerfgimenez: "In this case there was a problem with how the host was reserving disk space while creating new disks. However, one of our administrators was able to fix the problem, and it shouldn't occur again in the future."12:16
fgimenezniemeyer: \o/ ? not sure if that souds really well :)12:17
niemeyerfgimenez: I think it's fine :)12:17
niemeyerYesterday the response was "The previous message yesterday was "It looks like this one was a fluke. I've been able to thaw out the same image on your Linode just fine. Please let us know if it happens again and we'll be glad to look into it further."12:18
jaceknhello. Is https://bugs.launchpad.net/snapd/+bugs the right place for snapd bugs? I filed one yesterday but nobody was subscribed to it and it's still in "New" state12:18
niemeyerWhich is less fine :)12:18
niemeyerjacekn: If you want quick feedback, the forum is the best place to report issues and discuss them12:19
jaceknniemeyer: ack. In this case it looks like a bug so I reported it. It's not super critical12:21
jaceknniemeyer: but is https://bugs.launchpad.net/snapd/+bugs the right place or there is somewhere else I should be reporting bugs?12:22
niemeyerjacekn: If it's about snapd, that's the right place12:22
jacekngreat, thanks for confirmation12:22
niemeyernp12:23
jaceknniemeyer: that location looks dead BTW, there are many old bugs that were not even triaged12:26
niemeyerjacekn: I really mean it when I said the forum is the place to discuss and get quick feedback12:26
jaceknniemeyer: as in you prefer people to open forum threads about bugs rather than file them in LP?12:27
niemeyerjacekn: As in that's where all the daily activities happen, and that's where we discuss issues most frequently.. if you file a bug in Launchpad, it's tracked and will be eventually looked at, but there are many more eyes in the forum every single day12:29
niemeyerjacekn: If you want to talk about the bug today, please open a forum thread12:29
mupPR snapcraft#1376 opened: options: fix s390 kernel arch <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1376>12:31
ogra_ppisati, wow, do we ever exect to support s390 UbuntuCore installs ?12:33
ogra_expect12:33
* ogra_ thinks s390x and ppc64el should simply not be built by the plugin by default ... it is unlikely that anyone will ever actually boot UbuntuCore on such systems12:34
ogra_(kernels that is)12:34
jaceknniemeyer: thanks for explaining. I don't want/need to talk about the bug, totally happy to wait. I wanted to make sure that LP bug tracking was not dead (because that's what it may look to people without context abotu forums)12:34
mupPR snapcraft#1377 opened: kernel plugin: add default targets per powerpc, ppc64el and s390x <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1377>12:34
xnoxogra_, our contracts says different =)12:34
ogra_xnox, you mean there will be people booting off an UbuntuCore image natively ?12:35
xnoxogra_, and core is very much usable in kvm / openstack on both s390x and ppc64el.12:35
xnoxogra_, yes.12:35
ogra_wow12:35
niemeyerjacekn: It's not dead, but it's not well maintained today either, as you've noticed. That's something we need to fix.12:35
* ogra_ notes that he just triaged two snapd bgs that were filed today ... definitely not dead, just not moving super fast since many issues are resolved in forum discussions before even becoming actual bugs12:37
Chipacapedronis: question about aliases: in the json you get from the store, is the 'target' the name of the app?12:44
pedronisChipaca: which json?12:44
Chipacapedronis: ah, maybe this doesn't come to you as json yet12:45
Chipacabut in the declaration itself i guess?12:45
pedronisChipaca: it's in the assertion12:45
pedronisis not json12:45
Chipacathat'd explain why a quick search didn't find me the json bits of this :-)12:45
Chipacapedronis: ok. I'll be getting a list of aliases from the store, in json12:45
pedronisok12:46
Chipacapedronis: [{"name": "foo", "target": "bar"}, ...]12:46
pedronisbut that's unrelated to how we do aliases12:46
pedronisfor actually installed snaps12:46
pedronisthose comes from the signed snap-declaration12:46
Chipacapedronis: right, this is for command-not-found, ie for non-installed snaps12:46
pedronisI know nothing about that (atm)12:46
Chipacaok12:46
pedronisbut yes, internall we keep things as name, taget12:47
pedronisI mean in the internally in the store12:47
Chipacapedronis: and target is the app name?12:47
pedronisyes12:47
Chipacaok12:47
pedronisit's a plain app name12:47
pedronisnot snap.app12:48
Chipacajust double-checking with nessita_ that things are sane :-)12:48
Chipacathat's fine, it'll be "inside" a snap12:48
Chipaca{"package_name": "some-snap", "aliases": [...]}12:48
Chipacaso i'll know the snap :-)12:48
mvofgimenez: yay, good news. the nested core-revert test seems to be working now with current edge12:50
fgimenezmvo: \o/ wonderful news!!! congrats for all the hard work12:51
fgimenezmvo: shall i start with the full validation?12:51
mvofgimenez: some smoke testing for edge with the core revert would be great, or just an independant re-run, I need to get this all backported to 2.26, then we can do te real validation12:57
fgimenezmvo: sure, i have the core revert already running locally, in fact it was started automatically too by spreadcron when the new core was detected but  it was killed because of the time restriction https://travis-ci.org/snapcore/spread-cron/builds/24617510813:01
fgimenezi'll run some additional smoke tests13:02
=== chihchun_afk is now known as chihchun
fgimenezcachio: we are still getting create-key timeout errors, have all the fixes landed? https://travis-ci.org/snapcore/spread-cron/builds/24617515713:27
cachiofgimenez, ouch13:29
cachiofgimenez, it is failing to restart the service13:29
cachiofgimenez, the manual was working better than the automatic restart13:32
cachiodid you merge your branch with the latest changes in master?13:35
cachiofgimenez,13:35
fgimenezcachio: yes, this is executed from the current master13:37
fgimenezcachio: https://github.com/snapcore/spread-cron/blob/snapd-core-i386-edge/run-checks13:38
cachiofgimenez, ok, thanks for the info, I'll research more13:38
fgimenezcachio: ok thx13:39
jdstrandmvo: nice speed improvement in https://github.com/snapcore/snapd/pull/3502. Thanks for doing that PR (fyi, I commented)13:41
mupPR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>13:41
zygajdstrand: hey13:43
zygajdstrand: greetings from Poland :)13:43
jdstrandzyga: hi! :) nice to be back?13:44
zygajdstrand: it's a big change in our lives, not sure yet :)13:46
jdstrandmvo: I also notice https://github.com/snapcore/snapd/pull/3504 isn't committed yet. isn't it needed to truly test the revert regression that the bpf fixes?13:46
mupPR snapd#3504: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504>13:46
zygajdstrand: thank you for the review on the cleanup, I'll follow up shortly13:46
jdstrandzyga: oh, permanently? wow13:46
jdstrandzyga: thanks you for doing it :)13:46
zygajdstrand: yes, all our stuff is packed into ~60 boxes now13:46
zygajdstrand: (most haven't arrived yet)13:46
jdstrandsome quick example code went through as is and then I missed the NULL checks :\ that's why we have more than one reviewer! :)13:47
zygajdstrand: yep, it's always possible to miss something13:47
zygajdstrand: but I'm very happy with the changes towards precompiled bpf13:48
jdstrandzyga: does this mean you will attend (in part or in whole) the Warsaw sprint?13:48
zygajdstrand: it's going to be safer and faster13:48
zygajdstrand: I plan to but I didn't talk to JamieBennett about it yet13:48
zygajdstrand: if anything I'll drop by to get a coffee and say hi :)13:48
jdstrandzyga: if you do, we can visit (I'll be there)13:48
fgimenezmvo: core-revert succeeded with the edge core snap \o/ I'm currently generating images for running the full suite on them, will keep you posted13:48
zygajdstrand: I'd never miss the only sprint in warsaw :)13:48
jdstrandhehe :)13:48
zygajdstrand: that's great to hear :-) I'll show you around Warsaw (except I need to catch up after 6 years of living in Spain)13:49
jdstrandfgimenez: note my above question to mvo re https://github.com/snapcore/snapd/pull/350413:49
mupPR snapd#3504: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504>13:49
fgimenezjdstrand: aha thanks, good to know, all seems to be working fine now fwiw, anyway will keep running it in a loop to try to catch racy results13:52
jdstrandfgimenez: I guess there was the netlink revert failure that never had the policy reverted. I don't know if you are testing that snap, but if you are, then that PR isn't strictly needed to demonstrate the fix13:55
mvojdstrand: hey, thanks for the review of 3502. re 3504 - our test also failed without the reverts, but I agreee, we should do the test with that one merged too. we had a failure with bluez that hit exactly the same issue so I'm quite confident that the fix is there. but then, I'm much in favour of double checking :)13:56
mvojdstrand: it needs a second review, then it can go in13:57
jdstrandmvo: yeah, I just remembered netlink wasn't reverted13:58
fgimenezjdstrand: exactly, the test includes bluez, which was failing after revert with "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process", with the current core at edge this problem is gone13:58
jdstrandok, perfect13:58
jdstrandperhaps zyga would want to peek at 3504 :)13:58
mupPR snapd#3519 closed: arch: the kernel architecutre name is armv7l instead of armv7 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3519>14:01
niemeyerIt's getting to that point where I type "snap install blah" and then wonder why nobody has snapped blah yet14:43
mupPR snapcraft#1378 opened: Integration tests for snap command with target arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1378>15:19
mvofgimenez: hm,hm, it looks like #3519 got merged 4h ago but its not part of the snapd-vendor branch (and hence not in the ppa) yet, any idea?15:26
mvofgimenez: can I manually trigger this?15:26
fgimenezmvo: mm maybe the build after merging on master didn't succeed, the sync is done after merge + green build15:29
fgimenezmvo: i'll check, anyway you can retrigger from #mupmock on tg, this will get the current master no matter if the test passed or not, let me show you15:30
mupPR snapd#3521 opened: snap-seccomp: make sure snap-seccomp writes the bpf file atomically <Created by mvo5> <https://github.com/snapcore/snapd/pull/3521>15:40
fgimenezmvo: i got two errors executing the suite from master on the latest edge http://paste.ubuntu.com/24933366/, if you could take a look that would be great, i'm trying to reproduce both of them now15:41
mvofgimenez: thanks, 2017/06/23 16:52:12 Error executing external:ubuntu-core-16-64:tests/main/server-snap:goServer :  is strnage, no denials or anything15:42
mvofgimenez: the snapd-notify is hopefully fixed with 351515:44
mvocachio: could oyu please check 3515 why the testsuite fails?15:44
fgimenezmvo: ok thx, i'll focus on server-snap:goServer then15:44
mvoChipaca: 3521 is something for you, the best thing is that we probably caught it via one of the tests :)15:45
mvo(spread tests)15:45
fgimenezmvo: it fails consistently, adding -v to the nc call i get "nc: connect to ip6-localhost port 8081 (tcp) failed: Cannot assign requested address", the session is open in case you want to get anything else15:54
mvofgimenez: is the service itself running?15:54
fgimenezmvo: yep, it's up and listening on 8081 http://paste.ubuntu.com/24933471/15:56
fgimenezmvo: i think this is probably related to the changes to the way we manage ipv6 when /etc/gai.conf is not writable http://paste.ubuntu.com/24933600/16:07
mvofgimenez: aha, puhhh, that a) makes sense b) means I did not break it .)16:08
fgimenezmvo: yep :) http://paste.ubuntu.com/24933635/ i'll prepare a PR for fixing it16:09
mvofgimenez: I broke master bug 35212 should fix that16:09
mupBug #35212: unable to compose messages <Mozilla Thunderbird:Fix Released> <mozilla-thunderbird (Ubuntu):Fix Released by adconrad> <https://launchpad.net/bugs/35212>16:09
fgimenezmvo: thx, np16:10
fgimenezmvo: anyway, it won't affect the backport to 2.26, we didn't have any changes related to /etc/gai.conf there16:12
=== chihchun is now known as chihchun_afk
mupPR snapd#3522 opened: tests: do not disable ipv6 on core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3522>16:29
mupPR snapcraft#1374 closed: tests: set up the spread execution in linode <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1374>16:52
mupPR snapcraft#1379 opened: blank version not allowed in snapcraft.yaml <Created by roxyd> <https://github.com/snapcore/snapcraft/pull/1379>17:04
mupPR snapcraft#1380 opened: release changelog for 2.32 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1380>17:16
mupPR snapd#3523 opened: tests: fix for create-key task to avoid rng-tools service ramains alive <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3523>17:44
mupPR snapd#3524 opened: asserts,overlord/devicestate: allow and support serials signed by a trusted authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3524>18:11
mupPR snapd#3522 closed: tests: do not disable ipv6 on core systems <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3522>18:25
mupPR snapcraft#1381 opened: tests: install pyramid in autopkg integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1381>18:41
cachiomvo, sorry for the delay19:29
cachiothe 3515 is failing due to the reboot error19:30
cachiomvo, it is one of the most difficult tests to fix19:30
cachiomvo, it always happens on ubuntu-core-16-64 and the issue is that after the core image is created and the system rebooted, the machine does not start anymore19:32
cachiomvo, I also pushed a fix for the create-key issue, this should be the final one19:35
mvocachio: nice, thank you19:44
cachiomvo, if you can retrigger it should be fine19:44
mvocachio: yeah, I noticed the that the ubuntu-core-16-64 issue is tricky19:44
mvocachio: sure, let me do that19:44
cachiomvo, then if you can trigger also 352319:45
cachioif failed because of the snapd-notify19:46
cachioit failed19:46
mvocachio: sure thing19:48
mvocachio: I can not (easily) retrigger autopkgtests, we need to ignore those for now. sorry for that19:49
cachiomvo, np19:54
mupPR snapd#3525 opened: interfaces: add password-manager-service implicit classic interface (LP: #1653769) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3525>20:15
cachioniemeyer, could yo please take a look to Spread-1420:59
cachioin the console20:59
cachioniemeyer, 50.116.52.4720:59
cachioniemeyer, in case it is powered off, could yo uplease try to start it and see the screen output?21:01
mupPR snapcraft#1381 closed: tests: install pyramid in autopkg integration tests <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1381>21:14

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