[12:13] <LaserJock> so I fired off an "Edubuntu is totally what you want" email too
[12:14] <ogra> i had a mail from the "institute for german unemployees munich" today ... they use edubuntu everywhere and wanted to know if its leagal to use arial and verdana :)
[12:14] <crimsun> I hope you added the disclaimer that you're involved in it :)
[12:14] <crimsun> that's a pretty important clarification
[12:14] <crimsun> (to LaserJock )
[12:15] <LaserJock> crimsun: well, I'm just on the Edubuntu Council, that's not really "involved" ;-)
[12:15] <ogra> haha
[12:15] <crimsun> except you have source code going into it
[12:15] <ogra> crimsun, by the way ...
[12:15] <crimsun> ogra: hi
[12:15] <ogra> i have weird probs with an usb headset here
[12:15] <crimsun> dapper or edgy?
[12:15] <ogra> a pretty standard logitech 250 in edgy
[12:16] <ogra> it plays sound for about 1min ...
[12:16] <ogra> then it just gets quiet
[12:16] <crimsun> is there any weird spew in ``dmesg |tail''?
[12:16] <ogra> if i use xmms with alsa output it works fine
[12:16] <ogra> nope, nothing in any logs
[12:17] <ogra> if i use ekiga or totem it doesnt ...
[12:17] <ogra> looks very much like gstreamer-alsa ...
[12:17] <crimsun> yes
[12:17] <crimsun> that was going to be my suggestion
[12:17] <crimsun> unfortunately I have not looked a gst-alsa
[12:17] <crimsun> a->at
[12:17] <ogra> oki
[12:18] <crimsun> if you can get debug spew from gst, that would rock
[12:18] <crimsun> please report a bug against it, sub me, and I'll take a look
[12:18] <ogra> is there any option i can set or something ?
[12:18] <ogra> (to get debug output)
[12:19] <crimsun> there's an environment variable iirc
[12:19] <crimsun> otherwise, http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-checklist-debug.html
[12:19] <crimsun> level 3 should suffice
[12:19] <crimsun> seb would know
[12:20] <ogra> yay, thanks
[12:27] <crimsun> np
[01:37] <Amaranth> ogra: i've got the init stuff figured out, i think
[01:38] <Amaranth> ogra: fixing up debian/init.d.ex renaming it to debian/init.d will do the right thing, won't it?
[01:38] <LaserJock> good morning jsgotangco
[01:40] <ogra> Amaranth, i susally use dh_installinit, no idea how cdbs handles that
[01:40] <ogra> *usually
[01:40] <Amaranth> i'll soon see
[01:40] <Amaranth> setting up the control file now, then i think i just need to make willowng.files and willowng-config.files
[01:40] <ogra> and you should call update-rc.d in the postinst with the runlevels you want to install to
[01:41] <Amaranth> i have no idea where to install it to
[01:41] <ogra> what, the initscript ?
[01:41] <Amaranth> i'm guessing i have to do a postrm thing to run update-rc.d again
[01:42] <Amaranth> yeah
[01:42] <Amaranth> what runlevel and such, i mean
[01:44] <jsgotangco> good morning
[01:44] <ogra> add that to the postinst: update-rc.d willowng start 50 2 3 4 5 . stop 50 0 1 6 . >/dev/null
[01:47] <Amaranth> ok
[01:49] <ogra> argh, mdz just sent the UVF announcement i thought we'd have the day tomorrow ... gamned
[01:50] <ogra> *damned too
[01:50] <jsgotangco> yeah
[01:51] <jsgotangco> 7UTC meeting *shudder*
[01:51] <ogra> 7UTC is fine :)
[01:52] <jsgotangco> sure that's only 10am here :D
[02:16] <rodarvus> 7UTC is 4UTC here
[02:16] <rodarvus> freaking early :)
[02:18] <jsgotangco> hah
[02:22] <mdz> rodarvus: 7UTC is 4UTC? now that's a weird time zoen
[02:22] <mdz> zone
[02:23] <rodarvus> mdz: UTC-3 (America/Sao_Paulo)
[02:24] <rodarvus> actually, the new meeting times are quite bad for me, but they seem to be very popular with everyone else, so rearranging meeting times its surely not worth the trouble
[02:26] <mdz> rodarvus: UTC is UTC no matter where you are :-)
[02:26] <mdz> rodarvus: you and BenC get the worst of it on this schedule I think
[02:27] <rodarvus> infinity probably is in the same situation as we are too
[02:27] <jsgotangco> yep
[02:32] <bimberi> How the Marketing Team came up with its meeting time (19UTC) - https://wiki.ubuntu.com/MarketingTeam/Meetings (at the bottom)
[02:33] <jsgotangco> bimberi: dev teams rotate the meeting times
[02:33] <jsgotangco> since its so spread between continents
[02:33] <jsgotangco> so do other big teams
[02:34] <jsgotangco> the table is not new, it was an LP team initiative =)
[02:36] <bimberi> jsgotangco: i'm not saying it is - and it still has value to find the best rotation times
[02:36] <jsgotangco> yep
[02:38] <bimberi> (although it was the first place i saw it ;-)  )
[02:42] <jsgotangco> its a very effective table really
[02:42] <jsgotangco> most of the time we don't realize that we live in timezones way way apart
[03:13] <Amaranth> ok i suck at making packages
[03:17] <Amaranth> ogra: can you pull from http://dev.realistanew.com/willowng and see what i'm doing wrong?
[03:18] <bddebian> Heya
[03:18] <Amaranth> hey
[03:18] <bddebian> Hi Amaranth
[03:19] <Amaranth> crap my meeting calendar is out of date
[07:26] <mhz> jsgotangco: ping
[07:26] <jsgotangco> hi
[07:26] <mhz> jsgotangco: hi there.
[07:26] <jsgotangco> whats up
[07:26] <mhz> jsgotangco: if I say that an ideal relation of an edubuntu env. (considering my reality of server)
[07:26] <mhz> is 1:7
[07:27] <mhz> 1 server for 7 clients
[07:27] <jsgotangco> err?
[07:27] <jsgotangco> ahhh
[07:27] <mhz> hehehe
[07:27] <jsgotangco> it really depends on your server
[07:27] <mhz> yup
[07:27] <jsgotangco> have you seen jim's ltsp sizing?
[07:27] <mhz> "if I say.."
[07:28] <mhz> Can i call each 1:7 environment a 'node' ?
[07:28] <mhz> and a lab can be made of many 'nodes'?
[07:28] <mhz> made = set
[07:28] <mhz> jsgotangco: nope, I have not yet
[07:29] <mhz> jsgotangco: ?
[07:29] <jsgotangco> hmmm
[07:29] <jsgotangco> sure
[07:30] <jsgotangco> you call each client a node
[07:30] <jsgotangco> much like how you call a network connection is
[07:30] <mhz> hmm, then if each client is a 'node', then what would you call '7 clients per 1 server'
[07:31] <jsgotangco> a solution?
[07:31] <jsgotangco> hehehe
[07:31] <mhz> I need to be specific because when I have said "Edubuntu is suitable for your lab"
[07:32] <mhz> they say, oh, well, my lab is about 40 pc's
[07:32] <mhz> then I gotta tell them "depending on your server" and etc
[07:32] <mhz> so, i wanna make my life simple from now on
[07:33] <mhz> "If you have this server, then you can have excellent performance using no more than 7 to 9 clients"
[07:33] <jsgotangco> just say thin clients?
[07:33] <mhz> BUT, yes "you can have on lab composed of many 1:7 environements"
[07:34] <mhz> but again, I still have no clue what to call this 1:7 env., man
[09:07] <crimsun> 'afternoon/'evening
[09:09] <ogra> moin :)
[09:10] <jsgotangco> hey
[10:06] <crimsun> ogra: hacky workaround if you need to use usb headset /right now/: invoke gstreamer-properties and change both sink & source to oss
[10:07] <crimsun> ogra: (if I think you're using ekiga or whatnot?)
[10:07] <ogra> will try
[10:09] <crimsun> sorry, it's 4 AM and I'm trying to proof a dissertation
[10:10] <ogra> dont worry about my bugs then, i'll find my way around :)
[10:11] <crimsun> well, I'm definitely devoted to making sure *buntu rocks for audio, so...
[10:11] <ogra> well, its early edgy time :)
[10:11] <ogra> bugs are expected :)
[10:12] <crimsun> are you using ekiga?
[10:12] <ogra> yup
[10:12] <ogra> we use it all over the company now
[10:12] <crimsun> hmm, there's a bug report against alsa-lib where the user says that edgy's ekiga version crashes for him
[10:13] <ogra> works fine here ....
[10:13] <ogra> i had no probs with ekiga itself so far
[10:13] <crimsun> ok, try using oss for GSt's sink and source
[10:13] <crimsun> it will not play nicely with alsa's dmix, however
[10:16] <ogra> hmm
[10:16] <ogra> ekiga itself only offers alsa support internally it seems
[10:17] <ogra> nope, still dies
[10:18] <crimsun> ah, if it only supports ALSA internally then setting GSt won't be of much use
[10:19] <Amaranth> ogra: one small bug with my package (both packages own /usr/share/willowng/willowng.glade) :/
[10:19] <Amaranth> i need to get the willowng package to create an empty /usr/share/willowng if it doesn't exist
[10:19] <Amaranth> actually, i'll just include an empty training.db
[10:20] <crimsun> ogra: ok, then I'll wait for debug output
[10:20] <ogra> /usr/share/willowng should work with a .dirs file in the debian dir
[10:20] <ogra> /usr/share/willowng/willowng.glade should only be in the gui package, no ?
[10:20] <Amaranth> yeah
[10:21] <ogra> so dont install it in the backend :)
[10:22] <Amaranth> what should i put in willowng.dirs to get it to make a /usr/share/willowng/?
[10:22] <ogra> usr/share/willowng/ i think
[10:24] <Amaranth> didn't work :/
[10:24] <Amaranth> i'll just include a training.db
[10:25] <Amaranth> i plan on eventually including some initial training anyway
[10:25] <ogra> just be careful with the content ;)
[10:26] <Amaranth> i can't include inappropriate words in the training.db?
[10:27] <ogra> sure you can
[10:27] <ogra> just dont add something thats not binary :)
[10:27] <Amaranth> it doesn't have any images or full webpages or anything
[10:27] <Amaranth> just words
[10:27] <ogra> yep
[10:31] <ogra> brb, reboot
[10:45] <Amaranth> brb, reboot (stupid sound)
[10:50] <Amaranth> hrm, long restart for ogra
[11:17] <Amaranth> ogra: http://dev.realistanew.com/releases/willowng/0.1/deb-src/
[11:19] <ogra> Amaranth, echo 'X-Ubuntu-Gettext-Domain=willowng' >> debian/tmp/usr/share/applications/willowng.desktop
[11:20] <ogra> whats that for ?
[11:20] <Amaranth> langpack translation stuff
[11:20] <ogra> you could add it to the .desktop.in file , no ?
[11:20] <Amaranth> it's ubuntu specific
[11:20] <ogra> and ? other distros will just ignore it
[11:20] <ogra> we have many upstreams that add it for us
[11:21] <Amaranth> next release :)
[11:21] <ogra> packge looks fine to me ...
[11:22] <ogra> lets see if it builds :)
[11:22] <Amaranth> heh
[11:22] <Amaranth> i built it in pbuilder once
[11:22] <Amaranth> and installed it on dapper and ran it
[11:24] <ogra> E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
[11:24] <ogra> ARGH !!!
[11:24] <Amaranth> ack
[11:36] <Amaranth_> oh suspend, why must you tease me?
[11:39] <ogra> well you *have* suspend ... be happy :)
[11:40] <crimsun> it's faster for me to shutdown and boot than to suspend-to-disk and resume
[11:42] <ogra> but suspend to ram rules :)
[11:42] <ogra> at least on this ibook (if it works)
[11:42] <Amaranth> if i hibernate i get a snowy screen on resume (like a TV with no reception)
[11:43] <Amaranth> if i suspend-to-ram it appears to do something for about 10 seconds then stops with the machine still on and no way of getting back to anything
[11:43] <Amaranth> this all worked when i first installed dapper (-23 kernel) :(
[11:43] <Amaranth> it worked on at least the -25 kernel for awhile too, i have no idea what changed
[11:50] <jsgotangco> gahh!! the power went out!
[11:51] <jsgotangco> ogra: it went out for more than an hour ;)
[11:51] <jsgotangco> there's a typhoon here
[11:51] <jsgotangco> haha
[12:26] <RichEd> ogra: ping
[12:26] <ogra> RichEd, pong
[12:27] <RichEd> ogra: what is your suggested install order for my Ubuntu / Edubuntu on top of XP ...
[12:28] <RichEd> ogra: and what help resources should i refer to ... (assume i am a newbie user)
[12:28] <ogra> doesnt matter, pick as you like
[12:29] <ogra> in case you want the classroom server install (to demo ltsp or something) http://www.edubuntu.org/gettingstarted
[12:29] <ogra> else just pich the workstation option in the menu
[12:29] <ogra> *pick
[12:29] <RichEd> tx ...
[12:29] <ogra> the only glitch you might have is the partitioning
[12:30] <ogra> the rest of the install process will just work :)
[12:30] <RichEd> okay tx.
[12:31] <ogra> the stuff listed on the gettingstarted page will be adressed in edgy (no more editing of dhcp config files etc)
[12:32] <RichEd> i'll read through it all before i start tomorrow ... will ask questions if i have any ...
[12:32] <ogra> ok ;)
[12:33] <jsgotangco> its much easier to have XP first
[12:33] <jsgotangco> imo
[12:33] <jsgotangco> besides its already there
[12:33] <ogra> jsgotangco, yes, we discussed that yesterday, thats why RichEd said on top of XP i guess ;)
[12:33] <RichEd> jsgotangco: new notebook, had to pay for XP :)
[12:34] <jsgotangco> heh we could buy a notebook here with no OS
[12:34] <RichEd> am keeping XP for demo purposes, but want to dig into how to buy h/w without paying for throw-way os
[12:34] <ogra> Amaranth, hmm, we'll need a reboot notification for dbus
[12:34] <ogra> Introspect error: The name com.ubuntu.WillowNG was not provided by any .service files
[12:34] <RichEd> found only 1 dealer in SA who will sell me a DOS notebook ...
[12:35] <jsgotangco> wow
[12:35] <RichEd> was saying to ogra that 150 euro (his discount in germany) is a weeks wages for a teacher in SA or 1 months room rental for a uni student
[12:35] <jsgotangco> the only ones with XP built in here are the big brands but even IBM sells a DOS notebook here
[12:36] <jsgotangco> 1 here is 60Pesos and the minimum wage here in the city is only 300Pesos
[12:36] <RichEd> Mr G has wrapped up Sotuh Africa ... is it the commercial gateway up into Africa ... so he spreads his influence & wicked stories very deeply
[12:37] <RichEd> South Africa
[12:37] <jsgotangco> so a typical good laptop model would be around 800
[12:38] <RichEd> Even for educational discount into schools via MS Government Agreement ... Office is Free, Encarta is Free, but must pay for OS "becuase giviing away an OS is a bad example & precedent"
[12:38] <jsgotangco> interesting
[12:38] <jsgotangco> over here BSA-led raids are pretty common lately
[12:40] <RichEd> I have just left HP ... they were talking about providing Ubuntu Notebooks (as in Germany) but due to lack of internal support from HP, they have gone with Linspire
[12:40] <ogra> Amaranth, the DAEMON= line in the initscript is wrong (poins to /usr/bin instead of /usr/sbin)
[12:41] <ogra> Amaranth, also /usr/sbin/willowng needs to return
[12:42] <ogra> else the init script just hangs at Starting WillowNG:
[01:00] <RichEd> highvoltage: hey there :) just sent you a mail
[01:09] <ogra> sooo, it seems firefox has a hard dependency on the ubuntu firefox icontheme now ...
[01:09] <highvoltage> RichEd: ok
[01:11] <ogra> which adds 1.2M of icon crap we dont use to the CD
[01:11] <ogra> *sigh*
[01:11] <jsgotangco> okayyy
[01:12] <rodarvus> can't this dependency be made optional?
[01:12] <highvoltage> RichEd: which account?
[01:13] <ogra> rodarvus, see -devel
 OIC.  Without that if you launch firefox it will fail to start.
[01:13] <ogra> we *could* ship a crippled firefox (which is only needed as dependency for epiphany anyway)
[01:13] <ogra> but if users want to use it, they will complain
[01:15] <RichEd> @ubuntu.com
[05:28] <cbx33> hey guys how easy is it to run gnome and fluxbox side by side?
[05:28] <cbx33> i mean so I can logout and switch to another
[08:23] <LaserJock> ogra: is the bashism a problem with the move to that other shell (can't think of the name off the top of my head)?
[08:23] <ogra> dash
[08:24] <ogra> yes that a problem
[08:24] <LaserJock> right
[08:24] <ogra> ltsp-build-client fails currently, that will break the CD
[08:24] <LaserJock> I didn't quite understand the dash/bash thing
[08:24] <LaserJock> so dash is used by the system, but bash by users?
[08:25] <ogra> yep
[08:25] <ogra> /bin/sh points to dash now
[08:25] <ogra> but users have /bin/bash in /etc/passwd
[08:25] <ogra> so as long as you log in you use bash ... and its builtins
[08:26] <LaserJock> that's somewhat confusing
[08:26] <ogra> but if a system script runs it uses /bin/sh ... which points to dash a ... with no builtins, way smaller footprint and ages faster
[10:44] <EmxBA> hi!
[10:45] <LaserJock> hi EmxBA
[10:45] <EmxBA> hi LaserJock, anything new here connected to the "Schoolkids + Edubuntu cooperation" project'
[10:48] <LaserJock> not that I know, but I mostly lurk so it could have gone by my radar
[10:48] <EmxBA> :) ok
[10:49] <EmxBA> I am waiting for bluekuja to appear 'cause i need to talk to *her* and the rest of you
[10:50] <LaserJock> "her"? I think he's a he
[10:51] <EmxBA> *he* sorry
[10:51] <EmxBA> is it andrea? or something like that?
[10:51] <LaserJock> yeah
[10:51] <LaserJock> hard to tell with names
[10:52] <EmxBA> np


[05:10] <mborzecki> morninb
[05:10] <mborzecki> morning
[06:29] <mborzecki> mvo: good morning
[06:30] <mvo> mborzecki: good morning
[06:32] <mborzecki> mvo: do we need https://github.com/CanonicalLtd/subiquity/pull/770 and https://github.com/snapcore/snapd/pull/8661 for beta?
[06:32] <mup> PR CanonicalLtd/subiquity#770: console-conf: always run when triggered for the chooser <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/770>
[06:32] <mup> PR #8661: configcore: add "service.console-conf.disable" config option <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[06:32] <mvo> mborzecki: it's not beta critical
[06:32] <mvo> mborzecki: I will not even backport it :)
[06:33] <mborzecki> mvo: ah ok
[06:45] <zyga> Good morning
[06:47] <mborzecki> zyga: hey
[06:50] <mvo> hey zyga
[06:59] <pstolowski> morning
[07:01] <ackk> good morning, I'm seeing a weird behavior with a core20-based snap. If I call the snapraft-runner script in a configure hook, it segfaults
[07:01] <ackk> it worked fine with core18
[07:09] <mborzecki> pstolowski: hey
[07:11] <ackk> oh, actually I might know what's the issue
[07:16] <ackk> have snap hook always been duplicated in snap/hooks and meta/hooks ?
[07:20] <mborzecki> hmm google:ubuntu-18.04-64:tests/main/mount-ns:reboot failing?
[07:21] <zyga> mborzecki: how?
[07:22] <mborzecki> zyga: https://paste.ubuntu.com/p/NSHS5rHk34/
[07:22] <mborzecki> look slike / is moutned with different options and efivars is present
[07:22] <zyga> Are you up to date in relation to master?
[07:23] <zyga> This changed yesterday to match the new image
[07:23] <mborzecki> ah ok, i need to update tht branch then
[07:24] <zyga> ackk: hooks must be in meta/hooks
[07:24] <zyga> Perhaps snapcraft is copying them?
[07:25] <ackk> zyga, yeah I mean you put them in snap/hooks for snpcraft to find them right?
[07:25] <zyga> I don’t really know, 90% of my snaps are hand made
[07:26] <ackk> heh
[07:28] <ackk> ah yeah, it seems they've always been in both places.
[07:29] <ackk> maybe snapcraft could not populate snap/hooks?
[07:29] <zyga> That does seem weird
[07:38] <mup> PR snapd#8667 opened: interfaces/fwupd: allow bind mount to /boot related on core <Created by woodrow-shen> <https://github.com/snapcore/snapd/pull/8667>
[07:43] <ackk> zyga, IIUC snapcraft copies snap/ as-is, with the exception of snap/local
[07:57] <mup> PR snapd#8663 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8663>
[08:05] <mup> PR snapd#8664 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.45 <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8664>
[08:05] <mup> PR snapd#8665 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.44 <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8665>
[09:04] <pstolowski> xnox: hey
[09:09] <ackk> mvo, hi, to confirm, there's currently no way via sudo/su to drop from root the snap_daemon user, right?
[09:11] <mvo> ackk: hey, not sure I understand the question, can you please give me a little bit more context? what do you want to archive exactly. you are root and drop to the snap daemon-user inside the snap?
[09:13] <ackk> mvo, yes, I want to run a process as daemon user, ideally from a bash script. afaict sudo/su don't work in the snap
[09:15] <ackk> mvo, I thought we did that in maas, but actually we have a python script that does that
[09:15] <mvo> ackk: I'm out of my depth here unfortunately, I think we need jdstrand to help if you can use su/sudo inside a snap to drop from root to the snap-daemon user
[09:15] <ackk> mvo, ok, np, thanks
[09:43] <pstolowski> zyga: what was the PR you wanted reviewed to unblock you (mentioned yesterday in the standup)?
[09:43] <zyga> pstolowski: let me find it
[09:43] <zyga> https://github.com/snapcore/snapd/pull/8566
[09:43] <mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
[09:44] <pstolowski> k
[09:47] <mborzecki> wow, https://github.com/snapcore/snapd/pull/8650 is green
[09:47] <mup> PR #8650: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8650>
[09:51] <ijohnson> ackk: if you want to drop privs to snap_daemon from a shell script you need to use one of the tricks mentioned in "Usage considerations" on https://snapcraft.io/docs/system-usernames
[09:53] <ackk> ijohnson, ah, thanks
[09:53] <zyga> re
[09:53] <zyga> sorry, helped wife with lucy for a moment
[09:54] <zyga> mborzecki: makes all the test fixing worth it :)
[10:00] <zyga> pstolowski: I removed the hacks around /home/ubuntu from https://github.com/snapcore/snapd/pull/8633 it now simply ignores it
[10:00] <mup> PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
[10:00] <zyga> pstolowski: also extended tests to show this
[10:00] <pstolowski> thanks
[10:00] <zyga> pstolowski: and extended help to show the invariants
[10:00] <zyga> pstolowski: I think it's good now
[10:00] <zyga> and rebased on master to get all the fixes
[10:01] <zyga> I didn't do the extra test suite as that's somewhat more work
[10:12] <pstolowski> zyga: naive question to the lock PR
[10:12] <zyga> looking
[10:13] <zyga> pstolowski: as in when the lock file exists but is empty?
[10:13] <zyga> pstolowski: if you look at unlock() that's exactly an unlocked lock :)
[10:13] <zyga> pstolowski: we truncate to unlock
[10:13] <pstolowski> zyga: exists & not-empty
[10:13] <zyga> if it exists and is non-empty then it is locked
[10:14] <pstolowski> zyga: yes and if reboot happens it remains non-empty, is it going to ihibit snap run?
[10:14] <zyga> perhaps the confusing aspect is that there are two locks in one: the contents of the file and the flock protecting reading/writing the contents
[10:14] <zyga> yes
[10:14] <zyga> pstolowski: that's the fature
[10:14] <zyga> *feature
[10:14] <zyga> it can very much happen that you reboot to uninhibit
[10:14] <pstolowski> zyga: is there a guarantee it gets released?
[10:14] <pstolowski> (i'm missing bigger picute)
[10:14] <pstolowski> *picture
[10:14] <zyga> pstolowski: it's not a part of this branch
[10:15] <zyga> pstolowski: it's the same question as link/unlink snap
[10:15] <zyga> pstolowski: those are just the primitives
[10:15] <zyga> pstolowski: and the primitives do allow having a lock for indefinite amount of time
[10:15] <pstolowski> ok. my only concern is that this interrupts a snapd op in flight and we leave snap run unusable for given snap
[10:15] <pstolowski> but yes, i can see it belongs elsewhere to handle this
[10:15] <zyga> pstolowski: if you look at the usage of this in another PR
[10:15] <zyga> I currently inihibit before unlinking
[10:16] <zyga> and uninhibit after linking
[10:16] <zyga> though my preference is to expand that period so we inhibit when we decide to refresh
[10:16] <zyga> and uninhibit when refresh is either done or aborted
[10:20] <ijohnson> mborzecki: have you seen https://bugs.launchpad.net/snapd/+bug/1878505 ?
[10:20] <mup> Bug #1878505: recovery chooser doesn't trigger on rpi with core20 <snapd:New> <https://launchpad.net/bugs/1878505>
[10:21] <mborzecki> ijohnson: hm not surprised really, it's probably a usb keyboard, so it may come up whenever during the boot
[10:22] <ijohnson> mborzecki: yes he mentioned it was a usb keyboard, in fact he has multiple attached
[10:22] <mborzecki> ijohnson: probably after loadign the modules, and udev has to settle and create input devices by the time the trigger detection runs
[10:22] <ijohnson> mborzecki: so perhaps the chooser should gain a systemd depends on systemd-modules-load and systemd-udev-settle (or whatever it's called) ?
[10:23] <mborzecki> ijohnson: the post-pivot one runs after snapd seeding is done iirc
[10:23] <ijohnson> ah I see
[10:23] <mborzecki> ijohnson: what i would expect to work pretty well is using gpio-keys in dtb, setting up one gpio to emit KEY_1
[10:25] <pstolowski> quick errand, bbiab
[10:26] <mup> PR snapd#8650 closed: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8650>
[10:33] <mborzecki> ijohnson: added a note, not sure udev settle would fix that reliably tho
[10:33] <mborzecki> it's a usb stack after all :/
[10:38] <zyga> brb
[10:44] <ijohnson> mborzecki: ack thanks for looking at it
[10:45] <mup> PR snapd#8668 opened: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
[10:45] <ijohnson> pedronis: mvo: I opened https://github.com/snapcore/snapd/pull/8668 which is the first step to cross-check, complete with some tests, not sure if y'all will want more tests or not, it's already at ~1k lines
[10:45] <mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
[10:46] <pedronis> ijohnson: thanks I will look, we would also like to move partition somewhere else before 1.0, so need also to think whether this bits belong here or not
[10:47] <ijohnson> ok
[10:47] <pedronis> *these bits
[10:50] <mvo> ijohnson: thanks
[10:51] <zyga> re
[10:52] <zyga> TIL, well, not T but recently, gparted cannot resize FAT16
[10:52] <zyga> those small boot partitions, you need some hand holding and remaking from scratch to grow them
[10:52] <ijohnson> mvo: also could you do a sudo git merge on https://github.com/snapcore/snapd/pull/8659 ?
[10:52] <ijohnson> the test failures are unrelated
[10:52] <mup> PR #8659: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8659>
[10:59] <abeato> o/ is it possible to do 'snap run --gdb' on UC? It complains about gdb command not found
[10:59] <zyga> abeato: IIRC not at present
[11:00] <zyga> abeato: we discussed some work required for that but it's not scheduled
[11:00] <abeato> ok, thanks
[11:03] <mborzecki> an errand, back in 2-3h
[11:03] <mup> PR snapd#8659 closed: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8659>
[11:26] <pstolowski> re
[11:33] <mvo> pstolowski: thanks your view in 8531! great comments
[11:33] <zyga> hmm
[11:33] <zyga> that binfmt misc change is annoying
[11:33] <zyga> let me take it out of the equation
[11:37] <pstolowski> mvo: yw, glad you found it useful
[11:43] <mvo> pedronis: fwiw, I updated the vitality score pr, need to address the comemnts from pawel still though, feel free to have a look still
[11:47] <mup> PR snapd#8669 opened: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8669>
[11:47] <zyga> https://github.com/snapcore/snapd/pull/8669 fixes random occurance of mounted of binfmt_misc brekaing mount-ns test
[11:47] <mup> PR #8669: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8669>
[11:55] <zyga> mvo: ^
[12:04] <pstolowski> cachio: hi, i commented on your nested.sh PR
[12:04] <cachio> pstolowski, thanks
[12:13] <xnox> pstolowski:  hi
[12:14] <pstolowski> xnox: hey! i've sent you an email
[12:17] <zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/8656/
[12:17] <mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
[12:17] <zyga> I think it's okay now
[12:17] <zyga> mvo: I have one tiny fix for you https://github.com/snapcore/snapd/pull/8670 -- debian packaging
[12:17] <mup> PR #8670: packaging: update sid packaging to match 16.04+ <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8670>
[12:18] <zyga> ijohnson: do you want to review https://github.com/snapcore/snapd/pull/8566 -- it has +2 and I'd like to merge it to make progress
[12:18] <mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
[12:18] <zyga> you marked yourself as a reviewer
[12:18] <mup> PR snapd#8670 opened: packaging: update sid packaging to match 16.04+ <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8670>
[12:18] <zyga> but that was two weeks ago
[12:19] <ijohnson> zyga: go ahead without me, I started a review but didn't finish
[12:19] <zyga> ok
[12:19] <zyga> thanks :)
[12:24] <pedronis> ijohnson: I reviewed #8668, it probably could help if it go split at least in two, I comment as much. I need to go take of an errand, but happy to chat about it later if you have questions. I also think it should live under osutil/disks or something like that.
[12:24] <mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
[12:24] <pedronis> *take care of an errand
[12:26] <pedronis> mvo: notice that I commented on one of pstolowski considerations and your answer
[12:26]  * pedronis errands
[12:29]  * zyga found a curious failure in session agent test, looking
[12:29] <zyga> a daily reminder that spread -seed is your friend
[12:56] <mvo> zyga: thank you
[13:49]  * zyga breaks for a moment, for the next meeting
[13:51] <cachio> zyga, please tell be what you mentioned about the spread user
[13:51] <ijohnson> pedronis: yes let me finish going through your comments, splitting out is probably a good idea and fine to do, I had forgotten I still had the exported mocking methods in the file, those are used in a followup
[13:51] <cachio> zyga, couldn't hear
[14:03] <mborzecki> re
[14:04] <zyga> cachio: in a moment, in another call
[14:07] <mvo> pedronis: what was the second comment you had about 8351? I will work on the seeding spread test now but forgot what comment 2 was
[14:07] <pedronis> mvo: we should block people from putting snapd itself in the list
[14:08] <pedronis> because we are not going to support making it less important than other things
[14:09] <mvo> pedronis: nice, will do
[14:17] <pedronis> ijohnson: I asked a question, and answered/made a suggestion to something else in that PR
[14:40] <pedronis> pstolowski: mvo's PR has landed (and maybe we got new enough kernels), #8533 needs  master merge
[14:40] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[14:40] <pstolowski> pedronis: ok, thanks
[14:40] <zyga> 20 minutes until next call
[14:40] <zyga> mvo: I feel your pain :D
[14:43] <zyga> jdstrand: before the next call, do you have time to look at https://github.com/snapcore/snapd/pull/8578
[14:43] <mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
[14:43] <zyga> jdstrand: it's doing the same thing, just some naming changes
[14:43] <ijohnson> thanks pedronis sounds good
[14:52] <pedronis> ijohnson: made a suggestion based on your answer
[14:53] <mborzecki> pedronis: do you have a minute to talk abou the tweaks to keeping track of the current system? i implemented the changes we discussed and have some concerns that we may be overcomplicating it
[14:53] <ijohnson> thanks yes a Dev() method is fine too
[14:53] <ijohnson> also a quick review on https://github.com/snapcore/snapd/pull/8652 by anybody would be great  :-)
[14:53] <mup> PR #8652: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8652>
[14:54] <pedronis> mvo: should I come to the next meeting? mborzecki wants to chat about something with me
[14:54] <jdstrand> zyga: before the next call? no. as mentioned yesterday when talking about the coordination email I sent, I will be getting to PR reviews today/tomorrow. I have a bunch of meetings so likely tomorrow
[14:56] <zyga> jdstrand: sure, no worries
[14:57] <jdstrand> ackk, mvo: you may not use sudo/su in a snap to drop to the snap_daemon user. those go through the pam stack. I outlined in https://forum.snapcraft.io/t/system-usernames/13386 with a link to code on how to do it. I believe there is something in the snapcraft realm that (cc cjp256) to make it even easier
[14:58] <jdstrand> one of the reasons why is that sudo and su use the pam stack. but you don't need pam for this
[14:58] <mup> PR snapd#8669 closed: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8669>
[14:59] <ijohnson> thanks zyga for the review!
[14:59] <zyga> :)
[14:59] <zyga> I need to look at the snap routine portal info test
[14:59] <zyga> but
[14:59] <zyga> more meetings
[14:59] <mup> PR snapd#8652 closed: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <Simple 😃> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8652>
[15:04] <mborzecki> pedronis: no worries, we can talk after your meeting
[15:04] <cachio> pstolowski, hey
[15:05] <cachio> nested is working again
[15:05] <cachio> cmatsuoka, told me the problem
[15:05] <pstolowski> cachio: yay, that's great
[15:05] <cachio> pstolowski, I'll push in a bit
[15:07] <pstolowski> thx
[15:11] <zyga> woot
[15:12] <pedronis> mborzecki: I'm available now, standup?
[15:12] <mborzecki> pedronis: ok
[15:12] <pedronis> zyga: yes, I looked at your PR, we indeed should talk, also because if I understand that's not the final place you want to put those in, right?
[15:12] <pedronis> I mean the inhibit locks
[15:13] <zyga> pedronis: that's right, I'd like to grab the lock earlier, when we do the soft check and it succeeds
[15:13] <zyga> pedronis: I will look at it in detail tomorrow
[15:13] <zyga> my main question was where should this live
[15:13] <zyga> as there will be more code for a non-demo version (undo, all exit paths covered, tests)
[15:15] <cachio> pstolowski, I pushed the change
[15:16] <cachio> I already tested that
[15:16] <zyga> cachio: my question was about the external user
[15:16] <zyga> cachio: what's the reason for using a non-root user to log into the test device in spread, when using the ad-hoc backend
[15:16] <zyga> cachio: and a follow-up, if we could use regular root instead
[15:17] <cachio> zyga, I suppose that in core device we need a user
[15:17] <cachio> different than root
[15:17] <zyga> cachio: do you know why?
[15:17] <pstolowski> cachio: could you push this fix as a separate PR? i think this could land quickly if independent of your nested lib PR
[15:18] <cachio> I mean, if you can setup the password for root you can use root
[15:18] <cachio> zyga, but you need to specify the passwotd in the spread.yaml
[15:18] <zyga> cachio: and how is that different from the external user? we specify a password for it
[15:19] <zyga> cachio: I want to avoid the difference between ad-hoc and all the other backends
[15:19] <cachio> zyga, I mean, it is the same
[15:19] <zyga> cachio: because we get more and more session level things
[15:19] <zyga> and now we will get a new session that only occurs in a rarely-exercised test interaction
[15:19] <cachio> zyga, we could use root
[15:19] <cachio> zyga, I dindt'
[15:20] <cachio> didn't try with root in a core device but I dont see any restriction
[15:20] <cachio> zyga, let me make a try
[15:20] <zyga> cachio: cool, if we can do it that is preferable
[15:20] <zyga> cachio: if we cannot do it I will try to accommodate the external user instead
[15:20] <cachio> pstolowski, yes I can, but I'll need a bitr of time because there are few other thinks needed as well
[15:21] <cachio> zyga, ok
[15:21] <pstolowski> cachio: ah, if it is more than this 2 line change to apply it on master than maybe it's not worth it
[15:22] <cachio> pstolowski, I'll make a try after lunch
[15:22] <cachio> I need to review what is needed
[15:23] <zyga> ijohnson: hey, if you have a moment, I'd love to get a 2nd review for https://github.com/snapcore/snapd/pull/8633 -- I have some extra checks piled after that, which might help with flaky tests
[15:23] <mup> PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
[15:24] <zyga> I merged master to get some more fixes but it should otherwise pass (unless network issues show up)
[15:26] <zyga> mvo: I guess I could look at proposing prompting in to master
[15:26] <zyga> mvo: it needs considerable setup so it would be a distinct suite / backend perhaps
[15:27] <cachio> mvo, is it possible to add a password to root in ubuntu core?
[15:27] <cachio> zyga, ~
[15:27] <zyga> home :)
[15:30] <ijohnson> zyga: sure I will take a look at it
[15:32] <zyga> ahhh
[15:33] <zyga> I just understood why we still see some failures
[15:33] <zyga> the failover fixes
[15:33] <zyga> they don't reload root's session systemd --user
[15:33] <zyga> I'll send a follow up shortly
[15:33] <zyga> the things we learn :)
[15:34] <pedronis> zyga: btw not urgent, but I also spent some time thinking about how to name the *-tool things. we should think a good time to talk about that
[15:34] <zyga> pedronis: I'm off tomorrow but we can try early next week
[15:34] <pedronis> ok
[15:34] <zyga> pedronis: or by email if it's low bandwidth
[15:35] <zyga> pedronis: I see the problem but I also love the -tool suffix is recognizable as our internal thing and it's short
[15:36] <pedronis> yes, I agree, we need recognizable or at last standing out names
[15:36] <pedronis> but the problem with -tool is that is not easy to know what to actually expect from them
[15:37] <pedronis> zyga: anyway this is a bit an area were it's easy to bikeshed, I might have to simply make a call about where to got at some point
[15:38] <zyga> pedronis: SURE
[15:38] <zyga> sure
[15:38] <zyga> :)
[15:38] <zyga> sorry, tabbed out of vm with the wrong key
[15:39] <pedronis> also we have snap-tool that being consistent should be called snapd-tool-tool
[15:39] <pedronis> :)
[15:40] <pedronis> anyway
[15:41] <zyga> pedronis: snapd-metatool
[15:42] <zyga> https://github.com/snapcore/snapd/pull/8671 should fix the cases that fail with errors like
[15:42] <mup> PR #8671: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8671>
[15:42] <zyga> - Make snap "test-snapd-user-service-sockets" (unset) available to the system (Post http://0/v1/service-control: read unix @->/run/user/0/snapd-session-agent.socket: read: connection reset by peer)
[15:42] <mup> PR snapd#8671 opened: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8671>
[15:42] <zyga> and with that I'd like to do some paperwork and EOD
[15:42] <zyga> cachio: ^
[15:44] <zyga> ijohnson: I should probably move the defer.sh + tac trick into a helper
[15:44] <zyga> ijohnson: cleanup-tool (accepting any rename after we agree on new names)
[15:45] <mup> PR snapd#8654 closed: tests: test registration with serial-authority: [generic] <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8654>
[15:46] <zyga> this is so nice
[15:46] <zyga> I wanted to do my own model a few times
[15:46] <zyga> and now with the generic authority I can just really do that
[15:46] <zyga> and not feel like it's half baked
[15:48]  * cachio lunch
[15:50]  * zyga EOWs
[15:50] <zyga> see you on Monday everyone
[16:03] <pedronis> pstolowski: there seem to be some selinux failures showing up in #8533
[16:03] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[16:03] <pstolowski> looking
[16:09] <mup> PR snapd#8672 opened: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8672>
[16:09] <pstolowski> hmm that's weird, seems unrelated
[16:10] <mvo> cachio: adding a password to the root user is pretty hard, it's /etc/passwd,shadow are readonly so we would need to play bind-mount tricks
[16:20] <ackk> is it possible to share unix sockets via a content interface between snaps?
[16:23] <zyga> ackk: yes
[16:23] <zyga> ackk: it's also tested
[16:23] <zyga> ackk: and really works :)
[16:26] <ackk> zyga, lol. yeah I think I have misconfiguration on my side
[16:27] <ackk> thanks
[16:27] <zyga> :)
[16:27] <zyga> I'm EOD but can respond to questions with small alg
[16:27] <zyga> *lag
[16:27] <pstolowski> pedronis: ok, it's not obvious with selinux and the test alone against master didn't fail, i'll investigate tomorrow
[16:28] <zyga> pstolowski: looking
[16:29] <pstolowski> zyga: it's about #8533
[16:29] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[16:29] <pstolowski> afk
[16:29] <zyga> ok, next week
[17:27] <pedronis> ijohnson: questions: https://github.com/snapcore/snapd/pull/8668#discussion_r425309127
[17:27] <mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
[17:38] <mup> PR snapd#8671 closed: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8671>
[17:39] <mup> PR snapd#8633 closed: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8633>
[17:47] <ijohnson> pedronis: well iiuc from xnox is that what we are trying to do re: cross checking may be racy in that we are walking through entries in sysfs and udev, and "the-tool" currently doesn't wait for udev, it just waits for systemd-modules-load
[17:48] <ijohnson> I think maybe making the-tool run after udev would eliminate some of the raciness, in which case maybe it's okay to say it's deterministic, but I just don't honestly know
[17:49] <ijohnson> I have not seen it fail at any point mid way through the function with incomplete output fwiw, but that also isn't a good representation
[17:54] <pedronis> ijohnson: sorry, so we write a lot of code to avoid the raciness of lsblk but actually we have raciness anyway?
[17:55] <ijohnson> pedronis: well I don't know how much / what is racy
[17:56] <ijohnson> pedronis: so to combat not knowing I am just assuming it's racy and doing a best effort in the function
[17:56] <ijohnson> pedronis: if you'd rather I can just turn all of the "continue"s into return nil, err` but then there will be very many checks there and it feels all a bit fragile to me
[17:57] <pedronis> ijohnson: we should step back a bit I think
[17:57] <ijohnson> also fun fact the "unsafe encoding" actually comes from blkid, and the format is already deprecated yet udev continues to use it:-/
[17:57] <ijohnson> or rather the "safe encoding" format comes from blkid
[17:58] <ijohnson> pedronis: ok, sure how should we proceed
[18:04] <ogra> snap changes
[18:04] <ogra> error: no changes found
[18:04] <ogra> is there any particular reason why we consider this an "error" ?
[18:07] <xnox> ijohnson:  "currently doesn't wait for udev" => we did discuss this before, to order it after udev trigger is done....
[18:07] <ijohnson> xnox: true but we didn't do this yet
[18:07] <ijohnson> xnox: so if we ordered the-tool to run after udev, would you expect things in /sys/dev/block/<maj:min>/uevent to change ?
[18:08] <xnox> ijohnson:  what do you mean to change?
[18:08] <xnox> uevent is a kernel api file there.
[18:08] <xnox> it's dynamic write/read response api
[18:08] <ogra> is "udevadm settle" not existing anymore ?
[18:09] <ogra> (that used to block until udev is done)
[18:09] <xnox> ogra:  why would you run that under systemd?
[18:09] <xnox> when there is a  unit to order one after?
[18:09] <ijohnson> i.e. in order to implement mounting of a consistent set of partitions, we need to look at all of the devices with uevent files like that that match some filter, in this case the same major number
[18:09] <ogra> xnox, dunno ... probably because i'm from last century ;)
[18:10] <ijohnson> and I'm wondering if in the course of finding the set of devices that match the same major device number, would anything read from say the first uevent we look at change by the time we are done and look at the last uevent?
[18:10] <ijohnson> xnox: from the sounds of it you are saying it wouldn't change
[18:10] <xnox> ijohnson:  i'm not sure, why you key onto the uevent file. but the /sys/dev/block/<maj:min> numbers are stable from device inception as seen in userspace from kernel.
[18:10] <zyga> https://github.com/snapcore/snapd/pull/8669 fixes random occurance of mounted of binfmt_misc brekaing mount-ns test
[18:10] <mup> PR #8669: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8669>
[18:10] <ijohnson> sorry we're not keying on the uevent file, we just need to read that file
[18:10] <zyga> sorry, paste frommdauaf\t\
[18:10] <zyga> keyBa
[18:10] <zyga> fghhh
[18:11] <zyga> lol
[18:11] <zyga> she loves backlit keys
[18:11] <ijohnson> really we glob /sys/dev/block/NUM:*/uevent and read all those files basically
[18:11] <zyga> (that was Lucy smashing keys)
[18:11] <xnox> ijohnson:  yeah, reading it is fine.
[18:12] <ijohnson> xnox: ok, next question for each device that matches the filter above, we also run `udevadm --name <devname> --query property`, would you expect the output from that to change at all from the first device we query to the last one?
[18:12] <xnox> ijohnson:  note, that will only have kerenl uevent details, not the udev uevent details. Normally one subscribes to the kernel netlink uevents and just listens the stream of them.
[18:12] <ijohnson> xnox: again, if we ordered after udev
[18:12] <xnox> or like subscribe to udevd's events, which have more information.
[18:13] <ijohnson> xnox: perhaps this would be easier if you just reviewed my PR and tell me if what I'm doing looks racy/non-racy
[18:13] <xnox> ijohnson:  you are asking very low level questions, without the overall goal known.
[18:13] <ijohnson> xnox: see disks.go in https://github.com/snapcore/snapd/pull/8668/files#diff-6c8f8423221c269ce0465372c62a9751
[18:13] <xnox> ijohnson:  yeah. Normally, one uses udev apis and talks against it's database which is cached / consistent.
[18:13] <mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
[18:14] <ijohnson> xnox: the overall algorithm is, we have a mountpoint, how do we get 1) the mapper partition from that mountpoint, 2) the underlying encrypted partition from that mapper partition, 3) the disk that the encrypted partition comes from
[18:16] <xnox> sounds fun
[18:17] <xnox> ijohnson:  and you don't want to use libudev bindings to query all of those things? cause it has like apis to query all the things, including "who is parent of this device", and again, and again, etc.
[18:17] <xnox> ijohnson:  https://pkg.go.dev/github.com/farjump/go-libudev?tab=doc ? you rather have your own code, instead of using libudev1, right?
[18:18]  * xnox is kind of surprised that snapd doesn't already use libudev bindings => it's the fastest thing to query drives
[18:18] <xnox> and is the ultimate source of truth.
[18:18] <ijohnson> xnox: last I heard is that we don't want cgo
[18:19] <ijohnson> if there are pure go bindings to libudev then probably that would help, but would it help by much?
[18:22] <xnox> there are pures ones too, but executing udevadm imho is safer than any custom native bindings.
[18:22] <xnox> ijohnson:  you seem to do a lot of work walking all the things in /dev/ when you have all of that information in the udev database already.
[18:22] <ijohnson> xnox: is there a way that we can get udev params from device major minor directly ?
[18:22] <xnox> yes
[18:22] <ijohnson> how?
[18:23] <ijohnson> using udevadm directly I mean
[18:23] <ijohnson> not the libudev library
[18:23] <xnox> i normally, just do `udevadm info --export-db` which exports a consistent snapshot of _everything_
[18:23] <xnox> and in there you have all the major:minor, all the DM_UUID, all the parents already pre-declared.
[18:23] <ijohnson> xnox is there a way you can get that in the --query output format though?
[18:23] <xnox> xnox:  and you can ask udevadm to tell you which major:minor a given device is on
[18:24] <ijohnson> the format that udevadm outputs by default is slightly more complicated to parse than I would like
[18:25] <xnox> ijohnson:  there is also this:
[18:25] <xnox> $ udevadm info --device-id-of-file /boot/
[18:25] <xnox> 259:5
[18:25] <xnox> which prints major:minor of the device a given file is on
[18:25] <xnox> such that if something is mounted, you can just query give me the device of the things.
[18:25] <ogra> geezs ... allthehiddenknobs !
[19:01] <jdstrand> ackk: fyi, I updated "Dropping privileges" in https://forum.snapcraft.io/t/system-usernames/13386 to discuss the 'setpriv' command with an example snap: https://git.launchpad.net/~jdstrand/+git/test-setpriv/tree/snapcraft.yaml
[19:02] <jdstrand> ackk: with snapd 2.45 you can just use setpriv without LD_PRELOAD
[19:02] <jdstrand> ackk: hope that helps
[19:03] <ackk> jdstrand, oh, great, thanks! that will make things easier
[19:04] <jdstrand> cool :)
[19:04] <jdstrand> fyi emitorino ^
[19:06] <ijohnson> jdstrand: why does setpriv in snapd 2.45+ work without LD_PRELOAD?
[19:07] <jdstrand> ijohnson: https://github.com/snapcore/snapd/pull/8220
[19:07] <mup> PR #8220: interfaces/seccomp: allow passing an address to setgroups <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8220>
[19:09] <ijohnson> jdstrand: so does that mean that setpriv is doing the same thing as dnsmasq and is arguably a coding error?
[19:09] <jdstrand> ijohnson: yes
[19:10] <emitorino> jdstrand, ack
[19:11] <ijohnson> hmm jdstrand but couldn't upstream setpriv change to not do this and effectively break snaps that are relying on this behavior ?
[19:13] <mup> PR snapd#8673 opened: tests: enable degraded test on uc20 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8673>
[19:15] <jdstrand> ijohnson: sure, but that is true of anything that you stage when you change bases
[19:19] <jdstrand> ijohnson: fyi, this is the code: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/setpriv.c#n1035
[19:19] <jdstrand> ijohnson: but actually, the only way they could break it would be to call setgroups(<something not 0>,)
[19:20] <jdstrand> ijohnson: ie, it doesn't matter what they do with the second argument (use the document NULL or something else), cause our filter no longer cares
[19:20] <jdstrand> documented*
[19:21] <jdstrand> (and it is safe that we don't care as per the PR discussion)
[19:21] <pedronis> ijohnson: so I'm looking at #8668, and even ignoring the raciness I think there's too much going on, given in the end we are going to call udevadm info, we don't need to use /sys/ that much, we can pass /sys paths to udevadm
[19:21] <mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
[19:21] <pedronis> directly
[19:34] <ackk> jdstrand, does that mean that apps using initgroups/setgroups will also work without preload in 2.45?
[19:37] <jdstrand> ackk: no. this is about using setgroups(0, <something>) only
[19:38] <jdstrand> ackk: before we required setgroups(0, 0). dnsmasq didn't do that so we investigated and got comfortable with setgroups(0, <something>)
[19:38] <jdstrand> ackk: as it happens, that makes setpriv with --clear-groups also work
[19:39] <jdstrand> ackk: setgroups with a size of > 0 is not mediatable by the sandbox, since we can look at what is in the second argument
[19:40] <jdstrand> ackk: so, we can't differentiate between setgroups(1, 584788) and setgroups(1, 0)
[19:40] <jdstrand> meh
[19:40] <jdstrand> setgroups(1, [584788]) and setgroups(1, [0,1,1000,...])
[19:41] <jdstrand> (we can't dereference a user space point at the time of mediation as a limitation of seccomp's design and implementation)
[19:42] <jdstrand> it should be possible to mediate setgroups when apparmor grows its syscall filtering, but that is not on a near term roadmap
[19:43] <mup> PR snapcraft#3122 closed: pluginhandler: make the build environment available to all steps <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3122>
[19:43]  * cachio afk
[19:44] <jdstrand> ackk: (and initgroups() is a glibc wrapper around the setgroups system call, so it has all the same issues)
[19:45] <jdstrand> ackk: erf
[19:45] <jdstrand> s/since we can look at.../since we can*not* look at.../
[19:46] <jdstrand> ackk: hopefully I answered your question (sorry for the typos)
[19:55] <mup> PR snapcraft#3123 opened: cmake v2 plugin: configure with $SNAPCRAFT_PART_SRC <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3123>
[20:16] <zyga> heh
[20:16] <zyga> are we again waiting on travis?
[20:16] <zyga> https://github.com/snapcore/snapd/pull/8566 is stuck on travis
[20:16] <mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
[20:17] <zyga> close/reopen to fix it, as usual
[20:30] <ijohnson> pedronis: part of the issue with the code tho is that udevadm just doesn't give us enough info for various bits
[20:30] <ijohnson> We still need to go to sysfs for various things unless there's more magical flags to udevadm that tell us what we need
[20:31] <pedronis> ijohnson: what doesn't it tell us?
[20:32] <ijohnson> (sorry internet cutting out here)
[20:32] <ijohnson> pedronis it doesn't have heirarchical info and doesn't know much about the dm devices
[20:33] <pedronis> ijohnson: well the hierarchical issues are kind of the same
[20:33] <pedronis> ijohnson: afaict it has the same info about dm devices that /sys has
[20:33] <ijohnson> pedronis how do you mean
[20:33] <ijohnson> I run udevadm on the dev mapper and it gives me very little info
[20:34] <ijohnson> But regardless I see your suggestion now, if you would rather me iterate with udevadm calling on the minor incremented I can do that, I don't see the advantage of that vs inspecting sysfs
[20:35] <pedronis> ijohnson: there is a lot of back and forth between reading /sys and udevadm, each of that needs an error check
[20:35] <pedronis> it's all very roundabout
[20:36] <pedronis> ijohnson: afaict dm name and dm uuid here are present as DM_UUID and DM_NAME
[20:36] <ijohnson> Well I mean yes all of this is extremely roundabout since there's not a complete set of info from udev or sysfs
[20:36] <pedronis> ijohnson: i still don't understand the complete info bit, they kind of have the same information
[20:36] <pedronis> in slightly different ways
[20:36] <ijohnson> pedronis those were defined for udev env vars for me before we started mounting as /dev/mapper, but now that we use that I don't get that info
[20:37] <ijohnson> Pedronis can you share what you see running udevadm where you get that info
[20:37] <ijohnson> Perhaps my uc20 install is buggy somehow
[20:38] <ijohnson> pedronis: this is what I see now with udevadm
[20:38] <ijohnson> https://www.irccloud.com/pastebin/xy1iR8UT/
[20:38] <ijohnson> (my internet seems to be back so back at my computer now)
[20:39] <ijohnson> I get the same output if I try to access it by /dev/disk/by-label/ubuntu-data or by the major device number as well
[20:41] <pedronis> ijohnson: I was playing with a focal system, not uc20, I get a ton more info for dm devices
[20:41] <pedronis> strange
[20:41] <pedronis> I wonder what is different
[20:41] <ijohnson> pedronis: yes on my focal classic system I have more info too, but not in uc20
[20:42] <ijohnson> could be in the options we use in creating the luks device, etc.
[20:42] <pedronis> I doubt that
[20:42] <pedronis> this is about the mapper info
[20:43] <ijohnson> well I mean I really don't know, what I know is that the code I have works with the info we currently have on uc20 and that there is probably about 1000 other ways we could do the same thing
[20:44] <pedronis> ijohnson: that code is full of continue, that is the part that worries me, I would really like to have as little things returning errors as possible
[20:44] <pedronis> to have to deal with
[20:45] <pedronis> and also even with less info is still seems a bit too roundabout
[20:45] <ijohnson> pedronis: I can try to refactor it to use udevadm calls with incremented minor numbers perhaps that will make it easier/have less `continue`/`return nil, err` but I think at the end of the day unless we have some kind of magical udevadm flag or config option or something that I don't know about we're going to have to get our hands dirty with this code
[20:46] <pedronis> ijohnson: like I don't think we need to do all the find DEVNAME then use the DEVNAME
[20:46] <pedronis> udevadm will happily take things under /sys/
[20:47] <ijohnson> sure let me try to refactor that and see how much goes away
[20:49] <pedronis> ijohnson: do your partion all have ID_PART_ENTRY_DISK at least ?
[20:49] <ijohnson> pedronis: you mean physical partitions or dm partitions
[20:49] <ijohnson> dm partition does not have
[20:49] <pedronis> I mean the physical partitions
[20:49] <ijohnson> dm partition does not have ID_PART_ENTRY_DISK
[20:50] <ijohnson> the physical partitions all seem to have that prop though yes
[20:50] <pedronis> well, it's not a partition
[20:50] <pedronis> it has DEVTYPE=disk
[20:51] <pedronis> but it here it has a little bit more info
[20:51] <pedronis> but we can deal with that
[20:51] <ijohnson> ok, but yes all of the vda* have that defined
[20:51] <pedronis> anyway as I also remarked it doesn't make sense to find all the partition, especially when we just want to find if the mount points come from the same disk
[20:52] <pedronis> it seems we need two primitives  diskFromMountPoint(path) -> major:minor
[20:53] <pedronis> diskIter(major:minor, func(udev props) (done bool)) or something like that
[20:54] <ijohnson> by diskIter you just mean a function which finds all the partitions for the specific disk?
[20:54] <pedronis> yes, and calls a function passing the result udevadm for each partition until the function is happy
[20:54] <pedronis> this are the internal primitives
[20:54] <pedronis> not what we expose as api to be clear
[20:55] <ijohnson> seems overly complicated to me, why do that over a for loop ?
[20:55] <mup> PR snapcraft#3124 opened: storeapi: update api and error messages from push to upload <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3124>
[20:55] <ijohnson> do we need different kinds of searches ?
[20:55] <pedronis> ijohnson: we need to mock both of those in this world
[20:57] <ijohnson> so I think what the impl will look like is diskfrommountpoint returns a wrapper object around the major/minor and doesn't do any searching yet and then the MountPointIsFromDisk and FindMatchingPartitionUUID functions actually do the searching, in the case of mount point from disk we may not actually need to do any searching
[20:58] <pedronis> ijohnson: yes, something like that
[20:58] <ijohnson> because MountPointIsFromDisk really just gets the dev maj:min for the mount point and compares
[20:58] <ijohnson> so we only have to do one search, which is for FindMatchingPartitionUUID
[20:59] <ijohnson> see originally I had different function names where you called one function and not two like this and it seems the refactor carried a bit too much implementation much the before the factor
[21:00] <pedronis> ijohnson: yes, I still think that the helper would make clearer what's constraints and responssibility, and also make mocking a bit more limited
[21:00] <ijohnson> right
[21:00] <ijohnson> alright well I will re-work this a little bit later today, need to go run an errand, perhaps we can sync on this shortly tomorrow after/before SU to see if I'm in a better direction then
[21:01] <pedronis> anyway looking at a focal system it seems the extra DM_ info comes from /lib/rules.d/55-dm.rules
[21:01] <pedronis> I wonder if they are not in core 20 or something they need is not there
[21:02] <pedronis> anyway this is the initramfs
[21:02] <pedronis> so maybe it has less rules anyway
[21:02] <ijohnson> pedronis: I have that file in /usr/lib/udev/rules.d/55-dm.rules from the core20 snap
[21:02] <ijohnson> let me quickly check the initramfs
[21:03] <ijohnson> hmm actually that same file is also in the initramfs
[21:04] <pedronis> interesting
[21:04] <pedronis> anyway as you said we are not waiting for udev, whatever that means
[21:05] <ijohnson> yes there's a systemd udev service that runs in the initramfws
[21:05] <ijohnson> we should make the-tool depend on it
[21:05] <ijohnson> but also I've been looking at userspace where it should also have run
[21:10] <pedronis> reading that rule files it sounds that we probably have only what we got from the initrd
[21:10] <pedronis> given that we carry the mount device through from it
[21:10] <pedronis> so userspace doesn't matter
[21:11] <pedronis> the question is just why that doesn't work in the initrd
[21:11] <pedronis> not our biggest concern anyway atm, but interesting/confusing
[21:13] <pedronis> ijohnson: actualy does _FLAG you have sounds like they have been turned off (maybe)
[21:13] <pedronis> *those _FLAG
[21:16] <ijohnson> pedronis what _FLAG ?
[21:16] <pedronis> ijohnson: you have things like: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
[21:16] <pedronis> in your udevadm output
[21:16] <pedronis> it sounds like things are turned off
[21:54] <mup> PR snapd#8566 closed: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8566>
[22:13] <mup> PR snapcraft#3123 closed: cmake v2 plugin: configure with $SNAPCRAFT_PART_SRC <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3123>
[23:22] <mup> PR snapcraft#3124 closed: storeapi: update api and error messages from push to upload <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3124>


[00:14] <Azendale> So, I tried with a fresh rabbitmq install without the "vip_iface: 'eth0'" setting and and the HA charm still had trouble. So, I went looking for where it was getting the interface value, and the hacluster charm is getting it from relation-get. So I went and looked at the rabbitmq charm side, and it is getting it from config-get. So, I guess I'm trying to figure out where the default settings are set?
[00:25] <melmoth> Azendale, you can change the default setting in a yaml file to be use with a --configure when you deploy rabbitmq
[00:26] <melmoth> the defalt value is set in the config.yaml file that comes with the charm itself.
[00:26] <Azendale> melmoth: ok, so that file ISN'T just documentation
[00:26] <melmoth> that s my understanding.
[00:27] <Azendale> melmoth: thanks, I was hoping to see if I could submit a patch/branch
[00:27] <Azendale> melmoth: since I just used the default settings and it broke
[00:29] <melmoth> hmm, last time i try hacluser/rabbitmq i did set both vip-interface and ha-bindiface (even though i set them to the default value)
[00:30] <melmoth> and it 'just worked', well, sort of :)
[00:40] <Azendale> melmoth: hm, what version (I'm using Havana)? I didn't set it so it defaulted to "eth0". (I'm assuming that you are saying that you set these on the rabbitmq charm?)
[00:41] <Azendale> melmoth: Here's the config I used http://paste.ubuntu.com/6308688/
[00:41] <melmoth> i was deploying stuff on an openstack cloud, i m not sure of the release of.
[00:41] <melmoth> and yep, those were set in the rabbitmq config file
[00:43] <melmoth> Azendale, this was my test case http://pastebin.com/cKmd8j0V
[00:44] <melmoth> (i did set stuff for fsid and monitor secret, i just put * in the patebin)
[00:44] <Azendale> melmoth: do you still have that setup running? It would be interesting if you could ssh to one of the rabbitmq servers and do an ifconfig
[00:45] <melmoth> let me check.
[00:46] <melmoth> Azendale, http://pastebin.com/g6dr8qQ7
[00:49] <Azendale> melmoth: ok, I see why it worked. On the newer version (or just something quirky about how it set mine up) it puts the ethernet interface into a bridge, and then puts all the addresses on the bridge interface.  The hook in the newer version breaks when it tries to get the IP assigned to the ethernet interface, because the ethernet interface has no IP, the bridge that it is a part of has the address
[00:51] <Azendale> melmoth: thanks, that probably narrows it down to being in just the Havana version (you're on Grizzly, which is the version just before the one I'm running. They go in alphabetical order just like Ubuntu)
[00:51] <melmoth> i deployed charm from the grizzly cloud archive, but i have no idea whta is the openstack version of the cloud i was deploying stuff into
[00:52] <Azendale> melmoth: ah, so you were testing the charm on top of an openstack cloud then?
[00:52] <melmoth> yes.
[00:53] <melmoth> i was not really interested in using rabbit (i bet it wold not work because i will not have multicast in this environment), just trying to reproduce a pacemaker issue
[00:54] <Azendale> melmoth: ah, ok. Well, thanks for the help anyways! :)
[03:12] <Azendale> Where are the default settings for a charm stored? I tried changing config.yaml, but for some reason, when I tested it it didn't make any change. I assume it's set somewhere else?