| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1393 opened: python plugin: output json in pip list <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1393> | 04:11 |
|---|---|---|
| mup | PR snapd#3564 opened: tests: speedup prepare statement part 1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3564> | 05:05 |
| === mjl_ is now known as mjl | ||
| === stokachu_ is now known as stokachu | ||
| === cargonza_ is now known as cargonza | ||
| === oh4_ is now known as oh4 | ||
| === souther_ is now known as souther | ||
| mup | PR snapd#3561 closed: tests: store /etc/systemd/system/snap-*core*.mount in snapd-state.tar.gz <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3561> | 07:24 |
| mup | PR snapd#3563 closed: release: merge release/2.26 branch back into master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3563> | 07:24 |
| mup | PR snapcraft#1394 opened: tests: document the test suites in the snapcraft repo <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1394> | 07:26 |
| zyga | re | 07:29 |
| mup | PR snapd#3551 closed: systemd, osutil: rework systemd logs in preparation for services commands <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3551> | 07:37 |
| mup | PR snapd#3504 closed: interfaces: bring back seccomp argument filtering <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3504> | 07:42 |
| mvo | a second review for 3501 would be great, looks very straightforward | 07:43 |
| mvo | zyga: maybe 3491 is sometihng that you could review? just needs a second review | 07:45 |
| morphis | morning! | 07:46 |
| zyga | mvo: certainly, with pleasure | 07:46 |
| mvo | hey morphis | 07:47 |
| mvo | zyga: thank you! | 07:47 |
| morphis | zyga, mvo: how was the sprint last week? | 07:48 |
| zyga | morphis: very productive | 07:48 |
| zyga | morphis: but also some bugs interfered | 07:49 |
| morphis | oh bad | 07:50 |
| morphis | zyga: still for the 2.26 release? | 07:50 |
| zyga | morphis: indeed | 07:51 |
| morphis | I guess you had a lot fun last week :-) | 07:51 |
| mvo | morphis: *cough* | 07:54 |
| mvo | fgimenez: snapd 2.26.8 is now also -proposed everywhere and ready for SRU testing | 07:55 |
| fgimenez | mvo: great thanks, on it, we should have proper detection now on spread-cron, could you please check the date the tests were triggered? https://travis-ci.org/snapcore/spread-cron/builds/250440323 | 07:59 |
| mvo | fgimenez: 14h ago sounds about right | 08:02 |
| zyga | mvo, pstolowski: reviewed https://github.com/snapcore/snapd/pull/3491#pullrequestreview-48258965 | 08:03 |
| mup | PR snapd#3491: snapd: generate snap cookies on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/3491> | 08:03 |
| pstolowski | zyga, thanks! | 08:05 |
| fgimenez | mvo: cool thx | 08:06 |
| mup | PR snapd#3565 opened: cmd/snap-repair: skeleton code around actually running a repair <Created by pedronis> <https://github.com/snapcore/snapd/pull/3565> | 08:31 |
| pedronis | mvo: hi, this ^ is the last of a chain, it has some skeleton code (similar to what you had in one of your branches) about where actually running the repair could happen | 08:32 |
| mvo | pedronis: nice, thank you! | 08:33 |
| pedronis | mvo: I have a wip branch with code to actually verify the signature of the repair, anyway that plugs in one of the previous pieces in the chain where there's a todo | 08:34 |
| mvo | pedronis: ok, I need to tie up some loose ends and then I can jump on it | 08:35 |
| pedronis | mvo: it's quite a bit of code in those PRs :/ the fetching is a bit complicated | 08:36 |
| mvo | pedronis: yeah, I noticed, I peeked over them already (but not review carefully yet) | 08:37 |
| pedronis | mvo: anyway mostly saying, getting those pieces into shape for landing or changing as needed, running and small TODOs in those branches should be all things that can be worked on while I'm of, verification is probably something that I can pick up again when I'm back, anyway the server bits still needs a bit more work too | 08:39 |
| pedronis | mvo: so as I said in the standup, depending on timings, 2.28 or 2.29 are probably more realistic goals to get this all pieced together | 08:40 |
| pedronis | mvo: btw about file names etc, I'm following the current stuff in "transparent" section of the forum topic | 08:42 |
| pedronis | if we change those we should change the topic as well | 08:42 |
| mvo | pedronis: ok, sounds good | 08:43 |
| pedronis | mvo: sorry for the info dump, but I'm off a bit this afternoon as I said, and you are taking tomorrow off? | 08:44 |
| mvo | pedronis: correct | 08:45 |
| mvo | pedronis: no need to be sorry, I appreciate the update :) | 08:45 |
| pedronis | mvo: I migtht also get a PR up, today or tomorrow about reading brand/model out of the seed/assertions data, haven't started yet though and want to work also on something else | 08:47 |
| pedronis | unrelated to repairs | 08:47 |
| mvo | ta | 08:48 |
| pedronis | I'll put a link in the forum if I get to it | 08:49 |
| pedronis | (the other PRs are also already linked from there) | 08:49 |
| zyga | mvo, pstolowski: trivial and long overdue https://github.com/snapcore/snapd/pull/3566 | 08:52 |
| mup | PR snapd#3566: interfaces: fix copy-pasted iio vs io in io-ports-control <Created by zyga> <https://github.com/snapcore/snapd/pull/3566> | 08:52 |
| mup | PR snapd#3566 opened: interfaces: fix copy-pasted iio vs io in io-ports-control <Created by zyga> <https://github.com/snapcore/snapd/pull/3566> | 08:53 |
| pstolowski | zyga, looks good, but I think the test file has the same issue? s/iio/io there too? | 08:54 |
| zyga | pstolowski: which one? | 09:00 |
| zyga | pstolowski: I only see iio_* files having iio identifiers | 09:00 |
| pstolowski | zyga, io_ports_control_test.go has Iio* | 09:01 |
| zyga | ah, I didn't look for Iio :) | 09:01 |
| zyga | thanks | 09:01 |
| zyga | fixed | 09:01 |
| zyga | pushed | 09:02 |
| pstolowski | thanks | 09:02 |
| pstolowski | +1 | 09:05 |
| mup | PR snapd#3518 closed: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3518> | 09:24 |
| fgimenez | mvo: zyga i'm getting an error on trusty when trying to install core from beta http://paste.ubuntu.com/25031042/ | 09:36 |
| zyga | fgimenez: looking | 09:38 |
| mvo | fgimenez: what version of libseccomp do you have installed in that machine? is it the latest from -updates? | 09:38 |
| Chipaca | pedronis: is there a sorting requirement for a series? | 09:38 |
| zyga | interesting | 09:38 |
| zyga | mvo: missing dep on snapd? | 09:39 |
| Chipaca | pedronis: that is, in “series, err := stringList(headers, "series")”, can series be assumed sorted? | 09:39 |
| zyga | mvo: thread synchronization is a feature that was not originally in the distro | 09:39 |
| pedronis | Chipaca: not atm | 09:39 |
| fgimenez | mvo: let me check | 09:39 |
| Chipaca | pedronis: aw | 09:40 |
| pedronis | Chipaca: I think it's also fair to assume there's not bazillion of them | 09:40 |
| Chipaca | pedronis: was hoping we could drop one of the implementations of inStringList | 09:40 |
| Chipaca | :-) | 09:40 |
| pedronis | Chipaca: I suppose we have copies of two ? (sorted and unsorted) | 09:40 |
| pedronis | time to put those into strutil? | 09:41 |
| Chipaca | yeah | 09:41 |
| Chipaca | pedronis: and there's testutils's Contains, just for extra fun | 09:41 |
| Chipaca | testutil's* | 09:41 |
| pedronis | test and prod should not meet :) | 09:41 |
| pedronis | or something | 09:41 |
| fgimenez | mvo: http://paste.ubuntu.com/25031072/, libseccomp2 is at 2.1.1-1ubuntu1~trusty3 | 09:42 |
| * zyga hugs contains | 09:42 | |
| Chipaca | pedronis: yeah, testutil's is all about reflect :-) | 09:43 |
| mvo | fgimenez: this looks good, how strange | 09:44 |
| mvo | fgimenez: how strange - those tests passed in linode/spread | 09:45 |
| mvo | fgimenez: aha, what kernel is running? | 09:45 |
| fgimenez | mvo: for the sru validation we install the package from the archive, it's the only difference afaict | 09:45 |
| fgimenez | mvo: 4.4.0-85-generic from snap version | 09:46 |
| mvo | fgimenez: what does uname -r tell you? | 09:46 |
| fgimenez | mvo: same, 4.4.0-85-generic | 09:47 |
| mvo | fgimenez: confusing, I have a look | 09:47 |
| fgimenez | mvo: i can prepare a tunnel if you want to log in the machine | 09:47 |
| mvo | fgimenez: I start with my local vm | 09:48 |
| mvo | fgimenez: but thank you | 09:48 |
| fgimenez | mvo: great thanks | 09:48 |
| zyga | mvo: it does look good "on paper" | 09:48 |
| pedronis | Chipaca: I see for 4 "contains" around, so maybe indeed worth a look | 09:48 |
| mvo | zyga: what exactly :) the kernel version? or the code? or sometihng-else? | 09:49 |
| pedronis | Chipaca: seems a its own branch thing though | 09:50 |
| Chipaca | totz | 09:50 |
| * pedronis lunch | 09:50 | |
| Chipaca | pedronis: which are the four? I see this new "inStringList", overlord/snapstate's contains, and one contains in interfaces/policy/basedeclaration_test | 09:51 |
| Chipaca | this is studiously ignoring the one in testutil ;-) | 09:51 |
| Chipaca | and vendor obvs | 09:51 |
| pedronis | there are some that are even declared locally | 09:51 |
| pedronis | ./partition/grubenv/grubenv.go:var contains = func(needle string, haystack []string) bool | 09:52 |
| pedronis | ./daemon/api.go:contains := func(needle string, haystack []string) bool { | 09:52 |
| pedronis | as well | 09:52 |
| Chipaca | ah | 09:52 |
| pedronis | and haven't looked to hard with things name like my in* | 09:52 |
| pedronis | *too hard for things* | 09:53 |
| Chipaca | my grep was looking for ^func :-) | 09:53 |
| * Chipaca tries harder | 09:53 | |
| * pedronis really lunch | 09:53 | |
| pedronis | Chipaca: that's not the full story(tm) :) | 09:53 |
| fgimenez | mvo: zyga for reference these are all the steps taken during sru validation for putting the snapd package in place https://github.com/snapcore/snapd/blob/release/2.26/tests/lib/apt.sh#L15 we begin from the package in updates, then add the proposed pocket and upgrade snapd from it | 09:54 |
| Chipaca | 3× unsorted, 1× sorted | 09:58 |
| Chipaca | I'll add strutil.ListContains and strutil.SortedListContains | 09:58 |
| zyga | re! | 10:00 |
| zyga | ha | 10:00 |
| zyga | stupid orange modem | 10:00 |
| mvo | fgimenez: I can reproduce the issue on 14.04 | 10:02 |
| * zyga tries one more thing with his network | 10:05 | |
| Chipaca | zyga: Wat heb je tegen het Huis van Oranje? | 10:08 |
| Chipaca | zyga: (or something) | 10:08 |
| === ahrs_ is now known as ahrs | ||
| zyga | maybe this will hold, for now | 10:24 |
| pstolowski | mvo, do you know from top of your head where do we set refresh.schedule to 0 in our tests? (it's also possible we don't actually do this and I've a bug in my branch) | 10:49 |
| pstolowski | i couldn't find any explicit assignment, so perhaps it's set automagically somewhere | 10:51 |
| * pstolowski lunch | 10:54 | |
| mup | PR snapd#3566 closed: interfaces: fix copy-pasted iio vs io in io-ports-control <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3566> | 10:56 |
| mvo | pstolowski: iirc this is just the default value | 10:57 |
| mup | PR snapd#3553 closed: interfaces: enable access to bridge settings <Created by coreycb> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3553> | 10:57 |
| mup | PR snapd#3555 closed: assserts,overlord/assertstate: test we don't accept chains of assertions founded on a self-signed key coming externally <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3555> | 11:00 |
| zyga | mvo: any idea about 14.04 error? | 11:02 |
| zyga | mvo: is that on 3.13 or on the LTS kernel? | 11:03 |
| mvo | zyga: I can reproduce it on the lts kernel - but only with snap install --beta core - not with the stable core | 11:03 |
| zyga | mvo: hum hum hum | 11:03 |
| zyga | mvo: so does it indicate we are using a new version/feature/code branch in libseccomp? | 11:04 |
| zyga | mvo: when I was diffing libseccomp at the sprint I did see tsync patches | 11:04 |
| pedronis | pstolowski: there are lines doing snap set core refresh.* = ... in prepare.sh ? do you mean something else? | 11:04 |
| pedronis | pstolowski: ah, you meant unit tests? | 11:06 |
| mvo | zyga: I'm not sure what it means yet unfortunately. maybe a missing patch in the libseccomp backport for trusty | 11:20 |
| ogra_ | WTF! | 11:31 |
| ogra_ | ppisati, something does always release the unusable newer kernel to stable, only you, me, the kernel team and mvo have access | 11:32 |
| ogra_ | i dont get how that happens, is the kernel team running any scripts ? | 11:32 |
| ogra_ | (this is the third time i had to roll back the snap) | 11:33 |
| * ogra_ talks about pi2-kernel here | 11:34 | |
| ppisati | ogra_: yep, you me and my team | 11:35 |
| ppisati | ogra_: i guess someone inside my team is doing it, though it shouldn't go to -stable | 11:35 |
| ppisati | ogra_: but unusable why? | 11:35 |
| ppisati | ogra_: for the dtb relocation? | 11:35 |
| ogra_ | ppisati, because the dtb we ship in the gadget doesnt boot with anything newer than rev 22 of the pi2-kernel snap | 11:36 |
| ogra_ | only the gadget updates implementation will fix that ... but thats still far out | 11:36 |
| ppisati | ogra_: ok, let me work it out | 11:37 |
| ogra_ | (we cant update the dtb on disk of users yet .... so we're stuck with the kernel revision the first stable image had) | 11:37 |
| ogra_ | ppisati, thanks | 11:37 |
| ogra_ | i hope it at least rolls back properly ... :) | 11:37 |
| * ogra_ never runs stable ... | 11:38 | |
| ppisati | ogra_: so, the kernel snap creation script automatically pushes the kernel to "candidate, beta" | 11:38 |
| ppisati | https://code.launchpad.net/~ubuntu-kernel/+snap/pi2-kernel | 11:38 |
| ogra_ | thats fine | 11:38 |
| ppisati | so, someone else is moving it to -stable | 11:38 |
| ogra_ | could also push to edge if you feel like | 11:38 |
| ppisati | let me find my whip and this guy | 11:38 |
| ogra_ | :) | 11:39 |
| ogra_ | ppisati, since we're just talking ... i'll likely need a fix in the vc4 setup ... seems loading the overlay dtb for it breaks the kernels "simple framebuffer" ... using something that writes to /dev/fb0 directly with that overlay loaded makes the board hang hard (see my last comment on bug 1701018 ) | 11:42 |
| mup | Bug #1701018: Splash screen is not enabled in kernel <Snappy:New> <https://launchpad.net/bugs/1701018> | 11:42 |
| ogra_ | might be that https://github.com/raspberrypi/firmware/issues/597 is related ... there seems to be a dtb fix | 11:44 |
| ppisati | ogra_: "psplash only works with a working simple framebuffer driver, so this option needs to be disabled" | 11:57 |
| ppisati | ogra_: FB_SIMPLE (the simple-framebuffer kernel driver) is already off, because if i turn it on, it'll attach (and screw actually) to the simple-framebuffer DT node, injected by u-boot | 11:57 |
| ogra_ | ppisati, well, somehow vc4 breaks fb0 ... and i see a patch (added a link to the bug) | 11:59 |
| ogra_ | there seems to be a corresponding u-boot dt change too though | 11:59 |
| ppisati | ogra_: what does vc4-kms-v3d do? | 12:00 |
| ogra_ | turn on vc4 acceleration | 12:00 |
| ogra_ | it is needed for GLES and mir-kiosk | 12:00 |
| ppisati | ogra_: ok, is there a way for me to test if this acceleration is on? | 12:00 |
| ogra_ | ppisati, use an ubuntu core image, we have it on by default there | 12:01 |
| ogra_ | beyond that, just set the option in your config.txt on a classic install ... should do the same | 12:01 |
| ppisati | ogra_: but if we already have this acceleration on, why do we need this vc4-kms-v3d overlay? | 12:02 |
| ogra_ | no | 12:02 |
| ogra_ | we have the overlay loaded by default | 12:02 |
| ogra_ | (which turns it on) | 12:03 |
| ogra_ | without the dtbo you dont have any acceleration | 12:03 |
| ppisati | ogra_: uhm, ok | 12:04 |
| ogra_ | i havent seen any prrobs with it yet until i tried to use psplash on it ... (psplash works fine on all other boards) | 12:04 |
| pedronis | Chipaca: thanks for the reviews btw, bit surprised the Next one didn't get any extra comments :) | 12:04 |
| pedronis | Chipaca: mvo: as I mentioned yesterday, going to be off for some hours from now, so no standup for me today | 12:05 |
| mvo | pedronis, Chipaca: thanks for the notification. I may also not make it today, a repairman is scheduled for this afternoon and the time is a bit uncertain | 12:07 |
| Chipaca | pedronis: hrm, maybe i missed something? :-) | 12:15 |
| jdstrand | mvo: I'm not familiar with the 'tsync bit' error. It seems to be a libseccomp-golang thing though: https://github.com/seccomp/libseccomp-golang/blob/master/seccomp.go#L497 | 12:25 |
| jdstrand | mvo: strike that. I see libseccomp-golang give that error string, but libseccomp does reference tsync | 12:27 |
| jdstrand | mvo: I did see this: https://github.com/seccomp/libseccomp/issues/20 | 12:28 |
| jdstrand | mvo: which may me wonder if libseccomp on trusty is built with a 3.13 kernel (as opposed to lts kernel), perhaps it isn't being built with tsync support | 12:29 |
| jdstrand | mvo: (guess) | 12:29 |
| jdstrand | mvo: I then saw https://github.com/seccomp/libseccomp/commit/a1f144a9a28aa1b831f7d3f481fb3e0e5e3de3aa | 12:30 |
| jdstrand | "The seccomp() syscall was first added in Linux 3.17 so most systems | 12:30 |
| jdstrand | should now support this syscall. Most importantly, the use of the | 12:30 |
| jdstrand | seccomp() syscall enabled the thread sync functionality which isn't | 12:30 |
| jdstrand | possible with prctl(); although callers still need to enable the flag | 12:30 |
| jdstrand | per-filter as the thread sync default is disabled." | 12:30 |
| jdstrand | mvo: with snap-seccomp, we moved to prctl | 12:31 |
| pstolowski | pedronis, mvo thanks, it was about spread tests and refresh schedule | 12:32 |
| jdstrand | mvo: maybe if we appropriately used the seccomp syscall, this would resolve itself? | 12:32 |
| mvo_ | jdstrand: sorry, disconnected, you mean use seccomp() instead of prctl() ? | 12:33 |
| jdstrand | mvo_: yes. let me give you full context | 12:33 |
| pstolowski | mvo, pedronis with my changes wrt json decoding it now requires " to be escaped around timestamp, otherwise it treats it as number taking leading 0 ang ignoring the rest :( | 12:33 |
| pstolowski | mvo_, pedronis has to do with shell eating quotes I suppose | 12:34 |
| pstolowski | mvo_, pedronis so snap set core refresh.schedule="0:00-23:59" needs to be snap set core refresh.schedule=\"0:00-23:59\" | 12:34 |
| jdstrand | mvo_: http://paste.ubuntu.com/25031898/ | 12:34 |
| pstolowski | bummer | 12:34 |
| mvo_ | jdstrand: aha, thank you - yes, I have a look | 12:36 |
| jdstrand | mvo_: fingers crossed :) | 12:36 |
| mvo_ | pstolowski: oh, nice find | 12:36 |
| pstolowski | mvo_, well, it's *after* my changes | 12:38 |
| jdstrand | mvo_: I'm not sure if this will be needed for libseccomp on trusty: https://github.com/seccomp/libseccomp/commit/08a682a9f895b8f622499df5ee69fcabe1e3cbab | 12:39 |
| jdstrand | (but not sure if naively applying that would cause problems for libseccomp with non-lts kernel) | 12:40 |
| mvo_ | jdstrand: hm, indeed, it sounds slightly dangerous | 12:40 |
| jdstrand | mvo_: actually, if you are calling the seccomp syscall directly, you aren't using libseccomp, so that should be needed | 12:40 |
| mvo_ | jdstrand: shouldor should not? | 12:41 |
| jdstrand | I guess we'll need to see what libseccomp-golang ends up doing if you use seccomp syscall instead of prctl | 12:41 |
| pstolowski | mvo_, this is bad, becase it means it may break for people on their variables if they start with a number (one such case is also in our tests - an IP address) | 12:41 |
| jdstrand | mvo_: heh, shoud *not* | 12:41 |
| jdstrand | sould* | 12:41 |
| jdstrand | argh | 12:41 |
| mvo_ | jdstrand: :) no worries | 12:41 |
| jdstrand | s h o u l d n o t | 12:41 |
| jdstrand | :) | 12:41 |
| mvo_ | jdstrand: lol | 12:41 |
| jdstrand | I'm not using my external keyboard atm. I'll blame that | 12:42 |
| jdstrand | my laptop keyboard likes to occasionally drop entire words | 12:43 |
| jdstrand | :) | 12:43 |
| zyga | jdstrand: o/ | 12:45 |
| zyga | jdstrand: interesting observation on prctl vs seccomp syscall (darn flags) | 12:46 |
| * zyga thinks about skipping standup and having lunch instead | 12:47 | |
| zyga | jdstrand: is it possible that cat /sys/kernel/security/apparmor/policy/*/raw_data truncates stuff? | 12:47 |
| zyga-suse | mvo_: is this sensbile? pastebin.ubuntu.com/25031983/ | 12:51 |
| mvo_ | zyga-suse: hm, with the latest master this shoudl be fixed | 12:51 |
| mvo_ | zyga-suse: is our branch current? | 12:51 |
| zyga | mvo_: this is from https://github.com/snapcore/snapd/pull/3531 (10 days ago) | 12:54 |
| mup | PR snapd#3531: interfaces: updates default, mir, optical-observe, system-observe, screen-inhibit-control and unity7 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3531> | 12:54 |
| mvo_ | zyga: it just needs master | 13:00 |
| mvo_ | niemeyer: sorry, I miss standup, there is a repairman at the door | 13:00 |
| niemeyer | mvo_: np, thanks for the note | 13:00 |
| jdstrand | zyga: I am not familiar with those interfaces. curious why you a playing with them, but jjohansen would be the person to ask | 13:08 |
| ogra_ | ppisati, did you see bug 1691729 ... seems a few classic users have actual probs with it | 13:09 |
| mup | Bug #1691729: linux-firmware-raspi2 conflicts with linux-firmware over brcmfmac43430-sdio.bin <linux-firmware-raspi2 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1691729> | 13:09 |
| zyga | jdstrand: I can give you some advice but I already spoke with jj about that | 13:11 |
| jdstrand | zyga: is this for a pending PR? | 13:18 |
| ppisati | ogra_: added to my list - i think that is the bluetooth fw | 13:20 |
| ogra_ | ah | 13:21 |
| zyga | jdstrand: more like bug hunting | 13:26 |
| jdstrand | I see | 13:26 |
| zyga | jdstrand: trying to figure out why people bump into the issue with snap-confine using old profile | 13:26 |
| jdstrand | zyga: talked to jj about truncating possiblility. I would think 'no' but that is based on nothing :) | 13:26 |
| zyga | jdstrand: and one case where it seems profiles are in wonky state and only work after re-loading by hand | 13:26 |
| jdstrand | ah that | 13:27 |
| * zyga learned x10 more about how apparmor works in the last week | 13:27 | |
| ogra_ | volunteering for the security team ? | 13:28 |
| ogra_ | :) | 13:28 |
| jdstrand | zyga: I'm not saying this is it, but keep in mind when the cache file is used and when it isn't | 13:28 |
| jdstrand | zyga: it is possible to get into situations where an old cache file is loaded into the kernel, then the thing runs with it, then it is loaded/updated later | 13:29 |
| jdstrand | so at debug time, everything looks ok, but at the moment of the access, the old cache was in place | 13:30 |
| jdstrand | this is just general advice not anything specific to what you are doing | 13:30 |
| jdstrand | also, with snapd deciding which snap-confine and which profile to use, that could get even more interesting | 13:31 |
| mup | PR snapd#3567 opened: many: introduce and use strutil.ListContains <Created by chipaca> <https://github.com/snapcore/snapd/pull/3567> | 13:33 |
| zyga | jdstrand: yes, that's a good point, cache is bypassed when we upgrade packages | 13:33 |
| zyga | jdstrand: but we write to the cache in that case | 13:33 |
| jdstrand | if I were debugging this, I would try to trace the whole process from boot to denial to debug time. tracing for when apparmor unit loads the profile, when snap-confine runs at all, what profile it is running under, the cache mtimes vs profile mtimes at time you run apparmor_parser, etc | 13:36 |
| zyga | jdstrand: I'd love to see this reproduced first | 13:36 |
| jdstrand | oh still no reproducer. that is unfortunate to say the least | 13:36 |
| zyga | yes | 13:36 |
| zyga | so working "dry" | 13:37 |
| zyga | and reading binary profiles | 13:37 |
| zyga | (very interesting btw) | 13:37 |
| jdstrand | but if your tracing is in place, maybe you can see a potential race | 13:37 |
| jdstrand | zyga: (also what options are being used with apparmor_parser whenever it is called) | 13:39 |
| niemeyer | pstolowski, zyga: This is the issue: https://play.golang.org/p/qyx_D3F-DO | 13:40 |
| zyga | jdstrand: -T -W | 13:40 |
| niemeyer | pstolowski: When you use a decoder, it handles the input as a stream | 13:41 |
| pstolowski | niemeyer, aaah! | 13:41 |
| zyga | niemeyer: WAT? | 13:41 |
| zyga | niemeyer: ah | 13:41 |
| niemeyer | pstolowski: It's decoding the first integer, and waiting for instructions | 13:41 |
| pstolowski | niemeyer, indeed... | 13:42 |
| zyga | so all we have to do is to ensure we reached end of the input | 13:42 |
| jdstrand | zyga: I meant as part of the tracing exercise (if you are going to do that). seeing the arguments that are actually being used rather than what you expect them to use | 13:43 |
| Chipaca | pedronis: i couldn't resist and threw together snapd#3567 | 13:44 |
| mup | PR snapd#3567: many: introduce and use strutil.ListContains <Created by chipaca> <https://github.com/snapcore/snapd/pull/3567> | 13:44 |
| zyga | jdstrand: interesting, I'll patch my system to log apparmor_parser invocations | 13:44 |
| zyga-suse | travis seems to have network hicckups | 13:59 |
| zyga-suse | spread times out on snapd downloads with speeds of 50KB/s | 14:31 |
| zyga-suse | that's pretty slow | 14:31 |
| * zyga-suse dinner | 14:49 | |
| ppisati | ogra_: that linux-raspi2-firmware package wasn't the one in the archive, but one from a PPA | 15:00 |
| ppisati | lp1691729 | 15:00 |
| ppisati | bug1691729 | 15:00 |
| ogra_ | ppisati, oh sigh ...again ? | 15:00 |
| ppisati | ogra_: yes | 15:00 |
| ogra_ | iirc the last big issue was also some PPA stuff | 15:01 |
| ogra_ | oh my | 15:01 |
| ogra_ | JamieBennett, ^^^ | 15:01 |
| ppisati | well, we deserve the blame because we never generated an ubuntu classic img so far | 15:01 |
| fginther | What is required to update the 'current' link for the ubuntu-core images? The 'stable' image for pi3 is still using an image from 2017-03-14, but much newer stable pi3 images exist | 15:01 |
| fginther | this link: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ | 15:01 |
| ogra_ | ppisati, huh ? we do have http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/ | 15:02 |
| ogra_ | oh, you are talking about pi3 i guess | 15:02 |
| ogra_ | fginther, "ubuntu-core" ?!? | 15:02 |
| fginther | ogasawara, this is what https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 links to | 15:03 |
| ogra_ | fginther, thats dead and gone since ages ... your board should have migrated from "ubuntu-core" to "core" quite a while ago | 15:03 |
| fginther | so, this is just crufty websites? | 15:03 |
| ogra_ | fginther, right, i'm talking about the snap on your system :) | 15:03 |
| ogra_ | nah | 15:03 |
| ogra_ | the images are fine, they should all auto-migrate to core | 15:03 |
| fginther | oh, snap list shows it as "core" | 15:03 |
| fginther | core 16-2.26.8 2331 canonical - | 15:04 |
| ppisati | ogra_: yes, pi3 | 15:04 |
| ogra_ | that sounds recent | 15:04 |
| davidcalle | fginther: what? No it links to http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz | 15:07 |
| davidcalle | Oh sorry, misread the thread :) | 15:07 |
| ogra_ | davidcalle, yeah, naming issues (snap vs image name) : | 15:08 |
| ogra_ | :) | 15:08 |
| * davidcalle got scared for a second | 15:09 | |
| davidcalle | (the chain of notifications made it look like http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/ was the link on developer.ubuntu.com) | 15:10 |
| fginther | hhe | 15:10 |
| fginther | heh | 15:10 |
| fginther | The pi3 image at http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz does have a bug (https://bugs.launchpad.net/snappy/+bug/1678076), but newer 'stable' images don't. I was curious if the fix for the bug is to just update the current link. | 15:13 |
| mup | Bug #1678076: console-conf crashes with eth0 and wlan0 on Pi 3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1678076> | 15:13 |
| ogra_ | fginther, i dont know what conditions need to be fulfilled to have the ones in pending/ move to current/ ... there are definitely newer ones in pending | 15:16 |
| ogra_ | i guess the QA for them isnt done yet (they are only a day old) | 15:17 |
| ogra_ | fginther, fgimenez and slangasek might be able to tell you though :) | 15:18 |
| jjohansen | zyga: it shouldn't truncate, and you should be able to use multiple reads/search etc | 15:18 |
| ogra_ | iirc federico is the gatekeeper and slangasek owns the setting of the links | 15:18 |
| jjohansen | that being said the lxd guys reported occasionally getting a truncated file, but I could never reproduce | 15:19 |
| fginther | ogra_, thanks for the info. I'll follow up with fgimenez | 15:21 |
| fginther | once I test this again and have better info | 15:21 |
| pedronis | Chipaca: lgtm but the tests aren't happy on that branch | 15:23 |
| Chipaca | ah, i didn't run the full unit tests | 15:23 |
| ogra_ | fginther, note that wlan-only installs do not work yet though ... only the python traceback issue of that bug will be fixed | 15:23 |
| Chipaca | literally just threw the branch together | 15:23 |
| Chipaca | i'll take a look in a bit | 15:23 |
| mup | PR snapd#3568 opened: snapctl: add new `snapctl internal configure-core` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3568> | 15:24 |
| fginther | ogra_, thanks | 15:25 |
| zyga-suse | jjohansen: interesting | 15:25 |
| zyga-suse | jjohansen: thank you | 15:25 |
| ogra_ | (there is another bug i cant find right now) | 15:25 |
| fginther | https://bugs.launchpad.net/snappy/+bug/1632387 looks promising | 15:27 |
| mup | Bug #1632387: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:Confirmed> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1632387> | 15:27 |
| ogra_ | fginther, yeah, thats the one | 15:29 |
| ogra_ | fginther, it works fine after the first reboot ... you can just run "sudo console-conf", turn of eth0 and configure wlan just fine | 15:29 |
| ogra_ | only the very first boot breaks ... | 15:30 |
| fginther | ogra_, right, that worked for me (wlan only works if you restart during console-conf) | 15:30 |
| ogra_ | well | 15:30 |
| mvo_ | Chipaca: I love that listContians branch, fix for the unit test looks trivial (just a misisng import), I can push for you if you are busy. fun how many contains we had in that code :) | 15:30 |
| ogra_ | not during | 15:30 |
| ogra_ | i usually just confgure the board wired, then reboot ... ssh in via wired and run console-conf again | 15:30 |
| Chipaca | mvo_: there's another one in the pipeline, which is what triggered the branch | 15:30 |
| fginther | I never had mine wired. | 15:31 |
| Chipaca | i'm on it | 15:31 |
| ogra_ | ah | 15:31 |
| ogra_ | well, then you were lucky to have it working at all | 15:31 |
| fginther | I'm updating the bug with the workaround | 15:31 |
| ogra_ | there is some race i cant put my finger on :/ | 15:31 |
| fginther | ah, maybe it was just luck then | 15:31 |
| zyga-suse | ogra_: did we get to the bottom of that bug? | 15:32 |
| ogra_ | zyga-suse, no | 15:32 |
| ogra_ | zyga-suse, we do know the symptoms and workarounds but not the reason ... and it is only the very first boot | 15:33 |
| zyga-suse | well, there will be a lot of people hitting that | 15:34 |
| zyga-suse | so the "only" part is not so happy | 15:34 |
| ogra_ | i'll try to allocate some time to it again but i'm not very hopeful | 15:34 |
| ogra_ | the prob is that you cant access the system at this point and as soon as you start with a debug systemd shell it works | 15:35 |
| ogra_ | so nailing it down is really hard | 15:35 |
| pedronis | Chipaca: thx for that branch btw | 15:35 |
| === anewman is now known as anewman|away | ||
| pstolowski | zyga, you mentioned earlier you'd be working on some big interface changes, what is that? | 15:36 |
| zyga-suse | pstolowski: hmm? I think none anymore, all the things I wanted are "in" | 15:38 |
| pstolowski | zyga, ok, maybe I misunderstood something in the standup, nvm then | 15:39 |
| zyga-suse | ah | 15:40 |
| zyga-suse | sorry | 15:40 |
| zyga-suse | that was the "interface" command | 15:40 |
| zyga-suse | and indeed that is in the pipeline, but it should not interfere with any API changes | 15:40 |
| pstolowski | zyga, ah, good, thanks :) | 15:40 |
| zyga-suse | pstolowski: please ensure that we have deprecated API detection in all_test.go | 15:42 |
| pstolowski | zyga, sure... but that's faaar away ;) | 15:45 |
| pstolowski | niemeyer, hey, there? | 15:46 |
| niemeyer | pstolowski: Sort of here :) | 15:47 |
| niemeyer | pstolowski: What's up? | 15:47 |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | niemeyer, about that json decode problem; in my tests it looks like Decode always decoded as much as it can (i.e. entire object where it makes sense) and stops (with More()==true); but that doesn't seem to be backed up by the docs; do you know if More() is a good indicator to know we have invalid json (because there is more data)? | 15:51 |
| niemeyer | pstolowski: What's the behavior that is taking place there which seems unexpected in comparison to docs? | 15:53 |
| pstolowski | niemeyer, I feed it with very large array, followed by some random stuff, and I always receive entire array object. so it never "stops" at the middle of an object, it reads it completely | 15:56 |
| pstolowski | niemeyer, the doc says "// More reports whether there is another element in the | 15:56 |
| pstolowski | // current array or object being parsed. | 15:56 |
| pstolowski | " | 15:56 |
| pstolowski | I find the observed behavior natural and exepected, receiving partial object would be terrible | 15:58 |
| niemeyer | pstolowski: I don't understand what that means.. the json decoder outputs objects.. it doesn't output byte arrays | 15:58 |
| niemeyer | pstolowski: When you create a decoder and initialize it with a reader, that decoder will use the reader as a stream, and will decode objects on it sequentially | 15:59 |
| niemeyer | pstolowski: I don't even mean what a "partial object" would be in this context.. there are no half-values in Go | 15:59 |
| niemeyer | pstolowski: Byte stream comes in, Go values get decoded.. | 15:59 |
| ogra_ | 50 shades of objects ... | 15:59 |
| niemeyer | pstolowski: One a time.. | 15:59 |
| ogra_ | :) | 15:59 |
| niemeyer | pstolowski: When you decode "0:", you get to the zero only, because that's as far as the json decoder can reasonably go, and then you have More | 16:00 |
| niemeyer | pstolowski: This is the behavior I'd expect, and also what I think is documented | 16:00 |
| niemeyer | pstolowski: What in this picture disagrees with your expectation, or with what's happening in your observations? | 16:01 |
| pstolowski | niemeyer, yes, I get that, and it works as I expected it to work. it's just that docstring for More that confuses me ("whether there is another element in the current array...") | 16:01 |
| niemeyer | pstolowski: That seems to describe what I just said above | 16:02 |
| niemeyer | Have a call now, we can continue in a bit | 16:02 |
| Chipaca | pstolowski: More() says whether there is more stuff in the thing _being parsed_, not in the result of the parse | 16:04 |
| pstolowski | Chipaca, aha, great, that confirms my understanding than and clears the confusion, thank you | 16:05 |
| pstolowski | thanks niemeyer, I'm good | 16:05 |
| Chipaca | funnily enough the implementation of More seems a bit bogus | 16:06 |
| Chipaca | like, `[1,2,3]]` would give you an array and no More, i think? | 16:07 |
| Chipaca | bah. never mind. | 16:07 |
| * Chipaca goes for some tea | 16:07 | |
| === anewman|away is now known as anewman | ||
| niemeyer | kyrofa: Looking through the notes in that topic, it may be a good idea to enable building on multiple bases.. | 16:25 |
| niemeyer | kyrofa: Specifically so that people on multiple distributions can collaborate on the same snaps.. | 16:25 |
| niemeyer | kyrofa: I'll cover more in the topic itself.. but just wanted to point out the disagreement from what I just said in the sprint so it doesn't feel awkward | 16:26 |
| niemeyer | s/sprint/call/ | 16:26 |
| kyrofa | niemeyer, indeed, that makes sense. Fits into the stage-package grammar as well, where you can provide separate ones depending on distribution | 16:26 |
| kyrofa | If you use that, you probably want a different base as well | 16:27 |
| mup | PR snapd#3569 opened: snapd, snapctl: use json Decoder instead of Unmarshall <Created by stolowski> <https://github.com/snapcore/snapd/pull/3569> | 16:34 |
| sergiusens | niemeyer: yes, we want multiple bases in that grammar | 16:35 |
| mup | PR core-build#15 opened: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15> | 16:45 |
| === anewman is now known as anewman|away | ||
| === anewman|away is now known as anewman | ||
| === anewman is now known as anewman|away | ||
| === anewman|away is now known as anewman | ||
| mvo_ | jdstrand: I ported snap-seccomp to use the seccomp() syscall but no change, I dig some more | 17:42 |
| mup | PR snapd#3567 closed: many: introduce and use strutil.ListContains <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3567> | 17:42 |
| jdstrand | mvo_: did you also set the flag? the PR said to have to set tsync since seccomp syscall won't do it by default | 17:43 |
| jdstrand | mvo_: I haven't done this myself; just going by that commit I referenced earlier | 17:43 |
| jdstrand | but I did read tsync isn't set by default | 17:44 |
| === anewman is now known as anewman|away | ||
| zyga | mvo_: jdstrand is right, the seccomp syscall just _lets_ you use the flag | 17:47 |
| === anewman|away is now known as anewman | ||
| mvo_ | jdstrand: yeah, tried that | 17:51 |
| jdstrand | hmm, bummer | 17:51 |
| mvo_ | I dig some more | 17:52 |
| jdstrand | mvo_: does libseccomp-golang use C to libseccomp? | 17:52 |
| mvo_ | jdstrand: yes | 17:53 |
| jdstrand | mvo_: cause it might get back to the builtime checks for the kernel and tsync, where the 14.04 kernel doesn't have tsync | 17:53 |
| mvo_ | jdstrand: AIUI | 17:53 |
| mvo_ | jdstrand: indeed, I'm checking rightnow | 17:53 |
| jdstrand | so libseccomp is built without it | 17:53 |
| jdstrand | cool | 17:53 |
| mvo_ | jdstrand: well, I don't know yet, all I know is that porting to syscall seccomp did not help | 17:56 |
| jdstrand | mvo_: yeah, the 'cool' wasn't 'cool' that it worked but that it was your next step :) | 17:58 |
| mup | PR snapd#3542 closed: cmd,client,daemon: expose "force devmode" in sysinfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3542> | 18:22 |
| mvo_ | jdstrand, zyga: I think I know what the tsync problem is - we run snap-seccomp from the core snap which was build with a libseccomp > 2.2 - in this case libseccomp-golang tries to enable the tsync bits. however this does not work on trusty and the libseccomp version we have there (2.1.1). I need to think a bit how to fix this | 18:51 |
| mvo_ | jdstrand, zyga: more tomorrow, need to go offline, thunderstorm is heading my way | 18:52 |
| * zyga-suse thinks about what mvo said | 19:03 | |
| cachio | niemeyer, again, cannot Direct Disk boot a disk with no MBR | 19:10 |
| niemeyer | cachio: Uh oh | 19:11 |
| niemeyer | cachio: Which machine? | 19:11 |
| cachio | niemeyer, sorry, different error | 19:12 |
| cachio | cannot connect to linode:debian-unstable-64 (Spread-25): dial tcp 45.79.191.246:22: i/o timeout | 19:12 |
| niemeyer | cachio: Ahh, okay | 19:13 |
| niemeyer | cachio: Phew | 19:13 |
| cachio | it is more sporadic, but I saw it twice | 19:13 |
| niemeyer | cachio: That's one of those that we need to reproduce while keeping the system alive so we can have a look | 19:14 |
| cachio | niemeyer, yes, continuosly monitoring the builds | 19:15 |
| niemeyer | cachio: That alone won't help.. spread will kill the system once the test fails | 19:17 |
| niemeyer | cachio: We need to reproduce with -reuse so we can dig in | 19:18 |
| === JanC is now known as Guest56451 | ||
| === JanC_ is now known as JanC | ||
| === anewman is now known as anewman|away | ||
| === anewman|away is now known as anewman | ||
| kyrofa | Hey cprov, I'm trying to upload a snap to a branded store via the web interface and I'm getting an Oops (Sentry id: 9b78868ed9a4429b8d600cec207974bc) | 19:55 |
| kyrofa | Can't seem to get it to succeed | 19:56 |
| kyrofa | noise][, nessita this ^^ is blocking me, can I get anyone to help? | 20:04 |
| nessita | kyrofa, one sec, replying to the forum topic about this (brand store and pushes) :-) | 20:06 |
| nessita | kyrofa, what snap, what store? | 20:06 |
| kyrofa | nessita, kyrofa-store, snap name was just registered kyrofa-branded-test-snap | 20:06 |
| nessita | kyrofa, do you have any special role in that store? | 20:08 |
| kyrofa | nessita, I'm the owner | 20:08 |
| kyrofa | Or admin, whatever | 20:08 |
| nessita | kyrofa, you mean admin? | 20:08 |
| nessita | right | 20:08 |
| nessita | let's continue privately since this store is unlisted | 20:08 |
| nessita | roadmr, hey, I have to EOD now, is there any chance you could follow up the issue that kyrofa is having? he is having a sentry issue on the uploader https://sentry.ols.canonical.com/canonical/snapcraft-dashboard/issues/1798/ | 20:18 |
| nessita | the sentry report is absolutely unhelpful | 20:18 |
| roadmr | let's see | 20:18 |
| roadmr | kyrofa: so.. | 20:22 |
| kyrofa | roadmr, all broken? | 20:25 |
| roadmr | kyrofa: no idea :) | 20:25 |
| kyrofa | Hahaha | 20:25 |
| roadmr | kyrofa: what were you doing? just uploading a snap to that store? | 20:25 |
| kyrofa | Yeah, that's it. Get an Oops every time | 20:25 |
| roadmr | kyrofa: as nessita said, the sentry report is quite unhelpful, not sure if that's because the js client is outdated. So I'd need to repro it myself to get a peek at the js console | 20:26 |
| roadmr | and then my inexperience with js will really show haha | 20:26 |
| roadmr | kyrofa: but you can usually upload fine (e.g. to the ubuntu store)? | 20:26 |
| kyrofa | roadmr, I typically use snapcraft to be honest | 20:26 |
| kyrofa | roadmr, but I can't with brand stores, at least for the first | 20:26 |
| roadmr | ok, let me see what I can find out | 20:27 |
| roadmr | kyrofa: can you invite or add me (roadmr) to that store? | 20:31 |
| kyrofa | roadmr, hmm.... I'm not sure how. When I hit "manage" I just see a bunch of interface checkboxes | 20:32 |
| kyrofa | Err, review checkboxes | 20:32 |
| roadmr | interesting. | 20:37 |
| roadmr | kyrofa: let me see, maybe I can add myself | 20:37 |
| roadmr | kyrofa: I'm building a snap to upload | 20:46 |
| roadmr | kyrofa: hm... it works for me... | 20:49 |
| roadmr | let me try something | 20:50 |
| roadmr | kyrofa: which snap was this for? | 20:52 |
| kyrofa | roadmr, I just registered it, kyrofa-branded-test-snap | 20:53 |
| roadmr | ok... anything particular about the snap itself? (I was able to build/upload a dummy strict/stable test snap, no problem) | 20:53 |
| kyrofa | roadmr, it's literally the output of `snapcraft init` | 20:54 |
| kyrofa | With a changed name | 20:54 |
| kyrofa | I tried with and without an app, just in case, no change | 20:55 |
| roadmr | aha :) so close to mine | 20:55 |
| roadmr | but mine is not published. Let me try that | 20:55 |
| roadmr | kyrofa: :/ I hate problems I can't repro... ugh | 20:57 |
| kyrofa | roadmr, yeah I feel ya | 20:58 |
| roadmr | kyrofa: you say you get an actual oops? as in a 50x response and the ugly "oooops" page? | 20:58 |
| kyrofa | roadmr, no, sorry, just the message "Oops! I'm broken. Here's the sentry ID" | 20:59 |
| roadmr | oh, I see | 20:59 |
| roadmr | kyrofa: so let's flip this around. You get this reliably? could you open your browser's dev console, retry the upload, then show me (pastebin for instance) any output in that window? | 21:00 |
| kyrofa | roadmr, definitely, one sec. Do I need to be on the VPN? | 21:00 |
| kyrofa | Or have we established that it isn't helpful? | 21:00 |
| roadmr | kyrofa: no, not needed | 21:00 |
| kyrofa | Okay, one sec | 21:00 |
| roadmr | kyrofa: the thing is - if you're in the vpn then sentry.js can send its report to our sentry server. But the report has proven useless :) so it's not needed | 21:01 |
| roadmr | raven.js actually... but anyway | 21:01 |
| kyrofa | roadmr, http://pastebin.ubuntu.com/25034621/ ... that looks terrible though | 21:07 |
| roadmr | it's javascript, how could it look any other way? | 21:08 |
| roadmr | "Empty string passed to getElementById(). upload" seems to be it. The others I also get but they seem harmless | 21:08 |
| kyrofa | Yeah that looked questionable to me as well | 21:08 |
| roadmr | kyrofa: firefox? any chance you could try with the other browser? | 21:08 |
| roadmr | (or chrome?) | 21:09 |
| kyrofa | roadmr, indeed, firefox. I'll try chrome now | 21:09 |
| roadmr | kyrofa: it's a shot in the dark and fwiw I also have firefox and WFM, but let's give it a try. | 21:09 |
| kyrofa | roadmr, yeah that worked fine | 21:10 |
| kyrofa | What the heck... | 21:10 |
| roadmr | kyrofa: tell me about your plugins on firefox | 21:10 |
| * kyrofa closes firefox and opens it again... | 21:10 | |
| kyrofa | roadmr, these: https://pasteboard.co/GzJy240.png | 21:11 |
| roadmr | I opened that blindly, you could have rickrolled me :D | 21:13 |
| kyrofa | Ha! /me makes a note for the future... | 21:13 |
| roadmr | kyrofa: I'd suspect adblock or Ubuntu Modifications, if a restarted firefox still misbehaves I'd look at those two (and/or bisect which plugin may be giving trouble) | 21:14 |
| roadmr | ok, not Ubuntu Modifications - I also have that and it's oK | 21:14 |
| kyrofa | Not adblock either... | 21:15 |
| kyrofa | I'll just through through disabling each one | 21:15 |
| roadmr | kyrofa: ah also, the most basic check: Build identifier: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 | 21:16 |
| roadmr | is what I have | 21:16 |
| roadmr | (on 16.04) | 21:16 |
| roadmr | kyrofa: if you do find a plugin is messing with uploads, please ping me so I can file a bug and we look into it | 21:16 |
| * roadmr unpublishes his crappy snap from kyrofa's store | 21:17 | |
| kyrofa | roadmr, privacy badger! | 21:18 |
| roadmr | ahh! | 21:18 |
| kyrofa | Veerrrry interesting | 21:18 |
| roadmr | that makes sense... let me install it and try to repro | 21:18 |
| kyrofa | Looks like it's blocking google tag manager | 21:19 |
| roadmr | aha.. and we added that somewhat recently (a few weeks ago IIRC) | 21:19 |
| kyrofa | Hahaha, no, when I actually upload, it blocks apps.ubuntu.com! | 21:20 |
| kyrofa | Err, upload.apps.ubuntu.com | 21:20 |
| kyrofa | Tag manager has nothing to do with it | 21:20 |
| kyrofa | If I allow upload.apps.ubuntu.com, it succeeds | 21:21 |
| kyrofa | Wonder why that's on the blacklist | 21:21 |
| roadmr | wow... | 21:21 |
| roadmr | kyrofa: interesting, it works for me even with privacybadger installed... | 21:22 |
| kyrofa | roadmr, once you upload, do you see upload.apps.ubuntu.com in the dropdown there? | 21:23 |
| kyrofa | It completely blocked it for me | 21:23 |
| kyrofa | But it sounds like it's letting it through for you | 21:23 |
| roadmr | yep... kyrofa no, I don't see it in the badger dropdown | 21:24 |
| kyrofa | Huh, interesting | 21:24 |
| roadmr | kyrofa: I click where it says "upload", choose the file, then it uploads and enables the "Submit to store" button | 21:24 |
| kyrofa | Once it uploads, check the dropdown again | 21:24 |
| kyrofa | It didn't show up for me once I did that | 21:24 |
| kyrofa | until once I did that* | 21:24 |
| roadmr | I clicked "submit to store", the upload is complete and badger is still green | 21:25 |
| roadmr | it shows stats.g.doubleclick.net 066-eov-335.mktoresp.com as potential trackers | 21:25 |
| kyrofa | Huh. Weird. It's not blocking google tag manager either? | 21:25 |
| roadmr | and three more which "don't appear to be tracking" (analytics, tagmanager, marketo) | 21:25 |
| kyrofa | What the heck... | 21:25 |
| kyrofa | It's working totally differently for me | 21:25 |
| kyrofa | Wait, do you have do not track enabled? | 21:26 |
| roadmr | kyrofa: no.. heh | 21:26 |
| roadmr | kyrofa: version 2017.6.13.1 | 21:26 |
| kyrofa | Maybe that's it | 21:26 |
| kyrofa | (I do) | 21:26 |
| roadmr | how do I enable DNT? | 21:27 |
| roadmr | oh that's a browser setting, right? | 21:27 |
| kyrofa | Firefox preferences > Privacy > manage your Do No Track settings | 21:28 |
| kyrofa | Yeah | 21:28 |
| roadmr | ok, let's try nwo | 21:28 |
| roadmr | now | 21:28 |
| roadmr | wtf. No, it's still letting my upload through | 21:30 |
| kyrofa | Man... no idea what's different, then | 21:31 |
| roadmr | kyrofa: the badger's introduction suggests it has some sort of learning behavior. You've been using it for a while, while I just installed it | 21:31 |
| roadmr | that may explain it... | 21:31 |
| kyrofa | Hmm, good point | 21:31 |
| kyrofa | Makes it tough to reproduce issues, huh? | 21:31 |
| kyrofa | Regardless, I submitted a complaint via the addon, and now I know | 21:32 |
| kyrofa | I wonder why it thinks upload.apps.ubuntu.com is tracking me | 21:32 |
| roadmr | yeah... well if they think we need to change anything on our side, do let us know | 21:32 |
| kyrofa | Will do | 21:32 |
| roadmr | we absolutely need analytics, tag manager and marketo though :( | 21:32 |
| roadmr | but upload.apps should not have any of that, it's just the bucket where snaps are uploaded/downloaded | 21:33 |
| kyrofa | Blocking those things shouldn't break uploads though. And they're separate! | 21:33 |
| kyrofa | Yeah | 21:33 |
| kyrofa | Makes no sense | 21:33 |
| roadmr | I'll probably keep the badger anyway - it's cute | 21:33 |
| kyrofa | Yeah I kinda love it | 21:33 |
| kyrofa | roadmr, thanks for all the troubleshooting :) | 21:33 |
| roadmr | kyrofa: no probl, glad to be of help | 21:34 |
| kyrofa | roadmr, can you verify something for me? The kyrofa-store should be inheriting snaps from the ubuntu store, right? | 21:44 |
| roadmr | kyrofa: let me see | 21:45 |
| roadmr | kyrofa: I don't see it inheriting anything, but I could be misreading the screen | 21:46 |
| kyrofa | roadmr, hmm... can you change that for me? That's an option, right? | 21:46 |
| roadmr | kyrofa: sure! | 21:47 |
| kyrofa | roadmr, to be clear, that means stuff I add to the store is hidden from the ubuntu store, but not the other way around. Right? | 21:47 |
| roadmr | kyrofa: right, AIUI | 21:47 |
| kyrofa | Perfect, yeah that's what I want | 21:48 |
| roadmr | inheritance works only in the direction of the arrow :) | 21:48 |
| roadmr | kyrofa: done, can you check it's as you expect now? | 21:48 |
| kyrofa | roadmr, by the way, I thought it was inheriting because I saw all the snaps I had in the ubuntu store there | 21:48 |
| roadmr | hm. intereesting | 21:48 |
| kyrofa | This could use some UX love | 21:48 |
| roadmr | for sure :( yes, we need to revamp the stores ui and all | 21:49 |
| roadmr | I think there's a bug for that down here, between this old trunk and this set of hockey sticks... | 21:49 |
| kyrofa | roadmr, still not working the way I expect. I've created a model assertion that uses my store slug, but it can't find the "pc" gadget snap | 21:49 |
| roadmr | no, seriously, I'm sure we have that in our backlog but priorities can get crazy and it keeps getting punted to the bottom | 21:49 |
| kyrofa | Yeah I know how that goes | 21:50 |
| roadmr | kyrofa: there should be a place where you can cherrypick which snaps are available, I don't think you inherit them all for free | 21:50 |
| kyrofa | Ah, interesting | 21:50 |
| kyrofa | Maybe "add packages to this store" | 21:50 |
| kyrofa | Heeey, there we go | 21:51 |
| roadmr | kyrofa: try it, if it still doesn't show I think I need to reindex your store | 21:51 |
| kyrofa | roadmr, "Select a valid choice. u'pc' is not one of the available choices." | 21:52 |
| roadmr | aha... | 21:52 |
| roadmr | kyrofa: there's a crapload of snaps on the rightside of that thing, so I guess pc is not a valid choice because you're already inheriting it.. | 21:55 |
| roadmr | same with e.g. beagleblack, I can clearly see it's there so I can't readd it | 21:55 |
| kyrofa | Hmm.... then why can't ubuntu-image find it... | 21:55 |
| roadmr | kyrofa: probably the reindex thing, hang on | 21:56 |
| === arcade_droid is now known as avamander | ||
| roadmr | kyrofa: ugh, my docs are obsolete and I don't know how to trigger a reindex now | 22:05 |
| kyrofa | Hahaha | 22:06 |
| roadmr | snaps have individual "reindex" controls | 22:06 |
| roadmr | I'm not about to go reindexing all the Ubuntu store packages :) but maybe we can index the ones you need right now | 22:06 |
| kyrofa | Huh, interesting, okay. I just need pc and pc-kernel | 22:07 |
| kyrofa | And core, I suppose | 22:07 |
| roadmr | kyrofa: I've just set pc to be reindexed | 22:08 |
| roadmr | kyrofa: can you check if it's installable now? | 22:09 |
| kyrofa | Yes! Core is working as well | 22:09 |
| roadmr | it is? WOW I didn't touch core! | 22:09 |
| kyrofa | pc-kernel failed | 22:09 |
| kyrofa | core is special, perhaps | 22:09 |
| roadmr | ok, let me index that one explicitly | 22:10 |
| roadmr | I'm pretty sure "core" is marked as essential and is there for all stores | 22:10 |
| kyrofa | Yeah that makes sense | 22:10 |
| kyrofa | roadmr, to clarify, would this reindex happen automatically if I was patient enough? | 22:10 |
| roadmr | kyrofa: I don't think it would | 22:10 |
| kyrofa | roadmr, is that just because you changed the inheritance type for me? | 22:10 |
| roadmr | kyrofa: this changed recently; up until a few days ago there was a "reindex everything" admin action, but it's now gone | 22:11 |
| roadmr | kyrofa: the instructions clearly say a reindex is needed when adding an inherited store, so I guess they are two separate actions... | 22:11 |
| kyrofa | Interesting | 22:11 |
| roadmr | where the instructions fail is where they don't account the fact that the "reindex the world" action was removed (or at least changed to a place where I was unable to find it) | 22:11 |
| roadmr | kyrofa: the package index has just moved to a new set of services, so it may just be that it's somewhere I didn't know to look | 22:12 |
| roadmr | kyrofa: meanwhile - try pc-kernel, I reindexed it 2 mins ago | 22:12 |
| kyrofa | roadmr, yep, working now :) | 22:13 |
| roadmr | kyrofa: awesome! | 22:13 |
| roadmr | kyrofa: I'll find out how this indexing can be done in bulk | 22:13 |
| roadmr | but tomorrow, as right now, the park awaits. | 22:13 |
| roadmr | EOD, good night! | 22:13 |
| kyrofa | roadmr, I'm unblocked, again, I appreciate your help! Enjoy the park | 22:14 |
| roadmr | thanks kyrofa ! (btw I *just* found the new reindexing page :) I'll try it tomorrow. Cheers! | 22:16 |
| mup | PR snapcraft#1390 closed: meta: bash completion support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1390> | 22:40 |
| === charles_ is now known as charles | ||
| noise][ | kyrofa - fwiw, roadmr was pretty much correct on everything. Changing store inheritance does require re-indexing, it's usually a set once and leave it kind of thing | 23:40 |
| noise][ | and yes, core is special and is always "cherry picked" even if you don't inherit any stores entirely | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
