[00:06] PR snapcraft#1113 opened: repo: cache stage packages for faster future use === markusfluer1 is now known as markusfluer === chihchun_afk is now known as chihchun === JanC is now known as Guest57353 === JanC_ is now known as JanC [06:43] ogra_, I am now using your proxy snap for building snap. when I build nodejs project, it still downloads the node-v4.4.4-linux-x64.tar.gz from internet. it is not cached. is there any way to solve the problem? it is really slow. [07:04] PR snapd#2771 closed: debian: update changelog from releases 2.22.{1,2} [07:08] PR snapd#2558 closed: snapstate: move refresh from a systemd timer to the internal snapstate Ensure() [07:12] PR snapd#2764 closed: tests: disable ubuntu-core->core transition on ppc64el (its just too slow) [07:15] PR snapd#2754 closed: tests: improve debug when the core transition test hangs [07:33] PR snapd#2772 closed: interfaces: allow nice/setpriority to 0-19 values for calling process by default [07:35] PR snapd#2750 closed: interfaces/default: don't allow TIOCSTI ioctl [07:36] PR snapd#2796 closed: Fix checks failing on code formatting [07:55] PR snapd#2797 opened: tests: stop tying setting up staging store access to the setup of the state tarball [08:22] Bug #1662452 opened: A snap tries to continue setting up a systemd service, even if download failed [08:32] hi there just wanted to include an icon as mentioned here [1], but snapcraft calls it unexpected. Was "icon" deprecated? And how do i include my icon now? .desktop? [08:32] 1: https://snapcraft.io/docs/build-snaps/metadata [08:34] PR snapd#2757 closed: tests: add regression spread test for #1660941 [08:40] PR snapd#2798 opened: interfaces/builtin: instead of just /proc/bus/pci/devices allow full read access on /proc/bus/pci [08:40] mvo: can you add the PR above for 2.23? [08:42] morphis: sure [08:45] mvo: thanks! [08:57] PR snapd#2799 opened: tests: fix pattern and use MATCH in find-private [09:01] PR snapd#2795 closed: Only add aliases field when we have aliases [09:38] liuxg, well, my packageproxy only operates .deb packages ... i suspect you would have ot hack up the nodejs plugin to use a local tarball for this [09:39] ogra_, yeah, this is too troublesome.. the developers in my last sprint was desperate in downloading the package again and again. [09:41] liuxg, well, the plugins are only python. cant be to hard to make this one use a local tarball instead of downloading it [09:41] liuxg, also file a bug so the snapcrafters can add an option for this [09:41] there is one :) [09:41] ogra_, yeah, I will do it. thanks. really? what is the bug number? [09:42] I thin the issue is that snapcraft often requires "gah, doesn't work - snapcraft clean" workflow [09:42] sergiusens, is it somehow possible to prevent the nodejs plugin from downloading the tarball all the time ? [09:42] and then you are stuck with downloading over and over [09:42] liuxg, i said you should file a bug :) [09:42] ogra_, OK. I will do that, thanks [09:42] zyga, right, but you should be able to make it skip the downloading and make it use a local version of the tarball [09:43] that cant be to hard [09:43] ogra_: no, it just just be smarter [09:43] ogra_: implementing a fix for the bug ev logged a while back will do the trick [09:43] zyga, what if you dont want to download it at all ? [09:43] PR snapd#2797 closed: tests: stop tying setting up staging store access to the setup of the state tarball [09:43] ogra_: you don't want to hand-hold the process, you just want the process to be less silly [09:43] smartness wont help [09:44] ogra_: I don't understand what you mean, [09:44] ogra_: if your snapcraft is offline then it will work offline [09:44] ogra_: if it is not offline, you need to get them [09:44] ogra_: and be super smart on caching [09:44] ogra_: I am going to implement something similar to the python plugin where if it is staged (dump it) you won't need to download [09:44] most of the times i agree ... but in a presentation where you already use a package proxy for the debs and your internet is 2G based you better down download at all [09:44] ogra_: adding a gazillion options won't be useful as nobody will really feel good about that (hard to find, quirky, why it it even an option) [09:45] make it not an option, make it an env var (and consider not documenting it) [09:45] program --dont-be-silly-and-broken=3 [09:45] ogra_: when I get xenial on my tablet I will be able to work from bed and be much more productive btw ;-) [09:45] zyga, rather --dont-use-the-great-chinese-wall [09:46] thats the issue here [09:46] so what are the options? [09:46] where do people get those bits from? [09:46] moon? :) [09:46] zyga, in the workshop the presenter shares them [09:46] I see [09:46] he downloaded it in davance over night [09:47] if snapcraft had caching sufficient to do "snapcraft cache" [09:47] then one option would be to copy that tree over to everyone [09:47] but there are many things that are tricky to do caching / offline work right [09:47] the point is that liuxg has limited time forhis workshops ... debs already use a package proxy ... but the plugin still downloads [09:47] I bet sergiusens know this far better than I even imagine the problem [09:48] yeah, i'm fine with copying a cache ... as long as you cover this usecase [09:48] not everything needs to be an option ;) you can make it a hidden feature, a cache dir to copy, a hidden env var etc [09:49] zyga, ogra_, yes, that is the point. during a workshop, the download of the nodejs can be tedious, even in my daily work. it takes a few minutes to get it done. [09:52] ogra_, I have reported a bug for it. https://bugs.launchpad.net/snapcraft/+bug/1662464, thanks for your help [09:52] Bug #1662464: node-v4.4.4-linux-x64.tar.gz is downloaded again and again during the build of a snap [09:54] sergiusens, is there any way to use the nodejs from the cache? thanks [10:04] mvo, ping [10:05] JerryKao: pong [10:06] hi mvo, how to check snapd version in core system? [10:06] snap version [10:06] like on a classic system [10:07] ogra_, thanks [10:32] PR snapd#2799 closed: tests: fix pattern and use MATCH in find-private [10:34] ara: one quick question - what is the output of "snap version" in the non-chatty version that fails for you? [10:35] mvo, 2.22.1 [10:37] thanks [10:37] Bug #1662357 changed: Can't use lsb_release on Ubuntu Core 16 [10:38] mvo, would you be opposed if i made lsb_relese non-executable with a build time hack on the core images ... we're always getting bugs for it [10:38] ogra_: hm, can we remove it entirely? [10:38] i can rm it but not remove the package easily [10:39] we also need it in the classic tarball ... there i made it work fine [10:39] ogra_: right, either way is fine with me then, rm the binary feels slightly cleaner [10:40] no prob, will do that then ... [10:41] ta [11:35] PR snapd#2677 closed: snap: improve the error message for `snap try` === hikiko is now known as hikiko|ln === chihchun is now known as chihchun_afk [12:15] PR snapd#2800 opened: daemon: show "$snapname (delta)" in progress when downloading deltas [12:23] PR snapd#2801 opened: snap-confine: add the key for which hsearch_r fails [12:27] Hi guys, has anyone here tried to upgrade/change the kernel in ubuntu core? [12:28] kw: hey, can you be more specific? the kernel is reglarly updated [12:29] zyga, well ... [12:29] Yes, sure. Let me rephrase. [12:30] kw, what hardware ? [12:32] I'm using up board with ubuntu core installed. The original goal is to overclock the cpu frequency a little bit but it seems that the kernel wouldn't allow. ( not sure how to confirm) [12:33] We have a working one beside (up board with legacy ubuntu 14.04 and higher cpu freq) [12:33] that's probably where the guess is from [12:34] so I'm thinking the possibilities to upgrade the kernel in ubuntu core [12:35] it would be appreciated, if anyone could give any recommendation, [12:35] kw: you will need to roll your own kernel snap [12:35] kw: and a model assertion that describes that [12:35] kw: and (AFAIK, could be wrong) a gadget snap [12:36] yes ,I was also thinking about that and I found this [12:36] https://docs.ubuntu.com/core/en/guides/build-device/image-building [12:36] not sure if this is the manual I should follow. the information is limited though [12:38] kw: the kernel and gadget need to be signed by your "brand" key [12:38] kw: you will need to build an image with that assertion [12:38] kw: you cannot change a kernel on an already running device (only the brand can do that) [12:38] kw: not sure, [12:41] zyga, hmm, its an ATOM, i would expect our pc kernel snap to work on this [12:41] ogra_: yeah, it should work [12:41] I see [12:41] i rather think you want your own gadget and modify cmdline options [12:42] is there tutorial or instruction for creating custom kernel and gadget snap? [12:42] and possibly ship some sysctl.d files [12:43] kw, https://github.com/snapcore/pc-amd64-gadget [12:43] pull that, install snapcraft on your desktop ... then run snapcraft in the toplevel dir [12:43] and indeed make changes before calling snapcraft as needed :) [12:44] yes, this also works for me. thanks [12:45] with ubuntu-image you just need to use the --extra-snaps option and point to your snap then [12:45] the local one will override the one from the store [12:47] I see. [12:48] I think I'll give it a try first and see how it goes. [12:48] I'm not familiar with snap enough yet [12:48] many thanks :) === hikiko|ln is now known as hikiko [12:53] just ask if you run into more issues :) [13:13] PR snapd#2801 closed: snap-confine: add the key for which hsearch_r fails [13:22] hey all [13:22] has anyone got experience with creating a snap package where git binary is needed for the application you're snapping (e.g. NPM)? [13:23] add git-core to build packages or some such [13:23] or just the toplevel 2git" [13:23] *"git" [13:24] joedborg: could be hairy (it will pull in perl and a zoo of other bits I bet) but you can try [13:24] thoug, doesnt the nodejs plugin provide all bits needed for npm builds ? [13:25] i've tried adding it as a build-package and stage-package as well as a separate part and build it [13:25] but it always says that the "https helper is missing" [13:25] so it can't pull any https repos [13:25] I'm trying to package bower [13:25] NPM was just an example [13:26] try libcurl4-openssl-dev in build-packages [13:26] yep, I've tried that too [13:26] i think that provides https [13:26] as well as - gettext [13:26] - libssl-dev [13:26] - libcurl4-openssl-dev [13:26] - libexpat1-dev [13:27] and adding the --with-curl and --with-expat flags to the configure [13:27] and then given it home and network plugs [13:28] err, wait, you are trying to run git *inside* your snap at execution time ?? [13:29] ogra_: yes [13:29] ah, i misunderstood [13:29] joedborg: I'd suggest trying to usea classic confinement snap [13:29] zyga: yeah, I made the snap like that originally but want to try to get it into strict confinement [13:32] joedborg: depending on what you want from git (I suspect npm just wants to clone) [13:32] joedborg: you could build a super small git version in your snap [13:32] joedborg: just enough to have basic bits written in C [13:32] joedborg: should be simple and fast [13:32] joedborg: (build git from source, disable all the useless option) [13:34] zyga: you mean write my own, calling libgit? [13:34] joedborg: no, just build upstream git but trim all the deps [13:34] joedborg: npm doesn't need 99% of git, just git clone I suspect [13:34] joedborg: and a minmal build of git from source should be good [13:34] joedborg: and you can pick any version you want :) [13:35] zyga: yes, that's what I've also been trying, but if I cannot build the current source with git-http, I think I'd have the same issue even if i cut the bloat out, right? [13:36] joedborg: what's the problem with building? [13:36] zyga: git: [13:36] source: https://github.com/git/git [13:36] source-type: git [13:36] source-depth: 1 [13:36] plugin: autotools [13:36] configflags: [13:36] - --with-curl [13:36] joedborg: bloat may be built-in (deps) [13:36] - --with-expat [13:36] build-packages: [13:36] - gettext [13:36] - libssl-dev [13:36] - libcurl4-openssl-dev [13:36] - libexpat1-dev [13:36] stage-packages: [13:36] - libcurl3 [13:36] joedborg: rather than pasting here please use pastebin, irc likes things this way [13:36] this builds without warnings [13:36] joedborg: does it work in the end? [13:37] joedborg: note that I'm not a snapcraft expert, I work on snapd internals [13:37] joedborg: perhaps sergiusens or kyrofa can give you better advice [13:37] zyga: okay, here is is as a Gist https://gist.github.com/joedborg/c496eaa6de26a14d73b55a6db372f531 [13:39] and the build looks okay, I even see "checking if Curl supports SSL... yes" [13:40] joedborg: and what is the part that doesn't work? [13:42] zyga: but then, if i install with --devmode (to see what's going on) and try to get bower to pull something (which is done via git) I get "Failed to execute "git ls-remote --tags --heads https://github.com/jquery/jquery-dist.git", exit code of #128 fatal: Unable to find remote helper for 'https'" [13:44] joedborg: what probably happens is that your git looks for /usr/bin/something [13:44] joedborg: and that's not found there [13:45] joedborg: apart from teaching git to use $SNAP and be smarter [13:45] joedborg: I'd suggest configuring with --prefix=/snap/$SNAP_NAME/current/usr [13:45] joedborg: and changing the installed files with organize [13:45] joedborg: so that your snap contains just the /usr part [13:45] joedborg: I did that a few times when apps love to hardcode where to run stuff from [13:46] joedborg: otherwise it just looks for files in the usual spot and they are not there [13:46] zyga: that makes sense, because the helper should be in "/snap/libexec/git-core" [13:46] joedborg: look at the output of `dpkg -L git` [13:46] joedborg: this is where git keeps all the commands [13:46] zyga: so I guess it's an environment problem [13:46] joedborg: play with --prefix and other bits [13:46] joedborg: I bet you can get it to work [13:47] joedborg: environment? [13:48] zyga: if that's the case, I think I'd just need to add libexec/git-core to $PATH inside the snap [13:48] joedborg: depending on how git runs those [13:48] joedborg: if it uses PATH to search, yeah [13:48] joedborg: if it has a hard-coded path, you need to do more [13:48] I've just got to work out how to do that from snapcraft [13:49] joedborg: --prefix=/snap/yoursnapname/current/usr [13:49] joedborg: then use organize [13:49] joedborg: (in the part) [13:49] joedborg: to strip that so that only usr is placed in the prime dir [13:51] PR snapd#2768 closed: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default [13:51] https://git-scm.com/book/tr/v2/Git-Internals-Environment-Variables#Global-Behavior [13:51] you migth want to use a wrapper around git that sets some of these global vars ;) [13:51] ogra_: yeah, nice [13:51] joedborg: GIT_EXEC_PATH [13:52] though I think building git with correct prefix is pretty good too [13:52] zyga: trying the prefix first, can't work the syntax out for setting envars in snapcraft yaml [13:53] joedborg: you need a wrapper script or latest snapcraft [13:53] (it's a new feature in snapcraft) [13:53] sergiusens: ^^ [13:53] ah, did that land already ? [13:54] not sure, it might have [13:54] zyga: i'm on 2.26 [13:54] i saw a commit but didnt follow the status [13:59] zyga: you get the same issue when setting prefix - i assume because path still isn't pointing to the libexec/git-core directory [13:59] joedborg: note that that is not on PATH in any distro either [13:59] joedborg: look at what git is doing internally [14:00] PR snapd#2746 closed: interfaces: remove some syscalls already in the default policy plus comment cleanups [14:00] GIT_EXEC_PATH is the one that needs to point to libexec/git-core [14:01] (check on any ubuntu install with "git --exec-path" ... it should return /usr/lib/git-core) [14:01] (which has all the binaries) [14:01] ogra_: question is, how does git decide on that value? [14:02] why does that matter as long as it respects your override [14:02] ogra_: it matters to know how git works as this may be something we may fix in general [14:02] i guess it is set at build time normally [14:02] ogra_: depending on ... ? prefix? [14:02] combo ... [14:03] at build time i guess prefix is just /usr [14:03] so it combines with the distros typical libexec path [14:03] which is lib in our case [14:07] ogra_ zyga: would that be baked in when git is packaged for apt? i don't think we have any GIT_* envars set [14:07] the vars are for user overrides ... so indeed they are not set by the package :) [14:07] they are nontheless the right thing to use in a snap [14:08] orga_: do you know if this can be passed in via snapcraft? [14:08] https://github.com/snapcore/snapcraft/pull/1103 is the commit adding support for that to snapcraft btw [14:08] PR snapcraft#1103: meta: support for the environment keyword [14:08] merged 23h ago [14:09] okay, I'll pull master down and built it and try with that [14:09] hah [14:10] look at the changed files there ... there is even: [14:10] + PATH: $PATH:$SNAP/libexec/git-core [14:10] + GIT_TEMPLATE_DIR: $SNAP/share/git-core/templates [14:11] so exactly what you want [14:20] PR snapd#2802 opened: snap-confine: make sc_map_search/read_number take const const char * arguments [14:24] ogra_: just getting through the snapcraft master build :) [14:30] PR snapd#2803 opened: asserts: introduce a variant of model assertions for classic systems [14:38] ogra_: seems to still fail the YAML check [14:56] PR snapd#2770 closed: interfaces/core-support: allow modifying snap rsyslog configuration [14:59] ogra_: fyi ^ [14:59] \o/ [14:59] jdstrand, next is timesyncd :) [14:59] ogra_: I'm sending up a PR for /etc/systemd/timesyncd.conf now [15:00] hah, snap [15:00] yep! :) [15:00] :) [15:00] and then the more complex sysctl.d [15:00] oh, I haven't seen that one. is there a bug? [15:00] though thats only complex on the configure hook side ... [15:01] hmm, not sure, let me search [15:01] bug 1485683 and bug 1552679 [15:01] Bug #1485683: /etc/sysctl.d is not applied on boot [15:01] Bug #1552679: snappy config ubuntu-core should get support for manipulating /etc/sysctl.conf [15:02] hmm. probably only the latter one [15:03] ogra_: do you want to modify /etc/sysctl.conf or /etc/sysctl.d/{,[0-9][0-9]-}snap*.conf ? [15:03] yeah, one fixed filename would be enough though [15:04] i doubt we will use multiple files since the configure hook needs to generate all of it on every run [15:04] ogra_: shall I send something up for that? [15:04] that would be awesome [15:04] ok [15:06] ogra_: will you be applying the sysctl values in the config hook or some other way? [15:07] the config hook will create or re-create the file if it runs [15:08] ogra_: will the config hook also run 'sysctl -p /etc/sysctl.d/'? [15:08] i'd like a more atomic way, but the current implementation of the config handling doesnt provide that ... i could create a file per option but i fear that gets messy [15:08] oh, i didnt think of that, yeah it should immediately apply the new settings with sysctl -p [15:09] Elleo: so my in-progress unity8 interface had some maliit access bits and jdstrand pointed me to your maliit interface branch. jdstrand, how granular do we want those to be? Elleo, do we plan to ship the OSK separate from the unity8 snap? [15:12] mterry: when I'd suggested including maliit access in the unity8 interface tvoss wasn't very keen on the idea, so might be a good idea to check up on his thinking there [15:12] mterry: FYI: one snap can use many interfaces [15:13] mterry: but we're likely to have scenarios where we want the OSK but not unity8 (e.g. probably in kiosk cases) [15:13] I figured that maliit and unity8 interfaces would be separate, but unity8-session snap would slots both [15:13] zyga: I know, it's just a matter of what we want app developers to put: "[maliit, mir, unity8]" or just [mir, unity8] [15:13] jdstrand, hey I understand you might be the person to talk to about getting auto-aliases added to my snaps in the snapstore - is that right? [15:14] jamespage: I am one person who can help with that, yes [15:14] Elleo, jdstrand: OK I can take the maliit bits out of u8 [15:14] mterry: I think the former ([maliit, mir, unity8]). this can all be made the default in the sdk [15:14] for the unity8 tempalte [15:15] yar [15:30] PR snapd#2804 opened: interfaces/core-support: allow modifying systemd-timesyncd and sysctl configuration [15:31] ogra_: fyi, ^ === qengho_ is now known as qengho [15:31] yeah, just saw it pass on telegram :) [15:31] fun :) [15:31] mup is everywhere ! [15:31] heh [15:35] We're snapping an application that calls out to iptables - is there a way to do that without classic confinement? We've looked into using the network-control plug, but that doesn't appear to have the juju we need. [15:36] ogra@localhost:~$ snap interfaces|grep firewall [15:36] :firewall-control - [15:36] :) [15:37] not sure thats available on classic installs though ... [15:37] (i see it exposed there ...) [15:40] Thanks ogra_ [15:43] ogra_: i'm rebuilding a snapdragon image from scratch, and it stops at "/scripts/local-premount" - does it ring any bell? [15:43] ppisati, how did you rebuild ? [15:43] ogra_: right, i didn't explain well enough [15:44] (do you have a "writable" label, else the boot will wait for 2min til it times out) [15:44] ogra_: if i use the kernel from the store, everything is fine [15:44]