[04:13] pitti: Howdy. [04:18] 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] Good morning === doko_ is now known as doko === dpm_ is now known as dpm [07:50] pitti: congratulations on cludified adt, this is a major achievement! [07:51] zyga: thanks! it's very rewarding to finally see it working :) [07:52] pitti: do you have nova at home or were you using a public provider? [07:53] zyga: I tested on Canonical Bootstack [07:54] bootstack? [07:54] how many *stacks do we have/ [07:59] zyga: too many :) [08:00] zyga: I've heard of {Canoni,Prod,Boot,Dev}Stack, there's probably more [08:00] zyga: a few months ago I've tested it on HP cloud, but I don't have credentials any more [08:03] pitti: ScalingStack [08:06] StevenK: ah, of course [08:30] sil2100, lucene++ accepted in debian/unstable [09:34] pitti: speaking of adt, do you have an idea how long it takes for ci.debian.net to pick up new Testsuite: autopkgtest packages? === vrruiz_ is now known as rvr [09:35] pitti: I'm itching to see openssh results there to make sure they match my local ones :) [09:35] 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] righto [09:36] 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] cjwatson: that's not yet in Ubuntu, right? https://jenkins.qa.ubuntu.com/job/utopic-adt-openssh [09:37] right, about to file an FFe for it [09:39] pitti: oh, I have "Restrictions: isolation-container" - is it possible that ci.d.n will just skip it then? [09:39] cjwatson: yes, it will [09:39] bah, right [09:40] 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] let me know if you think that's wrong? the regression tests have to start sshd on a high port [09:40] which by my reading is isolation-container [09:40] I'll talk to Antonio soon, I'd like to test this on EC2 and adjust the setup script if necessary [09:40] cjwatson: why wouldn't that work in a schroot? [09:41] pitti: well, README.package-tests says "isolation-container: The test wants to start services or open network TCP ports" [09:41] 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] it's also needs-root :-) [09:41] that was unclear actually, strictly, it just needs unpassworded sudo [09:42] 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] right, it's not trying to use port 22 indeed [09:42] cjwatson: ah, I wrote that as most developers and schroots have a policy-rc.d [09:42] ci.d.n's doesn't, so services from postinst actually do start up [09:42] so does isolation-container really just mean wants to start services on their default ports? [09:43] (that's not very robust of course, but meh, it seems Antonio manages to keep it running :) ) [09:43] 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] yeah it'll break if somebody's opened port 4242 for something else [09:44] 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] but, well, I guess I can try [09:45] I wrote a debci LXC backend not too long ago, unfortunately Debian's LXC packages kind of suck [09:45] I guess that's why it's not being used widely yet === MacSlow is now known as MacSlow|hanout [10:24] as the maintainer of MATE in Debian, I would love to support flexiondotorg with pushing MATE into Ubuntu and make UMR happen. [10:24] hi! [10:24] 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] see ubuntu motu documentation :P [10:29] Sweetshark, seb128: thanks for the libixion upload, however it is still incomplete: https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 [10:29] Ubuntu bug 1349859 in liborcus (Ubuntu Utopic) "[MIR] libixion (b-d of liborcus)" [High,Confirmed] [10:29] https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess === MacSlow|hanout is now known as MacSlow [10:35] Sweetshark, ^ what doko wrote on that bug [11:11] 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] it says "adt-run [10:04:29]: ERROR: unexpected error: test dependencies are unsatisfiable" [11:11] but I don't know how to see what is unsatisfiable [11:14] it would be very helpful if autopkgtest were more verbose about that ... === MacSlow is now known as MacSlow|lunch [11:14] pitti: ^- can you help? [11:16] cjwatson, pitti: ubiquity test depends on universe packages oem-config-kde oem-config-remaster, might that be the issue? [11:17] not in itself [11:47] looking [11:47] cjwatson, Riddell: well, there's the whole apt problem solver debugging output there, it's just quite hard to read [11:48] some libwebkitgtk arch desync, or some binNEWing going on or so? [11:49] 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] 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] oh maybe the problem is that the apt problem resolver output is way up there compared to the final error from autopkgtest [11:50] I bet it was just hte usual temporary uninstallability from mismatching arch:all [11:50] not obvious to go and look for it [11:51] yeah, I know; it's all just a single apt-get install call, not sure if the ordering can be influenced [11:51] I'll give it another 20 mins or so for publishing and then retry [12:22] 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] it always works on i386 and always fails on amd64 [12:23] 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] and apparently it's not due to the new webkit-gtk [12:23] that caused uninstallability with ubiquity, but that's fixed now [12:23] cjwatson, Riddell ^ FTR [12:27] cjwatson, bdmurray: I'm looking into bug 1365079 [12:27] bug 1365079 in apport (Ubuntu) "apport should gather package information about click packages" [Medium,Triaged] https://launchpad.net/bugs/1365079 [12:27] cjwatson: for mapping an exe path to a click, would this be suitable: [12:27] - parse all root= from /etc/click/databases/*.conf [12:27] - check if the exe path starts with any of those root dirs [12:28] - if not → discard, not packaged [12:28] pitti: click pkgdir PATH [12:28] pitti: or in fact probably click info PATH [12:28] cjwatson: oh splendid -- much easier, thanks! [12:29] cjwatson: right, click info $exepath, and taking nae and version from it is what I'm after === MacSlow|lunch is now known as MacSlow [12:29] pitti: you'll either get non-zero exit (and exception junk on stderr) or zero exit + json output [12:29] ack, so in fact implementing this is quite simple, the test case will be much more work :) [12:29] heh [12:30] in fact this interface is mentioned in the bug description ;-) [12:31] cjwatson: ah indeed; reading helps *brown paperbag* TGIF! [12:38] pitti: is there a handy retry button somewhere? [12:38] Riddell: yes, on http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/ ; but for that you need the company VPN :/ [12:38] (we're working hard on gutting Jenkins and the entire current setup, though) [12:39] Riddell: so I guess the button for now is "pitti, jibel: please retry tests" [12:39] Riddell: but I'm watching all failures anyway and retry ones like ubiquity [12:40] lovely [12:42] pitti: hm, thanks! I have a look (once this image build is finished that I'm currently testing) [12:55] 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] anyone can help with this http://paste.ubuntu.com/8532798/ [13:26] mhall119: whom do I bug about the email that you get when you submit a CDA :P [13:26] . If your application is approved, we contact you. [13:26] grammatically incorrect ^^ === nik90 is now known as nik90|Lunch [13:28] well, inelegant anyway ... [13:33] I have a merge I want to propose a merge for lp:ubuntu/indicator-application-gtk2 [13:33] But LP says "This branch is not mergeable into lp:ubuntu/indicator-application-gtk2." when I try and submit the proposal. [13:34] How should I go about submitting my merge? Raise a bug and attach a patch? === mpt_ is now known as mpt [14:06] hum [14:07] cjwatson, that cinnamon-menus, "Install typelib files in multiarch libdir" ... I though we didn't start that transition for utopic? [14:07] oh hmm [14:07] our gir doesn't support multiarch afaik [14:07] sorry I assumed that was so obviously excellent we must have done [14:08] well, it was late and still had issue [14:08] it seems to ftbfs so I guess we can just leave it [14:08] k [14:08] however it'll be an issue for the pile of mate syncs in the queue, probably [14:08] *sponsoring queue [14:08] let me have a look to those [14:09] 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] k [14:09] the gir change will make some cross-building/cross-installing changes a lot easier once it does land [14:10] indeed [14:10] mvo wanted it this cycle [14:11] 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] ok, reverting that bit of the mate-panel sync for now [14:12] keeping the new upstream though [14:12] thanks for keeping an eye on that [14:13] yw! [14:31] shadeslayer: CDA? [14:34] tseliot: ping? [14:35] mhall119: Community Donation Application [14:35] ah, that would be msm I think [14:38] tseliot: can we have sddm added to nvidia-prime's alternative depends? [14:40] mhall119: ack :) [14:40] bye Sweet5hark. [14:41] tseliot: I just uploaded it to utopic === nik90|Lunch is now known as nik90 [14:50] Riddell: ok but I don't think it will actually support Nvidia optimus systems [14:51] tseliot: why not? [14:52] Riddell: does it allow to run scripts when X is stopped or launched? [14:54] tseliot: it runs scripts in Xsession.d if that's what you mean? [14:56] Riddell: no, I mean exactly what I said. This is the equivalent config file for lightdm: http://paste.ubuntu.com/8533397/ [14:56] Riddell: display-setup-script and display-stopped-script are the relevant fields [14:57] tseliot: hmm are you able to join #kubuntu-devel to discuss? [14:57] Riddell: sure but I have a conference call in 3 minutes [15:44] mvo_: app-install-data due to be updated before RC? [16:05] is there a standard dh/rules variable for "srcdir"? [16:09] seb128: make's $(CURDIR)? [16:09] Or else, I'm not sure I understand the question. [16:09] rbasak, if building out of the srcdir, is CURDIR pointing to the source dir or the build dir? [16:10] that rules has [16:10] dh $@ --with click,translations --fail-missing -- -B build [16:10] e.G "-B build" [16:10] and I want to copy something from build/... back to the srcdir [16:13] seb128: I think CURDIR points to the top level. So $(CURDIR)/debian/rules should find the right file, for example. [16:13] I don't know about click, though. [16:13] rbasak, thanks [16:13] that's a deb [16:13] (I'm not entirely sure) [16:14] Though the cwd (pwd output) should also be the same as $(CURDIR), unless you've changed it. [16:14] So just in debian/rules, "cp build/foo ./" should also work. [16:16] 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] seb128: -B to what command? [16:17] dh $@ --with click,translations --fail-missing -- -B build [16:17] dh -- -B build [16:17] to dh [16:17] that makes dh_ subcommand be run from build/ [16:18] Ah, I'm not familiar with that. [16:18] 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] I'm going to try [16:19] but using ../ works [16:19] 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] but I wanted to know the answer for next time anyway ;-) [16:19] :) [16:19] rbasak, thanks for the help! [16:19] np [16:50] ppetraki: ping [17:22] goodwill, pong [17:28] sil2100, for your information, is it ok if I upload on debian a new lucene++ with this fix? [17:28] https://github.com/luceneplusplus/LucenePlusPlus/pull/76/files [17:28] it should fix hurd and kfreebsd build failures [17:35] 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] bug 994931 in linux (Ubuntu Utopic) "Altering use_tempaddr drops all IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/994931 [17:35] 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] slangasek, well, no . it dos not suggest work arounds. [17:47] slangasek, you are changing use_tempaddr.all ? [17:49] 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:49] Ubuntu bug 1004243 in debian-installer (Ubuntu) "multipath installs not working" [High,Confirmed] [17:50] goodwill, nice comment ;) [17:52] !regression-alert [17:52] bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [17:52] bug #1379201 breaks openvswitch dkms update on precise [17:52] bug 1379201 in openvswitch (Ubuntu) "openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3: openvswitch kernel module failed to build [error: too many arguments to function ‘ip_select_ident’]" [Undecided,Confirmed] https://launchpad.net/bugs/1379201 [17:54] goodwill, unless someone picks it up, I don't think so. you might be able to convince hallyn to take a look [17:54] 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] hallyn, jamespage ^ zul assigned it to himself but i dont know the status. [17:55] adam_g: will look at it [18:08] 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:08] Ubuntu bug 1378658 in grub2 (Ubuntu) ""no such device" error from grub2 search command" [Undecided,New] [18:22] zul: Are you taking care of 1379201? [18:23] ScottK: yes im working on it [18:23] OK. Thanks. === roadmr is now known as roadmr_afk [19:04] bug 1379201 [19:04] bug 1379201 in openvswitch (Ubuntu) "openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3: openvswitch kernel module failed to build [error: too many arguments to function ‘ip_select_ident’]" [Undecided,Confirmed] https://launchpad.net/bugs/1379201 [19:05] slangasek, it does indeed appear that utopic does the right thing. [19:06] so i expect that both bugs then are fix-released in utopic [19:09] smoser: aha - so it does come down to the kernel bug with use_tempaddr? [19:10] 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] 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] changing the value flushed the address but re-running the same command didn't [19:13] right, cool [19:14] hello [19:14] 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] 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] geser, yeah.. .but i dont know why my 'pre-up' command then didn't fix it. [19:16] oh. i do know why now. [19:17] funny. because yesterday i didn't realize that cloud-images have [19:17] /etc/sysctl.d/99-cloudimg-ipv6.conf [19:17] which sets those 2 values to '2'. [19:18] err.. that sets it to zero. [19:18] hm.. [19:18] '2' == 0? [19:18] 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] so in a cloud image right now, we first set them to 2 (enabled) and then milliseconds later set them to 0. [19:19] https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756 [19:19] Ubuntu bug 1068756 in cloud-init (Ubuntu) "IPv6 Privacy Extensions enabled on Ubuntu Server by default" [Medium,Triaged] [19:20] hee [19:20] 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] 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] and its the 2 -> 0 change in that case that was killing the addresses. [19:22] i just verified on utopic you can flip values back and forth to your whim and not destroy addresses. [19:23] so as such, i'm going to mark bug 994931 as 'fix-released' [19:23] bug 994931 in linux (Ubuntu Utopic) "Altering use_tempaddr drops all IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/994931 [19:23] in utopic. [19:29] slangasek, or geser you know why procps-instance.conf is [19:29] start on virtual-filesystems or static-network-up [19:29] why the "or static-network-up". it would seem that on a normal boot that is going to run more than once. [19:31] 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] oh. because some of the settings have some.value.$IFNAME.value [19:31] ? [19:31] 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] yep [19:32] ideally there would be a way to apply these settings in-line with each interface bring-up [19:32] but /etc/sysctl.conf doesn't lend itself to this [19:32] not sure if systemd has tried to solve this problem [19:33] well, sed -n "/.$INTERFACE./p" /etc/sysctl.d/* | sysctl -p -f - [19:34] yeah, horrible layering violation ;) === roadmr_afk is now known as roadmr [19:48] ppetraki: well its a magical land :) [19:54] ppetraki: so should I ping hallyn ? [19:54] ppetraki: I am trying to debug it and get to the cause ... but its twisted one [20:03] goodwill, yeah, he's good [20:03] goodwill, so a quick search is showing no udeb for multipath [20:04] ppetraki: where are you searching? [20:04] hallyn: ping [20:06] hey #ubuntu-devel! do packages in universe have to go through the same SRU process as packages in main? === JanC_ is now known as JanC === huats is now known as Guest27566 [20:12] dx: yes [20:17] SpamapS: don't have a lot of time just now, sorry. is it reproducible in qemu? [20:31] ev, bdmurray: is https://errors.ubuntu.com/problem/d7b8b576c9b773cd5d822e833534e98fba85e30d == bug #1345569 ? [20:31] bug 1345569 in apport (Ubuntu) "recoverable_problem crashed with ValueError in add_proc_info(): invalid process" [High,Fix released] https://launchpad.net/bugs/1345569 [21:27] mhall119, still need track leads? [21:32] I haven't started recruiting them yet, but yes [21:46] oh ok just let me know [21:46] slangasek: yeah, that looks the same to me [21:50] 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] bdmurray: so should we reopen bug #1345569, given that this crash is being reported against apport 2.14.7-0ubuntu5? [23:09] bug 1345569 in apport (Ubuntu) "recoverable_problem crashed with ValueError in add_proc_info(): invalid process" [High,Fix released] https://launchpad.net/bugs/1345569 [23:13] bdmurray: (presuming yes and reopening with comment) [23:35] 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] those are the wrong letters [23:35] you mean Very Tasty Velociraptor [23:39] oh yeah. [23:39] we should pull an android and drop the code name and just call it: V for Vendetta [23:41] slangasek: please remove btrfs-tools from utopic-proposed. [23:42] 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] stuck in proposed that is, blocked by tag. [23:43] or i guess it doesn't matter if i have a proper on in the unapproved queue. [23:43] xnox: ok. I guess you don't think it would be preferred to approve the FFe at this point? [23:44] fwiw that FFe bug is a bit sparse on justification [23:44] 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] slangasek: justification is that it slipped my radar whilst employed, and ideally btrfs bug-fixes should match the kernel release =)) [23:49] xnox: right, ideally they would, but ideally this would be figured out before freeze [23:49] xnox: and I don't think that ideal is sufficient justification for an FFe [23:51] xnox: so if that's all you've got then yes, I'll remove it from -proposed ;)