[00:07] <beuno> heya poolie!
[00:08] <beuno> knittl, heh, ingenious
[00:12] <knittl> beuno: well, it worked fastest :>
[00:12] <knittl> and so i made sure nothing is left
[00:15] <lifeless> knittl: bzr clean-tree --ignored
[01:02] <spiv> Good morning.
[01:06] <poolie> hi there spiv, lifeless
[01:11] <poolie> spiv, would you care to give a second opinion on https://code.launchpad.net/~mbp/bzr/ui-factory/+merge/34956
[01:18] <spiv> poolie: sure
[01:48] <lifeless> poolie: the apport one might be usable
[01:51] <poolie> lifeless: apport what?
[01:52] <lifeless> it has a dup detection demon
[01:52] <lifeless> for detecting things with the same backtrace
[02:31] <poolie> so, spiv, what do you think?
[02:31]  * poolie is going to see about getting scriptrunner to test interactive ui stuff
[02:50] <spiv> poolie: comment added
[02:57] <poolie> thanks for the review, and i think that's a nice statement about kwargs
[02:57] <poolie> i'd almost paste that into hacking
[02:57] <poolie> actually i will paste that into hacking
[02:58] <spiv> Ok :)
[02:58] <spiv> It took me a few goes to get my thoughts on kwargs reasonably clear.
[02:59] <poolie> yes, it's pretty much what i was trying to say
[03:49] <grettke> Hi folks. Just insalled bzr on the olpc-xo-1. When I try running bzr, I get ""bzr does not support python -OO." What did I do wrong?
[03:55] <spiv> grettke: bzr 2.2 should work with python -OO
[03:56] <spiv> It seems a bit unusual that bzr would be installed to be run with python -OO by default, but I guess it's an attempt to avoid wasting space on the XO.
[03:57] <spiv> grettke: how did you install bzr?  As a workaround, you can probably do "python /usr/bin/bzr", although if there are only .pyo files and no .pyc files it could be quite slow.
[04:02] <grettke> I did a yum install bzr.
[04:03] <spiv> Sounds like a bug in the rpm package, then :/
[04:03] <grettke> oh ok, good to know, thank you
[04:03] <spiv> But it wouldn't matter with the current release of bzr, which should work fine in those conditions.
[04:04] <spiv> (And thus also allow the space saving that -OO provides)
[04:04] <spiv> (And memory saving as well.)
[04:04] <spiv> On most systems I'd say those wouldn't matter, but they probably do help on the XO :)
[04:28] <poolie> is it just me or does lp-propose fail if there's already a proposal for the branch?
[05:18] <poolie> spiv, where was your testdoc branch?
[05:19] <spiv> poolie: it's in trunk now
[05:19] <poolie> oh, just lp:testdoc?
[05:19] <spiv> poolie: (also, jml made me the maintainer)
[05:20] <poolie> i like the idea of using it to review what i changed
[05:20] <poolie> tag :)
[05:28] <poolie> wow, very nice
[05:29] <spiv> Hooray :)
[05:29]  * poolie resolves to make his docstring slightly better
[05:29] <spiv> vila tells me it's unreadable with a light-background terminal ;)
[05:30] <poolie> :/
[05:30] <poolie> that's such a mess
[05:30] <poolie> i mean it's probably true but it's a shame unix lets you say "yellow" when you want "a bold contrasting color"
[05:30] <spiv> Yeah.
[05:31] <poolie> i guess he could write a formatter that either uses just bold/underline/etc, or that uses emacs to rewrite stuff into its own face markup
[05:31] <poolie> actually you could write the whole thing inside emacs quite well
[05:31] <poolie> i'm kind of surprised jml didn't
[05:31] <spiv> Yes, for interactive use the editor is in a way a better home for it.
[05:32] <spiv> I think perhaps jml wasn't thinking of using it interactively initially (given that the original output format was Moin markup).
[05:33] <spiv> Also I can imagine writing elisp to invoke Python to do fiddly introspection might trip some "that's too gross" thresholds...
[05:34] <poolie> i probably wouldn't use real python introspection, just regexps to find the methods and docstrings
[05:34] <poolie> but i'm glad it's standalone, since i no longer use emacs
[05:34] <poolie> much
[05:37] <spiv> I think ideally it wouldn't use introspection, but it certainly makes it easier to write.
[07:37] <vila> hi all !
[07:37] <vila> woohoo, connected to pratchett (.freenode.net) The day will be fun :)
[07:49] <bialix> hi
[07:52] <vila> hmm, is it me or is lp using a new font in same places ? (the mp links at https://code.edge.launchpad.net/bzr/+activereviews for example)
[07:52] <vila> bialix: _o/
[07:53] <lifeless> vila: the ubuntu font?
[07:53] <bialix> vila: \o_
[07:53] <vila> lifeless: hehe, looks like so to me, the funny thing is that I just installed it myself ;)
[07:54] <lifeless> vila: thats why you just noticed.
[07:54] <vila> lifeless: haaa, you mean the font change is older ? When did it occur ?
[07:55] <lifeless> 2 weeks I think
[07:56] <vila> lifeless: wow
[07:58] <vila> lifeless: haa, right, I see the font *because* I installed it...
[08:14] <mgz> morning all.
[08:20] <mgz> see from planet debian Robert's done an interesting post on what he's been up to
[08:20] <lifeless> I meant to edit it more, but it escaped due to wordpresss
[08:21] <poolie> > Bazaar is a tool anyone can install locally
[08:21] <poolie> > Launchpad, by contrast
[08:21] <poolie> is a tool no one can install :)
[08:21] <lifeless> hah
[08:23] <poolie> jk
[08:30] <poolie> vila, are you up?
[08:30] <poolie> is there some trick about matching blank lines in test scripts?
[08:30] <vila> poolie: yup !
[08:31]  * bialix waves at poolie
[08:31] <vila> poolie: hmm, ring a bell...
[08:31] <poolie> hi there bialix
[08:31] <bialix> new qbzr release hits the street
[08:32] <vila> I vaguely remember that initially blank lines were ignored when there was no '$' prefix for commands... Not sure we fixed that now that the expected output lines don't have a prefix
[08:32] <vila> poolie: what do you observe ?
[08:32] <vila> poolie: An expected output blank line not respected or detected or... ?
[08:33] <poolie> there's a blank line in the output
[08:33] <poolie> it seems to be a bug: by the time we run the checker, it's not in the 'expected' variable
[08:33] <bialix> poolie: check http://stackoverflow.com/tags/bazaar/info ; is it ok for you?
[08:34] <poolie> looks good
[08:35] <poolie> did you just set that up? thanks
[08:35] <bialix> actually, yesterday
[08:35] <bialix> I've got enough bazaar karma for this
[08:36] <bialix> ddaa asked me to do so...
[08:40] <vila> poolie: right, so I think my bell was right, want me to look at it ?
[08:41] <poolie> no it's ok, i think i see it
[08:41] <vila> poolie: bzrlib.script.py line 87
[08:42] <poolie> yeah :)
[08:42] <poolie> just working out what level to test that at
[08:42] <vila> poolie: right, and line 112 smells like an additional test would be good
[08:42] <poolie> i put up a branch ~mbp/bzr/script, that tests user interaction
[08:43] <vila> poolie: like... test_empty_line_is_ignored ? :-D
[08:43] <poolie> exactly
[08:43] <poolie> i think in some contexts it should be ignored
[08:43] <poolie> i guess only at the start of the document
[08:43] <vila> poolie: but I think this one should be kept... yeah, you got it
[08:44] <vila> i.e. output can exist if a command as been seen, otherwise, just ignore
[08:46] <poolie> so as simple as just saying, we'll ignore one initial blank, but no more?
[08:46] <poolie> at the _script_to_commands level?
[09:04] <vila> poolie: lp:~mbp/bzr/doc approved if you remove the 'I think' occurrences, I don't think we ever say 'I' in these docs ;-p
[09:05] <mgz> "I don't think we ever say 'I' in these docs" <- maybe you should add that to the docs
[09:06] <lifeless> -lol-
[09:06] <vila> mgz: my man ! Can you have a look at your mps ? There are some tweaks, but otherwise you have several you can land
[09:07] <mgz> yeah, I'm short news again aren't I?
[09:07] <vila> hehe
[09:07] <lifeless> probably
[09:07] <mgz> I'll add what's lacking and push.
[09:07] <vila> mgz: s/I don't think// applies to your remark :)
[09:08] <mgz> when you next poke babune vila, lifeless has released a new pyjunitxml version.
[09:08] <vila> mgz: already done, but thanks for the heads-up and thanks to lifeless for the upgrade ;)
[09:09] <mgz> ...you're always ahead of me
[09:09] <vila> I try to avoid running private branches for babune or I lose... track ? my mind ? my sanity ?
[09:09] <vila> mgz: not at all, just following closely instead :-p
[09:10] <vila> mgz: ... which may mean I'm ahead when you stop :D
[09:13] <mgz> pqm has news merge on right? otherwise I'm going to conflict horribly here.
[09:14] <poolie> vila: proposal updated
[09:15] <poolie> vila :)
[09:15] <poolie> well, it was kind of quoted
[09:15] <poolie> but not very clearly
[09:16] <vila> poolie: sure, but lp doesn't show any changes yet, you've pushed right ?
[09:16] <vila> wow, I'm already in love with the new Ubuntu font :)
[09:16] <poolie> oh i meaont the scripts one
[09:16] <poolie> did it change again?
[09:16] <vila> ha
[09:17] <vila> poolie: ok, wasn't there yet
[09:17] <poolie> do you think that's a reasonable position about string interpolation?
[09:17] <vila> "args are split in to words" ? into ?
[09:19] <vila> poolie: hmm, I really dislike the idea of removing the first and final line
[09:19] <vila> """\ works great for the first one
[09:20] <poolie> vila, and you can do the same for the last one
[09:20] <poolie> it just seems unfortunate to make every caller type that
[09:20] <poolie> especially because it's meant to be an easy way to get good tests, and because i don't think tracking them will ever be useful
[09:20] <vila> they shouldn't need that if we ignore the first one (but take care of it if we need error reporting with correct line numbers)
[09:21] <vila> your note about the comment handling is right though...
[09:22] <poolie> oh, so you're saying you don't mind ignoring them, but you don't like the implementation of trimming the list
[09:22] <poolie> because it will change the line numbers?
[09:22] <vila> well, it will always be impossible to distinguish a comment *preceding* a command, from a comment in the expected output of the *previous* command
[09:23] <vila> yes, I think it's fine to ignore the first line if it's empty (while keeping track of line numbers) knowing that anal script writers can use """\
[09:23] <vila> but I think we shouldn't ignore the last one until someone encounter problems with it (which hadn't occur yet right ?)
[09:25] <poolie> it does happen
[09:25] <vila> and for the comments, well, the only robust solution I can think of is to allow \# when you want to use it literally
[09:25] <poolie> now that i don't ignore all blank lines, a bunch of tests fail
[09:25] <poolie> """
[09:25] <poolie> $ echo foo
[09:25] <poolie> foo
[09:25] <poolie> """
[09:25] <poolie> fails
[09:26] <poolie> because '\n'.split(that) has a '' at the end, after the last newline
[09:26] <vila> rhaa, bogus split
[09:26] <spiv> Trim leading and trailing blank lines?
[09:26] <poolie> a bit surprising hey
[09:27] <poolie> that's what i'm doing
[09:27] <spiv> Or use """\ ;)
[09:27] <poolie> yes, but i'd rather write the trim once, not \ a hundred times
[09:27] <poolie> especially because the message is confusing if you miss it
[09:28] <vila> poolie: you have 'if line == '': continue' indented, is that intended
[09:28] <vila> wow, look mom, no typo !
[09:31] <vila> poolie: and the tweak in _check_output looks suspicious too
[09:40] <poolie> the indenting is actually intentional
[09:41] <poolie> it's a somewhat misleading diff
[09:41] <poolie> we want to skip lines that are blank only because they contain a whole-line comment
[09:41] <poolie> why suspicious?
[09:42] <vila> poolie: yup, I'm digging
[09:42] <poolie> that's the change i was originally trying to make :)
[09:42] <poolie> so the interaction test works
[09:42] <poolie> test_confirm_action
[09:42] <poolie> needs it
[09:43] <vila> is that because test_confirm_action doesn't require that the user type <enter> ?
[09:44] <poolie> no, it's because bzr doesn't write out a \n at the end of the prompt
[09:44] <poolie> it leaves the cursor there and the user presses enter for us
[09:45] <vila> ouch, that's "expected output does not end with \n', ok
[09:45] <vila> right, that's what you say in the comment :)
[09:46] <vila> almost
[09:49] <poolie> isn't that nice? :)
[09:54] <poolie> then i can pop back one fram
[09:55] <vila> poolie: right, it's not clean but 100% DWIM
[09:55] <poolie> so my goals, which i suppose are yours too
[09:55] <poolie> are that it's easy to use
[09:55] <vila> poolie: what about http://paste.ubuntu.com/492989/ ?
[09:55] <poolie> when it fails, gives a decent message
[09:55] <poolie> and as much as possible lets you  be precise if you want to
[09:56] <vila> poolie: totally, the alternative would be to allow specifying an expected output *without* a final new line which means rewriting _script_to_commands for a little benefit
[09:56] <poolie> vila so it seems like the only actual difference in behaviour there is that you tolerate multiple leading blank lines
[09:56] <vila> poolie: overkill
[09:56] <poolie> which does not seem useful to me
[09:57] <vila> try putting a several lines long comment at the start
[09:58] <poolie> ok, let's add a test for that
[09:59] <poolie> that works
[10:00] <vila> and an empty line after the opening comment ?
[10:00] <vila> http://paste.ubuntu.com/492991/
[10:01] <poolie> vila i'm not convinced that should pass
[10:01] <poolie> istm letting people have a leading """ with no \ is useful
[10:02] <poolie> but letting them have arbitrary blanks is not actually helpful
[10:02] <poolie> and may get in the way of precision
[10:04] <vila> poolie: no, failing because they forgot to be precise before their first command is just annoying them for no good reason IMHO
[10:06] <vila> in _script_to_commands, the split is the bulk of the scanner while the loop is the parser, the comments are scanned in the loop to finish the scanning, and the parser should really kick in when the first command starts, but well, that's not so important, it just feels cleaner
[10:06] <vila> but the comment I deleted is obsolete and misleading now
[10:08] <vila> well cleaner and respecting newlines which del doesn't...
[10:09] <vila> anyway, don't spend time on it, this will matter more if/when we implement error reporting with linenos at which point whoever does it can fix it
[10:12] <lifeless> jml: so, testtools MP, I gave feedback, you seem undecided?
[10:15] <vila> lifeless, jml: As a data point, I came across 'a' and 'n' *this* wee-end and... found it akward
[10:15] <vila> week-end I don't even know what wee-end could mean...
[10:16] <lifeless> vila: EPARSE
[10:16] <vila> good :)
[10:16] <lifeless> I don't know what 'a' and 'n' you mean
[10:16] <vila> yeah 'b' :)
[10:17] <vila> at least this typo reveals my lack of understanding, I don't know what it's about so I can't type it properly :)
[10:17] <lifeless> vila: I'm still lost
[10:18] <vila> lifeless: I encountered 'a' and 'b' in assertEqualDiff and thought: "Wth ? Why not 'expected' and 'actual' ?"
[10:18] <lifeless> oh right
[10:18] <lifeless> yes
[10:27] <jml> lifeless, yes.
[10:27] <jml> lifeless, I'm otp atm.
[10:27] <poolie> hello jml!
[10:27] <lifeless> jml: yes
[10:27] <jml> poolie, hi
[10:27] <poolie> welcome back (if you are)
[10:27] <lifeless> jml: we can talk about it tonight/tomorrow if you want
[10:27] <poolie> vila i'd kind of like to just merge this
[10:27] <jml> lifeless, that'd be good.
[10:27] <poolie> that particular problem might be confusing but it hasn't bit me yet, anyhow
[10:28] <poolie> bug 636930 sounds familiar
[10:29] <poolie> ah bug 513432
[10:30] <poolie> spiv, if any, it looks like that has regressed in 2.2?
[10:31] <mgz> 633915 is the same bug and also new.
[10:33] <mgz> and 635874.
[10:35] <mgz> all of them involve launchpad, so the regression might be that side rather than in 2.2
[10:36] <vila> poolie: as in: "Thanks for review, but still" ? :-D
[10:36] <vila> grr, %2Bbranch still ?
[10:36] <poolie> yes, "but still" :)
[10:37] <poolie> i feel like that's enough of that particular yak for today
[10:39] <vila> poolie: ok, I've shelved my patch and I can trivially break your test, that's good enough :)
[10:40] <vila> poolie: moreover I get a "SyntaxError: No command for line ''" which is a perfect case to implement better error reporting with line numbers :-D
[10:44] <poolie> yeah that would be higher up my list
[10:44] <poolie> also there's something strange happening with ellipsis
[10:45] <lifeless> I triggered the elusive bzr: ERROR: Tree transform is malformed [('missing parent', 'new-1')]
[10:45] <vila> lifeless: hmm, with bzr itself or builddeb ?
[10:45] <lifeless> with bzr
[10:45] <lifeless> 2.2b3
[10:46] <lifeless> rev 5340
[10:46] <lifeless> I had added a directory and files in the dir, and I did shelve --all
[10:46] <vila> that's a bug then (all MalformedTransform are :-/)
[10:47] <vila> oh, shelve...
[10:47] <vila> or... did you have .pyc files there ?
[10:47] <lifeless> ignored files yes
[10:47] <lifeless> foo~ - editor backups
[10:48] <poolie> oh, wow
[10:48] <lifeless> sounds like you have an idea about whats going on; perhaps you could file the bug ?
[10:48] <vila> lifeless: can you try again with lp:~vila/bzr/323111-orphan-non-versioned-files ?
[10:48] <poolie> an actual bug, not a test suite bug
[10:48] <poolie> but not a very big one
[10:48] <lifeless> vila: i will tomorrow
[10:48] <vila> lifeless: ok, waiting for your feedback then
[10:48] <lifeless> vila: you could try it yourself :P
[10:48] <lifeless> vila: trunk, and then your branch
[10:51] <vila> lifeless: yeah right :) I'm busy fixing my branch.conf files with lp spitting bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/ urls everytime I create a new bzr branch :-/
[10:52] <lifeless> vila: you might like to file a bug on that
[10:52] <lifeless> its good that private branches are supported, but its a bit annoying
[10:52] <vila> lifeless: there isn't already one ??? I thought you mention tim related to that when I mentioned it... friday ?
[10:52] <lifeless> I did
[10:52] <lifeless> have you communicated with him about it though?
[10:53] <vila> no, I thought you and I were already discussing it, rats, it's a bad bug
[10:53] <vila> lifeless: should I file against lp or lp-code ?
[10:53] <poolie> ok, and now i get to fix the n-1th yak
[10:55] <vila> lifeless: oooooh, but the urls work...
[10:56] <vila> no need to fix my branch.conf files (I get fooled in a particular setup)
[10:57] <vila> hmm, fooled twice even, if they work today, the problem I encountered friday was either transient or fixed since
[10:58] <vila> lifeless: so bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/ will now always point to the dev focus right ?
[11:00] <lifeless> I don't know.
[11:00] <lifeless> I guess.
[11:00] <mwhudson_> vila: yes
[11:00] <lifeless> and anothe bug
[11:00] <lifeless> :!bzr shelve --all debian/python-fixtures.install
[11:00] <lifeless> Selected changes:
[11:00] <lifeless> -D  debian/
[11:00] <lifeless> -D  debian/python-fixtures.install
[11:00] <lifeless> bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-2'), ('missing parent', 'new-2')]
[11:00] <lifeless> (filed)
[11:01] <vila> mwhudson_: thx
[11:11] <bialix> poolie: still here?
[11:14] <poolie> hi, yes, though not for long
[11:14] <bialix> https://bugs.launchpad.net/bzr-website/+bug/636961
[11:15] <poolie> really
[11:15] <poolie> it should
[11:15] <poolie> thanks
[11:15] <poolie> i can't fix it but i'll ask
[11:15] <bialix> so far I'll use URL without www.
[11:16] <poolie> good idea
[11:26] <poolie> ok good night all
[11:38] <spiv> poolie: yes, bug 636930 did sound familiar, thanks for finding the bug it may be a regression of
[11:38] <spiv> I'll look into it tomorrow if no-one fixes before then.
[12:16] <jml> poolie, good night. we should have a chat some time.
[14:28] <nlisgo> 'bzr remove --keep file.php' keeps the file locally but removes it from repository. Is there a way to have it removed from repository but it when the repo is pull within a branch the file file.php is not removed within the branch
[14:29] <nlisgo> I know it also needs adding to the .bzrignore file
[15:44] <rubbs> I'm looking for a way to create a shared repo system that allows for devs to have their own branches in the shared repo, but not have write access to a specific branch, for example, the trunk. what's the best way to go about doing this?
[15:45] <rubbs> I basically want the space saving abilities of the shared repo (or similar) but need a gate keeping sort of system. I'm the only one who should have commit access to the trunk. Is this possible? or do I need the trunk to be in a separate repo?
[15:45] <maxb> You'll need everyone to have write access to the repository. You could enforce some application-level constraint on people who can change a branch tip
[16:01] <rocky> what's the quickest way to see what repo a branch comes from? (ie where all the rev info is stored)
[16:02] <Meths> bzr info ?
[16:02] <rocky> bzr info on a branch does not tell me where it's repo is located
[16:06] <ddaa> rubbs: maybe have a look at stacked branches
[16:06] <ddaa> they were designed for this kind of use case:
[16:07] <ddaa> space saving of shared repo, without giving everyone write access to everything
[16:08] <ddaa> http://doc.bazaar.canonical.com/latest/en/user-guide/stacked.html
[16:08] <rubbs> maxb: ddaa thanks. I'll take a look at stacked.
[16:09] <ScottK> Feedback from a satisfied customer on a proprietary project I'm working on that uses bzr: "`bzr merge --uncommitted --force --interactive`s. Neat." <-- the commenter is generally a die hard svn/centralized VCS traditionalist.
[16:11] <ddaa> separatists of the world, unite!
[16:11] <Kinnison> splitter!
[16:11] <rubbs> Hmm... seems like binding to a stacked branch could cause some problems.
[16:13] <ddaa> generally, it's better to enforce this kind of constraint by policy, or to deal with the additional disk usage of having multiple independent repos
[16:13] <rubbs> ddaa: yeah I htink I'm going to do that later. We would have the policy and I do trust the devs here, but I want that safety net if possible.
[16:13] <rubbs> I think I'm going to have a dev repo and a release repo
[16:14] <rubbs> disk space is cheap ;)
[16:15] <ddaa> stacked branches were designed for launchpad, which has a relatively unique set of constraints and level of control.
[16:18] <ddaa> hi Kinnison. Do you really, really hate the Romans?
[16:21]  * ddaa goes out to look at the bright side of life
[16:33] <maxb> rocky: Yes, it does, unless the repository is implicitly located within the branch bzrdir itself
[17:32] <dobey> can anyone help me figure out http://pastebin.ubuntu.com/493200/ ? the tarmac branch tests are all failing with this error in the PPA package builds. and rockstar and others seem to get the errors when running the tests, however, i am unable to get the errors to occur on my system.
[17:33]  * rockstar bets jam can help.
[17:33] <rockstar> He is smart.
[17:34] <jam> rockstar, dobey: starting with bzr 2.2 we require a configured username to commit, because we had a lot of problems with people forgetting to enter it, and then getting committers they didn't want
[17:34] <jam> for test suitse
[17:34] <jam> the bzr TestCase sets BZR_EMAIL as part of setUp()
[17:35] <rockstar> dobey, we should be using the bzr TestCase in those examples.
[17:37] <dobey> ah
[17:37] <dobey> hmm
[17:38] <dobey> TestCaseWithMemoryTransport?
[17:38] <dobey> also, i'd still like to know wtf i'm not getting the issue while everyone else is
[17:42] <jam> dobey: do you have the env variable set already?
[17:42] <Logomachist> Are we any closer to a bzr book getting released?
[17:42] <jam> again bzr's base TestCase clears out the environment variable while running
[17:43] <jam> I just double checked the code
[17:43] <jam> bzr's TestCase has a "_cleanEnviroment" function, called from TestCase.setUp()
[17:43] <jam> which sets BZR_EMAIL = None, and<EMAIL_ADDRESS>[17:44] <jam> if you are inheriting from a bzrlib TestCase you should get that for free
[17:44] <dobey> jam: no
[17:44] <jam> if you are just inheriting from unittest.TestCase then you won't
[17:44] <jam> and you'll want to do something similar
[17:44] <dobey> jam: if i run 'bzr whoami' in os.system() in the test, it prints the message that it's unset
[17:45] <jam> dobey: right, but that is because there are multiple ways of setting it
[17:45] <jam> what does "set" give?
[17:45] <jam> we will accept, EMAIL, BZR_EMAIL, or 'bzr whoami "foo bar<EMAIL_ADDRESS>[17:46] <dobey> none of those are in my env
[17:46] <dobey> and the tests are setting BZR_HOME to an empty dir
[17:47] <jam> dobey: IIRC, 'bzr whoami' only looks at the information you gave it
[17:47] <jam> (it doesn't look at the env vars)
[17:48] <jam> dobey: would you have an older version of bzrlib?
[17:48] <jam> like 2.1 ?
[17:48] <dobey> well it looks at the config too. and since it's printing the no value message, it is not reading it from my config
[17:48] <dobey> no, i'm on maverick and have bzr 2.2
[17:49] <dobey> this broke when the 2.2 release went into maverick, and i did some work on the tarmac tests to make the error go away
[17:49] <dobey> but it seems to have cropped back up somehow, though i can't make it happen on my machine
[17:52] <jam> dobey: sorry, I got disconnected for a second, last thing i see:
[17:52] <jam> 11:49:11 AM) dobey: but it seems to have cropped back up somehow, though i can't make it happen on my machine
[17:52] <jam> (11:50:00 AM) jam: dobey: this is for the tarmac test suite itself, right?
[17:52] <dobey> yeah, a subset of the tests in tarmac
[17:53] <dobey> i'm happy to switch it to using the appropriate bzrlib testcase, but want to understand why i seem to be the only person not seeing the issue :)
[18:30] <rubbs> quick question, is there a way to make a branch on the remote server without having to make commands via ssh. I'm basically saying can I from computerA do this: rubbs@computerA$ bzr branch bzr+ssh://computerB/branch1 bzr+ssh://computerB/branch2?
[18:31] <jelmer> rubbs, you should be able to, yes
[18:32] <jelmer> it would probably be slower than ssh'ing out to computerB or computerC though
[18:35] <rubbs> jelmer: thanks, that worked. I know it may be slightly slower, but at this point it's easier to explain it to newbies. Long story short, I want all their branches to be on the server so I can back up their work. They will use bzr to create their branch on the server, then branch+bind to their local machine from the new server branch. If I can get them to do it all with bzr commands, it will make more sense to them.
[18:35] <rubbs> after they are more comfortable I'll make sure they know they can do it faster
[18:36] <rubbs> I'm also toying with the idea of giving them sftp access only to our repo server
[18:39] <jelmer> rubbs: well, s/slightly/a lot/
[18:40] <jelmer> rubbs: rather than using local paths it would fetch all data locally to computerA only to send it off to computerB again
[18:59] <rubbs> jelmer: ah, I'll try to find another way around it.
[19:15] <servilio> hi all! is there a [stable|reliable] way to have composite/nested trees?
[19:45] <lifeless> servilio: the externals plugin seems popular
[19:46] <servilio> lifeless: will take a look, thanks
[19:47] <servilio> lifeless: just found the lp:~jelmer/bzr/foreign branch, but doesn't have any linked blueprints or bug report, so no info on when to expect it to be merged in core bzr
[20:01] <jelmer> servilio: What do you expect that branch do be?
[20:03] <servilio> jelmer: it is a hosting environment, I have one repo for the environment skeleton, and another for the different hosting buildouts
[20:03] <jelmer> servilio: I mean ~jelmer/bzr/foreign, what are you expecting it to do?
[20:04] <jelmer> servilio: it's just the branch where I keep changes to improve foreign branch support that haven't landed yet.
[20:04] <servilio> so, are there any options in the stock bzr to be able to create nested branches?
[20:05] <servilio> like "bzr co repo:hosting . && bzr co repo:buildouts/b1 b1"
[20:05] <servilio> and then being able to do bzr pull independently in b1 and its parent to pull updates
[20:06] <servilio> is that possible right now?
[20:06] <jelmer> servilio: no, see bug 402814
[20:11] <servilio> jelmer: just read the bug report
[20:12] <servilio> jelmer: but I don't have anything clear yet
[20:12] <servilio> jelmer: I mean, of current support and if it is possible to use it
[20:13] <jelmer> servilio: there is no support in bzr core for by-reference nested trees. There are some plugins that provide alternatives.
[20:14] <servilio> jelmer: and what's the prospect for its support in the core?
[20:15] <servilio> jelmer: any plugin that has some kind of forward compatibility with the approach that core will head to?
[20:15] <jelmer> servilio: it's a much requested feature and I believe the core team has plans to work on it in the near future.
[20:16] <jelmer> servilio: there is no plugin that uses the same approach as core will use.
[20:16] <servilio> jelmer: do you know of one that at least won't cause problems when migrating to the way core will support this?
[20:17] <jelmer> servilio: I don't think any of them will cause problems.
[20:19] <servilio> jelmer: any specific suggestion? or links?
[20:20] <jelmer> servilio: personally I would suggest bzr-externals
[20:21] <servilio> jelmer: thanks a lot
[20:21] <jelmer> it's the simplest but also the most straightforward
[20:21] <servilio> great
[20:26] <TresEquis> jelmer: that plugin is stable / recommendable at this point?
[20:26] <TresEquis> I think the last time I looked it was still not-quite-there, but that was a while ago
[20:27] <jelmer> TresEquis: it's stable as far as I know
[20:27] <servilio> TresEquis: just looked at the page, and right now looks to be at a useful and usable state
[20:28] <jelmer> TresEquis: I'd still consider it a stopgap fix until proper nested tree support lands though.
[20:29] <TresEquis> maybe that's the caveat I was remembering
[20:30] <TresEquis> I have a bunch of SVN-backed checkouts which use svn:externals, would be nice to be able to track those in bzr-svn
[20:30] <servilio> jelmer: anything that could be done to get proper support into the core faster?
[20:53] <chx> hi. i am trying diff one file in a checkout against its HEAD counterpart.
[21:00] <chx> nevermind :)
[21:02] <jelmer> servilio: I think it's already high on the list of things to work on of the Bazaar core developers, for more details the mailing list or that bugreport are probably the right places to ask.
[21:03] <servilio> jelmer: ok, thanks
[21:58] <ali> hi bzr masters, what does this error mean? bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('ShortReadvError', 'b22a569ce92096b22330c933808dc3b1.tix', '0', '772', '60')
[21:59] <ali> seems my repository is corrupted ("bzr check" reports the same thing, "bzr reconcile" failed with   File "/usr/lib/python2.5/site-packages/bzrlib/index.py", line 1074, in _parse_lines
[21:59] <ali>     raise AssertionError("%s %s" % (self._size, pos)) AssertionError: 772 59)
[22:16] <maxb> ali: Yes, that doesn't sound good. The first thing you could do is to try running "md5sum .bzr/repository/packs/*.pack" to check the status of some other files in your repository - for pack files, their name should be identical to their md5sum value
[22:25] <lifeless> maxb: hi
[22:25] <maxb> hello
[22:26] <lifeless> maxb: I've got your mail about packages on my to-read
[22:26] <lifeless> I've updated a couple of packages
[22:26] <lifeless> in sid
[22:27] <maxb> hmm, which ones?
[22:29] <lifeless> python-junitxml
[22:30] <lifeless> testrepository I think, or was it testtools
[22:30]  * lifeless checks archive mails
[22:30] <maxb> Ah yes, I have tracked them down in debian-devel-changes@ now
[22:31] <lifeless> yes, those two
[22:31] <lifeless> I need to do a testtools one
[22:31] <lifeless> May wait a few days, get a small improvement in cleanups into it first
[22:32] <maxb> Ok, once that appears, I'll do the PPA uploads for it, and re-propose promotion of testtools/subunit from the beta ppa
[22:33] <maxb> That reminds me, bzr-svn is also languishing in the beta ppa, I should do something about that
[22:36] <ali> ni, maxd, i just ran "md5sum .bzr/repository/packs/*.pack", all files' md5 matches file name
[22:38] <maxb> Well, that's a start. You might want to read through https://answers.launchpad.net/bzr/+question/96346 next - I don't know any more than what's there, but others here can possibly help
[22:38] <ali> thx, maxb
[22:54] <RomanMoz> Hello! How to launch bzr-gtk or bzr-explorer on Windows systems? Ten years I used Linux and forgot many things in windows
[22:55] <RomanMoz> Please...
[22:57] <ali> maxb, "bzr dump-btree" is even failing on my other good repositories, any ideas?
[22:58] <ali> build@dev-001:/bzr/server/.bzr/repository/indices$ bzr dump-btree b8e9c1d28ae7c837d4f1472535a58a03.iix
[22:58] <ali> bzr: ERROR: b8e9c1d28ae7c837d4f1472535a58a03.iix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
[23:08] <maxb> ali: hmm. odd. what format repository is that?
[23:08] <maxb> also, you could try dump-btree --raw
[23:08] <maxb> also, is the broken repository private data, or public?
[23:11] <ali> it is private. tried with "--raw", none of the indices are recorgnized
[23:12] <ali> i tried .six, tix, rix, iix files. bzr version 2.0.4 on 64-bit ubuntu, weird
[23:12] <lifeless> ali: what does 'bzr info -v' show - you can elide the paths, but we need the format data
[23:12] <ali> ali@dev-001:/bzr/server/.bzr/repository/indices$ bzr info -v
[23:12] <ali> Shared repository (format: pack-0.92)
[23:12] <ali> Location:
[23:12] <ali>   shared repository: /glass/sfw/bzr/repo/server
[23:12] <ali> Format:
[23:12] <ali>        control: Meta directory format 1
[23:12] <ali>     repository: Packs containing knits without subtree support
[23:12] <ali> Repository:
[23:12] <ali>       7522 revisions
[23:13] <lifeless> ok, so this is not a btree based format
[23:13] <lifeless> the indices are linear arrays with bisection used, instead of a btree.
[23:14] <ali> i see, the repository was created two years ago with old bzr version, i guess
[23:15] <ali> anyway i can migrate to the new btree repository? (if i can fix this one first)
[23:25] <maxb> upgrading's easy. fixing this, however, may be rather hard
[23:26] <ali> i reserved the crime scene, and just rolled back to this morning's backup. :-) If you need me to report a bug or something let me know
[23:27] <lifeless> ali: it looks like you had a write to an index get truncated by your filesystem
[23:27] <lifeless> ali: without notification to bzr
[23:27] <lifeless> the code in question is:
[23:27] <lifeless>         for line in lines:
[23:27] <lifeless>             if line == '':
[23:27] <lifeless>                 # must be at the end
[23:27] <lifeless>                 if self._size:
[23:27] <lifeless>                     if not (self._size == pos + 1):
[23:27] <lifeless>                         raise AssertionError("%s %s" % (self._size, pos))
[23:27] <lifeless> so we got:
[23:28] <lifeless>  - an empty line (EOF shows as this)
[23:28] <lifeless>  - we know the size of index we -wrote-
[23:28] <lifeless>  - must be at the end of the index, but its not
[23:28] <lifeless> 772 is the file size expected
[23:28] <lifeless> 59 is the file size found
[23:29] <ali> hmm, any reason why filesystem truncate the file? the file size is too big?
[23:30] <lifeless> not in this case, 772 bytes is very small :)
[23:31] <lifeless> 59 bytes is an odd amount to truncate too
[23:32] <lifeless> the other possibility is that there is garbage in the index (again, almost certainly a fs bug, we've not seen bzr write nonsense stuff out in the index as a bug)
[23:32] <poolie> hi
[23:33] <poolie> we have seen a few people complaining their fs truncated the files to 0 bytes
[23:33] <poolie> 59 is indeed odd
[23:33] <ali> i can send you the idx files if you want to take a look
[23:34] <ali> btw, the server was stable and running for the last 4 months, nothing weird today either
[23:43] <poolie> ali, if you record a bug and attach those files that would help
[23:55] <poolie> hi jam?


[09:01] <Laney> xnox: did we ever figure out that serial-getty thing?
[09:01] <xnox> Laney, nope, don't think so
[09:01] <Laney> hmm
[09:05] <Laney> stgraber: if you've got some time later, could you help us figure out where<EMAIL_ADDRESS>is coming from in ubuntu images: containers please?
[09:05] <Laney> stgraber: it blocks the system from being considered 'running' until it times out
[09:07] <xnox> and it appears to be generated on first boot only; not subsequent ones; as if some side-channel is used to configure the container on first boot, which systemd serial generator manages to spot but then that goes away
[11:28] <LocutusOfBorg> sbeattie, intel-microcode sync now? :)
[11:58] <menace> why does ubuntu not fix gnupg for 16.04, though it is in main and should therefore get security upgrades? there's a security update
[12:06] <rbasak> menace: are you sure it's not fixed? What's the CVE?
[12:06] <rbasak> menace: use https://people.canonical.com/~ubuntu-security/cve/ to look it up please.
[12:10] <mdeslaur> this? https://usn.ubuntu.com/3675-1/
[12:11] <mdeslaur> menace, rbasak ^
[12:27] <menace> yep, why is gnupg2 not fixed in 16.04?
[12:27] <jdstrand> mdeslaur: ^
[12:28] <menace> sorry for the long reaction
[12:29] <mdeslaur> hrm, that's a good question
[12:29] <mdeslaur> sbeattie: ^
[14:33] <r4co0n> Hi, I come over from #ubuntu, where I just asked if a backport of a recent version of source package nghttp2 would be accepted for xenial? We have this as a build dependency here and would like to avoid building it too.
[14:35] <r4co0n> upstream has 1.32.0, as does buster - xenial, which we are targetting, only has 1.7.1 available, cosmic is at 1.30.1.
[14:37] <rbasak> r4co0n: see https://wiki.ubuntu.com/StableReleaseUpdates and/or https://wiki.ubuntu.com/UbuntuBackports
[14:40] <r4co0n> rbasak, I think "Continued Functionality of Reverse-Dependencies" is what will rule out backporting this.
[14:41] <r4co0n> thanks for your help
[15:43] <winksaville> sarnold: All is good, it looks to me that gcc-7 was used to compile the toolchain, clang was used in tests.
[15:44] <winksaville> Not what I was hoping to see, as I've found compiling llvm with clang but the app (ponyc) with gcc works, where as if both are compiled with gcc it fails. So I'm going to try to figure out why, we'll see if I'm successful :)
[15:56] <mdeslaur> r4co0n, rbasak: nothing appears to use nghttp2 in xenial though, so it may still be a possibility: $ reverse-depends -r xenial src:nghttp2
[15:56] <mdeslaur> No reverse dependencies found
[15:57] <mdeslaur> we pretty much disabled everything from using nghttp2 in xenial with the intent on possibly re-enabling at a later date. Updating it to a more recent version would possibly make sense
[16:13] <r4co0n> mdeslaur, that sounds promising. I will look into backporting this, if I get it to work as expected locally, I will get back here.
[16:14] <nacc> r4co0n: if you haven't seen it, `backportpackage` may be helpful (you can test in  PPA)
[16:30] <slangasek> cjwatson: hi, so LP: #1451194 has been a nuisance for a while but has bubbled up the priority list a bit.  I would like us to fix this by having openssh itself (as profile code shipped in the package, not directly in the daemon...) detect when an invalid locale has been passed, and squash it to C.UTF-8.  Do you have opinions?
[16:32] <cjwatson> slangasek: I'd rather see somebody help to push forward something like Damien's suggestion towards the end of https://bugzilla.mindrot.org/show_bug.cgi?id=1346, personally
[16:33] <cjwatson> I don't think any of this is particularly straightforward
[16:33] <cjwatson> slangasek: but I'll review a patch to profile code if somebody wants to come up with one, I suppose
[16:37] <slangasek> cjwatson: "could somehow search the local locale database for a good fit" that one?
[16:38] <slangasek> I'd fear that would get bogged down in upstream design discussions for rather a long time
[16:38] <slangasek> am I wrong?
[16:39] <slangasek> and doing it in profile of course has the limitation that it's ineffective when you're not running a shell
[16:39] <cjwatson> slangasek: it might take a while to sort out, but I'm concerned about yet another profile-level hack that will have corner cases, be Debian-specific, etc. etc.
[16:39] <slangasek> ok
[16:39] <cjwatson> I acknowledge it may be better than nothing at all, but still, it's not my preferred optiomn
[16:40] <cjwatson> *option
[16:40] <cjwatson> something that's been suggested by upstream to begin with seems like a good candidate for not getting too hopelessly bogged down
[16:40] <slangasek> so we currently have /etc/profile.d/Z99-cloud-locale-test.sh which looks at the locale settings, detects invalid ones, but only screams about it rather than fixing up
[16:40] <slangasek> maybe we should improve that in cloud-init, and then also work on the upstream openssh solution
[16:40] <rbasak> I suggested doing it in PAM rather than in profile. I think that'd work for non-shell cases too.
[16:41] <slangasek> right, otoh if there's appetite for doing it in openssh directly, that's even more comprehensive
[16:43] <slangasek> smoser: ^^ do you have concerns about making /etc/profile.d/Z99-cloud-locale-test.sh do a locale fix-up instead of screaming?  (to eventually become a no-op if we change the openssh upstream behavior)
[16:57] <smoser> slangasek: what is "fixup" ?
[16:57] <slangasek> smoser: replace invalid locales in the environment with C.UTF-8
[16:57] <slangasek> smoser: (instead of a loud banner)
[16:58] <smoser> the fallout of doing so is 2 things
[16:58] <slangasek> smoser: at minimum for en_* locales that we haven't generated; but I think we should give the same experience to users of all locales, English or not
[16:58] <smoser> a.) the user doesn't get told how to fix this situation on their new instance
[16:59] <smoser> b.) if they already knew hwo to fix it, theyd' have to exit and come back in to get it applied. versus just having it fixed by 'apt install'
[16:59] <smoser> its not "english or not"
[17:00] <smoser> its instance has a locale present or not.
[17:00] <smoser> quite possibly an image built other than by canonical official images has multiple locales.
[17:00] <slangasek> the user gets told how to fix it; in English.  if they needed a non-English locale, this is not the most helpful.
[17:01] <smoser> slangasek: we're not going to fix all the places that a non-english speaking person who ssh's to a system has to read english.
[17:01] <smoser> at least not in cloud-init
[17:01] <smoser> it may not be perfect, but I suspect that the majority of users are able to figure it out.
[17:02] <slangasek> a well-localized system should not require a user to read any English at all
[17:02] <slangasek> if the user wanted non-English, they can pick their locale in cloud metadata
[17:03] <smoser> so was the message actually causing problems ?
[17:03] <smoser> ie.... could we
[17:03] <slangasek> if I don't speak English and I log into the system and get English, I'm going to google for help in my own language
[17:04] <cjwatson> The message doesn't cause a major problem IMO; not having a working locale can, though
[17:04] <smoser> slangasek: well, honestly likely if you see:
[17:04] <slangasek> the banner is not necessarily useful, because I don't necessarily understand any of the words printed
[17:04] <smoser>  apt-get install locale-cc
[17:04] <smoser> you might guess that copy and paste is going to fix your problem
[17:04] <cjwatson> (IMO in all cases where it does cause a problem it's a bug at that point, but tackling it that way hasn't always been super-effective)
[17:04] <smoser> but anyway...
[17:04] <smoser> so... what about
[17:04] <smoser> a.) give a message stating how to fix
[17:05] <smoser> b.) set C.utf-8
[17:05] <slangasek> smoser: the message is intrusive, particularly for users who *don't* care about translations because their local locale is en_US.UTF-8 and their remote locale should be C.UTF-8
[17:05] <smoser> or was the message itself problematic to something.
[17:05] <slangasek> smoser: we have had a complaint about the message per se
[17:05] <slangasek> and per above, I don't think it's actually the right place to tell the user how to fix it
[17:05] <slangasek> was this initially added based on user requests?
[17:06] <smoser> this was originally added under request of a partner who was heavily non-english
[17:06] <slangasek> ok
[17:06] <smoser> (from my memory)
[17:06] <slangasek> so that's a useful datapoint
[17:06] <slangasek> smoser: I certainly think that "print message, then map to C.UTF-8" is better than status quo
[17:06] <slangasek> I would still prefer the mapping, with no message
[17:07] <smoser> slangasek: i dont understnad why youd' prefer that though.
[17:08] <smoser> other than filling up stderr with non-useful information on the first time connection to a new instance for the user.
[17:08] <slangasek> smoser: because I think it's correct for every US user to have en_US.UTF-8 as their local locale, and I think it's correct to have C.UTF-8 as the default remote locale on all cloud instances, and I think it's annoying to print a large banner message in this case
[17:08] <smoser> i can see myself complaining about cloud-init writing nonsense to my stderr that was breaking some scripts i have.
[17:08] <slangasek> which is why I mentioned that we might special-case English here
[17:09] <smoser> but then i can see the other side of myself saying ... "well set your locale to C.UTF-8 and that wont happen... you should do that anyway if you're looking at output."
[17:09] <slangasek> which also leads to my observations about the irony of presenting a message in English only to those users who request non-English
[17:10] <slangasek> "set your locale to C.UTF-8" - nack that is not the correct locale for the client, and having to configure your ssh client to DTRT is noisome
[17:10] <smoser> meh. i get bug reports in non-english. i can usually make out what they mean. and i'm about as non-french (or dutch or spanish or chinese) speaking as a person can be.
[17:10] <smoser> i'd only ever complain about automation
[17:11] <smoser> that is the only time when it can be considered annoying.
[17:11] <smoser> if you're parsing machine output, C.UTF-8 is the right thing.... or, if you wanted to parse xx_XX, then well, you should be setting up the locale so the message was useful.
[17:13]  * cjwatson takes that as a challenge to start filing bug reports in smoser's direction in Irish
[17:13] <smoser> as long as they have stack traces
[17:13] <cjwatson> heh
[17:13] <smoser> then i'm good.
[17:14] <Nafallo> reminds me about when I had a Welch manager that changed language when he was in the mode. he stopped when I talked Swedish at him ;-)
[17:14] <slangasek> smoser: so there's the other subcase that we would care about, which is that I think this message should be suppressed on minimal images
[17:14] <smoser> slangasek: i'm not completely bent on keeping exactly what is there. as you might suspect, it doesn't affect me
[17:14] <Nafallo> s/mode/mood/
[17:15] <smoser> but i dont know where else you might enlighten the user on how to fix this.
[17:15] <slangasek> smoser: minimal images have all locales stripped etc and are not meant for human use and the user gets a separate message in motd telling them how to unminimize
[17:15] <smoser> the human user gets a message
[17:15] <smoser> the one that the image was not designed for
[17:15] <smoser> :)
[17:16] <slangasek> yes
[17:16] <smoser> is that message translated ?
[17:16] <slangasek> but as they already get a message about it being minimal and how to make it human-friendly, we should fold any locale information into that message
[17:16] <slangasek> not have cloud-init present one separately
[17:19] <smoser> i'm also perfectly fine to look one other place before doing nothing in Z99-cloud-locale-test.sh
[17:19] <smoser> such that minimal images could just contain configuration that tells cloud-init you're not interested in that.
[17:23] <smoser> or, i guess if you  put something that changed the lcoale as you're suggesting in the minimal image, as long as it ran before Z99, then cloud-init would see the changed values and would not print anything.
[17:23] <smoser> right?
[17:24] <smoser> echo 'LC_ALL=C.utf-8' > /etc/profile.d/Z98-minimal-cloudimage.sh
[17:28] <slangasek> smoser: that makes it even more difficult for a user to set a different locale if that's what they want.  If cloud-init is going to print anything at all in any cases, I'd rather we have it a) not print when the invalid locale is en_*, and b) not print when we're running on an image which is discernably Ubuntu minimal
[17:29] <slangasek> smoser: but, if the end state is that openssh is going to avoid ever passing an invalid locale to the target environment, this script in cloud-init will no longer print anything, ever
[17:31] <slangasek> so if that's the direction we're going, I don't see a reason not to change cloud-init now to match that
[17:32] <smoser> $ cat /etc/profile.d/Z98-minimal-cloudimage.sh
[17:32] <smoser> LC_ALL=C.UTF-8
[17:32] <smoser> that does seem to work.
[17:35] <slangasek> yes, but it's wrong to have to add this as additional config on the image
[17:36] <smoser> i dont know that that is true.
[17:36] <smoser> you're suggesting its wrong to change the thing that wants behavior changed. its better to change everything.
[17:36] <smoser> but again, i'm not really oppposed to your suggested change if its thought through. i am opposed to change on a whim.
[17:36] <slangasek> I'm saying it's wrong to solve this by scattering more unmanaged config files on the image
[17:37] <smoser> it doesnt have to be unmanaged.
[17:37] <slangasek> that increase what the user has to contend with if they do know what they're doing and do want to enable a locale on a minimal image
[17:37] <slangasek> we don't install any additional packages in the minimal image
[17:38] <ErichEickmeyer> Okay, I've gone through the wiki and I give up. We (the Ubuntu Studio team) have a number of ubuntustudio-* package updates that we need to get into Cosmic. How do we go about doing that?
[17:41] <tsimonq2> ErichEickmeyer: Meaning, new packages or existing package updates?
[17:41] <ErichEickmeyer> existing package updates.
[17:41] <tsimonq2> What kind of updates? Do you have a debdiff?
[17:41] <ErichEickmeyer> Basically, the first four in https://code.launchpad.net/~ubuntustudio-dev
[17:42] <slangasek> ErichEickmeyer: does the Ubuntu Studio team not have any uploaders for your packages?
[17:42] <ErichEickmeyer> slangasek: We do not currently, the ones we had are AWOL or burnt-out during the last two years.
[17:43] <tsimonq2> ErichEickmeyer: I can help y'all out this time, but ditto slangasek. :)
[17:43] <ErichEickmeyer> There were a lot of issues leading to it, but we're picking-up the pieces.
[17:44] <slangasek> ErichEickmeyer: from a flavor governance POV, it should be a very high priority for you to get uploaders on your team, either by convincing existing Ubuntu developers to become part of the team or by having team members apply for uploader rights
[17:45] <tsimonq2> ErichEickmeyer: It would be great if these could be git instead of bzr. ;P
[17:46] <ErichEickmeyer> tsimonq2: We have one in git, and we're slowly migrating. I might take-up that on the ones I've touched.
[17:47] <ErichEickmeyer> slangasek: Agreed. Studio was on the verge of dying before a few of us got busy, but those of us that "rescued" it don't have uploader rights.
[17:48] <tsimonq2> ErichEickmeyer: I have a script that converts them super easily. If you add me to a team I can JFDI.
[17:48] <ErichEickmeyer> slangasek: We used to have Ross Gammon, but we rarely if ever see him, and sakrecoer is, for lack of a better term, out.
[17:48] <ErichEickmeyer> tsimonq2: Done.
[17:48] <tsimonq2> ErichEickmeyer: I might also invest some time in cleaning up these packages, so that when someone else jumps in, they aren't coming into a labyrinth of outdated packaging (been there done that). ;)
[17:49] <ErichEickmeyer> tsimonq2: Sadly, that's going to be the case. We have a ton of packages that are leftover from Trusty. :P
[17:49]  * tsimonq2 shudders
[17:49] <tsimonq2> Challenge accepted.
[17:49] <ErichEickmeyer> LOL
[17:50] <slangasek> ErichEickmeyer: I know Ross applied for uploader rights last November but I don't know if that was granted... and I hadn't heard that he'd idled out
[17:50] <ErichEickmeyer> slangasek: That's correct, pretty much idled out.
[17:50] <ErichEickmeyer> He simply has no time.
[17:51] <ErichEickmeyer> same with sakrecoer.
[17:52] <ErichEickmeyer> This is what happens when a flavor is on the verge of dying and somebody gives it CPR.
[17:54] <ErichEickmeyer> I've been lucky to be able to keep OvenWerks and eylul, but everyone else is new (including me).
[17:54] <ErichEickmeyer> Though eylul is pretty burnt-out from the last two years as well.
[17:56] <tsimonq2> ErichEickmeyer: Seems I need to be a member of Ubuntu Studio Core to have permissions to push to lp:ubuntustudio-icon-theme.
[17:57] <ErichEickmeyer> tsimonq2: Oh man, sakrecoer is still the owner, and he was going to hand ownership to me 2-3 weeks ago but never did. :/
[17:57] <tsimonq2> ErichEickmeyer: Oh well. We can make it work for now.
[17:58] <tsimonq2> I'll just push to a different-yet-sane location.
[17:58] <ErichEickmeyer> tsimonq2: I just changed the maintainer. Should be good now.
[17:59] <tsimonq2> ErichEickmeyer: Thanks.
[17:59] <ErichEickmeyer> Np
[18:00] <tsimonq2> ErichEickmeyer<EMAIL_ADDRESS>is still your mailing list?
[18:00] <ErichEickmeyer> tsimonq2: Yes.
[18:00] <tsimonq2> Cool.
[18:00] <tsimonq2> Actually, let's continue this in #us-dev :)
[19:02] <Deknos> ahoi, is there a information, why ubuntu did not patch gnupg2 for ubuntu 16.04?
[19:08] <sbeattie> Deknos: sorry, oversight, working on it.
[19:10] <Deknos> ah, okay, that's okay, no problem, thank you!
[21:16] <slangasek> smoser: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1134036/comments/20
[21:17] <slangasek> smoser: and I've polled some non-native English speakers, so far nobody has told me I'm insane for wanting to remove the message
[21:17] <slangasek> smoser: but I give you options on what type of patch you'd prefer for cloud-init
[23:32] <tych0> smoser: hi, i have a question. i'm using uvtool to try and test some new kernels
[23:33] <tych0> when i install my new kernel and reboot, it renames my vm's NIC
[23:33] <tych0> so i followed the instructions in /etc/netplan/*cloud-init.yaml
[23:34] <tych0> about putting network: {config: disabled} in /etc/cloud/cloud.cfg.d somewhere
[23:34] <tych0> but it still configures my interface :(
[23:35] <tych0> is there some way i can get it to not configure? or otherwise get it to b esmart enough to rename the interface?
[23:50] <rbasak> tych0: for testing, if you have only one NIC, I believe you can set net.ifnames=0 on the kernel commandline and it should always be called eth0. Does that help?
[23:59] <tych0> oh
[23:59] <tych0> that does help :)
[23:59] <tych0> let me try.


[18:52] <guampa> greetings
[19:56] <AlanBell> going to schedule an IRCC meeting for later in the week
[19:57] <IdleOne> Wednesday is good for me
[19:57] <IdleOne> :P
[19:59] <AlanBell> yeah, might do wednesday, will see what the rest of the IRCC are like for that
[19:59] <AlanBell> Sunday evenings are harder than they used to be for some reason


[22:22] <jim-intel> Hi, I have a question.It is kinda off topic. But I want to install surveillance ip cameras in my house. I have an Ubuntu PC with two LAN ports. I want all of the poe cameras with static ip4 addresses. All Cameras are connected to a switch and also the PC with one of the lan ports. The second lan port is connected to my router/internet. Is this
[22:22] <jim-intel> setup safe enough to hide the cameras from the internet or are there possibilities in the camera software that they find the internet trough my PC? Sorry for that tinfoil noob question but I don't trust these IP cameras ;)


[19:30] <loki77> hi - I'm trying to convert postgresql 9.1 to using upstart.  It works fine for the most part, but my post-start script hangs forever, and basically makes it so I can't do anything with the job, whenever there's an issue with starting postgres.  I tried having it fail after 10 retries, but I couldn't figure out how to then let upstart know that the job had failed from within post-start, as exit 1 doesn't seem to do what I'd hoped.. an
[21:50] <xnox> we should add to the topic "Please pastebin jobs if need help troubleshooting them"
[21:51] <xnox> wait he posted to mailing list. That's fine then.