[00:26] <rbasak> pdeee: sorry, I have a big backlog of outstanding things to do for people from before Christmas. Still working my way through (as well as regular work). It's my SRU day today (Wednesday) though, so I'll see if I can review it as part of that.
[00:34] <jbicha> tzero: you could also try #debian-python on OFTC
[00:37] <tzero> jbicha: cool, I'll try that, thanks
[00:38] <tzero> I severely underestimated how much time and effort it would take to create a PPA for a project :/
[00:47] <pdeee> rbasak, thanks!
[01:01] <nacc> bdmurray: sorry, I'll clarify in the bug!
[01:20] <nacc> tarpman: openldap import should be done now
[09:39] <Laney> elopio: I needed to restart one of the machines - all the others seemed okay
[10:00] <Saviq> wgrant, hey, another builder kernel update? arm64 fails to build again https://bileto.ubuntu.com/#/ticket/2272
[10:01] <Saviq> better link https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2272/+build/11841438
[10:03] <sil2100> Yeah, I published a new kernel to -updates/-security yesterday, so maybe the builders go those automatically
[10:09] <Saviq> oSoMoN, do you know of an oxide throw of "'std::out_of_range'   what():  map::at"?
[10:11] <oSoMoN> Saviq, could it be https://bugs.launchpad.net/oxide/+bug/1643976 ?
[10:11] <oSoMoN> huh, why is this bug private?
[10:13] <oSoMoN> bug #1643976
[10:14] <Saviq> oSoMoN, yup, looks like it
[10:15] <oSoMoN> Saviq, can you please confirm (and add details if relevant)
[10:19] <Saviq> ack
[10:42] <gabmus> hello people. I am making a graphical application to install GPU drivers on linux, and I'd need some help. I use arch but I'd want to make this application compatible with any (or most) distro. Could you please tell me the packages you need to install on ubuntu 16.04 and 16.10 to get the drivers working respectively for nvidia, nvidia+intel (optimus), intel, amd, amd+nvidia and intel+amd (primus)?
[10:43] <gabmus> thank you
[10:50] <rbasak> gabmus: Ubuntu already does this in System Settings->Software & Updates->Additional Drivers. If you still want to write an alternative app, perhaps look at the source of the existing one?
[10:51] <rbasak> I'm not sure if my knowledge is current. Maybe try #ubuntu-desktop.
[10:52] <gabmus> rbasak: It's much easier to just get a list of packages from users. If there was a good wiki page about this it'd be better. Don't worry if your knowledge is a bit dated, it's still more than I have right now :)
[10:52] <rbasak> gabmus: the list of packages will fall out of date though.
[10:53] <gabmus> rbasak: and I will update it. it's not possible to make this kind of application without updating it.
[11:30] <wgrant> Saviq: argh, new one uploaded.
[11:30] <wgrant> Will take a couple of hours to build.
[11:37] <LocutusOfBorg> nacc, imagemagick uppdate/merge?
[11:58] <Saviq> wgrant, thanks
[12:36] <juliank> On a partial request for https://netix.dl.sourceforge.net/project/corefonts/the%20fonts/final/andale32.exe, the sourceforge redirector responds with 302 Found Location: http://downloads.sourceforge.net/mirrorproblem?failedmirror=netix.dl.sourceforge.net
[12:36] <juliank> - that thing is madness
[13:02] <ginggs> I'm seeing a few packages coming from Debian that have recently added 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' and now FTBFS in Ubuntu.  Is it sane to change that to 'hardening=+all,-pie' ?
[13:03] <cjwatson> hardening=+all in Debian is a deliberate request to opt into PIE
[13:03] <cjwatson> so that sounds like a peculiar approach to fixing the build failures
[13:04] <ginggs> compare a build log: https://buildd.debian.org/status/fetch.php?pkg=flint&arch=amd64&ver=2.5.2-14&stamp=1482283514
[13:04] <ginggs> https://launchpadlibrarian.net/299303934/buildlog_ubuntu-zesty-amd64.flint_2.5.2-14_BUILDING.txt.gz
[13:04] <ginggs> look for the './configure' line
[13:05] <ginggs> on the Ubuntu build log has -fPIE
[13:05] <ginggs> *only
[13:06] <juliank> Both should do -fPIE according to man, wonder what changed
[13:06] <cjwatson> Debian's dpkg-buildflags doesn't emit -fPIE nowadays since it's the default in the toolchain
[13:06] <cjwatson> AIUI
[13:06] <cjwatson> see Debian #835149
[13:06] <ginggs> in this case we are building a library, so we don't actually want PIE, right?
[13:07] <juliank> Don't we really want the newer dpkg with that change?
[13:07] <cjwatson> that would seem better than hacking about with individual packages
[14:11] <LocutusOfBorg> I agree, I had to patch libpng, gdal and many more for this pie stuff
[14:11] <LocutusOfBorg> not sure why doko didn't switch it yet
[14:11] <LocutusOfBorg> and I'm also waiting for the new dpkg to merge sbuild
[14:12] <slangasek> kenvandine: did you mean to edit the TB calendar event,
[14:12] <slangasek> kenvandine: or was that an Ubuntu Phone playing havoc with sync?
[14:12] <LocutusOfBorg> gdcm patched too
[14:12] <kenvandine> slangasek, no... i didn't... it must have been my phone
[14:12] <kenvandine> damn!
[14:12] <kenvandine> sigh
[14:13]  * kenvandine disables canonical account on all devices
[14:34] <elopio> thanks Laney. Testing again.
[15:22] <caribou> I'm doing an SRU of a fix in Zesty that brought in two new values to a conffile. Those values are not required to be present in the conffile and can be added later to alter some timings. Would it be sufficient to add a mention in the README to avoid a conffile prompt ?
[16:44] <RFleming> Greetings and other salutations...
[16:45] <RFleming> Is there a way to change the mount options for gvfsd-fuse to allow root access to /run/user/x/gvfs... or is it hardcoded somewhere?
[17:25] <nacc> RFleming: did you perhaps want #ubuntu for that question?
[17:26] <nacc> tarpman: were you able to look at the openldap import? did it provide what you needed?
[18:26] <tarpman> nacc: sorry for the delay, import looks great, thanks a lot!
[18:26] <nacc> tarpman: np! just wanted to check in
[18:55] <RFleming> nacc: I did ask #ubuntu and in #gnome as well.  I thought to ask here as GVfs is a fundamental part of GNOME and Unity and if anyone knew how to modify how gvfs-fuse-daemon started, it would be developers.
[18:58] <RFleming> nacc: I'm also aware this really is a fuse issue (in that root can't stat the gvfs folder)
[18:59] <RFleming> nacc: that's why I was hoping someone would have an idea on passing further options to gvfs-fuse-daemon that would allow root to at least stat the gvfsd-fuse mount
[19:02] <nacc> RFleming: ok, i just meant topically
[19:03] <nacc> RFleming: note that it seems root can ls it with gvfs-ls
[19:03] <RFleming> nacc: Yes, that is true... but the problem is with backup software which doesn't know.
[19:04] <RFleming> instead it tries to stat it (even though it is ignored ... same with the fstype) and fails to generate a list of files it can backup because it errors out.
[19:05] <RFleming> I have to manually unmount the gvfsd-fuse mount for backups to function.
[19:05] <RFleming> It truly is a GNOME only thing
[19:05] <RFleming> FYI: the backup software is Veritas Backup Exec
[19:06] <nacc> RFleming: why are you backing up /run?
[19:06] <RFleming> I'm not, but the agent has to scan the filesystem
[19:07] <RFleming> ... /run is ignored, so is the gvfsd-fuse filesystem type.
[19:07] <RFleming> but it still stats every directory
[19:07] <RFleming> It's frustrating
[19:08] <nacc> that sounds like broken software
[19:08] <nacc> why woudl it need to stat directories it is going to ignore?
[19:08] <RFleming> my guess is "Because it's easier".
[19:09] <RFleming> it appears to use the ignore lists to not put those items in the selectable list, not in ignoring what to stat
[19:11] <dobey> so it sounds like you should complain to veritas then
[19:11] <RFleming> they don't particularly care
[19:11] <dobey> their software is broken
[19:11] <RFleming> their answer is... you shouldn't be using GNOME in a server environment, unmount it
[19:12] <RFleming> but this deviates from the question on how to pass additional options gvfs-fuse-daemon that would let root stat it (without using gvfs commands)
[19:12] <dobey> so it works with other fuse mounts?
[19:12] <RFleming> if it isn't possible, then that's that.
[19:13] <RFleming> I don't have other fuse mounts
[19:13] <dobey> and does "sudo stat" work on the mount point?
[19:14] <RFleming> no
[19:14] <smoser> anyone know how to make this new-fangled ipython work in vi mode ?
[19:14] <smoser> with the old link to readline i used to hit ctrl-alt-j
[19:14] <RFleming> dobey: as root /run/user/x/gvfs says permission denied
[19:15] <smoser> i think i'm supposed to be able to do:
[19:15] <smoser>  %config TerminalInteractiveShell.editing_mode = 'emacs'
[19:15] <smoser> per http://ipython.readthedocs.io/en/stable/config/options/terminal.html
[19:15] <smoser> (err... = 'vi') but that doesnt seem to work for m
[19:15] <smoser> me
[19:16] <dobey> RFleming: the problem has nothing to do with gvfs
[19:17] <dobey> hmm
[19:19] <nacc> rbasak: ok, i might have found a problem with our -devel pointers
[19:20] <dobey> RFleming: well maybe it's a bug in gvfs-fuse then
[19:20] <dobey> RFleming: you could just uninstall gvfs-fuse perhaps
[19:20] <RFleming> how would that impact Unity?
[19:20] <dobey> it wouldn't
[19:21] <dobey> gvfs-fuse is just a magic thing to expose gvfs "mounts" as traditional filesystem mounts so you can access with things that don't support gvfs
[19:21] <RFleming> ok
[19:22] <RFleming> It might be better to disable it first
[19:24] <RFleming> dobey: thanks.
[19:25] <dobey> sure
[20:32] <nacc> jbicha: for the pacemaker merge, i see you kept a delta in the yakkety merge, but it only applies if upgrading from 14.04 -- it seems like that could have been dropped post x release?
[20:36] <jbicha> nacc: I don't know much about the package
[20:37] <jbicha> I think the changelog is confusing though, I think it's intent is "to maintain compatability with how that package used to work, keep these packages as recommends"
[20:37] <nacc> jbicha: yeah, i might update in the updated merge to make that clear
[20:37] <jbicha> I
[20:38] <jbicha> 've no idea how important those packages are
[20:39] <nacc> jbicha: ack, thanks!
[20:40] <nacc> jamespage: --^ i think you actually originated this in the first xenial merge; am I right in thinking we can drop that delta at this point? new installers don't need it (afaict), and upgraders will have it from x release?
[21:40] <nacc> rbasak: in your branch, `usd import` fails, because import_patches_unapplied_tree refers to oldcwd which no longer is defined?
[21:51] <nacc> slangasek: since we are not syncing from debian on src:ilohamail (fakesync), but debian has deleted that package, do I need to manually (via bug subscribing ~ubuntu-archive) request its deletion from Ubuntu?
[23:47] <rbasak> nacc: sorry, I'll take a look.
[23:47] <nacc> rbasak: np! i was just doing an import and hadn't switched my branch back :)
[23:58] <rbasak> nacc: I think the easiest way to fix that is to 1) not change the current directory; and 2) use dpkg-source -x ... dsc_path extract_dir.
[23:59] <rbasak> nacc: I'm not sure if you know that dpkg-source -x takes "output_directory" as an optional second positional argument. Do you see any other issue with that?
[23:59] <rbasak> We could do that in most places, actually.