[00:01] tumbleweed, jtaylor, barry, pitti: migration of python-numpy is needed for the python3.4 removal. any ideas? [00:03] * tumbleweed looks [00:05] numpy itself is failing, but maybe that's shallow [00:05] (failing on py27?) [00:15] doko: whats blocking it? [00:15] oh the failure itself is simple [00:15] too bad morph doesn't care about adt tests :( [00:16] df70490874e33e1fad18720f5c74fb5e319c9e06 is the fix [00:16] fwiw scipy will fail with that numpy but an upload for that is waiting on a sphinx update [00:17] should be done soon === rww is now known as rwd [00:19] jtaylor, well, then why does he add these? [00:19] doko: I added them [00:19] bad jtaylor ;-P === rwd is now known as rww [00:51] ok, so I really don't know who to contact so I came here. I was looking at FTBFS and I noticed hplip was failing builds. So I peeked at the logs and it had a dependency error of cups that was already in the repos. On my machine, the build was successful. Where should I file a bug? Who should I report it to? [00:52] and it builds successfully upstream [00:52] hplip is in main [00:53] should this go in #ubuntu+1-maint? [01:20] tsimonq2: Probably fixed by the recent promotion of liblouis-bin to main. I've retried the failed builds. [01:21] cjwatson: ok thanks [01:22] * tsimonq2 watches the builds :D [01:58] woo! [01:58] I've finally made progress on the apache configs for php7.0 [02:27] can this bug be attached to apt in FTBFS? thanks! https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 [02:27] Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New] [02:28] mdeslaur: don't suppose you would have any insight into bug 1537762...? bit short on details unfortunately [02:28] bug 1537762 in openldap (Ubuntu) "syncrepl does not work when using tls" [Undecided,Incomplete] https://launchpad.net/bugs/1537762 [02:34] tarpman: it reminds me a little of https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1534230 -- the openssl s_client and openssl x509 advice there may help debug that [02:34] Launchpad bug 1534230 in gnutls26 (Ubuntu) "LDAP TLS connection stopped working" [Undecided,Invalid] [02:34] pity these bugs elide the useful details; it'd take one of us a few seconds to check.. oh well. [02:35] to be fair, slapd's logging of tls errors leaves something (a lot) to be desired... I have a wishlist bug for that around here somewhere :) [02:35] hehe :) [02:35] yeah, that definitely looks relevant. thanks, posting the link now (unless you beat me to it) [02:36] go ahead [02:36] I always have to /whois you to remind myself you're not my former coworker with the same first initial last name :P [02:37] the guy who's been stealing my username! [02:37] heh, I don't think he IRCs... [03:02] I looked into devscripts on FTBFS, it seems like there is no longer a dependency problem but a build problem. Can someone please do a build to confirm this and to get bugs filed? Thanks! [03:05] It also seems like this is a problem on our part, since Debian's autobuilders succeed: https://buildd.debian.org/status/fetch.php?pkg=devscripts&arch=i386&ver=2.15.10&stamp=1451535039 [03:26] looking at FTBFS again, can graphite2 be rebuilt? I might have some local problems but I know the dependency problems are fixed... [05:48] good morning [06:41] Good morning [06:48] morning [06:49] hey lathiat, good morning! [06:58] doko: looking at the regessions; I uploaded the fix for numexpr [07:20] doko: the "Specified path is invalid." warning in python-numpy is real, and does not happen with 1.8.2 [07:28] doko: it tries to os.path.isdir('') which is the value of runtime_library_dirs which gets initialized to [] [07:30] doko: this whole system_info code is new in 1.10 apparently [07:30] doko: I mean the part with the default_runtime_dirs, there's a few other default_*_dirs already [08:53] hi cjwatson a question wrt iulib [08:53] can I steal your merge? if so, can we fakesync it? [08:53] not sure what does it mean :) [09:53] pitti: may i have some tests lxc tests re-run please: run-autopkgtest -s trusty -a ppc64el --trigger linux-meta/3.13.0.77.83 lxc [09:56] henrix: started [09:57] pitti: awesome, thanks! [10:48] mdeslaur: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5 apparently regresses php-crypt-gpg and php-horde-icalendar, can you please have a look? (the other regressions are already overridden) [10:50] that blocks the python3.4 removal [10:56] cjwatson: do you know a trick how to get the -images tarball from https://launchpad.net/~pitti/+archive/ubuntu/sru-test/+build/8897111 ? [10:56] or do PPAs simply not do that? === _salem is now known as salem_ [11:21] cking, are the zfs package bits aiming for main inclusion for 16.04? I was pondering enabling support in ceph for zfs but would need libzfslinux-dev in main for that [11:23] jamespage, we hoping to get it into main, I've filed a MIR, so it's Work-in-Progress === cpaelzer is now known as cpaelzer_afk [11:25] pitti, can you please make qbzr autopkgtest not blocking pygments migration? It's not a regression, but rather something seasonal (https://bugs.debian.org/776188#10) [11:25] Debian bug 776188 in src:qbzr "qbzr: autopkgtest fails since 2015-01-01" [Normal,Open] [11:26] (and I've just fixed sphinx which was a real regression) [11:30] mitya57: wtf at that [11:30] but can't it be fixed? [11:31] I quickly looked at it, and didn't see an easy way to fix it. [11:31] And I don't have much time today to dig into that code. [11:33] pitti: can i also have this please? run-autopkgtest -s wily -a armhf --trigger linux-meta/4.2.0.27.30 flashcache === cpaelzer_afk is now known as cpaelzer [11:45] henrix: done [11:49] pitti: thanks [11:56] mitya57: "the tests [11:56] fail on months containing J, that is Januarys, Junes and Julys" [11:56] ! [11:57] mitya57: it's not nearly as good as the infamous "OpenOffice does not print on Tuesdays" bug, but still fun :) [11:57] :) [11:59] mitya57: but the sphinx regression is really recent (it started failing on the new pygments), so that needs looking into [11:59] pitti, I've uploaded new sphinx fixing the issue [12:00] mitya57: ah great! I hinted qbzr [12:00] Thanks! [12:04] pitti: yes, I'll look today (php5 migration failure) [12:04] mdeslaur: thanks [12:13] cjwatson: unping; the build log plus local build are sufficient [13:20] LocutusOfBorg: Feel free to steal my iulib merge, don't mind what you do with it after that [13:21] pitti, no need to say that I trust you, so next time on libmtp you want to fix something, just fix it :) [13:21] quadrisp1o: ok :) [13:21] feel free to add yourself to Uploaders [13:22] quadrisp1o: we don't need an upload just for this, but good to know that we don't have a permanent delta because of this now [13:23] pitti: I don't think you can get the tarball as such, but it's unpacked and published to your PPA in the usual place - http://ppa.launchpad.net/pitti/sru-test/ubuntu/dists/trusty/main/installer-amd64/20101020ubuntu318.34/images/ [13:23] cjwatson: oh! I guess that was too obvious, thanks! [13:30] doko: hi, llvm 3.8-rc1 got released, do you know if sylvestre plans to work on it soon? [13:31] tjaalton, no [13:31] doko: ok, I'll ask him [13:31] ta [13:31] cjwatson, question: the delta is now dropped, unfortunately the version naming is strange 0.4+is+0.3-3ubuntu2 [13:31] so I don't think I can sync [13:32] do you have any advice? just rename the last entry and upload? [13:34] apw: do you still remember what we meant in bug 1497291? [13:34] doko: turns out it's already uploaded to experimental, but in NEW [13:34] bug 1497291 in Auto Package Testing "britney is requesting/reporting test results for reverse-depends architectures even when used in forward context" [Undecided,New] https://launchpad.net/bugs/1497291 [13:34] LocutusOfBorg: I would probably apply the same changes so that it's effectively in sync and call it 0.4+is+0.3-3ubuntu3; not much else we can do until the version in Debian increases to something past ours [13:35] thanks, I was wondering about epoch in debian and sync :) [13:35] anyhow, I just changed the last changelog entry and uploaded [13:35] thanks [13:36] pitti, i am reading that as when running a test for foo which triggers linux-keystone that it triggers tests for all of foo's architectures not all of linux-keystones' [13:36] LocutusOfBorg: an epoch would be permenant. At least this way the mess is temporary. [13:36] pitti, but ... it is rather vague [13:36] rbasak, sure, I really don't like epoch too [13:36] * LocutusOfBorg never bumped an epoch [13:38] apw: hm, I thought that got fixed a long time ago already [13:40] pitti, may well so [13:40] apw: the bug says that http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#linux-meta-keystone was wrong, but it currently looks right, doesn't it? [13:40] pitti, yep looks right. i'd be inclined to call it fixed as we'll never know anyhow now :)( [13:40] :) [13:40] apw: ack [13:46] question, an ubuntu delta about renaming library for gcc5 transition ( pitti ), can be dropped after wily? [13:46] package: libclaw [13:47] LocutusOfBorg: no, after xenial only, as we need to support trusty → xenial upgrades [13:47] if not: can I steal your merge? [13:47] LocutusOfBorg: please do steal, thanks! [13:47] :D [13:47] thanks to you [13:48] * tsimonq2 wonders if he should repost wht he said yesterday, following up on some FTBFS issues... [13:48] apw: FYI, we have a slight technical hitch (aka "we kill all instances"): http://paste.ubuntu.com/14671742/ [13:49] pitti, that doesn't look good [13:49] pitti, any idea what is triggering that ? [13:49] Laney: let's move here, to have everyone on the same channel [13:49] apw: I figure apt pinning + dist-upgrade again, let me check [13:50] pitti, oh it might not be a real issue, one we are generating in the test environment [13:50] pitti, it can be syncd [13:50] I missed that debian renamed the library too [13:50] LocutusOfBorg: heh, they better did; nice [13:51] I was looking at the latest changelog entry, missing the previous one [13:51] and complaining about "why the hell the patch doesn't apply", when I discovered it was already there :p [13:51] LocutusOfBorg: someone (you?) already synced [13:51] me [13:52] After using an schroot, is there anything I have to do to clean it? [13:52] as you have noted, I'm merging all the libpng-dev packages from debian [13:52] For building a package [13:54] apw, Laney: yep, --apt-pocket=proposed=src:init-system-helpers does that; yay apt pinning being too clumsy :/ [13:54] I'll disable it for a moment, let the i-s-h tests run, and re-enable it [13:55] mterry, can I steal your xaos merge? [13:55] LocutusOfBorg: doesn't need an epoch; the version in experimental is already greater than what we have, so we should be fine when it gets to unstable [13:55] cjwatson, yes, sure [13:55] BTW the revert was back to oneiric [13:55] when a reverse-dependency that now disappeared was needing the old version [13:56] so I presume without it, we might also push experimental to unstable and force-sync [13:56] but I prefer to concentrate to fixing libpng [13:56] LocutusOfBorg, sure thanks [13:57] pitti, phew (in a way) [13:57] dear apt: pinning priority of 800 does not mean "OMG stay away from it like the plague!" [13:58] Laney: so *now* it will test everything with kernel 4.4 too (without apt pinning, I mean) :) [13:59] pitti: heh [14:00] pitti: there's a forced lockstep upgrade of i-s-h and sysvinit-utils [14:00] xaos can be syncd [14:00] I guess this explodes apt [14:00] Laney: right [14:01] Laney: well, it's fine without pinning, but if you say "prefer the i-s-h binaries from -proposed" it doesn't grok that it should use proposed for the necessary dependencies too [14:01] Laney: it seems like it's either "ish binary deps are completely satisfiable in -release" or "I refuse" [14:01] pitti, i thought that when things failed with pinning it fell back to enabling -proposed en-toto ? [14:01] apw: yes, but that's the early dist-upgrade [14:02] oh heh only there, ok [14:02] way before installing the test deps [14:02] and it doesn't technically fail [14:02] it "just" removes openss.. [14:02] h [14:03] pitti, hehe that must be a little bit disruptive to results gathering :) [14:03] since apt pinning is so completely useless for every nontrivial case, I wonder if there's a different approach that we can take [14:04] pitti, we know the versions of them don't we, can we not install foo=version [14:04] perhaps, first install everything from -release, *then* add -proposed apt source, and install everything again [14:04] then it should not upgrade stuff unless dependencies mandate it [14:04] that sounds feasable [14:04] I don't want to rewrite apt's resolver, no [14:05] just make it less greedy with picking stuff from -proposed, or alternatively fix the apt pinning to actually fall back from 900 -proposed to 800 -release [14:05] * apw doesn't even want to look at apt's resolver :) === _salem is now known as salem_ [14:05] that sounds like a nice thing to look at tomorrow morning in the train [14:06] in FTBFS, libsecret is failing due to gjs not being in main but Universe, and there is no Mir bug filed...should *I* file one, not being the maintainer? [14:06] i think upgrade from !-proposed, install triggers, add -proposed, install triggers would do pretty well, and better than it does now [14:07] pitti, and remember thats not -release but -updates in the older releases [14:07] yeah, but same thing in this context [14:08] I guess that would improve things, yeah [14:08] same situation with appstream-glib depending on libgcab-dev... [14:08] apw: so in the second step we would iterate over all binaries of the triggers, check if they are instaslled, and if so, apt-get install them again [14:08] The other thing is to move testing to another phase after _output [14:08] (as we don't want to blindly install all binaries of the trigger -- that might not even be possible) [14:08] and do it per transaction [14:09] I wonder how that would fail with library transitions [14:09] pitti, yeah good point [14:09] and for binNEW, or even source NEW, etc. (the trigger might not even *be* in teh release yeat) [14:09] yet [14:09] so, it's not going to become any easier (the contrary), just perhaps more useful [14:10] (Then you test the set of things you're trying to migrate) [14:10] Laney: "move testing to another phase after _output" → can't parse, sorry [14:10] excuses -> output -> test -> migrate [14:10] i.e. test things after they become a candidatge [14:11] Laney: ah, to avoid running into uninstallability [14:11] because britney has then worked out the transactions already [14:11] and those are the units of migration [14:11] interesting idea [14:11] so you'd make a fake Packages file or something which represents those [14:32] Laney: or we could pin all binaries involved in that transaction [14:33] Laney: which should work again, as that ought to be a closed set [14:33] Laney: sounds elegant, but we would then start depending on being able to download update_output.txt from everywhere [14:33] and more importantly, depending on that it is actually current === coreycb` is now known as coreycb [15:05] sarnold, can I sync flogwatch? your security update seems icluded in the debian version (new release) [15:22] pitti: Hm? I imagine you'd feed the requests from britney still, just at a later phase [15:22] pitti: can't use update_output now as the packages we're testing aren't candidates yet so they don't appear there [15:23] Laney: oh right, you mean britney will forward the set of packages as test parameter, so that the worker can just add them to --apt-pocket=proposed=src:a,src:b, etc. [15:24] so, this is quite a heavy piece of reengineering, but sounds interesting indeed [15:24] pitti: I would ditch the pinning and just make a fake release as this is more robust [15:25] but it might work either way [15:25] definitely a lot of reworking [15:26] Laney: oh, you mean: apt-get update, create fake _Packages from the complete proposed_Packages and the sources we want, and replace -proposed apt source withthat [15:26] that doesn't work, as dependencies from the ones "we want" might also just be in -proposed [15:26] pitti: britney is saying that it wants to remove the -release package and all its binaries and put the -proposed one(s) and all its binaries in [15:26] so for that we need the britney "give me the complet set" features [15:26] yes [15:26] Laney: but once we have that, apt pinning works equally well :) [15:26] that's what update_output knows [15:28] pitti: I don't think that's the most important part of the proposal, so whichever way you like [15:28] The other way feels more like "this is the state we are trying to mutate -release into" to me [15:29] no possibility of an unclean environment [15:29] but, doesn't matter that much [15:29] * Laney goes to write weekly report [15:33] mitya57, can you please merge tracker from debian? [15:52] LocutusOfBorg, sure [15:58] hey, do we have a plan for signed firefox addons ? [15:59] just upgraded and see that 'Uubntu Online Accounts', 'Unity Desktop Integration', 'Unity Websites integration' have all been disabled. [15:59] in addition to pentadactyl which i actually care about (https://github.com/5digits/dactyl/issues/99) [16:04] LocutusOfBorg, done [16:06] mitya57, <3 [16:19] barry, we are close https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1538198 [16:19] Launchpad bug 1538198 in python-defaults (Ubuntu) "python in xenial cloud image" [Undecided,New] [16:19] no real digging yet as to what is getting the remaining bits pulled in. [16:21] smoser: cool, thanks. i'm subscribed now. [16:27] pitti: hi, re: bug #1537211, your changelog makes it sound like you're dropping the attachment of /var/log/udev rather than replacing it with attaching the udevadm info output? [16:27] bug 1537211 in libmtp (Debian) "clean up /var/log/udev.log" [Unknown,New] https://launchpad.net/bugs/1537211 [16:28] slangasek: attaching udevadm dump already has happened for a long time (UdevDb: field) [16:34] pitti: hah ok [16:34] pitti: thanks :) === cpaelzer is now known as cpaelzer_afk [17:47] lamont, around ? [17:47] you're postfix maintainer... postfix seems to be what is pulling in python in cloud image http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/cloud-image.depends [17:47] smoser: sigh [17:47] https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1538198 [17:47] Launchpad bug 1538198 in python-defaults (Ubuntu) "python in xenial cloud image" [Undecided,New] [17:47] otp [17:47] its Recommends. [17:48] i'll poke a bit, but if you know why, and if we could do anything, that'd be good. [18:13] smoser: looks like https://bugs.launchpad.net/bugs/1538198 and some scripts that need to be taught about python3, and a change in Recommends [18:13] Launchpad bug 1538198 in postfix (Ubuntu) "python in xenial cloud image" [High,Confirmed] [18:13] bah [18:13] smoser: rather, * Recommend: python for postfix-add-* scripts. <-- that change [18:14] so postfix-add-* scripts need to learn about pytho3n [18:14] lamont, yeah. see bug, i posted a hack/quick 10 minute try [18:14] I expect to have some time on the plane this weekend, which is doubtlessly not soon enough for your happiness. [18:15] well, thats fine with me. we're down to just that in the image to my knowledge. [18:15] oh, cool [18:15] * lamont adds it to his plane-fun [18:15] though, tbf, it's more airport-fun, I plan to sleep on at least the first leg [18:15] if you want, you can give my patch a try. i just verified running 'python3 .py' worked for everything. [18:16] smoser: uh... you do the ubuntu1 version and I'll merge it upstream? [18:16] bounus if the hacked file runs under both :D [18:17] well, want to test it . i just verrified compiles [18:17] SHIP IT! [18:23] I think "mk-sbuild sid" may be broken on Xenial. Not confirmed fresh yet. /dev/null inside the chroot ends up 644. Anyone else seen this? [18:24] "mk-sbuild xenial" is fine. === cpaelzer_afk is now known as cpaelzer [18:34] xnox: did you get nodejs to build on s390x? [18:37] lamont, anoterh patch there now. this one passes pylint's checker [18:39] heh [18:39] thanks [18:40] I wonder, does launchpad bugs have anything like debian's bts (cli) for offline bug processing and perusal? thinking "wut? no..." [18:42] Launchpad has an API, so you could write a CLI I guess, if nobody's done that. [18:42] You can change bug statuses via email. [18:43] rbasak: the question was one of totally not wanting to write it, just wanting to be able to read the bug while wifi-disconneted. :/ [18:43] so no worries, I guess [18:44] lamont: what's this "offline" thing you talk about? [18:44] mdeslaur: sometimes, it's my life. :( [18:45] mdeslaur: says the security guy :-P [18:45] rbasak: to the security guy :D [18:47] you don't get security updates when you're offline! :P [18:47] Tell me that when you show me a CVE that affects my offline single-user machine :) [18:48] * rbasak half expects one to exist [18:48] CVE-2016-0123: rbasak left his front door unlocked [18:48] ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0123) [18:52] lol === southey is now known as foxtrot [18:55] hehehe [19:15] hallyn: So if I add a dep on libpam-cgm, should that be a "libpam-cgm | libpam-cgfs" ? [19:17] tedg: or rather libpam-cgfs | libpam-cgm [19:18] K [19:26] It's debootstrap that's broken I think. It now creates /dev/null as 644 because it runs mknod directly and doesn't set permissions. [19:26] * rbasak files a bug. [19:27] maybe try with umask 0 to see if that unblocks you? [19:49] sarnold: I'm just reverting the upstream commit that caused the regression - http://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=5518b79792dd93a416464c0744b87eb1a32ff770 [19:49] I just patched the functions file in reverse, and I think I'm good for now. [19:54] rbasak: hah, nice fix.. [20:14] rbasak: so I've got a question [20:15] Pharaoh_Atem: o/ [20:15] Sure [20:15] I've got working dep8 tests for php7.0 now [20:15] \o/ [20:15] and I've even added an fpm one [20:15] but my problem is how to handle adding the php-fpm httpd config to the php package [20:15] because right now, the php package does not provide one [20:15] Pharaoh_Atem: heya! [20:15] nacc: yo! [20:16] I saw your post on LP [20:16] If I understand you correctly, you can just drop it into the test [20:16] You don't need the package to provide one specifically; the test can have a local copy of what it needs. [20:16] well, the config doesn't exist _at all_ in the php package, so there's no a2enconf or whatever for making php-fpm receive httpd input [20:17] You have some way of making it work, right? [20:17] If you can script that way, then the test is just that script. [20:17] I wrote a config file and dropped it onto my local xenial install [20:17] but it might make sense to actually provide it as something people could use, too [20:17] Sure [20:17] that's what I need your advice on [20:17] I don't know how to go about this [20:18] Until it provides it, you can write the test as you like. Either "cat > /foo < ah [20:18] well, then, I guess I'll do that [20:18] I'll prepare a git patch for you in a bit [20:18] The test should declare "needs-root breaks-testbed" and the dep8 runner will do the right thing. [20:18] (revert the VM or container before running the next test, etc) [20:18] ah [20:19] If it makes sense for the package to ship some configs, then that'd probably be best to send in a patch to Ondrej, and coordinate with him on what he thinks is suitable, etc. === salem_ is now known as _salem === mnepton is now known as mneptok [20:51] robert_ancell: you really want to MIR AppStream itself: https://packages.debian.org/source/sid/appstream [20:52] ximion1, ta, will do that one too [20:52] if Protobuf and Qt5Core are in main for Ubuntu, it should have no dependencies on stuff which isn't already there [20:52] let me know if if you need any help :) [21:07] Meanwhile APT 1.2/1.2.1 and squashfs-tools are still in depwait due to lz4 MIR bug 1531923 [21:07] bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed] https://launchpad.net/bugs/1531923 [21:50] mdeslaur, nope. it's strange it build on debian but not on ubuntu. Even if I, e.g. disable pie too. And i don't see anything obvious. I shall engage upstream on that. [21:50] mdeslaur, well porters in question. === popey_ is now known as popey