[00:07]  * thumper out for lunch
[00:07] <thumper> damn
[00:07] <thumper> wrong channel
[00:09] <lifeless> jelmer: is there still a gtk applet for bzr?
[00:10] <lifeless> nvm
[00:19] <jam> lifeless: With the new remap code (for map and unmap) I'm now able to get farther in converting revisions from bzr.dev to chk inventory
[00:19] <jam> Last time it failed around 12.1k revs, I'm now at 14.8k
[00:20] <jam> at ~1200s
[00:20] <jam> so it will take maybe an hour to finish
[00:25] <jam> This is the info for a quick conversion of bzrtools:
[00:25] <jam> http://paste.ubuntu.com/79555/
[00:31] <lifeless> jam: cool
[00:32] <jml> lifeless: hello
[00:33] <jml> lifeless: you pinged me yesterday
[00:33] <lifeless> yes, about testresources foo I think
[00:34] <jml> lifeless: want to talk about it now?
[00:34] <lifeless> nope
[00:34] <lifeless> got to leave real sooon
[00:34] <jml> lifeless: np
[00:56] <jam> lifeless: so it took a total of 39m51s to convert all of bzr.dev into development4
[00:56] <jam> I'm doing the repo-details analysis now
[00:57] <lifeless> jam: thats pretty good
[00:57] <jam> Also, my first attempt at a quick hack to get knit delta compression failed. I'm not 100% sure why, but I was setting a parent, and it *wasn't* doing a delta.
[00:57] <jam> I'll also note that I get a *lot* of collisions with different details
[00:57] <jam> I don't quite understand that
[00:58] <LaserJock> do people here regularly use multi-pull?
[00:59] <LaserJock> I tried using -v (for verbose) and the output seems just as terse
[01:03] <jelmer> lifeless, jam: I am allowed to change the inventory returned by Repository.get_inventory(), right?
[01:03] <jam> Legal? probably, recommended?
[01:04] <lifeless> jelmer: no, and split-inventory will not let you
[01:04] <jam> I believe in the chk code we are adding an Inventory.create_by_apply_delta() function, which would be the recommended way to do it
[01:04] <lifeless> jelmer: why do you want to?
[01:05] <jelmer> just curious, it would be a cheap optimization right now
[01:05] <lifeless> jelmer: things could behave badly with aliasing
[01:06] <jelmer> lifeless, bzr.dev doesnt' have a Repository.add_inventory_delta() yet, btw
[01:06] <lifeless> ah
[01:06] <lifeless> its been reviewed, mayhave a name change and so on
[01:07] <lifeless> gotta go, ciao
[01:08] <jml> ciao
[01:08] <awmcclain> Will installing Pyrex make 1.10 run much faster?
[01:09] <jam> awmcclain: are you running from an installed bzr, or from source?
[01:09] <awmcclain> jam: easy_install -U bzr
[01:10] <jam> hmm... I don't know for sure what that gets as a package.
[01:10] <jam> I think it gets the released tarball
[01:10] <jam> which means you should only need gcc
[01:10] <jam> and not Pyrex
[01:10] <awmcclain> "The python package 'Pyrex' is not available. If the .c files are available,
[01:10] <awmcclain> they will be built, but modifying the .pyx files will not rebuild them."
[01:10] <jam> that warning seems fine
[01:10] <lifeless> doesn't bzr --version list the optimisers?
[01:10]  * lifeless goes
[01:10] <jam> you are watching out for the "could not build XXX using the slower python versions instead"
[01:10] <awmcclain> Right, since I'm not modifying the source.
[01:11] <jam> lifeless: you may be interested in: http://paste.ubuntu.com/79569/
[01:11] <jam> if you haven't gone yet
[01:11] <jam> it is the repo details for chk w/ bzr.dev
[01:43] <Peng_> lifeless: Cool. Is it possible to upgrade the indexes or do you have to "rm -rf"/"bzr index"?
[01:48] <rockstar> jelmer, still around?
[01:49] <jelmer> rockstar, yep
[01:49] <rockstar> jelmer, getting a test failure in a fresh subvertpy branch
[01:50] <jelmer> if there's a single test failure, that's a known issue
[01:50] <rockstar> jelmer, http://pastebin.ubuntu.com/79582/
[01:50] <jelmer> the failure is known, the error isn't
[01:50] <rockstar> That's running nosetest on the build
[01:52] <rockstar> I did `python setup.py build && cd build/build-* && nosetests`
[01:52] <rockstar> make check fails in the same way.
[01:52] <jelmer> I moved some things around but forgot to run the tests
[01:53] <jelmer> I'm pushing a fix
[01:53] <jelmer> thanks for letting me know :-)
[01:53] <rockstar> jelmer, sure.
[01:53] <jelmer> the other issue is known, and is caused by the fact that subvertpy can't rely on bzrlib.urlutils
[01:53] <rockstar> jelmer, why's that?
[01:54] <jelmer> it's otherwise independent of bzr, and it would make adoption by e.g. the basie folks harder
[01:54] <rockstar> jelmer, basically, I'm back evaluating using subvertpy in cscvs, and, in effect, the launchpad import system
[01:54] <jelmer> ah, cool
[01:55] <rockstar> jelmer, do you think it could be used in production?
[01:55] <jelmer> subvertpy? Yeah, I think so. The bzr-svn tests exercise it pretty well and I haven't seen any other problems either
[01:56] <jelmer> the server stuff is still incomplete and unstable, but you won't be using that anyway I presume
[01:56] <rockstar> jelmer, nope.
[01:57] <rockstar> We want to be able to roundtrip commits as well.
[01:57] <jelmer> if you want to roundtrip commits, it's probably more worthwile to look into bzr-svn
[01:59] <rockstar> jelmer, did you push the fix to trunk
[02:00] <jelmer> rockstar, yep
[02:02] <rockstar> I'm on rev 1971, and it's telling me there are no revisions to pull
[02:02] <rockstar> :/
[02:02] <jelmer> it's a mirrorred branch, in case you're pulling from lp
[02:02] <rockstar> jelmer, ah, that makes sense.
[02:21] <jelmer> lifeless: looks like by using inventory deltas I can actually avoid that Inventory copy
[02:22] <jelmer> lifeless, that would save another 33 % \o/
[02:28] <jelmer> lifeless, still there?
[02:28] <jelmer> abentley1, ?
[02:29] <jelmer> or somebody else familiar with inventory deltas?
[02:29] <abentley1> jelmer: hi.
[02:30] <jelmer> abentley1, hi!
[02:30] <jelmer> abentley1, Is it possible to recursively delete entries using a single inventory delta entry, or do I need to delete all ancestors separately?
[02:31] <abentley1> jelmer: You're supposed to list all the deletions.
[02:31] <jelmer> abentley1: Thanks.
[02:31] <abentley1> jelmer: I think deleting the parent works with current implementations, but it's not guaranteed.
[02:32] <jelmer> abentley1: Also, is it valid to have two changes for a single ie?
[02:33] <jelmer> file_id I mean
[02:33] <abentley1> jelmer: No, the ie describes the target state.
[02:33] <abentley1> So if you had two, and they differed, one would be wrong.
[02:34] <jelmer> right, that makes sense. Thanks again.
[02:34] <abentley> jelmer: np
[02:35]  * jelmer regrets not trying out inventory deltas earlier. I thought they would be complex to deal with in bzr-svn for some reason, but it's actually improving the code in various places
[02:49] <AfC> It's always a treat when you discover {that,} someone else's code {,that} can make your life better.
[02:54] <jelmer> abentley, is it valid to remove a file_id first and then re-add it again at a different path?
[02:56] <abentley> jelmer: No, a file id should occur at most once in a given delta.
[02:56] <abentley> jelmer: Removing the file_id is not needed if you're moving the file.
[02:58] <abentley> jelmer: There is no "before" or "after" in a delta.  It's ambiguous to perform two operations (deletion or moving) in the same delta.
[02:59] <jelmer> abentley: Ah, ok.
[03:00] <jelmer> I don't know beforehand which files are only removed but not added again (a rename), but I can obviously keep a set of files that are deleted and remove the ones that are also copied from that and just process the renames at the end
[04:29] <metajack> Any idea what "bzr: ERROR: The branch lp:poetry has no revision None." means?  I've used this launchpad branch plenty in the past.  All of a sudden it is being weird.
[05:08] <Chaosmagi>  Do u feel like your life is stuck in a rut, just going around in circles.  I've seen replies to several messages I haven't received.
[05:11] <Peng_> In the svn-import performance thread, I see four messages. Gmane only has two.
[05:12] <Peng_> The mailing list archive says there are five messages. So I guess I am missing something for some reason.
[05:12] <abentley> Peng_: I see 5 also.
[05:13] <Peng_> So it's just me? Damn.
[05:13] <Peng_> :P
[05:13] <abentley> Peng_: #5 is ~ 16 minutes old.
[05:15] <Peng_> abentley: I'm missing the first reply from jam, not the most recent message.
[05:16] <AfC> Sorry for a stupid question: if using bzr-svn, does the Bazaar revno == the Subversion revision number?
[05:17] <AfC> (fresh branch, etc)
[05:17] <abentley> AfC: Not in the general case.
[05:19] <Peng_> AfC: No, because svn revnos are repo-wide while bzr revnos are branch-wide. "bzr log" will show the svn revnos on revisions created with svn.
[05:21] <AfC> ah
[05:22] <AfC> Peng_: didn't know about that. Nice feature. Thanks.
[05:22] <Peng_> There's also an svn revspec, so you can do e.g. "bzr cat -r svn:123 foo".
[05:22] <fullermd> Peng_: Taking reality back is easy.  The question is, does reality want YOU back?
[05:29] <Peng_> Gmane seems to have all of hte messages.
[05:29] <Peng_> Hm.
[06:07] <AfC> Peng_: you have a blog or homepage?
[06:08] <Peng_> AfC: I own a domain name, but whether you can call an almost-blank index.html a "homepage"...
[06:09] <AfC> Peng_: It could hardly be worse than http://audacious-media-player.org/
[06:10] <Peng_> AfC: By "almost-blank", I seriously meant "almost-blank". It's only one page, with no CSS or images or anything. :)
[06:11] <AfC> Fine. I won't link to you.
[06:11] <AfC> {shrug} just trying to be polite and attribute when due.
[06:13] <Peng_> AfC: Thank you. :) I'd really rather not be linked. I just imagine the disappointment someone feels when they click a link, expecting to find something interesting, and...don't. :P
[06:13] <AfC> Maybe you should endeavour to be interesting, then? :)
[06:14] <AfC> [Tricky]
[06:15] <AfC> [/me notices in passing that is virtually impossible to make this conversation not make it appear condescending. Oh well]
[06:15] <Peng_> Heh. I didn't take it that way.
[07:16] <fullermd> I tried being interesting once, but it was way too much work.  I went with irreverant and misanthropic instead; it's surprisingly close to the same thing, but SO much easier.
[07:43] <vila> hi all
[07:45]  * vila had to reset its switch (first time in years, took him a while to even think about it as an explanation for  losing internet connectivity :-)
[08:21] <mtaylor> hey all... I was going to upgrade my launchpad branches to 1.6 but now 1.9 exists... should I just go all the way to 1.9 now? or should I hold off and just do 1.6?
[08:23] <fullermd> I thought I heard that LP doesn't support 1.9 yet.
[08:26] <mtaylor> fullermd: well then - that would be a great reason to not use it yet!
[08:34] <fullermd> It makes it harder anyway   ;p
[09:12] <thekorn> hi, I've got a question about bzr rebase: did I get it right, this plugin can be used to create a new branch containing only the last ten revisions of another branch
[09:15] <thekorn> is there some workflow related documentation to rebase somewhere?
[09:41] <thekorn> ok, maybe I'm wrong with bzr rebase
[09:43] <thekorn> so more general question: is it possible to create a new branch of the last ten revisions of an existing branch?
[09:45] <luks> thekorn: you can probably branch the original branch with -r0, then merge everything from revision 0 to -9, `bzr revert --forget-merges`, `bzr commit`, `bzr replay` the rest
[09:47] <thekorn> luks, hmm, thanks, this looks like magic, let me try
[09:48] <luks> thekorn: basically the problematic part to squash everything from the start of the branch to some point into a single revision
[10:16] <thekorn> luks, does not seem to work, maybe I'm doing something wrong, thanks for your help anyway
[10:35] <yacc> jelmer, yt?
[10:36] <Peng_> fwiw, he last talked 7 hours ago, so likely not
[13:47] <knighthawk> can someone explain the difference between merge, and pull to me? I'm not getting something.
[13:48] <luks> perhaps it would be better if you ask specifically what you don't understand
[14:49] <enobrev> has anyone here ever seen pack files get corrupted after a push
[14:49] <enobrev> ?
[14:52] <jelmer> yacc, hi
[14:52] <Tak> did anyone file a feature request to make `bzr status -S` not show conflicts in an inconsistent way?
[15:04] <enobrev> After a push, when I try to do anything, I get "Unrecognised container format: 'B363'".  A couple of the pack files don't have their header ("Bazaar pack format 1 (introduced in 0.18)").
[15:05] <enobrev> "anything" such as bzr update
[15:06] <knighthawk> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[15:06] <knighthawk> but when I use the merge command I get 'Nothing to do'
[15:10] <LarstiQ> knighthawk: could you provide a bit more context on when this happens, what bzr status/missing say?
[15:11] <LarstiQ> enobrev: I've seen something like that before, don't recall off the top of my head what the situation was.
[15:11] <jelmer> Peng, the mailing list is not sending me everything right away either
[15:28] <enobrev> LarstiQ: you were the one to help me with it last time.  I ended up killing the repo and re-pulling because adding the header manually didn't work
[15:29] <tigger^> hey peeps
[15:29] <LarstiQ> enobrev: ah
[15:29] <tigger^> bzr branch bzr+ssh://myrepo
[15:29] <tigger^> bzr: ERROR: Generic bzr smart protocol error:
[15:30] <tigger^> doesn't give me much to go on..
[15:30] <tigger^> Bazaar (bzr) 1.7.1
[15:30] <tigger^> -Dhpss doesn't change the output at all, which strikes me as odd
[15:32] <enobrev> LarstiQ, at least that's what I did last time.  But just ran into the problem again this morning.  I'm waiting for the developer who made the last push to log on so I can debug with him, but just wondering if anyone's seen that happen around here
[15:32] <LarstiQ> enobrev: this time, go the launchpad answers/bugs route
[15:32] <enobrev> LarstiQ, good call
[15:32]  * LarstiQ nods
[15:32] <LarstiQ> enobrev: succes with that
[15:32]  * LarstiQ heads downtown
[15:33] <enobrev> LarstiQ: thx
[15:38] <tigger^> branching localy I got bzr: ERROR: exceptions.MemoryError:
[15:44] <Tak> wow - `bzr branches localrepodir` => 750MB memory usage
[15:46] <tigger^> swap was disabled on the machine, fixed that, it works now
[15:51] <yacc> jelmer, hi ;)
[15:51] <jelmer> yacc, hi
[15:52] <yacc> jelmer, OT, technically, today #samba-technical is more appropiate ;)
[16:02] <knighthawk> LarstiQ, bzr status says nothing. bzr missing says I'm missing 2 revisions.
[16:10] <jam> abentley: ping about bug #304841
[16:11] <jam> When you say "as of revno 3873" is that because that is the bzr.dev you used to test it with
[16:11] <jam> or that is the actual revision that shows the bug versus not showing it?
[16:11] <abentley> jam: No, that's the version of 1.10 I tested it with.
[16:11] <jam> And are you talking the 1.10 branch or the bzr.dev branch
[16:11] <jam> ug
[16:11] <jam> the new "loom" command hijacked "bzr up" to mean something other than "bzr update"
[16:12] <abentley> jam: 1.10 rc does not exhibit the bug, because it gives the ShortReadv
[16:12] <jam> k, did you try bzr.dev ?
[16:12] <abentley> jam: bzr.dev also gives the ShortReadv
[16:12] <jam> I don't expect anything different but just something to compare against
[16:12] <jam> hm... k
[16:12] <jam> I guess Martin didn't get the revert into bzr.dev yet
[16:13] <abentley> jam: Right.
[16:22] <abentley> jam: It's possible that the waste you're seeing in packs was introduced by Martin's stacking fix in 1.10.  That creates a fulltext if the basis text isn't available.
[16:23] <abentley> jam: (but the basis text may arrive later in the stream).
[16:24] <jam> abentley: I don't think it would "go away" during autopack
[16:24] <jam> Also, this is only in the brisbane-core branch which doesn't have bzr.dev merged in yet
[16:25] <jam> I'm pretty sure it is Robert's chk work, which adds things to the repository, then determines the sha1, and if it collides, just omits one of them from the index.
[16:33] <jam> abentley: do you get the same failure if you don't use "--use-existing" ?
[16:33] <abentley> jam: No, then I get the standard error you get if you push to an existing directory.
[16:34] <jam> sure, I'm just wondering if there is something already wrong with the target, that is causing confusion.
[16:34] <jam> Do you get the failure if you push do a different branch?
[16:35] <jam> Certainly this is the "convert back to fulltext" code, since it is going through "get_bytes()".
[16:35] <jam> I can't actually see the branches, though, so I'm a bit limited in what I can poke at.
[16:36] <abentley> jam: I would expect so, but I'll verify.
[16:39] <abentley> jam: Unfortunately, these are LP branches, so providing a mirror would take significant time.  You may be able to reproduce with lp:~abentley/launchpad/web-diffs
[16:39] <jam> abentley: I'm not on the private team that has access to lp branches
[16:39] <jam> so I can't reproduce at *all*
[16:41] <abentley> jam: That seems dumb.  I've gotta run.  Be back in ~ 2 hours
[16:41] <jam> I won't disagree...
[16:41] <jam> see you later
[16:44] <jam> It would also seem that the CombinedGraphIndex it is using doesn't have any actual indices, so there isn't any way for it to have *any* content.
[16:44] <jam> Seems like something is confused as to where the real content is.
[16:51] <jam> abentley: I can reproduce it here trying to push a stacked branch of bzr with bzr-1.10 onto launchpad.
[16:51] <jam> I get the same: KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()) failure
[16:52] <jam> oddly it takes almost 7m before it gets there...
[17:19] <eferraiuolo> Can someone explain what type of smart server would be the best for the following uses...
[17:20] <eferraiuolo> I want controlled user access to my repos, and maybe certain users have access to certain repos. This is on a server which I manage (VPS)
[17:20] <eferraiuolo> I would need the connection to the server to be encrypted
[17:21] <eferraiuolo> and possibly not want to create SSH or machine-level user accounts for people accessing the repos
[17:21] <eferraiuolo> ...I've been reading up on the different smart server configs and not sure which matches with what I want to do the best, any suggestions?
[17:33] <jam> eferraiuolo: my recommendation would be to use bzr+ssh with a single account
[17:33] <jam> and use different ssh keys for each user
[17:33] <jam> you can see some sample info in contrib/bzr_access
[17:34] <jam> abentley: it also seems that I can reproduce it locally, without having to connect to LP at all
[17:34] <eferraiuolo> okay, so you're suggesting a single user account on my machine that each user would login thru?
[18:02] <LaserJock> can running bzr upgrade after installing bzr 1.9 have some bad consequences?
[18:03] <LaserJock> I tried it and now bzr says there's no repository present when I try to pull/info/status, etc.
[18:04] <beuno> LaserJock, the default format is the same as 0.92
[18:04] <beuno> so there should be no consecuences
[18:05] <beuno> what exactly is the error?
[18:05] <LaserJock> bzr: ERROR: No repository present: <path to repo>
[18:05] <beuno> that's very odd
[18:06] <beuno> are you using a shared repo?
[18:06] <LaserJock> no
[18:06] <beuno> can you check that there's a .bzr dir in there?
[18:06] <LaserJock> yeah, it's there :-)
[18:06] <james_w> LaserJock: check .bzr/repository
[18:06] <LaserJock> I checked that first
[18:06] <james_w> there's a bug where it renames .bzr/repository to repository.moved or something
[18:07] <LaserJock> james_w: there's a repository.backup
[18:07] <james_w> *then* checks
[18:07] <james_w> then doesn't move it back if it fails
[18:07] <beuno> james_w, really???
[18:07] <james_w> LaserJock: yeah, move that to .bzr/repository
[18:07] <beuno> also, why is it upgrading?
[18:07] <beuno> it only should upgrade if LaserJock was on knits
[18:07] <LaserJock> heah, there we co
[18:07] <LaserJock> *go
[18:07] <LaserJock> ok, it works now
[18:07] <james_w> it happens when rich-root support is not the same
[18:07] <beuno> aaah
[18:08] <beuno> rich root is evil
[18:08] <LaserJock> I've had a bunch of "you should upgrade" messages
[18:08] <LaserJock> but I never do it
[18:08] <beuno> ok, so you where on knits
[18:08] <LaserJock> but I decided to try it on a throw-away branch as it didn't matter if it screwed it up
[18:08] <Peng_> Tak: That's something with bzr-svn.
[18:08] <beuno> and you should probably do:  bzr upgrade --rich-root-pack
[18:08] <Peng_> Tak: Augh, I was scrolled really far up. Sorry.
[18:09] <Tak> that's ok - good to know
[18:09] <james_w> bug 145812
[18:09] <LaserJock> I think almost all my branches are rich-root-pack
[18:10] <LaserJock> that's one of my "issues" with bzr is it seems like I'm always worrying about formats, and I don't understand them and can't keep them straight
[18:12] <LaserJock> is pack-0.92 the default?
[18:12] <beuno> yes
[18:13] <LaserJock> ok, I've got a couple of those
[18:15] <LaserJock> now if I upgrade my local branch does that slow down pulls if the branch I'm pulling from has an old format?
[18:16] <beuno> it does
[18:16] <beuno> you should upgrade the remote one as well
[18:16] <LaserJock> well, I never have access to the remote one
[18:16] <LaserJock> so i'll just leave them alone
[18:17] <LaserJock> I just wondered what would happen
[18:24] <jelmer> jam: hi!
[18:24] <jelmer> jam: You mentioned a patch to a bug I was seeing in brisbane-core
[18:24] <jelmer> jam: Which patch is that?
[18:30] <abentley> jam: glad to hear it.
[18:43] <kjcole> Hi.  Any cure for old (0.8.2) error: Error -3 while decompressing: invalid distance too far back?
[18:45] <Peng_> 0.8.2? That release is older than I am. Does anyone even remember the error codes from back then?
[18:48] <kjcole> The error continues, mentioning specifically the same line referred to in a launchpad bug report about memory issues:
[18:48] <kjcole> usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py line 103
[18:49] <kjcole> (It's a very short message resulting from "bzr check" only two or three lines of error, before returning to the prompt.  No long stack.
[19:00] <ToyKeeper> After using bzr, svn makes me :( :(
[19:01] <ToyKeeper> ... especially with this 11 GiB checkout full of dead branches.
[19:40] <pygi> jelmer, how are the duck branches going?
[19:41] <crisb> has anyone any suggestions for end of line translation?
[19:41] <jelmer> crisb, I think there's a plugin somewhere, not sure what the status of it is
[19:42] <jelmer> pygi, Well, they're there
[19:42] <jelmer> pygi, I guess it may be a good idea to put up a wiki page about them..
[19:42] <crisb> jelmer: i've seen that one, but is there any plans for anything more in bzr itself?  the plugin doesnt really do anything automated (but is still useful in some regards)
[19:42] <pygi> jelmer, I mean have you done any work to support them in core? :)
[19:44] <crisb> it would be nice to get some info about how other projects manage it.  my current idea is to use just LF's in the repository except on files which need CRLFs (ini's etc) - is that how other people do it?
[19:44] <jelmer> crisb, yeah, I think most just pick one line ending mechanism
[19:44] <crisb> but I can see that without at least the EOL plugin, repositories could become a mishmash of different line endings
[19:45] <jelmer> crisb, afaik the plugin did most things automated, but perhaps it's a good topic to bring up on the mailing list again
[19:45] <jelmer> crisb, I know we're at least planning on supporting line ending conversions like svn does
[19:47] <crisb> jelmer, ah thats good to know. we're converting from PVCS which (supposedly!) has some sort of conversion between line endings and although I dont see it as a real problem, some people are quite precious about it!
[19:48] <jam> jelmer: the patch is in the email "CHKMap._check_remap()"
[19:48] <jam> abentley: I'm pretty sure I understand the cause and have an idea of a reasonable solution
[19:48] <jam> it was one Martin considered originally, but didn't go with
[19:49] <jam> namely, requesting topological ordering
[19:49] <jam> if we have a fallback vfs
[19:49] <abentley> jam: What was the cause?
[19:49] <jelmer> jam, Thanks, I'll give it a try
[19:49] <jam> If you go back to the bug I mentioned it theree. But basically, Assume you have a delta chani A-B-C-D
[19:49] <jam> and only A is present in the fallback
[19:49] <jam> if we get the delta "C"
[19:50] <jam> we can't extract it to a fulltext
[19:50] <jam> because we haven't seen B yet
[19:50] <jam> abentley: sound reasonable to you?
[19:51] <jam> The actual case I looked at was a bit more confusing than that, because it seemed like I was inserting D, and C was present, but not B.
[19:51] <jam> And I didn't understand how *that* could happen.
[19:51] <jam> But I'm going to start from there.
[19:51] <jam> I should have a patch shortly that you can try.
[19:52] <abentley> jam: I thought we were checking for the case where B wasn't present.
[19:52] <jam> I'm not sure what you mean by "checking for"
[19:53] <jam> The idea is that  the stream is "unordered"
[19:53] <jam> so it can send "C, B, D"
[19:53] <abentley> jam: Only trying to get a fulltext when B was present.
[19:53] <jam> abentley: that might actually be why I saw the confusion
[19:53] <jam> Imagine we are fetching and we see C, D, B
[19:53] <jam> at the point we get to D, C is present
[19:54] <jam> but if we want to insert a fulltext, B is not
[19:54] <jam> (we only look at the direct parent, and not the whole chain)
[19:54] <jam> anyway, I'm not 100% sure
[19:54] <jam> But that is the best I could put together
[19:54] <abentley> jam: I'm pretty sure we're checking whether C is present in the fallback.
[19:54] <jam> (so far)
[19:54] <jelmer> hmm, next issue
[19:54] <jelmer> CHKInventory doesn't have a apply_delta() function anymore
[19:54] <jam> jelmer: you aren't allowed to mutate a CHKInventory
[19:54] <jam> you need to use "create_by_apply_delta()"
[19:55] <jam> which we should be adding to regular Inventory if we haven't
[19:55] <abentley> jelmer: But more likely, you want to use Tree.apply_delta.
[19:55] <jelmer> jam: Thanks, I'll look at that
[19:55] <jelmer> abentley, A tree would be overkill in this situation I think. I'm only constructing the inventory for internal use by bzr-svn
[19:56] <jam> abentley: also, Tree doesn't have apply_delta, right? You have to at least have a MutableTree (I would assume)
[19:56] <abentley> jelmer: Oh, I thought you were using it for commit.
[19:57] <abentley> jam: Interesting question.  Not sure.
[19:57] <jam> You can't really do RevisionTree.apply_delta, IMO
[20:00] <abentley> jam: Well, it would probably be a bad idea, anyhow.
[20:01] <abentley> jam: So I'm looking at the test in knit.py near 1336.
[20:02] <jam> This one, right:
[20:02] <jam> elif ((record.storage_kind in knit_types)
[20:02] <jam>       and (not parents
[20:02] <jam>            or not self._fallback_vfs
[20:02] <jam>            or not self._index.missing_keys(parents)
[20:02] <jam>            or self.missing_keys(parents))):
[20:02] <jam> And the "self.missing_keys(parents)" is supposed to determine that the fallback doesn't have the parent either
[20:02] <abentley> jam: "or self.missing_keys(parents)" should mean that we don't attempt to construct fulltexts unless the parent is present.
[20:02] <jam> Right, so imagine a long change A-B-C-D-E
[20:03] <jam> We first get C
[20:03] <jam> and we see that only A is in the fallback
[20:03] <jam> so we go ahead and insert it as a delta.
[20:03] <jam> then we get D
[20:03] <jam> I guess that should be telling us it is okay to insert as a delta as well, because C is present...
[20:04] <abentley> jam: No, that would fail the missing_keys(parents) and the not _index.missing_keys(parents)
[20:05] <abentley> jam: Okay, I'm inclined to agree that forcing a topo sort makes sense here.
[20:05] <abentley> As it's much simpler.
[20:05] <jam> well, I can say that in my test case, forcing topological order made it "just work"
[20:06] <jam> but I'd like to make sure I know the problem first :)
[20:06] <abentley> So if we have C, we're allowed to make D a fulltext.
[20:06] <jam> abentley: supposedly, but we don't have B to *actually* create D as a fulltext
[20:07] <jam> but the problem is that I don't understand why we *want* to make D a fultext
[20:07] <jam> anyway, here is the "just make it work" patch:
[20:07] <jam> http://paste.ubuntu.com/79974/
[20:07] <abentley> jam: Oh, I was trying to explain it to you because of your last comment.
[20:07] <jam> A whole 1 line insertion
[20:08] <jam> abentley: figured it out
[20:08] <jam> it is a merge revision
[20:08] <jam> and we check "self.missing_keys(parents)"
[20:09] <jam> not "self.missing_keys([compression_parent])"
[20:09] <jam> so it *does* have the direct parent
[20:09] <jam> but not the merged parent
[20:09] <jam> (I'm double checking that)
[20:10] <jam> ok, a bit weird, but "self._index.missing_keys(parents)" returns 1 entry and "self.missing_keys(parents)" returns None...
[20:10] <jam> so that means that the stacked branch has *merged* the base branch
[20:12] <abentley> jam: I'm testing out your patch.
[20:12] <jam> I'll also try a different one that isn't so heavy handed.
[20:13] <abentley> jam: I can confirm your patch works for me.
[20:20] <jam> abentley: I'm almost done with a patch that just fixes parents => compression_parent
[20:20] <jam> give me a sec
[20:21] <jelmer> jam, Yeah, "plain" Inventory doesn't have create_by_apply_delta() yet
[20:21] <jelmer> jam, Other than that, things at least work now - thanks
[20:22] <jam> abentley: try this: http://paste.ubuntu.com/79983/
[20:22] <jam> jelmer: It is trivial to add create_by_apply_delta to plain inventory
[20:22] <jam> basically, it is just "new = self.copy(); new.apply_delta(); return new"
[20:23] <jelmer> right, that's what I was already doing myself, so I've just added a check for that method :-)
[20:23] <jam> I think we would want that actual function in the brisbane branch
[20:23] <jam> if you want to write it up quickly
[20:23] <jam> abentley: so in testing it here, either patch I proposed to you fixes the bug
[20:24] <abentley> jam: testing...
[20:26] <abentley> jam: 2nd patch works for me.
[20:26] <jam> ok. I feel like I have a good grasp of the problem at least.
[20:26] <jam> I'll probably propose both fixes
[20:26] <jam> as I think the topological sorting just means things go smoother in general
[20:27] <jam> and the other is a "correctness" fix
[20:27] <abentley> jam: cool.  Thanks for taking point on this.
[20:28] <jam> np
[20:28] <jam> martin asked me to step up for any stacking problems while he was afk
[20:29] <kjcole> Any way to recover damaged "knit" files?  I have an old tree that appears to be working fine... Until I try to move to a newer system (or create a branch from it).
[20:30] <kjcole> "bzr check" reveals a zlib.error "invalid distance too far back" related -- I think -- to an old memory bug listed on launchpad.
[20:32] <kjcole> (the error appears to be at /usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py line 103, which is listed in the afore-mentioned bug report.)
[20:59] <jelmer> jam: I'll look into providing a patch
[20:59] <jelmer> jam, while I'm at it it would be nice to also fix this: http://paste.ubuntu.com/79989/
[21:00] <jelmer> any idea what's going wrong there?
[21:00] <jam> Probably a problem with an initialization path
[21:01] <jam> I believe Robert added an _entry_cache
[21:01] <jam> so that it doesn't have to read from disk and deserialize into an InventoryEntry multiple times
[21:01] <jam> but I don't know when _entry_cache gets written
[21:01] <jam> I would have thought in __init__ but maybe he did it elsewhere
[21:02] <jelmer> lifeless, ^
[21:08] <jelmer> jam: is it useful that I test and report these issues this at all atm or are you working on fixing them anyway?
[21:09] <jam> ATM, I'm working on some bits lower down in the stack
[21:09] <jam> Also, ATM, I'm the only one working on it... :)
[21:09] <jam> however, I think it is good to be aware of where things are broken in the branch
[21:10] <jam> I believe we want to get tests passing
[21:10] <jam> as it makes further development easier
[21:11] <jelmer> k, I'll just keep reporting issues and seeing if there's (small) things I can help with then
[21:11] <jelmer> speaking of which..
[21:11] <jelmer> InventoryDirectory.children appears to've become a lot slower
[21:12] <jam> jelmer: CHKInventoryDirectory.children is quite slow as it has to go out and bring in more pages, etc.
[21:12] <jam> Oh, and are you using "--development3" or "--development4" ?
[21:13] <jam> --dev4 added a "parent_id,basename => file_id" map
[21:13] <jam> the --dev3 code has to iterate the *entire* inventory for every .children request.
[21:14] <jelmer> I'm using --development4-subtree
[21:14] <jam> so... CHKInventory is now lazily evaluated
[21:14] <jam> so when you create one it doesn't read the whole inventory
[21:15] <jam> and only pages things in as you go to each IE.children
[21:15] <jam> sort of thing
[21:15] <jam> So building up that dict should be a lot slower than having already built it and only evaluating a dictionary
[21:16] <jelmer> right, so I should try to limit inspecting the inventory to the things I actually need
[21:17] <jam> yep
[21:17] <jam> I wish "bzr shelve" worked on windows....
[21:17] <jam> I keep wanting to use it :)
[21:19] <jelmer> yeah, I use it all the time as well :-)
[21:20] <jelmer> when add_inventory_delta() has to do an expensive copy of the inventory and apply the delta against that, is there some cheap way to get the resulting inventory?
[21:21] <jam> not sure
[21:21] <jam> I would guess Robert didn't optimize for that case
[21:21] <jam> Certainly you could just have "add_inventory_delta()" return some sort of Inventory object back to you
[21:25] <jelmer> but calculating that return value might be more expensive in the case of CHKInventory, no?
[21:26] <jam> I would imagine you could just return the CHKInventory
[21:26] <jam> it is really "add_inventory_*by*_delta"
[21:26] <jam> and I think at some point it needs to work out what the basic shape of the inventory is
[21:26] <jam> even if it didn't have to unpack every node.
[21:27] <jam> (I believe Martin mentioned wanting a slightly different name for the function.)
[21:39] <jam> abentley: the plot thickens further... the simple test case doesn't work right because it sees that the parent is missing so it 'buffers' the index entry
[21:40] <jam> I have to figure out how to get one of the entries to not be buffered
[21:40] <jam> ugh
[21:41] <abentley> jam: Did the old shelve work with win32?  It's now provided as "shelve1".
[21:41] <jam> abentley: yeah, the new one fails because of the WT locking issues
[21:41] <jam> you can't actually hold a WT.basis_tree() outside the length of a lock
[21:42] <jam> or you end up with 2 references to the dirstate file
[21:42] <jam> which both try to lock it.
[21:42] <jam> for now "cp" is good enough
[21:42] <jam> but yeah, I can probably use shelve1
[22:09] <awilkins> jelmer: Can bzr-svn 0.5 push a bzr branch as a new svn branch?
[22:09] <jelmer> awilkins, 0.4 can already do that
[22:09] <awilkins> jelmer: Is there a particular syntax?
[22:09] <jelmer> bzr svn-push
[22:09] <awilkins> jelmer: I'm trying to push a branch into a zero-revision svn repo
[22:10] <jelmer> awilkins, you can't push to the root of the repository, as that already exists
[22:10] <jelmer> awilkins, but you can push to e.g. /trunk
[22:11] <awilkins> jelmer: waah, needs create-prefix :-P
[22:11] <jelmer> awilkins, ?
[22:11] <jelmer> awilkins, this behaviour is similar to that of bzr push
[22:11] <jelmer> awilkins, note that you need "bzr svn-push", not "bzr push"
[22:13] <awilkins> Yes, svn-push has no equivalent of the --create-prefix option of "push"
[22:13] <jelmer> ahh
[22:21] <DeviantPeer> hi all!
[22:22] <DeviantPeer> I'm evaluating vcs an trully enjoying bazaar. Just a quick question: is there a way to have local branches whithout using another directory? (something like git does)
[22:23] <DeviantPeer> and also mercurial does that kind of branching.
[22:23] <lifeless> Peng_: rm-rf, new formats need to reindex anyhow to get more data.'2' isn't really finished yet, I haven'tdone a release..
[22:24] <DeviantPeer> I know that you can use hardlinks in order to keep the storage usage low, but it's so easy to do something like (git checkout branch.name) and start using that branch...
[22:26] <lifeless> DeviantPeer: yes, use a shared treeless repository to hold the branches, and then use 'bzr switch' to switch between them.
[22:26] <DeviantPeer> lifeless: shared treeless? hum... how?
[22:26] <jelmer> lifeless, create_by_apply_delta() forgets to set _entry_cache in the returned CHKInventory to {}, could that right?
[22:27] <DeviantPeer> lifeless: or better... where do I start to read about it? any links?
[22:28] <NfNitLoop> DeviantPeer: bzr init-repo . --no-trees;  bzr branch <remote-branch>; cd <workspace>; bzr co --lightweight <local-branch>  :)
[22:28] <NfNitLoop> DeviantPeer: check the bzr wiki for the "workflows" page.
[22:28] <DeviantPeer> NfNitLoop: ok.. gona try that. thx.
[22:29] <NfNitLoop> I'm pretty sure it's one of the ones listed there.  (though I don't remember if 'switch' is mentioned specifically.)
[22:29] <lifeless> jelmer: yes, looks like thats a bug to me
[22:29] <DeviantPeer> NfNitLoop: already open and reading. ;) thx
[22:31] <NfNitLoop> DeviantPeer: unfortunately it does use another directory, but with the --no-trees options, the directory only contains .bzr metadata about the branch, and all of the changesets(?) are stored in a shared .bzr in a parent dir.
[22:31] <DeviantPeer> NfNitLoop: I understood that. I guess it works by harlinking to the other directory
[22:32] <NfNitLoop> nope, no hardlinking.
[22:32] <DeviantPeer> NfNitLoop: ups then.. got to read more ;)
[22:32] <NfNitLoop> *nod*
[22:33] <NfNitLoop> I vaguely remember about one dscm using hardlinking (mercurial?)  and wondered how that worked on windows...
[22:33] <DeviantPeer> NfNitLoop: so if it doesn't use hardlinking it works even on "not so good" filesystems such as ntfs? (well yes.. at works we have to use it.. damn)
[22:34] <NfNitLoop> DeviantPeer: yep!
[22:34] <DeviantPeer> :) goody. :)
[22:34] <NfNitLoop> I use bzr on windows, osx and linux regularly. :p
[22:34] <DeviantPeer> I use wubi on the work computer... and didn't tell anyone about it.
[22:34] <NfNitLoop> wubi?
[22:35] <DeviantPeer> NfNitLoop: a small utility that installs ?ubuntu on top of windows without erasing anything from the hardisk
[22:36] <DeviantPeer> NfNitLoop: I think it's called wubi... I might be giving you the wrong name.
[22:36] <NfNitLoop> oh, cool.  Installs it on the FAT partition?
[22:36] <NfNitLoop> I think I did something like that back when Slackware was cutting-edge. :p
[22:36] <DeviantPeer> anyway.. my manager is realy happy 'cause I'm 5 times more productive than my coleagues
[22:36] <NfNitLoop> heh.  apt-get and free tools will do that.  ;)
[22:36] <DeviantPeer> NfNitLoop: it creates a biiiiig files on the ntfs (10 or more Gib)
[22:37] <NfNitLoop> BTW, I found out that 'meld' works with bzr this week.
[22:37] <NfNitLoop> <--happy. :)
[22:37] <DeviantPeer> NfNitLoop: and then uses that file as a loopback devide for the linux root.
[22:37] <jam> abentley: you may want to review the patch I just sent in, since I don't know if anyone else can get to it.
[22:37] <jam> I'm done working for now.
[22:37] <NfNitLoop> DeviantPeer: aah.
[22:37] <jam> abentley: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E
[22:38] <DeviantPeer> on bazaar: it's looking great. tomorow I'm going to try the "speed" of it when compared to others.
[22:39] <abentley> jam: thanks.
[22:39] <DeviantPeer> on features it rocks.
[22:39] <DeviantPeer> the proper versioning of directories is great.
[22:39] <DeviantPeer> now I can't even believe that I survived without it for so long ;)
[22:40] <NfNitLoop> DeviantPeer: what VCS were you using previously?
[22:40] <DeviantPeer> although ClearCase does version directories
[22:40] <DeviantPeer> NfNitLoop: uff.. I have used CVS, svn, ClearCase (arghhhh!) and git
[22:40] <DeviantPeer> NfNitLoop: now I'm trying some newer ones.
[22:41] <NfNitLoop> We actually used MS VSS at one company I was at.  >.<
[22:41] <DeviantPeer> argh!
[22:41] <DeviantPeer> it's even worse than CCase.
[22:41] <DeviantPeer> :)
[22:41] <DeviantPeer> so much worse than anything actualy ;)
[22:42] <metajack> Any particular reason that bzr+ssh would fail but sftp would work?  I get 'bash: bzr: command not found' and 'bzr: ERROR: Connection closed: please check connectivity'.  ssh host bzr works fine though.
[22:42] <metajack> oh wait. no it doesn't. never mind me :)
[22:42] <NfNitLoop> metajack: glad to be of service! :)
[22:42] <DeviantPeer> metajack: :D
[22:44] <DeviantPeer> well... time to go and read... the old fashion way of learning.
[22:45] <DeviantPeer> NfNitLoop: thx for the tips.
[22:45] <DeviantPeer> lifeless: thx
[22:45] <DeviantPeer> bye all.
[22:54] <lifeless> jelmer: I've pushed a fix
[22:54] <jelmer> lifeless, argh, I was just working on a fix as well..
[22:54] <jelmer> I have a testcase, if that helps..
[22:54] <lifeless> jelmer: won't hurt to have a test
[22:55] <lifeless> jelmer: I just made a __init__
[22:56] <markh> jam: kerguelen is back up :)
[22:58] <Lutin42> hi! I have a bzr repository broken and I'm looking for help to fix it (or at least export its content)
[22:59] <Lutin42> I executed the following command: bzr rm documents
[22:59] <Lutin42> and now, with most of the commands (except logs), I get the following errors: bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: documents
[22:59] <Lutin42> is there any way to fix this?
[23:00] <markh> an assertion eh...  You have a recent verison of bzr?
[23:01] <lifeless> jelmer: feel free to push trivial stuff to brisbane-core directly
[23:01] <lifeless> jelmer: [like trivially correct, doco etc]
[23:02] <jelmer> lifeless, or this test ? :-)
[23:02] <lifeless> jelmer: larger stuff please send a [split-inv][MERGE] to the list, and get an ack before pushing
[23:02] <Lutin42> I was with an old version (1.6 I think)
[23:02] <jelmer> k
[23:02] <Lutin42> updated to 1.9, and still the same problem
[23:03] <lifeless> Lutin42: that error will persist until you removeo the tree and check it again; it is a cache corruption, not a core data corruptio
[23:03] <Lutin42> ok... now I feel like a noob
[23:03] <lifeless> Lutin42: if you have no outstanding changes in the tree, or none you care about, just do 'bzr remove-tree --force; bzr checkout .'
[23:04] <Lutin42> this tree was never pushed anywhere
[23:04] <lifeless> Lutin42: do you have outstanding edits you haven't committed?
[23:05] <Lutin42> nothing that is not backed up
[23:05] <lifeless> ok
[23:05] <lifeless> then do
[23:05] <lifeless> 'bzr remove-tree --force; bzr checkout .'
[23:06] <NfNitLoop> Lutin42: I'm also curious if you're working on a case-insensitive fs. (Windows)
[23:06] <Lutin42> I'm on mac os x
[23:06] <Lutin42> default install
[23:09] <Lutin42> your command seemed to have worked ; produce a lot of conflict though
[23:12] <lifeless> Lutin42: you can clean that up though, using bzr revert/resolve etc
[23:13] <Lutin42> yes ; I'm looking into it, as the slightly different workflow is different for an svn guy
[23:18] <Lutin42> Can I safely assume that all my modifs since the last commit have been moved to <file>.normal_extension.moved and that moving this file to the normal name and then do bzr resolve FILE will solve it?
[23:18] <Lutin42> from what I've seen so far, yes, but just in case...
[23:36] <Lutin42> back to normal
[23:36] <Lutin42> lifeless, thanks a lot for your help
[23:40] <uws> Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
[23:40] <uws> Is it possible this also happens with pull over bzr+ssh:/ if the server is 1.8 and the client is 1.5?
[23:43] <maxb> I'm browsing "bzr help commands" ..... what is a ghost and why would I want to fetch it?
[23:44] <speakman> using bzr+ssh it says "Unable to determine your name. Use "bzr whoami" to set it.", but the whoami is already set to "Forename Lastname<EMAIL_ADDRESS>[23:55] <fullermd> uws: 1.6 (I think) removed the streaming pull thing for various reasons, so yes.


[11:50] <ricotz> tseliot, hi
[11:51] <tseliot> ricotz: hi, I haven't had the time to look into your patch yet, but I will soon
[11:51] <ricotz> tseliot, alright, make sure that the current build doesnt pass the NEW-queue
[11:52] <tseliot> ricotz: I'm pretty sure it did already
[11:52] <ricotz> no, not yet
[11:52] <ricotz> armhf fails of course
[11:52] <tseliot> yes, I'll fix that
[11:53] <ricotz> didn't look into that, some missing ARM__EXCLUSEDs I guess
[11:53] <tseliot> yes, easy stuff
[11:54] <ricotz> still *-386 is not a good way, while real multi-arch is possible
[11:54] <tseliot> yes, well, I used what Debian did, but I'm available to change it
[11:55] <ricotz> ok, take your time


[01:26] <mup> PR snapd#4079 opened: daemon: Allow Polkit authorization to cancel changes <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4079>
[02:04] <pjdc> fyi, starting RT#106813: Production SSO rollout (r1583) shortly
[02:04] <pjdc> er, sorry, wrong channel
[02:27] <mup> PR snapcraft#1640 opened: cli: add what, why, and how to fix to the common errors <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1640>
[06:08] <Guest54752> I have to get started with development of qt Application on ubuntu core how to proceed with snap please help
[07:02] <zyga-solus> mvo: good morning
[07:02] <mvo> hey zyga-solus
[07:02] <zyga-solus> mvo: I'm ready to help with 14.04
[07:02] <zyga-solus> mvo: I'll start by reproducing the problem unless you have some other suggestions
[07:02] <mvo> zyga-solus: cool, I tried to reproduce the error in https://bugs.launchpad.net/snapd/+bug/1721518 but failed so far
[07:02] <mup> Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518>
[07:03] <mvo> zyga-solus: so if you can reproduce that would be great
[07:03] <zyga-solus> ok, let's see what I can do
[07:03] <mvo> zyga-solus: I used the autopkgtest generated image, maybe that is the problem. its a very minimal image. I suspect some boot race but its all very foggy
[07:03] <zyga-solus> mvo: I'll start with a desktop image as I have that around
[07:04] <mvo> zyga-solus: aha, cool
[07:40] <kalikiana> moin moin
[07:43] <zyga-solus> mvo: how did you get 2.27.6? from launchpad somewhere or from the core snap revision?
[07:56] <zyga-solus> mvo: hmm, I cannot install 2.27.6 and 2.28.5 is OK
[08:01] <mvo> zyga-solus: I used 2.27.5 and then installed core
[08:01] <mvo> zyga-solus: so maybe/probably I did not test .6
[08:01] <mvo> zyga-solus: did you manage to reproduce anything?
[08:02] <zyga-solus> mvo: no
[08:02] <mvo> zyga-solus: :(
[08:02] <zyga-solus> mvo: I'll disable reexec and see
[08:02] <mvo> feels like a wild goose chase
[08:02] <zyga-solus> mvo: though that's hardly what the OP did
[08:03] <mvo> zyga-solus: yeah, exactly. once you are happy (or unhappy) please followup in bug
[08:04] <mvo> zyga-solus: I give this one more try in a less minimal image and then give up
[08:04] <mvo> zyga-solus: interessting that cachio  reproduced it
[08:05] <zyga-solus> mvo: with 2.27.5 I get the same behavior
[08:05] <zyga-solus> mvo: I bet there is something we're missing that is making this relevant
[08:06] <mvo> zyga-solus: yeah, hopefully that is also the glue what is wrong :)
[08:06] <zyga-solus> I'll reboot a few times
[08:06] <zyga-solus> maybe it really is timing
[08:07] <mvo> zyga-solus: no luck with a full trusty image either, disappointing
[08:20] <zyga-solus> mvo: woaaah
[08:20] <zyga-solus> mvo: it happened
[08:21] <zyga-solus> mvo: not exactly like in the report but out of 3 installed snaps I lost some interfaces!
[08:21] <zyga-solus> mvo: I just set up auto logging
[08:21] <zyga-solus> mvo: and I was rebooting and running "snap interfaces"
[08:21] <zyga-solus> mvo: I disabled reexec so this is stock 2.27.5
[08:21] <zyga-solus> mvo: I'm investigating the state now
[08:21] <pstolowski> woot
[08:21] <pstolowski> zyga-solus, !
[08:23] <zyga-solus> so the sad stuff is that I don't see any logs from snapd
[08:23] <zyga-solus> zilch
[08:23] <zyga-solus> not a single line
[08:23] <zyga-solus> oh, wait I actually have something now
[08:24] <zyga-ubuntu> http://pastebin.ubuntu.com/25822002/
[08:25] <zyga-ubuntu> theyory
[08:25] <zyga-ubuntu> *theory
[08:25] <zyga-ubuntu> very weak at the moment
[08:25] <zyga-ubuntu> there's a real bug where on certain systems YAML parsing is exploding in unexpected ways
[08:25] <zyga-ubuntu> what if it's just a race that for kernel config + vm reasons are making it more or less likely
[08:25] <zyga-ubuntu> and at random we cannot read yaml's
[08:25] <zyga-ubuntu> another theory: those are not mounted soon enough
[08:26] <zyga-ubuntu> and end up "broken" when the interface repository is setup
[08:26] <zyga-ubuntu> I'll look at the code to see what happens there
[08:26] <zyga-ubuntu> I think we are just saying "ooops, problem but not going to die on this"
[08:27] <zyga-solus> I'll paste my logs in case someone can fish out facts out of timing
[08:27] <zyga-solus> one sec
[08:28] <zyga-ubuntu> syslog: http://paste.ubuntu.com/25822015/
[08:29] <zyga-ubuntu> journalctl http://paste.ubuntu.com/25822015/
[08:29] <zyga-ubuntu> journalctl status snapd.service http://pastebin.ubuntu.com/25822002/
[08:29] <zyga-ubuntu> oh, hold on, one of those is wrong
[08:29] <zyga-ubuntu> http://paste.ubuntu.com/25822017/
[08:29] <zyga-ubuntu> that's journalctl (2nd paste)
[08:30] <zyga-ubuntu> snap list: http://paste.ubuntu.com/25822020/
[08:30] <mvo> zyga-ubuntu: nice! yeah, the things-are-not-mounted-in-time is what the reporter also suggested
[08:30] <zyga-ubuntu> mvo: so my snapd process is in this state now
[08:30] <mvo> zyga-ubuntu: maybe systemd orders things differently in trusty
[08:30] <zyga-ubuntu> I'll keep it as such for now
[08:31] <zyga-ubuntu> I'll inspect units
[08:31] <zyga-ubuntu> mvo: if you have ideas for experiments to make do say, I'll dig around
[08:31] <zyga-ubuntu> zyga@ubuntu-trusty:~$ systemctl
[08:31] <zyga-ubuntu> Failed to issue method call: No such method 'ListUnits'
[08:31] <zyga-ubuntu> hmm, unexpected
[08:31] <zyga-ubuntu> is our systemd compiled correctly?
[08:31] <mvo> sudo ?
[08:32] <mvo> or maybe systemd is in a funny state
[08:32] <mvo> and it just happens to trigger this issue in snapd as a side-effect
[08:32] <zyga-ubuntu> aha, interesting
[08:32] <mvo> (just a very weak theory)
[08:34]  * zyga-ubuntu would love for snapd to log everything to a file manually
[08:37] <zyga-ubuntu> I've tweaked journal settings and rebooted
[08:37] <zyga-ubuntu> I'll try to reproduce the bug again
[08:37] <zyga-ubuntu> but hopefully with full output from snapd
[08:37] <zyga-ubuntu> mvo: is there a thread for this? I'd like to respond
[08:38] <mvo> zyga-ubuntu: https://bugs.launchpad.net/snapd/+bug/1721518
[08:38] <mup> Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518>
[08:43] <sergiusens> Odd_Bloke the `.` is used to namespace the app name with the snap name
[08:44] <zyga-ubuntu> thanks!
[08:46] <zyga-ubuntu> mvo: hmm, why are there /etc/systemd/upstart/snapd.service and /etc/systemd/system/snapd.service?
[08:46] <sergiusens> popey your issue with lxd should be looked at by kalikiana, I feel that the general user experience on lxd has decayed a bit in the past months :-/
[08:47] <popey> thank you
[08:47] <zyga-ubuntu> (sorry, those are /lib, not /etc0
[08:47] <mvo> zyga-ubuntu: I have no idea, I did not work on the trusty part of snapd :/
[08:47] <mvo> zyga-ubuntu: sudo systemctl gives you the same error?
[08:47] <mvo> zyga-ubuntu: i.e. that systemctl is busted? anything in the logs that might indicate whats wrong? is systemctl status snapd working?
[08:48] <zyga-ubuntu> yes
[08:49] <zyga-ubuntu> one sec
[08:49] <zyga-ubuntu> ah, with sudo they work OK
[08:49] <mvo> ok
[08:49] <mvo> so not systemd
[08:50] <mvo> zyga-ubuntu: let me try something
[08:50] <zyga-ubuntu> I've tweaked the snapd unit
[08:50] <zyga-ubuntu> I now have logs each time we start
[08:50] <zyga-ubuntu> I'm in a reboot loop
[08:50] <zyga-ubuntu> let's see what we get
[08:51] <zyga-ubuntu> mvo: and it just happened again :)
[08:52] <zyga-ubuntu> http://pastebin.ubuntu.com/25822085/
[08:52] <zyga-ubuntu> I'll enable debug
[08:52] <mvo> zyga-ubuntu: I wonder if something trivial like http://paste.ubuntu.com/25822089/ would be enough?
[08:53] <zyga-ubuntu> heh, maybe :-)
[08:53] <zyga-ubuntu> don't we do that?
[08:53] <mvo> zyga-ubuntu: maybe you can add it manually to the mount units that exist
[08:53] <zyga-ubuntu> how do we guarantee that those mount before snapd?
[08:53] <zyga-ubuntu> yep
[08:53] <mvo> zyga-ubuntu: I don't think so :(
[08:53] <zyga-ubuntu> let me enable debug and reproduce again before doing htis
[08:54] <mvo> zyga-ubuntu: I think in our systemd the mount stuff happens before multi-user target (where snapd is started). maybe (maybe!) this is different in old systemd?
[08:54] <mvo> zyga-ubuntu: thanks a lot
[08:54] <zyga-ubuntu> mvo: I was assuming that when there's a mount unit
[08:54] <zyga-ubuntu> systemd sets up automount thing
[08:55] <zyga-ubuntu> so that there cannot be a race if you simply attempt to access files s there
[08:55] <zyga-ubuntu> but maybe I'm wrong and that's not default at all
[08:56] <zyga-ubuntu> mvo: honestly another reason I'd cache the snap.yaml files
[08:57] <zyga-ubuntu> mvo: we could operate without mounted units
[08:57] <zyga-ubuntu> mvo: we could even mount them on demand
[09:02] <mvo> zyga-ubuntu: right
[09:02] <mvo> zyga-ubuntu: please keep me updated about if the before=snapd.service helps, that might be an easy fix
[09:03] <zyga-ubuntu> ok
[09:03] <zyga-ubuntu> yes, definitely a 2.29.x material if that helps
[09:11] <pedronis> mvo: zyga-ubuntu:  well on 14.04 systemd is not really pid 1, so not even sure when itself is started and what multi-user.target means there
[09:13] <mup> PR snapcraft#1616 closed: store: guide to account creation upon login <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1616>
[09:14] <pedronis> mvo: don't at least the proxy.* config make sense on classic too? or is the code to set them too dangerous there?
[09:14] <sergiusens> kyrofa for when you come in snapcraft#1607 should be your priority for the week
[09:14] <mup> PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
[09:15] <zyga-ubuntu> mvo: I added Before=snapd.service now, trying to reproduce
[09:16] <zyga-ubuntu> oh!
[09:17] <zyga-ubuntu> and on the 3rd boot it failed again!
[09:17] <zyga-ubuntu> in super weird way where core didn't load but others did
[09:17] <sergiusens> kyrofa kalikiana elopio every PR has a milestone now, DO NOT merge those marked 2.36 or we will never cut a release; focus on getting the 2.35 stuff finalized please
[09:18] <mvo> zyga-ubuntu: uhh, so strange
[09:21] <mup> PR snapd#4080 opened: snapctl: added long help to stop/start/restart command <Created by stolowski> <https://github.com/snapcore/snapd/pull/4080>
[09:21] <kalikiana> sergiusens: Alright. 5 PRs to get in by the looks of it. Let's push those hard!
[09:24] <pedronis> zyga-ubuntu: does systemd  own logs tells something about the order it did things?
[09:25] <zyga-ubuntu> pedronis: no, things are very crippled
[09:25] <zyga-ubuntu> pedronis: but let me look at one thing, it may indicate time
[09:25] <zyga-ubuntu> so...
[09:25] <zyga-ubuntu> core mounted on
[09:25] <Saviq> mvo: hey, when you have a bit of time, can you point me at how you took care of the "autopkgtests" results in snapd's PRs?
[09:25] <zyga-ubuntu>    Active: active (mounted) since czw 2017-10-26 11:16:39 CEST; 1min 51s ago
[09:27] <zyga-ubuntu> snapd started on
[09:27] <zyga-ubuntu>    Active: active (running) since czw 2017-10-26 11:16:41 CEST; 10min ago
[09:27] <zyga-ubuntu> so core *was* mounted at the time snapd was started
[09:28] <zyga-ubuntu> I added this to the bug report
[09:29] <mvo> Saviq: sure, what do you mean with "took care of" ? how we added autpkgtests to the PRs?
[09:29] <mvo> zyga-ubuntu: sounds like we need more debug in why it fails to find core then
[09:29] <zyga-ubuntu> mvo: yes, I'm building snapd from 2.27.5 now
[09:29] <Saviq> mvo: yes
[09:29] <zyga-ubuntu> I'll add verbose logging to that part
[09:29] <mvo> zyga-ubuntu: \o/
[09:29] <zyga-ubuntu> where we add interfaces from snaps
[09:30] <mvo> Saviq: I talked to martin pitt, however nowdays you will need to talk to laney or sil2100 afaik, then your projects gets whitelisted and you add a webhook
[09:30] <Saviq> mvo: aha so it's a feature of autopkgtests, nice :0
[09:31] <Saviq> .u.c, that is
[09:31] <mvo> Saviq: yeah
[09:31] <Saviq> mvo: thanks!
[09:31] <mvo> yw
[09:39] <ogra_> mcphail, i dont think the sheevaplug is ARMv7 ... (so same thing as RPi-1 ... Ubuntu wont run on it)
[09:40] <mcphail> Thanks ogra_
[09:42] <mwhudson> arm9 woo
[09:45] <ogra_> i guess with the upcoming base snaps we could eventually have an armbian-base snap though ...
[09:45] <ogra_> that would be v6
[09:46] <ogra_> (though might not work if snapd in the core snap isnt also built for v6)
[09:48] <mcphail> ogra_: thought this through with kyrofa last night and realised i was not on to a winner
[09:55] <zyga-ubuntu> ok, so I have a logging build of 2.27.5
[09:55] <zyga-ubuntu> no change apart from printfs in a few spots
[09:56]  * zyga-ubuntu is in a reboot loop again
[09:56] <zyga-ubuntu> wooooah
[09:56] <zyga-ubuntu> mvo: I know what the bug is now!
[09:56] <zyga-ubuntu> wow, that's golden :D
[09:57] <zyga-ubuntu> mvo: you'll love this
[09:57] <zyga-ubuntu> http://paste.ubuntu.com/25822364/
[09:57] <zyga-ubuntu> so
[09:57] <zyga-ubuntu> we load snaps _after_ loading connections *somehow*
[09:57] <mvo> ohhh
[09:57] <mvo> a race on our side, how strange
[09:57] <zyga-ubuntu> yes
[09:58] <zyga-ubuntu> but that's almost crazy
[09:58] <zyga-ubuntu> I don't recall any goroutines or tasks there
[09:59] <pedronis> load snaps?
[09:59] <mvo> zyga-ubuntu: yeah
[09:59] <zyga-ubuntu> pedronis: I updated the bug again
[10:00]  * zyga-ubuntu looks at what could cause this
[10:00] <mvo> zyga-ubuntu: silly question, could it still be snap.yaml missing for some reason? i.e. still the mount ordering race?
[10:00] <zyga-ubuntu> no
[10:01] <zyga-ubuntu> I verified that we started after the mount was ready
[10:01] <zyga-ubuntu> I suspect that starting snapd itself can trigger this
[10:01] <zyga-ubuntu> after everything else is settled
[10:01] <zyga-ubuntu> I'm looking at the code to see what happens there, I'll verify this later
[10:02] <mvo> zyga-ubuntu: ok, re mount unit - it might be the thing that system reports that it started the mount unit but the mount is not fully done when systemd returns and starts snapd or is that not a possibility?
[10:04] <zyga-ubuntu> mvo: look at my last pastebin
[10:04] <zyga-ubuntu> mvo: it's irrelevant because we do stuff on interfaces before we even loaded them
[10:04] <zyga-ubuntu> mvo: and we load all of them correctly later
[10:04] <mvo> zyga-ubuntu: ok
[10:05] <mvo> zyga-ubuntu: could you please pastebin your diff to produce this debug output?
[10:05] <zyga-ubuntu> no diff but I can pastebin the one file
[10:06] <zyga-ubuntu> http://paste.ubuntu.com/25822405/
[10:06] <zyga-ubuntu> that's all the modifications I did on top of the 14.04 package
[10:06] <zyga-ubuntu> (maybe I could ask dpkg to get a diff somehow)
[10:08] <mvo> ta
[10:08] <zyga-ubuntu> sorry, IRL interrupts
[10:08] <zyga-ubuntu> back now
[10:08] <mvo> no worries
[10:09] <zyga-ubuntu> so no goroutines in how overlord starts
[10:09] <pstolowski> zyga-ubuntu, some quick feedback on your content interface pr
[10:09] <zyga-ubuntu> I'll look at what can cause the first output
[10:09] <zyga-ubuntu> pstolowski: thank you!
[10:10] <zyga-ubuntu> (the one where we are missing the snaps and go setup stuff)
[10:10] <zyga-ubuntu> mvo: hmmm
[10:10] <zyga-ubuntu> mvo: I think I made a mistake
[10:10] <zyga-ubuntu> mvo: there are two files, stdout and stderr
[10:11] <zyga-ubuntu> so odering is not what appears in the log file
[10:11] <zyga-ubuntu> I'll add more debug
[10:11] <zyga-ubuntu> mvo: it's clear we are loading the three snaps
[10:11] <zyga-ubuntu> and it's also clear that when reloadConnections is called we cannot find them
[10:12] <zyga-ubuntu> although
[10:12] <zyga-ubuntu> I just noticed this;
[10:12] <zyga-ubuntu> Plugs:map[string]*snap.PlugInfo(nil),
[10:12] <zyga-ubuntu> so they are indeed not present
[10:12] <zyga-ubuntu> how can we load a yaml
[10:12] <zyga-ubuntu> and not that !?
[10:12] <zyga-ubuntu> this version does not have that fancy validation that's using backchannels, right?
[10:13] <mvo> zyga-ubuntu: fwiw, I just unmount my /snap/*/* and added your debug info and ran snapd and I see similar behaviour, my debug info looks similar and I also get the "cannot connect plug..." messages
[10:18] <zyga-ubuntu> mvo: down to the list of snaps but no plug/slot?
[10:18] <zyga-ubuntu> mvo: something else is not showing an error message then
[10:18] <zyga-ubuntu> mvo: maybe another case of logger.Noticef not working
[10:18] <zyga-ubuntu> mvo: I know for a fact that it doesn't log in some cases (not sure what triggers this)
[10:18] <zyga-ubuntu> mvo: maybe we fail earlier but don't show it
[10:19] <mvo> zyga-ubuntu: I think what I see is similar, not sure if equal because I still haven't reproduce it on my box a single time :/
[10:21] <zyga-ubuntu>                         logger.Noticef("cannot retrieve info for snap %q: %s", snapName, err)
[10:21] <zyga-ubuntu> this is how we log that failure
[10:21] <zyga-ubuntu> I'll patch logger to fmt.Printf just without any other fanciness
[10:21] <mvo> zyga-ubuntu: +1
[10:22] <mvo> zyga-ubuntu: so yeah, if I manually umount and restart snapd I think I see exactly what is happening here. but but I'm super puzzled that before=snapd.service does not work in the mount units
[10:25] <zyga-ubuntu> mvo: let me paste my unit
[10:25] <zyga-ubuntu> maybe I did it incorrectly
[10:25] <zyga-ubuntu> (rebooting now)
[10:25] <zyga-ubuntu> with new logger
[10:25] <zyga-ubuntu> mvo: and BTW< the null loger is just MEH
[10:25] <zyga-ubuntu> why did we even have that?
[10:25] <zyga-ubuntu> early logger should be buffered
[10:25] <zyga-ubuntu> and replayed after configuration
[10:26] <zyga-ubuntu> ha
[10:26] <zyga-ubuntu> I'm lucky
[10:26] <zyga-ubuntu> boot and fail
[10:27] <mvo> zyga-ubuntu: nice! looking forward for the pastebin
[10:28] <mup> PR snapd#4075 closed: many: reorg things in preparation to make handling of the base url in store dynamic  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4075>
[10:28] <zyga-ubuntu> actually, nothing logged :/
[10:29] <zyga-ubuntu> nothing more that is
[10:29] <zyga-ubuntu> I see my logging patch being there bug nothing, no errors
[10:29] <zyga-ubuntu> I wonder if this is a problem:
[10:29] <zyga-ubuntu> ...failed snap epoch cannot be empty
[10:32] <zyga-ubuntu> mvo: how are you running 14.04?
[10:32] <mvo> zyga-ubuntu: how does your boot unit look like? where you added the "before" thing? could you please pastebin one
[10:32] <mvo> zyga-ubuntu: in a qemu VM
[10:34] <zyga-solus> mvo: SMP or UP?
[10:34] <zyga-solus> mvo: I'll pastebin in a sec
[10:35] <zyga-ubuntu> log from failure: http://paste.ubuntu.com/25822552/
[10:35] <zyga-ubuntu> http://paste.ubuntu.com/25822556/
[10:36] <mvo> j
[10:36] <mvo> zyga-solus: defaults, so probably UP
[10:36] <mvo> zyga-ubuntu: before= needs to go into the [unit]
[10:37] <zyga-ubuntu> mvo: aha
[10:37] <zyga-ubuntu> mvo: so...
[10:37] <zyga-ubuntu> mvo: how can we load a yaml
[10:37] <zyga-ubuntu> see the apps
[10:37] <zyga-ubuntu> and not the plugs!?
[10:37] <zyga-ubuntu> look at line 6
[10:37] <mvo> zyga-ubuntu: I suspect it did not load the yaml, but maybe I am wrong
[10:37] <mvo> zyga-ubuntu: try manually umount core
[10:37] <mvo> zyga-ubuntu: and restart snapd
[10:38] <zyga-ubuntu> apps are not in the snap state, are they?
[10:38] <mvo> zyga-ubuntu: I need to check, I don't know off-hand
[10:40] <zyga-solus> mvo: my qemu is SMP
[10:40] <zyga-solus> mvo: maybe that's relevant
[10:40] <zyga-solus> I added logging to snap yaml loading
[10:40] <mvo> zyga-solus: I can try that. I also wonder if moving the before= helps
[10:43] <zyga-ubuntu> http://paste.ubuntu.com/25822591/
[10:43] <zyga-ubuntu> shttp://paste.ubuntu.com/25822590/
[10:44] <zyga-ubuntu> http://paste.ubuntu.com/25822590/
[10:45] <zyga-solus> mvo: look at this please
[10:45] <zyga-solus> mvo: here canonical-livepatch did not load
[10:45] <mvo> zyga-solus: in which one of the three?
[10:46] <mvo> zyga-solus: aha, in the middle one, right?
[10:46] <zyga-solus> mvo: just two
[10:46] <zyga-solus> we didn't load canonical-livepatch
[10:46] <zyga-solus> the other log is the same as before but with very verbose output when we load a yaml
[10:46] <zyga-solus> snapstate.ActiveInfos() returned: []*snap.Info{(*snap.Info)(0xc82027c000), (*snap.Info)(0xc82027c780), (*snap.Info)(0xc82027cf00)}
[10:46] <zyga-solus> this returns three infos
[10:46] <zyga-solus> but only two yamls were loaded
[10:46] <zyga-solus> a moment later we do something else that loads yamls
[10:47] <zyga-solus> and then we load all three correctly
[10:47] <zyga-solus> something is still not failing when meta/snap.yaml is absent
[10:47] <zyga-solus> I'll look at snap manager now
[10:50] <zyga-solus> Broken:"cannot read snap \"canonical-livepatch\": cannot find installed snap \"canonical-livepatch\" at revision 26
[10:50] <zyga-solus> mvo: I think you were right
[10:51] <zyga-solus> I'll move the Before thing now
[10:51] <mvo> zyga-solus: yay, thank you, its a wild chase
[10:51] <zyga-solus> mvo: we don't log that
[10:51] <zyga-solus> mvo: because it goes into Broken: reason
[10:51] <zyga-solus> I think we should be super vocal about broken snaps at startup
[10:52] <mvo> yes
[10:52] <mvo> *YES* :)
[10:52]  * mvo tries the SMP thing
[10:52] <zyga-solus> mvo: btw, this also means that sometimes machies may not reexec
[10:52] <zyga-solus> mvo: which is crazy bad if you think about it
[10:54] <mvo> zyga-solus: :( that is something we need to inspect too
[10:54] <mvo> zyga-solus: I can reproduce it now I think with -smp 4 in my qemu :-D
[10:54] <zyga-solus> woot
[10:54] <zyga-solus> great
[10:56] <zyga-solus> so far so good, no failures
[10:57] <popey> I appear to have a corrupt core snap on my system. https://forum.snapcraft.io/t/snapcraft-unable-to-install-core-snap/2599/27
[10:58] <popey>  pedronis helped debug this, but I wonder how I got in this state and how one gets out of it
[10:58] <zyga-solus> popey: what is the sha of the snap?
[10:59] <zyga-solus> mvo: no failures
[10:59] <zyga-solus> mvo: so good news and bad news
[10:59] <mvo> zyga-solus: sweet
[10:59] <zyga-solus> mvo: good news is this is a simple fix
[10:59] <mvo> zyga-solus: what is the bad news here :) ?
[10:59] <zyga-solus> mvo: bad news is that we never rewrite mount units
[10:59] <zyga-solus> mvo: we need to switch to EnsureFiles.. for that
[11:00] <mvo> zyga-solus: meh, ok
[11:00] <zyga-solus> and perhaps even restart snapd if we bot and found that we modified them (the function will tell us)
[11:01] <zyga-solus> mvo: ok, I have no failures and I bet this is this now
[11:02] <mvo> zyga-solus: thank you so much for trakcing this down. I pushed a trivial PR to fix it for new units, I get lunch now, lets talk at the standup about the rewriting
[11:02] <zyga-solus> oh
[11:03] <mup> PR snapd#4081 opened: systemd: run all mount units before snapd.service to avoid race <Created by mvo5> <https://github.com/snapcore/snapd/pull/4081>
[11:03] <zyga-solus> I was just pushing :)
[11:03] <zyga-solus> haha
[11:03] <zyga-solus> ok
[11:03] <zyga-solus> thank you
[11:03] <mvo> zyga-solus: autsch, sorry
[11:03] <zyga-solus> no worries, can you please edit the commit message to explain what we found\
[11:03] <zyga-solus> I'll break too, I need to go to school (1st time, more later)
[11:03] <zyga-solus> and pay for food there
[11:04] <mvo> zyga-solus: sure, I update the commit message and force push
[11:04] <zyga-solus> mvo: after lunch I can explore updating mount units in the field
[11:04] <zyga-solus> mvo: thank you!
[11:04] <zyga-solus> mvo: or get back to content
[11:04] <zyga-solus> mvo: I wonder what to do with 4008
[11:04] <zyga-solus> land it or wait until gustavo returns :/
[11:04] <zyga-solus> mvo: please think about it, it blocks everything I do for layouts/content
[11:05] <mvo> zyga-solus: yeah, lets talk priorities during the standup
[11:05] <mvo> zyga-solus: thanks, I will
[11:05] <popey> zyga-solus: how do i calculate the sha? (honestly)
[11:05] <popey> (on 16.04)
[11:07] <zyga-solus> I think it is tricky popey
[11:07] <zyga-solus> naive command returns bad data
[11:07] <zyga-solus> pedronis: ^
[11:07]  * zyga-solus AFK
[11:25] <pedronis> zyga-solus: that's what I asked him to do the sha is wrong
[11:25] <pedronis> we already know that
[11:25] <pedronis> zyga-solus: what I don't know if the file is shorter or some bytes are different
[11:25] <pedronis> I asked about that
[11:26] <pedronis> he managed to download the same file again and get the right stuff
[11:27] <pedronis> popey: the fix is easyish, stop snapd and any snap with daemons,  replace the file and reboot or start again... doesn't give us a clue how you got in that state though
[11:27] <pedronis> worst scenarios would be some kernel bug that writes back to a read-only squashfs :/    we obvisouly don't do any kind of writing to .snap files after downloading them
[11:31] <pedronis> popey: you could also try to see (before fixing) if you have other corrupt snaps
[11:33] <popey> how would I test every snap?
[11:34] <pedronis> popey: something like:  ls /var/lib/snapd/snaps/*.snap|xargs -n 1  snap info --verbose|grep -E "path|sha3-384"
[11:34] <pedronis> give you all the hashes
[11:34] <popey> sha3-384 doesn't exist on 16.04 AFAICT
[11:35] <pedronis> ?
[11:35] <pedronis> that's why I'm using snap info --verbose
[11:35] <popey> oh duh, sorry
[11:37] <popey> ok, so that dumps me out a bunch of snaps and sha3-384s, how do I know which are good/bad?
[11:43] <pedronis> popey: try to see which ones gives a match with snap known ---remote  snap-revision snap-sha3-384=SHA3-384
[11:44] <popey> that'll be fun with 90+ snaps installed :)
[11:44] <popey> Thanks.
[11:44] <popey> I could just switch channels then delete the broken snap I guess, and switch channel again to trigger a re-download?
[11:45] <pedronis> well if you switch channel with refresh it will download something new
[11:45] <pedronis> but it would be good to know if you have other broken snaps
[11:45] <pedronis> it's a bit scary this issue
[11:46] <popey> it didnt re-download
[11:47] <popey> i switched and switched back earlier, it used the local snap
[11:47] <kalikiana> sergiusens, kyrofa, elopio: FYI I'll be taking a late longer break in ~2h in place of my  lunch break, and working later tonight
[11:50] <pedronis> popey:  this one liner might work to do the check:  ls /var/lib/snapd/snaps/*.snap|xargs -n 1  snap info --verbose|grep "sha3-384:"|cut -c10-|grep -Eo "[^ ]*"|xargs -n1 -I {}  snap known --remote snap-revision snap-sha3-384={}
[11:52] <pedronis> popey: we do caching now, that might be related, mvo might know more
[12:04] <Odd_Bloke> sergiusens: Well, the first . is, sure.  Any later dots would surely be fine?
[12:18] <mvo> popey: what version of snapd are you running?
[12:21] <ogra_> mvo, hrm
[12:21] <ogra_> what happened to my PATH?
[12:22] <ogra_> ogra@styx:~$ echo $PATH
[12:22] <ogra_> /home/ogra/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/var/lib/snapd/snap/bin
[12:22] <mvo> ogra_: you mean thta there are two /snap/bin in there now?
[12:22] <ogra_> (where do the latter two entries come from all of a sudden ? this is xenial 2.28.5)
[12:23] <ogra_> /etc/profile.d/apps-bin-path.sh has not changed
[12:24] <mvo> ogra_: I would suspect https://github.com/snapcore/snapd/pull/3398/files#diff-ba91021c40c2949f09b89cbc853a17daR1 is the relevant PR, however why you have /var/lib/snapd/snap/bin is a bit strange
[12:24] <mup> PR #3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
[12:25] <ogra_> ogra@styx:~$ locate snapd.sh
[12:25] <ogra_> ogra@styx:~$
[12:26] <ogra_> hmm
[12:27] <ogra_> and definitely not in /etc/profile.d ...
[12:28] <ogra_> mvo, hmm, that last file in that PR looks suspiciously as if nothing gets installed to /etc/profile.d anymore (packaging/ubuntu-16.04/snapd.install )
[12:29] <ogra_> that smells wrong
[12:30] <mvo> ogra_: https://github.com/snapcore/snapd/pull/3398/files#diff-f86ccdfbe771a0164e1e0c116db70386R174 should do that now
[12:30] <mup> PR #3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3398>
[12:30] <mvo> ogra_: (i.e. line 174)
[12:31] <ogra_> mvo, thats debian/rules ... but the .install file explicitly doesnt install the dir
[12:31] <ogra_> also thats a conffile ...
[12:32] <ogra_> that would need some debhelper  postinst love, wouldnt it (to update the file on my disk)
[12:32] <ogra_> ogra@styx:~$ cat /etc/profile.d/apps-bin-path.sh
[12:32] <ogra_> # Expand the $PATH to include /snap/bin which is what snappy applications
[12:32] <ogra_> # use
[12:32] <ogra_> PATH=$PATH:/snap/bin
[12:33] <ogra_> i surely dont have the new file ... so it is still a bit beyond me where that PATH comes from
[12:34] <mvo> ogra_: check "wget https://launchpad.net/ubuntu/+archive/primary/+files/snapd_2.28.5_amd64.deb && (dpkg -c snapd_2.28.5_amd64.deb|grep etc/)" to see that the new file is in the package. what version of snapd are you running currenlty (apt list snapd and snap version) please?
[12:35] <mvo> popey: if it is the download cache thing that broke stuff, could you please pastebin "sudo ls /var/lib/snapd/cache"
[12:35] <mvo> popey: I wonder if that gives a hint
[12:37] <mvo> popey: also, do you still have the snap that has the wrong hash? if so, could you please put it somewhere so that I can download it?
[12:37] <popey> i do, one moment
[12:37] <mvo> popey: thank you
[12:38] <mvo> popey: and this all happend with 2.29~rc1 ?
[12:38] <mvo> popey: or a different version?
[12:39] <popey> core 3291
[12:39] <popey> so yes, 16-2.29~rc1
[12:40] <mvo> ta
[12:41] <popey> mvo: http://people.canonical.com/~alan/core_3291.snap
[12:44] <mvo> popey: ta
[12:44]  * ogra_ shakes fist at his DSL
[12:46] <ogra_> mvo, sorry, i got disconnected ... i dont have the new stuff in my /etc/profile.d here so i'm not sure where the additional PATH entries could come from ...
[12:46] <ogra_> also, my deb is still at 2.27.5 ...
[12:50] <mvo> popey: http://paste.ubuntu.com/25823191/ is what I found - I hexdumped both the snap download core --beta and your snap. the difference are 4 bytes (32bit) so I suspect corruption when writing to disk
[12:51] <popey> wow
[12:51] <mvo> ogra_: any hints in sudo grep -r var\/lib\/snapd\/snap\/bin /etc ?
[12:52] <pedronis> mvo: remember that we check the hash before mounting, so this happened after the first use
[12:53] <pedronis> mvo: the file was fine, and then later 4 bytes changed :/
[12:54] <mvo> pedronis: hm, we check the hash during the download (the hash from the data streaming via the download). do we check the on-disk file as well again? I vaguely remember we discussed this
[12:54] <pedronis> we do
[12:54] <ogra_> GRMBL ... whats up with my DSL
[12:54] <ogra_> mvo, did you get my last lines ?
[12:54] <mvo> yeah, in this case its more alarming, the file was fine on disk at least once then
[12:54] <mvo> ogra_: not sure, lsat that I wrote was: <mvo> ogra_: any hints in sudo grep -r var\/lib\/snapd\/snap\/bin /etc ?
 mvo, sorry, i got disconnected ... i dont have the new stuff in my /etc/profile.d here so i'm not sure where the additional PATH entries could come from ...
 also, my deb is still at 2.27.5 ...
[12:55] <ogra_> thats the last i typed
[12:55] <mvo> ogra_: yeah 2.28.5 is still in proposed
[12:55] <ogra_> right
[12:55] <ogra_> so i cant have the new stuff yet
[12:55] <ogra_> though i do have these PATH entries ... let me try that grep
[12:56] <ogra_> ogra@styx:~$ sudo grep -r var\/lib\/snapd\/snap\/bin /etc
[12:56] <ogra_> ogra@styx:~$
[12:56] <ogra_> nope
[12:57] <ogra_> /etc/nevironment looks normal too ... nothing in /etc/bash* or so ...
[12:57] <mvo> pedronis: you are right (of course :) - we download and then seek to zero and take the hash. then we rename. so the on-disk data was valid. unless of course we never read back from disk but instead linux just gave us what was in the memory cache. i.e. the bits on disk were wrong but because the file was fully in the cache we never read it back
[12:57] <pedronis> mvo: we do in validate-snap
[12:58] <pedronis> mvo: it's not a fun bug, unless popey has more general filesystem/disk issues
[12:59] <mvo> pedronis: could it be the same problem though? I mean, could it be that because its all in the linux disk cache we did not detect that the on-disk bits are wrong?
[12:59] <mvo> pedronis: i.e. linux itself never hit the disk to read it back in (because it was in the cache already)?
[12:59] <pedronis> mvo: could be, but darkest fear would be some obscure bug when the kernel decide to write back to the squashfs for reason
[13:00] <mvo> pedronis: yeah, that would be *wuuuarh* :)
[13:02] <pstolowski> standup?
[13:10] <mup> PR snapcraft#1641 opened: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>
[13:23] <zyga-solus> mvo: your PR fails tests
[13:28] <zyga-solus> mvo: I think some tests failed (unit test)
[13:28] <zyga-solus> does go test in systemd/ works?
[13:28] <mvo> zyga-solus: checking
[13:29] <pedronis> mvo:  this is topic: https://forum.snapcraft.io/t/snapcraft-unable-to-install-core-snap/2599 btw
[13:34] <mvo> pedronis: thank you
[13:43] <ryebot> snapcraft.io down?
[13:45] <mvo> ryebot: looks like it :/
[13:45] <ryebot> kk thanks
[13:48] <mvo> ryebot: looks like more infra is affected :/
[13:48] <ryebot> yeah, just failed to hit jujucharms as well
[13:48] <ryebot> whee
[13:50] <zyga-solus> darn
[13:50] <zyga-solus> tests cannot run now
[13:50] <mvo> weeeh :(
[13:51] <zyga-solus> mvo: also does --resend cache core snap?
[13:51] <mvo> zyga-solus: uh, I don't know
[13:58] <ryebot> looks like things are back up
[14:05]  * kalikiana back later
[14:09] <mup> PR snapd#4077 closed: spdx: fix for WITH syntax, require a license name before the operator <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4077>
[14:12] <mup> PR snapd#4071 closed: release: merge 2.29~rc1 changelog <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4071>
[14:16] <mup> PR snapd#4061 closed: daemon, store: forward SSO invalid credentials errors as 401 Unauthorized responses <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4061>
[14:17] <mup> PR snapd#4055 closed: daemon: generate a forbidden response message if polkit dialog is dismissed <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4055>
[14:18] <mup> PR snapd#4050 closed: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4050>
[14:18] <mup> PR snapd#4053 closed: tests,po: sync translations from LP and add regression test for LP:1723974 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4053>
[14:18] <mvo> yay, back to 25 open PRs!
[14:22] <mvo> jdstrand: a second review for 4054 would be great. I applied your feedback
[14:24] <jdstrand> mvo: ok
[14:25] <jdstrand> mvo: is the xdg-settings one ready for me to review again?
[14:25] <jdstrand> mvo: also, I'm going to have another policy updates PR that I'd like to get into 2.29. if I submit to master and 2.29, will that be a problem?
[14:27] <mvo> jdstrand: the xdg-settings one is not yet ready, need to address the open point about info disclousure
[14:34] <jdstrand> mvo: 4054 approved. did you see my question about 2.29?
[14:34] <mvo> jdstrand: I have not seen your question
[14:34] <mvo> jdstrand: 4060 is also ready (review points addressed)
[14:35] <jdstrand> 09:25 < jdstrand> mvo: also, I'm going to have another policy updates PR that I'd like to get into 2.29. if I submit to master and 2.29, will that be a problem?
[14:36] <jdstrand> 4060 was already on my list for today. let me take a look now
[14:36] <pedronis> jdstrand: what impact on preexisting snaps will that policy change have?
[14:38] <jdstrand> pedronis: only more access
[14:39] <mvo> jdstrand: if you submit to master and tag 2.29, that should be fine
[14:39] <jdstrand> mvo: ok thanks. need to get out from under PR reviews and forum discussions, then will submit. striving for eod tomorrow
[14:40]  * jdstrand crosses fingers
[14:40] <mvo> ta
[14:40] <mvo> jdstrand: no worries we have still some critical 2.29 prs pending so no worries
[14:46] <jdstrand> mvo: 4060 done (note, see my comment on missing assert)
[14:50] <mvo> jdstrand: ta
[14:51]  * mvo takes a short break while waiting for tests
[15:40] <pstolowski> pedronis, mvo added help for --long options to 4080, can you take a quick look and let me know wdyt?
[15:40] <pedronis> in a bit
[16:02] <pedronis> pstolowski: commented
[16:02] <pedronis> I have no idea if it's ok to refer to systemd there or not
[16:03] <pstolowski> pedronis, thanks, I've just fixed caitalization.
[16:03] <pstolowski> pedronis, yeah, me neither, but it's difficult not to since we depend so much on i
[16:03] <pstolowski> *it
[16:08] <pstolowski> mvo, your thoughts on that? ^
[16:36] <zyga-solus> re
[16:36] <zyga-solus> I'm still AFK, working with kids
[16:36] <zyga-solus> jdstrand: hey, how's life?
[16:36] <zyga-solus> jdstrand: no updates from me yet, I think we will see a PR tomorrow though
[16:58] <mup> Bug #1727787 opened: segmentation fault <Snappy:New> <https://launchpad.net/bugs/1727787>
[17:06] <gsilvapt> elopio, you around=
[17:06] <gsilvapt> s/=/?
[17:09] <elopio> gsilvapt: yes. Hello
[17:09] <gsilvapt> Can I talk to you via pvt?
[17:10] <gsilvapt> elopio ^ (I can forgetting to reference people, sorry :P )
[17:13] <elopio> gsilvapt: sure.
[17:24] <jdstrand> zyga-solus: hey, things going fine here. just trying to get through the PR reviews and forum discussions. how about you?
[17:48] <zyga-solus> jdstrand: trying to catch up with my son's classes and all the things he needs to learn in this school; otherwise pondering about overlayfs, I may have made a mistake and not realized it
[17:49] <zyga-solus> jdstrand: but no conclusions yet, I just realized something but I didn't finish investigating
[19:50] <mup> Bug #1727787 changed: segmentation fault <Snapcraft:New> <https://launchpad.net/bugs/1727787>
[20:41] <kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64
[20:41] <snappy-m-o> kyrofa: I've just triggered your test.
[20:50] <kyrofa> elopio, I've seen this error several times now<EMAIL_ADDRESS>[20:50] <kyrofa> plainbox test failing, unable to find pyramid
[20:51] <kyrofa> And ROS ones, looks like
[20:51] <elopio> Mmm, let me see...
[20:52] <kyrofa> elopio, wait, no-- plainbox has a valid-looking match error
[20:52] <kyrofa> Like something changed out from under us
[20:52] <kyrofa> 2013.com.canonical.plainbox::collect-manifest versus no 2013
[20:52] <kyrofa> But the ROS ones suddenly can't find pyramid
[20:57] <kalikiana> kyrofa: I realized I hadn't actually approved snapcraft#1637 but this is good to go
[20:57] <mup> PR snapcraft#1637: repo: add elementary to deb distros <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1637>
[20:58] <jdstrand> stgraber: hey, I see this denial: apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=10047 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[20:59] <jdstrand> stgraber: you can fix that by plugging 'system-observe' in the lxc command
[21:10] <nanodrone> is snappy installable on puppylinux?
[21:13] <stgraber> jdstrand: why would I need that though?
[21:13] <stgraber> jdstrand: snap.lxd.lxc runs through "aa-exec -p unconfined"
[21:13] <stgraber> jdstrand: the line above seems to indicate that it's "snap-exec" which is attempting to read that file, not our script, so it'd point to a profile issue for snap-exec rather than lxc
[21:32] <elopio> kyrofa: pyramid is not on debian/tests/control for snapstests.
[21:32] <elopio> What I don't know is what changed to require it now.
[21:32] <kyrofa> elopio, huh, no kidding
[21:45] <elopio> kyrofa: you are adding a dependency on the integration tests with that skip_unless_codename
[21:45] <kyrofa> elopio, ohhhhhhhh
[21:45] <kyrofa> Dangit!
[21:46] <elopio> to be honest, I dislike the skip annotations. But, with my refactor on the suites, you would be able to put it in snapcraft/tests/skips, and just import that.
[21:46] <elopio> actually, you could do that right now, no need to wait.
[21:46] <kyrofa> elopio, you mean you don't like the decorators?
[21:47] <elopio> for the plainbox thing, I'll report a bug for joc to see. It's late for him, and I'm not sure if we can just update the expected result.
[21:47] <elopio> kyrofa: yes, the decorators.
[21:47] <kyrofa> elopio, you'd rather be using self.skipTest or whatever in the body of the test?
[21:47] <kyrofa> I feel like that adds code to the test that has nothing to do with the test
[21:48] <elopio> that is more readable to me. I'm not strongly opposing to the decorators, I just don't like them.
[21:54] <kyrofa> elopio, so to be clear, you want me to create a new snapcraft/tests/skips.py and put the skip code in there, then import from there for both the integration_tests and the units?
[21:55] <elopio> kyrofa: yes, I think that's the future. Things common will go in there, things specific will go in snapcraft/tests/unit or snapcraft/tests/integration.
[21:56] <kyrofa> elopio, good deal
[21:56] <kyrofa> elopio, and yeah, that was my favorite part of your refactor
[21:57] <elopio> my favorite part is when we get rid of snaps_tests completely. I will use this chance to move the plainbox test.
[21:58] <elopio> kyrofa, can you land snapcraft#1630 ?
[21:58] <mup> PR snapcraft#1630: tests: allow to select a suite when running autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1630>
[21:58] <elopio> I want to start experimenting with the adt-lxd.
[22:06] <kyrofa> elopio, sure thing-- done
[22:07] <elopio> :D
[22:09] <mup> PR snapcraft#1630 closed: tests: allow to select a suite when running autopkgtests <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1630>
[22:09] <mup> PR snapcraft#1637 closed: repo: add elementary to deb distros <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1637>
[22:18] <kalikiana> 3 more to go til we can release :-D https://github.com/snapcore/snapcraft/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.35
[22:23] <kyrofa> kalikiana, still need autopkgtests to pass...
[22:24] <kyrofa> plainbox seems busted


[13:10] <ZenoArrow> Hi. Trying to boot Lubuntu into command line (no X). Have held down shift to get to GRUB. Where do I go from here?
[15:50] <follower> hey does anyone know if xfburn supports disc spanning?
[19:37] <piepiepie> hello, lightdm is stuck in a loop
[19:38] <genii> piepiepie: It kicks you back when you try to login?
[19:40] <piepiepie> I do not get the login prompt. In /var/log/lightdm/x-0-greeter.log I read: Failed to register client: GDBus.Erro:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service file
[19:40] <piepiepie> Unable to register client with session manager
[19:41] <piepiepie> XIO: fatal IO error 11 (Resource temporarily unavailable) on X server  ":0"
[19:41] <piepiepie> GConf Erro: Failed to activate configuration server: Connection closed
[19:42] <genii> Hm. No idea on that one, I haven't seen it yet.
[19:42] <piepiepie> I tried to remove and reinstall lubuntu -desktop
[19:42] <piepiepie> no luck with that
[19:42] <piepiepie> the other log files seem to contain no errors...
[19:44] <piepiepie> Is there an alternate display manager that I could try?
[19:44] <piepiepie> Like xdm or gdm?
[19:47] <genii> piepiepie: Which lightdm greeter do you have currently installed?
[19:48] <piepiepie> unity-greeter 12.10.4 UID=105 LANG=en_US.UTF-8
[19:49] <genii> piepiepie: Perhaps lightdm-gtk-greetr
[19:49] <genii> greetr->greeter
[19:50] <Unit193> And you do have lubuntu-default-settings?
[19:51] <piepiepie> yes, lightdm-gtk-greeter is installed
[19:51] <piepiepie> this is a fresh installation of lubuntu 12.10.4
[19:51] <piepiepie> it got stuck in the loop at the first boot
[19:52] <piepiepie> lubuntu-default-settings is installed too
[19:52] <Unit193> I'd try something current, meaning 13.04.
[19:53] <piepiepie> yes I could try that
[19:53] <piepiepie> do you know how to start xdm? I just installed it...ù
[19:53] <Unit193> But, another DM is LXDM.  I'd still recommend upgrading.
[20:00] <piepiepie> there is a segmentation fault in /usr/lib/xorg/modules/drivers/sis_drv.so
[20:00] <piepiepie> I'll try upgrading to 13.04
[20:01] <Unit193> Well thta's not good..
[23:08] <malaphus> Hello, I copied my /etc/network/interfaces file over from an older ubuntu 11.04 machine to a new lubuntu 13.04 machine and none of my "up route add" commands seem to work anymore, any ideas why?
[23:09] <holstein> malaphus: mabye just check in on the changes that have been made and redo the config to match current requirements
[23:10] <malaphus> holstein: the only thing that I seemed to need to change was eth0 -> p5p1, which I did
[23:10] <malaphus> if I run the route add commands manually they work


[08:05] <dpm> good morning all
[08:06] <noodles775> Hey there dpm
[08:06] <dpm> hey noodles775, good morning :)
[09:39] <rigved> hi everyone. i am using 12.04 and quickly. i was following the quickly tutorial, but i have come across a problem: http://paste.ubuntu.com/834986/
[09:41] <rigved> the quickly tutorial says that i should provide only the start and the end iter for the TextView widget's TextBuffer.
[09:41] <rigved> but the error tells me otherwise. can anyone help regarding this?
[09:42] <dpm> hi rigved, which tutorial are you following?
[09:44] <rigved> i typed the quickly tutorial on the cli
[09:45] <dpm> rigved, let me try to reproduce it to see if I can help
[09:46] <rigved> dpm: i was checking http://www.pygtk.org/docs/pygtk/class-gtktextbuffer.html#method-gtktextbuffer--get-text.
[09:47] <rigved> there is a third attribute: include_hidden_chars
[09:48] <rigved> i just now included it in the function call and it worked.
[09:49] <dpm> rigved, ah, cool :)
[09:50] <rigved> dpm: so, it seems like the textbuffer api has changed, right? should i file a bug?
[09:51] <dpm> rigved, I think a bug to update the tutorial would be useful, yes. Which part in the quickly tutorial mentions these arguments?
[09:52] <rigved> dpm: Quickly 11.12 User Guide > Getting Started > Here's the code to get pull the text out of the TextView
[09:53] <rigved> dpm: it's the part where the note data is retrieved from the TextView's TextBuffer.
[09:54] <rigved> dpm: also, i just now noticed that there is a grammatical mistake here: "Here's the code to get pull the text out of the TextView" should be "Here's the code to get/pull the text out of the TextView" or something like that...
[09:56] <rigved> dpm: so, should i file a bug against quickly or is there a separate package for quickly tutorial?
[09:57] <dpm> rigved, thanks, yeah, a bug would be really helpful. Afaik there is only one quickly project, so if you fire up a terminal and run 'ubuntu-bug quickly', it should take you to the right project
[09:59] <rigved> dpm: ok. thanks!
[09:59] <dpm> no worries, thank you!
[10:15] <rigved> bug 929417
[10:15] <ubot2> Launchpad bug 929417 in quickly "Quickly tutorial contains wrong gtk.TextBuffer.get_text function call" [Undecided,New] https://launchpad.net/bugs/929417
[10:16] <rigved> bug 929420
[10:16] <ubot2> Launchpad bug 929420 in quickly "Quickly tutorial contains grammatical mistake" [Undecided,New] https://launchpad.net/bugs/929420
[10:17] <dpm> awesome, thanks rigved!
[10:22] <rigved> dpm: np
[19:26] <arslanatajanov> Hello. Are there any Python devs here?
[19:31] <jo-erlend> arslanatajanov, yes, but I'm sure that's not really what you'd like to know. :)
[19:31] <jo-erlend> just blurt out your question and see if someone answers. People aren't always looking at their screens. :)
[19:33] <arslanatajanov> Thank you for your prompt reply....Yes, I seek advise...
[19:34] <arslanatajanov> I have just finished reading couple books about Python 2.x and 3.x...And I want to start "a little project"...
[19:35] <arslanatajanov> Let say I am still new to Python but can do something that is working :)
[19:37] <jo-erlend> in that case, it doesn't really matter which one you begin with. Python 3 is the way forwards, but it has less libraries to play with.
[19:39] <jo-erlend> they aren't radically different. If you learn Python 2 first, then you might get a few bad habits, but other than that the languages are the same. You can start to use mostly Python 3 syntax in Python 2 as well.
[19:39] <jo-erlend> for instance, don't get used to writing things like: print "Test". That won't be allowed in the future, so get used to writing print("Test"), etc.
[19:40] <arslanatajanov> So back to my "project"... I am a Biomedical Science student and Computer Science student....And I have noticed that people who are studying with me experience difficulties in finding short and "highly understandable" definitions for various scientific words and phrases...And I thought if it would be possible to create a piece of software which contains a set of short definitions for a large number of scientific termin
[19:42] <jo-erlend> there is a collection of those... But what is it called?
[19:44] <jo-erlend> oh, I misread. I don't know of anything exactly like that.
[19:45] <jo-erlend> arslanatajanov, I think that sounds like a cool project. How do you intend to deliver the application, via a browser or a native desktop experience?
[19:48] <arslanatajanov> Via native experience, (and If it is going to be successful I would like to add different features that will need internet connection, I've came up with a whole list of possible features, so its too long to write) :)
[19:49] <arslanatajanov> I also know C# and have experience in .NET....So i dont know, what to choose, if I choose C# then i'll need to stick to Windows for a long time...but I really like Ubuntu and want to make something on this platform
[19:51] <jo-erlend> You can develop in C# in Ubuntu using Mono. Or you can use Vala, which is very similar to C# but very much faster and built for Gnome.
[19:51] <arslanatajanov> and I wish to use Python because it is more or less portable
[19:51] <jo-erlend> Python is a beautiful language.
[19:51] <arslanatajanov> Yes ive heard of it...but I like Python :)
[19:52] <arslanatajanov> I would really appreciate if you will provide me with links to some resources with Python apps
[19:53] <arslanatajanov> I couldn't find any descent resources on the web by myself
[19:57] <jo-erlend> arslanatajanov, I would look at http://developer.ubuntu.com.
[19:57] <jo-erlend> http://docs.python.org/tutorial is nice.
[19:58] <jo-erlend> of course, there are plenty of apps in Ubuntu itself. Ubuntu One, for instance.
[19:58] <arslanatajanov> Hmm..Ok Thank you...Hope I will get something descent in near future. :)
[19:59] <arslanatajanov> But I really want to implement it..
[19:59] <jo-erlend> :)
[19:59] <jo-erlend> http://python-gtk-3-tutorial.readthedocs.org/en/latest/
[19:59] <arslanatajanov> Ok...Thank you again...bye..
[20:00] <jo-erlend> that's a good one for Python and GTK3 apps.
[20:00] <arslanatajanov> wow..that last link seems cool
[20:01] <arslanatajanov> I was looking for something like this
[20:01] <arslanatajanov> thanks
[20:01] <jo-erlend> Quickly is the first thing you should look at.
[20:01] <jo-erlend> it gets you up and running in minutes.
[20:01] <arslanatajanov> ok...need to go...thanks...I've looked at it...and glade...and created couple simple programms
[20:02] <arslanatajanov> bye