[00:16] <zyga> Caelum: Yeah, Good idea. I will mąkę that change unless already did
[00:16] <zyga> I’m back tomorrow
[00:16] <Caelum> awesome, thank you!
[03:59] <mwhudson> so is there any way to tell patchelf to leave certain files alone? https://launchpadlibrarian.net/363045593/buildlog_snap_ubuntu_xenial_ppc64el_go110_BUILDING.txt.gz
[03:59] <mwhudson> the hints in the log seem to be about how to exclude the file, which i don't really want to do
[05:01] <mborzecki> morning
[06:05] <mborzecki> mvo: morning
[06:15] <mvo> hey mborzecki ! good morning
[06:15] <mvo> mborzecki: how are things? any fires?
[06:15] <mborzecki> mvo: not that i'm aware of
[06:15] <mvo> mborzecki: excellent
[06:16] <mvo> mborzecki: I see the list of open PRs is also relatively tame
[06:16] <mborzecki> mvo: yes, zyga was doing the 'trimming'
[06:16] <mvo> mborzecki: nice!
[06:18] <mvo> 4967 needs a "review" :)
[06:18] <mvo> (just changelog updates so not really much of a review9
[06:18] <mvo> )
[06:24] <zyga> Hey
[06:24] <zyga> I’m trying to wake up
[06:25] <zyga> Sorry for being late
[06:25] <mvo> zyga: good morning!
[06:25] <zyga> Good morning
[06:27] <mvo> zyga: how are you? any issues that need attention?
[06:28] <zyga>  Sleepy :-)
[06:28] <zyga> I think one issue needs attention.  The release, I didn’t publish the build to beta that day.
[06:29] <mvo> zyga: ok, on it
[06:30] <mvo> zyga: done
[06:30] <zyga> Thank you
[06:32] <zyga> I noticed a new recurring test failure
[06:32] <zyga>     - google:debian-9-64:tests/main/interfaces-network fails very often, though not all the time
[06:33] <zyga> and the failure looks real
[06:33] <zyga> typical failure of the network test on debian https://www.irccloud.com/pastebin/KujuZdgP/
[06:46] <FeelAporl> License error in discord app showing Up! https://paste.ubuntu.com/p/yHcHWGH2z2/
[06:59] <kalikiana> good morning
[06:59] <zyga> hey kalikiana
[06:59] <zyga> mvo: I found an interesting bug
[07:00] <zyga> snaps cannot be refreshed concurrently with core when reexec is supported https://www.irccloud.com/pastebin/46PfLThC/
[07:00] <zyga> as snapd restarts and snapctl doesn't run
[07:01] <mvo> zyga: uh, indeed
[07:02] <zyga> we could sort the refresh list so that snapd-carrier is always first
[07:02] <zyga> and make it so that core refresh blocks all the other guys
[07:03] <zyga> but not sure how since they are in lanes
[07:03] <zyga> we could perhaps make concurrentl downloads but apply them one by one
[07:03] <zyga> (so lane some part but not all of it0
[07:03] <zyga> but it would be a bigger redesign
[07:04] <mvo> zyga: yeah, or we ensure core is done last
[07:04] <mvo> zyga: fwiw, the nvidia fix works for me (tm) on bionic - thanks mborzecki for this!
[07:04] <mborzecki> mvo: yay!
[07:04] <zyga> I chose core first because of assumes: snapdXY
[07:04] <zyga> mvo: can we have a "bug" tag on the forum?
[07:05] <mvo> zyga: sure, I think you can add tags yourself
[07:05] <zyga> oh, thanks, I didn't see that
[07:05] <mvo> zyga: just write them and I think they appear. I'm not fully sure though, I did not use them much in the past (only for releases)
[07:08] <zyga> mvo: I don't think I can do that actually
[07:08] <zyga> mvo: anywy, I tried to capture this so that we don't forget: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/4841
[07:16] <pstolowski> morning
[07:17] <pstolowski> do we have a fire with a configure hook?
[07:28] <mvo> pstolowski: good morning! not really a fire more a bit of a wart: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/4841 but we should fix it as it leaves ugly errors in the `snap changes`
[07:34] <zyga> hey hey pawel
[07:38] <mborzecki> pstolowski: hey
[07:38] <pstolowski> o/
[07:39] <zyga> pstolowski: I added some feedback to https://github.com/snapcore/snapd/pull/4917
[07:39] <mup> PR #4917: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4917>
[07:39] <zyga> but I think it's close to landing otherwise
[07:39] <zyga> though I think it warrants a gustavo/pedronis review
[07:41] <pstolowski> zyga: thank you, i need to revisit this
[07:42] <zyga> sure
[07:42] <zyga> mvo: how do you feel about https://github.com/snapcore/snapd/pull/4911
[07:42] <mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[07:43] <zyga> we can rebase it to make tests pass
[07:43] <zyga> but we could also close it
[07:43] <zyga> mborzecki: I have a question about https://github.com/snapcore/snapd/pull/4880
[07:43] <mup> PR #4880: [RFC] cmd, data: plain make  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>
[07:43] <zyga> mborzecki: can we please close it, add a makefile and switch to it gradually
[07:44] <zyga> mborzecki: it'd be easier to review and I have some strong opinions about how to use plain make to its full extent
[07:45] <mborzecki> zyga: can you leave some comments on what you have in mind there?
[07:45] <zyga> mborzecki: well, it's a lot of little thing
[07:46] <zyga> *things
[07:46] <zyga> I'm mainly saying it's easier to discuss this in PRs when the scope is smaller
[07:49] <zyga> mborzecki: let me propose some skeletons to show what I mean
[07:49] <zyga> but I need to finish trespassing branch first
[07:49] <zyga> so in the afternoon
[07:50] <mborzecki> zyga: ok, i'll close it for now
[07:51] <mup> PR snapd#4880 closed: [RFC] cmd, data: plain make  <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>
[07:57]  * zyga is once again reaffirmed that terminus is the best font for low-dpi displays
[07:59] <mborzecki> morphis: can you take a look at https://github.com/morphis/meta-snappy/pull/17 ?
[07:59] <mup> PR morphis/meta-snappy#17: updates: snapd 2.32.2, libseccomp 2.3.3 <Created by bboozzoo> <https://github.com/morphis/meta-snappy/pull/17>
[07:59] <morphis> mborzecki: sure
[08:00] <mborzecki> morphis: thanks
[08:17] <zyga> brb
[08:25] <seb128> mvo, hey, how are you? had a good easter w.e?
[08:35] <mvo> seb128: hey, good morning! I had a really nice weekend, thank you. how are you?
[08:36] <seb128> mvo, I'm good, thanks! I had a long relaxing w.e :) but now back to bionic crazyness :/
[08:37] <seb128> mvo, did you see https://forum.snapcraft.io/t/translation-management/4798 ? is that something you could help with ? ;)
[08:37] <seb128> mvo, basically how is snapd setup for translations? do you import the translation work from launchpad to github?
[08:38] <mvo> seb128: I have seen it but not thought about it yet. we do not currently merge the translations back but we could easily do this of course
[08:38] <mvo> seb128: and I think we have to for the benefit of the other distros
[08:38] <seb128> mvo, do you have translators on github?
[08:38] <mvo> seb128: I mean, for ubuntu langpacks are probably ok
[08:38] <seb128> right
[08:38] <mvo> seb128: not really, LP seems to be the better choice here
[08:38] <seb128> but even on ubuntu, the template was outdated on launchpad
[08:38] <seb128> Gunnar updated it manuallys
[08:39] <seb128> -s
[08:39] <seb128> so at least translators can do their job now, but it made us wonder what was the expected workflow around snapd translations
[08:39] <mvo> seb128: uh, I though we had setup auto-sync :/ I need to look into this, we certainly want the auto-imported snapd LP tree for the translations
[08:39] <seb128> k
[08:40] <mvo> seb128: tbh we just had not put enough effort into the translations and to support them, but now is a good time to fix that I think
[08:40] <Chipaca> moin moin
[08:42] <seb128> mvo, k, well let me know if I can do anything to help. I think that with the template update from Gunnar translators can do their work, you might just want to do an export/import of those in github a bit later for other distros as you said
[08:42] <seb128> mvo, and I'm going to keep an eye on what's going on with the template import, the package build generated a correct one but somehow launchpad ended up not having all the strings until Gunnar workarounded it
[08:42] <Chipaca> is there an automated way to export it, so we can add it to the other distros build scrips?
[08:47] <mvo> seb128: I look into it once I finished my current task
[08:47] <seb128> mvo, thx
[08:48] <seb128> Chipaca, launchpad can auto export to a branch/vcs I think
[08:53] <zyga> Chipaca: hello
[08:53] <Chipaca> zyga: hiya
[08:53] <zyga> mvo: hey, do you think we could seed langpacks-all into the core as an experiment?
[08:53] <Chipaca> zyga: did you see #1760416?
[08:53] <zyga> Chipaca: how have you been? :)
[08:53] <mup> Bug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1760416>
[08:53] <zyga> oh, nope
[08:53] <Chipaca> zyga: very lazy :D
[08:54] <zyga> bummer, that's something nasty
[08:54] <Chipaca> was tempted into looking at snapd things only twice in the last week \o/
[08:57] <mborzecki> zyga: can you do antoher pass of #4942
[08:57] <mup> PR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
[08:57] <zyga> mborzecki: queued, now looking into the bug chipaca referenced
[08:58] <mborzecki> zyga: thanks
[09:01] <zyga> I cannot reproduce that bug on bionic
[09:01] <zyga> trying artful
[09:15] <zyga> same
[09:16] <zyga> is anyone on artful that can reproduce that bug?
[09:16] <zyga> just running any snap should fail
[09:16] <zyga> that code is on an unconditional code path
[09:19] <mborzecki> zyga: any idea what's happening with fedora?
[09:19] <zyga> in which sense?
[09:19] <mborzecki> zyga: i mean the go build thing
[09:19] <zyga> ah
[09:19] <zyga> the one that was failing last week
[09:19] <zyga> yes
[09:20] <zyga> downstream package for gopkg.in/yaml.v2 was broken
[09:20] <zyga> I added some information about this here: https://github.com/snapcore/snapd/pull/4832#issuecomment-377539457
[09:20] <mup> PR #4832: tests: move fedora 27 to google backend <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
[09:20] <mborzecki> zyga: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/pull-request/1 ??
[09:21] <zyga> maybe Pharaoh_Atem can help us speed up landing and releasing this
[09:21] <zyga> as it's a terribly broken package now
[09:21] <zyga> (out in stable)
[09:29] <kjackal> Hey snappy people! Is there a way to disable elf stripping?
[09:29] <zyga> kjackal: hey
[09:30] <kjackal> 2.40 is breaking at least one of our banaries and trying to see why
[09:30] <kjackal> binary is kubernetes-test
[09:31] <kjackal> hi zyga (!?)
[09:31] <zyga> kalikiana: ^ I think you know the answer
[09:34] <kjackal> Just to offer some context. Here is the build with snapcraft 2.40 with -d: https://pastebin.ubuntu.com/p/jTm7TBJH4B/
[09:35] <kjackal> and here is the segfault we are getting with builds from 2.39 vs 2.40 : https://pastebin.ubuntu.com/p/f4552kVxVK/
[09:39] <mvo> zyga: 4967 needs a "review" :)
[09:47] <zyga> OH
[09:47] <zyga> ah :)
[09:48]  * zyga mvo: #4938 needs a review as well
[09:48] <mup> PR #4938: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>
[09:48] <mup> PR snapd#4967 closed: release: 2.32.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4967>
[09:51] <kalikiana> kjackal: yes, you can disable it. By adding build-attributes: [no-patchelf] to the part
[09:52] <zyga> mborzecki: there are some unanswered comments on your PR
[09:52] <zyga> well, one so far :)
[09:52] <kjackal> trying that kalikiana, thanks
[09:52] <zyga> thef first one down the line , aobut the error message
[09:52] <zyga> thank you kalikiana :)
[09:53] <kalikiana> sure
[09:55]  * zyga does the review and enjoys the sunny day today :)
[09:55] <zyga> finally less clouds and more sun
[09:57] <mvo> zyga: oh, ah :) will do in a little bit
[09:57] <mvo> zyga: thanks for the merge
[10:01] <kjackal> kalikiana: zyga: seems to be working now. But I was wondering, why would snapcraft touch the banaries packaged? Seems like a bug to me. I guess I would better open a forum thread
[10:07] <kalikiana> kjackal: Yeah, a forum post sounds sensible. If you think it's doing the wrong thing we can discuss it there.
[10:08] <kjackal> thanks
[10:09] <kjackal> You definetely have your reasons I just do not know them
[10:09] <Chipaca> any other reviews i should do before going to add stuff to the error report?
[10:15] <zyga> hmm hmm
[10:16] <ogra_> hmm?
[10:17] <zyga> wondering why tests on my branch failed
[10:17] <zyga> it was supposed to work, just a re-factor
[10:17] <zyga> but let me finish one review before jumping back into my branches
[10:17] <zyga> hey ogra_, how have you been btw?
[10:18] <ogra_> busy implementing workarounds for customers ;)
[10:18] <Chipaca> ogra_: hehe
[10:18] <Chipaca> ogra_: phrasing there makes it sound like you're working around customers =)
[10:19] <ogra_> heh, well ...
[10:20] <Chipaca> la la la la can't hear you
[10:21] <Chipaca> zyga: wasn't snap-confine always in core?
[10:23] <ogra_> not in the early days (IIRC it was also called differetly in the begining)
[10:23] <ogra_> *differently
[10:26] <zyga> Chipaca: yes, that's a good point
[10:26] <zyga> Chipaca: but the one in core is correct and I have no idea how this could happen there
[10:28] <Chipaca> zyga: ＭＡＧＩＣ
[10:30] <pedronis> Chipaca: hi, #4900 needs reviews
[10:30] <mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
[10:30] <Chipaca> pedronis: hi
[10:30] <Chipaca> pedronis: ack, on it in a bit
[10:30] <pedronis> it's big, the big parts are the test changes
[10:31] <zyga> hey pedronis, power is back?
[10:31] <pedronis> yes
[10:32] <pedronis> I noticed the problems with interfaces-network on debian
[10:32] <zyga> I haven't debugged that yet
[10:33] <zyga> it's certainly random but also worrysome (related to security) and pretty frequent now
[10:33] <zyga> I suspect it is related to system key somehow
[10:37] <mvo> zyga: oh? how?
[10:37] <zyga> mvo: nothing changed in that area for a while and we introduced system key recently, I don't know what else could cause this
[10:38] <zyga> mvo: but it's just a guess, it needs to be debugged
[10:40] <mup> PR snapd#4968 opened: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
[10:40] <pstolowski> zyga: hey, thoughts on https://github.com/snapcore/snapd/pull/4968 ? some tests will need updating but before that I'd like to get +1/-1 on the approach
[10:40] <mup> PR #4968: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
[10:40] <zyga> looking
[10:42] <mvo> zyga: isn't debian itself changing?
[10:42] <zyga> mvo: debian 9 is not changing much
[10:43] <zyga> this was on stretch, not sid
[10:43] <mvo> zyga: hm, hm, ok
[11:01] <pstolowski> zyga: thanks for the quick review; apart from that minor detail re logging, do you see any big no-no?
[11:04] <cjwatson> ~/wg 40
[11:04] <cjwatson> sorry
[11:19] <zyga> pstolowski: no, it's fine I think
[11:19] <zyga> pstolowski: sorry, I will be back with reviews in a moment
[11:19] <zyga> some interruptions IRL
[11:20] <pstolowski> np, ty!
[11:39] <diddledan> snapcraft isn't working :-( (paste follows)
[11:39] <diddledan> https://www.irccloud.com/pastebin/dOwZkaZC/
[11:39] <diddledan> was fine when I went to bed last night
[11:39] <zyga> 4327 is the core snap in candidate now
[11:40] <diddledan> maybe related:
[11:40] <diddledan> https://www.irccloud.com/pastebin/Us8ymABs/
[11:40] <zyga> hmm, no idea though
[11:40] <zyga> kalikiana: more fire ^
[11:44] <zyga> ah, I found a typo in my PR
[11:44] <zyga> fixed locally, should make it green now
[11:44] <zyga> but I need to make that more robust, one sec...
[11:47]  * Chipaca -> lunch
[11:48] <zyga> sigh
[11:48] <zyga> is there any gnome extension that makes alt-tab less moronic
[11:48] <zyga> I have two virtual screens,
[11:48] <zyga> two terminals open, one on each
[11:49] <zyga> each screen also has one other unrelated window (browser and editor)
[11:49] <zyga> (again, each)
[11:49] <zyga> alt-tab from unrelated window should not jump to the terminal on another virtual screen
[11:49] <zyga> man, I hate how gnome gets most things right and consistently breaks something very very commonly used
[11:51] <zyga> and https://extensions.gnome.org/ says there is no "native connector", whatever that means
[11:53] <tomwardill> zyga: I use https://extensions.gnome.org/extension/15/alternatetab/ and you’ll need to install the extension for your browser to install gnome-extensions from that site
[11:53] <zyga> I have that installed (apparently)
[11:54] <zyga> the extension for firefox that is
[11:54] <mborzecki> any idea for which snap we dump a dbus policy file in /etc/dbus-1/system.d?
[11:54] <zyga> mborzecki: mmm
[11:54] <zyga> let me look
[11:54] <mborzecki> i've tried some of the test-snapd-* ones but no luck so far
[11:55] <zyga> mborzecki: anything that uses dbus backend would
[11:55] <mborzecki> zyga: hmm test-snapd-dbus-{consumer,provider} did not (at least on arch)
[11:55] <zyga> mborzecki: oh, that's very weird
[11:55] <zyga> let me try quickly
[11:58] <zyga> hmm
[11:58] <zyga> `func (iface *dbusInterface) getAttribs(attribs interfaces.Attrer) (string, string, error) {`
[11:58] <zyga> need to name the return values
[11:58] <mborzecki> heh :)
[11:58] <mborzecki> probably, (ok, ok, not-so-ok)
[11:59] <zyga> mborzecki: so dbus services need a policy only if they are on the system bus
[12:00] <zyga> and the snaps you mentioned use the session bus
[12:00] <zyga> so you'd have to find one that uses bus: system
[12:04]  * zyga found one more bug the refactoring has introduced
[12:04] <mup> Bug #1760841 opened: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:New> <https://launchpad.net/bugs/1760841>
[12:04] <zyga> more interesting than just a bug
[12:04] <zyga> oh
[12:04] <zyga> interesting bugs galore
[12:10] <Chipaca> mhdwtfs?
[12:11] <ogra_> a new filesystem !
[12:12] <zyga> wtffs
[12:12] <zyga> oh
[12:12] <zyga> that's frelling interesting
[12:12] <zyga> https://romanrm.net/mhddfs
[12:12] <zyga> looks like another overlayfs?
[12:12] <diddledan> yaffs = yet another ferking file system?
[12:13] <diddledan> was yaffs invented by SuSE? :-p
[12:13] <zyga> mtfs: me too file system ;)
[12:13] <diddledan> lol
[12:13] <zyga> anyway, I need to fix this bug
[12:13] <ogra_> not overlay ... but union
[12:13] <diddledan> htfs - hashtag filesystem
[12:13] <zyga> yeah, overlay can do unions today
[12:13] <ogra_> indeed
[12:13] <zyga> everything-in-a-box filesystem
[12:14] <ogra_> but that just looks like another unionfs-fuse stepchild
[12:14] <diddledan> we missed April the 1st to launch our new bhfs - black hole file system. it's effectively >/dev/null
[12:14] <zyga> diddledan: lol, indeed
[12:14] <zyga> ogra_: wait for our own snapdfs
[12:14] <zyga> it's really coming
[12:14] <ogra_> oh my
[12:15] <zyga> (not april 1st)
[12:15] <ogra_> as if we had not more pressing issues to fix :P
[12:16] <zyga> it will help a lot
[12:17] <ogra_> well, not with the issues we're facig at customers :) but yeah
[12:17] <zyga> ogra_: hey, we released the fix for /dev/ttymcsN
[12:18] <ogra_> yeah, saw that
[12:18] <ogra_> is that already ib stable ?
[12:18] <ogra_> *in
[12:18] <zyga> ogra_: no, needs to go through testing
[12:19] <ogra_> yeah, thats what i thought
[12:19] <zyga> should be out soonish though
[12:19] <ogra_> yep
[12:20] <zyga> mvo: we need to fix https://bugs.launchpad.net/snappy/+bug/1760841 for .3
[12:20] <mup> Bug #1760841: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1760841>
[12:21] <zyga> mvo: this prevents snapd from starting :/
[12:21] <zyga> mvo: the bug here is that when we cannot parse fstab we cannot start up
[12:21] <zyga> I didn't expect that
[12:24] <zyga> ogra_: I'm sure some of the issues faced by our customers will be addressed with layouts and the snapdfs idea will make that easier to work with, we could essentially allow merging content in arbitrary ways (finally)
[12:24] <zyga> this would eliminate almost all reasons to patch or alter software with configuration
[12:25] <pedronis> Chipaca: thx for the review
[12:25] <ogra_> zyga, well, main issues atm are autoconnecting interfaces on first boot, and disabling of console-conf (which michael seems to be tackling atm)
[12:26] <ogra_> also an option to disable the assertion auto-importer ... gadget updates ...
[12:26] <zyga> ogra_: one of those, the auto-importer, why is that an issue
[12:26] <ogra_> zyga, some customers want a 100% locked down device
[12:27] <zyga> aha, I see
[12:27] <zyga> so not performance related
[12:27] <ogra_> with no way to insert anything, not even a valid assertion
[12:27] <zyga> well, only they can issue assertions :)
[12:27] <ogra_> well, also performance
[12:27] <mvo> zyga: looking at the bug now
[12:27] <zyga> thank you mvo
[12:28] <zyga> ogra_: how is that performance critical?
[12:28] <ogra_> zyga, thats not the highest prio though ... autoconnecting is most important (saves one of the build.sh script hacks) atm
[12:28] <zyga> ogra_: I think that was the missing bit that we didn't understand when that PR was closed
[12:29] <zyga> yeah, the auto-connect is something I totally agree iwth
[12:29] <zyga> *wtih
[12:29] <zyga> *with :)
[12:29] <mvo> zyga: do you think I could push my suggestion for 4930?
[12:29] <zyga> looking
[12:29] <mvo> ogra_: iirc auto-connect from the gadget is something that pedronis will work on next
[12:29] <zyga> yeah, go for it, great idea
[12:30] <mvo> zyga: cool, thank you. but 176... first, looks more important
[12:30] <ogra_> zyga, it mounts all attached devices on every boot (and also falsely mounts XrpmbX and XbootX partitions (and fails since they are not mountabe ... but that causes a systemd timeout counter)
[12:30] <ogra_> )
[12:30] <ogra_> zyga, but it isnt the super imortant thing anyway
[12:30] <zyga> ogra_: is this attached to the bug report? this is relevant
[12:31] <ogra_> as i said ... console-conf and auto-connect are high prio ... but seems they are properly on the TODO
[12:31] <zyga> mvo: it basically is this:
[12:31] <zyga>  Apr 03 13:43:33 asd snapd[4016802]: 2018/04/03 13:43:33.378103 helpers.go:115: error trying to compare the snap system key: cannot parse /etc/fstab: expected between 3 and 6 fields, found 1
[12:31] <zyga> when this happens we mustn't die
[12:31] <ogra_> zyga, i think i added it to the original description
[12:31] <zyga> thanks!
[12:31] <pedronis> mvo: yes,  need G-ustavo back to discuss syntax, but yes is next on my list after being done with 2.32.x stuff
[12:31] <ogra_> zyga, it is the "#" (your fstab issue)
[12:32] <zyga> oh?
[12:32] <zyga> hmmm but don't we ignore those?
[12:32]  * zyga looks
[12:32] <ogra_> how silly can you be to require a # sign in your fs line
[12:32] <zyga> ah
[12:32] <zyga> yes
[12:32] <zyga> man, is that how this operates
[12:32] <zyga> foo# /some/other/shit?\
[12:32] <ogra_> i think no space
[12:32] <zyga> thank you ogra, I totally missed that
[12:32] <ogra_> foo#/some/other/shit
[12:33] <mvo> zyga: hm, I think I know what is going on
[12:33] <mvo> zyga: with the statup issue
[12:33] <zyga> I see
[12:33] <zyga> mvo: thank you
[12:33] <zyga> mvo: if you focus on this I will fix the parser
[12:33] <zyga> ogra_: this is interesting (from man fstab):               mount(8) and umount(8) support filesystem subtypes.  The subtype
[12:33] <zyga>               is defined by '.subtype' suffix.  For example 'fuse.sshfs'. It's
[12:33] <zyga>               recommended  to  use subtype notation rather than add any prefix
[12:33] <zyga>               to the first fstab field  (for  example  'sshfs#example.com'  is
[12:33] <zyga>               deprecated).
[12:34] <ogra_> aha
[12:34] <ogra_> well, there you go .. deprecated
[12:34] <ogra_> (though i'm surprised this was ever valid)
[12:34] <zyga> especially since the suffix is ... empty
[12:34] <zyga> this is going to be fun for parsing
[12:34] <ogra_> ŷeah
[12:35] <zyga> ogra_: that field is out of spec but I guess reality trumps specs
[12:36] <zyga> and trump trumps reality
[12:36] <zyga> and reality will trump trump eventually
[12:36] <zyga> :-)
[12:36] <zyga> brb, tea time
[12:36] <ogra_> hopefully ...
[12:42] <mup> PR snapd#4969 opened: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[12:46] <vidal72[m]> it would be nice to have snapd in debian stable backports https://backports.debian.org/ , I'm little afraid of using it from normal repos
[12:46] <vidal72[m]> flatpak is there already
[12:51] <zyga> vidal72[m]: on debian we benefit from reexec
[12:51] <ogra_> vidal72[m], snapd should re-exec itself to the binary from the core snap if this is newer so you should automatically always get the latest
[12:51] <zyga> vidal72[m]: but yeah, no disagreement
[12:51] <ogra_> vidal72[m], "snap version" will tell you
[12:51] <zyga> and some things cannot be fixed with reexec
[12:52] <ogra_> zyga, huh ? you mean it wont bring us world peas ?
[12:53] <cwayne> That's a lot of peas
[12:53] <ogra_> not *that* many https://imgur.com/gallery/MQWyj
[12:53] <vidal72[m]> zyga ,ogra_ : thx, I may try it
[12:56] <cwayne> ogra_: nice
[12:56] <ogra_> :)
[13:02] <kalikiana> diddledan: zyga: I just saw this before reading this. The `lxc push` seems to be failing consistently as if cleanbuild's source tarball didn't exist... I'm investigating what's going on there.
[13:03] <zyga> kalikiana: thank you
[13:03] <diddledan> \o/
[13:18] <mvo> cachio: (for later) is it possible to run the sru validation against https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8895866/+listing-archive-extra ? (2.32.2 from the ppa:snappy-dev/image) ? it would be great to know if the issues we saw with the sru validateion for 2.31 is now fixed
[13:23] <zyga> mvo: the converstaion is spread among two PRs: https://github.com/snapcore/snapd/pull/4868 and https://github.com/snapcore/snapd/pull/4957
[13:23] <mup> PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
[13:23] <mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
[13:35] <zyga> mvo: the tofu-meat is in this comment: https://github.com/snapcore/snapd/pull/4957#pullrequestreview-108131063
[13:35] <mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
[13:53] <kalikiana> diddledan: zyga FYI reported it here after narrowing it down a bit https://github.com/lxc/lxd/issues/4394
[13:54] <mvo> zyga: thank you
[13:54] <mvo> cachio: let me know if it is possible to run the sru vadlidation (or even just the subset that failed in 2.31) against the 2.32.2 ppa deb, if that is possible and the results are green I will do the sru based on 2.32.2 today
[13:55]  * kalikiana now lunch
[13:57]  * zyga -> walk
[13:57] <zyga> kalikiana: thank you, will read soon
[14:02] <pedronis> mvo: #4900 is the new API switch PR
[14:02] <mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
[14:26] <oSoMoN> jdstrand, hey, would you mind commenting on https://bugzilla.mozilla.org/show_bug.cgi?id=1449594#c9 ?
[14:33] <mvo> zyga: hey, whats the latest on user-mounts? I am asked in a HO about this right now
[14:36] <mup> PR snapd#4970 opened: Add SocketUser and SocketGroup options <Created by guilhem> <https://github.com/snapcore/snapd/pull/4970>
[14:42] <jdstrand> oSoMoN: there are no current plans to mount /tmp/.X11-unix into the snap's mount namespace since X is typically accessed via an abstract socket. I guess the request is "since we are special and use 'allow-sandbox: true' and can unshare() the network namespace, we break because now we don't have access to the abstract socket and .X11-unix isn't in /tmp either"
[14:43] <cachio> mvo, sure, I'll run that
[14:44] <jdstrand> oSoMoN: the simple answer is "don't do that and you get the abstract socket". I'm not sure what the network namesapce is giving them over apparmor mediation, but maybe they are concerned about devmode classic distro
[14:44] <jdstrand> oSoMoN: this requires a forum topic. it isn't a trivial request
[14:46] <mvo> cachio: great, please keep me updated!
[14:51] <oSoMoN> jdstrand, ack, that makes sense. it looks like they have a solution (not unsharing) even when /tmp/.X11-unix is not mounted in the snap's namespace, so that's alright. Can you just comment on the bug to state that there are no current plans to mount /tmp/.X11-unix, or shall I do it?
[14:52] <alexlarsson> Relying on abstract sockets is kinda ass
[14:52] <jdstrand> oSoMoN: well, just cause there aren't current plans doesn't mean there couldn't be
[14:52] <alexlarsson> I'm recommending everyone to stop listening to them, because they are not properly sandboxed
[14:53] <jdstrand> apparmor has mediation for abstract sockets with an out of tree patch (eg, Ubuntu, its derivatives and Solus have it). we are in the process of upstreaming that
[14:53] <alexlarsson> Sure, but not everyone uses apparmor
[14:54] <jdstrand> sure, hence the 'devmode classic distro'
[14:54] <alexlarsson> abstract namespaces predate /run and are really made deprecated by it
[14:54] <alexlarsson> since that is also auto-cleaned up, and additionally allows per socket access rights
[14:55] <alexlarsson> And is properly namespaceable
[14:58]  * zyga is back
[14:59] <zyga> hey alexlarsson, I'm very happy to see you here
[15:23]  * zyga is happy to see green tests on #4889
[15:23] <mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
[15:24] <zyga> but it needs some more love before I'm happy with it
[15:24] <zyga> mvo: about https://github.com/snapcore/snapd/pull/4969/files
[15:24] <mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[15:25] <zyga> I think we should return the error but log it at the caller
[15:25] <zyga> as otherwise we neuter the whole error value
[15:25] <zyga> ah, wait, actuall
[15:25] <zyga> actually, hmmm
[15:25]  * zyga thinks
[15:28] <diddledan> is there any way to use snapcraft until lxd 3.1 comes along without uninstalling the lxd snap to clear it's configuration??
[15:28] <diddledan> I can't rollback because: error: The database schema is more recent than LXD's schema.
[15:29] <zyga> diddledan: doesn't lxd use $SNAP_DATA for the database location?
[15:29] <diddledan> yes
[15:31] <diddledan> it looks like the 2.0/* channels don't have the 2.21 release which is what I was running previous to the refresh
[15:32] <diddledan> actually using `snap revert` to get to 2.21 now tells me: error: Error creating database: schema version '37' is more recent than expected '36'
[15:32] <diddledan> I think whoever is in charge of lxd has made a mess
[15:32] <nacc_> stgraber: --^ :)
[15:33] <diddledan> :-p
[15:35] <diddledan> shouldn't the database be backed-up by snapd so that reverts actually revert the database, too??
[15:35] <cachio> mvo, the errors we used to see on sru are not happening with
[15:35] <cachio> 2.32.2
[15:35] <diddledan> it looks to be being stored in $SNAP_COMMON
[15:36] <cachio> mvo, there are some problems to run on 17.10 which I have to fix
[15:40] <stgraber> diddledan: snapcraft will be fixed in the next hour or so
[15:41] <stgraber> diddledan: LXD can't be downgraded, we used to revert the database but then the rest of the data couldn't be read, so now we just don't allow it ever
[15:41] <diddledan> hmm
[15:41] <diddledan> ok
[15:41]  * diddledan twiddly diddly
[15:43] <mvo> cachio: yay, thats encouraging that most of the errors are fixed. can you pastebin the 17.10 errors?
[15:43] <cachio> mvo, cannot find the linux-image-extra-4.10.0-20-generic
[15:43] <mvo> cachio: i.e. I assume we need a 2.32.3 with the sru fixes?
[15:43] <mvo> cachio: oh, heh :)
[15:44] <mvo> cachio: thanks for finding this, do we hardcode this path?
[15:44] <mvo> cachio: eh, package name
[15:44] <cachio> yes
[15:44] <cachio> I'll push a fix
[15:45] <cachio> mvo,  but it is a test problem
[15:45] <cachio> so I can patch that locally and run the tests
[15:45] <mvo> cachio: thank you! once the fix is up I will prepare/sru 2.32.3
[15:46] <cachio> ok
[15:49] <zyga> mvo: what's the timeline for 2.32.3
[15:49] <zyga> I can prepare the 2nd part of the fix soon, just driving home now
[15:52] <vidal72[m]> jdstrand: I would prefer snap doesn't use abstract x socket https://forum.snapcraft.io/t/xorg-abstract-socket-is-mandatory-for-running-snaps/4580
[16:04] <jdstrand> oSoMoN (cc vidal72[m]): I didn't answer your question because it is a matter of priority as opposed to me saying 'yes' or 'no' (tbh, I wouldn't probably be the one to implement it, but I would review it). this is why I suggested a forum topic. perhaps add to vidal72[m]'s
[16:05] <oSoMoN> ack
[16:08] <mup> PR snapd#4971 opened: errtracker: add more fields to aid debugging <Created by chipaca> <https://github.com/snapcore/snapd/pull/4971>
[16:08] <jdstrand> oSoMoN: we aren't avoiding the named socket for security reasons. we just haven't needed it since the abstract is there
[16:08] <Chipaca> jibel: ^^ fwiw (but i assume you're getting pinged via github and the forum on this already =)
[16:08] <mvo> pstolowski: you have some feedback in 4940, looks reaonable to me, I wonder if we need gustavo for this or if we can just go ahead
[16:12] <pstolowski> mvo: thanks for you review! i'd like Gustavo's opinion on the overall approach, afaict he hasn't really evaluated the approach I described in the forum post
[16:12] <mvo> pstolowski: ok
[16:15] <mup> PR snapd#4911 closed: daemon,client: add build-id to /v2/system-info <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[16:15] <mvo> pedronis: I'm halfway through 4900, looks good so far and the non-test code is less than I expected it to be
[16:20] <zyga> mvo: you now have a review on https://github.com/snapcore/snapd/pull/4969
[16:20] <mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[16:22] <zyga> jdstrand: hey,  have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1760416
[16:22] <mup> Bug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New for zyga> <https://launchpad.net/bugs/1760416>
[16:22] <zyga> I'm very puzzled why that could ever fail
[16:27] <cachio> mvo, are you pushing 2.32.3 to beta too?
[16:29] <zyga> mvo: is 2.32.3 already done?
[16:29] <mup> PR snapcraft#2046 opened: lxd: specify arch in lxc image list command <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2046>
[16:29] <zyga> I haven't fixed the fstab parser error (though your fix is sufficient, though not merged either)
[16:31]  * kalikiana wrapping up for today
[16:33] <kenvandine> alexlarsson, it was great to see the snap support PR for xdg-desktop-portals merged today
[16:33] <jdstrand> zyga: give me a minute, it seems I got the lxd 3.0 snap and things are broken
[16:35] <jdstrand> that's weird. 'snap interfaces lxd' shows nothing
[16:35] <zyga> Oh
[16:36] <zyga> Snap was not mounted or onterface was inwalidów?
[16:36] <zyga> Invalid
[16:36] <zyga> But sure, no rush
[16:36] <jdstrand> the snap doesn't show as broken this time
[16:37] <jdstrand> I have 16-2.32.2
[16:38] <jdstrand> I stopped and started snapd and it seems to be back
[16:39] <jdstrand> then I needed to disconnect/connect
[16:39] <jdstrand> weird
[16:51] <zyga> jdstrand: weird
[16:51] <zyga> jdstrand: are you on bionic?
[16:54] <jdstrand> zyga: the seteuid or setegid calls could fail for a number of reasons (see man seteuid)
[16:54] <jdstrand> zyga: I am
[16:55] <jdstrand> zyga: I responded to the bug
[16:58]  * zyga breaks because kids are getting crazy
[17:15] <mvo> zyga, cachio no 2.32.3 yet, we need the fstab fix and the sru fix in there at least
[17:15] <zyga> what's the sru fix, the golang 1.6 thing?
[17:15] <zyga> I'm almost home, I will resume work on the fstab fix shortly, i have most of it done but I need to add some tests and see if I broke anything by changing things
[17:15] <mvo> zyga: the sru validation fails on 17.10 because of a hardcoded linux-image package name (with an abi) apparently
[17:16] <zyga> ah
[17:16] <zyga> uch
[17:21] <cachio> ok, is the sru for 2.32.2 ready?
[17:21] <cachio> tests for sru worked
[17:21] <cachio> just some known issues
[17:23] <mvo> cachio: almost ready, I think we need 4969 and then its a go (fixes a regression in 2.32.2)
[17:23] <stgraber> diddledan: should be good now
[17:24] <diddledan> yey
[17:24] <diddledan> danke
[17:25]  * diddledan pushes the button
[17:25] <cwayne> mvo: so should we be expecting another beta?
[17:25] <diddledan> yup everything good
[17:26] <mvo> cwayne: yeah, we have one (corner case) regression we need to fix
[17:26] <cwayne> mvo: ack, will keep an eye out
[17:27] <mvo> cwayne: thank you
[17:28] <cwayne> no problemo
[17:36] <mup> PR snapcraft#1997 closed: lxd: merge existing image info contents <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1997>
[17:36] <mup> PR snapcraft#2038 closed: Add an option for setting npm flags option <Created by guilhem> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2038>
[18:15] <mvo> zyga: I updated 4969 based on your suggestion
[18:49]  * zyga looks
[18:52] <zyga> #4969 needs a 2nd review
[18:52] <mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[19:04]  * cachio afk
[21:29] <popey> When is 2.32 going to be in stable?
[21:31] <mup> PR snapcraft#2047 opened: pluginhandler: organize in build instead of stage <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2047>
[23:59] <mup> PR snapcraft#2043 closed: cli: support exporting login to stdout <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2043>


[12:54] <keesj> :.. not good http://paste-it.net/raw/public/q26a6ac/ ..
[12:58] <keesj> proc is not mounted so I guess it's normal that I can't open "/proc/%d/oom_adj" whatever that is :P
[13:12] <arekm> you need a patch that ignores this error instead of failing
[13:13] <arekm> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/~checkout~/SOURCES/upstart-oomfail.patch?rev=1.1;content-type=text%2Fplain
[13:14] <ion_> CVS? *shiver*
[13:17] <arekm> cvs sill works you know
[13:17] <ion_> FSVO works
[13:28] <keesj> arekm: thanks
[13:57] <keesj> cvs never left me down
[13:58] <keesj> unlike upstart
[13:58] <keesj> right now :p
[14:11] <arekm> upstart is well, too new to be marked as "good"
[14:18] <keesj> lol , it's hard to debug the init proccess. for the kernel i use jtag+openocd  and for userland many tricks but the "init" process is just a pain
[15:09] <keesj> hmm , two more problems
[15:11] <suihkulokki> keesj: kvm/qemu are convinient when debugging init
[15:12] <keesj> typing start with no argument segfaults and initctl list looks very bad
[15:12] <keesj> http://paste-it.net/raw/public/j18a061/
[15:13] <keesj> suihkulokki: I also have a qemu build running with a nfs export
[15:14] <keesj> I guess there must be a way to attach gdb to the init process when the kernel starts
[15:15] <suihkulokki> keesj: qemu -p
[15:26] <keesj> suihkulokki: I do full system emulation (so also a kernel) als upstart doens't like not being something else then p1
[15:27] <keesj> it's not that easy :p
[15:44] <suihkulokki> keesj: have you tried? qemu -p works well system qemu. you can stop anywhere in the guest execution.
[15:54] <keesj> so that would be the kernel right.
[15:57] <keesj> I do something like this http://paste-it.net/raw/public/ve3bd51/ starting with -p doens't have effect and I need to switch to the qemu control (control-a c) and type gdbserver 1234 to start it :p
[16:02]  * suihkulokki is having trouble shutting down system cleanly using upstart native mode
[20:57] <sadmac2> ion_: ping
[21:13] <ion_> sadmac2: pong
[21:13] <sadmac2> ion_: I'm working on a waitfd implementation, was wondering if you wanted to comment on how the api should look
[21:13] <ion_> I could take a look.
[21:15] <sadmac2> ion_: its not really a code matter. just whatever you'd like the function signature to look like
[21:17] <ion_> I’m afraid i haven’t thought of waitfd enough to have any ideas, but if you shared your ideas, i might have thoughts. :-)
[21:18] <sadmac2> ion_: right now it takes basically the same arguments as waitpid, and the descriptor spits out a stream of siginfos that would come from calling waitpid repeatedly.
[21:19] <ion_> Alright, sounds good.
[21:20] <sadmac2> ion_: the interesting bits are: is specifying such a descriptor for one process useful, and do we need a way to specify n specific processes
[21:20] <sadmac2> ?
[21:23] <ion_> waitfd (..., {pid0, pid1, pid2, NULL}); or waitfd (..., pid0, pid1, pid2) perhaps?
[21:23] <sadmac2> ion_: varargs? in MY system call?
[21:23] <ion_> Thus the former one. :-)
[21:24] <sadmac2> what I dislike there is that it doesn't map easily to the underlying wait4 call
[21:28] <ion_> How about just waitfd (-1, ...), have it spout siginfo_ts for all pids and filter them as appropriate in userspace, in case the app is interested of multiple pids?
[21:30] <sadmac2> ion_: that's a given
[21:30] <sadmac2> ion_: right now you can wait on all, a specific pid, or a group
[21:30] <sadmac2> you just can't do N specific pids
[21:30] <ion_> Yeah, i meant that as an answer to how to do N specific pids
[21:31] <ion_> Capture all, filter them in the app
[21:33] <sadmac2> ion_: certainly it can be done. is it best?
[21:38] <ion_> int fd = waitfd (...); ioctl (fd, WAITFDADDPID, pid0); ... :-)
[21:38] <sadmac2> ion_: no
[21:38] <sadmac2> ion_: the array thing is more likely
[21:44] <ion_> Keybuk probably would give better input.
[21:45] <sadmac2> indeed
[21:46] <sadmac2> but I haven't seen him today
[21:46] <ion_> He’s on a leave AFAIK.
[21:46] <sadmac2> ah
[21:47] <ion_> I’d spend *more* time on IRC when on a leave. :-P
[21:47] <sadmac2> heh
[22:26] <sadmac2> ion_: fun disaster case: what does read(mywaitfd) return when wait() would return ECHILD?
[22:33] <ion_> Hmm :-)
[22:33] <sadmac2> ion_: the read manpage says read can return "other things" depending on what its hooked to.
[22:34] <ion_> siginfo_t with si_pid = 0 or something like that?
[22:34] <sadmac2> no, I think we should throw an error.
[22:35] <sadmac2> timerfd already has a custom error code entry, this will be no different.
[22:35] <ion_> Alright


[03:17] <pygi> jml, hey :)
[04:16] <Peng_> When is the version of bzr LP runs going to be upgraded next?
[04:17] <Peng_> (Not to be pushy; I'd just like to know.)
[04:17] <rockstar> Peng_, what do you mean?
[04:17] <rockstar> Peng_, nevermind, I see what you're asking.
[04:18] <Peng_> :P
[04:18] <rockstar> It'll be updated in two weeks with a fresh version of Launchpad.
[04:18] <Peng_> It's still 1.7.1rc1, which means no btrees.
[04:31] <rockstar> Peng_, yea, there were some hiccups.
[04:32] <beuno> hiccups? in loggerhead?
[04:32]  * beuno server is down
[04:34] <rockstar> beuno, no, LP running bzr 1.7
[04:35] <beuno> rockstar, phew
[04:35] <rockstar> beuno, seems like loggerhead is okay right now, for once.  :)
[04:36] <beuno> rockstar, I'd be very happy if by tomorrow it still was
[04:36] <beuno> means I can focus on other stuff
[04:36] <rockstar> beuno, yup.
[04:36] <beuno> which also includes performance improvements
[04:36] <beuno> just not random ones  :)
[04:37] <rockstar> beuno, :)  Yes, we know too much of that dance.
[04:38] <beuno> now, back to socializing...
[06:12] <ziroday> Hi, are there any local asian ppa mirrors?
[08:43] <newfeats> how do i use launchpad?  i forgot how to set up bazaar.
[09:41] <smihaylov> staging.launchpad.net is not working. It says to report the problem here
[11:51] <christoph_debian> hi! launchpad ppa is refusing my dupload connection and the ppa-guide pointed to this place. can someone help me?
[11:51] <christoph_debian> http://paste.debian.net/22973/
[11:53] <christoph_debian> http://paste.debian.net/22974/
[11:55] <cprov-away> christoph_debian: sure, let me check.
[11:58] <cprov-away> christoph_debian: the ftp server seems to be down, indeed.
[11:58] <christoph_debian> cprov-away, ok that's an explanation
[11:58] <christoph_debian> so there is no problem on my side
[11:58] <christoph_debian> thanks for looking
[11:58] <cprov-away> solution coming in a bit.
[12:00] <cprov-away> christoph_debian: fixed.
[12:00] <christoph_debian> cprov-away, jep working again, thanks
[12:01] <cprov-away> christoph_debian: you are welcome, thanks for reporting the problem here.
[12:44] <pthulin> hi! Bazaar file browser seems to be down
[13:58] <cprov-away> pthulin: loggerhead, can you paste the URL you are using, please ?
[14:00] <cprov-away> pthulin: I see the problem, nevermind.
[17:54] <bpierre> hi
[20:55] <TRD> #openid
[23:33] <psusi> why on earth does searching for packages that contain "2.6.27" on launchpad.net/ubuntu/+search come back with 770 results, that don't contain that string anywhere?
[23:33] <Hobbsee> do they contain it in the page itself?
[23:33] <Hobbsee> as in, not just the title?
[23:34] <psusi> not that I can see or imagine
[23:35] <Hobbsee> oh, i see
[23:36] <psusi> also the overview page shows the package changelog, but not the description... shouldn't that be mentioned somewhere?
[23:37] <Hobbsee> psusi: I expect it's because it's matching only part of that string.  launchpad search is often wrong, when it comes to things like numbers.
[23:37] <Hobbsee> i note that quoting them doesn't seem to work for there, though
[23:37] <psusi> I was wondering about that... like it's matching only "27"
[23:37] <psusi> yea, I tried quoting it too
[23:38] <Hobbsee> you're better off doing a google search, using site:launchpad.net, iirc
[23:39] <psusi> heh
[23:39]  * Hobbsee points at https://edge.launchpad.net/ubuntu/+source/vmware-player-kernel-2.6.15/<IP_ADDRESS>-14 for the description
[23:39] <psusi> how about package descriptions?  does lp show them anywhere?  I'm wandering more about what some of these things are than their version history
[23:40] <psusi> ohh... edge eh? next gen launchpad code?
[23:40] <Hobbsee> yeah
[23:40] <Hobbsee> but that's on normal launchpad too
[23:40] <Hobbsee> (you just have to click on the version of whichever package you want, and it says it)
[23:41] <Hobbsee> doesn't give the short descriptions, though, only the long oness
[23:41] <Hobbsee> perhaps it should give the short ones too
[23:42] <psusi> hrm... I"m clicking on everything I can see and I can't get the description
[23:43] <psusi> wait... I suddenly found it... somehow
[23:44] <psusi> wow... have to go through like 4 clicks from the package overview page to get there
[23:45] <psusi> click on a version, click on the realease, click on releases in ubuntu...
[23:45] <Hobbsee> this is why a lot of people have shortcuts to parts of launchpad
[23:45] <Hobbsee> myself included.
[23:46] <psusi> what do you mean?
[23:47] <psusi> well, now that I've answered the questions that popped up on the way, maybe now I can get back to what I started trying to do... finding the kernel package.... lp doesn't seem to know about linux-image, except for the old 2.4
[23:47] <Hobbsee> linux-image binary comes out of linux-meta, but the source package for all the kernel stuff changed to just 'linux' a while ago
[23:48] <Hobbsee> https://launchpad.net/ubuntu/+source/%s
[23:48] <Hobbsee> as a shortcut
[23:48] <psusi> ahhh
[23:48] <Hobbsee> apt-cache madison is handy for that
[23:49] <psusi> so why don't the binary packages show up though?
[23:49] <psusi> when I search for linux-image?
[23:49] <Hobbsee> because launchpad search is likely borked again
[23:49] <Hobbsee> (ie, i don't know, but i've seen various borked results from it, so it wouldn't surprise me if that were the problem)
[23:50] <psusi> hehe...
[23:59] <flavour> staging.launchpad.net is down? "Sorry, there was a problem connecting to the Launchpad server. "


[08:59] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-screenshooter 1.9.9 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-screenshooter-1-9-9-released-tp60052.html (by andre)
[09:40] <jphilips> for everyone info about the freenode issue - https://lists.ubuntu.com/archives/ubuntu-irc/2021-May/001923.html
[09:43] <jphilips> Unit193: has debian decided on what it will do?
[09:43] <Unit193> Mate, Debian's on OFTC, it'll stay on OFTC> :P
[10:52] <jphilips> oh didn't know about OFTC :D


[03:24] <yookoala> Hello.
[03:24] <yookoala> Anybody here?
[03:33] <lotuspsychje> yes?
[03:33] <lotuspsychje> !ask | yookoala
[03:34] <yookoala> My 17.10 installation logs me out of my desktop session every time I turn off my screen.
[03:34] <yookoala> And I'm not the only one experience that.
[03:35] <yookoala> Discussion: https://ubuntuforums.org/showthread.php?t=2372388&p=13694312&posted=1#post13694312
[03:35] <yookoala> Question: where and how should I report this issue?
[03:36] <lotuspsychje> !bug | yookoala
[03:37] <yookoala> I am not reporting a bug here. I have problem locating the package that's responsible and hence I don't know how best to report that.
[03:37] <yookoala> My current bug report is on gnome-shell:
[03:37] <yookoala> https://bugs.launchpad.net/gnome-shell/+bug/1721428
[03:37] <yookoala> Is there any advice on how to proceed with it?
[03:38] <lotuspsychje> yookoala: yes, test stuff yourself
[03:38] <lotuspsychje> yookoala: try a guest account, try a previous kernel,etc
[03:39] <lotuspsychje> yookoala: and keep your bug alive, by adding new tests
[03:41] <lotuspsychje> yookoala: did you clean install or upgrade?
[03:42] <yookoala> Yes. I have clean installed 3 times and the pattern is the same. I can even reporduce that on the Live session of the installation medium.
[03:42] <yookoala> (Beta 2)
[03:42] <lotuspsychje> hmmm
[03:44] <lotuspsychje> yookoala: might be worth also mentioning your graphics card chipset to bug
[03:44] <yookoala> Sure. Will do it tonight when I'm home.
[03:46] <lotuspsychje> yookoala: the more info the devs have, the better
[03:47] <lotuspsychje> yookoala: finding other users affected also works good, to help solve ing it
[03:47] <Thewafflication> Hello all, I am running the daily build of 17.10 desktop.  After a recent update, my system no longer boots properly with a Nvidia Quadro NVS290 in the system.  How can I report this?
[03:49] <lotuspsychje> !bug | Thewafflication
[03:49] <yookoala> lotuspsychje: Thanks. Will keep the bug updated.
[03:54] <Thewafflication> Thanks, I was reading the page, but I was having a hard time taking it all in.
[03:55] <lotuspsychje> Thewafflication: from a terminal you can just ubuntu-bug package-affected
[03:55] <Thewafflication> yep.  Thank you
[08:38] <CRogers> Hi. 17.10 kept freezing after the updates, so I reinstalled. I decided to avoid disk encryption in case that was causing problems with the swap file.
[08:39] <CRogers> However avoiding the LVM checkbox seems to have the effect that there is no swap file (and no swap partition)
[08:39] <CRogers> Id this intentional?
[08:39] <CRogers> *Is?
[10:27] <dchotas> Hello everyone, I'm on a 17.10b2 fresh install and my wirelress card (qca9377) is making the system hang on shutdown/restart. Can anyone help me track this down?
[10:29] <ducasse> so, are you really on 17.10 or 17.04?
[10:30] <dchotas> ducasse, both, same problem.
[10:35] <ghisvail> is anyone also having an issue with gmail setup in Thunderbird via oauth on 17.10?
[10:35] <ghisvail> works with password auth
[10:36] <ghisvail> but not oauth2 which is the default Thunderbird proposes
[10:36] <ghisvail> the gmail webpage does not respond to clicks
[12:26] <opti> does anyone know if ZFS 0.7.x is going in 17.10 eventually?
[13:45] <StrangeNoises> that's odd. nvidia-387 seems actually better at wayland than it is at xorg now. in that, in xorg the desktop scale settings are ignored. though i don't know that's nvidia's fault (feels like it would be gnome's)
[15:02] <StrangeNoises> yay, hard crash of the gnome desktop, halfway through me quitting chrome. (it was literally half faded-out when everything froze)
[15:02] <StrangeNoises> restarting gdm didn't even help (wouldn't log in afterwards, just froze again). had to reboot.
[15:10] <Asad2005> I tried installing ubuntu-dock from extention tab in tweaks but nothing happen it seems to fail
[17:28] <iratemin> Looking for some assistance on a wifi problem.  Upgraded 17.04 - 17.10 last night.  Wifi connects but continues to show a ? instead of strength.  Unable to resolve any address.  Can ping <IP_ADDRESS>.  Tried forcing DNS to <IP_ADDRESS>,<IP_ADDRESS>. but didnt fix it.
[17:28] <iratemin>  NetworkManager.conf already had wifi.scan-rand-mac-address=no set as others had found a few months ago.
[17:58] <iratemin> any advice?
[21:46] <adamitsch> why area selective print screen doesn't capture image?
[22:07] <vixxo> hello! If I install the current snapshot of 17.10 (I think It's Beta 2) and I keep updating It
[22:07] <vixxo> at the relase date, will I have an installation as if I've downloaded and installed the final relase ?
[22:08] <nacc> vixxo: yes, like any other version of Ubuntu.
[22:08] <vixxo> nacc, ok so at the relase I don't have to reinstall on change repos
[22:08] <vixxo> or*
[22:09] <iratemin> Looking for some assistance on a wifi problem.  Upgraded 17.04 - 17.10 last night.  Wifi connects but continues to show a ? instead of strength.  Unable to resolve any address.  Can ping <IP_ADDRESS>.  Tried forcing DNS to <IP_ADDRESS>,<IP_ADDRESS>. but didnt fix it.
[22:10] <nacc> vixxo: no, the repositories don't change
[22:10] <nacc> vixxo: (and thinking they do sort of misapprehends how Ubuntu works, perhaps)
[22:10] <Thewafflication> iratemin: What wifi hardware is it?
[22:14] <vixxo> nacc, is the beta2 the last one or are there any daily snapshot ?
[22:15] <vixxo> is*
[22:19] <iratemin> I think Intell 3160
[22:20] <Thewafflication> iratemin: Does it show up with lspci?
[22:20] <iratemin> correct, says rev 83
[22:21] <iratemin> it connects to the wifi and I can use lan functions.  can ping ips.  DNS doenst seem to work
[22:26] <mads_RH> Hello. Can anyone tell me if there's any documentation on creating/editing a Gnome 3 theme?
[22:29] <nacc> vixxo: there are daily snapshots as well, i assume
[22:30] <nacc> vixxo: but it doesn't really matter, whatever you download, do an `sudo apt update; sudo apt full-upgrade` on anyways
[22:30] <nacc> vixxo: or use GUI
[22:30] <jbicha> vixxo: http://cdimage.ubuntu.com/daily-live/current/
[22:31] <nacc> jbicha: thanks
[22:45] <vixxo> thanks nacc , thanks jbicha


 I'm having an issue where my shell inside gnome-terminal remembers which dir I'm in when I open a new tab - I don't want that... I'd like it to always start in the home dir. Is there any way to do this?
[19:03] <dsynapse> hi
[19:04] <dsynapse> I have a laptop with a hidpi screen (4k) but if I connect it to a 2k external or 1k external monitor, everything is WAY oversized when going to the smaller monitor.  The "fix" I have right now is that I leave hidpi scaling to 1 which is small on the laptop, but normal on the connected monitors...I was curious if there's a better way of doing this?


[00:04] <mdke> or maybe we should have a single project with different release series; /me doesn't understand launchpad
[00:15] <nixternal> I was just thinking the same exact thing
[00:15] <nixternal> ubuntu-docs, kubuntu-docs, edubuntu-docs, and xubuntu-docs? is that what you were thinking?
[00:18] <mdke> yeah. I think I'll ask the LP list for advice, it's not clear cut. Plus it's ridiculous that you need projects for distro specific things anyway :)
[00:19] <nixternal> hehe, plus it isn't like we have enough teams as it is
[00:19] <nixternal> if we have kubuntu-docs, then just to add more trouble, I will add a team for each section of the docs :)
[00:21] <mdke> no, i was just talking about projects; I think it's fundamental we keep a single team
[00:21] <mdke> now we are using bzr it should be pretty easy to merge changes and share stuff, but we need to keep everyone working together for that
[00:21] <nixternal> yup
[00:23] <nixternal> holy smokes. the kubuntu-docs are still downloading
[00:23] <nixternal> I forgot all about them
[00:24] <mdke> hah
[00:26] <nixternal> 3/4 now
[01:49] <tonyyarusso> mdke: Erm, I'm confused by your marking of https://bugs.edge.launchpad.net/ubuntu-doc/+bug/130680 as Fix Released, as https://help.ubuntu.com/7.04/internet/C/web-design.html is still wrong.
[01:50] <tonyyarusso> mdke: The proper text for the page would be s/NVU/KompoZer/ & s/nvu/kompozer/, and specify that the user will need to enable the universe section of the feisty *backports* repository.
[01:52] <tonyyarusso> mdke: I'm not sure if gnome-app-install supports backports either...if it does it will be under Internet, not Office.  Otherwise Synaptic will be needed.
[01:52] <tonyyarusso> I'm off for a bit, but will be back
[06:56] <posingaspopular> hey all. I'm reading the logs for Ubuntu Open Week (I was afk for most of it) and I'm noticing some small errors in the docs, mainly artitrary stuff like Ubuntu being spelled 'ubuntu' and a missing question mark. Seeing as how it's a wiki, would it be okay for me to go in and make some trivial changes, or would someone get mad at me for it?
[06:57] <posingaspopular> i'm not an offical member of the project because I haven't applied through the CC
[07:12] <posingaspopular> popey: ping. i have a question about the open week logs, which i posted above.
[09:54] <mdke> posingaspopular: yes, on the wiki you can just go straight ahead and edit to improve things
[09:55] <mdke> posingaspopular: there is no need to be a member of the project, although if you're interested in contributing regularly you should sign up to the mailing list and maybe read the https://help.ubuntu.com/community/WikiTeam page
[10:36] <bbyman> is anyone aware of the hardware requirements to host a mirror of ubuntu?
[10:42] <jpatrick> http://www.ubuntu.com/getubuntu/mirror
[10:45] <bbyman> thank you
[12:17] <Sammi__> hello
[13:43] <mpt> hi mdke
[17:11] <posingaspopular> mdke: thanks for the response
[20:04] <TeTeT> does anyone know when help.ubuntu.com will be serving the 7.10 help?
[20:43] <visualdeception> exit
[21:11] <TeTeT> does anyone know what this message is about:
[21:11] <TeTeT> Element include in namespace 'http://www.w3.org/2001/XInclude' encountered in book, but no template matches.
[21:23] <TeTeT> nevermind
[22:22] <mdke> TeTeT: for the first question, in the next few days.


[17:28] <Saviq> xnox: hey, any idea where does -DCMAKE_C_COMPILER value come from in dh_auto_configure when cross-compiling? seems on 16.04 arm64 it points to aarch64-…-cc instead of -gcc, resulting in broken configure
[17:29] <xnox> Saviq, both should be valid, are you telling me that ....-cc doesn't exist? or that it does exist, but behaves not like gcc, and/or ...gcc is expected?
[17:30] <xnox> Saviq, there is debhelper itself, but also there is cross-build patch in cmake source. either one, or both might be doing this.
[17:30] <Saviq> xnox: doesn't exist
[17:30] <xnox> Saviq, also i'm assuming you are using normal cross-compilaton, not the archaic dpkg-cross stuff
[17:30] <Saviq> # aarch64-linux-gnu-cc
[17:30] <Saviq> No command 'aarch64-linux-gnu-cc' found, did you mean:
[17:30] <Saviq>  Command 'aarch64-linux-gnu-gcc' from package 'gcc-aarch64-linux-gnu' (main)
[17:30] <Saviq> aarch64-linux-gnu-cc: command not found
[17:31] <xnox> Saviq, and you do have cross build-depends insteadd for the arm64 right?
[17:31] <Saviq> xnox: normal as in `debuild -aarm64`?
[17:31] <Saviq> # aarch64-linux-gnu-gcc
[17:31] <Saviq> aarch64-linux-gnu-gcc: fatal error: no input files
[17:31] <Saviq> compilation terminated.
[17:31] <xnox> yes that is normal
[17:31] <xnox> crossbuild-essential-arm64 is installed right?
[17:31] <Saviq> yup
[17:32] <Saviq> yeah using mk-build-deps --host-arch arm64
[17:32] <Saviq> the same works on 17.10
[17:32] <xnox> fun
[17:32] <xnox> might be a cross-toolchain bug, rather than anything in debhelper/cmake.
[17:32] <xnox> let me check things and/or possibly ping doko
[17:33] <Saviq> xnox: FWIW the same applies to -c++ vs. -g++
[17:33] <xnox> yeah, checked that too
[17:55] <xnox> Saviq, please use ubuntu-bug and open a bug against debhelper, saying that when crosscompilig, using dh, using dh's buildsystem cmake, it sets incorrect default compiler variables. and request that this commit is SRUed into xenial - https://anonscm.debian.org/git/debhelper/debhelper.git/patch/lib/Debian/Debhelper/Buildsystem/cmake.pm?id=61d575451f028e2bba666d40ee1dedc8c6308f40
[17:56] <xnox> please let me know the bug number, i can prep the sru, but could you please open the bug report such that you get all the notifications about it
[18:00] <Saviq> xnox: ack
[18:01] <Saviq> how did we not see this before... <shake_head />
[18:01] <Saviq> prolly overlay hid it away
[18:04] <Saviq> xnox: bug #1728673
[18:06] <xnox> Saviq, there is a cheat =) install and use debhelper from xenial-backports, as that one is fixed =)
[18:06] <Saviq> xnox: aha, might do that
[23:07] <xnox> Saviq, can you return me a favor?
[23:07] <xnox> what is the best current practice for cmake gmock/gtest?
[23:07] <xnox> -- Found Threads: TRUE
[23:07] <xnox> CMake Error at /usr/src/googletest/googletest/cmake/internal_utils.cmake:149 (add_library):
[23:07] <xnox>   add_library cannot create target "gmock" because another target with the
[23:07] <xnox>   same name already exists.  The existing target is a static library created
[23:07] <xnox>   in source directory "/usr/src/googletest/googlemock".  See documentation
[23:07] <xnox>   for policy CMP0002 for more details.
[23:07] <xnox> Call Stack (most recent call first):
[23:07] <xnox>   /usr/src/googletest/googletest/cmake/internal_utils.cmake:172 (cxx_library_with_type)
[23:07] <xnox>   /usr/src/gmock/CMakeLists.txt:84 (cxx_library)
[23:07] <xnox> ..
[23:07] <xnox> i hate when above happens =/
[23:18] <Saviq> aha :)
[23:21] <Saviq> xnox: have a look at https://github.com/MirServer/mir/compare/1e543d3b885fca34f494a9be4d6f60ec541c4203...277b0a0b13087e190a641f06cd5a745e6d14c181
[23:22] <Saviq> actually that might not be all, but Alan did just redo the gtest/gmock detection in mir https://github.com/MirServer/mir/commits/master
[23:25] <Saviq> so https://github.com/MirServer/mir/blob/master/cmake/FindGtestGmock.cmake should help
[23:25] <Saviq> as it works on Ubuntu and Fedora, too
[23:44] <xnox> hm, why is /usr/src/googletest/googletest/ second given that is the preferred path on both ubuntu and debian in new world order?


[21:18] <krkhan> I have an upstart init (RHEL 6.8) running from /oldroot/sbin/init
[21:18] <krkhan> [root@RHEL68Test1VM ~]# lsof | grep /oldroot init         1 root  txt       REG                8,2   150352  392509 /oldroot/sbin/init
[21:18] <krkhan> It is now the only process left with a handle to /oldroot
[21:18] <krkhan> # fuser -vm /oldroot
[21:19] <krkhan> However, telinit u does not make it restart
[21:19] <krkhan> [root@RHEL68Test1VM ~]# /sbin/telinit u
[21:19] <krkhan> [root@RHEL68Test1VM ~]# fuser -vm /oldroot
[21:19] <krkhan>                      USER        PID ACCESS COMMAND
[21:20] <krkhan> strace output: https://gist.github.com/krkhan/6b4e0c1c530268b525be3bacec7f922c
[21:20] <krkhan> Any ideas on why init isn't restarting properly?