| === ssweeny_ is now known as ssweeny | ||
| Son_Goku | yay... | 01:25 |
|---|---|---|
| Son_Goku | somebody broke the packaging for snapd in Fedora in snapd git | 01:25 |
| Son_Goku | I think I'm going to have to resync from Dist-Git asap | 01:25 |
| Son_Goku | it's also broken for 2.29 | 01:25 |
| === nacc_ is now known as nacc | ||
| mborzecki | morning | 05:54 |
| === nsg_ is now known as nsg | ||
| mborzecki | mvo: morning | 06:29 |
| kalikiana | moin moin | 07:00 |
| === grumble is now known as 17SAA0F42 | ||
| === 17SAA0F42 is now known as grumble | ||
| mborzecki | guys, what's with the nested functions in libsnap-confine-private? | 07:23 |
| mvo | hey mborzecki | 07:24 |
| mborzecki | mvo: hey | 07:24 |
| mvo | mborzecki: good morning! what in particular? this is mostly the baby of zyga, however review/cleanup is always good | 07:25 |
| mvo | mborzecki: it might have gotten less reviews than the average other code we have | 07:25 |
| mborzecki | yeah, i was a bit tired with arch fixes so i went on and tried checking the lower level C bits with sparse and now build it with clang | 07:25 |
| mvo | mborzecki: well, thats not true, it got a different kind of reviews, very security focused mostly | 07:25 |
| mvo | mborzecki: cool, what are your findings so far? | 07:26 |
| mborzecki | a bunch of signed/usigned comparisons | 07:26 |
| mvo | mborzecki: we ran it through coverity a while ago | 07:26 |
| mvo | mborzecki: aha, neat, lets fix those | 07:26 |
| mborzecki | sprinkled some statics here and there, added voids in function arguments where possible | 07:26 |
| mborzecki | clang chokes on nested functions though, I don't think it's actually supported outside of gcc | 07:27 |
| mborzecki | btw. that's actually weird that coverity did not pick up signed/unsigned stuff, i remember it to be very picky | 07:29 |
| mvo | mborzecki: indeed, not sure what happend, maybe it was too long ago, I would have to check my mail history. having some static analyizing that happens regularly as part of each build ideally would be way better | 07:32 |
| mborzecki | yeah, i'll tune CFLAGS there to something more useful, it's -Wall -Werror right now, there should albo be -Wextra at least | 07:34 |
| mvo | mborzecki: +1 | 07:34 |
| mvo | mborzecki: great to have a fresh new set of eyes looking at this | 07:34 |
| mup | PR snapd#4150 opened: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <https://github.com/snapcore/snapd/pull/4150> | 08:18 |
| zyga-ubuntu | o/ | 08:42 |
| zyga-ubuntu | good morning | 08:42 |
| mvo | hey zyga-ubuntu | 08:44 |
| zyga-ubuntu | hey, sorry for starting late today | 08:45 |
| zyga-ubuntu | how are things? | 08:45 |
| mborzecki | zyga-ubuntu: hey | 08:49 |
| zyga-ubuntu | hey :) | 08:49 |
| mvo | zyga-ubuntu: things are mostly good, a test failure for 2.29.2 on pi3 which is annyoing but mostly test breakage not real issues it seems | 08:54 |
| mvo | zyga-ubuntu: i.e. arm seems to return EPERM for cgroup access denials and x86 EACCESS | 08:55 |
| zyga-ubuntu | oh | 08:55 |
| zyga-ubuntu | that's intereting | 08:55 |
| zyga-ubuntu | just last week I recall jdstrand and tyhicks discuss EPERM vs EACCSS on various syscalls | 08:56 |
| zyga-ubuntu | it seems that it varies from one syscall to another | 08:56 |
| mvo | and annoying because it means 2.29.2 is not in candidate yet :/ | 08:56 |
| zyga-ubuntu | and thus, perhaps, varies from arch to arch | 08:56 |
| mvo | yeah, the pattern isnot consistent | 08:56 |
| sergiusens | mvo are you guys paying attention to the adt results? | 09:05 |
| mvo | sergiusens: generally speaking yes, things were very slow with the opening of bionic so we may have missed some data because of this in the most recent few days. why? | 09:06 |
| mvo | sergiusens: all releases go through the regular autopkgtest distro testing so yes, we are generally autopkgtest clean | 09:06 |
| sergiusens | mvo oh, because of the slowness, was wondering if you where interested in our approach of launching them on demand (after a review) so resources don't starve | 09:07 |
| sergiusens | there are many tests for the same branch of a snapd PR enqueued, which I guess comes after minor review fixes and such | 09:08 |
| zyga-ubuntu | I think adt could use the concept of travis automatic job cancellation | 09:08 |
| zyga-ubuntu | so only one such instance exists for the same branch (the latest one) | 09:09 |
| mvo | sergiusens: we are definitely interessted, cachio was working on this, but because of other work this is a bit slow going crrently | 09:09 |
| sergiusens | zyga-ubuntu yeah, it is nice to think of ideals others can do, and there is a bug for that; I am talking about things we can do ;-) | 09:09 |
| zyga-ubuntu | sergiusens: no disagreement there | 09:09 |
| mvo | sergiusens: yeah, we definitely want to stop starving the distro | 09:09 |
| mvo | sergiusens: and there is work, its just slow right now because of other duties | 09:10 |
| mvo | sergiusens: I will connect you with cachio, sounds like you guys have figured it out already | 09:10 |
| mvo | sergiusens: or is it trivial? if so I can have a look in a bit myself | 09:10 |
| sergiusens | mvo zyga-ubuntu we have a telegram and irc bot if interested. We've been using this approach for a while now | 09:11 |
| sergiusens | mvo for hooking up; elopio and cachio could hook up and discuss | 09:11 |
| zyga-ubuntu | sergiusens: I saw you use this multiple times and I was indeed intrigued | 09:11 |
| zyga-ubuntu | sergiusens: it seems like a better way to use our resources, last-phase test after review and travis say it's oK | 09:12 |
| sergiusens | most of it is based out of this https://github.com/snapcore/snapcraft/blob/master/tools/retry_autopkgtest.sh | 09:12 |
| sergiusens | zyga-ubuntu that is what we do; we also run a nightly with travis' cron for sanity checks | 09:12 |
| sergiusens | I don't know if you suffer this, but we get dns/proxy errors all the time on non-x86 so running on every PR just became noise | 09:13 |
| zyga-ubuntu | no, we don't suffer those | 09:13 |
| sergiusens | yeah, I guess we hammer the system a bit more given we build stuff for like 3 hours min for every run :-P | 09:14 |
| mvo | sergiusens: cool, thanks. do you know where the result of the runs are stored? or is retry-github-test synchronous ? | 09:17 |
| sergiusens | mvo it adds the entry to the PR (just as if it were triggered by the webhook) | 09:18 |
| mvo | sergiusens: sweet | 09:18 |
| === tinwood_ is now known as tinwood | ||
| sergiusens | mvo if you want more automation that having to trigger, you cold run something like that script as the last step of your travis run (keeping the secret as an encrypted var on travis) | 09:21 |
| mvo | sergiusens: btw, are you up early or traveling (if I may ask :) | 09:23 |
| === mardy_ is now known as mardy | ||
| mup | PR snapd#4151 opened: tests: fix security-device-cgroup* tests on devices with framebuffer <Created by mvo5> <https://github.com/snapcore/snapd/pull/4151> | 09:40 |
| zyga-ubuntu | wow, nice! | 09:41 |
| zyga-ubuntu | approved, thank you mvo! | 09:41 |
| sergiusens | mvo I woke up at 4am; just early ;-) | 09:42 |
| * mvo hugs sergiusens | 09:45 | |
| sergiusens | there's just so much to do and so little time | 09:46 |
| mborzecki | where can I get spread images? | 09:52 |
| zyga-ubuntu | mborzecki: you can build them youself or get them from spread.zygoon.pl | 09:52 |
| zyga-ubuntu | spread images are just images with well known user/password | 09:52 |
| zyga-ubuntu | nothing maic | 09:52 |
| zyga-ubuntu | *magic | 09:52 |
| zyga-ubuntu | if you have a way please contribute a build command for arch linux | 09:53 |
| zyga-ubuntu | I can refresh my images periodically (just was too lazy to set it up before) | 09:53 |
| mborzecki | ok | 09:53 |
| mborzecki | my first time using spread :) i'll probably have a lot of questions, so bear with me | 09:53 |
| zyga-ubuntu | gladly :) | 09:54 |
| mup | PR snapd#4152 opened: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152> | 09:55 |
| * zyga-ubuntu reads 4152 | 09:59 | |
| mup | PR snapd#4153 opened: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup lowe level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153> | 10:03 |
| mup | Issue snapcraft#1658 opened: Map of supported bases to containers <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1658> | 10:04 |
| mup | Issue snapcraft#1659 opened: Schema support for supported bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1659> | 10:04 |
| mup | Issue snapcraft#1660 opened: Container passthrough for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1660> | 10:04 |
| zyga-ubuntu | mborzecki: are you trying to build snap-confine with clang? | 10:07 |
| mborzecki | yeh, it builds now | 10:07 |
| mup | Issue snapcraft#1661 opened: Walk the prime directory for elf files (in lifecycle) <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1661> | 10:07 |
| mup | Issue snapcraft#1662 opened: patchelf with ld-linux <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1662> | 10:07 |
| mup | Issue snapcraft#1663 opened: patchelf with common rpath (not runpath) <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1663> | 10:07 |
| zyga-ubuntu | mborzecki: is clang becoming a default in arch? | 10:08 |
| mborzecki | not that I know of | 10:08 |
| zyga-ubuntu | so why? | 10:08 |
| mup | Issue # opened: snapcraft#1664, snapcraft#1665, snapcraft#1666, snapcraft#1667, snapcraft#1668 | 10:11 |
| mborzecki | to start with, clang is usually better with finding errors, but the best outcome is to usually build the code with both gcc and clang | 10:11 |
| mborzecki | and then you have initiatives like debian clang, that try to rebuild the whole archive using clang | 10:12 |
| zyga-ubuntu | I think that unless we can test build this with clang it will quickly bitrot | 10:12 |
| zyga-ubuntu | I don't mind the initiative just hoping it can stay something we really support (or not) but explicitly | 10:12 |
| mborzecki | well, i left a note about this in the PR, 'We should aim to integrate at least clang builds into the CI pipeline.' | 10:13 |
| mborzecki | and basically that's why i asked about spread images | 10:13 |
| mup | Issue snapcraft#1669 opened: patchelf with ld-linux from the future <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1669> | 10:14 |
| mup | Issue snapcraft#1670 opened: Change file migrations such that files move from stage to prime rather than coming from the part each time <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1670> | 10:14 |
| mup | Issue snapcraft#1671 opened: Rename prepare/build/install to pre-build/build/post-build, and deprecate prepare/build/install <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1671> | 10:14 |
| mborzecki | if this does not make sense, feel free to point that out and I'll stop with the PR that's already opened | 10:14 |
| mup | Issue # opened: snapcraft#1672, snapcraft#1673, snapcraft#1674, snapcraft#1675, snapcraft#1676, snapcraft#1677 | 10:17 |
| mup | Issue snapcraft#1678 opened: Support for set-summary <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1678> | 10:20 |
| mup | Issue snapcraft#1679 opened: Support for set-name <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1679> | 10:20 |
| mup | Issue snapcraft#1680 opened: Documentation overhaul for pre/post and setters <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1680> | 10:20 |
| zyga-ubuntu | mborzecki: I think it's fine, just trying to understand your motivation better | 10:20 |
| pstolowski | pedronis, hey! i've proposed the PR for cookies problem. re your questions from Friday about why cookie is not removed in UnlinkCurrentSnap for example - it's deliberate. we're interested in having a single cookie for given snap regardless of revisions or whether the snap is enabled or disabled. we create the cookie when we install the snap for the first time, and we remove the cookie when the last revision is discarded | 10:20 |
| pedronis | pstolowski: ok, I'll look at it with that in mind | 10:21 |
| pstolowski | thanks | 10:21 |
| Chipaca | i thought we weren't adding more patches until we got epochs working? | 10:22 |
| zyga-ubuntu | Chipaca: I think this patch is "special" | 10:22 |
| zyga-ubuntu | Chipaca: it's not really a patch | 10:22 |
| zyga-ubuntu | we could even do it in one of the managers at startup | 10:22 |
| Chipaca | it still breaks reverts | 10:23 |
| Chipaca | so the reason we're not doing patches is still there | 10:23 |
| zyga-ubuntu | just by virtue of incrementing the patch level? | 10:23 |
| Chipaca | yes | 10:23 |
| zyga-ubuntu | ah | 10:23 |
| zyga-ubuntu | then yes, it cannot be a patch | 10:23 |
| pedronis | as not a patch it will need a flag, that we can remove when we have patches I suppose | 10:26 |
| pedronis | mvo: I cannot make the standup, but we need to talk with Gustavo about moving snapctl start/stop/... etc from 2.29 to 2.30 in the roadmap topic | 10:31 |
| mup | Issue snapcraft#1681 opened: Make architectures grammar-powered <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1681> | 10:32 |
| mvo | pedronis: sure, I will raise that | 10:33 |
| mup | Issue # opened: snapcraft#1682, snapcraft#1683, snapcraft#1684, snapcraft#1685 | 10:35 |
| mvo | pedronis: 4150 is something I would appreciate your review, should be (hopefully) easy as its closely copied^Wmodelled after how the assertdb is handled | 10:35 |
| ackk | Chipaca, hi, I added some comments/replies on https://github.com/snapcore/snapd/pull/3916 | 10:36 |
| mup | PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916> | 10:36 |
| Chipaca | ackk: yep, it's in my queue | 10:43 |
| pedronis | mvo: I'll look at it today | 10:44 |
| ackk | Chipaca, thanks. I addressed some of the comments, fwiw | 10:45 |
| mvo | pedronis: thank you | 10:46 |
| mborzecki | zyga-ubuntu: do you think splitting tests/unit/c-unit-tests into c-unit-tests-gcc & c-unit-tests-clang will be enough? | 10:46 |
| zyga-ubuntu | mborzecki: yes | 10:59 |
| zyga-ubuntu | mborzecki: that's fine and it will clearly show what's what | 10:59 |
| * pedronis lunch+dentist appt | 10:59 | |
| mborzecki | testing this locally now | 10:59 |
| mborzecki | also made me go through how spread testing is setup, looks like adding arch will not be that complicated | 11:00 |
| zyga-ubuntu | most of the complexity is concentrated in "prepare.sh" where we build snapd and prepare the system for testing | 11:01 |
| mborzecki | while i'm waiting for spread to finish, did anyone get a chance to look at https://github.com/snapcore/snapd/pull/4135#issuecomment-342002622 ? | 11:04 |
| mup | PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135> | 11:04 |
| mborzecki | i'm leaning towards removing tests/main/static and i'm not sure this would be acceptable, but the packaging (fedora, suse) do not build snapd statically, so I don't know what exactly this tests is supposed to check | 11:05 |
| Chipaca | mborzecki: if it's the CGO_ENABLED check, it was because we'd had problems with cgo stuff sneaking in through depends that was impacting memory consumption at one point | 11:06 |
| zyga-ubuntu | mborzecki: commented on your questions | 11:06 |
| Chipaca | and that was an easy way to block it | 11:07 |
| mborzecki | ok, so one alternative way to fix this is to drop CGO_ENABLED=0 and set -extldflags, we can keep the test this way | 11:11 |
| Chipaca | mborzecki: how would that alert us of new cgo bits we didn't know about? | 11:15 |
| Chipaca | (that's basically what we need) | 11:15 |
| mborzecki | i won't, but it doesn't build now either, it did build before because no cgo built pieces were called yet | 11:17 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| Chipaca | mborzecki: well, that's the whole purpose of the test, if it's not working why have it? | 11:21 |
| mborzecki | i could probably rework the group stuff to not call the c library, but instead parse /etc/groups directly, but this is half solution only, and probably 100% correct on musl systems only as glibc is happy to use nss instead | 11:24 |
| zyga-ubuntu | pstolowski: reviewed | 11:29 |
| niemeyer | Hello hello! | 11:35 |
| niemeyer | mborzecki: Welcome! | 11:35 |
| mborzecki | niemeyer: hey | 11:35 |
| mvo | hey niemeyer - welcome back | 11:37 |
| niemeyer | mvo: Thank you | 11:37 |
| niemeyer | Glad to be back | 11:37 |
| zyga-ubuntu | hey | 11:40 |
| mborzecki | zyga-ubuntu: pushed clang test as well | 11:40 |
| pstolowski | thanks zyga-ubuntu | 11:41 |
| pstolowski | hey niemeyer ! | 11:41 |
| Chipaca | mborzecki: what if we just have panic'ing stubs for the no-cgo build? just for this check? | 11:41 |
| niemeyer | Heyos! | 11:41 |
| mborzecki | Chipaca: yeah, this might work | 11:43 |
| zyga-ubuntu | mborzecki: I just sent my review, let me read the new parts | 11:43 |
| kalikiana | hrm, failing to see the forest for the trees, time for a break | 11:44 |
| zyga-ubuntu | mborzecki: added two more comments | 11:45 |
| zyga-ubuntu | mvo: what shall I do with https://github.com/snapcore/snapd/pull/4146 ? | 11:46 |
| mup | PR #4146: interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146> | 11:46 |
| mup | Issue snapcraft#1686 opened: Support strings in grammar <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1686> | 11:47 |
| mup | Issue snapcraft#1687 opened: Make source grammar-powered <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1687> | 11:50 |
| mup | Issue snapcraft#1688 opened: Documentation for advanced grammar for sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1688> | 11:50 |
| mup | Issue snapcraft#1689 opened: Implement "on" and "from" selectors (statements) in project_loader <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1689> | 11:50 |
| mvo | zyga-ubuntu: lets leave it for now if we need a .3 I think we can consider it | 11:52 |
| mvo | zyga-ubuntu: I did not had the mental capacity last friday to include it | 11:52 |
| mup | Issue snapcraft#1690 opened: Design quilt support <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1690> | 11:53 |
| mup | Issue snapcraft#1691 opened: Implement quilt design <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1691> | 11:53 |
| mup | Issue snapcraft#1692 opened: snapcraft quilt tutorial <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1692> | 11:53 |
| mvo | zyga-ubuntu: what would happen if we build snap-cofnine with g++ (i.e. using c++ rules for the C part)? would it explode in size? | 11:54 |
| zyga-ubuntu | mvo: not sure, why would you want that? | 11:54 |
| mvo | zyga-ubuntu: to avoid having to write "foo(void)" when I mean "foo()" | 11:56 |
| mup | Issue snapcraft#1693 opened: Develop metadata handler system <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1693> | 11:56 |
| mup | Issue snapcraft#1694 opened: Develop appstream handler <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1694> | 11:56 |
| zyga-ubuntu | mvo: I don't think that's a very strong reason honestly | 11:56 |
| zyga-ubuntu | mvo: it's not C vs C++, just particular -W flag | 11:56 |
| zyga-ubuntu | perhaps we need to default to C99 or more recent | 11:57 |
| mvo | zyga-ubuntu: I checked and it seems C99 is also considering f() as unknown vs f() as empty (which is what we want) | 11:58 |
| zyga-ubuntu | f() as unknown? | 11:59 |
| mvo | zyga-ubuntu: well, maybe not, it just annoys me that backward compatiblity to 1877 requires us to write a clunky f(void) when e.g. c++ gets this right | 11:59 |
| mvo | zyga-ubuntu: yes, it means "don't assume anything about arguments" | 11:59 |
| mup | Issue snapcraft#1695 opened: Refactor meta into package <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1695> | 11:59 |
| mup | Issue snapcraft#1696 opened: Add schema checking for snap.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1696> | 11:59 |
| mup | Issue snapcraft#1697 opened: Documentation for sources of information extraction <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1697> | 11:59 |
| mvo | zyga-ubuntu: f() means that | 11:59 |
| mvo | zyga-ubuntu: and apparently its for compatibility with older C programs (i.e. before K&R C). which makes me even more sad | 11:59 |
| mup | Issue # opened: snapcraft#1698, snapcraft#1699, snapcraft#1700, snapcraft#1701, snapcraft#1702, snapcraft#1703 | 12:02 |
| mup | Issue snapcraft#1704 opened: Add unit tests for error classes <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1704> | 12:05 |
| mup | Issue snapcraft#1705 opened: Remove the current tests that assert exact error messages and only assert on the error class <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1705> | 12:05 |
| cachio | mvo, hey | 12:29 |
| niemeyer | mvo: Hey, did you start on monthly refresh scheduling already? | 12:30 |
| mvo | niemeyer: I have not started on this yet, I have started on the refresh-control things we talked about before (via snapd-control) | 12:31 |
| mvo | hey cachio | 12:31 |
| cachio | mvo, waiting for the confirmation of the cert team | 12:32 |
| * zyga-ubuntu ->coffee | 12:32 | |
| niemeyer | mvo: Cool, I'm talking to mborzecki and will suggest he pick up that plus timer services shortly after it, if you're okay with that | 12:32 |
| cachio | mvo, other thing, did you take a look to the gsettings app? | 12:32 |
| cachio | snap | 12:32 |
| mvo | cachio: still not, sorry :/ | 12:32 |
| mvo | cachio: is there an open PR for this? | 12:32 |
| mvo | niemeyer: sure, thats fine | 12:32 |
| cachio | mvo, no yet, waiting for the snap in the store | 12:33 |
| mvo | cachio: aha, ok. is it blocking on me uploading it? | 12:33 |
| cachio | mvo, I sent the branch, do you need it? | 12:33 |
| cachio | mvo, yes | 12:33 |
| mvo | cachio: if you could mail me the PR again, that would be great | 12:33 |
| cachio | mvo, there is a branch | 12:34 |
| cachio | mvo, should I create a PR? | 12:34 |
| cachio | mvo, it is gonna fail | 12:34 |
| mvo | cachio: branch is enough, just pass me the link and I have a look | 12:34 |
| mvo | cachio: but after lunch, gtg now :) | 12:34 |
| cachio | mvo, sure, thanks | 12:34 |
| * Chipaca dances | 12:39 | |
| * Chipaca stops for lunch | 12:39 | |
| mup | PR snapd#4154 opened: overlord/snapstate: support completion for command aliases <Created by chipaca> <https://github.com/snapcore/snapd/pull/4154> | 12:40 |
| Son_Goku | mvo, you guys somehow broke snapd packaging for Fedora | 12:49 |
| Son_Goku | it doesn't compile anymore | 12:49 |
| Son_Goku | gobuild: invalid option -- '-' | 12:52 |
| Son_Goku | error: Unknown option - in gobuild(o:) | 12:52 |
| Son_Goku | error: line 370: %gobuild -o bin/snap-update-ns --ldflags '-extldflags "-static"' $GOFLAGS %{import_path}/cmd/snap-update-ns | 12:52 |
| zyga-ubuntu | Son_Goku: there's some tricky quoting there | 12:56 |
| Son_Goku | I already fixed this in my spec in Dist-Git | 12:56 |
| zyga-ubuntu | ah wait | 12:56 |
| zyga-ubuntu | no | 12:56 |
| zyga-ubuntu | s/bin/cmd/ | 12:56 |
| Son_Goku | yeah you just can't do what you did | 12:56 |
| zyga-ubuntu | this is fixed in mater | 12:56 |
| Son_Goku | nope, master is broken too | 12:56 |
| Son_Goku | I tried | 12:56 |
| zyga-ubuntu | ?? | 12:56 |
| zyga-ubuntu | what cannot you do? | 12:56 |
| Son_Goku | %gobuild does not let you pass --ldflags | 12:57 |
| zyga-ubuntu | the problem there is "bin => cmd" | 12:57 |
| Son_Goku | -o is the *output file* | 12:57 |
| zyga-ubuntu | ah | 12:57 |
| zyga-ubuntu | sorry, I must confused this with similar opensuse issue | 12:57 |
| Son_Goku | yeah, openSUSE issue is different | 12:57 |
| Son_Goku | their %gobuild macro works differently | 12:57 |
| Son_Goku | much more complicated | 12:57 |
| zyga-ubuntu | Son_Goku: hmm, but we do build s-u-n statically | 12:58 |
| * zyga-ubuntu wonders | 12:58 | |
| mup | Issue snapcraft#1706 opened: Summary of errors at the end of build <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1706> | 12:59 |
| mup | Issue snapcraft#1707 opened: New UX for travis CI enablement <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1707> | 13:02 |
| mup | Issue snapcraft#1708 opened: Implement new design for travis CI UX <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1708> | 13:02 |
| mborzecki | it's -ldflags not -- | 13:04 |
| mborzecki | Son_Goku: ^^ | 13:05 |
| Son_Goku | ah | 13:06 |
| === alan_g is now known as alan_g|lunch | ||
| jdstrand | mvo: thank you for doing 4151 | 13:15 |
| === andreas is now known as ahasenack | ||
| zyga-ubuntu | jdstrand: hello | 13:18 |
| jdstrand | hey zyga-ubuntu :) | 13:18 |
| jdstrand | mvo: I wonder if we should load a framebuffer module if /dev/fb0 doesn't exist instead of mocking it | 13:20 |
| ogra_ | jdstrand, that might be tricky ... some of the framebuffer modules clash with kms | 13:22 |
| ogra_ | (if we ever get armhf added to the tests) | 13:22 |
| jdstrand | I'm surprised that none of the VMs have an actual device. my Ubuntu Core 16 vm has one | 13:22 |
| jdstrand | I guess cause I chose qxl as the driver | 13:23 |
| ogra_ | x86 should be okay with that though | 13:23 |
| jdstrand | ogra_: interesting | 13:24 |
| jdstrand | mvo: maybe instead of loading it, perhaps we should configure (at least some of) the VMs to have a framebuffer (eg, qxl or similar) | 13:24 |
| jdstrand | mvo: and then it would autoload. I was obviously thinking that the vms would have a framebuffer (all of mine do locally), but if nothing in the test infrastructure does, it means the test is rather pointless | 13:25 |
| mvo | Son_Goku: what is the build error? | 13:32 |
| Son_Goku | mvo: invalid invocation to the macro | 13:33 |
| mvo | Son_Goku: aha, nevermind | 13:33 |
| Son_Goku | I'm merging my changes into the git master spec now | 13:33 |
| Son_Goku | so I'll have a PR in a few minutes | 13:33 |
| mvo | jdstrand: in the standup right now, but you make import points | 13:34 |
| mvo | Son_Goku: \o/ | 13:34 |
| jdstrand | mvo: if you could ping me to discuss whenever is convenient, that would be great | 13:37 |
| Son_Goku | mvo: also, why did snap-confine.1 become snap-confine.5? | 13:41 |
| mvo | Son_Goku: uh, that is a question for zyga-ubuntu | 13:42 |
| Son_Goku | or rather the other way around | 13:42 |
| Son_Goku | it went from 5 to 1 | 13:42 |
| Son_Goku | ah, Debian bug | 13:43 |
| Son_Goku | meh | 13:43 |
| zyga-ubuntu | re | 13:52 |
| zyga-ubuntu | Son_Goku: thank you :-) | 13:53 |
| zyga-ubuntu | Son_Goku: there was a bug about the man page number from debian | 13:53 |
| zyga-ubuntu | Son_Goku: I changed that so the bug could be fixed | 13:53 |
| Son_Goku | yeah, I saw after git blame | 13:53 |
| Son_Goku | I'm surprised no one complained yet about snap being in the wrong section | 13:53 |
| zyga-ubuntu | ah, great, sorry for laggy response, I was on HO | 13:53 |
| Son_Goku | so... I have the beginnings of EL7 support now | 13:53 |
| zyga-ubuntu | Son_Goku: something I can look into this week, | 13:53 |
| zyga-ubuntu | oh, exciting | 13:54 |
| zyga-ubuntu | any issues so far? | 13:54 |
| Son_Goku | it was a pain to get it to compile :/ | 13:54 |
| Son_Goku | https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/ | 13:54 |
| Son_Goku | I think I'm going to have to do more enhancements to the SELinux policy again | 13:55 |
| Son_Goku | since it's completely untested, I don't think I should create the distro target symlink just yet | 13:55 |
| Son_Goku | also, unlike the fedora build, the centos build is vendorized | 13:56 |
| Son_Goku | so a litany of weirdness showed up during the build | 13:56 |
| mborzecki | zyga-ubuntu: do you think we should run c-unit-test-{gcc,clang} with -Werror so that it fails when on warnings? | 13:56 |
| zyga-ubuntu | ok | 13:56 |
| zyga-ubuntu | mborzecki: yes, that's sensible | 13:57 |
| Son_Goku | zyga-ubuntu: this is why I really need those multi-tarball releases as I asked mvo last year | 13:57 |
| mvo | Son_Goku: I was planning to do for the 2.29, do you need one for 2.28.5? | 13:59 |
| mup | PR snapd#4155 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4155> | 13:59 |
| Son_Goku | mvo: nah, I don't care for 2.28 | 13:59 |
| Son_Goku | I'm okay with jank preview crappiness for my copr build for 2.28 | 14:00 |
| Son_Goku | but once I am more comfortable with the snapd build on CentOS, I don't want that anymore | 14:00 |
| Son_Goku | mvo, zyga-ubuntu: PR proposed | 14:00 |
| Son_Goku | this will need to be merged back into 2.29 as well | 14:01 |
| mvo | Son_Goku: thanks! | 14:04 |
| mvo | Son_Goku: https://github.com/snapcore/snapd/releases/tag/2.28.5 now has the "no-vendor" tarball that contains no vendor/ dir - so now we have one tar with vendor and one without. do you need more? | 14:08 |
| Son_Goku | mvo: basically, I just want a no-vendor tarball and a tarball containing *only* the snapd-<version>/vendor/ tree | 14:08 |
| Son_Goku | that way I can include both tarballs in dist-git unconditionally | 14:09 |
| mvo | Son_Goku: aha, only vendor - sure, let me add this too | 14:09 |
| Son_Goku | and only use the latter when I'm doing CentOS builds | 14:09 |
| Son_Goku | because I'm *really* not going to be having zyga-ubuntu do a bunch of go library packages for EL7 | 14:09 |
| Son_Goku | it's not worth it when go is rebased every year | 14:09 |
| Son_Goku | mvo: this multi-tarball configuration will also help you deal with the delta between debian and ubuntu | 14:10 |
| Son_Goku | since debian purges the vendor/ tree | 14:10 |
| mvo | Son_Goku: ok, please check if https://github.com/snapcore/snapd/releases/tag/2.28.5 looks reasonable | 14:13 |
| Son_Goku | mvo: LGTM | 14:14 |
| mvo | Son_Goku: great, thats my updated script now, so things should hpefully be better from now on | 14:15 |
| Son_Goku | :D | 14:15 |
| === alan_g|lunch is now known as alan_g | ||
| Son_Goku | zyga-ubuntu: feel free to give this a go: https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/ | 14:15 |
| Son_Goku | let me know how well it works (or doesn't work!) | 14:15 |
| zyga-ubuntu | I'll install centos | 14:19 |
| mborzecki | i'm out for today, leaving to pick up my kids, maybe I'll push another patch for #4153 | 14:20 |
| mup | PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153> | 14:20 |
| zyga-ubuntu | see you mborzecki | 14:21 |
| kalikiana | meh. was hunting what I thought was a syntax error. until I realized confinement was what prevented parsing from working at all. | 14:25 |
| pedronis | mvo: #4150 looks reasonable but I don't understand the need of the changes in overlord.New | 14:26 |
| mup | PR #4150: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <https://github.com/snapcore/snapd/pull/4150> | 14:26 |
| mvo | pedronis: yeah, I revert that one | 14:28 |
| mvo | pedronis: thank you! | 14:28 |
| pedronis | mvo: do you plan do add helpers? (a bit like assertstate has) to ifacerepo? or just use the repo directly ? | 14:32 |
| pedronis | I suppose it also depends how far is the repo interface to what you actually need | 14:33 |
| mvo | pedronis: no helpers planned so far, the repo is rich enough for my use case | 14:34 |
| mvo | pedronis: but my use case is really simple | 14:34 |
| mvo | :) | 14:34 |
| zyga-ubuntu | the time of day when I change my vim color scheme :/ | 14:35 |
| pedronis | mvo: it's fine, assertstate has helpers, but there's also code that gets DB and does just Find, it depends | 14:35 |
| zyga-ubuntu | aha sunset | 14:35 |
| pedronis | mvo: I'm mostly asked because of the name of the package | 14:35 |
| mvo | pedronis: aha, ok | 14:38 |
| mvo | pedronis: I'm fine using something more generic, no strong opinion but for now that package is all I need | 14:39 |
| mup | Issue snapcraft#1709 opened: Extract macaroon retrieval into more generic place <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1709> | 14:54 |
| mup | Issue snapcraft#1710 opened: Research circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1710> | 14:54 |
| pedronis | pstolowski: added a couple of high-level comments to the cookie PR | 14:55 |
| pstolowski | pedronis, thanks | 14:55 |
| mup | Issue snapcraft#1711 opened: Develop enable-ci circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1711> | 14:57 |
| mup | Issue snapcraft#1712 opened: Tutorial for circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1712> | 14:57 |
| mup | Issue snapcraft#1713 opened: catkin plugin: support for building all packages in a given workspace <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1713> | 15:00 |
| mup | Issue snapcraft#1714 opened: catkin plugin: recursively merge rosinstall files <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1714> | 15:00 |
| mup | Issue snapcraft#1715 opened: catkin plugin: detect and gracefully handle rosinstall clashes <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1715> | 15:00 |
| elopio | sergiusens: meeting? | 15:02 |
| === ahasenack is now known as andreas | ||
| === cachio is now known as cachio_lunch | ||
| Chipaca | hmm, looks like i need to take a bunch of days off | 15:12 |
| Chipaca | pedronis: mvo: niemeyer: any preference as to when i do this? | 15:12 |
| Chipaca | taking the last two weeks of the year off i still have 11 days | 15:14 |
| mvo | Chipaca: nothing in particular, but I have the same issue, I will probably take some days off in early Dec | 15:16 |
| Chipaca | i mean, i could take all of december off | 15:17 |
| Chipaca | but that's probably bad :-) | 15:17 |
| pedronis | I will take the last two weeks of december off | 15:28 |
| Chipaca | pedronis: as well as the shutdown, or including that? | 15:28 |
| pedronis | including shutdown | 15:28 |
| pedronis | I mean off from Dec 18 | 15:29 |
| Chipaca | pedronis: right, even doing that i have 11 left | 15:29 |
| pedronis | you should have taken holidays before :) | 15:29 |
| Chipaca | yes. | 15:29 |
| pedronis | Chipaca: anyway you can keep some for the next year as well, not sure that's a fix though | 15:29 |
| Chipaca | pedronis: i might do something like taking mondays off, and keep what's left for next year | 15:30 |
| Chipaca | or lose 'em, i mean i just took a week off less than a month ago | 15:30 |
| Chipaca | oh, no, i took two days off | 15:30 |
| Chipaca | it _felt_ like a week :-) | 15:30 |
| pedronis | heh | 15:30 |
| Chipaca | see that's the problem :-) | 15:30 |
| zyga-ubuntu | Chipaca: take all holidays on January | 15:32 |
| zyga-ubuntu | problem solved | 15:32 |
| zyga-ubuntu | I need to pick up my daughter as my wife is stuck in traffic, ttyl | 15:32 |
| === nacc_ is now known as nacc | ||
| elopio | sergiusens: the only explanation I see for the timeout is that the plugins suite is taking 100 minutes on autopkgtest. This suite takes 40 minutes in travis, and has worked on autopkgtests until last week, so my guess is that the system is overloaded making everything twice as slow. | 15:44 |
| sergiusens | elopio ok, that could explain it | 15:45 |
| sergiusens | cjwatson any idea how adt hosts are setup ^ ? | 15:45 |
| elopio | we can split the tests in autopkg like we do on travis. But that will be slower because for every test the deb is prepared, but it will give us a bigger margin on the timeout for when the system is overloaded. I'm not sure how often this will be. | 15:45 |
| sergiusens | elopio but these timeouts, are they present on amd64? | 15:46 |
| elopio | I'm looking at arm64. Let me check the amd64 | 15:46 |
| niemeyer | Chipaca: You can roll one of the weeks on to next year, if you want | 15:47 |
| sergiusens | Chipaca taking days off without traveling away from $HOME always makes it feel like it is longer that it should be for me | 15:48 |
| elopio | sergiusens: the result we have available for amd64 shows that suite finishing in 3091s | 15:51 |
| sergiusens | so less than an hour | 15:54 |
| zyga-ubuntu | re | 15:58 |
| elopio | yes. I think splitting makes sense, at least until all our hello world builds take less than 1 minute. It will at least let us worry about real errors and not time outs. | 16:00 |
| === cachio_lunch is now known as cachio | ||
| cjwatson | sergiusens: none, ask Laney | 16:03 |
| cjwatson | sergiusens: (autopkgtest isn't LP, even though we share cloud regions) | 16:04 |
| sergiusens | cjwatson yeah, thanks; just got a hold of him on my random question about queuing on #ubuntu-release | 16:04 |
| sergiusens | apparently a cloud region died and things got bad | 16:04 |
| sergiusens | and the snapd queue which we already discussed on how to make it easier going | 16:05 |
| kalikiana | elopio: do test snapcraft.yaml files versus modifying them on the fly impact this? I was looking into build packages/ snaps tests which are all fixed, but you were suggesting we prefer creating them on the fly | 16:15 |
| kalikiana | kinda wondering if one or the other is faster | 16:15 |
| elopio | kalikiana: I don't think so. We can create a file in a lot less than a second. | 16:19 |
| jdstrand | roadmr: hi! re goby> I think I forget to rerun the review-- I didn't add the comment for granting classic to the snap, so I think I may have granted then got pulled away | 16:37 |
| roadmr | jdstrand: right, it's what I speculated in the bug | 16:37 |
| jdstrand | roadmr: I didn't see the bug. is there anything else I should do? | 16:38 |
| roadmr | jdstrand: I don't think so, the bug was about things being "stuck" but I explained the sequence of events which seems sensible. Let me find it for you | 16:39 |
| roadmr | jdstrand: https://bugs.launchpad.net/snapstore/+bug/1729826 | 16:39 |
| mup | Bug #1729826: "Waiting for previous upload" when none in review queue <Snap Store:New> <https://launchpad.net/bugs/1729826> | 16:39 |
| elopio | sergiusens: do you know why our ppa is not building for armhf and arm64? | 16:40 |
| jdstrand | roadmr: thanks | 16:43 |
| mup | PR snapd#4156 opened: overlord/devicestate: switch to the new endpoints for registration <Created by pedronis> <https://github.com/snapcore/snapd/pull/4156> | 16:45 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | elopio our ppa? snapcraft is architecture all | 17:16 |
| elopio | sergiusens: ahhh, of course, that is why it builds only once. | 17:19 |
| elopio | so, we won't have the unittests running in different architectures every day, but that's probably fine. | 17:21 |
| sergiusens | elopio what is this about building a deb everyday? | 17:42 |
| * sergiusens steps away for a bit | 17:42 | |
| elopio | sergiusens: just trying to get rid of the make_beta_pr. It runs nightly, just as the PPA. So instead of making a branch, it would be better to run the autopkgtests on the PPA every night. | 17:44 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| === alan_g is now known as alan_g|EOD | ||
| mup | PR snapcraft#1716 opened: tests: split the integration autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1716> | 18:07 |
| * Chipaca EODs | 18:35 | |
| cachio | zyga-ubuntu, do you see he network-status interface when you list the interfaces? | 18:57 |
| jdstrand | cachio: I don't have context, but note that network-status is not an implicit slot. you need a slot implementation | 18:58 |
| cachio | jdstrand, ah, ok | 18:59 |
| cachio | jdstrand, tx, thats make sense now | 19:00 |
| jdstrand | cool | 19:00 |
| cachio | jdstrand, any idea why is it implemented in that way? | 19:01 |
| jdstrand | cachio: because the core snap and the classic system doesn't ship connectivity-api by default | 19:02 |
| jdstrand | implicit slots are for things that are expeccted to always be provided by the host OS | 19:02 |
| cachio | jdstrand, but the network-control is pretty similar and it is implicit | 19:04 |
| jdstrand | cachio: network-control allows using various tools that are avaialble inn the core snap or the classic distro | 19:05 |
| jdstrand | cachio: network-status allows using a dbus api provided by the connectivity-api deb from Touch | 19:05 |
| cachio | jdstrand, ah, ok | 19:05 |
| cachio | jdstrand, thanks for the explanation | 19:06 |
| jdstrand | cachio: ie, the core snap provides the things that are made avaialble via the interface. that is what makes it implicit. if it does not, then a slot implementation must provide it | 19:06 |
| zyga-ubuntu | cachio: looking | 19:06 |
| jdstrand | zyga-ubuntu: you don't have to | 19:06 |
| zyga-ubuntu | cachio: ah, I see jdstrand already answered | 19:07 |
| jdstrand | zyga-ubuntu: I answered the question | 19:07 |
| zyga-ubuntu | thank you :) | 19:07 |
| jdstrand | np | 19:07 |
| cachio | thanks guys | 19:07 |
| zyga-ubuntu | thank you for working on tests :) | 19:07 |
| zyga-ubuntu | jdstrand: FYI, tmpfs is in final stages of polish, expect a swarm of small PRs that make everything work nicely, spread and unit tests | 19:07 |
| jdstrand | ok | 19:08 |
| zyga-ubuntu | jdstrand: I'm adding support for files and symlinks which will also be handy for layouts (implementing this gives us all the designed building block of layouts now) | 19:08 |
| jdstrand | zyga-ubuntu: note I'm still in the throes of investigating various issues | 19:08 |
| zyga-ubuntu | throes? | 19:08 |
| jdstrand | sorry | 19:08 |
| jdstrand | I'm very busy lately investigatin the fallout of the udev tagging PR | 19:09 |
| zyga-ubuntu | ah, I see | 19:09 |
| zyga-ubuntu | thank you for doing that | 19:09 |
| zyga-ubuntu | let me know if I can help | 19:09 |
| jdstrand | getting through things, but still getting different reports | 19:09 |
| zyga-ubuntu | I pushed a PR related to udev tagging of hooks | 19:09 |
| jdstrand | I also have some spread tests I'm working on to fill some testing gaps I noticed | 19:10 |
| zyga-ubuntu | anything worrying from the reports you are getting? | 19:10 |
| jdstrand | nothing that seems terribly widespread | 19:10 |
| jdstrand | but things that are affecting people | 19:11 |
| jdstrand | (corner rcase type things I think is what's left) | 19:11 |
| * zyga-ubuntu nods | 19:12 | |
| kyrofa | elopio, whatever happened to re-using the cache in integration tests? | 19:13 |
| elopio | kyrofa: we didn't notice any improvements on travis. I started measuring the tests, and decided first to remove the duplicates which reduced 10 minutes. | 19:17 |
| elopio | after 2.35 we can reopen it and measure again | 19:17 |
| kyrofa | elopio, ah yes, okay. I'm adding another ROS test, FYI | 19:17 |
| elopio | kyrofa: ok. And any reason for putting it in the integration suite instead of the snapcraft-de-noche like we did with the lunar one? | 19:20 |
| kyrofa | elopio, those run too late, man. And they're so easy to forget about | 19:21 |
| kyrofa | All these ROS tests pull the same thing. If we had caching it wouldn't be the time suck that it is | 19:22 |
| elopio | kyrofa: ok. Lets try sharing the cache again :) | 19:23 |
| kyrofa | Lunar is a little different. That test ensures support, but that's all it needs to do. We have various other kinetic tests that all do the same, but slightly different things | 19:24 |
| kyrofa | Caching would make one test take a while, and all others take two minutes | 19:24 |
| kyrofa | Although if we're _already_ running into disk space issues that may be a problem | 19:25 |
| elopio | maybe we can remove the slow tag. But while we have that, remember that the ros tests will run once a day, just as late as snapcraft-de-noche. | 19:25 |
| kyrofa | elopio, not all of them are marked slow, just the snapd ones | 19:25 |
| kyrofa | elopio, also, triggering autopkgtest runs is easy, triggering de-noche tests... ? | 19:26 |
| kyrofa | (note that I'm not adding another snapd test, just a good old integration test) | 19:26 |
| elopio | we will have to see if it's because of tmpfs. But if it's not, we need a solution, so ask for more space on the runnners. | 19:26 |
| kyrofa | Indeed | 19:26 |
| elopio | kyrofa: a good old *slow* integration test :) I have no problem with this, if the test is needed, and we need to run it on each PR, we have to deal with the delay. I'm just making the questions, because the past two weeks have been sad because of slow tests. | 19:28 |
| kyrofa | elopio, hahaha | 19:29 |
| kyrofa | elopio, of course, you're doing your job ;) | 19:29 |
| kyrofa | elopio, but yeah, I need to make sure this behavior doesn't regress | 19:29 |
| elopio | it seems that our plugins will always be slow, so our suite will always be slow. Lets parallelize through splits and explore other options like the cache. | 19:31 |
| kyrofa | elopio, how is Travis looking today? Think it could handle a little experimentation? | 19:31 |
| kyrofa | I want to propose my ROS PR, and also propose that same PR with your caching rebased on top, and compare the two | 19:32 |
| elopio | kyrofa: the integration_tests/plugins suite is already big, so we might be forced to do it, not just for fun. | 19:33 |
| kyrofa | elopio, yeah that probably needs to be done | 19:33 |
| kyrofa | elopio, though note that this test is actually going into integration_tests/ itself. Are you trying to migrate those elsewhere? | 19:35 |
| elopio | kyrofa: why on integration_tests if it's for a plugin? souldn't it go in itnegration_tests/plugins? | 19:35 |
| kyrofa | elopio, also, you're trying to toast the snaps_tests, right? | 19:35 |
| kyrofa | elopio, because it was already there, I was just adding to it | 19:35 |
| elopio | kyrofa: yeah, no more snaps_tests please. | 19:36 |
| kyrofa | elopio, this PR will actually _remove_ one then, ;) | 19:36 |
| elopio | kyrofa: that sounds wrong, but lucky wrong because the integration_tests suite has a little more room than the plugins one. | 19:37 |
| elopio | kyrofa: you can experiment locally with the shared cache, just adding a timer like https://stackoverflow.com/a/9502897/2665322 | 19:37 |
| kyrofa | elopio, oh yes of course, good call | 19:37 |
| kyrofa | elopio, well, if I move these both into plugins I guarantee it'll run over. Shall we split first | 19:38 |
| kyrofa | ? | 19:38 |
| elopio | kyrofa: yes, I think we first refactor to have everything in snapcraft/tests/integration | 19:39 |
| kyrofa | elopio, agreed | 19:39 |
| elopio | then we can split snapcraft/test/integration/plugins/ros and snapcraft/tests/integration/plugins/others | 19:39 |
| kyrofa | elopio, I'll rebase to build on that branch | 19:39 |
| kyrofa | elopio, haha, great idea | 19:39 |
| kyrofa | Okay, got it | 19:40 |
| kyrofa | I'll do that, then experiment with caching with that single suite | 19:40 |
| elopio | not great, but well, we don't have many options. My experiment running cleanbuilds in parallels was a lot slower than one thread of normal builds :( | 19:41 |
| kyrofa | Yeah, not surprising :( | 19:42 |
| kyrofa | Oh wait, I can't build on that test refactor, this needs to land for this release | 19:51 |
| kyrofa | I'll just propose in the integration_tests suite for now | 19:51 |
| zyga-ubuntu | pedronis: around? | 19:53 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4141 what happened here? | 19:53 |
| mup | PR #4141: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/4141> | 19:53 |
| pedronis | zyga-ubuntu: no, clue I didn't push to that branch, I don't even have it around | 19:58 |
| pedronis | also the commit are marked as mvo too | 19:59 |
| zyga-ubuntu | pedronis: ah, mvo must have rebased something oddly | 19:59 |
| zyga-ubuntu | no worries, I'll check it out tomorrow | 19:59 |
| * zyga-ubuntu -> EOD | 20:00 | |
| === JanC is now known as Guest24940 | ||
| mup | PR snapcraft#1717 opened: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 20:25 |
| sergiusens | pedronis cachio I've been looking at your PRs that have been merged and noticed that almost none waited for adt to finish running; given the queue for adt is being starving due to so many snapd requests on the upstream queue, mind disabling the adt hooks you guys have (temporarily at least). | 21:02 |
| sergiusens | I did tell mvo earlier today about our process and mentioned elopio mind be able to help cachio | 21:03 |
| kyrofa | snappy-m-o, autopkgtest 1717 zesty:amd64 | 21:05 |
| snappy-m-o | kyrofa: I've just triggered your test. | 21:05 |
| kyrofa | sergiusens, the shebang fix in post-build won't work. Not even post-pull will work, as we need to make sure shebangs are fixed for stage-packages that are used as part of pulling | 21:07 |
| mup | PR snapcraft#1653 closed: internal: don't reuse variable in OsRelease <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1653> | 21:07 |
| sergiusens | kyrofa oh right; pre-build then? | 21:08 |
| kyrofa | sergiusens, it needs to happen in the repo | 21:08 |
| sergiusens | kyrofa as part of unpacking? Like all other things? | 21:09 |
| kyrofa | sergiusens, yeah, which is where it is right now | 21:09 |
| kyrofa | sergiusens, but then we also need it post-build | 21:09 |
| kyrofa | And pre-build | 21:09 |
| kyrofa | Heh | 21:09 |
| sergiusens | kyrofa I still think that `unpack` should eventually be something triggered by pre-pull and pre-build | 21:09 |
| sergiusens | kyrofa as in the directive to do something should be something a user could override | 21:10 |
| sergiusens | that is the gist of it | 21:10 |
| kyrofa | So: repo for stage-packages that might be used for pulling. pre-build for source that needs to be fixed before building, and pre-stage for fixups in order to be useful in staging (and the snap in general) | 21:10 |
| kyrofa | Yeah you're probably right there | 21:10 |
| sergiusens | kyrofa doing it in unpack right now is fine as we do a bunch of other things that should be overrideable there | 21:11 |
| kyrofa | sergiusens, it really comes down to this: we currently don't have pre/post. But we currently are doing the shebang fix in unpack as well as pip, python plugin, and catkin plugin | 21:11 |
| kyrofa | sergiusens, in the interest of not needing to play whackamole with this shebang bug, I'd like to make those all go through the same codepath | 21:12 |
| kyrofa | Where should that be with the view of having pre/post? | 21:12 |
| mup | PR snapd#4157 opened: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157> | 21:13 |
| kyrofa | I can just throw in in internal/common for now, then we can refactor it when we use pre/post | 21:17 |
| kyrofa | That's better than file_utils because that's public | 21:17 |
| sergiusens | kyrofa internal.mangling ? | 21:18 |
| kyrofa | Hey, not bad | 21:18 |
| sergiusens | it is settled then | 21:18 |
| kyrofa | Done | 21:19 |
| mwhudson | heh i now have the 4th oldest snapcraft and the oldest snapd pr | 21:25 |
| mwhudson | the snapd one still being open is definitely my fault though | 21:25 |
| mup | PR snapcraft#1718 opened: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718> | 21:25 |
| sergiusens | mwhudson it is marked 2.36, as soon as adt is freed up and we can release 2.35 we will focus on those | 21:28 |
| mwhudson | sergiusens: it also has conflicts i haven't resolved so i'm not too bitter :) | 21:28 |
| mwhudson | sergiusens: and it would make sense to do #1718 first in any case | 21:28 |
| mup | PR #1718: daemon,overlord: add subcommand handling to snapctl <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1718> | 21:28 |
| mwhudson | mup: bad bot | 21:29 |
| mup | mwhudson: Roses are red, violets are blue, and I don't understand what you just said. | 21:29 |
| kyrofa | mwhudson, looks like that PR _definitely_ happened first | 21:29 |
| mwhudson | snapcraft#1718 | 21:29 |
| mup | PR snapcraft#1718: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718> | 21:29 |
| mwhudson | eh | 21:29 |
| mwhudson | *heh | 21:29 |
| mwhudson | (can't type today) | 21:29 |
| sergiusens | ah, kalikiana or kyrofa mind looking at that ^? I am going to be signing off soonish, it has been a very long Monday in front of my computer. | 21:34 |
| kyrofa | Sweet, I'll check it out | 21:34 |
| mwhudson | i haven't managed to run the tests yet so we should let travis do it's thing i guess... | 21:35 |
| kyrofa | Alright, I'll take a look in a few then | 21:35 |
| elopio | Alright, trying something new here. Weechat relay+SSL to sync with the android app | 22:45 |
| elopio | IRC fun never ends. | 22:46 |
| kyrofa | elopio, haha, welcome back! | 23:04 |
| cachio | cwayne, hey, can't access to the bug that is in the email | 23:14 |
| cachio | https://bugs.launchpad.net/plano/+bug/1727783 | 23:14 |
| sergiusens | elopio, snap install thelounge | 23:28 |
| elopio | sergiusens: I tried that, hated it. | 23:29 |
| elopio | And anyway, it's almost as complicated as this one. I would also need letsencrypt for the lounge. | 23:31 |
| sergiusens | Yup | 23:32 |
| * elopio goes to exercise. I'll be back in 1 hour. | 23:34 | |
| * sergiusens goes into airplane mode | 23:38 | |
| * mwhudson finds FakeLxd | 23:39 | |
| mup | PR snapcraft#1719 opened: many: account for python shebang ars in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719> | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!