| quotemstr | Say I have a loom. What's the best way of merging the loom into the parent branch while erasing all the history, making each thread in the loom a single commit? | 07:51 |
|---|---|---|
| quotemstr | I could just generate patches and apply them manually. | 07:51 |
| mgz | morning | 08:06 |
| quotemstr | Why would anyone want to use loom instead of pipeline? | 08:08 |
| thumper | looms came first... | 08:08 |
| quotemstr | Neither allows you to associate a thread/pipe/patch with a message, though. | 08:10 |
| quotemstr | Is it possible to convert a branch to an init-repo branch without cloning all over again? | 08:15 |
| mgz | quotemstr: depending on what you mean by that, yes, see `bzr help reconfigure` | 08:17 |
| * thumper wants a command to turn a stand-alone branch into a shared repo and move the branch to a named directory | 08:20 | |
| thumper | don't suppose that exists yet? | 08:20 |
| quotemstr | Ah, I see. | 08:20 |
| quotemstr | What's the difference between bzr branch in a shared repository, then, and bzr checkout? | 08:21 |
| mgz | read http://doc.bazaar.canonical.com/latest/en/user-guide/core_concepts.html | 08:22 |
| mgz | thumper: it's not hard to do that, just in a couple of steps | 08:22 |
| mgz | `mv branch name; bzr init-repo branch; mv name branch/name; bzr reconfigure --use-shared branch/name` | 08:23 |
| thumper | mgz: similar to what I do now :) | 08:26 |
| thumper | mgz: I was hoping for one command :) | 08:26 |
| mgz | feel free to submit one for merging :) | 08:31 |
| mgz | you'd need to be a bit careful over checking that the location really is just a plain branch, moving repos around is one of the easier ways to lost revision history | 08:33 |
| quotemstr | Okay, so I had two branches in a shared repo, trunk and test. | 09:08 |
| jml | any lp:udd devs around? | 09:08 |
| === mrevell_ is now known as mrevell | ||
| quotemstr | I deleted test with rm -rf, and now most bzr operations complain that the directory that used to contain test is no longer a branch. | 09:08 |
| quotemstr | But test was a branch of trunk. Why should trunk know about test or care that test's been deleted? | 09:09 |
| quotemstr | Huh. trunk is now a checkout of test? When did that happen? | 09:11 |
| mgz | jml: who are those mysterious creatures? | 09:16 |
| mgz | quotemstr: check back through your .bzr.log to see if you like | 09:16 |
| jml | mgz: anyone who can tell me how to land https://code.launchpad.net/~james-w/udd/binary-scanning-series/+merge/119248 | 09:17 |
| mgz | jml: it's changed recently, poke vila | 09:17 |
| mgz | (if by merge you also mean deploy, otherwise it's just push to the branch, no?) | 09:18 |
| quotemstr | mgz: Ah, I didn't know about that file. Thanks. | 09:18 |
| jml | mgz: so there's no gatekeeper ala pqm? | 09:19 |
| mgz | jml: nope, just merge locally, run tests (hah) and push | 09:20 |
| mgz | really needs to be deployed at the same time though, otherwise the skew from what's actually being used vs trunk becomes painful | 09:21 |
| mgz | and because the test aren't great, so breaking sooner while people still remember the mp is best. | 09:21 |
| mgz | quotemstr: you know how to change trunk back to a normal branch, right? | 09:22 |
| jml | mgz: I'm sorry, but I don't think I can take responsibility for that. | 09:23 |
| mgz | jml: I see vila did update README_DEPLOYMENT after doing the quantal chroot stuff | 09:23 |
| mgz | jml: well, I'm not really sure who should. I can do it, but if things blow up you and james will still be the ones we coming crying to. | 09:25 |
| jml | mgz: that's fine by me. | 09:27 |
| mgz | okay. want me to merge and push to, or have you done that? | 09:28 |
| quotemstr | mgz: Too late. I just puled again. | 09:28 |
| quotemstr | mgz: pulled, even. | 09:29 |
| quotemstr | Is it possible to tell bzr to use hard links _by default_? Some commands that branch internally don't provide a top-level hardlink option. | 09:29 |
| mgz | quotemstr: that works fine too, shared repo so apart from constructing tree again doesn't really hurt | 09:29 |
| mgz | hardlinks aren't a win when using a shared repo. | 09:30 |
| jml | mgz: I'm still trying to figure out how to run the tests. | 09:30 |
| jml | mgz: lot of dependencies, no obvious list of them or means of acquiring them. | 09:30 |
| quotemstr | mgz:For me they are. A branch with hard links takes 4.4 seconds. A branch without hard links in a shared repo takes 10.4 seconds. | 09:32 |
| mgz | jml: that is a good point | 09:32 |
| jml | mgz: 'ImportError: cannot import name LAUNCHPAD_API_URLS' | 09:32 |
| jml | from bzrlib.plugins.launchpad.lp_api import LAUNCHPAD_API_URLS | 09:32 |
| jml | mystery meat bzr. | 09:33 |
| mgz | heh, that's a recent change on trunk, aaron updated the launchpad plugin to expect a newer launchpadlib version | 09:34 |
| mgz | and apparently udd is getting vars from launchpadlib via the bzr plugin... | 09:35 |
| jml | \o/ | 09:36 |
| mgz | ah, it does have a comment so is for (semi) sensible reasons (launchpadlib had the api stability of a not very stable thing), wants updating though | 09:38 |
| jml | mgz: cool. you right to do that? | 09:39 |
| mgz | yeah, I'll take that one. | 09:39 |
| jml | mgz: thank you | 09:42 |
| mgz | ...is there any reason to support any older launchpadlib anyway? we control the versions... | 09:47 |
| vila | jml: apart from lp, james_w introduced other tests dependencies which I don't remember from the top of my head and that are not installed (nor easy to install on jubany), caveat emptor | 09:47 |
| vila | jml: i.e. test cannot be run on jubany | 09:47 |
| jml | vila: what makes them hard to install on jubany? | 09:48 |
| mgz | have 1.9.12 on jubany, will making 1.6 the minimum break anything for you jml? | 09:48 |
| jml | mgz: pretty sure not. | 09:48 |
| * jml checks | 09:48 | |
| jml | launchpadlib = 1.10.2 | 09:48 |
| jml | we're laughing. | 09:49 |
| vila | jml: usual china wall | 09:50 |
| jml | vila: oh. hmm. | 09:50 |
| jml | vila: what are your thoughts on buildout? | 09:50 |
| vila | jml: no first hand experience, almost only bad reports though :-/ | 09:51 |
| jml | vila: heh. | 09:51 |
| jml | vila: my thesis is that Python packaging is terrible in pretty much every way. | 09:51 |
| jml | vila: so it's simply a matter of choosing your means of execution. | 09:52 |
| jelmer | jml: debian packaging of python stuff, or the wide range of packging available for python? | 09:52 |
| vila | jml: oh, also, I'm now part of jfunk's team (since monday) | 09:52 |
| jml | jelmer: deploying Python services with dependencies | 09:52 |
| vila | jml: regarding test deps, the consensus was that the bzr-package-importer package should add them as build deps | 09:53 |
| jelmer | jml: ah, ack on that | 09:53 |
| jml | jelmer: so, every available option, including Debian packaging | 09:53 |
| jml | which is great until you want to have more than one service on a machine, or want to be able to update a dependency without a week-long lead time. | 09:54 |
| jml | vila: is lp:udd deployed as a package on jubany? | 09:55 |
| vila | nope, as a branch | 09:55 |
| jml | vila: what's the bzr-package-importer package used for? | 09:55 |
| vila | track the other dependencies :) | 09:55 |
| vila | lp:udd is not packaged to the best of my knowledge | 09:56 |
| vila | I needed *something* to keep track of the deps and install test setups | 09:56 |
| jml | vila: so b-p-i is installed on jubany? | 09:56 |
| jml | vila: or is it just for dev envs? | 09:56 |
| vila | jml: installed in the quantal chroot, I don't think it's installed on jubany (precise) itself | 09:57 |
| jml | vila: and the actual service runs from the chroot? | 09:57 |
| vila | jml: all jobs running in the chroot are started from the crontab (see lp:udd), that lefts the apache web server running on precise | 09:58 |
| vila | and the tmp reapers | 09:58 |
| jml | vila: thanks | 09:58 |
| jml | vila: so, will you no longer be maintaining lp:udd once you move to jfunk's team? | 09:59 |
| vila | and that's not that bad to be able to say that in 3 IRC msgs ;) Far from an automated deployment, but... | 09:59 |
| vila | jml: yes, I moved last Monday | 09:59 |
| jml | vila: yeah, definite improvement in deployment :) | 10:00 |
| jml | vila: I asked that question with a negative, so your answer confused me :) | 10:00 |
| * jml tries the positive construction | 10:00 | |
| vila | argh :) | 10:00 |
| jml | vila: Are you still maintaining lp:udd? | 10:00 |
| vila | jml: no | 10:01 |
| jml | check. | 10:01 |
| jml | vila: who is? | 10:01 |
| vila | jml: lp maintenance team | 10:01 |
| jml | vila: thanks. | 10:02 |
| * vila wonders if he should have answered 'no' to the negative... | 10:02 | |
| vila | Do you still beat your wife ? | 10:02 |
| mgz | yes! | 10:02 |
| vila | ha ! Said the single ! :) | 10:02 |
| jml | vila: at chess? quite comprehensively | 10:02 |
| vila | hehe | 10:03 |
| jml | "Have you stopped beating your wife?" is the traditional formulation. | 10:03 |
| vila | ha right | 10:04 |
| jml | Hmm. I guess lifeless is the person to talk to re longer term udd maintenance plans then. | 10:04 |
| vila | jml: jam has a kanban card about moving jubany to wepobs | 10:05 |
| jml | vila: ah cool. I might approach him, since we have quite a lot of friction with our udd deployment that's currently maintained by them. | 10:06 |
| vila | jml: hopefully I addressed a lot of the pre-requisites, apart may be pushing my b-i-p branch but the history there is pretty boring anyway ;) | 10:07 |
| jml | vila: yeah. the main issues are that packages are a really error-prone way of managing dependencies. (there's a long lag with updates, it's difficult to get the exact versions used on prod, upgrades bypass the regular automated testing process, if your machine is shared then things can randomly break because someone else upgraded a version, etc.) | 10:09 |
| jml | vila: and that lp:udd (well, our deployment especially), doesn't give a whole heap of visibility as to what it's doing through the web | 10:10 |
| jml | which doesn't matter so much when you've got shell access | 10:12 |
| vila | "really error-prone way", not sure, in the lp:udd case, the only strictly required branch is lp:udd, everything else can use the quantal packages (see my last mail in the udd ML) | 10:12 |
| jml | today | 10:12 |
| vila | jml: on jubany, installing from sources wasn't an option for xz-utils for example as this isn't a dev machines and the dev packages are not installed... | 10:13 |
| vila | jml: but yeah, lack of visibility is an issue as is the need to issue commands on jubany | 10:14 |
| vila | to fix imports | 10:14 |
| vila | deploying new versions is another story | 10:14 |
| jml | vila: we still use packages for non-Python dependencies. | 10:15 |
| vila | for lp:udd ? | 10:16 |
| jml | no, for pkgme-service, txpkgme and libdep-service | 10:16 |
| vila | ha | 10:16 |
| jml | we're in the middle of migrating to buildout. | 10:17 |
| vila | oh | 10:17 |
| vila | why not juju ? | 10:17 |
| jml | we don't like it very much, but we like everything else less | 10:17 |
| jml | vila: why juju? | 10:18 |
| vila | way of the future ? Allows a single story for dev/test/prod ? | 10:19 |
| jml | vila: That would only solve the 'many services, one machine' issue if IS were willing to have one archive per service. It would still mean that developers would have to use different packages to the ones in production, since people aren't given general access to the 'cat' archives. | 10:19 |
| vila | jml: I found a way: chroot with a dedicated PPA ;) | 10:20 |
| jml | vila: and it wouldn't address the multi-day -- sometimes multi-week -- lag that we get when updating package dependencies. | 10:20 |
| jml | vila: not allowed to deploy from PPAs in production. | 10:20 |
| vila | jml: allowed in the jubany chroot | 10:20 |
| vila | jml: don't get me wrong, I'm not arguing *against* you, | 10:20 |
| vila | but either juju is the preferred way and each service runs in its own isolated machine where a PPA is allowed or it's far less interesting | 10:21 |
| jml | vila: I still see juju as very interesting, even when using something like buildout or virtualenv for dependency management | 10:21 |
| vila | right, my point is more about: if it's isolated devs should be able to deploy specific packages | 10:22 |
| vila | and get rid of the delays | 10:22 |
| vila | it's a bit ironic to run end-to-end tests and then wait for deployment... | 10:23 |
| vila | may be ironic is not the right word... | 10:23 |
| jml | vila: quite possibly. | 10:24 |
| jml | vila: "silly"? "pointless"? :P | 10:25 |
| vila | and having isolated machines (1 service by machine) addresses the issues of package compatibility | 10:25 |
| mgz | okay, stopped fiddling and did that udd/launchpadlib change: <https://code.launchpad.net/~gz/udd/require_launchpadlib_1.9.0/+merge/120132> | 10:25 |
| jml | mgz: LGTM | 10:26 |
| vila | of course devs are supposed to submit their patches upstream or to ubuntu and converge as fast as possible to the standard packages (which is what I had in mind with the pristine-tar issue) | 10:26 |
| jml | vila: I always find such patches more convincing when they have been deployed and been known to work :) | 10:27 |
| vila | jml: isn't it ? | 10:27 |
| vila | That's one more reason to allow devs to deploy them to demonstrate their patch is working no ? | 10:27 |
| jml | yes. | 10:27 |
| * vila feels better :) | 10:28 | |
| vila | lunch break | 10:28 |
| jml | :) | 10:28 |
| jave | hello | 10:43 |
| jave | I have a bzr project where files mysteriously seems to have vanished | 10:43 |
| jave | how can I figure out what happened? | 10:43 |
| jave | heres the project: http://bzr.savannah.gnu.org/lh/emacs/xwidget/files/head:/leim/quail/ | 10:43 |
| jave | and a missing file is latin-post.el | 10:43 |
| mgz | jave: looks like it exists in the branch <http://bzr.savannah.gnu.org/lh/emacs/xwidget/annotate/head:/leim/quail/latin-post.el> | 10:49 |
| mgz | do you mean your local branch doesn't have the file? | 10:49 |
| mgz | try looking in your .bzr.log (see `bzr version` for the location) for 'latin-post.el' to see what's happened to it recently | 10:50 |
| jave | mgz: yes, it doesnt exist in my local copy | 10:51 |
| mgz | so, `bzr status` should tell you the current state vs the last committed revision, but the .bzr.log output may be more useful (if it was bzr that touched the file rather than say, a mistake in the make clean or something) | 10:53 |
| jave | I get: | 10:53 |
| jave | [11406] 2012-08-17 00:01:14.716 INFO: missing leim/quail/latin-post.el | 10:53 |
| jave | [11406] 2012-08-17 00:01:14.717 INFO: deleted leim/quail/latin-post.el | 10:53 |
| jave | 10:53 | |
| mgz | and that's under a 'commit' command? | 10:54 |
| jave | [11406] 2012-08-17 00:01:14.607 INFO: Committing to: /home/joakim/current/build_myprojs/emacsnew/allbranch/my-working-copy/xwidget-bigmerge2/ | 10:54 |
| jave | 0.182 Selecting files for commit with filter None | 10:54 |
| jave | 10:54 | |
| jave | If I understand the log format at all | 10:54 |
| mgz | right | 10:54 |
| mgz | so, something (not bzr) removed the file, then you committed the change without noticing | 10:55 |
| jave | okay | 10:55 |
| jave | hmm | 10:55 |
| jave | how can I get out of this mess? | 10:55 |
| mgz | can fix by bringing the file back and committing | 10:56 |
| jave | should I just checkout again from my upstream? | 10:56 |
| mgz | or if it's a change you haven't pushed anywhere and don't care about, just uncommitting | 10:56 |
| jave | recently ive only merged from upstream trunk | 10:57 |
| jave | anh probably not pushed to the public branch | 10:57 |
| jave | the files arent touched by build command afaics, so something more serious must have happened like a disk failure during copy or something. so, ill probably just checkout from the savannah branch and discard this broken branch | 10:59 |
| jave | anyway, thanks. | 10:59 |
| mgz | jave: so, the simple fix is `bzr revert -rbranch::parent leim/quail/latin-post.el && bzr commit -m "Restore accidentially deleted latin-post.el file"` | 11:01 |
| mgz | which is always safe | 11:01 |
| mgz | but if you're not sure whether you might have other broken changes, and don't have any important changes you've not pushed back yet, then just restoring the branch to the trunk state is fine too | 11:02 |
| jave | mgz: theres a large number of files mising | 11:04 |
| jave | so I would like to revert to a known sane state | 11:05 |
| mgz | right, that does sound like the best option | 11:05 |
| jave | and just hand pick any relevant local changes | 11:05 |
| mgz | you can cherrypick merge from your broken branch to a fresh one | 11:05 |
| jave | yes | 11:06 |
| mgz | hm... qt4-x11 was the last thing out of the queue and it's in again... thought the issues over pending packages were fixed | 12:26 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!