[06:30] <didrocks> good morning
[06:32] <jibel> hi
[06:32] <didrocks> Am I the only one to see 2 things? Scaling factor is all messed up for the Shell UI on boot and some slowdown, like pause for 5s sometimes, second array, all UI frozen?
[06:33] <jibel> I don't see that
[06:33] <didrocks> opening a bug on the first one at least, easily reproducible here
[06:39] <duflu> Morning didrocks and jibel
[06:39] <duflu> didrocks, there's a known issue for Nvidia
[06:40] <duflu> scaling...
[06:41] <duflu> biab
[06:43] <didrocks> duflu: is there a bug opened? It's indeed Nvidia. Is it worked on?
[06:43] <didrocks> (and hi!)
[06:44] <RAOF> didrocks: Oh! You also see the 5 second pauses!
[06:45] <RAOF> bug# 1815550
[06:45] <didrocks> RAOF: oh, so nvidia specific as well?
[06:46] <RAOF> didrocks: For me, gnome-shell spins, unresponsive, at 100% CPU usage each time a zsh prompt is displayed.
[06:46] <didrocks> good that you spot it on RSS
[06:46] <RAOF> didrocks: Yeah. My intel + amd box is much, much smoother.
[06:47] <didrocks> it's really a PITA. Let's nominate it for -incoming
[06:47] <RAOF> Yeah, it's a tremendously bad experience.
[06:49] <didrocks> RAOF: do you have the scaling factor issue as well on that box?
[06:49] <RAOF> I do not have the scaling factor issue on that box.
[06:50] <RAOF> I'm booting with `nvidia_drm.modeset=1`, though, which has… different behaviours.
[06:50] <RAOF> (Mostly the behaviour is that GDM can't log in until I manually start an X server on a VT)
[06:50] <didrocks> unnince
[06:50] <didrocks> ok, another pause :(
[06:51] <didrocks> and I didn't start any app anything
[06:51] <didrocks> just switched window
[06:53] <RAOF> I don't *normally* notice it just generally mousing around. But that's partially because it happens *every* *single* *time* I press <enter> in a terminal.
[06:59] <oSoMoN> good morning desktoppers
[07:04] <duflu> didrocks, https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bugs?field.tag=x11-scaling
[07:04] <duflu> Hi oSoMoN and RAOF
[07:05] <oSoMoN> hi duflu
[07:05] <RAOF> Ello!
[07:06] <oSoMoN> salut didrocks
[07:06] <oSoMoN> didrocks, mw_hudson already handled the rust-cbindgen no-change rebuild
[07:13] <duflu> RAOF, didrocks, sounds easy to reproduce. I might switch to NVIDIA instead of reverting to SRU work soon
[07:14] <duflu> RAOF: where you using modeset=1 when the bug was first reported?
[07:14] <duflu> *were*
[07:15] <RAOF> I think I was using modest=1 when U first reported the bug. It'll be recorded in the apport details anyway.
[07:15] <duflu> RAOF, it's not
[07:16] <RAOF> Oh, /proc/cmdline isn't captured?
[07:16] <RAOF> Anyway, I probably was using it.
[07:16] <duflu> Unless you count the loaded module name
[07:16] <RAOF> I can try without, if you like.
[07:16] <duflu> RAOF, yes please
[07:19] <RAOF> I might need to get to that tomorrow.
[07:19] <didrocks> oSoMoN:oh nice! THANKS :)
[07:19] <didrocks> (without caps)
[07:21] <didrocks> duflu: FYI, I have modeset=1
[07:21] <didrocks> I have it for a couple of cycles
[07:25] <duflu> RAOF: yeah I thought that too. Night...
[07:26] <duflu> didrocks, thanks
[07:26] <didrocks> duflu: if I can help debugging, do not hesitate
[07:27] <duflu> Oooh. Actually mutter uses a completely different code path for Nvidia modeset=1
[07:27] <duflu> One which I don't use or test normally
[07:27] <didrocks> ahhh, so you might be able to reproduce :)
[07:40] <duflu> didrocks, but you weren't using modeset=1 with the scaling issue right?
[07:41] <duflu> I also assume people using nvidia-drm.modeset=1 are using Wayland sessions because there's no point otherwise. Although that might have its own bugs if used with Xorg
[07:44] <didrocks> duflu: I do have the scaling issue with modeset=1
[07:44] <didrocks> and I'm using the Xorg session, I switched to modeset=1 a while ago, when testing Wayland
[07:45] <didrocks> to test the "Run that on intel, run this on nvidia" IIRC
[07:45] <RAOF> I am not using the Wayland session, either.
[07:45] <RAOF> (because Steam doesn't work in it 😀)
[07:46] <RAOF> I use `modeset=1` to test Mir
[07:47] <didrocks> RAOF: Steam doesn't start at all with Wayland?
[07:48] <RAOF> didrocks: XWayland has no GL acceleration on NVIDIA.
[07:48] <duflu> Cool, thanks didrocks and RAOF. That's odd but now I know.
[07:48] <RAOF> So while Steam might *start*, it's not very useful 😀
[07:49] <didrocks> duflu: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1822478/comments/12 FYI
[07:49] <ubot5`> Ubuntu bug 1822478 in mutter (Ubuntu) "[regression][nvidia] All on screen text is tiny. Icons are normal size but text is nearly unreadable." [High,Triaged]
[07:49] <didrocks> RAOF: ahah :)
[07:49] <didrocks> ok, got it
[07:49] <didrocks> duflu: so basically, when "resetting" on g-c-c, it does what I expect, the issue is only initial state on boot
[07:50] <didrocks> duflu: s/upon/until/ btw
[07:50] <duflu> didrocks, OK. I need to get through my pending work yet.   Do I remember you saying you would take a look at this one?  https://bugs.launchpad.net/ubuntu/+source/libnfs/+bug/1746598
[08:05] <ubot5`> Ubuntu bug 1746598 in libnfs (Ubuntu Cosmic) "[MIR] libnfs" [Undecided,New]
[08:06] <didrocks> hey Laney
[08:07] <seb128> willcooke, Eric has been working on it and I told him I would help if needed, it's a bit complicated. If that's for bug triaging purpose I can do that
[08:08] <willcooke> thx seb128, yes for tracking purposes
[08:08] <seb128> willcooke, security team would prefer to have the new serie if we promote it, but that includes a soname change so it's non trivial
[08:08] <Laney> hi seb128 duflu oSoMoN didrocks
[08:08] <seb128> k, done
[08:13] <duflu> Hmm still April 1st on Stack Overflow
[08:15] <willcooke> oSoMoN, there is a huge openjdk upgrade bug open which has some LibreOffice tasks : https://bugs.launchpad.net/ubuntu/+source/saaj/+bug/1814133
[08:15] <ubot5`> Ubuntu bug 1814133 in virtualbox-hwe (Ubuntu Cosmic) "update to openjdk 11 in 18.04 LTS" [Undecided,New]
[08:15] <willcooke> oSoMoN, is that on your list somewhere?  i.e. should I assign it to you?
[08:32] <oSoMoN> willcooke, yes, that's under control: I backported a couple of patches to fix the build against the new openjdk, the updated packages are in bionic-proposed and should migrate to -updates soon
[08:33] <oSoMoN> do_ko and t_daitx are overseeing the update
[08:33] <willcooke> thx oSoMoN
[08:34] <oSoMoN> you can assign the libreoffice tasks to me if you want (and if LP lets you…)
[08:34] <oSoMoN> updating such huge bug reports tends to timeout more often than not
[08:34] <willcooke> indeed :D
[08:43] <willcooke> duflu, re:  https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1803319 can I assign you on that one?  You already fixed it upstream, but it's targetted to a release and so either needs untargetting or an assignee
[08:43] <ubot5`> Ubuntu bug 1803319 in mutter (Ubuntu Disco) "GNOME Shell task bar menus not updated with external monitor primary and laptop screen fractionally scaled" [High,Triaged]
[08:44] <duflu> willcooke, yes I was thinking the same and then forgot. That's the first time I've decided to unassign myself. The intention was to say that I won't be the one doing the 3.32.1 release which contains the fix
[08:44] <duflu> Now assigned again
[08:45] <willcooke> duflu, merci!
[09:18] <duflu> willcooke, Jonas confirmed he expects there to be a 3.32.1 so I am assuming we will want to grab that in one go instead of patching each fix that it contains
[09:19] <andyrock> monring all!
[09:19] <andyrock> *morning
[09:19] <duflu> moaning andyrock
[09:19] <duflu> :)
[09:19] <duflu> Also good morning
[09:19] <andyrock> 😂
[09:19] <seb128> hey andyrock
[09:20] <seb128> duflu, yeah, we are going to want to update, do you know when they plan to roll it out?
[09:20] <duflu> seb128, I don't know anything more
[09:20] <andyrock> hey seb128! did you have good holidays? :)
[09:20] <duflu> Some gnome stuff is already at 3.32.1
[09:20] <seb128> duflu, k, no worry, probably this week
[09:20] <seb128> right
[09:21] <seb128> andyrock, yes, excellent, thx!
[09:44] <willcooke> duflu, cool, thanks.  (sorry was otp)_
[11:29] <seb128> willcooke, did you see the comment on https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/1819744 ?
[11:29] <ubot5`> Ubuntu bug 1819744 in ubuntu-wallpapers (Ubuntu) "19.04 Disco default wallpapers" [Undecided,Fix released]
[11:30] <willcooke> The last one?  yeah, the wallpaper is slightly different for the grey one.  NFA as far as I'm concerned
[11:32] <seb128> k, thx, I just wanted to make sure it was ok/expected
[11:35] <willcooke> thx
[11:51] <Laney> is the team meeting in 99 minutes or 159 minutes or 219 minutes?
[11:52] <willcooke> Laney, 98 mins
[11:52] <Laney> thx
[11:58] <Laney> it is pinned to 14:30 UK time then?
[11:58] <Laney> I'll ask the fridge calendar people to update it
[12:00] <willcooke> Laney, yeah, looks like it's pinned to "United Kingdom Time"
[12:00] <Laney> righto
[12:00] <willcooke> https://imgur.com/a/xJKFUv5 \o/
[13:10] <willcooke> Laney, do you use IPv6 generally?  And if so, have you seen any problems in Disco?
[13:15] <willcooke> Laney, unping.  Seems there are general connectivity problems
[13:15] <willcooke> with the archive
[13:22] <Laney> doh
[13:22] <Laney> but yes, most of the time
[13:29] <willcooke> #startmeeting Desktop Team Meeting  2019-04-02
[13:29] <meetingology> Meeting started Tue Apr  2 13:29:49 2019 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[13:29] <meetingology> Available commands: action commands idea info link nick
[13:30] <willcooke> Roll call: andyrock, didrocks, duflu (out), jbicha, jamesh (out), jibel, kenvandine, laney, oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out)
[13:30] <kenvandine> \o
[13:30] <oSoMoN>      o/
[13:31] <didrocks> hey
[13:31] <jibel> bonjour
[13:31] <willcooke> We'll do the usual rls incoming bugs.  I already went through the tracking bugs and made sure they are all assigned etc.
[13:31] <andyrock> o/
[13:32] <willcooke> Let's start with B
[13:32] <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[13:32] <willcooke> Nice, zero.
[13:32] <willcooke> C:  http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
[13:32] <willcooke> Also 0.
[13:33] <willcooke> #winning
[13:33] <willcooke> D: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html
[13:33] <willcooke> we have some bugs to review  :)
[13:33] <willcooke> First up:
[13:33] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1815550
[13:33] <ubot5`> Ubuntu bug 1815550 in gnome-shell (Ubuntu) "[nvidia] gnome-shell RSS grows without limit, general slowness" [Critical,Confirmed]
[13:34] <didrocks> we discussed it this morning. It's really making disco unusable
[13:34] <didrocks> (nvidia drivers)
[13:34] <willcooke> +1 to investigate.
[13:34] <seb128> +1 for nominating/assigning
[13:34] <didrocks> +1, duflu started to have a look
[13:35] <willcooke> duflu seems like a good person to assign
[13:35] <seb128> yes
[13:35] <willcooke> ok, targetted and assigned
[13:36] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1822478
[13:36] <ubot5`> Ubuntu bug 1822478 in mutter (Ubuntu) "[regression][nvidia] All on screen text is tiny. Icons are normal size but text is nearly unreadable." [High,Triaged]
[13:36] <willcooke> +1 and already assigned to Trevinho
[13:36] <didrocks> same, annoying regression due to scaling factor with nvidia, so +1
[13:36] <seb128> wfm
[13:37] <willcooke> done
[13:37] <willcooke> next: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1822072
[13:37] <ubot5`> Ubuntu bug 1822072 in gnome-shell (Ubuntu) "User selector doesn't have focus from login screen after screen turned off" [Medium,Confirmed]
[13:38] <willcooke> I logged this one.  It's a regression IMO.  But I'm interested to know if you think it's rls worthy or not.
[13:38] <seb128> I would vote -1 from the steps
[13:38] <seb128> but if that also happens when you lock the screen by keybinding so maybe that's a +1
[13:39] <willcooke> I dont think it does effect lock screen
[13:39] <seb128> I don't think the "wait on the lock screen" is that common of an usecase and while slightly annoying the workaround is obvious
[13:39] <seb128> on the login screen*
[13:39] <seb128> I vote -notfixing
[13:39] <seb128> would still be worth reporting upstream/fixing if we can
[13:40] <willcooke> kk, I'm happy with notfixing then
[13:40] <willcooke> and I can upstream
[13:40] <didrocks> same
[13:40] <seb128> thx
[13:40] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1821901
[13:40] <ubot5`> Ubuntu bug 1821901 in gnome-initial-setup (Ubuntu) "Location services option should be off by default" [Undecided,New]
[13:41] <willcooke> Legal team say this needs to be off by default.  So I think +1 on rls
[13:41] <seb128> k, +1 if legal says so
[13:41] <seb128> you can assign to me
[13:41] <kenvandine> +1
[13:42] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1821895
[13:42] <ubot5`> Ubuntu bug 1821895 in gnome-shell (Ubuntu) "Gnome Shell crashes after resume on Disco" [Undecided,Incomplete]
[13:43] <willcooke> Seems to be wayland only.  So -1 for rls
[13:43] <seb128> -notfixing
[13:43] <seb128> it's lacking info, not confirmed and wayland only
[13:43] <seb128> the report doesn't even state what release he's using
[13:44] <seb128> ah, in the title
[13:44] <seb128> still, almost no info and not impacting the default session
[13:44] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1821019
[13:44] <ubot5`> Ubuntu bug 1821019 in gnome-terminal (Ubuntu) "gnome-terminal does not gain focus upon launch via clicking icon" [Undecided,Confirmed]
[13:44] <willcooke> I've got a feeling that duflu might have fixed this upstream
[13:44] <seb128> yes
[13:45] <oSoMoN> that one is really annoying
[13:45] <seb128> it's a dup of bug #1817924
[13:45] <ubot5`> bug 1817924 in mutter (Ubuntu Disco) "(In Xorg sessions only) apps launched from gnome shell do not get input focus" [High,Triaged] https://launchpad.net/bugs/1817924
[13:45] <willcooke> Do we patch or wait for a point release upstream
[13:45] <seb128> the fix has been commited upstream
[13:46] <seb128> tarballs are due next week
[13:46] <seb128> we might want to backport a fix fixes meanwhile, up to Trevinho/duflu I guess
[13:46] <seb128> we can talk about that out of the meeting though
[13:46] <willcooke> oki
[13:46] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1821933
[13:46] <ubot5`> Ubuntu bug 1821933 in gnome-shell (Ubuntu) "Touch input is offset with two screens (even appearing on the wrong screen)" [Undecided,Confirmed]
[13:47] <willcooke> Another one of mine.  It doesnt affect Fedora.  +1 to work on this
[13:47] <seb128> I would vote -notfixing
[13:48] <seb128> I don't think using touch screen with 2 monitors is common
[13:48] <willcooke> uh, that's a fair point
[13:48] <seb128> touch support is already not great and we don't get lot of flack for it
[13:48] <seb128> so I think our touch users number is low
[13:48] <willcooke> any other votes?  Otherwise notfixing
[13:48] <seb128> those who use docked is problem even lower
[13:48] <didrocks> -notfixing as well for now
[13:48] <kenvandine> -1
[13:49] <willcooke> k, that's the end of the incoming bugs
[13:50] <willcooke> As I said earlier, the unassigned tracking bugs are all clear.
[13:50] <andyrock> maybe let's just add a trello card for it
[13:50] <willcooke> andyrock, will do
[13:50] <willcooke> Laney, anything in the proposed migrations you want to raise?
[13:50] <Laney> nope
[13:51] <willcooke> Cool
[13:51] <willcooke> #topic AOB
[13:51] <willcooke> Anyone got anything?
[13:51] <andyrock> nope
[13:51] <willcooke> Oh, while I remember, jibel do you know how that backlight / blackscreen issue is going off hand?
[13:52] <seb128> what issue is that?
[13:52] <jibel> willcooke, it's going nowhere afaik
[13:52] <willcooke> jibel,  do you have a bug number handy?
[13:53] <jibel> i'ms searching
[13:53] <willcooke> thx, I will follow up after the meeting then
[13:53] <willcooke> anything else for anyone?
[13:53] <willcooke> 1 min before I end the meeting
[13:53] <seb128> not me
[13:53] <oSoMoN> nothing here
[13:54] <willcooke> #endmeeting
[13:54] <meetingology> Meeting ended Tue Apr  2 13:54:44 2019 UTC.
[13:54] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2019/ubuntu-desktop.2019-04-02-13.29.moin.txt
[13:54] <willcooke> thanks all
[13:54] <didrocks> thx
[13:54] <jibel> willcooke, bug 1821882
[13:54] <ubot5`> bug 1821882 in linux (Ubuntu) "Screen is very dark and brightness cannot be adjusted" [Undecided,Incomplete] https://launchpad.net/bugs/1821882
[13:54] <willcooke> thanks jibel
[13:55] <willcooke> kk, I will poke Pierre to reply
[13:56] <willcooke> and done
[13:57] <seb128> willcooke, is there of any concern to us? the report states it already exist in bionic so not a new issue, also seems to be a video driver problem on a specific config...
[13:59] <willcooke> I'd like that confirming by Pierre.  If it means that new machines (like that beefy Dell gaming laptop) get a black screen when trying to install, I'd love to see if fixed.  I'll see what t_jaalton says after Pierre has confirmed
[14:00] <seb128> k
[14:00] <seb128> willcooke, also is your touch coordinate bug happening only on the desktop view? or in other UI elements/apps?
[14:00] <Trevinho> morning...
[14:00] <seb128> hey trevinho
[14:00] <seb128> just in time to miss the meeting :p
[14:00] <willcooke> seb128, everything is offset, shell, window titles, etc
[14:00] <Trevinho> seb128: hey...
[14:01] <seb128> willcooke, that's new from disco?
[14:01] <willcooke> seb128, yeah
[14:01] <seb128> k
[14:01] <Trevinho> yes I set the alarm, but I think I put the wrong tz in it 😭
[14:08] <Trevinho> saw the backlog by the way. but starting next week it will be too early anyways (7 am)
[14:59] <seb128> Laney, do you think you could skip the n-m/ppc64el failure? the current disco version has the same problem, it's not a regression from 1.16 in proposed
[15:42] <Laney> seb128: see my comment on the card, I already did do that
[15:44] <seb128> Laney, ah, I was not on this card/didn't see the comment before, I've just been trying to clean stuff from update_excuses_by_team.html#desktop-packages today
[15:44] <seb128> got cairo, pygobject and few others off :)
[15:45] <seb128> Laney, thx!
[15:46] <seb128> (it's still blocking migration but I guess we need to wait a bit longer?)
[15:46] <seb128> the page refreshed 10 mins ago though...
[16:15] <greyback> kenvandine: hey, with demise of remote desktop-helper, how should one use desktop helpers now? Copy/paste the yaml?
[16:15] <greyback> I've not had to look into the topic in a while, hence being very out of date!
[16:31] <kenvandine> greyback: yes, copy the yaml
[16:32] <kenvandine> until we have the extension
[16:34] <greyback> kenvandine: ack, thanks!
[17:28]  * willcooke -> haircut
[17:28] <willcooke> night all
[17:32] <oSoMoN> good night
[18:06] <seb128> andyrock, bdmurray was asking if bug #1807900 is still on your todolist (I guess it should be an easy change?)
[18:06] <ubot5`> bug 1807900 in update-manager (Ubuntu Bionic) "update-manager suggests to use Livepatch, which is not available" [High,Triaged] https://launchpad.net/bugs/1807900
[18:06] <andyrock> checking
[18:07] <andyrock> yup thanks for reminding me that
[18:07] <andyrock> :)
[18:11] <seb128> andyrock, np! :)


[00:53] <Swami_> sure thanks kyrofa. if you are around
[00:53] <Swami_> will get back and look through it
[03:53] <stgraber> beuno, jdstrand: Just uploaded a tiny fix for LXD 2.0.0 to the store (use the old lxcbr0 bridge as we don't have lxdbr0 on snappy yet)
[03:53] <stgraber> folks upgrading didn't have any issue with rc9 or 2.0 final, but folks doing a clean install would have got broken networking, this will fix new installs
[03:53] <stgraber> cyphermox: ^
[05:09] <cyphermox> stgraber: thanks
[09:31] <davidcalle> Hi snappers, when using the snap find command, I don't see the fully qualified app name, how can I install apps without it?
[09:59] <davidcalle> Anyone, zyga maybe? ^
[09:59] <davidcalle> "when using the snap find command, I don't see the fully qualified app name, how can I install apps without it?"
[10:00] <zyga> davidcalle: store bug
[10:00] <zyga> davidcalle: and it's snaps, not apps
[10:04] <davidcalle> zyga =) ty
[10:13] <mvo> davidcalle: beuno mentioned the other day they are working on automating this, for now we may need to set aliases for the store apps (worst case manually until this is automated). but I'm not sure what the status is, maybe its fixed already, beuno will know
[10:16] <ogra_> ubuntu@localhost:~$ snap install webdm
[10:16] <ogra_> error: access denied
[10:16] <ogra_> mvo, can we make that message a bit more user friendly ?
[10:17] <ogra_> (it used to tell me i should use sudo etc)
[10:17] <oparoz> Any idea why this doesn't compile on arm? https://github.com/kyrofa/mdns-publisher/blob/master/main.go
[10:18] <davidcalle> mvo: thanks
[10:18] <oparoz> Actually, that's wrong, it compiles, but fails in the stripping phase
[10:27] <mvo> ogra_: yes, I think we should
[10:29] <ogra_> Building dependency tree...
[10:29] <ogra_> E: Unable to locate package ubuntu-core-libs
[10:29] <ogra_> P: Begin unmounting filesystems...
[10:30] <ogra_> mvo, s390x and ppc64el fail with that ^^^
[10:30] <ogra_> do we not build that package there ?
[10:35] <oparoz> https://bugs.launchpad.net/snappy/+bug/1569280
[10:36] <mvo> ogra_: I'm surprised by that, I think that worked before :/
[10:36] <ogra_> mvo, did we ever buikld images for them ?
[10:36] <ogra_> (i just added both arches and started a testbuild)
[10:38] <ogra_> OH !
[10:38]  * ogra_ wasnt aware it is a meta package :P
[10:40] <mvo> ogra_: I don't think we did images for them
[10:40] <ogra_> right
[10:44] <ogra_> where the heck do the seeds live for that package ?
[10:46] <ogra_> ah, found them
[10:51] <daker> kyrofa: hi sorry for the noise, store question : if i have rev1 of v1.0 of my snap that's have been automatically rejected, i need to upload v1.0.1(for ex) ?
[11:25] <attente> is there a reason the names of the binaries in /snaps/bin don't match the ones in the snaps themselves?
[11:27] <ogra_> attente, got an example ?
[11:27] <attente> ogra_: ubuntu-calculator-app for example
[11:27]  * ogra_ never used that
[11:28] <ogra_> i meant an example of the binary names :)
[11:28] <ogra_> vs what you expect
[11:28] <attente> ogra_: maybe a better question is what is the canonical way of launching a snap
[11:28] <ogra_> packagename.binary-name
[11:28] <ogra_> i.e. in my nethack snap i defined "run" ... to start my game i now need to exec nethack.run
[11:29] <attente> ogra_: so in ubuntu-calculator-app, i think the Exec line of the desktop file is incorrect possibly
[11:29] <ogra_> well, i thought dpm has tested that
[11:30] <attente> ogra_: it just has the line 'Exec=ubuntu-calculator-app
[11:31] <ogra_> and there is no binary of that name in the snap ?
[11:31] <ogra_> (not sure if .desktop files are simply handled differently)
[11:31] <ogra_> i never used them :)
[11:32] <attente> ogra_: no, there's only /snaps/ubuntu-calculator-app.ubuntucoredev/current/usr/bin/ubuntu-calculator-app
[11:32] <ogra_> then thats fine i guess
[11:32] <attente> ogra_: but /snaps/*/current/usr/bin isn't in the user's path
[11:32] <attente> only /snaps/bin is
[11:33] <attente> so it finds /snaps/bin/ubuntu-calculator-app.calculator instead
[11:33] <ogra_> well, i dont exactly know how ,.desktop files are operated in snappy ... but i guess it is only run inside the confined env ... where that path will be exported by the launcher
[11:34]  * ogra_ assumes /snaps/bin/ubuntu-calculator-app.calculator is a script
[11:34] <attente> yes
[11:35] <ogra_> then it will likely set the path correctly
[11:37] <attente> ogra_: so i should probably not be using the desktop file at all and just using the script in /snaps/bin directly?
[11:37] <attente> since it seems like the desktop file refers to the binary in the snap itself and not /snaps/bin
[11:38] <ogra_> you should use the ,.desktop files from GUIs obviously ... :)
[11:39] <ogra_> no idea how the integration works with that though
[11:39] <ogra_> from commandline you shoudl always just run ubuntu-calculator-app.calculator
[11:58] <tsimonq2> ogra_: can you make metapackages with Snappy or does it have to all be in the package?
[11:59] <tsimonq2> whoops, snap, not package :)
[11:59] <ogra_> tsimonq2, whats the difference ?
[11:59] <ogra_> :)
[11:59] <tsimonq2> heheheh
[11:59] <ogra_> a snap *is* essentially a metapackage :)
[11:59] <tsimonq2> well
[11:59] <tsimonq2> oh I see
[11:59] <ogra_> containing all the bits and pieces
[12:00] <tsimonq2> so let's say I want to make the bob metapackage, and include like 20 deb dependencies, would that work smoothly?
[12:00] <tsimonq2> ooh, could I get it from upstream instead if I wanted to?
[12:01] <ogra_> sure, you would just define all the debs in your snapcraft.yaml and snapcraft would include them
[12:01] <ogra_> and yes, you could as well use the upstream source
[12:01] <tsimonq2> are the debs only from Ubuntu or can they be from Debian as well?
[12:01] <ogra_> for one or even for all your deps
[12:01] <ogra_> only from ubuntu
[12:01] <tsimonq2> oic
[12:01] <tsimonq2> is there a tutorial I could follow to do this?
[12:02] <tsimonq2> or is it really simple?
[12:02] <ogra_> there are examples in the snapcraft-examples package
[12:02] <tsimonq2> is that a deb package that I could install now, or a snappy package? :D
[12:02] <ogra_> snapcraft is a deb package ... note though that you need xenial if you build for xenial snappy
[12:03] <tsimonq2> I'm on Xenial :)
[12:03] <ogra_> good
[12:03] <ogra_> well, "sudo apt install snapcraft"
[12:03] <ogra_> ;)
[12:03]  * tsimonq2 does sudo apt update && sudo apt -y install snapcraft snapcraft-examples
[12:04] <tsimonq2> :)
[12:04] <ogra_> create a workdir ... create a snapcraft.yaml file ... run "snapcraft" in the workdir and if your yasml file is correct you get a working snap ;)
[12:04] <ogra_> *yaml
[12:04] <tsimonq2> where are the examples then? :)
[12:04] <ogra_> i guess in /usr/share7doc
[12:05] <tsimonq2> also, can I upload snaps to PPAs?
[12:05] <ogra_> dpkg -L snapcraft-examples will tell you as usual ;)
[12:05] <ogra_> no
[12:05] <tsimonq2> that would be an awesome feature
[12:05] <ogra_> you can use launchpad to build snaps from a snapcraft.aml in a bzr branch
[12:05] <ogra_> and you can upload them to the store
[12:06] <ogra_> snaps *are* PPAs ... like they are metapackages ;)
[12:06] <tsimonq2> oh okay :)
[12:06] <tsimonq2> so let's say I have my snap built and all ready to go, how do I test it?
[12:07] <ogra_> in xenial you shoudl actually be able to install it directly on your system ...
[12:07] <ogra_> at least after release, not sure what bugs are still there
[12:07] <tsimonq2> it would replace packages and cause a big huge mess, I would prefer a VM :)
[12:07] <ogra_> alternatively you can run a complete snappy in kvm or on i.e. a raspberry pi
[12:07] <ogra_> no, it wouldnt cause any mess
[12:08] <tsimonq2> KVM? I thought there was a guide somewhere for that...
[12:08] <ogra_> snappy on classic installs is a feature of xenial :)
[12:08] <ogra_> installing a snap will "just work" ... snaps live in their own filesystem space, they wont mess up anything
[12:09] <ogra_> (it shoudl already work if your xenial system is up to date, ubuntu-snappy-cli should be installed)
[12:10] <oparoz> ogra_: What's the strategy when we need to ship a firewall, log rotater, etc. It's not really efficient to add it to every single snap part of a solution
[12:11] <ogra_> you would creater a library snap that all your other snaps (only yours though) can consume
[12:11] <oparoz> ogra_: Ah, good. Is there doc on that already?
[12:11] <ogra_> not sure
[12:13] <tsimonq2> ogra_: if I create a snappy package from upstream, will it automatically pull in updates from there?
[12:13] <tsimonq2> for example GitHub
[12:13] <ogra_> if you re-build it
[12:15] <tsimonq2> that seems a bit tedious :|
[12:15] <tsimonq2> is it easy to rebuild and reupload?
[12:16] <ogra_> if your snapcraft.yaml is correct it should be one click in launchpad
[12:16] <ogra_> (modulo build failures that the upstream changes introduce indeed ...)
[12:16] <tsimonq2> can you set up daily builds?
[12:17] <ogra_> i think launchpad receipes are supported ... not sure though
[12:18] <tsimonq2> I'll try later today :)
[12:18] <tsimonq2> then to update everything is sudo snappy update?
[12:19] <ogra_> sudo snap update
[12:19] <ogra_> the "snappy" command is dead
[12:19] <tsimonq2> why?
[12:19] <tsimonq2> 2 extra letters? :P
[12:19] <ogra_> dunno
[12:20]  * ogra_ wasnt involved in that discussion :)
[12:21] <tsimonq2> alright, thank you ogra_, I'm off for a few hours, have a nice day. :)
[12:21] <ogra_> you too
[12:36] <dholbach> kyrofa, sergiusens: can you maybe advise on https://bugs.launchpad.net/click-reviewers-tools/+bug/1569226?
[12:36] <dholbach> I don't know what the right fields and stuff are
[12:36] <kyrofa> Hey dholbach!
[12:36] <dholbach> hey hey - how are things?
[12:37] <sergiusens> morning
[12:53] <ogra_> eeek !
[12:53] <ogra_> sergiusens, !
[12:54] <ogra_> sergiusens, all our initrds use lzma now ... seems the kernel plugin has no check about the compression method and just assumes gzip
[12:58] <sergiusens> ogra_, well, not really; it said we only supported that for now
[12:58] <sergiusens> lzma or lzma2 or xz?
[12:58] <ogra_> bug 1569337
[12:59] <sergiusens> ogra_, thanks
[12:59] <sergiusens> ogra_, probably an EOW thing
[13:00] <ogra_> yeah
[13:07] <kyrofa> dholbach, things are frantic, haha
[13:07] <kyrofa> dholbach, any chance that bug relates to the removal of old-security from snappy?
[13:07] <dholbach> kyrofa, I don't know which fields are current and which old fiels should still be allowed
[13:07] <dholbach> but this breaks store reviews right now
[13:08] <kyrofa> dholbach, join the club, things are changing fast :(
[13:08] <kyrofa> dholbach, I believe old-security is gone and one needs to use the actual interface names now. But then I heard maybe that would come back
[13:08] <kyrofa> dholbach, zyga would know more on that one
[13:09] <zyga> old-security is gone now
[13:09] <zyga> but we'll probably bring it back later, for now use real interfaces
[13:09] <zyga> they are listed in docs/interfaces.md
[13:09] <zyga> note that only auto-connecting interfaces really work as connection/disconnection commands are not wired to the backend yet
[13:09] <zyga> that will land today though so all the interfaces will be fully functional
[13:09] <dholbach> ok... I guess I need to talk to jdstrand to find out what policy should be in this case... reject snaps which don't have proper interface names?
[13:10] <kyrofa> dholbach, I guess so. I thought we had old-security as a migration plan, but I guess not?
[13:11] <zyga> dholbach: snappy validates that internally
[13:11] <zyga> kyrofa: it's all crazy :)
[13:12] <kyrofa> zyga, I've noticed :)
[13:12] <zyga> kyrofa: I want to add old-security back but that's not top-priority
[13:12] <zyga> top priority is fully functional REST api for managing interfaces
[13:12] <kyrofa> zyga, I'm not sure it's necessary since everyone is broken now-- everyone will have to move to interfaces if they want stuff to work
[13:12] <zyga> kyrofa: true
[13:13] <zyga> kyrofa: but some edge cases need old security
[13:13] <dholbach> zyga, right... but the store needs to check it too
[13:13] <zyga> sergiusens: can you release snapcraft that allows something other than old security today?
[13:13] <zyga> dholbach: no
[13:13] <zyga> dholbach: the store doesn't have to check it in any way
[13:13] <oparoz> zyga there is no docs/interfaces.md in snapcraft
[13:13] <zyga> dholbach: we'll add some checks via assertions but that's not today
[13:13] <kyrofa> oparoz, that's snappy
[13:13] <sergiusens> ppisati, fwiw ogra_ logged a bug about the gzip issue
[13:13] <zyga> oparoz: sorry, look at snappy
[13:13] <zyga> oparoz: github.com/ubuntu-core/snappy/ docs/interfaces.md
[13:13] <dholbach> zyga, what if somebody uploads an old style app to the store
[13:14] <sergiusens> zyga, today? wow
[13:14] <oparoz> Thanks guys
[13:14] <dholbach> zyga, with no plugs defined
[13:14] <zyga> dholbach: nothing
[13:14] <zyga> dholbach: it will just run without any extra permissions, fully confined
[13:14] <zyga> dholbach: snappy ignores unknown or invalid interfaces
[13:14] <sergiusens> zyga, we can, but we need old-security replacements for our examples
[13:15] <zyga> sergiusens: I'd be fine with a half-broken release that lets people snapcraft non-broken snaps without old-security
[13:15] <zyga> sergiusens: I suspect that most of those can just use normal interfaces but I didn't check
[13:15] <sergiusens> zyga, right, but we won't be able to know if snapcraft itself is working
[13:15] <sergiusens> or doing the right thing
[13:16] <zyga> sergiusens: ideas welcome, right now you cannot build a snap that uses unity7 + x11 plugs
[13:16] <zyga> sergiusens: I don't know snapcraft as well as you do, what would be the best way forward?
[13:16] <sergiusens> zyga, 1st; is there an os image in edge that works already?
[13:17] <zyga> sergiusens: mvo built a package, the image is soon after that I bet
[13:17] <sergiusens> zyga, 2nd; do we have replacements for everything in `examples` wrt interfaces?
[13:17] <zyga> sergiusens: I don't know what's in all the examples
[13:17] <sergiusens> zyga, 3rd; is old-security coming back or gone forever?
[13:18] <sergiusens> if it is gone, I'd rather have it gone forever
[13:18] <zyga> sergiusens: 3 not sure, I can implement it but if powers that be demand it gone, what can we do?
[13:18] <zyga> sergiusens: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md
[13:18] <zyga> sergiusens: that is what we have today
[13:18] <dholbach> thanks... I'll just catch the error if no plug is defined
[13:18] <dholbach> think that should be fine
[13:19] <sergiusens> zyga, create a snapcraft bug and I'll work on a branch; kyrofa heads up, we might release today
[13:20] <kyrofa> sergiusens, thanks for the heads up
[13:20] <kyrofa> sergiusens, though that probably means we need to do the examples as well
[13:27] <zyga> sergiusens: sure; I'll open the bug in a moment
[13:28] <attente> has something changed with the /run/snapd.socket api in the past day? i seem to only be getting 404 errors now
[13:28] <zyga> attente: many things were removed
[13:28] <zyga> attente: look at docs/rest.md (it has been updated AFAIK)
[13:29] <zyga> attente: which endpoints were you calling
[13:30] <attente> zyga: for example GET /2.0/snaps?sources=local
[13:31] <attente> zyga: docs/rest.md was removed too?
[13:32] <attente> zyga: ok, i'll take a look, thanks for the pointer
[13:33] <zyga> attente: no, it is still there?
[13:33] <zyga> https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#v2snaps
[13:33] <zyga> attente: the prefix changed so you just have to update your client code
[13:35] <attente> zyga: ok, thanks. is the api going to be frozen at some point?
[13:35] <zyga> attente: when we release 1.0 I suspect
[13:35] <zyga> attente: though there will be less changes made now
[13:35] <zyga> attente: you can expect additions rather than changes
[13:39] <jdstrand> zyga: fyi, there are checks that the review tools need to do in the absence of assertions
[13:40] <zyga> jdstrand: perhaps but I don't know what the plan is for that
[13:40] <jdstrand> zyga: I will handle the review tools
[13:40] <jdstrand> dholbach: ^
[13:40] <zyga> jdstrand: thank you!
[13:41] <jdstrand> but there is no point in changing them atm until we have a working system
[13:41] <jdstrand> so, perhaps later this week
[13:41] <zyga> jdstrand: do you know where we are today?
[13:41] <jdstrand> not yet
[13:42] <zyga> jdstrand: we got auto-connection feature landed, also for x11 and unity7
[13:42] <zyga> jdstrand: I'm working on some tweaks to connection control so that it persistst properly and that users are in control
[13:43] <jdstrand> zyga: x and unity7 are autoconnecting? can you explain what you mean by autocontrol?
[13:43] <zyga> jdstrand: x11 (it was renamed)
[13:43] <zyga> jdstrand: it gets connected to os snap on install
[13:43] <jdstrand> I understand what that means
[13:44] <jdstrand> that also is a security hole
[13:44] <jdstrand> so we had the idea that there would be some sort of prompting
[13:44] <jdstrand> what happened with that?
[13:44] <jdstrand> beuno: ^ ?
[13:46] <zyga> jdstrand: there's no propmpting for that as there's no UI for install
[13:46] <jdstrand> I didn't mean an install prompt
[13:46] <zyga> jdstrand: oh?
[13:47] <jdstrand> what I suggested was no autoconnect on install. then on first use, prompt the user somehow, letting them know the app wants privileged access to the user's session. the user says yes or no. if yes, there is an interface connect
[13:47] <jdstrand> this prompt could be done via zenity, or anything really. mvo was in agreement on the approach
[13:47] <jdstrand> there is a card on the idea, but I think beuno was shopping it around
[13:48] <zyga> jdstrand: that's not realistic today
[13:48] <zyga> jdstrand: we'll improve it with SRUs
[13:48] <jdstrand> maybe not 'today' but interface connect is surely something for 16.04 release?
[13:48] <zyga> jdstrand: yes
[13:49] <mvo> jdstrand: quick question, we don't need ubuntu-core-security-{apparmor,seccomp,utils} anymore, correct?
[13:49] <jdstrand> so it should be realistic for 16.04 release
[13:49] <jdstrand> mvo: correct
[13:49] <mvo> ta
[13:49] <jdstrand> mvo: they should be removed from the archive too
[13:49] <zyga> jdstrand: there will be no prompting for 16.04
[13:49] <zyga> jdstrand: we can explore that after the release
[13:50] <jdstrand> zyga: why? who decided that? we are making announcements for this. where was this discussion?
[13:50] <zyga> jdstrand, mvo: FYI we only run apparmor_parser but templates seem to refer to included files
[13:50] <jdstrand> zyga: the prompt can be as simple as updated the shell script
[13:50] <jdstrand> zyga: the includes don't come from ubuntu-core-security. they come from apparmor
[13:50] <zyga> jdstrand: there are no APIs to implement the prompt
[13:50] <jdstrand> we don't need it
[13:51] <zyga> jdstrand: it's not just the UI
[13:51] <jdstrand> all we need is interface connect foo unity7
[13:51] <jdstrand> or whatever the api is
[13:52] <zyga> jdstrand: yes and that's not ready yet
[13:52] <zyga> jdstrand: I'm trying to get it ready
[13:52] <jdstrand> zyga: but you said a moment ago it would be for 16.04 release
[13:52] <zyga> jdstrand: auto connect is internal
[13:52] <zyga> jdstrand: connect/disconnect requires an API
[13:52] <jdstrand> I don't care about *today* so much as when someone tries to use this thing on release day, people see the choice
[13:53] <zyga> jdstrand: I'm trying to implement the API so that we can use it but it's not working as of this second yet
[13:53] <zyga> jdstrand: the goal is to get it working today (API) but I don't think we can manage a GUI at this stage
[13:59] <jdstrand> a gui is a zenity prompt
[13:59] <jdstrand> snappy sees if x11 or unity7 interface (or home) is requested. oh, it is, insert this zenity prompt in the shell script
[13:59] <zyga> jdstrand: can you implement one quickly? perhaps we can manage that?
[14:00] <zyga> jdstrand: note that there's a REST API there
[14:00] <jdstrand> I need beuno to confirm it is ok
[14:00] <zyga> jdstrand: so it's not a simple sequential client
[14:00] <jdstrand> zyga: where is the rest api?
[14:00] <zyga> jdstrand: you'd have to install the snap, inspect available plugs
[14:00] <zyga> jdstrand: deamon/api.go, the docs are in docs/rest.md
[14:01] <zyga> jdstrand: then see if your new snap has x11 or unity7 plug
[14:01] <zyga> jdstrand: and then offer a quick prompt (even without zenity, just a simple stdin prompt)
[14:01] <zyga> jdstrand: and then call .Connect()
[14:01] <zyga> jdstrand: note that there are GO bindings for the api (look at client/interfaces.go)
[14:01] <zyga> jdstrand: I think someone could look at doing that but I need to finish connect/disconnect first
[14:04] <zyga> jdstrand: also note that you need to work with cmd/snap/cmd_ops.go (AFAIR) because that's where install is
[14:04] <zyga> jdstrand, mvo: can tell you more
[14:04] <jdstrand> when I spoke to mvo before he said that he thought this was all managable. that was a few weeks ago
[14:05] <zyga> jdstrand: I thnk that explains it
[14:05] <zyga> jdstrand: there were many things that got us busy
[14:06] <jdstrand> sure, I understand
[14:06] <jdstrand> I'm not upset about that or anything-- I just want to make sure this is handled in some way
[14:08] <zyga> jdstrand: I understand, I'm sorry if I seem defensive :-) I'm just tired and we're all racing to get bits in place
[14:08] <jdstrand> no worries
[14:28] <jdstrand> mvo: can you ping me when you adjust the seeds for ubuntu-core-security?
[14:34] <dholbach> jdstrand, thanks
[14:34] <beuno> jdstrand, I'll follow up on the notify-when-x
[14:34] <jdstrand> thanks!
[15:06] <elopio> ogra_: any news about the new archs? I'm digging all the emails from yesterday but haven't seen anything.
[15:08] <ogra_> elopio, well i got no mails (probably olli forgot to forward something) ... but i have the rootfs snaps building (sadly they arent published yet because i still need to teach livecd-rootfs to not try to build kernel snaps for them)
[15:09] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ both fail right after creating the ubuntu-core os snap
[15:17] <elopio> the image PPA is still not building for s390x. mvo: can you enable that? or do you know who can?
[15:21] <elopio> noise][: can you help me with spi? I'm getting 401 checking for the results of the run I launched. https://paste.ubuntu.com/15793410/
[15:28] <mvo> cjwatson: who should I talk to about s390x builds for https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages ? is that something you could enable or do I need to ask IS? or can I do it myself if I find the right knob :) ?
[15:28] <mvo> elopio: I ask someone who knows everything ;)
[15:29] <mvo> elopio: I think I can not do it myself
[15:29] <noise][> elopio: hey.. that's odd
[15:29] <cjwatson> you can't do it yourself because s390x has no virtualised builders yet, so it lacks sandboxing
[15:30] <cjwatson> but I see that PPA is already devirtualised
[15:30] <cjwatson> mvo: done
[15:30]  * ogra_ cureses about livecd-rootfs code ....
[15:31] <cjwatson> mvo: new builds aren't auto-created, but if you want to create new builds of an existing source in that PPA without reuploading, you can copy the source over itself including existing binaries and that has the side-effect of creating missing builds
[15:31] <ogra_> feels like i painted myself into a corner, skipping kernel creation for one arch is really hard now :/
[15:31] <cjwatson> mvo: (also obviously only xenial, since s390x didn't exist before that)
[15:32] <mvo> cjwatson: \o/
[15:32] <mvo> cjwatson: thanks a bunch
[15:34] <cjwatson> np
[15:34] <elopio> cjwatson: mvo: thanks!
[15:35] <ppisati> sergiusens: saw it
[15:35] <elopio> noise][: here in the dragonboard section is all I did, in case it helps: http://pad.ubuntu.com/spi
[15:35] <ppisati> sergiusens: i'm a bit nervous about the 'snappy login' step, i bet there's no way to skip it
[15:36] <zyga> ppisati: snap login, snappy is gone
[15:36] <ppisati> zyga: snapcraft login i mean
[15:36] <zyga> ah
[15:36] <ppisati> zyga: what does it do btw?
[15:36] <zyga> ppisati: I'm not quite sure
[15:36] <ppisati> sergiusens: ^
[15:41]  * ogra_ guesses it logs you in
[15:42] <ogra_> :P
[15:43] <ppisati> ogra_: ok, but why it needs to log me into UU build a kernel/snap?
[15:43] <ogra_> heh, no idea ... i was just stating the obvious :P
[15:44]  * ogra_ doesnt even know where to it logs you in
[15:44] <ppisati> ah ok
[15:45] <ogra_> i assume "snapcraft snap" should still work without login though
[15:45] <ogra_> (it does on the livefs builders ... and we wouldnt be able to use any kind of login there(
[15:46] <noise][> elopio: can you try to query the results w/o the test opp query param?
[15:47] <noise][> just https://spi.canonical.com/products/$PRODUCT_ID/tests/events
[15:47] <ppisati> ogra_: nope, it requires the login
[15:47] <ppisati> http://pastebin.ubuntu.com/15794106/
[15:47] <ppisati> btw i thought 'snap' was the default target
[15:47] <ogra_> ppisati, well, it has to be skippable, else we cant build images
[15:48] <ogra_> zyga, sergiusens ^^^
[15:48] <ogra_> there is no way we can add credentials on the image builders, nor can they see the store
[15:49] <sergiusens> ogra_, ppisati the login is to download the os.snap. I wasn't sure it was possible to download without being logged in
[15:49] <ogra_> sergiusens, just grab it from cdimage :P
[15:49]  * zyga doesn't know what login is for in the long term, cannot comment
[15:50] <ppisati> sergiusens: does it store my credentials somewhere?
[15:51] <sergiusens> ppisati, yes, in the form of oauth; not the password
[15:52] <sergiusens> ppisati, ~/.config/snapcraft/snapcraft.cfg
[15:52] <ogra_> sergiusens, how would that work for i.e. a launchpad based build ?
[15:52] <sergiusens> it is only the kernel plugin
[15:52] <ogra_> where you simply dont have these credentials
[15:52] <sergiusens> ogra_, ^
[15:53] <sergiusens> only the kernel plugin
[15:53] <sergiusens> kernel plugin is experimental
[15:53] <ogra_> sure, but what stops me from using the kernel plugin ibn an LP build
[15:53] <sergiusens> nothing is set on stone
[15:53] <sergiusens> and as I said multiple multiple multiple multiple times
[15:53] <sergiusens> this download thing goes away as soon as snappy does the initrd dance the correct way
[15:54] <sergiusens> ogra_, ^ what stops you is the fact that you need to login
[15:54] <ogra_> (i doubt that will happen before next LTS :P )
[15:54]  * ogra_ is obviously very pessimistic wrt the SRU process of massive architectural changes :)
[15:58] <elopio> noise][: same result.
[16:00] <noise][> elopio: hmm, and is that repeatable? starting w/a new product?
[16:26] <elopio> noise][: let me try that.
[16:33] <elopio> noise][: I can't create it anymore. Now I get 401 on the first step.
[16:33] <elopio> oh, wait, no there was a typo.
[16:33] <elopio> going on...
[16:35] <sergiusens> zyga, I logged https://bugs.launchpad.net/snapcraft/+bug/1569452 since I am impatient
[16:36] <elopio> noise][: reproduced again, I created everything from scratch, made a POST on the images endpoint and got 201. But when I query the tests/events, I get 401.
[16:46] <noise][> elopio: ok, I don't have time to dig at the moment, but can try to repro later this afternoon
[17:16] <sergiusens> jdstrand, zyga can you check if I made as "an accurate as possible" translation of things here https://github.com/ubuntu-core/snapcraft/pull/441/files
[17:16] <sergiusens> I am aware some things will just not work
[17:17] <sergiusens> like busybox which would need a read_path of / at least
[17:17] <zyga> looking
[17:18] <sergiusens> not sure what `network-management` was for, I hope it was covered by `network-bind` and also not sure I need `network` if I have `network-bind`
[17:18] <kyrofa> sergiusens, I was just about to ask that question :P
[17:18] <sergiusens> nor if `network-service` is covered in any way
[17:19] <kyrofa> network-service is now network-bind, I believe
[17:19] <sergiusens> my gut says it would
[17:19] <sergiusens> or anything needing network-bind would need network
[17:20]  * sergiusens is sad for removing all those tests though
[17:20] <zyga> sergiusens: network-management is more like "I want to be network-manager"
[17:20] <zyga> network == client; network-bind == server)
[17:21] <sergiusens> zyga, ok, so for something that listens on a port and also talks to the network I need both?
[17:21] <zyga> it won't hurt
[17:21] <zyga> but I suspect network-bind gives you network
[17:21] <zyga> jdstrand: can clarify
[17:21] <sergiusens> zyga, I'll wait for your first pass
[17:21] <zyga> we should add those kind of FAQs to the docs :/
[17:21] <zyga> sergiusens: I reviewed it already
[17:22] <sergiusens> oh; yeah, the docs aren't really all that complete ;-)
[17:23] <sergiusens> zyga, the mosquitto one, elopio can you look ^
[17:23] <sergiusens> zyga, if you look at how the listener plug is defined it seems to indicate it needs `network` and not `network-bind`
[17:23] <zyga> sergiusens: sorry, I'm so drained today I feel like I'm about to fall asleep right here;
[17:24] <zyga> my comments were based purely on the names
[17:29] <jdstrand> sergiusens: network-management was network-admin on 15.04
[17:29] <jdstrand> sergiusens: it is network-control now
[17:30] <jdstrand> sergiusens: network-bind and network client are not the same. network-bind currently gives you all of network, but there is no guarantee that will always be the case
[17:35] <kyrofa> jdstrand, good to know, thank you
[17:36] <sergiusens> jdstrand, ok, so my shout client I should add network and network-bind (basically a web irc bouncer)
[17:36] <sergiusens> shout app (not client)
[17:37] <jdstrand> sergiusens: gopaste technically would need network-control for a 1-1 mapping, but I think gopaste is suffereing from bug #1465724
[17:38] <jdstrand> sergiusens: I would, yes
[17:38] <sergiusens> jdstrand, yeah, most likely the case for gopaste
[17:38] <jdstrand> sergiusens: it is safe to leave network-control out for gopaste and just live with the denial until we can fix the kernel
[17:38] <sergiusens> jdstrand, what is your suggestion for it?
[17:38] <sergiusens> ok
[17:38] <jdstrand> tyhicks: iirc, that is the current recommendation, right? ^
[17:38] <tyhicks> jdstrand: yes
[17:39] <tyhicks> I think I know the proper fix for the denial now
[17:40] <tyhicks> I'll have another look at it soon
[17:40] <jdstrand> tyhicks: oh nice :)
[18:02] <dholbach> elopio, thanks for the update on bug 1569478 and everything
[18:11] <attente> are there any plans to add some api for extracting the metadata out of a snap that isn't yet installed?
[18:12] <kyrofa> attente, a store API already exists. Are you talking about a local snap, though?
[18:12] <attente> kyrofa: yeah, for sideloading
[18:13] <kyrofa> attente, not that I know of, but feel free to log a wishlist bug for it
[18:13] <attente> kyrofa: sure, thanks
[18:13] <ogra_> You can mount the snap or use unsquashfs to get the snap.yaml
[18:15] <ogra_> (it is just a squashfs file after all)
[18:15] <kyrofa> ogra_, hardly an API, but yeah
[18:16] <kyrofa> attente, if you're just scripting something, that may be a good direction
[18:16] <ogra_> Well, yaml iis kind of an api :P
[18:16] <kyrofa> ogra_, hahaha
[18:17] <kyrofa> attente, may I specifically call your attention to `unsquashfs -e`
[18:18] <kyrofa> attente, even more specifically: `unsquashfs -e meta/snap.yaml`
[18:18] <attente> yeah, i was just wondering if maybe there should be some friendlier tooling for it
[18:18] <attente> kyrofa: cool
[18:18] <kyrofa> attente, can you explain your use-case?
[18:18] <kyrofa> attente, though I guess you should do that in the bug anyway-- no need to make you repeat yourself :)
[18:19] <attente> heh
[18:36] <oparoz> Is it possible to merge unsquashed snaps and resquash the result?
[18:37] <beuno> oparoz, you'd have to unpack them, and re-pack them
[18:37] <beuno> what are you trying to do?
[18:37] <oparoz> beuno build parts on different machines
[18:47] <sergiusens> zyga, seems even after changing to interfaces I still have failing tests
[21:07] <jdstrand> meh, the security policy is messed up for the path renames
[21:07] <jdstrand> $ focuswriter.run
[21:07] <jdstrand> mkdir: cannot create directory ‘/home/jamie/snap/focuswriter’: Permission denied
[21:07]  * jdstrand takes a look
[21:07] <tsimonq2> can I make a snap part that just consists of a package from the Ubuntu archives?
[21:07] <tsimonq2> or does it *have* to be from source?
[21:11] <jdstrand> oh no, that wasn't hit. I hit the old ~/snap owned by root bug
[21:11] <jdstrand> sigh
[21:11] <jdstrand> but the path rename broke the apparmor system unit
[21:12] <jdstrand> tyhicks: hey, have you uploaded already?
[21:12] <jdstrand> we need better integration tests
[21:13] <tyhicks> jdstrand: I haven't yet
[21:14] <jdstrand> tyhicks: ok, can you add a super-quick change? just need to update a path. let me get you a bug and details
[21:14] <tyhicks> jdstrand: yes, this is good timing
[21:19] <jdstrand> tyhicks: https://bugs.launchpad.net/snappy/+bug/1569573
[22:16] <oparoz> Is SNAP_FULLNAME going away?
[23:01] <tyhicks> jdstrand: uploaded
[23:48] <sergiusens> jdstrand, tyhicks is that also the reaosn for what I pastebined not working?
 zyga, jdstrand it seems that with these new interfaces I can't create files in SNAP_DATA http://paste.ubuntu.com/15800694/
[23:48] <sergiusens> that just in case ^
[23:49] <zyga> sergiusens: thanks for noticing this. I don't recall us removing this explicitly. I will look at the apparmor template we use
[23:50] <zyga> I see
[23:50] <zyga> looks like another victinm of moving files around
[23:54] <zyga> sergiusens: https://github.com/ubuntu-core/snappy/pull/910
[23:55] <zyga> after the dust settles we should use ... variables for that :P


[00:40] <tinman> when i click on the Help icon in app launcher, i get a 404 page
[00:40] <tinman> 12.04.3
[00:41] <holstein> tinman: what can we help you with?
[00:43] <tinman> make the 404 page go away
[00:44] <tinman> or make the help icon do something more helpful
[00:44] <holstein> tinman: it does, friend..
[00:44] <holstein> tinman: what is the address?
[00:44] <tinman> /usr/share/ubuntustudio-docs/
[00:45] <tinman> non existent
[00:45] <holstein> tinman: thats a local file
[00:45] <tinman> and that folder is not there
[00:45] <tinman> fresh install
[00:45] <holstein> tinman: i wouldnt lose sleep over it.. things change, and get blown out when you upgrade packages.. and we have had lots of changes migrating
[00:45] <tinman> i just added vlc, k3b and kdenlive
[00:46] <tinman> so i should make my own help page for this machine?
[00:46] <holstein> you can change whatever you are clicking on to point at https://help.ubuntu.com/community/UbuntuStudio
[00:46] <holstein> you can add a help file to that location
[00:46] <holstein> tinman: you can just come here, as you did, and ask if you need help
[00:46] <tinman> but the icon is not for me
[00:46] <tinman> so ill point it there
[00:47] <holstein> tinman: OK.. then do the above for whomever
[00:47] <holstein> tinman: i hear what you are saying, and i understand something you are clicking on is not working.. but, all i can do is suggest workarounds and fixes
[00:47] <holstein> !bugs
[00:48] <holstein> you can file a bug.. if you need help, i glad to help you.. and im sorry you have found a missing help doc..
[00:48] <tinman> is that folder something that can be installed from repo?
[00:48] <holstein> tinman: its something that should
[00:49] <holstein> just work
[00:49] <holstein> tinman: i'll have to fire up my 12.04 and see.. what button are you hitting where?
[00:50] <holstein> tinman: what would be great is if you confirmed it, and filed a bug, with specifics. then, we can reference it and get the issue addressed
[00:50] <tinman> just above Log Out in the launcher menu is the Help icon. it's broken
[00:50] <holstein> tinman: so, in the main menu, you click on what? the image of the user? and click "help"?
[00:51] <tinman> app launcher (the one in the upper left with the Studio logo) -> i click on Help which has a question mark icon. it open firefox which returns a 404
[00:52] <holstein> tinman: have you filled a bug?
[00:52] <tinman> i go to that location in nautilus and the folder isn't there
[00:52] <tinman> not yet
[00:52] <tinman> igonna confirm it on another machine
[00:54] <tinman> confirmed
[00:54] <tinman> what do i file the bug against?
[00:54] <holstein> tinman: go ahead and file it.. i would just do a workaround for the intended user though
[00:55] <tinman> ubuntu studio main?
[00:55] <holstein> tinman: sure
[00:55] <holstein> something studio specific
[01:06] <tinman> filed
[01:09] <holstein> tinman: link it here, and i'll talk it around the dev channel.. but you should not expect a fix
[01:11] <tinman> im using the https://help.ubuntu.com/community/UbuntuStudio link for now.   bug filed here: https://bugs.launchpad.net/ubuntustudio/+bug/1236111
[02:10] <caodepalha> hi everyone! Is there a way to save all the settings of a session? For example, if I have a session with  a midi synth, guitarix, sooper looper all conected to ardour do I have to open and connect everything everytime? or can all the programs and connections be saved?
[14:36] <carlostorres1975> Hello, I been using ustudio since some time just waiting to really learn to use it, so here I m lastly... Mi primary interest is to record my songs form (sorry) Guitar Pro with RSE (samplers) into a good mixed sound with my voice... so please send me whatever i have to...
[14:37] <carlostorres1975> : )
[14:37] <smartboyhw> carlostorres1975, read https://help.ubuntu.com/community/UbuntuStudio first?
[14:38] <carlostorres1975> ok im on it!
[14:42] <cfhowlett> smartboyhw, I worked up a new wallpaper http://ubuntuone.com/14PqUXQMhIP9yqRXxyv9AP
[14:42] <cfhowlett> from the archives of proposed but unused US wallpapers
[14:42] <smartboyhw> cfhowlett, good job!
[22:07] <escalpelo> Ubuntu studio running on surface pro 2?
[22:21] <Sakrecoer> escalpelo: any other ubuntu running on surface pro 2?
[22:21] <Sakrecoer> if yes, it might work...
[22:22]  * Sakrecoer is looking in his pocket for some more cents...
[22:22] <Sakrecoer> http://askubuntu.com/questions/265644/dual-boot-surface-pro-with-ubuntu
[22:23] <escalpelo> what a nice theme for the boot loader
[22:27] <Sakrecoer> agreed! aparently, you can even put your  own favorit picture in the universe :) https://github.com/webbrandon/Surface-Boot-Themes/
[22:29] <Sakrecoer> but personaly, i never see the bootloader  splash. i use one system :) and its done booting before my screen is lit. :D
[22:29] <Sakrecoer> ubuntustudio of course :)
[22:31] <Sakrecoer> escalpelo: if you can install ubuntu, you can use a package manager to add everything that comes with ubuntustudio.
[22:33] <escalpelo> I've tryed ubuntu studio
[22:33] <escalpelo> on a normal PC
[22:34] <escalpelo> and also installed Ubuntu and turned into ubuntu studio, I was wondering about Studio on Surface because of the Microsoft efforts to make it compete with iPad in music area
[22:50] <Sakrecoer> to me, anything that can install another os than dictated by the constructor is the most comptetitve device. except in some rare synthesizer cases :D
[22:51]  * Sakrecoer should be sleeping actualy :)
[22:52] <Sakrecoer> goodnight escalpelo and best of luck!!!!! :)
[22:53] <escalpelo> good night Sakrecoer


[07:05] <dholbach> good morning
[15:41] <Laney> git-svn clone is one seriously slow operation
[15:41] <Laney> I should have done it locally on alitoh


[18:09] <ibeardslee> morning
[19:53] <olly> morning
[21:39] <hads> morning
[21:44] <ibeardslee> hads: so finally the Pi3 on the way?
[21:44] <ibeardslee> will you have stock, or just covering backorders?


[08:02] <hrw> morgen
[12:39] <furibondox> hello everybody
[12:40] <furibondox> I'm trying to use rootstock on ubuntu lucid but I have a blocking problem...
[12:40] <furibondox> anybody have a suggestion?
[12:41] <furibondox> the error is: /usr/bin/rootstock: line 282:  6890 Segmentation fault      qemu-system-arm $QEMUOPTS -append "${APPEND}" > $QEMUFIFO 2>&1
[12:41] <furibondox> it seems a problem related to qemu itself...
[12:46] <furibondox> anybody use rootstock from ubuntu lucid?
[13:00] <furibondox> anybody use rootstock with ubuntu lucid?
[13:30] <vstehle> furibondox: You may want to report this into launchpad.
[13:31] <furibondox> vstehle: I've just reported... https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 (item 13)
[13:32] <ubot2> Launchpad bug 570588 in rootstock (Ubuntu) (and 1 other project) "qemu-system-arm can not handle more than 256M in versatile machine mode using the -m option (affects: 2) (heat: 53)" [Undecided,Invalid]
[13:33] <furibondox> I just would like to know if someone experienced the same behaviour and have found a solution/workaround...
[13:34] <ogra> if you see the exact same bug, just revert your changes to the rootstock script
[13:40] <furibondox> ogra: which change?
[13:40] <ogra> furibondox, did you read the bug before commenting ?
[13:40] <furibondox> yes
[13:41] <ogra> its about someone who hacked his rootstock script to use 512M
[13:41] <ogra> so revert that and it will work
[13:42] <furibondox> I've also tried to use 512M changing the rootstock script but it fails again
[13:43] <ogra> well, qemu cant use 512M
[13:43] <ogra> thats what the bug is about
[13:44] <furibondox> sorry ogra, I know that but I've read some bug report on google describing the same error but in different threads... and I took the 570588 to add a comment
[13:45] <furibondox> may be is not the more approriate item opened
[13:45] <ogra> well, if you changed the script to use 512M thats the bug, if you didnt, its not that bug and should be filed as a new one
[13:47] <furibondox> I tell you my tests: 1) with 512M 2) with 256M 3) with more seeds 4) with only one seed
[13:47] <furibondox> the result is the same
[13:48] <ogra> and you are onyl using packaged versions of rootstock, qemu and friends ?
[13:48]  * ogra knows that pleanty of people use rootstock under lucid and it works for them
[13:50] <berco> ogra: just to let you know that your udev script worked fine in the end. Can't think I told you.
[13:51]  * ogra hugs berco
[13:51] <ogra> perfect !
[13:57] <furibondox> yes ogra, all my packages (qemu, rootstock, debootstrap etc) come from the lucid repository
[13:57] <ogra> in your pm you used rootstock-native, thats definately not packaged
[13:59] <furibondox> yes sorry... it was just a test...
[14:01] <furibondox> ii  rootstock                                  <IP_ADDRESS>-0ubuntu1                               shellscript to create armel rootfs tarballs
[14:02] <furibondox> May be there's something wrong with my command line?
[14:03] <furibondox> sudo rootstock -f NGP --seed setserial,openssh-server,ubuntu-minimal -i 1G --serial ttyS2 --doswap --swapsize 256 --restore-package-cache
[14:03] <ogra> setserial should be included in ubuntu-minimal, beyond that all looks fine
[14:03] <ogra> and adding setserial shouldnt cause issues
[14:03] <furibondox> ok
[14:04] <furibondox> but, as far as you know, do you think that is a qemu problem or rootstock problem?
[14:05] <furibondox> if you think that is a rootstock problem I can try to uninstall/re-install qemu and try again
[14:05] <furibondox> what do you think?
[14:07] <ogra> well, qemu segfaults
[14:07] <ogra> its definately not a rootstock problam
[14:07] <ogra> *problem
[14:08] <furibondox> ok
[14:08] <furibondox> I try to remove all and reinstall
[14:09] <ukleinek> ogra: it's not long ago when I told you how to spell definitely :-)
[14:10] <ogra> ukleinek, i blame the heat
[14:10]  * ogra melts slowly
[14:10] <ukleinek> ogra: so Berlin is hot, too?
[14:10] <ogra> ukleinek, kassel here
[14:10] <ogra> 28°C in my office, 36°C outside
[14:10] <ukleinek> ogra: oh, Kassel, I thought you'd live in Berlin
[14:11] <ukleinek> ogra: similar here
[14:11] <ogra> i'd love to ... (who wants to live in kassel anyway)
[14:11] <ukleinek> ogra: so why do you?
[14:11] <amitk> b-----i------g house
[14:11] <ogra> free living :)
[14:11] <amitk> :-p
[14:12] <ogra> no rent, solar heating system ... major cost factor :)
[14:12]  * ukleinek has a solar heat here for free, too
[14:13] <furibondox> ogra: I'm retring...
[14:16] <rsalveti> morning
[14:21] <rsalveti> hm, another qemu segfault
[14:21] <rsalveti> interesting that this is happening with lucid
[14:22] <rsalveti> ogra: was finally able to create the rootfs as user, but still have many issues to solve
[14:22] <ogra> rsalveti, might be realted to amd64 systems
[14:22] <ogra> rsalveti, good to hear :)
[14:22] <rsalveti> first, fuseext2 is incredibly  unstable =\
[14:23] <rsalveti> I can create the same image many times, just with 'ro', and get different results everytime
[14:23] <rsalveti> lots of files get the wrong size and data
[14:24] <rsalveti> so just after running the second stage, to be able to test, I mounted as loop, until we get this solved
[14:24] <ogra> k
[14:24] <rsalveti> ogra: but my biggest problem is the seg fault that I'm getting most of the time
[14:24] <ogra> qemu segfault too ?
[14:24] <rsalveti> ogra: yep :-(
[14:24] <ogra> crap
[14:24] <rsalveti> just after running the second stage
[14:24] <ogra> x86 or amd64 ?
[14:24] <rsalveti> amd64, this could be the issue
[14:24] <ogra> yeah
[14:24] <rsalveti> will try on x86 to see
[14:25] <lag> sebjan: Ping
[14:25] <rsalveti> ogra: see comment 54 on bug 532733
[14:25] <ubot2> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 7) (dups: 1) (heat: 79)" [High,Incomplete] https://launchpad.net/bugs/532733
[14:25] <ogra> rsalveti, that bug isnt about segfaults
[14:26] <rsalveti> yeah, I know
[14:26] <rsalveti> but many people reported about the segfault while trying to reproduce it
[14:26] <ogra> that bug slowly turns into a mess :(
[14:26] <rsalveti> that's why I posted there, cause it can be similar to what people was getting
[14:26] <rsalveti> bug for sure, it's different
[14:26] <ogra> the hang doesnt produce any segfaults at all
[14:27] <rsalveti> ogra: are you using x86?
[14:27] <ogra> upstream already refused to look at it because of the confusing comments
[14:27] <ogra> yes
[14:27]  * rsalveti wasn't able to get just the 'hang'
[14:27] <rsalveti> oh, ok
[14:28] <ogra> the hang only shows up if you install a big task like ubuntu-desktop or ubuntu-netbook
[14:28] <ogra> dpkg hangs at some point
[14:28] <rsalveti> ogra: yeah, but I'm getting the seg fault before that :-), but I'm using amd64
[14:28] <ogra> your segfault seems userspace related
[14:28] <rsalveti> will see with x86
[14:32] <furibondox> ogra: same error: http://pastebin.ca/1898986 :-(
[14:32] <rsalveti> furibondox: how are you calling rootstock?
[14:33] <furibondox> sudo rootstock -f NGP --seed openssh-server,ubuntu-minimal -i 1G --serial ttyS2 --doswap --swapsize 256 --restore-package-cache
[14:33] <furibondox> from ubuntu lucid
[14:33] <furibondox> all packages (qemu, rootstock, etc...) came from the lucid repository
[14:34] <rsalveti> furibondox: are you running on x86 or amd64?
[14:34] <furibondox> x86
[14:34] <rsalveti> furibondox: ok, can try to reproduce it here, but many people did run rootstock without this issue on lucid
[14:35] <furibondox> the only unusual component is that my lucid x86 runs under vmware
[14:35] <ogra> heh
[14:36] <rsalveti> :-)
[14:36] <ogra> thats probably something you should have told in the beginning :)
[14:36] <ogra> not sure if qemu can run inside vmware
[14:36] <rsalveti> yeah, could be the problem
[14:36] <furibondox> some times ago I tested qemu inside vmware w/o problems
[14:37] <ogra> i know qemu cant run inside a kvm instance
[14:37] <ogra> or insice vbox
[14:37] <ogra> *inside
[14:37] <lool> ogra: uh?
[14:37] <lool> I thought qemu could work just fine in kvm
[14:37] <ogra> lool, can it now ?
[14:37] <ogra> soren told me it cant
[14:37] <lool> First time I heard it can't
[14:38] <lool> You cant use qemu acceleration though
[14:38] <ogra> so i never bothered to try to stack qemu instances
[14:38] <ogra> hey asac
[14:38] <lool> You can't run kvm in QEMU though
[14:38] <asac> omg
[14:38] <asac> the heat is on
[14:38] <ogra> warm here, eh ?
[14:38]  * ogra grins
[14:39] <furibondox> ok... so your suggestion is to try within physical ubuntu installation, right?
[14:39] <rsalveti> furibondox: yep, I'm trying it here on x86 with your command line
[14:39] <ogra> if you have one around, i would suggest that
[14:40] <furibondox> tnx rsalveti
[14:46] <sebjan> lag: pong
[14:46]  * ogra goes to find some icecream
[14:46] <lag> sebjan: HI
[14:46] <lag> Hi*
[14:46] <lag> What's the latest with the Syslink driver?
[14:46] <lag> Is it going to make our build?
[14:47] <sebjan> I have tested with your last patch update, and could see that the modules where automatically loaded, as expected
[14:48] <sebjan> we have no solution yet for the issues when it is built as modules. We may have to re-test with syslink v2 and debug on this version rather than on the current one
[15:02] <furibondox> rsalveti: can you tell me if the building is finished without errors?
[15:02] <rsalveti> furibondox: still going
[15:03] <rsalveti> going to run the full vm now
[15:03] <furibondox> ok
[15:05] <lag> sebjan: Thanks for the update
[15:06] <lag> sebjan: Do any of your chips have parallel ports?
[15:17] <vstehle> lag: I don't think we have parallel ports in the OMAP per se, but it can be "emulated" with GPIO if needed.
[15:25] <furibondox> rsalveti: is finished now?
[15:26] <rsalveti> furibondox: not yet, but it's just finishing the full emulation part, no crash until now
[15:26] <furibondox> good
[15:31] <lool> ogra: Hey
[15:32] <ogra> lool, yup
[15:32] <lool> ogra: Do you folks intend to include x-loader + u-boot in omap pre-installer images?
[15:32] <lool> *pre-installed
[15:32] <ogra> yep
[15:32] <lool> ogra: Ok; is this tracked in a bug/blueprint somewhere?
[15:33] <ogra> err, sorry, was distracted
[15:33] <ogra> we *do* already include both
[15:34] <lag> vstehle: Thanks, but there's no need. The parport_pc driver is crashing your devices.
[15:34] <ogra> lool, https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
[15:34] <ogra> lool, "Change armel+omap debian-cd scripts to create a two partition image with first partition being vfat with proper bootloader setup"
[15:36] <lool> ogra: Hmm
[15:36] <ogra> lool, dailies are here: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ (still lacking web indicies, manifest and proper md5sum stuff, but its on teh list)
[15:36] <lool> ogra: Yes, this didn't boot with qemu for me
[15:37]  * ogra never tried it with qemu
[15:37] <ogra> did you dd it to an SD card and ran qemu with it as hdd1 ?
[15:37] <lool> ogra: My ports-dev PPA has an updated package
[15:38] <ogra> you will definately need a real disk for it
[15:38] <ogra> since it tries to expand to the full disk size, it wont work if it cant expand to have free diskspace
[15:39] <ogra> we only leave 10M in the root partition that are eaten up ny the ext3fs journal
[15:39] <ogra> s/ny/by/
[15:39] <ogra> so even if you would get it to boot, it would need to be dd'ed to a bigger sized (i'd recommend 4G) image
[15:40] <ogra> lool, your qemu is omap3 i guess, we only include the actual beagleboard MLO in the image atm
[15:40] <lool> ogra: I did a bunzip2
[15:40] <lool> and ran it with qemu -sd
[15:40] <ogra> so if you dont strictly emulate a beagle that might be the prob
[15:41] <lool> ogra: My QEMU boots the Angstrom beagleboard image somewhat
[15:41] <lool> Well into kernel boot messages for instance
[15:41] <ogra> and ours ? where does it stop ?
[15:41]  * ogra is in the process of updating to x-loader 1.4.4 from 1.4.3 ... probably that helps
[15:42] <ogra> i didnt touch the omap3 stuff since pre-A2 but it definately works on real HW
[15:42]  * ogra focuses on omap4 atm
[15:43] <ogra> lool, angstrom images are not partitioned, they are tarballs, no ?
[15:44] <hrw> ogra: they are
[15:44] <ogra> unless something changed significantly recently
[15:44] <hrw> ogra: you mean 'narcissus' ones I assume
[15:45] <ogra> hrw, no idea what lool used above for qemu tests
[15:45] <hrw> neither do I
[15:46] <ogra> i know for sure our images work on actual HW and i would have never gotten the idea to try one of them in qemu :)
[15:46] <ogra> especially since its quite some hassle you have to do with the image sizing
[15:46] <ogra> if you dont actually dd to an SD card
[15:47] <lool> ogra: No, it's a partitioned SD card image
[15:47] <lool> Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.sd-image-2GiB.img1  *           1           9       72261    c  W95 FAT32 (LBA)
[15:47] <lool> Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.sd-image-2GiB.img2             10<PHONE_NUMBER>+  83  Linux
[15:47] <ogra> where did you get that ?
[15:47] <ogra> i only know the tarballs
[15:47] <hrw> I know that OE can generate any type of image
[15:47] <ogra> the partitioning seems to be identical to ours though
[15:48] <ogra> and since we use the same code i bet it actually is :)
[15:48] <ogra> so the only difference can be xloader or uboot if you dont get any serial output
[15:49] <ogra> our omap3 x-loader package is still at 1.4.3 with the XM patches on top ... in 1.4.4 the XM patches are included, i'll update it this week
[15:49] <ogra> lool, so try an image from the end of this week
[15:50] <ogra> so we can exclude MLO here
[15:50] <ogra> its my only explanation
[15:50] <ogra> lool, you can also try to replace the binaries in the vfat and see
[15:51] <rsalveti> furibondox: yep, no problem
[15:51] <rsalveti> furibondox: same arguments
[15:51] <rsalveti> furibondox: vmware can be your problem
[15:51] <furibondox> thank you very much rsalveti
[15:51] <rsalveti> np
[15:52] <furibondox> I will try with a native ubuntu installation
[15:52] <lool> ogra: I tried the image from yesterday evening
[15:52] <ogra> lool, cant be, the livefs builder was broken since thu :)
[15:53] <furibondox> rsalveti: I've a question... do you have tested with a lucid?
[15:53] <lool> ogra: I grabbed the "current" image from yesterday
[15:53] <lool> it might be a stale one
[15:53] <ogra> lool, as i said above, i'll update x-loader-omap3 this week
[15:53] <lool> ogra: Ok, thanks
[15:53] <ogra> until then try to replace the binaries in our image witrh the angstrom ones
[15:53] <ogra> and see if it boots then
[15:54] <rsalveti> furibondox: yep
[15:54] <ogra> our vfat is exactly 9 clinders and "W95 FAT32 (LBA)" so there shouldnt be a difference apart from MLO and uboot
[15:55] <furibondox> rsalveti: can you also send me the output of a dpkg -l of your pc?
[15:55] <rsalveti> furibondox: 10.04.1
[15:55] <rsalveti> furibondox: sure, 1 sec
[15:55] <furibondox> I leave my email in pm
[15:55]  * ogra takes a break and hunts for more icecream
[15:57] <rsalveti> furibondox: http://paste.ubuntu.com/462558/
[15:58] <furibondox> tnx
[16:40] <hrw> lag: did you got working screen finally on panda?
[16:41] <lag> Nope
[16:41] <lag> TI are working on it
[16:41] <lag> I've been working on something else
[16:41] <hrw> lag: maybe http://gitorious.org/pandaboard/kernel-omap4/blobs/L24.6_panda/drivers/video/omap2/dss/hdmi.c  will help you to find working hdmicode value
[16:42] <ogra> or http://omappedia.org/wiki/Bootargs_for_enabling_display
[16:42] <ogra> we had all that in the dicussing last week :)
[16:43] <ogra> *discussion
[16:43] <hrw> ;)
[16:43] <lag> Finding a working hdmicode is not the issue
[16:43] <ogra> right
[16:44] <lag> When I use sysfs almost all of them work for me and my monitor
[16:44] <lag> When I use the cmdline arguments, the best I can hope for is a fuzzy screen and an "out of range" message from my monitor
[16:45]  * ogra just thinks its a matter of the right glasses
[16:45] <ogra> they should just ship them with the boards ;)
[16:55] <fjrivash> Hello, I am following these instructions to get a rootfs for ARM https://wiki.ubuntu.com/ARM/RootfsFromScratch, I compiled a kernel and generated a zImage, when I try to run qemu (as specified in the tutorial) I got a black screen, I tried adding -d options file.log at the end of the command to get the output but I got nothing, am I missing something?
[16:55] <fjrivash> I changed the -cpu option for amr11mpcore,
[16:55] <fjrivash> thanks in advanced :D
[16:58] <ogra> fjrivash, for which release are you building your rootfs ?
[16:58] <fjrivash> lucid
[16:58] <ogra> wont run with arm11mpcore
[16:58] <ogra> lucid is built for armv7
[16:59] <ogra> arm11mpcore is an extended armv6 as i understand it
[16:59] <fjrivash> ohhh I see.
[17:00] <fjrivash> Yes it is compatible with armv6kz
[17:00] <ogra> use the binary kernel from the tutorial
[17:01] <fjrivash> well see : I did the first step of this section "Building a root filesystem image instead of a tarball" and after that compiled my own kernel and tried booting : it did not work. After that I got that image and is the same, that is why I am asking.
[17:03] <fjrivash> is there a way to build a rootfs of a release wich support armv6 (or compatible) using rootstock?
[17:04] <GrueMaster> fjrivash: Try using Karmic or Jaunty.
[17:04] <GrueMaster> Otherwise you are kind of stuck with debian.
[17:04] <ogra> karmic supports v6
[17:05] <fjrivash> Ok. i will try with them :D great!. Thank you (both) very much :D
[17:16] <fjrivash> I have been reading different documents about this topic and some of them says that you need to specify initrd in qemu command line, is it necessary?, I am not pretty sure about that, thanks in advanced again
[17:19] <Apaisal> hello all
[17:26] <rsalveti> ogra: hm, same seg fault on x86 =\
[17:26] <rsalveti> will try to debug it now
[17:27] <suihkulokki> lool: committed and pushed to gitorious
[17:27] <htc>  I wana to do  same her   http://nexusonehacks.net/nexus-one-hacks/how-to-install-ubuntu-on-your-nexus-oneandroid/  whit another version of ubuntu but I don't know how  bullied an arm img of it it there any doc can help
[17:30] <hrw|gone> htc: try karmic
[17:31] <htc>  <hrw|gone> how
[17:32] <hrw> htc: no idea, never played with chroot on mobile devices
[17:32] <hrw> and I do not like idea of 'run ubuntu/debian/fedora/anyotherdistro in chroot and tell everyone that you run it'
[17:33] <hrw> chroot is chroot... if people boot that distro then I will say that they managed to do something worthy
 no , what I want is the way to builded from scratch there is any doc can help
[17:35] <hrw> htc: you rather want to get rootfs for ARM rather then start from scratch
[17:35] <htc>  yep  like this exmple http://nexusonehacks.net/nexus-one-hacks/how-to-install-ubuntu-on-your-nexus-oneandroid/ in order to run it on an android device
[17:36] <hrw> so use rootstock
[17:36] <htc> like her https://wiki.ubuntu.com/ARM/RootfsFromScratch
[17:37] <hrw> yes
[17:38] <htc> I will need any thing else after I build the ARM img
[17:39] <hrw> htc: ask nexusonehacks.net guy?
[17:39] <hrw> hi prpplague
[17:40] <prpplague> hrw: greetings earthling
[17:41] <htc> ok  men I will
[17:41] <htc> & tnx
[17:54] <lool> ogra: is LP #589624 still an issue for you?
[17:54] <ubot2> Launchpad bug 589624 in linux (Ubuntu) "[Maverick] omap flavour does not work on beagle XM board (affects: 1) (heat: 97)" [High,Triaged] https://launchpad.net/bugs/589624
[17:54] <lool> suihkulokki: Thanks
[19:31] <ogra_cmpc> lool, yes, thats the main reason why i update the x-loader package
[19:31] <ogra_cmpc> lool, apparently it works on *some* XMs
[19:32] <ogra_cmpc> i'm hoping updating x-loader makes it work on all
[19:32] <ogra_cmpc> (recommendation from #beagle)
[21:18] <ukleinek> npitre: thanks for your mails, great to have your support
[21:25] <zumbi> yeah! mv sh*t /dev/null
[21:27] <armin76> zumbi: what happened?
[21:27] <zumbi> armin76: nothing! spain won, we are champions! congrats! :)
[21:29] <zumbi> armin76: linus wants to remove defconfigs from arm and ppc, but ukleinek did a proposal (he did not like it, but it removes 200k lines of sh*t)
[21:34] <ukleinek> zumbi: :-)
[21:35] <ukleinek> user@host:/usr/bin$ ls sh*t
[21:35] <ukleinek> showcfont  showfont
[21:36] <zumbi> ukleinek: this is best than TV series anyway (also we have the hardfloat arm stuff) :)
[21:37] <ukleinek> zumbi: your sentence doesn't make it through my natural language parser :-(
[21:42] <zumbi> ukleinek: i meant that your thread at linux-arm@ is going to take long discussion (better to follow this thread than TV series - I have no TV at the moment -). We, as distro, also have long thread on having an arm hardfloat port, which it is involving upstream and it seems that lot of people is interested, but they need to workout mechanisms (on the upstream side)
[21:42] <ukleinek> ah
[21:42] <zumbi> ukleinek: It seems that it is time to put some order in the ARM trees (linux+rootfs)
[21:43] <ukleinek> zumbi: there is definitly potential for more order, yes
[21:44] <ukleinek> still, I leave for bed now and will recheck tomorrow for the outcome of the discussion
[21:44] <zumbi> Sure, it'll take a while to put all bits in place
[21:44] <zumbi> g'night! and congrats for the good job :)
[21:44] <ukleinek> There is even potential for more code sharing across archs
[21:45] <ukleinek> zumbi: It was easy and I don't consider it "good", it's just nice and the best thing that currently works.  My main concern is to be able to continue build testing until a better solution is implemented
[21:46] <zumbi> ukleinek: sure, s,good,fast & effective, but you are the one that came up with the short term idea, for others to think on the long term one. :)
[21:47] <ukleinek> zumbi: if you check the changes I did to the ns9xxx_defconfig you see it's actually an old idea
[21:48] <ukleinek> This file was first reduced and then I added some symbols that I expected to be mainlined next
[21:48] <zumbi> uhm.. haven't check the changes.. but i worked with ns9215
[21:49]  * ukleinek is now really away
[21:49] <zumbi> bye
[21:49] <zumbi> i'll have a look
[22:13] <npitre> ukleinek: no problem
[23:30] <npitre> ukleinek: ... and it is in now ;-)
[23:32] <zumbi> linus is fast! I like it :)
[23:33] <zumbi> npitre: and rmk warns linus about adopting DT?
[23:33] <zumbi> or did I misunderstood?
[23:34] <npitre> zumbi: no, what RMK is refering to is not DT
[23:34] <zumbi> ah! I was thrilled about it
[23:34] <npitre> zumbi: we're working on various patches to eventually allow a single kernel binary to support multiple SOC families, and that is orthogonal to DT
[23:35] <zumbi> but I guess both approaches target the same problem
[23:35] <npitre> zumbi: not exactly
[23:36] <npitre> zumbi:  DT is about how to provide info to the kernel so it can configure itself even for yet-to-exist boards
[23:37] <npitre> zumbi: so DT will allow to reduce the per machine static configuration code
[23:37] <npitre> zumbi: but DT cannot solve the much bigger issue of being able to compile together support for more than one SOC
[23:39] <zumbi> which it is probably what RMK was talking about


[12:45] <jenda> dergringo: semi-pong
[12:45] <jenda> dergringo: I recommend email - i'm here for about a minute a day lately :(
[01:11] <popey> for uwn perhaps? http://news.bbc.co.uk/1/hi/technology/7034828.stm
[01:11] <popey> "Russian schools move to Linux"
[07:07] <dee> hello
[07:08] <dee> question concerning: http://fridge.ubuntu.com/node/1154 under which license are these entries? can we use the images in a translation? (I'm from the German Ubuntu LoCo-Team)
[07:12] <popey> well, they are hotlinked from other sites, so the tracker logo is (I suspect) whatever license Gnome use, the screenshot is on the wiki, so that is under whatever the wiki is under
[07:12] <popey> at a guess
[07:14] <dee> hm, I do not see the license of the wiki. :(
[07:15] <popey> CC-BY-SA I believe
[07:16] <dee> hm. okay. is the doumentation team responsible for the wiki? If so it should be cc-by-sa.
[07:16] <popey> hmmm
[07:19] <Daviey> hmm
[07:19] <Daviey> What does that mean then?
[07:22] <juliux> hi dee
[07:23] <dee> hi juliux.
[07:25] <popey> Daviey: I have no clue what _language_ it is, let alone what it says :)
[07:26] <juliux> dee, you can also ask the tracker team in #tracker on GimpNet
[07:26] <popey> heh, its chinese
[07:26] <popey> it means "Welcome to the"
[07:27] <dee> juliux: the tracker-teams knows which license fridge has?
[07:28] <juliux> dee, not the fridce but the logo and the screenshots;)
[07:30] <dee> the screenshot is from the ubuntu wiki (as mentioned by popey above). so the tracker team could only say what license the logo is. but it's a little bit ... eh, complicated to look in three resource for a licence.
[07:39] <juliux> hehe
[07:39] <juliux> always the same with licences;)
[07:40] <dee> juliux: I hate it. :(
[07:41] <juliux> dee, i can create an screenshot from tracker
[07:41] <juliux> -n
[07:44] <dee> juliux: I suppose someone in our team has gutsy too, so no need for it. but it would be easier if we could use the images.
[09:26] <beuno> popey, ping
[09:32] <popey> beuno: pong
[09:32] <popey> you got marks mail?
[09:32] <beuno> popey, when you see this, I got an email from Mark asking for some help to promote screencasts, so ping me back when you're around and let's see what I can do to help
[09:33] <popey> ok, thanks
[09:33] <beuno> but you're here now  :p
[09:33] <beuno> when does the month of screencasts end?
[09:33] <popey> there's a good question
[09:33] <beuno> maybe we can announce it in -news when it's over
[09:33] <beuno> a nice email
[09:33] <popey> well..
[09:34] <popey> the original intention was to run from 1st to 30th sept
[09:34] <beuno> full with information, and request for any collaboration you might need
[09:34] <popey> various personal circumstances coupled with me being pretty much the only person making them has put paid to that idea
[09:34] <popey> so what I'm doing it trying to get all 30 done before Gutsy releases
[09:35] <popey> once they are done, there will be 30 of them which .. well, I don't know what's next :)
[09:35] <popey> feedback would be the best thing!
[09:35] <popey> (help would be even better)
[09:35] <beuno> popey, so what do you think is best, wait for you to finish, or send something now and try and get some help?
[09:36] <popey> good question
[09:36] <popey> let me think about that and get back to you
[09:36] <dee> popey: could you explain Marks mail? Why do you launch another Month of Screencasts in 8 days? I thought the old "month" isn't over yet.
[09:36] <popey> he misunderstood
[09:36] <popey> he saw the gutsy countdown
[09:36] <popey> :)
[09:36] <beuno> popey, sure, I'll give it some more thought on how I can help you promote it, and if you can think of anything else I can do, let me know
[09:36] <dee> ah okay... I was a little bit confused. :)
[09:38] <popey> :)