| hallyn | rbasak: have you seen jodh around lately? :) | 00:00 |
|---|---|---|
| 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:01 |
| hallyn | i bet he'd be interested | 00:02 |
| hallyn | cause it's a fascintaing bug | 00:02 |
| 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. | 00:11 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| lamont | how is it that "drop database foo; create database foo;" on current xenial results in a complete restore of the database? | 03:11 |
| stgraber | I don't know the answer to that question either way, but you may want to mention what DB you're using :) | 03:13 |
| lamont | stgraber: heh.. yeah. postgresql 9.4 | 03:14 |
| lamont | renaming the db before droping it doesn't help either | 03:15 |
| lamont | stgraber: sadly, I'm just trying to make a fresh start, and postgrs is being overly helpful, apparently | 03:19 |
| pitti | Good morning | 06:46 |
| sarnold | morning pitti :) | 06:51 |
| 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:52 |
| pitti | sarnold: oh, get well soon then! you seem to be in good company :/ | 06:57 |
| 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 :) | 06:58 |
| 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:13 |
| ubottu | 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:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| didrocks | pitti: ok, I'll prepare this and upload this early next week (don't want to try without doing an upgrade try) | 07:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:37 |
| 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:39 |
| 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:40 | |
| pitti | didrocks: yeah, and takes a second only | 07:41 |
| sladen | Morgen! | 07:53 |
| dholbach | good morning | 07:53 |
| * sladen beat the script! | 07:53 | |
| dholbach | what? no script :) | 07:53 |
| 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:44 |
| pitti | didrocks: \o/ merci! | 08:45 |
| doko | pitti, why does ruby2.3 trigger any autopkg tests at all? it's not yet supported ... | 08:45 |
| pitti | doko: well, britney doesn't know what we consider "supported" | 08:46 |
| pitti | we can override it if we don't care, but seeing what breaks against it is interesting nevertheless, no? | 08:47 |
| doko | well, if somebody addresses these | 08:48 |
| 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:23 |
| 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:24 |
| 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:26 |
| seb128 | so it's not a today update one | 09:27 |
| seb128 | thanks for testing! | 09:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| seb128 | want a bug report? against what component? | 09:31 |
| 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:32 |
| pitti | I'll find out what's supposed to start it | 09:33 |
| seb128 | pitti, danke | 09:36 |
| seb128 | pitti, in fact bug #1531442 seems to be about that issue | 09:37 |
| ubottu | bug 1531442 in keyboard-configuration (Ubuntu) "reboot switches to us keyboard layout on console" [Undecided,New] https://launchpad.net/bugs/1531442 | 09:37 |
| seb128 | assigned it to you | 09:37 |
| pitti | thanks | 09:37 |
| 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:39 |
| 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:40 |
| seb128 | http://launchpadlibrarian.net/227354002/systemd_228-1ubuntu2_228-2ubuntu1.diff.gz doesn't have much though :-/ | 09:41 |
| pitti | *nod* | 09:42 |
| 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:43 |
| seb128 | I've a feeling it's plymoyth | 09:44 |
| seb128 | plymouth | 09:44 |
| seb128 | diiiiddrrooock | 09:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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 | 09:58 |
| Odd_Bloke | infinity: Any ideas about the "Unknown symbol mcount (err 0)" in the powerpc boot log (http://paste.ubuntu.com/14430284/)? | 10:38 |
| doko | pitti, ruby2.3 ... it doesn't even test with ruby2.3, it's all run with 2.2 ... | 10:53 |
| doko | so, wasting resources | 10:54 |
| xnox | rbasak, do we ship cloud-archive on the server iso? | 10:54 |
| LocutusOfBorg1 | infinity, hi, upstream seems to be working on endianess thanks to you https://github.com/arrayfire/arrayfire/issues/1055 | 11:00 |
| LocutusOfBorg1 | if you could force it to release I'll be so happy | 11:01 |
| pitti | doko: ah, because of ruby-defaults | 11:05 |
| pitti | doko: ack, I'll force-skiptest ist | 11:05 |
| 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:06 |
| 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:08 |
| 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:14 |
| LocutusOfBorg1 | yofel, seems that kdepimlibs is preventing boost-defaults from migrating | 11:20 |
| 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:22 |
| pitti | yofel, LocutusOfBorg1: you mean kdepimlibs? | 11:28 |
| yofel | yes | 11:28 |
| pitti | done | 11:29 |
| yofel | thanks | 11:29 |
| === _salem is now known as salem_ | ||
| LocutusOfBorg1 | thanks | 11:42 |
| 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:49 |
| 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:50 |
| doko | ta | 11:51 |
| pitti | --noscripts --onlyscripts? that sounds contradictory | 11:51 |
| doko | yes, that's a change I found there ... | 11:51 |
| 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:52 |
| 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 | 11:54 |
| === Chipaca` is now known as Chipaca | ||
| === ddstreet_away is now known as ddstreet | ||
| === buxy_bak is now known as buxy | ||
| doko | tdaitx, https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1527685 needs some feedback | 13:25 |
| ubottu | Launchpad bug 1527685 in freeipmi (Ubuntu) "Please merge freeipmi 1.4.11-1 (main) from Debian unstable (main)" [Wishlist,Incomplete] | 13:25 |
| tdaitx | doko, yes, I am working on that one =) | 13:25 |
| doko | just looking at ooold merges | 13:27 |
| === Wellark_ is now known as Wellark | ||
| doko | ogra_, ping | 13:43 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| * xnox files bug #1532197 | 13:55 | |
| ubottu | bug 1532197 in packagekit-qt (Ubuntu) "unbuildable packagekit-qt" [High,Triaged] https://launchpad.net/bugs/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:55 |
| doko | rbasak, well, I just saw 1527685 ... | 13:56 |
| xnox | rbasak, thanks for your answer w.r.t. cloud-archive. | 13:56 |
| 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:01 |
| 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:02 |
| rbasak | doko: do you mean Steve's debdiff? | 14:04 |
| 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:05 |
| doko | rbasak, yes, that one | 14:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| tdaitx | rbasak, doko: agreed, go ahead, I will talk to slangasek later on | 14:15 |
| rbasak | ack | 14:21 |
| rbasak | kickinz1, tdaitx: I need to lose power for a while. I will upload when I'm back online. | 14:22 |
| ogra_ | doko, kindof pong (i'm on vacation) | 15:14 |
| dobey | hmm | 15:23 |
| dobey | where is ocamlopt on ppc64el? | 15:24 |
| dobey | seems it's not part of ocaml-nox there? | 15:24 |
| 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:26 |
| 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:27 |
| cjwatson | Yeah, that's it | 15:28 |
| 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:30 |
| 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:40 |
| ubottu | bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New] https://launchpad.net/bugs/1531923 | 15:40 |
| doko | juliank, mvo: missing bug subscriber | 15:44 |
| 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:47 |
| 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:53 |
| juliank | bdmurray: ^ | 15:54 |
| bdmurray | juliank: seems fine to me, I'll subscribe the team | 16:02 |
| juliank | bdmurray: thanks | 16:02 |
| juliank | doko: ^ | 16:02 |
| 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:06 |
| smoser | pitti, i'd be very happy to have you do the merge ;) | 16:08 |
| 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. | 16:10 |
| === LocutusOfBorg1 is now known as LocutusOfBorg | ||
| === LocutusOfBorg is now known as LocutusOfBorg1 | ||
| === LocutusOfBorg1 is now known as LocutusOfBorg | ||
| LocutusOfBorg | Laney, I did something wrt lp: #1424769 | 17:21 |
| ubottu | Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [High,Triaged] https://launchpad.net/bugs/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:21 |
| hallyn | jodh: hey! | 17:33 |
| hallyn | jodh: i know you've moved on, but i think you'll find this very intersting: bug 1530617 | 17:34 |
| ubottu | bug 1530617 in lxc (Ubuntu) "FUSE in wily image with upstart installed causes chaos" [High,Confirmed] https://launchpad.net/bugs/1530617 | 17:34 |
| xnox | jodh, any advise would be appreciated. it seems like udev, inside the container is causing havoc =) | 17:39 |
| dobey | cjwatson: ah, hmm. | 17:59 |
| === salem_ is now known as _salem | ||
| Laney | LocutusOfBorg: nice, will look soon, thanks! | 18:04 |
| === _salem is now known as salem_ | ||
| doko | slangasek, mind, if I have a look at the shadow merge? | 18:22 |
| slangasek | doko: be my guest | 18:25 |
| doko | barry, fyi https://launchpad.net/ubuntu/+source/python-pysam/0.8.4+ds-1 looks like the same thing | 19:00 |
| 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:23 |
| cjwatson | you can dig it out from https://launchpad.net/ubuntu/trusty/amd64/vmware-view-open-client | 19:26 |
| nemo | oh sweet. thanks | 19:26 |
| * nemo backs that up | 19:27 | |
| 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 |
| ubottu | 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 | |
| nemo | cjwatson: thanks. you're awesome | 19:35 |
| nemo | well. apart from the fact it appears to be you who removed it 😝 | 19:35 |
| cjwatson | nemo: it was Debian who removed it, I was just robotically following :) | 19:36 |
| 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:37 |
| 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:38 |
| sarnold | tgm4883: would debconf(7) help you any? | 19:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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 | 19:59 |
| 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:00 |
| nacc | tgm4883: no, use a configuration management tool to manage your configuration :) | 20:01 |
| 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:02 |
| nacc | tgm4883: sure | 20:03 |
| 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:08 |
| tgm4883 | also, I've been shuffled from #ubuntu-server to #ubuntu-app-devel to here | 20:09 |
| 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:10 |
| 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:12 |
| tgm4883 | sarnold: it's odd, as there are cnf files in both directories | 20:13 |
| 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:16 |
| tgm4883 | sarnold: so then just moving to that other directory should be fine? | 20:18 |
| sarnold | tgm4883: probably :) | 20:21 |
| 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:27 |
| 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:28 |
| tgm4883 | why though, that seems like extra work for little gain | 20:29 |
| sarnold | normally you'd lreesae them every six months or so? :) | 20:30 |
| tgm4883 | sarnold: we have daily builds that is built from the same packaging | 20:31 |
| tgm4883 | for supported releases | 20:31 |
| sarnold | ahhh | 20:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| * 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:37 | |
| 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:38 |
| tgm4883 | I don't see one | 20:41 |
| tgm4883 | and nothing in debconf either | 20:41 |
| * tgm4883 blames Daviey | 20:41 | |
| Daviey | tgm4883: entirely my fault. | 20:44 |
| 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:45 |
| tgm4883 | We've got it worked out to a packaging issue that we need to figure out how to fix now | 20:46 |
| 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 | 20:47 |
| Daviey | tgm4883: Hmm.. | 21:06 |
| 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:07 |
| 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:09 |
| 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? | 21:59 |
| dobey | skoe_: i guess #ubuntu-kernel might be a better place to ask | 22:00 |
| tsimonq2 | dobey: 0.0 that exists? woah thanks :D | 22:01 |
| dobey | of course | 22:01 |
| skoe_ | dobey, thanks, I missed that one | 22:01 |
| 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:27 |
| slangasek | Saviq: looking | 23:34 |
| slangasek | Saviq: that's with unity8 as the trigger? | 23:34 |
| slangasek | Saviq: (triggered) | 23:38 |
| Saviq | slangasek, yes, thank you | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!