[01:23] <mup> PR snapcraft#2778 opened: Release changelog for 3.9 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2778>
[06:21] <mborzecki> morning
[06:28] <mvo> hey mborzecki
[06:29] <mborzecki> mvo: hey
[07:18] <zyga> good morning
[07:18] <zyga> bug triage duty!
[07:18] <mborzecki> zyga: hey
[07:18] <zyga> hey :)
[07:18] <zyga> I'm working away from office today
[07:21] <zyga> I'll begin the day with some reviews
[07:21] <zyga> then go to UX docs
[07:30] <mup> PR snapd#7682 opened: [RFC] add kernel remodel undo tests and fix undo <Created by mvo5> <https://github.com/snapcore/snapd/pull/7682>
[07:30] <zyga> mvo: small -1 comment on the 2.42.1 cherry pick PR
[07:32] <zyga> mvo: 2.42 PR failed on mount ns test
[07:32] <zyga> mvo: the failure indicates it is a missing lxd cleanup
[07:32] <zyga> mvo: I think mborzecki sent a patch to master to fix that
[07:32] <zyga> mvo: you may want to cherry pick that as well
[07:32] <zyga> mvo: for context, this is how such failure looks like:
[07:32] <zyga> https://www.irccloud.com/pastebin/Zxxde5Sh/
[07:34] <mborzecki> zyga: mvo: this one? https://github.com/snapcore/snapd/commit/03f3210eadeb47ee3c286e2c4fb242ce67365c86#diff-413b2f27493a11371053198f7020e23f
[07:34] <zyga> I think so
[07:47] <zyga> abeato: gentle ping about https://github.com/snapcore/snapd/pull/7603
[07:47] <mup> PR #7603: interfaces: add dpdk and hugepages interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7603>
[08:04] <pstolowski> morning
[08:04] <zyga> hey pawel
[08:09] <mborzecki> pstolowski: hey
[08:33] <mvo> zyga, mborzecki thank you, I have a look
[08:39] <pedronis> mvo: hi, is #7624 ready for review?
[08:40] <mup> PR #7624: snap: make `snap download` download via snapd if available <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
[08:42] <mvo> pedronis: yes
[08:44] <mvo> store seems to give 503 right now, we have lots of red
[08:45] <mup> PR snapd#7663 closed: tests: add 14.04 canonical-livepatch test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7663>
[08:49] <pedronis> mvo: I made some initial comments in 7682
[08:50] <mvo> pedronis: yeah, excellent
[08:51] <mvo> pedronis: I was wondering if deviceCtx is the way and you suggested it for oldModel so I will add it. thank you!
[08:51] <mvo> pedronis: will make the diff a bit bigger (with test updates) so I may do it as a separate PR (?)
[08:51] <mvo> pedronis: and *thank you* for the  feedback!
[08:55] <pedronis> mvo: np
[08:55] <pedronis> did a quick on 7624 too
[08:56] <mvo> pedronis: thank you!
[09:01] <mup> PR snapd#7683 opened: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <https://github.com/snapcore/snapd/pull/7683>
[09:09]  * dot-tobias good morning
[09:14] <mvo> ackk: did you had a chance to test the performance of snaps inside lxd recently? we fixed some performance issues and iirc the maas team mentioned they were hit by the slow performance inside lxd
[09:15] <ackk> mvo, hi, I haven't tried it recently. our issue was with squashfuse being super-slow, and particularly visible with the maas snap since it's quite big
[09:15] <ackk> and a lot of small (python) files that get read at startup
[09:15] <mvo> ackk: yeah, that should be fixed in current core
[09:16] <ackk> mvo, nice, I'll give it a try, let you know how it goes
[09:16] <mvo> ackk: thank you!
[09:17] <ackk> mvo, thank you for the update
[09:22] <Chipaca> hmmmmmmm
[09:22] <Chipaca> morning folks
[09:31] <Chipaca> mvo: tried reviewing the download one but all i'm seeing is bad news so i'm going to finish my coffee and look back later, maybe i'm just grumpy
[09:33] <ackk> mvo, I'm getting "Run configure hook of "maas" snap if present (run hook "configure": cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied)" when installing the maas snap, could it be something in the configure hook or is it snapd itself?
[09:42] <dot-tobias> mvo: Is there a rough date for the next stable core release? Just to get a sense if it'll be this week, next or later.
[09:45] <Chipaca> ackk: https://forum.snapcraft.io/t/cannot-perform-readlinkat-on-the-mount-namespace-file-descriptor-of-the-init-process-permission-denied/6743/7
[09:46] <mvo> Chipaca: oh no! I'm ready for bad news, I will steady myself
[09:46] <ackk> Chipaca, thanks
[09:47] <ackk> Chipaca, so I need the snapd snap, right?
[09:48] <Chipaca> ackk: … no?
[09:49] <Chipaca> ackk: sorry i'm not sure i'm being helpful at all here
[09:49] <Chipaca> ackk: are you running this on 14.04?
[09:49] <ackk> Chipaca, no, bionic
[09:49] <Chipaca> ackk: then it's not that, probably
[09:49] <ackk> Chipaca, spinned a fresh bionic container, tried snap install --edge maas
[09:50] <Chipaca> ackk: what's in 'snap version'?
[09:50]  * Chipaca should add a --irc flag to snap version
[09:51] <ackk> Chipaca, one sec, I'm testing with an up-to-date bionic now since I didn't update snapd (from the deb) there
[09:52] <Chipaca> ackk: in which case installing core or snapd would've also fixed it via snapd updating itself
[09:53] <ackk> Chipaca, fwiw https://paste.ubuntu.com/p/2rCzjTtrMM/
[09:53] <ackk> I'm trying to install the maas snap but the store is flaky
[09:54] <ackk> yeah it's not working
[09:57] <mvo> ackk: that error rings a bell, we saw this before, probably zyga knows more
[09:57] <Chipaca> ackk: "yeah it's not working" same error, or now store issues?
[09:57] <Chipaca> ackk: the store is having some issues now yes
[09:57] <ackk> Chipaca, store errors, sorry
[09:57] <ackk> yeah I can't test right now
[09:58] <ackk> mvo, btw is "core" still required for installing core18 snaps?
[09:58] <ackk> mvo, installing maas didn't install it
[09:58] <mvo> dot-tobias: iirc we did cherry pick your fix, right? the plan is to release 2.42.1 to beta this week and stable next week (if testing is all good). worst case stable in the week after that. but there is one pending branch that needs reviews :/
[09:59] <mvo> ackk: core should not be required anymore
[09:59] <mvo> ackk: on fresh systems snapd will now install core18 and snapd
[09:59] <mvo> ackk: if you request a core18 only snap
[10:00] <mup> PR snapd#7676 closed: many: cherry pick test updates for 2.42 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7676>
[10:00] <dot-tobias> mvo: Yes, it's been merged to master (though all credit to zyga). Thanks for the timeframe, I can work with that 😊
[10:01] <mvo> dot-tobias: was it cherry-picked into release/2.42?
[10:01] <mvo> dot-tobias: it will only be in 2.42.1 if it was cherry-picked, if not please point me to the PR
[10:01] <dot-tobias> mvo: Checking
[10:01] <mvo> dot-tobias: then I can (probably) cherry-pick it, I remember it was a pretty straightforward fix
[10:02] <dot-tobias> mvo: Actually, it doesn't seem to be cherry-picked into release/4.42 yet. https://github.com/snapcore/snapd/pull/7655 is zyga's PR
[10:02] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[10:04] <mvo> dot-tobias: ok - now it is :) thanks for checking
[10:06] <dot-tobias> mvo: 🙏🎉
[10:08] <mup> PR snapd#7684 opened: tests: disable mount-ns test in release/2.42 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7684>
[10:18] <pedronis> pstolowski: what's the status of #7601 ?
[10:18] <mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
[10:19] <pstolowski> pedronis: i've the tab open and going to address Jamie's comment, will do today
[10:19] <pedronis> ok, thx
[10:28] <pedronis> mvo: did you make a card or something about unifying the default-provider extracting code?
[10:29] <mvo> pedronis: uh, not yet, let me do this now
[10:29] <pedronis> thx
[10:34] <Chipaca> mvo: what's that about a pending branch that needs reviews?
[10:38] <Chipaca> mvo: i see one pr each in both 2.42 and 2.43 milestones, but it looks like the 2.42 one needs input from foundations and the 2.43 has all the reviewage it can handle ;-p
[10:43] <mvo> Chipaca: the most important one is the foundations input
[10:43] <Chipaca> yeh
[10:43] <Chipaca> xnox is allegedly off gallivanting though :-p
[10:44] <mvo> Chipaca: yeah, I can try to get a re-review from vorlon for #7661
[10:44] <mup> PR #7661: packaging: tweak handling of usr.lib.snapd.snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/7661>
[10:44]  * Chipaca throws flowers at vorlon
[10:45] <mvo> Chipaca: should we have a HO about 7624 ? do you think there is something fundamentally wrong with it?
[10:45] <Chipaca> mvo: just started going through it again
[10:45] <Chipaca> mvo: download-via-snapd needs to grow a 'resume' thing, but that's a separate pr
[10:45] <mup> PR snapd#7685 opened: snapstate,devicestate: make OldModel() available in DeviceContext <Created by mvo5> <https://github.com/snapcore/snapd/pull/7685>
[10:46] <mvo> Chipaca: oh, yeah, thats a good point
[10:59] <ackk> mvo, I still see snapfuse at 100%cpu but perhaps that's expected?
[11:01] <pedronis> mborzecki: I did a first pass on 7665
[11:03] <mborzecki> pedronis: thanks
[11:03] <pedronis> mborzecki: some questions/wonderings there
[11:03] <ackk> mvo, yeah, it seems it's still quite slow in the case of maas
[11:06] <mvo> ackk: hm, ok. it should be quicker than before, can you see what version of snapd is running inside your lxd?
[11:10] <pedronis> Chipaca: hi, could you answer the question about hidden commands vs autocomplete toward the end of comments in #7589 ?
[11:10] <mup> PR #7589: cmd/snap: add ability to register "snap internal" commands <⛔ Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
[11:12] <ackk> mvo, https://paste.ubuntu.com/p/2rCzjTtrMM/
[11:14] <Chipaca> pedronis: probaboy
[11:14] <Chipaca> probably?
[11:19] <Chipaca> mvo: review done. Less bad news than this morning early.
[11:19] <Chipaca> mvo: still a little bad
[11:32] <Chipaca> siigh
[11:33] <Chipaca> today's already been a long day
[11:33] <Chipaca> i think i need more coffee
[11:33] <Chipaca> starting to chase shadows
[11:35] <mup> PR snapd#7686 opened: systemd: handle preseed mode <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
[11:36] <pstolowski> uhm... 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"
[11:37] <mborzecki> pstolowski: yeah
[11:38] <mborzecki> in the morning i got some 503s as well
[12:05] <mvo> Chipaca: sorry for the delay, I was in a meeting - you say this gives me no progress bar for snpa donwload but iirc we don't have one today either. or am I missing something?
[12:10] <mvo> Chipaca: hm, the code says there is a download progress, I'm just not seeing it, probably an issue on my side, I have a look. nevermind
[12:10] <pedronis> mvo: Chipaca: I meade a suggestion there
[12:11] <pedronis> *made
[12:11] <pedronis> not sure it fits or not, it was a quick thought
[12:11] <pedronis> Chipaca: thanks for the answer, I enquired some more :)
[12:19]  * zyga is at a service center and may miss standup
[12:20] <zyga> I'll make up the time in the evening to do all my responsibilities
[12:20] <zyga> sorry :/
[12:23] <Chipaca> mvo: i mean, try it: 'snap download core' gives you a nice progress bar
[12:23] <Chipaca> pedronis: did you enquire, or did you inquire?
[12:25] <mvo> Chipaca: yeah, I did something wrong, thanks for noticing this
[12:25] <pedronis> Chipaca: afaict I meant enquire
[12:26] <Chipaca> pedronis: phew
[12:27] <pedronis> pstolowski: reviewed #7683
[12:27] <mup> PR #7683: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <https://github.com/snapcore/snapd/pull/7683>
[12:31] <pedronis> pstolowski: thank you
[12:31] <pedronis> pstolowski: I also made a general comment in 7686
[12:32] <pstolowski> pedronis: ty
[12:33] <sergiusens> mvo, jdstrand, zyga: any assistance with https://paste.ubuntu.com/p/KXHFrbYmvZ/ ? This is on an autopkgtest env for 18.04/amd64
[12:36] <sergiusens> journal show Oct 29 05:37:28 autopkgtest snapd[1828]: handlers.go:460: Reported install problem for "gtk3-hello" as 2f8217c0-fa0e-11e9-b619-fa163e102db1 OOPSID
[12:37] <mvo> sergiusens: are these instances resource constrained? it looks like a malloc() (well, "new") wasn't successful, maybe(?) it requested too much memory
[12:37]  * mvo needs to urgently get lunch though before he can look deeper
[12:38] <sergiusens> mvo: get lunch, I am not so worried about the failure itself (as I know our test works on google/spread)
[12:46] <pstolowski> pedronis: i've updated #7601, would you like to take a look at this as well or can it land when green?
[12:46] <mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
[12:46] <pedronis> pstolowski: no, it's probably fine if zygmunt and jamie are ok with it
[12:48] <pstolowski> ack
[12:48] <pedronis> pstolowski: I mean, I can look if you think I should
[12:49] <pstolowski> pedronis: maybe just check the comment & response re locking there. i don't think there was a deep reason it was done the way it was
[12:49] <pedronis> ok
[12:50] <pedronis> pstolowski: I put it in my queue, I will also merge it if everything is fine
[12:55] <pstolowski> pedronis: thanks
[13:17] <Chipaca> pedronis: should I do the 'hidden-but-completed' thing?
[13:17] <pedronis> Chipaca: if you can, and is not too distracting, yes
[13:17] <Chipaca> it's not, right now
[13:22] <Eighth_Doctor> popey_, zyga, mborzecki, mvo: I've finally introduced `snapd` for EL8
[13:23] <Eighth_Doctor> that was a more annoying bringup than I thought it would be
[13:23] <mborzecki> but it's done now :P
[13:24] <Eighth_Doctor> yeah, I'll do a PR to snapd upstream with a spec sync soon
[13:25] <Eighth_Doctor> I haven't done one of those in a while
[13:30] <zyga> Eighth_Doctor: thank you for persisting, congratulations!
[13:31] <Eighth_Doctor> between broken architectures and missing packages due to incomplete imports, I wasn't certain EL8 was ever going to get built
[13:36] <mborzecki> Eighth_Doctor: if you take away these problems, there's no more excitement in getting things done
[13:36] <Eighth_Doctor> I guess so
[13:37] <Eighth_Doctor> but I didn't enjoy people bitching about updated snapd releases being held up
[13:43] <jdstrand> sergiusens (cc mvo, zyga): that is the memory consumption bug
[13:44] <jdstrand> sergiusens (cc, mvo, zyga): can you try edge?
[13:44] <Chipaca> mvo: silly question: i just noticed the completion helper for 'snap' in 1604 is ancient, is the update on its way / stuck somewhere?
[13:44] <jdstrand> sergiusens: zyga did excellent PR work to fix that which is committed, and may even end up in 2.42.2 (not sure of the status of that)
[13:45] <jdstrand> or is it 2.42.1 (did I say I'm not sure of the status of 2.42.N? :)
[13:47] <mvo> Eighth_Doctor: e8> nice! thanks so much!
[13:48] <mvo> jdstrand: 2.42.1 once we get it out, pending one review from xnox or vorlon (7661)
[13:48] <mvo> Chipaca: could you tell me some more details? is the completion helper part of bash-completion there?
[13:49] <Chipaca> mvo: I mean data/completion/snap that gets shipped to /usr/share/bash-completion/completions/snap
[13:49] <jdstrand> mvo: cool, thanks :)
[13:50] <Chipaca> mvo: this is not about completion of snapped commands
[13:50] <jdstrand> mvo: I wouldn't mind 2.42.1 with that change myself :)
[13:50] <Chipaca> mvo: but of the snap command itself
[13:50] <Chipaca> mvo: an easy way to check: snap debug <tab>, vs snap debug model <tab>
[13:50]  * zyga blushes :-)
[13:51] <mvo> jdstrand: I cherry picked it already :)
[13:51] <Chipaca> mvo: with the one in-tree, that second one should not offer all debug commands all over again
[13:52] <mvo> Chipaca: what do we need to do to update it? (sorry, I still don't have the full picture but hopefully I'm getting there :)
[13:52] <Chipaca> mvo: I don't know :) the one in-tree was fixed in August
[13:53] <Chipaca> mvo: how does the .deb pick that up? maybe the .deb is older than august?
[13:53] <Chipaca> or the release
[13:54] <Chipaca> i guess august on master means september release so it's not unpossible for this to be alright just lagged
[13:54] <mvo> Chipaca: aha, got it now - yes, I think we want 2.42.1
[13:54] <mvo> Chipaca: we have no deb update in a while because of various issues
[13:54] <Chipaca> ah
[13:54] <Chipaca> a'ight then
[13:54] <mvo> Chipaca: one of which is this postinst PR review :)
[13:54] <Chipaca> mvo: are we going to be able to update before 16.04.<whatever>?
[13:55] <Chipaca> mvo: because images don't ship packages from -updates so snapcraft hates us
[13:55] <Chipaca> because there's all these neat features they can't depend on or sth
[13:55] <Chipaca> anyway, snowballing moaning doesn't hep
[13:55] <Chipaca> help*
[13:55] <Chipaca> i need to get ready for standup
[13:55] <mvo> Chipaca: woah, let me look
[13:58] <mvo> Chipaca: me too - I fixed the issues in download but I guess this could need a refactor to unify a bit of this code
[13:59] <mup> PR snapd#7687 opened: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7687>
[14:00] <jdstrand> mvo: re cherrypic, yep, thanks! looking forward to 2.42.1 in a channel somewhere :) (not pushing, just enthusiastic :)
[14:01] <mvo> jdstrand: :)
[14:02] <jdstrand> mvo: also, I heartily endorse the approach for snap-confine in 7661
[14:02] <jdstrand> mvo: that'll be real nice to finally have fixed :)
[14:06] <mvo> jdstrand: \o/
[14:06] <sergiusens> jdstrand: cannot easily try edge on autopkgtests, will try later though, thanks
[14:13] <Chipaca> cachio: BTW there are 63520800 ways of getting 3 tests out of 400 so the fact that you found a failing combination is quite something
[14:18] <jdstrand> sergiusens: with the fact that it is a gtk3-hello demo which I bet is using the content interface, I'm inclined to say, don't worry about it for now since it will be fixed soon. if it is happening after 2.42.1 is in stable, report back (cc mvo)
[14:18]  * mvo had the same thoughts
[14:26] <cachio> Chipaca, there are pretty good search techniques :)
[14:26] <jdstrand> pstolowski: hey, fyi, this is what I meant to say before: https://github.com/snapcore/snapd/pull/7601#discussion_r340101086
[14:26] <mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
[14:35] <mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
[14:35] <mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[14:38] <mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
[14:38] <mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[14:44] <pstolowski> jdstrand: ok, i see, right. i was thinking if the unlocking/locking there was deliberate or not. semantically it looks irrelevant to me and if it had any sideffects it would be a bit fishy tbh. either way it's impossible to test / prove. maybe pedronis can recall something
[14:53] <pedronis> pstolowski: I'm having a break and then I will look at that PR
[14:55] <pstolowski> ty
[14:57] <om26er> private jobs have taken over https://launchpad.net/builders ...
[15:00] <cachio> mborzecki, hey, could yo utake a look to #7681
[15:00] <mup> PR #7681: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
[15:00] <cachio> please
[15:00] <mup> PR snapd#7688 opened: cmd/snap: make completion skip commands (& opts) that ask for it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7688>
[15:00] <cachio> It is confirmed the start-limit-hit issue on core-18
[15:01] <Chipaca> om26er: private jobs do that
[15:05] <jdstrand> pstolowski: ack, not a blocker or anything. thanks for thinking about it
[15:07] <pstolowski> jdstrand: sure, thanks for the review!
[15:15] <pstolowski> mvo, pedronis: ah, i forgot about the fix for the issue of services & install hook that we want to fix for pre-seeding, and it needs ijohnson's #7341
[15:15] <mup> PR #7341: many: introduce package seed and seedtest <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7341>
[15:16] <pstolowski> i mean #7431
[15:16] <mup> PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
[15:16] <ijohnson> pstolowski: I should update that PR with your suggestions later today, I implemented them just need to finish testing that the spread tests still work with my changes
[15:17] <pstolowski> ijohnson: that's great, thanks
[15:17] <Chipaca> mvo: you mind if i push some code to #7624?
[15:17] <mup> PR #7624: snap: make `snap download` download via snapd if available <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
[15:18] <Chipaca> not saying i will, but i might
[15:22] <ijohnson> hmm it's rather confusing for github's PR diff files view that for a line changed, the "unexpanded" snippet which shows the function/unindented block of code the line is in doesn't account for the fact that the "unexpanded" part itself also changed
[15:23] <cachio> zyga, could yo uplease re-review #7681
[15:23] <mup> PR #7681: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
[15:23] <cachio> I added a fix there
[15:23] <cachio> thansk
[15:24] <pedronis> pstolowski: mmh, are we losing the timing in 7601 ?
[15:28]  * cachio lunch
[15:30] <pstolowski> pedronis: we're passing it to SetupMany, it's measured there
[15:30] <pedronis> ah
[15:30] <pstolowski> indentation is a bit weird
[15:34] <pedronis> pstolowski: sorry, yes, I missed it
[15:34] <pedronis> pstolowski: I commented a bit more on the lock thing
[15:35] <pedronis> pstolowski: and gave my +1
[15:35] <pedronis> pstolowski: it can land when it is green
[15:36] <pedronis> Chipaca: I commented on 7688
[15:36] <Chipaca> pedronis: i saw
[15:36] <Chipaca> pedronis: we can always think more :)
[15:36] <pedronis> Chipaca: I can see a couple of ways out
[15:36] <zyga> cachio: doing so now
[15:36] <pstolowski> pedronis: thank you, yes, exactly what i was thinking
[15:38] <zyga> cachio: interesting
[15:38] <zyga> cachio: does this mean we can make journalctl fail if we just restart the service in a loop?
[15:38] <pedronis> Chipaca: we could add code to stick (hidden) at the end of any description of hidden command that don't have it on their own. And have a flag to stop that
[15:38] <zyga> cachio: if we could do that without any snapd stuff in the way, we could report a bug upstream
[15:38] <zyga> cachio: it feels like explicit requests should not be counted towards the number of after which the service is not started
[15:39] <Chipaca> pedronis: a contra to that is that we'd have to reflect the structs ourselves
[15:40] <pedronis> Chipaca: ?
[15:40] <Chipaca> to get the other flag
[15:40] <Chipaca> unless you meant a flag to addCommand
[15:40] <Chipaca> not a struct tag
[15:41] <Chipaca> (my first read was that you meant a struct tag, like hidden:"true" completed:"true"
[15:41] <pedronis> Chipaca: we have our own flags on cmdInfo
[15:41] <Chipaca> right
[15:41] <zyga> kenvandine: hey, personal question
[15:42] <zyga> kenvandine: where can I report a bug on gnome-shell where someone I can talk to will look
[15:42] <kenvandine> zyga: 7
[15:42] <kenvandine> :)
[15:42] <pedronis> Chipaca: can we key on Item somehow? can it be partial, how does that bit work?
[15:42] <zyga> kenvandine: I have this pet bug of mine that is very frustrating
[15:42] <zyga> kenvandine: and probably something silly somewhere
[15:42] <kenvandine> ping Trevinho :)
[15:42] <zyga> kenvandine: high-dpi in vmware results in white background
[15:42] <zyga> low-dpi is ok,
[15:42] <zyga> background shows
[15:42] <Trevinho> pong
[15:42] <zyga> kenvandine: all you need to do is to toggle 200% zoom
[15:42] <zyga> and you get white background
[15:42] <pedronis> Chipaca: I mean, we could also keep global maps Item -> flags, or Description -> flags (assuming they are unique enough)
[15:42] <kenvandine> that's annoying
[15:42] <zyga> this bug was around for about a year now
[15:43] <zyga> but I never reported it, hoping someone would notice and it wouldn't be just my machine
[15:43] <zyga> but now I just want to report it
[15:43] <zyga> because maybe my machine has something useful on it
[15:43] <zyga> it happens in vmware fusion on both my macbook and my imac
[15:43] <zyga> it happens in not just ubuntu
[15:43] <Trevinho> mhmh, ah so the problem is the guest
[15:43] <zyga> all gnome shell is affected
[15:43] <zyga> (opensuse, fedora, debian and ubuntu for sure)
[15:43] <zyga> perhaps it's some texture size limit
[15:43] <zyga> or something of this nature
[15:43] <zyga> but
[15:44] <zyga> it's a new thing
[15:44] <zyga> it did work great about a year ago, using same older VMs works good now
[15:44] <Trevinho> zyga: always in x11 or wayland?
[15:44] <zyga> let me check
[15:44] <zyga> x11
[15:44] <zyga> but double checking now
[15:44] <Chipaca> pedronis: go-flags figures out what things to complete, and we then get the list of whole names even if it's completing a partial
[15:44] <Trevinho> zyga: and also using new vmware + old ubuntu?
[15:44] <zyga> yes
[15:44] <zyga> Trevinho: it's just new gnome/kernel perhaps that causes this
[15:45] <zyga> one sec
[15:45] <zyga> Trevinho: it happens in x11, let me log out into wayland
[15:45] <pedronis> Chipaca: ok, so it sound we could make a map in addCommand as well, instead of looking at the description
[15:45] <zyga> it's also 100% reproducible on my machines using latest version of everything, I can toggle back and forth
[15:45] <pedronis> though in principle I have nothing agaisnt sticking (hidden) there,  it's true
[15:46] <zyga> Trevinho: it affects x11 and wayland equally
[15:46] <zyga> everything works great at 100% zoom in 5K
[15:46] <zyga> in 200% zoom everything but background displays fine
[15:46] <zyga> looking at logs now
[15:46] <om26er> Is https://snapcraft.io/blog/handy-snapcraft-features-remote-build in the stable channel now ? Also can we use that to build private projects and how is the code actually pushed to launchpad builders ?
[15:46] <Chipaca> pedronis: yes, we could. Assuming you mean a map of just things to skip, and there weren't synonyms where we wanted to skip only one of them, then it'd probably work
[15:47] <pedronis> Chipaca: yes, just the one to skip
[15:47] <om26er> IOW is it secure ?
[15:47] <Chipaca> pedronis: note we only get the last command
[15:47] <pedronis> ?
[15:47] <zyga> Trevinho: in wayland, toggling 200% zoom gives me
[15:47] <Chipaca> om26er: it is secure but as it says there your build is public
[15:47] <Chipaca> pedronis: 'snap debug foo' → you get "foo"
[15:47] <zyga> Trevinho: wayland journal fragment after setting 200% zoom https://www.irccloud.com/pastebin/beonJbDn/
[15:48] <pedronis> Chipaca: I see, so we cannot use item
[15:48] <pedronis> but we can use description
[15:48] <pedronis> assuming they are unique
[15:48] <pedronis> and they should be really
[15:48] <pedronis> except for a few degenerate cases that we can accept
[15:48] <pedronis> like "Internal (hidden)"
[15:49] <zyga> Trevinho: x11 journal fragment after setting 200% zoom https://www.irccloud.com/pastebin/6Wm8NA5u/
[15:49] <zyga> Trevinho: I can report that, just point me the way
[15:49] <pedronis> Chipaca: shortHelp is description ?
[15:49] <zyga> thank you for looking and I'd love to know if you have any ideas
[15:49] <pedronis> for commands
[15:49] <Chipaca> pedronis: yes
[15:50] <Trevinho> zyga: don't think journal is saying anything wrong, unless edid, but shouldn't matter for this
[15:50] <zyga> yeah, apart from the background there are no problems
[15:50] <Trevinho> zyga: better if you report it at https://gitlab.gnome.org/GNOME/mutter/issues
[15:50] <zyga> Trevinho: nothing fails, 3D works, all the apps work flawlessly
[15:50] <zyga> Trevinho: sure thing
[15:50] <om26er> @chipaca that's not a problem, we want to release the software for everyone but the source code model is closed for now
[15:51] <Chipaca> om26er: but if the build is public, the source is public
[15:51] <Chipaca> om26er: as i read it at least
[15:52] <Trevinho> zyga: also when setting 200 the WM is using native 2x or zooming?
[15:52] <Chipaca> om26er: maybe confirm with somebody that knows :)
[15:52] <Trevinho>  xprop -root RESOURCE_MANAGER
[15:52] <zyga> Trevinho: I don't know the difference
[15:52] <Trevinho> and maybe you can -spy that whiele changing the value
[15:52] <zyga> let me get that output for you :)
[15:52] <zyga> sure
[15:52] <Trevinho> (just use -spy :))
[15:52] <Trevinho> zyga: well, it's not stretched I imagine, right?
[15:53] <Trevinho> it's just asking the WM to use proper scaling I assuem
[15:53] <zyga> Trevinho: no, it's all nice and pretty all the time
[15:53] <Trevinho> assume*
[15:53] <pstolowski> pedronis: was your suggestion to also avoid 'preseed' term in the apparmor/security backend?
[15:53] <om26er> Chipaca not sure who works on the build service these days, is Colin (cj watson) the right person ?
[15:54] <pedronis> pstolowski: no, there is fine I think
[15:54] <pedronis> I mean it's ok if you want to use a different term
[15:54] <pedronis> like DiskOnly or something
[15:54] <pedronis> but preseed would work too
[15:54] <pstolowski> pedronis: ok, cause emulation indeed wouldn't fit
[15:54] <zyga> Trevinho: RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t96\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t24\nXcursor.theme:\tYaru\n"
[15:54] <zyga> Trevinho: not sure how to use -spy
[15:55] <Trevinho> just pass -spy, it will print you something if it changes
[15:55] <Trevinho> zyga: that's at 200%?
[15:55] <zyga> Trevinho: yes
[15:55] <zyga> Trevinho: let me give you output at both
[15:55] <zyga> I'm in x11 now
[15:55] <zyga> though that matters for xprop
[15:55] <Trevinho> weird, so... mh not really using internal scaling...mhmh
[15:56] <zyga> https://www.irccloud.com/pastebin/oWGjJE9b/
[15:56] <Trevinho> a scaled system should have Xft.dpi = scale*96
[15:56] <zyga> this ix xprop -root -spy
[15:56] <zyga> *this is xprop -root spy
[15:56] <zyga> when going from low to high dpi
[15:56] <zyga> Trevinho: let me double check if I got those initial output bits right
[15:56] <Trevinho> ah, ok it changes to 192, it makes sense then
[15:56] <Trevinho> I saw already, yeah... it's just showing things at 2%
[15:57] <zyga> Trevinho: so at 200% it is: RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t192\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t48\nXcursor.theme:\tYaru\n"
[15:57] <Trevinho> so, weird. Cause there's should no difference between that and normal 2x scaling (normal = native)
[15:57] <zyga> Trevinho: and at 100% it is
[15:57] <zyga> RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t96\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t24\nXcursor.theme:\tYaru\n"
[15:57] <Trevinho> yeah makes sense
[15:57] <pedronis> Chipaca: I played a bit and indeed our description are basically unique, so that idea would work
[15:57] <zyga> Trevinho: anything else I can try?
[15:57] <Chipaca> pedronis: is it worth it?
[15:58] <Trevinho> zyga: mh, no in the top of my head, should probably do some deeper debugging.
[15:58] <zyga> ok
[15:58] <zyga> let me report the issue
[15:58] <pedronis> Chipaca: less magic, so yes
[15:58] <zyga> what to include in the report?
[15:58] <pedronis> Chipaca: it's fairly simple I think
[15:58] <Trevinho> zyga: I use vmware player here, and I don't think that has the option visible
[15:59] <pedronis> Chipaca: anyway probably simple enough that I should pick up your PR and try to fit it in there
[15:59] <Trevinho> but I assume I can have the same by changing manually the conf fike
[15:59] <Trevinho> file*
[15:59] <cmatsuoka> zyga: patriciadomin needs more space for snap data, would it work if she just moves /var/snap to a different filesystem?
[15:59] <zyga> Trevinho: I think it's a fusion thing, on a high-dpi display you get to choose to give the VM the full resolution or to give it a scaled down version (e.g. for older OSes)
[15:59] <zyga> cmatsuoka: yes, it should work perfectly
[15:59] <pedronis> Chipaca: but maybe your point is that you think that by default hidden commands should auto complete?
[16:00] <cmatsuoka> zyga: thanks!
[16:00] <Trevinho> zyga: if you instead change the option internally from the VM only?
[16:00] <ijohnson> pedronis: reviewed #7679
[16:00] <mup> PR #7679: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
[16:00] <Trevinho> i.e from g-c-c, as that's what I'm doing here all the times, but never had such issue
[16:00] <zyga> Trevinho: this is internally in the VM
[16:00] <zyga> Trevinho: I didn't change the vmware fusion settings
[16:00] <zyga> Trevinho: (having that high-dpi screen really makes me want to use the high-dpi for daily work)
[16:00] <Trevinho> ah, but well fusion I suppose is doing something different the
[16:01] <zyga> Trevinho: so to be clear, the VM on the host has a setting toggled to enable "retina" resolution (native resolution of the panel)
[16:01] <zyga> Trevinho: if you toggle that down the VM gets told that resolution is half in each dimension
[16:01] <Trevinho> although I've not used this in a very high dpi screen, but simulating it shoudl be the same
[16:01] <zyga> Trevinho: and there's no 200% zoom to choose from
[16:01] <Chipaca> pedronis: no, i'm not sure what my point is, but that is not it :)
[16:01] <pedronis> Chipaca: ok, I'll try to push a PR based on yours and then we can discuss something concrete
[16:02] <Chipaca> pedronis: ok
[16:02] <Trevinho> zyga: ah, I see then. But well in the normal case it should just give the same display size so...
[16:02] <zyga> yeah
[16:02] <pedronis> Chipaca: in a bit
[16:02] <Trevinho> basically the same of the player
[16:02] <Trevinho> zyga: by luck changing the bg image rebuilds anything and makes it appear or no?
[16:02] <zyga> Trevinho: let me check
[16:02] <zyga> but I think not
[16:03] <Trevinho> in theory should not be the same of what happens on resolution changes, but.. sometimes.. :)
[16:03] <zyga> Trevinho: nope, no luck
[16:03] <Trevinho> zyga: this seems close https://gitlab.gnome.org/GNOME/gnome-shell/issues/1175
[16:03] <zyga> yeah!
[16:05] <Trevinho> could be texture size problem indeed
[16:05] <zyga> Trevinho: https://gitlab.gnome.org/GNOME/mutter/issues/894
[16:05] <Trevinho> I suppose in some cases it should be tiled
[16:05] <zyga> Trevinho: I'll grab lunch (starving) and be back soon
[16:05] <zyga> Trevinho: oh actually, I think I could set a background *color* correctly
[16:05] <zyga> now this option seems gone
[16:06]  * Chipaca ⇝ tea
[16:06] <Trevinho> zyga: I've marked as duplicate, feel free to copy&paste that text to the original bug so we don't loose the comment :)
[16:06] <Trevinho> sorry, I linked it too late
[16:08] <Trevinho> looks like something introduced during the 3.32 cycle though, so if running a machine with 3.30 is working, maybe would be nice to bisect 3.32 branches
[16:12] <om26er> I have python3.8 in a snap and a snapcraft plugin allowing other snaps to use python3.8 https://forum.snapcraft.io/t/introducing-python3-8-as-a-snap/13923
[16:15] <pedronis> ijohnson: thansk for the reviews, I tried to answer all the questions
[16:15] <ijohnson> pedronis: cool looking now
[16:17] <ijohnson> pedronis: thanks for the explanations, lgtm still
[16:18] <pedronis> thank you
[16:24] <cachio> zyga, hey, so, we can make it fail in a loop but just on ubuntu core
[16:24] <cachio> it is not reproduced on classic
[16:26] <vorlon> mvo, Chipaca: sorry, my slowness in reviewing that PR (aside from being sick yesterday) is that the PR is of course only showing me the delta vs the latest commit, and what I actually care about is the delta vs the current version of the packaging in bionic.  I'll get to it today
[16:30] <mvo> vorlon: thank you, sorry for being so pushy about it
[16:30] <Chipaca> mvo: do you know the tag of most-recently-in-bionic ?
[16:30] <Chipaca> git tag i mean
[16:31] <mvo> Chipaca: one sec, looking
[16:33] <mvo> Chipaca: commit adee89d789e452c9d12a90625865954cae448d42 (tag: 2.40)
[16:35] <zyga> Trevinho: thank you
[16:35] <zyga> cachio: interesting, wonder why there
[16:35] <zyga> cachio: and if you copy the config to a regular system, can we make it fail there?
[16:36] <cachio> zyga, didn0't try that
[16:36] <cachio> let me try
[16:36] <zyga> cachio: perhaps it's something specific to the config we use on core
[16:36] <zyga> cachio: cool, good luck
[16:47] <Chipaca> mvo: 2.40, or release/2.40?
[16:51] <mvo> Chipaca: tag is "2.40"
[16:56] <Chipaca> gah, github does not help with this
[16:56] <Chipaca> vorlon: sorry :) best i can do is say git diff 2.40 mvo5/snap-confine-conffile -- packaging/ubuntu-16.04
[16:57] <Chipaca> but that's not particularly useful :)
[16:57] <mup> PR snapd#7689 opened: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <https://github.com/snapcore/snapd/pull/7689>
[16:57] <Chipaca> it's http://paste.ubuntu.com/p/ZZ4nK4Byq9/ fwiw
[16:58] <cachio> zyga, well I found that it also fails on classic
[16:59] <zyga> cachio: that's good, closer to reproducer for a bug report
[16:59] <cachio> zyga, https://paste.ubuntu.com/p/jqdCqX7sTn/
[16:59] <mvo> Chipaca: nice!
[17:00] <zyga> cachio: why "not systemctl restart"?
[17:00] <mvo> Chipaca: I pushed 7689 that probably should land before we land 7624 (tweaks the api a little bit for things we need)
[17:00] <cachio> zyga, we restart until it fails
[17:01] <zyga> ah, I see
[17:01] <cachio> what we see is that when the tests run fast
[17:01] <cachio> the service fails to be restarted
[17:01] <cachio> and it is because we are reaching the start limit
[17:02] <zyga> cachio: would be worth to report a bug on upstream systemd project with the question if manual restarts should count towards the failure counter
[17:02] <zyga> cachio: perhaps we should reset the failure state
[17:02] <zyga> cachio: and try again?
[17:03] <cachio> reset the failut state?
[17:03] <zyga> yes
[17:03] <cachio> zyga, how can I do that?
[17:03] <zyga> cachio: one sec
[17:03] <zyga> there's a command for it
[17:03] <zyga> it's pretty rarely used
[17:04] <cachio> zyga, ahh, nice
[17:05] <zyga> cachio: systemctl reset-failed
[17:05] <zyga> cachio: note that we could do something else
[17:05] <zyga> cachio: run systemctl _stop_ to stop the journal
[17:05] <zyga> sync
[17:05] <zyga> to let various IO buffers stabilize
[17:05] <zyga> cachio: then start again
[17:06] <zyga> cachio: the sync in the middle may give everything enough time to actually not choke
[17:06] <zyga> cachio: but if stop or start fails, we could run the reset-failed command to see if we can try again
[17:06] <cachio> zyga, let me try it
[17:06] <zyga> cachio: good luck, I have not tried that, maybe it won't lead anywhere
[17:06] <zyga> but maybe it will
[17:08] <cachio> using stop / sync / start
[17:09] <cachio> works well
[17:09] <cachio> rexec 20 times without error
[17:09] <zyga> cachio: worth giving it a shot
[17:12] <cachio> zyga, fix pushed
[17:12] <zyga> cachio: super
[17:12] <zyga> cachio: thank you!
[17:12] <cachio> zyga, to you
[17:19] <mvo> pedronis: you may want to check https://github.com/snapcore/snapd/pull/7689 just to make sure that the chosen name (client.DownloadInfo) is ok. happy to adjust as needed
[17:19] <mup> PR #7689: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <https://github.com/snapcore/snapd/pull/7689>
[17:19] <mup> PR snapd#7690 opened: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7690>
[17:19] <pedronis> Chipaca: #7690 is what I had in mind
[17:19] <mup> PR #7690: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7690>
[17:20] <pedronis> mvo: seems fine
[17:21] <Chipaca> hehe
[17:24] <pedronis> Chipaca: ?
[17:25] <Chipaca> pedronis: reviewed
[17:25] <Chipaca> pedronis: "hehe" because you called it 'autocomplete', and the flag 'autocompletHidden' (sic)
[17:26] <Chipaca> pedronis: when it's completion, not autocompletion
[17:26] <pedronis> Chipaca: it's funny because people call it autocompletion but is not the correct term?
[17:27] <Chipaca> pedronis: on the phone it is
[17:27] <Chipaca> pedronis: who calls it autocompletion on the terminal?
[17:27]  * Chipaca googles
[17:27] <pedronis> me apparently
[17:27] <pedronis> living in the future
[17:27] <Chipaca> pedronis: you and 190k+ people
[17:27] <Chipaca> pedronis: vs 6M+ for just 'completion'
[17:28] <Chipaca> pedronis: you're the 3%
[17:28] <zyga> Chipaca: this autocompletes this problem
[17:28] <zyga> ;-)
[17:28] <pedronis> Chipaca: the flag is the override, so don't need to set on first boot, I need to set it on any hidden command we still want to auto complete
[17:29] <pedronis> mostly the key stuff I think
[17:29] <Chipaca> zyga: https://i.imgur.com/9HY53al.gif
[17:29] <Chipaca> pedronis: d'oh! obvs
[17:29] <zyga> my day is autocomplete now
[17:30] <Chipaca> zyga: https://i.imgur.com/NJZgC1W.gif
[17:30] <mup> PR snapd#7691 opened: builtin/browser_support.go: allow monitoring process memory utilizati… <Created by Erick555> <https://github.com/snapcore/snapd/pull/7691>
[17:39] <pedronis> Chipaca: fixed and marked some commands back
[17:39] <vidal72[m]> what "disabled" mean under "notes" in "snap list" outpout?
[17:40] <Chipaca> vidal72[m]: that the snap is not enabled
[17:40] <Chipaca> vidal72[m]: i.e. that it is not even mounted
[17:40] <Chipaca> vidal72[m]: or, if you're seeing 'snap list --all', that it is not current
[17:40] <Chipaca> vidal72[m]: why?
[17:42] <vidal72[m]> Chipaca: it seems my snap was during self-update, now "disabled" is gone
[17:48] <pedronis> Chipaca: wonder if this means we would like: snap debug commands  to list them all anyway
[17:48] <Chipaca> pedronis: say again?
[17:49] <pedronis> Chipaca: do we need a way to show all the commands implemented
[17:49] <pedronis> before this PR you could
[17:49] <pedronis> "snap " <TAB> away to that
[17:49] <Chipaca> pedronis: i don't think we do
[17:49] <pedronis> now not anymore
[17:49] <pedronis> Chipaca: ok
[17:49] <Chipaca> pedronis: «GO_FLAGS_COMPLETION=1 snap ""» fwiw
[17:50] <pedronis> Chipaca: that will not show the hidden ones now
[17:50] <Chipaca> pedronis: i know, i'm just saying you to get it non-interactively
[17:50] <pedronis> yea
[17:50] <pedronis> I mean that command to list commands, for us, not in general
[17:54] <Chipaca> pedronis: i don't think we need it, but we can add it if we do
[17:58] <Chipaca> i'ma EOD
[18:07] <mup> Bug #1584590 changed: Snap install download progress neatening up <snapd:Confirmed> <https://launchpad.net/bugs/1584590>
[18:07] <mup> Bug #1616629 changed: could not unmarshal state entry "snap-type" <canonical-bootstack> <snapd:Confirmed> <https://launchpad.net/bugs/1616629>
[18:10] <mup> Bug #1574103 changed: Raspberry Pi 2 image LEDs are swapped. <snapd:In Progress by maciek-borzecki> <https://launchpad.net/bugs/1574103>
[18:10] <mup> Bug #1630789 changed: normal users can't run snaps inside of LXD containers <verification-needed> <snap-confine:Fix Released by jdstrand> <snapd:Fix Released by tyhicks> <snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released by tyhicks> <snap-confine (Ubuntu Xenial):Fix
[18:10] <mup> Committed> <snap-confine (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1630789>
[18:13] <mup> Bug #1664383 changed: running snap list <snap> on a system that has no snaps installed exits 0 <conjure-up> <snapd:Fix Released> <https://launchpad.net/bugs/1664383>
[18:14] <zyga> sil2100: hello, can you please enqueue looking at https://bugs.launchpad.net/snappy/+bug/1701018 tomorrow
[18:14] <mup> Bug #1701018: Splash screen is not enabled in kernel <Snappy:Confirmed> <https://launchpad.net/bugs/1701018>
[18:15] <zyga> there are open PRs and I think someone should have a look at them, decide which way to go and update the bug report
[18:16] <mup> Bug #1721676 changed: implement errno action logging in seccomp for strict mode with snaps  <verification-done-xenial> <verification-done-zesty> <snapd:Fix Released by tyhicks> <linux (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu Xenial):Fix Released by tyhicks> <linux (Ubuntu Zesty):Fix
[18:16] <mup> Released by tyhicks> <linux (Ubuntu Artful):Fix Released by tyhicks> <https://launchpad.net/bugs/1721676>
[18:19] <mup> Bug #1708527 changed: Add /proc/partitions to system-observe <snapd-interface> <snapd:Fix Released> <https://launchpad.net/bugs/1708527>
[18:23] <mup> PR snapd#7688 closed: cmd/snap: make completion skip commands (& opts) that ask for it <Created by chipaca> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7688>
[18:25] <mup> Bug #1583975 changed: ubuntu IoT - webcam-demo 1.0.2 - apparmor="DENIED" operation="open" profile="webcam-demo.canonical_webcam-demo_1.0.2" name="/dev/video0" pid=3898 comm="fswebcam" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 <snapd:Fix Released> <https://launchpad.net/bugs/1583975>
[18:25] <mup> Bug #1648431 changed: Allow snaps to shadow mounts from core <snapd:Fix Released by kalikiana> <https://launchpad.net/bugs/1648431>
[18:25] <mup> Bug #1649837 changed: Can remove required-snaps <snapd:In Progress by pedronis> <https://launchpad.net/bugs/1649837>
[18:27] <zyga> pedronis: kind request to look at the bug https://bugs.launchpad.net/snapd/+bug/1649837 and check if the state can be updated now
[18:27] <mup> Bug #1649837: Can remove required-snaps <snapd:In Progress by pedronis> <https://launchpad.net/bugs/1649837>
[18:28] <mup> Bug #1650689 changed: Channel switching (track new channel) does not work if the two channels happen to have identical snap packages <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1650689>
[18:30] <pedronis> zyga: we never implemented a patch so it's still not finished, now that we have idempotent patches maybe we can finish it
[18:31] <zyga> pedronis: thank you, I'll update the bug
[18:35] <zyga> mvo: are you still working by any chance?
[18:40] <mup> Bug #1659534 changed: userdel doesn't supports extrausers <patch> <verification-done-bionic> <verification-done-xenial> <Snappy:Fix Released> <shadow (Ubuntu):Fix
[18:40] <mup> Released> <shadow (Ubuntu Xenial):Fix Released> <shadow (Ubuntu Bionic):Fix Released> <shadow (Ubuntu Cosmic):Confirmed> <https://launchpad.net/bugs/1659534>
[18:40] <mup> Bug #1660879 changed: snap refresh with more than one argument produces poor error message <snapd:Fix Released> <https://launchpad.net/bugs/1660879>
[18:40] <mup> Bug #1661436 changed: snap download can't find snaps from a branded store <snapd:In Progress> <https://launchpad.net/bugs/1661436>
[18:53] <mvo> zyga: ish, what can I do for you?
[19:02]  * cachio afk
[19:07] <zyga> ah, sorry, I went upstairs for some tea
[19:11] <mup> Bug #1661590 changed: GNOME Software only supports running one application from a snap <verification-done-xenial> <GNOME Software:Fix Released> <Snappy:Fix Released> <gnome-software (Ubuntu):Fix Released by robert-ancell> <gnome-software (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu
[19:11] <mup> Artful):Won't Fix> <gnome-software (Ubuntu Bionic):Fix Released by robert-ancell> <https://launchpad.net/bugs/1661590>
[19:14] <mup> Bug #1693423 changed: initramfs error while loading Custom ubuntu core Image on X86 but it works fine in KVM <Snappy:Invalid> <https://launchpad.net/bugs/1693423>
[19:25] <mup> PR snapcraft#2778 closed: Release changelog for 3.9 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2778>
[20:23] <zyga> re
[20:23]  * zyga managed to put Lucy to bed
[20:23] <zyga> back to bug review
[20:31] <mup> PR snapcraft#2779 opened: ci: switch to travis workspaces <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2779>
[21:06] <mup> PR snapd#7692 opened: tests: opensuse tumbleweed has similar issue than arch linux with snap --strace <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7692>
[21:54] <mup> PR snapd#7601 closed: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Needs Samuele review> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7601>
[22:16] <om26er> Hi! I landed a pull request for a project that has been setup for snapcraft automatic builds but it seems the build didn't start
[22:16] <om26er> https://build.snapcraft.io/user/crossbario/crossbar
[22:17] <om26er> Here is the relevent PR https://github.com/crossbario/crossbar/pull/1649
[22:17] <mup> PR crossbario/crossbar#1649: Base snap on python 3.8 <Created by om26er> <Merged by om26er> <https://github.com/crossbario/crossbar/pull/1649>
[22:19]  * zyga EODs
[22:19] <zyga> ttyl
[23:50] <sil2100> zyga: ACK! Will look!


[02:48] <scientes> ahh so unity-2d was also dropped caused in qt5 qtquick is moving to opengl ES 2.0
[03:49] <SpamapS> dpkg: error: parsing file '/var/lib/dpkg/status' near line 26005 package 'libsdl-net1.2:i386': mixed non-coinstallable and coinstallable package instances present
[03:50] <SpamapS> while dist-upgrading precise->quantal
[03:51] <ScottK> Multiarch is fun.
[03:52] <SpamapS> Yeah
[03:52] <SpamapS> not really sure how to work around it
[03:53] <SpamapS> dpkg seems basically dead in the water
[03:54] <SpamapS> like, dpkg -l doesn't even work
[03:57]  * SpamapS does something unholy and just removes the bad entry there
[04:03] <slangasek> SpamapS: bug #1015567, I'm afraid
[04:03] <SpamapS> slangasek: thanks, was just about to head off looking into whether or not it was a bug/known
[04:44] <infinity> SpamapS: It's known, but no one's had a chance to look into a "sane" migration/fix yet.
[04:45] <infinity> (I also still contend that the check is a complete joke, since it doesn't trigger in other cases that could be equally broken, so maybe just removing it would be fine)
[09:50] <tjaalton> @pilot in
[10:13] <mitya57> ScottK: hi, do you have any plans to merge our python-defaults with debian?
[10:13] <mitya57> there were some important dh_python2 fixes in 2.7.3-1 and 2.7.3-2
[10:43] <xnox> mpt: in quantal, in the system menu i have: "Log Out...; Suspend; Hibernate; Restart...; Switch Off..."
[10:43]  * xnox manually enabled hibernate
[10:43] <xnox> mpt: how come suspend/hibernate do not have '...' at the end?
[10:45] <cjwatson> Don't they act immediately rather than producing a dialog?
[10:47] <mpt> xnox, what cjwatson said
[10:47] <xnox> cjwatson: mpt: ok.
[10:47] <cjwatson> http://developer.gnome.org/hig-book/3.4/menus-design.html.en#menu-item-type-command
[10:48] <mpt> "…" means "you're going to need to provide more input to complete the primary function of this command"
[10:48] <xnox> 3.4 hig
[10:48] <cjwatson> Although there is an argument from the HIG text there that Log Out and Switch Off shouldn't have … either, since they only present a confirmation dialog
[10:48] <cjwatson> I don't know if that wrinkle is somehow controversial
[10:48] <xnox> oh... goodies. need to read it =)
[10:49] <cjwatson> 3.4 was just the current link; AFAIK the ellipsisation advice has been there forever
[10:51] <mpt> Yeah, we diverge from the Gnome HIG in that we make no distinction between a confirmation alert and other types of input
[10:52] <mpt> (For example, the confirmation alert might have a checkbox in it like "Install updates before switching off", or might offer multiple choices like "Restart" vs. "Restart Into Windows")
[10:54] <cjwatson> For reference, do we have documentation of our HIG divergences anywhere?
[10:55] <mpt> I think the Gnome HIG has the "ignore confirmation alerts" guideline only because the classic Mac OS guidelines did, but even OS X doesn't
[10:56] <mpt> cjwatson, no, that would be priority #2 where priority #1 is to have our own guidelines to diff between :-)
[10:56] <cjwatson> Heh
[10:56] <cjwatson> I know how it is
[11:03] <bdrung> bdmurray: the sponsoring overview is not updated any more. do you know why?
[11:20] <xnox> point of interest 3.6 libreoffice spash is weird. i liked previous one better...
[11:34] <alexbligh> What is the best way to make a script run very early on (i.e. as the first thing upstart does) after remounting / read-write and before any udev/hotplug events are processed
[12:12] <smoser> hm.. ok. i'm out of ideas. anyone see what is wrong here
[12:12] <smoser> https://bugs.launchpad.net/ubuntu/+source/choose-mirror/+bug/1031696
[12:18] <smoser> alexbligh, i dont think you can accomplish that.
[12:19] <smoser> udev starts on virtual-filesystems, which i do not believe depends on mounted / rw
[12:19] <smoser> although when i say that it doesn'tmake much sense. sosomething must block processing of hotplug/udev events until after rw
[12:21] <geser> smoser: in the second screenshot (that one from busybox) the grep isn't searching in the output from wget but in the file "Release" from the filesystem (see Release in the grep call)
[12:21] <smoser> geser, well, he did both
[12:21] <smoser> first one he just grepped from the file
[12:22] <smoser> second he did the wget
[12:22] <smoser> oh.
[12:22] <smoser> no
[12:22] <smoser> you're right.
[12:24] <alexbligh> smoser, so if I do "start on starting udev and started virtual-filesystems" then I am going to create some form of dependency loop?
[12:25] <alexbligh> udev is "start on virtual-filesystems"
[12:25] <smoser> i dont know what would happen.
[12:26] <alexbligh> Hmmm, in this case I can guarantee the only filesystem is the root filesystem which is initramfs and already about. mountall is just going to remount that r/w (I presume it's mountall which does the remount r/w)
[12:28] <alexbligh> I don't think I can use "stopped mountall" as presumably mountall is only stopped after it has emitted all the events.
[12:28] <alexbligh> (incl. the one that starts udev)
[13:09] <jodh> alexbligh: lets continue this on #upstart.
[13:17] <bdrung> tumbleweed: how about a u-d-t release?
[13:28] <hrw> starting daemons...
[13:29] <hrw> one day I will find time to learn what is ubuntu way of having daemons installed and not started on boot even after package update
[13:31] <ogra_> stgraber, heh, the lightdm/gdm mail on the ltsp list is funny ... so he did all that work but still needs the same user locally ... somone should tell him that this is the actual readon for ldm to exist :)
[13:31] <ogra_> *reason
[13:36] <directhex> hrw, tl;dr: an entry in /etc/default/packagename along the lines of "ENABLED=0", and an init script which bails out unless ENABLED=1
[13:36] <directhex> e.g. see dnsmasq
[13:37] <hrw> directhex: thanks
[13:40] <jodh> hrw: it's covered in a generic fashion in the Upstart Cookbook too. See http://upstart.ubuntu.com/cookbook/#pre-start and http://upstart.ubuntu.com/cookbook/#post-stop.
[13:40] <stgraber> ogra_: haven't read too closely, but it sounds like he needs scotty's libpam-ssh and libnss-ssh
[13:40] <ogra_> stgraber, right
[13:41] <ogra_> i just find it funny how people invest a ton of work without talking to anyone before they start and then end up in the same situation all others did before them
[13:42] <jocarter> ogra_: it's things like that that cause me to grind my teeth and then having the dentist telling me to stop stressing so much
[13:42] <tumbleweed> bdrung: as usual, I'd like to do a pass through the bugtracker first
[13:43] <ogra_> jocarter, who are *you* ?
[13:43] <ogra_> *g*
[13:43] <jocarter> I'm the artist previously known as highvoltage
[13:43] <bdrung> tumbleweed: then go ahead. :p
[13:43] <ogra_> is that a permanent change ?
[13:44] <jocarter> ogra_: I think so. I tried changing away from highvoltage before but there was a lot of resistance
[13:44] <jocarter> *badish*
[13:44] <ogra_> lol
[13:47] <jamespage> doko_, just noticed the java-common package is still installing the architecture-less symlinks for openjdk-6 -  we should probably drop those
[13:48] <jamespage> (I can do that if you agree)
[13:57] <xnox> jocarter: i will be calling you jo forever now.
[13:57]  * xnox expects you to respond to 'jo:' pings ;-)
[14:00] <NCommander> infinity: ping, do you remember what APT bugs I had to look at?
[14:01] <ogra_> NCommander, just look at all of them :P
[14:01] <ogra_> (and fix them indeed)
[14:03]  * NCommander glares at ogra
[14:18]  * xnox lines up apt bugs in alphabetical order for NCommander (while winking at ogra_)
[14:18] <NCommander> xnox: [A-Z][a-z]? Or are you using an extended alphabet which has more letters :-)
[14:19] <xnox> NCommander: есть же и другие алфавиты...
[14:19] <NCommander> How very cryillic of you :-)
[14:20] <NCommander> *cyrillic
[14:20] <xnox> ;(
[14:20] <xnox> ;)
[14:20]  * xnox typing fail
[14:20]  * NCommander still remembers the days of fidonet and spam on DOS could be identified by blocks in Fidomail
[14:21]  * NCommander suddenly feels old as hell
[14:22]  * NCommander <3 ProcommPlus for DOS
[14:22]  * xnox never used fidonet.....
[14:23] <killown> What ubuntu team just did with the last update? it messed around with kubuntu-desktop http://bpaste.net/show/8uqye6UT9JCKGHcVgDuS/ thanks for wasting my time with this
[14:23] <cjwatson> that's a bit overly aggressive
[14:23] <killown> i386 devel libs is useless and I can't compile wine, other great thing I would thank for too
[14:23] <cjwatson> I expect whoever made the change in question would need a significantly more complete report than that, including e.g. which Ubuntu release you're using
[14:23] <xnox> killown: if I was you, I'd wait for the mirrors to catch up.
[14:23] <NCommander> That looks like aptitude
[14:24] <cjwatson> but cut the sarcasm, please
[14:24] <cjwatson> it doesn't help anyone
[14:26] <bdmurray> bdrung: the sponsoring report is a dholbach thing
[14:31] <bdrung> bdmurray: he is on holiday and told me that you are able to deploy changes
[14:33] <bdmurray> bdrung: I only have read access to the files there...
[14:34] <shadeslayer> Daviey: ping
[14:36] <bdrung> bdmurray: do you know who has access to it?
[14:36] <bdmurray> bdrung: yes, dholbach
[14:36] <janimo> NCommander, you're not old, you were precocious
[14:37] <shadeslayer> Daviey: it seems you dropped smbfs with this merge : https://launchpad.net/ubuntu/+source/cifs-utils/2:5.4-1ubuntu1
[14:37] <shadeslayer> Daviey: was it intentional? what replaces smbfs in that case
[14:37] <bdrung> bdmurray: is the sponsoring script run on his private machine?
[14:38] <shadeslayer> Daviey: Debian still has smbfs apparently : http://packages.debian.org/source/unstable/cifs-utils
[14:41] <NCommander> janimo: somewhere, I have a box of token ring adapters, and a copy of OpenVMS for Itanium :-)
[14:41]  * NCommander has had notions of wiring up a DECnet network at home
[14:41] <janimo> NCommander, ok then, s/precocious/crazy/
[14:42] <NCommander> :-)
[14:42] <janimo> I am older than you and only know those from history books
[14:42] <janimo> by which I mean IT books printed in the early 90s
[14:43] <NCommander> If it weren't for the fact everything here is on VoIP, I'd stick a modem in my itanium system and wire up uucp
[14:43] <NCommander> (dial-up is suprisingly useful in some of the places I go to)
[14:47] <ScottK> postfix supports delivery via uucp.
[14:51] <NCommander> ScottK: curious if it will handle a bangpath email
[14:51]  * NCommander notes Thunderbird (used to) explode when you fed it one
[15:00] <lamont> NCommander: that got turned off by default some time a go, iirc
[15:01] <lamont> AS IT SHOULD
[15:01] <NCommander> you don't like have addresses like ..!someisp!canonical!lamont
[15:04] <lamont> NCommander: not since the late 80s
[15:04] <lamont> and the lasthop was !hpda!lamont then
[15:05]  * NCommander remembers HP-UX and feels slightly sick :-P
[15:13] <apw> can anyone remind me where the 'update only to the next LTS' flag is for a server
[15:14] <shadeslayer> apw: just use do-release-upgrade -d
[15:14] <lamont> apw: d/
[15:14] <shadeslayer> and it'll upgrade to precise
[15:14] <lamont> bah
[15:15] <lamont>  /etc/update-manager/meta-release
[15:15] <apw> lamont, ahh /etc/update-manager/release-upgrades thanks for the right area
[15:15] <lamont> apw: pastefail
[15:16] <lamont> sorry
[15:16] <apw> lamont, heh :)
[15:43] <ogra_> 2706 ogra      20   0 2172m 746m  21m R  102  4.7   5938:06 compiz
[15:43] <ogra_> hmpf
[15:43] <ogra_> (thats an idling machine)
[15:46] <ppisati> ogra_: don't oppose the progress! :)
[15:47] <ogra_> haha
[16:02] <jamespage> doko, do java-access-bridge and java-atk-wrapper do the same thing?
[16:10] <slangasek> cjwatson: where do things sit with bug #926340? seems glatzor hasn't replied to your last proposal
[16:12] <cjwatson> slangasek: as you say - I was waiting for him to respond
[16:12] <cjwatson> looked for him on IRC this morning actually but he wasn't around
[16:12] <slangasek> IME he's not very irc-catchable
[16:13] <cjwatson> I'll mail him
[16:13] <slangasek> ok
[16:15] <xnox> cjwatson: python3-debian, any patch-queue review updates?
[16:15] <cjwatson> not yet, sorry, I meant to take care of that in my holiday last week but was stymied by lack of internet
[16:16] <xnox> cjwatson: ah ok. there are two patches send to you in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625509 for python2 compat
[16:17] <xnox> cjwatson: ok. no rush =)
[16:17] <cjwatson> yeah I saw
[16:17] <cjwatson> right, off homenow, but at least irc is running in screen now
[16:17] <slangasek> xnox: so do you know anything about this autofs use of /etc/nsswitch.conf?
[16:17] <cjwatson> not convinced about the subprocess one, I want to take a different approach there
[16:17] <cjwatson> (I'd rather use universal_newlines and make it work, than give up)
[16:17] <slangasek> xnox: I can't find any relevant entry points in libnss_nis, so I'm not sure what this has to do with nsswitch at all
[16:18] <xnox> slangasek: no, not really. it's just that the bug is filed against older autofs5 vs newer autofs package
[16:18] <xnox> and I want to test what's going on. i remember poking that code while doing the merge and fixing other bugs.
[16:20]  * slangasek nods
[16:20] <infinity> slangasek: The parsing code that's throwing the error is fairly easily greppable in the autofs5 source.
[16:21] <infinity> slangasek: My assumption is that it's vomiting over the [WHATEVER=something] syntax
[16:23] <infinity> (Oh, that assumption would be based on me not continuing to read the bug comments where adding a line "fixes" it?)
[16:28] <xnox> i am confused as to what is the bug reported here.
[16:29] <xnox> nsswitch.conf is valid syntax
[16:29] <slangasek> yes
[16:29] <xnox> auto.master seems to configured correctly and it does work for me.
[16:29] <slangasek> nsswitch.conf is valid syntax, and autofs has its own wrong parser for nsswitch.conf
[16:29] <xnox> what's different in the reported setup that breaks?
[16:29] <xnox> hm... cause autofs expects spaces around [ ] ?
[16:30] <slangasek> dunno
[16:39] <xnox> slangasek: ok. thanks for that comment. now i am back to dmraid.
[16:41] <slangasek> bdmurray: what put bug #488696 on your radar?
[16:46] <jdstrand> slangasek: for security support, icedtea-6-plugin should be demoted and icedtea-7-plugin promoted, correct?
[16:47] <jdstrand> meh
[16:47] <jdstrand> slangasek: nm
[16:47] <jdstrand> sbeattie: ^
[16:47] <bdmurray> slangasek: the release task nominations
[16:48] <jdstrand> sbeattie: it looks like this is what icedtea-web is doing now, and thought I'd fix the component-mismatches if you tell me so
[16:48] <jamespage> jdstrand, I'd +1 that - lines up with the Java 6 -> 7 transition
[16:48] <jamespage> (and it was me that just switched the 'default')
[16:49] <slangasek> bdmurray: ah, ok
[16:51] <jdstrand> jamespage: ack
[16:52] <sbeattie> jdstrand: yeah, that's correct.
[16:53] <jdstrand> jamespage, sbeattie: thanks, I'll adjust
[16:53] <jamespage> jdstrand, marvellous - thanks
[16:54] <jdstrand> (done)
[17:00] <xnox> slangasek: both mdadm and dmraid have support for isms
[17:00] <xnox> s/isms/imsm/, the intel raid
[17:01] <xnox> and both try to assemble them in udev/initramfs
[17:01] <smoser> @pilot in
[17:01] <xnox> i will disable intel and ddf in mdadm for now, and will think about how to migrate from one to another...
[17:02] <xnox> since there is no way to know.
[17:02] <xnox> to know what the user wants.
[17:02] <xnox> the device names and symlinks generated are different
[17:07] <bdmurray> mterry: do you have any test case ideas for bug 818760?  I've uploaded an SRU for precise for it.
[17:08] <mterry> bdmurray, no...  I couldn't reproduce myself.  I just looked at the stacktrace and used that to fix the bug
[17:12] <doko> jamespage, java-access-bridge is obsolete now
[17:13] <jamespage> doko, thats what I thought looking at it; as it FTBFS I'll file a removal bug report
[17:13] <doko> yes, sounds fine
[17:14] <slangasek> xnox: ok, cool
[17:16] <tjaalton> @pilot out, meh
[17:16] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[17:16] <tjaalton> bah
[17:16] <tjaalton> @pilot out
[17:30] <shadeslayer> I found this in germinates output : ? Unknown desktop-common package: fonts-freefont
[17:31] <shadeslayer> shouldn't that be fonts-freefont-ttf ?
[17:32] <shadeslayer> cjwatson: ^ bzr log says you changed this :)
[17:32] <infinity> shadeslayer: Yeah, looks like a source/binary thinko.  I'll fix.
[17:33] <shadeslayer> infinity: awesome
[17:34] <infinity> shadeslayer: Committed.
[17:34] <shadeslayer> thanks
[17:34] <shadeslayer> now if someone could just tell me why smbfs was dropped ....
[17:35] <infinity> shadeslayer: In edgy...?
[17:35]  * shadeslayer is yet to find a reason for that
[17:35] <shadeslayer> infinity: quantal
[17:35] <shadeslayer> apparently Daviey did a merge and it disappeared
[17:35] <infinity> Oh, the log shows it being dropped in edgy. :P
[17:35] <shadeslayer> whut
[17:35] <shadeslayer> infinity: it comes from cifs-utils
[17:35] <shadeslayer> !info smbfs precise
[17:35] <shadeslayer> !info smbfs quantal
[17:36] <shadeslayer> dafuq
[17:36] <shadeslayer> ahh
[17:36] <shadeslayer> yes, as you can see, current cifs-utils is 2:5.5 whereas ubottu reports 2:5.1
[17:37] <shadeslayer> !info cifs-utils
[17:37] <infinity> shadeslayer: So, I see both smbfs and cifs-utils seeded...
[17:37] <shadeslayer> infinity: but smbfs doesn't exist ... https://launchpad.net/ubuntu/+source/cifs-utils/2:5.5-1ubuntu1
[17:37] <infinity> shadeslayer: Oh, you weren't talking about seeds anymore.  Check.
[17:37] <shadeslayer> nope
[17:38] <shadeslayer> infinity: I'm talking about completely missing binary packages in the archive
[17:39] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620847
[17:40] <infinity> shadeslayer: I think the answer here is "transition to using cifs-utils, and stop relying on smbmount"
[17:40] <shadeslayer> got it
[17:41] <shadeslayer> I guess I saw the transitional package on packages.debian.org
[17:41]  * shadeslayer fixes his seeds
[17:45] <infinity> shadeslayer: Fixed the samba-server seed in quantal too.
[17:46] <shadeslayer> yay
[17:47] <shadeslayer> infinity: uh ... wait, I don't understand, samba-server seed? 0.o
[17:47] <infinity> shadeslayer: For the "samba-server" Task.  It installed smbfs, which used to pull in cifs-utils transitively.
[17:48] <infinity> shadeslayer: Which obviously doesn't work anymore. :P
[17:48] <shadeslayer> ahh ok
[17:48] <shadeslayer> infinity: though, I'm curious as to where the samba-server task resides
[17:49] <infinity> apt-get install samba-server^
[17:49] <infinity> (or use tasksel)
[17:50] <shadeslayer> uhh
[17:50] <shadeslayer> !find samba-server quantal
[17:50] <infinity> It's a task, not a package.
[17:51]  * shadeslayer looks
[17:51] <infinity> apt-cache show samba | grep ^Task
[17:51] <shadeslayer> ahhhh ok
[17:53] <ogra_> hggdh, https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages?field.name_filter=linaro-boot-utils&field.status_filter=published&field.series_filter=precise
[17:55] <ogra_> hggdh, http://paste.ubuntu.com/1123801/
[17:57] <ogra_> hggdh, http://people.canonical.com/~ogra/uboot/
[19:23] <SpamapS> slangasek: looking at the libbonobo SRU.. does this mean all the reverse deps have to be rebuilt, or just *tested* to build with the new one?
[19:23] <SpamapS> $ apt-cache rdepends libbonobo2-0|wc -l
[19:23] <SpamapS> 45
[19:23] <stgraber> SpamapS: just tested to build
[19:23] <SpamapS> ok
[19:24] <slangasek> SpamapS: just tested, yes
[19:24] <slangasek> stokachu: ^^ have libbonobo revdeps been build-tested now?
[19:27] <mhall119> can someone take a look at https://bugs.launchpad.net/ubuntu/+bug/1031886?
[19:27] <mhall119> at UDS-Q, sabdfl showed interest in a help lens
[19:28] <mhall119> it should already have a package
[19:32] <slangasek> SpamapS: hold off on nis in -proposed please
[19:33] <SpamapS> slangasek: ok. Is it broken-er than before?
[19:33] <slangasek> SpamapS: there's at least one regression, bug #993291
[19:33] <slangasek> and I think there may be another one, which is what I was looking for when stumbling upon that one
[19:34] <SpamapS> slangasek: should we mark bug 569757 verification-failed ?
[19:35] <slangasek> SpamapS: just doing so now, but wanted to make sure I got you directly to avoid any race conditions :)
[19:36] <SpamapS> slangasek: consider me blocked
[19:56] <slangasek> SpamapS: ok, further analysis tells me that publishing the nis SRU for lucid should be safe: https://bugs.launchpad.net/ubuntu/+source/nis/+bug/569757/comments/75
[19:56] <slangasek> SpamapS: btw, the tags on that bug ended up being 'verification-done verification-done-lucid verification-needed'... what's that supposed to mean?
[19:57] <slangasek> I've seen similar tag sets applied to other SRUs, but I'm not aware that the report tools do anything useful with such a combo, and AFAIK it's not documented on the SRU page
[19:58] <stgraber> slangasek: I implemented verification-done-<SERIES> into sru-report a few weeks ago
[19:58] <slangasek> ah
[19:58] <slangasek> then shouldn't it be *just* verification-done-<SERIES>, without the verification-done tag?
[19:58] <stgraber> yes
[19:59] <stgraber> using both was the old way of doing it as sru-report wouldn't mark it green
[19:59] <stgraber> so in the past most people would mark verification-done + verification-done-SERIES, then when accepted, the SRU team member would reset verification-done until all series were verified
[19:59] <stgraber> which was rather confusing, so for bugs like that, the "right" way of doing it now should be to only use the -SERIES tag
[20:36] <smoser> @pilot out
[20:57] <slangasek> what happened to firefox that's causing pdfs to now load in-browser in some horribly slow reader?
[20:57] <slangasek> is this just me?
[20:58] <elmo> slangasek: installing the adobe pdf reader can do that
[20:58] <slangasek> not installed
[20:58] <mdeslaur> slangasek: firefox now has a built-in pdf viewer
[20:59] <mdeslaur> slangasek: à la chrome
[20:59] <bkerensa> slangasek: we integrated reading
[20:59] <bkerensa> :D
[20:59] <slangasek> mdeslaur: how do I turn it off?
[20:59] <slangasek> this is not a feature
[20:59] <bkerensa> slangasek: you cannot atm
[20:59] <slangasek> argh
[21:00] <bkerensa> https://bugzilla.mozilla.org/show_bug.cgi?id=752676
[21:00] <bkerensa> :D
[21:00] <mdeslaur> dpkg -P firefox?
[21:00] <slangasek> mdeslaur: and use what instead for the browsing?
[21:01] <mdeslaur> slangasek: w3m-img! :P
[21:01] <slangasek> well, pdfjs.disabled lets me disable it entirely; still doesn't let me view pdfs directly in evince, I have to save them to file now :/
[21:01] <slangasek> mdeslaur: away with you, troll
[21:01] <mdeslaur> lol
[21:02] <mdeslaur> the retro-grouches I work with have started to rub off on me :)
[21:31] <SpamapS> slangasek: re the tags on the nis SRU.. IIRC there was also a Fix Committed task for another release, so verification-done + verification-needed == purple on the SRU report
[21:51] <clepto> hello, i am writing an app with quickly-pygtk-glade and i have some questions...i want to show a dialog and get the return id...
[21:52] <clepto> i used the run() method
[21:52] <clepto> but then i closed the dialog and try to reopen it
[21:52] <clepto> and i got an emtpy window
[21:52] <ogra_> clepto, see /topic ... #ubuntu-app-devel might be a better place to ask this
[21:52] <clepto> thanks!
[22:01] <enapupe> Hi, I'm searching for some information on how ubuntu handle multimedia keys on my keyboard, can anyone show me some directions?
[22:04] <slangasek> enapupe: /usr/share/doc/udev/README.keymap.txt.gz
[22:06] <enapupe> wow, now i'm 1 step ahead, ty very much slangasek !
[22:09] <enapupe> now, I was abble to find this: scan code: 0xC00CD   key code: playpause  // I would like to reproduce the effect of pressing this key, is this possible?
[22:18] <slangasek> enapupe: there's no good way to emulate keypresses that I know of
[22:18] <enapupe> slangasek: xdotool seems to work just fine, but it wont understand the multimedia keys
[22:19] <enapupe> xdotool key Alt+F4 // this works fine, prompts me to close the terminal
[22:20] <enapupe> AFAIK my keyboard works as 2 eventX instances, 1 for regular keys and another to multimedia
[22:20] <slangasek> yes, the problem with emulating multimedia keys is that many of them are mapped outside of the range of keycodes that can be represented in X - so they're actually bridged to the desktop via a dbus service
[22:21] <enapupe> is thing something on the driver level?
[22:22] <slangasek> no
[22:22] <slangasek> it might be gnome-settings-daemon intercepting these directly?
[22:23] <enapupe> sudo /lib/udev/keymap -i input/event5
[22:23] <enapupe> scan code: 0xC00EA   key code: volumedown
[22:23] <enapupe> ^C
[22:23] <enapupe> this behavior answers the question?
[22:42] <NCommander> Who usually handles migration of a package that's aged in proposed and is verification-done?
[22:43] <stgraber> sru team
[22:43] <stgraber> NCommander: on Wednesday it's SpamapS
[22:44] <NCommander> SpamapS: are you around? I'd like to see highbank migrate, its verification-done and in proposed
[22:44]  * NCommander fishes for a bug
[22:44] <NCommander> SpamapS: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004018
[22:45] <SpamapS> NCommander: infinity had asked me to leave those to him.
[22:45] <SpamapS> infinity: ^^ ?
[22:45] <NCommander> SpamapS: ah
[22:45] <SpamapS> NCommander: but yes, they appear to be ready
[22:45] <mdeslaur> SpamapS: any chance you can push LP: #953922?
[22:45] <NCommander> SpamapS: great, I'll nag infinity then.
[22:45] <mdeslaur> SpamapS: is that one not appearing on your list, or do you guys just have a back log?
[22:46] <SpamapS> mdeslaur: its there. I stopped 2 short of it. ;)
[22:46] <SpamapS> totem and remmina are in front of it
[22:46] <mdeslaur> SpamapS: ah, cool. thanks...I wasn't sure if I did something wrong or not.
[22:47] <SpamapS> mdeslaur: no, looks good. If its small I can do a quick queue jump..
[22:54] <SpamapS> mdeslaur: accepted :)
[22:55] <mdeslaur> SpamapS: awesome, thanks!
[22:55] <enapupe> slangasek: found a way! echoing the keything to \dev\input\event5
[22:55] <slangasek> ah, interesting
[22:56] <enapupe> don't ask me wtf is this keything, the weirdest string ever seen
[22:56] <enapupe> i don't know what kind of encoding it is
[22:57] <scientes> backslashes FTW
[22:58] <enapupe> :T
[22:58] <enapupe> scientes: would you believe if I say that i wrote corretly before, then deleted and typed wrong?
[22:59] <enapupe> maybe is my IRC client font which makes the slashes uggly ;P