[02:11] <mup> PR snapd#6735 opened: tests: Wait for man db cache is updated before after install snapd on Fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6735>
[06:45] <zyga> good morning
[06:54] <zyga> Hey mvo
[06:58] <mvo> hey zyga
[07:00] <pedronis> zyga: mvo: hi
[07:00] <zyga> Hey pedronis
[07:00] <zyga> I didn’t push it yet but I have the next chunk of update ns refactor rebased and adjusted
[07:01] <zyga> I’ll open the PR in about an hour after I handle kids and other morning routine
[07:07] <mvo> hey pedronis - good morning
[07:08] <pedronis> zyga: ok, I likely will not get to it before my vacation though
[07:15] <pstolowski> morning
[07:31] <mup> PR snapd#6659 closed: snapcraft: build static fontconfig in the snapd snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6659>
[07:32] <mvo> https://github.com/snapcore/core/pull/104 <- needs a review (should be simple :)
[07:32] <mup> PR core#104: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
[07:37] <mborzecki> morning
[07:37] <mvo> hey mborzecki
[07:38] <mborzecki> mvo: hey
[07:38] <mborzecki> a day off and i'm looking at spread logs :)
[07:39] <mvo> mborzecki: I was wondering
[07:39] <mvo> mborzecki: if I misremembered the day :)
[07:40] <mborzecki> mvo: got an email from travis that the job is still failing
[07:41] <mborzecki> looks like google:centos-7-64:tests/main/nfs-support leaves garbage behind
[07:41] <mvo> mborzecki: uh, ok - I saw this failing earlier indeed
[07:43] <mup> PR snapd#6418 closed: many: allow core as a fallback for core16  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6418>
[07:44] <mup> PR snapd#6603 closed:  snapstate: add new NoReRefresh flag and use in Remodel() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6603>
[08:14] <mborzecki> mvo: it's probably best to disable the test for fedora and centos until i figure out a way of this
[08:15] <mborzecki> mvo: in short, nfsv3 does not export selinux labels, nfs 4.2+ can
[08:15] <mborzecki> mvo: so with nfs3 incorrect label (nfs_t) will be used, regardless of what we do
[08:18] <mborzecki> mvo: just checked that nfsv4 with security_label option works correctly
[08:24] <zyga> quick trivial PR ahead of other stuff https://github.com/snapcore/snapd/pull/6736
[08:24] <mup> PR #6736: cmd/snap-update-ns: rename variable "up" to "ctx" <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6736>
[08:24] <zyga> mborzecki: are you off or not :)
[08:24] <zyga> mborzecki: sho, go and enjoy the sunlight :-)
[08:24] <mborzecki> hahah
[08:24] <mup> PR snapd#6736 opened: cmd/snap-update-ns: rename variable "up" to "ctx" <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6736>
[08:24] <mup> PR snapd#6737 opened: tests/main/nfs-support: temporarily disable for Fedora and CentOS <SELinux> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6737>
[08:24] <mborzecki> zyga: mvo: ^^
[08:25] <zyga> approved
[08:25] <mborzecki> didn't want to leave you with master broken again :P
[08:25] <mborzecki> ok, now i'm off, cu tomorrow
[08:26] <zyga> ah
[08:26] <zyga> hey Chipaca
[08:27] <Chipaca> hi
[08:28] <Chipaca> why do i suspect forum-person tried the equivalent of 'snap install snapd'
[08:28] <Chipaca> because they heard the snap needed snapd
[08:29] <zyga> Chipaca: perhaps, I was thinking the same thing
[09:32] <zyga> https://github.com/golang/go/commit/97c4ad432743d74ee59648dee0db1b107c701834
[09:32] <zyga> CL
[09:32] <zyga> change list
[09:32] <zyga> perforce
[09:32] <zyga> people hacking on go use perforce?
[09:40]  * pstolowski runs a quick errand, afk for a bit
[09:42] <Chipaca> zyga: googlespeak leaking
[09:54] <mup> PR snapd#6599 closed: snapstate,state: add TaskSet.AddAllWithEdges() and use in doUpdate <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6599>
[10:09] <pedronis> mvo: maybe this was already clear but I added a post-facto comment to https://github.com/snapcore/snapd/pull/6418
[10:09] <mup> PR #6418: many: allow core as a fallback for core16  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6418>
[10:24] <zyga> mvo: https://api.travis-ci.org/v3/job/521150301/log.txt is interesting
[10:24] <zyga> mvo: no idea, perhaps something left over core16 behind?
[10:25] <mvo> zyga: yeah, that sounds like it :/
[10:25] <zyga> mvo: mvo I saved https://paste.ubuntu.com/p/GVwfVfTHVm/
[10:25] <zyga> mvo: I'll restart the run
[10:25] <mvo> ok
[10:25]  * Chipaca goes to get some exercise
[10:30] <mvo> pedronis: thanks for adding this extra info to the core16-core pr. quick question: checkSnap() needs to get access to the new model to validate things like kernel/gadget for the new model. should I add model to checkSnap or rather "task" and we add the info about the new model to the task. or something else?
[10:42] <pedronis> mvo: we probably need to chat, I have a plan for that but is involved  (we really need to know a new store and new model at various points)
[10:43] <mvo> pedronis: is now good? how long will it take? I can also shelve it and work on something else first if you want to do the prereq work
[10:44] <pedronis> mvo: we can chat quickly now
[10:44] <mvo> pedronis: ok, I'm in the standup ho
[10:48] <pstolowski> re
[11:09] <zyga> gah
[11:10] <zyga> when master is read on rename, it's not a good day
[11:10] <zyga> portal test failure https://www.irccloud.com/pastebin/PKt1NTxz/
[11:14] <zyga> pedronis: https://github.com/snapcore/snapd/compare/master...zyga:feature/user-mount-ns-20.9-split-3-of-n?expand=1
[11:15] <zyga> pedronis: at +800, -200 I think I will split it into 2-3 more branches
[11:15] <zyga> but this is now rebased and I think in good shape
[11:15] <zyga> and on top of that I have working persisted and updated per-user mount namespaces
[11:15] <zyga> I will need to spend some time to research jdstrand's questions but it's closer now
[11:15] <pedronis> zyga: cool, as I said but likely might not get to look at it this week
[11:15] <zyga> yep
[11:15] <zyga> I'll return to other pending branches
[11:16] <mup> PR snapd#6737 closed: tests/main/nfs-support: temporarily disable for Fedora and CentOS <SELinux> <Simple 😃> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6737>
[11:16] <zyga> time to fix https://github.com/snapcore/snapd/pull/6717
[11:16] <mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
[11:18] <pedronis> mvo: btw as I said I'm ok with 6733 with the small tweaks I proposed
[11:20] <mvo> pedronis: thanks!, will get to it after lunch
[11:20] <mup> PR snapd#6738 opened: tests: check for /snap/core16/current in core16-provided-by-core <Created by mvo5> <https://github.com/snapcore/snapd/pull/6738>
[11:41]  * cachio afk
[11:46] <pedronis> zyga: do I see it correcly that #6681 will/might conflict with our own snap-confine groups related rework?
[11:46] <mup> PR #6681: many: support system-users for 'daemon' user <Complex> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
[11:46] <pedronis> s/our own/your own/
[11:46] <zyga> yes
[11:46] <zyga> I spoke with jamie about it and promised to work on all conflicts
[11:46] <pedronis> ok
[11:46] <zyga> he was happy with either of us doing the conflict resolution though
[11:46] <zyga> so I don't anticipate problems
[12:03] <zyga> eh
[12:03] <zyga> so that go check thing where it eats all memory
[12:03] <zyga> that is not fixed?
[12:03] <zyga> when it diffs recursive structures
[12:13] <Chipaca> zyga: i thought it was a bug in the differ, that had been fixed?
[12:13] <Chipaca> not sure tho
[12:13] <zyga> apparently not enough
[12:13] <Chipaca> maciej knows more
[12:13] <zyga> I fixed it locally
[12:14] <zyga> by disabling that
[12:22] <Chipaca> don't disable the maciej! it's nice having him around
[12:22] <zyga> pstolowski: can you please look at https://github.com/snapcore/snapd/pull/6717
[12:22] <zyga> too late! he's gone today
[12:23] <mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
[12:23] <pstolowski> zyga: will do
[12:36] <pedronis> jdstrand: hi, I did a first pass, getting familar with #6681
[12:36] <mup> PR #6681: many: support system-users for 'daemon' user <Complex> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
[12:45] <pedronis> jdstrand: what's the status of #5644  vs landing it for 2.39 ?
[12:45] <mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
[12:45] <jdstrand> pedronis: thanks! I'll take a look. other than that, there is the outstanding question of how to deal with systems that do not have the daemon user
[12:46] <pedronis> jdstrand: there is a list of those in the forum topic, right?
[12:46] <jdstrand> pedronis: I've been unable to do any snap decls. I've hoped to get to it since the agreement. I still hop to start this week
[12:46] <pedronis> jdstrand: ok
[12:47] <jdstrand> pedronis: the forum topic only lists solus as not having the LSB-required daemon user. that is the only one I am aware of
[12:48] <jdstrand> pedronis: I have not tested actual behavior yet if it doesn't exist. I know that the lookup for u:daemon and g:daemon will fail in policy generation. how that is exposed to the user I'm not sure
[12:49] <pedronis> jdstrand: I think we should fail somehow around checkAssumes on this
[12:49] <jdstrand> pedronis: so, I could try to do something with an implied assumes, an explicit assumes, fail earlier or implement a new backend to create it. maybe you have other ideas
[12:49] <jdstrand> pedronis: I was leaning towards something like that as well
[12:50] <pedronis> jdstrand: I think we start by failing with an implied assumes
[12:50] <pedronis> and see what feedback we get from users there
[12:50] <jdstrand> pedronis: ok, I'll work on that next
[12:50] <pedronis> and whether that pushes us, the packaging or the distro to creat the user
[12:50] <jdstrand> zyga: I had a conflict today. I already resolved it
[12:50] <jdstrand> pedronis: what is the timeframe for 2.39 btw?
[12:51] <pedronis> jdstrand: it's in the forum now
[12:51] <pedronis> jdstrand: https://forum.snapcraft.io/t/the-snapd-roadmap/1973
[12:52] <jdstrand> pedronis: I marked the daemon user for that since, well, lots of people want it, roadmap, etc. it shouldn't be very risky since most of the code only hits if specifying system-users
[12:52] <jdstrand> ok, cool. I see the topic (hadn't read email yet today)
[12:52] <pedronis> jdstrand: that's fine, next week I'm off but I would think if we clarify things,  mvo and zygmunt reviews would be enough
[12:53] <pedronis> jdstrand: I have a question about the snap-confine change, I'm either confused or the comment is or yet something else
[12:53] <jdstrand> pedronis: joe said it's my highest priority, so I'll stay on top of it
[12:54] <jdstrand> pedronis: I saw, I'll swing back to your questions a bit later
[12:59] <mup> PR snapd#6627 closed: devicestate: deal correctly with the "required" flag on Remodel <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6627>
[13:26] <jdstrand> pedronis: ok, responded. I'll focus on the implied assumes behavior and keep an eye on the PR for things you or others would like to see changed
[13:31] <jdstrand> mvo: hey, fyi https://bugs.launchpad.net/snapd/+bug/1825052 in case you didn't see it
[13:31] <mup> Bug #1825052: seccomp argument filtering not working on Fedora with 2.38 and Debian with 2.37.4 <snapd:New> <https://launchpad.net/bugs/1825052>
[13:33] <jdstrand> mvo: also, I wasn't planning on looking at that. if you need me to, we'd need to chat with joe (note, I've not really worked on cross distro enablement)
[13:39] <jdstrand> mvo: I'd also like hello-world to be updated to accept hello-world.sh -c ... (not to mention, be rebuilt so it passes review-tools resquash since it was built before -no-fragments)
[13:40] <jdstrand> mvo: I can submit something for that (or upload); istr it was part of the shared account but then the shared account went away... please advise :)
[13:49] <mvo> jdstrand: I can add you to hello world, one sec
[13:49] <mvo> jdstrand: you should have an email
[14:15] <pedronis> pstolowski: #6678 can land right?
[14:15] <mup> PR #6678: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
[14:15] <pstolowski> looking
[14:18] <pstolowski> yes
[14:18] <mup> PR snapd#6678 closed: cmd/snap, api: use DebugGet for timings <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6678>
[14:31] <jdstrand> mvo: thanks!
[14:31] <jdstrand> mvo: it's the little things in life :)
[14:58] <mvo> jdstrand: heh - my pleasure! thanks for updating this snap
[15:05] <mup> PR snapd#6736 closed: cmd/snap-update-ns: rename variable "up" to "ctx" <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6736>
[15:06] <mvo> 6716 needs a second review
[15:10] <mvo> pedronis: 6720 has a conflict now
[15:26] <mup> PR snapd#6739 opened: cmd/snap, store, image: support for cohorts in "snap download" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6739>
[15:26] <Chipaca> pedronis: ^ first cohorts bit (starting from an unlikely one, but a nice narrow vertical)
[15:27] <pedronis> mvo: possibly yes
[15:27] <Chipaca> next up, create-cohort
[15:28] <Chipaca> with an alias of 'cohorate', obvs
[15:28] <pedronis> Chipaca: thx
[15:28]  * pedronis is doing fun things in/to snapstate atm
[15:28] <Chipaca> nooo
[15:29] <Chipaca> :-)
[15:29]  * cachio lunch
[15:29] <Chipaca> ooh, oh, i forgot to add a bit to that
[15:29]  * Chipaca force-pushes quickly before anybody notices
[15:35] <jdstrand> mvo: fyi, I never got an email
[15:36]  * Chipaca quickly sends jdstrand his first email
[15:37] <jdstrand> heh
[15:55] <mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[15:55] <mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[15:56] <mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[15:56] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[16:05] <mvo> jdstrand: oh, let me try again
[16:05] <mvo> jdstrand: tried again, can you please check?
[16:22] <mup> PR snapd#6740 opened: cmd/snap-update-ns: refactor of profile application (3/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6740>
[16:24] <mup> PR snapd#6741 opened: [RFC] osutil: make CommandFromCore honor the snapd snap <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6741>
[16:25] <mvo> pedronis: ^-- this should fix some more of the gaps in snapd vs core
[16:25] <mvo> pedronis: iirc you wanted to also move osutil.ExecFromCore, please let me know the details and I will expand the PR
[16:30] <mup> PR snapd#6732 closed: tests: run livepatch on 18.04 as well <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6732>
[16:43] <jdstrand> mvo: got it
[16:48] <cachio> Chipaca, hey, when you have a time could you please take a look to #6694
[16:48] <mup> PR #6694: tests: improve how snaps are cached <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6694>
[17:10] <zyga> WAT
[17:10] <zyga> -----
[17:10] <zyga> + cat
[17:10] <zyga> EOM
[17:10] <zyga> + Use release-tools/debian-package-builder to interactively fix build
[17:10] <zyga> /bin/bash: line 62: Use: command not found
[17:14]  * zyga fixes
[17:45] <mup> PR snapd#6742 opened: tests: fix syntax error in here-doc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6742>
[18:10] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/6742 if you can please
[18:10] <mup> PR #6742: tests: fix syntax error in here-doc <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6742>
[18:10] <Chipaca> ouch
[18:10] <Chipaca> how did that land?
[18:11] <Chipaca> ah, debug
[18:11] <Chipaca> ok
[18:18] <zyga> Chipaca: fun right
[18:18] <zyga> thank you
[18:34] <mup> PR snapd#6742 closed: tests: fix syntax error in here-doc <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6742>
[18:50] <mup> PR snapd#6738 closed: tests: check for /snap/core16/current in core16-provided-by-core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6738>
[18:51] <Wimpress> Snapcraft Live is starting in 10 mins - https://twitter.com/snapcraftio/status/1118587454821367808
[18:58] <zyga> Wimpress: mind if I haunt the comment section? :)
[19:02] <mup> PR snapd#6743 opened: cmd/snap, client, daemon, store: create-cohort <Created by chipaca> <https://github.com/snapcore/snapd/pull/6743>
[19:02] <Chipaca> pedronis: ^
[19:02] <Chipaca> and EOD for me
[19:02] <Chipaca> tomorrow: snapstate cohortitation /o\
[19:17] <pedronis> mvo: still around?
[19:25] <mvo> pedronis: yes
[19:30] <pedronis> mvo: introducing DeviceContext is going well, but I wonder how much you would dislike this change: https://paste.ubuntu.com/p/hzcxF3rCbS/
[19:30] <pedronis> mvo: needing Model in the bowels of doInstall is a bit annoying/fragile
[19:31] <mvo> pedronis: looking
[19:32] <mvo> pedronis: that looks fine
[19:32] <pedronis> ok, thx
[19:32] <pedronis> it simplifies some things and avoid some strange effects
[19:32] <mvo> pedronis: thanks for this - do you have advice for osutil.CommandFromCore for me? iirc you wanted this to go to cmd.CommandFromSystemSnap or something like this?
[19:32] <mvo> pedronis: yeah, it sounds nice
[19:33] <pedronis> yes, something in cmd
[19:34]  * mvo nods
[19:34] <pedronis> mvo: close to InternalToolPath basically
[19:37] <mvo> pedronis: will do
[19:37] <mvo> pedronis: thank you!
[19:42] <Wimpress> zyga: Thanks for joining us!
[19:42] <zyga> pleasure to do so, really enjoy this part ;)
[19:42] <zyga> :)
[19:43] <Wimpress> :-D
[19:44] <zyga> jdstrand: I know you are busy but may I interest you with https://github.com/snapcore/snapd/pull/6714
[19:44] <mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
[19:44] <mvo> pedronis: hm, we have an import cycle if I move CommandFromCore to cmd
[19:45] <pedronis> mvo: hm
[19:45] <mvo> pedronis: snapinfo.go is the problem
[19:45] <mvo> pedronis: it imports client which in turn imports snap which imports snapfs
[19:46] <pedronis> blargh
[19:46] <mvo> pedronis: maybe I can move snapinfo out?
[19:46] <mvo> it does not fit there much
[19:46] <pedronis> yes, the problem is that so far we haven't found where to put it either
[19:46] <pedronis> also we do plan to break snapfs and snap
[19:46] <pedronis> but dep but not now
[19:46] <pedronis> s/but dep/dep/
[19:47] <mvo> pedronis: I could move CommandFromCore into its own cmd/cmdutil pkg?
[19:47] <mvo> pedronis: together with InternalToolPath maybe
[19:48] <pedronis> that sounds ok, if we move both, at least temporarely, we really need to find a home for snapinfo.go
[19:48] <pedronis> but I haven't had time to think one yet
[19:49] <mvo> pedronis: ok, I will explore this avenue
[20:25] <zyga> pedronis: do you think you will have time to look at https://github.com/snapcore/snapd/pull/6717 before your holidays
[20:25] <mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
[20:25] <zyga> pedronis: alternatively, can you defer to mvo for review?
[20:27] <pedronis> zyga: it's on my list to try to review tomorrow
[20:27] <zyga> thank you!
[20:30] <mvo> pedronis: 6741 is now updated, probably does not need your review I tried to follow your guidance
[20:30]  * mvo -> sleep
[21:12] <mup> PR snapd#6744 opened: tests: make test parallel-install-interfaces work for boards with pre-installed snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6744>
[21:50] <mup> PR snapd#6745 opened: tests: make snap-connections test work on boards with snaps pre-installed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6745>
[22:21] <mup> Bug #1825254 opened: auto-complete doesn't work on ubuntu core 18 <Snappy:New> <https://launchpad.net/bugs/1825254>
[22:44] <mup> PR snapd#6746 opened: cmd: typedef struct sc_error <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6746>


[12:29] <Craw^> hello
[13:01] <Craw^> Ngayon lang ba down ang ubuntu-ph.org?
[16:52] <Craw^> Knightlust
[17:49] <Igorots> Craw^: yes?
[17:49] <Igorots> sorry, was busy a while back
[17:52] <Craw^> No problem. Was just browsing through your blog kanina :P
[17:57] <Igorots> yeah, find anything interesting?
[18:06] <Craw^> I'll continue reading tomorrow :)
[18:10] <Igorots> hehe, thanks for visiting, but i doubt you'll find something useful there.
[18:18] <Craw^> I'm a newbie so I'm sure I'll learn something :D
[18:33] <Craw^> Talk to you tomorrow.


[03:16] <mjg59> Hm.
[03:36] <mdz> mjg59: hm?
[03:37] <mjg59> The password for the "ume" user doesn't seem to be "ume"
[03:37] <mjg59> Also, are the dailies being built for x86 or lpia?
[03:37] <mjg59> Because I seem to be seeing unhildonised apps that are supposed to check for that at build time
[03:38] <mdz> mjg59: I think the password DES-crypts to 'ume' but the system is configured for md5 passwords
[03:38] <mjg59> Also, I can't change to a VT and the application launcher menu is only showing me stuff up to "c"
[03:38] <mdz> that's only a guess, as I haven't had my hands on a Q1 to try it out
[03:39] <mjg59> Want me to ship the dodgy one back to London?
[03:39] <mjg59> As far as I can tell, it's just the fan - so it's ok for short periods of time
[03:50] <mjg59> Ok. So /why/ are the ume dailies being built with i386?
[03:59] <amitk> mjg59: the password is blank
[03:59] <mjg59> amitk: For which?
[03:59] <amitk> ume
[03:59] <mjg59> No it's not
[03:59] <mjg59> There was a hash in shadow
[04:09] <amitk> mjg59: are we talking crownbeach or samsung Q1 images?
[04:09] <mjg59> Q1
[04:19] <mdz> mjg59: yes, please do
[04:19] <mdz> mjg59: the dailies are being built with i386 only because Tollef hasn't gotten around to changing them yet (was supposed to happen last week)
[04:20] <mjg59> mdz: Ok
[04:20] <mjg59> Hm. The other thing is that the dailies still seem to use an ext2fs, and never fsck it?
[04:22] <mjg59> Oh, no, it /is/ ext3 - we're just mounting it as ext2
[04:27] <amitk> atleast the crownbeach ones seem to have blank password set.
[04:28] <amitk> mjg59: ^^ I just reflashed my crownbeach at 5am to make sure I wasn't hallucinating :-)
[04:29] <mjg59> amitk: Heh. Certainly not the case here.
[04:44] <mjg59> mdz: Did you send me a PSU with this one?
[05:56] <mdz> mjg59: yes (without the country-specific cable)
[06:00] <mjg59> mdz: Ok, I'll find that - I can only put my hands on one of them right now
[08:32] <dholbach> good morning
[03:00] <agoliveira> kwwii: Hi Ken. Have a minute?
[03:01] <Mithrandir> agoliveira: if you could prod me when you have a couple of minutes, that'd be good.
[03:01] <agoliveira> Mithrandir: We can talk now if you want.
[03:01] <Mithrandir> sure, I'll take it to a query
[03:10] <amitk> Mithrandir: latest kernel upload seems to fix the unionfs oops. Haven't been able to reproduce it since last night.
[03:10] <Mithrandir> amitk: rockin'
[03:10] <Mithrandir> I've found out my display here hates the crown beach, but I'll bring in another monitor tomorrow.  We'll hopefully have lpia images then
[03:11] <amitk> super
[03:13] <mjg59> Yeah, I've been unable to reproduce it either now
[03:21] <smagoun> amitk: we're still having trouble with unionfs on our crown beach, even with 2.6.22-12.39
[03:21] <smagoun> Is there a more recent kernel? (I don't see one in launchpad)
[03:24] <Mithrandir> you probably only need the newer linux-ubuntu-modules
[03:28] <smagoun> Mithrandir: ah, of course. I have 2.6.22-12.31, and I see that 2.6.22-12.32 is now available - with a unionfs update in the changelog. Thanks!
[03:33] <mjg59> smagoun: I could reproduce the issue with the .31 code, but not with .32
[03:34] <smagoun> mjg59: thanks. Testing it now...
[03:40] <dholbach> hey guys :)
[03:51] <agoliveira> dholbach: Hi there!
[04:09] <kwwii> agoliveira_brb: let me know when you are back and we can talk
[04:12] <agoliveira> kwwii: Hello. I want to set a few things with you about the themeing process if you have a few minutes.
[04:12] <kwwii> agoliveira: sure, shoot
[04:14] <agoliveira> Nice. I was thinking about the process of using the theme tools. Currently it downloads a standard theme from maemo's svn and uses to build a package. We agreed on have the option to use a local theme and uses it as the base to create a new one, correct?
[04:14] <kwwii> yes
[04:15] <kwwii> I think that we simply need one package in which all the artwork lives
[04:15] <kwwii> kubuntu does it this way
[04:15] <kwwii> and it works great
[04:16] <kwwii> if we had one package with all the pieces in it defining the sdk would be much easier. Scripts would install everything to the right place
[04:16] <kwwii> I have no idea why maemo pulls stuff from svn, seems like a bit of overkill to me
[04:17] <agoliveira> kwwii: Cool. The problem now is, how it will be different from current theme format? For now it can't or we can't use the same tools.
[04:17] <kwwii> until now the format is not that different...we just need to update the layout to reflect what we want (the email that peter zhu sent explains that)
[04:18] <agoliveira> kwwii: Ok, I got that. So, should I use the theme package you uploaded to LP as the base? Because I need something to start wiht.
[04:21] <kwwii> agoliveira: it would be better to start with a totally clean theme
[04:21] <kwwii> agoliveira: I can then put my updated pics into it
[04:21] <kwwii> I made a mistake and built the theme before uploading it
[04:21] <agoliveira> kwwii: Can you provide me with one?
[04:22] <kwwii> yepp, what should I call it? ume-basic or such?
[04:22] <agoliveira> kwwii: Something in the line, I guess.
[04:23] <kwwii> I think there was an email about that somewhere I will check it, make it, and send you a tar.gz of the whole thing
[04:23] <agoliveira> kwwii: Ok. Thanks.
[04:24] <kwwii> no problem, good to see this stuff moving forward ;-)
[05:05] <kwwii> agoliveira: email sent
[05:06] <agoliveira> kwwii: Thanks. I'll Check it out right after lunch (even so because it downloading very slowly :( )
[05:09] <kwwii> sounds good
[05:17] <Mithrandir> HappyCamp: why is it you are removing galculator from the ubuntu-mobile fset?
[05:19] <HappyCamp> Mithrandir, I did that because I put moblin-calc in the staging fset.
[05:20] <Mithrandir> HappyCamp: and you did that why?  What's wrong with galculator?
[05:21] <HappyCamp> Adolivera and bspencer know.
[05:21] <Mithrandir> given that galculator is hildonised on lpia, I don't see a point?
[05:21] <HappyCamp> Adolivera replied to my email on ubuntu-mobile and gave some reason.
[05:22] <HappyCamp> I really don't know.  I was just told that they wanted it in there.  So I did it.
[05:22] <Mithrandir> ok, I'll harass bob instead then. :-)
[05:22] <HappyCamp> Mithrandir, thanks! :)
[05:23] <HappyCamp> Mithrandir, by the way.  What is "hppa" architecture?
[05:24] <Mithrandir> PA-RISC
[05:24] <Mithrandir> is probably the name you'd know it by
[05:24] <HappyCamp> Okay.  I don't think I need to mirror that.
[05:25] <Mithrandir> you don't, nor do you need ia64, I believe.
[05:25] <HappyCamp> yep, I was already excluding ia64
[05:30] <Mithrandir> HappyCamp: how's the sponsorship process for moblin-chat going?
[05:31] <HappyCamp> Mithrandir, good.  Slower then it should but that is on our end :(  I am working with the developer of moblin-chat to fix a few minor issues and then should be getting it pushed to asac, hopefully today.
[05:31] <Mithrandir> it would be nice to see it in soon.
[05:31] <Mithrandir> it's not like it has to be perfect on first try.
[05:32] <HappyCamp> I am hoping to hand it off to asac today, if we get our stuff done.
[05:32] <Mithrandir> coolie
[05:32] <asac> HappyCamp: if you have it ready ... let me know .)
[05:33] <asac> HappyCamp: if you have questions I am here :) ... actually not each and every lintian warning needs to be fixed to make me happy ... just to most obvious ones.
[05:33] <asac> if you fix all ... even better ;)
[05:34] <HappyCamp> asac, Will do.  I will hopefully have something for you within two hours.  I'm about to take a shower and then "go to work" :)
[05:55] <agoliveira> Mithrandir, HappyCamp. Looks like there was a misunderstood about galculator. I hildonized it as scheduled and Bob told me later that there was already a hildonized version of it. I checked it out and, despite it did have some hildonized code, it wasn't working for me and I told Bob that and to keep an eye to not let this kind of duplicated work to happen again.  Let's start sell protection instead of support! :-D
[07:35] <HappyCamp> Mithrandir, I was confused before, when you were talkinga bout moblin-chat I was thinking about moblin-applets.  That is what I am currently working on getting pushed.  Almost have the lintian errors fixed.
[07:35] <Mithrandir> HappyCamp: ok, what about moblin-chat?
[07:35] <HappyCamp> I will work with bspencer to find out about moblin-chat
[07:36] <HappyCamp> I think he or horace own it.
[07:36] <HappyCamp> Though I guess I can just see if it looks ready.
[07:36] <Mithrandir> you should be nagging them. :-P
[07:36] <HappyCamp> I will do that, for sure.
[07:37] <Mithrandir> thanks
[07:39] <Mithrandir> I'll revert the galculator commit, and then I'll add some bits to the fsets, then upload.
[07:39] <Mithrandir> upload moblin-image-creator, that is.
[07:39] <Mithrandir> sounds good?
[07:55] <bspencer_> moblin-chat you say?
[07:55] <bspencer_> ode to moblin-chat, by bspencer_
[07:56] <bspencer_> moblin-chat is functional, works with gtalk
[07:56] <bspencer_> oh, why, great moblin-chat, art thou so ugly ?
[07:56] <bspencer_> HappyCamp: did you have a Q about moblin-chat?
[07:56] <HappyCamp> bspencer_, Yep.  Mithrandir was wondering about getting it into ubuntu.
[07:57] <HappyCamp> Is it ready to go?  Has anybody run lintian on it? (Probably not since I haven't told anybody about that).
[07:57] <bspencer_> true, I don't know about lintian
[07:58] <bspencer_> Peter Zhu has worked on moblin-chat and it works but it still has an unpolished UI
[07:58] <HappyCamp> bspencer_, pretty easy to do.  You just download all the build output and then do: lintian *.dsc
[07:58] <HappyCamp> and: lintian *.deb
[08:00] <HappyCamp> bspencer_, So do you want to try pushing in what we got?  Maybe after we fix up any blatan lintian errors.
[08:00] <Mithrandir> (or just run lintian on the .changes file)
[08:01] <HappyCamp> Also is Peter going to be around.
[08:02] <bspencer_> Peter is not around until Oct 10th
[08:02] <bspencer_> but having moblin-chat in Ubuntu would be nice
[08:03] <bspencer_> and it is as good as it will get for this release
[08:03] <Mithrandir> is that blocked on him, or can we get it in without him being around?
[08:03] <bspencer_> not blocked
[08:04] <bspencer_> Mithrandir: have you ever run moblin-chat?
[08:04] <Mithrandir> yes, ages ago
[08:05] <HappyCamp> asac, Can you help me get moblin-chat into ubuntu?
[08:07] <HappyCamp> asac, are these lintian things acceptable? http://moblin.pastebin.org/3316
[09:09] <agoliveira> kwwii: Still around?
[09:11] <kwwii> agoliveira: yepp
[09:12] <agoliveira> kwwii: A question: the layout file will be the same, hildon-theme-layout-4?
[09:12] <kwwii> agoliveira: no, it will be a different version based on the info that peter zhu put together
[09:13] <agoliveira> kwwii: Hmmm... will someone create this? This package deppends on a layout to be built.
[09:13] <kwwii> I certainly hope so :-)
[09:14] <agoliveira> kwwii: Maybe I can just point to a "generic" layout package that will have the hildon-theme-layout-4 contents for now?
[09:15] <kwwii> agoliveira: that sounds like the best plan
[09:15] <kwwii> reading the emails that were sent they apparently think that I'll create a png file and then adjust the coordinates in the layout accordingly
[09:15] <kwwii> I don't see why they cannot go ahead and create the layout file as he already sent a test template which shows the pieces
[09:16] <agoliveira> kwwii: and by your tone I suppose you disagree?
[09:16] <agoliveira> kwwii: Well, I don't want to have to redo things at this point of the process.
[09:17] <kwwii> well, normally artists do artwork and developers develop not sure where the overlap is in this process
[09:17] <kwwii> agoliveira: for now we only have the layout4 stuff so we should keep going with that until we have something new
[09:18] <kwwii> I am starting a totally new template based on the new stuff anyway, so we can figure this out once I get done with that
[09:18] <kwwii> once I have the svg done getting the coordinates from that should not be too hard
[09:18] <agoliveira> kwwii: Should I get done that thing I have now or wait for you?
[09:18] <kwwii> agoliveira: finish what you have now so that we at least have something in
[09:18] <agoliveira> kwwii: Okeedokee
[09:19] <kwwii> agoliveira: the package that I sent you has a black/orange pic in it so it might not be the best but it shows where we are going with this
[09:19] <agoliveira> kwwii: Ok, so I'll stick with the plan and use the current layout as a generic one as a starting point.
[09:20] <kwwii> agoliveira: great, thanks :-)
[09:22] <agoliveira> kwwii: One is glad to be of service :)
[09:22] <kwwii> it probably helps getting paid though :p
[09:45] <agoliveira> kwwii: In a completely unrelaqted news, yesterday I took sushi and sashimi. I was exited about making it at home until I realized the kind of work it is :)
[09:45] <agoliveira> kwwii: I took lessons, well said...
[10:13] <kwwii> agoliveira: killer! I never took lessons but I did make some at home once
[10:13] <kwwii> agoliveira: what I figured out is that buying a whole salmon makes for a lot of food
[10:14] <kwwii> that is why I do not eat any sushi or sashimi with salmon anymore
[10:15] <agoliveira> kwwii: Indeed but to prepare everything, is a lot of work and salmon is easy to prepare compared to tuna which is my favorite... I'll think twice before come out with the idea of make it at home again :)
[10:16] <kwwii> agoliveira: yeah, it is a lot easier to just go to a restaurant and buy it ;-)
[10:17] <agoliveira> kwwii: Yep. Now I know why it's so damn expensive :)
[10:17] <kwwii> ;-)
[10:50] <ian_brasil> what version of hildon is in UME?
[10:55] <ian_brasil> or rather does it support GTK UI Manager?
[12:55] <asac> HappyCamp: yes, please eliminate the duplicate relation depends ... and think about whether we need the "non-dev-pkg-with-shlib-symlink" ... otherwise it looks fine