=== cpaelzer is now known as cpaelzer_afk === _salem is now known as salem_ === salem_ is now known as _salem [05:40] Good morning [06:07] Laney: oh, one of the armhf nodes still had the regressing lxcfs installed which caused the timeouts with systemctl daemon-reload; downgraded now and retried everything [06:19] good morning [06:22] pitti: do you know what needs to be done for the transition still? [06:23] hey Mirv [06:23] Mirv: we made a lot of progress last night, but I think it now hinges on aptdaemon not working properly with apt 1.1 [06:23] pitti: ah, the apt transition is still there, ok [06:23] Mirv: and the whole Qt transition depends on the apt transition [06:24] I've kindly asked Kubuntu to not upload a new KDE since that could set as back for another week [06:31] right, now I saw the right parts of the backlog === nudtrobert1 is now known as nudtrobert [07:30] xnox: just stumbled over missing "git" on s390; impressive dependency chain :) [07:30] git needs subversion needs ruby, wow [07:31] although ruby-defaults and ruby2.2 ought to be there now [07:33] hm, I can install ruby and ruby-dev on the autopkgtest system, but apparently the buildd can't [08:50] pitti, Mirv we should have been building kde for s390x in the bootstrap archive. [08:51] * pitti fixes apport for apt 1.1 [10:03] doko, i am suddendly seeing build failures (for the kernel) on arm64, i am suspicious that i have a binutils issue: https://launchpadlibrarian.net/229533923/buildlog_ubuntu-xenial-arm64.linux_4.3.0-3.12_BUILDING.txt.gz [10:04] doko, the previous build was identicle souce in arm64 and built just fine === cpaelzer is now known as cpaelzer_afk === _salem is now known as salem_ [11:36] pitti: did mv_o have a chance to look at the aptdaemon failures? [11:36] I haven't heard anything yet; mvo ^ [11:36] mvo: would be nice to know if that's ignorable for now, or serious enough to block propagation [11:41] pitti: I did not had a chance, sorry [11:42] pitti: can you please give me the link again [11:42] mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/aptdaemon/20151209_192259@/log.gz is the log [11:42] mvo: i. e. http://autopkgtest.ubuntu.com/packages/a/aptdaemon/xenial/amd64/ [11:43] pitti: its just the cdrom test, so go ahead and promote and we will figure out the reason once there is a bit of time [11:44] mvo: test_archives_lock (tests.test_lock.LockTest) [11:44] mvo: error code 100 is "apt error", that doesn't seem to be CD-ROM only? [11:44] Err:4 copy:/tmp/adt-run.z6d472/build.z7b/aptdaemon-1.1.1+bzr982/tests/repo ./ Packages [11:44] Hash Sum mismatch [11:44] oh, perhaps just that [11:45] but that seems to happen consistently [11:46] pitti: hm, right. need to look but in a meeting [11:46] mvo: at least it looks likely to be a test-side problem [11:49] pitti: I can reproduce I suspect a test issue because the new apt is stricted and its less easy to fake data [11:50] mvo: right; ok, so are you ok with force-badtest'ing it and let the new apt land? [11:53] yes [11:53] mvo: ack, thanks for the review [11:53] * pitti commits hint [11:55] meh, this is also a regression: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/u/ubuntu-release-upgrader/20151210_062305@/log.gz [11:55] apparently with new python-apt [12:04] any archive admins around? I need a binary only promotion of libboost-random-dev to main to get ceph 9.2.0 building... [12:05] that will pull in libboost-random1.58-dev libboost-random1.58.0 [12:05] jamespage: ah, so these two need to go to main too [12:05] pitti, yup [12:06] jamespage: done [12:06] pitti, thankyou! [12:20] Mirv, xnox: apt and friends are valid candidates now, but still installability errors :( [12:24] hmm [12:31] pitti: do I parse update_output correctly that it'd claim big installability problems on amd64 too? I don't see problems on my xenial lxc if I enable -proposed, it seems I can install pretty much install + upgrade all of Qt / KDE etc [12:34] right, not arch specific [12:34] something in that list is still not built against the new apt [12:34] or this needs to be hinted, not entirely sure [12:41] qtdeclarative is not a candidate [12:41] ah, qtmir-gles tests? [12:42] indeed, FTBFS against new Qt? [12:42] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/q/qtmir-gles/20151210_062159@/log.gz [12:42] Mirv: ^ ? [12:42] oh, but apparently against the whole stack, like in the third on http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/xenial/amd64/ [12:42] so, just insufficient build deps [12:42] pitti: yes, whole stack [12:43] probably have the line from yesterday [12:43] I guess they should be tightened [12:43] ok, hint it is, let's not reupload just to tighten build deps [12:43] meanwhile I'll file a bug for it [12:44] hinted [12:45] pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtdeclarative-opensource-src also shows non-hinted random timeouts with kaccounts-integration [12:46] Should wait for kaccounts-integration 4:15.08.2-0ubuntu1 test, but forced by pitti [12:46] Mirv: already hinted [12:46] * Mirv re-learns to read [12:46] a lot of tech debt when this lands :) [12:46] Mirv: yeah, sorry, it's not immediately under that line, easy to miss [13:08] pitti, syncpackage pbuilder pretty please LP: #1524083 [13:08] Launchpad bug 1524083 in pbuilder (Ubuntu) "Sync pbuilder 0.221.2 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/1524083 [13:08] and if you can lp: #1524315 [13:08] Launchpad bug 1524315 in boinc (Ubuntu) "Sync boinc 7.6.20+dfsg-4 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1524315 === pat_ is now known as Guest15515 [13:26] pitti: still some but a lot less uninstallable? [13:26] (or claimed as such) [13:27] apt seems pretty happy about installing those for me, so far [13:29] I found unbuilt arm64 plasma-workspace, rebuilding https://launchpad.net/ubuntu/+source/plasma-workspace/4:5.4.3-0ubuntu1/+build/8330580 [13:29] I triggered a chain of ~30 KDE packages for arm64 before I landed Qt 5.5 since they had been stuck since beginning of November [13:33] calligra armhf FTBFS related to the poppler transition? xnox? [13:35] xnox: and gdcm not considered [13:38] pitti: related to apt, openscap ICE on ppc64el, rebuilding [13:41] pitti, can I have some help deciphering update-excuses? I'm trying to get the new gsl to land. the update_output.txt file indicates there's something going on with cpl-plugin-naco and slgsl. But I'm not sure what it is [13:42] Granted, the naco plugin is also held in proposed, because autopkg isn't testing with the latest gsl... [13:43] Is that a circular loop? Or did it just test with the old gsl and hasn't been retested yet? [13:56] not sure how much it helps, but I managed to get successful builds for ppc64el: openscap lxqt-panel arm64: user-manager systemsettings plasma-framework (next: plasma-desktop) s390x: libqtxdg [14:01] didrocks, thanks for looking at the s390x MIRs [14:07] mterry: yw! there are still 2 to be done [14:07] maybe doko or you have time for them? [14:08] yeah, I should have time ... [14:08] mterry: also look if they were pre-promoted. Some were without any message on the bug report [14:08] doko: ^ [14:09] didrocks, yeah I saw your comments [14:09] I trust thus xnox to fix things quickly then :) [14:12] LocutusOfBorg1: pbuilder synced; for boinc, the debian changelog does not mention the ubuntu changes at all, so doesn't this need merging? [14:12] pitti: thanks for pbuilder! ♥ [14:13] mapreri: no worries, thanks to you for making the package syncable, that's fantastic! [14:13] Mirv: hm, apt uninstallablity is still the same? [14:13] Mirv: right, the KDE uploads failed on arm64 on several attempts, but why do they block apt? [14:14] pitti: I don't know if they block apt, I'm just flexibly interpreting problems on excuses or update_output page to be possibly related to the migration [14:15] pete-woods: any idea about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-dbusmock/20151210_061403@/log.gz ? I didn't see that in my local test [14:15] the calligra armhf is actually an ICE https://launchpadlibrarian.net/229169305/buildlog_ubuntu-xenial-armhf.calligra_1%3A2.9.7-0ubuntu8_BUILDING.txt.gz so I guess it could be retried. calligra is among else listed in the trying easy from easyhinter portion of update_output. [14:16] meh, and poppler is also part of that transition [14:16] and rather old [14:16] it seems folks have become very sloppy with actually finishing what they start :( [14:19] mterry: so update_excuses says that the new gsl breaks cpl-plugin-naco indeed [14:19] Mirv: so it seems it depends on the new gsl but doesn't declare that [14:19] pitti, I think that's a lie? [14:20] pitti, it's hard because they changed SONAME but not package name [14:20] who's become sloppy? [14:20] poppler got dragged back from almost finished by s390x [14:20] and was entangled into the parallel qt and apt transitions [14:21] pitti, right now gsl being stuck in proposed is making a lot of broken packages (because they build against proposed SONAME, land in release, and expect that same SONAME) [14:21] mterry: no, not a lie, the new gsl is indeed not installable with the old naco [14:21] pitti, right, but the naco in proposed that it does work with is being stuck for bogus reasons (it was tested against release pocket version of gsl) [14:22] so, let's try to test the proposed naco against the proposed gsl [14:22] pitti, exactly [14:22] mterry: yes, as I said -- it doesn't depend on the -proposed gsl, so it doesn't get tested against it [14:22] pitti, right I get that logic. That's why I'm coming to you for manual futzing :) [14:23] mterry: started now; if that succeeds, it should unblock naco and thus gsl [14:23] pitti, Ubuntu got a botched version of the debian transition for gsl [14:23] pitti, awesome thanks [14:23] ah, that's why [14:23] mterry: so we aren't hiding a soname change without package rename with this, but we fix it? [14:24] pitti, that's the idea (2.0 had package name transition, 2.1 bumped soname to match -- but in debian, 2.0 never hit testing / rdeps didn't seem to adjust for it until 2.1) [14:24] pitti, but in Ubuntu, we had a delta for 2.0 [14:25] pitti: I've seen that before when you run the tests individually (e.g. ./tests/foo.py) [14:25] pitti, so we didn't get 2.1 in a timely fashion, but we got all of Debian's rdep changes to require >=2.0 [14:25] I guess there's some magic setup in the main setup.py that registers a mainloop or something [14:26] pitti, (we could fix this in Ubuntu by adding lots of deltas on >=2.1, but I figured it was easier to accept one time pain than that) [14:28] mterry: passed now, that's better [14:29] pitti, yay [14:30] pitti, something seems weird about that migration logic though -- new naco passed its autopkg test with new gsl. But we blocked both new packages because naco didn't pass with old gsl -- why would we care there? (I get why it was tested with old gsl, but seems like we should ignore that specific test result when considering gsl promotion) [14:31] mterry: because neither package can be promoted individually, and since the new naco doesn't dependd on the new gsl it's not attempted to be promoted as a group [14:32] mterry: that "botched transition/missing dependency" is a case for manual promotion/review indeed; not sure if that can be formalized [14:32] pitti, sure. But the migration script has enough information here to know that it ought to treat them as a group. But yeah, maybe this case doesn't come up except in broken cases [14:33] mterry: right, it happens seldomly only; normally dependencies (particular for library transitions) DTRT [14:33] pitti, well thanks for setting this one straight -- this was an annoying transition [14:35] mterry: thanks for grinding through it :) [14:45] in ubuntu this worked, can somebody try a retry? https://launchpad.net/ubuntu/+source/cowdancer/0.75/+build/8254960 [14:45] s/ubuntu/debian/, clearly.... [14:45] pitti: ↑ [14:46] mapreri: kicked [14:46] thx [14:46] ok plasma-desktop is building for arm64 too now [14:46] the launchpad build farm is so scary nowadays, you upload a thing, 2 seconds later is already building [14:47] mapreri: +1 :) [14:47] and there's lots of capacity too (for most arches) [14:48] I recall the times where for a ppa build you had to wait nearly day in the worst case [14:48] a retry of a failed ppa build, that is [14:48] ok, failed again, anyway [14:49] "* '/' is not mounted, something is wrong with the system or the code" — meh [14:50] didrocks, Thanks for updating plymouth for Ubuntu MATE. Much appreciated :-) [14:54] pitti, Mirv: what's up with proposed migration btw? i see stuff as "valid candidate" on excuses for some time now, but still not migrated. is it just incredibly slow atm? [14:54] dobey: no, but it still renders stuff uninstallable [14:55] dobey: that's "phase 2" of p-m, on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [14:55] oh, hmm :-/ [14:55] apt+poppler+three dozen Qt packages, some KDE interspersed, yummy ;/ [14:56] mterry: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cpl-plugin-naco \o/ [14:57] mterry: it's being promoted [14:57] pitti, heh, great [14:58] mterry: hm, but not http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsl itself yet [14:59] pitti, update_output.txt also mentioned slang-gsl (from slgsl) [14:59] pitti, but I wasn't sure why there [14:59] mterry: that's already promoted [14:59] mterry: so maybe that needs another rebuild against the new gsl? [15:00] pitti: yeah, i'm mostly concerned about ubuntuone-credentials at the moment. i guess it's just in an unlucky position, dependency-wise [15:00] pitti, no the promoted version should be built against new one (it snuck in because it didn't have autopkgtests and this was a silent transition) [15:01] oh, and i guess it just made it through. whee :) [15:01] pitti, wait... [15:01] pitti, no.. it's building against some ancient gsl version (looking at build log) [15:01] but this was a couple days ago [15:01] [15:12:23] LocutusOfBorg1: pbuilder synced; for boinc, the debian changelog does not mention the ubuntu changes at all, so doesn't this need merging? [15:01] it does [15:01] http://metadata.ftp-master.debian.org/changelogs/main/b/boinc/unstable_changelog [15:01] https://launchpad.net/ubuntu/+source/qtbase-opensource-src/+publishinghistory ! [15:01] Mirv, Laney, xnox ^ [15:02] just on a older entry :) [15:02] and apt too [15:02] yippie! [15:02] pitti: what changed? [15:02] pitti, how did that happen? [15:03] britney got slippering fingers? ;-) [15:03] * pitti watches two metric tons of packages land in xenial [15:03] finally enough ignored test regressions and the arm64 rebuilds from Mirv [15:03] wasn't s390 blocking things as well? [15:04] seb128: xnox was busy :) [15:04] no [15:04] he's sitting at the table doing "wth" with Laney [15:04] now we just need to get out of the Haskhell and then -proposed should become halfway manageable again [15:04] we thought it was still far off [15:04] seb128: well, I wasn't aware of any remaining blockers, what was left? [15:05] this morning we were at qtmir-gles and some leftover arm64 FTBFS [15:05] FWIW I uploaded ghc-testsuite a few hours ago [15:05] xnox though that s390 had libreoffice depending on poppler triggered kde things [15:05] I'm gradually working my way up the Haskell stack [15:05] seb128, can I ask you a really difficult question? the problem is your keyutils sync. it didn't went to -release, because it didn't build everywhere. Now a package depending on it, is failing to build from source where it is built, and building correctly where it failed (because the older one was picked). Since nothing in the code should have changed, I'm lost, maybe you can consider disabling again the testsuite? [15:05] cjwatson: ah, thanks; is that mostly doing build retries in mostly the right order? [15:06] LocutusOfBorg1, somebody should fix it [15:06] pitti: partly, some manual rebuilds, and there are some bits still broken in Debian [15:07] LocutusOfBorg1, that's not a difficult question [15:07] seb128, I lost half the day without any clue [15:07] pitti: !!! [15:07] but disabling the testsuite again should be the best fix [15:07] do you think you can sponsor it? [15:08] * Mirv hugs pitti xnox Laney mterry + everyone [15:08] * pitti hugs Mirv back [15:08] :) [15:08] seb128, https://launchpadlibrarian.net/187477970/keyutils_1.5.9-5_1.5.9-5ubuntu1.diff.gz something like that [15:08] même pas mal ! [15:09] britney traded uninstallables [15:10] Laney: on s390? [15:10] It'll do that [15:10] sil2100 ^ [15:10] Is it DONE? [15:10] Did it happen?! [15:11] In the sense that unity8 is about to be uninstallable on xenial/armhf, yes :P [15:11] :) [15:11] cross arch trading? [15:11] Yes [15:11] \o/ [15:12] uh, the "Newly uninstallable packages in testing"? [15:12] :-( [15:12] that's a loot [15:12] "fun" [15:12] hey, would someone who can see private bugs mind summarizing #723515? it's mentioned in libhugetlbfs's debian/rules [15:12] I didn't know that britney allowed that kind of trading [15:12] and I'm wondering if that can be dropped [15:13] is it supposed to? [15:13] or is that a bug? [15:13] it's a misfeature [15:13] hmm [15:15] actually, it's *supposed* to check per-arch [15:16] # if the uninstallability counter is worse than before, break the loop [15:16] if ((item.architecture != 'source' and arch not in new_arches) or \ [15:16] (arch not in break_arches)) and len(nuninst[arch]) > len(nuninst_comp[arch]): [15:16] better = False [15:16] break [15:16] maybe easy hints are different [15:17] I think they may be :( [15:18] see is_nuninst_asgood_generous [15:31] so ubuntu-ui-toolkit is stuck due to s390x issues, which makes the phone world not happy yet and which was the interesting trade done [15:33] mdeslaur: playing notify bot, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5 causes a lot of regressions, so it's stuck; what's worse is that they all look different :( [15:34] looks like https://launchpad.net/ubuntu/+source/ubuntu-app-launch/0.5+15.10.20150817-0ubuntu1/+build/8382760, but is that really just "fails when rebuilt with current glib" or similar? [15:35] coreycb: FYI, new python-oslo.log needs a bunch of universe b-deps so it doesn't build: https://launchpad.net/ubuntu/+source/python-oslo.log/2.0.0-1ubuntu1/+build/8370838 [15:36] pitti, those depends should be in main. i've not been able to figure out why they're stuck in proposed though. [15:37] I think u-a-l probably wants something like http://paste.ubuntu.com/13897054/ [15:37] xnox: ubuntu-app-launch ftbfs on s390x due to warning treated as error. that's a pre-requirent for building autopilot which is one of the blockers keeping ubuntu-ui-toolkit in -proposed [15:37] Mirv: ^- [15:37] coreycb: uh, indeed [15:37] cjwatson: right, I read just after pressing enter [15:37] pitti, like this one, it builds ok but stuck in proposed: https://launchpad.net/ubuntu/+source/python-oslo.utils [15:38] coreycb: sorry, they are uninstallable, not in universe [15:38] * cjwatson tries it on amd64 [15:38] coreycb: https://launchpadlibrarian.net/228297733/buildlog_ubuntu-xenial-amd64.python-oslo.log_2.0.0-1ubuntu1_BUILDING.txt.gz [15:40] # apt-get build-dep python-oslo.log [15:40] : Build-Depends-Indep dependency for python-oslo.log cannot be satisfied because candidate version of package python-oslo.serialization can't satisfy version requirements [15:41] coreycb: ah, it has python-oslo.serialization (>= 1.10.0), but only 1.9.0-2 is available [15:42] coreycb: 1.9.02 is in debian unstable, 2.0.0-1 is in experimental [15:42] coreycb: did you merge the others from experimental too? i. e. shoudl the exp version be synced? [15:42] pitti, I think the new oslo.serialization is stuck in proposed. I think the real blocker starts with oslo.utils (see link above) [15:42] pitti, oslo.utils is building ok but stuck in proposed and I don't see any update excuses issues [15:43] coreycb: hm, but builds are done against -proposed [15:43] pitti, odd [15:43] coreycb: I'll just retry again, it seems they all interlock on each other then [15:43] pitti, yes they are, thanks [15:43] ah right, o-serialization is also depwait [15:44] coreycb: btw, please document ubuntu changes in changelogs; "upload to xenial" is empty contents [15:44] (as that's quite clear from the other parts of the changelog already) [15:44] and there have been no previous ubuntu changes [15:45] pitti, ok. yeah that was a weird situation where it could have been a sync but hadn't yet been uploaded to experimental. [15:45] Mirv: yep, same failure on amd64 [15:45] this makes it hard to see what we changed, what bug refs are, etc. [15:45] coreycb: oh, ok; please use ~fakesync or ~build1 or something then [15:45] pitti, ok [15:45] hm, reubild didn't help [15:47] flexiondotorg: yw! :) [15:48] coreycb: so https://launchpad.net/ubuntu/+source/python-oslo.utils/3.0.0-1ubuntu1/+build/8370376 builds python-oslo.utils, but apt-cache policy python-oslo.utils doesn't show it (in -proposed); WTH [15:49] mvo and/or anyone who cares: I'm right that you'd like to have stars in gnome-software when switching to it, right? hughsie thought about removing star ratings, I wrote that I think you still want it [15:49] it's like someone removed the binary [15:50] it's not in the binNEW queue [15:50] pitti, hmm, fwiw I may be hitting the same issues with the cloud archive staging ppa [15:50] Oh, APT 1.1 has passed proposed :) [15:50] https://launchpad.net/ubuntu/xenial/amd64/python-oslo.utils/3.0.0-1ubuntu1 - Status: superseded [15:50] cjwatson: ^ any idea about that? [15:50] cjwatson: is that from binary package removal or so? [15:51] the binaries clearly have been built, are not in binNEW, but are missing from the archive (http://paste.ubuntu.com/13897353/) [15:51] I'll look in a minute, I just Ctrl-q'ed my browser by mistake :P [15:53] cjwatson: uh, I hope you have tab restoration enabled [15:53] sure do [15:53] pitti: I think that was possibly double-override-bug - have copied back in [15:53] cjwatson: cheers [15:55] Mirv,tedg,mterry: any chance we could please get https://code.launchpad.net/~mterry/ubuntu-app-launch/fix-ftbfs/+merge/279322 landed, perhaps in isolation so that we can get past this cluster of problems? [15:56] Oh, sure, I didn't realize it was blocking anything. [15:57] Got a couple meetings and then I can do it after that. [15:58] thanks [15:58] juliank, thanks for the rating comment [15:58] juliank, do they want to replace it with something else? [15:59] seb128: I'm not sure what it was used for, I don't think they had rating data. But he'll keep the widget in now, and rely on plugins to do the right thing. [15:59] k [16:01] seb128: hughsie now added stuff like "available in your language" "integrated into your desktop" "has documentation" [16:01] I still think stars may be useful, though [16:01] yeah [16:01] rating&reviews are useful [16:02] and every other platform have those [16:02] it's a bit weird they remove that [16:02] juliank: yeah, I think we want ratings&reviews, there is even a git branch iirc by robert ancil [16:02] Yes [16:02] https://git.gnome.org/browse/gnome-software/log/?h=wip/rancell/ubuntu-ratings [16:10] tedg cjwatson: I can put it building into a silo [16:11] Mirv: that sounds like a good plan [16:17] LocutusOfBorg1, does https://launchpadlibrarian.net/187477970/keyutils_1.5.9-5_1.5.9-5ubuntu1.diff.gz still apply/would work? [16:25] tedg: mterry cjwatson: ok it's building and amd64 + ppc64el already successful, ticket https://requests.ci-train.ubuntu.com/#/ticket/771. please follow up since I'm in a bus already. [16:30] seb128, the testsuite is failing, so I presume it works [16:30] I can try [16:32] LocutusOfBorg1, k, thanks [16:32] those issues don't happen in Debian? [16:33] http://paste.ubuntu.com/13898370/ [16:33] seb128, according to the changelogs between 5 and 8, many different debian kernels have issues [16:33] and debian disabled tests in those revisions [16:33] so I presume also Debian is broken with some kernel combos [16:34] Let's see how my costamagnagianfranco/costamagnagianfranco-ppa behaves in the build [16:37] hum [16:37] diff doesn't apply [16:37] the one above? [16:37] I wonder if pastebin screwed new lines or something [16:37] damn yes [16:37] http://paste.ubuntu.com/13898496/ [16:37] does this one work? [16:38] the problem wasn't pastebin, but that I copy-pasted from vim :) [16:38] better [16:38] cjwatson: ah what I was hoping for before regarding multiple uploads in proposed was that LP would close the bug with the whole changelog leading to the fix, not just the last upload. but I went through the bugs now like bug #1502883 copy-pasting the relevant changelog manually. [16:38] bug 1502883 in qtdeclarative-opensource-src (Ubuntu) "Impossible to pull to refresh scopes with Qt 5.5" [Undecided,Fix released] https://launchpad.net/bugs/1502883 [16:39] but I think I've tried that using -v when building doesn't help there either [16:39] LocutusOfBorg1, sponsored [16:39] thanks! [16:39] I uploaded arrayfire a few seconds ago on debian [16:39] https://buildd.debian.org/status/package.php?p=arrayfire&suite=unstable [16:39] maybe on the next dinstall it will just work! [16:41] btw, I drafted a MOTU application https://wiki.ubuntu.com/CostamagnaGianfranco/MOTUApplication [16:43] I had many different sponsors ~10 and ~100 uploads sponsored [16:43] and they are low just because I maintain a no-delta policy from Debian for my packages :) [16:50] Is UDD being turned on for xenial at some point? [16:50] pitti: btw, don't know if you've seen LP: #1524480... the plymouth breaks: are tickling an extant bug in the lubuntu theme package [16:51] Launchpad bug 1524480 in lubuntu-artwork (Ubuntu) "package plymouth 0.9.2-3ubuntu2 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/1524480 [16:51] Odd_Bloke: according to cjwatson's mail to ubuntu-devel, it seems not; I would really prefer to have it turned on, imperfect as it is, given that a git replacement is not on the horizon [16:53] Thanks; I thought that's what I'd read but I couldn't think where I'd seen it to go and check. :p [16:53] slangasek, hey, do you have an opinion on samba versions for the LTS? or do you know who else might have? [16:56] seb128: I do not, sorry [16:56] k :-/ [17:00] slangasek: ah, will look at that with didrocks tomorrow, thanks [17:00] slangasek: (dealing with s390 ATM, and EOD, sorry) [17:00] pitti: no problem [17:01] same here, dealing with google code in student, will look at it tomorrow [17:23] what's the right way to merge a git branch on launchpad? [17:23] e.g equivalent of "bzr merge lp:~user/project/branch" [17:26] git remote add CONTRIBUTOR lp:~CONTRIBUTOR/PROJECT; git remote update CONTRIBUTOR; git merge CONTRIBUTOR/BRANCH [17:26] or something like that [17:27] at some point we'd like to add a merge/ ref namespace for all the active merge proposals into your repository, which would make that easier [17:27] (github has a pull/ namespace; similar idea) [17:28] cjwatson, thanks [17:28] cjwatson, are mps supposed to be closed if you pull your branch into master and push that? [17:28] seb128: yes [17:29] I did merge detection in ~June [17:29] merge [17:29] but not pull/push? [17:29] https://code.launchpad.net/~seb128/geonames/+git/reviewchanges/+merge/280044 [17:29] whatever :) [17:29] didn't close [17:30] git merges are often fast-forward [17:30] == pull [17:30] I guess I pushed at the wrong place :-/ [17:30] let me check [17:30] hum, no [17:30] https://git.launchpad.net/~geonames-dev/geonames/+git/geonames/log/?h=debian [17:30] has it [17:30] let me check [17:31] thanks [17:31] BTW you should just use ~seb128/geonames - no need to add a repository name [17:31] k [17:31] the intent is that the per-user default is suitable for basic patch contribution [17:32] seb128: so I don't know what you did but you didn't merge - I think you rebased or something [17:33] seb128: the commit hashes don't match [17:33] I did what Laney suggested :p [17:33] which is basically "clone master, pull my branch, rebase, and push" [17:34] well we can't detect rebases [17:34] if you'd merged we'd have detected that [17:34] k [17:34] I need to learn git better [17:34] thanks ;-) [17:34] if you're going to rebase, push the rebase to your branch first [17:34] * seb128 closes that one manually [17:35] i.e. git push +debian [17:35] (since this is the debian branch) [17:35] if you do that then LP has the information to know that the MP is actually merged [17:36] k [17:56] directhex, what's the story with the arm64 support in mono? [18:03] infinity: is lttng ust broken on arm64? it tries to use CLOCK_MONOTONIC which is not defined... [18:03] https://launchpadlibrarian.net/229616606/buildlog_ubuntu-xenial-arm64.ubuntu-app-launch_0.5%2B15.10.20150817-0ubuntu2_BUILDING.txt.gz [18:05] xnox_: Certainly sounds broken to me. [18:10] something needs to include the appropriate feature test macro in CPPFLAGS, I guess [18:12] infinity: cjwatson: https://git.lttng.org/?p=lttng-ust.git;a=commitdiff;h=ca4525b556680256149ead3746b566103e043d8e;hp=f7b16408b00ecce757bdde940853a48534b25edd [18:12] somebody things it's great everywhere. [18:12] i think i'll revert this check and make it conditional on actually ahving said clock available.... [18:12]