=== maclin1 is now known as maclin
=== giraffe is now known as Guest30004
[07:04] <mwhudson> what's with the armhf autopkgtest queue length?
[07:13] <ginggs> slow armhf is slow
=== pstolowski is now known as pstolowski|lunch
[09:56] <seb128> thanks to whoever has do an update from the langpacks
[11:03] <infinity> seb128: I believe that's sil2100, though he's been quiet about it. :)
[11:04] <seb128> he's not even on IRC :p
[11:08] <infinity> seb128: That might explain the quiet.
=== pstolowski|lunch is now known as pstolowski
[11:52] <jibel> I noticed that the locale is wrong when booting with the default language on the livecd. Submitted bug 1723404
[11:52] <ubottu> bug 1723404 in livecd-rootfs (Ubuntu) "Wrong locale ' UTF-8' in /etc/locale.gen on desktop live image" [Undecided,New] https://launchpad.net/bugs/1723404
[11:53] <seb128> jibel, so, about /etc/locale.gen being buggy/having no value when booting the current artful I notice something changed around locale-gen in http://launchpadlibrarian.net/339014783/livecd-rootfs_2.459_2.460.diff.gz
[11:53] <seb128> slangasek changed livecd-rootfs
[11:54] <seb128> unsure if that could create that issue though
[11:54] <seb128> but sounds like that's something foundations should understand better
[11:56] <jibel> could it cause the problem with the terminal?
[11:56] <jibel> seb128, ^
[11:57] <jibel> yes
[11:57]  * jibel answering to himself
[11:57] <seb128> I think it could
[11:57] <seb128> did you confirm?
[11:57] <slangasek> yeah, that's my fault
[11:57] <jibel> seb128, if you fix locale.gen regenerate the locale, and the locales properly it starts
[11:58] <seb128> that makes sense
[11:58] <didrocks> at least, it's only one issue :)
[11:58] <slangasek> it'll be a bit before I could fix it today; I was planning to fix it to properly default to C.UTF-8 without generating any locale in the default case
[11:58] <seb128> slangasek, good morning, you won bug #1723404 then :-)
[11:58] <ubottu> bug 1723404 in livecd-rootfs (Ubuntu) "Wrong locale ' UTF-8' in /etc/locale.gen on desktop live image" [Undecided,New] https://launchpad.net/bugs/1723404
[11:58] <slangasek> thanks
[11:58] <seb128> thank *you*!
[11:59] <jibel> yw
[11:59] <seb128> jibel, you can dup /invalid the other bug
[11:59] <jibel> done
[11:59] <seb128> thx
[12:01] <slangasek> seb128, jibel: actually, proposed fix just uploaded, if someone wants to sanity-check it in the queue
[13:32] <slangasek> jibel, seb128: sorry, was offline while plenarying; any opinions on that casper upload?
[13:34] <seb128> slangasek, it seems to work, I tried by doing a break=casper-bottom and sedding the changes/editing /etc/default/locale and then booting
[13:34] <seb128> so +1 from me
[13:34] <slangasek> nice
[13:34] <slangasek> self-accepting, then
[13:34] <seb128> thanks
[13:48] <coreycb> doko: i just uploaded a new neutron-vpnaas for artful which should fix the build error. i wasn't able to recreate any of the other neutron-* or swift FTBFS.
[14:05] <sunweaver> hi all.
[14:05] <sunweaver> I need a build log of a specific package in Ubuntu artful (src:package: pakcs).
[14:05] <sunweaver> where do I find the build logs?
[14:05] <sunweaver> THANKS!
[14:07] <cjwatson> sunweaver: https://launchpad.net/ubuntu/+source/pakcs and follow links
[14:07] <cjwatson> sunweaver: the version under the artful section takes you to https://launchpad.net/ubuntu/+source/pakcs/1.14.2-1; pick an architecture under "Builds"; and the build log is linked from there
[14:25] <sunweaver> cjwatson: thanks so much!
[14:28] <coreycb> doko: have you seen anything like this in artful by any chance? https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1722553
[14:28] <ubottu> Launchpad bug 1722553 in python-openstackclient (Ubuntu) "openstack command raises exception referencing gi.repository and gnome bug 709183" [Undecided,Confirmed]
[14:44] <xnox> rbasak, https://www.goodreads.com/book/show/242472.The_Black_Swan =)
[14:51] <rbasak> xnox: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-update
[14:58] <xnox> rbasak, what i'm trying to say, it is not possible to predict, ahead of time, if HA will blow up or not, and how.
[14:58] <xnox> rbasak, any kernel update can cause HA to break, yet we do them blindly and fix things up quickly when they do break.
[14:59] <xnox> rbasak, hence risk assessment should rely on tangible things.
[14:59] <rbasak> xnox: it is absolutely possible to think about it
[15:00] <rbasak> xnox: when you know and understand exactly what you're proposing to change, and when you are able to look into some of the complex use cases that can be identified.
[15:01] <rbasak> This *is* a tangible thing.
[15:01] <rbasak> It's not just "any kernel update". It's a specific and understood behaviour change.
[15:02] <rbasak> For example: for Neutron, you could ask our OpenStack QA guys to simply try it.
[15:02] <rbasak> Not even a PPA is needed.
[15:05] <xnox> rbasak, there is no change to uevents/netlink events as all of them are still generated, thus any existing software that needs to monitor ip address changes, already does so, and is unaffected.
=== ahasenack is now known as andreas
[15:06] <xnox> rbasak, asking OpenStack QA people to try Neutron with said sysctl on is a bit of a waste of time, as one needs to specifically be triggering/causing assignment of multiple ip addresses, issued for the same subnet/netmask, by the same dhcp server ttl (or lack of) and removing/updating those.
[15:07] <rbasak> xnox: you seem to be limiting your analysis to "needs to monitor ip address changes"
[15:07] <rbasak> Perhaps I misunderstand the scope of the change, but IMHO, that's your job to explain it well in the bug, and to explain why the scope is not wider.
[15:08] <xnox> rbasak, if i add 4 ip addresses from different netmasks they are all primary and are all unaffected/unchanged.
[15:09] <xnox> rbasak, if i add an ip address that matches all all basis (issued by the same dhcp server, for the same interface, for the same netmask, etc) kernel designates that duplicate ip address as secondary; which is only discoverable post-factum from the uevent/netlink qeuries.
[15:10] <xnox> primary & secondary address operate just fine; apart from only the primary one used as source address routing, never secondary. but one can accept connections/data on the secondary address.
[15:10] <xnox> this is all on ipv4 only.
[15:11] <xnox> when asking to removing primary address, it removes matching secondary addresses. which is surprising event, but is observable via netlink/uevent.
[15:11] <xnox> change of behaviour is bad.
[15:12] <xnox> but change of behaviour where it's not the same on all Ubuntu variants is even worse, when certain installer/packagesets/configs are in use, is even more confusing.
[15:14] <xnox> the net change here is that when requesting to remove 1 address, only that address is removed - previously kernel would also remove other addresses that were not requested to be removed.
[15:14] <xnox> from the group of same interface, same netmask, same network, same dhcp issuer.
[15:15] <xnox> rbasak, was above word-salad, same/similar to what was your understanding of the scope of change prior to word-salad?
[15:17] <xnox> rbasak, also if you don't understand the scope of the change, why are you assesing the risk of it, instead of asking "i don't understand what this is changing, please elaborate again?"
[15:17] <xnox> surely we should first make sure everyone understands the proposed change, before debating if it is a good idea or not...
[15:18] <rbasak> I'm not assessing the risk of it. I'm assessing the areas where you have either not assessed the risk of it or not shown it to be out of scope.
[15:21] <xnox> rbasak, O_o
[15:23] <xnox> the bit about existing code / old code -> code that tries to change ip address, therefore must be either monitoring removal of ip address; or removing first, then adding. cause otherwise with with all default linux kernels "add new, rm old" does not work.
[15:24] <xnox> for a trivial case of add 10.0.0.1; add 10.0.0.2; rm 10.0.0.1 => one has to do add .1 rm .1 add .2, unless we apply this sysctl.
[15:24] <ogra_> rbasak, note that the main scope is Ubuntu Core and that the issue was discovered by a customer that has 10000s of IoT devices out there already ... note also that OTOH only UbuntuCore uses systemd-networkd in xenial yet (distro stayed with the old stuff for 16.04)... we *could* just stay with the interim hack we use in Core to set this sysctl option
[15:24] <ogra_> (it is just ugly to diverge)
[15:24] <xnox> but using this syclt, does not break the old code; as doing add .1 rm .1 add .2 still works.
[15:24] <xnox> ogra_, false
[15:25] <ogra_> xnox, which part ?
[15:25] <xnox> rbasak, ogra_ - we have multiple bare metal and virtualised clouds using netplan & networkd in xenial.
[15:25] <xnox> in production.
[15:25] <ogra_> oh
[15:25] <ogra_> i didnt know
[15:25] <rbasak> ogra_: so this is the part I don't like: changing behaviour on *all* Ubuntu developments for the sake of a bug in a package that is only used by a very small subset of those use cases.
[15:25] <ogra_> i thought we were the only ones ... ignore that then
[15:25] <xnox> however, most clouds use static ip addresses and do not change them. hence unaffected.
[15:26] <rbasak> all Ubuntu deployments
[15:26] <xnox> dhcp v4 with changing ip address with intermetint connectivity is more in scope for IoT / Core, hence it is reasonable that that product has discovered this issue first.
[15:26] <rbasak> Users do crazy things with Linux networking
[15:26] <xnox> ogra_, yes, the scope of change is everyone.
[15:26] <ogra_> yeah, users are crazy :)
[15:26] <rbasak> It feels risky to me to tweak a default from under their feet
[15:27] <rbasak> I'm not saying that we shouldn't SRU something.
[15:27] <rbasak> We absolutely should.
[15:27] <xnox> rbasak, i find sysctl's madness =) espacially since we often do not control neither the kernel, nor sysctls from userspace.
[15:27] <rbasak> But it doesn't seem very difficult to limit this in scope.
[15:27] <ogra_> xnox, i personally could live with the current solution and you could just skip xenial ... but i dont know how these others you mentioned would be impacted
[15:27] <xnox> and kernel defaults seem to be broken by design, often.
[15:28] <ogra_> (seemingly only Core users complained yet)
[15:28] <xnox> ogra_, haha, no. i find it appauling that you backdoor images and build core in a way that does not match the ubuntu archive.
[15:28] <ogra_> (and they have a fix in next weeks core snap)
[15:28] <xnox> not in terms of series of bytes, but in terms of net effect & result.
[15:28] <ogra_> xnox, that will even get worse, "base" snaps were exactly designed to diverge even moe
[15:29] <ogra_> the core as you know it will soon go away
[15:47] <ogra_> xnox, note that core has always used extra icing on top btw https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[15:53] <mitya57> tjaalton, hi! Will you mind if I backport https://cgit.freedesktop.org/xorg/xserver/commit/?id=885636b7d42b3c7b into Artful package?
[15:54] <mitya57> Or too late and better to do it as SRU?
[16:00] <nacc> mitya57: i believe it's final freeze now
[16:00] <nacc> (possibly /topic needs an update)
[16:02] <mitya57> nacc: I know it is final freeze, but bugfixes should be OK, and the release team can push them to 0-day SRUs.
[16:04] <pdeee> rbasak, nacc we have a Certbot SRU call now if either of you are joining
[16:29] <fenevadkan> Hi
[16:29] <fenevadkan> just upgraded to Artful
[16:30] <fenevadkan> and I cannot login with neither lidghtm nor gdm if using nvidia driver
[16:30] <fenevadkan> if I remove nvidia drivers I can login, but it is just terrrribly slow
[16:30] <fenevadkan> is there no hardware acceleration in nouveau??
[16:57] <rbasak> pdeee: argh! Sorry. Still there?
[16:58] <tjaalton> mitya57: file a bug for sru with steps to reproduce
[16:59] <rbasak> bmw: ^
[17:01] <bmw> rbasak: unfortunately no, we wrapped up 10-15 mins ago
[17:02] <bmw> we did a little more digging into the different issues we wanted to resolve
[17:02] <rbasak> Well, now I owe you. I'll sort something out.
[17:03] <bmw> OK thanks
[17:03] <bmw> it ended up still being productive for us as we chatted about the relevant issues and started talking about other packaging problems
[17:04] <bmw> but for the SRU, we looked into shim packages
[17:05] <bmw> python-letsencrypt is only really useful for people using third party plugins installed through other means with the current packages from Ubuntu xenial
[17:05] <bmw> we looked at the server side numbers for people doing that, and we saw 16 certs issued that way out of around 100k
[17:05] <bmw> in your mind, is that worth creating this package?
[17:06] <bmw> we can probably reach out to the people (or more likely individual) who are doing that and warn them about upcoming changes
[17:07] <bmw> as for python-letsencrypt-apache, our issues there would be resolved by making python-letsencrypt-apache a virtual package that installed python-certbot-apache
[17:07] <bmw> my knowledge of .deb packaging is pretty limited, but our Debian maintainer thought that'd be extremely easy to do
[17:07] <bmw> and finally the package build failures
[17:08] <bmw> our Debian package maintainer thought that shouldn't really be a problem as long as we ensure all packages transition together cleanly to the production repos
[17:08] <bmw> there have been a few times only a subset of the packages have made it to Debian sid or backports and that has caused issues, but otherwise, the build failures seemed normal and expected to him
[17:08] <bmw> we can talk more about that with our Debian maintained in #letsencrypt-dev if you want though
[17:08] <bmw> regardless, I hope this info dump helps!
[17:11] <rbasak> It does, thanks. I'll move over to the other channel.
[19:22] <est31> https://packages.ubuntu.com/xenial/wine-mono0.0.8
[19:22] <est31> https://packages.ubuntu.com/zesty/wine-mono0.0.8
[19:22] <est31> what happened here?
[19:22] <est31> the wine-mono package is not available in zesty
[19:26] <jbicha> est31: yes we share wine packaging with Debian now, which doesn't have that package
[19:27] <est31> jbicha: the issue is, I can't seem to be able to run mono applications with wine
[19:27] <est31> dot net that is
[19:27] <est31> err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed
[19:28] <est31> archlinux wiki says "it copies wine over automatically from the wine-mono package" -- that's not how it works in ubuntu apparently
[19:29] <sarnold> looks like it's in both wine and wine-development packages https://codesearch.debian.net/search?q=GetRuntimeHost
[19:32] <est31> sarnold: right wine and wine-development only differ in the version of wine
[19:32] <sarnold> est31: which -might- work out in your favour for zesty, since the wine-development is much newer in zesty..
[19:34] <est31> its not about versions
[19:35] <est31> its about having mono or not
[19:35] <est31> I guess I need to figure out a way to install it manually then...
[19:36] <sarnold> est31: oh? I think it's worth trying wine-development on zesty, at least that one symbol appears in the packaging http://paste.ubuntu.com/25733931/
[19:37] <est31> sarnold: thats the symbol throwing the error
[19:38] <est31> if you look at the source code you can see sth like if(there is mono) {fine!}  else{ ERROR}
[19:38] <sarnold> est31: Oh :(
[19:42] <est31> at least you can install it manually :)
[19:42] <est31> but its a packaging issue basically
[19:42] <est31> a) all the other distros have it
[19:43] <est31> b) upstream wine installs it automatically
[19:43]  * est31 nags debian