[00:01] <apachelogger> unless
[00:01] <apachelogger> ah script line bogus
[00:02] <apachelogger> for pot in *.pot ; do po=${pot:0:-1}; msgmerge ../po.orig/de/$po $pot > $po; echo $po; msgfmt --statistics $po; msgfmt --statistics ../po.orig/de/$po; echo "-----"; done
[00:02] <apachelogger> that's the correct one
[00:02] <apachelogger> shadeslayer: translation good to go
[00:06] <ahoneybun> does anyone have alpha 2 installed with the new kubuntu-docs package working?
[00:06] <ahoneybun> hey valorie
[00:07] <apachelogger> ahoneybun: possibly, what do you need?
[00:07] <ahoneybun> I installed the new package and it does not show up in khelpcenter
[00:11] <apachelogger> oh something is bugged
[00:12] <ahoneybun> /usr/share/doc/kubuntu-docs has nothing in it.
[00:13] <ahoneybun> but a copyright file and a changelog.gz
[00:19] <valorie> hello
[00:21] <apachelogger> something is fishy in the build
[00:23] <ahoneybun> oh?
[00:24] <apachelogger> my that is lovely
[00:24] <apachelogger> some piece of shit automated compression is gzipping the flipping docbooks which makes them unlocatable for khelpcenter
[00:25] <apachelogger> ffs
[00:26] <apachelogger> and of course actually mentioning that one is throwing stones at the installed files is too much to ask, so the logs are as always utterly useless
[00:34] <apachelogger> ahoneybun: possible fix uploading right now
[00:37] <ahoneybun> awesomeness
[00:51] <valorie> lovely that you two are fixing that
[00:52] <valorie> :-)
[00:52] <valorie> apachelogger: I did your muon discover survey
[00:53] <ahoneybun> valorie: apachelogger is the developer not I
[00:53] <ahoneybun> survey?
[00:54] <valorie> you tested and gave feedback
[00:55] <valorie> https://docs.google.com/forms/d/1MIE1hbjAABbhvXnq-Ys_JLYAbKu1pN_0nlc8wVYVXUg/formResponse
[00:56] <valorie> is the survey
[00:57] <apachelogger> valorie: ah, you were that, it prompted me to add an email field :P
[00:57] <apachelogger> might also be handly to have comment options
[00:57] <valorie> heh
[00:57] <valorie> well, I was an early whiner about it
[00:58] <valorie> so I felt I owed some feedback
[00:58] <valorie> I found no place to add a review though
[00:58] <apachelogger> there should be a button on the apps mainpage
[00:59] <valorie> hmmm, I didn't discover it
[00:59] <apachelogger> http://i.imgur.com/9vfaTlH.png
[00:59] <valorie> ha!
[00:59] <valorie> my fault; when I was on that page, i didn't look for it
[01:00] <apachelogger> valorie: file a wishlist bug I guess, although aleix wanted to change the apps pages considerably
[01:00] <apachelogger> might be more discoverable then
[01:00] <valorie> and when I looked for it, I wasn't on that page
[01:00] <valorie> I was looking at the other reviews
[01:00] <valorie> oops, dinner time
[01:00] <valorie> ttyl
[01:01] <apachelogger> valorie: I added a description to the test
[01:01] <apachelogger> alas, the review dialog is outright atrocious as I discovered when writing the test cases
[01:02] <apachelogger> so personally I wouldn't put my money on that feature right now ^^
[01:05] <apachelogger> valorie: I also added comments fields to all tests so one can note things that seem odd etc.
[01:11] <apachelogger> valorie: did this type of testing seem accessible though?
[02:06] <valorie> yes, very accessible
[02:07] <valorie> as long as a devel can look at the results easily
[02:07] <valorie> very easy for the tester though
[02:12] <valorie> off to see my daddy
[06:07] <valorie> geez, another split?
[06:07] <valorie> sheesh
[06:20] <Tm_T> it's not that often (:
[06:24] <valorie> as long as it's not another attack
[06:33] <ScottK> apachelogger: I can run a patched one for testing, but it'll be on saucy.
[08:51] <yofel> wtf, I was wondering why my system is swapping and update-apt-xapian-index is using 1.5G of memory O_O
[08:53] <Riddell> must be lots of packages!
[08:53] <yofel> well yeah, my sources.list is huge - but that's just excessive for a "background" process
[09:12] <apachelogger> yofel: it is python python python, it is ewww, it is python python python, it is booo, it is python python python, it is kaput.
[09:13] <yofel> well, thanks to it being python I fixed this for now by putting 'sys.exit(0)' at the top
[09:13] <apachelogger> ScottK: that shouldn't be a problem, but what does 'gets grumpy' look like in terms of UI etc.
[09:22] <lordievader> Good morning.
[10:11] <Riddell> oh dear, libmm-qt is not in the slightest bit binary compatible
[10:17] <Blizzz> is this new that you cannot paste into qt-pinentry?
[10:17] <apachelogger> gettext is really very shitty I have to say
[10:18] <apachelogger> http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html#The-LANGUAGE-variable
[10:18] <apachelogger> if you set en:pt it will simply not give a rats behind and use pt
[10:26] <Riddell> blaze: hmm dunno but I can't paste either
[10:26] <Riddell> nothing has changed there recently
[10:28] <apachelogger> Blizzz even ^^
[10:30] <Riddell> him too
[10:31] <Blizzz> Riddell: mh, right. I typed my passphrase manually before, but now I got a different key and don't know it by heart. So, probably it attracted my attention just because of this. However,  it makes password manager quite useless. Where would bugs be filed for qt-pinentry?
[10:32] <Riddell> in gnupg I think http://www.gnupg.org/aegypten/
[10:33] <Blizzz> Riddell: ty
[10:34] <shadeslayer> morning
[10:34] <Riddell> Blizzz: I can see in the code it has QSecureLineEdit::paste()
[10:38] <xnox> shadeslayer: encrypted btrfs -> use alternate/d-i installer e.g. using mini.iso or server.iso
[10:38] <xnox> shadeslayer: one can do it, by preseeding default filesystem to btrfs.
[10:39] <xnox> shadeslayer: i'd like to add gui options to pick btrfs/xfs into the installer.
[10:39] <Blizzz> Riddell: what does it mean?
[10:40] <Riddell> Blizzz: it seems to want to accept the paste but only if it thinks it's valid, you could try recompiling with that method removed and see if that fixes the issue
[10:40] <shadeslayer> ack
[10:41] <shadeslayer> apachelogger: https://notes.kde.org/p/kubuntu-foreign-language is fine wrt localization test cases?
[10:45] <Blizzz> Riddell: do you know what the criteria for considering it being valid are?
[10:47] <Riddell> Blizzz: no idea I'm afraid
[10:50] <Blizzz> theres an old bug in launchpad for this https://bugs.launchpad.net/ubuntu/+source/pinentry/+bug/326132
[10:51] <apachelogger> shadeslayer: I think that needs two test cases
[10:51] <shadeslayer> apachelogger: I'm listening
[10:51] <apachelogger> install in $locale -> test && install in en -> change via systemsettings -> test
[10:52] <apachelogger> alas, I'll settle for former TBH
[10:52] <Blizzz> i found an issue on gnupg, the claim compiling with --enable-pinentry-qt4-clipboard should solve it
[10:52] <apachelogger> the systemsettings step is really just adding application QA into the mix
[10:52] <shadeslayer> ^^
[10:52] <apachelogger> shouldn't be a ISO test case
[10:52] <apachelogger> shadeslayer: can't look at it in detail though right now
[10:52] <apachelogger> knee deep in gettext snafu
[10:52] <shadeslayer> I think the latter can be covered easily by adding a "Install $lang via systemsettings"
[10:52] <shadeslayer> hehe
[10:52] <shadeslayer> apachelogger: I just wanted to make sure that is indeed what the card wanted
[10:55] <Blizzz> Riddell: can i see the default compile options as they are used for 13.10 somewhere?
[10:56] <Riddell> DEB_CONFIGURE_EXTRA_FLAGS = --disable-rpath --without-libcap \ --enable-pinentry-curses --disable-pinentry-qt --enable-pinentry-qt4 --disable-pinentry-gtk --enable-pinentry-gtk2
[10:56] <Riddell> Blizzz: from the package debian/rules file ↑
[10:56] <Riddell> Blizzz: where do you see about --enable-pinentry-qt4-clipboard ?
[10:56] <Blizzz> Riddell: good to know, thanks! and sorry for all the stupid questions ;)
[10:56] <Riddell> grep doesn't come back with anything for that
[10:57] <Blizzz> Riddell: https://bugs.g10code.com/gnupg/issue1374
[10:57] <Blizzz> the most recent (= top) comment
[10:57] <Blizzz> ah
[10:57] <Blizzz> requires 0.8.4
[10:58] <Riddell> there's a 0.8.4?
[10:59] <Blizzz> Riddell: seems like it is not released, yet
[10:59] <Riddell> right
[10:59] <Blizzz> latest pinentry release according to the git short log was 0.8.3
[11:00] <Riddell> you could find the patch if you're keen on it
[11:00] <Blizzz> the commit is http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=0b3a8568e14b994a8d1f4c1cb42aed4959dfc811
[11:00] <jussi> Riddell: it came! :)
[11:00] <Riddell> yay!
[11:00] <Riddell> what did?
[11:00] <Riddell> oh tablet?
[11:02] <Riddell> Blizzz: I guess we'd need to pass that by an ubuntu security person first
[11:03] <Riddell> Blizzz: pinged them
[11:04]  * Riddell updates libnm-qt and libmm-qt
[11:11] <shadeslayer> apachelogger: re https://bugs.launchpad.net/ubuntu/+source/kubuntu-settings/+bug/1268931 : what if the user explicitly put in kopete, in say 13.10
[11:11] <shadeslayer> apachelogger: because they want OTR
[11:11] <shadeslayer> apachelogger: won't the update script then cause annoyance
[11:16] <Blizzz> Riddell: seems also http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=54b9b92c13a496a33868501dec893bc8d82b1a8d is required but this cannot applied to  0.8.1 without dragging other commits into qt4/Makefile.am
[11:17] <Peace-> guys
[11:17] <Peace-> i can't connect to ftp here http://wstaw.org/m/2014/02/13/plasma-desktopCE2295.png
[11:17] <Peace-> why :D
[11:17] <Blizzz> without this, configure  claims to not knowing --enable-pinentry-qt4-clipboard although all patches are applied and i rechecked that the part really is inside configure.ac
[11:19] <jussi> Riddell: yep, tablet :)
[11:38] <BluesKaj> 'Morning all
[11:45] <apachelogger> shadeslayer: SRU a noop migration script to 13.10 then
[11:45] <apachelogger> personally I would not care TBH
[11:46] <apachelogger> Riddell: ping
[11:46] <shadeslayer> mm
[11:46] <shadeslayer> apachelogger: I need some bash help
[11:46] <shadeslayer> apachelogger: why would this not work http://paste.kde.org/p9muwjlx1
[11:47] <apachelogger> Riddell: eglibc is utterly broken and misehaves with LANGUAGE=en:foo, it will always pick foo, apparently ubuntu's language selector forces all englishes to be last to avoid this problem
[11:47] <apachelogger> the ubuntu approach is somewhat non trivial for us because of how those two list widgets work
[11:47] <apachelogger> and personally I would simply redirect each and every bug in that department to eglibc
[11:51] <apachelogger> shadeslayer: because of unicorns
[11:51] <apachelogger> also that condition looks fishy to begin with
[11:51] <apachelogger> why would it care about the branch variable name
[11:52] <Riddell> apachelogger: why is it non-trivial to mv en to the end of the list?
[11:52] <apachelogger> Riddell: visually
[11:52] <shadeslayer> apachelogger: because debian/config defines BRANCH as the kde-l10n branch and the LANG_PACK_BRANCH as the language-pack one
[11:52] <apachelogger> Riddell: you basically need to lock en_US and en_GB at the end of the listwidget
[11:52] <apachelogger> which basically means that the user can move them around and you reset them again and say "scru u"
[11:53] <shadeslayer> if you run the meta lang pack script , it will compare rev's between 2 different branches
[11:53] <apachelogger> Riddell: if you try the ubuntu version you'll see why that approach is shit
[11:53] <apachelogger> if you try to drag en_AU in front of say french it will simply do nothing...
[11:53] <Riddell> apachelogger: why does it need to be end-user visible? can't it just be worked around behind the scenes?
[11:53] <apachelogger> Riddell: how?
[11:54] <apachelogger> if the user configures en:fr and then his terminal apps speak french he'll be somewhat unhappy
[11:54] <Riddell> if (startswith("en")) {move to end of list}
[11:55] <Riddell> ah your point being that the end result is always end user visible
[11:55] <apachelogger> Riddell: bug 1247802
[11:55] <Riddell> well that sucks
[11:55] <apachelogger> Riddell: well, as I said IMO the approach should be to spam eglibc with bug reports
[11:56] <apachelogger> Riddell: also FWIW it appears that this behavior is not even intentional
[11:56] <apachelogger> if you insert a conditional breakpoint in getenv it will suddenly start to use english
[11:57] <Riddell> that seems quite broken
[11:59] <apachelogger> well
[11:59] <apachelogger> it's a marginal use case at best
[11:59] <apachelogger> there is no real use case for haven en:foo:... as en will cover everything
[11:59] <apachelogger> *having
[12:00] <apachelogger> so really this probably only ever happens when a user is too lazy to move the old languages around and simply moves en to the top
[12:00] <apachelogger> which in itself is a weird thing to do for a normal person IMO
[12:01] <apachelogger> Riddell: perhaps we'll want to have a release note though?
[12:02] <kubotu> ::runtime-bugs:: [999054] DrKonqi should suggest to add dbgsym packages @ https://bugs.launchpad.net/bugs/999054 (by Dennis Schridde)
[12:02] <Riddell> apachelogger: yep
[12:02] <Riddell> shadeslayer: new comment on https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112
[12:03] <shadeslayer> cool
[12:04] <shadeslayer> cdbs question : if I override a target in my make file, and that target also exists in a make file that I've included, how do I call the target from the included make file?
[12:05] <apachelogger> how is that a cdbs question :O
[12:06] <shadeslayer> because said target exists in a cdbs make file
[12:06] <apachelogger> you cannot call an overriden target in general you can however call a fake dependency if they exist
[12:06] <apachelogger> like for example
[12:06] <apachelogger> superclean:
[12:06] <apachelogger> clean: superclean
[12:06] <apachelogger> then you override clean with
[12:06] <apachelogger> clean: superclean
[12:06] <apachelogger> (the overridden target in this case is assumed to not have any actual logic and all the actual logic is in superclean)
[12:07] <apachelogger> shadeslayer: cdbs usually has such super targets
[12:07] <apachelogger> I think they usually are prefixed with ::
[12:07] <apachelogger> not sure though
[12:07] <apachelogger> simply read the files? :P
[12:08] <shadeslayer> apachelogger: trying to solve https://trello.com/c/DtAwHbWR
[12:08] <shadeslayer> I replaced all instances of 14.04 with RELEASE
[12:08] <shadeslayer> and want to resubstitute during build .. hmm
[12:09] <apachelogger> shadeslayer: IIRC xnox had an opinion on that
[12:09] <shadeslayer> xnox: ^^
[12:09] <apachelogger> actually
[12:09] <apachelogger> shadeslayer: that makes no sense
[12:09] <apachelogger> the substitution needed to happen in ubiquity
[12:10] <shadeslayer> oh hm
[12:10] <apachelogger> you have no access to the translated strings outside of that I think
[12:10] <shadeslayer> doesn't the slideshow have it's own pot?
[12:10] <shadeslayer> different from that of the installer
[12:10] <apachelogger> maybe
[12:11] <apachelogger> that has nothing to do with who loads the catalog though
[12:12] <shadeslayer> apachelogger: well at the very least the kde loads a webview to show the slideshow
[12:13] <shadeslayer> would it make sense to add code there that replaces _RELEASE_ with whatever the release version is?
[12:14] <apachelogger> <- not working on ubiquity, so he does not know
[12:15] <Riddell> I'm updating packages and gosh debian seems to be behind on everything
[12:23] <Riddell> hi vorian, ahoneybun
[12:23] <ahoneybun> hey Riddell
[12:44] <Riddell> shadeslayer: can you remember what the magic command is to get bluetooth working on my laptop?
[12:44] <Riddell> hcitool dev  reports nothing
[12:49] <Riddell> 12:48 < mdeslaur> jdstrand, Riddell: I wouldn't object at all...the user is choosing to paste a password
[12:50] <Riddell> Blizzz: I guess that means we can go ahead, but is the patch more complex than the single commit?
[12:50] <Riddell> ↑
[12:52] <Blizzz> Riddell: these are two commits, but the second cannot be applied without tracking changes in Makefile.am. I guess it is doable. What i do not understand was why configure is not recognizing the option.
[12:54] <apachelogger> why don't you simply wait for new upstream release?
[12:54] <Riddell> who knows when that will be
[12:54] <Riddell> we want to paste now!
[12:54] <apachelogger> you weren't able to paste for the past 6 years
[12:55] <jussi> apachelogger: but impatience!!!
[12:55] <apachelogger> but efficient use of time :P
[12:57] <Blizzz> apachelogger: I agree that memorizing a handful strings like xaiRe6shoY9fo^oDi0Ais>u3g is helpful for training your memory
[12:58] <apachelogger> I do not question that it's handy, my point is that it affects like 10 people in the whole wide world and the patch seems to be complicated to get going :P
[12:58] <Blizzz> of it's just two or three it's really not so much a problem
[12:59] <apachelogger> resovle a bug that affects 100 people vs. resolve a bug that affects 10 people
[12:59] <apachelogger> hell yes, it's not so much a problem :P
[12:59] <apachelogger> shadeslayer: https://trello.com/c/bmg4cNW9 did you find out how to push screenshottery?
[13:01] <Blizzz> well, everybody complains how complex and unusable cryptography is OTOH. Tho no doubt you're right, apachelogger,.
[13:01] <jussi> apachelogger: our activities thing is going to need more time, sadly. Plasma people said to me basically, "go away, we are too busy right now with plasma next"
[13:01] <apachelogger> lol
[13:02]  * apachelogger reasd what they actually said
[13:02] <apachelogger> I see nothing, at least as funny
[13:04] <jussi> apachelogger: comment was made by marting in #plasma-devel: [15:24:17] <mgrae sslin> jussi: I think the timing is probably just bad as we are all so busy in getting Plasma Next running
[13:04] <jussi> Martin even...
[13:04] <apachelogger> Blizzz: fwiw, somehow security developers always get weird ideas that stand in the way of usability
[13:06] <Blizzz> apachelogger: imho you need to make compromises anyway if you want security, nevertheless making it as easy and comfortable as  possible is crucial in the long run.
[13:07] <apachelogger> I completely agree
[13:22] <xnox> shadeslayer: huh? we have support for "RELEASE" to substitute to cd-flavour build from .disk at cdimage build time.
[13:22] <xnox> shadeslayer: dito within interface.
[13:22] <xnox> shadeslayer: it's just a special care needs to be taken.
[13:22] <xnox> shadeslayer: where is RELEASE not substituted?
[13:23] <xnox> shadeslayer: we can't have it substituted in the .deb package, as it needs to be dynamic at cdimage .iso time.
[13:23] <xnox> sure we only have one flavour using qt-frontend at the moment, but you wouldn't want to prevent new flavours to start using it with their own name (or e.g. respin the iso with a different name e.g. Kubuntu Active)
[13:41] <shadeslayer> xnox: this is for the slideshow
[13:41] <shadeslayer> where the values are hard coded
[13:42] <shadeslayer> apachelogger: nope, need to contact maintainer
[13:42] <shadeslayer> apachelogger: because it uses saucy lists and the web form needs to be updated to use trusty
[13:44] <xnox> shadeslayer: ideally slideshow would also somehow do runtime substituion...
[13:44] <xnox> shadeslayer: it's reading files off disk doesn't it?
[13:44] <shadeslayer> xnox: I do have an idea of how to do it
[13:44] <shadeslayer> atleast for the KDE ui
[13:44] <shadeslayer> we have markers like _RELEASE_ in the html files
[13:45] <shadeslayer> then read the file in the installer, replace _RELEASE_ with number, set that as the HTML for QWebView
[13:45] <shadeslayer> http://qt-project.org/doc/qt-4.8/qwebview.html#setHtml < allows setting html directly
[13:45] <xnox> shadeslayer: interesting.
[13:45] <xnox> shadeslayer: let me see if whichever webview binding gtk is using to see if that can also do it.
[13:46] <xnox> shadeslayer: cause we'd want to replace distro name and version number.
[13:46] <shadeslayer> cool
[13:46] <shadeslayer> xnox: yep
[13:46] <shadeslayer> well
[13:46] <shadeslayer> name is hard coded
[13:46] <xnox> ideally we want to replace both name and version number.
[13:46] <shadeslayer> not sure why I said that ...
[13:46] <shadeslayer> *nod*
[13:46] <xnox> as names are trademarks and shouldn't be translated.
[13:47] <xnox> It's Kubuntu not Кубунту
[13:47] <shadeslayer> *nod*
[13:48]  * shadeslayer moves to other cards while waiting for xnox
[13:48] <shadeslayer> apachelogger: poke
[13:49] <apachelogger> ouch
[13:49] <shadeslayer> apachelogger: which card do you want me to do?
[13:49] <shadeslayer> cuz FF in one week
[13:49] <shadeslayer> I somehow managed to miss that >.>
[13:50] <apachelogger> yes, let's freeze that future
[13:50] <apachelogger> actually
[13:50] <apachelogger> lets take the opportunity to postpone things that won't be in the scope
[13:50]  * shadeslayer is sad, no one comments on his bugs
[13:51] <shadeslayer> apachelogger: *nod*
[13:51] <apachelogger> Riddell: https://trello.com/c/0uTGSJbM won't happen this cycle I guess?
[13:51] <shadeslayer> apachelogger: d_ed says he wants a new KTP in before FF
[13:51] <apachelogger> well, I want some ice cream
[13:51]  * shadeslayer hands apachelogger a cone and a ice cream machine
[13:52] <Riddell> apachelogger: unlikely
[13:52] <shadeslayer> apachelogger: FWIW I don't think that the upgrade option should be implemented
[13:52] <apachelogger> feature wise we are in a pretty good state I'd say
[13:53] <shadeslayer> it's hacky at best
[13:53] <apachelogger> shadeslayer: firefox apt has been handed off?
[13:53] <shadeslayer> apachelogger: yes
[13:53] <shadeslayer> apachelogger: not a feature, but a bug
[13:53] <shadeslayer> talk to seb128
[13:54] <apachelogger> shadeslayer: https://trello.com/c/w5Ji8mIw
[13:54] <d_ed> shadeslayer: apachelogger: we're about to make a beta, I want 0.8 in the final release of LTS
[13:54] <d_ed> is that possible?
[13:54] <apachelogger> d_ed: many things are possible, some things are just not as likely as others
[13:54] <shadeslayer> sure, but I'm conflicted on whether to include the 0.8 beta on the 14.04 beta
[13:55] <shadeslayer> apachelogger: card needs more details
[13:55] <apachelogger> details!
[13:55] <apachelogger> d_ed, shadeslayer: upload beta to 14.04 and please tell me that ktp 0.8 is feature frozen :P
[13:55] <Riddell> shadeslayer: do it!
[13:55] <d_ed> aye, we will be
[13:55] <shadeslayer> ^^
[13:56] <d_ed> I don't expect many changes between 0.8 beta and 0.8 release
[13:56] <shadeslayer> Riddell: do what ? :D
[13:56] <apachelogger> shadeslayer: details have been spewed
[13:57] <Riddell> shadeslayer: ktp 0.8 beta
[13:57] <apachelogger> shadeslayer: upload
[13:57] <shadeslayer> Riddell: ah ok
[13:57] <shadeslayer> apachelogger: upload what ? :S
[13:57] <apachelogger> if 0.8 is feature frozen anwyay and supposed to reach final before 14.04 there is no reason why one shouldn't do ktps' beta testing as part of our beta testing
[13:57] <apachelogger> shadeslayer: ktp
[13:58] <shadeslayer> d_ed: plz provide tarballs
[13:58] <d_ed> is by Monday ok?
[13:58] <shadeslayer> apachelogger: cool, will have a look at it post discussion
[13:58] <shadeslayer> d_ed: fine by me ;]
[13:58] <d_ed> cheers guys
[13:59] <apachelogger> I hate it when I write cards that are really epics
[13:59]  * apachelogger cries in the corner
[13:59] <Riddell> and yay I got gtalk working in ktp again!
[13:59] <apachelogger> such awesome.
[14:01] <d_ed> Riddell: hmm, what was broken?
[14:03] <Riddell> d_ed: I don't know, I just removed it and added again and it started working
[14:04] <shadeslayer> apachelogger: https://trello.com/c/0tn1vYPN
[14:04] <apachelogger> OO
[14:04] <shadeslayer> apachelogger: I've been using the settings for a couple of weeks
[14:04] <shadeslayer> and the fonts do look a tiny bit sharper
[14:04] <apachelogger> the question I guess is
[14:05] <apachelogger> why does the global fontconfig/freetype config not have this set
[14:05] <apachelogger> i.e. if we were to supply different settings via kubuntu-settings we'd start diverging from ubuntu platform settings
[14:06] <apachelogger> and that sounds like a pretty bad idea
[14:06] <apachelogger> in particular since neither of us knows anything much about fontconfig/freetype
[14:06] <shadeslayer> well, does ubuntu ship such a config?
[14:06] <shadeslayer> maybe they do and we don't know about it?
[14:06] <apachelogger> ask them
[14:06] <apachelogger> but it would be a platform setting
[14:07] <apachelogger> there is no point in supplying the font settings for one desktop I reckon
[14:07] <apachelogger> well, except for the case that some times someone is breakint font rendering in Qt so it all ends up being rubbish ^^
[14:07] <shadeslayer> heh
[14:11] <shadeslayer> apachelogger: anything else?
[14:12] <apachelogger> no, I don't know anything about font rendering :P
[14:12] <shadeslayer> neither do I :P
[14:13] <shadeslayer> but I was talking about any other cards that need discussing
[14:13] <shadeslayer> for Feature Freeze
[14:13] <sgclark> Riddell: not sure what going on with thse symbols, uploaded rebuilt libssh, no errors here.
[14:13] <shadeslayer> apachelogger: re https://trello.com/c/Mw5FBYpI http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6110
[14:14] <apachelogger> shadeslayer: there's no other feature cards apparently
[14:14] <apachelogger> or they are in doing
[14:14] <apachelogger> and hopefully will be done in time
[14:15] <apachelogger> well the qt path thing in startkde might be something
[14:16] <apachelogger> otherwise everything is in doing
[14:16] <shadeslayer> apachelogger: bug fix IMHO
[14:16] <apachelogger> so I guess the idea is to push that along as much as possible so everything lands before feature freeze
[14:16] <xnox> shadeslayer: i think the right approach is to inject javascript into webview which does "var distro='Buntu'; var distro_version='16.04'"
[14:17] <xnox> shadeslayer: and then slideshows should use script write that variable.
[14:17] <apachelogger> then we get the other changes cards done that might not have been features but aren't bugfixes either
[14:17] <apachelogger> and after that it's bug fixeroo all the way to final
[14:18] <shadeslayer> *nod*
[14:19] <shadeslayer> xnox: should be doable
[14:20] <shadeslayer> I think ...
[14:20] <shadeslayer> at the very least I see http://qt-project.org/doc/qt-4.8/qwebframe.html#evaluateJavaScript
[14:27] <shadeslayer> xnox: though I have no clue how the js side of things will work ;)
[14:40] <shadeslayer> apachelogger: could you fixup the bzr rev check in debian/common in kde-l10n-common?
[14:40] <shadeslayer> because the two ways I know don't work
[14:41] <Riddell> sgclark: libssh is all good, it's in
[14:42] <sgclark> Riddell: ok thank you
[14:52] <apachelogger> aaaaah, time
[14:52] <apachelogger> shadeslayer: please write a card
[14:52]  * apachelogger needs to leave in 8 minutes
[14:56] <xnox> shadeslayer: looks like not possible with current webkit/python api. we need a new one =/
[14:56] <shadeslayer> :(
[14:57] <shadeslayer> xnox: can the gtk web view allow setting HTML?
[14:57] <shadeslayer> if so, we can do the first solution till the next release
[15:00] <xnox> shadeslayer: yes, and no, setting html will not work here we need to load it.
[15:01] <xnox> shadeslayer: also why is it a problem? a 14.04 slideshow was already uploaded...
[15:02] <shadeslayer> xnox: https://trello.com/c/DtAwHbWR
[15:02] <shadeslayer> extra effort for translators apparently
[15:03] <shadeslayer> and if it's not translated, it looks like shit apparently
[15:03] <xnox> shadeslayer: the upload i did for s/13.10/14.04/ copied translation strings.
[15:03] <xnox> shadeslayer: and you are going to change translation string to omit 14.04, which will also retriger translation...
[15:04] <xnox> (thus 14.04 should not have less translations than 13.10 did for that versioned string)
[15:04] <shadeslayer> hmm, I see
[15:04] <shadeslayer> apachelogger: ^^
[15:05] <shadeslayer> postpone to 14.10?
[15:08] <sgclark> apachelogger: is packaging librocket something I can do?
[15:10] <shadeslayer> sgclark: so many KF alpha packages to poke at :)
[15:11] <sgclark> shadeslayer: what do you mean? need packaging?
[15:11] <shadeslayer> sgclark: some of them need packaging, others need rebuilding/fixing
[15:11] <sgclark> shadeslayer, oh ok, did not know
[15:13] <sgclark> shadeslayer: is there a list somewhere?
[15:15] <shadeslayer> sgclark: I posted a link somewhere in te backlog
[15:15] <shadeslayer> but can't find it anymore :(
[15:17] <shadeslayer> sgclark: maybe Riddell still has the link
[15:18] <Riddell> maybe I do
[15:19] <Riddell> http://paste.kde.org/psafkbfir
[15:19] <shadeslayer> there we go ^^
[15:19] <Riddell> but mostly click retry on all of these https://launchpad.net/~kubuntu-ppa/+archive/experimental/+packages
[15:20] <shadeslayer> sgclark: something that is sorely needed is adding versioning to build depends
[15:21] <Riddell> it's all in bzr now so stuff like that can just be added to bzr without having to upload to the PPA
[15:21] <Riddell> is there not new frameworks to package?  plasma-framework? something else?
[15:21] <shadeslayer> yep that too
[15:22] <shadeslayer> Riddell: do you think we can land a KWallet PAM module which will only work with KDE SC 4.13 before KDE SC 4.13?
[15:25] <sgclark> Riddell: I do not have option to click retry. Shadeslayer: don't know what you  mean by versioning
[15:25] <Riddell> shadeslayer: will it break anything?
[15:26] <Riddell> sgclark: I just added you to the team so you should be able to click retry
[15:26] <Riddell> although really it should be scripted
[15:27] <shadeslayer> apachelogger: fyi flash plugin install does not work in Ubuntu too
[15:27] <sgclark> Riddell: ok ty.
[15:28] <sgclark> Riddell or shadeslayer, so if it fails again I need to repackage/fix it correct?
[15:29] <Riddell> depends on the failure, it might just be waiting for something else to compile first
[15:29] <shadeslayer> ^^
[15:29] <sgclark> ok
[15:33] <shadeslayer> ahoneybun: valorie: plz review migration guide from a docs POV https://notes.kde.org/p/kubuntu-migration-guide
[15:41] <jussi> anyone tried today's dail.y yet?
[15:43] <jussi> hrm, links to the images are wrong on the qa tracker thiogn
[16:19] <sgclark> Riddell: pbuilder fails with http://paste.ubuntu.com/6926219/ I remember seeing this before I just don't remember what we did, all the patches appear to have been removed.
[16:35] <jussi01> ok, so now the fun begins...
[16:36] <sgclark> Riddell: nevermind I figured it out
[16:38] <sgclark> Riddell: frameworkintegration ready for you
[16:39] <jussi01> at the partitioning screen with a totally blank drive, using guided, use entire disk, the after part says "Kubuntu 1.0B" - this seems weird, no?
[17:08] <shadeslayer> sgclark: how did you solve that test issue?
[17:08] <sgclark> shadeslayer: added X support
[17:08] <sgclark> shadeslayer: openbox trick
[17:09] <shadeslayer> openbox? :)
[17:09] <shadeslayer> can I have a look at your rules file?
[17:10] <sgclark> shadeslayer: http://paste.ubuntu.com/6926489/
[17:10] <shadeslayer> sgclark: what happens you just run xvfb-run -a dh_auto_test ?
[17:11] <shadeslayer> and well, also export the dbus-launch variables
[17:11] <sgclark> shadeslayer that is what I had when it failed
[17:12] <sgclark> does not fail local, just in pbuilder which has no X support
[17:12] <shadeslayer> sgclark: which package is that?
[17:13] <sgclark> frameworkintegration
[17:16] <ScottK> apachelogger: It's the dialogue you get when more packages are needed due to dependency and have to be added to the set to be installed, but in this case they aren't really required.
[17:22] <shadeslayer> sgclark: does the test take quite a bit of time?
[17:23] <sgclark> shadeslayer: nope
[17:35] <shadeslayer> sgclark: fwiw when using  /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk please use overriden_target
[17:35] <shadeslayer> instead of calling dh_auto_test
[17:35] <shadeslayer> so something like : xvfb-run -a $(overriden_target)
[17:35] <sgclark> shadeslayer: I have no idea what you mean sorry
[17:36] <shadeslayer> sgclark: in debian/rules, if you include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk
[17:36] <shadeslayer> plz use $(overriden_target) inside target overrides
[17:36] <sgclark> ahh ok, did not know sorry
[17:38] <shadeslayer> sgclark: do you know *why* calling dh_installwm causes it to work?
[17:39] <sgclark> shadeslayer: because it adds X support? I do not know the nitty gritty of lower level operating system functionality sorry :(
[17:39] <shadeslayer> no, that's from xvfb-run
[17:39] <shadeslayer> see man xvfb-run
[17:40] <sgclark> shadeslayer: I meant window manager sorry
[17:40] <sgclark> those calls are being made to the window manager
[17:40] <sgclark> pbuilder  and the build farms do not have that support
[17:41] <sgclark> hense why the openbox trick works, I feel like I did something wrong?
[17:42] <shadeslayer> hmm, I don't think those calls go to a window manager since openbox isn't actually installed on my pbuilder
[17:42] <shadeslayer> sgclark: well, I'm trying to figure out why that works
[17:44] <sgclark> Riddell: may have better answers for you, he was around when I discovered it.
[17:45] <sgclark> and is has alot more knowledge than I
[17:45] <sgclark> openbox has to be listed as a build depend
[17:46] <shadeslayer> well, since it's working without it being installed, it clearly doesn't need to be listed as a build-depend
[17:49] <shadeslayer> Riddell: ^^ why does dh_installwm make things work>
[17:49] <shadeslayer> it's just generating postinst and prerm files is it not?
[17:52] <sgclark> shadeslayer: it will fail on the build farms without it.
[17:57] <shadeslayer> sgclark: ok, but why ? :)
[17:58] <shadeslayer> sgclark: thing is, dh_installwm just generates some postinst and prerm files
[17:58] <shadeslayer> and man pages
[18:02] <sgclark> did you see the tests that fail? maybe look at those and compare to what installwm does to see why? I am not yet a coder so I am not much help, I am sorry : /
[18:03] <jussi> is nvidia in trusty borked or is it just me?
[18:03] <shadeslayer> I did have a quick look at installwm
[18:04] <shadeslayer> and it doesn't make any sense to me :P
[18:04] <shadeslayer> ( why running installwm would work that is )
[18:40] <allee> shadeslayer: maybe you know: where does user-manager store the email?  I stare at the code and don't get it :-(
[18:41] <shadeslayer> it stores it with account service afaik
[18:43] <allee> shadeslayer: and where does account service store it?  The usual 'Save' and: fiind ~/.??* -cmin -2 does not work :-(
[18:44] <apachelogger> ScottK: mh, ok, I'll try to come up with a debug patch tomorrow
[18:44] <shadeslayer> allee: try qdbus --system org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.Email
[18:44] <apachelogger> ScottK: FWIW I think that is qapt being silly
[18:44] <shadeslayer> btw if you add the kdeconnect plasmoid to the systemtray , does plasma start for you?
[18:44] <shadeslayer> ( make sure everything is updated )
[18:45] <apachelogger> shadeslayer: please do not upstream bugs yourself, if one has further questions for debugging you won't be able to provide them
[18:45] <apachelogger> ohohohoho, talking about kdeconnect
[18:45] <apachelogger> we need to get that listed in discover somehow
[18:45] <apachelogger> seeing as it is going to be come a featured app
[18:45] <allee> shadeslayer: uh. magic!  Thx     Me continues hunting storage place ...
[18:45] <shadeslayer> apachelogger: actually, I will be able to, I could reproduce the search bug at the very least
[18:46] <shadeslayer> apachelogger: https://bugs.kde.org/show_bug.cgi?id=331116
[18:47] <apachelogger> shadeslayer: in refernece to teh qaptworker one
[18:48] <apachelogger> that will likely need excessive gdb fiddling
[18:48] <apachelogger> just thought I'd point it out in general though
[18:49] <shadeslayer> roger roger
[18:49] <shadeslayer> apachelogger: I was testing muon discover today
[18:49] <shadeslayer> discovered that it had a upgrade feature
[18:49] <shadeslayer> which is quite bad :/
[18:50] <apachelogger> yeah
[18:50] <apachelogger> master is somewhat better
[18:50] <shadeslayer> do we want to get that in before FF?
[18:50] <apachelogger> actually we were thinking about handling upgrades through discover for 2.2, but it's still not quite there
[18:50] <apachelogger> shadeslayer: yeah
[18:50] <shadeslayer> add a card for it?
[18:50] <apachelogger> I guess
[18:51] <shadeslayer> apachelogger: so, regarding firefox plugins
[18:51] <apachelogger> talking about cards, new numbers: 28 todo, 18 doing, 46 done, 12 postoned, 9 abandoned \o/
[18:52] <shadeslayer> they don't work on ubuntu too
[18:52] <apachelogger> shadeslayer: yeah, I figured
[18:52] <apachelogger> shadeslayer: but even if it did we wouldn't be able to use it because that would be piped through aptworker which is in a bit of a conflict with qaptworker
[18:52] <apachelogger> eh
[18:52] <apachelogger> s/aptworker/aptdaemon
[18:52] <shadeslayer> apachelogger: was trying to read the code, and it just went over my head
[18:52] <apachelogger> shadeslayer: yes, I had pretty much the same experince
[18:53] <shadeslayer> so I tried writing my own plugin, but that's not something I can whip up in a day or two
[18:53] <apachelogger> mostly mad that mozilla stuff ix :P
[18:53] <shadeslayer> since I have no experience with FF plugins
[18:53] <shadeslayer> ( side note : xul reads like it was developed by a mad man )
[18:54] <apachelogger> shadeslayer: well, I'd suggest talking to the ubuntu-mozilla team, perhaps we somehow can fiddle in some sort of support into ubufox
[18:54] <shadeslayer> though apparently you can hook xul up with C++ code
[18:54] <shadeslayer> using autotools ....
[18:54] <apachelogger> i.e. if we only call qapt-batch-installer it would still be somewhat sensible
[18:54] <apachelogger> after all, that is what we did for rekonq and it's pretty non-invasive
[18:55] <apachelogger> in fact the only thing we needs is a dbus call and handle the rest in kubuntu-notification-helper
[18:55] <shadeslayer> apachelogger: I was thinking more along the lines of just poking the user with the restricted plugin install dialog
[18:55] <shadeslayer> exactly
[18:55] <apachelogger> shadeslayer: maybe, I'd still talk to them, perhaps someone is feeling generous and coudl whip up a simple plugin to do that
[18:55] <shadeslayer> apachelogger: I talked to chriscoulson and he has 0 time
[18:56] <apachelogger> well that's unfortunate
[18:56] <shadeslayer> even for apturl issues
[18:56] <apachelogger> shadeslayer: maybe spy what other distros do
[18:56] <shadeslayer> hmm
[18:57] <shadeslayer> suse at the very least ships kde patches
[18:57] <shadeslayer> apachelogger: btw I was also fidding with various protocol support handlers
[18:57] <shadeslayer> and it's not just apt that's broken, every protocol that you try and register won't work
[18:57] <shadeslayer> so for eg. try registering magnet -> doesn't work
[18:58] <apachelogger> see, we should have gone with chromium
[18:58] <apachelogger> I said it all along :P
[18:58] <mamarley> Firefox for the win!!!
[18:59] <Peace-> apachelogger: why?
[18:59] <shadeslayer> apachelogger: unfortunately, I own a "I <3 Mozilla" wristband and cannot in good conscience say we should ship Chromium
[18:59] <apachelogger> shadeslayer: lol
[18:59] <Peace->  shadeslayer xD
[18:59] <apachelogger> shadeslayer: actually I think it is entirely possible that canonical will eventually go to chromium
[19:00] <apachelogger> unless mozilla is throwing sweets at them
[19:00] <mamarley> I would own an "I <3 Mozilla" wristband if Mozilla would actually sell them to non-Mozillians...
[19:05] <shadeslayer> mamarley: https://bugs.kde.org/show_bug.cgi?id=331116
[19:05] <shadeslayer> erm
[19:05] <shadeslayer> https://plus.google.com/photos?pid=5979961400218894194&oid=115138410189586016392
[19:06] <mamarley> Darn, I seem to have forgotten my Google+ password...
[19:06] <shadeslayer> mamarley: http://imgur.com/XZje9HL
[19:06] <mamarley> Nice :)
[19:07] <shadeslayer> apachelogger: http://imgur.com/XZje9HL
[19:07]  * mamarley has been a die-hard Firefox user since one of his friends in high school converted him from IE6 about 9 years ago.
[19:07] <shadeslayer> apachelogger: I'm bored
[19:07] <shadeslayer> apachelogger: nothing interesting on trello
[19:07] <shadeslayer> and the interesting bits I don't know how to do
[19:07] <mamarley> Ironically, that person is now an Apple® fanboy.
[19:08] <shadeslayer> :D
[19:09] <Peace-> mamarley: lol
[19:09] <shadeslayer> Riddell: do you reckon we can remove kdeconnect-kde from Trusty?
[19:13] <shadeslayer> apachelogger: btw plz also check my kconf_update work
[19:18] <apachelogger> shadeslayer: card plz
[19:19] <shadeslayer> apachelogger: already there
[19:31] <ScottK> apachelogger: It may well be qapt.  Not sure.
[19:55] <shadeslayer> Riddell: https://bugs.launchpad.net/ubuntu/+source/kdeconnect-kde/+bug/1279949 when you get the time
[20:31] <apachelogger> shadeslayer, Riddell: doesn't bluedevil 2rc only work with bluez5?
[20:32] <apachelogger> bug 1279960
[20:32] <apachelogger> ehm
[20:32] <apachelogger> If your distro is using BlueDevil 2.0 you must:
[20:32] <apachelogger> 1-Use at least BlueZ 5.11 [1]
[20:32] <apachelogger> Riddell: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[20:33] <shadeslayer> ^^
[20:33] <shadeslayer> apachelogger: Alex confirms
[20:33] <apachelogger> doctor said instead of raging I should sigh
[20:34] <apachelogger> so imagine me sighing while the veins on my head are throbbing
[20:34] <shadeslayer> apachelogger: http://paste.kde.org/pvkkp715o
[20:35] <shadeslayer> this format is so bad :<
[20:35] <apachelogger> why it is beautiful
[20:36] <apachelogger> html markup is something we should use a lot more
[20:36] <apachelogger> such a pleasent read as well
[20:37]  * shadeslayer heads home for dinner
[21:17] <ScottK> shadeslayer: Shouldn't kdeconnect provide a kdeconnect-kde transitional package for upgrades?
[21:19] <ScottK> apachelogger: ^^^
[21:35] <shadeslayer> ScottK: I have a package ready for upload
[21:35] <shadeslayer> once kdeconnect-kde is removed I'll upload
[21:35] <shadeslayer> or should I upload anyway?
[21:44] <ScottK> Let me do the removal and then wait a publisher cycle.
[21:44] <ScottK> Hang on.
[21:45] <ScottK> shadeslayer: Removed.  Wait half an hour and upload.
[21:45] <shadeslayer> thx
[22:34] <shadeslayer> ScottK: plz upload https://launchpad.net/~rohangarg/+archive/experimental/+files/kdeconnect_0.4.2-2ubuntu2.dsc
[22:35] <shadeslayer> I'm not elite enough
[22:45] <ScottK> If you got MOTU ....
[22:49] <ScottK> Done.
[22:57] <valorie> shadeslayer: I've added my suggestions to the migration doc
[22:58] <shadeslayer> thanks valorie :)


[10:00] <ricotz> tseliot, please apply fixes correctly https://github.com/tseliot/nvidia-graphics-drivers/commit/27adcaeb811c7bb225a9ae001674557228a79afa
[10:00] <ricotz> +#LIBDIR#/vdpau/vdpau/libvdpau_nvidia.so.#VERSION#                               #LIBDIR#/vdpau/libvdpau_nvidia.so
[10:01] <tseliot> ricotz: I haven't uploaded anything yet, as I have to unblock things in -proposed first
[10:01] <tseliot> but yes, I'll fix that
[10:02] <ricotz> tseliot, hi, better don't get it NEWed at all and make the "fixed" version the first which enters the archive
[10:02] <ricotz> nvm
[10:03] <ricotz> it got NEWed :(
[10:03] <tseliot> ricotz: BTW, all the changes I made, caused i386 and armhf to fail, for some reason https://launchpad.net/~albertomilone/+archive/ubuntu/nvidia-glvnd-temp/+packages
[10:03] <ricotz> i386 built fine
[10:04] <ricotz> for my earlier version
[10:04] <ricotz> https://launchpad.net/~ricotz/+archive/ubuntu/experimental/+packages
[10:04] <tseliot> I haven't looked into the binary-arch failure
[10:05] <ricotz> did you thought about libnvidia-compute-* yet?
[10:06] <tseliot> ricotz: the conflicts/replaces ?
[10:06] <ricotz> I can take another look after lunch
[10:07] <ricotz> yes, those doesn't play well with mulitarch
[10:07] <tseliot> ricotz: yes please, I'm very busy right now
[10:13] <ricotz> tseliot, I assume you didn't push everything yet, git doesn't match the upload
[10:14] <tseliot> ricotz: no, as I couldn't test it. It's all in git, just in case
[10:14] <tseliot> that would be the 390-ppa branch
[10:15] <ricotz> ah, I see, was looking at 390 branch
[13:15] <ricotz> tseliot, pushed some changes to https://github.com/ricotz/nvidia-graphics-drivers/commits/390-ppa
[13:17] <ricotz> built here https://launchpad.net/~ricotz/+archive/ubuntu/experimental/+packages
[13:55] <tseliot> ricotz: thanks, I'll have a look at them later
[14:31] <ricotz> tseliot, more fixes coming
[14:31] <tseliot> ricotz: thanks, I'll check them all out
[14:57] <ricotz> tseliot, pushed
[14:58] <tseliot> thanks again
[15:03] <ricotz> tseliot, btw, why did you switch to the not "no-compat32" source?
[15:04] <tseliot> ricotz: because the i386 package is going to be built on i386 anyway
[15:04] <ricotz> exactly, but you are not using the no-compat32 run binary
[15:06] <ricotz> (of course this can only be changed with the next upstream release)
[15:07] <tseliot> I thought I did
[15:07] <tseliot> too many negations :D
[15:07] <ricotz> NVIDIA_DIRNAME_amd64	 = NVIDIA-Linux-x86_64-${NVIDIA_RELEASE}
[15:07] <ricotz> NVIDIA_FILENAME_amd64	 = ${NVIDIA_DIRNAME_amd64}.run
[15:10] <tseliot> yes, we'll use the no-compat one
[15:13] <ricotz> this call seems to fail on install https://github.com/tseliot/nvidia-graphics-drivers/blob/390-ppa/debian/templates/nvidia-dkms-flavour.postinst.in#L75
[15:14] <tseliot> I must have changed something when I removed the delayed build code
[15:16] <ricotz> I think the earlier version parsing is broken at some point and the arguments for dpkg are incomplete
[15:16] <ricotz> "dpkg: Fehler: Version »-« hat falsche Syntax: Revisionsnummer ist leer"
[15:23] <tseliot> yes, that's the result of heavy multi-tasking with no testing
[15:24] <ricotz> I think "generate-modaliases" is running too early
[15:24] <ricotz> it should be run after install


[10:50] <mcclurmc> rogpeppe: hey, i just finished that intro to go and juju blog we talked about
[10:50] <mcclurmc> rogpeppe: http://mcclurmc.wordpress.com/2012/11/05/go-lang-and-juju/
[10:50] <rogpeppe> mcclurmc: i'm just reading it!
[10:51] <mcclurmc> awesome
[10:51] <rogpeppe> mcclurmc: looks good
[10:51] <mcclurmc> should i spam the juju list about it?
[10:56] <rogpeppe> mcclurmc: i think you should explain the ... wildcard feature of the go command, as you use it quite a bit
[10:58] <rogpeppe> mcclurmc: in fact the "go doc launchpad.net/.../ec2" example should perhaps be "go doc launchpad.net/goamz/ec2" to avoid confusion
[11:00] <rogpeppe> mcclurmc: BTW version pinning is often done by importing code locally and renaming the package path. another alternative is to put the version into the package path (e.g. labix.org/v2/mgo)
[11:00] <rogpeppe> mcclurmc: other than the above minor comments, this looks great - i'd post to both the juju list and the juju-dev list
[11:45] <mcclurmc> rogpeppe: my irc proxy lost the minor comments you had. could you repeat them?
[11:46] <rogpeppe> 10:56:56] <rogpeppe> mcclurmc: i think you should explain the ... wildcard feature of the go command, as you use it quite a bit
[11:46] <rogpeppe> [10:58:29] <rogpeppe> mcclurmc: in fact the "go doc launchpad.net/.../ec2" example should perhaps be "go doc launchpad.net/goamz/ec2" to avoid confusion
[11:46] <rogpeppe> [11:00:11] <rogpeppe> mcclurmc: BTW version pinning is often done by importing code locally and renaming the package path. another alternative is to put the version into the package path (e.g. labix.org/v2/mgo)
[11:46] <rogpeppe> [11:00:48] *** mcclurmc is now known as mcclurmc_away.
[11:46] <rogpeppe> [11:00:58] <rogpeppe> mcclurmc: other than the above minor comments, this looks great - i'd post to both the juju list and the juju-dev list
[11:46] <mcclurmc> rogpeppe: cool, i'll make the changes and post to the lists. thanks!
[11:47] <rogpeppe> mcclurmc: one other thing - you could also mention something about the changes required to environments.yaml
[11:47] <rogpeppe> mcclurmc: and perhaps you could end by bootstrapping a juju instance...
[11:47] <rogpeppe> mcclurmc: assuming that succeeds, of course :-)
[11:48] <mcclurmc> rogpeppe: yes, that would be a good idea. i need to create an ec2 account since the local lxc doesn't work
[11:48] <rogpeppe> mcclurmc: yes, that's true - an unfortunate current limitation
[12:04] <rogpeppe> davecheney: yo!
[12:05] <mcclurmc> rogpeppe: i just made those changes. instead of giving a juju bootstrap howto, i linked to https://juju.ubuntu.com/docs/getting-started.html
[12:06] <rogpeppe> mcclurmc: cool
[17:43] <SpamapS> does juju-core just log everything to syslog?
[17:43] <SpamapS> oh please oh please tell me it does
[22:11] <rogpeppe> SpamapS: i wish it did
[22:11] <rogpeppe> SpamapS: but it doesn't
[22:11] <rogpeppe> SpamapS: it writes to /var/log/juju/*


 The Kubuntu UEFI OEM lacks a mouse pointer. The installer runs and mostly responds to keyboard input but some of the dropdown menus do not. Thus, changing the hard drive dropdown is not possible with keyboard only input.
 https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1869451
[06:00] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop amd64 [Focal Beta] (20200328) has been added
[13:44] <BluesKaj> Hi folks
[13:53] <RikMills> valorie: I am dropping kio-grive off the ISO for the beta. can we please however recommend that people install it and test with a look to restoring?
[13:54] <RikMills> I want it off for now, as the libgapi libs it requires being seeded may complicate a PIM FFe
[19:13] <valorie> RikMills: ok
[19:13] <valorie> last I checked it didn't work for me
 Have been trying to start to work on PIM today, and keep getting other bugs jump out. lol
 @RikMills, What a PIM in the you-know-what.
[20:08] <valorie> amazing, who could predict bugs in PIM!
[20:09] <Eickmeyer> ^
 Actually, I meant mostly plasma bugs!
[20:10] <valorie> lol
[20:11] <valorie> fixitfixitfixit
[20:11] <Eickmeyer> While I'm here, I might as well say it: Ubuntu Studio is 90% sure to switch to Plasma beginning with 20.10.
[20:13] <valorie> cool
[20:14] <Eickmeyer> It'll be my pet project next cycle to get the seed switched.
[20:14] <valorie> paul brown will be over the moon
[20:14] <valorie> in #kde-promo
[20:15] <valorie> he's been talking with indie creative projects to come into the KDE community
[20:15] <Eickmeyer> Oh, I'm sure. Driving factors: My dev lead (Len Ovens) wants to use Kubuntu 20.04 with the Ubuntu Studio bolt-on as his daily driver. My design lead (Eylul Dogruel) already uses Kubuntu with the Studio bolt-on. It's just proving to be better for creative types than Xfce.
[20:15] <valorie> if they do, that could make your work a bit easier perhaps
[20:16] <Eickmeyer> So, if the team is already doing it, and we've had numerous requests from the community, it seems like post-LTS release would be the perfect time.
[20:17] <valorie> good to hear, Eickmeyer
[20:17] <valorie> if we all live through this!
[20:17] <valorie> so far, so good here
[20:17] <Eickmeyer> Same. My wife is an essential worker (childcare director) so we're not losing income, but she's definitely more in harm's way than myself and my son.
[20:18] <valorie> yeah
 It's not a zombie apocalypse yet, so I think I am good.
[20:19] <valorie> @RikMills your zombie-in-chief is in self-isolation
[20:19] <valorie> so it's all good
 haha