| mup | PR snapcraft#2310 opened: nodejs plugin: add support for ppc64el and s390x <Created by anthonyfok> <https://github.com/snapcore/snapcraft/pull/2310> | 00:50 |
|---|---|---|
| luk3yx | When will build.snapcraft.io use 18.04 to build snaps? | 01:03 |
| ilias_gr | hi all. does anyone maybe know why using skype for ubuntu the systray icon doesn't change when user switch between different system's icon packs? | 04:27 |
| mborzecki | morning | 05:06 |
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 06:28 |
| * zyga spent way too many hours debugging a simple type error : / | 06:30 | |
| mup | PR snapd#5895 closed: client, daemon: support passing of 'unaliased' option when installing from local files <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5895> | 06:31 |
| zyga | error: received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/pYVQrBcKmBa0mZ4CCN7ExT6jH8rY1hza_158.snap?token=1538474400_751f689ba95d256c948c3192959fb3e166ab9c82 | 06:38 |
| zyga | + find '/home/gopath/src/github.com/snapcore/snapd/tests/snapd-state/snapd-lib/*' -maxdepth 0 '!' '(' -name snaps -o -name seed ')' -exec cp -rf '{}' /var/lib/snapd ';' | 06:38 |
| zyga | find: ‘/home/gopath/src/github.com/snapcore/snapd/tests/snapd-state/snapd-lib/*’: No such file or directory | 06:38 |
| mborzecki | well, at least the tests failed right? | 06:46 |
| zyga | integration tests failed, I incorrectly handled one unit test that would work ok because it was mocked | 06:47 |
| zyga | error types | 06:47 |
| zyga | anyway, sorted out now | 06:47 |
| zyga | just realised it way too late last nighrt | 06:47 |
| zyga | *night | 06:47 |
| mup | PR snapd#5875 closed: interfaces/builtin: avahi interface update <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5875> | 06:53 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:05 |
| === chihchun is now known as chihchun_afk | ||
| zyga | hmm hmm | 07:21 |
| * zyga digs deeper into issues | 07:21 | |
| === chihchun_afk is now known as chihchun | ||
| zyga | there's something wrong with layouts on core18 | 07:38 |
| mup | PR snapd#5874 closed: interfaces/builtin: adding missing permission to create /run/wpa_supplicant directory <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5874> | 07:39 |
| zyga | I have a hunch I know what is going on but I wasn't expecting this problem yet | 07:40 |
| mvo | zyga: tell me more please | 07:45 |
| zyga | well, it's related to trespassing and when we consider it is safe to write to a directory | 07:45 |
| zyga | I started with a conservative decision to only allow writes to a directory when said directory is the mount point of a tmpfs we can trace to snapd | 07:45 |
| zyga | one of the tests exercises a sub-sub directory | 07:46 |
| zyga | and snap-update-ns doesn't consider that a guaranteed tmpfs | 07:46 |
| zyga | this happened because the apparmor generalisation landed | 07:46 |
| zyga | and a test switched from /bin/some-very-weird-place to /bin/some/very/weird/place to show that the apparmor part of it works | 07:47 |
| zyga | I knew about it but didn't realise it would come into reality as a test problem this way (via merging of the other branch) | 07:47 |
| zyga | the question is how to safely extend the logic to allow sub-directories of a tmpfs that is still a tmpfs and not hidden by some other mount operation | 07:48 |
| Chipaca | moin | 07:48 |
| Chipaca | mvo: mborzecki: Asplode() -> AsMaps()? | 07:49 |
| zyga | so if /bin is a tmpfs then /bin/very is also a tmpfs unless it's explicitly mounted as something else | 07:49 |
| zyga | it's just tricky code because we cannot identify a filesystem instance easily AFAIK | 07:49 |
| * zyga checks | 07:49 | |
| zyga | maybe I'm wrong actually | 07:49 |
| mborzecki | Chipaca: sounds good | 07:49 |
| mborzecki | Chipaca: your #5879 made me dig into go-flags and read what the flag does :) | 07:50 |
| mup | PR #5879: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879> | 07:50 |
| Chipaca | mborzecki: I'm so sorry | 07:50 |
| Chipaca | :) | 07:51 |
| Chipaca | mborzecki: --posixly-correct | 07:51 |
| Chipaca | ¯\_(ツ)_/¯ | 07:51 |
| mborzecki | Chipaca: don't be, it was nice | 07:51 |
| Chipaca | heh, that looks like I'm holding mborzecki up on a platter | 07:52 |
| Chipaca | maybe I'm about to throw it into a pool or sth | 07:52 |
| Chipaca | zyga: is your pi3 connected and on in The Lab? | 08:10 |
| zyga | nope, it's a bit offline actually | 08:11 |
| zyga | I need to reformat all of the things and put them in proper network | 08:11 |
| zyga | if urgent I can bring one online | 08:11 |
| Chipaca | not urgent | 08:11 |
| zyga | I have pi2-2 in my hands | 08:12 |
| zyga | I think it's still running core | 08:12 |
| Chipaca | I was just wondering how long 'snap' took to run on a pi these days | 08:12 |
| zyga | hold on | 08:12 |
| Chipaca | (that is: 'time snap > /dev/null' | 08:12 |
| Chipaca | ) | 08:12 |
| Chipaca | things that are fun: find -type f -name \*.go \! -name \*_test.go -print0 | xargs -0 perl -pi -we 's/(^func init\(.*)/$1\nprintln("$ARGV")/' | 08:16 |
| Chipaca | yaml wins | 08:16 |
| zyga | no pikcza | 08:17 |
| zyga | (no picture) | 08:17 |
| zyga | it doesn't boot | 08:17 |
| zyga | I think the SD cards degrade pretty rapidly :/ | 08:18 |
| zyga | I'll re-flash it | 08:18 |
| * zyga tries to recall where to get pi2 images | 08:20 | |
| zyga | or the magic incantation to make one... | 08:20 |
| mvo | zyga: no worries I should have a working pi3 | 08:20 |
| zyga | I may as well flash it | 08:21 |
| mvo | Chipaca: https://paste.ubuntu.com/p/JfZ5NtpJJX/ | 08:22 |
| mvo | zyga: try http://cdimage.ubuntu.com/ubuntu-core/16/stable/ | 08:22 |
| Chipaca | mvo: and redirecting to /dev/null? | 08:22 |
| mvo | zyga: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ | 08:22 |
| Chipaca | mvo: (thanks!) | 08:22 |
| mvo | Chipaca: pretty much the same | 08:22 |
| mvo | Chipaca: https://paste.ubuntu.com/p/HTwkZzTGGf/ | 08:23 |
| Chipaca | mvo: lovely | 08:23 |
| Chipaca | I can stop worrying about this for another year \o/ | 08:23 |
| zyga | thanks moo! | 08:23 |
| zyga | mvo: | 08:23 |
| zyga | (silly tab completion) | 08:23 |
| zyga | but somehow aptpropritate | 08:23 |
| mvo | haha | 08:24 |
| mup | PR snapd#5890 closed: overlord/snapshotstate: small refactor of internal helpers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5890> | 08:31 |
| Chipaca | BRB, new kernel | 08:41 |
| === kjackal_v2 is now known as kjackal | ||
| * zyga tests a tweak that should get out out of the problem | 09:17 | |
| * zyga forgot to flash pi2, flashing now | 09:20 | |
| mup | PR snapd#5896 opened: snapcraft.yaml: set grade to stable and add type: snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/5896> | 09:21 |
| zyga | sigh :/ | 09:24 |
| zyga | woah | 09:24 |
| zyga | actually! | 09:24 |
| mup | PR snapd#5897 opened: interfaces/builtin: add gpio-keys interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897> | 09:34 |
| * pstolowski after typing 'go push' for nth time, wishes computers were smart enough to know what i mean wrt to git and go, and simply do the right thing | 09:36 | |
| mup | PR snapd#5898 opened: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898> | 09:36 |
| zyga | flashed pi2, no picture :/ | 09:37 |
| zyga | back to debugging | 09:37 |
| mborzecki | zyga: you got to make an offering to the pi | 09:38 |
| zyga | I have to plug the serial adapter but sigh, not now | 09:39 |
| zyga | 2018-10-02 11:39:38 Cannot allocate google:ubuntu-core-18-64: cannot allocate new Google server for ubuntu-core-18-64: quota 'IN_USE_ADDRESSES' exceeded. Limit: 575.0 in region us-east1. | 09:50 |
| zyga | we may have stale machines somewhere? | 09:50 |
| zyga | woot, some improvement | 09:57 |
| mup | PR snapd#5883 closed: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5883> | 10:08 |
| mup | PR snapd#5899 opened: tests: shellchecks, final round <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5899> | 10:18 |
| mvo | mborzecki: yay for shellcheck | 10:37 |
| mborzecki | mvo: slightly longer than usual, but i figured we should just be done with it | 10:38 |
| mvo | mborzecki: +1 | 10:40 |
| === chihchun is now known as chihchun_afk | ||
| rogpeppe | if i have i've registered a snap, but i want to make it possible for other people (ideally a team) to manage that snap (push updates, etc), how would I do that? | 10:47 |
| zyga | rogpeppe: add them as collaborators in the snap dashboard | 10:50 |
| rogpeppe | zyga: where do i find the snap dashboard? | 10:50 |
| zyga | rogpeppe: login to https://snapcraft.io/ and go to https://snapcraft.io/snaps | 10:51 |
| rogpeppe | zyga: i'm currently looking at https://snapcraft.io/mysnapname/listing | 10:51 |
| zyga | then pick the snap name you want to share | 10:51 |
| rogpeppe | zyga: click on it? | 10:52 |
| zyga | hmm, hold on | 10:52 |
| zyga | https://dashboard.snapcraft.io/snaps/ | 10:52 |
| rogpeppe | zyga: ah yes! just found that | 10:53 |
| zyga | that functionality is available in the old dashboard | 10:53 |
| rogpeppe | zyga: very confusing | 10:53 |
| zyga | then you can go to collaboration page | 10:53 |
| zyga | yeah, I agree | 10:53 |
| zyga | I thought this was one page now | 10:53 |
| rogpeppe | zyga: can i add groups? | 10:53 |
| zyga | no, only users AFAIK | 10:53 |
| rogpeppe | zyga: ok, thanks. | 10:54 |
| zyga | mborzecki: I took the logic for updating a namespace into a new package and wrote a mini tool that just displays what would happen given two fstab files | 10:54 |
| zyga | I ran it on the problematic namespace | 10:54 |
| zyga | https://paste.ubuntu.com/p/QYCsJMkPJg/ | 10:54 |
| zyga | the results are sane | 10:54 |
| rogpeppe | zyga: thank you | 10:54 |
| zyga | so far so good then | 10:54 |
| zyga | I'll break for coffee and do more digging | 10:57 |
| ogra | mvo, sil2100 what happened to the pi3 gadget, there are a bunch of fixes that do not show up in edge (16) | 11:00 |
| ogra | all of a sudden the auto-builds seem to build 18.X only | 11:00 |
| ogra | we (ondra mainly) are trying to test the pi3 b+ and the last pi3 gadget build for core16 is from august ... yet the last commits on GH are newer (to pick up the new boot firmware) | 11:01 |
| ogra | i see it being built at https://code.launchpad.net/%7Ecanonical-foundations/+snap/pi3 | 11:02 |
| ogra | oh | 11:02 |
| ogra | "Store upload failed: Cannot upload new revisions for name=pi3 series=16 " | 11:03 |
| ogra | https://code.launchpad.net/~canonical-foundations/+snap/pi3/+build/343957 | 11:03 |
| ogra | ondra_, so seems the builds havent been uploaded since august 2017 :/ | 11:03 |
| ogra | cjwatson, any idea whats going on there with that "Store upload failed: Cannot upload new revisions for name=pi3 series=16" ? (there is no other error msg anywhere) | 11:04 |
| ogra | hrm ... and hitting the retry button gets me "you are not allowed here" ... thats new | 11:05 |
| ogra | this is pretty serious, the boot firmware had plenty of imprtat fixes since aug. 2017 that should go in asap | 11:08 |
| ogra | (power and thermal mgmt ... support for cm3 and pi3b+) | 11:09 |
| zyga | back to digging | 11:10 |
| Chipaca | oh dang | 11:14 |
| Chipaca | mborzecki: mvo: do we have a 'stop the line' button? | 11:15 |
| Chipaca | mborzecki: mvo: the xdelta tests are failing -- at first I thought it was a transient and was checking with wgrant, but the logs show we aren't enabling deltas, and mborzecki's pr just failed with them as well | 11:15 |
| Chipaca | mborzecki: mvo: what have we broken? | 11:16 |
| mborzecki | Chipaca: wasn't there a switch to enable deltas? | 11:17 |
| mborzecki | i vaguely recall a pr (from mvo?) | 11:17 |
| ondra_ | ogra ping | 11:18 |
| pedronis | it's generally on now (lat time I checked) | 11:18 |
| Chipaca | mborzecki: as long as we have an xdelta3 executable it should be on -- and we nearly always have an xdelta3 executable as it's in core :-) | 11:18 |
| ogra | ondra_, yo | 11:18 |
| mborzecki | Chipaca: what if the executable is named xdelta? | 11:18 |
| Chipaca | mborzecki: the one in core isn't | 11:19 |
| ogra | ondra_, i can see you now | 11:19 |
| pedronis | Chipaca: are they failing everywhere or only some distros? | 11:19 |
| wgrant | mborzecki, Chipaca: Also xdelta is xdelta 1, not xdelta3 | 11:19 |
| Chipaca | pedronis: everywhere | 11:19 |
| Chipaca | bah | 11:19 |
| pedronis | did master became red and we didn't notice? | 11:20 |
| pedronis | or is it on PRs? | 11:20 |
| Chipaca | amazon-linux-2-64,arch-linux-64,debian-9-64,fedora-28-64,opensuse-42.3-64,ubuntu-14.04-64,ubuntu-16.04-64,ubuntu-18.04-64, | 11:20 |
| mborzecki | w8, but the PRs id opened today were green | 11:20 |
| Chipaca | everywhere that isn't actually core | 11:20 |
| Chipaca | pedronis: on two unrelated PRs that are unrelated to this bit of code | 11:20 |
| pedronis | master is green fwiw | 11:21 |
| pedronis | atm | 11:21 |
| Chipaca | my epoch.CanRead, which isn't even used anywhere, and mborzecki's shellchecks | 11:21 |
| mborzecki | yup, but #5898 which was opened 2h ago is green | 11:21 |
| mup | PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898> | 11:21 |
| Chipaca | mborzecki: and the same epochs PR that ran spread just before this last run failed with a silly transient error unrelated to this | 11:22 |
| Chipaca | so whatever it was, it was in the last half hour | 11:22 |
| Chipaca | which is why the first thing I assumed was store shenanigans | 11:22 |
| Chipaca | (sorry wgrant) | 11:22 |
| wgrant | :) | 11:23 |
| wgrant | New core snap maybe? | 11:23 |
| wgrant | Yeah | 11:24 |
| wgrant | It had core 5618 | 11:24 |
| wgrant | Which is 16-2.36~pre1, and it's 53 minutes old | 11:24 |
| wgrant | mvo: ^^ | 11:24 |
| wgrant | Must be that, surely | 11:24 |
| Chipaca | 334 "created-at": "2018-10-02T10:30:33.953597+00:00", | 11:24 |
| Chipaca | heh, yep | 11:24 |
| pedronis | likely, wonder why we decided to drop one package there (or whether we dropped more, that would be bad) | 11:24 |
| wgrant | xdelta3 is in the build log, though | 11:25 |
| wgrant | But not the manifest | 11:25 |
| pedronis | it's supposed to have a fixed list of packages | 11:25 |
| Chipaca | wgrant: in which build log? | 11:25 |
| wgrant | https://launchpad.net/~snappy-dev/+snap/core/+build/344744 | 11:25 |
| Chipaca | ah | 11:25 |
| pedronis | at this point | 11:25 |
| wgrant | The build log for that core snap | 11:25 |
| Chipaca | $ /snap/core/current/usr/bin/xdelta3 -h | 11:25 |
| Chipaca | bash: /snap/core/current/usr/bin/xdelta3: No such file or directory | 11:25 |
| Chipaca | ^ that's core from beta | 11:25 |
| Chipaca | fuuuuu | 11:25 |
| Chipaca | mvo: OHAI | 11:25 |
| Chipaca | or maybe cachio | 11:26 |
| pedronis | fun (not) | 11:26 |
| Chipaca | also, also, of course cachio today had is laptop go all MCE on him so he's unavailable for a bit | 11:26 |
| pedronis | Chipaca: either losing packages out of core is bad (tm) :/ | 11:26 |
| mborzecki | good thing it was caught by the tests after all | 11:27 |
| pedronis | I think core18 has more checks in that area | 11:27 |
| sil2100 | ogra: yeah, I'll be looking at that | 11:27 |
| ogra | sil2100, thanks ... | 11:28 |
| wgrant | Oh | 11:28 |
| wgrant | The xdelta3 in the log is LP installing it for the snapd in the container to use | 11:28 |
| wgrant | Not the build itself, heh. | 11:28 |
| Chipaca | another thing, we need to update the tests because we've got refresh-delta and refresh-delta-from-core with the assumption that the former has xdelta3 from the distro and the latter doesn't, but the former doesn't check | 11:28 |
| ogra | wgrant, Chipaca that build log shows that the completely wrong livecd-rootfs is used | 11:30 |
| ogra | it needs to come from the PPA unless *all* PPA changes have been merged into xenial-updates yet | 11:30 |
| wgrant | Hah, indeed, | 11:30 |
| ogra | (probably that was a manual build and whoever did it missed to pick the PPA as archive ?) | 11:31 |
| wgrant | RUN: /usr/share/launchpad-buildd/slavebin/in-target override-sources-list --backend=lxd --series=xenial --arch=amd64 SNAPBUILD-344744 'deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial main' 'deb http://ftpmaster.internal/ubuntu xenial main restricted universe multiverse' 'deb http://ftpmaster.internal/ubuntu xenial-security main restricted universe multiverse' 'deb http://ftpmaster.internal/ubuntu | 11:31 |
| wgrant | xenial-updates main restricted universe multiverse' | 11:31 |
| wgrant | yeah, no, image in there, just tools | 11:31 |
| wgrant | https://launchpad.net/~snappy-dev/+snap/core/+build/344744 <- indeed, primary archive build | 11:31 |
| wgrant | Worth quickly reverting that at least in beta to avoid bricking everybody? | 11:32 |
| Chipaca | no brick, just no deltas | 11:32 |
| pedronis | Chipaca: that's a theory, it was built all wrong, so something else might be amiss | 11:33 |
| ogra | Chipaca, definitely brick ... | 11:33 |
| ogra | Chipaca, if the build scripts are wrong you get more broken content than xdelta3 missing :) | 11:33 |
| Chipaca | ogra: if so then we should definitely revert | 11:33 |
| Chipaca | i can do it, but i'd rather a nod from mvo before just doing it :) | 11:33 |
| === d__ed is now known as d_ed | ||
| * Chipaca telegrams | 11:34 | |
| * Chipaca succeeds | 11:34 | |
| mvo | Chipaca: here | 11:37 |
| mvo | Chipaca: thanks for altering me, I removed ~pre1 from edge | 11:37 |
| Chipaca | mvo: nice | 11:38 |
| Chipaca | mvo: thanks | 11:38 |
| mvo | Chipaca: reading backlog now | 11:39 |
| Chipaca | mvo: look for 'stop the line' and down from there | 11:39 |
| mvo | Chipaca: hrm, the annoying part is there is a script that checks if the ppa is missing and it should error in this case | 11:39 |
| * mvo looks why this was not working | 11:39 | |
| Chipaca | mvo: maybe ogra removed the 'set -e' | 11:40 |
| * Chipaca hides | 11:40 | |
| mvo | haha | 11:40 |
| ogra | mvo, whoever buuilt it missed to pick the PPA as archive in the build form ... so the archive livecd-rootfs was used | 11:40 |
| mvo | ogra: yes, my fault | 11:40 |
| mvo | ogra: I'm looking why it did not error, there is code in there that should make it error :( | 11:41 |
| ogra | Chipaca, well, for my british friends i nowadays do not remove "set -e" but add "set -eu" :P | 11:41 |
| ogra | mvo, thats the outer lxd container ... during build it then pulls the right livecd-rootfs (but then it is already too late) | 11:42 |
| ogra | not sure you can actually have code inside the container that checks the livecd-rootfs version outside | 11:42 |
| zyga | ogra: lol | 11:43 |
| Chipaca | ogra: +1.33 | 11:43 |
| cjwatson | ogra: That means that the user who authorised the upload of that snap is no longer a publisher or a collaborator of the snap. Get somebody appropriate to go to https://code.launchpad.net/~canonical-foundations/+snap/pi3/+authorize and reauth it | 11:45 |
| ogra | cjwatson, ah, seems i lost my credentials when i moved teams or some such ... but sil2100 already said he'd take care | 11:45 |
| ogra | (or the build moved ownership ...) | 11:46 |
| mup | PR core#97 opened: snapcraft.yaml: add check for ppa:snappy-dev/image <Created by mvo5> <https://github.com/snapcore/core/pull/97> | 11:49 |
| zyga | HA | 11:50 |
| zyga | that was super fun to find | 11:50 |
| axino | hi popey, could you please release edge into stable for the sentry snap ? | 12:06 |
| popey | axino: done | 12:07 |
| axino | popey: thanks ! | 12:07 |
| === pstolowski is now known as pstolowski|lunch | ||
| dot-tobias | What's the best way to implement an on-demand-service in my snap? Use case: My snapped app needs a DNS server (dnsmasq) if it is in setup mode, so I need to start/stop the server from within my application code. However, it should *not* (re-)start automatically (i.e. like snap daemons) Q1: How would I start the service from within the snap? Q2: And how to stop the service if I don't have access to systemctl? | 12:27 |
| zyga | you can do both by invoking "snapctl" | 12:27 |
| zyga | or by talking to snapd over a socket directly | 12:27 |
| zyga | (but snapctl makes that much easier) | 12:27 |
| mup | PR snapcraft#2309 closed: snap: improve early base detection logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2309> | 12:27 |
| zyga | as for the part where you want the service not to restart automatically | 12:28 |
| zyga | there's a word that you can use in the snapcraft.yaml (or snap.yaml) to convey that | 12:28 |
| zyga | I recall that at the level of an application definition you say "refresh: endure" or something like that | 12:28 |
| zyga | it will then not be restarted when a snap is refreshed | 12:28 |
| zyga | and it is up to you to manage that | 12:28 |
| dot-tobias | zyga Ok, thanks. But the service would be started on snap installation? | 12:29 |
| zyga | currently yes but there's a PR that fixes a bug in this area, which once merged would allow you to disable the service from a configure (or install) hook | 12:30 |
| zyga | so your hook disables the service using snapctl | 12:30 |
| zyga | your snap or configure hook can enable or start it on demand | 12:30 |
| zyga | or actually, as the need arises | 12:30 |
| zyga | such as when the application logic determines it is now needed | 12:30 |
| zyga | not in the socket-activation meaning of the word | 12:30 |
| zyga | but note that the bug is still in place and snapd will still try to start disabled services | 12:31 |
| * zyga looks at the PR | 12:31 | |
| zyga | https://github.com/snapcore/snapd/pull/5777 | 12:31 |
| mup | PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777> | 12:31 |
| zyga | it seems that someone needs to pick that up and finish it | 12:31 |
| zyga | dot-tobias: does that answer your question? | 12:32 |
| dot-tobias | zyga (skimming through the PR) yes, that should solve my problem. Any internal ETA on when this will be merged? Need to release an initial beta soon, and depending on that I'd need to find a workaround until then. | 12:34 |
| dot-tobias | And thank you again, of course 😊 | 12:34 |
| zyga | no ETA, someone just needs to pick it up | 12:35 |
| mup | PR core#97 closed: snapcraft.yaml: add check for ppa:snappy-dev/image <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/97> | 12:41 |
| dot-tobias | zyga Would love to help if I had any proficiency in Go, but I guess I would need to take a weeklong deep dive into Go & snapd to even have a faint idea of what I'd be doing there … While the daemon route seems the way to go when the PR is merged, is it possible to stop a process (dnsmasq in background mode) that's been triggered by my app? The interfaces docs mention that core-support provides access to systemctl, but is reserved for core snaps. | 12:41 |
| ogra | mvo, oh, wow ... seems you trashed three of my test Pi's over here ... all of them run 16-2.36~pre1 and there are no network tools in the rootfs (so only serial login) | 12:42 |
| zyga | dot-tobias: I think we will handle that , no worries, just cannot give you a timeline | 12:42 |
| ogra | interestingly enough it boots fine to console login | 12:42 |
| Chipaca | waiting for tests is dangerous | 12:42 |
| Chipaca | https://pastebin.ubuntu.com/p/jR2vnGjZvP/ | 12:42 |
| zyga | dot-tobias: would dnsmasq be a part of your snap or just any random service in the system? | 12:42 |
| dot-tobias | zyga dnsmasq is part of my snap. | 12:42 |
| dot-tobias | organized to $SNAP/bin/dnsmasq | 12:43 |
| zyga | dot-tobias: for that you *can* use snapctl to stop the service from your snap, you don't need any interface for this | 12:43 |
| zyga | I don't recall if this is documented, let me look | 12:43 |
| zyga | dot-tobias: have a look at https://forum.snapcraft.io/t/service-management/3965 | 12:43 |
| mvo | ogra: yeah, snap revert | 12:44 |
| mvo | ogra: but no network, I reproduced it and the no-network is the killer | 12:44 |
| mvo | ogra: sorry for that | 12:44 |
| dot-tobias | zyga: Thanks, will try it out! | 12:44 |
| ogra | mvo, no worries ... i asked for it by choosing edge after all ;) | 12:45 |
| Chipaca | oh dang, lunch | 12:45 |
| mvo | ogra: I'm looking into a check for this as we speak to ensure this can't happen again | 12:45 |
| ogra | mvo, yeah, i saw your clever PR above already | 12:45 |
| ogra | that looks actually good ... | 12:46 |
| zyga | dot-tobias: good luck! | 12:46 |
| zyga | dot-tobias: hint: try "snap run --shell your-snap" | 12:46 |
| zyga | and then run snapctl | 12:47 |
| zyga | you should be able to get access to your services | 12:47 |
| mvo | ogra: yay, check worked, so this won't ever happen again:https://code.launchpad.net/~snappy-dev/+snap/core/+build/344819 - bad enough that it happend once :( | 12:48 |
| ogra | jdstrand, any news for me about dashkiosk-client-browser ? | 12:48 |
| ogra | mvo, once ? it happened quite often to me back when i was still in charge ... :) (but i usually noticed before it went to the store) | 12:49 |
| ogra | its a bit sad that LP doesnt simply keep the choices you did for the last build as default | 12:50 |
| mvo | ogra: heh - indeed | 12:50 |
| ogra | perhaps one day someone invents an internet technology that makes it possible to store such data in your local browser ... and callsss them crisps ... or cakes ... or cookies :P | 12:52 |
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| === pstolowski|lunch is now known as pstolowski | ||
| jdstrand | ogra: oh sorry. I had it on my desk then got distracted | 13:06 |
| ogra | no worries ... i thought so :) | 13:06 |
| mup | PR snapd#5900 opened: release: 2.36~pre1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5900> | 13:11 |
| ijohnson | Hey folks, I'm almost done with handling sockets/timers in #5777, but currently snapctl and snap commands both don't handle stopping services with timers/sockets so that can't be tested in my PR. I'm wondering if I should add support for stopping sockets/timers in this PR or a different one? | 13:36 |
| mup | PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777> | 13:36 |
| emilengler | Why snap remove does not remove the cahced snap ? | 13:40 |
| ogra | can you elaborate ? | 13:40 |
| zyga | emilengler: I think we cache the snap on disk for some time | 13:41 |
| zyga | I don't recall the exact condition | 13:41 |
| zyga | but it's deliberate | 13:41 |
| ogra | but only the first installed one, no ? | 13:42 |
| mborzecki | pedronis: can you take a look at https://github.com/snapcore/snapd/pull/5898 later today/tomorrow? | 13:42 |
| mup | PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898> | 13:42 |
| pedronis | mborzecki: tomorrow, I have some errands today and will finish a bit early | 13:43 |
| mborzecki | pedronis: sure, thank you! | 13:43 |
| pedronis | Chipaca: https://github.com/snapcore/snapd/pull/5791 | 13:43 |
| mup | PR #5791: overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath <Created by pedronis> <https://github.com/snapcore/snapd/pull/5791> | 13:43 |
| Chipaca | mvo: with you now having written a juju charm, do we need to add Charming to your honorifics? | 13:44 |
| Chipaca | pedronis: looking | 13:44 |
| Chipaca | zyga: https://github.com/snapcore/snapd/pull/5891 one to help you with your aim of review more :-D | 13:45 |
| mup | PR #5891: snap: give Epoch a CanRead helper <Created by chipaca> <https://github.com/snapcore/snapd/pull/5891> | 13:45 |
| zyga | Chipaca: ack :) looking now | 13:45 |
| * zyga fired spread with the tmpfs subdirectory fix | 13:45 | |
| zyga | the actual fix is tiny, it just took a while to get to | 13:45 |
| Chipaca | pedronis: I'm sure I'd seen this one before; +1 | 13:46 |
| zyga | Chipaca: oooh | 13:47 |
| pedronis | Chipaca: yes, but just today I went to it to make the spread tests pass, again don't make it too backward incompatible | 13:47 |
| zyga | Chipaca: you know I will bike shed around intersect, right? | 13:47 |
| Chipaca | zyga: I can show you alternative, worse implementations | 13:47 |
| Chipaca | zyga: https://pastebin.ubuntu.com/p/2WwjkPNStG/ | 13:48 |
| Chipaca | zyga: the only one that is arguably better is F1b | 13:49 |
| Chipaca | zyga: F1c, not shown there, which has two more ifs in it is slower again | 13:49 |
| mvo | Chipaca: hahaha | 13:49 |
| Chipaca | bah, I might as well add them all | 13:49 |
| zyga | Chipaca: did you try sorting the shorter list, then iterating over the longer list while binary-searching in the short list? | 13:50 |
| Chipaca | zyga: they're both sorter | 13:50 |
| Chipaca | sorted* | 13:50 |
| zyga | oh | 13:50 |
| zyga | nice | 13:50 |
| Chipaca | zyga: and both non-empty | 13:50 |
| Chipaca | zyga: F3 does binary search | 13:50 |
| zyga | anyway, I'll get something to bite on and read this | 13:51 |
| Chipaca | zyga: I'll restore the full one so you see all the variations | 13:51 |
| zyga | k, brb | 13:51 |
| mborzecki | funny, cause iirc the list of 10 elements max :) | 13:53 |
| cachio | mvo, 2.35.2 is stable now | 13:55 |
| mvo | cachio: thank you | 13:55 |
| mvo | cachio: now I just need to nudge the sru guys again about it :/ | 13:56 |
| mborzecki | off to pick up the kids | 13:56 |
| cachio | mvo, good | 14:01 |
| cachio | mvo, I'll start with beta now | 14:02 |
| kenvandine | zyga: any theories on bug 1794953 ? | 14:05 |
| mup | Bug #1794953: GNOME Calculator snap has wrong theme in live session <rls-cc-tracking> <snapd:New for zyga> <gnome-calculator (Ubuntu):Invalid by ken-vandine> <snapd (Ubuntu):Confirmed | 14:05 |
| mup | for zyga> <gnome-calculator (Ubuntu Cosmic):Invalid by ken-vandine> <snapd (Ubuntu Cosmic):Confirmed for zyga> <https://launchpad.net/bugs/1794953> | 14:05 |
| Chipaca | zyga: qqq in my home on office.zygoon.pl, fwiw | 14:34 |
| zyga | re | 14:42 |
| zyga | Chipaca: qqq? | 14:42 |
| zyga | (sorry, I was stolen to participate in family lunch_) | 14:43 |
| zyga | ah | 14:43 |
| * zyga looks | 14:43 | |
| Chipaca | zyga: I have a random package name generator | 14:43 |
| Chipaca | zyga: (it's not very random) | 14:43 |
| Chipaca | for example I also have some other unrelated tests in /tmp/jjj | 14:43 |
| zyga | I need to spend this evening on bringing machines back online | 14:43 |
| Chipaca | (about json) | 14:43 |
| * zyga sees that now | 14:44 | |
| Chipaca | ¯\_(ツ)_/¯ | 14:44 |
| zyga | oh, BenchmarkF | 14:44 |
| Chipaca | it starts with /tmp/q.go being my default scratch file for go stuff | 14:44 |
| zyga | I never tried that | 14:44 |
| Chipaca | and, well, not being good with names means i don't even try unless it's important :-) | 14:44 |
| zyga | kenvandine: as for your question, no theory yet, I need to see what's going on in live sessions to begin with | 14:44 |
| zyga | kenvandine: is it perhaps related to the fact that theming was broken in those snaps we looked at the last time? | 14:45 |
| rbasak | Is there any known regression in the core beta snap atm? I have one | 14:46 |
| rbasak | Affects beta and edge AFAICT | 14:47 |
| rbasak | https://paste.ubuntu.com/p/zqWhpGF8nC/ | 14:47 |
| rbasak | mvo: ^ | 14:47 |
| Chipaca | rbasak: re-refresh | 14:47 |
| Chipaca | rbasak: we broke it, and then fixed it | 14:47 |
| rbasak | Ah | 14:47 |
| Chipaca | rbasak: 1 sec, let me get you a timestamp | 14:48 |
| Chipaca | rbasak: 2018-10-02T10:30:33.953597+00:00 | 14:48 |
| Chipaca | rbasak: that core ^ is buggy | 14:48 |
| rbasak | ahasenack: ^ | 14:48 |
| Chipaca | er, i should have a revno | 14:48 |
| mvo | rbasak: we had a bad core for about 30min | 14:48 |
| Chipaca | rbasak: we caught the issue and reverted to a known-good one already, fwiw | 14:48 |
| Chipaca | as mvo says | 14:49 |
| kenvandine | zyga: the theme is fine for those same snaps on a clean 18.10 install | 14:49 |
| zyga | I see | 14:49 |
| ahasenack | refresh-date: 11 days ago, at 08:50 -03 | 14:49 |
| rbasak | beta (5624) is still broken I think? | 14:49 |
| ahasenack | weird why mine didn't refresh in such a long time | 14:49 |
| zyga | it could be a new interaction with how overlayfs is used on 18.10, I need to debug that | 14:49 |
| mvo | rbasak: sorry for that, just revert or refresh and it should be fine again. sorry for the trouble. we identified the source and added an extra check during the build to ensure this won't happen again | 14:49 |
| zyga | I didn't have the time to do that yet | 14:49 |
| ahasenack | installed: 16-2.35.2 (5548) 92MB core is what I have | 14:49 |
| Chipaca | 5618 is the broken one for amd64 | 14:49 |
| ahasenack | what about 5548? | 14:50 |
| * Chipaca checks revnos | 14:50 | |
| mvo | rbasak: what kind of breakage do you see with 5624? | 14:50 |
| mvo | ahasenack: 5548 should be good | 14:50 |
| rbasak | I don't have a reproducer with core only. Is there any way of getting a shell on core? | 14:50 |
| ahasenack | I'm tracking beta, I wonder why I didn't get beta: 16-2.36~pre1 (5624) 92MB - | 14:50 |
| rbasak | My reproducer is as my pastebin above | 14:50 |
| mvo | rbasak: if you have grub you can add "systemd.debug-shell=1" to the cmdline | 14:50 |
| Chipaca | 5548 is stable, even | 14:51 |
| mvo | rbasak: missed that pastebin let me look | 14:51 |
| rbasak | It could be git-ubuntu, I don't know. | 14:51 |
| mvo | rbasak: let me try this | 14:51 |
| Chipaca | rbasak: ahasenack: ah, was about to say, 5624 is what you're on it seems | 14:51 |
| rbasak | But it seems to be triggered by a core snap update - stable was OK this morning. | 14:51 |
| mvo | rbasak: could be us let me look at it | 14:51 |
| rbasak | Thanks | 14:51 |
| mvo | rbasak: I mean, we had a bad beta today so I'm inclined to first look at our stuff. | 14:52 |
| zyga | kenvandine: I can promise you to look at and attempt to debug the issue first thing tomorrow | 14:52 |
| ahasenack | Chipaca: https://pastebin.ubuntu.com/p/mw8g8x3qm3/ am I not on 5548? | 14:52 |
| zyga | kenvandine: today I plan to finish producing mergeable fixes for other mount related bugs | 14:52 |
| Chipaca | ahasenack: ah, you are, rbasak is not | 14:52 |
| kenvandine | zyga: thanks | 14:52 |
| ahasenack | ok, I get the same problem as him | 14:52 |
| rbasak | I've jumped about all over the place today | 14:52 |
| Chipaca | ahasenack: so that's confusing, are you talking about the same issue? | 14:52 |
| Chipaca | mvo: ahasenack has it and he's on stable | 14:52 |
| ahasenack | yes, I'm getting this: | 14:53 |
| rbasak | I can confirm a specific one for you if you want to focus on a particular version | 14:53 |
| Chipaca | we haven't touched stale in a while, let me get a timestamp | 14:53 |
| ahasenack | 10/02/2018 11:50:51 - ERROR:stderr: awk: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory | 14:53 |
| ahasenack | awk: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory | 14:53 |
| ahasenack | which rbasak streamlined into his pastebin | 14:53 |
| Chipaca | stable is from 2018-09-21 | 14:53 |
| Chipaca | ahasenack: rbasak: 5548 is from 2018-09-21T09:37:27.063407+00:00 | 14:53 |
| mvo | ahasenack: we had a stable update today | 14:54 |
| ahasenack | the word "stable" does not appear for core in my snap list --all output | 14:54 |
| ahasenack | and "snap info core" says I'm tracking beta | 14:54 |
| ahasenack | is stable ahead of beta? | 14:54 |
| rbasak | stable is now broken :-/ | 14:54 |
| rbasak | 5548 | 14:55 |
| Chipaca | sigh | 14:55 |
| rbasak | it was working for me this morning, but I didn't record the version | 14:55 |
| Chipaca | ahasenack: you said you were on 5548 | 14:55 |
| Chipaca | ahasenack: or am I losing it | 14:55 |
| ahasenack | Chipaca: look at https://pastebin.ubuntu.com/p/mw8g8x3qm3/ | 14:55 |
| mvo | rbasak: this morning it was 2.35 - now its 2.35.2 | 14:55 |
| ahasenack | 5548 has "beta" next to it | 14:55 |
| rbasak | I did some testing this morning, then was called away, so there was a gap before I reported it here, sorry. | 14:56 |
| ahasenack | so looks like beta was promoted to stable, and now both have 5548, is that it? | 14:56 |
| mvo | rbasak: what environment did you run this on? bionic? cosmic? | 14:56 |
| rbasak | mvo: bionic | 14:56 |
| mvo | ahasenack: candidate was promoted to stable today, beta should be a different revision (r5624 currently) | 14:57 |
| * Chipaca was getting confused and only adding confusion so will now keep quiet for a bit | 14:57 | |
| rbasak | mvo: I reproduced on a Bionic VM with the edge git-ubuntu snap | 14:57 |
| mvo | rbasak: thanks, let me try with git-ubuntu edge | 14:57 |
| ahasenack | refreshing core | 14:58 |
| ahasenack | I'm getting 5624 now | 14:58 |
| rbasak | I can give you exact steps that work I believe, so let me know if you have any difficulty | 14:58 |
| mvo | rbasak: I poke at it now (both on my bionic box and in a VM) | 14:58 |
| ahasenack | still happens to me with 16-2.36~pre1 5624 | 14:58 |
| ahasenack | fwiw | 14:58 |
| mvo | rbasak: slightly strange is that you and ahasenack were running beta for a while so nothing should have changed for you | 14:58 |
| Chipaca | ahasenack: rbasak: which was the last core that worked ok for you? | 14:59 |
| mvo | rbasak: this revision of core that is now in stable was in beta/candidate for a while | 14:59 |
| ahasenack | mvo: I didn't get this just today, it's from last week I think | 14:59 |
| ahasenack | I was on pto | 14:59 |
| mvo | ahasenack: oh, ok | 14:59 |
| mvo | ahasenack: thanks, that explains this part then | 14:59 |
| ahasenack | I can try reverting core | 15:00 |
| rbasak | mvo: I haven't been using this particular subcommand of git-ubuntu that triggers it, so it's only ahasenack who had noticed it until I tried to reproduce | 15:00 |
| ahasenack | I still have 5486 available | 15:00 |
| rbasak | Chipaca: I believe stable from this morning worked, though I don't see exactly how to revert to that right now. | 15:00 |
| mvo | rbasak: snap revert core is not working ? | 15:01 |
| Chipaca | rbasak: snap list --all core, if you still have the revno you can revert core --revision=... | 15:01 |
| Chipaca | which is the git-ubuntu subcommand that fails? | 15:01 |
| ahasenack | mvo: Chipaca rbasak with core r5486, it works | 15:01 |
| Chipaca | nice | 15:02 |
| ahasenack | Chipaca: build-source, when inside an ipsec-tools package, but rbasak's test case is shorter/simpler | 15:02 |
| rbasak | Chipaca: thanks. "snap help refresh" said "snap refresh --list" but that didn't work (just said "All snaps up to date." | 15:02 |
| rbasak | ) | 15:02 |
| Chipaca | rbasak: refresh != revert :) | 15:02 |
| mvo | so far on my bionic main box I can not reproduce it but I am trying in a vm now, my regular machine is heavily customized | 15:02 |
| rbasak | Chipaca: nevertheless, that's what "snap help refresh" says! | 15:03 |
| mvo | rbasak: I see it in a fresh vm | 15:03 |
| rbasak | Unfortunately I think I've tested too many revisions since, and it has scrolled out of my (three?) history revisions | 15:03 |
| rbasak | (the stable one that worked) | 15:03 |
| Chipaca | rbasak: I'm not following, but let's get back to that afterwards (better docs is good, but) | 15:03 |
| rbasak | OK | 15:05 |
| Chipaca | rbasak: which was your smaller reproducer? | 15:06 |
| mup | PR snapcraft#2311 opened: snap: legacy needs to now it is legacy for re-exec <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2311> | 15:07 |
| Chipaca | rbasak: got it | 15:08 |
| rbasak | FTR, https://paste.ubuntu.com/p/zqWhpGF8nC/ | 15:08 |
| rbasak | On the git-ubuntu edge snap, is the smallest I have | 15:08 |
| Chipaca | rbasak: can you install test-snapd-tools, and snap run --shell test-snapd-tools.sh and see awk there? | 15:09 |
| mvo | rbasak: it looks like something is not setting the right LD_LIBRARY_PATH, with LD_LIBRARY_PATH=/snap/core/current/lib/x86_64-linux-gnu/ inside the shell things should be ok | 15:10 |
| mvo | Chipaca: -^ | 15:11 |
| mvo | rbasak: the issue is that bionic ships with libreadline.so.7 | 15:11 |
| rbasak | Chipaca: done, and awk works there, contrary to the git-ubuntu snap for the same core snap revision. | 15:11 |
| mvo | rbasak: but the awk on core is from xenial which has libreadline.so.6 and the core awk wants this lib. | 15:11 |
| greyback | sergiusens: hey, any ideas why this is failing? https://pastebin.ubuntu.com/p/hxMjKT6VMM/ | 15:12 |
| mvo | rbasak, Chipaca I think it is related to --classic so test-snapd-tools is fine | 15:12 |
| Chipaca | my next check was the same but with 'go' | 15:12 |
| mvo | Chipaca: \o/ | 15:12 |
| Chipaca | rbasak: if you could do the same (snap install --classic go && snap run --shell go, and see awk) | 15:13 |
| mvo | Chipaca: I'm still struggling to understand why that worked before - actually I thnk I know. before it was a symlink in /etc/alternatives that pointed inside the host fs. now its a relative symlink that points into core | 15:13 |
| sergiusens | greyback: you are on stable? | 15:13 |
| rbasak | Chipaca: also works | 15:13 |
| greyback | sergiusens: yes | 15:13 |
| mvo | Chipaca: can of worms | 15:14 |
| greyback | sergiusens: but same on edge and beta | 15:14 |
| rbasak | I'm happy to land any change you recommend into git-ubuntu of course | 15:14 |
| sergiusens | greyback: we haven't changed stable in weeks | 15:14 |
| sergiusens | greyback: lxd 3.0? | 15:14 |
| mvo | rbasak: thanks and again sorry for the trouble, looking at git-ubuntu now to see what its actually doing | 15:14 |
| sergiusens | greyback: if you run again, does it work? | 15:14 |
| greyback | sergiusens: 3.5 from the stable snap | 15:14 |
| greyback | sergiusens: no, fails same way. Just tried cleanbuild, also errored out with "snapcraft: not found" | 15:15 |
| sergiusens | greyback: what happens if you wipe "~/.local/share/snapcraft/projects/lxd/"? | 15:16 |
| sergiusens | I mean, can you wipe that and try again | 15:16 |
| mvo | sergiusens: I'm just looking at an issue with a classic snap. the issue is that it uses gawk from xenial which uses libreadline.so.6 but runs (in classic mode) on a bionic with just libreadline.so.7. it looks like snapcraft sets the PATH to the /snap/core/current. should we also set the LD_LIBRARY_PATH to the matching pathes? | 15:18 |
| zyga | mvo: I don't think that's safe | 15:18 |
| zyga | in general | 15:19 |
| zyga | that impacts more than it should | 15:19 |
| zyga | if you set it other things may break | 15:19 |
| sergiusens | mvo: we never set PATH, I we do not set LD_LIBRARY_PATH | 15:19 |
| sergiusens | because of what zyga mentions | 15:19 |
| sergiusens | we leave it up to the dev | 15:19 |
| mvo | sergiusens: aha, so thats a snap specific thing? ok | 15:19 |
| greyback | sergiusens: that seemed to have helped (core and snapcraft snaps installed ok), now fails a bit later https://pastebin.ubuntu.com/p/CR26TgZjgg/ - something not done apt update? | 15:19 |
| sergiusens | if they do not intend to ever shell out or dlopen anything random, it can work | 15:19 |
| mvo | rbasak: where is the source of git-ubuntu? I will poke a bit | 15:20 |
| greyback | sergiusens: but I can work with that at least | 15:20 |
| sergiusens | greyback: you are using tech we really haven't supported at all, but try "snapcraft refresh" then go and build away | 15:20 |
| greyback | sergiusens: ok, what should I use? cleanbuild? | 15:20 |
| mvo | zyga: yeah, but right now setting path but not the library path seems inconsistent. i will poke at the snap some more | 15:20 |
| zyga | mvo: we don't set the PATH | 15:21 |
| sergiusens | mvo rbasak git-ubuntu shells out a lot, if you add library paths you risk it breaking when calling binaries from the host | 15:21 |
| zyga | mvo: not for classic snaps | 15:21 |
| mvo | sergiusens: well, its broken right now and I'm looking for a way to unbreak it :) | 15:22 |
| sergiusens | mvo: I cannot say in words on how classic has been my biggest pain for the past two years 🙂 | 15:22 |
| mvo | sergiusens: amen brother | 15:22 |
| ogra | +1 | 15:23 |
| sergiusens | I still blame zyga for saying "it's easy" 😉 | 15:23 |
| ogra | (or rather +10000) | 15:23 |
| * greyback holds up his ligher | 15:23 | |
| zyga | it's all about the context | 15:23 |
| mvo | zyga: I was under the misconception that this would be something that snapcraft would do automatically | 15:23 |
| zyga | making a correct snap is hard | 15:23 |
| sergiusens | yeah, a "Hello world" works fine :-P | 15:23 |
| * ogra hands out hinges to everyone ... so we can actually do something useful with this can of worms | 15:24 | |
| sergiusens | mvo: that's the thing, we crawl all the elf files in the snap and set relative RPATHS all over the place | 15:24 |
| sergiusens | mvo: but not PATH or ld_library_path's | 15:24 |
| mvo | sergiusens: makes me wonder if I should do the same for core | 15:24 |
| rbasak | mvo: https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer/+ref/master | 15:24 |
| rbasak | otp | 15:24 |
| sergiusens | mvo: but then dlopen and python ctypes and maybe other things need manual patching still as they all have their own implementation on how to find libraries to load | 15:25 |
| sergiusens | mvo: that would solve problems if it is what is causing a segfault | 15:25 |
| sergiusens | mvo: if I can parse the problem, is rbasak calling a binary in core and it is loading the wrong libraries? | 15:28 |
| mvo | sergiusens: correct | 15:28 |
| sergiusens | if that is the case, then elf patching is what you need to do, as a classic snap accessing things from core, makes core essentially classic | 15:29 |
| mvo | sergiusens: git-ubuntu is running gawk and because PATH is set its the version from core | 15:29 |
| mvo | sergiusens: but gawk does not find its library (libreadline.so.6) | 15:29 |
| sergiusens | mvo: the alternative is, disallow calling binaries from core; and only allow libraries; but then, you run into problems of libraries calling binaries (like you know in apt) | 15:29 |
| sergiusens | and also library behavior when it dlopens | 15:30 |
| mvo | sergiusens: hrm, hrm, can of worms | 15:30 |
| sergiusens | we can also discuss and transform what classic means and require you to bundle all your deps except maybe libc6 or maybe even so, and they become baseless snaps | 15:30 |
| ogra | just fix PATH that $SNAP/bin:$SNAP/usr/bin comes first and ship gawk in the snap | 15:31 |
| sergiusens | ogra: what if you call a shell out to an app on the host and the host sees that path and makes you call a binary in the snap instead of the host | 15:32 |
| sergiusens | everything is solvable, but it is really project specific | 15:32 |
| ogra | indeed | 15:32 |
| mvo | yeah, the readline problem is really only {g,n}awk and gpg | 15:33 |
| sergiusens | we cannot throw out ideas without looking at the actual problem | 15:33 |
| Chipaca | mvo: and vi? | 15:34 |
| sergiusens | mvo: if core/bases are to support classic, they probably need to do the right thing when it is not the root | 15:34 |
| mvo | Chipaca: unless my script is silly vi on core does not use libreadline | 15:35 |
| mvo | Chipaca: but yeah, its all the same issue it just happens to work because most libs have not changed much | 15:36 |
| mvo | sergiusens, Chipaca it sounds like for this particular problem we would need something like LD_LIBRARY_PATH_AFTER_LD_SO_CONF=... | 15:37 |
| Chipaca | mvo: ah, i was thinking the other way round, but yeah | 15:37 |
| sergiusens | mvo: but the library path will live on the host or how will you set this up? | 15:39 |
| mvo | sergiusens: yeah, there is no such a think right now | 15:39 |
| mvo | sergiusens: I mean the problem would be solved with LD_LIBRARY_PATH=$HOST_LIBRARY_PATH_FROM_LD_SO_CONF:/snap/core/current/lib... | 15:40 |
| * mvo scratches head a bit | 15:40 | |
| sergiusens | mvo: but the libreadline from the host will be found first | 15:41 |
| sergiusens | mvo: that works if the host does not have the library | 15:41 |
| mvo | sergiusens: thats ok in this particular case | 15:41 |
| mvo | sergiusens: yeah this would solve this particular problem | 15:41 |
| * rbasak is back | 15:41 | |
| sergiusens | mvo: heh, that last sentence kind of proves it is not a generic solution | 15:41 |
| mvo | sergiusens: heh, no | 15:41 |
| mvo | sergiusens: I think there is no general solution there is just too much messiness (as you said, ctypes and friends) | 15:42 |
| sergiusens | mvo: this is what we do for snapcraft as a snap to support ctypes https://github.com/snapcore/snapcraft/blob/master/patches/ctypes_init.diff#L1 | 15:43 |
| mvo | sergiusens: woah, you patch it inside the snap? | 15:44 |
| sergiusens | mvo: yes; ctypes works in a way that it finds libraries by doing an ldconfig -p | 15:45 |
| sergiusens | which means it will never pick libs in the snap | 15:45 |
| sergiusens | I need to upstream this in a sort of generic way into cpython | 15:45 |
| mvo | rbasak: I have not forgotten you, still poking at this | 15:58 |
| rbasak | No problem, thanks | 15:59 |
| mvo | rbasak: could you please try this low-tech "fix": http://paste.ubuntu.com/p/CZkGWz7dzm/ - snapcraft should patchelf gawk to look into core for its libs (cc sergiusens) | 16:07 |
| * mvo is off for a bit but will read backlog | 16:08 | |
| sergiusens | yeah, bundling gawk in the snap will fix it, certainly will be patched correctly too | 16:08 |
| sergiusens | this is however, a workaround to the core issue (oh a pun) | 16:09 |
| * zyga runs one more round of spread and goes to make something warm to drink | 16:11 | |
| zyga | Chipaca: I did not forget | 16:11 |
| zyga | I think I should just approve it and bikes head separately | 16:11 |
| roadmr | yum spread | 16:11 |
| zyga | yeah, we should add an RPM package | 16:12 |
| zyga | oh | 16:12 |
| zyga | drat, I forgot opensuse, I got my package in | 16:12 |
| zyga | I need to do some paperwork on ti | 16:12 |
| zyga | on *it | 16:12 |
| mup | PR snapcraft#2312 opened: meta: support relocatable prime for path verification (#2287) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2312> | 16:16 |
| rbasak | mvo: thanks! I created https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/355995 so I can get a CI run that will produce a test snap for me. Then I can test the generated snap manually for now. Is my commit message accurate? Separately I'll see about adding a test to ensure gawk works for CI in the future before landing it, but I thought I'd throw your patch at CI now to see if it works. | 16:19 |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | rbasak: I will write a followup on this, the commit message is mostly fine - I will suggest some tweaks (after dinner :) | 16:30 |
| Chipaca | zyga: *doubt* | 16:32 |
| zyga | ;-) | 16:34 |
| morphis | mvo: just found an issue where the systemd units generated by snapd for socket activation causes my system to not start NetworkManager on startup: https://forum.snapcraft.io/t/networkmanager-doesnt-start-anymore-on-a-fresh-ubuntu-system-after-installing-the-lxd-snap/7666 | 16:35 |
| zyga | Chipaca: review sent | 16:35 |
| Chipaca | wee | 16:36 |
| zyga | morphis: I think we dropped the online target | 16:36 |
| zyga | but we don't update existing units | 16:36 |
| zyga | we don't have code for that yet | 16:36 |
| morphis | zyga: I've installed the system a few hours ago so not sure if these are left over units | 16:37 |
| zyga | Chipaca: I revised the second comment | 16:37 |
| zyga | morphis: maybe that's 2.36 material | 16:37 |
| zyga | I recall seeing this land | 16:37 |
| zyga | I think we ought to think about doing that | 16:38 |
| zyga | but not sure how TBH | 16:38 |
| zyga | snapd starts up and decides to rewrite all the systemd units? | 16:38 |
| morphis | zyga: only bad thing about this is that it leaves my system starting up with no network, sounds pretty bad for unattended systems | 16:38 |
| zyga | no disagreement | 16:38 |
| Chipaca | zyga: what's your nitpick? | 16:39 |
| mup | PR snapd#5901 opened: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901> | 16:39 |
| Chipaca | zyga: I'm merging, but I can amend the comment in a followup :) | 16:39 |
| zyga | Chipaca: it's a placeholder for the eventual nitpick about avoiding O(N^2) | 16:39 |
| Chipaca | ah | 16:39 |
| zyga | but please merge | 16:39 |
| zyga | it's not a problem now | 16:39 |
| Chipaca | zyga: nor ever, because N<=10 | 16:39 |
| zyga | Chipaca: can I ask you to look at the principal idea behind https://github.com/snapcore/snapd/pull/5901 | 16:39 |
| Chipaca | :) | 16:39 |
| mup | PR #5901: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901> | 16:39 |
| Chipaca | muuurged! | 16:40 |
| mup | PR snapd#5891 closed: snap: give Epoch a CanRead helper <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5891> | 16:40 |
| zyga | that is use of major:minor numbers | 16:40 |
| zyga | feel free to postpone till tomorrow | 16:40 |
| zyga | Chipaca: the primary part of the change is https://github.com/snapcore/snapd/pull/5901/files#diff-4096bdaf9890161ea9c6e277d6ec7291R100 | 16:40 |
| zyga | + the commit message | 16:40 |
| zyga | and what is in the next hunk | 16:40 |
| zyga | rest is just tests and furnishing | 16:41 |
| Chipaca | zyga: allowed allowed | 16:43 |
| Chipaca | https://github.com/snapcore/snapd/pull/5901/files#diff-72963e5a6ac9e80f645d1c39c1a670d1R186 | 16:43 |
| mup | PR #5901: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901> | 16:43 |
| zyga | I shall fix fix | 16:43 |
| zyga | thanks! | 16:43 |
| Chipaca | wow, there's a lot of allowed allowed | 16:43 |
| Chipaca | a lot == at least 2 | 16:43 |
| * Chipaca skips ahead to the meat of the pr | 16:44 | |
| zyga | corrected locally | 16:45 |
| zyga | I'll push with any updates | 16:45 |
| zyga | mborzecki: I understand why the propagation failed | 16:46 |
| zyga | it didn't | 16:46 |
| zyga | it was a tricky test | 16:46 |
| zyga | I will explain tomorrow | 16:46 |
| zyga | but the good thing is, there are no bugs :) | 16:46 |
| zyga | well | 16:46 |
| zyga | it's still not what people may expect | 16:46 |
| zyga | and we can fix the sorting to perhaps handle that (I alluded to a better sort algorithm) | 16:46 |
| zyga | but it's not propagation | 16:47 |
| Chipaca | zyga: which was the syscall that qt started using that they didn't take the patch? | 16:47 |
| zyga | statx | 16:47 |
| Chipaca | zyga: ta | 16:47 |
| Chipaca | aw, no manpage on xenial | 16:47 |
| zyga | I'll make tea and see if my wife has any plum cake left | 16:47 |
| zyga | Chipaca: http://man7.org/linux/man-pages/man2/statx.2.html | 16:47 |
| Chipaca | teo | 16:48 |
| Chipaca | ta* | 16:48 |
| Chipaca | not sure what i tried to write there | 16:48 |
| Chipaca | zyga: when is .dev 0? | 16:50 |
| * ogra hugs jdstrand | 17:00 | |
| ogra | jdstrand, is it whitelisted too ? (i might need a few subsequent changes) | 17:01 |
| zyga | re | 17:02 |
| zyga | Chipaca: ha, in tests | 17:02 |
| zyga | that warrants a comment :) | 17:02 |
| zyga | I only added it so that we don't mistakenly use zero-valued struct data | 17:02 |
| Chipaca | zyga: yeh | 17:02 |
| Chipaca | zyga: otherwise, looks very sane | 17:02 |
| zyga | adding now | 17:02 |
| zyga | Chipaca: pushed | 17:06 |
| rbasak | mvo: the fix only half works. "gawk" now succeeds, but "awk" does not - since usr/bin/awk isn't provided in the snap (I wonder why) | 17:06 |
| rbasak | mvo: snap binary here: https://jenkins.ubuntu.com/server/view/git-ubuntu/job/git-ubuntu-ci/40/ | 17:07 |
| mup | Bug #1783772 changed: syslog error msgs when running 'snap list' on disabled daemon snap <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1783772> | 17:07 |
| rbasak | Chipaca: here's the snap refresh doc thing: https://paste.ubuntu.com/p/3pbYj7F9dQ/ | 17:08 |
| rbasak | Chipaca: from line 40 I expected refresh --list would work | 17:08 |
| Chipaca | rbasak: in what sense does it not work? | 17:08 |
| rbasak | "All snaps up to date." is not a list of available snaps for refresh | 17:09 |
| Chipaca | rbasak: or rather: what did you expect it would do? | 17:09 |
| rbasak | I expected it to do what "snap list --all git-ubuntu" does | 17:09 |
| rbasak | Show me the snaps I can refresh to | 17:09 |
| rbasak | (versions) | 17:09 |
| Chipaca | rbasak: how does --all show you what you can refresh to? | 17:09 |
| Chipaca | i mean, list --all | 17:09 |
| Chipaca | "snap list --all" shows you what you can revert to, if you want | 17:10 |
| rbasak | sudo snap refresh --revision=x1 git-ubuntu | 17:10 |
| rbasak | That works | 17:10 |
| Chipaca | sigh | 17:11 |
| rbasak | How is "All snaps to date." a list of snaps avialable for refresh? | 17:11 |
| Chipaca | rbasak: ok, try this | 17:11 |
| Chipaca | rbasak: snap switch core --edge | 17:11 |
| Chipaca | rbasak: snap refresh --list | 17:11 |
| rbasak | Oh, I see | 17:11 |
| rbasak | Snaps that would refresh if I ask for a refresh with no parameters? | 17:12 |
| Chipaca | or even by name | 17:12 |
| rbasak | I suppose the difference is that I can use refresh to switch channels and suchlike | 17:12 |
| Chipaca | so, clearly the doc needs work | 17:12 |
| rbasak | I probably conflate refresh, revert and switch | 17:13 |
| rbasak | And the CLI is happy to do what I mean | 17:13 |
| Chipaca | "List snaps that would be updated on the next refresh"? | 17:13 |
| rbasak | But that leads to confusion in understanding the docs | 17:13 |
| Chipaca | rbasak: conflating revert and refresh will lose you data :-/ | 17:13 |
| Chipaca | (per-revision data is assumed bad on revert, and left alone, whereas on refresh it's copied along) | 17:14 |
| Chipaca | revert is "omg these idiots broke it" | 17:15 |
| rbasak | The problem with revert is that it's a one time thing | 17:15 |
| rbasak | It's not necessarily obvious when it broke | 17:15 |
| rbasak | It might have been multiple refreshes ago | 17:15 |
| rbasak | Or at least it _seems_ like a one time thing to me | 17:15 |
| Chipaca | yes, the revert story isn't complete without health checks | 17:15 |
| Chipaca | (those are coming!) | 17:15 |
| rbasak | Whereas normally I end up having to "hunt" to get back to something working, as I don't necessarily know when it broke; rather all I have is a reproducer | 17:16 |
| * Chipaca nods | 17:16 | |
| Chipaca | which ties in with xnox's argument about foundations having to keep a copy of every revision of every snap ever | 17:16 |
| zyga | Chipaca: just share it on facebook | 17:17 |
| rbasak | Anyway, thank you for helping me understand better what I'm doing | 17:17 |
| Chipaca | I mean, I'm still not sure I agree, but I can see where he's coming from | 17:17 |
| Chipaca | rbasak: no problem! thank you for pointing out where things are unclear / surprising | 17:17 |
| rbasak | We keep a copy of every deb we published ever. It's particular useful when debugging broken upgrade paths, etc. | 17:18 |
| rbasak | snap refresh --list git-ubuntu | 17:19 |
| rbasak | All snaps up to date. | 17:19 |
| zyga | hmm? | 17:20 |
| zyga | rbasak: what were you hoping to see? | 17:20 |
| zyga | rbasak: note that the store keeps a copy of every revision | 17:20 |
| rbasak | Perhaps this is the particular case that's confusing? "All" doesn't make sense here. "This snap is up to date." would perhaps be clearer in hinting to me what the command actually does. | 17:20 |
| Chipaca | mmmm | 17:20 |
| Chipaca | this one might be even more interesting | 17:20 |
| rbasak | Hard to translate possibly though | 17:20 |
| rbasak | (for i8n etc) | 17:20 |
| Chipaca | rbasak: if --list is given, the argument is ignored completely | 17:21 |
| Chipaca | I'd posit that that's a bug :-) | 17:21 |
| rbasak | Ah. Yes :) | 17:21 |
| Chipaca | either error, or filter | 17:21 |
| Chipaca | hmmm hmmm | 17:21 |
| Chipaca | i'll error for now (making it filter would be either client-side (ew), or a lot of work on the daemon (ugh)) | 17:24 |
| Chipaca | TBF --list is one of the weird ones that we're pretty sure doesn't "go" there (like --times), but we haven't found the right place yet | 17:27 |
| Chipaca | rbasak: are you rbasak on github as well? | 17:34 |
| rbasak | Chipaca: no, "basak" | 17:35 |
| Chipaca | k | 17:35 |
| rbasak | Chipaca: how about --dry-run or similar, instead of --list? | 17:36 |
| rbasak | The same information, but from a "what I would do" perspective which is easier semantically I think since that concept is pretty common rather than being snap-specific. | 17:37 |
| Chipaca | rbasak: I'm used to --dry-run and it feels more natural to me, but the output would be wrong (unless refresh did the same) | 17:37 |
| Chipaca | … or does it | 17:37 |
| * Chipaca hasn't looked at 'refresh' in a while :) | 17:37 | |
| rbasak | I don't expect --dry-run to produce exactly the same output | 17:37 |
| rbasak | But I understand why others might | 17:37 |
| Chipaca | I like rename's behaviour of --dry-run being --verbose | 17:39 |
| Chipaca | OTOH, we _could_ write a --dry-run that just printed nearly the same as a plain refresh, but with "would be updated" instead of "updated" | 17:39 |
| Chipaca | er, refreshed | 17:39 |
| Chipaca | core (edge) 16-2.35.2+git954.b1b6b89 from Canonical✓ available for refresh | 17:40 |
| Chipaca | that sort of thing | 17:40 |
| Chipaca | all the info you want is there | 17:40 |
| Chipaca | hmm | 17:40 |
| Chipaca | niemeyer: you around? | 17:40 |
| mup | PR snapd#5902 opened: cmd/snap: tweak UX of snap refresh --list <Created by chipaca> <https://github.com/snapcore/snapd/pull/5902> | 17:41 |
| Chipaca | rbasak: ^ | 17:41 |
| rbasak | Thanks! | 17:42 |
| Chipaca | niemeyer: what do you think of moving from 'snap refresh --list' with its 'snap list'-like output (that's slightly alien-feeling), to a 'snap refresh --download' that would print summaries very similar to what 'snap refresh' actually does? | 17:43 |
| Chipaca | er | 17:44 |
| Chipaca | er | 17:44 |
| Chipaca | niemeyer: snap refresh --dry-run | 17:44 |
| Chipaca | brain fart there | 17:44 |
| Chipaca | clearly i should eod | 17:44 |
| mvo | rbasak: does https://forum.snapcraft.io/t/git-ubuntu-issue-with-core-2-35-2/7668 clarify things? I tried to summarize the issue we hit, I hope this also answers your question in the commit messages | 17:53 |
| niemeyer | Chipaca: No problem, happy to help-by-listening :) | 17:54 |
| Chipaca | niemeyer: question stands though :-) | 17:55 |
| Chipaca | niemeyer: 'snap refresh --list' is a bit weird, why isn't it 'snap refresh --dry-run'? | 17:55 |
| mvo | rbasak: re gawk> awk is "special" in that it does not ship a awk binary but only a postrm script that uses update-alternatives. let me look into this again | 17:56 |
| mvo | rbasak: I pushed an alternative PR | 18:02 |
| rbasak | mvo: thanks! Will read. | 18:03 |
| mvo | rbasak: let me know if anything is unclear, its an unfortunate combination of classic, update-alternatives etc | 18:11 |
| rbasak | mvo: that's clear, thanks. I need to EOD now. I'll resume tomorrow. Meanwhile your branch/MP is building a test snap in CI. | 18:17 |
| jdstrand | ogra: part of it has a snap decl. the other part is committed in the review-tools but is not in prod yet | 18:19 |
| jdstrand | roadmr: hi! at whatever time is convenient, can you pull r1131? | 18:19 |
| mvo | rbasak: ta | 18:27 |
| mvo | rbasak: enjoy your eod | 18:27 |
| mup | PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 18:30 |
| mup | PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 18:30 |
| mup | PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 18:30 |
| mup | PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 18:31 |
| mup | PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 18:31 |
| mup | PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 18:31 |
| mup | PR snapcraft#2311 closed: snap: legacy needs to now it is legacy for re-exec <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2311> | 18:43 |
| zyga | re | 19:08 |
| roadmr | jdstrand: sure thing | 19:09 |
| zyga | jdstrand: hey | 19:10 |
| zyga | jdstrand: I have two pings for you: one is a quick look on a "input" trigger on udev on an upcoming interface: https://github.com/snapcore/snapd/pull/5897 | 19:10 |
| mup | PR #5897: interfaces/builtin: add gpio-keys interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897> | 19:10 |
| zyga | jdstrand: and another is extension of the tmpfs detector for sub-directory support https://github.com/snapcore/snapd/pull/5901 | 19:11 |
| mup | PR #5901: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901> | 19:11 |
| zyga | nothing urgent | 19:11 |
| zyga | jdstrand: the detector is mostly test changes, look at the non-test part of the patch to see what the interesting thing is, I also tried to make the commit message as useful as I could | 19:11 |
| zyga | that's all, enjoy your work on the road | 19:12 |
| zyga | Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, '(ssssa{ss})', does not match expected type '(sssa{sv}a{ss})' | 19:14 |
| zyga | another case of that | 19:14 |
| zyga | well, for tomorrow | 19:14 |
| * zyga EODs | 19:14 | |
| mup | PR snapcraft#2312 closed: meta: support relocatable prime for path verification (#2287) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2312> | 19:58 |
| mup | PR snapcraft#2305 closed: [legacy] pluginhandler: update build should overwrite organize <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2305> | 20:01 |
| mup | PR snapcraft#2313 opened: meta: link the icon correctly across filesystems <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2313> | 20:25 |
| sergiusens | Saviq: want to give that a review? ^ | 20:26 |
| koala_man | what are my options if I'm unable to reproduce a build failure locally? | 20:27 |
| ogra | koala_man, how do you not reproduce it locally ? ... did you use snapcraft cleanbuild to do so ? | 21:00 |
| koala_man | Yes. Is the intention that this type of build uses the same kinds of http proxies? | 21:01 |
| ogra | no, the intention is that you use the same container setup the builders use | 21:04 |
| ogra | not necessarily the proxies | 21:04 |
| ogra | does your build fail with a proxy error ? | 21:04 |
| koala_man | it fails on 'cabal update' which is supposed to download an index of haskell packages | 21:05 |
| koala_man | I'm not sure how to debug it since it works locally, or how to try any random suggestions without pushing junk commits | 21:09 |
| ogra | open a forum thread and attach a build log (or a link to a pastebin with a build log) | 21:10 |
| ogra | (see the topic for the forum link) | 21:11 |
| ogra | if it locally also works when using snapcraft cleanbuild, there is surely somthign wrong | 21:11 |
| ogra | typically cleanbuild shows the same errors as the builders and most of the time this points to some missing build-packages entry ... i.e. if you would download something using wget during your build but did not define wget in your build-packages it will fail in cleanbuild | 21:17 |
| ogra | or on the build host | 21:17 |
| ogra | but it wouldnt fail on your desktop because you have wget already installed | 21:18 |
| ogra | this is why i initially asked if you tried cleanbuild | 21:18 |
| cjwatson | maybe cabal doesn't honour the usual proxy environment variables | 21:28 |
| koala_man | It does. I googled it for a while and found some misc older bugs, but nothing concrete and it's hard to test anything | 21:31 |
| cjwatson | do you have a link to a failing build? | 21:31 |
| koala_man | here's one with cabal update -v3: https://build.snapcraft.io/user/koalaman/shellcheck/345086 | 21:32 |
| koala_man | at least I think that's the failing command. | 21:33 |
| cjwatson | https://launchpadlibrarian.net/391408584/buildlog_snap_ubuntu_xenial_amd64_0dfd7b5345eb70630bdf6240b06280c5-xenial_BUILDING.txt.gz <- direct link | 21:36 |
| cjwatson | koala_man: Could you please file a bug on https://bugs.launchpad.net/launchpad-buildd about that? Not something I've seen before. | 21:37 |
| koala_man | sure | 21:38 |
| cjwatson | Certainly something odd there, as it claims to be sending GET http://hackage.haskell.org/packages/index.tar.gz but there's no corresponding log message from the internal proxy. | 21:40 |
| cjwatson | Nor from the backend proxy (in our private logs). | 21:42 |
| cjwatson | Chances are it's a bug in the internal proxy in launchpad-buildd, since that's the least well-tested code involved, but it's a surprise that this is the first place I've seen it. | 21:44 |
| cjwatson | Looks very reproducible given the appropriate setup though, so that'll help. | 21:45 |
| mup | PR snapd#5903 opened: overlord/snapshotstate: store epoch in snapshot, check on restore <Created by chipaca> <https://github.com/snapcore/snapd/pull/5903> | 23:29 |
| === genii is now known as Barista | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!