[00:16] <spm> wgrant: it is running; but appears it is rather beautifully broken. possibly from the reroll
[00:29] <spm> wgrant: ok. that looks to be working again. reverted back to prior the rollout and seeing stuff happen again. I call shenanigans
[00:30] <wgrant> spm: As you might have noticed, I've been dropping in and out a bit. What's happened since I LOSA-pinged?
[00:30] <spm> lala. I hadn't.
[00:30] <spm> wgrant: it is running; but appears it is rather beautifully broken. possibly from the reroll
[00:30] <spm> wgrant: ok. that looks to be working again. reverted back to prior the rollout and seeing stuff happen again. I call shenanigans
[00:30] <spm> is all you may have missed
[00:31] <AdamDV-iPod> Would it be revealing too much if someone was able to tell me what is the lp servers run?
[00:31] <thumper> hardy right now
[00:31] <spm> my 2c observation is a misconfig/code mess - looks like it's trying to talk to a local postgres instance, vs the db servers
[00:31] <thumper> or do you mean hardware?
[00:32] <AdamDV-iPod> Nope, hardy is a good answer
[00:32] <AdamDV-iPod> Are there plans to upgrade to lucid?
[00:32] <thumper> yes
[00:32] <AdamDV-iPod> I see
[00:33] <wgrant> OK.
[00:33] <wgrant> What's it dying with?
[00:33] <wgrant_> Argh.
[00:35]  * wgrant crosses fingers, and asks again: How's it failing?
[00:35] <spm> wgrant of the dropouts: psycopg2.OperationalError: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket....
[00:38] <wgrant> So, it seems that my entire Optus cable node drops out whenever I ask how it's broken :P
[00:39] <wgrant> But that looks like a broken config.
[00:40]  * ajmitch would blame the censorship
[00:42] <wgrant> spm: Ahem. So, nothing else is showing that sort of failure?
[00:43] <spm> wgrant: not yet........
[00:44] <wgrant> spm: Because that doesn't look even slightly Soyuzy.
[00:44] <wgrant> I refactored buildd-manager lots during 10.04, but nothing that low-level.
[00:45] <spm> this seems to be a change between the roll; and the reroll; i've reverted to the version from the roll; and that's fine. so... the opportunitys for brokenness are reduced.
[00:45] <AdamDV-iPod> Why python over php or another language?
[00:45] <wgrant> Oh, so it's actually OK now?
[00:46] <wgrant> AdamDV-iPod: Um, well, PHP is... PHP.
[00:46] <spm> and the configs are the same revno; so not config based. my 2c.
[00:46] <wgrant> spm: Bah. I was going to accuse the prod configs.
[00:47] <spm> :-)
[00:49] <AdamDV-iPod> Haha
[00:51] <wgrant> spm: Has it died again, or is it just busy processing uploads?
[00:51] <wgrant> it's not done much for a few minutes.
[00:51] <spm> manually stopped; chasing stuff with jelmer
[00:51] <wgrant> Whereas it should be doing lots every 5 seconds.
[00:51] <wgrant> Ahh.
[00:52] <spm> who isn't here btw. he is 'away'. says so in his irc client.
[01:02] <AdamDV-iPod> Launchpad depends on got-core. How ironic?
[01:02] <maxb> huh?
[01:02] <jelmer> AdamDV-iPod: ah, you mean git-core?
[01:03] <mwhudson> it's for testing git imports
[01:03] <AdamDV-iPod> Yea. Stupid touch screen.
[01:03] <AdamDV-iPod> Oh
[01:03] <AdamDV-iPod> Lp supports git imports?
[01:03] <jelmer> AdamDV-iPod: That's probably to test the git import functionality
[01:04] <AdamDV-iPod> The functionality never ends!
[01:06] <spm> the kitchen-sink module is my personal favourite
[01:07] <maxb> Is there really one?
[01:07] <maxb> Subversion has a kitchen_sink.c :-)
[01:08] <spm> maxb: I have no idea; but I wouldn't be terribly surprised :-)
[01:12] <thumper> AdamDV-iPod: we do everything except what people really want, like wikis and dashboards
[01:12]  * thumper tries not to be too bitter
[01:13] <thumper> must be coffee time
[01:13] <AdamDV-iPod> Haha
[01:13] <AdamDV-iPod> People want wikisband dashboards eg?
[01:14] <thumper> AdamDV-iPod: I don't grok what you just said
[01:14] <AdamDV-iPod> Err, eh. I hate the iKeyboard
[01:14] <Guest44380> Translation: People want wikis and dashboards now, ey?
[01:15] <thumper> Guest44380: how many ids do you have?
[01:15] <AdamDV2> Nah, Nickserv hates me.
[01:15] <AdamDV2> I have AdamDV and TuxIce
[01:15] <AdamDV2> Pidgin randomly cuts out, and doesn't identify to nickserv.
[01:15] <thumper> luckily someone is working on wikis :)
[01:16] <thumper> well that sucks
[01:16] <AdamDV2> Ooh nice :)
[01:16] <AdamDV2> And yes, it does. However, its my only option. I loathe Empathy.
[01:16] <jelmer> thumper: Ooh, I wasn't aware of that - who?
[01:16] <thumper> although since they aren't a priority, it is an idle / evening task
[01:16] <thumper> jelmer: me
[01:16] <thumper> :)
[01:16] <AdamDV2> :D
[01:17] <thumper> jelmer: I should have something that will serve a bzr branch as a wiki soon
[01:17] <AdamDV2> Rocketfuel is installing obsolete versions of postgresql, apparently.
[01:17] <thumper> jelmer: it is my evening fun
[01:17] <thumper> AdamDV2: yeah, not yet updated to 8.4
[01:17] <jelmer> thumper: that sounds really cool
[01:17] <thumper> AdamDV2: it does work with 8.4
[01:17] <AdamDV2> I see.
[01:17]  * thumper uses 8.4
[01:17]  * AdamDV2 uses MySQL
[01:18]  * thumper needs food and coffee
[01:18] <AdamDV2> Heh
[01:18] <jelmer> thumper: It looks like Dulwich trunk itself works but the combination dulwuch+bzr-git is broken against http repos atm :-/
[01:18] <thumper> :(
[01:18] <maxb> Presumably once we go lucid and 2.6 for real, there'll be somewhat more motivation to get on with the move to 8.4
[01:18] <thumper> jelmer: which versions should I take then?
[01:19] <thumper> maxb: there is no reason not to use 8.4 now
[01:19] <jelmer> thumper: the last version I know at least works is from 13 april
[01:19] <thumper> maxb: it was just that stub hadn't gotten around to it
[01:19] <thumper> jelmer: which versions are they?
[01:19] <thumper> jelmer: cause I really wanted 909 of bzr-git
[01:19] <thumper> jelmer: oh, and you commit *a lot*
[01:20] <AdamDV2> I have *never* had apt-get take 1 hour, 15 minutes and going.
[01:20] <AdamDV2> You guys aren't exaggerating when rocketfuel says "This will take awhile"
[01:21] <jelmer> thumper: bzr-git 889, dulwich 562
[01:21] <thumper> AdamDV2: you obviously don't upgrade to the beta OS early
[01:21] <AdamDV2> I don't usually upgrade.
[01:22] <thumper> jelmer: [rs=jelmer] upgrade to lp:bzr-git 899
[01:22] <jelmer> thumper: alternatively I can look at fixing the issue with http, it shouldn't be too hard
[01:22] <thumper> jelmer: from lp's bzr-git branch
[01:22] <thumper> jelmer: if you can fix http, I'll upgrade bzr-git on LP asap
[01:24] <jelmer> thumper: I don't really have time to do that now though, probably friday evening
[01:24] <thumper> jelmer: ok, np, lets look to upgrade early next week
[01:24] <thumper> jelmer: I can add it to my Monday tasks
[01:24] <jelmer> thumper: are you going to be at UDS?
[01:24] <thumper> jelmer: nope
[01:25]  * thumper afk for food
[01:25] <wgrant> thumper: This is where I am confused. Why are the things that would make LP less completely unattractive not priorities?
[01:26] <thumper> wgrant: best answer for that is "ask jml" :)
[01:26]  * thumper takes laptop to coffee ship
[01:26] <thumper> shop
[01:27] <wgrant> Also, I should look at wikkid at some point.
[01:27]  * wgrant looks at wikkid.
[03:23] <thumper> wgrant: I've just pushed my work from the last few days into trunk
[04:02] <maxb> Something deeply weird is happening to the Debian package syncer: https://edge.launchpad.net/debian/+source/subversion/+publishinghistory
[04:09] <ajmitch> it's been happening for awhile, I think
[04:10] <ajmitch> StevenK has been looking at it
[04:10] <ajmitch> at least with regards to out-of-date stuff :)
[04:12] <ajmitch> the old version is due to debian being a bit strange, and having 2 different versions of source packages, see this in 'rmadison -u debian subversion'
[04:19] <maxb> oh, it's picked the version in hurd-i386
[04:20] <maxb> ugh
[04:20] <ajmitch> ugly, isn't it?
[04:21] <maxb> Do you know where the bug might be found (I assume there is one) - registry? soyuz?
[04:23] <ajmitch> most likely related to bug 568745 which I filed
[04:23] <mup> Bug #568745: Debian unstable record of gpt missing <gina> <Soyuz:Triaged by stevenk> <https://launchpad.net/bugs/568745>
[04:23]  * ajmitch should put in the info about duplicate info in the Sources.gz from debian
[04:30]  * AdamDV2 curses
[04:51] <wgrant> ajmitch, maxb: But gina has been able to handle multiple versions for either a few weeks or a couple of days.
[04:52] <wgrant> StevenK: That was one of your first branches, wasn't it?
[04:52] <StevenK> wgrant: I think so
[04:52] <ajmitch> wgrant: that subversion +publishinghistory is showing the first version listed in Sources as being the latest
[04:53] <wgrant> ajmitch: That suggests that it just hadn't picked it up before.
[04:53] <wgrant> Probably because StevenK's change hadn't landed yet.
[04:53] <wgrant> So when his change landed, it picked up both versions. But the real latest version was already there, so it wasn't recreated.
[04:53] <wgrant> So only the old one was new, so it appears to be the latest.
[04:54] <ajmitch> that sounds reasonable
[04:54] <ajmitch> it just looks a little odd when https://edge.launchpad.net/debian/+source/subversion has that old version as the latest upload
[04:54] <wgrant> Yes, that is slightly COMPLETELY INSANE.
[04:54] <StevenK> Right. The bug is that gina is of the opinion that gpt 1.0.4-3 already exists in the database, so it doesn't import it
[04:55] <wgrant> But it's right.
[04:55] <ajmitch> that's special
[04:55] <wgrant> It's not a bug.
[04:55] <wgrant> Oh, wait, different one.
[04:55] <StevenK> wgrant: It does not exist for Debian sid.
[04:55] <ajmitch> at the time I filed that bug the sync hadn't been requested for lucid either
[04:57] <wgrant> Hmm.
[04:58] <wgrant> StevenK: What suggests that it thinks it's already there?
[05:03] <StevenK> wgrant: Because of the log messages
[05:09] <wgrant> StevenK: Pfft.
[05:19] <StevenK> wgrant: You don't have much faith in logs now, do you? :-)
[05:21] <wgrant> StevenK: I might point out that this is gina we are talking about.
[05:21] <wgrant> I don't have much faith in it, let alone its logs.
[05:21] <StevenK> wgrant: Point
[05:25] <StevenK> wgrant: So I think the bug is in _getSource in lib/lp/soyuz/scripts/gina/handlers.py
[05:26] <StevenK> wgrant: Since that function is effectively the one that decides if the package has been imported and can be skipped, or hasn't, and needs to be imported.
[05:28] <wgrant> StevenK: See, I looked at that, but it looks fine.
[05:29] <wgrant> What is the log message that tells you that it's skipping it?
[05:29] <wgrant> I only see a log call when it isn't being skipped.
[05:33] <wgrant> And, well, https://edge.launchpad.net/debian/+archive/primary/+copy-packages?field.name_filter=gpt&field.status_filter=&field.series_filter= makes it pretty clear that 1.0.4-3 was never in that archive.
[05:33] <wgrant> And _getSource's query looks correct to me.
[05:34] <wgrant> StevenK: So, I doubt it's skipping it because it's already there -- unless you have a log message to prove it.
[05:34] <StevenK> Just getting logs synced
[05:49] <StevenK> 2010-05-06 02:06:20 INFO    SourcePackageRelease already published with no chang
[05:49] <StevenK> es as Pending
[05:49] <StevenK> wgrant: ^
[05:50] <StevenK> 2010-05-06 02:06:20 INFO    gpt already exists in the archive
[05:50] <wgrant> Oh, interesting.
[05:50] <wgrant> It really could do with logging the version string, though.
[05:53] <wgrant> StevenK: So, there's only one source version in unstable, but are you sure that's not from a stable/testing run?
[05:56] <StevenK> wgrant: Exactly the same message for sid, lenny and squeeze
[05:58] <wgrant> Hrmph.
[06:02] <StevenK> wgrant: But yes, the SQL reads cleanly and looks right
[06:02] <wgrant> StevenK: Have you tried convincing it to spew SPR/SPPH versions and IDs? I am really really confused at how this can go wrong.
[06:03] <wgrant> My first thought was that it didn't know about archives.
[06:03] <wgrant> But it does.
[06:03] <wgrant> It restricts the location correctly.
[06:07] <StevenK> wgrant: I can't recall how to pull the SPPH out, since the SQL returns the SPR
[06:07] <wgrant> StevenK: The thing prints out 'Pending', so it has the SPPH somewhere there too.
[06:08] <wgrant> But that's probably in publish_sourcepackage.
[06:08] <StevenK> I was thinking in _getSource
[06:08] <StevenK> A debug print of what it thinks is actually in the archive
[06:09] <wgrant> Right, but if you're going to get a patch applied, it's probably best to get as much debugging in as possible.
[06:09] <wgrant> I'd be printing out the version we're searching for, and the found SPR and SPPH IDs.
[06:11] <StevenK> wgrant: http://paste.ubuntu.com/428746/
[06:12] <StevenK> wgrant: I don't think that's enough, but I welcome suggestions
[06:12] <wgrant> StevenK: SPR IDs too, please.
[06:13] <StevenK> wgrant: It's .id?
[06:15] <wgrant> StevenK: Yes. http://paste.ubuntu.com/428748/ would also be handy.
[06:17] <StevenK> wgrant: http://paste.ubuntu.com/428750/
[06:17] <wgrant> StevenK: LGTM
[07:06] <spm> wgrant: LGTM ? Lets Go To Mothers????
[07:07] <StevenK> Looks Good To Me
[07:08]  * spm holds up the humour meter near StevenK ... hrrm. reading near 0....
[07:09] <wgrant> So, yes, hopefully that patch will tell us something less useless.
[08:03] <adeuring> good morning
[09:22] <mrevell> Morning Launchpadderisers.
[09:26] <StevenK> wgrant: Still here?
[09:29] <wgrant> StevenK: I am.
[09:30] <StevenK> wgrant: Right, so we get this:
[09:30] <StevenK> 2010-05-06 07:15:51 INFO    SourcePackageRelease already published with no chang
[09:30] <StevenK> es as Pending (SPPH 478847)
[09:30] <StevenK> 2010-05-06 07:15:51 INFO    gpt already exists in the archive
[09:30]  * wgrant hunts out SPPH 478847
[09:30] <StevenK> I have it, going to paste
[09:30] <wgrant> gpt 1.0.4-1 in sid
[09:30] <StevenK> gpt          | 1.0.4-1        | debian | sid
[09:31] <wgrant> Intriguing.
[09:31] <wgrant> So... you're sure it's looking for -3? Does the log say so?
[09:31] <StevenK> My debug message doesn't fire at all :-(
[09:31] <StevenK> Oh, duh
[09:32]  * StevenK asked spm for the wrong thing
[10:58] <wgrant> archive.txt is too long.
[11:00] <noodles775> yep (well, *exceptionally* long... all the doc tests are long :/)
[11:00] <wgrant> Heh.
[13:27] <maxb> Hrm.
[13:27] <maxb> When the datacentre upgrades to lucid, as a side effect of the updated dpkg, the form of the quilt metadata in all source format 3.0 package import branches is going to change
[13:28] <maxb> From the .dpkg-source-applied file to the .pc/ directory
[13:28] <wgrant> maxb: Hm, it's not already running a very recent dpkg?
[13:29] <maxb> Not *that* recent
[13:30] <maxb> The change is in 1.15.5.4
[13:30] <wgrant> Oh, really really recent.
[13:32] <wgrant> This would be a james_w thing, right?
[13:32] <maxb> yes
[13:48] <james_w> eh?
[14:07] <leonardr> BjornT, can you help me track down the apache configuration for launchpad in production?
[14:08] <leonardr> i thought it would be in lp-production-configs but that only has launchpad configs
[14:10] <BjornT> leonardr: i think you need to ask a losa for that
[14:10] <leonardr> losas, will you induct me into this secret?
[14:20] <maxb> james_w: Once the udd importer starts running on lucid, lucid's dpkg will be producing a different form of quilt metadata in unpacked sources, so there will be spurious churn in the first versions of every 3.0 package imported after the change
[14:20] <maxb> I don't think there's anything to be done about that, though
[14:21] <james_w> no, I don't think so
[14:21] <maxb> In a perfect world we'd move the format change into its own revision, but ETOOMUCHFAFF
[15:47] <manish> leonardr, you free?
[15:47] <leonardr> manish: i'm actually about to go afk for a bit. are you available at around 12:30?
[15:47] <manish> leonardr, 12:30 UTC?
[15:48] <leonardr> manish: sorry, that was stupid
[15:48] <leonardr> in about an hour and a half
[15:48] <manish> leonardr, sure
[15:48] <leonardr> great
[17:19] <jml> wgrant, I'm happy to answer an email, or talk at UDS or what have you
[17:23] <manish> leonardr, am back. Whenever you are free, just tell me
[17:23] <leonardr> manish, i'm back
[17:23] <manish> leonardr, I was just checking your mail again. It is highly insightful. I never thought of that situation
[17:24] <manish> the major question is have is what I mentioned at the end of the second mail I sent. How will the apps know about the new API? this makes Apps API specific?
[17:24] <leonardr> manish: let me pull up your second email to respond in detail
[17:25] <leonardr> but, it's true that there's a limit to the server-side changes that a client can hide from an app
[17:25] <manish> leonardr, i see, this was the mail I was talking about https://lists.launchpad.net/launchpad-dev/msg03314.html
[17:25] <leonardr> thanks for link
[17:25] <leonardr> the advantage of the launchpadlib approach is that even in the worst case, where a client based on launchpadlib totally breaks, launchpadlib itself does not break
[17:26] <manish> leonardr, Yeah. i can see that. Probably that caching is taken care by the library (launchpadlib) rather than the app
[17:26] <manish> another questions is that how will I come to know what all versions of API are present?
[17:27] <manish> means via code? not manually
[17:27] <leonardr> manish: that's a very good question. right now there is no machine-readable advertisement of the available versions
[17:27] <leonardr> i would really like to add one, and if you need it, that would give me a reason to fight for time to add it
[17:27] <manish> or maybe we can parse the +apidoc page to check the existence, but it would be a brutal thing
[17:27] <leonardr> exactly
[17:28] <leonardr> i want to publish a json equivalent of the +apidoc page at http://api.launchpad.net/
[17:28] <manish> another problem with LP is that the WADL file is present behind OAuth
[17:28] <manish> it should be publicly available
[17:29] <leonardr> manish: i agree. the service root and the version list should not be protected
[17:30] <manish> leonardr, what I intend to make is a component which takes in WADL file and then converts it to a library which can be loaded at runtime
[17:31] <manish> and another component which checks the API version and calls the above component
[17:31] <leonardr> that sounds pretty good. let me respond to your message in order
[17:31] <manish> leonardr, sure
[17:32] <leonardr> so we covered #1 a little bit
[17:32] <leonardr> a client written against version 1.0 that uses checkBugIsValid will not break when we release version 2.0 with checkBugValidity
[17:32] <leonardr> it will break, but that's not the time when it will break
[17:32] <leonardr> it will break when 1) someone tries to upgrade it to use 2.0 instead of 1.0
[17:33] <leonardr> or when 2) we end-of-life version 1.0
[17:33] <leonardr> our goal is to work with developers so that they upgrade their applications (and fix problems like this) well before an old version reaches end-of-life
[17:33] <manish> ^^ point. The most apt one
[17:36] <leonardr> so, now on to #2 with that for context
[17:36] <leonardr> wait, does that answer your question about having multiple backends?
[17:37] <leonardr> the idea is that you will have one backend and you will gradually upgrade it to keep it up to date with launchpad
[17:37] <leonardr> since launchpad is always available there's no need to have a 1.0 version and a 2.0 version. once you port your app to 2.0 you can get rid of the 1.0 backend
[17:38] <manish> leonardr, I meant that there is a backend for example named foo
[17:38] <manish> and the app just tells it what version of API it is built for
[17:38] <manish> and the backend foo passed it the library which is linked
[17:38] <leonardr> ah, i see
[17:38] <manish> I havnt done it, just planning to do it this way
[17:38] <leonardr> yes, the app will say it's based on version 2.0, and you will give it a library based on the current wadl file for version 2.0
[17:39] <manish> ^ exactly
[17:39] <leonardr> this should work fine
[17:39] <manish> I think this way there wont be hundreds of copy of the library
[17:39] <leonardr> the one caution i would give you is to make sure you take advantage of whatever caching features are present in your http client
[17:39] <manish> and every app doesnt need to be bundled with a copy of library
[17:40] <leonardr> so that you don't retrieve the wadl file every time
[17:40] <manish> yeah. it would be surely there. It
[17:40] <manish> when the app requests for example v2.0 of API
[17:40] <manish> then foo would hunt for library for it
[17:40] <manish> if not present, it would download the WADL and generate the library
[17:41] <manish> and then passed
[17:41] <manish> the generated library is stored in the library cache
[17:41] <manish> means relevent location as per the OS
[17:41] <leonardr> ok, i just want to be clear that the wadl file for 2.0 may change once a month when a new launchpad is rolled out, or even more often than that on edge
[17:41] <leonardr> you will need to occasionally check for changes and possibly re-download the wadl and regenerate the library
[17:42] <manish> is it so?
[17:42] <manish> once a stable API is released, it should be stable
[17:42] <manish> any new changes should be in a new version.
[17:43] <leonardr> for most new features, it's easier for us to just add them to all versions than to specifically exclude them from old versions
[17:43] <manish> another problem with WADL is the enormous size
[17:43] <manish> it takes minutes to download it
[17:43] <leonardr> you will need to build this flexibility in anyway, to allow clients to access the 'devel' service
[17:43] <manish> something has to be done here
[17:43] <leonardr> manish: this is why i talked about the caching
[17:44] <leonardr> we have made a number of improvements
[17:44] <leonardr> i am working on one final improvement, which is compressing the wadl in transit
[17:44] <manish> leonardr, that's cool
[17:44] <leonardr> (i implemented this a long time ago and only recently discovered that it didn't work)
[17:44] <leonardr> let me quickly outline the levels of caching
[17:45] <leonardr> the first time a user starts an application the full wadl will be downloaded
[17:45] <leonardr> once i make the compression fix, this will be about 100k instead of over 1 megabyte
[17:45] <manish> Yes. based on the app API version
[17:45] <leonardr> yes, per version
[17:45] <leonardr> this wadl file will be used for 1 week (unless it is the devel wadl, but you won't use the devel wadl in a real application)
[17:45] <leonardr> no requests for the wadl at all
[17:46] <leonardr> during that week
[17:46] <leonardr> at the end of that week, the client will make a _conditional_ request for the wadl
[17:46] <leonardr> if the wadl changed in that week (because we rolled a new version of launchpad), the client will download the new wadl--another 100k
[17:46] <leonardr> if the wadl has not changed (because launchpad has not been updated), the client will download nothing
[17:46] <leonardr> and will use the existing wadl for 1 more week
[17:47] <manish> well, how to achieve this?
[17:47] <manish> some headers in the request?
[17:47] <leonardr> yes. it is already implemented in launchpadlib + httplib2
[17:47] <leonardr> i want to make sure you implement it too, or use an existing http client library that understands caching and conditional requests
[17:47] <leonardr> so you can receive the same benefit
[17:48] <manish> I mean does the request to fetch WADL returns a specific header which contains a specific code?
[17:48] <leonardr> yes
[17:48] <manish> like the revision no of the API
[17:48] <leonardr> sort of. there are two headers
[17:48] <manish> then I could do a HEAD request and read this revision no
[17:48] <leonardr> Cache-Control: max-age=604800
[17:48] <leonardr> ETag: "004e1871cab3546c277f7ebae72513058bc6b50f"
[17:48] <leonardr> the ETag is analogous to the revision no
[17:48] <leonardr> the Cache-Control tells the client that it can use this document for 1 week
[17:49] <manish> okay. For each WADL revision,  ETag is different?
[17:49] <leonardr> yes
[17:49] <leonardr> the ETag must change when the document changes
[17:49] <manish> okay. Sort of Hash value?
[17:49] <leonardr> exactly
[17:49] <leonardr> so there's a week when you can just use this document from the cache without requesting it again
[17:49] <leonardr> at the end of the week, you can make a conditional request
[17:50] <leonardr> GET /1.0
[17:50] <leonardr> If-None-Match: "004e1871cab3546c277f7ebae72513058bc6b50f"
[17:50] <leonardr> this tells the server to compare the ETag you give it in If-none-Match against the current ETag
[17:50] <leonardr> if the ETags are the same, that means the wadl has not changed
[17:50] <leonardr> the server will send:
[17:50] <leonardr> 304 Not Modified
[17:50] <leonardr> Cache-Control: max-age=604800
[17:50] <leonardr> that means you can use the existing wadl for another week
[17:51] <leonardr> if the ETags differ, the server will send
[17:51] <leonardr> 200 Ok
[17:51] <leonardr> Cache-Control: max-age=604800
[17:51] <leonardr> ETag: "some-new-etag"
[17:51] <leonardr> and then the new wadl, which you can cache for a week
[17:51] <leonardr> you can make a HEAD request, but then if it turns out the wadl has changed, you will have to make a GET request anyway
[17:51] <leonardr> so you might as well make a conditional GET request
[17:51] <leonardr> does this make sense?
[17:52] <manish> Absolutely. :)
[17:52] <leonardr> great
[17:52] <manish> It clears so many of my doubts
[17:52] <leonardr> like i said, hopefully you can use an existing C# http client that understands these rules
[17:52] <leonardr> they are standard parts of http
[17:52] <leonardr> but if not, they are fairly simple to implement
[17:52] <manish> It's pretty simple to implement this
[17:53] <leonardr> yeah
[17:53] <manish> If-None-Match headers solves so many of my doubts
[17:53] <manish> otherwise I would have gone crazy
[17:53] <leonardr> yes, it's very useful
[17:54] <manish> my biggest fear was what about the people who are under slow internet connection
[17:54] <manish> or who pay per kb
[17:54] <manish> so compression of WADL is very useful
[17:54] <leonardr> yes, it's very bad that the compression system has been broken for so long
[17:54] <leonardr> unless you have any questions, i'm going to go back to work on that
[17:55] <manish> Nope. Nearly all doubts solved which I had presently
[17:55] <leonardr> great
[17:55] <leonardr> ping me again if you have more questions
[17:55] <manish> leonardr, sure.
[18:08] <mrevell> nytol
[18:08] <sinzui> mars, ping
[18:13] <sinzui> salgado, ping
[18:14] <salgado> hi sinzui
[18:14] <sinzui> salgado I am hacking on bug 575317. I cannot delete the account because it is
[18:14] <sinzui> used required by the OpenIDSummary table. I think I need to update that table
[18:14] <sinzui> to point the entries to the remaining account. This may be pointless because
[18:14] <sinzui> other schema parts I do not know about also link to Account. I could change
[18:14] <sinzui> the openid of the merged account to ensure authentication falls back to email
[18:14] <mup> Bug #575317: Person merge must delete merged account <Launchpad Registry:Triaged> <https://launchpad.net/bugs/575317>
[18:14] <sinzui> address
[18:16] <sinzui> salgado, maybe our OpenIdRPSummary table is obsolete. Lp is not the real OpenId provider
[18:16] <salgado> it is obsolete, yes
[18:16] <sinzui> fab
[18:17] <salgado> but you're right that there may be other tables referencing the row you want to delete
[18:18] <salgado> I guess changing the OpenID identifier of the merged account is the easier solution, while we don't get rid of the Account table completely
[18:18] <mars> sinzui, pong
[18:20] <sinzui> There is a function that allows us to change the openid. I could use it to make the merge account unmatchable
[18:20] <sinzui> mars, salgado has confirmed my discoveries about account. ^ I will instead change the account's openid identifier so that there is no match--fallback to the email address to select the Lp person
[18:21] <mars> sinzui, cool
[18:27] <sinzui> mars, I will prepare a script to that we can run in production that will update the merged accounts.
[18:32] <salgado> Chex, the script sinzui described above should make it unnecessary to delete that account you were trying to delete
[18:33] <sinzui> Chex, yes it will. I have will not know the rules of what must change until I complete the test I am writing
[22:01]  * maxb is amused by the Code/Branches backtracking
[22:04] <thumper> maxb: I wasn't particularly happy with the change when it happened
[22:04] <maxb> I like Code better too
[22:29] <wgrant> Can someone please EC2 https://code.edge.launchpad.net/~wgrant/launchpad/bug-576168-no-disabled-latest-ppas/+merge/24812? Vanished instance count so far: 1
[22:42] <wgrant> sinzui: About bug #576478: it doesn't make sense to have Packagings at all for virtual packages like that.
[22:42] <mup> Bug #576478: Common link for virtual package providers <Launchpad Registry:Triaged> <https://launchpad.net/bugs/576478>
[22:42] <sinzui> wgrant, no?
[22:44] <sinzui> wgrant I think we need to know which ones are virtual then...Edwin may have a step to a solution. He is adding real database data for DSPs. We can ignore the packaging questions if the DSP is virtual
[22:45] <wgrant> sinzui: *Binaries* are virtual, not sources.
[22:45] <wgrant> And they won't exist in the DB, since they are virtual.
[22:45] <wgrant> They only exist by being Provided by another binary.
[22:45] <wgrant> They are used for things like mail-transport-agent, where any one of many packages can fulfil the dependencies.
[22:46] <wgrant> They do not represent a particular piece of software.
[22:49] <sinzui> wgrant, I see. Thanks for explaining that
[23:20] <wgrant> Can someone please suspend https://login.launchpad.net/+id/mHhGP3h? He spammed the dev wiki overnight.
[23:22] <maxb> Identity theft too :-(
[23:24] <wgrant> Hm, yes, the name was different a few hours ago.
[23:24] <wgrant> "Eugene Griffin"
[23:25] <wgrant> Oh.
[23:25] <wgrant> Wrong URL.
[23:26] <wgrant> https://login.launchpad.net/+id/7k7hHkp is the real one.
[23:26] <wgrant> (had to steal it from the wiki source, since the links point to the LP person, which doesn't exist)