| cpaelzer_ | good morning | 05:40 |
|---|---|---|
| === cpaelzer_ is now known as cpaelzer | ||
| pitti | Good morning | 06:11 |
| pitti | +gnome-software (3.20.1+git20160617.1.0440874.ubuntu-xenial-0ubuntu1~16.04.1) | 06:19 |
| pitti | Laney: ^ triggering buffer overflows in dpkg and apt? :-) | 06:20 |
| didrocks | and then, people complained about CI train versionning scheme! :-) | 06:26 |
| === NCommander is now known as mcasadevall | ||
| pitti | Laney: rejecting your ubuntu-themes xenial SRU, it doesn't have an SRU bug | 07:00 |
| rbasak | pitti: mysql-5.7 dep8 is failing on ppc64el on both xenial and yakkety due to a latent bug. Has something changed in the way tests on ppc64el are run - such as parallelism? | 07:47 |
| rbasak | pitti: Skuggen has kindly provided http://bugs.mysql.com/bug.php?id=81923 upstream, but that is a while from being fixed. Would it be acceptable to ignore the test positive as it is not a regression over Xenial? | 07:48 |
| rbasak | (it's blocking progress for us right now and we don't have a fix; apparently it's a race) | 07:48 |
| rbasak | Or should we disable the affected tests? | 07:48 |
| rbasak | mwhudson: with bug 1591021, I'd go as far as Won't Fix. We've tried to fix things up in the past and maintaining that delta was more painful than it was worth. If upstream aren't interested in fixing it, that's Won't Fix for us. | 08:03 |
| ubottu | bug 1591021 in docker.io (Ubuntu) "upgrading docker does not restart daemon" [Wishlist,Triaged] https://launchpad.net/bugs/1591021 | 08:03 |
| rbasak | Otherwise there's the implication that the bug could make progress and/or that we'd take a patch, which isn't true. | 08:03 |
| mwhudson | rbasak: fair enough | 08:03 |
| Laney | pitti: ffs, the train is supposed to add that | 08:04 |
| seb128 | Laney, did you commit --fixes lp:<nnn> or have the bug linked to the merge request? | 08:05 |
| Laney | don't know | 08:06 |
| Laney | don't worry seb128, I can manage fixing it :) | 08:06 |
| seb128 | yeah | 08:06 |
| seb128 | it might be a train regression, please let them know if you had one of those and it failed to create the correct changelog | 08:06 |
| === Spads_ is now known as Spads | ||
| pitti | rbasak: sorry, was OTP; no, there were no recent changes from my side | 08:11 |
| pitti | rbasak: but it could certainly be that some underlying library or hte kernel or whatnot changed | 08:11 |
| pitti | rbasak: http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/yakkety/ppc64el/ doesn't look new, though, it has always been fairly flaky | 08:12 |
| pitti | rbasak: and http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/xenial/ppc64el/ didn't regress, it's alwaysfail | 08:12 |
| rbasak | pitti: it seems to consistently fail now, but I'm told the bug existed from the start of 5.7, and we didn't hit the issue in Xenial. | 08:13 |
| pitti | (like on http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mysql-5.7) | 08:13 |
| rbasak | pitti: though if you look at the actual failure log, you'll see that it is intermittent - but since there are a number of tests affected, at least one of them tends to fail. | 08:13 |
| pitti | yeah, the latest xenial run is something different | 08:13 |
| pitti | http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mysql-5.7 is just marked red because of the ruby-mysql2 regressino | 08:14 |
| * pitti retries that | 08:14 | |
| rbasak | They're all different. | 08:14 |
| rbasak | The problem is that there are some essential fixes I want to land in Xenial after some testing in Yakkety. | 08:14 |
| rbasak | But this is blocking those. | 08:15 |
| pitti | # very flaky | 08:15 |
| pitti | force-badtest mysql-5.7/5.7.12-0ubuntu2/ppc64el | 08:15 |
| pitti | hah | 08:15 |
| pitti | so this just needs to be bumped | 08:15 |
| rbasak | Oh | 08:15 |
| rbasak | I didn't know that was there! | 08:15 |
| pitti | done | 08:15 |
| rbasak | We think it could all be http://bugs.mysql.com/bug.php?id=81923 so add that as a comment if you like? | 08:16 |
| rbasak | Thanks! | 08:16 |
| Skuggen | \o/ | 08:16 |
| pitti | feel free to hit retry on http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mysql-5.7 again if the currently running one fails again | 08:16 |
| Skuggen | We're pretty sure this problem has been there for all of 5.7, so was a bit odd that the tests are failing more often now | 08:16 |
| rbasak | Will do, thanks. | 08:16 |
| rbasak | Skuggen: looks like the failure was being ignored before (due to being flaky) | 08:17 |
| Skuggen | Ah, maybe it used to be "Always failed", but then a fully green build passed through? | 08:17 |
| Skuggen | I seem to remember two platforms listed as "Always failed" for 5.7 | 08:17 |
| pitti | yeah, it happened to succeed four times | 08:24 |
| rbasak | Skuggen: I filed bug 1594716 so we leave a trail for anyone hitting this. | 08:25 |
| ubottu | bug 1594716 in mysql-5.7 (Ubuntu) "InnoDB: Failing assertion: it != chunk_map->end()" [Medium,Triaged] https://launchpad.net/bugs/1594716 | 08:25 |
| Skuggen | Bug: Random test successes | 08:28 |
| caribou | pitti: any reason why https://cloud-images.ubuntu.com/yakkety/current/yakkety-server-cloudimg-amd64-disk1.img doesn't exist ? | 08:29 |
| pitti | caribou: the -disk1 suffix was dropped | 08:29 |
| caribou | pitti: any relation to your new autopkgtest 4.0 release ? | 08:29 |
| caribou | pitti: which means that one cannot run yakkety dep8 tests on Xenial... | 08:29 |
| rbasak | "Inconsistency for the sake of consistency", as smoser put it. | 08:29 |
| pitti | caribou: this was already fixed in 3.20.7 | 08:30 |
| pitti | caribou: install the version from xenial-backports | 08:30 |
| caribou | pitti: ah, ok : apt-get update && apt-get -y dist-upgrade | 08:30 |
| caribou | pitti: yeah, backport is better | 08:30 |
| caribou | pitti: thanks! | 08:31 |
| Odd_Bloke | rbasak: caribou: pitti: The .img in yakkety is intended to boot in both UEFI and traditional manners; it is actually different to what the -disk1 image was. :) | 08:37 |
| juliank | mvo: Could you leave some endorsement on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU please? | 08:38 |
| juliank | pitti: you probably do not recall any upload you sponsored (I see two ndiswrapper ones from 2008 and 2014) and could add something? | 08:40 |
| juliank | and infinity wanted to write something too... | 08:40 |
| * juliank hates bureaucracy | 08:41 | |
| mvo | juliank: happy to do that | 08:41 |
| mvo | juliank: more than happy | 08:41 |
| pitti | juliank: indeed only these two: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Martin+Pitt&sponsor_search=name&sponsoree=Julian+Andres+Klode&sponsoree_search=name | 08:42 |
| pitti | which was a simple sync | 08:42 |
| pitti | juliank: I'll add a recommendation, though! | 08:42 |
| juliank | pitti: syncs are mostly what I do :D | 08:42 |
| pitti | good thing :) | 08:43 |
| juliank | That's what I want the PPU for, to get rid of the sponsorship step for the syncs | 08:43 |
| juliank | Mostly I work around the normal procedure a bit and just ask someone like mvo or infinity to sync something - that's way quicker than filing a sync request in lp ... - but it does not get the same "publicity" | 08:44 |
| mvo | juliank: let me know if I should expand it more | 08:47 |
| juliank | mvo: it's great | 08:47 |
| xnox | mvo, juliank, recommended for Ubuntu Core Dev | 09:12 |
| juliank | xnox: Well, we can do that too... | 09:13 |
| juliank | (but that's a PPU applications) | 09:13 |
| xnox | juliank, i went from "contributing member" -> core-dev in one step. | 09:14 |
| xnox | juliank, yes, but in practice mark said "any debian developer is ubuntu developer" thus you should have effective PPU anyway, and you are good enough for coredev =) no need to reapply for everypackage. and you can and know how to fix stuff. | 09:15 |
| juliank | Oh, there is a less formal procedure for adding/removing packages for Debian developers. | 09:16 |
| juliank | But I can also go the core dev road, if that's OK with everyone | 09:16 |
| juliank | That is, if you think I'm OK for that, I'd prefer that | 09:17 |
| === iahmad is now known as iahmad_ | ||
| juliank | xnox: I just wanted to play safer this time, a few years ago, I applied for MOTU and was rejected. :/ | 09:20 |
| === iahmad_ is now known as iahmad | ||
| xnox | bah, silly DMB members | 09:22 |
| caribou | pitti: any reason why dep8 tests would run then adt-run would report that there were no test ? http://pastebin.ubuntu.com/17636513/ | 09:22 |
| xnox | juliank, i was on DMB for a little while, but i'm not any more =( | 09:22 |
| pitti | caribou: that looks like a bug indeed; what's the exit code? | 09:23 |
| caribou | pitti: 8 as expected | 09:24 |
| pitti | well, 0 or 2 would be expected | 09:24 |
| caribou | pitti: I'm running the latest in xenial-backports | 09:24 |
| pitti | as there *are* tests | 09:24 |
| rbasak | May I have a review of https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692 from an experienced dev please? The mechanics are simple but I want to make sure the approach is correct (seddery of conffile) | 09:24 |
| caribou | pitti: yes, but since it reports SKIP, then 8 is to be expected | 09:24 |
| caribou | pitti: I'll retest on Yakkety & let you know | 09:24 |
| pitti | caribou: right, please file a bug about it with the full command line | 09:25 |
| caribou | pitti: sure | 09:25 |
| juliank | xnox: well, I'd be happy with core-dev membership. The MOTU thing was way back before 2010 even, I think. Kind of depends what mvo and infinity think, as those two are the ones I worked most with longterm/recently. I gtg to university in a few minutes, but will be back in about 20 minutes. | 09:26 |
| juliank | You're not the first to suggest this | 09:27 |
| juliank | IIRC | 09:27 |
| juliank | Someone suggested the same when I applied for bug control... | 09:27 |
| xnox | !dmb-ping please give juliank core-dev, based on the fact that he is a dd, and lands apt into ubuntu, properly. | 09:27 |
| ubottu | xnox: I am only a bot, please don't think I'm intelligent :) | 09:27 |
| xnox | !dmb-ping | 09:27 |
| ubottu | bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping. | 09:27 |
| xnox | ^^ | 09:27 |
| mwhudson | argh | 09:27 |
| sil2100 | uh oh! | 09:28 |
| mwhudson | can someone delete https://launchpad.net/ubuntu/+source/golang-defaults/2:1.6.1+1ubuntu2~ppa1 ? | 09:28 |
| xnox | mwhudson, added "block-proposed" tag on https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1508122 | 09:29 |
| ubottu | Launchpad bug 1508122 in dh-golang (Ubuntu) "please transition to shared libraries" [High,In progress] | 09:29 |
| juliank | xnox: If I miss anything in the next twenty minutes, let me know when I rejoin | 09:29 |
| mwhudson | xnox: it's in NEW, luckily | 09:29 |
| xnox | mwhudson, and affects golang-defaults | 09:29 |
| mwhudson | but yes, thanks! | 09:30 |
| xnox | mwhudson, well it's in proposed already, and "block-proposed" is the mere-mortal accessible emergency stop handle =) | 09:30 |
| Trevinho | bdmurray: as for these regression mails... It seems I'm not getting them anymore, but I think the update can be fired to everyone. These are not related to SRU. | 09:30 |
| xnox | mwhudson, usually ask for package removals like that on #ubuntu-release | 09:30 |
| xnox | mwhudson, people with powers monitor that. | 09:30 |
| mwhudson | ah good point | 09:30 |
| rbasak | xnox: how does not giving juliank core dev hinder progress? I think I'm settling that as a general criteron now. | 09:35 |
| rbasak | (while also slowly forgetting how to spell and otherwise construct sentences) | 09:36 |
| xnox | rbasak, the fact that foundations doesn't have an active apt maintainer, and juliank has been effectively maintaing apt in ubuntu, for ubuntu specific stuff for a while now =) | 09:36 |
| rbasak | xnox: so that's an excellent reason to give juliank apt PPU. | 09:36 |
| xnox | rbasak, the list of PPU packages he requests are fine. However, he also finds things and fixes bugs in other dependant packages, and is capable of being an effective core dev =) | 09:37 |
| * xnox wants juliank as a core dev, cause he would be a good core dev =) | 09:38 | |
| rbasak | The first part of that reason is a good reason. The second part is a good endorsement but not in itself a reason :) | 09:38 |
| rbasak | Please put your reasons in your endorsement ;) | 09:38 |
| juliank | xnox: I'm back! | 09:48 |
| juliank | xnox: Nice excerpt in the wiki | 09:49 |
| sil2100 | ;) | 09:55 |
| juliank | I must say that xnox is very enthusiastic about this whole thing | 09:56 |
| juliank | I like that. | 09:56 |
| rbasak | juliank: so I was saying while you were out. I'm new on the DMB. But I'm slowly settling on wanting a reason for people to have particular upload access. For core dev, often that's "I keep needing sponsorship and that slows down my work", for example. | 09:57 |
| rbasak | That is: I'm more likely to +1 a request if not doing so will hinder someone somehow, and so I'd like that explained. | 09:58 |
| rbasak | Since anyone uploading to Ubuntu is doing us all a favour, and I want to "get out of the way". | 09:58 |
| juliank | rbasak: Yes, isn't that the reason for everyone? I listed "so I can sync new bugfix releases when needed." - I can expand on that obviously | 09:59 |
| rbasak | juliank: right, but apt (and apt-related packages) PPU would suffice for that. | 09:59 |
| rbasak | juliank: it does seem to me that apt (and related) PPU is a no-brainer for you BTW. | 09:59 |
| juliank | Yes, for the APT stuff, it probably would. The other packages are unrelated to APT, but also need syncing in import freeze times to get new bug fixes in | 10:01 |
| juliank | Apart from the technical component, there's also the social component with core-dev. | 10:02 |
| juliank | Also, it could easily happen that I NMU a debian package for some RC bug and then want to sync that during freeze and stuff like that | 10:03 |
| rbasak | Yes, there is. I'm aware of that being documented, though AIUI there's quite a high bar for that. I've not seen it done before, and as a DMB newcomer, I'm less confident around that. | 10:03 |
| rbasak | Before I was an uploader, I found that people were more willing to sponsor things for me as time went on, because they knew that it was likely to be right and not take much time. | 10:04 |
| rbasak | And they checked less and less. | 10:04 |
| juliank | I really only do syncs these days, I don't think there's a whole lot of checking going on when someone sponsors them... | 10:05 |
| juliank | It's like: Hey I need this synced, and 3 minutes later I hear done | 10:06 |
| cjwatson | I find it difficult to imagine somebody who's suitable for apt PPU who wouldn't also be suitable for core-dev. | 10:06 |
| cjwatson | (FWIW) | 10:06 |
| rbasak | If you have needed sponsorship for a bunch of syncs in random packages, that's also a good reason I think. | 10:07 |
| juliank | cjwatson: With apt PPU rights I can basically do just as much damage as with core-dev permissions.. | 10:07 |
| rbasak | Well, technically you're root in a user's postinst with any upload :) | 10:07 |
| pitti | the threat of "any package you touch will belong to you for a long time" should be high enough, too :) | 10:07 |
| cjwatson | juliank: Quite. | 10:08 |
| rbasak | cjwatson: I appreciate your opinion, thanks. Forgive me for being cautious. I'm new to this ;) | 10:08 |
| pitti | rbasak: FWIW, you got elected on the board because people trust your opinion, so don't apologize :) | 10:10 |
| rbasak | pitti: thanks :) But still, subjective decisions are hard to make, and there will always be someone who falls on the wrong side of one and suffers undue hassle. So I'm still happy to apologise for that. | 10:11 |
| caribou | pitti: FYI the SKIP autopkgtest report was not a bug but my misuse of the adt-run command | 10:20 |
| caribou | pitti: was running adt-run makedumpfile --unbuilt-tree . and there is no DEP8 tests in the package in the archive | 10:21 |
| pitti | caribou: oh, you are running *two* tests here | 10:21 |
| caribou | pitti: yep, just found out : | 10:22 |
| caribou | :) | 10:22 |
| pitti | caribou: that's the confusing scenario that autopkgtest 4.0 fixes :) | 10:22 |
| pitti | well, "fixes" → "does not allow any more" | 10:22 |
| caribou | pitti: I prefer the new syntax better | 10:22 |
| LocutusOfBorg | does anybody know where I can find mirv? | 10:48 |
| === hikiko is now known as hikiko|ln | ||
| mitya57 | LocutusOfBorg, try /query'ing him, he's here on freenode | 11:08 |
| LocutusOfBorg | yep, I did that, even if I prefer a public discussion | 11:08 |
| LocutusOfBorg | well, the public discussion is now on #ubuntu-x FWIW | 11:08 |
| LocutusOfBorg | qtbase-opensource-src is broken on arm64 | 11:08 |
| LocutusOfBorg | a transition is needed because gles has been enabled there | 11:09 |
| LocutusOfBorg | I found it while rebuilding calibre on arm64, failing because of missing symbols (rebuilding pyqt5 is helping) | 11:09 |
| mitya57 | OK. FWIW you can also ask me about Qt related questions :) | 11:10 |
| LocutusOfBorg | mitya57, https://irclogs.ubuntu.com/2016/06/21/%23ubuntu-x.html | 11:11 |
| LocutusOfBorg | can you please take care of it then? :) | 11:11 |
| mdeslaur | infinity: I'd appreciate your thoughts on the best way to address bug 1584485 | 11:22 |
| ubottu | bug 1584485 in samba (Ubuntu) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485 | 11:22 |
| mdeslaur | infinity: that approach doesn't look sane to me, do you have any suggestions for something better? | 11:22 |
| * mitya57 is back and looks | 11:29 | |
| mitya57 | LocutusOfBorg, I can rebuild pyqt5 and calibre. Will it solve your problem? :) | 11:34 |
| LocutusOfBorg | mitya57, I'm doing that | 11:45 |
| LocutusOfBorg | the problem is: does anything else needs a rebuild? | 11:45 |
| === hikiko|ln is now known as hikiko | ||
| mitya57 | LocutusOfBorg, I suppose anything build-depending on libqt5opengl5-dev may need a rebuild. | 11:51 |
| mitya57 | But I assume Timo is/was intending to take care about most of that himself. | 11:51 |
| mitya57 | I.e. he filed bug #1586026 for packages that don't build with the new version. | 11:52 |
| ubottu | bug 1586026 in vite (Ubuntu) "Remove arm64 binaries for packages failing to build with Qt compiled with OpenGL ES" [Undecided,New] https://launchpad.net/bugs/1586026 | 11:52 |
| LocutusOfBorg | thanks mitya57 | 12:12 |
| LocutusOfBorg | following up there | 12:12 |
| mitya57 | FWIW there was also a thread on ubuntu-devel about this | 12:15 |
| === dpm_ is now known as dpm | ||
| coreycb | pitti, hi, I commented on bug 1586900 if you can take a look please | 12:41 |
| ubottu | bug 1586900 in python-keystoneauth1 (Ubuntu Xenial) "[SRU] keystoneauth1 2.4.1 for Xenial/Mitaka" [Medium,Triaged] https://launchpad.net/bugs/1586900 | 12:42 |
| pitti | coreycb: yes, but they were added to the binary deps too | 12:42 |
| coreycb | pitti, only python-requests-kerberos was added to the binary Suggests | 12:44 |
| pitti | ah, these are *all* Suggests? | 12:44 |
| pitti | sorry then, I missed that | 12:44 |
| coreycb | pitti, the only d/control changes from 2.4.0 to 2.4.1 is additions to Build-Depends-Indep | 12:45 |
| coreycb | pitti, I can upload that again if you agree. thanks for reviewing btw. | 12:53 |
| pitti | coreycb: that would be good, sorry for the trouble | 12:54 |
| coreycb | pitti, np :) | 12:54 |
| rbasak | May I have a review of https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692 from an experienced dev please? The mechanics are simple but I want to make sure the approach is correct (seddery of conffile) | 13:32 |
| pitti | rbasak: nitpick: I'd add a '^ *' at the front of the regexp, or at least a \b, to ensure that you aren't catching a partial word | 14:11 |
| pitti | like some otherthing_key_buffer | 14:12 |
| infinity | mdeslaur: The proposed fix is certainly not reasonable. I'll ponder the problem over breakfast. | 14:18 |
| infinity | mdeslaur: Is it a question of ABI breaks, or ABI additions? It seems the real issue is bad dependencies between libnss-winbind and its deps. | 14:19 |
| rbasak | pitti: good point, thanks. Is the general principle of handling it OK? Backup file left if changed with sed's --in-place option, dropping the backup if sed left the file unchanged, guarded by version comparison for upgrade only, etc - is there anything else we should be doing that we've missed? | 14:19 |
| infinity | Oh, because samba-libs is a big blob os libraries that shouldn't be packaged together. | 14:20 |
| infinity | Whee. | 14:20 |
| pitti | rbasak: seems good enough to me | 14:20 |
| rbasak | Great. Thank you for the review! I didn't want to do this badly since fixing it later would be painful :-/ | 14:20 |
| rbasak | Skuggen: ^ | 14:20 |
| mdeslaur | infinity: if the abi changes, running processes die because they're running with the old version of libnss-winbind | 14:22 |
| mdeslaur | infinity: I guess abi additions should be fine, but I'm not sure how careful samba preserves abi between versions | 14:23 |
| infinity | mdeslaur: Running processes should be fine, it's new processes that explode miserably. (Well, or running processes calling into NSS anew, but that's still "new", from my POV) | 14:24 |
| infinity | mdeslaur: But yeah, the problem is clearly a lack of sane ABI versioning on "samba-libs" and, thus, incorrectly weak deps between libnss-winbind and samba-libs. | 14:25 |
| infinity | mdeslaur: Doesn't look like something one can properly fix in an SRU, since the fix is to actually version the *#^)! libraries correctly. | 14:26 |
| mdeslaur | oh, right, new processes in that specific case | 14:27 |
| infinity | mdeslaur: But having samba-libs Break libnss-winbind << Binary-Version, and disable/reenable winbind on preinst/postinst would "work". Though, gross. | 14:27 |
| mdeslaur | I thought I saw a bug where existing processes were crashing because of an incompatibility with a newer winbind service | 14:27 |
| infinity | Existing processes will also explode if they call into NSS fresh, NSS is effectively a dlopen(). | 14:28 |
| infinity | But yeah, I consider dlopen "new processes" from the POV of hunting library ABI issues. :P | 14:28 |
| infinity | Otherwise my head hurts. | 14:28 |
| mdeslaur | hehe | 14:28 |
| infinity | Anyhow, any solution that halts upgrade with "we notice you have packages installed and you're actually using them correctly; please stop using them" is not sane. | 14:29 |
| infinity | If it can be automated to disable/reenable, that's vaguely okay, though if their setup relies on winbind resolution working, there's a gap there where the world sucks. | 14:30 |
| infinity | But better that than crashing, I suppose. | 14:30 |
| * infinity -> breakfast run. | 14:30 | |
| mdeslaur | infinity: but what happens when an existing process is running with an old libnss-winbind, and the windbind package gets upgraded to a version that is not compatible with the old libnss-winbind? | 14:32 |
| mdeslaur | perhaps that's not a problematic scenario | 14:33 |
| infinity | mdeslaur: After taking a walk, it occurs to me that in the absence of proper library versioning, the more robust solution might just be for nss-winbind and pam-winbind to be statically linked to samba-libs. | 14:46 |
| infinity | mdeslaur: That would eliminate the problem, and have the added bonus of not having to pull in a massive samba-libs package just for the small bits that the nss/pam plugins need. | 14:47 |
| mdeslaur | hrm, that does sound reasonable | 14:48 |
| mdeslaur | infinity: please add your infinite widsom to the bug? | 14:48 |
| infinity | mdeslaur: I have a face full of breakfast. Feel free to copy and paste. ;) | 14:48 |
| mdeslaur | ack | 14:50 |
| mdeslaur | infinity: thanks for your input | 14:53 |
| nacc | rbasak: thanks for the various MR reviews, will respond shortly | 15:28 |
| tinoco | mdeslaur: infinity: should i work on the statically linked pam-winbind version debdiff ? | 15:43 |
| tinoco | totally agree on being a better solution | 15:43 |
| infinity | tinoco: pam-winbind and nss-winbind. | 15:43 |
| mdeslaur | tinoco: perhaps file a debian bug also? | 15:43 |
| tinoco | definitely. the proposal was to bring the discussion only | 15:44 |
| infinity | tinoco: Only statically linked to samba-libs, of course. You still want to be dynamically linked to any properly-versioned system libs (like libc). | 15:44 |
| tinoco | i wasn't supper happy about the approach either | 15:44 |
| tinoco | infinity: definitely. gotcha | 15:44 |
| tinoco | i'll work on it and provide a new sru suggestion | 15:44 |
| tinoco | tks! | 15:44 |
| infinity | tinoco: But yes, in the absence of properly-versioned samba libs, I don't see a better solution. | 15:45 |
| tinoco | infinity: yep, me neither. there would be always a time window for things to go bad | 15:45 |
| infinity | tinoco: The best solution would be for upstream to properly version all those little libs in samba-libs, and then break them out into individual packages. | 15:45 |
| infinity | tinoco: But I don't see that happening any time soon, if ever. | 15:45 |
| tinoco | ok. i'll document this for future reference (if they ever go that way) | 15:46 |
| tinoco | and will fix it on debian also | 15:46 |
| tinoco | tks infinity | 15:46 |
| infinity | tinoco: The "disable in samba-libs preinst, reenable in samba-libs postinst" approach would also work, but it's (a) potentially very brittle, and (b) likely next to impossible to do for pam-winbind (which probably suffers the same issue as nss-winbind). | 15:50 |
| tinoco | infinity: my hope was that pam-auth-update (or any other mean) could remove/re-add winbind to nsswitch | 15:51 |
| tinoco | but then.. if customer had a taylor made change of nsswitch.conf.. it would be no good | 15:51 |
| tinoco | other choice would be to remove.. but then, if user doing the installation was coming from NSS | 15:51 |
| tinoco | things would go bad also | 15:51 |
| infinity | tinoco: Right, nsswitch isn't too hard, but /etc/pam.d/* is an order of magnitude worse. | 15:52 |
| tinoco | just like you said before | 15:52 |
| tinoco | infinity: definitely | 15:52 |
| tinoco | i think statically compiling it for now is the best approach | 15:52 |
| tinoco | only way without dealing with infinitive possibilities coming from pam.d/nss | 15:52 |
| nacc | jbicha: re: php-horde-http (LP: #1594618), at least one of the two test failures in Ubuntu are skips in Debian; trying to figure out why | 15:53 |
| ubottu | Launchpad bug 1594618 in php-horde-http (Ubuntu) "Sync php-horde-http 2.1.6-3 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1594618 | 15:53 |
| infinity | nacc: Differences in name resolution, perhaps? (blind guess without looking at the failures) | 15:54 |
| nacc | infinity: yeah, i think that must be it (and why mdeslaur had patched the old version). But the older version was also failing :) | 15:54 |
| infinity | nacc: Debian buildds can generally resolve the world, even if they can't reach it. Ubuntu buildds have a restricted bind view that won't even resolve outside names. | 15:54 |
| nacc | infinity: is it possible for me to reproduce exactly the env that it's used for autopkgtest? | 15:54 |
| infinity | nacc: Oh. This is autopkgtest, not buildds? | 15:54 |
| infinity | nacc: In that case, ignore my above comment. Out autopkgtest infra can resolve everything. | 15:55 |
| nacc | infinity: ok :) | 15:55 |
| infinity | nacc: Though, given mdeslaur's patch, it's possible the autopkgtest infra has a * entry for the base domain, which would be silly... | 15:57 |
| infinity | nacc: But this is what example.com is for. doesnotexist.example.com would be a sane default for that test. | 15:57 |
| nacc | infinity: yep, agreed, it's just not obvious what exactly is failing from the current output :) | 15:59 |
| infinity | nacc: Indeed. And even with the patch in play, those same two tests were failing before. | 15:59 |
| infinity | So, hrm. | 15:59 |
| nacc | infinity: yeah, it's confusing :) I am wondering if it's actually a deps issue; i'm going to see if we can sync a few of the pecl http packages and see if that fixes things | 16:00 |
| infinity | nacc: Those tests have been flaky forever, it seems. I'm more confused about why they passed. Exactly once. | 16:01 |
| nacc | infinity: agreed, it seems like that's really an outlier/fluke and we actually didn't fix anything :) | 16:01 |
| nacc | infinity: heh, that test passed, because we skipped the two failures | 16:04 |
| nacc | infinity: probably because php-curl was uninstallable transiently or something | 16:04 |
| nacc | infinity: same for peclhttp2 -- so was a false positive, of sorts (although matching Debian) | 16:05 |
| mdeslaur | stgraber, infinity, kees, slangasek: tech board? | 16:12 |
| nacc | infinity: hrm, strange! running locally, i get 'Assertions: 22, Skipped: 15' | 16:13 |
| infinity | mdeslaur: Wha... Did someone delete it from the calendar? | 16:14 |
| mdeslaur | which calendar is it supposed to be in? | 16:16 |
| infinity | mdeslaur: It was on the Fridge calendar, and we all had invites. Seems it's been removed. Grr. | 16:16 |
| mdeslaur | crap, I hope I didn't do that | 16:17 |
| infinity | mdeslaur: Is it likely that you might have? :P | 16:17 |
| mdeslaur | my thunderbird plugin went on a rampage a couple of weeks ago and killed a bunch of stuff | 16:17 |
| infinity | Oh my. | 16:18 |
| mdeslaur | but, hopefully I didn't have rights on that one | 16:18 |
| stgraber | oh, didn't get a notification for some reason | 16:18 |
| stgraber | well ^ may be the reason :) | 16:18 |
| mdeslaur | crud | 16:19 |
| mdeslaur | if it was me, sorry about that | 16:19 |
| infinity | * linux: Implement secure boot state variables (LP: #1593075) | 16:29 |
| ubottu | Launchpad bug 1593075 in linux (Ubuntu) "linux: Implement secure boot state variables" [Medium,Triaged] https://launchpad.net/bugs/1593075 | 16:29 |
| infinity | - SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl | 16:29 |
| infinity | cyphermox: ^ | 16:29 |
| infinity | cyphermox: That should have landed in -proposed, if you want to double-check that userspace matches. | 16:29 |
| cyphermox | xenial you mean? | 16:34 |
| infinity | cyphermox: yakkety would be a good start. | 16:34 |
| cyphermox | I uploaded shim-signed 1.15 for that | 16:34 |
| infinity | cyphermox: Ahh, shiny. Then I'll validate the combination myself later and get back to you. :) | 16:35 |
| cyphermox | cool | 16:36 |
| cyphermox | I'm looking at precise and trusty atm; the stuff that was already in proposed | 16:36 |
| slangasek | mdeslaur: tech board > hmm why is it not on my calendar? | 17:26 |
| mdeslaur | slangasek: it got removed by mistake, possibly by me | 17:26 |
| slangasek | ah doh | 17:26 |
| mdeslaur | slangasek: infinity is adding it back | 17:27 |
| === JanC is now known as Guest79667 | ||
| === JanC_ is now known as JanC | ||
| === mcasadevall is now known as NCommander | ||
| capum321 | hello | 22:16 |
| capum321 | I am trying to compile mono-addins package as dependency to build a monodevelop 6.0 which doesn't exist in repositories. get this error http://dpaste.com/2PBR989 - - - the package is https://launchpad.net/ubuntu/+source/mono-addins/1.0+git20130406.adcd75b-3 -> mono-addins_1.0+git20130406.adcd75b-3.debian.tar.gz | 22:16 |
| nacc | capum321: an unaltered source package? | 22:29 |
| capum321 | hello | 23:44 |
| capum321 | nacc: | 23:44 |
| capum321 | are you there? | 23:44 |
| capum321 | dan | 23:45 |
| nacc | capum321: hello | 23:51 |
| nacc | jbicha: hey, just tried to reply to you and gnome mail said 'mail forwarding loop' and rejected it? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!