[06:27] <zyga> good morning
[06:32] <zyga> hey pedronis :)
[06:59] <pedronis> hi
[07:02] <mvo> hey pedronis
[07:07] <pstolowski> mornings
[07:09] <mvo> hey pstolowski
[07:13] <mup> PR snapd#7329 opened: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <https://github.com/snapcore/snapd/pull/7329>
[07:14] <pedronis> mvo: ^ pstolowski: ^
[07:14] <pedronis> pstolowski: hi
[07:14] <mvo> pedronis: ta
[07:15] <pstolowski> ok
[07:19] <zyga> mvo: what about https://github.com/snapcore/snapd/pull/7321
[07:19] <mup> PR #7321: tests: restore dpkg selections after upgrade-from-2.15 test <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7321>
[07:19] <zyga> I'm not sure how many reviews we need now
[07:20] <mup> PR snapd#7328 closed: tests: pass --remove to userdel on core <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7328>
[07:25] <mvo> zyga: its fine from my POV, its not perfect
[07:25] <zyga> mvo: yeah, I'd like to land it
[07:25] <mvo> I mean, you pointed out that the tool has flaws
[07:25] <mvo> but its fine IMO
[07:25] <zyga> mvo: yeah
[07:25] <zyga> mvo: do we need zero, one or two reviews on top of this state?
[07:28] <mvo> zyga: so far this has zero reviews… :( let me review it
[07:28] <mvo> zyga: having one review from !us would be nice I think
[07:29] <zyga> yeah, I feel the same way
[07:29] <zyga> it's unclear what the rules say when two people work on something and agree
[07:29] <mvo> zyga: lets not fuss too much, its a tiny PR and affects only tests. I'm sure if e.g. pstolowski can have a quick look it can land :)
[07:30] <zyga> +1
[07:32] <pstolowski> seems i missed my 2 minute window to review this ;)
[07:38] <pstolowski> ah, it wasa about 7321, looking at it
[07:44] <zyga> brb
[07:46] <pstolowski> one comment there, +1
[07:51] <zyga> re
[07:51] <zyga> pstolowski: replied
[07:52] <pedronis> mvo: I archive 2.40 and created the 2.42 lane, I also made cards for the UC20 things I'm working on
[07:54] <mup> PR snapd#7321 closed: tests: restore dpkg selections after upgrade-from-2.15 test <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7321>
[07:58] <mvo> pedronis: excellent, thank you
[08:38] <Chipaca> ullo ullo
[08:39] <Chipaca> i just popped in to make sure y'all were aware today's a bank holiday so that's why i'm not here
[08:39] <pstolowski> pedronis, zyga: when we optimize apparmor backend to load multiple profiles in one go we're going to loose the granularity of error handling we have now for the apparmor_parser invocation. at the moment regenerateAllSecurityProfiles just logs an error for a given snap and carries on with the rest (we can still have such per-snap policy for intermediate errors before aa parser is invoked). any toughts on that?
[08:39] <pstolowski> hey Chipaca
[08:42] <pstolowski> pedronis, zyga unless we run apparmor parser with --vebose flag and go into business of parsing it's output ('Replacement succeeded for "snap....' gets printed for every successfull profile)
[08:51] <abeato> mvo, morning! would it be possible to merge https://github.com/snapcore/snapd/pull/7252 now? Also, what about https://github.com/snapcore/snapd/pull/7173 ? Is retriggering the tests needed there?
[08:51] <mup> PR #7252: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7252>
[08:51] <mup> PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173>
[08:52] <mvo> abeato: in a meeting, will check in ~1h when they are over
[08:52] <abeato> mvo, ack, thanks
[08:55] <zyga> pstolowski: interesting
[08:55] <zyga> pstolowski: on failure, we can re-run per profile and see what really failed
[08:58] <pstolowski> zyga: yeah but we need to find out which one failed (for which snap), just log this snap and don't consider entire operation as failed
[09:02] <zyga> pstolowski: yeah but when the batch fails you can re-try non-batch to reliably get information about those that really failed
[09:02] <zyga> pstolowski: alternatively
[09:02] <zyga> pstolowski: we can batch only inside one snap
[09:03] <zyga> pstolowski: that's less generic but better in terms of our understanding what to do
[09:03] <zyga> pstolowski: because when things fail, we need to change at the snap-granularity anyway
[09:04] <pstolowski> zyga: we already pass all profiles of given snap to aa parser (if that's what you mean). but re-trying one-by-one is an interesting idea
[09:05] <zyga> pstolowski: if it's already per-snap then retrying is not of much use
[09:05] <zyga> pstolowski: because it partially failed anyway
[09:05] <zyga> pstolowski: another idea: do it in stages: first compile then load
[09:05] <zyga> pstolowski: if compilation failed nothing in the system is broken
[09:05] <zyga> pstolowski: it's easier to reason about the state
[09:06] <zyga> pstolowski: you can pass a flag to the parser to let it just compile all profiles
[09:06] <zyga> pstolowski: then you can pass a different flag to ask it to just load binary profiles
[09:08] <pstolowski>  -d, --debug
[09:08] <pstolowski>            Given once, only checks the profiles to ensure syntactic correctness.
[09:08] <pstolowski> zyga: ^ yeah, interesting
[09:11] <zyga> pstolowski: rather than debug I'd try something like --skip-kernel-load
[09:11] <pstolowski> zyga: aha! thanks
[09:11] <zyga> pstolowski: you can use other options to capture the compiled profile into memory
[09:11] <zyga> pstolowski: or to disk
[09:26] <niemeyer> Morning all
[09:30] <mvo> hey niemeyer ! welcome back
[09:30] <niemeyer> Thanks! Glad to be back
[09:30] <niemeyer> How're things going?
[09:38] <mup> PR snapd#7252 closed: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7252>
[09:40] <mvo> niemeyer: going well, thank you!
[09:40] <niemeyer> I see mup is still going strong
[09:41] <mvo> niemeyer: some annoying test hickups that we are fighting but its getting better
[09:41] <mvo> niemeyer: yeah, mup was doing great last week iirc
[09:41] <mvo> mup: hey, still fine?
[09:41] <mup> mvo: I apologize, but I'm pretty strict about only responding to known commands.
[09:41]  * mvo hugs mup
[09:42] <niemeyer> Nice
[10:33] <zyga> mvo: found the bug :)
[10:33] <zyga> mvo: whee
[10:33] <zyga> core is good
[10:33] <mvo> zyga: tell me more!
[10:33] <zyga> mvo: the logic in reset_all_snap was silly wrong
[10:34] <zyga> I'll send a PR in a moment
[10:34] <mvo> zyga: ta
[10:45] <zyga> mvo: two bugs actually
[10:45] <zyga> in other news, shell is tricky
[10:52] <ogra> pfft
[11:14] <zyga> fired one more run to be sure, brb
[11:14] <zyga> mvo: tl;dr; grep -w is a deception
[11:14] <zyga> mvo: - is a word separator
[11:14] <zyga> mvo: dont-remove-this-snap-core18 matches against grep -w core18
[11:25] <mvo> zyga: woah, nice find
[11:32] <zyga> mvo: https://github.com/snapcore/snapd/pull/7330
[11:32] <mup> PR #7330: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330>
[11:32] <mup> PR snapd#7330 opened: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330>
[11:38] <mup> PR snapd#7331 opened: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7331>
[11:40] <zyga> ohh, a new PR label
[11:40] <mup> PR snapd#7332 opened: tests: remove trailing spaces from shell scripts <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7332>
[11:41] <abeato> mvo, it looks like tests for https://github.com/snapcore/snapd/pull/7173 finally passed :)
[11:41] <mup> PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173>
[11:41] <zyga> I need to do some reviews while tests are churning
[11:49] <mup> PR snapd#7333 opened: tests: fix system version check on listing test for external backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7333>
[11:51] <zyga> wow, only one test not passing cleanly in main on core16!
[11:51] <zyga> and a simple one at that
[12:15] <zyga> unit test failure?
[12:15] <zyga> https://www.irccloud.com/pastebin/AQb5iDB8/
[12:15] <zyga> and another one on snap_daemon user
[12:15] <zyga> https://www.irccloud.com/pastebin/5rYhzSZG/
[12:15] <zyga> mvo: is that still expected?^
[12:15] <zyga> or should I get more recent master
[12:32] <mup> PR snapd#7334 opened: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7334>
[12:38] <mvo> zyga: the daemon-user in tumbleweed?
[12:38] <zyga> mvo: that is 16.04
[12:38] <zyga> mvo: not TW
[12:38] <zyga> mvo: group removal failed because there's a user using it as primary group
[12:39] <mvo> zyga: let me check
[12:39] <zyga> mvo: offtopic: core18 does not leak any more mount points as far as my tests are showing
[12:39] <zyga> mvo: I'm running a more complete pass but this is fantastic, it's not buggy anymore :
[12:40] <zyga> mvo: this means both core and classic are clean, only two PRs to review to get there
[12:42] <mvo> zyga: cool
[12:42] <mvo> zyga: where is the userdel failure?
[12:43] <mvo> zyga: I mean, what PR failed ? I want to check the log
[12:43] <zyga> mvo: I restarted it already
[12:43] <zyga> mvo: sorry, :/
[12:43] <jamesh> and then the test suite will be 100% robust? :-)
[12:45] <zyga> jamesh: no :)
[12:45] <zyga> jamesh: but that aspect will
[12:45] <zyga> jamesh: so my test that measures it can be enabled again
[12:46] <zyga> jamesh: without acting like a mount leak detector
[12:47] <jamesh> zyga: fyi, I'm in Greece for GUADEC until Thursday (and then flying home until Friday evening).  So I may be slow to respond to activity on my PRs
[12:48] <zyga> jamesh: enjoy Guadec, I'd love to visit Greece for one :)
[12:48] <zyga> I'm doing a pass over older PRs, including many that you sent, sorry for the enormous lag
[12:49] <jamesh> zyga: no problem.  At some point I'd like to go over the work I need to complete for 20.04
[12:50] <jamesh> dbus activation is still the big one (which hopefully is getting close to unblocked)
[12:50] <jamesh> there will probably be some xdg-desktop-portal related changes too though
[12:50] <zyga> jamesh: any interesting portal work that would be of interest for us to integrate with?
[12:50]  * zyga has some back pain today, should move to laptop
[12:51] <jamesh> zyga: mostly things that were brainstormed almost a year ago
[12:51] <zyga> jamesh: as in, they are coming now?
[12:51] <zyga> after a year of being under development?
[12:52] <jamesh> I want to give xdg-desktop-portal more information about snaps, which will probably involve adding a hidden "snap" command that takes a pid for a confined app and spits out some machine readable data about the snap
[12:52] <jamesh> a year of having other priorities
[12:52] <zyga> jamesh: oh neat
[12:52] <zyga> jamesh: would it be like snap info --pid=123
[12:52] <zyga> that then matches that pid to a snap and gives you that kind of information
[12:52] <zyga> jamesh: my question is mainly: do you need more than what snap info would say
[12:53] <jamesh> in particular, I want snap name, desktop file ID, possibly presence of network plug
[12:53] <jamesh> maybe some information about readable/writable paths
[12:53] <zyga> mmm
[12:53] <zyga> jamesh: what kind of writable paths do you mean? precise rules or something high-level?
[12:54] <jamesh> zyga: the main use would be to identify cases where files do not need to be proxied through xdg-document-portal
[12:54] <zyga> oh, I see
[12:54] <jamesh> so it's alright if it isn't complete
[12:54] <zyga> jamesh: would it be ok if it was just a query per path?
[12:55] <zyga> jamesh: snap internal is-accessible --pid=123 /path/to/file
[12:55] <jamesh> zyga: perhaps.  I need to get up to speed with that code base again
[12:55] <zyga> ok
[12:55] <zyga> thanks for sharing, this is interesting
[12:56] <jdstrand> pstolowski: ime you don't want to run apparmor_parser so much on all profiles as much as run it only once at the end
[12:57] <jamesh> zyga: also: what is the best cross platform way to detect if a pid is a snap app?
[12:57] <jamesh> zyga: the current code is checking AppArmor labels, but that obviously doesn't work for the non AA distros
[12:57] <jdstrand> pstolowski: ie, snap.foo.bar has 3 interfaces. apparmor_parser it once after all 3 interfaces are connected instead of each time after one is connectedc
[12:57] <jamesh> the aim is to have something quick to check before shelling out to the "snap internal" command we eventually write
[12:58] <jdstrand> jamesh: the freezer cgroup atm
[12:58] <zyga> jamesh: that's a good question
[12:58] <zyga> jamesh: I'd like that to be an API of snapd, not something that is determined externally
[12:58] <zyga> jamesh: because e.g. the freezer or apparmor are internal implementation detail
[12:58] <zyga> jamesh: and that will change
[12:58] <zyga> jamesh: unless we can come up with a robust way to make that without making any problems
[12:58] <jamesh> zyga: the flatpak method is to check for a special file in the root directory of the process's mount namespace
[12:58] <zyga> jamesh: perhaps /proc/PID/root/meta/snap.yaml presence?
[12:59] <zyga> jamesh: that would be reliable today (except for classic snaps)
[12:59] <jdstrand> and yes, we should have an api
[12:59] <zyga> jdstrand: ^ I might even be happy with that being a stable way to check
[12:59] <zyga> regardless of an API
[12:59] <jamesh> zyga: treating classic snaps as unconfined is fine for the purposes of xdg-desktop-portal
[12:59] <jamesh> they effectively are anyway
[12:59] <pstolowski> jdstrand: right. this is kind of already done for auto-connect on install (landed recently, edge only atm)
[13:00] <jdstrand> pstolowski: the same goes for snap-seccomp
[13:00]  * zyga goes to a meeting
[13:00] <jdstrand> pstolowski: oh! 'kind of'?
[13:00] <pstolowski> jdstrand: the case i'm trying to cover now is where we regenerate all profiles on startup when system key or templates changed
[13:00] <pstolowski> jdstrand: 'kind of' in a sense that it's only for auto-connect, not connect in general
[13:01] <jdstrand> pstolowski: but that includes auto-connect via snap decl too, right?
[13:01] <jdstrand> (it would be weird if it didn't, but thought I'd ask)
[13:02] <jdstrand> pstolowski: what about app snap refresh?
[13:02] <pstolowski> jdstrand: yes, precisely that - when you install a snap, and slots get automatically connected
[13:02] <jdstrand> pstolowski: is refresh a special case for install?
[13:03] <pstolowski> otp
[13:03] <jdstrand> pstolowski: feel free to ping me after
[13:07] <mup> PR snapd#7331 closed: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7331>
[13:11] <pstolowski> jdstrand: yes, refresh as well, it's special case for install indeed
[13:15] <pstolowski> jdstrand: but there is atm no improvement if you manually snap connect multiple plugs/slots in one go. this could benefit from similiar optimization (as you suggested; and similiar to auto-connect), the framework for that is already in place and we can tackle it at some point
[13:16] <jdstrand> pstolowski: oh, I didn't know you could do more than one in one go :) indeed, that could be done. I think the key is once per command, not per snap or per batch of snaps and then you get reasonable optimizing with good error reporting
[13:17] <jdstrand> pstolowski: doing more than one profile at a time only saves you a fork/exec/tiny overhead which is probably not worth losing the error handling
[13:17] <jdstrand> at least note atm
[13:17] <jdstrand> not*
[13:17] <jdstrand> pstolowski: and this was done for snap-seccomp too?
[13:19] <pstolowski> jdstrand: yes, this was done on higher level than specific backends, we basically run setup-profiles just once at the right moment
[13:19] <jdstrand> pstolowski: woo nice! :)
[13:21] <pstolowski> jdstrand: hmm re apparmor parser, my tests on pi3 suggest we will benefit a lot (3x faster) by running aa parser once over multiple snaps' profiles, did i miss something? see https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909
[13:22] <pstolowski> (re error handling i'm sure we can overcome this, per zyga's suggestions)
[13:23] <jdstrand> pstolowski: so apparmor can do some parallelizing and things for sure... but it seems your --cache-loc is wrong
[13:24] <jdstrand> pstolowski: it should be /var/cache/apparmor, not /etc/apparmor.d/cache
[13:24] <jdstrand> the cache's should be invalidated
[13:24] <jdstrand> (though)
[13:24] <jamesh> jdstrand: I'll be talking to the freedesktop-sdk folk tomorrow.  Is there anything newer than what you wrote at https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153/40?u=jamesh that I should be aware of?
[13:25] <jdstrand> jamesh: unfortunately not. since the work is unplanned, it is falling behind some other stuff that is planned
[13:25] <jamesh> fair enough
[13:26] <jdstrand> jamesh: but, there is a clear path forward
[13:26] <jdstrand> it's 'just work'
[13:26] <jamesh> getting to that point is half the battle :-)
[13:26] <jdstrand> (in terms of implementaion. there are a few process details to sort out, but that isn't a big deal)
[13:26] <jdstrand> jamesh: ha, yes :)
[13:27] <zyga> mvo: FYI https://github.com/snapcore/snapd/pull/7316#pullrequestreview-279586840
[13:27] <mup> PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
[13:28]  * zyga goes to rest to avoid the back pain
[13:28] <mvo> zyga: thanks, looking
[13:31] <mvo> zyga: nice, thank you!
[13:32] <jdstrand> pstolowski: your use of snap.* is not accounting for snap-update-ns.*, no? did you find those aren't getting regenerated with ifacemgr?
[13:32] <mup> PR snapd#7173 closed: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7173>
[13:33] <pstolowski> jdstrand: indeed, looks like i used the wrong cache path. anyway, that shouldn't matter for the test due to --skip-read-cache, as i was testing the pessimistic scenario only
[13:34] <pstolowski> jdstrand: and you're right i haven't tested snap-update-ns* profile (it is covered by snapd code, so code is fine)
[13:35] <jdstrand> I think what is happening here is with the single call you are benefiting from parallel processing
[13:35] <jdstrand> whereas otherwise it is completely serial
[13:36] <jdstrand> gimme a second and I can confirm that
[13:36] <mup> PR snapd#7330 closed: tests: fix removal of snaps on ubuntu-core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7330>
[13:37] <jdstrand> right, a pi3 has 4 cpus that can be used
[13:37] <jdstrand> and so apparmor will used -j4
[13:39] <jdstrand> right, if I use --max-jobs=1 then I get roughly the same performance as serial
[13:39] <mup> PR snapcraft#2684 closed: meta: decouple DesktopFile logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2684>
[13:39] <jdstrand> 33s vs 35s on amd64
[13:43] <pstolowski> jdstrand: ah, that means it would help on faster machines (originally the problem was reported with fast pc & lots of snaps https://forum.snapcraft.io/t/snapd-causing-lengthy-boot-time/10466), but not on low-end ones that some customers have...
[13:44] <jdstrand> pstolowski: I commented: https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909/2
[13:45] <jdstrand> ps
[13:45] <pstolowski> jdstrand: thank you, that's useful feedback
[13:46] <jdstrand> pstolowski: let me dig up one more tidbit. I recall we had perf bugs in Ubuntu when we took all the CPUs and choked boot
[13:46] <zyga> mvo: another failure, daemon user present, test failed to add it
[13:47] <ogra> on actual single core HW you will also see I/O saturation that you wont if you use a multicore device and just limit cores
[13:47] <jdstrand> pstolowski: also, you may find this handy: getconf _NPROCESSORS_ONLN
[13:49] <ijohnson> jdstradn, pstolowski: fwiw the big problem I remember from a customer device about this is that it takes _ages_ on a low-end ARM CPU to finish the first boot because there's a lot of snaps and a lot of service/commands with a lot of plugs
[13:49] <mvo> zyga: yeah, I pushed a pr to get to the bottom of this
[13:49] <ijohnson> jdstrand: sorry ^
[13:49] <mvo> zyga: its very strange
[13:49] <jdstrand> pstolowski: right, I remember now. we could make the parser even faster by using a -j value higher than _NPROCESSORS_ONLN, and that was the problem. In Ubuntu, we use _NPROCESSORS_ONLN. *maybe* you want to use _NPROCESSORS_ONLN-1? (you'd want to measure, etc)
[13:50] <ijohnson> note that device only has one CPU core
[13:50] <jdstrand> ijohnson: that is already going to be helped tremendously by what pstolowski already did. run the parser once per command rather than once per interface per command
[13:50] <pstolowski> jdstrand: interesting. we may try to be conservative and paranoid there to start with
[13:51] <ijohnson> right okay, I missed part of this conversation so I wasn't sure what was being discussed right now :-) I'm sure they will be happy to hear that
[13:51] <jdstrand> btw
[13:51]  * jdstrand hugs pstolowski :)
[13:52] <jdstrand> pstolowski: ok cool. I forgot that the rpi3 had so many cores. parallelizing defintely helps with more cores :)
[13:54] <ogra> we should really measure on actual HW that was designed as single core though ... faking it like that will make you miss a lot of aspects
[13:55] <abeato> ijohnson, yes, I am happy to hear that :D
[13:55] <ogra> (though if the focus is really only on CPU processing thats probably okay ... but for overall performance mesuaring IO should also come into play)
[13:55] <pstolowski> jdstrand: thanks for looking at this!
[13:57] <jdstrand> ogra: well, note, on a single core it defaults to -j1. apparmor will use -jNUMBER OF CORES by default. My question is do we want to make that 'minus 1' or something
[13:57] <jdstrand> no one is suggesting a -j higher than the number of cores (I advocated agaisnt it :)
[13:57] <ogra> what would minus 1 achieve ? dynamic picking ?
[13:57] <jdstrand> no no
[13:58] <ogra> oh, you mean "one less"
[13:58] <jdstrand> I'm saying 1 core, -j1. 2 cores, -j1, 3 cores, -j2, etc
[13:58] <ogra> yeah
[13:58] <jdstrand> yes
[13:58] <ogra> got it, sorry, slow today
[13:58] <jdstrand> ie, leave at least one for other stuff
[13:59] <jdstrand> which is probably quite reasonable for a refresh core scenario
[13:59] <ogra> if we can we should surely do that since we might have something running in parallel (we have no real control about systemd here  i guess)
[13:59] <jdstrand> but I'll let others decide
[14:00] <abeato> jdstrand, or maybe change the nice value for the process, as another option?
[14:00] <jdstrand> oh, we can do that. calculate the cores (see aforementioned getconf command), add --max-jobs
[14:00] <jdstrand> abeato: that is an available option as well
[14:08]  * zyga has lots of back pain and stops to do any reviews too
[14:08] <zyga> sorry folks, need to break and get better somehow
[14:12]  * ijohnson relocates, back in ~15 min
[14:12] <pedronis> mvo: I got this:  https://api.travis-ci.org/v3/job/576683798/log.txt  do I need to merge master again?
[14:13] <mup> PR snapd#7334 closed: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7334>
[14:14] <mvo> pedronis: no, this is still under investigation :(
[14:14] <mvo> pedronis: its strange, let me add some more debug
[14:18] <cachio> mvo, hey
[14:18] <mvo> hey cachio
[14:18] <cachio> mvo, taking a look to the error on core18 I see this
[14:18] <cachio> https://paste.ubuntu.com/p/9hzczyDQjf/
[14:18] <cachio> 2.41. instead of 2.41~
[14:18] <cachio> is it a bug?
[14:19] <cachio> or we will use dot
[14:19] <cachio> just to see if I need to change the script
[14:19] <mup> PR snapd#7336 opened: tests: add debug section to interfaces-contacts-service <Created by mvo5> <https://github.com/snapcore/snapd/pull/7336>
[14:19] <mvo> cachio: thats a bug
[14:19] <mvo> cachio: the edge is the correct version
[14:20] <mvo> cachio: its just the version number though that is wrong in beta, its the right snapd
[14:20] <mvo> cachio: with the next beta/candidate the version shoud be fine
[14:20] <cachio> mvo, perfect
[14:20] <cachio> thanks!
[14:21] <mvo> cachio: once you are happy with the beta I can push a new version. but we need to make sure of course that it includes all fixes you have for 2.41
[14:22] <cachio> mvo, sure, I'll push a fix now
[14:22] <cachio> mvo, that + the fix for listing test should be enough
[14:22] <cachio> then I have another one but so far I cound't reproduce it
[14:25] <mvo> cachio: thanks, let me tag the listing one as 2.41
[14:25] <mup> PR snapd#7332 closed: tests: remove trailing spaces from shell scripts <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7332>
[14:25] <zyga> Thank you mvo
[14:31] <mup> PR snapd#7337 opened: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>
[14:39] <zyga> mvo: all stuff fails on travis
[14:39] <zyga> E: Failed to fetch http://apt.postgresql.org/pub/repos/apt/dists/xenial-pgdg/main/binary-i386/Packages  Writing more data than expected (788347 > 787357)
[14:39] <zyga> 269
[14:39] <mvo> zyga: yeah, I noticed - I don't think we can do much, this is in the travis setup itself
[14:39] <zyga> correct :/
[14:39] <mvo> zyga: I wonder if #travis is a thing to report issues
[14:40] <mvo> zyga: but I guess nowdays #twitter is the thing :P
[14:40] <zyga> I'm sure  they know
[14:40] <zyga> yeah
[14:40] <zyga> where the kids and crazy world leaders (or is that that same thing) are
[14:40] <zyga> mvo: random simple patch from my pile https://github.com/snapcore/snapd/pull/7338
[14:40] <mup> PR #7338: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338>
[14:40] <mup> PR snapd#7338 opened: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338>
[14:42] <mup> PR snapd#7339 opened: tests: don't look for lxcfs in mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/7339>
[14:45] <zyga> mvo: cna we unblock  https://github.com/snapcore/snapd/pull/7196
[14:45] <mup> PR #7196: packaging: use passthrough for type:snapd <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196>
[15:32] <pstolowski> cachio: https://github.com/snapcore/snapd/pull/7110 is green and can land?
[15:32] <mup> PR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
[15:36] <zyga> pstolowski: please hold on
[15:36] <pstolowski> ok
[15:36] <mup> PR snapd#7340 opened: tests: adding support for arm devices on ubuntu-core-device-reg test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7340>
[15:37] <zyga> pstolowski: I asked two questions there
[15:37] <zyga> cachio: can you please check those out?
[15:38] <cachio> zyga, sure
[15:38] <zyga> Thanks
[15:39] <zyga> I'm mainly after avoiding network IO
[15:39] <cachio> pstolowski, yes
[15:39] <cachio> :)
[15:40] <cachio> pstolowski, first let me check the questions
[15:45] <cachio> zyga, answered
[15:45] <cachio> zyga, thanks for the review, I didn't know about those questions
[15:46] <zyga> cachio: no worries, I just asked them a moment ago
[15:49]  * cachio lunch
[15:49] <zyga> cachio: replied again, sorry for being persistent about this
[15:49] <mvo> zyga: anything new in the twitter sphere about travis :) ?
[15:50] <zyga> mvo: sadly no
[15:50] <zyga> mvo: no status on travis website
[15:50] <zyga> as in, all is green there
[15:51] <mvo> booo
[15:51] <zyga> I'm still in bed so if I don't respond it's me trying to re-orient to get less painful layout
[16:04] <mvo> zyga: no worries, was just curious
[16:07] <zyga> oh, mvo is gone  :)
[16:07] <zyga> https://paste.ubuntu.com/p/Pdx9qmqbdH/
[16:07] <zyga> some unexpected stuff here
[16:07] <zyga> but I should break now
[16:22] <cachio> zyga, ok, let me see how could be changed that
[16:26] <cachio> zyga, do you know which test is installing a local version of the snap?
[16:26] <cachio> I found some but in most of the cases we are building the snap as part of the test
[16:26] <zyga> cachio: I don't remember from the top of my head, I recall seeing some that were installing a snap over itself but it was from "snap pack"
[16:26] <zyga> yeah
[16:29] <cachio> zyga, what do you suggest in this case?
[16:30] <zyga> snap install /var/lib/snapd/snap/core_$rev.snap
[16:30] <cachio> zyga, ah, ok
[16:30] <zyga> rev is read from readlink /snap/core/current
[16:31] <cachio> I'll try that
[16:38]  * zyga eod
[16:42] <cachio> zyga, updated
[16:42] <cachio> :)
[17:32] <mup> PR snapd#7341 opened: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>
[17:51] <zyga> travis is back to normal
[17:56] <ardaguclu_> Hi, there are some FIXME comments in various places, is it ok handling some of them. For instance, "// FIXME: this really should be TypeCore" in the types package
[17:56] <zyga> ardaguclu_: hey
[17:56] <zyga> ardaguclu_: yeah, though it's best to try asking first as some are harder or more tricky than others
[17:56] <zyga> ardaguclu_: but we 100% welcome all participation so please feel welcome :-)
[17:59] <ardaguclu_> zyga: thanks
[18:01] <ardaguclu_> creating unit tests and fixing bugs are the best ways to understand snapd codebase efficiently
[18:01] <ardaguclu_> that's why, I am really happy working these stuff :)
[18:02] <zyga> There is always something to improve :-)
[18:02] <zyga> I’m working on making the integration test suite more robust
[18:03] <zyga> Mainly by writing tools that detect misbehavior and adjusting tests not to do bad stuff
[18:07] <ardaguclu_> zyga: you are right, they are definitely not bad stuff.
[19:18] <arnatious> Hey all - I'm trying to run the code-insiders snap in an 18.04 lxd container and I'm just getting "dropping privs did not work"
[19:19] <arnatious> That look like a snap error or should I look elsewhere?
[19:26] <kyrofa> arnatious, it's definitely snap-related (comes from snap-confine if I remember correctly), just not sure what might be causing it. It's not a privileged container, is it?
[19:27] <arnatious> kyrofa nope
[19:27] <kyrofa> Hmm. zyga, any idea there? ^
[19:28] <arnatious> It has nesting enabled, and is being run from `lxc shell --user 1000 --env SHELL=/bin/bash -- sh -c /bin/bash`
[19:31] <kyrofa> arnatious, nesting shouldn't need to be enabled
[19:41] <mup> PR snapd#7342 opened: fixme: rename ubuntu*architectures to dpkg*architectures <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7342>
[19:52] <mup> PR snapcraft#2686 opened: New app handler (command-chain and no wrappers if command allows for it) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2686>
[19:58] <mup> PR snapcraft#2679 closed: colcon plugin: add ability to ignore packages in workspace <Created by danielwangksu> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2679>
[19:58] <mup> PR snapcraft#2687 opened: colcon plugin: add ability to ignore packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2687>
[21:50] <mup> PR snapd#7343 opened: tests: moving tests to nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7343>
[22:43] <mup> PR snapcraft#2688 opened: Build base types <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2688>


[07:13] <abogani> BenC: ping
[07:18] <abogani> BenC: About "Reviving Ubuntu PowerPC"...
[07:18] <abogani> BenC: What systems will be used as reference in this effort?
[07:18] <abogani> BenC: Thanks!
[08:35] <ppisati> infinity: how is the armhf image going?
[08:35]  * smb steps in
[08:37] <jjohansen> ppisati: last I heard well
[08:37] <ppisati> cool
[11:19] <ppisati> uhm, nice
[11:19] <ppisati> if you switch kernel release, it breaks princhanges&c
[11:33] <hrw> hi
[12:29] <BenC__> abogani: I'm more interested in server platforms (as opposed to legacy mac systems)
[12:30] <BenC> abogani: personally, I'm using a freescale e500mc based system (8-core, 32-bit)
[12:44] <Stratisphere> Morning, i'm running xbmc with PVR on oneiric but there is a bug with the 3.0 kernel that prevents me from using my TV card. There is a patch available but hasnt made it upstream I believe. Whats the best way I can go around compiling the patch in to my kernel on my machine?
[12:44] <Stratisphere> or whats the risk with downgrading to a 2.6 kernel?
[12:46] <abogani> BenC: Interesting. Is there a roadmap already?
[12:48] <smb> Stratisphere, Mostly the risk is that it is not tested at all. So some stuff may break or it works. And probably it will be a hassle to always keep track of updates to those older kernel...
[12:49] <smb> Stratisphere, But as a work-around... Since it is a different version, at least you can boot back into other kernels with grub
[12:51] <Stratisphere> yeh true. What about downloading the 3.0 source and patching the fix in, if I just grab the source from https://github.com/torvalds/linux/tags is that suitable?
[12:51] <Stratisphere> sorry, what i'm getting at is, does ubuntu have any specific bits in it?
[12:51] <smb> Stratisphere, Rather go to git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git
[12:51] <Stratisphere> ah ha, thats what I was after :)
[12:52] <smb> That also has all the build stuff to make debs
[12:52] <Stratisphere> oky cool
[12:52] <Stratisphere> is it somewhat stable?
[12:52] <smb> The master branch is what is the current kernel in proposed which goes into updates
[12:53] <smb> So fairly stable
[12:53] <Stratisphere> oky cheers
[12:53] <Stratisphere> thanks for your help :)
[12:53] <smb> np :)
[12:53] <Stratisphere> sucks, had to upgrade from lucid to fix the IR remote, but upgrading meant it broke the Tv card :P
[12:54] <smb> I know the pain. Though for me it will be the other way round (at least I intend to go to oneric lts backport kernel to enable mine)
[12:55] <Stratisphere> ahh, the struggles of an awesome HTPC :D
[12:56]  * Stratisphere hopes the wife appreciates it when he's done
[12:56] <smb> Stratisphere, hehe, depends on the media you put onto it, me thinks. :)
[12:57] <Stratisphere> lol ruhoh. Mostly my scifi stuff! I keep telling her to tell me what to download but she never does lol
[12:57] <Stratisphere> still. She can now play her iphone things on the TV which is kind cool
[12:58] <smb> You know how it works, you're supposed to know without asking. ;) But having the other thing may help, too. :)
[13:13] <Stratisphere> hmm, lol the changesets are already in that repo
[14:01] <Stratisphere> wow it takes a while to compile the kernel!
[14:02] <smb> Depends on how powerful the build machine is... But "normal" ones... yes
[14:02] <Stratisphere> out of curiosity, say you were to compile the kernel and then change one .c file... does it just compile that one file and then relink them or does it have to compile everything from scratch? (sorry, c noob here :P)
[14:04]  * Stratisphere should have started the compile in a screen :(
[14:05] <smb> Using the normal packaging without tricks, everything. At least when you use dpkg-buildpackage. There is work-arounds
[14:06] <smb> by only running "fakeroot debian/rules binary-xxx" and removing the build stamp file under debian...
[14:06] <smb> (xxx = the flavor like generic or generic-pae)
[14:07] <Stratisphere> gotta say, you guys deserve top credits. i'm sure i've just seen the top of the pile but how you guys manage such a massive and complex project is amazing
[14:07] <Stratisphere> btw, whats -pae?
[14:07] <tgardner> sconklin, have you been running any of your tests on an ecryptfs mounted FS ?
[14:08] <smb> The PAE feature enabled (which is physical address extenstion, I believe). This allows to use more than 4G of RAM in i386
[14:08] <Stratisphere> ahh
[14:08] <Stratisphere> knew I had heard/seen it before
[14:25] <ledzgio> hi all
[14:26] <ledzgio> I have a patch for an ethernet driver and I have to compile the kernel and apply that patch
[14:26] <ledzgio> could someone help me in that?
[14:28] <smb> Will this help? https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[14:29] <ledzgio> yes, I have to apply this patch
[14:29] <ledzgio>  http://patchwork.ozlabs.org/patch/125198/
[14:29] <ledzgio> how can I do that following the document you linked before?
[14:30] <smb> ledzgio, I would propose to get the source the git way. Then you can save the raw patch and try "git am <patch>"
[14:31] <ledzgio> could you please explain better whats mean " Then you can save the raw patch and try "git am <patch>""
[14:31] <ledzgio> ??
[14:32] <smb> ledzgio, There is a patch link on that page that will let you download the complete patch. Then you go into the directory containing the source git tree and run the command "git am" with the file as argument
[14:33] <smb> Or without git you run "patch -p1 < xxx" where xxx is again the patchfile
[14:33] <ledzgio> ok you mean the patch in the link I have sent to you correct?
[14:33] <smb> yes
[14:34] <ledzgio> the command git am will apply the patch to the kernel?
[14:34] <ledzgio> at that time I only need to build the patched kernel correct?
[14:34] <Stratisphere> im off. Thanks again for your help smb :)
[14:34] <smb> Stratisphere, welcome
[14:35] <smb> ledzgio, yes. git am does a bit more if the file is in a special format which is to make it a commit in the repo
[14:36] <smb> The link you sent looked like it would be the right format. But anyways if either way of applying succeeds you build that source
[14:36] <smb> I suggest you change debian.master/changelog to add something like +myversion to the version number in the first line
[14:37] <smb> That way the package and the running kernel have a specific version where you can see that you are really running your kernel
[14:37] <ledzgio> ok perfect
[14:38] <ledzgio> thabk you, I'll give it a try later
[14:38] <ledzgio> if you will be here I'll contact you again if I have problem
[14:39] <smb> I may or may not be
[14:39] <smb> But there are always some people that can help around
[14:39] <ledzgio> ok thank you very much
[14:39] <ledzgio> your help is really appreciated
[14:40] <ledzgio> the last thing
[14:40] <smb> np
[14:40] <ledzgio> I think that patch is good with kernel 3.0 or 3.1 also
[14:40] <ledzgio> correct?
[14:41] <sconklin> tgardner: no, but there's no reason not to. The ltp lite that's currently being used doesn't do much file system testing. I'll (eventually) try running tests against ecryptfs
[14:42] <sconklin> tgardner: I've pretty much completed the inventory of what's in ltp: https://wiki.canonical.com/SteveConklin/LtpTestList
[14:42] <smb> That depends. I did not read all the details. If its just going upstream the chances are higher. But it was some wireless driver and there could be more change in that area of code
[14:43] <ledzgio> I told you that because on top of that page are specified the versions and architectures supported(?)
[14:43] <tyhicks> sconklin: Sync up with me before you do start running tests against eCryptfs. I hope to have a nice way to set up various types of eCryptfs mounts and run the typical filesystems tests against those mounts.
[14:44] <sconklin> tyhicks: sweet, OK
[14:46] <smb> ledzgio, Well that is the usual thing with backports. You may find that the compile breaks because some defines are not present (meaning support was neither) and then you have to tweak things. Also note that on that page the status has been set to superseded. Could mean there is something newer or different
[14:46] <tgardner> sconklin, tyhicks: I'd like to get a full suite of ecryptfs tests running well before Beta 1. I'm still getting plenty of hate mail over corrupted disks.
[14:47] <sconklin> tgardner: I can walk you through a manual install of ltp and tell you how to run the tests. In a few days, I may have that automated
[14:47] <sconklin> (running of ltp in general, not ecryptfs)
[14:47] <tgardner> sconklin, I'll wait. I've got other things on my plate right now.
[14:48] <tyhicks> tgardner: agreed - before Beta 1 would be great
[14:52] <ledzgio> smb, when you say "you have to tweak things", which kind of tweaks?
[14:54] <smb> ledzgio, Decide how to modify the code, so it does compile in a way that still does work the same for the remaining code...
[14:59] <ledzgio> ok I have some basics of C, I think i can do that if those tweaks are not too complicated
[15:04] <ledzgio> thank you
[15:04] <ledzgio> smb
[15:04] <ledzgio> your help is really appreciated
[15:04] <smb> you're welcome. no worries
[15:06] <ledzgio> bye
[15:29]  * ogasawara back in 20
[16:12] <smoser> smb, around ?
[16:13] <smb> smoser, at the moment, yes
[16:13] <smoser> http://paste.ubuntu.com/762860/
[16:13] <smoser> that is get-console-output of a precise hvm instance.
[16:14] <smoser> i'll point out that there is no 'idle=halt'.
[16:14] <smoser> the instance was not reachable.
[16:17] <smb> smoser, right. Hard to say. Usually we know things get missing. Hm, also let me do a quick version check...
[16:17] <smoser> i dont know if idle=halt would help or not. i tried a quick start, stop, attach, modify /boot/grub/grub.cfg, re-attach, start,
[16:17] <smoser> but then got *no* console output
[16:19] <smb> smoser, I did not see a using mwait in that one... so probably not...
[16:19] <smb> smoser, But maybe it was before the k(u)nmap patch, though that normally hit only on higher load...
[16:19] <smoser> smb, that is just the latest precise daily... but i have unfortunately no recollection of if this has worked at all in precise.
[16:20] <smb> smoser, I think I got precise booting in my environment (I also think in the ec2 alike) but having booted too many variations I get confused
[16:20] <smb> and I got amd
[16:22] <smoser> smb, i suppose i should open a bug, eh?
[16:24] <smb> smoser, Can you reproduce it at will? ;-P But ok, we need to have an eye on it...
[16:24] <smoser> it reproduced 2 times out of 2
[16:24] <smoser> but maybe i'm lucky
[16:25] <smb> At least you might be lucky with the xen version
[16:25] <smb> So this one at least is 3.4...
[16:28] <smoser> smb,  bug 901305
[16:28] <ubot2> Launchpad bug 901305 in linux "precise fails boot on ec2 hvm" [High,Confirmed] https://launchpad.net/bugs/901305
[16:29] <smb> Oh HVM, right... Hm... That one I clearly have been running at least with my Oneiric dom0... at least
[16:35] <bjf> tgardner: is the lts-backport-natty kernel on the 10.04.3 CD/DVD ?
[16:37] <smb> smoser, The only difference is that I usually go for the "normal" kernels when doing hvm installs...
[16:39] <tgardner> nope, only maverick thus far
[16:39] <tgardner> bjf, ^^
[16:40] <bjf> tgardner: thansk
[16:41] <tgardner> bjf, the next point release should pick up natty and oneiric
[16:44] <tgardner> bjf, I wonder if there is a bug for that yet.
[16:45] <bjf> tgardner: i doubt it but skaet would probably know
[16:45] <tgardner> I'm creating one
[16:49] <tgardner> bjf, skaet: bug #901317
[16:49] <ubot2> Launchpad bug 901317 in debian-installer "10.04.4 DVD must include Natty and Oneiric kernels" [Undecided,New] https://launchpad.net/bugs/901317
[17:11]  * smb ends the day
[17:28] <ledzgio> hi
[17:28] <ledzgio> smb are you there?
[17:29] <ledzgio> I'm going to build my own kernel with a patch for my ethernet card
[17:29] <ledzgio> is there a way to enable pae support?
[17:29] <ledzgio> for ram > 4GB
[17:29] <ledzgio> ?
[17:34] <ledzgio> i'm going to patch my kernel, but when I type git am patch_file it says "patch format detection failed"
[17:34] <ledzgio> this is the patch http://patchwork.ozlabs.org/patch/125198/
[17:42] <ledzgio> guys
[17:48]  * ppisati -> eod
[17:49] <tgardner> ogasawara, I think apw's ext4 patch is worthy of an upload
[17:49] <ogasawara> tgardner: ack
[18:38] <vanhoof> sforshee: yo
[18:38] <vanhoof> sforshee: just to be certain, "[PATCH] dell-wmi: Change debug statements from pr_info to pr_debug"
[18:38] <sforshee> vanhoof, hey
[18:38] <vanhoof> sforshee: right thread?
[18:38] <sforshee> vanhoof, yep. I was just typing a reply to your email
[18:38] <vanhoof> sforshee: ok, i'm gonna go ahead and bounce it and send him a mail if that's cool with you
[18:39] <sforshee> vanhoof, that would be great, thank you
[18:42] <vanhoof> sforshee: done, let's see what we turn up :)
[18:42] <ledzgio> how can I enable pae support when building my own kernel?
[18:42] <vanhoof> sforshee: also sent him something with a bit of context
[18:44] <sforshee> vanhoof, good deal. I hope we can get a response on the thread, but I have no problem with sending the information myself either
[18:45] <ledzgio> with git
[18:45] <tgardner> ledzgio, there is already a flavour with PAE enabled, e.g., generic-pae
[18:56]  * cking has nearly finished with his wrestling with powertop
[19:06]  * tgardner -> lunch
[19:25] <ledzgio> how can I change the kernel name when I try to build my own?
[19:32] <ledzgio> thank you guys
[19:32] <ledzgio> really
[20:04] <arges> hey, looking at https://bugs.launchpad.net/ubuntu/+source/udev/+bug/842560 . Looks like the bnx2 binary blob is having issues. Does it make sense to suggest upgrading the firmware? and where/how is that done?
[20:04] <ubot2> Launchpad bug 842560 in linux "bnx2 firmware missing" [High,Confirmed]
[20:06] <tgardner> arges, its not a firmware problem. its a udev race.
[20:06] <arges> tgardner, ok been trying to understand it reading through the bug. so the fix is in udev?
[20:06] <arges> or should be
[20:07] <tgardner> arges, yep, the driver is working fine. its in the transition from initrd udev to rootfs udev
[20:07] <tgardner> arges, apw is more familiar with the details
[20:08] <arges> tgardner, ok, https://bugs.launchpad.net/ubuntu/+source/udev/+bug/842560/comments/43  made me think it was a kernel issue
[20:08] <ubot2> Launchpad bug 842560 in linux "bnx2 firmware missing" [High,Confirmed]
[20:08] <arges> ok i'll sync up with apw then when he's around
[20:09] <tgardner> arges, we had a number of chats with slangasek at UDS about this issue. I'm pretty sure apw found the root of the problem.
[20:10] <apw> arges, yep we are pretty sure the issue is that firmware loads are not restartable
[20:10] <arges> tgardner, ok awesome.
[20:10] <apw> arges, but that only matters because we don't drain waht is in progress when we restart udev
[20:11] <arges> apw, ok, anything I can help you with on this bug?
[20:11] <apw> arges, essentially we need to clean up the hand over, probally using the systemd handover
[20:11] <apw> arges, it near the top of my todo, i need to re-review it in the morning perhaps we can chat tommorrow then after that
[20:12] <arges> apw, yea sounds good
[20:13] <apw> arges, you might investigate who has the reproduing machine and see if we have access to it for testing
[20:13] <dupondje> somebody alive that takes care of the daily builds ? :)
[20:14] <arges> apw, volon can reproduce the bug
[20:15] <bjf> dupondje: what is the issue you'd like someone to address ?
[20:15] <apw> arges, vorlon ?
[20:15] <dupondje> Well, the .config needs to be changed a bit
[20:15] <arges> apw, steve langasek
[20:15] <apw> arges, indeed
[20:15] <dupondje> cause the CONFIG for intel wireless changed.
[20:16] <apw> dupondje, whats wrong with the dailies ?
[20:16] <dupondje> which makes no more intel wireless driver is build :)
[20:16] <dupondje> and thats annoying :)
[20:16] <tgardner> apw, I think he means mainline
[20:16] <bjf> dupondje: we are kind of detail oriented, not good at guessing
[20:16] <slangasek> apw: do you need me to get you access to the reproducing box?
[20:16] <apw> dupondje, whats the config name change from and to, and i'll get it fixed
[20:16] <dupondje> -CONFIG_IWLAGN=m
[20:16] <dupondje> +CONFIG_IWLWIFI=m
[20:17] <apw> slangasek, that may well make sense, i don't think i need it immeidiatly but yes
[20:17]  * apw adds it to tommorrows todo
[20:17] <slangasek> ok, let me see if I can get that sorted
[20:19] <dupondje> http://comments.gmane.org/gmane.linux.kernel.wireless.general/81036 FYI
[20:19] <bjf> dupondje: thanks, we'll take a look at that
[20:20] <dupondje> thanks :)
[20:20]  * dupondje was looking why his wireless didn't work in the daily builds :P
[20:25] <skaet> bjf, tgardner - ack.
[20:26] <tgardner> skaet, its been so long I've forgotten what this is about.
[20:26] <cking> slangasek, I've completed the journal-commit test (+readahead) with various applications running and updated bug 900923. Just some more data points to consider
[20:26] <ubot2> Launchpad bug 900923 in pm-utils "pm-utils: readahead and journal-commit waste power" [Medium,New] https://launchpad.net/bugs/900923
[20:26] <skaet> tgardner, backports on DVD
[20:26] <tgardner> skaet, ah, right
[20:27] <slangasek> cking: thanks :)
[20:27] <cking> I'm very happy to test different scenarios if you deem it necessary
[20:28] <slangasek> cking: I don't imagine so; I'll have a look at the data today
[20:28] <cking> cool - thanks
[20:29]  * ogasawara wonders what's bringing zinc to a crawl.  taking forever to upload.
[20:30] <cking> jsalisbury is doing a git merge which is sucking cycles
[20:31] <cking> nope, it's something else too
[20:31] <jsalisbury> cking, hmm, let me take a look
[20:31] <tgardner> ogasawara, prolly gitweb
[20:32] <cking> reckon so
[20:33] <jsalisbury> cking, on zinc, I'm not doing a git merge that I know of?  Maybe I have something that ran away
[20:33] <cking> jsalisbury, it was busy for some tens of seconds and then popped away..
[20:34] <jsalisbury> cking, ok
[20:35] <vanhoof> sforshee: looks like the mail just landed -- hopefully that's helpful
[20:36] <dupondje> sforshee: seems your quite active in the platform mailing list. Any chance you can have a look @ my email from some days ago?
[20:37] <dupondje> aka 'dell-laptop: bug in rfkill'
[20:49] <sforshee> vanhoof, that's great. Thanks for your help.
[20:52] <sforshee> dupondje, I found your message. Let me look at it.
[20:53] <vanhoof> sforshee: np, let me know if you need any other info :)
[20:53] <sforshee> dupondje, have you filed a bug?
[20:53] <sforshee> in launchpad that is
[20:53] <dupondje> sforshee: not yet
[20:54] <sforshee> dupondje, please do so. If you use 'ubuntu-bug linux' to file the bug it will attach a bunch of useful information
[20:55] <vanhoof> dupondje: only thing that comes to mind is this: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/887834
[20:55] <ubot2> Launchpad bug 887834 in network-manager "Unable to find wireless networks after toggling wireless" [Undecided,Fix committed]
[20:56] <vanhoof> dupondje: but that's a total guess
[20:58] <dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/901410
[20:58] <ubot2> Launchpad bug 901410 in linux "dell-laptop: rfkill bug" [Undecided,New]
[20:59] <dupondje> When I block the dell-bluetooth, my Wireless LAN gets hard blocked
[20:59] <dupondje> which ofc shouldn't happen :)
[21:00] <sforshee> dupondje, thanks. I'll set aside some time a little later to take a look, and then I'll comment on the bug.
[21:19]  * ogasawara lunch
[21:19] <dupondje> sforshee: thanks alot :)
[22:12]  * tgardner -> EOD


[14:03] <ShalokShalom> hi there
[14:03] <ShalokShalom> https://docs.lubuntu.net/releases
[14:03] <ShalokShalom> 18.04 is not here


[14:26] <Brian_H> hey bkerensa "check in the mail" :)
[14:27] <bkerensa> Brian_H: Cool... I think now I just wait to hear from them sometime next month
[14:27] <bkerensa> Brian_H: I'll bring it down for the release party too
[14:27] <Brian_H> hahah awesome
[14:28] <Brian_H> new laptop comes today pretty excited
[14:40] <bkerensa> Brian_H: Which did you end up getting?
[14:41] <Brian_H> ended up getiting the smaller version of what I have, which is a dell latitude 6420
[14:41] <Brian_H> it will work with all the existing work related plugs/docks etc
[14:42] <Brian_H> so it was a logical decision
[14:42] <bkerensa> cool
[14:43] <bkerensa> Brian_H: You going to BarCamp?
[20:58] <bkerensa> Brian_H: The banner is done I am headed out to pick it up
[20:58] <Brian_H> aweseom!
[20:59] <Brian_H> wheres barcamp/what it is?
[21:04] <bkerensa> Brian_H: Barcamp http://barcampportland.org/ "a international community of user-generated conferences with DIY/Hacker/Open Culture themes
[21:04] <bkerensa> its a tech gathering :)
[21:04] <bkerensa> and its going on tonight and tomorrow and its free
[21:05] <Brian_H> awesome


[01:34] <jeri> just installed 14.04 lts, i wanted to know if i can upgrade to the latest kde, what i mean upgrade the desktop environment only, not upgrade to 16.04.
[01:35] <jeri> amd doesn't support 16.04 with amd gpu amd radeon 8470d. that's why i installed 14.04
[01:37] <mparillo> Not the latest, but you can install the Kubuntu Backports PPA.
[01:37] <mparillo> Oh, _14_
[01:38] <jeri> can you show me how?
[01:38] <mparillo> You can follow these instructions, but 14.04 is pretty old
[01:38] <mparillo> https://kubuntu.org/news/plasma-5-11-5-bugfix-release-available-in-backports-ppa-for-artful-aardvark-17-10/
[01:39] <jeri> yeah. if it wasn't only for the gpu driver i wouldn't install 14.04
[01:39] <jeri> thank u.
[01:39] <mparillo> YW. I am afraid that backports will add nothing new. 14.04 is Plasma 4, right?
[01:41] <jeri> yes. umm really don't like the ui.
[01:43] <mparillo> Yes, 14.04 was the last Plasma 4 LTS release. Plasma 4 is pretty much pining for the fjords.
[01:45] <mparillo> By 14.10, Plasma 5 was optional (but pretty much unusable). After 3+ years, Plasma is in a good place again.
[01:45] <jeri> cool :)
[01:45] <jeri> the last time i used kubuntu was 6.06 lts, which i find it really good.
[01:50] <jeri> there is a bug, i think, when it ask me for the password in samba share, i provided my password but keeps asking me in a loop.
 SDDM question: why would SDDM start on hybrid laptop with the intel driver but not the NVidia driver?
[01:55] <mparillo> I am no expert on samba, and all I know about NVidia is the picture of Linus.
 @jeri, Which version of kubuntu?
[01:58] <jeri> lol haha
[01:58] <jeri> @IrcsomeBot you mean the one im using right now?
 @jeri, Yes, which version of kubuntu is samba causing trouble?
[02:04] <jeri> 14.04
 @jeri, I have not used 14.04 in a while, but I do remember it had issues.  I resorted to using fish://<server name> in dolphin as it was much easier and did not require manual sharing of invidiaul directories.
 I think you need to install ssh on respective machines to enable: sudo apt install openssh-client openssh-server
[02:26] <jeri> thank u @IrcsomeBot
[02:27] <jeri> just finished upgrading. need to reboot.
[02:28] <jeri> one last thing, at the konsole it said: setting up xserver-xorg-video-ati-lts-xenial. does it mean its using gpu drivers from the latest 16.04?
 @jeri, I never have used AMD drivers on Linux, so I am no help there....
[02:30] <krytarik> But yes, it does.
[02:31] <jeri> aww okay @IrcsomeBot thank u ;)
[02:32] <jeri> @krytark radeon 8470d is not supported by amd on machines with 16.04
[02:32] <jeri> thats why left 16.04 awhile ago and installed 14.04
[02:33] <krytarik> Well, that's not the proprietary driver anyway.
[02:36] <krytarik> !amd
[02:39] <jeri> @krytarik okay. so it means amd hasn't have support for now but ubuntu has some driver for it?
[02:40] <jeri> btw im using an A6 6400k richland apu with 8470D gpu in it.
[02:50] <krytarik> jeri: So that looks like the open-source 'radeon' driver would be for you then.
[02:52] <jeri> oh okay. then the one im using for before i installed 14.04 is already good. just wanted to make sure im using the full potential of the gpu .
[02:57] <jeri> thanks @krytarik. and thank u guys
[06:05] <lordievader> Good morning
[09:03] <jeri> instead of reinstalling the 16.06 with usb, i'm doing an upgrade, what version will it be after it finish?
[10:22] <ktecho> Hi friends. I've just noticed that in my Kubuntu 18.04 there is a service called mpd.service. I've tracked it upto here:    https://help.ubuntu.com/community/MPD
[10:23] <ktecho> do you know what's it for? Do I need it to play music from VLC, MPV or Cantata?
 cantata
[10:24] <ktecho> I've seen that Cantata uses it, but I don't use Cantata, so it would be nice to know if I can remove it
 you can then
[10:25] <ktecho> just removed them. Will reboot to see if things continue to work
 Hi everyone. Will there be a more recent KDE framework in 16.04 any time soon? :-)
 No. Sorry
 Hi Rik. Thanks for the fast reply. Why won't there be an update?
 We can't support or do the QA to update the version in the archive. In backports PPA, we have the newest possible version supported by Qt 5.6 we have there.
[11:38] <Lorra> Hi everybody, I was trying to use my bluetooth speaker with KDE5. Association works just fine and the speaker emits its successful associaton tone, but then I cannot change the audio profile to A2DP nor to HSP/HFP. Does anybody have a clue about this? Thank you ^^
[11:46] <deniska_> когда релиз 18.04?
 @acheronuk, Thank you for your time and quick answer!
[12:53] <BluesKaj> Howdy all
[14:09] <lanini1101> https://discord.gg/gM5rux
[14:10] <lanini1101> https://discord.gg/gM5rux
[23:37] <Guest82974> brasileira por aqui
[23:37] <krytarik> !br


[00:16] <Unit193> pleia2: Heh, finally got to it, and that doesn't work anymore either, so glad I have this!  (Wiki blocks some UAs)  Also know why my script fails on some, the pages don't support HEAD requests.
[00:16] <pleia2> oh yeah, the wiki never worked with that
[00:16] <pleia2> I always had to assume the wiki links were correct
[00:17] <Unit193> Mine "spoofs" it's UA as Firefox. :D  (Aurora, technically)
[00:54] <pleia2> The new edition of the Ubuntu Weekly Newsletter is now available here: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue303
[01:15] <Unit193> Still good.
[07:59] <dholbach> good morning
[20:32] <pleia2> so, Jasna has to back off Ubuntu work for now, I'm going to need some help rounding up news and more folks pitching in with summaries (she did a lot!)
[20:35] <akgraner> pleia2, I'll add some some block time to my schedule and chip in more
[20:36] <pleia2> akgraner: thank you :)
[20:36] <pleia2> awful timing for me, I'm out of town for the holiday this weekend (we'll release on Tuesday of next week due to the holiday) and then SCaLE the next weekend
[20:36] <akgraner> (yes I totally mean it - my vacation and being totally unplugged totally recharged me)
[20:36] <pleia2> glad to hear it, hooray for unplugged vacations!
[20:36] <Unit193> As far as Ubuntu goes, I only read Phoronix and the oddball article elsewhere.
[20:36] <pleia2> very much looking forward to my honeymoon in May :)
[20:37] <akgraner> pleia2, Pete locked up my phone, tablet and chromebook in the safe on the cruise
[20:37] <pleia2> akgraner: haha
[20:37] <akgraner> I didn't even take a single picture
[20:37] <pleia2> pgraner++
[20:37] <akgraner> and it was soooooo worth it
[20:37] <pleia2> :)
[20:37] <pleia2> I'm hoping to have my new camera for my honeymoon, so I'll have that but I'm going to not do internet
[20:38]  * pleia2 was even online constantly while in Africa, needs this break
[20:38] <akgraner> I didn't even do that when we got married -- Pete was deploying and I was working on the conflict so we had like 3 days and even then we were "flirting" with work stuff
[20:38] <pleia2> yeah, we've had to make some major adjustments work-wise to pull off this honeymoon, it's going to be painful when we return
[20:38] <akgraner> yeah  - just concentrate on each other the interwebs will be here when you get back
[20:39] <pleia2> I'll be attending the openstack summit a week before my wedding, will be unavailable Ubuntu release day and skipping UDS entirely
[20:39] <pleia2> but the beginning of the cycle for both projects really is the easist time for me to get away
[20:40] <pleia2> on a scale that goes from "not easy" to "really really really hard" :)
[20:40] <akgraner> I get it - but I've got your back and help the team however I can
[20:40] <pleia2> \o/
[20:42] <akgraner> If you get a chance let's have a quick hangout before you go digitally dark
[21:27] <JoseeAntonioR> pleia2: I can help with summaries too, will try to do more this week


[08:26] <HelpShortcut> Sup guys, CTRL ALT T does not work but every other shortcut is working fine
[11:56] <maxagaz> hi
[11:57] <maxagaz> I have accidentally remove the default panel after a new first install of ubuntu 17.04
[11:57] <maxagaz> how can I recover it ?
[11:57] <maxagaz> restore
[15:48] <notf> Is there a canonical guide for installing Lubuntu on a computer via CD or USB?
[15:48] <notf> Or does any old tutorial off google suffice?
[16:22] <FoeHammered> This might be a silly question, but what on earth is the name of the stock Lubuntu clock? Regardless of that answer, how do I get a desktop clock that shows multiple timezones at once?
[18:05] <FoeHammered> Never mind. Still not sure exactly what clock it nominally uses, but somebody hooked me up with Conky and I'm in looooove.
[19:13] <slim_> hi, can this be installed on hp laptop?
[19:13] <lyn||ian> slim_, yes most of the time unless something really wierd happens but there are lots of hp laptops
[19:15] <slim_> mine is 250 g notebook,running win 10 .will it work?
[19:42] <JohnDoe_71Rus> https://s30.postimg.org/nfkmqngq9/2017-04-01-094710_1920x1080_scrot.png icons on libreoffice window. this problem LO or lxpanel?
[19:43] <JohnDoe_71Rus> LO <IP_ADDRESS> the same
[20:02] <lyn||ian> JohnDoe_71Rus, I think it is actually maybe an openbox problem as that is what is drawing the window decorations and titlebars
[20:03] <JohnDoe_71Rus> other window with icons. and old LO 4.4. with icons too
[20:03] <JohnDoe_71Rus> at the bottom plank with icon
[20:05] <lyn||ian> JohnDoe_71Rus, I see but this might be a thing that does not only happen with new libreoffice I do not think
[20:05] <lyn||ian> it is a big archive
[22:43] <strive> Hello. I'd like to know if there are any exclusives within Lubuntu that aren't included in lxde alone?
[22:45] <lyn||ian> strive, icon theme and default settings and keybindings really
[22:45] <lyn||ian> are the main things
[22:45] <strive> lyn||ian: Ah, ok.
[22:46] <lyn||ian> some of the program packages are not lxde of course and then there is the whole rest of the ubuntu archives
[22:46] <strive> lyn||ian: Right.
[22:48] <strive> I'll give Lubuntu a try :)