[00:00] http://wstaw.org/m/2013/03/02/plasma-desktopqc2250.png [00:01] how did we end up going back to grey background? [00:01] not that it looks bad though [00:01] * yofel is tired of launchpad erroring out on him *-.- [00:03] yofel: ask sheytan [00:03] at this point I do not even care no more [00:04] this still has to transition to blue at some point... [00:04] * yofel throws 500 errors at launchpad *-.- [00:07] http://wstaw.org/m/2013/03/02/plasma-desktopRb2250.png [00:07] yofel: try 404 :P [00:07] yofel: also why blu? [00:07] our desktop background is blue? [00:07] not really [00:07] it has blue [00:07] it is every color of the rainbow [00:08] plus loads of dark [00:08] it feels as blueish as it hasn't done in a long time [00:08] blue is all in the mind it seems :P [00:09] did I mention that 2 users looks fucked up due to imbalance [00:16] ohm [00:16] somehow it seems the spacing in the current lightdm theme is fucked [00:17] the userlist+passwordinput+sessiondropdown is not layouted as one block of foo but instead the passwordinput is in the absolute center and the other crap is relative to it [00:17] which makes the entire thing slightly oriented to the top [00:20] this code is a weee bit crappy [00:21] at least it's not python [00:23] http://wstaw.org/m/2013/03/02/plasma-desktopdn2250.png [00:23] I sure hope that was also intentional in sheytan's mock [01:00] http://wstaw.org/m/2013/03/02/plasma-desktopJZ2250.png [01:32] running lintian over all KDE packages is... interesting [01:32] ^^ [01:35] ok, status page fortified against launchpad failures and linitan output added [01:35] now to wonder why launchpad fails in the first place... [01:36] oh, it stopped failing [01:36] perfect timing....... [01:58] W: kde-workspace-randr: empty-binary-package [01:58] o.O [02:13] so many colors [02:13] -.- [02:13] * apachelogger feels like blogging about rolling [02:17] too much red on that page -.- [02:23] * apachelogger decided not to blog about rolling [02:24] there is nothing to blog about [02:24] * apachelogger ponders making a graphic and simply post the graphic as a blog post [02:24] Scott said what was to be said [02:24] we don't know more yet to say anything more [02:25] ScottK's wrong because he was not listening to me yesterday :P [02:26] also unless I am mistaken there is no concensus as to who is the target audience of the rolling release yet [02:26] is it devs, or is it geeky users, or the regular john doe [02:26] no one knows [02:27] pretty much [02:27] and to that extent what really is important there ... what degree of assumable breakage can this audience face [02:28] and that is really fundamental to outlining exactly what a package distribution flow needs to look like in terms of pre-rolling-archive QA [02:28] BUT [02:30] why I think ScottK is wrong is because mostly we are doing a rolling workflow with the SC already [02:30] with a binary rolling distro you need a staging ground so that all SC binaries are built and can be published *as a whole* to a public archive [02:30] not quite [02:31] he did say that our rolling workflow is currently opt-in to users [02:31] what ubuntu plans isn't [02:31] it doesn't matter [02:31] also ubuntu's rolling is [02:31] either use LTS or use rolling [02:32] erm, it's LTS or use rolling-montly or use rolling-daily [02:32] what ScottK decides to completely ignore is that by not having intermediate Kubuntu releases we free up resources to provide intermediate SC releases to an LTS release [02:33] that only works as long as backports are feasable [02:33] we have no plan on how to distribute the thusly formed new product, but that is really just a either this or that decision [02:33] there is no policy making involved there [02:33] yofel: when do they become unfeasble? [02:33] though I saw something called cxx11-cmake-modules today so maybe I worry too much [02:34] apachelogger: stuff like things becoming unbackportable [02:34] like JontheEchidna not supporting gcc 4.6 [02:35] stop pushing updates? [02:35] as long as we can somehow keep moderately-adventurous users up-to-date on the LTS for 2 years, we should be able to work out the rest [02:36] nah [02:36] wrong thinking again [02:36] sure one would have to stop. But providing 4.11 on rolling-only isn't something that I really like [02:36] we do not know what the target audience of rolling is [02:36] so supporting anything but an LTS user on LTS is right now no concern [02:37] hum [02:37] so I agree, that is an issue, it's more of an upstream issue though [02:37] we can't quite say that without knowing the target userbase :/ [02:37] if an upsteram decides they do not want to support 1 year old software for the lulz of it that is their right, however our position towards that upstream probably ought to be reconsidered [02:39] heh, what I would really like are commit-info mailing lists for kde stable branches, then us distros can keep sharing fixes there when upstream stops caring [02:39] which reminds me that we need to check debian for 4.8 fixes at some point [02:39] I was under the impression we hae that [02:39] we do? all I know about is #kde-commits [02:39] commitfilter.kde or something [02:40] should go into projects.kde at some point I reckon [02:40] looking at it [02:40] at any rate, there is server-side infrastructure due to irc commit stuff [02:41] so if comitfilter is not working anymore I guess making a new thing is really just a matter of writing a simple webui with rules and have a hook send mails accordingly [02:42] back to the rolling thing though..... there is a close to nothing difference between what we do and what we would end up doing [02:42] stuff goes into ninja -> inital binary staging (such that one has a consistent binary stack) + inital limited QA [02:42] well, leaving kde betas aside, that's true [02:42] talking stable [02:43] once packaging is done... [02:43] in fact, KDE itself is really not the worst issue here. More worrying is the base system and toolchain transitions [02:43] it moves to archive (if archive targets people who can live with the odd upgrade breakage) [02:43] if it is not for archive it goes into testing (new ppa) [02:44] once we are happy with it, it goes into archive (guess that's about a week or so) [02:44] now with betas/unstables it is really the same process [02:44] except it again depends on the audience of the archive [02:45] yeah [02:45] if they can live with the odd crash in not-so-stable software it goes in the archive, otherwise it goes into the experimental ppa for example [02:45] and here is the thing ... putting it in a ppa when the archive is not the place to put it due to the audience it does not change the way we get testing [02:46] right now you can be using stable and need to opt into beta-backports [02:46] OR you have opted into using raring in which case you again willingly opted for a testing platform [02:46] what we would loose are the dev release users that we could force beta packages onto [02:46] though... [02:47] those would probably add the PPA anyway [02:47] in a world where the archive is always targetting a semi-end-user-ready state you'd be able to run LTS and opt into testing (given backportibility is given) OR run rolling and opt into testing (via ppa) [02:47] at the end of the day a user will have to opt into beta testing as they have had to do for years already [02:48] yofel: yeah, but really you are not forcing something onto people that were not willing to live with the brokenness and help make it go away [02:49] I mean, perhaps you have the odd user that wanted to try it and will never do it again because in feburary the x team decided to break nvidia compat and he can't play tf2 anymore [02:49] what I am saying is [02:49] a raring user may not have agreed explicitly to testing the 4.10 prereleases, they did so implicitly though [02:50] fun part here is that the X team wouldn't be allowed to do so anymore [02:50] yeah [02:50] a fact people apparently also decide to ignore [02:51] they try to fix/discuss kubuntu's problems because the other teams apparently do not see it as a problem they will face :S [02:52] yet we are really in a fantastic position because we have the workflow pretty much ironed out already, it is only a matter of which path a package will have to take given the target audience of the archive [02:52] really? I don't think people dispute over the benefits. Those are clear. The problem is the missing technical details of the implementation and that nobody looked at the problems of the non-core teams [02:52] IMO pitty summarised out issues pretty well [02:52] or at least the ones I was worried about [02:53] haven't read any mail in detail [02:53] so I'd not comment on that specifically [02:53] s/pitti/slangasek [02:53] overall it feels like the non-canonical stakeholders other than kubuntu (thanks to ScottK!) are not really trying to make their concerns heard [02:53] http://paste.kde.org/685202 [02:53] (or perhaps they have no concerns, who knows) [02:54] non-canonical stakeholders other than Kubuntu are all muppets [02:54] actually scratch the last point, we just talked about that [02:54] if that is true it makes me sad [02:54] yofel: yeah, and the other stuff is arm [02:55] which is really the only issue we have from a testing&staging perspective [02:55] also ddebs [02:55] it's true though. The ubuntu community has become pretty stale recently [02:55] I think having a "release" with current KDE is important. [02:55] And backports is not the answer. [02:55] Many teams feel kind of zombie like, and the folks in #ubuntu+1 are pretty much the same ones I've known for years [02:56] Well Mythbuntu, Ubuntu Studio, Edubuntu, and Xubuntu are all kind of on life support. [02:57] Not a lot of diverse developer participation. I think we have more than all of them combined. [02:57] ScottK: why is backporting not the answer though? [02:57] The official rule we have for backports is no new versions of libraries. [02:58] ah you mean official backports [02:58] yes [02:58] ScottK: wouldn't it be ok if we took one of the post-KDE release good ISO images and marked that as usable? Or would that be too close to Arch? [02:58] yofel: Then users are still stuck on rolling. It's not a release. [02:58] hm [02:58] It's just like another beta image. [02:59] hm [02:59] If Ubuntu goes LTS + Rolling, what that really means is LTS + dev release. [02:59] yeah [02:59] my problem with KDE "releases", is that upstream really totally doesn't care about release-1 [02:59] Hi. Developer from Ubuntu Studio here. Yes, Kubuntu seems quite big, but the focus on development is quite different for different flavors. For Ubuntu Studio, the desktop makes less difference, while just having a decent kernel already makes a world of difference for us. We're flexible in this way [02:59] So if you want to give someone a stable release it's LTS + stuff. [02:59] so a release looses a lot of its worth half a year after it's out [03:00] ScottK: I find that a pleasing thing TBH [03:00] yofel: Right. I was thinking we might support a year instead of 18 months for non-LTS. [03:00] we get to put neat new KDE stuff on a constantly maturing base [03:00] so to me that seems like a good thing [03:00] I would think however, that if a rolling release is in question, it should be in everyones interest to have good quality packages. And the ones flavors care about aren't necessarily the same as flavors care about [03:00] Then we're at most n-2 for supported releases which is what officially gets security support from upstream. [03:01] Sorry, Canonical vs flavors [03:01] Some kind of buffer is needed [03:01] zequence: That's true, but given the claims of stability and consistent usability for this rolling thing, it's really not clear how to do development in it at all. [03:02] zequence: Ubuntu desktop and Ubuntu server are flavors too. [03:02] Just Canonical sponsored ones. [03:02] ScottK: as I see it the release buisness first needs to be decided by us though ... in terms of which route we want to go ... because simply using PPA backports has served us well and is straight forward ... taking LTS and pack a new KDE ontop of it is also nice but more work [03:02] one question I didn't see an answer on the list about was kernel testing [03:02] i.e. [03:03] apachelogger: Yes, but we never needed to do base an official release on that, so it's a bit more than we've done. [03:03] I'd be surprised if the kernels would not be dealt with differently on a rolling release [03:03] yofel: It was asked and there's a spec for next week on how kernel transitions will be done. [03:03] do we actually want intermediate releases with supported aligned to upstream (dropping the LTS idea) or do we retain the LTS idea and allow users to put a new KDE SC on top of the LTS base [03:03] ScottK: well yeah, we'd organize our own release [03:03] ScottK: ok, I saw the question, but obviously missed the spec [03:03] and do it basically [03:04] They simply must keep some kind of testing repo. Call it experimental, or whatever [03:04] yofel: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-rolling-kernel-maintenance [03:04] thanks [03:04] hm, got renamed... again [03:04] anywho [03:04] Lovely [03:04] all I am saying is that we need to mae a decision on this topic first [03:05] https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-rolling-kernel-maintenance [03:05] apachelogger: We definitely need to do that. [03:05] then draw requirements from that [03:05] like if we want to roll ontop of LTS perhaps a kubuntu-specific pocket would be possible [03:05] This is why I carefully phrased my last reply as a personal opinion and not something Kubuntu had settled on. [03:05] https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-rolling-kernel-maintenance [03:05] ah, zequence was faster :) [03:05] so our backports woud be in the archive but not in the regular backports [03:06] I love how for all the crap emails I get from launchpad, it doesn't send the one with the new URL. [03:06] apachelogger: New pockets are kind of really hard. [03:06] <3 lunchpad ^^ [03:06] ScottK: just an idea [03:07] Yeah. Someone else suggested it in the threads in a slightly different context and cjwatson ran screaming into the night. [03:07] pocket names are apparently hard coded throughout the LP codebase. [03:07] I personally would have no problem with doing it via PPAs either, given the size of our team that is also doable for the forseeable future [03:07] ScottK: big surprise there ^^ [03:07] I'm not sure if a blessed non-virt PPA or a full LP derivative distro are the best ideas. [03:08] Neither are mirrrored. [03:08] But that's implementation details. [03:09] yeah, also at least I do not know the involved software enough to make educated guesses about what would be easiest to achieve with greatest gain [03:09] I mean, one coudl perhaps also nicely ask mirror providers to mirror the kubuntu-ppas (for example) [03:09] The derived distribution function is what Canonical uses to roll their own OEM variants. [03:10] You get a whole derived distro release that you can sync to like we do from Debian or upload directly to. [03:10] *nod* [03:10] We could probably automate SRU and security update copies from the LTS. [03:10] Then whatever we put on top of that is really up to us. [03:10] Are you talking about keeping the entire flavor in a PPA, and have ISOs generated from that? [03:11] we are talking about whether or not to do releases with the LTS foundations and a more recent KDE ontop [03:11] hmm, wait, I'm forgetting about the repos now :P [03:11] nothing more than that :P [03:11] zequence: It's either LTS repo + PPA for our stuff or a full derived distro, which is not a PPA, but more - you will have never seen it as they aren't public (it's only due to very odd circumstances I've seen it) [03:12] ScottK: you spied someone's laptop at uds didnt ya :P [03:12] No. [03:12] that's probably why they stopped doing udses [03:12] I got invited to participate in beta testing an LP thing. [03:12] canonical employees were always reading internal mailz during talks [03:12] Because I was a !canonical archive admin [03:12] ah [03:13] I like my uds conspiracy theory better though [03:13] ^^ [03:14] ScottK: oh btw, we did a testing mumble setup yesterday, mumble should be good to use for uds [03:14] I do know lamont has a very spiffy light polarization screen he pulls out if he's sitting in a session next to you and he doesn't want you to see his screen. [03:14] Great. [03:14] also the client has builtin recording so that is reather nice [03:14] Nice. [03:15] oh and shadeslayer was trying to use juju to auto-deploy a configured mumble to ec2 [03:15] so we could actually do voip whenever we want to ^^ [03:17] Handy. [03:17] IIRC mumble has a security record that doesn't inspire confidence for leaving it up and running. [03:17] Or maybe I'm thinking of something else. [03:17] How would this work for you? All updated packages end up in a buffer repo, something like -proposed, and if any problems are found, flavors are able to freeze them. I'm pretty sure the packages that flavors care about in this context would not stop Canonical to keep developing Ubuntu in whatever way they want [03:18] zequence: For Alpha 1 and Alpha 2 we did put migration blocks in place. [03:18] zequence: that fails the moment we have issues with enthusiastic X updates from canonical [03:18] It did affect packages they care about, but not for very long, so they were OK with it. [03:18] ScottK: seems to be somewhat popular with the gamers short of getting expensive TeamSpeak3 licenses, so I'd at least hope it has somewhat sane security ^^ [03:19] How much do gamers usually care about security? [03:19] but yeah, for us it makes no sense ot have it running all the time anyway, so... ^^ [03:19] I'm sure mumble is fine. [03:19] ScottK: gamers usually use hosting services, those probably care [03:19] this could also be expanded to them keeping two repos. A dev repo, and stable rolling release repo, which would not be updated as aggresively [03:19] ScottK: i.e. specific mumble hosters actually [03:19] gamers are really lazy ^^ [03:20] zequence: not sure if that is much more than the raring + raring-updates + PPA proposal [03:20] apachelogger: btw. do you still need the database? [03:20] or did you guys redo the setup? [03:21] I didn't redo it, you coudl simply tar it up and put it on people.ubuntu.com in a .foo folder or something [03:21] lol - http://hellenicpolytheist.files.wordpress.com/2012/07/killer_whale_eating_penguins-jump-in-air.jpg [03:21] in case shadeslayer wants to try deploying it [03:21] See Alan Bell's mail to u-devel. It's pretty decent. [03:21] though since he is out of office I am not sure that is gonna happen soon ^^ [03:22] yofel: I think the main difference would be that the community needs to have a stronger veto in stopping updates, when needed [03:22] zequence: I can stop any update in the archive right now. [03:22] yofel: zequence has a point in that technically other teams will need a setup like ours [03:22] What it takes is being on the release team, doesn't matter who you work for. [03:23] namely what I was raging about earlier what with other teams apparently not caring [03:23] It is somewhat different as it's not like Xfce or Lxde have libs used by a lot of third party apps. [03:24] well, ubuntustudio were the only ones beside us to comment, true [03:24] Our problem right now is definately a lack of developers. None with upload rights, etc. But, a couple of us are moving towards that. [03:24] I think studio is primarily focused on a kernel and it's a separate one. [03:24] I'm currently the maintainer of linux-lowlatency. I however am not doing the dev release kernel yet [03:24] xfce or lxde would still be affected by the gtk backportability discussion [03:24] ScottK: Alan's mail caues QA boners [03:24] yofel: Not going in official backports, so it needn't affect them. [03:25] We depend on desktops too, of course, but we don't focus on making them stable [03:25] :-) [03:25] hm ok, true [03:25] not so efficient though unfortunately [03:25] 1 month set testing is *a lot* of time [03:26] I think for other flavors, the change has been very sudden, and they haven't had the time to react properly [03:26] and chances are there will be at least one package every month that has had a somewhat sizable regression [03:26] isn't what Alan wants kinda gentoo-like? put everything in testing and mark stuff stable after a while? (except gentoo doesn't do it based on date) [03:27] zequence: really? the rumor was there for a while now. Maybe everyone tried to ignore reality ^^ [03:27] yofel: I think people were expecting a change for 14.04 [03:27] Not 13.03 [03:27] yofel: oh, I read it as the entire snapshot gets rejected [03:27] per-package makes somewhat more sense [03:27] zequence: that is right (same for us actually...) [03:28] however that allows for kabooms in terms of KDE SC [03:29] say somestuff fails QA and doesn't get in but a new amarok gets in, but the new amarok really runtime depends on somestuff, so you have a somewhat defunct amarok now [03:29] apachelogger: well, he was esp. against snapshots. He wants to always be 1 month behind, not shift between 1day and 1month all the time [03:29] though tbh runtime stuff is a qa nightmare anyway ^^ [03:29] the same point was made for security updates that depend on a newer lib [03:31] which really only works if you rebuild stuff for rolling-stable as cherry picking binaries simply won't work [03:31] and you have one more release to provide security updates for [03:31] as I see it what you cut off in 'backlog' support overhead you get in horizontal overhad [03:32] in a previous job of mine we had basically a rolling release kind of thing and for the sake of QA we basically rebuilt the entire archive *at least* once a day [03:32] and at that point we did not even have security stuff to handle [03:33] ... [03:34] as I see it you either risk temporary screwery in the rolling and hope you can react fast enough to fix it or you prevent it by chaining autoQA until you are confident this will not break stuff (like say it will remove half the system because of a wrong dep) [03:35] latter of courese requires quite a bit of juice ^^ [03:36] and as far as autoQA goes IMHO you'd want binarystaging -> optin testing -> binarystaging -> rolling [03:36] in tersm of pocket movement [03:36] why binarystaging twice? [03:37] because of the case where X and Y get staged, and build but Y fails QA, so you want to restage X [03:38] in particular you'd actually want to compare the binary results of staging1 and staging2 and only pass the package into rolling if they match! [03:38] however out of experience I can tell you that this is not practical ^^ [03:38] software often embeds timestamps in the binary [03:38] in fact gcc does so via the buildid [03:39] but think amarok ... it contains the data it was built in the about dialog [03:41] so practically you stage twice to ensure that whatever happened between staging1+testing and now did not break it [03:42] I get the restaging point, that makes prefect sense. But I'm not too sure why you would even try the binary comparison [03:42] runtime crap [03:42] as I said it is almost impossible to pick that up reliably [03:43] so we looked into the simplest of things.. check if the binaries are the same, even though that really turned out to be the most complicated of things ^^ [03:43] ah, also space reasons [03:44] if the builds are all the same you only need to archive the binaries once [03:45] which was kind of a big concern given that the entire package pool was rebuilt regularly, so there was massive amounts of binary duplication [03:49] anyway [03:49] for sheytan's new lightdm thingy we need a qml plugin [03:50] fortunately that plugin will only expose one already existing class [03:50] so yay [03:50] sort of ^^ [03:50] anyway's the key word. It's almost 5 am and I'm falling asleep on the keyboard, so good night folks [03:50] no clue how he wants to make that coherent with plymouth though [03:50] the background is all sorts of complicated [03:50] (can't even get it to scale the same in lightdm and ksplash right now -.-) [03:51] yofel: oh, yes night [03:51] * apachelogger should go to bed too ^^ [03:55] One simple reason why I haven't posted more on the ubuntu-devel mail list is simply because it's moderated [03:56] That's a little annoying actually [06:16] B [06:18] How do I enable "set date and time automatically" in adjust date and time? I keep gettiing the error "Unable to authenticate/execute the action: 6, [06:53] 21:54 < ScottK> non-canonical stakeholders other than Kubuntu are all muppets [06:53] really? :( [06:53] I haven't heard much out of anyone else. [06:54] I posted a bunch of harsh stuff against the project to ubuntu-devel yesterday [06:54] and made some private mails to some folk at canonical. [06:54] It's possible I was over generalizing. [06:55] but they just try to wash it off with some vague corporate bullshit political generic empty responses [06:57] I wish I knew who of the Canonical people actually believes what they are saying and how many are staying on message because they've been told to. [06:58] well you have people like steve and colin who believe in what they do and I believe what they say, but I can also tell that they're spending lots of brain resources working on rationalising it and trying to align things to keep it true for them === Jacky is now known as jalcine === blaze` is now known as blaze === blaze is now known as Guest8690 === blaze` is now known as blaze [11:53] sheytan: http://wstaw.org/m/2013/03/02/plasma-desktopJZ2250.png [13:01] * smartboyhw says hi [13:01] Sorry yofel, forgotten to do `bzr add` yesterday:P [13:01] * smartboyhw proposes an immediate fix [13:02] BTW when did we have a trello board!? [13:02] since a few days ago [13:02] ^^ [13:04] how does this happen... [13:04] W: kate-data: icon-size-and-directory-name-mismatch usr/share/icons/oxygen/16x16/actions/debug.png 22x22 [13:05] yofel, what the..... [13:05] I added a full blown lintian check on all kde sc packages. The results are... interesting [13:05] Uh [13:06] yofel, v [13:06] s/v/https://code.launchpad.net/~smartboyhw/ubuntu/raring/homerun/0.2.1-0ubuntu2-added-watch-file/+merge/151359/ [13:06] smartboyhw meant: "yofel, https:" [13:06] LOL [13:06] https://code.launchpad.net/~smartboyhw/ubuntu/raring/homerun/0.2.1-0ubuntu2-added-watch-file/+merge/151359 [13:07] BTW Riddell + yofel you want me to update Skrooge to 1.6.0 ? [13:07] Or is it a debian-sync package? [13:07] I forgot what that was [13:07] And BTW where's the Rekonq merge!? [13:08] skrooge 1.6 is in debian experimental [13:08] yofel, request merge then:P [13:08] s/merge/sync/ [13:08] smartboyhw meant: "yofel, request sync then:P" [13:08] go ahead [13:09] yofel, any kubotu command for this!? (LOL) [13:09] nope, but requestsync from ubuntu-dev-tools [13:11] homerun uploaded, thanks [13:11] yofel, thx [13:12] Got the bug filed now :) [13:12] Bug 1139955 [13:12] bug 1139955 in skrooge (Ubuntu) "Sync skrooge 1.6.0-1 (universe) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/1139955 [13:12] How come I don't know about this nice feature?!!? [13:13] kde-runtime failed [13:13] And I can't access the Build Log, "Processing failed" [13:14] try again, it'll fetch the log then [13:15] launchpad has hiccups currently :/ [13:15] kde-runtime went busted because of kate [13:16] s/kate/katepart in kate/ [13:16] smartboyhw meant: "kde-runtime went busted because of katepart in kate" [13:16] yeah, and kate failed on pykde4 [13:16] The kstar i386 one is weird [13:17] not really, though I haven't seen a DSO link error in quite a while [13:17] yofel, that's good (or bad?) [13:18] well, it'll need a buildsystem fix [13:18] probably best to check what upstream did there [13:20] hm [13:21] except that they didn't change a thing between 4.10.0 and .1 [13:21] (except some i18n strings) [13:22] smokeqt failed because libqscinitilla2-9 wasn't there [13:22] The -proposed version for 2.7 is still in -proposed [13:22] with build errors for almost all architecture [13:22] hmm [13:23] ninjas has -proposed enabled [13:23] Bah, the symbols went haywire [13:23] * smartboyhw wonders will ScottK fix it [13:27] he will, but not until he's awake ^^ [13:27] :) [13:38] amd builders y u so busy [13:39] what are you waiting for? [13:43] Quintasan, LOL [13:43] yofel: telepathy dailies [13:43] ah [13:44] * yofel uploads more builds to ninjas to postpone those even more [13:44] LOL [14:14] Oh yofel went MIA [14:34] Howdy all [14:34] hiho [14:34] Hey BluesKaj [14:35] hi soee , smartboyhw [14:57] Welcome back yofel__ [14:57] more or less [14:58] yofel__, ? [14:59] the core died because postgresql got stuck on I/O [14:59]