| costello | cjwatson thanks, yes, the fact that it is under /usr/share and not /usr/include was a bit misleading. .. should I really make copy of the file or say #include "/usr/share/gettext/gettext.h" .. say, now it is #defined to npgettext_aux and if that detail of internal implementation is to change in the future, then.. | 17:28 |
|---|---|---|
| cjwatson | costello: You should follow the directions in the gettext documentation, which say to copy it | 17:28 |
| cjwatson | costello: npgettext_aux is a static function declared in that same header file | 17:29 |
| costello | Ok, getgext.h is gpl. my package is lgpl and can't be gpl due to openssl licensing stupidities -> does this pose a problem? | 17:29 |
| cjwatson | costello: No idea, ask the gettext maintainers | 17:30 |
| costello | If I'm supposed to copy that. And that way also distribute it. | 17:30 |
| costello | yes. | 17:30 |
| cjwatson | I imagine you could just do the same things with dcgettext/dcngettext that it does | 17:31 |
| cjwatson | That's the actual important function, the rest is just syntactic sugar over the top | 17:31 |
| costello | y. better idea. | 17:31 |
| vila | hmm, something is weird with https://code.launchpad.net/~vila/bzr/1451448-skip-racy-tests | 17:54 |
| vila | launchpad doesn't show the diff even after way longer than usual (not a metric ;) | 17:55 |
| vila | bzr push --overwrite after 1 hour says 'No new revisions or tags to push' so the data is there | 17:56 |
| cjwatson | vila: run this in "lp-shell production devel": lp.branches.getByUrl(url="lp:~vila/bzr/1451448-skip-racy-tests").unscan(rescan=True) | 20:51 |
| vila | cjwatson: lp-shell ? never heard about that before | 20:52 |
| cjwatson | vila: (LP's bzr branch modelling is terrible and requires inserting a row for every revision in the branch's history when you push a new branch, so it often times out for large histories) | 20:52 |
| cjwatson | vila: it's in lptools | 20:52 |
| cjwatson | basically just a Launchpad.login_with wrapper, but convenient | 20:52 |
| cjwatson | vila: if the history isn't there after six minutes (technically five but let's make sure not to overlap) after you attempt the rescan, try it again, repeat until it actually manages to scan the thing | 20:53 |
| vila | cjwatson: ack, ran | 20:54 |
| vila | cjwatson: but well, it's 2 or 3 commits on top of trunk, I doubt we were close the limit before that... | 20:55 |
| cjwatson | vila: it depends how hot things are in the DB (or something) | 20:55 |
| cjwatson | vila: and this is not the first bzr branch that has timed out this way, by any means | 20:55 |
| vila | cjwatson: ack, thanks for the feedback anyway ;) | 20:55 |
| cjwatson | vila: it may happen a bit less often for bzr than it does for LP itself, but we've had a number of other reports | 20:56 |
| vila | cjwatson: but the row has to be inserted for any bzr branch right ? Err, bzr the tool, not the project. I.e. every lp project using bzr share the same db table right ? | 20:57 |
| cjwatson | they all use BranchRevision, yes | 20:57 |
| cjwatson | but the number of rows varies wildly | 20:57 |
| vila | so bzr the project itself shouldn't be more affected than any other project no ? | 20:57 |
| cjwatson | it is, because it has quite a deep history | 20:57 |
| vila | cjwatson: oh, the cache... | 20:58 |
| vila | cjwatson: anyway, it worked ! Thanks a lot | 20:58 |
| cjwatson | no, not the cache | 20:58 |
| vila | cjwatson: so little activity on bzr that the revs are not cached anymore ? | 20:58 |
| cjwatson | <cjwatson@niejwein ~/src/bzr/bzr/bzr.dev>$ bzr log | grep --count '^ *revno:' | 20:58 |
| cjwatson | 6609 | 20:59 |
| cjwatson | you don't understand how terrible the LP data model is here | 20:59 |
| cjwatson | if you push a new branch of bzr based on the above, it will insert 6609 + (something small) rows | 20:59 |
| cjwatson | instead of, say, (something small) | 20:59 |
| cjwatson | and it turns out that trying to insert thousands of rows is slow | 21:00 |
| vila | O_o even for already known revisions ? | 21:00 |
| cjwatson | yes | 21:00 |
| * vila heart stops | 21:00 | |
| cjwatson | it's revision per branch | 21:00 |
| cjwatson | like I say: terrible | 21:00 |
| vila | I've heard stories about that table since... barcelona 2009 ? But I never realize there was revnos per *branch* :-( | 21:01 |
| cjwatson | unrolling the whole graph into the DB in an incredibly inefficient way | 21:01 |
| vila | cjwatson: say no more ;-} | 21:01 |
| cjwatson | we avoided repeating this mistake for the git data model, obviously | 21:01 |
| vila | well, you don't revnos in git anyway ;) | 21:02 |
| cjwatson | it's not revnos anyway, it's revisions | 21:02 |
| cjwatson | i.e. not just the left-hand side | 21:02 |
| cjwatson | LP itself is at revno 17709, but every new LP branch we push involves inserting well over a hundred thousand rows | 21:03 |
| cjwatson | it is very annoying | 21:03 |
| vila | bzr has revids, what you mention seems related to revnos, i.e. for the same revid, tracking all the revnos in the branches | 21:03 |
| cjwatson | err | 21:03 |
| cjwatson | no it's not | 21:03 |
| cjwatson | it's branch * revision (revid if you like), it's not relevant if they share revnos in many cases | 21:04 |
| cjwatson | and it's not an attempt to track revnos, it's more like a performance-terrible implementation of merge detection | 21:04 |
| * vila rollbacks | 21:05 | |
| vila | ok, so you mean for each branch (irrelevant of whether revisions are shared via repositories), a list of *all* revisions is maintained and used to detect merges ? | 21:06 |
| cjwatson | yes | 21:06 |
| vila | and this doesn't try to use the bzr code that do the same but knows how to load only part of the graph ? | 21:06 |
| cjwatson | possibly other reasons | 21:07 |
| vila | yeah, ok, nm ;) | 21:07 |
| cjwatson | I don't think there's any point analysing exactly why it got that way TBH | 21:07 |
| cjwatson | I believe it's trying not to use the bzr code in question because that would require a callout to a system that actually has the branches in question | 21:09 |
| cjwatson | merge detection is done just with the LP database | 21:09 |
| cjwatson | that said, for the git implementation, we said screw that, we just call out to the git hosting system and ask it to do merge detection | 21:10 |
| cjwatson | much easier | 21:10 |
| cjwatson | William had part of a BranchRevision 2.0 implementation at one point, but then we did git instead | 21:11 |
| * vila nods | 21:11 | |
| wgrant | To be fair, at the time the code was devised, bzr LCA detection wasn't exactly fast. | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!