[09:05] <ubotu> New bug: #144011 in xserver-xorg-video-ati (main) "GUTSY. No video output firing up X." [Undecided,Incomplete]  https://launchpad.net/bugs/144011
[09:06] <ubotu> New bug: #145097 in xorg (main) "Live session directly go to black screen" [Undecided,New]  https://launchpad.net/bugs/145097
[11:10] <ubotu> New bug: #145128 in xorg (main) "LiveCD No intel video" [Undecided,New]  https://launchpad.net/bugs/145128
[02:11] <ubotu> New bug: #145186 in xorg (main) "mouse pointer disappears when using external display" [Undecided,New]  https://launchpad.net/bugs/145186
[02:40] <ubotu> New bug: #145198 in xserver-xorg-video-ati (main) "[gutsy] [9700]  analog output on DVI-I broken" [Undecided,New]  https://launchpad.net/bugs/145198
[04:02] <Q-FUNK> seb128: exactly how did you reach the conclusion that the broken gtkprint was caused by libcups?
[04:04] <seb128> Q-FUNK: what is the bug number? the backtrace calls are in libcups if I remember correctly
[04:05] <ubotu> New bug: #145211 in xorg (main) "OS won't shutdown after certain video usage; memory corruption?" [Undecided,New]  https://launchpad.net/bugs/145211
[04:06] <Q-FUNK> bug #135832
[04:06] <ubotu> Launchpad bug 135832 in cupsys "evince: libgtkprint support is broken" [Low,New]  https://launchpad.net/bugs/135832
[04:10] <seb128> #1  0xb71b5478 in connect () from /lib/tls/i686/cmov/libc.so.6
[04:10] <seb128> #2  0xb476513c in httpAddrConnect () from /usr/lib/libcups.so.2
[04:10] <seb128> #3  0xb47639e6 in httpReconnect () from /usr/lib/libcups.so.2
[04:10] <seb128> ^
[04:10] <seb128> that looks like it's hanging while connecting to cups
[04:10] <seb128> and it's a hang in libcups
[04:10] <seb128> maybe you have a firewall blocking it or something
[04:11] <Q-FUNK> definitely not
[04:11] <seb128> ok, so maybe the cupsys config is broken
[04:11] <seb128> or libcups has a bug
[04:11] <seb128> or you have a network issue
[04:11] <seb128> I'm not sure, and I don't know cups enough to figure
[04:11] <Q-FUNK> besides, gtkprint is the only thing that fails. gnomeprint, OOo, firefox, all work.
[04:12] <Q-FUNK> so that tells me that cupslib works fine, given how apps that directly access it and gnomeprint both work.
[04:12] <seb128> does it happen in other applications use gtkprint? yelp, epiphany, gtk-demo
[04:13] <Q-FUNK> I can try yelp.  just a sec.
[04:14] <Q-FUNK> yelp also buggers.
[04:14] <Q-FUNK> same symptoms
[04:15] <seb128> k, so it looks like gtkprint, libcups, cupsys issue
[04:15] <seb128> having a backtrace with dbgsym package for those would be useful
[04:16] <Q-FUNK> gtkprint, definitely.
[04:17] <seb128> how do you know?
[04:17] <seb128> the backtrace indicates it's hanging in a connect made by libgnomecups
[04:17] <seb128> libcups rather
[04:17] <Q-FUNK> and yet gnomeprint doesn't hang during connect.  it just works.
[04:18] <seb128> do you know it's internel?
[04:18] <seb128> does it uses the same libcups functions than gtkprint?
[04:18] <seb128> that's not because some part of libcups is not buggy that there is no bug
[04:21] <Q-FUNK> well, that's rich.
[04:47] <seb128> re
[04:48] <seb128> Q-FUNK: you know, trying to change bug setting over a maintainer is not the way to get it resolved
[04:48] <Q-FUNK> seb128:  neither is changing it without justification.
[04:49] <seb128> Q-FUNK: I told you my justification
[04:49] <seb128> the stacktrace indicates it's blocked on a libcups listen
[04:49] <Q-FUNK> "looks like a libcupsys bug. reassigning." that's not a justification.
[04:50] <seb128> Q-FUNK: I gave you details on this chan
[04:50] <seb128> looks at http://launchpadlibrarian.net/9211483/gdb-evince.txt
[04:50] <seb128> connect, httpAddrConnect, httpReconnect, httpConnectEncrypt
[04:51] <seb128> it's clearly hanging on a call from libcups
[04:51] <seb128> why do you think it's a GTK bug?
[04:51] <seb128> might be a httpConnectEncrypt() libcups bug, which is something libgnomeprint maybe doesn't use
[04:51] <Q-FUNK> you'd need to write that in the bug as a justification, for this to be usefull to pitti or anyone else. then they can decide for themselves if they agree with your assessment.  right now, the one-liner your wrote is useless as an explanation.
[04:52] <seb128> I explain it to you on this chan
[04:52] <Q-FUNK> that could be.
[04:52] <seb128> you could have asked that instead of just reassigning
[04:52] <Q-FUNK> I already asked.
[04:52] <Q-FUNK> you had already reassigned
[04:52] <seb128> from now I'll just ignore this bug since you don't want to work in the right way
[04:52] <Q-FUNK> you thus didn't get copy of the question.
[04:54] <Q-FUNK> seb128:  reassigning the bug with such a laconic justification helps nobody, so please work in the right way and provide details for that sort of action.
[04:54] <Q-FUNK> on the bug, where it belongs.
[04:55] <seb128> it was assigned to evince which was clearly wrong
[04:55] <seb128> I reassigned to libcups what is the most likely place according to the backtrace
[04:55] <seb128> what about letting the maintainer make calls?
[04:55] <seb128> bug tracker should not allow users to change settings over maintainers
[04:56] <seb128> anyway could you get a debug backtrace?
[04:56] <Q-FUNK> nothing more than what I already attached to the bug.
[04:57] <seb128> libcupsys2-dbgsym libc6-dbg libgtk2.0-0-dbgsym are installed?
[04:57] <seb128> http://launchpadlibrarian.net/9211483/gdb-evince.txt has no debug functions
[05:01] <ubotu> New bug: #145244 in xft (main) "[gutsy]  libXft library - undefined symbol FT_Library_SetLcdFilter" [Undecided,New]  https://launchpad.net/bugs/145244
[05:58] <bryce_> tepsipakki: on bug 136783, what do you think of forcing TV off in dexconf?  Is there a better way we can address this?
[05:58] <ubotu> Launchpad bug 136783 in xserver-xorg-video-intel "not using whole widescreen" [High,Triaged]  https://launchpad.net/bugs/136783
[06:28] <Q-FUNK> /querry bryce_ ah :)
[06:28] <Q-FUNK> ...
[06:28] <bryce_> hi Q-FUNK
[06:29] <Q-FUNK> bryce_: did the strace that Scott provide made any sense to oyu?
[06:35] <bryce_> bug#?
[06:37] <Q-FUNK> bug #140051
[06:37] <ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [Medium,Confirmed]  https://launchpad.net/bugs/140051
[06:41] <ubotu> New bug: #145276 in xorg (main) "xorg.conf multiple monitor failure" [Undecided,New]  https://launchpad.net/bugs/145276
[06:56] <ubotu> New bug: #145283 in kde-guidance (main) "[gutsy]  When Driver in xorg.conf is set to  "openchrome"  X fails to start. Changing it manually to "via" works." [Undecided,New]  https://launchpad.net/bugs/145283
[07:10] <bryce_> Q-FUNK: interesting
[07:13] <bryce_> Q-FUNK: it looks like its segfaulting while trying to load vgafb
[07:13] <bryce_> er, s/vgafb/vgahw/
[07:21] <bryce_> Q-FUNK, ok left my interpretation of the strace.  I have no idea what's going on, but hopefully that should give you some new stuff to test
[07:44] <tepsipakki> bryce_: well, that's one option.. but maybe first ask upstream?
[07:51] <bryce_> tepsipakki: who would be best to ask?
[07:54] <tormod> hi, I am building new ati drivers in PPA now, with the post-194 git commit.
[07:55] <bryce_> tepsipakki: also see discussion on #ubuntu-desktop about -ati's xrandr and multi-screening
[07:55] <bryce_> I sense that glatzor would favor sticking with -ati 6.6.3 since displayconfig-gtk does not support xrandr yet
[07:56] <tepsipakki> uh
[07:56] <tepsipakki> ok
[07:57] <tepsipakki> that's better than skip dualhead with intel&ati?
[07:57] <tepsipakki> in displayconfig-gtk
[07:57] <jcristau_> &nv
[07:58] <tepsipakki> right
[07:58] <tepsipakki> well, dunno
[08:00] <tormod> stick with 6.6.3? omg we have to reopen many a bug then. like my favorite 22985...
[08:00] <tepsipakki> i'll check the discussion soon
[08:02] <tormod> hmm #ubuntu-desktop is not logged
[08:43] <tepsipakki> hmm, the reason why xresprobe fails for so many is probably that laptop-detect fails
[08:45] <bryce_> that's what I'm wondering
[08:46] <tepsipakki> it's easy to check..
[08:46] <tepsipakki> ask the reporters to run that
[09:06] <tormod> laptop-detect fails? again?
[09:07] <tormod> last time it failed during casper, but would work in installed, which was quite confusing. (#40503)
[09:09] <tormod> and I remember initial resolution detection would also fail. bug # anyone?
[09:13] <bryce_> bug 127008
[09:13] <ubotu> Launchpad bug 127008 in xresprobe "Alternate install of Tribe-4 corrupts video display when installing packages (affected hardware includes Santa Rosa)" [High,In progress]  https://launchpad.net/bugs/127008
[09:20] <bryce_> tormod: btw, when you start a discussion with a user, and esp. after asking a question, could you set the state of the bug from New to Incomplete (or Confirmed)?
[09:20] <tormod> bryce_: ok, I do it sometimes :)
[09:21] <bryce_> tormod: this'll help the bug triagers a lot
[09:21] <tormod> sure. It's just that I then feel compelled to assign it to myself, which I sometimes don't want to.
[09:21] <bryce_> like bug 145097, can probably be set to incomplete
[09:21] <ubotu> Launchpad bug 145097 in xorg "Live session directly go to black screen" [Undecided,New]  https://launchpad.net/bugs/145097
[09:22] <tormod> in that bug I am not at all sure I am on the right track, would be nice if someone else takes a look.
[09:23] <bryce_> tormod, brian murray says the incomplete state should always be set when someone has at least taken a preliminary look, even if it's not clear what's going on
[09:23] <tormod> ok, will do that every time then.
[09:24] <bryce_> cool thanks
[09:24] <bryce_> yeah I looked at this one too, and it seemed odd
[09:24] <bryce_> I wonder if it really is the screensaver coming on
[09:24] <bryce_> it sounds very familiar; I think I ran into something similar once
[09:25] <bryce_> however there the issue was that the clock got reset, so the screensaver *thought* a lot of time had passed and came on
[09:25] <bryce_> doesn't sound like this is happening here
[09:28] <tormod> yes I saw that earlier when coming back from hibernation, but that's fixed (I think).
[09:29] <tormod> if he could change the screensaver and then restart X we would see. But at this point I am not sure he and I understand each other.
[09:31] <tormod> screensaver on/off is that logged somewhere? I guess not.
[09:34] <bryce_> I don't think it's logged, but it could be tested for using 'xset q'
[09:35] <bryce_> so something like xset q | grep -A 2 "Standby:" could be useful
[09:36] <bryce_> if those values are not 0, then it means a screensaver may be active
[09:36] <tormod> you mean the built-in xorg screensaver, ok
[09:38] <tormod> I built an ati driver with verbose dpms messages, I could get him to try that. However, the blanking doesn't call dpms functions I guess, only when it's time to shut off the screen.
[09:43] <tormod> btw the new ati packages (with more "mode" fixes) are done building in my ppa
[09:43] <bryce_> awesome
[09:49] <bryce_> Brice Goglin mentioned the multi-board multi-head bug on the xorg list (ATI + MGA)
[10:05] <bdmurray> Looking at an Xorg.0.log I saw "(--) Chipset ATI Radeon XPRESS 200M 5A62 (PCIE) found" is 5A62 the product part of the pci id?
[10:10] <bryce_> I think almost certainly
[10:10] <bryce_> I notice ATI Radeon XPRESS 200M 5955 (PCIE) has pciid 1002:5955, so expect 5A62 would be similarly so
[10:11] <bdmurray> I'm pretty sure too and was trying to figure out if lspci wasn't always necessary.
[10:12] <bdmurray> I understand that ideally we would like it but instead of bothering a reporter for the umpteenth time.
[10:19] <bryce_> it's extremely rare that the device name would include the pciid like in this case
[10:22] <bdmurray> That is the device name?
[10:24] <bdmurray> Okay, I see now.
[10:24] <tormod> there are probably so many versions of 200M they had to put in a unique ID
[10:25] <bdmurray> It seems ATI specific my laptops just says "Chipset 945GM found"
[10:45] <bryce_> bbiab
[10:46] <tormod> bryce_: I suggest making a Gutsy/Xrandr page and link to it from the release notes. Otherwise it will be too much with links and workarounds.
[11:31] <tormod> good night


[11:11] <ricotz> mlankhorst, hi, copying wine1.7 builds from saucy to trusty isnt easily working anymore while libtiff4 is gone
[11:12] <mlankhorst> oh :/
[11:12] <mlankhorst> hm
[11:12]  * mlankhorst copies libtiff4
[11:13] <mlankhorst> would that cause anything unexpected to happen?
[11:14] <ricotz> it might work, but i would prefer proper builds for every pocket rather than binary copies ;)
[11:14] <mlankhorst> meh but I'm lazy
[11:14] <ricotz> with a nice versioning
[11:15] <ricotz> i see ;)
[11:16] <mlankhorst> fine I'll look
[11:18] <ricotz> thanks
[11:21] <mlankhorst> ok updated my scripts


[07:28] <didrocks> ogra_: hey! when you have some time, do you mind answering on http://askubuntu.com/questions/741088/qemu-snappy-15-04-how-to-tune-sysctl-conf ?
[07:28] <didrocks> ogra_: and please poke me, I'm interested in the answer as well :)
[07:54] <dholbach> good morning
[08:08] <didrocks> good morning dholbach
[08:08] <dholbach> salut didrocks
[08:30] <zyga> good morning
[08:38] <noizer> good morning
[08:42] <didrocks> mvo: hey, it seems that even if we branch snapcraftv1, we can't build anymore 15.04 snaps on xenial.
[08:42] <didrocks> mvo: Snapping /
[08:42] <didrocks> open /home/didrocks/work/ubuntu-core/demos/youtube-streamer/snap/meta/snap.yaml: no such file or directory
[08:42] <didrocks> I guess the issue is the new metadata snappy files
[08:42] <didrocks> and so snappy snap doesn't know it's some 15.04 snaps and look for this
[08:44] <didrocks> (I did downgrade snappy for now)
[08:46] <mvo> didrocks: yeah, snappy is unfortunately not able to do 15.04 stuff in xenial
[08:46] <mvo> didrocks: if that is important we could introduce a snappy-15.04 package, but then 16.04 is going to be released in some weeks so not sure about it
[08:47] <didrocks> mvo: I agree, but it seems that a lot of people have (unfortunately) interests in 15.04. I guess if we tell them to use < 16.04 for now, it's ok, but still something to keep in mind in case people starts complaining
[09:02] <noizer> Hi I played some with the REST API but i got an error with this call.
[09:02] <noizer> http://pastebin.com/e4yVQTKj
[09:04] <zyga> noizer: which version of snappy did you use?
[09:04] <zyga> noizer: can you run "snap interfaces"
[09:05] <noizer> 16.04
[09:05] <noizer> zyga
[09:05] <zyga> noizer: and FYI: https://github.com/ubuntu-core/snappy/pull/559
[09:06] <zyga> mvo: thank you!
[09:07] <noizer> ok but i got it for other different calls like /2.0/snaps/nameOfSnap/services
[09:07] <zyga> noizer: you might have to authenticate
[09:07] <zyga> noizer: or run as root
[09:08] <noizer> hmmm ok i will check it first out
[09:08] <zyga> noizer: look at the rest.md file
[09:08] <zyga> noizer: it says what each of the method requires
[09:08] <zyga> noizer: including authentication
[09:08] <zyga> noizer: currently if you connect as root over the local socket then we trust you and you can touch any of the bits exposed
[09:09] <noizer> zyga: but with the /2.0/snaps there needed to be authentication too but it works right out the box
[09:09] <zyga> noizer: maybe your image still has /2.0/skills
[09:10] <zyga> noizer: I'd recommend using my devtools scripts to run latest master on your image
[09:10] <noizer> maybe
[09:10] <zyga> noizer: try the get with /2.0/skills
[09:10] <zyga> if that works you have older snappy in your image
[09:11] <noizer> zyga: I will build a new image
[09:12] <noizer> zyga when was the last update
[09:12] <noizer> zyga because I build it before with you previous monday (22/02/16)
[09:14] <zyga> noizer: you don't have to build a new image
[09:14] <zyga> noizer: that won't change anything
[09:14] <zyga> noizer: images auto-update if there are new releases
[09:14] <zyga> noizer: I'd suggest injecting new snappy into your existing image
[09:14] <zyga> noizer: my devtools scripts do exactly that
[09:18] <noizer> zyga: oooh ok i will have a  look at it how i need to do it
[09:27] <noizer> zyga can you push me fast around how it works again you devtools
[09:27] <zyga> noizer: sure, clone it somewhere
[09:27] <zyga> noizer: make sure you can run the kvm image or you have a device around
[09:28] <zyga> noizer: make sure you can ssh to your device under the names listed in the readme file (e.g. ssh snappy-pi2)
[09:28] <zyga> noizer: then run ./refresh-bits --pi2 setup snap snapd snappy run-snapd
[09:28] <zyga> noizer: and read the script, it's very simple
[09:29] <noizer> I don't need to do some things with go?
[09:29] <zyga> mvo: I've added sorting tests, the test for Interfaces() is in a subsequent branch, do you want me to cherry pick it in or can it land separetely?
[09:29] <zyga> noizer: sure, you have to be able to build the snappy tree, that's covererd by README.md in the snappy repo
[09:34]  * zyga needs a bigger switch
[09:35] <mvo> dpm: a new os snap is now in rolling/edge so you may need to update your example app
[09:37] <dpm> mvo, thanks! so I need to 'snappy update ubuntu-core' as well I guess?
[09:41] <mvo> dpm: yeah, its in edge right now, I promote to stable in a bit
[09:42] <dpm> ok, I just wanted to see if I did it right, as I caouldn't see any update yet
[09:43] <noizer> Zyga building !!!! niceee
[09:44] <zyga> noizer: cool,
[09:44] <zyga> noizer: patches are welcome, if you can improve the devtools or documentation around them
[09:45] <noizer> zyga: I will think about it and let you know
[09:49] <dpm> mvo, looks about right? http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/revision/282
[09:51] <noizer> zyga: strange its just like you script is blocking
[09:52] <mvo> dpm: yes
[09:53] <dpm> great, thanks
[09:57] <zyga> noizer: it is blocking
[09:57] <zyga> noizer: the run-snapd subcommand blocks
[09:57] <zyga> noizer: and you can see what snapd says if it says something interesting
[09:57] <zyga> noizer: you can ctrl-c it to stop snapd
[09:57] <zyga> noizer: if it's blocking for other reason it's probably misconfigured ssh on your side
[10:01] <zyga> mvo: follow up with more tests https://github.com/ubuntu-core/snappy/pull/571/files
[10:04] <noizer> ubuntu
[10:06] <noizer> zyga here its blocking :s http://pastebin.com/aBafF3RW
[10:11] <zyga> noizer: it's doing exactly what I said it does
[10:11] <zyga> noizer: it's running snapd
[10:11] <zyga> noizer: that's _expected_
[10:11] <zyga> noizer: you can now ssh into your board and run ./snap
[10:11] <noizer> so its done?
[10:11] <zyga> noizer: no
[10:11] <zyga> noizer: it's not done, it's _running_ snapd in the foreground for you to see
[10:12] <zyga> + ssh snappy-pi2 sudo /lib/systemd/systemd-activate -l /run/snapd.socket ./snapd
[10:12] <zyga><EMAIL_ADDRESS>password:
[10:12] <zyga> Listening on /run/snapd.socket as 3.
[10:12] <zyga> noizer: keep that session around, use another session to play with snappy
[10:12] <noizer> this needs then open all the time?
[10:13] <zyga> noizer: yes
[10:13] <zyga> noizer: this is a development tool
[10:13] <zyga> noizer: it's not something you'd run for any production need
[10:14] <noizer> oooh ok :D
[10:16] <noizer> And now i can make some REST Calls to the new API
[10:18] <zyga> noizer: great!
[10:18] <noizer> zyga I think so
[10:18] <noizer> zyga im trying right know
[10:20] <noizer> zyga  unix connect failed: Permission denied
[10:21] <noizer> nc: unix connect failed: Permission denied
[10:21] <noizer> wasn't complete
[10:28] <noizer> zyga: I can't make any calls to the socket right now
[10:30] <zyga> noizer: is the daemon running?
[10:30] <zyga> noizer: ah, just chmod the socket
[10:30] <zyga> noizer: or run as root
[10:30] <zyga> noizer: systemd-activate makes a socket with restrictive permissions by default
[10:30] <zyga> noizer: that's just a side effect of devtools
[10:35] <noizer> I think its works now
[10:35] <noizer> zyga
[10:38] <zyga> mvo: FYI https://github.com/ubuntu-core/snappy/pull/548#discussion-diff-54862218
[10:38] <zyga> mvo: otherwise yes, LGTM
[11:06] <popey> mvo: is it possible to switch (for example my pi 2) to edge/rolling? So I get latest crack? (I also have a stable pi 2)
[11:10] <mvo> popey: only with a tiny bit of hackery, something like "for f in /var/lib/snappy/meta/*; do sed -i 's/channel: stable/channel: edge/g' $f; done
[11:10] <mvo> popey: Chipaca is working on channel switching from the commandline
[11:10] <popey> ah
[11:10] <mvo> popey: will land soon but not there yet
[11:10] <popey> okay, thanks!
[11:10] <mvo> yw
[11:47] <ogra_> zzarr, (continuing from the other channel) ... i doubt you will make X11 work on snappy unless you drop all security (which in turn will make it un-upgradeable)
[11:48] <ogra_> Mir will work at some point but we are still a bit away from graphical drivers and such on the dragonboard specifically
[11:49] <zzarr> would Mir be sw accelerated, or not work at all?
[11:50] <ogra_> no idea, i'm still working on the basics of the image, i can tell you once i tried the driver ... really depends what state the freedreno driver is in
[11:54] <zzarr> thanks ogra_, I'll begin with a Linaro image
[12:24] <kyrofa> Good morning
[12:32] <didrocks> ogra_: hey, have you seen my askubuntu link?
[12:32] <didrocks> hey kyrofa!
[12:32] <kyrofa> Hey didrocks!
[12:32] <olli_> m
[12:37] <ogra_> didrocks, answered now
[12:43] <didrocks> ogra_: thx!
[12:44] <zyga> mvo: quick question, on reboot, when the system is brought back to life, is there something that takes existing apparmor profiles, compiles them and inserts them into the kernel?
[12:44] <zyga> mvo: it seems that there is something like that as my demos work after rebooting but I cannot find anything like that
[12:45] <ogra_> zyga, s/inserts them into the kernel/rebuilds the cache/
[12:46] <ogra_> it is like on the phone :)
[12:47] <zyga> ogra_: hmm, not sure what "rebuilds the cache" means
[12:48] <zyga> ogra_: apparmor_parser --reload /path/to/profile parsers, compiles and inserts the profile into the kernel
[12:48] <zyga> ogra_: is that what you meant?
[12:51] <kyrofa> enoch85, ping
[12:53] <ogra_> zyga, qwll, i always thought it reads the binary profile from disk ... but yeah, thats what i mean
[12:53] <ogra_> *well
[12:54] <zyga> ogra_: so what does that?
[12:54] <zyga> ogra_: does snappy do that somewhere?
[12:55] <ogra_> there should be a systemd job that checks if they are outdated and kicks in on boot
[12:55] <ogra_> at least that is how it works on the phone
[12:55] <ogra_> ask tyhicks or jdstrand_ how it exactly works on snappy
[12:56] <ogra_> but i would imagine largely the same ...
[13:04] <kyrofa> zyga, I suspect that ubuntu core launcher does it, actually
[13:05] <kyrofa> zyga, not 100% sure about that
[13:08] <kyrofa> zyga, I figure apparmor is configured with the directory to the profiles, and when u-c-l launches the app for the first time the profile is loaded and cached
[13:17] <zyga> kyrofa: no, it doesn't I did check
[13:17] <zyga> kyrofa: currently snappy does that on changes
[13:17] <noizer> zyga Hi what is the best way to connect to the socket with some code
[13:17] <zyga> kyrofa: but I'm curious about the reboot case
[13:18] <zyga> noizer: in which language?
[13:18] <noizer> uuuhm python
[13:18] <zyga> noizer: in go? using our offcial client API
[13:18] <zyga> noizer: in python, using http package or even requests
[13:18] <zyga> noizer: it's just http
[13:18] <zyga> noizer: over a unix socket
[13:18] <noizer> zyga ok I will give it a shot
[13:19] <kyrofa> zyga, how did you check?
[13:19] <zyga> noizer: you can look at the client package
[13:19] <zyga> kyrofa: I read the source of the laucher
[13:19] <zyga> noizer: it's well tested and has example requests and responses
[13:19] <zyga> noizer: it's pretty nice as documentation
[13:19] <zyga> kyrofa: the launcher handles seccomp profile compilation to ebpf
[13:19] <noizer> zyga: client package? where can I find this
[13:19] <zyga> kyrofa: but apparmor profile has to be already loaded in the kernel AFAIR
[13:20] <zyga> noizer: in the snappy source code, the package client/ is in the top-level directory
[13:20] <zyga> https://github.com/ubuntu-core/snappy/tree/master/client
[13:20] <zyga> noizer: e.g. interface related API is here: https://github.com/ubuntu-core/snappy/blob/master/client/interfaces_test.go
[13:22] <kyrofa> zyga, ah, you're right-- the man page says profiles need to already be loaded with apparmor_parser
[13:24] <zyga> kyrofa: I suspect there's a systemd unit that does this on boot
[13:24] <zyga> kyrofa: but I need to dig and I'm in the middle of meetings
[13:30] <zyga> noizer: if you want to build python APIs that'd be quite useful
[13:30] <zyga> noizer: I can work with you on that in small capacity
[13:32] <kyrofa> zyga, etc/init/apparmor.conf in 15.04
[13:32] <noizer> zyga for me thats good
[13:33] <noizer> Just know how to start best on it
[13:34] <zyga> noizer: noizer cool
[13:34] <zyga> kyrofa: thanks!
[13:35] <zyga> I'm not sure that's doing anything in 16.04, I need to see this in more detail
[13:37] <kyrofa> zyga, yeah, same file on 16.04
[13:38] <noizer> zyga when can we start on the python API?
[13:38] <zyga> noizer: for now I'd make that a separate git/pypi project
[13:38] <zyga> noizer: we're super busy with 16.04 and I'd not complicate it by trying to put it in the main snappy repo
[13:39] <zyga> noizer: after 16.04 we can explore doing that
[13:39] <noizer> oooh ok
[13:39] <zyga> noizer: I'd model a python api after the current Go api
[13:39] <zyga> noizer: if you look at cmd/snap/cmd_* you will see that each command is really trivial
[13:39] <noizer> first i will experience some with the REST
[13:39] <zyga> noizer: and you could re-implement snap (the tool) in python in a handful of screens of text
[13:40] <zyga> noizer: so start a new project (say python-snappy) and start working on the initial package with methods that map to go methods
[13:40] <zyga> noizer: and we can work on a case-by-case basis from there
[13:41] <zyga> noizer: which APIs are you going to touch/need first?
[13:42] <noizer> zyga start and stop services
[13:43] <noizer> so the REST api to maybe the python API
[13:45] <zyga> noizer: that might not be exposed yet, look at cmd/snap/cmd_snap_op.go
[13:45] <zyga> noizer: those are "snap operations"
[13:45] <zyga> noizer: and I don't see service operations yet
[13:47] <noizer> zyga I will have a look at it tonight first and then i will let you know what we can start first.
[13:47] <mvo> zyga: yes, there is a systemd job for this
[13:47] <noizer> zyga just an other question about the REST api. I see that it is possible to start and stop services with a PUT
[13:48] <zyga> mvo: ah, interesting piece of the security puzzle
[13:48] <zyga> mvo: I sure hope we don't race with that job
[13:48] <zyga> noizer: oh? perhaps -- I'm mostly focused on interfaces, perhaps all the bits you want are in
[13:49] <mvo> zyga: something like snappy-runhooks
[13:49] <mvo> zyga: I think it is ordered early
[13:50] <zyga> mvo: ideally we'd start like this <run-hooks> <snappy> <snappy activates various apps>
[13:50] <zyga> mvo: but that's only when we have dynamic interfaces that may not be "the same" after a reboot due to hook decisions
[13:50] <zyga> mvo: for static world, it is nor relevant
[13:59] <noizer> zyga ooh ok but it is interesting too. but for now i need to start services with the rest api. But I will try to make a python API
[13:59] <kyrofa> Chipaca, sergiusens how fleshed out are the 16.04 gadget snaps? Can I write one today?
[13:59]  * zyga wants to know too, I have some interface integration I want to do there
[13:59] <zyga> at least for pi
[13:59] <kyrofa> zyga, for pi here too
[14:00] <zyga> kyrofa: you know where the sources for the gadge snap are, right?
[14:00] <zyga> kyrofa: I want to add static interface declarations there so that bits like I2c and some GPIOs are exposed
[14:00] <ogra_> kyrofa, i dont think they will change much
[14:01] <zyga> kyrofa: and more as I enable
[14:01] <noizer> zyga ok are  you online tonight. then we can discuss how to start the api etc.
[14:01] <kyrofa> zyga, nice
[14:01] <kyrofa> ogra_, change much from 15.04?
[14:01] <ogra_> no, from 16.04
[14:01] <zyga> noizer: just ping me here, even if I'm not around
[14:01] <ogra_> 15.04 is dead and done
[14:02] <noizer> zyga ok I will do that
[14:02] <ogra_> (15.04 did not have gadget snaps ... only oem snaps ;) )
[14:02] <kyrofa> ogra_, argh, I'm lost in a sea of terminology :P
[14:02] <ogra_> haha
[14:02] <ogra_> not only you
[14:03]  * ogra_ updates his personal snaps for interskillcapability supoort
[14:03] <ogra_> :P
[14:03] <kyrofa> Ha!
[14:03] <zyga> ogra_: if you could rename it one more time, which word would you pick?
[14:03] <kyrofa> interskillability reads better
[14:04]  * ysionneau ordered an rpi2, to play with Snappy on real HW.
[14:04] <zyga> ysionneau: cool
[14:04] <kyrofa> zyga, powers
[14:04] <ysionneau> I abandonned the fucked up Tegra X1 boards we have
[14:04] <kyrofa> zyga, maybe special-powers
[14:04] <ogra_> zyga, i would rename it to "nomoresprints"
[14:04] <ogra_> every time you gusy have a sprint i need to rebuild my world :P
[14:04] <ogra_> *guys
[14:04] <kyrofa> zyga, we should host a light-hearted poll on that
[14:05] <kyrofa> zyga, regarding sources, you mean the rpi gadget? No, where is that?
[14:06] <ogra_> https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
[14:06] <ogra_> (note that i havent updated rpi2 there yet, i only bumped the 15.04 oem snap a while ago)
[14:06] <kyrofa> Hmm... pi2 or pi2.moved?
[14:06] <ogra_> pi2 iirc
[14:06] <wiggleworm> has anyone here created a snapcraft.yaml file to build tools usbutils or pciutils? If so can you point me to your file?
[14:07] <ogra_> kyrofa, whichever has a snap.yaml (vs package.yaml)
[14:07] <kyrofa> ogra_, indeed, rpi2
[14:07] <jdstrand> zyga: regarding --reload. yes. that command doesn't have any caching options though, so it is just a compile and (re)load
[14:08] <jdstrand> kyrofa: snappy should be using the appropriate caching options when generating the profile on install. and interfaces should when updating the profile.
[14:08] <jdstrand> err
[14:08] <jdstrand> zyga: ^
[14:08] <kyrofa> Thanks jdstrand, I was curious as well :)
[14:09] <kyrofa> ogra_, and gadget snaps are the only way to have snaps preinstalled in the generated image, right?
[14:09] <jdstrand> zyga: and there is an initscript that is called on early boot that makes sure all the profiles are loaded before stuff runs. it will create caches and update outdated ones
[14:11] <ogra_> kyrofa, no, you should be able to just use the --install option ... though that seems to be broken currently (i pointed mvo to it but didnt open a bug yet, seems the "current" link is missing and system units dont get installed for such snaps)
[14:11] <kyrofa> ogra_, oh darn
[14:11] <ogra_> (the --install option of u-d-f that is)
[14:11] <kyrofa> Right
[14:11] <ogra_> probably it is webdm specific though, i installed webdm that way (which btw breaks all upgradeability )
[14:12] <kyrofa> ogra_, well... log that bug!
[14:12] <kyrofa> :P
[14:17] <zyga> jdstrand: thanks
[14:18] <zyga> jdstrand: I'll be doing exactly this today and tomorrow (meetings aside)
[14:18] <zyga> jdstrand: everything else has landed or waits for a review
[14:19] <beuno_> zyga, sounds like enough of the syntax has landed in snap.yaml that we could kick off store integration?
[14:20] <ogra_> identity crisis ?
[14:20] <beuno> yes, going from sprint to sprint messes you up  :)
[14:21] <zyga> beuno: yes, I think it's all in for 16.04
[14:21] <beuno> ooook
[14:21]  * beuno rolls up sleeves
[14:21] <zyga> beuno: I don't know what the channel for transferring local interfaces over to the store is though
[14:21] <zyga> beuno: I would imagine we'd send them in "search" requets
[14:21] <beuno> zyga, we'll work out the API together
[14:21] <zyga> requests*
[14:21] <beuno> yes, in search requests
[14:22] <zyga> beuno: but the primitives have landed now so snappy has this knowledge
[14:22] <jdstrand> zyga, beuno: are you guys talking about skills -> interfaces is now in 16.04 images?
[14:22] <zyga> beuno: it sounds like a nice card to work on next week (mid week)
[14:22] <zyga> jdstrand: yes
[14:22] <jdstrand> alright, I get the review tools branch landed then
[14:22] <jdstrand> I'll*
[14:23] <kyrofa> sergiusens, FYI ^^ time to release
[14:23] <beuno> zyga, I'll find someone to work on this on the store side
[14:23] <zyga> beuno: sounds good
[14:29] <jdstrand> pindonga: can you do a pull of the review tools? (for the skills to interfaces change
[14:29] <jdstrand> )
[14:29] <jdstrand> pindonga: and hi! :)
[14:29] <pindonga> jdstrand, hi :)
[14:30] <pindonga> ack, will do, but not sure it'll get to prod this week
[14:30] <pindonga> btw, we're on 599 on staging
[14:30] <jdstrand> understood
[14:30] <pindonga> with the new click-review stuff
[14:30] <jdstrand> great
[14:30] <jdstrand> nice! :)
[14:30] <pindonga> if you can submit a few snaps/clicks to test it it'd be great
[14:30] <mvo> ogra_: hm, that should work, the symlink should get created on first boot
[14:31] <jdstrand> ok
[15:02] <kyrofa> ogra_, do you know if we have working kernel snaps as well?
[15:11] <ogra_> kyrofa, all in the store
[15:12] <kyrofa> ogra_, awesome, any chance you know where the sources are?
[15:12] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[15:13] <ogra_> dragonboard  is still a local build from the deb in the archive
[15:13] <ogra_> all others come from these device tarballs
[15:18] <kyrofa> ogra_, I mean the thing containing the snap.yaml. These are all built, right?
[15:18] <ogra_> manually
[15:19] <ogra_> using the scripts from http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
[15:19] <ogra_> (which i hope to have integrated into the build system soon)
[15:20] <kyrofa> ogra_, ah, thanks!
[15:26] <sergiusens> ogra_, kyrofa --install is no different in udf logic to putting it in  a gadget
[15:26] <kyrofa> sergiusens, awesome
[15:26] <ogra_> sergiusens, well
[15:26] <ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --gadget canonical-dragon.canonical --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical -o dragonboard-all-snap.img
[15:27] <ogra_> that gets me an installed webdm without anyx systemd units in place and without the current symlink
[15:27] <ogra_> in that state i cant remove or install the package and auto-upgrades break when trying to stop the webdm service
[15:27] <ogra_> err
[15:27] <ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --gadget canonical-dragon.canonical --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical --install webdm.canonical -o dragonboard-all-snap.img
[15:28] <jdstrand> pindonga: something isn't right. I just uploaded hello-world 16.04-2 (20) to the store and I see:
[15:28] <jdstrand>  2 Passes
[15:28] <jdstrand> OK Stated package version matches the manifest
[15:28] <jdstrand> OK Is a valid click package
[15:28] <ogra_> that was the right one (sorry, pasted from the wrong terminal)
[15:28] <sergiusens> ogra_, right; I'm saying if it is roken for one case it is also brokem for the other
[15:28] <kyrofa> ogra_, man was I confused :P
[15:28] <ogra_> sergiusens, well, gadget is installed ... and i can manually upgrade ubuntu-core
[15:28] <jdstrand> pindonga: the review tools aren't being run
[15:28] <ogra_> the system works fine otherwise
[15:29] <jdstrand> pindonga: https://myapps.developer.ubuntu.com/dev/click-apps/1999/rev/20/
[15:29] <pindonga> jdstrand, errr... staging... the new stuff hasn't landed on prod yet
[15:29] <jdstrand> oh
[15:30] <jdstrand> pindonga: when do we expect that to happen?
[15:31] <pindonga> jdstrand, early next week
[15:31] <pindonga> I'll see if I can do that today
[15:31] <pindonga> but no promises
[15:32] <jdstrand> ok, thanks
[15:32] <renat> Hi all! It's Renat from Screenly=)
[15:33] <kyrofa> Hey renat :)
[15:33] <renat> First of all I want to thank snappy team for help.
[15:33] <renat> =)
[15:33] <pindonga> jdstrand, if I pull this off, is r601 of crt good to go?
[15:33] <renat> Our first snap worked well=)\
[15:33] <jdstrand> pindonga: yes
[15:33] <ogra_> renat, yay !
[15:34] <renat> I have questions, as usual=)
[15:35] <renat> What do snap developers use to build their snaps for raspberry pi? We used Ubuntu MATE, but maybe there are other solutions?
[15:35] <pindonga> jdstrand, pls test on staging sca as we won't roll out to prod if we find the review tools broken there
[15:35]  * pindonga is testing as well
[15:36] <jdstrand> pindonga: the last time I tried on staging istr that I wasn't able to test
[15:36] <beuno> renat, we're building out snap building into Launchpad
[15:36] <pindonga> jdstrand, why?
[15:36] <jdstrand> pindonga: can you tell me where to go to try again?
[15:36] <beuno> renat, so you can build them for ARM in there if you don't have the hardware
[15:36] <jdstrand> idr
[15:36] <pindonga> jdstrand, https://myapps.developer.staging.ubuntu.com
[15:36] <jdstrand> I'll try now though
[15:37] <pindonga> thx, let me know if you have any troubles
[15:37] <beuno> renat, just push a branch with snapcraft, and there will be an option to build a snap from it
[15:37] <renat> I have=) I build on the RaspberryPI2. It's ultra slow=)
[15:37] <renat> beuno, thanks! Amazing!
[15:38] <jdstrand> pindonga: I can't login with the shared account
[15:38] <beuno> renat, you probably need to enable ARM specifically, I think it doesn't build for ARM by default
[15:38] <beuno> on the change details for the snap, once you create it
[15:39] <jdstrand> pindonga: should I try with my personal lp account?
[15:39] <ogra_> renat, for native builds i use the classic dimension under snappy itself ... "sudo snappy enable-classic; snappy shell classic".... then just use apt as usual
[15:40] <renat> ogra_, never tried that.
[15:40] <renat> Thanks for help. Now I have something to experiment with!
[15:40] <ogra_> :)
[15:42] <pindonga> jdstrand, remember staging myapps uses staging sso
[15:42] <pindonga> so separate account
[15:42] <renat> beuno, never used launchpad before. Going to investigate its capabilities soon, thanks.
[15:47] <jdstrand> pindonga: I'm not trying to be dense, but I don't know what to do with that information. are you saying I need to use a separate staging account? if so, how do I get one?
[15:47] <jdstrand> I think I see now why I wasn't able to test on staging :P
[15:49] <pindonga> jdstrand, sorry, yes, you need a staging sso account (login.staging.ubuntu.com)
[15:49] <pindonga> jdstrand, don't worry, I'll do the testing
[15:49] <jdstrand> zyga: hey, I have this yaml: http://paste.ubuntu.com/15274178/ and if I try to install then I see:
[15:49] <pindonga> no point in you having to struggle with this
[15:49] <jdstrand> $ sudo snappy install /tmp/snappy-interfaces-security_0.1_all.snap
[15:49] <jdstrand> Installing /tmp/snappy-interfaces-security_0.1_all.snap
[15:49] <jdstrand> Waiting for snaps-snappy\x2dinterfaces\x2dsecurity.sideload-LSDpPYfYXdlm.mount to stop.
[15:49] <jdstrand> /tmp/snappy-interfaces-security_0.1_all.snap failed to install: only a single slot is supported, 2 found
[15:49] <jdstrand> pindonga: ok thanks. I think it's possible that was the exact outcome we had last time :)
[15:50] <pindonga> quite likely :)
[15:50] <jdstrand> zyga: is there a bug in the yaml or is this just that the interfaces work isn't completed yet?
[15:51] <jdstrand> I believe I am following the documented spec
[15:56] <ysionneau> zyga : so I'm still trying to find out why my hello world (which does dlopen) crashes when it's cross compiled with my own toolchain, but works when using native compiling (in classic shell)
[15:56] <ysionneau> I've attached gdb to the process
[15:57] <jdstrand> mvo_: ok, fyi, hello-world uploaded with updated bash. the store fixes are only on staging. pin donga is working on getting them in prod today, but it might be monday
[15:57] <ysionneau> and when I look at /proc/<pid>/maps , it shows it's using the libraries from the .snap (libc, libdl, libgcc_s) but it's using the dynamic linker from the system
[15:57] <ysionneau> /lib/arm-linux-gnueabihf/ld-2.21.so
[15:57] <ysionneau> I guess this causes the crash
[16:01] <ysionneau> any idea how I can try to use /snaps/hello.sideload/IOCceQHPQPfQ/lib/ld-linux-armhf.so.3 instead of /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ?
[16:03] <ysionneau> I can confirm if I run /lib/ld-linux-armhf.so.3 /snaps/hello.sideload/IOCceQHPQPfQ/usr/bin/hello it crashes, if I run /snaps/hello.sideload/IOCceQHPQPfQ/lib/ld-linux-armhf.so.3 /snaps/hello.sideload/IOCceQHPQPfQ/usr/bin/hello it works
[16:03] <ysionneau> so it's indeed a dynamic linker issue
[16:04] <ogra_> try a wrapper script that sets PATH ?
[16:04] <ogra_> hmm, though that wont help i guess
[16:17] <ysionneau> ok I get it now
[16:17] <ysionneau> I will wrap all my binaries with something that will call $SNAP/lib/ld-linux-armhf.so.3 <binary_name>
[16:18] <ysionneau> 17:04 < ogra_> hmm, though that wont help i guess < nop because the dynamic linker does not use LD_LIBRARY_PATH or PATH, it's loaded by the kernel, taking the string in the "interp" section of the ELF
[16:18] <ysionneau> but it's OK to prefix the binary with the path to the dynamic linker in a wrapper
[16:18] <ysionneau> o/
[16:18] <ysionneau> I might end up with something which works after all...
[16:18] <ogra_> awful, but will likely work :)
[16:19] <ysionneau> not more awful than all the already existing wrappers :p
[16:19] <ogra_> haha, yeah
[16:19] <ogra_> wrappers in wrappers that are in wrapped wrappers :)
[16:19] <ysionneau> ;)
[16:19] <ysionneau> yep
[16:20] <ysionneau> it's either this, or hard coding it in ubuntu-core-launcher like "if (there is a dynamic linker in the snap) execve prefixed with it"
[16:20] <ysionneau> but I suspect you would not like this upstream
[16:20] <ogra_> no idea, i dont maintain the launcher ;)
[16:21] <ysionneau> ah so maybe you would +2 this :p
[16:21]  * ysionneau joking
[16:21] <ogra_> if it saves the dve from hassles i could actually imagine it going upstream
[16:21] <ysionneau> dve ?
[16:21] <ogra_> but i guess the heuristics of "whats a wrapper, how do we identify there is one" might be pretty complicated
[16:21] <ogra_> err
[16:21] <ogra_> s/wrapper/linker/
[16:22] <ogra_> (my head is also full of wrappers it seems)
[16:22] <ogra_> *dev
[16:22] <ogra_> tedg, ^^
[16:24] <tedg> ogra_: ?
[16:25] <ogra_> tedg, if a package ships its own linker,, would it make sense to handle that from ubuntu-core-launcher ?
[16:25] <ogra_> (instead of having to have another wrapper to prefix all calls with the linker path)
[16:26] <tedg> ogra_: I'd say that we don't have a way to signal things to the launcher today, so the wrapper is the better option. I'd like to see the launcher get smarter, but I think that needs to be engineered.
[16:27] <ysionneau> 17:22 < ogra_> (my head is also full of wrappers it seems) < that's when you wrap your head around it
[16:27] <tedg> ogra_: It would be nice if it could load all the environment variables in a consistent way as well, for instance.
[16:27] <ogra_> tedg, yeah, in the case of the linker you dont really have an env var though
[16:27] <tedg> ogra_: Sure, just talking about other things that a more rich launcher would handle.
[16:27] <ogra_> you need to wrap your exec calls into something like "$SNAP/lib/ld-linux-armhf.so.3 <binary_name>"
[16:28] <ogra_> and it would be nice if we could just tell the launcher to do that for us
[16:29] <ysionneau> yep, when you detect that the interp of the binary does exist in the $SNAP/
[16:29] <ysionneau> means you need to parse the ELF to get the interp string
[16:29] <ysionneau> that's actually not that hard to add to the launcher :o
[16:30] <ogra_> well, it could be some option ... or config
[16:31] <ogra_> you dont want to do it all the time
[16:31] <ogra_> (most people will likely just use the system linker)
[16:32] <ogra_> (and rely on LD_LIBRABRY_PATH for their own libs)
[17:01] <kyrofa> wiggleworm, you still around?
[17:12] <ysionneau> well, if you have a path that corresponds to the dynamic linker in your $SNAP, you most likely want to use it
[17:25] <jdstrand> niemeyer: you seem to have disconeected
[17:44] <kyrofa> ogra_, so if cdimage is used to create the kernel snaps, where might I find the kernel configs that we use?
[17:46] <ogra_> either in the source package or in the git trees on kernel.ubuntu.com (ask the kernel team for specific branch urls)
[17:48] <kyrofa> ogra_, excellent thank you
[18:19] <sergiusens> ogra_, do you know if your initrd made it into an OS snap?
[18:20] <ogra_> sergiusens, it made it into all tarballs ... no idea if mvo rebuilt the os snaps today though
[18:20] <ogra_> (its all manual)
[18:20] <ogra_> http://people.canonical.com/~ogra/core-image-stats/20160303.changes
[18:22] <sergiusens> yeah
[18:23] <ogra_> worst case roll your own http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
[18:23] <ogra_> (the mk-os ones should suffice)
[18:35] <sergiusens> ogra_, he'll be pushing one soon
[18:35] <ogra_> k
[18:35] <sergiusens> ogra_, where is this generic initrd installed btw?
[18:36] <ogra_> ogra@styx:~/Devel/packages/initramfs-tools-ubuntu-core-0.7.20$ cat debian/ubuntu-core-generic-initrd.install
[18:36] <ogra_> build/boot/* usr/lib/ubuntu-core-generic-initrd/
[18:36] <ogra_> ogra@styx:~/Devel/packages/initramfs-tools-ubuntu-core-0.7.20$
[18:36] <ogra_> :)
[18:36] <sergiusens> thanks
[18:41] <pindonga> jdstrand, hey, got crt 601 to prod... could you please test uploading some snap ?
[18:41] <pindonga> the fact we can't upload snaps with the same name anymore is a nuisance for testing :/
[18:49] <sergiusens> jdstrand, hey, I never got your ack/nack on https://github.com/ubuntu-core/snapcraft/pull/360
[18:58] <rajen> Folks. Is there a place where you are uploading ".img" file or ".snap's" of daily-preinstalled xenial builds.  I am looking for ubuntu-core snap files when they get released.
[19:10] <jdstrand> pindonga: it is
[19:11] <jdstrand> sergiusens: I'm going to test that snap, have a quick bite to eat, then review your PR
[19:12] <jdstrand> sergiusens: btw, I dig 'snapcraft snap <dir>'
[19:12] <jdstrand> :)
[19:12] <jdstrand> so much nicer than remembering the mksquashfs commands
[19:12] <jdstrand> s/commands/args/
[19:14] <jdstrand> pindonga: woo!
[19:14] <jdstrand>  1 Warning
[19:14] <jdstrand> could not determine fstime of squashfs security-snap-v2_squashfs_supports_fstime
[19:14] <jdstrand> 58 Passes
[19:14] <jdstrand> perfect-o!
[19:14] <pindonga> \o/
[19:15] <jdstrand> pindonga: what interesting though is I don't see the review tools commit number in the passes output any more
[19:16] <jdstrand> pindonga: that certainly doesn't have to be a rushed fix
[19:16] <pindonga> it's only listed for reviewers
[19:16] <jdstrand> ah
[19:16]  * pindonga double checks though, should be there
[19:16] <jdstrand> pindonga: I can do it
[19:17] <jdstrand> pindonga: 601 click-reviewers-tools version
[19:17] <pindonga> yep
[19:18] <jdstrand> pindonga: thanks for the quick turnaround
[19:18] <pindonga> happy it (seemed) to work well (so far)
[19:18] <pindonga>  :)
[19:18] <jdstrand> beuno: fyi, the store is back to reviewing again :)
[19:18] <jdstrand> thanks to pindonga :)
[19:18] <jdstrand> I guess I helped a little
[19:18] <pindonga> :)
[19:26] <the-solipsist> Sorry for a stupid question, but I'm a newbie... If snappy already does app isolation, why would anyone want to install docker on it?
[19:27] <Mikaela> Probably because docker has mostly everything available while snappy doesn't have so much
[19:30] <the-solipsist> So, it's just a matter of time?  And, if Docker provides the kind of app isolation that snappy does, then why create snappy at all?  I can understand the need for LXD, but not for Snappy...
[19:36] <sergiusens> the-solipsist, there's a nice email from Mark in the mailing lists explaining when to use one or the other
[19:39] <ogra_> there are people using snappy in cloud envs ... they are used to docker and have their setups ready to just use them ...
[19:39] <popey> ogra_: I'm told that in the debian world, one just does a dist-upgrade and rpi-update of an image inside a pi 2, to make it work in a pi 3.
[19:39] <popey> https://twitter.com/winkleink/status/705477199042838528
[19:40] <popey> so I guess we need to find out what that does, and update our image, then our image will work on pi 2 and pi 3
[19:40] <ogra_> popey, yeah, most likely some kernel changes to get the devicetree file for the new pi ... and likely also some bootloader updates
[19:40] <ogra_> i'll check on the weekend
[19:41] <wiggleworm> orga_: Do you know anyone who has created a snapcraft.yaml file to build tools usbutils or pciutils?
[19:41] <ogra_> wiggleworm, i doubt that will be possible in a way that you can upload this snap to the store
[19:42] <ogra_> (i might be wrong, but i suspect you will need to access most of /proc and such which means you need to run unconfined ... which in turn means you wont be allowed into the store)
[19:43] <ogra_> wiggleworm, if you want unconfined you can take a look at somehting like http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files though
[19:43] <wiggleworm> thank you - I will look
[19:44] <ogra_> (note though that this hasnt been ported to the security model de jour yet (now called "interfaces") bt still uses last weeks "skills" system)
[19:45]  * ogra_ goes afk ...
[20:48] <dduffey> kyrofa, lool : I am compiling the 3.18 kernel now and seeing if my compile of that vmlinuz still links with with binary modules I have ... if so, then I will re-compile that 3.18 with the necessary kernel settings snappy needs ... do you have a list of config options that I need (and I'm assuming it is okay to statically compile in items rather than have them as modules/add them to initrd)
[20:57] <jdstrand> sergiusens: done
[21:05] <sergiusens> jdstrand, thanks
[21:07] <sergiusens> jdstrand, hm, should I add umask != 0 as well?
[21:13] <jdstrand> sergiusens: you could. that is actually something I would expect the review tools to catch (ie, 0777 file perms)
[21:14] <jdstrand> plus, other access isn't as big of a deal-- a snap shouldn't be shipping private data since it isn't actually private
[21:14] <jdstrand> I don't think it is needed. let the review tools discover weird perms
[21:15] <sergiusens> jdstrand, ok, seems good
[21:17] <sergiusens> kyrofa, mind to start reviewing https://github.com/ubuntu-core/snapcraft/compare/master...sergiusens:feature/1552168/kernel-plugin#diff-a6d756e312a41b33e3a9de439c8527a8R9 ?
[21:20] <sergiusens> kyrofa, the busybox example already works
[21:20] <sergiusens> let me just create a PR
[23:43] <popey> ogra_: fyi, sudo iwconfig wlan0 power off - needed on pi 3, it power saves wifi which means it's unusable
[23:47] <zyga> jdstrand: thanks for the meeeting notes


[02:10] <imgbot> [11:46] <ogra_> imgbot, status 194 vivid
[11:46] <imgbot> Error: There does not seem to be any build with the number 194
[12:10] <ogra_> hmm, seems the importer has a stuck lock file


[00:18] <menn0> axw: I wasn't going to tackle the statemetrics bit so if you've already started on that then great
[00:54] <axw> menn0 wallyworld_: I'm back if you want to chat
[00:54] <wallyworld_> meeting in today's standup HO?
[00:55] <menn0> axw, wallyworld_: sounds good
[02:33] <axw> wallyworld_: what's a sensible upper bound on the flush interval? 10 minutes?
[02:33] <wallyworld_> i was thinking more like seconds
[02:34] <wallyworld_> since we need to not lose errors if agent is killed
[02:34] <wallyworld_> and actually, we should maybe flush immediately if there's an error
[02:34] <wallyworld_> or a warning or ciritical
[02:34] <axw> wallyworld_: it'll flush when the agent shuts down
[02:34] <wallyworld_> what about when it is killed
[02:34] <axw> and it'll go to logsink.log immediately anyway
[02:35] <axw> wallyworld_: what do you mean by killed?
[02:35] <wallyworld_> hard stopped via kill -9 or something
[02:35] <wallyworld_> do we catch signals
[02:35] <axw> wallyworld_: I can't recall if we catch the signal, but we should if we don't
[02:36] <wallyworld_> yep, and systemd restart etc
[02:36] <axw> wallyworld_: SIGTERM should lead to graceful shutdown, which would involve flushing
[02:36] <wallyworld_> ok, all that aside, i think 5 or 10s max for flush interval, IMO
[02:38] <axw> wallyworld_: I'll make it 10 seconds. if we get to 10 seconds then you've basically got no logging happening, and you shouldn't have the flush interval that high anyway
[02:39] <wallyworld_> exactly, hence the desire to not allow the user to do something dumb by mistake
[02:42] <axw> menn0: on the allwatcher frame size thread: doesn't the first response have to have all the records? i.e. like the other watchers, the first response gives you the initial state
[02:43] <menn0> axw: gah, good point
[02:43] <menn0> axw: maybe there needs to be some special handling for the allwatcher
[02:43] <axw> menn0: yeah, it could get pretty huge
[02:43] <axw> menn0: perhaps some kind of continuation flag
[02:44] <menn0> axw: exactly
[03:21] <menn0> wallyworld_: ping
[03:21] <wallyworld_> hey
[03:21] <menn0> wallyworld_: I have some questions about your PR. quick hangout?
[03:21] <wallyworld_> sure
[03:22] <menn0> wallyworld_: standup again?
[03:22] <wallyworld_> yep
[03:57] <wallyworld_> menn0: with where the interface lives, it may be used multiple places so saying it needs to live where it is used doesn't always work. For state, because it's a bit of a ball of mud, we to date have tended to include interfaces for entity foo in the state/foo.go file. For other things like Environ, we have a separate interfaces.go file, but if we were to do that for state as it exists now, it wouldn't be pretty
[03:58] <menn0> wallyworld_: understood but for this interface it seems like it might be better to be defined at point of use.
[03:58] <menn0> wallyworld_: happy to defer to your judgement
[03:59] <wallyworld_> menn0: i guess i'm saying "point of use" could be many places not just one place in the code
[03:59] <menn0> wallyworld_: fair enough
[03:59] <wallyworld_> but the other place, i should return a concrete type though
[05:35] <anastasiamac> axw: ping
[07:46] <rogpeppe> axw, anastasiamac: looking for a second review of https://github.com/juju/juju/pull/7507 if you fancy it...
[07:47] <rogpeppe> wallyworld_: ^
[07:47] <axw> rogpeppe: sure
[07:47] <rogpeppe> axw: ta!
[07:50] <axw> rogpeppe: ah, I was wondering what the context of your tweet was :)
[07:50] <rogpeppe> axw: :)
[07:55] <axw> rogpeppe: LGTM, thanks!
[07:56] <rogpeppe> git diff
[07:56] <rogpeppe> axw: tyvm
[08:00] <rogpeppe> axw: another (tiny) one - I just noticed I missed out a return statement in the ContextWithDeadline code https://github.com/juju/utils/pull/283
[08:01] <axw> rogpeppe: LGTM
[08:15] <rogpeppe> axw: thanks


[13:40] <BluesKaj> Hi all
[13:50] <RikMills> santa_: uploading frameworks
[13:50] <RikMills> and pushing git/tags
[13:50] <santa_> RikMills: thanks a lot!
[13:51] <RikMills> after a short while, I'll set the retry script on a loop
[13:52] <BluesKaj> Hi RikMills, santa_
[13:52] <RikMills> had to switch to ka master to make the uploads. that rsync issue was annoying
[13:52] <santa_> yes, sorry about that
[13:53] <santa_> I don't understand how it could went under the radar
[13:53] <santa_> I wanted to do another RC release with the packages and all but I didn't have time yet
[13:53] <RikMills> not hit that before on the new kde server, so it is odd it happens now
[13:54] <santa_> ahhh, the new server
[13:54] <santa_> maybe that's the explanation
[13:54] <santa_> the problem is that rsync returns 0 (no error) even if no tarball was downloaded
[13:55] <RikMills> maybe the new server has a newer rsync with changed behaviour
[13:55]  * RikMills shrugs
[13:55] <RikMills> or different setup
[13:56] <santa_> yeah, I have that impression too, but I don't know
[13:56] <RikMills> me neither. but your changes fixed it, so hey :)
[13:59] <RikMills> santa_: looks like there is some python installability issue in proposed, so much of fw may not build right away
[13:59] <RikMills> domn
[13:59] <RikMills> *damn
[14:01] <RikMills> python3-distutils is not installable
[14:05] <santa_> so we will have to wait a little bit then


[00:01] <Jc2k> jelmer: its not without its problems - it can only handle revisions that came from git as it stands for example.
[00:02] <Jc2k> anyway, i think im going to sleep at this point :]
[00:33] <jml> :( :( :( :(
[00:33] <jml> I hit Ctrl-C during an up-thread --auto and now everything is screwed :(
[00:35] <jml> switching down to trunk and doing up-thread manually all the way to the top seems to work ok.
[00:35] <jml> (i.e. fix the problem of pending merges without working tree changes)
[00:36] <jml> I hope I haven't actually screwed up the loom though
[00:36] <lifeless> jml: interesting
[00:36] <lifeless> jml: up-thread --auto probably wnats a KeyBoardInterrupt catch-and-rollback
[00:36] <jml> it all started when I accidentally hit "bzr up-thread --auto" when I had uncommitted changes
[00:36] <jml> and so hit C-c
[00:38] <jml> hmm. bzr di -r branch:../trunk/ looks about right.
[00:38] <lifeless> jml: bottom: might be easier :)
[00:39] <jml> lifeless: but less reliable, given that the loom itself is now suspect.
[00:40] <lifeless> jml: current-thread writes are atomic, and up-thread doesn't modify the bottom thread, so I don't see bottom: being faulty
[00:47] <jelmer> rocky, hi
[00:47] <jelmer> rocky, any chance you can confirm that bug in bzr-svn you were hitting is fixed now?
[00:49] <rocky> ohh...
[00:49] <rocky> unfortunately i'm away from my workstation atm, but i'll certainly try it as soon as i can
[01:02] <lifeless> jam: still around?
[02:23] <igc> hi all
[02:28] <thumper> igc: hi
[02:28] <thumper> igc: are you up for a quick skype call?
[02:28] <igc> thumper: sure
[02:45] <igc> thumper: http://arstechnica.com/news.ars/post/20090107-dvcs-adoption-is-soaring-among-open-source-projects.html
[02:53] <lifeless> I need to pop out for a minute to the chemist
[02:53] <lifeless> brb
[02:56] <thumper> Tree transform is malformed [('versioning no contents', 'new-4')]???
[02:56] <thumper> what does that mean?
[03:12] <emmajane> hi all!
[03:12] <emmajane> I'm trying to understand using launchpad for merging branches.
[03:12] <poolie> thumper: it's either a bug in bzr, or in code that's calling in to bzrlib
[03:12] <emmajane> Should there be a big "MERGE" button that I'm looking for?
[03:13] <thumper> poolie: ta
[03:13] <thumper> emmajane: launchpad doesn't merge branches for you yet
[03:13] <thumper> emmajane: we have some kinda future plans, but it just isn't there yet
[03:13] <emmajane> thumper, ah! probably why I can't find a button. :)
[03:13] <thumper> emmajane: exactly
[03:14] <emmajane> thumper, I'm glad to know I'm just a futurist instead of plain ol' daft. ;)
[03:14] <thumper> heh
[03:15] <thumper> emmajane: lets just say I have a loom with about 8 threads dealing with this topic
[03:15] <thumper> that I haven't had time to get to
[03:15] <emmajane> awww.
[03:15] <thumper> ('cause I'm a manager now)
[03:15] <emmajane> So I guess I shouldn't wait for the button to appear tonight? ;)
[03:15] <thumper> and I don't get as much time to code as I'd like
[03:15] <emmajane> (congrats on your promotion)
[03:15] <thumper> emmajane: sorry, no
[03:16] <thumper> emmajane: promotion was quite some time ago
[03:16] <thumper> but thanks
[03:16] <emmajane> thumper, heh. so you're only just coming to grips with never being able to code again. ;)
[03:16] <thumper> well, I hope not never
[03:16] <thumper> just not as often as I'd like
[03:17]  * emmajane nods
[03:17] <emmajane> so to merge I need to pull down the branch I want to merge into; merge; and then push back up?
[03:17]  * emmajane has never done this before.
[03:17] <thumper> emmajane: can you give me a concrete example?
[03:18] <emmajane> https://code.edge.launchpad.net/~emmajane/ubuntu-desktop-course/udc-804/+merge/2799
[03:18] <emmajane> that's sort of concrete, eh? :)
[03:18]  * thumper looks
[03:18] <thumper> right
[03:18] <emmajane> I'm very happy to RTFM if there's anything specific for launchpad.
[03:19] <emmajane> -beta needs to go into main.
[03:19] <poolie> lifeless: can we catch up before you finish today, maybe at 4?
[03:19] <thumper> emmajane: ok, so you are a member of the team that owns the target branch, so that means you can do it
[03:20] <thumper> emmajane: did you want to move this to #launchpad?
[03:20] <emmajane> thumper, can do. :)
[03:24] <lifeless> poolie: shortly before owould be fine
[03:24] <lifeless> and migod its hot out there
[03:26] <poolie> isn't it just
[03:32] <lifeless> anyone know of stats modules in the stdlib ?
[03:33] <lifeless> e.g. to get stddev, IQR etc
[03:41] <lifeless> can someone look at bzrlib.check.Check._check_one_revision
[03:41] <poolie> thumper: hi
[03:41] <poolie> lifeless: i'm pretty sure there is an SD function
[03:41] <poolie> in math?
[03:41] <thumper> poolie: hi, just helping emmajane on #launchpad
[03:42] <poolie> thumper: whenever you like
[03:42] <poolie> lifeless: in scipy according to google
[03:42] <poolie> it's not in math
[03:43] <lifeless> yeah, I knew scipy would have everything I'd need
[03:50] <lifeless> but its not stdlib :(
[03:52] <poolie> copy & paste?
[03:52] <poolie> lifeless: what about that function?
[03:52] <poolie> check_one
[03:53] <lifeless> poolie: well several things
[03:53] <lifeless> it calls check revision tree
[03:53] <lifeless> which means we're extracting the inventory for every revision 3 times I think, maybe more
[03:54] <lifeless> once there, once to generate the text key references, and once in check_weaves
[03:55] <lifeless> check_revision_tree seems to check that the fileid iteration of the inventory only yields each id once; which seems rather redundant to me - its checking using too high an API pehaps
[03:58] <lifeless> and then InventoryFile._check seems to double-check the sha1, which means we're extracting every file text twice (or more)
[03:58] <thumper> poolie: call?
[03:58] <lifeless> so I'm saying it seems like check can be halved in time without huge effort
[04:10] <jml> how hard would it be to add a debug option to bzr that shows bytes transferred? is there one already?
[04:10] <jml> (or can I trick linux into doing this for me somehow?)
[04:10] <lifeless> jml: -Dtransport possibly, also see vila's transport debugging plugin
[04:12] <jml> lifeless: thanks
[04:12] <bob2> ethereal could, too
[04:13] <lifeless> bob2: ELOWTECH
[04:13] <bob2> hehe
[04:17] <poolie> lifeless: yes that's all true
[04:17] <poolie> about check
[04:17] <lifeless> poolie: thanks, useful confirmation
[04:18] <lifeless> you want that call now?
[04:18] <lifeless> poolie: ^
[04:19] <poolie> lifeless: talking to thumper at the moment but straight after that would be good
[04:19] <lifeless> ok
[04:19] <lifeless> I want to finish sharp at 4
[04:21] <poolie> k
[04:54]  * emmajane chuckles at poolie. I assure you it's mostly photos of knitting and looms.
[04:54] <poolie> i was seriously impressed by the looms
[04:54] <emmajane> Thanks. :)
[04:55]  * emmajane is pretty hardcore into the fibre arts.
[04:55] <emmajane> That's only because I'm a recovering bookbinder though.
[05:04] <fullermd> Aren't photos of knits deprecated?   :p
[05:09]  * emmajane chuckles.
[05:14] <poolie> emmajane: what was it that made you chuckle anyhow?
[05:15] <emmajane> poolie, knitting and looms and bzr. It amuses me more than it should.
[05:16] <emmajane> poolie, a friend of mine also runs a craft show called http://www.bazaarbizarre.org/cleveland.html
[05:58] <emmajane> Alright. On that happy note. I'm going to give up on the idea of eating supper (it's 1AM) and trundle off to sleep. http://emmajane.net/node/884 <-- thanks for the help (although it happened over yonder, it all started here).
[07:08] <vila> hi all
[07:09] <Peng_> Good morning. :)
[07:54] <poolie> hello vila, Peng
[07:54] <poolie> sleepy
[08:44] <igc> night
[11:02] <LarstiQ> siretart: heya! In bug 317001 you say an unwriteable dir to watch cause bzr-hookless-email to traceback, I haven't yet managed to reproduce that (then again, I'm still sleepy)
[11:06] <siretart> LarstiQ: yes. testcase: chown -R the branch to root:root and try as user
[11:07] <siretart> silly use case, I know, but we have system configuration managed in a bzr branch, and wondered if I can setup the monitoring (bzr-hookless-mail) as non-priviledged user
[11:07] <siretart> LarstiQ: btw, did you query me before?
[11:08] <LarstiQ> siretart: not in a looong time
[11:08] <siretart> ok. then it was someone else :)
[11:09] <LarstiQ> ah, there needs to be a branch in place *doh*
[11:09] <siretart> yes. I assume the plugin doesn't work else anyways..
[11:10] <LarstiQ> siretart: it does, it notices branches that get created after it starts watching
[11:10] <LarstiQ> (not branches that get mv'ed in the hierarchy, but I've almost fixed that)
[11:10] <LarstiQ> siretart: and of course it needs to open a branch to trigger that traceback, I was just being stupid
[11:12] <LarstiQ> siretart: I'll push your changes up in a sec, thanks for the patch!
[11:13] <siretart> you're welcome!
[14:15] <vila> guilhembi: ping
[16:30] <ericvw> How do I have a branch un-ignore a file extension is ignored globally?
[16:30] <ericvw> that is*
[16:31] <jelmer> ericvw: I don't think there's a way to do that, but you can explicitly override the ignore by "bzr add <filename>"
[16:32] <LarstiQ> it will version the file of course
[16:32] <ericvw> jelmer: Okay, I will do that for now.  Thanks!
[18:11] <Kobaz> how come sometimes i get: These branches have diverged.  Try using "merge" and then "push".
[18:11] <Kobaz> and sometimes i don't
[18:11] <Kobaz> sometimes it will merge for me, and it's auto
[18:11] <Kobaz> here's an example
[18:11] <fullermd> It will never merge for you.
[18:12] <fullermd> The snarky answer is of course "because sometimes they're diverged, and sometimes they haven't"   :p
[18:12] <Kobaz> files 1,2,3 exist in the repo, user A makes changes to file 1 and does a push, user B makes a change to file 2 and does a push
[18:12] <Kobaz> and bzr will complain branches have diverged
[18:12] <Kobaz> so now i have to do a merge
[18:12] <Kobaz> even though nothing is in conflict
[18:12] <fullermd> It's a question of what revisions are where.
[18:13] <fullermd> If all the revisions on the far side are in your local history, they're not diverged, and push can Just Run.
[18:13] <Kobaz> and then other times, person A will modify file 1, and person B will modify file 2, and then a pull is down, and the files are brought down and merged in
[18:13] <fullermd> If there are revisions there that you don't have, though, you have divergeance.
[18:13] <Kobaz> mmm
[18:13] <Kobaz> so it has nothing to do with conflicts then
[18:13] <LarstiQ> Kobaz: correct
[18:14] <fullermd> Yah.  Push doesn't do merges, or create new revisions; it just moved around revs that are already created.
[18:14] <LarstiQ> Kobaz: the divergence is about wether both branches have different revisions from a certain point
[18:14] <LarstiQ> Kobaz: do you know the `bzr missing` command?
[18:15] <Kobaz> yeah
[18:16] <Kobaz> so if there are missing revs, then you need a merge?
[18:16] <LarstiQ> sorry, phone call interrupted
[18:16] <LarstiQ> Kobaz: no
[18:17] <LarstiQ> Kobaz: if missing reports extra revisions for one side only, yours, or theirs, then you can pull/push and do not need a merge.
[18:17] <LarstiQ> Kobaz: but if missing shows extra revisions for _two_ sides, that is when divergence has occurred and you would need a merge
[18:17] <fullermd> If the other side has revs you don't, you're out of date and can pull.  If you have revs the other side doesn't, then it's out of date and you can push.
[18:18] <fullermd> If you both have revs the other doesn't, then you have divergeance, and have to merge them.
[18:18]  * LarstiQ nods
[18:18] <fullermd> (that's a rather simplified way of looking at it, but it works)
[18:18] <LarstiQ> Kobaz: does that make sense?
[18:19] <Kobaz> sec
[18:19] <LarstiQ> lifeless: oh oh, I got an Acer Aspire One, so now I have a laptop with working wireless ;)
[18:22] <Kobaz> okay, i see
[18:38] <beuno> jam, second day using yout log alias, and it's 100 times more comfortable to use. Speed and presentation-wise
[19:27] <maco> hi um, bzr just told me that a file i have on launchpad.net has been locked for 900+ hours, and the error said to use " bzr break-lock lp-46717904:///~maco.m/5-a-day-data/main/.bzr/branch/lock
[19:28] <maco> but when i do that, bzr then tells me that it's an unsupported protocol
[19:28] <maco> why's it telling me to do something it can't do?
[19:28] <jelmer> maco, try running bzr break-lock on the branch location
[19:28] <jelmer> maco, that's a bug in the launchpad plugin
[19:29] <maco> so remove the -##### stuff so it just says lp: like it normally does?
[19:29] <jam> beuno: yeah, I like it a lot, too
[19:30] <jam> a *long* time ago I proposed it as the default for "bzr log", but I think at that time we decided to be compatible with other systems
[19:30] <jam> maco: yeah
[19:30] <jelmer> maco, yeah
[19:30] <maco> ok, thanks
[19:30] <jam> bzr break-lock lp:~maco.m/5-a-day-data/main
[20:00] <Lo-lan-do> jelmer: A thought occurred to me while I was eating my lasagna tonight.
[20:01] <Lo-lan-do> The bzr-svn logs show that there are lots of "get-dir" requests going back and forth to the SVN server, but they all seem to concern past revisions.
[20:01] <Lo-lan-do> Shouldn't their results be cached?  Surely that data is not expected to change over time, is it?
[20:23] <jelmer> Lo-lan-do: Those results specifically are not cached but some of the data that is inferred from them are
[20:27] <guilhembi_> vila: ping
[20:28] <dereine> hi is it possible to follow symlinks?
[20:30] <Lo-lan-do> jelmer: So... why not cache the rest and do without the round-trips?  Or am I talking complete nonsense?
[20:30] <jelmer> Lo-lan-do: Too much caching takes up too much disk space
[20:30] <jelmer> Lo-lan-do: Also, I'm not sure why it's looking at those older revisions at all
[20:35] <Lo-lan-do> Well, I'd be willing to sacrifice some more disk space if it means a commit to SVN takes significantly less than half an hour.
[20:37] <jelmer> Lo-lan-do, let's figure out first why it's looking at those older revisions
[20:37] <jelmer> also, a single get-dir call isn't supposed to be as slow as it appears to be for you
[20:37] <Lo-lan-do> Sounds like a plan.  How can I help?
[20:38] <jelmer> should just be a single round-trip with about a kb of data
[20:38] <Lo-lan-do> I guess the remote server is slow...
[20:38] <dereine> anyone?
[20:38] <LarstiQ> dereine: your question doesn't make sense to me as-is, could you elaborate?
[20:39] <Lo-lan-do> But even if it weren't, there's a scalability problem: the number of requests is O(number of revisions committed through bzr-svn)
[20:39] <fullermd> If they catch you, they might call the cops...
[20:39] <dereine> i have a repo called config
[20:39] <dereine> where i link all my config files
[20:39] <dereine> but bzr only diffs the links itself and not the file behind it
[20:40] <Lo-lan-do> dereine: Store the files under bzr and do the symlinks the other way round?
[20:40] <dereine> no other way?
[20:41] <jelmer> Lo-lan-do, It shouldn't be of that order though
[20:42] <LarstiQ> dereine: no other way
[20:42] <dereine> ok thx! btw bzr is awesome!
[20:42] <Lo-lan-do> Hardlinks maybe.
[20:43] <LarstiQ> Lo-lan-do: I doubt they won't be broken by bzr though.
[20:43] <Lo-lan-do> LarstiQ: If you just use bzr as a backup mechanism and only do the restores by hand, myabe you can afford that.
[20:44] <LarstiQ> Lo-lan-do: possibly
[20:45] <LarstiQ> dereine: how are you using bzr that this becomes an issue?
[20:45] <dereine> i have ~/.config
[20:46] <dereine> no
[20:46] <dereine> ~/config, there i would like to collect all config files for example ~/.bashrc
[20:46] <dereine> and ~/.vimrc ...
[20:46] <dereine> but i don't want to have my home folder as repo
[20:47] <lifeless> jelmer: git pack delta compression
[20:49] <LarstiQ> dereine: ah, right
[20:49] <LarstiQ> dereine: I do that with a ~/dotfiles branch, and then I symlink ~/.zshrc to ~/dotfiles/.zshrc etc
[20:50] <dereine> its still ok
[21:34] <dereine> what is the difference between init-repo and init?
[21:35] <Lo-lan-do> One initialises a repository, the other initialises a branch.
[21:35] <dereine> mh i did not used init-repo
[21:37] <Lo-lan-do> That's not strictly necessary.
[21:37] <Lo-lan-do> A repo is just a way of storing data that saves disk space when several branches share some revisions.
[21:39] <dereine> for my config i only need one branch
[21:39]  * dereine still has to learn
[21:39] <Lo-lan-do> Then no repo is needed.
[21:39] <dereine> so i pushed my current branch to a webspace
[21:39] <dereine> removed my local one
[21:40] <dereine> bzr branch the webspace one
[21:40] <dereine> so now i change a file locally
[21:40] <dereine> how can i get them to the server?, so how can i commit on the server
[21:41] <Lo-lan-do> Either you commit locally then push, or you bind your local branch to the remote one and every commit you do locally will automatically be pushed.
[21:41] <dereine> what happens if i have no internet connection if i bind?
[21:42] <Lo-lan-do> Then you can do bzr commit --local, and push only when you get back on the net.
[21:42] <dereine> ah nice
[21:42] <Lo-lan-do> Or bzr unbind, work, commit, bzr push, bzr bind
[21:42] <dereine> wow
[21:43] <dereine> thats much better than any cvs stuff
[21:43] <Lo-lan-do> You know, I think that kinda was the point :-)
[21:43] <Lo-lan-do> Note that a bound branch is also known as a "checkout".
[21:44] <Lo-lan-do> So when you do "bzr checkout $remotebranch", it behaves the same as a CVS or SVN checkout.  Except you can do diff and log and annotate and whatnot even when you're not on the net.
[21:45] <dereine> the idea of working locally is just much better!
[21:46] <dereine> can you explain what https://launchpad.net/bzr-push-and-update does exactly?
[21:47] <Lo-lan-do> Yeah.
[21:47] <Lo-lan-do> When you're in a branch, you've got your files, and your .bzr dir.
[21:48] <Lo-lan-do> That .bzr dir contains the history of the revisions so far.
[21:48] <dereine> exact
[21:48] <dereine> yes?
[21:48] <Lo-lan-do> When you commit or log or diff, the command operates on that .bzr dir.
[21:49] <Lo-lan-do> When you push to a branch, bzr mostly updates the stored revisions, ie the .bzr dir of that branch.
[21:49] <Lo-lan-do> The actual (plaintext) files need to be updated separately.
[21:50] <Lo-lan-do> If the branch is local, then they are updated automatically, but if the branch is remote then they're not.
[21:50] <dereine> they are only updated if someone merges them from the repo?
[21:50] <Lo-lan-do> Yup, or if the branch is local.
[21:51] <dereine> a personal question, do you have your whole homefolder in a repo?
[21:51] <Lo-lan-do> That plugin does the update for remote branches accessible through ssh.
[21:52] <dereine> nice
[21:52] <Lo-lan-do> No.  I have my ~/bin in a repo, and most of my ~/debian/* stuff, but I not the whole home dir.
[21:53] <dereine> just wonders. because i wait for 5 minutes for a push a branch with files(not .bzr) of one mb
[22:02] <igc> jam: w.r.t. log --short FILE not working ...
[22:03] <igc> I think we need to always include_merges inside calculate_view_revisions if there's a fileid given
[22:03] <igc> sound right?
[22:04] <igc> that should give us the correct projection onto the mainline
[22:09] <jelmer> 'morning Ian
[22:11] <dereine> how can i save the repo , so that i only have to write bzr push?
[22:12] <Lo-lan-do> bzr push --remember $remotelocation
[22:12] <dereine> wow incredible
[22:12] <Lo-lan-do> Although I think it remembers automatically the first time you push
[22:12] <LarstiQ> it does
[22:13] <jelmer> hmm
[22:13] <jelmer> *somebody* should fix progress indication
[22:14] <Lo-lan-do> ...or make stuff so fast that it's unneeded :-)
[22:14]  * LarstiQ quickly goes to sleep
[22:32] <jelmer> poolie, thanks for sending the standup notes again
[22:32] <mwhudson> beuno: apropos of not much, the directory listing for serve-branches should probably paginated
[22:32] <mwhudson> -d
[22:33] <fullermd> Uh oh.
[22:33] <fullermd> "mbp: several calls; today will bzrtools into ppa"
[22:33] <Haffi___> Hi, I've pushed a few python files onto a ssh server I'm running, and me and a few others will be working on these files on separate machines. I've read the user guide but I'm not quite I understand fully the difference between using branch and merge or checkout and update
[22:33] <fullermd> He ran out of verbs already   :(
[22:34] <fullermd> Haffi___: Checkout gives you a [n additional] working tree on a branch.  Branch gives you a new independent branch.
[22:34] <jml> "There should be a newer version of Bzrtools available, e.g. 1.12."
[22:34] <jml> abentley: is this true?
[22:34] <fullermd> Haffi___: Update is how you bring a working tree up to date with its branch.  Merge is how you integrate changes from 2 branches together.
[22:35] <Haffi___> fullermd: So if we're trying to keep things centralized, then we should use checkout and update?
[22:35] <fullermd> (also, rain causes rainbows, and babies come from good home-cookin')
[22:36] <fullermd> Haffi___: That way you'd have everybody working in lockstep on one branch (CVS/SVN style).
[22:36] <fullermd> Now, that doesn't stop people from making their OWN branches and working in them locally, then later merging them into the checkout of trunk.
[22:38] <abentley> jml: No, it's a little early for 1.12.
[22:38] <jml> hmm.
[22:38] <abentley> bzrtools 1.11 won't emit that for a dev version of 1.12.
[22:39] <Haffi___> But regarding concurrency, is it as safe? If I checkout the "latest" branch and work on a file, but in the meantime someone else has made changes to a file and pushed it to the branch when I send my changes in, does it matter shich method I use?
[22:39] <jml> abentley: I somehow have 1.10...
[22:39] <jml> I wonder how that got there
[22:39] <fullermd> Haffi___: If you try to commit in a checkout and it's out of date, it won't let you; you'll have to 'update' first.
[22:40] <jml> ahh ok. running from a branch.
[22:40]  * jml pulls to get the happiness
[22:40] <abentley> jml: So bzrtools 1.11 will work with it.
[22:40] <jml> abentley: yeah, that works. thanks.
[22:41] <abentley> jml: np
[22:41] <fullermd> Hm.  I think it complained for me after bzr.dev changed...
[22:41] <fullermd> I had to pull it before I could multi-pull my plugins.
[22:42] <poolie> jelmer: oh, thanks for saying so
[22:42] <poolie> glad you liked them
[22:42] <Haffi___> I lost the connection for a bit there...
[22:42]  * fullermd likes them too.
[22:42] <abentley> fullermd: What version were you on when you did that?
[22:43] <fullermd> A rev or two back.  Last pulled in Dec sometime.
[22:43] <fullermd> r688 probably.
[22:44] <abentley> fullermd: Well, the version number would be 1.11 then, and that was compatible with 1.12dev
[22:45] <fullermd> Hm.  Well, I can't reproduce it.
[22:45] <Haffi___> Are the IRC logs kept public somewhere?
[22:47] <fullermd> Oh well.  I'll worry about it next time it happens, when I've forgotten about it   ;)
[22:48] <fullermd> jam used to have them somewhere.  Dunno if he still does.
[22:48] <fullermd> Only thing I said after your last was
[22:48] <fullermd> Haffi___: If you try to commit in a checkout and it's out of date, it won't let you; you'll have to 'update' first.
[22:49] <Haffi___> and update is just merging your working tree with the parent branch?
[22:49] <fullermd> Pretty much, yah.
[22:49] <jam> fullermd, Haffi___: If you look in the topic, you can see: http://irclogs.ubuntu.com/
[22:49] <jam> http://irclogs.ubuntu.com/2009/01/14/%23bzr.html
[22:49] <Haffi___> right, thanks... :)
[22:50] <fullermd> Topic?  Well, shoot, why hide the info where nobody will ever look?   :p
[22:50] <jam> That only seems to update every-hour or so
[22:51] <Haffi___> I try to look at documentation and such before asking stupid questions, but sometimes you forget looking at the most obvious places
[23:11]  * ToyKeeper tries to remember how to explicitly set branches URLs for :parent and :submit
[23:11] <ToyKeeper> s/branches/branch/
[23:16] <NfNitLoop> toytoy: --remember
[23:16] <NfNitLoop> er, ToyKeeper
[23:17] <ToyKeeper> Some commands have a --remember option, but the option name and the branch label don't match and the commands I want to use don't have --remember.
[23:18] <fullermd> Parent would be pull, and submit...   mmm...   merge, I think?
[23:18] <NfNitLoop> yep.
[23:18] <NfNitLoop> Yeah, I've been confused by that before too.
[23:18] <NfNitLoop> why aren't they just called the "pull branch" and the "merge branch".
[23:19] <ToyKeeper> I'm still used to the way hg handles branch URLs...  it'll use 'default-CMD' for the 'CMD' command, if it exists, or fall back to 'default' otherwise.  It's simple and intuitive.
[23:20] <ToyKeeper> To set one, edit .hg/hgrc
[23:21] <ToyKeeper> Ah, found it.  .bzr/branch/branch.conf ; '%s_location = URL'
[23:22] <ToyKeeper> I guess it doesn't allow arbitrary labels though, and 'submit_location' isn't the variable for the :submit branch.
[23:24] <ToyKeeper> Odd.  :parent uses 'parent_location = ../trunk/' but :submit uses 'submit_branch = file:///full/path/to/trunk/'
[23:26] <NfNitLoop> as you said, it's not meant for arbitrary aliases. :)
[23:26] <ToyKeeper> If I have both 'submit_branch' and 'submit_location' set, bzr dies on commands like diff, even though 'submit_location' doesn't actually seem to get used for anything.
[23:27] <NfNitLoop> so don't set submit_location?  :)
[23:28] <ToyKeeper> Well, yeah.  It's just odd that it would be ignored when it's alone (since it's the wrong name), but cause a collision when the correct name is set.
[23:28] <ToyKeeper> I resolved the original issue I was having, and now am just looking to see what's fragile or internally inconsistent.
[23:32] <lifeless> jelmer: around?
[23:32] <jelmer> lifeless, somewhat
[23:33] <jelmer> lifeless, what's up?
[23:33] <lifeless> pack delta compression - how did you implement that
[23:33] <lifeless> its xdelta right?
[23:34] <jelmer> I'm not sure it's xdelta completely, but it sure did look like it
[23:35] <jelmer> it's apply_delta() in dulwich/pack.py in dulwich fwiw
[23:35] <lifeless> how fast is your implementation? does it need C bindings to libxdelta? where is it?
[23:35] <jelmer> no, it's implemented in Python
[23:35] <jelmer> lp:dulwich
[23:35] <jelmer> dulwich/pack.py
[23:35] <jelmer> the function is called apply_delta()
[23:36] <lifeless> did you write a compressor?
[23:36] <jelmer> there's a create_delta() as well, but I didn't write that - Jc2k did
[23:36] <lifeless> AIUI xdelta has a turing complete [or nearly] component
[23:36] <lifeless> is that used?
[23:36] <poolie> lifeless: i really don't think it's turing complete
[23:37] <poolie> imbw
[23:37] <poolie> but i don't think it can switch based on the content
[23:37] <poolie> written out by the delta
[23:37] <lifeless> poolie: I have no idea, haven't read the specs, just going on memorys of jams comments
[23:37] <poolie> i guess it would be turing complete if you ran xdelta repeatedly on its own output
[23:37] <poolie> but that would be weird
[23:38] <jelmer> lifeless, I don't think that's used
[23:40] <lifeless> jelmer: thanks
[23:41] <jelmer> lifeless, but speed is an issue with the current in-python implementation
[23:42] <jelmer> I'm looking at ways to improve it at the moment
[23:42] <lifeless> jelmer: I'm putting together a compressbench tool
[23:42] <lifeless> jelmer: it needs a VersionedFile interfface
[23:43] <jelmer> it's ok for small repositories (loudmouth, ~500 revs, takes a few minutes)
[23:43] <lifeless> or rather a subset of it
[23:43] <jelmer> but for e.g. Samba just figuring out what objects to fetch takes a loooong time
[23:43] <lifeless> is it byte orientated?
[23:44] <jelmer> lifeless, is what?
[23:44] <lifeless> and do you string join?
[23:44] <lifeless> the deltas
[23:44] <jelmer> lifeless, the git deltas are byte-based, yes
[23:44] <lifeless> do they work in bits bytes lines
[23:44] <jelmer> bytes
[23:44] <lifeless> do you string join in your decompressor?
[23:45] <jelmer> string concatenate, yes
[23:45] <lifeless> do you know the length of the output when you start decompression?
[23:47] <jelmer> lifeless, sorry, the delta-applyer does string concatenate
[23:47] <jelmer> the decompressor is a simple zlib decompresser
[23:47] <jelmer> and the output length is not known beforehand
[23:47] <lifeless> jelmer: well, I meant the delta applier
[23:47] <lifeless> which is a form of decompression :P
[23:48] <jelmer> lifeless, sure, but it makes the terminology a bit confusing
[23:48] <lifeless> well
[23:48] <jelmer> as all objects (whether they're deltas or plaintexts) are stored zlib-compressed
[23:48] <jelmer> in the packs
[23:48] <lifeless> k, well ignore the zlib step for this discussion
[23:49] <poolie> the length is still not known
[23:49] <poolie> it's an instruction stream
[23:50] <lifeless> poolie: it may be wrapped
[23:50] <poolie> i guess you *could* run over it once as a dummy to work out the eventual length
[23:50] <poolie> if you mean you could have a statement of the eventual length
[23:50] <lifeless> poolie: and as jelmer has been coding this I'm asking him rather than digging up the pack spec to check
[23:50] <poolie> sure
[23:51] <lifeless> jelmer: so, do you know the output length of the object?
[23:51] <jelmer> lifeless, so fwiw, the delta unpack algorithm does not use the delta length
[23:51] <jelmer> lifeless, in dulwich' case we do know the delta length since we always do a complete decompress before applying a delta
[23:52] <lifeless> jelmer: Its not the delta length; what I was getting at was that if you know the objec tlength you could mmap a region of the right size and decompress into place
[23:52] <damijit> Hello, I am wondering if it is save to move the top level directory for a bzr project (i.e., the  one that contains the .bzr directory). Will this cause any problems?
[23:52] <damijit> *safe
[23:55] <jelmer> lifeless, ah, sorry
[23:55] <jelmer> lifeless, the result size *is* known beforehand
[23:55] <jelmer> it's one of the two variable-size headers of the delta
[23:57] <RAOF> damijit: Yes, it's safe.
[23:58] <RAOF> damijit: As long as the contents of that directory stay the same, bzr is (almost) entirely oblivious to where it is.
[23:58] <damijit> RAOF: Thanks, that's good to  know
[23:59] <jelmer> lifeless, we don't use the result size, just for verification purposes


[17:41] <mitya57> Can we please move forward with libwnck3 SRUs? The reported apport regression seems to be absolutely unrelated.
[17:43] <mitya57> bdmurray: ^
[19:36] <bdmurray> mitya57: do you mean the autopkgtest failures? what about the notify-osd one?
[19:55] <mitya57> bdmurray: The error log is not verbose enough, I need a trusty chroot to test it (or a pitti)
[20:24] <bdmurray> mitya57: Okay, I'll look into it myself some on Monday


[06:27] <lotuspsychje> 2 new bugs on bionic, feel free to test them
[06:27] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1740142
[06:28] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1740146
[07:41] <flocculant> lotuspsychje: can't confirm the vlc one - checked yesterday, don't have wayland in xubuntu
[07:41] <lotuspsychje> ah tnx for checking flocculant what grafix do yo have?
[07:42] <flocculant> GeForce 210 using nouveau though
[07:43] <lotuspsychje> flocculant: might be a wayland/radeon issue then
[07:43] <flocculant> k
[08:21] <dax> lotuspsychje: I have AMD, but it's an rx480, so amdgpu not radeon. no problems here :\
[08:25] <lotuspsychje> dax: your on the xorg or wayland session?
[08:26] <dax> lotuspsychje: it's fine with both.
[08:26] <lotuspsychje> allrighty, tnx for testing dax
[08:32] <flocculant> lotuspsychje: I booted live and installed vlc - worked ok there
[08:32] <lotuspsychje> hmmm
[08:32] <flocculant> took 2:30 to get a desktop though ...
[08:34] <lotuspsychje> i got 2 machines out of 3 that lag wayland flocculant
[08:35] <flocculant> wouldn't know wayland from xorg tbh - not something we're worrying about currently
[08:35] <lotuspsychje> kk
[08:35] <dax> only time i can tell a difference is with screenshotting. unsurprisingly (at least if you've read up on wayland), it doesn't work with gimp on wayland
[08:35] <lotuspsychje> flocculant dax ill see where the bug goes from here, perhaps other users might encounter it, tnx for the test
[08:36] <dax> GNOME can do it obviously, but GNOME's screenshot tool is... not as featureful as what i'm used to from Plasma
[08:37] <flocculant> lotuspsychje: np - I'll always try issues at least
[08:37] <lotuspsychje> its weird my bug complains about radeon, but driver installed correctly
[08:38] <lotuspsychje> smplayer works fine on same mkv
[08:39] <lotuspsychje> tested both from terminal, no errors spitout on smplayer