[06:09] <mborzecki> morning
[06:21] <mup> Bug #1749374 opened: The /bin/sync command is not allowed by default <Snappy:New> <https://launchpad.net/bugs/1749374>
[06:33] <zyga> hey
[06:33] <zyga> mborzecki linode was broken last night
[06:33] <mborzecki> zyga: did we break it?
[06:33] <zyga> I suppose so
[06:34] <zyga> it stopped responding to API requests
[06:34] <mborzecki> haha omg
[06:34] <zyga> let's hope it's not that bad today
[06:35] <mborzecki> zyga: any idea how advanced is the move to GCE or DO?
[07:22] <zyga> mborzecki no, I hope it's under way though
[07:26] <zyga> mborzecki are any of your branches working/
[07:27] <mborzecki> zyga: don't have any new PRs open atm
[07:33] <zyga> I'm running tests in linode and locally to compare
[07:48] <zyga> mborzecki can you please have a look at 4664
[07:48] <zyga> it is designed to unbreak master
[07:48] <zyga> it came out of 4658
[07:48] <zyga> I also pushed it there to show that it fixes things
[07:48] <zyga> (except where linode doesn't work)
[07:49] <mborzecki> looking
[07:50] <zyga> I could move some of the patches out to an even smaller prerequisite branch if that helps
[07:52] <kalikiana> o/
[07:53] <zyga> hey kalikiana
[08:04] <telboon-> hmm. is snap designed to be a fully secured container?
[08:04] <zyga> it depends on what you mean by a container
[08:04] <telboon-> cos i've somehow just escaped the snap and managed to create files outside of the container...i think
[08:04] <zyga> snap apps are not typical containers
[08:04] <telboon-> are they meant to protect the rest of the environment?
[08:04] <zyga> it depends
[08:05] <zyga> it all depends on how you installed the snap, which interfaces you connected to it and what the "outside of the container" really is
[08:05] <zyga> please tell me more and I will try to help you
[08:05] <zyga> if you think this is a security issue you can contact me in private
[08:05] <zyga> or send me an encrypted mail
[08:08] <zyga> telboon- let me know if you need more information
[08:09] <telboon-> zyga: let me try to reproduce it in a few scenarios
[09:15] <zyga> + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
[09:15] <zyga> <kill-timeout reached>
[09:15] <zyga> hmm :/
[09:17] <zyga> I see this often but on random tests
[09:20] <Chipaca> with all the verbosity in tests, maybe we should add a -v to that tar :-)
[09:23] <zyga> -vv
[09:23] <zyga> --poem
[09:23] <mvo> zyga: quick question, how far are user mounts away (roughly)? days? weeks?
[09:23] <zyga> mvo days
[09:23] <zyga> mvo but unhappy master is making stuff sad
[09:23] <zyga> or is it just my branch?
[09:23] <zyga> hey mvo, how are you doing?
[09:24] <mvo> zyga: I'm fine thank you
[09:24] <mvo> zyga: yeah, unhappy master makes me unhappy too
[09:25] <mvo> zyga: what error do you see? I also see some strange errors
[09:25] <zyga> timeouts
[09:25] <zyga> but not the ones we saw before
[09:25] <zyga> I see tests reaching 49 minutes
[09:25] <zyga> many linode api errors
[09:25] <zyga> errors on tar (see above) being killed by timeout
[09:25] <zyga> honestly, I don't know what's wrong
[09:26] <zyga> mvo I ran my branch in qemu all the way (though not without hiccups)
[09:26] <mvo> zyga: ok
[09:26] <zyga> but my record on linode is "red since yesterday"
[09:27] <zyga> maybe something is related to nfs, I need to look at that
[09:27] <zyga> + umount /home
[09:27] <zyga> umount.nfs: /home: device is busy
[09:27] <zyga> 2018-02-14 08:26:18 Error restoring linode:ubuntu-16.04-64:tests/main/nfs-support :
[09:27] <zyga> we cannot unmount nfs, then we cannot remove the nfs kernel server package
[09:28] <Chipaca> zyga: and you can't umount home because that's where spread's running
[09:29] <Chipaca> zyga: chroot time?
[09:29] <Chipaca> would that even work
[09:29] <zyga> Chipaca this is not a new test
[09:29] <zyga> look at main/nfs-support
[09:31] <Chipaca> zyga: i see it, but i still wonder it works
[09:31] <Chipaca> zyga: does it hang every time with your changes?
[09:31] <zyga> no
[09:32] <Chipaca> ah drat :-)
[09:32] <zyga> yeah
[09:32] <zyga> so something else depends on ordering
[09:32] <Chipaca> zyga: does it hang every time if you specify the seed of the time it hung?
[09:32] <zyga> maybe my patch is just broken
[09:32] <zyga> I didn't try (~~ hours)
[09:32] <zyga> let's see
[09:32] <Chipaca> zyga: if it's reproducible, you can figure out what's holding it back
[09:33] <Chipaca> zyga: OTOH if it works with any subdir instead of just home, maybe use a subdir in the tests, one that isn't being used by the tests :-)
[09:33] <Chipaca> (but if it works sometimes, maybe figuring out what blocks it when it doesn't is better)
[09:33] <zyga> the unmount earlier should not have failed
[09:33] <zyga> some process is lurking
[09:34] <zyga> but
[09:34] <zyga> this is just one of the failure
[09:34] <zyga> *failures
[09:34] <mwhudson> does anyone here have any Opinions on go 1.9 vs go 1.10 as default in bionic?
[09:34] <zyga> mwhudson I suspect 1.10 is just a bit younger so it will be EOLd later
[09:34] <zyga> mwhudson does go have LTS-like releases?
[09:34] <pedronis> no
[09:34] <mwhudson> right, that's certainly a consideration, and no
[09:35] <pedronis> it's why we should really think how to use newer go
[09:35] <pedronis> for snapd, at some point it will bite us
[09:36] <zyga> using new go is easy, using new go everywhere is hard
[09:36] <zyga> changing base requirement is hard
[09:38] <mborzecki> it will have to happen at some point though
[09:39]  * zyga reproduced nfs error with debug shell
[09:39] <zyga> inspecting
[09:51] <zyga> hmmmmmm
[09:54] <zyga> so, I have a suspicion
[09:57] <zyga> it is actually related to nfs
[09:57] <zyga> my code was too optimistic
[09:57] <zyga> and it's failing
[09:57] <zyga> when the nfs aspect changes the code won't load the profile
[09:57] <zyga> the reexec profile handling code needs to be nfs aware
[09:57] <zyga> hmm hmmm
[09:58] <zyga> (that came out wrong, it's more subtle)
[09:58] <zyga> I'm running another run with extra logging
[09:59] <zyga> mvo can you look at 4664 since you wrote the original code there
[10:02] <mvo> zyga: ok
[10:03] <mvo> zyga: debugging a thorny test fialure right now, will do once that is done
[10:10] <mvo> zyga: silly question, what was broken in the old one?
[10:11] <ikey> zyga, jdstrand https://youtu.be/faqQuJkqCIA?t=584 or "why steam snap is threatened"
[10:13] <zyga> mvo the old one was happy with stale file on disk
[10:13] <zyga> mvo as long as it was present it would say, yeah fine
[10:13] <mvo> zyga: how could the file be stale? it was rewriten on a new core release and once written the core template never changes?
[10:14] <zyga> mvo because our test code tarballed the state
[10:14] <zyga> and it contained the old one after fresh core install
[10:14] <zyga> then we repackage core and things go down from there
[10:14] <mvo> zyga: could we just exclude this file from the saved state in the tests? would that re-generate it ?
[10:15] <zyga> yes
[10:15] <zyga> though I would really prefer a properly working generator
[10:15] <zyga> I *think* I fixed it now, testing locally
[10:15] <zyga> well, I suspect I know what the problem was, now I'm thinking about how to solve it in a non-hackish way
[10:16] <mvo> zyga: sure, was mostly trying to understand it (and also thinking YAGNI a bit). I have a look in a wee bit
[10:17] <zyga> mvo the new code is conceptually easier to grok IMO, just the bugging aspect of apparmor nfs
[10:17] <zyga> thanks!
[10:17] <mvo> heh, ok - if it really is easier I will shut up and hug you
[10:18] <zyga> yes, just now we see why the old code worked in more cases :)
[10:18] <zyga> it always reloaded
[10:18] <zyga> mvo I also found a subtle error escaping due to error mishandling
[10:18] <zyga> but nothing serious
[10:18] <zyga> https://github.com/snapcore/snapd/pull/4664/files#diff-57dc34ab6f4bf9730b356d0439daa0fdL208
[10:18] <mup> PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
[10:19] <zyga> if err is an error (but not ENOENT) it will be ignored
[10:19] <mvo> zyga: nice catch
[10:21] <zyga> whee
[10:21] <zyga> ok works
[10:23] <mup> PR snapd#4665 opened: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[10:24] <zyga> uh
[10:24] <zyga> I hit wrong key and suspended my VM
[10:24] <Chipaca> ogra_: I blame you ^
[10:24] <Chipaca> making me look at code
[10:25]  * ogra_ makes note to cash in bonus for that
[10:25] <popey> zyga: what was the outcome yesterday of the opensuse conversation, I may have missed it. Are we likely to get an update over there soon?
[10:27] <zyga> popey not sure, there's a community member that works on packaging snapd for factory
[10:27] <zyga> I reached out to him and invited him to join us here
[10:28] <zyga> mvo: https://github.com/snapcore/snapd/pull/4658/commits/0a0a3faa4e0b7f6ef5fdda907870924668523625
[10:28] <mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
[10:28] <zyga> popey I',m "not sure" because it can also mean that the update will take a while and will hit opensuse properly
[10:28] <zyga> I think someone should still look at the "PPA"
[10:35] <mup> PR snapd#4666 opened: interfaces/apparmor: generalize apparmor load and unload helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/4666>
[10:39] <mvo> zyga: reviewed and agreed, its conceptually simpler
[10:41] <ikey> OK looking for some details please, because finding out the true roadmap is a somewhat opaque thing..
[10:41] <ikey> 1) How far away is actual complete desktop integration (theming, etc.)
[10:41] <ikey> 2) What is the current holdup with apparmor changes to unblock steam-support?
[10:44] <pedronis> ikey: afaiu from the forum  jdstrand was waiting on input from Gustavo about 2
[10:45] <ikey> Ok ty
[10:45] <ikey> In that case I'm removing snapd integration from the roadmap for Solus 4
[10:45] <ikey> We were meant to be releasing in january and this snapd debacle has had me held up for months now
[10:45] <ikey> I've lost too much time on this
[10:46] <ikey> I can't support crippling of our own cadence to match that of Ubuntu
[10:48] <mvo> ikey: theming and all that is pretty close (zyga will know the details but my understanding is that most of things needed to make it work have landed now)
[10:48] <pedronis> ikey: afaiu our deadline its +-  beginning of march
[10:48] <zyga> mvo theming is now open for business but it's just getting started on the actual theme snaps
[10:49] <ikey> Would be nice if that had been communicated ahead of time to others, thats what I mean about opaque
[10:49] <ikey> I'm flying blind on the outsides here
[10:49] <ikey> But I believe it safe to say that snapd isn't completely ready yet for the desktop
[10:49] <zyga> ikey theming will be in 18.04 for sure but it's not here now
[10:49] <ikey> Right, an Ubuntu target
[10:49] <zyga> well, more less a deadline for us to reach, many things are in progress
[10:50] <pedronis> I didn't even know you were waiting on us, so I'm probably the wrong person to chime in either way
[10:50] <ikey> pedronis, several months now
[10:50] <zyga> ikey I agree that themes are a known missing feature
[10:50] <niemeyer> ikey: We are late on it ourselves.. and it's not because we are bound to Ubuntu, but because it takes time to develop.. zyga has been working on mounts since forever
[10:50] <ikey> It's taken so long that the flatpak/collabora camp are now developing their own version of what I've been blocked on
[10:51] <ikey> Which to be blunt is crippling my own value-add
[10:51] <ikey> By putting all my eggs in one basket
[10:51] <ikey> At this point waiting on snapd is affecting business decisions in Solus, and I can't allow that to continue
[10:51] <ikey> (I know, its the word we don't like to use)
[10:51] <ikey> But that is the reality
[10:52] <ikey> So I'll defer snapd integration until such point as its suitable and remove it from the Solus 4 roadmap
[10:52] <ikey> As we're way overdue
[10:52] <ikey> Then we can revisit it around the time of 18.04
[10:53] <niemeyer> ikey: It's okay, by the end of the day you know your own priorities much better than anybody else.. we'll continue to be here pushing things forward if you change your mind
[10:53] <ikey> niemeyer, ? im not sure you get it. ive been contributing and my own work has been repeatedly blocked. its not like my mind needs changing
[10:54] <ikey> the platform isn't ready, im blocked on what i need to do for months, and i cant allow it to continue blocking the release
[10:55] <niemeyer> ikey: I totally get it.. our own work gets blocked all the time too.. the more interesting a project becomes the harder it is to make everybody happy about the pace that things move on..
[10:55] <ikey> niemeyer, thats great - but you know whats going on, us poor mortals on the outside do not
[10:56] <ikey> and snapd's interests are clearly aligned with Ubuntu and hasn't got to compete
[10:56] <zyga> ikey we'll get the desktop bits implemented and will gladly have you use snaps more in solus when you feel they meet your goals
[10:56] <niemeyer> ikey: We've been giving you and Solus a fair share of our attention, and we appreciate having you with us, but apparently we still cannot make things work for you as fast as you need
[10:56] <ikey> niemeyer, again its not about speed, its a failure in communication
[10:56] <ikey> repeatedly stone walled and left in the dark
[10:56] <niemeyer> ikey: That's not what I hear above
[10:56] <ikey> I'd appreciate it if you stopped turning this around to put yourself on the moral highground
[10:56] <niemeyer> 2) What is the current holdup with apparmor changes to unblock steam-support?
[10:56] <niemeyer> 08:44:30
 Samuele Pedroni ikey: afaiu from the forum  jdstrand was waiting on input from Gustavo about 2
[10:56] <niemeyer> 08:45:00
 ufee1dead Ok ty
[10:56] <niemeyer> 08:45:08 In that case I'm removing snapd integration from the roadmap for Solus 4
[10:57] <ikey> niemeyer, because again failure to communicate
[10:57] <ikey> i shouldnt have to be meekly asking every week
[10:57] <ikey> and more often times than not, ignored
[10:57] <ikey> Communication is the core problem
[10:57] <niemeyer> ikey: I've been on holiday because it's been Carnival in Brazil.. I'm not actually sorry for spending some of my time with my family :)
[10:57] <zyga> ikey ok, what would you have us change to make things better on communication?
[10:58] <ikey> niemeyer, dude, jesus christ
[10:58] <ikey> stop with the guilt trips and making it about you
[10:58] <niemeyer> ikey: Yes, sort of related to jesus christ
[10:58] <ikey> fuckin hell
[10:58] <ikey> ill talk to zyga
[10:58] <ikey> zyga, probably not have niemeyer interjecting with childish remarks would be a good start
[10:58] <ikey> As I said in the past, just being kept in the loop would be enough
[10:59] <ikey> Knowing how things are going and the future goals, how things are progressing, is entirely enough
[10:59] <ikey> Then folks external to Ubuntu know how to plan appropriately
[10:59] <ikey> It really is that simple
[10:59] <ikey> And doesn't require the drama that niemeyer is trying to stir
[10:59] <zyga> do you think a periodic (say weekly) update on the roadmap, blockers and similar things, in written form would be sufficient to convey this information
[11:00] <ikey> Yeah eow update sounds perfect
[11:00] <zyga> I think we have a few things going on but they are probably not coordinated with each other (some newsletters, some forum posts, etc)
[11:00] <ikey> Like I wanna be perfectly clear here, I did *not* say I was removing snapd from Solus (so the overreaction was completely unwarranted) - I said i was removing snapd *integration* from the Solus 4 roadmap
[11:00] <ikey> i.e. inclusion in the software center, promoting of default snaps
[11:01] <niemeyer> :)
[11:01] <ikey> Frankly I'm shocked at the immediate hostility
[11:01] <zyga> I agree that communication is hard and it's probably most evident for people that don't participate in daily standups where everyone shares their progress and priorities
[11:01] <ikey> zyga, i totally get it though, ive been in similar situations, when we had to liase with green-badges at intel
[11:01] <ikey> so its not a blame game
[11:02] <ikey> just saying that those of us outside the core circle aren't always abreast of targets/goals
[11:02] <ikey> Thus in the interest of future work, that would be much appreciated and helpful
[11:03] <mvo> ikey: thanks for sharing this with us, I know it sounds cliche but it is important feedback. I personally had the feeling that we get the communication right (now that we have the forum and there is a lot of buzz there). so its good to get corrected on that view
[11:03] <zyga> right, I think we should advertise our roadmap and updates more, maybe we could start a recurring update forum post (written by everyone hacking on snapd) and collectively sent/shared every week
[11:04] <ikey> yeah i mean i dont think it needs to be overly formal, you just need to expose the pulse, if that makes sense
[11:04] <mvo> ikey: just to double check that I get this correctly - the main problem was e.g. that "theme support" was on the roadmap but no clear times/dates attached and not clear if/how much progress was happening(?)
[11:05] <mvo> (so for the things you cared about the sense of "where are we" was missing?)
[11:05] <ikey> mvo, so in a nut shell yeah, aware of items drifting on the horizon for some length of time, but we dont know where they are or when they come or whats stopping them
[11:05]  * mvo nods
[11:05] <ikey> the other important aspect for that is you provide a point for newcomers to the project who want to onboard and contribute
[11:05] <ikey> they see the blockers and have something to work on
[11:07] <ikey> wait for the cringe: virtuous cycle of growth
[11:07] <niemeyer> ikey: We did report recently about the desktop progress: https://forum.snapcraft.io/t/desktop-improvements-report-and-plans/3510
[11:07] <mvo> ikey: thats a good one too, I wonder if the forum and a pinned topic would help with that. I personally find this apsect (good newcomer tasks one of the hardest)
[11:07]  * mvo messed up the () above, clearly needs to do more lisp
[11:07] <ikey> niemeyer, if you think im going to talk to you now you're very much mistaken, you're one of the core issues with this project
[11:07] <zyga> mvo I think pinning might be the key, we have lots of discussions now (because the forum is quite successful) and it's hard to find the essential news in summarized form
[11:08] <ikey> once you correct your attitude I'll recommence communications
[11:08] <mvo> zyga: yeah, thats a good point, the front-page scrolls by super fast
[11:08] <ikey> zyga, most topics with tag would last a week in the scroll i think?
[11:08] <ikey> like you might need to click the tag first to filter
[11:08] <mvo> zyga: or maybe more categories, but not sure if that would help and now discoverable this actually is
[11:09] <zyga> I don't know the technical forum answer yet, we need to experiment and see how it looks like
[11:09] <zyga> I understand the forum page is personalised so it might need testing in a private browser session
[11:09] <ikey> oh right
[11:09] <ikey> TIL. :)
[11:09] <niemeyer> ikey: That will make collaboration a bit harder.. :)
[11:10] <ikey> pot calling the kettle black
[11:10] <ikey> Anyway, I'm gonna take my leave for now, because I really can't be in the same room as him right now.
[11:10] <ikey> Hope I've provided enough details on the report thing
[11:10] <ikey> Like I said, only removing the target for snapd *integration*
[11:10] <ikey> not snapd itself
[11:10] <ikey> Besides, I made aa-lsm-hook, not removing apparmor now :P
[11:16]  * Chipaca hugs ikey
[11:16] <Chipaca> ikey: thank you, and sorry, and … stuff
[11:16] <ikey> Chipaca, pfft dont be. you're awesome
[11:17] <Chipaca> ikey: "sorry for not being awesomer" sounds like a lame non-apology
[11:17] <ikey> lol
[11:18] <Chipaca> ikey: to be clear, thank you for speaking up and not just going off in a huff
[11:18] <Chipaca> that's hard to do and i appreciate it a lot
[11:18] <Chipaca> ikey: and sorry that you had to do so, we like to think we're better than this and need reminding every so often
[11:19] <ikey> bit hard to cross back over the river when the bridge is in flames :)
[11:19]  * Chipaca brings out the marshmallows
[11:19] <ikey> Chipaca, well i always look at these things as a way to refresh the path forward tbh
[11:20]  * Chipaca brings out the marshmallow rpg
[11:20] <ikey> like, ok now we know such and such doesn't happen now, revisit it then, and correct stuff in the meantime
[11:20] <ikey> too old and hairy now for drama
[11:22] <zyga> mborzecki can you please look at https://travis-ci.org/snapcore/snapd/builds/341366071?utm_source=github_status&utm_medium=notification
[11:22] <mborzecki> looking
[11:22] <zyga> one test failed there
[11:22] <zyga> doesn't look related to the change
[11:25] <mborzecki> hmm, w8, how does it pass on master?
[11:25] <zyga> what do you mean?
[11:27] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/4654 stops the timer in prepare
[11:27] <mup> PR #4654: tests/lib/prepare: disable snapd.refresh.timer <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4654>
[11:27] <zyga> maybe we are running tests of the branch, not of the merged result
[11:27] <zyga> (that would be an interesting find)
[11:28] <mborzecki> iirc that's what travis does by default
[11:28] <zyga> that == merged or just branch?
[11:28] <mborzecki> branch
[11:28] <mborzecki> anyways, that test was there before right?
[11:29] <zyga> yes
[11:30] <mborzecki> right, so 4654 travis job was ok, some master jobs after that PR was merged were fine too, so why does it fail now?
[11:30] <zyga> yeah, I don't know that
[11:30] <mborzecki> clearly it will file if the timer is stopped
[11:31] <mborzecki> so somehow it must be started again :/
[11:38] <zyga> + test -f /usr/share/dbus-1/services/io.snapcraft.Launcher.service
[11:38] <zyga> + diff -u /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig /usr/share/dbus-1/services/io.snapcraft.Launcher.service
[11:38] <zyga> --- /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig	2017-12-18 14:41:33.000000000 +0000
[11:38] <zyga> +++ /usr/share/dbus-1/services/io.snapcraft.Launcher.service	2018-02-13 16:57:31.000000000 +0000
[11:38] <zyga> @@ -1,3 +1,4 @@
[11:38] <zyga>  [D-BUS Service]
[11:38] <zyga>  Name=io.snapcraft.Launcher
[11:38] <zyga>  Exec=/usr/bin/snap userd
[11:38] <zyga> +AssumedAppArmorLabel=unconfined
[11:38] <zyga> -----
[11:38] <zyga> I have a feeling that our prepare restore code is buggy
[11:39] <Chipaca> mvo: tweaked the system-shutdown sync comment, see what you think
[11:39] <Chipaca> might be getting a little rambly
[11:53] <zyga> + snap install test-snapd-control-consumer
[11:53] <zyga> error: cannot install "test-snapd-control-consumer": cannot get nonce from
[11:53] <zyga>        store: store server returned status 418
[11:53] <zyga> that's the teapot, right Chipaca ?
[11:53] <Chipaca> yes
[11:54] <Chipaca> mup, what's http status 418
[11:54] <mup> Chipaca: In-com-pre-hen-si-ble-ness.
[11:54] <Chipaca> zyga: se?
[11:54] <Chipaca> zyga: see?
[11:55] <zyga> thanks
[12:03] <mvo> Chipaca: thanks, comment looks fine
[12:03] <mup> PR snapd#4662 closed: tests: removing packages which are not needed anymore to generate random data <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4662>
[12:06] <Son_Goku> [06:16:41 AM]  <Chipaca>	ikey: thank you, and sorry, and … stuff
[12:06] <Son_Goku> did I miss an emotional moment or something?
[12:06] <ikey> we hugged
[12:06] <ikey> :3
[12:06] <Chipaca> Son_Goku: ikey called us out on stuff we thought we were better at than we are
[12:07] <Son_Goku> Chipaca: I just don't bother anymore
[12:07] <Chipaca> Son_Goku: you're just wanting a hug too
[12:07]  * Chipaca hugs Son_Goku
[12:07] <Son_Goku> aww
[12:07]  * Son_Goku hugs Chipaca back
[12:07] <ikey> o wait its valentines day
[12:07] <ikey> not to make the hugs awkward or anything
[12:07] <Son_Goku> Yeerp
[12:07] <ikey> .. :D
[12:07] <Son_Goku> :D
[12:07]  * zyga would pour some vodka but then again this is IRC
[12:07] <Son_Goku> I stay the _hell_ away from your vodka
[12:08] <ikey> yeah you can only have 512 of the vodka
[12:08] <zyga> haha
[12:09] <Son_Goku> but yeah, these days, I don't really know whats going on with the features for snappy that I need to accomplish my objectives
[12:09] <Son_Goku> unlike ikey though, I don't have the time to dig into everything all the time
[12:09] <Son_Goku> so I just kinda let it go and hope something comes up to give me a better picture later
[12:09] <Son_Goku> I've barely had _any_ time to work on the RPM backend for snapcraft
[12:10] <Son_Goku> which I already know requires me to implement some functionality in DNF to make things a little less stupid
[12:11] <zyga> Son_Goku btw, offtopic. hurricanehrndz is idle for about a month (on irc), is that the right nickname?
[12:11] <Son_Goku> I think that's the right nick
[12:12] <Son_Goku> worst case, I'll probably do some work myself on the openSUSE packaging
[12:12] <mup> PR snapd#4664 closed: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4664>
[12:12] <mup> PR snapd#4666 closed: interfaces/apparmor: generalize apparmor load and unload helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4666>
[12:13] <Son_Goku> zyga, but at least from a fedora point of view, the main things I want to see is *some* effort towards a selinux backend for snap-confine
[12:13] <Son_Goku> it doesn't even have to involve code
[12:13] <Son_Goku> just at least discussions with selinux developers to figure out gaps and how to close them, if any
[12:14] <Son_Goku> and of course, a way to swap core snaps for building a modular Fedora system built on snaps
[12:14] <zyga> that 2nd thing may come out of base/core 18 work where things will force us to move snapd out of core
[12:14] <zyga> or out of the "one" nap
[12:14] <zyga> *snap
[12:15] <zyga> naming things aside
[12:15] <zyga> 1st thing is something I just don't have time to work on, I agree it is interesting and would like to see that started eventually
[12:18] <niemeyer> mborzecki: Replied in the timer conversation
[12:18] <mborzecki> niemeyer: thanks
[12:19]  * zyga switches focus to user mounts for the rest of the day
[12:19] <zyga> and takes a break to relieve back pain
[12:25]  * kalikiana going for a brief break
[12:28]  * Chipaca -> lunch
[12:39] <mup> PR snapcraft#1925 opened: elf: cache crawled files <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1925>
[12:42] <mup> PR snapcraft#1922 closed: elf: fast track when the host used matches the base <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1922>
[12:44] <pedronis> I'm getting this:  Cannot allocate linode:ubuntu-16.04-64: cannot boot linode:ubuntu-16.04-64 (Spread-5941868): missing or incomplete Linode startup profile.  Contact Linode support.
[12:53] <jdstrand> ikey: for my part, sorry steam-support dragged a bit. honestly, I didn't know it was a blocker for solus 3, but I'm going to keep working at it. also, fwiw, I thought you were saying you were dropping snapd too so glad to hear you are keeping that and apparmor :)
[13:00] <mup> PR snapd#4658 closed: many: don't allow layout construction to silently fail <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4658>
[13:36]  * kalikiana lunch
[13:58] <pedronis> mvo: let me if I can help with that issue, I also noticed that I replicated the issue in my new branch about the new api
[13:59] <mvo> pedronis: thanks, I will prepare a PR and ask you for a review (with appropriate comments)
[14:01] <mup> PR snapd#4667 opened: tests/main/ubuntu-core-services: enable snapd.refresh.timer for the test <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4667>
[14:05] <koza> pedronis, hey, quick question: assuming eth cables are plugged in and internet is available can I be sure that prepare-device hook runs after the networking connection is established or there is a race?
[14:07] <pedronis> koza: I don't know in general, prepare-device will be retried though if needed
[14:08] <koza> pedronis, i know just want to make sure if i can safely assume it runs with networking *if* is available at the time of boot and properly configured
[14:10] <mborzecki> zyga: 4667 should address the failure in tests/main/ubuntu-core-services you were seeeing
[14:15] <pedronis> koza: I don't know, that seems related to the systemd services setup,  mvo might know more about that
[14:17] <koza> pedronis, mvo, ^^ and what has to happen for prepare-device to be retried; do i remember rightly it will happen when the Initialize Device stage is failed?
[14:17] <pedronis> koza: yes,  also if prepare-device itself fails
[14:18] <koza> pedronis, got it, thanks
[14:18] <mvo> koza: we just use "WatnedBy=multi-user.target", so no gurantee other than that
[14:18] <mvo> koza: i.e. we do not have anything like after=network of network-online.target
[14:19] <koza> mvo, right, understood; but one could rely on retry and wait for net to be up in case there is a race between these two
[14:26]  * kalikiana re
[14:33] <mup> PR snapd#4668 opened: store: revert PR#4532 and do not display displayname <Created by mvo5> <https://github.com/snapcore/snapd/pull/4668>
[14:43] <mborzecki> off to pick up the kids
[15:03] <alexlarsson> zyga: when referring to snap in writing, what do i use "snap", "snappy"?
[15:05] <popey> alexlarsson: we tend not to use "snappy"  so much, snap and snapcraft are more widely used
[15:05]  * popey realises he is saying that in #snappy
[15:06] <zyga> alexlarsson hmmm
[15:06] <zyga> I try to say "snapd" because snappy is a compression format and snap typically a file
[15:07] <zyga> alexlarsson it also depends on what you are writing about, snap packages are "snap" but it is "snapd" who manages them
[15:07] <popey> (and snapcraft [generally] that makes them)
[15:07] <alexlarsson> more like refering to the project/organization/people
[15:08] <alexlarsson> "snap wants to use portals"
[15:08] <popey> "the snap developers want to use portals"
[15:08] <zyga> I would say "snapd integrates with portals" and "snap packages can use portals"
[15:08] <alexlarsson> ok, cool
[15:33] <popey> niemeyer: we have a new user on the forum who is going to post a call for testing of their snap. They will get anti-spam blocked linking to their issue tracker. Can you help?
[15:33] <popey> (I am pre-emptively asking because I know this will happen)
[15:34] <zyga> Chipaca 4669 is trivial and I think you wrote the original
[15:34] <zyga> or perhaps mvo
[15:34]  * zyga knows how to gather reviewers ;-)
[15:34] <mup> PR snapd#4669 opened: osutil: reimplement IsMounted with LoadMountInfo <Created by zyga> <https://github.com/snapcore/snapd/pull/4669>
[15:35] <Chipaca> zyga: mountSuite does the mocking of proc/mounts?
[15:35] <Chipaca> or whatever it was :-)
[15:35] <Chipaca> ah tere it is
[15:40] <zyga> re
[15:41] <zyga> Chipaca, no, there's mocking in each function
[15:42] <niemeyer> popey: Yeah, happy to help
[15:43] <niemeyer> popey: In general I tend to respond to such blocks quickly if it's during my day
[15:43] <niemeyer> popey: But please feel free to ping here or on Telegram when necessary
[15:43] <popey> niemeyer: will do
[15:44] <niemeyer> popey: I just approved a different one moments ago coincidentally, which was responding to a request for version
[15:44] <niemeyer> popey: Not sure why it triggered the anti spam.. too many pre blocks?
[15:44] <popey> Excellent. :)
[15:48] <mvo> zyga: heh
[15:52] <zyga> Chipaca, mvo: another part of the per-user mount split: https://github.com/snapcore/snapd/pull/4670
[15:52] <mup> PR #4670: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
[15:52] <zyga> trivial 34 additions PR
[15:52] <mup> PR snapd#4670 opened: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
[15:58] <mvo> zyga: in a meeting right now
[15:58]  * zyga nods
[16:01] <zyga> jdstrand quick ack on https://github.com/snapcore/snapd/pull/4670
[16:01] <mup> PR #4670: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
[16:01] <zyga> jdstrand I'll reduce the per-user branch to the most essential (hard) changes today
[16:04] <mup> PR snapd#4667 closed: tests/main/ubuntu-core-services: enable snapd.refresh.timer for the test <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4667>
[16:05] <zyga> Chipaca can you please merge master into https://github.com/snapcore/snapd/pull/4665
[16:05] <mup> PR #4665: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[16:05] <zyga> (or rebase since it's so tiny)
[16:15] <mup> Bug #1749538 opened: refresh time docs lacks the correct command <docs> <Snappy:New> <https://launchpad.net/bugs/1749538>
[16:25] <jdstrand> zyga: ack
[16:32] <mup> PR snapd#4669 closed: osutil: reimplement IsMounted with LoadMountInfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4669>
[17:05] <zyga> hmmm
[17:05] <zyga> https://travis-ci.org/snapcore/snapd/builds/341459647?utm_source=github_status&utm_medium=notification
[17:06] <zyga> It says "We couldn't find the repository snapcore/snapd"
[17:10] <mborzecki> zyga: restart the job?
[17:10] <zyga> look at that page
[17:10] <zyga> there's no link for that
[17:11] <zyga> in fact
[17:11] <zyga> it looks like all travis jobs are broken
[17:11] <zyga> cachio ^
[17:11] <zyga> man
[17:11] <zyga> this feels like a time to EOD and take a break
[17:12] <cachio> zyga, let me take a lokk
[17:12] <zyga> mvo ^ (in case you were hoping for releases)
[17:14] <kalikiana> bah. what is it with containers and networking that it works perfectly but also doesn't
[17:14] <mborzecki> zyga: refreshed now and the job page is there
[17:14] <zyga> same here
[17:14] <mborzecki> zyga: also restarted the build, seems like github failed this time :/
[17:14] <kalikiana> I guess I'll have something to investigate tomorrow morning
[17:14] <zyga> broken travis?
[17:15] <zyga> mborzecki can you look at 4670
[17:15] <zyga> it's trivial and blocks other bits
[17:20] <cachio> zyga, travis is a caos
[17:20] <zyga> caos?
[17:21] <cachio> chaos
[17:23] <zyga> cacaos :)
[17:23] <cachio> hehehe
[17:23] <cachio> zyga, I still cant run tests on linode
[17:23] <cachio> from localhost
[17:23] <zyga> no? what happens
[17:24] <zyga> I ran some this morning
[17:24] <mborzecki> tried to something here ~3pm, didn't work either
[17:24] <mborzecki> i was getting: '2018-02-14 14:59:29 Cannot allocate linode:ubuntu-core-16-64: cannot decode Linode response (status 200): json: cannot unmarshal string into Go struct field linodeServerData.PLANID of type int', a change in linode's API?
[17:24] <cachio> mborzecki, I see errors from linode
[17:25] <cachio> mborzecki, yes
[17:25] <cachio> that
[17:25] <zyga> eh :/
[17:25] <zyga> thank you for the feedback Chipaca!
[17:27] <mup> PR snapd#4665 closed: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[17:32] <mup> PR snapd#4665 opened: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[17:48] <zyga> Chipaca fixed
[17:48]  * zyga heads for some food
[17:48] <zyga> ttyl
[18:56] <mup> PR snapd#4665 closed: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[18:58] <mup> PR snapd#4671 opened: tests: adding new test to validate the raw-usb interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4671>
[19:36] <Oooohboy> hello all, I'm getting what looks to be a permissions issue when running snapcraft. "Can't drop privileges for downloading as file"
[19:37] <Oooohboy> anyone have any links or anything to general troubleshooting docs on snapcraft? This is probably user error here, but I've tried sudo and sudo -H
[19:40] <nacc> Oooohboy: you don't generallly want to be root to buildl a snap
[19:40] <nacc> Oooohboy: can you pastebin your exact command and output?
[19:43] <Oooohboy> https://pastebin.com/DnFdGfxt
[19:43] <Oooohboy> should be everything needed there I think
[19:49] <nacc> Oooohboy: do you possibly have a ppa on your system that doensn't work?
[19:49] <nacc> Oooohboy: ppa.launchpad.net_tista_adapta_ubuntu_dists_artful_
[19:51] <Oooohboy> nacc: yes
[19:52] <Oooohboy> nacc: well, I think it works...
[19:55] <nacc> Oooohboy: sorry, i'm not sure then; i'd wait till a snapcraft dev is arounnd
[19:59] <Oooohboy> nacc: thanks for looking. As this is my first snap I was sure it was something I was/am doing wrong
[20:07] <kyrofa> Oooohboy, have you tried without sudo?
[20:14] <Oooohboy> kyrofa: yeah sorry heres that paste https://pastebin.com/YRiWqasy
[20:17] <kyrofa> Oooohboy, I suspect things are owned as root now in that dir. Try blowing away the snapcraft cache in `/home/sbrady/.cache/snapcraft` and trying again (without sudo)
[20:20] <mup> PR snapd#4672 opened: tests: adding test for removable-media interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
[20:20]  * cachio afk
[20:21] <Oooohboy> kyrofa: thanks for looking...did that, same issue...apt-get update and upgrade are working fine https://pastebin.com/4stUYuGR
[20:22] <kyrofa> Oooohboy, note that stage-packages don't use `apt-get` directly
[20:22] <Oooohboy> ok
[20:23] <kyrofa> That's not actually the same error... something is segfaulting
[20:23] <kyrofa> Oooohboy, can I see the output of `snap version` please?
[20:25] <Oooohboy> https://pastebin.com/HkFZRcXR
[20:47] <mup> PR snapcraft#1924 closed: schema: update version regex <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1924>
[20:48] <kyrofa> Hmm, 17.10, I've not tried that recently
[22:07] <mup> PR snapd#4670 closed: interfaces/mount: add support for per-user mount entries <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4670>
[22:10] <mup> PR snapd#4673 opened: interfaces/mount: generate per-user mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4673>
[22:14] <zyga> jamesh, I'm chopping your user-mounts branch into pieces, I will merge master into the main branch until it reduces to an empty diff
[22:14] <zyga> this way it will get in faster as smaller pieces are easier to iterate on
[22:14] <zyga> I'm going to bed, talk you tomorrow!


[07:47] <mardy> jgdx: hi! I definitely want to merge your MP :-)
[07:51] -queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2288 Needs rebuild due to new commits (zesty/ubuntu-system-settings-online-accounts). Successfully built (xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/ubuntu-system-settings-online-accounts, zesty/ubuntu-settings-components, zesty/ubuntu-system-settings)
[09:41] <vigo> morphis, ping :)
[09:41] <morphis> vigo: pong
[09:43] <vigo> morphis, I'm reading the notes for 2333 but is not clear to me how is the best way to test it
[09:44] <vigo> should it be tested on core too?
[09:44] <morphis> you can
[09:44] <morphis> that is the primary target
[09:44] <vigo> great, amd64 I guess, right?
[09:44] <vigo> or all boards too?
[09:44] <morphis> we publish the test for all listed architecture
[09:45] <morphis> and its supported on all of them
[09:45] <morphis> vigo: we provide the canonical-se-engineering-tests snap which gives you a set of manual plainbox tests you can use to verify the snap is working well
[09:45] <vigo> morphis, cool, I'll let you know how it goes =)
[09:46] <morphis> other than that documentation exists at https://docs.google.com/document/u/1/d/1vNu3fBqpOkBkjv_Vs9NZyTv50vOEfugrQqgxD0_f0rE/edit
[09:50] <vigo> morphis, really useful thank you!
[09:52] <morphis> vigo: pulseaudio passed the test?
[09:54] <vigo> morphis, I passed it but left some notes about it on pi3 too
[09:54] <vigo> https://trello.com/c/Q9yW0n5l/3907-2327-snap-pulseaudio-morphis
[09:55] <vigo> morphis, and there's also a new bug
[09:55] <vigo> https://bugs.launchpad.net/snappy/+bug/1654585
[09:56] <morphis> koza: ^^
[09:56] <morphis> vigo: thanks
[10:18] <pete-woods> any chance of a core-dev doing a packaging ack on https://bileto.ubuntu.com/#/ticket/2345
[10:21] <Mirv> pete-woods: done!
[10:22] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2345 Publishing packages
[10:25] <pete-woods> Mirv: thanks!
[10:37] <jgdx> mardy, okay, let me know
[10:38] <mardy> jgdx: I've merged it into my branch
[10:38] <jgdx> righto
[10:40] <jgdx> mardy, i've +1'd, but I can't top approve due to things
[10:40] <jgdx> please top approve it as soon as you can
[10:41] -queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2288 Preparing packages
[10:41] <mardy> jgdx: it's already top-approved by Ken
[10:42] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2339 Needs rebuild due to new commits (zesty/cmake-extras). Successfully built (xenial/cmake-extras)
[10:43] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2339 Preparing packages
[10:47] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2345 Proposed pocket
[10:48] <jgdx> mardy, but not your revision
[10:48] <jgdx> *latest
[10:48] <jgdx> so you need to do it again
[10:51] <mardy> jgdx: how? the LP UI doesn't allow me to choose "approved" again (unless I select something else before)
[10:52] <mardy> jgdx: well, I'll click on needs review then
[10:52] <mardy> jgdx: done :-)
[10:52] <jgdx> mardy, yeah, that's the way
[10:52] <jgdx> thanks
[10:57] <koza> vigo, fyi: read your comments, looking into them
[10:58] <vigo> koza, thanks! =)
[11:01] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2339 Successfully built
[11:06] <oSoMoN> is it a known issue that with the latest image (#117) one can’t get past the language selection screen in the first boot wizard on frieza_arm64 ?
[11:07] <jibel> oSoMoN, yes it is known
[11:07] <oSoMoN> jibel, what’s the last known working image ?
[11:07] <jibel> oSoMoN, you can workaround it by downgrading dbus
[11:07] <jibel> oSoMoN, 102
[11:07] <jibel> oSoMoN, bug 1654241
[11:09] <oSoMoN> jibel, "Failed to locate image 102" :/
[11:09] <jibel> oSoMoN, argh, it must have been purged from the server
[11:10] <jibel> oSoMoN, oldest is 103 :/ http://system-image.ubuntu.com/ubuntu-touch/staging/ubuntu/frieza_arm64/
[11:11] -queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2288 Successfully built
[11:47] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2345 Release pocket
[11:54] <Mirv> workaround: don't click next
[11:54] <Mirv> who would need next buttons anyway
[11:54] <Mirv> the old image clean bites us again, I was also about to flash my frieza with 102
[12:06] <jibel> Mirv, do you know when lukasz is back?
[12:06] <jibel> Mirv, we need an image built without proposed to fix this
[12:10] <Mirv> jibel: no, I kind of didn't know he was away
[12:10] <Mirv> jibel: hmm, might be some Fri _+_ Mon public holiday while we had Fri only
[12:12] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Pending binary packages (zesty/qtbase-opensource-src-gles). Successfully built (zesty/akonadi, zesty/analitza, zesty/appmenu-qt5, zesty/calibre, zesty/ciborium, zesty/fcitx-qt5, zesty/frameworkintegration, zesty/gammaray, zesty/gcin, zesty/gsettings-qt, zesty/hime, zesty/kdeclarative, zesty/kwin, zesty/libfm-qt, zesty/libqtxdg, zesty/lxqt-qtplugin, zesty/maliit-framework, zesty/mus
[12:17] -queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2349 Preparing packages
[12:33] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Successfully built
[12:38] -queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Needs rebuild due to new commits (xenial/content-hub). Ready to build (xenial/qtbase-opensource-src-gles). Successfully built (xenial/qtbase-opensource-src, xenial/qtubuntu-print, xenial/ubuntu-printing-app)
[12:54] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Pending binary packages (zesty/qtdeclarative-opensource-src-gles). Successfully built (zesty/akonadi, zesty/analitza, zesty/appmenu-qt5, zesty/calibre, zesty/ciborium, zesty/fcitx-qt5, zesty/frameworkintegration, zesty/gammaray, zesty/gcin, zesty/gsettings-qt, zesty/hime, zesty/kdeclarative, zesty/kwin, zesty/libfm-qt, zesty/libqtxdg, zesty/lxqt-qtplugin, zesty/maliit-framework, ze
[12:54] <vigo_> morphis, hi! could you please take a look when you have time?
[12:54] <vigo_> https://pastebin.canonical.com/175340/
[13:11] -queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2349 Successfully built
[13:11] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Generating diffs
[13:16] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2272 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
[13:22] -queuebot:#ubuntu-ci-eng- boiko tiagosh, https://bileto.ubuntu.com/#/ticket/2283 Preparing packages
[13:30] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2272 Preparing packages
[13:34] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2339 Preparing packages
[13:44] <morphis> vigo_: hm, looks like the wifi-ap tests are a bit outdated
[13:45] <vigo_> morphis, is there anything on edge to update them?
[13:46] -queuebot:#ubuntu-ci-eng- boiko tiagosh, https://bileto.ubuntu.com/#/ticket/2283 Successfully built
[13:46] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Preparing packages
[13:47] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2336 Preparing packages
[13:49] <Elleo> trainguards: what do I need to do make lp:ubuntu-keyboard/vivid the target for vivid landings in bileto?
[13:49] <Elleo> to make*
[13:56] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2272 Failed to build (xenial/unity8, zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
[14:02] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2339 Successfully built
[14:03] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 QA Signoff: Approved
[14:04] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Publishing packages
[14:06] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Publish failed: Packaging diff requires ACK
[14:07] <pete-woods> hey again core-devs! more packaging ACKs in here: https://bileto.ubuntu.com/#/ticket/2344
[14:07] <pete-woods> hopefully they're all dull and trivial
[14:07] <Mirv> Elleo: have MPs that target it, nothing else
[14:08] <Elleo> Mirv: ah, okay, cool; thanks :)
[14:08] <Mirv> pete-woods: sound looks like typo/thoughtpo
[14:10] <pete-woods> Mirv: sorry, struggling to parse that sentence
[14:10] <Mirv> pete-woods: open the diff, compare to others :)
[14:10] <pete-woods> ahh, you mean indicator-sound
[14:10] <Mirv> right, sorry
[14:12]  * pete-woods struggling to see the diff
[14:12] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Successfully built
[14:13] <Mirv> pete-woods: cmake ( >= 0.10) vs cmake-extras ( >= 0.10 )
[14:14] <pete-woods> Mirv: thanks for spotting that
[14:14] <pete-woods> time to go round the loop again!
[14:14] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-app, zesty/messaging-framework). Successfully built (xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/libircclient, zesty/mfw-plugin-irc)
[14:18] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2336 Successfully built
[14:19] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 QA Signoff:
[14:19] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Preparing packages
[14:20] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (xenial/telephony-service). Needs rebuild due to new commits (zesty/telephony-service)
[14:35] -queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2350 Preparing packages
[14:35] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2272 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
[14:38] -queuebot:#ubuntu-ci-eng- gary-wzl77, https://bileto.ubuntu.com/#/ticket/2278 QA Signoff: Approved
[14:38] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Generating diffs
[14:39] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 Preparing packages
[14:40] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2272 Preparing packages
[14:44] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2254 Preparing packages
[14:45] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 vivid/ubuntu-keyboard: Failed to add changelog message
[14:46] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Pending binary packages (xenial/indicator-sound, zesty/indicator-sound). Successfully built (xenial/indicator-display, xenial/indicator-transfer, xenial/libqtdbusmock, xenial/libqtdbustest, zesty/indicator-display, zesty/indicator-transfer, zesty/libqtdbusmock, zesty/libqtdbustest)
[14:48] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2254 zesty/libdbusmenu: Failed to commit https://code.launchpad.net/~mitya57/libdbusmenu/massivedebugging-fix. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
[14:51] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 Ready to build
[14:52] -queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2350 Pending binary packages (xenial/ubuntu-ui-extras). Successfully built (zesty/ubuntu-ui-extras)
[15:06] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2254 Preparing packages
[15:07] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Successfully built
[15:10] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 Preparing packages
[15:10] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 vivid/ubuntu-keyboard: Failed to add changelog message
[15:11] <vigo> morphis, does 2333 work for you? can you properly set the Ap and connect to it?
[15:11] <morphis> vigo: yes!
[15:11] <morphis> vigo: on which board are you trying it?
[15:12] <vigo> morphis, dragonboard
[15:12] <morphis> also interesting which wifi hardware you're using
[15:12] <morphis> can you paste: journalctl --no-pager -u snap.wifi-ap.management-service
[15:12] -queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2350 Successfully built
[15:15] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 Preparing packages
[15:16] <vigo> morphis,  -u gives an error
[15:16] <vigo> $ sudo journalctl --no-pager --u
[15:16] <vigo> journalctl: option '--u' is ambiguous; possibilities: '--user' '--utc' '--update-catalog' '--user-unit' '--unit' '--until'
[15:17] <morphis> vigo: just: -u not --u
[15:17] <morphis> vigo: full command: journalctl --no-pager -u snap.wifi-ap.management-service
[15:19] <vigo> morphis, https://pastebin.canonical.com/175355/
[15:21] <morphis> vigo: looks like the driver doesn't support AP mode
[15:24] <morphis> vigo: did you try on the pi3?
[15:28] -queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2291 Preparing packages
[15:31] <vigo> morphis, is the next device I'll try
[15:31] -queuebot:#ubuntu-ci-eng- jgdx ltinkl, https://bileto.ubuntu.com/#/ticket/2329 Ready to build (xenial/ubuntu-settings-components, zesty/ubuntu-settings-components). Successfully built (xenial/ubuntu-system-settings, zesty/ubuntu-system-settings)
[15:31] <vigo> should I file  bug for it? it wrked for you on pi3 then?
[15:31] <morphis> vigo: safest is if you try pi3 and amd64
[15:31] <vigo> worked*
[15:31] <morphis> yes it does
[15:31] <vigo> morphis, cool
[15:31] <morphis> and yeah, please file a bug
[15:32] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Pending binary packages (zesty/qt3d-opensource-src-gles, zesty/qtmultimedia-opensource-src-gles). Successfully built (zesty/akonadi, zesty/analitza, zesty/appmenu-qt5, zesty/calibre, zesty/ciborium, zesty/fcitx-qt5, zesty/frameworkintegration, zesty/gammaray, zesty/gcin, zesty/gsettings-qt, zesty/hime, zesty/kdeclarative, zesty/kwin, zesty/libfm-qt, zesty/libqtxdg, zesty/lxqt-qtplu
[15:35] -queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2272 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
[15:44] <robru> Elleo: have MPs target it, and fix it's changelog to match what's currently in vivid
[15:48] <Elleo> robru: thanks
[15:48] <robru> Elleo: yw
[15:53] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Successfully built
[15:53] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 Successfully built
[15:57] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2254 Currently building (zesty/libdbusmenu). Failed to build (zesty/nux). Successfully built (zesty/compiz, zesty/unity)
[16:10] -queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2349 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/unity8)
[16:13] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 Pending binary packages
[16:15] <rvr> pete-woods: Did you rebuild silo 2344?
[16:15] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-app, zesty/messaging-framework, zesty/mfw-plugin-irc). Successfully built (xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/libircclient)
[16:16] <pete-woods> rvr: yes
[16:16] <pete-woods> it needed a packaging fix
[16:16] <rvr> pete-woods: It was already tested and approved
[16:17] <pete-woods> so we had to go round the loop again
[16:17] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2254 Failed to build (zesty/nux). Successfully built (zesty/compiz, zesty/libdbusmenu, zesty/unity)
[16:19] <pete-woods> rvr: I certainly wouldn't want to make you guys review it again for no reason
[16:20] <pete-woods> FWIW, the only change between last time and this, is a package version dependency change
[16:20] <rvr> pete-woods: Diff?
[16:21] <pete-woods> grabbing it
[16:21] <pete-woods> rvr: http://bazaar.launchpad.net/~pete-woods/indicator-sound/cmake-extras-compatibility/revision/546
[16:22] <rvr> Ok, I'll take a look later
[16:22] <pete-woods> rvr: thanks!
[16:30] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Preparing packages
[16:34] -queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2351 Successfully built
[16:34] -queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 QA Signoff: Approved
[16:38] <rvr> kenvandine: Silo 2127 approved
[16:39] <kenvandine> rvr, thx
[16:39] -queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2291 Pending binary packages (xenial/unity8). Successfully built (xenial/qmenumodel, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8-desktop-session, zesty/qmenumodel, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api, zesty/unity8, zesty/unity8-desktop-session)
[16:40] -queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Publishing packages
[16:40] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
[16:43] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 QA Signoff: Approved
[16:44] <pete-woods> Mirv: hi! do you have any time to have another look at the silo from before again? (https://bileto.ubuntu.com/#/ticket/2344)
[16:55] -queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2133 Needs rebuild due to higher version at destination (xenial/content-hub). Needs rebuild due to new commits (zesty/content-hub)
[16:56] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-framework). Pending binary packages (xenial/messaging-app, xenial/mfw-plugin-irc, zesty/messaging-app, zesty/mfw-plugin-irc). Successfully built (xenial/libircclient, xenial/messaging-framework, zesty/libircclient)
[16:58] -queuebot:#ubuntu-ci-eng- bfiller, https://bileto.ubuntu.com/#/ticket/2277 Needs rebuild due to higher version at destination
[16:59] -queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2291 Successfully built
[17:09] -queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Proposed pocket (zesty/address-book-app, zesty/camera-app, zesty/content-hub, zesty/gallery-app). Release pocket (xenial/address-book-app, xenial/camera-app, xenial/content-hub, xenial/gallery-app)
[17:10] -queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
[17:16] -queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Needs rebuild due to new commits (zesty/messaging-framework). Successfully built (xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/libircclient, zesty/messaging-app, zesty/mfw-plugin-irc)
[17:21] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build
[17:23] -queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2343 Preparing packages
[17:29] -queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Proposed pocket (zesty/content-hub). Release pocket (xenial/address-book-app, xenial/camera-app, xenial/content-hub, xenial/gallery-app, zesty/address-book-app, zesty/camera-app, zesty/gallery-app)
[17:38] -queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Failed to build (xenial/content-hub). Pending binary packages (xenial/qtubuntu-print, xenial/ubuntu-printing-app). Ready to build (xenial/qtbase-opensource-src-gles). Successfully built (xenial/qtbase-opensource-src)
[17:45] -queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2343 Pending binary packages
[17:58] -queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Failed to build (xenial/content-hub). Ready to build (xenial/qtbase-opensource-src-gles). Successfully built (xenial/qtbase-opensource-src, xenial/qtubuntu-print, xenial/ubuntu-printing-app)
[18:02] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
[18:03] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 You must add ~ci-train-bot to https://launchpad.net/~ubuntu-desktop to continue
[18:05] -queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2343 Successfully built
[18:17] <dobey> kenvandine, mterry: can either of you ack/pub 2344 please?
[18:18] <mterry> sure
[18:20] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build
[18:22] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Publishing packages
[18:31] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Generating diffs
[18:35] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 zesty/fcitx-qt5: debdiff failed: see log for details
[18:39] <dobey> mterry: thanks
[18:46] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Proposed pocket (zesty/indicator-display, zesty/indicator-sound, zesty/indicator-transfer, zesty/libqtdbusmock, zesty/libqtdbustest). Release pocket (xenial/indicator-display, xenial/indicator-sound, xenial/indicator-transfer, xenial/libqtdbusmock, xenial/libqtdbustest)
[18:54] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Successfully built
[19:01] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Currently building (xenial/empathy, zesty/empathy). Failed to build (xenial/telephony-service, zesty/telephony-service)
[19:21] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Diff missing (xenial/empathy, zesty/empathy). Failed to build (xenial/telephony-service, zesty/telephony-service)
[19:37] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Generating diffs
[19:46] -queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2344 Release pocket
[19:53] <dobey> robru: deploying a bileto change?
[19:54] <robru> dobey:  not today, no. What's wrong?
[19:54] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Pending binary packages (zesty/analitza, zesty/qtmultimedia-opensource-src, zesty/qtmultimedia-opensource-src-gles, zesty/qtsvg-opensource-src). Successfully built (zesty/akonadi, zesty/appmenu-qt5, zesty/calibre, zesty/ciborium, zesty/fcitx-qt5, zesty/frameworkintegration, zesty/gammaray, zesty/gcin, zesty/gsettings-qt, zesty/hime, zesty/kdeclarative, zesty/kwin, zesty/libfm-qt, z
[19:55] <dobey> robru: one of my tabs just went to the "-1: ERROR" page
[19:55] <dobey> robru: switching away and back and it seems ok again
[19:56] <robru> dobey: hmmmm dunno, transient network issue I guess. tabbing out and tabbing back triggers an ajax refresh
[20:03] <robru> dobey: huh, -1 apparently means that the request was aborted. not sure how that would come up, angular must be doing something funky behind the scenes.
[20:04] <dobey> robru: ah, maybe it was refreshing automatically and something went wrong behind the curtain
[20:05] <robru> dobey: yeah, could be. not sure if I should catch -1 and trigger another refresh or just ignore it...
[20:05] <dobey> robru: probably just ignore it. re-run would be bad if it just kept hitting the issue
[20:06] <dobey> ignoring and waiting at least will avoid browser eating all the CPU :)
[20:06] <robru> true
[20:09] -queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Release pocket
[20:14] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
[20:15] -queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Successfully built
[20:18] -queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Needs rebuild due to new commits (xenial/content-hub). Ready to build (xenial/qtbase-opensource-src-gles). Successfully built (xenial/qtbase-opensource-src, xenial/qtubuntu-print, xenial/ubuntu-printing-app)
[20:19] -queuebot:#ubuntu-ci-eng- bfiller, https://bileto.ubuntu.com/#/ticket/2277 Needs rebuild due to higher version at destination (xenial/gallery-app). Needs rebuild due to new commits (zesty/gallery-app)
[20:22] -queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2179 Failed to build (xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles, zesty/ubuntu-ui-toolkit, zesty/ubuntu-ui-toolkit-gles). Needs rebuild due to new commits (zesty/content-hub). Successfully built (xenial/content-hub)
[20:42] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Pending binary packages (xenial/telephony-service, zesty/telephony-service). Successfully built (xenial/empathy, zesty/empathy)
[21:01] -queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Successfully built
[22:55] <jgdx> trainguards: halp! Can you please recycle the regressions in  ubuntu-system-settings-online-accounts (xenial and zesty) in ticket https://bileto.ubuntu.com/#/ticket/2288 ?
[23:01] <tedg> Hmm, I don't think I can do that.
[23:02] <jgdx> thanks anyway
[23:03] <tedg> Sorry jgdx but your trainguard is in another castle.
[23:04]  * jgdx jumps into the toilet
[23:09] <xnox> jgdx, recycled
[23:13] <jgdx> xnox, thanks!


[00:08] <sirpengi> is there a way to fetch a branch but not pull any history?
[00:08] <bob2> --depth
[00:08] <bob2> hm, maybe it only works for clones
[00:12] <sirpengi> i don't seem to be able to find any documentation about --depth
[00:12] <bob2> oops, wrong channel, sorry =)
[00:13] <sirpengi> anyhow, I think what I'm looking for is --lightweight checkout
[00:13] <bob2> I don't think "history horizons" has been implemented yet, but the lightweight checkout plugin might be good enough
[00:13] <bob2> or you could stack
[00:14] <sirpengi> what do you mean by stack?
[00:15] <bob2> http://doc.bazaar.canonical.com/latest/en/user-guide/stacked.html
[00:17] <sirpengi> ohh, nifty
[00:18] <sirpengi> that'll involve me finding a place for the stacked branch though...
[00:18] <sirpengi> well, I'll see if the lightweight checkout works...
[00:25] <maxb> Noldorin: Funnily enough, I just needed to replace my system dulwich with a newer version
[00:25] <Noldorin> maxb: oh right?
[00:25] <Noldorin> you on linux though, i take it?
[00:26] <maxb> I came up with the idea of creating a file .bazaar/plugins/AAAusedulwich.py containing "import sys; sys.path.insert(0, '/my/path/to/dulwich')
[00:26] <maxb> Seems to work :-)
[00:26] <Noldorin> oh cool
[00:26] <Noldorin> i was thinking something along those lines too, but don't know any python, so meh
[00:27] <Noldorin> maxb: also, are you using the binary/python version of bzr?
[00:39] <maxb> I don't think that question has any meaning on Linux
[01:00] <Noldorin> maxb: heh, fair enough
[01:00] <Noldorin> maxb: i'll give that a go shortly. thanks for the tip :)]
[01:12] <Noldorin> maxb: wait. this AAAusedulwich.py file... it's just in C:\Program Files\Bazaar\plugins ?
[01:20] <maxb> I imagine that would be the relevant windows location
[01:38] <Noldorin> maxb: ah ok. what's with the AAA bit...?
[01:47] <maxb> To make it sort first
[01:55] <Noldorin> ah fair enough
[02:12] <Noldorin> maxb: i get this error now:
[02:12] <Noldorin> No module named protocol
[02:12] <Noldorin> Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins'
[02:12] <Noldorin> bzr: ERROR: exceptions.AttributeError: 'InterRepository' object has no attribute
[02:12] <Noldorin>  'fetch_objects'
[02:12] <jelmer> hi Noldorin
[02:12] <jelmer> Noldorin: did you see my reply to your bug comment?
[02:15] <Noldorin> hi jelmer
[02:15] <Noldorin> yes i did. i was just going to do a bit more testing before i replied :)
[02:16] <Noldorin> jelmer: i noticed shortly after that it seems to be a problem with dulwich
[02:21] <maxb> Noldorin: uhm, it shouldn't be loading dulwich itself as a plugin
[02:21] <maxb> if you have a C:/Program Files/Bazaar/plugins/dulwich, get rid ot it
[02:21] <maxb> *of
[02:22] <Noldorin> hmm
[02:23] <Noldorin> maxb: but i don't...
[02:23] <Noldorin> i did previously, but i deleted it then
[02:23]  * maxb is confused, then
[02:25] <Noldorin> yeah, odd...
[03:09] <Noldorin> jelmer: just update the bug report: https://bugs.launchpad.net/bzr/+bug/449507
[08:19] <andrewblack> I am prob being dense, is there a command to give a list of all files in the repository
[08:24] <chx> hi. i want to back out a revision that changed lots of stuff ... 700+ revisions ago. I have reverted to the previous revision and planning to apply the revisions since in a loop. i was thinking to do a 'dry run' check for error and if it applies flawlessly then apply otherwise record for later manual work.
[09:15] <fullermd> chx: Well, if by 'reverted' you mean 'bzr revert', it's almost certainly not doing what you think it is...
[09:15] <fullermd> chx: Sounds more like a rebase-type operation.
[09:16] <fullermd> andrewblack: You presumably mean 'in a branch', not 'in a repository'.  See "bzr ls".
[09:22] <andrewblack> cheers fullermd .  i havent quite got hang of bzr terminology
[09:27] <fullermd> andrewblack: Generally, anything you do, you do it to a branch or a working tree; you almost never do anything to a repository directly.
[09:31] <andrewblack> ok.   ls -V does what i want.  ls by itself gives unknown files too whic confused me
[12:46] <Noldorin> jelmer: hello?
[13:05] <jelmer> Noldorin, hi
[13:29] <Noldorin> hey
[13:30] <Noldorin> jelmer: i saw youre reply to the bug report...
[13:30] <Noldorin> wondering how my installation of dulwich got borked though....
[13:30] <Noldorin> if you could help me figure out how it needs to be setup on windows, that would be great.
[13:56] <jelmer> Noldorin: I've never used it on Windows I must admit
[14:14] <Noldorin> jelmer: hehe ok
[14:15] <Noldorin> jelmer: well what would you suggest i do if i were on linux?
[14:15] <Noldorin> (maybe i can translate for windows)
[14:20] <jelmer> Noldorin, I'd run "python setup.py install" in the dulwich source dir
[14:20] <jelmer> Noldorin: and copy bzr-git to ~/.bazaar/plugins/git
[14:21] <maxb> jelmer: ooi, what would you suggest for a per-user install of dulwich?
[14:22] <jelmer> maxb: I've aliased bzr to 'PYTHONPATH=$PYTHONPATH:/home/jelmer/pylib /usr/bin/bzr'
[14:23] <maxb> Ah. I've done sys.path manipulation in ~/.bazaar/plugins/AAAusedulwich.py
[14:52] <Noldorin> jelmer: sorry, lost internet conn
[14:53] <jelmer> Noldorin, did you see my reply?
[14:54] <Noldorin> jelmer: looks like using cygwin to compile puts things in the wrong place
[14:54] <Noldorin> http://pastebin.ca/1736212
[14:54] <Noldorin> Noldorin: and copy bzr-git to ~/.bazaar/plugins/git
[14:54] <Noldorin> that's the last message i got ^
[15:00] <Noldorin> jelmer: look right/wrong to you?
[15:02] <jelmer> Noldorin: So far
[15:03] <Noldorin> jelmer: don't i really want the .egg in C:\Python25\... though?
[15:03] <Noldorin> i'm still getting No module named dulwich.errors
[15:03] <Noldorin> when i dpush
[15:04] <jelmer> Noldorin: If you want the egg in c:\python25 I don't think you should be using cygwin
[15:04] <Noldorin> jelmer: yeah...i really want to run the bzr on windows in (c:\program files) to use bzr-git
[15:04] <jelmer> Noldorin: are you using bzr in cygwin?
[15:04] <Noldorin> what is the alternative?
[15:04] <Noldorin> i don't have VS 2003...
[15:04] <jelmer> Noldorin: in that case, you shouldn't be using cygwin - that's completely independent
[15:04] <Noldorin> ok
[15:05] <Noldorin> i guess i just wanted to use cygwin for the GCC compiler
[15:05] <Noldorin> hmm
[15:05] <jelmer> Noldorin: binaries generated by that C compiler won't be usable with the python in c:\python25
[15:05] <Noldorin> i sere
[15:05] <Noldorin> see*
[15:06] <Noldorin> i don't even know if c:\program files\bazaar\bzr.exe uses the python in c:\python25 though
[15:06] <Noldorin> what i really want is to install bzr-git and dulwich *for bzr.exe in program files*
[15:06] <Noldorin> i think i have succeeded with bzr-git, but not dulwich...
[15:06] <jelmer> Noldorin: bzr-git doesn't require compilation
[15:07] <Noldorin> jelmer: indeed. just pasting it into c:\program files\bazaar\plugins seems to work
[15:07] <jelmer> Noldorin: you might want to ask on the mailing list about this issue, I'm afraid I don't know enough about the bzr windows installer
[15:07] <Noldorin> hmm ok
[15:08] <Noldorin> jelmer: by the look of it, i need to use VS 2003 to compile though no?
[15:08] <jelmer> Noldorin: Yeah, I think you need to compile with the same comp[iler that was used to compile the rest of bzr
[15:08] <Noldorin> unless i can somehow get bzr-git to use the *uncompiled* (python source) of dulwich
[15:08] <Noldorin> ok
[15:08]  * Noldorin thinks it should really be looking for VS 2008 nowadays
[15:08] <jelmer> Noldorin: Yeah, you should be able to use dulwich without the extension as well
[15:09] <jelmer> Noldorin: but that'll be slower
[15:09] <Noldorin> yeah..
[15:09] <Noldorin> not the biggrest problem atm
[15:09] <Noldorin> jelmer: any idea how to tell bzr-git to use dulwich source rather than binaries?
[15:09] <Noldorin> (if possible)
[15:09] <jelmer> to do that, copy the 'dulwich' directory from the dulwich source tarball to some path that is in your python path
[15:09] <jelmer> Noldorin: if the extensions aren't there it should just not use them
[15:10] <Noldorin> right
[15:11] <Noldorin> jelmer: in this case i now get...
[15:11] <Noldorin> No module named protocol
[15:11] <Noldorin> Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins'
[15:11] <Noldorin> bzr: ERROR: exceptions.AttributeError: 'InterRepository' object has no attribute
[15:11] <Noldorin>  'fetch_objects'
[15:11] <Noldorin> dulwich relies on a module called 'protocol' perhap?
[15:13] <jelmer> Noldorin: Where is the "No such protocol" bit raised from?
[15:13] <jelmer> ~/.bzr.log should be able to tell you
[15:14] <jelmer> Noldorin: You shouldn't install dulwich in your plugins directory
[15:14] <jelmer> (that might explain the error, actually)
[15:15] <Noldorin> jelmer: oh, there's a traceback too
[15:16] <Noldorin> jelmer: it iwsn't installed in plugins. at least, i don't think so
[15:16] <Noldorin> if it is, maybe i need to uninstall it somehow...
[15:16] <jelmer> Noldorin: the error suggests otherwise, is there no C:/Program Files/Bazaar/plugins/dulwich directory?
[15:16] <Noldorin> jelmer: nope :S
[15:16] <Noldorin> http://pastebin.com/m406420d5
[15:17] <jelmer> Noldorin: See line 4, there's a plugin there
[15:18] <Noldorin> jelmer: there is a C:/Program Files/Bazaar/plugins/git dir but definitely no C:/Program Files/Bazaar/plugins/dulwich :S
[15:18] <jelmer> Noldorin, do you still get that error if you remove the git directory ?
[15:18]  * Noldorin tries
[15:19] <Noldorin> jelmer: yep
[15:19] <Noldorin> slightly different but similar:
[15:19] <Noldorin> No module named dulwich.errors
[15:19] <Noldorin> Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins'
[15:19] <Noldorin> (dulwich.errors instead of protocol now)
[15:19] <jelmer> Noldorin: Any other places on your system where you might've installed dulwich ?
[15:20] <Noldorin> jelmer: i'll do a search
[15:27] <Noldorin> jelmer: this is really weird: windows explorer shows nothing in C:\program files\bazaar\plugins, but ls does :P
[15:28] <jelmer> well, that certainly explains a lot :-)
[15:28] <Noldorin> heh yep
[15:31] <Noldorin> jelmer: 'cannot find module' error is gone now :)
[15:31] <Noldorin> now just one more...
[15:31] <Noldorin> http://pastebin.com/m4ceb1ad2
[15:34] <Noldorin> jelmer: bzr-git should be using the dulwich source under c:\libs\dulwich-0.4.0
[15:35] <Noldorin> obviously, there is another version (compiled) under c:\cygwin\lib\python2.5\site-packages ...
[15:35] <Noldorin> but that's not being used i think
[15:41] <Noldorin> ping?
[15:53] <Noldorin> hi jelmer. what's the last message of mine you got?
 now just one more..
 Noldorin, what's left?
[15:58] <Noldorin> jelmer: http://pastebin.com/m75bfdf4c
[15:59] <Noldorin> jelmer: i.e. now i *only* have the error given in https://bugs.launchpad.net/bzr-git/+bug/449507
[15:59] <Noldorin> (whereas before i had multiple errors)
[15:59] <jelmer> Noldorin: can you paste "bzr info" again for the source and target repositories?
[16:00] <jelmer> s/repositories/branches/
[16:00] <Noldorin> sure
[16:01] <Noldorin> jelmer: http://pastebin.com/m1bccdfbd
[16:01] <Noldorin> sorry, clipboard fail
[16:01] <Noldorin> try http://pastebin.com/m6f1205ca
[16:02] <Noldorin> jelmer: the second paste is correct
[16:04] <jelmer> Noldorin: I think you might need to upgrade to a rich root format before you can push
[16:04] <Noldorin> jelmer: hmm i see.
[16:04] <jelmer> Noldorin: The source branch, that is
[16:04] <Noldorin> no idea what that is/how to use it. :)\
[16:05] <jelmer> Noldorin: in the source branch, run "bzr upgrade --2a"
[16:05] <jelmer> and then try the dpush again
[16:06] <Noldorin> jelmer: could this cause any problems elsewhere?
[16:07] <jelmer> Noldorin: If you push to other branches they need to be in the 2a format (or something newer) as well
[16:07] <Noldorin> oh fair enough
[16:07] <Noldorin> well what's the newest?
[16:07] <Noldorin> i might as well upgrade to that :)
[16:09] <Noldorin> jelmer: "No new revisions to push." - i guess this means success
[16:11] <jelmer> Noldorin: 2a is the newest
[16:11] <Noldorin> ok great
[16:13] <Noldorin> jelmer: well, only issue remaining now is to push to github
[16:13] <Noldorin> i'm trying this:
[16:13] <Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+
[16:13] <Noldorin> ssh://git@github.com:Noldorin/IRC.NET.git
[16:13] <Noldorin> Permission denied (publickey).
[16:13] <Noldorin> bzr: ERROR: The remote server unexpectedly closed the connection.
[16:15] <Noldorin> i have my SSH key in pageant, so i'm not sure of the problem...
[16:16] <jelmer> Noldorin, that's not a valid URL
[16:16] <jelmer> Noldorin, you need a / rather than a : after the hostname
[16:16] <Noldorin> ah right
[16:17] <Noldorin> same error...
[16:18] <jelmer> Noldorin: what error exactly?
[16:18] <Noldorin> what i just pasted: bzr: ERROR: The remote server unexpectedly closed the connection.
[16:18] <Noldorin> erm
[16:18] <Noldorin> Permission denied (publickey).
[16:19] <jelmer> bzr-git should be using the same ssh keys that bzr itself would use
[16:19] <Noldorin> that's what i thought hrm
[16:19] <Noldorin> must be the URL wrong still?
[16:19] <jelmer> no, the URL looks ok
[16:19] <jelmer> Noldorin is your username on github?
[16:19] <Noldorin> jelmer: yes
[16:19] <Noldorin> jelmer: the project is http://github.com/Noldorin/IRC.NET
[16:20] <jelmer> Noldorin: No idea then, sorry
[16:21] <Noldorin> no worries
[16:23] <Noldorin> jelmer: maybe i need to do http://github.com/blog/180-local-github-config ?
[16:25] <jelmer> Noldorin: no, the API isn't relevant here
[16:25] <jelmer> and bzr-git doesn't use the git config
[17:04] <Noldorin> jelmer: hmm. who *should* i ask about this then?
[17:04] <Noldorin> it doesn't seem to be a git problem heh
[17:04] <jelmer> Noldorin: does pushing to e.g. launchpad work ok?
[17:04] <jelmer> does pushing using git to github work?
[17:05] <Noldorin> jelmer: yep
[17:05] <Noldorin> in both cases, no problemxs
[17:06] <jelmer> Noldorin: the other people on the general mailing list or on the bzr-windows mailing list might have aan idea
[17:06] <Noldorin> ok
[17:06] <Noldorin> it's odd tha this problem should be occuring
[17:06] <Noldorin> jelmer: i just tend to think if you, the author of the lib, doesn't know, then who does ;)
[17:06] <Noldorin> maybe i can turn on verbose to get some debugging info or such?
[17:07] <jelmer> Noldorin, I haven't written the ssh bits
[17:07] <jelmer> Noldorin: we're just calling out to the generic functionality in bzrlib for that
[17:07] <jelmer> and there's windows-specific code in bzrlib for handling ssh
[17:08] <Noldorin> jelmer: mm, fair enough
[17:08] <Noldorin> jelmer: it would be helpful to see *which* ssh key it's trying to use though
[17:08] <Noldorin> if i can somehow
[17:14] <Noldorin> jelmer: i will try #git, then maybe the mailing list. thanks for all your help :)
[17:14] <jelmer> Noldorin: does ssh'ing into that server work?
[17:15] <Noldorin> i look forward to the next release of bzr-git..
[17:15] <Noldorin> jelmer: erm...will try now
[17:18] <Noldorin> jelmer: "no supporteed auth methods available"
[17:18] <Noldorin> on putty
[17:19] <jelmer> Noldorin: looks like the keys aren't available
[17:19] <Noldorin> jelmer: well pageant is running, and i can push to bzr
[17:19] <Noldorin> launchpad*
[17:19] <jelmer> Noldorin: github doesn't seem to have them then
[17:20] <Noldorin> ah
[17:20] <Noldorin> hm
[17:20] <Noldorin> jelmer: oh, it seems i *cannot* push with normal bzr to launchpad now :S
[17:21] <fullermd> You upgraded in the middle?
[17:22] <Noldorin> fullermd: what do you mean?
[17:22] <fullermd> Since the last time you could.
[17:22] <Noldorin> upgrade the branch, yep
[17:27] <fullermd> No, upgrade bzr.
[17:28] <fullermd> Specifically, across 2.0.0, which stopped using Putty as the default ssh implementation on Windows.
[17:29] <Noldorin> fullermd: oh i see.
[17:29] <Noldorin> yes i have indeed
[17:31] <Noldorin> fullermd: so how can i tell it to use putty/pageant now?
[17:31] <Noldorin> or should i be using something else?
[17:32] <fullermd> BZR_SSH env variable (or some name like that)
[17:42] <Noldorin> fullermd: set BZR_SSH = plink for putty right?
[17:44] <fullermd> Your guess is as good as mine   8-}
[17:44] <Noldorin> fullermd: gah, i get an error 2 now :(
[17:44] <Noldorin> when pushing
[17:44] <Noldorin> bzr: ERROR: [Error 2] The system cannot find the file specified
[17:45] <jelmer> Noldorin: bzr can't find the ssh/plink executable locally I think
[17:45] <fullermd> Rule 16: If you can't solve the problem, redefine the error.
[17:45] <fullermd> My work here is done.
[17:45] <Noldorin> jelmer: i need to put c:\program files\putty in my path then?
[17:46] <Noldorin> fullermd: :P
[17:46] <Noldorin> hehe
[17:50] <Noldorin> jelmer, fullermd: http://pastebin.com/m1064404a - hmm?
[17:52] <fullermd> 'bout what it says, I reckon.
[17:52] <fullermd> You can't interact with the ssh process through bzr, so you can't agree to accept the host key.  Have to invoke it manually to do that.
[17:52] <Noldorin> fullermd: seems to be thsi problem here: https://bugs.launchpad.net/bzr/+bug/237297
[17:52] <Noldorin> but i don't understand the solution
[17:53] <fullermd> Use plink to manually connect to LP, so you ahve to chance to accept the key.
[18:01] <Noldorin> fullermd: meh, seems i should really be using paramiko now
[18:01] <Noldorin> installed it, but i see no info how to configure it for my key :S
[18:01] <Noldorin> documentation is somewhat lacking there it seems
[18:05] <Noldorin> bah
[18:05] <Noldorin> putty was so much easier to use
[18:08]  * fullermd finds openssh nice and easy to use   :p
[18:08] <Noldorin> fullermd: yeah, it's all good on linux, but windows is a different story :P
[18:09] <Noldorin> fullermd: if you can point me to a guide for paramiko on windows, that would be good heh
[18:09] <luks> Noldorin: how did you use your key with putty?
[18:09] <Noldorin> luks: just ran pageant and added the PPK file
[18:09] <luks> the same will work for paramiko
[18:09] <luks> it will use the key from pageant
[18:09] <Noldorin> doesn't seem to :(
[18:11] <Noldorin> luks: Permission denied (publickey).
[18:12] <luks> I'm afraid I can't help with finding the problem, but it's supposed to work
[18:12] <luks> (I know, because I submitted a patch for bzr a long time ago to enable it)
[18:13] <Noldorin> ah right
[18:13] <Noldorin> hrm
[18:15] <Noldorin> luks: who might be able to suggest a solution then?
[18:16] <fullermd> jam might be a good bet.  He may be back around tomorrow.
[18:16] <Noldorin> ok
[18:16] <Noldorin> thanks anyway
[18:23] <luks> Noldorin: check your .bzr.log
[18:23] <luks> it should say that it's using paramiko, and then list all available keys in messages like "Trying SSH agent key ..."
[18:24] <Noldorin> luks: hrm
[18:24] <Noldorin> 3.000  ssh implementation is OpenSSH
[18:24] <Noldorin> could be the problem :P
[18:24] <luks> :)
[18:24] <Noldorin> i thought it default to paramiko though, no?
[18:24] <luks> I don't know
[18:24] <luks> BZR_SSH=paramiko should fix it
[18:24] <Noldorin> yep, just doing that now
[18:27] <Noldorin> luks: success. thanks very much
[18:27] <luks> I just noticed that you mentioned you were using cygwin
[18:27] <luks> adding the key to your cygwin's ssh config would be another solution
[18:28] <Noldorin> luks: was just using cygwin to compile stuff
[18:28] <Noldorin> normally on native windows though
[18:28] <luks> is it not in %PATH%?
[18:28] <Noldorin> it is
[18:28] <luks> it obviously tried *some* openssh ssh client
[18:28] <Noldorin> mm
[18:33] <Noldorin> ok, so it's just github not recognising my ssh key now...
[18:35] <Noldorin> bah
[18:40] <saedelaere> hi, when i do [bzr info] i see among other things
[18:40] <saedelaere> "Repository branch (format: unnamed)"
[18:41] <saedelaere> what does "format: unnamed" mean, and is this ok?
[18:41] <fullermd> Yes, it's fine.
[18:41] <fullermd> It means bzr doesn't have a rollup name for what you have there.
[18:42] <saedelaere> hm, ok. because the original branch on my computer shows
[18:42] <saedelaere> "Standalone tree (format: pack-0.92)"
[18:43] <fullermd> If you branch that standalone with a current bzr, you'll still have that repo format, and (I think) that branch format, but you'll have the new WT format.  Thus, unnamed.
[18:44] <maxb> Use bzr info -v for individual format information on repo, branch and WT
[18:45] <maxb> 'unnamed' is dramatically unhelpful, I wish it said something like 'pack-0.92+wt6'
[18:46] <Noldorin> hrm, i still seem to be having the wrong URL format for bzr-git:
[18:46] <Noldorin><EMAIL_ADDRESS>[18:46] <saedelaere> ok, thank you very much.
[18:50] <fullermd> maxb: Well, but it would actually be pack-0.92-wt4+wt6 or something.  Falls over soon's you wander off the beam.
[18:56] <maxb> huh?
[18:56] <maxb> It can't be wt4 and wt6 simultaneously
[18:56] <fullermd> Thus my point   :p
[19:00] <maxb> um?
[19:00] <maxb> By pack-0.92+wt6 I mean pack-0.92 modified by the wt version being replaced by 6
[19:01] <fullermd> Sure, but + doesn't mean modify, it means add.  So you have to subtract wt4 before you can add wt6.
[19:02] <maxb> I am less strictly algebraic
[19:04] <Peng> Bazaar doesn't track that it used to be WT4.
[19:04] <Peng> Best you can do is a heuristic.
[19:09] <lifeless> fullermd: that sounds confusing
[19:09] <fullermd> That would be the meta-point...
[19:10] <lifeless> fullermd: as each slot can only be filled once I don't see why you'd need a - operator
[19:10] <fullermd> Whole point of a rollup name is to avoid combinatorics.  Adding combinatorics to the rollup kinda squirrels up the idea.
[19:23] <lifeless> fullermd: that I don't agree with
[19:24] <maxb> IMO, anything less vague than 'unnamed' is an improvement
[19:30] <Peng> That reminds me, someone should file a bug about it saying "format: unnamed" for remote branches...
[19:31] <lifeless> Peng: no, someone should fix it :P
[19:32] <Peng> Yes, but if that someone is me, the former is much more likely than the latter. :P
[19:38] <maxb> Didn't someone say it was fixed in bzr.dev?
[19:40] <fullermd> Not exactly.
[19:40] <fullermd> It reads the real format names over the smart protocol now.
[19:40] <Peng> maxb: The detailed information is useful now (e.g. "branch: Remote: Branch format 7"), but the summary is not.
[19:41] <fullermd> But since it never reads WT's remotely, it doesn't get that format, so there's never a matching rollup name.
[19:41] <maxb> ah
[19:41] <Peng> Oh.
[19:57] <lifeless> fullermd: huh, its not about reading WT's remotely.
[19:57] <lifeless> fullermd: its just info being borked.
[19:58] <fullermd> Howzat?  There's no defined rollup format name without a WT format, is there?
[19:58] <fullermd> So how would you expect to ever get anything but 'unnamed'?
[20:05] <lifeless> fullermd: try it locally
[20:16] <fullermd> Try it remotely locally?
[20:21] <lifeless> try it locally locally
[20:21] <lifeless> bzr init; bzr remove-tree; bzr info
[20:29] <fullermd> Bah.
[20:36] <lifeless> fullermd: do you see ?
[20:39] <Peng> init --no-tree still isn't supported?
[20:39] <Peng> Heh, thought that'd been changed.
[21:31] <Noldorin> hi jelmer
[22:16] <jelmer> Noldorin: hi
[22:36] <Noldorin> jelmer: not sure if you got the messages, but i think aLmost evrything is sorted now...
[22:36] <Noldorin> everything, except it's regusing my ssh key it seems.
[22:36] <jelmer> Noldorin, cool
[22:37] <Noldorin> what's the URL meant to be for github repos?
[22:37] <Noldorin> i'm currently using<EMAIL_ADDRESS>[22:37] <Noldorin> erm
[22:37] <Noldorin><EMAIL_ADDRESS>[22:37] <Noldorin> but if wonder if this is wrong
[22:42] <jelmer> that seems right
[22:42] <jelmer> I'm using something similar to push to github
[22:43] <Noldorin> jelmer: i've set things up to use paramiko with pageant....
[22:43] <Noldorin> perhap's it's not communicating right?
[22:43] <Noldorin> hmm ok
[22:43] <Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+
[22:43] <Noldorin><EMAIL_ADDRESS>[22:43] <Noldorin> Permission denied (publickey).
[22:43] <Noldorin> bzr: ERROR: The remote server unexpectedly closed the connection.
[22:45] <jelmer> Noldorin, did you manage to get pushing to launchpad working again?
[22:52] <spiv> Good morning


[07:40] <roo^y> mozzwald: you may know this already, the usually bustling "traffic" that this channel once was is at a stand-still. You may have to join telegram, where all the action is, now that it seems to be disconnected from this channel
[12:57] <calamity> hey can I run ubuntu touch on virtual box?