| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (Remote host closed the connection) | 00:31 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 00:31 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 00:31 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 00:34 | |
| mischief | Marian46: maybe pass rdinit=/bin/... | 00:37 |
|---|---|---|
| mischief | or just install your own symlink for init somewhere in the image recipe | 00:37 |
| *** otavio <otavio!~otavio@201-35-186-235.user3p.brasiltelecom.net.br> has joined #yocto | 00:42 | |
| khem | Marian46: start with https://docs.yoctoproject.org/dev-manual/building.html?highlight=initramfs#building-an-initial-ram-filesystem-initramfs-image | 01:03 |
| *** Ablu <Ablu!~Ablu@user/Ablu> has quit IRC (Ping timeout: 245 seconds) | 01:06 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6524:7200:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 260 seconds) | 01:08 | |
| *** Ablu <Ablu!~Ablu@user/Ablu> has joined #yocto | 01:10 | |
| khem | belgianguy: you might look into uefi support and its good for arm64 look into meta-arm, however, yocto does not provide infra for signing keys etc. its left to the distros | 01:12 |
| khem | belgianguy: I would suggest to look into debian secure boot process | 01:12 |
| *** Marian46 <Marian46!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has quit IRC (Quit: Client closed) | 01:18 | |
| *** Marian88 <Marian88!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has joined #yocto | 01:18 | |
| Marian88 | Finally I managed to boot a initramfs using: INITRAMFS_SCRIPTS = " initramfs-boot ". The only problem that I still have is the root password. I'm using -EXTRA_IMAGE_FEATURES ?= "debug-tweaks", but the initramfs image seems to not have this option enabled | 01:21 |
| Marian88 | genericx86-64 login: root | 01:21 |
| Marian88 | Password: | 01:21 |
| Marian88 | Login incorrect | 01:21 |
| Marian88 | genericx86-64 login: root | 01:21 |
| Marian88 | Password: | 01:21 |
| Marian88 | Login incorrect | 01:21 |
| Marian88 | genericx86-64 login: | 01:21 |
| Marian88 | any idea | 01:21 |
| Marian88 | ? | 01:21 |
| *** Marian88 <Marian88!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has quit IRC (Quit: Client closed) | 01:25 | |
| *** Marian55 <Marian55!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has joined #yocto | 01:29 | |
| khem | Marian55: Perhaps add IMAGE_FEATURES:append = " empty-root-password" in local.conf | 01:37 |
| *** starblue <starblue!~juergen@dslb-088-078-099-052.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 245 seconds) | 01:42 | |
| *** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has joined #yocto | 01:44 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:e11a:3faa:e378:93d1> has quit IRC (Quit: ZZZzzz…) | 01:45 | |
| *** Marian55 <Marian55!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has quit IRC (Quit: Client closed) | 01:50 | |
| *** belgianguy <belgianguy!~belgiangu@ptr-651fbf6nccqxxk5pil6.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 245 seconds) | 01:50 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:5125:e59:9dab:e455> has joined #yocto | 01:51 | |
| *** Marian89 <Marian89!~Marian@c-73-219-138-101.hsd1.nh.comcast.net> has joined #yocto | 01:59 | |
| Marian89 | I managed to fix it via "+IMAGE_FEATURES:append = "${EXTRA_IMAGE_FEATURES}"" | 01:59 |
| Marian89 | in the -initramfs.bb image | 01:59 |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@151.58.174.15> has quit IRC (Read error: Connection reset by peer) | 02:14 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@151.58.174.15> has joined #yocto | 02:16 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6524:1400:2ce:39ff:fecf:efcd> has joined #yocto | 02:32 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:5125:e59:9dab:e455> has quit IRC (Ping timeout: 248 seconds) | 03:17 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has joined #yocto | 03:21 | |
| *** otavio <otavio!~otavio@201-35-186-235.user3p.brasiltelecom.net.br> has quit IRC (Ping timeout: 244 seconds) | 04:45 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:03 | |
| *** Xhivo <Xhivo!~Xhivo@109.72.102.19> has joined #yocto | 06:13 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:15 | |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has joined #yocto | 06:17 | |
| *** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1294-101.w86-207.abo.wanadoo.fr> has joined #yocto | 06:32 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (Quit: Leaving) | 06:39 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Ping timeout: 256 seconds) | 06:40 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has quit IRC (Quit: ZZZzzz…) | 06:43 | |
| *** mckoan|away is now known as mckoan | 06:47 | |
| mckoan | good morning | 06:47 |
| *** frieder <frieder!~frieder@87.123.146.73> has joined #yocto | 06:52 | |
| *** pgowda_ <pgowda_!uid516182@2a03:5180:f:3::7:e056> has joined #yocto | 06:52 | |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has quit IRC (Quit: valdemaras) | 06:54 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 06:54 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 06:58 | |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has joined #yocto | 07:02 | |
| *** AKN <AKN!~AKN@49.37.202.224> has joined #yocto | 07:21 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:56 | |
| *** olani- <olani-!~olani@wlan-gw.se.axis.com> has quit IRC (Ping timeout: 246 seconds) | 07:56 | |
| *** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has joined #yocto | 07:59 | |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has joined #yocto | 08:18 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:20 | |
| *** florian_kc <florian_kc!~florian@217.146.132.69> has joined #yocto | 08:34 | |
| kanavin | y2038 facepalm of the day | 08:47 |
| kanavin | void | 08:47 |
| kanavin | _dbus_get_real_time (long *tv_sec, | 08:47 |
| kanavin | long *tv_usec) | 08:47 |
| kanavin | { | 08:47 |
| kanavin | used throughout dbus, obviously | 08:47 |
| RP | kanavin: it isn't something you'd think about :/ | 08:48 |
| kanavin | RP: not quite; the implementation does | 08:49 |
| kanavin | struct timeval t; | 08:49 |
| kanavin | gettimeofday (&t, NULL); | 08:49 |
| kanavin | if (tv_sec) | 08:49 |
| kanavin | *tv_sec = t.tv_sec; | 08:49 |
| kanavin | if (tv_usec) | 08:49 |
| kanavin | *tv_usec = t.tv_usec; | 08:49 |
| kanavin | } | 08:49 |
| kanavin | at which point it would be prudent to look up data types in timeval | 08:50 |
| kanavin | (tv_sec would be time_t) | 08:50 |
| RP | kanavin: ah right :/ | 08:52 |
| *** Guest50 <Guest50!~Guest62@host-80-41-74-129.as13285.net> has joined #yocto | 08:56 | |
| Guest50 | Isd there any way to lilst valid target architectures for a recipe which builds in a different subdirectory of tmp/work on a different computer ? | 08:57 |
| Guest50 | basically a recipe build on the correct subdirectory of /tmp/work on my station and finds what it needs there, but on a different computer it builds in another subdirectory and does not find one projects it needs to build come of its libraries | 08:58 |
| Guest50 | to build ONE of its libraries* | 08:59 |
| Guest50 | and decides to ignore this during its do_configure | 09:00 |
| Guest50 | not sure how to change the recipe to "force" it into the right build/tmp/work/ subdirectory | 09:00 |
| Guest50 | never needed to on my station | 09:01 |
| *** Xhivo <Xhivo!~Xhivo@109.72.102.19> has quit IRC (Ping timeout: 246 seconds) | 09:06 | |
| ptsneves | Guest50: I do not think it is a good idea to depend on the tmp/work directory. If you need outputs from the recipe you should deploy it somewhere | 09:08 |
| Guest50 | but how comes the recipe builds in a different subdirectory on a different machine? | 09:09 |
| *** xmn <xmn!~xmn@2600:4040:9390:8c00:68b3:cbd9:125:9481> has quit IRC (Quit: ZZZzzz…) | 09:11 | |
| kanavin | RP: what I don't understand is why c compiler is happy with that. Surely assigning long long to long or long to int should be at least a warning? | 09:13 |
| RP | kanavin: I'd have thought the compiler would show a warning | 09:13 |
| RP | probably depends on the compiler options? | 09:14 |
| kanavin | RP: I just wrote a trivial program to check and there's not warning, not with Wall | 09:14 |
| kanavin | is there some Wreally-super-duper-all maybe? | 09:14 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 09:16 | |
| Guest50 | RP: -Wall -Wextra ... Some diagnostics for non-ISO practices are controlled by specific warning options other than -Wpedantic, but are also made errors by -pedantic-errors | 09:26 |
| Guest50 | RP: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html | 09:27 |
| kanavin | Guest50, all, extra, pedantic. Adding all three still doesn't make a warning. | 09:27 |
| Guest50 | RP: version of gcc are you using? | 09:28 |
| kanavin | I guess the question is for me? 12.2.0 | 09:28 |
| Guest50 | try issuing a sizeof() of the respective integers, | 09:28 |
| kanavin | 4 for int, 8 for long long | 09:30 |
| kanavin | no warning | 09:30 |
| kanavin | #include <stdio.h> | 09:32 |
| kanavin | int main(){ | 09:32 |
| kanavin | int a; | 09:32 |
| kanavin | long long b = -3000000000; | 09:32 |
| kanavin | a = b; | 09:32 |
| kanavin | printf("%d %ld\n",a, sizeof(a)); | 09:32 |
| kanavin | printf("%lld %ld\n",b, sizeof(b)); | 09:32 |
| kanavin | } | 09:32 |
| RP | kanavin: this is more khem's area than mine to tbh, I just work out how to build the compilers... | 09:32 |
| kanavin | RP: I think it's more or less clear gcc won't help, and maybe there's some awful reason why :-( | 09:34 |
| kanavin | such as 'programmers should know what they're doing, and it's their fault if they mess up' | 09:34 |
| RP | kanavin: I fear that may be the case | 09:35 |
| *** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has quit IRC (Ping timeout: 246 seconds) | 09:36 | |
| sudip | kanavin: you can use -Wconversion | 09:39 |
| sudip | I used that with your code and: | 09:39 |
| sudip | test.c:7:5: warning: conversion from ‘long long int’ to ‘int’ may change value [-Wconversion] | 09:39 |
| kanavin | sudip, right! why is it not in all or extra or pedantic? | 09:40 |
| *** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has joined #yocto | 09:42 | |
| * sudip has no idea why | 09:42 | |
| ptsneves | Does anybody know why in get_taskhahs@siggen.py, the iteration of self.file_checksum_values[tid] is unsorted? I had 2 signatures which are identical except the file list is in a slightly different order leading to a different taskhsh | 09:42 |
| rburton | ptsneves: sounds like a bug to me | 09:45 |
| *** wyre_ <wyre_!~wyre@user/wyre> has joined #yocto | 09:45 | |
| *** wyre <wyre!~wyre@user/wyre> has quit IRC (Read error: Connection reset by peer) | 09:45 | |
| ptsneves | rburton: ok. Will try to sort the list and see if the hashes come out correctly | 09:45 |
| RP | ptsneves: definitely a bug | 09:54 |
| Guest50 | still looking for an answer to previously posted question(s) | 10:03 |
| Guest50 | still need to understand so I can rectify the problem | 10:04 |
| *** olani- <olani-!~olani@wlan-gw.se.axis.com> has joined #yocto | 10:05 | |
| ptsneves | Guest50: Try bitbake-getvar -r <recipe> WORKDIR on both machines and see where the values come from | 10:05 |
| Guest50 | ptsneves: Thank you, will try that as soon as the respective builds finish | 10:06 |
| *** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 250 seconds) | 10:06 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 10:07 | |
| *** wyre_ <wyre_!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 10:08 | |
| *** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has joined #yocto | 10:08 | |
| *** wyre <wyre!~wyre@user/wyre> has joined #yocto | 10:09 | |
| *** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has quit IRC (Read error: Connection reset by peer) | 10:10 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 10:11 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 10:11 | |
| ptsneves | RP: Ironically the dump_sigfile function sorts a_data['file_checksum_values']. I only spotted this because i opened the signatures directly with zstdcat | 10:13 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 246 seconds) | 10:13 | |
| *** Guest50 <Guest50!~Guest62@host-80-41-74-129.as13285.net> has quit IRC (Quit: Client closed) | 10:14 | |
| *** Schlumpf48 <Schlumpf48!~Schlumpf@62.157.232.203> has joined #yocto | 10:15 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Ping timeout: 246 seconds) | 10:19 | |
| *** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has joined #yocto | 10:22 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 10:24 | |
| *** camus <camus!~Instantbi@58.246.136.203> has quit IRC (Ping timeout: 246 seconds) | 10:26 | |
| *** camus <camus!~Instantbi@58.246.136.203> has joined #yocto | 10:28 | |
| mcfrisk | How are poky oe-selftests executed on autobuilder(s)? I'd like to know what's in their conf/local.conf, auto.conf and site.conf | 10:42 |
| mcfrisk | kanavin: what does test_testimage_virgl_headless need from the build host? some GPU HW or just vgem kernel module? | 10:44 |
| mcfrisk | on my x86_64 build machine with "Integrated Matrox G200eW3 Graphics Controller", starting qemu with GPU support is always failing and thus test_testimage_virgl_headless too. loading vgem kernel module doesn't help. What do the upstream build/test servers have? | 10:55 |
| *** Estrella <Estrella!~quassel@075-081-060-240.res.spectrum.com> has quit IRC (Ping timeout: 256 seconds) | 11:02 | |
| RP | ptsneves: yes, well spotted! | 11:07 |
| RP | ptsneves: I'd be happy to fix that issue | 11:08 |
| RP | mcfrisk: you can see it in the logs? | 11:08 |
| RP | mcfrisk: https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1948/steps/14/logs/stdio | 11:08 |
| RP | from https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1948 step 14, "OE Selftest: Write config" | 11:09 |
| RP | that one is an arm worker but you get the idea | 11:09 |
| RP | mcfrisk: I think that test is excluded on some distros and has some host requirements | 11:09 |
| kanavin | mcfrisk, loading vgem should help, that's what yocto ci does | 11:12 |
| kanavin | spcifically vgem should create /dev/dri/renderD* entries, if the gpu driver does not | 11:12 |
| mcfrisk | kanavin: I loaded the vgem module but starting qemu still fails with "qemu-system-x86_64: egl: render node init failed" | 11:13 |
| kanavin | are permissions correct? | 11:13 |
| mcfrisk | I saw that /dev/dri/renderD128 is created, ah I don't render group rights, will add and try again. thanks! | 11:14 |
| kanavin | mcfrisk, qemu error message isn't helpful, I think I tried to make runqemu print something more useful in that case, not sure | 11:15 |
| RP | mcfrisk: making some nicer errors messages around that would be nice if we could | 11:15 |
| ad__ | hi, any simple way to change glibc version ? | 11:15 |
| kanavin | ad__, update to the yocto version that has the needed version | 11:15 |
| mcfrisk | yea, I'm trying to improve the error messages and host dependency detection | 11:16 |
| ad__ | kanavin: agh, would like to test 2.28 in place of 2.33 hadrdknott | 11:16 |
| kanavin | ad__, everything else is tested with 2.33, so you're likely to run into difficulties and unpredictable amount of time trying to resolve them | 11:16 |
| kanavin | why 2.28? | 11:17 |
| RP | ad__: you can copy in recipes and try it but no guarantees as we never tested that | 11:17 |
| ad__ | well, i am trying to compare to an older buldroot stuff that was more performant, using 2.28 | 11:19 |
| ad__ | not sure glibc is the culprit, just investigating | 11:20 |
| kanavin | ad__, it's perhaps easier to take a version of yocto that has 2.28 | 11:20 |
| ad__ | kanavin: ok thanks, so not so simple | 11:20 |
| kanavin | switching major pieces like glibc, or gcc while leaving everything else as it was is asking for cryptic failures | 11:21 |
| ptsneves | RP: I fixed the issue like this(https://pastebin.com/tP10qcVJ) but I would like to create a reproducer for a test. I do not see anything similar. I think these check sum lists are coming from the data cache but I do not see where in the cache code the file list is retrieved. Ideally I would like to create 2 sets of bitbake recipe metadata whose cache objects only differ in the order of the files to checksum. Then from make an expect that they have the same | 11:21 |
| ptsneves | task hash | 11:21 |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has quit IRC (Quit: valdemaras) | 11:22 | |
| RP | ptsneves: sadly these issues are tricky, the ordering comes from python's dict ordering being random | 11:25 |
| RP | ptsneves: the data is put into a dict and effectively randomised there | 11:25 |
| RP | ad__: try swapping in some other recipes, see what happens would be my advice. I don't know how bad the issues would be | 11:26 |
| ptsneves | RP: can you point me in the code where this is happening, so I at least learn something? | 11:26 |
| RP | ptsneves: https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n200 is where it is defined as a dict. https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n338 is where it is assigned into that dict. At that point it is going to be unordered | 11:28 |
| RP | ptsneves: or do you mean where dataCaches[mc].file_checksums[mcfn] comes from ? | 11:29 |
| RP | ptsneves: are those full path filenames? If so that sorting won't be deterministic | 11:30 |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has joined #yocto | 11:30 | |
| ptsneves | Where dataCaches[mc].file_checksums[mcfn] comes from. I see it comes from the cooker but what populates it? | 11:30 |
| ptsneves | RP: In my case no. The signature files are relative paths and after my patch they are correctly ordered | 11:31 |
| RP | ptsneves: add_cacheData in cache.py | 11:31 |
| ptsneves | RP: Thanks! | 11:31 |
| mcfrisk | kanavin: loaded vgem module and added user to "render" group and now test_testimage_virgl_headless passes, thanks | 11:33 |
| RP | ptsneves: I don't think you can't assume those paths are relative | 11:34 |
| RP | ptsneves: see the comment in checksum.py:get_checksums about "/./" being injected into the path. You need to sort on the piece after that marker if present | 11:35 |
| RP | ptsneves: or perhaps just sort on the checksums | 11:36 |
| ptsneves | RP: Ah! clever! Indeed we do not really need any sorting of the paths. We just need the sort for the reproducibility | 11:36 |
| RP | ptsneves: right | 11:37 |
| ptsneves | Ohhh that would be not enough after all. The list will be ambiguous if sorted by checksum if there are more than one file with the same checksum. | 11:40 |
| ptsneves | The list's order i mean | 11:40 |
| ptsneves | I actually have such signature on hand | 11:41 |
| RP | ptsneves: right, then you'll have to use the paths :/ | 11:41 |
| *** xmn <xmn!~xmn@pool-71-105-152-109.nycmny.fios.verizon.net> has joined #yocto | 11:43 | |
| *** olani_ <olani_!~olani@66.159.215.7> has quit IRC (Remote host closed the connection) | 11:47 | |
| ptsneves | RP: Regarding the "/./" being injected. I do not think it matters for task hash purposes. As we talked, the ordering is just a means to have a unique representation for a list of (file,checksum) tuples. Which order irrelevant as long as it is unique. | 11:49 |
| RP | ptsneves: someone might lay out the files differently between layers or something though | 11:50 |
| RP | ptsneves: i.e. there are slightly unusual things someone might do that could affect this :( | 11:50 |
| RP | I really don't want to introduce such a different bug | 11:50 |
| RP | ptsneves: imagine a recipe in a layer that references a file in oe-core and two people lay the layers out differently in different paths | 11:51 |
| *** olani_ <olani_!~olani@66.159.215.7> has joined #yocto | 11:52 | |
| ptsneves | RP: Such case would not affect the hash. If we sort only in the calc_taskhash function like in my proposal https://pastebin.com/tP10qcVJ i think we will not touch anything else. Do you agree? | 11:53 |
| RP | ptsneves: no, I don't agree | 11:53 |
| ptsneves | Nevermind the "/./" is inside the sorted loop. I dont really have a good idea on how to fix this then. I will try to understand better what the /./ does | 11:56 |
| RP | ptsneves: what you probably need to do is write a specific sort function which splits the string on "/./" and returns the second bit as the sort key | 11:57 |
| RP | ptsneves: it is there to stop us including user local build paths in the task checksums | 11:58 |
| RP | otherwise everyone would have to build in the same path for sstate to match | 11:59 |
| ptsneves | ok. Will have a go at it after lunch. Otherwise I will just open a bug so people are aware of the issue. | 11:59 |
| RP | ptsneves: you're close, we just need to make sure we cover the corner cases | 11:59 |
| ptsneves | Ok. By the way is this line https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n1100 incorrect as well? | 12:00 |
| RP | ptsneves: that is probably ok as it is a list, written here: https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/siggen.py#n429 | 12:02 |
| RP | so we probably need to fix that bit | 12:02 |
| RP | once it is a list, the order is determinstic | 12:02 |
| *** pgowda_ <pgowda_!uid516182@2a03:5180:f:3::7:e056> has quit IRC (Quit: Connection closed for inactivity) | 12:41 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 12:49 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 13:00 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-81.dsl.bell.ca> has joined #yocto | 13:29 | |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto | 13:48 | |
| *** Estrella <Estrella!~quassel@075-081-060-240.res.spectrum.com> has joined #yocto | 13:56 | |
| *** dmoseley_ <dmoseley_!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has joined #yocto | 14:05 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has quit IRC (Ping timeout: 256 seconds) | 14:09 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 14:16 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 14:17 | |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 14:23 | |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto | 14:24 | |
| *** otavio <otavio!~otavio@189-11-189-69.user3p.brasiltelecom.net.br> has joined #yocto | 14:25 | |
| *** dmoseley_ <dmoseley_!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 14:38 | |
| ptsneves | RP: https://pastebin.com/HU5gxLcy does this key method work to handle the "/./" case? | 14:39 |
| *** dmoseley <dmoseley!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has joined #yocto | 14:40 | |
| *** belsirk <belsirk!~rfuentess@78.240.112.105> has joined #yocto | 14:40 | |
| *** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1294-101.w86-207.abo.wanadoo.fr> has quit IRC (Ping timeout: 245 seconds) | 14:42 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:42 | |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has quit IRC (Quit: valdemaras) | 14:44 | |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has joined #yocto | 14:45 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 246 seconds) | 14:50 | |
| RP | ptsneves: yes, that looks like what we need | 14:50 |
| ptsneves | ok will submit to the to the mailing list after kids go to sleep :) I do not have the current computer configured for the mailing list | 14:52 |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 14:53 | |
| *** belsirk is now known as rfuentess | 15:07 | |
| *** Schlumpf48 <Schlumpf48!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 15:07 | |
| tlwoerner | aha, there *are* 2 JPEWs! | 15:12 |
| JPEW | tlwoerner: When did that happen.... *looks around suspiciously* | 15:15 |
| *** amitk <amitk!~amit@58.84.62.13> has joined #yocto | 15:21 | |
| *** AKN <AKN!~AKN@49.37.202.224> has quit IRC (Read error: Connection reset by peer) | 15:31 | |
| *** rfuentess <rfuentess!~rfuentess@78.240.112.105> has quit IRC (Remote host closed the connection) | 15:34 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 15:38 | |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has quit IRC (Quit: valdemaras) | 15:40 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 15:42 | |
| yates_work | i have a humble question on the yocto reference manual. | 15:42 |
| *** vladest <vladest!~Thunderbi@89.217.204.83> has quit IRC (Ping timeout: 248 seconds) | 15:43 | |
| yates_work | in that manual i see major headings like "Classes," "Tasks," "Images," etc., but I do not see a corresponding "Recipes." Where are are the various aspects of recipes defined? for example how recipe files are to be named, the required syntactic components (e.g., LICENSE), etc? | 15:44 |
| JPEW | yates_work: Well.... we are actually working on getting that into the manual | 15:45 |
| yates_work | JPEW: Ah! Ok, cool, thanks. | 15:45 |
| yates_work | i am creating a new custom recipe for an app and the question i'm having is this: should i append the version number after the recipe base file name or not? e.g., if my application is called "myapp", is it ok to just name it "myapp.bb" or should i name it "myapp_1.0.bb"? | 15:51 |
| rburton | if you don't put it in the filename then you get the default of 1.0 unless you set PV manually | 15:55 |
| rburton | looking at oe-core will show you that most recipes put the version in the filename unless they're something that doesn't really have a version | 15:57 |
| rburton | like, images don't have intrinsic versions | 15:57 |
| yates_work | rburton: i see. thanks for answering such a basic question! | 15:59 |
| *** Dr_Who <Dr_Who!~tgall@70.35.96.200> has joined #yocto | 16:04 | |
| *** ptsneves <ptsneves!~Thunderbi@84.47.155.82> has quit IRC (Ping timeout: 244 seconds) | 16:10 | |
| zwelch | My do_patch task for my kernel recipe wants to run after do_kernel_metadata, but one of the patches adds the defconfig defined in KBUILD_DEFCONFIG. How can I break this cycle? (FWIW, adding `addtask do_patch before do_kernel_metadata` results in a circular dependency.) | 16:15 |
| zwelch | I suspect one solution is "move the defconfig from the patch to the layer", but the patch is being automatically extracted from a vendor's BSP package and I'd rather avoid complicating that process. | 16:17 |
| Saur | yates_work: Also know that you can only use versioned bbappends if the recipe actually has a version in the recipe name. I.e., for a foobar_1.%.bbappend to work, the foobar recipe has to be called something like foobar_1.2.3.bb. It does not work to have versioned bbappends for recipes that set PV in the recipe. | 16:20 |
| dvergatal | RP: I'm sorry I couldn't get on the meeting I was busy ATM | 16:32 |
| *** mckoan is now known as mckoan|away | 16:35 | |
| *** florian_kc <florian_kc!~florian@217.146.132.69> has quit IRC (Ping timeout: 248 seconds) | 16:37 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:37 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 16:41 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 16:56 | |
| *** vladest <vladest!~Thunderbi@mob-194-230-160-62.cgn.sunrise.net> has joined #yocto | 16:57 | |
| khem | RP: kanavin the example is convertion between two integer types and compiler does an implicit conversion if no explicit cast is specified. Now if implicit conversion is happening and target type is smaller like in this case then there is risk of overflow and behaviour is upto compiler to define with gcc and clang the behaviour is to discard upper 32bits. thats why there is no warning by default but you can use -Wconversion to enable | 16:58 |
| khem | compiler to warn about implicit conversions of this kind | 16:58 |
| RP | dvergatal: no problem | 16:59 |
| *** vladest <vladest!~Thunderbi@mob-194-230-160-62.cgn.sunrise.net> has quit IRC (Ping timeout: 246 seconds) | 17:14 | |
| *** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:71eb:b8e9:8589:9ca5> has quit IRC (Quit: Leaving) | 17:14 | |
| *** tgamblin <tgamblin!~tgamblin@2001:1970:5b1f:ab00:71eb:b8e9:8589:9ca5> has joined #yocto | 17:14 | |
| yates_work | Saur: good point, thanks. | 17:19 |
| kanavin | khem, yes, the point is something else: this behaviour leads to subtle bugs, and compiler could do a better job of warning about it | 17:37 |
| *** lexano <lexano!~lexano@174.119.69.134> has joined #yocto | 17:37 | |
| kanavin | khem, i.e. see dbus's implementation of getting time here. There's no help from gcc indicating that this will discard data when long is 32 bit: https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-sysdeps-unix.c#L3408 | 17:40 |
| kanavin | I have a patch, but I'd rather not have to spend time chasing such issues https://git.yoctoproject.org/poky-contrib/tree/meta/recipes-core/dbus/dbus/0001-time-use-time_t-for-seconds-instead-of-long.patch?h=akanavin/y2038&id=7f47c2 | 17:42 |
| kanavin | not your fault obviously :) | 17:43 |
| *** prabhakarlad <prabhakarlad!~prabhakar@149.11.182.26> has joined #yocto | 17:45 | |
| khem | compiler takes a general approach as long as code generation is correct. It does offers knobs if programmer wants to be strict or not, integer promotion and conversions are language features. Its good to know them especially in C which is not strictly typed language | 17:48 |
| khem | one can certainly argue to make -Wconversion to be part of -Wextra upstream | 17:49 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 17:52 | |
| kanavin | khem, I wonder if you will take a harder stance on this when your power supply goes out in Jan 19 2038 :) | 17:54 |
| kanavin | the more I look at C, the more I'm in favour of bondage and discipline languages | 17:55 |
| kanavin | such as rust | 17:55 |
| *** belgianguy <belgianguy!~belgiangu@ptr-651fbf6qt3idf6rrcwk.18120a2.ip6.access.telenet.be> has joined #yocto | 17:58 | |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has joined #yocto | 18:01 | |
| belgianguy | khem, thanks, yeah I've been reading a lot about Debian, they seem to have only recently fixed a bug with Secure Boot and ARM64, but then whilst digging I read about GPLv3 not being compatible with Secure Boot, which is a hornets nest of its own, ... So far I've only seen deby from meta-debian as a Debian-like distro, but I don't know how similar it is to "real" Debian | 18:03 |
| *** frieder <frieder!~frieder@87.123.146.73> has quit IRC (Remote host closed the connection) | 18:04 | |
| *** flom84 <flom84!~flom84@user/flom84> has joined #yocto | 18:11 | |
| *** flom84 <flom84!~flom84@user/flom84> has quit IRC (Remote host closed the connection) | 18:11 | |
| *** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has quit IRC (Quit: WeeChat 3.8) | 18:13 | |
| *** flom84 <flom84!~flom84@user/flom84> has joined #yocto | 18:17 | |
| *** starblue <starblue!~juergen@dslb-088-078-109-047.088.078.pools.vodafone-ip.de> has joined #yocto | 18:19 | |
| khem | kanavin: I think if I were to start with a clean state - C/C++ will not be at top of consideration for sure | 18:21 |
| kanavin | khem, I've been fixing stuff like this for the past three weeks or so, so my patience with C is a bit thin :) https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/y2038 | 18:22 |
| khem | Y2038 issue is independent of language though | 18:23 |
| *** valdemaras <valdemaras!~valdemara@86.38.230.59> has quit IRC (Read error: Connection reset by peer) | 18:23 | |
| khem | I understand | 18:23 |
| kanavin | I beg to differ. It's very much C-specific. | 18:23 |
| kanavin | C/libc | 18:24 |
| khem | system C library ( particularly glibc in this case ) agreed. But its a implementation issue rather than language | 18:27 |
| khem | belgianguy: yeah, although I would suggest to not mix debian and yocto/OE unless you know what you are getting into, it has a potential of painting yourself into wall | 18:29 |
| kanavin | khem, it's also a language issue. C is both ambiguous about how many bits are in long, and won't warn you when 64 bit time_t is assigned to 32 bit long. | 18:30 |
| belgianguy | khem, hmm, the layered approach really interested me about Yocto/OE and that there was some industrial inflow, from "pure" Debian I've only seen a buster version that supposedly works with a custom 4.14 kernel | 18:30 |
| khem | right, you can get inspiration from that on how secure boot is implemented and get it done on yocto | 18:31 |
| belgianguy | khem, I've seen some Bootlin Youtube videos regarding Secure Boot and it seems a very complex topic, signing every step, and it's not well documented for embedded systems (and depend a lot on vendor, too) | 18:33 |
| khem | belgianguy: yes it is you need all the signing infra vetted | 18:35 |
| khem | kanavin: time_t is not defined by C or C++ std so technically c/c++ compiler can not do much about it. its another define/typedef impl | 18:36 |
| *** amitk <amitk!~amit@58.84.62.13> has quit IRC (Remote host closed the connection) | 18:44 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Quit: ptsneves) | 19:08 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 19:09 | |
| kanavin | khem, C could mandate strict checks in type conversions, and deprecate long... in theory :) | 19:30 |
| kanavin | declaring that c programmers should know what they're doing is insane, because practice shows they do not | 19:31 |
| kanavin | short/long/long long while we're at it | 19:33 |
| kanavin | all this ambiguous crap | 19:33 |
| kanavin | int too! | 19:33 |
| *** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 260 seconds) | 19:34 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-133-038-113.93.133.pool.telefonica.de> has joined #yocto | 19:36 | |
| * kanavin finally gets all 32 bit ptests to pass y2038 grrrr | 19:37 | |
| * kanavin should write 'Why C is not my favorite programming language' one of these days | 19:38 | |
| tgamblin | kanavin: I'd read it | 19:48 |
| kanavin | the title is homage to https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html | 19:49 |
| kanavin | (much of what he said in 1981 doesn't apply to modern pascal) | 19:49 |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 244 seconds) | 19:53 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto | 19:55 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 19:57 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 246 seconds) | 20:02 | |
| *** davidinux <davidinux!~davidinux@95.247.187.85> has quit IRC (Ping timeout: 248 seconds) | 20:03 | |
| *** davidinux <davidinux!~davidinux@95.247.187.85> has joined #yocto | 20:06 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 20:07 | |
| *** vladest <vladest!~Thunderbi@6.174.199.178.dynamic.wline.res.cust.swisscom.ch> has joined #yocto | 20:13 | |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has quit IRC (Quit: Haxxa flies away.) | 20:15 | |
| dario` | hi, i built nativesdk-rust from master, and i think the target definition json files are missing; i think something like https://pbot.rmdir.de/-rwZHClgYadlGTBsVcBk5g might help (that's from some mickledore+X branch, but rust_1.69.bb looks mostly like rust_1.70.bb in master there) | 20:20 |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has joined #yocto | 20:20 | |
| dario` | is anyone around who can confirm whether that's at all possible or whether i'm just looking at it the wrong way or something? | 20:20 |
| kanavin | dario`, you should probably find out how target json gets made and installed in rust-native, and why it isn't happening in nativesdk-rust | 20:25 |
| kanavin | rust toolchain is intricate, and it's unlikely anyone remembers all the details unless they happen to be working on it this very moment | 20:25 |
| RP | dario`: a test case showing how things fails and what this fixes would also help FWIW. I would send the patch, I can imagine how there could be an issue like this | 20:27 |
| RP | dario`: although thinking about it, the target definition would vary per target so it wouldn't be right coming from a nativesdk recipe | 20:27 |
| RP | the nativesdk recipe isn't meant to be target specific | 20:27 |
| dario` | hm, but isn't nativesdk-gcc also specific for whatever target you're building for? | 20:29 |
| RP | dario`: gcc-cross-canadian is the target gcc in an sdk and is architecture specific | 20:30 |
| dario` | but yes, how i noticed was rustc from the sdk complaining that it couldn't find target spec for x86_64-poky-linux, and even `rustc --print target-list` did that, and providing some target spec fixed that issue, maybe that's not the right point though, not sure | 20:31 |
| RP | dario`: I don't doubt it might be missing, I'm just saying that providing it through nativesdk-rust isn't right | 20:31 |
| RP | dario`: we do have sdk tests for rust so this does work with master (see meta/lib/oeqa/sdk/cases/rust.py) | 20:32 |
| dario` | hm, and rust-cross-canadian does install them, maybe i just don't want nativesdk-rust for my use-case then.. | 20:33 |
| dario` | what's nativesdk-rust used for anyway then, if building packages reasonably requires rust-cross-canadian? | 20:35 |
| dario` | (just answer rtfm if that's appropriate) | 20:35 |
| *** flom84 <flom84!~flom84@user/flom84> has quit IRC (Ping timeout: 256 seconds) | 20:36 | |
| *** ptsneves <ptsneves!~Thunderbi@031011128011.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Ping timeout: 252 seconds) | 20:37 | |
| kanavin | dario`, I suspect it is not used for anything in particular | 20:40 |
| kanavin | nativesdk-cargo depends on it, but I'm not sure if that's a leftover from old time | 20:40 |
| kanavin | times | 20:41 |
| RP | dario`: that QA test points at rust-cross-canadian having the json files. Those depend on nativesdk-rust as the compiler which is target independent | 20:41 |
| dario` | is there a one-sentence summary of "nativesdk" like in https://www.mail-archive.com/yocto@yoctoproject.org/msg22483.html? | 20:42 |
| RP | dario`: I think what you want is SDK_TOOLCHAIN_LANGS += "rust" | 20:42 |
| dario` | ah, i'll take a look at that, thanks :) | 20:43 |
| RP | dario`: "nativesdk" build once per sdk, run on sdk, output code for sdk | 20:43 |
| RP | it happens rust can output for target with the json addition | 20:43 |
| RP | kanavin: it is the main compiler, definitely needed. It works a bit differently to gcc | 20:44 |
| smurray | RP: I have a couple of recent mickledore change backports and a fix for riscv for my kirkstone Rust mixin layer, do I just push those in? | 20:45 |
| RP | smurray: I think so, you're the maintainer! :) | 20:45 |
| smurray | RP: heh | 20:45 |
| kanavin | smurray, you can post to yocto@ list too | 20:46 |
| kanavin | for mixin layers it's ok to post/push simultaneously | 20:46 |
| RP | smurray: usually for my own changes I have to post them and get feedback before I merge | 20:46 |
| smurray | kanavin: yeah, I'll post them there as well | 20:46 |
| smurray | RP: right | 20:46 |
| RP | how long "before" is varies depending on how risky the change is and how much breakage it might fix | 20:46 |
| smurray | I actually have a new issue I need to figure out, there's a crate dependency of the major Rust thing we build for AGL atm that doesn't build for risc-v due to it (ring crate) being a wrapper around a bunch of crypto asm | 20:48 |
| dario` | building SDK with SDK_TOOLCHAIN_LANGS += "rust" now, thanks so much RP and kanavin :-) | 20:49 |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 21:01 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 21:02 | |
| yates_work | if i build something with a MACHINE ?= "genericx86-64" under a standard ubuntu desktop distribution, which that actually get installed to the system? (e.g., /usr/local/bin)? | 21:05 |
| yates_work | slightly different question: if i build something with a MACHINE ?= "genericx86-64" under a standard ubuntu desktop distribution, can i run it natively on that system? | 21:06 |
| *** amitk_ <amitk_!~amit@58.84.62.13> has quit IRC (Ping timeout: 256 seconds) | 21:08 | |
| yates_work | s/which that/will that/ | 21:08 |
| *** amitk <amitk!~amit@58.84.62.13> has joined #yocto | 21:09 | |
| kanavin | yates_work, in general, no. If you want to run things on ubuntu, build them using ubuntu tooling. | 21:11 |
| kanavin | yates_work, however, building something in it's -native variant will work | 21:13 |
| kanavin | but that's independent of what MACHINE is set to | 21:13 |
| *** dgriego_ <dgriego_!~dgriego@user/dgriego> has joined #yocto | 21:30 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-133-038-113.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds) | 21:31 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 248 seconds) | 21:32 | |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 21:57 | |
| khem | kanavin: there is lot of legacy code in C that has to be carried forward. Clang is doing some aggressive steps in this area e.g. trying to default to newer C std and this leads to fundamental breakages like autoconf probing tests failing to compile and worse in some cases the test logic depended on these old c89 behaviors | 21:57 |
| *** mpb27 <mpb27!~mpb27@2604:3d08:1c7f:cc50:ac33:eab1:2021:ab99> has joined #yocto | 22:23 | |
| *** mpb28 <mpb28!~mpb28@2604:3d08:1c7f:cc50:ac33:eab1:2021:ab99> has joined #yocto | 22:23 | |
| *** dmoseley_ <dmoseley_!~dmoseley@50.4.187.9> has joined #yocto | 22:24 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-9-187.evv.wideopenwest.com> has quit IRC (Ping timeout: 252 seconds) | 22:25 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!