| cpaelzer | good morning | 06:05 |
|---|---|---|
| pitti | Good morning | 06:18 |
| pitti | cjwatson: looking | 06:21 |
| pitti | cjwatson: fix pushed, I'll watch the next wily run | 07:09 |
| === bdrung_ is now known as bdrung | ||
| === Saviq_ is now known as Saviq | ||
| === uaa is now known as Guest5838 | ||
| === marlinc_ is now known as marlinc | ||
| === Guest5838 is now known as damascene | ||
| infinity | xnox: okular/s390x is holding up a fairly large transition due to its autopkgtest regression. None of our kubuntu folks have s390x hardware access, would it be possible for you to look into what's failing? | 07:21 |
| pitti | do we even care? | 07:22 |
| pitti | (we could just ignore the s390x failure) | 07:22 |
| pitti | infinity, cjwatson: ok, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is back | 07:26 |
| ricotz | pitti, good morning :) | 07:27 |
| ricotz | pitti, do you have a moment to take a look at https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1556651 | 07:28 |
| ubottu | Launchpad bug 1556651 in plank (Ubuntu) "FFe: Update plank to 0.11.0" [Undecided,Confirmed] | 07:28 |
| pitti | smoser, rbasak: nova-lxd wants to go from main to universe, is that intended? | 07:30 |
| dholbach | good morning | 07:33 |
| pitti | ricotz: what about it? | 07:34 |
| pitti | it's already approved | 07:35 |
| ricotz | pitti, ah, flexiondotorg's comment is already sufficient | 07:37 |
| yofel | pitti: from the kubuntu side: feel free to ignore s390x | 08:01 |
| === cpaelzer_ is now known as cpaelzer | ||
| yofel | and I don't understand autopkgtest yet again | 08:02 |
| yofel | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libkdegames | 08:02 |
| yofel | is kept back because yet another build for an outdated version (tmp)failed | 08:02 |
| yofel | where did the libkdegames trigger even come from?!? | 08:02 |
| yofel | there was no change for that | 08:03 |
| pitti | I reran these failures earlier today | 08:03 |
| pitti | yofel: err -- Depends: kpimtextedit kio (not considered) | 08:03 |
| pitti | sorry, wrong paste | 08:03 |
| pitti | libkdegames (4:15.08.2-0ubuntu1 to 4:15.12.1-0ubuntu1) | 08:03 |
| pitti | there sure is an update of libkdegames | 08:03 |
| yofel | yes, but I uploaded rebuilds of the games for the lib transition. It even shows those builds in the autopackagetest logs. But after that it went and build another test set for the previous versions | 08:04 |
| yofel | why? | 08:04 |
| pitti | sorry, I don't understand the question | 08:04 |
| pitti | that s390x test should either succeed on the retry, or we ignore it (if something is broken on s390x, and we don't care) | 08:05 |
| pitti | either way, once this knetwalk 390x test goes green or yellow, libkdegames will become a valid candidate | 08:05 |
| yofel | take e.g. http://autopkgtest.ubuntu.com/packages/k/knetwalk/xenial/s390x/ | 08:06 |
| yofel | it did a build because of knetwalk 4:15.12.1-1ubuntu2 using 4:15.12.1-1ubuntu2 -> OK | 08:06 |
| yofel | then, *after* that, it went and build the test again using 4:15.12.1-1ubuntu1 -> why?!? | 08:06 |
| pitti | well, it was tested once for the new knetwalk and once for the new libkdegames | 08:06 |
| pitti | and since the latter is a transition, it had to use the knetwalk from -proposed as well | 08:06 |
| * pitti is still confused what your question is | 08:07 | |
| yofel | I don't get why it built an older version after a newer one. After all ubuntu2 should've been in proposed at that time, until the publisher delayed things | 08:07 |
| yofel | *unless | 08:08 |
| pitti | we test packages in -proposed in isolation (as much as possible) | 08:08 |
| pitti | https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/038985.html | 08:08 |
| yofel | well, then maybe I just don't get why britney is showing what it does. | 08:12 |
| yofel | libkdegames cannot migrate with knetwalk ubuntu1, it requires ubuntu2. The autopkgtest for ubuntu2 was OK, but then the one for ubuntu1 failed. | 08:12 |
| yofel | So while britney should be able to migrate libkdegames just fine, it's now not considering it because a test for a version that's superseded and doesn't help failed. | 08:12 |
| yofel | guess I'll read the docs linked from there later, thanks | 08:12 |
| pitti | yofel: knetwalk ubuntu2 wasn't in proposed yet when that test ran for libkdegames | 08:13 |
| pitti | yofel: the queued retry will use ubuntu2 of course | 08:13 |
| yofel | ok, thanks | 08:14 |
| pitti | stgraber, smoser: hmm, having lxd preinstalled on cloud images isn't helpful -- the default ubuntu user can't actually use it as it's not in the lxd group; will cloud-init get changed for that too? | 08:15 |
| rbasak | pitti: that's one for zul or jamespage I think. | 08:32 |
| rbasak | jamespage: see 07:30 above. | 08:33 |
| doko | argh, tcl/tk 8.5 in main again? | 08:38 |
| doko | hmm, never demoted | 08:38 |
| doko | xnox, pitti: any opinion on the cmake update? | 08:54 |
| pitti | doko: I'm not opposed per se, but we'd need a test rebuild of the rdepends, and there are ~ 1500 of them.. | 08:55 |
| pitti | doko: and there's an ubuntu delta "Revert back to 3.2.2, build issues on armhf, arm64 and powerpc." which does not have much further details; bug 1534263 has open questions about that | 08:56 |
| ubottu | bug 1534263 in cmake (Ubuntu) "[FFe] [merge request] Import cmake-3.4 series to Ubuntu Xenial 16.04LTS" [High,Incomplete] https://launchpad.net/bugs/1534263 | 08:56 |
| doko | yeah, I can't remember ... | 08:56 |
| LocutusOfBorg | pitti, s/3.4/3.5? :( | 09:14 |
| LocutusOfBorg | :) | 09:14 |
| pitti | LocutusOfBorg: I don't know, the bug says 3.4 | 09:15 |
| LocutusOfBorg | 3.5 uploaded some hours ago in debian | 09:15 |
| caribou | When loading a new package to stable releases (Universe), is there a specific process or it just a normal SRU ? | 09:17 |
| caribou | I'm loading a new mstflint4 package for the mstflint source pkg which has the Xenial version | 09:17 |
| pitti | l | 09:17 |
| doko | Pharaoh_Atem, any idea about the remctl ftbfs? | 09:33 |
| juliank | mvo_: I disabled SHA1 support in APT yesterday, and want to get this into xenial; as that's going to be supported until 2021, and who knows how secure SHA1 is by then. | 09:37 |
| LocutusOfBorg | Hi, can anybody please explain to me "ImplicitPointerConversions" issues? | 09:38 |
| LocutusOfBorg | https://launchpadlibrarian.net/247604891/buildlog_ubuntu-xenial-amd64.ipmitool_1.8.16-1_BUILDING.txt.gz | 09:38 |
| juliank | This does not yet require GPG signatures to use stronger hashes, though. | 09:38 |
| LocutusOfBorg | "Function `getpass' implicitly converted to pointer at ipmi_user.c:486" | 09:38 |
| LocutusOfBorg | I see the header file included | 09:38 |
| juliank | that seems broken | 09:39 |
| LocutusOfBorg | Adding the prototypes inside the .c files works, but seems obviously wrong to me | 09:39 |
| pitti | stgraber: http://autopkgtest.ubuntu.com/packages/l/lxc/trusty/ppc64el/ → it seems we lost the ppc64el images on https://images.linuxcontainers.org/images/ubuntu/trusty/ ? | 09:42 |
| === shuduo is now known as shuduo-afk | ||
| juliank | LocutusOfBorg: That seems somewhat crazy :/ | 09:45 |
| LocutusOfBorg | indeed | 09:46 |
| juliank | Same for the strtok_r things | 09:46 |
| LocutusOfBorg | "index" is a misssing strings.h include | 09:47 |
| LocutusOfBorg | but the others... are something worrying | 09:47 |
| juliank | LocutusOfBorg: Even with the missing include, it should not convert the *function* to a pointer. The return type would be considered int, and thus trigger an implicit conversion (int->ptr) warning | 09:49 |
| juliank | Unless the 'Function `index' implicitly converted to pointer at ipmi_sel.c:2397' is misleading and means function result | 09:49 |
| === essembe is now known as sbeattie | ||
| doko | pitti, I assume the ruby-defaults triggered autopkgtest failures need a walk through, and maybe rebuilds against the -proposed pocket ... | 10:05 |
| pitti | doko: yes, I already requeued some tests this morning | 10:05 |
| doko | ahh, fine | 10:05 |
| pitti | doko: I'm waiting for the current backlog to settle down, then do my usual walk through excuses | 10:05 |
| pitti | doko: there's also some s390 fallout to sort out and stuff | 10:06 |
| pitti | but queues were quite full, and I just pushed a workaroudn for bug 1556175, so it'll still take a bit | 10:06 |
| ubottu | bug 1556175 in isc-dhcp (Ubuntu) "networking.service hangs on shutdown -- killing dhclient has no effect any more" [High,Triaged] https://launchpad.net/bugs/1556175 | 10:06 |
| doko | pitti, s390x should be fixed now with the new ruby2.3 upload (-4ubuntu1) | 10:06 |
| pitti | doko: oh, my retry from last night worked alredy | 10:07 |
| doko | lamont wanted to work on the dhclient issue (re-introducing the second set of bind9 libs) | 10:07 |
| pitti | ah no, it didn't; /me kills the hanging s390 build of ubuntu1, indeed | 10:07 |
| pitti | doko: yes, I talked to him on Friday; seems it's a known problem/known solution, just SMP | 10:08 |
| pitti | "Rests not run on $(DEB_HOST_ARCH)" :) | 10:08 |
| doko | mehh | 10:09 |
| infinity | LocutusOfBorg: The log makes it pretty clear that it's an implicit declaration. So "the header is included" can't be the whole story. | 10:09 |
| pitti | doko: resting is always good! | 10:09 |
| smb | pitti, kinda both related to the combined bind9 lib which moved to use threads | 10:10 |
| pitti | smb: yes, I know now; just took me a while on Friday to track down | 10:10 |
| smb | pitti, Sorry you had to spend time there again. I try to get people aware of this (and the complete failure to run as a daemon) for a while now | 10:12 |
| LocutusOfBorg | infinity, I hthink I got it | 10:13 |
| LocutusOfBorg | damn old Makefile.am | 10:13 |
| infinity | LocutusOfBorg: s/std=c99/std=gnu99/? | 10:13 |
| LocutusOfBorg | they used INCLUDES instead of AM_CPPFLAGS | 10:13 |
| infinity | LocutusOfBorg: std=c99 skips get _USE_MISC-wrapped getpass in unistd.h | 10:16 |
| LocutusOfBorg | ok indeed | 10:16 |
| LocutusOfBorg | I tried c89, but yes, gnu99 is the good one | 10:17 |
| infinity | Not sure if that's true for the other implicit declarations, but easy enough to check. | 10:17 |
| LocutusOfBorg | I did put some #error in string.h to see where and when they were used | 10:17 |
| infinity | LocutusOfBorg: Looks like just s/std=c99/std=gnu99/ in configure.ac and configure (or just .ac if the package autoreconfs) will DTRT. | 10:19 |
| infinity | But I'm looking at this blind. :P | 10:19 |
| * infinity goes middle of the night hamburger hunting. | 10:19 | |
| LocutusOfBorg | :) | 10:19 |
| LocutusOfBorg | infinity, if it works, I'll give credits to you ;) | 10:20 |
| LocutusOfBorg | your "don't know" is order of magnitude better of my "i'm sure" | 10:20 |
| LocutusOfBorg | infinity, strange enough, running autoreconf might be also a fix | 10:24 |
| LocutusOfBorg | I'll do some more testing | 10:24 |
| pitti | hm, new ruby2.3 and new perl in about half an hour, the test queues won't get any shorter today :) | 10:33 |
| ogra_ | and new kde (or is that through already ?) | 10:34 |
| doko | and php7 not yet migrated ... | 10:37 |
| pitti | doko: ah, they found some actual crashes like ruby-awesome-print (looksl like debian bug 816161) | 10:39 |
| ubottu | Debian bug 816161 in src:ruby-awesome-print "ruby-awesome-print: FTBFS: Aborted (core dumped)" [Serious,Open] http://bugs.debian.org/816161 | 10:39 |
| pitti | hm, two reverse build deps | 10:39 |
| pitti | ogra_: it didn't land yet, but testing for it is mostly through (some regressions, though) | 10:39 |
| cjwatson | pitti: wily autopkgtest> thanks | 10:42 |
| * pitti goes through the KDE and some older ruby failures | 10:42 | |
| Laney | pitti: thinking about skipping okular/s390x | 10:43 |
| pitti | Laney: yep, that was one I was about to add too | 10:43 |
| pitti | Laney: it was briefly discussed this morning here | 10:43 |
| Laney | cool | 10:43 |
| Laney | pitti: is it package/arch/version? | 10:44 |
| pitti | Laney: yes, something like okular/all/s390x | 10:44 |
| Laney | pitti: so package/version/arch? :) | 10:44 |
| pitti | Laney: err, sorry for confusion; yes, there's some precedent in current hints | 10:45 |
| Laney | pitti: yeah, I was confused a bit | 10:45 |
| Laney | you have a diffoscope hint which is p/a/v but I guess just a braino :) | 10:45 |
| pitti | Laney: thanks, fixed locally | 10:46 |
| Laney | nice | 10:46 |
| pitti | Laney: I'm queueing a few hints ATM, I'll add okular too | 10:46 |
| Laney | already done oular | 10:46 |
| * Laney wants poppler to go through | 10:46 | |
| === adrian|sick is now known as adrian | ||
| === lilstevie_ is now known as lilstevie | ||
| pitti | Laney: poppler still has some issues: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 11:17 |
| pitti | * amd64: libokular-perl, libsmokekde-dev, libsmokeokular3, okular-backend-odp | 11:18 |
| pitti | ^ and okular too | 11:18 |
| Laney | ok | 11:18 |
| Laney | I needed okular to be a candidate to see that | 11:18 |
| Laney | something suspicious is going on with my desktop | 11:18 |
| Laney | schroot -x xenial-amd64 ... | 11:18 |
| Laney | this shouldn't take 20 seconds | 11:18 |
| ogra_ | it is monday though | 11:19 |
| Laney | s/-x/-c/ | 11:19 |
| Laney | ogra_: you mean if I pour coffee through this here vent..? | 11:20 |
| ogra_ | yeah, definitely ... for me that always helps :) | 11:20 |
| LocutusOfBorg | infinity, it fixes the issue, but not on s390x, and I don't have access to porterboxes on ubuntu | 11:24 |
| infinity | LocutusOfBorg: That s/INCLUES/AM_CPPFLAGS/ change makes literally no difference, FWIW. | 11:33 |
| LocutusOfBorg | true | 11:35 |
| LocutusOfBorg | actually to check that change I had to autoreconf, and that was the fix :) | 11:36 |
| Laney | pitti: uploaded smokekde - that should be it | 11:36 |
| pitti | Laney: yay, thanks | 11:37 |
| infinity | LocutusOfBorg: I don't see autoreconf having fixed anything either (except for it propagating the std=gnu99 from configure.ac, which you could have done manually by patching configure) | 11:37 |
| infinity | LocutusOfBorg: Not that autoreconf is necessarily a bad idea anyway. | 11:38 |
| infinity | LocutusOfBorg: Less sure of the continued s390x breakage. That's weird. I see 26 implicit declarations in that build log, most of which I wouldn't think should be. | 11:39 |
| infinity | LocutusOfBorg: Oh. Same on powerpc, though. It just doesn't fail because we only fail pointer conversions on 64-bit. | 11:41 |
| infinity | LocutusOfBorg: So, could be some endian oops somewhere. | 11:41 |
| infinity | Or. No. | 11:42 |
| * infinity scratches his head. | 11:42 | |
| infinity | This source is a mess. | 11:42 |
| LocutusOfBorg | powerpc is fine to me | 11:42 |
| infinity | Actually, it's all busted on every arch still. | 11:42 |
| infinity | LocutusOfBorg: Testing something here. | 11:50 |
| LocutusOfBorg | thanks infinity :) | 11:53 |
| juliank | I'm planning to release APT 1.2.7 today without SHA1 support. This might break some third-party repositories, for example, Google Chrome is definitely broken (only MD5Sum and SHA1 fields; also signed with a 1024 bit DSA key...). Can we agree on having that in xenial? | 12:11 |
| juliank | I'm not sure how much this tightens up security with gpg still accepting SHA1-based signatures, but it still seems like a good idea to do it. | 12:12 |
| zequence | pitti: Ok, we're dropping dvdstyler, and replacing it with devede | 12:13 |
| === kyrofa_ is now known as kyrofa | ||
| rbasak | For mvo_ or someone from the security team perhaps? mdeslaur? ^^ | 12:13 |
| juliank | For Google, I have informed both the Chrome and Security teams about the issue with their repository | 12:14 |
| mdeslaur | juliank: will it still work with 1024 bit keys? | 12:15 |
| mdeslaur | juliank: or is it just md5/sha1? | 12:15 |
| mdeslaur | (that is being dropped) | 12:15 |
| cjwatson | juliank: Re bug 1556666, can I confirm that it is your belief that the digests on the primary Ubuntu archive are OK? (I believe this to be the case, but it's worth checking in this context) | 12:15 |
| ubottu | bug 1556666 in Launchpad itself "PPA (In)Release files use SHA1 digests for GPG signature" [Undecided,New] https://launchpad.net/bugs/1556666 | 12:15 |
| juliank | mdeslaur: GPG signatures are entirely unaffected. This affects only the fields within the Release/Packages/Sources files | 12:15 |
| juliank | cjwatson: I believe so, yes | 12:16 |
| cjwatson | Good. It's probably just a matter of passing --digest-algo SHA512 then, as we do there | 12:16 |
| juliank | mdeslaur: We can easily switch off SHA1 for GPG signatures in an SRU if a stronger threat exists. | 12:16 |
| juliank | (That would also practically turn of DSA keys) | 12:16 |
| cjwatson | Oh, except I bet we do this with gpgme, ugh | 12:17 |
| cjwatson | hatred | 12:17 |
| juliank | cjwatson: Just as a note, the PPAs also would not be affected by APT 1.2.7 | 12:17 |
| juliank | As that's the GPG signature, and we're not rejecting weak stuff there yet (GPG rejects md5 itself). | 12:18 |
| cjwatson | juliank: That was my understanding from what you said, but thanks for confirming | 12:18 |
| juliank | The point is: Disabling our side of the SHA1 support was a *small* bit of work, and it's safer to do that now than in the next 5 years. | 12:19 |
| cjwatson | The main difficulty with this sort of thing around PPAs is upgrading keys (https://bugs.launchpad.net/launchpad/+bug/1331914 etc.), but I think we can upgrade the digests without having to get into that. | 12:19 |
| ubottu | Launchpad bug 1331914 in Launchpad itself "Allow users to re-generate a PPA signing key" [High,Triaged] | 12:19 |
| juliank | If a strong threat pops up, disabling SHA1 for our gpgv use would be just adding two lines in a config file. | 12:19 |
| doko | Mirv, could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html (libqt5xcbqpa5)? | 12:34 |
| cjwatson | uh. as far as I can tell, the only way to pass --digest-algo SHA512 through gpgme is to give it a wrapper gpg program | 12:34 |
| cjwatson | I hate software | 12:34 |
| juliank | cjwatson: Or create a gpg.conf with the option and set home_dir accordingly | 12:35 |
| cjwatson | Yeah, also ridiculously cumbersome | 12:36 |
| cjwatson | It really ought to have library-level control of this | 12:36 |
| juliank | GPG is a total clusterfuck | 12:38 |
| juliank | It should just default to sane values already | 12:39 |
| juliank | and warn about SHA1 signatures | 12:39 |
| juliank | cjwatson: Also: No idea whether the self-sigs of the keys use SHA1 | 12:39 |
| === Pici` is now known as Pici | ||
| juliank | then again, nobody sees the UIDs anyway, so I don't think it's much of a problem. | 12:41 |
| cjwatson | They probably do at the moment. A fix in the proper place in lp.services.gpg.handler would take care of both. | 12:43 |
| cjwatson | Oh look, we already use a custom gpg.conf | 12:44 |
| smoser | pitti, ubuntu that commit is in trunk now (ubuntu in lxd group) | 13:01 |
| smoser | will upload that today. | 13:01 |
| smoser | rcj took care of that for us. thanks! | 13:02 |
| pitti | smoser: cool, thanks | 13:05 |
| CustosL1men | does ubuntu have something like rhel scl ? https://www.softwarecollections.org/en/about/ | 13:08 |
| Mirv | doko: thanks for reminding about it, I will take care of those | 13:12 |
| Mirv | I had a note about it but it got buried | 13:12 |
| rbasak | CustosL1men: yes, see Ubuntu Snappy. But this is a conversation for #ubuntu really, not #ubuntu-devel. | 13:13 |
| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| rbasak | smoser: I just imported open-iscsi into lpusdp for matsubara, but then realised that loses the broken down delta. | 14:08 |
| rbasak | Do you want to replace it with a broken down delta if you have it? | 14:08 |
| smb | lamont, Not sure how much time you had for looking into bind9. Not sure of how much help I could be but at least I'd try. I had a bit of looking into it this morning and it feels like reverting could rather be modifying the udeb build done now. Though the details feel erm complicated. | 14:10 |
| === Guest12587 is now known as mfisch | ||
| === mfisch is now known as Guest62254 | ||
| === Guest62254 is now known as mfisch | ||
| lamont | smb: agreed | 14:15 |
| lamont | I have much of it done, but need to smack the build around a bit to fix the current ftbfs | 14:16 |
| lamont | and so, when lunch, or a test run comes, I'll have 40 min or so to fight with it | 14:16 |
| lamont | the test run will come first, and fairly soon | 14:16 |
| smoser | rbasak, i have my commits | 14:16 |
| smoser | but not sure what i'm supposed to do with them. | 14:17 |
| smb | lamont, ok, so I think the best was to help would be to take the resulting libs and try isc-dhcp builds and the resulting binaries. | 14:18 |
| lamont | smb: I would love that | 14:19 |
| smoser | rbasak, pushed my most recent workign delta to https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi | 14:19 |
| rbasak | Looking | 14:19 |
| lamont | Once I get it to build, I'll toss it at my ppa and let you know | 14:19 |
| lamont | smb: ^^ | 14:19 |
| smoser | 'working' there is the working-2.0.873+git0.3b4b4500-13ubuntu1 | 14:19 |
| smb | lamont, Ok, cool. Thanks | 14:20 |
| smoser | and working-<long> is 14ubuntu1 | 14:20 |
| Odd_Bloke | I'm talking to someone who wants to install from ISO and end up with the original trusty kernel; I've found http://old-releases.ubuntu.com/releases/14.04.0/, but I'm not wild about pointing them at something with old-releases in the URL. | 14:21 |
| rbasak | smoser: first let's settle the debian/sid branch. I just pushed that to lpusdp with the full history, so let's just use that. | 14:21 |
| Odd_Bloke | Is there another option? (We support the 14.04.0 kernel until trusty EOL, right?) | 14:21 |
| rbasak | smoser: otherwise you could have created it by using git-dsc-commit on top of the existing debian/sid branch, and then pushing that to lpusdp with the import/<version> tag. | 14:22 |
| rbasak | smoser: next, can you rebase working-<long> on top of that new debian/sid branch that is now in lpusdp? | 14:22 |
| rbasak | When done, you can tag that as upload/<version> to donate that that is the tree that you uploaded, and (force) push that as ubuntu/devel. | 14:23 |
| rbasak | smoser: does that make sense? In lpusdp, debian/sid just gets imports added as commits to the end, each tagged as import/<version> and the branch just moves along. | 14:24 |
| rbasak | smoser: and ubuntu/devel is always based on debian/sid + commits, either import/<version> or the uploaders commits with a final upload/<version> | 14:25 |
| rbasak | smoser: ubuntu/devel currently gets force pushed after an Ubuntu "merge". cjwatson convinced me to do something a little different there but we've not implemented that yet. | 14:25 |
| pitti | mvo_: please rename the "snap" binary in the test too: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snap | 14:26 |
| pitti | yofel: a lot of KDE updates landed now, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kopete is one of the few remaining actual issues | 14:27 |
| pitti | and kwin | 14:27 |
| smoser | Odd_Bloke, i dont know that there is a answer to your question. | 14:33 |
| smoser | other than old-releases. :-( | 14:34 |
| Odd_Bloke | It does mean that I can make the "really really make sure you're upgrading" point more forcefully, at least. :p | 14:34 |
| yofel | pitti: thanks! | 14:34 |
| xnox | Odd_Bloke, use d-i installer, it offers a choice of kernels to install, but you need .0 d-i image for trusty original kernel. | 14:35 |
| xnox | Odd_Bloke, also at cdimage we have original stack images files. | 14:35 |
| yofel | Mirv: were there any qtopengl dep changes that would cause https://launchpad.net/ubuntu/+source/kalgebra/4:15.12.1-0ubuntu2/+build/9344094 ? (No-change rebuild that previously built fine) | 14:35 |
| yofel | or do I need to look somewhere else? | 14:35 |
| xnox | Odd_Bloke, i believe ...1 release are also still on original stacks (.2 is the first one to get later stack) | 14:35 |
| smoser | xnox, i dont think it offers a selection of kernel | 14:35 |
| xnox | Odd_Bloke, http://cdimage.ubuntu.com/ubuntu/releases/ there is | 14:36 |
| xnox | 14.04.1, 14.04.2, 14.04.3, 14.04.4 -> original, +1, +2, +3 stacks. | 14:36 |
| xnox | smoser, it does, at lower debconf priority. | 14:36 |
| === henrix_ is now known as henrix | ||
| Odd_Bloke | xnox: If you follow the cdimage links through, you can't get the .{1,2} images; you still end up with only .3 and .4 files listed. | 14:37 |
| xnox | http://cdimage.ubuntu.com/ubuntu/releases/14.04.1/release/ is supposed to be .1 images archive. | 14:37 |
| xnox | if not, it's a bug. | 14:37 |
| Odd_Bloke | xnox: Cool, I think it's a bug then; where shall I file it? | 14:37 |
| xnox | indeed it is. | 14:37 |
| xnox | Odd_Bloke, ubuntu-cdimage project, assign to infinity. | 14:38 |
| Odd_Bloke | xnox: Cool, thanks. | 14:38 |
| xnox | Odd_Bloke, however, they may have been moved intentionally due to disk space constraints. | 14:38 |
| xnox | Odd_Bloke, i do see .0, .1, .2 at http://old-releases.ubuntu.com/releases/14.04.1/ | 14:38 |
| Odd_Bloke | Yeah, that's what I was going to use; just didn't like it being at "old-releases" (which suggests "may disappear at any time without notice" to me :p). | 14:39 |
| xnox | Odd_Bloke, old-releases is long term for-ever archive of ubuntu. that one does not disapear ever. | 14:39 |
| Odd_Bloke | OK, cool. | 14:39 |
| xnox | it has Warty Warthog =) | 14:40 |
| xnox | and e.g. the title page says it right: | 14:40 |
| xnox | http://old-releases.ubuntu.com/releases/ | 14:40 |
| xnox | The following old releases of Ubuntu are available: | 14:40 |
| xnox | <old stuff> | 14:40 |
| xnox | The following releases are also available which have been superseded by later point releases (the current point release is available on releases.ubuntu.com as usual): | 14:40 |
| xnox | Ubuntu 12.04.4 LTS (Precise Pangolin) | 14:40 |
| Mirv | yofel: nothing I know of. no recent mesa uploads, the only qtbase change was enabling ALSA support (http://launchpadlibrarian.net/247469048/qtbase-opensource-src_5.5.1+dfsg-15ubuntu1_5.5.1+dfsg-16ubuntu1.diff.gz) | 14:40 |
| xnox | Ubuntu 14.04.2 LTS (Trusty Tahr) | 14:40 |
| yofel | Mirv: ok thanks, then maybe it's a build ordering issue on our side | 14:41 |
| mvo_ | pitwill do, sorry for the trouble | 14:41 |
| pitti | mvo_: thanks | 14:43 |
| pitti | mvo_: no trouble, just playing relay :) | 14:43 |
| smoser | rbasak, ok. i think i'm good now. | 14:58 |
| smoser | http://paste.ubuntu.com/15384413/ | 14:59 |
| smoser | my local 'ubuntu/devel' branch is ahead of lpusdp/ubuntu/devel by my logical delta changes | 14:59 |
| smoser | and upload/2.0.873+git0.3b4b4500-14ubuntu1 is tagged | 15:00 |
| smoser | and upload/2.0.873+git0.3b4b4500-14ubuntu1 is tagged | 15:01 |
| smoser | so i think i just need to git push --force lpusdp ubuntu/devel | 15:02 |
| pitti | doko: argh, soooo close! http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-defaults | 15:16 |
| smoser | rbasak, ^ please let me know if that isnt right. | 15:20 |
| === maxb_ is now known as maxb | ||
| pitti | nacc: hmm, do you know why php 7 in xenial-proposed is in this big sorryness of uninstallability? | 15:26 |
| nacc | pitti: yeah | 15:27 |
| nacc | pitti: so the issue is we bumped php-defaults, but we need to dump php7.0 too ... but i spent last week just getting the split done. So I can post debdiffs for the newer merge | 15:28 |
| nacc | s/dump/bump/ | 15:28 |
| nacc | pitti: as the new php-defaults requires a newere php7.0 than we have | 15:28 |
| pitti | nacc: ah, so you're on it, thanks | 15:28 |
| doko | pitti, but +100 ruby packages migrated | 15:28 |
| pitti | doko: yeah, and poppler, most of kde and some others too | 15:29 |
| pitti | doko: hopefully ruby-defaults in the next round, armhf queue is back at 0 | 15:29 |
| nacc | slangasek: my last two debdiffs for php-imagick & imagemagick should allow all the tests on i386 & s390x to pass (LP: #1549942) | 15:29 |
| ubottu | Launchpad bug 1549942 in ImageMagick "php-imagick failing autopkgtests" [Unknown,New] https://launchpad.net/bugs/1549942 | 15:29 |
| pitti | doko: I stand corrected, it's miggrating right now | 15:30 |
| pitti | nacc: yay, I'll look at/sponsor them, thanks | 15:31 |
| pitti | nacc: I was just adding ignores for php-imagick, as slangasek already dropped them (I thought prematurely, but I guess not then) | 15:32 |
| doko | nacc, pitti: is this the same issue? https://launchpadlibrarian.net/247846239/buildlog_ubuntu-xenial-amd64.ruby-riddle_1.5.12-3_BUILDING.txt.gz | 15:33 |
| pitti | doko: very likely | 15:33 |
| nacc | pitti: yeah, we had decided it was safe to ignore both (the upstream maintainer says that test is unreliable). But I think the proper fix to imagemagick is included now | 15:33 |
| nacc | doko: yep | 15:33 |
| nacc | ok, will get those debdiffs done ASAP | 15:33 |
| pitti | nacc, slangasek: imagick and php-imagick sponsored, thanks! | 15:38 |
| nacc | pitti: thanks, i'll keep an eye on the tests! | 15:39 |
| doko | nacc, yare you working on the php7.0 merge, or do you need help? | 15:42 |
| nacc | doko: i had two questions for you, actually, on merges the server team would like to get done: 1) is it worth merging ldb to 1.1.26? 2) I think we can sync pep8? I can file that bug, just wanted to check with you first. Debian has some more updated tests in 1.7.0-1, but otherwise the biggest diff is debian doesn't have build/lib/pep8.py ? | 15:42 |
| nacc | doko: working on it now | 15:42 |
| doko | nacc, ldb: have it on your radar; the python3 bindings patch is not yet merged | 15:46 |
| doko | if it is, you can sync it. but maybe it's worth having the subminor version | 15:47 |
| doko | now synced talloc and tdb | 15:47 |
| === rw is now known as dax | ||
| doko | nacc, synced pep8 too | 15:49 |
| nacc | doko: thanks! | 15:50 |
| barry | doko: hahaha! thanks for syncing pep8. i was just working on a -2 and fixing up the repo. was gonna sync also, but will do that after i upload -2 to unstable | 15:52 |
| barry | doko: flake8 is next on my list | 15:53 |
| nacc | slangasek: sorry, didn't look at your diff until just now, but why did the stuff in debian/control move around? also, it doesn't match the changelog anymore, as -imap, -interbase, etc aren't in d/control? | 16:12 |
| rbasak | smoser: what's the parent of c5109da36b887b39840ab5e60022a92b38c163ca? | 16:13 |
| smoser | rbasak, http://paste.ubuntu.com/15384903/ | 16:15 |
| rbasak | smoser: yes that looks right. I would use git push --no-tags though, since otherwise you'll end up pushing your "working" tag etc. | 16:16 |
| rbasak | You can push the import/upload tags explicitly. | 16:16 |
| smoser | how do i do that ? | 16:16 |
| rbasak | git remote add lpusdp lpusdp:open-scsi; git push lpusdp --no-tags +ubuntu/devel upload/2.0.873+git0.3b4b4500-14ubuntu1 | 16:17 |
| pitti | nacc: ah, I figure php-imagick needs to wait for that php7.0 merge too? (FTBFS due to uninstallability as well) | 16:17 |
| nacc | pitti: yep | 16:18 |
| nacc | pitti: pretty much all of php will :/ | 16:18 |
| smoser | rbasak, done. thanks. | 16:19 |
| rbasak | smoser: thanks! | 16:19 |
| rbasak | matsubara: ^^ | 16:19 |
| matsubara | thanks rbasak and smoser! | 16:20 |
| stgraber | pitti: not sure if smoser replied, but I think the plan was to have cloud-init add the user to the lxd group when it makes sense (when the user is an admin or whatever similar logic exists in there) | 16:20 |
| pitti | stgraber: heh did; he said the fix is in git now, and will be uploaded soon; thanks | 16:21 |
| smoser | stgraber, i just uploaded earlier. | 16:21 |
| pitti | cheers | 16:21 |
| stgraber | pitti: and yeah, we haven't built ppc64el images in quite a while so I cleaned up all the seriously oudated, full of security issues images on Friday | 16:21 |
| smoser | pitti, ^ . its in -proposed now. | 16:21 |
| smoser | b asically the default user is in 'lxd' | 16:21 |
| smoser | so lxd group gets added for him if nto there. | 16:21 |
| stgraber | pitti: we have new ppc64el, powerpc and s390x VMs that we can use now, I just need to set them up to talk to our Jenkins | 16:21 |
| pitti | stgraber: ah, nice! apw complained about the regressing tests again, as on ppc64el there are no images any more (for any release) | 16:22 |
| pitti | stgraber: awesome, s390x too | 16:22 |
| stgraber | pitti: yeah, I just noticed. I'll try to setup those jenkins runners today. In theory we can also build Debian images on those 3 arches then which may be useful to some | 16:22 |
| apw | stgraber, yeah we seem to have regressed in terms of images for all series there ... i filed you a shiney bug against lxc | 16:23 |
| apw | stgraber, though we have assumed it is a lack of images not functional regressions | 16:23 |
| stgraber | apw: yeah, so long as the only errors you're getting is "no image found", that's all fine | 16:23 |
| stgraber | I should really make our image publisher wipe images that are outdated rather than do it manually every so often, I really didn't like seeing images that still contained vulnerable libssl :) | 16:24 |
| apw | no image found indeed | 16:25 |
| pitti | stgraber: would it make sense to treat "no image found" as "skip"? | 16:27 |
| stgraber | pitti: yeah, that would make sense | 16:27 |
| === tyhicks` is now known as tyhicks | ||
| === francisco is now known as Guest95587 | ||
| === AdmWiggin is now known as tianon | ||
| balloons | mpt, ping | 17:07 |
| nacc | slangasek: so i think what happened is that you ended up editing the d/control files for both src:php7.0 and src:php-universe-source7.0 to not include binary targets that aren't built for those packages. Do you want to keep that delta? I will document it in the new merge, if so | 17:08 |
| Logan | Laney: wanted to apologize for uploading this: https://launchpad.net/ubuntu/+source/banshee/2.9.0+really2.6.2-3ubuntu2 - didn't realize until after the fact that you were working on a fix in Debian's VCS in an Ubuntu branch | 17:17 |
| Logan | Laney: I usually just assume that the VCS in debian/control is just for Debian :/ | 17:17 |
| Laney | Logan: no worries, but it would be good if you could pick up those fixes | 17:19 |
| Laney | thanks for fixing it! | 17:19 |
| sladen | anyone know what the heck these 'PlusServer GmbH' empty mailings are | 17:49 |
| sladen | being sent to ubuntu-security-announce@lists.ubuntu.com | 17:49 |
| sladen | sbeattie: are they generated bounces/misconfiguration in response to your mailings? | 17:51 |
| sbeattie | sladen: yes, I accidentally moderated them through. Sorry for the noise. | 17:52 |
| ogra_ | just charge them for the free ads they got ;) | 17:52 |
| sbeattie | heh, well, maybe having them spammed everywhere will get them to stop it. | 17:53 |
| sbeattie | (we get them for every single USN we publish) | 17:57 |
| === uaa is now known as Guest97616 | ||
| ginggs | Anyone from ubuntu-release please look at LP: #1555586 ? | 18:12 |
| ubottu | Launchpad bug 1555586 in lazarus (Ubuntu) "FFe: Sync lazarus 1.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1555586 | 18:13 |
| doko | nacc, do you have updated packages, or do you want to wait for slangasek to sponsor these? | 18:54 |
| Chipaca | popey: wrt the kswap thing (on twitter :) ) does anything show up in iotop? | 19:02 |
| === Guest97616 is now known as damascene | ||
| nacc | doko: i'm just building & testing them now | 19:12 |
| nacc | doko: sorry, had to make sure i understood slangasek's changes | 19:13 |
| nacc | doko: and we had introdcued a bug i was hoping to fix easily (testing that too) | 19:13 |
| juliank | cjwatson: mdeslaur: WRT APT, 1024 bit keys and SHA1 for GPG signatures: I landed a patch in APT git that allows us to reject signatures in APT made with specific algorithms. I plan to turn that on in Summer, so it's part of the 16.10 release, and then would want a xenial SRU in January 2017 to turn that off for Xenial as well (changing two lines: incrementing array length + uncommenting new array member) - this hopefully gives the third | 19:13 |
| juliank | party repositories enough time to catch up. | 19:13 |
| juliank | (At least Spotify and Google repos are affected by this) | 19:14 |
| nacc | doko: i *think*, in the interest of getting these issues fixed, you or anyone cna sponsor them, the functional differnce is nil from what we had before (the main/universe split), it's just a normal merge. And our delta is pretty well contained at this point | 19:14 |
| nacc | doko: but i'd like to run the autopkgtests against php7.0 here just to be sure, so it'll take another 15-20 minutes, I think | 19:15 |
| juliank | Basically scheduling the SRU around a 16.04.2 release | 19:16 |
| juliank | best reasonably-possible security for everyone! | 19:16 |
| juliank | (I'd like to reject weak key lengths too, but key length is not exposed by gpg) | 19:17 |
| mdeslaur | juliank: sounds good | 19:18 |
| popey | Chipaca: ended up having to reboot, was completely unusable | 19:21 |
| popey | Chipaca: seems a known issue, if you have no swap defined, and do something which fills the cache (dding a 16GB IMG to SD card) it will spin kswapd forever | 19:22 |
| mterry | cjwatson: I'm experiencing a problem with a silo ppa, where we accidentally built a package with a version number that was too high. We (tried to?) deleted it from the ppa and rebuilt. But now the upload of built packages fails because it still sees the old packages (but only for i386 and amd64, not for armhf). Do you know what might be going on? | 19:25 |
| mterry | https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/9349898 for example | 19:25 |
| nacc | slangasek: doko: for a package that's only in ubuntu (php-universe-source), but which is essential a fork for php7.0 ... should i provide the .dsc, debian.tar.gz and orig.tar.xz files for sponsorship? or shoudl i provide a debdiff between the ubuntu versions (and a note indicating the orig.tar.gz is the same as for src:php7.0, but renamed)? | 19:29 |
| doko | nacc, I'd say yes, maybe omitting the .orig.tar if it's exactly the very same file | 19:31 |
| nacc | doko: yeah, it's identical, we do all the manipulation in the rules and with control file changes | 19:32 |
| nacc | doko: thanks! i'll provide that all shortly, are you ok if just subscribe you the bug once it's ready? | 19:32 |
| nacc | doko: LP: #1553419 | 19:51 |
| ubottu | Launchpad bug 1553419 in php7.0 (Ubuntu) "php7.0: update to latest version of packages from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1553419 | 19:51 |
| Pharaoh_Atem | doko: ? | 19:59 |
| slangasek | nacc: I didn't get a chance to answer your question the other day before you dropped off IRC... you're talking about pulling a new upstream version of php7 now, are there changes that constitute new features and should go through the FFe process? | 20:04 |
| slangasek | nacc: and we're talking about pulling a new upstream version, when the actual bug we care about fixing is a packaging incompatibility issue - seems risky to me | 20:05 |
| nacc | slangasek: afaict, 7.0.3 -> 7.0.4 is all bugfixes | 20:07 |
| nacc | slangasek: looking at their changelog, that is | 20:07 |
| slangasek | nacc: so you don't see any risk in pulling forward to that latest version from unstable, as opposed to just pulling the last Debian packaging for 7.0.3? | 20:08 |
| slangasek | I ask because it was a sync from Debian that gave us the current set of Breaks: issues :) | 20:08 |
| nacc | slangasek: that's a fair question; before i answer, can i ask something? if we stay on 7.0.3-13, will we, in the future, have to backport bugfixes to 7.0.3-13? Or will we at some point in the future merge to 7.0.4 from debian (or whatever is current)? | 20:09 |
| slangasek | nacc: if "Some point in the future" means "next release cycle"... | 20:10 |
| slangasek | nacc: if you think 7.0.4 is the target for 16.04, let's do that now | 20:10 |
| nacc | slangasek: well, that's what i'm, maybe, struggling to understand ... if we take 7.0.3, let's say, 7.0.3-13 (which i think will be the last debian release of 7.0.3), does that mean we'll just be backporting to 7.0.3-13 for the next 5-ish years? | 20:11 |
| slangasek | nacc: "backporting" what? | 20:13 |
| nacc | slangasek: bugfixes, future bugfixes, etc | 20:13 |
| slangasek | we wouldn't make packaging changes to php7.0 in 16.04 post-release | 20:13 |
| nacc | slangasek: so, presuming that php7.0 upstream continues to fix bugs, would we proactively be backporting those bugfixes to our level? or will we rely on users reporting issues and selectively backporting the fixes? | 20:14 |
| nacc | slangasek: this is maybe my general ignorance on ubuntu maintainership/policies/etc | 20:14 |
| slangasek | nacc: I'd say that's a prioritization question you should discuss with jgrimm-afk :) | 20:15 |
| nacc | slangasek: :) | 20:15 |
| nacc | slangasek: ok, i can easily rebase my chagnes to 7.0.3-13 instead, that's trivial for me to do & test | 20:15 |
| nacc | Pharaoh_Atem: do you have an opinion here? | 20:15 |
| slangasek | nacc: a look at the versions of php5 in the various LTS pockets may offer some historical insight - there are no new upstream versions in -security or -updates, but 21 SRUs to precise since release and 14 SRUs to trusty since release | 20:16 |
| Pharaoh_Atem | nacc: I'm in favor of pushing to new minor releases in 7.0.x | 20:16 |
| Pharaoh_Atem | I'd prefer to keep the backport delta as low as possible until the release | 20:17 |
| Pharaoh_Atem | at which point, the version freeze can kick in and we can do backports on an as-needed basis | 20:17 |
| slangasek | nacc: so I would use that as the guide for now, and assume we are not going to take newer upstream point releases post-release | 20:17 |
| Pharaoh_Atem | one of the things that the php community has gotten better at with php7 is ensuring that bugfix releases are really only bugfix releases | 20:18 |
| slangasek | that would be grounds for a conversation about php getting a micro release exception for SRUs; but that should definitely be sorted out later and not block the current updating | 20:20 |
| nacc | slangasek: yep, understood -- i think in this particular care, it does seem like 7.0.4 has some pretty large bugfixes (segfaults, crashes, overflows) based upon the upstream chagnelog. I think it is worth us moving to that version now, to minimize the need to backport (already) 10-15 fixes | 20:21 |
| nacc | s/care/case/ | 20:21 |
| slangasek | nacc: copy. I can have a look at this today then | 20:21 |
| nacc | slangasek: and i will look into the micro release exception, as well as be more cautious in teh future about our versioning and stability | 20:21 |
| nacc | slangasek: thank you very much! it should allow a lot of excuses to clear out again, as php-defaults is currently broken | 20:22 |
| slangasek | nacc: btw regarding the debian/control delta - yes, I ran the debian/rules debian/control target against both source packages, which I think is the correct thing to do. That target certainly existed before we split the source, and I assume it should always be run before generating the source package | 20:22 |
| slangasek | if that resulted in deltas vs Debian, umm <shrug> | 20:22 |
| nacc | slangasek: yeah, it ended up just moving a bunch of stuff around | 20:22 |
| nacc | and i was told to minimize our delta :) | 20:22 |
| nacc | slangasek: but i will look at that too | 20:23 |
| nacc | slangasek: coudl be that whatever level we were on hadn't run it recently | 20:23 |
| nacc | so it was out of date | 20:23 |
| slangasek | right, so if it moved stuff around that either implies the Debian debian/control was not up to date, or the target is not reproducible | 20:23 |
| slangasek | for merging, I would suggest ignoring debian/control diffs / conflicts and just regenerating that file after merging up debian/control.in | 20:24 |
| nacc | slangasek: ah, i think the debian/control is not uptodate | 20:24 |
| nacc | slangasek: wrt. debian/control.in & debian/rules | 20:24 |
| * slangasek nods | 20:24 | |
| nacc | slangasek: want me to update the debdiffs? i'd like to document that in the changelog too, just so it's clear to me in the future :) | 20:24 |
| slangasek | nacc: yes, feel free to update the debdiffs now, it'll be about an hour before I'm pulling | 20:25 |
| nacc | slangasek: ok, will do that now, thanks! | 20:25 |
| doko | tumbleweed, https://launchpad.net/ubuntu/+source/pyzmq/15.1.0-1ubuntu1 any idea? you don't see that in unstable because of #818187 | 21:02 |
| tumbleweed | doko: urgh | 21:03 |
| tumbleweed | I didn't know what was wrong the last time around, with pyzmq | 21:03 |
| tumbleweed | thankfully the latest upstream fixed it, at the time | 21:03 |
| Pharaoh_Atem | nacc: I think we'll likely use 7.0.5 as the final release before Ubuntu Xenial freeze | 21:05 |
| doko | nacc, Pharaoh_Atem, slangasek: sorry, didn't see the discussion until now. had it already uploaded | 21:07 |
| nacc | doko: slangasek: i can provide 7.0.4-5ubuntu1->ubuntu2 debdiff if you'd like that will clean up the changelog and include the stuff discussed above? | 21:11 |
| nacc | doko: also, i do see the uploads in excuses, but it seems to be unhappy that we skipped 7.0.3-9ubuntu2? | 21:11 |
| doko | <fk for today | 21:11 |
| infinity | nacc: That'll clear up once britney sees the new binaries. | 21:16 |
| nacc | infinity: ah ok, thanks! | 21:16 |
| nacc | slangasek: let me know how you want to proceed ... i have my cleaned up tree locally; i expect it to just be d/control & d/changelog changes | 21:22 |
| nacc | infinity: does someone have to go in and manually delete "old binaries"? (e.g., php 7.0.3-9ubuntu2 binaries on armhf) | 21:43 |
| infinity | nacc: No. | 21:43 |
| infinity | nacc: That just means the armhf build wasn't done/published yet when britney ran. | 21:44 |
| nacc | infinity: oh i see | 21:44 |
| nacc | infinity: thanks! | 21:44 |
| nacc | infinity: one last question, sorry, now that php7.0 is updated, will all the autopkgtest regressions from the php-defaults issue (which is now fixed, it was an unsatisfiable dependency) be automatically resubmitted? | 21:46 |
| === nobuto_ is now known as nobuto | ||
| infinity | nacc: No idea. Depends on what depends on what and ends up triggering things as a result. | 21:47 |
| nacc | infinity: ok, i'll try and follow the depends, thanks! | 21:48 |
| doko | nacc, https://launchpadlibrarian.net/248138216/buildlog_ubuntu-xenial-amd64.remctl_3.10-1build2_BUILDING.txt.gz | 21:54 |
| nacc | doko: hrm, probably needs updating to be php7.0 compatible, let me look | 21:57 |
| nacc | doko: yeah, it's on my list of automatically updateable ones (basically needs to be sed'd). Want me to provide a debdiff? | 21:58 |
| doko | please do | 21:59 |
| slangasek | nacc: I'll take a debdiff for debian/control + debian/changelog, sure | 22:05 |
| nacc | slangasek: ok, i'll try and get that going once i've figured out remctl | 22:06 |
| nacc | doko: i *think* remctl might not be php7 compatible ... meaning we'd need to disable the php bindings | 22:07 |
| nacc | let me look upsream | 22:07 |
| nacc | doko: yeah, it's not. I can take a swing at updating it, but those are lower on my priority list to look at. Do you want a debdiff that just disables php5-remctl for now? | 22:15 |
| nacc | slangasek: can you do that sync of php-xdebug? php-common has a breaks on it | 22:28 |
| nacc | slangasek: that'll fix the php-imagick and phpunit, afaict | 22:32 |
| slangasek | nacc: yes, I saw that was still pending and will get to it in about an hour. It's a sync that overwrites an Ubuntu delta for your upstream cherry-pick, that's something that's included in the 2.4.0 release? | 22:47 |
| nacc | slangasek: yep | 22:47 |
| nacc | slangasek: i put that in the description of LP: #1553419 | 22:48 |
| ubottu | Launchpad bug 1553419 in php7.0 (Ubuntu) "php7.0: update to latest version of packages from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1553419 | 22:48 |
| nacc | slangasek: i should have made that clearer, sorry | 22:48 |
| nacc | slangasek: we could hav sync'd sooner, actually, i was just waiting for the final release, as upstream told me they weren't going to do another RC | 22:48 |
| slangasek | nacc: oh then maybe I'll just hit the button now | 22:49 |
| slangasek | nacc: synced. but the bug won't autoclose, because the bug task was on php-xdebug but the current source package name is xdebug | 22:50 |
| nacc | slangasek: np, i can close the task | 22:51 |
| nacc | slangasek: i think i confused myself on that | 22:51 |
| metaf5_ | What are the practical differences between Xenial Beta and Daily? I'm looking to update an application that is distributed as a modified Ubuntu install CD, and wondering where to start. | 22:51 |
| nacc | metaf5_: i'm not sure what you mean? it seems like Beta is a snapshot at a specific point in time, while Daily is ... well, daily? | 22:52 |
| slangasek | well, one difference is that we have not released a beta of Ubuntu yet for Xenial; that's only available for community flavors | 22:53 |
| metaf5_ | Oh, I was looking at Ubuntu-Gnome, my bad. I think I probably want the daily then. Thanks! | 22:56 |
| nacc | doko: ok, i think i got a build working, let me see how the tests go :) | 23:04 |
| nacc | slangasek: will the php-imagick build that failed earlier (https://launchpad.net/ubuntu/+source/php-imagick/3.4.0~rc6-1ubuntu3) automatically kick off again now that php-defaults has been fixed? | 23:12 |
| slangasek | nacc: no, but I can kick it now | 23:14 |
| nacc | slangasek: thanks, i wasn't sure about that one as it never made it into proposed | 23:14 |
| slangasek | if launchpad detects that a failure is because of a missing build-dependency, it'll put it into "dep-wait" state and automatically retry it. otherwise, needs a manual poke | 23:15 |
| nacc | doko: i'm trying to figure out how to run the tests :) i don't think we really run them normally, but there is a php testsuite | 23:15 |
| nacc | slangasek: right, i remember that from before, figured this might be a different case | 23:15 |
| nacc | doko: hrm, i'd need to actually ocnfigure kerberos to test it :) | 23:16 |
| nacc | doko: so i can provide you my patch, which does let it build, or i can work with upstream to see if they can test? | 23:16 |
| nacc | doko: and in the meanwhile, disable php5-remctl | 23:16 |
| nacc | doko: I just sent the upstream/debian maintainer a note with my patch | 23:24 |
| ari-tczew | flexiondotorg: ping | 23:32 |
| flexiondotorg | ari-tczew, Yo | 23:32 |
| ari-tczew | flexiondotorg: about bug 1556506, does mate-menu 5.6.9 contain any new features? | 23:33 |
| ubottu | bug 1556506 in mate-menu (Ubuntu) "Sync mate-menu 5.6.9-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1556506 | 23:33 |
| flexiondotorg | ari-tczew, Just fixes and translations. | 23:34 |
| cjwatson | mterry: I think your deletion raced with builds that were in progress. Repeat the deletion using "remove-package -A ppa:ci-train-ppa-service/ubuntu/landing-041 -s vivid -m 'wrong version' -e 8.13+15.04.20160314.3-0ubuntu1 unity8", wait for it to vanish from http://ppa.launchpad.net/ci-train-ppa-service/landing-041/ubuntu/dists/vivid/main/binary-i386/Packages.gz, then retry the builds | 23:34 |
| ari-tczew | flexiondotorg: ok, I'll process it for you. | 23:34 |
| flexiondotorg | ari-tczew, Perfect. Thank you very much! | 23:34 |
| mterry | cjwatson: heyo! OK will try, thanks | 23:34 |
| ari-tczew | flexiondotorg: did you already consider to get PPU for any mate related package? | 23:35 |
| flexiondotorg | ari-tczew, If you're able a have a few others too ;-) | 23:35 |
| nacc | is there a standard place for me to see if a build is in dep-wait? | 23:36 |
| flexiondotorg | ari-tczew, I have applied but the DMB didn't meet last time and are now in limbo :-( | 23:36 |
| ari-tczew | flexiondotorg: ah, right, I see your application now | 23:36 |
| ari-tczew | DMB is broken this time :P | 23:37 |
| flexiondotorg | ari-tczew, I saw. | 23:37 |
| cjwatson | nacc: The +build page will say "Dependency wait" if it is. | 23:37 |
| cjwatson | And it will name the unsatisfied dependency. | 23:37 |
| flexiondotorg | ari-tczew, This is another fixes only sync request - https://bugs.launchpad.net/ubuntu/+source/mate-dock-applet/+bug/1557207 | 23:37 |
| ubottu | Launchpad bug 1557207 in mate-dock-applet (Ubuntu) "Sync mate-dock-applet 0.69-1 (universe) from Debian unstable (main)" [Undecided,New] | 23:37 |
| nacc | cjwatson: ah! | 23:38 |
| flexiondotorg | ari-tczew, And another - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1556711 | 23:38 |
| ubottu | Launchpad bug 1556711 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 16.04.4 release [debdiff attached]" [Low,New] | 23:38 |
| ari-tczew | flexiondotorg: how do you fill sync requests on LP? | 23:53 |
| ari-tczew | manually? | 23:53 |
| flexiondotorg | I use requestsync | 23:53 |
| ari-tczew | flexiondotorg: hmmm... I asked due to missing importance on your bugs | 23:55 |
| ari-tczew | normally should be set to Wishlist | 23:55 |
| flexiondotorg | OK, I can make sure that happens in the fture. | 23:55 |
| flexiondotorg | First time I've been told, but I can do that. | 23:56 |
| flexiondotorg | Are sync requests that fixes bugs Wishlist? | 23:56 |
| ari-tczew | flexiondotorg: it's not a key requirement or something. just requestsync should do this automatically, so I thought you just fill syncs requests on LP manually | 23:57 |
| flexiondotorg | ari-tczew, This is how I do it - requestsync -d unstable -s mate-menu | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!