[00:00] <sarnold> "It"?
[00:00] <infinity> mwhudson: I'm quite sure their test likely sucks.  Though, it might suck because it relies on docker, giving them multiple layers of suck.  I'm happy to smear the blame around.
[00:04] <infinity> mwhudson: But yes, I think we can ignore the fan failure as "probably not docker's fault".
[00:04] <mwhudson> infinity: hooray, or words to that effect
[00:05] <nacc> rbasak: can you take a look at LP: #1675924
[00:05] <ubottu> Launchpad bug 1675924 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.17-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1675924
[00:05] <mwhudson> in entirely unrelated news, why the heck is networkd not noticing a new network device when i hotplug it with the qemu monitor
[00:06] <infinity> Huh.  How did 6pm happen already?
[00:18] <nacc> powersj: should we start skipping certain packages that don't need triaging by our rota? e.g., lxd, cloud-init, curtin?
[00:18] <nacc> powersj: maas comes to mind as well, and juju
[00:19] <powersj> nacc: I completely agree; I'm trying to remember why we didn't filter them out in the past. When I do triage I tend to glance at those packages and 99% of the time move on.
[00:19] <nacc> powersj: right, maybe put in a flag for --show-all, but by default, let's skip some that don't need triaging
[00:20] <nacc> powersj: also, we should clarify whether triaged/incomplete bugs shoudl show up (i have taken to just subscribing myself when i mark that state change in a bug and then if they change it back i get notified)
[00:21] <powersj> nacc: I do think those should continue to show up. If an update happened it is nice if I am the one triaging to help push it along more. I do see that you and cpaelzer subscribe yourselves to bugs as well though.
[00:23] <nacc> powersj: right, i treat those as relatively different priorities :)
[00:23] <nacc> powersj: and triaged should mean ubuntu-server was subscribed, meaning we all get those e-mails, right?
[00:24] <powersj> I don't :)
[00:25] <nacc> hrm
[00:25] <powersj> nacc: well I get some from updated bugs, but I don't think I get everything
[00:25] <nacc> powersj: i wondered about tht
[00:25] <nacc> powersj: ok, there's room for improvement regardless
[00:25] <nacc> powersj: also, i'm using rbasak's fork, because it has some good changes
[00:25] <nacc> powersj: and the script now throws some backtraces on 17.04 :)
[00:25] <nacc> non-fatal ones, but import failures
[00:26] <powersj> nacc, for example today I got a ton about lvcreate, but I didn't see any emails from the triaging you or I did today.
[00:27] <powersj> nacc: ha! ok time to look at his fork again. Last time he told me it was WIP
[00:28] <nacc> powersj: ok, it might be, but it might be worth getting it to merged :)
[00:28] <powersj> nacc: yeah I'll take a look tomorrow
[00:31] <nacc> powersj: thanks
=== salem_ is now known as _salem
=== maclin1 is now known as maclin
[07:07] <cpaelzer> xnox: the z-p checks on lvm2 failed for docker.io, but the fail is a docker.io one which is fixed in recent versions
[07:07] <cpaelzer> xnox: would you mind retriggering the test to pickl up the latter fixed docker version so that lvm2 can pass?
[07:34] <KeithW> Hi, I am the DM of mosh (in Ubuntu universe). Zesty currently has a release candidate (mosh 1.3.0~rc2-1) synced from Debian sid. Debian sid now has the final release (1.3.0-1).
[07:34] <KeithW> We filed https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1676218 requesting an FFe/sync of the final release. (Changes are minimal.) Is there anybody I should ping to make sure it gets looked at by the right people in the release team? Thanks for any help on this.
[07:34] <ubottu> Launchpad bug 1676218 in mosh (Ubuntu) "[FFe] Sync Mosh 1.3.0 instead of release candidate" [Undecided,New]
[07:41] <seb128> KeithW, if the update has no new feature compared to what is currently in the archive you don't need a ffe
[07:44] <KeithW> seb128: Thanks -- how do I ask for a sync then?
[07:45] <smb> infinity, mwhudson as in email reply fan tests fail because nc now does no longer fail with data errors which were by chance not causing the test to fail but now fail with timeout because netcat-openbsd upstream decided in their great wisdom that closing a connection when local input closes is now an optional thing.
[07:45] <seb128> KeithW, you subscribe ubuntu-sponsors on that bug so it's in the sponsoring queue
[07:46] <seb128> KeithW, you can also ask on this channel as you did, I'm going to have a look
[07:46] <KeithW> Thanks!
[07:49] <seb128> yw!
[07:52] <seb128> KeithW, done, https://launchpad.net/ubuntu/+source/mosh/1.3.0-1
[07:57] <KeithW> seb128: Thanks much!
[07:57] <seb128> KeithW, np, thanks for the work/filing the sync request and watching after the ubuntu version ;-)
[08:37] <xnox> cpaelzer, retriggered
[08:38] <cpaelzer> thanks, lets hope it picks up the new one now
[08:41] <alkisg> xnox: hi, could you please have a look at two bugs in friendly-recovery, in which I've attached patches and everything should be ready to commit and then maybe even SRU?
[08:42] <alkisg>  
[08:42] <alkisg> https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1675805
[08:42] <ubottu> Launchpad bug 1675805 in friendly-recovery (Ubuntu) "Friendly recovery uses invalid font" [Undecided,New]
[08:42] <alkisg> https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1675824
[08:42] <ubottu> Launchpad bug 1675824 in friendly-recovery (Ubuntu) "system-summary fails due to missing file /sys/.../scaling_available_frequencies" [Undecided,New]
[08:43] <alkisg> In the first one, friendly-recovery.service has 2 syntax errors, while in the second one, it tries to read a /sys/.../file that doesn't exist in 90% of the cases
=== vigo_ is now known as vigo
[09:38] <sil2100> tjaalton: hey! It seems your latest xf86-input-wacom upload caused xserver-xorg-input-wacom to be uninstallable
[09:39] <sil2100>  xserver-xorg-input-wacom : Depends: xorg-input-abi-22
=== marcusto_ is now known as marcustomlinson
[10:03] <tjaalton> sil2100: because there's a new xserver
[10:03] <tjaalton> with -abi-24
[10:04] <tjaalton> 0.34.0 is installable, or should be
[10:05] <sil2100> tjaalton: ah, I see it's now fetchable through apt - I saw the new version in -proposed through launchpad but it seems apt didn't see it yet (same for all the builders)
[10:05] <sil2100> tjaalton: yeah, seems to work now
[10:06] <sil2100> I actually thought the new upload was broken, but it seems it was fixing the breakage, just I tried using it too early
[10:08]  * Laney eyes sil2100 
[10:08] <Laney> you're using zesty-proposed?
[10:08] <sil2100> No, but our Bileto PPA builds do!
[10:09] <sil2100> And I checked what happened in my zesty-proposed chroot
[10:10] <Laney> ok, you can live :P
[10:12] <sil2100> phew!
=== hikiko is now known as hikiko|bbl
[11:21] <onlinedbug> Hey, where is a good place to file a bug about packages installed by default?
[11:22] <onlinedbug> Such as requesting to stop installing package X as a default because it is deprecated
[11:24] <cpaelzer> onlinedbug: at the package itself in launchpad?
[11:26] <onlinedbug> cpaelzer, fair enough, was making sure this is the right place
[11:27] <onlinedbug> I just don't want the report to go unnoticed because it's posted in the launchpad of a basically deprecated package
=== hikiko|bbl is now known as hikiko
[11:36] <onlinedbug> anyway where are the default package determined?
[11:37] <onlinedbug> I mean there gotta be a list the aggregates everything no
[11:38] <onlinedbug> nvm im @ https://wiki.ubuntu.com/SeedManagement now
[11:38] <onlinedbug> ty
[11:38] <cjwatson> well, a lot of that happens by way of dependencies, but more or less the top-level master list is in the seeds
[11:39] <cjwatson> so https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.zesty etc.
[11:39] <cjwatson> the specific details in the wiki page will be somewhat out of date but the broad brush is close enough
[11:43] <cpaelzer> onlinedbug: also if there is an obvious successor you can add that as additional bug task to make to be seen more
[11:44] <onlinedbug> not really. I'm looking at libwmf, if you are wondering. It's installed by default on every desktop and it has many security flaws. I can't bother to list everything now, so I'm just making a request to deprecate it specifying the reasons
[11:44] <onlinedbug> Nobody had touched it since 2000-09-13.
[11:45] <onlinedbug> correct me if I'm wrong
[11:47] <cjwatson> you're wrong
[11:47] <cjwatson> I haven't checked its upstream status but it's had security patches in Debian/Ubuntu much more recently than that
[11:48] <onlinedbug> cjwatson, where can I see that?
[11:48] <onlinedbug> I'm just not very familiar with bazaar, it's really confusing.
=== _salem is now known as salem_
[11:48] <ginggs> https://launchpad.net/ubuntu/+source/libwmf/+changelog
[11:48] <cjwatson> bzr isn't relevant - just look at the installed package's changelog
[11:48] <ginggs> http://metadata.ftp-master.debian.org/changelogs/main/libw/libwmf/unstable_changelog
[11:49] <ginggs> Ubuntu is missing the security fix from 0.2.8.4-10.6 though
[11:50] <cjwatson> it's in the desktop due to a dependency from libmagickcore-6.q16-2-extra I think
[11:51] <ginggs> rbalint: ^
[11:52] <onlinedbug> well this complicates things then. I guess it's more reasonable to post specific bug reports/cve's then...
[11:52] <cjwatson> probably, yes
[11:53] <onlinedbug> it becomes a real hassle because nobody is working on the original project though
[11:54] <rbalint> ginggs: yes
[11:54] <cjwatson> I agree that it's pretty dead upstream at the moment (though the last date I found was 2005-07-27 rather than 2000-09-13), but it still looks like it would better to fix where necessary than remove
[11:54] <cjwatson> s/would better/would be better/
[11:55] <rbalint> i fixed it a once indeed
[11:56] <cjwatson> if removal were eventually necessary it would have to be by carefully going through everything that depends on it and working out if it's possible to replace the functionality with something else, or otherwise how to deal with deprecating/removing functionality
[11:56] <cjwatson> which is generally a very case-by-case exercise, of course
[11:56] <onlinedbug> mmm so from what I understand, the package itself has a baazar source, that's been updated in 2005, and since then all changes are patches to the package?
[11:57] <cjwatson> I didn't check what VCS it happened to be hosted in at the time, but the last upstream release has files dated in 2005, yes
[11:58] <cjwatson> and yes it seems to have been maintained by downstream patching since then
[11:58] <onlinedbug> is this normal with open source projects?
[11:58] <cjwatson> it's not ideal but it happens
[11:58] <onlinedbug> it just seems like a real mess to me
[11:58] <cjwatson> original authors move on and sometimes it's a project that's sufficiently done that nobody cares to take over
=== salem_ is now known as _salem
[11:59] <onlinedbug> well that's fair
[11:59] <cjwatson> sometimes somebody is eventually motivated to take over
[12:00] <onlinedbug> one thing that bothers me the most is that libwmf uses gd 2.0.1 beta, which is a project which had been continued and now developed as libgd2
[12:01] <onlinedbug> and there are many security updates that's been added to it
[12:01] <onlinedbug> which are not applied to libwmf which uses hard coded gd
[12:01] <rbasak> nacc: bug 1675924: looks like the reporter deleted /etc/mysql/conf.d/, so the server is expected to fail to start, so not a bug - commented and marked Incomplete with one of my usual templates.
[12:01] <ubottu> bug 1675924 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.17-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1675924
[12:03] <cjwatson> mm, sounds like somebody should work out exactly what changes were made to libwmf's vendored copy and whether any still need to be upstreamed, then work out how to build it against an external library
[12:03] <cjwatson> would be a great thing for a new upstream maintainer to do ;-)
[12:04] <rbasak> powersj, nacc, cpaelzer: maybe worth having a brief sync on how the triaging is going, proposed script and process modifications and so on?
[12:04] <rbalint> cjwatson: as i remember libwmf was not terrible, just a little buggy when i did the update
[12:05] <onlinedbug> I'll try to see if I do it myself, but in the meantime I'll post a bug report in case I can't make enough time to take care of this. cjwatson and everyone else thanks for your time and clarifications :-)
[12:10] <rbalint> onlinedbug: i see no important security issues for libwmf in Debian
[12:11] <rbalint> onlinedbug: i can upload a patch merging the missing one if you want to open the bug about that
[12:24] <tjaalton> https://wiki.ubuntu.com/Debug%20Symbol%20Packages shows that foo-security should be in ddebs.ubuntu.com, but they are not
[12:24] <tjaalton> so, where are they?
[12:24] <cpaelzer> rbasak: if you have any new major things to discuss I'm around
[12:24] <cpaelzer> rbasak: nacc might not yet be around
[12:25] <rbasak> cpaelzer: nothing new, just a catch up
[12:25] <cpaelzer> rbasak: 30 mins beofre the IRC meeting maybe?
[12:25] <rbasak> And maybe trying to land my changes into Josh's tree.
[12:25] <rbasak> Sure
[12:25] <cpaelzer> rbasak: to have a chance to be all around?
[12:25] <cjwatson> tjaalton: packages from -security are copied to -updates
[12:25] <tjaalton> ok
[12:25] <cjwatson> (unless there's a conflict, but that's v rare)
[12:25] <tjaalton> so the wiki don't need that
[12:25] <tjaalton> line
[12:25] <cjwatson> yeah
[12:26] <cpaelzer> rbasak: btw I have a uvtool merge request for you about the per arch templates in a few minutes
[12:26] <cpaelzer> rbasak: I'd only do so for the master or do you want potential changes to the ubunut/devel branch right away?
[12:26] <cpaelzer> not sure if any are needed actually
[12:28] <cpaelzer> no, not needed since dh_auto will take care of everything
[12:28] <cpaelzer> rbasak: thanks for /usr/share/uvtool/libvirt/template.xml not being a conffile
[12:32] <cpaelzer> rbasak: submitted
[12:37] <cpaelzer> cjwatson: would mind sponsoring the X/Y versions of our ssh fix on bug 1668093?
[12:37] <ubottu> bug 1668093 in openssh (Ubuntu Yakkety) "ssh-keygen -H corrupts already hashed entries" [High,Triaged] https://launchpad.net/bugs/1668093
[12:46] <cjwatson> cpaelzer: done, sorry for the delay
[12:47] <cpaelzer> cjwatson: thank you - I don't mind the delay
[12:47] <cpaelzer> cjwatson: just wanted to close a potential race with e.g. sucurity updates
[12:48] <cjwatson> indeed
[12:49] <tinoco> Hello. Could someone please upload https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1317491 to -updates when gets a chance ? Verification was already done long time. Thank you.
[12:49] <ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed]
[12:53] <camako> tjaalton, I implemented EGL_KHR_platform_mir. Is there still time to include this or have you already started the landing process?
[12:54] <tjaalton> camako: haven't uploaded yet
[12:54] <tjaalton> or committed
[12:55] <camako> tjaalton, do you mind if I send it your way?
[12:55] <tjaalton> camako: is it closed to what will be upstreamed?
[12:55] <tjaalton> closer
[12:55] <tjaalton> feel free to
[12:56] <camako> tjaalton, yes very close... though the enum might be changed by khronos (the spec has not been ratififed - waiting on our implementation)
[12:56] <tjaalton> cool
[12:56] <camako> thanks
[13:01] <morphis> mardy: I saw your mail but didn't had time to look into it yet
[13:04] <mardy> morphis: ok, thanks for the ack
[13:26] <tjaalton> LocutusOfBorg: do you want to handle bumping the xorg abi on vbox?
[13:27] <tjaalton> LocutusOfBorg: actually, since it doesn't have the video driver anymore, perhaps just drop the abi dep
=== _salem is now known as salem_
[13:49] <sil2100> LocutusOfBorg: hey! You tracking the systemd merge you did for zesty?
[13:49] <sil2100> LocutusOfBorg: it seems the autopkgtests are failing here and there
[13:50] <LocutusOfBorg> tjaalton, feel free to fix it, if you think it is useless, yeah drop it
[13:50] <LocutusOfBorg> I admit I have really low knowledge on that stuff, and it gives me headaches
[13:52] <LocutusOfBorg> sil2100, I don't know how to fix that, because they seems to fail but for unrelated reasons (new kernel is the culprit?)
[13:52] <LocutusOfBorg> so I would prefer somebody (pitti?) having a look ;p
[13:52] <tjaalton> okay
[13:53] <LocutusOfBorg> just please try to create a zesty VM and install virtualbox-guest-x11 and see after the reboot if everything is good
[13:53] <LocutusOfBorg> (who am I to say this stupid things to you? sorry!)
[13:53] <tjaalton> i just want it to pass tests now that xserver 1.19 is on proposed
[13:54] <tjaalton> blocked by not being installable
[13:54] <LocutusOfBorg> SERVER_DEPENDS = $(shell cat /usr/share/xserver-xorg/videodrvdep 2>/dev/null)
[13:54] <LocutusOfBorg> yep, I see
[13:54] <LocutusOfBorg> if you want a no change rebuild I can deal with it
[13:54] <tjaalton> right, please :)
[14:12] <LocutusOfBorg> somebody from release team has to accept vbox :)
[14:14] <sil2100> zul: hey!
[14:15] <sil2100> zul: I wanted to take a look at a new cinder SRU in the queue but I see the previous one is still in -proposed - it looks like it's failing some autopkgtests there
[14:15] <sil2100> zul: can you take a look at that?
[14:15] <sil2100> zul: failure log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/c/cinder/20170309_173517_53255@/log.gz
[14:16] <sil2100> zul: is that something a re-run might fix, or is this a real problem?
[14:19] <zul> sil2100: ill take a look
[15:05] <barry> dannf: i've confirmed that those error messages from eieio.el happen in amd64 builds of emacs25.  they just don't crash over there.  i have a meeting in a bit but afterward i'll try to get on the porterbox and see what i can see
[15:15] <nacc> rbasak: thanks!
[15:15] <nacc> rbasak: cpaelzer: i'm aroundnow
[15:15] <dannf> barry: cool, thx!
[15:16] <nacc> barry: ah good to know!
[15:16] <rbasak> nacc, cpaelzer, powersj: now or after the IRC meeting is fine with me.
[15:16] <powersj> same
[15:20] <cpaelzer> same
[15:21] <rbasak> nacc, powersj, cpaelzer: so if everyone's happy, shall we say in 8 minutes - 1530 UTC?
[15:21] <cpaelzer> ack
[15:21] <powersj> wfm
[15:21] <cpaelzer> the first who posts a link in #server is the HO we go to
[15:51] <stgraber> infinity, kees, mdeslaur, slangasek: TB meeting in 9 minutes
[15:51] <mdeslaur> ack
[15:52] <nacc> jgrimm: --^ hrm, isn't that the same time as the server meeting? ~
[15:52] <stgraber> nacc: we're in #ubuntu-meeting-2 so shouldn't conflict
[15:52] <nacc> stgraber: ah! ok :)
[15:52] <jgrimm> nacc, diff channel
[15:52] <jgrimm> yeah
[15:53] <jgrimm> nacc, its always been at the same time. :)
[15:53] <nacc> funny
[16:14] <rbasak> smb, sforshee: server team meeting?
[16:15] <smb> rbasak, already again...
[16:16] <nacc> should there be some kind of clarifying statement at https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware_Enablement_Stack that if you use fglrx, it won't work with 14.04.5 stack & kernel?
[16:17] <nacc> tjaalton: --^
[16:18] <tjaalton> nacc: it can't be used without force
[16:18] <nacc> tjaalton: right, but that's not documented on that page at all
[16:20] <tjaalton> upgrading will take care of it, by uninstalling fglrx..
[16:21] <nacc> tjaalton: right, but if a user *wants* fglrx
[16:21] <nacc> tjaalton: which they had previously
[16:21] <nacc> 14.04.4 kernel/X is EOL, they need to downgrade (aiui) to 14.04.0/1
[16:21] <tjaalton> yes
[16:21] <nacc> and that's not docuemnted :)
[16:21] <tjaalton> feel free to add something
[16:21] <nacc> ok
[16:49] <rbalint> onlinedbug: LP: #1676958
[16:49] <ubottu> Launchpad bug 1676958 in libwmf (Ubuntu) "Please merge 0.2.8.4-10.6 from Debian" [Undecided,New] https://launchpad.net/bugs/1676958
[17:02] <rbasak> slangasek, cyphermox: I wonder if bug 1676597 is related to some reported DNS issues on Xenial? Patches are attached.
[17:02] <ubottu> bug 1676597 in dnsmasq (Ubuntu) "dnsmasq doesn't manage destruction/recreation of tun interface" [Undecided,New] https://launchpad.net/bugs/1676597
[17:03] <nacc> rbasak: is that related to LP: #1639776 ?
[17:03] <ubottu> Launchpad bug 1639776 in dnsmasq (Ubuntu Yakkety) "dnsmasq fails to send queries out after suspend disconnects the interface" [Undecided,In progress] https://launchpad.net/bugs/1639776
[17:03] <rbasak> nacc: that's what I'm wondering. I haven't looked deeply; it just sounds like it's in a similar area.
[17:03] <cyphermox> I suppose it's plausible
[17:04] <nacc> i have the fix queued in that bug locally
[17:04] <nacc> rbasak: it appears they point to the same RHEL bug and upstream fix
[17:04] <rbasak> Ah
[17:04] <rbasak> So a dupe?
[17:04] <nacc> which is in 17.04 and was NMU'd in debian
[17:04] <nacc> rbasak: i'd say so
[17:04] <cyphermox> one extra patch in yours though
[17:05] <nacc> they both refer to two upstream patches (as debian's fix did too)
[17:05] <nacc> iirc
[17:05] <cyphermox> nacc: sound like you have this under control
[17:05] <rbasak> Shall I mark the dupe then?
[17:05] <cyphermox> you're applying http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d  too?
[17:06] <cyphermox> rbasak: yeah, you could dupe it
[17:06] <nacc> cyphermox: yeah
[17:06] <rbasak> Duped.
[17:06] <nacc> and was going to submit that for xenial and yakkety today (the yakkety is trivial, the xenial were some minor conflicts, but easy resolved)
[19:38] <barry> dannf, nacc well, that's interesting.  i apt-get source'd the proposed version of emacs25 on the arm64 porter box, installed the build-deps, and dpkg-buildpackaged it.  no crash
[19:39] <barry> in a zesty-arm64 chroot
[19:39] <dannf> barry: right - the hard part is getting to fail outside of scaling stack. i managed to do it the first few times i tried in a VM, but whatever magic has since gone away
[19:40] <dannf> barry: i suspect it's a matter of getting the GC working during the build. I tried a few env vars to make it hungrier, and limited the memory on my vm, but haven't been able to get a reliable reproducer
[19:40] <dannf> s/a few/a few GC settings via one env var/
[19:42] <barry> dannf: yeah.  it reliably fails in my ppa.  i'm trying to think if we can somehow get the build to give us a gdb backtrace when it crashes
[19:42] <barry> so not real-time debugging, but maybe enough to give us a clue what's going on
[19:44] <barry> dannf: one thing i did find.  when i grepped the source i saw a hack of max_specpdl_size for CEDIT, which is suspiciously related to where we see the crash.  i don't see a lisp_eval_depth error in the output though (i did find a related bug from a few years ago)
[19:44] <barry> i think i might try just boosting that even higher and doing a ppa build
[19:44] <dannf> barry: i posted a gdb backtrace in the bug when i was able to get it to crash
[19:45] <dannf> barry: LP: #1656474
[19:45] <ubottu> Launchpad bug 1656474 in emacs25 (Ubuntu) "FTBFS on arm64: make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)" [High,Confirmed] https://launchpad.net/bugs/1656474
[19:45] <barry> dannf: oh, i missed that.  looking
[19:48] <barry> interesting.  that still doesn't make anything jump out at me, but let me poke around in emacs bugs
[20:01] <mwhudson> uh rmadison is hanging for me
[20:02] <barry> dannf: gotta run out for a quick errand.  bbs
[20:16] <rbalint> barry: have you tried compiling it with -00? maybe it is an optimization problem in GCC
[20:16] <rbalint> barry: i at least would give it a shot
[20:16] <barry> rbalint: i haven't yet, but i have seen references to that
[20:17] <rbalint> arm64 is a young arch
[20:18] <barry> i think it's a good idea.  there's some missing information in the bt (tail = <optimized out>) and it sure looks like it's trying to chase a linked list, probably heading off into la la land
[20:19] <rbalint> barry: maybe a null check is optimized away
[20:19] <barry>       for (tail = BUF_MARKERS (b); tail; prev = &tail->next, tail = *prev)
[20:19] <barry> could be.  if that 'tail' conditional isn't breaking
[20:22] <rbalint> barry: i'm sorry, have to leave now, but would be interested in the -O0 results
[20:23] <barry> rbalint: no worries.  i'll follow up here if i have any results
[20:23] <rbalint> barry: the list seems to be corrupted earlier
[20:40] <barry> rbalint, dannf okay, i think i have a -O0 arm64 build going in my ppa.  let's see what happens
[21:15] <nacc> Logan: re: LP: #1672941, you don't close the bug in the changelog. Are you ok if i fix locally while sponsoring?
[21:15] <ubottu> Launchpad bug 1672941 in cyrus-sasl2 (Ubuntu) "FTBFS with older versions of OpenSSL" [High,New] https://launchpad.net/bugs/1672941
[21:28] <nacc> infinity: freeze clarification -- Logan has provided a fix for a FTBFS for src:cyrus-sasl2 as in z-p. Given that it's already there, is it ok to upload the fix w/o an exception?
[21:29] <nacc> i'm especially asking because some binaries are seeded, so i wanted to be extra cautious
=== Guest60572 is now known as RAOF
[21:44] <tinoco> Hello, could anyone from SRU team release LP: #1317491 (Trusty SRU) ? Thank you
[21:44] <ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed] https://launchpad.net/bugs/1317491
=== salem_ is now known as _salem
[21:57] <nacc> powersj: ping
[21:57] <powersj> nacc: ack
[21:58] <nacc> powersj: looking at your mongosniff MRs
[21:58] <nacc> powersj: the dep3 headers are off
[21:58] <nacc> powersj: you're not hte AUthor, afaict?
[21:58] <nacc> powersj: and i think you should update your target to what you branched off of
[21:59] <nacc> powersj: (for yakkety)
[21:59] <powersj> ok first, dep3 headers. Is there a best way of making those?
[21:59] <nacc> powersj: you should be able to use the raw patch from github, etc.
[21:59] <nacc> powersj: directly as the patch
[22:00] <nacc> powersj: and then dep3changelog *should* do the right thing :)
[22:00] <powersj> oh ok, never used dep3changelog
[22:01] <powersj> (not sure how to get raw patch from github either)
[22:02] <powersj> nacc: so 1) get raw patch from github 2) run dep3changelog?
[22:04] <nacc> powersj: https://github.com/mongodb/mongo/commit/5d05a2b0767f2f6122ee509678e0df3fa36f94a7.patch
[22:05] <nacc> powersj: instead of https://github.com/mongodb/mongo/commit/5d05a2b0767f2f6122ee509678e0df3fa36f94a7
[22:05] <nacc> (jsut add .patch)
[22:05] <nacc> powersj: so yeah, you wget -O- that into d/p/
[22:05] <nacc> powersj: update series
[22:05] <nacc> dep3changelog d/p/newpatchfile
[22:05] <powersj> ah ok adding .patch is easy :)
[22:09] <powersj> nacc: thank you this is much easier
[22:10] <powersj> nacc: put the LP# at the end of the auto-generated change log entry?
[22:11] <nacc> powersj: ah ok, so you'll need to add some headers
[22:11] <nacc> sorry, forgot that bit
[22:11] <powersj> https://paste.ubuntu.com/24270609/
[22:11] <nacc> powersj: so given the raw patch, you'll want to add some stuff after it, before the path
[22:12] <nacc> e.g., Bug-Ubuntu
[22:12] <nacc> and Origin
[22:12] <nacc> if you do, then dep3changelog will do the LP: # for you
[22:12] <nacc> i have a bug to fix so that it ignores whitespace lines, but for now, just don't put a blank line int
[22:12] <nacc> powersj: note, taht i've also taken to doing the following
[22:13] <nacc> 1) get patch, update series
[22:13] <nacc> 2) update patch with dep3 headers
[22:13] <nacc> 3) dep3changelog patch
[22:13] <nacc> 4) edit changelog for series, etc.
[22:13] <nacc> 5) git commit debian/patches
[22:13] <nacc>  and in there (i use vi): !read git --diff -- debian/changelog
[22:13] <nacc> and use the d/changelog entry as teh commit message, basically (excluding the header and footer)
[22:14] <nacc> then you can commit d/changelog as 'changelog' -- what's nice about that is that `git-reconstruct-changelog` can reproduce the changelog
[22:16] <infinity> nacc: Bugfixes are always welcome, especially FTBFS fixes.
[22:16] <powersj> nacc: awesome, thank you for breaking it out like that
[22:16] <powersj> nacc: I'll give it a shot now
[22:18] <nacc> infinity: ok, just wanted to confirm, i recalled something about seeded packages being special
[22:18] <nacc> powersj: np, that's something i intend to blog about / document on the wiki for the drive-by backport case
[22:19] <nacc> powersj: the reason for git-reconstruct-changelog to work is that it lets merges be rebases
[22:19] <nacc> Logan: also, no dep3 header for the bug, i'm realizing, i'll fix locally and sponsor
[22:24] <nacc> jgrimm: ok, last nit, i swear, looking at LP: #1634989 again -- there are two changelog entries, but I think you can just drop the first?
[22:24] <ubottu> Launchpad bug 1634989 in rabbitmq-server (Ubuntu Yakkety) "Segfault on rabbitmq-server start" [Medium,In progress] https://launchpad.net/bugs/1634989
[22:27] <jgrimm> nacc, err?
[22:30] <nacc> jgrimm: http://paste.ubuntu.com/24270716/
[22:31] <jgrimm> nacc, oh you just want to drop the cherrypicked from upstream
[22:33] <jgrimm> nacc, fine by me tho its pretty standard to include in changelog (though someone could also dig deeper into the actuall d/p/*.patch and read that's where it came from too
[22:33] <nacc> jgrimm: is it? as it's own line?
[22:33] <nacc> jgrimm: as it's own line it reads funny and i've not seen that
[22:33] <nacc> jgrimm: as i was taught (by rbasak) one changelog entry per change -- and that reads as two
[22:33] <jgrimm> nacc, possibly indented next line then
[22:34] <nacc> jgrimm: yeah either way, i think it's clearer
[22:34] <jgrimm> nacc, i can agree with that
[22:34] <jgrimm> nacc, i'll update with indent and bullet then
[22:35] <jgrimm> nacc, did you notice the ibm bugproxy reposting patches in that bug? i reported to michael to make them aware/fix. just fyi
[22:38] <nacc> jgrimm: thanks and sorry for the nitty iterating
[22:38] <nacc> jgrimm: i hadn't noticed that until just now
[22:38] <nacc> jgrimm: and very strange :)
[22:38] <jgrimm> nacc, heh.. well for counter point look at the 3.5.4-3.1 changelog
[22:39] <jgrimm> not exactly the same scenario but a meta changelog entry first
[22:40] <nacc> jgrimm: ' * Non-maintainer upload.' is a specific string required for NMU (or so it seems to me) in Deiban
[22:40] <nacc> *Debian
[22:40] <nacc> jgrimm: yes, i see what you mean, but in this case, the two bullets are the same change
[22:41] <powersj> nacc: updated both mongodb merges
[22:41] <nacc> powersj: ah and one last thing -- the version is now incorrect for (yakkety) at least
[22:41] <nacc> powersj: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[22:41] <jgrimm> nacc, i'm find to be best practice.
[22:41] <jgrimm> fine
[22:42] <nacc> powersj: so in this case, should be 1:2.6.11-1ubuntu1.1 (iirc) for y and 1:2.6.10-0ubuntu1.1 for x
[22:45] <powersj> so even though incrementing 1 -> 2 would be ok version when comparing release-to-release upgrades, it is preferred to add the .1?
[22:46] <barry> nacc, dannf, rbalint -O0 is looking pretty good: https://launchpad.net/~barry/+archive/ubuntu/experimental/+build/12372450
[22:47] <barry> the build isn't done yet, but it's past the point of segfault
[22:47] <barry> if it finishes, i will upload
[22:47] <dannf> barry: cool
[22:47] <barry> dannf, nacc, rbalint here's the diff http://paste.ubuntu.com/24270807/
[22:48] <barry> ignore the changelog
[22:48] <barry> so it'll only use -O0 on arm64.  i have no idea what that'll actually do to performance, or whether anyone will care, but if it fixes the ftbfs, we'll call it a day ;)
[22:49] <barry> i do plan on reporting this to upstream, even though it might be near impossible for them to repro
[22:49] <jgrimm> nacc, updated
[22:52] <powersj> nacc: also updated
[22:55] <jgrimm> nacc, i'm EODing but you can of course leave me feedback here or in bug
[22:58] <nacc> jgrimm: thanks
[22:58] <nacc> powersj: thanks
[22:58] <powersj> nacc: oh thank you for the quick review :)
[23:06] <nacc> jgrimm: sponsoring, fyi
[23:07] <nacc> powersj: heh, dep3changelog apparently didn't understand the continuation line :)
[23:07] <nacc> powersj: "Fix mongosniff for decoding messages without a."
[23:07] <nacc> powersj: not super important, and/or you can just make that one line in the patch itself?
[23:08] <powersj> oh I literally thought it was cut it off after a certain number of characters to make it look all nice in the change log lol
[23:09] <powersj> nacc: sure I'll fix it up
[23:09] <nacc> powersj: it's just a pretty straightforward perl script, so it just chomps the subject or description line as given (but only reads in the one line)
[23:11] <powersj> nacc: so in order to make sure I'm doing this right, if I do want to fix the patch I have to essentially reset my commits and run through it all again, right?
[23:12] <nacc> powersj: not entirely
[23:12] <nacc> powersj: so you've got a branch locally, we'll call it 'fix'
[23:12] <nacc> git checkout fix
[23:13] <nacc> git rebase -i lpusip/ubuntu/yakkety (or whatever you started from)
[23:13] <nacc> mark some commits to edit
[23:13] <nacc> save/quit the editor and at the first commit to edit run:
[23:13] <nacc> git reset HEAD^
[23:13] <nacc> which unstages the commit
[23:13] <nacc> make changes to what you want
[23:14] <powersj> nacc: oh ok just like when doing the merge
[23:14] <nacc> presuming all you did was edit, you shold be able to do `git commit -a -c ORIG_HEAD` and edit the commit message
[23:14] <nacc> powersj: yeah
[23:14] <nacc> and then you'll force push over your old branch on lp and the merge will update
[23:18] <nacc> powersj: albeit in this case, given the nature of the change and the need to redo both commits (so the commit message matches the changelog) i end up usually dropping my chagnelog entry (as it should be easily reproducible after fixing the commit message) and then use `git-reconstruct-changelog HEAD^` after commiting the fixed chagne
[23:31] <nacc> pitti: hallyn: when you get the chance, can you respond to my findings in LP: #1576341
[23:31] <ubottu> Launchpad bug 1576341 in systemd (Ubuntu) "systemd in degraded state on startup in LXD containers" [High,Confirmed] https://launchpad.net/bugs/1576341