**** BEGIN LOGGING AT Thu Apr 21 02:59:57 2022
Apr 21 10:04:03 <mort> what were you supposed to do again when you have a static library recipe and need the .a files to be part of the SDK
Apr 21 10:04:19 <mort> the SDK only includes ${PN}-dev but the archives are part of ${PN}-staticdev
Apr 21 10:52:34 <rburton> mort: add the -staticdev explicitly to TOOLCHAIN_TARGET_whateverthevaribleiscalled
Apr 21 12:42:37 <Crofton> paulg: I suspect non subscribed people get moderated
Apr 21 13:34:18 <mort> how do you get bitbake to explain why a task is included when your build machine is a headless server? `bitbake -g whatever -u taskexp` wants to open a GTK window so that doesn't work
Apr 21 13:58:13 <kroon> mort, "bitbake -g whatever" should output a .dot file
Apr 21 13:58:37 <kroon> task-depends.dot
Apr 21 14:07:30 <mort> ah, neat
Apr 21 14:09:04 <mort> How do you get a tarball for the rootfs? I'm trying to follow https://docs.yoctoproject.org/singleindex.html#using-the-gdbserver-method, but bitbake only generates the image.rootfs.tar.gz file, not the image.tar.gz file
Apr 21 14:09:55 <mort> sorry, it generates image-dbg.rootfs.tar.gz but not image.rootfs.tar.gz
Apr 21 15:07:15 <rburton> mort: use X forwarding if your local machine has X
Apr 21 19:20:02 <dv_> I have trouble fetching from a private github repo. a SRC_URI like git://git@github.com:/foobar/baz.git;branch=${SRCBRANCH};protocol=ssh does not work because bitbake strips the "git@" part of the URL and converts the rest to ssh://github.com/foobar/baz.git
Apr 21 19:20:20 <dv_> but it should be ssh://git@github.com/foobar/baz.git - only then does the fetch succeed
Apr 21 19:21:10 <dv_> with such a URL, git correctly uses my ssh agent to use my private key. without the "git@", this does not happen.
Apr 21 19:26:32 <Habbie> dv_, as a workaround, you can set per-host usernames in ~/.ssh/config
Apr 21 19:27:03 <Habbie> Host github.com
Apr 21 19:27:06 <Habbie>   User git
Apr 21 19:36:22 <mort> dv_: it should work with git://git@github.com/fobar/baz.git
Apr 21 19:36:40 <mort> with ;protocol=ssh at least
Apr 21 19:37:19 <mort> note the lack of : after .com
Apr 21 20:11:12 <dv_> mort: nope, does not change
Apr 21 20:11:16 <dv_> this is yocto dunfell
Apr 21 20:11:25 <mort> huh, weird
Apr 21 20:11:32 <dv_> Habbie: is this a known issue?
Apr 21 20:11:49 <Habbie> dv_, i know absolutely nothing about OE, i just know ssh can do this trick
Apr 21 20:13:35 <mort> slightly redacted from one of my recipes, used with gatesgarth: SRC_URI = " git://git@git.example.com/foo/bar;protocol=ssh "
Apr 21 20:14:10 <mort> I know that uses ssh because that repo is also private and only accessible over ssh
Apr 21 20:14:12 <dv_> perhaps dunfell incorrectly strips off the "git@" ? khem ? RP ? is this an OE/yocto bug?
Apr 21 20:14:20 <mort> this also works in sumo
Apr 21 20:14:26 <mort> I've also had it work in dunfell actually
Apr 21 20:14:40 <dv_> having to edit the ssh config to get this to work is not ideal
Apr 21 20:14:48 <mort> yeah
Apr 21 20:15:47 <mort> maaybe it's something to do with using gitlab vs github but I would be extremely surprised if it works with gitlab but is broken with github
Apr 21 20:23:23 <dv_> I think github changed several details about accessing repos recently, maybe "git@" used to not be necessary even for private repos
Apr 21 20:29:12 <RP> dv_: I'd be surprised if that was a bitbake change. github did change their supported key types and a whole load of other things so I'd probably check if it works from the commandline first
Apr 21 20:40:08 <dv_> RP: ssh://git@github.com/foobar/baz.git works. ssh://github.com/foobar/baz.git doesn't.
Apr 21 20:40:14 <dv_> so it's all about the "git" username
Apr 21 20:41:32 <dv_> and that's what bitbake removes from the initial "git://git@github.com:/foobar/baz.git;branch=${SRCBRANCH};protocol=ssh" SRC_URI
Apr 21 20:41:40 <dv_> I've tried to force it to keep the username in, no luck
Apr 21 20:43:14 <RP> dv_: it isn't via a mirror url is it? https://git.yoctoproject.org/poky/commit/bitbake/lib/bb/fetch2?id=a4c1325251f57c483ada8377d291e1fb6de9739b
Apr 21 20:45:14 <RP> dv_: https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/fetch2/git.py#n692 is where it builds that, it should pass the user
Apr 21 20:45:52 <dv_> hmm it does try a mirror, but I don't need that functionality (makes no sense with a private repo)
Apr 21 20:45:55 <RP> https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/fetch2/git.py?h=dunfell#n656 in dunfell
Apr 21 20:45:57 <dv_> but - this is dunfell.
Apr 21 20:45:59 <dv_> oh ok
Apr 21 20:46:24 <dv_> yeah I saw that, but adding a "user" parameter did not change anything
Apr 21 20:46:37 <RP> dv_: it should parse the user out the url
Apr 21 20:46:48 <RP> user isn't a parameter
Apr 21 20:47:09 <RP> dv_: stick a bb.warn() in there, see what it uses
Apr 21 20:47:41 <dv_> ok. and for disabling the mirror functionality it should suffice to set MIRROR to "" in the recipe, right?
Apr 21 20:49:26 <RP> dv_: MIRRORS = "" and PREMIRRORS = ""
Apr 21 21:05:23 <dv_> huh - erasing the URL line and re-entering it worked
Apr 21 21:05:31 * dv_ checks for hidden unicode characters
Apr 21 21:06:33 <dv_> ehm, not sure what happened, but entering the entire SRC_URI line by hand again in the recipe fixed it... can't detect anything suspicious in a hexdump of that file.
Apr 21 21:06:40 <dv_> anyway, thx for the info
Apr 21 21:07:41 <RP> dv_: glad it is working
Apr 22 00:22:17 <khem> RP: I am preparing a patch for gcc 11.3 for master and perhaps we might want to backport it for kirkstone at some point
**** ENDING LOGGING AT Fri Apr 22 02:59:56 2022