[00:31] <smoser> skaet, updated https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
[00:31] <skaet> Thanks smoser!  :)
[00:31] <smoser> we are generally a go with cloud images 20111130.
[00:31] <smoser> https://jenkins.qa.ubuntu.com/job/precise-server-ec2/
[00:31] <smoser> we've not recorded those test results in the iso tracker, bu tthey're there, and only 2 minior issues. one of which i've fixed.
[00:32]  * skaet nods
[01:04] <stgraber> skaet: we're back to i386 and amd64 ubuntu alternate fully tested
[01:04] <skaet> stgraber,  excellent!!!  :)  thank you
[01:10] <charlie-tca> skaet: all of xubuntu passed on hardware except wubi. I can not do wubi tests here.
[01:10] <skaet> charlie-tca,   thank you.
[01:11] <skaet> wubi tests won't work without the images being respun (see comments)
[04:02] <skaet> pitti,  Technical overview has updates from the ISO tracker and some of the bugs from the Oneiric Release Notes that still seem to be present and folks might stumble into.    Its missing a few edits from the teams still.
[04:07] <skaet> pitti,  If you start publishing images before I am online again,   given there hasn't been much testing there's some I don't think we should release.   amd64+mac, powerpc ones are lacking significant testing in Ubuntu.   Also,  there's been no definitive statement or evidence of much testing from the Kubuntu images by this point (other than the work Gruemaster did on the arm ones) so unless the picture drastically
[04:07] <skaet> changes in the next few hours,   I recommend that Kubuntu not be released as part of alpha 1.
[04:09] <skaet> pitti,  word from smoser and utlemming is that the cloud images are good, so even though they're not on the tracker, they should be good to publish.
[04:19]  * skaet --> zzz
[05:03] <pitti> Good morning
[05:05] <pitti> skaet, jibel: for wubi we'd only need to respin the CDs, not the live images (so archive skew doesn't matter), but still, +1 from me for release-noting
[05:07] <pitti> skaet: ok, I'll disable powerpc, but the diff of amd64+mac is tiny, I think we should releasea them
[05:08] <pitti> skaet: kubuntu desktops got some testing; we could skip kubuntu alternates, as they weren't tested at all
[05:09] <pitti> skaet: thanks for the summary
[07:02] <pitti> stgraber, cjwatson: committed publish-image-set.py port to isotracker_xmlprc, thanks stgraber for adding the API!
[07:02] <pitti> yay no more screenscraping
[08:24] <jibel> pitti, while waiting for wubi, I can test kubuntu alternate.
[08:24] <pitti> ah, I already pinged apachelogger
[12:28] <infinity> pitti: What's the story with A1?
[12:28] <pitti> infinity: I think we are as ready as we can be
[12:28] <pitti> we'll skip kubuntu alternates, no testers (pinged apachelogger, no response)
[12:28] <infinity> pitti: Oh good, so that klibc upload I just did can be considered post-freeze. ;)
[12:28] <pitti> infinity: I was just about to lift the freeze
[12:29] <infinity> (itchy trigger finger)
[12:30] <pitti> infinity: see #u-devel :)
[12:30] <ogra_> infinity, whats that bash ftbfs ?
[12:31] <ogra_> do we have a fix for that ?
[12:31]  * pitti publishes the images
[12:32] <infinity> ogra_: I think we do.  Lemme refresh my memory.
[12:33]  * ogra_ thought he heard doko say something 
[12:34] <infinity> Yeah, I thought so too.
[12:59] <pitti> smoser, Daviey: can you please publish the alpha-1 cloud images?
[12:59] <pitti> (they'll need some time to mirror, I figure)
[13:00] <pitti> I am currently publishing the a1 images
[13:19] <smoser> pitti, they're all "pre-published", so 10 minutes it will be public. i will do that now.
[13:44] <smoser> pitti, https://cloud-images.ubuntu.com/server/releases/precise/alpha-1/ is public.
[13:46] <ogra_> pitti, http://cdimage.ubuntu.com/releases/precise/alpha-1/ misses the actual arm images (still mirroring ? or is that an oversight)
[13:46] <ogra_> oh, mirroring delay
[13:46] <ogra_> ignore me
[14:02] <pitti> smoser: ah, I didn't know you do pre-publishing for alphas (ubuntu isos don't)
[14:03] <pitti> ogra_: yes, mirroring
[14:11] <stgraber> pitti: cool!
[14:13] <smoser> pitti, basically after we test something we go through the entire publish process other than the ec2 equivalent of "chmod g+r".  that is what I call "pre-publish". it takes like an hour now so we do it ahead of time.
[14:16] <pitti> skaet: mirroring of published images completed; release away :)
[14:18] <stgraber> skaet, pitti: Just updated the TechnicalOverview for Edubuntu, sorry for not doing that earlier
[14:19] <pitti> stgraber: cheers
[14:28] <nessita> skaet: hey there! I was wondering if you had any news regarding what mdeslaur asked you yesterday re: licenses for the qt4reactor packaging
[14:53] <skaet> pitti,   good day
[14:53]  * skaet catching up on the backscrolll
[14:54] <skaet> nessita,  yup gots some input from folks, but need to get release sorted out first,  I'll ping you and mdeslaur later in the day after that's sorted.
[14:55] <mdeslaur> skaet: cool, thanks!
[14:55] <nessita> skaet: thanks!
[14:55] <pitti> hey skaet
[14:56] <skaet> pitti,  I've just gone and looked at the iso tracker,  only 1/7 of the mandatory tests have been run on the desktops,  and no one from Kubuntu has bother to update the Techncial overview.   That's not good enough for release.
[14:57] <pitti> skaet: ok, fair enough; I can reasily remove them from /relelases/ again
[14:57] <pitti> "easily"
[14:57] <pitti> skaet: what about lubuntu?
[14:58]  * skaet looking
[15:00] <skaet> pitti,  lubuntu's been well tested, and documented in the release notes - is there some issue I'm not catching?
[15:01] <pitti> skaet: it wasn't in your release announcement that you sent to me
[15:01] <pitti> skaet: I published it
[15:01] <skaet> lol
[15:03] <skaet> pitti,  it was an oversite in my announce - thanks for catching.  :)
[15:03] <skaet> and publishing
[15:03] <pitti> skaet: I replied to your mail, could be that there was something else, too
[15:03] <pitti> but I think it was just that
[15:03] <skaet> yup,  just scanned it now.   Will add in the changes.
[15:07] <pitti> skaet: please let me know when you are done with wiki editing; I want to add that the i386 ubuntu desktop is oversized (or you do it while you are at it, I don't mind)
[15:09] <skaet> pitti,  done.   There's already a statement in it at the top, but repeating won't hurt
[15:09] <skaet> This release is for developers only. Most of these images are oversize; you can use either a DVD or USB for installation instead of a CD.
[15:10] <skaet> pitti,  would appreciate you taking another pass at it,  and seeing if anything else needs to be tweaked.
[15:10] <pitti> skaet: "most of" is really an exaggeration :) ok, fixing
[15:10] <skaet> ;0
[15:10] <skaet> :) even
[15:11] <pitti> updated for oversized; doing another pass (had one this morning, but we got updates since then)
[15:16] <skaet> thanks!
[15:19] <brendand> skaet - i'll try and run a bunch of the kubuntu tests, can't do anything about the technical overview though
[15:20] <skaet> brendand,  its too late now.
[15:20] <brendand> skaet - ah, have we released?
[15:20] <skaet> brendand,  on the last stages now.
[15:21] <pitti> skaet: FYI, removing the two crash reports from known issues; we have client-side apport dup checking now
[15:23] <skaet> brendand,  all the other images are tested and have been documented.   I don't want to keep the web-team and pitti around after their normal EOD at this stage.
[15:24] <pitti> skaet: fixed a couple of "oneiric"s and typos, done now
[15:24] <skaet> pitti,  thanks for catching those.  ;)
[15:25] <skaet> brendand,  thank you for offering though,  and any testing you do do,  I expect the Kubuntu developers would appreciate getting feedback on the images and if there are other bugs that should be caught.
[15:32] <jibel_> skaet, we should add to the release notes that Ubuntu can't currently be upgraded from Lucid ?
[15:32] <pitti> skaet: FTR, cdimage cronjobs re-enabled
[15:32] <skaet> jibel_, yes,  that one should be mentioned.    Please add.
[15:33] <pitti> jibel_: oh, we can't? sounds like something the stable+1 team (*cough*) ought to fix ASAP
[15:33] <pitti> jibel_: do we have an auto-tester for this?
[15:33]  * skaet didn't know about it either.... good catch
[15:33] <jibel_> pitti, yes I added it this week.
[15:34] <pitti> nice
[15:34] <pitti> jibel_: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/PROFILE=main-all,label=upgrade-test/ is for oneiric->precise, though, right?
[15:34] <jibel_> pitti, there are resolving issues with the X stack, some ABI breakage I think, but didn't go into details
[15:34] <cjwatson> bug 898482
[15:34] <ubot4> Launchpad bug 898482 in update-manager (Ubuntu Precise) (and 1 other project) "Lucid to Precise upgrade fails: release upgrader fails to start (affects: 1) (heat: 8)" [Critical,Triaged] https://launchpad.net/bugs/898482
[15:34] <pitti> still trying to find my way there
[15:35] <jibel_> cjwatson, that's another one, even with this one fixed, it won't upgrade
[15:35] <cjwatson> ah
[15:35] <mvo> "can't load DistUpgradeViewGtk (Unknown internal child: selection)
[15:35] <mvo> " is fixed in bzr
[15:35] <jibel_> I'll finish server profiles and will publish the results
[15:36] <cjwatson> ah yes, bug 898551
[15:36] <ubot4> Launchpad bug 898551 in update-manager (Ubuntu Precise) (and 1 other project) "lucid desktop i386 -> precise upgrade failed: Resolver failed to calculate the upgrade (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/898551
[15:36] <jibel_> right
[15:36] <jibel_> and with server upgrades, I can't connect with ssh after upgrade
[15:41] <pitti> skaet: do you still need me for anythign? if not, I'd call it a day (you can SMS/call me if you need, of course)
[15:42]  * skaet goes and looks at the process list....  
[15:43] <skaet> pitti,  was the upgradetestingprocess completed?
[15:43] <pitti> skaet: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/
[15:44] <pitti> skaet: i. e. there's a corner case with full multi-arch and full main: which is failing (investigating), but the others are green
[15:45] <skaet> when you switched cron back on,  has the default_milestone been changed to Daily, or is that still pending?
[15:46] <pitti> skaet: oh, for ISO tracker, right
[15:47]  * pitti tries to figure this out
[15:48] <pitti> stgraber, jibel_: is that the "Daily CDs" milestone in http://91.189.93.73/admin/config/services/qatracker/milestones (currently "archived"), or should I create a new "Precise Daily" one? I'm not sure how it was disabled
[15:48] <stgraber> stgraber: there's a "Precise Daily" milestone somewhere on there
[15:48] <stgraber> doh :)
[15:48] <stgraber> pitti: ^
[15:48] <pitti> stgraber, jibel_: nevermind, found "precise daily"
[15:49] <pitti> stgraber: so I flip alpha-1 to "released" and precise daily to "testing"?
[15:49] <stgraber> pitti: yep
[15:50] <pitti> done, and updated the notice
[15:50] <pitti> http://91.189.93.73/ cross-check?
[15:50] <stgraber> looks good
[15:50] <cjwatson> remember to change ~cdimage/.isotracker.conf in sync too
[15:51] <pitti> done
[15:51]  * pitti documents on https://wiki.ubuntu.com/MilestoneProcess
[15:52] <pitti> + 1. Update the ISO tracker to set the milestone to "released", re-enable the "daily", and update the notice.
[15:52] <pitti> skaet: all set
[15:52] <pitti> (MilestoneProcess already documented .conf)
[15:52] <skaet> pitti,  Thanks for all your help today!   Have a good evening. :)
[15:53] <mvo> re the upgrade failure lucid->precise, it appears that with the backported apt this works actually, the packages are currently in ppa:mvo/lucid-precise-upgrades but should move to lucid-backports eventually
[15:53] <mvo> or lucid-proposed maybe, not entirely sure yet
[15:53] <pitti> so, good night!
[15:53]  * skaet waves to pitti
[15:54] <skaet> mvo,  thanks - definitely want to make sure those get added in to lucid and well tested before 10.04.4
[15:56] <stgraber> cjwatson: so skaet and I were wondering yesterday if we now have something in place to avoid images that were published on the tracker from being removed from cdimage
[15:57] <stgraber> and if not, what would help to make that happen, I introduced builds.get_list yesterday but it only lists active builds, not superseded ones (that we usually like to keep too)
[15:57] <stgraber> the new tracker also knows the path on cdimage for most/all of the builds, I could export that through the API too if that'd help
[16:04] <cjwatson> well, we can't keep all superseded builds
[16:04] <stgraber> not enough space?
[16:04] <cjwatson> perhaps anything that was pushed for a milestone
[16:05] <cjwatson> we only keep about two or three days of dailies normally
[16:05] <stgraber> right, by superseded builds I meant anything that was posted on the tracker for a given milestone
[16:05] <cjwatson> all superseded builds would be all dailies ever :)
[16:05] <cjwatson> that would be OK
[16:06] <stgraber> so whatever does the cleanup would look for builds associated with the milestone definied in ~/.isotracker.conf on the tracker (if the current milestone isn't a daily milestone) and never remove one of these
[16:06] <stgraber> then when the milestone is no longer marked as testing, these will get cleaned up as usual
[16:07] <stgraber> that'll avoid situations where we want to keep an image as a fallback and it ends up being removed from cdimage
[16:07] <cjwatson> cdimage already knows how to map from its own idea of the world to the iso tracker, so probably no need to duplicate that
[16:07] <cjwatson> give me a method to get all builds and I'll see what I can do :)
[16:11] <stgraber> cjwatson: ok, code updated to support doing that, you'll need this applied to ubuntu-archive-tools: http://paste.ubuntu.com/756098/
[16:12] <stgraber> default behaviour for get_builds remains that same, but you can now give a list of status that you want to list
[16:13] <stgraber> if you want everything, you'll need to use [0,1,2,3] (0 = current, 1 = rebuilding, 2 = removed, 3 = superseded)
[16:13] <cjwatson> mkay
[16:15] <cjwatson> committed that
[16:15] <ogasawara> skaet: I'd noticed pitti mentioned that archive is unfrozen now in #ubuntu-devel.  I just wanted clarification as I was under the assumption we're still frozen until you send the official announcement out?
[16:17] <skaet> ogasawara,  yes, its a little out of order, but we'll not be respinning at this stage, so is ok.
[16:17] <ogasawara> skaet: but just for future reference I assume I should wait for the announcement
[16:18] <skaet> ogaswara,  yes please
[16:18] <ogasawara> skaet: ack, thanks.
[17:09] <skaet> Alpha 1 is release!
[17:15] <Laney> nice quote!
[17:16] <skaet> Laney aka HOHOHaney  thanks!  :)
[17:18]  * HOHOHaney jingles some bells
[17:18] <skaet> :)
[17:43] <skaet> mdeslaur, nessita - from the results of my pinging, there doesn't seem to be a lot of precedent discussed on this so far based on the folks I've talked to.  Standard disclaimers apply - I'm not a lawyer.    Feeling is since the MIT licensed code is dynamically loading the GPL/LGPL/other bits as it needs them,  the MIT code shouldn't be derived work, so things should be ok,  based on what I was reading in the channe
[17:43] <skaet> l.   I haven't gone through and read the code though - so if I've gotten something wrong about the dynamic that's happening - please point me at the code bits inquestion.
[17:44] <nessita> skaet: the piece of code that does the lib loading is this https://github.com/ghtdak/qtreactor/blob/master/qt4reactor.py#L44
[17:44] <nessita> skaet: is a  python import inside a try-except block, and if the GPL lib (pyqt4) is not installed, it will try with pyside, which is a LGPL lib
[17:45]  * skaet looking
[17:47] <nessita> skaet: did you ask the legal guys? (I'm asking so I don't go a ping them again about the same :-))
[17:49] <skaet> nessita,  yup thats who I was looking for input from yesterday.
[17:54] <skaet> nessita,  it was informal discussion with a couple of lawyer friends though,   so if you have concerns and want to follow up,  no problems.
[17:54] <nessita> skaet: ok, I will do that, thanks
[18:02] <cjwatson> I think it's reasonably standard to say that if a piece of code can get by with any of multiple implementations under various licences, then your code isn't a derived work of any particular one of those implementations
[18:03]  * skaet nods
[18:03] <cjwatson> worst case the work as a whole is GPL; that does not affect the licensing of the MIT portion of the code
[18:03] <cjwatson> (I'm coming into this conversation half-way)
[18:03] <cjwatson> is this MIT code used by GPL-incompatible things?
[18:06] <cjwatson> nessita: ^-
[18:06] <nessita> cjwatson: hello there!
[18:07] <nessita> cjwatson: so far no, we use it inside the Ubuntu One QT desktop apps which all are GPL v3
[18:07] <mdeslaur> cjwatson: it's twisted (MIT) that uses qt4reactor (MIT) that uses pyqt (GPL)
[18:07] <cjwatson> then there is unambiguously no problem
[18:07] <cjwatson> the people who talk about the GPL being viral and forcing you to write GPL code as well are lying
[18:08] <cjwatson> all you need is for it to be possible to distribute the work as a whole under the terms of the GPL
[18:08] <nessita> mdeslaur: actually twisted does not use qt4reactor, but is a tiny detail. Our Ubuntu One apps use the qt4reactor (MIT) which uses twisted (MIT) and pyqt4 (GPL)
[18:08] <mdeslaur> cjwatson: so stuff in the archive can possibly be GPL incompatible and still use twisted?
[18:09] <cjwatson> that's more questionable
[18:09] <cjwatson> it depends on whether you think that we're distributing a work as a whole by distributing it such that it uses pyqt by default
[18:10] <cjwatson> perhaps we might need to arrange that there's never a situation where GPL-incompatible code that uses twisted ends up using pyqt, for example; that's probably a check-with-a-lawyer situation
[18:11] <cjwatson> but it's absolutely fine for MIT code to use GPL code, it just means that you need to comply with the union of all the applicable licence terms when modifying/distributing the whole thing
[18:12] <cjwatson> there is a wrinkle in that the debian/copyright file for python-qt4 is a bit confusing
[18:12] <cjwatson> it says:
[18:12] <nessita> cjwatson: what about when packaging the MIT code that list as requires the GPL code?
[18:12] <cjwatson>   This program is free software; you can redistribute it and/or modify
[18:12] <cjwatson>   it under the terms of the GNU General Public License as published by
[18:12] <cjwatson>   the Free Software Foundation; either version 2 of the License.
[18:12] <cjwatson> however http://www.riverbankcomputing.co.uk/software/pyqt/intro says "GPL (v2 and v3)"
[18:12] <cjwatson> (GPLv2-only software isn't compatible with GPLv3 so that was worth checking)
[18:13] <cjwatson> nessita: nothing wrong with that.  The GPL doesn't compel the twisted developers to licence their code differently; it merely means that you must comply with the GPL when doing things with the GPL part
[18:13] <cjwatson> nessita: but since you can comply with the MIT licence and the GPL at the same time, that's OK
[18:15]  * skaet nods
[18:15] <mdeslaur> so, looks like it's fine then
[18:16] <cjwatson> in any case, pyqt comes with a GPL exception that specifically says it's OK to use pyqt with a bunch of other licences
[18:16] <cjwatson> GPL_EXCEPTION.TXT in the source package
[18:16] <cjwatson> this specifically lists the MIT licence, so even if there were any doubt (which I don't think there is), that would cover it
[18:16] <mdeslaur> ah! nice
[18:18] <scott-work> cjwatson:  is this a convenient time for a brief discussion on a "libavcodec-extra-53 conflicts with libavcodec53" problem with ubuntu studio?
[18:18] <cjwatson> scott-work: the precedent there is that ubuntustudio should be using libavcodec-extra-53 consistently throughout
[18:19] <cjwatson> the point of the ffmpeg-common seed was to force that
[18:19] <scott-work> i remember we made a change during natty and i reviewed the precise seeds and it appears to be inline for precise (hence my searching for you)
[18:20] <scott-work> i reviewed http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise/files against the changes for https://bugs.launchpad.net/ubuntu/+source/ffmpeg-extra/+bug/685049
[18:20] <ubot4> Launchpad bug 685049 in ffmpeg-extra (Ubuntu) (and 1 other project) "libavutil-extra-50 & libavcodec-extra-52 conflicts cause ubuntustudio natty alpha1 iso install to fail (affects: 1)" [Undecided,New]
[18:21] <scott-work> aw, jeez, i think i see the problem...missing destkop-common
[18:22] <cjwatson> are you sure that bug isn't simply closable?
[18:22] <mdeslaur> cjwatson: thanks for the details on the licensing issue
[18:22] <cjwatson> libavcodec isn't in the dependency-expansion of ubuntustudio.precise/desktop-common
[18:23] <cjwatson> ah, it shows up in graphics, I see
[18:23] <scott-work> cjwatson: yes, the old bug is probably closable, but the the precise dailies and alpha1 (apparently) have been reporting ""libavcodec-extra-53 conflicts with libavcodec53""
[18:24] <cjwatson> scott-work: right, I have a fix - is there a bug number?
[18:24] <scott-work> cjwatson: there is not at this point but i am happy to make one
[18:24] <scott-work> shall i make one?
[18:25] <scott-work> and can you explain the problem?
[18:25]  * scott-work thinks he understands the problem in natty with forcing to choose the -extra packages based on desktop-common and ffmpeg-common
[18:25] <cjwatson> no need to file one
[18:27] <cjwatson> when germinate processes the graphics seed, it encounters something that depends on libavcodec53.  given the context it's operating in, it doesn't realise that it's supposed to choose libavcodec-extra53 for compatibility with other ubuntustudio bits.
[18:27] <scott-work> i am hoping to better understand the problem because i speculate that i could have prepared fix to be checked and pushed to repos rather than bothering you for this
[18:27] <cjwatson> the fix is to tell it that the graphics seed (and audio-plugins, for good measure) inherits from ffmpeg-common, whose purpose is to force the -extra variants to be selected
[18:27] <cjwatson> I've committed a seed change for that
[18:28] <cjwatson> don't feel too bad about not getting this, since to some extent it is dark wizardry
[18:28] <scott-work> hehe, i can see that ;)
[18:29] <cjwatson> not that that should prevent you from trying to understand it, just that it's not something widely understood right now
[18:29] <scott-work> so you just added ffmpeg-common or desktop-common to the other seeds (graphics and audio-pluins) for this fix
[18:29] <cjwatson> ffmpeg-common, not desktop-common (which wouldn't have helped)
[18:29] <scott-work> aye
[18:29] <cjwatson> http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise/revision/1279
[18:29] <cjwatson> that should sort things out, but let me know if it doesn't
[18:29] <scott-work> i presume this resulted in further changes in the seeds during precise, which explain why the fix during natty worked and oneiric but now yields a problem
[18:30] <scott-work> thnak you very much cjwatson :)
[18:30]  * cjwatson looks into the cause
[18:31] <cjwatson> it happened because https://launchpad.net/ubuntu/+source/gimp-gap/2.6.0+dfsg-2 changed gimp-gap to start recommending mplayer rather than merely suggesting it
[18:31] <cjwatson> which caused mplayer (which depends: libavcodec53 | libavcodec-extra-53) to be pulled into the dependency-expansion of the ubuntustudio graphics seed
[18:32] <scott-work> it's a complicated web
[18:32] <scott-work> thank you again
[18:56] <ogasawara> skaet: just want to confirm that we still email out our weekly team status, but there won't be an actual meeting tomorrow?
[18:57] <skaet> ogasawara, yes.  I'll send out a note to ubuntu-release to make it explicit and remove the meeting from the calendar.
[18:58] <Daviey> That works well, as i wasn't sure i could attend. :)
[18:58] <Daviey> Should we be sending status updates to the list for this week, still?
[19:03] <scott-work> doh, and i was being all super aggressvie getting my email sent out on time :P
[19:12] <skaet> Daviey,  scott-work,  yes please send status out to the list,   if there's anything critical showing up,  adhoc meeting will be called on monday,.  :)
[19:12]  * skaet adding her bits to the agenda page,  so status for overall release is captured there right now
[19:14] <jdstrand> skaet: where is the raw data for http://status.ubuntu.com/ubuntu-precise/ stored? eg, where is the data for http://status.ubuntu.com/ubuntu-precise/canonical-security.html?
[19:37] <skaet> jdstrand,  I'm not sure which server the raw data is residing on these days,  I know we had some problems with it in oneiric.  pitti or cjohnston will know.   If you want to tweak the tend baseline, or something similar it can be done through a change to http://bazaar.launchpad.net/~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config/view/head:/config/ubuntu-precise.cfg
[19:37] <jdstrand> skaet: I'm curious in the data, for my own reporting needs. pitti ^
[19:44] <skaet> jdstrand,  data's on cranberry these days (just heard back from cjohnston)
[20:16] <jdstrand> skaet: thanks!