[00:12] <vertago1> If I were to start trying to help with packaging, where on KCI would be the best place to look? senile?
[00:57] <frecel> hello
[00:57] <frecel> is anyone working on plasma 5.5.1 packages for kubuntu or aware of a ppa that has them?
[08:52] <lordievader> Good morning.
[10:06] <yofel> frecel: no, we're not working on them yet. Yes, we are working in their direction (currently on frameworks), but we're very shorthanded currently
[10:39] <mparillo> yofel: Suggestion: Since it seems that either you or sgclark seem to have to reply almost daily, perhaps load it into the channel topic?
[10:40] <yofel> might as well add that back, we did have that in the past
[10:42] <yofel> a bit cryptic, but those people that actually bother to read the topic should understand taht
[10:43] <yofel> actually
[10:43] <yofel> peace
[10:45] <mparillo> TY. Mind if I try to add the last bit to the support channel?
[10:46] <mparillo> Sorry, I guess I do not have the permissions anyway.
[11:00] <yofel> I would rather not have that over there, even if it means answering a couple more questions. Additional info in the already long topic there is really just for emergencies
[11:17] <yofel> ok, so finally took a look at those app "backports" and the PPA had a dep on the INDI ppa which it shouldn't have. People really need to stop adding random PPA deps
[11:21] <yofel> uh... staging-frameworks didn't depend on -proposed
[11:40] <BluesKaj> Hiyas all
[18:07] <santa_> yofel: hi since I have been absent for a while: where do you need help (besides parallelinzing git-clone-all)?
[18:08] <santa_> * parallelizing
[18:18] <vertago1> I was looking at the merging failures and it looks like it would just take someone with git access to address a merge conflict: http://kci.pangea.pub/job/merger_breeze-icons/
[18:18] <vertago1> I was looking into how to help, but I don't know the git information to look into fixing the merge conflicts.
[18:47] <yofel> vertago1: git access is restricted and requires membership on the qt-kde team on alioth (debian). In the beginning we recommend sending patches for actual packaging issues (or pointing us to a fixed git branch somewhere) or doing coop packaging with someone or tackling small package updates
[18:48] <yofel> let me think a bit about how a good way to start helping with packaging would be... 
[18:49] <yofel> santa_: hard to say, didn't you want to implement your workflow? I'm currently trying to meet that coming from the other direction by reworking and splitting the current scripts a bit so we can get work done.
[18:52] <yofel> santa_: I pretty much gave up using your workflow after making git-clone-all work for me took too long. I work in temporary directories, so I added -t to the script, but then it started doing nothing at all because you are relying on a fixed path in getFtpVersionMap(), which will fail depending on when the function is called
[18:52] <yofel> after I saw that I didn't feel like digging more into it
[18:53] <santa_> yofel: what was that -t suposed to do?
[18:53] <yofel> same thing as -t does for staging-upload
[18:53] <yofel> make a tmpdir and do all the work in there
[18:53] <yofel> so it can later be easily deleted
[18:54] <santa_> well the idea of automation-ng is using clones which you are suposed to keep
[18:55] <santa_> if your intention is to clone all the repositories each time a new upstream release arrives that is going to take a long time
[18:55] <yofel> doesn't work for me. I know myself, and if I have repo clones lying around, I *will* use them for random stuff. And I need a clean environment for the automation stuff
[18:56] <yofel> sure, that's why -t is supposed to be optional
[18:56] <yofel> there's nothing wrong with the script supporting both persistent and volatile workflows
[18:57] <santa_> well, I fail to see whats the problem
[18:57] <santa_> if you don't trust your previous clones you can clone them again
[18:58] <santa_> or if you screwed up and you want to start fresh or whatever
[18:58] <yofel> well, for starters, the git-clone-all I tried, cloned all repos inside of the kubuntu-automation checkout, without subfolder. Sorry, but that's a no-go for me
[18:59] <yofel> ok, I can go and make a symlink, and copy all the config stuff it needs to the temporary location, but the script should do that really.
[19:00] <yofel> And why would a *library* function rely on a specific execution location? If it needs the path, that's supposed to be a function parameter, not an in-function call
[19:00] <santa_> wat
[19:01] <yofel> def getFtpVersionMap(releaseType):
[19:01] <yofel> [snip]
[19:01] <yofel>     cwd = os.path.dirname(os.path.realpath(__file__))
[19:01] <vertago1> yofel: any tips on sorting out the packing issues from the kci / git repo issues?
[19:01] <yofel> well, guess what, cwd depends on where you run it...
[19:01] <yofel> or where you are when that function is called
[19:06] <santa_> yofel: that cwd depends on where lib/utils.py is located
[19:06] <yofel> not if you os.chdir() before you run the function
[19:06] <yofel> which is what -t does
[19:07] <yofel> I mean, you can rework it to work even with that cwd call, but why would you rely on that in the first place?
[19:08] <santa_> hmm before anything, could you clarify exactly what are you trying to do and the expected behaviour?
[19:09] <santa_> I mean
[19:09] <santa_> $ git-clone-all -r frameworks -t
[19:09] <santa_> ↑ this?
[19:09] <santa_> something else?
[19:10] <yofel> ./git-clone-all -r frameworks -t ./foobar/
[19:10] <yofel> after that all repos should be inside ./foobar/
[19:10] <yofel> which means that git has to be run in foobar/, which means that cwd is in foobar
[19:11] <santa_> oh, ok, I don't think that is difficult to achieve
[19:12] <yofel> probably not, but I hit so many env assumtions in the script that it felt like I'm wasting me time
[19:12] <santa_> give me some minutes to code and think about what you have said so we can reach an "agreement" here
[19:13] <santa_> I don't think there isn't so many env assumptions but let me have a look
[19:13] <yofel> I'm actually happy that you're putting code into lib functions, but I want to eventually have those testable, and the current implementation is rather bad for that
[19:16] <yofel> vertago1: not where it's just a merge conflict. It's better if you look for build failures, missing files, lintian warnings etc. For those you can easily send me a patch that I can apply
[19:17] <yofel> git diff would be idea ofc. The repositories are on http://anonscm.debian.org/cgit/pkg-kde/ and the CI builds from the kubuntu_unstable / kubuntu_stable branches
[19:17] <santa_> yofel: ok. I have seen you have implemented the -t option, it works as expected here
[19:18] <yofel> I think it actually worked for frameworks or so, but did nothing for applications. Something weird like that
[19:18] <yofel> been a while since I tried it
[19:18] <vertago1> has anyone thought about having KCI guess what the problem is to apply tags to build failures?
[19:19] <santa_> yofel: also I'm inclined to think you are wrong about this:
[19:19] <santa_> [20:06] <santa_> yofel: that cwd depends on where lib/utils.py is located
[19:19] <santa_> [20:06] <yofel> not if you os.chdir() before you run the function
[19:19] <Riddell> vertago1: what's up with breeze-icons? I was packaging that today
[19:19] <yofel> possibly, I remember there being something wrong and thought that was it
[19:19] <santa_> I think it works regardless of what you do with os.chdir
[19:21] <santa_> yofel: ok, so would you give the thing another chance, so we can figure out the actual issues?
[19:21] <yofel> let me try
[19:21] <vertago1> Riddell: I am fairly new to you all's packing workflow, but the merger script for breeze icons is complaining of a merge conflict
[19:21] <santa_> we could try it for plasma 5.5.1 or so
[19:21] <Riddell> vertago1: url?
[19:21] <vertago1> Riddell: http://kci.pangea.pub/job/merger_breeze-icons/
[19:22] <vertago1> is there any easy way to scrape the console outputs of the packages so I could look into writing a script to tag them?
[19:23] <yofel> you'll want to talk to sitter about that
[19:23] <vertago1> actually I should wait on that. I am still trying to figure out which branch would be best to look for problems in. Senile?
[19:23] <Riddell> vertago1: thanks, fixed
[19:24] <vertago1> Riddell: thanks
[19:24] <Riddell> vertago1: at some point a manual fix it needed, I'm not sure automating a tag on problems to label them would be worth any time it saved since manual look would still be needed
[19:25] <vertago1> Riddel: yeah, I think it would be only useful if people were good at fixing particular kinds of problems and it was easier for them to find those problems by looking for a tag.
[19:27] <vertago1> I am seeing this error a lot "Upload was likely rejected, we have been waiting for well over 30 minutes!"
[19:28] <vertago1> It doesn't appear to be accurate because the timestamps don't reflect a 30minute wait
[19:29] <santa_> yofel: is it possible that you got something like this: https://paste.kde.org/pnkresnlw ?
[19:29] <yofel> that too, I forgot the mkdir call
[19:30] <yofel> but the script does seem to work now
[19:30] <santa_> yeah, was about to say that
[19:33] <clivejo> does anyone else find that when they click on the taskbar to switch to another prgramme, that the cursor picks up a shortcut instead?
[19:33] <vertago1> yes
[19:33] <clivejo> its really getting on my nerves now
[19:33] <vertago1> and sometimes it crashes plasma
[19:33] <vertago1> or at least it used to
[19:33] <clivejo> I havent crashed plasma in months
[19:33] <vertago1> yeah I think that part might be fixed
[19:33] <vertago1> I don't understand why it is picking up an icon though
[19:34] <clivejo> but cant understand why is keeps picking up the shortcut
[19:34] <clivejo> and it keeps following me until I click on the desktop and create the icon
[19:34] <clivejo> I have to keep a section of desktop clear as an icon dump!
[19:35] <vertago1> clivejo do you think an event might be getting lost so it thinks it is a click and drag instead of a single click?
[19:35] <clivejo> well I thought that it was my wireless mouse
[19:35] <clivejo> but I have a USB wired mouse and its doing the same
[19:35] <vertago1> I have a logitech g9x and have the issue
[19:35] <clivejo> my wireless mouse is logitech
[19:36] <clivejo> but this wired one is a M$ one
[19:36] <clivejo> a Basic Optical Mouse version 1.0
[19:36] <clivejo> 1.0A
[19:37] <yofel> I've seen that, but I can usually get rid by dropping the icon onto the app it came from
[19:37] <vertago1> that is what I have done
[19:37] <shadeslayer> vertago1: re tags , you mean like http://kci.pangea.pub/job/wily_unstable_purpose/74/parsed_console/
[19:37] <clivejo> yofel: its just a bloody pain having to dump the icon somewhere
[19:37] <yofel> agreed
[19:38] <clivejo> when you're busy trying to do something
[19:38] <clivejo> has anyone reported it?
[19:39] <vertago1> shadeslayer: that is several steps toward what I would want to do. The next steps would involve filtering by errors or warnings. That would let you exclude all the build errors do to git
[19:39] <clivejo> I dont know if its my workflow, but the majority of the icons are firefox and dolphin
[19:39] <shadeslayer> Hm, might be possible
[19:39] <clivejo> firefox the vast majority
[19:39] <vertago1> clivejo: I wonder if I could use wireshark's USB monitoring to troubleshoot it
[19:39] <shadeslayer> Iirc Jenkins allows Job tagging
[19:40] <clivejo> vertago1: if you know how, please do!  Id love to see it resolved
[19:40] <vertago1> clivejo I need to be able to trigger it though
[19:40] <clivejo> if 3 of us are experiencing it, must be an issue somewhere
[19:40] <vertago1> clivejo: it seems to be sporadic
[19:41] <clivejo> <---- Xenial up-to-date as of yesterday morning
[19:41] <yofel> happens in wily for me
[19:41] <clivejo> the quicker, or more of a hurry Im in the worse it is
[19:42] <vertago1> clivejo, it may be a click and drag threshold that needs to be adjusted
[19:43] <clivejo> wonder should I mention it in plasma
[19:43] <vertago1> the drag start distance default seems to be 4pixels
[19:43] <clivejo> is it a kubuntu issue or all KDE distros
[19:44] <vertago1> clivejo, I would try upping the drag start distance to 8 pixels or more and see if it makes it not as bad
[19:44] <clivejo> how do I do that?
[19:44] <vertago1> if you search mouse on the application launcher it is under the advanced tab
[19:44] <vertago1> called "drag start distance"
[19:45] <clivejo> ah yes
[19:45] <vertago1> I use a high resolution: 1920x1200 so 4 pixels is fairly small
[19:45] <clivejo> upped to 8
[19:45] <clivejo> will try that for a while
[19:45] <vertago1> you may need it even higher
[19:50] <clivejo> what happened 5-6days ago to throw senial packages off?
[19:50] <santa_> yofel, ok I found what I think it was wrong when you tried it
[19:50] <clivejo> back to over 300 broken
[19:51] <yofel> clivejo: branch switching for stable did that I guess
[19:52] <santa_> yofel: maybe something like this https://paste.kde.org/pm7zbweh6 ?
[19:52] <yofel> don't think so, I think it literally did nothing (package list update from ftp failed?)
[19:53] <clivejo> yofel: any update on how to fix networkmanager-qt ?
[19:53] <yofel> update? that still is waiting for scarlett to update n-m
[19:53] <soee_> Applications 15.12 released :)
[19:54] <yofel> diff: - milestone link. That's better linked from qa
[19:54] <clivejo> soee_: when will you have the packaged and ready for testing :P
[19:55] <soee_> :D
[19:55] <santa_> yofel: in any case I think I have a couple of small changes for git-clone-all
[19:55] <soee_> here i relay on the devs :_-)
[19:56] <yofel> 15.12 added
[19:56] <soee_> topic says that: TODO Apps 15.08.3, should 15.12 be done not the old one ?
[19:56] <santa_> btw this line
[19:56] <santa_> workdir = args.workdir if args.workdir else cwd
[19:56] <yofel> now it does ;)
[19:56] <clivejo> soee_: you do know we are subscribed to the release mailing list and know this already :)
[19:57] <santa_> disappeared misteriously after the merge
[19:57] <soee_> clivejo: i;m like a smart bot that  remainds it anyway :D
[19:57] <yofel> o.O
[19:57] <clivejo> like a facebook poke
[19:58] <yofel> now someone has to write a depression bot that constantly reminds us of all the things we have to do
[19:59] <vertago1> you can put writing that bot on the list of things the bot should remind you to do
[19:59] <soee_> :}
[19:59] <yofel> ahahaha
[19:59] <clivejo> oh kolab will be at FOSDEM
[20:02]  * yofel goes back to making ppa-build-status write out json
[20:02]  * clivejo wishes he knew what was broken and how to fix it
[20:03] <yofel> the script is currently both a) a data processor, b) a print-out-html-string-because-that's-the-cool-way thingy because that was easy to do and because nobody cares and because AAAAARGh
[20:05] <clivejo> like parley, why does the AMD64 build ok, but 386 wont install the deps?!?
[20:05] <yofel> where?
[20:05] <vertago1> clivejo, that sounds like there may be a naming difference between amd64 and i386
[20:06] <clivejo> vertago1: https://launchpadlibrarian.net/230041926/buildlog_ubuntu-xenial-i386.parley_4%3A15.08.2%2Bgit20151215.0457%2B16.04-0_BUILDING.txt.gz
[20:06] <yofel> probably more like other packages not building on i386 as well
[20:06] <vertago1> hmm
[20:06] <clivejo> kio-dev but it is not going to be installed
[20:07]  * clivejo kicks KCI
[20:07] <vertago1> why can't it fetch teh gpg key?
[20:07] <yofel> yeah, you can't debug that without aptitude, apt with debug output, or dose output
[20:07] <yofel> good question, but this is launchpad internal, so it doesn't really need to
[20:08] <santa_> yofel: pushed the simple fixes to https://github.com/jmsantamaria/kubuntu-automation-work
[20:08] <santa_> this way it will work better
[20:08] <santa_> btw I shouldn't have called that variable cwd, since it's confusing
[20:09] <vertago1> santa_ scriptdir would probably make sense
[20:09] <santa_> or installdir or something like that
[20:11] <yofel> merged. Into master btw. as we should really start using them (And I kind of messed up while juggling branches)
[20:12] <santa_> ok, I will try to be here as much as possible to assist with issues
[20:12] <yofel> #packages we know use a different version than the rest of the release
[20:12] <yofel> differentVersion = ["baloo-kf5", "kfilemetadata-kf5", "kdepimlibs", "kdepim", "kdepim-runtime", "kde4libs"]
[20:13] <yofel> wow, even ppa-build-status has hardcoded configs /o\
[20:24] <vertago1> clifejo: so that is the kubuntu_xenail_archive branch here http://anonscm.debian.org/cgit/pkg-kde/applications/parley.git/refs/heads?
[20:25] <clivejo> the KCI is using the unstable and stable branches
[20:25] <vertago1> ok
[20:25] <vertago1> is that parley the stable branch?
[20:27] <clivejo> both stable and unstable are failing
[20:27] <clivejo> due to the 386 build
[20:27] <clivejo> I attempted to fix it and got the AMD64 to build locally and then on KCI
[20:28] <clivejo> but the 386 keeps FTBFS
[20:28] <clivejo> I have no idea why
[20:28] <vertago1> clivejo are all the dependencies available?
[20:28] <vertago1> I am looking at the list
[20:28] <vertago1> cmake,
[20:28] <vertago1>                debhelper (>= 9),
[20:28] <vertago1>                extra-cmake-modules,
[20:28] <vertago1>                imagemagick,
[20:28] <vertago1>                kdoctools-dev,
[20:28] <vertago1>                kio-dev,
[20:28] <clivejo> as far as I can see
[20:28] <vertago1>                kross-dev,
[20:28] <vertago1>                libkeduvocdocument-dev,
[20:28] <vertago1>                libkf5config-dev,
[20:28] <vertago1>                libkf5coreaddons-dev,
[20:28] <vertago1>                libkf5crash-dev,
[20:29] <vertago1>                libkf5i18n-dev,
[20:29] <vertago1>                libkf5kcmutils-dev,
[20:29] <vertago1>                libkf5khtml-dev,
[20:29] <vertago1>                libkf5newstuff-dev,
[20:29] <vertago1>                libkf5sonnet-dev,
[20:29] <vertago1>                libqt5svg5-dev,
[20:29] <vertago1>                libxml2-dev,
[20:29] <vertago1>                libxslt-dev,
[20:29] <vertago1>                pkg-config,
[20:29] <vertago1>                pkg-kde-tools (>= 0.12),
[20:29] <vertago1>                qtmultimedia5-dev,
[20:29] <vertago1>                qtscript5-dev
[20:29] <clivejo> vertago1: we prefer to use a paste bin :)
[20:29] <vertago1> yeah I didn't realize it was going to do that
[20:29] <clivejo> https://paste.kde.org/
[20:29] <clivejo> or the likes
[20:30] <vertago1> quassel keeps sending me to file : ///home..../kioexec/krun/ when I click URLs
[20:30] <clivejo> I did attempt to setup a 386 pbuild but I ran into problems
[20:30] <vertago1> how do you sent one up?
[20:31] <vertago1> I can setup a i386 container
[20:31] <clivejo> https://wiki.ubuntu.com/PbuilderHowto
[20:31]  * clivejo doesnt like 386
[20:32] <vertago1> have you use lxc at all?
[20:32] <vertago1> they arn't that bad. I set one up because of a regression in samba
[20:32] <yofel> clivejo: what problem did you run into regarding i386 pbuilder?
[20:33]  * clivejo has a slow internet connection and had to upload and downland calligra source on numurious occassions
[20:33] <clivejo> yofel: getting the packages
[20:33] <yofel> o.O that should work the same as always when in an i386 chroot
[20:35] <santa_> The following packages couldn't be cloned:
[20:35] <santa_> spectacle
[20:35] <santa_> ↑ what's that?
[20:37] <vertago1> pbuilder create --architecture i386?
[20:37] <yofel> seems to be some new app in 15.12
[20:37] <vertago1> looks like it wants sudo
[20:37] <vertago1> I am going to see if I can run it in userland
[20:38]  * yofel has a very custom pbuilder setup (not userland)
[20:38] <yofel> so can't really help with the defaults
[20:38]  * clivejo wonders how yofel has pbuilder set up
[20:38] <vertago1> it doesn't work in userland because of debbootstrap
[20:39] <vertago1> I got it to start fetching stuff
[20:39] <clivejo> mine fetched lots of stuff, but then stopped 
[20:39] <clivejo> that ppa seems to corrupt things
[20:39] <yofel> enjoy my pbuilderrc paste.ubuntu.com/14056289/ - lots of stuff you don't need, but maybe you'll find something interesting
[20:39] <vertago1> the problem is I am on wiley so I don't know if it will be a good test
[20:40] <yofel> hm, I need to update the debian codenames ^^
[20:40] <clivejo> vertago1: you can create pbuilder instances for xenial too
[20:41] <clivejo> BTW senial is sitters codename for xenial
[20:41] <clivejo> sorry senile
[20:42] <vertago1> is that how it is pronounced anyway?
[20:42] <clivejo> he has me typing senial by mistake
[20:42] <BluesKaj> zenial
[20:42] <clivejo> only if you have a certain accent ;)
[20:42] <vertago1> hahaha
[20:42] <vertago1> BlueKaj that is what I thought
[20:44] <clivejo> grrrr stupid symbols
[20:46] <clivejo> what is purpose anyway?
[20:46] <clivejo> Ive packaged it and have no idea what its for!
[20:47] <yofel> Description: library for abstractions to get the developer's purposes fulfilled
[20:47] <yofel> uhuuuuh...
[20:47] <yofel> sounds very meta
[20:47]  * clivejo feels enlightened
[20:48] <clivejo> yofel: its part of framesworks now?
[20:48] <yofel> looks like it
[20:48] <yofel> maybe it has a purpose there
[20:48] <clivejo> why doesnt it have a frameworks version number?
[20:49] <vertago1> hmm
[20:49] <vertago1> it looks like my system config is incompatible with pbuilder as is
[20:50] <yofel> oh, it's not in 5.17
[20:50] <yofel> #libnamingconfusion
[20:50] <vertago1> I am going to have to get it to download the packages to the same physical device I am making the base configs on
[20:51] <yofel> if you're getting ln errors, you can disable the aptcache and use bindmounts or so
[20:51] <vertago1> it is trying to hardlink across two hard drives
[20:52] <clivejo> strange, its under frameworks in debian git - http://anonscm.debian.org/cgit/pkg-kde/frameworks/purpose.git/
[20:52] <yofel> right, I get that too when building in tmpfs, so I'm using this when I do:
[20:52] <yofel> BINDMOUNTS="/var/cache/apt/archives/ /run/"
[20:52] <yofel> APTCACHE=""
[20:52] <vertago1> I have a ssd for / and a platter drive for /home
[20:53] <vertago1> I am just going to let it use /var for the base
[20:53] <vertago1> I may need to move it later though
[20:59] <santa_> https://github.com/jmsantamaria/kubuntu-automation-work/commits/master
[20:59] <santa_> ↑ yofel stuff needed to bump the build depends for the last versions
[21:02] <yofel> I really don't see the point of that list you know
[21:02] <yofel> but thanks for the update
[21:02] <santa_> the json with all the -dev packages?
[21:03] <yofel> yep
[21:03] <yofel> or well, the package list has a potential use, but the versions?
[21:03] <santa_> they have the epoch or not
[21:04] <santa_> so no need to hardcode which packages are epoch'ed
[21:04] <vertago1> clivejo so after getting a i386 pbuilder setup where do I get the .dsc to do the build?
[21:05] <santa_> note that the list is generated automatically with dev-package-names-list
[21:05] <santa_> also note that this script could be glued with the bump-* script in the future
[21:05] <yofel> aaaaah, that script actually does look up the real epoch
[21:05] <yofel> ok
[21:06] <santa_> yeah, parses the changelogs
[21:08] <clivejo> vertago1: debuild -S
[21:08] <vertago1> clivejo, in what context?
[21:09] <clivejo> to get the .dsc to build in pbuilder
[21:10] <vertago1> I need the tar files
[21:12] <vertago1> should I enter the pbuild environment and then use apt-source?
[21:12] <vertago1> I mean apt-get source
[21:14] <clivejo> well I grab the debian git branch and then use uscan to grab the source
[21:14] <vertago1> it is complaining that I don't have a sources.list
[21:14] <yofel> that's an option. Other one is to look up the URL on the web ui, or to use pull-ppa-source from lp:kubuntu-dev-tools, or to just rebuild from git as clive said
[21:15] <clivejo> but KCI is grabbing the source directly from git
[21:15] <vertago1> I already have the source from git and I checkout out the xenail-unstable branch
[21:15] <clivejo> so in those cases I download the source from KCI PPA's
[21:16] <clivejo> then you need to debuild -S to build the source
[21:16] <clivejo> and instead of uploading to your PPA, you build it in pbuilder
[21:17] <clivejo> for example  use pbuilder-dist xenial build ../*dsc
[21:17] <clivejo> that builds it in a nice clean xenial install
[21:17] <clivejo> on my machine
[21:19] <clivejo> yofel: do you know what top level package creates libkf5kcmutils-dev ?
[21:19] <vertago1> it is complaing about no .orig.tar.xz even though it is there
[21:19] <yofel> clivejo: apt-cache showsrc libkf5kcmutils-dev
[21:19] <vertago1> it looks like the version number is wrong
[21:20] <santa_> kscreenlocker (exit status = 1)
[21:20] <santa_> discover (exit status = 1)
[21:20] <santa_> breeze-gtk (exit status = 1)
[21:21] <clivejo> check debian/changelog and make sure the versions are the same
[21:21] <santa_> ↑ this packages from plasma doesn't have a kubuntu_xenial_archive branch
[21:21] <vertago1> how do you keep uscan from downloading newer versions?
[21:21] <yofel> they're new
[21:22] <santa_> could you create the branches then so I can continue to test the thing?
[21:22] <santa_> (no hurry)
[21:25] <vertago1> I must have the wrong download url for uscan it says no matching hrefs for 15.08.2
[21:26] <yofel> no, that's uscan not properly fetching all versions it could find.
[21:26] <yofel> I believe there's an uscan bug report for that
[21:27] <vertago1> looks like I will have to do it manually
[21:30] <vertago1> ls
[21:33] <vertago1> hmm my build failed but for a different reason
[21:34] <vertago1> actually when I looked at it more closely it is the same error, but my base probably has less installed by default
[21:36] <vertago1> http://paste.ubuntu.com/14056655/
[21:36] <clivejo> yofel: https://launchpadlibrarian.net/230149652/buildlog_ubuntu-xenial-i386.kdeclarative_5.17.0%2Bgit20151216.0354%2B16.04-0_BUILDING.txt.gz says libkf5declarative-dev_5.17.0+git20151216.0354+16.04-0_i386.deb is being built ok
[21:36] <yofel> okaaaay..?
[21:37] <clivejo> yet sbuild-build-depends-kcmutils-dummy : Depends: libkf5declarative-dev (>= 5.16.0~) but it is not going to be installed
[21:37] <clivejo> why?
[21:37] <yofel> apt saying that doesn't mean that package is the problem
[21:37] <yofel> it is the package that apt fails on, due to dep issues with other packages
[21:38] <yofel> as I said, you need the output from aptitude, or apt with -o debug::pkgproblemresolver=true, or some kind of dose output to debug this
[21:38] <yofel> the apt output in the buildlog is next to useless
[21:39] <clivejo> it only seems to be an issue in 386 
[21:39] <vertago1> yofel is there a way to get apt to include that option inside pbuilder?
[21:39] <yofel> you can put it into the chroot's apt.conf I gues
[21:39] <yofel> s
[21:40] <vertago1> how do you change the base and save updates?
[21:40] <vertago1> nvm
[21:40] <vertago1> I will just manually edit the .tgz
[21:40] <yofel> pbuilder login --save-after-login
[21:40] <vertago1> that is easier
[21:41] <yofel> just make sure your last command exist with 0
[21:41] <yofel> otherwise it won't save
[21:42] <yofel> python 2's datetime class has no easy way to generate a unix timestamp, seriously?
[21:42] <yofel> first time that I see something useful in 3
[21:44] <vertago1> yofel are you talking about an epoch timestamp? I am pretty sure you can get that in python 2
[21:45] <yofel> I'm properly bllind, but I see nothing on https://docs.python.org/2/library/datetime.html
[21:45] <yofel> I'll just port the script to py3. Needs to be done anyway
[21:47] <vertago1> yofel there is no obvious function, but it looks like most people just use .strftime("%s")
[21:47] <vertago1> which is ugly because you have to parse a format string
[21:47] <clivejo> yofel: I used sudo DIST=xenial ARCH=i386 pbuilder create does this overwrite my AMD64 environment?
[21:48] <vertago1> clivejo I used pbuilder create --basetgz xenial_i386_base.tgz --architecture i386 --distribution xenial
[21:48] <yofel> not with my config if that's what you're trying...
[21:48] <vertago1> my config is empty
[21:49] <vertago1> minus the parallel build lines I copied from yofel's config
[21:49] <clivejo> Im reviewing my 386 setup, trying to find out why its not working
[21:51] <clivejo> but I only have one xenial-base.tgz
[21:51] <clivejo> I think Ive overwritten my amd64 environment
[21:51] <vertago1> clivejo I explicity name my base.tgz to keep from doing that
[21:52] <yofel> my setup will e.g. create a /var/cache/pbuilder/xenial-amd64.tgz
[21:52] <clivejo> vertago1: thanks, I must do that in future
[21:52] <clivejo> mine seems to put it in ~/pbuilder
[21:52] <yofel> right, depends on your config
[21:53] <clivejo> which is what I want my /home is on a HDD and keeps writes off my SSD
[21:54] <vertago1> this is the new error I get after adding pkgproblemresolver to the config: http://paste.ubuntu.com/14056915/
[21:54] <vertago1> it looks like my source urls are wrong
[21:54] <vertago1> kdoctools-dev which is a virtual package and is not provided by any available package.
[21:55] <clivejo> did you add the KCI PPA?
[21:55] <vertago1> no
[21:56] <vertago1> I will do that now
[21:57]  * clivejo waits on new pbuilder base to download
[21:57] <clivejo> sucks being on a slow connection
[21:59] <clivejo> vertago1: what are you trying to build?
[21:59] <vertago1> parley on i386
[21:59] <vertago1> since it was broken
[22:00] <vertago1> I am having trouble finding the exact ppa I should add
[22:01] <vertago1> this one: https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable?
[22:01] <clivejo> looks like it
[22:03] <clivejo> I think its higher up in the dep tree
[22:04] <clivejo> a lot of those failing on KCI are due to the 386 build
[22:04] <vertago1> I just got the repo added
[22:05] <clivejo> vertago1: are you on LP?
[22:05] <yofel> wait, you're keeping writes off the SSD? why? They're built for stuff like that
[22:05] <vertago1> yofel my home dir is much much larger than my ssd
[22:06] <clivejo> yofel: I read keeping writes off a SSD helps its life
[22:06] <yofel> the split itself I understand, I had that myself for a while
[22:07] <vertago1> I just have to make sure I don't fill up the ssd, so far it isn't a problem but I have had to put /var/lib/mysql off the ssd before
[22:07] <yofel> clivejo: you should measure the wear and see if it matters. From my experience it doesn't unless you have really heavy workloads. And for package building the SSD is a nice thing
[22:07] <vertago1> I have enough ram I could do the package building in ram
[22:07] <vertago1> unless it is a big package like gcc
[22:08] <vertago1> or plasma
[22:08] <clivejo> yofel: its small so I just use it for system, all tmp and cache are on HDD
[22:08] <yofel> ah, then it might matter
[22:08] <yofel> the smart data usually has some vendor dependent wear indicator
[22:08] <clivejo> then /home is backed up to 2Tb external HDD 
[22:09] <clivejo> I dont want to kill my SSD, I love it too much!
[22:10] <yofel> that's how I felt about my first 60G SSD, in the end I stopped worrying, but still only managed to wear it out ~50% after ~5 years
[22:10] <vertago1> I have 1.02TB of writes to mine
[22:11] <clivejo> oh, this time pbuilder create has made xenial-i386-base.tgz
[22:12] <clivejo> in /var/cache/pbuilder/xenial-i386-base.tgz
[22:12] <clivejo> strange
[22:12] <clivejo> didnt do that last time
[22:13] <yofel> my server SSD (300GB intel 320) says it wrote 86TiB, and the wear indicator sits at 94% life left (The warranty was 35TiB). I guess they measure the absolute worst case workload
[22:14] <vertago1> here is the most recent failure
[22:14] <vertago1> http://paste.ubuntu.com/14057389/
[22:15] <yofel> is universe enabled in the PPA?
[22:21] <clivejo> I cant get i386 to work
[22:27] <vertago1> i am enabling universe now and will retry it
[22:29] <vertago1> it appears to be working
[22:29]  * clivejo gives up again, too tired
[22:30] <vertago1> yofel it looks like for some reason the repos are not right for the i386 builds
[22:30] <vertago1> the error matches the error I got before I added the KCI ppa
[22:31] <clivejo> vertago1: the dep's are failing too
[22:31] <yofel> could be, still leaves the question of what the issue is
[22:31] <vertago1> mine is building though
[22:32] <vertago1> no dependency problems after enabling the ppa and universe
[22:34] <vertago1> it succeeded but I don't know where it put the .deb file
[22:34] <vertago1> where is the kci build code for setting up pbuilder for i386?
[22:37] <vertago1> I have enough information I could probably write a wiki page tutorial on how to setup a local test
[22:42] <yofel> kci doesn't use pbuilder but uploads the builds to launchpad (which uses some customized sbuild AFAIR)
[22:43] <vertago1> yofel any idea on how to configure its source repos?
[22:43] <yofel> grrr, whoever said that string handling in py3 improved was crazy
[22:44] <yofel> vertago1: pbuilder has an OTHERMIRROR setting that you might be able to use to inject a ppa into --create
[22:44] <vertago1> I meant for launchpad so kci can be fixed
[22:45] <clivejo> vertago1: do you have buildlog for your parley build in pbuilder?
[22:45] <clivejo> see what version of the packages its installing
[22:46] <vertago1> it looks like i need to run it again and pipe the output to a file
[22:47] <vertago1> or use --logfile
[22:47] <clivejo> could be installing older stable versions
[22:52] <vertago1> http://paste.ubuntu.com/14058223/
[22:52] <clivejo> its installing older versions
[22:53] <clivejo> libkf5kcmutils-data [5.15.0-0ubuntu2 (xenial)]   
[22:53] <clivejo> libkf5kcmutils5 : Depends: libkf5kcmutils-data (= 5.17.0+git20151214.0845+16.04-0) but it is not going to be installed.
[22:54] <clivejo> installing from the archive rather than the PPA
[22:55] <clivejo> can you add a hook to drop into the terminal
[22:55] <clivejo> see why it cant/wont install 5.17.0
[22:56] <vertago1> how do I do that?
[22:57] <clivejo> https://wiki.ubuntu.com/PbuilderHowto#Using_the_Kubuntu_pbuilder_hooks
[22:58] <clivejo> theres a hook to drop into the pbuilder environment after the build
[22:59] <clivejo> cant remember now to do it exactly
[22:59] <clivejo> how
[23:00] <vertago1> I see list missing
[23:01] <yofel> C10shell is what you need
[23:02] <clivejo> yofel to the rescue!
[23:02] <yofel> helping you guys is more fun than fixing python str != byte issues
[23:02] <clivejo> vertago1: http://bazaar.launchpad.net/~kubuntu-packagers/pbuilder/pbuilder-hooks/view/head:/C10shell
[23:03] <clivejo> yofel: does it only drop to shell if it fails?
[23:03] <yofel> C10shell yes, B10shell would drop on success
[23:03] <clivejo> cause it is building successfully
[23:04] <yofel> :96
[23:04] <yofel> oops
[23:04] <clivejo> its dropping back to 5.15.0-0ubuntu2 instead of using 5.17.0
[23:06] <yofel> can you install the 5.17 version by hand?
[23:07] <clivejo> I cant even get a i386 environment setup :(
[23:07] <vertago1> ok I got a shell after the build
[23:08] <vertago1> The following packages have unmet dependencies:
[23:08] <vertago1>  libkf5khtml5 : Depends: libkf5khtml-data (= 5.17.0+git20151214.0838+16.04-0) but 5.17.0+git20151215.0437+16.04-0 is to be installed
[23:12] <vertago1> This one probably needs to be fixed first: http://kci.pangea.pub/job/xenial_unstable_khtml/
[23:13] <vertago1> https://launchpadlibrarian.net/230040872/buildlog_ubuntu-xenial-i386.khtml_5.17.0%2Bgit20151215.0437%2B16.04-0_BUILDING.txt.gz
[23:14] <clivejo> thats failing on kio-dev, libkf5parts-dev and libkf5wallet-dev
[23:14] <vertago1> those are the same as before
[23:14] <clivejo> thats why I think its up the dep tree somewhere
[23:15] <clivejo> ah - https://launchpadlibrarian.net/230149363/buildlog_ubuntu-xenial-i386.kio_5.17.0%2Bgit20151216.0344%2B16.04-0_BUILDING.txt.gz
[23:15] <clivejo> symbols
[23:17] <vertago1> it looks like a function name was changed
[23:18] <vertago1> - _ZNK13KUrlNavigator7Private17retrievePlacePathEv@Base 4.96.0 + _ZNK13KUrlNavigator7Private16retrievePlaceUrlEv@Base 5.17.0+git20151216.0344+16.04-0
[23:27] <clivejo> yofel: ping
[23:27] <yofel> hm?
[23:27] <clivejo> Ive updated the symbols for kio
[23:28] <yofel> good?
[23:28] <clivejo> but not sure on what to put in the changelog
[23:28] <yofel> for CI? nothing
[23:29] <yofel> or what branch are you on?
[23:29] <clivejo> kubuntu_unstable
[23:29] <yofel> nothing then
[23:29] <yofel> just write a proper commit message
[23:30] <vertago1> hopefully that is at least part of a fix if not a full fix
[23:31] <clivejo> soon see :)
[23:31] <clivejo> KCI has picked it up and building now
[23:33] <clivejo> vertago1: how long did it take to build on your machine?
[23:33] <vertago1> not very long but I was using 8 cores
[23:34] <clivejo> last build on KCI was 24mins
[23:34] <clivejo> so I guess LP is slower 
[23:35] <yofel> that includes the publishing
[23:36] <clivejo> i386 is 25%
[23:36] <clivejo> https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+build/8449523
[23:38] <clivejo> yofel: BTW can I start KCI rebuilds?
[23:39] <clivejo> I logged in with my LP ID but says I dont have permission
[23:39] <yofel> that requires being in ~kubuntu-members
[23:39] <clivejo> oh
[23:41] <yofel> wtf? in my script here, log.index() always throws a "ValueError: substring not found", but does return the correctly found index
[23:41] <stacksUpHigh> is gnome good? new to linux..
[23:41] <stacksUpHigh> python programming is so much better using ubuntu though
[23:41] <yofel> #ubuntu-gnome will likely answer with yes, we will with no
[23:41] <yofel> so I don't think we can help much there ^^
[23:42] <clivejo> stacksUpHigh: We use the KDE desktop, hence the K in Kubuntu
[23:42] <vertago1> I haven't used gnome much since gnome 2
[23:43]  * clivejo is not a fan of Gnome or Unity
[23:44] <clivejo> well the buildlogs look good :)
[23:44] <clivejo> yofel: KCI retries all builds at midnight UTC?
[23:45] <yofel> during the night, no idea what exact time
[23:45] <yofel> sounds about right though looking at the logs
[23:45] <clivejo> I seem to get pinged every night around that time!
[23:46] <vertago1> that is 15minutes from now
[23:46] <vertago1> hopefully it finishes before that
[23:47] <clivejo> its finished
[23:47] <clivejo> just needs to publish the files to the PPA
[23:48] <clivejo> always forget about that part
[23:48] <clivejo> takes ages!
[23:49] <clivejo> the bot should post a message in here
[23:51] <yofel> *facepalm*
[23:51] <yofel> I spent an hour debugging a corrupt cache. RAGE
[23:51] <vertago1> ouch
[23:51] <vertago1> ccache?
[23:52]  * clivejo offers Phillip a stiff drink
[23:52] <yofel> no, the script has it's own caching
[23:52] <yofel> heh thanks
[23:52] <yofel> and kio is happy
[23:52] <clivejo> yippee we saved a Lemming
[23:52] <vertago1> hopefully all its dependents become happy once kci gives them the kick to rebuild
[23:53] <clivejo> wheres wily
[23:53]  * clivejo kicks kubuntu-ci bot
[23:53] <vertago1> does the merge work?
[23:53] <yofel> brrr, there's even more html inlining *-.-
[23:54] <clivejo> hopefully purpose can build tonight and I can fix the symbols tomorrow
[23:56] <yofel> I triggered a build for it
[23:56] <clivejo> there are other deps need to build first
[23:58] <clivejo> kaccounts, kcmutils and kdeconnect