[05:04] <artur> Hello, can someone help to sponsor this? Thanks. https://bugs.launchpad.net/ubuntu/+source/systemd-hwe/+bug/2046687
[05:04] -ubottu:#ubuntu-devel- Launchpad bug 2046687 in OEM Priority Project "Add three Dell platforms to sensor accel location base" [Critical, In Progress]
[19:48] <sudip> tsimonq2: just tried your suggested "quilt header --dep3 -e" with a Debian package but it did not insert the headers. I will try the same on a Ubuntu system
[22:16] <tsimonq2> sudip: Are you in the appropriate directory, and is the patch a) created, b) on the top of the stack, and c) without any existing headers (you can copy those over to another text file and ref if you'd like)?
[22:17] <tsimonq2> Those are all the reasons that it would not work, in my experience.
[22:22] <tsimonq2> artur on the OEM Priority Project (please direct my message to them via Canonical channels): bug 2046687 seems mostly reasonable on first glance. That being said, a) I would increase the verbosity of the SRU paperwork here, unless the SRU Team feels it's appropriate to fasttrack in this case, b) it's a Foundations branch, but please subscribe sponsors regardless, and c) this may not land until the
[22:22] -ubottu:#ubuntu-devel- Bug 2046687 in OEM Priority Project "Add three Dell platforms to sensor accel location base" [Critical, In Progress] https://launchpad.net/bugs/2046687
[22:22] <tsimonq2> new year, not sure if this is for a client with an SLA, please follow up accordingly/internally. Kind regards.
[22:22] <sudip> tsimonq2: yes, it was the last patch in the series, I removed all existing headers, and applied via `quilt push -a`, and then did quilt header --dep3 -e, it opened the patch header section in editor but did not add dep3 headers to it. I will check again later.
[22:23] <tsimonq2> vorlon, mclemenceau: Simply trying to Do The Right Thing in terms of having *someone* follow up on the above OEM priority bug, but it's clear this should at least be on Foundations' radar. Pinging directly given the time of year. :)
[22:24] <tsimonq2> sudip: Iiiiiiiiiiiinnnteresting. Let me actually find that boilerplate for you.
[22:27] <tsimonq2> sudip: https://sources.debian.org/src/quilt/0.67+really0.67-4/debian/patches/dep3_headers/?hl=75 Here it is.
[22:28] <tsimonq2> bryceh: FYI ^^^^ I seem to remember that you're collecting links.
[22:30] <tsimonq2> sudip: Here's a quick example, in case you'd like to play with getting that working on your end :) https://paste.ubuntu.com/p/FRWMS9tqyC/
[22:30] <sudip> tsimonq2: thanks, and now working
[22:30] <sudip> I did not delete the '---' while removing the headers
[22:30] <tsimonq2> ahhhhhh that'll do it :)
[22:32] <sudip> and the patch you pointed says "if the header is empty"
=== guiverc2 is now known as guiverc
[22:35] <tsimonq2> It is pretty darn fidgety. In an ideal world (I haven't looked too deeply into this), you'd just be able to run e.g. --replace and it would use some kind of heuristics.
[22:36] <tsimonq2> sudip: 🎈 🚀 btw
[22:41] <tsimonq2> Hidden gem, in case anyone (read: patch pilotees) is curious how I compare versions when I can't tell if one is greater than the other:
[22:41] <tsimonq2> $ dpkg --compare-versions 2.0.0~rc7-1ubuntu0.1 gt 2.0.0~rc7-1build1 && echo "Condition met" || echo "Condition not met"
[22:41] <tsimonq2> Condition met
[22:42] <tsimonq2> (gt = "greater than," there's similar flags like "lt" as well.)
[22:45] <tsimonq2> sudip: printrun> You hit the nail on the head, great work!!!! :)
[22:45] <tsimonq2> If I'm being *incredibly* pedantic, I'd ask you to throw the Fedora bug in the DEP-3 header, but that's really no big deal at all. :)
[22:46] <sudip> :)
[22:47] <sudip> btw, LP: #1950959 seems to be an easy fix, will that be accepted for SRU? I know ftbfs are not on top of the list, but this is not ftbfs
[22:47] -ubottu:#ubuntu-devel- Launchpad bug 1950959 in qtcreator (Ubuntu) "Missing dependency in libqt5gstreamer-dev" [Undecided, New] https://launchpad.net/bugs/1950959
[22:48] <tsimonq2> I also happen to be on the Debian Qt/KDE Team (and use qtcreator quite regularly); I'll take a look! thank you :)
[22:51] <tsimonq2> sudip: I'd say the answer to your question of "is this SRUable" is also the answer to this question: is this intended functionality that regressed? From looking at the bug, I think the answer is probably "yes."
[22:52] <tsimonq2> The people on the Debian side of that bug are really good at what they do; I have trust that the fix itself is sane (besides my own analysis).
[22:53] <sudip> yes, but I can argue that the package will only be used to build something else and this problem by itself is not a problem
[22:53] <sudip> which is why I was confused and asked if it is SRU'able ?
[22:53] <tsimonq2> There are tons of packages in the archive that exist only to build something else. :)
[22:53] <tsimonq2> Qt packages are not exempt from SRUs if warranted. ;)
[22:54] <tsimonq2> I am reading the Debian bug though, I do think this would be important to consider, specifically in this case:
[22:54] <tsimonq2>  This class of bug is generally considered to be release-critical, although arguably it might not be RC for libqt5gstreamer-dev if the functionality of libqt5gstreamer-dev is normally located via CMake and only rarely via pkg-config (maintainers: please downgrade if the .pc files are considered to be unimportant in this particular package).
[22:55] <sudip> yes, thats RC because its basically unusable from an users point of view
[22:55] <tsimonq2> Therefore, that suggests (at least to me) that it's somewhat SRUable :)
[22:56] <tsimonq2> Great questions though, I appreciate that you're seeking clarification here!
[22:58] <sudip> its too late in my timezone, I can prepare the debdiff tomorrow unless you have not fixed that already :)
[23:00] <tsimonq2> sudip: I'll wait for you, to give you some practice :) please let me know how I can help! (For the record, I'm US/Central)
[23:01] <sudip> thanks :)
[23:02] <tsimonq2> Of course!