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