[00:12] PR snapcraft#2119 opened: repo: automatically prune unneeded stage-packages [02:26] PR snapd#5123 opened: tests: skip test lp-1721518 for arch, snapd is failing to start after reboot [08:06] moin moin [08:54] why does snapcraft depend on binutils? [09:04] doko: readelf [09:05] doko: although that seems to be in tests, so maybe something else [09:05] doko: why? [09:06] it was using readelf in the past (I ripped that code out to use pyelftools instead) [09:06] maybe the deb packaging is out of date? [09:27] jamesh: when you ripped it out, did you also update stuff under debian/? :-) [09:27] jamesh: (tbh there might be something else that needs it, dunno) [09:29] Chipaca: I didn't: https://github.com/snapcore/snapcraft/pull/1913/files -- I guess I wasn't sure whether it was in use elsewhere or not [09:29] PR snapcraft#1913: elf: pyelftools to parse ELF files rather than readelf [09:30] jamesh: you know how people sometimes annotate C includes with what they were included for, to track when to remove it? [09:30] jamesh: i wish there was a similar practice for this [09:31] although the answer might be 'move it to source-deps and see if anything breaks' [09:31] at the time, it sounded like the snapped version of snapcraft was the main focus [09:41] mvo: o/! [09:41] mvo: how's things? [09:41] hey Chipaca - things are going well [09:41] mvo: cool [09:42] Chipaca: how are you? [09:42] mvo: not envious [09:42] Chipaca: hahahaha [09:42] * mvo hugs Chipaca [09:43] * Chipaca hugs mvo back [09:45] mvo: 'snap install mosaic' might bring a bit of levity to your day [09:48] Chipaca: woah [09:48] Chipaca: WOAH [09:50] Chipaca: this even works without layouts and a custom base? nice [09:50] mvo: yeah, this is a rebuild, nothing fancy [09:50] mvo: still working on the other thing [09:50] * mvo nods [09:50] (not today though) [09:50] mvo: also I somehow tricked popey into picking that one up :-D [09:51] * popey shakes fists at Chipaca [09:51] * Chipaca likes this "break stuff and then make it somebody else's problem" MO [09:51] popey: have you tested it on arm? [09:51] no, i dont have an arm machine which is connected to a display [09:52] actually, I could ssh -X [09:52] (or can I?) [09:52] expense a Chromebook? [09:52] hahahahahahaah [09:52] (if you need to touch arm often enough, that is) [09:53] popey: IIRC you'd need x11-utils (or was it xauth)? for -X to work (use -v to see the error) [09:53] https://paste.ubuntu.com/p/n7nKkGwr42/ [09:57] popey: ssh -v and look at errors before you get shell [09:57] there'll be something like 'nah nah no xauth' [09:57] maybe later :) [09:57] k [09:58] * Chipaca tries to get back to work that isn't emails === mcphail_ is now known as mcphail [10:25] cachio_: let me know when you're around [10:31] Chipaca: because binutils now triggers snapcraft autopkg tests, and these fail [10:32] Chipaca: when it's just a test dependency, then please remove it as a dependency [10:33] doko: it'd be a build dependency, right? [10:36] Chipaca: yes. and you could even annotate it as [10:37] doko: I don't know what that means, but I'll forward the information to sergiusens or ev when they're around [10:38] (I can imagine what it means, yes) [11:09] Hey! I have tried to find some information about this, but haven't had any luck. Hopefully you can help me. Is there any way to set up Ubuntu Core on a RPi2 without a monitor and keyboard (headless)? [11:11] nickman: yes, if you have serial [11:14] Chipaca: okay, there is no way to just boot up directly with the SSO credentials and internet settings in place? [11:17] nickman: AFAIK not without a custom gadget snap, but maybe ogra_ knows more [11:18] auto-import only does assertions, which those aren't [11:18] (auto-import is the feature where it'll load assertions from removable media) [11:18] well, it defaults to serial console ... so it depends how headless your definition oif headless is ;) [11:19] ogra_: but there's no way to get sso creds and netplan on there, right? [11:19] but yes, you can use a user assertion via usb device to set up a user account ... [11:19] ogra_: Headless as in, insert sd card, bootup, done. [11:20] Chthe user assertion provides the SSO creds ... i think at least [11:20] Chipaca, ^^^ [11:21] nickman: out of curiosity, what do you need this for? [11:21] and yes, i just checked and user assertions have ssh keys so you can do that [11:22] (don't know how to do it myself, though -- maybe pedronis) [11:22] still no answer for netplan though [11:22] Chipaca: I have a bunch of RPis that will be running Ubuntu Core, they all are going to use the same SSO credentials. Connecting every RPi to a screen and keyboard is a bit tedious. [11:23] SSHing to every one of them and finishing the set up in that way would also be nice and could easily be automed with the use of Terraform. [11:24] nickman: sounds reasonable. You want to go to the forum with it? it sounds like a longer/deeper conversation than can be addressed here [11:25] yu could create your own gadget with an extzra vfat partition where you include the user assertion ... but that kind of defeats all security [11:27] ogra_: security is overrated [11:27] * Chipaca hides from jamesh [11:27] er [11:27] i meant from jdstrand [11:27] haha [11:27] * Chipaca hides from all the jameses [11:27] ogra_: also, https://www.heise.de/ct/artikel/Super-GAU-fuer-Intel-Weitere-Spectre-Luecken-im-Anflug-4039134.html [11:28] pfft intel ... [11:28] onbolete architecture [11:28] *obsolete too [11:28] * Chipaca covers his processor's ears [11:29] Chipaca: I suppose I could post something on the forum. Can't seem to find any Ubuntu Core specific sub forum though? [11:29] nickman, the "device" topic [11:30] nickman: 'device' [11:30] heh [11:32] I suppose Ask Ubuntu would suffice? [11:33] forum.snapcraft.io [11:33] (see channel topic btw :) ) [11:35] Hah, my bad. Sorry! [11:40] Issue snapcraft#2093 closed: manifest.yaml does not indicate the release the snap was built on [11:41] cjwatson: do you know when we will get the ability to tell build.snapcraft.io to *only* trigger builds for specific architectures? (e.g. a snapcraft.yaml that ingests an amd64 deb only, won't build on armhf)? [11:42] popey: Can't say, because I'm waiting for the snapcraft team to provide the necessary support as discussed in New York [11:43] Ok, thanks. kyrofa ^ When will snapcraft ( :) ) grow the abililty to say "only build this for $ARCH"? [11:43] PR snapcraft#2120 opened: many: dedup environment entries [11:47] Chipaca, uhm ... are we aware that a "snap switch core --$targetchannel" does not actually switch core at all on ubuntu-core devices ? [11:47] ogra_: whaddya mean? [11:47] (it does not touch the bootloader, so the old core is booted, but in state.json the channel info is updated) [11:47] ah [11:47] oh [11:47] oooh [11:48] just a little bit [11:48] ogra_: can you file a bug? [11:48] ogra_: I don't want to risk forgetting, and have too much state right now [11:52] ogra_: and by 'state' i mean 'lunch' [11:52] * Chipaca -> lunch [11:53] Chipaca, https://bugs.launchpad.net/snapd/+bug/1768822 [11:53] Bug #1768822: snap switch core on ubuntu-core does not update the bootloader, but state.json === stgraber_ is now known as stgraber [11:57] kyrofa: re popey's question, I believe the promise was also that snapcraft's parser would be split out in a way that we could consume from py2 code [12:04] ogra_: I always thought "switch" was supposed to be followed by a "refresh" - that was the design [12:05] when you "switch" it's instant, it doesn't actually do the download/install of the snap [12:05] ..until the next refresh [12:08] hmm, i thought it is only instant if the snap is installed and otherwise installs it [12:09] I *think* it's working as designed. [12:09] i'll try it on the next test run [12:10] no mention of switch in https://docs.snapcraft.io/core/usage [12:11] looks like someone didnt update the docs :) [12:17] ogra_: popey: having had a bit of lunch, [12:18] ogra_: popey: snap switch a-snap && snap refresh === snap refresh a-snap [12:18] that is, switch just changes what the snap is tracking [12:19] even the --help output could use some love [12:20] patches welcome :-D [12:20] popey: ^ hint hint nudge nudge [12:20] * Son_Goku waves [12:21] Son_Goku: o/ [12:22] zyga, so where's Zygoonix? :D [12:24] cjwatson, why do you need snapcraft's parser to be py2 compatible? [12:25] Son_Goku: Because I need to use it in Launchpad [12:25] eh? [12:25] It needs to know which architectures to dispatch to [12:25] you can't just read the yaml and figure that out? [12:25] The parsing rules for architectures are non-trivial [12:25] We *might* be able to duplicate it, but I'd rather avoid that if possible [12:26] Sergio seemed OK with the idea of splitting out the parser. If that's changed, we can of course revisit duplicating code [12:26] It's not a completely hard requirement, but I don't want to drop it on the floor just because people forgot about it either [12:26] another way to do it would be to write a small Python 3 program that would output JSON that you'd capture from LP [12:26] as a stop-gap until LP itself can run that aspect in Python 3 natively [12:26] Possible, but the build manager is a tight loop and we'd rather avoid the fork/exec overhead [12:27] We already have problems with the one other place that we do fork/exec there [12:27] the build manager is difficult to port to Python 3? [12:27] independent of the rest of LP? [12:27] Yes [12:28] It doesn't have particularly py3-difficult bits itself, but it's not very separable [12:28] Afk on a bike [12:30] sergiusens: ah, good timing. Is it still your plan to split out the snapcraft parser in a form that we could consume from LP (py2), or should we expect to need to duplicate the architectures parsing/interpretation code in the LP build manager? [12:30] brrr py2 :P [12:31] believe me I'd rather we were on py3 [12:31] and I'm aware we only have a couple of years [12:32] cjwatson: how split out does it need to be for you to be able to use it? [12:32] Chipaca: in the previous discussion, my memory is that sergiusens said "separate PyPI package" [12:33] of course this is worth rechecking from time to time [12:33] cjwatson, is there a py3 port of LP stuff in progress, out of curiosity? [12:33] Son_Goku: it's been ongoing for some time, but it's a huge job [12:34] Son_Goku: >700K lines of code and >200 dependencies [12:34] ooh [12:35] that's... a lot of code [12:35] that's a similar scale to what's going on in Fedora [12:35] though now we're _nearly_ done [12:35] we just have two major applications left to port [12:36] the Koji Build System and the Pagure VCS [12:36] and I can't just down tools and work on nothing else for three months [12:37] cjwatson, well, you could :P [12:37] you'd just have to go on a sabbatical :P [12:37] dunno if your bossman would let you do that, though :) [12:37] I kind of like the whole getting paid thing [12:37] cjwatson: we can certainly consider splitting it out, but we are a very small team; I'll discuss with sparkiegeek whose sitting real close to me right now [12:38] sergiusens: we're an even smaller team [12:38] we might consider just going into launchpad code and adding the code there [12:38] cjwatson: we are 2 people ;-) kyrofa and me [12:38] sergiusens: I didn't expect this to be a new requirement, though - we've discussed this before. I just wanted to check whether it was still a current plan [12:38] sergiusens: LP is mostly just me at the moment [12:39] cjwatson: right, so I proposed that we just do the work (kyrofa or myself) on launchpad itself [12:39] cjwatson, well, it'd be a paid sabbatical :D [12:39] (not entirely, William does a lot of infra, but in terms of application code I'm producing most of the changes right now) [12:39] someone must see the value in having LP last beyond 2019, right? [12:39] sergiusens: cjwatson: I don't know this variation of the three yorkshiremen sketch, but I'm not liking it [12:40] sergiusens: I'm good with that too of course, but I thought snapcraft was going to have to have the corresponding code too [12:41] cjwatson: the grammar we have is much more complex than what you need to do the detection and taking that back to python2 might be a huge pain [12:41] sergiusens: OK, so if there's been a change of plan then that's fine, I just need to know [12:42] Hi, apologies for the ignorant question, I'm trying to choose a platform for an IoT Hub: I'm looking at Ubuntu Core and Yocto (and ResinOS also looks great). What would you say are the advantages/differences of Ubuntu Core over Yocto? [12:42] sergiusens: is the which-architectures-should-this-snap-be-built-on logic (as discussed in New York) in snapcraft as yet, or still in progress? [12:43] Son_Goku: Ubuntu has committed to supporting 2.7 out to 2023 by virtue of shipping it in 18.04 main; obviously it gets harder the longer we go [12:43] (AIUI) [12:43] cjwatson: it lives in snapcraft already and is documented https://forum.snapcraft.io/t/architectures/4972 [12:43] sergiusens: aha, nobody told me :) [12:44] cjwatson, sure, and it's supported in RHEL 7 until 2024 [12:44] cjwatson: hmm, I thought kyrofa discussed with you a couple weeks ago, I'll figure out where the communication broke down [12:44] and SLE 12 until 2027 [12:45] cjwatson, but for the normies, py2 is dead on Jan 1, 2020 [12:45] hackeron: do you think you could ask that question on the forum? https://forum.snapcraft.io/c/device [12:45] hackeron: answers are probably going to be interesting to other people as well [12:47] Chipaca: sure, I'm also on #yocto and so far my understanding is Yocto is more low level, allowing you to build exactly what you want and ubuntu-core is more of a higher level package, trying to tie you into their cloud services and container type but eeasier to get started [12:51] argh sergiusens I was still typing something to you [12:51] email it is I guess [13:15] slangasek, i've opened and closed stable/ubuntu-18.10 branches for all of the seeded snaps [13:15] seb128, ^^ [13:16] kenvandine, great, thx [13:17] kenvandine: does that include the gnome-3-26-1604 snap? [13:17] slangasek, yes [13:17] kenvandine: excellent, thanks. I'll kick off another image test build [13:18] slangasek, let me know if you need anything [13:22] sergiusens: taken to email, since you're bouncy here :) [13:22] cjwatson: yeah, I am client mode and at the product sprint; email seems to be the best path forward :-) [13:24] Chipaca: you cannot hide! === Chipaca is now known as TotallyNotChipac [13:27] * TotallyNotChipac whistles innocently === TotallyNotChipac is now known as Chipaca [13:32] hehe :) [13:34] Hey guys :-) [13:35] We have fantastic summer this spring [13:35] zyga: shut up shut up shut up shut up [13:35] :-) [13:35] zyga, Chipaca when you have 1 minute #5123 [13:35] PR #5123: tests: skip test lp-1721518 for arch, snapd is failing to start after reboot [13:35] cachio_: I've been looking at it [13:36] Chipaca, tx [13:36] cachio_: is what you're seeing that «cannot reconnect may031403-609338 (google:arch-linux-64) after reboot: dial tcp 35.231.24.141:22: connect: connection refused» ? [13:36] * zyga hugs chipaca wearing his sweaty biking shirt ;-) [13:36] * Chipaca isn't wearing a sweaty biking shirt [13:36] It is very warm even in the forest [13:37] Chipaca, it can reconnect [13:37] cachio_: ok, i'll run it a few more times [13:37] after reboot it reconnects and tries to run the command to validate interfaces [13:37] cachio_: i've been trying to reproduce the error you were seeing and every time getting a different, unrelated error [13:37] and it hungs doing that [13:37] :-( [13:37] cachio_: right [13:38] Chipaca, snapd is not starting correctly [13:38] after the reboot [13:38] cachio_: yes, that's what I understood from the PR [13:38] cachio_: I'm trying to get in to it to figure out why [13:39] cachio_: I'd rather not disable the test if it's going to hide an issue [13:39] cachio_: but if I can't figure it out before eod i'll +1 so we're not blocked on this [13:39] * Chipaca extends his eod a bit [13:40] Chipaca, well the idea is not to hide an issue, the idea is stop making the builds fail until we discover why it is happening [13:40] cachio_: yes [13:40] cachio_: hiding the issue is a side-effect of that though :-) [13:41] Chipaca, I mean, we already know there is an issue there, and as it is causing machines don't die and keeping consumig resources [13:41] * Chipaca nods [13:41] Chipaca, I'll continue working on this today [13:42] cachio_: I'm hoping I can get in with -debug [13:42] Chipaca, if you use -vv you will see the details [13:42] cachio_: yep [13:43] cachio_: but so far it's failed twice with some TLS nonsense, and once with the above 'cannot reconnect' thing [13:43] ¯\_(ツ)_/¯ [13:43] Chipaca: done :) < https://forum.snapcraft.io/t/ubuntu-core-vs-yocto-and-resinos/5266 [13:44] hackeron: thanks! looking forward to the replies :-D [14:24] Chipaca, https://paste.ubuntu.com/p/cXdsZV8Rg3/ [14:24] it remains in activating [14:24] and I see "Dependency failed for Snappy daemon." [14:25] I just retriggered the test becuse the machine was killed [14:44] cachio_: do you still have that shell? [14:48] Chipaca, no, I rexecuted and I got this https://paste.ubuntu.com/p/CQvw6mSRh5/ [14:49] Chipaca, I triggered another run [14:49] I'll hopefully have a similar shell in few minutes [14:50] Chipaca, it is like there are different problems when we reboot arch [14:50] niiice [14:50] for very small values of nice [15:12] PR snapcraft#2114 closed: meta: stop creating empty snap directory in prime [15:19] sergiusens, cjwatson communication breakdown was my fault, we were sort of talking here https://github.com/snapcore/snapcraft/issues/1685 but then in the 18.04 ramp I never managed to circle back [15:20] cjwatson, things have greatly simplified, there's no special grammar anymore like there was in the previous proposal [15:21] kyrofa: all right, hopefully the duplicated code won't be too bad then [15:22] kyrofa: and you're right, sorry, I'd forgotten about the discussion in that issue [15:22] cjwatson, no apology necessary, I'm sorry for not getting back to you [15:23] cjwatson, there should actually be very little overlap. If you take a look at the proposal sergiusens linked, you'll see that snapcraft is really only concerned with a specific host, where build.snapcraft.io has the big picture [15:24] kyrofa: we solved all problems already, no need to go into them again ;-) [15:24] Ha! [15:24] kyrofa: (see email, too) [15:24] strictly speaking BSI doesn't really have the big picture, LP does :) [15:24] Ah, should have looked there first [15:25] BSI is probably just going to say snap.requestBuilds() or similar and let LP figure it out [15:30] sergiusens, read the email, I'll take that task unless it's one you want [15:30] cjwatson, python2, right? [15:32] kyrofa: Yep - ideally the sort of bilingual code that doesn't impede porting [15:32] Yep, easy [15:32] kyrofa: Don't worry too much though, I'll massage it into shape, it's more the logic I want [15:32] Cool [16:26] zyga: was switching to quassel, let me know if you need me to do anything re: factory submission [16:27] I’m off now. We need to file bugs to unblock badness on our package [16:28] Join opensuse-admin perhaps, I was talking there a few days ago [16:48] Caelum: there's quite a few things that the snapd package currently does that's completely against Factory policy [16:49] Caelum: the number one thing is that you can't have an rpmlintrc file for factory submissions [16:49] which means you have to make rpmlint actually pass your package [17:22] Pharaoh_Atem: I see, and for things that can't be fixed, we file bugs, what do we file bugs against? [17:23] you don't get to file bugs [17:23] ok but, like, there's an apparmor file for instance, it has to be there [17:23] well, the stuff with permissions and whatnot requires a bug request to security team [17:23] ok [17:24] well first take care of the rpmlint errors [17:24] for example, FHS compliance and things like that [17:24] FHS compliance might not be possible [17:24] but we'll look [17:25] actually, it is [17:25] we did this for the Fedora package [17:25] https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec [17:29] PR snapd#5123 closed: tests: skip test lp-1721518 for arch, snapd is failing to start after reboot [17:57] diddledan: https://transfer.sh/gceSf/snapcraft-pr2120.snap [17:57] Should fix the Gimp 2.10 issues [18:40] Pharaoh_Atem: at a cost, you know that :) [18:40] Pharaoh_Atem: it's all a matter of people acking that [18:40] * zyga is happily tired after biking with family lately [19:28] Wimpress: seems not [19:28] I used `snapcraft-pr 2120 cleanbuild` [19:28] PR #2120: Fix installed-size not being set in GET v2/snaps [19:29] diddledan: don't use snapcraft-pr, I did and it seems a bit broken [19:29] https://www.irccloud.com/pastebin/qScXIxcH/ [19:29] oh [19:29] I think it still uses the deb [19:30] so you're not actually using the new version [19:31] might be "easier" to grab the pull request, and make a snap from it, install that in devmode and use that to build cleanbuild style [19:31] ok, I've pulled the snap that Wimpress built now [19:31] or that [19:48] diddledan: snapcraft-pr is still running from source. When snapcraft is running from source and requested to cleanbuild, it doesn't copy that source over to the container, it installed the deb instead [19:48] diddledan: so it's only really useful if you're building locally (on the host or in a container) [19:54] If you're testing out PRs, I suggesting running it either without cleanbuild, or building a snap and cleanbuilding with that, which will copy that snap into the container [20:07] Quick question from a noob, this SSO account I register, if I deploy Ubuntu Core on 2,000 devices, is there any pricing or limits? - Is there an overview of what is sent to the cloud servers and is there a way to disable them if needed? [22:27] PR snapcraft#2121 opened: cli: add provides command [23:02] I installed latest Ubuntu Core but the "snappy" and "ubuntu-core-upgrade" commands are both missing. How would one update the OS/kernel? -- Also, I checked cfdisk /dev/sda and there's just 1 single root filesyste, how would one rollback a failed kernel without having 2 root partitions? [23:20] hackeron: hi [23:21] hackeron: what are you reading, that it talks about "snappy" and "ubuntu-core-upgrade"? [23:21] hackeron: in ubuntu core everything is a snap, the root filesystem, the kernels, and everything [23:52] Caelum: all over the place, e.g. https://www.unixmen.com/getting-started-with-snappy-ubuntu-core/ -- I guess things have changed since then :) -- so how would you upgrade from 16 to the new 18 that was out? - or is that just ubuntu, not yet on core? [23:59] Caelum: and it doesn't seem very resiliant to filesystem corruption, I would've thought it would use something like this? < https://mender.io/user/pages/02.product/02.How-it-works/arch-1HTTPS.png -- any reason it doesn't?