[00:02] <vila> mathrick: file a bug and find jelmer ;) There is probably a text file you can edit somewhere which contains the windos path.
[00:03] <jelmer> mathrick: is this with the core bzr support for colocated branches, or with bzr-colo ?
[00:03] <mathrick> jelmer: I dunno, 2.5.1, created via bzr-explorer with "colocated workspace" option
[00:04] <jelmer> mathrick: ah, that's the bzr-colo plugin
[00:04] <jelmer> mathrick: please file a bug, but against the bzr-colo project on Launchpad
[00:05] <mathrick> is that really a bug in bzr-colo?
[00:05] <vila> jelmer: well dodged ;)
[00:05] <vila> mathrick: more or less
[00:05] <jelmer> vila: :-)
[00:06] <mathrick> OK, how should I describe it? Since I have no clue how that is a problem with bzr-colo and not bzr reconfigure for instance
[00:06] <vila> mathrick: zip is not a transport supported by bzr ;) So you run into some absolute paths that may be better handled as relative (but obviously are  not (yet ?))
[00:07] <vila> mathrick: what you explained here is good enough: zipped on windos, unpacked on linux
[00:08] <vila> mathrick: it may be interesting to see if the reverse breaks in the same way (zipped on linux, unzipped on windoz)
[00:08] <vila> dows
[00:08] <vila> damn tyops
[00:09] <mathrick> vila: I understand that, what I don't understand is how bzr-colo breaks things. Bzr reconfigure should be able to change that path
[00:10] <vila> mathrick: well, the point is that bzr-colo doesn't really break things, it assumes the working trees/branches/repos would stay on the same files system (roughly)
[00:11] <jelmer> mathrick: bzr-colo stores an absolute path to the colocated branch, rather than a relative one; bzr reconfigure tries to open the old branch when it reconfigures I think
[00:11] <mathrick> that is a problem with reconfigure then, no?
[00:11] <vila> mathrick: I suspect that there should be some way to bzr-colo push instead of zip/unzip that should work
[00:11] <mathrick> yes, there is
[00:12] <mathrick> I just didn't remember I made it collocated when I zipped
[00:12] <jelmer> mathrick: bzr-colo should be storing a relative path
[00:12] <vila> mathrick: bzr reconfigure assumes it starts with a "correct" context, it may be worth filing a different bug for that
[00:12] <jelmer> mathrick: you might be able to use --force to get reconfigure to ignore the old code
[00:13] <mathrick> ah, I didn't notice --force wasa thing
[00:13] <vila> jelmer: good point (dunno if this will work but it should ;)
[00:14] <mathrick> nope, --force only seems to influence potentially losing local changes
[00:14] <vila> but in this specific case, if the branch is required, it's hard to ignore it
[00:14] <vila> mathrick: you tried or you just read the --help ?
[00:15] <mathrick> tried
[00:15] <vila> thanks
[00:15] <vila> mathrick: did you try to grep for that path under .bzr ?
[00:16] <mathrick> no, but I expected to be able to change it by hand
[00:16] <mathrick> I was asking for the proper way
[00:17] <vila> mathrick: for this case, I doubt there is one (or that would be bzr-colo push)
[00:18] <fullermd> Pfft, proper.  What fun is that?
[00:18] <vila> mathrick: but really, as jelmer said, bzr-colo should use a relative path (that may not be enough but should help anyway)
[00:18] <mathrick> vila: bzr-colo push is "how do I transport it properly?". But I didn't, and now my question is "how do I fix it?". Bzr reconfigure *should* be able to fix that, and I will file a bug too
[00:19] <vila> mathrick: worth a try, but if there is a single place where the branch path is defined and it's broken, bzr reconfigure can't guess the right one
[00:20] <mathrick> why not? bzr info tells me what the checkout thinks the source branch is. That is what bzr reconfigure is supposed to change; if it tries to open it before changing, it's kinda useless for fixing things
[00:21] <vila> mathrick: it can avoid opening it (it's broken after all) but what will it use instead of that broken path ?
[00:21] <mathrick> the one I give it in --bind-to?
[00:22] <vila> mathrick: oh, well done !
[00:22] <vila> for this specific case indeed, not sure if the code will make it easy to implement but file-a-bug++
[00:24] <mathrick> done, bug #1076809 and bug #1076810
[00:25] <vila> mathrick: thanks
[00:25] <mathrick> sure
[00:55] <vila> fullermd: linked a branch with reproducing failing tests for bug #1072513, one step closer to diagnosis ;-p
[00:57] <vila> fullermd: you may want to look at the intermediate commits to see how I get there from your script (including revno 6515 where 'bzr test-script ./bzrlib/tests/blackbox/log_bug_1072513.sh  --null-output' was passing)
[00:58] <vila> fullermd: the missing feature still being to be able to keep the built env to toy around manually with the results :-/
[00:59] <vila> but at least the syntax should be copy/pastable enough for you to tweak
[01:00] <mgrandi> is there a preferred way to backup a repository to a file, or is just zipping the directory pretty much
[01:00] <vila> mgrandi: <cough> ask mathrick ;)
[01:01]  * mgrandi asks mathrick
[01:01] <vila> mgrandi: if you really want a *backup* 'bzr push' should be the fastest
[01:02] <mgrandi> im just sending my code to someone, including the repo for archival purposes
[01:02] <vila> mgrandi: sorry, that a was a joke, mathrick just ran into an issue while zipping on windows and unzipping on linux (special setup where an absolute path has been recorded)
[01:02] <mgrandi> interesting o.o
[01:02] <vila> mgrandi: same os on the receiving side ?
[01:03] <mgrandi> stack overflow says this; http://stackoverflow.com/questions/1976857/bzr-create-tgz-file-containing-full-repository
[01:03] <mgrandi> might not be
[01:03] <vila> bzr send is safest
[01:03] <mgrandi> what does bzr send actually do? generate patch files?
[01:04] <mgrandi> so this just creates a series of patch files or something?
[01:04] <vila> mgrandi: almost, they are called merge directives and contains both the revisions and a human-readable patch
[01:04] <vila> mgrandi: it's not lossless as patches can, you get the real revisions
[01:05] <mgrandi> interesting, thanks
[01:05] <vila> mgrandi: the idea is that send accept a public url readable by both sides and create the delta between your branch and the public branch
[01:06] <vila> mgrandi: so it can be *far* smaller than zipping the whole repo (like the stackoverflow recipe suggests)
[01:06] <mgrandi> yeah, this isn't a problem here but i was just curious
[01:07] <vila> mgrandi: the recipe basically uses an empty branch as a starting point
[01:07] <mgrandi> so are there problems with zipping a bzr branch directory and then using it on a different os?
[01:07] <vila> mgrandi: not a bzr branch, a bzr-colo environment (plugin)
[01:08] <mgrandi> isn't that integrated into bzr now?
[01:08] <vila> there is wip about native colocated branches yes, that's different
[01:09] <mgrandi> but normal branches should be fine? besides the whole symlinks thing
[01:09] <mgrandi> that i still need to work on...
[01:09] <vila> yes
[01:10] <vila> but it's been a looong time since I did that myself, most of the machines I'm working on have ssh and bzr so it's easier to kust push ;)
[01:10] <vila> *just
[01:11] <fullermd> Obviously, the solution is that somebody needs to donate vila a machine without ssh or bzr on it, to force him to work on it   :p
[01:12] <vila> fullermd: the last case was a windows vm where I managed to install ssh as a service anyway ;)
[01:12] <fullermd> I've probably got some OS/2 install media somewhere...
[01:12] <vila> fullermd: and if they don't have ssh but bzr, well, it's easy enough to pull instead of pushing ;-)
[01:14] <fullermd> vila: So, wait, you already fixed it, then re-broke it?  I mean, if the test was passing, that means everything's good, right?   :p
[01:17] <vila> hehe, that's where the test scripts shine: they can express failure more easily ;)
[01:19] <fullermd> 'druther they expressed success   ;p
[01:21] <vila> tsk, tsk, they allow success to be *demonstrated*, that's TDD for you ;)
[01:22] <fullermd> I dunno, TDD sounds like something I'd discuss with my doctor in a hushed voice.
[01:24] <mgrandi> depends on who you ask. they really beat it into us at my school
[01:24] <mgrandi> =P
[01:25] <fullermd> Well, yes, I remember that from high school too, but...
[01:25] <mgrandi> unit test ALL THE THINGS
[01:26] <vila> Alzheimer, Pratchett and I.. what was it I wanted to say...
[01:26] <mgrandi> so vila, i just tried that recipe out, and it seems useless cause you can't merge the file back into an empty repo =/
[01:26] <vila> ha yes, tests are good substitute for failing memory
[01:26] <jelmer> mgrandi: you can pull it into an empty repo though
[01:27]  * jelmer wonders if vila is in the US
[01:27] <fullermd> I do wish I had regression tests for stuff at work.  Sadly, I've never heard a good story for writing something useful considering the depth of stuff that breaks.
[01:27] <vila> jelmer: hehe, no ;)
[01:27] <jelmer> ... or just up late :-)
[01:27] <mgrandi> then the documentation for send is slightly out of date
[01:27] <vila> jelmer: yeah :-} Bad vila, go to sleep
[01:27] <mgrandi>  `bzr send` creates a compact data set that, when applied using bzr merge, has the same effect as merging from the source branch.
[01:27] <fullermd> No, but using it to replicate whole histories is out of the scope of the docs.
[01:27] <mgrandi> well it should still be mentioned that pull can be used as well
[01:28] <fullermd> And it does; merging the source branch into a branch with no history will also fail  ;p
[01:28] <mgrandi> 'using bzr merge or pull, has the same effect etc
[01:29] <vila> mgrandi: that's supposed to work, there may be a bug for *empty* branches (worth filing too, I thought we nailed down all the empty-branch-are-special ones...)
[01:29] <mgrandi> well it specifically gave a bug url when i tried to do it
[01:30] <vila> which one ?
[01:30] <mgrandi> bzr: ERROR: Merging into empty branches not currently supported, https://bugs.launchpad.net/bzr/+bug/308562
[01:31] <mgrandi> dang 5 years, old bug
[01:32] <vila> helllo, someone remember the shortest workaround for that ?
[01:32] <vila> 'bzr init . ; bzr pull <merge-directive>' ?
[01:33] <mgrandi> well yeah thats what i did
[01:33] <vila> good, my job here is done ;)
[01:35] <mgrandi> is that merge into empty repo a particuarly hard bug?
[01:36] <fullermd> I've never been quite clear as to what it's even supposed to _mean_.
[01:36] <mgrandi> probably along the lines like, its trying to merge two histories but one doesn't exist so it breaks?
[01:38] <fullermd> Yeah, the whole point of merge is "take these two separate things and bring them together", so how's it even meaningful to talk about when there's only one thing?
[01:38] <vila> I think the issue is about root-ids (branches of the same project shares a unique id for their root)
[01:38] <mgrandi> well, it still seems to me that bzr should be smart about that, and if one history just doesn't exist, then just take the other one
[01:38] <vila> the first branch of a project gets a new root-id which is then duplicated
[01:39] <vila> mgrandi: devil is in the details
[01:39] <mgrandi> i imagine
[01:39] <vila> the fact that it's a corner case rarely encountered didn't help raise the bug importance
[01:40] <vila> most of the issues are probably already solved, time is lacking for that one
[01:41] <fullermd> Well, taking the other one is "pull"  ;p
[01:41] <fullermd> If I wanted "merge" to sometimes silently do a "pull" instead, I'd use git...
[01:41] <mgrandi> haha.
[01:42] <mgrandi> maybe the error message should be updated to say 'try pull instead?"
[07:36] <gmarkall> i'm having trouble rebasing a branch. I'd like to rebase the last five revisions onto another branch, but i can't seem to work out how to tell bzr that's what i want to do - i only seem to be able to rebase "all but the last 5" with -r last:5. Is there a way to do this please?
[07:37] <bob2> you mean you're using bzr-rewrite?
[07:37] <gmarkall> (if I don't specify a revision then bzr wants to rebase 54 revisions, which includes a lot of duplicate changes)
[07:37] <gmarkall> bob2: i think i am
[07:37] <gmarkall> bzr help rebase says "From: plugin "rewrite""
[07:41] <lifeless> gmarkall: you might try -r -5:..
[07:43] <gmarkall> lifeless: that gives me "Bzr has encountered an internal error..." - shall I submit a bug report?
[07:43] <lifeless> sure
[07:43] <fullermd> Without the colon, probably...
[07:43] <lifeless> oh heh, yes.
[07:43] <lifeless> EOUTOFPRACTICE
[07:43] <lifeless> gmarkall: -r -5..
[07:44] <gmarkall> ah, that didn't crash bzr! :-)
[08:08] <gmarkall> I managaed to get the crash down to a small example: https://bugs.launchpad.net/bzr/+bug/1076894
[08:10] <gmarkall> I managed to choose the correct revisions with the syntax suggested by lifeless/fullermd - however, when i run with --dry-run, the commit ids that it shows are printed out-of-order - is that to be expected?
[08:16] <gmarkall> when i actually did the rebase, the commits were applied in the correct order
[09:03] <mgz> morning!
[09:06] <tbf__> can i tell bzr to just commit the changes of a conflict free merge?
[09:06] <tbf__> constantly forgetting that commit and then messing up stuff
[09:07] <tbf__> (well, also lack the creativity to invent merge commit messages)
[09:17] <tbf__> ok. why would "bzr diff ../parent" show changes that a plain "diff -ru ../parent" doesn't see?
[09:18] <tbf> apparently i still fundamentally fail in understanding things
[09:27] <mgz> tbf: could be lots of reasons for the diff not being the same, fundamentally those two commands look at different stuff
[09:28] <mgz> so, for instance, if the working tree of ../parent is not up to date, plain recursive diff will not see the later revisions
[09:32] <tbf> mgz, ../parent is up-to-date
[09:33] <tbf> mgz, at least the output of "bzr status" and "bzr diff" in ../parent is empty
[09:35] <tbf> mgz, seems i seriously fail to understand even the basics of  bzr: http://nopaste.me/paste/111230873509cce1382789
[09:36] <tbf> mgz, how can it be, that rev 334 contains changes from 316.1.64, while rev 333 is entirely empty?
[09:37] <tbf> 316.1.64 is the last commit in that merge
[09:38] <tbf> i'd only expect to see that change in 334 if i'd reverted 316.1.64 by accident while commiting 333
[09:47] <mgz> ...that paste site is borked, gives 406 + error fallout based on UA string
[09:48] <mgz> tbf: from that log, I'm not sure what's suprising you
[09:49] <tbf> mgz, the output of "bzr diff -c 334 debian/control" entirely surprises me
[09:49] <mgz> the diff for -r331..332 is empty, but the log above stops at 332 so that might be right, and 316.1.64 was merged in 333
[09:50] <mgz> tbf: that command isn't in the paste
[09:50] <tbf> mgz, line 51
[09:51] <tbf> mgz, rev 333 already should have that change, but bzr shows it was applied again in 334
[09:51] <mgz> I suspect you have some funny history
[09:52] <mgz> you remerged the same branch in 334?
[09:53] <tbf> mgz: forgot to commit a merge, shelved the mess. merged from parent again, unshelved.
[09:53] <tbf> expecting that only the really new changes would get applied
[09:54] <tbf> now bzr even crashes when accessing that branch
[09:54] <tbf> great.
[09:54] <mgz> okay, so the history and log/diff output is probably correct
[09:54] <tbf> apparently "bzr switch -r 333" was a stupid idea
[09:55] <tbf> mgz, how that?
[09:55] <mgz> r333 includes the merge, and the history of the other branch, but none of the actual changes
[09:55] <mgz> which you shelved, then committed in 334
[09:56] <mgz> so, log tells you 333 merged stuff, but diff only sees the changes when you actually committed them in 334
[09:56] <mgz> the best thing to get out of trouble here is just make a new branch from 332 and do the merge right this time
[09:57] <tbf> mgz: "r333 includes the merge, and the history of the other branch, but none of the actual changes" - this makes absolutely no sense to me.
[09:57] <tbf> maybe too much in git mind set. what stone i don't see?
[09:57] <mgz> you merged the history from the other branch
[09:57] <mgz> but left the actual text changes uncommitted
[09:57] <mgz> it's the same as doing that in git.
[09:57] <tbf> well. in git i usually rebase
[09:58] <tbf> and stay away from merges
[09:58] <tbf> too much vooodo
[09:58] <tbf> voodoo and magic
[09:58] <mgz> you like having a nice linear world view :)
[09:59] <tbf> mgz, yup :-)
[09:59] <mgz> anyway, the point of version control is you have the old stuff still
[09:59] <mgz> so you can just start from where you were originally and do it right, rather than trying to fix up the current state
[10:00] <tbf> mgz, sure. still at the point of merging a feature i don't care about the dirty details anymore
[10:00] <tbf> all that merging zig-zack and so on
[10:01] <mgz> look, it's easy, do this:
[10:02] <tbf> as long as i work on the features i highly appreciate having different branches and switching between them comparing them, letting them divert, pick changes and so on...
[10:02] <tbf> ...but once it is done. it is done.
[10:04] <mgz> cd .. && bzr branch -r332 old new && bzr merge -r 332.. -d new ../old
[10:05] <mgz> you then have a new branch, with the just the text changes you made in the last few revs ready to commit, and no hisotry to confuse you
[10:05] <mgz> you could bring in the original feature branch as a merge to make the history correct, but you probably don't care about that
[10:06] <mathrick> so how do install libraries needed by plugins in a standalone windows install?
[10:06] <mathrick> I thought it was $plugindir/lib/, but that doesn't seem to work
[10:07] <mgz> mathrick: what I did was use not use the windows standalone installers but the python ones and install all the plugins and bits I wanted via the normal setup.py method
[10:08] <mgz> there was a thing added for the standalone ones to look in another location for libs though
[10:08] <tbf> mgz, checking what this does...
[10:09] <mathrick> mgz: I tried that before, but it's a huge PITA really and never works quite as well as the standalone installer
[10:10] <mgz> mathrick: try
[10:10] <mgz> $ BZR_PDB=1 bzr assert-fail
[10:10] <mgz> (Pdb) sys.path
[10:10] <mgz> which will tell you where the installed bzr looks for stuff
[10:10] <mathrick> ah, good idea
[10:11] <mathrick> ah, so site-packages has been added
[12:13] <lolek> hello all
[12:13] <lolek> a question, i've installed bzr-eclipse, and i'm looking for option: compare with latest from repository ... that is available when using svn but with bzr repo ?
[12:15] <lolek> hmm ok, forget the question, found it, but the is only: compare with latest from branch, what if i want to specify revision ?
[12:59] <jelmer> lolek: I don't think bzr-exclipse is anywhere near usable, is it?
[13:00] <lolek> well ... it is
[13:00] <lolek> :)
[13:01] <lolek> and oh one thing
[13:01] <lolek> regarding this: https://bugs.launchpad.net/bzr-svn/+bug/1076388, i've used svn:// when gave url :)
[13:02] <jelmer> lolek: not sure I follow?
[13:02] <lolek> oh.. sorry my fault... mind shortcut
[13:02] <lolek> forget ;d
[13:04] <mirtwo> TBF!
[13:04] <mirtwo> boah ist die welt klein
[13:09] <jelmer> lolek: sorry, me too :-)
[13:09] <lolek> mirabilos|work: could you please speak in english ?
[13:09] <mirabilos|work> yes
[13:09] <mirabilos|work> “the world is small”
[13:10] <lolek> thank You ;)
[13:10] <mirabilos|work> tbf was one of the first people I met on IRC, b̲e̲f̲o̲r̲e̲ I even spoke something resembling English
[13:13] <tbf> hey mirabilos|work
[13:14] <lolek> uhm
[13:15] <tbf> mirabilos|work, how long ago is this? 12 years?
[13:15] <mirabilos|work> something like that, yes
[13:15] <mirabilos|work> probably around 1999/2000
[14:13] <lolek> a question, can i use this way of workflow for bzr and svn as centralized repo ? : http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html
[14:14] <lolek> i'm trying to figure out how bzr will deal with branches in folders on svn repo
[14:16] <lolek> of course if You have some suggestions or better aproach, i can consider that also
[14:31] <karni> Hello folks. I have a problem committing u1-servers. bzr really wants to sign with my<EMAIL_ADDRESS>key, while I want to sign with<EMAIL_ADDRESS>[14:32] <mgz> karni: see #launchpad
[14:32] <jelmer> karni: it should be using your whoami details to find the gpg key
[14:32] <karni> It's picking mkarnicki by default. How do I change that? I've tried overriding gpg_signing_key
[14:32] <karni> whoami says<EMAIL_ADDRESS>but it's not using that one
[14:33] <karni> mgz: I think they'll send me back to #bzr :(
[14:33] <mgz> probably :)
[14:33] <karni> To make matters more "fun", I can sign with @canonical.com a different project with no fuss.
[14:33] <karni> I don't see any specific configuration to that project in my locations.conf
[14:34] <karni> nor authentication.conf
[14:35] <mgz> karni, okay, looking at the code
[14:35] <karni> mgz: Thank you!
[14:36] <mgz> gpg_signing_key should be either "default" or suitable for passing to gpg -u
[14:36] <karni> FWIW I tried passing my canonical e-mail as well as key signature (that's what you call it?) to gpg_signing_key
[14:36] <mgz> if default, it looks at 'email'
[14:36] <karni> right. I can try that again.
[14:36] <karni> should I put it in ~/.bazaar/authentication.conf ?
[14:37] <mgz> karni: nope, just bazaar.conf I think
[14:38] <mgz> apart from by having a different `bzr whoami --branch` I don't see how different projects could get you different signing
[14:39] <karni> mgz: I think it had something to do with me signing it within lxc..
[14:39] <karni> mgz: I did add it to authentication.conf, though
[14:39] <karni> mgz: I tried from my host machine, and it commited properly
[14:40] <karni> yeah, it's still trying to sign with<EMAIL_ADDRESS>within lxc
[14:40] <karni> mgz: I don't know how that works, but just so you guys know ↑
[14:43] <mgz> but `bzr whoami` in lxc isn't that, and `gpg --clearsign -u<EMAIL_ADDRESS>works?
[14:44] <mgz> possibly lxc hides some of your keys, or confuses the agent in some way?
[14:51] <mgz> karni: I can't find any key on your name on a gpg key server
[14:52] <karni> mgz: in lxc, bzr whoami is also: Michał Karnicki<EMAIL_ADDRESS>[14:52] <karni> So correct.
[14:53] <karni> mgz: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0xF1044FC25FD638E7
[14:53] <karni> mgz: I bet it's confusing the agent in some way
[14:54] <mgz> ah, you have an 'i' on the end I'd not registered
[14:55] <karni> :)
[14:58] <fullermd> You should vowel to be more careful with your spelling...
[15:00] <mgz> karni: when you ran just the gpg command inside lxc, did it also want to sign with the wrong key?
[15:00] <karni> I can check
[15:00] <mgz> fullermd: @ expands to eat all adjacent characters
[15:01] <mgz> *munch* *munch*
[15:01] <fullermd> Only to the right; you can see what's where the mouth is.
[15:01] <karni> mgz: gpg --sign desktop.png signs with mkarnicki, but -u michal.karnicki works to override and sign with the second key
[15:10] <lolek> ok, one more time with my question, i'd like to use this approach: http://doc.bazaar.canonical.com/beta/en/user-guide/svn_plugin.html#using-a-central-repository-mirror but want to use svn as central repository, my question is what problems should i consider ?
[15:12] <lolek> the problem is that i want to use that like this: http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html, the second question is how bazar will work with branch in subdirectory on svn repo ?
[15:14] <jelmer> lolek: hi
[15:14] <jelmer> lolek: what do you mean with branch in subdirectory exactly?
[15:15] <jelmer> bzr-svn handles it fine if there is e.g. a branch named /trunk in the repository, and recognizes copies
[15:30] <mgz> karni: last thing to see is run `bzr config` in the branch, see if gpg_signing_key is set anywhere up the chain
[15:30] <karni> mgz: bzr: ERROR: unknown command "config"
[15:31] <jelmer> karni: your running a very old version of bzr
[15:32] <karni> Bazaar (bzr) 2.1.4 in lxc (LUCID), 2.5.1 on host OS
[15:32] <karni> This is because it's u1-servers branch, lucid was advised (although I hear it works on more current version)
[15:35] <iwata0303> Hi.
[15:36] <iwata0303> Does anyone know when bzr2.6b3 will come ?
[15:39] <jelmer> vila, mgz: ^
[15:40] <lolek> jelmer: may i pm You ?
[15:41] <jelmer> lolek: sure
[16:03] <mgz> karni: that might also be an issue with gpg signing then. you can, on lucid, us the bzr ppa to restore sanity to the world.
[16:03] <karni> mgz: ah. I might try that. I'll stick with committing from host for now :) Thank you!
[16:04] <mgz> karni: ppa:bzr/ppa
[16:04] <mgz> iwata0303: ideally soon
[16:05] <iwata0303> mgz: Thank you!
[16:05] <karni> mgz: Thank you, sir!
[16:06] <mgz> I'll send something to the list when I'm about to launch on working out how to do a release
[16:06] <mgz> hm.... the next couple of weekends are full, might need to find a weekday night
[16:46] <embersoaker> I merged and commited a branch in to trunk and then reverted it. Went back and changed my code in my branch and then when trying to merge again it won't let me. Is there a way to get trunk to forget that this branch was merged/conmitted before? or a way to force a commit?
[16:52] <mgz> you merge trunk back into your branch, revert the tree but not the merge marker (`bzr revert .` && bzr commit), then merge the branch back into trunk
[16:54] <mgz> basically, the feature branch needs to acknowledge the tree changes were not accepted on trunk, and have a new rev with the changes still present as well as trunk history so trunk knows to reapply them
[16:56] <mgz> embersoaker: ^that make sense to you?
[16:58] <embersoaker> yes
[16:58] <embersoaker> thank you
[17:00] <vila> mgz: I'll be in england next week, if connected the latency should be low ;)
[17:00] <mgz> oh ho ho, london?
[17:00] <mgz> all week?
[17:00] <vila> mgz: yup and yup
[17:00] <mgz> jelmer: ^
[17:01] <jelmer> vila: where in England?
[17:01] <vila> london
[17:01]  * jelmer will be in London from Wed-Fri
[17:05]  * SamB_MacG5 grumbles about how ad-hoc bzr's commands are ...
[17:24] <vila> jelmer, mgz : I'll leave Friday afternoon, will need to check my schedule but... would be nice to have either lunch or dinner or something no ?
[17:42] <jelmer> vila: yeah, that'd be great
[17:43] <fullermd> If I start swimming now, maybe I can meet you there...
[17:43] <vila> fullermd: be my guest ;)
[18:35]  * SamB_MacG5 is especially thinking that "bzr missing" should support most of the options of "bzr log", like -p ...
[18:39] <fullermd> https://lists.ubuntu.com/archives/bazaar/2008q2/041074.html   :p
[22:23] <delinquentme_> ls
[22:23] <delinquentme_> derp!
[22:24] <delinquentme_> I have config files ... I'd like a new user to be able to have access to a version of them ... but not mine ...
[22:24] <delinquentme_> SO .. can I include files within a bzr repo which aren't VC'ed ?
[22:31] <fullermd> Well, you can PUT a file there and ignore it.  Obviously bzr won't know anything about it, so you'd have to put it there (if it's important) any time you make a WT.
[22:32] <delinquentme_> WT?
[22:32] <delinquentme_> fullermd, ?
[22:32] <lifeless> working tree
[22:33] <fullermd> Oh, shucks.  If I'd known lifeless was here, I'd have just hit 6 or 8 keys at random, and he'd interpret a correct answer out of it...


[05:43] <pitti> mwhudson: err, that bug never affected xenial; it was introduced in some commit in 231 and reverted/fixed shortly after
[05:43] <mwhudson> pitti: it's happening to me right now
[05:43] <mwhudson> and i'm on xenial
[05:43] <pitti> mwhudson: if you see a similar effect under xenial, please file a new bug, it's something completely new and unknown then
[05:43] <mwhudson> pitti: oh goodie
[05:44] <pitti> Good morning
[05:44]  * mwhudson ubuntu-bugs
[05:48] <mwhudson> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1621327
[05:49] <pitti> mwhudson: oh, so keystrokes don't go to the VTs or mess up the console, only Alt+Left/Right?
[05:49] <mwhudson> pitti: yeah
[05:50]  * pitti actually has no idea what handles [Ctrl+]Alt+Left/Right, I thought that was the kernel itself
[05:50] <mwhudson> so i guess it's not quite the same
[05:50] <pitti> mwhudson: and is that happening in y for you too?
[05:50] <mwhudson> pitti: no, i'm on x
[05:50] <mwhudson> pitti: only started recently, i wonder what the chances that it'll stop if i restart...
[05:51] <pitti> mwhudson: so this only happens after an upgrade, not after a fresh boot?
[05:52] <mwhudson> pitti: to be fair i don't know what caused it
[05:52] <pitti> this needs some reproducer and collecting data, I'm afraid; I don't get that here, nor did I see this before in bugs
[05:52] <mwhudson> i just mentioned my symptoms and someone mentioned that debian bug
[05:52] <pitti> I'll do some research what handles the (Ctrl+)Alt keys
[05:52] <mwhudson> i'll reboot and see if it goes away :-)
[05:57] <mwhudson> pitti: yeah, i rebooted and it's stopped
[05:58] <RAOF> Oh, *that* bug!
[05:58] <RAOF> Oooh, does it happen when updating systemd?
[05:58] <stgraber> mwhudson: sudo kbd_mode -s
[05:58] <RAOF> (That happens on yakkety too)
[05:59] <stgraber> mwhudson: I've had a few systems where the console got reset to non-raw mode (on Xenial) which can cause the symptoms you described above
[05:59]  * pitti runs systemctl daemon-reexec, and sudo apt-get install --reinstall systemd, nothing here
[06:00] <pitti> maybe it sometimes restarts console-setup.service or so? /me tries
[06:00] <stgraber> mwhudson: yep, confirmed that if I intentionaly break it with "sudo kbd_mode -u" I do get exactly what you described, "sudo kbd_mode -s" fixes it
[06:00] <pitti> I tried to restart console-setup.service, keyboard-setup.service, setvtrgb.service, all fine; does that trigger the bug for you?
[06:09] <mwhudson> stgraber: ah
[06:10] <pitti> xnox: hm, today's dist-upgrade pulls in gnupg-l10n gnupg1 gnupg1-curl gnupg1-l10n
[06:10] <mwhudson> pitti: yeah, those don't seem to do anything
[06:10] <pitti> xnox: I thought we wanted to move to 2 only?
[06:11] <mwhudson> stgraber's thing seems to match my symptoms
[07:14] <pitti> Laney: FYI, I got it working last night: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=df691943dc
[07:14] <pitti> Laney: i. e. nothing to change in the charms, just driving the juju-1 vs. -2 CLI in the deploy.sh script needs adjusting; now it works with both
[07:14] <smb> nacc, Not at such times. I am UTC+2 right now ;)
[07:15] <pitti> Laney: I ran into bug 1621336 (but that happens with juju-1 too) and bug 1621237, otherwise works great
[07:49] <dholbach> smb, happy birthday! :)
[07:50] <sakrecoer> hi! we have a situation in ubuntu studio, non of our members have upload rights. could anyone of you help us with that or point me to someone who could?
[07:51] <sakrecoer> and happy birfday smb! :) virgo power!
[07:51] <smb> thanks
[07:52] <pitti> ooh, alles Gute smb!
[07:54] <smb> pitti, danke danke :)
[07:56] <sarnold> gratulieren smb :)
[07:56] <smb> danken sarnold
[07:56] <smb> :-P
[07:59] <xnox> pitti, ack. let me look into reverse-deps and kick things out.
[08:00]  * xnox is glad things finally landed.
[08:00] <pitti> xnox: oh, might be because I have signing-party installed
[08:00] <pitti> xnox: indeed, congrats! nice work
[08:00] <xnox> pitti, ... however i will be sad if caff cannot do gnupg2....
[08:01] <pitti> xnox: so indeed my main concern was to not install it by default on images
[08:01] <pitti> Package: gnupg
[08:01] <pitti> Task: minimal
[08:01] <pitti> I suppose we should update that :)
[08:02] <pitti> also, minimal seems harsh
[08:02] <pitti> apt prefers gpgv over gpgv2, at some point we should flip that around
[08:02] <xnox> it's not that harsh. we rely on master key for archive key migrations.
[08:02] <pitti> xnox: but that should be gpgv2, not gnupg
[08:03]  * xnox thought gpgv is now 2.1, gpgv2 transitional, gpgv1 old one? (same as gnupg)
[08:03]  * xnox checks
[08:03] <pitti> xnox: oh, you are right, nice
[08:03] <pitti> so we don't actually seed gpg or gnupg
[08:04] <pitti> must come through dependencies, or the Task: headers didn't get recomputed after that
[08:05] <pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt has a lot of stuff which wants to get lifted, but no gpg 1 stuff to get dropped, hmm
[08:05] <xnox> pitti, https://launchpad.net/ubuntu/+source/gnupg should be demoted to universe and/or removed
[08:05] <xnox> as it should be replaced fully now by src:gnupg2 & src:gnupg1
[08:05] <pitti> indeed, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[08:06] <xnox> cool
[08:06] <pitti> only the source, for some reason
[08:06] <pitti> ah, the gnupg binary is from gnupg2 now
[08:14] <pitti> xnox: hm, do we actually want/need pinentry-curses as Priority: important (i. e. in the standard install, even in containers) now?
[08:15] <xnox> it's either that or
[08:15] <pitti> seb128, Laney: who knows about ubuntu-system-settings these days? it's the remaining thing on http://people.canonical.com/~ubuntu-archive/nbs.html, thus a thorn in my eye :)
[08:15] <seb128> pitti, kenvandine and jgdx
[08:16] <xnox> telling everyone to "echo allow-loopback-pinentry >> ~/.gnupg/gpg-agent.conf" and "echo pinentry-mode loopback >> ~/.gnupg/gpg.conf"
[08:16] <seb128> you probably want Ken for packaging changes
[08:16] <pitti> seb128: thanks
[08:16] <seb128> yw
[08:41] <mitya57> Mirv, I would like to get https://codereview.qt-project.org/170467 and https://codereview.qt-project.org/170460 into yakkety, but I want to wait for +2s first.
[08:42] <mitya57> Maybe there will be one more fix from me, related to desktop notifications. But I have not yet written it :)
[08:43] <Mirv> mitya57: I noticed them both, yes feel free to add them to qtbase packaging once +2. I'm (just) done now with my changes for a while.
[08:44] <Mirv> mitya57: ok :)
[08:45] <mitya57> Mirv, I'm a bit sorry that we now have too many patches, but on the other hand we'll have less bugs and complaints :)
[08:46] <Mirv> mitya57: well this was hoped all along to get appmenu truly fixed for xenial+1, it's great to have these
[08:59] <xnox> pitti, trying out systemd-graphical-session.... do i still need ppa and hud from that ppa and systemd-graphical-session?
[08:59]  * xnox gets no hud/unity running
[09:00] <pitti> xnox: half of it landed in yakkety proper, the other half has been stuck in https://requests.ci-train.ubuntu.com/#/ticket/1710 for a while
[09:00] <pitti> xnox: but I believe Trevinho is working on landing the unity bits
[09:00] <pitti> xnox: but the PPA is still expected to work, for the indicators, hud, and unity
[09:01] <xnox> horum
[09:02] <xnox> bamfdaemon failed for me, and then unity7 failed with dependancy wait
[09:04] <xnox> pitti, i ponder about: alias userctl='systemctl --user'
[09:06] <xnox> manually starting bamfdaemon works, and things look like they work.
[09:06] <pitti> what did it fail on?
[09:06] <xnox> the combos of upstart, systemd, gnome-session are a bit weird =)
[09:06] <xnox> pitti, it was failing to aquire the dbus name for the org.Bamf whatever.
[09:07] <pitti> xnox: hm, did both the upstart and the systemd job try to run?
[09:07] <xnox> so it seems like bamfdaemon was started, respawned, hit limit, before user dbus was up.
[09:07] <xnox> yes. my dbus is under upstart control it seems.
[09:07] <xnox> and gnomne-session
[09:07]  * xnox is weird and i have gnome-session (Unity) also under upstart
[09:08] <pitti> hm, this is all supposed to be moved already
[09:08] <xnox> and url-dispatcher, mediascanner-2.0
[09:08] <pitti> dbus-user-session still installed?
[09:08] <xnox> yeah.
[09:09] <brendand> AdUw3Maa83!
[09:10] <xnox> pitti, i have dbus-user-session installed, and i have two dbuses....
[09:11] <xnox> systemctl --user status dbus pid 25133
[09:11] <xnox> initctl --user status dbus process 27389
[09:12] <doko_> Laney: yes, alan_g is looking at the mir test failure
[09:12] <Trevinho> xnox: yeah... Please add an alias for that... Ora soooo annoying :-)
[09:12] <xnox> i see no override for dbus in /usr/share/upstart/systemd-session/upstart
[09:12] <Trevinho> xnox: as for unity, the other landing should be enough
[09:14] <xnox> how is dbus supposed to run?
[09:18] <xnox> this is amazing.... switched to tty and the gpg-agent still works =)
[09:19] <pitti> xnox: via "systemctl --user status dbus.service"
[09:19] <pitti> xnox: yep, the magic  of user bus :)
[09:20] <Laney> Trevinho: are you still waiting for a second review?
[09:20] <xnox> ok. and the $ initctl --user status dbus -> shouldn't be running? is it on manual for you?
[09:20] <pitti> xnox: i. e. /usr/lib/systemd/user/dbus.service will always run, independent of our systemd-ified session startup
[09:20] <xnox> sure. but something needs to get rid of the upstart user session dbus, no?
[09:20] <Trevinho> Laney: yep...
[09:21] <pitti> xnox: yes, indeed; trying to remember what does that
[09:21] <Laney> meh
[09:21] <pitti> xnox: ah, here: http://launchpadlibrarian.net/261442770/dbus_1.10.6-1ubuntu3_1.10.6-1ubuntu4.diff.gz
[09:21] <pitti> xnox: we built it into the upstart dbus job itself
[09:22] <pitti> xnox: so you should still have the upstart job running as we need it as a "stub" to start reverse dependencies, but it should only run "sleep infinity"
[09:22] <pitti> (this can probably be made more elegant somehow, by merely having it appear as running but not execing anything)
[09:23] <Laney> Trevinho: ted_g approved it
[09:25] <xnox> right that pid is sleep infinity
[09:26] <xnox> more elegantly, one would "initctl emit started JOB=dbus" and that's it.
[09:26] <xnox> without actually running/respawning sleep infinity.
[09:26] <pitti> sounds nice
[09:27] <Laney> wouldn't that make it stop straight away?
[09:27] <xnox> why?
[09:27] <Laney> the process would finish
[09:27] <highvoltage> l/win 46
[09:28] <pitti> right, "stop on stopped dbus" needs to continue to DTRT
[09:28] <pitti> if things are only listening for "started dbus", that'd be fine
[09:29] <pitti> but ISTR having seen a job which does nothign on exec and just has pre/post-start
[09:29] <Laney> RemainAfterExit=yes # oh wait
[09:29] <Laney> yeah, gpg-agent does that
[09:29] <Laney> I forgot precisely what events that causes
[09:29] <Laney> but then you could just do /bin/true
[09:30] <Laney> assuming it goes to started
[09:30] <Saviq> xnox, hey, shouldn't gnupg in yakkety depend on dirmngr now?
[09:30] <pitti> I thought it would only work for that as nothing does "stop on stopped gpg-agent"
[09:30] <Laney> hang on, this is easily testable
[09:30] <Laney> .config/upstart to the rescue
[09:31] <xnox> Saviq, Laney asked me that as well. I'm not sure. what are the symptoms you hit?
[09:31] <Saviq> https://unity8-jenkins.ubuntu.com/job/run-commands/node=jenkins-slave-0/lastBuild/console
[09:31] <Saviq> xnox, ↑
[09:34] <Laney> pitti: Don't think it works, since you still need the exec block for the old case; this trick only works if you have pre-start but no exec (or script)
[09:34] <xnox> Laney, echo 'start on starting xsession-init' > ~/.config/upstart/dbus.conf
[09:34] <xnox> Laney, echo 'stop on stoping xsession-init' > ~/.config/upstart/dbus.conf
[09:34] <xnox> Laney, echo 'stop on stoping xsession-init' >> ~/.config/upstart/dbus.conf
[09:35] <xnox> start dbus; status dbus -> running; stop dbus -> stopped.
[09:35] <xnox> Laney, why do we need it for the old case? systemd user dbus session is always available, even in xenial.
[09:35] <xnox> and we are not double/tripple landing dbus
[09:35] <Laney> then just have it always be started
[09:35] <Laney> pre-start exec /bin/true
[09:35] <xnox> we need dbus events in upstart user session, but dbus can be started/stopped by user systemd
[09:36] <xnox> i don't even need to exec anything.
[09:36] <Laney> if that works, then 'start on startup'
[09:36] <pitti> xnox: no, you can uninstall dbus-user-session, and it's not installed by default in xenial
[09:36] <Laney> I think the old way is still required to be supported
[09:36] <xnox> just have "start/stop on starting/stopping xsession-init" it does make an assuption that dbus is started by systemd before upstart user session is available.
[09:36] <xnox> horum.
[09:37] <xnox> then split into two upstart jobs.
[09:37] <xnox> one is dbus to emit events / become sync point and another is dbus-daemon that actually spawns the daemon if need be, which is start on starting dbus
[09:37] <Laney> sleep infini_ty seems less annoying than that
[09:37] <xnox> true
[09:38] <xnox> gnome-session is also sleep infinity
[09:38] <pitti> the overrides  can go away once we lland systemdification of the rdepends
[09:38] <pitti> i. e. unity and indicators
[09:38] <pitti> so those sleep infinitys are only a temporary shim
[09:39]  * pitti didn't expect unity and indicators to take that long, sorry
[09:40] <xnox> what about the phone though?
[09:40] <xnox> it has more things still....
[09:41] <pitti> xnox: right, still lots of WIs for the phone; but this doesn't run on yakkety, so no sleep i_nfinity there
[09:42] <xnox> Saviq, given that one cannot '--recv-keys' i do think we need/want dirmngr.
[09:42] <Saviq> +1
[09:42] <xnox> however, may i use "Recommends:" instead of "Depends:"?
[09:42] <xnox> that way it will be installed by default on most systems, but bare-minimal offline ones.
[09:43]  * xnox thinks that through for a moment.
[09:43] <xnox> wait it already recommands dirmngr
[09:43] <xnox> so why is it not installed.
[09:44] <Saviq> xnox, likely the way I configured mk-sbuild
[09:44] <xnox> Saviq, you use add-apt-repository, which assumes importing things over the network, maybe that should depend on dirmngr?
[09:44] <xnox> same as e.g. bzr-builddeb, landscape-client, piuparts, python-apt, python-germinate, ubuntu-dev-tools?
[09:45] <xnox> (as in software-properties-common)
[09:45] <Saviq> xnox, wfm
[09:45] <xnox> i'm happy to add depends in software-properties-common.
[09:45] <Saviq> agreed that gnupg2 itself maybe shouldn't depend, since unless you use --recv-keys it will work fine, and the error message than is pretty clear
[09:46] <Saviq> *then
[09:55] <xnox> and done =)
[09:58]  * pitti adds a more tasteful home page to http://autopkgtest.ubuntu.com/
[10:01] <Trevinho> Laney: one more approval, then if you want it's good for your publish button
[10:03] <tseliot> pitti: hey, do you think you can approve those packages for me today?
[11:16] <roaksoax> howdy! are there any issues with apt or archives ?
[11:16] <roaksoax> i'm starting to see issues like: http://pastebin.ubuntu.com/23149808/ in an overlayfs
[11:19] <roaksoax> pitti who should I talk to about issues like http://pastebin.ubuntu.com/23149808/ ? any ideas ?
[11:23] <Anticom> Hi all, I'm looking for jml. According to his readme, he's the guy to talk to about undistract-me
[11:25] <hloeung> roaksoax: larrymi saw the same thing earlier today, so it may be a bad MAAS image. Not sure
[11:26] <roaksoax> hloeung: I don't think it is the maas image itself, but something changed that is causing this issue
[11:26] <roaksoax> hloeung: in an overlayfs
[11:27] <hloeung> roaksoax: oh ok
[11:28] <roaksoax> hloeung: may be related to this: https://bugs.launchpad.net/cloud-init/+bug/1618572
[11:47] <pitti> tseliot: looking; FWIW, "low regression potential" is quite an understatement -- this involves new pacakges, new driver on existing systems, etc. :)
[11:48] <pitti> roaksoax: it came up a few times recently with overlayfs (most people experienced that in schroot)
[11:48] <pitti> roaksoax: I think I've overheard xnox saying it's some kernel change, but I'm not sure
[11:49] <pitti> roaksoax: ah yes, that bug looks right
[11:49] <Laney> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1620525
[11:49] <Laney> xnox pointed me to that one, but might be a duplicate
[11:50] <Laney> and the other one has a fix, go apw!
[11:52] <roaksoax> pitti: yeah it seems it is the same bug
[11:55] <pitti> tseliot: source-NEWed; will wait for the binaries, new them, and then call for testing on the bug
[12:28] <mapreri> jbicha: in debian libsecret was properly fixed (and not just "skip the tests"+hacks..).  The fix is span over pygobject and libsecret itself, which could be both synced, imho.  Though we are in FF so some care could be used..
[12:28] <mapreri> can you please look at it and see whether you could/should sync them?
[12:30] <tseliot> pitti: thanks!
[12:53] <pitti> tseliot: done
[12:54] <jbicha> pitti: ^ see above about possiblying syncing pygobject 3.21.91
[12:55] <jbicha> maybe I should type a bit slower
[12:55] <pitti> ah, to keep up  with the beta
[12:56] <pitti> jbicha: no objection, we have fairly good test coverage for it
[12:58] <pitti> infinity: http://autopkgtest.ubuntu.com/packages/g/glibc/yakkety/amd64 started failing two weeks ago, is that known? due to gcc 6?
[13:00] <flexiondotorg> I'm working on the this bug for libmateweather
[13:00] <flexiondotorg> https://bugs.launchpad.net/ubuntu/xenial/+source/libmateweather/+bug/1616533
[13:00] <flexiondotorg> I've released libmateweather 1.12.2 upstream, which fixes the issue.
[13:01] <infinity> pitti: That's LP: #1600000
[13:01] <flexiondotorg> I want to SRU libmateweather to xenial.
[13:01] <infinity> pitti: Please turn off libnss-resolve in autopkgtest VMs until that's fixed? :)
[13:01] <pitti> infinity: oh? we've had resolve a lot earlier than that
[13:01] <infinity> pitti: Well, if you check the log, that's the failure.  *shrug*
[13:02] <flexiondotorg> Do I need to create a additional bug for the SRU to xenial?
[13:02] <pitti> infinity: ack, thanks
[13:02]  * pitti looks into that
[13:06] <jbicha> flexiondotorg: maybe use that bug for tracking the libmateweather issue and have bug 1620557 handle libgweather
[13:06] <jbicha> just because the SRU verification is a bit different for the 2 different packages
[13:26] <flexiondotorg> jbicha, Just to be clear. You're suggesting libgweather uses https://launchpad.net/bugs/1620557 for SRUs.
[13:27] <flexiondotorg> ANd libmateweather uses https://launchpad.net/bugs/1616533
[13:52] <pitti> infinity: https://github.com/systemd/systemd/pull/4111 sent FYI, I'll see to land that soon
[13:54] <infinity> pitti: Excellent.
[13:55] <infinity> pitti: When did systemd-resolve start being a thing we built and shipped?
[13:55] <infinity> pitti: I'd suggest that's broken enough behaviour that it should be SRUed to any release that included the bits, even though we didn't enable it.
[13:56] <pitti> infinity: somewhere end of May or June or so
[13:56] <pitti> infinity: sure, it's simple enough to SRU (even though I don't think it's that important -- other than test suites I don't see what it could realistically break)
[13:56] <pitti> resolving foo.bar.. like foo.bar is hardly completely unexpected
[13:57] <pitti> but I'll cherry-pick it to the xenial branch once it lands
[13:57] <infinity> pitti: Other than being completely wrong, but yeah, I suppose it's not something people are likely to do often.
[13:59] <pitti> infinity: anyway, arguing about whether or not it's important enough would take more time than just cherry-picking the fix once it's in master, so JFDI :)
[14:03] <infinity> pitti: Yeah, I think you're probably right that it's not actually desperately important, I'm just a big fan of not breaking RFCs.
[14:04] <infinity> pitti: But, there's also just the "LTSes deserve polish" argument.
[14:07] <flexiondotorg> jbicha, How to proceed with SRUs for libgweather and libmateweather?
[14:08] <tseliot> pitti: great, thanks again!
[14:10] <davmor2> pitti: JFDI is that yoda's impression of Obi-wan?  Jedi Force Disturbance Is hmmmmmmmm
[14:20] <xnox> infinity, something i hope they don't, even I don't do that =)
[14:21]  * xnox is crap with standards and networking =)
[14:22] <jbicha> flexiondotorg: yes, the libgweather xenial sru is already in the unapproved queue
[14:23] <flexiondotorg> OK, So no problem for me to remove libgweather from #1616533 then?
[14:23] <jbicha> flexiondotorg: sure, go ahead
[14:23] <flexiondotorg> jbicha, Thanks.
[14:23] <pitti> davmor2: it's jedi typoed too indeed, but more commonly "just f** do it" :)
[14:23] <jbicha> and change the title to match :)
[14:24] <davmor2> pitti: I knew what it mean I just thought it was nicer ;)
[15:23] <doko_> kenvandine: libphonenumber ping
[15:25] <pitti> hmm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and http://people.canonical.com/~ubuntu-archive/component-mismatches.txt are stuck, /me prods
[15:30] <Laney> pitti: Already doing
[15:30] <Laney> see #ubuntu-release
[15:30] <pitti> Laney: just pushing the b1 fix
[15:30] <pitti> Laney: argh
[15:30] <Laney> :|
[15:30] <pitti> Laney: what did you do?
[15:30] <Laney> Nothing
[15:30] <pitti> Laney: just pushed http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/296
[15:30] <Laney> I know what the problem is but I didn't push it yet
[15:31] <Laney> Fine
[15:31] <pitti> Laney: sorry
[15:31] <Laney> You should remove the exit 0 in run-proposed-migration
[15:31] <Laney> doesn't that just push the problem to the next time?
[15:31] <pitti> Laney: how do you mean?
[15:32] <pitti> Laney: exit 0 removed
[16:42] <kenvandine> doko_, there's a test failure for telephony-service in the silo, someone's working on fixing that
[16:46] <drab> hi, couple questions: I'm trying to preseed all my installations and would love to be able to have a preseed common file imported by others. I'm pulling my main preseed file via url over http. There is a preseed/include string but that doesn't seem to be able to fetch from http, or I'm doing it wrong
[16:46] <drab> anybody got a working example? or is there a better place to ask this question?
[16:47] <drab> oh, maybe -installer, trying there
[17:14] <nacc> drab: iiuc, preseed/include will grab relative to whatever directory your main preseed file was obtained from. Have you tried using a relative path? I honestly don't expect that to work (it seems mostly designed for on-cd customization), but it might?
[17:31] <drab> nacc: yeah I read that and tried, it didn't, it never tried to pull from the webserver where the main file comes down from
[17:31] <drab> I'm puzzled why if url works at the very beginning of the process preseed/include can't
[17:31] <drab> but that does seem to be the case
[17:32] <drab> i might look if I can use something like an early_command to pull it down on the system, but not sure that runs as early in the process as needed (ie it can influence partman etc)
[17:33] <nacc> drab: yeah, i don't think early command will help you necessarily, for the reason you said
[20:01] <semiosis> Odd_Bloke: i'm going to take a look into Poma's report about DNS on the new xenial vagrant box
[20:01] <Odd_Bloke> semiosis: Excellent, thanks!
[20:02] <semiosis> Odd_Bloke: if I can reproduce it and dont see a new bug opened tomorrow i'll open it myself.  i think i know were the problem is.  seem to remember something about resolv.conf manipulation in the livecd-rootfs hooks
[21:02] <Bluefoxicy> I wonder how close my response to Thierry would be to something Linus would say, ignoring the many colorful ways in which Linus would say "You are Dumb(TM)" throughout the whole exchange
[23:07] <attente> is anyone here using a yubikey for ssh authentication on yakkety? i'm wondering why the S.gpg-agent.ssh socket is no longer in my .gnupg directory
[23:11] <stgraber> attente: possibly because of the ongoing switch to gpg2? just a guess though, I'm not using the gpg agent for ssh auth


[02:22] <chilts> afternoon
[18:15] <Atamira> morning
[19:33] <ibeardslee> morning
[19:34] <Atamira> such a lovely day today


[01:25] <Unit193> http://launchpadlibrarian.net/340180936/xubuntu-meta_2.217_2.218.diff.gz urgh..
[06:29] <flocculant> yea knew about that stuff - don't say anything anymore when I see things being added
[06:54] <Unit193> Yeah saw it coming, but still...
[09:47] <knome> hmm, why do we need liberation?
[09:47] <knome> do they bring some language support?
[11:10] <flocculant> nope they just bring freedom
[11:10] <flocculant> or liberation at least :D
[11:10] <flocculant> didn't bother saying anything about fonts cos last time I did it was pointless
[11:20] <flocculant> akxwi-dave: we're 11 days from release - if we're going to try to get some increase in testing of rc then we need to do it now :)
[11:53] <knome> lol, well
[11:54] <knome> the liberation fonts are okay, but i think we have better options available
[11:54] <knome> i might be wrong for serif though
[11:54] <knome> (noto serif isn't shipped with the noto packages we have right?)
[12:00] <flocculant> knome: manifest from 30th June has fonts-liberation - don't think it's added, perhaps where it comes from has changed
[12:01] <flocculant> -indic is new
[12:01] <flocculant> http://paste.ubuntu.com/25706947/
[12:03] <knome> mhm
[12:31] <knome> maybe we should do a quick overview of the fonts for 18.04 amongst other things too
[12:39] <flocculant> knome: possibly, though last time I brought fonts up it was 'what about this user or that user' so not sure why we need to worry about fonts :)
[12:40] <knome> that discussion was probably about supporting languages
[12:40] <knome> noto should support way more languages than many others, especially if we ship the whole package
[12:40] <flocculant> nope - was about why would we want to include noto iirc
[12:40] <knome> right...
[12:41] <flocculant> or rather -cjk
[12:41] <knome> yep
[12:41] <knome> cjk aka chinese japanese korean
[12:41] <flocculant> yea
[12:41] <knome> eg. language support :P
[12:41] <flocculant> *shrug*
[12:41] <knome> or technically glyph but..
[12:41] <knome> aaanyway
[12:41] <knome> eating and youtubing
[12:41] <knome> not videoing :P
[12:42] <flocculant> don't really see that there's much need to worry about us having 'some' fonts
[12:42] <flocculant> on the other hand - don't much care or have an axe to grind on it
[12:42] <knome> i'd probably just dump most of the other fonts if noto can support most
[12:42] <knome> yeah, it's a detail
[12:42] <flocculant> well
[12:42] <knome> that probably has more meaning for me than you
[12:43] <knome> etc...
[12:43] <flocculant> likely that's just going to really annoy me :)
[12:43] <knome> heh
[12:43] <flocculant> I change fonts - like other stuff in 'appearance overall'
[12:43] <knome> :)
[12:44] <flocculant> and when the scale of 'I need to change this now as well' gets too much - I'll use some other distro
[12:45] <knome> yeah
[12:45] <knome> though isn't noto our default anyway now? :)
[12:45] <knome> so no extra change there
[12:45] <knome> unless you change it to something else that is now shipped but won't if we do a cull
[12:49] <flocculant> yup
[12:50] <flocculant> obviously that's the same for everyone, not me in particular :)
[12:50] <knome> yep
[13:01] <akxwi-dave> flocculant:  ack.. will sort..
[13:02] <akxwi-dave> oh and when does the new job start?
[13:02] <flocculant> 26th :)
[19:38] <flocculant> bluesabre: do remember what the outcome for the not being able to search new locattions in weather app was?
[19:42] <flocculant> would be quite nice to have that working before release
[19:43] <ochosi> the weather plugin you mean?
[19:44] <flocculant> ochosi: yea
[19:45] <ochosi> oh right, never noticed that bug before
[19:45] <ochosi> just don't use the plugin very much atm
[19:45] <flocculant> just seen some bugmail which reminded me ...
[19:46] <ochosi> is there an upstream report about this too?
[19:46] <flocculant> seems to be more than 1 ...
[19:46] <flocculant> https://bugzilla.xfce.org/show_bug.cgi?id=13877
[19:47] <flocculant> 13901 os a dupe of that one
[19:48] <ochosi> i'll test the patch now
[19:48] <flocculant> ok
[19:48] <ochosi> if it works we can at least ship it as a patch for 17.10
[19:48] <ochosi> and it's fairly trivial
[19:49] <flocculant> yup
[19:49] <ochosi> i can also make sure it ends up in upstream
[19:49] <flocculant> :)
[19:49] <flocculant> there is an lp one I did in september - linked upstream to it now
[19:50] <flocculant> can't remember why I stopped doing more - vague recollection of chat in #xfce-dev at the time
[19:50] <flocculant> bug 1718182
[19:50] <ochosi> so the patch doesn't seem to help
[19:50] <flocculant> :)
[19:52] <flocculant> must try to find time this week to double check bugs listed
[19:53] <flocculant> back tomorrow
[19:57] <ochosi> the patch/analysis is sound though
[19:57] <ochosi> i'll debug a little more later


[09:08] <hjd> Good morning. :) Could someone please mark bug 1360075 as Triaged/High (program doesn't start)?