05:46 <cyborg_ar> i put my case up here https://www.printables.com/model/885692-3d-printed-case-for-the-glasgow-interface-explorer

13:31 <xdbob[m]> Hey, I gave a shot at packaging glasgow (and it's dependencies) for fedora, would anyone care to test and/or review it ? https://copr.fedorainfracloud.org/coprs/xdbob/glasgow/ (and the spec files are there https://git.sr.ht/~xdbob/rpm-glasgow )

16:16 <whitequark[cis]> xdbob: what does a version look like? I'd like the package version to look exactly the same as if you grabbed it from the git repo

16:18 <whitequark[cis]> i.e. right now the version of main is 0.1.dev2047+g3365f4f

16:20 <whitequark[cis]> I actually don't care that much about the version that appears in the package manager, but I do care about glasgow --version

16:22 <xdbob[m]> The fedora package version looks like `0^20240520git3365f4f`, It's built according to the packaging guidelines ( https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots ) with `0^` because no relase has been tagged, the date, the scm and the short commit

16:22 <xdbob[m]> The python version is currently `0.0.0+20240520git3365f4f` , I'll need to do some digging to rebuild the `0.1.dev{commit_num}` since the packaging does not have access to the git repository

16:25 <xdbob[m]> otherwise I might just hardcode it in the package and update it when I update the target commit

16:25 <whitequark[cis]> xdbob: I don't think this line is right https://copr-dist-git.fedorainfracloud.org/cgit/xdbob/glasgow/python-libusb1.git/tree/python-libusb1.spec#n20

16:25 <whitequark[cis]> libusb1 doesn't require cython

16:26 <whitequark[cis]> it is, as the description says, pure python... no c code at all

16:26 <whitequark[cis]> (or python code pretending to be c)

16:27 <xdbob[m]> thanks ! this one needs to be fixed upstream (as in fedora upstream) ^^, it's a verbatim copy of https://src.fedoraproject.org/rpms/python-libusb1/blob/rawhide/f/python-libusb1.spec

16:49 <whitequark[cis]> gsuberland: do you think you can finish the hardware doc sometime soon?

18:20 <gsuberland[m]> I'm super busy with EMF prep at the moment so might be a week or two before I get round to it, but I've not forgotten 🙂

18:20 <whitequark[cis]> gotcha

18:26 <xdbob[m]> <whitequark[cis]> "I actually don't care that..." <- It's ISO now, thanks for the feedbacks

18:27 <whitequark[cis]> ISO?

18:27 <xdbob[m]> woops, the same

18:28 <whitequark[cis]> ah, yeah! thanks

18:28 <whitequark[cis]> that's incredible

18:29 <xdbob[m]> :')

18:30 <whitequark[cis]> re: toolchain, as shipped it would use the native one unless the yowasp one is installed, which it probably won't be unless someone runs pip with --break-system-packages

18:30 <whitequark[cis]> aiohttp is a runtime dep, not a test dep

18:31 <whitequark[cis]> why did you conclude that it's a test dependency?

19:00 <xdbob[m]> me being a moron and going too fast, I guess aiohttp should still be a build dependency but the package should recommend it ?

19:02 <xdbob[m]> re: toolchain, I still think I should reverse the default, what would happen if someone calls glasgow from a venv shipping yowasp ?

19:03 <whitequark[cis]> if they are calling a package from system site-packages from a venv their workflow is broken beyond repair

19:03 <whitequark[cis]> xdbob[m]: everything that's in the [http] group yes

19:17 <xdbob[m]> damn, aiohttp-remotes is not packaged, I'll look into it next weekend