[00:00] rbasak: have you seen jodh around lately? :) [00:01] I didn't think we ever "supported" upstart as system init since the switch to systemd, whatever that even means. "Supported" is such a weasel word. It can mean anything. [00:01] hallyn: :) [00:02] i bet he'd be interested [00:02] cause it's a fascintaing bug [00:11] In fact upstart is still used for user sessions on the desktop too, isn't it? And the system init on the phone too. === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [03:11] how is it that "drop database foo; create database foo;" on current xenial results in a complete restore of the database? [03:13] I don't know the answer to that question either way, but you may want to mention what DB you're using :) [03:14] stgraber: heh.. yeah. postgresql 9.4 [03:15] renaming the db before droping it doesn't help either [03:19] stgraber: sadly, I'm just trying to make a fresh start, and postgrs is being overly helpful, apparently [06:46] Good morning [06:51] morning pitti :) [06:52] hey sarnold, how are you? [06:52] pitti: not bad, getting over a cold, a little slower than I'd like, but otherwise alright :) how are you? [06:57] sarnold: oh, get well soon then! you seem to be in good company :/ [06:58] sarnold: I'm quite fine, fortunately I managed to evade the flu all winter so far :) [06:58] pitti: too true, half my family got the cold .. [06:58] pitti: nice nice :) [07:13] didrocks: I just followed up to bug 1524480; the Breaks:/Replaces of plymouth-theme-lubuntu-logo to plymouth is just for moving files, I suppose? [07:14] bug 1524480 in lubuntu-artwork (Ubuntu) "package plymouth 0.9.2-3ubuntu2 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/1524480 [07:15] didrocks: do you know, does that only affect lubuntu-logo for some reason, or a gazillion other themes too? I. e. the mutual Breaks: [07:15] mutual Breaks: forces "deconfigure", i. e. I wonder if we can avoid that somehow [07:17] hey pitti! I'm afraid that's pretty much global, indeed [07:17] pitti: as most of the themes seems to be copy and paste and they copied a wrong prerm [07:18] yeah, the Breaks/Replaces is just about the moving files, to ensure we don't end up for partial upgrade with an non working theme [07:18] didrocks: oh, so that's not just plymouth's prerm, but *all* prerms of logo packages? [07:18] pitti: yeah, plymouth prerm is fine (let me confirm in a minute), it's the ones in the logo packages for sure at least [07:18] and most of them are copy/paste :/ [07:18] didrocks: so instead of SRUing all logo packages and plymouth itseslf, it seems easier to me to just drop the Breaks: of the logo packages in xenial? [07:19] yeah, that would be slightely incorrect, but there is nothing else anyway that should call deconfigure on those packages [07:19] didrocks: oh, ok, I misinterpreted the log, it's indeed not plymouth itself [07:19] didrocks: right, which is how it got unnoticed for so long [07:19] we should still fix them in xenial though, so that this doesn't happen in the future [07:19] well, years :p [07:19] some packages were untouched since 2010/2011… [07:19] didrocks: curiously I had exactly the same case for ifupdown and udev two days ago (mutual Breaks:, missing deconfigure in udev.prerm) [07:20] didrocks: yes; so my proposal is to fix all the logo packages in xenial with (1) teaching prerm about deconfigure, and (2) dropping the Breaks: to fix upgrades [07:20] I don't know why people are doing this *) echo "Call with unknown parameter; exit 1 [07:20] didrocks: I had that too; I think that was in some standard templates [07:20] but that's a bit overzealous indeed [07:20] pitti: as most cases are empty anyway, I would suggest we drop that [07:21] yeah [07:21] so yeah, we can workaround and avoid the SRU by removing the Breaks [07:21] (in plymouth) [07:21] didrocks: oh, in plymouth, not in the logo packages? [07:21] the Breaks in plymouth against logo packages [07:21] didrocks: you should drop it on the side which has the Replaces:, not the other one [07:21] there is no Replaces [07:22] just Breaks [07:22] basically, new plymouth needs themes in /usr/share instead of /lib [07:22] Replaces: lubuntu-plymouth-theme, plymouth (<< 0.8.1-1~) [07:22] oh, I see, that's much older, not from this transition [07:22] yeah [07:22] the breaks is just to ensure we don't install new logo without new plymouth [07:22] and vice-versa [07:23] didrocks: that could also become a versioned depends: on the logo (which is simpler) [07:23] i. e. Depends: plymouth + Breaks: plymouth (<< 0.9.2-3ubuntu1~) == Depends: plymouth (>= 0.9.2-3ubuntu1~) [07:23] (was looking at plymouth-theme-lubuntu-logo) [07:23] but if you upgrade plymouth alone [07:24] you are in a "broken" situation [07:24] (for some definition of broken, for sure ;)) [07:24] didrocks: yes, that's why I think we should keep the Breaks: on plymouht and drop it from the themes [07:24] the breaks in plymouth won't force deconfigure in -logo? [07:24] didrocks: only a mutual Breaks: forces that [07:25] didrocks: if it's one-sided, the broken package gets upgraded first [07:25] oh didn't know that, was thinking one way was enough if plymouth was going to get configured first [07:25] ok [07:25] so apt reorders [07:25] making sense [07:25] didrocks: but if both packages break each other, there is no order which would always be consistant, so apt randomly picks one package, deconfigures that, and upgrades both [07:25] I can handle it then [07:25] indeed [07:26] we should maybe at some point scan the archive to see if this broken template is used elsewhere [07:26] didrocks: I *think*, plymouth breaks: theme (<< version) and theme Depends: plymouth (>= version) should work [07:26] yeah, worth a try anyway :) [07:27] pitti: ok, I'll prepare this and upload this early next week (don't want to try without doing an upgrade try) [07:28] well, first, let me check how many themes are concerned [07:28] didrocks: right, it should happen 50% of the time on upgrades depending on the order that apt picks [07:29] didrocks: I put the IRC conversation into the bug for reference [07:29] thanks! [07:29] didrocks: thanks to you! [07:29] thanks for looking and finding a way not breaking partial upgrades :) [07:30] pitti: I keep the mutual breaks in the ones that are not impacted, anything against it? [07:30] didrocks: technically not, but aesthetically a versioned depends: is clearer [07:30] didrocks: but no need to upload just for that, just if you have to touch a package anyway [07:31] yeah, some will need to replace harcoded 15.10 to 16.04 anyway [07:31] didrocks: ah, so not all themes are affected? [07:31] no, there is basically 2 templates that were used [07:31] didrocks: e. g. plymouth-theme-ubuntu-{logo,text}.prerm seem fine [07:33] pitti: yeah, the one based on the xubuntu theme are the ones to blame [07:33] they all contains something like http://paste.ubuntu.com/14436235/ [07:33] didrocks: ok, so can you handle that? you probably still have the most context in your head [07:34] didrocks: yeah, let's just drop that completely [07:34] pitti: yeah, and I have the list! So, preparing, doing an ugprade testing, and uploading :-) [07:34] +1 [07:34] didrocks: merci beaucoup ! [07:34] pitti: mais de rien :-) [07:35] didrocks: so, I hope that Breaks: and versioned Depends: don't force deconfigure; if it does, then indeed we can only just drop the Breaks: on one side :/ [07:35] (I'd still drop it on the themes side, though) [07:37] yeah, let's see if I can reproduce a wrong order in some vm with that fix (but that's why I only want to upload it on Monday) [07:37] (schroot should suffice) [07:39] yeah, but easier to use a snapshot for multiple runs [07:39] (I'm not on btrfs here :p) [07:39] well, should mount my schroot on tmpfs, yeah [07:39] (had to revert that recently as not enough RAM) [07:39] didrocks: so, I started a wily schroot, and this reproduces it: [07:39] apt install plymouth-theme-lubuntu-logo [07:39] [07:40] apt update [07:40] apt install plymouth-theme-lubuntu-logo [07:40] ah, quite easy indeed! [07:40] thanks for looking [07:40] * pitti puts that into the bug [07:41] didrocks: yeah, and takes a second only [07:53] Morgen! [07:53] good morning [07:53] * sladen beat the script! [07:53] what? no script :) [08:44] pitti: so works, and the good news is that the other themes aren't impacted (no prerm), only the other maintainer scripts have the parameters restrictions [08:44] pitti: uploading now :) [08:45] didrocks: \o/ merci! [08:45] pitti, why does ruby2.3 trigger any autopkg tests at all? it's not yet supported ... [08:46] doko: well, britney doesn't know what we consider "supported" [08:47] we can override it if we don't care, but seeing what breaks against it is interesting nevertheless, no? [08:48] well, if somebody addresses these [09:23] hum [09:23] since before holidays consoles are in qwerty layout on my xenial [09:23] unsure when it started but it was not like that in wily or earlier in the cycle [09:23] didrocks, ^ did you notice that as well? [09:24] pitti, is that a systemd thing? [09:24] /etc/default/keyboard is pc105/fr/oss [09:24] that used to work [09:26] console-setup presumably? [09:26] that didn't change since wily [09:26] seb128: it's still azerty here [09:26] :-( [09:26] (I didn't update since yesterday morning) [09:26] I had the issue before holidays [09:27] so it's not a today update one [09:27] thanks for testing! [09:28] seb128: did "systemctl status console-setup.service" run? if you run it manually, does it fix the layout? [09:28] seb128: I think that's what sets the layout (it calls loadkeys) [09:28] Active: inactive (dead) [09:29] oh: sudo journalctl -u console-setup [09:29] yes, that fixes it [09:29] it does run for me [09:29] déc. 11 08:43:11 seb-e6410 loadkeys[311]: Chargement de /etc/console-setup/cache [09:29] -- Reboot -- [09:29] janv. 08 10:29:02 seb-e6410 systemd[1]: Starting Set console keymap... [09:30] seb128: ah, that's just from right now [09:30] so no mention between decembre when the issue started and my manual start [09:30] oh, hang on [09:30] Dez 09 08:26:53 donald systemd[1]: Started Set console keymap. [09:30] that's my last entry [09:30] so indeed it doesn't get run any more [09:31] want a bug report? against what component? [09:32] hmm, 228-1ubuntu2 landed on Nov 23 (too early), -2ubuntu1 o Dec 12 (too late) [09:32] seb128: it's shipped by keyboard-configuration, so against that, but please assign to me [09:33] I'll find out what's supposed to start it [09:36] pitti, danke [09:37] pitti, in fact bug #1531442 seems to be about that issue [09:37] bug 1531442 in keyboard-configuration (Ubuntu) "reboot switches to us keyboard layout on console" [Undecided,New] https://launchpad.net/bugs/1531442 [09:37] assigned it to you [09:37] thanks [09:39] pitti, "-2ubuntu1 o Dec 12 (too late)" [09:39] pitti, are you sure? [09:39] my last valid run is from dec 11 [09:39] so that would pretty much match [09:39] yours is 09 and you maybe didn't reboot or installed the new systemd before upload to test it? [09:40] hm, not sure why it wouldn't have started for me on Dec 10 or Dec 11, but maybe I had a pre-upload version installed [09:40] seb128: I do reboot every day, but local dpkg -i sounds plausible [09:40] seb128: so indeed that one is the most probable culprit indeed [09:41] http://launchpadlibrarian.net/227354002/systemd_228-1ubuntu2_228-2ubuntu1.diff.gz doesn't have much though :-/ [09:42] *nod* [09:43] seb128: anyway, I'll check on wily what's supposed to depend on console-setup.service, apparently that's now missing [09:43] danke [09:43] it's a static service (no [Install] section), so it doesn't run by itself [09:44] I've a feeling it's plymoyth [09:44] plymouth [09:44] diiiiddrrooock [09:45] or not :p [09:45] +Description: Remove systemd-vconsole-setup.service as it's not shipped in Debian [09:45] but that's different [09:46] Requires=console-setup.service [09:46] it's not [09:46] seb128: so that's what started it [09:46] seb128: i. e. systemd-vconsole-setup.service got previously started, which pulled in console-setup [09:46] http://launchpadlibrarian.net/229422903/plymouth_0.9.0-0ubuntu9_0.9.2-3ubuntu1.diff.gz [09:47] the diff has [09:47] ++After=systemd-udev-trigger.service systemd-udevd.service keyboard-setup.service [09:47] seb128: but still, this sounds like an accident [09:47] that's to plymouth-start.service [09:47] IMHO keyboard-configuration should just make sure to run console-setup by itself [09:47] not to rely on plymouth to do it [09:47] yeah [09:48] so, let's just add that enablement symlink to keyboard-configuration [09:48] seb128: thanks for the research [09:48] yw! [09:58] hallyn, we cannot drop it from main... (a) we need it in main for 14.04->16.04 upgrades (b) desktop user session uses upstart, and nobody ported that to systemd yet (c) phone uses upstart, both as pid 1 and in the user session, and nobody has ported that to systemd yet [10:38] infinity: Any ideas about the "Unknown symbol mcount (err 0)" in the powerpc boot log (http://paste.ubuntu.com/14430284/)? [10:53] pitti, ruby2.3 ... it doesn't even test with ruby2.3, it's all run with 2.2 ... [10:54] so, wasting resources [10:54] rbasak, do we ship cloud-archive on the server iso? [11:00] infinity, hi, upstream seems to be working on endianess thanks to you https://github.com/arrayfire/arrayfire/issues/1055 [11:01] if you could force it to release I'll be so happy [11:05] doko: ah, because of ruby-defaults [11:05] doko: ack, I'll force-skiptest ist [11:06] doko: they haven't started running on armhf yet, so I'll drop them from the queue (and the other arches are already done) [11:08] smoser: would you be able to merge open-iscsi? I know very little about it, I wouldn't know how to sensibly test it [11:14] xnox: AFAIK, no. Stuff on the server iso is seeded entirely separately, although there is overlap of course. [11:14] Actually the cloud-archive has nothing to do with seeds either I think. [11:14] It's completely independant and online only unless I'm mistaken. [11:20] yofel, seems that kdepimlibs is preventing boost-defaults from migrating [11:22] LocutusOfBorg1: sorry, I won't get to looking into the test failures before tomorow [11:22] you'll have to temporarily override it if you need boost to migrate [11:28] yofel, LocutusOfBorg1: you mean kdepimlibs? [11:28] yes [11:29] done [11:29] thanks === _salem is now known as salem_ [11:42] thanks [11:49] cjwatson, could you have a look at a proposed merge? http://paste.ubuntu.com/14437303/ I left three FIXME's in the changelog [11:50] doko: "Install a suspend.d symlink to also call the pm-utils hook on" -> that doesn't actually exist in the debian/rules delta any more, and it's also obsolete [11:50] so the changelog entry can be dropped [11:51] ta [11:51] --noscripts --onlyscripts? that sounds contradictory [11:51] yes, that's a change I found there ... [11:52] doko: hm, does the .deb actually ship an init.d script? current version doesn't [11:52] dunno about the exact details but the original motivation was that udev would run hdparm anyway so the init script wasn't needed [11:52] so it would be a complete no-op [11:52] see changelog for 6.3-3ubuntu1 [11:54] so dropping these too [11:54] just compare file lists and maintscripts before and after, I guess [11:54] doko: so as long as the .deb doesn't actually ship an init.d script, the whole debian/rules delta can be dropped === Chipaca` is now known as Chipaca === ddstreet_away is now known as ddstreet === buxy_bak is now known as buxy [13:25] tdaitx, https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1527685 needs some feedback [13:25] Launchpad bug 1527685 in freeipmi (Ubuntu) "Please merge freeipmi 1.4.11-1 (main) from Debian unstable (main)" [Wishlist,Incomplete] [13:25] doko, yes, I am working on that one =) [13:27] just looking at ooold merges === Wellark_ is now known as Wellark [13:43] ogra_, ping [13:50] cjwatson, doko - so briefly packagekit 0.9.5 existed in wily-proposed which made packagekit-qt to build _and_ migrate (cause it has only alternative depends on the new packagekit...) which makes it now impossible to build. I guess obviously we should move to packagekit 1.0.11, but before that becomes a viable option, what should I do? [13:50] surely packagekit-qt should be downgraded too, no? [13:50] tdaitx, o/ [13:50] er, I don't know, sorry. perhaps. [13:51] kickinz1, o/ [13:51] tdaitx, I'm finalizing the merge of freeipmi right now. [13:51] xnox, ask seb128 or the desktop cabal ... something isn't yet updated for the new packagekit ... [13:51] i mean i could build packagekit 0.9.x in a ppa, build packagekit-qt there for s390x, and copy the lot over to the archive.... to replay how it was built before... [13:51] tdaitx, did we miunderstood the other day? [13:51] doko: click [13:51] tdaitx, (did I misunderstand) [13:51] kickinz1, oh, it seems we did [13:52] cjwatson, only that? but then, this is actively developed. this is more than a year now ... [13:52] really britney should not migrate things, which have unsatisfiable build-depends... [13:52] doko: you say actively developed [13:52] it should be part of the excuses, no? [13:52] doko, snap is active... [13:52] ahh, ok [13:53] doko: but I don't have hardware to test the native-dbus change, and mvo hasn't had time to push it forward; I'd heard that somebody (was it alecu?) was going to pick it up [13:53] xnox, ahh, and apt-daemon [13:54] tdaitx, kickinz1: between you both, who is working on the freeipmi merge? Have you decided? [13:54] ah yes, http://irclogs.ubuntu.com/2015/12/09/%23ubuntu-devel.html#t17:52 [13:55] * xnox files bug #1532197 [13:55] bug 1532197 in packagekit-qt (Ubuntu) "unbuildable packagekit-qt" [High,Triaged] https://launchpad.net/bugs/1532197 [13:55] rbasak, the good news is: there are more merges left ;-P [13:55] doko: yes, and so I'd like to know what I'm reviewing so I don't waste my time! :) [13:56] rbasak, well, I just saw 1527685 ... [13:56] rbasak, thanks for your answer w.r.t. cloud-archive. [14:01] kickinz1, tdaitx, slangasek: can we resolve this exclusively on this channel please, so there's no confusion? [14:01] I don't mind who does the merge or who sponsors it. [14:01] As long as it gets done. [14:01] I just want to know if I'm sponsoring something, and if so exactly what I'm reviewing. [14:02] I also don't want to duplicate review/sponsoring effort with slangasek, since that's a waste of effort and confusing, since different reviewers will always have slight differences in what they want. [14:02] Ok, so I think that with tdaitx, we finally agreed that I will finsh working on this with rbasak for sonsoring this merge. [14:02] rbasak, according to the bug report, the merge is just needing feedback/review [14:04] doko: do you mean Steve's debdiff? [14:05] I'm not clear on what slangasek wanted to happen after posting that, since presumably he didn't upload it himself for a reason. [14:06] rbasak, yes, that one [14:08] tdaitx, can you confirm? [14:08] rbasak, doko: he probably wanted me to check that and provide an update, I just copied and pasted the feedback message and was working on it, but I failed to see the attachment and was doing the changes myself [14:09] OK, I don't mind what happened. It's all clearly just a misunderstanding. Just decide between you who is submitting what and who is sponsoring, and let us all know. [14:09] As long as you both say that you agree to do the same thing, that's fine. Just please tell us what that is. [14:10] rbasak, doko: the changes in the proposed debdiff are just fine [14:10] pitti, i really want to merge that too. [14:10] (open-iscsi that is). [14:10] tdaitx, well, then subscribe -sponsors, or slangasek can upload himself =) [14:11] smoser: I looked at the merge, it doesn't seem particularly complicated; but it's a new upstream version, so some actual testing would be good [14:12] doko, tdaitx: OK, I'm just going to "sponsor" slangasek's merge without review. Given that he's an uploader and he says it's good, it's good. [14:12] And then we'll be done with it. [14:15] rbasak, doko: agreed, go ahead, I will talk to slangasek later on [14:21] ack [14:22] kickinz1, tdaitx: I need to lose power for a while. I will upload when I'm back online. [15:14] doko, kindof pong (i'm on vacation) [15:23] hmm [15:24] where is ocamlopt on ppc64el? [15:24] seems it's not part of ocaml-nox there? [15:26] I think that's something that requires explicit compiler support as opposed to bytecode-type stuff [15:26] So it only exists on some arches [15:27] maybe? [15:27] Package: ocaml-native-compilers [15:27] Architecture: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc sparc [15:28] Yeah, that's it [15:30] It might actually be a packaging bug - I see some ppc64 support in there, so might be worth looking at whether it can be extended if you fancy a weekend project ;-) [15:40] If someone from the MIR team has time, #1531923 is needed for squashfs-tools 4.3 which is in depwait for who knows how long and the upcoming APT 1.2 [15:40] bug #1531923 [15:40] bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New] https://launchpad.net/bugs/1531923 [15:44] juliank, mvo: missing bug subscriber [15:47] doko: mvo: I'd propose to have that handled by the foundations team, but that's not my choice. (but it's subscribed to both apt and squashfs-tools) [15:53] Who decides if foundations could take on lz4 bug subscription? slangasek? [15:53] It's used by two reverse deps (squashfs-tools and soon apt) that are both foundations material [15:54] bdmurray: ^ [16:02] juliank: seems fine to me, I'll subscribe the team [16:02] bdmurray: thanks [16:02] doko: ^ [16:06] smoser: o-iscsi> is that something which you'll actually have time for in the next days, or should we perhaps share the load, and you test my merge in a PPA ? [16:08] pitti, i'd be very happy to have you do the merge ;) [16:10] have you looked at rbasak's "ubuntu logical delta" theory ? https://github.com/basak/ubuntu-git-tools [16:10] i'd love to have a set of logical delta changes that we can look at individually. === LocutusOfBorg1 is now known as LocutusOfBorg === LocutusOfBorg is now known as LocutusOfBorg1 === LocutusOfBorg1 is now known as LocutusOfBorg [17:21] Laney, I did something wrt lp: #1424769 [17:21] Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [High,Triaged] https://launchpad.net/bugs/1424769 [17:21] what do you think about? [17:21] I'm setting up a virtualbox trusty VM to test it right now [17:33] jodh: hey! [17:34] jodh: i know you've moved on, but i think you'll find this very intersting: bug 1530617 [17:34] bug 1530617 in lxc (Ubuntu) "FUSE in wily image with upstart installed causes chaos" [High,Confirmed] https://launchpad.net/bugs/1530617 [17:39] jodh, any advise would be appreciated. it seems like udev, inside the container is causing havoc =) [17:59] cjwatson: ah, hmm. === salem_ is now known as _salem [18:04] LocutusOfBorg: nice, will look soon, thanks! === _salem is now known as salem_ [18:22] slangasek, mind, if I have a look at the shadow merge? [18:25] doko: be my guest [19:00] barry, fyi https://launchpad.net/ubuntu/+source/python-pysam/0.8.4+ds-1 looks like the same thing [19:23] So... like an idiot, I decided to try vmware-view-client:i386 instead of vmware-view-open-client (x64) and right away ran into the fact that pkcs11 support appeared to be non-existent. So I tried to go back, and, oh look, vmware-view-open-client had been pulled from trusty sometime between when I installed it and now... [19:23] Is there any secret repository where I can get this back? ☹ [19:23] 'cause I think I just broke my entire work setup [19:26] you can dig it out from https://launchpad.net/ubuntu/trusty/amd64/vmware-view-open-client [19:26] oh sweet. thanks [19:27] * nemo backs that up [19:35] wooooot. reinstall the .deb from your link, reapply the fixes from https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770 and vmware view works again! ♥ [19:35] Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed] [19:35] * nemo documents this process internally [19:35] cjwatson: thanks. you're awesome [19:35] well. apart from the fact it appears to be you who removed it 😝 [19:36] nemo: it was Debian who removed it, I was just robotically following :) [19:37] I have a feeling the "official" client would work if I was willing to remove all amd64 from all our ubuntu systems and just install i386 [19:37] (and applied the fixes) [19:37] (or package an opensc:i386) [19:37] Would this be a good place to ask about packaging conf files for mysql-server? [19:38] Previously we've packaged a file that changes the bind-address, but I don't believe that is going to work anymore [19:38] or rather, what would be the proper way for another application to change the bind-address of mysql-server [19:44] tgm4883: would debconf(7) help you any? [19:46] sarnold: I don't think so. It's not that I can't make it work. It's that mucking around with other people conf files seems bad [19:46] sarnold: so I'm not sure what the right(tm) way should be [19:47] tgm4883: indeed, that is a bit rough, unless of course that's why they want it :) [19:47] tgm4883: in which case something like ansible or puppet or chef or whatnot might be a decent way to centralize all those sorts of changes.. [19:47] sarnold: if that's the case, that sucks. It defaults to bind-address=127.0.0.1 which makes building anything that depends on mysql-server not really work [19:48] tgm4883: but if it's just one config setting, maybe a dpkg-precofigure command to run first might be tolerable [19:48] sarnold: it's a single configuration change. The issue arrises from there being a new conf directory in mysql-server for cnf files [19:48] sometime between 14.10 and and now [19:49] what we used to do is drop a file in /etc/mysql/conf.d/ and as long as it was read last it works fine. However now there is an additional /etc/mysql/mysql.conf.d/ that gets read after our file [19:50] and there is a mysqld.cnf file in there that sets bind-address to localhost [19:50] Now I could easily drop a file in that directory that gets read after the other file and sets bind-address accordingly [19:50] we currently have a debconf question that asks about that for the old directory [19:51] But my question is, what is the blessed way to do this? [19:51] I suppose at this point, it's less of a technical issue and more of a political one [19:59] I guess it depends in my mind on what you mean by blessed [19:59] it seems odd to me to repackage anything just for a config file change [19:59] you should use a configuration management tool, I'd think [20:00] tgm4883: --^ [20:00] that way, when/if upstream (ubuntu in this case, I suppose) puts out a new version of mysql, you don't need to build your package again; you can just update like normal and the configuration manager handles it [20:00] nacc: wait, you want me to package a configuration management tool to change a setting? [20:01] tgm4883: no, use a configuration management tool to manage your configuration :) [20:02] sarnold mentioned several, ansible, puppet, chef [20:02] nacc: I don't need to manage my configuration, I need a way to manage the configuration of users that install this package [20:02] my configuration already works :) [20:02] tgm4883: so (I assume) you have several systems you have to manage (physical or VM) [20:02] you want to ensure the mysql installation on those systems follow some standard set of rules? [20:02] nacc: let me back up a step and see if this makes more sense. [20:03] tgm4883: sure [20:08] I (Mythbuntu) need to package MythTV (which includes both mythtv-frontend and mythtv-backend packages) for 16.04. These packages can be installed on the same box, or in a distributed setup, but the mythtv-frontend package needs to be able to connect to the mysql-server (mythtv-backend pulls in mysql-server). So if you are in a distributed setup, you need [20:08] mysql to listen on on the private IP address rather than localhost. Previously we've had a debconf question that asks if you are doing a distributed setup and then places a cnf file in /etc/mysql/conf.d/ with the bind-address set to "bind-address=::". However in 16.04 (and probably some other versions after 14.04) there is a second conf directory for cnf [20:08] files at /etc/mysql/mysql.conf.d/ and in this directory exists a file that sets bind-address to "bind-address=127.0.0.1". Since this gets read after the other directory, our setting gets overridden. Now I could easily just drop the file in /etc/mysql/conf.d/ and have it get read after the other file (it seems to be done alphabetically), but I'm not sure if [20:08] this is the "correct" way to do this, and I'd rather not just do it and have the archive admins complain when I push the package to the official repos [20:09] also, I've been shuffled from #ubuntu-server to #ubuntu-app-devel to here [20:10] nacc: sarnold however, yes. If I was just talking about my own network, or my network at work. I would use Puppet (as I do in those cases) [20:12] tgm4883: I wonder if the /etc/mysql/mysql.conf.d/ vs /etc/mysql/conf.d/ represents upstream finally adapting something that debian was doing themselves for ages... that's happened with other .d/ directories. If that's the case then probably moving the file you're setting to the new location is the correct answer [20:12] sarnold: is there anything that explains what that directory is? I know there's hier for the top level directories, but this one's probably owned by mysql [20:13] sarnold: it's odd, as there are cnf files in both directories [20:16] tgm4883: the changelog entries here give me the impression that it's a deliberate change https://launchpad.net/ubuntu/+source/mysql-5.6/5.6.23-0ubuntu1 [20:18] sarnold: so then just moving to that other directory should be fine? [20:21] tgm4883: probably :) [20:27] sarnold: hmm, ok. That fixes one problem and introduces another. We can install it to that other directory, but can I do a .install that is release specific (eg. mythtv-database.install.xenial) ? [20:28] is anything like that doable [20:28] tgm4883: hmm, I think I'd probably approach it with different source packages for different releases, but there may be better ways [20:29] why though, that seems like extra work for little gain [20:30] normally you'd lreesae them every six months or so? :) [20:31] sarnold: we have daily builds that is built from the same packaging [20:31] for supported releases [20:31] ahhh [20:32] they push to out PPA, but it uses the same packaging that we use in the repos [20:32] that makes testing a bit easier [20:33] tgm4883: sorry, didn't realize you were referring to mythbuntu's packaging ... makes more sense now [20:33] nacc: no worries, I didn't want to hit anyone with that wall of text that didn't ask for it ;) [20:34] so yeah, you'd need to put the config file in the right place depending on the release, then? [20:34] yea that's the new problem :) [20:37] * nacc naively assumes mysql itself knows where config files should live ... is there some sort of hook you can call that says your package needs mysql to be reconfigured? [20:38] Looking at https://github.com/dannf/mysql-5.6/commit/61e2b53ddede9a951f9910a027e68edd2a74903a [20:38]