[00:08] infinity: Looking forward to the American election too, eh? === bipul_ is now known as bipul [01:26] for my own reference, if I update a package in the repositories that another relies on, and the package that relies on mine depends on it, how would a rebuild be issued, or what would be the most sensible way to approach that? Hypothetically. [01:27] teward: Why would a rebuild be necessary? [01:27] teward: Are you talking an SONAME bump in a library, or similar? [01:29] teward: Anyhow, if there's a library transition in play, you do something like "pull-lp-source foo && cd foo-* && dch -R", enter a changelog entry like "Rebuild for the libbar transition.", and upload. [01:30] teward: But first, I'm curious about specifics, rather than hypotheticals. We don't rebuild rdeps unless there's a reason. [01:30] infinity: with regards to https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-June/016654.html, https://lists.ubuntu.com/archives/ubuntu-server/2016-June/007360.html, and https://lists.ubuntu.com/archives/ubuntu-server/2016-June/007361.html [01:31] infinity: basically, it's on the discusison list - if there is a package with a .so dynamic module built against 1.10.1 and we release 1.10.2 for bugfix/security reasons, a package with the .so dynamic module would need a rebuild [01:32] reading up on the thread may make the reasoning more clear? [01:32] more or less to try and understand weird edge cases [01:33] granted, i've not yet merged in Debian's dynamic module handling yet, which might be a pre-req [01:33] rbasak: fyi ^ [01:33] teward: Having the server ABI tied to version is madness. [01:34] I told nginx upstream their dynamic modules approach doesn't work well in downstreams [01:35] teward: But, if we're stuck with that for now, then any rdeps in the archive would need a rebuild on upgrade, yes. And they better have proper dependencies based on some nginx-signature-12345 provides or something. [01:35] got a reply "Yeah we know, we'll work on it but it's not a short-term goal" [01:35] teward: It's not hard to fix. All they need is an ABI tracker that bumps signature if and only if the ABI breaks. Which means some rebuilds, but not on every version. [01:35] (This is basically the PHP approach) [01:36] teward: Anyhow, does nginx actually have rdeps in the archive right now? [01:36] infinity: for now, no. come next LTS, probably. [01:36] or sooner, if people start putting things into Debian for third-party modules [01:36] So, let's solve this properly before then. For both Debian and Ubuntu. [01:37] Modules need to have a specific exported ABI to depend on, so they don't have to depend on nginx (>> foo), nginx (<< bar) | nginx-foo (<< foo) ... [01:37] You can see how that gets ugly quickly. [01:37] indeed [01:37] I think this is something that should be deferred until nginx can fix things? [01:37] because the way they've got things done, at least AIUI, there's no ABI-based handling [01:38] You can fake one. [01:38] infinity: guidance on that would be appreciated [01:38] Remind me when it's not... Today. [01:38] works for me :) [01:39] * teward looks back at the nagios page saying all his Ubuntu Server VMs are down, and figures he should probably fix them instead of worrying about nginx :P [01:39] (at least for right now) [01:40] teward: As for upstream, they need to track ABI, but what they do with that information is another question. They *could* export an ABI define somewhere, that people could test against. Or, they could go the sane route, and promise ABI stability in a major.minor (or even just major) series. [01:41] teward: The latter would be much better, but it means checking for ABI breaks in upstream commits and blocking them or backing them out of people oops. [01:41] s/of people/if people/ [01:41] infinity: I think ABI breakage is more prone in mainline (1.9.x as an example) than 1.10.x which basically doesn't change once released [01:41] Well, "basically doesn't change" isn't a promise. ;) [01:41] except for bug fixes, and I think that nginx is smart enough to make notices about it [01:42] well, with dynamic modules being a 'new' thing with 1.9.x, 1.10.x, I think they'd put "This may break third party dynamic modules" over the lists i'm on [01:43] and that'd prompt the need to poke rebuilds or 'fake' an ABI change [01:43] Not if the ABI signature checked at load time is based on the version, they won't. :P [01:43] * teward yawns [01:43] Cause, in their mind, they break modules regardless. [01:43] infinity: I get what you're saying, i'm basically dead here. [01:43] Anyhow. Another time. [01:43] um, clarify "they" [01:43] there's nginx upstream, Google PageSpeed upstream, and us :p [01:44] They, upstream. They're not going to inform you if a change may break modules, because their "ABI" breaks on every version change anyway. [01:44] (there's two upstreams) [01:44] nginx upstream. :P [01:44] :P [01:44] well [01:44] i have an evil painful workflow that I currently do for a few home-grown packages which depend on others [01:45] basically a shell script that builds one, pulls in for the build env on a separate package, and tests. [01:45] but eh [01:45] We can talk more later. I have a hot date with a shawarma. [01:45] could potentially adapt, but CBA to bother now [01:45] heheheh, enjoy infinity [01:45] i'm going to go find coffee... [01:45] and fix my servers... (I think the hypervisor powercycled...) === rww is now known as rwd === elbrus_ is now known as elbrus === rwd is now known as ezri === robert_ancell is now known as robertancell === robertancell is now known as robert_ancell === robert_ancell is now known as robertancell === robertancell is now known as robert_ancell === {8 is now known as robot === JanC is now known as Guest5182 === JanC_ is now known as JanC