[00:00] 6 more hours untill i'm officialy 29 :P woot [00:00] lol [00:00] ( localtime ) [00:01] been sitting here playing with my new bday toys ( a 5.1mp digital camera via my mom and a usb card reader from my kido's ) [00:01] :) [00:01] 127.0.0.1:123 [00:02] can't use woot anymore... it's mainstream :( [00:02] whoot! happy bday! [00:03] heh [00:03] imbrandon: young'un [00:04] !nvida [00:04] sorry wrong channel [00:06] Sorry, I don't know anything about nvida - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [00:07] cyberix: February 14 is too late, yes. :) [00:41] anybody happen to know the difference between ${Source-Version} ${source:Version} and ${binary:Version}? cause lintian tells me to use binary:Version, but I can't find docs about the different var ANYWHERE [00:42] mtaylor: ${Source-Version} is deprecated because the name is misleading. ${binary:Version} is what it says; in Ubuntu it's always the same as ${source:Version}, but for Debian compatibility the difference is that ${binary:Version} changes when there's a binNMU and ${source:Version} always refers to the original source version [00:42] the distinction is relevant for dependencies between arch: all and arch: any packages, since arch: all packages aren't rebuilt in a binNMU [00:42] slangasek: AWESOME [00:44] slangasek: you don't happen to know where that's doc'd do you... I looked through the policy and tried googling... [00:45] good question, I have the unfortunate habit of usually being there when the policies are being drafted so never have occasion to look for documentation :/ [00:45] (well, or non-policies in this case, since it's not really in policy) [00:45] hm. sounds like it should be in policy... [00:45] since it is a lintian rule, after all [00:46] Bah, slangasek beat me to it my almost a minute :( [00:46] s/my/by/ [00:46] the current Debian policy czars seem to think very little should be written into policy. :) [00:46] I wasn't going to tell you [00:46] gr [00:47] * mtaylor thinks the detailed policy is one of debian's strong points [00:47] at minimum, it ought to be in the developer's reference, and it's not there either [00:47] One would think it should be. [00:48] I would think there shouldn't be a lintian rule warning me about anything if there isn't a policy to back it up [00:48] else what the hell is lintian anyway ? [00:48] but then, I suppose I'm odd perhaps [00:48] It is policy, it's just not in the policy document. [00:48] hehehe [00:48] NICE [00:49] * mtaylor feels like he'll possibly be tried in a secret court for violating a secret law now... [00:52] oh, well, lintian is a tool that mechanically checks for bugs, and it correctly identifies some uses of ${foo:Version} as buggy; unfortunately, there's a stream of thought that if it's self-evidently a cause of bugs, it doesn't need to be written in Policy :-P [00:52] (but then it should be in the devref, where it also isn't, and the devref isn't maintained via debian-policy, so....) [00:52] ah... I follow [00:52] long story short, you have a valid complaint, and you've touched a nerve with me :-) [00:53] YAY! [00:54] * mtaylor has done his job for the night then [01:20] * persia wonders if there is any sane way to handle bug #177360 (say, something like Debian bug #415287) [01:20] Launchpad bug 177360 in ion3 "ion3 in Gutsy doesn't follow author's License" [High,New] https://launchpad.net/bugs/177360 [01:20] Debian bug 415287 in ion3 "dummy bug; should not be in testing" [Serious,Open] http://bugs.debian.org/415287 [01:22] Nnnnnnggg [01:23] I don't think we can remove packages from Gutsy. [01:23] Well, we can, but we won't. I was more interested in not including it in hardy unless there was an actual stable release. [01:23] in the interest of preserving sanity, cyanide pills are available in the pouch in front of you [01:24] Muaha [01:24] Preserving nothing still leaves nothing [01:24] slangasek: I'm not interested in sanity, but only archive integrity (and understand these are incompatible). Any other suggestions? [01:24] Hah [01:25] so are you asking for a way to mark a package in hardy as "not for release"? [01:25] Can we even do that? [01:25] no [01:25] but I'm asking if that's what he's asking for :) [01:25] slangasek: That would be one way to do it. An alternate would be to pull from hardy in such a way as to resync for hardy+1. [01:25] right, kicking the package out of the dist is the only method that's consistent with the current model [01:26] slangasek: There's actually a bug outstanding for each of those requests. I'm just not sure which of the many workarounds is currently preferred. [01:28] persia: I think it's reasonable to kick the package out under those circumstances; while Debian unstable is something that users run long-term for its own sake, Ubuntu's "development" dist is pretty explicitly a staging ground for the next release [01:29] so not a place to carry stuff that shouldn't be in a release at all due to licensing reasons [01:30] * Hobbsee waves [01:30] * slangasek waves [01:39] slangasek: Thanks. I'll retitle & subscribe the archive admins. === bigon is now known as bigon` [02:15] Heya gang [02:15] Good evening :) [02:15] Hi persia [02:18] * imbrandon waves to all [02:19] Heya imbrandon [02:19] heya bddebian [02:36] lol [02:36] my firefox is taking up 375mb of ram :D [02:36] * joejaxx is an internet power user :D [02:37] I had Transmission taking up 1.4Gb before I closed it [02:37] * Fujitsu 's Epiphany is eating 120, but X is rather suspiciously eating 250. [02:37] joejaxx 834 53.9 36.3 633152 375944 ? Rl Dec17 718:08 /usr/lib/firefox/firefox-bin [02:37] lol [02:38] Fujitsu: That 250 is probably mostly textures [02:38] StevenK: Gecko textures, yes. [02:38] StevenK: 1.4gb lol :P [02:38] And if Gecko crashes, they don't get freed until X is restarted. [02:39] * persia cheers gecko, and points at midori for those who don't agree [03:08] slangasek: that LP bug got fixed. i could still delete before, as deletions don't generate mail anyway, FYI [03:10] * Fujitsu thinks -changes should probably be renamed to -selected-manual-uploads-if-LP-feels-up-to-it [03:10] heh [03:10] hehe [03:10] heh [03:10] It doesn't track -updates migrations, deletions, autosyncs... [03:10] Security notifications are meant to return in 20 minutes, but somebody stuffed up the announcement... [03:11] s/20 minutes/40 minutes ago/ [03:17] Hobbsee: ah, ok [03:19] slangasek: i can accept and reject packages. that's about it [03:20] * slangasek nods [03:22] and i have to poke one of you to work around YALPB whenever i accept a package, too [03:22] which triggers YALPB#2 if done in a particular timeframe. [03:24] The main default? [03:25] And associated upload failure? [03:27] yes [03:47] Interesting. http://www.linuxtoday.com/infrastructure/2007121901026NWDTRL [03:51] Bah. [03:51] If they use proprietary software to do that, this will be exactly what Stallman feared. [03:53] yeah, that's really a compromise which ends any hope of open formats for DVDs/media [03:58] hey folks, if anyone is feeling up for a revu: http://revu.tauware.de/details.py?package=ical2sqlite [03:58] awesome [03:58] I got random e-mail [03:59] through extensive googling, some guy writing a paper has determined I am the person most familiar with Ubuntu Linux's security posture [03:59] What the hell gave him that impression? [03:59] Oh well, everything he lists is stuff I'm familiar with so okay. [03:59] You've written all the security specs. [03:59] rofl [03:59] PITTI is probably most familiar with Ubuntu's security posture [04:00] or Kees Cook [04:09] LucidFox, Hi, See this: http://psxim.googlecode.com/ :) [04:10] LucidFox, what do you think? is there anything missing? [04:11] so i want to update the libtorrent/rtorrent packages in gutsy, i see they are maintained by MOTU but they haven't been updated in a long time. is there someone that could go through the process with me so i can get the hang of packaging? [04:11] i've read through several of the packaging docs on the wiki, etc but there are so many different ways of doing that i'm a bit confused about the best way to tackle a package [04:12] bderrly_: The best way to update a package is to keep the same packaging style. [04:13] makes sense [04:15] * Fujitsu saw something on Planet Debian recently about those new versions. [04:16] Fujitsu, yah, i talked with the guy that packages them for debian, but i want to get them in ubuntu [04:16] no one has updated those packages for ubuntu since april i htink [04:16] even though debian has updated several times since then [04:16] Those actions are largely the same. [04:16] !info rtorrent hardy [04:16] rtorrent: ncurses BitTorrent client based on LibTorrent. In component universe, is extra. Version 0.7.8-1 (hardy), package size 351 kB, installed size 948 kB [04:17] We take almost all of our package from Debian. [04:18] but who does that and when? [04:18] Fujitsu, are you a motu? [04:18] I am. [04:18] bderrly_: The set of all package contributors for packages with ubuntu versions, and the automated script run by the archive-admins at the beginning of each development cycle. [04:19] bderrly_: It is largely automatic until last week. [04:19] Fujitsu, I need a favor, I have written a python and it now needs packaging and you know that's not easy, could you make the deb for me? the program's home is here: http://psxim.googlecode.com/ [04:20] Fujitsu, a python program* [04:20] Fujitsu, it's only one file [04:20] * Fujitsu notes that there are more capable MOTU around, that he doesn't like writing new packages, and that he is a little busy at the moment. [04:20] verb3k: As I told you before, if you want someone else to package it, you should file a needs-packaging bug. If you don't want it in universe, this isn't the right place to ask. [04:21] persia, didn't know that packaging is so hard like that :) [04:21] hi folks [04:22] Fujitsu, so how do i get these packages updated in gutsy? [04:22] bderrly_: We're not Gentoo. YOu could try backports, though. [04:22] !backports | bderrly_ [04:22] bderrly_: If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging [04:23] bderrly_, you may wanna work on getting them updated for hardy [04:23] * Fujitsu wonders if s/they go/they can go/ might be a good idea. [04:23] * persia seconds Fujitsu [04:23] Err. Or maybe "may"? [04:24] I think either should be acceptable. [04:24] You have bot powers now, don't you? [04:26] Fujitsu: I may be an editor, but that's like saying I'm licensed to fly intergalactic craft: it doesn't help me actually do anything. [04:26] (the distinction being I could probably read something in the former case, but don't know what) [04:27] * Fujitsu isn't sure of the command to run regexps over a factoid, but does know how to set them. [04:27] verb3k: i think 23 minutes after release is a bit early to be asking for a package [04:28] Fujitsu: My problem is that ubotu doesn't believe I'm me. Trying to convince it I'm real again now. If this works, maybe I can do something. If not, we can submit to the moderation queue. [04:28] pwnguin: The release was only to support packaging. [04:28] interesting [04:28] Ah. [04:28] what's the bot problem? [04:29] Hobbsee: I don't know how to wrangle, and !backports needs an extra "can" or "may". [04:29] * persia is trying to learn now... [04:29] ubotu: backports is ~s/they go/they can go/ [04:29] But backports already means something else! [04:29] !no backports is If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging [04:29] I'll remember that Hobbsee [04:30] Danke. [04:30] i dont' remember the regexpisms. [04:30] pwnguin, It was released long ago and tested , I just made a hoepage for the project becasue a MOTU said do that before you buidl your package [04:30] i think there's documentation on it somewhere, though [04:30] What is "!no"? [04:30] build* [04:31] persia: Overwriting an existing factoid. [04:31] Ah. [04:31] One would normally do `!newfactoid is whatever', but that will fail if it exists, as Hobbsee adeptly demonstrated. [04:31] pwnguin, besides, I am not asking for universe inclusion, I am just trying to get help from packagers [04:32] I don't think you're likely to find packages here if it's not for universe. [04:32] heh. I learned enough to discover that I'm not a licensed bot wrangler. Now I can stop worrying and go back to pestering others :) Thanks Hobbsee (as always) [04:32] hehe [04:33] verb3k: why not? [04:34] if it has a package, and is tested etc === asac_ is now known as asac [04:34] verb3k: it might as well be in universe [04:35] * persia notes it would likely be multiverse anyway [04:35] pwnguin, Does the universe follow some rules for inclusion regarding quality? (like the debian stable) [04:35] wow, the upgrade to hardy is pretty large [04:35] 651MB [04:35] 920 packages upgraded [04:35] That's quite small. [04:35] bderrly_: It's just getting started... [04:36] verb3k: different rules [04:36] 000/c [04:36] ugh [04:36] guess i had better get it now then ;) [04:36] verb3k: if you, as the upstream author, are not prepared to accept bug reports from users, its probably not a good idea [04:37] pwnguin, I would like to solve bugs in my program, that's good practice [04:37] pwnguin, google code has a decent tracker [04:37] persia: i dont see why it'd go in multiverse if the code's free and doesnt depend on nonfree [04:37] verb3k: as does launchpad ;) [04:37] does lp track google code yet? [04:38] That would be a no. Bug #78395. [04:38] Launchpad bug 78395 in malone "Support Google Code's issue tracker" [Undecided,In progress] https://launchpad.net/bugs/78395 [04:38] anyways, its fine if you use google [04:39] not upstreams problem if it doesnt [04:39] pwnguin, I may switch to launchpad, I make up my mind later [04:39] verb3k: ideally, you'd get it into ubuntu and debian unstable at least [04:40] pwnguin, good, have you seen the code? do you think it can stand on its feet? [04:40] im looking at the google code svn [04:40] its empty [04:40] pwnguin, yes XD , I just put the tarball [04:40] pwnguin, downloads [04:41] check it into cvs/svn/bzr at least, so distros can track commits for patches [04:41] pwnguin, will do [04:41] pwnguin: I thought it was a firmware manager for a non-free emulator. Shouldn't that depend on the emulator, making it multiverse? [04:42] from what i can tell [04:42] it rips cds [04:43] we have tools to rip music to disk [04:43] persia, that's true, you do NOT need to play it in an emulator, you can just back it up for later burning [04:43] My misunderstanding. I thought it packed into the right format for a PSX emulator. It's certainly free for real hardware. [04:44] again, oggenc isnt in multiverse, nor is sound juicer [04:45] verb3k: unfortunately, im not in MOTU, and not at all familiar with psx emulation or python [04:45] pwnguin: Right. I misunderstood. If I were packaging a ROM manager for MAME, I'd rather be multiverse and depend on a MAME than be universe. On the other hand, PS X hardware is more common than arcade cabinets. [04:46] im not sure why rarity matters [04:46] psx hardware is commonly modded to play backups [04:46] the original psx didn't need modchips to play backups [04:46] shennanigans [04:47] maybe later versions yes [04:47] pwnguin: One sets Recommends & Suggests based on the common case. Universe Recommending Multiverse is frowned upon. If the common case is real hardware, than Suggests: is correct. If the common case is emulators, Recommends: is correct. [04:47] unless you're referring to the console port in the back [04:47] * Fujitsu wonders what this PS X is. Is it some generation of the Sony PlayStation that I've never heard of? [04:47] Fujitsu: Yes. [04:48] its the old term for the playstation one [04:48] Ah. [04:48] apparently there was some playstation hardware running simply as a drive to the snes [04:48] that got scrapped and they called the new project psx internally, i guess [04:49] Initially, sony wasn't planning to enter gaming business http://en.wikipedia.org/wiki/PlayStation [04:49] verb3k: You should really put your code repo up... [04:50] assuming one ever existed [04:50] it would be nice to import that into the public repo on google code [04:50] it's a fresh account [04:50] indeed [04:50] but it should be able to import histories [04:52] verb3k: about how many users do you think you have currently? [04:53] pwnguin, I don't know , didn't release it for the gaming community yet [04:53] many developers saw it [04:53] but not many gamers [04:55] one thing I find very daunting in programming, is the amount of knowledge you should have to complete a single task.....that's very good but requires a lot of time, dedication, and lots of reading [04:55] depends on the task [04:55] and lots of research [04:56] but basically, yea, preparing is better than diving in head first [04:58] I am trying to find problems that interest me to solve them with python, this psxim tool initially was a bash script I did for myself only, then thought about sharing it, and then making a GUI etc.....chains of ideas :) [05:00] is it possible to detect which drives have a psx disc in them? [05:00] pwnguin, I thought about that but didn't really search or ask [05:01] I think it's achievable [05:03] not a requirement, but it might make it slightly more substantial [05:03] true [05:03] alternatively, it might mean you could write a nautilus script [05:04] well, i just broke another chair [05:04] guess i need to go to walmart [05:04] ... [05:05] verb3k: later; if nobody wants to put it directly into universe or debian unstable, you might see if a "packaging jam" is being held locally [05:06] what's that? [05:07] verb3k: a LoCo training session [05:07] for packaging [05:07] my loco is shattered [05:07] but jono cant possibly use normal words, being a british [05:07] 5 or so people and then can't find them anymore [05:09] In fact, LUGs are more common than LoCos [05:10] yea [05:11] locos in the US feel a bit silly [05:13] the local community needs join forces instead of splitting in smaller groups( you know gentoo guys, ubuntu guys and suse guys) [05:13] to* [05:23] well, its nice to have resources available to ask "how do i do x" in cases where it varies between gentoo, ububntu etc [05:30] verb3k: I don't find LoCos in the U.S. silly [05:31] I didn't say that LOL :) [05:31] Ah, that was pwnguin, sorry ;) [05:32] Yay for a package having an MD5/size mismatch causing debmirror to fail. :) [05:32] pwnguin, that's true but nor for all countries, there are countries where you barely find a Linux user [05:33] pwnguin, not* [05:33] TheMuso: Broken mirror? [05:33] Fujitsu: No, the problem is on auc as well. [05:33] Ah, that bug. [05:34] Fujitsu: Oh its known? [05:34] * TheMuso shouldn't be surprised. [05:34] But is [05:34] Yes. I'll find it. [05:34] np [05:34] Bug #174038 [05:35] Launchpad bug 174038 in soyuz "bad md5sum in Packages file" [Undecided,Triaged] https://launchpad.net/bugs/174038 [05:35] Fujitsu: You really seem to be quite up on soyuz shortcomings. === ScottK2 is now known as ScottK [05:36] * Fujitsu ends up reading most Soyuz/Malone bugs. [05:36] TheMuso: he does a lot of soyuz support. crazy guy [05:36] Hah. [05:36] heh [05:37] * persia wonders if the 1.12 rollout was successful, and if it fixed the bug that annoyed me. [05:37] The announcement was wrong. [05:38] Fujitsu: Incorrect, evil, or both? [05:38] Ah. Then no, and no, and more so, not good questions anyway. Thanks. [05:38] It apparently wasn't attempted. The date was probably listed incorrectly. [05:39] Maybe they are using the 49-hour international day, and it's still pending RSN. [05:40] It says UTC, and I haven't seen any other announcements about it happening, whereas there are usually emails. [05:41] Right. Looking again, I was doing bug triage during the upgrade window, so would have noticed. Isn't it usually Thursdays anyway? Maybe the 20th? === cassidy_ is now known as cassidy [06:11] * Fujitsu wonders why that md5sum bug isn't Critical and long-fixed... [06:11] Hi all! [06:12] Hi warp10. [06:12] Fujitsu: hi! [06:14] Is is "a EVMS object" or "an EVMS object"? What's the rule again? [06:15] That's debateable. [06:15] I would say the latter, as it's very rarely expanded, but others would disagree. [06:16] Wait, in both cases it is the latter. [06:17] The rule is that the 'n' is included if the following word begins with a vowel (sometimes including 'h' and excluding 'y') [06:18] Right. But acronyms can get interesting to pronounce with that policy, but that particular one isn't afflicted. [06:18] yes, I remember that it's not only the letter, but the sound. [06:18] blueyed: Right, which is why it is often "an hour" and "a yellow dog" [06:24] Does a patch like the following make sense really? Or does it only put work on the translators? http://launchpadlibrarian.net/4704937/evms-strings.patch [06:25] blueyed: It makes a lot of sense, and is a good patch, and should be applied upstream (not even Debian would be very interested). [06:26] persia: yes, I'd forward it in anyway. So you think I should prepare a debdiff? [06:26] There are two other similar bugs for the same package. [06:26] (with smaller patches) [06:27] blueyed: I don't see anything there that might be confusing, just typos & the like. I'd not sponsor that, and don't expect others would: the problem is that it makes all the strings fuzzy for small benefit. [06:28] Ok. So then it should only get forwarded upstream? [06:29] blueyed: Right, and watched, and closed when upstream accepts it. Was there a change that would reduce confusion, or changed something that was wrong, it would make more sense to apply an Ubuntu-specific patch. [06:29] * persia notes that the guidelines are a little different for packages in main due to Rosetta, and that the answer may be different (but not likely very different). [06:39] persia: submitted the patch to upstream (luckily on SF.net) and added bug watches. Sometime launchpad is really nice.. ;) [06:47] blueyed: Sometimes :) Please stay subscribed, as LP can't yet tell when it's fixed by tracking the upstream bug into the repos. [06:50] * Fujitsu notes that LP should actually grab the status of SF bugs from 1.1.12. [06:51] Fujitsu: yes, but it does not close the Ubuntu task. [06:52] Fujitsu: As in actually report them as "closed elsewhere" for easy tracking? [06:52] persia: Yes. [06:52] SourceForge is the only type of bugtracker import that doesn't do that at the moment. [06:54] * persia anticipates significant growth of https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream [06:54] Hopefully. [06:54] And we even get importance syncing soon. [06:55] c [06:55] damn wrong ta [06:55] tab [06:58] Fujitsu: What's the MOTU-swat workflow? Does it involve subscriptions for things like bug #176931? [06:58] Launchpad bug 176931 in lookup-el "[lookup-el] [CVE-2007-0237] possible local symlink attack" [Unknown,Fix released] https://launchpad.net/bugs/176931 === zakame_ is now known as zakame [06:58] persia: Yes please. I wish hk47 would subscribe us, as he files a lot. [06:59] Fujitsu: This should probably be documented somewhere :) [06:59] Quite possibly. [07:28] good morning [07:52] morning [07:55] hey geser [07:55] Hi dholbach [08:20] what is format for specifying LP bug number in changelog? [08:26] LP: #nnn === LucidFox is now known as Sikon_Stargate [08:34] geser: thanks [08:36] One more question. a package doesn't exist in debian yet, I am packaging it for Ubuntu. Is the XSBC-Original-Maintainer field necessary? [08:37] No if the maintainer address you use is an @ubuntu.com one, I believe. [08:38] If you plan to have the package be team maintained, it's good to add your name as the Original-Maintainer to note that you are a good contact if people have questions. [08:42] persia: No plans like that as of now. === blueyed_ is now known as blueyed === Sikon_Stargate is now known as LucidFox [09:05] I have just added libxml-commons-external-java to revu. This is one step forward in getting latest batik in Ubuntu. It is my first attempt at java library packaging from scratch. So please hammer slowly. :-D [09:09] Mightn't it be an idea to get batik to build on the buildds in the first place, before upgrading it? [09:10] Fujitsu: Tried that already. Too many errors. 1.7 beta will build if this library is in and a small problem in build.xml is fixed via a patch. :-) [09:11] Ah, good. [09:11] Using icedtea or gcj? [09:11] Fujitsu: gcj [09:12] MOTUs and hopeful : Hello :) [09:13] * persia complains about discrimination against core-devs and happy contributors :) [09:17] ;) [09:17] * dholbach hugs y'all :) [09:17] persia: if you want I can leave and come back to make it ok :) [09:20] huats: No worries. I just like complaining about that :) [09:22] * huats always knew that you like to complain.. [09:22] :) [09:46] Does anyone in the SRU team intend to attend the MOTU meeting on Friday? [09:49] Don't think I can make it. [09:49] Actually, I could make that [09:50] persia: I don't think its hard to use. I've almost got the steps memorised, both for making one, and checking one. [09:53] TheMuso: I'd agree with that, it's just that there was an SRU team meeting last week, and I'd like to see a report of the updated process. If someone is attending, and wouldn't mind preparing a short note as an agenda item, it might be nice (but is definitely wishlist). [09:53] Right. [09:54] * persia cheers, and travels [10:12] hi [10:19] must an upstream makefile support the DESTDIR variable ? [10:27] dsop: if it doesn't use autoconf then yes [10:31] It think I'm not allowed to change files outside the debian folder? [10:31] Somehow the f-spot package does this [10:32] elmargol: if you need to do it use a patch system [10:33] * StevenK tries to figure out why a CDBS using package fails with dh_install [10:40] ... Interesting. The terminal that build is in is orange ... [10:40] I think the Ubuntu theme is re-asserting itself === bigon` is now known as bigon [11:05] norsetto: morning [11:05] morning [11:08] hey norsetto - how's your network? [11:08] dholbach: hi :) [11:08] hi Kmos [11:08] dholbach: hey! finally solved my problems with my IP [11:09] norsetto: how did you solve it? [11:09] everybody cheer! we have norsetto back! [11:09] dholbach: by calling them and giving them a hard time .... [11:10] and how did they fix it? [11:11] dholbach: no idea, what they told me is that there was a problem in the "central", I guess just a server went boing last thunderstorm [11:11] moins all [11:11] * imbrandon yawns [11:11] norsetto: I'm really glad you're back [11:11] yes, his colon is still ok [11:11] * txwikinger2 sympathy-yawns [11:12] imbrandon == imbrandon++; today is the last birhtday of my 20's :( [11:12] hehe [11:12] ____ ___ _ _ ____ ____ _ _____ ____ _ [11:12] / ___/ _ \| \ | |/ ___| _ \ / \|_ _/ ___|| | [11:12] | | | | | | \| | | _| |_) | / _ \ | | \___ \| | [11:12] | |__| |_| | |\ | |_| | _ < / ___ \| | ___) |_| [11:12] \____\___/|_| \_|\____|_| \_\/_/ \_\_| |____/(_) [11:12] [11:12] ! :-) [11:12] hehe thanks dholbach [11:13] long live monospace [11:13] imbrandon: happy birthday! [11:13] happy birthday imbrandon :) [11:13] happy bday imbrandon [11:13] imbrandon: happy (!?) birthday [11:13] * imbrandon feels loved [11:13] * txwikinger2 feels really old [11:13] we need to get an irc admin to kill him with "HAPPY BIRTHDAY" [11:13] :) [11:14] Kmos: i'm a freenode staff, guess i could do it myself LOL [11:14] imbrandon: lolll [11:14] * norsetto thinks txwikinger is a reckless youngster [11:14] imbrandon: isn't a bad idea.. onself kill [11:15] * txwikinger2 is probably double the age of norsetto :) [11:15] what does that make norsetto then? :D [11:16] since we are talking about age, I think somebody just turned to the top position again (well, at least he joined me) [11:16] heh age is all relitive, i turn 29 today and it dont bug me a bit, i love birthdays , but my wife is a few months older than me ( turned 29 in sept ) and it kills her [11:16] lol [11:17] txwikinger2: I doubt you are 90 years old, but then I could be wrong [11:17] what is the top position? the oldest person? [11:17] Nah.. not 90 :D [11:18] the only bad part is its still 5am here, so no one else is awake yet :) [11:18] a lot of people never really wake up anyway [11:19] heh [11:19] * txwikinger2 thinks otherwise they wouldn't prefer Windows over Ubuntu ;) [11:22] bug 173529 [11:22] Launchpad bug 173529 in python-coverage "Please sync python-coverage 2.6-1 (universe) from Debian unstable (main)" [Wishlist,Invalid] https://launchpad.net/bugs/173529 [11:22] DaD is down? [11:22] what can I do about this one? [11:22]