[00:33] slangasek: so are we good to go on serving up some a2 images? [00:51] wxl: sure - what do you need from me? AIUI you should be able to trigger respins when you need, and I only need to do the final tagging as "alpha", or is there something else you need from me? [00:52] maybe creating the milestone on iso.qa.ubuntu.com requires release-team? [00:53] slangasek: pretty sure it does. i don't have the powers. when it's up, an announcement to ubuntu-release@lists would be nice [00:54] wxl: ok, created [00:54] oops. :) [00:54] now we have two alpha2's [00:54] hello o/ [00:55] heh [00:55] slangasek: is the plan for release still going to be thursday? if so, could we release it late so we have a little wiggle room? if not, friday please [00:55] slangasek, i'll go and archive the other. [00:55] knome: I've already archived one ;P [00:55] yeah... [00:56] i saw that [00:56] * knome takes a step back [00:57] wxl: this is a decision for the flavor contacts; I'm available either Thursday or Friday to pull the trigger [00:57] slangasek: ok then we're good to go now or are you and knome still playing in the sandbox together? XD [00:57] eheh [00:57] oh i see we don't have images yet, just the milestone [00:57] * knome pats the shovel on the bucket [00:58] you have exactly 28 minutes to resolve that, otherwise drop me an email when you're done :) [01:00] wxl, what do you need? [01:00] I in fact have no idea how to register a build as being for the alpha [01:00] http://iso.qa.ubuntu.com/qatracker/milestones/354/builds is empty [01:00] http://iso.qa.ubuntu.com/qatracker/milestones/354/builds [01:00] yep what he said [01:00] right [01:00] and has no button for associating a build with the milestone [01:01] i think i have done that at least once. [01:01] let me see. [01:01] knome: ok, I found where I seem to be able to do it [01:02] good :) [01:02] then i'll let you do it [01:02] done [01:03] wxl: does that mean you will send the email, or is this something you need me to do? [01:06] slangasek: i'm on it [01:06] wxl: ok, cheers [01:06] slangasek: thank you sir [01:07] flexiondotorg: you around? you ok with releasing on friday? also it looks like your amd64 is outdated http://iso.qa.ubuntu.com/qatracker/milestones/354/builds [01:09] flexiondotorg: well suffice it to say do what you want with your images until you got the milestone the way you like and let me know if you want to do thu or fri (i prefer the latter), and i'll email everyone [03:20] slangasek: did you stop building dailies? [06:55] wxl: mmm no I didn't sorry, will do that now [06:57] slangasek: please don't stop everyone's :) [06:58] flocculant: I'm stopping the ones for the flavors opting into the alpha [06:58] just double checking :) [06:58] it has happened in the past ;) [07:09] wxl Friday is fine with me. [08:49] Hello! I need to disable the system-image importer for a short while again [13:12] slangasek, Ubuntu MATE i386 and PPC and stuck rebuilding. [13:13] The existing images are good enough. [13:13] I can't cancel the rebuilds, can you stop them please? [13:25] flexiondotorg: Cancelled. [13:25] infinity, Thank you. === pete-woods1 is now known as pete-woods [17:18] arges, could you please review libica in xenial NEW for me? =) [17:18] it's blocking further enablement of s390x crypto [17:26] slangasek, could you please review libica in xenial new? (btw are you AA?) [17:51] arges: Could you have a look at my ubuntu-release-upgrader SRU in the wily queue? [17:52] bdmurray: sure [17:52] thanks [17:56] can anybody look at wily queue? people wants llvm* accepted :) [17:56] LocutusOfBorg: sure [17:56] trivial changes, just fixing build failures [17:56] no even need to test them [17:57] thanks arges [17:57] also the llvm-3.4, is there since a few months, safe to accept, just a regex update to accept gcc-5 [17:57] while I'm on it [17:58] today I NMUed a bunch of packages in unstable, wrt libpng transition [17:58] the transition will start soon(TM) on debian [17:58] and I would like to followup on ubuntu too [17:58] I'm fixing the reverse dependencies since a while now [17:58] and they should be in order [17:58] except for a few [17:58] bdmurray: its difficult to tell with the diff but the demoted.cfg.trusty in data is a symlink to the one in utils? [17:58] maybe having a tracker, might help [18:00] bdmurray: and where is the explaination for adding the mirrors? [18:01] arges: Updating mirrors is just a thing that happens when running pre-build.sh [18:03] arges: And yes to the other question: [18:03] lrwxrwxrwx 1 adconrad adconrad 20 Oct 21 10:25 demoted.cfg -> ../utils/demoted.cfg [18:03] lrwxrwxrwx 1 adconrad adconrad 27 Jan 25 15:09 demoted.cfg.trusty -> ../utils/demoted.cfg.trusty [18:05] infinity: thanks [18:06] infinity: thanks [18:07] LocutusOfBorg: the llvm-toolchain-3.7 in wily queue, does ubuntu4 superceed ubuntu3? [18:07] yes arges [18:08] with ubuntu4 the package will build everywhere [18:09] LocutusOfBorg: also for LP: #1501300, can you add SRU information, and ensure that the development task is fixed? [18:09] Launchpad bug 1501300 in llvm-toolchain-3.4 (Ubuntu) "Wily (15.10) this package got not compiled with __cxx11 support" [Medium,In progress] https://launchpad.net/bugs/1501300 [18:14] arges, updated, even if Laney should have a look (being the sponsor here) ^^^ [18:16] LocutusOfBorg: so this is fixed in Xenial? [18:17] i'll just check [18:17] arges, if you ask about llvm-3.4 yes, because the package has been removed :D [18:17] LocutusOfBorg: yea : ) [18:17] ok [18:17] anyway, we did the same in debian FWIW [18:17] and for later releases [18:21] LocutusOfBorg: sru template on LP: #1532716 would be nice too. : ) [18:21] Launchpad bug 1532716 in llvm-toolchain-3.7 (Ubuntu Wily) " llvm-toolchain-3.7 FTBFS on powerpc and s390x [SRU]" [Undecided,New] https://launchpad.net/bugs/1532716 [18:23] done :) [18:24] LocutusOfBorg: ok accepted. did I miss anything? [18:24] I guess not :) [18:24] thanks! [18:46] arges, if you really have time I would appreciate a review of the package in bug 1424769 [18:46] bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [High,Triaged] https://launchpad.net/bugs/1424769 [18:46] I would like to upload asap on trusty [18:46] I just uploaded virtualbox-lts-vivid_4.3.36-dfsg-1+deb8u1ubuntu1.15.04.2~14.04.1ubuntu1.dsc on my ppa [19:13] LocutusOfBorg: hi I'm not exactly sure about adding this new package if its the right answer here. So I'd ask others to review that may have more experience here [20:04] can someone figure out why the proposed migration excuses system doesn't see the latest binaries built in the upload of nginx 1.9.10-1ubuntu1, or whether that's old data left over on the cached migration excuses page? [20:04] (it's as if autopkgtests aren't being processed... or something's not synced up...) [20:04] teward: just need to wait for the publisher to rerun [20:05] Last run was 2016.01.27 19:52:45 +0000 [20:05] Usually it's around half an hour between updates. [20:05] odd, then, that it didn't catch the binaries built - LP shows the builds all having succeeded before that last run time [20:05] (it cycles constantly, AIUI) [20:05] LP might not have "published" them to the proposed pocket, though. [20:06] rbasak: "Published: 50 minutes ago" according to LP, unless it's giving me junk data [20:06] hence my curiosity as to why update excuses says no binaries exist [20:07] * teward shrugs [20:07] Sources or binaries published? [20:07] Anyway, I'm not familiar with the details. All I know is that I want a cycle or two before I assume anything's wrong :) [20:07] i'll wait another 30 minutes or so and poke again if it's still broken [20:45] teward: You got unlucky and hit the once a day or so when we run "apt-ftparchive clean" to make sure a-f's databases don't get out of hand [20:46] teward: So this was an unusually long run as a result, but it's getting there [20:46] (If we don't do this, things get incrementally worse and worse) [20:46] cjwatson: coincidence: i was just about to poke here heh [20:47] cjwatson: i can understand that, though it's one of those "what the...?" moments where we don't see that going on here on my end [20:47] so it's just sitting there in "Confused!" state heh [20:47] Right, it's not visible externally [20:48] But all those nginx binaries were in the publisher run that just finished (well, finished enough for jobs such as proposed-migration to be able to see it), so it shouldn't be too long now [20:49] awesome, thanks for keeping me in the loop :) [20:51] The long run isn't at a fixed time; it happens if the publisher gets to the relevant point and it's been more than a day since the last cache cleanup [20:51] So in practice it tends to precess slowly around the clock [20:52] As emergent effects go that isn't a terrible one, as it means it isn't always irritating the same people [21:53] xnox: no dep3 headers on your patches? (libica) [21:56] slangasek, nope =) [21:56] xnox: y u h8 freedom [21:57] also: 'lintian -I' for great justice [21:57] slangasek, because i am trump?! [21:57] =) [21:57] slangasek, there is no upstream to submit them too, is there [21:57] ? [21:59] isn't there? you listed an upstream homepage [21:59] did I? /me redownloads the package [22:01] xnox: debian/libica2.install > please include the soname as part of the glob; AFAICS there's nothing in the packaging that will hard fail the build if someone tries to build a new upstream version without checking the soname [22:02] slangasek, but rpm provides catch that. [22:02] * xnox talks like an ibm java engineer [22:02] slangasek, fixing. [22:02] thanks [22:02] not a blocker, so accepting [22:02] so you can upload 0ubuntu2 [22:03] tah. [22:06] blimey there is git repository. I shall git format all the patches. [22:39] something broke gettext on s390x (and/or other arches...) [22:39] # xgettext [22:39] xgettext: error while loading shared libraries: libcroco-0.6.so.3: cannot open shared object file: No such file or directory [22:40] doko, gettext is no worky. [22:43] doko, libcroco3 dependency is missing. [22:45] xnox: You run -proposed? [22:46] infinity, my sbuild chroots do =) e.g. systemd when findinging utilities (e.g. xgettext) tries to exec them too. and that causes FTBFS. [22:46] Ahh, that makes more sense. ;) [22:46] i wish i didn't open gettext debian/rules [22:46] let's just say there is no debian/compat file [22:46] who is sanvila [22:48] xnox: A Debian developer since slightly before you were born. [22:53] infinity, blimey. i think i got it. [23:02] nah i don't get it. [23:03] xnox, hmm, the build log looks ok, libcroco is linked, but the deps are missing :-/ [23:04] infinity, doko: i've rerun the build, run the shlibs myself, and i am confused... http://paste.ubuntu.com/14683428/ [23:04] slangasek, i really like rpm automatic provides & requires for stuff like this. [23:04] doko, i wonder if running dh_ commands will actually make it work somehow. [23:08] infinity, doko: # dh_shlibdeps -p gettext => generates the right thing, shlibs:Depends=libc6 (>= 2.17), libcroco3 (>= 0.6.2), libgomp1 (>= 4.9), libtinfo5 (>= 6), libunistring0, libxml2 (>= 2.9.1) [23:11] hm. [23:11] multiarch?! [23:12] dpkg-shlibdeps `sh debian/elf debian/$@/usr/bin/* debian/$@/usr/lib/gettext/* debian/$@/usr/lib/*` [23:12] That would miss the multiarch dirs. [23:12] aha [23:13] doko, do you want to upload with extra debian/$@/usr/lib/*/* ? [23:13] * xnox really does not want TIL there. [23:13] Looks like it got done for the library build, but not the binary builds. [23:14] yeap. [23:14] dpkg-shlibdeps `sh debian/elf debian/$@/usr/bin/* debian/$@/usr/lib/*` [23:14] dpkg-shlibdeps `sh debian/elf debian/$@/usr/bin/* debian/$@/usr/lib/gettext/* debian/$@/usr/lib/*` [23:14] is that our delta, or bug in debian? [23:14] dpkg-shlibdeps `sh debian/elf debian/$@/usr/lib/$(DEB_HOST_MULTIARCH)/*` [23:14] dpkg-shlibdeps `sh debian/elf debian/$@/usr/lib/$(DEB_HOST_MULTIARCH)/*` [23:14] Based on the changelog, I'm guessing it's us. [23:15] yep [23:15] test building ... [23:15] doko, thanks. [23:16] infinity: for a package removal request, who needs to be subscribed to the bug, the archive admins team? Or is there someone else I'm missing (the docs were a little hard to process, so it wasn't as clear to me...) [23:16] teward: ~ubuntu-archive [23:17] cool, wasn't sure if there was another team that needed subscribed, thanks. [23:17] slangasek or infinity, could you please process binary new for libica? [23:18] xnox: Looking. [23:19] xnox: libica-dev looks like it's missing a dep on libssl-dev [23:20] (At least, based on the fact that libica2 depends on libssl) [23:20] how is the cdbs hook called that runs after the upstream make install? [23:23] xnox: Looks good otherwise. [23:28] doko, binary-post-install/mypackage:: [23:28] mv debian/mypackage/usr/sbin/myprogram debian/mypackage/usr/bin/myprogram [23:28] rm debian/mypackage/usr/share/doc/mypackage/INSTALL [23:28] stuff? [23:29] http://build-common.alioth.debian.org/cdbs-doc.html#id2546352 [23:29] xnox, no, not after every package is installed, just the hook after the installation into debian/tmp [23:31] doko, common-install-arch:: [23:31] and/or common-install-indep:: [23:32] doko, http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml see table 2.2 Targets commonly available in debian/rules [23:33] doko, looking at your gettext diff, i'm pretty sure it will fail to build from source =) [23:33] http://launchpadlibrarian.net/235452931/gettext_0.19.7-2ubuntu1_0.19.7-2ubuntu2.diff.gz [23:34] missing DEB_HOST_MULTIARCH in the second hunk, and/or accidental removal of the trailing` [23:34] Looks fine to me... [23:34] oh [23:35] i resize the browser and it looks good. [23:35] :P [23:35] i shall logout and go away [23:35] xnox: automatic provides+requires only works because rpm lets you have two versions of the same package name installed at the same time, which is just looney [23:36] slangasek, which is what multiarch allows, right?! =) [23:36] slangasek, they do allow that, but guess what koji has no concept of not-build-from source binaries, they are wiped from the archive. Horay broken builds all the time, and really painful abi transitions. [23:37] (one generally ends up using bootstrap repositories a lot) [23:40] xnox, looks pretty green [23:40] doko, yeah, i failed at using computers [23:41] ok. How does one interpret the User process faults? [23:41] https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1538723 [23:41] Launchpad bug 1538723 in rsyslog (Ubuntu) "rsyslog user process faults on s390x" [High,New] [23:41] * xnox expected a whoopsie popup... [23:41] * xnox ponders if that is installed on the server [23:42] xnox: you didn't see the whoopsie popup? You must not have been watching the teletype [23:42] no, there is no whoopsie installed by default on the server. You can choose to install apport-noui