=== JanC is now known as Guest2050
=== JanC_ is now known as JanC
[08:05] <artur> Hello, could somebody help to check this SRU ticket please? https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/2042902
[08:05] -ubottu:#ubuntu-devel- Launchpad bug 2042902 in OEM Priority Project "ucm2: soundwire: add rt713 SDCA device" [Critical, In Progress]
[08:13] <locutusofborg_> lvoytek, hello, quick question:
[08:13] <locutusofborg_> +liblua5.4-c++.so.0 liblua5.4-0 #MINVER#
[08:13] <locutusofborg_> + LUA_5.4@LUA_5.4 5.4.6-2
[08:13] <locutusofborg_> + lua_ident@LUA_5.4 5.4.6-2
[08:13] <locutusofborg_> this is what I got after trying to build your branch
[08:19] <locutusofborg_> so, just one symbol exported in c++ library... interesting
[08:35] <locutusofborg_> lvoytek, I guess the version-script file was wrong
[08:35] <locutusofborg_> not the patch
=== locutusofborg_ is now known as locutusofborg
=== locutusofborg is now known as LocutusOfBorg
[09:26] <mkukri> added the xf86-synaptics merge now to the queue, had misunderstood what was going on because sbuild thought it was a native package because i failed to manually pull the orig tarball. still done a bit of cleaning up to the ubuntu delta
[11:54] <LocutusOfBorg> lvoytek, how do you feel about grabbing this debian dsc file http://debomatic-amd64.debian.net/distribution#unstable/lua5.4/5.4.6-2/lintian
[11:54] <LocutusOfBorg> and committing the content on top of your merge request?
[11:54] <LocutusOfBorg> http://debomatic-amd64.debian.net/debomatic/unstable/pool/lua5.4_5.4.6-2/lua5.4_5.4.6-2.debian.tar.xz
[11:54] <LocutusOfBorg> this is the tarball, I made the package more lintian clean
[12:03] <slyon> @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: slyon
[12:41] <LocutusOfBorg> sergiodj, hello! Do you think Adrien Nader is here on irc?
[12:42] <LocutusOfBorg> I would like to understand something related to this: https://launchpad.net/ubuntu/+source/gnutls28/3.8.1-4ubuntu3
[12:42] <LocutusOfBorg> you disabled tls1.0 and tls1.1, the question is: do we have a way to retrieve programmatically if a specific suite is supported?
[12:42] <LocutusOfBorg> context is: libfilezilla testsuite fails when trying to use tls1.0 and tls1.1
[12:42] <LocutusOfBorg> https://trac.filezilla-project.org/ticket/13005#comment:4
=== guiverc2 is now known as guiverc
[13:04] <adrien> LocutusOfBorg: o/
[13:04] <adrien> and I think sergiodj is off at the moment
[13:06] <adrien> LocutusOfBorg: define "programmatically"
[13:06] <adrien> as a sysadmin, as a software developer, as something else?
[13:07] <LocutusOfBorg> software developer
[13:07] <LocutusOfBorg> as said the app testsuite is trying to emulate a tls1.0 channel for torrent
[13:07] <LocutusOfBorg> but it obviously fails
[13:07] <LocutusOfBorg> https://trac.filezilla-project.org/ticket/13005#comment:4
[13:08] <adrien> as far as I know, it's not possible
[13:09] <adrien> the openconnect developers were asking for one too (let's say it's related but they chose to break system-wide configuration of gnutls in their software)
[13:10] <adrien> two things: a) we said years ago that we were disabling TLS 1.0 and 1.1 on Ubuntu but for gnutls-based applications, this was not very effective and in practice probably most often overriden
[13:12] <adrien> b) there's a difficulty there indeed: if we want to disable TLS-foo system-wide, or even SSL-bar, tests using these should fail; if they didn't that would mean we're not testing properly, but the code is there and we're letting users re-enable it...
[13:14] <adrien> I don't have the one-true-answer to this but there are a few ways: if, as I want in the medium-term, we get configuration profiles, one of the profiles could be lenient and still enable all of these protocols, which would let us test them but that wouldn't be cross-distro probably (I don't know if filezilla on windows uses gnutls; I don't know if there's a system-wide gnutls configuration on windows
[13:14] <adrien> either)
[13:15] <adrien> but also, it's possible to temporarily hide the system-wide configuration
[13:15] <LocutusOfBorg> adrien, probably I wasn't clear:
[13:16] <LocutusOfBorg> I want something that can be upstream like
[13:16] <LocutusOfBorg> if(tls1.0 supported in conf) then run test; else skip
[13:16] <adrien>  with gnutls you can set GNUTLS_SYSTEM_PRIORITY_FILE=/dev/null IIRC, and it'll let you use whatever would be disabled system-wide
[13:16] <LocutusOfBorg> yeah I saw too :/
[13:17] <adrien> I understood but as I said: as far as I know, this API doesn't exist in gnutls or openssl
[13:17] <adrien> I think that setting the env var makes sense for testsuites
[13:18] <LocutusOfBorg> and change something like GNUTLS_TLS_VERSION_MAX ?
[13:18] <LocutusOfBorg> I mean during gnutls build, define it
[13:18] <LocutusOfBorg> so we know and can use it
[13:18] <LocutusOfBorg> if tls_ver >= GNUTLS_TLS_VERSION_MIN then run test
[13:22] <adrien> as a ubuntu-specific patch?
[13:23] <adrien> but I also agree that if the code exists, it would be good to test it; that's why I think setting the env var would be a good solution typically
[13:24] <LocutusOfBorg> yeah indeed
[13:25] <LocutusOfBorg> if we can ask gnutls people to export a new GNUTLS_TLS_VERSION_MIN variable, we should be good, right?
[13:25] <LocutusOfBorg> define as TLS1.2 in Ubuntu and start using it
[13:26] <adrien> btw, about using the env var: for instance, exim will have TLS 1.0 and 1.1 disabled due to the gnutls change and I think that is likely going to be changed by more than one sysadmin so I expect many deployments to re-enable it
[13:28] <adrien> for the variable and expanding the API, I haven't discussed that with gnutls upstream so far because the current maintainer works at RH I think and RH has had "crypto-policies" for a while now, with pretty much the same topics, and several RH people have been discussing it and I think they mentioned a similar need, yet it didn't materialize yet; I couldn't find a reference right now but it's not
[13:28] <adrien> really a new topic so I don't expect immediate or even medium-term changes
[13:31] <LocutusOfBorg> ack, looks good for me
[13:31] <LocutusOfBorg> I contacted Debian maintainer to export the variable
[13:36] <adrien> and ftr, I would like to have system-wide consistent configuration for cryptography but this is still being specified (although it's very advanced) and there will clearly be some work to implement it (no, it cannot be like RH's crypto-policies, for the same reason only RHEL is RHEL)
[14:21] <tsimonq2> @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: slyon, tsimonq2
[14:22] <tsimonq2> This'll be a short flight, just doing the usual "one or two" today.
[14:22] <tsimonq2> slyon: If you're still in the cockpit, feel free to coordinate.
[14:23] <tsimonq2> slyon: More precisely, are you looking at any of mkukri's merges? I may just do those today.
[14:26] <slyon> tsimonq2: Yes, I'm currently looking into zlib. So please skip that
[14:26] <tsimonq2> slyon: Didn't plan on touching zlib, all yours. :)
[14:28] <tsimonq2> mkukri: Per yesterday's discussion, I've marked this as "Needs Resubmitting." Happy to change my review state if you're confident this should still go in Ubuntu. https://code.launchpad.net/~mkukri/ubuntu/+source/xserver-xorg-input-synaptics/+git/xserver-xorg-input-synaptics/+merge/456418
[14:28] <mkukri> i think it should, and debian didnt really have an issues i just had a misunderstanding of 1.0 source format packages
[14:29] <mkukri> but it's a pretty straightforward ubuntu merge now, it is just a 1.0 package, and the tools thought it was native because i forgot to the pull the orig tarball.
[14:30] <tsimonq2> Ah, cool. tjaalton you have first round on this one, I'll wait a few days Just To Be Safe before I circle back myself.
[14:33] <mkukri> the rest of my universe merges are farily simple hopefully
[14:36] <lvoytek> LocutusOfBorg: Added your changes to the lua merge request
[14:37] <LocutusOfBorg> thanks!
[14:46] <tsimonq2> mkukri: Why should ayatana-indicator-datetime be a merge and not a sync? All three of those build dependencies you're removing have been in the archive since Lunar (at the latest).
[14:47] <tsimonq2> Also, librelp has the extra changelog line. :P
[14:48] <mkukri> ah i didnt know, i will request a sync. ive already done that on another ayatana thing with outdated delta
[14:49] <tsimonq2> Thanks! :)
[14:51] <mkukri> filed sync request and deleted mp
[14:58] <tsimonq2> Done. For your own notes, I just ran `syncpackage -f -s mkukri -b 2045041 ayatana-indicator-datetime`
[14:58] <mkukri> thanks
[14:58] <tsimonq2> No worries.
[15:01] <tsimonq2> mkukri: presage> Just be careful that you're preserving everything that was dropped/preserved in your changelog entry. I'm seeing "Remove python-wxgtk3.0 from Build-Depends" which was upstreamed (and not in your merge diff) but not noted. Not a blocker, but verbose changelogs in that respect are Usually a good idea.
[15:01] <mkukri> yeah sorry, i didnt know what to do with that, because the previous changelog saying that it is a remaining change was already wrong, so i technically wasnt preserving or removing anything
[15:02] <tsimonq2> Oh, okay. That makes a lot of sense.
[15:03] <tsimonq2> Also, I'm seeing an Ubuntu-specific patch defaulting to Python 2. I don't know if we even ship that by default anymore... have you guaranteed that's pulled in somehow?
[15:03] <tsimonq2> (And/or is that patch droppable?)
[15:03] <mkukri> hmm it might not be, it could have been the case that that changelog entry also referred to that patch, and ive only kept the d/p/foo.patch line
[15:04] <mkukri> but i have not removed any changes that werent upstreamed into debian afaik
[15:05] <tsimonq2> Yeah, that patch still exists.
[15:05] <mkukri> i believe there is a line for it too, so i guess ive only dropped a duplicate changelog entry
[15:05] <tsimonq2> Also, for the patches: https://dep-team.pages.debian.net/deps/dep3/
[15:06] <tsimonq2> mkukri: I'll leave more detailed comments on the MP, but probably coming back to this one.
[15:15] <tsimonq2> mkukri: Done. You've generally been doing a pretty great job (see how many uploads I *did* review and sponsor for you today!) - keep up the great work. :)
[15:16] <tsimonq2> On that note, I'll be around, but not actively piloting. Thanks again.
[15:16] <tsimonq2> @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: slyon
[15:16] <mkukri> Thank you
[15:16] <tsimonq2> Of course, happy to help!
[15:31] <slyon> @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
[16:07] <lvoytek> @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: lvoytek
[16:11] <tsimonq2> 🎉🎉🎉🎉🎉🎉
[18:32] <ogayot> lvoytek: thanks for sponsoring nvme-stas!
[18:50] <tsimonq2> juliank: xfsprogs> It works, thanks for your help!!
[18:53] <lvoytek> ogayot: Sure thing, thanks for the patch!
[18:59] <juliank> tsimonq2: yw
[20:00] <lvoytek> @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
[20:16] <Eickmeyer> Anybody know where the docs are on building a snap like a recipe in launchpad?
[21:07] <Eickmeyer> Nvm, figured it out.
=== JanC is now known as Guest1745