[01:16] <manchicken> Stupid wifi notification won't go away.
[02:07] <manchicken> I can't think of anything to do.
[02:58] <valorie> manchicken: from earlier: 16:47] <sitter> [18:01:17] anyone with vivid who wants to test 5.2.0?
[02:58] <valorie> sitter is offline, Riddell is out, etc.
[02:59] <manchicken> I'm online
[02:59] <manchicken> ^_^
[02:59] <manchicken> I asked earlier but they were out then. I sent an email.
[03:00] <valorie> anyway, that one ask is all I saw in the backlog
[03:00] <valorie> and I've not upgraded to vivid yet
[03:02] <manchicken> I'm on vivid. It's got some weird issues still.
[03:02] <manchicken> Which is - of course - expected.
[03:02] <manchicken> No show stoppers, just major annoyances.
[03:03] <manchicken> Notifications for wifi are completely nuts. I've had this wifi notification popup on my screen since I first connected. It won't go away.
[03:03] <valorie> I sometimes know how to fix/get around issues, but am no expert
[03:03] <valorie> which is why I'm holding back
[03:03] <manchicken> Where's your sense of adventure?
[03:03] <valorie> I have no backup machine right now
[03:04] <manchicken> heh
[03:04] <valorie> and actually, need to do a backup of /home on this one too
[03:04] <valorie> not enough hours in the day, really
[03:04] <manchicken> I'm backing up my mobile now so I can reset it. Lollipop really harmed performance for me, I'm going to see if resetting it will help.
[05:37] <SonikkuAmerica> Clue me in: Is the "14.12.0" for the PPA that downgrades to KDE 4?
[05:40] <valorie> there is a ppa that downgrades?
[05:40] <valorie> um
[05:41] <valorie> how can that even be possible?
[05:42] <SonikkuAmerica> Maybe "downgrade" is the wrong word...
[05:42] <valorie> it's vivid, according to http://qa.kubuntu.co.uk/ninjas-status/build_status_14.12.0_vivid.html
[05:42] <SonikkuAmerica> I meant the KDE version, not Kubuntu itself
[05:43] <valorie> keep in mind that "14.12.0" is the applications
[05:43] <valorie> nothing to do with plasma 5 or frameworks 5 in the numbering
[05:44] <SonikkuAmerica> Oh.
[05:44] <SonikkuAmerica> Lol, clumsy me can't read the description. :P
[05:46] <valorie> there is an email on release-team and K-c-d about it
[05:46]  * valorie wouldn't touch it yet....
[05:46] <valorie> called "Apps 14.12 release aftermath / Running KF5 apps in KDE 4"
[05:47] <valorie> of course we're not shipping "kde4" in vivid
[05:49] <SonikkuAmerica> So this is the PPA for Apps 14.12 ... feels a bit like Ubuntu GNOME where all the extra GNOME apps (that arguably give GNOME that, well, pure GNOME look and feel) get stuck in (at least) one PPA
[05:52] <SonikkuAmerica> Whoa! Why does whoopsie have a hard dependency on an old version of libwhoopsie0?
[05:53] <SonikkuAmerica> depends on 0.2.39 but installed version is 0.2.44
[05:53] <valorie> oooo, please file a bug report
[05:53] <SonikkuAmerica> Will do immediately.
[05:53] <valorie> sitter will want to know about that
[05:54] <valorie> ninjas is very early stuff, SonikkuAmerica
[05:54] <valorie> we're not even to beta with Vivid
[05:55] <SonikkuAmerica> Well, with this at least we can fix one problem with in-place upgrades
[05:56] <SonikkuAmerica> I could also check the daily-build contents as well
[05:56] <SonikkuAmerica> (I would assume the correct assertion would be in there)
[05:56] <valorie> I want to be able to upgrade, yeah
[05:57] <valorie> not brave enough to do it yet
[05:57] <SonikkuAmerica> Well I test in odd and weird situations, so I guess this is one for you guys at Kubuntu dev team to munch on.
[05:58] <valorie> yep
[05:58] <SonikkuAmerica> I actually spotted where the mismatch originated. Apparently the version of whoopsie in vivid is still pointing to the version of libwhoopsie0 used in Utopic
[06:00] <valorie> these guys are doing so incredibly much at the same time
[06:00] <valorie> thanks so much for reporting the bug
[06:06] <SonikkuAmerica> Also I should mention that I already made the switch to systemd
[06:08] <valorie> working well for you?
[06:08] <SonikkuAmerica> Absolutely. (I had experience messing with it in ArchLinux with GNOME.) Learned the ins and outs of creating .service files too while I was at it
[06:09]  * SonikkuAmerica is picking up a 15.04 Alpha 2 image for a clean install
[06:09] <valorie> be sure to report your results to the qa tracker
[06:10] <SonikkuAmerica> Right.
[06:13] <SonikkuAmerica> https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1414899
[06:15] <valorie> thank you, SonikkuAmerica
[07:13] <soee> good morning
[07:14] <Riddell> hi soee
[07:15] <Riddell> well my e-mail is back working today, I wonder how many I've missed and how many mailing lists I've unsubscribed from
[07:15] <soee> hihi, Riddell do you have yesterdays history ? I posted 2 paste.ubuntu.com links with Plasma 5.2 upgrades problems
[07:19] <Riddell> ah libkwinxrenderutils5 -> libkwinxrenderutils6 transition
[07:19] <Riddell> ok I'll tidy that up
[07:33] <lordievader> Good morning.
[09:41] <sitter> :O
[09:42] <sitter> I always marvel at the ppa-build-status script
[09:47] <Riddell> sitter: so what to do with all these backports?
[09:47] <Riddell> sitter: are they ready for testing and moving to kubuntu-ppa/next-backports?
[09:48] <sitter> staging utopic still
[09:48] <sitter> shadeslayer didn't run the backport :@
[09:49] <sitter> Riddell: vivid is good for testing though
[09:49] <sitter> minus the not released bits, minus muon (deps still stuck in proposed), minus bludevil (bluez5 migration, when is that happening anyway?)
[09:52] <Riddell> sitter: bluez, rather like qt, seems to be stuck on unity crap
[09:52] <Riddell> hassle didrocks about it https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions/+packages
[09:52] <sitter> kubotu: order vodka
[09:52]  * kubotu slides vodka down the bar to sitter
[09:53] <Riddell> not until midday!
[09:54] <sitter> bluez - blocked; qt - blocked; packagekitqt - blocked; telepathy-qt - blocked;
[09:55]  * sitter fails to read the build-status script
[09:56] <Riddell> which happens in a large project with lots of different dependencies, it just seems to happen a lot now, and it kindae predictable with canonical wanting to write their own desktop that they don't have the resources to look after all of it
[09:56] <sitter> I totally fixed it at some point, why is it broken again -.-
[09:56] <sitter> Riddell: nm /minor/ release landed some 1.5 years after its upstream release :P
[09:57] <sitter> on the plus side I have been told nm 1.0 ought to land in vivid as well
[09:59] <Riddell> sitter: minor release of what?
[09:59] <sitter> networkamanger
[10:00] <sitter> which I reckon isn't really minor considering it is networkmanager xD
[10:07] <Riddell> kde-runtime uploaded with qapt depends removed, maybe that'll get muon into the archive
[10:07] <Riddell> sitter: for the trello, what is telepathy-qt blocked on again?
[10:08]  * Riddell just puts "waiting on unity stuff"
[10:09] <Riddell> Quintasan: don't forget you're due to sort out ksnakeduel name
[10:09] <sitter> Riddell: canonical specific public API patches
[10:10] <sitter> I did not take a look since last time though, so maybe it can get unblocked but I distinctly remember that there was an API addition that didn't seem to map to any of the upstream changes
[10:10] <Riddell> mm yes
[10:10] <sitter> ah ah ah
[10:10]  * sitter blind
[10:11] <sitter> kfilemetadata and baloo are red because their versions are different
[10:11] <Riddell> d_ed: also said he'd look at upstreaming it but it's not like it's fun stuff to work on
[10:11] <sitter> such smart script
[10:11] <Riddell> yes the script needs a fix there
[10:11] <sitter> I think this script needs more fixes than that
[10:11] <Riddell> well yes
[10:14] <sitter> does python have a static global variable type?
[10:15] <Riddell> goodness no
[10:15] <Riddell> but that sounds mildly evil
[10:16] <sitter> what's wrong with having a variable that only is initialized once? :O
[10:17] <Riddell> global variables are usually frowned upon
[10:18] <sitter> http://bazaar.launchpad.net/~kubuntu-packagers/+junk/kubuntu-automation/revision/504
[10:18] <sitter> ....
[10:18] <sitter> Riddell: the important part is the staticness not the globalness :P
[10:18] <sitter> interestingly I didn't need globalness anyway because the script is very efficient spagetthi holding everything in the main scope...
[10:26] <Riddell> kglobalaccel_5.6.0-1_amd64.changes is NEW  says Debian FTP masters
[10:36] <sitter> Riddell: when are you done with 5.2.0 release procedure?
[10:36] <mitya57> maxy uploaded lots of stuff in the last days
[10:40] <Riddell> sitter: wanting to tidy up the announce and make publish shortly
[10:40] <Riddell> sitter: why do you ask?
[10:40] <sitter> Riddell: I want to merge documentation fixes into releaseme
[10:40] <sitter> and then carry the entire thing into master
[10:40] <Riddell> oh go ahead
[10:41] <Riddell> but I have a lot of plasma release crap in that branch so maybe make a plasma branch for me to keep that in?
[10:41] <sitter> Riddell: if you were to respond to my mail about plasma bits :P
[10:41] <Riddell> sitter: which one?
[10:42] <sitter> the one were I said it should be rubeh :P
[10:42] <sitter> well rubeh or yaml
[10:43] <sitter> I rather see the benefit in composing a meta release as a simple yaml config and have tarme deal with how to best get the things
[10:44] <sitter> anyway, before it goes to master I want to finish up manual configuration, the projects xml does not always scale as well as it should
[10:56] <sitter> Riddell: what goes into the next-backports ppa, I forgot
[11:00] <Riddell> sitter: utopic qt5/kf5/plasma5 backports
[11:00] <Riddell> was my plan
[11:01] <Riddell> and applications too
[11:01] <sitter> was there a reason not to put it into next?
[11:01] <sitter> ah, qt54 possibly wouldn't be too good
[11:01] <Riddell> right, I'd worry that would break something
[11:01] <sitter> k
[11:02] <sitter> so we need update test from next to -> stage0+stage1+stage2+utopic-qt5
[11:02] <sitter> actually
[11:02] <sitter> applications need to get split
[11:02] <Riddell> oh meh, faff
[11:02] <sitter> the majority of them have nothing todo with next
[11:08] <sitter> Riddell: I don't get why muon doesn't migrate
[11:08] <sitter> everything is marked as valid candidate now
[11:09] <sitter> oh oh, driver-manager maybe
[11:10] <sitter> if britney output wasn't so atroxious
[11:10] <sitter> maybe even correctly spelled
[11:10]  * sitter hungry
[11:10] <shadeslayer> sitter: https://www.youtube.com/watch?v=t3otBjVZzT0
[11:15] <sitter> ah
[11:15] <sitter> Riddell: I think kde-runtime is blocking it
[11:16] <sitter> seems you uploaded a fix
[11:16] <Riddell> I did
[11:38] <mitya57> Hi shadeslayer, can you please quickly review http://mitya57.me/tmp/pkg-kde-tools_0.15.15ubuntu1_0.15.16ubuntu1.debdiff which I am going to upload?
[11:38] <mitya57> Most is trivial except maybe kf5.pm part
[11:39] <mitya57> Also qt-kde-team/1/policy.mk delta was mentioned in changelog, but was lost in previous uploads for some reason.
[11:40] <Riddell> sitter: tagme runs ruby at 100%cpu and doesn't seem to do much :(
[11:41] <Riddell> sitter: https://paste.kde.org/pcu7yfuay
[11:43] <sitter> Riddell: for how long?
[11:43] <sitter> it was still doing project resolution that can take a while
[11:43] <sitter> actually
[11:43] <sitter> mh
[11:43] <sitter> Riddell: you did not specify a name now did you?
[11:43] <sitter> oh with tagme you wouldn't
[11:44] <sitter> Riddell: are you sure your release_data is correct?
[11:44] <Riddell> http://starsky.19inch.net/~jr/tmp/release_data
[11:45] <Riddell> --MARK--
[11:46] <sitter> ewww
[11:46] <sitter> cabbage juice was the worst idea ever
[11:47] <sitter> Riddell: I think it is just really very slow
[11:48] <sitter> it does walk the entire xml document for each project
[11:50] <Riddell> sitter: yeah it's going now
[11:50] <Riddell> sorry for the noise
[11:52] <sitter> well it is a bit of a problem
[11:52] <sitter> alas, not one that is necessarily easy to work out
[11:54] <sitter> the problem is that release_data holds each invidiual project name, so where tarme would make one query "give me all workspace things", tagme needs to do "give me plasma-workspace, now give me plasma-desktop, now give me ksysguard..." and each of those need to traverse the entire xml because each of those identifiers could be either a component or a module or a project or a subproject of a project
[11:54] <sitter> it's why I raged about the projects xml when I redid the parser :P
[11:55] <sitter> the probably best solution is to expand release_data, make it yaml or json and basically marshal the project class which encapsulates the information found in the xml
[11:55] <sitter> that way nothing but tarme needs to even look at the xml
[11:56] <sitter> alternatively release_data could use the xml xpath thus making each of those queries an immediate hit through xpath lookup
[12:09] <shadeslayer> mitya57: -DECM_MKSPECS_INSTALL_DIR=/usr/lib/
[12:09] <shadeslayer> mitya57: that should really be in kf5flags
[12:09] <shadeslayer> oh
[12:09] <shadeslayer> mitya57: I read that wrong
[12:09] <shadeslayer> nvm
[12:10] <shadeslayer> mitya57: so what happens to ECM_MKSPECS_INSTALL_DIR ?
[12:11] <shadeslayer> or not required?
[12:12] <shadeslayer> mitya57: and FWIW we can keep the maintainer checking, the maintainers are combined now
[12:12] <shadeslayer> so it's Debian and Kubuntu Qt/KDE team
[12:13] <sgclark> morning
[12:14] <shadeslayer> morning sgclark :)
[12:22] <yofel> it's a mix of "Debian and Kubuntu" and "Debian and Ubuntu" and "Debian/Ubuntu" and maybe something else and sometimes there's a X-Ubuntu-Maintainer tag
[12:25] <sitter> on utopic something seems to drag in qt5.3 still
[12:25] <sitter> brr
[12:26] <Riddell> !newversion choqok 1.5
[12:26] <Riddell> kubotu: newversion choqok 1.5
[12:26] <kubotu> https://bugs.launchpad.net/bugs/1415022
[12:36] <mitya57> shadeslayer: it was you who dropped ECM_MKSPECS_INSTALL_DIR option: http://anonscm.debian.org/cgit/pkg-kde/pkg-kde-tools.git/commit/?id=1387e463e59a9bef
[12:37] <shadeslayer> aha cool
[12:37] <mitya57> (sorry, was afk)
[12:37] <shadeslayer> I'm awesome
[12:37] <shadeslayer> mitya57: ship it
[12:37] <mitya57> shadeslayer: can I add back maintainer checking everywhere? (1,2,3)
[12:37] <shadeslayer> mitya57: only in 3
[12:38] <mitya57> ok
[12:38] <shadeslayer> I don't think our older packages have co maintainer ship with the Debian team
[12:38] <shadeslayer> so that'll fail there
[12:39] <mitya57> yep
[12:46] <sitter> Riddell: utopic seems good for copy unless you want more testering?
[12:48] <Riddell> sitter: how about kate?
[12:49] <sitter> that's applications
[12:49] <Riddell> sitter: what are you proposing to move?
[12:49] <sitter> plasma-frameworks-qt
[12:49] <Riddell> why not applications?
[12:50] <sitter> because I have not tested them
[12:50] <sitter> also they need splitting IMO, no point in putting the kde4 apps into next
[12:51] <Riddell> I think apps should have all go into next-backports and kde4 ones into backports
[12:51] <Riddell> if you're ready to go with plasma-frameworks-qt then ok
[12:52] <Riddell> and we can fight over who gets to finish off applications
[12:52] <sitter> Unpacking kate5-data (4:14.12.0-0ubuntu1~ubuntu14.10~ppa1) ...
[12:52] <sitter> dpkg: error processing archive /var/cache/apt/archives/kate5-data_4%3a14.12.0-0ubuntu1~ubuntu14.10~ppa1_all.deb (--unpack):
[12:52] <sitter>  trying to overwrite '/usr/share/icons/hicolor/64x64/apps/kate.png', which is also in package kate-data 4:4.14.1-0ubuntu1
[12:52] <sitter> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[12:52] <sitter> I am not sure how that backport is supposed to work anyway
[12:52] <sitter> installing that will break dolphin and kdevelop and whatnot
[12:52] <Riddell> the icon should be removed from kata-data is all
[12:52] <sitter> that doesn't solve anything :P
[12:53] <Riddell> well anyway that needs more testing and tidying as I say
[12:53] <Riddell> plasma 5.2 on vivid has the issue soee reported earlier with overlapping kwin libs http://paste.ubuntu.com/9885905/
[12:54] <sitter> if you install kate (kf5) it replaces kate (kdelibs4) and all things that use kpart(4) depend on kate so they'll be satisfied by the kf5 version but that has an incompatibru with kdelibs4 apps, so they have no katepart
[12:54] <sitter> same for konsole
[12:54] <sitter> Riddell: I blame that on you
[12:58] <sitter> fixed in git
[12:59] <sitter>   Uploading kwin_5.2.0-0ubuntu1~ubuntu15.04~ppa2_source.changes: done.
[12:59] <sitter> Successfully uploaded packages.
[12:59] <Riddell> lovely
[12:59] <Riddell> time to log out and see what breaks
[13:01] <Riddell> yay it works!
[13:02] <Riddell> sitter: let's coordinate on a plan?  plasma 5.2 needs uploaded to vivid? plasma-frameworks-qt backports copied over? apps backports need copied over?  who's doing what?
[13:03] <BluesKaj> Hey folks
[13:10] <yofel> Riddell: doesn't the app backport need testing first? (looking at what sitter posted above it doesn't seem to work?)
[13:10] <sitter> Riddell: apps needs fixing
[13:10] <sitter> plasma-framework-qt backport I am on
[13:10]  * sitter writes script :O
[13:11] <yofel> also, please only copy full PPA's so no packages get missed (like with the 4.14 precise backport)
[13:11] <yofel> if you copy subsets copy that somewhere else first and re-test that
[13:12] <yofel> (or at the very least, re-test *after* the copy has been done)
[13:14] <sitter> hence why I made 3 stages :P
[13:14] <yofel> sitter++
[13:14] <sitter> Riddell: qtquick1 backport is still missing it appears :P
[13:16] <sitter> pft
[13:16] <sitter> shadeslayer: oauth gem is not threadsafe xd
[13:16] <shadeslayer> yay
[13:16] <sitter> such bastard
[13:16] <sitter> mutex all the things \o/
[13:16] <shadeslayer> My mozilla CI scripts are becoming awesomer by the minute
[13:17] <yofel> is that "awesome" or "monkey awesome" ?
[13:17] <sitter> monkey patch all the things \o/
[13:17] <shadeslayer> not monkey patching
[13:17] <shadeslayer> I found this thing called filterdiff
[13:17] <shadeslayer> it is the most magical thing ever
[13:18] <sitter> filterdiff used to be big in the days when people still used debdiff
[13:18] <shadeslayer> people still use debdiff
[13:19] <sitter> yeah, there's no need for filtering tho
[13:20] <shadeslayer> xD
[13:20] <shadeslayer> sitter: http://paste.ubuntu.com/9897989/
[13:20] <shadeslayer> so far
[13:21] <shadeslayer> not that it'll make any sense :P
[13:22]  * sitter has threaded ppa copy \o/
[13:22] <sitter> all hail the mutex
[13:23] <shadeslayer> pft
[13:26] <Riddell> sitter: ok shall I upload plasma 5.2 to vivid?
[13:26] <soee> yes :)
[13:32] <sitter> Riddell: all goody from my side
[13:32] <sitter> Riddell: while you are at it, maybe make muon migrate :P
[13:32] <shadeslayer> sitter:  rewrite dci/mozilla.rb (91%)
[13:32] <shadeslayer> xD
[13:33] <sitter> it has no classes
[13:33] <sitter> I find this highly suspicous
[13:33] <Riddell> sitter: I'm trying! (on muon)
[13:33] <shadeslayer> don't need no classes
[13:33] <shadeslayer> sitter: though it feels like I'm writing C code now xD
[13:33] <sitter> build_* suggests otherwise
[13:33] <shadeslayer> sitter: build_* ?
[13:33] <sitter> the methods
[13:34] <shadeslayer> ah
[13:34] <shadeslayer> sitter: what would you recommend
[13:34] <sitter> I see a buildthing prototype and specifics of the kind firefox and thunderbird, so there should at least be 2 classes and a module or 2 classes and one base
[13:34] <sitter> *base class
[13:35] <shadeslayer> mmmm
[13:35] <shadeslayer> sitter: I'll spend some more time architechting it better I guess
[13:35] <shadeslayer> when I have time
[13:35] <shadeslayer> for now this will do
[13:35] <sitter> listen to robucop :P
[13:35] <shadeslayer> I did
[13:35] <sitter> if you have more than 10 lines of code in a method you are most likely cheating
[13:36] <shadeslayer> I feel that's stupid tbh
[13:36] <shadeslayer> the 10 line limit
[13:36] <sitter> sometimes it is
[13:36] <sitter> most of the times it actually isn't
[13:39] <shadeslayer> sitter: so something like : MozBase, which does pull-lp-source, install build deps and what not, and then specific hacks go into firefox and tb classes?
[13:40] <sitter> yup
[13:41] <Quintasan> Riddell: Sure.
[13:42] <sitter> Riddell: plasma-frameworks-qt copied, pending publication
[13:43]  * sitter is tempted to say that we should continue using 3 stages moving forward
[13:43] <sitter> makes for much easier isolated testing, unfortunately dependency management on PPAs is a bit of a drag
[13:44] <Riddell> sitter: you didn't package plasma 5.2 bluedevil?
[13:44] <sitter> Riddell: bluez
[13:45] <Riddell> sitter: right but it can be backported and the vivid packages uploaded to transition ppa
[13:46] <sitter> Riddell: I feel a bit uneasy about that, should bluez5 not get landed we are in a world of trouble
[13:46] <Riddell> shrug, bluedevil for kdelibs4 doesn't do much on plasma 5
[13:47] <sitter> true enough, but if we backport we need to backport bluez5 which means if a next user then upgrades to vivid they still have bluez5 with potential screwery
[13:49] <sitter> Riddell: maybe assert bluez5 as a hard requirement for us?
[13:50] <Riddell> sitter: how do you mean?
[13:51] <sitter> Riddell: get foundations to commit to bluez5 landing in vivid, or did they do that anyway?
[13:51] <sitter> I understand only mobile is holding up the landing
[13:51] <sitter> 14.10 libbluedevil uploading to staging
[13:52] <shadeslayer> sitter: my linter doesn't seem to pick up variables that aren't defined
[13:52] <shadeslayer> any idea what I can use?
[13:53] <sitter> there no such thing I think
[13:54] <shadeslayer> :(
[13:54] <sitter> variables can come from outofscope due to the non-finalized state of all objects, so until actual runtime there is no way to accurately tell whether a variable is defined
[13:54] <sitter> ruby -w might tell you at runtime though
[13:55] <shadeslayer> sitter: but then I have stupid shite like http://anonscm.debian.org/cgit/pkg-kde/ci-tooling.git/commit/?id=8c69f9b885ec98ef389dc5c79acdb96ba6f5a3c5
[13:55] <sitter> which plays back into the fact that you should unittest everything :P
[13:55] <sitter> shadeslayer: write tests :P
[13:55] <shadeslayer> uf
[13:55] <shadeslayer> can't, tests would need root etc
[13:56] <sitter> not a good test wouldn't
[13:56] <shadeslayer> code needs root
[13:56] <shadeslayer> in certain parts
[13:56] <shadeslayer> like apt-get update and stuff
[13:56] <sitter> I doubt that is ever going to change btw, new_changelog in that case could be a variable defined in the super scope, a module that you mixin, a class deriving from this context etc. etc. all of which can be different files
[13:57] <sitter> shadeslayer: make it testable then?
[13:58] <shadeslayer> not sure how to do that, but I'll try
[13:58] <sitter> overload Kernel::system in the test and make it noop for example
[13:58] <sitter> would be naughty but that's one option for example
[14:00] <sitter> I think we'll eventually need a class/module wrapping around Apt anyway. for testing purposes you could then open up the class in the test case and make system noop, that way the noopness is limited to apt and doesn't interfer with anything else
[14:10]  * sitter scratches head
[14:10] <sitter> ha!
[14:11] <sitter> status page script list for utopic is incomplete
[14:14] <sitter> Riddell: what do we do with kcm-touchpad and usermanager?
[14:15] <sitter> should I fetch new snapshots?
[14:20] <shadeslayer> sitter: http://paste.ubuntu.com/9898643/
[14:20] <shadeslayer> sitter: makes me not want to use overlayfs
[14:22] <Riddell> sitter: leave them at beta for now
[14:22] <Riddell> kcm-touchpad will need an update but it needs testing and ktouchpadenabler removing
[14:23] <sitter> there are no beta backports
[14:23] <shadeslayer> I broke a thing
[14:23] <shadeslayer> oh noes
[14:28] <SonikkuAmerica> So I've got good news and bad news
[14:28] <Riddell> good news is good
[14:30] <SonikkuAmerica> The good news is, I have Plasma 5. The bad news is, I have a mixed system. I filed a bug as to the reason why already. But the other bad news is, the daily build threw me "invalid magic number" errors.
[14:31] <SonikkuAmerica> So bug 1414899 , by the way
[14:36] <Riddell> 5.2.0 is uploaded to vivid
[14:36] <Riddell> including kwin <IP_ADDRESS>
[14:37] <Riddell> which we can ignore for utopic because utopic already has qt 5.4 which fixes the issue too
[14:40] <shadeslayer> mitya57: re Qt 5.4 fixes for 5.3.2, I don't think it's worth the effort
[14:40] <shadeslayer> mitya57: because we also want things like better high dpi support and what not
[14:41] <shadeslayer> which you can probably not backport
[14:43] <sitter> shadeslayer: releaseme's upcoming logable module in case you want something reusable btw : http://paste.ubuntu.com/9898985/
[14:43] <sitter> can be mixed into other modules and classes alike
[14:47] <shadeslayer> just put it in ci-tooling/lib ?
[14:48] <sitter> shadeslayer: yeah
[14:48] <sitter> http://paste.ubuntu.com/9899074/
[14:48] <sitter> this version has slightlyb etter output when used from class methods
[14:49] <sitter> http://paste.ubuntu.com/9899102/
[14:49] <sitter> this one supports prepending properly xD
[14:49] <sitter> now I am done
[14:51] <sitter> Riddell: any reason not to pull a snapshot of user-manager/kcm-toucpad?
[14:56] <shadeslayer> sitter: all that seems magic to me at the moment
[14:57] <Riddell> sitter: any reason to do so?
[14:58] <Riddell> sitter: ooh ooh [ubuntu/vivid] libqapt 3.0.0-0ubuntu2 (Accepted)
[14:58] <mitya57> shadeslayer: ok
[14:59] <mitya57> shadeslayer: in any case the patches needed for tray icons are already in vivid
[14:59] <shadeslayer> mitya57: roger, thanks for that! :)
[14:59] <SonikkuAmerica> Um... is the MD5 checksum listed on cdimage.u.c correct for vivid Alpha 2?
[14:59] <shadeslayer> Riddell: btw I'll need your notes from Spanish class when I get back :P
[15:00] <Riddell> SonikkuAmerica: should be
[15:01] <Riddell> shadeslayer: que pasa, is all you need to know :)
[15:01] <SonikkuAmerica> Riddell: Then I should be very afraid - the image I just downloaded gave me a completely different MD5 sum
[15:01] <shadeslayer> xD
[15:01] <Riddell> SonikkuAmerica: which one?
[15:01] <SonikkuAmerica> Vivid Alpha 2
[15:01]  * SonikkuAmerica is DL'ing a 2nd image into another dir to double-check
[15:02] <Riddell> >sha256sum vivid-desktop-amd64.iso
[15:02] <Riddell> c309ef229f2ddfa59a7db5f3a346b269e51054192be3246bf0407c4d2b5ff35d  vivid-desktop-amd64.iso
[15:02] <Riddell> same as http://cdimage.ubuntu.com/kubuntu/releases/15.04/alpha-2/SHA256SUMS
[15:02] <sitter> shadeslayer: mh, the prepend and included functions are builtins called when one uses the include or prepend keywords on a thing, extend and include respectively then pull ClassMethods into the thing that includes or presend, and extend basically adds all the rubbish into class scope and include into instance scope
[15:03] <sitter> severe meta programming that is :P
[15:03] <SonikkuAmerica> I also got something different with the SHA256 sum. Probably a fluke then. The 2nd image should tell all now. > Riddell
[15:04] <shadeslayer> sitter: don't try to explain it, I've only had 4 hours of sleep
[15:04] <shadeslayer> Cards against humanity and the drinking went on for too long
[15:04] <sitter> long story short: http://paste.ubuntu.com/9899270/
[15:04] <sitter> you include the logable feature into any other thing and that other thing can then use the ClassMethods defined in the Logable
[15:05] <sitter> alas, the name there is right now misleading because the methods get imported into class and instance scope, as seen in the class B example there you can call log_warn from an instance method and a class method
[15:05] <serverhamster> Will plasma 5.2 come to 14.10 too?
[15:10] <sitter> shadeslayer, Riddell: whatever is this https://launchpad.net/ubuntu/+source/muon/4:5.2.0-0ubuntu1/+build/6754738/+files/buildlog_ubuntu-vivid-i386.muon_4%3A5.2.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:10] <shadeslayer> sitter: aha
[15:10] <shadeslayer> oho
[15:11] <shadeslayer> sitter: mitya uploaded new pkg-kde-tools with policy check
[15:11] <Riddell> "debian_qt_kde.mk usage denied by policy..  Stop." gosh, harsh
[15:11] <shadeslayer> maybe you want to make muon shared between Debian and Kubuntu
[15:11] <Riddell> waa, so everything is going to fail to compile?
[15:11] <shadeslayer> Riddell: no, unless you changed the maintainers
[15:11] <Riddell> it is isn't it?
[15:11] <shadeslayer> from Debian Qt/KDE team to whatever
[15:12] <Riddell> oh that does need fixed
[15:12] <Riddell> hmm
[15:12] <shadeslayer> what needs fixed?
[15:12] <sitter> we use Debian/Kubuntu Qt/KDE or something
[15:13] <Riddell> maintainer is still jontheechidna for some reason
[15:13] <Riddell> hi manchicken!
[15:13] <Riddell> how's life?
[15:13] <manchicken> I'll chat you.
[15:14] <sitter> Riddell: ah well, that's wrong to begin with then xD
[15:18] <manchicken> Does anybody know how to get the wifi notifications to stop reappearing on vivid?
[15:27] <manchicken> Okay, Riddell, I'm on the server
[15:27] <Riddell> manchicken: groovy, this is an ec2 cloud computer and we're sharing a screen, can you see it installing stuff?
[15:27] <manchicken> Running that command now.
[15:27] <manchicken> Yessir!
[15:27] <manchicken> Screen?
[15:28] <Riddell> yep, boybu is a nice setup for GNU Screen
[15:28] <manchicken> Cool.
[15:28] <Riddell> manchicken: what would you like to package today?
[15:28] <manchicken> What's the ^A?
[15:28] <Riddell> choqok seems to have a new release
[15:28] <manchicken> Sure!
[15:28] <Riddell> I see no ^A
[15:28] <manchicken> The control key
[15:29] <Riddell> should be set to go to beginning of line
[15:29] <Riddell> this Screen escape key is F12 i think
[15:29] <manchicken> Gotcha.
[15:29] <Riddell> manchicken: make a new directory and download the current choqok with apt-get source
[15:31] <manchicken>  K
[15:31] <Riddell> manchicken: so a source "package" is the .orig upstream tar, the debian tar and a description file .dsc with meta data
[15:31] <Riddell> manchicken: cd into the source
[15:31] <Riddell> you'll see the source code
[15:31] <Riddell> and a debian/ directory
[15:32] <Riddell> manchicken: this is the packaging take a look in each file and ask me what you don't understand
[15:33] <Riddell> manchicken: you picked the most complex one
[15:33] <Riddell> debian/rules is a makefile
[15:33] <Riddell> which has a build: target that runs the make; make install
[15:34] <Riddell> there's a few different ways to abstract the makefiles so they just do the right thing
[15:34] <Riddell> this seems to use an old system called cdbs which is pretty complex
[15:36] <manchicken> So it does that implicitly?\
[15:37] <manchicken> For the build/choqok:: rule I only see docbook stuff.
[15:37] <Riddell> yep
[15:37] <Riddell> it'll magically know to run cmake and install it (into debian/tmp)
[15:37] <Riddell> all the rules file is adding is the manpage which Debian likes to add for everything
[15:38] <manchicken> Righto.
[15:38] <Riddell> don't spend too long trying to understand cdbs style debian/rules files, they're not much used any more
[15:39] <manchicken> Righto.
[15:39] <Riddell> manchicken: really, get out of there before it eats your mind, almost all packages use debhelper 9 now which is much nicer
[15:39] <manchicken> I'm just trying to understand the build ^_^
[15:39] <manchicken> heh
[15:40] <manchicken> Righto.
[15:40] <manchicken> So debuild?
[15:40] <Riddell> manchicken: no, this is the old package, we want to update to the new one
[15:40] <manchicken> Oh, no, I need to pull the new version. Right.
[15:40] <Riddell> manchicken: in a new directory grab the new one from http://choqok.gnufolks.org/download/
[15:40] <manchicken> Is that on the KDE git repo then?
[15:41] <Riddell> I think it is but just grab the tar from the website
[15:42] <Riddell> manchicken: the tar also needs renamed for the name format packages need
[15:43] <Riddell> name_1.0.orig.tar.bz2
[15:43] <manchicken> Is xz okay still or should I change it to be a .tar.bz2?
[15:43] <Riddell> xz is good yes
[15:43] <manchicken> Cool.
[15:43] <manchicken> Like that?
[15:43] <Riddell> manchicken: yep
[15:44] <Riddell> manchicken: copy over the debian/ directory from the old package
[15:44] <Riddell> manchicken: in the sources run  dch  and add a new changelog
[15:44] <Riddell> set the version to 1.5-0ubuntu1
[15:45] <manchicken> So go into the toplevel package directory choqok-1.5?
[15:45] <Riddell> yep, or in debian/ probably works too
[15:46] <manchicken> Vivid?
[15:46] <Riddell> yes lower case
[15:46] <manchicken> Or Is there an LP ticket for this?
[15:47] <manchicken> I can't remember if package updates get tickets.
[15:47] <Riddell> https://bugs.launchpad.net/bugs/1415022
[15:47] <Riddell> yep, that one
[15:47] <Riddell> LP: #1415022  is the syntax
[15:47] <Riddell> give it a text desciption too
[15:47] <Riddell> oh groovy
[15:48] <manchicken> Like that?
[15:48] <Riddell> lovely
[15:48] <manchicken> (I like that this helps reduce my likelihood of screwing up since you can verify)
[15:48] <manchicken> Okay, and written.
[15:49] <Riddell> now debuild
[15:49] <manchicken> One second, I want to take notes.
[15:54] <Riddell> gosh it's communitymanagerappreciationday.com, I wonder when distro packager appreciation day is
[15:54] <manchicken> I'm going to share this note with you so that you can help edit it.
[15:54] <manchicken> It's on evernote, do you have an evernote email?
[15:55] <Riddell> mm nope
[15:55] <Riddell> notes.kde.org has etherpad, google docs works
[15:56] <manchicken> Evernote seemed to know you. heh
[15:56] <manchicken> Anyway, debuilg.
[15:57] <manchicken> debuild even
[15:57] <Riddell> apt install those
[15:57] <manchicken> Isn't there an debhelper to install deps?
[15:58] <manchicken> I guess not
[15:58] <Riddell> nope
[15:58] <Riddell> /usr/lib/pbuilder/pbuilder-thingy
[15:58] <Riddell> can work if it's installed
[15:59] <manchicken> Do I have sudo?
[15:59] <Riddell> yep
[15:59] <Riddell> also apt instead of apt-get
[15:59] <Riddell> those 4 character are stealing precious keyboard lifetime
[15:59] <manchicken> Like that?
[15:59] <manchicken> Hahah
[15:59] <Riddell> yep
[15:59] <manchicken> I type fast
[16:00] <manchicken> Gotta love those dependencies.
[16:00]  * Riddell also aliases  apt="sudo apt"
[16:02] <manchicken> hah
[16:03] <Riddell> go go debuild
[16:03] <Riddell> uh oh
[16:04] <manchicken> Missed one
[16:05] <Riddell> and it doesn't like something on line 5 of changelog
[16:05] <Riddell> maybe the comma
[16:06] <Riddell> manchicken: oh I know
[16:06] <Riddell> manchicken: it wants two spaces after the e-mail
[16:07] <manchicken> Oooh
[16:07] <manchicken> I wouldn't have gotten that
[16:10] <manchicken> I never noticed that Star Trek TNG had sonic screwdrivers, too.
[16:10] <Riddell> have a cup of tea I guess, it's a slow ec2
[16:10] <Riddell> it does?
[16:10] <Riddell> aren't they called phasers and are actually quite violent?
[16:11] <manchicken> In engineeringthey were using a sonic driver. Watching season 1 episode 2.
[16:12] <Riddell> isn't that still the pilot?
[16:13] <manchicken> The pilot was split, but on Netflix it's still one episode.
[16:13] <Riddell> ah
[16:14] <Riddell> does it explain why the captain claims to be french but has an english accent?
[16:15] <manchicken> heh
[16:15] <Riddell> manchicken: anyway stuff we've simplified here, often packaging is in bzr or debian git so it's best to get it from there rather than apt-get source the old one
[16:15] <Riddell> and update the git after
[16:15] <Riddell> it'll be listed in debian/control if it is
[16:15] <manchicken> Okay, so maybe we can do one like that right after this one?
[16:16] <Riddell> and actually debian do keep this in git at http://git.debian.org/?p=collab-maint/choqok.git
[16:16] <Riddell> but we don't
[16:17] <Riddell> this package only makes one .deb so there's no files that need to be split up into separate .debs, if so there would be multiple foo.install and bar.install files in debian/ to say which file goes where
[16:18] <Riddell> this package was taken from debian (as most packages in ubuntu are) and looking at the git they don't have any new versions since we took theirs
[16:18] <Riddell> but if they did it would be good to merge them back together
[16:18] <Riddell> or just start with the debian package and drop any change ubuntu had if it's not needed
[16:19] <manchicken> Makes sense.
[16:20] <Riddell> and as I say this is with cdbs which is old and crap so it might be an idea to convert to debhelper 9 (but then it would be a divertion from debian so you'd need to try to get whoever looks after it in debian to take the change or have a large difference with no gain)
[16:20] <manchicken> For a microblogging client this thing takes a while to build.
[16:21] <Riddell> slow ec2 as I say
[16:22] <manchicken> heh
[16:24] <manchicken> Do we package CPAN modules ourselves?
[16:25] <Riddell> ubuntu typically doesn't do much with perl, ubuntu perfers python (unless it's sitter in which case it prefers ruby)
[16:25] <Riddell> cpan modules in debian are usually only packaged if something else needs them
[16:25] <manchicken> We do have some modules in the repos.
[16:25] <manchicken> Righto. I've been doing a bunch of C for the Net::AMQP::RabbitMQ module.
[16:25] <Riddell> yeah popular ones will be there and ones used by other packages
[16:27] <Riddell> manchicken: it's finished compiling and installing
[16:27] <Riddell> manchicken: now it runs all the debhelper script dh_foo which do lots of bits to turn the installed files into the .deb
[16:27] <Riddell> ooh exciting, it's running lintian
[16:28] <Riddell> which is a tool to check for common problems in packages
[16:28] <Riddell> manchicken: all done!
[16:29] <manchicken> So, should I download and sign that package?
[16:30] <Riddell> manchicken: take a look in the directory above you should see the .deb
[16:30] <Riddell> manchicken: I don't suppose you're running i386?
[16:30] <Riddell> manchicken: run the .deb through lesspipe to check the contents are sane
[16:30] <Riddell> manchicken: and  dpkg --install it to check it actually installs
[16:30] <manchicken> I'm amd64
[16:31] <Riddell> mm me too
[16:31] <manchicken> Connection is going silly
[16:32] <Riddell> looks good
[16:32] <manchicken> That seems reasonable.
[16:33] <Riddell> apt -f install to fix it
[16:34] <Riddell> no filename with it
[16:34] <Riddell> -f is "something is half installed, please fix it apt"
[16:34] <manchicken> Gotcha
[16:34] <Riddell> sudo apt -f install
[16:34] <manchicken> Gotcha.
[16:36] <manchicken> I keep having connection issues.
[16:37] <manchicken> Comcast is not cool.
[16:38] <manchicken> Installed
[16:39] <manchicken> Wow, episode 3 of season 1 is super racist...
[16:39] <Riddell> oh?
[16:39] <Riddell> manchicken: so groovy it built and installs
[16:39] <Riddell> manchicken: you can run  debuild -S  in the sources to build the source package
[16:40] <manchicken> They encounter an alien race which reinforces a racist african tribal trope.
[16:40] <Riddell> which is just making the debian tar and a couple of meta data files .dsc and .changes
[16:40] <manchicken> Gotcha.
[16:41] <manchicken> All good?
[16:42] <Riddell> let me sign it
[16:42] <manchicken> Righto.
[16:44] <Riddell> manchicken: ok I signed the .changes file using..
[16:44] <Riddell> debsign -r ubuntu@ec2-54-242-81-84.compute-1.amazonaws.com:choqok-manchicken-build/choqok_1.5-0ubuntu1_source.changes
[16:44] <Riddell> it'll normally do that as part of the debuild if the debian/changelog e-mail matches a gpg key on your system
[16:45] <Riddell> manchicken: right let's upload
[16:45] <Riddell> look into choqok_1.5-0ubuntu1_source.changes and check it's going to the right release
[16:45] <Riddell> then  dput ubuntu choqok_1.5-0ubuntu1_source.changes
[16:45] <Riddell> you'll need to read the manpage to work out how to get it to not moan about no gpg key on the server
[16:46] <Riddell> ignore the i386 changes
[16:46] <Riddell> that was made when you built the .deb package
[16:47] <Riddell> but ubuntu forbits uploading a .deb package
[16:47] <Riddell> (unlike debian who i think still require it for some reason)
[16:48] <manchicken> Like that?
[16:48] <Riddell> yay!
[16:48] <Riddell> so now you can watch it build at https://launchpad.net/ubuntu/+source/choqok/1.5-0ubuntu1
[16:48] <Riddell> it'll build in vivid-proposed
[16:49] <Riddell> if it builds and doesn't cause anything to break it'll get moved to vivid-release
[16:49] <Riddell> and life is good
[16:49] <Riddell> you should join https://launchpad.net/~kubuntu-ninjas-yellow-belts
[16:51] <manchicken> w00t
[16:51] <Riddell> packaging takes an hour or two to learn but there's loads of finer details we've missed out so there's a never ending learning process
[16:51] <Riddell> if you want another challenge digikam could do with being packaged I think
[16:52] <SonikkuAmerica> Finally a good test case
[16:53] <SonikkuAmerica> But not without some difficulty.
[16:53] <manchicken> YEah
[16:53] <SonikkuAmerica> (To the QA Tracker!)
[16:53] <manchicken> I think that may have been the first package I've ever uploaded. hah
[16:54] <manchicken> More than eight years in, and I finally got one uploaded... with much hand holding. hah
[16:54] <SonikkuAmerica> So, anyway, I was dumb and re-downloaded the whole Alpha 2 ISO because of a checksum mismatch
[16:55] <manchicken> Okay, so I'll try this one by myself ten
[16:55] <manchicken> then*
[16:55] <SonikkuAmerica> When I could've just installed zsync and fixed it.
[16:55] <SonikkuAmerica> Then came the 2 test cases.
[16:55] <SonikkuAmerica> The independent variable this time was the init daemon.
[16:58] <manchicken> Is there a master list of the tickets?
[16:59] <SonikkuAmerica> manchicken: Tickets as in bugs or the QA tracker?
[17:00] <manchicken> LP bugs
[17:00] <SonikkuAmerica> manchicken: Generally a master list can be found per package or work item
[17:04] <manchicken> Riddell: This ticket then? https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/1379410
[17:08] <Riddell> manchicken: yep
[17:08] <manchicken> w00t
[17:08] <Riddell> manchicken: I need to leave, let me know when I can turn off the ec2
[17:10] <manchicken> Should I assign these tickets to myself?
[17:10] <Riddell> yeah
[17:11] <manchicken> Okay, my ticket is to upgrade to 4.5.0, but the attachment is for 4.6.0
[17:12] <Riddell> attachment?
[17:12] <Riddell> use your common sense on what the right thing to do is
[17:14] <manchicken> Okay, so my ticket is 4.5.0, not 4.6.0.
[17:15] <Riddell> do the latest version
[17:15] <manchicken> Righto.
[17:20] <SonikkuAmerica> Installer dies, no reason given.
[17:22] <SonikkuAmerica> (This was trying to inject an install into an unformatted partition.)
[17:24] <manchicken> So I should pull this from the bzr repo, yes?
[17:26] <manchicken> How do people ususally brin their SSH key to the ec2?
[17:26] <manchicken> bring*
[17:44] <_Groo_> any news on the 14.12 backports to utopic?
[18:11] <manchicken> Very slow ec2...
[18:29] <manchicken> Man, trying to get digikam out of bzr so that I can get the latest patches.
[18:30] <soee> Riddell: ping
[18:31] <manchicken> He runnoft.
[18:32] <manchicken> soee: You ever work with packaging where a patch was out of date?
[18:32] <soee> manchicken: nope sorry
[18:32] <manchicken> Anybody else?
[18:33] <Riddell> quilt is what you need
[18:33] <Riddell> quilt pop and push
[18:33] <Riddell> quilt push -f
[18:33] <Riddell> edit
[18:33] <Riddell> quilt refresh
[18:34]  * manchicken googles.
[18:34] <manchicken> I was checking the bzr repo to see if there was a later and greater revision.
[18:35] <soee> Riddell: updates in Vivid, this one is going to be removed right: libmuonprivate2 ?
[18:36] <manchicken> Riddell: How do we change the screen window in this screen session?
[18:36] <Riddell> soee fine
[18:36] <Riddell> f12 2
[18:49] <soee> why since i rememebr this message is produced often during updates: Unknown media type in type 'all/all' etc.
[18:49] <soee> can't we get rid of thise media types ?
[18:49] <Riddell> manchicken: on my computer now if you need help
[18:50] <Riddell> soee: dunno it's been a warning for years,worth investigating but not very important
[18:50] <soee> Riddell: yes harmless but so annoying :)
[18:51] <manchicken> Okay, so I think I can just manually fix this patch.
[18:51] <manchicken> But I'm curious as to whether or not we have another version of this updated patch already lying around somewhere.
[18:53] <manchicken> The bzr branch is even more out of date.
[18:58] <Riddell> soee: something kde will be using that mimetype which doesn't really exist in the xdg mimetype list, it could be added though
[18:59] <Riddell> manchicken: check debian git
[18:59] <Riddell> but I don't think so
[18:59] <yofel> manchicken: bzr for digikam? I think a gsoc student was working on it a bit but his work supposedly got lost. Then I did some changes in bzr but never had time to actually work on the update
[19:06] <Riddell> manchicken: remove that one
[19:06] <manchicken> hah
[19:06] <manchicken> K.
[19:06] <manchicken> Just rm thefile?
[19:06] <Riddell> manchicken: it's called "upstream_." so it comes from digikam git anyway
[19:06] <manchicken> Gotcha.
[19:06] <Riddell> manchicken: yes and edit it out of debian/patches/series
[19:07] <Riddell> (I expect there's a quilt command to do that but I've never bothered to learn)
[19:08] <Riddell> manchicken: also this will take days to build, you might be better doing it on your own computer or asking for a better ec2
[19:08] <manchicken> That's a good point.
[19:09] <Riddell> manchicken: are you running vivid?
[19:09] <yofel> also don't forget to bzr rm the patch later
[19:09] <manchicken> Yes
[19:09] <manchicken> yofel: The bzr repo for digikam seems rather out of date.
[19:09] <manchicken> It may have been a while since it was refreshed from upstream.
[19:10] <Riddell> manchicken: this may well be the case, we're also moving our branches over to debian git so for bonus points you can get an account on alioth and see if there's a place to put it there
[19:10] <yofel> IIRC digikam is in debian SVN
[19:10] <manchicken> Riddell: What would you recommend for building?
[19:11] <manchicken> I'm worried about getting caught up in build hell.
[19:11] <yofel> manchicken: bzr looks like it's in sync with the archive to me
[19:11] <manchicken> (because I've never been derailed by a build environment problem before, and I don't know how to use our build virtualization pieces)
[19:11] <manchicken> yofel: The one patch for the mysqld seems like it's pointing at a super old version.
[19:11] <Riddell> manchicken: how do you mean?
[19:12] <manchicken> Well the version of the package directory referenced in the diff itself was 2.0, but also, it had the exact same diff.
[19:12] <yofel> manchicken: the path prefix is stripped by patch, so that doesn't matter
[19:12] <Riddell> manchicken: if I was me I'd make a chroot on my local machine to build it
[19:12] <yofel> otherwise we would have to refresh the patch each time we update the version
[19:12] <soee> woho new webbrowser :o
[19:13] <yofel> or well, *all* patches each time
[19:13] <manchicken> Riddell: Can you RTFM me on that?
[19:14] <manchicken> Riddell: https://help.ubuntu.com/community/DebootstrapChroot ?
[19:15] <Riddell> yep
[19:15] <Riddell> deboostrap vivid vivid  will make one
[19:15] <Riddell> then   chroot vivid  to get into it
[19:15] <Riddell> instant vivid build environment, all clean
[19:16] <soee> do you also liek 0.5 second freeze when opening new app ?
[19:16] <soee> *do you also have
[19:16] <Riddell> pbuilder is another tool which sets up a chroot, builds it and then removes the chroot.  I only like to use it for a final check as it makes you build it all from scratch even if you only change a small thing
[19:18] <manchicken> Gotcha.
[19:18] <manchicken> I'm out of that session then.
[19:18] <manchicken> I'll do this locally.
[19:18] <Riddell> manchicken: copied your files over?
[19:19] <manchicken> Yeah
[19:19] <manchicken> I only had the one, really.
[19:19] <manchicken> Everything else was generated :)
[19:19] <Riddell> killed it
[19:19] <Riddell> "3h59m" just before we got charged for another hour :)
[19:28] <manchicken> Sorry I took so long.
[19:28] <Riddell> no no, it's there to be used
[19:28] <Riddell> and you're a pleasure to tutor compared to the google code-in students we had :)
[19:30] <manchicken> haha
[19:35] <manchicken> Riddell: That package we worked on earlier is accepted for several archs now.
[19:35] <Riddell> arm64 being slow as usual
[19:36] <Riddell> do download and test the amd64 one
[19:37] <Riddell> hmm, I can't actually add an account
[19:44] <Riddell> ok working now
[19:45] <Riddell> suspicious
[19:50] <manchicken> Okay, so, it says I'm missing schroot.conf
[19:50] <manchicken> ....
[19:52] <Riddell> manchicken: what says that?
[19:52] <Riddell> "
[19:52] <Riddell> "
[19:52] <Riddell> hey @kubuntu , an installer asking for the crypt-password before choosing the keyboard layout is not nice. shot myself in the foot right now
[19:52] <Riddell> "
[19:52] <manchicken> hah, I just touched the file.
[19:52] <manchicken> schroot
[19:52] <Riddell> says twitter, a fair point
[19:52] <Riddell> oh I've not used schroot, it's like pbuilder isn't it?
[19:52] <manchicken> w00t!
[19:52] <manchicken> Got it.
[20:23] <manchicken> digikam is huge.
[20:25] <manchicken> Riddell: So I should start with the apt-get source, add in the latest stable package, commit the souce directory to the bzr repo with the updated patch?
[20:28] <Riddell> manchicken: if apt-get source has a newer version sure
[20:30] <manchicken> Cool, but do we want to merge the stable version from the tarball into he bazaar repo/
[20:30] <manchicken> ?
[20:31] <yofel> shouldn't be a merge if you got the vivid source
[20:31] <yofel> just copy your debian dir over and commit
[20:32] <manchicken> yofel: I think I understand what you just said, but I'm not sure. Could you repeat it worded differently?
[20:32] <yofel> checkout what we have in bzr, copy the debian folder you just worked on in there, bzr rm whatever you had to delete, then bzr commit your changes
[20:33] <manchicken> digikam is coming in from upstream though, yeah?
[20:33] <manchicken> So should I just unpack the stable tarball into the base of the bzr repo?
[20:33] <yofel> no, *just* the debian folder. We don't keep the upstream source in the VCS again
[20:34] <yofel> you can then make a package from bzr with 'bzr builddeb' which will pick up the orig tarball by itself
[20:35] <yofel> hm, debian actually has 4:4.4.0-1.1
[20:35] <yofel> nvm for now
[20:36] <manchicken> Gotcha.
[20:36] <manchicken> So if there's source in the bzr, ignore it?
[20:36] <yofel> there isn't ;)
[20:37] <yofel> if you copy more than you intended, bzr will ignore anything it doesn't actually track
[20:37] <manchicken> It seems like digikam's bzr repo does have source.
[20:37] <yofel> lp:~kubuntu-packagers/kubuntu-packaging/digikam/ doesn't
[20:37] <manchicken> lp:ubuntu/digikam <-- That's the repo I have.
[20:38] <manchicken> Okay, that's my problem then.
[20:38] <yofel> see "Vcs-Bzr" in the control file for the correct URL
[20:39] <manchicken> Remember, I'm pretty new to the packaging.
[20:40] <yofel> no problem, apt will also point you to it when you run apt-get source
[21:57] <ovidiu-florin> In case you haven't seen it: https://www.youtube.com/watch?v=1z2u1pM8PeY
[22:00] <soee> ovidiu-florin: nice ill share on g+ :)
[22:08] <Riddell> ovidiu-florin: where did you see that linked?
[22:11] <soee> ok folks on #plasma know about the freeze bug i mentioned earlier: https://bugreports.qt.io/browse/QTBUG-40207


[16:09] <knome> 7n
[16:09] <knome> err
[16:18] <cjohnston> 5k
[16:18] <knome> ;)
[21:21] <AlanBell> cjohnston: last UDS I put in an RT request for someone to reboot pad.ubuntu.com prior to the UDS starting
[21:21] <cjohnston> ok
[21:21] <cjohnston> should we do that again?
[21:21] <AlanBell> I got a reply a week or so ago from someone saying "I guess you don't need this any more" or words to that effect
[21:22] <AlanBell> and pad did crash on day 1 of UDS and stayed up the rest of the time
[21:22] <AlanBell> perhaps it might be an idea to actually try and reboot it before linaro connect
[21:22] <cjohnston> ok
[21:25]  * AlanBell headdesks at a totally unrelated RT reply
[21:26] <AlanBell> apparently for someone to type "/msg ubuntulog join #ubuntu-classroom-es" has been deemed a non-trivial task so has been put in a queue
[21:27] <cjohnston> AlanBell: its an auto reply
[21:27] <cjohnston> it goes into a queue
[21:28] <AlanBell> I got the autoreply earlier, this might be a template reply
[21:29] <AlanBell> all set to do a lovely etherpad-lite/summit integration after linaro connect is over
[21:30] <cjohnston> ok
[21:30] <cjohnston> AlanBell: is it just rebooting the etherpad, or the entire server?
[21:31] <AlanBell> pad.ubuntu.com is running etherpad and is the primary notetaking solution for UDS as it is integrated with summit. I am finding it a little slow and timing out occasionally and I think it needs some love and attention before the hordes descend on it at UDS. Please could someone have a look at it, maybe restart it, and generally make sure it is in tip-top condition by the start of UDS-P at the end of October.
[21:31] <AlanBell> is what the last request said
[21:32] <knome> is it running etherpad or etherpad lite?
[21:32] <AlanBell> I suspect restarting the etherpad service would be sufficient
[21:32] <AlanBell> knome: etherpad at the moment
[21:32] <knome> ok, you should try lite
[21:32] <cjohnston> ok
[21:32] <AlanBell> knome: yes, we have been hacking on it, and integrating openid auth against launchpad
[21:32] <knome> :)
[21:32] <knome> nice
[21:33] <AlanBell> just not implementing that until after Linaro connect
[21:33] <cjohnston> AlanBell: do you think having it scheduled Friday afternoon/evening EST would be good?
[21:34] <AlanBell> cjohnston: dunno, the last request didn't get processed until 29th December (slightly more than a week ago, but still slightly after UDS-P)
[21:34] <cjohnston> I can poke for it to happen..
[21:34] <AlanBell> that would be great, I lacked poking power
[21:35] <cjohnston> :-)
[21:35] <cjohnston> AlanBell: did you notice that linaro connect is using pad.linaro.org
[21:37] <AlanBell> I did not
[21:38] <AlanBell> hmm, interestin!
[21:39]  * AlanBell looks puzzled
[21:40] <AlanBell> so are they running a separate summit django process somewhere looking at the same postgres back end?
[21:41] <cjohnston> is it the same postgres backend?
[21:41] <AlanBell> well I don't know, I am confused
[21:41] <cjohnston> i think its a seperate instance
[21:41] <AlanBell> summit has only one pad parameter
[21:41] <cjohnston> not anymore
[21:42] <AlanBell> ah, ok
[21:42]  * AlanBell goes to read cjohnston's fine blog in more depth
[21:44] <AlanBell> in that case forget everything I said about rebooting the pad server ;)
[21:44] <cjohnston> it may still need to be done
[21:44] <cjohnston> i dunno
[21:46] <AlanBell> phalsa.canonical.com is the pad.linaro.org server and fragaria.canonical.com is pad.ubuntu.com
[21:46] <AlanBell> so I guess we can crack on with the pad.ubuntu.com migration to etherpad lite
[21:46] <cjohnston> i wouldnt incase they want stuff for reference
[21:47] <AlanBell> oh, from the last linaro pads, good point
[21:48] <mhall119> AlanBell: can you start putting lite on a different box, and call it padlite.u.c?
[21:49] <AlanBell> well I can, I have no shortage of boxen
[21:49] <mhall119> then we can point uds-q to it and try it out
[21:49] <AlanBell> but they are mine, not canonicals
[21:49] <mhall119> hmmm, we can point to any url, actually
[21:49] <AlanBell> sure, I can run one up for testing
[21:49] <cjohnston> mhall119: no we cant...
[21:49] <mhall119> we can't?
[21:49] <mhall119> oh,  is it still trying to validate?
[21:49] <cjohnston> https://code.launchpad.net/~chrisjohnston/summit/etherpad-breaks-summit/+merge/90537
[21:50] <mhall119> right, someone really needs to approve that so it'll land
[21:50]  * cjohnston looks at AlanBell
[21:51] <AlanBell> so what does verify_exists do?
[21:51] <cjohnston> lol
[21:52] <cjohnston> the fact that pad.u.c redirects to SSO makes summit think that the url pad.u.c is invalid
[21:52] <mhall119> AlanBell: it makes an HTTP call to the url to make sure it get's a 200 response back
[21:52] <cjohnston> s/invalid/doesnt exist
[21:52] <cjohnston> my mp will make that stop
[21:52] <AlanBell> oh, so you don't want the server behind an obnoxious outbound firewall
[21:53] <mhall119> AlanBell: it's a deprecated attribute in Django anywa
[21:55] <AlanBell> what a very clever & utterly crazy standard feature for a URL field


[01:09] <infinity> vorlon: Yeah, it was only https://bugs.launchpad.net/ubuntu/+source/msttcorefonts/+bug/1713615/comments/18 who implied a dpkg failure, and since he didn't back it up with any evidence, I'm going to assume he was smoking something, cause all the pasted logs look fine.
[04:48] <vorlon> Logan: have you seen that the new mtail's autopkgtests seem to be less than happy (possibly related to the presence of proxies)?
[09:56] <juliank> infinity: So apt would have done the right thing with both filename and sha256; but apt-helper only accepts one
[09:56] <juliank> this fixes it: https://github.com/Debian/apt/compare/master...julian-klode:pu/apt-helper-multihash?expand=1
[09:56] <juliank> allows you to add as many hashes a you want to a download-file
[09:57] <juliank> (download-file accepts multiple URL PATH pairs, so it's a bit confusing
[10:30] <LocutusOfBorg> mwhudson, it was quite easy to find out... I did build successfully on my laptop (bionic amd64) and it failed on ppa, so I found two possible reasons: 1) restrictions on ppas 2) something in -proposed pocket. I did reconfigure my ppa to not use proposed-pocket and the build was good, so I diffed the two logs and found that only gcc and openssl had -proposed version... looking at the version number of openssl gave me the answer
[10:30] <LocutusOfBorg> without having to prove it :)
[12:02] <LocutusOfBorg> mwhudson, golang-1.11 merge too please?
[12:03] <LocutusOfBorg> also golang-defaults...
[12:04] <LocutusOfBorg> I can do them if you want
[12:04] <LocutusOfBorg> they are trivial
[12:14] <ahasenack> hello sru team, we almost gave up on an sru that has been unverified for too long, but yesterday the reporter finally flipped the tags. That upload was blocking another more urgent sru, but looks like now it can finally move forward!
[12:14] <ahasenack> it's sssd, and both bugs are green now in the sru report page: 	1722936 1793882
[12:35] <rbasak> apw: linux-snapdragon ended up getting imported by git-ubuntu as it isn't matched by the blacklist. Is that a problem? Should I blacklist and/or remove the repo?
[12:48] <coreycb> RAOF: hello, would you have cycles in your rotation today to take a look at nova in the xenial unapproved queue? we'd like to see if we can get that one moving along.
[12:48] <apw> rbasak, i have no idea what it really means to be imported, i assume it is making a default repository called +git/linux-snapdragon which we then never use ?
[12:53] <apw> rbasak, ahh there they are, as they are in another user entirely, i am not sure if i care either way if you blacklist them or not
[13:12] <rbasak> apw: the repository will end up being the default one for the package if I don't blacklist it.
[13:13] <apw> rbasak, presumbly not if i then later change it
[13:13] <rbasak> apw: which would collide in the case of "linux", for example, which currently points to https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/version-seeds/+ref/master
[13:13] <rbasak> (but "linux" is blacklisted)
[13:14] <apw> rbasak, are you saying you would move it back every time, or only when you first make it
[13:14] <rbasak> apw: you could later change it, but you'd be fighting with our scripts - since occasionally we have to batch run the defaults change for all repositories that we import.
[13:14] <rbasak> I can of course coordinate and adjust scripts which is why I'm talking to you :)
[13:14] <apw> rbasak, it would feel like you should take the default if it has none currently, else not
[13:14] <rbasak> The question is just what we want exactly to maximise benefit and minimise pain.
[13:15] <apw> then the thing could always import safely
[13:15] <rbasak> That's a good idea.
[13:15] <apw> out default is stupid, i did that to try and make pushes to new repos cheaper, it didn't work
[13:15] <apw> and some new git setting helped it not be so stupid
[13:16] <rbasak> One thing I'd like is to reduce exceptions.
[13:16] <apw> as i have no objction to linux being imported, so raw dscs are in there
[13:16] <rbasak> git-ubuntu is most valuable if it works on all packages
[13:16] <rbasak> You had warned me from importing linux for performance reasons :)
[13:16] <apw> oh it might make you sad ;)
[13:16] <apw> but i have no philosphical objection
[13:17] <rbasak> Any objection to git-ubuntu eventually taking over the default for all packages without exception?
[13:17] <apw> i don't know that that makes sense, the default should be what the packager expects you to use, no ?
[13:17] <apw> not that we can even do that in our current namespace for linux for example
[13:17] <rbasak> That makes it very painful for new and/or drive-by contributors
[13:18] <apw> it is more painful surely if they do their work against an importer tree
[13:18] <apw> and we have no way to work with what they give us, and make them do it another way
[13:18] <rbasak> No way? git-rebase is trivial for us.
[13:19] <rbasak> The benefit of doing it against an importer tree is consistent documentation and tooling for all packages.
[13:19] <rbasak> When "git ubuntu build" and "git ubuntu lint" and "git ubuntu submit" eventually work.
[13:19] <apw> i am going to ignore this part for now, and say, that i am expecting you will have to do something
[13:19] <rbasak> Then it'll be a case of "clone, cherry-pick, build, submit".
[13:20] <rbasak> No learning packaging involved.
[13:20] <apw> witht the default, for the 'push a tag here as an upload' world,
[13:20] <apw> so maybe it all becomes forced on us by then anyhow
[13:20] <rbasak> OK. So let's leave it for a future discussion when tooling is better.
[13:21] <rbasak> linux-snapdragon I'll ignore for now then, and let it continue importing.
[13:21] <apw> rbasak, but with our per series repo split, we cannot use the default for anything useful, as you can only have one
[13:21] <rbasak> It will become default when I next run the script (the importer instance can't do it since it doesn't have core dev credentials)
[13:21] <rbasak> And next time I work on the script, I'll add your suggestion about only assigning the default if none is set.
[13:21] <rbasak> (without --force or something)
[13:22] <apw> sounds fine, i tend to unset the default to stop it being utterly confusing to people
[13:22] <rbasak> OK. Thanks!
[13:58] <seb128> bdmurray, hey, do you know what's needed to get http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html generated?
[14:07] <bdmurray> seb128: you reminding me ;-) maybe we should add it to the release opening checklist
[14:08] <seb128> bdmurray, that would make sense I guess (or maybe the system should just be smart enough to query launchpad for active series and no need manual changes)
[14:08] <seb128> bdmurray, thx in any case :)
[16:44] <infinity> jdstrand: What are you trying to accomplish with gcc-multilib on arm64?
[16:45] <infinity> jdstrand: Note that gcc-multilib:armhf (that you believe you want) is hf/sf multilib, not v8/v7.
[16:47] <infinity> jdstrand: Is it possible that what you actually want is gcc-arm-linux-gnueabihf (which does exist on arm64)?
[16:47] <jdstrand> infinity: to be able to use -m32 on arm64, like I can with gcc-multilib on amd64
[16:48] <infinity> jdstrand: Yeah, -m32 on arm64 is a non-starter, as we don't do arm64 multilib.
[16:48] <infinity> jdstrand: For any number of reasons, though a major one being that armv8 doesn't actually require armv7 compat as part of the spec.
[16:49] <infinity> jdstrand: That said, I'd also suggest that multilib is an outdated, evil, and nasty concept that we might want to shy away from, not lean into. :P
[16:49] <jdstrand> infinity: it is only for test code so I have 32 bit binaries I can run on 64 bit machines
[16:50] <jdstrand> and trying to make that work with a single snapcraft.yaml that will build everything in LP
[16:50] <infinity> jdstrand: Kay.  Keeping in mind, again, that most armv8 machines can't run 32-bit code. :P
[16:51] <jdstrand> infinity: that's fine. I disabled the 32 bits bit from arm64 for this test code
[16:51] <jdstrand> thanks for the info
[16:52] <infinity> jdstrand: Anyhow, crossing with gcc-arm-linux-gnueabihf will produce 32-bit binaries.  Running them is a bit more exciting, since you won't have a libc or linker on path, but you can fudge that by running the linker by hand if you're only do it for test purposes.
[16:52] <infinity> jdstrand: (ie: LD_PRELOAD=/path/to/cross/libc.so /path/to/cross/ld.so /path/to/test/binary)
[16:53] <infinity> Or similary hideousness.
[16:53] <jdstrand> yeah, I was thinking about that. I'd need to get a libc on the system I could use and the same bug that prevented me from getting gcc-multilib prevents me from getting that staged
[16:54] <jdstrand> it works for amd64 so I'm ok
[16:54] <infinity> jdstrand: I'm not sure how people will respond to your request for foreign arches in snap builds, but I've been strongly against it for deb builds because it leads to the architectures no longer being self-contained (and, also, some fuzziness on how to resolve multi-arch deps when packages exist on A, B, C, but not D, E, F)
[16:55] <infinity> jdstrand: There's a libc pulled in by the cross gcc (it needs one to link to), it's just that ld.so and libc.so aren't on the usual paths, so don't "work" by default.  Aiming at them manually will make it magically work if the goal is just to build and run a throwaway binary.
[16:56] <infinity> jdstrand: Then if you don't want weirdly divergent code, you could switch the x86 implementation to use gcc-i686-linux-gnu and the cross-libc too, but meh.
[16:56] <infinity> (Guess how much I wish multilib wasn't a thing)
[16:56] <infinity> (Guess how functional my time machine isn't)
[16:57] <xnox> jdstrand, this been discussed before. and gcc-multilib is bad, crossbuild-essential-ARCH is good! and it does pull in the right libc, etc.
[16:58] <jdstrand> yeah. since the arm doesn't require the compat, for the test code I think I'm good as is, but noted
[16:58] <xnox> in all cases, devel machines, chroots, snap builds etc. and that's the thing to use. Including enabling multiarch deps, where needed.
[16:58] <xnox> jdstrand, that's generic supported any-to-any solution.
[16:58] <jdstrand> ack
[19:31] <coreycb> bdmurray: hello, if you have cycles in your rotation today can you take a look at nova in the xenial unapproved queue? we'd like to see if we can get that one moving along.
[19:38] <bdmurray> coreycb: bug 1708572 doesn't have any Ubuntu tasks
[20:22] <coreycb> bdmurray: sorry about that. i've updated the bug.
[21:01] <mwhudson> LocutusOfBorg: was going to do golang-defaults but forgot
[21:01] <mwhudson> LocutusOfBorg: should probably remove golang-1.11, it'll be EOL by the time eoan releases
[21:02] <mwhudson> (let's not mention anything about disco releasing with eol golang 1.10 oops)