[00:00] <hallyn> rbasak: have you seen jodh around lately? :)
[00:01] <rbasak> 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] <rbasak> hallyn: :)
[00:02] <hallyn> i bet he'd be interested
[00:02] <hallyn> cause it's a fascintaing bug
[00:11] <rbasak> In fact upstart is still used for user sessions on the desktop too, isn't it? And the system init on the phone too.
[03:11] <lamont> how is it that "drop database foo; create database foo;" on current xenial results in a complete restore of the database?
[03:13] <stgraber> I don't know the answer to that question either way, but you may want to mention what DB you're using :)
[03:14] <lamont> stgraber: heh.. yeah.  postgresql 9.4
[03:15] <lamont> renaming the db before droping it doesn't help either
[03:19] <lamont> stgraber: sadly, I'm just trying to make a fresh start, and postgrs is being overly helpful, apparently
[06:46] <pitti> Good morning
[06:51] <sarnold> morning pitti :)
[06:52] <pitti> hey sarnold, how are you?
[06:52] <sarnold> pitti: not bad, getting over a cold, a little slower than I'd like, but otherwise alright :) how are you?
[06:57] <pitti> sarnold: oh, get well soon then! you seem to be in good company :/
[06:58] <pitti> sarnold: I'm quite fine, fortunately I managed to evade the flu all winter so far :)
[06:58] <sarnold> pitti: too true, half my family got the cold ..
[06:58] <sarnold> pitti: nice nice :)
[07:13] <pitti> 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:15] <pitti> 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] <pitti> mutual Breaks: forces "deconfigure", i. e. I wonder if we can avoid that somehow
[07:17] <didrocks> hey pitti! I'm afraid that's pretty much global, indeed
[07:17] <didrocks> pitti: as most of the themes seems to be copy and paste and they copied a wrong prerm
[07:18] <didrocks> 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] <pitti> didrocks: oh, so that's not just plymouth's prerm, but *all* prerms of logo packages?
[07:18] <didrocks> 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] <didrocks> and most of them are copy/paste :/
[07:18] <pitti> 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] <didrocks> yeah, that would be slightely incorrect, but there is nothing else anyway that should call deconfigure on those packages
[07:19] <pitti> didrocks: oh, ok, I misinterpreted the log, it's indeed not plymouth itself
[07:19] <pitti> didrocks: right, which is how it got unnoticed for so long
[07:19] <didrocks> we should still fix them in xenial though, so that this doesn't happen in the future
[07:19] <didrocks> well, years :p
[07:19] <didrocks> some packages were untouched since 2010/2011…
[07:19] <pitti> didrocks: curiously I had exactly the same case for ifupdown and udev two days ago (mutual Breaks:, missing deconfigure in udev.prerm)
[07:20] <pitti> 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] <didrocks> I don't know why people are doing this *) echo "Call with unknown parameter; exit 1
[07:20] <pitti> didrocks: I had that too; I think that was in some standard templates
[07:20] <pitti> but that's a bit overzealous indeed
[07:20] <didrocks> pitti: as most cases are empty anyway, I would suggest we drop that
[07:21] <didrocks> yeah
[07:21] <didrocks> so yeah, we can workaround and avoid the SRU by removing the Breaks
[07:21] <didrocks> (in plymouth)
[07:21] <pitti> didrocks: oh, in plymouth, not in the logo packages?
[07:21] <didrocks> the Breaks in plymouth against logo packages
[07:21] <pitti> didrocks: you should drop it on the side which has the  Replaces:, not the other one
[07:21] <didrocks> there is no Replaces
[07:22] <didrocks> just Breaks
[07:22] <didrocks> basically, new plymouth needs themes in /usr/share instead of /lib
[07:22] <pitti> Replaces: lubuntu-plymouth-theme, plymouth (<< 0.8.1-1~)
[07:22] <pitti> oh, I see, that's much older, not from this transition
[07:22] <didrocks> yeah
[07:22] <didrocks> the breaks is just to ensure we don't install new logo without new plymouth
[07:22] <didrocks> and vice-versa
[07:23] <pitti> didrocks: that could also become a versioned depends: on the logo (which is simpler)
[07:23] <pitti> i. e. Depends: plymouth + Breaks: plymouth (<< 0.9.2-3ubuntu1~) == Depends: plymouth (>= 0.9.2-3ubuntu1~)
[07:23] <pitti> (was looking at plymouth-theme-lubuntu-logo)
[07:23] <didrocks> but if you upgrade plymouth alone
[07:24] <didrocks> you are in a "broken" situation
[07:24] <didrocks> (for some definition of broken, for sure ;))
[07:24] <pitti> didrocks: yes, that's why I think we should keep the Breaks: on plymouht and drop it from the themes
[07:24] <didrocks> the breaks in plymouth won't force deconfigure in -logo?
[07:24] <pitti> didrocks: only a mutual Breaks: forces that
[07:25] <pitti> didrocks: if it's one-sided, the broken package gets upgraded first
[07:25] <didrocks> oh didn't know that, was thinking one way was enough if plymouth was going to get configured first
[07:25] <didrocks> ok
[07:25] <didrocks> so apt reorders
[07:25] <didrocks> making sense
[07:25] <pitti> 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] <didrocks> I can handle it then
[07:25] <didrocks> indeed
[07:26] <didrocks> we should maybe at some point scan the archive to see if this broken template is used elsewhere
[07:26] <pitti> didrocks: I *think*, plymouth breaks: theme (<< version) and theme Depends: plymouth (>= version) should work
[07:26] <didrocks> yeah, worth a try anyway :)
[07:27] <didrocks> pitti: ok, I'll prepare this and upload this early next week (don't want to try without doing an upgrade try)
[07:28] <didrocks> well, first, let me check how many themes are concerned
[07:28] <pitti> didrocks: right, it should happen 50% of the time on upgrades depending on the order that apt picks
[07:29] <pitti> didrocks: I put the IRC conversation into the bug for reference
[07:29] <didrocks> thanks!
[07:29] <pitti> didrocks: thanks to you!
[07:29] <didrocks> thanks for looking and finding a way not breaking partial upgrades :)
[07:30] <didrocks> pitti: I keep the mutual breaks in the ones that are not impacted, anything against it?
[07:30] <pitti> didrocks: technically not, but aesthetically a versioned depends: is clearer
[07:30] <pitti> didrocks: but no need to upload just for that, just if you have to touch a package anyway
[07:31] <didrocks> yeah, some will need to replace harcoded 15.10 to 16.04 anyway
[07:31] <pitti> didrocks: ah, so not all themes are affected?
[07:31] <didrocks> no, there is basically 2 templates that were used
[07:31] <pitti> didrocks: e. g. plymouth-theme-ubuntu-{logo,text}.prerm seem fine
[07:33] <didrocks> pitti: yeah, the one based on the xubuntu theme are the ones to blame
[07:33] <didrocks> they all contains something like http://paste.ubuntu.com/14436235/
[07:33] <pitti> didrocks: ok, so can you handle that? you probably still have the most context in your head
[07:34] <pitti> didrocks: yeah, let's just drop that completely
[07:34] <didrocks> pitti: yeah, and I have the list! So, preparing, doing an ugprade testing, and uploading :-)
[07:34] <didrocks> +1
[07:34] <pitti> didrocks: merci beaucoup !
[07:34] <didrocks> pitti: mais de rien :-)
[07:35] <pitti> 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] <pitti> (I'd still drop it on the themes side, though)
[07:37] <didrocks> 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] <pitti> (schroot should suffice)
[07:39] <didrocks> yeah, but easier to use a snapshot for multiple runs
[07:39] <didrocks> (I'm not on btrfs here :p)
[07:39] <didrocks> well, should mount my schroot on tmpfs, yeah
[07:39] <didrocks> (had to revert that recently as not enough RAM)
[07:39] <pitti> didrocks: so, I started a wily schroot, and this reproduces it:
[07:39] <pitti> apt install plymouth-theme-lubuntu-logo
[07:39] <pitti> <change sources.list>
[07:40] <pitti> apt update
[07:40] <pitti> apt install plymouth-theme-lubuntu-logo
[07:40] <didrocks> ah, quite easy indeed!
[07:40] <didrocks> thanks for looking
[07:40]  * pitti puts that into the bug
[07:41] <pitti> didrocks: yeah, and takes a second only
[07:53] <sladen> Morgen!
[07:53] <dholbach> good morning
[07:53]  * sladen beat the script!
[07:53] <dholbach> what? no script :)
[08:44] <didrocks> 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] <didrocks> pitti: uploading now :)
[08:45] <pitti> didrocks: \o/ merci!
[08:45] <doko> pitti, why does ruby2.3 trigger any autopkg tests at all? it's not yet supported ...
[08:46] <pitti> doko: well, britney doesn't know what we consider "supported"
[08:47] <pitti> we can override it if we don't care, but seeing what breaks against it is interesting nevertheless, no?
[08:48] <doko> well, if somebody addresses these
[09:23] <seb128> hum
[09:23] <seb128> since before holidays consoles are in qwerty layout on my xenial
[09:23] <seb128> unsure when it started but it was not like that in wily or earlier in the cycle
[09:23] <seb128> didrocks, ^ did you notice that as well?
[09:24] <seb128> pitti, is that a systemd thing?
[09:24] <seb128> /etc/default/keyboard is pc105/fr/oss
[09:24] <seb128> that used to work
[09:26] <pitti> console-setup presumably?
[09:26] <seb128> that didn't change since wily
[09:26] <didrocks> seb128: it's still azerty here
[09:26] <seb128> :-(
[09:26] <didrocks> (I didn't update since yesterday morning)
[09:26] <seb128> I had the issue before holidays
[09:27] <seb128> so it's not a today update one
[09:27] <seb128> thanks for testing!
[09:28] <pitti> seb128: did "systemctl status console-setup.service" run? if you run it manually, does it fix the layout?
[09:28] <pitti> seb128: I think that's what sets the layout (it calls loadkeys)
[09:28] <seb128>    Active: inactive (dead)
[09:29] <pitti> oh: sudo journalctl -u console-setup
[09:29] <seb128> yes, that fixes it
[09:29] <pitti> it does run for me
[09:29] <seb128> déc. 11 08:43:11 seb-e6410 loadkeys[311]: Chargement de /etc/console-setup/cache
[09:29] <seb128> -- Reboot --
[09:29] <seb128> janv. 08 10:29:02 seb-e6410 systemd[1]: Starting Set console keymap...
[09:30] <pitti> seb128: ah, that's just from right now
[09:30] <seb128> so no mention between decembre when the issue started and my manual start
[09:30] <pitti> oh, hang on
[09:30] <pitti> Dez 09 08:26:53 donald systemd[1]: Started Set console keymap.
[09:30] <pitti> that's my last entry
[09:30] <pitti> so indeed it doesn't get run any more
[09:31] <seb128> want a bug report? against what component?
[09:32] <pitti> hmm, 228-1ubuntu2 landed on Nov 23 (too early), -2ubuntu1 o Dec 12 (too late)
[09:32] <pitti> seb128: it's shipped by keyboard-configuration, so against that, but please assign to me
[09:33] <pitti> I'll find out what's supposed to start it
[09:36] <seb128> pitti, danke
[09:37] <seb128> pitti, in fact bug #1531442 seems to be about that issue
[09:37] <seb128> assigned it to you
[09:37] <pitti> thanks
[09:39] <seb128> pitti, "-2ubuntu1 o Dec 12 (too late)"
[09:39] <seb128> pitti, are you sure?
[09:39] <seb128> my last valid run is from dec 11
[09:39] <seb128> so that would pretty much match
[09:39] <seb128> yours is 09 and you maybe didn't reboot or installed the new systemd before upload to test it?
[09:40] <pitti> 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] <pitti> seb128: I do reboot every day, but local dpkg -i sounds plausible
[09:40] <pitti> seb128: so indeed that one is the most probable culprit indeed
[09:41] <seb128> http://launchpadlibrarian.net/227354002/systemd_228-1ubuntu2_228-2ubuntu1.diff.gz doesn't have much though :-/
[09:42] <pitti> *nod*
[09:43] <pitti> seb128: anyway, I'll check on wily what's supposed to depend on console-setup.service, apparently that's now missing
[09:43] <seb128> danke
[09:43] <pitti> it's a static service (no [Install] section), so it doesn't run by itself
[09:44] <seb128> I've a feeling it's plymoyth
[09:44] <seb128> plymouth
[09:44] <seb128> diiiiddrrooock
[09:45] <seb128> or not :p
[09:45] <seb128> +Description: Remove systemd-vconsole-setup.service as it's not shipped in Debian
[09:45] <seb128> but that's different
[09:46] <pitti> Requires=console-setup.service
[09:46] <pitti> it's not
[09:46] <pitti> seb128: so that's what started it
[09:46] <pitti> seb128: i. e. systemd-vconsole-setup.service got previously started, which pulled in console-setup
[09:46] <seb128> http://launchpadlibrarian.net/229422903/plymouth_0.9.0-0ubuntu9_0.9.2-3ubuntu1.diff.gz
[09:47] <seb128> the diff has
[09:47] <seb128> ++After=systemd-udev-trigger.service systemd-udevd.service keyboard-setup.service
[09:47] <pitti> seb128: but still, this sounds like an accident
[09:47] <seb128> that's to plymouth-start.service
[09:47] <pitti> IMHO keyboard-configuration should just make sure to run console-setup by itself
[09:47] <pitti> not to rely on plymouth to do it
[09:47] <seb128> yeah
[09:48] <pitti> so, let's just add that enablement symlink to keyboard-configuration
[09:48] <pitti> seb128: thanks for the research
[09:48] <seb128> yw!
[09:58] <xnox> 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] <Odd_Bloke> infinity: Any ideas about the "Unknown symbol mcount (err 0)" in the powerpc boot log (http://paste.ubuntu.com/14430284/)?
[10:53] <doko> pitti, ruby2.3 ... it doesn't even test with ruby2.3, it's all run with 2.2 ...
[10:54] <doko> so, wasting resources
[10:54] <xnox> rbasak, do we ship cloud-archive on the server iso?
[11:00] <LocutusOfBorg1> infinity, hi, upstream seems to be working on endianess thanks to you https://github.com/arrayfire/arrayfire/issues/1055
[11:01] <LocutusOfBorg1> if you could force it to release I'll be so happy
[11:05] <pitti> doko: ah, because of ruby-defaults
[11:05] <pitti> doko: ack, I'll force-skiptest ist
[11:06] <pitti> 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] <pitti> 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] <rbasak> xnox: AFAIK, no. Stuff on the server iso is seeded entirely separately, although there is overlap of course.
[11:14] <rbasak> Actually the cloud-archive has nothing to do with seeds either I think.
[11:14] <rbasak> It's completely independant and online only unless I'm mistaken.
[11:20] <LocutusOfBorg1> yofel, seems that kdepimlibs is preventing boost-defaults from migrating
[11:22] <yofel> LocutusOfBorg1: sorry, I won't get to looking into the test failures before tomorow
[11:22] <yofel> you'll have to temporarily override it if you need boost to migrate
[11:28] <pitti> yofel, LocutusOfBorg1: you mean kdepimlibs?
[11:28] <yofel> yes
[11:29] <pitti> done
[11:29] <yofel> thanks
[11:42] <LocutusOfBorg1> thanks
[11:49] <doko> 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] <pitti> 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] <pitti> so the changelog entry can be dropped
[11:51] <doko> ta
[11:51] <pitti> --noscripts --onlyscripts? that sounds contradictory
[11:51] <doko> yes, that's a change I found there ...
[11:52] <pitti> doko: hm, does the .deb actually ship an init.d script? current version doesn't
[11:52] <cjwatson> 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] <pitti> so it would be a complete no-op
[11:52] <cjwatson> see changelog for 6.3-3ubuntu1
[11:54] <doko> so dropping these too
[11:54] <cjwatson> just compare file lists and maintscripts before and after, I guess
[11:54] <pitti> doko: so as long as the .deb doesn't actually ship an init.d script, the whole debian/rules delta can be dropped
[13:25] <doko> tdaitx, https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1527685 needs some feedback
[13:25] <tdaitx> doko, yes, I am working on that one =)
[13:27] <doko> just looking at ooold merges
[13:43] <doko> ogra_, ping
[13:50] <xnox> 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] <xnox> surely packagekit-qt should be downgraded too, no?
[13:50] <kickinz1> tdaitx, o/
[13:50] <cjwatson> er, I don't know, sorry.  perhaps.
[13:51] <tdaitx> kickinz1, o/
[13:51] <kickinz1> tdaitx, I'm finalizing the merge of freeipmi right now.
[13:51] <doko> xnox, ask seb128 or the desktop cabal ... something isn't yet updated for the new packagekit ...
[13:51] <xnox> 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] <kickinz1> tdaitx, did we miunderstood the other day?
[13:51] <cjwatson> doko: click
[13:51] <kickinz1> tdaitx, (did I misunderstand)
[13:51] <tdaitx> kickinz1, oh, it seems we did
[13:52] <doko> cjwatson, only that? but then, this is actively developed. this is more than a year now ...
[13:52] <xnox> really britney should not migrate things, which have unsatisfiable build-depends...
[13:52] <cjwatson> doko: you say actively developed
[13:52] <xnox> it should be part of the excuses, no?
[13:52] <xnox> doko, snap is active...
[13:52] <doko> ahh, ok
[13:53] <cjwatson> 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] <doko> xnox, ahh, and apt-daemon
[13:54] <rbasak> tdaitx, kickinz1: between you both, who is working on the freeipmi merge? Have you decided?
[13:54] <cjwatson> ah yes, http://irclogs.ubuntu.com/2015/12/09/%23ubuntu-devel.html#t17:52
[13:55]  * xnox files bug #1532197
[13:55] <doko> rbasak, the good news is: there are more merges left ;-P
[13:55] <rbasak> doko: yes, and so I'd like to know what I'm reviewing so I don't waste my time! :)
[13:56] <doko> rbasak, well, I just saw 1527685 ...
[13:56] <xnox> rbasak, thanks for your answer w.r.t. cloud-archive.
[14:01] <rbasak> kickinz1, tdaitx, slangasek: can we resolve this exclusively on this channel please, so there's no confusion?
[14:01] <rbasak> I don't mind who does the merge or who sponsors it.
[14:01] <rbasak> As long as it gets done.
[14:01] <rbasak> I just want to know if I'm sponsoring something, and if so exactly what I'm reviewing.
[14:02] <rbasak> 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] <kickinz1> 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] <doko> rbasak, according to the bug report, the merge is just needing feedback/review
[14:04] <rbasak> doko: do you mean Steve's debdiff?
[14:05] <rbasak> 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] <doko> rbasak, yes, that one
[14:08] <kickinz1> tdaitx, can you confirm?
[14:08] <tdaitx> 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] <rbasak> 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] <rbasak> 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] <tdaitx> rbasak, doko: the changes in the proposed debdiff are just fine
[14:10] <smoser> pitti, i really want to merge that too.
[14:10] <smoser> (open-iscsi that is).
[14:10] <doko> tdaitx, well, then subscribe -sponsors, or slangasek can upload himself =)
[14:11] <pitti> 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] <rbasak> 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] <rbasak> And then we'll be done with it.
[14:15] <tdaitx> rbasak, doko: agreed, go ahead, I will talk to slangasek later on
[14:21] <rbasak> ack
[14:22] <rbasak> kickinz1, tdaitx: I need to lose power for a while. I will upload when I'm back online.
[15:14] <ogra_> doko, kindof pong (i'm on vacation)
[15:23] <dobey> hmm
[15:24] <dobey> where is ocamlopt on ppc64el?
[15:24] <dobey> seems it's not part of ocaml-nox there?
[15:26] <cjwatson> I think that's something that requires explicit compiler support as opposed to bytecode-type stuff
[15:26] <cjwatson> So it only exists on some arches
[15:27] <cjwatson> maybe?
[15:27] <cjwatson> Package: ocaml-native-compilers
[15:27] <cjwatson> Architecture: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc sparc
[15:28] <cjwatson> Yeah, that's it
[15:30] <cjwatson> 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] <juliank> 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] <juliank> bug #1531923
[15:44] <doko> juliank, mvo: missing bug subscriber
[15:47] <juliank> 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] <juliank> Who decides if foundations could take on lz4 bug subscription? slangasek?
[15:53] <juliank> It's used by two reverse deps (squashfs-tools and soon apt) that are both foundations material
[15:54] <juliank> bdmurray: ^
[16:02] <bdmurray> juliank: seems fine to me, I'll subscribe the team
[16:02] <juliank> bdmurray: thanks
[16:02] <juliank> doko: ^
[16:06] <pitti> 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] <smoser> pitti, i'd be very happy to have you do the merge ;)
[16:10] <smoser> have you looked at rbasak's "ubuntu logical delta" theory  ? https://github.com/basak/ubuntu-git-tools
[16:10] <smoser> i'd love to have a set of logical delta changes that we can look at individually.
[17:21] <LocutusOfBorg> Laney, I did something wrt lp: #1424769
[17:21] <LocutusOfBorg> what do you think about?
[17:21] <LocutusOfBorg> I'm setting up a virtualbox trusty VM to test it right now
[17:33] <hallyn> jodh: hey!
[17:34] <hallyn> jodh: i know you've moved on, but i think you'll find this very intersting: bug 1530617
[17:39] <xnox> jodh, any advise would be appreciated. it seems like udev, inside the container is causing havoc =)
[17:59] <dobey> cjwatson: ah, hmm.
[18:04] <Laney> LocutusOfBorg: nice, will look soon, thanks!
[18:22] <doko> slangasek, mind, if I have a look at the shadow merge?
[18:25] <slangasek> doko: be my guest
[19:00] <doko> barry, fyi https://launchpad.net/ubuntu/+source/python-pysam/0.8.4+ds-1  looks like the same thing
[19:23] <nemo> 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] <nemo> Is there any secret repository where I can get this back? ☹
[19:23] <nemo> 'cause I think I just broke my entire work setup
[19:26] <cjwatson> you can dig it out from https://launchpad.net/ubuntu/trusty/amd64/vmware-view-open-client
[19:26] <nemo> oh sweet. thanks
[19:27]  * nemo backs that up
[19:35] <nemo> 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]  * nemo documents this process internally
[19:35] <nemo> cjwatson: thanks. you're awesome
[19:35] <nemo> well. apart from the fact it appears to be you who removed it 😝
[19:36] <cjwatson> nemo: it was Debian who removed it, I was just robotically following :)
[19:37] <nemo> 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] <nemo> (and applied the fixes)
[19:37] <nemo> (or package an opensc:i386)
[19:37] <tgm4883> Would this be a good place to ask about packaging conf files for mysql-server?
[19:38] <tgm4883> Previously we've packaged a file that changes the bind-address, but I don't believe that is going to work anymore
[19:38] <tgm4883> or rather, what would be the proper way for another application to change the bind-address of mysql-server
[19:44] <sarnold> tgm4883: would debconf(7) help you any?
[19:46] <tgm4883> 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] <tgm4883> sarnold: so I'm not sure what the right(tm) way should be
[19:47] <sarnold> tgm4883: indeed, that is a bit rough, unless of course that's why they want it :)
[19:47] <sarnold> 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] <tgm4883> 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] <sarnold> tgm4883: but if it's just one config setting, maybe a dpkg-precofigure command to run first might be tolerable
[19:48] <tgm4883> 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] <tgm4883> sometime between 14.10 and and now
[19:49] <tgm4883> 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] <tgm4883> and there is a mysqld.cnf file in there that sets bind-address to localhost
[19:50] <tgm4883> Now I could easily drop a file in that directory that gets read after the other file and sets bind-address accordingly
[19:50] <tgm4883> we currently have a debconf question that asks about that for the old directory
[19:51] <tgm4883> But my question is, what is the blessed way to do this?
[19:51] <tgm4883> I suppose at this point, it's less of a technical issue and more of a political one
[19:59] <nacc> I guess it depends in my mind on what you mean by blessed
[19:59] <nacc> it seems odd to me to repackage anything just for a config file change
[19:59] <nacc> you should use a configuration management tool, I'd think
[20:00] <nacc> tgm4883: --^
[20:00] <nacc> 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] <tgm4883> nacc: wait, you want me to package a configuration management tool to change a setting?
[20:01] <nacc> tgm4883: no, use a configuration management tool to manage your configuration :)
[20:02] <nacc> sarnold mentioned several, ansible, puppet, chef
[20:02] <tgm4883> 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] <tgm4883> my configuration already works :)
[20:02] <nacc> tgm4883: so (I assume) you have several systems you have to manage (physical or VM)
[20:02] <nacc> you want to ensure the mysql installation on those systems follow some standard set of rules?
[20:02] <tgm4883> nacc: let me back up a step and see if this makes more sense.
[20:03] <nacc> tgm4883: sure
[20:08] <tgm4883> 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] <tgm4883> 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] <tgm4883> 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] <tgm4883> 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] <tgm4883> also, I've been shuffled from #ubuntu-server to #ubuntu-app-devel to here
[20:10] <tgm4883> 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] <sarnold> 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] <tgm4883> 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] <tgm4883> sarnold: it's odd, as there are cnf files in both directories
[20:16] <sarnold> 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] <tgm4883> sarnold: so then just moving to that other directory should be fine?
[20:21] <sarnold> tgm4883: probably :)
[20:27] <tgm4883> 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] <tgm4883> is anything like that doable
[20:28] <sarnold> tgm4883: hmm, I think I'd probably approach it with different source packages for different releases, but there may be better ways
[20:29] <tgm4883> why though, that seems like extra work for little gain
[20:30] <sarnold> normally you'd lreesae them every six months or so? :)
[20:31] <tgm4883> sarnold: we have daily builds that is built from the same packaging
[20:31] <tgm4883> for supported releases
[20:31] <sarnold> ahhh
[20:32] <tgm4883> they push to out PPA, but it uses the same packaging that we use in the repos
[20:32] <tgm4883> that makes testing a bit easier
[20:33] <nacc> tgm4883: sorry, didn't realize you were referring to mythbuntu's packaging ... makes more sense now
[20:33] <tgm4883> nacc: no worries, I didn't want to hit anyone with that wall of text that didn't ask for it ;)
[20:34] <nacc> so yeah, you'd need to put the config file in the right place depending on the release, then?
[20:34] <tgm4883> 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] <tgm4883> Looking at https://github.com/dannf/mysql-5.6/commit/61e2b53ddede9a951f9910a027e68edd2a74903a
[20:38] <tgm4883> maybe I can just call update-alternatives and pass it some parameters
[20:38] <tgm4883> I wonder if there is a $MYSQL_CONF_DIR or similiar
[20:41] <tgm4883> I don't see one
[20:41] <tgm4883> and nothing in debconf either
[20:41]  * tgm4883 blames Daviey
[20:44] <Daviey> tgm4883: entirely my fault.
[20:45] <tgm4883> Daviey: glad you are taking the blame. I'm assigning this bug to you
[20:45] <Daviey> tgm4883: which bug?
[20:45] <tgm4883> Daviey: the one I'm about to file for getting mythbackend working in 16.04
[20:46] <tgm4883> We've got it worked out to a packaging issue that we need to figure out how to fix now
[20:47] <tgm4883> Daviey: basically, we need to change where mythtv.cfg gets installed. But then how do we do that for 16.04 and yet have a different location for 14.04
[20:47] <tgm4883> I thought we could do something like mythtv-database.install.xenial but I can't find any documentation on that
[21:06] <Daviey> tgm4883: Hmm..
[21:07] <Daviey> Why not install it to the same place and add a compatibility symlink?
[21:07] <tgm4883> so install it in the old location and if the new location exists symlink it there?
[21:09] <tgm4883> Daviey: That might work. on 16.04 it would be getting read twice, as mysql looks in both directories. As long as the mythtv.cnf file gets read last it should work
[21:59] <skoe_> Hi, I want to debug an alsa issue (for the first time) on Xenial Xerus. https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS seems to be the wrong way - at least I don't see a DKMS package there. Can somebody give me a pointer?
[22:00] <dobey> skoe_: i guess #ubuntu-kernel might be a better place to ask
[22:01] <tsimonq2> dobey: 0.0 that exists? woah thanks :D
[22:01] <dobey> of course
[22:01] <skoe_> dobey, thanks, I missed that one
[23:27] <Saviq> slangasek, 'tis me again... can I ask for a restart of the failed run http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/armhf/, and /me files bug for flaky test
[23:34] <slangasek> Saviq: looking
[23:34] <slangasek> Saviq: that's with unity8 as the trigger?
[23:38] <slangasek> Saviq: (triggered)
[23:38] <Saviq> slangasek, yes, thank you