[10:09] <bluca> mmh the amd64 build of llvm-defaults has fallen off noble, is that still due to the archive rollback for xz?
[10:10] <bluca> bunch of CIs trying to install 'clang' are failing
[10:10] <juliank> yup
[10:12] <juliank> bluca: Hopefully the faux regressions are sorted out with the migration reference tests running now/shortly and it should be migrateable later today
[10:13] <juliank> bluca: But essentially we cleaned out -updates yesterday, where the old llvm-defaults was in
[10:14] <bluca> got it, thanks
[10:17] <adrien> rbasak: I just (finally?!) noticed that "git gui" removes leading spaces on the first line of commit messages which is an issue when generating the changelog; do you have thoughts about automatically adding two spaces to any line in the commit message that would be missing them?
[10:18] <adrien> rbasak: that seems minimal and it would prevent completley-broken changelogs; they might not be perfect if something goes undetected by human review but at least they won't be entirely broken
[10:21] <rbasak> adrien: this is for git-reconstruct-changelog?
[10:22] <adrien> yes, sorry I didn't make that explicit :P
[10:23] <rbasak> adrien: the current implementation is a dumb hack. A number of people have had suggestions to improve how it works, and I'm very much in favour of making it better!
[10:23] <adrien> great, I'll try to find some time to do what I outlined above
[10:23] <rbasak> adrien: my only request is that someone figures out a written spec of how it should behave first, since otherwise I fear a confusion of pile-on changes leading to confusing behaviour.
[10:24] <adrien> ok, got it
[10:24] <rbasak> adrien: I think some people on my team would be interested in such a spec - bryceh and kanashiro I think, maybe others?
[10:24] <rbasak> adrien: once a spec is agreed, then I'd be happy to accept patches that bring towards it.
[10:24] <adrien> I'll also try to think about ways to keep the second line of the commit message empty (but I'm not sure there are ways to do it)
[10:26] <rbasak> I think someone was seeking for compatibility with gbp-dch, too.
[10:31] <adrien> I'll keep that in mind, that could be interesting indeed
[10:35] <rbasak> adrien: I also wondered if we could do something like, as an option, providing the precise entry in the main body between some kind of special markers, allowing the rest of the text to be free form that doesn't end up in the changelog. If the markers are detected then use those, otherwise fall back to other behaviour.
[10:36] <rbasak> adrien: also, while splitting, the ability to simply copy and paste directly without any additional formatting makes things nice and quick, so it'd be nice to be able to keep that.
[10:36] <rbasak> So there would be like three or four different modes that the spec would ideally accommodate. But if something has to be sacrificed, I'm fine with that as long as it was a considered, deliberate decision.
[10:37] <rbasak> I'm quite happy just to make suggestions and let others drive and decide what the final spec should look like.
[10:37] <adrien> I think I like the marker approach
[10:37] <juliank> while we're at it I just thought maybe we should add change-id to the commits
[10:38] <juliank> Then you can identify reliably which changes are dropped in a rebase
[10:38] <adrien> it might be good to hand out an appropriate template to editors but that's very easy to do
[10:39] <rbasak> juliank: is git-range-diff not sufficient for you? I've found that to be reliable enough.
[10:39] <juliank> I can't say I ever used that
[10:39] <rbasak> Please try it. It's game changing for this kind of work :)
[10:42] <kanashiro> I had a draft branch where I was trying to add annotations like Gbp-Dch. One could specify if you want the full commit message in the changelog or just the summary (first line) But I stopped my work on this at the spec stage, I'd be happy to contribute to that.
[10:45] <adrien> kanashiro: do you have a link to that?
[10:46] <rbasak> I tried to find it earlier but couldn't :0/
[11:03] <ginggs> @pilot in
[12:28] <paride> ginggs, green light on https://bugs.launchpad.net/ubuntu/+source/dublin-traceroute/+bug/2060658
[12:28] -ubottu:#ubuntu-devel- Launchpad bug 2060658 in dublin-traceroute (Ubuntu) "dublin-traceroute FTBFS on Noble" [Undecided, Confirmed]
[12:28] <ginggs> paride: thanks :) i'll sponsor
[12:53] <luismi75> Hi. Any chance of having upower 1.90.4 to fix this issue before the release?
[12:53] <luismi75> https://www.phoronix.com/news/UPower-1.90.4-Released
[12:53] <luismi75> I'm seeing the process in my htop all the time, even if I'm not doing anything.
[12:57] <rbasak> sudip: in bug 2056361, FWIW "Origin: Debian, ..." isn't valid according to https://dep-team.pages.debian.net/deps/dep3/. Would you like to fix it, or it's not important enough so I can just accept anyway/
[12:57] -ubottu:#ubuntu-devel- Bug 2056361 in python-qrencode (Ubuntu Jammy) "[SRU] python3-qrencode fails with SystemError about PY_SSIZE_T_CLEAN macro" [Undecided, Confirmed] https://launchpad.net/bugs/2056361
[12:57] <rbasak> ?
[12:57] <schopin> luismi75: not promising anything, but you'll have much better chances of seeing any bug fixed in Ubuntu if there's a matching Launchpad bug.
[12:57] <rbasak> I'm not aware of anything automatic that parses dep3 headers!
[12:59] <schopin> I think Debian has some tooling in the tracker that does, but I'd agree that it's not important enough to reject an SRU upload :P
[12:59]  * schopin has probably written plenty of invalid Origin fields.
[13:00] <sudip> rbasak: I think, it should have said Origin: vendor, <link>  :(
[13:02] <sudip> but, will be great if you can accept it please
[13:04] <rbasak> Sure, I'll accept. Thanks. I just like to give people the option since some prefer to fix it first, just for appearances.
[13:06] <sudip> rbasak: I would have, but then that will go back to sponsors queue  as I dont have upload rights and with every one busy with Noble that will take a long time :)
[13:07] <luismi75> schopin: I added the bug report. I didn't want to do it because they said "don't open issues to create a new package", but I think it was for packages not included yet in the repo. Thanks!
[15:04] <ginggs> @pilot out
[15:04] <ginggs> thank you for flying Ubuntu Air!
[15:10] <adrien> no boeing plane involved
[15:39] <jbicha> @pilot in
[15:47] <sudip> how do I request removal from Noble for some Ubuntu native packages? they will fail to install without gconf2
[15:52] <jbicha> sudip: you can either file a bug and subscribe ubuntu-archive or you can ask "ubuntu-archive" here
[15:54] <rbasak> Time to send "New component-mismatches" to /dev/null I think :-/
[15:55] <sudip> thanks jbicha, lets try here first
[15:57] <sudip> ubuntu-archive: the packages "ubuntu-business-defaults" and "ubuntu-defaults-nl-nl" needs gconf2 which is not available in Noble and so can not be installed. Can these be removed please.
[15:57] <sudip> and also "ubuntu-defaults-zh-cn".
[16:04] <jbicha> sudip: none of those packages depend on gconf2
[16:04] <cpaelzer> I feel those might need Desktops attention to become installable, or at least update the source packaging to not just regenerate it in a bad way. Localization sounds like desktop, I'm not even sure.
[16:04] <cpaelzer> jbicha: do you know these, I've not even seen the direct dependency
[16:04] <cpaelzer> oh there you are, two people same thought
[16:04] <sudip> jbicha: it doesnot from d/control, but if you try to install they will fail in postinst - "update-gconf-defaults: not found"
[16:05] <sudip>  /var/lib/dpkg/info/ubuntu-defaults-nl-nl.postinst: 7: update-gconf-defaults: not found
[16:05] <jbicha> sudip: oh, are you interesting in fixing ubuntu-defaults-builder which is where the gconf handling comes from? Then we can just rebuild those other packages to fix the issue
[16:08] <sudip> ohh.. sure, I can check
[16:10] <jbicha> (the correct channel to ping ubuntu-archive is #ubuntu-release but it looks like we don't need Archive Admins to fix this issue)
[22:18] <rbasak> sudip: then that will go back to sponsors queue> sorry I missed that before. For trivial changes I can just fix up and re-sponsor for you - we'll bend the "SRU reviewer can't sponsor" rule for trivial things like that to save the sponsorship delay.
[22:19] <rbasak> But I've accepted it now so it doesn't matter.
[22:19] <rbasak> Although sometimes I would like a sponsors ack for a change I request wearing my SRU hat. That didn't apply here though.
[22:19] <rbasak> sponsor's
[22:20] <sudip> I will remember next time, thanks rbasak
[22:20] <rbasak> np. Just trying to explain my logic to hopefully help with the future :)
[22:26] <arraybolt3> Maik: (Pinging you on IRC too just in case you didn't see Matrix/Telegram) Are you around? I'm trying to fix a bug in Kubuntu and Ubuntu Unity's installer in 24.04 (https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/2060879), and need to get permission for the Ubuntu Unity Noble Beta ISO to be respun for it to get through. I'm willing to do the testing work for Ubuntu
[22:26] -ubottu:#ubuntu-devel- Launchpad bug 2060879 in calamares-settings-ubuntu (Ubuntu Noble) "pkgselect module is broken in Kubuntu and Ubuntu Unity" [Undecided, New]
[22:26] <arraybolt3> Unity resulting from the respin if necessary.
[23:10] <bryceh> @adrien, regarding markers and annotation in git commits, if you're not already familiar with git-ubuntu's --CL--, then you may be interested in watching https://drive.google.com/file/d/1u2BFk-UwxxlGPK9NJqi5wchexUKTuPte/view
[23:12] <bryceh> @adrien Christian also scheduled a meeting at the sprint, Thursday morning in the server room, to discuss Distro delta handling and use of this style of annotation for tracking delta disposition alongside the corresponding changelog entry.
[23:15] <bryceh> the --CL-- approach makes some of the git/changelog formatting problems into non-issues, so see what you think
[23:46] <jbicha> @pilot out