| jmehdi | hi, I have deleted a package 8 hours ago (webstrict_1.4-0ubuntu1), but I still can see it here: http://ppa.launchpad.net/sabily.team/ppa/ubuntu/pool/main/w/webstrict/, is it normal? | 00:01 |
|---|---|---|
| mwhudson | jmehdi: it takes about a day to disappear iirc | 00:03 |
| maxb | Though it's a bit odd, why does it matter? | 00:03 |
| jmehdi | mwhudson: ok | 00:04 |
| aboudreault | emm i tried to upload (for the first time) a package, and i got this message: .orig.tar.gz already exists in Primary Archive for Ubuntu Linux, but uploaded version has different contents. | 00:10 |
| aboudreault | Why it is checking in "Primary Archive for Ubuntu Linux" ? | 00:10 |
| aboudreault | I've uploaded it in my PPA. | 00:10 |
| wgrant | aboudreault: An orig.tar.gz for that version already exists in Ubuntu. PPAs also look in Ubuntu for their orig.tar.gz. | 00:11 |
| wgrant | But does it really say Ubuntu Linux? | 00:11 |
| wgrant | jmehdi: I've had a look at your PPA through the API, and there's something a bit strange going on. Try deleting the package again. | 00:11 |
| aboudreault | if i remember well, yes. | 00:11 |
| wgrant | aboudreault: It should just say Ubuntu, but anyway. | 00:12 |
| aboudreault | wgrant: so, i have to change the version or what ? | 00:12 |
| wgrant | You should reuse the orig.tar.gz from Ubuntu if possible, but otherwise rename the orig.tar.gz. | 00:12 |
| wgrant | aboudreault: Why not just use the Ubuntu one? | 00:12 |
| aboudreault | could try.. it said that the content was different. | 00:12 |
| aboudreault | will try that. thanks | 00:13 |
| wgrant | jmehdi: It looks like you might have deleted it before the binary was published, so the binary was still published and is keeping the source around. | 00:13 |
| wgrant | jmehdi: When it's properly deleted, you should see "Removal requested on <some time>" in the publishing history. | 00:13 |
| jmehdi | wgrant: could be possible, cause I saw I forgot the ~ppa and deleted it immediately | 00:13 |
| wgrant | jmehdi: You deleted it a couple of minutes after the build finished, but the binary might not have actually entered the system at that point. | 00:14 |
| wgrant | jmehdi: So just try to delete it again. | 00:14 |
| jmehdi | wgrant: ok, deleted again | 00:14 |
| * wgrant checks. | 00:14 | |
| wgrant | It worked. | 00:14 |
| wgrant | At least, the binary is gone. | 00:15 |
| wgrant | So hopefully something will notice that the source can die too, as no binaries reference it. | 00:15 |
| jmehdi | wgrant: ok, I'll try to push again the ~ppa version since its build failed | 00:15 |
| jmehdi | wgrant: could I push it now? | 00:15 |
| wgrant | jmehdi: No. | 00:15 |
| wgrant | But in 7 or so minutes it might work. | 00:16 |
| wgrant | jmehdi: But you just need to retry the build; don't reupload. | 00:16 |
| jmehdi | wgrant: ok, I'll retry the build tomorrow | 00:16 |
| jmehdi | wgrant: got to sleep now, thanks! :) | 00:16 |
| wgrant | jmehdi: np | 00:17 |
| * wgrant files a bug or two about it. | 00:17 | |
| wgrant | jmehdi: "# Removal requested 42 seconds ago. " - the source will go away very shortly. | 00:22 |
| xnox````` | About vcs-imports Are any of the sourceforge imports working? | 00:25 |
| === xnox````` is now known as xnox | ||
| mwhudson | xnox: some of them are, yes | 00:39 |
| mwhudson | xnox: are you the eina import dude? | 00:39 |
| wgrant | mwhudson, maxb: Assuming an absence of bugs like bug #376256, packages seem to be removed after a publisher run or two. Not a day, any more. | 00:41 |
| ubottu | Launchpad bug 376256 in soyuz "Deleting a source before binaries are accepted leaves things published" [Undecided,New] https://launchpad.net/bugs/376256 | 00:41 |
| xnox | mwhudson: nope gnomesword dude | 00:41 |
| mwhudson | xnox: ah | 00:41 |
| * mwhudson has a look | 00:41 | |
| * xnox it never managed to import | 00:41 | |
| aboudreault | wgrant: i assume that i have to download the file *.orig.tar.gz that is on launchpad to generate my `debuild -S -sd` ? | 00:42 |
| aboudreault | s/assume/suppoe | 00:42 |
| aboudreault | suppose. | 00:42 |
| wgrant | aboudreault: You should, yes. | 00:42 |
| mwhudson | xnox: wow, 44 hours and still failing :( | 00:42 |
| aboudreault | How can I find it ? | 00:43 |
| * xnox thinks it's a waste of launchpad unless you want to experiment with such stubborn testcases | 00:43 | |
| aboudreault | ha got it i think. | 00:43 |
| aboudreault | it was on karmic | 00:43 |
| xnox | mwhudson: I'm friendly with upstream is there something they can do from their side? | 00:44 |
| mwhudson | xnox: yes, i am changing it to not try again after five failures | 00:44 |
| mwhudson | xnox: no, not really | 00:44 |
| mwhudson | xnox: i can grab the repo via rsync and import from a file:/// url | 00:44 |
| mwhudson | xnox: but it's a fiddle :/ | 00:45 |
| xnox | mwhudson: ok. I'm pulling into development-subtrees format from scratch and it seems to work locally right now.... | 00:46 |
| mwhudson | xnox: ah, using bzr-svn? | 00:46 |
| mwhudson | xnox: currently launchpad uses cscvs (something else i want to change soon) | 00:46 |
| xnox | mwhudson: yeap. I might just push it to launchpad, *cough* unless it's too much | 00:47 |
| mwhudson | no, should be fine | 00:47 |
| mwhudson | xnox: how big is it? | 00:47 |
| xnox | mwhudson: old one ~100MB I'll wait till I see new one | 00:50 |
| xnox | not as big as I thought.... | 00:50 |
| mwhudson | that's totally fine then :) | 00:50 |
| xnox | cool dude =D | 00:51 |
| * xnox wonders when the first kernel git-repo import to launchpad will happen | 00:53 | |
| mwhudson | there's a little bug/missing feature in bzr-git currently | 00:53 |
| lifeless | xnox: what are you using development-subtrees for? | 00:53 |
| xnox | lifeless: trying to experiment with the new autobuild plugin for nightly builds of software I package =D In addition I'm about to embark on a project were I'll have 4 major parts, though interconnected but yet separate on their own. (one non-free) | 01:00 |
| xnox | subtrees is faster for bzr-svn =D didn't expect | 01:02 |
| xnox | visually not a real benchmark | 01:02 |
| lifeless | xnox: it shouldn't be; subtrees are not supported yet. | 01:02 |
| xnox | lifeless: maybe because priously I was on 1.9-rich-root..... | 01:03 |
| * xnox can't remember exactly but it was always telling "or some other name" | 01:04 | |
| lifeless | xnox: 1.9-rich-root is the current supported format you should use for bzr-svn | 01:04 |
| xnox | lifeless: ok, not killing it since it copied about 1/5 of revisions already... I'll be geany pig | 01:05 |
| lifeless | xnox: if you want to beta test stuff, get bzr 1.15 dev and use --development-rich-root | 01:05 |
| lifeless | *that* is a lot faster and has the same caveats and warnings | 01:05 |
| xnox | lifeless: ok I am on 1.14.1 i'll upgrade | 01:06 |
| lifeless | xnox: did you perhaps mean '--development-rich-root' not '--development-subtrees' | 01:06 |
| lifeless | they are different things | 01:07 |
| xnox | lifeless: nope subtrees, defo | 01:08 |
| lifeless | 1.14 doesn't have --development-subtrees | 01:08 |
| xnox | xnox: bzr --version tells 1.14.1 and help other-formats has development-subtree | 01:09 |
| xnox | is "s" at the end make the difference | 01:10 |
| lifeless | bah, its docs | 01:10 |
| lifeless | xnox: anyhow, dont use development-subtree | 01:10 |
| lifeless | xnox: --development-rich-root is what we're working on | 01:10 |
| xnox | ok | 01:11 |
| lifeless | and it will get subtrees soon | 01:11 |
| lifeless | --development-subtree is actually something different again | 01:11 |
| xnox | real coders don't write documentation, eh =D | 01:13 |
| jelmer | https://launchpad.net/api gives a strange error.. | 01:17 |
| xnox | james_w: ~bzr-nightly-ppa bzr-svn-0.6 hardy, intrepid..... jaunty is missing =( | 01:21 |
| james_w | xnox: yeah, there's a problem with the jaunty packaging branch | 01:22 |
| james_w | I haven't had time to fix it or use the debian packaging branch instead I'm afraid | 01:22 |
| xnox | which one is it? I'm ok at packaging and have some spare time | 01:23 |
| xnox | james_w: lp:~bzr/bzr-svn/jaunty-ppa ? | 01:24 |
| james_w | yeah, I think so | 01:24 |
| james_w | code.launchpad.net/~dailydebs-team to check for sure | 01:25 |
| james_w | it's a problem with the branch itself rather than the packaging though | 01:25 |
| xnox | james_w: jaunty-ppa is stacked onto lp:bzr-svn/0.5 instead of the 0.6 that is lp:bzr-svn apart from that this is the only difference between jaunty vs hardy/intrepid | 01:52 |
| xnox | do you have dailydebs logs to look at? | 01:52 |
| xnox | [hardy|intrepid] ppa are not stacked onto any bzr-svn | 01:52 |
| xnox | how does it manages to merge? | 01:53 |
| xnox | about bzr-svn 0.6 hmmm it asks for username and password? | 01:56 |
| thumper | jelmer: thanks for filing the bug :) | 02:25 |
| === savvas_ is now known as savvas | ||
| wgrant | Grah. Who changed build pages so we can no longer hack URLs to get binaries early? | 03:53 |
| xnox | wgrant: LOL =D you made me laugh | 04:45 |
| wgrant | xnox: How? | 04:45 |
| ajmitch | it's functionality that was quite useful at times | 04:46 |
| wgrant | It was :( | 04:46 |
| wgrant | 20 minutes is quite a while. | 04:46 |
| wgrant | sinzui: I think people are going to have to sometimes live with API breakage, or you're quite constrained in what changes you can make internally. | 04:57 |
| sinzui | wgrant: yes. I just have difficulties with the semantics of alpha and beta | 04:58 |
| jml | sinzui: they are fluid terms, defined very differently by different people. | 04:58 |
| wgrant | sinzui: So does Ubuntu One. | 04:59 |
| jml | sinzui: in terms of API compatibility, if we say "We're breaking API compatibility until we say otherwise", then it doesn't matter to me whether we call it alpha, beta or susan. | 04:59 |
| wgrant | Other products and projects have no problems breaking compatibility at beta. | 04:59 |
| lifeless | suddenly alpha would be less funny than suddently susan | 05:00 |
| jml | wgrant: Python breaks compatibility with every major release | 05:00 |
| wgrant | jml: Yes... in very subtle and unexpected ways, as we've found with 2.5->2.6... | 05:01 |
| sinzui | wgrant: jml: we namespaced the URL to support different versions so that users have reliability. I cannot foresee a day when the API wont be beta. | 05:01 |
| wgrant | sinzui: That's an awful lot of compat shims. | 05:01 |
| wgrant | I can't see that happening. | 05:01 |
| * sinzui already as a 1400 line diff in review to remove a compatability shim | 05:02 | |
| jml | wgrant: Twisted has had issues with every release from 2.4 on. | 05:02 |
| jml | sinzui: hasn't it been reviewed yet? | 05:02 |
| sinzui | jml: no | 05:02 |
| wgrant | jml: We didn't exist for 2.4->2.5, fortunately. | 05:02 |
| * jml fixinates. | 05:03 | |
| wgrant | sinzui: All that for just removing canonical.launchpad.webapp.testing? | 05:03 |
| wgrant | Impressive. | 05:03 |
| wgrant | I guess that means you have lots of tests. | 05:03 |
| sinzui | wgrant: 3 deft find and replaces, 4 reversions, and 8 hand fixes in 30 minutes. no more canonical.launchpad.testing | 05:04 |
| wgrant | sinzui: Pretty easy review, then. | 05:04 |
| sinzui | very boring. I may have to provide coffee to who ever does it | 05:05 |
| jml | sinzui: I confess here and now, I'm not doing a detailed line-by-line review. | 05:05 |
| * wgrant blames jml for any future breakage. | 05:06 | |
| sinzui | jml: the import UnitTest as LaunchpadUnitTest is a speed bump in the diff | 05:06 |
| sinzui | I'm sure all eyes are on me at the moment. | 05:07 |
| cody-somerville | Does anyone notice the big fat problem on edge? | 05:09 |
| cody-somerville | <g> | 05:09 |
| cody-somerville | Someones made those tiny little icons repeat-x | 05:09 |
| sinzui | my that is fun. A chorus line of me | 05:10 |
| cody-somerville | ugh... | 05:10 |
| wgrant | The icing probably hasn't updated yet. | 05:10 |
| cody-somerville | if you force refresh, there is like... no styling at all | 05:10 |
| wgrant | The icing updates in a minute or so, from experience. | 05:11 |
| wgrant | Hmmm, still not fixed. | 05:11 |
| wgrant | There we go. | 05:11 |
| * wgrant checks what's new. | 05:11 | |
| cody-somerville | wee | 05:11 |
| cody-somerville | fixed | 05:12 |
| xnox | that was fun =D | 05:12 |
| xnox | I did manage to catch it =D | 05:12 |
| wgrant | (that was the daily edge update, I presume) | 05:13 |
| xnox | are there any "eastern eggs" on launchpad? | 05:16 |
| xnox | apart from famous LP:1 | 05:16 |
| * xnox wants to fix bug 1 | 05:16 | |
| ubottu | https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout) | 05:16 |
| sinzui | xnox: all the easter eggs are in the test | 05:16 |
| sinzui | tests | 05:17 |
| spm | wgrant: you presume correctly. to help avoid bigger issues, we accept a small window of server A is new and amazing, with server B being old and boring versions of edge. Which means you can get funnies. | 05:35 |
| wgrant | spm: But is it intentional that the new icing takes a while to get there? | 05:38 |
| spm | no. that's not cause and effect. you're getting part of new server, and part of old - end result is weirdness | 05:39 |
| lifeless | do we include the revno in the icing url | 05:39 |
| wgrant | Oh, I thought the icing would be served by the load balancer. | 05:39 |
| wgrant | lifeless: You do. | 05:39 |
| wgrant | So both could be present at once. | 05:40 |
| lifeless | spm: so what we need to fix this, is for squid to only ask new servers for requests after a single server is upgraded | 05:41 |
| lifeless | spm: or for old servers to have the new icing url | 05:41 |
| spm | lifeless: of get the devs to improve the stop/start/working now time? :-P | 05:41 |
| spm | s/of/or/ | 05:41 |
| lifeless | spm: nah, the race is orthogonal to that; think of 0-downtime planning | 05:41 |
| spm | I dunno. yah try for a troll, and he takes the question seriously.... /me sighs | 05:42 |
| wgrant | Speaking of 0-downtime... is read-only-launchpad fixed yet? | 05:42 |
| lifeless | wgrant: thats not really 0-downtime | 05:43 |
| spm | lifeless: seriously tho - if we can make squid do that? that'd be great! just need to hook it into logic around edge1 potentially not restarting and remaining dead till human^Wlosa intervention. | 05:44 |
| wgrant | lifeless: I know, but it's related enough that it reminded me of it. | 05:44 |
| lifeless | spm: should be doable, number of ways | 05:45 |
| lifeless | spm: safesty would be to down <some N>, upgrade, bring up <some N> disabled from squid, then tell squid <switch to those N only> repeat on the others, enable all. | 05:49 |
| lifeless | spm: easiest way is simply to change the peer definitions | 05:49 |
| spm | yeah makes sense. the logistics of making it so ... hmmmm. not so much not-doable, but.... | 05:50 |
| lifeless | its three squid --reconfigure calls | 05:53 |
| maxb | wgrant: https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA#Deleting%20packages says it's a half-hourly cronjob | 06:54 |
| wgrant | maxb: Aha, that would explain it. | 06:57 |
| wgrant | maxb: But things seem to not be marked for removal immediately after deletion; I wonder if the publisher does that. | 06:57 |
| maxb | I assume the publisher has to republish the Packages/Sources files before the files become candidates for deletion | 06:58 |
| wgrant | Ah, true. | 06:58 |
| === herb__ is now known as herb | ||
| ianto | Hello I have an issue with an inactive translation team in launchpad, what can be done to ensure that it is possiblle to revive the team? | 09:19 |
| henninge | ianto: Have you tried to contact the team? | 09:20 |
| ianto | They were last active in 2007 so I'm guessing their email doesn't work anymore | 09:20 |
| ianto | s/2007/2006 | 09:21 |
| ianto | https://edge.launchpad.net/~ubuntu-l10n-cy/+members#active , people are trying to join but obviously no-one can accept them | 09:22 |
| ianto | It also means that I can't upload .po files because I am not on the team | 09:23 |
| henninge | ianto: I, too, have email addresses much older than 2006 so there is no reason to assume the admin cannot be contacted. | 09:24 |
| henninge | ianto: please try that first. | 09:24 |
| henninge | ianto: other than that you can talk to dpm about it. | 09:25 |
| ianto | OK... I've had at least 20 email addresses since ;06 and only check 2 now but I will email Daffydd too | 09:25 |
| henninge | ianto: really? why do you change them that often? I've had mine since 1996, I think. | 09:26 |
| ianto | henninge: Well more like 15 than 20, 20 was an over-estimate and because I like cool domain names :) | 09:27 |
| henninge | ;-) | 09:27 |
| wgrant | mrevell: Thanks! | 09:52 |
| mrevell | wgrant: You got it? Cool :) | 09:53 |
| wgrant | mrevell: Yep. | 09:53 |
| rowinggolfer | good morning fellas | 09:54 |
| wgrant | cprov: Under what conditions are binary uploads rejected because of a newer upload? Only if newer binaries exist, or also if the source is superseded/deleted? | 10:14 |
| cprov | wgrant: let me check, one sec | 10:15 |
| wgrant | (I also notice that lots of binary uploads for the rebuild are failing, because they seem look for ancestry in the primary archive too) | 10:16 |
| cprov | wgrant: binaries conflict only with published files in the repo (no blacklisted versions) | 10:16 |
| cprov | wgrant: failed-to-upload in the rebuilds ? | 10:17 |
| wgrant | cprov: Yes, lots of them. | 10:17 |
| wgrant | Because there are newer binaries in primary. | 10:17 |
| wgrant | (well, not *lots* yet) | 10:17 |
| wgrant | http://people.ubuntuwire.com/~wgrant/rebuild-ftbfs-test/ | 10:17 |
| cprov | wgrant: the lookups should not leak to the primary archive. | 10:17 |
| wgrant | cprov: Shall I file a bug, then? | 10:18 |
| cprov | wgrant: probably, wait a second | 10:19 |
| wgrant | Copy archives also don't follow ogre-model, which makes them a bit misleading. | 10:21 |
| cprov | wgrant: that's a configuration bug, isn't it ? | 10:22 |
| wgrant | cprov: I didn't think there was a configuration option for that, but I could well be wrong. | 10:23 |
| cprov | wgrant: +edit-dependencies should allow owners to say 'Follow primary archive components' | 10:23 |
| wgrant | cprov: Oh, true. I forgot about that. | 10:24 |
| wgrant | cjwatson: ^^ You might want to fix that, if you can. | 10:26 |
| cprov | wgrant: crap, binary uploads to copy archives do no reach the publishing tables ... we have to process them. | 10:29 |
| cjwatson | wgrant: I'm not sure I understand. What should I fix? | 10:30 |
| wgrant | cprov: I did ask about that last night, but somebody seemed to think they'd be processed. | 10:30 |
| cprov | wgrant: was it me ? | 10:30 |
| cjwatson | it's a karmic rebuild test, surely it's correct for it to build against karmic | 10:30 |
| wgrant | cjwatson: ogre-model isn't being respected in the rebuild; you need to tell it to use the right components. | 10:30 |
| wgrant | cprov: No. | 10:31 |
| cjwatson | oh, gotcha | 10:31 |
| cjwatson | fixed | 10:31 |
| wgrant | cjwatson: Thanks. | 10:31 |
| cjwatson | are there any build failures due to that? | 10:32 |
| cjwatson | by the way, the ubuntuwire ftbfs pages would be a lot more useful if they had links to the build page in LP for each architecture | 10:32 |
| cjwatson | (well, each arch that fails) | 10:33 |
| cjwatson | at the moment they link to the source, the sourcepackagerelease, and the build log | 10:33 |
| cjwatson | makes it awkward to do retries | 10:33 |
| wgrant | cjwatson: They initially did show that, but it was decided to change them to point to the log instead. You can easily enough get to the build page with two clicks (one to get to the DSPR, and one in the builds portlet to the build) | 10:34 |
| wgrant | But I can probably add an extra link in each cell, somewhere. | 10:34 |
| persia | I believe that was my request, because I usually wanted to look at logs, and when it was just rebuild buttons, usually wanted to do it for several architectures (for which the sourcepackagerelease was a good landing location) | 10:35 |
| wgrant | I might split the two parts of the text in each cell. | 10:35 |
| wgrant | The arch to the build, the letter to the log? That sort of makes sense, although it's a bit odd... | 10:35 |
| wgrant | Does anybody have any good ideas? | 10:36 |
| persia | I'm not that worried about my usage, because I've not been giving FTBFS as much time as I'd prefer, so don't block just to support my previous request. | 10:36 |
| wgrant | There were requests to link directly to the logs from others too. | 10:37 |
| wgrant | And requests to link the build page. | 10:37 |
| cprov | wgrant: right, need a bug for binary upload ancestry lookup, it's looking up Primary archive. | 10:37 |
| wgrant | cprov: Alright, will file. | 10:38 |
| cprov | wgrant: i.e, every source that is new in karmic will fail-to-upload. | 10:38 |
| wgrant | Yep. | 10:38 |
| persia | splitting build/log by arch/letter could work, but probably needs documentation on the page. | 10:38 |
| wgrant | persia: Certainly. | 10:38 |
| wgrant | cprov: Why weren't the binary uploads being processed? Are PPA/primary/partner processed by separate jobs? | 10:39 |
| cprov | wgrant: https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20090513/+build/1002174 is a good example. | 10:39 |
| wgrant | cprov: Yep, I've seen several of those. | 10:39 |
| cprov | wgrant: PPA & PRIMARY/PARTNER are separated | 10:39 |
| wgrant | cprov: OK, interesting. | 10:39 |
| cprov | wgrant: that is less urgent than the lookup issue, but annoying for debug. | 10:40 |
| wgrant | cprov: But they're all on cesium (or its successor?), as each set of buildds can be used for either? | 10:41 |
| cprov | wgrant: yes, the binary uploads are waiting in the copy-archive ACCEPTED queue, no worries, it will catch up when we CP. | 10:42 |
| cprov | wgrant: we only have 8 failed-to-upload builds (up to sources starting with 'c') | 10:42 |
| cprov | https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20090513/+builds?build_text=&build_state=uploadfail | 10:42 |
| wgrant | cprov: I know (I prefer http://people.ubuntuwire.com/~wgrant/rebuild-ftbfs-test/, although it has update latency), but they will get more frequent as the rebuild progresses. | 10:43 |
| wgrant | cprov: Erm, al-maisan fixed the ancestry bug in 2.2.4. | 10:44 |
| wgrant | Bug #369209 | 10:44 |
| ubottu | Launchpad bug 369209 in soyuz "Rebuild archive: versions are erroneously checked against primary archive for binary uploads" [High,Fix released] https://launchpad.net/bugs/369209 | 10:44 |
| cprov | wgrant: apparently missed some bits ... | 10:45 |
| wgrant | cprov: Reopen, or file again? | 10:45 |
| cprov | wgrant: re-open, I'd say | 10:45 |
| cprov | wgrant: it's exactly the same issue reported, right ? | 10:45 |
| wgrant | cprov: There's no error message, and I don't know if there's something else it could have meant, but it certainly seems to be the same issue... | 10:46 |
| wgrant | You'd best reopen it, I guess. | 10:46 |
| wgrant | Bugs people: Why on earth are there three links to edit tags now? | 10:47 |
| cprov | wgrant: it's clear in the apport upload-processing log: apport_1.1.1-0ubuntu1_all.deb: Version older than that in the archive. 1.1.1-0ubuntu1 <= 1.1.1-0ubuntu2 | 10:47 |
| cprov | wgrant: that version only exist in karmic PRIMARY | 10:47 |
| cprov | wgrant: moreover, there are no binary publications in the COPY archive itself | 10:48 |
| cprov | wgrant: no ancestries should be found ... | 10:48 |
| cprov | wgrant: it's erroneously falling back to PRIMARY, although it's not clear why it's doing it by looking at the code. | 10:49 |
| wgrant | cprov: One would think. But the fix for the bug might have been to have it check the COPY archive, which then decides to cascade to PRIMARY because it has none. I can't see the diff :P | 10:49 |
| cprov | wgrant: ehe, you are so funny, Jef! :) | 10:50 |
| cjwatson | wgrant: links directly to the logs are useful too. I don't have any bright UI ideas but I'm sure it would fit somewhere :-) | 10:52 |
| cprov | wgrant: on the bright side these failed-to-upload builds do not affect the rebuild results, after all a new source was uploaded to karmic and built. | 10:53 |
| wgrant | cprov: jef does seem to have taken over from my previous role rather well! | 10:53 |
| wgrant | But yes, the upload failures don't matter, as long as the bug gets fixed. | 10:54 |
| cprov | wgrant: no kidding, he comments every single blog post I read ... | 10:55 |
| maxb | Hmm. It occurs to me that IIUC, with the way scoring works, anyone who wants to retry a failed PPA build is out of luck until the rebuild finishes | 10:55 |
| bigjools | yes, we need to fix that | 10:56 |
| wgrant | maxb: I pointed something similar out last night, and cprov then pointed that particular case out. | 10:56 |
| wgrant | Although nobody filed a bug. | 10:56 |
| wgrant | Or was it bigjools. | 10:56 |
| wgrant | I forget. | 10:56 |
| * maxb will file a bug in a bit if no one already has | 10:56 | |
| wgrant | (language packs also get ignored, as they are scored to 0) | 10:56 |
| cprov | maxb: thanks, meanwhile, bug me for rescoring your retries. | 10:57 |
| bigjools | maxb: I don't think there is one, thanks | 10:57 |
| maxb | I don't have any at the moment, it was just a random thought passing through my head :-) | 10:58 |
| maxb | Can anyone think of any reason why retries shouldn't keep their original score? | 11:04 |
| wgrant | maxb: I can't; I can almost as easily upload a new source if I want to DoS the buildds. | 11:05 |
| maxb | Actually, a new upload would go on the end of the queue - a retry at original score would go to the front of the queue (within packages of the same score) | 11:05 |
| cprov | maxb: yes, that source already had its build slot. It shouldn't be as easy as a 'click' to get in front of the build queue again. | 11:06 |
| maxb | hmm | 11:06 |
| wgrant | I imagined it would be scored as normally, ie. without the time bonus initially. | 11:06 |
| maxb | Would going to the front of the queue actually be an issue? | 11:07 |
| wgrant | If we have abusive people, yes. But there are better ways of dealing with them than punishing everybody. | 11:07 |
| maxb | I mean, you'd need a very stupid person indeed to sit there mashing retry repeatedly | 11:07 |
| cprov | maxb: for the other people, kinda yes. | 11:07 |
| bigjools | I think we shou;ld probably be more trusting | 11:07 |
| wgrant | Trust generally works well in Launchpad. | 11:07 |
| bigjools | yes | 11:07 |
| wgrant | People who abuse that trust just get booted out. | 11:07 |
| cprov | it makes more sense to keep the original score in PPA domain | 11:08 |
| bigjools | exactly | 11:08 |
| maxb | Why not in the primary archive too? | 11:08 |
| cprov | maxb: otherwise main retries would dominate universe, for instance. | 11:09 |
| cprov | and that doesn't seem fair | 11:09 |
| wgrant | I don't see a problem with that, really. | 11:09 |
| bigjools | how many retries are done, typically? | 11:09 |
| wgrant | Hmm, actually. | 11:10 |
| maxb | Shouldn't main retries be more important than universe anyway? | 11:10 |
| wgrant | We do sometimes have mass-givebacks. | 11:10 |
| wgrant | Which block the port buildds for several days. | 11:10 |
| maxb | Point | 11:10 |
| wgrant | In PPAs it's fine, because there are dozens of buildds. | 11:10 |
| wgrant | But most port archs only have two rather slow buildds. | 11:10 |
| wgrant | So cprov is right. | 11:10 |
| maxb | Maybe it should be mass-giveback => 0, individual-giveback => original score? | 11:11 |
| wgrant | That would be ideal. | 11:11 |
| wgrant | And easy enough, I suspect - given that the mass-giveback script already has to retry them, it must be easy for it to rescore too. | 11:11 |
| * maxb needs to go now, but will summarize this conversation into a bug later | 11:12 | |
| cprov | well, it's actually more complex than this, mass-retry are strictly done by buildd-admins and keep their original score, currently | 11:13 |
| cprov | because we do *trust* buildd-admins :) | 11:13 |
| wgrant | cprov: But buildd admins can rescore even through the web UI. | 11:14 |
| cprov | the individual UI build retry (mostly done by uploaders) resets the score | 11:14 |
| cprov | wgrant: right | 11:14 |
| wgrant | So the retry UI needs to set the score to the original value, and the script/SQL just has not reset the score, or set it to 0 | 11:14 |
| wgrant | s/has not/has to not/ | 11:14 |
| cprov | wgrant: don't know if buildd-admins would agree with that change in the mass-retry | 11:15 |
| wgrant | cprov: It wouldn't change the behaviour from the current one, would it? | 11:15 |
| wgrant | Only the individual retry behaviour would be altered. | 11:15 |
| cprov | wgrant: the question here is to whether or not trust uploaders and keep the original score values for UI retries | 11:15 |
| cprov | UI == UI & API soon | 11:16 |
| wgrant | cprov: You trust us to upload. You must trust us to retry with a normal score. | 11:16 |
| cprov | I don't have strong arguments for the current behavior, we can change it if it make everyone happier. | 11:16 |
| wgrant | But none of this is actually necessary; you could just give retries a static score of more than 4. | 11:17 |
| cprov | ERRRR, missing cherrypick for the binary upload ancestry lookup issue | 11:18 |
| cprov | FFS! | 11:18 |
| wgrant | cprov: Ahaha. | 11:18 |
| wgrant | cprov: But... wasn't it on 2.2.4 db-devel, so wouldn't require a CP? | 11:18 |
| cprov | wgrant: we should have required the re-rollout on the builddmaster machine :-/ | 11:19 |
| wgrant | cprov: I recall a similar problem occurred a couple of months ago... | 11:19 |
| wgrant | You went looking for an issue, and found the builddmaster was out of date... | 11:19 |
| cprov | wgrant: last release, the email query ... we are getting good at it :( | 11:20 |
| wgrant | cprov: Ah, yes. | 11:20 |
| * wgrant must remember to look at the dates of commits in future, as each Launchpad milestone is in fact multiple milestones! | 11:21 | |
| bigjools | wgrant: we do a re-roll after the main release to fix release issues | 11:23 |
| wgrant | bigjools: I know, but forgot that stuff was still targetted to the previous release, not the next. | 11:24 |
| wgrant | (really there should be a 2.2.4.1 milestone, but I guess that makes things overcomplicated) | 11:24 |
| bigjools | no kidding :) | 11:24 |
| bigjools | maybe a close-out date | 11:24 |
| wgrant | Or just a point on the re-roll checklist to update the builddmaster, of course. | 11:26 |
| bigjools | that'd be handy | 11:26 |
| SiDi | Hi | 11:58 |
| SiDi | How can i check which of my GPG keys my PPA is linked to, please ? | 11:58 |
| SiDi | Also, if i want to change my GPG key for a PPA, do I have to sign the CoC again with the new key ? How to do so, if it's needed ? | 11:59 |
| wgrant | SiDi: Check on the page for your user - any keys there have access to the PPA. | 12:00 |
| wgrant | And no, your upload key doesn't have to have signed the CoC - any one key on your account will do. | 12:00 |
| SiDi | Ah good to hear | 12:03 |
| SiDi | so any active key will work for my PPA ? | 12:03 |
| wgrant | Yes. | 12:03 |
| SiDi | Ok, cheers | 12:03 |
| wgrant | np | 12:04 |
| === salgado-afk is now known as salgado | ||
| === fta_ is now known as fta | ||
| === salgado is now known as salgado-brb | ||
| fta | when will bug 371640 land? | 13:01 |
| ubottu | Launchpad bug 371640 in soyuz "Upload processing order is unstable" [Medium,Fix committed] https://launchpad.net/bugs/371640 | 13:01 |
| fta | cprov, ^^ any idea? | 13:02 |
| cprov | fta: 2.2.5 | 13:02 |
| cprov | fta: 27th this month | 13:03 |
| cprov | fta: is it causing you extra trouble with the mozilla-daily PPA ? | 13:03 |
| fta | i had to add a workaround, a 10 minutes delay between the upload of the orig and the rest, so it's slowing down my work | 13:05 |
| fta | i guess 27th is fine | 13:05 |
| === salgado-brb is now known as salgado | ||
| mok0 | How do you compare different branches with bzr? | 13:36 |
| james_w | compare them how? | 13:36 |
| james_w | diff? | 13:36 |
| mok0 | I get this: bzr: ERROR: Files are in different branches | 13:36 |
| james_w | ah | 13:36 |
| james_w | "bzr diff --old branch1 --new branch2 path" might be the trick | 13:36 |
| mok0 | james_w: well, what I _really_ want is to compare a local branch to one at LP | 13:36 |
| mok0 | james_w, the --new and --old addition works for my local branches! | 13:38 |
| james_w | ace | 13:38 |
| mok0 | ... and the same is true if I substitute "lp:blahblah", so thanks! | 13:38 |
| james_w | should work for remote branches too | 13:38 |
| mok0 | bingo! :-) | 13:38 |
| james_w | I think there's a proposal to make that case a bit easier to type as well | 13:40 |
| mok0 | I just typed it without the --new and --old | 13:40 |
| mok0 | ... and that doesn't work | 13:40 |
| intellectronica | i usually do `bzr diff -r branch:$BRANCH_URI ./` | 13:40 |
| mok0 | james_w: on LP, can I retract a merge request? (It's and older one that turned out to be bogus) | 13:43 |
| mok0 | james_w: it was already rejected but it remains on the list | 13:43 |
| james_w | mok0: I'm not sure sorry, I would have thought rejecting it would work | 13:43 |
| mok0 | james_w: that would be the logical thing | 13:44 |
| james_w | the LP folks make much more use of merge proposals than me though, so maybe someone else has experience | 13:44 |
| wgrant | You could delete them last time I tried. | 13:44 |
| james_w | or maybe they never have to reject a proposal :-) | 13:44 |
| wgrant | Although i don't think it's good to. | 13:44 |
| beuno | you can delete | 13:46 |
| beuno | there has to be a trash icon next to the title | 13:46 |
| mok0 | wgrant: ah, /me will try that | 13:46 |
| james_w | hey beuno | 13:46 |
| james_w | anyone know if there is any delay between marking a branch the development focus and the stacking policy being set up to stack on it? | 13:48 |
| james_w | (I'm mainly interested in package branches, but I assume it is the same) | 13:48 |
| beuno | james_w, hrm, not that I know of | 13:48 |
| james_w | I'm getting inconsistent results, so a slight delay could be the cause | 13:48 |
| beuno | it's db-driven, so no cron jobs involved | 13:48 |
| jml | james_w: database deprecation lag is a possibility. | 13:48 |
| jml | deprecation. sheesh. | 13:48 |
| mok0 | ah, yes, there's a trashcan... | 13:48 |
| jml | _replication_ | 13:48 |
| james_w | jml: ah, a possibility | 13:48 |
| jml | james_w: what sort of delay are you seeing? | 13:48 |
| james_w | I'm not sure | 13:48 |
| james_w | whenever I try it by hand it works | 13:51 |
| james_w | but some of the branches that I pushed up last night didn't stack | 13:51 |
| james_w | e.g. https://code.edge.launchpad.net/~ubuntu-branches/debian/lenny/tipa/lenny | 13:51 |
| jml | james_w: ahh, bummer. | 13:51 |
| james_w | I can't see how they would be pushed in the wrong order | 13:51 |
| james_w | hmm, it's not just Debian | 13:51 |
| james_w | https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/warty/tipa/warty | 13:51 |
| jml | james_w: I would guess replication lag. | 13:51 |
| james_w | yeah | 13:51 |
| james_w | I'll add a sleep? | 13:51 |
| jml | james_w: oh, also there's a cache in the codehosting service... | 13:51 |
| * jml looks | 13:51 | |
| jml | ... but we don't cache the stacking information. | 13:51 |
| jml | james_w: I'm not sure what the work-around is. I'm not even sure that polling the server to detect a change in stacked-on location would be enough. | 14:05 |
| james_w | why's that? | 14:05 |
| jml | james_w: because the polls might be going to the master database. | 14:05 |
| james_w | ah | 14:06 |
| jml | james_w: I honestly don't know if that's a possibility though. | 14:06 |
| jml | james_w: maybe you want to raise this question with launchpad-users -- it's a valid, interesting, generic API question. | 14:06 |
| james_w | but the push isn't over the API? | 14:08 |
| jml | james_w: the codehosting server doesn't use the webservice APIs, no. | 14:08 |
| james_w | so when I set the link for the development focus it goes to the master, but codehosting might hit a replicated db when it checks whether there is something it should stack on? | 14:10 |
| jml | james_w: yeah. | 14:17 |
| james_w | ok | 14:17 |
| james_w | and I guess you won't make the check go to the master? | 14:17 |
| jml | james_w: we might change it to do that. | 14:17 |
| james_w | it seems like normal usage wouldn't trigger this | 14:19 |
| jml | james_w: but a) it's not obvious to me right now; b) I'd want to double check with stub or flacoste before we did that; c) it wouldn't take effect until the end-of-may rollout | 14:19 |
| james_w | or when it did it wouldn't cost much | 14:19 |
| james_w | I can put a sleep that waits for the replication delay | 14:19 |
| jml | james_w: that will reduce the number of misses, definitely | 14:19 |
| james_w | the rate of misses seems to be rather high | 14:19 |
| james_w | so I think it's in our interests | 14:19 |
| jml | cool. | 14:19 |
| james_w | any idea what a sensible delay would be? | 14:19 |
| jml | james_w: no, not really. ask stub or flacoste, or mail launchpad-users | 14:19 |
| james_w | ok, thanks | 14:20 |
| stub | replication delay is normally < 10 seconds | 14:20 |
| james_w | thanks stub | 14:20 |
| * jml really needs to go to bed. | 14:22 | |
| stub | If it is replication, we should be able to cope with ridiculous delays though as there are occasions it will spike to hours (screwups, failures, database maintenance operations) | 14:22 |
| stub | There are lots of moving parts though, so replication might not be the culprit. There is also the thingy that mirrors branches from the private areas to the public areas etc. | 14:23 |
| james_w | yeah, it's not a correctness thing in this case, but an efficiency thing | 14:24 |
| james_w | it was creating ~2x as much data as needed | 14:24 |
| james_w | but I'll give it a go with the sleep and see if the miss rate falls sufficiently | 14:24 |
| jml | it won't be the mirroring in this case. | 14:26 |
| * jml gone | 14:27 | |
| === asac_ is now known as asac | ||
| flacoste | jml, james_w: afaik, the codehosting system talks through XMLRPC which always use the master, unless the code explicitely ask for the solve, so unlikely | 14:38 |
| === Lure_ is now known as Lure | ||
| flacoste | s/solve/slave/ | 14:38 |
| james_w | hmm | 14:38 |
| flacoste | leonardr: i hit voicemail? | 14:38 |
| === matsubara-afk is now known as matsubara | ||
| === salgado_ is now known as salgado | ||
| === matsubara is now known as matsubara-afk | ||
| === thunderstruck is now known as gnomefreak | ||
| === salgado changed the topic of #launchpad to: https://launchpad.net/ | Help contact: salgado | Join https://launchpad.net/~launchpad-users | Channel logs: http://irclogs.ubuntu.com | ||
| exarkun | How do I stop getting email about changes to a bug that doesn't affect a project I'm developer on but was incorrectly marked as affecting it? | 16:12 |
| beuno | exarkun, you can't at the moment :( | 16:12 |
| exarkun | :( | 16:12 |
| aboudreault | E_NEEDMORESPACE | 16:12 |
| aboudreault | :P | 16:12 |
| AnAnt | Hello, is there a problem with bzr ? | 16:36 |
| AnAnt | I mean on launchpad | 16:36 |
| AnAnt | I can't browse code.launchpad.net | 16:36 |
| beuno | AnAnt, which exact URL? | 16:37 |
| AnAnt | ah, it worked now | 16:37 |
| davideotape | It might be a generic launchpad problem | 16:37 |
| AnAnt | I see, thanks | 16:37 |
| beuno | mthaddon, flacoste ^ | 16:37 |
| davideotape | It's being a bit on and off for me at the moment. Sometimes it loads, sometimes it doesn't:-( | 16:37 |
| mthaddon | there does seem to be a problem with app servers at the moment, yes | 16:37 |
| tethridge | are you guys having issues with your servers now? | 16:42 |
| tethridge | I can't submit a bug | 16:42 |
| tethridge | a bug update that is | 16:42 |
| beuno | tethridge, we are | 16:42 |
| noodles775 | tethridge: yes, there seems to be a problem with the app servers at the moment. | 16:42 |
| tethridge | ok | 16:42 |
| === beuno changed the topic of #launchpad to: https://launchpad.net/ | Help contact: salgado | Join https://launchpad.net/~launchpad-users | Channel logs: http://irclogs.ubuntu.com | We are having some server issues, they are being worked on | ||
| jblount | barry: Hiya! Is it weird to think that a link to the archives url for that paticular message? | 16:50 |
| barry | jblount: hi! um, what? | 16:50 |
| jblount | barry: So I have emails froma mailing list, and sometimes I want to send someone a link to it (like on twitter). To do this, I have to poke around the archives. | 16:50 |
| jblount | barry: It'd be nice if the each mail (in the links at the bottom) had a link to the archive absolute url | 16:51 |
| barry | jblount: absolutely! it's a wishlist for mm3 http://wiki.list.org/display/DEV/Stable+URLs | 16:52 |
| barry | jblount: it requires some coordination between the archiver and the list manager | 16:55 |
| barry | jblount: unfortunately, i cannot give you an eta | 16:55 |
| jblount | barry: This is fantastic, I thought I was probably bringing up something already suggested. Thanks for the linkage :) | 16:55 |
| barry | np! | 16:55 |
| aemyr | Does anyone know when Launchpad will be back ? | 16:55 |
| aemyr | I need to report a bug | 16:55 |
| jblount | aemyr: Sorry, is LP down? It seems to work here... | 16:56 |
| davideotape | Unless the server issues were planned, I don't think anyone knows exactly when they'll be back up:-D | 16:56 |
| davideotape | It's not down as such | 16:56 |
| davideotape | Just being a bit hit and miss at the moment | 16:57 |
| aemyr | Whenever i try to report a bug it gives me the "Please try again" page :( | 16:57 |
| jblount | aemyr: Yikes! Sorry for my confusion, I was just working in blueprints and didn't notice anything. | 16:57 |
| aemyr | works now | 17:01 |
| aemyr | i have submitted my bug report w00t | 17:01 |
| MacYET | hi, why is LP so flaky since days? often getting error pages? | 17:03 |
| jblount | aemyr: Welld one :D | 17:03 |
| davideotape | Does anyone know why you can't add tags to a bug whilst reporting it? | 17:07 |
| davideotape | ? | 17:09 |
| === matsubara-afk is now known as matsubara | ||
| === salgado is now known as salgado-lunch | ||
| geser | wow, the i386 PPA builders have a queue size of nearly 13000 packages | 17:51 |
| bigjools | geser: yes there's a rebuild in progress, but they have low priority | 17:52 |
| hggdh | er. https://edge.launchpad.net/~launchpad-beta-testers asks one to join the mailing list, and provides a link to do that. The link goes straight into the mail archives, though | 17:52 |
| cruisemaniac | Hi, i was wondering if there is a desktop app for launchpad which can be used as alternative to using the site on the browser? | 17:55 |
| geser | bigjools: is this expected? http://launchpadlibrarian.net/26675042/upload_1002174_log.txt | 17:56 |
| geser | bigjools: looking at https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20090513/?field.name_filter=apport&field.status_filter=published&field.series_filter=any I see only the the -0ubuntu1 version there | 17:57 |
| bigjools | geser: yes, there was a fix done last cycle but didn't get released properly, it will be released soon | 17:57 |
| === Ursinha is now known as Marvin_ | ||
| === Marvin_ is now known as Ursinha | ||
| luke_ | hi | 18:10 |
| luke_ | can i delete my launchpad acccount? | 18:11 |
| === Ursinha is now known as Marvin_ | ||
| === Marvin_ is now known as Ursinha | ||
| === salgado-lunch is now known as salgado | ||
| beuno | inline bug tag editing | 19:27 |
| beuno | woooooooooooooooooooooooooooooooooooooooooooooooooooo | 19:27 |
| Ursinha | beuno, where!? I tried this morning and it didn't work | 19:28 |
| beuno | Ursinha, edge has been re-rolled out! | 19:28 |
| beuno | EVERYWHERE | 19:28 |
| * Ursinha looks | 19:29 | |
| Ursinha | beuno, !!!!!!!!!!!!!!!!!! | 19:29 |
| Ursinha | who did that!? | 19:29 |
| beuno | Ursinha, intellectronica and mars | 19:30 |
| intellectronica | Ursinha: mars did most of brilliant stuff, and i helped integrate it | 19:30 |
| Ursinha | weeeeeeeee | 19:30 |
| * Ursinha hugs intellectronica and mars | 19:30 | |
| mars | Ursinha, glad it works :) | 19:32 |
| intellectronica | Ursinha: of course, any help with testing will be much appreciated :) | 19:33 |
| === salgado_ is now known as salgado | ||
| Ursinha | intellectronica, count me in :) | 19:34 |
| intellectronica | :) | 19:34 |
| Goundy | Hi back. | 19:38 |
| Goundy | Quick question, just fmi. | 19:38 |
| Goundy | Is launchpad going to offer a small wiki for hosted projects in the future ? | 19:39 |
| beuno | Goundy, yes | 19:39 |
| beuno | it's the first thing we want to do as soon as we finish our 3.0 cycle (these next 2 or 3 months) | 19:39 |
| Goundy | beuno do you know if they talk about somewhere on the launchpad web site ? | 19:39 |
| Goundy | Ah I see | 19:39 |
| Goundy | Thank you beuno that's grateful | 19:39 |
| Goundy | Time to go to bed :) | 19:40 |
| Goundy | Thanks again and good night ;) | 19:40 |
| * jblount is stoked on inline bug editing | 19:41 | |
| === niklas_ is now known as nh2 | ||
| nh2 | is there any way how I can make building faster in launchpad (e.g. using my own computer as build daemon or something like that)? | 21:09 |
| === rker1 is now known as rowan | ||
| === rowan is now known as rkerr | ||
| persia | nh2, No. If your computer is faster, and you have a stable connection, you can build locally and have a repo on your server. | 21:24 |
| persia | If you want to use the shared server, you have to wait. This helps enforce the rule that for any binaries, that source is available (and it's known how to turn the source into the binary). | 21:25 |
| nh2 | persia: OK | 21:25 |
| nh2 | wouldn't it be nice to use a computing clound (I've heard Ubuntu is going to develop certain capabilities here) so that every Ubuntu user had an option to participate and help building packages? | 21:27 |
| nh2 | sorry I meant *cloud* | 21:28 |
| persia | nh2, Well, maybe, but that's more complex, and not likely soon, to say the least. | 21:33 |
| aruetten | Hy, can anyone give me a short estimation how far we are from mirroring git repositories in launchpad? 1 week, 1 month, 1 year, ... ? | 21:50 |
| beuno | mwhudson, ^ | 21:52 |
| mwhudson | aruetten: about two weeks hopefully | 21:52 |
| aruetten | oh, cool. thanks | 21:52 |
| === salgado changed the topic of #launchpad to: https://launchpad.net/ | Help contact: - | Join https://launchpad.net/~launchpad-users | Channel logs: http://irclogs.ubuntu.com | ||
| mwhudson | aruetten: if you have a particular import you're interested in, you can request it on staging | 22:01 |
| aruetten | mwhudson: I have tried this a few minutes ago. staging says: The URI scheme "git" is not allowed. Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp | 22:05 |
| ablert | I'm attempting to create a more up to date version of teh pgpool2 package in hardy. and upload that to my ppa. I believe I've followed the instrucitons apropriately but i get the following error: Not permitted to upload to the RELEASE pocket in a series in the 'SUPPORTED' state. | 22:06 |
| ablert | would anyone have any suggestions for me? | 22:06 |
| aruetten | mwhudson: I have to create branch with a external location for that, right? | 22:07 |
| aruetten | mwhudson: I mean mirrored | 22:09 |
| mwhudson | aruetten: no | 22:15 |
| mwhudson | aruetten: https://code.staging.launchpad.net/+code-imports/+new | 22:15 |
| aruetten | mwhudson: thanks, that works so far | 22:19 |
| === salgado is now known as salgado-afk | ||
| === matsubara is now known as matsubara-dinner | ||
| wgrant | beuno: What are these branch listing sparklines? Revisions per day? | 22:45 |
| beuno | wgrant, yes | 22:47 |
| wgrant | beuno: They're a bit fat and ugly :( | 22:47 |
| beuno | ouch | 22:47 |
| wgrant | I think the red is the problem. | 22:47 |
| beuno | yes, the colors suck | 22:47 |
| beuno | but | 22:47 |
| beuno | could I see a screenshot? | 22:48 |
| playya_ | is it possible tio import a git repository to launchpad? | 22:49 |
| wgrant | beuno: http://williamgrant.id.au/f/1/2009/sparkline.png | 22:50 |
| wgrant | beuno: The colours are off, and it looks quite tall. I think it actually fits, but the spacing is off now. | 22:51 |
| wgrant | (the 'lp:apport' is much lower than it should be) | 22:51 |
| beuno | wgrant, right, that's roughly what i se | 22:51 |
| satirik | hey there | 22:52 |
| satirik | anyone can review my translation file on launchpad here ? | 22:53 |
| wgrant | I think if the colours matched those used in the rest of Launchpad, and the spacing is fixed, it would be pretty good. | 22:53 |
| beuno | wgrant, agreed | 22:54 |
| beuno | any other thoughts? | 22:54 |
| beuno | satirik, when have you submitted it? | 22:54 |
| wgrant | beuno: No, it's pretty nice otherwise. | 22:55 |
| satirik | yesterday | 22:56 |
| beuno | wgrant, good to hear. The main driver is to be able to, at a glance, get the feel of how active a branch is | 22:56 |
| beuno | in this case, trunk | 22:56 |
| beuno | so, other projects look knda inactive: https://code.edge.launchpad.net/bzr-upload | 22:56 |
| wgrant | beuno: Should they also appear on branch pages? | 22:57 |
| beuno | wgrant, yes, they will extend there, as well as project pages | 22:57 |
| beuno | this is an initial test | 22:57 |
| beuno | to take the technology for a spin | 22:58 |
| beuno | and figure out the UI | 22:58 |
| wgrant | Yep. | 22:58 |
| wgrant | Certainly a good idea. | 22:58 |
| beuno | cool, more of these things will slowly creap in | 22:59 |
| beuno | and since it's rendered with javascript (canvas) | 22:59 |
| beuno | it's scalable and such | 22:59 |
| beuno | so we will be able to do interesting things with it | 22:59 |
| satirik | so anyone can help me ? | 23:00 |
| beuno | satirik, nobody's around right now | 23:00 |
| satirik | k | 23:00 |
| beuno | but they will get to it pretty soon | 23:00 |
| beuno | usually they get reviewed within 24-48hs | 23:00 |
| wgrant | beuno: Good to see you're not letting IE hold you back. | 23:01 |
| beuno | danilos will help if not | 23:01 |
| satirik | k thank you | 23:01 |
| beuno | wgrant, hell no. Although there's a library that will add compatibility for it, just haven't had the courage to bloat launchpad even more yet | 23:01 |
| wgrant | That inline tag editor is nice, too. | 23:05 |
| beuno | :) | 23:05 |
| * KaptenRodSkagg_ is away: Jag är upptagen | 23:22 | |
| === matsubara-dinner is now known as matsubara | ||
| === fta_ is now known as fta | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
