[09:41] <fabbione> hey tmarble
[09:41] <tmarble> hi fabbione
[09:42] <tmarble> fabbione: sorry -- didn't see you here -- multitasking
[09:42] <tmarble> i head out to San Diego in about 1 hour
[09:42] <fabbione> no problem
[09:42] <fabbione> i saw your ping yesterday but i was already weekend'ing :)
[09:42] <fabbione> ok
[09:42] <tmarble> you can do that!
[09:42] <fabbione> have fun there
[09:42] <fabbione> not always.. my wife doesn't allow me to :)
[09:42] <tmarble> it's all work :-(   SPECjvm2006
[09:43] <fabbione> well i love to travel..
[09:43] <fabbione> is there anything i can do for you before you take off?
[09:43] <tmarble> Please note: https://launchpad.net/sprints/uds-mtv
[09:44] <tmarble> I will be attending all week and coordinating activities for Sun
[09:44] <fabbione> ok
[09:44] <fabbione> than you should subscribe to all specs you are supposed to be in
[09:44] <tmarble> any tips on things to think about and/or how to prepare for UDS would be most helpful
[09:45] <fabbione> once you are registered go to the spec tracker
[09:45] <tmarble> with the exception of the their launchpad page -- is there any other mechanism to determine "who's who" among developer/attendees?
[09:45] <fabbione> and make sure to be subscribed to the one you are interested in
[09:45] <tmarble> got it
[09:45] <fabbione> nope
[09:45] <fabbione> but there will be a general introduction the first day
[09:46] <tmarble> first day = Sunday
[09:46] <tmarble> ?
[09:46] <fabbione> i assume we will do like other times.. everybody stands up and say a couple of word on "who am I"
[09:46] <fabbione> yes sunday is my very best guess
[09:46] <tmarble> I'll arrive around noon-ish on Monday
[09:46] <tmarble> do you suppose that developers are going to want to go on caffeine induced hackathons for 24-hour straight?
[09:47] <tmarble> or, would there be some interest, do you think, in *a little* sight-seeing (e.g. food or nightlife in San Francisco)?
[09:47] <fabbione> no, specs writing is boring enough that we spend the evening drinking to forget :)
[09:47] <fabbione> sight seeing and life > *
[09:48] <fabbione> are you going to be the only guy from SUN showing up?
[09:48] <fabbione> Simon was talking about a few more coming
[09:48] <tmarble> hmmm  I'm very tempted to organize an outing... say tuesday-ish?... for some (techno dance) clubbing... sound good?
[09:48] <fabbione> and we were trying to arrange a dinner just to get to know eachother before starting to work
[09:48] <tmarble> there will be several -- don't have a full count yet
[09:48] <tmarble> cool -- any ideas on which day the dinner would take place
[09:48] <fabbione> well they need to register in LP and subscribe to specs, otherwise it will be caothic
[09:49] <tmarble> right
[09:49] <fabbione> dinner should be wed AFAIK
[09:49] <fabbione> it really depends.. Simon didn't answer one single email i wrote to him to have names and dates
[09:49] <tmarble> now, let's say, Sun person wants to package application foobar for Ubuntu (Debian)... if there isn't a spec yet, should they create one?
[09:50] <tmarble> I apologize on Simon's behalf for that... I'll be much more responsive
[09:50] <fabbione> yes, they need to create a spec in wiki.u.c (use the spec template) register it in LP and get it scheduled for MV
[09:50] <tmarble> I just got approved late friday
[09:50] <tmarble> k
[09:50] <fabbione> but there is a time limit for specs submission
[09:50] <fabbione> let me check
[09:51] <tmarble> but, I don't see anything on the schedule yet -- > will the schedule be on the wiki -> ? https://wiki.ubuntu.com/UbuntuDeveloperSummitMountainView
[09:51] <fabbione> the schedule will be generated on a daily base
[09:51] <tmarble> OK....
[09:51] <fabbione> because specs don't get all approved/worked at the same speed
[09:51] <fabbione> but
[09:51] <fabbione> if SUN guy is known to show up tue, his specs will not be scheduled for monday
[09:52] <fabbione> or something like that
[09:52] <tmarble> ok
[09:52] <fabbione> i mean.. apply that rule in different ways
[09:52] <fabbione> like he needs to leave early and so on
[09:52] <fabbione> point is that fixed schedule simply doesn't work
[09:52] <tmarble> sure, that makes sense
[09:52] <fabbione> if a spec needs more discussion or one just go from draft to approved in one hour..
[09:52] <fabbione> etc.
[09:52] <tmarble> I'm going to target nightlife for tuesday (or thursday)
[09:52] <fabbione> you get the idea
[09:53] <fabbione> yeah let's meet up on monday and see how things are settled
[09:53] <tmarble> ok...
[09:53] <fabbione> i have no idea of a lot of details yet
[09:53] <fabbione> like what's up for dinner and so on
[09:53] <tmarble> hey, I thought you were supposed to know *everything* :)
[09:53] <fabbione> (if we need to find our own resturant or we are all at the hotel.. etc.)
[09:53] <tmarble> i'm at the same hotel BTW
[09:54] <tmarble> .. and I'm going to stay the weekend as I have biz the following week in Santa Clara
[09:54] <fabbione> yeah yeah.. my wife accuses me of the same, but then when i ask her to fix an IRQ problems, she believes i got some weird new sexual desease
[09:54] <fabbione> cool
[09:54] <tmarble> hehe
[09:54] <fabbione> we will stay the week after too
[09:54] <fabbione> but we have a fixed event on saturday
[09:54] <fabbione> and we need to change hotel
[09:54] <tmarble> you can do that
[09:55] <fabbione> yeps.. let see how things evolve
[09:55] <fabbione> i am all up for partying and driking
[09:55] <fabbione> drinking
[09:55] <fabbione> it helps to face the day after :P
[09:55] <tmarble> don't know how to localize "woot" in italian ;-)
[09:55] <fabbione> ehehe
[09:55] <tmarble> I have to step away from the computer for a bit (last minute packing and all...)
[09:56] <fabbione> i understand that
[09:56] <fabbione> take care
[09:56] <fabbione> i am off to watch a movie and then to bed
[09:56] <tmarble> I'll be around (on IRC) once I'm in San Diego
[09:56] <fabbione> ok
[09:56] <tmarble> buon cine!
[09:56] <fabbione> thanks
[09:56] <tmarble> ttyl!
[09:56] <fabbione> have a pleasent flight
[09:56] <fabbione> cya
[09:56] <tmarble> thanks


[11:45] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: What is virtualisation? The basics @ https://ubuntu.com//blog/what-is-virtualisation-the-basics
[21:01] -SwissBot:#ubuntu-news- ::Planet:: Alan Pope: Pro Breeze Air Fryer Review @ https://popey.com/blog/2021/02/pro-breeze-air-fryer-review/


[02:07] <Pharaoh_Atem> Hey everyone, if there's anyone interested in trying out snappy on Fedora, it'd be great if you could test out snapd
[02:07] <Pharaoh_Atem> more details here: https://forum.snapcraft.io/t/call-for-testing-snapd-2-23-on-fedora/127/6
[03:47] <olympionex> does anybody know if there has been any other progress on this snap download connection reset bug? https://bugs.launchpad.net/software-center-agent/+bug/1617765
[03:47] <mup> Bug #1617765: Connections reset when downloading snaps from CDN <Snapcraft:New> <Software Center Agent:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1617765>
[03:49] <olympionex> my experience is similar to the comments from others on that bug, it seems to affect snapcraft being run inside containers in particular
[03:50] <olympionex> have tried both building inside lxd and docker containers and the core snap fails to download the vast majority of the time
[05:04] <morphis_> mwhudson: ping
[05:04] <mup> PR snapd#3151 opened: Small adjustments for debian deb builds and packaging symlink for Debian Sid <Created by morphis> <https://github.com/snapcore/snapd/pull/3151>
[05:15] <mup> PR snapd#3151 closed: Small adjustments for debian deb builds and packaging symlink for Debian Sid <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3151>
[06:43] <zyga> o/
[06:44] <zyga> mvo: I will take a small detour to check something that gustavo requested (build system tweaks)
[06:44] <zyga> mvo: meanwhile can you do a review on updates to https://github.com/snapcore/snapd/pull/3145
[06:44] <mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
[06:44] <zyga> mvo: and let's plan how to change the plug names on core
[06:44] <zyga> mvo: (i.e. how to test that)
[06:45] <zyga> mvo: so that we don't cauese any regressions with this move
[06:45] <zyga> mvo: after the build system detour I will look at ensuring plug/slot name uniqueness validation
[06:45] <zyga> mvo: we have code for that but apparently it's not used or working
[06:45] <zyga> mvo: (I suspect the way implicit slots are added side-steps that)
[06:46] <mup> PR snapd#3152 opened: store: make hash error message more accurate <Created by mvo5> <https://github.com/snapcore/snapd/pull/3152>
[06:46] <mvo> zyga: ok
[06:57] <sabdfl> mcphail, we will figure out security in wayland
[06:57] <sabdfl> we need to do that anyway to get snaps to be amazing on a GNOME desktop
[06:58] <sabdfl> but we will keep Mir for IoT projects where security and simplicity are the main requirement
[06:58] <zyga> about wayland, I think we could use a test on fedora 25 + wayland to see how the interface shoud look like, I think it will be relatively straightforward
[06:59] <zyga> and try the same on ubuntu with apparmor to see what's to do with confinement
[06:59] <zyga> morphis was recently working on better X11 auth support for snaps
[06:59] <zyga> and that feels in line with similar work for wayland
[07:05] <zyga> mvo: ok, experiment done
[07:06] <zyga> now looking at plut/slot uniqueness again
[07:06] <mvo> thanks zyga
[07:07] <mvo> fgimenez: could you please have a look at 3148? it needs a second review and is pretty simple (I hope :)
[07:07] <Aimilius> Hello, I'm trying to update the snapd PKGBUILD on archlinux form 2.21 to 2.23.6. I removed the biuld patches that move the /snap dir to /var/lib/snapd/snap and updated the verison number. Everytime I would try to build snapd, I would get a linking error I cannot resolve. https://pastebin.com/YY3Pa3U8
[07:07] <fgimenez> mvo: sure on it
[07:08] <mvo> fgimenez: btw, is the re-exec spread-cron happy now? with the new snapd now being build?
[07:08] <zyga> Aimilius: hello! welcome :-) looking at the diff
[07:08] <zyga> er, log :)
[07:09] <zyga> Aimilius: aha, I think I know what's wrong
[07:09] <Aimilius> That was quick :)
[07:09] <zyga> Aimilius: can you do a master snapshot pleaes
[07:09] <zyga> Aimilius: I landed a PR that makes the build system more flexible
[07:09] <zyga> Aimilius: look at cmd/autogen.sh
[07:10] <fgimenez> mvo: nope it seems to have the same errors https://travis-ci.org/snapcore/spread-cron/builds/219549331
[07:10] <zyga> Aimilius: the problem is related to the set of libraries that are linked into snap-confine statically
[07:10] <zyga> Aimilius: in master each library (that can) has a knob to control if it is linked dynamically or statically
[07:10] <zyga> Aimilius: and the defaults are all dynamically as that is most easy to compile on all distributions
[07:10] <zyga> Aimilius: in 2.23.6 that wasn't the case
[07:11] <zyga> Aimilius: we are working on 2.24 now (not sure if it goes out today as we found some old bugs last night and want to fix them) but if you take master you will have a better chance at building it
[07:11] <Aimilius> zyga: I'm trying to rebuild now
[07:11] <zyga> Aimilius: excellent!
[07:12] <fgimenez> mvo: snapd 2.23.6+201704061805.git.996da23~ubuntu16.04.1 in that execution, is that ok?
[07:13] <mvo> fgimenez: that sounds good
[07:15] <Aimilius> Master builds fine, though some checks fail
[07:17] <Aimilius> I believe they are about apparmor confinement (test_restrictions test_complain_missed and test_unrestriced_missed, so I didn't excpect that would work
[07:17] <mvo> zyga: one quick question in your 3145 PR - if correct I can quickly push a branch for core
[07:18] <zyga> mvo: looking
[07:18] <Aimilius> Oh, they're about the linux-grsec restrictions
[07:18] <Aimilius> So everything works fine
[07:18] <zyga> mvo: yes, that's correct, also replied there
[07:18] <zyga> Aimilius: those are about seccomp I think
[07:18] <zyga> Aimilius: aha
[07:19] <zyga> Aimilius: interesting, feel free to report those on the forum, I'm sure the security team will be interested in them
[07:19] <Aimilius> zyga: I've got linux-grsec installed, that blocks unpriviliged dmesg access
[07:19] <zyga> aha
[07:19] <Aimilius> zyga: The test-suites try to access dmesg, so that doesn't work
[07:19] <mvo> zyga: ta, I will push a branch for core with that fix
[07:19] <zyga> mvo: OK
[07:20] <Aimilius> zyga: I think on plain linux (without grsecurity) it'll work fine
[07:21] <zyga> mvo: branch with plug/slot uniqueness enforcement on AddPlug/AddSlot is almost ready
[07:28] <mvo> zyga: it looks like snapcraft.yaml does not allow to use: "plugs: network-bind-hook: interface: network-bind" :/
[07:29] <mvo> zyga: the valications allows only flat strings arrays
[07:29] <mvo> zyga: whichi is very stange
[07:29] <kristbaum_> jdstrand I have had an "review pending" on my snap for five or six days. Is this normal, should I change something? I just wanted to try and upload an beta of mdt for testing.. it's namespace is mdt.kristbaum.
[07:30] <mvo> zyga: hm, looks like its just a bit of a strange syntax
[07:31] <zyga> mvo: no, you need to spell that differently
[07:31] <zyga> mvo: like this:
[07:31] <mvo> zyga: yeah, silly me
[07:31] <zyga> mvo: plugs:\n  network-bind-plug:\n    interface: network-bind
[07:33] <Aimilius> zyga: After a build on clean linux (without-grsecurity) the tests still fail. https://pastebin.com/WH1JBmMe
[07:34] <mup> PR core#32 opened: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
[07:35] <zyga> mvo: have a look at https://github.com/snapcore/snapd/pull/3153 please
[07:35] <mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
[07:36] <mup> PR snapd#3153 opened: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
[07:36] <zyga> Aimilius: hmm, can you please open a topic for that on https://forum.snapcraft.io/ - make sure to report the kernel version used
[07:36] <zyga> Aimilius: we may carry some seccomp fixes
[07:36] <zyga> Aimilius: not sure yet, we'll check it out
[07:36] <Aimilius> Ok, I'll open a topic
[07:36] <zyga> morphis: ^^ have a look please
[07:36] <Aimilius> zyga: uname -a Linux glorfindel 4.9.20-1-lts #1 SMP Fri Mar 31 15:23:31 CEST 2017 x86_64 GNU/Linux
[07:37] <zyga> mvo: note that this branch may be a flag day for core revert
[07:37] <zyga> mvo: as previous core won't validate and because the plugs are explicitly defined and slots are implicitly added later, may be dysfunctional (no network-bind slot, no core-support slot)
[07:38] <zyga> mvo: I can do a separate patch that fixes this by detecting it and changing the snap via implicit.go
[07:38] <zyga> mvo: let me know what you think
[07:39] <zyga> mvo: I also thing we could use a `snap --validate ./path/to/file.snap` command
[07:39] <zyga> (^ internal hidden thing maybe)
[07:40] <mvo> zyga: hm, if we need a flag day we need to think about this more carefully, maybe a HO in a bit for some brainstorm?
[07:41] <zyga> mvo: yes
[07:41] <zyga> mvo: I think we can avoid it
[07:41] <zyga> mvo: if we teach snapd to just rename those two plugs
[07:41] <zyga> mvo: (core:network-bind -> core:network-bind-plug) (same for core-support)
[07:41] <zyga> mvo: then no flag day needed
[07:41] <zyga> mvo: do you want to jump into a HO to discuss?
[07:43] <zyga> mvo: I'm in the standup HO if you want to
[07:44] <mvo> zyga: yes, one minute, just addressing some things
[07:44] <zyga> mvo: though sligthly complex, depending on where we do this exactly
[07:44] <mup> PR core#32 closed: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/32>
[07:52] <morphis> Aimilius, zyga: looking
[07:54] <Aimilius> I posted a topic on the forum here: https://forum.snapcraft.io/t/checks-fail-on-arch-linux/200/1
[07:58] <morphis> Aimilius: thanks, will respond there once I find something
[07:58] <Aimilius> morphis: thanks for your effort
[07:58] <morphis> np
[08:00] <morphis> Aimilius: you're not building on a kernel with AppArmor support, right?
[08:01] <Aimilius> zgrep APPARMOR /proc/config.gz # CONFIG_SECURITY_APPARMOR is not set
[08:01] <Aimilius> morphis: though I do use apparmor
[08:01] <morphis> Aimilius: ok, then you should compile snap-confine with --disable-apparmor
[08:01] <morphis> Aimilius: how when the kernel side support is disabled?
[08:02] <Aimilius> I normally run linux-grsecurity with apparmor compiled
[08:02] <Aimilius> But the tests didn't like the dmesg restrictions so I booted my normal kernel without grsecurity and apparmor
[08:03] <morphis> Aimilius: ok, when you don't have AppArmor in the kernel you should build with --disable-apparmor --disable-seccomp
[08:03] <Aimilius> morphis: I'm running this command to build snap-confine ./autogen.sh --prefix=/usr --disable-apparmor --enable-merged-usr
[08:03] <morphis> we don't have runtime detection (yet)
[08:03] <morphis> please add --disable-seccomp too
[08:03] <zyga> morphis: without apparmor the seccomp tests wont run either, I think the logic there assumes both
[08:04] <Aimilius> morphis: does snap-confine depend on out-of-tree seccomp patches
[08:04] <Aimilius> morphis: because the arch kernel does support seccomp
[08:04] <Aimilius> morphis; and I have libseccomp installed
[08:04] <morphis> Aimilius: the problem is that only using seccomp will unhide a few problems nobody didn't look into yet
[08:04] <morphis> safest is to disable both right now
[08:05] <Aimilius> Ok, rebuilding
[08:06] <Aimilius> morphis: if I add --disable-seccomp, the checks still fail
[08:06] <morphis> Aimilius: ok
[08:06] <morphis> Aimilius: can you paste the log output for that?
[08:06] <Aimilius> morphis: sure
[08:07] <mcphail> sabdfl: thanks. Sorry Plan A didn't work out. Loved what you were trying to do
[08:07] <Aimilius> morphis: https://pastebin.com/v2sh2f7Z
[08:10] <morphis> Aimilius: will look in a bit
[08:11] <Aimilius> morphis: I'll have to go leave soon
[08:11] <morphis> Aimilius: ok
[08:11] <Aimilius> But I'll look at the forum this afternoon
[08:11] <morphis> Aimilius: I will see that I get an Arch setup and try to reproduce
[08:12] <Aimilius> morphis: Shall I post my PKGBUILD?
[08:12] <morphis> Aimilius: please!
[08:13] <Aimilius> morphis: https://pastebin.com/qRRNSYmz
[08:13] <Aimilius> I use a ugly hack to install the systemd unit files
[08:13] <morphis> Aimilius: ok, we have something better for this in 2.24
[08:13] <Aimilius> morphis: But with the --nocheck option, it appears to install
[08:13] <Aimilius> morphis: great to hear
[08:14] <morphis> Aimilius: something like make -C data/systemd DESTDIR=... install will do the job then
[08:14] <Aimilius> morphis: that was what I did
[08:14] <morphis> ah
[08:14] <Aimilius> morphis: with SYSTEMDUNITDIR=/usr/lib/systemd/system, because of the usr merge
[08:14] <morphis> ok, that is then what you should do
[08:15] <Aimilius> But it felt like I shouldn't use a Makefile there
[08:18] <zyga> mvo: have a look a tthis please https://github.com/snapcore/snapd/compare/master...zyga:rename-clashing-core-plugs?expand=1
[08:18] <zyga> mvo: that's what I was thinking about (tests WIP)
[08:18] <zyga> mvo: essentially this is the essence: https://github.com/snapcore/snapd/commit/59ae873d82883f8887ac7c55bead62e60ab749f6
[08:18] <zyga> (the last two patches are new in this brancH)
[08:34] <Kristbaum__> Is somebody here that is responsible for manual reviews in the snap store?
[08:39] <zyga> Kristbaum__: I think so
[08:40] <zyga> Kristbaum__: I think you may have better luck on forum.snapcraft.io, using the "store" category
[08:40] <zyga> Kristbaum__: as they are in different timezones
[08:40] <zyga> Kristbaum__: and you may get more organized replies there
[08:43] <Kristbaum__> zygra okay will try that
[08:45] <zyga> Kristbaum__: thanks!
[09:03] <zyga> mvo: I'm adding tests to RenamePlug
[09:09] <zyga> mvo: adding tests to ifacestate
[09:11] <morphis> actually running snapd spread tests in QEMU doesn't look much reliable these days ..
[09:12] <zyga> morphis: why? what are you getting?
[09:12] <zyga> morphis: I sometimes get startup errors but if it runs, it is quite reliable
[09:12] <morphis> timeouts for apt-get
[09:12] <morphis> ala "running late"
[09:12] <morphis> sometimes network connectivity dies
[09:12] <morphis> but could be that I have a debian container I am trying to run the tests in
[09:12] <zyga> morphis: late is normal
[09:12] <zyga> morphis: aha, I dind't try it that way
[09:13] <morphis> zyga: should the lxd backend work these days?
[09:13] <Chipaca> morphis— apt update/upgrade the base image to keep the time in check
[09:13] <Chipaca> otherwise each test run does that, and it's hella slow :-)
[09:14] <morphis> Chipaca: yeah doing that right now
[09:14] <Chipaca> (that's a technical term)
[09:14] <pstolowski> mvo, #3070 failed again, the failures seem to be unrelated to the branch, i.e. snap confine test failures, gccgo failures
[09:14] <Chipaca> morphis— niemeyer has a cron job for this, but not sure if it's reusable for qemu
[09:14] <morphis> Chipaca: let me check
[09:15] <zyga> morphis: I don't know
[09:15] <zyga> morphis: we don't exercise it I think
[09:18] <morphis> zyga: ok, worth a try later
[09:18] <morphis> zyga: but I must say using the debian openstack images is working like a charm so far
[09:24] <zyga> morphis: nice!
[09:24] <zyga> morphis: can you add instructions on how to get them to spread-qemu-images please?
[09:24] <morphis> zyga: had to modify the adt-* script a bit but will send a PR for your spread images repo later today or on monday
[09:27] <morphis> zyga: you had a chance to test snapd on fedora yesterday again?
[09:29] <morphis> Son_Goku: any more testing from your side happend? I've added +1 to all three bodhi requests now
[09:30] <zyga> morphis: nice
[09:30] <zyga> morphis: no, I didn't we found a new set of bugs that delayed 2.24 release
[09:30] <zyga> morphis: I'm still working on fixing them
[09:30] <morphis> ok
[09:30] <morphis> zyga: what kind of bugs?
[09:32] <zyga> morphis: https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/7
[09:34] <zyga> mvo: ok, I'm adding one more correction, I will migrate connection state as well
[09:34] <zyga> mvo: that is done, just adding tests
[09:36] <morphis> zyga: I see
[09:38] <mup> PR snapd#3148 closed: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3148>
[09:41] <zyga> mvo: ok ready
[09:42] <zyga> mvo: let me open a PR
[09:48] <mvo> pstolowski: some of the test failures in 3070 look real
[09:48] <mvo> zyga: ok
[09:50] <mup> PR snapd#3154 opened: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[09:50] <zyga> Chipaca: hey, mvo is off now
[09:50] <zyga> Chipaca: I need a hand with critical 2.24 reviews
[09:51] <Chipaca> zyga— shoot
[09:51] <Chipaca> zyga— or i can look myself :-)
[09:51] <Chipaca> on it
[09:52] <zyga> Chipaca: https://github.com/snapcore/snapd/milestone/6
[09:52] <zyga> Chipaca: there are two approaches used
[09:52] <zyga> Chipaca: (and both should land)
[09:52] <zyga> Chipaca: I added one more branch to 2.24
[09:54] <zyga> Chipaca: - rename everything when starting so even old core snap is correct
[09:54] <Chipaca> why is our test suite brittle all of a sudden :-(
[09:54] <zyga> Chipaca: this is done in https://github.com/snapcore/snapd/pull/3154
[09:54] <mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[09:55] <zyga> Chipaca: - validate everything so it doesn't happen again
[09:55] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/3153
[09:55] <mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
[09:55] <zyga> Chipaca: and lastly because we found this by fixing a bug in core transition
[09:55] <Chipaca> snapd#3145 needs niemeyer to re-review i guess
[09:55] <mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
[09:56] <zyga> Chipaca: this branch fixes the damage done there https://github.com/snapcore/snapd/pull/3145/files
[09:56] <Chipaca> (as he marked it as Changes Needed)
[09:57] <zyga> yep
[09:57] <zyga> that's fine
[09:57] <zyga> I want to go through the first round on the two new PRs
[10:03] <Chipaca> zyga— wouldn't it make sense, in snapd#3154, for you to also test RenamePlug for a case where a plug and slot have the same name?
[10:03] <mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[10:03] <tvoss> pedronis: hey there, I was looking into replacing the exec'ing of ssh-keygen with using openssl via CGO as in: http://pastebin.ubuntu.com/24333148/
[10:03] <zyga> Chipaca: sure, can do
[10:03]  * zyga does
[10:03] <tvoss> pedronis: do you have any guidelines on how to use CGo? Like place actual implementation into .c file or some such?
[10:06] <zyga> tvoss: look at...
[10:06] <zyga> tvoss: https://github.com/snapcore/snapd/pull/3095
[10:06] <mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
[10:06] <zyga> Chipaca: ha, I cannot
[10:06] <zyga> Chipaca: it's validated now
[10:07] <zyga> Chipaca: http://pastebin.ubuntu.com/24333233/
[10:09] <tvoss> zyga: ack
[10:09] <Chipaca> zyga— state twiddling direclty?
[10:10] <Chipaca> zyga— or make a for-testing way of overriding the validation
[10:10] <Chipaca> because clearly you can be in that state
[10:10] <Chipaca> so we need to test it
[10:11] <zyga> Chipaca: I'll think of something
[10:11] <zyga> Chipaca: good point about being able to be in that state
[10:11] <Chipaca> zyga— I'm now wanting to check it even more, to make sure we don't break people that are in that state already
[10:12] <zyga> Chipaca: look at the other branches and suggest ideas
[10:13] <zyga> Chipaca: note that it is not strictly speaking "hurtful" to have clashing names
[10:13] <zyga> Chipaca: but we want to get away from that
[10:13] <pedronis> I think it's a matter of order of things in the other branch fixing this
[10:13] <pedronis> but we need to be able to load the state to fix it
[10:13] <Chipaca> zyga— idea: make space probes look futuristic to trick aliens into thinking we're more advanced than we are
[10:13] <zyga> pedronis: state is not validated there (just connections are changed)
[10:14] <zyga> pedronis: and interfaces.ConnRef has no validation
[10:14] <Chipaca> zyga— or did you mean ideas that were relevant to the branch
[10:14] <pedronis> don't we do a big add all the snaps thing
[10:14] <mvo> Chipaca: re brittle> https://forum.snapcraft.io/t/hashsum-failures-during-tests/198 is what I see in a bunch of them
[10:14] <pedronis> zyga: initializes does addSnaps, no?
[10:15] <zyga> pedronis: aha, good point
[10:16] <pedronis> I don't see the aha there but yes, bit of a chicken and egg problem
[10:16] <zyga> Chipaca: ok, I have something for that now
[10:16] <zyga> pedronis: well, if we load core snap and validate it
[10:16] <Chipaca> mvo— D:
[10:16] <zyga> pedronis: it won't reach that point
[10:16] <pedronis> so it explodes
[10:16] <pedronis> is that aha?
[10:17]  * pedronis has probably no sense of humur today
[10:17] <zyga> Chipaca: have a look, just pushed
[10:17]  * Chipaca hugs pedronis
[10:17] <pedronis> anyway I agree with Gustavo's yesterday point that we need to tread carefully through these fixes
[10:17] <zyga> pedronis: yes, I totally agree
[10:18] <pedronis> will one of our spread tests exercise thiss? like the upgrade one?
[10:18] <zyga> pedronis: spread tests do exercise this already
[10:19] <zyga> pedronis: well, not directly this
[10:19]  * pedronis anyway, lunch
[10:19] <zyga> pedronis: but the branch that adds validation is all read
[10:19] <zyga> red*
[10:19] <zyga> pedronis: because now core doesn't validate anymore
[10:20] <Chipaca> zyga— dude, stop with the Not(IsNIl) :-)
[10:21] <pshod> any way to create env variables or signals that can be accessed by two different processes inside a snap env?
[10:21] <zyga> Chipaca: how should I do it?
[10:21] <Chipaca> zyga— NotNil
[10:22] <Chipaca> zyga— compare the failing output and you'll see what i mean
[10:22] <zyga> Chipaca: oooh, didn't know about it :)
[10:22] <zyga> Chipaca: ack, will do
[10:22] <pshod> my snap exposes a noejs app which spawns a sh script which fires a banary
[10:22] <pshod> binary
[10:23] <Chipaca> pshod— one easy way is to use the filesystem
[10:23] <Chipaca> pshod— that includes, for example, a unix socket
[10:23] <pshod> i am notifying the event by writing into a file
[10:23] <pshod> and then if the file has a particular content
[10:24] <pshod> i close my watch in the node app
[10:24] <pshod> chipaca : the sh script should write unto a socket and the node app listens on the socket?
[10:25] <pshod> zyga: help help help!
[10:25] <Chipaca> pshod— it depends on what you need to do, etc etc
[10:25] <Chipaca> pshod— please tell us more
[10:25] <pshod> ill try to be concise
[10:26] <zyga> pshod: so
[10:26] <zyga> pshod: if you set environment from a running process
[10:26] <Chipaca> pstolowski— “- Download snap "core" (1577) from channel "stable" (unexpected EOF)” <- just got that :-(
[10:26] <pshod> snap exposes a node app -> spawns a sh script that fires a binary->binary reads data from a sensor and writes into a file in SNAP_COMMON->node app reads the file and posts to a REST server
[10:26] <zyga> pshod: you cannot just "see" that easily in other processes without looking at /proc
[10:27] <zyga> pshod: not sure what you meant by a signal
[10:27] <zyga> pshod: tell me what you want to achieve
[10:27] <Chipaca> pshod— with you so far
[10:27] <zyga> pshod: (not how)
[10:27] <zyga> pshod: and we'll recommend osmething
[10:27] <pstolowski> Chipaca, is this with current code, or latest release?
[10:27] <Chipaca> pstolowski— https://travis-ci.org/snapcore/snapd/builds/219327815
[10:28] <pshod> no the node app is configurable..we pass the number of tmes the binary writes into the fuke
[10:28] <pshod> file*
[10:28] <Chipaca> pstolowski— upgrade/basic failed with that
[10:28] <pshod> now what I have done is, i modifies the sensor binary so that after writing the said "n" observations into the file
[10:28] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/3154#discussion_r110359632 (updated and added tests)
[10:28] <mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
[10:28] <pshod> overwriting*
[10:28] <pshod> it writes "Closing Session"
[10:29] <pshod> so when i read the file from SNAP_COMMON
[10:29] <pshod> and see it's contents as "Clossing Session" I remove the watch from SNAP_COMMON and my node app exits gracefully
[10:29] <pstolowski> Chipaca, uhm. not good. would be great to find out how to provoke 'unexpected eof' in the test. what I did recently was a test with closing client connections, and that triggers normal EOF
[10:30] <pshod> people dont like this design and I am not pretty confident about it too
[10:30] <pshod> :|
[10:30] <Chipaca> pstolowski— send a RST
[10:30] <zyga> pshod: today I'm focusing on 2.24 release and I don't have much time to help
[10:30] <Chipaca> pshod— ah, so this is what you're doing now and you need to improve it?
[10:30] <zyga> pshod: maybe ask on the forum and we'll get to that
[10:31] <Chipaca> pshod— yeah, maybe it's better as a forum question, rather long-winded for here
[10:31] <pshod> zyga : hey thank you!
[10:31] <Chipaca> pshod— nothing wrong with the file-based approach as long as you're using locking appropriately
[10:31] <Chipaca> pshod— but there are other ways, sure
[10:31] <pshod> zyga: have gotten much help from you in the past :D
[10:32] <zyga> pshod: I'll gladly help next week but I need to focus on fixing something we just found out that is affecting core
[10:32] <zyga> pshod: namely https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/6
[10:32] <Chipaca> pstolowski— no i don't know *how* to send a RST, i know a RST is the usual cause for that unexpected eof
[10:32] <zyga> pshod: we won't release today (Friday = bad idea) but I want it to be ready
[10:32] <pshod> chipaca : locking is done properly, I suggested we just update a variable which gets updated when API for posting is called
[10:32] <zyga> pstolowski: network throttling things sent RSTs to kill connections
[10:32] <pstolowski> Chipaca, exactly... i'll look into that later, thanks. in the meantime - E_TOOMANYISSUES_ATM
[10:32] <pshod> but that was rejected too.
[10:33] <pshod> zyga : duplicate plug names
[10:33] <Chipaca> pshod— ok, open a forum thread, write everything out there please
[10:33] <pshod> zyga: sounds too much of fun :P
[10:33] <pshod> chipaca : on it
[10:34] <Chipaca> pshod— what you want to achieve, what you are doing now, why it was rejected/requested to be improved, what other things were proposed but also rejected
[10:34] <zyga> pedronis, Chipaca, pstolowski, mvo: I'm looking for proposals on how to fix the chicken/egg problem on core's snap.yaml: we need to load an invalid file to fix it
[10:34] <Chipaca> pshod— the 'what you want to achieve' there is missing in what you've written so far, afaict
[10:34] <zyga> my naive idea is to add a way to load snap.Info that's invalid
[10:34] <zyga> use that on the core snap only
[10:34] <zyga> and apply the fix right there
[10:34] <zyga> (the fix is currently in interface manager but it should move to snap manager)
[10:35] <mvo> zyga: how about a forum.snapcraft.io topic? to have an archived discussion?
[10:35] <zyga> mvo: +1
[10:35] <pshod> chipaca : will do it like that
[10:36] <mup> PR core#32 opened: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
[10:38] <zyga> commented on the forum about it
[10:38] <zyga> https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/9?u=zyga
[10:39] <pshod> chipaca : wont i be able to register using my company id?
[10:40] <Chipaca> pshod— I don't know. It's not (yet) tied into login.ubuntu.com, if that is what you mean
[10:50] <Chipaca> zyga— what calls snap.Validate on startup?
[10:56] <mikeb_> Hi, I need some help with snapcraft.yaml syntax.  I'm trying to implement a command wrapper to start my apps.  I'm trying to pass a command and its arguments to the wrapper, but I can't get the syntax correct.  For example -  command: usr/bin/mywrapper --wrapper-arg1 --wrapper-arg2  --exec '$SNAP/usr/bin/cmd --cmd-arg1 --cmd-arg2'.  Snapd parses cmd-arg1 and cmd-arg2 as arguments to usr/bin/mywrapper.  What is the syntax to put them al
[10:56] <mikeb_> What is the syntax to put them all in the string as the --exec argument?
[10:57] <zyga> Chipaca: when you load the state, I think that's in snapmgr somewhere
[10:57] <zyga> Chipaca: look at the interface manager, it asks for all the snaps and adds active ones to the repository
[10:57] <zyga> Chipaca: with the validation code in place we will naver reach that spot
[10:57] <zyga> Chipaca: as we will crash and burn on invalid core
[10:57] <Chipaca> mikeb_— can you share the yaml in a pastebin?
[10:58] <mikeb_> Chipaca: sure
[10:59] <Chipaca> zyga— I see interface/repo.go:73 calling ValidateName, but no Validate call
[10:59] <Chipaca> interfaces*
[10:59] <pshod> chipaca : i should tag my entry as "other"?
[11:00] <mikeb_> https://pastebin.com/GhCBe4Gd
[11:01] <Chipaca> mikeb_— ok, that seems alright. Can you show me the .service file that gets generated?
[11:03] <mikeb_> Chpaca: is the generate service file located in the prime area? Or is it generated at snap install time?
[11:05] <Chipaca> mikeb_— it'll be in /etc/systemd/system
[11:05] <Chipaca> mikeb_— called something obvious
[11:05] <Chipaca> mikeb_— ah, at install itme
[11:05] <Chipaca> time*
[11:06] <mikeb_> Chipaca: my install is failing, so I can't get to it.
[11:07] <Chipaca> ah
[11:07] <Chipaca> mikeb_— how is it failing?
[11:07] <mikeb_> Chpaca: https://pastebin.com/4Ufw8WcE
[11:10] <Chipaca> mikeb_— that happens on 'snap install', i take it
[11:10] <Chipaca> or snap try
[11:10] <mikeb_> Chipaca: snap install
[11:11] <mikeb_> Chipaca: on a Ubuntu-core system
[11:11] <Chipaca> mikeb_— so, what's *probably* happening is that the quoting there reaches the .service file intact, and then systemd reads it wrong
[11:11] <Chipaca> I need to test this
[11:11] <Chipaca> give me a bit
[11:11] <Chipaca> (it's a bug at our end, but there's a workaround if this is the case)
[11:11] <mikeb_> Chipaca: okay.  Thanks!
[11:13]  * zyga will work on fixing the migration situation after lunch
[11:13] <zyga> ttyl!
[11:14] <pedronis> zyga: rememeber that we setup-profiles twice for core
[11:14] <pedronis> the first time with old snapd code
[11:14] <pedronis> the 2nd with new snapd code
[11:14] <pedronis> and that one has passed managers init at that point
[11:14] <zyga> pedronis: good point
[11:14] <zyga> pedronis: thank you!
[11:15] <pedronis> so need to think a bit exactly what sees what here
[11:15] <zyga> pedronis: let's discuss this at the call, I think (all) of PRs are unlikely to land today
[11:15] <Chipaca> mikeb_— huh, that's strange. When trying to do this myself I get an error.
[11:15] <Chipaca> mikeb_— in that the command can't contain quotes
[11:16] <Chipaca> mikeb_— so maybe you're in an older version that didn't validate this? i'd say move the long command into a shell script and use that as the command in the yaml
[11:16] <mikeb_> Chipaca: FYI context - I have a snap that is made up of many .deb packages all with services to start up.  I'm trying to come up with a wrapper that will deal with service before/after/wants/requires/etc as well as the various preinst/postinst/prerm/postrm/etc
[11:18] <pedronis> zyga: I mean it might turn out that is less to do that we think,  (some fixes don't make sense), though there's the no reexec case as well to keep in mind, we don't reexec everywhere yet, do we?
[11:18] <mikeb_> Chipaca: I'm running snapcraft 2.28
[11:18] <Chipaca> mikeb_— sound slike fun
[11:19] <Chipaca> mikeb_— I get this: error: cannot read snap info for /home/john/canonical/snappy/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-service: app description field 'command' contains illegal "bin/start foo bar \"baz quux\"" (legal: '^[A-Za-z0-9/. _#:-]*$')
[11:20] <mikeb_> Chipaca:  The upstream packages are still changing a lot.  It's more fun to try to manually translate all the service and inst files to snapcraft apps:
[11:21] <pedronis> Chipaca: seems indeed that we don't support quotes in commands
[11:21] <pedronis> (never did I think,  maybe we need to ? )
[11:21] <mikeb_> Chipaca: That's unfortunate...
[11:23] <Chipaca> mikeb_— however, note you can set a per-app 'environment' entry that does have quotes
[11:24] <pedronis> Chipaca: not sure though that env var in a command do the right thing
[11:25] <Chipaca> pedronis— they get set in the environ of the service
[11:25] <mikeb_> Chipaca: I hadn't thought to escape my quotes in the yaml file.  That actually seems to be working... almost.  Give me a few to play around a bit more.
[11:25] <pedronis> though you can always use a wrapper
[11:25] <Chipaca> Apr 07 12:25:33 fogey snap[17032]: FOO=$'there once was a man from nantucket\nwho was very bad at limericks\n'
[11:26] <Chipaca> ^ that's from
[11:26] <Chipaca>   environment:
[11:26] <Chipaca>     FOO: |
[11:26] <Chipaca>       there once was a man from nantucket
[11:26] <Chipaca>       who was very bad at limericks
[11:26] <Chipaca> makes it all the way through, newlines and all
[11:27] <pedronis> Chipaca: sorry, what I was saying is that I don't know if:  command: bin/x $FOO   works
[11:27] <pedronis> (I suspect not, might be wrong)
[11:27] <Chipaca> pedronis— no because $ is not in [A-Za-z0-9/. _#:-]
[11:27] <pedronis> even if it were
[11:28] <Chipaca> mikeb_— what version of snapd are you on? (output of “snap version”)
[11:29] <Chipaca> pedronis— and, no, environment key is applied by snap run, not by systemd
[11:30] <pedronis> Chipaca: I don't I understand your suggestion, I mean, it's not a direct transformation
[11:30] <pedronis> Chipaca: cannot tunr    bin/x "a b"   into   FOO="a b"  bin/x $FOO
[11:30] <Chipaca> pedronis— mikeb_ is writing a wrapper for a bunch of services
[11:31] <Chipaca> pedronis— for a single snap to handle ordering of services itself
[11:31] <mikeb_> Chipaca: snapd 2.23.6
[11:31] <Chipaca> as we don't expose ordering
[11:31] <mikeb_> among other things...
[11:31] <pedronis> Chipaca: I think I should give up helping, I don't have context
[11:31] <Chipaca> pedronis— as such, he's currently taking a bunch of options to his script from the commandline itself
[11:32] <Chipaca> but we dont' support that (and apparently we've introduced a breaking change around this between 2.23.6 and now? i need to dig a little)
[11:32] <pedronis> ah, ok, I though it was tryign to call directly something not under his control
[11:32] <Chipaca> pedronis— but instead they *could* take it from environ
[11:32] <pedronis> yes
[11:32] <Chipaca> it's probably not as nice
[11:33] <Chipaca> k? k.
[11:33] <Chipaca> :-)
[11:33] <pedronis> working beats nice, I suppose
[11:33] <Chipaca> mikeb_— I'm on 2.23.6 as well. something doesn't add up :-/
[11:33] <Chipaca> ah
[11:33] <pedronis> seems there's confusion around env from yaml working or not
[11:33] <Chipaca> mikeb_— what's in your *snap.yaml*?
[11:33] <Chipaca> mikeb_— in prime/meta/snap.yaml
[11:34] <pedronis> I have seen an open topic about that
[11:34] <Chipaca> mup— poke kyrofa
[11:34] <Chipaca> ah, no ldap
[11:34] <pedronis> https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/3
[11:35] <Chipaca> it's 4am for kyle, i'll ask later
[11:35] <pedronis> it actually pings you at the end
[11:35] <pedronis> that topic
[11:35] <Chipaca> me? nevah!
[11:35] <pedronis> fwiw
[11:35]  * Chipaca looks
[11:35] <pedronis> well Gustavo does
[11:35] <mikeb_> Chipaca: With the escaped quotes, it seems to be working as I intended.  I'm trying to fix some bugs in my test code right now, but the '--cmd' seems to be getting through now.
[11:36] <Chipaca> mikeb_— i suspect snapcraft might be helping, hence me asking for your snap.yaml :-)
[11:41] <mikeb_> Chipaca: Sorry, had to deal with an interrupt.  snap.yaml on the way.
[11:41] <Chipaca> mikeb_— no worries
[11:41] <Chipaca> speaking of interrupts, lunch would be nice sometime
[11:41] <Son_Goku> anyone have any idea why I'm getting this error?
[11:41] <Son_Goku> - Download snap "core" (1577) from channel "stable" (sha3-384 mismatch after patching "core": got 3ca758bb05ff3a422fffa2c02018aaf63909417180b3e902eaddcf0cbc4d4c317bfe26ac5c39567bc69abb94ece0d1e8 but expected cbdff81206101ef7063f2f91a4c3f36e1ad946fe8a809eca4c21fa5335968dfc0c696e5f364cbc9a4c83590aceb3fc15)
[11:41] <Chipaca> Son_Goku— in tests, or in real life?
[11:41] <zyga> re
[11:41] <Son_Goku> real life
[11:41] <Chipaca> whee
[11:42] <Son_Goku> I'm trying to do "sudo snap install hello-world"
[11:42] <Son_Goku> snapd 2.23.6 + Fedora 25
[11:42] <Chipaca> Son_Goku— you crazy bleeding-edger you
[11:42] <zyga> pedronis: we don't reexec everywhere (reading backlog and responding)
[11:42] <Chipaca> :-)
[11:42] <Chipaca> Son_Goku— can you pastebin `journalctl -u snapd`? the bit around the install in particular, not the whole thing :-)
[11:43] <zyga> Son_Goku: I think there's some issue in deltas
[11:43] <zyga> Son_Goku: I saw michael do some changes there today
[11:43] <Chipaca> zyga— michael's change is around the error, which always mentions deltas even if it's not a delta
[11:43] <zyga> Son_Goku: hey man :) nice to see you today
[11:43] <zyga> hah
[11:44] <zyga> I mean, "aha"
[11:44] <Chipaca> zyga— you can mean both
[11:44] <mikeb_> Chipaca:  https://pastebin.com/fc9jN3wd - I added prime/command-test-daemonize-notify.wrapper to the end of the paste.
[11:44] <Chipaca> riiight
[11:44] <zyga> ok, I'll get back to the key issue at hand
[11:44] <Chipaca> mikeb_— so snapcraft is wrapping things for you
[11:44] <Chipaca> mikeb_— that's why you're not seeing the error about using quotes in there :-)
[11:44] <Chipaca> but it's doing a bad job of it
[11:45] <Chipaca> :-)
[11:45] <Son_Goku> Chipaca, zyga: https://paste.fedoraproject.org/paste/hzxtldZltZyI94LRqVeKr15M1UNdIGYhyRLivL9gydE=
[11:45] <mikeb_> Chipaca: yes, wrapper for a wrapper for a command.  Fun.  Doesn't snapcraft always generate wrappers for commands?
[11:46] <Chipaca> mikeb_— probably, yes
[11:46] <zyga> mikeb_: there's a plan to stop that eventually
[11:47] <morphis> Son_Goku: doesn't look good but maybe because of a network error?
[11:47] <morphis> didn't had problems here switching between different core's
[11:47]  * Son_Goku shrugs
[11:47] <zyga> how do we compute the has? internally?
[11:48] <zyga> maybe bug in golang that's fixed in ubuntu or maybe different (subtly) output in an external program?
[11:48] <zyga> maybe delta?
[11:48] <Son_Goku> well, we're on golang 1.7.5 on Fedora 25
[11:49] <zyga> Son_Goku: the reverse may be true :-)
[11:49] <Son_Goku> it could also just be this VM, but I doubt it
[11:50] <Son_Goku> well fuck it
[11:50] <Son_Goku> a reboot fixed everything
[11:50]  * Son_Goku shrugs
[11:51] <Son_Goku> Chipaca: lol i dunno anymore
[11:51] <Son_Goku> maybe my VM was screwy?
[11:51] <morphis> possible
[11:51] <morphis> seeing some network issues from time to time here
[11:51] <Son_Goku> I could have just been lucky, I guess
[11:52] <Chipaca> fwiw
[11:52] <Chipaca> we're getting that error in tests
[11:52] <Chipaca> occasionally
[11:52] <Chipaca> i suspect the cdn
[11:52] <Son_Goku> huh
[11:52] <Son_Goku> maybe related, then
[11:52] <Son_Goku> well, that would explain corruption in the core snap download
[11:52] <Chipaca> mhmm
[11:52] <Son_Goku> and when I tried to fetch it myself, nothing happened :?
[11:53] <Son_Goku> it timed out
[11:53] <Chipaca> encouraging
[11:53] <Son_Goku> well, it worked this time
[11:53] <davidcalle> Can someone on 16.04 check if snap:// links work? http://www.omgubuntu.co.uk/2017/02/snap-url-support-coming-ubuntu-software-app-plus-love-news
[11:53] <Son_Goku> so at least it passed the smell test
[11:53] <Chipaca> Son_Goku— that does not make it better (in fact, the opposite :) )
[11:54] <Son_Goku> Chipaca: I know :(
[11:54] <Son_Goku> but I'm trying to make sure I didn't screw up everything with my Fedora packaging changes
[11:54] <Son_Goku> ;)
[11:54] <Chipaca> davidcalle— I'm on 16.04, clicked the snap link, it went to xdg-open, which laughed a very deep laugh
[11:55] <Son_Goku> haha
[11:55] <Son_Goku> actually, this is interesting
[11:55] <Chipaca> davidcalle— actually it returned 0, no error output, so it seems to *think* it worked
[11:55] <Son_Goku> snapd forced my VM's resolution down to 800x600
[11:55] <Son_Goku> wtf
[11:55] <davidcalle> Chipaca, ahaha, ok, no software center popping up?
[11:55] <Chipaca> davidcalle— correct
[11:56] <Chipaca> Son_Goku— you need to scale the qubit's strangeness down a notch
[11:56] <Chipaca> damn quantum-entangled snapd
[11:56] <morphis> Son_Goku: really?
[11:57] <davidcalle> Chipaca: thanks for the gunea pigging :)
[11:57] <Son_Goku> morphis: yes really
[11:57] <morphis> Son_Goku: do you have the vbox drivers installed?
[11:57] <Son_Goku> it happened the moment the core snap finished installing
[11:57] <morphis> Son_Goku: anything in dmesg/journal?
[11:57] <Son_Goku> no, this is VMware Fusion, so open-vm-tools and regular vmware drivers are used
[11:58] <zyga> Son_Goku: log out and log in without wayland
[11:58] <Son_Goku> I'm using Plasma, with Xorg
[11:59] <zyga> Son_Goku: hmm, then no idea
[11:59] <zyga> Son_Goku: snapd doesn't touch anything X related
[11:59] <zyga> Son_Goku: does it work if you remove snapd and reboot?
[11:59] <Son_Goku> well, everything is fine *after* installing the core snap
[12:00] <Son_Goku> it's just the act of installing the core snap seems to snap the resolution down to what it is when sddm is launched
[12:00] <Chipaca> davidcalle— oink oink (or, rather, squee squee)
[12:00] <Son_Goku> sddm is Wayland, I think
[12:00] <zyga> sddm?
[12:00] <Son_Goku> sddm, Simple Desktop Display Manager
[12:00] <Son_Goku> from the Hawaii OS (now Liri OS) guys
[12:00] <Son_Goku> it replaced kdm for Plasma 5
[12:01]  * zyga says "maaagic"
[12:01] <zyga> no idea,
[12:02] <morphis> Son_Goku: btw. can you check with a gui snap too on KDE
[12:02] <Son_Goku> lol i dunno
[12:02] <morphis> Son_Goku: like krita
[12:02] <Son_Goku> morphis: I'm playing ohmygiraffe :)
[12:03] <morphis> Son_Goku: good, so we're not affected by https://bugzilla.opensuse.org/show_bug.cgi?id=1031501#c3
[12:04] <Son_Goku> we probably will be once Fedora 25 transitions to Plasma 5.9
[12:05] <Son_Goku> morphis: Plasma 5.9 tightens the security a little bit
[12:05] <Son_Goku> I'm still on Plasma 5.8
[12:06] <Son_Goku> it'll probably fail on Fedora 26 KDE, you should try
[12:06] <morphis> Son_Goku: yeah maybe
[12:06] <morphis> Son_Goku: if it does we have a fix for that upcoming
[12:06] <morphis> not 2.24 bur 2.25 maybe
[12:06] <morphis> jdstrand: ping
[12:08] <Son_Goku> morphis, zyga: anyway, I can't give karma for the snapd updates, so I need you guys to do so and find someone get it up to +3 across the board
[12:09] <Son_Goku> and it has to be someone with a FAS account, because anonymous karma doesn't count for karma :/
[12:09] <morphis> Son_Goku: yes, I gave +1 already
[12:09] <morphis> Son_Goku: you think you can find someone
[12:09] <Son_Goku> I'm going to try
[12:11] <Son_Goku> morphis: zyga's karma was zeroed out, so he has to do it again
[12:14] <morphis> yes
[12:14] <morphis> Son_Goku: I've asked him already but he seems to be under time pressure to get things fixed for 2.24
[12:14] <zyga> yes, sorry
[12:14] <morphis> np
[12:14] <Son_Goku> it only takes a couple of minutes to hit +1s for everything, since he's already tested it :)
[12:14] <zyga> the clashing names need to be fixed really urgently
[12:14] <zyga> Son_Goku: I didn't really test the new packages
[12:15] <zyga> Son_Goku: I'd like to really test them before +1
[12:15] <zyga> Son_Goku: (I mean after the next upload)
[12:15] <Son_Goku> the only change is that I added the scriptlet to autostart them
[12:15] <zyga> ah
[12:15] <Son_Goku> well, and I bumped to snapd-glib 1.10, but we can't really test that with anything
[12:15] <zyga> well, I'll +1 after testing it at least once still :)
[12:15] <zyga> that's the point of the process
[12:15] <Son_Goku> right
[12:16] <Son_Goku> I just bundled that update with it because I want the buildsystem error emails to go away...
[12:16] <Son_Goku> err, dependency error emails
[12:16] <zyga> (not talking about glib specifically)
[12:17] <Son_Goku> right
[12:18] <Son_Goku> well, the sooner snapd and snapd-glib hit stable, the sooner that gnome-software can move to using it entirely
[12:18] <Son_Goku> (snapd-glib, I mean)
[12:18] <Son_Goku> because then hughsie will be able to test against it
[12:22] <zyga> pedronis: looking at snap/*.go, we don't seem to validate loaded yaml's
[12:23] <zyga> pedronis: validation is in ReadInfoFromSnapFile but I don't see any calls to that yet
[12:24] <zyga> pedronis: specifically if you look at ReadInfo which is defined just above
[12:24] <zyga> pedronis: we just don't validate it
[12:24] <zyga> pedronis: and ReadInfo is used in readInfoAnyway
[12:24] <zyga> pedronis: which in turn powers CurrentInfo
[12:25] <zyga> pedronis: so this is both good and bad
[12:25] <zyga> pedronis: it's bad for obvious reason, we should validate
[12:25] <zyga> pedronis: it's good that maybe the rollback is "easier" as ... we don't validate
[12:25] <zyga> pedronis: but I'd like to ask you if this is for a reason, the missing validation
[12:26] <Chipaca> zyga— validation is done on ingestion
[12:26] <Chipaca> currently
[12:27] <Chipaca> zyga— which, not as good, we should do it on load, but it's there
[12:28] <zyga> Chipaca: hmmm
[12:28] <zyga> Chipaca: any reason not to always validate?
[12:28] <Chipaca> zyga— validation needs to be versioned?
[12:28] <Chipaca> other than that, no
[12:28] <zyga> Chipaca: I also worry that some "fixups" (see broken.go) are done in other places, it feels like this is responsibility for snap/ (package) to hide and do this internally
[12:28] <Chipaca> zyga— i mean, changing validation means patching
[12:28] <zyga> Chipaca: why?
[12:29] <zyga> Chipaca: patching as in overlord patches?
[12:29] <Chipaca> zyga— because valid state suddenly can become invalid without it
[12:29] <Chipaca> zyga— yes
[12:29] <zyga> aha
[12:29] <jdstrand> morphis: hey
[12:29] <zyga> but we don't store info in state?
[12:29] <morphis> jdstrand: hey!
[12:29] <zyga> Chipaca: so "state" is still valid
[12:30] <zyga> Chipaca: we may just notice disk is (and was) invalid
[12:30] <morphis> jdstrand: I've pushed up an initial version of the Xauthority handling at https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116/10
[12:30] <jdstrand> morphis: I'll add it to my list
[12:30] <morphis> jdstrand: and implemented simple parsing of the Xauthority file, is that ok for you to do validation of that file?
[12:31] <morphis> jdstrand: we don't have the xauth binary everywhere so need another way to handle this
[12:31] <jdstrand> morphis: I think simple parsing is good enough. I mean, X is supposed to handle it itself and we aren't trying to protect the user from herself
[12:31] <morphis> right
[12:32] <morphis> jdstrand: then let me go and prep a PR for this then we can do a proper review
[12:32] <jdstrand> ok
[12:36] <ogra_> niemeyer, your opinion on bug 1674509 (regarding the last four/five comments) would be valuable ...
[12:36] <mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
[12:41] <mikeb_> Chipaca: Just a follow up. It looks like surrounding my command arguments with escaped quote does, in fact, work as expected.  Now I have to figure out why my wrapper'daemonization is not
[12:41] <mikeb_> working.
[13:00] <zyga> tvoss: some small reviews on the rsa branch
[13:02] <zyga> pstolowski: standup?
[13:03] <tvoss> zyga: thanks, looking
[13:11] <Son_Goku> zyga: all we need is one more +1 and then snapd rolls out to stable for F25
[13:11] <Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2017-37a7331620
[13:11] <zyga> Son_Goku: just after my standup
[13:12] <zyga> Son_Goku: I'll boot my VMs and try
[13:12] <zyga> Son_Goku: thanks for tracking this!
[13:12] <Son_Goku> excellent
[13:12] <Son_Goku> mhall119: it's happening! :D
[13:13] <Son_Goku> zyga: if you do it quick enough, it might even sync out today!
[13:15] <zyga> Son_Goku: I didn't buy 16GB of ram (it's 250 euro) so I'm still on 4G, with that and firefox and chrome I cannot do it now
[13:16] <Son_Goku> damn
[13:30] <zyga> Son_Goku: testing f25 server now
[13:38]  * zyga hugs "dnf install --enablerepo=updates-testing snapd"
[13:53] <zyga> morphis: F25 server is good to go
[13:54] <morphis> zyga: great!
[13:55] <zyga> morphis: added my +1
[13:55] <zyga> going to try F24 while I wait for 26 alpha to download
[13:56] <morphis> zyga: what a wonderful weekend present
[13:56] <zyga> morphis: indeed
[14:05] <pedronis> niemeyer: it might be easier to do a separate preparatory branch though, because with these decisions AliasesStatus the type goes ways, that's a boring but big diff in itself I think
[14:06] <mup> PR snapcraft#1242 opened: kernel_plugin: use CROSS_COMPILE to override the default toolchain <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1242>
[14:06] <niemeyer> pedronis: Happy to follow your guidance on how to organize the changes in the easiest way
[14:06] <Chipaca> SLIGHTLY_UPSET_COMPILE
[14:06] <pedronis> niemeyer: thanks, I'll try and see just how big that is and go fromt there
[14:11] <zyga> Chipaca: ?
[14:12] <Chipaca> zyga— CROSS_COMPILE?
[14:12] <ogra_> zyga, that was a reaction to the PR line i think :)#
[14:12] <zyga> ah
[14:12] <zyga> I missed that :)
[14:12] <zyga> (got used to ignoring what humble mup says)
[14:14] <zyga> does ext4 do background initialization
[14:14] <zyga> so you can format quickly
[14:14] <zyga> and it will finish it in the background over time?
[14:15] <niemeyer> ogra_: Replied in the bug
[14:24] <morphis> zyga, niemeyer: what kind of ubuntu images are you using on Linode as a base? regular cloud images?
[14:28] <Pharaoh_Atem> zyga: snapd for Fedora 24 needs +1 karma to go stable: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4
[14:28] <zyga> morphis: we use ubuntu images that were modified to be like vanilla ubunut, that is booting with grub and with ubuntu kernel
[14:28] <zyga> Pharaoh_Atem: 24 is next on my list
[14:28] <Pharaoh_Atem> F25 and F26 have the karma to go stable
[14:28] <Pharaoh_Atem> so F24 is key now
[14:29] <zyga> Pharaoh_Atem: oh great, I will test 24 and skip 26 then
[14:29] <zyga> I reverted to the initial install snapshot
[14:29] <zyga> so "dnf update" takes a long while
[14:30] <tvoss> pedronis: so I'm looking into the BIO mem_buf stuff, encoding the key to a mem_buf BIO fails (not due to insufficient memory). Investigating
[14:31] <morphis> zyga: ok, wondering if we can just use the official openstack debian images as a base and initialize them once via cloud-init
[14:31] <morphis> Pharaoh_Atem: looks like F25 is close now :-)
[14:32] <morphis> Pharaoh_Atem: who is the third one who gave +1 for F25?
[14:32] <zyga> morphis: seems very sensible
[14:32] <morphis> ok
[14:32] <Pharaoh_Atem> morphis: decathorpe (Fabio Valentini)
[14:33] <Pharaoh_Atem> he's the guy packaging Pantheon Desktop for Fedora
[14:33] <Pharaoh_Atem> I asked him to test it out :)
[14:33] <Pharaoh_Atem> GL is busted with nvidia on Fedora, though
[14:33] <Pharaoh_Atem> it crashed for him when he tried to use ohmygiraffe
[14:33] <pedronis> tvoss: ok, I hope it can be made to work
[14:34] <zyga> Pharaoh_Atem: that's expected :/
[14:34] <zyga> Pharaoh_Atem: we need to redesign that
[14:35]  * zyga wishes he had more ram and maybe dedicated, non-spare-junk HDD for the VMs
[14:36] <morphis> Pharaoh_Atem: nvidia is still broken?
[14:36] <Pharaoh_Atem> Yep
[14:37] <zyga> morphis: yes, there was never support for fedora+nvidia
[14:37] <zyga> Pharaoh_Atem: tell me, is Fabio using drivers from the archive (if so, which package) or from nvidia directly?
[14:37] <Pharaoh_Atem> from the negativo17 repository, I believe
[14:37] <Pharaoh_Atem> or rpmfusion
[14:37] <Pharaoh_Atem> one of the two
[14:37] <zyga> Pharaoh_Atem: ok
[14:37] <zyga> I know how to fix it, just not a high priority (yet)
[14:37] <zyga> and no time (yet)
[14:38] <zyga> first need to get mount world in order
[14:38] <morphis> zyga: feel free to give me pointers for a fix
[14:39] <zyga> morphis: we don't print anything useful on isntall
[14:39] <zyga> morphis: we should say "please log out to get PATH updates"
[14:39] <zyga> or similar useful advice
[14:41] <zyga> morphis, Pharaoh_Atem: there are selinux denials because of loopback mounted snaps
[14:41] <zyga> for the gnome-shell
[14:41] <Pharaoh_Atem> :/
[14:42]  * Pharaoh_Atem makes a note to set up a Fedora Workstation system
[14:42] <zyga> type=AVC msg=audit(1491576072.251:282): avc:  denied  { getattr } for  pid=1044 comm="gnome-shell" path="/dev/loop-control" dev="devtmpfs" ino=16235 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:loop_control_device_t:s0 tclass=chr_file permissive=0
[14:42] <zyga> can we correct that from snapd-selinux
[14:42] <zyga> I suspect it should go to gnome-shell selinux directly too
[14:43] <Pharaoh_Atem> we cannot
[14:43] <Pharaoh_Atem> well, we *could*
[14:43] <Pharaoh_Atem> the gnome guys would kill us, though
[14:43] <morphis> :-D
[14:43] <morphis> I think there is a reason why this is denied for gnome-shell
[14:43] <Pharaoh_Atem> yeah
[14:43] <Pharaoh_Atem> it's out of scope for snapd-selinux anyway
[14:43] <morphis> but why is it trying to do this at all?
[14:44] <Pharaoh_Atem> maybe it's probing disks?
[14:44] <zyga> morphis, Pharaoh_Atem: let's file a bug and correct this in the main policy
[14:44] <zyga> Pharaoh_Atem: yes, I suspect so
[14:45] <zyga> type=AVC msg=audit(1491575811.619:770): avc:  denied  { create } for  pid=39655 comm="systemctl" name="var-lib-snapd-snap-hello\x2dworld-27.mount" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=lnk_file permissive=1
[14:45] <zyga> I have 50 selinux denials after installing hello-world and rebooting in workstation
[14:45] <morphis> Pharaoh_Atem, zyga: yeah lets get a bug and lets see why this happens and where we fix the best way
[14:45] <zyga> Pharaoh_Atem: shall I report those on bugzilla now?
[14:45] <Pharaoh_Atem> Yes
[14:45] <zyga> kk
[14:46] <zyga> Pharaoh_Atem: on redhat bugzilla, under fedora?
[14:46] <Pharaoh_Atem> yes
[14:46] <Pharaoh_Atem> component would be the source package name
[14:47] <zyga> ok
[14:47] <Pharaoh_Atem> well, at least the snappy denials are occurring permissively :D
[14:48] <zyga> Pharaoh_Atem: yeah but for gnome-shell it is a real denial
[14:48] <Pharaoh_Atem> yeah
[14:51] <morphis> zyga: yeah something we need to fix
[14:51] <zyga> morphis: I would love to get rid of the myriad of denials too
[14:51] <zyga> morphis: even if they are in complain mode
[14:51] <zyga> morphis: 100% of the users will see that
[14:51] <zyga> and it's just annoying
[14:51] <morphis> yes
[14:52] <morphis> Pharaoh_Atem, zyga: so do we hold the release back until early next week?
[14:52] <zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1440207
[14:53] <zyga> morphis: no, I think we can release
[14:53] <zyga> morphis: release, iterate
[14:54] <morphis> zyga: fine for me
[14:54] <zyga> morphis: can you install f25 workstation
[14:54] <zyga> morphis: snapshot it, install snapd + hello-world
[14:54] <zyga> morphis: and file all the bugs (on snapd in bugzilla) for each unique denial
[14:55] <zyga> morphis: it will be a while but I think that's the way to track them
[14:55] <zyga> morphis: I can help this weekend as I was hoping to see something selinux for a while
[14:55] <zyga> morphis: maybe I can squash one or two
[14:55] <morphis> zyga: can do this on monday, for today I want to finish what I have currently
[14:56] <zyga> morphis: ok
[14:56] <zyga> morphis: let me do one as an example
[14:57] <morphis> ok
[14:59] <zyga> Pharaoh_Atem, morphis: https://bugzilla.redhat.com/show_bug.cgi?id=1440208
[15:00] <zyga> suggestions on how to report those are welcome
[15:01] <zyga> morphis: fixing those might take a while but we should at least fix the majority that may be as easy as a few extra rules in the policy
[15:01] <morphis> yeah
[15:01] <zyga> ok, booting f24 now
[15:01] <morphis> zyga: can you add them to https://trello.com/c/Fvtml6A1/26-fedora-fix-selinux-denials ?
[15:01] <morphis> zyga: the bug links I mean
[15:02] <zyga> morphis: trello
[15:02] <zyga> morphis: no, trello is dead
[15:02] <morphis> zyga: it isn't :-)
[15:02] <morphis> that is for my cross-distro work
[15:02] <morphis> nothing else
[15:02] <zyga> morphis: let's be consistent
[15:02] <zyga> morphis: if anything use the forum
[15:03] <morphis> zyga: lets not discuss this here, this has a different scope but I am fine with a forum post for this too
[15:04] <zyga> morphis: +
[15:04] <zyga> morphis: +1
[15:10] <Pharaoh_Atem> zyga: are you able to give the F24 update a +1 yet?
[15:10] <zyga> Pharaoh_Atem: yes, now mid way dnf update
[15:10] <zyga> Pharaoh_Atem: at 335/763 updates
[15:11]  * Pharaoh_Atem is trying to beat the clock for when bodhi mash starts
[15:11] <zyga> Pharaoh_Atem: when is that?
[15:11] <zyga> Pharaoh_Atem: I will be ready in 10-15 minutes
[15:12] <zyga> (437 now)
[15:12] <Pharaoh_Atem> I don't know
[15:12] <Pharaoh_Atem> it's usually around now
[15:12] <zyga> aha
[15:12] <zyga> well
[15:12] <zyga> if we miss it, when is the next one?
[15:12] <zyga> daily
[15:12] <zyga> ?
[15:12] <Pharaoh_Atem> lemme check
[15:12] <zyga> thank you
[15:13] <tvoss> pedronis: I'll take a quick break
[15:13] <zyga> 500/763 updates
[15:14] <zyga> some updates are bigger than others...
[15:14] <ogra_> thanks for implanting sesame street music in my head now...
[15:15] <Pharaoh_Atem> zyga: it's irregular, but it happens about once a day
[15:15] <zyga> 620 now
[15:15] <zyga> still more than 10 minutes away I suspect, then all the disk IO starts and reboot and more installs
[15:16] <Pharaoh_Atem> you know, you didn't have to do a full update...
[15:16] <zyga> this is f24 vanilla iso install
[15:16] <zyga> I wanted it to be more realistic
[15:16] <Pharaoh_Atem> oh dear
[15:16] <Pharaoh_Atem> wow
[15:16] <Pharaoh_Atem> you reset all the way back to GA?
[15:16] <zyga> (as I said, snapshot :)
[15:16] <zyga> 741 now
[15:18] <zyga> DRPMs now
[15:25] <pedronis> pstolowski: I tried quickly, the issue is simply that json doesn't work with map[interface{}]interface{}
[15:26] <pedronis> (even if the value have correct types)
[15:27] <pstolowski> pedronis, yes, in fact json spec says only strings can be used as keys
[15:28] <jfmcarreira> heyyy guys
[15:28] <jfmcarreira> any help on this error? cannot create user data directory: /nfs/home/jcarreira.it/snap/vlc/x1: Read-only file system
[15:29] <zyga> jfmcarreira: hey
[15:29] <ogra_> jfmcarreira, looks like you are not trying to write to $SNAP_DATA but to $SNAP
[15:29] <zyga> to put your home directory on NFS you need to do some extra things
[15:29] <zyga> jfmcarreira: there's a bug report with details on launchpad
[15:29] <ogra_> (or rather $SNAP_USER_DATA in your case)
[15:29] <ogra_> oh
[15:29] <zyga> jfmcarreira: I cannot find it now (busy)
[15:29] <ogra_> ignore me
[15:30] <zyga> jfmcarreira: but quick suggestion:
[15:30] <ogra_> zyga, is right
[15:30] <zyga> jfmcarreira: for now you will have issues with network denials and this is a kernel/nfs limitation
[15:30] <zyga> jfmcarreira: if you --bind mount your home directory under /home/ you will have a better experience
[15:30] <zyga> jfmcarreira: but it won't work really
[15:30] <pedronis> pstolowski: yes, but this is an implementation detail, it could go over the key and still do the job if they are strings, but it doesn't
[15:30] <pedronis> pstolowski: anyway wrote a bit more in the forum
[15:32] <pstolowski> pedronis, ty
[15:37] <jfmcarreira> zyga: ok thanks for the help.. but i only have ubuntu on a NFS system
[15:39] <zyga> Pharaoh_Atem: finally updated
[15:44] <zyga> hmm, I don't get tab-completion on fc24
[15:45] <zyga> morphis, Pharaoh_Atem: we don't install tab completion files
[15:45] <Pharaoh_Atem> do we have tab completion files to install?
[15:46] <morphis> Pharaoh_Atem: yes
[15:46] <zyga> Pharaoh_Atem: yes
[15:46] <zyga> Pharaoh_Atem: I do that in suse
[15:46] <zyga> Pharaoh_Atem: it's just one file really
[15:46] <Pharaoh_Atem> well gee, I wish I had known :/
[15:46] <morphis> Pharaoh_Atem: no bad, lets do it with the next release :-)
[15:46] <zyga> Pharaoh_Atem: (and thanks to Chipaca's magic) they will now tab complete into snaps with confinement (really nice code to read)
[15:47] <Chipaca> *blush*
[15:47]  * zyga hugs Chipaca
[15:47] <zyga> really great stuff!
[15:48] <zyga> Pharaoh_Atem: +1 to release
[15:49] <Pharaoh_Atem> doesn't help me here :)
[15:49] <Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce0fdd87a4
[15:49] <zyga> Pharaoh_Atem: I was typing it there already :D
[15:50] <zyga> Pharaoh_Atem: saved
[15:50] <zyga> Pharaoh_Atem: after this is out I'll gladly get my feet wet and make a few trivial suggestions
[15:50] <zyga> Pharaoh_Atem: do we need +3 for F24 / F26?
[15:50] <Pharaoh_Atem> nope
[15:51] <Pharaoh_Atem> I lowered the karma req so that they'd all make it
[15:51] <zyga> ok
[15:51] <Pharaoh_Atem> though feel free to add feedback there too :)
[15:51] <zyga> I'll test 26 now
[15:51] <zyga> and EOD
[15:51] <Pharaoh_Atem> okay
[15:51] <zyga> the 2.24 issues are for next week or this evening, I have some ideas but too taxed mentally today
[15:52] <zyga> oh one more thing
[15:52] <zyga> Pharaoh_Atem, morphis: do you have any fedora booted?
[15:52] <zyga> I just shut down to install 26
[15:53] <zyga> what does "snap version" say?
[15:53] <zyga> is it correct?
[16:02] <zyga> Pharaoh_Atem: release release release
[16:07] <Pharaoh_Atem> zyga: looks like it already mashed... https://bodhi.fedoraproject.org/masher/
[16:07] <Pharaoh_Atem> :(
[16:08] <Pharaoh_Atem> zyga: it'll mash again early tomorrow, I think
[16:08] <Pharaoh_Atem> though it may happen earlier, who knows
[16:09] <zyga> Pharaoh_Atem: that's fine
[16:09] <zyga> Pharaoh_Atem: so once this is out can we do the tab completion and some tweaks over weekend?
[16:10] <Pharaoh_Atem> zyga: yeah
[16:10] <zyga> Pharaoh_Atem: great, I'll do that
[16:27] <mup> PR snapcraft#1240 closed: cli: improve push output <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1240>
[16:29] <jdstrand> niemeyer: hi! :) re 'I'd put that ahead of pretty much anything else'> were you talking to me or Sergio?
[16:29] <niemeyer> Oops.. fixing :)
[16:30] <jdstrand> ok. I'll get to that other bit. it is slowly moving up the list
[16:30] <niemeyer> Thanks
[16:36] <mup> PR snapd#3155 opened: snapstate: simplify AliasesStatus down to just an AutoAliasesDisabled bool flag (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3155>
[16:37]  * zyga takes a break now
[16:39] <pedronis> niemeyer: created snapd#3155 and then used it to simplify snapd#3087
[16:39] <mup> PR snapd#3155: snapstate: simplify AliasesStatus down to just an AutoAliasesDisabled bool flag (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3155>
[16:39] <mup> PR snapd#3087: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
[17:09] <niemeyer> pedronis: Thanks!
[17:46] <niemeyer> pedronis: Tests filaed on 3155.. the issue mvo reported with checksum problems on partial downloads
[17:46] <niemeyer> Retrying
[17:46] <pedronis> thanks
[17:47] <morphis> zyga: https://paste.ubuntu.com/24335332/ doesn't look bad for the first day working on this :-)
[18:03] <niemeyer> Taking a break
[18:13] <Guest123> Is it possible to install Ubuntu Core without an Ubuntu One account?
[18:18] <kyrofa> Guest123, install, yes. SSH into, no
[18:30] <Guest123> Is it possible to install Ubuntu Core without an Ubuntu One account?
[19:58] <coreycb> sergiusens_, hi, i added some details to bug 1675479. i have a work around but i'm not sure what's different in our environments that you weren't able to reproduce.
[19:58] <mup> Bug #1675479: python plugin doesn't work for namespace packages <openstack> <plugin> <Snapcraft:New> <https://launchpad.net/bugs/1675479>
[19:59] <coreycb> sergiusens_, probably can lower that from high though since i have a workaround
[20:30] <tvoss> okay, when using unsafe.Pointer, is ownership transferred to the go runtime?
[20:30] <tvoss> s/unsafe.Pointer/C.GoBytes/
[20:56] <tvoss> pedronis: done,just updated the PR with changes to avoid file operations
[20:59] <jdstrand> sabdfl: fyi, I already started poking at wayland: https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186/2
[21:00] <jdstrand> sabdfl: I've got gnome/wayland now running on my laptop and plan to work on the initial interfaces
[21:01] <kyrofa> jdstrand, nice
[21:02] <jdstrand> sabdfl: (fyi based on backscroll from earlier today)
[21:03] <jdstrand> it's kinda interesting cause snaps with gnome/wayland/portals should be a nice desktop security story
[21:09] <mup> PR snapcraft#1243 opened: tests: update the location of the upstream retry autopkgtests script <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1243>
[21:19] <sabdfl> hi jdstrand, thank you
[21:19] <sabdfl> yes i think we can bring those two ideas together very neatly
[21:20] <sabdfl> portals bear a startling resemblance to helpers so all the concepts are in place
[21:20] <sabdfl> and i'll be glad to have snaps be first class across all the major desktops
[21:20] <jdstrand> indeed
[21:21] <jdstrand> and they do bear a startling resemblance to helpers-- they were clearly inspired by our work :)
[21:29] <ahoneybun> sabdfl: are you taking about the flavors?
[21:30] <sabdfl> ahoneybun, and upstream
[21:30] <ahoneybun> right other distros too then
[21:31]  * ahoneybun dreams of a snap that can detect the desktop (gtk, qt) and change the UI to that
[22:15] <mup> PR snapcraft#1243 closed: tests: update the location of the upstream retry autopkgtests script <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1243>
[22:39] <lutostag> anybody know how to set dns servers on core 16?


[00:45] <JonOomph> Hi! I was curious if a LaunchPad recipe can invoke cargo (or commands which utilize git and GitHub). For example, in the Debian packaging rules, it runs the `cargo` command, but gets the following error: "spurious network error (2 tries remaining): curl error: Could not resolve host: github." Thx!
[01:03] <cjwatson> JonOomph: It can't talk to the internet.  I answered your question on answers.launchpad.net
[01:04] <cjwatson> But there are very many existing Rust packages in Ubuntu, so it can definitely be done with a bit more effort
[01:04] <JonOomph> Okay, thanks for the answer! I appreciate it!
[01:04] <cjwatson> (Not talking to the internet, that is, but getting cargo to use local registries etc.)
[01:26] <JonOomph> I was hoping for a quick win trying to package an unpackaged dependency... But it has 50+ cargo dependencies, and this is no longer what I would call a "quick" fix, haha
[01:27] <JonOomph> I'll make this an optional dependency, and then hope some folks will help package it up for Debian/Ubuntu and all the other distros out there.
[03:58] <veebers> ]j31
[03:58] <veebers> sigh
[15:17] <seb128> hey there! is launchpad/librarian having issues again?
[15:18] <juliank> same question here
[15:18] <juliank> getting 502s
[15:19] <cjwatson> there does seem to have been a spike
[15:20] <cjwatson> #is-outage internal
[15:21] <seb128> thx
[16:06] <cjwatson> seb128,juliank: better now?
[16:06] <seb128> cjwatson, yes!
[16:06] <seb128> thx
[16:06] <cjwatson> Restarting the librarian eventually helped but makes no sense
[16:07] <seb128> :/
[17:05] <tomreyn> hi, i just into a 503 while uploading a chromium crash log. https://i.imgur.com/bPJA59y.png
[17:06] <tomreyn> is errors.u.c. managed by you at all? if not, whom to talk to?
[17:10] <cjwatson> tomreyn: It's not.  #canonical-sysadmin
[17:10] <tomreyn> ty
[17:10] <tomreyn> + a nice weekend to you
[17:10] <cjwatson> (I think it's actually the Ubuntu foundations team, but IS should be able to either handle it or redirect you)
[17:10] <cjwatson> likewise
[18:23] <acheronuk> cjwatson: hi. would it be possible to get size bumped on this to 15GB? https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/beta
[18:24] <acheronuk> I would like to get testers on 2 releases, but can only fit one in there currently
[18:24] <cjwatson> acheronuk: you just caught me before I ran away for the weekend.  done
[18:24] <acheronuk> cjwatson: thank you :)
[18:24] <cjwatson> np
[18:24] <acheronuk> have a good weekend
[18:25] <cjwatson> had enough of working on the git.l.n redeployment for one week :)
[18:25] <acheronuk> ooooh. I bet, but having that perform better will be great.
[18:26] <cjwatson> some of it's ceph limitations that we can't improve without a better cloud
[18:26] <cjwatson> but the redeployment will remove at least some horizontal scaling barriers
[18:26] <cjwatson> and hopefully not introduce too many weird NFS bugs :)
[18:28] <acheronuk> fair enough. can cope its not super fast.
[18:28] <cjwatson> we were able to double its RAM recently, so that's helped
[18:29] <cjwatson> it isn't really going into deathspirals any more
[18:31] <acheronuk> timeout on our CI fetching packaging, causing build 'fails' was one annoying thing. and slow initial clone of repos
[18:32] <acheronuk> sometime I'm doing dozens or hundereds as a set, so slow gets multiplied
[18:32] <cjwatson> Have you seen any of that since 2019-01-11?
[18:33] <cjwatson> I mean, timeouts rather than mild sluggishness
[18:35] <acheronuk> some timeouts I think on the CI, but much much rarer. I now mostly just notice the sluggishness compared to what things were like a couple of years ago.
[18:36] <acheronuk> oh, I misread that date!
[18:36] <acheronuk> yes, it has been much better the last week
[18:37] <cjwatson> Right, that's when we doubled its RAM
[18:37] <acheronuk> some times before I'd do a git clone, and wonder if anything would ever happen....
[18:38] <cjwatson> The initial plan for the redeployment is to have about the same amount of total RAM, but spread across a couple of compute nodes and sharing storage via NFS
[18:38] <acheronuk> now there may be a slight delay, but it gets that quite quickly
[18:38] <acheronuk> sounds reasonable
[18:38] <cjwatson> If we need to scale up it'll basically be juju add-unit rather than needing to scrape around for bigger instance sizes
[18:39] <acheronuk> you are starting to lose me on the 'server speak' ;)
[18:39] <cjwatson> Took most of a month to get all the new deployment machinery put together though - I just finished the first end-to-end draft of that this afternoon
[18:39] <acheronuk> but it sounds cool
[18:40] <acheronuk> it is appreciated
[21:02] <jrwren> I'm trying to file an ubuntu bug, but when I click submit, I get an error.
[21:02] <jrwren> Timeout error
[21:03] <jrwren> Sorry, something just went wrong in Launchpad.
[21:03] <jrwren> Error ID: OOPS-9c464f76c8c3ba2369cc40720a6ed347
[21:30] <jrwren> oh, i tried a 4th time and this time it worked!
[21:30] <jrwren> the LP gods have smiled upon me.


[01:34] <doko> vorlon: first getting real issues fixed. Still need to validate the claims about -5ubuntu1
[03:40] -queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu9.7 => 2.31-0ubuntu9.8] (core, i386-whitelist)
[08:43] -queuebot:#ubuntu-release- New source: ignition-gui (jammy-proposed/primary) [6.3.0+ds-0ubuntu1]
[08:43] -queuebot:#ubuntu-release- New source: ignition-sensors (jammy-proposed/primary) [6.1.0+ds-0ubuntu1]
[08:44] -queuebot:#ubuntu-release- New source: ignition-rendering (jammy-proposed/primary) [6.1.0+ds-0ubuntu1]
[08:44] -queuebot:#ubuntu-release- New: accepted ignition-gui [source] (jammy-proposed) [6.3.0+ds-0ubuntu1]
[08:44] -queuebot:#ubuntu-release- New: accepted ignition-sensors [source] (jammy-proposed) [6.1.0+ds-0ubuntu1]
[08:44] -queuebot:#ubuntu-release- New: accepted ignition-rendering [source] (jammy-proposed) [6.1.0+ds-0ubuntu1]
[08:56] -queuebot:#ubuntu-release- New binary: ignition-rendering [amd64] (jammy-proposed/universe) [6.1.0+ds-0ubuntu1] (no packageset)
[09:00] -queuebot:#ubuntu-release- New binary: ignition-rendering [ppc64el] (jammy-proposed/universe) [6.1.0+ds-0ubuntu1] (no packageset)
[09:18] -queuebot:#ubuntu-release- New binary: ignition-rendering [armhf] (jammy-proposed/universe) [6.1.0+ds-0ubuntu1] (no packageset)
[09:20] -queuebot:#ubuntu-release- New binary: ignition-rendering [arm64] (jammy-proposed/universe) [6.1.0+ds-0ubuntu1] (no packageset)
[11:03] -queuebot:#ubuntu-release- New binary: ignition-rendering [riscv64] (jammy-proposed/universe) [6.1.0+ds-0ubuntu1] (no packageset)
[11:29] -queuebot:#ubuntu-release- New source: 0ad (jammy-proposed/primary) [0.0.25b-1.1ubuntu1]
[11:29] -queuebot:#ubuntu-release- New binary: halide [amd64] (jammy-proposed/universe) [13.0.4-1ubuntu2] (no packageset)
[11:44] -queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.103-0ubuntu5~20.04.6 => 0.104-0ubuntu2~20.04.1] (core)
[11:45] <LocutusOfBorg> finally fixed halide
[11:45] <ricotz> hello ubuntu-archive, please accept 0ad in NEW to reinstate it in jammy
[11:47] <slyon> sil2100: hey! The pending netplan SRU for Focal in LP: #1962297 now made it above the 7 day aging cutline, it should be released into -updates first, before accepting the 0.104 SRUs from the Impish and Focal queues.
[11:48] <sil2100> \o/
[11:48] <slyon> The 0.104 SRU (LP: #1964481) is kind of special, due to removing/hiding some internal symbols, so please read the changelog carefully. We discussed that approach with Steve and made sure not to break anybody, tho.
[11:53] <sil2100> ricotz: looking o/
[11:54] <ricotz> sil2100, thank you, see https://bugs.launchpad.net/ubuntu/+source/0ad/+bug/1962154
[12:39] <kanashiro> vorlon, I'll be taking a look at the uninstallability issue involving ruby2.7 you mentioned
[12:50] <ddstreet> fnordahl re: PPU application, would it be better to request to add those pkgs to the 'openstack' pkgset, and then you could apply for membership to the ~ubuntu-openstack-dev team?
[13:27] <LocutusOfBorg> vorlon,
[13:27] <LocutusOfBorg> -rw-r--r--  root/root   /usr/lib/python3/dist-packages/igraph-0.9.8.egg-info/PKG-INFO
[13:27] <LocutusOfBorg> -rw-r--r--  root/root   /usr/lib/python3/dist-packages/python_igraph-0.9.6.egg-info/PKG-INFO
[13:27] <LocutusOfBorg> this is what changed
[13:28] <xnox> urgh
[13:29] <LocutusOfBorg> I don't know what to do, patch dh-python to add a new quirk?
[13:30] <LocutusOfBorg> ./pydist/cpython3_fallback:igraph python3-igraph
[13:30] <LocutusOfBorg> I see this
[13:35] <tumbleweed> LocutusOfBorg: where is this?
[13:35] <tumbleweed> the amd64 build of https://launchpad.net/ubuntu/+source/python-igraph/0.9.9-1/+build/23101115 LGTM
[13:35] <LocutusOfBorg>  /usr/lib/python3/dist-packages/igraph-0.9.9.egg-info
[13:36] <LocutusOfBorg> the first line is the new version, the second line is the old version
[13:36] <LocutusOfBorg> the "new" version doesn't work, while python_igraph works
[13:37] <tumbleweed> doesn't work in what sense?
[13:37] <LocutusOfBorg> I: dh_python3 pydist:292: Cannot find package that provides python_igraph. Please add package that provides it to Build-Depends or add "python_igraph python3-igraph" line to debian/py3dist-overrides or add proper dependency to Depends by hand and ignore this info.
[13:37] <LocutusOfBorg> in the sense that python-leidenalg is sooooooooooooo sad :D
[13:37] <tumbleweed> is it in Build-Deps?
[13:37] <LocutusOfBorg> bulding python-leidenalg with the old version works
[13:37] <LocutusOfBorg> no change rebuild with new version broke
[13:37] <LocutusOfBorg>                python3-igraph <!nocheck>,
[13:38] <LocutusOfBorg> and yes it is there
[13:38] <LocutusOfBorg> its something in the upstream igraph renaming
[13:38] <tumbleweed> so, requirements.txt in python-leidenalg probably needs to be changed
[13:39] <tumbleweed> err the requirements, in setup.py/setup.cfg/wherever (probably not requirements.txt)
[13:40] <tumbleweed> or add an explicit dependency to the binary package, until upstream changes their requirements
[13:40] <Trevinho> Can someone please check on FFe https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1964732 ?
[13:40] <Trevinho> As I would like to avoid the extra steps involved in UIFe's, and so it would be nice to have in before Thu :-P
[13:47]  * tumbleweed is retrying autopkgtests to unblock python3-stdlib-extensions & python3.10
[14:23] <LocutusOfBorg> tumbleweed, isn't cpython3_fallback born for this reason?
[14:23] <LocutusOfBorg> adding
[14:23] <LocutusOfBorg> python-igraph python3-igraph to that file works
[14:24] <tumbleweed> LocutusOfBorg: no
[14:24] <tumbleweed> cpython3_fallback is there for people who don't build-depend on packages that they expect to depend on
[14:26] <stgraber> can't remember whether deletions need an FFe or not, so filed one anyway: https://bugs.launchpad.net/ubuntu/+source/adapt/+bug/1964786
[14:27] <stgraber> if this makes sense to someone else in ~ubuntu-release, please approve and I'll switch hat to ~ubuntu-archive and handle the cleaup
[14:27] <stgraber> *cleanup
[14:28] <LocutusOfBorg> tumbleweed, https://github.com/vtraag/leidenalg/commit/7e415c3ad0965f96d2351b0cefab9f4d5b577531
[14:28] <LocutusOfBorg> NICE
[14:42] <holmanb> @sil2100: cloud-init cherry picked a patch into 22.1 to revert a change that introduced a regression on Oracle. The latest upload is queued in unapproved state. Could you please review and accept into -proposed?
[14:59] <LocutusOfBorg> vorlon, fixed
[15:09] <vorlon> LocutusOfBorg: thanks!
[15:18] -queuebot:#ubuntu-release- Unapproved: evdi (focal-proposed/universe) [1.9.1-1ubuntu4~20.04.1 => 1.9.1-1ubuntu4~20.04.2] (kernel-dkms)
[15:19] -queuebot:#ubuntu-release- New: accepted 0ad [source] (jammy-proposed) [0.0.25b-1.1ubuntu1]
[15:25] -queuebot:#ubuntu-release- New: accepted halide [amd64] (jammy-proposed) [13.0.4-1ubuntu2]
[15:34] <vorlon> ah, nvidia-cuda-toolkit, lovely, hard-coded libssl because of a bundled libqt5network5 that dlopens it
[15:36] <bdmurray> holmanb: I'll take a look at cloud-init as sil2100 may be out
[15:38] <holmanb> bdmurray: Thanks!
[15:43] <xnox> vorlon:  i wonder if we should quickly upgrade nvidia-cuda-toolkit to something much newer.
[15:43] <vorlon> xnox: that sounds fun
[15:45] <vorlon> xnox: it also sounds rather orthogonal; the libssl1.1 dep is hard-coded in debian/control, and even qtbase-opensource-src is cherry-picking upstream fixes for openssl3 compat so there's no guarantee a newer nvidia-cuda-toolkit upstream is any better
[15:48] -queuebot:#ubuntu-release- New binary: 0ad [amd64] (jammy-proposed/universe) [0.0.25b-1.1ubuntu1] (no packageset)
[15:50] -queuebot:#ubuntu-release- New: accepted 0ad [amd64] (jammy-proposed) [0.0.25b-1.1ubuntu1]
[16:40] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (impish-proposed) [22.1-14-g2e17a0d6-0ubuntu1~21.10.2]
[16:41] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [22.1-14-g2e17a0d6-0ubuntu1~20.04.2]
[16:44] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [22.1-14-g2e17a0d6-0ubuntu1~18.04.2]
[16:45] <ricotz> LocutusOfBorg, hi, please sync wine 6.0.3~repack-1
[16:51] <LocutusOfBorg> ,
[16:56] -queuebot:#ubuntu-release- Unapproved: yt-dlp (focal-backports/universe) [2022.02.04-1~bpo20.04.1 => 2<IP_ADDRESS>-1~bpo20.04.1] (no packageset)
[17:51] <ricotz> ty
[18:11] -queuebot:#ubuntu-release- New sync: yapet (jammy-proposed/primary) [2.6-1]
[18:48] <vorlon> mwhudson: is the new yapet fixed for openssl 3?
[18:51] <stgraber> vorlon: sorry should have been clearer about how broken "adapt" is :) AFAICT the last time it would have worked for anyone is July 2016, effectively against Ubuntu 16.04 GA and up until that old protocol was dropped from the upstream image servers (a few years ago). That package never worked at all in 16.10 or higher.
[18:52] <Eickmeyer[m]> cjwatson: Still failing. :(
[18:52] <stgraber> This seems like it was a one-off lightning-talk type script from kirkland which found its way into the archive and was never updated by its author :)
[19:38] <LocutusOfBorg> nice linux-firmware broke autopkgtests...
[19:40] <LocutusOfBorg> dpkg: error processing archive /var/cache/apt/archives/linux-firmware_20220314.gitcd01f857-0ubuntu1_all.deb (--unpack):
[19:40] <LocutusOfBorg>  unable to install new version of '/lib/firmware/ath11k/WCN6855/hw2.1/amss.bin': No such file or directory
[19:40] <LocutusOfBorg> e.g<EMAIL_ADDRESS>[19:41] <LocutusOfBorg> vorlon, what about restore when previous version?
[19:42] <vorlon> stgraber: ack thanks
[19:42] <vorlon> LocutusOfBorg: you want to roll back linux-firmware?
[19:42] <LocutusOfBorg> I guess so :)
[19:43] <LocutusOfBorg> otherwise installations and autopkgtests will be broken...
[19:43] <LocutusOfBorg> not sure how to fix, I think better ask uploader to fixup
[19:43] <vorlon> it's already in the release pocket so a rollback is best done with a new upload that reverts
[19:43] <vorlon> so yeah let's talk to the uploader
[19:43] <LocutusOfBorg> (not even sure why such issue was not triggered)
[19:43] <LocutusOfBorg> is he on irc?
[19:43] <vorlon> not sure
[19:43] <vorlon> juergh:
[19:44] <vorlon> juergh: hi, LocutusOfBorg has some concerns about linux-firmware causing regressions, see above
[19:44] <LocutusOfBorg> juergh, look on e.g. https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xorg-server for "/unknown"
[19:44] <LocutusOfBorg> all the tests are failing since 1h, the time where linux-firmware migrated
[19:45] <vorlon> LocutusOfBorg: it is past EOD for him so he may well not reply today
[19:45] <vorlon> LocutusOfBorg: so is the package completely uninstallable?
[19:45] <LocutusOfBorg> I would say so
[19:45] <LocutusOfBorg> I'm testing locally
[19:45] <vorlon> if so that's a pretty strong argument for rolling it back regardless
[19:45] <LocutusOfBorg> vorlon, if I get a fix I'll upload the new one
[19:45] <LocutusOfBorg> I'm pulling the source
[19:46] <LocutusOfBorg> broke all autopkgtests, they will need some manual kick
[19:46] <kanashiro> vorlon, FYI I just uploaded ruby3.0 fixing the generation of Provides from libruby3.0 which should fix the uninstallability issues you mentioned
[19:46] <LocutusOfBorg> I don't think anybody could have installed it on their machines :D
[19:48] <mwhudson> vorlon: yes
[19:49] <mwhudson> vorlon: i forwarded the debian bug upstream and he fixed it and the debian maintainer picked it up just after it got removed
[19:52] <LocutusOfBorg> dpkg: error processing archive /var/cache/apt/archives/linux-firmware_20220314.gitcd01f857-0ubuntu1_all.deb (--unpack):
[19:52] <LocutusOfBorg>  unable to open '/lib/firmware/ath11k/WCN6855/hw2.0/regdb.bin.dpkg-new': No such file or directory
[19:52] <LocutusOfBorg> nice I got a different issue
[19:52] <LocutusOfBorg> but still uninstallable in empty chroot
[20:01] <tjaalton> I don't see how it could be caused by linux-firmware.. it's just a package with bunch of files
[20:05] <tjaalton> the package installs just fine on a focal chroot
[20:06] <LocutusOfBorg> mmm interesting
[20:06] <LocutusOfBorg> so debhelper is to blame?
[20:06] <LocutusOfBorg> or dpkg?
[20:08] <LocutusOfBorg> tjaalton, did you try to install the previous and then upgrade?
[20:08] <LocutusOfBorg> maybe its the upgrade path broken
[20:10] <tjaalton> no
[20:12] <tjaalton> hmm that fails yes
[20:13] <LocutusOfBorg> interesting
[20:13] <LocutusOfBorg> because also for me a clean installation in jammy worked
[20:14] <LocutusOfBorg> oh... today is 314, maybe a package that has PI in the changelog fails...
[20:14] <LocutusOfBorg> never upload on PI day!
[20:24] <tjaalton> I guess it's caused by the symlinks
[20:24] <tjaalton> +Link: ath11k/WCN6855/hw2.1/regdb.bin -> ../hw2.0/regdb.bin
[20:24] <tjaalton> etc
[20:25] <tjaalton> well, it's hw2.1/ -> hw2.0/
[20:28] <LocutusOfBorg> but the symlink looks good?
[20:28] <LocutusOfBorg> I thought it was the symlink but still looks correct
[20:29] <vorlon> kanashiro: ruby3.0> hurray! thanks
[20:29] -queuebot:#ubuntu-release- New: accepted yapet [sync] (jammy-proposed) [2.6-1]
[20:33] <tjaalton> right, the symlinks look fine
[20:34] -queuebot:#ubuntu-release- New binary: yapet [amd64] (jammy-proposed/universe) [2.6-1] (no packageset)
[20:35] -queuebot:#ubuntu-release- New binary: yapet [s390x] (jammy-proposed/universe) [2.6-1] (no packageset)
[20:36] <LocutusOfBorg> I'm out of ideas
[20:36] -queuebot:#ubuntu-release- New binary: yapet [ppc64el] (jammy-proposed/universe) [2.6-1] (no packageset)
[20:36] <sarnold> strace a dpkg -i run?
[20:37]  * LocutusOfBorg tries
[20:38] -queuebot:#ubuntu-release- New binary: yapet [armhf] (jammy-proposed/universe) [2.6-1] (no packageset)
[20:41] -queuebot:#ubuntu-release- New: accepted yapet [armhf] (jammy-proposed) [2.6-1]
[20:41] -queuebot:#ubuntu-release- New: accepted yapet [s390x] (jammy-proposed) [2.6-1]
[20:41] -queuebot:#ubuntu-release- New: accepted yapet [ppc64el] (jammy-proposed) [2.6-1]
[20:41] -queuebot:#ubuntu-release- New: accepted yapet [amd64] (jammy-proposed) [2.6-1]
[20:43] <LocutusOfBorg> sarnold, https://easyupload.io/c9qdij
[20:54] -queuebot:#ubuntu-release- New binary: yapet [arm64] (jammy-proposed/universe) [2.6-1] (no packageset)
[20:55] <sarnold> LocutusOfBorg: sigh nothing stands out as an obvious source of the error :(
[20:56] <LocutusOfBorg> sarnold, indeed :/
[20:56] <LocutusOfBorg> and its not even the first link being processed
[20:57] <LocutusOfBorg> maybe juliank has some idea
[21:00] <juliank> LocutusOfBorg: write a summary, put it in a LP bug and I might take a look tomorrow. Too late to read backlog and think now, sorry
[21:02] <sarnold> heh, good plan :)
[21:06] <LocutusOfBorg> juliank, https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1964825
[21:06] <LocutusOfBorg> :) g'night
[21:26] <mwhudson> can we blame usrmerge for this
[21:57] -queuebot:#ubuntu-release- Unapproved: lxd (focal-proposed/universe) [1:0.9 => 1:0.10] (edubuntu, ubuntu-server)
[21:59] <stgraber> ^ tiny change but unfortunately quite time sensitive
[22:28] <cjwatson> Eickmeyer[m]: Yeah, I don't need further updates at the moment since IS haven't got back to me
[22:39] <RAOF> stgraber: Do you want to ping SRU for that lxd? Do you have someone on it already?
[23:06] <stgraber> RAOF: I don't have anyone looking at it yet, diff is tiny, just changing a debconf template to remove the option we don't want to expose anymore
[23:11] <RAOF> stgraber: `_Description` is a translatable (and translated?) string, right? How is that going to be handled?
[23:12] <stgraber> RAOF: oh right, forgot about that. Based on that, I guess it'd be better not to change the description, better to have a description that's slightly out of sync than not translated
[23:13] <RAOF> 👍
[23:14] -queuebot:#ubuntu-release- Unapproved: rejected lxd [source] (focal-proposed) [1:0.10]
[23:15] <RAOF> And the moral of the story is:  Launchpad should have invested in turing-passing AI so that we could accurately machine-translate everything we upload :)
[23:15] -queuebot:#ubuntu-release- Unapproved: lxd (focal-proposed/universe) [1:0.9 => 1:0.10] (edubuntu, ubuntu-server)
[23:16] <stgraber> RAOF: updated ^
[23:17] <stgraber> and yeah, translations have always been problematic for that, even worse when the translation is in the langpack
[23:17] <stgraber> because even in the magical world where we get it all translated quickly, we still need another update to actually roll it out :)
[23:17] <RAOF> Ooof, and sorry! Why are we unmounting `/var/lib/lxd/*` on package removal? There's no bug associated.
[23:18] <stgraber> that was a fix we had in the packaging branch for a while, let me look for it, we may have a bug somewhere for it
[23:18] <stgraber> yeah, looks like https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1876979 was where we noticed it, only saw one report but felt safe to include since we || true :)
[23:19] <stgraber> RAOF: want a re-upload with the bug # added?
[23:19] <RAOF> Yes, please. Might as well while I've got you here :)
[23:20] -queuebot:#ubuntu-release- Unapproved: rejected lxd [source] (focal-proposed) [1:0.10]
[23:29] -queuebot:#ubuntu-release- Unapproved: lxd (focal-proposed/universe) [1:0.9 => 1:0.10] (edubuntu, ubuntu-server)
[23:42] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (focal-proposed) [1:0.10]
[23:58] <jbicha> autopkgtest infrastructure looks broken
[23:59] <sarnold> jbicha: is it linux-firmware in the logs?
[23:59] <jbicha> ok yes
[23:59] <sarnold> jbicha: .. if that sounds familiar, https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1964825