[00:14] <capum321> nacc sorry , i am back
[00:14] <capum321> nacc what do you mean by that?
[00:17] <nacc> capum321: you're rebuilding the existing binary package w/o modifications?
[00:18] <capum321> yes
[00:18] <capum321> i just downloaded it from the launchpad site
[00:18] <nacc> capum321: can i ask why you're rebuilding it? why not just it as a dependency?
[00:19] <capum321> because of this http://www.monodevelop.com/developers/building-monodevelop/#linux
[00:19] <nacc> capum321: that's a long page, can you just explain?
[00:20] <capum321> it is a dependency for building monodevelop
[00:20] <nacc> capum321: it says it needs mono.addins 0.6; ubuntu is at 1.0?
[00:21] <nacc> capum321: and even so, what would rebuilding get you?
[00:21] <capum321> yes you are right
[00:21] <capum321> to install latest monodevelop
[00:22] <nacc> capum321: no, you misunderstand; you've got 1.0+git20130406.adcd75b-4; rebuilding the same from the source package will just get you 1.0+git20130406.adcd75b-4. So just use the existing binary package as the dep
[00:24] <capum321> I don't think I am aware of how to do this? do you mean using the tar.gz file as dependency?
[00:29] <nacc> capum321: i mean, just install the package (mono-addins-utils or whatever)
[00:29] <nacc> capum321: as that page says, use the distribution packages wherever possible
[00:32] <capum321> libmono-addins-cil-dev    libmono-addins-gui-cil-dev    libmono-addins-gui0.2-cil    libmono-addins-msbuild-cil-dev    libmono-addins-msbuild0.2-cil    libmono-addins0.2-cil    mono-addins-utils
[00:32] <capum321> these?]
[00:32] <capum321> install one by one you mean?
[00:33] <capum321> the parental package mono-addins doesn't have a .deb. one should build it. is that it?
[00:34] <capum321> not sure if I am following you correctly
[00:34] <nacc> capum321: no, i think you're confusing source packages and binary packages
[00:35] <nacc> capum321: mono-addins (the debian/ubuntu package) is just a source package
[00:35] <capum321> yes
[00:35] <nacc> capum321: it's what is used to build binary packages
[00:35] <capum321> ok
[00:35] <nacc> capum321: but you are running ubuntu/debian, so just install the binary pacakges
[00:36] <capum321> there are no binary packages since i have to build them at first place?
[00:36] <nacc> capum321: i mean, you *can* build the source package yourself, but the result is exactly what is provided by debian/ubuntu; so why would you?
[00:36] <nacc> capum321: what?
[00:36] <capum321> look inside the file
[00:36] <nacc> capum321: no, the src:mono-addins package makes several binary pacakges, as you said
[00:36] <capum321> there are no binaries
[00:36] <nacc> capum321: that's not how source pacakges work
[00:38] <capum321> oh i think i have understand
[00:38] <nacc> capum321: in this case, src:mono-addins makes 7 binary packages: libmono-addins-cil-dev, libmono-addins-gui-cil-dev, libmono-addins-gui0.2-cil, libmono-addins-msbuild-cil-dev, libmono-addins-msbuild0.2-cil, libmono-addins0.2-cil, mono-addins-utils
[00:39] <capum321> continue
[00:39] <nacc> those 7 packages are available from Ubuntu, you don't build them yourself, unless you have need of a modification or something
[00:39] <nacc> capum321: afaict, you don't need to modify mono-addins per that page, you just need to install those packages (i don't know precisely which ones)
[00:39] <capum321> so i should install them one by one as i said
[00:40] <capum321> you're saying
[00:41] <capum321> no?
[00:45] <nacc> capum321: i mean, you can just install them all at once, i guess
[00:45] <capum321> off course
[00:45] <capum321> all in one line
[00:45] <capum321> like apt-get install libmono-addins-cil-dev libmono-addins-gui-cil-dev libmono-addins-gui0.2-cil libmono-addins-msbuild-cil-dev libmono-addins-msbuild0.2-cil libmono-addins0.2-cil mono-addins-utils
[00:45] <nacc> capum321: yes, but i genuinely don't know which of those you actually need
[00:46] <capum321> let me check
[00:46] <capum321> is there a ppa I could use to install simply mono-addins using this launchpad repo?
[00:46] <capum321> to makes simpler things
[00:46] <nacc> capum321: what?
[00:47] <nacc> capum321: mono-addins is *not* a binary package name
[00:47] <capum321> i see
[00:47] <capum321> not natively
[00:48] <nacc> capum321: what? what do you mean "natively"?
[00:48] <capum321> native... you should buid the source i you want the bin?
[00:51] <nacc> capum321: no
[00:51] <nacc> capum321: you never need to build a source package unless you're doing some Ubuntu development
[00:51] <nacc> (maybe too general, but good enough for now)
[00:51] <nacc> capum321: the binary packages mentioned already contain the binaries built from building src:mono-addins
[00:52] <capum321> i see
[00:52] <capum321> i move on. now installing cmake
[00:52] <nacc> capum321: a major point of a distribution (well, other than gentoo) is so you, as the user, don't have to build stuff yourself, IMO
[00:53] <nacc> capum321: you should not have any need for source packages if you're just trying to build some random sourcecode
[00:55] <capum321> not sure if I get this... how would you build something if you don't have it?
[00:56] <nacc> capum321: have you used ubuntu before?
[00:56] <capum321> source packages are full of binary packages
[00:56] <capum321> is that it?
[00:57] <nacc> capum321: when you `apt-get install <pkgname>` do you build it?
[00:57] <nacc> capum321: source packages are full of *descriptions* of how to build binary packages
[00:57] <nacc> capum321: source packages are just that, source
[00:58] <capum321> no you don't build like that; debuild builds it
[01:00] <nacc> capum321: so you're saying you've built every package for your ubuntu yourself? no, you use the archives that contain binary packages.
[01:01] <nacc> capum321: that page you linked to said use Mono.Addins 0.6, which has been package for Ubuntu since 12.04; so what made you think you need to build that yourself? is it because of the name?
[01:02] <capum321> actually would be compile a better word?
[01:03] <nacc> capum321: build, compile, it's the same -- you don't do that for any other package, I don't think
[01:03] <nacc> capum321: let's say some website said "please make sure you have libc development files installed", would you go get the libc source package and build it yourself? No, you'd `apt-get install libc6-dev`. Why is this any different?
[01:03] <nacc> capum321: you're not building the dependencies, you're building monodevelop itself, afaict
[01:05] <capum321> yes, i guess because i read on monodevelop page, i should have thought was the same for its dependency, in particular mono-addins, which was on a deb.tar.gz format with bunch of files in it
[01:07] <capum321> yeah but I can't do that with `apt-get install mono-addins` because i thought it would install as a usual package likewise
[01:08] <nacc> capum321: i don't know what file you're referring to (deb.tar.gz format), that sounds like something to ask mono about (not #ubuntu-devel).
[01:08] <nacc> capum321: that's because mono-addins is a *source* package, as I just spent some time explaining
[01:08] <nacc> capum321: "Mono.Addins" is the upstream project name, it has no relation, in and of itself, to the binary package names that you need
[01:09] <capum321> yes, it is getting clearer
[01:10] <nacc> capum321: but in the end, this whole long conversation has nothing to do with Ubuntu development; I would suggestion asking future questions in #ubuntu
[01:10] <capum321> deb.tar.gz is on of the four files that trusty supports
[01:13] <capum321> just a fun fact i spent the whole afternoon trying to solve this in unimagenable channels. including ubuntu, there people who were quiet start to tell me i should use auto-completions plugin + some editor and change to windoze and the hell came up
[01:15] <nacc> capum321: i don't parse that first sentence, but ok.
[01:17] <capum321> where should i seek assitance for installing libssh2? is it $ apt-cache search libssh = libssh-4 - tiny C SSH library
[01:18] <teward> capum321: #ubuntu is the support channel
[05:57] <cpaelzer> good morning
[06:57] <ubuntu__> Only thing i would imagine that would cause problems in manual extracting the kernel headers from the kernel to the /usr/src directories is either the folder structure is a little different or  you miss uses the wrong versions
[06:57] <ubuntu__> Other then that the includes should be exactly identical
[07:13] <pitti> Good morning
[07:18] <ubuntu__> linux kernel headers are only useful for LKM creation thats all i can see them for. having to install different versions of them for different LKM versions thats about it... because the headers are also self contained in the linux kernel as well
[07:33] <dholbach> jbicha, nice one!
[08:46] <cpaelzer> I have a .service file of clamav and wonder why it isn't startign anymore on newer releases
[08:46] <cpaelzer> the service files are bit identical throughout the releases, but obiously systemd is newer
[08:46] <cpaelzer> things work on jessie, but fail on xenial, yakkety, sid
[08:47] <pitti> cpaelzer: what does "sudo systemctl status clamav" say?
[08:47] <cpaelzer> on the newer systems it comes as "inactive (dead)" after being installed
[08:47] <pitti> so it either died or wasn't started at all -> systemctl status please
[08:48] <cpaelzer> ... need to convince pastebinit ...
[08:50] <cpaelzer> it hates the utf chars in systemd's output
[08:50] <pitti> uh? not here
[08:50] <pitti> http://paste.ubuntu.com/17686364/
[08:50] <cpaelzer> might be a missing dependency in my container
[08:50] <cpaelzer> I'll push it through an editor to get on for now
[08:50] <pitti> wrong locale perhaps?
[08:51] <pitti> copy&paste into http://paste.ubuntu.com :)
[08:53] <cpaelzer> sid (broken) http://paste.ubuntu.com/17686435/ and jessie (working) http://paste.ubuntu.com/17686449/
[08:53] <cpaelzer> all the log content in the sid case is from former start/stop/install/uninstalls
[08:54] <cpaelzer> at first it had no entries at all in the broken case
[08:54] <cpaelzer> a simple "systemctl start clamav-freshclam.service" gets things working fine - so it is not broken config or so
[08:55] <cpaelzer> thereby (working when stared manually and no log) I'd expect it never got started
[08:55] <cpaelzer> Test is as easy as "apt-get install clamav-freshclam; systemctl status clamav-freshclam.service" on anything recent
[09:04] <cpaelzer> pitti: are there any other obvious next levels of debugging that could help - like attaching to something like a systemd monitor of event or any logs ?
[09:04] <pitti> cpaelzer: is that service actually enabled? in your pastebin it was started and stopped
[09:05] <cpaelzer> pitti: Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; vendor preset: enabled)
[09:05] <cpaelzer> the starts were manual ones where I checked if it would start (it did) and stops are from uninstalling the package
[09:06] <pitti> cpaelzer: for me it doesn't start right after package install, but it does start after a reboot
[09:07] <cpaelzer> pitti: yeah, exactly - why doesn't it after install is more or less my question?
[09:07] <pitti> supposedly some breakage in the postinst
[09:07] <cpaelzer> pitti: ok I'll check for diffs if you assume it is there
[09:07] <pitti> it apperantly only calls dh_systemd_enable, but not dh_installinit or dh_systemd_start
[09:08] <pitti> instead it does some really complicated manual code dance
[09:08] <cpaelzer> pitti: I'd have expected the systemd version change as the service file was bit-identical
[09:08] <pitti> but it calls invoke-rc.d *before* enabling the unit
[09:08] <pitti> so this stuff needs to move after #DEBHELPER#
[09:08] <pitti> cpaelzer: probably more likely to be a side effect of an invoke-rc.d fix
[09:09] <cpaelzer> pitti: I wonder if it wasn't broken back in the jessie version - I'll look into that - thanks a lot for the pointer
[09:09] <pitti> it must be enabled first, then started
[09:09] <pitti> invoke-rc.d does not start disabled stuff
[09:09] <pitti> maybe it did in earlier versions
[09:35] <blut> where can i find the busybox configuration of the 16.04 netboot image?
[09:36] <blut> or maybe, where would be the right place to ask this question?
[09:44] <cjwatson> blut: It's in the busybox source package in 16.04; debian/config/pkg/udeb
[09:46] <blut> thank you
[10:01] <xnox> caribou, hey about https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1583563 why did you steal assignment for it for xenial?
[10:02] <xnox> is https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=multipath not enough?
[10:05] <juliank> thanks pitti
[10:11] <pitti> juliank: thanks to you, good luck!
[10:14] <rbasak> cpaelzer: I thought it wasn't starting because of the condition - because freshclam hasn't run?
[10:14] <rbasak> That's just from memory though I didn't look much deeper.
[10:15] <cpaelzer> rbasak: it is a bit more complex
[10:15] <cpaelzer> rbasak: I updated the bug if you want to read into the full analysis
[10:16] <cpaelzer> rbasak: TL;DR - we discussed the "freshclam doesn't start" part here - but there is also an "daemon should start after install, but only once db is ready" part
[10:16] <cpaelzer> rbasak: the first is an actual regression - the second always was that way, yet I came up with suggestions that I'll present to the debian maintainer
[10:20] <rbasak> cpaelzer: sounds like you're on top of it. Thanks :)
[10:22] <rbasak> cpaelzer: meet ScottK. He used to look after clamav in Ubuntu.
[10:22] <rbasak> ScottK: this is bug 1590688, which AFAICT affects sid also.
[10:22] <cpaelzer> hi ScottK - I'm currently wrapping things up for a proper Debian bug - but I'm gonna test my suggestion first :-)
[10:24] <flexiondotorg> pitti, I was just asked if there is any intention to change the default systemd timeout from 90s on shutdown in 16.04.1?
[10:24] <pitti> flexiondotorg: no, this isn't planned
[10:24] <flexiondotorg> ty
[10:24] <pitti> this doesn't appear like a safe change for an SRU
[10:25] <pitti> some stuff like mysql or whatnot might actually need a lot of time during shutdown
[10:25] <pitti> i. e. *after* we went through services which legitimately need a long shutdown time and add stop timeouts to their *.services, then we can think about lowering the global limit
[10:26] <pitti> we already got burned with imposing default nproc limits and KillProcesses=, not gonna do this exercise in stable :)
[10:51] <caribou> xnox: 'cause I'm about to SRU another Xenial fix so I thought I'd do them both
[10:51] <caribou> xnox: got discussed during the server team meeting yesterday & then I bailed out for the day & just came back so didn't have time to ping you about it
[10:52] <xnox> caribou, right, if you trump my sru with more fixes, pull mine package from -proposed, add your things on top, and use proper -v to include all changelog entries since xenial-release.
[10:52] <xnox> caribou, or maybe just ship these. What are the other bug #s to SRU?
[10:53] <xnox> are they as urgent as multipath-tools are utterly borken?
[10:54] <caribou> xnox: broken to the point where, with LVM2 devices will be claimed by LVM before multipath gets them
[10:58] <caribou> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817940 was fixed in debian but for some reason the Xenial package has the wrong fix
[11:00] <caribou> xnox: opening a bug for this atm
[11:02] <caribou> xnox: lp: #817940
[11:06] <caribou> meh: lp: #1595141
[11:21] <xnox> caribou, my SRU fixes not linked to libsystemd.
[11:23] <xnox> caribou, # ldd /sbin/multipathd  | grep systemd
[11:23] <xnox> 	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fc6df0e1000)
[11:23] <xnox> caribou, can you retest the lvm bug in yakkety?
[11:23] <xnox> the not linked to libsystemd is what is causing the 3 bugs mentioned in the changelog, and this lvm thing too.
[11:23] <caribou> xnox: yakkety has the correct target
[11:23] <xnox> caribou, and that's included in my sru.
[11:24] <xnox> caribou, so that pending sru should cover everything, no?
[11:24] <xnox> caribou, please check http://launchpadlibrarian.net/266780737/multipath-tools_0.5.0+git1.656f8865-5ubuntu2_0.5.0+git1.656f8865-5ubuntu2.1.diff.gz
[11:24] <caribou> xnox: yep,
[11:25] <caribou> xnox: just did a debdiff on xenial .vs. yakkety & your SRU brings in the fix
[11:26] <caribou> xnox: ok, I duped my bug on yours
[11:30] <xnox> pitti, could you please partially release https://bugs.launchpad.net/ubuntu/+source/gcc-5-cross/+bug/1572613/comments/64 ?
[11:30] <xnox> pitti, just the packages mentioned in that comment that have non-regressed autopkgtests?
[11:30] <pitti> xnox: yes, will do; thanks
[11:32] <pitti> xnox: done
[11:39] <ouroumov> Hi. pitti, you've got a sec to talk about https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1457400 ? - Specifically, do you know if there is movement on the subject of changing the default timeout for Desktop Ubuntu?
[11:42] <pitti> ouroumov: see backscroll from an hour ago, flexiondotorg already pinged above
[11:43] <ouroumov> ok
[11:43] <pitti> pitti | this doesn't appear like a safe change for an SRU; some stuff like mysql or whatnot might actually need a lot of time during shutdown
[11:43] <pitti> pitti | i. e. *after* we went through services which legitimately need a long shutdown time and add stop timeouts to their *.services, then we can think about lowering the global limit
[11:46] <cpaelzer> IRC deja-vu
[11:47] <ouroumov> Thanks pitti.
[12:05] <juliank> mvo: What do you think about moving my application from PPU to CoreDev? xnox and pitti seem to be excited about that
[12:09] <Laney> I'm sure it can gracefully fall back to PPU if the DMB doesn't like the core-dev bit
[12:09] <mvo> juliank: +1 for core-dev
[12:09] <caribou> xnox: btw, I didn't *steal* your assignment, it was unassigned when I took it : "assignee:	nobody → Louis Bouchard (louis-bouchard)"
[12:10] <caribou> :)
[12:11] <mvo> arges: is there anything I can do to help move #1590434 foward? its a new build-dep in snapd and it would be great to see this landing as its currently blocking some people in the team from moving there code forward. should be no risk as its a) just source b) nothing uses it yet. but if there is anything missing or anything I can do please let me know
[12:15] <juliank> OK, I moved the application to https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-CoreDev
[12:25] <mapreri> pitti: is 'dh_installchangelogs: Do not install upstream changelog in compat level 7.  This floods packages with huge upstream changelogs which take precious CD space.' actually still a problem?  did anybody tried to see what happens without that patch?
[12:26] <mapreri> I don't think it would make stuff much bigger…
[12:35] <juliank> xnox: OK, it's official now, I sent out a core-dev application!
[12:37] <juliank> Someone really should fix https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda, the next meeting most definitely is not on "Monday June 20th, 2016 19:00 UTC"
[12:37] <juliank> that was two days ago
[12:38] <xnox> mapreri, full debian/changelog, when gzip compressed is 193k, and things from 1994 are entirely pointless.
[12:38] <rbasak> juliank: go ahead and add it to the agenda with a date. Then you'll be first in line.
[12:39] <xnox> mapreri, throw in everything in minimal and one has more than a meg of useless stuff.
[12:39] <rbasak> juliank: https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda?action=recall&rev=565 is an example of what it usually looks like when there are applicants lined up.
[12:39] <rbasak> We appear to have none right now.
[12:40] <rbasak> micahg: ^
[12:41] <juliank> rbasak: OK, added
[12:42] <rbasak> Thanks!
[12:42] <mapreri> xnox: we're talking about *upstream* changelog, which not everything has them, and they tends to be a little smaller than d/changelog from my experience.  and even if we get like 2/3 MB more I think we can live with that.  I agree they are useless for ~everybody, though, but it's a delta less from debian.
[12:43] <juliank> rbasak: Do I now have to monitor that page to find out when the meeting is?
[12:44] <juliank> or should that be 4th of July at 19:00 UTC?
[12:44] <rbasak> juliank: sorry, I didn't explain this properly. The date in your entry in the agenda should be the date of the meeting you want to attend, not the date you entered the entry.
[12:44] <rbasak> Right
[12:44] <juliank> OK
[12:44] <juliank> I'll just reformat my entry as well and make my name link to my application
[12:45] <rbasak> juliank: the meeting on 4 July will be at 1430 UTC according to my calendar unless I'm mistaken.
[12:45] <rbasak> Uh, 1500.
[12:45] <juliank> rbasak: OK, I'm at DebCamp anyway, so I can manage any time
[12:46] <juliank> s/Camp/Conf/
[12:46] <rbasak> I have my calendar entry include 30 minutes to remember to show up and read applications, etc.
[12:46] <rbasak> http://fridge.ubuntu.com/calendars/fridge/ seems to have duplicates but I think it is correct.
[12:47] <juliank> Wonderful.
[12:49] <xnox> mapreri, pretty sure those are huge and utterly useless.
[12:49] <xnox> too
[12:49] <xnox> we did ignore/reduce both. e.g. limit number of entries and/or not have them at all.
[12:49] <xnox> mapreri, no, we cannot live with 2/3MB more.
[12:49] <rbasak> I added future meeting dates to the agenda.
[12:50] <xnox> mapreri, that's huge increase for containers and snappy, target there is about 40MB
[12:50] <rbasak> I remember it being a pain when I applied to the DMB in the past to find the dates of the meetings. We should keep the upcoming meeting dates updated in the agenda.
[12:50] <rbasak> micahg: ^
[13:15] <juliank> Laney: The date parsing issue is now fixed in apt 1.3~exp3, should be syncable in half a day or something
[13:15] <juliank> (just uploaded it to Debian)
[13:16] <juliank> SRU for 1.2.14 is also prepared in bug 1595177, I'm just waiting a day or two before turning that bug live
[13:22] <juliank> Note that 1.3~exp3 now allows you to use weak repositories with the correct setting for your source
[13:22] <juliank> We might be able to backport that to 1.2 for next year for the SHA1 kill release, once we have a sensible amount of translations
[13:23] <juliank> but not entirely sure
[13:32] <caribou> question to SRU team members : I got two regression bugs for the libapache2-mpm-itk SRU (LP: #1286882) on trusty, both caused by the same issue
[13:33] <caribou> a bug in a2query + misconfiguration of the apache2 server
[13:33] <coreycb> arges, good morning, if you have a moment can you review our xenial horizon sru?  it's a hot one for bug 1594249
[13:34] <caribou> is there a way we can unblock this SRU which is blocking another apache SRU (LP: #1286882)
[13:34] <caribou> coreycb: I thinkg that arges is off this week
[13:34] <coreycb> caribou, ah thanks!
[13:35] <coreycb> bdmurray, would you be able to look review that? ^
[14:21] <elopio> pitti: hello! I'm having a problem with autopkgtests and the proxy. Do you have a minute?
[14:22] <pitti> hey elopio, what's up?
[14:22] <elopio> pitti: pass -e http_proxy, https_proxy and no_proxy, but it fails when during the package build the network is accessed.
[14:22] <elopio> like: http://paste.ubuntu.com/17698405/
[14:22] <elopio> *I pass.
[14:23] <pitti> elopio: do you actually have localhost in $no_proxy?
[14:23] <elopio> pitti: yes, this is the call: http://paste.ubuntu.com/17698490/
[14:24] <elopio> notice that the error is during the package build. Everything that accesses the network during the test execution gets the environment variables alright.
[14:24] <pitti> elopio: oh, package build -- that might not actually get proxy vars
[14:24] <elopio> so I'm guessing that the package is build before the -e is set. And I don't know how to set up the proxy earlier.
[14:24] <pitti> you sholdn't need to
[14:24] <pitti> a package build should not have proxy vars
[14:25] <pitti> elopio: if you don't specify -e, does the package build?
[14:26] <pitti> elopio: so I guess your problem is rather the inverse -- proxy vars *are* already set during package build
[14:26] <pitti> as using the nova setup scirpt for this does that for *all* commands
[14:26] <pitti> elopio: so something in your test isn't respecting $no_proxy
[14:26] <pitti> (test during package build, I mean)
[14:28] <elopio> pitti: ah, I think I understand what you are saying. If the package build doesn't get the http_proxy, then it shouldn't fail when accessing localhost.
[14:28] <elopio> hum, let me try without -e.
[14:28] <pitti> elopio: I think ssh runner's -e is a bit ill-conceived
[14:28] <pitti> at least for using proxies
[14:30] <pitti> rbasak: in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804992#15 you said that you already dropped the initscripts dep from mysql-server-5.7 in your git
[14:30] <elopio> it gets weirder because we have another branch failing trying to access pypi, which has a proxy exception. So for some reason it doesn't respect no_proxy, but also doesn't work with the http_proxy. :/
[14:30] <elopio> anyway, I'll collect more data points.
[14:31] <pitti> rbasak: however, it's still there in https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/tree/debian/control
[14:31] <pitti> rbasak: is that still just not pushed, or in some branch?
[14:32] <pitti> rbasak: background: I'm currently mopping up the last few stragglers on https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintainers@lists.alioth.debian.org;dist=unstable;tag=initscripts-dep
[14:33] <pitti> rbasak: the other 5 look simple enough, but I suppose I shouldn't just upload mysql-5.7 for this to not disrupt your vcs etc.
[14:37] <rbasak> pitti: sorry I hadn't pushed that yet. There are so many loose ends for mysql right now I'm focusing on only a few at a time. No need to block on that now though, so I've just pushed it to Debian VCS in the 5.7 branch.
[14:37] <rbasak> pitti: I need to prepare an upload to Debian experimental next, and I'll be able to sync that into Yakkety (Ubuntu is almost exactly the same as the Debian 5.7 VCS branch already)
[14:37] <pitti> rbasak: nice, thanks
[14:38]  * pitti updates the Debian bug accordingly
[14:38] <rbasak> Oh, not a sync, but a really trivial merge, to drop a universe dependency.
[14:38] <pitti> rbasak: you might want to use substvars and drop it for an ubuntu build, to keep the packages in sync?
[14:39] <rbasak> pitti: yeah, I need to look into that.
[14:39] <rbasak> It's a build dep, but they're allowed now :)
[14:39] <rbasak> So I think I can just conditionally compile without support, but have the build dep present all the time.
[14:40] <pitti> rbasak: ah yes, and conditionally add a --disable-foo?
[14:40] <rbasak> Yes. Also it's a plugin, so I may be able to have a binary that ships universe dependency plugins in universe. I'm not sure how to do that in a unified way with Debian without it getting ugly though, because Debian shouldn't really have a separate binary package for that.
[14:42] <pitti> yeah, that's much harder, this probably warrants a delta then
[14:42] <pitti> still doable with some conditional -N magic, but still "eww"
[14:42] <rbasak> That's sort of why I haven't got round to it yet (yet another loose end). Thank you for confirming that I'm not missing something :)
[14:44] <pitti> rbasak: so I guess the simpler thing would be to just conditionally --disable it, and then ponder how to make this thing available in Ubuntu as step 2
[14:47] <bdmurray> coreycb: I'm out today but will look tomorrow
[14:48] <coreycb> bdmurray, ok thankx
[14:48] <coreycb> thanks
[14:57] <Laney> juliank: cool beans
[15:12] <blut> !mir
[15:59] <nacc> rbasak: hey, i was looking at a bug you had fixed/worked for mysql +dbconfig-common, re: empty port values. I saw it was fix released for mysql, but bacula still fails to configure bacula-directory-mysql; is that because dbconfig-common hasn't been fixed yet?
[16:01] <nacc> rbasak: LP: #1563274
[16:01] <rbasak> nacc: the "fix" for MySQL was to allow empty port values again, but they'll be dropped again in 5.8. But it does emit a warning. I've seen dbconfig-common failures but I'm not sure if that's because of the warning or because of some other problem.
[16:02] <rbasak> The other day I was debugging a pdns dep8 failure which seem to be related to dbconfig-common and postinst ordering.
[16:02] <rbasak> But the problem went away by itself (non-deterministic)
[16:02] <nacc> rbasak: i think it's that any warning gets emitted
[16:02] <nacc> rbasak: http://paste.ubuntu.com/17702876/
[16:03] <rbasak> elbrus may be able to help.
[16:03] <rbasak> That's actually a warning followed by an error.
[16:03] <rbasak> It seems to me that the error (can't connect to socket) is unrelated.
[16:03] <rbasak> nacc: try experimenting with the ordering of installation of mysql-server, the dbconfig packages, and bacula.
[16:04] <rbasak> Just a hunch.
[16:04] <nacc> rbasak: yeah, that might be because it got into a bad state the first time
[16:11] <nacc> rbasak: this is a relatively important bug, no? bacula consistenly fails to install because of it (and requires manual intervention)
[16:12] <brendand> has anyone seen this when using autopkgtest-buildvm-ubuntu-cloud: 'qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory'
[16:12] <brendand> this is being run inside a kvm instance
[16:12] <nacc> brendand: are you out of memory on your host? :)
[16:12] <nacc> brendand: nested kvm?
[16:15] <brendand> nacc, i suppose I *could* be, but I do have 16GB
[16:15] <brendand> nacc, nested, yeah
[16:18] <brendand> i suppose i really don't need to do this inside the vm anyway
[16:20] <rbasak> nacc: yes, it is.
[16:24] <nacc> brendand: right, but does your guest have 16GB assigned to it?
[16:24] <nacc> brendand: meaning, does your nested host have sufficient memory?
[16:25] <brendand> good point. i just used a default, so probably only 1GB
[16:25] <brendand> i'll change that and try again
[16:25] <nacc> brendand: yep, that'd be the issue, i'm guessing -- so the second level guest was ENOMEM'ing, as expected :)
[16:25] <brendand> 500M, heh
[16:28] <nacc> rbasak: could i put a default value for dbport in /etc/dbconfig-common/config to workaround it?
[16:28] <LocutusOfBorg> robru, you there?
[16:28] <LocutusOfBorg> hi
[16:29] <robru> LocutusOfBorg: yes, I am here in athens on my vacation.
[16:30] <LocutusOfBorg> sorry for bothering, quick question
[16:30] <LocutusOfBorg> the new python-coverage broke ubuntuone-dev-tools
[16:30] <robru> LocutusOfBorg: ok
[16:30] <rbasak> nacc: if it works, but it would cause a conffile prompt. Is there another way?
[16:30] <LocutusOfBorg> the fix I propse
[16:30] <LocutusOfBorg> http://paste.ubuntu.com/17704325/
[16:30] <LocutusOfBorg> I can upload BTW
[16:30] <nacc> rbasak: not sure, just learning about dbconfig-common now :)
[16:31] <LocutusOfBorg> error is: AttributeError: 'module' object has no attribute 'erase'
[16:31] <robru> LocutusOfBorg: I don't understand why you're talking to me about this.
[16:31] <LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/u/ubuntuone-dev-tools/20160622_153920@/log.gz
[16:31] <LocutusOfBorg> robru, you are the last uploader
[16:31] <robru> LocutusOfBorg: of what? I generally don't upload much
[16:32] <LocutusOfBorg> ubuntuone-dev-tools
[16:32] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/ubuntuone-dev-tools/13.10-0ubuntu4
[16:32] <LocutusOfBorg> you are almost the only uploader here, even if it was a long time ago
[16:32] <robru> oh god why
[16:33] <LocutusOfBorg> err, you are the only one :)
[16:33] <nacc> heh
[16:33] <LocutusOfBorg> so, before uploading my "fix" I would like you to ack it
[16:33] <LocutusOfBorg> it should be just a matter of defining a variable, but I prefer you to ack it ;)
[16:34] <LocutusOfBorg> and for sure the testsuite will give us another answer
[16:34] <cjwatson> LocutusOfBorg: err, I think you are confused by "Robert" and "Rodney" looking quite similar
[16:34] <cjwatson> LocutusOfBorg: robru has uploaded it exactly once, dobey did all the other uploads that I can see
[16:34] <robru> cjwatson: but indeed mine is the latest
[16:34] <dobey> what's up?
[16:35] <dobey> oh hmm
[16:35] <LocutusOfBorg> cjwatson, I clicked on the email
[16:35] <LocutusOfBorg> and it bringed me to robru profile
[16:35] <LocutusOfBorg> not sure what I'm confusing, anyway, if a python developer can acknowledge this http://paste.ubuntu.com/17704325/
[16:35] <LocutusOfBorg> I'm fine :)
[16:36] <dobey> cjwatson, LocutusOfBorg: can we just remove ubuntu-sso-client, software-center, and ubuntuone-dev-tools from yakkety?
[16:36] <cjwatson> LocutusOfBorg: the most recent one would do, but all the other uploads in https://launchpad.net/ubuntu/+source/ubuntuone-dev-tools/+changelog are not robru
[16:36] <cjwatson> dobey: hey, I'm just attempting to drive-by unconfuse LocutusOfBorg here
[16:36] <cjwatson> removing software-center would be a desktop team thing
[16:36] <robru> dobey: +1
[16:37] <dobey> Laney: ^^ ? :)
[16:37] <Laney> Dunno
[16:37] <Laney> ask the list
[16:37] <Laney> I would upload the fix to unblock whatever is currently stuck
[16:37] <Laney> No need to couple the two things IMO
[16:38] <LocutusOfBorg> well, indeed cjwatson :)
[16:38] <dobey> LocutusOfBorg: fix looks ok to me. if it unblocks, go ahead and upload it
[16:38] <LocutusOfBorg> dobey, yes, it is building correctly
[16:38] <LocutusOfBorg> lets upload and see the testsuite
[16:38] <LocutusOfBorg> thanks
[16:38] <LocutusOfBorg> done! :)
[16:38]  * LocutusOfBorg leaves shortly, train is approaching station
[16:38] <Laney> you probably could have run adt locally
[16:39] <Laney> oho
[16:39] <dobey> Laney: well, if it's ok to remove them, then we should do it now, rather than waiting for the next failure :)
[16:39] <LocutusOfBorg> Laney, it works
[16:39] <Laney> dobey: I recommend you start the thread now then
[16:39] <Laney> I can't decide that alone
[16:39] <LocutusOfBorg> it wasn't compiling, and it started building correctly
[16:40] <LocutusOfBorg> the failure was on rebuild, and it seems fixed
[16:40] <LocutusOfBorg> and the runner is called the same way on adt and build testsuite
[16:40] <LocutusOfBorg> so I guess no issue expected ;)
[16:41] <LocutusOfBorg> but I'll keep an eye until coverage and ubuntuone-dev-tools migrates
[16:41] <LocutusOfBorg> dobey, thanks for removing the binaries eventually ;)
[16:41] <dobey> yes, if the source tree builds it should be fine
[16:41] <LocutusOfBorg> thanks a lot
[16:41]  * LocutusOfBorg leaves
[16:41] <dobey> the autopkgtests just run the same build :)
[16:50] <nacc> rbasak: hrm, i changed bacula's dbconfig file, it avoids that error, but then it says it can't connect, although i can using the same credentials from the cli command-line
[17:39] <semiosis> hi all.  i'm working on bug 1565985 and think I have a good strategy to solve it.  anyone around to discuss?
[17:39] <semiosis> copying what i wrote in #ubuntu-server.  i think this may be a better forum.
[17:40] <semiosis> what i want to do is move 42-vagrant.binary to 40-vagrant.binary and, instead of having it use the vmdk produced in 40-vmdk-image.binary, use the disk image produced by 32-disk-image.binary. that way we can mount the disk image, install the extra packages needed for a vagrant base box, then call create_vmdk and continue with the rest of the vagrant packaging stuff.
[17:40] <semiosis> the source files i'm referring to are here: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/live-build/ubuntu-cpc/hooks/
[17:46] <nacc> rbasak: ok, here's what i figured out so far: if i just do a `apt-get install bacula` first, it will use sqlite3 (contradicts https://help.ubuntu.com/lts/serverguide/bacula.html), but it succeeds. If I then install `apt-get bacula-director-mysql bacula-common-mysql`; that install throws a warning and error (http://paste.ubuntu.com/17707954/) but it does not fail to install (unlike if I try to just
[17:46] <nacc> `apt-get install bacula-director-mysql` as the first package)
[17:58] <infinity> semiosis: Discuss it on the bug, the right people might not be paying attention here.
[18:01] <rharper> hallyn: around ?  on yakkety, non-root access to /dev/kvm doesn't work;  http://paste.ubuntu.com/17708681/
[18:01] <semiosis> infinity: i'm going to try that strategy out and if it works i'll push a branch.  then there will really be something to discuss.  just wanted to throw out the idea here too.
[18:02] <rharper> hallyn: of course adding kvm group works;  just wondering why it works without the group on xenial I suppose
[18:03] <hallyn> acl not being set?
[18:04] <hallyn> are you logging inthe same way to both?
[18:04] <hallyn> on xenial an acl gets set on login
[18:04] <hallyn> for the desktop user
[18:04] <infinity> I've never noticed non-root access to /dev/kvm working without being in the group...
[18:04] <infinity> Why would that work?
[18:05] <sarnold> o_O
[18:05] <hallyn> bc http://paste.ubuntu.com/17708894/
[18:06] <hallyn> i never really liked that, but desktop ppl did
[18:06] <infinity> So, it's part of the desktop session?
[18:06] <infinity> Or..?
[18:06] <hallyn> grep -nr kvm /lib/udev
[18:06] <hallyn> i actually forge the details, looking,
[18:07] <hallyn> yeah it's some combination of udev and consolekit
[18:08] <hallyn> /lib/udev/rules.d/70-udev-acl.rules is the key .  is that different in yakkety?
[18:09] <infinity> It doesn't exist in yakkety.
[18:10] <hallyn> ships with consolekit...
[18:10] <hallyn> rharper: ^ there you go, were you going to track down what changed? :)
[18:10] <infinity> Which we don't install.
[18:11] <rharper> hallyn: interesting, yakkety is a ssh session, my xenial is my laptop/desktop session
[18:11] <rharper> infinity: I don't know that I've verified that either... I think group access has always been required as well ; I was just surprised that it worked on my laptop without it.
[18:12] <rharper> hallyn: looking
[18:12] <infinity> rharper: Okay, so if this is set for local sessions, that ssh one wouldn't work anyway.
[18:12] <infinity> (I'm not a big fan of people's extrapolation that because you have physical access, you may as well be allowed to do scary things, but whatever...)
[18:13] <ubuntu__> curious does /dev/kvm does that device need to exist for uses of virtualbox ,quem , bochs ,...etc or is that just for type 1 virtualization like hypervisor analogy for windows
[18:13] <rharper> I do think something changed;  I've been running some qemu based tests on my yakkety host via ssh and I've not seen this before;
[18:13] <infinity> ubuntu__: It's for kvm-accelerated VMs so, no, not for full-emu qemu, bochs, etc.
[18:13] <infinity> ubuntu__: Also, pick a better IRC nick? :P
[18:13] <rharper> ubuntu__: any virt software that wants to use hardware virt provided the platform needs it
[18:14] <sarnold> /dev/kvm is likely only used by kvm-accelerated qemu and kvmtool. bochs probably not, virtualbox probably can't work with the module loaded..
[18:14] <infinity> rharper: s/hardware/kvm/ :P
[18:14] <infinity> sarnold: vbox and kvm can coexist, but the former doesn't use the latter.
[18:15] <rharper> infinity: yeah;  vbox loads it's module instead IIRC
[18:15]  * infinity nods.
[18:15] <sarnold> infinity: intersting, I thought I recalled rmmodding the one to use the other many years back
[18:16] <infinity> sarnold: I flip-flop between the two when bug-hunting specific oddities, they seem to coexist fine these days.
[18:16] <sarnold> infinity: nice, it was an annoying compliction back in the day
[18:17] <infinity> sarnold: Well, the better option is always just to burn vbox in fire.
[18:18] <infinity> sarnold: Yet another example of the importance of UI design, I suspect.  Doesn't matter if the underlying tech sucks a bit if the package is pretty and usable.  Which qemu/kvm sure as heck weren't for ages (and still aren't, a lot of the time).
[18:18] <hallyn> sarnold: i think that's in the past.  yeah they used to not work together
[18:19] <hallyn> infinity: personally i hate vbxo bc i never have a gui and hte cmdline sucks ass
[18:19] <infinity> A nice VM UI that sat on top of kvm, hyper-v, and whatever the native MacOS interface is, and just did the right thing in a pretty and consistent way would probably have users flock to it in droves.
[18:19] <Unit193> hallyn: ...phpvirtualbox. :P
[18:20] <hallyn> yeeaaah
[18:20] <sarnold> lalalalalalala can't hear you lalalala
[18:20] <infinity> hallyn: I've never even attempted to use vbox from the CLI.  And, on the flipside, any attempt I've made to use qemu from a GUI has drive me *back* to the CLI.  Clearly a gap there in both directions. :P
[18:20] <hallyn> yup
[18:20] <hallyn> rharper: inthe past when it worked for you in yakkety, which user were you using?  was it not inthe kvm group?
[18:20]  * juliank used vbox cli stuff a few years ago. but vbox sucks big time, it made the machines fairly crashy
[18:21] <rharper> hallyn: correct
[18:21] <hallyn> bc typically on my nested vm usage, user ubuntu is in group kvm
[18:21] <rharper> like last week, it worked without group kvm
[18:21] <hallyn> that sounds like a fixed regression then :)
[18:21] <rharper> yeah
[18:21] <hallyn> it shouldn't have
[18:21] <juliank> infinity: Do you have some endorsement to share on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-CoreDev ? That would be nice, perhaps even useful :)
[18:21] <rharper> I agree
[18:21] <rharper> which makes me thing I'm bonkers
[18:21] <hallyn> as you get more datapoints please ping me - or raise a bug
[18:21] <hallyn> \o
[18:21] <rharper> because how would something fundamental like group access fail ?
[18:22] <hallyn> negative acls
[18:22] <rharper> hallyn: well, I can't reproduce it working *without* the group now
[18:22] <rharper> that's a new term to me
[18:22] <hallyn> without the group and without the acl?
[18:22] <hallyn> please do open a bug then, this is too convoluted a set of data to keep straight in my head or in an irc conv
[18:22] <rharper> ok, I'll open
[18:41] <elbrus> nacc: I can try to help with bacula, but your pastebin gives too little information
[18:41] <nacc> elbrus: ack, will reproduce, what all do you need?
[18:41] <nacc> elbrus: it happens immediately on trying to install bacula + mysql in 16.04
[18:41]  * nacc starts up a fresh container
[18:43] <elbrus> nacc: is the mysql-server installed and configured before?
[18:44] <elbrus> if mysql-server is not yet configured, you can expect this I guess
[18:44] <nacc> elbrus: not necessarily; it's the first configuration that came up this time (not sure if it's consistently/repeatably so)
[18:44] <elbrus> I had to order this correctly for cacti autopkgtest as well, if the order is wrong, things fail
[18:45] <elbrus> this can't be properly detected by dbconfig-common, as the mysql-server may very well live on a different host, so nothing to test before the admin told us what to expect
[18:46] <elbrus> well, I think detection is correct ...
[18:46] <elbrus> it fails...
[18:46] <nacc> http://paste.ubuntu.com/17710725/ is the typescript
[18:46] <nacc> elbrus: note that time, it threw the same warning and then an error ("invalid default value for 'CleaningDate'")
[18:47] <nacc> but it finsihed that time too :/
[18:48] <ubuntu__> ok lsmod gives me all the LKM in uses. Tracking down only audio i have http://pastebin.com/KpMy9NXp
[18:48] <elbrus> nacc: but the invalid value for CleaningDate looks like a bug in bacula with respect to MySQL not accepting zero-date anymore
[18:48] <ubuntu__> using lspci i have that the audio hardware is associated to this LKM snd_hda_intel
[18:48] <elbrus> I had to fix that in cacti as well in a SRU.
[18:48] <nacc> elbrus: ah could be, do you have a pointer to the corresponding cacti fix?
[18:49] <elbrus> nacc: let me look that up
[18:49] <nacc> elbrus: and i think the result is actually a failure, btw (i have to ignore the bacula-director-mysql errors to proceed) as trying to then install the test packages from my ppa fails due to various tables existing
[18:49] <ubuntu__> so kind of wondering what the other snd* LKM are for am i right in saying the snd_hda_intel is the lowest level LKM in the sense of does the most lowest level control of the sound card hardware?
[18:49] <nacc> elbrus: so let me add your fix :)
[18:50] <nacc> ubuntu__: wrong channel?
[18:50] <elbrus> http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/commit/?id=b94dd8459080d242f24d900786d4ab5052526545
[18:50] <elbrus> and
[18:50] <elbrus> http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/commit/?id=82150a56c51cbdb82e9f6f8e7136b1a939d7dffe
[18:50] <elbrus> so effectively
[18:50] <elbrus> http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/tree/debian/patches/make_cacti_sql_mode-strict_compatible.patch
[18:51] <nacc> elbrus: great, thank you! let me try and do the same to bacula
[18:51] <elbrus> which basically sets the session sql_mode to exclude the NO_ZERO_DATE
[18:51] <elbrus> because upstream doesn't want to fix it "properly" as it is using it by design
[18:52] <nacc> ok :)
[19:04] <nacc> elbrus: it seems like bacula uses a script to create the tables; would i run that set in their script then?
[19:04] <elbrus> nacc: I guess there, and upon calls involving this column
[19:05] <nacc> elbrus: yep
[19:05] <elbrus> as in my patch, I set it in cacti.sql (which is used to fill the database) and in lib/database.php, which is used to connect the web-app to the database
[19:11] <nacc> elbrus: got it
[19:20] <nacc> elbrus: thanks for the pointers, all of this is foreign to me :)
[19:20] <elbrus> nacc: np
[19:21] <elbrus> this is more related to the late move of Ubuntu to MySQL 5.7
[19:21] <elbrus> but glad I could help
[19:21] <nacc> elbrus: yeah, i am gathering as much
[19:22] <nacc> elbrus: since bacula is in sync w/ debian right now, i'll send up whatever fixes i find as well
[19:22] <elbrus> nacc: Debian hasn't moved to MySQL 5.7 yet last time I looked
[19:23] <elbrus> but yes, patches welcome
[19:23] <elbrus> I assume
[19:29] <nacc> elbrus: yeah, i guess it'd be eventual
[19:29] <nacc> elbrus: there are some functional issues with the code too, i think
[19:29] <nacc> elbrus: working through our bugs now
[19:51] <nacc> elbrus: hrm, so another attempt to install bacula-director-mysql, and got: http://paste.ubuntu.com/17713797/. THe mysql-server configuration finished first
[19:57] <elbrus> nacc: looks like you chose an other password for the bacula user than the previos time
[19:57] <nacc> elbrus: this was a fresh lxc container
[19:57] <elbrus> (there is an existing bug that the password does not get replaced)
[19:58] <nacc> elbrus: link to that bug?
[19:58] <elbrus> hmm, ${db_name} should have been replaced with a name
[19:59] <nacc> elbrus: yeah, i would ahve thought so
[19:59] <elbrus> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439078
[20:00] <elbrus> but you mean, fully clean lxc before THIS install of bacula?
[20:00] <nacc> elbrus: yep, i'm starting from scratch each time
[20:00] <elbrus> or clean before you started to try install
[20:00] <elbrus> ok
[20:00] <nacc> elbrus: it's super-inconsistent :/
[20:01] <elbrus> can you please "dbc_debug=true" before the apt-get incantation?
[20:01] <elbrus> be carefull with copy/paste, passwords are exposed
[20:01] <nacc> elbrus: let me reproduce it and do so
[20:01] <nacc> elbrus: there are all throw-away containers
[20:01] <nacc> *these
[20:02] <nacc> elbrus: but will do so and ping you when i have output
[20:05] <nacc> elbrus: e.g., `dbc_debug=true apt-get install bacula-director-mysql` ?
[20:05] <nacc> elbrus: or does it need to be exported in teh env?
[20:05] <elbrus> indeed
[20:05] <elbrus> the first one
[20:06] <nacc> elbrus: thanks
[20:09] <nacc> elbrus: http://paste.ubuntu.com/17714692/
[20:12] <elbrus> nacc: can you log into mysql and verify that the bacula database exists and that the bacula user exists? maybe even try to log in manually as bacula user with the password in your copy?
[20:12] <nacc> elbrus: yep, one sec
[20:14] <elbrus> oh, and maybe grep for db_name in the bacula code? I can't find that string in dbconfig-common, so it looks like it comes from bacula
[20:15] <nacc> http://paste.ubuntu.com/17714862/
[20:15] <nacc> elbrus: ack, one sec
[20:17] <nacc> elbrus: http://paste.ubuntu.com/17715004/ heh, i wonder if that sed fix isn't complete
[20:18] <elbrus> well, the variable end up in MySQL as a string '${db_name}' as the name of the database, which doesn't exist of course, because the name is 'bacula'
[20:19]  * elbrus is nearly going to bed.
[20:20] <nacc> elbrus: yep, i'll dig, thanks!
[21:00] <marlinc> What would be a good package to check out that is not being compiled? I'm trying to create a deb for a application that is not being compiled
[21:03] <jbicha> marlinc: please be more specific about what kind of package you're looking for
[21:04] <marlinc> I'm sorry, this is the first time I'm trying to package up a application. I think I found out was going wrong..
[21:04] <dobey> marlinc: compiled is irrelevant. python isn't necessarily compiled, for example
[21:04] <dobey> what are you trying to package exactly?
[21:04] <Unit193> Some scripts are just popped into place, I have a package like that.
[21:05] <marlinc> ipsilon, its a identity provider written in Python. Kind of a companion to FreeIPA
[21:05] <dobey> marlinc: does it have a setup.py script?
[21:05] <marlinc> it does, yes
[21:05] <marlinc> And it has a Makefile to run tests etc
[21:06] <dobey> then you can grab almost any other python based tool's source package to learn from. pep8 or pyflakes are probably some of the simplest ones
[21:06] <marlinc> Cool, thanks
[21:07] <dobey> marlinc: there's also #ubuntu-packaging which is a channel specifically for such packaging questions :)
[21:07] <marlinc> Ah, thank you :)
[21:09] <jbicha> marlinc: https://wiki.debian.org/Python
[21:10] <marlinc> I'll look at that jbicha, thanks
[22:49] <nacc> elbrus: rbasak: fyi, i found (a/the) bug, i think, /etc/bacula/scripts is not subsituting db_name
[22:55] <nacc> elbrus: rbasak: hrm, maybe not
[23:22] <nacc> can anyone say if messages like this: http://paste.ubuntu.com/17722065/
[23:22] <nacc> come from the package itself, or some (well-known) helper tool?
[23:28] <nacc> found it, it's in dbconfig-common
[23:41] <nacc> rbasak: elbrus: ok, it's the postinst that's emitting the error ("Access denied for user 'bacula'@'localhost' to database '${db_name}'). still debugging