[06:13] newz2000: are you ignoring me? :P [06:50] MTecknology, no, i'm ignoring him. [06:50] ermm.. ;) [06:50] hi hi [06:51] you ignore me, knome ? :'( [06:51] morning SiDi! [06:51] nope. i ignore nobody. [06:51] and why do you ignore him ? [06:51] that was a joke. [06:51] I have one ignore - 0:51 1 root: MSGS [06:52] i have ignores as well, but they are only ignores for different types of messages in channels [06:52] eg. joins and parts in boring channels ;P [06:52] like ermmmm... #ubuntu-website :P [06:53] that's pretty much what mine is for too [06:53] bitlbee [06:53] mine ignores any message [06:53] /ignore * [06:53] yes, i'm ignoring both of you right now ! [06:55] stop ignoring me Q.Q [06:55] MTecknology, i have an irssi script that makes the bitlbee root messages more readable (and also so short that they fit a normal terminal window) and modifies their type so that they don't create "activity" [06:56] nice [06:56] I'll have to grab it sometime :P [06:56] irss.org? [06:56] http://blog.knome.fi/files/2007/02/fixbbpl.txt [06:56] nope, only private use ;) [06:57] it might be a bit crappy code, but hey, it works. [06:57] I'll try it out sometime, thanks [06:58] np. [06:58] * MTecknology goes back to coding svg and all the annoying they come with [06:58] oh wow, that email is outdated [06:58] i don't even have access to it anymore [14:43] MTecknology: not ignore you, are you trying to reach me? [19:35] newz2000: regarding that tarball I sent you a while ago :) [19:35] oh, no, not ignoring you per se [19:36] but I am consistently failing to reply [19:36] I was just curious if you ever got around to look at it :P [19:36] then I was going to ask what you thought [19:37] I did look at it and I'm still not sure what I'm looking at. I'm not sure what problem it solves and I don't understand the solution. [19:37] let me open the tarball again, just a min [19:38] You're familiar with Drupal. Do you have your own drupal site? [19:38] yes [19:38] It's just text files for each banner option. [19:38] each text file contains a reference to the js file (a script tag) [19:39] I'd prefer it if instead I were able to just grab a tarball of the entire thing, but because you guys control the minute the banner switches to showing as released, it's not really possible [19:41] The project is lp:drupal-ubuntu-countdown [19:41] a tarball of the entire "what"? [19:42] all the images and everything needed so there's no need for your servers to get hammered [19:43] a tarball of the images is certainly possible [19:43] the only thing that gets tricky is to know when the image "it's here" should show [19:43] that's what I was referring to [19:44] but currently what I do is modify the js file [19:44] it's not a big deal to modify something else so that your script can detect the change [19:44] you may have noticed that the js doesn't appear to change for an hour or two after release... [19:45] this is because of our caching rules changing [19:45] ya, I did actually [19:45] You could log into the website and clear cache [19:45] this trigger we're referring to would suffer the same problem [19:45] we do that [19:45] oh [19:45] well, wait [19:46] we modify the servers in the day or days before release to prevent shift+reload from working [19:46] the caches basically get a static copy of the site [19:46] then we release the caches for a moment when it's time to release [19:46] and then again shortly after release [19:47] it's this second tiem that the js and banners change [19:47] might be 15 min after or 2 hours after, but right in there [19:47] anyway, your trigger script that detects the change would be subject to the same delay [19:47] it's really not a big deal [19:47] but if all you want is a trigger we can do it [19:48] would you be willing to host a tarball for it as well? [19:48] I don't have the bandwidth to offer for that sort of thing? I get 50mb up but my bandwidth/month is pretty low [19:48] well, we host it on the wiki currently [19:48] where? [19:49] wiki.ubuntu.com/Website [19:49] there's a page for the countdown banners and we put it there somewhere [19:49] what is the purpose of the tarball, is it somehting your script will automatically grab? If so we should not host it on the wiki [19:49] ya, that's it purpose [19:50] so instead we should create a ppa or something similar [19:50] otherwise someone could stuff the tarball with nasty php or something [19:50] or we could just agree on a naming scheme for the files [19:50] and host them on ubuntu.com [19:51] what we should do is hold off for just a bit [19:51] hrm... how hard would it be to pull a ppa w/ php? [19:51] probably hard. :-) [19:51] I'm working on a solution to host static content [19:51] for ubuntu.com and the related websites [19:51] I'm hoping to have some progress soon [19:51] alrighty [19:51] it would be the ideal place for this stuff [19:52] I'll look into the ppa as well, just since that sounds like it could be a fun idea [19:52] sure [19:52] we could probably put a redirect in place on ubuntu.com that points to the final location of the files [19:52] it would only change once each release around the beta period [19:54] You should take a peek at the source code sometime, or try out the module :) - I think I did pretty decent work on it [19:54] Everything I'm producing I'm going to try to port to D5 when it's all done [19:55] ok, I will [19:55] I'll wait a week or two before I poke you again :) [19:55] or more if you prefer... somehow I get the feeling you're a busy person :P [19:56] well, there's always more to do than I can do, so it just comes down to priorities [19:56] this will probably increase in priority as it nears time to release banners again [19:57] holy crap... [19:57] why ppa... [19:57] yeah, bad idea [19:57] that's just for debs [19:57] but no reason we can't do something like https://edge.launchpad.net/ubuntu-drupal-releases/6.x/6.3.2 [19:58] We could use a redirect on ubuntu.com to point at w/e [20:00] what's your opinion on that? [20:00] I think we can do better [20:01] you don't like the launchpad idea? [20:01] wait, is this to a .deb file or can we host any file there? [20:01] oh, any file [20:01] yes, that's good [20:01] yup [20:01] sure [20:01] http://edge.launchpad.net/ubuntu-drupal-releases/6.x/6.3.2/+download/ubuntu-drupal.tgz [20:03] It's look something like http://launchpad.net/drupal-ubuntu-countdown/head/jaunty/+download/jaunty-banners.tgz [20:04] not only that, but then I can have my group keep owning the code, but I can also add you ~ubuntu-website as maintainers so if I randomly die then you guys can keep it up to date [20:05] You think that's a good idea then? Or do you still want to look for better? [20:06] that'll work [20:06] we might still want a file the javascript can scan to see if it's been released or not [20:09] I can easily make it so if the pointer is pointing at the same location as before then it won't pull new cache too [20:11] newz2000: is there any way you could send me a tarball of all the images and everything else for the current release? [20:11] they're on that wiki page [20:11] that's the best place to get them [20:16] I love launchpad bugs.... [20:17] newz2000: Any chance you could make a pointer that points here? http://edge.launchpad.net/drupal-ubuntu-countdown/banners/jaunty/+download/countdown.tgz [20:18] I know it'll sit there because I just created it :P [20:23] MTecknology: I'd rather not [20:23] the reason is because I want to make sure we have a solid qa process before we put a redirect in from ubuntu.com [20:24] good point [20:25] what is one redirect that you have setup? [20:25] MTecknology: what do you mean? [20:26] Do you have any redirects currently? [20:26] I just wanted to see what curl showed me about them [20:26] ok, sure [20:26] let me find one [20:27] http://www.ubuntu.com/cloud [20:29] interesting [20:31] So I'll probably pull the redirect and see if it points at a new location fromt eh one saved in the db and if it is different then pull a new copy [20:31] Thanks :D