[00:02] <bdmurray> jawn-smith: ocrfeeder is still stuck so I'll override it
[00:04] <jawn-smith> bdmurray: thanks!
[00:43] <bdmurray> mwhudson: does  bug 1952093 need fixing in Jammy?
[00:43] <mwhudson> bdmurray: no
[00:43]  * mwhudson bug statuses
[09:07] <Unit193> slyon: Hello!  I hear you're a new core-dev and may be keen to try out sponsoring, if so could you take a look at https://unit193.net/source/pastebinit_1.5.1-1ubuntu1.dsc ?
[09:14] <slyon> Unit193: heh, not that new after all, but anyways I'll put that on my list to review later! :)
[09:15] <Unit193> \o/
[09:44] <slyon> Unit193: LGTM! Did you submit those patches to Debian, too? They look rather generic and useful for Debian.
[09:45] <Unit193> Trying to poke the right people about this, kinda dorment so going "upstream" first.  That didn't start out as an Ubuntu upload, in fact.
[09:54] <slyon> Unit193: ok. May I suggest you doing the "submittodebian" limbo at least? So it will be available in the Debian bug tracker for Simon to pick up.
[09:54] <slyon> Otherwise that's a very nice diff, the only thing I'd like to suggest for the future would be using DEP-3 headers: https://dep-team.pages.debian.net/deps/dep3/
[10:00] <Unit193> Yeah, likely a good idea.  If nothing else, to silence lintian. :P
[10:02] <Unit193> Thanks slyon!
[10:09] <schopin> Unit193: for the record, the newest, shiniest Core Dev is jawn-smith (Americas tz) ;-)
[10:12] <schopin> bryceh: thanks for the upload, duly noted for the Core Dev thing :)
[10:17] <schopin> bryceh: regarding git-ubuntu, it wasn't very clear that (in most cases?) it's pretty-much read-only. The recent developments for rich history incorporations are a step in the right direction, but it's only relevant for those with upload rights to the packages handled by git-ubuntu, which AIUI are basically all in main?
[10:18] <Unit193> schopin: Haha yes!  I did see that, but not pokable right now, seems he's gone. :P
[10:22] <schopin> Most people these days look for the "github project" when trying to contribute, or at least the Git repo. "Ubuntu git" in Google gives me the git-ubuntu tool as in the first page, and the only relevant result if you want to contribute to Ubuntu and not just install git.
[10:23] <schopin> bryceh: That's why I find it confusing. However, I'm using it for my merges and am loving it :)
[11:37] <schopin> doko_: waveform: does this ICE on armhf look familiar to either of you? https://launchpadlibrarian.net/571874086/buildlog_ubuntu-jammy-armhf.postgresql-14_14.1-1build1_BUILDING.txt.gz
[11:38] <schopin> My Google-fu gives me some bug report related to inline assembly, but the affected file doesn't have any inline assembly.
[11:38] <doko> schopin, no, I can have a look later this week
[11:39] <doko> but: "The bug is not reproducible, so it is likely a hardware or OS problem." so maybe retry the build first
[11:43] <KBar> Hi. I was having a look at bash's startup files and found this particular line in /etc/bash.bashrc in this script that displays information about sudo the first time bash is invoked: case " $(groups) " in *\ admin\ *|*\ sudo\ *)
[11:44] <KBar> Isn't the group called "adm" these days?
[11:45] <waveform> schopin, no doesn't look familiar but this thread from a few days ago looks eerily familiar: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GD3ABSWD6HHTNEKV2EJY4PXABQ245UCZ/ (and doesn't involved inline assembly)
[11:50] <KBar> Nevermind, "adm" is actually used for system monitoring tasks, as per Debian Wiki.
[11:56] <schopin> doko: already the second build :/
[11:57] <schopin> waveform: I've seen the thread (well, glanced at it to find the bugzilla link), and on the bugzilla from what I understand (which isn't much) it *is* an inline assembly issue. Perhaps the asm comes from functions that are inlined in my source, though.
[12:04] <waveform> schopin, could well be -- may be worth trying the -DSTAP_SDT_ARG_CONSTRAINT workaround
[12:08] <waveform> schopin, -DSTAP_SDT_ARG_CONSTRAINT=g that is
[12:15] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:15] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:15] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:15] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:15] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:16] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:16] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:16] <rbasak> schopin: it's only relevant for those with upload rights to the packages handled by git-ubuntu> isn't that the same for basically every GitHub repo, where only one person or a small set of people can commit? But anyone can file a pull request against any repo, and that's the same with git-ubuntu. We've also been adding a repository for nearly any package on request, including packages in universe.
[12:16] <cpaelzer_> rbasak: something makes your msg repeat ?
[12:17] <rbasak> Sorry!
[12:21] <schopin> rbasak: it's actually possible to use the merge proposal process if I want to contribute to a git-ubuntu package? I have been misled, then. Also, note that my comments must be contextualized: I expanded on my MOTU application comment that "There is no clear-cut way to contribute to an existing package", specifically the git-ubuntu remark in there.
[12:28] <rbasak> schopin: you can file an MP against a git-ubuntu repository, and ask any uploader to review and upload it from there.
[12:28] <rbasak> I would like to adjust the sponsoring queue report generator to display these requests, but that's not done yet.
[12:28] <rbasak> However the actual MP part should work fine.
[12:32] <schopin> rbasak: sure, filing the MP is possible, I was more curious about the standard MP/PR/MR lifecycle : Open, Closed, Merged. I was under the impression that the uploader would basically pull the branch locally, upload the package, and close the MP manually.
[12:37] <rbasak> schopin: right, except if using rich history preservation, the MP will get marked as Merged automatically.
[12:40] <schopin> Cool, I wasn't sure about that bit.
[12:41] <rbasak> To be clear, one missing piece right now is that if you file an MP against a git-ubuntu branch and do nothing else, the default reviewer will be a bot that will never review your MP.
[12:41] <rbasak> But the MP mechanism itself does work, if you find a reviewer to review and upload the MP.
[12:43] <schopin> Nice, I think I might give that a try for my next patch in need of sponsor.
[12:44] <schopin> Which gives me a nice segue into...
[12:44] <schopin> Looking for a sponsor for LP: #1953023 :D
[12:46] <rbasak> Sure I'll sponsor that for you.
[12:47] <rbasak> Would you like to try a git-ubuntu MP? If not I'm happy to just upload.
[12:51] <schopin> I'd rather not, my time and brain don't have the capacity for it right now :)
[12:51] <rbasak> Sure
[12:56] <rbasak> (done)
[13:58] <xnox> schopin:  i am working on upgrading to 2.1 but yes fixing FTBFS is needed too
[15:01] <slyon> ddstreet: I'm currently preparing a round of systemd SRUs, is there anything to add from your side? Especially wrt to LP: #1950508 ? (There isn't any patch for Impish yet, tho that is marked as 'in progress' on LP)
[19:13] <genii> Sorry, would just a clarification point on do-rlease-upgrade. I know LTS-LTS is not offered until point release, and assumed it was the same with interim release upgrades, but would like to double-check
[19:17] <bdmurray> genii: Could you elaborate what you mean by interim release upgrades? When 22.04 is released upgrades from 21.10 to it will be enabled.
[19:21] <genii> bdmurray: Interim releases would be all non-LTS. So for instance any non-LTS to either the next incremental non-LTS or for instance non-LTS to LTS is what I'm interested in. Whether upon initial rlease it's available to upgrade to, or becomes available when the first point release happens
[19:22] <bdmurray> Only LTS releases have point releases, regardless for non-LTS releases upgrades are enabled shortly after the next release is available
[19:23] <genii> OK, thanks for the clarification
[19:29] <xnox> genii:  if there are no upgrade blockers, the upgrades are enabled more or less straight away. in some previous releases there was a delay in enabling upgrades due to upgrade-specific bugs.
[19:31] <genii> OK
[19:59] <dbungert> so python debug packages are generally going away, right?  so this sort of thing would be appropriate?  https://paste.ubuntu.com/p/Y7xYrj9RHn/
[20:25] <mwhudson> good morning
[20:47] <dbungert> vorlon: from the meeting today you mention ignoring pyqt5 for the time being. However it is relevant to node-jquery.  Can you elaborate on the pyqt5 comment?  I think my linked patch should fix this.
[21:08] <vorlon> dbungert: I meant that it seemed like it might be something else in the dependency chain that would work itself out without Foundations and therefore I wasn't going to assign it out, but if you have a better analysis, let's get it fixed :)
[21:08] <dbungert> will do, thanks!
[21:12] <jawn-smith> dbungert: do you need a sponsor for that patch?
[21:14] <dbungert> jawn-smith: I think we should upstream to Debian.  The question is, is this urgent enough to upload to Ubuntu in the mean time.
[21:14] <vorlon> yes it is
[21:14] <vorlon> ;)
[21:14] <dbungert> I'll request a sponsor then
[21:15] <dbungert> and upstream it
[21:15] <jawn-smith> dbungert: just let me know when everything is fully ready :)
[21:15] <dbungert> jawn-smith: I'll send you a patch with a reasonable changelog after this meeting
[21:15] <jawn-smith> sounds good
[22:48] <mwhudson> Depends: cryptsetup openssl (not considered)
[22:48] <mwhudson> oh good
[23:08] <dbungert> jawn-smith: LP: #1953083, thanks for volunteering
[23:25] <mwhudson> huh how can preinst files use debconf templates?
[23:39] <jawn-smith> dbungert: on it, thanks!