=== swstalcup is now known as v [00:58] Quintasan: I do have an amazon account, why? [00:58] howdy ScottK! [00:59] howdy v. [00:59] I see your names in emails a lot, but I'm never on the chat of relays anymore [01:00] And yet, here you are ... [01:00] just thought I'd say howdy [01:00] Yeah. Thanks. Nice to see you again. [01:02] likewise [01:27] valorie: 80% of the information is useless [01:28] workflows are all different, the only think useful on the page is where to find the packaging branches, and even for that we have more meaningful ways xD [07:38] hey valorie [07:41] hey [07:43] I'm trying to make a tahr icon for the new banner [07:43] cool [07:44] tring got this look http://wallpapo.com/wp-content/uploads/Ubuntu-13.04-Blue-Wallpaper-Full-HD.jpg [07:44] I haven't seen the official artwork [07:44] but I think from the side would be easier and better [07:44] oh, yes I have [07:44] is there [07:44] ? [07:44] that blue looks rather washed out [07:44] is that our official color? [07:45] from the side? [07:45] not sure [07:45] is there a logo already made? [07:49] wow, it is hard to google for this stuff, isn't it? [07:49] canonical has artwork, I'm sure [07:49] that we can use as a base [07:50] http://i1-news.softpedia-static.com/images/news-hot/This-Is-Why-Ubuntu-Is-Successful-and-Has-an-Awesome-Community-h2.png [07:55] nice [07:55] http://i.stack.imgur.com/Plm0R.png something I don;t like about ubuntu [07:57] what? [07:58] the -desktop files are just metapackages [08:01] really? [08:03] https://openclipart.org/people/Last-Dino/tahr3.svg [08:04] yes, pretend you are going to install one, and look at what it contains [08:04] it's a selection of packages [08:04] I believe it is the stuff we choose for the ISO [08:05] but don't quote me on that [08:06] yea [08:07] now, if it lists about a 100 packages, then you are sorta screwed [08:11] yea [08:11] http://farm6.staticflickr.com/5486/11475766576_c01f69a803_h.jpg [08:11] still cannot find official artwork for trusty [08:13] http://4.bp.blogspot.com/-CvosMV8kQQ4/UmP_HLS0DUI/AAAAAAAAFY0/bKhwzY-GxY4/s699/trusty-tahr.jpg [08:13] me either [08:13] there is some nice TT fanart though [08:15] ydea [08:18] it is almost 3:30am [08:20] you are worse than me! [08:20] I turn out the light by then [08:21] lol [08:21] I don't normally stay up this late [08:22] * ahoneybun needs ideas for a icon design [08:29] I might have something [08:34] http://imgur.com/JTJPt0H [08:45] http://imgur.com/AddHXmE [08:47] second one is better [08:47] I do not like the target on forehead look [10:11] 23:48 < maxy> Riddell: Ok, the idea started with kf5 as a sync point and scaleted rapidly into having the packaging in the same repos, as done in other debian ubuntu teams [10:11] should we move our kf5 packaging into debian git? [10:12] (or convince them to move theirs to launchpad bzr) [10:15] discover seem to be broken again. it shows no apps in categories: http://www.dodaj.rs/f/2n/J/2LUt3dMj/snapshot19.png [10:17] yeah, known bug snele, dunno what's wrong but apol should be onto it [10:19] how is our kf5 packaging situation any different from our kde sc one? [10:19] it's not, except it's a fresh start [10:20] I've always been reluctant to do it because a) canonical wouldn't let me and b) it might be more hassle and cause delays in some way [10:20] but a) isn't relevant any more [10:20] and b) may well not be true [10:20] but I'm still uncertain [10:21] other teams do it I belive [10:21] IIRC (correct me) it was about managing commit rights mostly - as it would be impossible to match archive upload permissions to branch commit rights [10:21] BUT [10:21] that's pretty much broken anyway since we moved to universe [10:21] apachelogger: ^ [10:21] I'm not very interesting in matching archive upload to branch commit rights as I say on the Policy thread, we should have a lowish barrier of entry for new contributors [10:22] * Riddell runs out for the day [10:26] having -members as an entry point for direct commit rights is sensible I believe. I don't remember what the d-q-k team's requirements for being added to the team on alioth are [10:40] ::qt-bugs:: [1286767] package libqtcore4 4:4.8.4+dfsg-0ubuntu18.1 failed to install/upgrade: unable to clean up ... @ https://bugs.launchpad.net/bugs/1286767 (by Tomi) [10:53] universe universe [10:53] masters of the universe [10:54] snele: was it you who had muon-updater display "your system is out of date, please update cache" on startup? if so, does that still happen with the latest version in trusty? [10:55] yofel: how is that broken? [10:56] kubuntu-dev | core-dev | motu [10:56] oh, motu is in there? nvm me then [10:57] apachelogger: just tried it. it doesn't show that screen any more :) [10:57] no they aren't because we also have main bits (such as qt :P) [10:58] snele: https://bugs.kde.org/show_bug.cgi?id=331665 you may want to comment here [10:58] well, then it's broken. [10:58] KDE bug 331665 in updater "muon-updater prompts to click missing "Check for updates" button" [Minor,Unconfirmed] [10:58] snele: I think this issue is unique to 2.1.x [10:58] yofel: how so? [10:58] apachelogger: mapping of uploads rights to commit rights (that's all I meant) [10:59] well [10:59] kubuntu-packaging-universe vs kubuntu-packaging-main [10:59] it ain't broken it's just kept at a more convenient setup [11:00] I call that broken (even if just slightly) :P [11:00] it all comes back to the fact that motus didn't want to be killed off by the archive reorg [11:00] yofel: no it's a bloody workaround to satisfy parts of the community being unreasonable [11:00] true [11:00] apachelogger: yeah that is the bug I was experiencing. Now on 14.04 it starts normally [11:00] because motu was supposed to go away, and then the mimimi started [11:01] snele: right, please comment [11:01] 14.04 has 2.2 alpha1 [11:02] so I am not sure we'll want to pursue this issue for 2.1 at all (given it does not actually break anything and 2.1 goes EOL in like 3 months, along with 13.10) [11:02] was our issue with debian any different? (i.e. something else than whatever we sync from the debian archive at least having passed a DM review, unlike git?) [11:03] *shrug* [11:03] why :( [11:04] I think we should move our packaging to kde :P [11:04] or rather, debian should, then all derivates can actually maintain derived repositories, and everyone can easily get access because kde has a very low barrier for getting a dev upgrade as it were [11:04] all hail the kde [11:04] what does gentoo gain by having their packaging there? [11:05] yofel: gentoo is derived from debian? [11:05] the debian-qt-kde team's entry barrier for the alioth membership isn't that hight either I believe [11:06] but here's what everyone gains: all the flipping silly patches are all in the same place [11:06] apachelogger: I meant having it on the kde side [11:06] (they were in kdesupport or where was it?) [11:06] and everyone can fork anything becuase everything is at the same place [11:06] and everyone can steal build workarounds from each other [11:07] also everyone feels closer to the kde and perhaps stops breaking the branding [11:10] well, we could first move to debian and then convince them to move to kde later. [11:10] Maybe that would start an interesting discussion about why they want to stick to alioth but look weird at us for keeping our own repos while being a derivative [11:13] well, I guess here is the main question: what do we get from moving to debian? [11:14] a cookie? ^^ [11:16] well that's not very useful now is it :P [11:16] collective maintenance would be one point, but I'm not sure how well that would play out with them always working in different timeframes than us === chiefw0tj is now known as tfieber [12:13] Good afternoon. [12:17] Howdy folks [15:29] yofel: There would be less risk of Kubuntu doing to initial packaging work and then Debian reworking it differently. [15:29] I think working in common makes sense. [15:29] The biggest problem will probably be Qt5 anyway. [15:30] Note that trusty is STILL on 5.0.2 while Debian has 5.2.0 in testing/unstable and 5.2.1 in experimental. [15:32] right, but that's more of a downside for them if they have to re-do all our work? [15:32] No, then when we try to merge back it's a pain. [15:32] So it sucks for both of us. [15:33] well, if we merge at all. Without a convergence point, e.g. kde sc is unmergable now. [15:33] Yeah, I would rather have everyone improve the same set of packages [15:35] I think for kf5 it definitely makes sense to try it. [15:35] If it doesn't work out, we can always fork and go back to the way it is now. [15:36] apachelogger: leaving aside your tendency to want to move to kde. In respect to commit permissions, maxy suggested that one could potentially make a debian-qt-kde-dev team just with DM/DD/kubuntu-dev that manages the repositories [15:38] yofel: tbh, I don't think permissions ever were a real issue [15:38] in fact I don't think there ever was any opposition other than people claiming bzr is better than git [15:39] *blink* [15:40] there's many arguments to be made, they are all not very compelling though [15:40] for example spreadign out our stuff too much [15:40] our infrastructure would basically spread from random-ubuntu-service (iso tracker), to launchpad, to alitoh, to kde [15:42] and since I know Riddell likes low entry barriers, I think wrapping one's head around that ought to be the biggest show stopper ever [15:44] anyway [15:45] well, I'm on your side in that discussion. In any case, I'm not convinced that low entry barriers justify duplicating so much work [15:45] yofel: I am not opposed to the idea, my only comment is that ultimately everyone should converge on KDE :P [15:45] heh [15:45] other than that I really do not care [15:46] though if you want a general comment: if a change does not make the product better it's a pointless change [15:49] well, I want to reduce merges. In kde sc we had many packaging regressions every time we merged, and that's gotten to the point where we're essentially not really merging anymore now. [15:49] If we could get at least kf5 to a point where the packages work both in debian and kubuntu and we all work on the same damn thing it would be less of a pain in the end [15:50] *If* we can work out some of the workflow diff that we have just because of launchpad that is [15:50] well, you can't elminiate merges [15:50] they are a result of the different release cycles [15:51] not really - if you work on the same repo and just upload as 'upload from debian git' [15:51] then you'll have no diff to merge [15:51] the only way to reduce the regressions introduced by merges is conducting regular merges [15:51] yofel: maybe [15:52] what about kubuntu branding patches? [15:52] could be done with a build-time switch? (maybe) [15:52] we've got ton of packages with distro-specific stuff in the build system [15:53] "does a build-time switch it make the product better" :P [15:53] why does ubuntu not maintain it's own copy of gcc? [15:53] it does? [15:53] that packaging has release names and distro codenames ifdef'd all over the place [15:54] maybe, but tons of the ubuntu specific changes are part of the debian package [15:54] because if upmerging I think [15:54] though I could not possibly comment on the factuality of it [15:55] s/if/of [15:55] yofel: I think what ought to happen first is do a failure analysis and find out why exactly merges introduce regressions [15:56] then see if repo restructuring/sharing/moving would actually solve those [15:56] well, people overlook things, like not adding back versioned deps that are needed etc. [15:56] why did we need them and debian didn't? [15:56] whether *those* could be solved, I'm not sure [15:57] eitherway, I'd much rather have some hard metrics :P [15:57] the case I think of was part of our kde-sc-dev-latest deprecation [15:57] yofel: so there's a platform delta already that sharing doesn't solve :P [15:57] that's why we should try kf5 and see where it goes. kde sc would be A LOT of work [15:57] nono [15:58] we should find out why things fail, then see how this can be avoided, and then possibly try with kf5 whether it actually solves the issue [15:58] apachelogger: it is a platform specific workaround that breaks *nothing* on the debian side [15:58] they could just ignore it [15:58] so why does the packaging break? [15:59] if the delta is contained within the platform then why do individual packages regress if they ought not have invididual delta? [15:59] human errors because of so much diff? [15:59] ..micro merges... :P [15:59] yeah right, do a micro merge for kde-workspace [16:00] that's effectively what a shared repo with different release artifacts is [16:01] well, then we might as well have one repo that applies platform specific changes when needed. At least to the point where we really only have the changes that cannot be kept in debian as our diff [16:02] right, but that is different from a shared repo [16:02] define shared repo please? [16:02] which is the reason I am saying that first you must analysis why things fail, devise requirements for how to make them not/less fail and then implement a solution [16:02] yofel: one single repository shared across all the world [16:03] versus two repositories where one is a fork of the other [16:04] well, we might not be getting one shared over all across the world, but we could share a lot at least in debian [16:05] and latter is what really should be kept to a minimum [16:05] yofel: across our world of kde with debian [16:06] the point is you need to know exactly what the problems are we try to solve and whether they can be solved etc. [16:06] because say we have per-package delta that simply cannot be conveniently isolated, which would then require two repos or at least a different branch [16:07] to facilitate micro merging you'd then need some additional automation along the lines of "daily merge $master into $kubuntumaster" [16:08] why daily? one could merge whenever we start a new version (or so) [16:08] ranodm example [16:08] and git merge is a hell of a lot better than what we're doing right now [16:09] you are thinking implementation, I am thinking problem solving :P [16:10] well, I know some of the problem with kde that I'll discuss with debian. Still wanted to see how much you disagree on the doability [16:10] *kde sc [16:11] I do not disagree on the doability at all [16:12] I'd just like to be this correctly planned out because if you adjust automation for setup scenario 1 and then it turns out that will not work and we'll need to use setup scenario 2, then we end up ajdusting all the automation again [16:12] right [16:12] for no reason, other than not having understood the problems we try to solve and the requirements we canot change [16:14] sure, that'd be an utter waste of time [16:44] hey guys, just as a side-note, maybe https://wiki.ubuntu.com/Kubuntu/Membership should be updated? [16:44] the benefits of ubuntu membership are a lot more now [17:10] jose: apachelogger is going over much of the wiki stuff [17:11] jose: see https://wiki.kubuntu.org/Kubuntu/Policies#A.2BAH4-kubuntu-members [17:14] oh, got it :) === ryanakca_ is now known as ryanakca [20:00] there is some updates that breaks oxygen style ? [20:01] if i open system settings and check App style i have CDE enabled and oxygen is missing [21:10] kubotu: newversion calligra 2.8.0 [21:10] https://bugs.launchpad.net/bugs/1286908 [21:19] we have some systemd things coming in already? [21:19] Riddell, I have a design for a banner for 14.04 [21:21] ahoneybun: as in? (systemd). We've had logind for a while now, but I don't think we'll have proper systemd until the next release [21:22] yofel, Setting up libsystemd-daemon0:amd64 (204-5ubuntu13) ... [21:22] Setting up systemd-services (204-5ubuntu13) ... [21:22] Setting up libpam-systemd:amd64 (204-5ubuntu13) ... [21:22] Setting up libsystemd-login0:amd64 (204-5ubuntu13) ... [21:22] ah, we've had that for a while now [21:22] it's for logind [21:22] yofel, http://imgur.com/AddHXmE what do you think? [21:23] the horns look... choppy, kinda. Otherwise kinda nice [21:24] yea [21:24] the ears a bit too [21:33] yofel, http://imgur.com/kciydN0 I only have half the head on purpose [22:18] Riddell, http://imgur.com/kciydN0 [23:51] is there something wrong with samba?