[00:56] <mup> PR snapcraft#1006 closed: schema: replace `snap` filter with `prime` filter <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1006>
[00:59] <mup> PR snapcraft#1014 closed: tests: reorganize plugin tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1014>
[02:00] <liuxg> elopio, have you checked the reported "classic confinement requires the core_dynamic_linker to be set"? I just installed a container, and I found the same issue
[02:04] <mup> Bug #1653851 opened: no way to avoid CDN for assertions.ubuntu.com within launchpad builds <Snappy:New> <https://launchpad.net/bugs/1653851>
[02:10] <mup> Bug #1653852 opened: Cannot activate Chinese input method for Qt app even in the devmode <Snappy:New> <https://launchpad.net/bugs/1653852>
[04:20] <liuxg> elopio, I have tried to build it in yaketty container, and I have the same issue. What is your finding? thanks
[07:55] <mup> PR snapd#2492 closed: cmd/snap: remove currency switch following UX review <Created by pete-woods> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2492>
[09:27] <mup> PR snapd#2549 closed: cmd/snap-confine: add shutdown helper <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2549>
[09:27] <davidcalle> Morning and happy new year! Is it expected that on 2.20.1+17.04ubuntu2 , network-bind doesn't auto-connect?
[09:28] <davidcalle> mvo ^
[09:29] <davidcalle> (or zyga ? ^)
[09:55] <liuxg> davidcalle, network-bind needs to have mannual connect? according to the spec, http://snapcraft.io/docs/reference/interfaces, it should be.
[09:56] <davidcalle> liuxg: I know, that's why I'm asking why it's not auto-connecting anymore
[10:06] <topi`> I'm trying to build os/kernel/gadget snaps for an unsupported device (Hummingboard), any idea how to "cache" the always-recurring download of ubuntu-core when running "snapcraft"?
[10:07] <topi`> no matter how little I change, it always re-downloads it
[10:27] <davidcalle> sergiusens: ^
[10:37] <jamespage> jdstrand, ok so I've had some good success with the new network-namespace support in network-control with the nova-hypervisor snap
[10:38] <jamespage> jdstrand, the nova-hypervisor snap almost works in strict mode now
[10:39] <jamespage> jdstrand, looking at the remaining syslog DENIED messages, the remaining issues look related to processes wanting to drop privs for things like dnsmasq
[10:41]  * jamespage is frustratingly close to having this working...
[10:58] <mup> PR snapd#2551 opened: refactore store.Snap to take a spec struct <Created by chipaca> <https://github.com/snapcore/snapd/pull/2551>
[11:24] <kalikiana_> topi`: Does the core snap show as being installed? Does "snap changes" say anything dubious?
[11:26]  * kalikiana_ has no idea about that device, but checking those should be a good start
[11:32] <mup> PR snapcraft#1015 closed: tests: reorganize command tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1015>
[12:04] <mcphail> kyrofa: are you still maintaining the nextcloud snap? If I install it, in preference to a manual nextcloud install, what restrictions would I be likely to face? Can I, for example, use Let's Encrypt etc?
[12:11] <mup> Issue snapd#2552 opened: snapd is not tested with against Arch Linux <Created by zyga> <https://github.com/snapcore/snapd/issue/2552>
[12:21] <kalikiana_> Hrm. Getting "...changes in progress..." error and nothing in 'snap changes'. I hate it when that happens.
[12:38] <mup> Bug #1653955 opened: Access to<EMAIL_ADDRESS>should be allowed for semaphores to work <Snappy:New> <https://launchpad.net/bugs/1653955>
[12:41] <mup> Issue snapd#2553 opened: snapd is not tested against Debian <Created by zyga> <https://github.com/snapcore/snapd/issue/2553>
[12:56] <popey> mcphail: http://flexion.org/posts/2016-12-raspberry-pi-3-powered-nextcloud-box-on-ubuntu-core - i used that guide to add letsencrypt
[13:24] <mcphail> popey: thanks. That looks clever. Didn't realise there were helper scripts in the snap. Do you know if you can dd extra apps like the calendar app etc? Not sure how the snap would handle that...
[13:24] <mcphail> *add
[13:28] <popey> mcphail: i think so, yes. I added an app as part of that guide
[13:28] <didrocks> pedronis: hey! I was wondering if when providing required-snaps, I could make one installed in devmode?
[13:30] <pedronis> didrocks: you can say --devmode for everything but it's probably going to change again
[13:30] <pedronis> didrocks: anyway is something you pass/would pass to ubuntu-image, not something that goes into the model assertion
[13:31] <pedronis> didrocks: we have a open task about clarifying/fixing this
[13:31] <pedronis> didrocks: mvo started to look into that
[13:32] <didrocks> pedronis: hum, so, in the model assertion, I should put the snap name
[13:32] <didrocks> pedronis: and in ubuntu-image, there is a devmode option?
[13:32] <pedronis> didrocks: yes, just the snap name
[13:32] <pedronis> didrocks: there should be but might not work atm
[13:32] <mcphail> popey: excellent. Ta
[13:32] <pedronis> as I said bit of wip atm
[13:33] <didrocks> pedronis: ok, I think this isn't going to work for our workshop deadline thus
[13:33] <didrocks> pedronis: I'll keep on "this does not work thus"
[13:33] <didrocks> :)
[13:45] <mup> PR snapcraft#1019 closed: tests: reorganize state tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1019>
[13:48] <mup> PR snapcraft#973 closed: ci: check the license agreement on Travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/973>
[13:52] <mup> PR snapd#2551 closed: refactor store.Snap to take a spec struct <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2551>
[13:59] <mup> PR snapd#2554 opened: tests: add end-to-end store test for classic confinement <Created by mvo5> <https://github.com/snapcore/snapd/pull/2554>
[14:13] <liuxg> sergiusens, ping
[14:15] <sergiusens> liuxg hey
[14:15] <jacekn> hello. What's the best way to create new directory in my snap package using snapcraft.yaml? I need to ship it with empty directory but can't find a way to do it, thought dump plugin woudl do it but does not look like it
[14:16] <liuxg> sergiusens, regarding the bug https://bugs.launchpad.net/snapcraft/+bug/1650946, I tried to compile my sample project using LXD, and I had the same issue. What could be reason for it? thanks
[14:16] <mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Incomplete> <https://launchpad.net/bugs/1650946>
[14:16] <liuxg> sergiusens, I checked it with my colleague and it worked under 17.04.
[14:17] <sergiusens> liuxg oh, does snap list show `core` in there? if not, `snap install core`
[14:17] <sergiusens> and tell me if that works
[14:18] <liuxg> sergiusens, http://paste.ubuntu.com/23739129/, this is the list
[14:18] <liuxg> sergiusens, I think ubuntu-core is there already
[14:18] <sergiusens> liuxg I didn't need the list ;-) And no it is not, `ubuntu-core` != core
[14:19] <sergiusens> so `snap install core`
[14:22] <liuxg> sergiusens, oh, I see your point. However, I got an error http://paste.ubuntu.com/23739153/. Should I remove ubuntu-core first?
[14:23] <liuxg> sergiusens, I am wondering what is the difference between "core" and "ubuntu-core". Are they the same thing? Sorry, this is the first time I tried to install core.
[14:23] <sergiusens> liuxg I don't know about that, I have both at the same time. But you need that for classic snaps to be buildable
[14:23] <sergiusens> core replaces ubuntu-core
[14:24] <sergiusens> liuxg you will need to ask someone in the snapd (core team) about this
[14:24] <liuxg> sergiusens, so, I should remove the "ubuntu-core" first in order to install "core".
[14:25] <liuxg> sergiusens, by the way, who is from the snapd team?
[14:26] <sergiusens> mvo zyga ^
[14:26] <sergiusens> liuxg you can get by this by `snap install core` in a clean lxd container and build there
[14:27] <liuxg> sergiusens, OK. I will try it. thanks
[14:27] <mvo> liuxg: ubuntu-core and core are currently mostly identical except the name, we will transition ubuntu-core to core at some point but thats not done yet
[14:28] <sergiusens> mvo right, classic confined snaps require having core installed to build and eventually run
[14:28] <liuxg> mvo, the thing is that classic needs to have "core" instead of "ubuntu-core", right? I cannot remove the "ubuntu-core" for now in my 16.04 system. Can I get them both co-exist in order to test classic?
[14:28] <sergiusens> seems an addition to not allowing both installed was added recently
[14:30] <liuxg> sergiusens, mvo, the problem is that how can I test it on 16.04 OS. By default, "ubuntu-core" is installed on my machine. when i tried to remove "ubuntu-core", it complains "error: cannot remove "ubuntu-core": snap "ubuntu-core" is not removable"
[14:34] <mvo> liuxg: thats a bug then in classic mode, it should work with either ubuntu-core and core, let me have a look
[14:35] <mvo> liuxg: plus it should be possible to exachange the two, thats another bug :/
[14:35] <sergiusens> mvo it actually isn't possible, we designed it that way with zyga
[14:35] <liuxg> mvo, thanks! I never got it working. could you please see the bug report at https://bugs.launchpad.net/snapcraft/+bug/1650946?
[14:35] <mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Incomplete> <https://launchpad.net/bugs/1650946>
[14:36] <sergiusens> mvo the linker used is hard coded in the elf headers
[14:36] <mvo> sergiusens: oh, ok. so then we need to make it possible to remove ubuntu-core
[14:36] <mvo> sergiusens: I have a look
[14:38] <pedronis> mvo: that is a bit problematic in other ways, I think we wanted to allow that but only if there are no other snaps installed (on classic)
[14:38] <pedronis> I mean to remove core/ubuntu-core
[14:42] <mup> Bug #1653988 opened: no soundcore in linux-raspi2  <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1653988>
[14:44] <mvo> pedronis: aha, I see, to avoid that people break their system? I guess "snap install core and remove ubuntu-core" would be nice :)
[14:48] <pedronis> mvo: yes, to avoid people breaking stuff without thinking
[15:29] <pmcgowan> mvo, is there a workaround to the issue discussed above? can I just rm the /snap/ubuntu-core folder?
[15:31] <mvo> pmcgowan: cleanest workaround is to purge snapd (the deb) and then snap install core as the first operation
[15:32] <pmcgowan> OK
[15:41] <popey> mvo: that requires removal of all snaps?
[15:46] <mvo> popey: unfortunately, we work on something better but its not there yet
[15:47] <popey> ok
[15:52] <jdstrand> niemeyer: hi! I'm not up on everything for 'aliases'. I need to add support to the review tools and was wondering if declaring aliases should prompt for manual review. My understading is 'no' since the aliases are applied by the user unless there is an auto-alias in the store
[16:05] <niemeyer> jdstrand: Heya
[16:05] <niemeyer> jdstrand: Happy new year (to all!)
[16:06] <niemeyer> jdstrand: Yeah, it shouldn't prompt for manual review.. the idea is that people can experiment with aliases without the burden of involving reviews
[16:06] <niemeyer> jdstrand: We then need a way for people to ask for aliases
[16:06] <niemeyer> ask for auto-aliases, that is
[16:06] <niemeyer> Which is just an explicit whitelist of a particular alias that may (and may not!) be in the snap
[16:09] <jdstrand> niemeyer: ok, thanks. fyi, cprov showed me today that the store already has support to grant auto-aliases. I don't know the status/plans for how to request them
[16:09] <jdstrand> I mean, putting them in the yaml is a form of request, but I don't think that is what you were talking about
[16:21] <niemeyer> jdstrand: Yeah, that's no tit
[16:22] <niemeyer> jdstrand: As long as you can edit them, we can take bugs as requests for the time being
[16:23] <jdstrand> niemeyer: sounds good
[16:23] <ogra_> sudo apt install fakeroot
[16:23] <ogra_> bah !
[16:26] <longsleep> ogra_: hey any idea how and whom to contact so https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1652262 can be resolved rather sooner than later? For me right now its pretty unclear how extra dependencies for stuff added to ubuntu-core are handled. I remember there was some ppa which got pulled in during rootfs build in the past.
[16:26] <mup> Bug #1652262: subiquitycore exception in controller.run <snappy> <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1652262>
[16:27] <ogra_> heh, i just saw someone comment on it
[16:27] <longsleep> ogra_: yeah me too, thats why i rememberd to ask you :)
[16:27] <ogra_> longsleep, usually subiquity is mwhudson's baby
[16:27] <ogra_> might be that he is still on EOY vacation though
[16:27] <longsleep> ogra_: yes but the fix is in a dependency of subiquity - i wonder how these get pulled in
[16:28] <ogra_> oh ?
[16:28]  * ogra_ checks the bug
[16:28] <longsleep> ogra_: fix is in https://github.com/CanonicalLtd/probert/commit/09c449104c15f7c4518eff77055d70af08bcc42a
[16:28] <longsleep> ogra_: so in the probert python module
[16:29] <ogra_> longsleep, ah, well, that might be a cyphermox package (though mwhudson tends to touch it too)
[16:29] <ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[16:30] <ogra_> last probert upload for xenial is from nov. 10th though
[16:30] <longsleep> ogra_: ah yeah that was the repo - good to know that this is still used
[16:30] <longsleep> ogra_: yeah so what needs to happen to get probert updated eventually is the question
[16:30] <ogra_> yeah, sadly it is ... i'll work my way throuhg SRUs the next weeks
[16:31] <ogra_> technically all these packages need SRUing
[16:31] <ogra_> longsleep, you either catch mwhudson or cyphermox to upload a new version to that PPA
[16:32] <longsleep> ogra_: ok - great  thanks!
[16:33] <ogra_> longsleep, if you dont get any answers before EOW, ping me again and we can see what to do (i would just upload a fixed package but i dont want to break any processes the guys have in place)
[16:34] <longsleep> ogra_: yeah no hurry - i can wait until they have time
[16:38] <mup> PR snapd#2555 opened: many: implement 'snap aliases' <Created by pedronis> <https://github.com/snapcore/snapd/pull/2555>
[17:04] <mup> PR snapd#2556 opened: interface/builtin: drop the obsolete checks in udisks2 SanitizeSlot <Created by pedronis> <https://github.com/snapcore/snapd/pull/2556>
[17:06] <mup> PR snapcraft#989 closed: pluginhandler: add support for disabling system library migration <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/989>
[17:23] <elopio> ev_: I heard you can help me with my rocket chat account. I can't log in.
[17:23] <ev_> elopio: hey! sorry for not getting back to you on Telegram
[17:23] <ev_> I’m not actually an admin on RocketChat
[17:23] <elopio> ev_: Also, I'll have a meeting with shadow tomorrow at 14:30 UTC. What to join us?
[17:24] <ev_> no idea who keeps pointing people in my direction
[17:24] <elopio> ev_: ^_^
[17:24] <ev_> shadow> yes please!
[17:24] <elopio> sabdfl: do you know who is admin in rocket chat?
[17:34]  * ogra_ gives up for the day ... this extrausers group stuff makes my brain hurt ...
[17:35] <ogra_> (but we'll eventually have lxd working on core images at least ... )
[17:51] <kyrofa> elopio, in our snaps tests, are we using the ubuntu-core snap or the core snap?
[17:51] <kyrofa> (i.e. is it a clean install)?
[17:53] <mup> Issue snapd#2557 opened: Serial Port Plug/Interface issue with Ubuntu-core 16.04 <Created by mrsinghgit> <https://github.com/snapcore/snapd/issue/2557>
[17:55] <ogra_> hopefully the latter
[18:01] <elopio> kyrofa: it is a clean install. But sergiusens forced one test to install core if it wasn't installed before.
[18:01] <kyrofa> elopio, ah! Excellent
[18:06] <Cust0sLimen> hi
[18:06] <Cust0sLimen> how poorly will snappy work with firewalld ?
[18:08] <kyrofa> Cust0sLimen, I expect it just needs to be properly packaged with the right interfaces
[18:08] <Cust0sLimen> kyrofa, well ... let me put it like this rather ... if I use firewalld on ubuntu ... will snappy stop working ?
[18:09] <kyrofa> Cust0sLimen, ah, indeed I misunderstood the question
[18:09] <kyrofa> Cust0sLimen, I don't see why that would interfere with snappy. What makes you suspect that it will?
[18:10] <Cust0sLimen> so there is this: http://snapcraft.io/docs/reference/interfaces - "firewall-control - Can configure network firewalling giving privileged access to networking."
[18:11] <kyrofa> Yeah, if you have a snap installed that utilizes that interface you might run into issues
[18:11] <Cust0sLimen> kyrofa, :/
[18:11] <kyrofa> Cust0sLimen, run `snap interfaces` to check that
[18:11] <kyrofa> Cust0sLimen, it would be like having both ufw and firewalld installed
[18:11] <Cust0sLimen> why could ubuntu not just be fedora without stupid rules that result in not having ffmpeg ;(
[18:12] <Cust0sLimen> kyrofa, I have no snaps at the moment
[18:12] <Cust0sLimen> just pessimistic
[18:12] <kyrofa> Cust0sLimen, then you should have no issues
[18:12] <Cust0sLimen> kyrofa, I might have some installed later though
[18:12] <kyrofa> Cust0sLimen, just don't install a firewall snap then, and you should be fine
[18:30] <jdstrand> Cust0sLimen: the firewall-control interface you referenced in the documentation is something that a snap may request, not what snappy necessarily controls. in other words, if your system uses firewalld, you'll have no problems with snappy. if you install the ufw or some other firewall snap and use it, they might conflict with each
[18:30] <jdstrand> other
[18:30] <jdstrand> Cust0sLimen: this is no different than trying to install two different firewall applications via rpm and eb and using them at the same time
[18:30] <jdstrand> s/and eb/or deb/
[18:31] <jdstrand> Cust0sLimen: so, basically, what kyrofa said: if you don't install a firewall snap, you should have no issues
[18:32] <jdstrand> roadmr: hi! can you pull r814? it adds 'aliases' support to the review tools among other things
[19:03] <roadmr> jdstrand: sure thing
[19:03] <roadmr> jdstrand: (happy new year :)
[19:04] <jdstrand> roadmr: thanks! and happy new year to you too :)
[19:45] <wswartz> Hello.  I was wondering if anyone knew what the various flavors (Gnome, KDE, etc) were planning to also be Snap-based?
[19:58] <mup> PR snapd#2556 closed: interface/builtin: drop the obsolete checks in udisks2 SanitizeSlot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2556>
[20:11] <mwhudson> longsleep: hi
[20:11] <longsleep> mwhudson: hey
[20:12] <mwhudson> longsleep: you want a probert upload?
[20:13] <longsleep> mwhudson: yeah would be awesome to have probert with the wifi stuff try/except change in edge asap
[20:13] <mwhudson> alright
[20:13] <longsleep> mwhudson: i still do not know why it fails with my kernel though as my test code works just fine in classic ubuntu
[20:14] <longsleep> mwhudson: but the try/except fix would unblock me to hopefully get a working edge image for further testing
[20:14] <mwhudson> longsleep: with the same kernel?
[20:14] <mwhudson> that is pretty odd
[20:14] <mwhudson> longsleep: does your board actually have wifi?
[20:14] <longsleep> mwhudson: yes, different builds though
[20:14] <longsleep> mwhudson: yes board has wifi / iw works just fine as well
[20:15] <mwhudson> longsleep: how odd
[20:15] <mwhudson> anyway, i'll get the fix uploaded
[20:15] <longsleep> mwhudson: did you see my test program - maybe you can spot a difference - or probert runs in some confinment when started on snappy boot
[20:17] <longsleep> mwhudson: awesome - most appreciated thanks
[20:18] <longsleep> mwhudson: btw if i might suggest an improvement to https://github.com/CanonicalLtd/probert/commit/09c449104c15f7c4518eff77055d70af08bcc42a#commitcomment-20335990 - it should say that it cannot start the nl80211 listener instead of just the listener imho
[20:19] <mwhudson> it says wlan_listener?>
[20:20] <longsleep> ah right, wouldnt be nl80211 wlan_listener better? After all there is also the rtnetlink wlan listener?
[20:20] <mwhudson> there's nothing wlan about the rt listener
[20:20] <longsleep> oh
[20:20] <mwhudson> i agree it's a bit obscure
[20:20] <longsleep> right - then i guess its just my misunderstanding
[20:24] <mup> PR snapcraft#1025 opened: project loader: better error message for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1025>
[20:28] <mwhudson> longsleep: uploaded, should be in the next edge build
[20:28] <longsleep> mwhudson: very nice thank you!
[20:28] <longsleep> mwhudson: i just rebuilt probert from source on classic ubuntu on that kernel to see if i can reproduce the original issue there
[20:29] <mwhudson> longsleep: that would be interesting
[20:30] <mwhudson> longsleep: you can just run python3 probert/network.py
[20:30] <mwhudson> (after python3 setup.py build_ext -i)
[20:30] <longsleep> mwhudson: yeah on it, need some extra python modules installed first
[20:33] <longsleep> mwhudson: what do you make of this http://paste.ubuntu.com/23741215/ ?
[20:33] <mwhudson> longsleep: well that's interesting
[20:34] <longsleep> mwhudson: thats not the same error as when run through subiquity though
[20:34] <mwhudson> yeah
[20:34] <mwhudson> pretty odd though, is the device actually up already?
[20:35] <longsleep> mwhudson: ifconfig shows wlan0 and wlan1 it as up yes
[20:36] <mwhudson> longsleep: can you hack network.py:435 to print link.flags?
[20:36] <longsleep> mwhudson: sure hold on
[20:36] <mwhudson> it shouldn't be trying to up the device if it's already UP
[20:37] <mwhudson> um i guess printing ifindex would be useful too
[20:37] <longsleep> mwhudson: mhm magic print makes it work - no error this time
[20:38] <longsleep> let me down it again
[20:38] <mwhudson> hah uh maybe some kind of race maybe
[20:38] <mwhudson> longsleep: wait, you have two wifi devices? i haven't tried it in that situation, maybe there is some confusion
[20:38] <longsleep> ah yeah if its down before
[20:38] <mwhudson> shouldn't be but who knows
[20:38] <longsleep> yeah two
[20:38] <longsleep> that driver creates two interfaces for a single card
[20:38] <mwhudson> oh right
[20:39] <longsleep> mwhudson: xxx (5, 1)
[20:39] <mwhudson> so i bet when you up one, the other gets implicitly upped too
[20:39] <longsleep> 5 is the index and 1 is the flags
[20:39] <longsleep> mwhudson: ah yeah thats true
[20:39] <longsleep> mwhudson: i usually disable the second device in interfaces
[20:39] <mwhudson> and probert tries to up both and something complains
[20:39]  * mwhudson waves hands
[20:40] <mwhudson> longsleep: wait what, the flags are 1 for the call that crashes?
[20:41] <longsleep> mwhudson:  yes - full output at http://paste.ubuntu.com/23741260/
[20:41] <longsleep> mwhudson: if i run it again without downing the interfaces first, no error
[20:42]  * mwhudson tries to remember how to find out what -16 means
[20:43] <mwhudson> longsleep: can you pastebin git diff, to be sure?
[20:43] <mwhudson> oh
[20:43] <mwhudson> #define NLE_SEQ_MISMATCH	16
[20:43] <longsleep> +                print("xxx", (ifindex, IFF_UP))
[20:43] <mwhudson> longsleep: oh
[20:43] <mwhudson> longsleep: link.flags, not IFF_UP :)
[20:43] <longsleep> err sorry
[20:45] <longsleep> mwhudson: link.flags is 4098 for both errors
[20:45] <mwhudson> longsleep: thanks
[20:45] <longsleep> mwhudson: http://paste.ubuntu.com/23741285/
[20:46] <mwhudson> longsleep: but anyway, the wlan_listener is starting ok?
[20:47] <mwhudson> eh it must be
[20:47] <longsleep> mwhudson: well no other error and it shows a bunch of networkinfo objects
[20:47] <mwhudson> longsleep: and the interfaces are up after you run probert?
[20:47] <longsleep> mwhudson: yes
[20:47] <mwhudson> then i don't know what is going on but it seems harmless
[20:48] <longsleep> mwhudson: xxx wlan_listener started (<_nl80211.listener object at 0x7fa91f3b88>,)
[20:48] <mwhudson> longsleep: cool
[20:49] <mwhudson> if still mysterious why it doesn't work with snappy
[20:49] <longsleep> mwhudson: ok, but it confirms that wlan listener starts fine on classic ubuntu, same kernel except that one is manual build and the other is built by snapcraft
[20:51] <longsleep> mwhudson: fyi - kernel snap is built with this https://github.com/longsleep/build-pine64-image/blob/master/snappy/kernel/snapcraft.yaml
[20:51] <longsleep> mwhudson: and the classic kernel is also built only with sun50iw1p1smp_linux_defconfig config
[20:55] <mwhudson> longsleep: can you do this: http://paste.ubuntu.com/23741362/ re-down the interfaces and run network.py again?
[20:55] <mwhudson> uh after running build_ext -i
[20:55] <mwhudson> pastebin the output, there will be a lot of it
[20:55] <longsleep> mwhudson: sure hold on
[20:56] <longsleep> oh wow thats a lot of output
[20:58]  * longsleep installs pastebinit
[20:59] <longsleep> mwhudson: http://paste.ubuntu.com/23741380/
[21:09] <mup> PR snapcraft#1010 closed: meta: add 'desktop' entry for apps <Created by oSoMoN> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1010>
[21:31] <cliftonts> Evening everybody
[21:34] <cliftonts> I'm having an issue packaging up a python script, is there anybody here who might be able to point out where I'm going wrong?
[21:34] <kyrofa> cliftonts, sure! What's up?
[21:35] <cliftonts> Initially it was building but the installed snap was saying it couldn't find python
[21:35] <kyrofa> cliftonts, which plugin were you using?
[21:35] <cliftonts> Mark Shuttleworth suggested I change the python location stated in the script, now it just loads the python interpreter.
[21:36] <cliftonts> my snapcraft.yaml is here: http://paste.ubuntu.com/23741430/
[21:36] <kyrofa> cliftonts, the python plugin pulls in python2-- is that the one you want?
[21:37] <cliftonts> My script will work with either 2 or 3
[21:37] <kyrofa> cliftonts, ah, but you have no setup.py or anything
[21:37] <cliftonts> for what purpose?
[21:38] <kyrofa> cliftonts, to tell snapcraft (or users, for that matter) about your project's dependencies and where it should be installed
[21:38] <kyrofa> cliftonts, I'm referring to the RokuTerm project itself
[21:38] <kyrofa> We still might be able to get this to work, hold on a sec
[21:39] <cliftonts> I am not the most experienced at this. I've never been able to package an app. Tried with deb for 2 years and gave up!
[21:39] <cliftonts> So please forgive me if I'm doing things in an odd way.
[21:39] <kyrofa> cliftonts, that's alright, you're just about there :)
[21:40] <cliftonts> It's one of those things that's impossible until you've done it once I think.
[21:42] <kyrofa> cliftonts, I'm playing with it for a minute, hold on
[21:42] <cliftonts> kyrofa - rokuterm is a sort of prototype program, mostly not finished, mostly patched together and just there to iron out some kinks in the design which will be transferred to a new project later. It seemed appropriate to experiment with packaging on an experiment.
[21:43] <cliftonts> I would be keen to learn how one of these setup.pys would work though.
[21:45] <kyrofa> cliftonts, it's a python packaging thing. This might prove a good starting point: https://stackoverflow.com/questions/1471994/what-is-setup-py
[21:45] <cliftonts> Ok, thanks
[21:45] <kyrofa> cliftonts, but you probably don't need it for this
[21:45] <cliftonts> I was about to say, the snap handles all of that anyway, right?
[21:46] <kyrofa> I'll explain in a second
[21:46] <kyrofa> cliftonts, well, you still have to tell snapcraft what to put in the snap
[21:46] <kyrofa> cliftonts, the `dump` plugin just puts EVERYTHING in its `source` into the snap (unless files are filtered out)
[21:46] <cliftonts> Yes, but once I've got it actually loading the script I can then worry about dependancies and permissions.
[21:47] <kyrofa> cliftonts, the make plugin doesn't-- it runs `make` and `make install`
[21:47] <kyrofa> cliftonts, i.e. if you didn't have a Makefile, the `make` plugin wouldn't know what to install. Does that make sense?
[21:47] <kyrofa> The python plugins are the same way
[21:48] <kyrofa> cliftonts, but we can get around that by telling it exactly what to do
[21:48] <cliftonts> kyrofa - I see, I have simply been following the demo for the python3 snap, trying to change as little as possible. But to be honest that didn't seem to work for me either.
[21:48] <kyrofa> cliftonts, the python3 demo pulls in https://github.com/markokr/spongeshaker, which has a setup.py
[21:49] <cliftonts> kyrofa - I will browse further. The problem with coming in with zero knowledge is you can so easily overlook the obvious.
[21:50] <kyrofa> cliftonts, alright, quick question:
[21:51] <kyrofa> cliftonts, rokuterm.py is supplied by two things, it seems: the github project and alongside the snapcraft.yaml
[21:51] <kyrofa> cliftonts, can you explain that? Do you actually want both of them?
[21:52] <cliftonts> kyrofa - No, as I previously stated that is pretty much a carbon copy of the spongeshaker yaml. Make it go, then figure out why it goes. I had no idea what was removable, yet.
[21:52] <kyrofa> cliftonts, ah, I see. So that github project should work standalone?
[21:52] <cliftonts> Download it to your desktop and run the py, it'll just work.
[21:53] <kyrofa> No dependencies other than python2 or 3?
[21:53] <kyrofa> (Note that the py is not executable)
[21:54] <cliftonts> kyrofa - Only a number of python modules. I debated with myself whether it would be frowned upon to have it set as executable as standard.
[21:55] <kyrofa> cliftonts, default python modules, or pypi?
[21:56] <cliftonts> requests, urllib, sys, time, os, urllib2
[21:56] <kyrofa> Alright, sounds standard. Does this work better? http://pastebin.ubuntu.com/23741636/
[21:57] <kyrofa> I made a few changes. First of all, got rid of the extra dump usage
[21:57] <kyrofa> Second, I noticed the script uses `env python` so I used python2 instead of python3
[21:57] <kyrofa> Third, I had to tell snapcraft how to install the script, due to the lack of a setup.py that tells that to snapcraft for you
[21:58] <kyrofa> It's just a simple "make a bin folder, copy it into the bin folder, make it executable"
[21:59] <kyrofa> cliftonts, does that make sense?
[21:59] <cliftonts> Sounds good
[22:01] <cliftonts> kyrofa - Trying now
[22:02] <kyrofa> cliftonts, looks like you use requests
[22:02] <kyrofa> Oh, you said so. Not standard, missed that
[22:02] <cliftonts> kyrofa - I will work on creating the setup.py next then. Easier now I have a starting point
[22:02] <cliftonts> Requests if python 3
[22:03] <cliftonts> Oh no sorry, I use th requests module yes.
[22:04] <kyrofa> cliftonts, alright, this works: http://pastebin.ubuntu.com/23741673/
[22:04] <cliftonts> kyrofa - Excellent! I now get an error stating no module named requests so that's one problem fixed, one created. Progress!!
[22:05] <kyrofa> cliftonts, it doesn't work though-- it's trying the wrong subnet for me. But that should get you closer :)
[22:05] <kyrofa> At least it builds correctly now
[22:05] <cliftonts> kyrofa - As I said it is experimental, one of the next stages is to get network scanning working correctly. But you can specify the IP manually anyway.#
[22:06] <kyrofa> How? I have a roku
[22:06] <cliftonts> kyrofa - rokuterm 192.168.blah, blah
[22:07] <gb__> kyrofa ive been searching for a solution to my snap/nextcloud question.  I have I installed the ownbackup plugin but it doesnt seem to run.  What would you recommend as a backup solution?  I found on reddit that your the goto guy and worked on the snap package.
[22:08] <cliftonts> kyrofa - Brilliant. It works but of course it is contained so can't access the network. I haven't read up on that yet.
[22:09] <kyrofa> cliftonts, excellent, a little homework then!
[22:10] <kyrofa> gb__, we've been talking about that actually
[22:10] <cliftonts> kyrofa - Feel free to download and play with it. The aim is to re-create it using a graphivcal interface once all the features work.
[22:10] <kyrofa> gb__, can you explain what you're trying to backup and why?
[22:10] <kyrofa> cliftonts, already done ;)
[22:11] <kyrofa> cliftonts, nice job by the way
[22:11] <kyrofa> cliftonts, it would probably be helpful if you brought your mailing list thread to a close, by the way
[22:11] <kyrofa> To others, I mean
[22:11] <cliftonts> kyrofa - It's not that impressive, I've simply reverse engineered the code for uroku for ubuntu touch.
[22:12] <gb__> kyrofa all i wanted to do was backup the data so if i loose the boot disk on my server i can restore everything
[22:12] <kyrofa> gb__, so you want _everything_, including the data?
[22:12] <kyrofa> gb__, how often do you want to capture such a backup?
[22:12] <gb__> kyrofa thats what i was thinking of yes
[22:13] <gb__> kyrofa, just once a week its only a home server
[22:14] <cliftonts> kyrofa - Thanks for your help. More progress in 24 hours than the last 2 years!
[22:15] <kyrofa> gb__, that's all I have to, but that's still a few hundred GBs per backup if you include the data. Where do you intend on putting them? (not trying to attack by the way, it's just helpful having a use-case to poke at)
[22:15] <kyrofa> cliftonts, any time!
[22:15] <mup> PR snapcraft#1025 closed: project loader: better error message for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1025>
[22:15] <kyrofa> gb__, and how many do you intend on keeping?
[22:15] <cliftonts> I'm off to try and find something to watch on the bottomless pit that is roku. Night!
[22:16] <gb__> kyrofa i have a zfs array on the server to backup too
[22:18] <mup> PR snapcraft#984 closed: parser: improve output <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/984>
[22:18] <kyrofa> gb__, okay. So currently, you can totally just slurp the entire /var/snap/nextcloud/current directory
[22:18] <kyrofa> As well as the /var/snap/nextcloud/common directory (which holds the raw data)
[22:19] <kyrofa> To restore, just install the snap and copy stuff over the top
[22:19] <kyrofa> gb__, but we're working on making a nicer export/import
[22:20] <kyrofa> gb__, but unlike just Nextcloud, we have other things to think about. SSL keys, etc
[22:21] <kyrofa> gb__, so: do you find yourself caring about the raw data, the database, the nextcloud config, the extra stuff like SSL keys, or everything in one big dump?
[22:23] <kyrofa> gb__, note that the discussion to which I refer is happening here: https://github.com/nextcloud/nextcloud-snap/issues/126
[22:24] <gb__> kyrofa thinking about it if i backup just the data i could always copy it back
[22:26] <kyrofa> gb__, yeah just backup /var/snap/nextcloud/common, then. If you need to restore, just put the files back in there and Nextcloud will pick them up
[22:26] <kyrofa> gb__, but we can make that better
[22:26] <kyrofa> It's on the list :)
[22:27] <gb__> kyrofa thanks for your help Ill do that then.  I have a long list of todo's too.  Thanks for your help :)
[22:28] <kyrofa> gb__, any time!
[22:28] <kyrofa> gb__, thanks for letting me pick your brain. Feel free to join in that conversation on the bug
[22:29] <gb__> kyrofa will do!
[23:04] <mwhudson> longsleep: sorry for the delay, that doesn't really make much sense to me though :(


[12:27] <stokachu> cjwatson: hey when you get a chance would you mind looking over bug 1311274
[12:27] <ubot2> Launchpad bug 1311274 in Ubuntu Untitled "Include sosreport into ubuntu-seeds/cloud-image" [Medium,Confirmed] https://launchpad.net/bugs/1311274
[13:13] <bregma> hey guise I have a bunch of Unity and Compiz bugfixes for 14.04, some of which will obviously require an SRU, but do I require going through the SRU process for every single bug fix or can some fixes be uploaded without?
[13:25] <seb128> bregma, having different bugs/testcases help to build confidence in the update, but I think not having a bug reference for every change is fine, as long as you have one that covers those changes to make sure to regression test the update
[13:25] <seb128> I'm not in the SRU team though
[13:25] <seb128> so to be confirmed by others
[13:26] <bregma> seb128, we've got bug references for every bug, I just want clarification if we need to SRU every bug
[13:26] <seb128> but we often have "upstream bugsfix updates" as SRUs with a bug describing the update and what to test/check for
[13:26] <seb128> if you list them in the changelog they should be SRU compliant yet
[13:26] <seb128> yes
[13:26] <bregma> mostly because it's going to quickly become unscalable
[13:26] <seb128> otherwise it's going to create issues with the process
[13:27] <seb128> why not?
[13:27] <seb128> if those are identified issue with fixes it shouldn't be that difficult to have a testcase for each
[13:27] <seb128> if you don't want to do that just don't list them in the changelog
[15:22] <sil2100> Hello SRU team! There are 3 packages in the UNAPPROVED queue that we think are ready from the SRU-point of view - it's ubuntu-push, webbrowser-app, unity-webapps-googleplus
[15:22] <sil2100> All those packages have SRU-ready bugs
[15:31] <infinity> bregma: If you're asking if you need an upload per bug, absolutely not.
[15:31] <infinity> bregma: One upload with all the bugs fixed, and proper references for each is what we expect to see.
[16:12] <bdmurray> infinity: could you release app-install-data-ubuntu early to fix bug 1161283?
[16:12] <ubot2> Launchpad bug 1161283 in app-install-data-ubuntu (Ubuntu) "Problems reported with .desktop files for sonic-visualiser" [Medium,Fix committed] https://launchpad.net/bugs/1161283
[16:14] <infinity> bdmurray: Yeah, can do in a sec.
[16:14] <infinity> bdmurray: Can you find someone to do verification on bug #1308354?  It didn't get all properly linked to things, cause mvo messed up the changelog...
[16:14] <ubot2> Launchpad bug 1308354 in software-center (Ubuntu Trusty) "Password revealed when pasted with Ctrl-V" [High,In progress] https://launchpad.net/bugs/1308354
[16:14] <infinity> (You'd think whoever accepted that upload would have noticed)
[16:16] <bdmurray> hrm
[16:42] <bdmurray> infinity: okay, I've verified that fix if you want to release it early so we don't forget which bug it fixes.
[16:52] <infinity> bdmurray: Ta.
[17:32] <ogra_> is the archive open yet
[17:32] <ogra_> ?
[17:34] <infinity> ogra_: You're joking, I hope.
[17:34]  * ogra_ taps foot
[17:34] <ogra_> :)
[18:00] <stgraber> yay, I can finally start doing Ubuntu stuff (was pretty much doing upstream work only till now). I'll setup the tracker and system-image after lunch then.
[18:13] <davmor2> hey guys when will Quantal be retired?
[18:13] <davmor2> also for that matter saucy
[18:15] <sergiusens> davmor2: https://wiki.ubuntu.com/Releases
[18:16] <infinity> davmor2: I'll send out warning announcements later tonight.  The wiki is probably wrong, FWIW.
[18:16] <sergiusens> infinity: so not this month?
[18:17] <davmor2> sergiusens: yes I was more after date then month ;)
[18:17] <infinity> sergiusens: Next month.  Got extended a bit to stagger upgrades and not have people panicking due to the weird support cycle changes in the last few releases.  Then it'll be business as usual going forward.
[18:17] <sergiusens> great
[18:17] <davmor2> infinity: thanks dude
[18:32] <Logan_> infinity: I've got someone in #ubuntu who is not getting any new releases with a do-release-upgrade - Prompt=normal, and lsb_release -a spits out 13.10 - what gives?
[18:37] <infinity> Logan_: Not sure, ask bdmurray.
[18:37] <Logan_> bdmurray: ^
[18:40] <bdmurray> Logan_: have them run DEBUG_UPDATE_MANAGER=1 /usr/bin/do-release-upgrade'
[18:40] <bdmurray> well without the '
[18:41] <bdmurray> It might be bug 1310891
[18:41] <ubot2> Launchpad bug 1310891 in ubuntu-release-upgrader (Ubuntu Trusty) "cached meta-release file should not be saved if it is html" [High,Triaged] https://launchpad.net/bugs/1310891
[18:44] <Logan_> bdmurray: <Sinistrad> Logan_: http://paste.ubuntu.com/7316720/
[18:44] <Logan_> (at the bottom)
[18:45] <Logan_> looks exactly like that bug, eh?
[18:45] <bdmurray> no it doesn't say "reading file" does it?
[18:46] <Logan_> no, no it doesn't
[18:46] <Logan_> bdmurray: if you want to debug with him directly, he's Sinistrad in #ubuntu :P
[18:47] <Logan_> or I can have him come in here
[18:47] <bdmurray> that's okay how about #ubuntu-bugs
[18:47] <bdmurray> or have him check the contents of the files that are read in the bug report I mentioned
[18:57] <cjwatson> ^- lack of bug number, I've talked to the lander
[19:05] <infinity> cjwatson: Sure.
[19:05] <cjwatson> disabling publisher
[19:06] <cjwatson> utopic -> FROZEN
[19:06] <infinity> cjwatson: I'll toss up milestones.
[19:06] <cjwatson> ta
[19:06] <cjwatson> branching seeds
[19:07] <cjwatson> infinity: I think you can safely +initseries if you want
[19:07] <cjwatson> (don't remember whether ~launchpad can do that)
[19:08] <infinity> cjwatson: I can do it.  Did you want to poke WeBops to pre-emptively disable the possibly-offensive lock contender first?
[19:08] <cjwatson> so glad I wrote branch-seeds, avoids having to pay attention
[19:08] <cjwatson> infinity: nah, let's see if it works by itself
[19:10] <cjwatson> (it might do, I think some jobs have moved around a bit)
[19:11] <infinity> cjwatson: Does "auto-select" for arch indep work, or should I be paranoid and click i386?
[19:12] <cjwatson> infinity: What's the exact text?
[19:12] <infinity> Architecture independent builder:
[19:12] <infinity>     Auto select
[19:12] <infinity>     amd64
[19:12] <infinity>     arm64
[19:12] <infinity>     armhf
[19:12] <infinity>     i386
[19:12] <infinity>     powerpc
[19:12] <infinity>     ppc64el
[19:12] <cjwatson> Pretty sure I just left it at the defaults last time, but double-checking
[19:13] <infinity> I'm assuming the default should work, I've just never played with this form before. :)
[19:14] <cjwatson> Yeah, pretty certain auto select is fine
[19:14] <cjwatson> Not that being explicit hurts
[19:14] <infinity> Button pressed.
[19:14] <cjwatson> Seeds branched
[19:14] <infinity> Back to milestones...
[19:16] <cjwatson> 2014-04-23 19:15:21 INFO    Running <InitializeDistroSeriesJob for distribution: ubuntu, distroseries: utopic, parent[overlay?/pockets/components]: jessie[False/Release/], architectures: (u'amd64', u'arm64', u'armhf', u'i386', u'powerpc', u'ppc64el'), archindep_arch
[19:16] <cjwatson> So no lock problem
[19:17] <infinity> Hah.  LP is timing out creating milestones.  La la la.
[19:18] <cjwatson> Still need to do germinate output, but all the seeds exist on the mirror now which is good enough for the publisher
[19:19] <infinity> Wait, that's not a timeout, that's something more insidious.
[19:19] <infinity> I'm getting the "Please try again" error page.
[19:19] <cjwatson> Do you have an oops?
[19:19] <infinity> No, see above.
[19:19] <infinity> OOPSless, it's the page you get during maint.
[19:20] <cjwatson> Oh.  Looks normal here, I can manual/auto a builder just fine ...
[19:20] <cjwatson> Maybe you can't create milestones during IDS?
[19:20] <infinity> Maybe.
[19:20]  * infinity shrugs and moves down the list to see what can happen in parallel.
[19:21] <infinity> I can do the bootstrap archive twiddling.
[19:22] <cjwatson> You could probably do the edit-acl too
[19:22] <cjwatson> 12 and 13
[19:22] <cjwatson> NoNameYet_xnox: Your nick is wrong now. :-)  Do you know how to branch-distro?  Not quite time yet but will be shortly
[19:22] <infinity> I did those post-release.
[19:23] <infinity> Well, I did 12 post-release.  13 might need doing (but it implies it should maybe be automatic)
[19:24] <cjwatson> Oh, yeah, IDS might do it
[19:24] <cjwatson> In fact it might grant ubuntu-sru access too since we did 12 early ...
[19:24] <cjwatson> So you'll want to check that
[19:26] <cjwatson> IWBNI IDS gave any intermediate feedback whatsoever.  *nervous*
[19:28] <cjwatson> I'm sure it was more like 7min last time
[19:28] <cjwatson> Ah, there
[19:29] <cjwatson> 2014-04-23 19:28:44 INFO    Ran 1 InitializeDistroSeriesJob jobs.
[19:29] <cjwatson> 13mins
[19:30] <cjwatson> re-enabled publisher, will run in ~4mins
[19:31] <infinity> Ahh, milestone creation works now.
[19:31] <cjwatson> (Also, I can't add, publisher will be at :33)
[19:35] <infinity> cjwatson: Yeah, drat, it copied the perms from trusty.  of course.
[19:35]  * infinity will edit.
[19:36] <cjwatson> publisher taking ages to say anything for some reason; I guess it lacks logging in this situation
[19:38] <cjwatson> Ah, there
[19:38] <cjwatson> 2014-04-23 19:37:08 INFO    Creating archive indexes for utopic, utopic-backports, utopic-security, utopic-updates, utopic-proposed.
[19:38] <infinity> Alright, queue rights look sane, bootstrap archive fixed up.
[19:38] <infinity> cjwatson: Should be good to go to toss in chroots now?
[19:38] <cjwatson> Yup
[19:38] <infinity> Ahh, yes, should be.
[19:39] <infinity> Throwing in trusty chroots for now, will fix (and reenable bootstrap bits) later.
[19:40] <cjwatson> I've taught archive-reports etc. about utopic; it may be temporarily confused but whatever
[19:41] <infinity> I'll do a partner copy in a sec.
[19:41] <cjwatson> infinity: I think I have to go now, but the delicate bit is done.  I suggest compare-archives after this publisher run + archive-reports and then the second publisher should fix everything up properly
[19:42] <infinity> cjwatson: *nods*
[19:42] <cjwatson> So yay
[19:42] <cjwatson> If you want to continue wittering here then I can pick up later
[19:42] <stgraber> qatracker is ready for utopic (copied manifest over from trusty, setup testsuites and daily milestone)
[19:43]  * stgraber goes to create a few system-image channels now
[19:43] <cjwatson> BTW proposed-migration is stopped by way of ~ubuntu-archive/proposed-migration/STOP
[19:43] <cjwatson> So if you get to the point where you want it to run again and you're sure it has been adequately educated, rm that
[19:43] <infinity> cjwatson: Check.
[19:43] <cjwatson> Actually I can minimally educate it now
[19:46] <cjwatson> I wonder if autopkgtest will work with utopic
[19:46] <cjwatson> ah there's an entry for that
[19:47] <cjwatson> jibel: could you please set up autopkgtest for utopic?
[19:47] <cjwatson> proposed-migration configured for utopic (but still stopped)
[19:47] <cjwatson> gone
[19:47] <infinity> cjwatson: Ta.
[19:49] <infinity> I think I've angered LP with my chroot uploads.
[19:49]  * infinity taps his foot.
[19:58] <cjwatson> infinity: (oh look, still slightly around) compare-archives looks fine
[19:59] <cjwatson> so we're up to and including 10, except for 8
[19:59] <cjwatson> assuming you got milestones done
[20:00] <infinity> Milestones done.
[20:00] <infinity> Partner should be okay once it publishes my copy.  I'll wait another cycle.
[20:00] <infinity> 12 and 13 are done.
[20:00] <infinity> 14 and 15 are done.
[20:01] <cjwatson> 18 (merge-o-matic) done
[20:01] <infinity> cjwatson: Can we turn on p-m without adt working, or will it explode?
[20:01] <cjwatson> ... I forget
[20:01] <cjwatson> you could disable it by temporarily emptying ADT_SERIES
[20:02] <cjwatson> or just let it explode and force things as needed
[20:02] <cjwatson> it shouldn't explode in a way that permanently blocks p-m or anything
[20:02] <infinity> Well, depends on the definition of "explode". :)
[20:02] <infinity> If it just fails all the tests, that's "fine" for now.
[20:02] <cjwatson> Yeah, I think that's the worst case
[20:02] <infinity> So, 8 and 17...
[20:03] <infinity> And 16.
[20:03] <cjwatson> No rush on 17, I'll do that later / tomorrow
[20:03] <cjwatson> 8 can either wait until xnox is around or you can see if a webop knows how
[20:03] <cjwatson> 13?
[20:03] <infinity> I did 13.
[20:04] <infinity> So, we can defer 8, 16, and 17, and I think we're up to toolchain bits.
[20:04] <infinity> (Once the publisher runs again)
[20:05] <cjwatson> should be safe to jam in whatever toolchain bits we have now, yeah
[20:05] <infinity> doko: That's your cue for binutils/gcc, if you're still around.
[20:06] <infinity> I'll let my base-files in to build once this publisher settles.
[20:06] <cjwatson> IDS has over-copied a spare grub-efi-amd64 for some reason but I'll look into that tomorrow, ignore for now if you happen to be fine-tooth-combing compare-archives
[20:06] <infinity> I'm taking your word on compare-archives, I don't think it needs two of us.
[20:07] <infinity> skype just published to partner, will check that archive once the mirror pushes.
[20:07] <cjwatson> second publisher is mostly done; you should be all good there now
[20:08] <cjwatson> all it really lacks at this point is Contents, which I expect will be filled in tonight
[20:08] <infinity> Yeah, should be good to let base-files build and see if it implodes.
[20:08] <cjwatson> yup
[20:08] <cjwatson> really gone
[20:09] <doko> infinity, cjwatson: thatÄs for tomorrow morning
[20:09] <infinity> doko: Do either of your uploads need to be pre-open, or do you just want them pre-debian-import?
[20:10] <infinity> (ie: is there much of an argument to wait on them?)
[20:11] <doko> infinity, the binutils upload should be pre-open, I don't care about the other ones (besides the ruby default, but ScottK did volunteer for this)
[20:12] <infinity> doko: Kay.  The binutils you already had prepped, right?  Want me to just grab it from chinstrap, twiddle the changelog target and upload for you?
[20:12] <infinity> base-files builds looked sane.
[20:12] <doko> sure
[20:13] <doko> I thought you didn't want to rush things?
[20:13] <infinity> distro-info-data looks sane too, if someone wants to SRU that.
[20:14]  * stgraber does the usual extras.ubuntu.com trick to generate the needed indices
[20:14] <infinity> bdmurray: Feel like snagging my distro-info-data delta from utopic and SRUing it back to current releases?
[20:15] <infinity> bdmurray: I'll review, and we can push an instant release if it all looks sane.
[20:15] <infinity> bdmurray: (Or vice versa, I can do the SRUs and you can review)
[20:15] <infinity> partner looks published correctly.
[20:16] <bdmurray> I'll do the SRU if you could review my P and S fixes for bug 1311396
[20:16] <ubot2> Launchpad bug 1311396 in ubuntu-release-upgrader (Ubuntu Saucy) "broken croatian translation results in traceback in new release notification" [High,In progress] https://launchpad.net/bugs/1311396
[20:19] <infinity> bdmurray: Looking.
[20:20] <infinity> bdmurray: Is that what was being reported on IRC a little while back, or something else?
[20:20] <infinity> Oh, must be something else, based on the timestamp.
[20:22] <bdmurray> infinity: yeah, something else fun
[20:22] <infinity> bdmurray: Japanese isn't broken in S?
[20:23] <infinity> bdmurray: And none of these are broken in Q?  (I haven't EOLed Q just yet, but feel free to not care)
[20:33] <bdmurray> infinity: no, japanese is fine in saucy
[20:33] <infinity> bdmurray: Kay, cool.
[20:33] <infinity> bdmurray: Accepted both, assuming that would be your answer.
[20:33] <bdmurray> mvo and I talked about modifying pre-build.sh to check for this
[20:33] <infinity> bdmurray: Hard failing the actual build on msgfmt errors wouldn't hurt either.
[20:35] <infinity> bdmurray: I'm not a huge fan of too much logic living in weird pre-build scripts outside debian/rules.  It's good to get the import right, but it's also good to make sure the build itself is sane.
[20:35] <infinity> bdmurray: (And if the build fails, you won't upload, cause you always testbuild, right?)
[20:36] <bdmurray> infinity: right unless it is distro-info-data
[20:37] <infinity> bdmurray: Need a d-i-d for precise too, methinks.
[20:38] <bdmurray> its coming
[20:38] <infinity> Oh, c'mon LP, how is there not a debdiff for the saucy one yet?
[20:38] <Logan_> infinity: can we have Utopic derive from Sid instead of Jessie?
[20:39] <infinity> Logan_: I assme you mean where debian autosyncs will come from, that's sid.
[20:39] <Logan_> no: https://launchpad.net/ubuntu/utopic
[20:39] <Logan_> > Derived from Jessie
[20:39] <infinity> Logan_: Right, that's not particularly meaningful.
[20:39] <Logan_> well, the package diffs are helpful (although there's also MDT for that)
[20:40] <Logan_> and it compares against Jessie instead of Sid
[20:40] <infinity> Oh, you're the one person who uses that page? :)
[20:40] <Logan_> thank you for making me feel special! :)
[20:40] <Logan_> I was always a unique one
[20:40] <infinity> Logan_: So, this is pretty much how we always set this up.
[20:41] <Logan_> there's always room for change!
[20:41] <infinity> Also not sure if that can be changed post-init. :P
[20:41] <Logan_> gah, should've asked before
[20:42] <infinity> Logan_: I believe if you ask LP people, they consider that feature pretty much broken by design anyway.  I wouldn't worry too much about it.
[20:42] <Logan_> alrighty
[20:43] <infinity> (base)adconrad@cthulhu:~$ sru-review -s saucy distro-info-data
[20:43] <infinity> ERROR: queue does not have a debdiff
[20:43] <infinity> bdmurray: ^-- What crack is sru-review smoking?
[20:44] <bdmurray> infinity: works for me
[20:44] <infinity> ...
[20:44] <infinity> Bad cache, I guess.
[20:44]  * infinity wipes out his lplib cache.
[20:45] <infinity> Which is, apparently, enormous.
[20:46] <infinity> bdmurray: Thanks for those.
[20:47] <infinity> ScottK: Did you still want to do some ruby mangling pre-open?
[21:46] <tumbleweed> finally, a name. thanks infinity
[22:26] <cjwatson> infinity: How goes?
[22:27] <infinity> cjwatson: Taking a break on 19 for doko (maybe) and ScottK (he had some ruby stuff he wanted to do for opening)
[22:27] <infinity> cjwatson: Though, I suppose we can call those things "pre-autosync" rather than "pre-thaw" and no one will care much.
[22:27] <infinity> cjwatson: Going to skip down to livefs chroots shortly, just a bit distracted at the moment.
[22:28] <xnox> cjwatson: i have no rights to do branch-distro someone more powerful needs to do that.
[22:28] <xnox> cjwatson: i'll check udd to be up-to-date, unless it has been done already
[22:28] <cjwatson> OK
[22:28] <wgrant> xnox: branch-distro is in progress
[22:28] <wgrant> It will take $longtime
[22:28] <wgrant> UDD must not be restarted until it is complete
[22:30] <cjwatson> infinity: OK, well, if you're ready to start auto-sync and I'm not around, just drop --dry-run from that crontab entry on snakefruit
[22:30] <cjwatson> But we should make sure that p-m is working first
[22:30] <cjwatson> infinity: Shall I try turning on p-m?
[22:31] <infinity> cjwatson: Can't hurt.
[22:31] <infinity> (famous last words)
[22:32] <infinity> cjwatson: If it seems to be working correctly, I'll do the carefully selective mass copy/delete from t-p to u-p.
[22:34] <cjwatson> Running
[22:35] <infinity> Oh, actually, I won't do the copy/delete until adt is back up.
[22:35] <cjwatson> Grr, needs fixing mk2.  Let me just get my daughter a drink then I'll try again
[22:35] <infinity> Just in case something in there would actually migrate without tests.
[22:36] <infinity> Though I think it was all missing binaries.
[22:36] <infinity> I think.
[22:39] <xnox> Logan_: it's best to derive from jessie imho, since otherwise everything is always derived from sid.... and the diffs will just keep on pointlessly growing post-ubuntu-release.
[22:39] <xnox> wgrant: i've stopped UDD a while back (wednesday release week).... so much for wishful release name thinking.
[22:40]  * xnox looks what else i can do.
[22:41] <cjwatson> Right, had to copy the Dates file over, let's try that again
[22:48] <infinity> Oh, whee, I have 13 minutes to get to my dinner appt with my brother.  I'll be back in a couple of hours, though.  The rest of the checklist just seems like crossed Ts and dotted Is, except for the cdimage stuff, which I can do later tonight.
[22:49] <cjwatson> Setting up chdists
[22:49]  * infinity runs out.
[22:57] <ScottK> cjwatson: We need to sync in ruby2.1 and make it default (per doko).  I can do it if you're ready for it.
[22:57] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html looks plausible; I might drop the block shortly
[22:57] <cjwatson> ScottK: Please do
[22:58] <cjwatson> Well, unless it wants to go after binutils
[22:58] <ScottK> OK.  Never done Ruby before, so let's give this a shot ...
[23:01] <cjwatson> I guess there isn't really a problem with this going before binutils; should only need to have that before the general bulk
[23:02] <bdmurray> Should step 12 (ubuntu-sru queue admin access) from NewReleaseCycleProcess move to the ReleaseProcess page?
[23:02] <ScottK> cjwatson: Any objection to me waving ruby2.1  through New?
[23:02] <cjwatson> bdmurray: It's better where it is, because ideally (i.e. without this stupid name delay) it comes after initialising the new series, so that it doesn't get copied over
[23:02] <cjwatson> ScottK: None except that I just did
[23:02] <ScottK> OK.
[23:02] <ScottK> Thanks.
[23:03] <ScottK> OK, so while that builds, I'll go learn how to make it default.
[23:03] <bdmurray> cjwatson: okay, fyi I think infinity did that step last Friday
[23:03] <cjwatson> bdmurray: Yeah, we dealt with the fallout today
[23:04] <cjwatson> When things aren't pathological the process as written is better :-)
[23:04] <bdmurray> cjwatson: got it
[23:04] <Logan_> xnox: fair enough
[23:08] <ScottK> xnox: Did you figure out what boost version we want?
[23:09] <xnox> ScottK: i've mailed debian maintainer, we want to go for .55 but i haven't done a test rebuild in either ubuntu nor debian.
[23:09] <xnox> ScottK: i could upload the switch to e.g. experimental and sync. But i'd also need to do the .55 package split.
[23:10] <ScottK> cjwatson: doko specifically said he wanted ruby2.1 as default, but Debian is still on 2.0.  It's easy enough on the packaging side for me to set it as 2.1, but I'd like someone else to agree with it who's here right now.
[23:10] <xnox> infinity: ideally i'd love to get the boost 1.55 as default pre-debian-import.....
[23:12] <xnox> ScottK: looking at changes between 2.0 and 2.1 it's fairly minimalistic. If there is fallout / incompatibilities i'm happy to work on fixing them.
[23:12] <cjwatson> I don't think I have an opinion on ruby
[23:12] <xnox> ScottK: my ruby  is rusty, but i don't see anything scary at all.
[23:12] <cjwatson> The main problem historically has just been somebody actually caring for it properly in Ubuntu; if xnox is happy to step up to that ...
[23:13] <ScottK> Yep.  I'll upload it once ruby2.1 is built.
[23:14] <xnox> here be unicorns! =)
[23:16] <slangasek> mmm, tasty unicorns
[23:16] <xnox> slangasek: i think we should start adding easter-eggs e.g. to pop-up mascot PNG if one does something, cause unicorn will be an awesome mascot =)
[23:18] <slangasek> we should just bundle http://games.adultswim.com/robot-unicorn-attack-twitchy-online-game.html
[23:21] <xnox> slangasek: I heartbleed ^_^
[23:24] <ScottK> Needed for ruby2.1 ^^^
[23:31] <ScottK> Thanks.
[23:33] <xnox> ScottK: yeah, got agreement from Steve to do 1.55 by default in experimental and also sync into ubuntu
[23:34] <ScottK> OK.
[23:34] <ScottK> It would be nice to get that done before the first autosync.
[23:36] <cjwatson> Urgh, no syncpackage.
[23:36] <cjwatson> -proposed.
[23:56] <kirkland> can someone approve byobu 5.77-0ubuntu1.1 into trusty-proposed?
[23:56] <kirkland> I have motivated testers ready and waiting...


[00:58] <dax> !kpti
[00:58] <dax> changed the Ubuntu link to that insights.ubuntu.com one
[00:59] <dax> as it covers things like why there aren't already updates out a bit better
[01:04] <TJ-> "because we're all still on holiday!" :)
[01:04] <Ben64> ok so no update for 17.04 or 17.04's hwe kernel
[01:07] <TJ-> well it looks as if the trickle of x86/mm patches might be done now so we may be able to backport with confidence. Others will have to do another kernel release to include the more recent fixes.
[01:24] <dax> there's an odd clause in that insights blogpost though
[01:24] <dax> "Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date, and sooner if possible. "
[01:25] <dax> does it not affect 32-bit, or...?
[01:32] <TJ-> I've not seen anything in the papers or the patches that suggests x86 32-bit isn't affected. I suspect that sentence is a focused oversight
[01:34] <dax> yeah, I hadn't seen anything either. it is odd.
[01:34] <dax> *shrug* will just wait and see what they come out with
[05:50] <lotuspsychje> good morning to all
[05:50] <daftykins> heya :)
[05:50] <lotuspsychje> hey daftykins
[05:51] <lotuspsychje> !kpti
[05:51] <lotuspsychje> any news yet?
[05:51] <daftykins> not been looking if i'm honest :)
[05:51] <lotuspsychje> hmm just a ruby flaw added
[05:55] <lotuspsychje> http://www.omgubuntu.co.uk/2018/01/gnome-desktop-icons-removed-3-28
[05:56] <lotuspsychje> ah!
[05:56] <lotuspsychje> http://news.softpedia.com/news/canonical-will-soon-patch-all-supported-ubuntu-releases-against-meltdown-spectre-519234.shtml
[05:57] <lotuspsychje> news afterall
[05:57] <lotuspsychje> dax: can you use any of this ^
[05:58] <lotuspsychje> https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-the-meltdown-spectre-vulnerabilities/
[05:58] <dax> re: the icon thing: saw talk about that on IRC earlier today, good chance Ubuntu won't be going with nautilus 3.28 for 18.04 because of it
[05:58] <dax> that insights post is on !kpti now, added it a few hours ago
[05:59] <dax> it's the ubottu.com shortened link
[05:59] <lotuspsychje> ah great tnx
[05:59] <dax> that's the most recent news i've seen, personally
[05:59] <lotuspsychje> yep
[05:59] <dax> the softpedia post is basically a restatement of the insights.ubuntu.com one, so i'd go with the latter
[06:00] <lotuspsychje> dax: agree :p
[06:00] <lotuspsychje> few days more settle down users now
[06:01] <lotuspsychje> !info gnome-shell bionic
[06:04] <lotuspsychje> http://www.zdnet.com/article/how-linux-is-dealing-with-meltdown-and-spectre/
[06:04] <lotuspsychje> linus is mad oO
[06:06] <Ben64> ew, autoplaying video
[06:06] <lotuspsychje> lol
[07:29] <lotuspsychje> welcome
[07:36] <DrManhattan> hola
[07:37] <DrManhattan> so do you think 4.10 to 4.15 stable vanilla would be too big a jump?
[07:37] <DrManhattan> it's still using the ubuntu configs, I love it!
[07:37] <DrManhattan> seriously thanks again this is better than I could have hoped for
[07:38] <DrManhattan> I wish it would update via APT
[07:38]  * DrManhattan cracks his knuckles
[07:49] <daftykins> !mainline
[07:49] <daftykins> it can
[07:49] <daftykins> but you shouldn't chase version numbers
[07:55] <ducasse> good morning, all
[07:58] <lotuspsychje> hey ducasse
[08:01] <ducasse> hi lotuspsychje, how are you today?
[08:01] <lotuspsychje> great here, what about you ducasse
[08:03] <ducasse> i'm fine, thanks
[08:03] <ducasse> still waking up :)
[08:06] <lotuspsychje> coffee to the rescue
[08:06] <lotuspsychje> or tea
[08:26] <DrManhattan> daftykins, I just want to chase the latest that Linus says is good to go ::)
[08:28] <daftykins> ducasse: \o
[08:28] <daftykins> DrManhattan: afraid of the news story huh? waste of time
[08:30] <daftykins> just wait for patches to your normal kernel :) or just boot with the kernel boot parameter
[08:31] <DrManhattan> Noes not the news
[08:33] <ducasse> \o daftykins - how goes?
[08:33] <daftykins> DrManhattan: why chase versions then?
[08:34] <daftykins> ducasse: not too shabby thanks, although this morning is a little boring :)
[08:37] <ducasse> daftykins: mornings usually are :)
[08:40] <DrManhattan> daftykins, because we can!
[08:40] <daftykins> DrManhattan: that's really silly
[08:42] <DrManhattan> No, it is not silly.
[08:43] <daftykins> yeah it is, because you'll be just fine staying with your distros patches as they become available
[08:43] <lotuspsychje> bbl brunch :p
[10:11] <immu> hi
[11:33] <BluesKaj> Howdy folks
[11:40] <EriC^^> hey BluesKaj
[11:40] <BluesKaj> Hi EriC^^
[11:40] <EriC^^> how's it going?
[11:42] <BluesKaj> good here, we have an arctic blast here ...very very cold even for my neck of the woods, but otherwise I'm fine, How about you?
[11:45] <EriC^^> i'm ok, it's very cold here as well, it's been raining for the past 3 days straight
[12:25] <pauljw> hi everyone
[12:31] <BluesKaj> 'Morning pauljw
[12:31] <pauljw> hey BluesKaj :)
[14:04] <lotuspsychje> good afternoon
[14:07] <lotuspsychje> 1377 users
[14:07] <lotuspsychje> hey BluesKaj
[14:08] <BluesKaj> hi lotuspsychje
[14:08] <lotuspsychje> BluesKaj: !kpti edited
[14:10] <BluesKaj> lotuspsychje, guess we just need some patience with the kpti patches
[14:15] <lotuspsychje> yeah
[14:46] <lotuspsychje> whats that package channel called again guys?
[14:46] <lotuspsychje> where they spam new releases
[14:57] <hggdh> lotuspsychje: for Ubuntu? #ubuntu-release
[14:57] <lotuspsychje> ah tnx hggdh
[14:57] <lotuspsychje> thats the one i looked for :p
[14:59] <TJ-> it doesn't show up in an /alis search, strangely
[15:05] <lotuspsychje> hi Scytale89
[15:10] <EriC^^> hey lotuspsychje
[15:11] <lotuspsychje> hey EriC^^
[15:11] <EriC^^> how's it going?
[15:11] <lotuspsychje> great here tnx and you EriC^^
[15:11] <EriC^^> great thanks
[15:11] <EriC^^> seen any good movies lately?
[15:12] <lotuspsychje> hmm not really
[15:12] <EriC^^> i saw source code, not bad
[15:13] <lotuspsychje> cool
[15:13] <lotuspsychje> EriC^^: did you check who am i yet?
[15:13] <EriC^^> nope what's that?
[15:13] <lotuspsychje> german hack movie lol
[15:13] <EriC^^> oh
[15:13] <lotuspsychje> lemme find link
[15:14] <EriC^^> is it in english?
[15:14] <lotuspsychje> https://en.wikipedia.org/wiki/Who_Am_I_(2014_film)
[15:14] <lotuspsychje> no german, but you might find one with eng subs
[15:16] <lotuspsychje> 7.6 imdb
[15:16] <lotuspsychje> not bad heh
[15:19] <jink> Meh, not on Netflix (yet?).
[15:28] <EriC^^> :D
[16:02] <lotuspsychje> 1423 users EriC^^
[16:29] <EriC^^> nice
[16:30] <lotuspsychje> that uefi guy is back EriC^^
[16:30] <EriC^^> which one?
[16:30] <EriC^^> oh monk2
[16:30] <lotuspsychje> ye
[16:31] <EriC^^> source code is kinda mind boggling
[16:32] <EriC^^> you gotta see it, though i cant talk much without giving away something
[16:32] <lotuspsychje> how much on imdb?
[16:32] <EriC^^> lol who cares i am the imdb god
[16:32] <EriC^^> haha
[16:32] <lotuspsychje> lol
[16:32] <EriC^^> 7.5/10
[16:32] <lotuspsychje> what was i thinking hehe
[16:33] <EriC^^> it's not like anything you've ever seen though
[16:33] <EriC^^> 'A soldier wakes up in someone else's body and discovers he's part of an experimental government program to find the bomber of a commuter train. A mission he has only 8 minutes to complete. '
[16:33] <lotuspsychje> 2011 movie?
[16:33] <EriC^^> yeah it's kinda old
[16:59] <lotuspsychje> hey Bashing-om
[17:05] <Bashing-om> lotuspsychje: :) .. Geting settled in for another fun day - hoz it been ?
[17:05] <lotuspsychje> Bashing-om: kind crowdy, 1423+
[17:07] <Bashing-om> The more the merrier :P
[17:08] <lotuspsychje> lol
[17:33] <lotuspsychje> bbl
[20:54] <lotuspsychje> nite nite all