| *** florian <florian!~florian@dynamic-002-244-162-037.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 276 seconds) | 00:30 | |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 00:35 | |
| *** eltricos <eltricos!~eltricos@ip68-8-181-201.sd.sd.cox.net> has quit IRC (Ping timeout: 240 seconds) | 01:04 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe | 03:54 | |
| *** sgw <sgw!~swold@user/sgw> has quit IRC (Quit: Leaving.) | 05:11 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 05:22 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 05:22 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 06:12 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 06:12 | |
| *** |Xagen <|Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #oe | 06:17 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Ping timeout: 256 seconds) | 06:21 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #oe | 06:33 | |
| *** pespin_ <pespin_!~pespin@osmocom/pespin> has quit IRC (Quit: WeeChat 3.0) | 06:45 | |
| *** mckoan|away is now known as mckoan | 07:38 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:ea03:5200:83a2:cfc9:319f:fd08> has joined #oe | 07:50 | |
| *** frieder <frieder!~frieder@i5C75E60A.versanet.de> has joined #oe | 07:51 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #oe | 08:39 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #oe | 08:40 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has joined #oe | 08:46 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** Kubu_work1 <Kubu_work1!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has joined #oe | 09:01 | |
| mort | why does everyone seem to be using repo rather than git submodules for putting together yocto-based distros | 09:13 |
|---|---|---|
| *** alperak <alperak!~alperak@176.33.71.251> has joined #oe | 09:16 | |
| *** skokkonda <skokkonda!~skokkonda@49.205.254.125> has joined #oe | 09:21 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 240 seconds) | 09:26 | |
| *** Guest10 <Guest10!~Guest46@49.204.85.206> has joined #oe | 09:27 | |
| *** Guest456123 <Guest456123!~Guest4561@49.204.85.206> has joined #oe | 09:28 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 09:28 | |
| *** Guest10 <Guest10!~Guest46@49.204.85.206> has quit IRC (Client Quit) | 09:29 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 09:43 | |
| *** Guest456123 <Guest456123!~Guest4561@49.204.85.206> has quit IRC (Ping timeout: 250 seconds) | 09:43 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #oe | 09:46 | |
| *** yshinde <yshinde!~yshinde@49.204.85.206> has joined #oe | 09:48 | |
| *** Kubu_work1 <Kubu_work1!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Ping timeout: 252 seconds) | 09:51 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has joined #oe | 09:55 | |
| *** florian_kc is now known as florian | 10:11 | |
| *** Guest456123 <Guest456123!~Guest4561@49.204.85.206> has joined #oe | 10:18 | |
| Guest456123 | Hi, | 10:38 |
| Guest456123 | How can we disable a particular toolchain's oe-selftest in poky? Is there any option/file to disable a particular toolchain oe-selftest while all other oe-selftests continue to run? | 10:38 |
| Guest456123 | There's a option "PACKAGECONFIG" which can be used to enable/disable some features. Can we disable using that? | 10:38 |
| Guest456123 | https://docs.yoctoproject.org/dev/singleindex.html#term-PACKAGECONFIG | 10:38 |
| *** Guest456123 <Guest456123!~Guest4561@49.204.85.206> has quit IRC (Ping timeout: 250 seconds) | 10:48 | |
| *** Guest456123 <Guest456123!~Guest4561@49.204.85.206> has joined #oe | 10:58 | |
| *** olani- <olani-!~olani@wlan-gw.se.axis.com> has quit IRC (Ping timeout: 264 seconds) | 11:26 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 12:10 | |
| *** olani- <olani-!~olani@wlan-gw.se.axis.com> has joined #oe | 12:12 | |
| *** Guest456123 <Guest456123!~Guest4561@49.204.85.206> has quit IRC (Ping timeout: 250 seconds) | 12:25 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Ping timeout: 264 seconds) | 12:26 | |
| *** yshinde <yshinde!~yshinde@49.204.85.206> has quit IRC (Read error: Connection reset by peer) | 12:38 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #oe | 12:38 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 12:40 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Ping timeout: 264 seconds) | 12:51 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has joined #oe | 12:55 | |
| *** sgw <sgw!~swold@user/sgw> has joined #oe | 13:13 | |
| *** speeder <speeder!~speeder__@2001:8a0:dfde:fa00:4776:680b:510:5965> has quit IRC (Ping timeout: 240 seconds) | 13:40 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Ping timeout: 246 seconds) | 13:49 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has joined #oe | 13:51 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds) | 13:58 | |
| *** speeder <speeder!~speeder__@213.205.68.220> has joined #oe | 14:02 | |
| *** speeder_ <speeder_!~speeder__@213.205.68.220> has joined #oe | 14:04 | |
| *** speeder <speeder!~speeder__@213.205.68.220> has quit IRC (Ping timeout: 252 seconds) | 14:06 | |
| *** sgw <sgw!~swold@user/sgw> has quit IRC (Quit: Leaving.) | 14:09 | |
| *** sgw <sgw!~swold@user/sgw> has joined #oe | 14:10 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 14:15 | |
| *** speeder__ <speeder__!~speeder__@213.205.68.220> has joined #oe | 14:22 | |
| *** speeder__ <speeder__!~speeder__@213.205.68.220> has quit IRC (Remote host closed the connection) | 14:25 | |
| *** speeder_ <speeder_!~speeder__@213.205.68.220> has quit IRC (Ping timeout: 255 seconds) | 14:25 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 264 seconds) | 14:28 | |
| Crofton | mort: not everyone. Repo is mostly used by people who used repo before we found alternatives | 14:30 |
| Crofton | Now many people use submodules, kas, and there is a setup tool in botbake from kanavin | 14:31 |
| *** skokkonda <skokkonda!~skokkonda@49.205.254.125> has quit IRC (Quit: Client closed) | 14:38 | |
| kanavin | mort, the split between repo, kas and submodules is roughly 1/3 each for legacy projects, actually | 14:45 |
| kanavin | mort, for new projects the recommendation is to use the built-in tooling | 14:45 |
| Crofton | I really need to try your work kanavin a tleast for snapshoting something from my submodules workflow | 15:00 |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Remote host closed the connection) | 15:05 | |
| *** rcw <rcw!~rcwoolley@104.247.247.154> has joined #oe | 15:06 | |
| JPEW | Crofton: I used the new tooling here: https://github.com/JoshuaWatt/meta-bitbake-hashserver It was pretty easy. | 15:07 |
| JPEW | I think I would still prefer submodules for some use cases, but I like that A) this is in OE-core and B) it's not kas | 15:07 |
| Crofton | so you edit the hashes in the json file for updates? | 15:09 |
| mort | kanavin: are you referring to OE/bitbake tooling which replaces the other stuff or are you referring to submodules? | 15:13 |
| mort | by "native tooling" I mean | 15:13 |
| JPEW | Crofton: Ya, or you can re-run the command to generate the JSON file... I have a local script I was hacking together to make it a litter easier | 15:14 |
| Crofton | mort: take a look at what JPEW posted | 15:14 |
| JPEW | I think I did a combination of running the command and manually editing | 15:15 |
| kanavin | Crofton, you can update the checked out layer revisions with regular git, then re-run the json generator command and have it overwrite the old json | 15:17 |
| kanavin | mort, I refer to 'bitbake-layers create-layers-setup' | 15:17 |
| kanavin | and I'm glad JPEW is now a user :) | 15:18 |
| JPEW | kanavin: Ya, I think it makes sense for something like that layer; I'm not switching away from submodules at work though :) | 15:18 |
| JPEW | kanavin: The idea is sound though; the scripting has a few things that would be nice, like refusing (by default anyway) to use a SHA-1 that doesn't exist on the remote | 15:19 |
| JPEW | And the ability to fetch bitbake itself | 15:19 |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe | 15:26 | |
| KanjiMonster | JPEW: what's wrong with kas? Just curious, as I'm currently looking into switching our project from repo to kas | 15:52 |
| JPEW | KanjiMonster: Nothing really. I (personally) don't like tools that hid a lot of what's going on, but I see the appeal of having the big "pull the lever and do it all for me" | 15:54 |
| rburton | JPEW has conflict of interest as he wrote another build orchestrator :) (whisk) | 15:54 |
| Crofton | kanavin: this would be a good thig to talk about at the post FOSDEM workshop | 15:58 |
| JPEW | rburton: Ya, that too | 15:58 |
| *** mvlad <mvlad!~mvlad@2a02:2f08:ea03:5200:83a2:cfc9:319f:fd08> has quit IRC (Remote host closed the connection) | 16:00 | |
| *** eltricos <eltricos!~eltricos@ip68-8-181-201.sd.sd.cox.net> has joined #oe | 16:06 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 16:22 | |
| *** Kubu_work <Kubu_work!~kubu@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Quit: Leaving.) | 16:54 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 17:06 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:ea03:5200:61a2:7a29:c68a:27bd> has joined #oe | 17:32 | |
| khem | mort: I will take some blame for repo :) | 17:32 |
| khem | repo and kas for that matter adds another layer on top of OE, we should be peeling off the layer and not adding more to simplify things | 17:35 |
| khem | git submods or even combo-tool are better to my taste | 17:35 |
| *** mckoan is now known as mckoan|away | 17:36 | |
| mort | I had no idea about bitbake-layers create-layers-setup | 17:38 |
| mort | I strongly prefer submodules to repo | 17:39 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 268 seconds) | 17:39 | |
| fray | What I do is use 'repo' when I want versions to float to latest in a branch (on release I will create a hash based manifest and tag).. If I want something tied to a give version, then I may incorporate submodules as well (i.e. bringing in tooling and such)... Something like kas (or similar there are multiple) is useful for people trying to encapsulate both a repository checkout and configuration into a single | 17:39 |
| fray | place.. (I personal don't want that combination, but that is my use-case) | 17:39 |
| mort | I don't actually think I understand what problem repo solves | 17:40 |
| mort | I understand what it does and what the repo manifest xml file means and what not but that's different from understanding which problem it solves | 17:41 |
| fray | I have a collection of 15 layers I need in my project. Each layer is branched to 'nanbield'. So I have repo point to 'nanbield' and all I need to do is 'repo sync' and I each individual repository gets updated to latest 'nanbield' | 17:41 |
| fray | historically, submodules are locked to a specific hash.. I don't want that behavior.. I don't want to have to regularly (manually) update the repository download to the latest nanbield hash | 17:41 |
| mort | I guess submodules are tied to a commit rather than a commit yeah | 17:41 |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 255 seconds) | 17:42 | |
| mort | 'for x in meta-*; do cd "$x"; git checkout nanbield; git pull; cd ..; done' isn't *that* much work but I guess 'repo sync' is nicer | 17:42 |
| fray | repo also includes tooling that lets you easily process and iterate over the repositories, as well as manifest generation tooling (to tag or share specific versions [commit based] with others, and also allows for things like special files/symlinks to be generated as part of the checkout) | 17:42 |
| fray | the later stuff is "nice to have" | 17:42 |
| mort | on the other hand, I like that a specific commit of the main repository is a reflection of the whole system at that time, with which exact commits of each submodule was used | 17:43 |
| fray | when the manifest file changes, the next repo sync downloads the manifest and automatically updates.. this includes adding or removing things | 17:43 |
| fray | you can also change a branch by changing the repo manifest or the manfest branch and everything just changes on the next repo sync | 17:43 |
| mort | > when the manifest file changes, the next repo sync downloads the manifest and automatically updates -- isn't this just `git submodule update` | 17:44 |
| fray | For MY needs, tieing to a branch is the correct behavior... tieing to a commit is too heavy weight.. | 17:44 |
| fray | repo init -u <maniest> -b langdale | 17:44 |
| fray | repo sync | 17:44 |
| fray | I get the things pointed to by the manifestin the langdale branch... | 17:44 |
| fray | (same directory) | 17:44 |
| fray | repo init -b nanbield | 17:44 |
| fray | repo sync | 17:44 |
| mort | ideally imo, git submodules should be tied to branch + commit, and there should be a `git submodule for-each pull` or something which moves the submodules' heads to the latest commit in their branch | 17:45 |
| fray | The new nanbield (manifest from that branch) is used and everything is updated without a full download.. but in nanbield, maybe some magic layer isn't there.. that goes away, and maybe a replacement is added.. | 17:45 |
| fray | it allows very quick management of things by a simple manifest | 17:45 |
| fray | (the same manifest concept is used by kas and others just with different tooling and additional features) | 17:45 |
| mort | I guess I don't see how managing things through .gitmodules and the git submodule commands is less quick than by editing the manifest xml | 17:46 |
| fray | I believe git submodules can now be tied to a branch (and not commit), but histroically that wasn't true.. (I've never tried tieing submodules to a branch though) | 17:46 |
| fray | but assuming you CAN do that, then a 'manifest' (submodule) repository could be created that did the same thing as repo, bu thte data stored differently.. (manifest as in that git repository is just made up of submodule references, not actual files) | 17:47 |
| mort | my preferred way of doing it is that a "distro" is one repository with a bunch of meta-blah submodules and a poky submodule, and then there's one or more plain meta-blah directories in the repo containing distro-specific stuff | 17:48 |
| mort | so I'll have like meta-qcom, meta-openembedded and poky as submodules and meta-mydistroname as a directory | 17:49 |
| fray | but in the end the 'requirement' is some people want to manage a set of manifests (of other repositories) by commit, some want to do it by branch... the actual tooling underneith (shell script, git submodule or repo) doesn't really matter as they all are the same resulting method | 17:49 |
| fray | I have a "product" (petalinux) that I build.. The product has about 22 repositories referenced in it (and about 30 layers).. Inside of it has a distribution that does NOT use all of those layers, but can optionally use them.. So I have a 'how do I distribute this?' (repo), how do I configure this (eSDK, oe-init-build-env [wrapped] with a default template that can change based on the users needs) | 17:51 |
| fray | (so simplifying it), the 'product' ships, poky, meta-petalinux, meta-openembedded, meta-xilinx and meta-virtualization.... but not all of the layers in each of those repositories is needed.. | 17:52 |
| fray | meta-petalinux (the layer) has both layer dependencies and recommendations specified, and uses dynamic-layers to adjust behavior for optional components | 17:53 |
| fray | (I also have tooling for cross repository changes to generate pull requests and such.. but that could be done in any method, submodule, kas or repo) | 17:54 |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #oe | 17:55 | |
| JPEW | mort: submodules have a `branch` parameter that indicates the upstream branch. It doesn't _really_ do much other than make a correct tracking branch when you checkout, but it does make the loop you are talking about at lot easier because of it | 17:55 |
| mort | JPEW: that sounds nice, I should start using that | 17:56 |
| mort | detached heads are annoying | 17:56 |
| JPEW | mort: Right | 17:56 |
| JPEW | You still get the detached head, but your update to the latest version is basically `git checkout <branch> && git pull [--rebase]` | 17:56 |
| JPEW | because the tracking branch exists and is correct | 17:57 |
| mort | sorry, yeah I mixed up terms | 17:57 |
| fray | the repo way of doing that is (detached heads) from repo init ; repo sync.. then you go into a repository and do 'repo start <my_branch_name>' and it will do whatever branch specified in the repsoitory linked as the upstream for your local branch | 17:58 |
| JPEW | mort: I had to do some fighting internally to set our branches for submodules, because there was the incorrect assumption that setting them made it track the branch head (like repo) and we _really_ do not want that | 17:58 |
| fray | then on the next 'repo sync', it will automatically rebase _NOT_ merge commit your changes on top or stop and have you do the rebase.. (I prefer rebase vs merge for this type of work-in-progress as well, so repo works better for me) | 17:58 |
| mort | one of the annoying thing with repo is that every time you run repo, it goes on this long tirade about how there's an update available you should install | 17:58 |
| fray | (but most developers trying to use YP are not modifying multiple upstream layers.. they're working on a small set of 'internal' product layers.. so that is MUCH MUCH less of a general isseu) | 17:59 |
| mort | I want to use the version of repo packaged in my system thank you very much | 17:59 |
| JPEW | I also like submodules because grepping actually works without having to tell tools to ignore git ignore :) | 17:59 |
| fray | repo foreach -c '......' | 18:00 |
| JPEW | The downside of submodules is that you need some "parent" repo to house all of them; repo doesn't need that | 18:00 |
| mort | eh repo needs a manifest xml file which more often than not is in a repo | 18:00 |
| fray | JPEW kind of repo needs a manifest repository, so it's similar concept but stored in an XML file vs a git repository and .submodule file(s) | 18:00 |
| mort | granted, sometimes people have a bunch of manifests in one git repo | 18:00 |
| JPEW | fray: Ya. I mean why can `ripgrep` just work without preamble :/ | 18:00 |
| JPEW | If i have to do the foreach, it's no fun | 18:00 |
| mort | but you could have a parent repo with a bunch of branches I guess | 18:00 |
| JPEW | We already have a parent repo to configure all our products, so it wasn't a problem | 18:01 |
| fray | In my (internal) case, I have multiple manifests.. a 'default' which matches what I intend to release, and then an internal manifest that includes unreleasble stuff for development.. and even multiple 'internal-restricted-foo' manifests that include references to things that require special permissions to access | 18:01 |
| fray | repo init -m <manifest_name> allows me to switch configurations, which I do need to do occasionally.. | 18:02 |
| mort | I usually have unreleasable stuff for development in separate branches | 18:02 |
| fray | All of these things are very much doable with git submodule, but it's "different" | 18:02 |
| mort | `git checkout <branch name>` + `git submodule update` allows me to switch configurations | 18:02 |
| mort | I do 100% get the familiarity and muscle memory angle | 18:03 |
| fray | My problem with git submodules (and using branches like that), if I want an updated poky (which in master updates pretty much daily).. then every day I have to go to each of my master based branches.. git remote update, get the right commit, git add (submodule)'.. etc.. (this of course can be scripted).. and then repeat that for each of the branches for each of my sets of checkout.. | 18:04 |
| fray | so that means my 'manifest' repository now has 3 branches (or more) each with 1 checkout per day, that might deviate slightly from each other (or might not)... | 18:04 |
| khem | You can do everything in git submods like you do in repo these days and it’s gitty in nature so just fits the mindset. I update to latest of a branch using git submods with a single git cmd it has come a long way since it was introduced | 18:06 |
| khem | Earlier issue were that you got into some weird state which you could not get out of but that’s gone | 18:06 |
| khem | And I like monorepo model | 18:07 |
| fray | khem, ya I know git submodule has changed.. floating branches was the big missing feature for a LONG LONG time, assuming that works now then much of repo is unnecessary (from a management perspective), only the repo tooling is still possibly useful, but could be moved to pure git | 18:08 |
| * kanavin comes back and skims through all of that | 18:25 | |
| kanavin | just saying, with the new built-in tooling you have a chance to make it behave the way you want | 18:26 |
| kanavin | with all those repo/kas/submodules things, there'll be forever grumbling how they don't quite work like you would like them to | 18:27 |
| *** florian_kc <florian_kc!~florian@dynamic-002-243-107-084.2.243.pool.telefonica.de> has joined #oe | 18:37 | |
| fray | Historically the different tests against each distro really have highlighted errors in the recipe's, upstream items or distro configuration.. Especially in the 'tiny' and (now obsolete) custom libc cases.. | 18:39 |
| *** eltricos1 <eltricos1!~eltricos@ip68-8-181-201.sd.sd.cox.net> has joined #oe | 18:39 | |
| *** eltricos <eltricos!~eltricos@ip68-8-181-201.sd.sd.cox.net> has quit IRC (Read error: Connection reset by peer) | 18:39 | |
| *** florian__ <florian__!~florian@dynamic-002-243-107-084.2.243.pool.telefonica.de> has joined #oe | 18:56 | |
| *** florian_kc <florian_kc!~florian@dynamic-002-243-107-084.2.243.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 19:00 | |
| *** Kubu_work <Kubu_work!~kubu@2a01cb05945b7e009bdc688723a24f31.ipv6.abo.wanadoo.fr> has joined #oe | 19:10 | |
| *** Saur_Home16 <Saur_Home16!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 19:10 | |
| *** frieder <frieder!~frieder@i5C75E60A.versanet.de> has quit IRC (Remote host closed the connection) | 19:13 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Ping timeout: 250 seconds) | 19:14 | |
| Crofton | JPEW: https://youtu.be/NjDQcdAWUaw?si=m_CQmQSVtRPzWd8Z | 19:20 |
| Crofton | and others intereested in SBOM | 19:20 |
| Crofton | also one minute is 2:50 or so :) | 19:20 |
| JPEW | Crofton: Nice | 19:28 |
| OnkelUlla | mort, JPEW: The branch recorded in .gitmodules is used when you do a 'git submodule update --remote --checkout', see https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt---remote . | 19:28 |
| OnkelUlla | mort, JPEW: This makes things a little bit more handy. | 19:28 |
| JPEW | OnkelUlla: Right! I knew there was a command to do it, I just forgot it off the top of my head | 19:28 |
| JPEW | That is really useful FWIW | 19:28 |
| *** Saur_Home16 <Saur_Home16!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 19:59 | |
| *** Saur_Home16 <Saur_Home16!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 19:59 | |
| *** Saur_Home46 <Saur_Home46!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 20:12 | |
| *** Saur_Home39 <Saur_Home39!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 20:12 | |
| *** Saur_Home16 <Saur_Home16!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Ping timeout: 250 seconds) | 20:16 | |
| *** Saur_Home46 <Saur_Home46!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Ping timeout: 250 seconds) | 20:16 | |
| *** alperak <alperak!~alperak@176.33.71.251> has quit IRC (Quit: Client closed) | 20:20 | |
| *** alperak <alperak!~alperak@176.33.71.251> has joined #oe | 20:22 | |
| *** jpuhlman <jpuhlman!~jpuhlman@50-240-203-141-static.hfc.comcastbusiness.net> has joined #oe | 20:26 | |
| *** florian__ <florian__!~florian@dynamic-002-243-107-084.2.243.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 20:33 | |
| *** eltricos1 <eltricos1!~eltricos@ip68-8-181-201.sd.sd.cox.net> has quit IRC (Ping timeout: 260 seconds) | 20:36 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Ping timeout: 252 seconds) | 20:38 | |
| *** eltricos <eltricos!~eltricos@ip68-8-181-201.sd.sd.cox.net> has joined #oe | 20:40 | |
| *** florian__ <florian__!~florian@dynamic-002-243-107-084.2.243.pool.telefonica.de> has joined #oe | 20:45 | |
| *** Saur_Home39 <Saur_Home39!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 21:04 | |
| *** Saur_Home39 <Saur_Home39!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 21:04 | |
| *** olani <olani!~olani@134.238.48.37> has quit IRC (Ping timeout: 255 seconds) | 21:14 | |
| *** alperak <alperak!~alperak@176.33.71.251> has quit IRC (Quit: Client closed) | 21:14 | |
| *** Saur_Home39 <Saur_Home39!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 22:50 | |
| *** Saur_Home39 <Saur_Home39!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 22:51 | |
| *** Saur_Home39 <Saur_Home39!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 23:12 | |
| *** Saur_Home39 <Saur_Home39!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 23:13 | |
| *** Kubu_work <Kubu_work!~kubu@2a01cb05945b7e009bdc688723a24f31.ipv6.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 23:16 | |
| *** olani <olani!~olani@81-230-172-170-no2811.tbcn.telia.com> has joined #oe | 23:22 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!