[00:05] <vorlon> bdmurray: certain dev tools fail to work on older releases if the new release name isn't known via distro-info; but I'm not sure why we require that to work in a security-only environment
[01:35] <nisstyre> Does Ubuntu backport bug fixes in libraries or do they just rely on the Debian maintainers? If it's purely Debian, do they only backport security fixes generally, or any kind of bug fixes?
[01:35] <nisstyre> Just curious how that works
[01:39] <sarnold> nisstyre: you can skim a huge number of changelogs pretty quickly at https://lists.ubuntu.com/archives/bionic-changes/ to get a feeling for what gets fixed when
[01:39] <nisstyre> sarnold: cool thanks for the link
[01:40] <Unit193> Canonical peeps basically maintain stuff in main, and "the community" takes care of universe (which tends to mean that stuff gets a bit ignored, but really just depends.)  I have seen an update basically get sync'd from Debian, but often that's not quite how it works (if for no other reason than version scheme differs.)
[01:41] <nisstyre> Unit193: I see. I'm guessing the process for adding packages to universe basically depends on someone creating a PPA and then it becoming popular/used a lot?
[01:43] <Unit193> nisstyre: Universe is comprised of everything not in main, main is basically the stuff on the main Ubuntu flavor as well as the server set (with some additions, usually because infra stuff uses it.)
[01:43] <Unit193> One can actually add something to the repo that isn't in Debian, but that usually has a team looking after it or whatnot.
[01:43] <nisstyre> makes sense
[01:44] <nisstyre> I'm coming from Arch Linux (beeng using it for the past decade basically), and I'm trying to get more familiar with Ubuntu since I've got to start using it for my work machine now.
[01:44] <Unit193> A community member doing a security update usually means someone that can read the wiki page, file a bug on LP, attach a debdiff, and find a sponsor (sub them to the bug), so it's not specifically that hard.  I've done it a few times.
[07:27] <mwhudson> does anyone know how the default mirror selection works in either d-i or ubiquity? is it just http://geoip.ubuntu.com/lookup and then $CountryCode.{archive,ports}.ubuntu.com ?
[10:07] <seb128> sil2100: hey, please don't copy bug #1740894 to bionic-updates if you didn't do it yet
[10:16] <sil2100> seb128: hm, just did cosmic for now
[10:17] <sil2100> seb128: are we still missing the systemd changes?
[10:17] <sil2100> seb128: I mean, seeing that the bug got switched to verification-done (and had no other open tasks), I thought it's good to go
[10:17] <sil2100> I'll wait with bionic
[10:26] <seb128> sil2100: I'm in meetings in London today, but my understanding is that the regression isn't fixed, they likely verified that the fix does work on those models that didn't work but that doesn't tell us that it's not sitll breaking the models that used to work
[10:59] <xnox> doko, vorlon - my understanding is that if one specifies 'skippable' in debian/tests/control Restrictions; one can exit 77 to skip
[11:00] <xnox> doko, vorlon - i recall you mentioning something like that, but "it didn't work on our infra" or something?
[11:00] <xnox> doko, vorlon - do we need to fix things in the webui and/or autopkgtest-cloud?
[11:00] <xnox> Laney, ^^^ might be interesting
[11:27] <Laney> xnox: should work, some tests use that already
[11:27] <ricotz> hello, is there a reason why there are no updates here http://cdimage.ubuntu.com/bionic/daily-live/ ?
[11:27] <Laney> we might not interpret the results in the best way in all circumstances tho
[11:40] <doko> oSoMoN: uploaded LO again to the apps PPA, we were missing debug symbols in this ppa
[11:44] <oSoMoN> ack
[11:58] <xnox> Laney, gotcha
[12:01] <ahasenack> doko: hi, did you get my last yesterday? bzr-git has a Recommends on python-tdb. We either drop that (and break bzr-git somewhat?), or keep building python-tdb (py2)
[12:14] <doko> ahasenack: I didn't check, is this a useful thing?
[12:15] <ahasenack> doko: don't know, not my package (bzr-git)
[12:15] <ahasenack> someone in the internet always finds something useful
[12:17] <rbasak> Is another option to demote it?
[12:18] <rbasak> Oh, it's already in universe. So I guess not.
[12:18] <rbasak> Keep building python-tdb but leave it in universe maybe? Would that work?
[12:24] <ahasenack> rbasak: yes, I was just checking what build-requires python-tdb, and it's just bzr-git, ldb (for python-ldb probably, which we don't build anymorE) and samba itself
[12:24] <ahasenack> I would just have to revert my revert again :)
[12:25] <ahasenack> that's why I kept building python2, to avoid introducing bigger changes
[12:25] <ahasenack> my thinking was we could just move all of the python(2) packages to universe in this first step
[12:29] <ahasenack> doko: everything else in that ppa is py3 now (even tdb, but I will rebuild it with py2 *and* py3 due to bzr-git)
[12:35] <rbasak> ahasenack: might be worth leaving a "uses py2" bug open against bzr-git?
[12:35] <ahasenack> I think we should have worked with the previous packages the way they were, building both py2 and py3
[12:35] <ahasenack> and later figure this out
[12:35] <ahasenack> but, too late now
[12:36] <ahasenack> I just don't want to keep dragging this for too long, since it's an FFe already
[12:37] <ahasenack> beta freeze in march 28th
[13:11] <cjwatson> bzr-git's tdb thing is used by LP
[13:11] <cjwatson> for git-to-bzr code imports
[13:11] <cjwatson> this doesn't mean you should block on it, since we maintain our own copies of the modules we need, just FYI on what sorts of things it's used for
[13:31] <ahasenack> cjwatson: thanks
[13:31] <ahasenack> cjwatson: I think I can keep python-tdb around
[13:32] <cjwatson> Like I say, LP doesn't need you to, though it's perhaps useful for people to be able to reproduce what imports do
[13:33] <cjwatson> Though we'll hopefully get onto the breezy version in the medium term anyway
[13:33] <rbasak> Breezy? :)
[13:33] <cjwatson> Yes?
[13:33] <cjwatson> Not sure I understand the question :)
[13:34] <rbasak> Oh
[13:34] <rbasak> You mean https://en.wikipedia.org/wiki/Breezy_(software)
[13:34] <cjwatson> Yes
[13:34] <rbasak> I thought you meant https://en.wikipedia.org/wiki/Breezy_Badger#Ubuntu_5.10_(Breezy_Badger) :-)
[13:35] <rbasak> (well, obviously you didn't, hence the question)
[15:59] <rbasak> Eickmeyer: in what way is the process for becoming a Per-Package Uploader convulated? How do you think we should change it?
[16:01] <Eickmeyer> rbasak: I think it needs to be more clear-cut and better defined. (BTW, that application is still work-in-progress, that might change. I may have been venting a little/in full panic mode considering Ubuntu Studio's status being in danger).
[16:01] <rbasak> Eickmeyer: well OK, but what about the current process isn't clear cut or clearly defined?
[16:02] <Eickmeyer> rbasak: The minimum number of packages and experience required doesn't seem to be defined, at least not that I could see.
[16:02] <Eickmeyer> Or, the minimum number of sponsors required.
[16:03] <rbasak> https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[16:03] <rbasak> "There is no minimum number of sponsored uploads into the archive that you need to have. You need to have demonstrated enough previous work to be able to assure your endorsers that you can be trusted with unsupervised upload access to the primary archive."
[16:05] <Eickmeyer> rbasak: I'm actually in the process of eliminating that line from my application right now, as it was written out of frustration/panic.
[16:05] <Eickmeyer> Doing that since I have not yet formally applied.
[16:05] <rbasak> OK. You absolutely are allowed to have that line, FWIW. We want feedback on making the process better.
[16:11] <Eickmeyer> rbasak: I actually changed it to be more about bureaucracy with a little addage about undertanding why it exists, but I have no idea how to improve that. I have a degree in leadership, so different leadership styles and organizations is something I understand pretty well.
[16:13] <rbasak> Eickmeyer: what bureaucracy? No, really. All we want is for you to write down why you need upload (obvious in this case) and demonstrate that you know what you're doing, and we'll consider it in a meeting.
[16:13] <rbasak> For exceptional circumstances such as this, I think you'll find that we can stretch quite a bit.
[16:13] <rbasak> So far, the problem is that nobody has talked to us about it since we all agreed what you needed to do in 2016.
[16:14] <rbasak> You can't pin that on bureaucracy.
[16:16] <Eickmeyer> rbasak: Okay.
[16:22] <Eickmeyer> rbasak: I fixed that. Take a look at the line now, tl;dr: that Ubuntu Studio hasn't had an uploder in several cycles, and not knowing we were required to have one.
[16:24] <rbasak> Eickmeyer: that's fine, but to be clear, I'm not trying to adjust your opinion in your application, or requiring that your application say the right thing or anything. I'd like to think that I won't hold your opinion against you in your application regardless of whether you state it.
[16:24] <Eickmeyer> rbasak: I appreciate that.
[16:24] <rbasak> Eickmeyer: separately from that, I'm frustrated that the current situation seems to be being taken the wrong way. I want to fix it, but I'd like us to end up on the same page about what is wrong and what needs to be addressed in the process (independent of your application)
[16:25] <Eickmeyer> rbasak: I appreciate that as well. I wish I had been alerted that this problem existed earlier. This all happened as a result of me seeking sponsorship, which I thought was the proper way, since that's what had been done for several cycles earlier.
[16:26] <ahasenack> vorlon: hi, samba 4.10 FFe, which also lists the other 4 FFes that are needed for its dependencies: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1818518
[16:26] <rbasak> Eickmeyer: so, with that in mind, what I'm trying to get to is that, while welcoming criticism, I also have the expectation that they are adjusted as needed so that they are well thought out and identify specifics.
[16:27] <rbasak> Eickmeyer: yeah. I understand you weren't involved the last time this came up, and that you've been thrown in the deep end.
[16:28] <rbasak> It wasn't because you requested sponsorship. It's that Steve happened to notice and be reminded because you spoke up.
[16:28] <rbasak> It's perhaps not appropriate to have caused you to feel like it was your fault somehow.
[16:28] <rbasak> vorlon: ^
[16:29] <Eickmeyer> The thought has crossed my mind that I should've kept my mouth shut, but in reality, I know that would've been improper.
[16:33] <Eickmeyer> rbasak: Thanks for your help, by the way. I really appreciate it, and I appreciate you asking me the tough questions, and forcing me to think through my application. :)
[16:59] <rbasak> Eickmeyer: sorry, was in a meeting. You're welcome! We want more contributors :)
[16:59] <rbasak> (and we want them to be able to upload themselves)
[17:10] <vorlon> Eickmeyer: yes, I don't blame you for the current state of things; it would've been nice if you had happened to have escalated this sooner, but you didn't know there was a reason to.  If the TB fixes having a process of reviewing flavor status, this should be less of a fire drill in the future.
[17:14] <Eickmeyer> vorlon, rbasak: Very much appreciated. I wish I had and known this needed to be escalated escalate this much sooner as well. I'm also glad it pointed-out an area that needed improvement.
[17:14] <vorlon> yeah
[17:15] <vorlon> Eickmeyer: from my perspective, it's an alarm bell that someone who's driving a flavor has to go begging for sponsorship from uploaders across the wider Ubuntu developer community
[17:15] <vorlon> and that's what I'm trying to sort out, so that ubuntustudio can be self-sustaining and effective
[17:16] <Eickmeyer> vorlon: Indeed. It seems to be the one missing piece of the puzzle. I hope that either myslf or Ross or both of us can fill that role. My application is in progress.
[17:17] <vorlon> excellent!
[18:03] <LocutusOfBorg> seb128, are you fixing poppler?
[18:03] <LocutusOfBorg> lol I did the same lol :D
[18:04] <seb128> what needs to be fixed in poppler?
[18:04] <LocutusOfBorg> I think I fixed gdcm and gdal
[18:04] <LocutusOfBorg> the last two blockers?
[18:04] <LocutusOfBorg> I was fixing calligra, and I just discovered your upload sigh
[18:04] <LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#disco/gdal/2.4.0+dfsg-1ubuntu1/buildlog
[18:04] <seb128> oSoMoN said he was going to look at that earlier
[18:04] <LocutusOfBorg> http://debomatic-i386.debian.net/distribution#disco/gdcm/2.8.8-6ubuntu2/buildlog
[18:04] <seb128> check with him
[18:05] <seb128> LocutusOfBorg: next time better to ask before starting to poke :)
[18:06] <seb128> oSoMoN: ^ fyi
[18:06] <LocutusOfBorg> sure! but meh, I said "lets do it while on train" :)
[18:07] <LocutusOfBorg> its a work I started yesterday, this is why I didn't check again
[18:08] <LocutusOfBorg> oSoMoN, the gdcm fix is trivial, https://github.com/malaterre/GDCM/pull/84
[18:09] <LocutusOfBorg> you can avoid the build, I'm doing it in the above link (if successful)
[18:10] <oSoMoN> LocutusOfBorg, thanks, I had come to the same conclusion, and have a local build currently running to verify that it's enough
[18:11] <seb128> cjwatson: big thanks from the desktop team for the gitlab support :-)
[18:11] <willcooke> thanks cjwatson!
[18:14] <oSoMoN> LocutusOfBorg, are you uploading the fixes for gdal and gdcm, then?
[18:14] <oSoMoN> I can't upload myself anyway
[18:15] <oSoMoN> gotta go, bbiab
[18:17] <seb128> oSoMoN: sorry if you had started and dupped work, it's annoying when it happens
[20:27] <oSoMoN> LocutusOfBorg, thanks for the gdcm upload, are you going to do gdal as well?