[02:54] <aus_mal> hi everyone. can anyone help me with lowering screen brightness past the lowest setting?
[18:30] <kaisoz> hi
[18:45] <PaulfraOSAA> kaisoz: lo
[18:59] <mimecar> hi
[20:08] <Guest36640> how to install ubuntu touch on mtk 6582
[20:12] <Guest36640> hi
[20:12] <Guest36640> how to install ubuntu touch on mtk6582?
[20:13] <Guest36640> how to install ubuntu touch on mtk6582?
[20:13] <mimecar> what's your  device?
[20:14] <Guest36640> gionee p3
[20:14] <mimecar> I don't know if that device can run Ubuntu Touch
[20:15] <Guest36640> any version that i can run?
[20:17] <mimecar> I think not
[20:18] <mimecar> there was a link with supported devices
[20:18] <mimecar> https://wiki.ubuntu.com/Touch/Devices
[20:19] <TheKit> Guest36640, hard, unless you have kernel sources for your device and want to do the porting
[20:20] <Guest36640> ok.. thanks
[22:13] <mondte> Hi , i have just flashed the Nexus 7 Wifi 32 GB (Flo)  Ubuntu Touch but ubuntu says its only 12 GB Disc Space on it
[22:13] <mondte> what can i do?
[22:29] <mondte>  i have just flashed the Nexus 7 Wifi 32 GB (Flo)  Ubuntu Touch but ubuntu says its only 12 GB Disc Space on it
[22:29] <mondte> what can i do?


[06:09] <pitti> Good morning
[06:12] <cpaelzer> good morning
[06:16] <pitti> mvo: good morning!
[06:16] <pitti> Preparing to unpack .../snap-confine_1.0.30_ppc64el.deb ...
[06:16] <pitti> Unpacking snap-confine (1.0.30) ...
[06:16] <pitti> dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_ppc64el.deb (--unpack):
[06:16] <pitti>  trying to overwrite '/lib/udev/rules.d/80-snappy-assign.rules', which is also in package ubuntu-core-launcher 1.0.29+1ubuntu1
[06:16] <pitti> mvo: ^ known?
[06:16] <pitti> this serial-kills workers during dist-upgrade, I'll see to turning that into a proper failure
[06:22] <pitti> +Breaks: ubuntu-core-launcher (<< 1.0.29)
[06:22] <pitti> +Replaces: ubuntu-core-launcher (<< 1.0.29)
[06:22] <pitti> ^ this isn't enough, must be << 1.0.30
[07:01] <mvo> pitti: uh, thank you! sorry for this, will fix right away
[07:01] <pitti> I deployed the autopkgtest fix now, should go from "in progress" to "failed" in the next run
[07:03] <mvo> ta
[09:08] <seb128> SRU team, is there any reason the glib/xenial SRU is not copied to updates? it has been marked verification-done at the start of the month and didn't move since ... is that because of the "regression in autopkgtest"?
[09:09] <seb128> Laney, ^ did you look at those/got pinted about them?
[09:09] <Laney> no
[09:15] <Laney> i retried them
[09:17] <seb128> now or before and they failed again?
[09:18] <Laney> 4 minutes ago
[09:18] <seb128> k, let's see if that improves things
[09:18] <Laney> but nobody told me they don't release it because of this
[09:18] <seb128> nobody from the SRU team pinged you saying the SRU was on hold because of that?
[09:18] <seb128> I'm assuming that's why they didn't copy over but I'm not sure
[09:19] <pitti> presumably that, yes; i. e. needs confirmation that the regressions are unrelated and just because of flakiness; some of them might need overides in xenial
[09:33] <rbasak> nacc: I already sent it in Debian bug 825079
[09:35] <cpaelzer> RAOF: rbasak: as last uploaders I wanted to check with you if it is ok if I start a merge of dovecot  2.2.22 -> 2.2.24 and then look again into bug 1524526 as we discussed
[09:36] <rbasak> cpaelzer: go ahead. Thank you!
[09:40] <seb128> pitti, thanks for copying the verified SRUs over!
[09:40] <pitti> no worries!
[09:46] <cpaelzer> rbasak: I asked via mail a while ago, but I can't even find my own mail so no chance to complain :-) - but could you usd-import dovecot for me?
[10:06] <rbasak> cpaelzer: I'm trying. I've not actually done an import before but it's about time that I did. Just figuring out getting a working environment.
[11:02] <cpaelzer> rbasak: any luck with the env to import?
[11:02] <rbasak> Still on it, sorry.
[11:02]  * rbasak is installing usd-import dependencies
[11:03] <cpaelzer> rbasak: not a problem, just needed to check
[11:03] <cpaelzer> I'm prepping myself by parsing through debdiffs - so I'm ready to go then
[11:03] <cpaelzer> already found a "changelof only" change :-)
[11:27] <mdeslaur> chiluk: did you see ted's comment in bug 1592862? could you re-check and see if we can just sync it now?
[11:59] <cpaelzer> rbasak: I'd have my prep by debdiff analysis ready - a lot cruft to clean up in that package already - without git helping me to identify more
[12:00] <cpaelzer> rbasak: I'm going for a bit of soccer with my son which should give you more time to get the import ready - if not when I'm back I'll try to pick something else for the rest of the day
[12:00] <rbasak> cpaelzer: OK. The import's been going for a while. Now up to Natty.
[12:21] <rbasak> cpaelzer: dovecot import pushed
[12:21] <rbasak> nacc: ^^
[12:21] <rbasak> Hope I did it right!
[13:16] <cpaelzer> rbasak: thanks a lot for th eimport
[13:22] <Laney> seb128: it's magically all cleared
[13:22] <Laney> let's see if it more magically gets copied now
[13:22] <seb128> Laney, \o/
[13:35] <cpaelzer> rbasak: nacc: did something on the workflow change dastrically? - I easily able to identify and tag my old/debian, new/debian, old/ubuntu; but when I want to rebase from old/ubuntu to old/debian to start breaking into reconstruct and logical things fail
[13:35] <cpaelzer> rbasak: maybe the history is broken (or other than I expect) - maybe one of the few algo rewrites is not yet in my mental process
[13:37] <cpaelzer> rbasak: in the tree you pushed rebasing from ubuntu/yakkety to import/1%2.2.22-1 (which is old/debian) tries to give me the full history into the rebase -i
[13:39] <rbasak> cpaelzer: use "usd-merge reconstruct old/ubuntu". Not a drastic workflow change but it makes things rebaseable again so the old workflow will still work once that's done.
[13:44] <cpaelzer> rbasak: thanks
[13:45] <cpaelzer> rbasak: I should just forget all old I had in mind and follow the new doc at https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow to ensure I'm not on old tracks
[13:46] <rbasak> cpaelzer: it's very similar. I think "deconstruct" and the need for "usd-merge reconstruct" first are the only major changes.
[14:05] <chiluk> mdeslaur: will do..
[14:24] <pitti> Laney: FYI, in case you check: I disabled the autopkgtest workers on cyclops (armhf Calxeda nodes) on purpose
[14:25] <pitti> Laney: there are now three lxd-armhf[123] arm64 instances on bos01 driven by the autopkgtest-lxd-worker/0 service
[14:25] <pitti> Laney: last week we found some workarounds how to make bug 1531768 a bit less devastating, so I'd like to see how they are holding up
[14:29] <Laney> pitti: okay --- your last post in the bug doesn't sound good though
[14:30] <Laney> will you bring up arm64 workers if this is good now?
[14:30] <pitti> Laney: yeah, but at least with nohz=off they seem to survive for hours instead of minutes, and I have the auto-reboot watch dog in place
[14:31] <pitti> Laney: arm64> this works in principle (I tested it last week)
[14:31] <pitti> Laney: however, we don't have enough capacity ATM
[14:31] <pitti> Laney: and I filed an RT about reboot being broken on arm64
[14:31] <pitti> that's kind of a hard blocker
[14:32] <pitti> well, I commited some workaround to autopkgtest to do "nova reboot --hard" after 5 minutes timeout, but this is both ugly and also utterly slow
[14:32] <Laney> heh
[14:33] <pitti> Laney: but I also want to collect some experience wiht the new lxd runners in general
[14:33] <Laney> surprised nobody else has pressured for reboot to be fixed
[14:33] <pitti> Laney: e. g. this morning I noticed that internet access through proxy was broken (fixed now)
[14:33] <pitti> and there might be some tests that behave differently under lxd than under lxc
[14:34] <pitti> if that works, I'll ask for opening the firewall between PS and the two s390x nodes, and convert them to the new lxd structure
[14:35] <pitti> Laney: not sure if you saw the autopkgtest-lxd-worker/0 service box yet; it's fairly similar to the cloud worker box, except that it talks to LXD remotes instead of nova
[14:36] <pitti> Laney: I just put it onto a new service as autopkgtest-cloud-worker is already fairly loaded with 60 parallel tests
[14:43] <Laney> pitti: I think I saw this before
[14:43] <Laney> how are the SS instances themselves managed?
[14:43] <Laney> cloud-worker starts X and then each one can have Y containers?
[14:44] <pitti> Laney: the three lxd-armhf* SS  instances are created manually by me, by nova boot'ing with userdata https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/armhf-lxd-slave.userdata
[14:45] <pitti> Laney: and then adding their IP and number of parallel LXD containers to credentials/lxd-remotes.conf on wendigo
[14:45] <pitti> Laney: and then juju set autopkgtest-lxd-worker lxd-remotes="$(cat credentials/lxd-remotes.conf)"
[14:45]  * Laney blinks
[14:45] <pitti> Laney: this tells the autopkgtest/lxd-worker instance about the new lxd remote, and it'll start running workers on it
[14:46] <pitti> Laney: (deploy.sh uses this file automatically)
[14:46] <pitti> Laney: I'll wikify all this soon, once it proves itself in production
[14:46] <pitti> and I'm sure we can automate this some more
[14:47] <pitti> Laney: blinks> what's unclear? happy to explain (I don't like bus factor == 1..)
[14:48] <Laney> pitti: Initially all of the configuration in that file - seems painstakingly worked out, and then the list of stpes that I'm not sure I'd get right. :)
[14:48] <Laney> wiki will help
[14:49] <pitti> Laney: yeah, the userdata file is a horrible collection of bug workarounds and lots of black magic to create a btrfs partition
[14:49] <pitti> Laney: we don't have cinder on scalingstack, so no volume-create and friends
[15:13] <LocutusOfBorg> dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_amd64.deb (--unpack):
[15:13] <LocutusOfBorg>  trying to overwrite '/lib/udev/rules.d/80-snappy-assign.rules', which is also in package ubuntu-core-launcher 1.0.29+1
[15:13] <LocutusOfBorg> wow
[15:13] <pitti> LocutusOfBorg: told mvo this morning, the Breaks/Replaces: has the wrong version
[15:13] <LocutusOfBorg> thanks
[15:14] <LocutusOfBorg> from time to time I upgrade my yakkety machine :)
[15:14] <pitti> LocutusOfBorg: err, you have -proposed enabled?
[15:14] <LocutusOfBorg> yes
[15:14] <pitti> *shrug*, you get to keep both halves
[15:14] <pitti> seriously, never EVAR do this
[15:14] <LocutusOfBorg> pitti, virtual machine
[15:15] <LocutusOfBorg> I'm not *that* crazy
[15:15] <LocutusOfBorg> :)
[15:15] <mvo> hehehe
[15:15] <mvo> thanks, another reminder to fix this silly bug
[15:15] <LocutusOfBorg> sorry for the dup :)
[15:18] <mvo> no worries
[15:29] <coreycb> arges, mind rejecting my dh-python upload to wily?  it has some cruft in it.
[15:29] <pitti> coreycb: done
[15:29] <pitti> arges: ^
[15:29] <coreycb> pitti, thanks
[15:35] <nacc> cpaelzer: ack, that's the major change; it has to, if you care, with the fact that all imports are now git-merge commits. git-rebase will try to replay the merges, which won't work. So we first have to break the git-tree into a 'reconstruct' tree that is a sequence of linear commits with only one parent.
[15:35] <nacc> rbasak: ack, thanks!
[15:48] <nacc> can someone re-trigger the autopkgtests for phpseclib -> php-horde-mapi (new version has landed in yakkety)
[15:49] <pitti> nacc: doing
[15:50] <nacc> pitti: thanks!
[15:50] <nacc> pitti: i think almost all of php has cleared out of excuses now :)
[16:02] <cpaelzer> nacc: yeah thanks for the extra explanations
[16:02] <cpaelzer> nacc: worked fine after I adde the two new stages
[16:03] <cpaelzer> nacc: I'm just starting to build my newly merged package
[16:05] <nacc> cpaelzer: great! sorry for that confusion
[16:07] <cpaelzer> nacc: you are totally innocent for me starting as I did before instead of re-reading the new doc :-)
[16:07] <cpaelzer> s/innocent/unblamable/
[16:08] <nacc> cpaelzer: i hope that's mentioned on the new doc, and if not, i'll go fix that now :)
[16:08] <cpaelzer> nacc: it is there, working fine
[16:08] <nacc> cpaelzer: ok, good :)
[16:08] <cpaelzer> nacc: what is missing thou and I wanted to discuss that - is that if just following the doc you get missing references
[16:09] <cpaelzer> nacc: after the clone at the step of usd-merge tag
[16:09] <cpaelzer> nacc: as soon as you check out or at least fetch those you are good and usd-merge wrks fine
[16:09] <nacc> cpaelzer: ah, that's true, there is aw orkaround
[16:09] <nacc> let's say you named your remote usdi
[16:09] <cpaelzer> nacc: something for that would be nice to be added to the doc
[16:10] <nacc> then you can do `usd-merge tag usdi/ubuntu/yakkety usdi/debian/sid`
[16:10] <nacc> and it will dtrt
[16:10] <nacc> but yes, i'll clarify that! i wrote it from the persepctive of i have the imported trees locally that i'm pushing :)
[16:10] <cpaelzer> nacc: true, I don't mind what way gets added to the doc, also I expect most to find a way around like me - but "something" in the doc would surely be nice
[16:11] <nacc> cpaelzer: yep, fixing now
[16:13] <cpaelzer> nacc: also I tihnk section 7 mght be incomplete subject is "Tag, push and review.", but there is no tagging involved :-)
[16:14] <cpaelzer> nacc: in the long past we called that thing to be tagged archive/version, but I'm sure you have something new matching the remaining tests in a better way
[16:17] <cpaelzer> nacc: maybe just new/ubuntu ?
[16:17] <cpaelzer> until we know it is accepted and uploaded we can't really give it a version tag - that was the discussion back then
[16:17] <nacc> cpaelzer: yep, that's the discussion rbasak and i are still going through
[16:18] <nacc> cpaelzer: but from a MR perspective, that's ok
[16:18] <nacc> cpaelzer: just don't tag (just checkout -b merge or whatever) and push your branch
[16:18] <rbasak> Which tag are you talking about?
[16:18] <nacc> reviewer reviews the branch, and if uploader, they'll tag
[16:18] <nacc> rbasak: i think the 'proposed' new version
[16:18] <nacc> rbasak: as a result of the merge
[16:18] <nacc> proposed strictly from the submitter's perspective, not the archive
[16:19] <rbasak> ATM that appears as the MP's proposed branch, right? So no need to tag, but do need a branch name.
[16:19] <rbasak> In the past, we didn't technically need a branch.
[16:19] <cpaelzer> nacc: I'm fine with a brnach only, just drop the "tag" from the subject in section 7
[16:20] <rbasak> Though "new/ubuntu" is handy.
[16:20] <rbasak> But that'll move upon addressing review comments, so maybe we should stop using it and focus on a branch tip instead.
[16:20] <cpaelzer> nacc: and if you rewrite section 7 you might add to push tags as well, otherwise we don't have to discuss how to name them :-)
[16:22] <cpaelzer> no matter if we follow the branch (which is nice as it moves) or add a tag, uploading tags will surely help for logical/reconstruct and such tags
[16:22] <nacc> cpaelzer: updated, take a look?
[16:22] <nacc> cpaelzer: yep, i forgot to include the tags to push as well, you're right, fixed now
[16:23] <cpaelzer> nacc: a bit wide, but yeah good now
[16:24] <nacc> cpaelzer: yeah, i'll figure that out :)
[16:25] <cpaelzer> nacc: not to say that 99% of screens on the world would have enough screen-estate to jsut display it wide :-/
[16:26] <nacc> cpaelzer: now it's a little scrolly box :)
[16:28] <cpaelzer> nacc: it losts its index as #2 by that
[16:28] <cpaelzer> nacc: I'd vote for \ and indented follow up line
[16:31] <nacc> cpaelzer: check now?
[16:31] <cpaelzer> nacc: I don't want to be a pixel mover, but since we are at it anyway - the distance between "git push" and the line above is too small and the distance to the following line is too huge
[16:32] <cpaelzer> nacc: but feel free to just keep it as-is - it  is good
[16:36] <nacc> doko: question on openjdk-9-jdk (two questions, actually). 1) openjdk-9-jdk is uninstallable in 16.04 because it and openjdk-9-jdk-headless provide the same file (and -jdk depends on -jdk-headless). 2) openjdk-9-{jdk,jre} provide {java*-sdk,java*-runtime}, which causes some dependency issues (LP: #1584118). Any ideas on what the right way to resolve those are?
[16:42] <nacc> cpaelzer: it is a wiki :-P
[16:42] <nacc> cpaelzer: i don't know why the wiki formats that way, but it's not something i'm specifying, fwiw
[19:00] <sil2100> cyphermox, BenC, rbasak: hey guys! I won't be able to make it for todays meeting sadly
[21:40] <nacc> slangasek: could you take a look at LP: #1592890? it will clear out two more excuses entries (php7cc and php-pimple itself)
[21:40] <nacc> slangasek: i've already sent the same patch to Debian, if you want to just wait for that to get accepted and sync
[21:48] <nacc> mdeslaur: you added a patch to php-horde-http during 16.04 which turned a non-fqdn into a fqdn in a test case. But afaict, the test passes w/ or w/o it (and it's not in Debian still). There is no bug report linked, so I'm not sure if you know specifically why/if it's needed?
[22:06] <nacc> jbicha: thanks for the advice and pointers on the zend{,-}framework stuff!
[22:46] <nacc> let's say i'm providing a fix for a package which has received a security update, but my fix is not itself a security update. The current version of the package is 7.0.4-7ubuntu2.1. Would my package be versioned 7.0.4-7ubuntu2.2 or 7.0.4-7ubuntu3 ?
[22:46] <nacc> I guess not the latter, only in case there was a 7.0.4-7ubuntu3 published in the development release that it might conflict with?
[23:12] <mdeslaur> nacc: it was failing it's autopkgtest
[23:12] <mdeslaur> nacc: feel free to drop it if the autopkg test now works without it
[23:30] <jbicha> nacc: using the version numbering recommended on https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation is a good standard regardless of whether the sru is "security" or not
[23:30] <jbicha> 2.2 is fine
[23:31] <nacc> jbicha: ack, thanks!
[23:32] <jbicha> I think there's a little bit of flexibility as long as the number is less than it could be in a future release
[23:32] <nacc> mdeslaur: ok, i'll double-check again and request a sync if it works
[23:32] <nacc> jbicha: ack, that makes sense
[23:32] <jbicha> for instance I gave my https://launchpad.net/ubuntu/+source/abiword SRU 3.0.1-6ubuntu<IP_ADDRESS>
[23:33] <jbicha> but strictly following the rules I think it should have been 3.0.1-6ubuntu0.1
[23:33] <nacc> yep, i think i was just clarifying on if those rules applied to non-security updates and then how strictly they were followed :)


[00:01] <Keybuk> 1.0.0
[00:01] <mindstorms> hi all and happy new year (to those celebrating it)
[00:02] <mindstorms> somebody mentioned a couple of weeks ago that he is working on creating a patched svn version
[00:02] <mindstorms> and a smarter install for Mac
[00:02] <mindstorms> any news on this? (I know there is a distro for 10.5, but the discussion was to make it available for Mac 10.4 too)
[00:03] <abentley> Keybuk: So in 1.0, the reason why it didn't support remote urls was that it always used working trees.
[00:03] <abentley> However, local URLs should work just fine.
[00:05] <abentley> In bzr.dev, diff has been reworked significantly, and now uses the last-committed-tree for remote URLs and for branches without trees.
[00:39] <zekel> Anyone know how to get svn style status? There seems to be a short keyword arg to status.show_tree_status that does what I want, but I'm having trouble getting started with the api. I'm not really sure if I want to be writing a script to filter the bzr output, call status from within, or make a plugin that is called by normal bzr st. Can someone point me in the right direction?
[00:39] <jelmer> zekel: bzr st -S ?
[00:40] <jelmer> what sort of thing you would want to use really depends on what you're trying to write
[00:40] <zekel> Oh, I guess I got confused. What I really want is the paths outputted to be relative to the cwd, and I took that to be the svn thing.
[00:40] <jelmer> and in what lnaguage
[00:40] <zekel> I was thinking python.
[00:40] <jelmer> ah, ok. I don't think there's a way to report paths relative to the cwd yet
[00:40] <jelmer> but I may be wrong
[00:41] <zekel> I think I asked if there was a builtin way and was told no, not yet. I find that I don't check in stuff as much if the paths are long, which is really bad.
[00:41] <zekel> I could do something with sed, but I thought I'd try to do it from within python instead.
[00:43] <zekel> I think what I need is to know the correct way to get a working tree object, so that I can call a status method, which I can then mess with.
[00:43] <lifeless> uhm
[00:43] <lifeless> just write a replacement formatter?
[00:45] <zekel> That sounds like a great idea. I should look at the normal one and make my changes?
[00:45] <lifeless> it may not be fully pluggable right now; a good place to start looking is bzrlib.status
[00:47] <zekel> That's why I'm thinking it might just be a better idea to have a filter script to pipe it through.
[00:51] <lifeless> perhaps
[00:51] <lifeless> we do like making things pluggable though :)
[00:52] <zekel> I can't say I'm an expert, so hacking bzrlib vs. filter script might be the difference between impossible and doable.
[00:53] <zekel> At least based on trying to read it.
[01:00] <lifeless> zekel: ah
[01:00] <lifeless> zekel: well, let me have a quick check
[01:01] <lifeless> look for 'if short:' in status.py
[01:01] <lifeless> see _mod_delta._ChangeReporter
[01:01] <lifeless> thats the interface you can use to write a new reporter
[01:02] <Peng> What exactly are rich roots?
[01:02] <lifeless> you can subclass that too
[01:02] <lifeless> and hardcode in a new class in status.py for now
[01:02] <lifeless> Peng: versioned '/'
[01:02] <Peng> What does that gain?
[01:02] <lifeless> bzr split; bzr join
[01:05] <Peng> How do rich roots help that? What information about directories is there?
[01:06] <lifeless> last-change and file-id
[01:06] <lifeless> (and children obviously)
[01:06] <Peng> Ok.
[01:06] <Peng> I still don't get it.
[01:06] <lifeless> it stops new files in the root of the project you joined being merged to the root of the combined tree, rather than the correct child node
[01:07] <lifeless> say you have project A: [/]  and B: [/, /README]
[01:07] <lifeless> if you join B to A at subproject you get:
[01:07] <lifeless> A': [/, /subproject, /subproject/README]
[01:07] <lifeless> if you commit to B a new file 'configure'
[01:07] <lifeless> then merge B' to A' you want:
[01:08] <lifeless> A'':[/, /subproject, /subproject/configure, /subproject/README]
[01:08] <lifeless> this requires you to know that B''s '/' is A's '/subproject'.
[01:09] <lifeless> if B's / has no file-id then you can't tell that.
[01:12] <Peng> Ok.
[01:16] <Peng> That could be inferred, but I guess it would require rewriting history a bit?
[01:16] <Peng> Or, I dunno.
[01:16] <Peng> It sounds really easy to infer that when the merge is done, but I guess it doesn't map well to being stored?
[01:17] <lifeless> the only thing available to infer this is the presence of README
[01:17] <lifeless> or a deep history search
[01:18] <lifeless> the first fails if there is also another file, say AUTHORS, that became /AUTHORS rather than /subproject/AUTHORS
[01:18] <lifeless> though it is arguable at that point that a conflict should be raised (but you should still be clear about the options)
[01:18] <lifeless> and deep history searches are generally bad things to do
[01:19] <lifeless> because they break when you deliberately truncate history (e.g. partial branches because you don't want the deep history for now)
[01:21] <fullermd> Is there some reason other than backward compat not to go rich-root by default?
[01:21] <fullermd> It seems like most of the dangerous/surprising bits are segregated in the -subtree variant now.
[01:22] <lifeless> dunno; I'll think about that later. Coding now. Tchau. :)
[01:23] <fullermd> Better choice   :)
[01:49] <lifeless> abentley: if you are pro the experimental format approach I put forward, consider a review :).
[03:02] <pfharlock> This is probably asked allot, but, I created a bzr branch and then tried to merge in something from a subversion repository and just can't seem to figure out how to get it to work.  I have successfully branched a svn repo into a non-pre-existing bzr branch, but I was hoping to create a bzr repo and selectively merge in svn branches.  I'm using the svn-bzr plugin.  Any thoughts? Is what I'm trying to do even possible?  I can give any det
[03:02] <pfharlock> ails that may be of help.
[03:06] <lifeless> well, an error message would be a good start :)
[03:06] <pfharlock> ok
[03:06] <pfharlock> one sec
[03:06]  * fullermd presumes it'll be a repo format issue.
[03:07] <pfharlock> yes, that seems to be the case, here is the lead up
[03:07] <pfharlock> bzr init
[03:07] <pfharlock> bzr merge svn+file:///home/pfharlock/arc/subversion/snippets
[03:07] <pfharlock> bzr: ERROR: Repository KnitPackRepository('file:///home/pfharlock/test/.bzr/repository/') is not compatible with repository SvnRepository('file:///home/pfharlock/arc/subversion')
[03:09] <lifeless> upgrade --pack-0.92-rich-root I think is what you need
[03:09] <fullermd> Yeah.  You'll need....   mmm...   at least one of the rich-root formats, and maybe the -subtree one.  Not sure how far bzr-svn pushes you currently.
[03:09] <Peng> --rich-root-pack
[03:10] <Peng> (no 0.92?)
[03:10] <pfharlock> ok, thanks for the advice, I'll try that, I'm on bzr 1.0
[03:10] <Peng> bzr-svn is supposed to work with the rich-root formats.
[03:10] <pfharlock> just out of curiosity, why does the rich root format help?
[03:11] <lifeless> it adds metadata svn exports need to do the right thing with some of the copy-to-make-branch operations
[03:15] <pfharlock> yeah, that seemed to have worked, thankyou very much, will the rich root formats eventually become the default in bzr?
[03:16] <lifeless> yes
[03:28]  * igc lunch
[03:28] <pfharlock> one more silly question, if you create a rich root format branch or repo, can you merge from it into a standard default knitpack or is it simply not backwards compatible that way?
[03:35] <abentley> pfharlock: It is not compatible for the same reason SvnRepository isn't compatible.  There is data in "rich-root" formats that pack-0.92 cannot represent.
[03:36] <pfharlock> I see, thanks again for the help, it's really appreciated.
[05:39] <spiv> abentley: you replied to me, rather than the list
[05:39] <abentley> Oh, thanks.
[05:40] <spiv> abentley: I guess my habitual "group reply" in mutt that does "To: you / Cc: the list" breaks in combination with your reply habits?
[05:40] <abentley> I blame New Year's celebrations :-P
[05:40] <spiv> Heh.
[05:41] <abentley> I usually use "reply all", but I've recently changed my email address, so I've been a bit out of sorts.
[05:42] <abentley> spiv: Does that subtract_plans docstring look helpful?
[05:42] <spiv> abentley: very!
[05:42] <abentley> Oh, great.
[05:43] <abentley> I'm just applying your tweaks now.
[08:16] <igc> night all
[08:56] <mwhudson> lifeless: still here?
[09:07] <lifeless> fsvo here
[09:07] <lifeless> dinner is ready in 2 min
[09:07] <mwhudson> i was fighting getting tg installed on squid-cache
[09:08] <mwhudson> but now i'm on the phone to thumper
[09:13] <lifeless> tg is installed system wide
[09:15] <mwhudson> it is?
[09:16] <mwhudson> maybe i'm running things with the wrong python...
[09:16] <lifeless> 2.5
[09:16] <mwhudson> ah yeah
[09:50] <mwhudson> lifeless: you're definitely special: http://www.squid-cache.org/bzrview/squid3/trunk/changes
[10:07] <mathrick> is there a plugin to support individual hunks commits, darcs style?
[10:08] <lifeless> mwhudson: did you put anything in a per-user python dir or something ?
[10:08] <lifeless> mwhudson: and how are you starting it ?
[10:17] <mwhudson> lifeless: "python2.5 ./start-loggerhead.py -f"
[10:26] <mathrick> how come the release notes (and actually releases thmeselves as well) are so irregularly linked from http://bazaar-vcs.org/news ?
[10:26] <mathrick> doesn't that happen automatically?
[10:37] <mathrick> urgh, for some reason "bzr branch http://michael.ellerman.id.au/bzr/plugins/diffstat/" takes about 2 minutes and heaps of bandwidth
[10:37] <mathrick> for all of 11 revisions
[10:38] <mathrick> even a simple bzr ls takes 20s
[10:39] <Peng> The remote repository contains a lot more.
[10:41] <Peng> (Probably a copy of bzr's branch.)
[10:54] <lifeless> mwhudson: I was using 'python start-loggerhead.py'
[10:54] <lifeless> Peng: bet that teh remote repository is knits ;)
[10:54] <Peng> lifeless: It is.
[10:54] <lifeless> mathrick: thats an old format repository
[10:55] <mathrick> ah
[10:55] <lifeless> night all
[10:55] <Peng> I wouldn't call it old, just not new.
[10:56] <Peng> G'night.
[10:57] <mwhudson> lifeless: ah ha
[10:57] <mwhudson> why the fuck does that make a difference
[10:59] <mathrick> Peng: it's slow enough to be old :)
[11:05] <mwhudson> lifeless: as predicted, though i'm not sure why, deleting the [logging] section of the config seems to help
[11:07] <mathrick> garh, how can I debug WHY a plugin can't be loaded?
[11:08] <mathrick> ie. get whatever error makes it so
[11:13] <Kinnison> Can someone point me at the docs for what a Text conflict is, vs. a Contents conflict?
[11:15] <mathrick> Kinnison: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#conflicts-types
[11:16] <Kinnison> thanks
[11:17] <Kinnison> Contents conflict in vl.h
[11:17]  * Kinnison thinks bzr misclassified that file
[11:22] <Kinnison> mmm or perhaps not
[11:22] <Kinnison> urgh
[11:25] <Kinnison> I think upstream deleted that file
[11:25] <Kinnison> pants
[11:25] <Kinnison> thanks
[11:25] <Kinnison> I hate qemu
[11:26] <mwhudson> mathrick: look in ~/.bzr.log
[11:33] <mathrick> mwhudson: aha, thanks
[11:41] <indu> how can i work out with trunk and branch methodology
[11:41] <mathrick> indu: eh?
[11:41] <mathrick> what do you mean?
[11:41] <indu> is there a specific way that a version control system should follow for publishing the source, to the community
[11:42] <indu> mathrick, i just started maintaining a version control system for my project, prev i had used svn
[11:43] <indu> now i am trying to shift to bzr which has much more better features
[11:43] <mathrick> indu: aha, there's no One True Way
[11:43] <indu> but I am confused how to organise it
[11:43] <mathrick> there are many ways, depending on what your project needs
[11:43] <indu> mathrick, my project has different releases, named as sethu, tarang, and anant
[11:44] <mathrick> indu: how big is it? How many core developers do you have? Is it open source? Proprietary? Proprietary with external contributors?
[11:44] <indu> its an opensource
[11:44] <indu> mathrick, and in future i will have some more release,
[11:45] <indu> thus, if I consider each as seperate repo, and then upload my souce as branches ( each repo has more than one branch)
[11:47] <mathrick> indu: what are those releases? Are they versions, or separate codebases? Do you need to maintain each independently, or does one release make others obsolete?
[11:47] <indu> mathrick, they are not versions, they are different releases
[11:47] <mathrick> but what is a release?
[11:48] <mathrick> are they separate programmes?
[11:48] <indu> mathrick, i am working on a linux distribution,
[11:48] <indu> based on debian
[11:48] <mathrick> okay?
[11:48] <indu> and to maintain its source i am trying this
[11:49] <indu> you can have a look at http://packages.bosslinux.in/boss/pool/
[11:49] <indu> where there are three releases, and under each there is a main folder, and the source under that folder only need to be made version controlled
[11:50] <mathrick> aha, so they are effectively versions, except that they bundle a lot of things together each
[11:51] <mathrick> indu: is the source you want versioned related between releases (I assume yes)?
[11:51] <indu> no its not versined between releases,
[11:52] <indu> the source is independent for all the releases
[11:52] <mathrick> okay
[11:52] <mathrick> indu: so as far as you're concerned, sethu and tarang have no relationship at all?
[11:53] <indu> mathrick, yes
[11:53] <indu> mathrick, they are just under the project of our linux distro, but internally they are not related
[11:53] <mathrick> indu: then it makes sense to set up a separate repo for each of them
[11:54] <mathrick> indu: what is the structure of your team? Do you have any external contributors? How many internal ones do you have?
[11:55] <indu> internal are 15, and external may extend to 100
[11:56] <indu> or more than that
[11:57] <mathrick> okay, so you might want to set up a PQM for the internal ones, and pull from independent repos for external ones, if they are less active than internals. Otherwise you could grant access for the active external ones as well
[11:57] <mathrick> PQM lets you set up things such as buildbots and automated testsuites easily
[12:00] <indu> what is PQM ? first time i am hearing this terminalogy
[12:00] <indu> mathrick, mathrick, one more thing, i also need a good gui for the users to easily view the structure so that they can download the source, if i use loggerhead, then each repo appears extended by default and thus my page in browser looks very big with sethu (80 branches under it) lll'ly tarang and anant
[12:01] <mathrick> indu: https://launchpad.net/pqm http://bazaar-vcs.org/Workflows
[12:03] <mathrick> indu: a lot is explained in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html and http://bazaar-vcs.org/BzrPlugins
[12:03] <mathrick> including GUIs
[12:04] <mathrick> unrelated, could someone review this patch: http://pastebin.com/m22468f01
[12:04] <mathrick> is this the right thing to remove diff_cmd_helper?
[12:05] <indu> mathrick, ok i will have a look at those docs,
[12:05] <mathrick> it irks me somewhat I had to recreate spec_tree() from it
[12:05] <indu> mathrick, one more small doubt
[12:05] <indu> mathrick, i am unable to configure bazaar with apache
[12:05] <indu> do u have idea on it?
[12:06] <mathrick> indu: I don't know what you mean by configuring bazaar with apache, so no
[12:06] <mathrick> and I have no idea about anything that involves the two together, so I'm unlikely to help
[12:09] <indu> mathrick, ok. thanks for the help provided
[12:09] <mathrick> no problem
[12:13] <mathrick> any comments on the patch?
[12:33] <Peng> mathrick: What's that a patch too? Also, use bundles (bzr send -o foo.patch) when submitting patches so your commits won't be lost.
[12:34] <mathrick> Peng: it's for diffstat plugin
[12:34] <Peng> mathrick: Oh.
[12:34] <mathrick> and I know about bundles, I just wanted someone to look at the code
[12:34] <Peng> Ok.
[12:35] <Peng> I don't know anything, so I have no comment on the code.
[12:35] <mathrick> ok
[12:35] <mathrick> ah, right, I've fixed a buglet since I pasted it
[12:41] <indu> mathrick, i want to use http protocol, for publishing the content
[12:42] <indu> mathrick, that can be done by configuring apache web server for bazaar, is it right? or any other way is available
[12:42] <mathrick> indu: then you just publish the directories, bzr repos are simple directories on disk
[12:42] <mathrick> there's no configuring of apache for bazaar
[12:43] <mathrick> indu: unless you mean a sophisticated repo viewer, a'la loggerhead
[12:52] <indu> mathrick, yes, my problem is solved now, many thanx
[13:07] <indu> could some one tell me, what this message mean http://rafb.net/p/yfdEH296.html
[13:08] <soren> indu: You can't push over http.
[13:09] <indu> I soren branch on http worked
[13:09] <soren> Yes?
[13:09] <soren> That's a read only operation.
[13:09] <soren> push means that you want to send you changes somewhere. You can't do that over http.
[13:10] <indu> soren, ok fine
[13:13] <indu> soren, then i changed my command to bzr push /usr/local/boss-bazaar/Anant
[13:13] <indu> and the o/p was created one branch, but where does it create? since its not available under /usr/local
[13:14] <indu> under /usr/local/boss-bazaar/Anant
[13:14] <soren> o/p ?
[13:15] <indu> o/p = output
[13:17] <soren> "the output was created one branch"? I don't understand, I'm afraid.
[13:18] <indu> in svn, to create a new project repo, we using svn import command to add files to the repository
[13:18] <indu> but its not possible in bzzr
[13:21] <soren> Ok, now I'm seriously confused.
[13:21] <soren> What is your question?
[13:22] <soren> If you want to start to use bzr, you issue "bzr init", add your files, bzr add them, and bzr commit them.
[13:22] <Peng> (Even better, you convert from your svn repo so you don't lose your history...)
[13:45] <dlee> Indu:  When you bzr push, bzr get, etc., yes, you get one "branch" (the term "branch" has slightly different meanings in svn and bzr though, and I'm temporarily blurring the distinction).  The "output" will go where you told it to; for example, "bzr push /usr/local/out" would create a directory called /usr/local/out and under it /usr/local/out/.bzr, in which the data for the branch would go.  I'm not sure how much I'm helping here, but I
[13:46] <mathrick> pack-0.92 is the latest-and-fastest format?
[13:47] <dlee> Latest non-experimental format yes.  I'll let someone else tackle the "fastest" part.  There's a newer format, but I understand it's still experimental.
[13:50] <Peng> mathrick: Yes. It's a lot slower for operations that read the entire history (like log) though (which is being worked on). Also, older formats cache all of the information "bzr annotate" uses, but packs don't, so that's slower too. (There's going to be an annotation cache in the future.)
[13:51] <mathrick> okay, I was playing with a simple benchmark, and it seems that bzr rm on new files is pathologically slow
[13:51] <mathrick> I'm doing it on ~30K newly added files
[13:52] <Peng> mathrick: (On the flipside, operations that only read part of the history are much faster.  It also makes read-write dumb servers easier because files are not modified, only added and deleted.)
[13:52] <Peng> mathrick: Nice.
[13:52] <mathrick> and it has runtime at least 3m
[13:53] <Peng> Crapcrapcrap.
[13:53]  * Peng notes that running 'touch' 30,000 times isn't very fast either.
[13:53] <Peng> Crapcrapcrap. Ran it in the wrong directory.
[13:54]  * Peng kills it after 17,000 files.
[13:54] <mathrick> Peng: dunno, git can add all of them in 2s :)
[13:55] <dato> % seq -f %g.txt 30000 | =time -p xargs touch
[13:55] <dato> real 2.08
[13:55] <dato> Peng: ^
[13:55] <dato> Peng: the trick is not starting a new touch process per file ;)
[13:56] <mathrick> what's =?
[13:56] <mathrick> is that csh or some other abomination?
[13:56] <dato> zsh
[13:56] <dato> =time -> /usr/bin/time; I use in order not to use the shell builtin time, which I don't like
[13:57] <mathrick> oh
[13:58] <mathrick> someone should tell /usr/bin/time about spaces
[13:58] <Peng> dato: I know.
[13:58] <dato> mathrick: I like it with -p better
[13:58] <mathrick> bzr rm still running...
[13:58]  * Peng blows up his file manager moving all of the files with python.
[13:59] <mathrick> dato: ah, that's basically what bash's builtin time does :)
[13:59] <dato> ah, oh :)
[13:59] <Peng> I've been meaning to check out zsh instead of bash.
[14:01] <Peng> Sigh.
[14:01] <mathrick> guess what, it's still running
[14:01] <Peng> I think I really did freeze my file manager.
[14:01] <mwhudson> command-not-found --> bash wins
[14:02] <mathrick> God, I hope it has runtime <= 30 mins
[14:02] <Peng> Oh nice.
[14:02] <mathrick> I might add it pegs the CPU while it's running, too
[14:02] <Peng> ps says it's using 0.1% of the CPU. top says it's using 99.9%.
[14:02] <mathrick> so there's definitely something wrong going on
[14:03] <Peng> mathrick: Don't kill it! It's running Folding@home!
[14:03] <mathrick> Peng: more like Removing@tmp
[14:04] <Peng> That still helps solve cancer, right?
[14:04] <mathrick> I don't think it does
[14:04] <Peng> Hopefully Konqueror will be faster than bzr.
[14:04] <mathrick> heh
[14:04] <Peng> Craap.
[14:05] <mathrick> Peng: y'know, if it does something exponential, it probably won't finish within my lifetime
[14:05] <mathrick> even just O(n^2) is pretty bad on n = 30K
[14:07] <Peng> Yay, Konqueror is done!
[14:11] <mathrick> okay, 20 mins, I'll kill it now
[14:17] <mathrick> okay, I've tracked the problem
[14:18] <mathrick> it's collecting the info about files
[14:18] <mathrick> since all are new and can't be safely removed, "bzr rm" will error out
[14:18] <mathrick> and some kind of info it's gathering there is taking forever
[14:18] <mathrick> if I add --keep, it's fast
[14:18] <mathrick> no --keep == exponential
[14:58] <statik> is it possible to create my own location aliases similar to the lp: prefix for branches? so that instead of always getting a new branch by typing 'bzr branch bzr+ssh://foo.host.com/code/branchname' I could just type 'bzr branch me:branchname ?
[15:02] <dlee> Statik: The Bookmarks plugin might be what you want:  bzr branch bm:branchname should become possible with that.
[15:03] <statik> dlee: cool, thanks!
[15:22] <CardinalFang> Is this the right place to talk about bzr-gtk?
[15:25] <CardinalFang> I use the per-file commit comments, so there can be a lot of data.  I wish that there were a "cancel, but retain comments" option in "bzr gcommit".  Also, if I just "bzr uncommit", it would be nice if the previous comments were default in the UI for the next commit.
[15:28] <schierbeck> CardinalFang: yeah, this is the place
[15:29] <schierbeck> I'm not quite sure I follow -- you want to cancel the commit, but still retain the per-file commit messages for the next commit?
[15:29] <schierbeck> I guess it's possible, although we'd need to store the messages somewhere.
[15:30] <CardinalFang> schierbeck, Yes, that's what I meant.  And when we uncommit, store those messages in the same place also.
[15:31] <Peng> When you uncommit, the revision is not removed from the repository. You could store the revision ID somewhere and use it to get the message.
[15:31] <CardinalFang> Ah, good to know.
[15:32] <schierbeck> Peng: yeah, we could do that... but to be honest, this stuff should go into bzr itself, or maybe a plugin
[15:32] <schierbeck> It's a somewhat different work model
[15:33] <schierbeck> Writing per-file messages on the fly, and then committing after a while
[15:34] <schierbeck> But yeah, a temporary solution would be to store the revision id, and clean it up after a completed commit
[15:34] <schierbeck> I'll have a look at it now
[15:35] <CardinalFang> schierbeck, I think we should capture the global commit message also.  All the state of gcommit saved and reloaded.
[15:36] <schierbeck> CardinalFang: yeah, but I think the easiest way to get started is to restore the commit messages after an uncommit
[15:36] <schierbeck> later on I'll figure out how best to do it with cancelled commits -- perhaps write them to the repository anyway, and save the revid
[15:43] <schierbeck> Holy crap
[15:44] <schierbeck> I've never looked inside commit.py before
[15:44] <schierbeck> We actually implement just about everything ourselves
[15:44] <schierbeck> That stuff really needs to be moved to bzrlib
[15:46] <schierbeck> CardinalFang: this'll need more work than I anticipated... could I get you to file a bug report? That way it'll be easier to keep track of the issues
[15:46] <CardinalFang> schierbeck, Sure.
[15:46] <schierbeck> Thanks
[15:47] <CardinalFang> No, thank you.
[15:47] <schierbeck> :)
[15:56] <ubotu> New bug: #180107 in bzr "`bzr ls` should gain --modified and --added?" [Undecided,New] https://launchpad.net/bugs/180107
[16:02] <mathrick> my bash completion for bzr broke :(
[16:05] <ubotu> New bug: #180109 in bzr "gcommit should load default comments (from "bzr uncommit" and UI button "cancel but retain")" [Undecided,New] https://launchpad.net/bugs/180109
[16:05] <CardinalFang> schierbeck, ^
[16:06] <schierbeck> CardinalFang: got it! :)
[16:12] <statik> dlee: I've got a patch for the bookmark plugin to list the stored bookmarks. Should I send it to you, or luks?
[16:14] <dato> statik: hm, different to what `bzr bookmarks` does? :)
[16:14] <statik> dato: now, how did I miss that :(
[16:15] <statik> hmm, this might be polished still
[16:15] <statik> I think the bookmark name should be listed first
[16:15] <dato> it is, at least here?
[16:16] <statik> I get the path, then the short name
[16:16] <statik> it looks like the code is intending it to print the other way
[16:17] <statik> so, I still have a patch, it's just shorter :)
[16:17]  * statik should learn to read more carefully
[16:18] <Peng> That bookmarks plugin is cool.
[16:18] <dato> statik: maybe you should double check with an unmodified plugin, I still see the plugin name first?
[16:18] <Peng> That was something I liked from hg.
[16:18] <dato> (but I only have 1 bookmark, so it may be that)
[16:19] <statik> dato: this isn't about the plugin name. its about what is output when I run bzr bookmarks
[16:19] <statik> this fixes it
[16:19] <statik> -        for name, url in sorted(bookmarks):
[16:19] <statik> +        for url, name in sorted(bookmarks):
[16:19] <dato> statik:
[16:19] <dato> % bzr bookmarks
[16:19] <dato> forja                svn+https://forja.rediris.es/svn/csl2-minirok/trunk
[16:20] <dato> (err, s/plugin name/name/ in my line above, sorry)
[16:21] <statik> dato: I see. it prints the opposite way in revno 3 from http://bazaar.launchpad.net/~luks/%2Bjunk/bzr-bookmarks/
[16:21] <statik> dato: what revno do you have?
[16:21] <dato> I had 2, and pulled to 3
[16:22] <statik> dato: then the only explanation is that I stored the data wrong when I first added a bookmark.
[16:23] <statik> and this whole thing has been me being confused
[16:23] <dato> makes sense
[16:23] <dato> from ~/.bazaar/bazaar.conf:
[16:23] <dato> [BOOKMARKS]
[16:23] <dato> forja = svn+https://forja.rediris.es/svn/csl2-minirok/trunk
[16:23] <statik> yep, I have my bookmarks inside out
[16:26] <ubotu> New bug: #180116 in bzr "bzr rm pathologically slow with new files and no --keep" [Undecided,New] https://launchpad.net/bugs/180116
[16:38] <dato> jelmer: ping
[16:38] <jelmer> dato: pong
[16:38] <dato> jelmer: trouble in bzr-svn paradise ;)
[16:39] <dato> I have minirok.dev, which I push to svn+https://....../trunk
[16:39] <mathrick> funny, I just discovered bookmarks plugin today
[16:39] <dato> and I did svn mkdir https://..../branches; svn cp https://..../trunk https://...../branches/foo
[16:39] <dato> and b get minirok.dev minirok.foo
[16:40] <dato> but pushing from minirok.foo to svn+https://..../branches/foo won't work, is that expected?
[16:40] <jelmer> dato: What error do you get?
[16:40] <dato> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[16:40] <jelmer> what does "bzr missing" say?
[16:41] <dato> AssertionError: Empty parent added, but child wasn't added !?
[16:41] <mwhudson> oo-oo
[16:42] <jelmer> uhm, ok
[16:42] <jelmer> that's definitely a bug
[16:42] <jelmer> what version bzr-svn is this?
[16:42] <dato> % cd .bazaar/plugins/svn && b revno
[16:42] <dato> 826
[16:43] <dato> shall I pull?
[16:43] <jelmer> Hmm, I don't think anything has changed since that could've fixed it.
[16:44] <jelmer> Any chance you can file a bug? Links to minirok.dev, minirok.foo and the svn repository would be very useful
[16:45] <dato> ok. in the meantime, I guess it's ok if I continue to commit in minirok.foo?
[16:45] <jelmer> yep
[16:57] <dlee> I doubt we have this yet, but ... Do we have anything for handling line ending conversions?  I just cvs-imported a 760+ revision CVS project that had been managed under Windows, but bzr co's now check out with LF, not CR+LF.  I did the co under Window+Cygwin, then another one under just Windows using the stand-alone Windows binary bzr.
[16:58]  * dlee wishes everything including Windows could just use LF and be done with it :P
[17:01] <mathrick> I still don't understand why workingtree 3 uses so much bandwidth
[17:01] <CardinalFang> It's dangerous to alter the data.  Is that file with ordinals 13 and then 10 a text file or a PNG image?  Oops, wrong choice.
[17:04] <dlee> CardinalFang: Yeah I know...otherwise I'd just ask for a co option to deal with it.  Svn used properties because of that problem, and CVS used something like a checkin-time "property."  I think line endings are on the ToDo list but not addressed yet; I'm mostly just verifying, while I try to figure out how to keep selling the Bazaar concept to my entirely Windows-based company that has been using CVS for about five years...
[17:04] <CardinalFang> dlee, Ah.  We're in the same boat then.
[17:05] <mathrick> dlee: CVS had a horribly broken solution for that, though
[17:06] <mathrick> like for most things
[17:06] <dlee> hehehe
[17:07] <mathrick> given that more people seem to be awake now, anyone care to take a look at this patch: http://pastebin.com/m682e5b7e ?
[17:07] <mathrick> is this the correct way to remove diff_cmd_helper() use?
[17:08] <mathrick> I don't like the fact that I had to steal the whole spec_tree() from inside diff_cmd_helper()
[17:08] <dlee> It worked well enough for us, *if* people remembered the required -kb on cvs adds of non-text files.  But that's a big *if* there.  I liked the svn property idea better, but I used "native," which operated about like CVS anyway.  (I did that to avoid having to put ^M at the end of every line when actually editing in an LF environment.)
[17:15] <dato> jelmer: bug #180128
[17:15] <ubotu> Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128
[17:15] <jelmer> thanks!
[17:16] <CardinalFang> I'm accustomed to creating a new branch that I expect to pull into several branches that never themselves merge.  How does one create a branch that is the greatest common ancestor of two branches?
[17:17]  * mathrick doesn't really understand what CardinalFang said
[17:17] <CardinalFang> (Well, "never" is wrong.  One is a ostensibly a superset, but it may not have changes that have been added into the subset.)
[17:17] <CardinalFang> (Yet.)
[17:20] <dlee> CardinalFang: Verify this with more seasoned bzr users here, but I'd say bzr init-repo /path/proj, then cd /path/proj and bzr co projBranchThatWillAncestorNewOnes.  To make a descendant, from /path/proj, bzr co ancestorBranchJustMade newBranchName.
[17:20] <CardinalFang> mathrick, Suppose I have a v1.0 branch and a v2.0 branch.  I can't pull v1.0 to v2.0 because there are some things that others have added but are not yet added.  I know I can add to v1.0 and cherry-pick "merge -c" just one new revision, but is there a way to create a branch that has only changesets that are in v1.0 and in v2.0, so I can add a changeset to it and pull into both with no trouble?
[17:21] <CardinalFang> ^not yet added^not yet merged to v2.0
[17:22] <mathrick> CardinalFang: aha, first guess would be that bzr branch v1.0 common; bzr branch common v2.0 should work for you
[17:22] <CardinalFang> So, if a branch is a set of changesets, I want to create a branch that is the intersection of two other branches.
[17:23] <mathrick> if you want a commit applicable for both, push it into common, otherwise, into v1.0 or v2.0 as needed
[17:23] <dlee> Ah...I didn't know you had two already-existing branches; I thought you were doing this top-down (ancestor exists, then you spin off 1.0 and 2.0 from there).
[17:23] <mathrick> ah
[17:23] <mathrick> CardinalFang: what branches do you have *right now*?
[17:24] <mathrick> and how are they related?
[17:25] <CardinalFang> mathrick, One was created from another.  v1 and v2.  Most work is in v1, and people don't always merge to v2 soon enough.  So, I can't pull from v1 to v2 without having to merge a bunch of stuff that I don't know anything about.
[17:25] <CardinalFang> So, i can't add to v1 and pull.  Got it?
[17:25] <mathrick> aha, yes
[17:26] <CardinalFang> If I can create a branch that can always be pulled into v1 and v2, then I can fix my bug there and pull into both at once.
[17:26] <CardinalFang> Then, I don't have to care that other people were sloppy about getting their v1 changesets merged into v2.
[17:27] <mathrick> is v1.0 a strict superset of v2.0?
[17:27] <CardinalFang> No.  It's a subet, in a perfect world, but in reality, there's a delay between when someone adds to v1 and when they pull to v2.
[17:28] <mathrick> aha
[17:28] <mathrick> I don't know if there's a tool to do what you want to do automatically
[17:28] <CardinalFang> I'm beginning to think that the answer is cherry-picking.
[17:29] <CardinalFang> Add rev12345 to v1 and then in v2, "bzr merge -c rev12345 ../v1"
[17:29] <mathrick> if one branch is reasonably close to the shared subset, you could branch the common off it, and then hack at it with rebase and selective uncommits until it looks like you want it to... I think
[17:30] <mathrick> CardinalFang: you have to be aware that cherry picks in bzr are *not* tracked right now
[17:30] <CardinalFang> Eeek!
[17:30] <dlee> You seem to want a justV1 place to commit, and a justV2 place, and a V1&V2 place.  I don't think you'd need an ancestor branch; v1 and v2 are already related.  This is a long shot into stuff I don't know so well, but would Rebase be of any use here?
[17:30] <mathrick> indeed
[17:31] <mathrick> dlee: I think rebase would be a tool towards building such a V1&V2 thing, but you need something to back out changes that should not be there
[17:31] <mathrick> I'm not sure how exactly you'd go about that, uncommit can't pull from the middle, and revert works on the text level, not revisions level
[17:32] <CardinalFang> mathrick, How about "merge -r big..small" to remove changesets?  Is that safe?
[17:33] <mathrick> CardinalFang: what are big and small exactly?
[17:33] <dlee> I remember there was a CVS add-on (forget the name) for automating the commits to multiple branches for this type of problem.
[17:33] <mathrick> ahh
[17:34] <mathrick> CardinalFang: dunno, but now I think of it, bzr rebase --onto might do that whilst still preserving the history and identity of revisions
[17:34] <mathrick> unsure, the whole --onto thing is a bit magical
[17:34] <CardinalFang> Hrm.  Time for some testing.
[17:35] <mathrick> but it will be manual, unfortunately
[17:35] <mathrick> CardinalFang: if you have enough crap to deal with, you might consider writing a plugin I guess
[17:35] <dlee> It occurs to me that this could probably also be handled by having multiple "parents" of one branch--i.e., commit in such a branch must clear more than one source branch before committing locally; but that also sounds like a mess to set up :)
[17:36] <mathrick> dlee: there was something called "multiparent" there in bzr.dev at one point, but it was completely undocumented and I have no idea what it really did
[17:36] <dlee> hehe
[17:37] <CardinalFang> Dang.  The tool I'm accustomed to has a command that gives the greatest common ancestor between the current and a specified location on stdout.  Then one can "clone -r`find-the-greatest-common-ancestor ../v1`" .  Very useful, that.
[17:38] <mathrick> ahh, for that there's definitely support in bzrlib
[17:38] <mathrick> dunno about the UI
[17:41] <dlee> Mathrick: ...but I bet the bzrlib support only works on tracked stuff; cherrypicking would break that, no?  I think you'd have to do text compares otherwise, to figure out what v1 changesets equal what v2 changesets.
[17:42] <mathrick> dlee: no, changesets have identity
[17:42] <CardinalFang> I'm not using cherry picking.  I thought it was a solution to that problem, but now I don't.
[17:43] <dlee> Nice!  I'm still figuring out the cherrypicking history issues; I guess they're not quite as bad as I thought.
[17:43] <mathrick> CardinalFang: I dunno how easy it is to produce a tree that's the intersection of A and B from bzrlib. But given it's the base of all merges, it should be doable
[17:43] <mathrick> dlee: ah, no, cherrypicking does break stuff
[17:43] <mathrick> but CardinalFang wasn't cherrypicking between V1 and V2
[17:43]  * CardinalFang nods.
[17:45] <mathrick> uh-huh, bzr rebase is quite dangerous
[17:45] <mathrick> it just went to happily destroy my test tree
[17:48] <mathrick> jelmer: poke?
[17:48] <dlee> New issue:  I asked yesterday how to append one bzr repo to another.  Motivation: trying to combine a CVS history for proj1 with an SVN history for later workk on the same proj1.  Also, I want to rebuild a (so far unused) Bazaar repo that I initially built with Tailor but want to build with cvsps-import (to get tags), but there are subsequent bzr-only commits in it, so I'd have to cvs-import and then copy a stack of bzr commits on top of
[17:49] <mathrick> dlee: there was a graft plugin, but it's very much outdated
[17:49] <mathrick> I dunno if there's any successor to it
[17:49] <mathrick> I dunno if you can even get the source anymore
[17:50] <mathrick> dlee: http://spacepants.org/src/bzrgraft/
[17:51] <dlee> thanks
[17:56] <mathrick> I wonder if I can make bzr shell make execute scripts
[17:58] <mathrick> wtf
[17:58] <mathrick> http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk gives 404
[18:05] <jelmer> mathrick, pong
[18:06] <jelmer> mathrick, even "bzr rebase-abort" doesn't restore it?
[18:06] <mathrick> jelmer: lemme see
[18:07] <mathrick> jelmer: it does some very scary things in any case
[18:07] <jelmer> mathrick: why?
[18:07] <mathrick> jelmer: and no, rebase-abort doesn't help
[18:07] <mathrick> sec, I'll give you a test case
[18:08] <jelmer> mathrick, what version of rebase are you using?
[18:13] <mathrick> lemme see
[18:15] <mathrick> jelmer: unsure, it's a lightweight checkout, I dunno how to check the latest revision in my working tree in this case
[18:15] <dlee> revno still works in lightweights
[18:17] <mathrick> dlee: but it reports the latest *upstream* revision
[18:17] <mathrick> at least it used to
[18:17] <mathrick> maybe that got fixed since 0.90 when I last tried
[18:17] <dlee> Oh hehehe, I've never lightweighted a branch someone else was committing to, so I'd never know
[18:18] <mathrick> I use it for plugins, since I have no real interest in having my own branch, really, I just need an up-to-date copy
[18:18] <dlee> I do wish I had a way to get the revno of my local branch after a revert though...
[18:19] <mathrick> dlee: you can't, since revert works on text
[18:19] <mathrick> I ran into the same thing myself
[18:20] <dlee> Darn!
[18:23] <dlee> I wonder if any VCS' support a sort of grep that returns all revisions / revision ranges containing matches to a regexp.  Sounds really hard to do fast though, but I've often wanted that and never seen it offered.
[18:24] <dlee> I imagine it like grep, where instead of "filename:" at the beginning of each line, you'd have "revrange:"
[18:24] <dlee> actually revset, where a set could be one or more ranges, and a range could be a singleton
[18:24] <mathrick> bah, whole launchpad is broken
[18:24] <mathrick> you can't download things
[18:24] <mathrick> dlee: yes, there's a grep plugin for bzr I think
[18:25] <dlee> Uh oh, what'd I miss? * runs off to plugin page
[18:25] <mathrick> except that you won't get it, since launchpad is broken :(
[18:25] <jelmer> mathrick: Any chance you can report a bug about the rebase issue you just ran into with a testcase ?
[18:26]  * jelmer has been using rebase happily on a daily basis and knows of several other people who have
[18:26] <mathrick> jelmer: yes, I'm just trying to determine what rev I have
[18:27] <mathrick> I also ran into bzr reconfigure butchering my lightweight checkout today, I need to investigate that
[18:32] <mathrick> jelmer: aha, so apparently I had r69, which is the latest
[18:32] <mathrick> now for a testcase
[18:41] <mathrick> jelmer: http://pastebin.com/f77fd13fb
[18:41] <mathrick> want me to write a bug report, or do you want to do it yourself?
[18:44] <jelmer> please file it
[18:44] <mathrick> okay
[18:48] <mathrick> done
[18:48] <mathrick> jelmer: is what I'm trying to do (ie. pretend that r3 happened immediately after r1, and there was no r2) sensible and supposed to work?
[18:50] <jelmer> the way I read it you're just trying to remove r3
[18:50] <mathrick> jelmer: oh, then I'm misunderstanding something
[18:50] <jelmer> rebasing revision 2 on top of 1
[18:51] <mathrick> jelmer: right, that's because -r -2 always confuses me by its changing semantics
[18:52] <jelmer> I don't think there are any changing semantics there..
[18:52] <jelmer> the last revision (3) is -1
[18:52] <jelmer> the previous-to-last (2) is -2
[18:52] <mathrick> jelmer: well, yeah, but different commands interpret it slightly differently
[18:53] <jelmer> mathrick: Can you give an example? afaik we're consistent everywhere there
[18:54] <mathrick> jelmer: yes, in a repo with 3 revs, bzr diff -c -3 shows changes for revision
[18:54] <mathrick> *revision 1
[18:55] <mathrick> however, diffstat -r -2 and -r -3 shows stats starting from the same revision
[18:55] <mathrick> which is revision 1
[18:55] <jelmer> That makes perfect sense
[18:55] <mathrick> howso?
[18:56] <jelmer> well, not sure about diffstats behaviour
[18:56] <jelmer> but that's not a core bzr command
[18:57] <jelmer> but in a repository with 3 revisions -3 means revision 1
[18:57] <mathrick> yes
[18:57] <mathrick> but -2 should mean r2
[18:57] <jelmer> it does, for bzr diff
[18:58] <mathrick> I wonder where the inconsistency comes from in diffstat
[18:59] <jelmer> I think the fact that diffstat supports "-r2" is a bug in itself
[18:59] <mathrick> jelmer: anyway, why would rebasing r2 onto r1 kill r3?
[18:59] <mathrick> jelmer: oh?
[18:59] <mathrick> it should do the same thing as diff
[18:59] <jelmer> mathrick: It should accept -c2 or -r1..2
[18:59] <jelmer> mathrick: sorry
[19:00] <jelmer> I forgot -r2 has meaning as well
[19:00] <jelmer> diffstat -r2 should report the changes between -r2 and the current working tree
[19:00] <mathrick> yes
[19:00] <mathrick> it does, except that it interprets -2 in an odd way
[19:01] <jelmer> that's a bug in a single plugin, you can hardly blame the rest of bzr for that..
[19:01] <mathrick> it pretty much ignores the last rev
[19:03] <mathrick> jelmer: well, I know, it's consistent, just somewhat shifting conceptually depending on where you stand, not unlike the way how 1 is "different" in "asd"[:1] and "asd[1:]
[19:03] <mathrick> jelmer: in any case, why would rebasing r2 affect r3?
[19:04] <mathrick> jelmer: and I tried bzr rebase -r 3 --onto=1 .
[19:04] <mathrick> and it's a no-op
[19:05] <mathrick> I'd expected it to put r3 immediately after r1 in the history
[19:05] <jelmer> mathrick: because you're only rebasing a single revision
[19:05] <jelmer> I guess you may mean "-r2.." or something
[19:05] <mathrick> oh?
[19:06] <mathrick> jelmer: so, "rebase -r X --onto=Y" means "throw away everything that follows Y in history, and make it say X instead"?
[19:07] <mathrick> and if I say -r2 for X, it replaces the whole history with that single revision?
[19:08] <mathrick> jelmer: and why does it say "No revisions to rebase." when I do that>
[19:08] <mathrick> ?
[19:08] <jelmer> that's the bug
[19:08] <jelmer> it shouldn't abort early and print that error
[19:08] <mathrick> jelmer: ah, besides, that error message is missing a \n
[19:08] <jelmer> other than that, it looks fine
[19:10] <mathrick> jelmer: but then bzr rebase -r 3 --onto=1 . is buggy
[19:12] <jelmer> no, that makes sense
[19:12] <mathrick> then I'm not getting it
[19:14] <jelmer> -r3 means it will rebase the revisions up to r3
[19:14] <jelmer> *up to and including
[19:14] <jelmer> -r1..3 means it will rebase revisions in that specific range
[19:15] <mathrick> urk
[19:15] <jelmer> ?
[19:15] <jelmer> also, using rebase on "." usually doesn't make any sense
[19:15] <mathrick> jelmer: see, that's why I said changing semantics :). Sometimes it means "up to and including X", sometimes it means "starting from X", and sometimes it means "exactly X"
[19:16] <mathrick> jelmer: I want to effectively remove r2 from the branch's history
[19:17] <jelmer> mathrick, I don't think that's confusing. It's the same way how merge works
[19:18] <jelmer> Perhaps you want something like "bzr rebase -r2..3 --onto 1 ." ?
[19:18] <jelmer> it may be necessary to run "bzr up" after that because of the bug you just reported
[19:20] <mathrick> jelmer: it doesn't appear to do anything
[19:20] <jelmer> and -r3..3?
[19:20] <mathrick> jelmer: it commits r2 and r3, but they end up in the same place they started in, so it's not a real change
[19:21] <mathrick> jelmer: that works, and results in a text conflict
[19:21] <jelmer> that's right
[19:21] <jelmer> since the delta for r3 won't apply cleanly on r1
[19:21] <mathrick> yeah, I guessed that, since r3 modifies r2, which ceases to exist, it will give errors
[19:22] <mathrick> jelmer: will the revision identity be preserved afterwards?
[19:22] <jelmer> mathrick, the revision identity for r3 you mean?
[19:22] <mathrick> yes
[19:22] <jelmer> No the revid for that will change
[19:22] <jelmer> since it's parent revids have changed
[19:22] <jelmer> not changing that would be a severe bug
[19:23] <mathrick> jelmer: hmm, so it's not really suitable for tree surgery which would remove individual revs preserving the rest?
[19:24] <jelmer> mathrick: that's not really the use case for rebase.. you may want to have a look at 'bzr replay' (part of the rebase plugin)
[19:25] <jelmer> that basically just does diff+patch+commit with original metadata
[19:27] <mathrick> jelmer: aha, and the revisions will be seen as identical for purposes of calculating merges?
[19:27] <jelmer> no
[19:27] <jelmer> there's no way to do that
[19:28] <jelmer> rebase and replay will store metadata indicating what revisions they were originally based on
[19:29] <jelmer> however, they are not identical copies of those revisions and shouldn't be treated as such by merge. merge may be able to use that metadata in some way, but doesn't at the moment.
[19:30] <mathrick> jelmer: hmm, so there's no way of doing what CardinalFang wanted (ie. create a tree that only has changes common to A and B)?
[19:30] <mathrick> jelmer: "merge using that metadata in some way" would be tracking cherrypicks, right?
[19:30] <jelmer> basically, yes
[19:34] <mathrick> jelmer: so, if A and B share all revisions up to some revision R1, and afterwards there are revs that are sometimes in both, but sometimes only in one of them, the best you can do is split out the common tree up to R1, and there's no way to have a tree that would have the later commits that are present in both?
[19:35] <mathrick> though that seems wrong to me, my understanding would be that constructing such a tree is necessary for properly carrying out merges
[19:40] <jelmer> mathrick: how do you define "commits present in both"?
[19:40] <jelmer> commits with the same diff that have been applied to both trees?
[19:41] <mathrick> jelmer: sec, I'm drawing up a graph for that, and then we can ask CardinalFang if that's what he actually meant
[19:41] <jelmer> You could make those commits in a separate tree C and merge that into A and B
[19:41] <jelmer> where C could start out with R1
[19:42] <lifeless> moin
[19:42] <jelmer> 'morning lifeless
[19:43] <CardinalFang> jelmer, The use case:  You have two sister trees, neither of which is a subset of the other.  You find a bug common to both and you want to fix it as easily as possible, without otherwise altering the sister trees.
[19:44] <jelmer> CardinalFang: that is the basic use case for cherry picks
[19:45] <mathrick> jelmer: but cherrypicks break merges
[19:45] <CardinalFang> Agreed, cherry picking would solve it.  But that introduces other problems, yes?
[19:45] <fullermd> Well, or for daggy'ing it.
[19:45] <jelmer> mathrick: How do they break merges?
[19:45] <mathrick> jelmer: cherrypicks are not tracked, so they will introduce textual conflicts, no?
[19:45] <jelmer> merge treats cherrypick commits as ordinary commits at the moment
[19:47] <jelmer> mathrick: Merge will recognize the fact some revisions are cherrypicks, but from what I understand, CardinalFang is not merging between those trees anyway
[19:47] <mathrick> but I think he wants to at some point
[19:47] <CardinalFang> The SCM I use now, which is made by a notoriously litigious organization who shall not be named, provides a "repogca" command, which returns the "greatest common ancestor" of two trees, which one uses to branch off a tree that can be pulled into either.
[19:48] <mathrick> jelmer: will it recognise the fact they are present in the tree already?
[19:48] <jelmer> mathrick: No, that's what tracking cherrypick information is about.
[19:48] <mathrick> right, so merge does not really recognise cherrypicks
[19:48] <jelmer> CardinalFang: that would be possible with bazaar as well
[19:48] <CardinalFang> Yes, the two trees are constantly merged.  But with more than a hundred people committing /all the time/, we can't sit on our hands if one person falls behind.
[19:49] <mathrick> CardinalFang: okay, so what kind of change can make V1 unmergeable into V2?
[19:50] <CardinalFang> Lack of knowledge.  If there's a conflict in some dark corner of the code that only Joe and his acolytes know about, then I don't feel comfortable making decisions about what stays and what gets pruned away.
[19:51] <mathrick> CardinalFang: aha, and your current VCS can cope with that? Ie. track cherrypicks?
[19:51] <CardinalFang> No. Not at all.
[19:52] <CardinalFang> But it can give me a tree that has only common changesets in it.
[19:53] <mathrick> CardinalFang: uhh, but that's not very useful unless you can arrange for pulls that aren't contiguous wrt. to the source history (ie. cherrypicking)
[19:53] <mathrick> CardinalFang: let's sum up
[19:54] <fullermd> What he means is that there's a convenient command to set up a daggy fix.
[19:54]  * CardinalFang googles "daggy"
[19:55] <mathrick> CardinalFang: google mercurial together with it
[19:55] <fullermd> There isn't one in bzr currently; you'd have to manually poke around 'missing' or something to find the GCA.
[19:55] <fullermd> monotone, actually.  Nice page on their wiki.
[19:55] <mathrick> ahh
[19:55] <mathrick> CardinalFang: V1 is at R1, V2 is at R1'. At this point, V1 is cleanly mergeable into V2, right?
[19:57] <mathrick> CardinalFang: now there are two commits into V1, R2 and R3, and a commit R2' into V2. R2 conflicts with V2, but R3 doesn't. You want to pull R3 only, and leave R2 to be solved later, right?
[19:57] <jelmer> lifeless: any chance you can sponsor an upload of bzr-pqm to Debian?
[19:57] <mathrick> by "conflicts with V2" I mean "can't be merged into V2 without conflicts"
[19:58] <CardinalFang> mathrick, I'd rather not merge anything at all.  I have an urgent bug to fix that is present in all trees.
[19:58] <CardinalFang> If I don't fix it in 20 minutes, the Sun explodes.
[19:59] <fullermd> Wait, let me get my camera.
[19:59] <CardinalFang> fullermd, You have at least another 8 minutes, from this distance.
[20:00] <mathrick> CardinalFang: okay, and how do you do that with your current tool (and what is that tool, if I may ask)?
[20:01] <fullermd> So what you want to do, is create a new branch from the LCA, and do the fix there, so it'll merge just fine into both sides.
[20:01] <CardinalFang> mathrick, With my current tool, I think it creates a tree that is only R1.  I can create a new changeset R4 and pull that into V1 and V2
[20:02] <mathrick> CardinalFang: aha
[20:02] <CardinalFang> fullermd, Yes.  (Though I think it's "greatest" instead of "least", in the domain I'm thinking about.)
[20:02] <fullermd> I think it's usually expanded "latest" aroudn here.
[20:02] <CardinalFang> Ah.
[20:03] <fullermd> There's no command to give you it directly.  The quickest way is probably 'missing', then pick the rev before the earliest in both lists.
[20:04] <CardinalFang> fullermd, Hmm.  Perhaps I could write a plugin to do that.
[20:04] <fullermd> Probably.  I don't think it would be terribly difficult.
[20:05] <fullermd> [3-way] merge already does it after all; you could just steal the code from there.
[20:05] <fullermd> May even be a function that does it you could just call and display.
[20:11] <mathrick> CardinalFang: if you had a parent, and at R0 V1, V2 and C were branched off it, then A had R1, C1 (merged from C), R2, and V2 had R1', C1, R2', would repogca create a tree that ends with R0, or would it have R0, C1?
[20:11] <CardinalFang> mathrick, Good question.  I'll try it.
[20:14] <CardinalFang> fullermd, FWIW, graph.py says "least."  :)
[20:14] <CardinalFang> Sorry, "lowest".
[20:21] <fullermd> We should declare once and for all that it stands for "lambada".
[20:21] <fullermd> It may not mean anything useful, but it should lead to some really fun questions.
[20:21] <mathrick> *lambda
[20:21] <mathrick> :>
[20:21] <fullermd> No, I meant lambada   :p
[20:21] <CardinalFang> llama
[20:21] <fullermd> lambda is too close to actually meaningful.
[20:25] <mathrick> CardinalFang: anyway, if you write a plugin, it should be doable to get a tree that ends with R0, C1, since that's the tree merge has to construct when you say cd B; bzr merge A
[20:30] <lifeless> jelmer: good chance; this arvo probably
[20:33] <Arjen> Hi, is the benchmark script available somewhere?
[20:33] <mathrick> lifeless: can I trick you into looking at my short patch that removes diff_cmd_helper() use?
[20:34] <mathrick> I need someone with a clue if that's the way it's supposed to be done
[20:35] <lifeless> not now; coding. I'll come up for air when Lynne gets up probably.
[20:35] <lifeless> so in a couple of hours
[20:36] <mathrick> lifeless: okay then, I guess I'll just submit it upstream and wait for review there, I'll be sleeping in a couple of hours
[20:38] <mathrick> mathrick@hatsumi:/tmp/rebase$ bzr reconfigure --branch
[20:38] <mathrick> bzr: ERROR: Repository KnitRepository('file:///tmp/rebase/.bzr/repository/') is not compatible with repository KnitRepository('http://people.samba.org/bzr/jelmer/bzr-rebase/.bzr/repository/')
[20:38] <mathrick> huh?
[20:39] <jelmer> rebase is using dirstate-with-subtree
[20:39] <jelmer> looks that's confusing reconfigure
[20:39] <mathrick> it's a lightweight checkout which I converted from knitpack to knit (since it was erroring out about KnitPackRepository being incompatible)
[20:39] <mathrick> jelmer: oh
[20:41] <mathrick> the fact that reconfigure does not do a checkout is horribly confusing
[20:41] <mathrick> it looks as if it just ate your tree
[21:05] <lifeless> mathrick: I filed a bug last week on this; you might compare and see if its the same
[21:06] <ubotu> New bug: #180196 in bzr "bzr reconfigure gets confused by dirstate-with-subtree" [Undecided,New] https://launchpad.net/bugs/180196
[21:10] <mathrick> lifeless: I can't find it, care to give a bug#?
[21:54] <ryanakca> why is it that when I go "bzr up" on a local (well, ssh'd to server) branch, I get the following error message?
[21:54] <ryanakca> Using saved location: http://bazaar.launchpad.net/~...../
[21:55] <GoClick> Does bzr store all it's information is a million .bzr folders like svn?
[21:55] <ryanakca> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~...../.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[21:55] <mathrick> GoClick: ?
[21:55] <Odd_Bloke> GoClick: No.
[21:55] <mathrick> GoClick: you mean an .svn dir in ever subdir?
[21:55]  * ryanakca isn't uploading... so it shouldn't matter if http can or can't make a directory...
[21:55] <mathrick> no
[21:56] <GoClick> mathrick:  yeah
[21:56] <Odd_Bloke> GoClick: There is a single .bzr directory for your branch.
[21:57] <GoClick> good
[21:58]  * mathrick wonders if there's anything about SVN that's strictly better than bzr
[21:58] <Odd_Bloke> mathrick: It's faster for a lot of things. :p
[21:58] <fullermd> Partial checkouts.
[21:58] <jelmer> mathrick: eol-conversion support, better performance for large binaries, cherrypick tracking, ...
[21:58] <mathrick> Odd_Bloke: by not doing things, that's like being really fast at writing to /dev/null
[21:59] <mathrick> jelmer: it tracks cherrypicks how? Last time I checked, SVN had no merge support
[21:59] <GoClick> We put a lot of binaries in our version control as is, will that be a problem?
[21:59] <fullermd> That means cherrypicks can't screw up merges   ;)
[22:00] <foom> mathrick: but if you want to write to /dev/null, it sure would be nice if it went fast, instead of slow.
[22:00] <jelmer> mathrick: 1.5 has
[22:00] <jelmer> mathrick: svn has always had merge support, just hasn't had merge /tracking/ support until 1.5
[22:00] <mathrick> foom: sure, but it's not a reason to say "my foo is better than yours, since it's really fast at writing to /dev/null, whereas yours takes a lot of time to write to screen"
[22:01] <mathrick> jelmer: aha, so you can finally merge branches in a sane way and it doesn't kick you in the nuts harder for doing it often?
[22:01] <jelmer> yup
[22:02] <jelmer> that's 1.5 only though, which was supposed to be released 2 years ago or something..
[22:02] <foom> actually i think only 2 months ago or something
[22:03] <foom> but when i last skimmed the mailing list it didn't look too promising
[22:03] <foom> i'd sure like to be able to switch to bzr sometime soon. :)
[22:03] <mathrick> foom: not being punished for merging would be pretty promising in my book:)
[22:03] <jelmer> foom: They've always been pushing the deadline further forward
[22:03] <foom> mathrick: i mean, the chance of a release coming soon wasn't looking good
[22:04] <jelmer> foom: When I originally started on bzr-svn 1.5 was also "almost done"
[22:04] <jelmer> That's more than 2 years ago now
[22:04] <mathrick> foom: do like I do, use bzr-svn to manage your code, this way instead of putting up with stupid buggy SVN crap you will help bzr-svn maintainers discover new ways to improve their quality ;)
[22:04]  * mathrick runs
[22:04] <fullermd> OTOH, you keep finding new bugs in the python bindings, so...   :p
[22:04] <foom> mathrick: that's the plan, but bzr is too slow right now
[22:05] <mathrick> jelmer: so it's still not released?
[22:05] <mathrick> foom: only in the initial checkout, or do you mean something else too?
[22:05] <mathrick> the checkout thing is mucho painful because you can't horizon the history
[22:05] <jelmer> mathrick: svn 1.5 ? Nope, and doesn't look like it's going to be released soon either, at least not within the next couple of months.
[22:05] <foom> mathrick: log is excessively slow at the moment
[22:06] <mathrick> jelmer: oh, I see, I thought you were talking about actual shipped SVN now
[22:06] <lifeless> foom: local or remote. Please file a bug if it's remote, tagged hpss
[22:06] <foom> lifeless: local
[22:06] <mathrick> foom: dunno, it's being pretty fast for me, and I have repos with 3K revs with 2K-revs merges along the way
[22:06] <fullermd> log -v is downright vicious.
[22:06] <mathrick> lifeless: what does hpss mean?
[22:06] <foom> lifeless: i saw a bug already filed about log getting slow in pack format repos
[22:06] <lifeless> mathrick: smart server
[22:07] <mathrick> oh right, I didn't try it with pack yet
[22:07] <mathrick> lifeless: and hp?
[22:07] <mathrick> high perf?
[22:07] <lifeless> foom: there is a slow down
[22:07] <lifeless> mathrick: yes
[22:07] <lifeless> foom: but it should still be plenty fast; are you just doing 'bzr log' or -v or other optoins?
[22:08] <foom> lifeless: time bzr log -r30000 [waiting]
[22:08] <foom> real    0m35.296s
[22:08] <foom> user    0m28.513s
[22:08] <foom> sys     0m0.234s
[22:10] <foom> i'm sure if i was using a 3krev repo it'd be fine.
[22:10] <jelmer> 14k revs is 5 seconds here
[22:10] <lifeless> foom: using packs?
[22:11]  * mathrick wonders what git would score on that
[22:11] <foom> lifeless:     repository: Packs containing knits with rich root support
[22:11] <mathrick> it's awesomely fast to be sure
[22:11] <fullermd> -v will slaughter you even with 3k revs.
[22:11] <jelmer> yeah, -v is slow as hell
[22:11] <mathrick> OTOH, with bzr I'm able to figure how to un-add a file, with git, I'm not...
[22:12] <foom>      43276 revisions
[22:12] <foom>     599396 KiB
[22:12] <fullermd> With a ~1800 rev tree, 'log' runs in 1.7 seconds.  -v has passed the 3 minute mark so far, and broken 120 meg of RAM usage (impressive, since .bzr/ is only ~16 meg)
[22:12] <fullermd> Oh, there it finished.  225.5 user seconds, half a second of system time.  3:48 wall.
[22:13] <lifeless> foom: how many packs do you have ?
[22:13] <lifeless> fullermd: -v will get better before too much longer, but its a disk change
[22:13] <foom> just count the files in .bzr/repository/packs?
[22:13] <foom> 24.
[22:14] <lifeless> foom: yeah, or cat .bzr/repository/pack-names
[22:14] <fullermd> lifeless: And one I look heartily forward to, especially if it lets me 'log' more than one file at a time too.
[22:14] <foom> it says 22
[22:14] <lifeless> foom: you've had some interrupted uploads then
[22:15] <lifeless> do a ls -lS of the packs directory
[22:15] <lifeless> is there a good size distribution ?
[22:15] <lifeless> also you may find log gets faster if you do 'bzr pack'
[22:15] <ubotu> New bug: #180207 in bzr-eclipse "Creating project from bazaar branch" [Undecided,New] https://launchpad.net/bugs/180207
[22:15] <ubotu> New bug: #180208 in bzr "commit failed because of lack of disk space but with unclear message" [Undecided,New] https://launchpad.net/bugs/180208
[22:15] <foom> lifeless: yeah, bzr-svn crashed my machine while importing because it ran it out of ram.
[22:15] <foom> and the kernel OOM killer decided to kill everything *else*
[22:15] <lifeless> OOM FTW
[22:16] <jelmer> foom: That bug has been fixed since
[22:16] <jelmer> foom: http://subversion.tigris.org/issues/show_bug.cgi?id=3052
[22:16] <foom> jelmer: yeah, i saw
[22:23] <mathrick> hmm, you can't uncommit a single revision in the middle, right?
[22:26] <thumper> mathrick: right
[22:26] <thumper> mathrick: it is my understanding that you uncommit the latest commit
[22:27] <mathrick> http://bazaar-vcs.org/BzrVsHg#head-b92d4fdb6541abcf14ea53686e4bccc9f7b6ffa5 seems to suggest that bzr can indeed do that
[22:27] <mathrick> or so I read it at least
[22:28] <foom> lifeless: anyhow, yes, there's a good distribution of sizes, the biggest is 245595344 and smallest is 1875 and there's lots in between.
[22:28] <foom> lifeless: after bzr pack, it is down to 4.421s
[22:28] <fullermd> I think that page is misleading; bzr uncommit is only very vaguely related to hg rollback.
[22:29] <fullermd> uncommit removes a rev (or more precisely, changes the head).  rollback, AIUI, creates a new rev with opposite changes.  It's more like bzr merge -rx..x-1
[22:29] <foom> lifeless: still slow, but only 4x slower than svn instead of 30x.
[22:30] <mathrick> foom: that would be a bad distribution if they differ in sizes greatly
[22:30] <mathrick> I believe
[22:35] <lifeless> morning poolie
[22:36] <lifeless> mathrick: they are meant to differ geometrically
[22:36] <mathrick> ah
[22:38] <poolie> hi lifeless
[22:38] <lifeless> foom: ok; feel free to find out whats slow then ;) I don't feel like downloading a 1/2 GB repo to find out :]
[23:01] <igc> morning
[23:02] <lifeless> hi igc
[23:02] <igc> hi lifeless
[23:03] <foom> lifeless: is the 7x slowdown to be expected for 22 pack files vs 1, then?
[23:06] <lifeless> foom: pack orders the revision xml texts topologically
[23:07] <lifeless> foom: so you do ascending IO within the pack, which linux likes a lot.
[23:08] <foom> lifeless: sure but it's CPU time being spent.
[23:12] <lifeless> foom: possibly index layer stuff then, which is on the todo
[23:21] <ecasbas> hi, I am having a problem creating a local repository, the setup is like: http://wiki.squid-cache.org/Squid3VCS#head-a70c042fb73ac3863a0fd32ff452b59279ff7030
[23:21] <ecasbas> at the momment of: bzr branch $TRUNKURL ~/squid-repo/trunk
[23:22] <ecasbas> I get: bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n'
[23:22] <ecasbas> Bazaar 0.90 / Ubuntu 7.10
[23:23] <jelmer> ecasbas: you need a newer version of Bazaar
[23:23] <jelmer> at least 0.92 or higher
[23:23] <ecasbas> ok, thanks then I'll download the 1.0
[23:23] <ecasbas> thanks jelmer
[23:29] <ecasbas> thanks very much, the 1.0 worked perfectly!
[23:34] <lifeless> perfect example of our clear format strings not being enough lol.
[23:40] <poolie> I suspect many "they change formats too often" complaints are really "the changes are too bumpy"
[23:43] <foom> that error seemed pretty clear to me, unlike the ones that say KnitRepository isn't compatible with KnitRepository or w/e. :)
[23:46] <fullermd> Well, the changes aren't all that bumpy (at least, they're reasonably close to the irreducible limit of bumpiness)
[23:51] <lifeless> poolie: I agree with your statement if you change 'too bumpy' to 'we talk about it' :)
[23:52] <fullermd> I know I've seen several bumps in mtn, and it just wouldn't do anything 'till I told it to upgrade.
[23:52] <fullermd> Going across bzr bumps works OK (well, repo changes are usually **SLOOOOW** to work across, but they work, and you can keep working locally without the upgrade)
[23:53] <jelmer> imho bzr upgrade is too slow, that's in fact the reason I haven't upgraded a lot of my branches yet
[23:55] <fullermd> A big bump is that inter-repo-format work is so slow that practically, upgrading that means you need to flag day _every_ branch of the project.
[23:58] <lifeless> jelmer: to packs ?
[23:58] <lifeless> jelmer: its the time to clone, no more.
[23:58] <jelmer> it's actually reconcile that was the most problematic


[00:52] <smoser> utlemming, https://code.launchpad.net/~utlemming/cloud-init/sdc-op-script/+merge/206065
[00:52] <smoser> the only thing wrong with a boothook is that it doesnt guarantee network.
[12:01] <smoser> harlowja_away, one comment on datasource openstack
[12:01] <smoser> can't 'wait_for_url'
[12:01] <smoser> i know it sucks
[12:01] <smoser> but you can't
[12:01] <smoser> only ec2 can be annoying
[12:02] <smoser> ie, we want to be able to have both OpenStack and EC2 enabled
[12:02] <smoser> and not block boot for some stupid seconds
[16:15] <smoser> harlowja_away, wake up. man.
[16:15] <smoser> utlemming, did you see my half written response to the smart os change?
[16:16] <utlemming> smoser: yeah, and it makes sense
[16:16] <utlemming> smoser: I'll look at it later
[16:16] <smoser> ok. i really, really, really want an upload of cloud-init today
[16:16] <smoser> there is a bunch of stuff in
[17:46] <harmw> smoser: will we see an new cirros release this month aswell?
[17:47] <smoser> :)
[17:47] <smoser> i've been meaning to do that.
[17:47] <smoser> pathetically, one of my motivations for doing so is so i can get in a icehouse commit log :)
[17:48] <harmw> nice, though how does cirros fit into icehouse commitlogs? ;p
[17:49] <smoser> devstack
[17:49] <smoser> i'll change the default cirros used to be the released version.
[17:52] <harmw> nice nice
[17:55] <smoser> what do you use cirros for harmw?
[18:03] <harmw> testing openstack, or something else where I 'just want a vm shell'
[18:03] <harmw> instead of booting fedora/centos
[18:05] <harmw> which take considerably longer to boot :)
[18:17] <harlowja_> smoser waked up, lol
[18:22] <harlowja_> smoser wait_for_url, can be removed :-P
[18:23] <mfisch> is $INSTANCE_ID only available at bootcmd? It didn't seem to be there at runcmd time
[18:43] <smoser> harlowja_, i just about have it i think. was testing that it actually worked
[18:43] <smoser> then gonna merge it.
[18:44] <smoser> hm..
[18:44] <smoser> mfisch, the doc says it is.
[18:44] <smoser> i'm ok to put it in at runcmd also.
[18:45] <harlowja_> smoser did u get the overall change, basically unifying cfgdrive and osmetadata datasource, being backed by a common class, and then only really changing in the child classes how the data is fetched and from where (url or disk)
[18:46] <smoser> mfisch, it does appear that it should be there for you in bootcmd and in boothooks, but it is only done there.
[18:46] <smoser> harlowja_, yeah, it looks good.
[18:46] <harlowja_> smoser k
[18:46] <harlowja_> thx boss
[18:46] <harlowja_> :-P
[18:48] <smoser> harlowja_, http://paste.ubuntu.com/6927014/
[18:48] <smoser> thats my changes so far.
[18:49] <harlowja_> smoser seems ok, although should i just remove 'wait_for_url'
[18:50] <harlowja_> cause i know we all love waiting for datasources to come online, lol
[18:50] <harlowja_> and watchign the log
[18:52] <smoser> harlowja_, well, i had removed wait_for_url
[18:52] <smoser> but then i put it back
[18:52] <harlowja_> :-P
[18:52] <smoser> i figured its more useful being configurable
[18:52] <harlowja_> ah
[18:52] <smoser> if you had a openstack where it just wasn't working
[18:52] <smoser> ie, it didn't come up right way, you could turn max_wait up
[18:52] <smoser> and it would retry
[18:53] <harlowja_> ya
[18:53] <harlowja_> looks good to me then
[18:53] <harlowja_> shall i patch or u?
[18:55] <smoser> merged.
[18:57] <harlowja_> k
[18:57] <harlowja_> i know the heat folks and others wanted , https://code.launchpad.net/~harlowja/cloud-init/ec2-ssl ?
[18:58] <harlowja_> although in general since i don't use ssl for this stuff anyway (cfgdrive stil..) up to u :-P
[18:58] <smoser> harlowja_, didn't i pull that lareday?
[18:58] <harlowja_> oh
[18:58] <harlowja_> possibly
[18:58] <harlowja_> will double check
[18:59] <smoser> if not i will
[18:59] <smoser> seems not
[19:01] <smoser> harlowja_, there are merge conflicts there
[19:01] <smoser> can you resolve those really quick ?
[19:02] <harlowja_> k, one sec, writing up little speaker summary/abstract for atalanta summit stuff
[19:03] <smoser> ooh. fancy.
[19:06] <smoser> harlowja_, i'd also like to get the tox stuff too. but can't really pull it if it means it doesn't work "offline"
[19:06] <harlowja_> ya, understandable
[19:21] <smoser> harlowja_, random question.
[19:21] <harlowja_> yo
[19:22] <smoser> i'd like to have cloud-init write some "state" to /run/cloud-init
[19:22] <harlowja_> k
[19:22] <smoser> i dont have any ideas for a mechanism on doing tha tthat doesn't result in potential race conditions on reading it
[19:22] <smoser> ie, cloud-init writing the state file while a reader is reading it
[19:22] <smoser> do you?
[19:23] <harlowja_> write to temp state file, then swap it?
[19:23] <harlowja_> mv is atomic i think in linux
[19:23] <harlowja_> who's the readers in this case? users
[19:23] <harlowja_> ?
[19:36] <smoser> readers is users, yes (or tools)
[19:36] <smoser> mv is atomic, yes. but if i write state to 'cloud-init.state', then go to update it.
[19:36] <smoser> then that is not atomic.
[19:37] <smoser> mv cloud-inti.state cloud-init.state.old && mv cloud-init.state.new cloud-init.state
[19:37] <smoser> would leave a race.
[19:37] <smoser> probably over thinking
[19:37] <smoser> :)
[19:39] <med_> smoser, how do I ask cloud-init to re-run
[19:39] <smoser> :)
[19:40] <mfisch> med_ is asking because I want to test a feature w/o rebuilding an image
[19:40] <med_> (ie, on an image after I locally hack the cloud-init code0
[19:40]  * med_ is mfisch proxy
[19:40] <smoser> what i do very commonly is
[19:40] <smoser> rm -Rf /var/lib/cloud /var/log/cloud-init*
[19:40] <smoser> reboot
[19:40] <med_> He made me drive him to work and now he asks me to ask questions
[19:40] <med_> nod. that's it.
[19:40] <smoser> you can be less invasive too
[19:40]  * med_ knew there was a way
[19:40] <smoser> and you can run modules by themselves
[19:40] <smoser> cloud-init single
[19:41] <mfisch> smoser: I'm toying with the idea of having access to INSTANCE_ID inside the landscape module
[19:41] <mfisch> although I wonder if landscape uses hostname by default, /me checks
[19:41] <med_> mfisch, sounds like you're still working for (C)
[19:41] <med_> j/k
[19:44] <smoser> mfisch, so 2 things there..
[19:44] <smoser> a.) i'm not opposed to having INSTANCE_ID just in the environment whenever we set it
[19:44] <smoser> b.) you do have access to the instance id in the landscape module
[19:44] <mfisch> b) not currently
[19:45] <mfisch> and its not a shell script like bootcmd is
[19:45] <mfisch> so I'd have to do a pass of the dictionary we're building
[19:45] <smoser> you do have access.
[19:45] <smoser> you get 'cloud' passed in
[19:45] <smoser> that has it.
[19:46] <mfisch> ah cool
[19:46] <mfisch> would a simple check like if the dict has a key of $INSTANCE_ID set it there work?
[19:47] <mfisch> may want to make that more generic
[19:49] <smoser> mfisch, ?
[19:49] <smoser> the 'cloud' object has 'get_instance_id()'
[19:50] <smoser> and it proxies most things through to cloud.datasource.
[19:50] <mfisch> smoser: I mean in the config file, we need a token that says "substitute this with the instance ID"
[19:51] <smoser> i'm confused now.
[19:53] <mfisch> smoser: the landscape stuff gets loaded as a dictionary in that file
[19:54] <mfisch> account: foo
[19:54] <mfisch> for example
[19:54] <mfisch> computer-title could default to instance id if unset
[19:55] <mfisch> or something like if dict[computer-title] == "$INSTANCE_ID" then do the substitution
[19:55] <mfisch> smoser: let me propose a fix and maybe it makes more sense
[19:57] <smoser> http://paste.ubuntu.com/6927388/ ?
[19:57] <mfisch> smoser: yes, exactly
[19:57] <smoser> that doesn't do any template/rendering, but functional
[19:58] <mfisch> smoser: I will test that
[20:07] <mfisch> smoser: it screwed up the ordering in the config file to change it there, I'll look into it
[20:08] <mfisch> also instance human readable name, whatever that is would work better there
[20:15] <smoser> mfisch, yeah, yaml wont write in any predictable order
[20:18] <mfisch> smoser: it's sticking it above [client] which confused landscape
[20:18] <smoser> oh?
[20:18] <mfisch> yeah it comes out as
[20:18] <mfisch> computer-title = foo
[20:18] <mfisch> [client]
[20:18] <mfisch> ...
[20:18] <smoser> oh. yeah, it would
[20:18] <smoser> :)
[20:18] <smoser> cause i put it there.
[20:18] <smoser> i didn't realize that.
[20:18] <smoser> just put it in the right place.
[20:20] <smoser> mfisch, http://paste.ubuntu.com/6927527/
[20:21] <mfisch> smoser: I
[20:21] <mfisch> smoser: I just moved it up and checked if it was in ls_cloudcfg
[20:21] <mfisch> above the merge
[20:22] <smoser> ewll that paste there should basically fill it into instance id if its not present.
[20:27] <mfisch> smoser: yep and that explains why my idea didnt work
[20:48] <mfisch> smoser: sorry for the delay, this is what I ended up doing based on the 12.04 version:
[20:48] <mfisch> http://paste.ubuntu.com/6927655/
[20:58] <smoser> mfisch, well, if you do it after the mergeTogether
[20:58] <smoser> then you ensure that you're lowest priority
[20:58] <smoser> ie, merge all the stuff the way it does
[20:58] <smoser> then only fill it if its not set elsewhere
[20:59] <zooz> hi smoser, It's Vaidas. We've been talking over email re GCE data source
[21:00] <mfisch> smoser: true
[21:04] <smoser> zooz, hey.
[21:04] <smoser> trunk has gce now. woohoo.
[21:05] <smoser> (possibly not working as i might have broke your code :)
[21:05] <zooz> cool, I am about to look at your improvements and add them to my changes
[21:05] <zooz> I have got proper tests now, handling of user-data and more
[21:05] <zooz> smoser, no worries, I will test in GCE before I do a pull request
[21:07] <zooz> in fact I have been using cloud-init in GCE without any issues for some time now
[21:20] <zooz> smoser, a merge request is on the way for your review. I have tested it in GCE and ran unit tests. No issues.
[21:22] <smoser> zooz, thank you.
[21:22] <smoser> i plan on a cloud-init upload to ubuntu tonight.
[21:23] <zooz> great
[21:23] <smoser> so this will make its way into cloud images for trusty tonight
[21:23] <zooz> awesome!
[21:28] <zooz> done
[21:28] <zooz> let me know if any issues
[21:42] <med_> thanks smoser.
[21:43] <med_> does cloud-init get SRUd (or have a MRE for prior releases)?
[21:43] <smoser> well, SRU.
[21:44] <smoser> but for "hardware" enablement, sru team has let things in.
[21:44] <med_> nodz.
[21:44] <smoser> it is honestly though, somewhat of apain to port back to 12.04 at this point. although datasources are fairly standalone.
[21:44] <med_> 'k
[21:44]  * med_ will just take a look at rmadison in the morning
[21:52] <smoser> zooz, still there?
[21:52] <zooz> smoser, yeah
[21:52] <smoser> is there  a reason you'd not want the dns resolution?
[21:52] <smoser> the way i did it it actually works (should work) in gce
[21:52] <smoser> and will fail quickliy (dns resolution) just about anywhere else
[21:53] <zooz> smoser, no particular reason, I can test it using dns name
[21:53] <smoser> without attempting to get access to a <IP_ADDRESS> that might be firewalled off (and socket level timeout)
[21:53] <zooz> good point
[21:53] <zooz> let me do a quick test
[21:54] <zooz> smoser, it does work in GCE using dns name
[21:55] <smoser> ok. so lets keep that part, that will save people elsewhere from doing a request to that url.
[21:55] <smoser> (unless there is a dns entry external there, which would be unlikely)
[21:56] <zooz> smoser, do you want me to quickly add it back?
[21:56] <smoser> sure.
[21:56] <smoser> i have to go now for a couple hours.
[21:56] <smoser> so i'll take a look again later.
[21:57] <zooz> thanks
[23:27] <harlowja_> smoser alrihgt, i got some free time