| Son_Goku | sabdfl: so you're on this side of the pond now? | 02:47 |
|---|---|---|
| === ikey is now known as ikey|zzz | ||
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| zyga-ubuntu | good morning | 06:14 |
| * zyga-ubuntu does PR pass | 06:15 | |
| zyga-ubuntu | mvo: o/ | 06:21 |
| zyga-ubuntu | mvo: hey | 06:29 |
| zyga-ubuntu | mvo: I'm willing to do a deep dive on https://github.com/snapcore/snapd/pull/4030 | 06:29 |
| mup | PR #4030: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4030> | 06:29 |
| zyga-ubuntu | mvo: unless you are already doing that | 06:29 |
| Son_Goku | zyga-ubuntu | 06:31 |
| Son_Goku | that seems like a super-bad idea | 06:31 |
| zyga-ubuntu | Son_Goku: hey | 06:35 |
| zyga-ubuntu | Son_Goku: I know | 06:35 |
| zyga-ubuntu | Son_Goku: but if it's sufficient let's do it the best we can: | 06:35 |
| zyga-ubuntu | Son_Goku: I'd discard the generated files, discard uneeded code, integrate it into our build system, ete | 06:35 |
| zyga-ubuntu | Son_Goku: I haven't looked yet, maybe it is huge, maybe it will end up being a handful of files that we can just maintian | 06:35 |
| zyga-ubuntu | *maintain | 06:36 |
| zyga-ubuntu | Son_Goku: and good morning :) | 06:36 |
| zyga-ubuntu | Son_Goku: you're up early, it's barely sunrise here | 06:36 |
| Son_Goku | I'm about to pass out | 06:36 |
| zyga-ubuntu | my son is in a new school today | 06:36 |
| zyga-ubuntu | so I'm working from a coffee shop nearby | 06:36 |
| Son_Goku | zyga-ubuntu: I think it's a really bad idea to do this at all | 06:36 |
| zyga-ubuntu | Son_Goku: sure but what is the alternative? | 06:36 |
| zyga-ubuntu | Son_Goku: if we have to do it, we have to do it | 06:37 |
| zyga-ubuntu | Son_Goku: we canont just change apt defaults overnight (even though I agree they are bad) | 06:37 |
| zyga-ubuntu | Son_Goku: those should have been changed years ago | 06:37 |
| zyga-ubuntu | Son_Goku: but I think that now it is too late for that | 06:37 |
| Son_Goku | well, if people are updating graphically or using `apt upgrade`, they'd get it | 06:37 |
| Son_Goku | just fix apt-get upgrade's behavior | 06:38 |
| zyga-ubuntu | Son_Goku: yes but there is always a set that doesn't | 06:38 |
| zyga-ubuntu | Son_Goku: I think we've seen that already with snapd before (and we reverted a change that triggered that) | 06:38 |
| zyga-ubuntu | Son_Goku: it will also be a (I suspect) endless discussion in debian | 06:38 |
| zyga-ubuntu | Son_Goku: I think it's risky business to go and change that for snapd's sake | 06:38 |
| zyga-ubuntu | Son_Goku: (I'd still change it but on separate schedules) | 06:39 |
| zyga-ubuntu | Son_Goku: and once snapd can reliably depend on things, let's yank this | 06:39 |
| Son_Goku | then don't integrate it into the source tree | 06:39 |
| Son_Goku | just carry it as a separate tarball bundle | 06:39 |
| zyga-ubuntu | mmm | 06:39 |
| Son_Goku | that way it's harder to be lazy about it | 06:39 |
| zyga-ubuntu | that's interesting, perhaps that's a better idea indeed | 06:39 |
| zyga-ubuntu | Son_Goku: i'd require some tweaks to CI but yes, it's nicer this way | 06:40 |
| Son_Goku | zyga-ubuntu: I wish you'd do this with a vendor overlay tarball too | 06:44 |
| Son_Goku | basically, a tarball that only contains snapd-<version>/vendor/ | 06:44 |
| zyga-ubuntu | Son_Goku: yes, I think that's a natural place to do this for releases | 06:45 |
| zyga-ubuntu | Son_Goku: I'll talk to mvo | 06:45 |
| Son_Goku | this would allow me to ship the snapd-<version>.tar.gz (or in debian parlance, snapd-<version>.orig.tar.gz) and snapd-<version>.vendor.tar.gz in distgit as sources while not using the vendor tarball on Fedora | 06:46 |
| Son_Goku | which would open the door to adding an EPEL build | 06:47 |
| Son_Goku | (aka CentOS) | 06:47 |
| mvo | zyga-ubuntu: a vendor tarball? we can do this easily | 06:47 |
| Son_Goku | I asked for this a year ago too, btw | 06:48 |
| mvo | :( | 06:48 |
| mvo | sorry | 06:48 |
| mvo | must have forgoten | 06:48 |
| Son_Goku | the experimental CentOS builds are super-brittle :( | 06:48 |
| Son_Goku | zyga-ubuntu: incidentally, for your amusement, with literally no expectation of anything working: https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/ | 06:49 |
| mvo | Son_Goku: so snapd_2.28.5.{pristine,vendor}.tar.xz? a | 06:49 |
| Son_Goku | mvo: yep | 06:49 |
| Son_Goku | sounds fine with me :D | 06:49 |
| mvo | ok | 06:50 |
| * mvo will update his release script | 06:50 | |
| Son_Goku | mvo: basically, I need the base tarball to be closest to what git repo looks like, otherwise patches don't apply | 06:50 |
| Son_Goku | mvo: though you don't have to do weird underscores and whatnot :) | 06:51 |
| Son_Goku | unlike debian, I don't have such restrictions :) | 06:51 |
| mvo | Son_Goku: heh, ok | 06:51 |
| zyga-ubuntu | o/ | 06:52 |
| Son_Goku | it can just be snapd-2.28.5.tar.xz and snapd-2.28.5.vendor.tar.xz | 06:52 |
| mvo | Son_Goku: ok, I may need to keep the current convention for people using our GH release page, so it might be snapd.vendor-only.tar.xz or I will just annouce the new format and assume that not a lot of people need to adjust their scripts | 06:53 |
| Son_Goku | sure | 06:54 |
| Son_Goku | that's fine | 06:54 |
| Son_Goku | I don't particularly care if you only just upload a vendor-only tarball | 06:54 |
| Son_Goku | as I can just get the regular one from the GitHub link as I do now | 06:54 |
| zyga-ubuntu | mvo: I think it's just a handful of people, we'll be fine | 06:54 |
| Son_Goku | I just need the vendor code in a separate tarball that I can extract | 06:54 |
| mup | PR snapd#4047 opened: snap-confine: init all arrays with `= {0,}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4047> | 06:56 |
| zyga-ubuntu | mvo: .5 looks good so far | 07:08 |
| * zyga-ubuntu tweaks details on https://github.com/snapcore/snapd/pull/4008 | 07:09 | |
| mup | PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008> | 07:09 |
| Son_Goku | zyga-ubuntu: test and give karma for Fedora snapd updates | 07:12 |
| Son_Goku | they're on 2.28.5 now | 07:12 |
| mvo | zyga-ubuntu: could you or pawel try to reproduce the error on the pi3 that sergio got? I'm still nervous about it. otoh I have no report other than from sergio about it and would love to get that confirmed | 07:12 |
| zyga-ubuntu | mvo: I cannot do that today, sorry, I won't be home until after 18 | 07:19 |
| zyga-ubuntu | mvo: it seems the error cachio got was repeated on >1 SD card he had | 07:19 |
| zyga-ubuntu | maybe it's just bad luck but it does seem to indicate more than random issue | 07:20 |
| zyga-ubuntu | Son_Goku: only after I'm home, sorry :/ | 07:20 |
| zyga-ubuntu | mvo: though my pi3 is still up | 07:21 |
| zyga-ubuntu | mvo: I could try to test something remotely | 07:21 |
| zyga-ubuntu | pstolowski: hey | 07:23 |
| zyga-ubuntu | pstolowski: is your pi3 operational? | 07:23 |
| zyga-ubuntu | mvo: my pi3-1 is operational, though I cannot reflash it remotely | 07:24 |
| pstolowski | zyga-ubuntu, morning! yes, it is | 07:31 |
| zyga-ubuntu | pstolowski: I think mvo needs a little bit of help and I'm not at my office today | 07:31 |
| zyga-ubuntu | 09:12 < mvo> zyga-ubuntu: could you or pawel try to reproduce the error on the pi3 that sergio got? I'm still nervous about it. otoh I have no report other | 07:31 |
| zyga-ubuntu | than from sergio about it and would love to get that confirmed | 07:31 |
| zyga-ubuntu | pstolowski: I can only run spread tests on pre-installed remotely | 07:31 |
| zyga-ubuntu | pstolowski: last week cachio ran into a bug where smoehing got corrupted in the boot process | 07:32 |
| zyga-ubuntu | pstolowski: it might be related to the SD card he was using (he tried two) | 07:32 |
| zyga-ubuntu | pstolowski: we need hands on testing to see if we can reproduce it | 07:32 |
| pstolowski | zyga-ubuntu, sure, happy to help. i need to reflash with latest edge image correct? | 07:35 |
| zyga-ubuntu | pstolowski: I think so, ideally build the image as cachio did | 07:35 |
| * zyga-ubuntu looks | 07:35 | |
| zyga-ubuntu | pstolowski: look at this thread please: https://forum.snapcraft.io/t/snap-mode-try-on-raspberry-pi/2454 | 07:36 |
| pstolowski | zyga-ubuntu, k | 07:38 |
| === kira is now known as Guest92109 | ||
| Guest92109 | hello got stuck in network configuration can any one please help | 07:41 |
| zyga-ubuntu | Guest92109: hey, can you please ask a more precise question? | 07:42 |
| Guest92109 | zyga-ubuntu: Sure | 07:42 |
| zyga-ubuntu | pstolowski: I commented on the thread with details of what I know | 07:42 |
| pstolowski | zyga-ubuntu, thanks | 07:42 |
| Guest92109 | I got a machine with ubuntu core15.10 | 07:42 |
| Guest92109 | I need to configure eth0 | 07:43 |
| Guest92109 | I teied to edit /etc/network/interfaces file but it gives system is read-only message please help | 07:43 |
| zyga-ubuntu | Guest92109: 15.10 you say | 07:46 |
| zyga-ubuntu | hmmm | 07:46 |
| zyga-ubuntu | Guest92109: may I ask if you really want to use 15.10 or can you consider updating to ubuntu core 16? | 07:46 |
| pstolowski | zyga-ubuntu, what are the steps to build an image? | 07:47 |
| zyga-ubuntu | Guest92109: I don't think we support 15.10 anymore (apart from commercial contracts) as it was an early version and ubuntu core 16 has received immense fixes, features and improvements since | 07:47 |
| zyga-ubuntu | pstolowski: I think you need ubuntu-image and the pi3 model, one sec | 07:48 |
| zyga-ubuntu | pstolowski: $ sudo ubuntu-image -c beta -O pi3-beta.img pi3.model | 07:48 |
| Guest92109 | <zyga-ubuntu> - I am using dell edge gateway 5000 series which comes with preinstalled snappy core 15.10 and need to configure same | 07:48 |
| zyga-ubuntu | Guest92109: it used to ship with 15.10 with the desire to update to 16-series, new releases are only using 16; in any case let me try to find someone who can help you | 07:49 |
| zyga-ubuntu | pstolowski: you need the pi3.model assertion | 07:50 |
| zyga-ubuntu | pstolowski: cachio sent a link somewhere to a repo with test scripts but I cannot find it | 07:50 |
| zyga-ubuntu | mvo: do you happen to remember how to fetch the pi3 model file | 07:50 |
| zyga-ubuntu | Guest92109: I've asked around but I don't know how soon I'll get an answer | 07:51 |
| zyga-ubuntu | Guest92109: may I suggest that you go to forum.snapcraft.io and ask your question there | 07:51 |
| Guest92109 | zyga-ubuntu: thanks in advance would be a great help i am not getting any help onlien | 07:51 |
| zyga-ubuntu | Guest92109: please double check that you cannot upgrade your device to 16 series, then we can all help you easily | 07:52 |
| zyga-ubuntu | Guest92109: I think 15.10 is not supported anymore (apart from contractual obligations) and everyone is strongly encouraged to go to 16 | 07:52 |
| Guest92109 | zyga-ubuntu: Sure thanks but can u just answer is the read-only file system also persist in 16 series | 07:53 |
| Guest92109 | While configuring /etc/network/interfaces file | 07:53 |
| zyga-ubuntu | Guest92109: yes although network configuration in 16 series is different and much much easier | 07:53 |
| zyga-ubuntu | Guest92109: apart from a menu-driven wizard we also use declarative YAML based nplan (netplan) configuration | 07:54 |
| zyga-ubuntu | Guest92109: while the system as a whole is read only the set of writable files is different | 07:54 |
| zyga-ubuntu | Guest92109: (between 16-series and 15.10) | 07:54 |
| zyga-ubuntu | kissiel: ^ | 07:55 |
| zyga-ubuntu | kissiel: I think you are experienced with the dell gateways more than I am | 07:55 |
| Guest92109 | zyga-ubuntu: Thanks can i get the steps of 16 series, i will get the idea regarding the configuration | 07:56 |
| zyga-ubuntu | Guest92109: it's a simple process you follow using the on-screen menu (also availale via serial port) | 07:57 |
| zyga-ubuntu | Guest92109: you can run "console-conf" after initial setup if you wish to change the configuration | 07:57 |
| kissiel | Guest92109: I'd poke around network-manager snap | 07:57 |
| zyga-ubuntu | kissiel: note, Guest92109 is using 15.10, I'm not sure we still ship that snap for 15.10 | 07:57 |
| mvo | zyga-ubuntu, pstolowski sorry, was distracted, do you still need the pi3 model assertion ? i | 07:57 |
| mvo | pstolowski: "snap known --remote model series=16 brand-id=canonical model=pi3" | 07:58 |
| kissiel | zyga-ubuntu: ah, right. maybe joc will know more, I'll ping him when he gets online | 07:58 |
| zyga-ubuntu | mvo: thank you, I had a copy but I forgot how I got it | 07:59 |
| zyga-ubuntu | Guest92109: joc is in the UK timezone, he should be around soon | 07:59 |
| Guest92109 | zyga-ubuntu: Thanks a lot for ur support one last thing how would i know if he comes online | 08:01 |
| pstolowski | mvo, zyga-ubuntu thanks! so, I'm going to rebuild the pi3 image, flash it, configure pi3, then add the assertion on it, then run ubuntu-core-upgrade spread test on it in a loop; did i miss anything? | 08:02 |
| zyga-ubuntu | pstolowski: the assertion is needed to build the image | 08:03 |
| pstolowski | ah! | 08:03 |
| zyga-ubuntu | pstolowski: you need to set up the pi for external backend | 08:03 |
| pstolowski | ok | 08:03 |
| zyga-ubuntu | pstolowski: this is described in tests/external-backend.md | 08:03 |
| zyga-ubuntu | pstolowski: have a look, you just flash & first-boot as usual | 08:04 |
| zyga-ubuntu | pstolowski: then run a few scripts | 08:04 |
| zyga-ubuntu | pstolowski: (from the tree) | 08:04 |
| zyga-ubuntu | pstolowski: and then you are ready for testing | 08:04 |
| zyga-ubuntu | pstolowski: ask if you need help, I did this on Friday | 08:04 |
| pstolowski | zyga-ubuntu, oh yeah, i know that, just unclear on building the image + assertion part | 08:05 |
| mvo | pstolowski: yes, what zyga-ubuntu said and good luck | 08:06 |
| __chip__ | morning peeps | 08:06 |
| zyga-ubuntu | __chip__: hello, good morning | 08:07 |
| __chip__ | i'm on the road today -- doing admin stuff wrt the boys' schooling | 08:07 |
| __chip__ | got my tablet with me (thus the nick) | 08:07 |
| zyga-ubuntu | __chip__: I'm on the road too, and my son changed school (well, maybe, trial week) | 08:07 |
| zyga-ubuntu | __chip__: fingers crossed for both of us : | 08:07 |
| zyga-ubuntu | :) | 08:07 |
| __chip__ | zyga-ubuntu: hah. this is about changing schools also (looking into a different school) | 08:08 |
| __chip__ | so, yeah, good luck to us | 08:08 |
| pstolowski | mvo, zyga-ubuntu ok, all clear, i see where the assertion is needed now, thanks | 08:08 |
| zyga-ubuntu | mvo: if you want I can keep running that test on my pi3 but I think it depends on SD card model | 08:09 |
| zyga-ubuntu | mvo: and some models corrput something | 08:09 |
| zyga-ubuntu | mvo: otherwise why would it never fail vs always fail? | 08:09 |
| pstolowski | ok, got the image built, falshing | 08:10 |
| mvo | zyga-ubuntu: did you build the image yourself when you did the test? or download a pre-made one? maybe its a specific combination of the ubuntu-image cmdline/kernel/gadget or something | 08:12 |
| zyga-ubuntu | mvo: no, I ran the pre-made one | 08:13 |
| zyga-ubuntu | mvo: ah, indeed | 08:14 |
| zyga-ubuntu | mvo: could be! | 08:14 |
| __chip__ | pedronis: are you working today? | 08:17 |
| zyga-ubuntu | morphis: Guest92109 here has a dell gateway with ubuntu 15.10 and need help, can you please try to render assistance? | 08:22 |
| * zyga-ubuntu is on the move again, I'll be online in ~~ hour | 08:23 | |
| zyga-ubuntu | ttyl | 08:23 |
| mup | Bug #1723881 opened: [Feature Request] Support pre-invoke and post-invoke commands as DPkg::Pre-Invoke and DPkg::Post-Invoke in APT <Snappy:New> <https://launchpad.net/bugs/1723881> | 08:25 |
| joc | Guest92109: hi, i see you had some questions about the 5000 series gateways | 08:48 |
| pstolowski | mvo, it failed for me, but with slightly different output http://pastebin.ubuntu.com/25751741/ | 08:53 |
| pstolowski | Error: "snap_mode" not defined ? | 08:54 |
| pstolowski | mvo, it seems that re-running the test again after the above failure gives another unexpected failure, i assume the box is now in a bad shape and needs re-flashing before attempting tests again? | 09:05 |
| mvo | pstolowski: looking | 09:06 |
| mvo | pstolowski: could you please paste the other failure too? | 09:07 |
| mvo | pstolowski: this is very different from what cachio got, it went much further | 09:07 |
| pstolowski | mvo, the other failure after I re-run the tests: http://pastebin.ubuntu.com/25751799/ | 09:08 |
| mvo | pstolowski: and a different error, I would love to compare the revisions of core/gadget/kernel you have and the revision of ubuntu-image to see where things are different | 09:08 |
| pstolowski | mvo, external:ubuntu-core-16-arm-32 .../tests/main/ubuntu-core-upgrade# snap list | 09:08 |
| pstolowski | Name Version Rev Developer Notes | 09:08 |
| pstolowski | core 16-2.28.5 3214 canonical core | 09:08 |
| pstolowski | pi2-kernel 4.4.0.1075.75 43 canonical kernel | 09:08 |
| pstolowski | pi3 16.04-0.5 6 canonical gadget | 09:08 |
| mvo | pstolowski: maybe we can put it into sergios forum post? this way we can compare notes more easily | 09:09 |
| pstolowski | sure | 09:09 |
| mvo | pstolowski: the followup looks indeed just like a test issue with a strange state, might be enough to just "rm curChg" in the debug shell and run again | 09:10 |
| mvo | pstolowski: thank you, this looks promising, it does not fail in the omg-cant-explain-what-is-going on way at least (which is the case for sergios error, I can't make any sense of it) | 09:11 |
| pstolowski | mvo, I hope I didn't miss anything in the setup. will re-try from scratch in a while | 09:12 |
| mvo | pstolowski: if you could rm curChg and run again, that would be nice | 09:13 |
| mvo | pstolowski: miss something> well, if its really hard to reproduce it means its not wide-spread at least. i.e. we can't reproduce it with the pre-build images, we can't reproduce the same error with ubuntu-image, so it must be sometihng special | 09:14 |
| mvo | pstolowski: well, hopefully | 09:14 |
| kissiel | Guest92109: joc is online, you could consult him | 09:18 |
| jamespage | anyone else hitting https://bugs.launchpad.net/snapcraft/+bug/1723898 ? | 09:25 |
| mup | Bug #1723898: Unable to build snaps using python plugin - pypi.debian.net no longer accessible <Snapcraft:New> <https://launchpad.net/bugs/1723898> | 09:25 |
| jamespage | for the life of me I can't actually figure out where snapcraft is configured to use that | 09:25 |
| mvo | hrm, hrm, interfaces-cups-control test is busted | 09:26 |
| mvo | (in debian-unstable) | 09:26 |
| zyga-ubuntu | re | 09:26 |
| zyga-ubuntu | (and right on time) | 09:26 |
| mvo | zyga-ubuntu: heh :) debian-unstable cups control test is busted, that rings a bell, iirc we had artful broken as well recently. anyways, I'm debugging | 09:28 |
| Guest92109 | kissiel: Thanks | 09:28 |
| Guest92109 | joc: Hello I have a dell edge geteway with ubuntu 15.10 snappy core | 09:29 |
| Guest92109 | I am having difficulty in configuring the network using the traditional ubuntu method in the interfaces file | 09:30 |
| Guest92109 | as the system is read-only | 09:30 |
| joc | Guest92109: if i could first make a recommendation: if you are just beginning a project then zyga & kissiel were correct in urging you to update to Series 16 Ubuntu Core, we have been working with Dell to transition customers for serveral months to Series 16 | 09:33 |
| joc | Guest92109: in addition I believe Dell announced that your version of Ubuntu Core would go End Of Life on September 30th so you will not receive further security updates | 09:34 |
| zyga-ubuntu | mvo: ack | 09:35 |
| zyga-ubuntu | mvo: let me know if I can help in some way | 09:35 |
| zyga-ubuntu | mvo: I'm updating my branches | 09:35 |
| joc | Guest92109: in the meantime the supported method for configuring the network is to use network-manager which should come preinstalled on your system | 09:36 |
| mvo | zyga-ubuntu: yeah, I keep you updated, waiting for a debug shell right now. a cheap way would be to simply disable the test | 09:36 |
| mvo | zyga-ubuntu: on debian | 09:36 |
| zyga-ubuntu | mvo: is there a thread? | 09:36 |
| mvo | zyga-ubuntu: otoh, it will probably come back to use for artful+1 | 09:36 |
| mvo | zyga-ubuntu: not yet, I just noticed with my most recent PR that it fails | 09:36 |
| * zyga-ubuntu was reading something while stuck in transit and is a bit freaked out about this: | 09:36 | |
| zyga-ubuntu | ok | 09:36 |
| zyga-ubuntu | http://papers.mathyvanhoef.com/ccs2017.pdf | 09:37 |
| zyga-ubuntu | mvo: note, our spread image differs for linode and qemu | 09:37 |
| zyga-ubuntu | mvo: qemu uses, I believe, real sid, while linode is using stretch | 09:37 |
| zyga-ubuntu | mvo: I wanted to fix this a while ago but I wans't sure how | 09:37 |
| mvo | zyga-ubuntu: yeah, I'm running against linode just to be sure | 09:37 |
| mvo | zyga-ubuntu: however there was a new upstream release of cups to unstable yesterday so most likely fallout from that | 09:38 |
| Guest92109 | joc: thanks for your valuable information | 09:38 |
| Guest92109 | Will contact them and do the same | 09:38 |
| Guest92109 | Can i get a doc where complete step is mentioned how to open network manager and configure | 09:39 |
| zyga-ubuntu | mvo: aha | 09:39 |
| zyga-ubuntu | mvo: that paper I linked to looks like a massive security issue that affects everything using wifi, expect surge of updates everywhere :/ | 09:40 |
| Guest92109 | I am new to core and tried various commands using snappy but could not get the setting . Thanks in advance | 09:40 |
| zyga-ubuntu | morphis: I think you need to update hostapd | 09:40 |
| joc | Guest92109: configuration should be via the "nmcli" command | 09:43 |
| zyga-ubuntu | pstolowski: can you try the test a few more times? | 09:44 |
| Guest92109 | joc: sure will check and let u know :) | 09:44 |
| joc | Guest92109: there should be plenty of documentation for that in mangpages and on the internet, I would have to check with our Dell liasons whether there is some official docs for customers | 09:44 |
| Guest92109 | joc: Thanks a lot would be a great help | 09:46 |
| mup | PR snapd#4048 opened: tests: fix interfaces-cups-control test for cups-2.2.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4048> | 10:11 |
| zyga-ubuntu | mvo: +1 :) | 10:12 |
| mvo | zyga-ubuntu: ta | 10:12 |
| mvo | zyga-ubuntu: silly idea - could we simply govendor the squashfuse binary :) ? | 10:12 |
| mvo | zyga-ubuntu: it looks like govendor does not care if the git repo is go | 10:13 |
| zyga-ubuntu | mvo: mmm, dunno, how do you envision that? a go binary linking to something that is squashfuse itself or just a "govendor sync" repo that keeps all of squashfuse code but is unrelated to go | 10:13 |
| mvo | zyga-ubuntu: the later, just to have the git checkout and we do the building ourselfs | 10:14 |
| zyga-ubuntu | I like that much more than the PR | 10:14 |
| * kalikiana coffee | 10:14 | |
| mvo | zyga-ubuntu: its slightly crazy but maybe a nicer option than the massive embedding | 10:15 |
| zyga-ubuntu | mvo: yes, certainly nicer | 10:16 |
| zyga-ubuntu | *certainly | 10:16 |
| ogra_ | mvo, urgh ... i think i found your reason for the upgrade test issues ... | 10:33 |
| ogra_ | mvo, https://dashboard.snapcraft.io/dev/snaps/5596/configurations/ | 10:33 |
| ogra_ | candidate and beta use the stable gadget (ancient firmware and uboot) | 10:34 |
| ogra_ | if you dont start from edge this wil most likely always fail with newer kernels | 10:34 |
| ogra_ | pstolowski's last comment on the thread helped a great deal ... | 10:35 |
| ogra_ | mvo, if you dont mind, i'll switch beta and candidate to the latest edge gadget | 10:36 |
| pstolowski | ogra_, oh, the versions? | 10:37 |
| ogra_ | pstolowski, yeah, your pi3 is the stable one | 10:37 |
| ogra_ | (pi3 snap) | 10:37 |
| mvo | ogra_: lets not change it just yet, lets see if cachio can refresh to edge gadget to make the issue go away | 10:38 |
| mvo | ogra_: but it sounds great | 10:38 |
| mvo | ogra_: I mean, great in the sense that it sounds like a plausible theory | 10:38 |
| mvo | ogra_: and also would explain all the oddness around the issue | 10:38 |
| ogra_ | mvo, well, he'Äd have to build an edge image and then downgrade kerne/coe to the espective target channels he wants to test | 10:39 |
| ogra_ | mvo, what doesnt go well with that theory is that it only started recently | 10:39 |
| mvo | ogra_: yeah, he says it started recently, hm, hm | 10:39 |
| ogra_ | there must be another aspect to it since the gadget channel setup has never changed after the first stable one | 10:40 |
| ogra_ | but it is defintely one of the issues | 10:40 |
| pstolowski | ogra_, hmm, ok all the rpi3 stuff is new to me, so please bear with me... I didn't miss any setup test, did I? | 10:41 |
| ogra_ | pstolowski, well, if i wanted to test beta i'*d also just builld a beta image, the issue is on ou side, not on yours | 10:42 |
| ogra_ | *our | 10:42 |
| pstolowski | ok | 10:42 |
| pstolowski | ogra_, interestingly, i re-flashed and testing again, it a 3rd run of the test and so far so good | 10:43 |
| pstolowski | *it's a 3rd | 10:43 |
| mvo | pstolowski: ha! | 10:43 |
| ogra_ | and pi3 is still at rev 6 ? | 10:43 |
| mvo | pstolowski: so you and cachio need to compare notes what is different | 10:43 |
| pstolowski | ogra_, yes, rev 6 still | 10:44 |
| ogra_ | ++ fw_printenv snap_mode | 10:44 |
| ogra_ | ## Error: "snap_mode" not defined | 10:44 |
| mvo | ogra_: lets try to find what this other factor is, then we need to fix the gadget to match the beta kernel. but lets try to get to the bottom of this first | 10:44 |
| ogra_ | thats the thing that made me curious ... | 10:44 |
| ogra_ | the stable gadget has still all the old variablle names | 10:44 |
| ogra_ | the test should fail exactly there ... | 10:45 |
| ogra_ | (from http://pastebin.ubuntu.com/25751741/) | 10:45 |
| zyga-ubuntu | github feature idea: mark a PR as "unbreaks master" and stop testing and landing all other PRs | 10:45 |
| zyga-ubuntu | could help us with cases like the one today | 10:45 |
| zyga-ubuntu | do we have any friends there? | 10:46 |
| mvo | ogra_: hm, things should be ok if snap_mode is not definied at all (unless I miss something). when it needs to get set, snapd will set it. in what line in http://pastebin.ubuntu.com/25751741/ should it fail you mean? | 10:47 |
| ogra_ | mvo, sure, the point is that snap__mode doesnt even exist ... which is true for the ancient gadget but not true for all newer ones | 10:47 |
| ogra_ | mvo, in the old gadget only "snappy_mode" is set | 10:48 |
| zyga-ubuntu | the price of renaming | 10:48 |
| ogra_ | mvo, indeed just the missing variable isnt an issue but an indicator that yoou run old and incompatible binary bllobs and uboot | 10:49 |
| zyga-ubuntu | is eternal backwards compatibilty support code | 10:49 |
| mvo | ogra_: aha, yes | 10:49 |
| zyga-ubuntu | (said with the voice of malcom mcdowell) | 10:49 |
| zyga-ubuntu | *malcolm* | 10:49 |
| pstolowski | mvo, ogra_ ah, no, it eventually failed again http://pastebin.ubuntu.com/25752176 | 10:51 |
| mup | PR snapd#4030 closed: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4030> | 10:51 |
| zyga-ubuntu | Read error on /boot/uboot/uboot.env: Success | 10:51 |
| zyga-ubuntu | something is not setting errno | 10:51 |
| mvo | pstolowski: if you hexdump -C /boot/uboot/uboot.env - what happens? | 10:52 |
| ogra_ | mvo, note that this can actuallly be a eal corruption issue due to the ancient uboot vfat version in stable (vs very new kernel in beta and candidate) | 10:53 |
| pstolowski | mvo, I exited the spread test shell, is it still useful if I do that after spread restored the stuff? | 10:53 |
| ogra_ | pstolowski, just call fw_printenv alone | 10:54 |
| zyga-ubuntu | pstolowski: I think so | 10:54 |
| zyga-ubuntu | just ssh into it | 10:54 |
| mvo | pstolowski: I think so too | 10:54 |
| ogra_ | the test proobably swallows output | 10:54 |
| mvo | ogra_: yeah, corruption of the vfat would make a lot of sense. what version of uboot do we have there and in edge? might be worthwhile to do a quick scan of the uboot git log to see if anything related to vfat is there | 10:54 |
| pstolowski | ogra_, mvo, zyga-ubuntu fw_printenv output: http://pastebin.ubuntu.com/25752195/ | 10:55 |
| ogra_ | mvo, some 2015 version iirc, we neve properlly documented it and it isnt built fom source | 10:55 |
| ogra_ | that onlly changed in edge when we switched to actual uboot source builds | 10:55 |
| ogra_ | pstolowski, well, that doesnt look corrupt at all | 10:56 |
| mvo | pstolowski: the first call looks very short | 10:56 |
| ogra_ | mvo, seeing that i take back my vfat theory :P | 10:56 |
| pstolowski | mvo, yeah, ignore it, probably I made a mistake copying | 10:56 |
| ogra_ | there must be some issue how the test uses fw_printenv instead | 10:56 |
| mvo | ogra_: well: "+ fw_printenv | 10:57 |
| mvo | Read error on /boot/uboot/uboot.env: Success" is the error from the test | 10:57 |
| mvo | pstolowski: anything in dmesg? | 10:57 |
| mvo | pstolowski: related to read error or so? | 10:57 |
| pstolowski | mvo, snappy_mode in there? | 10:58 |
| ogra_ | mvo, yes ... but nmanualy it woks | 10:58 |
| ogra_ | pstolowski, yeah, eftover | 10:58 |
| ogra_ | *left | 10:58 |
| mvo | ogra_: yeah, still odd, how could the test use it incorrectly? also no errno set :/ | 10:58 |
| ogra_ | pstolowski, there should also be a snap_mode *if* you ae in any of try/trying ... it gets unset afterwards | 10:58 |
| mup | PR snapd#4048 closed: tests: fix interfaces-cups-control test for cups-2.2.5 <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4048> | 10:59 |
| ogra_ | mvo, well, i dont know, but manually running it obviously works ... perhaps missing env ? or does the test unmont snappy-boot at some point ? | 10:59 |
| mvo | ogra_: I don't think it does | 11:00 |
| pstolowski | mvo, nothing stands out in dmesg.. except for [ 6.989717] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities | 11:00 |
| pstolowski | [ 7.004959] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities | 11:00 |
| mvo | pstolowski: what ogra said, snappy_mode= can be ignored | 11:00 |
| ogra_ | pstolowski, thats /writable ;) and normal noise from the ext4 driver looping over fs capabilities | 11:01 |
| zyga-ubuntu | mvo: could it be (in any way) related to the fact that more recent ubuntu versions use incompatible feature set for ext4 | 11:01 |
| ogra_ | (i whish we could just quieten that) | 11:01 |
| zyga-ubuntu | csum_metadata | 11:01 |
| zyga-ubuntu | chsum_metadata* | 11:01 |
| ogra_ | zyga-ubuntu, wrong path :P we talk about a vfat ;) | 11:01 |
| zyga-ubuntu | ogra_: p2 is vfat? | 11:02 |
| zyga-ubuntu | ogra_: I thought p1 is | 11:02 |
| ogra_ | zyga-ubuntu, system-boot is | 11:02 |
| ogra_ | everywhere | 11:02 |
| ogra_ | mvo, the original test ooutput has "mesg: ttyname failed: Inappropriate ioctl for device" https://paste.ubuntu.com/25728858/ | 11:05 |
| ogra_ | mvo, i wonder if that could inflluence fw_printenv functionality somehow | 11:05 |
| mvo | ogra_: I think thats something from spread actually, but it might be, I am looking at fw_printenv from the uboot git now | 11:06 |
| ogra_ | mvo, better look at the one fgrom the deb source | 11:06 |
| ogra_ | thats what we use | 11:06 |
| ogra_ | (and it might be far behind git) | 11:06 |
| mvo | ogra_: the xenial one? | 11:06 |
| ogra_ | yep | 11:06 |
| ogra_ | 2016.01+dfsg1-2ubuntu3 ... nearly 2y old | 11:08 |
| zyga-ubuntu | how can 2016 be nearly two years old? | 11:08 |
| zyga-ubuntu | well, | 11:08 |
| zyga-ubuntu | nearly ok | 11:08 |
| ogra_ | january 2016 ... | 11:08 |
| ogra_ | (i could have said 22 months if you'd prefer that :P ) | 11:09 |
| pstolowski | my tests also had a couple of 'mesg: ttyname failed: Inappropriate ioctl for device' errors | 11:10 |
| ogra_ | yeah | 11:10 |
| ogra_ | must not be the issue but it might indicate that you tty is somewhat different to the one you have when running fw_printenv manually | 11:10 |
| ogra_ | something is surelly with the env | 11:11 |
| mvo | pstolowski, ogra_ http://git.denx.de/?p=u-boot.git;a=blob;f=tools/env/fw_env.c;h=ab06415898c2f718e8a926879379b1f8d74ca55d;hb=HEAD#l760 is the only place where this error is produced (looks the same in the 2016 version) | 11:16 |
| zyga-ubuntu | too bad it doesn't display rc | 11:16 |
| mvo | pstolowski: I would argue the code in there is incorrect | 11:17 |
| zyga-ubuntu | it may be just a partial read | 11:17 |
| mvo | zyga-ubuntu: yeah, exactly | 11:17 |
| zyga-ubuntu | (truncated environment?) | 11:17 |
| mvo | zyga-ubuntu: you mean something else truncated the uboot.env? | 11:17 |
| zyga-ubuntu | mvo: last week we learned how error messages suck | 11:17 |
| zyga-ubuntu | mvo: well, not sure if really truncated | 11:17 |
| zyga-ubuntu | mvo: I didn't read the rest of the code | 11:17 |
| zyga-ubuntu | mvo: I meant that if you have a fixed buffer | 11:17 |
| zyga-ubuntu | mvo: and then read until EOF | 11:17 |
| ogra_ | well, uboot.env isnt truncated if you manually run fw_printenv | 11:17 |
| zyga-ubuntu | mvo: then eventually you will get a partially complete buffer | 11:18 |
| mvo | zyga-ubuntu: there might be a signal | 11:18 |
| zyga-ubuntu | mvo: unless there's some assumption about the alignment of the file | 11:18 |
| zyga-ubuntu | mvo: "alignment" in blocks | 11:18 |
| mvo | zyga-ubuntu: but yeah, I think the code in there is slightly naive | 11:18 |
| zyga-ubuntu | mvo: might be but we don't know | 11:18 |
| mvo | zyga-ubuntu: yeah, sadly it does not print rc which is the crucial bit | 11:18 |
| mvo | s/is/would be/ :/ | 11:18 |
| zyga-ubuntu | mvo: maybe we just need to patch snapd to always write the environment in multiples of some block size | 11:18 |
| ogra_ | mvo, zyga-ubuntu, but why does it work manually then ? | 11:18 |
| zyga-ubuntu | mvo: and fill the rest with zeros | 11:18 |
| zyga-ubuntu | ogra_: I don't suppose it is corrected by that process somewhere | 11:19 |
| zyga-ubuntu | ogra_: maybe it fails, then gets fixed, and then is correct | 11:19 |
| zyga-ubuntu | ogra_: we don't have snapshots of the file during the process to say | 11:19 |
| ogra_ | well, you could stop the test before it calls fw_pintenv the first time i suppose | 11:19 |
| ogra_ | and then manually run the command to see | 11:20 |
| mvo | pstolowski: could you please rerun the test just to see if it fails in a similar way again? plus please update the forum post so that all the "evidence" is in a single place | 11:21 |
| zyga-ubuntu | ogra_: it doesn't fail for me, I cannot reflash beta sadly (AFK) | 11:21 |
| mvo | zyga-ubuntu: I still suspect a signal that might cause the short read, but what signal could it be? usually it would be something like SIGWINCH but that is probably not it on a spread run and no other signal springs to my mind | 11:22 |
| zyga-ubuntu | phone | 11:23 |
| * mvo lunch | 11:23 | |
| zyga-ubuntu | re | 11:25 |
| zyga-ubuntu | mvo: so I was thinking that it could be a signal _but_ I'm somewhat skeptical; let me check something | 11:26 |
| zyga-ubuntu | SIGWINCH 28,28,20 Ign Window resize signal (4.3BSD, Sun) | 11:27 |
| zyga-ubuntu | SIGWINCH is ignored by default | 11:27 |
| ogra_ | i guess we dont call out to fw_setenv when writing thhe file but use our own write finction ? | 11:27 |
| ogra_ | *function | 11:27 |
| ogra_ | (from snapd that is) | 11:28 |
| zyga-ubuntu | Interruption of system calls and library functions by signal handlers | 11:28 |
| zyga-ubuntu | If a signal handler is invoked while a system call or library | 11:28 |
| zyga-ubuntu | function call is blocked, then either: | 11:28 |
| zyga-ubuntu | * the call is automatically restarted after the signal handler | 11:28 |
| zyga-ubuntu | returns; or | 11:28 |
| zyga-ubuntu | * the call fails with the error EINTR. | 11:28 |
| zyga-ubuntu | ogra_: I think so | 11:28 |
| zyga-ubuntu | If a blocked call to one of the following interfaces is interrupted | 11:29 |
| zyga-ubuntu | by a signal handler, then the call will be automatically restarted | 11:29 |
| zyga-ubuntu | after the signal handler returns if the SA_RESTART flag was used; | 11:29 |
| zyga-ubuntu | otherwise the call will fail with the error EINTR: | 11:29 |
| zyga-ubuntu | * read(2), readv(2), write(2), writev(2), and ioctl(2) calls on | 11:29 |
| zyga-ubuntu | "slow" devices. A "slow" device is one where the I/O call may | 11:29 |
| zyga-ubuntu | block for an indefinite time, for example, a terminal, pipe, or | 11:29 |
| zyga-ubuntu | socket. If an I/O call on a slow device has already transferred | 11:29 |
| zyga-ubuntu | some data by the time it is interrupted by a signal handler, then | 11:29 |
| zyga-ubuntu | the call will return a success status (normally, the number of | 11:29 |
| zyga-ubuntu | bytes transferred). Note that a (local) disk is not a slow device | 11:29 |
| zyga-ubuntu | according to this definition; I/O operations on disk devices are | 11:29 |
| zyga-ubuntu | not interrupted by signals. | 11:29 |
| zyga-ubuntu | so I think the C code for uboot env handling may not be setting SA_RESTART in any place | 11:32 |
| * zyga-ubuntu looks | 11:32 | |
| pstolowski | mvo, will do | 11:34 |
| zyga-ubuntu | mvo: still no idea which signal it might be :/ | 11:39 |
| zyga-ubuntu | ideally we'd rebuild that old uboot | 11:39 |
| zyga-ubuntu | and set a breakpoint and see | 11:39 |
| zyga-ubuntu | but ... | 11:39 |
| zyga-ubuntu | well | 11:39 |
| zyga-ubuntu | maybe we can? | 11:39 |
| zyga-ubuntu | pstolowski: can you reproduce this? | 11:39 |
| zyga-ubuntu | pstolowski: or does it happen only once? | 11:39 |
| zyga-ubuntu | pstolowski: ideally we'd have a copy of the binary that has this problem and the file that causes it | 11:40 |
| zyga-ubuntu | pstolowski: and then see what gdb tells us | 11:40 |
| ogra_ | it prints the build date as very first line duing boot on serial | 11:40 |
| zyga-ubuntu | ogra_: any chance we can grab debug symbols for that build somewhere/ | 11:41 |
| ogra_ | nly via re-building ... i thinbk it gets stripped by default (it is a bootloade optimized for size after all) | 11:41 |
| zyga-ubuntu | ogra_: any -dbg package equivalent? | 11:42 |
| ogra_ | noot reallly | 11:42 |
| ogra_ | with the new setup it would be easy since we now build from upsteam tags ... stable was random local builds originally ... we need the string it prints, with lluck that had the commit in the version | 11:43 |
| ogra_ | *has | 11:44 |
| zyga-ubuntu | aha | 11:44 |
| zyga-ubuntu | well, that depends on if pstolowski can reproduce this :) | 11:44 |
| zyga-ubuntu | ogra_: could you provide a build for pawel to try | 11:44 |
| zyga-ubuntu | ogra_: just that command with debug symbols with ~~ similar version (as close as you can get it) | 11:44 |
| ogra_ | https://www.denx.de/wiki/DULG/DebuggingUBoot | 11:45 |
| ogra_ | seems it is actually not stripped (nothing theer says you need a debug build) | 11:46 |
| zyga-ubuntu | pstolowski: can you run gdb and see if that build has symbols? | 11:47 |
| ogra_ | https://www.denx.de/wiki/view/DULG/Debugging is a bit more informative and llinks to tips and tricks | 11:47 |
| * zyga-ubuntu breaks, I'll probably miss standup but I may show up if lucky | 11:51 | |
| pstolowski | just re-flashed to retest | 11:58 |
| zyga-ubuntu | re | 12:16 |
| zyga-ubuntu | Pharaoh_Atem: hey, can you remind me that repo sync issue in fedora/linode | 12:21 |
| zyga-ubuntu | Pharaoh_Atem: linode operators are in #linode but on OFTC, not freenode | 12:21 |
| zyga-ubuntu | Pharaoh_Atem: if you can give me those details again I'll collect everything and open a ticket | 12:22 |
| mvo | zyga-ubuntu, pstolowski just finished reading backlog. lets see if it is reproducible and then we attack it | 12:26 |
| pstolowski | mvo, ... and i'm having issues now on 1st boot after flashing. it's taking forever on 'random: nonblocking pool is initialized' | 12:27 |
| pstolowski | not sure if this is entropy issue or what. console-conf doesn't show up | 12:28 |
| ogra_ | no, thats a red herring | 12:28 |
| ogra_ | it is simply the last thing the kernel prints before switching consoles | 12:28 |
| mvo | pstolowski: hm, is the network cable attached? | 12:28 |
| pstolowski | mvo, no | 12:28 |
| ogra_ | that might then take 2min for the timeout | 12:29 |
| pstolowski | ogra_, i've been waiting much much longer already | 12:29 |
| ogra_ | hmm | 12:29 |
| ogra_ | mvo, i was actually wobndering if we should rip out the hardcoded DHCP default for eth0 that we add during build | 12:30 |
| ogra_ | at least for physical images (probably cloud still needs it) | 12:30 |
| zyga-ubuntu | mvo: I'll be away from home for at least three hours, after that I can spend any time debugging and exploring this with hands on | 12:31 |
| zyga-ubuntu | mvo: I'll try to focus on coding but I can help pstolowski with gdb | 12:31 |
| mvo | zyga-ubuntu: thanks, I think we are good for now, if pstolowski can reproduce that is good enough for now | 12:32 |
| pstolowski | ok, i reflashed and this time it didn't hang on boot. weird. | 12:48 |
| zyga-ubuntu | pstolowski: does the uboot env CLI tool fail the same way? | 12:54 |
| * zyga-ubuntu logs into ubuntu session, brb | 12:54 | |
| pstolowski | zyga-ubuntu, not yet, the test is running | 12:56 |
| zyga-ubuntu | aha | 12:56 |
| * zyga-ubuntu joins the standup | 12:56 | |
| mup | PR snapcraft#1615 closed: schema: improve invalid app, hook, and part errors <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1615> | 13:14 |
| jamespage | sergiusens: hi - raised https://bugs.launchpad.net/snapcraft/+bug/1723945 based on the conversation we had last week | 13:16 |
| mup | Bug #1723945: provide support for use of DEB_HOST_MULTIARCH in environment variables <Snapcraft:New> <https://launchpad.net/bugs/1723945> | 13:16 |
| jamespage | does that sounds about right? | 13:16 |
| mup | Issue snapcraft#1445 closed: ROS user oriented story <docs> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1445> | 13:29 |
| mup | Issue snapcraft#1446 closed: MOOS user oriented story <docs> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1446> | 13:29 |
| mup | PR snapcraft#1577 closed: lxd: don't inject local snaps on a different arch <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1577> | 13:29 |
| mup | PR snapcraft#1610 closed: tests: reenable the cleanbuild integration test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1610> | 13:32 |
| mup | PR snapcraft#1609 closed: tests: remove the duplicate nodejs integration tests <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1609> | 13:35 |
| sergiusens | jamespage yeah, that should cover it | 13:44 |
| jamespage | sergiusens: also what would you think of https://bugs.launchpad.net/snapcraft/+bug/1723957 | 13:45 |
| mup | Bug #1723957: cleanbuild: add PPA sources <Snapcraft:New> <https://launchpad.net/bugs/1723957> | 13:45 |
| jamespage | I'm using cleanbuild to produce test binaries; currently hacking in my ppa sources using cloud-init in lxd user.user-data config | 13:45 |
| diddledan | I don't understand this behaviour at all: https://forum.snapcraft.io/t/cleanbuild-remote-on-pi-grabs-wrong-arch-lxc-image/691/17 | 13:51 |
| diddledan | cleanbuild should not be forcing the version of snapd to anything EXCEPT "the latest" stable, unless the user specifically tells snapcraft otherwise | 13:52 |
| diddledan | and doing the forcing by injecting host-side snaps is just plain wrong | 13:53 |
| diddledan | IMO | 13:53 |
| diddledan | and no, that opinion is not humble in any way :-p | 13:53 |
| mvo | pstolowski: how is that test going? the second run of the core-refresh testing? | 13:55 |
| kalikiana | diddledan: snapd? do you mean the core snap? snapcraft attempts to install the same version in the container that's being used on the host | 13:56 |
| pstolowski | mvo, well.. | 13:57 |
| diddledan | yeah, core | 13:57 |
| pstolowski | mvo, http://pastebin.ubuntu.com/25753195/ | 13:57 |
| kalikiana | diddledan: so if eg. you're using beta on the host to test something, the container will be using that, same goes for snapcraft itself | 13:57 |
| pstolowski | mvo, last failure unrelated, probably wifi dropped or something | 13:58 |
| diddledan | I think it's wrong to be injecting at all, foreign arch or not. Core should be updated using snap processes not by injecting random snaps. We should not be designing weird behaviour for the edge case of "I want to test something" by default | 13:58 |
| diddledan | an "I want to test something" should be an opt-in not a default | 13:59 |
| mvo | pstolowski: do you have a monitor attached, i.e. can you actually see what is on screen when its in this "2017-10-16 15:41:20 Error debugging external:ubuntu-core-16-arm-32:tests/main/ubuntu-core-upgrade : EOF" state? | 13:59 |
| diddledan | the whole point of cleanbuild is that the build is in a clean environment. The moment you start injecting stuff to match the host it is no-longer "clean" | 14:01 |
| kalikiana | diddledan: I wouldn't agree it's "random". If you're using snapcraft natively without a container, it uses whatever core you are running. The experience should as much as possible be the same | 14:01 |
| kalikiana | You should of course be testing that your snap works with stable before you release it, in both cases | 14:03 |
| pstolowski | mvo, no, no monitor (but i've usb-serial). but hmm.. i cannot access this pi3 via wifi anymore | 14:03 |
| diddledan | maybe if you think we should be doing this, the name "cleanbuild" is wrong. So let's rename it to "meh, frankenstein, YMMV" | 14:03 |
| pstolowski | mvo, if serial console doesn't lie, then the last thing that happened was systemd[1]: Started Journal Service | 14:03 |
| mvo | pstolowski: hm, that looks harmless | 14:04 |
| mvo | pstolowski: I wonder why it stops responding | 14:04 |
| mvo | pstolowski: fwiw, cachio saw some of these errors too (EOF) but we never got to the bottom of it, might actually be multiple causes just showing the same error | 14:04 |
| pstolowski | mvo, wifi seems dead, no led blinking | 14:04 |
| diddledan | and let's change the documentation to say "this is not a clean environment. any attempt to get a system as close to build service is never going to work. We made it this way on purpose because we hate consistency" | 14:05 |
| kalikiana | diddledan: Can we take a step back and you tell me what your expectation of cleanbuild is? If this is your impression that's certainly not what anyone wants :-) | 14:07 |
| pstolowski | mvo, I just powered it again; on normal boot that Systemd Journal Service message is followed by brcmf initialization, which apparently didn't happen | 14:10 |
| diddledan | my expectation is that cleanbuild builds in a clean environment. Is it wrong to assume that when the documentation says "cleanbuild Create a snap using a clean environment..." that it will build using a clean environment? | 14:10 |
| mvo | pstolowski: hm, do you think you could put it on a cable connection? to make tests more reliable? | 14:11 |
| pstolowski | mvo, yeah, that might be a good idea | 14:12 |
| diddledan | also, when the documentation says "Create a snap using a pristine environment managed by lxd" I expect the environment to be unaltered | 14:13 |
| diddledan | I certainly do NOT expect for implementation in my host to "leak" through into the LXD container | 14:14 |
| kalikiana | diddledan: So even if you're doing, say, `snap install core --edge`, you wouldn't want the container to use the same channel? | 14:16 |
| diddledan | no | 14:16 |
| kalikiana | diddledan: Would you apply the same reasoning to persistent containers? | 14:16 |
| diddledan | if I did that then I would want a switch to tell snapcraft to change to using a different channel | 14:17 |
| diddledan | yes, I would | 14:17 |
| kalikiana | diddledan: One thing we could look into is a prompt like `You're using the "core" snap from the "edge" channel. Do you want to use the same in the container?` | 14:18 |
| diddledan | most people building snaps are NOT going to want to change the core snap to test things because they're not developing the core snap nor snapd nor snapcraft | 14:18 |
| diddledan | if they really need to test their snap builds against a different core then they will know that they want a specific core and should then be tasked with telling snapcraft that specifically | 14:19 |
| kalikiana | diddledan: Right. We have slightly different perspectives here. To my mind, the same core snap increases predictability. But I see the point you're making | 14:21 |
| kalikiana | diddledan: Would you mind opening a new forum topic for it? | 14:24 |
| diddledan | the problem that you wrote the PR in the link above with core being injected to foreign arch snaps is a symptom, not the cause. the cause is that we're assuming the user wants to match their host with their build. Now your PR says "match the host EXCEPT on remote builds." where are these exceptions going to end? why not just allow the user to specify the core they want to use rather than guessing | 14:24 |
| kalikiana | diddledan: The PR applies to both the core and snapcraft. We have to do this anyway to be able to get the correct snapcraft version. | 14:25 |
| kalikiana | If we decide to not push the core snap out of the box, that's a separate decision | 14:25 |
| kalikiana | Or maybe add a way to choose the channel explicitly etc. | 14:26 |
| kalikiana | diddledan: To be clear, we have to push snapcraft because it's calling itself. | 14:28 |
| === ikey|zzz is now known as ikey | ||
| diddledan | kalikiana: https://forum.snapcraft.io/t/dont-match-the-core-snap-to-the-host-in-cleanbuild-environments/2486 | 14:41 |
| kalikiana | diddledan: Thanks! | 14:42 |
| kalikiana | Will reply in a bit | 14:42 |
| diddledan | np | 14:42 |
| sergiusens | kalikiana just ensure it always comes from the stable channel | 14:43 |
| kalikiana | sergiusens: Yeah, that we can do. To be clear, though, we still want snapcraft itself to be injected from the host or same channel, right? | 14:47 |
| mup | Bug #1723974 opened: snap client doesn't work with Croatian language/characters <Snappy:New> <https://launchpad.net/bugs/1723974> | 14:48 |
| diddledan | kalikiana: I must apologise if I may have seemed aggressive above, I was just frustrated at my inability to articulate why I felt cleanbuild was behaving wonky | 14:50 |
| diddledan | group hug! | 14:50 |
| diddledan | :-p | 14:51 |
| * kalikiana hugs diddledan | 14:51 | |
| diddledan | yey | 14:51 |
| diddledan | for anyone who doesn't like hugs, as punishment I shall not hug you! :-D | 14:51 |
| sergiusens | kalikiana for persistent containers, most likely yes, for cleanbuild, only if it is in stable | 14:52 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| kalikiana | Good point. Will think about how we can do that | 14:56 |
| pstolowski | mvo, 5 runs of pi3 ubuntu-core-upgrade test passed when on ethernet | 15:20 |
| ogra_ | heh | 15:21 |
| ogra_ | yay ? | 15:21 |
| mvo | pstolowski: interessting. so lets compare notes with cachio when he is back tomorrow and see what the differences are | 15:23 |
| mvo | pstolowski: thanks a lot for your test! | 15:23 |
| ogra_ | this is starting to get curious ... | 15:23 |
| mvo | pstolowski: that gives me some peace of mind. this was an image produced with all bits from beta, right? | 15:23 |
| mvo | ogra_: to me it already was last week :) but yeah, it is very inconclusive | 15:24 |
| ogra_ | did you bump the gadget in beta ? | 15:24 |
| ogra_ | we should really do that | 15:24 |
| pstolowski | mvo, sudo ubuntu-image -c beta -O pi3-beta.img pi3.model, that's how I created it | 15:24 |
| mvo | pstolowski: great | 15:25 |
| mvo | pstolowski: lets see what sergio did - maybe it makes a difference if it was created without sudo or something else, also the revision of ubuntu-image. I'm sure we can now track it down better | 15:27 |
| pstolowski | ogra_, ethernet may have nothing to do here, it was just a re-test for yet another failure I pasted above where on the last run I lost access to my pi3 over wifi | 15:27 |
| mvo | ogra_: I did not touch the gadget | 15:27 |
| mvo | ogra_: I would like to wait until we solved this mystery, lets cange as little as possible | 15:27 |
| ogra_ | mvo, well, then it is interesting that this kernel boots at all, since the dtb will be incomplete | 15:27 |
| ogra_ | (i assume half the devices you have with the edge gadget wont simply be there or only half working) | 15:28 |
| mvo | ogra_: yeah, I think that is an interessting datapoint as well, the old dtb seems to be fine with most new kernels | 15:28 |
| ogra_ | well | 15:28 |
| ogra_ | the unstable wifi behavoiur might already be an indicator here | 15:29 |
| ogra_ | (we only added the fully fixed wifi stuff after stable got released) | 15:29 |
| ogra_ | it is like a lottery :) | 15:29 |
| mvo | ogra_: yeah, not saying its great, but interessting how uch apparently worked | 15:29 |
| ogra_ | yeah | 15:30 |
| mvo | ogra_: yeah, maybe that is the answer, sergio just draw the short straw | 15:30 |
| ogra_ | yep | 15:30 |
| mup | PR snapd#4049 opened: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049> | 15:32 |
| kyrofa | sergiusens, kalikiana, elopio: someone _banned_ me. Who hates me today? | 15:34 |
| kyrofa | I can't rejoin :P | 15:34 |
| ogra_ | have you been rude ? | 15:34 |
| ogra_ | :) | 15:34 |
| elopio | kyrofa: sorry | 15:34 |
| kyrofa | ogra_, sometimes it slips | 15:34 |
| ogra_ | haha | 15:34 |
| kyrofa | elopio, hahaha, was it you? Fess up | 15:35 |
| Chipaca | nice, we have a bug in the croatian translation that causes snap to panic | 15:48 |
| Chipaca | that's #1723974 | 15:48 |
| mup | Bug #1723974: snap client doesn't work with Croatian language/characters <Snappy:Confirmed> <https://launchpad.net/bugs/1723974> | 15:48 |
| Chipaca | also: “Pokušajte "snap install hello-world".” | 15:55 |
| ogra_ | i guess re-exec should better use C.UTF-8 ;) | 15:56 |
| zyga-ubuntu | re | 15:59 |
| === ShalokShalom_ is now known as ShalokShalom | ||
| Chipaca | mvo: do you know who I need to pester to fix a buggy translation? | 16:20 |
| sergiusens | elopio can we make that timing thing the default on tests or is that something you did manually? | 16:26 |
| kalikiana | this was a looong meeting :-D I need food now to re-ful | 16:27 |
| elopio | sergiusens: I added a timer in setup and teardown. It makes things verbose, and only the outliers are useful. As a second step after fixing the outliers, I was thinking to add a max time, and fail the tests that cross that line. | 16:31 |
| elopio | but if you want, I can get it printed in travis. | 16:31 |
| elopio | kyrofa: the ros unit tests should not connect to the server, right? https://launchpadlibrarian.net/341066726/buildlog_ubuntu-artful-amd64.snapcraft_2.34-201710161334-d0be68b~ubuntu17.10.1_BUILDING.txt.gz | 16:36 |
| kyrofa | elopio, huh, looks like it is | 16:38 |
| * kyrofa looks | 16:38 | |
| kyrofa | elopio, indeed, it seems that it is | 16:45 |
| kyrofa | But it shouldn't be... | 16:45 |
| kyrofa | Oh oh, wrong test | 16:46 |
| kyrofa | elopio, fixing now | 16:47 |
| mup | PR snapd#4050 opened: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4050> | 16:47 |
| mark__ | Hey guys, could you help me out making a snap? https://askubuntu.com/questions/965455/how-do-i-create-an-opengles2-and-glfw3-snap | 16:49 |
| mup | PR snapcraft#1614 closed: apt repo: allow insecure repos <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1614> | 16:50 |
| Chipaca | mark__: hello | 16:55 |
| mark__ | hi | 16:55 |
| Chipaca | mark__: I think the most effective way forward for you will be to ask in the forum | 16:56 |
| mark__ | I did | 16:56 |
| Chipaca | mark__: ah! ok then you're set :-) | 16:57 |
| mark__ | Thanks. | 16:57 |
| kyrofa | elopio, fixed | 17:03 |
| elopio | thank you! | 17:05 |
| Chipaca | mark__: about your other issue though | 17:06 |
| Chipaca | mark__: what distro are you on? | 17:07 |
| mark__ | lubuntu | 17:07 |
| sergiusens | elopio I am not so confident about killing tests that take too long. It is an extra burden and in practice doesn't work really well (considering that we already get our runners killed for long running test executions anyways) | 17:07 |
| Chipaca | mark__: what's the output of `which stopwatch`? | 17:08 |
| Chipaca | mark__: which -a stopwatch, even | 17:08 |
| mark__ | of both commands | 17:09 |
| mark__ | the output is "/snap/bin/stopwatch" | 17:09 |
| Chipaca | mark__: and if you run stopwatch, it complains about /usr/local/bin/stopwatch? | 17:10 |
| mark__ | Actually it's fixed now. I don't know, maybe because after the question I make a new snap and installed/removed it multiple times. | 17:10 |
| Chipaca | mark__: did you used to have it in /usr/local ? | 17:11 |
| mark__ | So now" snap run stopwatch" and "stopwatch" produce the same results | 17:11 |
| * Chipaca mangles the english language for fun & profit | 17:11 | |
| Chipaca | mark__: that error looks like at some point you had a /usr/local/bin/stopwatch, and bash cached it | 17:11 |
| mark__ | yeah, I had it installed manually before | 17:12 |
| mark__ | using custom install.sh and uninstall.sh scripts | 17:12 |
| Chipaca | mark__: for what it's worth, when that happens, bash has a builtini "hash" that lets you tweak that cache | 17:12 |
| Chipaca | hash -r, if memory serves, updated the entries in it | 17:12 |
| Chipaca | or maybe it reset it | 17:12 |
| Chipaca | one of those :-) | 17:12 |
| mark__ | oh, so that's solved then... | 17:12 |
| mark__ | thanks | 17:12 |
| Chipaca | no problem | 17:12 |
| Chipaca | glad it was that :-) | 17:12 |
| mark__ | I still can't load the graphics drivers though :( | 17:13 |
| Chipaca | mark__: yep, that's something else (and you'll need a snapcrafter for it i reckon) | 17:14 |
| elopio | kyrofa: wait, that test hasn't landed in master? | 17:14 |
| Chipaca | mark__: have you looked at one of the sample snaps that use opengl? | 17:15 |
| Chipaca | mark__: (no idea, just trying to help) | 17:15 |
| kyrofa | elopio, ah, yes indeed it has | 17:15 |
| kyrofa | elopio, I can propose a quick PR to fix it rather than putting it in the ament PR if you like | 17:15 |
| kyrofa | It's two lines | 17:15 |
| kyrofa | I suppose autopkgtest is barfing on it huh | 17:16 |
| elopio | kyrofa: is the PPA recipe. I'd appreciate if you make the PR, so I can move on with the PPA. | 17:17 |
| kyrofa | elopio, easy peasy. Two seconds | 17:17 |
| mup | PR snapcraft#1619 opened: tests: don't hit internet in ros2 units <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1619> | 17:20 |
| kyrofa | elopio, there you are ^^ | 17:20 |
| * sergiusens commutes to a location with something to eat lunch | 17:28 | |
| * zyga-ubuntu rests after a long day | 17:28 | |
| mup | PR snapcraft#1620 opened: plugins: build-attributes is already in the state <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1620> | 17:53 |
| diddledan | popey: can you review https://github.com/snapcrafters/corebird/pull/13 for me please? :-) | 18:07 |
| mup | PR snapcrafters/corebird#13: add wayland support for artful (17.10) <Created by diddledan> <https://github.com/snapcrafters/corebird/pull/13> | 18:07 |
| mup | PR snapcraft#1621 opened: integration tests: skip catkin test on non-xenial <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1621> | 18:08 |
| kyrofa | elopio, take a look at that ^^ one when you get a sec as well | 18:09 |
| kyrofa | Hey elopio, I have another thought for our tests. What if we had a Docker container pre-configured with all our dependencies. That would save a lot of setup time, wouldn't it? | 18:28 |
| kyrofa | I mean, the static tests that take a few seconds on my machine take over 5 minutes in travis | 18:28 |
| gouchi | hi | 19:41 |
| gouchi | I was wondering why we have to connect manually some interfaces with snap connect xxxx:home for example ? | 19:41 |
| gouchi | why it is not done automatically ? | 19:42 |
| kalikiana | gouchi: some interfaces don't autoconnect for security reasons. Have a look at this wiki https://github.com/snapcore/snapd/wiki/Interfaces | 19:52 |
| gouchi | kalikiana: thank you | 19:53 |
| === Pharaoh_Atem is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Pharaoh_Atem | ||
| mup | PR snapcraft#1620 closed: plugins: build-attributes is already in the state <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1620> | 20:27 |
| Arthur_D | hi, noob question: how does Snapcraft interact with Github - if I give it access to my Github account, will it edit anything regarding the repo or Github presentation? For example create some sort of link to the Snap on the Snapcraft website | 21:21 |
| sergiusens | Arthur_D it shouldn't, the scope is a bit broad, but it is I think the no brainer one that allows webhooks | 21:38 |
| sergiusens | instructions on manually hooking it all up are being worked on to avoid this scenario, it would however require more manual interaction and setup | 21:39 |
| Arthur_D | the reason I ask is because I contribute a bit to a project but don't want to create some sort of official or official looking snap, mainly wanted to test | 21:42 |
| mup | PR snapcraft#1619 closed: tests: don't hit internet in ros2 units <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1619> | 21:57 |
| mup | PR snapcraft#1621 closed: integration tests: skip catkin test on non-xenial <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1621> | 21:57 |
| mup | PR snapcraft#1622 opened: schema: sync patterns with snapd <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1622> | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!