=== hwang4 is now known as hwang4-afk [01:09] Domi, I am *trying* to [01:14] What is your problem when using python? === chihchun_afk is now known as chihchun === not_phunyguy is now known as phunyguy === not_phunyguy is now known as phunyguy === chihchun is now known as chihchun_afk [08:44] zyga: later today [08:44] need to finish a bunch of non-snappy stuff first [08:44] sure, thanks [08:56] hello [08:57] hey [09:02] I'm wworking with what is called snappy for IOT and I've been having problems with 15.04 and 16.04. I need webdm, Webdm for 15.04 does not exist in the market. Hoping that webdm is present in the 16.04 market i tried to use it but this version of ubuntu-core is not present in the default ubuntu-device-flash server. Can someone help me? [09:04] Besides, the snappy-tools package is not present in the 16.04 desktop. but this is another problem. [09:04] s/16.04 desktop/16.04 snappy-tools repo/ [09:05] 15.04? [09:05] You lost me right there. [09:07] you don't read? it could be my client [09:08] hi [09:10] someone knows if webdm is going to be reintroduced in 15.04? (i tried to use 16.04 but it is not available) (i'm talking about snappy for "iot" armh) [09:13] ok I see that webdm was reintroduced in the 15.04 market. [09:15] pippo: Where do you see that? [09:29] pippo: 16 is not released yet [09:30] pippo: webdm should be available in the store soon but is still under development [09:30] pippo: 15.04 is almost guaranteed not to be supported anymore AFAIK [09:30] pippo: (webdm soon == for 16) [09:36] what is not available ? webdm for 16.04 or 16.04 core? ubuntu-core 16.04 is not present in the default ubuntu-flaash-device server. [09:37] nothing yet [09:37] all that is available is the source under development === chihchun_afk is now known as chihchun [10:01] ogra_: I think we need an initramfs update for uboot on x86, I will work on this in a bit, it seems like it is acting really silly [10:02] mvo, oh ? [10:03] given that only grub bits were dropped from the image that is weird [10:03] it shouldnt behave any different from uboot on armhf [10:03] (i havent seen any arch specific code ) [10:07] ogra_: the initramfs code is just plain silly, I upload in a bit once you see the diff it should be obvious [10:08] there is a lot silly stuff in the old initrd code :) [10:08] ogra_: yes :) [10:08] ogra_: I'm just double checking a few things before the upload to not make things worse [10:08] mvo, btw, should we perhaps rename /etc/system-image before final ? [10:08] i know thats just cosmetic ... :) [10:08] ogra_: yeah, good idea [10:08] but the german in me screams seeing it all the time there :) [10:09] ogra_: what german in you?!? [10:10] lol [10:11] ogra: i'd like to generate snappy-tools (for 16.04 desktop) and ubuntu-core 16.04 (for arm) from sources, is there some doc? (for the second one I suppose this is the place: https://github.com/ubuntu-core/snappy) [10:11] pippo, the latter one happens in your image build infrastructure ... thats rather complex [10:12] we use live-build to create the rootfs snaps with the configuration from the livecd-rootfs package in the archive [10:13] well, I have to migrate from 15.04 to 16.04. If the packages are not available from ubuntu-device-flash to download I have to generate it somehow. [10:13] "complexity" is not a problem ;) [10:14] what do you mean by " If the packages are not available " [10:14] mvo, so amd64 building fails ... [10:15] boot/ubuntu bind mount failed with: exit status 32 mount: mount point /tmp/diskimage835456834/system/boot/grub does not exist [10:15] pippo: core snap is available but the kernel and gadget snaps are being redesigned [10:15] seems we need a mkdir in u-d-f [10:15] i mean that 16.04 is not here: https://system-image.ubuntu.com/ubuntu-core/ [10:15] pippo: so no matter if you can build stuff from source, you will also chase a moving target [10:15] zyga, well, all sbnaps are "available" currently [10:15] both, in the store and on cdimage.ubuntu.com [10:15] ogra_: "yes" [10:16] ogra_: "available" but not released [10:16] and they usually produce bootable images [10:16] usually :) [10:16] * zyga loves our optimism [10:16] well, the ones in the store "always" :) [10:16] "this bridge is not finished but we let people use it every day, trucks too" [10:16] "it ususally doens't fall apart" [10:16] "we rebuild it every night too" [10:17] "last night it was blue" [10:17] cdimage is currently broken due to the "uboot on i386" crazyness :) [10:17] but the store is a manual thing ... i personally dont uzpload anything that i didnt smoketest [10:17] in the end we'll build a tunnel [10:18] you might need to re-flash them if format changes, but you shoudl always be able to use the userspace for testing development stuff [10:18] At Release Day, disk image uploads quiet down, right? [10:19] we're rolling :) [10:19] So, we have to fix that. [10:19] release day only marks when we start with that officially ;) [10:19] Software is hard. :( [10:19] usually hardware is hard [10:19] software just ships broken [10:20] but has a splash screen so it's all good [10:21] the really good SW has a splash *and* a progressbar [10:22] while being on fire ;) === chihchun is now known as chihchun_afk [11:22] mvo, woah ... so your image build failed ... in chpasswd for the ubuntu user ?!? [11:24] * ogra_ doesnt get why that would fail all of a sudden [12:00] ogra_: eh, that is very surprising [12:15] Good morning [12:27] mvo, yeah, totally not logical ... nothing changed [12:39] ogra_: friday failure syndrome [12:40] zyga, well, there is no reason at all why it could fail ... no code changes, no changes in the archive that could even remotely touch chpasswd behaviour [12:40] ogra_: we saw totally weird autopkgtests errors this morinng [12:40] but it now fails reproducable [12:40] ogra_: no idea what the cause ise [12:40] is* [12:41] * ogra_ starts a yakkety build ... to check if that fails too [13:13] mvo, yakkety builds :/ [13:13] ogra_: all broken? [13:13] xenial, yes [13:13] yakkety not ... [13:14] the only thing that changed in the archive since the last working xenial build was bind9 [13:14] but i see no reason why that should make chpasswd fail [13:22] Get:52 http://ftpmaster.internal/ubuntu xenial-updates/main arm64 libisc-export160 arm64 1:9.10.3.dfsg.P4-8ubuntu1 [124 kB] [13:22] Get:53 http://ftpmaster.internal/ubuntu xenial-updates/main arm64 libdns-export162 arm64 1:9.10.3.dfsg.P4-8ubuntu1 [534 kB] [13:22] Get:31 http://ftpmaster.internal/ubuntu xenial-updates/main arm64 debootstrap all 1.0.78+nmu1ubuntu1.1 [35.7 kB [13:22] the only three packages we get from xenial-updates [13:23] and debootstrap only adds a yakkerty link ... must be one of the two other libs [13:25] (which obviously come from bind9) [13:25] * ogra_ ponders to push a rool-back package to the PPA [13:25] *roll [13:27] jdstrand: hey [13:27] jdstrand: I found something curious/buggy yesterday [13:27] jdstrand: I wanted to ask you before proposing a fix [13:27] jdstrand: also seems like might be a CVE if you look at it the right way [13:44] mvo, oh, lovely ... bug 1576378 touches our bootloader work too ... [13:44] bug 1576378 in snapd (Ubuntu) "Snap installing doesn't work in live session" [Undecided,Confirmed] https://launchpad.net/bugs/1576378 [13:44] "can not set next boot: cannot determine bootloader" [13:55] ogra_: oh, right [13:55] hmm [13:55] i guess firstboot will also barf with the /boot/grub dir returned in the rootfs [13:56] do we have any i386 uboot gadget yet that we could test with ? [13:56] ricmm, ^^^^ ? [13:56] not from me, we need AceLan for that and Taipei is asleep [13:56] hmm, k [13:57] send him an email [13:57] i will, once i got the images back to building [13:58] * ogra_ hopes the bind9 rollback will fix us [13:58] sounds terrible [13:58] it is [13:59] and it ate my day so far :) [14:00] ogra_: could be worse :) [14:01] yeah,. it could rain or some such ... [14:04] * ogra_ taps foot waiting for the arm PPA builders [14:37] kyrofa care to take a glance at https://github.com/ubuntu-core/snapcraft/pull/480/files ? === pitti is now known as Guest30809 === Guest30809 is now known as pitti [14:42] sergiusens, sure, I'll trade you for my quickly bloating https://github.com/ubuntu-core/snapcraft/pull/454 [14:44] sergiusens, I'm starting to not like maintaining snappy docs in snapcraft. Things change without our knowing [14:44] kyrofa: interfaces? [14:45] zyga, like the removal of services, or --allow-unauthenticated [14:45] ah, yeah [14:45] Err, removal of snappy service [14:45] well, bumpy ride [14:45] zyga, perfectly natural, just makes for sloppy docs [14:46] zyga, since we don't realize we're out of date until we actually hit something [14:46] zyga, or someone complains :P [14:46] yeah, I completely understand and agree [14:47] finally, bind9 built ... [14:48] * ogra_ kicks an amd64 image with the rolled back version ... lets see [14:50] kyrofa, sergiusens: speaking of being out of date, the macaroon MP aims at reducing the gap between the store and snapcraft regarding '16', there are more work to be done still, but the switch from OAuth to macaroons should happen sooner rather than later to get feedback from users [14:57] sergiusens, kyrofa, FYI, we're dropping oauth support very soon [14:57] so without vila's branch, snapcraft will break soon :) [15:01] mvo, definitely not the bind9 upload ... still fails [15:04] * ogra_ rips livecd-rootfs from the PPA [15:06] next build running ... [15:10] hey! just wondering about icons on snap. not sure that putting a file "./setup/gui/icon.png" is working .. is there a GUI to see my installed snap and there icons ? [15:11] svij: nope, not yet [15:11] slvn: ^^ [15:11] sorry, svij: [15:12] zyga, ok np ! [15:13] mvo, so even removing all packages from the PPA (except your initrd change) make chpasswd fail [15:13] oh, crap [15:14] LP lied ... the livecd-rootfs package still comes from the PPA despite having been deleted [15:14] zyga, another remark: it seems to me libpng12.so is accessible (because I don't provide it in my snap). but libjpeg is not, so that I need to provide it in the snap to get jpeg image loaded through SDL2_image! [15:14] *sigh* [15:14] slvn: you need both, you cannot access libpng12.so from the OS [15:16] zyga, well it seems this is possible :/ all my png images gets loaded correctly ! (and when I do "ldd on my snap binary, it requires : libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f8eb9799000)) [15:17] slvn: indeed [15:17] * zyga wonders why we need libpng in the OS snap [15:17] slvn: it's safer to include your own copy [15:17] slvn: though I cannot say as to when we will remove libpng from the os snap or if we ever will [15:18] zyga, ok .. then I'll include it [15:24] ogra_: is there a nice tool / website that shows the seed for ubuntu-core and how it results in the effective set of packages included? [15:25] zyga, there might be some germinate wikipage, not sure [15:26] hi, does anybody know of an easy way to disable apparmor for created snaps for testing purposes? [15:26] quagland: install the snap with --devmode [15:26] quagland: yes, http://www.zygoon.pl/2016/04/snap-install-devmode.html [15:26] * jdstrand let's zyga handle it from here [15:26] :D [15:27] I just use my crude language skills to describe what I work with :) [15:27] beuno that branch was missing something rather important, unit tests; while that is being worked on I don't want to switch to it. [15:29] sergiusens: I thought that was settled with elopio, faked tests can be good while you can't test the real code, but this branch already test the real code so fakes are not needed and will only create paperwork [15:29] thanks for the --devmode argument, looks like still got some investigating to do - trying to get a java snap (with bundled jvm) working to no avail [15:30] sergiusens: with unit tests using fakes for Oauth, snapcraft will happily keep passing tests even when it stop working [15:31] vila, that's not an argument for having integration tests instead of units-- it's an argument for having both [15:31] sergiusens: with tests using real code both snapcraft and the server team have the opportunity to learn earlier that something broke [15:32] kyrofa: if the client and the server were in the same project they would be unit tests, just like a snappy command calls its internals [15:32] kyrofa: we don't have that, we have a staging server, that's better than fakes [15:35] vila, having tests that make sure we stay in sync with the real server is great. But we also need tests making sure our code works the way we think it does. Just because the server could change isn't a reason not to cover the code in unit tests [15:36] sergiusens, kyrofa: can we relax the definition of unit vs integration tests ? I don't think it helps getting progress. I'm focused on reducing the feedback loop between snapcraft and the store [15:37] kyrofa: and I don't think it helps anybody to know that the code does what he thinks it does if it does the wrong thing [15:37] kyrofa: don't get me wrong, [15:37] I've discovered some squashfs inconsistencies on pi2. http://paste.ubuntu.com/16127818/ [15:37] I /do/value layered and focused tests [15:39] kyrofa: and I like my test to allow reproducing and fixing bugs, fakes don't help with that and as far as the snapcraft part dealing with the server, fakes won't help either. I did ran into that when I started working on that branch [15:39] jdstrand: ^ this is related to why my nmap snap built on pi2 fails click-reviewers-tools [15:42] vila, the code doing the wrong thing as defined by what? By a service external to snapcraft. The snapcraft code would still be doing what it was designed to do, and passing its unit tests as a result. If that becomes the wrong thing with regards to the external service, that's exactly what an integration test is made to catch [15:42] You see how there are different layers here? [15:45] josepht: oh that will be helpful. I had this in a trello card but just filed bug #1576763 [15:45] bug 1576763 in click-reviewers-tools (Ubuntu) "pi2 images generate different checksums on repeated runs" [Undecided,New] https://launchpad.net/bugs/1576763 [15:46] josepht: can you check the version of squashfs-tools that the pi2 system is using? [15:46] josepht: also, attaching the offending snap would be great [15:49] jdstrand: I added both to the bug. Thank you [15:49] josepht: thank you! :) [15:51] jdstrand: my pleasure [15:53] mvo, mystery solved ... task header missing in initramfs-tools-ubuntu-core and ubuntu-core-config ... the latter ships the extrausers pam config ... that is why chpasswd failed [15:53] zyga, another thing I noticed : I don't know what is value of the current directory when running a snap. So I had to do a "chdir($env(SNAP))" to get file loaded correctly. [15:53] mvo still around, need to ask you SRU strategy questions and how you will deal with it [15:53] slvn: I don't think the directory is modified, I might be wrong [15:57] zyga, currently it is the real cwd (same as the shell). but the snap is confined .. so (for me) it's better to have it set to $env(SNAP). not sure what should be done [15:57] slvn: I think that's the desired behavior [15:58] ok [15:58] np [15:58] slvn: e.g. when the snap is using the home interface [15:58] kyrofa, sergiusens: sorry for the interruption, desktop crashed hard [15:58] (need to go away) [15:58] zyga, I don't use the "plug home" [15:58] I didn't get anything after: [15:58] kyrofa: and I like my test to allow reproducing and fixing bugs, fakes don't help with that and as far as the snapcraft part dealing with the server, fakes won't help either. I did ran into that when I started working on that branch [15:58] slvn: yes but if you did, would you expect snappy to behave differently for such a basic operation/ [15:59] ... and that wasn't a crash test ;) [15:59] vila, I didn't notice for a bit too long :P [15:59] vila, the code doing the wrong thing as defined by what? By a service external to snapcraft. The snapcraft code would still be doing what it was designed to do, and passing its unit tests as a result. If that becomes the wrong thing with regards to the external service, that's exactly what an integration test is made to catch [15:59] You see how there are different layers here? [16:04] kyrofa: then you're talking about the tests around _store.py which defines the internal API between snapcraft and the next layer which is storeapi, I can agree with that. But storeapi deals with the store [16:05] kyrofa: it cannot be tested without the store [16:05] kyrofa: the analogy would be for snapcraft to test without involving mksquashfs but fake it in memory [16:07] kyrofa: or testing the clean command without building a snapcraft.yaml [16:08] vila, how do you test error handling if you only talk to the real store? [16:08] vila to be clear you are saying that doing something like this https://github.com/ubuntu-core/snappy/blob/master/store/store_test.go#L179 is impossible? [16:09] kyrofa: for the edge cases where it's less effort to fake the errors, that's indeed what I did [16:09] sergiusens: not impossible, but less valuable as fakes bitrot [16:09] vila in the case of mksquashfs, we trust that the interface for that won't change (how it is called and what it will generate), but we make sure in a unit test we called it the right way [16:10] sergiusens: certainly fakes are better than not testing, but testing against the real thing is better than testing with fakes and when the real thing is available, why use fakes ? [16:10] vila fakes should not bit rot; you will not be around forever to keep this working, we need ensurance that when we change something it won't break badly [16:10] vila you don't understand, we need both [16:10] I am really really sad you don't see that [16:11] vila, we're not saying that we don't want to use the real store. Those tests are very valuable [16:11] sergiusens: I'm really sad that you don't see that using fakes means you will have to wait for your users reporting bugs rather than having the tests fail as soon as one side makes a wrong change [16:12] vila, in that case the integration tests fail [16:12] sergiusens: and if I won't be around, the test will [16:12] vila and if the store is down during maintenance? and if I want to develop while on an airplane? [16:12] kyrofa: you're back with the dichotomy between unit and integration, it's a continuum [16:12] vila, okay-- "in that case the tests with talk to the staging server fail" [16:12] s/with/which/ [16:13] fail if the server is down, skip if you're on the airplane [16:13] vila, how is that different than what you've currently done? [16:13] but if you're changing code dealing with the server on an airplane you can't test them either [16:14] vila, exactly. Not to mention such things are run in CI [16:14] vila, it won't merge if it's broken [16:14] vila bottom line, if the branch is not green, it is not landing; that means you cannot drop code coverage [16:14] vila if you don't want to do it, don't. [16:14] we will, but until then it does not land [16:15] ... [16:16] Snapcraft has the ability to upload snaps for publication in the Snappy Store. [16:16] If you're working on a feature that requires you to interact with the store, you [16:16] might want to use the staging server instead of the production store. [16:17] Your call, it's your project, I'm trying to help [16:17] vila, yeah, I think at this point, lets just roll with it [16:19] beuno vila so where is this part of the store documented for us to start working on it? [16:30] hi, I get this when running ubuntu-image to create a devel pi2 image : http://pastebin.ubuntu.com/16129071/ [16:30] any idea zyga ? [16:31] ysionneau: ! [16:31] ogra_: ^^ [16:31] is that the same thing? [16:31] ysionneau: I have no idea except that it seems to be everywhere now [16:31] ysionneau: are you on xenial or something else? [16:32] i've got a situation where my snap won't install due to a previous install attempt where it got stuck...so it now says "error: cannot install snap file: snap "mir-server" has changes in progress" [16:32] i have already rebooted [16:32] ysionneau, you didnt download the u-d-f from mvo today, did you ? [16:32] i looked at using snap abort [16:32] but how to find the change-id ? [16:32] kgunn: reboot wont help since snappy tracks changes in a persistent way [16:32] kgunn: snap changes [16:32] (that is in active development atm, might be broken) [16:32] kgunn: if all else fails rebuild the VM, I recommend using -snapshot for kvm boxes [16:32] kgunn: but I know you have special requirements [16:33] zyga: I'm on ubuntu mate 16.04 [16:33] hmmm seemed to work...returned id 1 [16:33] bugger...abort didn;t complain, but install still does... [16:33] ok, rebuilding image [16:34] ogra_: it's a brand new udf from mvo, yes [16:34] mvo: do you know anything about the squashfs magic number issue we saw in autopkgtests today? [16:34] I modified the sha512sum from ubuntu-image to make the script accept it [16:34] ysionneau, well, better roll back then [16:34] ah, and I guess I cannot download the old one can I? ;) [16:34] it is actively being changed atm [16:34] hmm, probably not [16:34] ysionneau: ubuntu-image keeps old versions [16:34] ysionneau: revert to earlier hash [16:35] ysionneau: if you ran that hash at least once it will work [16:35] (as in, it will run that udf) [16:35] ah, cool [16:36] ubuntu-image is transactional ;-) [16:36] wouldn't it be interesting to do versionning of those? [16:36] heh [16:36] like opening a git repository with udf binaries? [16:36] ysionneau: it would be much more interesting to not have to od htat [16:36] it would be interestiong to have a working version in the archive :) [16:37] and I think that's what we are trying to get :) [16:37] zyga: yes, I agree, but since it's been monthsthat we use this script and this binary [16:37] with this method of distribution (wget) [16:37] well, atm we're trying to get uboot into i386 :P [16:37] ysionneau: because we were focused on 16.04 [16:37] maybe we should at least do it right (with proper versioning) [16:37] ysionneau: it will be stabilized quickly now [16:37] high hopes :P [16:37] ogra_: what times we live in [16:37] uboot i386 [16:37] _i386_ [16:37] insanity [16:37] not even amd64 [16:38] next they will come and ask for grub on arm !!! [16:38] * ogra_ shakes head [16:38] heheh [16:42] zyga: none ofthe cached versions I have work :/ [16:43] does someone here have a working udf binary? [16:43] ysionneau: it's Friday [16:43] * zyga checks [16:44] zyga: the squashfs test is fixed, please merge master [16:44] mvo: \o/ thanks! [16:44] ysionneau: the copy I have doesn't work now [16:44] zyga: yw! Chipaca is the hero who did it [16:44] ysionneau, http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash that is the last one [16:45] mvo, YAY ! so after wasting my day on this we now have images building again ... [16:45] just finished :) [16:45] what a silly issue [16:45] so what was the true root cause? [16:46] zyga, missing XB-Task headers in PPA packages [16:46] what even is that? [16:46] if you dont use a metapackage for your seed, the packages get only a task header added ... that works fine in the archive [16:46] ogra_: meh, again [16:46] as soon as you upload to the PPA that header goes missing [16:47] ogra_: the headers are terrible [16:47] yes [16:47] ogra_: glad its fixed now [16:47] "fixed" [16:47] i hacked them in :P [16:47] ogra_: this one works, thanks! [16:48] * ogra_ triggers a full image set ... just to be sure [16:50] what a waste ... :( [17:36] Broken link https://developer.ubuntu.com/en/snappy/porting/ [17:37] mhall119: ^^ [17:37] From bottom of https://developer.ubuntu.com/en/snappy/start/ [17:50] zyga: you're famous: http://www.ubuntu.com/usn/usn-2956-1/ [17:50] my dream has come true :) [17:50] :) [17:51] given that I hack on interfaces all day, I wonder if I'll be on the less honorable end of the CVE (or rather, when :/) [17:51] heh [17:52] zyga, just wait until there's a big security flaw named after you [17:53] beuno: I sense it will be named after "Polon" [18:19] zyga: thanks, fixed it [18:19] mhall119: thank you :) [18:22] ogra_ ok, SRU followup questions :-) [18:22] ogra_ if I push this to yakety https://github.com/ubuntu-core/snapcraft/pull/491 (changing the series), can I push the same thing to xenial? or should the series there be xenial-updates? [18:23] ogra_ if it is just xenial, it will be auto forwarded to xenial-proposed, right? [18:25] Hey jdstrand, tyhicks: as of https://github.com/ubuntu-core/snappy/pull/1095 Snappy supports unversioned data. Okay with you if I add the creation of the one in $HOME/snap to ubuntu-core-launcher? [18:34] Is there anyway to change the gcc compiler version used when trying to install packages from pip inside of a python2 snap? [18:34] It seems I can't compile the version of numpy I need with gcc 6, from some testing it looks like gcc 4.7 is working [18:35] kyrofa: that seems reasonable [18:36] jdstrand, alright thanks :) [18:38] jdstrand ah, maybe I can ask you SRUing questions :-) can I? [18:40] I'm not on the ubuntu-sru team, but you can ask :) [18:49] jdstrand so I want to get this out https://github.com/ubuntu-core/snapcraft/pull/491 do I just dput that to yakety, wait for it to get in and the dput to straight out xenial (it should get forwarded to xenial-proposed iirc) [18:49] and then tag all those bugs as per the SRU doc (and probably update the description to cover how it is safe and all that) [18:51] geneios: I'd assume you could add gcc-6 or whatever to build-packages. I don't know if the python2 plugin supports the options to indicate a different compiler, but I'll bet you could write a custom plugin to do it fairly easily. [18:51] sergiusens: dput to yakkety, yes. you will want to use a diferent version for xenial following: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [18:52] sergiusens: I believe you will need to use xenial-proposed (that will definitely do the right thing), but I'm not 100% if it is required. otherwise, follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure [18:54] josepht: Thanks! I have started digging around in the python2 plugin. I had to make some changes already because it was having issues finding the python-dev headers too. [18:56] jdstrand so when uploading to xenial I can change the version to 2.8.5ubuntu16.04 ? [19:00] sergiusens: yes [19:00] sergiusens: you might even consider 2.8.5ubuntu16.04.1 [19:02] jdstrand: can I have a moment of your time? [19:02] jdstrand ok, the next release in Y will be 2.9 and we will ty and get that SRUed as well (as we will have to basically SRU everything we do anyways). [19:02] https://github.com/ubuntu-core/snappy/pull/1095/files#diff-a34e166c5b3016c122430c5884f41e9b [19:02] jdstrand: can you please look at apparmor changes there? [19:03] seems harmless I just want to ensure you see it [19:03] zyga: I did already. they look fine. I'll comment [19:03] zyga: thanks! :) [19:03] thanks! [19:07] jdstrand hmm, looking at how the desktop team did gnome software really confuses me https://launchpad.net/ubuntu/+source/gnome-software [19:10] slangasek can I bug you about SRUing? [19:10] * sergiusens is pinging everybody [19:10] sergiusens: hi [19:12] sergiusens: indeed, that is non-standard to say the least :) [19:14] they should've used 3.20.1+git20160426.1.a976144-0ubuntu0.16.04.1 for xenial and 3.20.1+git20160426.1.a976144-1 for yakkety [19:15] jdstrand series also says 'xenial' in the yakety changelog [19:15] jdstrand to be fair, it is sort of what I want to do; but I get it if it is not valid :-) [19:15] * sergiusens likes clear versions [19:16] sergiusens: they probably did a pocket forward copy [19:16] which people sometimes do at the beginning of the release. but people should do separate uploads due to our shiny gcc [19:17] jdstrand yeah, but this is python, so if there is a new python that breaks the old one, there goes my ideal one code base to rule them all [19:17] sergiusens: what I described is the normal procedure. for a short period of time at the beginning of the release you can get away with the shortcut. but you can't go wrong if you follow the route I mentioned [19:18] jdstrand yeah; I follow :-) I just want my development focus to be xenial (as it really is) and just upload to yakety because the norm says so ;-) [19:19] sergiusens: it's simply a changelog difference and a dput [19:19] jdstrand snapd will see it much worse as they will have to deal with go 1.7 [19:19] I did literally the same thing for ubuntu-core-launcher today [19:19] jdstrand ack then :-) [19:20] slangasek so the only question for you about SRUing is, do I put `xenial` in debian/changelog and expect to be automatically forwarded to -proposed? [19:20] sergiusens: yes [19:20] slangasek ty! [19:20] jdstrand and ty! [19:20] how do you restart the network in snappy or use ifconfig? [19:23] Ah.. you use sudo ifconfig :facepalm: [20:08] jdstrand: so i'm really close...but just need to confirm one thing [20:09] in my mir.go file, when adding apparmor/seccomp for the mir-server (not the client) i was add those for permanentslot right? [20:09] (not plug) [20:09] yes [20:10] dang...i was hoping that was wrong jdstrand [20:10] jdstrand: cause now i get the endless hang on install [20:10] debug from snapd [20:10] https://pastebin.canonical.com/155582/ [20:10] we need zyga [20:10] :-/ [20:10] actually [20:11] ERROR cannot setup dbus for snap "mir-server": cannot obtain DBus security snippets for snap "mir-server": unknown security system [20:11] you need to I think give something empty [20:11] * kgunn raise one eyebrow [20:11] kgunn: there are 4 secure subsystems-- apparmor, seccomp, dbus and udev [20:12] jdstrand: ok, i wondered about that [20:12] you are only need two [20:12] so you have to do something with the other two it seems [20:12]