[00:45] <arraybolt3> https://bugs.launchpad.net/ubuntu/+bug/2046086 I would like to get this new package (picom-conf) into the archive for Lubuntu. Could tsimonq2 and perhaps LocutusOfBorg review it? It's not being submitted directly to Debian yet because Ubuntu has a build-time dep of picom-conf that is not present in Debian now, and this is going to provide an
[00:45] <arraybolt3> intended Lubuntu feature, so I'd like to get it in sooner.
[00:45] -ubottu:#ubuntu-devel- Launchpad bug 2046086 in Ubuntu "Please package picom-conf" [Wishlist, New]
[00:46] <arraybolt3> I've already done the packaging, and it seems to work in testing. Also I do intend on doing the needed work to get this into Debian.
[01:18] <tsimonq2> vorlon: ^^^ We had a discussion regarding MIT vs Expat in #l-devel, this is another package falling into that pattern.
[01:21] <vorlon> tsimonq2: discussing what, exactly?
[01:23] <tsimonq2> vorlon: I think the discussion is slightly pedantic, but in my notes of things to review I have <vorlon> tsimonq2: lxqt-themes-extra> "License: MIT" is wrong, this should say "Expat"
[01:23] <vorlon> yes, this is documented in the Debian copyright spec
[01:26] <tsimonq2> "There are many versions of the MIT license. Please use Expat instead, when it matches." Oh, I see.
[01:27] <tsimonq2> vorlon: The argument I heard in favor of "just saying MIT" is, upstream explicitly declares it as the MIT license. If both license texts are the same (from what I can tell, they are), what is the importance of the license *name*, if upstream says one thing explicitly?
[01:28] <tsimonq2> (I happen to be convinced we should just say Expat at this point, but curious to get the wider picture.)
[01:34] <arraybolt3> What about MIT (Expat)? That should satisfy upstream's choice and Debian's recommendation.
[01:35] <arraybolt3> (assuming of course that upstream used the Expat license and called it MIT)
[01:35] <arraybolt3> (which the above package does)
[02:56] <vorlon> tsimonq2, arraybolt3: upstream calling the license one thing or another isn't relevant, the license text is relevant; and the Debian copyright spec says to refer to it as Expat because "MIT" is ambiguous.  "MIT (Expat)" is also not a valid license short name in the spec.
[02:59] <arraybolt3> vorlon: "MIT (Expat)" is non-ambiguous. Also I think we should consider the labor of copyright file updaters (me oftentimes). It can be difficult to deal with packages in which we have to mentally "transform" the licenses we're looking at into something we can put into debian/copyright. The GPL long-form license headers are infamous for this in my
[02:59] <arraybolt3> experience, but having to look at MIT and think "ugh, no, that's Expat" is not exactly condusive to the update process. MIT (Expat) at least gives me a bit of a connection so that I don't get hung up quite so easily. (In practice this is unlikely to be a big deal, but it might make a bit of a difference, and when you have to sift through upwards of
[02:59] <arraybolt3> a thousand files in one session, small differences can add up.)
[03:00] <arraybolt3> That being said, if you're determined to keep it "Expat", and only "Expat", I will update it, but that's some of my reasoning as to why I'd rather not.
[03:04] <arraybolt3> (I should also note that Debian policy does not enforce the use of short names, and the document at https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name says that the standard short names **can** be used in the synopsis (first line) of a License field. Assuming RFC 2119 applies here, "can" isn't "must" or even
[03:04] <arraybolt3> "should".)
[03:07] <arraybolt3> also of interest is that the copyright file spec has "MIT" being used as a license identifier in its Example 4 :P
[03:26] <vorlon> arraybolt3: "MIT (Expat)" is not valid syntax.  If you're going to claim that your copyright file conforms to the machine-readable copyright spec, then you should do the work to actually make it conform
[03:27] <arraybolt3> Fair enough. Will fix it.
[05:20] <arraybolt3> And it is now fixed.
[07:42] <LocutusOfBorg> arraybolt3, why are you setting Release build type?
[07:44] <LocutusOfBorg> arraybolt3, to have a package in Debian, ITP is the way
[07:45] <LocutusOfBorg> $ reportbug -b wnpp
[07:45] <LocutusOfBorg> does the job for you :)
[07:46] <LocutusOfBorg> also, why no manpage? help2man is handy
[07:51] <LocutusOfBorg> or maybe for graphical tools help2man is useless
[07:51] <LocutusOfBorg> so the Release build type is the only thing I don't get
[08:21] <LocutusOfBorg> that said, if you open an ITP we can probably just upload in Debian, and let the autosync stuff kick in
[09:13] <ogayot> tsimonq2: quote from https://wiki.ubuntu.com/UbuntuDevelopment/Merging: "Attach these debdiffs to the bug report, un-assign yourself, set the status to "confirmed" and subscribe (not assign!) the relative sponsor[...]"
[09:13] <ogayot> tsimonq2: and from https://wiki.ubuntu.com/SponsorshipProcess: "Do not assign a bug to anyone if it needs sponsorship."
[09:17] <ogayot> ^ I've always found this confusing
[10:03] <ogayot> May I kindly ask someone to retrigger this build for me? Thanks! https://launchpad.net/ubuntu/+source/lomiri-download-manager/0.1.2-2ubuntu1/+build/27060196
[10:54] <mkukri> can i get the efibootmgr 18-1 build re-triggered? or do i need to get a re-build upload sponsored? I think FTBFS got fixed by the last efivar sync, and it builds fine in my PPA: https://launchpadlibrarian.net/702013145/buildlog_ubuntu-noble-amd64.efibootmgr_18-1build2_BUILDING.txt.gz
[11:48] <LocutusOfBorg> Eickmeyer, if you need sponsoring in Debian to avoid delta, w.r.t. LP: #2046007 please feel free to ask here
[11:48] -ubottu:#ubuntu-devel- Launchpad bug 2046007 in Ubuntu "Please sync signond from Debian" [Undecided, New] https://launchpad.net/bugs/2046007
[11:49] <LocutusOfBorg> usually a simple ping is enough to get the delta uploaded in Debian, and forget about merges
[12:00] <waveform> @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: waveform
[14:00] <tsimonq2> ogayot: Hrmmmm, I wonder why. After all, that karma belongs to you, and that bug should still be assigned to you. Especially with some of the larger bugs, it's easier to just look at the assignee on the top. You could argue that it should be reassigned to the sponsor; after all, technically they hold responsibility since it's their key. Unassigning it though, that seems unhelpful...
[14:01] <tsimonq2> I see ogayot's retry request has been handled, mkukri did you want those depwaits retried, or is that expected on your end?
[14:02] <tsimonq2> waveform: Not looking at the queue today, by the way. I hope it stayed relatively clean. Thanks for being in the cockpit. :)
[14:02] <mkukri> tsimonq2: it's expected, those are depwaits in debian too. we don't build efi stuff for those arches
[14:02] <tsimonq2> mkukri: Kinda figured, thanks!
[14:13] <tsimonq2> PSA, probably for +/- ~= Foundations: https://launchpad.net/ubuntu/+source/pcre2/10.42-4ubuntu1
[14:13] <tsimonq2> That can be understood in the context of https://answers.launchpad.net/launchpad/+question/708661
[14:16] <arraybolt3> LocutusOfBorg: The Release build type is actually a leftover from the packaging I used as a base (a tool from the same family of tools picom-conf) is in. I didn't try building without it, but it looked sane (usually you want either nothing at all, or Release, or RelWithDebInfo), so I left it. It was used in a closely related tool, so it may be
[14:16] <arraybolt3> helpful.
[14:17] <arraybolt3> (gah, move "is in" into the parentheses and the sentences make more sense)
[14:17] <tsimonq2> https://github.com/qtilities/sddm-conf/ - in the README, that has Release explicitly there. I have a note to follow up on that but didn't get far. :P
[14:17] <tsimonq2> I think LocutusOfBorg is right, though.
[14:18] <arraybolt3> Ah.
[14:18]  * arraybolt3 checks a thing
[14:18] <arraybolt3> https://github.com/qtilities/picom-conf/ Well look at that, same note :)
[14:19] <arraybolt3> So Release is valid for both of them.
[14:20] <arraybolt3> LocutusOfBorg: picom-conf upstream recommends setting the Release build type for picom-conf.
[14:20] <arraybolt3> (sigh, my typing makes it apparent that I just woke up.)
[14:20] <LocutusOfBorg> arraybolt3, release is Valid doesn't mean RelWithDebInfo is better :)
[14:21] <LocutusOfBorg> usually "Release" is not adding "-g" flag, so the build doesn't produce debug symbols
[14:21] <LocutusOfBorg> this is why we use in Debhelper/dpkg automatic RelWithDebInfo :)
[14:21] <LocutusOfBorg> I'm checking both logs right now
[14:21] <LocutusOfBorg> picom-conf_0.17.0~git20231210-0ubuntu1~ppa4_source.changes
[14:22] <arraybolt3> s/is/isn't/? I think you meant to say RelWithDebInfo is better.
[14:22] <arraybolt3> Just trying to make sure I understood what you meant.
[14:22] <LocutusOfBorg> yes
[14:22] <LocutusOfBorg> https://launchpadlibrarian.net/701984434/buildlog_ubuntu-noble-amd64.picom-conf_0.17.0~git20231210-0ubuntu1~ppa3_BUILDING.txt.gz
[14:23] <LocutusOfBorg> looks like no debug symbols?
[14:23] <LocutusOfBorg> and upstream is right at saying "use release", because nobody is expecing you to strip if you build manually
[14:24] <arraybolt3> I guess theoretically RelWithDebInfo probably won't hurt anything.
[14:25] <arraybolt3> tsimonq2: since I'm going to be very busy in a couple hours most likely, and you're the one with the initial rationale, can I leave this discussion in your capable hands?
[14:25] <arraybolt3> (I'll fix picom-conf again if needed.)
[14:27] <arraybolt3> I am leery of departing from upstream recommendations though unless Debian policy or a very good reason presents itself, since otherwise we can trigger things we didn't mean to in ways we didn't expect. It's unlikely to happen here, but it's code, anything can happen :P
[14:28] <arraybolt3> Perhaps having debuginfo packages is a very good reason though.
[14:33] <arraybolt3> Sigh, yeah, it really is a good reason. Alright, I'll fix it.
[14:34]  * arraybolt3 had flashbacks of fighting with an Ubuntu MATE package after glib dropped the slice allocator and realized how critical debug symbols can be sometimes
[14:34] <tsimonq2> arraybolt3: Happy to be your rubber ducky <3
[14:40] <LocutusOfBorg> arraybolt3, so, now if you remove that line on rules file, or ask upstream about it
[14:41] <LocutusOfBorg> and open an ITP... we can go directly in sid?
[14:41] <arraybolt3> Should be doable, yes. (If you want me to file prior to upload to both Sid and Noble that would be fine.)
[14:42] <arraybolt3> (I would like for it to be fast tracked into Noble for Lubuntu development's sake, but have no problems making its introduction into Sid easy.)
[14:42] <arraybolt3> Oh, one thing
[14:43] <arraybolt3> There's a build dep that needs in Sid first.
[14:43] <arraybolt3> qtilitools in particular
[14:43] <arraybolt3> It's already been uploaded to Ubuntu, but is not present in Sid yet.
[14:43] <tsimonq2> LocutusOfBorg: Context: for some NEW packages this cycle, I uploaded to both Sid and Noble at the same time, to get the benefits of whatever queue reviewed first. ;P
[14:44] <tsimonq2> (As Lubuntu RM, decision was made to frontload the vast majority of the QA this cycle; so this works, but is not typically how I'd like to do it (e.g. straight to Debian))
=== arraybolt3 is now known as arraybolt3_tl
[16:01]  * tsimonq2 shamelessly dmb-pings...
[16:01] <tsimonq2> !dmb-ping
[16:01] <ubottu> bdmurray, kanashiro, rbasak, seb128, sil2100, teward, utkarsh2102: DMB ping
[16:11] <mmikowski> We did a full desktop check on 5.27.10 on Kubuntu 22.04 LTS. No regressions were found. Besides the normal test suite, we checked for issues that were testable from the published 5.27.10 change log. This release appeared more stable when changing themes, with no plasma shell resets.
[16:12] <tsimonq2> mmikowski: Hey, not sure if Rik mentioned it or Just Did It already, but I heard word about an SDDM update coming down the pike.
[16:13] <mmikowski> I haven't heard about that but could ask Nate Graham.
[16:13] <tsimonq2> It's not an SDDM release, it's a packaging update. :)
[16:13] <tsimonq2> (Tell Nate I say hi! And would like five of his time one of these days :D)
[16:13] <tsimonq2> mmikowski: Oh wait, are we in #ubuntu-devel, not #kubuntu-devel? :O
[16:14] <mmikowski> If shoot! My bad! I will move my comment there. Sorry everyone!
[16:15] <mmikowski> tsimonq2 see you on the over there?
=== arraybolt3_tl is now known as arraybolt3
[16:15] <tsimonq2> mmikowski: absolutely :)
[16:53] <waveform> @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
[18:25] <sergiodj> tjaalton: hi, re. https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2015562, I don't see the difference you mentioned in the last comment. maybe I'm missing something, but man/dnsmasq.8.orig already exists in the source package currently in Jammy
[18:25] -ubottu:#ubuntu-devel- Launchpad bug 2015562 in dnsmasq (Ubuntu Jammy) "[SRU] Segfault in dnsmasq when using certain static domain entries + DoH (bugfix possibly exists upstream)" [Undecided, In Progress]
[18:42] <tjaalton> sergiodj: it shows in http://launchpadlibrarian.net/699406697/dnsmasq_2.86-1.1ubuntu0.2_2.86-1.1ubuntu0.4.diff.gz
[18:44] <tjaalton> sergiodj: ahah, it got added in the security update then :)
[18:44] <sergiodj> tjaalton: but that includes the security upload, which is already there
[18:44] <sergiodj> exactly
[18:45] <sergiodj> Miriam's upload only modifies the files listed in the changelog :)
[18:45] <sergiodj> let me know how you'd like to proceed.  I can reupload if needed
[18:46] <tjaalton> it should be recoverable from the rejected queue, but not sure how
[18:48] <ahasenack> you can run sru-review from the reject queue
[18:48] <ahasenack> if you were about to accept it
[18:49] <ahasenack>   -q QUEUE, --queue=QUEUE
[18:49] <ahasenack>                         Use a specific queue instead of Unapproved
[18:49] <tjaalton> ah
[18:49] <ahasenack> don't know how to specify it exactly if there happen to be multiple same versions in the rejected queue
[18:49] <ahasenack> in the ui you just select it
[18:51] <tjaalton> there are two on the rejected queue..
[18:51] <ahasenack> same version?
[19:00] <tjaalton> no
[19:01] <tjaalton> so, not an issue with -e