| mborzecki | morning | 05:02 |
|---|---|---|
| mborzecki-suse | hmm found an interesting error: `error: store.RevisionNotAvailable with 2 snaps` | 05:16 |
| mborzecki-suse | well, nvidia seems to work just fine | 05:21 |
| mborzecki-suse | apparmor denials are not logged in dmesg, so it's easy to miss those | 05:37 |
| mborzecki-suse | type=AVC msg=audit(1529645643.115:406): apparmor="DENIED" operation="open" profile="snap.ohmygiraffe.ohmygiraffe" name="/etc/pulse/client.conf.d/" pid=10207 comm="love" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 | 05:37 |
| zyga | hey | 05:50 |
| zyga | mborzecki-suse: hey | 05:51 |
| mborzecki-suse | zyga: hey | 05:51 |
| zyga | I was up till 2AM iterating on the packaging | 05:52 |
| mborzecki-suse | zyga: so far so good, no issues with package from your repo | 05:52 |
| zyga | found a few annoying bugs and fixed them | 05:52 |
| zyga | and learned a few things that we need to change in our build system | 05:52 |
| zyga | (not having a central build system sucks) | 05:52 |
| mborzecki-suse | but man, textual yast installer is awful, didn't manage to install it the way i'd like, gave up and went with the defaults at some point, ended up with gpt partitioned disk, no efi, no luks, no lvm, btrfs on rootfs, xfs on home and non-blacklisted nouveau (what made xorg unusable) | 05:56 |
| snaphelp | hey | 05:57 |
| snaphelp | so how do I go about backing up a snap's data | 05:57 |
| snaphelp | Like nextcloud. | 05:57 |
| zyga | snaphelp: fantastic question | 05:58 |
| zyga | you can do it manually today | 05:58 |
| zyga | but we are also working on a feature that makes it easy | 05:58 |
| snaphelp | zyga: Snaps aren't auto updating are they? | 05:58 |
| mborzecki-suse | don't know why people even bother building such installers, what i really need is creating partitions myself, mounting them in the layout i want, bootstrapping the system, update fstab, crypttab, rebuild initramfs, install some bs pacakges, install bootloader (the way i want) | 05:58 |
| zyga | all snap data is held in /var/snap/$SNAP_NAME and $HOME/snap/$SNAP_NAME | 05:58 |
| zyga | mborzecki-suse: hmm? | 05:59 |
| zyga | snaphelp: the upcoming feature will allow you to snapshot this state easily from the snap CLI | 05:59 |
| snaphelp | zyga: is the snap directory in my home directory just a symlink to /var/snap? | 05:59 |
| zyga | snaphelp: no | 05:59 |
| zyga | snaphelp: those are separate data sets, one is per user and the other is global for the system | 05:59 |
| snaphelp | hmm | 06:00 |
| mborzecki-suse | zyga: just being grumpy about distro installers :| | 06:00 |
| zyga | hey mvo | 06:02 |
| mborzecki-suse | mvo: morning | 06:02 |
| mvo | hey zyga and mborzecki | 06:02 |
| snaphelp | zyga: so the global data is in /var | 06:04 |
| snaphelp | and there's no auto updating correct? | 06:04 |
| zyga | snaphelp: per-snap global data is in /var/snap/$SNAP_NAME | 06:05 |
| zyga | snaphelp: I don't understand the question about auto-updating | 06:05 |
| snaphelp | Do snaps automagically update themselves | 06:05 |
| snaphelp | or is it snap update <snap> | 06:05 |
| zyga | snaphelp: it is snap refresh but you don't have to do it explicitly, snapd automatically refreshes everything periodically | 06:06 |
| snaphelp | Can I disable automatic refreshes? | 06:07 |
| zyga | you can set a schedule but you cannot turn it off | 06:07 |
| zyga | mvo: I'm a bit tired, I spent half of the night on this packaging | 06:10 |
| zyga | mvo: I will be sending patches when I'm consistently awake | 06:11 |
| snaphelp | zyga: any plans to allow disabling? | 06:11 |
| zyga | snaphelp: no, there are no such plans | 06:11 |
| snaphelp | hm | 06:11 |
| snaphelp | zyga: I'm torture testing a snap | 06:13 |
| snaphelp | heh wow it's handling being beat with 40gb of data | 06:14 |
| zyga | mvo: we need to have a makefile in data/ | 06:18 |
| zyga | and stop installing files by hand in packaging | 06:18 |
| zyga | it's easy to miss files | 06:18 |
| zyga | and it's silly to do this | 06:18 |
| mborzecki | need to go to kids school for a while, bbl | 06:21 |
| mup | PR snapd#5352 closed: many: expose full publisher info over the snapd API <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5352> | 06:22 |
| mvo | zyga: ok | 06:23 |
| mup | PR snapd#5375 opened: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Created by mvo5> <https://github.com/snapcore/snapd/pull/5375> | 06:53 |
| zyga | oh, interesting | 06:53 |
| mup | PR core18#34 opened: hooks: make /usr/bin/snapctl available in the base <Created by mvo5> <https://github.com/snapcore/core18/pull/34> | 06:57 |
| mvo | zyga: one more commit to 5375 (apparmor default update) | 06:57 |
| mup | PR core18#34 closed: hooks: make /usr/bin/snapctl available in the base <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/34> | 07:07 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:13 |
| * zyga is super sleepy | 07:17 | |
| zyga | sorry folks, this day will be hit-and-miss | 07:18 |
| mvo | hey pstolowski, good morning | 07:18 |
| mup | PR snapd#5376 opened: tests: skip security-udev-input-subsystem without /dev/input/by-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/5376> | 07:28 |
| mvo | zyga: just get some rest :) it will be better i'm sure | 07:30 |
| mup | PR snapd#5373 closed: release: 2.33.1 <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5373> | 07:35 |
| zyga | mvo: thank you | 07:36 |
| zyga | I'm chopping final bits of packaging updates | 07:36 |
| zyga | thank you for 2.33.1 | 07:36 |
| pstolowski | re https://forum.snapcraft.io/t/gnome-calculator-failed-to-create-symbolic-link/5742/10 , the after-install seeding doesn't look good in cosmic, gets stuck on autoconnect and in the meantime an update of snapd arrives through deb and gets stuck on deb configure step | 07:43 |
| mup | PR snapd#5377 opened: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <https://github.com/snapcore/snapd/pull/5377> | 07:43 |
| zyga | mborzecki: ^ | 07:44 |
| zyga | mborzecki: which distributions did you test? | 07:44 |
| zyga | popey: do you have a suse box for some testing? | 07:44 |
| zyga | popey: I'd like to update snapd in openSUSE | 07:45 |
| zyga | mborzecki: I also have one issue I don't know how to solve | 07:45 |
| zyga | mborzecki: the new snapd.apparmor.service needs to be enabled manually | 07:45 |
| zyga | mborzecki: I don't know what to do about it | 07:45 |
| zyga | mborzecki: could you please have a look at https://build.opensuse.org/request/show/618441 | 08:01 |
| zyga | Pharaoh_Atem: ^ if you have the time | 08:02 |
| zyga | Pharaoh_Atem: this syncs the package in system:snappy with the package in snapd master | 08:02 |
| zyga | remaning diff is: patches, small change in path used to get packaging overrides (we don't have a symlink for packaging/opensuse in 2.33 _yet_). | 08:03 |
| zyga | in 2.34 the delta should be empty | 08:03 |
| === chihchun_afk is now known as chihchun | ||
| * zyga -> walk | 08:33 | |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | mvo, pedronis it appears that seeding+prerequisites explode in cosmic on autoconnect, also with 2.33.1 (i've built the deb manually) | 08:45 |
| pedronis | pstolowski: explode in which sense? | 08:46 |
| pedronis | we have no support atm if the seeding is not sorted right | 08:46 |
| pstolowski | pedronis: autoconnect is in state Doing, never completes | 08:46 |
| pedronis | pstolowski: is this a spread test or something else? | 08:47 |
| pstolowski | pedronis: there are 6 gnome packages + core in seed/ | 08:47 |
| pstolowski | pedronis: no, a fresh install of cosmic daily | 08:47 |
| pedronis | if they are sorted wrong | 08:47 |
| pedronis | no good | 08:48 |
| pedronis | given that seeding is serial | 08:48 |
| pedronis | we should teach seeding to do some sorting | 08:49 |
| pedronis | but that hasn't really changed much | 08:49 |
| === chihchun_afk is now known as chihchun | ||
| pedronis | pstolowski: I'm not even sure what autoconnect code is exactly in 2.33.1 | 08:50 |
| pedronis | I suppose is not like master | 08:50 |
| pstolowski | pedronis: correction, i actually build and tested with current master | 08:51 |
| pedronis | pstolowski: can you print seed.yaml there | 08:51 |
| pedronis | pstolowski: we might have made something worse | 08:51 |
| pedronis | but it was probably working by chance | 08:51 |
| pedronis | or I'm missing something, which could be | 08:53 |
| pstolowski | pedronis: http://pastebin.ubuntu.com/p/pPZkdHhp9B/ | 08:53 |
| pedronis | themes is wrong | 08:54 |
| pedronis | there was even a bug | 08:54 |
| pedronis | we told them to move | 08:54 |
| pedronis | not sure why is still like that | 08:54 |
| pstolowski | pedronis: i don't think we made it worse, i started with fresh cosmic image (it has 2.28.x), the problem was already visible | 08:54 |
| pstolowski | pedronis: oh ah | 08:54 |
| popey | zyga: i have a suse vm, but not sure how much time i will have today to help test | 08:55 |
| Chipaca | morning all | 08:55 |
| * Chipaca having a weird day (but a good'un) | 08:55 | |
| pedronis | pstolowski: is still open, though there was a fix: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1772844 | 08:58 |
| pedronis | bit confused | 08:58 |
| mup | Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844> | 08:58 |
| pstolowski | pedronis: right, clearly not landed | 09:01 |
| pedronis | pstolowski: we can teach either seeding or autoconnect to do something in that case, I want to have a clearer big picture related to conflicts before going there | 09:02 |
| pedronis | though | 09:02 |
| pedronis | the manual fix seems easy enough, not sure why is not landed | 09:03 |
| pedronis | or is just different teams building different images | 09:03 |
| pedronis | mvo: do you understand what is happening with that bug ? #1772844 | 09:07 |
| mup | Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844> | 09:07 |
| mborzecki | re | 09:09 |
| mborzecki | took longer than i expected | 09:09 |
| searedvandal | Hi. I just installed snapd on Antergos from the AUR, and I set it up following the instructions for Arch. Installed the hello snap, and tried to run it. I get this error "cannot locate the core or legacy core snap (current symlink missing?): No such file or directory". snapd version 2.33, kernel 4.17.2-1-ARCH. Any ideas to what may be the issue? | 09:57 |
| Chipaca | searedvandal: does Antergos use systemd? | 09:58 |
| searedvandal | Chipaca, yes | 09:58 |
| Chipaca | phew | 09:59 |
| Chipaca | searedvandal: 'snap list' lists nothing? | 09:59 |
| Chipaca | searedvandal: can you pastebin the output of 'snap tasks --last=install' | 09:59 |
| mborzecki | searedvandal: and pacman -Qi snapd | 10:00 |
| searedvandal | Chipaca, https://ptpb.pw/_0LP | 10:00 |
| searedvandal | mborzecki, https://ptpb.pw/iJb7 | 10:00 |
| Chipaca | hmmmm | 10:01 |
| searedvandal | Chipaca, and snap list shows core and hello | 10:01 |
| Chipaca | searedvandal: yep. I'm guessing something is expecting /snap instead of /var/lib/snapd/snap or viceversa | 10:02 |
| mborzecki | mvo: there's somethign wrong with the 2.33.1 release on github | 10:02 |
| Chipaca | searedvandal: what's in /etc/os-release? | 10:02 |
| mborzecki | mvo: it doesn't have a tag (?) | 10:02 |
| searedvandal | Chipaca, my /etc/os-release https://ptpb.pw/xFrR | 10:03 |
| mborzecki | ID_LIKE=archlinux chceks out | 10:03 |
| searedvandal | mborzecki, the AUR has the 2.33 build, not the 2.33.1 | 10:03 |
| mborzecki | searedvandal: yeah, i'm updating to 2.33.1 now ;) | 10:03 |
| niemeyer | Mornings | 10:03 |
| searedvandal | mborzecki, ah :) | 10:04 |
| searedvandal | when I do 'snap version' the antergos line has this - , is that correct? https://ptpb.pw/rOFw | 10:04 |
| Chipaca | searedvandal: probably | 10:05 |
| searedvandal | alright | 10:05 |
| Chipaca | searedvandal: because it's a rollin' release | 10:05 |
| Chipaca | so no 'version' | 10:05 |
| searedvandal | ah, yeah | 10:05 |
| searedvandal | Chipaca, and I have the /snap directory and the /var/lib/snapd/snap directory | 10:07 |
| mborzecki | searedvandal: yes, it's the same on arch | 10:07 |
| mborzecki | searedvandal: /snap is just a symlink in your system right? | 10:07 |
| Chipaca | searedvandal: can you pastebin find /{var/lib/snapd/,}snap/ -maxdepth 2 -ls | 10:08 |
| searedvandal | mborzecki, Chipaca here is the paste https://ptpb.pw/Qp_i | 10:09 |
| mborzecki | searedvandal: ls -l / | 10:10 |
| Chipaca | mborzecki: that looks like /snap is not a symlink but the real thing | 10:10 |
| Chipaca | mborzecki: and /var/lib/snapd/snap has nothing | 10:10 |
| searedvandal | mborzecki, https://ptpb.pw/Pj_e | 10:10 |
| searedvandal | oh, you're right | 10:10 |
| Chipaca | that is very strange | 10:11 |
| Chipaca | something's askew (gesundheit) | 10:11 |
| mborzecki | searedvandal: yeah, the package ships with /var/lib/snapd/... only | 10:11 |
| searedvandal | strange. I have not created any directories or changed anything | 10:11 |
| mborzecki | it used to ship /snap -> /var/lib/snapd/snap symlink a while ago but we got rid of that | 10:11 |
| mborzecki | searedvandal: can you pacman -Qo /snap ? | 10:12 |
| Chipaca | mborzecki: I suspect distro detection being confuse | 10:12 |
| searedvandal | mborzecki, no package owns /snap | 10:12 |
| Chipaca | in hindsight, we should print a summary of directory info on startup, at least in debug | 10:14 |
| mborzecki | searedvandal: ok, if there's any snap mounted, unmount it and remove the package, remove /snap and install the package again | 10:14 |
| mborzecki | Chipaca: +1 | 10:14 |
| mborzecki | snap debug distro :) | 10:15 |
| Chipaca | and now i need to stop myself from doing that and getting back to figuring out why warnings has my snapd all panicky | 10:16 |
| mvo | mborzecki: let me check, it should have a tag | 10:19 |
| searedvandal | alright, you're right, it gets confused on os-detection. I removed a pacman hook that sets the antergos info and updated the filesystem package to revert to identifying as regular arch. now everything seems to work just fine | 10:19 |
| searedvandal | snap run hello gives me a nice hello world output | 10:20 |
| mborzecki | mvo: https://github.com/snapcore/snapd/releases/tag/untagged-ec50ee5bfb45daefc236 <-- untagged-... | 10:20 |
| mborzecki | searedvandal: yay | 10:22 |
| mvo | mborzecki: better now? sorry, no idea what happened there, github glitch | 10:22 |
| searedvandal | so snap doesn't like it when the system is identified as antergos, but when it's identified as arch it's all good :) | 10:23 |
| mborzecki | hm otoh we do release.DistroLike(..., "arch", ..) this should probably be "archlinux" to catch the derivatives | 10:23 |
| searedvandal | ah, probably :) | 10:23 |
| Son_Goku | mvo, zyga, I just realized that next week will be the two year anniversary of me working on snappy on Fedora | 10:23 |
| mborzecki | mvo: yay! | 10:23 |
| zyga | :) | 10:23 |
| zyga | Time flies! | 10:23 |
| mborzecki | Son_Goku: we should get you some cake | 10:24 |
| Son_Goku | two years ago next week, I agreed on a lark to go to the first snappy sprint | 10:24 |
| ogra_ | \o/ | 10:24 |
| Son_Goku | I had received the email while (ironically) being at the Red Hat Summit | 10:24 |
| mvo | Son_Goku: woah, congrats \o/ | 10:24 |
| ogra_ | great to still have you here !! | 10:24 |
| * mvo hugs Son_Goku | 10:24 | |
| Son_Goku | and Josh Bressers and Thomas Cameron both told me I should go ahead and do it | 10:25 |
| Son_Goku | so I did | 10:25 |
| Son_Goku | (Josh: https://twitter.com/joshbressers; Thomas: https://twitter.com/thomasdcameron) | 10:25 |
| Son_Goku | at the time, I was really unsure if I was the right person to go to this | 10:26 |
| Son_Goku | of course, technically, I started two years ago next month, but... | 10:27 |
| mborzecki | searedvandal: could revert back to identifying as antegros and rebuild the package with this little fix https://ptpb.pw/Oo6u ? | 10:27 |
| Son_Goku | because the Heidelberg sprint was July 22, 2016 | 10:27 |
| niemeyer | Interesting.. we're importing from the snap package inside client | 10:33 |
| niemeyer | This is something we should avoid as otherwise importing the client will depend on importing snapd entirely | 10:34 |
| niemeyer | Son_Goku: That reminds me that we need a dev sprint soon | 10:34 |
| Son_Goku | niemeyer, I was wondering if we were going to go without one this year :) | 10:35 |
| mup | PR snapd#5378 opened: dirs: improve identification of Arch Linux like systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5378> | 10:36 |
| niemeyer | Son_Goku: We just need to think about what would be the best time and place.. we have non-dev sprints in July and September.. So either August or later in the year | 10:38 |
| Son_Goku | so I'm going to be at DevConf.us Aug 17-19, so please don't schedule it then | 10:39 |
| mborzecki | searedvandal: just opened a PR with this change, if it works in our test suite I'll include it as a patch in 2.33.1 package, so your next rebuild should work fine | 10:39 |
| Son_Goku | niemeyer, Flock is actually going on in Dresden, Germany on Aug 8-11: https://flocktofedora.org/ | 10:40 |
| Son_Goku | if zyga wants to talk about snaps at Flock, now would be a good time ;) | 10:40 |
| niemeyer | Son_Goku: Ah, interesting | 10:41 |
| zyga | Very likely | 10:41 |
| niemeyer | Son_Goku: Are you going? | 10:41 |
| Son_Goku | I can't afford to, so sadly no | 10:41 |
| Chipaca | niemeyer: we've been depending on snap from client for a long long time | 10:42 |
| Son_Goku | zyga: almost anything goes for CfP: https://flocktofedora.org/#cfp | 10:42 |
| Chipaca | niemeyer: snap is where Revision and Epoch live | 10:42 |
| niemeyer | Chipaca: Yeah.. my memory is weak by now, but IIRC the agreement we got about this kind of thing was to revert the dependency, having such types in client itself | 10:43 |
| niemeyer | Chipaca: So that importing the client becomes isolated | 10:43 |
| niemeyer | Chipaca: The snapd/snap package by now spreads its legs through quite a few bits | 10:44 |
| niemeyer | As in, importing deps | 10:44 |
| Son_Goku | niemeyer, but it'd be cool if Snapcraft was listed as a sponsor for Flock :P | 10:44 |
| niemeyer | Which is not a problem for it, to be clear.. it's just that the transitive dependency from client becomes weird | 10:44 |
| Chipaca | niemeyer: I thought it just used dirs and the different *util | 10:45 |
| niemeyer | Son_Goku: We can check that.. I haven't been involved in sponsorings for a while, so I'm not sure about what the current rules are | 10:45 |
| Chipaca | Son_Goku: this Flock is distinct from the flock that is a startup and an app? | 10:48 |
| Son_Goku | yes... | 10:48 |
| Son_Goku | Flock is the name for the Fedora contributor conference | 10:48 |
| Son_Goku | which used to be called FUDCon | 10:48 |
| Chipaca | I can see how a contention mechanism is a better name than FUDCon | 10:48 |
| Chipaca | but it's not a wide margin :) | 10:49 |
| mup | PR snapd#5378 closed: dirs: improve identification of Arch Linux like systems <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5378> | 11:09 |
| mborzecki | mvo: i think the tag can be removed: | 11:11 |
| mborzecki | * [new tag] untagged-ec50ee5bfb45daefc236 -> untagged-ec50ee5bfb45daefc236 | 11:11 |
| mborzecki | suprising github actually allowed creating this | 11:12 |
| zyga | re | 11:13 |
| * zyga picked up the coffee he made at 7 | 11:13 | |
| zyga | mborzecki, Pharaoh_Atem: can you please eyeball https://github.com/snapcore/snapd/pull/5377 | 11:13 |
| zyga | it's the last of the bunch | 11:13 |
| mup | PR #5377: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <https://github.com/snapcore/snapd/pull/5377> | 11:13 |
| zyga | mvo: hey | 11:21 |
| zyga | did you have a chance to look at https://github.com/snapcore/snapd/pull/5369 | 11:21 |
| mup | PR #5369: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5369> | 11:21 |
| mvo | hey zyga | 11:21 |
| mvo | zyga: looking at it currently | 11:22 |
| zyga | :-D ok, let me know once you've read it | 11:22 |
| zyga | I'll write something on the forum now | 11:22 |
| searedvandal | oh my how smooth TrackMania runs, I'm impressed | 11:22 |
| mvo | zyga: ok | 11:23 |
| mborzecki | snap downloads capped at 100kBps again? | 11:27 |
| zyga | mborzecki: hmm, not for me | 11:27 |
| zyga | 7MB/s | 11:28 |
| mborzecki | hmm 2 times hit 100kBps, another restart and 1.2MB now | 11:28 |
| zyga | over my LTE link | 11:28 |
| zyga | I looked at stats and I still cannot stop being impressed by how I can effortlessly live on LTE with 100s of GB of data used monthly | 11:29 |
| zyga | for the price of a meal in spain | 11:29 |
| zyga | (one meal, for one person) | 11:29 |
| === pstolowski is now known as pstolowski|lunch | ||
| mup | PR snapd#5379 opened: overlord/snapstate: disallow installing snapd on baseless models <Created by mvo5> <https://github.com/snapcore/snapd/pull/5379> | 11:36 |
| mvo | zyga: I split the snapd prevention bits (and added a trivial test) - I think we deefinitely want this | 11:36 |
| zyga | prevention bits? | 11:36 |
| zyga | the snapd.snap removal/installation? | 11:36 |
| mvo | zyga: disallow installing the snapd snap | 11:36 |
| zyga | note that it breaks the tests today :/ | 11:37 |
| mvo | zyga: it does? which one? | 11:45 |
| zyga | just look at the test failures, all the core 18 tests exploded | 11:46 |
| zyga | I asked if this was expected (perhaps the way we install snapd is not right) but we didn't talk about it since | 11:46 |
| mvo | zyga: aha, I will debug it :) | 11:46 |
| mvo | zyga: "all the core18 tests" - all two of them ;) ? | 11:46 |
| mvo | zyga: aha, I see what is going on | 11:47 |
| * mvo scratches head | 11:47 | |
| mvo | zyga: testing a fix now, and then I will go over the rest. thanks in any case! | 11:49 |
| mborzecki | searedvandal: changes are in AUR now | 11:52 |
| searedvandal | mborzecki, nice, thanks! | 11:52 |
| Son_Goku | mvo, wait, does that mean it'd be possible to make snapd snap either-or if a base snap provided snapd? | 11:55 |
| Son_Goku | I'm confused what PR#5379 actually does | 11:55 |
| Chipaca | Son_Goku: we're transitioning from having snapd in core to having snapd in snapd | 11:58 |
| Son_Goku | :/ | 11:58 |
| Chipaca | Son_Goku: we're special casing the special case so we can special case while we special case | 11:58 |
| Chipaca | Son_Goku: why :/? | 11:58 |
| Son_Goku | because I don't understand what's going on here | 11:58 |
| Son_Goku | I'm confused | 11:59 |
| Chipaca | Son_Goku: core 18 won't have snapd | 11:59 |
| Chipaca | rather | 11:59 |
| zyga | Son_Goku: because of core18 and core16 the idea of having snapd in _a_ core is gone | 11:59 |
| Chipaca | Son_Goku: core18 does not have snapd | 11:59 |
| Chipaca | Son_Goku: neither will core16 | 11:59 |
| zyga | so snapd moves to its own proper package | 11:59 |
| zyga | eventually the only snap that ships snapd will be snapd.snap | 11:59 |
| Chipaca | Son_Goku: today, core does; core will become core16 and snapd | 11:59 |
| Son_Goku | hmm | 11:59 |
| zyga | this will simplify and unify various special cases | 11:59 |
| Son_Goku | there were special cases? | 12:00 |
| zyga | and will make it natural to have bases | 12:00 |
| Chipaca | Son_Goku: but as core and core16 will co-exist, we want to put little yellow "don't step on the bubbling lava" signs | 12:00 |
| zyga | yeah, plenty of them | 12:00 |
| zyga | still are but this will help to remove it | 12:00 |
| zyga | core wil transition to core16 | 12:00 |
| Chipaca | Son_Goku: the end game is _less_ special cases, not more, fwiw | 12:00 |
| Son_Goku | okay, I think I get it | 12:00 |
| Chipaca | Son_Goku: where there must be a snapd snap, but you can have any base (and that base evolves separately from snapd itself) | 12:00 |
| zyga | Son_Goku: snap-confine will hopefully shrink a little thanks to this | 12:00 |
| Son_Goku | most of this doesn't really affect me though, since we don't allow re-exec on Fedora | 12:01 |
| zyga | and snap-run/snap-exec/snapd code will drop some if name == "core" code | 12:01 |
| Son_Goku | since your snapd breaks things | 12:01 |
| * Chipaca hopes Son_Goku doesn't ask what base snapd will use | 12:01 | |
| Son_Goku | I think I have a feeling that snapd will use base snapd | 12:01 |
| Son_Goku | or worse, base ubuntu-core16 | 12:01 |
| * Chipaca votes it uses base 'bo' | 12:01 | |
| zyga | Son_Goku: snapd won't use any base | 12:02 |
| Chipaca | or maybe base 'politically-incorrect-inanimate-object' | 12:02 |
| zyga | it's not a snap that ships apps or services in the traditional sense | 12:02 |
| zyga | more like a vehicle for runtime bits for any base | 12:02 |
| zyga | (snap-confine/exec/snapctl chain) | 12:03 |
| Son_Goku | so it pretty much doesn't affect me | 12:03 |
| Son_Goku | since we don't use those bits | 12:03 |
| zyga | no, you are slightly mistaken | 12:03 |
| Son_Goku | it'd only become a problem once we have a fedora bootable base :/ | 12:03 |
| zyga | you do use snap-exec and snapctl from core | 12:03 |
| zyga | that's always been the case | 12:03 |
| zyga | you don't use snap-confine from core when running snaps from the outside | 12:04 |
| Chipaca | Son_Goku: bootable fedora base is happening though, right? | 12:04 |
| Son_Goku | that's something zyga and I are working toward, yes | 12:04 |
| Son_Goku | I already know that we're in for hell because I can't swap the snapd :/ | 12:04 |
| zyga | Chipaca: yes, eventually, I think this cycle we will get fedora29 base for apps and future development though | 12:04 |
| * Son_Goku really wishes core16 / core18 would be ubuntu-core16 / ubuntu-core18 | 12:05 | |
| Son_Goku | that's what they actually are, after all | 12:05 |
| Chipaca | Son_Goku: I think it's that until there are other bases realistically out there being used, we don't want to have people think they're downloading all of ubuntu just to run tmnationsforever | 12:08 |
| Son_Goku | well there's already other bases in use | 12:08 |
| Son_Goku | at least ikey has the one for steam | 12:08 |
| * Chipaca misses ikey | 12:08 | |
| Son_Goku | and _a_ fedora base snap will be available by Fedora 29 GA | 12:09 |
| Son_Goku | I can almost nearly guarantee it | 12:09 |
| Son_Goku | primarily because I can make one whenever I want | 12:10 |
| zyga | Son_Goku: one good thing is that "core" will go away and become core{16,18} and those will shrink | 12:10 |
| Son_Goku | the work zyga and I will be doing this development cycle is integrating this into the infra tooling so it's literally part of the compose | 12:10 |
| Chipaca | Son_Goku: I'll raise it in the standup (unless zyga does it first) | 12:10 |
| Son_Goku | that is, part of the process to make all the release artifacts | 12:10 |
| zyga | we also considered (though not scheduled to do it) a bootless core which would be even smaller by a large amount | 12:10 |
| Chipaca | I think the bootless split was kicked to 20 | 12:11 |
| zyga | yeah | 12:11 |
| Chipaca | too many moving parts | 12:11 |
| zyga | yep | 12:11 |
| zyga | Chipaca: raise what exactly? | 12:11 |
| Chipaca | zyga: ubuntu-core18 instead of just core18 | 12:11 |
| Son_Goku | zyga, what does snapd.seeded.service do? | 12:11 |
| Chipaca | Son_Goku: wait until snapd is seeded | 12:11 |
| zyga | Son_Goku: tells you that the system has installed all of the snaps that are in the seed (from the model) | 12:12 |
| zyga | Son_Goku: it basically tells you that it is ready after first boot | 12:12 |
| Son_Goku | ah | 12:12 |
| Son_Goku | so is this something we need to have enabled in the fedora preset? | 12:12 |
| zyga | before that snapd is busy doing stuff and not really responding | 12:12 |
| Son_Goku | because right now, it ai't | 12:12 |
| Son_Goku | *ain't | 12:12 |
| zyga | Son_Goku: it's useful as target of "after snapd is there" | 12:12 |
| Chipaca | Son_Goku: shouldn't hurt, and would let you play with seeds | 12:12 |
| zyga | we added it because someone needed this kind of thing for another piece of software | 12:12 |
| zyga | I added it to suse | 12:12 |
| zyga | it's not core specific, I think it could be in fedora as well | 12:13 |
| mborzecki | though maybe not enabled by default right? | 12:16 |
| zyga | why not? | 12:16 |
| mborzecki | because it will wake up snapd | 12:16 |
| zyga | mmmm | 12:16 |
| zyga | interesting | 12:16 |
| mborzecki | seeded -> snapd.socket -> snapd.service | 12:17 |
| zyga | can we write the unit in a way that would make it do stuff only if snapd was enabled? | 12:17 |
| Son_Goku | no | 12:17 |
| Son_Goku | because you added Requires | 12:17 |
| zyga | I see | 12:17 |
| Son_Goku | you forced it on | 12:17 |
| zyga | then I agree with mborzecki | 12:17 |
| Son_Goku | yeah, so probably should stay off by default | 12:17 |
| mborzecki | i mean, once you know you need it you'll enable it :) | 12:17 |
| Son_Goku | it's only needed for firstboot if we had them preloaded, right? | 12:18 |
| Son_Goku | maybe the unit can be adjusted to have firstboot condition | 12:18 |
| zyga | mmm, interesting | 12:19 |
| zyga | how could we do that? | 12:19 |
| zyga | I think that's a pretty good idea | 12:19 |
| Son_Goku | ConditionFirstBoot= takes a boolean argument. This condition may be used to conditionalize units on whether the system is booting up with an unpopulated /etc directory (specifically: an /etc with no /etc/machine-id). This may be used to populate /etc on the first boot after factory reset, or when a new system instance boots up for the first time. | 12:19 |
| Chipaca | zyga: that's a very particular "first boot" condition | 12:19 |
| Son_Goku | from systemd.unit(5): https://www.mankier.com/5/systemd.unit#ConditionFirstBoot= | 12:20 |
| mborzecki | econnreset again, 2018/06/22 11:12:14.534944 store.go:1555: DEBUG: Download succeeded in 5.257s (102MB/s). | 12:20 |
| Son_Goku | alternatively, you could do ConditionPathExists= and do some custom logic here in the seeding code: https://www.mankier.com/5/systemd.unit#ConditionPathExists= | 12:20 |
| zyga | like the presence of /var/lib/snapd/{seed} or model or something | 12:21 |
| zyga | not sure but something like that | 12:21 |
| Son_Goku | yeah | 12:22 |
| Son_Goku | something that would make it far less penalizing to have it | 12:23 |
| Son_Goku | zyga, ConditionPathExists also takes a negation operator | 12:23 |
| Son_Goku | so !/var/lib/snapd/seeded would also work | 12:23 |
| zyga | pedronis: hey | 12:27 |
| zyga | pedronis: I wrote the post that I was supposed to, about the refresh + restart issue | 12:27 |
| zyga | https://forum.snapcraft.io/t/issue-with-using-snapstate-active-for-interface-repository/6065 | 12:27 |
| zyga | could you please read it and ensure I didn't miss anything critical or didn't skew the facts | 12:27 |
| Son_Goku | mborzecki, zyga , what happens if xdg-desktop-portal < 0.11 is installed on fedora for snapd? | 12:31 |
| zyga | Son_Goku: I don't know the version specifically | 12:31 |
| zyga | is that the old portal that was not aware of snapd? | 12:31 |
| Son_Goku | yes | 12:32 |
| Son_Goku | xdg-desktop-portal 0.9 is in Fedora 27 | 12:32 |
| Son_Goku | 0.11 is in Fedora 28+ | 12:32 |
| zyga | portals would not know they are used by a confined app | 12:32 |
| mborzecki | zyga: pushed an update to 5370 | 12:32 |
| zyga | so they would not trigger the portal-specific file open dialogs | 12:32 |
| zyga | (in cooperating apps) | 12:32 |
| zyga | the UX would suck | 12:33 |
| Son_Goku | :/ | 12:33 |
| zyga | (like it does now, not a regression) | 12:33 |
| Son_Goku | so it's no worse than today? | 12:33 |
| zyga | I believe it would be exactly like today | 12:33 |
| Son_Goku | so I don't need to add a "Conflicts: xdg-desktop-portal < 0.11"? | 12:33 |
| zyga | one sec | 12:33 |
| zyga | no no | 12:33 |
| zyga | https://github.com/snapcore/snapd/pull/5271 | 12:34 |
| mup | PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271> | 12:34 |
| zyga | scroll to the bottom | 12:34 |
| zyga | there's some talk about this exact issue | 12:34 |
| === pstolowski|lunch is now known as pstolowski | ||
| Son_Goku | so the answer is, openSUSE is fucked but not Fedora | 12:36 |
| mborzecki | tumbleweed to? | 12:37 |
| Son_Goku | yes | 12:39 |
| Son_Goku | openSUSE has been shipping Flatpak by default for a while now | 12:39 |
| Son_Goku | it's also shipping in SLE 15, too | 12:40 |
| zyga | Son_Goku: tumbleweed will probably get the latest version soon | 12:41 |
| zyga | it has 0.11.7 | 12:41 |
| zyga | Son_Goku: note that I enabled apparmor on tumbleweed | 12:41 |
| zyga | Son_Goku: so there's way more confinement than before :) | 12:42 |
| Son_Goku | eh | 12:42 |
| Son_Goku | I'm slightly annoyed you didn't merge my changes entry into the OBS package | 12:42 |
| zyga | I can do that in the final sync | 12:42 |
| zyga | it is not out yet | 12:42 |
| Son_Goku | I'm building snapd 2.33.1 and snapd-glib 1.41 now | 12:46 |
| Chipaca | niemeyer, mvo: I've got a meeting that I need to be in instead of the standup today | 12:46 |
| niemeyer | Chipaca: Ack, thanks for the note | 12:47 |
| Chipaca | niemeyer, mvo: it should be short, but if not --- i'm working on warnings, fixing all the tests in daemon/ that i've broken :-) | 12:47 |
| Chipaca | figured out the source of the panic, also | 12:47 |
| Chipaca | so huzzah | 12:47 |
| mborzecki | anyone wants to look at #5363 and #5366? | 12:48 |
| mup | PR #5363: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363> | 12:48 |
| mup | PR #5366: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366> | 12:48 |
| Son_Goku | zyga, also, xdg-desktop-portal will now supplement either flatpak or snapd | 12:49 |
| Son_Goku | err, the gtk and kde portals will | 12:49 |
| Son_Goku | https://src.fedoraproject.org/rpms/xdg-desktop-portal-gtk/blob/master/f/xdg-desktop-portal-gtk.spec#_22 | 12:50 |
| Son_Goku | https://src.fedoraproject.org/rpms/xdg-desktop-portal-kde/blob/master/f/xdg-desktop-portal-kde.spec#_40 | 12:50 |
| zyga | Thank you pedronis ! | 12:57 |
| pedronis | zyga: your description was not too wrong, but seemed to me a bit still too high level | 12:59 |
| zyga | yes, you got the specific details in place, thank you | 13:00 |
| pedronis | mvo: https://launchpad.net/bugs/1772844 | 13:26 |
| mup | Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844> | 13:26 |
| mvo | pedronis: thank you! | 13:30 |
| mvo | sil2100: does foundations have https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1772844 on the radar? if not, who should I ask about this? the bug is most likely that the seed.yaml needs to be tweeaks and things needs to be around a bit. happy to talk about the details once I know with whom :) | 13:31 |
| mup | Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844> | 13:31 |
| sil2100 | mvo: hmm, first time I hear about this! Let me read it up | 13:33 |
| mborzecki | niemeyer: experimental.parallel-instances then? | 13:36 |
| pedronis | pstolowski: what's the status of disconnect hooks? | 13:37 |
| niemeyer | mborzecki: +1 | 13:37 |
| mborzecki | ack | 13:38 |
| pedronis | pstolowski: this is a strange error: Disconnect bluez:client from bluez:service (snapd changed, please retry the operation: cannot disconnect bluez:client from bluez:service, it is not connected) | 13:38 |
| pstolowski | pedronis: i think i know why that is, i forgot to disable discard-conns, at the very least | 13:39 |
| pedronis | we do need to keep it though | 13:40 |
| pstolowski | pedronis: i'll ping you when it's ready | 13:40 |
| pstolowski | pedronis: i know | 13:40 |
| pedronis | but making it idempotent | 13:40 |
| pstolowski | pedronis: handler needs to stay, but task shouldn't be created for new changes | 13:40 |
| pedronis | ok, I'm still a bit confused | 13:40 |
| pedronis | I would have expected it to come before, not after | 13:41 |
| pedronis | pstolowski: also notice that these strange error seems about self connections | 13:41 |
| pedronis | pstolowski: are we trying to disconnect them twice? | 13:41 |
| pstolowski | pedronis: ah, i didn't think of it, might be the same issue we had with autoconnect | 13:42 |
| pedronis | I doubt because the code would be different | 13:42 |
| pedronis | but maybe the connect does strange things | 13:42 |
| pedronis | anyway an interesting datapoint | 13:43 |
| pedronis | I would expect the discard-conns to do nothing, assuming it happens last | 13:43 |
| Chipaca | I'm going offline for a while, will check in tonight again (with moar warnings) | 13:43 |
| * Chipaca -> school stuff and such | 13:43 | |
| pedronis | pstolowski: ah, mayb repo connections in this case return the same connection twice ? | 13:47 |
| pedronis | pstolowski: yes, the issue is repo.Connections, self connections are reported twice | 13:48 |
| pstolowski | pedronis: heh, indeed! i wonder if there is any undesired effect if i fix this centrally (in the repo.Connections) | 13:59 |
| pstolowski | it shouldn't afaict, don't think it has a use case | 14:00 |
| pedronis | pstolowski: it shouldn't, it's kind of weird/unexpect to get the same conn twice | 14:18 |
| ali1234 | should i install snapcraft from apt or from snap? | 14:29 |
| mborzecki | niemeyer: rename to parallel-instances pushed to #5370 | 14:32 |
| mup | PR #5370: overlord/{config,snap}state: introduce parallel-installs feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370> | 14:32 |
| niemeyer | mborzecki: Thanks! | 14:32 |
| pstolowski | ali1234: there is no reason not to use the one from snap; go for the snap; it also makes it easy to switch to a beta version (and back) in case of an important fix coming | 14:34 |
| popey | ali1234: i use the snap, personally. | 14:36 |
| pstolowski | pedronis: pushed the repo fix but discard-conns still needs work (undo for single disconnect) | 14:36 |
| * zyga fixed all the entries in the opensuse snapd.changes changelog to have non-fake copy/pasted/tweaked dates | 14:53 | |
| zyga | Pharaoh_Atem: ^ that's for you :) | 14:54 |
| Pharaoh_Atem | :) | 14:54 |
| zyga | apparently copy/pasting and tweaking seconds is ... popular | 14:55 |
| Pharaoh_Atem | :/ | 14:55 |
| mvo | zyga: my bad - I need an emacs mode or something of this. or obs-dch or whatnot | 14:56 |
| zyga | mvo: "ons vc" | 14:56 |
| zyga | er | 14:56 |
| zyga | "osc vc" | 14:56 |
| zyga | (sorry, spellchecker doesn't love acronyms) | 14:57 |
| zyga | that edits the changelog | 14:57 |
| mborzecki | well, to be fair it'd be nice if changelog included package version/release, otherwise rpm -q --changelog is not really that useful | 14:58 |
| mvo | nice, thank you | 14:58 |
| mvo | I hope I remember | 14:58 |
| zyga | the changelog is still wrong | 14:58 |
| zyga | sigh | 14:58 |
| zyga | someone wrote a tool that returns false | 14:58 |
| zyga | rather than "on line 123, ..." | 14:58 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | zyga: on line 123, .. false :) | 15:02 |
| zyga | gah, the bugzilla email apocalypse | 15:03 |
| Pharaoh_Atem | :D | 15:03 |
| mborzecki | btw emacs' rpm-mode can add changelog entries, but it's not aware of opensuse's *.changes file split | 15:04 |
| Pharaoh_Atem | which is actually annoying | 15:04 |
| Pharaoh_Atem | and also I'm working on fixing `osc vc` to properly generate entries with full author identities | 15:04 |
| Pharaoh_Atem | zyga, mborzecki, niemeyer, mvo: https://forum.snapcraft.io/t/snapd-updates-in-fedora/4342/5?u=conan_kudo | 15:08 |
| mvo | zyga: I found the issue with 5369 - ERROR installation not allowed by "daemon-notify" slot rule of interface "daemon-notify" | 15:08 |
| mvo | zyga: this is when it tries to mount the core snap | 15:08 |
| pedronis | mvo: zyga's RFC branch has code for that | 15:25 |
| zyga | yeah | 15:25 |
| zyga | you need to take that patch (that really pedronis wrote :) | 15:25 |
| mvo | pedronis: yeah, thank you, I figured it out by now, I added a fix that should make these tests work | 15:28 |
| mborzecki | mvo: shall i land #5374 or do you plan to push more patches? | 15:29 |
| mup | PR #5374: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5374> | 15:29 |
| ali1234 | when i run snapcraft: E:Failed to fetch copy:/home/al/.cache/snapcraft/stage-packages/apt/.../var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_bionic-security_main_dep11_icons-48x48.tar.gz Hash Sum mismatch | 15:35 |
| ali1234 | "..." is a very long hex string | 15:36 |
| mup | PR snapd#5374 closed: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5374> | 15:36 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/5379 can land as well | 15:37 |
| zyga | shall I? | 15:37 |
| mup | PR #5379: overlord/snapstate: disallow installing snapd on baseless models <Created by mvo5> <https://github.com/snapcore/snapd/pull/5379> | 15:37 |
| mvo | mborzecki: 5374 should be good | 15:51 |
| mvo | zyga: same for 5379 | 15:52 |
| zyga | there is a comment on 5374 | 15:52 |
| mup | PR snapd#5379 closed: overlord/snapstate: disallow installing snapd on baseless models <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5379> | 15:53 |
| zyga | Pharaoh_Atem: I wrote a tool for checking changelog entries | 15:56 |
| zyga | that's much nicer than the original | 15:56 |
| b_b | hi | 16:00 |
| zyga | niemeyer: where is the meeting taking place? | 16:03 |
| niemeyer | zyga: We're in the standup | 16:03 |
| b_b | i'm having this bug on snapcraft.io website | 16:03 |
| b_b | https://github.com/canonical-websites/snapcraft.io/pull/687 | 16:03 |
| b_b | but it seems resolved by this PR | 16:04 |
| b_b | i've tried to upload a 48px icon to a snap => 502 | 16:04 |
| mvo | 5309 is hopefully ready now if someone wants to do a second review | 16:05 |
| b_b | commented the PR | 16:13 |
| b_b | anyway, i'm happy/proud, my first snap is released on stable :) https://snapcraft.io/timeline | 16:14 |
| b_b | with a ridiculus small icon, but the dev team can't find the source file :p | 16:15 |
| b_b | see u ++ | 16:16 |
| diddledan | why am I being denied access to files in core? Log: apparmor="DENIED" operation="open" profile="snap.mycroft.bus" name="/snap/core/4830/lib/x86_64-linux-gnu/liblzma.so.5.0.0" pid=16522 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 | 16:43 |
| Pharaoh_Atem | zyga: oh? | 16:53 |
| zyga | yeh | 16:53 |
| zyga | one moment | 16:53 |
| zyga | I'm in a call | 16:53 |
| pstolowski | zyga: can you take another look at #5326 (doesn't have to be today, Monday is fine)? | 16:57 |
| mup | PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326> | 16:57 |
| mup | PR snapd#5380 opened: tests: blacklist more main tests for core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5380> | 16:57 |
| zyga | Pharaoh_Atem: wanna see it? | 17:10 |
| zyga | niemeyer: have a good weekend too :) | 17:12 |
| zyga | Pharaoh_Atem: halp | 17:13 |
| zyga | %{!?systemdgeneratordir: %global systemdgeneratordir %{_prefix}/lib/systemd/system-generators} | 17:13 |
| zyga | this doesn't produce a path that is absolute | 17:13 |
| pedronis | zyga: running setup-profiles twice is not a problem right? | 17:13 |
| zyga | no, not a problem | 17:13 |
| zyga | Pharaoh_Atem: undo help, I see the typo now | 17:14 |
| Pharaoh_Atem | zyga: the answer is yes | 17:18 |
| zyga | cool, just polishing a bit | 17:19 |
| zyga | Pharaoh_Atem: https://gitlab.com/zygoon/rpmtools/blob/master/changes-checker | 17:25 |
| zyga | Pharaoh_Atem: I need to take a break from work and ... buy some DVD-RWs | 17:26 |
| zyga | (don't ask why) | 17:26 |
| zyga | I should actually hop on my bike and go to a mall nearby | 17:26 |
| pedronis | zyga: now a remember though there is wrinkle which that setup-profiles and the active managing *link* tasks are not symmetrics at the moment | 17:28 |
| pedronis | zyga: on the Do path we have unlink-current-snap and link-snap but only one setup-profiles doing both | 17:29 |
| zyga | hmm hmm | 17:29 |
| zyga | pedronis: I will think about this over weekend | 17:30 |
| pedronis | we really to split the tasks over those two somehow | 17:30 |
| pedronis | or we get again a misaligned state | 17:30 |
| pedronis | zyga: what I mean for example on undo the undo of unlin-current-snap should resetup the profile of the old revision | 17:30 |
| pedronis | that's not how it works now though | 17:31 |
| pedronis | is done much earlier in the undo of setup-profiles | 17:31 |
| pedronis | zyga: conceptuall the sequence should have been (but isn't also because of optimisation): unlink-current-snap -> remove-profiles -> ... -> setup-profiles -> link-snap | 17:33 |
| zyga | mmm | 17:34 |
| pedronis | that's really the sequence we want to collapse into the *link* tasks | 17:34 |
| pedronis | to get correct state behavior | 17:34 |
| pedronis | otherwise we still the bug on undo | 17:34 |
| zyga | setup profiles has correct undo handling _now_ but I see how the collapse needs to change that | 17:34 |
| pedronis | yes, it doesn't work | 17:34 |
| pedronis | because again we would on undo setup profiles | 17:34 |
| pedronis | while the snap is inactive | 17:35 |
| pedronis | it needs to be done in the undo of unlink-current-snap | 17:35 |
| zyga | right, I agree; when I said correct I meant undo (if it has the right state) does the setup for the correct revision | 17:35 |
| zyga | yep | 17:35 |
| zyga | mborzecki, Pharaoh_Atem: can you ack https://build.opensuse.org/request/show/618540 | 17:36 |
| zyga | (if you agree :) | 17:36 |
| zyga | this is up-to-date with master and https://github.com/snapcore/snapd/pull/5377 | 17:36 |
| mup | PR #5377: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <https://github.com/snapcore/snapd/pull/5377> | 17:36 |
| zyga | so please review 5377 first | 17:36 |
| zyga | and if that is ok, ack the sync request | 17:36 |
| mup | PR snapd#5329 closed: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329> | 18:35 |
| * cachio akf | 19:00 | |
| zyga | re! | 19:01 |
| zyga | Pharaoh_Atem: how do you like it? | 19:01 |
| * zyga feels much better today, having spent a few hours outside | 19:02 | |
| zyga | I should plan an active outdoor weekend | 19:02 |
| zyga | Son_Goku: how do you like my rpmtools script? | 19:03 |
| Son_Goku | zyga, hadn't seen it, sorry | 19:03 |
| Son_Goku | wasn't at my desk | 19:04 |
| zyga | no worries | 19:04 |
| zyga | I will play with it to be more full-featured | 19:04 |
| niemeyer | pstolowski: Sorry, the meeting has overrun | 19:06 |
| niemeyer | pstolowski: I'm available to do it now if you still want to | 19:06 |
| Son_Goku | zyga, it looks nice! | 19:07 |
| zyga | I'll make it read the rest of the changelog and model it | 19:07 |
| zyga | stick a license on top | 19:07 |
| zyga | and then look at spec files | 19:07 |
| pstolowski | niemeyer: yep, let's | 19:07 |
| zyga | to read embedded changelogs from fedora-like systems | 19:07 |
| niemeyer | pstolowski: Cool, heading to the standup | 19:07 |
| Son_Goku | zyga: nice | 19:08 |
| zyga | pstolowski: what's the topic? | 19:08 |
| Son_Goku | note that RPM now supports two time styles | 19:08 |
| zyga | hotplug? | 19:08 |
| pstolowski | zyga: yes | 19:08 |
| mup | PR snapd#5381 opened: interfaces: make findSnapdPath smarter <Created by mvo5> <https://github.com/snapcore/snapd/pull/5381> | 19:08 |
| zyga | can I listen? | 19:08 |
| Son_Goku | the one in changes files, and the one you've seen in spec files | 19:08 |
| pstolowski | zyga: sure | 19:08 |
| zyga | Son_Goku: oh? they are different? | 19:08 |
| zyga | I didn't notice | 19:08 |
| zyga | well | 19:08 |
| zyga | some testing required :) | 19:08 |
| zyga | I'll write a spec file _for_ this tool | 19:08 |
| zyga | cool, I'll keep you in the loop | 19:09 |
| zyga | Son_Goku: I also plan to see how gitlab CI works | 19:09 |
| zyga | to see if I can do a pipeline with mypy/tests, package builds and maybe even publishing | 19:10 |
| pedronis | zyga: niemeyer: there is another thing to consider with the plan we discussed, which is what to do about things guaranteed by ifacemanager Runner blocked predicate, now we would have potentially tasks across two managers/runners | 19:10 |
| zyga | ah, because setup-profiles would block in the old world but not in the new one (naively) without extra help, correct? | 19:11 |
| pedronis | yes | 19:14 |
| pedronis | and blocking is messy because two managers/runners | 19:14 |
| pedronis | unless we set them up with one runner | 19:15 |
| pedronis | which is theoritecally possible | 19:15 |
| pedronis | but the predicate would be more involved than the current one | 19:15 |
| pedronis | zyga: I wrote something in the topic about what I understand of the plan and also describing this issue | 19:20 |
| zyga | Thank you, I will look at it after the call | 19:21 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | Pharaoh_Atem: do you want to review the changes to opensuse packaging? | 19:48 |
| zyga | or shall I pull the trigger and just merge it? | 19:48 |
| * zyga merges it | 19:52 | |
| mup | PR snapd#5377 closed: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5377> | 19:53 |
| ondra | kyrofa ping | 20:44 |
| kyrofa | Hey there ondra | 20:48 |
| ondra | kyrofa hey | 20:48 |
| kyrofa | You're up late! | 20:48 |
| ondra | kyrofa just quick question :) | 20:48 |
| kyrofa | Hit me | 20:49 |
| ondra | kyrofa I know :( | 20:49 |
| ondra | kyrofa is there plan to support layouts definitions natively or we will rely on passthrough? | 20:49 |
| kyrofa | ondra, oh certainly, just using passthrough while layouts are unstable | 20:50 |
| ondra | kyrofa I have situation where I need to overlay ust/lib/<arch>/something | 20:50 |
| kyrofa | ondra, feel free to experiment using passthrough, it won't suddenly break once we introduce official support | 20:51 |
| ondra | kyrofa and struggling to come up with syntax to make it combined with "- to armhf:" | 20:51 |
| kyrofa | Oh, that'll be problematic indeed | 20:51 |
| ondra | kyrofa so I use passthrough for this in other projects | 20:52 |
| kyrofa | ondra, your concern is the <arch> I'm assuming? | 20:52 |
| ondra | kyrofa but here I'd need in top level support for "to <arch>: | 20:52 |
| kyrofa | Yeah, no such thing I'm afraid | 20:52 |
| kyrofa | This is just to support the <arch> in there, right? | 20:52 |
| ondra | kyrofa I guess I cannot use "to <arch> in top level right? | 20:53 |
| ondra | kyrofa well there could be two ways | 20:53 |
| kyrofa | Correct. But try replacing <arch> with $SNAPCRAFT_ARCH_TRIPLET | 20:53 |
| ondra | kyrofa ah that is there? | 20:53 |
| ondra | kyrofa let me try | 20:53 |
| ondra | this could solve it | 20:54 |
| kyrofa | ondra, only in snapcraft, but it'll should turn into a text replacement for the resulting snap.yaml | 20:54 |
| mup | PR snapd#5382 opened: tests: add halt-timeout to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5382> | 20:54 |
| ondra | kyrofa damn close | 20:56 |
| ondra | kyrofa so it replaces only one | 20:56 |
| kyrofa | I'm not sure I understand | 20:56 |
| ondra | kyrofa https://paste.ubuntu.com/p/QWpVVsk6MC/ | 20:57 |
| kyrofa | ondra, nooo, that's terrible | 20:58 |
| kyrofa | :P | 20:58 |
| kyrofa | Let me look into that real quick | 20:59 |
| ondra | kyrofa how's that possible? :D | 20:59 |
| ondra | kyrofa thanks bunch! | 20:59 |
| kyrofa | I suspect a naive search/replace | 20:59 |
| ondra | kyrofa no I think I know why | 21:02 |
| ondra | kyrofa it's deliberate | 21:02 |
| ondra | kyrofa because when you for example use there $SNAP_COMMON | 21:03 |
| ondra | kyrofa this cannot be replaces there it has only meaning on actual install | 21:03 |
| ondra | kyrofa so I guess there is some rule | 21:03 |
| ondra | kyrofa but you do not expect this to be used in actual target, as there is no point overlay your own files, since you have control over those anyway | 21:04 |
| ondra | kyrofa but may be we should treat snapcraft's own environment variables differently as those on opposite have no meaning on actual install | 21:05 |
| kyrofa | Indeed, and we do. The replacement isn't very smart, it seems | 21:06 |
| kyrofa | We pass everything through except these specific types of things | 21:07 |
| ondra | kyrofa is there easy fix for this? | 21:15 |
| kyrofa | ondra, yes, but it's a snapcraft fix, working on it now | 21:16 |
| kyrofa | ondra, I can give you a branch once I'm done, if that's helpful | 21:16 |
| ondra | kyrofa ah, thanks buch! | 21:16 |
| ondra | kyrofa yeah | 21:16 |
| kyrofa | Okay give me a few | 21:16 |
| ondra | kyrofa sure :) | 21:16 |
| zyga | kyrofa: note, layout spec is stable | 21:20 |
| zyga | it's the implementation that varies | 21:20 |
| zyga | I think it'd be nice if we could get layouts yaml into snapcraft proper now | 21:20 |
| zyga | and hey :) | 21:21 |
| zyga | yes, it's late | 21:21 |
| * zyga experiments with opensuse | 21:21 | |
| ondra | zyga :) | 21:25 |
| ondra | zyga so need for snap set core has been removed? | 21:25 |
| kyrofa | ondra, any chance you could log a bug for me? Got it licked | 21:26 |
| zyga | ondra: not yet | 21:26 |
| zyga | but that's the implementation | 21:26 |
| zyga | not the yaml | 21:26 |
| zyga | kyrofa: licked? | 21:26 |
| ondra | kyrofa sure, I can do that | 21:26 |
| * zyga burns some recovery DVDs | 21:26 | |
| kyrofa | zyga, snapcraft can't break backward compat. As long as you have it behind a feature flag, you can. Until you can't, seems imprudent to bake it into snapcraft | 21:27 |
| zyga | mm | 21:27 |
| zyga | k | 21:27 |
| zyga | I'll do my best to get it off feature flags | 21:27 |
| kyrofa | If we didn't have passthrough, it would be different | 21:27 |
| kyrofa | zyga, you've never heard someone say "licked" before? | 21:28 |
| zyga | no, that's why I'm curious | 21:28 |
| zyga | I recall some cartoon | 21:28 |
| ondra | zyga I'm all for that feature, I have even git snap pending for release :D | 21:28 |
| zyga | when it was clear that this has a second meaning | 21:28 |
| kyrofa | zyga, it's a colloquialism, just meaning to beat a problem | 21:29 |
| zyga | I see | 21:30 |
| zyga | neat | 21:30 |
| ondra | lol | 21:30 |
| * zyga mutters something about midnight petroleum | 21:32 | |
| ondra | kyrofa https://bugs.launchpad.net/snapcraft/+bug/1778287 | 21:32 |
| mup | Bug #1778287: snapcraft not replacing all occurrences of $SNAPCRAFT_ARCH_TRIPLET <Snapcraft:New> <https://launchpad.net/bugs/1778287> | 21:32 |
| ondra | kyrofa I had even evil hack idea to fix it on LP, unfortunately not working | 21:33 |
| ondra | kyrofa I called from one override-build: sed -i 's/\/usr\/lib\/.*\/ondra/\/usr\/lib\/'"$SNAPCRAFT_ARCH_TRIPLET"'\/ondra/g' ../../../snap/snapcraft.yaml | 21:33 |
| ondra | kyrofa but one can't cheat snapcraft :) | 21:34 |
| * cachio afk | 21:38 | |
| kyrofa | Death, taxes, and snapcraft | 21:39 |
| mup | PR snapcraft#2166 opened: project_loader: replace dict keys as well as values <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2166> | 21:42 |
| kyrofa | ondra, that's ^ the one you want. I'm building a snap of it now | 21:42 |
| ondra | kyrofa how can I test with snapcraft-pr? | 21:43 |
| kyrofa | snapcraft-pr.init 2166 | 21:43 |
| kyrofa | Then use `snapcraft-pr 2166` instead of `snapcraft` in any command | 21:43 |
| mup | PR #2166: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2166> | 21:43 |
| ondra | kyrofa running clean build now | 21:50 |
| kyrofa | ondra, snapcraft-pr will get angry if you try to cleanbuild. It's the same as running from source: you can't cleanbuild, it'll just pull in the deb | 21:51 |
| kyrofa | ondra, if you want to cleanbuild, wait for the snap, or install snapcraft-pr inside a clean container and run it normally in there | 21:51 |
| kyrofa | LP claims the amd64 snap is 8 minutes away | 21:52 |
| ondra | kyrofa worked :D | 21:52 |
| ondra | kyrofa this is simple snap, only stage packages + dump plugin | 21:52 |
| kyrofa | Awesome! Mind mentioning that on the PR? | 21:52 |
| kyrofa | ondra, would releasing the snap in a branch be helpful to you, or should I cancel that? | 21:53 |
| ondra | kyrofa you can cancel that | 21:54 |
| ondra | kyrofa I'd need it in LP more | 21:55 |
| ondra | kyrofa but not super urgent | 21:55 |
| ondra | kyrofa I can manually repack | 21:55 |
| kyrofa | ondra, yeah, sorry, not a log I can do about that, but it'll be in the next release | 21:55 |
| ondra | kyrofa yeah I know for that we need LP start using snapcraft as snap | 21:56 |
| ondra | kyrofa but apparently in works | 21:56 |
| ondra | kyrofa but nothing urgent for me now, so I can wait for next release :) | 21:57 |
| ondra | kyrofa thanks bunch for quick fix though :) | 21:57 |
| cjwatson | ondra: you can select it manually | 22:02 |
| ondra | cjwatson how can I do that? | 22:02 |
| cjwatson | ondra: currently API-only - see auto_build_channels on https://launchpad.net/+apidoc/devel.html#snap, or channels on https://launchpad.net/+apidoc/devel.html#snap-requestBuild | 22:03 |
| ondra | cjwatson this is awesome, I can see one can choose edge of core :D | 22:05 |
| cjwatson | (I have a patch in the review queue to add web UI for it, but you can use it without that) | 22:05 |
| cjwatson | yeah, that's mostly intended for QA | 22:05 |
| ondra | cjwatson pretty cool | 22:06 |
| cjwatson | thanks | 22:06 |
| kyrofa | ondra, of course! | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!