=== _salem is now known as salem_
=== salem_ is now known as _salem
[06:30] <cpaelzer> good morning
[06:35] <Unit193> Howdy.
[09:16] <rbasak> mysql++ fails due to -fPIE, according to Skuggen, and this comes from dpkg-buildflags. Is there documentation around this?
[09:16] <rbasak> I know about https://wiki.ubuntu.com/Security/Features#pie, but that suggests a whitelist only.
[09:16] <rbasak> <Skuggen>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie fixes it
[09:17] <rbasak> So what's our rationale, and how should we approach this?
[09:18] <rbasak> In a Zesty container, "dpkg-buildflags" doesn't give me -fPIE. Is this a mismatch against the whitelist?
[09:19] <Skuggen> I haven't tracked exactly where it comes from (but it's from /usr/share/dpkg/buildflags.mk and the package's own libtools file)
[09:20] <tsdgeos> seb128: ping re https://code.launchpad.net/~aacid/geonames/more_liberal_city_search/+merge/316102
[09:20] <seb128> tsdgeos, oh right, going to try to do that today, thanks for the reminder
[10:56] <jbicha> nacc: I forwarded the php-imagick changes to Debian, I see imagemagick is still stuck because of emacs :(
[11:07] <infinity> rbasak: PIE has been on by default (in the compiler itself, not in buildflags) for a couple of releases now.
[11:08] <infinity> rbasak: That wiki page is hopelessly out of date.
[11:08] <infinity> rbasak: Oh, except it's not.  See the end of the bit you referenced:
[11:08] <infinity> rbasak: "PIE on 64-bit architectures do not have the same penalties, and will eventually be made the default (as of 16.10, it is the default on amd64, ppc64el and s390x)."
[11:11] <Unit193> Could always do something like parole does, export DEB_LDFLAGS_MAINT_STRIP=-Wl,-Bsymbolic-functions  though changing it to suit.
[11:12] <rbasak> infinity: ah. Thanks.
[11:13] <rbasak> infinity: I'm not sure how to resolve this though. Mind glancing at http://paste.ubuntu.com/23965945/ please?
[11:14] <rbasak> Skuggen reports that a main function is declared, which seems odd for a shared library.
[11:14] <jbicha> there's some pie weirdness I think is related to Ubuntu having an older dpkg than Debian
[11:15]  * rbasak wonders if that's a "don't export a main symbol then".
[11:17] <rbasak> cpaelzer: are you planning to glance again at my squid3 merge, or should I just upload it?
[11:18] <cpaelzer> rbasak: the findings I had were all of a kind that I don't tihnk I need to re-evaluate
[11:18] <cpaelzer> I read the diff now
[11:19] <cpaelzer> thanks for adding
[11:19] <rbasak> cpaelzer: OK thanks! I'll upload.
[11:19] <cpaelzer> rbasak: read and acked on th MP now
[11:26] <rbasak> cpaelzer: I forgot to mention, nis import complete. I guess you knew that :)
[11:26]  * rbasak just found that window
[11:29] <mardy> Mirv: hi! :-) https://github.com/tjyrinki/qt58/issues/1
[11:29] <mardy> first! :-p
[11:32] <cpaelzer> rbasak: thanks, yes I see it in proposed atm
[11:38] <rbasak> cpaelzer: does grep-merges work for you? If not, fancy fixing it for more of that core dev experience? :-) I have a patch, just needs landing :-)
[11:38] <rbasak> http://paste.ubuntu.com/23966354/
[11:39] <cpaelzer> I nack that on this special Friday
[11:39] <rbasak> OK :)
=== czchen_ is now known as czchen
=== _salem is now known as salem_
[12:42] <fossfreedom_> andyrock: I've got a valgrind trace (attached to the bug report) for the gnome-menus issue.  I think it is saying that there is a weak-pointer deallocation issue - any chance you can have a quick squint at the log please? https://launchpadlibrarian.net/305825578/valgrind.log bottom of the trace
[12:43] <andyrock> sure
[12:43] <andyrock> not at home right now
[12:44] <andyrock> but will be soon
[12:44] <fossfreedom_> many thanks
[12:57] <Mirv> mardy: yes, replied there :)
[12:57] <mardy> Mirv: any reason why that qmake plugin is not the default one?
[13:08] <Mirv> mardy: well the qmake plugin is required to find the dev sources when building the app itself. the autotools plugin override is then for the actual Qt configure.
[13:08] <Mirv> so, overriding things
[13:26] <sil2100> rbasak: hey! I have a question regarding SRUs to -backports - I see in yakkety a new pbuilder targetting yakkety-backports, is that bypassing proposed then and going straight to -backports?
[13:26] <sil2100> rbasak: I must say I have no experience with -backports so I don't know the rules regarding those
[13:28] <rbasak> sil2100: AFAIK, that's not a job for ~ubuntu-sru, so you can ignore it.
[13:28] <rbasak> There's a separate backporters team.
[13:29] <sil2100> Oh!
[13:29] <sil2100> Ok
[13:30] <sil2100> Thanks
[13:31] <Laney> does anyone know anything about the emacs25 ftbfs on arm64/zesty?
[13:32] <rbasak> So grep-merges appears completely broken. I filed bug 1663601. I would just upload a fix, but I can't upload to ubuntu-dev-tools in Debian and the package is in sync.
[13:32] <ubottu> bug 1663601 in ubuntu-dev-tools (Ubuntu) ""grep-merges" fails with "TypeError: sequence item 0: expected string, NoneType found"" [Medium,Triaged] https://launchpad.net/bugs/1663601
[13:33] <rbasak> tumbleweed: ^ or should I just throw in a delta?
[13:36] <cult-> xnox: how's the process going on with the ubuntu releases of the bugfix?
[13:37] <xnox> cult-, all status is up to date on launchpad.... all done in zesty. haven't looked at stable releases yet, busy with 16.04.2.
[13:38] <cult-> is it going to be included in 16.04.2 the fix i mean?
[13:50] <cult-> xnox: no worries,i'm waiting for the launchpad notifications everyday :)
[14:03] <xnox> cult-, did you not get a tonne of updates yesterday? are you subscribed to the bug report?
[14:03] <cult-> xnox: i got all of them, i am just waiting for it to be done in 16.04 hence i was asking if its included in 16.04.2 ?
[14:03] <xnox> cult-, there is no such thing as 16.04.2.... point release is install media only.
[14:04] <cult-> ah, ok
[14:04] <xnox> cult-, the update to that package, when it happens, will land in xenial-updates, which is were all the updates land for all of xenial, for all of its lifetime.
[14:05] <xnox> 16.04.2 install media, is important as it comes with newer kernel; such that one can boot the installer media on newer hardware. Otherwise, installed systems look the same for the updates point of view.
[14:05] <cult-> ok, but when you done the changes, what other things have to be done?
[14:08] <cult-> i choosed ubuntu because it has the correct balance between stability(LTS releases) and repository updates. fedora's lifecycle is too short, redhat repos are ancient.
[14:09] <andyrock> https://www.irccloud.com/pastebin/asXsO3un/
[14:09] <andyrock> so try to add the g_object_remove_weak_pointer line
[14:09] <cult-> but unfortunately the library software in question is completely unusable
[14:09] <andyrock> can you test this?
[14:10] <andyrock> fossfreedom_:
[14:11] <andyrock> ^^^
[14:11] <fossfreedom_> andyrock: yes - will do.  Thanks.
[14:13] <andyrock> let me know
[14:13] <fossfreedom_> andyrock: I was just now wandering through gobject documentation about weak-pointers - https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#GWeakRef  was wandering if this was a threading issue.  But yeah - force unallocation is the right was to go.
[14:14] <andyrock> i don't think it's a threading issue
[14:14] <fossfreedom_> * wandering wondering
[14:14] <andyrock> let's test this otherwise will make it thread safe too
[14:14] <andyrock> the problem is that when menu_monitor->monitor is freed
[14:15] <andyrock> the weak ptr system will try to nullify a ptr that is no longer valid
[14:15] <andyrock> because already freed
[14:15] <seb128> fossfreedom_, see, valgrind gave you the error :-)
[14:17] <fossfreedom_> seb128: :)  cross-fingers
[14:17] <seb128> fossfreedom_, well, not saying you have the right fix yet but the log has a clear invalid memory usage error which leads to your segfault
[14:55] <andyrock> fossfreedom_: any news?
[14:58] <fossfreedom_> andyrock: ah - should have clarified ... at work for the next couple of hours
[15:12] <andyrock> np
[15:12] <andyrock> :D
=== JanC is now known as Guest6853
=== JanC_ is now known as JanC
[16:20] <nacc> Laney: no, but as it's blocking imagemagick, I can try and reproduce and look around. Googling implies similar errors were reported in 2015, but not a segfault
[16:21] <Laney> nacc: Ya, I found that
=== elbrus_ is now known as elbrus
[16:38] <nacc> sarnold: mdeslaur: to enable http2 on apache2, we'd need to MIR libnghttp2-14 (src:nghttp2). Given where we are in the cycle, would you suggest keeping the extension disabled and focusing on enabling it first thing in 17.10? It's enabled in Debian, and it was disabled in Ubuntu in 16.04 due to its newness & the LTS.
[16:39] <mdeslaur> nacc: does upstream apache still consider it experimental?
[16:40] <rbasak> It does seem that way: https://httpd.apache.org/docs/2.4/mod/mod_http2.html
[16:41] <mdeslaur> if they don't consider it production quality, perhaps we should wait
[16:41] <mdeslaur> but it would make sense to do it first thing in 17.10
[16:41] <mdeslaur> in preparation for the next lts
[16:44] <nacc> mdeslaur: ah ack, thanks! i'll fix up my merge in -proposed
[16:44] <nacc> mdeslaur: and i'll make a note in the bug
[16:44] <nacc> thank you both!
[16:55] <nacc> jgrimm_: --^ that should on our z+1 blueprint :)
[16:56] <infinity> rbasak: PIE for a library is redundant with PIC anyway.  No harm in just disabling the flag.
[16:58] <jgrimm_> nacc, i'm not sure if we need anything explicit.. we've previously decided to carry delta to disable http2 in apache2 until it becomes non-expirimental
[16:58] <jgrimm_> nacc, are you suggesting we want to reassess that position and enable it anyway?
[16:59] <nacc> jgrimm_: in the interest of 17.10 being a precursor to 18.04 (where I think we'd want it available), we want to look at how stable it is in practice at that point
[17:00] <rbasak> infinity: OK. Thanks!
[17:00] <rbasak> Skuggen: ^ up a bit
[17:00] <jgrimm_> nacc, sure. general task to just check where things are at
[17:00] <nacc> jgrimm_: yeah
[17:02] <jgrimm_> nacc, fwiw i've started using the blueprint whiteboard as place to just capture deferred/next-cycle/as time permits
[17:02] <jgrimm_> nacc, and added apache http2 there
[17:02] <nacc> jgrimm_: ah ok, thanks! was going to ask
[17:02] <jgrimm_> nacc, mentioning in case you ever want to just add things yourself
[17:02] <jgrimm_> col
[17:02] <jgrimm_> cool
[18:03] <mapreri> rbasak: that said, who/where is the backports team?
[18:09]  * mapreri tries poking one name from https://launchpad.net/~ubuntu-backporters/+members
[18:18] <rbasak> mapreri: I think that's the team, yeah.
[18:19] <mapreri> I find the documentation in the wiki extremely confusing, or with many shortcomings.
=== salem_ is now known as _salem
=== fginther` is now known as fginther
[18:48] <sarnold> nacc: thanks for thinking ahead on that one.
[18:49] <sarnold> nacc: I think mdeslaur's suggestion is the way to go; I surely hope they consider it non-experimental before 17.10, it'd be nice to bake it in an interim release first.
[18:50] <nacc> sarnold: ack
=== _salem is now known as salem_
[19:03] <nacc> rbasak: heh, I think I found a piece of missing delta in openldap since natty ...
[19:04] <nacc> rbasak: that implies (I think), the apport hook hasn't been installed for openldap sinc then
[19:04] <tarpman> oh, really
[19:05]  * tarpman oops
[19:05] <nacc> tarpman: yeah ... it got dropped by the 2.4.23-6ubuntu1 merge.
[19:05] <nacc> sadly, it was only added in 2.4.23-0ubuntu1
[19:05] <tarpman> ah, before my time. ok, I have an alibi :D
[19:05] <nacc> :)
[19:05] <nacc> and it's just been carreid forward semi-automatically ever since as being in the changelog, but not actually being in the package
[19:05] <nacc> git ftw!
[19:06] <tarpman> the delta could really use a going-over... is likewise even in ubuntu any more?
[19:12] <nacc> tarpman: rebasing now, i'll show you the current delta to get your opinion
[19:26] <nacc> tarpman: http://paste.ubuntu.com/23968631/
[19:27] <nacc> tarpman: if you'd prefer a git tree, i can push it up for you to look at
[19:30] <tarpman> nacc: pm
[19:30] <nacc> ack
[20:22] <nacc> Laney: I assume you saw dannf's bug? (LP: #1656474)
[20:22] <ubottu> Launchpad bug 1656474 in emacs25 (Ubuntu) "FTBFS on arm64: make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)" [Undecided,Confirmed] https://launchpad.net/bugs/1656474
[20:22] <nacc> dannf: had you made any progress on it?
=== salem_ is now known as _salem
[21:13] <fossfreedom> andyrock: brilliant news - (with a small alteration) the suggested gnome-menus patch works!  Many thanks for all your help with this.  I have attached a debdiff for the patch to the bug report https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1631745
[21:13] <ubottu> Launchpad bug 1631745 in gnome-menus "Ubuntu Budgie - panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress]
[21:16] <andyrock> why the  event_info = g_new0 (MenuMonitorEventInfo, 1);
=== _salem is now known as salem_
[21:18] <andyrock> fossfreedom: ^^^
[21:19] <fossfreedom> andyrock: hmm - let me rerun the debdiff again - I didnt intentionally make that change.  just a sec
[21:19] <andyrock> ok so the only change is that you moved the line inside the if
[21:19] <andyrock> right?
[21:19] <fossfreedom> yep - exactly that
[21:19] <andyrock> makes sense
[21:24] <andyrock> fossfreedom: also the debdiff is ok
[21:24] <andyrock> is a patch to a patch
[21:25] <andyrock> so it's fine
[21:26] <fossfreedom> ah - ok. cheers
[21:50] <nacc> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: nacc
[21:52] <nacc> powersj: i'm assuming in LP: #1663329, you meant the delta was merged into Debian? (before [1])
[21:52] <ubottu> Launchpad bug 1663329 in nagios-nrpe (Ubuntu) "[Sync Request] Sync nagios-nrpe (3.0.1-3) from Debian unstable (main)" [Medium,Confirmed] https://launchpad.net/bugs/1663329
[21:54] <Unit193> Oh handy, I just filed a RFS in Ubuntu. \o/
[21:54] <nacc> Unit193: bug #? I can close that one too
[21:54] <Unit193> LP 1663754
[21:55] <ubottu> Launchpad bug 1663754 in deluge (Ubuntu) "Please merge from Debian" [Undecided,New] https://launchpad.net/bugs/1663754
[21:55] <nacc> Unit193: thanks
[21:57] <Unit193> Thank you.
[22:02] <nacc> Unit193: just threw a comment in the bug asking for one small tweak
[22:06] <Unit193> Ah right, sure.  Notice how it has d/p/ubuntu.series?  I poked the Debian (and Ubuntu) maintainer once about https://anonscm.debian.org/cgit/users/unit193-guest/deluge.git/commit/?id=d65670c15990838b8b1b1447ac99ca5f5194fd23 but sadly didn't get anywhere.
[22:07] <nacc> Unit193: yeah that seems like it would be cleaner, but it's also a relatively trivial delta to carry
[22:07] <nacc> Unit193: did the Debian maintainer respond at all?
[22:08] <Unit193> nacc: It was a memo, so I got notified he read it but nothing more.  And it's small, but so small and simple to fix.  Done on the bug.
[22:08] <nacc> Unit193: yeah, that's frustrating.
[22:08] <nacc> Unit193: thanks for the quick turnaround!
[22:09] <Unit193> nacc: No, thank you!
[22:21] <nacc> anyone able to see why https://launchpad.net/ubuntu/+source/libapache2-mod-perl2/2.0.10-2ubuntu1 is indicating failure only on some arches, due to missing dependency? Is it a timing thing? https://launchpad.net/ubuntu/+source/apache2/2.4.25-3ubuntu2 indicates it should be available for all architectures, iiuc?
[22:23] <nacc> if an AA is around, could they approve the new openldap binary for zesty?
=== salem_ is now known as _salem
[22:33] <Unit193> nacc: Huh, interesting bit about the sponsor tool not liking that dist, wondered why it was switched to zesty on my last sponsorship, guess that's likely why.
[22:36] <nacc> Unit193: yeah, it offered to let me manually fix it (it might even have prompted for automatic, I don't recall). It's a small and easy thing, so no big deal.
[22:38] <ilmaisin> xnox: what's the status of submitting the official sru to #1642966? is there anything that someone without advanced programming skills would be able to help with?
[22:39] <nacc> as to my apache2 question earlier, i've answered it myself, apparently it's because my openldap version showed up in between and so the pending binaries need to be present for libldap-common to be available
[22:40] <powersj> nacc: good catch yes I meant Debian, updated the bug
[22:41] <nacc> powersj: np, figured as much
[23:33] <nacc> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: