[00:14] nacc sorry , i am back [00:14] nacc what do you mean by that? [00:17] capum321: you're rebuilding the existing binary package w/o modifications? [00:18] yes [00:18] i just downloaded it from the launchpad site [00:18] capum321: can i ask why you're rebuilding it? why not just it as a dependency? [00:19] because of this http://www.monodevelop.com/developers/building-monodevelop/#linux [00:19] capum321: that's a long page, can you just explain? [00:20] it is a dependency for building monodevelop [00:20] capum321: it says it needs mono.addins 0.6; ubuntu is at 1.0? [00:21] capum321: and even so, what would rebuilding get you? [00:21] yes you are right [00:21] to install latest monodevelop [00:22] 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] I don't think I am aware of how to do this? do you mean using the tar.gz file as dependency? [00:29] capum321: i mean, just install the package (mono-addins-utils or whatever) [00:29] capum321: as that page says, use the distribution packages wherever possible [00:32] 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] these?] [00:32] install one by one you mean? [00:33] the parental package mono-addins doesn't have a .deb. one should build it. is that it? [00:34] not sure if I am following you correctly [00:34] capum321: no, i think you're confusing source packages and binary packages [00:35] capum321: mono-addins (the debian/ubuntu package) is just a source package [00:35] yes [00:35] capum321: it's what is used to build binary packages [00:35] ok [00:35] capum321: but you are running ubuntu/debian, so just install the binary pacakges [00:36] there are no binary packages since i have to build them at first place? [00:36] 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] capum321: what? [00:36] look inside the file [00:36] capum321: no, the src:mono-addins package makes several binary pacakges, as you said [00:36] there are no binaries [00:36] capum321: that's not how source pacakges work [00:38] oh i think i have understand [00:38] 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] continue [00:39] those 7 packages are available from Ubuntu, you don't build them yourself, unless you have need of a modification or something [00:39] 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] so i should install them one by one as i said [00:40] you're saying [00:41] no? [00:45] capum321: i mean, you can just install them all at once, i guess [00:45] off course [00:45] all in one line [00:45] 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] capum321: yes, but i genuinely don't know which of those you actually need [00:46] let me check [00:46] is there a ppa I could use to install simply mono-addins using this launchpad repo? [00:46] to makes simpler things [00:46] capum321: what? [00:47] capum321: mono-addins is *not* a binary package name [00:47] i see [00:47] not natively [00:48] capum321: what? what do you mean "natively"? [00:48] native... you should buid the source i you want the bin? [00:51] capum321: no [00:51] capum321: you never need to build a source package unless you're doing some Ubuntu development [00:51] (maybe too general, but good enough for now) [00:51] capum321: the binary packages mentioned already contain the binaries built from building src:mono-addins [00:52] i see [00:52] i move on. now installing cmake [00:52] 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] capum321: you should not have any need for source packages if you're just trying to build some random sourcecode [00:55] not sure if I get this... how would you build something if you don't have it? [00:56] capum321: have you used ubuntu before? [00:56] source packages are full of binary packages [00:56] is that it? [00:57] capum321: when you `apt-get install ` do you build it? [00:57] capum321: source packages are full of *descriptions* of how to build binary packages [00:57] capum321: source packages are just that, source [00:58] no you don't build like that; debuild builds it [01:00] 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] 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] actually would be compile a better word? [01:03] capum321: build, compile, it's the same -- you don't do that for any other package, I don't think [01:03] 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] capum321: you're not building the dependencies, you're building monodevelop itself, afaict [01:05] 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] 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] 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] capum321: that's because mono-addins is a *source* package, as I just spent some time explaining [01:08] 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] yes, it is getting clearer [01:10] 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] deb.tar.gz is on of the four files that trusty supports [01:13] 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] capum321: i don't parse that first sentence, but ok. [01:17] where should i seek assitance for installing libssh2? is it $ apt-cache search libssh = libssh-4 - tiny C SSH library [01:18] capum321: #ubuntu is the support channel [05:57] good morning [06:57] 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] Other then that the includes should be exactly identical === Cimi_ is now known as cimi === dcmorton_ is now known as dcmorton [07:13] Good morning [07:18] 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 === fabo_ is now known as fabo [07:33] jbicha, nice one! [08:46] I have a .service file of clamav and wonder why it isn't startign anymore on newer releases [08:46] the service files are bit identical throughout the releases, but obiously systemd is newer [08:46] things work on jessie, but fail on xenial, yakkety, sid [08:47] cpaelzer: what does "sudo systemctl status clamav" say? [08:47] on the newer systems it comes as "inactive (dead)" after being installed [08:47] so it either died or wasn't started at all -> systemctl status please [08:48] ... need to convince pastebinit ... [08:50] it hates the utf chars in systemd's output [08:50] uh? not here [08:50] http://paste.ubuntu.com/17686364/ [08:50] might be a missing dependency in my container [08:50] I'll push it through an editor to get on for now [08:50] wrong locale perhaps? [08:51] copy&paste into http://paste.ubuntu.com :) [08:53] sid (broken) http://paste.ubuntu.com/17686435/ and jessie (working) http://paste.ubuntu.com/17686449/ [08:53] all the log content in the sid case is from former start/stop/install/uninstalls [08:54] at first it had no entries at all in the broken case [08:54] a simple "systemctl start clamav-freshclam.service" gets things working fine - so it is not broken config or so [08:55] thereby (working when stared manually and no log) I'd expect it never got started [08:55] Test is as easy as "apt-get install clamav-freshclam; systemctl status clamav-freshclam.service" on anything recent [09:04] 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] cpaelzer: is that service actually enabled? in your pastebin it was started and stopped [09:05] pitti: Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; vendor preset: enabled) [09:05] the starts were manual ones where I checked if it would start (it did) and stops are from uninstalling the package [09:06] cpaelzer: for me it doesn't start right after package install, but it does start after a reboot [09:07] pitti: yeah, exactly - why doesn't it after install is more or less my question? [09:07] supposedly some breakage in the postinst [09:07] pitti: ok I'll check for diffs if you assume it is there [09:07] it apperantly only calls dh_systemd_enable, but not dh_installinit or dh_systemd_start [09:08] instead it does some really complicated manual code dance [09:08] pitti: I'd have expected the systemd version change as the service file was bit-identical [09:08] but it calls invoke-rc.d *before* enabling the unit [09:08] so this stuff needs to move after #DEBHELPER# [09:08] cpaelzer: probably more likely to be a side effect of an invoke-rc.d fix [09:09] 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] it must be enabled first, then started [09:09] invoke-rc.d does not start disabled stuff [09:09] maybe it did in earlier versions [09:35] where can i find the busybox configuration of the 16.04 netboot image? [09:36] or maybe, where would be the right place to ask this question? [09:44] blut: It's in the busybox source package in 16.04; debian/config/pkg/udeb [09:46] thank you [10:01] caribou, hey about https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1583563 why did you steal assignment for it for xenial? [10:01] Launchpad bug 1583563 in multipath-tools (Ubuntu Xenial) "System will not start with multipathd enabled" [High,Confirmed] [10:02] is https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=multipath not enough? [10:05] thanks pitti === martinst is now known as martinst-afk [10:11] juliank: thanks to you, good luck! [10:14] cpaelzer: I thought it wasn't starting because of the condition - because freshclam hasn't run? [10:14] That's just from memory though I didn't look much deeper. [10:15] rbasak: it is a bit more complex [10:15] rbasak: I updated the bug if you want to read into the full analysis [10:16] 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] 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] cpaelzer: sounds like you're on top of it. Thanks :) [10:22] cpaelzer: meet ScottK. He used to look after clamav in Ubuntu. [10:22] ScottK: this is bug 1590688, which AFAICT affects sid also. [10:22] bug 1590688 in clamav (Ubuntu) "clamav-daemon doesn't start after installation" [High,New] https://launchpad.net/bugs/1590688 [10:22] hi ScottK - I'm currently wrapping things up for a proper Debian bug - but I'm gonna test my suggestion first :-) [10:24] 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] flexiondotorg: no, this isn't planned [10:24] ty [10:24] this doesn't appear like a safe change for an SRU [10:25] some stuff like mysql or whatnot might actually need a lot of time during shutdown === cpaelzer is now known as cpaelzer_lunch [10:25] 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] we already got burned with imposing default nproc limits and KillProcesses=, not gonna do this exercise in stable :) === hikiko is now known as hikiko|ln [10:51] xnox: 'cause I'm about to SRU another Xenial fix so I thought I'd do them both [10:51] 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] 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] caribou, or maybe just ship these. What are the other bug #s to SRU? [10:53] are they as urgent as multipath-tools are utterly borken? [10:54] xnox: broken to the point where, with LVM2 devices will be claimed by LVM before multipath gets them === cpaelzer_lunch is now known as cpaelzer [10:58] 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 [10:58] Debian bug 817940 in multipath-tools "multipath-tools: multipathd is not linked to libsystemd, fails to notify systemd when ready" [Normal,Fixed] [11:00] xnox: opening a bug for this atm [11:02] xnox: lp: #817940 [11:02] Launchpad bug 817940 in Mahara "Session directories are created on every init" [Wishlist,Won't fix] https://launchpad.net/bugs/817940 [11:06] meh: lp: #1595141 [11:06] Launchpad bug 1595141 in multipath-tools (Ubuntu) "Debian bug #817940 incorrectly fixed in Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1595141 [11:21] caribou, my SRU fixes not linked to libsystemd. [11:23] caribou, # ldd /sbin/multipathd | grep systemd [11:23] libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fc6df0e1000) [11:23] caribou, can you retest the lvm bug in yakkety? [11:23] the not linked to libsystemd is what is causing the 3 bugs mentioned in the changelog, and this lvm thing too. [11:23] xnox: yakkety has the correct target [11:23] caribou, and that's included in my sru. [11:24] caribou, so that pending sru should cover everything, no? [11:24] 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] xnox: yep, [11:25] xnox: just did a debdiff on xenial .vs. yakkety & your SRU brings in the fix === iahmad_ is now known as iahmad [11:26] xnox: ok, I duped my bug on yours [11:30] pitti, could you please partially release https://bugs.launchpad.net/ubuntu/+source/gcc-5-cross/+bug/1572613/comments/64 ? [11:30] Launchpad bug 1572613 in gcc-mingw-w64 (Ubuntu) "GCC stack access scheduled after stack deallocation" [Wishlist,Triaged] [11:30] pitti, just the packages mentioned in that comment that have non-regressed autopkgtests? [11:30] xnox: yes, will do; thanks [11:32] xnox: done === hikiko|ln is now known as hikiko [11:39] 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:39] Launchpad bug 1457400 in systemd (Ubuntu) "reduce 90s session kill timeout if the session does not shutdown cleanly" [Low,Confirmed] [11:42] ouroumov: see backscroll from an hour ago, flexiondotorg already pinged above [11:43] ok [11:43] 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 | 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] IRC deja-vu [11:47] Thanks pitti. === inaddy is now known as tinoco === ara is now known as Guest21851 === tlyu_ is now known as tlyu [12:05] mvo: What do you think about moving my application from PPU to CoreDev? xnox and pitti seem to be excited about that [12:09] I'm sure it can gracefully fall back to PPU if the DMB doesn't like the core-dev bit [12:09] juliank: +1 for core-dev [12:09] xnox: btw, I didn't *steal* your assignment, it was unassigned when I took it : "assignee: nobody → Louis Bouchard (louis-bouchard)" [12:10] :) [12:11] 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] OK, I moved the application to https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-CoreDev === martinst-afk is now known as martinst [12:25] 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] I don't think it would make stuff much bigger… === ochosi_ is now known as ochosi [12:35] xnox: OK, it's official now, I sent out a core-dev application! [12:37] 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] that was two days ago [12:38] mapreri, full debian/changelog, when gzip compressed is 193k, and things from 1994 are entirely pointless. [12:38] juliank: go ahead and add it to the agenda with a date. Then you'll be first in line. [12:39] mapreri, throw in everything in minimal and one has more than a meg of useless stuff. [12:39] 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] We appear to have none right now. [12:40] micahg: ^ [12:41] rbasak: OK, added [12:42] Thanks! [12:42] 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] rbasak: Do I now have to monitor that page to find out when the meeting is? [12:44] or should that be 4th of July at 19:00 UTC? [12:44] 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] Right [12:44] OK [12:44] I'll just reformat my entry as well and make my name link to my application [12:45] juliank: the meeting on 4 July will be at 1430 UTC according to my calendar unless I'm mistaken. [12:45] Uh, 1500. [12:45] rbasak: OK, I'm at DebCamp anyway, so I can manage any time [12:46] s/Camp/Conf/ [12:46] I have my calendar entry include 30 minutes to remember to show up and read applications, etc. [12:46] http://fridge.ubuntu.com/calendars/fridge/ seems to have duplicates but I think it is correct. [12:47] Wonderful. [12:49] mapreri, pretty sure those are huge and utterly useless. [12:49] too [12:49] we did ignore/reduce both. e.g. limit number of entries and/or not have them at all. [12:49] mapreri, no, we cannot live with 2/3MB more. [12:49] I added future meeting dates to the agenda. [12:50] mapreri, that's huge increase for containers and snappy, target there is about 40MB [12:50] 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] micahg: ^ === olli__ is now known as olli === kyrofa_ is now known as kyrofa [13:15] Laney: The date parsing issue is now fixed in apt 1.3~exp3, should be syncable in half a day or something [13:15] (just uploaded it to Debian) [13:16] 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:16] bug 1595177 in apt (Ubuntu) "[SRU template] Update apt/xenial to 1.2.14" [Undecided,New] https://launchpad.net/bugs/1595177 [13:22] Note that 1.3~exp3 now allows you to use weak repositories with the correct setting for your source [13:22] 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] but not entirely sure [13:32] 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:32] Launchpad bug 1286882 in mpm-itk (Ubuntu Trusty) "libapache2-mpm-itk postinst failed" [Medium,Fix committed] https://launchpad.net/bugs/1286882 [13:33] a bug in a2query + misconfiguration of the apache2 server [13:33] arges, good morning, if you have a moment can you review our xenial horizon sru? it's a hot one for bug 1594249 [13:33] bug 1594249 in openstack-dashboard (Ubuntu Xenial) "[SRU] Update of dashboard fails on Xenial" [Critical,Triaged] https://launchpad.net/bugs/1594249 [13:34] is there a way we can unblock this SRU which is blocking another apache SRU (LP: #1286882) [13:34] Launchpad bug 1286882 in mpm-itk (Ubuntu Trusty) "libapache2-mpm-itk postinst failed" [Medium,Fix committed] https://launchpad.net/bugs/1286882 [13:34] coreycb: I thinkg that arges is off this week [13:34] caribou, ah thanks! [13:35] bdmurray, would you be able to look review that? ^ === iahmad_ is now known as iahmad === tyhicks` is now known as tyhicks === attente_ is now known as attente [14:21] pitti: hello! I'm having a problem with autopkgtests and the proxy. Do you have a minute? [14:22] hey elopio, what's up? [14:22] pitti: pass -e http_proxy, https_proxy and no_proxy, but it fails when during the package build the network is accessed. [14:22] like: http://paste.ubuntu.com/17698405/ [14:22] *I pass. [14:23] elopio: do you actually have localhost in $no_proxy? [14:23] pitti: yes, this is the call: http://paste.ubuntu.com/17698490/ === stub` is now known as stub [14:24] 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] elopio: oh, package build -- that might not actually get proxy vars [14:24] 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] you sholdn't need to [14:24] a package build should not have proxy vars [14:25] elopio: if you don't specify -e, does the package build? [14:26] elopio: so I guess your problem is rather the inverse -- proxy vars *are* already set during package build [14:26] as using the nova setup scirpt for this does that for *all* commands [14:26] elopio: so something in your test isn't respecting $no_proxy [14:26] (test during package build, I mean) [14:28] 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] hum, let me try without -e. [14:28] elopio: I think ssh runner's -e is a bit ill-conceived [14:28] at least for using proxies [14:30] 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] Debian bug 804992 in mysql-server-5.6 "mysql-server-5.6: Please drop dependency on initscripts package" [Normal,Open] [14:30] 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] anyway, I'll collect more data points. [14:31] rbasak: however, it's still there in https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/tree/debian/control [14:31] rbasak: is that still just not pushed, or in some branch? [14:32] 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] 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] 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] 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] rbasak: nice, thanks [14:38] * pitti updates the Debian bug accordingly [14:38] Oh, not a sync, but a really trivial merge, to drop a universe dependency. [14:38] rbasak: you might want to use substvars and drop it for an ubuntu build, to keep the packages in sync? [14:39] pitti: yeah, I need to look into that. [14:39] It's a build dep, but they're allowed now :) [14:39] So I think I can just conditionally compile without support, but have the build dep present all the time. [14:40] rbasak: ah yes, and conditionally add a --disable-foo? [14:40] 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] yeah, that's much harder, this probably warrants a delta then [14:42] still doable with some conditional -N magic, but still "eww" [14:42] 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] 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] coreycb: I'm out today but will look tomorrow [14:48] bdmurray, ok thankx [14:48] thanks [14:57] juliank: cool beans === bdrung_ is now known as bdrung === funkyHat_ is now known as funkyHat [15:12] !mir [15:12] Mir is the next-generation display server currently under development by Canonical and Ubuntu. It's slated for inclusion in Ubuntu 14.04. For more information on it, see https://wiki.ubuntu.com/Mir/Spec . For code, see https://launchpad.net/mir === ara is now known as Guest30555 [15:59] 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] rbasak: LP: #1563274 [16:01] Launchpad bug 1563274 in dbconfig-common (Ubuntu) "dbconfig-mysql sets blank port in config" [Undecided,Confirmed] https://launchpad.net/bugs/1563274 [16:01] 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] The other day I was debugging a pdns dep8 failure which seem to be related to dbconfig-common and postinst ordering. [16:02] But the problem went away by itself (non-deterministic) [16:02] rbasak: i think it's that any warning gets emitted [16:02] rbasak: http://paste.ubuntu.com/17702876/ [16:03] elbrus may be able to help. [16:03] That's actually a warning followed by an error. [16:03] It seems to me that the error (can't connect to socket) is unrelated. [16:03] nacc: try experimenting with the ordering of installation of mysql-server, the dbconfig packages, and bacula. [16:04] Just a hunch. [16:04] rbasak: yeah, that might be because it got into a bad state the first time [16:11] rbasak: this is a relatively important bug, no? bacula consistenly fails to install because of it (and requires manual intervention) [16:12] 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] this is being run inside a kvm instance [16:12] brendand: are you out of memory on your host? :) [16:12] brendand: nested kvm? [16:15] nacc, i suppose I *could* be, but I do have 16GB [16:15] nacc, nested, yeah [16:18] i suppose i really don't need to do this inside the vm anyway [16:20] nacc: yes, it is. [16:24] brendand: right, but does your guest have 16GB assigned to it? [16:24] brendand: meaning, does your nested host have sufficient memory? [16:25] good point. i just used a default, so probably only 1GB [16:25] i'll change that and try again [16:25] brendand: yep, that'd be the issue, i'm guessing -- so the second level guest was ENOMEM'ing, as expected :) [16:25] 500M, heh [16:28] rbasak: could i put a default value for dbport in /etc/dbconfig-common/config to workaround it? [16:28] robru, you there? [16:28] hi [16:29] LocutusOfBorg: yes, I am here in athens on my vacation. [16:30] sorry for bothering, quick question [16:30] the new python-coverage broke ubuntuone-dev-tools [16:30] LocutusOfBorg: ok [16:30] nacc: if it works, but it would cause a conffile prompt. Is there another way? [16:30] the fix I propse [16:30] http://paste.ubuntu.com/17704325/ [16:30] I can upload BTW [16:30] rbasak: not sure, just learning about dbconfig-common now :) [16:31] error is: AttributeError: 'module' object has no attribute 'erase' [16:31] LocutusOfBorg: I don't understand why you're talking to me about this. [16:31] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/u/ubuntuone-dev-tools/20160622_153920@/log.gz [16:31] robru, you are the last uploader [16:31] LocutusOfBorg: of what? I generally don't upload much [16:32] ubuntuone-dev-tools [16:32] https://launchpad.net/ubuntu/+source/ubuntuone-dev-tools/13.10-0ubuntu4 [16:32] you are almost the only uploader here, even if it was a long time ago [16:32] oh god why [16:33] err, you are the only one :) [16:33] heh [16:33] so, before uploading my "fix" I would like you to ack it [16:33] it should be just a matter of defining a variable, but I prefer you to ack it ;) [16:34] and for sure the testsuite will give us another answer [16:34] LocutusOfBorg: err, I think you are confused by "Robert" and "Rodney" looking quite similar [16:34] LocutusOfBorg: robru has uploaded it exactly once, dobey did all the other uploads that I can see [16:34] cjwatson: but indeed mine is the latest [16:34] what's up? [16:35] oh hmm [16:35] cjwatson, I clicked on the email [16:35] and it bringed me to robru profile [16:35] not sure what I'm confusing, anyway, if a python developer can acknowledge this http://paste.ubuntu.com/17704325/ [16:35] I'm fine :) [16:36] cjwatson, LocutusOfBorg: can we just remove ubuntu-sso-client, software-center, and ubuntuone-dev-tools from yakkety? [16:36] 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] dobey: hey, I'm just attempting to drive-by unconfuse LocutusOfBorg here [16:36] removing software-center would be a desktop team thing [16:36] dobey: +1 [16:37] Laney: ^^ ? :) [16:37] Dunno [16:37] ask the list [16:37] I would upload the fix to unblock whatever is currently stuck [16:37] No need to couple the two things IMO [16:38] well, indeed cjwatson :) [16:38] LocutusOfBorg: fix looks ok to me. if it unblocks, go ahead and upload it [16:38] dobey, yes, it is building correctly [16:38] lets upload and see the testsuite [16:38] thanks [16:38] done! :) [16:38] * LocutusOfBorg leaves shortly, train is approaching station [16:38] you probably could have run adt locally [16:39] oho [16:39] Laney: well, if it's ok to remove them, then we should do it now, rather than waiting for the next failure :) [16:39] Laney, it works [16:39] dobey: I recommend you start the thread now then [16:39] I can't decide that alone [16:39] it wasn't compiling, and it started building correctly [16:40] the failure was on rebuild, and it seems fixed [16:40] and the runner is called the same way on adt and build testsuite [16:40] so I guess no issue expected ;) [16:41] but I'll keep an eye until coverage and ubuntuone-dev-tools migrates [16:41]