[02:02] <arraybolt3> ginggs: I'm working on satpy now. It does need a merge, but the merge seems to have fixed almost everything. There's one test failure I've not yet figured out, but I think we're close. Should hopefully have an upload ready before tomorrow (depending on timezones and all that).
[02:16] <tsimonq2> arraybolt3: <3
[05:02] <arraybolt3> sooo... I've determined with a fair amount of certainty that satpy is not Python 3.12-ready. The one test failure remaining only happens on Python 3.12, it's a very obscure error about some sort of zero-dimension object (? no clue what that means but it doesn't sound like something was just deprecated and needs a small fix), and trying to install
[05:02] <arraybolt3> upstream satpy using pip in a Python 3.12 venv within a Noble VM is failing quite badly because multiple dependencies are failing to build due to the use of a configparser feature deprecated in Python 3.12
[05:02] <arraybolt3> Ubuntu 22.04 has Python 3.11 and Python 3.10, is Noble expected to have 3.12 and 3.11? If so, would it be an acceptable solution to add a flag to satpy that say "this is Python 3.11 only" somehow?
[05:36] <arraybolt3> I believe I finally have satpy working, have to do one last build to make sure that it works right with proposed in autopkgtesting.
[06:17] <arraybolt3> ginggs: https://bugs.launchpad.net/ubuntu/+source/satpy/+bug/2046322 satpy fix finished and ready for review.
[06:18] -ubottu:#ubuntu-devel- Launchpad bug 2046322 in satpy (Ubuntu) "Merge satpy from Debian" [High, New]
[06:18] <arraybolt3> Thanks for your patience while I figured out what was wrong, and for bringing the entanglement to my attention so I could help with it. :)
[10:40] <Stormer> Canonical needs to publish system requirements for Ubuntu. Its frustrating not being able to find them and is a red flag Ubuntu sucks that I'm having headaches with it before even using it.
[10:43] <LocutusOfBorg> I syncd satpy arraybolt3
[10:43] <LocutusOfBorg> Stormer, https://ubuntu.com/server/docs/installation#:~:text=CPU%3A%201%20gigahertz%20or%20better,a%20minimum%20of%202.5%20gigabytes
[10:44] <LocutusOfBorg> https://help.ubuntu.com/community/Installation/SystemRequirements
[10:44] <Stormer> LocutusOfBorg thanks, but that's for Ubuntu Server.
[10:44] <LocutusOfBorg> not the second one?
[10:44] <LocutusOfBorg> https://xubuntu.org/requirements/
[10:45] <Stormer> LocutusOfBorg thanks, but that's for Xubuntu.
[10:45] <LocutusOfBorg> https://help.ubuntu.com/community/Installation#Minimal%20installations
[10:45] <seb128> Stormer, https://ubuntu.com/download/desktop see 'Recommended system requirements'?
[10:45] <Stormer> LocutusOfBorg that page doesn't have any.
[10:46] <Stormer> seb128 thanks, but that is recommended system requirements, I just want the system requirements.
[10:46] <LocutusOfBorg> Stormer, what is the difference?
[10:47] <Stormer> LocutusOfBorg recommended system requirements is the recommended hardware for the best experience, system requirements are the minimum hardware requirements for it to work.
[10:48] <Stormer> LocutusOfBorg like this: https://ubuntu-mate.org/about/requirements/
[10:48] <LocutusOfBorg> 2 GHz dual-core processor or better 4 GB system memory 25 GB of free hard drive space
[10:48] <LocutusOfBorg> this is already the bare minimum to have a useful user experience
[10:49] <Stormer> LocutusOfBorg that isn't the system requirements. 4 GB is a lot of RAM. Not even Windows 11 needs that much.
[10:49] <Stormer> Ok, my times up. This distro sucks ass bad
[10:49] <LocutusOfBorg> lol trolling people are trolling
[11:14] <Skia> trying to build a package from a `git-ubuntu` tree with `gbp buildpackage` and I get `dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[11:14] <Skia> how do I workaround that?
[11:15] <schopin> Skia: `update-maintainer`
[11:15] <Skia> thanks!
[11:16] <Skia> isn't it strange that this fail with a branch rebased on `ubuntu/devel`?
[11:17] <schopin> Skia: not especially. The ubuntu/devel branch might contain vanilla Debian package if it's in sync
[11:18] <Skia> seems legit
[12:04] <seb128> @pilot in
[12:07] <mirespace> vorlon: I'm fixing a FTBFS in heimdal (bug 2036253)  similar to the one you fixed for krb5. I added as reviewer in the PR, if you have the time.
[12:07] -ubottu:#ubuntu-devel- Bug 2036253 in heimdal (Ubuntu) "FTBFS: missing strl* symbols fail the build" [Undecided, In Progress] https://launchpad.net/bugs/2036253
[12:08] <mirespace> vorlon:s/I added/I added you/
[13:36] <LocutusOfBorg> mirespace, for some reasons I like to have no space between (optional) and the symbol...
[13:37] <LocutusOfBorg> and for noble there is an extra newline on changelog file
[13:53] <mirespace> LocutusOfBorg: Ok, changing it! Thanks for the extra pair of eye  on the changelog
[13:55] <LocutusOfBorg> mirespace, if I can, I'm happy to sponsor
[13:56] <LocutusOfBorg> ping me, maybe with packages on a ppa
[13:56] <LocutusOfBorg> but as you prefer
[13:56] <mirespace> LocutusOfBorg: \o/ Thanks! I'll ping you when the changes are ready
[13:56] <LocutusOfBorg> usually I prefer a dsc on a ppa, this way I also check if it does build :D
[13:56] <LocutusOfBorg> and check build logs
[13:57] <mirespace> and uploaded again to ppa
[13:57] <LocutusOfBorg> ack
[13:57] <mirespace> I have a ppa: ppa:mirespace/heimdal-ftbfs-lp2036253 , but with the thing I have to correct from your input
[13:57] <mirespace> s/with/without/
[13:58] <LocutusOfBorg> for me it's also ok to just correct by myself and upload, not big deal
[13:58] <mirespace> as you wish :)
[13:59] <mirespace> I cannot do the fix right now (entering in meeting) .. so if you want to change and upload, thanks a lot!
[13:59] <LocutusOfBorg> uploading
[14:02] <LocutusOfBorg> mirespace, noble is fine, I also removed an extra space at the end of changelog file, this is added by merge o matic, and when I find it, I delete
[14:06] <LocutusOfBorg> both sponsored
[14:32] <mirespace> Thank you LocutusOfBorg!
[14:43] <LocutusOfBorg> mirespace, please use https://wiki.ubuntu.com/StableReleaseUpdates and convert your bug to have the SRU accepted for mantic...
[14:43]  * LocutusOfBorg has internet connection troubles, will go afk
[14:44] <mirespace> totally... I will do, but now I have to go afk
[14:44] <LocutusOfBorg> thanks
[14:46]  * tsimonq2 passes seb128 some well-deserved coffee :)
[14:46] <seb128> tsimonq2, thanks :)
[15:41] <seb128> @pilot out
[16:54] <athos> @pilot in
[18:55] <mirespace> LocutusOfBorg: Preparing the SRU paperwork for heimdal, looking for something for the test plan, I look for binaries that uses that symbols
[18:55] <mirespace> and they don't like the symbols:
[18:55] <mirespace> i.e.: aklog --help
[18:55] <mirespace> aklog: symbol lookup error: aklog: undefined symbol: rk_strlcat, version HEIMDAL_ROKEN_1.0
[19:33] <mirespace> ook.. after panic mode less-on and asking, it's a matter of rebuild the packages that uses those heimdal libraries
[20:58] <athos> @pilot out
[21:09] <eslerm> I am working on LP#2012440 and LP#2040321 to add compiler hardening flags to gcc-13 and dpkg
[21:09] -ubottu:#ubuntu-devel- Launchpad bug 2012440 in gcc-13 (Ubuntu) "Please add -D_FORTIFY_SOURCE=3 to default build flags" [High, New] https://launchpad.net/bugs/2012440
[21:09] -ubottu:#ubuntu-devel- Launchpad bug 2040321 in gcc-13 (Ubuntu) "Please add -mbranch-protection=standard to default arm64 build flags" [High, New] https://launchpad.net/bugs/2040321
[21:09] <eslerm> I am building the arm64 locally to test -mbranch-protection, since that Launchpad build is running slow
[21:09] <eslerm> https://launchpad.net/~eslerm/+archive/ubuntu/compilerflags/+packages
[21:09] <eslerm> apologize to @mwhudson for not notifying this channel earlier
[22:48] <mwhudson> eslerm: eh i think what we and you are doing is not _super_ related
[22:49] <mwhudson> the point of doing the riscv with-tests rebuild is mostly just to find out where we are at the current time
[22:49] <mwhudson> i guess it would be interesting to include the flags that we expect to be the default for noble but eh. useful either way
[22:55] <eslerm> relieved to hear that :)
[22:56] <eslerm> -mbranch-protection=standard only applies to arm64 (and is already enabled in dpkg) and -D_FORTIFY_SOURCE=3 instead of 2 shouldn't have a noticeable impact
[23:01] <eslerm> packages which misuse malloc_usable_size may have build issues using _FORTIFY_SOURCE=3
[23:01] <eslerm> https://archlinux.org/todo/prepare-packages-for-d_fortify_source3/
[23:04] <eslerm> I believe these cases are rare. The only two past exceptions I know about have been resolved (see LP comments)