[00:18] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [00:18] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [02:28] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [02:28] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [02:38] sheesh [02:58] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [03:38] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [03:43] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [04:26] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [05:23] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [05:33] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [05:33] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [06:15] doko_: yep on those today [06:33] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [06:33] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [06:54] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [08:04] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [08:43] Any opinions on me setting +r (block unidentified users from joining) here for a few days? [08:47] Please do. [08:49] Perhaps if people commonly don't authenticate before joining, +q $~a would be better? [08:52] so, I guess you are not interested in that blog... :( [08:53] they spammed lots of different irc servers [08:56] Unit193: Yes, maybe that's better. Remind me, do users who try to speak while quieted get any kind of notification of it? [08:56] I'm not interested in any channel I run assisting the propagation of weaponised conspiracy theories that are clearly the result of some stupid IRC feud, no [08:57] cjwatson: They do indeed, if you set +z then they won't (though Sigyn can continue to kline.) [08:57] Ah, they can have a notification, that's fine. [08:58] cjwatson: They won't get a note that it's because they aren't logged in, though. That's one benefit of +r. [08:58] wat [08:58] that obviously didn't help [08:59] (I assume non-chanops saw spam just now) [08:59] Nope. [08:59] cjwatson: +z is set. [08:59] Aha, good point === cjwatson changed the topic of #ubuntu-devel to: Archive: open (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first [09:02] That'll do for now I think [09:03] Thank you, cjwatson. [09:51] doko_: mir raised for both new deps - thanks for the headsup [10:53] cyphermox, didrocks: ^^^: please review if you have time today [10:55] afk for today === blahdeblah_ is now known as blahdeblah [12:51] I'm bringing forward a feature addition patch in freeipmi that adds new symbols for IPv6. In the meantime there's been an soname bump upstream that didn't include the feature (it's upstreamed but didn't make this release). I assume I don't need to bump the soname, since I'm only adding features. But should I bump the minor version? That doesn't really make sense to me, since it'll collide with a [12:51] minor version bump from upstream anyway. [12:53] A previous upload bumped "libfreeipmi libtool versioning", whatever that is. [15:00] doko_, tkamppeter uploaded fixes for MIR bug 1747759 and bug 1747760 [15:00] bug 1747759 in cpdb-libs (Ubuntu) "[MIR] cpdb-libs" [High,In progress] https://launchpad.net/bugs/1747759 [15:00] bug 1747760 in cpdb-backend-cups (Ubuntu) "[MIR] cpdb-backend-cups" [High,In progress] https://launchpad.net/bugs/1747760 [15:00] doko_, can you take a look at those please? === BrAss_mOnKEy is now known as ghostwilliampw-4 === ghostwilliampw-4 is now known as william === walbon___ is now known as walbon === chrisccoulson_ is now known as chrisccoulson === leosilva is now known as leosilva_ [17:04] rbasak: Adding symbols doesn't need any bumping, but it does need a minver shlibs bump (and adding symbols to the symbols file with correct package versions, if there's a symbols file) [17:04] s/any bumping/any version bumping/ [17:34] infinity: struggling to figure out what you mean by "minver shlibs bump". You mean in a shlibs file? I don't see any in debian/, only the symbols file. [17:35] The symbols file was previously added to, so I think I just copy the previous lines as-is. [17:35] The symbols file was previously added to, so I think I just copy the previous lines as-is? [17:35] rbasak: shlibs files and symbols files are mutually exclusive. [17:35] rbasak: They serve the same purpose, symbols files are just more fine-grained. [17:35] OK. So you're expecting me to only add lines to the symbols files, right? [17:36] rbasak: Basically, shlibs says "if you build against this library, your dep MUST be >= foo", symbols files let you define your versioned dep based on the symbols you actually reference. [17:36] rbasak: Yeah, if there's no shlibs, just make sure the symbols are correctly accounted for at the right package version. [17:37] OK, thanks. The other bit I'm unclear about is bringing forward (or not) the change to configure.ac here: https://git.launchpad.net/~racb/ubuntu/+source/freeipmi/commit/?h=merge-cosmic&id=022f72579f48d8b8149ab67ca98c8152e52468f3 [17:37] +-LIBFREEIPMI_REVISION=7 [17:37] ++LIBFREEIPMI_REVISION=8 [17:37] rbasak: Actually, I say that, but libfreeipmi16 totally ships a bogus shlibs file here. :P [17:38] https://git.launchpad.net/~racb/ubuntu/+source/freeipmi/tree/configure.ac?h=merge-cosmic&id=022f72579f48d8b8149ab67ca98c8152e52468f3#n112 [17:39] What does that actually do? [17:39] rbasak: Do we not already carry that? Or are you talking about a backport to xenial or trusty or something? [17:39] We're already carrying it. [17:39] (my links above are based on what we already have) [17:40] The configure.ac change conflicts as you'd expect, since the upstream numbers have changed. [17:40] rbasak: Okay. So I guess I'm confused about what you're asking. You want to know if it was a mistake to bring that forward? [17:40] I'm wondering how it makes sense to be touching them. [17:40] I want to know what to bring forward, and how. [17:40] Bringing the symbols file diff exactly forward makes sense to me. [17:40] The configure.ac diff part I'm unsure about. I'm not sure I understand why that was being bumped in the first place. [17:41] And of course the actual numbers have changed. [17:42] rbasak: I imagine the original upstream committer changed the micro-version in his patch, and we just consumed that wholesale? [17:42] rbasak: It certainly doesn't make sense to roll that forward to a whole new version. [17:42] rbasak: Now that I get what you're asking about (a merge, with an old feature patch coming forward) [17:42] It hasn't arrived upstream in this version [17:42] (nor the previous soname) [17:43] It does arrive in a future soname, but I'm not merging that (yet) [17:43] The configure.ac bump was present in the original ubuntu distro patch but not upstream I think. [17:43] Which I think is odd, because upstream might yet bump minor/micro with some other feature. [17:43] Right. And when it does arrive in a future SONAME, you can drop all the icky ubuntuX crap from the symbols file and just use the upstream version it appears in. [17:43] So I'm tempted to leave the minor/micro versions alone, unless you tell me otherwise. [17:44] IOW, drop the patch to configure.ac. [17:44] Don't touch the library version. Drop the configure.ac patch. It was silly to include it at all if it wasn't an upstream-blessed version. [17:44] Thanks. [17:44] I wasn't sure if I was missing something. [17:46] rbasak: As for shlibs, the current libfreeipmi shlib is a filthy lie. [17:46] I don't see a shlib in the source [17:48] In the binary? [17:48] libfreeipmi 16 libfreeipmi16 [17:49] rbasak: Yeah, that needs a version, because symbols were added after the first libfreeipmi16 upload. [17:49] (Unless the first upload of that SONAME also included this patch) [17:49] I see [17:49] So, you need dh_makeshlibs -V 1.4.11-1.1ubuntu3 [17:50] Which is where that patch was added. [17:50] That's autogenerated from the symbols file? [17:50] It's generated by dh_makeshlibs [17:50] Generally. [17:50] I see. [17:50] Nothing to do for me though, as I'll be bumping the soname for this merge, right? [17:50] Good to know though, thanks. [17:51] Back later. Dinner arrived. [17:51] Oh, it needs the whole relation, not just the version. Apparently. [17:51] You're bumping SONAME in this merge? [17:51] If this isn't libfreeipmi16 anymore, then yeah, life's simpler. [17:52] Ahh, I see unstable has 17. [17:53] rbasak: So, where this *does* matter is xenial. Because updates has the patch and security doesn't. Things built AGAINST freeipmi in updates will have a bogus dep that implies it's okay to run against freeipmi from the release pocket (if using a build system that doesn't use the .symbols file which, admittedly, isn't common these days) [17:54] rbasak: In reality, because most modern debian packages will use the symbols file correctly, it's not the horrifying bug it once was. [19:28] cyphermox: re bug 1781529, yeah we're driving this [19:28] bug 1781529 in mecab-ipadic (Ubuntu) "[MIR] mecab" [Undecided,New] https://launchpad.net/bugs/1781529 [19:28] cyphermox: I should formally check with dpb, but the intention is that we'll subscribe if this goes through [19:28] rbasak: cool, [19:28] I just pinged dpb too :) [19:28] dpb1: ^ are you happy to subscribe ~ubuntu-server now? [19:29] rbasak: I asked you to do a review [19:29] rbasak: via a card [19:31] dpb1: I'm happy to subscribe. I think it'll be minimal work. [19:31] what the best option to ask for an SRU review these days? I noticed the archive admin days are no longer used. I pushed a util-linux sru to fix an early boot hang on core18:https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=util-linux [19:31] OK [19:31] I'll just reply then [19:31] Thanks! [19:31] mvo: we process straight from that queue [19:31] mvo: but ping if it's urgent [19:32] rbasak: its a bit urgent, it blocks testing right now [19:32] rbasak: and its (hopefully) super simple and uncontroversial [19:32] rbasak: I'm actually surprised this wasn't an issue on cloud images yet, its a hang when the partition is resized on firstboot in the early boot [19:33] I'm EOD but can look tomorrow, or earlier if I get a moment. [19:33] rbasak: subscribed [19:33] rbasak: sure, enjoy EOD :) sorry, its not *that* urgent :) [19:33] Thanks! [19:33] mvo: :) [19:35] dpb1: thanks