=== juliank is now known as Guest22905 [03:40] is there a suggested way to confine the "buildroot" of the package to a subdirectory under debian/ ? Up until now, an `rsync --delete debian/` from the host OS to a ubuntu VM to avoid subsequent `dpkg-buildpackage` runs from complaining about the extraneous files under debian/ from the prior build [06:17] good morning [08:01] How to stop/start indicator-power in zesty like `stop indicator-power` in xenial? [08:15] FourDollars: systemctl --user stop indicator-power [08:16] pitti: thx [09:38] tzero: It depends on the upstream build system that's involved, but you should probably look into the "BUILD SYSTEM OPTIONS" section of debhelper(7) for building blocks you can use. And of course you should make sure that your clean target cleans up after the build, rather than relying on rsync --delete. [10:32] xnox: hey there :) === mardy_ is now known as mardy === _salem is now known as salem_ === Foxtrot is now known as Guest77411 === giraffe is now known as Guest73411 === madwizar1 is now known as madwizard === rumble is now known as grumble === hikiko_ is now known as hikiko|ln [13:47] Hey! Does anyone know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-keyboard is blocked in proposed? It the ubuntu-keyboard package the depends are unsatisfiable is provided by the source itself [13:49] sil2100: component-mismatch [13:49] Ah! [13:49] Indeed, the ubuntu-keyboard-esperanto is a new binary package from the source [13:50] Does it want to be in universe? [13:50] I think it needs to be in main as all the other ubuntu-keyboard binaries === iahmad_ is now known as iahmad === BrAsS_mOnKeY is now known as g2 [14:37] barry: who should be the bug subscriber for python-webencodings? [14:38] doko: i'm happy to be that [14:38] doko, mterry i'll look into the tests comment [14:38] barry: but I'm not ;p that has to be a team ... [14:38] doko: well then, foundations of course! [14:38] barry should be easy [14:38] ok [14:42] sanity check: I can't find any reference to a bug about Grub giving the error: [14:42] grub-install: error: cannot open `/boot/grub/x86_64-efi/gcry_twofish.mod': No space left on device. [14:42] slangasek: squid3> thank you for your reply. [14:43] I've done a lot of googling and can't locate this issue. This happens in post-install for shim-signed [14:43] the way I work around it is to copy the files manually to the destination, because the device is in no way out of space [14:43] slangasek: so if the update-rc.d line moved from squid3.postinst, I think it was a no-op before because it is defined not to work if /etc/init.d/squid3 exists, and that's exactly what squid3.postinst tested for first. [14:43] And it's run in set -e, so I'm surprised the postinst didn't fail. [14:44] Anyway, I'll sort it out. Thank you for your help :) [14:46] grub-install just thinks it is. [14:46] and ffs launchpad [14:46] okay, you know what? [14:47] I'm just pasting the output here instead of filing a bug in launchpad because whoever designed the "file a bug" ui in launchpad obviously didn't want people going to launchpad to file bugs! [14:47] go to lauchpad.net [14:47] click ubuntu [14:47] click "Report a bug" [14:47] https://help.ubuntu.com/community/ReportingBugs [14:48] i.e. "Fuck off, we don't want you reporting bugs, so we'll give you this wall of text with no obvious way to get into the bug tracker and enter bug details!" [14:49] oh, there it is [14:49] the one-hundredth link somewhere down 2/3 of the way into the page [14:50] after re-reading that page several times over about a dozen visits spanned across months, I found the link that takes me to the ACTUAL BUG REPORTING FORM [14:50] hooray [14:50] now let's see if I can remember what I wanted to file a bug about [14:51] Laney: please could you override the libreoffice autopkg test for python3.5? the junit-subsequentcheck failure seems to be unrelated === hikiko|ln is now known as hikiko [15:08] doko: ok, would appreciate it if you could ping SweetShark / file a bug & assign it though [15:09] Laney: he's not here, and I'm tired chasing people on various channels every time ... [15:09] I'm tired of skipping tests every time too [15:09] doko, report a bug on launchpad instead of chasing people then [15:09] Can anyone please promote the binary package ubuntu-keyboard-esperanto to main? [15:10] Since all the other binaries from ubuntu-keyboard are in main already [15:11] sil2100: That's backwards [15:12] Oh, it is, but why [15:12] The ubuntu-keyboard source is in main [15:12] Is there any reason why ubuntu-keyboard binaries are still in universe I wonder? [15:24] i want to install kernel manually, is there a particular order i must install it? i have headers-, image-, image-exra, & signed-image [15:27] mterry: hey! I'm wondering if you remember by any chance why ubuntu-keyboard source is in main and the binaries are still in universe [15:27] sil2100, binaries get only promoted if something in main depends on those [15:28] otherwise we keep them in universe [15:28] no point maintaining something in main if we don't need to [15:28] sil2100: yeah what seb128 said, but I don't remember why nothing depends on its binaries anymore... [15:30] mterry, seb128: ok, so I would like to request someone to either promote ubuntu-keyboard binaries to main or downgrade the new ubuntu-keyboard-esperanto binary to universe - whichever is more conveninent :) [15:30] Since the new binary is in main but causes a component mismatch as it depends on the ubuntu-keyboard binary which is still in universe [15:30] And thanks for the explanation! [15:31] unsure who NEWed the new binary and why they put it in main [15:31] check with doko maybe? [15:31] Isn't it automatic for new binaries for a main source package to also go to main, or something? [15:31] yes, it is [15:32] Anyway, I'm fine with any solution just to get this package migrating [15:41] Hi, sorry to annoy. Anyone knows what means the message: [15:41] WARNING **: Configuring 'bootstrap-base' failed [15:42] on syslog during installation? Where can I get more information on why it failed? [15:42] Seems to me it might be a failure on grub installation [15:53] Laney, after a fresh boot, dbus.log just has http://pastebin.ubuntu.com/23746715/ [15:54] I suppose it's a chicken-egg issue? [15:54] Try reverting the upstart job [15:54] fossfreedom_: hah! The budgie build seems to have moved forward finally! [15:55] fossfreedom_: I see it's still in the middle of building but the livefs builds succeeded \o/ [15:55] fossfreedom_: so far so good thanks to cjwatson! [15:56] sil2100: brilliant news!! 1000 thank-you's to you and cjwatson [15:57] For future's sake I'll document it somewhere on our wiki [16:00] rbasak: that wasn't a cross-file move, AFAIR? [16:01] Laney, confirmed, reverting the job makes it start, what I'm seeing happen is that DBUS_SESSION_BUS_ADDRESS is already set, but it's not running, it's likely some intricacy of how the touch session is set up [16:02] maybe the pre-start job should check for validity of the var... [16:02] thanks cjwatson, I'll check it out [16:03] Saviq: Wouldn't it be better to stop setting it to a bogus value? [16:03] I guess this only worked before because the job just clobbered it [16:03] Laney, sure, that, too [16:03] Wonder what's doing that [16:04] sil2100: I see the ISO :) downloaded. First image here http://imgur.com/Kq545ci [16:04] \o/ [16:15] mterry: thanks! [16:16] :) [16:19] seb128, Laney: filed https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1654320 [16:19] Launchpad bug 1654320 in libreoffice (Ubuntu) "libreoffice junit-subsequentcheck autopkg test failure" [High,New] [16:20] doko, thanks [16:20] doko, you might want to indicate in what Ubuntu serie and maybe a log url [16:24] well, kindof, commenting that line out didn't really help [16:27] Saviq, theer used to be an /etc/profile.d snippet that sets it [16:27] (not sure that still exists) [16:29] slangasek: it seems like it was to me. I'll reply to the thread. [16:31] ogra_, well, yeah, that's what I commented out, wondering now where the value comes from [16:31] ah [16:32] there also used to be an Xsession.d script ... neither sure if that still exists [16:32] (or if that would be even processed in your case) [16:33] slangasek: I'm sorry, my mistake. It was all in squid3.postinst. [16:34] (I won't email the thread then) [16:34] ok :) [16:35] slangasek: I think my statement that it couldn't have worked before still applies, but I can raise that with Debian separately. Either way I agree we can drop it now. [16:41] open question to anyone - during an ISO build - is there a way to blacklist (i.e. not install) a package that is normally installed because it is a recommended package of another package? [16:43] bdmurray: could you help iio-sensor-proxy through phased-updates? the error isn't new, but I guess the error signature changed and I think yakkety's release version didn't work at all, bug 1644246 & bug 1637864 [16:43] bug 1644246 in iio-sensor-proxy (Ubuntu) "/usr/sbin/iio-sensor-proxy:ERROR:iio-sensor-proxy.c:186:send_dbus_event: assertion failed: (data->connection)" [High,New] https://launchpad.net/bugs/1644246 [16:43] bug 1637864 in iio-sensor-proxy (Ubuntu Yakkety) "80-iio-sensor-proxy.rules in wrong location" [High,Fix released] https://launchpad.net/bugs/1637864 [16:44] jbicha: weird, i use iio-sensor-proxy on yakkety and rotation works fine [16:44] nacc: which version? [16:45] jbicha: oh nm, i see, i'm running the 'fixed' version. Although i thought it has worked since i upgraded to y. [16:47] I like the idea of phased-updates but for things that get stuck, it splits the userbase between those who use only update-manager to install updates and those who don't [16:59] barry: NB the revert has to happen in network-manager, not in systemd [17:00] slangasek, barry: see https://lists.ubuntu.com/archives/ubuntu-devel/2016-December/039564.html [17:08] cjwatson, hmm, did sshd startup behaviour change with the switch to systemd ? i remember in the past the sysv/upstart scripts created a host cert if there wasnt one by default on first start of a new image ... bug 1650677 looks like that isnt the case anymore [17:08] bug 1650677 in Canonical System Image "Xenial image for frieza does not have SSH configured correctly" [Undecided,New] https://launchpad.net/bugs/1650677 [17:21] jbicha: I've restarted the phasing of iio-sensor-proxy [17:23] Laney, *something* is writing to $XDG_RUNTIME_DIR/dbus-session, but dbus-daemon is never launched with that socket... (I've hacked the dbus-daemon binary to log into /tmp) http://pastebin.ubuntu.com/23747444/ [17:23] will now grep through / to try and find what else might be writing to dbus-session... [17:23] unless you have an idea? [17:27] Saviq: I sort of remember ogra_ doing something to save the DBUS_SESSION_BUS_ADDRESS [17:27] maybe it's that? [17:28] Laney, thats the one in /run ... and Saviq said he disabled the profile.d snippet that does this [17:28] ogra_, one that *saves* it? no, that I didn't find, I only saw Laney, well, I think [17:28] oh right [17:28] http://bazaar.launchpad.net/~phablet-team/ubuntu-touch-session/trunk/view/head:/etc/profile.d/dbus-source.sh [17:29] which *reads* it, doesn't save? [17:29] oh, right ... [17:29] There was a thing to save it [17:29] yeah, one sec [17:29] and that's the only mention in /etc/ [17:30] that used to be in the ubuntu-touch-session script itself, but it is gone [17:31] ogra_, dbus.conf, but.. [17:31] that's what's *not* writing it... and anyway the format would be different [17:32] because the upstart job does it with mktemp /tmp/dbus.XXXX... [17:32] something's adding the guid= there [17:32] http://pastebin.ubuntu.com/23747444/ [17:33] everything else in /usr only seems to read it, nothing writes it AFAICT [17:34] lifghtdm ? [17:35] doesn't look like it, nothing related in grepping the code [17:35] and you are sure /etc/X11/Xsession.d/75dbus_dbus-launch is not executed ? [17:35] dbus-launch? but wouldn't that call dbus-daemon anyway? [17:36] (as i mentioned before) [17:36] systemd --user?? [17:36] again, grep not helpful [17:39] It's written by the upstart job of dbus [17:39] But that should be the same one it launches dbus with [17:40] Laney, well, it's *not* written in this case, since it's prepopulated and the job does "sleep infinity" in that case, so post-start never runs? [17:40] Oh? [17:40] * Saviq checks again [17:41] or maybe it does, because you do exec [17:41] so it then does post-start [17:41] ok so dbus-session is a red herring [17:41] we need to find who's setting the env [17:43] correct [17:43] Laney, yes it is the upstart job that's writing it [17:43] * Saviq was chasing the wrong thread [17:44] Saviq: The problem is that it's already set in the environment earlier on, right? [17:44] yes [17:44] so the new job thinks it doesn't need to launch one [17:45] got it [17:46] it's systemd [17:47] it even has a FIXME there... [17:49] grr where do I find the code repo for the package :/ [17:50] for systemd? [17:50] Laney, ogra_ https://github.com/systemd/systemd/blob/master/src/login/pam_systemd.c#L177 [17:50] hah [17:51] that sets it to $XDG_RUNTIME_DIR/bus no? [17:53] indeed [17:54] lightdm's setting it, but only to a value that's already there... [17:55] http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/src/seat.c#L878 [17:57] ok it's dbus-server's value [17:58] https://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-server.c#n70 [17:58] question is now who's setting the env with it [18:02] look at upstart's /proc/pid/environ to see if it came earlier than upstart, maybe [18:03] got to run, might be back later [18:03] yeah it did === Skuggen_ is now known as Skuggen [18:11] ok it is systemd [18:15] pitti, slangasek yep [18:24] ogra_: none of my sysv/upstart jobs ever created host keys at boot time; I have specifically nacked that multiple times because the time you exactly shouldn't generate host keys is at boot when the system is low on entropy (there is academic research about how that particular idea leads to weak keys in the wild) [18:25] ogra_: anything which you observed doing that in the past was outside of the openssh package, and either without my knowledge or over my objections [18:25] ogra_: it should be done at imaging time or similar instead [18:26] * cjwatson feeds that into the bug [18:30] (https://factorable.net/weakkeys12.conference.pdf) [18:38] cjwatson, oh, ok ... yeah, then it was at imaging time or so [18:39] cjwatson, thanks for taking the time :) [18:40] always happy to play whack-a-mole with dangerous plans ;-) [18:59] Laney, ogra_, ok found the real problem: http://pastebin.ubuntu.com/23747890/ [19:00] this spawns dbus with --exit-with-session, which in the case of a unity8-touch-session seems to happen right after, so DBUS_SESSION_BUS_ADDRESS is left in the environment, but the dbus it launched dies [19:01] commenting out #use-session-dbus in /etc/X11/Xsession.options makes everything work again, but I'm not sure that's what we actually want [19:01] jibel, sil2100 ↑ [19:01] * Saviq filing a bug [19:18] Laney, in any case, I think there's a bug in your dbus.conf - if you stop/start it, it won't launch it even if it was the one that launched it in the first place [19:27] Laney, ogra_, bug #1654365 [19:27] bug 1654365 in ubuntu-touch-session (Ubuntu) "Session dbus lauched by /etc/X11/Xsession.d/75dbus_dbus-launch dies immediately" [Undecided,New] https://launchpad.net/bugs/1654365 [19:28] mterry, do you have enough lightdm/ubuntu-touch-session knowledge to shed more light ↑? [19:28] or do we need Robert? [19:28] * mterry reads [19:34] Saviq: no I don't know off hand why dbus is dying so quickly [19:36] I do suspect that the Xsession.d files are deprecatable [19:36] Upstart or systemd should be triggers for dbus these days I'd think [19:38] mterry, sure, we can actually make that happen by just disabling the dbus thing in Xsessions, but that means the rest of those scripts don't get the full env (not sure if it matters much, but still) [19:40] just added note of this workaround [21:14] Please can someone add Ubuntu Budgie to the ISO tracker? TIA http://iso.qa.ubuntu.com/qatracker === salem_ is now known as _salem