[04:13] <Unit193> pitti: Howdy.
[04:18] <pitti> bdmurray, slangasek: FYI, I did an RTM grep for lsb_release/lsb-release/os-release usage in http://people.canonical.com/~pitti/tmp/rtm-archive-grep-lsb_release/
[04:19] <pitti> Good morning
[07:50] <zyga> pitti: congratulations on cludified adt, this is a major achievement!
[07:51] <pitti> zyga: thanks! it's very rewarding to finally see it working :)
[07:52] <zyga> pitti: do you have nova at home or were you using a public provider?
[07:53] <pitti> zyga: I tested on Canonical Bootstack
[07:54] <zyga> bootstack?
[07:54] <zyga> how many *stacks do we have/
[07:59] <pitti> zyga: too many :)
[08:00] <pitti> zyga: I've heard of {Canoni,Prod,Boot,Dev}Stack, there's probably more
[08:00] <pitti> zyga: a few months ago I've tested it on HP cloud, but I don't have credentials any more
[08:03] <StevenK> pitti: ScalingStack
[08:06] <pitti> StevenK: ah, of course
[08:30] <LocutusOfBorg1> sil2100, lucene++ accepted in debian/unstable
[09:34] <cjwatson> pitti: speaking of adt, do you have an idea how long it takes for ci.debian.net to pick up new Testsuite: autopkgtest packages?
[09:35] <cjwatson> pitti: I'm itching to see openssh results there to make sure they match my local ones :)
[09:35] <pitti> cjwatson: it's supposed to do a full run every day, but I often found there's a two day delay until it catches up with new versions or packagess
[09:35] <cjwatson> righto
[09:36] <pitti> cjwatson: ci.d.n uses the schroot runner, so if it works for you locally the chance is quite high that it'll work there
[09:37] <pitti> cjwatson: that's not yet in Ubuntu, right? https://jenkins.qa.ubuntu.com/job/utopic-adt-openssh
[09:37] <cjwatson> right, about to file an FFe for it
[09:39] <cjwatson> pitti: oh, I have "Restrictions: isolation-container" - is it possible that ci.d.n will just skip it then?
[09:39] <pitti> cjwatson: yes, it will
[09:39] <cjwatson> bah, right
[09:40] <pitti> cjwatson: I hope for ci.d.n we can move to a cloud-based runner, now that that stuff works; after all, ci.d.n is already running on EC2
[09:40] <cjwatson> let me know if you think that's wrong?  the regression tests have to start sshd on a high port
[09:40] <cjwatson> which by my reading is isolation-container
[09:40] <pitti> I'll talk to Antonio soon, I'd like to test this on EC2 and adjust the setup script if necessary
[09:40] <pitti> cjwatson: why wouldn't that work in a schroot?
[09:41] <cjwatson> pitti: well, README.package-tests says "isolation-container: The test wants to start services or open network TCP ports"
[09:41] <pitti> cjwatson: as a rule of thumb, I found that pretty much every test which isn't "needs-root" can be made to work in schroot
[09:41] <cjwatson> it's also needs-root :-)
[09:41] <cjwatson> that was unclear actually, strictly, it just needs unpassworded sudo
[09:42] <pitti> cjwatson: so if it wants to open port 22, that will obviously not work in schroot as the openssh package already claims that (and the host itself, too)
[09:42] <cjwatson> right, it's not trying to use port 22 indeed
[09:42] <pitti> cjwatson: ah, I wrote that as most developers and schroots have a policy-rc.d
[09:42] <pitti> ci.d.n's doesn't, so services from postinst actually do start up
[09:42] <cjwatson> so does isolation-container really just mean wants to start services on their default ports?
[09:43] <pitti> (that's not very robust of course, but meh, it seems Antonio manages to keep it running :) )
[09:43] <pitti> cjwatson: at least in a container that's guaranteed to work, while in schroot it's between "depends on the config", and "may work or not depending on what's running on the host"
[09:44] <cjwatson> yeah it'll break if somebody's opened port 4242 for something else
[09:44] <pitti> cjwatson: but anyway, I've long lobbied for moving away from schroot in ci.d.n production; I'll talk to Antonio soon, we now have several better alternatives
[09:44] <cjwatson> but, well, I guess I can try
[09:45] <pitti> I wrote a debci LXC backend not too long ago, unfortunately Debian's LXC packages kind of suck
[09:45] <pitti> I guess that's why it's not being used widely yet
[10:24] <sunweaver>  as the maintainer of MATE in Debian, I would love to support  flexiondotorg with pushing MATE into Ubuntu and make UMR happen.
[10:24] <sunweaver> hi!
[10:24] <sunweaver> so my question is: what does it need for a DD to become a Ubuntu developer (i.e. gain upload rights to the archive / universe area of the archive)?
[10:28] <mlankhorst> see ubuntu motu documentation :P
[10:29] <doko> Sweetshark, seb128: thanks for the libixion upload, however it is still incomplete: https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859
[10:29] <mlankhorst> https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[10:35] <seb128> Sweetshark, ^ what doko wrote on that bug
[11:11] <Riddell> anyone know why this ubiquity test fails? (caused by casper upload) https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubiquity/lastBuild/ARCH=amd64,label=adt/
[11:11] <Riddell> it says "adt-run [10:04:29]: ERROR: unexpected error: test dependencies are unsatisfiable"
[11:11] <Riddell> but I don't know how to see what is unsatisfiable
[11:14] <cjwatson> it would be very helpful if autopkgtest were more verbose about that ...
[11:14] <cjwatson> pitti: ^- can you help?
[11:16] <Riddell> cjwatson, pitti: ubiquity test depends on universe packages oem-config-kde oem-config-remaster, might that be the issue?
[11:17] <cjwatson> not in itself
[11:47] <pitti> looking
[11:47] <pitti> cjwatson, Riddell: well, there's the whole apt problem solver debugging output there, it's just quite hard to read
[11:48] <pitti> some libwebkitgtk arch desync, or some binNEWing going on or so?
[11:49] <pitti> if there's some better way to tell apt "please tell me what's wrong so that a human can understand" I'm all ears
[11:50] <pitti> ah, https://launchpad.net/ubuntu/+source/webkitgtk/2.4.6-1ubuntu1/+build/6449387 just finished 30 mins ago, while amd64 finished muhc earlier
[11:50] <cjwatson> oh maybe the problem is that the apt problem resolver output is way up there compared to the final error from autopkgtest
[11:50] <pitti> I bet it was just hte usual temporary uninstallability from mismatching arch:all
[11:50] <cjwatson> not obvious to go and look for it
[11:51] <pitti> yeah, I know; it's all just a single apt-get install call, not sure if the ordering can be influenced
[11:51] <pitti> I'll give it another 20 mins or so for publishing and then retry
[12:22] <pitti> mvo: hm, so the unattended-upgrades test regression that holds back the new apt is quite persistant, I'm afraid (https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/38/ARCH=amd64,label=adt/console)
[12:22] <pitti> it always works on i386 and always fails on amd64
[12:23] <pitti> that smells like i386 and amd64 being out of sync in building or binNEWing, but I don't see anything relevant in https://launchpad.net/ubuntu/utopic/+queue?queue_state=0
[12:23] <pitti> and apparently it's not due to the new webkit-gtk
[12:23] <pitti> that caused uninstallability with ubiquity, but that's fixed now
[12:23] <pitti> cjwatson, Riddell ^ FTR
[12:27] <pitti> cjwatson, bdmurray: I'm looking into bug 1365079
[12:27] <pitti> cjwatson: for mapping an exe path to a click, would this be suitable:
[12:27] <pitti> - parse all root= from /etc/click/databases/*.conf
[12:27] <pitti> - check if the exe path starts with any of those root dirs
[12:28] <pitti> - if not → discard, not packaged
[12:28] <cjwatson> pitti: click pkgdir PATH
[12:28] <cjwatson> pitti: or in fact probably click info PATH
[12:28] <pitti> cjwatson: oh splendid -- much easier, thanks!
[12:29] <pitti> cjwatson: right, click info $exepath, and taking nae and version from it is what I'm after
[12:29] <cjwatson> pitti: you'll either get non-zero exit (and exception junk on stderr) or zero exit + json output
[12:29] <pitti> ack, so in fact implementing this is quite simple, the test case will be much more work :)
[12:29] <cjwatson> heh
[12:30] <cjwatson> in fact this interface is mentioned in the bug description ;-)
[12:31] <pitti> cjwatson: ah indeed; reading helps *brown paperbag*  TGIF!
[12:38] <Riddell> pitti: is there a handy retry button somewhere?
[12:38] <pitti> Riddell: yes, on http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/ ; but for that you need the company VPN :/
[12:38] <pitti> (we're working hard on gutting Jenkins and the entire current setup, though)
[12:39] <pitti> Riddell: so I guess the button for now is "pitti, jibel: please retry <src> tests"
[12:39] <pitti> Riddell: but I'm watching all failures anyway and retry ones like ubiquity
[12:40] <Riddell> lovely
[12:42] <mvo> pitti: hm, thanks! I have a look (once this image build is finished that I'm currently testing)
[12:55] <linoge> Hi there, I want to customize ubiquity in order to install another debian based distro (Canaima GNU/Linux) from it. Is that possible?
[13:14] <ejat> anyone can help with this http://paste.ubuntu.com/8532798/
[13:26] <shadeslayer> mhall119: whom do I bug about the email that you get when you submit a CDA :P
[13:26] <shadeslayer> . If your application is approved, we contact you.
[13:26] <shadeslayer> grammatically incorrect ^^
[13:28] <cjwatson> well, inelegant anyway ...
[13:33] <flexiondotorg> I have a merge I want to propose a merge for lp:ubuntu/indicator-application-gtk2
[13:33] <flexiondotorg> But LP says "This branch is not mergeable into lp:ubuntu/indicator-application-gtk2." when I try and submit the proposal.
[13:34] <flexiondotorg> How should I go about submitting my merge? Raise a bug and attach a patch?
[14:06] <seb128> hum
[14:07] <seb128> cjwatson, that cinnamon-menus, "Install typelib files in multiarch libdir" ... I though we didn't start that transition for utopic?
[14:07] <cjwatson> oh hmm
[14:07] <seb128> our gir doesn't support multiarch afaik
[14:07] <cjwatson> sorry I assumed that was so obviously excellent we must have done
[14:08] <seb128> well, it was late and still had issue
[14:08] <cjwatson> it seems to ftbfs so I guess we can just leave it
[14:08] <seb128> k
[14:08] <cjwatson> however it'll be an issue for the pile of mate syncs in the queue, probably
[14:08] <cjwatson> *sponsoring queue
[14:08] <seb128> let me have a look to those
[14:09] <cjwatson> I already synced mate-panel so I'll keep an eye on it and see if it needs to be fixed up.  there were other problems
[14:09] <seb128> k
[14:09] <cjwatson> the gir change will make some cross-building/cross-installing changes a lot easier once it does land
[14:10] <seb128> indeed
[14:10] <seb128> mvo wanted it this cycle
[14:11] <seb128> but it was late and still having a bunch of issue in Debian, I think Laney decided it was too much work/too late and preferred to delay to next cycle
[14:11] <cjwatson> ok, reverting that bit of the mate-panel sync for now
[14:12] <cjwatson> keeping the new upstream though
[14:12] <cjwatson> thanks for keeping an eye on that
[14:13] <seb128> yw!
[14:31] <mhall119> shadeslayer: CDA?
[14:34] <Riddell> tseliot: ping?
[14:35] <shadeslayer> mhall119: Community Donation Application
[14:35] <mhall119> ah, that would be msm I think
[14:38] <Riddell> tseliot: can we have sddm added to nvidia-prime's alternative depends?
[14:40] <shadeslayer> mhall119: ack :)
[14:40] <Sweetshark> bye Sweet5hark.
[14:41] <Riddell> tseliot: I just uploaded it to utopic
[14:50] <tseliot> Riddell: ok but I don't think it will actually support Nvidia optimus systems
[14:51] <Riddell> tseliot: why not?
[14:52] <tseliot> Riddell: does it allow to run scripts when X is stopped or launched?
[14:54] <Riddell> tseliot: it runs scripts in Xsession.d if that's what you mean?
[14:56] <tseliot> Riddell: no, I mean exactly what I said. This is the equivalent config file for lightdm: http://paste.ubuntu.com/8533397/
[14:56] <tseliot> Riddell: display-setup-script and display-stopped-script are the relevant fields
[14:57] <Riddell> tseliot: hmm are you able to join #kubuntu-devel to discuss?
[14:57] <tseliot> Riddell: sure but I have a conference call in 3 minutes
[15:44] <Riddell> mvo_: app-install-data due to be updated before RC?
[16:05] <seb128> is there a standard dh/rules variable for "srcdir"?
[16:09] <rbasak> seb128: make's $(CURDIR)?
[16:09] <rbasak> Or else, I'm not sure I understand the question.
[16:09] <seb128> rbasak, if building out of the srcdir, is CURDIR pointing to the source dir or the build dir?
[16:10] <seb128> that rules has
[16:10] <seb128> 	dh $@ --with click,translations --fail-missing -- -B build
[16:10] <seb128> e.G "-B build"
[16:10] <seb128> and I want to copy something from build/... back to the srcdir
[16:13] <rbasak> seb128: I think CURDIR points to the top level. So $(CURDIR)/debian/rules should find the right file, for example.
[16:13] <rbasak> I don't know about click, though.
[16:13] <seb128> rbasak, thanks
[16:13] <seb128> that's a deb
[16:13] <rbasak> (I'm not entirely sure)
[16:14] <rbasak> Though the cwd (pwd output) should also be the same as $(CURDIR), unless you've changed it.
[16:14] <rbasak> So just in debian/rules, "cp build/foo ./" should also work.
[16:16] <seb128> rbasak, no, I've having an override on a dh_ helper, and it's running from the "build" directory (the one specified with -B)
[16:17] <rbasak> seb128: -B to what command?
[16:17] <seb128>   dh $@ --with click,translations --fail-missing -- -B build
[16:17] <seb128> dh -- -B build
[16:17] <seb128> to dh
[16:17] <seb128> that makes dh_ subcommand be run from build/
[16:18] <rbasak> Ah, I'm not familiar with that.
[16:18] <rbasak> Though if debhelper is changing it in response to that call, you might still have $(CURDIR) set. I'm not sure if make exports that or not.
[16:18] <seb128> I'm going to try
[16:19] <seb128> but using ../<dir> works
[16:19] <seb128> and turns out in fact I don't even need to copy that file after all, the binarymangler is smart enough to handle the pot being in build/
[16:19] <seb128> but I wanted to know the answer for next time anyway ;-)
[16:19] <rbasak> :)
[16:19] <seb128> rbasak, thanks for the help!
[16:19] <rbasak> np
[16:50] <goodwill> ppetraki: ping
[17:22] <ppetraki> goodwill, pong
[17:28] <LocutusOfBorg1> sil2100, for your information, is it ok if I upload on debian a new lucene++ with this fix?
[17:28] <LocutusOfBorg1> https://github.com/luceneplusplus/LucenePlusPlus/pull/76/files
[17:28] <LocutusOfBorg1> it should fix hurd and kfreebsd build failures
[17:35] <slangasek> smoser: so did geser's pointer to bug #994931 help?  and does it suggest any workarounds (e.g., setting the desired use_tempaddr value before bringing up the interface?)
[17:35] <slangasek> smoser: fwiw I'm not able to reproduce this problem on a utopic kernel by changing the value of use_tempaddr on my running interface
[17:46] <smoser> slangasek, well, no . it dos not suggest work arounds.
[17:47] <smoser> slangasek, you are changing use_tempaddr.all ?
[17:49] <goodwill> ppetraki: is there any sense of multipathing netboot will be addressed in 12.04? https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004243
[17:50] <ppetraki> goodwill, nice comment ;)
[17:52] <adam_g> !regression-alert
[17:52] <adam_g> bug #1379201 breaks openvswitch dkms update on precise
[17:54] <ppetraki> goodwill, unless someone picks it up, I don't think so. you might be able to convince hallyn to take a look
[17:54] <ppetraki> goodwill, come to think of it, you don't really need to be on a mp system to debug this, just a vm with the right switches. It looks like the udeb is built wrong.
[17:55] <adam_g> hallyn, jamespage ^ zul assigned it to himself but i dont know the status.
[17:55] <zul> adam_g:  will look at it
[18:08] <SpamapS> cjwatson: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1378658 .. seen this bug? It was just recently reported by one of our developers. It sounds like something you might understand. :)
[18:22] <ScottK> zul: Are you taking care of 1379201?
[18:23] <zul> ScottK:  yes im working on it
[18:23] <ScottK> OK.  Thanks.
[19:04] <smoser> bug 1379201
[19:05] <smoser> slangasek, it does indeed appear that utopic does the right thing.
[19:06] <smoser> so i expect that both bugs then are fix-released in utopic
[19:09] <slangasek> smoser: aha - so it does come down to the kernel bug with use_tempaddr?
[19:10] <slangasek> smoser: and does pushing the same value to use_tempaddr have any effect?  i.e., if we had it pre-set before ifupdown ran, would that work around it?
[19:12] <geser> I did some tests with my trusty vm yesterday and used sysctl to change the value and "ip addr show" to show the ipv6 address
[19:12] <geser> changing the value flushed the address but re-running the same command didn't
[19:13] <slangasek> right, cool
[19:14] <ari-tczew> hello
[19:14] <geser> you can "play" with this during runtime, just assign an ipv6 address and the change the use_tempaddr to see your address gone
[19:16] <ari-tczew> There is a one sync request with following change:  debian/gir1.2-mate-menu.install: + Install typelib file into the multiarch libdir. (Closes: #763243). Would it seem to need a FFe request?
[19:16] <smoser> geser, yeah.. .but i dont know why my 'pre-up' command then didn't fix it.
[19:16] <smoser> oh. i do know why now.
[19:17] <smoser> funny. because yesterday i didn't realize that cloud-images have
[19:17] <smoser>  /etc/sysctl.d/99-cloudimg-ipv6.conf
[19:17] <smoser> which sets those 2 values to '2'.
[19:18] <smoser> err.. that sets it to zero.
[19:18] <smoser> hm..
[19:18] <geser> '2' == 0?
[19:18] <smoser> so yeah, the 'pre-up' would have set the values to '2' if that file existed.  then, they'd get reset to '2' and then to '0'.
[19:19] <smoser> so in a cloud image right now, we first set them to 2 (enabled) and then milliseconds later set them to 0.
[19:19] <smoser> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756
[19:20] <slangasek> hee
[19:20] <geser> so your pre-up sets it to 2, ip sets the address and then procps (started by upstart) processes the other sysctl files and sets it back to 0, flushing your ipv6 address?
[19:21] <smoser> well, the pre-up was setting to 2. the ip set the address. then procps setting to '2' again per 10-ipv6-privacy.conf. then setting to '0' per 99-cloudimg-ipv6.conf.
[19:22] <smoser> and its the 2 -> 0 change in that case that was killing the addresses.
[19:22] <smoser> i just verified on utopic you can flip values back and forth to your whim and not destroy addresses.
[19:23] <smoser> so as such, i'm going to mark bug 994931 as 'fix-released'
[19:23] <smoser> in utopic.
[19:29] <smoser> slangasek, or geser you know why procps-instance.conf is
[19:29] <smoser> start on virtual-filesystems or static-network-up
[19:29] <smoser> why the "or static-network-up". it would seem that on a normal boot that is going to run more than once.
[19:31] <slangasek> smoser: yes, we run it more than once because it's not possible to apply the sysctl settings to network devices before those devices are available
[19:31] <smoser> oh. because some of the settings have some.value.$IFNAME.value
[19:31] <smoser> ?
[19:31] <slangasek> so we run it once as early as possible to apply the settings that we can, then run it a second time after the network is up
[19:31] <slangasek> yep
[19:32] <slangasek> ideally there would be a way to apply these settings in-line with each interface bring-up
[19:32] <slangasek> but /etc/sysctl.conf doesn't lend itself to this
[19:32] <slangasek> not sure if systemd has tried to solve this problem
[19:33] <smoser> well, sed -n "/.$INTERFACE./p" /etc/sysctl.d/* | sysctl -p -f -
[19:34] <slangasek> yeah, horrible layering violation ;)
[19:48] <goodwill> ppetraki: well its a magical land :)
[19:54] <goodwill> ppetraki: so should I ping hallyn ?
[19:54] <goodwill> ppetraki: I am trying to debug it and get to the cause ... but its twisted one
[20:03] <ppetraki> goodwill, yeah, he's good
[20:03] <ppetraki> goodwill, so a quick search is showing no udeb for multipath
[20:04] <goodwill> ppetraki: where are you searching?
[20:04] <goodwill> hallyn: ping
[20:06] <dx> hey #ubuntu-devel! do packages in universe have to go through the same SRU process as packages in main?
[20:12] <geser> dx: yes
[20:17] <cjwatson> SpamapS: don't have a lot of time just now, sorry.  is it reproducible in qemu?
[20:31] <slangasek> ev, bdmurray: is https://errors.ubuntu.com/problem/d7b8b576c9b773cd5d822e833534e98fba85e30d == bug #1345569 ?
[21:27] <ahoneybun> mhall119, still need track leads?
[21:32] <mhall119> I haven't started recruiting them yet, but yes
[21:46] <ahoneybun> oh ok just let me know
[21:46] <bdmurray> slangasek: yeah, that looks the same to me
[21:50] <bdmurray> slangasek: this is the error associated with the bug - https://errors.ubuntu.com/bucket/?id=/usr/share/apport/recoverable_problem%3AValueError%3Aadd_proc_info%3A/usr/share/apport/recoverable_problem%4070%3Amain%3Aadd_proc_info
[23:09] <slangasek> bdmurray: so should we reopen bug #1345569, given that this crash is being reported against apport 2.14.7-0ubuntu5?
[23:13] <slangasek> bdmurray: (presuming yes and reopening with comment)
[23:35] <xnox> slangasek: right, i think sudo's pam config is incorrect. I'll submit patch to security for review, but it's too late for utopic, will wait for Tasty Topi
[23:35] <slangasek> those are the wrong letters
[23:35] <slangasek> you mean Very Tasty Velociraptor
[23:39] <xnox> oh yeah.
[23:39] <xnox> we should pull an android and drop the code name and just call it: V for Vendetta
[23:41] <xnox> slangasek: please remove btrfs-tools from utopic-proposed.
[23:42] <xnox> FFe bug didn't get approved and it's stuck in NEW, and I'd rather make a new point release upload and make it hit the queue properly
[23:42] <xnox> stuck in proposed that is, blocked by tag.
[23:43] <xnox> or i guess it doesn't matter if i have a proper on in the unapproved queue.
[23:43] <slangasek> xnox: ok.  I guess you don't think it would be preferred to approve the FFe at this point?
[23:44] <slangasek> fwiw that FFe bug is a bit sparse on justification
[23:44] <xnox> slangasek: oh, i'd love for the FFe approved, it's just i'll have 3.16.2 to upload now. So i'd want FFe approval against 3.16.2.
[23:44] <xnox> slangasek: justification is that it slipped my radar whilst employed, and ideally btrfs bug-fixes should match the kernel release =))
[23:49] <slangasek> xnox: right, ideally they would, but ideally this would be figured out before freeze
[23:49] <slangasek> xnox: and I don't think that ideal is sufficient justification for an FFe
[23:51] <slangasek> xnox: so if that's all you've got then yes, I'll remove it from -proposed ;)