| bluesabre | Please approve the above blueman upload. Fixes a crash on first login for systems without bluetooth | 00:59 |
|---|---|---|
| cyphermox | bluesabre: thanks! :) | 02:02 |
| bluesabre | cyphermox: np, glad to be able to help with some of these things :) | 02:02 |
| === marlinc_ is now known as marlinc | ||
| === xnox_ is now known as xnox | ||
| === stokachu_ is now known as stokachu | ||
| === stgraber_ is now known as stgraber | ||
| === maclin1 is now known as maclin | ||
| jamespage | hey arges - could we get the keystone upload associated with bug 1559935 accepted into wily-proposed alongside the nova update pls ? | 12:07 |
| ubot5` | bug 1559935 in keystone (Ubuntu Wily) "[SRU] nova 12.0.2, keystone 8.1.0" [Medium,Triaged] https://launchpad.net/bugs/1559935 | 12:07 |
| arges | jamespage: sure | 12:22 |
| arges | jamespage: didn't see that yesterday as I usually try to keep those together | 12:23 |
| === fabo_ is now known as fabo | ||
| === enyc_ is now known as enyc | ||
| === _bjf is now known as bjf | ||
| xnox | infinity, i think my s390-zfcp and s390-dasd uploads should have been held in the queue, instead of auto-accepted. They are priority-standard d-i things. | 13:26 |
| xnox | and thus totally affect images =) | 13:26 |
| cyphermox | flexiondotorg: do MATE installs have software-center or gnome-software? it's not immediately obvious in the seed? if it's gnome-software, you may want to update your slideshow | 13:50 |
| teward | any chance I can get https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1563393 reviewed for a freeze exception approval? | 15:06 |
| ubot5` | Launchpad bug 1563393 in nginx (Ubuntu) "[FreezeException Needed] Update nginx to 1.9.13." [Wishlist,Confirmed] | 15:06 |
| stokachu | rbasak: ping | 15:16 |
| rbasak | Skuggen: pong | 15:16 |
| rbasak | Sorry | 15:16 |
| rbasak | stokachu: pong | 15:16 |
| stokachu | rbasak: hey so we've finish the juju ffe for 2.0 here: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913 | 15:17 |
| ubot5` | Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] | 15:17 |
| stokachu | and we have packages uploaded for conjure, bigdata, just needing an archive admin to review | 15:17 |
| rbasak | I have NFI what is going on. | 15:17 |
| stokachu | anyone you know of that has some time to get these pushed forward | 15:17 |
| stokachu | heh | 15:17 |
| rbasak | Are all the Juju-related FFEs approved? | 15:17 |
| stokachu | ok | 15:17 |
| stokachu | well we're trying to get the FFe's approved | 15:17 |
| rbasak | I edited the description in bug 1545913 to link to them. | 15:17 |
| rbasak | Well, you can't really upload and ask for AA approval without FFEs approved. | 15:17 |
| stokachu | feedback was given by security team and those were incorporated | 15:18 |
| stokachu | my packages aren't installed by default and are new so they didn't need FFes | 15:18 |
| stokachu | juju 2 is the one that needs the FFe approval | 15:18 |
| rbasak | IMHO, all of these packages need to be considered for FFe as a whole. | 15:19 |
| rbasak | infinity: ^ | 15:19 |
| rbasak | I summarised in the description of the main Juju FFe bug 1545913. | 15:20 |
| ubot5` | bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] https://launchpad.net/bugs/1545913 | 15:20 |
| rbasak | Going in uncoordinated is crazy, and giving half the release team half the information isn't helpful either. | 15:20 |
| stokachu | doing best i can with what ive got | 15:20 |
| rbasak | Sure, nothing against your work. | 15:20 |
| stokachu | i think that FFe summarizes everything though | 15:20 |
| infinity | xnox: Ahh, hrm. seeded-in-ubuntu (which is what drives the bot) doesn't know about udebs. | 15:20 |
| jcastro | I am in the same boat as stokachu with the accompanying charm-tools | 15:21 |
| xnox | infinity, brilliant! | 15:21 |
| rbasak | The lack of coordination suggests that we're not ready for an FFe to me though. | 15:21 |
| stokachu | rbasak: what else is missing from that FFe bug though? | 15:22 |
| stokachu | i see the links to the packaging in the description and what has been done in response to the upgrade path | 15:23 |
| infinity | rbasak: I've handed off juju2 to slangasek, cause he was super keen on joining the discussion. | 15:23 |
| stokachu | ive got packages from juju-qa team uploaded to my ppa for review as well | 15:23 |
| slangasek | <eyebrow> | 15:23 |
| rbasak | slangasek: there just seem to be a growing number of packages impacted and every few days I learn of more. | 15:24 |
| rbasak | I linked all the known ones in the bug. | 15:24 |
| rbasak | There's also MAAS, but that's described in the bug description already though I don't see a bug on it. | 15:25 |
| slangasek | rbasak: thanks | 15:25 |
| rbasak | slangasek: there's also the complication that Juju 2.0 requires mongodb 2.6 and 3.2 to work, but won't have a dependency on those packages because Juju installs them manually. On the server side only, though. | 15:25 |
| rbasak | But, AIUI, Juju 2.0 beta3 will be unusable to deploy Xenial until those are in. | 15:26 |
| slangasek | rbasak: "until those are in" - I haven't seen any upload in NEW for this? | 15:28 |
| rbasak | slangasek: they're blocked on my review feedback. | 15:28 |
| slangasek | ok | 15:28 |
| rbasak | slangasek: I'm interested in your opinion on some of that actually. https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557852/comments/6 | 15:29 |
| ubot5` | Launchpad bug 1557852 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb3.2 in xenial, wily, and trusty" [Wishlist,Incomplete] | 15:29 |
| jamespage | bug 1546776 for all of those NEW packages | 16:23 |
| ubot5` | bug 1546776 in charm-tools (Ubuntu) "[FFe] charm-tools 2.0" [Undecided,Triaged] https://launchpad.net/bugs/1546776 | 16:23 |
| bdmurray | any guesses on why the walinuxagent diff is using 2.1.2-0ubuntu1~14.04.2? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 | 16:34 |
| infinity | bdmurray: Because LP isn't smart. | 16:36 |
| infinity | bdmurray: Just diff by hand. | 16:36 |
| infinity | 2.1.2-0ubuntu1~14.04.2 was in proposed and then deleted, and LP will forever consider it the "last upload" now, because of the higher version. | 16:36 |
| bdmurray | okay, I didn't see 2.1.2 for Trusty anywhere hence the confusion | 16:37 |
| flocculant | cyphermox: what's the current state on upgrading from 14.04? | 17:01 |
| cyphermox | flocculant: very close to fixed | 17:09 |
| flocculant | cyphermox: nice one :) | 17:09 |
| cyphermox | I know exactly what fails, I'm just figuring out the correct way to fix it | 17:09 |
| flocculant | even better :p | 17:09 |
| flocculant | I did see the upgrade getting compix removed - which was good - I know we don't have that :) | 17:10 |
| cyphermox | flocculant: well, the compiz crash I think was because of an issue in dbus | 17:11 |
| flocculant | yea - wouldn't know, I just know that compiz wouldn't affect xubuntu upgrade failing :) | 17:12 |
| cyphermox | the dbus-daemon-launch-helper lost its setuid bit when extracting, and the postinst wouldn't fix it until very late | 17:12 |
| cyphermox | I still haven't managed to successfully build a source tarball for ubuntu-release-upgrader though, I keep getting incoherent hash sums from the archive | 17:12 |
| infinity | cyphermox: Moving that dpkg-statoverride from postinst to preinst (or, keeping it in both) would likely do the trick? | 17:16 |
| cyphermox | infinity: not according to changelog | 17:16 |
| infinity | cyphermox: Pointer? | 17:17 |
| cyphermox | - preinst: partially revert change from 1.9.4-2. It seems that the | 17:17 |
| cyphermox | preinst is too late to add a useful dpkg-statoverride entry: dpkg has | 17:17 |
| cyphermox | already loaded the statoverride database by this point, and if we add | 17:17 |
| cyphermox | the entry in the preinst, dpkg-statoverride won't run and have | 17:17 |
| cyphermox | its --update side-effect in the postinst. (Closes: #773107, #773838) | 17:17 |
| cyphermox | that was in 1.9.6-1 | 17:17 |
| infinity | Huh. That seems suboptimal. | 17:18 |
| cyphermox | yeah | 17:19 |
| cyphermox | so my also suboptimal solution for now was in u-r-u | 17:19 |
| cyphermox | except I can't seem to build it ;) | 17:19 |
| infinity | I'm less than pleased with it being hacked around in u-r-u. :/ | 17:19 |
| cyphermox | suggestions? | 17:19 |
| cyphermox | this may be a dpkg bug if statoverride isn't happening at the right time | 17:20 |
| cyphermox | maybe for our interest preinst would be sufficient | 17:21 |
| infinity | It's definitely a dpkg bug, but I can understand exactly why. | 17:21 |
| infinity | statoverride should be loaded/parsed on each unpack, to get the expected behaviour, but it's obviously easier and more efficient to load it once at startup. | 17:22 |
| * infinity ponders. | 17:23 | |
| infinity | A purely dpkg/deb workaround would be to divert --copy the helper binary in preinst and put it back in postinst. But that only works if the old helper works with the newly-unpacked dbus. | 17:25 |
| infinity | Or a more gross hack would be to divert it and replace it with a shell script that does a chmod && exec helper.real. :P | 17:25 |
| infinity | (And then undo that in postinst) | 17:26 |
| infinity | Obviously, version-guarded, so we only do that insanity on upgrade to xenial. | 17:26 |
| infinity | Oh, but the helper is called by users, hence suid, so shell script no workie. | 17:26 |
| infinity | Derp. | 17:27 |
| infinity | Derpity derp. | 17:27 |
| infinity | cyphermox: I'm not against throwing the statoverride in u-r-u (I assume that was the intended hack) as a "fix it today" plan, but if we can fix the apt-get dist-upgrade scenario too, that would be nice. | 17:28 |
| infinity | I'll think about it some more. | 17:28 |
| cyphermox | I kind of expected the issue with u-r-u to be that it unpacks nearly everything and then runs all the postinsts later, in a very different order than dist-upgrade | 17:29 |
| cyphermox | or at least, different enough that it's annoying | 17:29 |
| infinity | Oh, as in maybe people don't hit this bug at all with apt-get? | 17:29 |
| infinity | That would be a pleasant discovery. | 17:29 |
| cyphermox | I don't think they do, but I'll re-test | 17:29 |
| rick_h_ | slangasek: howdy, is there a list of the team's concerns with the juju packages I can go through and make calls on if we can pull/reduce risk there? I'm looking for the list of things to address in #1545913 that I can either put the team on to remove any remaining blocks. | 18:00 |
| stgraber | rick_h_: so the bug now claims that we will have a Juju 2.0 final ready before 16.04 ships, is that correct? That's now what I was told before so that kinda surprises me. | 18:10 |
| rick_h_ | stgraber: yes, we're cutting an RC1 in the next week and solidifying to have juju 2.0 available to users on release day for 16.04. | 18:11 |
| rick_h_ | stgraber: juju 2.0 has to go with maas 2.0, lxd 2.0 as it's built on top of both of those | 18:12 |
| stgraber | both maas and lxd have betas or rcs in the archive right now, so presumably you're not blocked on those | 18:12 |
| rick_h_ | stgraber: no, we're not blocked on that at this time. We didn't put our alpha in because there was some confusion in the 'best path' to get juju2 in and allow side by side installs in trusty/xenial. | 18:13 |
| rick_h_ | stgraber: we've engaged with folks on your team to iron out that upgrade/side by side install process as we try to get juju 2.0 in | 18:14 |
| rick_h_ | stgraber: and my understanding is the team has addressed that path and made changes to the packages to make sure it works smoothly | 18:14 |
| stgraber | so if I read the FFe right, you're basically saying that all existing juju users will be broken by the upgrade as juju will now point to juju2 and juju2 can't talk to juju1 | 18:14 |
| rick_h_ | stgraber: no, when a user upgrades they'll keep juju 1, juju 2 will be installed along side, and juju will be update-alternatives pointed to juju 2 | 18:16 |
| rick_h_ | stgraber: it's all supported in update-alternatives and juju 2 is the higher priority | 18:16 |
| rick_h_ | stgraber: so I don't think they're 'broken' | 18:17 |
| rick_h_ | stgraber: that was some of the good feedback my team got and addressed | 18:18 |
| stgraber | """ | 18:18 |
| stgraber | Users upgrading from trusty will find their juju version updated. The current juju-core package will be provided as juju-1.25. Update-alternatives will provide support for toggling /usr/bin/juju between juju-1.25 and juju-2.0 binaries. | 18:18 |
| stgraber | """ | 18:18 |
| stgraber | I read this as, "juju" will point to version 2 after upgrade. | 18:18 |
| stgraber | and user can change it back to version 1 with update-alternatives | 18:18 |
| rick_h_ | stgraber: yes, it's the higher priority. | 18:18 |
| stgraber | ok, so someone using the juju command will be broken then | 18:18 |
| stgraber | or does juju2 somehow know to call juju1 instead in such case | 18:19 |
| stgraber | oh, I meant to quote: | 18:19 |
| stgraber | """ | 18:19 |
| stgraber | Upgrading Trusty/Wily/old Xenial: | 18:19 |
| stgraber | Already installed juju 1.X, upgraded to latest 1.25.4, 2.0 also installed and is the default juju, update-alternatives used to switch between the two. | 18:19 |
| stgraber | """ | 18:19 |
| rick_h_ | stgraber: what we've talked about doing in response to this is having juju 2.0 detect that you have a juju 1 config directory w/o a juju 2 directory and messaging the update-alternatives command | 18:19 |
| rick_h_ | stgraber: would that be an ok path? Or I can investigate what impact having juju 1 the higher prority would be? | 18:20 |
| stgraber | but juju doesn't run as root so it can't call update-alternatives and changing symlinks under the user like that isn't too good. | 18:21 |
| rick_h_ | stgraber: well we can give the user the copy/paste command to swich if they desire? | 18:22 |
| stgraber | You could probably have your postinst set the alternative to juju1 if it's installed though but then users will still be confused, just the other way around. | 18:22 |
| rick_h_ | stgraber: or we can go the juju 1 higher priority | 18:22 |
| stgraber | I think the best as far as user experience goes would be: | 18:22 |
| stgraber | - If juju1 is detected on installation of juju2, set the alternative to juju1 | 18:23 |
| stgraber | - Patch juju1 to show a one-time message to the user saying something along the lines of "we've noticed you were using juju1, juju1 is incompatible with juju2, when you're ready to switch, run: sudo update-alternatives --config juju" | 18:23 |
| stgraber | or something along those lines | 18:23 |
| rick_h_ | when would that message show to a juju 1 user? | 18:24 |
| stgraber | so don't break folks on upgrade, don't have an unprivileged process mess with systemd-wide settings but still make it easy for the user to figure out how to switch | 18:24 |
| * rick_h_ is thinking of the preferred injection point for a thing | 18:24 | |
| stgraber | first run of the juju command I'd guess, then touch a stamp file and don't show it again | 18:24 |
| rick_h_ | stgraber: ok | 18:25 |
| rick_h_ | stgraber: is that the only remaining concern or are there other ones we can/should address? | 18:25 |
| stgraber | not quite | 18:26 |
| stgraber | I see you list 3 packages that are needed for juju, juju-mongodb3.2, juju-mongodb2.6 and juju-mongo-tools3.2 | 18:27 |
| stgraber | none of which are in the archive yet and I believe all of which received some kind of negative review feedback | 18:27 |
| rick_h_ | stgraber: yes, so the current juju-mongodb in trusty/xenial to date is an old version that is out of support from mongodb. We'd like to get a supported mongodb in and have juju use that. | 18:28 |
| stgraber | before we really consider the juju FFe, we need to have any required dependencies in the archive and if needed, promoted to main. Then we can see how much time we have left after that and consider the risks that come with the new juju. | 18:29 |
| rick_h_ | stgraber: the team's writing up the reply to that negative feedback and filling in the details on the decisions there. | 18:29 |
| rick_h_ | stgraber: so juju can work with the mongodb that's there currently, but it's less than ideal as it's not supported upstream any more. | 18:29 |
| stgraber | I also see in one of those linked bugs a mention that juju 2.0 will be 64-bit only, yet I'm not seeing any mention of that in the Juju FFe | 18:30 |
| rick_h_ | stgraber: so we feel we can go whichever path forward your team would prefer. | 18:30 |
| stgraber | this seems like a rather big change that should have been mentioned with details on your upgrade path for 32bit users going to 16.04 (getting them to juju1 only with some kind of notification I guess) | 18:30 |
| rick_h_ | stgraber: the client tools build on all architectures. THe mongodb case is juju remote's server which is not a package in qustion | 18:31 |
| stgraber | ok | 18:31 |
| rick_h_ | stgraber: so this is something that's a bit of a line in that the juju client does not need mongodb, so it's all archs including 32bit | 18:31 |
| stgraber | ok, so those 3 packages are only needed for the juju server | 18:32 |
| stgraber | might be worth clarifying in the FFe | 18:32 |
| rick_h_ | stgraber: sure thing | 18:32 |
| infinity | stgraber: No need for juju2 to mangle the alternative conditionally, if juju1 is the higher priority it "just works" for upgrades. | 18:32 |
| infinity | (Well, assuming there's also a plan that keeps both packages around.... The last upload I saw was replacing 1 with 2...) | 18:33 |
| stgraber | infinity: true but what happens if someone apt-get install juju1 after the fact? | 18:33 |
| infinity | stgraber: Then juju1 would take priority. *shrug* | 18:33 |
| rick_h_ | infinity: right now we will have juju 1 until trusty EOL's and then we'll remove it from xenial | 18:33 |
| infinity | rick_h_: Err, no you won't. | 18:33 |
| infinity | rick_h_: We don't remove things from xenial. | 18:33 |
| infinity | Not after it's released. | 18:33 |
| rick_h_ | infinity: no? my understanding is that since 1.25 is in universe it can be removed? | 18:34 |
| infinity | Your understanding was incorrect. | 18:34 |
| stgraber | it's impossible to remove a package from the release pocket | 18:34 |
| stgraber | you can SRU an empty one though | 18:34 |
| rick_h_ | stgraber: infinity ok, folks are clarifying me that the package is still there but we can say "it's no longer supported' which is what I was asking them about | 18:35 |
| infinity | We could, in theory, 0-day SRU it to xenial-updates and not actually ship a copy in the release pocket at all. | 18:35 |
| rick_h_ | my apologies for the confusion there | 18:35 |
| infinity | But that would take some fun coordination. | 18:35 |
| stgraber | but then your users may be a bit surprised that a package in main with a 5 years support commitment from Canonical is removed | 18:35 |
| rick_h_ | stgraber: infinity we have a support window that's documented for 1.25 until trusty EOL but it's support specific | 18:35 |
| infinity | rick_h_: So, how does the upgrade get people both versions? | 18:36 |
| rick_h_ | infinity: that's in the juju ffe #1545913 under upgrades and we've tested this as the feedback | 18:37 |
| rick_h_ | we got around those issues | 18:37 |
| rick_h_ | infinity: so there's some metapackage foo that makes it 'just work' and tests well | 18:37 |
| infinity | rick_h_: The upgrade scenario I saw assume the metapackage is installed. | 18:38 |
| infinity | rick_h_: Users with juju-core installed get no upgrade, then? | 18:38 |
| rick_h_ | infinity: yes, all users have the juju metapackage currently | 18:38 |
| infinity | That's a bold statement. | 18:38 |
| infinity | There's nothing requiring them to. | 18:38 |
| rick_h_ | infinity: true, but all of our documentation and practices going back pre-trusty has the juju metapackage. | 18:38 |
| infinity | Also, that package was never actually a metapackage (ie: in section: metapackages) which means its deps are marked auto-installed. | 18:39 |
| rick_h_ | infinity: worst case, if they don't have the metapackage they end up with just juju 1 they were using, and have the option of installing juju2 by installing the metapackage or the juju-2 package | 18:39 |
| infinity | So, assuming they have it installed "apt-get dist-upgrade && apt-get autoremove" will remove juju-core. | 18:39 |
| infinity | And we're enabling autoremove by default. | 18:40 |
| infinity | In unattended-upgrades. | 18:40 |
| infinity | So, you still have a bit of a problem there. | 18:40 |
| rick_h_ | infinity: ok, that's good to know. We weren't aware. | 18:40 |
| infinity | rick_h_: Of which part? Your pastebin clearly shows juju-core as an autoremove candidate. | 18:40 |
| mgz | infinity: I have slightly changed the packaging since then, but am interested if there's a neat way of avoiding that problem | 18:41 |
| rick_h_ | infinity: that we either update the current trusty package and try to fix the section metapackages? | 18:41 |
| rick_h_ | or something else? | 18:41 |
| infinity | It's too late to fix it in trusty. | 18:41 |
| infinity | You can't guarantee all users will be fully-upgraded to trusty-updates before upgrading. | 18:41 |
| rick_h_ | infinity: agreed, hoping that we might not be alone in this and there's a known path that makes it non-fugly for users? | 18:42 |
| infinity | mgz: My best recommendation would be to have the metapackage depend on both until juju-core is EOL. | 18:43 |
| infinity | Unfortunately, you can't write to the apt autoremove database while apt is running, so you can't fix it up in a maintainer script. | 18:43 |
| mgz | infinity: okay, so, for instance, the initial version of the juju 2.0 source package can say, have juju depend on juju-2.0 and recommend juju-1.25 maybe? | 18:44 |
| rick_h_ | infinity: can it depend on both though as one is meant for main and one for universe? | 18:44 |
| * infinity thinks a bit about how best to solve this. | 18:44 | |
| infinity | rick_h_: Oh, nope. Not if the meta is in main. | 18:44 |
| mgz | you can recommend into universe right? | 18:45 |
| infinity | Nope. | 18:45 |
| infinity | Only Suggests. | 18:45 |
| infinity | Which might not be enough to pin it in, I can't recall the mechanics there. | 18:45 |
| mgz | meph, which isn't enough to prevent the autoremove | 18:45 |
| mgz | ...I think | 18:45 |
| mgz | infinity: I'm open to cunning plans | 18:51 |
| infinity | mgz: Suggests is enough to keep it in. | 18:51 |
| mgz | infinity: okay, that is excellent. I can do that. | 18:51 |
| infinity | http://paste.ubuntu.com/15570328/ | 18:51 |
| infinity | ^-- example/proof. | 18:51 |
| mgz | infinity: thank you very much | 18:52 |
| doko | infinity, did you find out more about glibc2.0 on s390x? If not, I'd like to upload a build which doesn't run the tests, so that we can get the package into the release pocket for the test rebuild | 18:52 |
| infinity | mgz: And that's actually appropriate anyway, as a Suggests implies the need for juju1 for transition/upgrade purposes. So, yay for that. | 18:53 |
| mgz | yeah, it's great that it makes sense and actually does what we want :) | 18:53 |
| rick_h_ | stgraber: infinity ok, so we're adding a comment to the FFe on the 32bit question and moving to suggest, and making juju1 the higher update-alternatives priority. | 18:53 |
| infinity | doko: Not yet, no. But if you want to disable for a build, I can revert when I've found something. | 18:53 |
| doko | ok | 18:54 |
| rick_h_ | stgraber: infinity are there other concerns/issues the team needs to address? If not, can I put those notes into the FFe that based on our conversation those are the conditions and upon meeting those it will be acceptable? | 18:55 |
| infinity | doko: (Alternately, disable for a PPA build and make your test depend on that PPA, but I think a bunch of other stuff is also blocked on glib, like gtk...) | 18:55 |
| doko | right | 18:55 |
| infinity | rick_h_: To me, the key points are that juju2 be considered feature-complete and fully-functional by release, because that's the thing you're telling users is the Way and the Light, and that upgrade scenarios don't leave users busted on upgrade. | 18:56 |
| rick_h_ | infinity: understand, we're moving the one feature not complete behind a feature flag that is not enabled by default for release | 18:56 |
| rick_h_ | infinity: juju 2.0 is fully functional, our next release is RC1 with bugfixes from then on. | 18:57 |
| infinity | rick_h_: I haven't reviewed the actual package yet, but apw had some concerns there too, like why is it shipping 250MB of binaries, much of which seem to be duplicated code? (could it be a single binary that switches on argv[0] and cut the install-size in 1/4?) | 18:57 |
| rick_h_ | mgz: do you know the background there? ^ | 18:58 |
| infinity | Given that there are powers that be that want to see juju eventually installed by default on every Ubuntu device, 250MB is pretty huge. | 18:58 |
| infinity | Like, very huge. | 18:58 |
| infinity | Guessing there may also be a lack of stripping. A combination of argv-switching and stripping would help a lot. :P | 18:59 |
| infinity | (If that 250MB is stripped, I'll be both surprised and even more annoyed at Go than before) | 18:59 |
| rick_h_ | infinity: mgz is pulling up the bug on this for reference. one sec | 19:00 |
| mgz | infinity: see https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/8 | 19:00 |
| ubot5` | Launchpad bug 1200255 in golang (Ubuntu) "go get ... fails with SIGILL on armhf" [Undecided,Fix released] | 19:00 |
| mgz | infinity: tldr, upstream golang doesn't support stripped binaries, things break when you do it | 19:01 |
| stgraber | hmm, pretty sure mwhudson said it's all fine and supported now | 19:02 |
| stgraber | except for binaries built with gccgo, those are still busted | 19:03 |
| mgz | it may be something we've made progress on upstream, but it's not been tested by us | 19:03 |
| mgz | I shall ask mwhudson later. | 19:03 |
| infinity | Yeah, I've heard that was sorted, or at least there was a workaround where you could strip mostly, but leave a section intact. | 19:03 |
| infinity | mgz: stripping aside, the 4 binaries that mostly link the same objects thing seems like it would be served better with one binary and 3 hardlinks and argv[0] switching. | 19:04 |
| mgz | infinity: I'm open to filing a bug on that, but thought the way forward was more likely to be shared objects for go | 19:07 |
| infinity | mgz: Sure, libraries would be wonderful, but we're not there yet. | 19:08 |
| infinity | mgz: When most of your binaries are 90% shared static objects, though, the busybox approach makes some sense. | 19:08 |
| rick_h_ | infinity: so to my list you'd like us to add that we argv switch in there as a gate to get the acceptance? | 19:09 |
| infinity | rick_h_: Well, reduce the package size considerably. How that happens is an implementation detail, I'm just suggesting an option. :P | 19:10 |
| infinity | rick_h_: Obviously, sorting out the stripping situation will also help a lot. But even then, you'll still have 4 giant almost-identical binaries. | 19:11 |
| infinity | Just slightly less giant. | 19:11 |
| rick_h_ | infinity: understand | 19:11 |
| rick_h_ | infinity: I'm working to get a list of things that are preventing this so I can get the team to address them and hopefully have a complete action plan | 19:11 |
| rick_h_ | infinity: to date I feel like we've gone back/forth and the lovely manager in me is wanting to get a plan in place | 19:11 |
| infinity | rick_h_: Well, it's not helping that this is all landing very late and (frankly) the default answer from both the Release Team and the Tech Board (if escalated) should be "no". | 19:12 |
| stgraber | rick_h_: would also be useful to have a section in that FFe which highlights how that mess happened in the first place and explaining how you intend to deal with pushing juju to the Ubuntu archive in future releases so that kind of situation doesn't happen again | 19:13 |
| infinity | rick_h_: So, working towards a slightly less violent "no" is a good first step, but it may still warrant a sabdfling if we can't dot every i and cross every t. | 19:13 |
| rick_h_ | infinity: ok, I can add that section and the plan we've put together on our end. | 19:13 |
| infinity | rick_h_: And I understand that there was a belief that the standing SRU exception would let this slide right in, but the SRU exception is predicated on intense regression testing and sane upgrade paths, so that certainly hadn't been met the last time I looked at this. | 19:14 |
| rick_h_ | infinity: understand, we had the mandate that there's not a current upgrade path from a juju1 environment to a juju2 one. However, that's the remote end vs the client that this is about. | 19:15 |
| rick_h_ | infinity: and I think that confused the issue a bit | 19:15 |
| rick_h_ | infinity: which is why the feedback from your end on the upgrades with the packages is <3 and I'm happier we did those updates | 19:16 |
| infinity | rick_h_: Right, the client upgrade path is what's of concern for the distro. ie: I can't upgrade my distro and break my client. | 19:16 |
| infinity | rick_h_: The network upgrade path is something apt obviously can't fix, so that's up to good documentation of migration strategies for the server side. | 19:16 |
| rick_h_ | infinity: definitely | 19:17 |
| rick_h_ | infinity: stgraber so we'll process these items per https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913/comments/14 | 19:20 |
| ubot5` | Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] | 19:20 |
| rick_h_ | infinity: stgraber if there are any other items to add to that list please let me know so I can make sure I'm aware and handling them | 19:21 |
| stgraber | rick_h_: document your plan for the next ubuntu release on how you'll adapt your process so we don't end up in the same situation again | 19:22 |
| rick_h_ | stgraber: right +1 | 19:22 |
| stgraber | rick_h_: we really should have had juju2 alphas or something in xenial way before feature freeze, incremental changes and FFes are far easier for us to review and way easier to get | 19:22 |
| stgraber | most of our other upstreams have figured it out and maas and lxd within Canonical also managed it, so surely Juju could have done it too | 19:22 |
| rick_h_ | stgraber: understand, I think this was a miscommunciation in that we had the feeling an alpha should not go in | 19:23 |
| stgraber | if you intend for the final version to go in, an alpha can absolutely go in | 19:24 |
| infinity | rick_h_: It's a development release, all bets are off. The key is to have something decently final by release. | 19:24 |
| rick_h_ | stgraber: we've had packages and been delivering to stakeholders alphas and betas for months | 19:24 |
| stgraber | rick_h_: right, just not in the Ubuntu archive, which is what matters to us :) | 19:25 |
| rick_h_ | infinity: yes, agree. We've got commercial engagments where my head's on the line so a final will be in for release | 19:25 |
| * rick_h_ steps away for lunch and to assign folks to tasks | 19:25 | |
| infinity | rick_h_: Threat of decapitation isn't my ideal motivator, but whatever works for you. | 19:26 |
| * rick_h_ tosses the obligatory "I'm rather attached to my head" joke | 19:26 | |
| stgraber | speaking of golang stuff, I don't suppose any archive admin is willing to look at those 3 golang-XYZ packages I uploaded back in December? | 19:26 |
| stgraber | they are the only bits left (well, once promoted to main) which we'd need for LXD not to use any bundled sources, so that would make the security team happy (apparently) | 19:27 |
| stgraber | it's not blocking us since we just use the bundled copies when we can't find the source in the archive but it's something we've been asked to do as part of being in main | 19:28 |
| stgraber | a couple of those I uploaded before have since landed in Debian so I've synced them from there instead, but those 3 aren't in Debian and won't be before release (no ITP for them even) | 19:29 |
| infinity | superm1: Why is fwupd arch:any? | 19:35 |
| superm1 | infinity: linux-any IIRC | 19:36 |
| infinity | superm1: Oh, I see. The intent is to someday extend it for non-EFI systems? | 19:36 |
| superm1 | it can support all sorts of firmware flashing types | 19:36 |
| infinity | (Though, that doesn't seem to be the case right now) | 19:36 |
| superm1 | raspberrypi, DFU, colorhug | 19:36 |
| infinity | Hrm. Kay. | 19:36 |
| superm1 | of course the main one I care about is EFI, but i'm also hoping to get other interesting pieces of firmware pushed that route too | 19:36 |
| infinity | GPGME needs this for proper building on i386, armhf, powerpc | 19:41 |
| infinity | ifeq "$(DEB_BUILD_ARCH)" "i386" | 19:41 |
| infinity | export DEB_CFLAGS_MAINT_APPEND = -D_FILE_OFFSET_BITS=64 | 19:41 |
| infinity | superm1: Is "dpkg-architecture -qDEB_HOST_ARCH_BITS" what you're looking for? | 19:41 |
| superm1 | infinity: possibly | 19:42 |
| infinity | superm1: Also, you've confused HOST and BUILD there. HOST is the one you're building *for*, BUILD is the one you're building *on*. | 19:42 |
| ginggs | is there anything wrong with just adding -D_FILE_OFFSET_BITS=64 for all arches? | 19:43 |
| slangasek | mgz, rick_h_: yes, per mwhudson, stripping of go binaries is now supported; we should ASAP start stripping juju binaries to get the install size under control | 19:43 |
| slangasek | ginggs: there is not, it's just superfluous on some archs | 19:43 |
| ginggs | slangasek: thanks, i was pretty sure i've done that in a couple of my packages | 19:44 |
| slangasek | so the usual approach for this is $(shell getconf LFS_CFLAGS) | 19:44 |
| slangasek | but of course that's not cross-friendly, so ymmw | 19:44 |
| slangasek | v | 19:44 |
| superm1 | infinity: dpkg-architecture -qDEB_HOST_ARCH_BITS should return 32 on the ones I was adding the flags? | 19:45 |
| infinity | superm1: Yes. | 19:45 |
| infinity | superm1: And many more, in the case of Debian. | 19:45 |
| infinity | You probably also want -D_LARGEFILE_SOURCE | 19:45 |
| infinity | And, as mentioned, it's not harmful to just unconditionally add both, even on 64-bit arches. | 19:46 |
| infinity | But if you want to conditionalise it, -qDEB_HOST_ARCH_BITS is the way to go. | 19:46 |
| superm1 | ok thanks | 19:46 |
| infinity | superm1: I look forward to your engagement with IBM (if they don't blackhole @dell.com) on making this work for PPC systems too. :) | 19:48 |
| infinity | (They have live firmware updating tools, it would just need to be hooked in and prettified) | 19:48 |
| infinity | superm1: Mostly sarcasm, FWIW. But I might suggest they look at the project and contribute. | 19:49 |
| superm1 | Heh, well if they have specs that are open on this stuff they should definitely participate | 19:50 |
| infinity | superm1: Their firmware updating (and firmware itself) are open, the problem they need to fix is sane distribution channels for their signed firmware images. | 19:51 |
| infinity | superm1: If they can plug that all in reasonably, so there's no manual click-wrapping and shuffling of files, this would all be quite slick. | 19:51 |
| infinity | superm1: I assume fwupd supports the concept of A-side/B-side/Commit somehow? | 19:52 |
| * infinity puts it on his list of things to learn about $later. | 19:53 | |
| superm1 | Anything is possible with the plugin architecture. Even if their stuff doesn't follow standards, it can fit into fwup-provider-ibm or something like that that does any crazy stuff | 19:53 |
| infinity | superm1: Shiny. | 19:54 |
| infinity | superm1: I'll bring it up with Jeremy Kerr when I have a spare few minutes. I'd love to see the fwupd story improve on those machines, given the open nature of both the tools and the firmware. It's a shame they haven't glued the last little bit together to make it stupid-proof. | 19:54 |
| superm1 | And LVFS is open to any OEM. If they would distribute their firmware images though that, it solves a lot of mess too | 19:55 |
| superm1 | Cool | 19:55 |
| Beret | infinity, haha | 20:00 |
| Beret | "Threat of decapitation isn't my ideal motivator, but whatever works for you." | 20:00 |
| mwhudson | mgz: strip go pls | 20:21 |
| mwhudson | mgz: not gccgo tho | 20:21 |
| rick_h_ | mwhudson: how confident are we on that? I'm concernede about sneaky issues that it might expose. | 20:22 |
| infinity | mwhudson: golang vs gccgo, does dh_strip DTRT, or does one need to do conscious debian/rules hackery? | 20:23 |
| infinity | mwhudson: (I assume you meant "strip binaries produced by golang, but not binaries produced by gccgo") | 20:23 |
| mwhudson | rick_h_: the failures we've seen before are of the "process crashes instantly on startup" | 20:23 |
| rick_h_ | mwhudson: ok | 20:23 |
| mwhudson | variety | 20:23 |
| mwhudson | i can't see the scope for subtle breakage | 20:23 |
| mwhudson | infinity: no, no smarts in dh_strip | 20:24 |
| infinity | So some icky ifeq magic on dpkg -S $(readlink /usr/bin/go)? | 20:25 |
| infinity | That might want dh_strip involvement. :P | 20:25 |
| rick_h_ | mgz: ^ for the bug | 20:25 |
| mwhudson | yeah | 20:25 |
| infinity | Can we tell by examining a binary if it's produced by one or the other? | 20:25 |
| mwhudson | probably not stripping binaries linked to libgo.so.X is the right heuristic | 20:25 |
| doko | one has a proper shared lib | 20:25 |
| mwhudson | although there are some gccgo-compiled static things too | 20:26 |
| doko | infinity, depends on libgoN | 20:26 |
| mwhudson | (jujud, dockerinit) | 20:26 |
| infinity | That seems odly backwards that a GCC-produced binary can't be stripped. | 20:26 |
| mwhudson | i've been meaning to pester ian about this for ages | 20:26 |
| doko | infinity, fix libbacktrace | 20:26 |
| mwhudson | it would still seem better to get no tracebacks if there is no debug data | 20:26 |
| infinity | doko: No thanks. It was an observation, not a demand for work. ;) | 20:27 |
| mwhudson | rather than fall over on startup | 20:27 |
| slangasek | mwhudson: in the past, I thought stripped binaries would crash at the first use of go reflection, which is not necessarily at startup | 20:27 |
| mwhudson | slangasek: don't think so? | 20:27 |
| slangasek | mwhudson: hmm, well, at least in one iteration of the bug, it was the reflection info that was disappearing when stripping :) | 20:27 |
| mwhudson | oh maybe you're right | 20:27 |
| mwhudson | uhh | 20:28 |
| * mwhudson is stripping gccgo binaries on his system and things are working | 20:28 | |
| rick_h_ | mwhudson: yea, the big thing is that juju seems to push things a bit and making that change at this point seems potentially risky. | 20:28 |
| slangasek | anyway, at this point we *ought* to be using golang consistently across all architectures in xenial, which means no reason to special-case in the packaging | 20:28 |
| mwhudson | slangasek: except powerpc | 20:29 |
| slangasek | rick_h_: whether or not it fails at startup, it should be the sort of breakage that's easy to regression-test | 20:29 |
| slangasek | mwhudson: oh that old thing | 20:29 |
| infinity | Yeah, except powerpc. But the right answer is special-casing in dh_strip, not in individual packages. | 20:29 |
| infinity | Just as we special-cased golang-go in a metapackage, not in package build-deps. | 20:29 |
| infinity | Packages should be blissfully unaware of their toolchain. | 20:29 |
| slangasek | mwhudson: apt-get install qemu-user-static; apt-get install juju-core:amd64; done | 20:30 |
| slangasek | running amd64 go binaries under qemu-user-x86, should work GREAT | 20:30 |
| mwhudson | slangasek: i bet juju tickles no bugs in qemu-user-static at all | 20:30 |
| slangasek | mwhudson: last time I tried qemu-user-x86, it didn't do nptl | 20:30 |
| slangasek | so | 20:30 |
| infinity | qemu-user-static is notoriously crap at all things threaded. Good thing Go doesn't ever do anything in paralle. | 20:30 |
| infinity | l | 20:30 |
| mwhudson | rick_h_: i can understand the reticence, but i reallllllyyyyy think the scope for subtle breakage is v minro | 20:32 |
| infinity | Surely there's a testsuite we can exercise to see if it breaks. | 20:32 |
| rick_h_ | mwhudson: ok, I'm not familiar enough to help but just wanted to make sure. | 20:32 |
| rick_h_ | infinity: yes, but if it's subtle there's risk it's something that would be provider specific/etc that scares me. | 20:32 |
| infinity | If the entire juju testsuite is "run the binary to see if it crashes", we have much bigger problems than stripping. :P | 20:32 |
| rick_h_ | lol | 20:32 |
| mwhudson | oh good juju doesn't build with gccgo on my system? | 20:33 |
| mwhudson | juju tip | 20:33 |
| mwhudson | i'm on wily thouhg | 20:33 |
| stgraber | +1 on having dh_strip DTRT | 20:34 |
| infinity | The 2.0 test PPA was only x86 too. | 20:34 |
| stgraber | FWIW, lxd doesn't override dh_strip, so I guess it means it's getting called and AFAICT our powerpc binary still works :) | 20:34 |
| infinity | stgraber: Do you have stripping logic in lxd you'd like to move to dh_strip? :) | 20:34 |
| infinity | Ahh. | 20:34 |
| infinity | Neat. | 20:34 |
| stgraber | that or dh_strip is skipping all go binaries which would be kinda bad :) | 20:34 |
| infinity | stgraber: Are your binaries a bazillion whosibytes? | 20:35 |
| infinity | stgraber: Cause if not, they're probably stripped. | 20:35 |
| stgraber | we have a powerpc box I use quite a bit for testing and to build various images, haven't had any problem on it | 20:35 |
| infinity | stgraber: powerpc or ppc64el? | 20:35 |
| infinity | I mean, I know you know the difference, but... Why would you have the former? | 20:35 |
| stgraber | we've got both | 20:36 |
| infinity | (says the man with several powerpc boxes...) | 20:36 |
| stgraber | because powerpc keeps breaking and I wanted to be able to test things before they break :) | 20:36 |
| infinity | Heh. Fair. | 20:36 |
| infinity | Do you use this reflection thingee vorlon speaks of? | 20:36 |
| stgraber | /usr/bin/lxd: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=923cbfc4794ecc86c35469418558d3146718e68c, stripped | 20:36 |
| stgraber | yup, we use reflection in a few code paths | 20:36 |
| infinity | mwhudson: So, maybe it all works now? Somehow? | 20:37 |
| stgraber | our biggest user of reflect appears to be our /dev/lxd interface, let me poke at it a bit to make sure it works as expected | 20:37 |
| mwhudson | infinity: maybe! | 20:37 |
| mwhudson | infinity: i'll ask upstream | 20:37 |
| infinity | Can the next new language we adopt have THREE differently-broken toolchains? Two isn't enough hassle. | 20:38 |
| mwhudson | infinity: i'll use common lisp for my next r | 20:39 |
| mwhudson | infinity: i'll use common lisp for my next project | 20:39 |
| mwhudson | ah stripping gccgo-built juju still breaks | 20:40 |
| slangasek | mwhudson: I thought the traditional exit strategy was haskell | 20:40 |
| stgraber | root@test:~# curl --unix-socket /dev/lxd/sock http://a/1.0/config | 20:40 |
| stgraber | ["/1.0/config/user.this-works"] | 20:40 |
| stgraber | this particular code path definitely runs through reflect.Indirect and a bunch of similar fun code | 20:40 |
| mwhudson | slangasek: but that only has one toolchain? (that anyone actually uses) | 20:40 |
| infinity | Curious. So something different breaks for juju. Good(?) to know. | 20:40 |
| slangasek | right :) | 20:40 |
| stgraber | as far as numbers, unstripped lxd is 21M, stripped lxd is 13M. That's the golang numbers. | 20:41 |
| stgraber | gccgo is smaller at just 6.2MB stripped | 20:41 |
| infinity | mwhudson: I'm kinda curious what breaks for juju and why it doesn't for lxd, but not curious enough to skip lunch any longer. | 20:44 |
| * infinity lunches. | 20:44 | |
| mwhudson | yeah, me too, except for the time of day | 20:45 |
| infinity | mwhudson: Although, stgraber's builds are on up-to-date xenial, you implied you were wilyish. | 20:46 |
| rick_h_ | mwhudson: all good, it's good to know we should look into it and explore it on our end | 20:46 |
| rick_h_ | mwhudson: everyone still thought it was a 'thou shalt not do' | 20:47 |
| mwhudson | infinity: i was trying juju in a xenial lxd | 20:47 |
| mwhudson | rick_h_: one myth at a time :-) | 20:47 |
| infinity | There was an LP bug about this a long time back that implied a less aggressive strip would work too. | 20:48 |
| infinity | Maybe that could be built into dh_strip, if I can figure out how to identify that a binary is Go. | 20:48 |
| infinity | And if I can remember the bug report. :P | 20:48 |
| infinity | But yes, lunch. Hungry, hungry hippo. | 20:48 |
| slangasek | rharper: so I'm taking a closer look at squid3 now; I do not like what I am seeing, and I'm not sure how much of it is Debian vs. Ubuntu delta. Do you know why we have extensive maintainer scripts for both the squid3 and squid binary packages? Do you know why the squid3 dummy package declares a pre-depends on squid instead of depends? Are you the right person for me to be pestering about these | 21:12 |
| slangasek | things? | 21:12 |
| rharper | slangasek: rbasak did the merge; so he's most intimate with the details | 21:13 |
| slangasek | ok | 21:13 |
| rharper | slangasek: if you put the questions in the FFE bug, rbasak will see them and can reply as he sees; I'll actively research and help until he's online tomorrow | 21:14 |
| slangasek | rharper: yeah, if you don't have the answers to hand, given the tz difference this is going to end up being a matter of me taking a machete to the packaging | 21:15 |
| slangasek | thanks, though :) | 21:15 |
| rharper | slangasek: my gut feeling is that most of the package stuff is from debian as our goal has been to drop delta | 21:15 |
| slangasek | yeah, it is | 21:15 |
| slangasek | there's some delta to each of the scripts from Ubuntu, but the fact that there are two sets of maintainer scripts is Debian-induced braindamage | 21:16 |
| rharper | yuck | 21:16 |
| mwhudson | AND the package uses cdbs! | 21:16 |
| rharper | and folks ask why we've not merged in so long | 21:17 |
| slangasek | yes | 21:17 |
| slangasek | and now is the time to fix up these maintainer scripts, *before* they dump a pile of orphaned config files onto users' systems in the LTS | 21:17 |
| doko | promoted libdata-alias-perl, blocking lintian migration | 21:17 |
| infinity | doko: It was already promoted once (by you). I guess someone demoted it again? :P | 21:17 |
| doko | yeah, not me ... | 21:18 |
| doko | foundations was also subscribed | 21:18 |
| rbasak | slangasek: the Debian situation isn't great. The Ubuntu delta isn't that large. | 21:18 |
| slangasek | doko: is that a new dep, then? | 21:18 |
| infinity | Oh well. My kingdom for auditing, so I can see who demotes without checking proposed. | 21:19 |
| rbasak | slangasek: it's complicated by the fact that Ubuntu carried a delta from Trusty from squid -> squid3, and Debian is going the other way now. | 21:19 |
| doko | how much do we care about mariadb-10.0 ? | 21:19 |
| slangasek | rbasak: yeah, I'm seeing that. Nothing I fault you for as part of the merge, but I'm reaching for increasingly large bladed weapons now ;) | 21:19 |
| rbasak | So there are various use cases such as Trusty -> apt-get install squid -> do-release-upgrade to Xenial being different from Trusty -> apt-get install squid3 -> do-release-upgrade to Xenial. | 21:19 |
| infinity | slangasek: Was a new dep, yeah: https://bugs.launchpad.net/ubuntu/+source/libdata-alias-perl/+bug/1564082 | 21:19 |
| ubot5` | Launchpad bug 1564082 in libdata-alias-perl (Ubuntu) "[MIR] libdata-alias-perl" [Undecided,Fix released] | 21:19 |
| slangasek | k | 21:20 |
| rbasak | Stuff breaks in strange ways because the dpkg-maintscript-helper calls are essentially a hack. | 21:20 |
| rbasak | The duplicate calls from both squid and squid3 maintainer scripts work around it. | 21:20 |
| rbasak | I'm not sure if that's what Debian intended, but it seems to work for us. | 21:20 |
| slangasek | infinity: without checking -proposed> well, I *did* point out that having one c-m report would be cleaner, but I got voted down. I didn't do the demotion though :) | 21:20 |
| doko | slangasek, https://bugs.launchpad.net/ubuntu/+source/libdata-alias-perl/+bug/1564082 | 21:20 |
| rbasak | (hack as in more of a hack than usual, since sometimes the prerm in squid might never run, etc) | 21:21 |
| rbasak | slangasek: if it helps, https://git.launchpad.net/~racb/ubuntu/+source/squid3/log/?h=merge breaks down the current Ubuntu delta (my merge) | 21:21 |
| slangasek | rbasak: at this point I assume the last time the squid3 maintainer looked at a package was 2003 | 21:21 |
| rbasak | slangasek: upstream have been quite involved recently, and he doesn't have much packaging experience I don't think. | 21:22 |
| doko | rbasak, are all those block-proposed tags really helpful? these prevent testing by a much larger community | 21:22 |
| rbasak | slangasek: his sponsor seems to be less involved nowadays, AFAICT. | 21:22 |
| infinity | slangasek: Other than the Debian packaging being insane, there's the added bonus that we and Debian were inverted on package names for a while, which makes it even more fun. | 21:23 |
| rbasak | doko: mysql-5.7 block-proposed was to prevent breaking mythtv during beta week. I guess that can be removed now, though I think there's still a dep8 fix to upload so it wouldn't migrate yet anyway. | 21:23 |
| slangasek | infinity: I know, I know | 21:23 |
| infinity | So, crazy on top of crazy. | 21:23 |
| infinity | With a side of delicious crazy. | 21:23 |
| rbasak | doko: squid's tag was suggested to me I think. I'd be fine to remove that now, but no need to break users until the current known bug is fixed I think. | 21:23 |
| doko | k, thanks | 21:24 |
| slangasek | oh good, adduser in the preinst without a pre-dep | 21:27 |
| slangasek | not like the maintainer had never heard of a pre-dep, he just apparently has no idea what they're fore | 21:28 |
| slangasek | -e | 21:28 |
| slangasek | adduser --system --home /var/spool/squid --group proxy | 21:30 |
| slangasek | chsh -s /bin/sh proxy | 21:30 |
| slangasek | >_< | 21:30 |
| teward | infinity: any chance you or someone else on the release team can review the nginx freeze exception request bug before tuesday? happy to give specifics as to why i say tuesday off-channel but... | 21:43 |
| slangasek | rbasak, rharper: looks like the upgrade also doesn't migrate /var/spool/squid3 to /var/spool/squid; do you know if there was a specific reason this wasn't done? | 21:48 |
| rharper | slangasek: no, guessing it was missed; I assume we want to move all squid3 -> squid where ever ? | 21:50 |
| rharper | slangasek: rbasak may know of a specific case; but I;m not aware of one | 21:50 |
| slangasek | rharper: well, the maintainer talks in NEWS.Debian about it not being automatically moved, which seems strange to me | 21:50 |
| rharper | maybe they didn't want to test it out | 21:52 |
| doko | afk now | 21:54 |
| mwhudson | slangasek, infinity: https://groups.google.com/d/msg/gofrontend-dev/WAl16EmuxyE/WXktcXJ8CAAJ re gccgo stripping | 21:54 |
| mwhudson | so it's not reflection per say, but other introspectiony thing | 21:54 |
| slangasek | ah, k | 21:54 |
| slangasek | superm1: is there an FFe bug for gnupg2 2.11-6ubuntu1 (not listed in the changelog)? | 22:02 |
| doko | slangasek, I discussed this today with him, including the MIR report for fwupd | 22:04 |
| slangasek | doko: what does that mean, you discussed it? I don't see an FFe bug | 22:05 |
| stgraber | that lxd upload should be trivial to review ^ it's just using the now promoted archive copy of go-colorable instead the embedded copy | 22:07 |
| slangasek | ah, now I get to the unnoticed bit where we're both removing and migrating /etc/init.d/squid3, heh ;) | 22:11 |
| superm1 | slangasek: no an FFe bug was not created, based on the conversation that happened in -devel and that MIR bug I was under the impression it wouldn't be necessary | 22:14 |
| superm1 | if it is, I can file one now | 22:14 |
| doko | slangasek, the MIR issue is https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871, the discussion was today on #ubuntu-devel, and the update fixed an issue in gpgme1.0 which was already in the release pocket | 22:14 |
| ubot5` | Launchpad bug 1536871 in npth (Ubuntu) "[MIR] fwupd" [Undecided,Fix released] | 22:14 |
| slangasek | superm1: what MIR bug are you referring to? | 22:14 |
| slangasek | ok | 22:14 |
| slangasek | doko: none of which excuses bypassing the release team and FFe review | 22:15 |
| doko | the gnupg1.0 issue is LP: #1564234 | 22:15 |
| ubot5` | Launchpad bug 1564234 in gnupg2 (Ubuntu) "gpgme1.0 doesn't work properly with gnupg 2.0" [Undecided,Fix released] https://launchpad.net/bugs/1564234 | 22:15 |
| slangasek | superm1: please do - from previous proposed-migration investigations, I understand that the behavior of the newer gnupg2 differs from the previous one in various ways that may or may not impact other things up the stack | 22:16 |
| doko | pretty please can we have a FFe for https://mail.python.org/pipermail/python-dev/2016-March/143603.html ? | 22:46 |
| slangasek | doko: I suppose you want this in for the next rebuild test? | 22:49 |
| doko | slangasek, I didn't expect you would volunteer for the packaging ... | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!