=== mfo_ is now known as mfo [09:46] tsimonq2: aha! i should use that to update the branch! [10:01] tsimonq2: also, why do you think you do not have commit access? all ubuntu core devs have commit access to lp:ubiquity [12:08] Hello bryceh, would you like to review bug #1980518 ? [12:08] Bug 1980518 in pdf2djvu (Ubuntu) "Fix build for Poppler 22.06" [Undecided, In Progress] https://launchpad.net/bugs/1980518 [13:49] juliank: i'm trying to figure out if ubiquity -> sudo -> ubuntu-drivers -> apt -> dpkg all preserve file descriptors between themselves. Or if everything tries to exec things with all descriptors closed. [13:50] xnox: apt tries to exec with all descriptors except 1,2 closed [13:50] though it's configurable [13:50] I think python does too? [13:50] which bits of code should i look at? i.e. where is it configurable / where does it do the closing? [13:50] You have to manually mark fds as keep open in python since a few months? [13:51] maybe i should give up on that, and instead just create a new file in /run and pass environment variable to be used..... [13:51] i am assuming apt doesn't randomly clear DEBCONF_DB_OVERRIDE variable [13:51] e.g. APT::Keep-Fds { "3"; "4"; "5"; } [13:51] um [13:51] add a ; [13:52] ack. [13:52] thanks. [13:58] and yes python changes are urgh. [13:58] so i think i will give up on the idea of passing FDs because it is fragile to go via three codebases reliably. [13:59] and will opt for an extra debconf database. [15:01] nteodosio, sure will do [15:07] During my +1 shift I noticed an odd circular dependency. [15:08] Package golang-github-jackc-pgtype is in NEW and is dependency wait on golang-github-jbackc-pgx-v4-dev [15:08] s/jbackc/jackc/ [15:09] golang-github-jackc-pgx-v4-dev is a new binary package from the source package golang-github-jackc-pgx, which is currently trying to migrate from major version v3 to v4 [15:10] However, the major version v4 can't build because it is dependency wait on golang-github-jackc-pgtype-dev [15:10] so package A in NEW can't build without a binary from package B that can't be built without binaries from package A. [15:11] ∞ [15:26] I briefly thought about combining the packages, but that is not idea for a few reasons. One being it breaks our golang-github-- packaging convention, and the other being that it would install possibly un-needed source code on people's machines if they install the combined package but really only needed one. Does anyone have any suggestions? [15:27] seb128 or tsimonq2: please could one of you review https://code.launchpad.net/~racb/ubuntu-sponsoring/+git/ubuntu-sponsoring/+merge/426087 for me, as you've touched the code recently? [15:50] rbasak, no today, but if tsimonq2 doesn't beat me to it I will try to review it monday [16:04] Sure, thanks! [16:22] jawn-smith, the two approaches I've generally found effective are a) if the dependency is only due to test requirements, disable testing during build; b) if there are earlier versions in debian that do not have the dependency issue, you can ask an AA to remove the back packages from New, then incrementally upload the earlier intermediary versions and bootstrap your way up [16:24] bryceh: Thanks for the reply! I'll take a look to make sure they're not just test dependencies [16:51] rbasak: OOOH yes I'll review this today!! An MP to ubuntu-sponsoring, I'm excited :) [18:37] nteodosio, pdf2djvu lgtm, upload sponsored. I notice you also had a debian-goodies merge proposed, which LGTM, and have sponsored that as well. [18:38] Thanks bryceh, cheers [19:42] Hello, is there a dedicated Matrix channel for Ubuntu-devel questions? [19:43] Or Slack / Mastodon / Telegram, etc.? Just not IRC in fact :) [19:43] s/Mastodon/Mattermost/ [19:51] if there is, many of us aren't there [19:51] and matrix can proxy to IRC, so [19:52] Yeah but the user experience is god awful [19:52] but you if suggests there is none. so ok [19:53] FreeVariable: All Matrix features work here, like I can use Matrix reactions on stuff. It's just that only other Matrix users see it. [19:54] arraybolt3[m]: Yeah so there is no point to use features most people won't be able to see / use [19:54] Anyway, my question is: Is there any place where I can see the "pipeline" / stages of a particular Ubuntu package? [19:55] I'm afraid I don't understand the question. stages of what? [19:55] packages [19:55] builds [19:55] that are not released yet. [19:56] where I can see the tests, tests results, commits, patches, etc. [19:56] launchpad.net/ubuntu/+source/$package shows all of the versions of a package that are current in the archive, you can drill down into them to see the build logs [19:56] but most packages in Ubuntu are not driven through VCS commits [19:56] But I am only interested n things not yet released. [19:56] s/n/in/, s//**/, s//**/ [19:57] In most distros there is staged worked being tested or otherwise tried out in the build pipeline [19:57] that's what I am interested in [19:57] before it's published [19:58] * In most distros there is "stage area" with work being tested or otherwise tried out in the build pipeline [19:58] so you can see this at the granularity of a per-upload package diff, but there's nothing more fine-grained than that [19:58] * In most distros there is "stage area" with work being tested or otherwise tried out, as in a build pipeline, before release. [19:58] ok, for that you probably want https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [19:59] the -proposed pocket is where the testing happens before packages are released [19:59] there are corresponding pages for each of the stable release series [19:59] Ok, I'll start with that. Thanks a lot! === chrisccoulson_ is now known as chrisccoulson