[02:00] <GrimSleepless> Hey I have a question for you guys :) I think you might be able to answer me, is there any plan for better support for Optimus laptop in Ubuntu 18.04?
[02:02] <sarnold> probably it depends upon how active optimus laptop owners have been filing bugs for issues with previous releases with ubuntu and the upstream projects ubuntu incorporates
[02:13] <Unit193> Well, could take a spin and see how it works for you.
[05:40] <tjaalton> define "better"
[05:41] <Unit193> "not worser"
[05:42] <tjaalton> than what :)
[05:43] <Unit193> (Had to scrollback to see what I was answering.)  Ah, I presume the user had some sort of issues in prior versions, likely 16.04.
[08:16] <apw> nacc, rbasak, what criterial is the git auto importer using to decide on whether to touch a git repo ?
[09:23] <rbasak> apw: currently it's anything in main that isn't explicitly blacklisted
[11:26] <rbasak> slangasek: given your comment https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1741277/comments/5, is it a bug that gnome-control-center recommends libnss-myhostname and therefore it's installed by default on desktop?
[11:26] <ubottu> Launchpad bug 1741277 in cloud-init (Ubuntu) "Not all platforms running cloud-init end up with the system hostname resolveable by default" [Undecided,Confirmed]
[11:26] <rbasak> installed by default> AFAICT, without actually looking.
=== Guest10860 is now known as _hc
[12:35] <jbicha> rbasak: maybe, I opened bug 1766575 it seems to work fine without that installed but feels a bit late to make that change
[12:35] <ubottu> bug 1766575 in gnome-control-center (Ubuntu) "Drop libnss-myhostname recommends" [Low,New] https://launchpad.net/bugs/1766575
[12:36] <rbasak> jbicha: thanks. Yeah I have the same feeling about the lateness.
[12:38] <BjornT_> juliank, xnox: could you please take a look at this bug? it's a regression with one of the latest uploads: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1766574
[12:38] <ubottu> Launchpad bug 1766574 in rsyslog (Ubuntu) "Installation failed if systemd isn't installed: /var/lib/dpkg/info/rsyslog.postinst: 28: /var/lib/dpkg/info/rsyslog.postinst: systemd-tmpfiles: not found" [Undecided,New]
[12:38] <rbasak> jbicha: based on your explanation in the bug, wouldn't removing libnss-myhostname break things like "hostname -f"?
[12:39] <rbasak> Given that bug 1162475 is not resolved.
[12:39] <ubottu> bug 1162475 in systemd (Ubuntu) "[hostnamed] Changing hostname doesn't update /etc/hosts" [Low,Triaged] https://launchpad.net/bugs/1162475
[12:39] <juliank> BjornT_: that's invalid
[12:40] <jbicha> rbasak: it seems to work here. Give it a try
[12:41] <juliank> xnox: Did you add the systemd-tmpfiles --create /usr/lib/tmpfiles.d/00rsyslog.conf?
[12:41] <jbicha> the recommends was added to fix an old bug but maybe the bug was also fixed a different way (in systemd??)
[12:41] <juliank> dh_installinit already adds that later on properly guarded by if [ -d /run/systemd/system ] ; then
[12:43] <juliank> BjornT_: Note that I'm not saying that running a system without systemd is supported.
[12:43] <juliank> But I'm confused why that's there
[12:44] <BjornT_> juliank: i don't see how it's invalid. it does break, so something is broken.
[12:44] <juliank> BjornT_: I looked at wrong postinst which only had the properly guarded call
[12:45] <juliank> new version now has systemd-tmpfiles call in a different place, unguarded.
[12:45] <juliank> *an additional place
[12:45] <BjornT_> ah, ok
[12:46] <juliank> BjornT_: But how do you get to a system without systemd in the first place? It's in minimal and core
[12:47] <BjornT_> juliank: no idea. i just used the ubuntu docker images. i have no idea how they are created, or by who
[12:50] <ackk> juliank, the ubuntu docker image doesn't have systemd preinstalled
[12:50] <juliank> Well, the lxc one does, that's all I know :)
[12:51] <ackk> yeah because it runs an ubuuntu system :)
[12:51] <juliank> Anyhow, sounds like a bug
[12:51] <ackk> what is?
[12:52] <juliank> I think I'll leave that up to xnox to figure out why he added the duplicate unguarded systemd-tmpfiles, but I don't see why it's needed
[12:52] <juliank> I think it needs to Depend on systemd
[12:52] <juliank> I'm not surer
[12:53] <juliank> So with this approach systemd-tmpfiles is required. Whether that needs systemd as an init or not, is a different matter.
[12:55] <juliank> ackk: the other question is whether it's valid for the docker image to ship without systemd, I'm not an expert on this
[12:55] <ackk> juliank, I think that's perfectly fine, there's nothing running by default
[12:56] <ackk> juliank, I mean, it just provies you a base system
[12:58] <juliank> Well, systemd contains a multitude of helper programs that are useful even without systemd-sysv
[12:58] <juliank> and if you're installing rsyslog, how'd that work without systemd?
[13:01] <ackk> juliank, you can run it manually, that's the normal use with docker
[13:01] <ackk> you run a single service in foreground
[13:01] <juliank> Interesting
[13:27] <kasper3> nacc: sorry for bugging you, do you know when would debian guys build the llvm-toolchain next? your lldb.h patch hasn't been landed in packages yet: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895051
[13:27] <ubottu> Debian bug 895051 in llvm-toolchain-6.0 "liblldb-6.0-dev: missing API/*.h files" [Normal,Open]
[13:27] <kasper3> (based on http://metadata.ftp-master.debian.org/changelogs/main/l/llvm-toolchain-6.0/llvm-toolchain-6.0_6.0-1_changelog)
[13:38] <xnox> BjornT_, will do.
[13:53] <nacc> kasper3: will look
[13:55] <kasper3> nacc: thanks! \o/
[13:56] <nacc> apw: if that was wrong for some linux* packages, let me know and i can switch them back
[13:57] <LocutusOfBorg> kasper3, isn't this something you should prod debian folks?
[13:57] <LocutusOfBorg> on oftc you can directly talk with sylvestre
[13:58] <nacc> kasper3: and yeah, i don't know, you'd need to ask the debian maintainer. It's in their VCS, so whenever they decide to do a release
[13:58] <LocutusOfBorg> I could upload llvm 6.0, but I don't get why we can't wait for 6.0.1 to be released, the VCS is ready for it
[14:03] <kasper3> LocutusOfBorg, please consider this if that is not too much of a trouble, it would unblock my build with llvm 6.0. the main lldb 6.0 headers were missing which nacc's patch fixed.
[14:04] <kasper3> stange that LLDB guys made release_60 without noticiing that the final package is not getting :/API directory on any platform..
[14:04] <nacc> kasper3: right, but only on debian, which is offtopic for this channel
[14:05] <kasper3> nacc: sure, i will take it to debian channel. for cross-ref with ubuntu https://bugs.launchpad.net/debian/+source/llvm-toolchain-6.0/+bug/1761009 :)
[14:05] <ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Debian) "LLDB.h is missing from liblldb-6.0-dev package" [Unknown,New]
[14:31] <cpaelzer> are currently all autopkgtest in bionic failing for arm64 for a kernel issue?
[14:32] <cpaelzer> I see all arm64 go down with "Errors were encountered while processing: flash-kernel"
[14:32] <Laney> yes
[14:33] <cpaelzer> Laney: thanks, any known bug I could subscribe myself to know when it makes sense to retrigger the tests to get things migrating?
[14:33] <Laney> cpaelzer: Once the new flash-kernel is in we'll retry all of the failed tests.
[14:34] <cpaelzer> oh nice, thank you
[14:34]  * cpaelzer holding still then
[14:51] <nacc> juliank: perhaps i'm missing something obvious; 18.04 -- `apt-get install maven openjdk-8-jdk-headless` and java8 and java11 are installed; `apt-get install openjdk-8-jdk-headless; apt-get install maven` only java8 is installed?
[14:53] <doko> nacc: 11 aka 10 is the default
[14:53] <doko> you always get it
[14:54] <nacc> doko: but why? maven's dependency is default-jre-headless (>= 2:1.7) | java7-runtime-headless
[14:54] <nacc> doko: and obviously you don't "always" get it, if you install java8 first
[14:55] <doko> what are you trying to do?
[14:55] <nacc> doko: a user is trying to install maven and use java8 in #ubuntu+1
[14:55] <nacc> it worked before 18.04, per the user
[14:55] <doko> openjdk-8 is in universe, you should keep away from it
[14:55] <nacc> doko: that's neither here nor there
[14:56] <nacc> from what i can tell from the apt dependencies, the single-line version *should* work
[14:56] <doko> is there is a dependency on any default package, then you get 11
[14:57] <nacc> doko: it's an *or*
[14:57] <nacc> doko: that is horribly broken if the or is ignored?
[14:58] <doko> I don't see anything broken
[14:58] <nacc> doko: maven depends on either the default JRE *or* something providing a java7 JRE
[14:58] <nacc> doko: java8-jre provides a java7 JRE. and this user does not want java 11
[14:58] <doko> and there are no other rdeps on any default package in the rdeps?
[14:59] <nacc> no, as I said, running them one after the ohter does *not* install java11
[14:59] <nacc> so i completely disagree it has to be installed in this case
[14:59] <nacc> it feels like apt is mis-resolving the |
[15:03] <juliank> nacc: can happen
[15:04] <nacc> juliank: the user is reporiting aptitude works correctly
[15:04] <nacc> juliank: do you want me to have them file a bug?
[15:04] <juliank> no
[15:04] <juliank> it's working correctly
[15:05] <juliank> or rather, I think we have a bug for that anyway
[15:05] <juliank> that said, stuff like that can happen
[15:06] <nacc> juliank: ok, it seems to have changed in this case for them from prior releases
[15:06] <nacc> some ansible recipe that worked until 18.04 and our java madness :)
[15:06] <juliank> it depends on concrete dependencies and scoring I guess
[15:06] <juliank> and hash values
[15:06] <nacc> juliank: ok, so the 'best' solution, perhaps is to force the java8 installation first by manual, then install maven?
[15:07] <juliank> yes
[15:07] <nacc> juliank: thanks, i'll let them know
[15:09] <juliank> nacc: so I don't find the bug, so if they want to open one, that's fine. But I definitely remember reading about this
[15:09] <nacc> cool, i'll let them know
[15:16] <juliank> nacc: The problem is simple: They specified openjdk-8-jdk-headless, but need to specify openjdk-8-jre-headless.
[15:17] <juliank> Otherwise, the order is undefined
[15:17] <juliank> java7-runtime-headless is provided by a jre package, not a jdk
[15:18] <juliank> I know, confusing
[15:20] <nacc> juliank: even though openjdk-jre-headless is a dependency of openjdk-8-jdk-headless?
[15:20] <juliank> yes
[15:21] <nacc> openjdk-8-jre-headless, rather
[15:21] <juliank> apt is dumb
[15:21] <nacc> ok, apparently this didn't hit them before, but i'll let them know
[15:21] <nacc> juliank: thanks!
[15:22] <juliank> nacc: we really need a minimization pass for that, but we don't have one
[15:22] <nacc> juliank: np, thanks! that does make sense to me
[15:23] <juliank> So all we're left with is a greedy algorithm that picks too much stuff to install :)
[15:23] <juliank> at least it could solve it
[15:23] <juliank> :)
[15:26] <nacc> juliank: lol
[16:31] <LocutusOfBorg> tdaitx, I uploaded cmake
[16:31] <LocutusOfBorg> but please open an upstream bug for this issue
[16:31] <tdaitx> LocutusOfBorg: ack, thanks!
[16:32] <LocutusOfBorg> do you have a bug report?
[16:42] <slangasek> rbasak: libnss-myhostname> yes it's a bug, how did that creep in? :P
[16:58] <rbasak> slangasek: j_bicha filed https://launchpad.net/bugs/1766575
[16:58] <ubottu> Launchpad bug 1766575 in gnome-control-center (Ubuntu Bionic) "Drop libnss-myhostname recommends" [Low,Fix committed]
[17:00] <jbicha> slangasek: how urgent is libnss-myhostname. We were thinking about just SRUing it eventually
[17:02] <slangasek> jbicha: apparently it's not urgent since it's been in main since xenial without my knowing
[19:01] <slangasek> kees: hmm, did you forget to rotate the chairs in the tb agenda?
[19:04] <slangasek> infinity: I guess you're out to lunchinner, and won't make the TB meeting?
[20:31] <infinity> slangasek: You guessed correctly.
[20:32] <slangasek> infinity: woo I'm a psychic
[21:08] <jbicha> slangasek: please moderate my ubuntu-devel-announce email (call for votes for DMB)
[21:11] <slangasek> jbicha: done
[21:51] <xnox> jibel, Laney - in your magic bug report of https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1765724 I see that, in-fact, despite initial timeouts and multiple attempts, the swap does come up eventually, and it is activated. The gnome-shell however fails to start on said machine.
[21:51] <ubottu> Launchpad bug 1765724 in gnome-shell (Ubuntu) "Xenial -> Bionic - System fails to boot after upgrade - gnome-screensaver & gnome-shell fail to start?" [Undecided,New]
[21:52] <xnox> jibel, Laney - could you check the logs there, to see if that machine is (a) a VM and (b) is not capable of running gnome-shell and (c) needs to be reconfigured with some other graphics card? (e.g. QXL or which one is the good one?)
=== led_ir23 is now known as led_ir22
[23:56] <Unit193> sarnold: Here?
[23:57] <sarnold> hey Unit193 :)
[23:57] <Unit193> Mind a PM?
[23:57] <sarnold> sure