[00:00] somerville32: Thanks. [00:00] nxvl_work: You're welcome to merge apt-proxy if you like. [00:00] effie_jayx: i'm looking at you patch, did you make the changes outside of debian/ [00:00] RAOF: thnx [00:00] nxvl_work: Just be careful of the bashism in Debian & dashism in Ubuntu :) [00:01] RAOF: but i haven't notice that it was already merged :( [00:01] nxvl_work, no [00:01] that I remember [00:01] the manpage was in debian/ [00:02] oh right i haven't look well :) [00:02] but it is renamed to runghc.man and when the other are generated, it gets changed to a .1 [00:03] effie_jayx: did you build it and install it? [00:03] yes [00:03] effie_jayx: and the man page it's installed correctly? [00:03] yes [00:03] I had to install man in my pbuilder to test it [00:03] so don't mind if the name is changed [00:04] heh, yes, thats the PITA of pbuilder, but i love it [00:04] nxvl_work, it's cool... [00:04] does it look ok' [00:04] that bug was tricky [00:05] the packaging of the manpages is done through a script that made it more difficult for me ... I couldn't see the manpages it had... [00:05] effie_jayx: they are all tricky when you start [00:06] i still find some bugs tricky [00:07] nxvl_work, well .. I did my best [00:07] and I think this is the first time I go all the way with a bug [00:08] effie_jayx: yes, we need to do our best, and if isn't enough to solve the bugs ask for help :D [00:08] there are somethings i already do mechanically [00:09] nxvl_work, thoughts on the bug... you think I did ok? [00:12] effie_jayx: well i only take a... [00:12] "mirada rapida" [00:12] and it seems fine [00:13] quick look* [00:13] oh yes [00:14] effie_jayx: you need to add (LP: #95985) to the changelog [00:14] also you have changed debian/rules, and it isn't shown on your changelog entry [00:15] hum. [00:15] ahhhmmm [00:15] :( [00:15] there's no license associated with debian/runghc.man. Is that intentional? [00:16] no [00:16] (i.e., normally one says that the man page is redistributable under the terms of Foo) [00:17] crimsun, sure... but hte manpage for ghc didn't mention anything :S [00:17] effie_jayx: I thought you made debian/runghc.man. [00:17] crimsun, but that's for runghc... [00:17] effie_jayx: i make a comment on LP with the 2 suggestions i have just made [00:18] effie_jayx: yes, and that's what I've been referring to... [00:18] there is a manpage for ghc [00:18] and I tried to follow the same pattern [00:18] crimsun, would you suggest a licence? [00:18] effie_jayx, You need a copyright notice. [00:18] effie_jayx: change this 2 thinks, the sponsors won't accept your patch until you fix them [00:19] ok [00:19] effie_jayx: for debian/runghc.man? I generally choose GPL v2 or later for man pages installed into Debian{,-derived} systems. [00:20] nxvl_work, I'll have a look at those ... [00:20] and fix them [00:23] effie_jayx: NICE! [00:24] tehe, jordi just flooded pkg-alsa-devel with several hundred queued e-mails [00:24] crimsun, where could I see and example of a copyright notice in a man page? [00:25] c [00:25] ugh wrong tab [00:25] heh [00:26] effie_jayx: e.g., update-alternatives(8) [00:29] crimsun, This manual page was written by Efrain Valles Pulgar [00:29] . This is free documentation; see the GNU General [00:29] Public Licence version 2 or later for copying conditions. There is NO WARRANTY. ... does that make sence? [00:29] ugh... sorry [00:29] should have pastbined [00:29] effie_jayx: sure, if you wish to use the GPL v2 or later. [00:30] it's ok [00:30] then I am going again [00:37] changes made [00:37] I have to package and test again? [00:48] that's a yes I guess.. [00:49] yes, regenerate the source package. [00:50] ok that's take a while ;) [00:51] I have done the source package [00:51] and donde the debdiff [00:51] but I need to test it? [00:52] * effie_jayx is already building the package for a test on a chroot env [00:53] effie_jayx: It's always best to test, as it saves having to do it again after you've forgotten the details when your sponsor tests, or worse needing to make new upload to fix the mistake when a user tests :) [00:53] hi [00:53] persia, could you spare some time for prism ? [00:54] Ubulette: Not soon :( You'll get a better package if you get reviews from lots of different people anyway. [00:55] i'm sure of that but I've asked 3 or 4 times here, no one answered [00:55] oh, RAOF had a quick look but that's about it [00:55] Ubulette: Did you ask on a Monday? Sometimes people wait for REVU day to do reviews. [00:56] i can easily have several reviews from the mozilla team but i wanted something external [00:56] ok [00:57] It'll take two hours or so [01:02] well, it's not really encouraging. i've tried my best to follow the motu process to integrate my new package. [01:02] Ubulette: From a quick look, it's fairly good, although I'm not sure of the value of shipping MPL in debian/ and in the orig.tar.gz, except perhaps to help with building the orig.tar.gz. One reason it might be taking a while is that people need to really test at this point, rather than just complaining about packaging issues. [01:04] Ubulette: You've been following the process wonderfully. It's just that it often takes a while to get things in, even when they are perfect, as there's not a lot of active reviewers. [01:07] what else could I do ? prism will gain more exposure only once it is in. so far, my limited set of users seems happy but now, what ? wait or give up ? [01:08] Ugh, what happened to font rendering in FF-3? [01:08] Ubulette: I'll have a more thorough look now. [01:08] Ubulette: I'd recommend waiting. The review queue is down to about two weeks (it was around 2 months a week back), so even FIFO processing will catch you soon enough. [01:10] RAOF: which ff3 ? b1 in hardy or my newer packages ? [01:10] B1 in hardy. [01:10] Has someone turned off the "build against libcairo-awesome" or something? [01:12] Oh dear. I appear to be capped. Hello, 13kb/s! [01:13] Ubulette: Oh, on my last run through of prism I noticed that new-orig-source seems to be doing what get-orig-source should do (at least on my reading of policy). [01:13] RAOF, ff3 is not using system cairo as mozilla is far ahead [01:13] On the other hand, your g-o-s rule is obviously useful, and my reading of policy may not coincide with anyone else's. [01:13] Urgh. [01:14] Dear upstreams: no matter how cool the new, unreleased library is, it's not worth shipping it in your source tree. kthxbye. [01:14] g-o-s should get the current orig.tar.gz, and other rules to help with updates are nice, but not required. [01:14] RAOF, i've tried but hardy has 1.4.10 while mozilla ships 1.5.2 [01:15] persia: Ok. Maybe I'm reading the "most current" in debian policy differently. [01:15] s/maybe/obviously/. [01:15] * persia looks at policy again [01:16] RAOF, get-o-s is supposed to fetch the tarball usefull to build the package, while new-s-o is supposed to fetch the newest possible tarball for the packager to prepare a newer version. [01:17] RAOF: No, you're correct, and I'm mistaken, based on an old justification for get-orig-source. I don't like the policy, but it seems it was too much trouble to try to reconstruct the preferred tarball. [01:17] at least, that's how I do things. maybe not what the book says [01:17] Ubulette: Yeah, I understand what you intend them to do, and they're both useful. I've just been reading policy to mean g-o-s should get the most recent source, not the one used to build teh package. [01:17] * persia apologieses for Ubulette for having previously provided incorrect advice [01:18] Easy enough to fix. Rename g-o-s to get-pkg-source, and n-o-s to g-o-s. [01:18] RAOF: That's what policy says. Do you think it's useful (assuming we're not enforcing a policy of having the very latest source)? [01:19] both of my rules are getting svn stuff. I assume the policy is about released tarballs [01:19] persia: It'd really be nice to have two targets, really. g-o-s as you understood it is probably more useful than a strict reading of policy. [01:20] Ubulette: Do you know how soon FF3 is planned to be released? [01:20] RAOF: I completely agree. On the other hand, I'm not very familiar with how we might get something useful without breaking all of the Debian syncs. I'm especially concerned for VCS pulls, as what g-o-s grabs may not even work when following policy. [01:22] why would you want a target to grab the *current* source, when that's already part of the source package at hand? [01:22] slangasek: Because you have just the debian/ directory in VCS? Because you repackage the upstream tarball? [01:23] Because upstream never releases, so you're packaging a VCS snapshot? [01:23] slangasek: 1) maybe you don't trust the packager, and want to reconstruct (paranoid user scenario), 2) maybe it would be nice to just pass a diff in order to reconstruct a package (easy reviewing scenario), 3) maybe it would simplify debian/ in VCS workflows (no need to VCS the orig.tar.gz scenario) [01:23] RAOF: those are all good reasons to have a target that lets you grab the *new* version for packaging [01:24] RAOF: but it's simply not true that the get-orig-source target in policy is expected to recreate the current tarball [01:24] slangasek: I don't disagree with that. [01:24] slangasek: A target to grab *new* is also nice, but that's for packaging convenience, and is unlikely to have direct user impact. On the other hand, having an orig.tar.gz whose md5sum doesn't match the upstream distribution point is annoying, and providing a way for users to verify is useful. [01:25] RAOF, FF3, not sure anyone knows. when it's ready ;) b2pre is moving quite fast, full gnome integration with theme and all, better memory handling, etc. [01:26] Ubulette: Because they're building against their own internal copy of a development snapshot of cairo which seems unlikely to be released before FF3. This seems like a really awkward situation. [01:27] persia: packaging convenience is a far more realistic use case than random end-users verifying source packages; and repacking an upstream tarball doesn't guarantee that you'll get the same md5sum as the maintainer anyway [01:27] s/verifying source packages/& at that level/ [01:27] slangasek: I don't care if I get the same md5sum, I care that I only need to read the diff.gz to see the distribution-specific changes. [01:28] RAOF, I know but mozilla is working closely with cairo devs to optimize it far more than what it is now. [01:28] slangasek: Further, I agree completely with your reading of policy: I just want the other as well. [01:28] RAOF, I assume your comment is about the freetype patch [01:28] persia: that's not an end-user operation anymore, then... [01:29] slangasek: I was doing that fairly regularly long before I actually sent any email to a debian ML, but perhaps it's just me. [01:29] or at least, you would still have to verify without the help of md5sum that the two tarballs match if that's what you care about [01:29] Ubulette: No, my comment is about having to ship FF3 with a development snapshot of cairo. The font rendering being crap is but one downside of this :) [01:30] slangasek, with repacking, you're absolutely sure you'll get a different md5 checksum ;) [01:30] slangasek: Well, if I can see a short script to construct it, and run the script, and it works, I don't usually need to go further, as long as the script downloads from a known good source. [01:30] Ubulette: I mean that two runs of get-orig-source (one generating the tarball in the archive, one on the user's local machine) are not guaranteed to give the same results, even given the same source tarball [01:30] s/same results/same md5sum/ [01:31] This is absolutely true, for any g-o-s that goes beyond calling uscan for a verified upstream tar.gz [01:31] persia: considering how few upstreams sign their tarballs, I think this is more useful for verifying whether upstream is a good source anyway... :) [01:32] in prism, with g-o-s, you'll get the same files (diff -r will show no difference) but not the same md5 as tar includes the time stamps which are always local, ie different [01:32] slangasek: Right: it just means that my grand plan for streamlining sponsoring needs some rework :( [01:32] Ubulette: That's normal. [01:33] persia, I know. I'm not a noob in unix [01:34] * persia apologies for the perceived slight [01:34] widgets/.libs/libmodest-widgets.a(modest-mozembed-msg-view.o): In function `set_message': [01:34] /modest-1.0/src/widgets/modest-mozembed-msg-view.cpp:673: undefined reference to `modest_tny_msg_find_body_part(_TnyMsg*, int)' [01:34] * StevenK looks confused. [01:34] StevenK: ld has lost a body part, you see [01:34] I see that. [01:34] I just can't figure out where it lost it. [01:35] Linking it not exactly my strong point. [01:35] s/it /is / [01:35] how about grepping? >:) [01:36] The header that defines that function is one level down, and ../.libs is empty [01:36] persia, no offense taken ;) [01:36] the function is defined in a header? [01:46] RAOF: define crap. are you talking about subpixel rendering improved by the turner's patch ? [01:46] bug 164640 [01:46] Launchpad bug 164640 in firefox-3.0 "Apply subpixel rendering patch to cairo" [Undecided,Confirmed] https://launchpad.net/bugs/164640 [01:48] Ubulette: Crap, as in looks much worse than epiphany or FF2. Possibly related to subpixel rendering, but it also seems to be using a different DPI calculation. [01:49] I can provide screenshots if you're interested. I know that "crap" isn't a particularly useful bug description. [01:50] well, try setting dpi to 0 in about:config (should be -1 by default) [01:51] some X drivers are buggy so 0 is not good, then a positive value is needed, like 82 or 84 [01:51] And restart FF? [01:51] no need [01:52] Ah, well. [01:52] screen -r [01:52] woops [01:52] Heya gang [01:53] Heh. Nouveau is a lot less buggy than I thought. It's xcompmgr :) [01:53] Ubulette: Well, that didn't appear to do anything at all. [01:54] layout.css.dpi ? [01:54] Was -1, is now 0 [01:55] try 82, 84 or anything positive matching your preference for the size [01:55] * persia suggests using the number that actually matches your hardware [01:55] Nope. [01:56] strange, works for everyone else [01:56] Ah, it works for some text but not all. [01:56] Particularly, it does'nt change the review text on revu at all. [01:56] And that's what's looking particularly ugly at the moment. [01:57] Maybe it's an issue with "monospace"? [01:58] Maybe. [01:58] * RAOF fiddles with font settings [02:00] * RAOF gets bored & gives up. [02:02] the focus is currently on better gnome integration, so it's time to report things like that [02:02] http://www.sofaraway.org/ubuntu/tmp/ff3b2pre-gnome.png <= b2pre with default ff3 theme and default ubuntu gnome theme [02:03] http://www.sofaraway.org/ubuntu/tmp/theme-after.png <= default ff3 theme but another gnome theme [02:03] (2nd window is nautilus) [02:05] Ah, so xul is becoming less obnoxious. Yay. [02:08] !info libgnome-desktop-dev hardy [02:08] libgnome-desktop-dev: Utility library for loading .desktop files - development files. In component main, is optional. Version 1:2.21.2-0ubuntu1 (hardy), package size 59 kB, installed size 452 kB [02:08] damn, hardy is late :( [02:18] Hi There. I'm on the Colorado LoCo and we have been discussing a user-friendly and educational way to confront this issue: http://ubuntuforums.org/announcement.php?a=54 [02:20] An idea we had was a sort of "sudo tutorial": A graphical tutorial on fresh-installs that pops up and details the power and danger of running commands as root prior to allowing any root commands to be run. [02:21] Would this be the right place to find a champion for this idea? [02:21] btrigg, See #ubuntu-doc [02:22] somerville32: Thanks much. [02:24] Ubulette, is sofaraway.org/ubuntu/ yours? the firefox-minefield packages have a dependency on pango 1.19 even tho 1.18 is in the repos. [02:27] * StevenK kicks his lack of linking knowledge [02:29] * persia dreams of a whitespace-aware diff [02:30] I'm trying to figure out how to fix an undefined references [02:30] StevenK, in what? [02:30] StevenK: Are the symbols available in the objects that you've -l'd into ld/gcc? [02:31] persia: It's a little more stranger than that, since the symbol is in the program itself, not a library [02:31] DarkMageZ: indeed, it's mine. strange, i'm not building pango in there. btw, i'm moving my bot from gutsy to hardy so some packages are broken (yet, the whole firefox-minefield mini dist should be ok) [02:32] StevenK: In the same source file that is under compilation? [02:32] persia: Not the same source file, but the same tree [02:32] StevenK: It's not some strange template instantiation issue? [02:33] OK. Are you linking the patch where that object file resides when you compile the target? Separately, are you also explicitly including the header for that reference in the source that references it? [02:33] Ubulette, yeah. i thought it a little odd that gutsy packages were depending on a version of pango that wasn't in either ubuntu or it's oown repository. [02:33] RAOF: I don't think so [02:33] s/patch/path/ [02:34] Ah, no. That error message is far to clear to be a template issue. [02:34] /modest-1.0/src/widgets/modest-mozembed-msg-view.cpp:673: undefined reference to `modest_tny_msg_find_body_part(_TnyMsg*, int)' [02:35] DarkMageZ, the goal of my repo is to daily package HEAD of everything so it no longer makes sense to use gutsy as a base [02:35] So where is that function defined again? [02:35] in src/modest-tny-msg.c [02:36] That looks like a parser issue, rather than a linking issue. Make sure your -I includes the right directories (even in the same source tree), and that you've explicitly included a header defining that in modest-mozembed-msg-view.cpp [02:39] StevenK: Is there a inc/modest-tny-msg.h or src/modest-tny-msg.h? [02:39] persia: Yup. And it's included in src/widgets/modest-mozembed-msg-view.cpp [02:40] StevenK: This is the same error as before, right? The one that starts with "widgets/.libs/libmodest-widgets.a(modest-mozembed-msg-view.o): In function `set_message': [02:40] RAOF: Right [02:40] StevenK: And your gcc call has "-I." ? [02:40] persia: I'm just checking that [02:40] Err. "-I widgets/" [02:41] It does not [02:41] Err. I suck! "-I ./widgets/" [02:41] StevenK: In that case, the #include directive probably can't find it. [02:43] But then it would error out on the compiling phase, right? [02:43] persia: But this thing is autoconf'd and automake'd, shouldn't it just deal? [02:43] * persia is confused: is this *not* a build-time error? [02:44] StevenK: It should, but it wouldn't be magic if it was easy to understand :) [02:44] Heh [02:44] I thought it was a link-time error? [02:44] persia: It's already built libmodest-widgets.a, and the linker's complaining about an undefined reference in that archive. [02:44] If it's link-time, then the problem isn't -I, but -L [02:45] (alternately, if it's trying to link into a .a file, perhaps there's some funny naming redirect, but that's unlikely) [02:45] There's only one -L, and it's xul stuff [02:45] Where does modest-tiny-msg.c end up being built into? [02:46] (This should be findable in the Makefile.am) [02:47] I think you usually get "-L ." by default, but likely not "-L ./widgets/" (and Makefile.am should do it right, but might need a hint) [02:48] RAOF: It ends up modest_SOURCES [02:49] Is that the src/ directory in which you are linking? [02:50] Yup [02:50] Just to confirm, the generated object does contain the correct reference mid-build, right? [02:51] 0# strings src/modest-tny-msg.o | grep body_part [02:51] modest_tny_msg_find_body_part [02:52] So, yes. :-) [02:53] Hmm... You might try a manual link with -L./src/ (or just '.' depending on where you run it), but I'm pretty sure you're supposed to get that by default. [02:54] Maybe some pastebinning of Makefile.am might be useful? [02:54] RAOF: src/ or src/widgets ? [02:55] RAOF: I can put my sources up, if you want? [02:55] Eh, why not. [02:55] I'll just do a bit of an update-reboot, and be back shortly. [02:55] * StevenK stares at git. [02:57] ROAF: Didn't you say you were going to let me have access to your server to build on? [03:02] somerville32: Yup. [03:02] Still want it? [03:03] It'll be a bit slower for a couple of days, until I get uncapped again. [03:03] RAOF: If you want to build it, you also need libtinymail, I can give you source or binaries of it too? [03:03] Either should be fine. [03:03] Whatever's easiest. [03:03] But it's not in the archives yet? [03:04] This particular version isn't, just in case I need to fiddle it to get modest happy [03:04] RAOF: amd64 or i386? Since amd64 is built [03:05] RAOF, yes sir [03:05] somerville32: LP id? [03:06] RAOF, cody-somerville [03:11] somerville32: Right. You should be able to login to cody-somerville@cooperteam.net now, and use sbuild. [03:11] Ugh. TPG. :-P [03:12] Eh, I haven't had (many) problems. [03:12] woot woot [03:12] TPG? [03:12] somerville32: An Australian ISP with a (deserved) reputation [03:13] I couldn't find anyone else with spare ADSL2+ sockets in my area at the time. [03:13] RAOF: So, are you building for amd64 or i386? [03:13] StevenK: amd64 by default. I think I've got an i386 builder lying around. [03:13] RAOF: Well, I'm building for amd64, too, so that makes it simple. [03:14] Yay! [03:15] RAOF: http://wedontsleep.org/~steven/modest/ [03:16] RAOF: I can run apt-ftparchve in that directory if that makes it simpler [03:17] There aren't really that many deps, right? [03:17] And dget is almost as simple as apt-get source [03:17] RAOF: What's in that directory is the source of the modest and amd64 debs for everything else [03:18] s/the // [03:19] Is there any particular reason not to use the libtinymail in the archives? [03:20] RAOF: Yup. That libtinymail is built against xulrunner-1.9, and the one in the archive is built with firefox-dev -- modest requires xulrunner-1.9 and gets upset if libtinymail isn't using what it needs. [03:20] K. [03:20] Eh, run an apt-ftparchive over it then, please :) [03:21] RAOF: Done. [03:22] Ta. [03:23] Let the scratch schrooting begin. [03:23] ...at the blistering speed of 15kb/s :( [03:23] Yeah, well, it is using my upstream [03:24] I suspect the dput I just started isn't helping. :-) [03:24] No, that's my downstream. I'm updating my chroot first. [03:24] Ah [03:24] * StevenK hugs his local mirror [03:25] * RAOF should buy one of these new-fangled 1TB drives and get him a mirror. [03:25] * Fujitsu mounr nhis local mirror. [03:25] Bahh, lag. [03:25] *mourns his [03:25] Fujitsu: What about it? [03:25] It got eaten by a buggy Gutsy debmirror last week. [03:25] Presumably it's messy & untimely death. [03:26] Oh. [03:26] This is why my mirror runs Dapper. [03:26] apt-mirror ftw :) [03:26] Anyway, I think debmirror is crap, and I need to write something better. [03:26] infact i need to request some backports for it [03:26] StevenK: So did mine. And the fix got pushed to -updates within 72 hours. [03:27] StevenK: help improve apt-mirror then, or join me and Fujitsu in planning/coding apt-mirror-ng ( pythonized ) [03:27] :) [03:27] Haha. [03:27] debmiror is really inflexible. [03:27] +r [03:27] imbrandon: Can I get apt-mirror to download i386, amd64 and lpia for gutsy,gutsy-updates,gutsy-security,hardy and installer-i386,installer-amd64 for gutsy,hardy in one easy command? [03:27] Thank you, irssi, for preventing me from pasting 22 lines of crap. [03:27] StevenK: yup [03:27] StevenK: that was my main problem. [03:28] StevenK: actualy you can :) [03:28] Is it written in Perl? [03:28] Thankyou, 'softies, for downloading a coupl of service packs and making my connection very laggy. [03:28] StevenK: Yes, it's one 500 line file. [03:28] It's very ugly. [03:28] yes, unfortunately [03:28] imbrandon-- [03:28] i wanna redo it in python someday :) [03:29] but atm its perl in all its glory [03:29] * Fujitsu decrements StevenK. [03:29] one perl file ( ~500 lines of code ) and one config ( /etc/apt/mirror.list ) [03:30] Actually, no, it also needs to pull amd64 and i386 from one place and lpia from another. :-) [03:31] RAOF, it is slow :] [03:31] yea thats doable [03:32] StevenK: it takes sources.list lines only modified like deb-i386 deb-lpia etc [03:32] * TheMuso returns. [03:32] so its totaly doable [03:32] RAOF, Can you install stuff like, you know... dh-make? :P [03:34] somerville32: done. [03:34] imbrandon: Can you pastebin a conffile? [03:34] somerville32: Anything else? I usually use that box as just a buildd, so it probably doesn't have much in the way of development utils. [03:34] StevenK: yea one sec [03:35] * TheMuso wonders how long he will be online before the storm decides to knock out power. [03:36] * RAOF should move to the mountains. He always misses out on the cool storms. [03:36] Heh [03:36] Heh. [03:38] StevenK: http://paste.ubuntu.com/2372/ [03:39] StevenK: with a config like that you litterly just run "10 * * * * apt-mirror apt-mirror" in a cron [03:40] Mmm [03:40] ( after initial sync ofcourse ) [03:40] and optionaly the clean.sh it generates ( cleaning removed packages ) [03:41] RAOF: Still poking at modest with a stick? [03:42] StevenK: it supports these arches .... ( more could be added trivialy ) [03:42] if($config_line =~ /deb-(alpha|amd64|armel|arm|hppa|hurd-i386|i386|ia64|m68k|mipsel|mips|powerpc|s390|sh|sparc)/) { [03:42] StevenK: Still updating my chroot with a straw. [03:42] StevenK: e.g. lpia :) [03:42] StevenK: 14.8kB/s 18m13s [03:42] RAOF: Heh, fair enough. It seems my local mirror has spoilt me [04:00] ohhh i'm in love, anyone ever messed with a picotux ? [04:00] http://www.picotux.com [04:01] Ah, one of *those* things. [04:03] * RAOF plays around with confusing awn into believing that unminimizing a window creates a new task [04:15] RAOF: Surely the chroot is up to date now? :-) [04:15] Yes, indeed. === vorian is now known as vorian_afk [04:37] RAOF: No news is good news? [04:38] There's a downside to using a disposable chroot. [04:38] Oh? It all went? [04:38] It's that there's a lot of deps that need to be downloaded before anything interesting happens. [04:39] I'll put it down to local mirror love again. :-) [04:39] * RAOF looks at prices for hard drives. [04:41] RAOF: You don't have a spare 60G? [04:41] RAOF: btw, you going to slug tonight? [04:41] Not really. [04:41] Hobbsee: No. Still sick. [04:42] :( [04:42] I presume no one at slug is going to be particularly interested in contracting week long evil cough. [04:42] With bonus bilateral middle ear infection! [04:44] RAOF: Ugh [04:44] * StevenK tries to debug hildon input method some more [04:44] Hm. I totally have 60Gb free. [04:44] apt-mirror, you say? :) [04:45] I use debmirror, but want to replace it. [04:45] RAOF: /dev/mapper/system-mirror 60G 45G 15G 76% /srv/mirror [04:46] RAOF: That's gutsy{,-{security,updates}},hardy amd64 and i386 [04:46] Binary only? [04:47] * RAOF starts working the LVM foo. [04:47] RAOF: Right. [04:49] RAOF: It took me about four days to seed my mirror, given I only want to pull down during my uncounted period. [04:49] It'll take me somewhat longer :) [04:50] However, this is not going to be terribly useful while I'm capped. [04:54] RAOF: But you're ADSL2+, and I'm only 1.5 .... [04:55] * StevenK needs to figure out how to get 30Gb down to his mother in law's place so he can upgrade his sister in laws machine to Gutsy [04:55] If only Ethernet wasn't limited to 100m [04:56] (And there wasn't a main road to cross) [04:56] Get yourself some gigibit :P [04:56] My switch is gigabit rated :-) [04:56] Cars will barely notice the twisted pair. [04:56] RAOF: Yes, but other people might [04:57] bring SIL's machine to your house? [04:57] Paint it red & white striped, or something. [04:57] RAOF: I wonder if it would have been faster to give you an account on my machine. [04:57] Hobbsee: I've been pondering that [04:57] StevenK: Survey says: yes. It may still be faster to do so. [04:58] ahh, yes, the end of the earth, where bandwidth sucks [04:58] RAOF: Okay, running adduser [04:58] Nah. Austalia's way better than New Zealand, which is itself better than Fiji [04:58] r [04:58] My bandwidth is fine until I download the 50Gb or whatever it is that my cap is. [04:58] After that... not so good. [04:59] what is this "cap" you speak of? [04:59] RAOF: Is it a cap on the local pipe, or a cap on international traffic? [04:59] persia: Local pipe. [05:00] Down to a swanky 128kbit/sec. [05:00] RAOF: Ah, so even a faster / better / cleaner mirror in AU wouldn't help :( [05:00]