[03:33] <mup> Bug #1871827 opened: git ubuntu submit fails on focal <snap> <submit> <Snappy:New> <usd-importer:New> <https://launchpad.net/bugs/1871827>
[05:58] <zyga> https://github.com/snapcore/snapd/pull/8581/checks?check_run_id=631328561 <- persistent journal failed
[05:58] <mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
[06:08] <mup> PR snapd#8582 opened: github: register matchers before running spread <Created by zyga> <https://github.com/snapcore/snapd/pull/8582>
[07:09] <pstolowski> morning
[07:24] <mvo> hey pstolowski
[07:24] <pstolowski> mvo: hi! how is the sprint going?
[07:30] <zyga> hey guys
[07:30] <zyga> I'm doing some test fixes
[07:30] <zyga> pstolowski: do you have backscroll?
[07:30] <zyga> pstolowski: can you see my message at 7:58?
[07:31] <pstolowski> zyga: i don't have it
[07:31] <zyga> https://github.com/snapcore/snapd/pull/8581/checks?check_run_id=631328561 <- persistent journal failed
[07:31] <mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
[07:31] <zyga> the failure is silly but wonder why
[07:38] <pstolowski> zyga: yeah it consistent with the previous failures, no idea. looks like snapd gets restarted (or crashes) during configure hook. i will think about a debug section for this test. thanks
[07:38] <zyga> is there something in the logs?
[07:42] <pstolowski> zyga: nothing obvious, "Running task 84 on Do: Run configure hook of "core" snap" is the last task run, and snap set fails with 'error: cannot communicate with server: Put http://localhost/v2/snaps/core/conf: EOF'
[07:42] <zyga> hmm
[07:42] <zyga> what ran before?
[07:43] <pstolowski> it's just snap set with true/false in this test
[07:43] <zyga> can you report a bug with the failure fragment, the list of tests that ran before and any additional insight
[07:43] <zyga> I mean tests that ran on this machine before this one
[07:43] <pstolowski> ah, that
[07:43] <pstolowski> yep, good idea
[07:43] <pstolowski> main/cgroup-devices is right before it
[07:45] <zyga> add the complete list
[07:45] <zyga> maybe next time we
[07:45] <zyga> maybe next time we'll know more
[07:46]  * zyga -> breakfast
[07:54] <pstolowski> done, https://bugs.launchpad.net/snapd/+bug/1876053
[07:54] <mup> Bug #1876053: occasional spread test failure on core-persistent-journal <snapd:Confirmed> <https://launchpad.net/bugs/1876053>
[07:54] <zyga> thanks!
[07:55] <zyga> one day we'll learn and understand :)
[07:56] <pstolowski> in the initial version of this code i was restarting journal service which had an undesired effect of restarting snapd during configure hook, but now it's misterious as there is no direct interaction with systemd, just removing/creating journal dir
[07:59] <zyga> do you know why restarting journal restarts snapd?
[07:59] <zyga> is it just snapd that is being restarted in that case?
[08:09] <pstolowski> dunno
[08:11] <zyga> pstolowski: hmm, perhaps we can do a small experiment with a simple service and see what happens
[08:11] <zyga> maybe it's documented
[08:11] <zyga> I think we ought to know, feels wrong to ship this to devices with potential for failure
[08:11] <zyga> offtopic: https://thepihut.com/products/raspberry-pi-high-quality-camera-lens !!! :)
[08:12] <zyga> i'm so getting this
[08:12] <zyga> and setting up a monitoring with a pi :)
[08:12] <zyga> and botland has it
[08:12] <zyga> https://botland.com.pl/pl/szukaj?controller=search&orderby=position&orderway=desc&search_query=Nowa+kamera+do+Raspberry+Pi&submit_search=
[08:20] <mborzecki> morning
[08:23] <zyga> mborzecki: hey
[08:35] <mvo> pstolowski: when you have a couple of minutes, could you please double check trello doing? just making sure it's a bit more up-to-date
[08:35] <pstolowski> mvo: sure
[08:36] <mvo> pstolowski: fwiw, the current trello has a bit too many lanes, this will get cleaned in the following days, so don't worry if it's a bit crowded :)
[09:12] <zyga> I need reviews for https://github.com/snapcore/snapd/pull/7825
[09:12] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[09:12] <zyga> it's super close and I'd love to land it this week
[09:20] <mborzecki> zyga: can yuo remind me whether the session-tool stops the session after the command exits?
[09:21] <zyga> no, because --prepare enables linger and --restore disables linger
[09:21] <zyga> what are you seeing?
[09:22] <mborzecki> so `session-tool -u test --restore` will kill the session then in restore right?
[09:22] <zyga> yes
[09:29] <zyga> it would be good to focus on making master less red
[09:29] <zyga> something broke in debian-sid now, we cannot compile our golang+C tests
[09:29] <zyga> would be worth taking a look,
[09:29] <zyga> I can in ~3-4 hours
[09:29] <zyga> but perhaps someone can fix it faster
[09:30] <mborzecki> zyga: got log?
[09:30] <zyga> mborzecki: plenty, check any of my latest PRs
[09:30] <zyga> mborzecki: asm/geneeric.h is missing or something like that
[09:30] <zyga> mborzecki: it fails each time
[09:30] <zyga> mborzecki: on tests/unit/go
[09:30] <mborzecki> master seems to be green
[09:30] <zyga> mborzecki: nope, it's red red red here :)
[09:30] <zyga> mborzecki: or did it magically go away just as it showed up?
[09:31] <mborzecki> zyga: https://github.com/snapcore/snapd/commits/master looks green
[09:31] <zyga> mborzecki: try debian-sid-64:tests/unit/go
[09:31] <zyga> the tick is confusing
[09:31] <zyga> it's just travis
[09:31] <mborzecki> w8, what's that tick?
[09:31] <zyga> we don't run spread there
[09:31] <mborzecki> pfff
[09:31] <mborzecki> yeah
[09:31] <zyga> yeah
[09:32] <mborzecki> omg
[09:32] <zyga> ?
[09:32] <mborzecki> so, the gh actions only runs on PRs
[09:32] <zyga> yes
[09:32] <zyga> we configured that deliberately
[09:32] <mborzecki> ok, so we do not run spread on master then
[09:32] <zyga> otherwise everything costs x2 more
[09:32] <zyga> we said we should extend that to run on all landings to release branches
[09:33] <zyga> as we land things regularly it's a reasonable tradeoff
[09:33] <mup> PR snapd#8583 opened: tests: add debug to core-persistent-journal test <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
[09:33] <mborzecki> 2020-04-29T17:55:01.8596162Z + su -l -c 'XDG_RUNTIME_DIR="/run/user/12345" DBUS_SESSION_BUS_ADDRESS="" test-snapd-desktop.cmd xdg-open http://www.example.org' test
[09:33] <mborzecki> 2020-04-29T17:55:01.8596782Z user-open error: exec: "dbus-launch": executable file not found in $PATH
[09:33] <mborzecki> heh, on sid
[09:33] <zyga> mborzecki: I really want to burn user.sh and the hacks with fire
[09:33] <zyga> all those XDGD_RUNTIME_DIR=... things are so bogus
[09:33] <zyga> mborzecki: I have a patch that moves one more tests over
[09:34] <zyga> maybe I can remove all of them today
[09:34] <zyga> I'm stuck on "serious" reviews anway
[09:34] <mborzecki> ok, let me see what i can do about that snap-seccomp unit test failing on sid
[09:34] <zyga> thanks!
[09:34] <zyga> one by one
[09:34] <zyga> and we can ask mvo to merge despite other failures
[09:34] <zyga> I'd love to end the week with totally green master
[09:34] <zyga> so that next week is not like a torture :/
[09:38] <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/8580 ? or even try it out if you have zsh installed
[09:39] <mup> PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>
[09:39] <zyga> mborzecki: sure
[09:39] <mborzecki> just dropping _snap file into /usr/share/zsh/vendor-completions/ should do the trick
[09:39] <mborzecki> or site-functions on other non deb distros
[09:40] <mborzecki> now that it works locally i see i've been missing out on some goodies :P
[09:42] <mborzecki> btw the zsh documentation is awful
[09:42] <zyga>   that doesn't seem to work
[09:44] <zyga> I installed that on my system
[09:44] <zyga> invoked zsh
[09:44] <zyga> and nothing
[09:44] <zyga> in comparison other completers work ok
[09:46] <zyga> reviewed
[09:46] <mborzecki> hmmm
[09:47] <zyga> also packaging seems to be broken
[09:47] <zyga> (check the various error logs)
[09:50] <mborzecki> heh, forgot to list the file for opensuse
[09:51] <zyga> check the suse error
[09:52] <zyga> it says something is listed twice
[09:52] <zyga> maybe a drive-by
[09:53] <mborzecki> zyga: https://asciinema.org/a/wXGEu1Ky2To2osTCJ8Wl1rD8b
[09:53] <zyga> weird
[09:53] <zyga> that's not what I'm seeing
[09:54] <zyga> I'll recheck
[09:54] <mborzecki> zyga: on ubuntu you need to move it to /usr/share/zsh/vendor-completins/_snap (with _)
[09:54] <zyga> that's where I put it
[09:55] <zyga> I naively tried to debug it by sourcing
[09:56] <zyga> fyke% source _snap
[09:56] <zyga> _setup:37: compstate: assignment to invalid subscript range
[09:56] <mborzecki> no, it won't work that way :)
[09:59] <zyga> I don't know how to debug it
[10:00] <mborzecki> zyga: that's on opensuse?
[10:00] <zyga> no, focal
[10:00] <zyga> weird, right
[10:01] <zyga> but I didn't set shell to zsh
[10:01] <zyga> just execed zsh
[10:01] <zyga> maybe that's why?
[10:02] <mborzecki> idk, maybe you need to enable completion? try `autoload -Uz compinit ; compinit` ?
[10:02] <zyga> it works for everything else in that directory
[10:02] <zyga> all the other commands generate completios
[10:02] <zyga> *completions
[10:03] <mborzecki> zyga: did you wget/curl the file or pasted it?
[10:03] <zyga> ...
[10:03] <zyga> pasted
[10:03] <zyga> is that relevant?
[10:03] <zyga> Omg :D
[10:04] <mborzecki> check whether the first line is `#compdef snap`
[10:04] <zyga> it is
[10:04] <mborzecki> idk, wget https://raw.githubusercontent.com/snapcore/snapd/060556f7adcf748546cd7c3c97f3254f0bd58644/data/completion/_snap ? :)
[10:05] <zyga> same result
[10:06] <mborzecki> pfff idk then
[10:06] <zyga> can you try?
[10:06] <mborzecki> you could try an wipe ~/.zshrc if you're not to used to it and start over
[10:06] <zyga> I mean, just spawn focal (multipass) and put that file
[10:07] <zyga> mborzecki: my zshrc is empty
[10:07] <mborzecki> zyga: that asciinema is on 20.04
[10:07] <zyga> mborzecki: yes but from spread
[10:07] <zyga> mborzecki: maybe there's a more magic button somewhere
[10:07] <mborzecki> ah, ok
[10:10] <mborzecki> zyga: yup, works
[10:10] <zyga> IDK
[10:10] <zyga> let's ship it then ;D
[10:11] <zyga> I tried setting the GO_... variable for completions and that does print stuff
[10:11] <zyga> did you exec zsh or did you do something more elaborate?
[10:11] <mborzecki> zyga: rm ~/.zshrc and run zsh again, that should suggest using the default config
[10:11] <zyga> tried
[10:12] <zyga> doesn't fix this issue :)
[10:12] <zyga> zyga@fyke ~ % snap inst
[10:12] <zyga> Completing `file' or `corrections'
[10:12] <zyga> I hit <tab> at inst<tab>
[10:14] <mborzecki> zyga: gcc-multilib isn't installed in sid images
[10:14] <mborzecki> zyga: that's why the unit test fails
[10:14] <zyga> cool, ping me for a patch
[10:16] <mborzecki> btw. i don't understand why test/unit build and install the snapd package
[10:17] <zyga> mborzecki: weird
[10:17] <zyga> probably for no reason at all?
[10:17] <mborzecki> that's a huge waste of time
[10:17] <zyga> I also wonder where we waste time
[10:17] <zyga> run 10 tests on a single machine
[10:17] <zyga> with -repeat 10
[10:17] <zyga> that does "true"
[10:17] <mborzecki> also, building the package runs unit tests /o\
[10:17] <zyga> it's incredibly slow
[10:17] <zyga> we are probably wasting loads of time doing something silly somewhere
[10:20] <mborzecki> uff, at least we pass nocheck to deb-bp
[10:20] <mborzecki> dpkg-buildpackage
[10:39] <mup> PR core#113 opened: Makefile: conditionally use the "edge" PPA in live-build <Created by mvo5> <https://github.com/snapcore/core/pull/113>
[10:47] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/8584
[10:48] <mup> PR #8584: packaging/debian-sid: add gcc-multilib to build deps <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8584>
[10:48] <mup> PR snapd#8584 opened: packaging/debian-sid: add gcc-multilib to build deps <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8584>
[10:48] <zyga> mborzecki: are we running tests on debian?
[10:48] <zyga> as in, unit tests while building the debian sid package?
[10:54] <mborzecki> zyga: it was the one that failed in this test
[10:54] <pstolowski> #8537 needs 2nd review
[10:54] <mup> PR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>
[10:54] <mborzecki> pstolowski: trying to review that since morning
[10:55] <mborzecki> zyga: there's only a bunch of systems we don't run unit tests on: [-ubuntu-core-*, -fedora-*, -opensuse-*, -arch-*, -amazon-*, -centos-*]
[10:55] <zyga> mborzecki: my question was different, we had a missing dependency, how come it didn't come up when building snapd in a pristine environment of a buidd?
[10:55] <zyga> mborzecki: are we running unit tests on package build on debian?
[10:56] <mborzecki> zyga: perhaps gcc-multilib is one of base dependencies already included?
[10:57] <mborzecki> zyga: which test runs buildd? i don't see one
[10:57] <zyga> mborzecki: perhaps :)
[10:57] <zyga> mborzecki: I mean "make check" style
[10:57] <zyga> go test ./...
[10:57] <mup> PR snapd#8585 opened: release: 2.44.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8585>
[10:59] <mborzecki> zyga: prepare sets nocheck in DEB_BUILD_OPTIONS, there's a nightly test that runs sbuild, but nobody looks at the result?
[10:59] <zyga> heh
[10:59] <zyga> ok
[10:59] <zyga> thanks for fixing htis
[10:59] <zyga> *this
[11:01] <mborzecki> zyga: where are the nightly test results?
[11:01] <zyga> replied to https://github.com/snapcore/snapd/pull/8581
[11:01] <mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
[11:01] <zyga> I have no idea
[11:01] <zyga> probably nowhere
[11:01] <zyga> just read the travis runs
[11:01] <mborzecki> cachio probably knows
[11:08] <mborzecki> zyga: so mvo pointed me to where the nightly tests are and as suspected sbuild test was failing, but even before it reached the package build step /o\
[11:09] <zyga> heh
[11:09] <zyga> where are the results?
[11:18]  * pstolowski lunch + errand
[11:19] <mborzecki> zyga: https://travis-ci.org/github/snapcore/spread-cron/branches and look for nightly
[11:19] <zyga> mmm
[11:19] <zyga> thanks
[11:20] <mborzecki> hm, we don't install sbuild and then run sbuild in the test
[11:20] <mborzecki> perhaps sbuild is no longer in the sid image?
[11:20] <zyga> IIRC we did but perhaps we stopped
[11:20] <zyga> for efficiency?
[11:22] <mborzecki> idk, let me check that test
[11:22] <mborzecki> hm sbuild is installed, wth?
[11:28] <doko> next chromium issue: https://bugs.launchpad.net/snapd/+bug/1876083
[11:28] <mup> Bug #1876083: chromium snap from focal fails DNS lookups, or delays them <snapd:New> <https://launchpad.net/bugs/1876083>
[11:32] <zyga> doko: in your report you said "that is using IPv6 only" - what do you mean by that?
[11:33] <mborzecki> hm idk, looks like sbuild-createchroot is broken
[11:33] <doko> zyga: my provider is doing IPv6 by default
[11:33] <zyga> I see
[11:33] <zyga> doko: what are the consequences of that, that you don't have an ipv4 address? that you cannot resolve ipv4 domains?
[11:34] <doko> no, I have an ipv4 address
[11:37] <zyga> mborzecki: we should nuke fedora 28, 29
[11:37] <zyga> and perhaps 30
[11:37] <zyga> and just have 31 and 32
[11:37] <mborzecki> 30 is eol in a mongth?
[11:37] <zyga> I will look after I wrap up this task
[11:37] <zyga> mborzecki: yeah, they go very quickly
[11:37] <zyga> the nature of fedora community is to move on
[11:37] <mborzecki> zyga: fwiw, the examples in sbuild-createchroot manpage don't work either, pfff
[11:37] <zyga> mborzecki: haha
[11:37] <zyga> I was in that same boat
[11:38] <zyga> mborzecki: with my recent debian maintainer hat
[11:38] <zyga> mborzecki: the wiki is broken
[11:38] <zyga> mborzecki: but also all of the tools behave different if they detect debian vs ubuntu
[11:38] <zyga> which is enormously confusing
[11:39] <mborzecki> eh, a wall of perl code :*
[11:39] <mborzecki> :(
[11:39] <zyga> heh
[11:39] <zyga> if that helps I have a magic line that gives you a working cowbuilder
[11:39] <zyga> it's really really great
[11:39] <zyga> and I use it for git-buildpackage
[11:39] <zyga> but most of the documentation is broken
[11:40] <zyga> and there is some overlap between those tools that doesn't help
[11:40] <zyga> btw, I need to thank stgraber and the team
[11:40] <zyga> lxd is really amazing
[11:40] <zyga> it's revolutionized how I think about systems
[11:40] <zyga> and the container registry is fantastic
[11:41] <zyga> I would love to have a vagrant-like tool for lxd
[11:41] <zyga> that bridges a project directory to the container ootb
[11:56] <cachio> zyga, hey
[11:56] <zyga> hey
[11:56] <cachio> I was trying to merge the no recommends branch
[11:56] <cachio> zyga, but I see these errors https://paste.ubuntu.com/p/BhXjghQ6Nh/
[11:56] <cachio> https://paste.ubuntu.com/p/hNRPxH7n6D/
[11:56] <cachio> both in the same test
[11:57] <cachio> zyga, I already tried with other dependencies
[11:57] <cachio> any idea what could be the cause?
[11:57] <zyga> lack of /lib/systemd/user/dbus.socket
[11:58] <zyga> I rewrote this test (though I haven't pushed it as I'm working on a prerequisite)
[11:58] <zyga> is that the only failure?
[11:58] <cachio> zyga, yes
[11:58] <zyga> do you have a debug shell?
[11:59] <cachio> no, let me create it
[11:59] <zyga> is dbus-user-session installed?
[11:59] <cachio> no
[11:59] <cachio> but it pass in other systems where it is not installed
[12:00] <zyga> ah, I missed that there are two test failures
[12:00] <cachio> zyga, yes, different
[12:00] <zyga> dbus-launch is a separate problem
[12:00] <zyga> the tests are really written in a way that won't work
[12:00] <zyga> I'm working on porting them over
[12:01] <cachio> zyga, I can disable it for those systems
[12:02] <cachio> and then we fix it
[12:02] <cachio> zyga, does it make sense?
[12:02] <zyga> can you add a comment like "TODO:session-tool: port and re-enable"
[12:02] <zyga> yeah
[12:02] <zyga> cachio: do you know if we are using different instances by any chance?
[12:02] <zyga> we've noticed that tests are much slower today
[12:03] <cachio> zyga, no
[12:03] <cachio> same
[12:04] <zyga> ok
[12:05] <cachio> zyga, I'll check
[12:05] <zyga> mborzecki: ^^ what do you think about the comments to disable the two tests sergio mentioned
[12:05] <zyga> cachio: today I'm going through failing tests and porting to session-tool, to unbreak from random annoying failures
[12:05] <zyga> so at some point I'll go through all the user.sh users and make them more robust
[12:06] <cachio> yes
[12:07] <cachio> zyga, it caused several issues already
[12:10] <cachio> zyga, pushed the change nad added the comment in both tests disabled
[12:11] <zyga> thanks
[12:11] <cachio> just disabled the failinf systems
[12:11] <cachio> not the test
[12:11] <zyga> do you need a review for the test changes?
[12:11] <zyga> cachio: uh, that's a bit heavy, I think we should not disable debian-sid
[12:11] <cachio> it is already  apporoved
[12:11] <zyga> 19.10 is a different story and I would not mind dropping it TBH
[12:11] <zyga> cachio: oh? where is it?
[12:12] <cachio> zyga #8468
[12:12] <mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
[12:13] <zyga> cachio: ah, ok,
[12:13] <zyga> I misunderstood what you said
[12:13] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8468#pullrequestreview-403460795
[12:14] <mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
[12:34] <mborzecki> zyga: yay, Chipaca is presenting ;)
[12:35] <zyga> watching :)
[12:35] <mborzecki> zyga: thanks for spotting, i left a comment there
[12:35] <zyga> cool!
[12:37] <doko> jdstrand: thanks, but now I'm facing LP: #1876083
[12:37] <mup> Bug #1876083: chromium snap from focal fails DNS lookups, or delays them <snapd:New> <https://launchpad.net/bugs/1876083>
[12:37] <doko> oops, wrong channel
[12:40] <mborzecki> mvo: can we merge https://github.com/snapcore/snapd/pull/8584 ? we'll need another PR for the xdg-desktop-portal test
[12:40] <mup> PR #8584: packaging/debian-sid: add gcc-multilib to build deps <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8584>
[12:40] <mborzecki> (needs your superpowers)
[12:43] <mvo> sure
[12:43] <mvo> ta
[12:43] <mup> PR snapd#8584 closed: packaging/debian-sid: add gcc-multilib to build deps <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8584>
[12:43] <mborzecki> mvo: thank you!
[13:46] <zyga> small improvement to session-tool, will replace some hand-crafted checks elsewhere: https://github.com/snapcore/snapd/pull/8586
[13:46] <mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
[13:46] <mup> PR snapd#8585 closed: release: 2.44.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8585>
[13:46] <mup> PR snapd#8586 opened: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
[13:46] <zyga> currently a draft, running one more pass of the full set, will open shortly
[13:47] <mborzecki> google:debian-sid-64:tests/main/xdg-open-portal fails in a weird way
[13:47] <mborzecki> user-open error: exec: "dbus-launch": executable file not found in $PATH
[13:49] <zyga> mborzecki: yeah, we looked at this
[13:49] <zyga> mborzecki: cachio disabled this test, it's on my list to port next
[13:49] <mborzecki> zyga: i replaced some bits with session tool, but i tlooks like the user dbus is not started
[13:49] <zyga> yeah, I know
[13:49] <zyga> my test actually shows that :)
[13:49] <mborzecki> i'm probably doing something wrong here
[13:50] <zyga> dbus-session-bus is not preinstalled
[13:55] <zyga> presumably --no-install-recommends
[13:55] <cachio> cmatsuoka, using new snapd still getting stuck https://paste.ubuntu.com/p/gScx3yH59y/
[13:55] <cachio> cmatsuoka, line 1353
[13:55] <cachio> is the last I see
[13:56] <cmatsuoka> let me see...
[13:56] <cachio> thanks
[13:57] <cmatsuoka> cachio: this is happening in graham's image as well
[13:57] <cachio> cmatsuoka, ahh
[13:58] <cmatsuoka> cachio: did you inject snap-bootstrap into the initramfs?
[13:58] <cachio> cmatsuoka, yes
[13:58] <cmatsuoka> I'm investigating here to see what could be happening
[13:59] <mborzecki> zyga: ok, fixed the portal-open test, but other portal tests need fixing too now
[13:59] <cachio> cmatsuoka, I am running repack_snapd_snap_with_deb_content_and_run_mode_firstboot_tweaks
[13:59] <zyga> mborzecki: ok
[13:59] <cachio> for the image
[14:02] <cmatsuoka> mborzecki: I moved the TPM-related stuff from initramfs-mounts to secboot in PR #8577, could you have a look when you have time? It's trying to not expose TPM to initramfs-mounts so it could work later with a TrustZone-based solution as well
[14:02] <mup> PR #8577: [RFC] secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8577>
[14:09] <mborzecki> cmatsuoka: sure
[14:09] <mborzecki> zyga: i think i've ported the portal tests now
[14:09] <zyga> mborzecki: to session-tool? :-)
[14:09] <mborzecki> yeah
[14:09] <zyga> \o/
[14:09] <zyga> awesome
[14:09] <zyga> push that!
[14:09] <zyga> I'm looking at the user-env test
[14:10] <zyga> I mean, I ported it but I'm adding some more bits before that can be proposed
[14:10] <zyga> I have a working branch that removes user.sh
[14:10] <zyga> and just fixes stuff that breaks
[14:10] <zyga> mborzecki: did you port all of the portal tests?
[14:11] <mborzecki> zyga: xdg-open-portal and desktop-portal-{filechooser,screenshot,open-file,open-uri}
[14:11] <zyga> awesome
[14:12] <zyga> ijohnson: I pushed to https://github.com/snapcore/snapd/pull/8586 and opened it normally now
[14:13] <mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
[14:13] <zyga> ijohnson: I made a small change to move the test to a new task
[14:13] <zyga> ijohnson: and I highlighted that https://github.com/snapcore/snapd/pull/8586/files#diff-e14795fd89d2bab1c7f6486851d463c0R15 sid has no session support somehow
[14:13] <zyga> this test is nice because it will show us changes in the distros
[14:13] <mborzecki> cmatsuoka: i think you added some standup notes under friday (tomorrow)
[14:13] <ijohnson> that's awesome very nice
[14:13] <zyga> I was thinking to move tumbleweed, sid and arch to unstable
[14:14] <ijohnson> is arch unstable ?
[14:14] <zyga> so that they reflect the unstable nature of the distributions they are
[14:14] <ijohnson> arch seems to be relatively stable for us recently I think
[14:14] <ijohnson> maybe I'm wrong though
[14:14] <zyga> so that we can get a heads up in case it affects the rest of the stack over time
[14:14] <zyga> ijohnson: yeah, it's relatively stable
[14:14] <zyga> but the point is not the measure our feeling about snapd in that distribution
[14:14] <zyga> but to measure the stability of the distribution - in the sense of debian stable
[14:14] <zyga> not sure if this makes sense to you
[14:15] <zyga> since those distributions move rapidly they can change like the wind at a seaside town :)
[14:15] <mup> PR core18#152 opened: Make .disk/info visible on the root partition <Created by sil2100> <https://github.com/snapcore/core18/pull/152>
[14:15] <cmatsuoka> mborzecki: I'm starting my annotations for the next day after the current SU to be in sync with people that have SU at the end of the day
[14:16] <cmatsuoka> (so the activities between SUs can be reviewed in the next SU)
[14:20] <zyga> ijohnson: one more small improvement, https://github.com/snapcore/snapd/pull/8587
[14:20] <mup> PR #8587: tests: session-tool allows preparing/restoring for many users <Created by zyga> <https://github.com/snapcore/snapd/pull/8587>
[14:20] <zyga> this will be used by changed user-env test
[14:20] <mup> PR snapd#8587 opened: tests: session-tool allows preparing/restoring for many users <Created by zyga> <https://github.com/snapcore/snapd/pull/8587>
[14:20] <zyga> that has test and test-zsh users
[14:25] <mup> PR snapd#8588 opened: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
[14:25] <mborzecki> zyga: ^^
[14:25] <zyga> looking
[14:26] <zyga> mborzecki: the pkg change is tricky, I would rather depend on it in snapd
[14:26] <zyga> mborzecki: otherwise we are testing something and users are running something else
[14:26] <zyga> mborzecki: wdyt?
[14:26] <mborzecki> zyga: suggests/reccomends?
[14:26] <zyga> yeah
[14:26] <zyga> suggests seems ok
[14:26] <zyga> or recommends
[14:26] <zyga> though we no-install-recommends
[14:26] <zyga> heh :)
[14:26] <zyga> not sure
[14:26] <mborzecki> aren't we suggsting/recommending portals already?
[14:26] <zyga> just don't want to let it slip like that
[14:27] <zyga> if we do we should bundle dbus in the same set
[14:27] <mborzecki> i would expect that to pull in relevant dbus packages
[14:27] <om26er> popey ping! I believe this will need your "blessings" https://forum.snapcraft.io/t/auto-connection-request-for-easy-installer/17063
[14:27] <zyga> the portal teardown should happen beore --restore
[14:27] <zyga> inside the portals you can probably remove loads of redudancy as well
[14:27] <popey> om26er bless you
[14:27] <zyga> it still calls start_user_session
[14:27] <zyga> and uses as_user
[14:28] <zyga> mborzecki: ^ review here :)
[14:28] <cmatsuoka> degville, cachio: something changed between gadget 96 and 98 that's causing the problem
[14:28] <mborzecki> zyga: portals teardown removes files and so on, it should probably be done after we know that session is stopped
[14:29] <zyga> mborzecki: look closer
[14:29] <zyga> it does more
[14:29] <zyga> purge_user_session-data
[14:29] <zyga> and stop_user_session
[14:29] <zyga> I think those two must go
[14:29] <degville> cmatsuoka: ah, thanks for the update.
[14:29] <cmatsuoka> degville: I'll diff them to see what changed
[14:30] <ijohnson> cmatsuoka: could it be https://github.com/snapcore/pc-amd64-gadget/pull/45 ?
[14:30] <mup> PR pc-amd64-gadget#45: Use UC20 signed grub <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/45>
[14:30] <popey> om26er I'll take a look
[14:31] <cmatsuoka> ijohnson: it looks very suspicious
[14:31] <zyga> mborzecki: reviewed but it's the same as I said here
[14:31] <ijohnson> cmatsuoka: indeed
[14:31] <om26er> popey thanks. I am in touch with the upstream, I was asked to help with snap packaging. After quite a few iterations we came to the point of pushing it to store.
[14:31] <zyga> mborzecki: thank you so much for pushing this :)
[14:33] <mborzecki> zyga: hmm not sure which portal helpers, there's only 2 of those, and they no longer start or stop session
[14:33] <cachio> cmatsuoka, ahhh
[14:33]  * zyga looks
[14:34] <cmatsuoka> ijohnson: this looks suspicious too:
[14:34] <zyga> mborzecki: doh!
[14:34] <zyga> I'm blind
[14:34] <zyga> this is so weird
[14:34] <cmatsuoka> -    - shim-signed=1.41+15+1552672080.a4a1fbe-0ubuntu1
[14:34] <cmatsuoka> -    - shim=15+1552672080.a4a1fbe-0ubuntu1
[14:34] <cmatsuoka> +    - shim-signed=1.40.3+15+1533136590.3beb971-0ubuntu1
[14:34] <cmatsuoka> +    - shim=15+1533136590.3beb971-0ubuntu1
[14:34] <zyga> I didn't see this file before :)
[14:34] <cachio> cmatsuoka, I'll try in that case by using the pc snap from stable
[14:34] <ijohnson> cmatsuoka: so the version of shim was reverted to an older one?
[14:34] <zyga> mborzecki: +1
[14:35] <popey> om26er it's a really nice looking app!
[14:35] <cmatsuoka> ijohnson: it seems so, and if this older one is the one without chris coulson's patches, it would fail like that
[14:35] <zyga> mborzecki: can you remove . user.sh in desktop-portal.sh?
[14:36] <ijohnson> cmatsuoka: yeah makes sense probably needs a comment from Dmitri
[14:38] <cmatsuoka> ijohnson: I pinged him about that
[14:39] <ijohnson> ack
[14:43] <cmatsuoka> degville, cachio: bad shim in recent gadgets, dimitri is fixing it
[14:43] <zyga> mborzecki: superb
[14:43] <zyga> mborzecki: we will have much fewer users of user.sh
[14:44] <cachio> cmatsuoka, awesome
[14:44] <degville> cmatsuoka: thank you!
[14:44] <cachio> cmatsuoka, the fun part is that I tried with older snapd snap, pckernel snap and core20 snap
[14:44] <cachio> cmatsuoka, but didnt try with older pc snap
[14:46] <cmatsuoka> when unlock fails, the prime suspects are the command line and shim, and they're both from gadget
[14:46] <zyga> mborzecki: once your branch lands this will be fixed, right?
[14:46] <zyga> https://github.com/snapcore/snapd/pull/8586/files#diff-e14795fd89d2bab1c7f6486851d463c0R19
[14:46] <mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
[14:46] <zyga> debian-sid-*/test exception will disappear
[14:53] <pstolowski> how do i restart github actions if they seem to be stuck? https://github.com/snapcore/snapd/pull/8583
[14:53] <mup> PR #8583: tests: add debug to core-persistent-journal test <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
[14:57] <zyga> pstolowski: looking
[14:57] <zyga> close and reopen
[14:57] <zyga> I saw that once before
[14:57] <zyga> seems like event got lost
[14:57] <pstolowski> mhm
[14:57] <pstolowski> ok,thanks
[14:57] <zyga> queued :)
[14:58] <zyga> and in progress
[14:59] <zyga> I'll break now
[14:59] <zyga> back hurts
[15:00] <pstolowski> magic
[15:00] <zyga> magic? :)
[15:00] <zyga> could you ask mvo to merge the two session-tool improvements once they are green enough
[15:00] <zyga> I have more follow ups that this enables
[15:10] <zyga> mborzecki: I approved https://github.com/snapcore/snapd/pull/8580#pullrequestreview-403616086
[15:10] <mup> PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>
[15:10] <zyga> but there's a conflict now
[15:12] <zyga> mborzecki: maybe move pkgver next to pgkname
[15:12] <zyga> so that it conflicts less frequently
[15:17] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/8576#pullrequestreview-403618621
[15:17] <mup> PR #8576: tests/main/lxd: add test for snaps inside nested lxd containers not working <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8576>
[15:18] <pstolowski> anyone up for #8583? needs 2nd review, it's a simple test change
[15:18] <mup> PR #8583: tests: add debug to core-persistent-journal test <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
[15:19] <zyga> pstolowski: perhaps just ask mvo, master is broken now so you will nedd an override anyway
[15:20] <morphis> zyga, mvo: have you guys seen any problems with snapd in lxd with focal images? running into https://pastebin.canonical.com/p/SkdNKHCyNy/
[15:20] <morphis> snapd seems to fail to initialize the system
[15:21] <zyga> morphis: can you do snap tasks 1 or [345]
[15:21] <zyga> I don't think we've seen this
[15:21] <morphis> https://pastebin.canonical.com/p/fwChrpCB49/
[15:21] <morphis> didn't knew `snap tasks` gives you that level of details
[15:22] <morphis> this is a LXD container with: https://pastebin.canonical.com/p/fQJHJq5R6t/
[15:22] <morphis> which works fine for bionic
[15:23] <zyga> morphis: so the preinstall hook fails
[15:23] <zyga> hmmm
[15:23] <zyga> er, install hook
[15:23] <zyga> 2020-04-30T14:58:46Z ERROR run hook "install": cannot perform operation: mount --rbind /var/lib/dhcp /tmp/snap.rootfs_hzQTBP//var/lib/dhcp: Permission denied
[15:23] <zyga> oh
[15:23] <zyga> that's new!
[15:23] <zyga> this is surprising
[15:23] <zyga> morphis: do you have denials?
[15:23] <zyga> on the host container
[15:23] <zyga> container host
[15:24] <zyga> jdstrand: ^ remember this?
[15:24] <zyga> I wonder if there's a regression that the lxd profile doesn't allow snapd to perform this
[15:25] <morphis> zyga: let me check
[15:25] <zyga> morphis: does it go away if you rmdir /var/lib/dhcp in the machine that you "snap install lxd" on?
[15:25] <zyga> we won't try it then
[15:25] <morphis> zyga: https://pastebin.canonical.com/p/NHKWyxpwQj/
[15:26] <morphis> let me check
[15:26] <zyga> [ 1113.914649] audit: type=1400 audit(1588259357.291:359): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_de7sTW/var/lib/dhcp/" pid=61879 comm="snap-confine" srcname="/var/lib/dhcp/" flags="rw, rbind"
[15:26] <morphis> that looks like it
[15:26] <jdstrand> what's up with locking /dev/null?
[15:26] <morphis> but the container has lxc.apparmor.profile=unconfined so I wouldn't expect that
[15:26] <zyga> hmmm
[15:26] <zyga> is that supported for snapd?
[15:27] <zyga> I'm never sure what the various lxd configuration options do
[15:27] <zyga> and which disable nested apparmor
[15:27] <zyga> jdstrand: maybe libc?
[15:27] <morphis> we have a lxd-profile.yaml in our lxd charm which adjusts the container config, k8s does the same AFAIK
[15:28] <morphis> https://github.com/charmed-kubernetes/charm-kubernetes-master/blob/master/lxd-profile.yaml
[15:28] <jdstrand> I've never seen that before
[15:28] <zyga> we have this rule:
[15:28] <zyga>     mount options=(rw rbind) /var/lib/dhcp/ -> /tmp/snap.rootfs_*/var/lib/dhcp/,
[15:28] <zyga>     mount options=(rw rslave) -> /tmp/snap.rootfs_*/var/lib/dhcp/,
[15:28] <zyga> which should cover the dhcp directory you had
[15:28] <zyga> I wonder what's wrong there
[15:29] <zyga> morphis: can you file a bug with repro instructions,
[15:29] <jdstrand> I'm going into a meeting, but if you set lxc.apparmor.profile=unconfined, I'm not sure the profile stacking is going to work correctly
[15:29] <morphis> zyga: rmdir /var/lib/dhcp doesn't seem to help
[15:29] <jdstrand> that is a stgraber question
[15:29] <morphis> now it runs into: 2020-04-30T15:28:45Z ERROR run hook "install": cannot open file /sys/fs/cgroup/freezer/snap.lxd/cgroup.procs: Permission denied
[15:29] <zyga> morphis: it's late today and I wanted to focus on some more bits but I will try to look either later today or on Monday (I'm off tomorrow)
[15:29] <morphis> zyga: sounds good!
[15:29] <zyga> morphis: I'm suspecting this is an unsupported config, please make sure to loop in stgraber
[15:29] <morphis> jdstrand: will check with him later
[15:30] <jdstrand> this is because the policy is shared between the host and the container I think
[15:30] <zyga> and we should document this somehow
[15:30] <jdstrand> because there is no stacking
[15:30] <zyga> yeah, I think jamie is spot on
[15:30] <jdstrand> yikes
[15:30]  * jdstrand -> meeting
[15:30] <morphis> just wondering as this worked well for bionic
[15:31] <jdstrand> yeah, I forget otoh the details of how lxd sets up the profile stacking
[15:31] <jdstrand> but this sounds like what I described
[15:31] <zyga> morphis: some incorrect configurations do seem to work
[15:31] <zyga> morphis: but not by design
[15:31] <zyga> and it depends heavily by what is on the container
[15:32] <pstolowski> zyga: what's broken in master now?
[15:33] <zyga> pstolowski: a few tests
[15:33] <zyga> pstolowski: but those are all with PRs now I think
[15:33] <zyga> pstolowski: your branch will likely fail on them
[15:35] <zyga> pstolowski: watch https://github.com/snapcore/snapd/pull/8588 :)
[15:35] <mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
[15:35] <zyga> maybe it will be green
[15:35] <zyga> then we can just work normally again
[15:36] <pstolowski> great
[15:36] <pstolowski> ty
[15:36] <cachio> cmatsuoka, I used the pc 93 and I see the same problem
[15:44] <morphis> zyga, jdstrand: dropping "lxc.apparmor.profile=unconfined" fixes it
[15:47] <zyga> great :)
[15:49] <zyga> mvo: could you please override/merge https://github.com/snapcore/snapd/pull/8586
[15:49] <mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
[15:49] <zyga> it's +2 and it fails on a known debian-sid failure maciek has fixed in a separate branch
[15:49] <zyga> thanks!
[15:50] <mup> PR snapd#8586 closed: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8586>
[15:50] <zyga> mborzecki: can you merge master into https://github.com/snapcore/snapd/pull/8588 and remove the debian-sid-*/test exception from tests/main/session-tool-support
[15:50] <mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
[15:51] <zyga> mborzecki: or I'll just open a follow-up as soon as this lands
[15:51] <zyga> opensuse has fails on degraded systemd unit
[15:51] <zyga> I had a look and it both looks familiar
[15:51] <zyga> and weird
[15:51] <zyga> not sure if we can just disable that service?
[15:51] <zyga> it's something related to tty, let me check...
[15:54] <cmatsuoka> cachio: 96 should work
[15:56] <cachio> cmatsuoka, it is not published anymore right?
[15:57] <cmatsuoka> cachio: no, the current one is 98
[16:01] <mup> PR snapd#8589 opened: tests: port user-session-env to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8589>
[16:02] <zyga> ijohnson: I opened one more https://github.com/snapcore/snapd/pull/8589 <- I'm somewhat worried about 14.04 test coverage thourh, not sure if this is something I should bring back with a separate test that just tests "env"
[16:02] <mup> PR #8589: tests: port user-session-env to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8589>
[16:03] <zyga> ijohnson: actually, the realization that 14.04's systemd build is *not* connected to dbus was my biggest worry/surprise recently
[16:03] <zyga> ijohnson: I don't think we really had this internalized before
[16:03] <jdstrand> morphis: glad to hear
[16:03] <zyga> mborzecki: I think we have only one user of user.sh left
[16:04] <zyga> once that is gone I will update the PR from jamesh
[16:04] <zyga> jamesh: ^ if you are reading backlogs, we are working on removing user.sh hacks
[16:04] <zyga> jamesh: but we don't want to leave you on ice
[16:05] <stgraber> morphis: lxc.apparmor.profile=unconfined will break apparmor, don't do that
[16:05] <stgraber> morphis: and that would indeed cause breakage for the snap
[16:05] <morphis> yeah, makes sense
[16:06] <morphis> something we should fix at https://github.com/charmed-kubernetes/charm-kubernetes-master/blob/master/lxd-profile.yaml#L5 as well unless they use it different
[16:09] <zyga> morphis: imperfect but interesting https://github.com/search?l=&q=lxc.apparmor.profile%3Dunconfined+language%3AYAML&type=Code
[16:09] <zyga> jdstrand: ^ all the unconfined lxds
[16:12] <zyga> stgraber: do you know if there's a way for snapd to detect that it's running in lxd and that lxc.apparmor.profile=unconfined has been set?
[16:29] <stgraber> zyga: it's doable, yeah
[16:31] <mborzecki> zyga: updated #8588
[16:31] <mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
[16:32] <zyga> looking
[16:32] <mborzecki> and feel a bit dizzy, just traversed through QDesktopServices down to xdgDesktopPortalOpenFile() and omg
[16:33] <zyga> mborzecki: I think you need to drop the sid fragment now
[16:33] <zyga> mborzecki: because your PR adds the dbus-user-session package to sid
[16:33] <zyga> and that will be detected by tests/main/session-tool-support
[16:33] <zyga> mborzecki: what did you find?
[16:36] <stgraber> zyga: if /sys/kernel/security/apparmor/.ns_level doesn't exist or is < 1 + /proc/self/attr/current is unconfined
[16:36] <mborzecki> zyga: i think there's a bug in the portal handler, https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI states that calling that with file:// fails (by design), while the QDesktopServices::openURL() calls that for file://
[16:36] <stgraber> zyga: that should indicate lxc.apparmor.profile=unconfined I think
[16:36] <zyga> stgraber: I'll try that, thanks!
[16:36] <zyga> hmm
[16:36] <zyga> mborzecki: is there any remapping done?
[16:36] <zyga> I didn't check though, perhaps that's a question to jamesh/kenvandine
[16:37] <zyga> mborzecki: we could also ask flatpak developers
[16:37] <mborzecki> zyga: and there's an unhappy user in the forum
[16:37] <mborzecki> zyga: i mean that's the spec, and the portal works according to the spec
[16:37] <zyga> mmmm
[16:38] <mborzecki> zyga: suggested the user to drop file:// from the url, which triggers the path that calls OpenFile()
[16:38] <zyga> mborzecki: ah, I thought the bug is in the app itself
[16:38] <zyga> and it seems you say that the problem is with the usage pattern
[16:38] <mborzecki> but i can understand his frustration, even if he files a bug, and it gets fixed, it's probably not goiung to see the fix for the next 6 months or so
[16:39] <zyga>  /snap/test-snapd-desktop/x1/bin/cmd: 4: exec: sh -c 'echo hello world': not found
[16:39] <zyga> mborzecki: we could fix it in qt
[16:39] <zyga> is the app using a shared qt runtime?
[16:40] <mborzecki> zyga: i could even submit a patch if i got qt building locally and signed cla, but that's like a over-the-weekend recreational activity ;)
[16:41] <zyga> I think the desktop team can help with that
[16:51] <mborzecki> hmm otoh, that app is in qt, i see a segfault starting it on arch
[17:01] <mup> PR snapd#8468 closed: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
[17:04] <zyga> cachio: \o/
[17:05] <zyga> cachio, mborzecki: make sure there's a follow-up for https://github.com/snapcore/snapd/pull/8468#discussion_r417975489 please
[17:05] <mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
[17:05] <zyga> cachio: thank you for pushing this forward :)
[17:07] <cachio> zyga, yaw
[17:07] <zyga> :)
[17:08]  * cachio lunch
[17:08] <cjp256> hello, anyone by chance have thoughts on https://travis-ci.org/github/snapcore/snapcraft/jobs/681562924#L432 ?  this is the first time i've seen snap report that LXD is already installed, but `lxd` not found...
[17:09] <cjp256> fwiw, it happened on the 20.04 image
[17:09] <zyga> cjp256: probably $PATH
[17:09] <zyga> can you debug with echo $PATH
[17:09] <zyga> or you can work around with "snap run ..."
[17:13] <cjp256> zyga: there's a bunch of other tests that ran fine alongside it.   Appears random.  I'll restart it and see if it repros, then I'll print PATH.
[17:13] <zyga> cjp256: you can debug it with things like echo $PATH, snap list, find /snap/bin
[17:14] <cjp256> will do, thanks
[17:15] <zyga> type=AVC msg=audit(04/30/20 17:13:46.842:526) : avc:  denied  { write open } for  pid=27614 comm=systemd-logind path=/var/lib/systemd/linger/test dev="sda1" ino=417790 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file permissive=1
[17:15] <zyga> but I think that's actually my fault
[17:15] <zyga> :)
[17:15] <zyga> fixing now
[18:08] <mup> PR snapd#8590 opened: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
[18:21] <mup> PR snapcraft#3100 opened: Removed ``key`` from ``progressive`` dict following changes in the server API <Created by nessita> <https://github.com/snapcore/snapcraft/pull/3100>
[19:06] <mup> PR snapcraft#3098 closed: build providers: bootstrap with dirmngr <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3098>
[19:14] <zyga> ijohnson: you may want to have a 2nd look at https://github.com/snapcore/snapd/pull/8590
[19:14] <mup> PR #8590: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
[19:14] <zyga> I added one more bugfix for session-tool on selinxu
[19:14] <zyga> *selinux
[19:14] <zyga> namely this: https://github.com/snapcore/snapd/pull/8590/files#diff-a8fce2de6a6829d98f798117050b6c93R287
[19:15]  * ijohnson should probably stop reviewing things that are drafts
[19:15] <zyga> haha
[19:15] <zyga> I'm very grateful that you did
[19:15] <zyga> makes fixing those annoying failures gratifying :)
[19:16] <ijohnson> do non selinux systems just ignore The SELinuxContext in the dbus call to StartTansientUnit ?
[19:16] <ijohnson> zyga: ^
[19:16] <zyga> yeah
[19:16] <ijohnson> cool
[19:16] <zyga> session-tool is this little thing that turns out to be a big sprawling mess
[19:16] <zyga> but I think it's better than what we had before :)
[19:18] <ijohnson> it's at least more uniformly a big sprawling mess
[19:18] <ijohnson> and when it's used everywhere it makes it easier for everything to be closer to the right thing
[19:20] <zyga> hopefully very close to having that
[19:20] <zyga> I need to update incoming branches that use user.sh as well
[19:21] <zyga> there's one heavy use in user session services branch
[19:24] <zyga>  I hope we can land all the test fixes
[19:24] <zyga> we have 73 PRs
[19:24] <zyga> but a good chunk of those are recent fixes
[19:27] <zyga> I pushed a small patch to https://github.com/snapcore/snapd/pull/8588 to reflect a new test in master
[19:27] <mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
[19:28] <zyga> I think I'll EOD now
[19:29] <zyga> it's almost 21:30 here
[19:29] <zyga> mvo: are you going to be around tomorrow?
[19:39] <mvo> zyga: yes
[19:39] <zyga> ok
[19:57] <cachio> cmatsuoka, https://paste.ubuntu.com/p/hxnGhxdH7F/
[19:57] <cachio> works well with the pc 96
[19:57] <cmatsuoka> \o/
[20:13] <cachio> so, I need to wait for the new gadget


[10:54] <xubuntu21w> hello, anyone else getting high memory usage on idle using the latest LTS?
[17:18] <AO-> .2
[17:19] <AO-> hi, I'm trying to seutp xfce4 desktop and I can't seem to startx successfully
[17:19] <AO-> it keeps saying "xinit: connection to X server lost"
[17:21] <AO-> I get 2 odd warnings: "NVIDIA(0): Unable to get display device for DPI calculation" and "NVIDIA(0): Option PrimaryGPU is not used"
[17:27] <GridCube> why are you setting up xfce4 for your self?
[17:27] <GridCube> xubuntu comes with xfce set up by itself
[17:27] <GridCube> you don't have to do anything
[17:28] <AO-> yea, I was trying to setup proper nvidia-driver
[17:28] <AO-> i may have fudged up everything
[17:36] <GridCube> mmm, i see, AO- you can reset your video drivers https://askubuntu.com/questions/159663/how-to-reset-the-xorg-xserver
[17:47] <AO-> oh, did I mention, I have no UI lol
[17:47] <GridCube> yes, you can just do that from a terminal
[17:56] <AO-> I opened it
[17:56] <AO-> tried doing that
[17:56] <AO-> didn't work
[17:56] <AO-> also, I found the .xsession-errors file
[17:57] <AO-> it's a lot of GTK_WARNING and GTK_CRITICAL messages, the message being mostly * failed to launch/create
[17:57] <AO-> then there's an interesting line about ICE and IO
[17:58] <AO-> i believe that is tied to a missing .ICEauthority file..
[18:07] <GridCube> AO-: delete .Xauthority and .ICEauthority files and try to restart?
[18:08] <GridCube> but that would only be if you already have an X session running that they would affect anything (as they are tied to your user session)
[18:08] <AO-> I do not
[18:08] <AO-> xsession doesn't start, or I don't know how to start it.. :sweat_smile:
[18:09] <GridCube> startx?
[18:09] <AO-> nope, that ain't working
[18:09] <GridCube> try reinstalling xubuntu-core?
[18:09] <AO-> recently tried that.. broke .Xauthority hard.. had to rebuild it
[18:09] <AO-> I don't think I have an xubuntu-core
[18:09] <GridCube> sudo apt install xubuntu-core --reinstall
[18:10] <GridCube> or xubuntu-desktop
[18:10] <GridCube> any would do
[18:10] <GridCube> -core should pull less stuff if you already have most of it
[18:23] <AO-> nope, doesn't work
[18:28] <GridCube> AO-: you can just remove the xorg.conf file from /etc/X11
[18:28] <GridCube> or try to re run nvidia-setting to create a new xorg.conf file
[18:28] <AO-> so, after that, startx still fails
[18:29] <AO-> okay
[18:29] <AO-> how-to?
[18:29] <GridCube> you shouldn't even try to run startx
[18:31] <GridCube> AO-: https://ubuntuforums.org/showthread.php?t=2352893
[21:47] <muchacho> hi
[21:48] <muchacho> How can i make the previews bigger when cycling ?
[21:48] <muchacho> when i use alt-tab ?


 I was meant to have a 2 hour nap and had 3.5 hours instead! lol
[08:36] <Kilos> morning kbmonkey Squirm
[08:37] <Kilos> hi space
[08:37] <space> Hello Kilos.
[08:43] <kbmonkey> hoe ganit Kilos ?
[08:44] <Kilos> fine ty and there
[08:45] <kbmonkey> lekker man
[08:46] <kbmonkey> I'm pretty hungry, gona have a soup and an orange I recon
[08:46] <Kilos> hehe
[08:52] <kbmonkey> the firemen across the road are doing some demonstration
[08:57] <Kilos> look and learn
[08:57] <Kilos> or most likely you can learn more with google
[09:13] <Squirm> hello all
[09:30] <Kilos> hi Vince-0 Squirm
[09:37] <Vince-0> heyo
[09:37] <Vince-0> wonderlike Sonday
[09:50] <Kilos> hi Dreen Xethron
[09:50] <Dreen> yo!
[10:41] <Squirm> our womans water polo is terrible
[10:42] <Kilos> teach them
[10:42] <Squirm> 7-0 near the beginning of the first chukka
[10:42] <Kilos> eish
[10:42] <Squirm> now it's 8-0 at the beginning of the 3rd chukka
[10:42] <Kilos> can they swim
[10:42] <Squirm> still 7 min to go and then the whole 8min of the last
[10:43] <Squirm> the one girl playing is my sisters KZN water polo coach :/
[10:43] <Kilos> ouch
[10:43] <Squirm> and KZN came 4th last year(90% of their team was 17 years old though), this year it may be better
[10:43] <Kilos> who are they playing
[10:43] <Squirm> China
[10:43] <Squirm> CHINA
[10:43] <Squirm> :/
[10:44] <Kilos> whew
[10:46] <Squirm> 10-0, still 4 min to go in the 3rd chukka
[10:47] <Squirm> aaaaargh
[10:47] <Kilos> china's national team?
[10:51] <Squirm> yeah
[10:51] <Squirm> China vs RSA
[10:51] <Kilos> well thats ok then, maybe our national team will do better
[10:52] <Kilos> oh my
[10:52] <Kilos> i thought it was your school team
[11:28] <Squirm> it's terrible
[11:28] <Squirm> 17-2 to China
[11:28] <Kilos> ouch
[11:28] <Cantide> ?
[11:29] <Squirm> Cantide: Womans Waterpolo world champs
[11:29] <Squirm> RSA vs China
[11:29] <Cantide> oh 'o'
[11:29] <Cantide> sounds like something nice to watch :)
[11:30] <Squirm> SA losing 17-2? Not very nice to watch :/
[11:30] <Squirm> was a terrible game
[11:30] <Cantide> well, other than the score :p
[11:30] <Squirm> SuperSport 5
[11:30] <Squirm> now it's USA vs Greece
[11:31] <Cantide> I've not got DSTV
[11:32] <Squirm> good
[11:32] <Squirm> it's terrible :/
[11:34] <Squirm> Cantide: if you are interested, seems like this link would work http://livemanager.eurovision.edgesuite.net/fina/site/index.html
[11:34] <Squirm> nevermind - that's hilights
[11:35] <Squirm> s/hilights/highlights
[11:35] <Cantide> it's okay
[11:35] <Cantide> i'm a little busy now >.<
[11:35] <Cantide> but thanks :)
[11:37] <Kilos> whew
[11:37] <Kilos> Due to a security breach Ubuntu Forums is down.
[11:38] <Squirm> lol
[11:38] <Cantide> yeah
[11:38] <Cantide> that tux with an AK is super cute though :)
[11:41] <Cantide> also
[11:41] <Cantide> "you dun goofed" makes me laugh :)
[15:20] <superfly> that is not a bad thing...
[15:20] <superfly> yet another case of Ubuntu using non-free software, and suffering for it.
[15:20] <superfly> (not that phpbb is much better :-( but Vanilla is good)
[15:50] <not_found> alo ZA-land
[15:59] <superfly> hi not_found
[15:59] <not_found> how are you superfly?
[15:59] <superfly> tired thanks, and you?
[16:00] <not_found> @work and bored... the usual I guess :p
[16:02] <superfly> hehe
[16:10] <Kilos> hi superfly not_found
[16:12] <not_found> uncle Kilos, alo :0
[16:15] <superfly> hi oom Kilos
[16:18] <Kilos> inetpro, ?
[16:19] <inetpro> hello oom Kilos
[16:19] <inetpro> oh and hi everyone else
[16:19] <Kilos> naand boetie nog n plan
[16:19] <inetpro> nog 'n plan?
[16:19] <Kilos> if you cant find that kinda tool here you can try
[16:20] <inetpro> Kilos: het vandag met iemand gesels wat sê ek behoort maklik so 'n ding in die hande te kry
[16:20] <Kilos> either find a piece of pipe that goes in there firmly and glue it in place
[16:20] <Kilos> or have one turned for you
[16:21] <Kilos> o ok
[16:21] <inetpro> maar daai klink ook nie na 'n slegte plan nie
[16:21] <not_found> o/ inetpro
[16:40] <Kilos> hi Cantide
[16:40] <Cantide> hello '-'/
[16:40] <Kilos> or wb
[16:41] <Cantide> tomorrow morning i'm off to PTA :)
[16:41] <Cantide> yeah, more like wb :)
[16:41] <Cantide> thanks
[16:49] <Kilos> hmm... inetpro
[16:51] <Kilos> you can also glue another seal on the ridge with silicon and put tap together and turn it closed till it just touches and leave for silicon to set lekker
[16:51] <Kilos> or a strip of black car tube
[17:08] <Kilos> hi smile4ever
[17:08] <smile4ever> hi Kilos :D
[17:22] <Kilos> yo Squirm
[17:23] <Squirm> hello
[17:23] <Squirm> A few more clips up on my channel. They're all unedited, etc. But this week I'll have access to a GoPro, going to attach it to quadcopter and will upload some decent videos
[18:38] <smile4ever> Good night! :)
[18:38] <not_found> bai
[20:05] <Kilos> night all you late night peeps
[20:05] <Kilos> sleep tight
[20:05] <Kilos> just watched battleship
[20:05] <Kilos> lekker movie


[12:30] <LocutusOfBorg> hello, looks like s390x is busy cleaning again, and with 4 thunderbird instances running... we have none free slots
[12:31] <LocutusOfBorg> maybe also ppc64el might need a stick?
[12:36] <cjwatson> resetting
[12:36] <cjwatson> though there's likely some deeper problem
[12:41] <LocutusOfBorg> thanks^2
[15:03] <Laney> Does archive.copyPackage respect the architecture whitelist? I was trying to use copy-package to resurrect libemail-address-xs-perl/i386 1.04-1build2 as a (probably new) lintian dep but it's not offered as a copy candidate. Or maybe I'm just using it wrong... anyway, a little bit of assistance would be appreciated
[15:23] <cjwatson> Laney: Is it just that copy-package doesn't show the i386 binary?
[15:23] <Laney> cjwatson: yes, which made me think it wouldn't be copied
[15:23] <Laney> is that lies?
[15:23] <cjwatson> copy-package guesses a bit
[15:24] <Laney> oho
[15:24] <Laney> I'll just try it then
[15:27] <cjwatson> IIRC it does respect the arch filter
[15:43] <Laney> yeah nothing doing https://launchpad.net/ubuntu/groovy/i386/libemail-address-xs-perl
[16:14] <Laney> (done)
[16:19] <cjwatson> Right, that page above probably only comes into existence once the build is done or similar
[16:19] <cjwatson> Oh, or the publication in this case since it's arch-all


[04:43] <DanaG> Say, any new news on getting dkms for powervr?
[04:43] <DanaG> Beagleboard, specifically.
[04:45] <rcn-ee> one of the linaro kernel guys pinged me about it last week.. (his dvi display wasn't working) but he has some questions on my sgx module patches..
[04:46] <DanaG> It really sucks that TI is so uptight about their graphics... they should take an example from nvidia, of all people.
[04:46] <DanaG> It's also confusing... for an Ubuntu beagleboard, do I need psp-sdk?
[04:47] <DanaG> oh yeah, and thanks for the new setup script -- setup_sdcard.sh
[04:48] <DanaG> Though, one improvement: it needs to "inhibit" automount as gparted does, or sometimes you get "Can't reread partition table".
[04:48] <rcn-ee> umm.. TI can't do anything about it..  By licenseing the core from imgtek (first mistake), TI has some rights, but imgtek makes the rules..
[04:48] <DanaG> Or TI should at least make the build script not phail.
[04:48] <DanaG> And even when inhibited, the error still sometimes happens.
[04:49] <rcn-ee> do you know anyway to in inhibit, other then going into gconf and turning it off?
[04:49] <DanaG> It's probably a dbus call.
[04:50] <DanaG> or udisks --inhibit
[04:53] <rcn-ee> interesting, i'll give that a try tomorrow.. hopefully in time for the 10.04.1 image, thanks DanaG
[04:54] <DanaG> ah, and when I tried to deploy btrfs, I got lack of fsck.btrfs.
[04:56] <rcn-ee> yeap, i've seen that too... i even added btrfs-tools to the default roostock image, thinking that would help, but no.. (even alpha-3)
[04:56] <DanaG> Argh, stupid wireshark...
[04:57] <DanaG> I try to type "usb0" in capture interface box, I get:
[04:57] <DanaG> ub0s
[04:57] <DanaG> And wlan0 is ub0s
[04:57] <DanaG> er
[04:57] <DanaG> wan0l
[04:57] <DanaG> And eth0 is eh0t
[04:58] <DanaG> Note: I think the udisks call to inhibit runs only as long as the udisks command is running.
[04:58] <DanaG> So, you may have to background it, then kill %something later.
[04:59] <rcn-ee> yeap, that's the way it looks in the man page..
[05:03] <rcn-ee> DanaG, what's weird, the package btrfs-tools contains 'fsck.btrfs' http://packages.ubuntu.com/lucid/i386/btrfs-tools/filelist kinda weird it isn't found at boot..
[05:03] <DanaG> It must not end up in the initramfs, then?
[05:04] <DanaG> ARGH, stupid EEM.
[05:04] <DanaG> I see packets of type 0xbc59 from ff:ff:d6:e3:b3:a0
[05:04] <DanaG> that's not a valid MAC address!
[05:08] <DanaG> argh, and TI's mirrors are dog-slow...
[05:08] <DanaG> 160 KB/sec on a connection that can do 500-600.
[06:00] <DanaG> Wait, maybe it's wifi fail, or Charter fail.
[07:58] <cooloney> does anyone still meet this issue with Maverick on Beagle?
[07:58] <cooloney> [    2.557128] mmc0: error -110 whilst initialising SD card
[08:00] <amitk> cooloney: known bug that mathieu is working on
[08:02] <lag> cooloney: Are you hitting it?
[08:03] <rsalveti> cooloney: I guess this was fixed with latest update
[08:04] <lag> cooloney: rsalveti: amitk: bug 591941
[08:04] <ubot2> Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 70)" [High,In progress] https://launchpad.net/bugs/591941
[08:04] <cooloney> amitk: yeah, i guess so
[08:04] <cooloney> lag: i just hit that
[08:04] <cooloney> rsalveti: i tried latest maverick kernel in our tree
[08:05] <amitk> rsalveti: lag: I don't consider that revert a 'fix'. It is a workaround at best :)
[08:05] <lag> Mathieu and Robert are working on it
[08:06] <rsalveti> yeah, true, they are still working on it
[08:06] <cooloney> ok, understood, thanks, bros
[08:06] <lag> amitk: Agreed, hence the present tense of my previous statement :)
[08:06] <cooloney> i just wanna test the kexec things on maverick
[08:06] <amitk> :)
[08:06] <rsalveti> the bug that got fixed is the mtd one
[08:07] <lag> cooloney: Either do this:
[08:07] <lag> CONFIG_SND_TIMER=m
[08:07] <lag> CONFIG_SND_PCM=m
[08:07] <lag> # CONFIG_SND_SOC is not set
[08:07] <lag> or turn off CONFIG_PREEMPT
[08:08] <rsalveti> well, time to get some sleep
[08:09] <cooloney> rsalveti: good night
[08:10] <cooloney> lag: so that's config patch from Mathieu?
[08:11] <lag> cooloney: ?
[08:13] <cooloney> lag: i saw some discussion about the CPU_IDLE in the LP thread
[08:13] <cooloney> but failed to find the CONFIG_SND_PCM stuff
[08:14] <lag> cooloney: Ignore CPU_IDLE
[08:14] <lag> I just turn off CONFIG_PREEMPT
[08:14] <lag> cooloney: Wait one
[08:15] <cooloney> lag: ah, i saw that, rcn-ee posted in his message
[08:15] <cooloney> lag: ok, let me disable PREEMPT
[08:15] <lag> cooloney: Do you know where it is?
[08:16] <lag> Kernel Features -> Preemption Model
[08:16] <lag> Change it from Desktop to Server
[08:17] <lag> cooloney: Do you have a working kernel uImage that USB is proven to work with?
[08:17] <lag> cooloney: In fact the .deb would be more helpful
[08:19] <cooloney> lag: oh, haven't try USB much this time
[08:19] <lag> Would you mind?
[08:20] <amitk> lag: could you try low-latency desktop for the pre-empt model. I noticed that Nokia ship with that enabled so their driver is tested in that environment
[08:20] <cooloney> lag: need i test it on omap4 panda or omap3 beagle?
[08:21] <lag> amitk: I've just looked, and that's what we have enabled at the moment - when did that happen?
[08:21] <amitk> lag: I did ask Mathieu to try that out in response to his patch on the list
[08:22] <lag> cooloney: 4
[08:22] <amitk> so that doesn't work either?
[08:22] <lag> amitk: I haven't tried
[08:22] <amitk> ok
[08:22]  * amitk is off to meet Tony
[08:22] <lag> amitk: I'll do so now though (neither of my boards work properly, so I may as well)
[08:23] <lag> amitk: Say hi from me :)
[08:23] <amitk> sure
[08:26] <cooloney> lag: will test it later.
[09:33] <lag> Hey npitre
[09:34] <GrueMaster> Hey lag.
[09:34] <lag> MOrning GrueMaster
[09:34] <lag> How's Oxford?
[09:34] <GrueMaster> Same as Oregon, just older.
[09:35] <lag> GrueMaster: I was there over the weekend Saturday was a bit drizzly, but Sunday was really nice
[09:35] <GrueMaster> You should have stopped by.  I got here Saturday.
[09:36] <lag> GrueMaster: I was at a festival - I was in no state to be meeting colleagues :)
[09:37] <lag> GrueMaster: I should mention that it was a Cider Festival :)
[09:37] <GrueMaster> More the reason to find me.
[09:37] <lag> GrueMaster: :)
[09:38] <lag> So, what can I do you for?
[09:38] <GrueMaster> Nothing really.  Just saying hey.
[09:38] <lag> GrueMaster: Ah, good morning
[09:38] <lag> GrueMaster: What's the plan for today?
[09:38] <GrueMaster> Did you say you needed to test something on panda?
[09:39] <lag> No, I need a replacement
[09:39] <GrueMaster> I'm in the CoP QA meeting, but also have my omap hw.
[09:40] <GrueMaster> But I would need an email from David before I could leave you with my es1.
[09:40] <lag> GrueMaster: Well if you have some spare cycles, feel free to test this: http://people.canonical.com/~ljones/usb-stopped-panda/
[09:40] <lag> The USB on my Panda has stopped working
[09:40] <lag> I think it's hardware
[09:40] <GrueMaster> ok, I'll pull it now and try it later this morning.
[09:41] <lag> Excellent, thanks
[09:42] <GrueMaster> Did you try rebooting with Alpha 3 image?
[09:44] <lag> I've tried Alpha 3, yes
[09:45] <GrueMaster> I hope this isn't another hardware killer patch from the kernel team.
[09:47] <lag> GrueMaster: It's more likely to be a userland issue
[09:48] <lag> =:-p
[09:48] <GrueMaster> ogra: Have you noticed the reason for the image build failures? It appears that we are hanging on unity missing a package that exists in a ppa (from what I could find).
[09:49] <GrueMaster> lag: PLBKAC
[09:49] <ogra> GrueMaster, have you noticed that tonights images have built ? :)
[09:50] <GrueMaster> No, missed that.  Last email Ihad said fail.  Will pull immediately (but I believe oem-config is still bad).
[09:50] <ogra> the package was stuck in universe, pitti fixed that yesterday
[09:50] <GrueMaster> ah.
[09:50]  * ogra is just done with pulling, gunzipping already
[09:50] <lag> GrueMaster: DYJMTUY?
[09:51] <GrueMaster> ?
[09:51] <lag> My sentiments exactly
[09:51] <lag> Did You Just Make That Up Yourself?
[09:52] <GrueMaster> Problem Lies Between Keyboard and Chair.
[09:53] <lag> PLBKACPU
[10:04] <GrueMaster> SD I/O is slowwwww.
[10:10] <ogra> NCommander, could you put http://qa.ubuntu.com/reports/team-assigned/canonical-mobile-assigned-bug-tasks.html on the meeting agenda ?
[10:10] <ogra> (as a standing item)
[10:13] <NCommander> ogra: can you add it yourself? my internet connection is really crappy, and the wiki VERY slow
[10:16] <NCommander> ogra: what's the usual window manager when UNE 2D is runnign?
[10:16] <ogra> metacity
[10:16] <NCommander> ogra: and what draws the bar at the top?
[10:16] <ogra> with maximus attached
[10:16] <NCommander> (and what starts metacity)
[10:17] <NCommander> hrm
[10:17] <ogra> thats gnome-panel
[10:17] <ogra> gnome-session starts metacity
[10:17] <NCommander> ogra: seems I have an issue with gnome-session then :-/
[10:17] <GrueMaster> NCommander: panda is still updating.  Hopefully done soon.
[10:17] <NCommander> ogra: what tells gnome-session then to start UNE or normal GNOME? env variable?
[10:18] <ogra> gconf
[10:18]  * DanaG still wants texture_from_pixmap on ARM... =/
[10:18] <ogra> well, gdm actually
[10:18] <ogra> gconf defines whats running in the session
[10:18] <DanaG> And I wish that "panda" weren't so impossible to find online.
[10:18] <ogra> DanaG, they are not sold yet
[10:18] <NCommander> ogra: ok, that makes sense. I'm trying to trace why I'm having a launcher failure
[10:19] <ogra> NCommander, which session do you try ?
[10:19] <NCommander> ogra: both UNE and UNE 2D
[10:19] <ogra> UNE will just hang hard
[10:19] <NCommander> I get netbook-launcher-efl to pop up, but nothing else
[10:19] <ogra> dont try that
[10:19] <NCommander> UNE starts 2D
[10:19] <ogra> it doesnt
[10:19] <DanaG> I don't even mean to buy... I just mean to find pictures!
[10:19] <ogra> if it does thats a bug you should talk to the desktop team about
[10:19] <DanaG> Unless it's under NDA. :(
[10:21] <ogra> GrueMaster, no change with oem-config in todays image :(
[10:21] <DanaG> Literally all I can find for "omap4 panda" are the kernel patches for "add support for omap4 panda".
[10:21] <GrueMaster> fail.
[10:22] <ogra> i'm out of debugging ides :/
[10:22] <ogra> *ideas
[10:23] <NCommander> ogra: on what?
[10:23] <DanaG> Say, if I were to take the GL ES apps source from the TI SDK, could I use it with the Mesa GL ES?
[10:26] <ogra> NCommander, for the oem-config issues
[10:26] <GrueMaster> ogra: I'll see if I can tweak with it a bit this week.
[10:26] <NCommander> ogra: ouch. I can confirm however that using the normal UNE session and not UNE 2D still causes the 2D launcher to stop
[10:27] <NCommander> ogra: can you please poke the casper bug for me?
[10:27] <ogra> NCommander, if the papaerwork on the bug is done :)
[10:27] <ogra> (remember i asked you about an additional task)
[10:28] <NCommander> ogra: bah, I thought you were going to add that :-P
[10:28] <ogra> right, thats the reason why i asked you :P
[10:29] <NCommander> ogra: ok, so starting the 2D launcher causes gnome panel to startup in desktop configuration, and not "normally" for UNE 2D
[10:29] <NCommander> ogra: and the 3D session starts the 2D session san panel
[10:29] <ogra> yes, thats a known bug
[10:29] <NCommander> W.T.F.
[10:29] <ogra> the 3D session shouldnt start a launcher at all
[10:29] <ogra> only the two unity panels
[10:29] <NCommander> ogra: is the 2D session known to be broken?
[10:29] <ogra> but they wont start up if you dont have proper GL support
[10:30] <NCommander> I don't think it should be showing a normal gnome-panel
 ogra: ok, so starting the 2D launcher causes gnome panel to startup in desktop configuration, and not "normally" for UNE 2D
 yes, thats a known bug
[10:30] <DanaG> argh, stupid PowerVR... not only are their drivers closed-source... even their freaking demos are closed-source.
[10:30]  * NCommander hits his head
[10:30] <NCommander> ogra: so what's the fix :-)?
[10:30] <DanaG> So you can't compile any GL ES stuff for non-PowerVR stuff.
[10:30] <ogra> NCommander, oem-config needs to work again so i can move on :P
[10:30] <DanaG> Or at least, there's no GL ES glxgears!
[10:31] <DanaG> Anyway, off to bed I go nowz.
[10:31] <ogra> NCommander, we have a -settings package but no settings in it yet
[10:31] <NCommander> ogra: but this worked in lucid!
[10:31] <ogra> to set these up i need a working session
[10:31] <ogra> GNOME changed a lot
[10:31] <NCommander> .oO(we should have used KNE)
[10:31]  * NCommander ducks
[10:31] <ogra> and the setting package we shared with the 3D launcher is gone
[10:32] <ogra> because of unity
[10:32] <NCommander> ogra: paperwork done :-P
[10:32] <ogra> thanks
[10:32] <ogra> i'll upload before the meeting
[10:35]  * GrueMaster votes +1 for KNE
[10:55] <ogra> hmm
[10:55] <ogra> seems /var/lib/dbus/machine-id exists and is wrong on the images
[10:56] <ogra> so dbus doesnt start and it tears down oem-config with it
[10:56]  * ogra tries to prove that theory now
[10:56]  * GrueMaster is still waiting for Alpha 3 -> current updates to finish.
[11:04] <NCommander> ogra: I'll look at ubuntu-netbook-2d-settings sometime this week if you want, since I need to ASAP for Marvell :-/
[11:04] <ogra> i'll do it as soon as i can get a working session
[11:04] <NCommander> ogra: fair enough
[11:04] <ogra> its not that it blocks anything from working
[11:05]  * NCommander must admit he feels exhausted today
[11:05]  * ogra guesses you will enjoy the team call this week :P
[11:06] <ogra> hmm, so there is no such dbus file in the plain images
[11:06] <ogra> i wonder why dbus doesnt start then
[11:07] <GrueMaster> Did you compare with A3?
[11:08] <NCommander> ogra: maybe it missed its bus to work
[11:08]  * NCommander runs
[11:09] <ogra_cmpc> haha
[11:09] <ogra_cmpc> GrueMaster, no, nothing to compare here
[11:33] <lag> ogra_cmpc: bug 605488
[11:33] <ubot2> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 1) (heat: 132)" [High,In progress] https://launchpad.net/bugs/605488
[11:33] <lag> ogra: How big should the swap file be?
[11:36] <lag> GrueMaster: ?
[11:38] <GrueMaster> sawp file?
[11:38] <GrueMaster> swap
[11:39] <GrueMaster> I think swap is currently turned off.
[11:39] <lag> ogra said this bug only appears when swap is on
[11:39] <GrueMaster> Oh, that one.  Make a swap file == ram size.
[11:40] <lag> k
[11:40] <lag> Well ...
[11:40] <lag> Only 256MB works
[11:40] <lag> Shall I use that?
[11:40] <GrueMaster> I guess.
[11:40] <lag> Or the actual 512MB
[11:40] <lag> k
[11:40] <GrueMaster> Panda?
[11:40] <lag> Beagle
[11:41] <lag> bs?
[11:42] <GrueMaster> so, you are checking an omap4 bug on an omap3 system?
[11:43] <lag> GrueMaster: So it is!
[11:43] <lag> Actually - I'm not
[11:43] <lag> I am on Panda
[11:44] <lag> (things get confusing when you're working on both boards at the same time)
[11:44] <GrueMaster> then my previous reply counts.
[11:44] <lag> (I am doing the correct thing) :)
[11:44] <lag> Which was?
[11:44] <lag> 512MB?
[11:44] <GrueMaster> yes
[11:44] <lag> np
[11:44] <lag> Thanks
[11:57] <lag> GrueMaster: How can I reproduce this bug?
[12:04] <ogra_cmpc> lag, just reboot, the messages about swapping should show up in dmesg
[12:06] <GrueMaster> yep.  Should see it as soon as the system mounts swap.
[12:14] <lag> ogra_cmpc: GrueMaster: Should I still be able to see it whilst using a rootstock rootfs?
[12:18] <GrueMaster> I don't know.
[12:19] <ogra_cmpc> since its a kernel message the rootfs shouldnt matter
[12:19] <lag> http://paste.ubuntu.com/479343/
[12:20] <ogra_cmpc> though it might only happen if the system actually uses swap
[12:20] <lag> Well here's what I do get
[12:20] <lag> ogra_cmpc: Should I write an application which uses lots of memory?
[12:33] <GrueMaster> Lanch une.
[12:33] <GrueMaster> launch
[12:40] <ogra_cmpc> lag, looks o so far, just start a desktop session and use firefox for a while or something
[12:41] <lag> ogra: I can't
[12:41] <lag> ogra: No USB
[13:58] <lag> GrueMaster: ping
[14:02] <GrueMaster> pong
[14:02]  * persia starts a meeting in #ubuntu-meeting
[14:36] <rsalveti> ogra: any change to sponsor me at bug 619026?
[14:36] <ubot2> Launchpad bug 619026 in pybootchartgui (Ubuntu) "pybootchartgui gives ZeroDivisionError when parsing the tgz file generated by a beagleboard (affects: 1) (heat: 8)" [Undecided,In progress] https://launchpad.net/bugs/619026
[14:36] <rsalveti> was testing ureadhead yesterday but found out that I couldn't generate the bootchart file on beagleboard
[14:37] <ogra> well, you can copy the tgz over to an x86 machine and generate the png there
[14:37] <rsalveti> and about ureadahead I'll just disable it if you run on systems with less than 512, doesn't change a thing at the bootchart
[14:37] <rsalveti> ogra: that's what I did
[14:37] <rsalveti> ogra: but the bug is inside pybootchartgui
[14:38] <rsalveti> it's not using the mmcblk device while generating the bootchart
[14:38] <ogra> ah, right
[14:38] <ogra> i'll sponsor it after the meeting
[14:41] <rsalveti> thanks
[14:55] <GrueMaster> ogra: /sys/devices/system/cpu/ showscpu0 & cpu1. Checking further.
[14:55] <GrueMaster> Kind of slow, still updating (from yesterday).
[14:55] <ogra> are you sure it just doesnt scroll off the screen or so ?
[14:56] <rsavoye> ogra: ever heard of the Sharp PC-Z1 NetWalker ?
[14:56] <GrueMaster> what scroll off the screen?  I have an HDMI monitor here.
[14:56] <GrueMaster> rsavoye: I think persia has one.
[14:56] <ogra> rsalveti, persia had one for a while
[14:56] <ogra> err
[14:57] <ogra> rsavoye, indeed
[14:57] <rsavoye> it ships with 9.04, I but I heard you can;t upgrade due to driver problems
[14:57] <persia> I used to have one, but I dropped it in the sink.  It's a lovely machine, and I am tempted to get another almost every week.
[14:57] <rsavoye> I just want something that's stable :-)
[14:57] <persia> A few folks have looked at the kernel patches, but untangling what needs to be applied to current kernels (some parts are upstream) seems yet to be resolved.
[14:58] <rsavoye> figures...
[14:58] <persia> There's no git tree available, so it's just a huge monolithic patch to dig through.
[14:59] <rsavoye> somebody said they were running 10.04 on one, but just never upgraded the kernel
[15:01] <GrueMaster> Interesting.  Jaunty was armV5  (iirc). Lucid+ is armV7.
[15:01] <rsavoye> 800Mhz sounds nice too
[15:02] <GrueMaster> ogra: On the panda,  /sys/devices/system/cpu/cpu[01]/online are both 1.  I assume this means they should be on.
[15:04] <persia> GrueMaster, It's i.mx51x, so it can do v7, but who knows how stable the userspace/kernel interface is in that configuration :)
[15:06] <persia> rsavoye, My critique of the netwalker is only that I don't like the keyboard that much (the 'a' key is in the wrong place, to my mind), and that the screen doesn't lay flat (or convert into tablet mode).  Beyond that, it's lovely (even running jaunty), and there is some upstream kernel support, so you might join the several folks trying to get newer kernels there.
[15:06] <GrueMaster> Yes, I know.  I was refering to the images.
[15:06] <rsavoye> persia: I have an old Sharp 3200, same teeny keyboard
[15:07] <persia> The way the super-special-sharp-installer for those works, one has to make a mess of the images anyway, which makes it less important.
[15:07] <GrueMaster> Does the raw Jaunty image work?
[15:07] <rsavoye> as much as I'd love to jump into the kernel patches, I need to finish my current ARM hacking first
[15:07] <persia> rsavoye, Not at all.  the SL-C3200 has a *much* better keyboard.
[15:07] <rsavoye> persia: oh no! Course I was considering using it as a build slave mostly
[15:07] <ogra> GrueMaster, nope, missing kernel patches
[15:07] <persia> (and is ergonomically better overall: pity that form-factor wasn't used in the more recent devices)
[15:08] <persia> Oh, as a buildd slave, just install pbuilder on top of the sharp remix, and have at it.  Nothing blocking there.  no need to fiddle the kernel.
[15:18] <GrueMaster> Hmm, interesting.  /proc/cpuinfo only shows one proc, but top shows both (one is barely awake).
[15:18] <GrueMaster> It does seem to be passing the load back & forth.
[15:20] <ogra_cmpc> thats how its supposed to work
[15:20] <ogra_cmpc> htop is better than top btw
[15:21] <GrueMaster> I just found it odd that /proc/cpuinfo only showed one proc.
[15:23] <ogra_cmpc> are you sure its not scrolled offscreen ?
[15:27] <GrueMaster> Is what scrolled of screen?
[15:29] <ogra_cmpc> the cpuinfo output
[15:30] <GrueMaster> It only fills a quarter of the screen.
[15:30] <GrueMaster> if that
[15:32] <GrueMaster> ok, now I see it.  Very weird.
[15:45] <lag> ogra: How are rootstock's commands compiled? (which toolchain)
[15:49] <prpplague> lag: a little elf writes down the list of commands and then spends straw into binary code
[15:49] <lag> prpplague: Okay, I'll cut to the chase
[15:50] <lag> prpplague: My cross-compiler is a little out of date and I need another
[15:50]  * prpplague isn't familiar with rootstock operations
[15:51] <prpplague> lag: i use OE and codesourcery for my cross-compilers
[15:52] <lag> prpplague: I'm trying to cross-compile a little program to use up lots of memory - but if I compile it dynamically I receive "file not found"
[15:53] <lag> prpplague: If I try it statically I receive "illegal instruction"
[15:53] <prpplague> lag: that sounds odd
[15:53] <prpplague> lag: mind if i give it a try?
[15:53] <lag> I have chopped it (all the way) down to a hello world - same result
[15:54] <lag> Do you want me to send you the binary?
[15:55] <prpplague> lag: sorry i ment try compliling the code
[15:56] <lag> prpplague: That's my point - it does the same for hello world
[15:56] <lag> It must be the compiler - the code is sound
[15:56] <prpplague> lag: what is command line you are using to cross-compile the source?
[15:57] <lag> arm-unknown-linux-gnu-gcc <-static> -o use-memory-arm use-memory.c
[15:58] <ogra_cmpc> lag, rootstock is a script
[15:58] <prpplague> lag: after you compile it, issue the command: file use-memory-arm
[15:59] <lag> Done that
[15:59] <prpplague> lag: that should give you some basic info about how the binary was compiled
[15:59] <lag> I did it already
[15:59] <prpplague> lag: all that info looks good?
[15:59] <lag> I have to go (meeting) will you be here in a bit?
[15:59] <lag> Yeah
[15:59] <prpplague> lag: yea all day
[15:59] <lag> Sort of
[16:09] <GrueMaster> ogra: upgrading from Alpha 3 to current seems to fail somewhere.  Just rebooted (finally), and it is locked up.  Will dive into, butthought you would want to know.
[16:10] <ogra> GrueMaster, awesome, then its not oem-configs fault as i suspected
[16:10] <GrueMaster> asac: I am having trouble getting to a point where I can test banshee for you.  Will let you know when I can get past these issues.
[16:11] <ogra> GrueMaster, just dont upgrade, apt-get install banshee on a plain A3
[16:11] <GrueMaster> ogra: X isn't even starting.
[16:11] <asac> GrueMaster: ok. let me know
[16:11] <ogra> it should only upgrade banshee related packages then
[16:11] <asac> thanks for the update
[16:11] <ogra> GrueMaster, try startx on a tty
[16:11] <ogra> see what it tells you
[16:12] <rsavoye> I wonder if I can debug thumb2 code on an i.mx51x...
[16:13] <GrueMaster> ogra: Total lockup.  need to modify kernel cmdline to get serial out first.  No prompt available.
[16:13] <ogra> wow
[16:14] <GrueMaster> Not even getting numlock or capslock.
[16:14] <ogra> thats ES1 ?
[16:14] <GrueMaster> yes.
[16:14] <ogra> smells like kernel
[16:15] <ogra> mount the boot partition, there are .bak files of kernel and initramfs
[16:15] <GrueMaster> No.  Had to reboot a couple times during the upgrade process (thought it had locked up)  New kernel came up fine.
[16:15] <ogra> copy them around so that you boot the .bak files
[16:16] <GrueMaster> I know the process, but I doubt it is the kernel.
[16:16] <ogra> well, do you see the same on an omap3 board ?
[16:17] <GrueMaster> I haven't had a chance to try this on omap3.  The time it takes is painful.
[16:24] <persia> rsavoye, Should be able to do so: the core supports it
[16:25] <rsavoye> cool, I've tempted to buy one so I can stop sharing a C4, which is insanely slow
[16:26] <rsavoye> persia: since you have one, is the keyboard worth it, or is the tablet one better ?
[16:26] <GrueMaster> ogra: old kernel locks.  Now trying with serial console.
[16:28] <persia> rsavoye, Depends on what you want to do with it.  The tablet one is uninteresting to me (I don't want only a tablet at that size/weight).  I complain about the keyboard, but I'm seriously considering getting another one.
[16:29] <rsavoye> for me it'd mostly be an ARM build slave, I don't like netbooks generally
[16:29] <rsavoye> the only other difference is the mmc size, but I could add a bigger one myself
[16:30] <persia> That would involve soldering :)
[16:31] <rsavoye> ouch. one has 4GB, the other 8GB
[16:32] <rsavoye> maybe an external USB drive...
[16:33] <prpplague> GrueMaster: i'd really like to see some info on how to get the ubuntu builds working with distcc or ice to improve native compiles
[16:34] <prpplague> GrueMaster: you guys got anyone working on that?
[16:34] <GrueMaster> The only one that did that I know of is NCommander, but he's probably out atm.
[16:35] <prpplague> GrueMaster: yea i asked, he only used ice once to do a couple of small compiles
[16:35] <persia> rsavoye, As a buildd slave, you *definitely* want an external drive, preferably rotary (otherwise you go through a heap of flash)
[16:35] <GrueMaster> You could always setup an NFS share.
[16:35] <rsavoye> USB2 drives are cheap these days, or I could just mount space off another machine
[16:36]  * prpplague has been experimenting with a fpga design that emulates nand flash but uses an external SATA drive
[16:36] <rsavoye> I use NFS on my XM board, which unfortunately is useless still for doing builds :-(
[16:36] <rsavoye> somehow I think I shouldn't hold my breath for the XM kernel fixes...
[16:36] <GrueMaster> I have a NFS share for builds and nfs-root, but not enough systems to try this with.
[16:37] <rsavoye> but it's impossible to run GDB on a C$ when somebody else is running linpack and whetstone tests...
[16:37] <GrueMaster> rsavoye: they should be out soon.
[16:37] <rsavoye> GrueMaster: this week ? :-)
[16:37] <rsavoye> I'm in a crunch for time unfortunately
[16:37] <GrueMaster> I don't know, I only test them.
[16:37] <rsavoye> I'
[16:37] <GrueMaster> Srry.
[16:37] <prpplague> GrueMaster: other fun items on my todo list, research multi-framebuffer support in ubuntu
[16:37] <rsavoye> l'll gladly test them too :-)
[16:38] <GrueMaster> prpplague: Same here (if someone will send me a blaze).
[16:38] <lag> prpplague: Hola
[16:38] <prpplague> GrueMaster: or panda
[16:38] <prpplague> lag: hey
[16:38] <lag> prpplague: Where were we?
[16:38] <GrueMaster> I only have one monitor per system.
[16:38] <prpplague> lag: you did a file command on the resulting binary
[16:38] <GrueMaster> And 5 in my office is getting tight.
[16:39] <prpplague> GrueMaster: hehe
[16:39] <lag> prpplague: Working: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
[16:39] <prpplague> oh that reminds, me i need to check on that HDMI switcher we ordered
[16:39] <lag> prpplague: Mine: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for GNU/Linux 2.4.3, not stripped
[16:39] <lag> prpplague: Note the Linux version and SYSV tags
[16:40] <prpplague> lag: ahh yea
[16:40] <GrueMaster> prpplague: If you get that working, it would greatly help my test environment.
[16:40] <lag> I've also tried stripped and static binaries
[16:40] <lag> prpplague: Also, did you test the kernel I sent you?
[16:41] <prpplague> lag: yea looks like your cross-compiler is out of date
[16:41]  * prpplague tries to remember about testing the kernel
[16:41] <prpplague> lag: been swamped with a release, let me check my notes
[16:43] <prpplague> lag: not seeing it in my notes or email, which email address did you send it to?
[16:47] <lag> I didn't, I gave you a people.canonical.com address and you downloaded it :)
 19:23:03> lag: pulling now
[16:47] <lag> :)
[16:47] <prpplague> ahh right, sorry
[16:48] <lag> prpplague: So it was 3hrs from now on Friday :)
[16:48] <prpplague> no i haven't had time to test
[16:49] <lag> prpplague: Do you still have the link?
[16:49] <prpplague> lag: negative, but i did pull it
[16:49] <lag> rsalveti: ping
[16:49]  * prpplague sees it
[16:50] <lag> :)
[16:50] <lag> prpplague: So your cross-compilers ...
[16:50] <lag> prpplague: Are they binaries? Or do you have to build them?
[16:50] <prpplague> lag: the codesorucery is binary, but when i use OE it builds it from source
[16:51] <lag> Are they both free?
[16:52] <prpplague> http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite
[16:53] <prpplague> lag: yea
[16:53] <prpplague> lag: there is a learning curve for OE
[16:53] <lag> prpplague: I just hit that link as you sent it :)
[16:55] <lag> jayabharath: Hi Jay
[17:11] <mopdenacker> there's a learning cliff for OE ;-)
[17:12] <lag> mopdenacker: :)
[17:12] <lag> CS is on its way :)
[17:13] <ogra> lag, talk to hrw, we have the distro gcc packaged as cross compiler
[17:13] <lag> ogra: In our repos?
[17:13] <ogra> either in the repo or in a linaro PPA
[17:14] <rsalveti> lag: pong
[17:14] <lag> Okay, he doesn't seem to be in at the moment
[17:14] <lag> rsalveti: Can you test a kernel for me please?
[17:14] <lag> rsalveti: http://people.canonical.com/~ljones/usb-stopped-panda/
[17:14] <rsalveti> lag: yep
[17:14] <lag> rsalveti: Thanking you!
[17:14] <rsalveti> lag: oh, about the usb issue you found on your board?
[17:14] <lag> I'm fairly sure it's my board
[17:15] <lag> rsalveti: Yeah
[17:15] <rsalveti> ok
[17:15] <lag> ta
[17:15] <mopdenacker> rsalveti: I'm testing your 903.7rsalveti2 kernel with the alpha3 preinstalled images on my Panda
[17:16] <rsalveti> mopdenacker: nice, did it work?
[17:17] <mopdenacker> rsalveti: not completely. It's not exactly the right resolution setting. At least we can see something and read the screen, but lines look interleaved.
[17:18] <rsalveti> mopdenacker: hm, ok, i think it should set 640x480 if it can't recognize it correctly
[17:19] <rsalveti> mopdenacker: you're testing with dvi, right?
[17:19] <mopdenacker> In graphics mode, the screen is split in 2 vertical parts.
[17:19] <rsalveti> hdmi->dvi
[17:19] <mopdenacker> rsalveti: I connected the hdmi output of the Panda to an apparently DVI-D monitor.
[17:20] <rsalveti> mopdenacker: ok
[17:21] <mopdenacker> rsalveti: let me show a picture (takes a bit of time to open my phone and take the sd card out)
[17:22] <rsalveti> mopdenacker: it'd also be interesting to see your boot log, with omapdss.debug=1 and your edid
[17:24] <rsalveti> to get the edid install the package read-edid and run parse-edid /sys/devices/omapdss/display0/edid
[17:24] <lag> mopdenacker: That is a known issue
[17:24] <lag> mopdenacker: Which monitor do you have?
[17:25] <lag> robclark: ping
[17:25] <rsalveti> mopdenacker: but he is testing my kernel
[17:25] <rsalveti> argh
[17:25] <rsalveti> lag: but he is testing my kernel
[17:26] <rsalveti> lag: with robclark's patches for better dvi support
[17:26] <lag> rsalveti: Does your kernel have robclark and mythripk's patches?
[17:26] <robclark> lag: pong
[17:26] <lag> robclark: You have a customer --^
[17:26] <rsalveti> lag: yep
[17:26] <lag> rsalveti: Coolio
[17:26] <mopdenacker> rsalveti: here's the picture: http://free-electrons.com/tmp/IMG_20100817_181722.jpg
[17:27] <lag> mopdenacker: robclark should be able to help :)
[17:27] <lag> robclark and I have seen this before
[17:27] <rsalveti> lag: http://gitorious.org/ubuntu-experimental/kernel-maverick/commits/rsalveti-ti-omap4
[17:27] <robclark> mopdenacker: if you haven't already, could you post bootlog and EDID...  I'll look in one minute
[17:28] <ogra> GrueMaster, so for me its definitely dbus related, if i get to the shell after oem-config failed i can see dbus not running, it fails to start due to the file /var/lib/dbus/machine-id already existing, if i delete that file and start up dbus (service dbus start) the system hardlocks
[17:28] <GrueMaster> Interesting.
[17:28] <GrueMaster> I'm retrying on beagle now.
[17:29] <ogra> though i would still blame the kernel, dbus shouldnt be able to lock up the system hard
[17:30] <mopdenacker> rsalveti, robclark, I can already share the bootargs that work: omapdss.hdmicode=35, omapdss.hdmimode=0. I'll reboot to get the bootlog.
[17:30] <robclark> ahh, sorry, back..
[17:30] <robclark> mopdenacker: this looks like the issue w/ framebuffer resize..
[17:30] <rsalveti> robclark: could be
[17:30] <ogra> mopdenacker, looks like you should use two mice
[17:30] <robclark> unfortunately rsalveti was having problems with one of those patches, and I haven't had time to debug yet ;-)
[17:30] <rsalveti> :-)
[17:31] <rsalveti> robclark: for now I'm just skipping it
[17:31] <mopdenacker> ogra: good idea. We have 2 hands, why shouldn't we use 2 mice ;-)
[17:31] <ogra> :)
[17:33] <robclark> fwiw rsalveti... what I suspect might be needed w/ that second patch, is an acquire_console_sem() before the fb_set_var() calls (in omapfb-main.c in size_notify()) and a release_console_sem() afterwards..  although that seems a bit ugly to me
[17:34] <robclark> at least w/ my kernel, I get some backtraces because of a callback that is called indirectly from fb_set_var() which is expecting console lock to be held
[17:34] <rsalveti> robclark: oh, ok, makes sense
[17:34] <robclark> my theory is that on your kernel that somehow causes a more severe result than just warning msg
[17:35] <rsalveti> robclark: probably, as the screen seems to be fine but it stays with just a black screen
[17:35] <rsalveti> lag: installing your kernel
[17:36] <rsalveti> lag: what's the difference?
[17:36] <lag> rsalveti: Cheers buddy
[17:43] <rsalveti> lag: 2.6.34-903-omap4 (root@tangerine): working fine with my usb
[17:43] <rsalveti> my / fs is in a usb hd :-)
[17:44] <rsalveti> lag: any other test?
[17:45] <lag> rsalveti: Nope, thanks :)
[17:49] <rsalveti> lag: http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ for linaro cross compiler
[17:49] <rsalveti> I'm using it here, works fine
[17:49] <rsalveti> just don't compile u-boot with 4.5 hehe
[17:51] <rsalveti> ogra: did you had time to look at the pybootchartgui bug?
[17:52] <mopdenacker> rsalveti, robclark: here's the bootlog. Unfortunately, there are module loading errors because I couldn't install the package (board not fully booted yet)
[17:52] <mopdenacker> http://pastebin.com/QrvhMEaN
[17:52] <rsalveti> mopdenacker: you can install the package using qemu, with your sd card at your host pc
[17:52] <rsalveti> or just copy the kernel modules
[17:53] <robclark> k, will look in a few minutes... in a call again :-(
[17:53] <rsalveti> mopdenacker: can you also get the edid from it?
[17:54] <mopdenacker> rsalveti: how can I get it? I don't see it in the boot log...
[17:55] <rsalveti> mopdenacker: adding omapdss.debug=1 to the boot args would help also, so we can get more information from the display driver
[17:55] <rsalveti> mopdenacker: after login, get the dmesg output
[17:55] <mopdenacker> rsalveti: ah, right! Thanks
[17:55] <rsalveti> so you can get the debug lines from the kernel
[17:55] <mopdenacker> Not sure I will get to a command line. I'll copy/paste the serial console.
[17:56] <rsalveti> mopdenacker: to get the edid, install the package read-edid and run parse-edid /sys/devices/omapdss/display0/edid
[17:56] <rsalveti> mopdenacker: you can change the boot.scr from your sd card
[17:56] <rsalveti> and add the command line argument you want
[17:56] <mopdenacker> rsalveti: right.
[17:57] <rsalveti> mopdenacker: put your sd card at your host, mount the first partition and you'll see the boot.scr
[17:57] <rsalveti> mopdenacker: dd if=boot.scr of=boot.script bs=1 skip=72
[17:57] <rsalveti> then edit boot.script
[17:58] <rsalveti> and run mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.script boot.scr to generate the boot.scr again
[17:58] <mopdenacker> rsalveti: thanks, I already have these details on OMAPpedia.
[17:58] <rsalveti> ok :-)
[17:58] <mopdenacker> and I already have done this.
[17:59] <mopdenacker> Anyway, thanks for the dd tip to create the boot.script file. I didn't think of this.
[17:59] <mopdenacker> This is a kind of "uboot dump-image" command ;-)
[18:00] <mopdenacker> rsalveti: sorry, I really gotta go now. Is the EDID the only thing you need?
[18:00] <rsalveti> edid and dmesg with omapdss.debug=1
[18:00] <rsalveti> with this we can check what went wrong
[18:02] <mopdenacker> rsalveti: good! Thanks a lot! I'll be away from my board tomorrow, but you will have these on Thursday.
[18:02] <rsalveti> mopdenacker: np :-)
[18:04] <rsalveti> lunch time
[18:09] <ogra> rsalveti, uploaded
[18:09] <rsalveti> ogra: nice, thanks :-)
[18:27] <GrueMaster> ogra: not dbus. Just started running A3 on beagle.  Upgraded kernel & reboot ok.  Upgraded dbus & reboot ok.  Will look at other packages in am.
[18:27] <GrueMaster> "May" be apparmor.  will look tomorrow.
[18:28] <GrueMaster> I have a list of package upgrades.
[18:28] <GrueMaster> anyways, beer time.  My peers are calling me.
[18:34] <npitre> lag: hey!
[18:41] <rsavoye> your peers or your beers are calling you ? :-)
[19:10] <DanaG> Say, anyone know of a packaged browser that runs on directfb, or qt-embedded?
[19:10] <DanaG> ... and supports css and javascript.
[19:12] <rsavoye> opera mini ?
[19:14] <DanaG> Well, I'd be rendering local files.
[19:24] <DanaG> ah, and say, where's nmcli?
[19:25] <suihkulokki> aa
[19:55] <armin76> suihkulokki: agreed
[20:36] <rsalveti> ls -l
[20:36] <rsalveti> argh :-)