[01:09] <RainCT> Uhm.. In a package version like X-Y+Z, what is Z?
[01:11] <RainCT> ah, used for security updates?
[01:26] <directhex> RainCT, used for any situation where you want to increment X-Y without going all the way to X-(Y+1)
[01:26] <directhex> in theory, anyway
[01:56] <desrt> is it possible to have karmic and jaunty-targeted versions of a package (of the same name) in one PPA?
[01:56] <desrt> or should i make a second ppa?
[01:57] <LaserJock> you can have them in the same PPA
[01:57] <desrt> how do i arrange for it to happen?
[01:57] <LaserJock> in your changes file you should set the release you want
[01:58] <desrt> fascinating
[01:58] <desrt> and i can just dput multiple separate ones and it will all be OK?
[01:58] <LaserJock> bah, changelog I meant
[01:58] <LaserJock> the only thing is you can't upload the same version multiple times
[01:59] <LaserJock> so you can either 1) build for one release and then copy the binary using Launchpad's UI or 2) use different versions for each target, like ~jaunty1 and ~karmic1
[02:00] <LaserJock> I'm a bit rusty though, maybe there's a better way out there that I don't know about
[02:14] <mgunes> Good day all.
[02:14] <mgunes> Is it a good idea to turn a needs-packaging bug for a package that has landed in Sid after Debian import freeze into a sync request and subscribe u-u-s?
[02:15] <LaserJock> wouldn't MOTU Release need to approve a FFe?
[02:26] <ScottK> mgunes: Not unless it's really important for some reason (like a package we already have in the archive won't build without it).
[02:26] <moldy> hi
[02:26] <ScottK> LaserJock is right about the FFe being needed now.
[02:27] <ScottK> hi moldy
[02:27] <moldy> do i understand this correctly: when i create a non-native package, i cannot have dashes in the upstream version?
[02:28] <LaserJock> I believe that's correct as the dash is the separator between upstream version and debian revision
[02:28] <mgunes> ScottK, thanks; I was actually wondering how it would have worked before FF. Should have worded better.
[02:28] <moldy> LaserJock: ok, that sucks :(
[02:28] <moldy> LaserJock: python's setuptools seems to use dashes now by default...
[02:28] <LaserJock> that's unfortunate
[02:29] <moldy> hm or no, wait, the error message actually does not say what i thought it did
[02:29] <moldy> ok, let me rephrase my question: how do i create a native/non-native package?
[02:29] <LaserJock> mgunes: if it was prior to Debian Import Freeze you could just wait for it to be automatically synced
[02:29] <ScottK> mgunes: Before Debian Import Freeze they come in automatically, so no bug is required.  Between DIF and FF, packages can be asked for manually, but you shouldn't just ask for them all.
[02:29] <LaserJock> what ScottK said ;-)
[02:30] <LaserJock> moldy: to create a non-native package you want to have the upstream tarbal as <package>_<upstream version>.orig.tar.gz
[02:30] <LaserJock> *tarball
[02:32] <moldy> LaserJock: that would be easy, but the paths *inside* the org.tar.gz also use the - ...
[02:32] <mgunes> What I was wondering, precisely, was whether it's OK to turn a needs-packaging bug from a past cycle into a sync request between DIF and FF. An example is bug #176548.
[02:33] <moldy> LaserJock: ah, never mind... those paths don't matter actually
[02:34] <moldy> ok, then it's not as bad as i thought it was :) thanks for your help
[02:34] <JontheEchidna> personally I'd just file a new bug for the sync and then mark the needs-packaging as a dupe. It's less confusing for the archive admin that way
[03:11] <arand> Is the syntax for dput different in intrepid compared to jaunty? dput ppa:arand/ppa file_source.changes don't work, but does in jaunty.
[03:17] <ScottK> Should be the same, but PPA does have some pecularities.  You might ask in #launchpad.
[03:18] <lamalex> conf issue?
[03:18] <LaserJock> arand: you're running dput from intrepid?
[03:20] <micahg> it seems like there are some config changes in teh changelog for dput for jaunty
[03:22] <arand> LaserJock: yes, it seems like only using "ppa" instead of "ppa:arand/ppa" will make it upload... to where I have no clue though...
[03:24] <lamalex> you should define that in ~/.dput.conf
[03:24] <LaserJock> yeah, the ppa: syntax was not supported prior to Jaunty
[03:25] <lamalex> i didn't know that was possible, good to know
[03:26] <arand> aha, so I should add ppa.launchpad.net/arand/ppa to the config file? (is there a way to do this in the command itself without mucking with the config?
[03:29] <LaserJock> arand: I don't think so, I think that's why the ppa: syntax was added
[03:32]  * ScottK stares at http://qa.ubuntuwire.com/ftbfs/karmic.html and wonders why people aren't busier.
[03:41] <ScottK> If anyone wants to take a stab at fixing FTBFS, I'll be glad to provide assitance and advice.
[03:43] <artfwo> ScottK, could you take a look at http://wiki.debian.org/ArmEabiFixes#qreal.28qMin.2CqMax.2CQt.29 ?
[03:43] <artfwo> is there any other way without using static_cast?
[03:43] <ScottK> artfwo: I'll look, but the armel qreal stuff is generally beyond me.
[03:44] <ScottK> artfwo: NCommander is the guy you want to look at that.
[03:44] <ScottK> He's who I ask on that stuff.
[03:44] <artfwo> I've got a picky FTBFS due to this type mismatch
[03:44]  * ScottK looks around for an easier one.
[03:45] <LaserJock> ScottK: what does "Failed to upload" mean?
[03:46] <ScottK> It means it got built, but didn't upload to the archive.  The most common reason is a newer source was published before that build finished.  Others are likely bugs in LP.  Sometimes retries help (soyuz is, I hear, a mess of interrelated scripts that aren't very deterministic)
[03:49] <arand> Hmm, I managed to dput something into ppa.launchpad.net with nothing else defined, is that anything to worry about, or do I jus force the upload to my own ppa (since it complains about it already being uploaded)?
[03:50] <ScottK> arand: rm the .upload file and try again.
[03:51] <arand> ScottK: Ah, that simple...
[03:53] <arand> Done. ScottK: LaserJock: lamalex: Many thanks for your help.
[03:54] <lamalex> there's a dput flag you can use to put if a .upload file exists also
[03:54] <lamalex> but removing the .upload works just as well
[03:55] <hyperair> -f
[03:56] <arand> Right, I though the complaint was based on the server rather than local data, hence my precaution.
[04:32] <NCommander> artfwo, you need to either cast the variable down or up
[04:33] <artfwo> NCommander, just replace foo with double(foo)?
[04:33] <ScottK> NCommander: Did you see my ping on KDE 4.3.1 with armel?
[04:33] <NCommander> arand, that can work
[04:33] <NCommander> er, artfwo
[04:33] <NCommander> ScottK, no
[04:34] <ScottK> NCommander: sebas helped me out and we are all built now.  Got netbook livd CD images for armel and everything.
[04:34] <artfwo> okay, will try
[04:34] <NCommander> ScottK, nice
[04:34] <ScottK> NCommander: He pushed the fixes to kdesvn too.
[04:34] <NCommander> :-)
[05:25] <quentusrex> Anyone know why reprepro would only hav econtrib main and non-free directories? when in the ./conf/distributions file has the components: main restricted universe multiverse?
[05:25] <quentusrex> and I can't seem to get it add the last three components, only main...
[05:41] <porthose> ScottK, I was looking at pysvn, it is listed on qa.ubuntuwire.com as a FTBFS, it builds locally just fine, and it also builds in my ppa http://launchpadlibrarian.net/31520921/buildlog_ubuntu-karmic-i386.pysvn_1.7.0-1ubuntu1%7Ekarmicppa1_FULLYBUILT.txt.gz
[05:41] <porthose> is there anything else that needs to be done to this?
[05:51] <ScottK> porthose: I'll give it a retry then.
[05:53] <ScottK> porthose: https://launchpad.net/ubuntu/+source/pysvn/1.7.0-1ubuntu1/+build/1194723
[05:53] <ScottK> If that works, ping me and I'll retry the rest tomorrow.  If not, install pgkbinarymangler in your pbuilder or ppa and see what happens.
[06:02] <porthose> ScottK, ok :)
[06:06] <fabrice_sp> porthose, just in case youy dind't saw it: it FTBFS
[06:06] <porthose> fabrice_sp, yes just noticed that :(
[06:07] <fabrice_sp> it seems that you're missing the --install-layout=deb in the setup.py call
[06:07] <fabrice_sp> (this is the most common root cause of this error)
[06:09]  * porthose goes and looks
[06:24] <fabrice_sp> Can somebody unsubscribe u-u-s from bug #283213?
[06:58] <dholbach> good morning
[07:00] <fabrice_sp> Hey dholbach ! Good morning
[07:00] <dholbach> hiya fabrice_sp
[07:07] <fabrice_sp> by the way, dholbach: https://wiki.ubuntu.com/FabriceCoutadeur/MOTUApplication
[07:08] <fabrice_sp> :-)
[07:10] <dholbach> woohooo
[07:10] <dholbach> :-)))
[07:20] <fabrice_sp> have to go. Bye
[08:05] <porthose> HA, got pysvn to build, I'll file a bug with diff tomorrow it's getting late and time for bed :)
[08:29] <kaushal> hi
[08:29] <kaushal> I am faced with the problem as described here http://paste.ubuntu.com/267433/
[08:46] <porthose> Does MOTU-Release need to ack a FTBFS fix?  The only changes made where to rules, control, and changelog
[08:52] <randomaction> no
[08:52] <porthose> randomaction, thx
[09:01] <porthose> Would a kind MOTU please have a look at bug #426677.  Ok *now* it's time for bed
[09:24] <slytherin> Does anyone know the reason why metacity would show borderless windows?
[09:27] <geser> is metacity running?
[09:27] <geser> I usually see borderless windows when metacity is not running (or any other window manager)
[09:29] <slytherin> geser: I am trying to take screnshots inside pbuilder chroot. I am using xvfb for that. I have metacity as build dep I assumed it must be running automatically.
[09:30] <slytherin> geser: Oh, wait. The code that takes screenshots also launches metacity.
[09:30] <slytherin> And the same problem is observed even with other WMs like xfwm4, fluxbox.
[09:55] <christoph_debian> it's probably quite obvious but whats wrong there -> 'ubuntutools.lp.udtexceptions.SeriesNotFoundException: Error: Unknown Ubuntu release: 'karmic'.'
[10:00] <geser> hmm
[10:01] <geser> does it happen again? it looks like edge has currently some issues again
[10:02] <christoph_debian> geser: nope it's fine this time
[10:03] <christoph_debian> ok sync request on the way
[10:35] <slytherin> geser: Any other idea about reason for borderless windows?
[10:41] <Q-FUNK> cat /etc/issue | awk '{print $1}'
[10:41] <Q-FUNK> howdy!  what could be used to eliminate white space in the above command's output?
[10:43] <Laney> Q-FUNK: tr -d?
[10:43] <Laney> awk is probably clever enough to do it but I am not clever enough to work awk
[10:44] <Q-FUNK> :)
[10:46] <Q-FUNK> right, tr might work, but it requires defining exactly what we're looking for e.g. space, tab, etc.
[10:48] <Q-FUNK> tr -d [:space:]
[10:49] <soren> Q-FUNK: awk '/./ {print $1}'
[10:49] <soren> Q-FUNK: (/./ makes it only handle non-empty lines)
[10:52] <Q-FUNK> ah, good to know
[10:52] <Q-FUNK> thanks! :)
[11:07] <DktrKranz> mok0: could you please look at bug #421825?
[11:07] <toabctl> hi all
[11:08] <toabctl> i try to cross-compile the kernel with: ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnu- make -j4 zImage
[11:08] <toabctl> /usr/bin/arm-linux-gnu-ld: no machine record defined
[11:08] <toabctl> /usr/bin/arm-linux-gnu-ld: no machine record defined
[11:08] <toabctl> make: *** [.tmp_vmlinux1] Fehler 1
[11:08] <toabctl> ^^ that is the error: can anybody help?
[11:08] <Laney> #ubuntu-kernel is probably better
[11:18] <mok0> DktrKranz: looking...
[11:18] <funkyHat> Weird, I just had a patch for brasero sponsored (just adding a dependancy), and I had an email from<EMAIL_ADDRESS>telling me I uploaded a translation template!
[11:18] <funkyHat> Is that normal? :)
[11:19] <mok0> DktrKranz: yes :-(
[11:19] <mok0> DktrKranz: big mistake on my part
[11:21] <dpm> funkyHat: you might want to ask at #launchpad if you don't get an answer here
[11:21] <geser> funkyHat: that's normal for package in main
[11:22] <funkyHat> geser: ok :)
[12:49] <DktrKranz> mok0: it will probably become syncing material, but please let's keep it on the radar for karmic.
[12:49] <mok0> DktrKranz: I a working on a down-grade
[12:50] <mok0> DktrKranz: there's a regression too
[12:50]  * mok0 kicks self
[13:34] <christoph_debian> hm -- https://launchpad.net/ubuntu/+source/micropolis-activity/0.0.20071228-3/+build/1209922 -- what's going wrong there?
[13:40] <DktrKranz> christoph_debian: http://launchpadlibrarian.net/31536021/upload_1209922_log.txt
[13:40] <DktrKranz> 2009-09-09 12:18:36 ERROR   Unhandled exception processing upload -> http://launchpadlibrarian.net/31536018/rdGkZnCNfI7aiF5hqHGAfYtaCHz.txt (The email address<EMAIL_ADDRESS>is already registered.)
[13:41] <christoph_debian> jep I got that via mail
[13:46] <blackxored> hello
[13:47] <geser> christoph_debian: know bug, let me find the bug number
[13:47] <christoph_debian> geser: the important thing is, can I just ignore it?
[13:48] <geser> christoph_debian: bug 408528
[13:48] <geser> you can ignore it but then the package doesn't get into the archive
[13:49] <christoph_debian> and what do I do to get it in?
[13:50] <geser> a work around is to do a no-change -Xbuild1 upload
[13:51] <christoph_debian> geser: from someone with upload rights?
[13:51] <ScottK> Yes
[13:52] <christoph_debian> ok so *I* can't do anything
[13:52] <ScottK> christoph_debian: What package?
[13:52] <ScottK> Oh.  I see it
[13:53] <ScottK> Seems odd it would only fail on one arch
[13:53] <ScottK> geser: I think we should retry the one arch first.
[13:54]  * ScottK does
[13:55] <christoph_debian> ScottK: it failed on lots of arches
[13:56] <christoph_debian> just took i386 as example
[13:56]  * ScottK looks again
[13:56] <ScottK> christoph_debian: https://launchpad.net/ubuntu/karmic/+source/micropolis-activity/0.0.20071228-2 says different
[13:57] <ScottK> christoph_debian: I was on the wrong release. Sorry
[13:57] <christoph_debian> right mips is not among the failed
[13:57] <geser> ScottK: -3 is recent not -2
[13:57] <geser> ScottK: https://edge.launchpad.net/ubuntu/+source/micropolis-activity/0.0.20071228-3
[13:57] <christoph_debian> but I have lpia amd64 powerpc armel ...
[13:57] <ScottK> Yes, just realised.
[13:58] <geser> the https://edge.launchpad.net/ubuntu/+source/micropolis-activity page doesn't list the -3 yet (for whatever reason)
[14:00] <ScottK> I'll do the upload, unless you want to geser.
[14:01] <geser> if you have it already ready, then go
[14:02] <ScottK> Just test building.
[14:02] <ScottK> Then I'll upload.
[14:06] <geser> I'm pretty sure that it will build (else it wouldn't fail during upload)
[14:08] <ScottK> Yes, but I'm cautious.
[14:08] <ScottK> geser and christoph_debian: Uploaded.
[14:08] <ScottK> christoph_debian: Thanks for letting us know about it.
[14:11] <blackxored> hello folks
[14:11] <blackxored> there's a way to get rid of those statements on debian/rules which only uudecode a binary file???
[14:13] <mok0> blackxored: what do you mean?
[14:14] <blackxored> mok0, please look here: http://git.debian.org/?p=pkg-java/azureus.git;a=blob;f=debian/rules;h=cdd1c025a9a631c39c1b93f53fa38e72cb64eefc;hb=HEAD
[14:14] <ScottK> christoph_debian: It got accepted on one arch, so that should mean it's all good.
[14:14] <blackxored> I want to get rid of the build/azureus:: target
[14:14] <blackxored> what only does it's do decode two png files
[14:14] <mok0> blackxored: are you sure they're not installed?
[14:16] <blackxored> mok0, of course
[14:16] <mok0> blackxored: so they're not mentioned in any other debian/* file?
[14:17] <blackxored> mok0, would you please take the link ;)
[14:17] <mok0> blackxored: I did
[14:17] <mok0> blackxored: but I can't see the other debian/ files
[14:17] <blackxored> mok0, ok, then I tell you: of course, from the install file
[14:18] <blackxored> just hit debian in that page
[14:18] <mok0> blackxored: it they're mentioned in debian/install, then you shouldn't touch it
[14:18] <blackxored> [pkg-java/azureus.git] / debian / rules
[14:18] <blackxored>                                                      ^^^^^
[14:18] <mok0> blackxored: oh yeah, they are installed
[14:18] <blackxored> mok0, so you are following now ;)
[14:19] <mok0> blackxored: I am
[14:19] <blackxored> I want to end my debian/rules in the PATCHES_DIR statement, only variables and includes ;)
[14:19] <blackxored> and I though if there might be some way to auto-decode this files
[14:19] <blackxored> implicitly
[14:19] <mok0> blackxored: you can't do that without screwing up the build
[14:20] <mok0> blackxored: the unpack structure is perfectly legitimate, it's used all over the place
[14:20] <blackxored> mok0, it's hard to wait for 3.0 format :D anyways, mok0 thanks for your time, it was only a wishlist improvement
[14:20] <blackxored> ;)
[14:21] <mok0> blackxored: don't hold your breath while waiting...
[14:21] <blackxored> mok0, ;)
[16:50] <lbrinkma> Hi all,
[16:50] <lbrinkma> I want to get involved with MOTU. I have steped through the documentations on the motu wiki page. Now I don't know what to do next. Can someone please show me an easy to fix bug for me as an beginner?
[16:55] <sistpoty|work> lbrinkma: you could search for bugs tagged as bitesize, as these should be easy ones
[16:57] <lbrinkma> sistpoty|work: thanks. I'll try
[17:04] <the-dude> lbrinkma: or search for typo
[17:07] <lbrinkma> the-dude: as a tag or what?
[17:07] <the-dude> many packages have typo's in it, they can be easyly fixed
[17:08] <lbrinkma> the-dude: ah ok. thanks a lot
[17:09] <sistpoty|work> the-dude: typos are best fixed upstream-wise
[17:10] <lbrinkma> So that down work, right?
[17:10] <randomaction> lbrinkma: See links in Topic (FTBFS, NBS, debcheck), some of those are easy.
[17:12] <the-dude> can someone tell what  -i, --indep set package class to arch-independent does with dh_make ?
[17:14] <blackmoon> hi, for packaging a python application with debhelper (not cdbs), i need to add some extra thing or is the same as a normal application?
[17:19] <lbrinkma> randomaction: Sorry, I don't now what to do on this pages. I'm just beginning to get involved.
[17:20] <the-dude> nm my question I think I already found the awnser
[17:34] <quentusrex> Anyone familiar with reprepro?
[17:35] <christoph_debian> a bit
[17:36] <quentusrex> alright, I'm trying to setup a repo locally on my network.
[17:36] <the-dude> http://www.debian-administration.org/articles/286
[17:36] <quentusrex> I need to be able to upload my own packages,
[17:37] <quentusrex> and mirror packages that were installed by machines on my network.
[17:37] <quentusrex> but I don't want to mirror the whole official repo
[17:39] <quentusrex> I would like to somehow only mirror the packages I need,
[17:39] <quentusrex> but have a list of all packages available...
[17:40] <quentusrex> the-dude: I've already looked at that documentation...
[17:41] <quentusrex> I think I may need to use two repo's for this
[17:42] <quentusrex> one to handle the official packages that are to be proxied.
[17:42] <quentusrex> and one to handle my custom packages.
[17:42] <quentusrex> christoph_debian: the-dude: thoughts?
[17:59] <the-dude> quentusrex: No I just found that article a few hours ago cause I want to start my own repo as well
[18:15] <quentusrex> the-dude: it seems in my case I'll need to combine a couple of services...
[18:16] <quentusrex> one would be a proxy service, either apt-cacher, or approx, or apt-proxy, etc
[18:16] <quentusrex> and the other would be my own custom repo
[18:16] <the-dude> would it be really usefull to use a proxy for your own repo?
[18:17] <quentusrex> no, I want to only have my network machines look to my proxy, rather than download from the internet
[18:18] <quentusrex> this would allow me to download packages once from the internet,
[18:18] <quentusrex> and locally proxy them.
[18:18] <quentusrex> that's the first part.
[18:18] <quentusrex> then the second would be able to add my own packages.
[18:18] <quentusrex> since almost no proxy application will allow for custom packages added to it.
[18:19] <quentusrex> so I split the requirements, proxy everything, so all the machines point to one place, then add my custom repo.
[18:19] <the-dude> does the proxy really care which repo it uses?
[18:36] <quentusrex> nope, and it can use multiple repos
[18:52] <the-dude> then its fine to use a upstream and your local repo
[18:57] <quentusrex> the-dude: yup, that's the plan.
[18:57] <quentusrex> cache and proxy both the upstream, and the local repo
[19:03] <the-dude> are you going 2 use apt-cacher of apt-proxy?
[19:05] <quentusrex> no idea yet...
[19:05] <quentusrex> I'm looking into which is the best proxy to use
[19:05] <quentusrex> so, everything on my network will point to the proxy, which will point to my repo, and remote repo.
[19:05] <quentusrex> so I want to have some control at the proxy leve.
[19:05] <quentusrex> level.
[19:06] <quentusrex> apt-cacher-ng
[19:06] <quentusrex> is another one...
[19:20] <the-dude> quentusrex: use ng where possible
[19:51] <pen1234> http://www.thaiadpoint.com/tap8.1/bin/redir.php?p=2042&l=1357&u_id=363435
[19:54] <pen1234> http://www.thaiadpoint.com/tap8.1/bin/redir.php?p=2042&l=1357&u_id=363435
[19:54] <fabrice_sp> !op
[19:54] <fabrice_sp> spam ^^
[19:54] <slytherin> fabrice_sp: what was that for?
[19:55] <fabrice_sp> the links posted by pen1234
[19:55] <fabrice_sp> it's spam8bot)
[19:55] <slytherin> Oh. At first I thought he was a genuine user.
[20:15] <slytherin> any archive admins here?
[20:16] <ttx> slytherin: o/
[20:18] <and_> jajjaaj
[20:43] <simon-o> Hi, I filed bug 426837. Now I'm not sure who I need to subscribe. ~ubuntu-release or ~ubuntu-main-sponsors?
[20:47] <simon-o> I just read the FreezeExceptionProcess wiki page carefully and from what I understand I must subscribe ubuntu-release and they will set it for confirmed when they approved it. Then the sponsoring takes place. Am I right?
[20:48] <fabrice_sp> simon-o, if it's a bug fixing only version, it's not mandatory to subscribe -release team
[20:48] <fabrice_sp> !info zsh
[20:49] <simon-o> fabrice_sp: yes, it's a bug fix, coming from Debian
[20:49] <simon-o> so the bug is ok, the way it is?
[20:49] <fabrice_sp> karmic has 4.3.10-2ubuntu1 so I would say just ubuntu-main-sponsors
[20:49] <fabrice_sp> let me check
[20:51] <fabrice_sp> seems ok
[20:51] <fabrice_sp> you just have to wait for a sponsor :-)
[20:52] <simon-o> fabrice_sp: thanks :)
[20:53] <fabrice_sp> yw :-)
[22:50] <ScottK> porthose: I see you are taking another stab at pysvn.  Good for you.
[22:53] <porthose> ScottK,  yep would you mind looking at it when you have time :)
[22:53] <ScottK> porthose: Do you have another diff to review?
[22:54] <porthose> ScottK, yes it is on the bug #426677
[22:55]  * ScottK looks
[22:56] <ScottK> porthose: Looks sane at first glance.
[22:57] <porthose> :)
[23:00] <ScottK> Reminder for everyone else: Plenty of stuff to do here: http://qa.ubuntuwire.com/ftbfs/karmic.html#universe
[23:16] <RainCT> ScottK: "Ubuntu MOTU Developers <..>" is officially dead now?
[23:17] <ScottK> RainCT: AFAIK for maintainer, yes.
[23:17] <ScottK> See update-maintainer in karmic
[23:17]  * RainCT didn't know update-maintainer dictates policy :)
[23:21] <ScottK> porthose: Close.  See the bug.
[23:21] <ScottK> RainCT: No, but I'm assuming it didn't get changed randomly.
[23:23] <geser> read the url in the script
[23:23] <geser> the new address was decided in a TB meeting
[23:51] <nicklas_> öj