[00:22] <tseliot> slangasek: sure, I'll do it tomorrow in the morning
[00:24] <slangasek> ok
[00:51] <superm1> jbarnes, pong
[02:45] <dhillon-v10> hi all, I am looking at some bugs in the xserver-xorg-video-intel section, and since I have similar drivers I can triage some bugs there, and set their importance, can anyone add me to the team so I can change the importance
[03:07] <bryyce> dhillon-v10, don't worry about setting the importance
[03:11] <dhillon-v10> bryyce, oh okay then :) that makes things easier for me
[03:15] <bryyce> dhillon-v10, help is always appreciated with the bug triaging.  I find I have a lot less time for doing it myself these days but it still needs done
[03:42] <dhillon-v10> bryyce, can you have a look at this: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/498287 should I ask the user to test against the latest version (2.6.3)
[03:45] <bryyce> dhillon-v10, because a lot of functionality that used to be in xserver-xorg-video-intel has moved to the kernel, it is often not sufficient to just have them test a newer version of that package
[03:45] <dhillon-v10> bryyce, so what do you advice in this case
[03:45] <bryyce> I mean, it couldn't hurt, but it's not likely to give them a fix
[03:46] <dhillon-v10> bryyce, okay :)
[03:46] <bryyce> dhillon-v10, well, first the patches he mentions are already in ubuntu.  So if they didn't fix it for him, then it's something else
[03:47] <bryyce> second, often these bugs are not due to something in the intel driver but due to something elsewhere in the system (the kernel maybe, or gnome-power-manager)
[03:49] <dhillon-v10> bryyce, I think it could be the kernel, because like you said a lot of functionality moved into the kernel so a commit must have broken something
[03:49] <bryyce> it would be interesting to know if it is a regression, and if so, if they can identify which piece of software solves it if downgraded
[03:49] <bryyce> so like booting to an older kernel if they have any in /boot might be interesting.
[03:52] <dhillon-v10> bryyce, ahh it could be a regression introduced by a newer kernel nice :)
[03:55] <dhillon-v10> bryyce, is this comment enough atm: This could be a regression caused by the kernel so can you try to boot into an older kernel (if you have one present on your system) and see if that solves your problem. Thanks.
[03:55] <bryyce> dhillon-v10, yes; if it does solve it then reassign to linux
[03:56] <dhillon-v10> bryyce, okay
[05:04] <hyperair> can someone help me debug an issue regarding my brightness keys?
[09:49] <BUGabundo_work> morning
[09:50] <bryyce> morning
[09:53] <BUGabundo_work> wb sebner
[09:54] <BUGabundo_work> wb seb128
[13:57] <hyperair> is there some kind of libgl breakage?
[13:58] <hyperair> http://pastebin.com/m789c79a6 <-- some guy with a 32-bit mesa-utils on a 64-bit comp
[13:59] <tseliot> hyperair: reinstalling xserver-xorg-core (or simply installing ubuntu5) should do it
[14:00] <tjaalton> ia32-libs isn't updated
[14:00] <tseliot> oh, I didn't read
[14:00] <tseliot> yes, that's broken anyway
[14:00] <hyperair> ah.
[14:00] <hyperair> i see
[14:01] <tseliot> it should be updated as tjaalton said and I should make sure that its libGL* libraries are put in /usr/lib32/mesa
[14:01] <hyperair> i think i provided a patch for that sometime back
[14:01] <hyperair> a very long time back.
[14:01] <tseliot> what kind of patch?
[14:02] <hyperair> one to the upstream, one as a debdiff
[14:02] <hyperair> the upstream went in, the debdiff...
[14:02] <hyperair> kinda died a natural death
[14:02] <tseliot> hyperair: ok but what did the patch do?
[14:03] <hyperair> changed a configure flag
[14:03] <hyperair> the upstream one added a configure flag that changed the DRI drivers' location
[14:03] <hyperair> the debdiff changed the configure flag so that it would install the DRI drivers' location to a place that could be symlinked to /usr/lib32/dri
[14:03] <hyperair> oh wait
[14:04] <hyperair> this is /usr/lib32/dri not /usr/lib32/mesa
[14:04] <hyperair> bug #248392
[14:05] <tseliot> right
[14:05] <tseliot> which is why I asked ;)
[14:05] <hyperair> heh
[14:05] <hyperair> wait, why are stuff being installed to /usr/lib32/mesa?
[14:05] <hyperair> not /usr/lib32?
[14:07] <tseliot> hyperair: because of the new alternatives system. Don't worry, ldconfig will know where to find those libraries
[14:07] <hyperair> ah
[14:07] <hyperair> i see
[14:07] <hyperair> not using rpath i suppose?
[14:08] <hyperair> i remember the ruling about rpath was dropped in one of the more recent debian policies
[14:08] <tseliot> yes, without rpath
[14:08] <jcristau> are you sure the 32bit ld.so can find stuff in /usr/lib32/mesa?
[14:08] <jcristau> when ld.so.conf only says usr/lib/mesa
[14:08] <tseliot> sure, it's patched to work with 32bit libraries
[14:09] <tseliot> jcristau: have a look at my changes to mesa (debian/rules)
[14:09] <jcristau> ok
[14:11] <siretart`> I noticed that with kms, a simple 'xrandr --query' now auto-enables the external monitor on my laptop. is this a known issue?
[14:12] <tseliot> hyperair: can you file a bug report about that, please?
[14:12] <tseliot> hyperair: feel free to assign it to me
[14:12] <hyperair> tseliot: what bug report?
[14:13] <tseliot> hyperair: about the fact that ia32-libs should install libGL* in /usr/lib32/mesa
[14:14] <hyperair> tseliot: i'm not on lucid and am not really sure what's going on at the moment really =\
[14:14] <tseliot> hyperair: ah, ok. Never mind
[14:14] <hyperair> sorry
[14:14] <tseliot> np
[15:06] <Sarvatt> anyone know whats up with libxcb? 2 sync requests closed a fixed for the 1.5 version but we're still at 1.4-1
[15:10] <tjaalton> it's on binary NEw queue
[15:10] <tjaalton> most likely
[15:14] <Sarvatt> thats what i thought because of the libxcb-dri2-0 but i never even saw it on https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=0&queue_text=
[15:14] <Sarvatt> not sure if thats even the place to look though
[15:28]  * BUGabundo_work waves to Sarvatt
[16:41] <geser> Sarvatt: grab an archive admin and let him look why the sync fails
[17:32] <afv> hi
[17:32] <afv> i'm getting the message "program: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory" when trying to run some apps
[17:32] <afv> locate libGLU: /usr/lib/mesa/libGLU.so.1 and /usr/lib/mesa/libGLU.so.1.3.070700
[17:33] <afv> hmm.. should i symlink that do /usr/lib/libGLU.so.1?
[17:35] <tseliot> afv: please make sure that your system has the latest mesa package
[17:35] <afv> 7.7-0ubuntu4
[17:35] <afv> i'm not using the edgers ppa
[17:36] <tseliot> afv: maybe try to reinstall it and do sudo ldconfig
[17:37] <afv> nop.. :s
[17:38] <tseliot> ?
[17:38] <afv> same problem
[17:38] <afv> dpkg --get-selections | grep mesa: libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, mesa-utils
[17:38] <afv> do i need something else than this?
[17:39] <tseliot> what does this command say? ldconfig -p | grep GL
[17:39] <afv> http://pastebin.com/d773782b6
[17:44] <tseliot> afv: can you file a bug report about it and assign it to me, please?
[17:44] <tseliot> as a quick fix a link to /usr/lib/mesa/libGLU.so.1 in /usr/lib/ should work
[17:45] <tjaalton> yeah the libdir change should be reverted, and install libGLU in /usr/lib again
[17:45]  * tseliot nods
[17:45] <afv> thanks. report it here? https://launchpad.net/ubuntu/+source/mesa/+filebug
[17:46] <tjaalton> though it changes the pkgconfig files then, but I don't know if those are used anyway
[17:46] <tseliot> afv: yes, please
[17:46] <afv> ok. no problem
[17:46] <tseliot> tjaalton: I'll take care of that. After alpha 2, that is
[17:47] <tseliot> afv: BTW what program gave you that problem?
[17:48] <tseliot> (just curious)
[17:48] <afv> blender, mixxx, yofrankie-bge
[17:48] <tseliot> ok
[17:48] <tseliot> just to have some test case
[17:48] <tseliot> cases
[17:49] <tjaalton> tseliot: ok
[17:51] <BUGabundo_work> tseliot: is nvidia better today? can i upgrade, or should i still hold on on it ?
[17:52] <tseliot> BUGabundo_work: sure, it should be safe to upgrade. Note: after the upgrade (just to be safe) reinstall xserver-xorg-core
[17:52] <BUGabundo_work> ok
[17:52] <BUGabundo_work> thanks
[17:53] <tseliot> np
[17:54] <afv> tseliot, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/506547
[17:55] <tseliot> afv: thanks a lot
[17:55] <afv> no problem. :)
[18:06] <Sarvatt> hmm those work fine here afv
[18:07] <Sarvatt> are you on amd64? using the nvidia blob maybe?
[18:07] <afv> using the nvidia blob
[18:07] <afv> 32bits
[18:08] <afv> they work fine after a ln -s /usr/lib/mesa/libGLU.so.1 /usr/lib
[18:08] <Sarvatt> i think it might be blob specific, not getting any errors on any of my machines not using the blob
[18:08] <tseliot> Sarvatt: that makes sense because the library is in the directory with the stuff installed by mesa
[18:09] <tseliot> but when you switch to nvidia
[18:09] <tseliot> ldconfig point to the directory with the nvidia libraries
[18:09] <afv> hmm.. what's your ls -l /usr/lib/libGLU.so.1 output?
[18:09] <tseliot> points
[18:09] <Sarvatt> ah yeah, so moving libGLU back would fix it there at least
[18:09] <tseliot> I doubt he has any
[18:09]  * tseliot nods
[18:10] <afv> maybe he has one that is there since an older update? :s
[18:11] <afv> i did an ubuntu fresh install yesterday (didn't fresh install since karmic alpha 2.. May last year :p) and maybe that's why i didn't have the file..
[18:11] <Sarvatt> btw we were going to add the drisearchpatch configure flag to mesa now that we're on 7.7 to fix ia32-libs? been fixing it in edgers for a few months now
[18:11] <Sarvatt>         --with-dri-searchpath=/usr/lib/dri:/usr/lib/dri/$(DEB_HOST_GNU_TYPE) \
[18:12] <Sarvatt> (adding that to confflags-dri after         --with-dri-driverdir=/usr/lib/dri \
[18:12] <jcristau> that would need a server change too?
[18:13] <tseliot> for bug #248392 ?
[18:14] <Sarvatt> yeah thats the bug, dont think it needs any server change
[18:16] <Sarvatt> http://old.nabble.com/-Bug-24766--New:-32-bit-libGL.so-searches-for-DRI-modules-in--usr-lib-dri-instead-of--usr-lib32-dri-td26082908.html
[18:17] <tseliot> ok, it seems a good candidate for alpha 3
[18:21] <tseliot> Sarvatt: with that configuration flag, do we still need the symlinks in ia32-libs?
[18:22] <tseliot> http://launchpadlibrarian.net/34815911/debdiff
[18:23] <jcristau> slangasek: so ia32-libs is still not going away? :(
[18:23] <Sarvatt> i dont think so.. hyperair?
[18:23] <tseliot> I guess it's either one way or the other
[18:23] <hyperair> Sarvatt: ?
[18:23] <tseliot> jcristau: how is it going away?
[18:24] <Sarvatt> are the symlinks needed in ia32-libs if we add this --with-dri-searchpath you added to mesa upstream?
[18:24] <hyperair> yes, they're needed.
[18:24] <hyperair> i think.
[18:24] <hyperair> well i could perhaps do --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri
[18:24] <jcristau> tseliot: how?  by someone removing it from the archive
[18:25] <tseliot> jcristau: interesting implementation ;)
[18:25] <hyperair> Sarvatt: coem to think of it maybe --with-dri-driverdir=/usr/lib32/dri might be the right solution?
[18:25] <tseliot> jcristau: I was asking what the alternative solution was
[18:25] <jcristau> tseliot: same as 5 years ago.  multiarch.
[18:26] <tseliot> jcristau: no doubt on that. Are we going to get that in dpkg?
[18:26] <jcristau> why do you ask me?
[18:26] <tjaalton> it's being worked on, but it was deferred to lucid+1
[18:26] <tseliot> aah, ok
[18:27] <hyperair> and when lucid+1 arrives, it'll be deferreed to lucid+2
[18:27] <tseliot> it's good to read that they're working on it :-)
[18:27] <tjaalton> mvo knows how hard it is to implement ;)
[18:27] <hyperair> and so on.
[18:27] <jcristau> it was deferred to etch+1 :)
[18:27] <tseliot> tjaalton: I bet he does ;)
[18:27] <jcristau> or was it sarge+1
[18:27] <tjaalton> jcristau: heh
[18:27] <tseliot> heh
[18:30] <Sarvatt> oops, need glproto 2.4.11 and dri2proto 2.2 already for mesa master now
[18:30] <hyperair> Sarvatt: ah right i just remembered. the symlinks are required, because the mesa things aren't rebuilt, and we needed some way to standardize the search path even for x64 builds.
[18:41] <tseliot> hyperair: good to know. I would like to fix this after alpha 2
[18:41]  * tseliot > dinner
[18:41] <hyperair> cool
[18:41] <Sarvatt> oh wow, moving the old 40-xserver-xorg-input-wacom.rules down below 65-xorg-evdev.rules was all that was needed to get it working? wasted all that time without knowing how things work and it was so simple :D
[18:41] <ripps> Okay, I think it's final. Plymouth was responsible from keeping my 2.6.32-10 kernel from booting
[18:42]  * hyperair will wait at least until then before upgrading
[18:42] <hyperair> plymouth?
[18:42] <jcristau> Sarvatt: i think it was all ron was missing for a while.  so he was (unknowingly) getting evdev and thought it didn't work quite well enough :)
[18:44] <ripps> I also know that something is wrong with the radeon drivers w/ dri1. Because my X keeps crashing when I try to boot with nomodeset. I can get into xterm and I can see through glxinfo that the right mesa glx is loaded, but once I try to boot into Gnome or Failsafe Gnome, black bars appear and suddenly X restarts.
[19:07] <Sarvatt> hmm [ 3999.496717] (II) intel(0): No memory allocations [ 3999.496901] (EE) intel(0): Couldn't create pixmap for fbcon [ 3074.601783] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id on the latest daily kernel after resume
[19:17] <Duke`> :/
[19:44] <tseliot> Sarvatt: maybe plymouth triggered that
[19:50] <tseliot> i.e. its drm plugin for intel
[20:26] <hyperair> we're using plymouth in lucid now?
[20:26] <BUGabundo> evening
[20:27] <BUGabundo> looks like nvidia aint still ready :(
[20:27] <BUGabundo> can't activate it via jokey
[20:27] <hyperair> nvidia's never ready before the release candidates anyway >_>
[20:27] <hyperair> those slowcoaches
[20:27]  * hyperair sighs
[20:27] <BUGabundo> $ pastebinit /var/log/jockey.log
[20:27] <BUGabundo> http://paste.ubuntu.com/355687/
[20:28] <hyperair> it probably wouldn't build
[20:29] <hyperair> speaking from past bad experiences with nvidia's driver, but then again mine's the 96xx legacy one
[20:29] <BUGabundo> I asked tseliot before coming home if it was fine
[20:29] <BUGabundo> he said so
[20:30]  * hyperair shrugs
[20:30] <hyperair> anyway, it looks like you'er missing the kernel module
[20:30] <hyperair> try poking dkms
[20:31] <BUGabundo> how?
[20:31] <hyperair> umm
[20:31] <hyperair> not sure..
[20:32] <hyperair> dpkg-reconfigure nvidia-<whichdriver>-kernel-source perhaps?
[20:32] <BUGabundo> lets try
[20:32] <BUGabundo> no such package
[20:33] <hyperair> huh
[20:33] <hyperair> you sure?
[20:33] <BUGabundo> $ sudo dpkg-reconfigure nvidia-
[20:33] <BUGabundo> nvidia-173-modaliases      nvidia-185-modaliases      nvidia-common              nvidia-current-modaliases  nvidia-settings
[20:33] <BUGabundo> nvidia-185-libvdpau        nvidia-96-modaliases       nvidia-current             nvidia-glx-185
[20:33] <hyperair> oho weird.
[20:33] <BUGabundo> $ dpkg -l | grep nvidia | pastebinit  http://paste.ubuntu.com/355696/
[20:34] <hyperair> nvidia-glx-185 depends on nvidia-185-kernel-source
[20:34] <hyperair> er
[20:34] <BUGabundo> there's no such thing in my apt db
[20:34] <hyperair> you don't even have nvidia-glx-185.
[20:34] <hyperair> okay
[20:34] <hyperair> try installing nvidia-glx-185?
[20:34] <BUGabundo> lucid, right?
[20:34] <hyperair> er
[20:35] <hyperair> actually i haven't done this for ages so i don't even remember how the process is supposed to go
[20:35] <hyperair> maybe you should just wait until someone moer familiar turns up =D
[20:35] <BUGabundo> it changed a lot
[20:35] <hyperair> since karmic?
[20:35] <BUGabundo> yep
[20:36] <hyperair> =x
[20:46] <bjsnider> BUGabundo, from tseliot: Jockey is not ready yet (because of a broken dependency on kdebindings).
[20:46] <BUGabundo> BAH
[20:46] <BUGabundo> bjsnider: so what's the manual approch?
[20:48] <bjsnider> the command is in the rues file
[20:48] <bjsnider> i don't have access to it at the moment
[20:48] <bjsnider> everything but glx should be working though
[20:50] <bjsnider> bug 494166
[20:50] <bjsnider> there might be info in there about it
[21:51] <slangasek> jcristau: I don't have time to work on multiarch this cycle; braindmg said he was going to work on the deep structure changes needed in dpkg, but I haven't seen any movement there lately (and haven't had time to check either)
[21:52] <jcristau> ok :/
[23:53] <maxb> Does anyone know if there's a bug filed for the current X doesn't work at all on Intel GPU woes in lucid?
[23:55] <RAOF> I don't know one offhand.  Also, my Intel X works fine; I've clearly dodged the bad upgrade.


[16:00] <vadi2> I think this'll be of interesting to some, found it on russian ubuntu forums: http://ur1.ca/2bc
[16:01] <shahriar86> checking
[16:04] <shahriar86> interesting one
[16:04] <shahriar86> :)
[16:05] <suprfish> does the spread-ubuntu mailing list work or is it just slowly moderated?


[00:00] <RAOF> intrader: Could you try a Maverick LiveCD?  We've just released the beta.
[00:06] <JanC> I guess it would also be useful to know what hardware it is
[00:08] <RAOF> It would appear to be nvidia-something-old.
[00:40] <RAOF> Man, a full piglit run takes a good long while.
[00:40] <RAOF> (When it doesn't hang the GPU)
[04:24] <RAOF> Yay!  A bug that is reproducible on hardware I own.  I love those!
[11:24] <RAOF> Anyone around who feels like sponsoring xserver-xorg-video-ati from git?
[11:25] <RAOF> It's just sitting there innocently in pkg-xorg git, waiting to fix an xserver crash.
[11:27] <tseliot> RAOF: sure
[11:36] <tseliot> RAOF: you prepended a "d" to xserver-xorg-video-ati in the changelog. I'll correct that and upload
[11:43] <RAOF> Thanks
[11:48] <tseliot> RAOF: also I made a diff between revision ubuntu4 and ubuntu5 and it seems a bit excessive (compared with the description in the changelog): http://pastebin.ubuntu.com/489168/
[11:50] <tseliot> any ideas?
[11:50] <tseliot> (it's not just the aclocal changes)
[13:22] <RAOF> tseliot: Hm, it's a bit late here.  Can I check that in the morning and see if I can work out why the diff is so big for you?
[13:22] <tseliot> RAOF: sure, no hurry
[15:32] <apw> anyone see the X-server wedging on i915_gem_throttle_ioctl ?
[15:35] <apw> s/on/in
[17:35] <jonasfa> Hello guys. As Maverick supports multitouch devices, I'm willing to develop an Android app to use the device as a multitouch mouse.
[17:35] <jonasfa> where can I find any docs to help me?
[18:23] <jonasfa> where can I find docs on how to simulate a MT device?
[18:30] <ScottK> RAOF: How is ATI + Maverick these days?  Need to set expectations from someone who's about to try it.
[23:51] <RAOF> ScottK: Not cutting-edge cards (up to r700, which is Radeon 4xxx) should have decent 3D and 2D, and should run Unity properly once we get mesa 7.9.  The newest evergreen cards (Radeon 5xxx I believe) have modesetting support, but no acceleration in Maverick.
[23:53] <RAOF> ScottK: fglrx doesn't work at the moment in Maverick, but should (AMD willing!) work by release.
[23:59] <ajmitch> RAOF: by 'decent 3D', how well does it work?


[15:31] <bdx> from a charm's perspective, what is the best way to inquire about the # of units that exist for the type of application that you are? - e.g. how many of myself are there?
[15:31] <bdx> pretty sure there is an all_units floating around somewhere
[15:31] <bdx> thought I would run it by the pros
[17:35] <Doctor_Nick> what are some good autoscalers to use with juju?
[19:39] <bdx> Doctor_Nick: depends on the cloud substrate
[19:40] <bdx> Doctor_Nick: https://jujucharms.com/charmscaler/
[21:35] <Doctor_Nick> bdx: aws, gcloud
[21:36] <Doctor_Nick> I had looked at that, but it's not free software
[22:32] <babbageclunk> wallyworld: here's that PR I was telling you about: https://github.com/juju/juju/pull/9180
[22:32] <wallyworld> babbageclunk: already looking :-)
[22:32] <babbageclunk> sweet
[22:35] <wallyworld> babbageclunk: returning an  error from the worker will just restart the worker every 3 seconds and spam the logs. maybe the restart delay needs to be longer in this case?
[22:37] <babbageclunk> wallyworld: yeah, I was wondering about that - how do I do a longer delay, return a specific error type?
[22:38] <wallyworld> not sure that we can - i know there's a RetryDelay we can set for the worker itself but I'm not sure off hand how to change that for a specific error
[22:38] <wallyworld> we'll have to look at the worker code
[22:39] <babbageclunk> ok, I'll take a look
[23:06] <babbageclunk> wallyworld: I could just change the worker loop so that it doesn't crash with that error, just logs it and sets retry to something bigger than the default 5 seconds - say 1 minute?
[23:07] <wallyworld> babbageclunk: i think that works - you mean provide an IsFatal()


[01:19] <InHisName> Evening
[01:30] <InHisName> Don't go bacon my heart
[01:30] <InHisName> I couldn't if I fried.
[01:45] <waltman> What are you, Canadian?
[09:25] <rmg51> Morning
[09:59] <JonathanD> Morning.
[12:09] <teddy-dbear> Morning peoples, dogs, turkeys and everything else
[12:36] <JonathanD> To the workmobile!
[14:16] <InHisName> for Mr Bacon:  http://imgur.com/gallery/qVh0O
[14:41] <ChinnoDog> Good morning
[14:45] <JonathanD> hi
[14:46] <InHisName> Lo
[17:26] <waltman> MutantTurkey: Hey, you wouldn't happen to know what's up with cs.drexel.edu, would you?  All I can find online is this: http://www.reddit.com/r/Drexel/comments/1c9zys/computer_science_students_all_csit_data_has/
[17:27] <waltman> A guesstimate of when mail will be back online would be awesome. :)
[17:28] <MutantTurkey> No, I was at professor breens this weekend and he was the one who told me
[17:28] <MutantTurkey> I know gaylord has backups but I don't know when it's all gonna be back up
[17:28] <waltman> *sigh*
[17:28] <MutantTurkey> why isn't there a #drexelcs channel?
[17:29] <MutantTurkey> the home folders are back online
[17:29] <MutantTurkey> so the web servers are up
[17:29] <MutantTurkey> email is probably online soon I'd hope
[17:29] <waltman> I saw that. Then I tried to connect to imap.cs.drexel.edu and got 'no route to host'
[17:30] <waltman> Then I tried to email gaylord and got 'connection refused'
[17:31] <MutantTurkey> yep I believe it.
[17:31] <MutantTurkey> I am to lazy to go see what happened
[17:31] <waltman> I didn't even know there was a problem until Ali asked if I'd gotten his email and I said, "What email?"
[17:31] <MutantTurkey> if I walk over to the cs dep gaylord will probably chop my head off...
[17:31] <MutantTurkey> out of pure anger
[17:31] <waltman> so it's your fault?
[17:31] <MutantTurkey> haha no
[17:32] <MutantTurkey> but I think he probably had a rough weekend
[17:32] <waltman> did one of your mutant turkey wings knock out a cable?
[17:32] <MutantTurkey> secretly been plotting all along
[17:32] <waltman> I knew it!
[17:32] <MutantTurkey> #drexel channel... now
[18:01] <MutantTurkey> just registered ceux.org


[04:14] <lotuspsychje> good morning
[07:05] <lordievader> Good morning
[07:49] <ducasse> good morning
[14:32] <pragmaticenigma> hggdh: you mean the fact that they've been doing it for more than 4 hours isn't enough reason to block them?
[14:33] <oerheks> he avoida a ban by using multiple ways of connection, weak tor config
[14:34] <hggdh> oerheks: banned by $a, not connection address/type
[14:34] <pragmaticenigma> I'm guessing with the somewhat higher internet usage.. tor is really going to be flakey
[14:35] <oerheks> thanks hggdh :-)
[14:35] <akem> Will "service" (to list services) be removed at some point? also i wonder why it is so slow to list.
[14:36] <pragmaticenigma> Isn't that something server side?
[14:39] <akem> pragmaticenigma, Hm, you mean that to me? It's all local AFAIK, i was trying to list running services, first using "service --status-all" and it's very slow, but "systemctl list-unit-files" is instant.
[14:39] <akem> Of course much more infos with systemctl.
[14:39] <pragmaticenigma> akem: oh... you mean on your machine... didn't realize the topic of the conversation switched
[14:40] <akem> Yeah.
[14:42] <akem> It is a bit faster now, but first time i tried, it was waiting on each line, strange.
[14:42] <pragmaticenigma> indexing perhaps?
[14:45] <akem> Yeah, i don't know.
[15:23] <pragmaticenigma> ChadTaljaardt: First and foremost, your company should be running daily backups of their production systems. If they're not doing that much, then they are setting themselves up for major single point of failure.
[15:24] <pragmaticenigma> the backups are the first line of defense for restore after system crashes, bad updates, etc
[15:24] <pragmaticenigma> and they should be keeping several backups around, in case an update takes a few days to manifest a problem
[15:24] <akem> If they want you to compile everything, switch to Gentoo it will be easier maybe :P
[15:24] <pragmaticenigma> akem: please don't
[15:25] <akem> Just joking.
[15:25] <oerheks> he worries about his 'production environment'  ???
[15:25] <oerheks> no testing setupo?
[15:25] <oerheks> lolz
[15:26] <ChadTaljaardt> We keep database backups every day and store them for 60 days if i recall correctly
[15:26] <pragmaticenigma> ChadTaljaardt: To make your company understand better... tell them that it takes more man hours and costs more money to take their proposed approach, when there are so many smaller more maintainable approaches
[15:27] <ChadTaljaardt> i dont think the comapany cares about that, they see it as a really high priority to make sure everything is version static
[15:27] <pragmaticenigma> also, all that stuff you mentioned, increases the chances of something breaking... not preventing
[15:27] <ChadTaljaardt> i just dont understand whats so bad about getting curl from apt..
[15:28] <oerheks> curl bad from apt?
[15:28] <oerheks> interesting..
[15:28] <pragmaticenigma> companies do many stupid things... but one they will pay attention to is their bottom line... they don't want to spend more money on a problem than they have to
[15:28] <ChadTaljaardt> i think their perspective is that if you download a specific version and compile it manually, there is no chance of something going wrong with it later on, as everything should be exactly the same
[15:29] <pragmaticenigma> and then they wonder why they got hacked because someone wasn't paying attention to a security update and didn't patch the servers
[15:30] <oerheks> ChadTaljaardt, if you are so sensitive, built it yourself then, i see no security risc building by ubuntu
[15:30] <ChadTaljaardt> Ive tried presenting that argument... they said getting the latest updates is a security risk
[15:30] <ChadTaljaardt> While - because this is essentially a temp solution until (hopefully) we go "docker", I can live with it,  I would point out that just pulling the "latest" version of even smaller widgets is a recipe for a) a bollocks when something unexpectedly gets broken (and sorry - sooner or later that will happen) and b) is a security hole as big as a very big one should the underlying widget codebase get compromised.   Its fine for Dev trees, as a
[15:30] <ChadTaljaardt>  "production" thing it rather less so...
[15:30] <ChadTaljaardt> thats what they said
[15:31] <oerheks> so, if you have no seperate testing pc, even your own builded packages can fail
[15:31] <oerheks> apt or make..
[15:31] <ChadTaljaardt> we do use a staging environement to test stuff
[15:32] <ChadTaljaardt> but we only update things like every 6 months or so
[15:32] <pragmaticenigma> ChadTaljaardt: Personally... I'd quit my job
[15:32] <oerheks> yeah, stay @<IP_ADDRESS>
[15:32] <ChadTaljaardt> bad time to quit lol, job market looks bad atm
[15:32] <pragmaticenigma> ChadTaljaardt: soon as they get hacked or something crashes... your butt is going to get fired... they're looking for a scape goat
[15:34] <ChadTaljaardt> problem is that the data hosted on the website is "highly sensitive"
[15:34] <ChadTaljaardt> so we need to have very very good security
[15:34] <ChadTaljaardt> such a dilemma..
[15:34] <pragmaticenigma> So they want to lower the security to make it more secure... oh that makes so much more sense /sarcasm
[15:35] <ChadTaljaardt> their argument is that newer versions of software can continue security holes, because it most likely hasn't been extensively tested and had time for people to look at it.
[15:35] <ChadTaljaardt> contain *
[15:36] <ChadTaljaardt> whereas older versions have had more time to be tested, thus more secure and more stable
[15:36] <ChadTaljaardt> -.-
[15:36] <pragmaticenigma> !latest | See this:
[15:37] <pragmaticenigma> Ubuntu already does that for you ChadTaljaardt ... they don't release the "latest" versions... they keep the version at the same version that was available at the time of release of the Ubuntu version
[15:37] <oerheks> a package gets tested before it gets green light...
[15:37] <ChadTaljaardt> already told them that..
[15:37] <ChadTaljaardt> got ignored
[15:37] <ChadTaljaardt> lol
[15:37] <pragmaticenigma> The updates that Canonical pushes out are patches against the existing and vulnerable version, they don't upgrade to the latest because of a hole or bug... they fix it
[15:38] <ChadTaljaardt> is that what you get when you do stuff like apt-get upgrade?
[15:38] <ChadTaljaardt> cause we arent allowed to do that
[15:38] <pragmaticenigma> Then I'm done with this exercise... As mentioned in main, the support channel will not support packages not provided through apt. That holds true for the channel and would probably hold true if your company had a support contract with canonical
[15:39] <pragmaticenigma> The volunteers rely on the documentation put out by the developers of ubuntu... when a person/group compiles their own, we have no idea what flags, customizations, etc, where done to the code. and wouldn't have the proper documentation to support it
[15:39] <ChadTaljaardt> well i got a call with them in 25 minutes to try argue the case for using apt.. so i wonder how this will go
[15:40] <pragmaticenigma> Oh my Tux! You guys are just begging to get hacked... your company is a very very sad company
[15:42] <pragmaticenigma> ChadTaljaardt: you can inform them... updates provided by canonical, within the support cycle of a release, do not push out the latest versions. They only focus on severe bug fixes and vulnerabilities. In the most rare of rare occassions is a new version release, but only when there is absolutely no way to fix the issue in the existing release.
[15:43] <ChadTaljaardt> when you say a new release and a fix in a pre-existing realease, does that mean that if you install the same version of a package, say curl, that the code used to run this could be different in both cases?
[15:43] <ChadTaljaardt> unless i am misunderstanding this
[15:43] <pragmaticenigma> And when such an event happens, there are notifications sent out through release notes and other channels to let customers and users know that such an update is being made. so companies have ample time to prepare and test before deployment
[15:44] <pragmaticenigma> Example: For Ubuntu 18.04 LTS, the version of curl I'm running on my machine is the same version that was available at install 2 years ago. Only thing that has been updated was for security vulnerabilities in that time. That is it
[15:45] <ChadTaljaardt> right okay, so the version number will change but itll only be minor version number changes, not major
[15:45] <pragmaticenigma> it won't necassarily be the minor version that changes... it might be a build number
[15:45] <pragmaticenigma> so sub of the sub minor version number
[15:46] <ChadTaljaardt> and if there are no security updates or major bug fixes, it'll be the original that was shipped with the os version
[15:46] <ChadTaljaardt> ahh okay
[15:46] <pragmaticenigma> that is correct ChadTaljaardt
[15:47] <ChadTaljaardt> i think they might listen if i say that, because their perspecitive is that any changes as long as its not a major change gets packaged and shipped..
[15:47] <pragmaticenigma> I'm a software developer myself... there is nothing worse than coding an application to leverage a system tool, only to have that tool change on you. It is one of the reasons that I have choosen Ubuntu over other distributions
[15:47] <ChadTaljaardt> tbh they just need to learn how this stuff works, dont think it should be me doing this lol
[15:47] <pragmaticenigma> darn right
[15:48] <ChadTaljaardt> yeah thats their fear, we used to install things like elasticsearch and when there was an update it would break the system, we have pinned the version of elasticsearch now, but because of that they want to pin absolutely everything
[15:48] <pragmaticenigma> the devs for Ubuntu, CentOS, RedHat, SuSE have been doing this for many many years... they all have similar philosophies when it comes to updates of software
[15:49] <pragmaticenigma> better is to pin the problematic package, terrible is to assume everything is doing that
[15:51] <ChadTaljaardt> yeah i proposed pinning the versions of all the stuff that is not within ubuntu, so like elasticsearch, rabbitmq, we have a custom python version (3.8) so thats pinned etc
[15:51] <ChadTaljaardt> but should leave things like autoconf and wget to just come from apt
[15:51] <pragmaticenigma> that sounds like the right approach to me
[15:52] <pragmaticenigma> from this conversation... what it sounds like to me is they got bit in the bum version chasing... now they're gun shy about everything
[15:52] <pragmaticenigma> I develop personally in python... I develop against version 3.6, even though most of my stuff is running on 3.7 and 3.8 machine
[16:05] <pragmaticenigma> littlekimmy... at it again...
[16:06] <oerheks> yes, a bad boy
[16:07] <oerheks> if people do not want to read, why reading in #u ?
[16:07] <pragmaticenigma> everything that comes up with a google search on their handle has someone telling them to leave
[16:08] <pragmaticenigma> and notice how ever time someone calls them out on it... they go silent... until they think I'm not looking
[16:08] <pragmaticenigma> or someone else that called them out for their behavior
[16:36] <ChadTaljaardt> woo..
[16:37] <ChadTaljaardt> convinced my team, they are on board with only pinning major packages we use like elasticsearch.. now i need to convince the CTO to allow us to run things like apt-get upgrade and not version pin everything
[16:37] <ChadTaljaardt> fun fun
[16:37] <daftykins> apt-get is pretty old school at this point fwiw, just apt now is enough :) saves on the ol' keystrokes
[16:38] <pragmaticenigma> agreed... apt helps simplify... apt-get is still better for automating stuff
[16:41] <pragmaticenigma> !info fglrx bionic
[16:42] <daftykins> how-so?
[16:42] <daftykins> definitely took a while for feature parity, i think the xenial one couldn't 'clean'
[16:44] <pragmaticenigma> I guess it came out of the man page: The `apt` command is meant to be pleasant for end users and does not need
[16:44] <pragmaticenigma>        to be backward compatible like apt-get(8).
[16:44] <oerheks> apt is superiour over apt-get
[16:45] <pragmaticenigma> I think where I got the apt-get for automatted purposes was the progress bar in apt (which can be turned off) could cause issues for applications trying to pull and interpret the output
[17:04] <ChadTaljaardt> pragmaticenigma do you know of a source which states that the ubuntu packages from apt are not the "latest"
[17:07] <pragmaticenigma> ChadTaljaardt: I'll see if I can find a place that it is explicately spelled out... for now it might be somewhere in these docs: https://ubuntu.com/server/docs
[17:07] <pragmaticenigma> https://ubuntu.com/server/docs/package-management
[17:09] <pragmaticenigma> I don't know where the source of our factoid came from
[17:09] <pragmaticenigma> !latest
[17:11] <ChadTaljaardt> yeah i tried googling for that term and it doesnt show anything except irc logs
[17:11] <daftykins> if people are version chasing, educate them how ridiculous it is
[17:11] <pragmaticenigma> hggdh: Do you happen to know the source of the !latest factoid
[17:12] <pragmaticenigma> daftykins: we just did that earlier in here
[17:12] <ChadTaljaardt> found this https://askubuntu.com/questions/151283/why-dont-the-ubuntu-repositories-have-the-latest-versions-of-software which tells it, but they want a more official source
[17:12] <ChadTaljaardt> lol
[17:13] <ChadTaljaardt> what is version chasing?
[17:13] <daftykins> when people think that a bigger number and the pursuit thereof is everything
[17:13] <pragmaticenigma> ChadTaljaardt: It's the opposite of what your company is trying to do
[17:14] <ChadTaljaardt> ahh so always wanting the latest and greatest of everything
[17:15] <lotuspsychje> ChadTaljaardt: latest doesnt mean greatest, thats the whole point
[17:16] <ChadTaljaardt> it was just tongue and cheek
[17:16] <ChadTaljaardt> im gonna get lunch, be back in a hour or so
[17:17] <ChadTaljaardt> take care :)
[17:17] <sarnold> hopefully helpful https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions https://www.debian.org/security/faq#version https://access.redhat.com/security/updates/backporting https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-update-backport.html
[17:19] <ChadTaljaardt> thanks sarnold
[17:19] <pragmaticenigma> ChadTaljaardt: White paper here: https://ubuntu.com/about/release-cycle
[17:19] <ChadTaljaardt> ill check it out
[17:21] <pragmaticenigma> ChadTaljaardt: in the link I sent, under the heading "Maintenance and security updates"
[17:21] <sarnold> pragmaticenigma: that's nice page
[17:22] <pragmaticenigma> BINGO! found it... same page ChadTaljaardt under the heading "Ubuntu kernel release cycle" second paragraph
[17:22] <pragmaticenigma> In general, all of the LTS kernel packages will use the same base version of the Linux kernel, for example, Ubuntu 18.04 LTS kernels typically used the 4.15 upstream Linux kernel as a base. Some cloud-specific kernels may use a newer version in order to benefit from improved mechanisms in performance or security that are material to that cloud. These kernels are all supported for the full life of their underlying LTS
[17:22] <pragmaticenigma> release.
[17:23] <ChadTaljaardt> thats only saying for the kernel though, not the packages in the apt?
[17:24] <ChadTaljaardt> unless im misunderstanding it
[17:26] <sarnold> cloud-specific kernels are weird
[17:27] <sarnold> https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html
[17:27] <pragmaticenigma> I'm not an expert on this, the page as a whole is supposed to instill the confidence that Ubuntu is stable and things aren't going to shift beneath the feat of an organization trying to use the product
[17:27] <pragmaticenigma> *feet
[17:27] <TJ-> clouds tend to vaporise or rain down on you - remember that!
[17:27] <sarnold> lol
[17:28] <pragmaticenigma> ChadTaljaardt: Beyond what we can find, you might have to call https://canonical.com/contact-us
[17:31] <pragmaticenigma> ChadTaljaardt: https://wiki.ubuntu.com/LTS
[17:31] <TJ-> LTS == if we break it we might actually fix it
[17:31]  * lotuspsychje opens umbrella
[17:38] <hggdh> !-latest
[17:38] <hggdh> pragmaticenigma: ^
[17:39] <hggdh> or, you meant the raw factoid:
[17:39] <hggdh> !+latest
 Packages in Ubuntu may not be the latest. Ubuntu aims for stability, so "latest" may not be a good idea. Post-release updates are only considered if they are fixes for security vulnerabilities, high impact bug fixes, or unintrusive bug fixes with substantial benefit. See also !backports, !sru, and !ppa.
[17:43] <pragmaticenigma> hggdh: I mean the actual location of documentation that was used to create that factoid... like where in the Canonical/Ubuntu documentation does that message come from
[17:43] <pragmaticenigma> hggdh: as in citation
[17:43] <lotuspsychje> hggdh: ChadTaljaardt wanted an explain of why LTS has not latest packages
[17:46] <hggdh> oh. No, I do not know (anymore). But the reason is basic: stability. Same thing Red Hat, SUSE, Oracle, etc (even Debian) do: you need a stable image you can redeploy multiple times without wasting time to learn of new problems/issues/features
[17:47] <pragmaticenigma> at some point, that should make it's way into ubuntu.com's whitepapers as "fact" ... for now the only true reference I was able to find lives in a wiki
[17:47] <pragmaticenigma> I don't know what the process is for that
[17:49] <lotuspsychje> somthing to also think about, is when ubuntu serves latest snaps right from software choices, we get mixed systems with both stability and latest software
[17:49] <hggdh> I really do not know. It may well be that this is one of the "basic truths" that everybody assumes but very few (myself included) actually thought of documenting
[17:50] <oerheks> interesting conv. https://discourse.ubuntu.com/t/proposal-for-ubuntu-20-04lts/12969
[17:50] <oerheks> all we need is an #ubuntu-snap channel please
[17:51] <lotuspsychje> oerheks: one month to go..i assume things will be bit late for insert all those ideas
[17:51] <hggdh> lotuspsychje: yes, snaps can give a sysadmin headaches; most places I have been, snaps are only installed by the sysadmins (and they have to have an approved change request)
[17:52] <hggdh> oerheks: there is already #snappy
[17:53] <pragmaticenigma> hggdh: I think with Ubuntu evolving toward more enterprise level of products, it would be advantages to include that in their whitepapers and on the main site pages. Where content can't be modified freely by those with accounts.
[17:53] <lotuspsychje> oerheks: maybe 20.10 :p
[19:34] <rfm> Is there any reason to prefer UUID=blahblah over /dev/disk/by-uuid/blahblah in /etc/fstab?
[19:36] <lordcirth_> rfm, It's shorter and clearer, IMHO
[19:37] <daftykins> yeah critical file, reduce the character count imo
[19:44] <rfm> I noticed the 20.04(dev) installer now uses /dev/disk/by-uuid
[19:58] <jalepenoftw> Hi there! I've been working on an open source project (https://FreePN.com) for a few months and wanted to get some feedback! FreePN is a Linux-first (Ubuntu included) open-source peer-to-peer VPN project.
[19:58] <jalepenoftw> explanations for this and other common questions here: https://freepn.com/pages/faq.html)
[20:01] <akem> jalepenoftw, It's a nice idea, but it won't work for many of us.
[20:04] <akem> Here i'm using a VPN(NordVPN) because it's not logged and no-one is monitoring the connection. Now if i use FreePN, i can become some sort of exit node for other peers, and my output is monitored, so someone torrenting for example, my ISP would just think i am torrenting. And other peers maybe logged or monitored too.
[20:04] <daftykins> yeah that'd be in violation of most peoples ISP contract
[20:08] <jeremy31> Who reads?
[20:08] <jalepenoftw> So we actually allow you to choose what traffic you're comfortable carrying -- we give certain pre-selected categories you can choose from (think filesharing as an example), and if you basically 'check the box' for a given category, that traffic will be rerouted elsewhere / you won't act as an exit node for that category of traffic.
[20:12] <akem> Yeah. It's still a good project, i hope it will get some attention.
[20:16] <akem> I think the alternative is the darknet(Tor) but only if you stay on the encrypted network(onion), that way no one can tell what's going on. - but most people want things that are only available on clearnet OFC, and it's not usable ATM for torrenting.
[21:13] <oerheks> LLVM 10.0.0 Release (llvm.org)


[00:09] <mup> Bug #1582944 opened: maasserver.rpc.tests.test_regionservice:TestRegionService.test_start_up_logs_failure_if_all_endpoint_options_fail fails ~15-20% of the time <MAAS:Triaged> <https://launchpad.net/bugs/1582944>
[00:52] <mpjetta> I’m trying to debug some network issues while bootstrapping juju 2.0 to my new MAAS 2.0. The node comes up but hangs for a 5 minute timeout on bringup up network. The node finally loads and I can ping it and SSH is up on port 22 but I can’t SSH in and immediately get a “Connection reset by xxx.xxx.xxx.xxx port 22” . any ideas?
[02:16] <dmick> looking at http://maas.ubuntu.com/docs/os-support.html#generated-images-vs-custom-images
[02:16] <dmick> how does one generate a custom Ubuntu image (say, with preinstalled packages)?
[02:17] <dmick> maas-image-builder claims only CentOS/RHEL
[02:20] <dmick> (and the ppa has apparently moved from that documented locatino)
[03:00] <jwitko> Hey All,  I have some servers getting stuck at the "comissioning" stage.  Does anyone know how I can trouble shoot?
[05:41] <shantanu> Need help
[05:42] <shantanu> Getting this error while deploying
[05:42] <shantanu> Specify a storage device to be able to deploy this node.", "Mount the root '/' filesystem to be able to deploy this node MAAS Deployment
[07:26] <KwootAtWork> newbie question: if on maas 1.9.2 I select "subnets" and I never get past the "loading" stage. How can I find out what is going wrong?
[08:39] <KwootAtWork> Ok,other question. If during system image download to maas the filesystem is full, the download halts. After adding more lvm space to the filesystem it is possible to start a new download. But maas keeps telling me "Cannot add machine until boot images have been imported. To fix, visit the images page.". Where can I find the marker that says that download failed?
[09:10] <jeffb> my MAAS won't autoboot my nodes. comes back very quickly with 1 node cannot be powered on. wakeonlan and etherwake both installed & work from CLI
[09:10] <jeffb> have added etherwake into sudoers file already
[09:11] <jeffb> any ideas what to check would be appreciated
[10:38] <mup> Bug #1583093 opened: Fail to deploy if VLAN are configured <MAAS:New> <https://launchpad.net/bugs/1583093>
[13:45] <mup> Bug #1560830 changed: maas power check won't work with ipmi hosts with the string 'on' in them <canonical-bootstack> <MAAS:In Progress by allenap> <https://launchpad.net/bugs/1560830>
[14:51] <mup> Bug #1578713 changed: maas cli help message shows API 1.0 after upgrade to 2.0 <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1578713>
[15:23] <FLU__> Does anyone have a recommendation where to find someone that will setup maas on ubuntu 15.04
[16:01] <LoRez> FLU__: on a non-LTS release?
[16:19] <mup> Bug #1560830 opened: maas power check won't work with ipmi hosts with the string 'on' in them <canonical-bootstack> <MAAS:In Progress by allenap> <https://launchpad.net/bugs/1560830>
[17:00] <dmick> how does one generate a custom Ubuntu image (say, with preinstalled packages)?
[17:00] <dmick> maas-image-builder claims only CentOS/RHEL
[17:10] <mup> Bug #1560830 changed: maas power check won't work with ipmi hosts with the string 'on' in them <canonical-bootstack> <MAAS:In Progress by allenap> <https://launchpad.net/bugs/1560830>
[17:22] <mup> Bug #1560830 opened: maas power check won't work with ipmi hosts with the string 'on' in them <canonical-bootstack> <MAAS:In Progress by allenap> <https://launchpad.net/bugs/1560830>
[17:31] <mup> Bug #1560830 changed: maas power check won't work with ipmi hosts with the string 'on' in them <canonical-bootstack> <MAAS:In Progress by allenap> <https://launchpad.net/bugs/1560830>
[18:07] <kiko> dmick, that's a great question for smoser or blake_r_ :)
[18:08] <dmick> thanks for the tip kiko
[18:08] <kiko> I've been looking for some docs on that for a long time
[18:09] <dmick> I'm even having trouble finding anything about what teh format of the image is expected to be
[18:10] <kiko> dmick, the only other hint I can give you is that the image is installed using curtin
[18:10] <kiko> that's the installer
[18:10] <dmick> yeah, I found that, and so perhaps "some sort of tarball" is my clue so far
[18:10] <dmick> haven't actually tried to read curtin source yet
[18:13] <kiko> dmick, you'd have gotten an answer by now except the guys are sprinting in vancouver this week
[18:13] <kiko> dmick, maybe write to the list or ask on askubuntu if you get bored
[18:14] <dmick> ok
[18:51] <pacavaca> is there an easy way to create a custom ubuntu image for maas? by custom I mean ubuntu + some additional packages installed and config changes made. The number of changes is quite big, so it's not wise to do them every time through preseed scripts and I'm looking for some way to create an fs snapshot and feed it to maas.
[19:13] <mup> Bug #1583317 opened: No visible warning when ipmipower fails or raises an error <MAAS:New> <https://launchpad.net/bugs/1583317>
[19:22] <kiko> pacavaca, are you in league with dmick?
[19:22] <kiko> pacavaca, I'm asking because he just asked the same thing a few hours ago :)
[19:22] <kiko> pacavaca, could you post a question on askubuntu.com?
[19:22] <kiko> I'll get it answered
[19:22] <kiko> the team is sprinting in vancouver so slow to answer IRC this week
[19:29] <pacavaca> kiko: no, I came up with this question independently, don't know who is dmick :) Ok, will post it there, thank you!
[19:30] <pacavaca> actually, there're similar quistions with no answer already. This one for example http://askubuntu.com/questions/725017/how-to-generate-a-custom-image-of-ubuntu-for-maas
[19:32] <dmick> pacavaca: I've just been asking it in here yesterday and today
[19:33] <kiko> pacavaca, okay, subscribe to that one (dmick too he likes) and I'll get an answer put in
[19:33] <dmick> yeah, I found that one last night.  I'll glom on.
[19:33] <pacavaca> kiko: thank you!
[19:33] <kiko> s/he likes/if he likes/
[19:33] <dmick> kiko: is my launchpad login good for that, or is it separate?
[19:34] <kiko> dmick, I think it's the same SSO yes
[19:34] <dmick> ah yeah, UI FTW
[19:34] <pacavaca> stackoverflow login works too
[20:29] <mup> Bug #1583333 opened: [2.0b5] duplicate key on startup: Key (vid, fabric_id)=(2, 0) already exists. <MAAS:New> <https://launchpad.net/bugs/1583333>
[21:29] <mup> Bug #1583349 opened: Minimum kernel set on node breaks commissioning : no image ubuntu/amd64/hwe-x/trusty/no-such-image/boot-kernel <oil> <MAAS:New> <https://launchpad.net/bugs/1583349>


[06:33] <Gunther_> Good morning!
[06:36] <Gunther_> Is an expert concerning u-d-f (vivid) available? We have a problem creating an image in Docker container (oem  generic-amd64). The generated image does not boot because it fails to locate the kernel.
[06:37] <Gunther_> Out of the Docker container the image works. The udev workaround is applied (ln -s /bin/true ...)
[06:38] <didrocks> Gunther_: hey! I guess ogra_ would be able to help you once he wakes up (few hours from now :))
[06:39] <Gunther_> thank you. I will wait for him :)
[07:11] <zzarr> tyhicks, -Wall and -Werror?
[07:44] <zyga> o/
[07:49] <Gunther_> didrocks: problem solved, and I did not need ogra :)
[07:51] <Gunther_> didrocks: the docker container used u-d-f from vivid, whereas the native installation had u-d-f installed from ppa:snappy-dev
[07:52] <dholbach> would it make sense to have packages have build-essential as an essential part of their build-packages declaration?
[07:53] <dholbach> it'd certainly simplify things if you're using 'snapcraft cleanbuild' and don't have to spell out things like make, g++ and others
[07:53] <didrocks> Gunther_: ahah, making sense!
[08:25] <zyga> jdstrand, tyhicks: https://github.com/ubuntu-core/snap-confine/pull/18/files
[08:33] <tptr> Hi, any word when ubuntu core 16.04 can be expected? (eagerly waiting for the newer docker version...:-)
[08:42]  * nhaines just waits for the pulseaudio interface.
[08:51] <zyga> nhaines: it's coming :)
[08:52] <zyga> nhaines: it's merged and an SRU under way
[08:52] <nhaines> zyga: \o/
[08:52] <zyga> tptr: 16.04 is out, you can use snappy on that version directly
[08:52] <zyga> tptr: as for an all-snap image, those are available as well but aren't finalized so you may need to re-flash a few times as we make big changes
[08:53] <zyga> tptr: also the tooling around those is evolving so expect ubuntu-device-flash to go away
[08:53] <nhaines> I have a little script that requires sox and then basically makes the same sound as the Enterprise NCC-1701-D's warp engines... perfect for background noise!  :D
[08:56] <nhaines> And the moment the pulseaudio interface is available, I'll be all set!
[08:57] <ogra_> you should make that a commercial app ... you will get rich in no time
[08:57] <nhaines> ogra_: haha, tempting!
[08:58] <nhaines> The code *is* available in my book, so a for-pay snap wouldn't be unconsciable.
[09:04] <tptr> zyga: thx! I am using snappy on an Intel compute stick. So sg like ubuntu-16.04-snappy-amd64-generic.img.xz would b what I am after...
[11:43] <kyrofa> zyga, images are available? Where are they?
[11:48] <lool> ogra_, sergiusens: Ah right, I see vejmarie solved the locale issue in the end  :-)
[11:48] <ogra_> yeah, just answered your mail :)
[11:48] <ogra_> in fact the locale manpage tells you how :)
[11:48] <erio> Wait
[11:49]  * ogra_ waits
[11:49] <erio> I am having a locale issue too, can someone send links
[11:49] <erio> ?
[11:49] <ogra_> http://manpages.ubuntu.com/manpages/xenial/en/man1/locale.1.html
[11:49] <ogra_> scroll to the bottom
[11:49] <lool> oh god, people can override locales with env vars
[11:50] <lool> strings often contain %s and what not
[11:50] <ogra_> here is also an old snap http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh (currently not functional, not fully proted to 16, but you should get what it does)
[11:50] <erio> Thanks, favoriting all of this
[11:51] <erio> https://github.com/ericoporto/fgmkPackaging/blob/master/snap/snapcraft.yaml
[11:51] <erio> Made a simple test, but was failing on locale
[11:53] <ogra_> http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml
[11:53] <ogra_> you want to ship locale and libc-bin in your snap as well
[11:54] <seb128> locales are workaroundable
[11:54] <seb128> code using bindtextdomain() not so much
[11:54] <ysionneau> tyhicks: Hi! Any news on the ptmx issue?
[11:56] <erio> Thanks ogra_   !
[11:56] <ogra_> :)
[12:33] <jdstrand> zyga: cool, thanks :)
[13:03] <vejmarie> great my snap has been approved !
[13:03] <vejmarie> ;)
[13:04] <ogra_> yay
[13:04] <vejmarie> but how does users find it ? I thought this was through "Ubuntu software" / Store interface in the GUI ?
[13:05] <ogra_> using "snap find" on the commandline ... or in the ubuntu-software tool
[13:06] <eriow> Have you tried searching using snap in command line?
[13:06] <ogra_> (not sure how fast the db of the tool is wrt getting the info about the new package though)
[13:06] <zyga> jdstrand: hey
[13:06] <zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/pull/20
[13:06] <zyga> jdstrand: trivial one
[13:07] <zyga> jdstrand: I just have a few patches, I will be working on cleanups in the code, making it nicer and less ifdefy
[13:13] <vejmarie> yes I see it in snap find ;)
[13:13] <vejmarie> but not in the software tool
[13:13] <vejmarie> (yet)
[13:19] <zyga> jdstrand: we also need to plan for new way to test anything
[13:19] <zyga> jdstrand: as we'll switch at some point (not today) to execing snap-exec
[13:19] <zyga> jdstrand: so the command line will almost entirely go away
[13:19] <zyga> jdstrand: we'll need some test-only environment variable
[13:20]  * jdstrand nods
[13:22] <zyga> jdstrand: I guess we can just have a secure_getenv-based test to exec a test playload (command) instead
[13:22] <zyga> jdstrand: sorry for making so many changes lately, I hope we can land seccomp filtering now
[13:23] <zyga> jdstrand: is the ubuntu kernel okay for that fature now/
[13:26] <jdstrand> zyga: seccomp arg filtering will work on any kernel with newer seccomp
[13:31] <sergiusens> dholbach I explicitly removed build-essential from this as it made building things that use nodejs incredibly and unnecessarily slow
[13:32] <dholbach> sergiusens, I see
[13:35] <vejmarie> quick question guys, how do you update manually the snap database ?
[13:36] <zyga> vejmarie: what do you mean exactly?
[13:36] <vejmarie> my colleague is looking at free cad within snap but when he kick snap find in a shell
[13:36] <vejmarie> he doesn't find it
[13:37] <zyga> vejmarie: that's always server side
[13:37] <zyga> vejmarie: is that snap published?
[13:37] <vejmarie> yes
[13:37] <zyga> vejmarie: is it published to series 16
[13:37] <vejmarie> I can see it on my system
[13:37] <vejmarie> yes
[13:37] <zyga> vejmarie: is he running snapd 2.0.5? (the latest one)
[13:37] <ogra_> ogra@styx:~$ snap find|grep freecad
[13:37] <ogra_> freecad                    0.17                       -        This is the first beta for freecad 0.17 supporting OCCT 7 / Netgen and new Smesh version
[13:37] <zyga> vejmarie: can he snap install freecad?
[13:38] <vejmarie> the main difference is that I am running 16.04 Desktop
[13:38] <ogra_> i definitely see it on my xenial lappie
[13:38] <vejmarie> he is running the server one
[13:38] <vejmarie> with X installed on it
[13:38] <ogra_> and i also see it in ubuntu-softare when i search for freecad
[13:39] <zyga> vejmarie: that's no different
[13:39] <ogra_> now ... why do i have to sign in to U1
[13:39] <vejmarie> I do not see it in ubuntu software
[13:39] <ogra_> i instaalled snaps yesterday and already did that ...
[13:39]  * ogra_ sighs ... not a nice experience
[13:40] <vejmarie> he is running 2.0.3
[13:40] <vejmarie> we are upgrading
[13:40] <zyga> vejmarie: yeah upgrade to 2.0.5
[13:41]  * ogra_ watches it installing now
[13:41] <erio> ogra_: the old Ubuntu Software Center, even non snap related, had this losing logging every time problem.
[13:42] <ogra_> i wouldnt mind it if i had no 2fa enabled ... it is just super annoying to search my phone every time i use sw-center
[13:46] <sergiusens> ogra_ not necessary with `sudo` I believe
[13:46] <ogra_> sergiusens, sudo ?
[13:46] <sergiusens> ogra_ `sudo snap install freecad`
[13:46]  * sergiusens is installing freecad now
[13:47] <ogra_> sergiusens, i clicked on the organge paper bag in my launcher :P
[13:47] <erio> Is there a way to publish a snap to the store, but make it invisible to others? I wanted to test, but using the store as provider. Similar to ppa maybe.
[13:47] <ogra_> sergiusens, and ubuntu-software demands a new U1 login ... even though i did that yesterday when trying out another snap
[13:48] <sergiusens> erio that should be coming soon iirc. nessita might have the details
[13:48] <ogra_> now it would be really nice if the dash found any snaps that i search for :/
[13:48] <erio> Ok, thanks surgiu sen, that would be great. Ma
[13:49] <erio> Or maybe like Steam Early Access, just to put out really beta things, but that people using know upfront that the app is far from "finished
[13:49] <erio> "
[13:50] <nessita> sergiusens, details about...? :-)
[13:51] <vejmarie> good luck sergiusens
[13:51] <ogra_> nessita, to late, you are on the hook
[13:52] <vejmarie> do not forget to connect the snap to the interfaces
[13:52] <ogra_> so should the dash find any of the snaps i installed yet ?
[13:52] <ogra_> (definiely doesnt here)
[13:52] <vejmarie> by the way we still do not see free cad in ubuntu-software
[13:53] <vejmarie> how do you connect to a user account through the tool ? I didn't find this option
[13:53] <ogra_> if i search for "freecad" i see it here
[13:53] <kyrofa> nessita, details about private snaps
[13:53] <vejmarie> I think I am currently using the store without being connected to it, and perhaps do not have the credential to see my snap ;)
[13:53] <ogra_> works if i start it from a terminal :)
[13:54] <kyrofa> erio, for beta things we have the concept of "channels." edge, beta, candidate, and stable
[13:54] <ogra_> the fonts are slightly awful ... but it runs and all :)
[13:54] <kyrofa> erio, if something isn't stable, don't put it on the stable channel and the users who want to try out the unstable version can use another channel
[13:54] <ogra_> wheee !!!
[13:55] <ogra_> switching to german actually gets me german !
[13:55] <erio> Nice kyrofa_ thanks. Will look into it.
[13:56] <erio> This is the docs kyrofa ? https://developer.ubuntu.com/en/snappy/guides/channels/
[13:58] <kyrofa> erio, yeah, though that seems kind of specific to ubuntu core
[13:59] <vejmarie> ogra_: what are you testing ?
[13:59] <ogra_> vejmarie, freecad :)
[13:59] <kyrofa> erio, when you publish your snap, you just check the boxes for the channel(s) you'd like it to be released into
[13:59] <vejmarie> ogra_: good to see it switching from languages
[13:59] <ogra_> yeah
[13:59] <vejmarie> ogra_: I have noticed the font issues
[13:59] <vejmarie> this is a problem within the python code
[14:00] <ogra_> it actually seems to ship quite a few fonts
[14:00] <vejmarie> I am working on fixing it at the present time, but I am not yet an expert
[14:00] <davidcalle> erio, kyrofa: yeah, this doc is mostly for core images themselves, although, it gives an overview of our concept of channels
[14:00] <vejmarie> yes it ship the font
[14:00] <vejmarie> but looks for them in the wrong places
[14:00] <ogra_> ah
[14:00] <vejmarie> which explain why it default to ugly ones
[14:00] <vejmarie> I need to fix the code upstream
[14:00] <kyrofa> davidcalle, indeed
[14:02] <ogra_> vejmarie, well, in any case ... GOOD WORK !
[14:04] <vejmarie> thanks
[14:04] <vejmarie> I might be fixing the font during the night and we shall be good
[14:04] <vejmarie> then I need to find a way to run highly build and automatize updates
[14:05] <vejmarie> and we shall be good for ubuntu support
[14:05] <vejmarie> (I normally do MacOS build)
[14:05] <vejmarie> I shouldn't say that there, people will stop to speak with me
[14:13] <sergiusens> vejmarie freecad launched ;-)
[14:13] <vejmarie> good ;)
[14:13] <sergiusens> vejmarie it has been a while since I last used it. I'll try it out later in the day
[14:14] <sergiusens> vejmarie one sugary thing you can do is name the `FreeCAD` in apps just to be `freecad`, then you can launch it from the cli by just typing in `freecad` instead of `freecad.FreeCAD`
[14:15] <sergiusens> up to you though ;-)
[14:15] <vejmarie> no problem. Be careful this is a developper version (latest git), so there might be bugs
[14:15] <vejmarie> yep I will upgrade that, this is my first snap still need some cleanup
[14:15] <sergiusens> vejmarie ah, for developer versions and to make your users not run into unexpected expectations, you should use the approriate channels when publishing ;-)
[14:16] <vejmarie> yes do not worry this is my intend, I moved the channel temporarly
[14:16] <vejmarie> as to see if I can see it in the store (which is still not the case !)
[14:16] <vejmarie> I will update it tonight when I will have understood why my store can't see it
[14:17] <vejmarie> I would like to run nightly build and distribute it through snap which seems to be the best way to test a few crazy features into free cad which has some very heavy dependancy (OCCT is a massive stuff)
[14:21] <vejmarie> by the way sergiusens, I think the developer version is quite stable
[14:31] <vejmarie> if needed I can build a stable version
[14:35] <kyrofa> vejmarie, no need if you think it's stable enough-- the beauty here is that it's all your call!
[14:36] <kyrofa> vejmarie, the only limitation as I understand it is that you can't release a snap that _requires_ devmode into stable channels
[14:37] <ogra_> now you just need to convince apple to support snaps too ... and only have to roll one package ;)
[14:38] <vejmarie> kyrofa: it doesn't needs devmode ;)
[14:38] <kyrofa> vejmarie, then you're all good
[14:38] <vejmarie> ogra_: might be a challenge
[14:38] <ogra_> yeah, thats the most awesome bit :)
[14:39] <ogra_> vejmarie, just a "small" one :)
[14:39] <vejmarie> :)
[14:42] <roadmr> heya folks, I have a theoretical question :) how would I snap something like e.g. vim, which I'd like to be able to access pretty much any file in the system? not only in $HOME but say in /etc...
[14:45] <ogra_> you would tell users to use --dvemode
[14:45] <ogra_> *devmode
[14:45] <ogra_> or wait til some content charing mechanism is in place that you can hook into
[14:46] <ogra_> *sharing
[14:46] <roadmr> is that planned?
[14:46] <ogra_> well, unity8 has it ...
[14:46] <roadmr> because devmode has other implications as well, right?
[14:46] <ogra_> it makes the snap run unconfined
[14:47] <ogra_> but thats peobably what you want for an editor anyway
[14:49] <kyrofa> ogra_, I'm not sure the content sharing thing is what you want there, since I believe that's for inter-snap relationships
[14:51] <kyrofa> roadmr, if vi isn't unconfined you need to limit where it can write-- can't have it both ways
[14:51] <kyrofa> roadmr, sorry, my double negative made that hard to read
[14:53] <elopio> ~
[14:53] <sborovkov> hello, Is there some env variable for snap's common directory?
[14:54] <zyga> sborovkov: AFAIR not yet but I may have rusty memory
[14:54] <zyga> sborovkov: but there's a way to reach it using ../something/something reliably
[14:54]  * zyga looks
[14:55] <kyrofa> sborovkov, not yet
[14:55] <kyrofa> sborovkov, you can get to it via SNAP_DATA/../common
[14:55] <sborovkov> understood. thanks.
[14:56] <kyrofa> sborovkov, the user-specific one is SNAP_USER_DATA/../common, but the launcher doesn't have the smarts to create it just yet
[14:56] <kyrofa> (so it's not actually usable, sorry about that)
[14:56] <kyrofa> But the system wide one (next to SNAP_DATA) works fine
[14:57] <zyga> kyrofa: thanks
[14:58] <kyrofa> zyga, no problem. sborovkov they'll be named soon!
[14:58] <kyrofa> niemeyer, ^^
[15:06] <kyrofa> elopio, test test
[15:07] <elopio> works.
[15:10] <plars> xcb
[15:10] <plars> err
[15:10] <plars> kyrofa: hi, I found https://github.com/kyrofa/qt-example-snaps/blob/master/systray/parts/plugins/x-qmake.py which was really helpful
[15:10] <plars> kyrofa: I was wondering if there are plans to include it in snapcraft?
[15:11] <plars> kyrofa: also, I am hitting an error with qt things that I try to snap, wondering if you've seen it:
[15:11] <plars> This application failed to start because it could not find or load the Qt platform plugin "xcb"
[15:16] <kyrofa> plars, I wasn't planning on it, I was just collecting some qt examples there, but I suppose it could be
[15:16] <sergiusens> plars use `after` qt5conf` and in command do `command: qt5launch <cmd>`
[15:17] <kyrofa> plars, you need the stage-package I have there
[15:17] <kyrofa> And yes, the qt5conf bit
[15:17] <sergiusens> kyrofa we should add the plugin, tag it experimental if you think it is not prime time ready yet
[15:18] <kyrofa> sergiusens, I'm good with that. I wonder if kgunn might give us a review to make sure it's decent
[15:18] <sergiusens> kyrofa maybe jamiebennett wants to contribute a plugin :-P
[15:18] <kyrofa> plars, sergiusens oh oops, I didn't actually read the whole link, I thought plars was talking about the example, not the plugin. Yeah that should definitely be included
[15:19] <plars> yes, the plugin itself would be really useful
[15:19] <kyrofa> plars, agreed, we'll get that in there
[15:19] <plars> sergiusens: kyrofa: I'll give the qt5conf bit a try, thanks!
[15:19] <kyrofa> plars, we even have a bug for it.
[15:19] <plars> err, qt5launch
[15:20] <kyrofa> plars, yeah, refer to https://github.com/kyrofa/qt-example-snaps/blob/master/systray/snapcraft.yaml for details
[15:20]  * jamiebennett hides
[15:20] <kyrofa> jamiebennett, know anything about qmake?
[15:21] <jamiebennett> I know how to spell it ;)
[15:21] <sergiusens> jamiebennett that's a starter :-P
[15:21] <jamiebennett> But thats about it
[15:22] <sergiusens> elopio have you tried manually uploading with https://github.com/ubuntu-core/snapcraft/pull/532 ?
[15:22] <elopio> sergiusens: yes.
[15:22] <sergiusens> elopio than yay!
[15:23] <plars> sergiusens: kyrofa: that seems to have worked great, thanks!
[15:23] <kyrofa> jamiebennett, haha, no pressure, but if you feel like poking at snapcraft it should be a fairly easy one. Happy to take it though
[15:24] <kyrofa> plars, excellent! And thanks for the qmake poke
[15:25] <elopio> sergiusens: want me to update and rerun the tests?
[15:29] <kyrofa> kgunn, any chance you'd be willing to review a qmake plugin?
[15:29] <kgunn> kyrofa: sure
[15:29] <kgunn> i may not be the best...but i can always get some support there
[15:30] <kyrofa> kgunn, thanks-- I'm sure you'll be better than me! I'm mostly unclear about qt4 versus qt5
[15:31] <elopio> sergiusens: kyrofa: jamiebennett: fgimenez: yesterday I got a green execution of snapcraft all-snaps in bos01.
[15:31] <jamiebennett> \o/
[15:31] <elopio> I can work on getting the all-snaps images updated everyday there.
[15:32] <jamiebennett> elopio: Great work
[15:32] <kyrofa> Awesom elopio!
[15:32] <elopio> zyga: can you give me a short summary of the ubuntu-image status? Can I use it to generate images with core/edge ?
[15:32] <kyrofa> With an e
[15:33] <fgimenez> elopio, great!
[15:34] <elopio> fgimenez: to take into account when uploading the images, we need to pass the arch property, and also the hypervisor.
[15:35] <kgunn> kyrofa: was there a pull request, i checked your github activity didn't see it...
[15:35] <kyrofa> kgunn, oh no, sorry-- I'll ping you once I have something
[15:35] <kgunn> oh...nw
[15:35]  * kgunn goes back to being buried ;-P
[15:37]  * kyrofa shovels more dirt on kgunn
[15:49] <zyga> elopio: no, I'm busy with other tasks and I don't think that anyone else is touching it
[15:50] <elopio> zyga: ok, np, we will keep using the hacked one.
[15:51] <zyga> elopio: I think it is on my plate right after my current task
[15:53] <ysionneau> hmm for the extlinux.conf, am I supposed to put it inside the gadget snap ? or the kernel snap ?
[15:55] <zyga> ysionneau: what is extlinux.conf?
[15:57] <ysionneau> some kind of menu config for u-boot
[15:57] <ysionneau> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/boot-assets/uboot.env.in < the uboot script searches for it
[15:57] <zyga> ysionneau: that will be the gadget snap but only after the new ubuntu-image is in place
[15:57] <zyga> ysionneau: contributions are very much welcome
[15:58] <zyga> ysionneau: look at github.com/CanonicalLtd/ubuntu-image for details (there's a spec for gadget's image.yaml)
[15:58] <zyga> ysionneau: that desribes how to put the image togeter
[15:58] <ysionneau> ah, thanks!
[15:59] <ysionneau> this ubuntu-image is the replacement for UDF ?
[15:59] <sethj> looking through the latest snapd changelog it mentions a debian import/patch that fixes the XDG path issue. Does that mean this bug was fixed?
[15:59] <sethj> https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576303
[16:00] <zyga> ysionneau: yes
[16:00] <zyga> ysionneau: I can tell you anything you want to know about it
[16:00] <zyga> ysionneau: but I'm not currently working on it (preempted by other tasks)
[16:00] <ysionneau> fair enough!
[16:00] <zyga> ysionneau: I was going to implement and test the x86 side (there's no real difference but I was going to make new gadget snaps firsts)
[16:01] <zyga> ysionneau: but I would love someone to look after uboot side (again, no real difference for u-i)
[16:01] <ysionneau> well, if I can help somehow don't hesitate to ask
[16:03] <zyga> ysionneau: sure
[16:03] <zyga> ysionneau: you can help a lot by doing one simple thing
[16:04] <zyga> ysionneau: read the image.yaml spec there
[16:04] <zyga> ysionneau: and tell me how you'd describe an image using uboot
[16:04] <zyga> ysionneau: make a demo .yaml, stick it in a branch
[16:04] <zyga> ysionneau: at the same time, look at ...
[16:04]  * zyga looks
[16:05] <zyga> ysionneau: look at this http://paste.ubuntu.com/16922791/
[16:05] <zyga> ysionneau: this is a shell "prototype"
[16:06] <zyga> ysionneau: see if you can make a prototype like that, in shell, that assembles the image
[16:06] <zyga> ysionneau: use local snaps for everything (u-i downloads them but let's not worry about that)
[16:06] <ysionneau> hmmmm
[16:06] <zyga> ysionneau: if you can make that prototype and the corresponding image.yaml that will help me a lot
[16:07] <zyga> ysionneau: we have some code that takes the .yaml file and handles it so that we can create such shell scripts
[16:07] <ysionneau> I've made a shell script to generate "image" for my board from rpi2 snaps :o
[16:07] <ysionneau> is that of any interest?
[16:07] <zyga> ysionneau: yes!
[16:07] <zyga> ysionneau: note that u-i has one major design change from udf
[16:07] <ysionneau> https://github.com/fallen/snappy-tools/blob/master/paros_image/genimage.sh
[16:07] <zyga> ysionneau: it doesn't run any code that's system specific or that's shipped by the gadget
[16:07] <zyga> ysionneau: all the code is either generic (making partitions, filesystems, pupulating filesystem)
[16:07] <kyrofa> sergiusens, do you know anything about bug #1587193?
[16:07] <elopio> sergiusens: didrocks: If you get an error on jenkins saying something bos01, it was my fault. I'm reverting that. Sorry.
[16:07] <zyga> ysionneau: or the gadget has to ship a blob that we just stick at a given offset
[16:08] <zyga> ysionneau: so images should be 100% reproducible
[16:08] <zyga> ysionneau: the blobs can be built by the gadget snap
[16:08] <zyga> ysionneau: but similarly to how snaps are built, that's done while the gadget snap is being built
[16:08] <zyga> ysionneau: not when the image is assembled
[16:08] <zyga> ysionneau: the image is more of a linker
[16:08] <zyga> ysionneau: and takes pre-built things
[16:08] <zyga> ysionneau: does that make sense?
[16:09] <ysionneau> IIUC, the image.yaml is describing the flash layout and partitioning scheme and which file to flash where?
[16:09] <zyga> ysionneau: so your script would need to be split into something that you can snapcraft (or make) into a gadget.samp (containing image.yaml, files to put into filesystems, blobs to put into a fixed offset)
[16:09] <zyga> ysionneau: it describes how to create a big blob out of other "parts"
[16:10] <zyga> ysionneau: some of those parts are filesystems that it can populate
[16:10] <ysionneau> ah ok a big flashable blob
[16:10] <zyga> ysionneau: either with files from the gadget or with magic stuff to make the core snap work
[16:10] <ysionneau> right
[16:10] <zyga> ysionneau: and some other parts are just fixed blobs to stick somewhere (not a filesystem, not a partition)
[16:10] <zyga> ysionneau: e.g. boot code in the MBR
[16:10] <zyga> ysionneau: or stage-2 grub in the bios bootloader partition
[16:10] <zyga> ysionneau: or modem binary on dragon. etc
[16:11] <zyga> ysionneau: if you start to arrange your script into two scripts
[16:11] <zyga> ysionneau: one that builds the blobs or gets them from somewhere
[16:11] <zyga> ysionneau: does any computing needed
[16:11] <zyga> ysionneau: and spits out a gadget.snap
[16:11] <zyga> ysionneau: and another that is more akin to what I pasted as the prototype in shell
[16:11] <zyga> ysionneau: then we can align nicely
[16:11] <zyga> ysionneau: if you see any issues in this desing please tell me early
[16:12] <zyga> ysionneau: but I think the idea is flexible enough to build virtually any image (on any host OS)
[16:12] <ysionneau> one thing I think is important to say, here the input format for our flashing tool is a .tar, and not a .img
[16:12] <zyga> ysionneau: and without having to change ubuntu-image in any way (hence declartive image.yaml and prebuilt stuff in the gadget)
[16:12] <zyga> ysionneau: what is the tar content?
[16:12] <ysionneau> to flash, we basically send (via DFU or other) a bootloader, a kernel, and an installer (an ELF)
[16:13] <ysionneau> then we speak through USB to the installer
[16:13] <zyga> ysionneau: I see
[16:13] <zyga> ysionneau: that's okay
[16:13] <zyga> ysionneau: for 0.1 I'd like to just make an image reliably
[16:13] <zyga> ysionneau: for 1.0 we can export parts into various other formats
[16:13] <zyga> ysionneau: you can always take the image and export those with post-processing tools
[16:13] <zyga> ysionneau: all that is important is that the image can be built reliably and (perhaps) with 100% reproducibility
[16:14] <zyga> (apart from things like partition IDs but perhaps snapd will manage those on first boot, time will tell)
[16:14] <zyga> ysionneau: please stay in touch, I want to ensure you are supported
[16:14] <zyga> ysionneau: and please do consider hacking on ubuntu-image, I will gladly review patches and take new features
[16:16] <ysionneau> 18:12 < zyga> ysionneau: what is the tar content? < basically the entire file system(S)
[16:17] <ysionneau> it's nice that it is in Python and not go anyway
[16:17] <zyga> :-)
[16:17] <ysionneau> cause I can hack on Python and not at all on go =)
[16:17] <zyga> ysionneau: and I think it should be fairly small and well-defined
[16:17] <zyga> not open-ended like u-d-f with ever-growing list of "supported boards"
[16:17] <didrocks> elopio: thanks for the head's up!
[16:18] <ysionneau> to be more precise about our flashing process : we send a big .tar through USB and the installer 1°) formats the eMMC with the partition scheme 2°) mounts  partitions 3°) extracts the tar
[16:18] <ysionneau> the fact that we mount the partitions before untaring allows to put contents for several partitions in the same .tar file
[16:18] <zyga> ysionneau: note that ubuntu-image is precisely not ubuntu-flash
[16:18] <zyga> flashing is a separate tool that I'm not making today
[16:18] <ysionneau> (eg system-boot and writable)
[16:19] <ysionneau> yes but the image generation tool should be able to produce a file that can be processed by the flashing tool, right?
[16:19] <ysionneau> anyway, about the image generation process, Nvidia tools are doing a bit what your image.yaml is doing, except they use .xml
[16:20] <ysionneau> you either specify an .img for each partition, or a blob and that's it
[16:20] <zyga> ysionneau: that's a little open-ended, I think we will just make an image (intially), later on we might natively produce separate bits (just filesystem contents and the like)
[16:21] <zyga> the flashing tool is complex because there are lots of different things to do there
[16:21] <zyga> ysionneau: as long as we can take the  big image and build a target-specific tool that flashes it (doing anything it needs internally), I think we are good
[16:21] <zyga> ysionneau: can you point me to those tools? I'd like to know this better
[16:35] <tyhicks> zzarr: I accidentally highlighted your name with the message about -Wall and -Werror but meant to highlight someone else - sorry about that!
[16:35] <tyhicks> ysionneau: sorry but I haven't been able to debug it any more
[16:37] <ysionneau> zyga: Parrot tools unfortunately are not open source :/
[16:37] <ysionneau> and Nvidia ones, I don't know
[16:37]  * elopio <- afk.
[16:38] <ysionneau> zyga: I've got to go, maybe I can drop you an email with more precise info about our image generation / flashing process?
[16:39] <zyga> ysionneau: thanks
[16:39] <zyga> ysionneau: please do
[16:39] <zyga> ysionneau: do you have my address?
[16:40] <ysionneau> zyga: yes :)
[16:41] <ysionneau> see you soon!
[16:52] <zzarr> tyhicks, no problem, shows you are human :-)
[20:10] <kgunn> zyga: you about? finally got round to trying vm --visual, with mir i/f builtin to snapd
[20:10] <kgunn> curious, if i install mir-server snap...i see mir:mir-server under the plug column
[20:11] <kgunn> i would;ve thot mir slot would've shown up w.o mir-server snap being installed?
[20:12] <kgunn> e.g. it only appears in the interface list after mir-server snap installation
[21:16] <jdstrand> sergiusens: hey, looking at bug #1583259 I'm trying to understand what ends up in snap.yaml. snapcraft.yaml is clear-- will snap.yaml be the same or different?
[21:17] <sergiusens> jdstrand it will be a direct copy, a global `environment` (same level as `name`) and one special to each app in `apps`
[21:17] <sergiusens> jdstrand the consumer for this is snap-run
[21:20] <jdstrand> sergiusens: ack, thanks
[21:27] <zyga> kgunn: hmm
[21:27] <zyga> kgunn: can you please re-state that?
[21:27] <zyga> kgunn: which snaps did you install
[21:27] <zyga> kgunn: in what order
[21:27] <kgunn> zyga: sure...more a matter of curiosity as i see mir trying to launch...but here's what i did
[21:28] <kgunn> used your run-devel-vm --visual, then rebuilt snap/snapd, setup, run-snapd, then on the vm ./devtools.snap installed mir-server snap
[21:29] <kgunn> rebuilding snap/snapd b/c i added the mir interface to builtins
[21:29] <kgunn> literally "mir" being the interface name
[21:29] <zyga> okay
[21:29] <zyga> ah
[21:30] <zyga> hmmm
[21:30] <zyga> can you please point me to the mir interface?
[21:30] <zyga> it depends on how you made the interface
[21:30] <zyga> you can think of mir-server having a mir socket
[21:30] <zyga> s/socket/slot/
[21:30] <kgunn> zyga: i actually figured you were gonna say that :)
[21:30] <zyga> then the slot grants you permissions
[21:30] <zyga> and it's not on the core snap
[21:30] <zyga> (I think that is what we wanted)
[21:30] <zyga> you can also stick it on the core snap but I think that's less desired
[21:31] <zyga> because what we are still after is the mir plug for some demo client to run and talk to mir snap
[21:31] <zyga> in any case, I'm very happy that it's progressing and that the tooling around snapd works fine
[21:31] <zyga> if you have any questions please do ask
[21:32] <kgunn> so i implemented them as "permanent slot"
[21:33] <kgunn> and at this point, i'm not even to mir-client...this is just to get mir-server running on the core
[21:34] <kgunn> and i should be able to make some progress, like i say..i see mir-server trying to launch
[21:38] <zyga> kgunn: so the permissions to 'be mir' are on the permanent side of the mir slot?
[21:38] <zyga> kgunn: that sounds good
[22:36]  * zyga watches tests fly past his screen
[23:59] <kallisti5> any plans for 16.04 based snappy core?