| mborzecki | morning | 04:56 |
|---|---|---|
| mborzecki | brb, new kernel | 05:00 |
| mborzecki | arch packages updated | 05:46 |
| zyga | Hi | 05:56 |
| zyga | Nice :-) | 05:56 |
| zyga | Biking home, 15 min | 05:57 |
| mborzecki | zyga: hey | 06:10 |
| jamesh | zyga: thanks for the review comments on the user session agent branch yesterday. It looks like this will need to be a separate process to userd though :-( | 06:16 |
| jamesh | not a huge deal, but means we don't have everything sitting under one roof. | 06:17 |
| zyga | re | 06:38 |
| zyga | jamesh: hey, because of the second socket? | 06:38 |
| zyga | jamesh: I thought that system can model that | 06:38 |
| zyga | jamesh: I'm catching up with the comments on the PR | 06:41 |
| zyga | jamesh: ah, is it because of xenial's systemd user oddity? | 06:43 |
| zyga | jamesh: hmm, that's unfortunate | 06:43 |
| zyga | hmm hmm hmm | 06:44 |
| zyga | jamesh: thank you for iterating on the branch | 06:44 |
| zyga | jamesh: it would be good to try to dig why systemd behaves this way on 16.04 and if that is something we can remedy, either on snapd side or by changing the distribution package a little | 06:44 |
| zyga | mborzecki: yesterday I implemented prediction of event propagation for snap-update-ns | 06:44 |
| zyga | mborzecki: I need to tweak it some more and add more tests but it is promising | 06:44 |
| mborzecki | zyga: nice, let me know when you ahve something to review | 06:45 |
| zyga | mborzecki: thank you, it doesn't pass all tests yet so I need to address that first | 06:46 |
| mborzecki | mhm | 06:46 |
| zyga | mborzecki: maybe it is a dead end but it is seductive that it doesn't require major changes in s-u-n | 06:46 |
| mborzecki | zyga: see, at least you did something useful, i instead was at a meetup about migration from c++11 to c++14, not sure if that was the presenter's goal, but i left with the conclusion that you should not let clerks and lawyers design a language | 06:50 |
| zyga | hahaha | 06:50 |
| zyga | what's the issue with C++ 11 -> C++14 | 06:50 |
| zyga | I recently used a C11 feature and I loved it (not C++) | 06:50 |
| zyga | standard atomics | 06:50 |
| mborzecki | zyga: s/is/are/ | 06:51 |
| mborzecki | zyga: i'm still waiting for a meetup about some large codebase introducing c++17 that should be even more questionable fun | 06:52 |
| jamesh | zyga: it would probably be possible to update the dbus upstart job to do a "systemctl --user set-environment" call, but I don't know how likely it would be for that to be accepted | 07:01 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:01 |
| jamesh | zyga: also, I suspect we'd have problems due to two ways for "snap userd" to be started: directly by dbus-daemon if a D-Bus call comes in, or managed by systemd for socket activation | 07:02 |
| zyga | jamesh: I think it's worth checking to ensue consistency of the snap platform | 07:02 |
| zyga | mmm | 07:02 |
| zyga | jamesh: tricky business, thank you for staying on top of that | 07:02 |
| zyga | good morning pstolowski | 07:02 |
| mborzecki | pstolowski: heyah | 07:02 |
| jamesh | zyga: and I suspect the the dbus-daemon invoked userd won't be able to take over the socket systemd created | 07:02 |
| jamesh | zyga: in contrast, having two processes should work the same everywhere. | 07:03 |
| zyga | jamesh: true though I wonder if we should design this so that a OS version on the way out dictates how it behaves everywhere in the future | 07:03 |
| jamesh | zyga: is there much benefit to multiplexing it all into a single process though? | 07:05 |
| zyga | jamesh: that I don't know, my whole point is we should be thoughtful about the design | 07:05 |
| zyga | there may be good reasons to do either approaches | 07:06 |
| jamesh | zyga: the systemd env on xenial is pretty bare. So in addition to not seeing the session bus, user units won't see the display | 07:11 |
| zyga | jamesh: please capture that in the thread, I think it is relevant for reviewers | 07:11 |
| zyga | brb | 07:59 |
| zyga | re | 08:10 |
| pedronis | mborzecki: hi, I looked again at #6680 | 08:34 |
| mborzecki | pedronis: hi, thanks for the the comments | 08:35 |
| Chipaca | mup_: you ok there? | 08:44 |
| Chipaca | niemeyer: can you tickle mup? it's feeling down | 08:44 |
| Paddy_NI | If I wanted others to test an app that I have snapped what would be the best practise for sharing the "snap" package? | 09:53 |
| jamesh | Paddy_NI: do you care who in particular tests it? | 09:55 |
| Paddy_NI | Not at all | 09:55 |
| Paddy_NI | :-) | 09:55 |
| jamesh | if you plan to eventually release it on the store, just register its name and publish the snap to the beta channel | 09:55 |
| jamesh | it won't show up in search results, and you can just tell people to run "snap install --beta myapp" | 09:55 |
| jamesh | when it's ready for general use, publish to stable | 09:56 |
| Paddy_NI | Okay, well the app is under MIT license and it's not mine. I have reached out to the developer via email and he has not responded. I just feel uneasy about publishing someone else's app. | 09:56 |
| Paddy_NI | I am also not sure just how "secure" or "safe" this app is, I have been using it for a very long time and think it's great but my own personal experience is not of much value when it comes to the safety of others | 09:58 |
| jamesh | you've to two options then: (1) publish it with a different name (e.g. suffix it with your own name), or (2) register it with the real name and get the name transferred later if the upstream wants to take over. | 09:58 |
| Paddy_NI | Okay, I might just add my name that seems like less hassle :-) | 09:58 |
| Paddy_NI | Thank you jamesh | 09:58 |
| Paddy_NI | Would I add my name as a suffix to the snapcraft.yaml too? | 09:59 |
| jamesh | yes. The "name" field in the snapcraft.yaml should match what you're publishing it as. | 10:00 |
| Chipaca | jamesh: beta does appear in search results | 10:00 |
| Paddy_NI | Okay good to know :-) | 10:00 |
| Chipaca | jamesh: from 'snap find' that is | 10:00 |
| jamesh | Chipaca: oh? I thought it was only stable | 10:00 |
| Chipaca | won't appear in gnome software | 10:00 |
| Chipaca | but will appear on the terminal | 10:00 |
| Chipaca | jamesh: search is now broad by default | 10:00 |
| Chipaca | jamesh: (old behaviour is --narrow) | 10:00 |
| Chipaca | Paddy_NI: it's probably best to register the final name | 10:01 |
| Chipaca | Paddy_NI: otherwise, people will get stranded | 10:01 |
| jamesh | Chipaca: thank you for the review comments yesterday. Converting to the new http.Server Shutdown() method turned out to be pretty easy | 10:01 |
| Chipaca | Paddy_NI: that is, say you register fooapp-paddy | 10:01 |
| Chipaca | Paddy_NI: people install it and love it | 10:02 |
| Chipaca | Paddy_NI: fooapp notices and starts doing their own, official, snap | 10:02 |
| Chipaca | Paddy_NI: so you stop maintaining fooapp-paddy | 10:02 |
| Chipaca | Paddy_NI: the users of which are now abandoned | 10:02 |
| Paddy_NI | That does not sound ideal | 10:02 |
| Chipaca | Paddy_NI: instead, if you grab fooapp, when they notice and want to pick it up it's a forum post and a couple of emails to get it transferred | 10:02 |
| Paddy_NI | Chipaca, Okay I'll do that instead :-) | 10:03 |
| Chipaca | Paddy_NI: it is a little bit more work for the handoff, but it doesn't suck for users as much when things go well :) | 10:03 |
| Chipaca | go well == upstream picks it up | 10:03 |
| Paddy_NI | That makes lots of sense | 10:04 |
| Chipaca | but we've tried to make it easy (as popey and/or Wimpress can attest) | 10:04 |
| Chipaca | jamesh: i'm glad that refactor is easy as i've been dreading it for daemon itself :0 | 10:04 |
| Chipaca | meant to write :) but :0 is also appropriate | 10:04 |
| Paddy_NI | This app can be used in conjunction with other applications using "--vlc" or "--mpv" or whatever really, is there a "plug" for this functionality as I am pretty sure it does not work at the moment in my snap? | 10:06 |
| jamesh | Chipaca: https://github.com/jhenstridge/snapd/blob/user-session-agent/userd/session_agent.go#L121 <- it's just a few lines longer, plus ignoring http.ErrServerClosed in the Serve goroutine | 10:06 |
| pedronis | Chipaca: there should be an explicit way to ask not to appear in searches though | 10:07 |
| Chipaca | pedronis: yes but AFAIK that's not implemented yet? | 10:07 |
| Chipaca | pedronis: at some point there was talk of not showing things that were only in edge, but I don't think that got done either | 10:08 |
| Chipaca | e.g. 'snap find wine' finds 'paladins' which is edge-only | 10:08 |
| pedronis | no now find gets everything | 10:09 |
| pedronis | but I thought we added a flag to hide from search | 10:09 |
| Paddy_NI | I wonder if all those plugs are necessary or if there is some overlapping, here is the contents of my yaml https://paste.ubuntu.com/p/8ngT32WpFQ/ | 10:10 |
| Chipaca | Paddy_NI: no plugs for vlc nor mpv, and typically those things would get bundled in a snap (unless it's a classic-mode snap which has its own drawbacks) | 10:12 |
| zyga | afk for a moment | 10:13 |
| Paddy_NI | Ah I see, so I would need to choose for the user. It would be a bit mad to bundle in VLC, MPV etc | 10:13 |
| pedronis | Chipaca: it's there, got to https://snapcraft.io/YOUR-SNAP/settings | 10:13 |
| Chipaca | pedronis: ooh nice | 10:13 |
| pedronis | remember that nowadays most publisher UI is in the store | 10:13 |
| Paddy_NI | Perhaps then the snap would have the bundled player suffixed to the name | 10:13 |
| Paddy_NI | "peerflix-mpv" | 10:14 |
| Chipaca | Paddy_NI: there's an "unlisted" option in the 'settings' tab of your snap on the web | 10:14 |
| Chipaca | Paddy_NI: as pedronis pointed out | 10:14 |
| Chipaca | pedronis: I didn't know that was implemented, that's neat | 10:15 |
| Paddy_NI | Chipaca, Alan Pope mentioned that in one of the snapcraft.io videos on youtube | 10:15 |
| Chipaca | psh, what does he know | 10:15 |
| Chipaca | :-þ | 10:15 |
| Paddy_NI | I just wasn't sure about etiquette | 10:15 |
| Paddy_NI | :-) | 10:16 |
| Chipaca | pedronis: we should make all the test-snapd-* snaps unlisted (unless we use them for 'snap find' integration tests) | 10:16 |
| Chipaca | Paddy_NI: wrt plugs etc that sounds more like a forum topic so you can get the right people's time to look | 10:17 |
| pedronis | Chipaca: maybe | 10:17 |
| Chipaca | Paddy_NI: some of those are gnarly interfaces | 10:17 |
| Paddy_NI | Chipaca, I was thinking that, I am very hesitant about sharing this with people | 10:18 |
| * Chipaca is people too! | 10:18 | |
| Paddy_NI | I also noticed an "issue" on the github page which has went unaddressed | 10:19 |
| Paddy_NI | I'll stick it on the snap store unlisted and see who wants to try it | 10:19 |
| * popey_ looks at Chipaca -_- | 10:20 | |
| jamesh | Paddy_NI: I wouldn't expect a bittorrent client to need firewall-control, network-control, or fwupd | 10:20 |
| jamesh | at a minimum | 10:20 |
| jamesh | try removing them and see if your snap still functions | 10:21 |
| Chipaca | jamesh: that's probably for poking holes to get incoming connections | 10:21 |
| Paddy_NI | jamesh, It streams the video over your lan you see | 10:21 |
| Chipaca | but i dunno | 10:21 |
| Paddy_NI | Unless that still does not matter | 10:21 |
| * Chipaca ignores popey_ and hopes for the best | 10:21 | |
| Paddy_NI | So for instance I would do 'peerflix "magnet_link_here"' and I can stream the video or whatever using the ip address of the computer being used on port 8888 | 10:22 |
| Paddy_NI | Very handy | 10:22 |
| jamesh | Paddy_NI: fwupd has nothing to do with firewalling | 10:22 |
| Paddy_NI | Okay I'll remove it and continue testing | 10:23 |
| jamesh | it is a tool for updating firmware | 10:23 |
| jamesh | in general you should ask for the minimal set of permissions the app needs, rather than just adding them just in case | 10:24 |
| Paddy_NI | If I don't use the "home" plug then I cannot do 'peerflix path/to/torrent.torrent' | 10:24 |
| jamesh | that one is fine | 10:24 |
| Paddy_NI | jamesh, I started with none | 10:24 |
| Paddy_NI | The output from snapcraft security log told me those | 10:24 |
| jamesh | Paddy_NI: if the app runs unconfined as a regular user, it probably doesn't need the *-control plugs | 10:25 |
| Paddy_NI | Or rather those snappy-debug.security scanlog | 10:25 |
| Paddy_NI | cool | 10:25 |
| Paddy_NI | Okay I have lost count now of how many times I have watched the opening sequence to "Big Buck Bunny" | 10:30 |
| Paddy_NI | The app works minus the aforementioned plugs. Thanks guys :-) | 10:31 |
| Paddy_NI | Bundling in mpv would probably be wise | 10:31 |
| Paddy_NI | It's not how I would use it but that's irrelevant I suppose. | 10:32 |
| Chipaca | Paddy_NI: there was somebody else looking into bundling mpv just yesterday | 10:32 |
| Chipaca | Paddy_NI: check the channel logs :) | 10:33 |
| Paddy_NI | Oh excellent :-) | 10:33 |
| Paddy_NI | Chipaca, I've just checked the logs from 4th, 5th and 6th of June. No mention of mpv. | 10:39 |
| Paddy_NI | Maybe I'm just stupid | 10:39 |
| Chipaca | Paddy_NI: i started searching myself as well and can't find it either | 10:39 |
| Chipaca | maybe i imagined it ¯\_(ツ)_/¯ | 10:39 |
| Paddy_NI | Chipaca, lol | 10:40 |
| Chipaca | wonder how | 10:40 |
| Paddy_NI | I'm going to google a bit | 10:40 |
| Chipaca | Paddy_NI: https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189 | 10:41 |
| Chipaca | Paddy_NI: not on irc :) | 10:41 |
| Paddy_NI | Ah great, cheers Chipaca | 10:41 |
| Paddy_NI | I suppose there is tons of work going on with regard interfaces "plugs"? It would be nice if there was a generic media player "plug" although that's most likely easier said than done. | 10:48 |
| Paddy_NI | If someone snaps a web browser and the user installs and uses this browser then clicks on say a "mailto" link is that able to summon the external mail client? | 10:50 |
| Chipaca | Paddy_NI: yes | 10:58 |
| Chipaca | Paddy_NI: through a magic proxying of xdg-open | 10:58 |
| * Chipaca ⇝ runch | 10:58 | |
| Paddy_NI | Chipaca, I suppose this works the same for magnet links etc? | 10:58 |
| Chipaca | Paddy_NI: i honestly don't know | 10:58 |
| Chipaca | when we wrote the first iteration, no | 10:59 |
| Chipaca | but it's seen work since and i lost track of it | 10:59 |
| Paddy_NI | Chipaca, That's no worries, I wonder if the same process is all that would be needed for peerflix | 10:59 |
| Chipaca | sounds reasonable to me | 10:59 |
| Paddy_NI | ultimately it's just telling the media player to open "http://localhost:8888" | 10:59 |
| Chipaca | jamesh: is that something you worked on? ^ | 10:59 |
| jamesh | Chipaca: I don't think the existing portals APIs will help much here. It'll probably just open the URL in a web browser too | 11:01 |
| Paddy_NI | Ah I see | 11:01 |
| ogra | Paddy_NI, if you cant see big buck bunny anymore ... https://durian.blender.org/download/ is also fine for testing | 11:04 |
| Paddy_NI | lol | 11:04 |
| Paddy_NI | Thanks for that :-) | 11:04 |
| ogra | :) | 11:04 |
| Paddy_NI | @ogra, I am using this list https://webtorrent.io/free-torrents | 11:05 |
| Paddy_NI | Amazing level of work has went into those videos, blows my mind. | 11:05 |
| ogra | ah, there is sintel on the list nevermind then | 11:06 |
| Paddy_NI | @ogra, I specifically need magnet links and torrent files to test this any how :-) | 11:07 |
| ogra | ah | 11:07 |
| Paddy_NI | It would be shoddy of me to stick peerflix on the store in it's current form as it is technically broken. | 11:08 |
| Paddy_NI | I could try moving on to "mps-youtube" however I believe I shall be facing the exact same issue with regards calling external media players | 11:09 |
| Paddy_NI | Which then brings me back to electing one that I bundle in | 11:09 |
| Paddy_NI | MPV of course would be my desired player but this might not be true of others. Also "mps-youtube" typically only works if both it and "youtube-dl" have been installed via "pip3" | 11:10 |
| Paddy_NI | Installing youtube-dl via apt creates problems with paths, mps-youtube expects it to be somewhere else. | 11:11 |
| ogra | well, you can trivially add mplayer to your stage-packages and use that ... | 11:12 |
| Paddy_NI | @ogra, oh I like that idea | 11:12 |
| ogra | like i do here in my wasp player https://github.com/ogra1/video-kiosk-snap/blob/master/snap/snapcraft.yaml ... https://github.com/ogra1/video-kiosk-snap/blob/master/launcher | 11:12 |
| Paddy_NI | I might actually try that now with peerflix actually | 11:12 |
| Paddy_NI | @ogra, Thank you :-) | 11:13 |
| Paddy_NI | We are getting crazy amounts of rain here, I find it quite soothing. | 11:15 |
| pedronis | Chipaca: mborzecki: as I said I don't think checking for nil in constructors is that typical | 11:23 |
| mborzecki | off to pick up the kids | 12:04 |
| zyga | I have a chaotic day, feel like is should take the day off to be fair | 12:33 |
| zyga | Sorry. I’m logged around to help with paperwork I must do in person | 12:33 |
| === ricab is now known as ricab|lunch | ||
| zyga | mborzecki: I’ll skip standup, in traffic now | 12:52 |
| pedronis | Chipaca: standup? | 13:00 |
| zyga | (Not attending now, crying baby, in traffic) | 13:01 |
| zyga | back in the office | 13:13 |
| zyga | they are shooting a film outside again | 13:13 |
| pstolowski | zyga: too bad it's not GoT ;) | 13:16 |
| zyga | pstolowski: my character would die in episode two | 13:17 |
| zyga | ;) | 13:17 |
| Chipaca | pedronis: dunno if you saw that I addressed your feedback from #6951 | 13:38 |
| pedronis | Chipaca: yes, but no, thank you, I put it back into my queue | 13:40 |
| ogra | Chipaca, with snap interfaces being deprecated, whats the replacement that will show me all available interfaces on a UC install (for GPIO or I2C i need to find the exact name, snap interfaces properly lists that) | 13:43 |
| Chipaca | wat | 13:43 |
| Chipaca | oh you mean 'snap interfaces' | 13:43 |
| Chipaca | phew | 13:43 |
| ogra | eh, yes, thats why i wrote snap interfaces :) | 13:44 |
| Chipaca | ogra: snap interfaces aren't deprecated | 13:44 |
| Chipaca | ogra: snap interfaces is deprecated | 13:44 |
| Chipaca | these two sentences are both true | 13:45 |
| ogra | lol | 13:45 |
| Chipaca | the plural is important | 13:45 |
| ogra | ok | 13:45 |
| Chipaca | :) | 13:45 |
| Chipaca | 'sanp interfaces', the command, is deprecated | 13:45 |
| ogra | well, i obviously mean the deprecated command | 13:45 |
| Chipaca | i read your original question as that plugs/slots ("interfaces") were deprecated | 13:45 |
| Chipaca | obviously | 13:45 |
| Chipaca | in retrospect | 13:45 |
| Chipaca | anyway | 13:45 |
| Chipaca | zyga: ^^^ | 13:45 |
| zyga | mmm? | 13:46 |
| zyga | haha | 13:46 |
| ogra | something like "snap connections --available-plugs" or so would be nice | 13:46 |
| Chipaca | zyga: snap interfaces for properties | 13:46 |
| === ricab|lunch is now known as ricab | ||
| Chipaca | ogra: this is specifically about the properties of the interfaces, right? | 13:46 |
| zyga | snap interfaces for which properties? | 13:46 |
| ogra | err ... --available-slots indeed, sorry | 13:46 |
| Chipaca | ogra: maybe 'snap interface --attrs'? | 13:46 |
| zyga | snap interface --attrs shows stuff | 13:47 |
| ogra | Chipaca, this is simply to find all offered slots on a UC device | 13:47 |
| zyga | but I really think we want snap <plug,slot> instead | 13:47 |
| ogra | well, i dont know the slot name and i dont know what slots are available | 13:47 |
| ogra | so i cant really hand the command a slot name | 13:48 |
| zyga | ogra: so you want smart tab completion that shows you what is available, in a way? | 13:48 |
| ogra | no | 13:48 |
| zyga | I agree it'd be nice to say snap what-can-I-connect-to <plug-or-slot> | 13:49 |
| ogra | i just want *some way* to list the available slots on a device | 13:49 |
| zyga | ogra: snap slots is that | 13:49 |
| ogra | no need for fancy tab completion | 13:49 |
| zyga | it's just not implemented | 13:49 |
| zyga | but it's agreed upon | 13:49 |
| zyga | maybe we can do a pass for .41 | 13:49 |
| ogra | ogra@stream:~$ snap interfaces|grep i2c | 13:49 |
| ogra | pi3:i2c-0 - | 13:49 |
| ogra | pi3:i2c-1 - | 13:49 |
| ogra | pi3:i2c-2 - | 13:49 |
| Chipaca | snap install zyga | 13:49 |
| Chipaca | zyga.slots | 13:49 |
| zyga | :D | 13:49 |
| ogra | something that gives me that output | 13:49 |
| zyga | Chipaca: I have one slot but it says "insert A/C" | 13:49 |
| ogra | (even unfiltered) | 13:49 |
| Chipaca | ogra: what's 'snap connections system'? | 13:50 |
| Chipaca | ogra: (at the same time maybe it's premature; interfaces isn't going away yet) | 13:50 |
| ogra | that only seems to list a subset | 13:50 |
| ogra | none of the gadget ones | 13:51 |
| zyga | ogra: it shows implicit slots | 13:51 |
| ogra | yes | 13:51 |
| zyga | ogra: it shows slots that are not associated with any installed snap | 13:51 |
| ogra | snap connections pi3 ... that works | 13:51 |
| ogra | an internal alias would be cool here "snap connections gadget" | 13:52 |
| Chipaca | ogra: also note --all (dunno if it helps, don't have fancy hardware here) | 13:52 |
| * Chipaca hugs his xeon before it gets offended | 13:52 | |
| ogra | --all also shows a subset but at least includes the gadget ones | 13:53 |
| ogra | thanks, i think i can go with that ... perhaps the "snap interfaces" error should point to some possible alternatives to get the same info | 13:54 |
| zyga | ogra: --all shows disconnected things AFAIK | 13:56 |
| ogra | seems to show connected and disconnected stuff (i cant see a pattern here what it shows/doesnt show though) | 13:57 |
| ogra | https://paste.ubuntu.com/p/GSRTXxvJ3V/ | 13:57 |
| ogra | as i said i can go with "snap connections pi3" for the particular use-case where i need to find out the interface name from a gadget ad-hoc | 13:58 |
| Chipaca | mborzecki worked on the ux of connections | 13:58 |
| Chipaca | i remember it being tricky to get right | 13:58 |
| Chipaca | (and maybe it still needs work in some cases?) | 13:58 |
| ogra | but it also means i need to know what the gadget name is ... thats why an alias might be cool here | 13:59 |
| mborzecki | iirc we discused snap slots or similar | 13:59 |
| zyga | brb | 14:00 |
| ackk | jdstrand, hi I'm using the patched snapd with support for system users you built, I have supervisord configured to run a process as daemon:daemon (which is configured in the snap as system user), but I see messages like this in log: supervisor: couldn't setuid to 1: Could not set groups of effective user | 14:00 |
| zyga | Exhausted by heat. | 14:03 |
| jdstrand | ackk: I suspect it is calling setgroups(). see privmsg | 14:03 |
| zyga | Maybe I should turn nocturnal | 14:03 |
| cachio | zyga, hey | 14:07 |
| cachio | found a problem running beta validation for amg64 http://paste.ubuntu.com/p/pzHMzjRZPG/ | 14:07 |
| cachio | runtime/cgo: pthread_create failed: Resource temporarily unavailable | 14:07 |
| ackk | jdstrand, ah, we do use a preload which overrides setgroups/initgroups, for nginx at the moment. I guess I need to do the same for squid then | 14:07 |
| mborzecki | cachio: Jun 05 21:52:38 localhost.localdomain snapd[20219]: runtime/cgo: pthread_create failed: Resource temporarily unavailable | 14:08 |
| mborzecki | Jun 05 21:52:48 localhost.localdomain snapd[20219]: SIGABRT: abort | 14:08 |
| cachio | mborzecki, yes | 14:09 |
| mborzecki | ahh that's the policy-app-consumer, the one with bandwagon of apps | 14:09 |
| cachio | mborzecki, any idea why it could be happening? | 14:11 |
| cachio | mborzecki, I have the machine here | 14:11 |
| cachio | with a debug session | 14:11 |
| ackk | jdstrand, but, this won't help with apps like supervisors trying to run other commands with a specifi user, will it? | 14:12 |
| ackk | jdstrand, I added the preload to squid but I see the same error | 14:12 |
| mborzecki | cachio: this one is interesting too: snap-repair[4812]: runtime/cgo: pthread_create failed: Resource temporarily unavailable | 14:13 |
| mborzecki | cachio: what does ps -efT | wc -l show? | 14:14 |
| cachio | 112 | 14:14 |
| cachio | mborzecki, | 14:14 |
| jdstrand | ackk: there should be a policy violation in the journal, what is it? | 14:15 |
| ackk | jdstrand, dmesg or journalctl? | 14:20 |
| ackk | jdstrand, I don't see any | 14:21 |
| jdstrand | ackk: journalctl | 14:21 |
| jdstrand | well, really either | 14:21 |
| ackk | jdstrand, no denial | 14:21 |
| jdstrand | ackk: are you using snappy-debug? | 14:22 |
| ackk | no | 14:22 |
| ackk | jdstrand, how does that work? | 14:22 |
| jdstrand | ackk: sudo snap install snappy-debug ; sudo journalctl --output=short --follow --all | sudo snappy-debug | 14:23 |
| jdstrand | ackk: that will tail the journal. then you exercise your application | 14:23 |
| jdstrand | ackk: and it will pop out denials with suggestions if there are logged policy violations | 14:23 |
| jdstrand | ackk: one thing it does is turn off kernel rate limiting | 14:24 |
| jdstrand | which might be why you aren't seeing a denial | 14:24 |
| ackk | ah, I see it now | 14:24 |
| jdstrand | what is the denial? | 14:24 |
| ackk | jdstrand, https://paste.ubuntu.com/p/xbbC2pJDbF/ | 14:25 |
| jdstrand | ackk: what is the name of the snap command invocation? maas.what? | 14:26 |
| ackk | jdstrand, it's a daemon maas.supervisord | 14:26 |
| * jdstrand notes he has a meeting in 4 minutes (coincidentally on this PR) | 14:26 | |
| ackk | sorry, maas.supervisor | 14:26 |
| jdstrand | ackk: what is the output of grep setgroups /var/lib/snapd/seccomp/bpf/snap.maas.supervisor ? | 14:27 |
| ackk | $ grep setgroups /var/lib/snapd/seccomp/bpf/snap.maas.supervisor.src | 14:27 |
| ackk | # allow use of setgroups(0, NULL) | 14:27 |
| ackk | setgroups 0 0 | 14:27 |
| ackk | setgroups32 0 0 | 14:27 |
| ackk | jdstrand, ^ | 14:27 |
| jdstrand | ackk: ok, so something with your LD_PRELOAD isn't working | 14:28 |
| ackk | jdstrand, well supervisor doesn't have LD_PRELOAD | 14:28 |
| jdstrand | ackk: setgroups needs to be called with setgroups(0, NULL) | 14:28 |
| ackk | jdstrand, does it also need it? | 14:28 |
| ackk | oh ok | 14:28 |
| ackk | then I'll add it there too | 14:29 |
| jdstrand | ackk: *any* setgrroups denial needs the preload | 14:29 |
| * jdstrand -> meeting | 14:29 | |
| ackk | jdstrand, cool, thanks | 14:30 |
| ackk | ah, and now squids actually fails to create the shm files | 14:32 |
| ackk | I guess I need snapcraft-preload after all | 14:32 |
| ogra | hmm, is there something with the store today ... i see a lot 503 errors why installing snaps (they dont show up on the second install attempt) | 15:05 |
| ogra | s/why/while/ | 15:05 |
| Chipaca | woo, woo | 15:06 |
| Chipaca | cohort pr #N is in, #(N+1) is up for review | 15:06 |
| Chipaca | woo | 15:06 |
| Chipaca | now running a little late for my train but, woo :) | 15:06 |
| roadmr | 🚂 | 15:06 |
| roadmr | ogra: https://status.snapcraft.io/ 💚 | 15:07 |
| Chipaca | pedronis: thank you for the review :) | 15:07 |
| ogra | roadmr, well ... Download snap "chromium-mir-kiosk" (32) from channel "edge" (received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/pKicqh8BMdA6Y6jbtWYBdI2QwhRH4v6T_32.snap?token=1559847600_743804ce162b2329f8ec18078bdcdd62d67273c6) | 15:08 |
| roadmr | ogra: if you're consistently seeing 503s and you could turn on snapd debugging and shoot me some logs of what the store is saying, I'd be grateful - can look deeper if I have that info | 15:08 |
| roadmr | ogra: oh! perfect! let's see | 15:08 |
| ogra | this took three attempts ... third one was the charm and it installs now | 15:08 |
| roadmr | ogra: oh that's the problem - you need juju if you want to install charms 👅 | 15:08 |
| ogra | lol | 15:08 |
| Chipaca | pedronis: dunno if you want to add this to your queue or not (it's low impact tbh): "overlord/snapstate, & fallout: give Install a *RevisionOptions" #6961 https://github.com/snapcore/snapd/pull/6961 | 15:09 |
| * Chipaca goes to catch that train | 15:09 | |
| ahasenack | ogra: I also got a couple of 503s today | 15:24 |
| ahasenack | and also worked on the third attempt only | 15:24 |
| roadmr | ahasenac, ogra: hey sooo.. yes, looks like our cdn provider is having some trouble, that explains your failure. We'll post an update in the forum/status page shortly | 15:24 |
| ogra | well, it still works ... just needs some run-on :) | 15:25 |
| roadmr | ogra: we've kicked the offending server, things should be copacetic now. Thanks for the report! | 15:42 |
| ogra | thanks for fixing ! | 15:44 |
| === pstolowski is now known as pstolowski|afk | ||
| jdstrand | pedronis: oh, I said next week I would work on the snap_daemon PR, but I forgot I will be at the snapcraft summit | 17:41 |
| zyga | a newline in the wrong spot of debian/rules makes one funny debugging session as to WTF | 18:04 |
| zyga | specifically the *first* line when /bin/sh executes a makefile | 18:04 |
| albertosottile | jdstrand: Hi, we read your last comment about the Syncplay classic confinement request... we honestly do not believe that we will add <<more functionality in the realm of taking “input from over the internet to run arbitrary commands”>> in the foreseeable future. So, what should we do now? | 18:30 |
| stgraber | jdstrand: hey there, just moved lxd-demo-server from being an old core16 snap to being a snap using the core18 base and looks like this somehow triggered a manual review? | 18:39 |
| stgraber | jdstrand: human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (daemon, lxd) | 18:39 |
| stgraber | jdstrand: so looks like it's because it's using the lxd interface (normal as it drives LXD) but that's not a change from any of the previous revisions, so a bit confused as to why this is getting flagged now | 18:40 |
| jdstrand | albertosottile: comment to that effect in the topic, then pedronis will make the final call | 18:40 |
| jdstrand | albertosottile: and hello to you too :) | 18:41 |
| albertosottile | jdstrand: We will, thanks :) | 18:41 |
| jdstrand | stgraber: this doesn't have to do with the move to core18 but new tests in the review-tools. I'll grant the snap decl for you | 18:42 |
| stgraber | jdstrand: thanks, so I guess it's just because I didn't upload that one in a while then :) | 18:42 |
| jdstrand | stgraber: yeah, exactly | 18:43 |
| jdstrand | stgraber: ok done. both now pass automated review. you'll need to release them to a channel | 18:46 |
| stgraber | jdstrand: done, thanks | 18:47 |
| jdstrand | np | 18:50 |
| zyga | jdstrand: I'm sorry about missing the call today, I was tired and frustrated by chaotic home schedule and the heat | 19:05 |
| jdstrand | zyga: no worries. I marked you optional and figured you simply opted out :) | 19:18 |
| jdstrand | zyga: hope things are getting better | 19:18 |
| zyga | jdstrand: I'm looking forward to coldness of canada | 19:18 |
| jdstrand | zyga: hehe :) | 19:21 |
| roadmr | zyga: the weather is amazing here, temps should be well above 20C next week, check the 7-day forecast: https://weather.gc.ca/city/pages/qc-147_metric_e.html (oh well, rainy tuesday) | 19:21 |
| jdstrand | zyga: it's been pretty warm and humid here too | 19:22 |
| zyga | roadmr: thank you!, looking | 19:22 |
| zyga | temps here are looking at close to 30 all the time | 19:23 |
| zyga | and my office behaves like a small oven with me inside | 19:23 |
| roadmr | zyga: ouch. We'll be there in about a month; July/August can be uncomfortably warm/humid | 19:24 |
| roadmr | summer is a crazy thing :) | 19:24 |
| jdstrand | roadmr: hmm, it that my recent review-tools builds are stuck in 'Uploading build': https://code.launchpad.net/~myapps-reviewers/+snap/review-tools | 19:59 |
| roadmr | jdstrand: maybe due to this morning's store trouble? | 19:59 |
| roadmr | oh this is happening right now - that's odd | 20:00 |
| jdstrand | I'm not aware of that trouble... if it's just catching up, that's fine. fyi since it is unusual | 20:00 |
| roadmr | jdstrand: right, there was some network saturation, let's give them a few and see if they catch up | 20:01 |
| roadmr | jdstrand: I see some of the stuck uploads finally uploaded - things may just be sluggish :/ | 20:08 |
| ijohnson | roadmr: fyi I have had snaps stuck in ci jobs for the past 2.5 hours trying to upload, so whatever the issue was this morning it seems to still be happening | 20:09 |
| roadmr | ijohnson: oh thanks.... where is this ci you speak of? 🤔 | 20:10 |
| ijohnson | uhh you mean physically? I think actually it's somewhere near you in Canada, it's a jenkins server the Linux Foundation uses | 20:10 |
| roadmr | ijohnson: well I meant whether it was e.g. travis | 20:11 |
| ijohnson | oh haha well no it's a custom jenkins server | 20:11 |
| ijohnson | roadmr: see for example https://jenkins.edgexfoundry.org/view/Snap/job/edgex-go-snap-edinburgh-stage-snap/10/console | 20:11 |
| roadmr | ijohnson: ah :) | 20:12 |
| roadmr | ijohnson: oh I see what happened - looks like revision 935 of that snap failed to complete auto-review, so that upload held the queue, subsequent uploads are awaiting review as well | 20:14 |
| roadmr | ijohnson: I've retriggered 935; btw the timing on 935 matches when we were having bandwidth problems | 20:14 |
| ijohnson | roadmr: hmm, but previously even when a previous snap was stuck in review snapcraft would at least stop and explain that it failed due to the queue | 20:15 |
| ijohnson | roadmr: are you saying that because the revision failed with auto-review during the bandwidth problem time period this new upload got stuck? | 20:16 |
| roadmr | ijohnson: yep, that could be it. btw 935 just passed, so the rest are being processed now | 20:16 |
| ijohnson | roadmr: ack thanks, btw any idea why they failed auto-review? | 20:17 |
| roadmr | ijohnson: probably network-related; e.g. the worker unit that runs the autoreview tries to download the snap, but it was slow/faily at that time, so it barfed, then retried... etc. They do a limited number of retries before giving up | 20:18 |
| ijohnson | ok that makes sense, because I don't think we added anything new to that revision that would have failed review | 20:19 |
| ijohnson | thanks for explaining | 20:19 |
| roadmr | yep, this was "task failed to complete because I couldn't download the snap", compare to "task succeeded but obtained a failed review from the review tools" | 20:19 |
| ijohnson | 👍 | 20:21 |
| === Greyztar- is now known as Greyztar | ||
| === ackk_ is now known as ackk | ||
| === ackk is now known as ack | ||
| === ack is now known as Guest15910 | ||
| === ackk is now known as ack` | ||
| === ack` is now known as ackk | ||
| === ackk is now known as ack` | ||
| === ack` is now known as ackk | ||
| === ackk is now known as ack` | ||
| === ack` is now known as ackk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!