=== juliank is now known as Guest43048 === juliank_ is now known as juliank [02:02] hm [02:03] why hasn't golang-1.6 migrated from -proposed to -updates in trusty yet? [02:03] i thought it would happen after a week [02:03] (and the bug was verification-done) [02:07] mwhudson: http://people.canonical.com/~ubuntu-archive/pending-sru.html -> seems green, but its probably because there's no golang-1.6 in trusty main [02:07] mwhudson: so might need manual push [02:07] w [02:07] roaksoax: ah ok [02:15] It's always manual. [02:15] It needs a human to say "yep, let's do that". [02:16] And we don't tend to release on weekends. [02:16] Though, for a NEW package, it can't hurt. [02:16] mwhudson: Released. [02:16] infinity: what is this weekend you speak of [02:16] infinity: thanks [02:17] mwhudson: The weekend is the time when a large number of our developers shockingly aren't glued to their keyboards and would prefer not to deal with the flood of bug reports a bad SRU can cause. [02:17] mwhudson: Weird, I know. Since some of us have brain uplinks. [02:18] infinity: it's already monday afternoon though! [02:18] (Well, it's both about developer response time, and about not breaking corporate users with unattended-upgrades and a similar 5-day schedule) [02:18] mwhudson: Not in the correct part of the world! [02:18] infinity: 'correct'! [02:18] lifeless: You heard me. [02:19] I see stockholm has its claws into you [02:19] I lived in the future for five years. It didn't agree with me. [02:20] Granted, not your little bit. [02:20] :) [03:59] woo fun running the go runtime tests can kill the kernel on s390x [03:59] i guess i should report that to someone... [04:01] mwhudson: ! [04:02] actually an ibm person mentioned this too [04:02] so /hopefully/ i'm just running an out of date kernel [04:26] good morning [06:07] Good morning [06:07] jdstrand: thanks, I'll look into the udev crash now [06:11] dannf, infinity: adt-run always sets LANG=C.UTF-8 by default; something changed there since the new glibc, can you reproduce this with that command? [06:11] dannf: lxd currently seems broken on my xenial, I'll look into that now and file a bug [06:27] good morning [07:18] yay https://launchpad.net/ubuntu/+source/docker.io/1.10.3-0ubuntu4 === seb128_ is now known as seb128 [09:38] Mirv: hi! ping ping :-) [09:52] mardy: pong pong [09:52] Mirv: red alert :-) Do you think we can get this fixed by 16.04? bug 1564767 [09:52] bug 1564767 in webapps-sprint "Wrong size of embedded window" [Critical,In progress] https://launchpad.net/bugs/1564767 [09:53] Mirv: I've attached a patch, generated with quilt on top of the existing debian/patches [09:53] mardy: thanks, sure it should be possible. can you submit it to https://launchpadlibrarian.net/251636878/xcb_fix_parent_screen_of_embedded_windows.patch ASAP? we shouldn't carry a patch if it's not approved by upstream. [09:54] Mirv: sorry, to where? [09:55] mardy: hah, https://codereview.qt-project.org/ I was meaning to paste [09:55] mardy: maybe look through http://code.qt.io/cgit/qt/qtbase.git/log/src/plugins/platforms/xcb/qxcbwindow.cpp too if there's something to backport instead of your patch [09:56] Mirv: but are they still interested in Qt 5.5? [09:57] mardy: no, they'd be interested in 5.6 though if it's affected by the same bug [09:58] mardy: and most likely 5.6 branch is the best place to offer a fix too in, they merge from there to 5.7 and dev. [09:58] Mirv: I'll now test 5.6, but looking at their code, I believe they've already fixed it [09:58] Mirv: the problem is, it's not just one patch to backport, but many [09:59] mardy: ok, to me it'd look like the line of code in question is still unchanged, just a variable name changed. but maybe it was fixed elsewhere? [10:00] mardy: we actually have a lot of XCB fixes already in, in order to try to fix multi-monitor issues that plagued 5.5 still (and maybe even 5.6 still too). [10:00] mardy: but at this point I'd tend to agree that if it's yet another multiple patches, it would be better to take your two-liner patch instead [10:02] Mirv: yes, that function is still there in Qt 5.6, but handleConfigureNotifyEvent() doesn't call that method anymore :-) [10:03] Mirv: but let's see, I'm installing 5.6 and I'll let you know [10:03] ok! [10:19] pitti: Hi Martin, Time to look at the FFe request at bug #1556457 (fontconfig 2.11.1 -> 2.11.94)? [10:19] bug 1556457 in fontconfig (Ubuntu) "[FFe] Demilight (OS/2 weight=350) confuses fontconfig" [High,New] https://launchpad.net/bugs/1556457 [10:36] Mirv: yes, 5.6 works! :-) [10:37] Mirv: but given how deep are the chanegs in teh XCB plugin between 5.5 and 5.6, I think it's quite risky to try a backport (also because we already have quite a few debian/patches touching XCB) [10:37] mardy: ok! :) then you don't need to submit anything to upstream since indeed they've forgotten about 5.5 by now (because 5.6 is LTS). so it may be your patch is simply the best way. [10:38] mardy: I agree, unless some of the already backported patches form a baseline on top of which one more could be cherry-picked, but I somehow doubt that too [10:38] mardy: it just happened I got my previous qtbase xenial upload done so I'll start preparing the next one but not with what I had on my mind earlier (not so important) but your patch instead [10:39] Mirv: excellent, thanks a lot! [10:54] tseliot: thank you for fixing bug 1565436 so quickly. I wasn't expecting that! [10:54] bug 1565436 in ubuntu-drivers-common (Ubuntu Wily) "gpu-manager hangs on boot when syslog is bloated" [High,Triaged] https://launchpad.net/bugs/1565436 [10:55] rbasak: I think I did a while ago. I need to find some time to backport the fix [10:55] Ah, OK [11:04] infinity: opinion on https://bugs.launchpad.net/ubuntu/+source/myodbc/+bug/1564856/comments/1 please? [11:04] Launchpad bug 1564856 in myodbc (Ubuntu) "myodbc uses internal libmysqlclient functions no longer exported by 5.7" [Undecided,New] [11:04] Presumably repackaging for cmake shouldn't be insurmountable and we should just do it? [11:05] rbasak: But the main issue hasn't been fixed upstream [11:06] Skuggen: how hard would it be to fix it and patch it in distro and then send that upstream? [11:06] (in that I'm asking the question - I don't mean that rhetorically) [11:08] The developers are working on a fix, which we would then apply to the newest released version, but I don't know the code, so I don't really know how big a task this is [11:11] GunnarHj: followed up; I don't think I have enough information/experience with fontconfig to answer this right away, but I asked some questions there === hikiko is now known as hikiko|ln === zyga_ is now known as zyga [12:00] Greetings, regarding bug 1530323, I don't know what to do next, and it's affecting Lubuntu, could somebody please take a look at this bug report and my comments and judge whether it's fixed yet or not? I can't really tell... [12:00] bug 1530323 in network-manager-applet (Ubuntu) "The input box for editing a Wired connection static IP address doesn't appear correctly" [High,Confirmed] https://launchpad.net/bugs/1530323 [12:01] pitti: Added an answer to bug #1556457. If you don't have enough fontconfig experience, who has ;) [12:01] bug 1556457 in fontconfig (Ubuntu) "[FFe] Demilight (OS/2 weight=350) confuses fontconfig" [High,New] https://launchpad.net/bugs/1556457 === hikiko|ln is now known as hikiko === lan3y is now known as Laney === Laney is now known as Guest76158 === Guest76158 is now known as Laney [12:11] Hi Laney, any chance you have some good advice re. the bug #1556457 FFe? [12:11] bug 1556457 in fontconfig (Ubuntu) "[FFe] Demilight (OS/2 weight=350) confuses fontconfig" [High,New] https://launchpad.net/bugs/1556457 === dholbach_ is now known as dholbach [12:42] bluez-gstreamer wine1.6 gnome-media need recompile against gstreamer 1.0; they depend on gstreamer 0.10 in Xenial o.o [12:42] not sure if that's fixable at this stage though [12:43] (also bah the Wine team, they didn't get Wine 1.8 in Xenial even though it's been out since before Wily) === _salem is now known as salem_ === fginther` is now known as fginther [14:16] <_hc> we (Android Tools Debian team) finally got all of our current packages into Debian/testing. xenial is mostly in sync, but there are two packages with packaging fixes that have not been fixed: android-platfrom-system-core and android-platform-tools-base [14:16] <_hc> oops, have not been synced [14:39] <_hc> should I do requestsync? [14:40] _hc: yes please [14:41] <_hc> ok will do [14:41] <_hc> seamlik: do you want to try the requestsync, or shall I? [14:42] I'm not familiar with that ... [14:42] <_hc> ok, I can do it, its basically a webform in launchpad [14:42] _hc: i'd be happy to run 'requestsync' for you if you need [14:43] then give you the bug # to make your comments ;) [14:43] this close to final freeze, though, how critical are the package updates :P [14:43] Hmm I would wait for some time [14:43] s/final freeze/final release/ [14:44] <_hc> I think they are essential, and these are new packages that nothing else depends on, so they are low risk changes [14:44] <_hc> the new packages do depend on each other [14:44] <_hc> for example, one change is a typoed package name in depends [14:44] Do we have any deadlines? [14:45] <_hc> yeah, final release is very soon [14:45] final freeze is next week I think [14:45] * teward pulls the Xenial schedule up [14:45] April 14? [14:45] https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule [14:45] Final Freeze on April 14 [14:45] and we're way past FeatureFreeze [14:46] <_hc> these are all bug fixes in the packaging [14:46] so you'll need to follow https://wiki.ubuntu.com/FreezeExceptionProcess to get it reviewable for FFe [14:46] OK, fire at will ;) [14:47] seamlik: android-platfrom-system-core and android-platform-tools-base ? [14:47] seamlik: and from Debian Testing? [14:48] <_hc> teward: the first package is https://packages.debian.org/source/sid/android-platform-system-core [14:48] and from Testing or Unstable? [14:48] <_hc> hold off on -tools-base [14:48] (where do you want the sync req. to come from) [14:48] <_hc> unstable and testing should be the same, it just happened, but unstable to be safe [14:49] hmm [14:49] !info android-platform-system-core xenial [14:49] Package android-platform-system-core does not exist in xenial [14:49] hate the bot [14:49] Oh, android-platform-build [14:49] source packages are better ;) [14:49] okay, so... [14:50] teward, _hc: android-platform-system-core package already sync'd [14:50] yep [14:50] i was going to say that [14:50] E:Versions match [14:50] :P [14:50] <_hc> ah, ok, I guess I should look at the ubuntu tools rather than the debian tools here :) [14:50] ginggs: though, rmadison shows a delta between sid and xenial/universe [14:50] are we absolutely certain they're in sync? [14:51] sync'd 5 minutes ago [14:51] Thank you! [14:51] ah, nice, so rmadison isn't updated :) [14:51] * teward goes back to figuring out why his boxes are deady [14:51] dead* === francisco is now known as Guest9390 [14:51] sponsored by LocutusOfBorg for Mapreri [14:51] even better :) [14:52] Mapreri helped a lot during the migration [14:52] _hc: what was the other one? [14:52] <_hc> android-platform-build [14:53] i get the same notice about version match for that too [14:53] ginggs: ^ [14:53] <_hc> the android-platform-tools-base update requires a new package to xenial, so that's probably not feasible [14:53] <_hc> liblombok-ast-java [14:53] my squid proxy on my net is dead, so... I can't check easily [14:54] as of a couple minutes ago 'cause i broke it :/ [14:54] android-platform-build was also sync'd already [14:54] <_hc> 8 minutes ago, it looks like :) [14:54] you can see https://launchpad.net/ubuntu/+source/android-platform-build and https://launchpad.net/ubuntu/+source/android-platform-system-core [14:54] <_hc> I think we're good then unless seamlik has something to add [14:54] did anyone contact the phone team about these packages (since they maintain their own patched versions of i.e. adb, adbd and fastboot) [14:55] <_hc> I think we've had some contact. these packages don't touch the original android-tools source package, which is what Ubuntu uses for adb, adbd, and fastboot [14:55] ok [14:55] <_hc> Ubuntu already has its own android-tools anyway, for a while now [14:56] we tried to sync it at one point [14:57] well, that's all we need for now :) [14:59] <_hc> it would be great to move adb and fastboot out of the android-tools package. We have more up-to-date adb and fastboot building in the Android Tools Team packages, but they only build on amd64 and i386. So someone would need to port things to all the other archs to fully replace the android-tools source package [15:00] you would have to pull in the patches to the udev rules [15:00] (that are added to support ubuntu devices) [15:01] (beyond that fastboot and adb binaries shoudl be fine to use vanilla ... adbd not though ... taklk to the guys in #ubuntu-touch) [15:17] mardy: bug #1564767 fix is now built at https://requests.ci-train.ubuntu.com/#/ticket/1215 - you can mark it as Lander Signoff Approved when ready, although no hurry since qtbase is and will be blocked in xenial-proposed because of mysql-5.7 transition it seems [15:18] bug 1564767 in qtbase-opensource-src (Ubuntu) "Wrong size of embedded window" [Critical,In progress] https://launchpad.net/bugs/1564767 [15:25] What happened to bzr-fastimport? Looks like it disappeared since Wily. [15:25] "(From Debian) RoQA; orphaned, unmaintained upstream, rc-buggy; Debian bug #742416" [15:25] Debian bug 742416 in ftp.debian.org "RM: bzr-fastimport -- ROM; orphaned, unmaintained upstream and rc-buggy" [Normal,Open] http://bugs.debian.org/742416 [15:47] doko: configglue (even upstream bzr) is still not python3.5 compatible, thus the ftbfs [15:47] doko: LP: #1504288 [15:47] Launchpad bug 1504288 in configglue "Test suite failure with Python 3.4 & 3.5" [Undecided,In progress] https://launchpad.net/bugs/1504288 [15:48] doko: i will spend a *little* time looking at an upstream [15:59] xnox: around? Please could you comment on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557830/comments/10 please? [15:59] Launchpad bug 1557830 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb2.6 in xenial, wily, and trusty" [Undecided,New] [15:59] xnox: I'm happy to do whatever you and the release team prefer. [16:05] rbasak, and why do you ask me? I'm not a release team =) [16:05] xnox: because you have reason to care :) [16:05] also what juju upstream supports should not matter what ubuntu archive compiles. [16:05] Yeah [16:05] rbasak, e.g. it should be totally valid to have a client on 32bit controlling 64bit deployments.... [16:06] I think I should change it to "any". [16:06] If it FTBFS on some archs, then the release team can decide whether to let that in or not. [16:06] It doesn't seem right to just turn it off on an arch, since I understand that makes life hard for porters who want a particular arch to work well across the archive. [16:15] stokachu, looking at bignum: please don't use bash as the shebang when plain sh is good enough [16:15] doko: bignum? [16:16] stokachu, you uploaded that to NEW. or can it be removed? [16:16] doko: you talking bout bigdata? [16:16] ahh [16:16] yes [16:17] doko: i can fix the bash string if you want [16:17] stokachu, just for your next upload [16:18] doko: thanks, fixed here https://github.com/Ubuntu-Solutions-Engineering/bigdata-deb/commit/fce9d383a8011e9b31cca01022128dc412afca87 so it'll make it into next upload [16:20] stokachu, debian/copyright is missing 2016, in conjure as well [16:20] stokachu, conjure: why all the pre-built egg files in conjure/dist? [16:21] doko: hmm [16:22] doko: i need to remove those, not sure why they are there [16:23] doko: i fixed it and the copyright, anything else? otherwise i can upload a new package [16:23] stokachu, ok, I'll reject that one. also ubuntui/*.py doesn't have any copyright notices. there might be more of these [16:23] ok ill add those files to copyright [16:24] stokachu, the question is, if these files should contain the copyright, as the other files have it [16:25] doko: yea some are LGPL and AGPL [16:26] stokachu, well, then the debian/copyright is wrong. it only mentions the MIT license [16:26] doko: yep fixing that now [16:28] stgraber, golang-gopkg-inconshreveable-log15.v2-2.11+git20150921.0.b105bd3 debian/copyright is missing the copyright for the term subdir [16:33] doko: thanks, will fix [16:41] stokachu, the update conjure: is it intended that the toplevel files are still covered by the MIT license? [16:41] doko: yea [16:42] aside from those directories i defined [17:47] tjaalton, updated https://bugs.launchpad.net/ubuntu/+source/libset-scalar-perl/+bug/1558820 [17:47] Launchpad bug 1558820 in libset-scalar-perl (Ubuntu) "[MIR] libva" [Undecided,Incomplete] [18:18] doko: cool, thanks [18:27] nacc: I'm having trouble actually building php-fshl locally [18:27] it keeps throwing errors [18:31] Pharaoh_Atem: paste? [18:47] nacc: http://fpaste.org/349497/45979560/ [18:57] infinity: any progress with debugging fpc FTBFS on powerpc yet? [18:57] ginggs: ^^ I don't assume you know more already? [18:58] elbrus: i know nothing! [18:58] :) [18:59] Pharaoh_Atem: hrm, rebuilt fine here [18:59] Pharaoh_Atem: oh, in debian, though [18:59] let me check that [18:59] elbrus: I didn't have time over the weekend to dig deeper. It's on my "free time" TODO this week. [19:00] ack [19:04] mterry: sorry for those late MIRs took forever for those 3 packages to be accepted into xenial (went unreviewed between December and a couple of hours ago...) [19:05] stgraber, lxc team == you? [19:05] Pharaoh_Atem: hrm, built fine in a sid schroot too [19:06] doko: lxc team is hallyn, mmcc, tych0 and I [19:06] doko: jgrimm is also in the team so he can get the rest of the server team up to speed on bugs if we miss any [19:06] stgraber, was the team accepted as a bug subscriber in the past? [19:06] doko: and the server team is also subscribed to those packages separately (jgrimm was working on it now-ish) [19:06] ahh, ok [19:06] doko: yeah, we are the MIR subscribe team for a dozen packages [19:07] stgraber, doko: should be done already even [19:07] doko: https://bugs.launchpad.net/~ubuntu-lxc/+packagebugs those are all the packages that are in main for which the ubuntu-lxc team is the main contact point [19:07] stgraber, mterry: I just did the NEW review, so I'll propose to promote these. just waiting on your feedback [19:08] mterry's feedback [19:08] cool. I poked mterry because he's been handling all our other go-related MIRs this cycle but I'm not picky as to what MIR team member gives the go ahead :) [19:09] I refreshed the go-lxc one with a new snapshot an hour ago to pick up the bugfixes needed for LXC 2.0, the other two looks to be perfectly functional so no reason to update to new upstream snapshots [19:28] superm1: hey, fyi bug #1565963 [19:28] bug 1565963 in seahorse (Ubuntu) "seahorse does not see gpg keys after upgrade to gnupg 2.1" [Undecided,New] https://launchpad.net/bugs/1565963 [19:28] seb128: fyi, ^ [19:30] thanks, i'll take a look [19:50] slangasek: does LP: #1565097 need to be re-uploaded? [19:50] Launchpad bug 1565097 in refdb (Ubuntu) "Update to PHP7.0 dependencies" [Undecided,Fix committed] https://launchpad.net/bugs/1565097 [19:50] slangasek: i don't see it changed yet [19:51] nacc: quite possibly! let's see [19:52] slangasek: jgrimm: i believe i'm down to the last 9 packages that need updating, fyi; a few will be in a broken state (e.g., drupal7 pending drupal8 or drupal7 updates) and i'm still contacting upstreams for a few to see if they have php7 versions we can pull down [19:52] slangasek: but i think we'll be in a position to remove src:php5 soon, if you want, with minimal breakage to the archive, afaict [19:52] nacc, great! [19:53] nacc: my count of remaining affected packages Friday was higher than yours; was your count including or excluding things that were still awaiting sponsorship at the time? [19:53] nacc: are any of the php5/php7 changes you've been shepherding in any way capable of removing a user from the sudo group? specifically anything related to libapache2-mod-php5 and/or a2enmod ? [19:53] nacc: I'm thinking .postinst mostly [19:55] slangasek: including those things still awaiting sponsorship. My count was more of what is left to touch list; the official reverse-depends count is 30 right now, but i submitted a bunch today and some are false-positives due to php5 | php [19:55] TJ-: hrm, in general, i've not changed any fucntionality in the postints, beyond calling the right command (for php5enmod -> phpenmod) or right parameter (a2endmod php5 -> a2endmod php) [19:56] TJ-: so I'd be surprised if that happened, but I'm not going to make any guaranteed; do you have a specific package in mind? [19:56] or a bug, i guess? :) [19:56] nacc: ok. my count as of Friday was 56, and a couple of those are already on the removals list (php-imap, php-mcrypt) but we should reconcile these counts soonish :) [19:56] nacc: maybe you could run your eyes over the following pastebin? A user in #ubuntu+1 reported it and I did some 'live' debugging and we couldn't figure it out, so not even sure it is a bug, and the user re-added themselves so the issue is now dead. http://pastebin.ubuntu.com/15585996/ [19:58] slangasek: yep, let's plan on syncing this afternoon? [19:58] nacc: +1 [19:59] TJ-: looking; but fwiw, i've not actually touched the src:php5 itself, which is a bit out of sync with debian probably [19:59] TJ-: it's goign to be removed [19:59] TJ-: so i'd just suggest to that user they need to migrate asap :) [19:59] TJ-: and/or reproduce it with php7 [20:00] nacc: right... I just wanted to do a heads up since we're so close to release... the trigger might have been a2enmod rather than the package install; hard to know but would be awful for that to escape into the wild [20:00] TJ-: yep, i'll try and reproduce it here in a bit? [20:01] infinity, hi [20:01] nacc: well no great pressure, as I said, the user re-added themselves from a recovery boot and I couldn't find any other mentions of similar stuff. It was a fresh clean install of 16.04 about 45 minutes before it happened, though. [20:02] TJ-: ok, np; but first, lunch! :) [20:02] nacc: supper :) [20:03] tkamppeter: Hi. [20:06] infinity, because of cups-filters. I do not know whether you know that I have made use of the fact that one could run LSB-compliant packages on Ubuntu. [20:06] infinity, for this there was an "lsb" package. Debian pulled this feature out, very shortly before our FF, not letting me a chance to introduce a new package. [20:08] infinity, so as LSB compatibility was actually only used by us to allow manufacturers to supply printer drivers, I have simply re-introduced the LSB compatibility by taking the stuff which was taken out of the lsb package into cups-filters. [20:09] infinity, only that I forgot the postinst in the first place and got a bug report because of this and added it today to complete my work. [20:09] tkamppeter: Yes, I followed your bug report to see what you were doing. cups should not, in any way, be responsible for providing ld.so links, however. [20:10] infinity, so does this mean that I should say LSB driver support is skipped on the LTS or forever? [20:11] tkamppeter: No, it means you should probably talk to Foundations people before deciding to hack around something like this in a printer driver package. :P [20:12] nacc: zend-framework> the prior-version argument to dpkg-maintscript-helper mv_conffile is strongly recommended [20:12] If we decide LSB ld.so links belong anywhere, it should be something reasonably low-level, either a re-introduction of some lsb thing, or in glibc itself. [20:12] nacc: (not blocking this upload on it, but you really want that there so that things eventually clean up) [20:12] tkamppeter: Surely, you see how your method would immediately go sideways if someone else also decides they need that functionality. [20:14] infinity, so what I could perhaps do then is to recover the lsb-source package to its old state, of before Debian took everything out and sync cups-filters with Debian to remove all LSB stuff from it. OK? [20:16] tkamppeter: I don't think reverting lsb is sane either. But leave it to slangasek and I to sort out the best way to solve this one. cups-filters definitely shouldn't have an lsb package, though. [20:16] superm1: I added some more info to the description of the bugs. the secret keys didn't get migrated [20:20] infinity, slangasek, so please check and tell me what is the best solution for that. [20:23] infinity, slangasek, the solution can be a short-term solution for 16.04 only. On the OpenPrinting Summit I will tell manufacturers that the LSB is dead for printing as one of the two principal distro families left the LSB. [20:24] tkamppeter: an LTS in not "short term"; anything deployed here has to be supported on upgrade for 2 years, so needs to be designed carefully. I'm fairly certain the right answer is to put the symlinks in glibc, but I'll leave that to infinity to confirm [20:26] infinity, slangasek, the package in which the symlinks where before was lsb-core, coming from the lsb source package. [20:26] we're aware [20:26] nacc: I'm not quite sure, but I think all of these debian package build tools hate me :/ [20:27] nacc: why does yubikey-ksm call phpenmod in its postinst for a module it does not ship? [20:27] nacc: (not a regression, not blocking the upload, but ugh) [20:31] nacc: mv_conffile, same thing for wikidiff2 [20:42] slangasek: oh sorry, i rusehd that! [20:42] slangasek: will post updated shortly [20:50] should unattended updates show install progress on shutdown? [20:55] slangasek: updated in both [21:13] nacc: 'tcpdf' - that's the Transmission Control Protocolortable Document Format, right? [21:13] slangasek: I'm not sure what you mean by "Robie (the uploader of the version (re?)introducing the recommends" in bug 801244 but I think that's moot now? [21:13] bug 801244 in vblade-persist (Ubuntu) "[MIR] vblade-persist" [Undecided,Won't fix] https://launchpad.net/bugs/801244 [21:13] AFAICT, I've never uploaded a vblade-persist. [21:13] anyone know what "main::scan_file() called too early to check prototype at /usr/bin/aclocal-1.11 line 644." means? [21:13] https://launchpadlibrarian.net/251176532/buildlog_ubuntu-xenial-amd64.google-perftools_2.4-0ubuntu4_BUILDING.txt.gz [21:13] rbasak: you sponsored the upload that reintroduced the recommends: on vblade-persist from vblade [21:13] Ah [21:14] is it code for running autoreconf or something? [21:15] slangasek: ah yes, I remember now. Sorry! Yeah cpaelzer is right. That was to bring vblade closer to sync with Debian so we can stop caring for it in universe next cycle. So no MIR any more so no further action I think. [21:15] (the conffile move needs a delta but that can go > Xenial) [21:15] rbasak: did vblade get uploaded to drop the MIR? (I haven't looked at any of this, was just poking the bug via component-mismatches) [21:16] slangasek: I wasn't aware of the MIR at the time. It was in MoM as needing a merge. We looked, decided we didn't want to maintain a delta, so merged it dropping most of the delta for a graceful removal next cycle. [21:17] rbasak: ok, you can't just drop the delta. It's a component-mismatch; packages in main need to not recommend packages in universe [21:18] it was confusing to have an MIR bug still around from before vblade was promoted, but this still needs to be dealt with [21:18] slangasek: sorry, I missed that. [21:19] rbasak: my recommendation, given the goal of minimizing delta, is to change that Recommends back to a Suggests in vblade; the alternative is to try to make vblade-persist work without ruinit [21:19] sorry, "runit" ;P [21:19] slangasek: I think we might be able to drop vblade from server-ship and get it into universe. [21:19] rbasak: also wfm :) [21:19] but that's a server product decision I guess, --> SEP [21:21] slangasek: heh, i who knows why they named it that way; it appears to be a fork of fpdf, also their website claims "Started in 2002, TCPDF is now one of the world's most active Open Source projects" [21:21] radioactive? bioactive? [21:28] Pharaoh_Atem: can you help me check something; if you install php-pecl-http and neable it, do you see a complaint if you just run `php`? [21:28] nacc: how do I enable it? [21:29] slangasek: SEP? [21:29] Pharaoh_Atem: actually, i think it will be enabled on install [21:29] rbasak: "somebody else's problem" ;) [21:29] Pharaoh_Atem: alternatively, phpenmod http? [21:29] slangasek: ah :) [21:29] slangasek: I'll take care of it [21:29] nacc: is this what you want to see? PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/http.so' - /usr/lib/php/20151012/http.so: undefined symbol: php_resource_factory_init in Unknown on line 0 [21:29] yeah [21:29] it seems like something is not putting in the lib dependency [21:29] that symbol is from raphf [21:30] but `ldd` indicates http.so doesn't load raphf.so, which seems like a mistake [21:30] trying to figure out what's mssing [21:31] see also dlopen() [21:32] raphf.so, implies it's not a library but a plugin of its own; so linking to it is likely wrong [21:32] yeah [21:32] sarnold: true; but not called in this library, and not linked against libdl [21:32] which means it's a runtime dependency [21:32] http.so probably assumes this symbol is resolvable through the parent [21:32] by raphf.so being loaded first [21:32] slangasek: so maybe it's an ordering thing [21:32] could be [21:32] istr something about the order of names does matter [21:32] let me see if i can find it [21:33] is it being linked with -Wl,--no-undefined? [21:33] could also be a scoping issue with the options php itself passes to dlopen() [21:33] Pharaoh_Atem: that would fail at build time if it were [21:33] right [21:34] slangasek: I've passed to kirkland/jgrimm for an ack. If they say yes, I'll unseed it. [21:35] so.... this just happened? http://fpaste.org/349595/59805700/ [21:35] anyone know why usb-modeswitch 2.3.0 isn't available? [21:35] Pharaoh_Atem: because don't try to dist-upgrade to -proposed [21:36] slangasek: I've been living on -proposed for over two months because php things :/ [21:36] Pharaoh_Atem: xenial-proposed is not for human consumption [21:36] I guess I'm not human :) [21:37] you should be doing that in a chroot, not on a desktop root [21:37] rbasak, ack from me (and kirkland gave an email ack to that on Feb 4, as well as, for munin) [21:37] slangasek: eh, it's a VM [21:37] rbasak: vblade? [21:37] rbasak: ack, +1 please drop from main. vblade (aoe) was needed for eucalyptus, many moons ago [21:38] virtual AoE blade emulator [21:38] yep [21:42] jgrimm, kirkland: thanks. Seed changed. [21:42] rbasak, munin too? [21:45] nacc: wikidiff2, zend-framework, please provide incremental debdiffs since the previous are already uploaded [21:47] jgrimm: no but done now, thanks. [21:47] rbasak, thanks! [21:48] nacc: are packages with build-deps but no runtime deps on php5 on your list? (e.g. jscribble) [21:50] slangasek: hrm, I thought I did ? [21:50] slangasek: and no, not build-deps yet, that is next on my list [21:50] slangasek: i just checked both bugs and the last attachment in each is an incremental debdiff? [21:51] nacc: hurrr ok apparently I didn't read it right :) [21:52] nacc: core-dev endorsement: "he writes correct code that I subsequently don't read; give him upload rights" [21:52] slangasek: heh [21:54] pitti: is there an easy way without cgmanager to get myself a shell that is running in its own cgroup? [21:54] I asked hallyn, he suggested I ask you :) [21:54] nacc: wrt php-mongo,php-horde-mongo - there are an awful lot of packages depending on php-horde-mongo, all of which will be broken by this; are we ok with that? [21:55] rbasak: which controllers are you intersted in? [21:55] nacc: oh - nope, these are all recommends, ignore me [21:55] slangasek: right, it should all be recommends [21:55] i should have noted that, but did see that before suggesting its removal [21:55] hallyn: I want to limit CPU and memory. I'm told that limiting memory will stop my entire cache from being dropped if I do something big in there. [21:56] Ideally I want "run-in-cgroup --memory=X --cpu=X /bin/bash" [21:56] (unprivileged) [21:56] you want cpu not cpuset right? [21:56] I'm not sure. [21:57] anyway memory you can do with no privilege with or without cgm; cpu you'd need to edit /etc/pam.d/common-session to add ",cpu" to the libpam-cgfs line [21:57] so in the meantime i'd recommend yeah use cgm. I think we should come up wiht a good systemd based answer and put that into the server guide [21:58] hallyn: OK, thanks [21:58] * rbasak reads up [21:58] Pharaoh_Atem: slangasek: may have found the pecl-http issue, typo -- checking to see if it fixes it [22:00] rbasak: Who's taking ownership of evaluating the removal of the block-proposed tag from https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 ? [22:00] Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Critical,Fix committed] [22:00] jgrimm: ^^ [22:00] Or rharper maybe? [22:00] rbasak: We're probably approaching a point where we're not going to find any more bugs without inflicting it on users. [22:00] I've seen activity, but I'm not sure who's holding the baton right now. [22:01] last I saw was a 1ubuntu4 upload with some fixes from slangasek on the maint scripts; [22:01] And another from me, yes. [22:01] I can give the proposed package a test; but since it was maint stuff, I don't it to modify the functionality w.r.t universe packages we were testing [22:02] rbasak: I didn't get any time to test additional rdepends on squid3 from universe yet; [22:02] we did want to maybe see about maas and squid3 [22:02] Well, we're running out of time to "see about" anything. [22:02] I don't see any reason to hold back [22:03] better to get the hurt ASAP [22:03] rharper: any known issues with what is in -proposed currently? [22:03] That was sort of my thinking. [22:03] Sorry, I haven't really been following along. [22:03] rbasak: none that I'm aware of [22:03] I'm sure we missed some bugs, but I've fixed the ones *I* run into. [22:03] So, I need other people to find more. :P [22:03] OK, let's drop the tag as I don't hear any objections. [22:03] * rharper nods [22:03] unless we want to risk keeping squid3 out-of-date for another LTS, we should let 'er rip [22:03] heh [22:03] not after all of this trouble [22:03] And someone might want to merge the new upstream after we let this one through. [22:03] Because more bugs. [22:03] 3.5.15 (new stable IIRC) [22:04] yes there may be some knock-on effects, but we need to find them before we can sort them out, and at this point we need it in xenial before we're likely to find them [22:04] yep [22:04]