': invalid argument: --origin frameworks (OptionParser::InvalidArgument) [08:18] it no likey [08:18] Riddell: I just want to change the name it shows on the login prompt [08:19] Guest is not descriptive enough for kids in the school I put Kubuntu in [08:19] Riddell: trunk or stable [08:19] I want to change it to Elev [08:19] always trunk or stable [08:19] there is no origin other than trunk or stable :P [08:23] my comput0r is too slow for bzr [08:24] Riddell: any solutions, pleasE? [08:26] ovidiu-florin: isn't it translated? [08:26] in 13.10 it isn't [08:26] I haven't upgraded yet [08:27] it won't have changed [08:27] d_ed will probably know [08:28] or robert ancell [08:28] is there a meta package for all KDE games? [08:29] there is kdegames [08:30] thank you [08:30] the guest string might actually be from accountservice FWIW [08:39] apachelogger: ah, I think what you mean to say is "jonathan, set the trunk branch in projects.kde.org and wait 10 minutes for it to propagate" [08:40] Riddell: possibly [08:40] now, I wonder if there's a way to magically rename the tar [08:44] there isn't [08:44] Riddell: why would you? [08:44] Riddell: rm -rf *.tar [08:44] oh wait [08:44] apachelogger: because e.g. baloo needs to be baloo-kf5 or something [08:44] that't not rename [08:44] Riddell: what, why? [08:44] oups :P [08:45] apachelogger: else distros will have to rename it, and better to do it upstream [08:45] Riddell: I'm pinged in something? [08:45] Riddell: nope, that indeed best had been done on a distro level [08:46] d_ed: ovidiu-florin here asks if the Guest user can be renamed or translated in lightdm [08:46] apachelogger: why do you think that is? [08:46] they only need renaming because shitty distro tools cannot deal with the same source having two different versions [08:46] it /should/ be able to [08:46] that is to say with rpm I think you don't even need to rename the source at all for example [08:46] it comes from KDE code [08:46] which goes via i18n [08:46] d_ed: how? [08:47] d_ed: a grep did not yield useful results on Guest [08:48] QStandardItem *guest = new QStandardItem(i18n("Guest")); [08:48] in lib [08:48] ah, in lib [08:49] it's probably not covered by a Messages.sh or something equally rubbish [08:49] d_ed: So there's no whay I can change that to "Student" or something like that without recompiling? [08:49] sorry, no. [08:49] bummer [08:49] well [08:50] if it is translated you could simply change the translation 6^ [08:50] ^^ [08:51] can I do that without changing the official translation? [08:54] is that a spupid question? since no one is answering, i can assume so.. [08:55] more tricky than stupid I think, as my answer would be no [08:56] but I'm not a l10n expert [08:56] i guess the translations are stored as po files [08:56] so I should be able to change the text in one [08:56] to get it overritten on update [08:57] po yes, but compiled to mo which is what you would have to replace [08:57] oh [08:57] see gettext docs [08:57] so, the answer is no [08:58] maybe a PPA package that's adjusted would be an option [09:02] shadeslayer: what happened to you uploading 4.13.1? [09:04] apachelogger: regarding E: libkf5wallet5: arch-dependent-file-not-in-arch-specific-directory usr/bin/kwalletd5 [09:04] put into 'kwallet' (which doesn't exist yet), or kwalletd5 ? [09:05] yofel: libkf5kwallet-bin [09:05] or kwalletd [09:05] hm, ok [09:05] although [09:05] it's a single binary... so I didn't really want to add lib [09:05] hm? [09:05] it's a runtime support binary for the lib [09:06] on its own I doubt kwalletd will have much use [09:06] you could ask teo in kde-devel though [09:06] ah nevermind, it has a bunch of support stuff too [09:06] so -bin it is [09:07] apachelogger: pre-depends was nonsense, right? [09:07] yofel: we at least did not find out what it was good for [09:08] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/kf5umbrella/". [09:08] Riddell: ^ that's why upstream we shouldn't randomly rename things [09:09] "To ensure that a multiarch-compatible libc is configured before your shared library package is unpacked to the new multiarch library paths (and the old version of the library deleted from /usr/lib), each shared library must declare a Pre-Depends on the multiarch-support package." [09:09] But that seems to be from the old times [09:11] apachelogger: it does actually get substituted to Pre-Depends: multiarch-support [09:12] how does the guest session work? [09:12] how does it start? [09:12] it creates a new user with a tmp home dir? [09:12] /usr/lib/lightdm/guest-session-auto.sh may help [09:12] where does it copy the settings from? [09:12] also /usr/lib/lightdm/lightdm-guest-session [09:12] ok [09:13] and /usr/sbin/guest-account [09:13] yofel: I am not sure that is still necessary [09:13] ovidiu-florin: same as any new user I expect [09:13] ovidiu-florin: yes it makes a new user with a tmp home dir [09:13] apachelogger: I'll ask debian if they need it [09:13] Riddell: that file does not exist on 13.10 [09:15] are there any logs for when a guest session failes? === Haudegen_ is now known as Haudegen [09:19] apachelogger: [09:19] [11:16:46] yofel: That was only for squeeze -> wheezy upgrades. [09:19] [11:18:51] yofel: It's not needed any longer. [09:19] so as we won't backport << trusty we won't need it either [09:20] groovy [09:23] ovidiu-florin: /var/log/lightdm/ maybe? [09:23] hm, libkf5kwallet5 is definitely not section:libdevel [09:29] yofel: I did [09:29] probably in the queue [09:29] ah yeah, probably [09:30] apachelogger: libkf5wallet-bin would be Multi-Arch: none? (or just skip the field?) [09:30] yofel: skip == none [09:30] yofel: and lib recommends bin [09:31] ack [09:34] apachelogger: on the topic of naming, is it intentional that we're using kactivities and not libkf5activites-bin ? [09:34] I have no clue [09:34] consistency-- -.- [09:34] mind you kactivities is special because upstream says the runtime bits are interchangable [09:35] i.e. you can use kde4 runtime or kf5 runtime, doesn't matter to the lib [09:35] well, the kde4 runtime is in libkactivities-bin :S [09:35] then something is astray I'd say [09:35] but yeah, I'm doing a whole review of frameworks later [09:35] also structural alignment and whatnot [09:35] ok [09:36] possibly also trying to get substvars going for descriptions [09:36] not quite interchangeable, kf5 kactivities needed for kf5 land [09:36] but should be backwards compatible [09:37] so you're supposed to be able to run kde4 with kf5 activities o.O? [09:37] yes I believe so [09:37] fun [09:42] Riddell, santa_: did you run the kdelibs4support patch by upstream? [09:42] also, it doesn't have dep3 [09:43] which reminds me I never voted on policy :( [09:43] boo [09:43] I'll do that after lunch [09:43] +1 anyway [09:44] apachelogger: he promised to do so [09:44] Riddell: did you read what I wrote about backlog yesterday [09:44] also [09:44] the patch is not documented in the changelog in any way [09:45] nope, what did you write about backlog? [09:45] that there's a bug [09:45] a bug that has been fixed 20 hours ago mind you [09:48] apachelogger: not yet, but will submit the pacth today to reviewboard and add the headers [09:49] [11:45] a bug that has been fixed 20 hours ago mind you [09:49] you first talk to upstream and then you do things. [09:51] yofel: is list-missing our code? [09:51] apachelogger: in the build logs? It's a patch to pkg-kde-tools I believe so it's script-parsable [09:52] http://people.canonical.com/~ubuntu-archive/phased-updates.html [09:52] yofel: just wondering why we don't make it detect manpages properly ^^ [09:52] quite fancy that stuff [09:52] shadeslayer: only implemented in update-manager I believe? [09:53] :( [09:53] the issue listing is cool though [09:53] https://errors.ubuntu.com/problem/2bb11f5013b5638956cbb06a6f822d811fde60a4 < known issue [09:54] https://errors.ubuntu.com/problem/d43591a91bd75c89b52b372618f42d0cabdc7e94 dupe [09:54] https://errors.ubuntu.com/problem/e0d7f4fb342e721238de3d5cc79148ab67ba3fe2 dupe [09:54] https://errors.ubuntu.com/problem/1a794f4f0b1fa61aa9916353ae643de6085125fc dupe [09:54] * apachelogger wonders how one makes kate open */debian/* without thorwing a bazillion errors on directories [09:54] apachelogger: generally list-missing is part of dh_install though, extended by pkg-kde-tools to support not-installed and run by us during build time for parsing [09:55] well yeah [09:55] but if we can estend through not-installed we could just as well check manpages I guess [09:55] what's actually wrong with the manpage check? [09:55] supposedly dh_install should get its act together though [09:56] yofel: manpages get compressed by dh_manthing [09:56] so they always yield false positives [09:56] oh right, it did complain about that [09:56] it's the same for movelibkdeinit [09:57] movelibkdeinit neeeds posted to kf5 [09:57] movelibkdeinit neeeds ported to kf5 [09:58] what's that do? [09:59] moves libkdeinit4_* to /usr/lib/kde4/libkdeinit/ [09:59] why don't we do that upstream? [09:59] uh, no idea? That was done before my time... [10:00] why don't we do that upstream for kf5 [10:00] no idea, should be done really [10:00] Riddell: release dude we haz feature request :P ^ [10:01] * yofel -> lunch [10:10] yofel: I hope you are already done with kwallet [10:10] * apachelogger is breaking all the frameworks [10:13] * apachelogger will need to write a control parser at some point [10:14] apachelogger: the inclusion of that patch is documented in the changelog [10:14] not what it does [10:15] apachelogger: needs working out what else dh_movelibkdeinit does then working out if it can be done in cmake or elsewhere [10:16] apachelogger: yes, it does, it's listed as a change below "build against network-manager" [10:16] it does not explain what the patch does [10:16] meanin it's needed to build against network-manager [10:17] it does not explain what the patch does [10:17] making you able to build against network-manager? [10:17] but if it's not clear enough, feel free to re-word it [10:23] apachelogger: merge for you https://code.launchpad.net/~panfaust/kubuntu-packaging-next/kdelibs4support-work/+merge/222154 [10:25] tsdgeos: does setting the master branch for baloo and milou and kfilemetadata to frameworks in projects.kde.org screw up 4.14 alpha/beta releases? [10:25] Riddell: busy, please send me an email or reask when not working [10:31] 'Morning [10:33] apachelogger: what exactly are you doing to our poor frameworks o.O? [10:42] yofel: everything [10:42] :O [10:42] http://paste.ubuntu.com/7593964/ [10:43] fun [10:43] I am actually thinking about splitting short and long description such that you can append stuff to the shortsies [10:43] - development files [10:44] otherwise the short description is the same for all packages of the framework which is a tad rubbish [10:45] apachelogger: waa, tarme doesn't save the release_data file if you run it multiple times :( [10:46] yeah [10:46] Riddell: suggestions? [10:47] or for that matter... why do you run it multiple times and expect the data to be there? [10:48] apachelogger: append rather than overwrite [10:49] Riddell: but why [10:50] because I need to make multiple tars then e-mail the release list with the list of hashes [10:51] Riddell: tarme.rb -v 1.0 --origin trunk kde/workspace/ rolls aaaaaallllll tars at the same time [10:52] apachelogger: btw. I asked you yesterday whether kubotu has flood control for the commit messages enabled (if it has to process like 200 commits). Is there something? [10:52] no [10:52] yes [10:52] it posts 13 lines at the most [10:52] ok [10:52] enough for me [10:52] that is 12 commits and one for the fact that there is more than 12 commits [10:53] might reduce it to 8, but since I haven't seen a 12 line block yet I can't say whether that ends up too much [10:53] I think it's fine, most I've seen was 10 so far which is rare [10:55] I find the package control sorting really annoying what with -dev being first becuase they don't have the soversion suffix -.- [10:56] apachelogger: mm, interesting [10:56] that's how we always did it.. and why do you need the soversion o.O? [10:57] yofel: noooo, we always had lib first, dev second, dbg last [10:57] my memory is buggy then [10:57] Riddell: pft, I made that feature specifically for you so you don't have to run releaseme 300 times and then have forgotten about one tarball :P [10:58] yofel: well, last I really packaged something was like 4 years ago, so who knows :P [10:58] apachelogger: features are no use unless someone knows about them :) [10:58] after a while the kde4 controls wer a bit of a mess anyway, but I really think libs generally came before the dev package [10:58] Riddell: I did tell you about that :P [10:58] like twice at the very least [10:59] http://paste.ubuntu.com/7594059/ [10:59] short and long description split [10:59] and I really think I need a control parser, because I also think Architecture should be listed first in the package stanzas [11:00] in particular section should not be first becuase it's rubbish and no one cares about it anyway ^^ [11:00] section should be there, end. Architecture usually comes next, but that's not defined anywhere, just how we usually do it [11:01] after that I don't think we really have a pattern what comes next, IIRC usually it's Pre-Depends, Depends, Recommends, Suggests, Breaks, Replaces, Conflicts [11:01] Provides [11:01] yofel: section is optional [11:01] architecture is not [11:02] so really the order should be arch>multiarch>section>priority>depends>breaks>conflicts>replaces>description IMO [11:02] I know it's optional, but I've always seen section coming before architecture [11:03] * yofel looks at policy [11:03] it doesn't even come first in the policy, becuase the policy also knows that the mandatory architecture fields is more important :P [11:04] well, by that logic description should come after architecture, but you're right, section comes after arch [11:05] nope [11:05] description is a multiline field [11:05] and breaks-conflicts-provides-replaces [11:07] yeah, but homepage, built-using and package-type coming after that sounds a bit weird then - even if it's like that in DEBIAN/control [11:07] yofel: coming after what? [11:07] description [11:08] I guess I'll agree though that the order should at least follow policy [11:08] those are autogenerated for the binary anyway [11:08] but even when not descripition would be last [11:09] we never use those so that's a moot point anyway [11:09] looking at kde4libs you're right that libs come before dev though :/ [11:10] apachelogger: in any case, please at least tell debian about the field reordering in case they're against it [11:10] I am not even sure I'll bother TBH [11:11] shadeslayer: are you adding back libs to kdepim o.O? [11:11] if I write a control parser or get down and dirty with perl I'd just do mass changes to fields through that [11:11] then I'll never have to look at the fugly control files anyway [11:11] yofel: yes, for utopic [11:11] why? [11:12] it's not like they're coming back... [11:12] for a .1 release it's bad to remove them? [11:12] we can nuke them in the beta release [11:12] well, that was for the SRU, but whatever [11:12] SRU? [11:12] ah [11:13] what does it matter whether the release is .1 or not for utopic? [11:13] the reverts were for the SRU [11:14] apachelogger: well, I did write a very basic control file editor in perl for neon once as overriding some fields at build time in rules didn't go so well [11:14] it was fun [11:14] was for the apport stuff IIRC [11:14] perl is a really dumb ruby, that's all [11:15] * yofel should read learnrubythehardway once [11:15] ^^ [11:15] I'm currently reading learncthehardway [11:15] neat stuff [11:15] I used perl because ruby isn't part of the default system :P [11:17] yofel: since Riddell uploaded some 4.13.1 stuff, how do you want to handle 4.13.1 for utopic [11:17] shadeslayer: for the 2 packages I did yesterday I just uploaded .1 [11:18] ok [11:18] so just upload then? [11:18] *upload 4.13.1 [11:19] yeah [11:19] apachelogger: that thing is still there actually ^^ http://bazaar.launchpad.net/~neon/project-neon5/project-neon5-runtime/view/head:/opt/project-neon5/share/pkg-project-neon5/scripts/get_control_field.pl [11:22] you could just have used the existing perl modules you know :P [11:22] they were confusing me even more so I was frustrated enough to write it from scratch.. [11:23] yeah, perl does that [11:23] but the dpkg modules are actually reasonably well documented from what I have seen [11:37] dch -.- [11:53] Riddell: how does one check whether a bzr branch has uncommited changed through the $? [11:58] well that only caused a bunch of bogus commits -.- [11:58] bzr diff? === vinay is now known as Guest30250 [11:59] as yofel says [12:00] strangely enough it returned 0 in both cases earlier [12:02] well, parse output wrt. not/empty then [12:04] much terrible [12:05] apachelogger: what exactly are you trying to do? [12:05] check whether a working tree is dirty [12:05] you can just go and commit, empty commits will give exit 3 from commit [12:06] yofel: except they'd be dirty if I simply dch [12:06] why would you not want to commit dchß [12:06] ? [12:06] yofel: dch -a -m yolo && debcommit [12:07] which is conditional to initial dirtyness [12:08] why is it conditional? [12:08] Riddell: good morning, anything for me to work on? [12:08] http://paste.ubuntu.com/7594397/ [12:09] yofel: because dch would make it dirty [12:09] whynot dirtynessful :) [12:09] apachelogger: are you trying to auto-generate changelogs from actual changes o.O? [12:09] well yes [12:10] ah, interesting [12:10] I did a sed on all 3 million branches [12:10] but the change only applies to 2 of the 3 million [12:10] so one needs a way to check which were actually changed and then dch && commit those [12:10] the other ones ought to be left alone [12:11] hm, if I run bzr diff on a branch with changes I get exit 1 [12:11] which matches the 'diff' behaviour [12:11] * yofel wonders why he always writes that in en_GB [12:12] I blame school [12:12] yofel: yes, except when I tired that it still was 0 [12:12] it's proper english, not the 'merican english [12:12] alas, now it is 1 when I try it [12:12] eitherway [12:12] diff is nasty [12:13] well, parsing of $? is rather error prone [12:13] yeah, for if you use it on bzr diff :P [12:13] which is why I was asking for a proper way [12:13] I show the exit status in my prompt and even that has $? caching in PS1 [12:14] feed branches-next had 25 updates, showing the latest 16 [12:14] ah, flood limit is 16 ^^ [12:14] sgclark: here's a first short of tars, you can see if they compile, install translations, do other sane things http://starsky.19inch.net/~jr/tmp/plasma-4.97.0/ [12:14] sgclark: I'll be remaking the tars because the version numbers are not updated there [12:15] Riddell: on it, thank you [12:15] kubotu: config set rss.announce_max 8 [12:15] sure [12:15] sgclark: so just for checking for problems for now [12:15] yofel: 8 seems to be the golden spot really [12:15] Riddell: ok [12:15] apachelogger: fine with me, IRC throttling does make 16 a bit long [12:15] yeah [12:16] if it spammed all within a second it would almost be fine, but even so, too big a wall of text [12:19] sgclark: oh actually you probably can't compile much because it needs qt 5.3 [12:19] Riddell: oh, is that available? [12:19] so one could ask if we should move next development to utopic which has at least some qt 5.3 packages [12:20] sgclark: yep, in https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2 but for utopic [12:20] apachelogger, yofel, sgclark: should we move next development to utopic? [12:21] Riddell: I think we should [12:21] sgclark: than I guess you can dist-upgrade and tell us if it's safe :) [12:22] if plasma needs 5.3, sure. [12:22] I'm not upgrading to utopic though until the whole init mess is kind of sorted out [12:22] Riddell: lol sure [12:23] Riddell: ENOPOINT until alpha2 if you ask me [12:23] apachelogger: how else would we do development? [12:24] trusty, we are only doing userspace anyway, if something breaks from trusty to utopic that would strike me as odd :P [12:24] my point is... until most of us are using utopic there is 0 point in developing on utopic [12:24] or well, some at least :P [12:25] but the missing qt 5.3 is the problem [12:25] earlierst point would be when qt 5.3 lands [12:25] sgclark: is that landed yet in utopic? [12:25] it's in a PPA [12:25] apachelogger: it's in PPA [12:25] ^ [12:25] yeah, so no point :P [12:25] the point is to have qt 5.3 packages available [12:26] apachelogger: so you want to not work on it until 5.3 is in o.O? [12:26] why? [12:26] Riddell: take them and build for trusty? [12:26] yofel: what's the point if they are in a ppa anyway [12:26] apachelogger: what's the point of backporting 5.3? [12:26] (that's rather heavy) [12:26] just as much work as ppa porting [12:26] well I don't care [12:27] if you feel that you need utopic, use utopic [12:27] I find it very pointless [12:27] as I understand it it would be a no-change rebuild to use the archive 5.3 packages, if anything [12:28] apachelogger: point is to continue working on plasma without much extra work [12:28] and backporting 5.3 is work [12:29] apachelogger: if anything we can wait on you to finish rewriting the kf5 packages [12:32] well that would be rather handy :P [12:37] god this is a mess [12:37] libkf5auth5-dbg vs. libkf5auth-dbg vs. kauth-dbg [12:38] middle [12:38] or hm [12:38] exactly :P [12:39] I think debug stuff is SOVERSION coinstallable, so first usually, second if a -bin package exists, third if a kauth package exists [12:39] total mess [12:40] looking through the archive middle certainly appears the most [12:40] debian-kde gave both answers when I asked them [12:40] some preferred foo5-dbg and some didn't care [12:40] so I went with foo5-dbg [12:41] utterly random [12:43] well, debug coinstallability is probably nonsense, or can by done with dbgsym, so first is junk, so it would be middle if only one lib is there, and last if multiple? [12:43] when will debian get dbgsym so we can do away with those shitty dbg packages [12:43] it's an outrage [12:43] it shouldn't be, they should be foo5-dbg. Now I was new at the beginning and perhaps some old builds were missing 5 but should be removed [12:44] yofel: debugs are always coinstallable as the symbol file name is the uuid of the build artifact [12:44] there is no actual tie to soversion or anything in terms of debug symbol [12:44] well, not if the packages have the same name [12:45] yeah [12:45] i.e. libfoo5-dbg <-> libfoo6-dbg versus 2xlibfoo-dbg [12:45] hence the so is supreme [12:45] but what about packages like kio [12:45]