| NCommander | Is there any repo software that handles udebs properly and sanely beside dak and soyuz? | 01:00 |
|---|---|---|
| NCommander | cjwatson, ^ | 01:06 |
| TheMuso | NCommander: cjwatson would be in bed now. As for software, what about falcon? | 01:19 |
| NCommander | Does it properly create the installer-*arch* dist files? | 01:20 |
| TheMuso | NCommander: I don't know, I just know it can allow you to create an archive. | 01:20 |
| cjwatson | NCommander: afraid I have no idea; when I need third-party archives I use dpkg-scanpackages or apt-ftparchive :-) I've never managed a big third-party archive | 11:02 |
| cjwatson | NCommander: I would be surprised if any software other than dak and Soyuz processed raw-installer uploads correctly (for installer-$ARCH); I wrote the code for both of those and I guess you could rip it out of dak | 11:03 |
| CIA-3 | tasksel: cjwatson * r1387 ubuntu/ (Makefile debian/changelog): Point Ubuntu task update script at jaunty. | 11:06 |
| CIA-3 | tasksel: cjwatson * r1388 ubuntu/ (debian/changelog ubuntu-seeds.pl): | 11:54 |
| CIA-3 | tasksel: Add an ubuntu-tasks/README file to explain that the files in | 11:54 |
| CIA-3 | tasksel: ubuntu-tasks/ are autogenerated. | 11:54 |
| CIA-3 | tasksel: cjwatson * r1389 ubuntu/ (Makefile debian/changelog): Remove obsolete kubuntu-kde4 tasks. | 11:56 |
| CIA-3 | tasksel: cjwatson * r1390 ubuntu/ (8 files in 2 dirs): | 11:59 |
| CIA-3 | tasksel: Update Ubuntu tasks from seeds, renaming mobile-mobile to | 11:59 |
| CIA-3 | tasksel: mobile-netbook-remix, adding mobile-live, adjusting description of | 11:59 |
| CIA-3 | tasksel: mythbuntu-live, and removing Seeds field from mythbuntu-live. | 11:59 |
| CIA-3 | tasksel: cjwatson * r1391 ubuntu/debian/changelog: releasing version 2.73ubuntu13 | 12:01 |
| CIA-3 | ubiquity: cjwatson * r2961 ubiquity/ (debian/changelog scripts/install.py): Make sure that only one of grub and lilo is installed (LP: #314004). | 13:45 |
| CIA-3 | debian-installer: cjwatson * r1016 ubuntu/debian/changelog: | 14:08 |
| CIA-3 | debian-installer: No-change rebuild with new kernel, including some crypto bits built as | 14:08 |
| CIA-3 | debian-installer: modules again, and with any luck enough support to let us build on | 14:08 |
| CIA-3 | debian-installer: armel. | 14:08 |
| CIA-3 | debian-installer: cjwatson * r1017 ubuntu/debian/changelog: releasing version 20081029ubuntu9 | 15:17 |
| tjaalton | alternate installer stops at the partitioner, shows a help screen and selecting 'continue' only brings it back | 15:51 |
| saispo | cjwatson: debian-installer_20070308ubuntu40.7 will be moved into hardy-updates ? | 15:57 |
| cjwatson | at some point yes | 15:58 |
| cjwatson | tjaalton: logs? | 15:58 |
| saispo | cjwatson: no idea when ? :) | 15:58 |
| cjwatson | saispo: it needs the corresponding kernel to be moved to hardy-updates first, which was blocked on verification of a whole load of SRU bugs last I checked | 16:00 |
| saispo | i don't understand somethings... i need to add proposed to debian-cd for building a good cd. if i not add proposed it use the kernel 2.6.24-19 and have 2.6.24-22 modules | 16:02 |
| saispo | (on the cd) why ? | 16:02 |
| saispo | normaly i just have main, update and security for building my cd | 16:03 |
| cjwatson | that should have been fixed a little while back; the debian-installer corresponding to -22 was moved to hardy-updates | 16:04 |
| cjwatson | few days ago, I think | 16:04 |
| saispo | oh ok :) | 16:05 |
| saispo | maybe my mirror have not catched it | 16:05 |
| saispo | thks | 16:05 |
| tjaalton | cjwatson: http://users.tkk.fi/~tjaalton/foo/partman http://users.tkk.fi/~tjaalton/foo/syslog | 16:09 |
| tjaalton | neither have anything suspicious | 16:10 |
| tjaalton | (the wget error isn't) | 16:10 |
| cjwatson | tjaalton: you might need to run with DEBCONF_DEBUG=developer | 16:10 |
| tjaalton | yeah, will try | 16:11 |
| tjaalton | cjwatson: ok I found out why it fails.. it didn't detect the disk | 16:15 |
| cjwatson | ah, that would do it | 16:16 |
| tjaalton | only the card reader | 16:16 |
| cjwatson | which would explain why it didn't give you an error | 16:16 |
| tjaalton | yep | 16:16 |
| tjaalton | now the obvious question, why does it fail?-) | 16:20 |
| * cjwatson blames the kernel, as usual for hardware detection problems :) | 16:20 | |
| cjwatson | (once in a blue moon this turns out to be wrong) | 16:20 |
| tjaalton | hmm ok, I'll just leave it there for now | 16:22 |
| kirkland | cjwatson: \o/ | 17:09 |
| kirkland | cjwatson: today's iso works for me, encrypted home directory | 17:09 |
| cjwatson | yay | 17:10 |
| kirkland | cjwatson: has the kernel module/built-in dust settled? | 17:10 |
| kirkland | cjwatson: or am i still working because the modules are built-in? | 17:10 |
| cjwatson | the CD you're using predates the build of d-i against the new kernel with those modules built-in | 17:10 |
| cjwatson | so partman-crypto will still fail | 17:10 |
| cjwatson | tomorrow's image will be the real test I think | 17:11 |
| kirkland | cjwatson: cool, i'll pull again tomorrow | 17:11 |
| kirkland | evand: fwiw, the encrypted home setup on the server daily cd finally works | 17:11 |
| kirkland | evand: it's probably time to revisit the graphical installer enablement | 17:11 |
| evand | hooray | 17:11 |
| kirkland | evand: or, perhaps after tomorow's "real test", per cjwatson's last comment | 17:12 |
| evand | mpt: any thoughts on the UI for that? | 17:12 |
| cjwatson | kirkland: graphical installer> blocked on figuring out the gtk/directfb bustage | 17:12 |
| cjwatson | kirkland: assuming you mean gtk d-i | 17:12 |
| kirkland | cjwatson: no, ubiquity | 17:12 |
| cjwatson | oh, what, seriously? | 17:12 |
| kirkland | cjwatson: or whatever the handler is for the desktop installer | 17:12 |
| cjwatson | how are you going to have it install packages? | 17:13 |
| cjwatson | ubiquity's not really designed for flexibility in terms of what gets installed ... | 17:13 |
| * kirkland yields to evand | 17:13 | |
| cjwatson | and in particular has no hooks into debootstrap or anything like that for base system installation, so you'd need a live filesystem | 17:13 |
| cjwatson | indeed you'd need one anyway to run ubiquity in | 17:14 |
| kirkland | cjwatson: i figured if space on the CD is an issue, such that ecryptfs-utils won't fit, i was going ask if it could be added to the DVD installer? | 17:14 |
| cjwatson | which seems like it'd crowd a bunch of other stuff off the CD? | 17:14 |
| cjwatson | oh, hang on | 17:14 |
| cjwatson | I thought you meant enabling ubiquity on the server CD | 17:14 |
| cjwatson | you mean enabling ecryptfs in ubiquity, don't you :) | 17:14 |
| * cjwatson belays panic | 17:14 | |
| kirkland | cjwatson: yessir :-) | 17:14 |
| * kirkland let's out a laugh | 17:15 | |
| kirkland | cjwatson missed a lot at UDS :-) | 17:15 |
| cjwatson | you never know what people are going to come up with ;-) | 17:15 |
| kirkland | cjwatson: as you requested, we discussed a bit of the actual interface with mpt at UDS | 17:15 |
| kirkland | cjwatson: he drew up a few picture boards | 17:16 |
| kirkland | cjwatson: evand and i looked at it | 17:16 |
| cjwatson | it's a checkbox and an initially-hidden password entry box, isn't it? | 17:16 |
| kirkland | cjwatson: i actually have some ideas on paper (not yet in code) for how to do a migration of a non-encrypted-directory to encrypt-my-home | 17:16 |
| kirkland | cjwatson: if space really became a blocker, i think it could be something we could empower users to "turn on" after install | 17:17 |
| kirkland | cjwatson: well, a little different than that | 17:17 |
| kirkland | cjwatson: for one thing, we're going to autogenerate the mount passphrase | 17:17 |
| kirkland | cjwatson: simplifies our validation thereof | 17:17 |
| cjwatson | I don't think disk space is a major problem for ecryptfs-utils | 17:18 |
| kirkland | cjwatson: and re: checkbox, it will need to operate a little more like a radio button, mutually exclusive with the AutoLogin feature | 17:18 |
| cjwatson | OK | 17:18 |
| kirkland | cjwatson: it might still look like a checkbox, but checking one of those two will need to uncheck the other | 17:18 |
| kirkland | cjwatson: which, technically is how a radio button works, i suppose | 17:18 |
| cjwatson | presumably it could be made to work with autologin, it's just kinda stupid? | 17:19 |
| kirkland | cjwatson: but i think mpt frowned upon radio buttons | 17:19 |
| cjwatson | radio buttons here feel a bit weird to me given that they aren't really obviously connected (to an end user) | 17:19 |
| kirkland | cjwatson: hmm, i don't think encrypted home could work with autologin ... encrypted ~/Private can work with autologin | 17:19 |
| kirkland | cjwatson: for encrypted home to work with autologin, we'd need some generic skeleton for gnome | 17:20 |
| cjwatson | sure | 17:20 |
| mpt | evand, my first request was to keep it out of the installer. Failing that, I drew up a couple of possible layouts, but I don't have those drawings here a.t.m. | 17:20 |
| kirkland | cjwatson: i haven't really thought that through | 17:20 |
| kirkland | cjwatson: but encrypting Private + autologin is actually a really cool combination, the way I set up my parent's laptop | 17:20 |
| mpt | evand, oh wait, yes I do. One of them uses radio buttons: | 17:20 |
| kirkland | cjwatson: allows them to secure some stuff, and enter a passphrase on accessing that | 17:21 |
| mpt | ( ) Log in as freddo automatically | 17:21 |
| mpt | ( ) Require a password to log in | 17:21 |
| mpt | ( ) Require a password to log in and to decrypt your home folder | 17:21 |
| cjwatson | why doesn't home directory encryption belong in the installer? it seems like the sort of thing you naturally want to do strictly before doing anything potentially sensitive in the directory | 17:21 |
| mpt | or something like that | 17:21 |
| cjwatson | which would lead to it being an option in (a) the installer and (b) users-admin | 17:21 |
| mpt | cjwatson, firstly because you might install Ubuntu months or *years* before you realize you're going to be doing something sensitive in your home folder. | 17:22 |
| cjwatson | mpt: I agree that it also needs to be something you can convert to afterwards (assuming that's practical) | 17:22 |
| mpt | cjwatson, secondly because you might not be the user who installed Ubuntu on this computer. | 17:22 |
| cjwatson | which means that oem-config might want to allow it | 17:22 |
| kirkland | cjwatson: that's on my plate, "Live migration to encrypting home" was something sabdfl specifically asked me to figure out | 17:22 |
| cjwatson | again, doesn't really seem to indicate against the installer providing the option | 17:22 |
| kirkland | cjwatson: i think i can solve it with a couple of rsync's | 17:23 |
| cjwatson | kirkland: have you tested that the bits from /etc/skel are copied into the encrypted home directory rather than into the underlying unmounted directory? | 17:23 |
| kirkland | cjwatson: yup | 17:23 |
| cjwatson | ok | 17:23 |
| kirkland | cjwatson: working beautifully in today's iso ;-) | 17:24 |
| mpt | cjwatson, true, but I think that's a slippery slope which the "Who are you?" page goes a little way down | 17:24 |
| NCommander | cjwatson, how's d-i on ARM coming? | 17:24 |
| kirkland | cjwatson: i have a 600M kvm image i can upload to people.ubuntu.com, if you'd like to see | 17:25 |
| cjwatson | kirkland: down a 600Kbit pipe? probably not :-) | 17:25 |
| kirkland | cjwatson: ;-) | 17:25 |
| mpt | cjwatson, for example, if Users & Groups gets the ability to take a photo of you for your account picture, should the installer acquire a (probably somewhat inconsistent) interface for doing that too? How about an interface for setting up an IM account? etc | 17:25 |
| cjwatson | mpt: while I sympathise with the slippery slope argument to some extent, I think those are very clearly distinct; those are attributes of your account, rather than a specification of how your data is stored, and furthermore migrating to encrypted-home later is always going to have some inherent problems (for example, I expect that you would need to have at least as much free disk space available as you have data in ... | 17:27 |
| cjwatson | ... your home directory | 17:27 |
| cjwatson | ) | 17:27 |
| mpt | cjwatson, the same applies even to Windows migration (why yes I do want to migrate Windows files from my other computer, but that's in my parents' house and I'm not), which is partly why I suggested earlier to evand that Windows migration be split out of the installer too | 17:28 |
| mpt | (and I'm not ... visiting them again until next week, for example) | 17:28 |
| kirkland | i see a difference between stuff that needs to be setup (bootstrapped) from the beginning of the install, and stuff that's easier to do later | 17:29 |
| cjwatson | that's an excellent argument for making m-a available from outside the installer, but not an argument for removing it from the installer | 17:29 |
| cjwatson | those two things need to be considered separately and not conflated | 17:29 |
| kirkland | setting up an IM account and uploading your picture is something that doesn't really benefit from happening on installation | 17:29 |
| cjwatson | m-a is useful in the installer because it is likely to deal with properties you want to be set up before you start using your computer in earnest | 17:30 |
| mpt | cjwatson, the general argument for not having, in the installer, anything that should be available elsewhere and doesn't *need* to be in the installer, is that it avoids having two inconsistent interfaces for the same function | 17:30 |
| cjwatson | for example, you want to migrate firefox properties over before you start to use firefox if possible, otherwise you have to figure out how to merge them | 17:30 |
| cjwatson | and I don't think that's a good argument, honestly | 17:30 |
| cjwatson | interfaces should be available in the installer if they're significantly more painful to do later | 17:30 |
| mpt | and it avoids misleading people into thinking that the installer was the only way of accessing those functions and oh, it's too late now | 17:31 |
| cjwatson | that's only a problem if the desktop is crap, frankly | 17:31 |
| cjwatson | (and we could always note that sort of thing in the installer somehow) | 17:31 |
| cjwatson | here is a logical consequence of your argument that I think is undesirable | 17:32 |
| cjwatson | there is an interface for adding users outside the installer (that some people fail to discover, for one reason or another) | 17:32 |
| cjwatson | it is not the same as the interface for adding the first user in the installer, since it offers more features such as adding multiple users | 17:32 |
| cjwatson | therefore the installer should not add any users at all, and should instead drop you into a guest account kind of thing post-install with users-admin popped up for you | 17:33 |
| cjwatson | the reason I think this is undesirable is that it conflicts with the principle that the installer should give you a usable system with no further fuss | 17:33 |
| cjwatson | NCommander: I set the build to retry earlier, haven't checked back on it | 17:35 |
| cjwatson | NCommander: you can monitor it yourself on LP | 17:35 |
| evand | well, m-a does merge settings, but probably a moot point | 17:35 |
| mpt | cjwatson, I broadly agree with that principle but I think it focuses a little too much on "the installer" as an executable | 17:36 |
| cjwatson | right, but what if you set it up from scratch again and typed in something slightly different | 17:36 |
| cjwatson | I think it does make sense to set as much up to start with as is reasonable | 17:36 |
| cjwatson | (and yes, these are all slightly-conflicting principles that we have to balance, which is why reasonable people can end up disagreeing!) | 17:36 |
| mpt | yeah | 17:36 |
| cjwatson | mpt: I'm focusing on it as a user-visible phase, rather than as an executable; I think users are quite likely to perceive rebooting as the end of installation, which I think is pretty reasonable ... | 17:37 |
| mpt | cjwatson, if you're going to restart the computer anyway to check the installation has worked, I think it's quite reasonable for a user setup to appear then | 17:37 |
| cjwatson | and I think that's superior to the alternative of rebooting in the middle of the installation process, which (from Windows experience) induced a feeling of despair | 17:37 |
| cjwatson | "oh god, how much longer is this going to take" | 17:38 |
| cjwatson | mpt: ah, see "reasonable people disagreeing" :-) I think it's better to do user setup first | 17:38 |
| mpt | because that same user setup is relevant to every user account, even if it's created months or years later. | 17:38 |
| mpt | Some of the users of the system you're installing may not even be born yet. | 17:38 |
| cjwatson | mpt: the clearest reason I can articulate for this is that it means more questions in the installation process are asked up-front, rather than with a long delay between questions | 17:38 |
| cjwatson | again, I'm not arguing for the removal of users-admin! I think it should be made *more* discoverable | 17:39 |
| cjwatson | *you're* arguing for a single interface, I'm not | 17:39 |
| mpt | yep | 17:39 |
| cjwatson | and I think the mindset one is in when installing the computer to start with is different from the mindset one is in when adding a new user | 17:39 |
| cjwatson | in the first case, the primary goal is "give me a usable computer" (subgoal: set up for me while we're there) | 17:40 |
| cjwatson | in the second case, the primary goal is "my wife wants to use the computer" | 17:40 |
| mpt | One case I have in mind is where you're installing the system for someone else, and you don't really want to get involved in setting up a dummy password for them if they're going to have to change it anyway | 17:40 |
| cjwatson | and I think those differing mindsets *can* indicate a different UI design | 17:40 |
| cjwatson | I think we should rebrand oem-config for that sort of purpose | 17:40 |
| cjwatson | but I don't think it's good to redesign the installation process for everyone based on that theory | 17:40 |
| cjwatson | OEMs installing systems that they then sell is a major case; users installing systems for themselves (and their families) is a major case. I honestly think that person X installing a system for person Y who isn't present (and so can't be called over to type in their password) is a niche case | 17:42 |
| cjwatson | I've been in the situation of being person X installing a system for person Y, but in all cases they were in the next room and I just called them over at the user setup stage | 17:43 |
| CIA-3 | usb-creator: evand * r70 usb-creator/ (6 files in 3 dirs): | 17:43 |
| CIA-3 | usb-creator: * Mark more strings for translation. Thanks István Nyitrai (LP: #310804). | 17:43 |
| CIA-3 | usb-creator: * Change the Debian maintainer to the Ubuntu Installer Team. | 17:43 |
| mpt | cjwatson, setting up multiple users is actually the exception to my one-interface-per-setup-task principle I'd be most comfortable with, because "Who will will be using this computer?" would better encourage people to have separate accounts. But Ubiquity (except with m-a) doesn't allow for multiple users *anyway*. | 17:45 |
| cjwatson | whereas I see that as optimisation for the common case | 17:45 |
| mpt | (Windows XP asks for multiple account names during installation. I don't remember what Vista does.) | 17:46 |
| evand | (we abandoned the multiple user model in m-a a release or two ago. You can only import into the account you are setting up at install, though it still supports multiple accounts under the hood.) | 17:46 |
| cjwatson | I could come down on either side of the how-many-users-during-installation question; I came down on the one-user side initially since it involved fewer interaction steps and was easier to implement, really | 17:47 |
| mpt | You mentioned rebranding oem-config | 17:48 |
| cjwatson | I agree that it seems likely to produce a different psychology, although I must say that I have never done any user observation to see how they react to it | 17:48 |
| mpt | If we did that, when and how would it be invoked? | 17:48 |
| cjwatson | (the only case I've observed was my parents, and they viewed it as somewhat ridiculous for the two of them to have different accounts given that they'd been married for 30+ years) | 17:49 |
| cjwatson | well, despite the name and modulo some details, oem-config is essentially a way to install a system but defer answers to user-specific questions until a bit later | 17:50 |
| cjwatson | so it's an "I'm installing a system for somebody else" mode | 17:50 |
| cjwatson | it is (I think intrinsically) more awkward | 17:50 |
| mpt | So do the user-specific questions appear on first login? | 17:50 |
| cjwatson | for example, you might not even have the same preferred language as the other person | 17:50 |
| cjwatson | right, the current scheme is that you install a system with a dummy 'oem' account which the OEM can use to customise things (this is the part I think is unnecessary if you're just ordinary person X installing for person Y), then after the OEM says "I'm done now", user-specific questions are asked at the next boot | 17:51 |
| mpt | ok | 17:52 |
| cjwatson | language, location, keyboard layout, user stuff | 17:52 |
| mpt | I'm trying to imagine how that would coexist on a CD where standard Ubiquity was also available | 17:52 |
| cjwatson | it does, right now | 17:52 |
| cjwatson | there's an option on the CD boot menu to invoke it | 17:53 |
| cjwatson | it's currently somewhat hidden since we don't want to confuse ordinary people into using it, since it has this customisation stage | 17:53 |
| mpt | ok, make that "coexist prominently" :-) | 17:53 |
| cjwatson | so it's on F4 "OEM install (for manufacturers)" or some such | 17:53 |
| cjwatson | how about user page has a thing at the top saying "I am installing this system for somebody else; ask me later" | 17:54 |
| cjwatson | the installer doesn't really need to know before that | 17:54 |
| cjwatson | technical effect of that would be that oem-config is installed and configured to run on the next boot | 17:55 |
| cjwatson | and I suppose no account would be created, or maybe some kind of dummy account | 17:56 |
| cjwatson | but at any rate it wouldn't ask for a password | 17:56 |
| mpt | that seems reasonable | 18:01 |
| cjwatson | NCommander: damn, didn't work, I've sent a patch to kernel-team to actually try to build udebs :-/ | 18:04 |
| NCommander | cjwatson, I can build the ARM kernel here | 18:04 |
| cjwatson | NCommander: https://lists.ubuntu.com/archives/kernel-team/2009-January/004042.html | 18:04 |
| cjwatson | if you can test that and follow up, go for it | 18:04 |
| NCommander | Sure, no problem, I can even get it merged if need-be | 18:04 |
| cjwatson | that isn't usually a problem, but sure | 18:05 |
| cjwatson | I expect all it needs is for somebody to have test-built it | 18:05 |
| NCommander | cjwatson, roughly speaking, how much work do we have in porting d-i to a new subarchitecture? | 19:02 |
| cjwatson | NCommander: d-i itself? shouldn't take more than an hour or so plus hanging around for build tests. also add whatever time is needed to write bootloader installation/configuration code | 19:03 |
| cjwatson | but actually getting the d-i build system to build for a new subarchitecture is pretty trivial | 19:03 |
| NCommander | cjwatson, I was considering packaging the freescale kernel so we could use it as a basis to port d-i so when the final kernel arrives, its a config file update and rebuild. | 19:04 |
| cjwatson | sure | 19:05 |
| NCommander | the only problem is we need a nice place to hang all the udebs and such since I don't think we want the freescale kernel in the archive | 19:05 |
| cjwatson | oh, just bung 'em in build/localudebs/ for local build-testing | 19:06 |
| NCommander | Aw, thats no fun ... | 19:06 |
| cjwatson | or put them in a temporary archive and fiddle build/sources.list.udeb.local | 19:06 |
| NCommander | *gunned down* | 19:06 |
| NCommander | I need to work out how to create a flash map with redboot first anyway; am I correct in assuming d-i knows how to handle writing an initrd to flash (I know it works right on the NSLU2) | 19:07 |
| cjwatson | I'm not quite sure how it works for NSLU2 but the usual approach is that you have a "bootloader installer" component that does the work | 19:08 |
| cjwatson | I believe that the flash-kernel package does it | 19:09 |
| cjwatson | it may need a trivial tweak | 19:09 |
| NCommander | I know d-i on NSLU doesn't touch the flash | 19:09 |
| cjwatson | or maybe not so trivial | 19:09 |
| cjwatson | d-i on NSLU2 has a bunch of code that fiddles with mtd | 19:10 |
| cjwatson | and says "Flashing kernel:" | 19:10 |
| NCommander | Well, we can get mtd going on the Babbage | 19:10 |
| cjwatson | so not sure I agree :) | 19:10 |
| NCommander | That isn't very difficult (I just need to work out the specifics of flash mapping) | 19:10 |
| cjwatson | have a look at flash-kernel, anyway | 19:10 |
| cjwatson | that's the main thing to port | 19:10 |
| NCommander | Ah, sounds like fun | 19:11 |
| NCommander | cjwatson, if you could get me a list of udebs ARM d-i wants, I can make sure they're all built | 19:11 |
| cjwatson | I'm pretty sure they already are | 19:12 |
| cjwatson | we'll find out once the kernel's in place | 19:12 |
| cjwatson | at this point it's less tedious to just test-build | 19:12 |
| NCommander | works for me | 19:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!