[00:26] <smoser> i'd really appreciate it if someone could take a look at the cloud-init upload in xenial-proposed.
[00:26] <smoser> I dont intend to be quick about moving it out of proposed at all, but would like it to get *in* to proposed to further testing.
[00:27] <smoser> bug 1577872
[00:28] <smoser> bah. bug fail
[00:28] <smoser> bug 1595302
[00:28] <smoser> better
[04:35] <ubuntu__> here something i don't get in /proc/iomem the sound is apparently using this mmap  address  f7d30000-f7d33fff : ICH HD audio doing out the math you only have 16 KB of memory for the buffer of audio . If your sampling  at 32-bit, 192 kHz how is this buffer going to be large enough. Maybe i am misunderstanding something
[04:50] <mgedmin> that's probably just the control registers
[04:50] <mgedmin> I would expect audio buffers to be DMAed from the main memory
[05:32] <cpaelzer> good morning
[05:36] <Skuggen> nacc: Just in case it wasn't clear, it does mean it's actually trying to connect to a database named "${db_name}"
[05:36] <Skuggen> nacc: http://paste.ubuntu.com/17732610/
[05:36] <Skuggen> nacc: And that the user is valid, or you wouldn't see the «to database» bit
[06:14] <pitti> Good morning
[06:15] <pitti> rbasak: mysql-server-5.7 is now the only remaining rdepends of initscripts in the whole yakkety archive; sooo tempted to cherry-pick that upload to finally finish it off..
[06:15] <pitti> rbasak: would that actually get in your way somehow?
[06:16] <ubuntu__> So i am wondering about how this acpi works for advanced configuration power interface really confused
[06:16] <ubuntu__> curious anybody familar with how these ports work
[06:16] <ubuntu__>   0400-0403 : ACPI PM1a_EVT_BLK
[06:16] <ubuntu__>    0404-0405 : ACPI PM1a_CNT_BLK
[06:16] <ubuntu__>    0408-040b : ACPI PM_TMR
[06:16] <ubuntu__>    0410-0415 : ACPI CPU throttle
[06:16] <ubuntu__>    0420-042f : ACPI GPE0_BLK
[06:16] <ubuntu__>    0450-0450 : ACPI PM2_CNT_BLK
[06:16] <ubuntu__> I have these ports for it
[06:17] <ubuntu__> And  d9ff9000-da2f9fff : ACPI Non-volatile Storage
[06:17] <ubuntu__> da35b000-da5dafff : ACPI Non-volatile Storage
[06:17] <ubuntu__> da5db000-da5dffff : ACPI Tables
[06:17] <ubuntu__> da5e0000-da622fff : ACPI Non-volatile Storage
[06:17] <ubuntu__> for the mmap
[06:19] <ubuntu__> I understand it is made some how platform independent uses some type of bytecode though  don't really get it at all there are like  tons of tables with in the ACPI TABLE 20kb address space  like DSDT SSDT XSDT ...
[06:19] <ubuntu__> Anybody good with this stuff
[06:27] <rbasak> pitti: an upload to Yakkety? That's fine if you want to upload it.
[06:31] <pitti> rbasak: yes, that; ok, thanks
[06:55] <LocutusOfBorg> pitti, please try ubuntuone-dev-tools against python-coverage in proposed? :) thanks
[06:55] <LocutusOfBorg> or the opposite is even better
[06:56] <pitti> LocutusOfBorg: err, python-coverage pulls in ubuntuone-dev-tools? that sounds strange
[06:59] <pitti> LocutusOfBorg: running: http://autopkgtest.ubuntu.com/running.shtml#pkg-ubuntuone-dev-tools
[06:59] <LocutusOfBorg> ubuntuone-dev-tools has a test with coverage
[06:59] <LocutusOfBorg> and the coverage in proposed is fixed, together with ubuntuone-dev-tools in proposed
[06:59] <pitti> but it seemed to me that the new python-coverage regresses
[06:59] <pitti> oh, ok, great
[07:00] <LocutusOfBorg> :)
[07:00] <pitti> mvo: btw, I uploaded https://launchpad.net/ubuntu/+source/ubuntu-core-launcher/1.0.30ubuntu1 last night, it broke too many things
[07:00] <LocutusOfBorg> so, I guess you can retry the one against python-coverage, make python-coverage migrate, and then I can retry the one on ubuntuone-dev-tools and see it migrate too :)
[07:00] <LocutusOfBorg> or you can retry them both, as you like
[07:01] <pitti> mvo: still makes stuff uninstallable (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt), but I'll leave that other transition to you :)
[07:01] <LocutusOfBorg> I'm leaving, thanks pitti
[07:02] <mvo> pitti: thanks and sorry, we meant to release a new version but there were some hickups there too
[08:12] <LocutusOfBorg> thanks pitti it worked flawlessly
[08:12] <pitti> nice
[08:27] <flexiondotorg> Anyone able to review a trivial merge proposal for indicator-session that would really help out Ubuntu MATE? https://code.launchpad.net/~ubuntu-mate-dev/indicator-session/mate-compatibility/+merge/297183
[08:39] <kmadac> Hello, I would like to ask where to find ics-dhcp-client package repository for ubuntu xenial. I tried to make "bzr branch ubuntu:isc-dhcp-client isc-dhcp-client.dev", but I get Invalid url error. Thanks
[08:40] <Odd_Bloke> kmadac: UDD (which provides bzr branches for packaging) is not used for xenial, so AFAIK your best is to use pull-lp-source in the ubuntu-dev-tools package.
[08:41] <kmadac> Odd_Bloke: Thank you :)
[08:46] <Odd_Bloke> pitti: Good morning!  https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1584393 looks like an ifupdown/SSH systemd deadlock/race condition on xenial; do you have the time to dig in to it?
[08:57] <pitti> hey Odd_Bloke
[08:59] <pitti> Odd_Bloke: I can't reproduce this in a VM, but yes indeed, looks like a deadlock
[08:59] <pitti> Odd_Bloke: it could be fixed in openssh's if-up.d hook to reload asynchronously
[08:59] <pitti> or in invoke-rc.d to make all reloads async, but this is prone to break other things which expect it to block until it's actually done
[09:00] <Odd_Bloke> pitti: (If you do want a system to look at, I've `ssh-import-id pitti`'d on ubuntu@104.155.74.34)
[09:00] <pitti> also, utterly low-prio -- restarting networking has never worked at all under upstart, and now it at least seems to work most of the time
[09:00] <Odd_Bloke> pitti: Yeah, I'm only asking because we're beginning to hear from partners about it.
[09:01] <pitti> Odd_Bloke: works on your system too
[09:02] <Odd_Bloke> ... It didn't before.
[09:02] <Odd_Bloke> Weird.
[09:10] <Odd_Bloke> pitti: Thanks for the bug comment. :)
[09:45] <Unit193> jbicha: Howdy.  Do you plan to package numix-gtk-theme as well?
[09:47] <Unit193> Ah, #827792 I see.
[09:48] <mwhudson> i'm sure i'm missing something obvious (and i'm tired and my brain isn't working)
[09:48] <mwhudson> but can someone explain to me why golang-defaults is not migrating?
[09:48] <mwhudson> it says "golang-any-shared-dev/amd64 unsatisfiable Depends: golang-any"
[09:49] <mwhudson> but golang-any is made by the same package...
[09:51] <mwhudson> and the package installs fine
[09:57] <Unit193> jbicha: Also FWIW Shimmer/Xubuntu may look into the GTK-3.20 patch here soon, but since Ubuntu is standing still on that it's not a high priority in Greybird, at least last I knew.
[10:00] <Unit193> ...It'd be weird for the GTK theme to dep on the icon theme, I'd believe.  Recommends or suggests would be better.
[10:43] <shemgp> is this where i ask for help in fixing an ubuntu bug in a package?
[10:43] <shemgp> bzr branch ubuntu:tomboy tomboy.dev from http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching doesn't seem to work in my machine
[10:43] <shemgp> says: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/tomboy/".
[13:10] <brendand> has anyone here ever tried configuring virsh/kvm to run an ipv6 (only) network? i'm a bit lost as to why it won't work
[13:36] <pitti> rbasak: yay, mysql-5.7 went in, with it the new sysvinit, so initscripts is history now \o/
[13:43] <infinity> pitti: Do you have some armhf autopkgtest machines running trusty kernels and some running xenial kernels?
[13:44] <infinity> pitti: I'm seeing a regression on glibc/wily that looks suspiciously related to running kernel.
[13:44] <pitti> infinity: ah, in fact I do; have one with t/w/x each, to bisect bug
[13:45] <pitti> the "old" LXC nodes on cyclops all run xenial
[13:45] <pitti> but I also have some new scalingstack ones
[13:45] <infinity> pitti: I guess there's no way to direct a job at a specific machine? :P
[13:45] <pitti> infinity: but this is actually obsolete, it's not due to the VM guest kernel; so I can bring them all up to xenial again
[13:45] <pitti> infinity: there is with some hand-holding
[13:46] <infinity> pitti: Of course, if the goal is to bring them all to xenial, that doesn't help me here. ;)
[13:46] <pitti> infinity: we record the kernel version, so it's easy enough to check
[13:46] <pitti> infinity: oh, you are saying xenial's is *worse*?
[13:46] <infinity> pitti: Since it's the xenial builds that fail, all the green ones are trusty.
[13:46] <pitti> 'cause that's all we've ever had
[13:46] <pitti> *all*?
[13:47] <infinity> Well, the random sampling of green that I've looked at.
[13:47] <infinity> They all look to be 3.13
[13:47] <infinity> Only those select few reds were 4.4.0
[13:48] <infinity> But I've not been patient enough to download *all* the logs.  If you can prove me wrong, I'm all for it. :)
[13:48] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/armhf/g/glibc/20160610_025954@/log.gz
[13:48] <pitti> that indeed was a trusty kernel, yes (green)
[13:48] <pitti> ooh!
[13:49] <pitti> infinity: right, the cyclops boxes run trusty kernels on xenial userspace as newer kernels don't work on those any more
[13:49] <pitti> I forgot, sorry
[13:49] <infinity> "cyclops" being... highbanks?
[13:49] <pitti> yes
[13:49] <infinity> If highbank regressed in xenial, we should fix that.
[13:49] <pitti> (Calxeda nodes)
[13:49] <infinity> It's meant to work, so the bug is likely downstream.
[13:50] <infinity> Anyhow.
[13:50] <pitti> yeah, may just be a config issue
[13:50] <pitti> AFAIR, it doesn't boot because it doesn't find the root fs, maybe missing driver
[13:51] <infinity> None of this is your problem.  I don't care what kernels the autopkgtest machines run (well, I care for kvm ones, but for lxc runners, whatever), just making sure my hypothesis that tst-signal6 regresses on newer kernels indeed matches your data.
[13:51] <pitti> yes, I agree
[13:54] <infinity> apw: ^-- On armhf, tst-signla6 is going to flap based on which node you land on, if you grep the log for "running kernel", 3.13 should be fine, 4.4 is bust.  That's not a new regression.
[14:49] <apw> infinity, ack thanks
[14:50] <roadmr> Hello folks! Firefox 47.0 breaks Selenium, is there a way to get the immediately previous version (46.0)? on Trusty, the only other one I see is 28.0 which is too old :(
[14:51] <nacc> Skuggen: yep, it's something screwed up during the build, I'm just trying to backtrack with dbconfig where it's getting that database name from. Thanks for the tip!
[14:53] <nacc> roadmr: is there a bug filed?
[14:53] <nacc> ubuntu__: i think i mentioned this to you earlier this week; that's not really a question for this channel. Ask in #linux or find an ACPI related channel using alis
[14:54] <roadmr> nacc: not on Ubuntu, I think. There's this: https://github.com/SeleniumHQ/selenium/issues/2110
[15:19] <nacc> roadmr: ok, it may help to file a bug in LP and explain. You can see from the changelog (http://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_47.0+build3-0ubuntu0.14.04.1/changelog) that many versions have been published in trusty.
[15:20] <nacc> rbasak: ugh, this bacula bug is teaching me quite a bit about dbconfig :) ... but not making much progress
[15:22] <nacc> elbrus: oddly, in /var/log/dbconfig-common/dbc.log: "populating database via sql...  done.", but http://paste.ubuntu.com/17749799/
[15:22] <nacc> elbrus: that's the the dbconfig output with set -x enabled in the common file
[15:24] <cjwatson> roadmr: you can get older versions by manually downloading the .debs, starting from https://launchpad.net/ubuntu/+source/firefox/+publishinghistory
[15:26] <roadmr> cjwatson: awesome!!! thanks! I'm sure I can hack something to use that for my broken tests. Cheers!
[15:27] <nacc> roadmr: i would try the immediately preceding one first and then it's obviously a regression, etc.
[15:28] <roadmr> nacc: it is; Firefox 46.0 works just fine
[15:35] <nacc> roadmr: ah ok
[15:35] <nacc> rbasak: elbrus: found it: http://paste.ubuntu.com/17750447/
[15:55] <nacc> rbasak: fyi, i might need some assistance from you eventually if bacula needs actual mysql changes (they do some db upgrade stuff in the debian pacakging, and i don't think it's been updated for 5.7) (the last upgrade file mentioned in the contents is 5.2.0)
[15:56] <rbasak> Sure
[15:57] <nacc> rbasak: still trying to figure out how dbconfig generates files like '/usr/share/dbconfig-common/data/bacula-director-mysql/install/mysql'
[15:57] <nacc> ah
[15:57] <nacc>         $(foreach db,$(VARIANTS),$(shell debian/scripts/install-dbconfig $(db)))
[16:04] <nacc> i totally see why dbconfig is better for maintainers, but quite difficult to debug :)
[16:05] <doko> apw, is linux-hammerhead still a supported kernel?
[16:05] <apw> i don't think it ever was supported, that was an rsalveti job i think no ?
[16:06] <apw> rtg ^ ?
[16:28] <ogra_> cjwatson, is https://twitter.com/launchpadstatus dead (LP just told me to check it in the "Uh Oh" message)
[16:29] <cjwatson> ogra_: it's alive, but having it be updated for a random unscheduled firewall failure would rather depend on there being any Launchpad staff around for whom it's a reasonable timezone and who aren't on leave.
[16:35] <jbicha> Unit193: https://github.com/numixproject/numix-gtk-theme/issues/488
[16:36] <ogra_> cjwatson, ah, i thought it is a bot
[16:46] <semiosis> hmmm launchpad is not working.  probably due to the flood of replies to the comment I left on bug 1565985 earlier today!
[16:46] <semiosis> heh, it just started working again
[16:47] <semiosis> aww, there weren't any replies to my comment
[16:51] <infinity> semiosis: We had a datacenter spontaneously reboot.  You didn't break it. :P
[16:52] <semiosis> ouch.  good luck with that
[16:53] <elbrus> nacc: your last message is it...
[16:53]  * elbrus means http://paste.ubuntu.com/17750447/
[16:53] <nacc> elbrus: yeah, i'm trying to work through dbconfig's generator to see why that's happening
[16:53] <elbrus> nacc: dbconfig-common taks that from bacula
[16:54] <nacc> i think it's a bad variable subsittution in the bacula build
[16:54] <elbrus> nacc: I thought you figured that out yesterday while I was still on-line
[16:55] <elbrus> isn't /usr/share/dbconfig-common/data/bacula-director-mysql/install/mysql in the bacula package, no mistery there I think
[16:55] <nacc> elbrus: i'm fully new to dbconfig, so i didn't realize that; or which particular file it was
[16:55] <nacc> elbrus: now i know, and am trying to work out what's generating that file
[16:55] <elbrus> did you read the documentation?
[16:55] <elbrus> especially the design document
[16:56] <elbrus> only about 3 pages IIRC
[16:56] <nacc> elbrus: yep, after realizing this, reading that now
[16:56] <nacc> *read
[16:57] <nacc> elbrus: so bacula has this debian/scripts/install-dbconfig file; which contains the lines: extract_here("src/cats/make_".$longdb."_tables", "debian/bacula-director-$db/$DBC/bacula-director-$db/install/$db");
[16:58] <nacc> but that source file is a shell script, and it seems like it's getting parsed somehow
[16:59] <nacc> because what ends up in install/mysql is just SQL syntax
[16:59] <elbrus> what do you mean with "parsed"?
[16:59] <elbrus> during build?
[16:59] <nacc> elbrus: let me show you the contents
[17:01] <elbrus> it's not shell, it's perl
[17:02] <elbrus> see the first line
[17:02]  * elbrus doesn't read perl...
[17:02] <nacc> elbrus: http://paste.ubuntu.com/17755004/
[17:03] <nacc> elbrus: yes, install-dbconfig is perl, but not he file it's installing
[17:04] <nacc> (src/cats/make_mysql_tables)
[17:05] <elbrus> nacc: where does your /bin/sh point to?
[17:05] <nacc> elbrus: dash, the default in ubuntu, i think
[17:06] <nacc> yeah
[17:06]  * elbrus has to attent to a little girl, back in an hour or so
[17:06] <nacc> elbrus: np, thanks
[17:10] <nacc> elbrus: ah i figured it out
[17:10] <nacc> elbrus: the perl script snips out everything between the two herefile markers
[17:10] <nacc> this can't ever have worked...
[17:17] <nacc> elbrus: ah, and at some point, debian did manually sed this file
[17:29] <nacc> argggh
[17:29] <nacc> elbrus: rbasak: upstream bug, fixed in the latest upstream git
[17:29] <nacc> elbrus: also that datetime issue fixed upstream too :)
[17:36] <nemo> What's wrong with bugs.launchpad.net ?
[17:37] <sarnold> nemo: I understand a datacenter lost power
[17:38] <nemo> sarnold: huh. hosted in california or something?
[17:38] <nemo> but aight. can wait
[17:38] <sarnold> nemo: I think this one is in london
[17:43] <nemo> sarnold: huh. the power shutdowns and decent into mad max chaos weren't supposed to happen until 21:00 UTC
[17:44] <sarnold> nemo: funny thing about descents into mad chaos..
[17:59] <elbrus> nacc: great
[18:03] <Unit193> jbicha: Gotta say, not seen that one.  It only happen in MATE?
[18:05] <jbicha> Unit193: AFAIK, MATE's theme chooser is the only thing that cares about a gtk theme setting an icon theme
[18:05] <jbicha> if no icon theme is set, it won't even show up in the chooser
[18:06] <jbicha> and if an icon theme is set but that theme isn't available, it'll show up but with a warning
[18:06] <Unit193> Well, recommends are installed both in Debian and Ubuntu, so might make sense to be able to install one without the other, no?
[18:07] <nacc> Unit193: only if you use `apt`; `apt-get` doens't install recommends by default (iirc)
[18:07] <Unit193> nacc: False, both get recommends.
[18:07] <nacc> Unit193: ah you're right sorry, i chagned my local config :)
[18:08] <jbicha> I don't think it helps any thing to demote it from depends to recommends
[18:08] <Unit193> Hah, that's fine.  Only flavor that doesn't get recommends is Lubuntu.
[18:12] <Unit193> jbicha: It'd give the user the option to uninstall it if the user doesn't plan on using it, while still being able to use the GTK theme.  Was just asking as it doesn't actually require it to run, I've been using it for a while and never noticed a thing (or message.) :)
[18:12] <jbicha> so for MATE's benefit, we need to depend on some icon theme: probably numix or adwaita
[18:12] <jbicha> who uninstalls icon themes?
[18:43] <nacc> elbrus: re: zero date. Upstream bacula (as well as the version in debian/ubuntu, did this: http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=36d647345df3c98a2cc1ad24af31e73aaff4a2e9)
[18:43] <nacc> why doesn't that work?
[18:43] <nacc> is it an implicit 0 now?
[18:59] <bdmurray> coreycb: There is a version of horizion already in xenial-proposed.  Should that be verified and release first?
[18:59] <coreycb> bdmurray, the version in the queue fixes a bug found in testing of the proposed package
[19:02] <coreycb> bdmurray, that doesn't answer your question but maybe it does indirectly
[19:02] <bdmurray> coreycb: it did, thanks
[19:02] <coreycb> bdmurray, ok, thanks
[19:04] <bdmurray> coreycb: oh hrmph, the bug (1594249)  didn't have any horizon tasks so didn't get commented on
[19:07] <coreycb> bdmurray, I see a comment from you.  it may be confusion between the source package being horizon and binary package being openstack-dashboard.
[19:08] <coreycb> bdmurray, thanks for the review
[19:09] <bdmurray> coreycb: launchpad tracks bugs about source packages not binary packages
[19:09] <bdmurray> coreycb: there's nothing here https://launchpad.net/ubuntu/+source/openstack-dashboard
[19:11] <coreycb> bdmurray, that is weird, I wonder why it's valid as a target for the bug
[19:11] <coreycb> bdmurray, awesome we have a bunch of bugs here too: https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard
[19:12] <coreycb> bdmurray, alright let me retarget that
[19:12] <bdmurray> coreycb: I think it used to be a source package
[19:13] <coreycb> bdmurray, ok.  I'll chat with jamespage about it and see if we can clean things up.
[19:13] <bdmurray> https://launchpad.net/ubuntu/+source/openstack-dashboard/+publishinghistory
[19:13] <bdmurray> Oneiric!
[19:15] <coreycb> bdmurray, that's like half an alphabet ago :)
[19:22] <Unit193> ...Any chance 1562358 / 1582713 will get in through a SRU, or should I just try and backport it?
[19:22] <krytarik> jbicha: Honestly, I'd just follow what the Debian policy lays out there: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
[19:32] <jbicha> krytarik: since recommends are not always installed and since it's broken on MATE if the icon theme isn't installed, I believe a depends is the right choice
[19:32] <seb128> jbicha, what package/what sort of breakage?
[19:33] <jbicha> seb128: https://github.com/numixproject/numix-gtk-theme/issues/488
[19:33] <jbicha> I'm just having numix-gtk-theme depend on numix-icon-theme
[19:34] <seb128> that feels wrong
[19:34] <jbicha> I could set IconTheme=Adwaita and depend on adwaita-icon-theme instead
[19:34] <seb128> well, a gtk theme doesn't depends on icons
[19:35] <seb128> recommends seems about righ
[19:35] <seb128> right
[19:35] <Unit193> Thanks, seb.
[19:35] <jbicha> they used to, MATE has a lot of old tech
[19:35] <roadmr> hey folks, where can I learn more about the process a package needs to go through to make it out of https://launchpad.net/ubuntu/xenial/+queue and into the archive?
[19:37] <jbicha> apt depends light-themes
[19:37] <jbicha> apt depends mate-themes
[19:37] <nacc> roadmr: https://wiki.ubuntu.com/ProposedMigration ?
[19:38] <seb128> jbicha, if you had numix-theme I would say add the depends
[19:38] <roadmr> nacc: awesome! reading, thanks!
[19:38] <seb128> but you have -gtk-theme
[19:38] <jbicha> but it's broken in MATE, did you see the screenshot?
[19:38] <nacc> roadmr: np, it links to several other pages, etc
[19:39] <seb128> jbicha, broken like missing from the theme selector?
[19:39] <seb128> or like not working if selected in a manual config?
[19:40] <Unit193> Sounds like a but in MATE to me.
[19:40] <jbicha> it looks bad in the theme selector
[19:40] <seb128> well, the theme selector is only one UI
[19:40] <seb128> if the gtk theme runtime is fine when manually selected then it's not a depends
[19:40] <seb128> recommends as "should be there"
[19:40] <seb128> are*
[19:42] <jbicha> ok, how about I just change IconTheme to Adwaita and not depend or recommend on any icon theme
[19:43] <jbicha> GTK3 depends on adwaita-icon-theme so it won't be broken
[19:43] <seb128> wfm
[19:45] <krytarik> jbicha: Well, you can still leave it set like that - Greybird does that too, for example.
[19:48] <jbicha> krytarik: that's a bug for MATE users then, I recommend it be patched in Ubuntu
[19:54] <elbrus> nacc: I don't know those internals of MySQL, but I guess you'll have to set a different default then?
[19:55] <nacc> elbrus: yeah, i'm not sure; your cacti change did work, so maybe i'll just do that, but it seems like it shouldn't have complained at all (aiui). I'll ask rbasak  :)
[19:57] <nacc> elbrus: reading the mysql pages about this, i think we just do what you did with cactui
[19:57] <nacc> *cacti
[20:36] <krytarik> jbicha: I see no reason to make a difference between Debian and Ubuntu there.
[20:37] <ubuntu__> Does anybody know where this driver is located 0 inteldrmfb its for /dev/fb0  cann't find it under lsmod so not a module and cann't find it in kallsyms so doesn't look like its a built in kernel function so where the heck is this driving program for the framebuffer?
[20:37] <nacc> ubuntu__: you've been doing this for days now. Please stop asking non-Ubuntu development questiosn here.
[20:38] <nacc> ubuntu__: ask in #ubuntu or #linux
[20:38] <Unit193> (##linux)
[20:38] <nacc> Unit193: thanks! :)
[20:38] <Unit193> Sure thing!
[20:48] <jbicha> krytarik: sure, Greybird should be packaged for Debian too (in Ubuntu, it's in shimmer-themes currently) :)
[20:49] <Unit193> In Ubuntu it's in the src:shimmer-themes and pkg:greybird-gtk-theme, in Debian it's in src/pkg:murrine-themes...
[20:51] <jbicha> Unit193: cool, thanks for the pointer
[20:52] <Unit193> jbicha: Sure, it's certainly not ideal, and I wouldn't recommend it in Debian as the last update was in June, and since then 3.20 has come out.  You have seen the Fedora patch that fixes Greybird for .20 I believe, though.  Done much testing on it?
[20:56] <jbicha> no I haven't tried the greybird patch yet
[20:58] <Unit193> Ah, OK.  Testing feedback could likely be useful if you were inclined, but that's more GNOME's stuff.
[21:05] <krytarik> jbicha: To be clear, I'm referring to your 'Numix → Adwaita' icon theme change in Debian and back in Ubuntu - imo should be Numix in both.
[21:08] <ubuntu__> well think i figured out what /proc/fb  comes from this line in kernel code  strcpy(info->fix.id, "inteldrmfb");
[21:09] <ubuntu__> all leave it at that kind of a dump thing to but into inteldrmfb how does that string help anything in finding the driver and code its not any name corrosponding to anything
[21:09] <jbicha> krytarik: I changed numix-gtk-theme in Debian new to just use Adwaita by default (for MATE) and not depend on any icon theme
[21:09] <jbicha> and it'll be synced to Ubuntu
[21:10] <ikonia> ubuntu__: you've been told - this channel is not for this discussion
[21:10] <ikonia> ubuntu__: please do not start up in here after you've been told not to use this channel
[21:10] <ubuntu__> but i will leave it at that i have found the built in driver code so its not an LKM  so lsmod won't list it  kallsyms has it but as   intelfb_create the real name for it . And this is where i stop thanks  goodbye
[21:22] <nacc> rbasak: elbrus: alright, bacula-director-mysql does install now (my last test build), but does require mysql-server to be fully installed & configured first (ordering isn't working if installed as part of the bacula install)
[21:22] <nacc> rbasak: should we pre-depend on mysql-server?
[21:22] <nacc> rbasak: in the bacula pacakge, that is
[21:27] <elbrus> nacc: the issue with MySQL (and other databases) is that it may not be running on the same host
[21:28] <elbrus> so if you add a (pre) depends, you are annoying admins that don't want the MySQL server on the same host
[21:28] <nacc> elbrus: oh right, you mentieond this, sorry!
[21:28] <nacc> elbrus: yep, and i think that's why the ubuntu wiki specifically mentions having the sql server alrady configured
[21:28] <elbrus> that is why in general packages that need MySQL have dependecies on the client, but not on the server
[21:28] <nacc> right, makes sense
[21:29] <nacc> elbrus: well, i think bacula with these 3 changes is in a much better state; continuing to debug the remaining bugs
[21:31] <elbrus> unfortunately, the Debian dependency system does not facilitate this
[21:31] <nacc> elbrus: yep, understood (or learning to understand.. :)
[21:31] <elbrus> one of the reasons why dbconfig-common exists...
[21:31] <elbrus> to make sure that packages don't need to invent this all
[21:31] <elbrus> again and again
[21:31] <elbrus> it isn't easy
[21:32] <nacc> yep, i am learning that! :)
[21:32] <elbrus> also dbconfig-common doesn't get it all correct
[21:32]  * elbrus tries to still fix some difficult bugs before the next Debian release
[21:34] <nacc> elbrus: thanks for all your help, again!
[21:35]  * elbrus is off to bed...
[23:12] <nacc> Pharaoh_Atem: can you take a look at LP: #1571436 ?
[23:12] <nacc> teward: --^ maybe you too
[23:14] <teward> nacc: that's a Universe package right?
[23:14] <teward> !info wordpress xenial
[23:14] <nacc> teward: yeah :)
[23:14] <nacc> teward: feel free to say no :)
[23:14] <teward> take a torch to it
[23:15] <teward> and burn the package with flame
[23:15] <teward> 4.4.2 is ancient
[23:15] <teward> at least according to WP
[23:15] <teward> riddled with many security holes
[23:15] <teward> 4.5.3 is latest
[23:15] <teward> and between 4.4.2 and 4.5.0 i think there were six security patch updates?
[23:15] <teward> foo i broke my fileshares
[23:16] <teward> nacc: probably an easy fix... if someone goes and looks at the example php-fpm configs in the nginx package currently
[23:16] <teward> or my blog for that matter
[23:16] <nacc> teward: yes, well, i'll probably sync it for yakkety
[23:16] <teward> nacc: http://dark-net.net/?p=125
[23:16] <nacc> teward: but our goal should be working packages, even if they are out of date (or so it seems)
[23:16] <nacc> teward: thanks, i'll refer to it
[23:17] <teward> nacc: true, but i'm not going to go poking every php package that happens to break OOTB when nginx isn't even listed in rdepends
[23:17] <teward> (for either suggest or recommends)
[23:17] <teward> nacc: fastcgi_pass unix:/run/php/php7.0-fpm.sock;  <-- socket for the conf file
[23:17] <nacc> teward: ack, hence you can say no :)
[23:20] <teward> nacc: i'm not touching it
[23:20] <teward> :P
[23:23] <teward> Pharaoh_Atem: ^ if you want to, you can refer to the nginx default conf currently, or the blog post I linked (http://dark-net.net/?p=125), it's the migration that broke it :)
[23:23] <teward> (from 5.x -> 7.0)