[04:36] <artur> Hello, can someone help to sponsor this ticket? https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/2042902
[04:36] -ubottu:#ubuntu-devel- Launchpad bug 2042902 in OEM Priority Project "ucm2: soundwire: add rt713 SDCA device" [Critical, In Progress]
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
[09:46] <arraybolt3> Just now due to Internet difficulties, I was unable to use autopkgtest-buildvm-ubuntu-cloud to create a new autopkgtest virtual machine - the download of the cloud image kept timing out. I was, however, able to download the correct image with wget. I patched autopkgtest-buildvm-ubuntu-cloud locally to allow me to use a predownloaded image and have
[09:46] <arraybolt3> it just do the customization parts. Is this something I should try to possibly upstream?
[09:47] <arraybolt3> i.e., would anyone else find this useful?
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
[10:29] <bigmdm> Hi! How do I find a sponsor for my package (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057076)?
[10:29] -ubottu:#ubuntu-devel- Debian bug 1057076 in sponsorship-requests "RFS: imsprog/1.1.2-11 [put in ITP, ITA, RC, NMU if applicable] -- friendly greeter" [Normal, Open]
[10:30] <ginggs> nteodosio: do you think duplicity is able to be sync'd now?  and would you need a sponsor?
[10:33] <bigmdm> I want the program to be available to all Debian users.
[10:37] <Fallen> bigmdm: Can you check in when the next patch pilot is in? They can help you with an answer. Next person should be there in 1.5 hours, and then we have coverage for about 8 hours. You'll see the current patch pilot in the topic. https://ubuntu.com/community/contribute/ubuntu-development/ubuntu-patch-pilots
[10:44] <bigmdm> Fallen, I'm new here and I don't understand a lot of things. Can you tell me what I need to do after an hour and a half?
[10:54] <nteodosio> ginggs, I do have bug 2039433 requesting the sync, but looks like I forgot to subscribe the sponsors.
[10:54] -ubottu:#ubuntu-devel- Bug 2039433 in duplicity (Ubuntu) "Please sync duplicity 1.2.2-2 from Debian" [Undecided, New] https://launchpad.net/bugs/2039433
[10:54] <zhsj> bigmdm: are you going to introduce a new package called imsprog? if so, you need to follow the process on https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[10:56] <bigmdm> zhsj, yes! Thank!
[10:56] <ginggs> nteodosio: thanks, I'll sponsor it now
[10:56] <nteodosio> Thank you
[10:58] <ginggs> de nada!
[11:08] <mateus-morais> arraybolt3: yes, I'm a +1 on that. I built a few autopkgtest images yesterday and having it re-download every time was annoying.
[12:10] <bdrung> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: bdrung
[12:17] <bigmdm> Hi, <bdrung>! I am the author of imsprog (https://launchpad.net/imsprog) in launchpad. This program is very necessary in Ubuntu. This program is very necessary for flashing BIOS chips for those who repair electronics and cars. There are no analogs in Linux at the moment. Can you please tell me how to publish it in the official Ubuntu repository? I opened Debian Bug report logs - #1057076.
[12:17] <bigmdm> I create the https://launchpad.net/~bigmdm/+archive/ubuntu/imsprog.
[12:17] <bigmdm> What should I do next?
[12:20] <bdrung> bigmdm, hi. normally the best way to get new packages in Ubuntu is through Debian. I can review and sponsor it in Debian as well. Once the packages landed in Debian unstable, it will be synced to Ubuntu (either automatically or manually - depending on the release schedule)
[12:22] <bdrung> bigmdm, have you file an ITP bug in Debian? https://www.debian.org/devel/wnpp/
[12:22] <bigmdm> bdrung, please do it!
[12:23] <bdrung> bigmdm, have you run lintian on the package? I see a lot of .ex files in debian/.
[12:24] <bdrung> bigmdm, files and debhelper-build-stamp should not be committed to git: https://github.com/bigbigmdm/IMSProg/tree/main/debian
[12:25] <bigmdm> bdrung, I got a blank response from the lintian. (Cleaned up all the errors and warnings.)
[12:27] <bigmdm> Is this file to be deleted?
[12:28] <bdrung> bigmdm, d/files and d/debhelper-build-stamp are files generated during package build
[12:29] <bigmdm> Ok. I remove it.
[12:30] <bigmdm> bdrung, it is done!
[12:33] <bdrung> bigmdm, debian/rules should be executable
[12:34] <bigmdm> Yes, there's a link to cmake.
[12:38] <bigmdm> bdrung, otherwise the package will not be builded.
[12:41] <bigmdm> bdrung, I posted on Launchpad Jemmy and Focal releases.
[12:42] <bigmdm> *Jammy*
[12:44] <bdrung> bigmdm, i build the package for Debian unstable and lintian has following complaints: https://paste.ubuntu.com/p/PNgS7g6DGn/
[12:45] <bdrung> bigmdm, since it's not a native Debian package, please use "3.0 (quilt)" source format. See https://paste.ubuntu.com/p/PNgS7g6DGn/ and https://raphaelhertzog.com/2010/10/21/the-secret-plan-behind-the-3-0-quilt-debian-source-package-format/
[12:52] <bigmdm> bdrung, странно, я запускаю lintian командой lintian -i -I --show-overrides imsprog_1.1.2-11_amd64.deb. И добился отсутствия ошибок. Как исправить ошибки "file-without-copyright-information"?
[12:53] <bigmdm> bdrung, strange, I run lintian with the command lintian -i -I -I --show-overrides imsprog_1.1.2-11_amd64.deb. and achieved no errors. How to fix "file-without-copyright-information" errors?
[12:53] <bdrung> bigmdm, you need to run lintian on the changes file to also get it run on the source package.
[12:54] <bdrung> bigmdm, you do not have an entry for "Files: *" in d/copyright
[12:55] <bdrung> bigmdm, Are all files from you? Then one single "Files: *" entry will be enough.
[12:57] <bigmdm> bdrung, no. Some of the files are from the QHEXEDIT and Snander projects, they are under GPL V2.
[12:58] <bdrung> bigmdm, then this needs to be documented in d/copyright
[12:59] <bigmdm> bdrung, then I will try to clean up those errors. When I get everything in order and make a new release, how can I let you know?
[13:00] <bdrung> bigmdm, ping me here. You can ping me before you cut a new release for deeper review.
[13:01] <bdrung> bigmdm, since it will be your first upload to Debian unstable, debian/changelog should only have one changelog block with the initial release.
[13:01] <bdrung> (uploads to somewhere else does not count for Debian)
[13:01] <bigmdm> bdrung, thank you very very much!
[13:02] <bdrung> bigmdm, you're welcome.
[13:06] <bigmdm> bdrung, some of the translations were also done by other people - some were e-mailed to me. Should this also be mentioned in the d/copyright?
[13:06] <bdrung> bigmdm, yes
[13:24] <mateus-morais> Hi! Can I get a review on this, please: https://code.launchpad.net/~mateus-morais/ubuntu/+source/lazr.restfulclient/+git/lazr.restfulclient/+merge/456553
[13:52] <schopin> mateus-morais: is it urgent? If not, give the standard sponsorship process a few days before making noise ;-)
[13:57] <schopin> mateus-morais: also, have you forwarded the fix to Debian? At a glance I think they'd be interested in the fix, and as it happens we have a few Debian Python Team members around, including the current patch pilot :)
[13:59] <bdrung> mateus-morais, where does the patch come from? Did you write it? Then please forward that patch upstream and document that in the patch.
[14:22] <mateus-morais> schopin bdrung: upstream is aware of the issue, there's an open bug about it https://pad.lv/2041407, it seems the work to make the package compatible with more modern python is on-going. Considering that, would you say the patch is upstreamable?
[14:22] -ubottu:#ubuntu-devel- Launchpad bug 2041407 in lazr.restfulclient "'ConfigParser' object has no attribute 'readfp'. Did you mean: 'read'? on Python 3.12" [Undecided, New]
=== pushkarnk1 is now known as pushkarnk
[14:27] <schopin> mateus-morais: Since they're apparently planning on doing it anyway, I think I'd just post the patch on the bug as an FYI.
[15:18] <bdrung> zhsj, did you forward the patch from https://code.launchpad.net/~zhsj/ubuntu/+source/abydos/+git/abydos/+merge/456583 to upstream?
[15:46] <zhsj> bdrung: upstream is inactive for years, but has sent to debian on corresponding bug
[15:53] <bdrung> zhsj, I saw that. I'll sponsor that in Debian. Can you drop the release commit from https://salsa.debian.org/python-team/packages/abydos/-/merge_requests/1? I'll just need the first commit
[15:53] -ubottu:#ubuntu-devel- Merge 1 in python-team/packages/abydos "Fix comparing float number in pairwise tests on Python 3.12 (Closes: #1056223, LP: #2045121)" [Opened]
[15:54] <bdrung> Otherwise I need to cherry-pick that commit.
[15:55] <zhsj> bdrung: done
[15:59] <bdrung> zhsj, thanks.
=== rkratky__ is now known as rkratky
=== pushkarnk1 is now known as pushkarnk
[16:39] <bdrung> zhsj, sponsored in Debian. You can close https://code.launchpad.net/~zhsj/ubuntu/+source/abydos/+git/abydos/+merge/456583 now.
[16:39] <bdrung> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
=== sem2peie- is now known as sem2peie
[16:41] <zhsj> bdrung: can you set it to rejected, it seems i can't reject it myself.
[16:42] <bdrung> zhsj, no, i can modify the state. but rbasak can do that.
=== sem2peie- is now known as sem2peie
=== pushkarnk1 is now known as pushkarnk
=== Adri2000_ is now known as Adri2000
=== sem2peie- is now known as sem2peie
[20:08] <ahasenack> coreycb: around? about https://bugs.launchpad.net/ubuntu/+source/keystone//+bug/1998789
[20:08] -ubottu:#ubuntu-devel- Launchpad bug 1998789 in keystone (Ubuntu Focal) "[SRU] PooledLDAPHandler.result3 does not release pool connection back when an exception is raised" [Undecided, In Progress]
[20:08] <ahasenack> shouldn't that go into focal-security instead?
[20:08] <ahasenack> the description says "This SRU intends to fix a denial-of-service bug"
[20:13] <coreycb> ahasenack: it possibly should. I just did a quick search and didn't see a CVE for it.
[20:13] <ahasenack> coreycb: is a cve required? I don't know if we get cves for all security updates
[20:13] <ahasenack> mdeslaur: hi, what do you think? ^
[20:13] <coreycb> ahasenack: I'm not sure either
[20:14] <ahasenack> mdeslaur: sorry, you were the first security person that came to my mind :)
[20:14] <ahasenack> (and is in a similar timezone)
[20:19] <sbeattie> a cve is not required to publish a security update / to the security pocket.
[20:19] <ahasenack> cool
[20:19] <ahasenack> I subscribed ubuntu-security@ to the bug anyway, to evaluate if we want to publish it into focal-security
[20:21] <sbeattie> the question is, is there an attack vector that a malicious actor could trigger keystone into doing, or is this just a keystone bug.
[20:21] <ahasenack> "But, if an exception or error happens while the LDAP connection is still borrowed, Keystone fails to release the connection back to the pool, hogging it"
[20:22] <sbeattie> .. trigger keystone into throwing an exception ...
[20:22] <ahasenack> the test case attempts to trigger a timeout in the ldap connection
[20:23] <ahasenack> so doesn't look like it's a case of bad input
[20:23] <ahasenack> but any exception that could happen while the ldap connection is being used
[20:24] <ahasenack> unreachable ldap server too, perhaps?
[21:41] <Eickmeyer> amurray_: If you're around, can you take a look at https://forum.snapcraft.io/t/need-to-make-a-post-with-more-than-two-links/37975 ? I have someone trying to help me, but I don't think they can help me.
[22:12] <Eickmeyer> amurray_: All taken care of. :)
[22:50] <bdrung> success. We have http://sponsoring-reports.ubuntu.com/ up and running now!
[22:53] <Eickmeyer> bdrung: That's really stinkin' cool!
[22:58] <arraybolt3> Eickmeyer: If you feel in a MOTU-work-sponsoring mood, could I interest you in reviewing https://bugs.launchpad.net/ubuntu/+source/python-etcd3gw/+bug/2045246 maybe?
[22:58] -ubottu:#ubuntu-devel- Launchpad bug 2045246 in python-etcd3gw (Ubuntu) "Merge python-etcd3gw from Debian" [Undecided, New]
[22:58] <Eickmeyer> arraybolt3: lgtm, I can do.
[22:58] <arraybolt3> Fairly simple merge that was really a sync but needed a tweak to avoid an FTBFS on Noble.
[23:06] <Eickmeyer> arraybolt3: That's anything but a simple merge, as I look at it. Look at the version numbers. 0.2.5-1ubuntu2 -> 2.1.0-2ubuntu1. This is a whole new upstream version. You skipped quite a few steps.
[23:09] <arraybolt3> Merge-O-Matic gave me a merge that had literally no difference between the Debian version and the merged version except for the changelog.
[23:09] <Eickmeyer> Yeah, this is why you can't rely on merge-o-matic all the time.
[23:09] <arraybolt3> That's worrying if that doesn't sound right, let me take a look
[23:10] <Eickmeyer> It's well known that Merge-O-Matic tends to be flaky especially for this kind of thing.
[23:10] <arraybolt3> crud
[23:12] <arraybolt3> I mean... I'm looking at the diff between the merged version's Debian directory and the original Ubuntu version's Debian directory and the changes are very minimal.
[23:12] <Eickmeyer> arraybolt3: You need a new tarball, full stop.
[23:13] <arraybolt3> how exactly would I do that? I'm not the one who can `debuild -S -d -sa` it, I thought that's what the sponsor had to do since they were the one who uploads it.
[23:14] <arraybolt3> do I need to upload a tarball to LP?
[23:16] <Eickmeyer> arraybolt3: What I'm saying is that you needed to mention it's a new upstream version in the bug report. You didn't say anything about that, you just expected a simple merge. This isn't a simple merge, it's a new upstream version. I'm also a little upset with the uploader in Debian for not putting that in the changelog.
[23:17] <Eickmeyer> arraybolt3: "Note: New upstream version" would alert a potential sponsor to grab the tarball.
[23:17] <arraybolt3> Eickmeyer: That makes sense. Perhaps this should be documented at https://wiki.ubuntu.com/SponsorshipProcess?
[23:17] <Eickmeyer> arraybolt3: Perhaps, but it's mostly a courtesy.
[23:17] <arraybolt3> +1
[23:18] <arraybolt3> I still think it's a simple merge since the delta is *very* small between Debian and Ubuntu and it doesn't look like MoM mangled it to me, but I will take that into consideration in these situations from now on.
[23:19] <arraybolt3> Should I edit the bug report first, or should this just be a "you know for next time" and we move forward with it as-is?
[23:20] <Eickmeyer> Nah, I know the rest, we can move forward.
[23:20] <arraybolt3> kk, will add this to my list of "how to prep an upload".
[23:24] <tsimonq2> I agree and disagree with both of you. You should not blindly rely on MoM, you should also always grab the orig tarballs directly from the *Debian* archive unless they're *intentionally* different. (If I'm the Debian maintainer and do a new release in Ubuntu first for Whatever Reason, I do it the other way around.) The reason is, uscan can Sometimes grab a tarball with a different checksum than the
[23:24] <tsimonq2> one in the archive, and that really messes with autosync. That being said, I don't blame arraybolt3 for not mentioning it's a new upstream release specificially, but I *do* blame the Debian maintainer for not properly documenting that in the changelog. It is always the responsibility of the sponsor to double check these items (new upstream version, correct merge diff, etc.) regardless, but I know
[23:24] <tsimonq2> arraybolt3 wants to patch pilot soon after MOTU, so I hope this helps.
[23:24] <tsimonq2> Eickmeyer: Thanks for looking at sponsorship for this.
[23:24] <tsimonq2> arraybolt3: And thanks for your work on this.
[23:25] <arraybolt3> tsimonq2: Thanks for the input, and I'll know from now on to be more careful with what MoM feeds me :)
[23:26] <tsimonq2> arraybolt3: Sometimes I think it should be called MoMnoMnoM
[23:26] <tsimonq2> :P
[23:27] <arraybolt3> lol XD
[23:27] <arraybolt3> Mangle-o-Matic-no-Merge-no-mhh,what_do_I_call_this_anyway
[23:28] <Eickmeyer> arraybolt3: W: python-etcd3gw source: runtime-test-file-uses-supported-python-versions-without-test-depends py3versions -vs [debian/tests/unittests:8]
[23:30] <arraybolt3> hmm, that's in the Debian side of the packaging though, not the Ubuntu delta?
[23:30] <Eickmeyer> arraybolt3: Doesn't matter, we need to add it.
[23:31]  * Eickmeyer can do
[23:31] <Eickmeyer> If we can fix a lintian tag, we do it. We also do a bug report to Debian.
[23:31] <arraybolt3> kk
[23:32] <arraybolt3> What I've been doing is making sure the Ubuntu delta is clean and ignoring the Debian side unless the problems are bad enough to warrant fixing the Debian side first, in which case I hold off on the merge entirely.
[23:32] <arraybolt3> (you can see an example of me fixing the Debian side first if you look at a recent bug report in openMSX, which was a disaster to begin with)
[23:33] <Eickmeyer> Right. I'm just more of a team player than that.
[23:34] <arraybolt3> I'm still going off Simon's "keep the delta as small as you can" training :P so it might just be two different styles of packaging
[23:34] <Eickmeyer> arraybolt3: If you wouldn't mind, could you file a bug report against the package and mention that tag and mention the fix is adding python3-all to Depends in debian/tests/control ?
[23:34] <arraybolt3> sure
[23:34] <Eickmeyer> I believe severity is `serious` since it breaks policy. :)
[23:35] <Eickmeyer> tsimonq2: can correct me if I'm wrong ^
[23:36] <Eickmeyer> arraybolt3: But yeah, if it's a simple fix like this, my recommendation is JFDI. The delta is still pretty dang small.
[23:36] <arraybolt3> +1
[23:42] <tsimonq2> Deferring judgement on the bug status, +1 to the rest.
[23:44] <tsimonq2> Eickmeyer: size of the Ubuntu delta> I mean, it's a grey area. Back in the day, (generally) my sponsors insisted on a Debian-first approach, and not to upload to Ubuntu when we can just wait for Debian. These days, I take a pragmatic middle ground approach, but still give the general advice of "keep the delta as small as possible, send as much up to Debian as you can."
[23:46] <Eickmeyer> tsimonq2: My approach is "Get it fixed in Ubuntu, but let Debian know something's up. Sync it from Debian when it's fixed."
[23:47] <tsimonq2> Eickmeyer: I think it all depends on release cycles. I don't think there's an official "apply this to everything" solution.
[23:47] <Eickmeyer> Agreed.
[23:48] <Eickmeyer> Case-by-case basis.