=== _salem is now known as salem_
=== dja_ is now known as dja
=== salem_ is now known as _salem
[02:23] <mwhudson> sigh i should just always pass -sa to dpkg-buildpackage, at least when i have a fast connection on hand
[02:27] <Unit193> I started doing  debuild -tc -sa  a bit ago too...  Added it to pbuilderrc.
[02:36] <mwhudson> eh i think i ~always pass -S too, so -tc wouldn't get me much?
[02:36] <mwhudson> building is for chroots
[02:43] <Unit193> Yeah, but I still do it. >_>
[02:54] <mwhudson> heh
[04:41] <cfoch-always> hi
[04:41] <cfoch-always> I read that Ubuntu will have GNOME by default
[04:41] <cfoch-always> I contribute to GNOME
[04:42] <cfoch-always> but I suppose that there must be some modifications of GNOME that are particular to Ubuntu
[04:42] <cfoch-always> how can I contribute in those parts?
[06:03] <TheMuso> cfoch-always: I don't think any decisions have been made along those lines yet.
[07:27] <mase_wk_> lo all. I have posted a message in #ubuntu-packaging but haven't had any reponse. Are packaging questions welcome in this channel ?
=== Orphis_ is now known as Orphis
[07:29] <sarnold> yes
[07:33] <Unit193> sarnold: If I wanted to change /etc/dpkg/origins/default (a symlink, not in alternatives) to something else without doing something gross, what'd be the best way?
[07:35] <sarnold> Unit193: it looks like this is the thing you've got ot play nicely with http://sources.debian.net/src/base-files/9.9/debian/postinst.in/?hl=47#L47
[07:36] <sarnold> Unit193: .. in which case it feels a bit like you can just drop in your own file, re-set the link, and probably things will continue to work
[07:36] <Unit193> Right, but if one didn't want to "fork" base-files?  One would have to take into account removing of course.
[07:36] <Unit193> sarnold: FWIW, I'm partially messing with you due to your answer.  But, might be looking to do something like this.
[07:37] <sarnold> I think the postinst script is prepared to live happily alongside your own deb dropping in your own file
[07:39] <Unit193> Was thinking of moving the file, and in the pre/postrm move it back.
[07:46] <sarnold> I think it looks set up to just accept a new file there, with a new symlink, without hassle
[07:47] <mase_wk_> i am trying to package a PHP pecl extension for 16.04.  previously i have used dh-make-pecl (i think) but that doesn't seem to be in the repos. Does anyone know if the process has changed or if there is a new tool or something that has replaced it ?
[07:48] <Unit193> Just have to handle the case of removing package-2.
=== CRogers_________ is now known as CRogers
[09:01] <tjaalton> mapreri: why did freeipa need a rebuild against ldns2?
[09:01] <xnox> cjwatson, infinity told me to not be a jerk and to scootch over.
[09:01] <xnox> and make room for you
=== jtaylor_ is now known as jtaylor
[11:57] <ackk> cyphermox, hi, I'm having an issue with the zesty ubuntu-gnome installer. on my desktop it freezes at some point with the initial spinner
[11:58] <ackk> cyphermox, how can I debug what's blocking?
[12:51] <cyphermox> ackk: what do you mean by "the initial spinner"? the plymouth splash screen?
[12:51] <ackk> cyphermox, yes
[12:52] <ackk> cyphermox, I've tried both the beta2 iso and the daily one. the former hang at gnome startup, the latter at the splash screen
=== _salem is now known as salem_
[12:55] <cyphermox> ackk: ok, did you file a bug? what hardware is that on?
[12:56] <ackk> cyphermox, I didn't because I don't have any info. I was wondering if there was a way to get some debug info
[12:57] <cyphermox> the best is to file a bug in the first place; use "ubuntu-bug ubiquity" to make sure it includes hardware info we'd need.
[12:57] <ackk> cyphermox, ok. is lshw output enough?
[12:57] <cyphermox> just from there I'd guess shell doesn't like your video hardware, and maybe it's something I could reproduce on my own laptop.
[12:58] <cyphermox> ackk: sure..., but ubuntu-bug does the right thing for you.
[12:58] <ackk> cyphermox, so I run it on yakkety and just mention the issue is with zesty?
[12:59] <cyphermox> yeah, that will do
[13:00] <cyphermox> I'm most interested in the hardware, what make/model especially, just in the off chance I have that at home.
[13:00] <mapreri> tjaalton: my fault.  I scheduled rebuilds on all packages mentioned by britney, I forgot to remove the arch:all ones (and I should have probably actually checked they build-dep on the relevant -dev…)
[13:00] <mapreri> so I triggered at least 2 useless builds, including that.
=== NCommander is now known as Guest19549
[13:18] <ackk> cyphermox, does it start X or wayland by default?
[13:19] <cyphermox> probably X, I suppose
[13:19] <cyphermox> jbicha: ^
[13:19] <cyphermox> not that it would matter much, a bug is a bug
[13:21] <jbicha> the installer does not use Wayland
[13:25] <ackk> cyphermox, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1681846 FTR
[13:25] <ubottu> Launchpad bug 1681846 in ubiquity (Ubuntu) "Zesty Ubuntu-GNOME Installer hangs at plymouth splash" [Undecided,New]
[13:28] <cyphermox> thanks
[13:32] <ackk> ty for the info
[13:48] <tjaalton> mapreri: ok, no prob
[14:32] <xnox> jamespage, i think https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1681470 is a cloudarchive backport bug. Is there a specific way to file cloudarchive bugs?
[14:32] <ubottu> Error: Could not gather data from Launchpad for bug #1681470 (https://launchpad.net/bugs/1681470). The error has been logged
[14:33] <xnox> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1681470
[14:45] <jamespage> xnox: https://bugs.launchpad.net/cloud-archive
[14:45] <xnox> jamespage, tah.
[14:49] <jamespage> yw
[15:37] <infinity> slangasek, kees, stgraber: Vote we skip the TB meeting today because release week and other drama.
[15:37] <stgraber> infinity: fine with me
[15:43] <slangasek> infinity: ok
[15:44] <rbasak> infinity: fancy doing my DMB->TB tasks then?
[15:44] <slangasek> infinity, kees, stgraber: updated on the wiki
[15:44] <rbasak> You (the TB) missed an outstanding one last week, so one person has been waiting a while.
[15:44] <rbasak> bug 1674440
[15:44] <ubottu> bug 1674440 in ubuntu-community "[TB/DMB] ACL for ~ubuntu-sru-developers" [Undecided,New] https://launchpad.net/bugs/1674440
[15:45] <slangasek> rbasak: infinity is release managing in London today, so probably not him
[15:45] <rbasak> Ah, I didn't realise there was a sprint.
[15:47] <jdstrand> tyhicks: hey, are you planning any apparmor uploads for zesty?
[15:47] <tyhicks> jdstrand: no, I don't believe so
[15:50] <jdstrand> tyhicks: I was going to fix aa-notify and verify the wayland abstraction. is there anything else you'd like incorporated in that upload?
=== jgrimm is now known as jgrimm-away
[15:51] <tyhicks> jdstrand: I can't think of anything - thanks for asking!
[15:52] <jdstrand> np
[16:06] <iulian> rbasak: Thanks!
[16:23] <rbasak> stgraber: would you be able to sort out bug 1674440 please?
[16:23] <ubottu> bug 1674440 in ubuntu-community "[TB/DMB] ACL for ~ubuntu-sru-developers" [Undecided,New] https://launchpad.net/bugs/1674440
[16:23] <rbasak> We've been waiting a while - it was missed at the last TB meeting.
=== JanC_ is now known as JanC
=== alan_g is now known as alan_g|EOD
[19:47] <nacc> rbasak: triaging a mysql 5.7 upgrade failure in #ubuntu; why does the postinst not capture (at least) the output in run_init_sql and display it in case it fails?
[19:47] <nacc> rbasak: as that's the failing step here
[19:48] <nacc> or at least say "mysqld failed to start" ?
[19:48]  * nacc thinks anytime a user ends up seeing only a dpkg returned 1 message and the log has nothing, there is something to improve :(
[20:00] <rbasak> nacc: we usually get fairly descriptive things in bug reports now. So I'm not sure what's missing in that case.
[20:00] <rbasak> Could it be a really old installation that doesn't write error logs at all?
[20:00] <nacc> rbasak: i'm not sure, they said they were on 16.04 and the `apt-get upgrade` just ran recently
[20:00] <rbasak> We fixed that an LTS or two ago, but users may not have picked up the conffile update.
[20:00] <rbasak> /var/log/mysql/error.log should have the details
[20:01] <rbasak> nacc: what was the dpkg output?
[20:02] <nacc> http://paste.ubuntu.com/24362260/
[20:02] <nacc> well taht was the first output
[20:02] <nacc> we got to this: http://paste.ubuntu.com/24362788/
[20:02] <nacc> and now we're asking them to hack the postinst a bit to not /dev/null that run
[20:08] <nacc> rbasak: http://paste.ubuntu.com/24362893/
[20:09] <nacc> it seems like mysqld is not starting properly
[20:09] <rbasak> That's odd.
[20:10] <rbasak> Skuggen: ^
[20:11] <rbasak> nacc: anything in /var/log/mysql/error.log?
[20:11] <rbasak> Is that file being touched?
[20:11] <nacc> oh right, let me ask
[20:16] <nacc> rbasak: "Fatal error: mysql.user table is damaged. Please run mysql_upgrade."
[20:16] <rbasak> We should perhaps capture the log and print it on failure in this case.
[20:17] <rbasak> I'd like Skuggen's input, but in the meantime, a bug report is welcome.
[20:17] <nacc> rbasak: i'll ask them to file
[20:17] <rbasak> Thanks!
[20:17] <rbasak> A bug for the lack of useful error message of course.
[20:17] <rbasak> I don't know that there is any other bug (yet).
[20:17] <nacc> yeah
[21:35] <tsimonq2> cyphermox: Hi :)
[21:40] <cyphermox> hey
[21:41] <tsimonq2> cyphermox: You around to do this debugging, or later?
[21:43] <cyphermox> tsimonq2: so, could you file a new bug, add "systemd-resolve --status" and try 'sudo systemctl stop systemd-resolved' and finally running 'SYSTEMD_LOG_LEVEL=debug /usr/sbin/systemd-resolved > /tmp/resolved.log 2>&1' and trying to resolve something again?
[21:44] <cyphermox> these command lines are approximate from memory, maybe there's not quite right
[21:45] <cyphermox> wow, my grammar is bad today
=== salem_ is now known as _salem
[21:45] <bdmurray> super bad
[21:45] <tsimonq2> cyphermox: But at the moment I overwrote my /etc/resolv.conf to make this work.
[21:45] <tsimonq2> cyphermox: Do I need a fresh file to do this on?
=== _salem is now known as salem_
=== salem_ is now known as _salem
[22:16] <bdmurray> nacc: I got a better stacktrace in bug 1667892. Should I flip it back to New?
[22:16] <ubottu> bug 1667892 in apache2 (Ubuntu) "apache2 crashed with SIGSEGV in <signal handler called>()" [Medium,Invalid] https://launchpad.net/bugs/1667892
[22:20] <nacc> bdmurray: yeah, sounds right
[23:41] <tsimonq2> cyphermox: You saw my above ping, right? :)
[23:43] <cyphermox> tsimonq2: yeah, I don't think you need to touch resolv.conf at all there
[23:43] <tsimonq2> cyphermox: Ok, I'll continue now :)
[23:43] <cyphermox> if you use the dig command to issue DNS requests you can point it right to 127.0.0.53
[23:44] <cyphermox> ie.
[23:44] <cyphermox> dig www.google.com @127.0.0.53
[23:44] <tsimonq2> cyphermox: What should I title the bug?
[23:44] <tsimonq2> Ok
[23:46] <tsimonq2> Ok wat >__< -- this is weirdf
[23:46] <tsimonq2> *weird
[23:46] <tsimonq2> It works fine now...
[23:46] <tsimonq2> O__o
[23:46] <tsimonq2> Oh lol
[23:46] <tsimonq2> cyphermox: bash: /usr/sbin/systemd-resolved: No such file or directory
[23:46] <tsimonq2> Where is it really?
[23:47] <cyphermox> oh, right
[23:47] <sarnold> /lib/systemd/systemd-resolved ?
[23:47] <Unit193> Yes.
[23:47] <tsimonq2> sarnold: Trying.
[23:47] <cyphermox> /lib/systemd/systemd-resolved
[23:47] <cyphermox> silly place to put a binary.
[23:48] <Unit193> > systemd
[23:48] <cyphermox> Unit193: yeah, just need to retrain to not always /usr/sbin.
[23:48] <tsimonq2> But... there's nothing in the log and I can dig everything fine?
[23:48] <cyphermox> nothing in the log?
[23:48] <tsimonq2> Plus, I'm talking to you now, soo
[23:49] <tsimonq2> Nope, nada
[23:49] <tsimonq2> $ cat /tmp/resolved.log
[23:49] <tsimonq2> simon@semantic ~ $
[23:49] <cyphermox> hold on, let me try this here.
[23:49] <tsimonq2> Ok.
[23:50] <tsimonq2> systemd is really "fun," at least this part of it is ^__^
[23:50] <cyphermox> you're missing sudo
[23:51] <tsimonq2> Gah, that would explain it...
[23:51] <cyphermox> but not only that
[23:52] <tsimonq2> Oh?
[23:55] <cyphermox> arf
[23:55] <cyphermox> sudo SYSTEMD_LOG_LEVEL=debug SYSTEMD_LOG_TARGET=console /lib/systemd/systemd-resolved 2>/tmp/resolved.log
[23:55] <cyphermox> because just honoring redirects would be too easy.