19:15 <xnox> #startmeeting DMB
19:15 <meetingology> Meeting started Mon Aug 17 19:15:35 2015 UTC.  The chair is xnox. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
19:15 <meetingology> 
19:15 <meetingology> Available commands: action commands idea info link nick
19:15 <xnox> !dmb-ping
19:15 <ubottu> cyphermox, infinity, Laney, micahg, xnox, bdmurray, stgraber: DMB ping
19:15 <xnox> roll-call bdmurray cyphermox xnox micahg_work are present
19:16 <xnox> #topic previous actions
19:16 <xnox> bdmurray: micahg_work: there are previous actions on the agenda
19:16 <xnox> all done, or not so much?
19:17 <micahg_work> not so much :(
19:17 * xnox doesn't see Unit193 around
19:17 <micahg_work> mozc was in the packageset
19:17 <xnox> ack.
19:17 <bdmurray> I setup a bzr branch although its not clear if that is sufficient or not.
19:17 <xnox> ok.
19:17 <xnox> i don't see Unit193
19:17 <xnox> so i guess, move to sil2100 application
19:17 <bdmurray> I believe micahg_work pinged Unit193
19:18 <xnox> well, we can keep that item on the agenda for the time being, i guess.
19:18 <xnox> #topic Core Developer Application Łukasz Zemczak sil2100
19:18 <xnox> sil2100: hola! please introduce yourself and your application =)
19:19 <sil2100> Hello dear DMB!
19:19 <xnox> https://wiki.ubuntu.com/LukaszZemczak/CoreDeveloperApplication
19:19 <sil2100> My name is Łukasz Zemczak, I'm a MOTU that would like to advance to a CoreDev
19:20 <xnox> And i see you have been motu for over a year now.
19:20 <sil2100> Most of the time I'm dealing with touch packages, operating the CI Train, managing the touch seeds, managing image builds and channels, acting as one of the release managers of the touch stack
19:20 <sil2100> I also have some experience with non-touch through patch pilot sessions
19:20 <sil2100> I do them rarely, but I try to spend at least a few hours every now and then
19:21 <sil2100> In the past it was more frequent, but after we got the few official ubuntu touch phones on the market I didn't have as much free cycles
19:22 <sil2100> Becoming a CoreDev will also help me in my patch pilot duties, as there's more main packages on the sponsoring queue than universe usually ;)
19:23 <xnox> sil2100: ok. looking at your set of packages you work on, e.g. uploaded / synchronised list, they seem to be mostly universe things.
19:23 <xnox> sil2100: which main packages did you modify to date, and proud off, that got sponsored into ubuntu?
19:24 <sil2100> hmm, that's a hard one, my memory is not so good, would have to think about that for a bit
19:24 * xnox looks through your history.
19:24 <sil2100> There weren't so many of those, I usually tried working in the fields where I can do the most, so universe - I helped out in some main transitions, but nothing that super specific
19:26 <sil2100> There were a few during the libav11 transiiton too... there was also the upower transtion we did, but not sure if that counts as it was in the infameous ubuntu-rtm distro
19:27 <xnox> ok, from renet there is https://launchpad.net/ubuntu/+source/thumbnailer/1.2+14.10.20140901.is.1.2+14.10.20140814-0ubuntu1 in main
19:27 <xnox> it FTBFS across the board
19:27 <xnox> click in utopic built https://launchpad.net/ubuntu/+source/click/0.4.31.2.is.0.4.30
19:27 <xnox> revert https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.4+14.10.20140820.is.0.5.3+14.10.20140806-0ubuntu1
19:27 <xnox> in universe
19:28 <sil2100> Yeah, the reverts are automatic creations from the CI Train tool
19:28 <xnox> sil2100: patch piloting can be done without upload rights -> cause most of things in the queue need review, comments, test building and +1. That would make it easier for those with upload rights, to quickly upload those things.
19:28 <sil2100> All those funny ones with versioning of version.is.version - I don't remember what happened with that one, but it was probably one attempt in a crisis and trying to revert a really broken package
19:29 <cyphermox> there's some older stuff in -changes emails I can see as qtbase-opensource-src/5.0.2+dfsg1-7ubuntu18
19:29 <sil2100> xnox: yes, I know as other MOTUs do that as well, but I always thought that I'll be of more use if I decrease the queue itself by doing uploads
19:30 <sil2100> If there were no urgent universe packages in the queue, I was moving to main ones, but that wasn't too frequent from my side
19:30 <cyphermox> sil2100: so, how would you say the CI Train work of reviewing others' package prepare you for having permission to upload any package in the Ubuntu archive?
19:31 <cyphermox> I think since this is a particularly unusual situation in where you don't necessarily get to upload many things yourself because it goes through CI Train, but you do see a whole lot of stuff and people go to you for help
19:31 <xnox> sil2100: from what i can see, there aren't many things in main that you have been working on. and most of your work is based on reviews & landing other peoples code. I wouldn't feel confident granting main upload rights for all packages, without much evidence of working on main packages.
19:31 <cyphermox> I'm not sure what precedent we may or may not want to make, but I think it probably warrants discussion.
19:31 <sil2100> It gives me an overall idea of possible packaging issues and problems that inexperienced developers were having
19:32 <sil2100> We're using the CI Train for main packages most of the time, so most of the main uploads I do I drive them through the CI Train
19:32 <xnox> sil2100: can you list some reasons for a package to FTBFS?
19:32 <sil2100> Every main upload needs to be ACKed by a core-dev, but before that happens I have to do a review of it
19:33 <bdmurray> Do you have examples of those reviews?
19:33 <cyphermox> sil2100: would you have examples of things that went particularly *not* well through the CI Train that you caught too late, or whatnot, that could have been handled differently?
19:33 <cyphermox> (or examples of outstanding work via...)
19:33 <sil2100> One of the most common reasons for a FTBFS of a new package is the lack of build-dependencies or invalid versions of such - another can be a change in the toolchain, or even an unnoticed ABI break in one of the dependent packages
19:34 <sil2100> Usually the last one is caught by symbol files in our packages
19:35 <xnox> sil2100: why did this package FTBFS? https://launchpadlibrarian.net/214593878/buildlog_ubuntu-wily-amd64.gunicorn_19.0-6ubuntu1_BUILDING.txt.gz
19:36 <sil2100> sbuild-build-depends-gunicorn-dummy : Depends: tox but it is not installable <- from the first look it seems that there's a dependency problem
19:36 <sil2100> But I would need to check what sbuild-build-depends-gunicorn-dummy is and what's the tux dep it has, and why it's not installable
19:36 <xnox> sil2100: what is sbuild-build-depends-gunicorn-dummy?
19:37 <xnox> sil2100: by the way, tox is installble in wily.
19:37 <sil2100> Sometimes when it's not super obvious on first glance, I run a chroot for the given system and try to install the build deps as the build machine does
19:37 <sil2100> Let me check
19:37 <xnox> i can do that, just did, tox is intallable.
19:38 <xnox> why would a tox be installable locally in a chroot, but wouldn't be installable in launchpad during a particular package build?
19:38 <xnox> by the way, which package is being built now?
19:38 <xnox> (now, as in, in the above changelog)
19:38 <sil2100> dpkg-deb: building package 'sbuild-build-depends-gunicorn-dummy'
19:38 <sil2100> And a package can be uninstallable with other packages, for instance
19:39 <sil2100> Because of a conflict
19:39 <xnox> true, but there is no conflict here, and apt would say about it.
19:39 <xnox> by the way package 'sbuild-build-depends-gunicorn-dummy' -> is not the one being built here.
19:40 <sil2100> The build log is in overall from the gunicorn
19:40 <sil2100> package
19:40 <xnox> ok.
19:40 <xnox> correct.
19:40 <sil2100> Checking the source if you don't mind
19:41 <xnox> yeah, you can look at anything =)
19:41 <xnox> and the build fails at: Install gunicorn build dependencies (apt-based resolver), stage of sbuild
19:41 <xnox> with failing to install tox.
19:42 <xnox> btw. sbuild-build-depends-gunicorn-dummy is what it says on the tin, a dummy package sbuild generates to install build dependencies of gunicorn. Kind of a hack, because one cannot do apt-get build-dep against an unpacked source package =(, `apt-get build-dep` only works against packages that are already built and published in the archive.
19:43 <xnox> sil2100: which component of the archive is gunicorn in?
19:44 <sil2100> Ok, this is something I did not know, ugh
19:44 <sil2100> It's a main component
19:44 <xnox> sil2100: ok. and which component is tox in?
19:45 <sil2100> Ah, universe! A main-mismatch!
19:45 <xnox> sil2100: how do i check components of packages from command line?
19:46 <sil2100> Interesting though, as usually in the past builds didn't fail because of that, I remember we had multiple cases where people had main packages depping on universe and we only caught it right before publishing
19:46 <sil2100> BUt that's probably because we built everything in PPAs
19:46 <sil2100> And those don't have the checkbox for checking this checked by default
19:46 <sil2100> xnox: I usually use rmadison for this
19:46 <sil2100> Although it tends to be slow nowadays
19:47 <xnox> sil2100: ok.
19:48 <xnox> sil2100: where would you check all "main-mismatch" in the archive?
19:49 <sil2100> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt <- there's this place here, but there's also e-mails sent on each new one
19:50 <xnox> sil2100: ok. and you know about graphical output for them as well, there is .svg about it
19:50 <xnox> sil2100: and there is also a separate one generated for -proposed
19:50 <sil2100> Yeah, all in the http://people.canonical.com/~ubuntu-archive place
19:51 <xnox> sil2100: i would recomend to check those out, and see if you can prepare uploads to resolve those, and or file MIR.
19:51 <xnox> sil2100: have you filed MIR before?
19:51 <micahg_work> is there a tool that you can use to see if all of the dependencies for a package are in main/restricted?
19:51 <sil2100> xnox: yes, a few ones I remember, most for touch packages of course...
19:52 <sil2100> micahg_work: check-mir :)
19:52 <xnox> ok. good.
19:52 <micahg_work> yep!
19:52 <xnox> sil2100: what is NBS? how to resolve them?
19:52 <sil2100> didrocks whipped me in the past for not using it
19:53 <sil2100> I remember that being Not Buildable from Source, but I need to think what it was about
19:53 <sil2100> *built
19:53 <xnox> good
19:53 <sil2100> I don't think I resolved any of those before though...
19:54 <xnox> http://people.canonical.com/~ubuntu-archive/nbs.html
19:54 <cyphermox> sil2100: did you help out with the gcc5 transition?
19:54 <sil2100> cyphermox: not too much... I was doing some work uploading/merging changes from the transition itself and helped out developers with packaging questions
19:55 <sil2100> But not as much as I would like
19:55 <cyphermox> it's fine, I'm just trying to figure things out
19:56 <sil2100> xnox: I suppose NBSes might be cases when certain packages depend on some binary packages that are no longer provided by source packages?
19:56 <sil2100> (a bit guessing here)
19:56 <xnox> sil2100: correct.
19:56 <sil2100> In that case I suppose those can be resolved by either adding transitional packages or, if a package got renamed, maybe adding a Provides and making those virtual?
19:57 <sil2100> (or for the case the same functionality is provided by a different package now)
19:57 <xnox> sil2100: no. usually what needs to be done, is those dependand package need to be rebuild to depend on new package names, and/or drop the dependencies.
19:58 <sil2100> Oh, yeah, the easy way, I think I went overboard with that idea
19:58 <DalekSec> xnox: Sorry I didn't get the pint (I'm Unit193)
19:58 <xnox> sil2100: e.g. maas-enlist-udeb needs to be rebuild to start depending on e.g. libcurl3-udeb.
19:58 <xnox> sil2100: my expectation from a core developer, to know about at least one thing at a proficient level: sbuild logs, components mismatches, NBS.
19:59 <xnox> sil2100: none of those things are typically encountered by universe / motu, developers as these things are either exclusive or have higher priority in main.
20:00 <sil2100> Maybe I could gain some points by my experience with dealin with -proposed migration update_excuses and update_output ;p?
20:00 <sil2100> *dealing
20:00 <xnox> sil2100: i would expect you to work on resolving NBS, filing/follwing up on MIR reports, and/or resolving components-missmatches by e.g. moving optional build-dependencies for test-suites only into adt tests.
20:01 <sil2100> I never resolved NBS as is, but I did similar work during the few transitions I was doing, as there were always a lot of rdeps to rebuild and change dependencies
20:02 <xnox> sil2100: yes, ultimately. things like nbs/components-missmatches end up entangling and keeping packages stuck in proposed migration.
20:02 <xnox> sil2100: and fixing proposed migration, especially during current gcc5 transition was what most core devs have been working on past few weeks.
20:03 <xnox> sil2100: i really think you should do get experience with those tools and reports, before i would vote +1 on your application.
20:03 <sil2100> Ok, I understand...
20:04 <xnox> do other people have more questions, or can we vote on the application?
20:05 <sil2100> I know it's bad I'm rather concentrated on touch packages
20:05 <xnox> !dmb-ping
20:05 <ubottu> cyphermox, infinity, Laney, micahg, xnox, bdmurray, stgraber: DMB ping
20:05 <xnox> are we ready to vote?
20:06 <sil2100> I did try to help out with some transitions for experience though, and also I got some experience with resolving packages being blocked in -proposed
20:08 * bdmurray is still here
20:08 <xnox> sil2100: do more of that. keep notes, get those uploads sponsored and keep a list. If you can demostrate that to us, for example i would be in favor voting +1 on your application very soon (e.g. within 1-3 months, as you have enough things to demonstrate)
20:09 <xnox> sil2100: i am confident in the rest of your skills and general programming. it's the coredev specific things, that i see you as lacking deep experience in.
20:09 <sil2100> Ok :)
20:09 <sil2100> Thanks
20:11 <xnox> but today will be a -1 from me.
20:14 <xnox> #vote sil2100 for Core Dev application
20:14 <meetingology> Please vote on: sil2100 for Core Dev application
20:14 <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
20:14 <xnox> !dmb-ping
20:14 <xnox> -1
20:14 <meetingology> -1 received from xnox
20:16 <micahg_work> +0
20:16 <meetingology> +0 received from micahg_work
20:16 <bdmurray> +0
20:16 <meetingology> +0 received from bdmurray
20:16 <cyphermox> sorry
20:16 <cyphermox> +0
20:16 <meetingology> +0 received from cyphermox
20:16 <bdmurray> I'd like to echo what xnox said though.
20:16 <micahg_work> me too
20:17 <sil2100> Ok... thanks
20:18 <xnox> #endvote
20:18 <meetingology> Voting ended on: sil2100 for Core Dev application
20:18 <meetingology> Votes for:0 Votes against:1 Abstentions:3
20:18 <meetingology> Motion denied
20:18 <xnox> sil2100: please follow advice above, and we hope to see you reapply soon!
20:19 <xnox> #action xnox to update wiki with good examples of core-dev work, on the above guidance to sil2100
20:19 * meetingology xnox to update wiki with good examples of core-dev work, on the above guidance to sil2100
20:19 <sil2100> Will do
20:20 <xnox> since inception of core-dev a lot of things have changed, and it's good to have that documented.
20:20 <xnox> #topic AOB
20:22 <cyphermox> micahg_work: did N o s k c a j get his feedback after all?
20:23 <micahg_work> no :(
20:23 <micahg_work> but I did chat with him a little and let him know that we haven't forgotten
20:24 <cyphermox> ok
20:24 <xnox> #endmeeting