=== Guest33512 is now known as jalcine === jono is now known as Guest27980 [06:17] good morning [07:54] good morning Kubuntu! [08:03] \o [08:12] cmollekopf: did the packages work? [08:12] Riddell: yes, thanks [08:19] morning folks [08:21] hi tariq, how's the support website doing? anything I can do to help? [08:25] Good morning. [08:36] ScottK: did you get a chance to look at the owncloud sru? [08:57] good morning Riddell [09:01] hi shrini [09:01] shrini: did you get your install bug in or do I need to review it? [09:05] agateau: same question ⇈ [09:10] Riddell: I don't understand the question [09:10] agateau: you had a merge request for ubiquity? is that still needing review? [09:12] Riddell: I haven't received any comment, so I guess it does. Note that I pick you out of habit for reviews, but feel free to point me to someone else if you are too busy :) [09:12] that's all good, I'll get onto them === KRF_ is now known as KRF [11:12] Hello Riddell yofel [11:36] Hey all [12:05] shadeslayer_: using i-7ae84810 ec2? [12:08] Riddell, how about lang packs?:P [12:31] smartboyhw: onto them now [12:32] smartboyhw: uploading [12:37] Riddell, plz review amarok in my main PPA plz [12:37] And don't give me packaging jobs for the coming two days plz, I'm soon off to London. [12:43] London? big and smelly place, come up to Edinburgh! [12:43] smartboyhw: where's amarok? [12:43] ah found it thanks https://launchpad.net/~smartboyhw/+archive/ppa [12:52] smartboyhw: uploaded, thanks for packaging, have fun in England (but if you hear anyone say that tennis chap is English, set them straight) [12:53] if anyone complains about Amarok crashing on startup with KDE 4.11, please point them to Amarok 2.8-beta [12:53] it's no longer crashing [12:53] technically it's sort of a Plasma regression, but anyway, we are now compatible with that [12:53] yay [12:54] I wonder if we need to backport that to any PPA [12:54] markey: so amarok 2.7 crashes with plasma 4.11 ? [12:54] it doesn't [12:54] * apachelogger goes Oo [12:54] on a related note, apparently lots of KDE applications, including Amarok, are crashing on Ubuntu/Unity with latest updates. no idea why. with Kubuntu everything is fine [12:54] we have the patch for that for 2 weeks already [12:55] Riddell: yes. if you would like to backport a patch, I can point you to the commit [12:55] xnox: pingy [12:55] yofel: pingy [12:55] shadeslayer_: pingy [12:55] markey: right, what you're seeing is bug 1195007 - I think caused by fixing bug 1180067 [12:56] bug 1195007 in kile (Ubuntu) "kile crashes when click on "file new + save"" [Medium,Confirmed] https://launchpad.net/bugs/1195007 [12:56] bug 1180067 in qt4-x11 (Ubuntu Raring) "No icons on buttons" [High,Fix released] https://launchpad.net/bugs/1180067 [12:56] apachelogger: pong (more or less) [12:56] yofel: did you confirm that the qt patch is what causes the crashery? [12:56] I confirmed that upgrading *only* qt on raring makes it crash - that's as much as I had time for [12:57] apachelogger: hi. [12:58] yofel: that could be it, yes. the backtraces are usually inconclusive. just some X error and then it's crash [12:58] ScottK, xnox, Riddell: the SRU for bug 1180067 (in theory) makes all KDE software crash, it should get rolled back asap [12:58] bug 1180067 in qt4-x11 (Ubuntu Raring) "No icons on buttons" [High,Fix released] https://launchpad.net/bugs/1180067 [12:58] um, wow [12:58] that patch registers gtk's x error handler for Qt/KDE apps it seems [12:58] !regression-alert [12:58] I am seeing some 20 upstream reports already [12:58] cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [12:58] and gdk_x_error() is FATAL [12:58] spread across all of kde [12:59] so it seems that Ubuntu devs don't give a shit about Qt apps working right? [12:59] that list of people needs updating as well. [12:59] ^^ [13:00] markey: please, use appropriate language. and Qt is cared about a lot, it's pushed as the default development toolkit for ubuntu. [13:00] heh [13:09] xnox: We'll need to revert that unless you have an immediate fix. [13:09] xnox: To be clear though, Canonical is pushing Qt5, not Qt4, so that's not quite true. [13:11] xnox: The regression alert ought to be on #ubuntu-devel since most of those people don't hang out here.. [13:11] ScottK: sure, but I have no idea how to start and properly record an incident report for SRU regression. And I only sponsored that SRU for mitya. I'm not expecting gdk to error out the way it is reported to be doing. [13:12] ScottK: can you coordinate a revert on #ubuntu-devel? or what needs doing here? [13:12] xnox: No. I have $work to do today. [13:12] Since you sponsored it, please follow up on #ubuntu-devel. [13:12] Thanks. === rdieter_ is now known as rdieter [13:20] apachelogger: yofel: it seems like https://developer.gnome.org/gdk/unstable/gdk-General.html#gdk-error-trap-push could be used... [13:21] Riddell, I know, it's British rather:P [13:22] xnox: I think that has too limited scope... it would need to be ::QApplication -> trap_push; ::~QApplication -> trap_pop [13:22] (Well, you can't deny that Andy Murray is British right????) [13:24] apachelogger: if I understand it right, callking gdk_error_trap_push() right after gtk_init, should be sufficient without ever doing a pop. [13:25] apachelogger: that's the solution that libreoffice went for as well. [13:27] xnox: I am all for giving it a try, but first I would really push a revert into -updates anthen have a possible fixed fix go through proposed again [13:28] apachelogger: well Riddell wants to revert as well. [13:28] apachelogger: do that. [13:29] it has quite the sizable impact, so the longer we don't have a fix the more grumpy upstream KDE gets [13:29] Riddell: are you handling the revert? [13:31] Riddell, hmm [13:34] apachelogger: yep [13:34] ok [13:34] Riddell, ftbfs of amarok in armhf [13:35] bah [13:36] Obviously, amd64 successfully built [13:36] So um [13:36] qreal [13:36] build log? [13:36] apachelogger, not qreaal [13:36] Build dep at cmake === BadDesign is now known as Guest85226 [13:36] no, cmake [13:36] apachelogger, https://launchpad.net/ubuntu/+source/amarok/2:2.7.90-0ubuntu1/+build/4778138/+files/buildlog_ubuntu-saucy-armhf.amarok_2%3A2.7.90-0ubuntu1_FAILEDTOBUILD.txt.gz [13:36] CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message): Could NOT find Qt4 (missing: QT_QTOPENGL_INCLUDE_DIR QT_QTOPENGL_LIBRARY) [13:37] Yeah....... [13:37] Could NOT find Qt4 (missing: QT_QTOPENGL_INCLUDE_DIR QT_QTOPENGL_LIBRARY) [13:37] markey: ^ [13:37] What the hell [13:37] amarok is no longer compatible with ARM [13:37] as there is no desktop opengl on ARM [13:37] :O [13:37] well, who wants to run Amarok on Arm at this point [13:38] I do [13:38] don't think that's amarok fault [13:38] oh it needs opengl? [13:38] To be fair, not compatible with Ubuntu's Arm. [13:38] markey: easy fix would probably be to simply make the opengl stuff optional [13:39] if you care at all [13:39] I'm not sure I care that much, for the tiny amount of people trying to run it on ARM [13:39] libqt4-opengl-dev [!armel !armhf] [13:39] why is that in there at all [13:39] if it were a larger audience, then yes [13:40] it felt really good to be able to make OpenGL a hard dependency, in 2013 [13:40] apachelogger: cos it doesn't work on arm and clashes with gles [13:41] Riddell: qtopengl doesn't work on arm? [13:41] Oo [13:41] what? [13:41] oO [13:42] it doesn't from what I've seen in build logs [13:42] related note: QGLWidget doesn't work right with EGL (it crashes). that's something I'm very interested in [13:42] (at least on Gentoo it crashes) [13:44] ... [13:51] bug 707794 [13:51] bug 707794 in clementine (Ubuntu) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [Undecided,Triaged] https://launchpad.net/bugs/707794 [13:51] note a few packages are still not fixed / do not support GLES [13:52] (or have dependencies which are GL only, without GLES ports) [14:03] yofel: kf5 project-neon5-plasma-framework should be building soonishy....... if you want to give it a shot, something with the neon envrionment files is fishy as they alone do not allow me to run plasma-shell, adding the stuff form the wiki additionally makes it work [14:03] didn't work in vbox though, so I suggest native tests [14:04] http://wstaw.org/m/2013/07/05/md4.png [14:04] fun [14:05] I'll check the list of env vars again, but I thought I added everything... [14:12] apachelogger: regarding ARM, I was just reconsidering. I think I can make OpenGL optional for 2.8-final. I'll look into it tonight [14:12] ok, bbl [14:12] markey: would be very appreciated :) [14:28] agateau: on https://code.launchpad.net/~agateau/ubiquity/kde-rework-try-install-buttons/+merge/172988 ... [14:28] you add try-install.svg is that used anywhere? [14:28] or is it just the source? [14:29] Riddell: it is the source for the new .png files [14:29] no need to ship them in the deb [14:29] groovy [14:30] agateau: how did you test running ubiquity with the buttons? [14:30] * xnox started to simply use .svg files directly instead of pngs. [14:30] I tried export UBIQUITY_GREETER=1 but that doesn't help [14:30] Riddell: UBIQUITY_GREETER=1 ubiquity -d kde_ui [14:30] oh, that works for me [14:31] shadeslayer_ and yofel: What did you tell afiestas_ we thought about KDE switching to a 3 month release cycle? [14:31] agateau: hmm it doesn't work, and it runs in oem mode, wonder why that is [14:31] Riddell: haven't tried it with latest saucy, let me try [14:32] afiestas_: Do you have a sample release schedule? Perhaps you could take the 4.11 schedule and overlay it with what you'd expect if there had been two three month releases instead of one 6 month one? [14:32] ScottK: wiki page_ [14:32] ? [14:32] ScottK: I don't think I explicitely talked to afiestas_, but my position is mostly "I don't care". The schedule I saw didn't really conflict with our 14.04 plans [14:32] afiestas_: Link? [14:32] just different kde version number [14:32] ScottK: it is in the email [14:32] yofel: No, I think that's wrong. [14:32] dafuq, nobody has read the wiki or what? [14:32] Riddell: indeed, doesn't work [14:32] http://community.kde.org/KDE_Core/ReleasesProposal [14:32] Thanks. Looking [14:33] it doesn't conflict but I'd like to look at it for cadance, each SC release takes a long time to package [14:33] xnox: did anything change wrt the UBIQUITY_GREETER env variable? [14:33] if anything the support duration for bugfixes would be an issue [14:34] agateau: not that I know. I usually go to tty1, stop lightdm; stop ubiquity; pkill -9 X; update files in place; start ubiquity: to see the greeter again. [14:34] * agateau investigates [14:34] agateau: we now use pkexec, which clears environment better I think, instead of kdesu / gtksu /sudo [14:35] afiestas_: any reason why you went with 2 point releases for .13 and 3 for .14? Because we won't care much about .14 from what I see [14:35] xnox: ah, could be it [14:36] Looks like 4.13 would release ~a week or two before "T" feature freeze. [14:36] That's substantially later in the cycle. [14:37] xnox: Riddell: there is a "-g" option for the command line, which works for me [14:37] yofel: that image is a sample [14:37] it will continue as long as it takes us to release kde5 [14:37] agateau: oh nice [14:39] afiestas_: sure, but as we don't push new features out as updates, if we release with .13 in april, and you then focus all your fixing attention to .14 until frameworks is done that's not really great for us [14:40] yofel: right, I want us to develop a script or something you guys can use to keep branches alive, and do further releases [14:41] if we had a site for example, listing bug fixes for example, you could easily backport those and we could do more releases [14:41] pretty much like we have done with some 0.5 and 0.6 that were not shceduled [14:42] Which might work, except with more releases, different distros will target different releases and so you end up with double the work. [14:43] accorcing to the release team (which I plan to join to help them) it won't be that much work [14:43] since point releases are almost automagical [14:43] as long as we have people caring about them [14:43] we have an issue now, that is impacting you (distros) and it is that nobody testes stable branch [14:43] Agreed. [14:44] so we need people that will take "maintainership" of these branches [14:44] What's why we put the point releases in a PPA for people to test before we put them into the regular updates cycle. [14:44] and ofc we need to make life easy to these maintainers [14:44] Right. [14:54] agateau: getting icons back on the buttons would be a nice addition if you happen to be still in ubiquity mood :) [14:54] afiestas_: on the stable branch topic: how can I list all commits done to 4.10 since it was branched? (that means including commits from all repositories that had commits to KDE/4.10 and including the svn branch) [14:55] agateau: 1 merge merged and 1 merge commented although I think a comment from a ubiquity gtk person on the splitting one would be needed before going ahead [14:55] Riddell: thanks! [14:55] Riddell: will look into the icon issue [14:55] Riddell: it's new to saucy, isn't it? [14:55] agateau: I think those went away when I switching it to a QApplication a couple of cycles ago [14:56] had to get rid of KButton [14:56] Riddell: there are icons on button here: http://agateau.com/2013/04/11/hacking-on-ubiquity/ubiquity2.png [14:57] agateau: hmm, but on when I run it on my installed saucy system, I wonder what's going on [14:58] yofel: yes, even though the idea is to make it even nicer [14:58] something like [14:58] that's why I think it's a regression in saucy [14:59] a website or something [14:59] or even with email alerts to kde-packagers [14:59] right now that's done manually I think [14:59] (with a CCMAIL) [15:03] afiestas_: right. I would be even happy with a seperate ML for all stable commits. I gave up on trying to filter kde-commits. [15:03] But yeah, if we could have some kind of notification that somebody fixed something in a stable release (esp. post-last-point-release) that would be incredibly helpful [15:04] yofel: please, send that kind of feedback to kde-core-devel thread [15:04] so we can add it to the proposal [15:06] right, will do [15:08] agateau: just tried 13.04 on a virtual machine and the icons aren't there http://starsky.19inch.net/~jr/tmp/ubiquity.png [15:09] Riddell: I wonder if this could be linked to running ubiquity from the live session versus running it from the dm [15:10] Riddell: that is: do you get icons if you select "try kubuntu", then start ubiquity from the desktop icon? [15:15] agateau: let me try [15:17] greaaaaaaat [15:18] any ideas where to debug when pc suddenly shuts down by itself and I get no messages after reboot? [15:18] Quintasan, :I [15:18] No.:P [15:19] I'm praying it's the hdd but who the hell knows [15:22] agateau: yes exactly right [15:23] agateau: icons show when in live session then ubiquity but not standalone ubiquity [15:24] Riddell: in raring, I changed code to use QIcon.fromTheme() instead of hardcoded full paths, that must be the reason why [15:24] My guess is the theme is not set when ubiquity is running standalone [15:24] yeah, I wonder how that gets set [15:24] must be something in QIcon that does it [15:27] mmm, maybe qapplication does not detect the environment it is running on and cannot pick a theme [15:27] which would make sense because there is nothing kde running at this point [15:30] anyway, I don't get icons at all on saucy :/ [15:32] ScottK: "Either they do have to change and do releases every three months or elements [15:32] of the SC get skipped on some releases." [15:32] who is they? [15:32] as I understood: e.g. kdepim [15:32] tsdgeos: In this case it's kdepim. [15:32] kdepim doesn't do any release [15:32] the release team does [15:33] all they do is increase a version number when we send them an email [15:33] Right, but their repo has to be in a releasable state. [15:33] they release features - aligned to the schedule the release team sets [15:33] ScottK: repos *always* have to be in a releaseable state [15:33] There are rules about when features can land, string changes, etc. [15:34] So I don't think it's right to suggest that changing the release cadence won't affect them. [15:34] you sound like a spanish politician :D [15:34] but it's on the constitution! [15:35] ScottK: is people suggesting it won't affect them? [15:35] That's how I read afiestas_' email. [15:36] "You don't have to change the way you work because of this." [15:36] and you don't [15:36] noone follows the damn freezes anyway [15:43] * ScottK gives up. [15:43] ScottK: see how laurent says "i just commited a feature for 4.11" [15:44] what? why? how? [15:44] feature freeze was months ago [15:44] I agree. [15:44] he doesn't understand than a shorter release cycle will be better for him [15:44] because he won't need to "do it now or wait 6 months to get it released" [15:44] it'll be "do it now or wait 3 months to get it released" [15:44] so he'll wait and do it proprely [15:45] ScottK: giving up is what happens when someone proposes change, because people just say "it's not what we do" without even thinking about it [15:45] No. [15:46] Its' when someone says two things that can't both possibly be true and people continue to claim it is.. [15:46] Either I don't understand or people are just pushing for change no matter the consequence. I don't know which this is. [15:47] people are pushing? [15:47] i only see afiestas_ :D [15:48] ScottK: you didn't give much info on why kubuntu had problems either [15:48] "Let's not do it again" [15:48] Like I said, I don't see how it's possible to both not affect developers and release twice as often, but that may be just me. [15:48] seems like a "no because no" [15:49] I think the problems with kdepim were felt by many distros and we discussed it at the time. [15:49] kdepim in 4.7 was buggy, really buggy, seriously. And looking back I regret uploading it back then [15:49] IIRC Fedora people like rdieter objected even more than we did. [15:49] we lived through it, but I would very much like to not have something like that happen again [15:49] and that has to do what with this? [15:49] if 4.7 was buggy [15:50] its code should not had been merged [15:50] yofel: Agreed, but I was talking about 4.5/4.6 where we had no pim. [15:50] ARGH [15:50] ah [15:50] It was always hard to figure out what pimlibs went with what. [15:50] right, it was out-of-schedule back then [15:51] tsdgeos: ^ and that's the thing we fear. If people start making changes thinking "they have until the next cycle", then things can either be better because they're better tested, but they can also get worse because we get an even larger untested code chunk [15:51] no idea what the best way to prevent that is though [15:52] yofel: how there can be a larger untested code chunk if there's half the time? [15:52] people is going to chunk code faster magically? [15:52] tsdgeos: I meant if they skip a release [15:52] i.e. a feature is still developed for half a year, not in 3 months [15:53] like kdepim did with their rewrite from 4.4 -> 4.6 [15:53] yofel: you *can't* skip a release [15:53] kdepim did [15:53] *did* [15:53] that's a good keyword [15:53] All I was saying is we tried skipping and it was painful. [15:54] no [15:54] you said "Let's not do it" [15:54] I have a tendency to expect people to do something again if they do it once. If you plan to prevent it: *great*, but understand that I'm skeptical [15:54] True. [15:54] OK, I said we tried skipping and it was painful, let's not do it again. [15:55] i don't unerstand what you mean by skipping [15:55] but if you mean a module not being released [15:55] that's not going to happen [15:56] That's what I mean. [15:56] if you mean kubuntu not releasing something [15:56] that's your issue [15:56] Sure. [15:56] I mean a module not being released. [15:56] ScottK: that won't happen [15:56] note that I count "a module not merging any feature branches for a release", skipping a release too in that context [15:57] it can happen that some developer decides to work on 6 month cycles, mergin features using that timeline, but the module will be released anyway [15:57] using the example in kde-pim, 4.12 will contain my kde-accounts patches, but won't contain some laurent features because they won't be ready [15:57] but in anyway 4.12/13/14/15 will be released [15:57] yofel: why? [15:58] you are going to force people to develop stuff? [15:58] yofel: I disagree with you there. [15:58] tsdgeos: what would have prevented you from calling "kdepim 4.4.11" "kdepim 4.6"? [15:58] 42 [15:58] what kind of question is that? [16:00] nvm me, maybe my trauma from kdepim 4.6 was just too large so I'm unable to be properly objective here. [16:02] tsdgeos: I'm just scared about a "feature" getting too large (e.g. kdepim rewrite) so it's not going to be properly stabilized in *one* kde release timeframe (including point releases). [16:02] But I guess there's nothing one can do about that [16:02] Are we going to push 4.10.5 to raring? [16:03] Quintasan: yes [16:03] Quintasan: Are there positive test results from PPA users? [16:03] Riddell: did you apply those kolab patches to the SRU packages too? [16:04] ScottK: From me - it works [16:04] ScottK, soee did report that 4.10.5 was good here... [16:04] I can get someone else to test [16:04] Any bugs on ~kubuntu-ppa that need review? [16:04] yofel: i should have done to all the PPA versions yes [16:04] If not, then I think it's fine to push it to -proposed. [16:05] yay [16:05] Quintasan: bug 1198754 needs looking at possibly [16:05] bug 1198754 in Kubuntu PPA "Please pull rev ec8e405c to fix memory leak in 4.10.x" [Undecided,New] https://launchpad.net/bugs/1198754 [16:05] e.g. 4.10.5 has them here https://launchpad.net/~kubuntu-ppa/+archive/ppa/+packages?field.name_filter=kdepim&field.status_filter=published&field.series_filter= [16:06] Riddell: ok, thanks! [16:10] yofel: We should definitely have that. [16:13] right [16:14] Quintasan: mind cherry-picking that? If you have no time I'll do it later [16:42] How hard would it be to have a PPA that did a recipe build on change for the stable branch? [16:42] People interested in the latest stable/testing could run that and it would be reasonably safe. [16:44] ScottK: on change of anything in stable branch? [16:44] yes [16:44] Hmmm [16:44] a neon-stable [16:44] Except I don't think it would need to be separate packages like Neon is. [16:45] Riddell, ScottK: Any ideas on why we have firefox-locale-en on the CD? [16:45] Quintasan: No. [16:45] Or it's quite possible the installer pulled it with internet connection [16:45] ScottK: I think I already explained that to d_ed on kde-quality or so a while ago. Essentially: imports of all stable branches + our SRU packaging in branches + recipes for that [16:46] yofel: Yes. [16:46] not too much work, but still enough that I want to have a confirmed userbase before doing that [16:46] I'm thinking if we did that, maybe we could send a point release straight to proposed since we'd have tested it already. [16:46] hm, good point [16:47] So it would ~replace the updates PPA. [16:48] Hell, I could run taht [16:48] Yeah. [16:48] * Quintasan was running neon [16:48] so why not [16:48] I have a recipe creation script in the neon tools, that would have to be extended to run on the whole KDE SC [16:49] then we need a name pattern for the SRU branches [16:49] import creation and recipe creation script that is [16:49] apachelogger is our namespace master, right? [16:49] right, at least he's better at that than I am ^^ [16:52] In any case, something like this could help with the "no one tests stable" problem, regardless of if the release schedule changes or not. [16:57] * Quintasan whines [16:57] This !@#!@%! PC [16:57] When I want to debug this bastard - everything works [16:58] When I was to do anything - shit hits the fan [16:58] want* [16:58] sounds familiar [16:58] At least I have an SSD now [16:59] I can finally kill the only PATA drive now [17:00] bbl [17:01] Can someone test the qt4-x11 in raring-proposed? [17:01] Is I can get a positive test, I'll release it once it's built on all archs. [17:02] presumably testing with unity is what's needed [17:02] True. [17:02] xnox: ^^^ [17:02] * ScottK will be away for awhile. [17:09] ScottK: Riddell: I don't have access a raring instance. I would have thought the testing that needs to happen is that kile doesn't crash with empty config. [17:09] xnox: But not in Kubuntu. In Unity. [17:09] oh... wait, yeah under !kde [17:09] Can you find someone to test? [17:10] ScottK: there are many "me too" on bug #1195007 [17:10] bug 1195007 in qt4-x11 (Ubuntu Saucy) "kile crashes when click on "file new + save"" [High,Confirmed] https://launchpad.net/bugs/1195007 [17:10] xnox: I need to leave and I was hoping someone would get it tested so I can release it when I get back. [17:11] ScottK: is there an "SRU accepted template" / call for -proposed testing that you can post there? [17:40] ScottK, yofel: namespace for what? [17:43] SRU branches for KDE SC packages. [17:44] LOL [17:45] yofel: I copied Win7 partition from my HDD to SSD, now I have two grub entries, doesn't matter which I press it still boots from the hdd xD [17:45] xnox: https://bugs.launchpad.net/ubuntu/+source/kile/+bug/1195007/comments/10 [17:45] Launchpad bug 1195007 in qt4-x11 (Ubuntu Saucy) "kile crashes when click on "file new + save"" [High,Confirmed] [17:55] ScottK, yofel: ~kubuntu-packagers/kubuntu-packaging/phonon-raring in case you mean the packaging [17:56] Quintasan: doesn't seem like you migrated the win7 boot manager entries properly [17:56] yofel: This retarded software overwrote my Kubuntu partition on SSD :D [17:56] lol [17:56] Even though I specifically asked it to restore it to the second paritition [17:57] The biggest problem with win7 is that the installer is so retarded it won't install unless your hdd is master on the first channel and you install it on the first partition [17:58] * yofel never touches win7 unless he has to [17:58] actual my notebook's win7 install is still on it's own HDD, I simply switch the disks out when I need it [17:58] lol [17:58] well, that's a solution [17:58] I actually need to do someting about my disks [17:59] I have overlapping partitions somehow [17:59] there was a grub2 bug where e.g. photoshop overwrote parts of the boot manager data (well, the win7 boot manager doesn't put data there so it's fine right?) [17:59]