=== JanC is now known as Guest73457
=== JanC_ is now known as JanC
=== BrAsS_mOnKeY is now known as g2
[07:57] <LocutusOfBorg> doko, that gcc regression is scary
[07:58] <LocutusOfBorg> 7.2.0-4 was good, 7.2.0-7 is ICE on i386, I'm testing with 7.2.0-5 right now
=== King_InuYasha is now known as Son_Goku
[12:41] <jbicha> Unit193: did you see https://bugs.debian.org/866657 ? xiphos 4.0.7 has a --enable-webkit2 flag that you could try
[12:41] <ubottu> Debian bug 866657 in src:xiphos "xiphos: depends on libwebkitgtk-3.0-0 which is deprecated" [Serious,Open]
[12:49] <doko> LocutusOfBorg: please attach the preprocessed source
[13:41] <rbasak> LocutusOfBorg, rbalint: please see https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2017-September/017697.html
[13:41] <rbasak> dpkg-vendor isn't available at runtime?
[13:41] <cjwatson> Not in general; it's in dpkg-dev
[13:42] <cjwatson> Ah, indeed, that says that
[13:42] <cjwatson> Usually best to either use lsb_release at runtime or to use dpkg-vendor at build time and substitute the result into scripts
[13:49] <LocutusOfBorg> rbalint, do I smell a patch?
[13:50] <rbalint> LocutusOfBorg: yes, thanks for the heads-up
[13:50] <rbasak> Please thank the guy on the list :)
[13:54] <LocutusOfBorg> thanks to you too!
[13:56] <LocutusOfBorg> I?m daily subscribed to that list, somewhat I missed it
[14:38] <rbalint> LocutusOfBorg: LP: #1719630, please sponsor it if you like the patch
[14:38] <ubottu> Launchpad bug 1719630 in unattended-upgrades (Ubuntu) "unattended-upgrades uses dpkg-vendor but doesn't depend on dpkg-dev" [High,Confirmed] https://launchpad.net/bugs/1719630
[14:48] <LocutusOfBorg> done thanks
[14:53] <LocutusOfBorg> rbalint, can't update the bug report, launchpad OOPS
[14:53] <LocutusOfBorg>  (Error ID: OOPS-2e3d23b275c4532a522ad06226c897df)
[15:08] <jdstrand> doko: fyi, I'm getting pulled into a meeting with vendors so may be late/not be able to attend the MIR meeting
[15:17] <bdmurray> coreycb: come to find out nova has an existing SRU in process / unverified.
[15:21] <coreycb> bdmurray: ah alright
[15:21] <coreycb> bdmurray: thanks
[15:21] <sil2100> robert_ancell: hey!
[15:24] <robert_ancell> sil2100: hi
[15:35] <doko> jdstrand, nacc: ping MIR meeting (in the lobby area)
[15:36] <sarnold> doko: I don't think nacc's here
[15:37] <doko> yeah, trying to get in touch with him on hangouts
[15:45] <jdstrand> doko: I sent you a message a little while ago: 10:08 < jdstrand> doko: fyi, I'm getting pulled into a meeting with vendors so may be late/not be able to attend the MIR meeting
[16:24] <ogra_> persia, pingaling !
[16:26] <jdstrand> doko: did you see ^ (sorry I didn't make the meeting)
=== anthonyf is now known as anthonyf_
=== JanC_ is now known as JanC
[17:52] <bmw> rbasak: I wanted to check in on the status of the Certbot SRU
[17:53] <bmw> the packages have had some time to bake in proposed and the test I wrote up passes for all packages
[18:16] <smoser> hey. wonder if someone could read my response on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852569
[18:16] <ubottu> Debian bug 852569 in cloud-initramfs-tools "cloud-initramfs-tools: Update udevadm path" [Serious,Open]
[18:16] <smoser> i can (and it seems right to me) make 'copy_exec' search the PATH in initramfs-tools
[18:18] <rbasak> bmw: o/
[18:18] <rbasak> bmw: I'm sprinting this week. I'm a little concerned about the transitional packages that failed to build. I'm going to ask other SRU team members about that this week.
[18:18] <rbasak> bmw: apart from that, if the bug is verified then we're good to release.
[18:19] <rbasak> bmw: as soon as we do, a large number of users will get the update. How confident are you about that?
[18:20] <bmw> rbasak: great! if the build failures are something where knowledge of Certbot internals would be useful, I'm happy to take a look
[18:20] <bmw> I'm very confident in the update
[18:21] <rbasak> bmw: it's because the old certbot (letsencrypt) is building against the new acme I think.
[18:21] <bmw> the majority of our users are still using "certbot-auto" which is our self updating alternative to packaging where we were waiting for packages to be created
[18:21] <bmw> this is hundreds of thousands of users and we've been auto updating them the whole time
[18:21] <rbasak> bmw: example: https://launchpadlibrarian.net/335455860/buildlog_ubuntu-xenial-amd64.python-letsencrypt_0.4.1-1ubuntu0.16.04.1_BUILDING.txt.gz
[18:21] <bmw> I don't expect any problems at all
[18:22] <bmw> that'd do it
[18:22] <rbasak> I didn't think of that issue before. Even if you say it can be patched to work,I think it's probably really a packaging issue that I'd like to discuss with experienced distro people
[18:22] <rbasak> As a different approach to the one I've taken may be more appropriate.
[18:22] <bmw> for better or worse, all of the different packages are released in lockstep right now and depend on a specific version
[18:23] <rbasak> Yeah
[18:23] <rbasak> Excactly - we don't want to be trying to build the old one against a new library anyway.
[18:29] <bmw> is the build still failing or did it just fail intermittently as the new packages were being added to the repo?
[18:30] <rbasak> I made the mistake* of getting those through last, so it's trying to build against the updated packages.
[18:30] <rbasak> The other way round it would have worked.
[18:30] <rbasak> But it exposes a fundamental flaw in my approach, so I guess it's good it happened in a way.
[18:30] <rbasak> The failure is a one-off. I can request a retry, but I believe I understand the problem and it'll recur so there's no point.
[18:31] <rbasak> I'll explain the details to others this week and see if we can decide how we should approach this instead (or indeed if we need to approach it at all).
[18:32] <bmw> OK sounds good
[18:32] <rbasak> My original point is to keep python-letsencrypt still buildable in case some users are using "import letsencrypt" in their own code and we don't want to break them.
[18:32] <rbasak> But I've now failed at that :-(
[18:33] <bmw> yeah we definitely want that to still work
[18:33] <bmw> similarly, which package handles creating a "letsencrypt" executable in the user's path that runs the renamed certbot?
[18:34] <rbasak> Oh
[18:34] <rbasak> We may not have handled that.
[18:34] <rbasak> I'll need to check.
[18:34] <rbasak> It may be that the certbot package does it correctly already and that came over from Debian.
[18:34] <bmw> OK
[18:35] <bmw> my tests scripts don't test things like that as it'll only apply to the xenial packages, but I'll do some testing to make sure both of those things work and if not I strongly think they should be fixed before we release
[18:36] <rbasak> I agree. Thanks for checking!
[18:36] <rbasak> bmw: perhaps we should check that for all future SRUs? If it makes sense we should add it to the list of things to check - in the policy document if not in your test script.
[18:37] <bmw> definitely
[18:37] <bmw> I should be able to add something like that to my script so it's automated
[18:37] <rbasak> Thanks!
[19:02] <slangasek> kees, infinity, stgraber: TB meeting?
[19:12] <seb128> slangasek, cyphermox, xnox, would anyone be interested helping oSoMoN to figure out why it's artwork has  NetworkManager-wait-online.service delaying boot/timeouting?
[19:13] <seb128> seems like there are a few similar reports on launchpad and the type of issue we want to see addressed for 17.10?
=== NCommander is now known as KD2JRT
[19:20] <slangasek> seb128: it absolutely is something we want addressed, and yes, we're seeing that escalated from several quarters; cyphermox can you take point on that?
[19:22] <seb128> slangasek, cyphermox, should we come downstair with the machine if you want to have a look with us? we just spend an hour poking in systemd-bootchar and blame and logs but I don't think we are efficient/know where to poke
[19:23] <cyphermox> seb128: by all means
[19:23] <cyphermox> or I can come upstairs
[19:25] <sil2100> seb128: how much is it delaying the boot?
[19:25] <seb128> cyphermox, if you want to come to the desktop room you are welcome. Laney suggested to just "sudo systemctl mask systemd-networkd-wait-online" which he said xnox is going to make systemd do in his next upload ... is that right?
[19:25] <seb128> sil2100, 30s timeout from NetworkManager-wait-online.service it seems
[20:02] <ddstreet> Laney I just re-submitted my merge request for ubuntu-dev-tools, you have a lot of history with pull-lp-source, if you have time can you reivew my changes?  https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/322863
[20:03] <ddstreet> for lp 1453330
[20:03] <ubottu> Launchpad bug 1453330 in ubuntu-dev-tools (Ubuntu) "pull-{lp,debian}-source not getting source for binary because DDE is dead" [High,Triaged] https://launchpad.net/bugs/1453330
[20:05] <johnnyfive> Hello. I'm writing an implementation of the repo meta-data creation process in Go, and have a few questions.
[20:07] <johnnyfive> The big one is where the canonical place to get extra information like the Homepage, Bug URL, etc, for any given package? Used in the Packages file: http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz
[20:08] <sarnold> johnnyfive: debian/control files maybe? http://sources.debian.net/src/systemd/234-2/debian/control/
[20:09] <johnnyfive> sarnold: you rock
[20:10] <sarnold> \o/
[20:16] <seb128> which is maintaining unattended-upgrades/is the person to talk about it?
[20:18] <sarnold> seb128: rbalint and LocutusOfBorg were discussing it earlier, about https://launchpad.net/bugs/1719630
[20:18] <ubottu> Launchpad bug 1719630 in unattended-upgrades (Ubuntu Artful) "unattended-upgrades uses dpkg-vendor but doesn't depend on dpkg-dev" [High,Fix released]
[20:22] <seb128> sarnold, thanks
[20:30] <xnox> seb128, slangasek, oSoMoN, cyphermox - sure, but only with 234-2ubuntu11 installed =)
[20:31] <seb128> xnox, when can we expect that to be uploaded?
[20:31] <seb128> xnox, by uploaded I mean approved :p
[20:32] <xnox> seb128, you can use one from ppa:xnox/nonvirt, and i think you can ping sil2100 about approving it ;-)
[20:32] <seb128> sil2100, ^
[20:33] <juliank> I'd have expected most problems to be solved now. Of course, lxd and virtualbox and friends all do the same network-online Wants, but network-online being part of the order is essentially still a bug in rc.local.service
[20:33] <juliank> now = with apt getting rid of the dep
[20:35] <sil2100> I already kicked new builds
[20:36] <juliank> Essentially what will happen eventually (at least in Debian) is systemd dropping debian/extra/units/rc-local.service.d/debian.conf which causes network-online.target to become ordered before the login targets
[20:37] <juliank> dropping the After=network-online.target, that is
[20:37] <juliank> This seems far more helpful than just breaking network-online.target IMO
[20:39] <seb128> xnox, ^ that's for you I guess?
[20:40] <seb128> sil2100, beta is on thursday, time for new packages and rebuilds :)
[20:41] <juliank> mbiebl: I noticed that that change ^ (removing the After=network-online.target for the rc.local.service drop-in) we agreed on in #debian-systemd has not been committed yet in the git, I hope we don't forget about this thing
[20:41] <xnox> juliank, there is no bug in rc.local.service, as rc-local.service is not enabled by default on ubuntu
[20:42] <juliank> xnox: How else is it pulled in then that it affects actual boot performance?
[20:43] <juliank> If you have an LSB script, it'd pull it in too, but I think that does not have any ordering related to login and so on.
[20:45] <juliank> I just spent an entire day looking for bugs on slow boots, and I did not find any, really
[20:47] <juliank> I mean I see https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1700382, but that just says boot slow
[20:47] <ubottu> Launchpad bug 1700382 in systemd (Ubuntu) "Boot times slow when LXD installed, due to poorly crafted systemd dependency chain" [Undecided,New]
[20:48] <juliank> But it's looking for graphical.target or complete boot time, which is the wrong question to ask
[20:49] <juliank> (you want to know when the system is usable, not when boot is complete, as that stuff might run in the background while you're already working)
[20:51] <juliank> oh and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1714301
[20:51] <ubottu> Launchpad bug 1714301 in systemd (Ubuntu Artful) "systemd-networkd hangs my boot (wireless)" [Critical,Confirmed]
[20:52] <juliank> But that contains no information whatsoever
[20:53] <juliank> I'd be really interested to see the dependency chains that is causing this to be part of the ordering
[20:55] <seb128> sil2100, should maybe accept the systemd update, that's the sort of changes you want to get more testing/feedback on so better to have in included in beta?
[20:59] <juliank> xnox: As for rc.local, it was enabled on 16.04 at least. The rc.local file was dropped at some point, but not removed on upgrades. Was the unit explictly disabled  later on?
[20:59] <Unit193> jbicha: I've seen it, and webkit2 requires gtkhtml which Debian removed.
[21:01] <jbicha> Unit193: xiphos is on the remove list at LP: #1710318 I'm not sure how much of that will happen for 17.10 but I think it's very unlikely the old webkitgtk will be available in 18.04 LTS
[21:01] <ubottu> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
[21:01]  * juliank does not see anything about rc.local in the systemd changelog
[21:02] <Unit193> Yep.
[21:06] <juliank> jbicha: I don't understand your report about APT logging to systemd.
[21:06] <juliank> jbicha: APT never logged to the system log.
[21:07] <jbicha> juliank: maybe it should
[21:07] <jbicha> Ubuntu's log viewer app only shows systemd logs, the log viewer in older Ubuntu releases also showed the apt logs
[21:08] <juliank> jbicha: Well, but the same also applies to dpkg. In any case, we have both a history log and a terminal output capturing. We definitely don't want the latter in the journal.
[21:08] <juliank> And history.log is Deb822 structured data
[21:09] <juliank> I don't see how that fits together.
[21:09] <jbicha> why definitely not?
[21:09] <juliank> Because it contains all terminal interaction, including conffile prompts and stuff
[21:10] <juliank> It's like the output of running dpkg in script(1)
[21:11] <juliank> I'm not sure if it even contains data you wrote into debconf prompts
[21:11] <jbicha> I would expect the history log to be in the systemd journal though
[21:13] <jbicha> apt is somewhat unique in the default Ubuntu Desktop install for it to use "traditional" logging instead of the journal
[21:13] <juliank> I guess you'd have to define a new output format for that
[21:14] <juliank> I mean, it makes no sense to include the machine-readable deb822 data in such a log
[21:14] <juliank> It's meant for tools to parse it and display it nicely
[21:15] <jbicha> I think lots of stuff already dump machine-readable logs into the journal
[21:15] <juliank> jbicha: And it's questionable if the apt log is that useful compared to the (more-detailed) dpkg.log
[21:16] <juliank> There's also update-alternatives.log and friends
[21:25] <juliank> jbicha: I guess it would definitely be an improvement for server workloads with centralized logging if we logged something, even if only history
[21:25] <juliank> Then you can see that installs/upgrades happened, but if you need to investigate further you need the dpkg, installation planner and term logs likely
[21:26] <juliank> jbicha: We definitely still need history.log for the eventually happening apt history command
[21:26] <juliank> So we can have apt history revert ...
[21:26] <sil2100> seb128: let me look at the changes there
[21:27] <seb128> sil2100, thanks
[21:38] <xnox> juliank, it is removed on upgrades in artful.
[21:38] <xnox> juliank, in the upload that is in the upload queue ;-)
[21:38] <juliank> Well yeah, but it was there before all the time
[21:40] <juliank> But really, network-online.target is sort of a failure
[21:40] <juliank> should not have existed
[21:41] <sil2100> seb128: ok, let me accept this then and think about re-spinning later
[21:43] <sil2100> I like the LP: #1714301 idea
[21:43] <ubottu> Launchpad bug 1714301 in systemd (Ubuntu Artful) "systemd-networkd hangs my boot (wireless)" [Critical,Confirmed] https://launchpad.net/bugs/1714301
[21:44] <sil2100> Will take ages to migrate probably, will check up on it after dinner
[21:48] <sarnold> is ubuntu-geoip used for anything these days?
[21:53] <Unit193> sarnold: unity-webapps-service and indicator-datetime both have: geoclue-ubuntu-geoip | geoclue-provider
[21:54] <juliank> jbicha: Just sent a mail to the bug. guillem mentioned that chroots would also log to the main log then, which would be weird and not what we want. Imagine every sbuild or pbuilder run spamming your journal with apt logs
[21:54] <juliank> totally confusing
[21:55] <sarnold> Unit193: do we still care about webapps?
[21:56] <sarnold> Unit193: wait. does _anyone_ still care about webapps?
[21:56] <ddstreet> xnox are you planning on artful for lp 1714505 or post-artful?  just checking
[21:56] <ubottu> Launchpad bug 1714505 in debian-installer-utils (Ubuntu) "systemd kmod builtin uses out of date kmod context" [Critical,New] https://launchpad.net/bugs/1714505
[21:56] <sarnold> "oh good it's a web page but doesn't work like my favourite browser"
[21:56] <sarnold> Unit193: probably the indicator-datetime thing can't be easily skpped. I wonder why I didn't see that one on my achine.
[21:57] <Unit193> sarnold: That's the better question.  Looks like it was removed from Artful, so only the ohter.
[21:57] <sarnold> Unit193: thanks.
[21:59] <jbicha> juliank: I don't understand why chroots would log to the system journal. That sounds wrong. Anyway, I'm sure I'm not the only one that would ask the question so it's good to have a tracker bug for my request
[22:00] <juliank> jbicha: Well, we'd have to log using syslog() or maybe there's some dbus-journal only thing? If we do syslog it works via /dev/log, which is a device.
[22:00] <juliank> Obviously, syslog would be more portable
[22:04] <juliank> I mean, for a lot of chroot scenarios (isolation of services), you want the chroots to report to the main journal, so I'd expect that to log to the parent journal, and not a chroot-specific journal (the chroot would need journald running for that anyway)
[22:08] <jbicha> I would not assume that things running a in a chroot would typically be changing system files outside the chroot
[22:10] <juliank> still sounds like a can of worms
[22:10] <juliank> And logging is actually one socket
[22:10] <juliank> I think systemd-nspawn at least does forward stuff
[22:11] <juliank> and as soon as you bind mount /dev and /run you get the socket to journald