=== salem_ is now known as _salem [05:21] good morning === RAOF is now known as ROUS === ROUS is now known as RAOF [06:23] infinity: ugh, there was more? thanks! [06:23] good morning [06:33] pitti: I am in the process of building a process for future APT SRUs via a PPA (release -dput> PPA -copy-package-> archive), and was wondering what it takes to get autopkgtests running on the PPA (if that is possible). I'm not sure how useful that would be, but it certainly would not hurt... [06:35] Urgh. It's really annoying to review SRUs from PPAs :( [06:35] that ^ [06:36] juliank: we can run autopkgtests on PPAs and do it all the time [06:36] juliank: for the CI train in particular [06:36] juliank: the problem isn't running the tests, but presenting them -- you would need to set up a britney instance for the PPA to get something similar to https://requests.ci-train.ubuntu.com/static/britney/ticket-979/landing-065-xenial/excuses.html [06:37] juliank: by default the machinery just gives you the raw results like in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-ppa?format=plain [06:37] and have to trigger the tests manually [06:38] RAOF: The PPA basically acts as the APT 1.2 upstream repository once APT 1.3 hits unstable. Currently we basically sync from unstable to xenial, that then changes to 1.2 PPA->xenial [06:38] juliank: It's perfectly sensible to do that, it's just that our tooling for reviewing sync-from SRUs is bad. [06:38] (Yes, we did not really sync so far due to some minor technical issues, but that's the plan) [06:39] juliank: but, I think we can make this easier -- i. e. I could envision a small CLI program which downloads all the results for a PPA and gives you a package | pass/fail | URL table [06:39] And when I say “bad”, what I really mean is “nonexistent”. [06:39] RAOF: well, not *that* bad -- sru-review --no-diff [06:39] RAOF: and having to click two or three times to the PPA to get the diff from there [06:39] RAOF: Well, there will be nice detailed SRU bug reports... [06:39] pitti: True, assuming LP has managed to generate a diff against the right version... [06:40] juliank: the trickier part is to create a CLI program which *triggers* the tests for all rdepends of your PPA -- this really should use britney [06:40] RAOF: heh, true that [06:40] I often see that with silos, they often have the wrong one [06:40] pitti: True. [06:42] The next APT SRU will be far too large again, as it's 3 versions in 1. (1.2.13, 1.2.14, 1.2.15), because of regressions in yakkety sort of preventing me from pushing the earlier ones. [06:42] Although I suppose I could SRU 1.2.14 first and then do the 1.2.15 afterwards [06:43] 1.2.15 is like 3 bug fixes; one of which is a buffer overflow, one is a null pointer dereferencing, and the other I have not looked at yet.... [06:44] slangasek, hi, looks like your python-imagesize universe -> main override didn't actually work… [06:44] According to https://launchpad.net/ubuntu/+source/python-imagesize/0.7.1-1/+publishinghistory it got moved to universe again [06:44] Can you please check that? [06:44] juliank: when we moved the CI train to autopkgtests, I actually made it reasonably easy to set up your own britney, and there's documentation about it now [06:45] juliank: so if you want to be the guinea pig, we could do a first manual run on your PPA, then improve the tools along :) [06:47] pitti: Well, the 1.2 PPA is empty right now, as I don't have 1.3 in unstable yet. But we can play with https://launchpad.net/~deity/+archive/ubuntu/sid in the meantime. [06:47] Which is our daily built PPA [06:48] I think I'm going to drop the actual 1.2 PPA and make it a "stable" PPA, then I can upload different versions for different release series sensibly. [06:49] On the other hand, maybe someone on an older release wants to try a newer apt. [06:49] Difficult choices... [07:52] juliank: I'd rather 1.2.15, than two rapid fire SRUs. [07:54] infinity: aye, aye === seb128_ is now known as seb128 [10:12] Odd_Bloke: Still apparently no recent images in https://cloud-images.ubuntu.com/xenial/ - do you know what's up there? [10:16] cjwatson: I've been looking at it this morning, I think we've just had a string of poor luck with builders dying for no apparent reason; there's a build appearing now: http://cloud-images.ubuntu.com/xenial/20160705/ [10:16] Ah, brilliant. [10:41] Odd_Bloke: Hm. No arm64-uefi1.img? [10:43] cjwatson: Something shonky must have happened with the sync; it's there on the source. [10:43] (And also the amd64-disk1.img should not be 84M :p) [10:44] Oh, that's fixed now, so perhaps it'll show up in a minute or two. [10:44] well, it would be *nice* if it was 84MB :) [10:50] cjwatson: It's now there. :) === hikiko is now known as hikiko|ln [11:02] xnox: I'm working on fixing LP: #1570775 which implies adding the crashkernel= mechanics into kdump-tools [11:02] Launchpad bug 1570775 in makedumpfile (Ubuntu Xenial) "makekdump should re-exec with cio_ignore on s390x" [Undecided,New] https://launchpad.net/bugs/1570775 [11:02] xnox: want me to remove the equivalent code from s390-tools ? [11:03] xnox: i.e. the bits that add/modify crashkernel= in /etc/zipl.conf [11:11] Hi, could someone please retry apache-directory-server and proguard on Yakkety? They are marked as build failures, but I was able to build both successfully. Might have been resolved as time has passed. Thanks i advance :) [11:12] hjd: done === _salem is now known as salem_ === hikiko|ln is now known as hikiko [12:21] Odd_Bloke: Current arm64 uefi1.img LGTM from the point of view of having initrd.img as a symlink etc.; do you have a way of conveniently test-booting a few arches? [12:43] cjwatson: We do in yakkety, I'm looking at porting that back to xenial now. [12:43] Hi, I am facing issues while apt-get update, how to get rid of these error? But somehow apt-get upgrade runs successfully. I am using ubuntu 15.04. Here is the log file -> http://pastebin.com/vxvCC64V [12:44] I have tried this solution but no use -> http://askubuntu.com/questions/135932/apt-get-update-failure-to-fetch-cant-connect-to-any-sources [12:45] caribou, sure [12:49] techsayan: 15.04 is not supported anymore you should upgrade [12:55] techsayan: 15.04 is end of life [13:01] techsayan: http://askubuntu.com/a/91821/7808, https://help.ubuntu.com/community/EOLUpgrades [13:05] jtaylor: dobey: rbasak: So there is no way out for this? [13:06] yes, upgrade [13:07] techsayan: rbasak just gave you two links that explain a way out [13:08] There's no point "updating" but staying on 15.04, since there are no more updates available. [13:11] techsayan: really you need to upgrade to 16.04, as even 15.10 will be end of life in a couple weeks [13:28] Odd_Bloke: i tested the new xenial vagrant box from cloud-images today, but it doesnt include my changes. how's that going? [13:29] cjwatson: just in case you happen to look at germanium, there's a loooong-running ddeb-retriever which re-downloads stuff since mid-April (to clean up after a few ddebs which had a HTML error contents) [13:32] pitti: Ah, thanks, glad you sorted that out [13:33] cjwatson: yesterday I collected the bits from the last month, and today for some longer history, just in case [13:33] semiosis: It'll need to be SRU'd back in to xenial, so it needs to land in yakkety first. [13:34] semiosis: But we have an unrelated yakkety build failure at the moment, so we're working on fixing that first. [13:34] Odd_Bloke: ok. thanks for the update === jdstrand_ is now known as jdstrand [14:35] cjwatson: We're seeing http://paste.ubuntu.com/18546366/ as the console log for the arm64 image. [14:35] cjwatson: (Worth noting we've never booted one of these in ScalingStack before, so we might be doing something stupid unrelated to image issues :) [14:35] Odd_Bloke: I was going to say, may be worth trying the previous one as a control [15:47] Okaaaay, new lsb-releases (9.20160110ubuntu0.1) dropped python2 support, as an SRU to xenial. That doesn't seem cool, moreso since it broke backportpackage. [16:03] Unit193: bug 1596638. [16:03] bug 1596638 in lsb (Ubuntu Xenial) "python2 cannot import lsb_release on yakkety and now xenial" [Critical,Triaged] https://launchpad.net/bugs/1596638 [16:03] I think slangasek said he'd try to take a look today, but if you can do it, please feel free. [16:04] ...I have no idea how I missed that bug, but alright. I'm not a core dev. [16:05] infinity: meeting? [16:06] mdeslaur, he's here at DebConf, probably already at the bar =) [16:06] ah :) [16:06] doko: thanks [17:47] mitya57: the python-imagesize override worked fine, and then someone reverted it [17:49] unfortunately there's no audit log of who does the component changes === salem_ is now known as _salem === _salem is now known as salem_ [18:24] slangasek, ok, thanks for re-promoting. As soon as I get the list of failed autopkgtests for sphinx, I'll look at them. [18:27] Odd_Bloke: Incidentally I'm partly also interested in ensuring that my change hasn't somehow broken other architectures, so non-arm64 tests would be good too. I've asked IS to try the LP builder case with the new cloud images. [18:42] Odd_Bloke: Your arm64 console log is somehow magically powerpc? [19:58] nacc: php-monolog has turned up on my radar as a TIL merge, the only remaining change is nocheck/stage1 build profiles; can you forward that to Debian please? [19:58] nacc: (and dropping the delta in the meantime) [19:58] slangasek: ack, will do! [20:20] slangasek: sent [20:36] cjwatson, infinity: either of you recall the status of build-arch standardization in Debian? seems we have a package that builds ok in Debian but FTBFS in Launchpad (https://launchpad.net/ubuntu/+source/ganglia/3.6.0-6.1ubuntu1/+build/10423092, Debian bug #821985) [20:36] Debian bug 821985 in ganglia "ganglia: Build arch:all+arch:any but is missing build-{arch,indep} targets" [Normal,Open] http://bugs.debian.org/821985 [20:37] looks like "now mandatory" and perhaps the dpkg hacks have been phased out [20:41] slangasek: I bet this is a change in dpkg 1.18.8; the successful Debian build was with 1.18.7 [20:43] slangasek: the changelog entry is confusingly written, but as I read the change (git commit ad94a98cf614e1c4129f8611080232d69d210a0a) it affects builds of any source package that has both Architecture: all and non-all binaries in debian/control === NCommander is now known as mcasadevall === mcasadevall is now known as NCommander === salem_ is now known as _salem [22:25] cyphermox: is sg3-utils stuck in -proposed because we also need to merge up partman-multipath and multipath-tools? [22:50] slangasek: weird issue i'm hitting with the php7.0 SRU. I just added -proposed in a container to see if I can reproduce LP: #1598489. But I get this rather confusing policy output: http://paste.ubuntu.com/18587507/ and apt wants to remove fpm (and I wonder if that's what broke that setup) [22:50] Launchpad bug 1598489 in php7.0 (Ubuntu) "package php7.0-common 7.0.8-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10" [Undecided,New] https://launchpad.net/bugs/1598489 [22:51] bah, nevermind! configuration issue on my end! [23:05] nacc: do you have -proposed enabled in your sources for main but not universe? [23:14] slangasek: yeah that was the problem :)