[17:03] <pleia2> jose: any way we can get the Ubuntu Women session on the schedule for 1800 on the 10th? :) (that's our usual meeting time, so would be super helpful schedule-wise for most of us)
[17:04] <jose> pleia2: lemme check
[17:05] <jose> pleia2: it's set now, could you please check?
[17:06] <pleia2> jose: perfect! thank you so much
[17:06] <jose> not a problem :)
[18:08] <jose> popey: hey, do you think an ubuntuonair webapp would work?
[18:10] <jcastro> mhall119, submitting non-bp sessions should show in the sidebar instanly right?
[18:10] <jcastro> mhall119, nm, forgot to accept!
[18:28] <mhall119> jcastro: there ya go :)
[19:01] <jose> mhall119: I don't know if it'll be good to indicate to track leads that only people listed as 'required to attend' are shown the hangout link?
[19:13] <mhall119> jose: everybody should see the hangout link now, we changed that
[19:14] <jose> well, as long as we don't have trolls in there it should be fine :)
[19:16] <mhall119> whoever sets up the hangout can kick/ban people if needed


[00:10] <Gibby> crap znc messed up, i didn't see if anybody responded to my metadata issue
[12:13] <mrand> No-one responded Gibby.  #mythtv-users or the mythv-users mailing list would be your best out
[12:38] <Gibby> thanks mrand
[12:46] <Gibby> from what i am reading looks like a mythbuntu issue, all the correct packages are installed......
[13:22] <mrand> Gibby: I haven't had time to study the metadata stuff in general.  Here is a recent bug that may or may not be related: http://www.launchpad.net/bugs/707903
[13:22] <Zinn> [www.launchpad.net] Bug #707903 in mythplugins (Ubuntu): “Example series name overrides enabled by default in jamu.conf”
[13:37] <Gibby> Tjat dpesm
[13:38] <Gibby> tjsdyt fprdm
[13:38] <Gibby> uhhh fingers on wrong keys lol
[13:39] <Gibby> this isn't a jamu.conf issue this is the build in meta grabber....
[14:34] <Gibby> looks like phython is missing some of the module names, which packages is supposed to import them?
[15:05] <Gibby> fixed it, looks like python-lxml was missing, this is on a less than 24 hour old build
[15:23] <superm1> Gibby, i missed the context on this, is a depends missing on something?
[15:23] <Gibby> Yeah it looks like it, I just opened https://bugs.launchpad.net/mythbuntu/+bug/710709
[15:23] <Zinn> [bugs.launchpad.net] Bug #710709 in Mythbuntu: âMissing python-lxml on new installâ
[15:24] <Gibby> Also, can someone approve me for
[15:24] <Gibby> Mythbuntu Bug Team so I can get the emails on new bugs
[15:24] <Gibby> My new job is kinda relaxed and slow so hopefully I will have more time for myth again
[15:26] <superm1> mrand, ^
[15:29] <superm1> Gibby, i just added the depends to fixes and master.  will be in next autobuilds
[15:30] <Gibby> cool
[15:30] <Gibby> for someone reason only seemed to effect my diskless FE's, the harddisk FE's are Ubuntu with myth added so that might be why since the diskless are mythbuntu
[15:45] <bitkiller> i'm trying to install mythbuntu on a laptop but the keyboard stops working during install
[15:46] <bitkiller> aany idea?
[15:49] <Gibby> laptop model?
[15:49] <bitkiller> old ecs g732
[15:50] <bitkiller> the keyboard is fine. works in bios and other OS
[15:51] <bitkiller> using mbuntu in live mode also locks the keyboard
[15:51] <bitkiller> now i have the system copied but can't fill the user/password form
[15:52] <bitkiller> can't go ahead
[15:55] <bitkiller> the power button worked...rebooting
[16:02] <bitkiller> at some point during install wizard, i press tab and it looks like it is kept pressed
[16:02] <bitkiller> however this only happens during mbuntu install. tab key is fine
[16:18] <Gibby> so it is fine now after you rebooted?
[16:18] <bitkiller> no
[16:19] <bitkiller> i've found after another reboot that the keyboard works after some few typings
[16:19] <bitkiller> and then freezes
[16:31] <Gibby> can you do "ctrl+alt+f1"?
[16:34] <bitkiller> well, sorry, Gibby, i hadnt seen your ctrl+...message. I entedered username and pass one character length and it seems installation is going well
[16:38] <ComradeHaz`> Hi all, I am having an issue whereby sometimes on boot my machine seems to forget some prior config. It asks me what language I want and asks me to confirm database settings, and also reverts to the default myth TV background as opposed to the Mythbuntu one
[16:38] <ComradeHaz`> Has anyone any idea what can be causingf this?
[16:51] <bitkiller> installed, but but mouse and keyboard got frozen after bott
[16:51] <bitkiller> boot
[16:52] <bitkiller> attempting install ubuntu first
[17:26] <ComradeHaz`> Hi all, on the new Mythbuntu installer, what are Windows remotes called in the options list?
[17:32] <tgm4883> ComradeHaz`, windows media centre remote?
[17:37] <ComradeHaz`> tgm4883: yeah
[17:37] <tgm4883> ComradeHaz`, thats what it should be listed as
[17:37] <ComradeHaz`> Oh. It's not.
[17:37]  * ComradeHaz` goes to be sure
[17:38] <tgm4883> ComradeHaz`, on 10.10?
[17:38] <superm1> i think maybe we should reorganize that list with submenus
[17:38] <superm1> like popular remotes (3-5) and then "Other"
[17:38] <superm1> i'm not sure how easy that would be to do though
[17:39]  * ComradeHaz` whimpers and mumbles something about going mad
[17:39] <ComradeHaz`> Sorry guys :D
[17:40] <tgm4883> :)
[17:41] <tgm4883> superm1, you mean something like having too combo boxes, or having a single one and stick popular at the top then have everthing else under --other--
[17:43] <superm1> a single one
[17:44] <superm1> popular at top, and then a submenu on there for other
[17:45]  * tgm4883 shrugs
[17:45] <ComradeHaz`> Another issue I've been wondering about: if I don't select my Myth Box HDMI input on my HDMI switch box before turning on my machine, I cannot get any picture without rebooting. Is there anyway to force the GPU to come on regardless?
[18:03] <Gibby> do you have another video output hooked up also
[18:03] <rhpot1991> ComradeHaz`: sounds like edid data isn't detected, you could hardcode it in xorg.conf (yuck)
[18:04] <rhpot1991> just get used to having the switchbox set before powering on, I have that issue with a kvm
[18:15] <ComradeHaz`> Gibby: good point, there is an internal GPU. I think it's as disabled as I can make it
[18:16] <ComradeHaz`> (something like disabled while other is active being best option available)
[18:18] <mrand> rhpot1991: you can grab the edid data easy enough I think, but I guess you're saying translating that into xorg is a pain?
[18:18] <mrand> ComradeHaz`: be sure to search ... someone may already have an xorg.conf for your display
[18:18] <ComradeHaz`> Unsure, will have to investigate later, off out now and late.
[18:21] <ComradeHaz`> Thanks for your help!!
[18:21]  * ComradeHaz` runs
[18:22] <rhpot1991> mrand: ya some things don't translate as easily
[18:22] <rhpot1991> some things in xorg aren't nice to setup, and edid automagically does them for you
[18:24] <bitkiller> keyboard also freezes in ubuntu


[00:40] <sparr> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc6/ has five patch files that are applied to the source before building the mainline kernel
[00:41] <sparr> https://help.ubuntu.com/community/Kernel/Compile and https://wiki.ubuntu.com/KernelTeam/GitKernelBuild don't mention those steps
[00:42] <sparr> if I am trying to build a kernel that is as close as possible to the ubuntu packaged kernels, should I be applying those or any other patches?
[00:42] <sparr> aww, damnit, sorry, all that belongs in another channel. sorry
[09:48] <LocutusOfBorg> hello oSoMoN
[09:48] <oSoMoN> hi LocutusOfBorg
[09:48] <LocutusOfBorg> can I upload a chromium fix for https://bugs.launchpad.net/ubuntu/+source/python-selenium/+bug/1667208 ?
[09:48] <LocutusOfBorg> my wild guess is: let chromium-chromedriver provide chromium-driver
[09:48] <LocutusOfBorg> and add a symlink from /usr/lib/chromium-browser/chromedriver to /usr/bin/chromedriver
[09:49] <LocutusOfBorg> this way chromium should expose the same binary packages as debian, and the binary would be in the same location, so applications can use it
[09:50] <oSoMoN> LocutusOfBorg, why not patch python-selenium to change the hardcoded path?
[09:51] <LocutusOfBorg> because we would need to patch all the reverse-dependencies if we do it that way...
[09:51] <LocutusOfBorg> do you have a reason for exposing tools in a different location with debian?
[09:53] <oSoMoN> no specific reason, just trying to figure out the least invasive fix − I'm not sure I understand why reverse deps would need to be patched, if the path is already in python-selenium, do other packages hardcode it too?
[09:54] <LocutusOfBorg> maybe ruby-selenium-webdriver?
[09:54] <LocutusOfBorg> not sure how many else...
[09:55] <LocutusOfBorg> ./lib/selenium/webdriver/chrome/service.rb:        @executable = 'chromedriver'.freeze
[09:55] <LocutusOfBorg> ./lib/selenium/webdriver/chrome/service.rb:          Unable to find chromedriver. Please download the server from
[09:55] <LocutusOfBorg> if applications are supposed to find it in $PATH, I think we should patch chromium...
[09:56] <oSoMoN> that makes sense
[09:56] <LocutusOfBorg> in the future more applications might start using it, this is why I think the binary package should be provided and the tool exposed in the system in a sane-way, otherwise we might not even have a way to find what in the archive breaks because of this
[09:57] <oSoMoN> LocutusOfBorg, please do not upload the fix right away though, as there's a new release in the stable channel for which I was preparing an upload when you pinged, if you make a patch and hand it to me I'll include it
[09:57] <LocutusOfBorg> oSoMoN, I think I'll reassing the bug to chromium, and I'm already looking at how debian did it, I'll provide a patch shortly
[09:58] <LocutusOfBorg> thanks for confirming my analysis, I'm of course not a chromium user/developer :)
[09:58] <oSoMoN> LocutusOfBorg, thanks, I'll put my upload on hold until I get your patch
[09:58] <LocutusOfBorg> mmm interesting, the debian package is 100MB, the Ubuntu one is 700MB
[09:59] <oSoMoN> I haven't checked in a while, they probably strip down the upstream source tarball
[10:05] <LocutusOfBorg> since nobody is using the old location https://codesearch.debian.net/search?q=browser%2Fchromedriver
[10:05] <LocutusOfBorg> I think I will avoid the symlink
[10:18] <LocutusOfBorg> https://paste.ubuntu.com/p/5TQn4kBMv6/
[10:18] <LocutusOfBorg> oSoMoN, ^^ it takes more time for the debdiff than for the patch itself...
[11:31] <oSoMoN> LocutusOfBorg, note that the description of bug #1667208 is incorrect, it says "/usr/lib/chromium/chromedriver" but it's "/usr/bin/chromedriver"
[11:40] <LocutusOfBorg> true...
[11:43] <oSoMoN> LocutusOfBorg, here is an updated diff, would you mind giving it a sanity check? https://paste.ubuntu.com/p/mdzS9BGmVt/
[11:44] <LocutusOfBorg> yes, I like it!
[11:44] <LocutusOfBorg> of course if it builds :)
[11:45] <oSoMoN> wait, I forgot the provides line
[11:45] <oSoMoN> adding it
[11:45] <LocutusOfBorg> oops true
[13:55] <rbasak> In backporting certbot from Bionic to Xenial, dh_installsystemd no longer exists which I think is causing the timer and service to no longer be installed.
[13:55] <rbasak> Suggestions?
[13:56] <rbasak> How were systemd services installed back then?
[13:57] <LocutusOfBorg> rbasak, hold on
[13:59] <LocutusOfBorg>  dh-systemd | 1.29ubuntu4                 | xenial-updates/universe   | all
[13:59] <LocutusOfBorg>  dh-systemd | 10.2.2ubuntu1~ubuntu16.04.1 | xenial-backports/universe | all
[13:59] <LocutusOfBorg> using dh-systemd from backports should work...
[13:59] <LocutusOfBorg> rbasak, is it ok?
[14:00] <LocutusOfBorg> anyway, you should build-depend on dh-systemd (>= 1.5) on control file, it wasn't part of debhelper at that time
[14:03] <rbasak> I can do that. Thanks!
[14:03] <LocutusOfBorg> in virtualbox/xenial I simply do dh --with systemd
[14:04] <LocutusOfBorg> and it should take care of mostly of it...
[14:04] <rbasak> I'll give that a try.
[14:04] <rbasak> I had completely forgotten about dh-systemd!
[14:05] <LocutusOfBorg> man dh_systemd_enable should give you the best answer :)
[14:05] <LocutusOfBorg> it took me a while to that back in time :)
[14:07] <rbasak> Oh. It's in backports?
[14:07] <rbasak> This is for an SRU.
[14:07] <rbasak> Will 1.29 be enough?
[14:07] <rbasak> It's >= 1.5 of course ;)
[14:08] <LocutusOfBorg> not sure, vbox uses virtualbox.service IIRC and it works
[14:09] <rbasak> It looks like certbot.service got installed but not the timer.
[14:09] <rbasak> And the override_dh_installsystemd didn't run.
[14:09] <rbasak> But I can trawl through the docs now. Thanks again!
[14:16] <LocutusOfBorg> override_dh_systemd_enable:
[14:16] <LocutusOfBorg>         dh_systemd_enable -p$(sname) --name vboxweb --no-enable debian/vboxweb.service
[14:16] <LocutusOfBorg> this is what I did in vbox for non-standard services names
[14:17] <LocutusOfBorg> if it is non-standard naming you should anyway tell it how to enable
[14:25] <rbasak> dh_systemd_enable: Could not find "certbot.timer" in the /lib/systemd/system directory of certbot. This could be a typo, or using Also= with a service file from another package. Please check carefully that this message is harmless.
[14:25] <rbasak> Maybe I can just installed that manually with dh_install
[14:25] <rbasak> (well, certbot.install)
[14:26] <rbasak> The certbot.service is ending up in the deb though.
[19:43] <Ark74> ricotz, hello!
[19:44] <Ark74> I've being studiying the libreoffice ppa compilation/build.
[19:44] <Ark74> Is this a good place to ask about it?
[19:44] <hggdh> kenvandine: ping re. a few gnome packages and snaps
[19:47] <kenvandine> hggdh: pong
[19:48] <hggdh> kenvandine: we compared the installed snaps from a Disco RC with an upgraded-to-Disco install. The RC install brings in gnome-(calculator|characters|logs|system-monitor), while on the already-existing system these are all (Disco) packages
[19:48] <hggdh> kenvandine: even more, at least gnome-calculator is at a different version package x snap
[19:48] <kenvandine> hggdh: upgraded from what?
[19:49] <kenvandine> disco has the devel series of the debs
[19:49] <kenvandine> the snaps are built from the upstream stable series
[19:49] <kenvandine> which is still 3.30.x
[19:49] <kenvandine> once that hits 3.32 the snaps will as well
[19:50] <hggdh> kenvandine: the upgraded system was Bionic->Cossmic->Disco
[19:50] <kenvandine> bionic shipped with those 4 as snaps not debs
[19:50] <kenvandine> so it should have the snaps instead
[19:51] <kenvandine> hggdh: could it have been an upgrade from a bionic system that was originally installed before bionic release?
[19:51] <kenvandine> the switch to the snaps was pretty late
[19:51] <hggdh> my snap list only shows gnome-common-themes
[19:52] <kenvandine> they were seeded pretty late, so if you installed around beta you wouldn't have gotten the snaps
[19:52] <hggdh> kenvandine: it *might*, yes. I got the laptop in... Feb 2018, so before release
[19:52] <kenvandine> ah, yeah they weren't seeded yet
[19:52] <hggdh> yeah
[19:52] <kenvandine> so they would have been there as debs
[19:54] <hggdh> k. Still, then, we now have two different paths -- older systems still carry the package, new ones carry the snap
[19:55] <hggdh> but they are at different versions. The gnome-calculator package on Disco is 1:3.31.90-1ubuntu1, the snap (stable) is 3.30
[19:55] <hggdh> (edge does have a 3.31.90)
[19:55] <kenvandine> yeah
[19:56] <kenvandine> that's the intent
[20:54] <zimmerian> so this is probably a larger apt / dpkg thign but on remove my symlink gets removed
[20:54] <zimmerian> nothing in post pre scripts
[20:54] <zimmerian> is this a known bug?
[20:55] <zimmerian> or could it be the upgrading package at fault?
[20:55] <cjwatson> not very clear what you mean - how is this symlink created?
[20:55] <infinity> ^
[20:56] <infinity> Need more info here.  What symlink, what package is being removed, does the package believe it exclusively owns that path?
[20:56] <infinity> dpkg makes no real distinction between links and files
[20:57] <cjwatson> (except for some details around symlinks vs. directories on upgrade)
[20:57] <zimmerian> k - let me look a bit deeper I think I may know what's going on - sorry and thanks
[20:57] <cjwatson> Certainly if a symlink is shipped in a .deb then it'll be removed when that package is removed.
[20:57] <cjwatson> Intentionally
[20:57] <infinity> Or if you replace a file shipped by a deb with a symlink.
[20:58] <infinity> Same story.
[21:01] <zimmerian> okay nope - still confused … so more info time - let me write this to be more clear and concise :-)
[21:06] <zimmerian> alright - I hope this helps
[21:06] <zimmerian> https://pastebin.com/bw1MpGDU
[21:08] <sarnold> maybe start with ls -l and dpkg -L output with the old version and new version of your package
[21:09] <cjwatson> It's possible that dpkg feels itself entitled to clean up the top-level directory (actually a symlink) when there was previously exactly one package using it and then that package was removed.
[21:09] <cjwatson> Not really specific to /opt except that packages generally don't install under /opt but apparently this one does.
[21:09] <zimmerian> cjwatson: that is true - it is the only package afaik
[21:09] <zimmerian> and yes - I fig'd that but this is the only package using /opt :-)
[21:10] <cjwatson> Not sure if there's a good way to avoid that here.
[21:10] <cjwatson> It's just generic "remove cruft that appears to be no longer used" code
[21:10] <zimmerian> hmm well I can create a stupid package with /opt/dont_delete_me or something
[21:10] <zimmerian> maybe that'd work
[21:10] <zimmerian> but curious if I should file this as a bug w/ debian
[21:11] <infinity> It's not a bug.
[21:11] <zimmerian> after I do actually test your theory - which seems to apply
[21:11] <cjwatson> I mean you could, but I'm not sure how it would be fixable even in theory
[21:11] <infinity> dpkg will always remove a directory when the last package owning it is removed.
[21:11] <infinity> (if it's also empty)
[21:11] <zimmerian> infinity: it's a symlink and there's other stuff that the symlink has -
[21:12] <zimmerian> it's a bug IMO
[21:12] <zimmerian>  /other/moar_stuff does exist
[21:12] <infinity> It might be a bug if it's non-empty and dpkg has decided to treat it as a file instead of a directory.
[21:12] <zimmerian> and so this has a larger impact
[21:12] <cjwatson> The question is how it could possibly be fixed without breaking lots of other stuff
[21:13] <cjwatson> But it's certainly not Ubuntu-specific, so if you wanted to pursue it then the proper place would be a bug report on Debian dpkg, yes
[21:13] <zimmerian> cjwatson: true but I'm hoping somehow a test -L can be used - dunno
[21:13] <zimmerian> thank you all!
[21:13] <infinity> It's not about testing if it's a link and then not removing it.
[21:14] <infinity> It's about resolving it, treating it as a directory, and then applying the directory tests.
[21:14] <zimmerian> well to see if it is indeed because no other packages are using there
[21:14] <infinity> (if not empty, don't remove)
[21:14] <infinity> So it does indeed feel like a bug in this case, if the target isn't empty.
[21:14] <zimmerian> yeah - I agree infinity but I think that would actually make it a bigger quest perhaps?
[21:15] <cjwatson> dpkg just tries rmdir/unlink and ignores stuff like ENOTEMPTY; it doesn't look before it leaps
[21:15] <zimmerian> not sure of the cost of delving into each / every item to see if there's something else if it's a symlink
[21:15] <cjwatson> (if it has no remaining references to the thing)
[21:16] <zimmerian> and it makes some sense from the apt / deb side
[21:16] <cjwatson> nothing to do with apt
[21:16] <cjwatson> purely dpkg
[21:16] <cjwatson> whether it's a bug or not
[21:17] <infinity> I mean, the word "bug" is perhaps not the right one here.  Misfeature. :P
[21:17] <zimmerian> cool - well thanks all - I'll see what I can find
[21:17] <zimmerian> hehehe true
[21:17] <infinity> I think it's behaving as expected (by the people who wrote it), but those people could be seen to be wrong, based on what a user might expect in this case.
[21:18] <cjwatson> It is mildly surprising, looking at the code, because it should try rmdir first, get ENOTEMPTY, give up before getting as far as the unlink that must have removed the symlink.  But I haven't often needed to look at this code so might be misreading something.
[21:18] <infinity> cjwatson: Or, the misfeature was fixed, and you're reading a newer version than he's using.
[21:19] <infinity> Guillem does have a nasty habit of improving dpkg occasionally.
[21:19] <cjwatson> oh, I'm misreading
[21:19] <cjwatson> rmdir would get ENOTDIR in that case, and then it falls through
[21:19] <infinity> Ahh.
[21:20] <infinity> But that also highlights a maybe-not-computationally-insane path to fixing it.
[21:20] <infinity> If ENOTDIR, check linkiness, check contents of target, bail if not-empty.  *hand-wavy*
[21:20] <cjwatson> Maaaaybe.  If there aren't legit cases that would break
[21:20]  * cjwatson is happy for somebody else to think through that maze
[21:21] <zimmerian> well I'll be - seems like way back this was a thing and well … still is
[21:21] <zimmerian> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182747
[21:21] <cjwatson> Probably means it's hard :)
[21:21] <zimmerian> …. and in true fashion - also /opt :-D
[21:21] <infinity> Yeah.
[21:21] <infinity> The real answer here might be to admit that /opt is a thing and ship it in base-files. :P
[21:22] <infinity> google packages have similar potential issues.
[21:23] <infinity> My hot take is that as soon as something is in deb/rpm form, it should be installing to system locations, not /usr/local or /srv or /opt, but obviusly there are those who disagree, and plenty of packages in the wild to prove it.


[17:50] <rtg> tseliot, how are you coming long on the nVidia drivers for the v4.10 kernel ? I see that we're still having ADT build failures.
[17:51] <tseliot> rtg: I am looking at the changes in the CPU hotplug code, and I'm a bit confused, as, apparently, I have to use the cpuhp_setup_state() function but I'm not sure about the first two arguments
[17:52] <tseliot> the first one is from an enum
[17:52] <tseliot> the second is a string
[17:53] <tseliot> following this pattern subsys/xxx/yyy:state
[17:54] <tseliot> the last two arguments are clear to me
[17:55] <tseliot> I'm not sure whether the first argument should be CPUHP_AP_ONLINE_DYN or CPUHP_HP_ONLINE, or something else.
[17:56] <rtg> tseliot, you've exceeded my knowledge in that area
[17:58] <tseliot> rtg: well, it's the first time I read the code too. I'll looking for examples within the kernel, and I'll experiment a bit. I'll let you know when this is done
[17:59] <rtg> tseliot, thanks, we're close to promoting a v4.10 kernel to proposed. I'd really like the nVidia drivers to at least build
[17:59] <tseliot> rtg: working, in addition to building, would be a nice plus ;)
[17:59] <rtg> indeed
[18:04] <tseliot> documentation FTW! https://static.lwn.net/kerneldoc/core-api/cpu_hotplug.html
[18:09]  * tseliot has an idea or two on how to do it
[21:14] <ricotz> rtg, hi, seems new intel i915 guc firmware is still missing
[23:33] <rtg> sforshee, ^^