You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(340) |
Dec
(162) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(456) |
Feb
(319) |
Mar
(493) |
Apr
(555) |
May
(47) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(114) |
Nov
(216) |
Dec
(198) |
2002 |
Jan
(284) |
Feb
(410) |
Mar
(243) |
Apr
(118) |
May
(65) |
Jun
(163) |
Jul
(300) |
Aug
(156) |
Sep
(201) |
Oct
(161) |
Nov
(62) |
Dec
(40) |
2003 |
Jan
(141) |
Feb
(320) |
Mar
(96) |
Apr
(55) |
May
(37) |
Jun
(113) |
Jul
(82) |
Aug
(35) |
Sep
(34) |
Oct
(37) |
Nov
(15) |
Dec
(77) |
2004 |
Jan
(31) |
Feb
(77) |
Mar
(106) |
Apr
(80) |
May
(59) |
Jun
(54) |
Jul
(127) |
Aug
(18) |
Sep
(27) |
Oct
(54) |
Nov
(36) |
Dec
(59) |
2005 |
Jan
(33) |
Feb
(20) |
Mar
(65) |
Apr
(68) |
May
(54) |
Jun
(26) |
Jul
(28) |
Aug
(85) |
Sep
(7) |
Oct
(16) |
Nov
(11) |
Dec
(13) |
2006 |
Jan
(14) |
Feb
(21) |
Mar
(259) |
Apr
(91) |
May
(65) |
Jun
(125) |
Jul
(71) |
Aug
(44) |
Sep
(35) |
Oct
(13) |
Nov
(74) |
Dec
(15) |
2007 |
Jan
(23) |
Feb
(32) |
Mar
(57) |
Apr
(43) |
May
(15) |
Jun
(4) |
Jul
(7) |
Aug
(16) |
Sep
|
Oct
(21) |
Nov
(7) |
Dec
(1) |
2008 |
Jan
(38) |
Feb
(24) |
Mar
(57) |
Apr
(9) |
May
(1) |
Jun
(3) |
Jul
(5) |
Aug
(6) |
Sep
(2) |
Oct
(5) |
Nov
(3) |
Dec
(2) |
2009 |
Jan
(1) |
Feb
(9) |
Mar
(16) |
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(6) |
Aug
(22) |
Sep
(1) |
Oct
(6) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(5) |
Apr
(40) |
May
(28) |
Jun
(85) |
Jul
(26) |
Aug
(32) |
Sep
(128) |
Oct
(170) |
Nov
(219) |
Dec
(78) |
2011 |
Jan
(58) |
Feb
(95) |
Mar
(36) |
Apr
(14) |
May
(57) |
Jun
(164) |
Jul
(59) |
Aug
(23) |
Sep
(34) |
Oct
(29) |
Nov
(44) |
Dec
(8) |
2012 |
Jan
(33) |
Feb
(67) |
Mar
(79) |
Apr
(37) |
May
(30) |
Jun
(31) |
Jul
(36) |
Aug
(88) |
Sep
(62) |
Oct
(120) |
Nov
(12) |
Dec
(84) |
2013 |
Jan
(31) |
Feb
(9) |
Mar
(13) |
Apr
(30) |
May
(17) |
Jun
(18) |
Jul
(24) |
Aug
(5) |
Sep
(4) |
Oct
(39) |
Nov
(6) |
Dec
(2) |
2014 |
Jan
(56) |
Feb
(34) |
Mar
(6) |
Apr
(9) |
May
(1) |
Jun
(16) |
Jul
(83) |
Aug
(39) |
Sep
(10) |
Oct
(50) |
Nov
(42) |
Dec
(31) |
2015 |
Jan
(40) |
Feb
(18) |
Mar
(116) |
Apr
(95) |
May
(14) |
Jun
(10) |
Jul
(60) |
Aug
(46) |
Sep
(47) |
Oct
(34) |
Nov
(24) |
Dec
(58) |
2016 |
Jan
(39) |
Feb
(18) |
Mar
(98) |
Apr
(13) |
May
(5) |
Jun
(1) |
Jul
(7) |
Aug
|
Sep
(1) |
Oct
(14) |
Nov
(1) |
Dec
(2) |
2017 |
Jan
(32) |
Feb
|
Mar
|
Apr
(3) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(15) |
Nov
(2) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(24) |
Mar
(4) |
Apr
(8) |
May
|
Jun
(6) |
Jul
(2) |
Aug
(6) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
|
2019 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(5) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
(1) |
Feb
(6) |
Mar
(7) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(15) |
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Lars K. <lar...@gm...> - 2024-07-29 07:03:36
|
Hello, After the inclusion of needed EFI modules (thanks) I have tested various setups, and it works great. Here's a script to deploy an USB key (or other storage) for dual booting on BIOS or EFI systems. It takes the target and source filename as the parameters: https://gist.github.com/lkarlslund/2330250ded87b919bfd043e9b353aac4 ./deploy-leaf.sh /dev/sda Bering-uClibc_7.3.1_x86_64_syslinux_vga.tar.gz There are no warnings / confirmations to protect the chosen target, it will just get wiped / reformatted. I'm using Ubuntu to run it - YMMV. Best regards, Lars |
From: Erich T. <eri...@th...> - 2024-05-30 21:44:34
|
From: Lars K. <lar...@gm...> - 2024-05-21 12:36:44
|
Thanks for adding these changes so quickly, great effort! I look forward to the upcoming commit and rc2 (can't see it pushed yet). Regarding the space usage, I agree that x64 should indicate a modern system with more capacity than older 32-bit systems. I'm not sure it even makes sense to add this to the 32-bit builds, unless people want to run a 32-bit version on a 64-bit EFI-only system, which makes little sense to me. But that decision is totally up to you. When the rc2 is out, I'll work a bit more on the script and post information about it here or in the users list. Regards, Lars On Mon, May 20, 2024 at 4:09 PM KP.Kirchdoerfer <ka...@be...> wrote: > Hi Lars; > > Am Mittwoch, 15. Mai 2024, 13:32:52 CEST schrieb Lars Karlslund: > > Hello, > > > > While BIOS/CSM is still supported on a lot of hardware, some vendors are > > starting to ship UEFI only enabled firmware, which is problematic due to > > some missing support not being baked into the linux kernels that ships > with > > LEAF. > > > > I've been experimenting a bit with this, and have come up with a solution > > that allows my USB-keys to support both BIOS and UEFI at the same time, > by > > creating an EFI-partition for GRUB2/EFI and also installing GRUB2/BIOS on > > the primary FAT partition that contains all the regular files from LEAF. > > > > The only thing that is missing is support for EFI framebuffer. This is > > required if you want to have a physical monitor with text output - which > I > > really like both for diagnostics or in error conditions. As it is now the > > existing kernel boots, but you get no output on the screen after the > > bootloader. > > > > With a custom compiled kernel everything works fine, so I was wondering > if > > I could persuade maintainers to add the missing .config entries to the > > stock shipped kernels? They don't take up much space and should not > > interfere with systems that are running under BIOS mode. > > I've added you're config entries for x86_64 (for now). > > Indeed it works with a system running in BIOS mode; about size YMMV the > kernel > is about 300kb bigger and modules.sqfs as well. But on a x86_64 system > such > size changes shouldn't be an real issue. > > I've building an rc2 for further testing and intend to add EFI support for > the > i686 kernel later. > > > > > > These are the entries that I used: > > > > CONFIG_ACPI_BGRT=y > > CONFIG_ACPI_PRMT=y > > CONFIG_APERTURE_HELPERS=y > > CONFIG_BOOT_VESA_SUPPORT=y > > CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y > > CONFIG_EFI_CUSTOM_SSDT_OVERLAYS=y > > CONFIG_EFI_DXE_MEM_ATTRIBUTES=y > > CONFIG_EFI_EARLYCON=y > > CONFIG_EFI_ESRT=y > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y > > CONFIG_EFI_MIXED=y > > CONFIG_EFI_RUNTIME_WRAPPERS=y > > CONFIG_EFI_STUB=y > > CONFIG_EFIVAR_FS=m > > CONFIG_EFI_VARS_PSTORE=y > > CONFIG_EFI=y > > CONFIG_FB_CFB_COPYAREA=y > > CONFIG_FB_CFB_FILLRECT=y > > CONFIG_FB_CFB_IMAGEBLIT=y > > CONFIG_FB_CMDLINE=y > > CONFIG_FB_DEFERRED_IO=y > > CONFIG_FB_EFI=y > > CONFIG_FB_NOTIFY=y > > CONFIG_FB_SYS_COPYAREA=y > > CONFIG_FB_SYS_FILLRECT=y > > CONFIG_FB_SYS_FOPS=y > > CONFIG_FB_SYS_IMAGEBLIT=y > > CONFIG_FB=y > > CONFIG_FIRMWARE_EDID=y > > CONFIG_FONT_8x16=y > > CONFIG_FONT_8x8=y > > CONFIG_FONT_SUPPORT=y > > CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y > > CONFIG_FRAMEBUFFER_CONSOLE=y > > CONFIG_INIT_STACK_NONE=y > > CONFIG_SYSFB=y > > CONFIG_XEN_EFI=y > > CONFIG_XEN_FBDEV_FRONTEND=y > > > > If there is interest, I can also share the script that I've made that > > prepares new USB-keys for this - it partitions, formats, decompresses > LEAF, > > installs bootloader etc. > > Of course, if you can provide (commented) scripts it may help others as > well. > > > FYI my use of LEAF is for a customer that has been using it for more than > > 10 years, and have 40-50 office firewalls deployed. All configuration is > > maintained in a central database, and complete firewalls are deployed > > pre-configured with everything needed as tgz files for either new > USB-keys > > or online updates to existing systems. > > Nice to hear! > > kp > > > > > Best regards, > > > > Lars > > > > > > _______________________________________________ > > leaf-devel mailing list > > lea...@li... > > https://lists.sourceforge.net/lists/listinfo/leaf-devel > > > > > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel > |
From: KP.Kirchdoerfer <ka...@be...> - 2024-05-20 14:09:41
|
Hi Lars; Am Mittwoch, 15. Mai 2024, 13:32:52 CEST schrieb Lars Karlslund: > Hello, > > While BIOS/CSM is still supported on a lot of hardware, some vendors are > starting to ship UEFI only enabled firmware, which is problematic due to > some missing support not being baked into the linux kernels that ships with > LEAF. > > I've been experimenting a bit with this, and have come up with a solution > that allows my USB-keys to support both BIOS and UEFI at the same time, by > creating an EFI-partition for GRUB2/EFI and also installing GRUB2/BIOS on > the primary FAT partition that contains all the regular files from LEAF. > > The only thing that is missing is support for EFI framebuffer. This is > required if you want to have a physical monitor with text output - which I > really like both for diagnostics or in error conditions. As it is now the > existing kernel boots, but you get no output on the screen after the > bootloader. > > With a custom compiled kernel everything works fine, so I was wondering if > I could persuade maintainers to add the missing .config entries to the > stock shipped kernels? They don't take up much space and should not > interfere with systems that are running under BIOS mode. I've added you're config entries for x86_64 (for now). Indeed it works with a system running in BIOS mode; about size YMMV the kernel is about 300kb bigger and modules.sqfs as well. But on a x86_64 system such size changes shouldn't be an real issue. I've building an rc2 for further testing and intend to add EFI support for the i686 kernel later. > These are the entries that I used: > > CONFIG_ACPI_BGRT=y > CONFIG_ACPI_PRMT=y > CONFIG_APERTURE_HELPERS=y > CONFIG_BOOT_VESA_SUPPORT=y > CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y > CONFIG_EFI_CUSTOM_SSDT_OVERLAYS=y > CONFIG_EFI_DXE_MEM_ATTRIBUTES=y > CONFIG_EFI_EARLYCON=y > CONFIG_EFI_ESRT=y > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y > CONFIG_EFI_MIXED=y > CONFIG_EFI_RUNTIME_WRAPPERS=y > CONFIG_EFI_STUB=y > CONFIG_EFIVAR_FS=m > CONFIG_EFI_VARS_PSTORE=y > CONFIG_EFI=y > CONFIG_FB_CFB_COPYAREA=y > CONFIG_FB_CFB_FILLRECT=y > CONFIG_FB_CFB_IMAGEBLIT=y > CONFIG_FB_CMDLINE=y > CONFIG_FB_DEFERRED_IO=y > CONFIG_FB_EFI=y > CONFIG_FB_NOTIFY=y > CONFIG_FB_SYS_COPYAREA=y > CONFIG_FB_SYS_FILLRECT=y > CONFIG_FB_SYS_FOPS=y > CONFIG_FB_SYS_IMAGEBLIT=y > CONFIG_FB=y > CONFIG_FIRMWARE_EDID=y > CONFIG_FONT_8x16=y > CONFIG_FONT_8x8=y > CONFIG_FONT_SUPPORT=y > CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_INIT_STACK_NONE=y > CONFIG_SYSFB=y > CONFIG_XEN_EFI=y > CONFIG_XEN_FBDEV_FRONTEND=y > > If there is interest, I can also share the script that I've made that > prepares new USB-keys for this - it partitions, formats, decompresses LEAF, > installs bootloader etc. Of course, if you can provide (commented) scripts it may help others as well. > FYI my use of LEAF is for a customer that has been using it for more than > 10 years, and have 40-50 office firewalls deployed. All configuration is > maintained in a central database, and complete firewalls are deployed > pre-configured with everything needed as tgz files for either new USB-keys > or online updates to existing systems. Nice to hear! kp > > Best regards, > > Lars > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Lars K. <lar...@gm...> - 2024-05-15 11:33:14
|
Hello, While BIOS/CSM is still supported on a lot of hardware, some vendors are starting to ship UEFI only enabled firmware, which is problematic due to some missing support not being baked into the linux kernels that ships with LEAF. I've been experimenting a bit with this, and have come up with a solution that allows my USB-keys to support both BIOS and UEFI at the same time, by creating an EFI-partition for GRUB2/EFI and also installing GRUB2/BIOS on the primary FAT partition that contains all the regular files from LEAF. The only thing that is missing is support for EFI framebuffer. This is required if you want to have a physical monitor with text output - which I really like both for diagnostics or in error conditions. As it is now the existing kernel boots, but you get no output on the screen after the bootloader. With a custom compiled kernel everything works fine, so I was wondering if I could persuade maintainers to add the missing .config entries to the stock shipped kernels? They don't take up much space and should not interfere with systems that are running under BIOS mode. These are the entries that I used: CONFIG_ACPI_BGRT=y CONFIG_ACPI_PRMT=y CONFIG_APERTURE_HELPERS=y CONFIG_BOOT_VESA_SUPPORT=y CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y CONFIG_EFI_CUSTOM_SSDT_OVERLAYS=y CONFIG_EFI_DXE_MEM_ATTRIBUTES=y CONFIG_EFI_EARLYCON=y CONFIG_EFI_ESRT=y CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y CONFIG_EFI_MIXED=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_EFI_STUB=y CONFIG_EFIVAR_FS=m CONFIG_EFI_VARS_PSTORE=y CONFIG_EFI=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_CMDLINE=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_EFI=y CONFIG_FB_NOTIFY=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_FOPS=y CONFIG_FB_SYS_IMAGEBLIT=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FONT_8x16=y CONFIG_FONT_8x8=y CONFIG_FONT_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_INIT_STACK_NONE=y CONFIG_SYSFB=y CONFIG_XEN_EFI=y CONFIG_XEN_FBDEV_FRONTEND=y If there is interest, I can also share the script that I've made that prepares new USB-keys for this - it partitions, formats, decompresses LEAF, installs bootloader etc. FYI my use of LEAF is for a customer that has been using it for more than 10 years, and have 40-50 office firewalls deployed. All configuration is maintained in a central database, and complete firewalls are deployed pre-configured with everything needed as tgz files for either new USB-keys or online updates to existing systems. Best regards, Lars |
From: Mike N. <mh...@gm...> - 2024-04-22 14:40:26
|
The current LEAF development team may want to revisit moving off of SourceForge to address security concerns. https://about.gitlab.com/pricing/ On Sun, 2024-04-21 at 11:37 -0700, Mike Noyes wrote: > Some rather nasty bugs present if SF is still using 2.1.21. > > ~mailman-coders/mailman/2.1 > Here is a history of user visible changes to Mailman > https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/NEWS > > > On Sun, 2024-04-21 at 11:14 -0700, Mike Noyes wrote: > > SourceForge is running Mailman version 2.1.21. > > https://www.list.org/ > > The current stable GNU Mailman versions are: > > 20-Oct-2023 Mailman 3.3.9 (Tom Sawyer) > > 13-Dec-2021 Mailman 2.1.39 > > > > > > https://sourceforge.net/p/forge/documentation/Contact%20Us/ > > https://sourceforge.net/p/forge/site-support/new/ > > > > > > On Sun, 2024-04-21 at 08:38 -0700, Mike Noyes wrote: > > > It looks like an issue with the SourceForge Mailman installation. -snip- -- Mike Noyes mike at noyes.name @mhnoyes:matrix.org |
From: Mike N. <mh...@gm...> - 2024-04-21 22:25:26
|
SourceForge is running Mailman version 2.1.21. https://www.list.org/ The current stable GNU Mailman versions are: 20-Oct-2023 Mailman 3.3.9 (Tom Sawyer) 13-Dec-2021 Mailman 2.1.39 https://sourceforge.net/p/forge/documentation/Contact%20Us/ https://sourceforge.net/p/forge/site-support/new/ On Sun, 2024-04-21 at 08:38 -0700, Mike Noyes wrote: > It looks like an issue with the SourceForge Mailman installation. > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html#trusted-authserv-ids > # Trusted Domains > # > # This list should include all additional domains > # that you manage that may be handling your incoming mail > # Only necessary to update if there are local domains or subdomains > # that are performing DKIM, DMARC, or SPF checks. > # > # trusted_authserv_ids: subdomain.your_domain.com, trusted_other_domain.com > trusted_authserv_ids: > > > > On Sat, 2024-04-20 at 22:18 -0700, Tom Eastep wrote: > > On 4/18/24 2:53 PM, Erich Titl wrote: > > > Hi folks > > > > > > I have problem with the mailing lists (leaf-devel, leaf-user), > > > possibly due to some bounces for my address. > > > > > > - I can send to the list > > > - I can log into the mailman list manager, see and modify my > > > > - options I can trigger a password reminder on the list manager > > > - and receive it > > > > > > - BUT I do not get the list messages, I have to look them up > > > - using the web interface which is kind of annoying. > > > > > > Ideas? > > > > > > > Hi Erich, > > > > I have the same problem. I believe the reason is: > > > > - The Sourceforge list manager specifies the sender as "Erich Titl > > <eri...@th...>" ("Tom Eastep <te...@sh...>" in > > my case). The problem started for me when this behavior was > > instituted. > > > > - Both think.ch and shorewall.net enable SPF > > > > teastep@debianvm:~$ dig think.ch TXT > > > > ; <<>> DiG 9.19.21-1-Debian <<>> think.ch TXT > > ;; global options: +cmd > > > > ... > > > > ;; ANSWER SECTION: > > think.ch. 300 IN TXT "v=spf1 mx a:luna.think.ch" > > > > teastep@debianvm:~$ dig shorewall.net TXT > > > > ; <<>> DiG 9.19.21-1-Debian <<>> shorewall.net TXT > > ;; global options: +cmd > > > > ... > > > > ;; ANSWER SECTION: > > shorewall.net.3600IN TXT "v=spf1 include:_spf.google.com > > ~all" > > > > I am no longer a Sourceforge list admin, so I can't see if there is > > a way to disable the above mentioned behavior on individual lists. > > > > -Tom > -- Mike Noyes mike at noyes.name @mhnoyes:matrix.org |
From: Mike N. <mh...@gm...> - 2024-04-21 21:09:16
|
Some rather nasty bugs present if SF is still using 2.1.21. ~mailman-coders/mailman/2.1 Here is a history of user visible changes to Mailman https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/NEWS On Sun, 2024-04-21 at 11:14 -0700, Mike Noyes wrote: > SourceForge is running Mailman version 2.1.21. > https://www.list.org/ > The current stable GNU Mailman versions are: > 20-Oct-2023 Mailman 3.3.9 (Tom Sawyer) > 13-Dec-2021 Mailman 2.1.39 > > > https://sourceforge.net/p/forge/documentation/Contact%20Us/ > https://sourceforge.net/p/forge/site-support/new/ > > > On Sun, 2024-04-21 at 08:38 -0700, Mike Noyes wrote: > > It looks like an issue with the SourceForge Mailman installation. > > > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html#trusted-authserv-ids > > # Trusted Domains > > # > > # This list should include all additional domains > > # that you manage that may be handling your incoming mail > > # Only necessary to update if there are local domains or subdomains > > # that are performing DKIM, DMARC, or SPF checks. > > # > > # trusted_authserv_ids: subdomain.your_domain.com, trusted_other_domain.com > > trusted_authserv_ids: > > > > > > > > On Sat, 2024-04-20 at 22:18 -0700, Tom Eastep wrote: > > > On 4/18/24 2:53 PM, Erich Titl wrote: > > > > Hi folks > > > > > > > > I have problem with the mailing lists (leaf-devel, leaf-user), > > > > possibly due to some bounces for my address. > > > > > > > > - I can send to the list > > > > - I can log into the mailman list manager, see and modify my > > > > > > - options I can trigger a password reminder on the list manager > > > > - and receive it > > > > > > > > - BUT I do not get the list messages, I have to look them up > > > > - using the web interface which is kind of annoying. > > > > > > > > Ideas? > > > > > > > > > > Hi Erich, > > > > > > I have the same problem. I believe the reason is: > > > > > > - The Sourceforge list manager specifies the sender as "Erich > > > Titl <eri...@th...>" ("Tom Eastep > > > <te...@sh...>" in my case). The problem started for > > > me when this behavior was instituted. > > > > > > - Both think.ch and shorewall.net enable SPF > > > > > > teastep@debianvm:~$ dig think.ch TXT > > > > > > ; <<>> DiG 9.19.21-1-Debian <<>> think.ch TXT > > > ;; global options: +cmd > > > > > > ... > > > > > > ;; ANSWER SECTION: > > > think.ch. 300 IN TXT "v=spf1 mx > > > a:luna.think.ch" > > > > > > teastep@debianvm:~$ dig shorewall.net TXT > > > > > > ; <<>> DiG 9.19.21-1-Debian <<>> shorewall.net TXT > > > ;; global options: +cmd > > > > > > ... > > > > > > ;; ANSWER SECTION: > > > shorewall.net.3600IN TXT "v=spf1 include:_spf.google.com > > > ~all" > > > > > > I am no longer a Sourceforge list admin, so I can't see if there > > > is a way to disable the above mentioned behavior on individual > > > lists. > > > > > > -Tom > > > -- Mike Noyes mike at noyes.name @mhnoyes:matrix.org |
From: Erich T. <eri...@th...> - 2024-04-21 17:04:22
|
Hi Tom Am 21.04.2024 um 17:38 schrieb Mike Noyes: .... >> Hi Erich, >> >> I have the same problem. I believe the reason is: >> >> - The Sourceforge list manager specifies the sender as "Erich Titl >> <eri...@th...>" ("Tom Eastep <te...@sh...>" in my >> case). The problem started for me when this behavior was >> instituted. >> >> - Both think.ch and shorewall.net enable SPF >> >> teastep@debianvm:~$ dig think.ch TXT >> >> ; <<>> DiG 9.19.21-1-Debian <<>> think.ch TXT >> ;; global options: +cmd >> >> ... >> >> ;; ANSWER SECTION: >> think.ch. 300 IN TXT "v=spf1 mx a:luna.think.ch" >> >> teastep@debianvm:~$ dig shorewall.net TXT >> >> ; <<>> DiG 9.19.21-1-Debian <<>> shorewall.net TXT >> ;; global options: +cmd >> >> ... >> >> ;; ANSWER SECTION: >> shorewall.net.3600IN TXT "v=spf1 include:_spf.google.com ~all" >> >> I am no longer a Sourceforge list admin, so I can't see if there is a >> way to disable the above mentioned behavior on individual lists. >> >> -Tom > Thanks for the answer, so I am not the only one. I would like to keep my SPF record though as it makes life easier on other destinations. cheers ET -- „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ ―Friedrich Nietzsche |
From: Mike N. <mh...@gm...> - 2024-04-21 15:38:40
|
It looks like an issue with the SourceForge Mailman installation. https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html#trusted-authserv-ids # Trusted Domains # # This list should include all additional domains # that you manage that may be handling your incoming mail # Only necessary to update if there are local domains or subdomains # that are performing DKIM, DMARC, or SPF checks. # # trusted_authserv_ids: subdomain.your_domain.com, trusted_other_domain.com trusted_authserv_ids: On Sat, 2024-04-20 at 22:18 -0700, Tom Eastep wrote: > On 4/18/24 2:53 PM, Erich Titl wrote: > > Hi folks > > > > I have problem with the mailing lists (leaf-devel, leaf-user), > > possibly due to some bounces for my address. > > > > - I can send to the list > > - I can log into the mailman list manager, see and modify my > > - options I can trigger a password reminder on the list manager and > > - receive it > > > > - BUT I do not get the list messages, I have to look them up using > > - the web interface which is kind of annoying. > > > > Ideas? > > > > Hi Erich, > > I have the same problem. I believe the reason is: > > - The Sourceforge list manager specifies the sender as "Erich Titl > <eri...@th...>" ("Tom Eastep <te...@sh...>" in my > case). The problem started for me when this behavior was > instituted. > > - Both think.ch and shorewall.net enable SPF > > teastep@debianvm:~$ dig think.ch TXT > > ; <<>> DiG 9.19.21-1-Debian <<>> think.ch TXT > ;; global options: +cmd > > ... > > ;; ANSWER SECTION: > think.ch. 300 IN TXT "v=spf1 mx a:luna.think.ch" > > teastep@debianvm:~$ dig shorewall.net TXT > > ; <<>> DiG 9.19.21-1-Debian <<>> shorewall.net TXT > ;; global options: +cmd > > ... > > ;; ANSWER SECTION: > shorewall.net.3600IN TXT "v=spf1 include:_spf.google.com ~all" > > I am no longer a Sourceforge list admin, so I can't see if there is a > way to disable the above mentioned behavior on individual lists. > > -Tom -- Mike Noyes mike at noyes.name @mhnoyes:matrix.org |
From: Tom E. <te...@sh...> - 2024-04-21 05:18:59
|
On 4/18/24 2:53 PM, Erich Titl wrote: > Hi folks > > I have problem with the mailing lists (leaf-devel, leaf-user), possibly > due to some bounces for my address. > > - I can send to the list > - I can log into the mailman list manager, see and modify my options > - I can trigger a password reminder on the list manager and receive it > > - BUT I do not get the list messages, I have to look them up using the > web interface which is kind of annoying. > > Ideas? > Hi Erich, I have the same problem. I believe the reason is: - The Sourceforge list manager specifies the sender as "Erich Titl <eri...@th...>" ("Tom Eastep <te...@sh...>" in my case). The problem started for me when this behavior was instituted. - Both think.ch and shorewall.net enable SPF teastep@debianvm:~$ dig think.ch TXT ; <<>> DiG 9.19.21-1-Debian <<>> think.ch TXT ;; global options: +cmd ... ;; ANSWER SECTION: think.ch. 300 IN TXT "v=spf1 mx a:luna.think.ch" teastep@debianvm:~$ dig shorewall.net TXT ; <<>> DiG 9.19.21-1-Debian <<>> shorewall.net TXT ;; global options: +cmd ... ;; ANSWER SECTION: shorewall.net.3600IN TXT "v=spf1 include:_spf.google.com ~all" I am no longer a Sourceforge list admin, so I can't see if there is a way to disable the above mentioned behavior on individual lists. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Mike N. <mh...@gm...> - 2024-04-19 14:28:44
|
Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/ In addition to these recommendations, there are a number of security best practices that can improve the security properties of our projects. While these recommendations will not thwart a persistent social engineering attack, they may help improve your overall security posture of your project. -- Mike Noyes mike at noyes.name @mhnoyes:matrix.org |
From: Boris <bo...@ca...> - 2024-04-19 13:07:37
|
Hej Erich, it does not explain your symptoms, but think.ch seems to be blacklisted on Spamhouse ZEN an SORBS DUHL (mxtoolbox.com). Best greetings from Kiel Fjord, Boris Am 18.04.24 um 23:53 schrieb Erich Titl: > Hi folks > > I have problem with the mailing lists (leaf-devel, leaf-user), possibly > due to some bounces for my address. > > - I can send to the list > - I can log into the mailman list manager, see and modify my options > - I can trigger a password reminder on the list manager and receive it > > - BUT I do not get the list messages, I have to look them up using the > web interface which is kind of annoying. > > Ideas? > > cheers > > ET > > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2024-04-18 21:54:24
|
Hi folks I have problem with the mailing lists (leaf-devel, leaf-user), possibly due to some bounces for my address. - I can send to the list - I can log into the mailman list manager, see and modify my options - I can trigger a password reminder on the list manager and receive it - BUT I do not get the list messages, I have to look them up using the web interface which is kind of annoying. Ideas? cheers ET -- „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ ―Friedrich Nietzsche |
From: Boris <bo...@ca...> - 2024-04-18 19:59:00
|
Am 18.04.24 um 16:32 schrieb Erich Titl: > „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ > ―Friedrich Nietzsche Great philosophy! In fact I seem to be unfortunate slave, but I learn..... Boris |
From: Erich T. <eri...@th...> - 2024-04-18 14:34:24
|
Hi everybody It looks like a non merged local branch (whatever that is) caused a conflict in my repository. Deleting all branches (except master) appears to have solved the problem. cheers ET -- „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ ―Friedrich Nietzsche |
From: Erich T. <eri...@th...> - 2024-04-18 13:10:50
|
Test, please disregard. -- „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ ―Friedrich Nietzsche |
From: Erich T. <eri...@th...> - 2024-04-18 13:04:33
|
Hi KP Tried again, to no avail. mega@leafbuilder:~/leaf/devel/packages$ ls 3_1 4_0 5_1 5_2 latest stable tools mega@leafbuilder:~/leaf/devel/packages$ git branch 7.0.0 7.0.2 7.0.3 7.1.2 * master mega@leafbuilder:~/leaf/devel/packages$ git pull Already up to date. Yesterday I cloned the repository again, just to find that the new clone behaved like the existing one. I cloned it using my credentials at sourceforge, e.g. my public key stored there. So even if I work on a freshly cloned I cannot see the full structure on master mega@leafbuilder:~/leaf/devel$ cd packages/ mega@leafbuilder:~/leaf/devel/packages$ ls 3_1 4_0 5_1 5_2 latest stable tools mega@leafbuilder:~/leaf/devel/packages$ git branch 7.0.0 7.0.2 7.0.3 7.1.2 * master mega@leafbuilder:~/leaf/devel/packages$ git pull Already up to date. If I switch to a branch I built a while ago I can see the content. mega@leafbuilder:~/leaf/devel/packages$ git checkout 7.1.2 Updating files: 100% (5911/5911), done. Switched to branch '7.1.2' Your branch is up to date with 'origin/7.1.2'. mega@leafbuilder:~/leaf/devel/packages$ ls armv8a bcmrpi cortex72 geode i486 i686 version wrap x86_64 mega@leafbuilder:~/leaf/devel/packages$ git log commit 7cfa2ae6e24ef268fca036d4a54baf8a602c8b45 (HEAD -> 7.1.2, origin/7.1.2) Author: kapeka <ka...@us...> Date: Sat Feb 19 16:50:00 2022 +0100 ./release-to-git.sh committed branch 7.1.2 I cannot see any commit messages by release-to-git.sh in master, just updates for the latest and stable files. mega@leafbuilder:~/leaf/devel/packages$ git checkout master Updating files: 100% (5911/5911), done. Switched to branch 'master' Your branch is up to date with 'origin/master'. mega@leafbuilder:~/leaf/devel/packages$ git log commit 64b9b9ec0a9b35ec3fdbc844673f1ec11525450b (HEAD -> master, origin/master, origin/HEAD) Author: kapeka <ka...@us...> Date: Wed Apr 10 14:06:32 2024 +0200 update lastest to 7.3.1-beta1 commit e8507480dbf1ed8b63a473d02b4707fed17a9686 Author: kapeka <ka...@us...> Date: Sun Dec 31 17:52:50 2023 +0100 update latest and stable to 7.3.0 commit 6145edbaf9c0e62fd4e59d9608bef52dc97ef4b4 Author: kapeka <ka...@us...> Date: Sat Dec 16 12:46:39 2023 +0100 update to 7.3.0-rc1 commit 905de71b79ab5a8b73946efd013f5c42c338c701 Author: kapeka <ka...@us...> Date: Sat Oct 28 18:57:49 2023 +0200 update stable to 7.2.3 .... It looks like release-to-git was not run at all on master mega@leafbuilder:~/leaf/devel/packages$ git log | grep release Make release-to-git more resilient against missing targets Disables signing in release_to_git activate signing code in release_to_git.sh First attempt to integrate signing into release_to_git.sh Switched sha256sum.list to sha512sum.list in release_to_git.sh Added i386 to ARCHS to be deployed in release-to-git.sh Fixed packagedir parameter in release-to-git.sh Added parameter for package path to release-to-git.sh Added cd to REPOPATH to avoid git hickups in release-to-git.sh First attempt to move release_to_git.sh to 6.x Removed abort in release_to_git.sh in case of --help Added writing of sha1sum.list to release-to-git Made the copy routines more generic in release-to-git Cleaned up the bcmrpi target in release-to-git Reenabled cleanup in release-to-git release-to-git now handles i386 based files completely More cosmetics on release-to-git A bit cleanup to release-to-git First attempt to improve release-to-git Small changes in release_to_git added release_to_git script to the tools directory As opposed to 7.1.2 mega@leafbuilder:~/leaf/devel/packages$ git checkout 7.1.2 Updating files: 100% (5911/5911), done. Switched to branch '7.1.2' Your branch is up to date with 'origin/7.1.2'. mega@leafbuilder:~/leaf/devel/packages$ git log | grep release ./release-to-git.sh committed branch 7.1.2 mega@leafbuilder:~/leaf/devel/packages$ git checkout -b 7.3.0 64b9b9ec0a9b35ec3fdbc844673f1ec11525450b Switched to a new branch '7.3.0' mega@leafbuilder:~/leaf/devel/packages$ ls 3_1 4_0 5_1 5_2 latest stable tools Something is fishy here, it feels like the changes by release-to-git are not pushed to origin. cheers ET -- „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ ―Friedrich Nietzsche |
From: KP.Kirchdoerfer <ka...@be...> - 2024-04-17 14:14:00
|
Am Dienstag, 16. April 2024, 12:52:07 CEST schrieb Erich Titl: > Hi Folks > > Today I tried to update my package repository to the latest release. It > appears that the package git repository does not get updated anymore. I > can still checkout a branch 7.1.3 but even master does not hold any > packages anymore. > > mega@leafbuilder:~/leaf/devel/packages$ git branch > 7.0.0 > 7.0.2 > 7.0.3 > * 7.1.2 > master > mega@leafbuilder:~/leaf/devel/packages$ ls > armv8a bcmrpi cortex72 geode i486 i686 version wrap x86_64 > > mega@leafbuilder:~/leaf/devel/packages$ git checkout master > Updating files: 100% (5911/5911), done. > Switched to branch 'master' > Your branch is up to date with 'origin/master'. > mega@leafbuilder:~/leaf/devel/packages$ git branch > 7.0.0 > 7.0.2 > 7.0.3 > 7.1.2 > * master > mega@leafbuilder:~/leaf/devel/packages$ ls > 3_1 4_0 5_1 5_2 latest stable tools > > Ideas? I see packages (today), may be a hickup on SF yestareday; can you pls try again? kp |
From: Erich T. <eri...@th...> - 2024-04-16 11:22:57
|
Hi Folks Today I tried to update my package repository to the latest release. It appears that the package git repository does not get updated anymore. I can still checkout a branch 7.1.3 but even master does not hold any packages anymore. mega@leafbuilder:~/leaf/devel/packages$ git branch 7.0.0 7.0.2 7.0.3 * 7.1.2 master mega@leafbuilder:~/leaf/devel/packages$ ls armv8a bcmrpi cortex72 geode i486 i686 version wrap x86_64 mega@leafbuilder:~/leaf/devel/packages$ git checkout master Updating files: 100% (5911/5911), done. Switched to branch 'master' Your branch is up to date with 'origin/master'. mega@leafbuilder:~/leaf/devel/packages$ git branch 7.0.0 7.0.2 7.0.3 7.1.2 * master mega@leafbuilder:~/leaf/devel/packages$ ls 3_1 4_0 5_1 5_2 latest stable tools Ideas? cheers ET -- „Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“ ―Friedrich Nietzsche |
From: KP.Kirchdoerfer <ka...@be...> - 2023-05-20 16:32:31
|
Hi all; I've started to get a working pkgconf within our environment using personalities to make building packages easier. It seems to look quite promising: This shows the "personality" poiting to staging/toolchain tools/usr/bin/pkgconf --personality=tools/usr/share/pkgconf/i486-unknown- linux-uclibc.personality --dump-personality Triplet: i486-unknown-linux-uclibc SysrootDir: /leaf/master/staging/i486-unknown-linux-uclibc DefaultSearchPaths: /leaf/master/staging/i486-unknown-linux-uclibc/usr/lib/ pkgconfig /leaf/master/staging/i486-unknown-linux-uclibc/usr/share/pkgconfig SystemIncludePaths: /leaf/master/staging/i486-unknown-linux-uclibc/usr/include SystemLibraryPaths: /leaf/master/staging/i486-unknown-linux-uclibc/usr/lib this shows the availabnle pkgconf files in toolchain tools/usr/bin/pkgconf --personality=tools/usr/share/pkgconf/i486-unknown- linux-uclibc.personality --list-all libcrypto OpenSSL-libcrypto - OpenSSL cryptography library lzo2 lzo2 - LZO - a real-time data compression library openssl OpenSSL - Secure Sockets Layer and cryptography libraries and tools libssl OpenSSL-libssl - Secure Sockets Layer and cryptography libraries Bt before I can start testing if this works I've need to know how to call pkgconf with path and option (--personality=tools/usr/share/pkgconf/i486- unknown-linux-uclibc.personality) within buildtool - preferrably as env variable in make/toolchain/* Any ideas how to accomplish this?? TIA kp |
From: KP.Kirchdoerfer <ka...@be...> - 2022-03-13 14:02:33
|
Hi; Am Sonntag, 13. März 2022, 13:41:02 CET schrieb lt...@ce...: > Hello, > > we would like to see VPP (based on DPDK) available as package in Leaf > Bearing. This would be really attractive alternative way, how to provide > high performance packet processing alternative to build-in Linux kernel > routing and bridging. To help we are offering to sponsor this task - > porting of VPP and DPDK to Leaf uClibc buildtool. If you are interested > please send me PM so we can discuss details. Thank you. > > Kind regards > Litin I did some research - are you referring to https://www.dpdk.org/ for dpdk and https://fd.io for VPP or anything else? kp |
From: <lt...@ce...> - 2022-03-13 12:41:22
|
Hello, we would like to see VPP (based on DPDK) available as package in Leaf Bearing. This would be really attractive alternative way, how to provide high performance packet processing alternative to build-in Linux kernel routing and bridging. To help we are offering to sponsor this task - porting of VPP and DPDK to Leaf uClibc buildtool. If you are interested please send me PM so we can discuss details. Thank you. Kind regards Litin |
From: Erich T. <eri...@th...> - 2021-11-23 15:27:37
|
Hi KP Am 23.11.2021 um 15:58 schrieb KP.Kirchdoerfer: > Am Montag, 22. November 2021, 21:26:48 CET schrieb Erich Titl: >> Hi KP >> ... >> /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty/etc >> /default > ( cd rtty-7.4.2; cmake . >> -DCMAKE_C_COMPILER=i486-unknown-linux-uclibc-gcc >> -DCMAKE_INSTALL_PREFIX=/usr >> -DCMAKE_FIND_ROOT_PATH=/home/mega/leaf/devel/bering-uclibc/build/i486-unknow >> n-linux-uclibc/rtty > ) >> CMake Error at >> /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 ...>> > > Looks like you haven't build libev before...? mega@leafbuilder:~/leaf/devel/bering-uclibc$ grep libev conf/i486-unknown-linux-uclibc/installed source libevent source libev build libevent build libev > > My log looks different: > > ( cd rtty-7.4.2; cmake . -DCMAKE_C_COMPILER=i486-unknown-linux-uclibc-gcc - > DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_FIND_ROOT_PATH=/leaf/master/build/i486- > unknown-linux-uclibc/rtty ) Except for the root path the command looks identical but it fails right here. > -- The C compiler identification is GNU 9.4.0 > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done ...> > kp So something is missing but what? The log from the Ubuntu upgrade looks OK to me. cheers ET |
From: KP.Kirchdoerfer <ka...@be...> - 2021-11-23 14:58:18
|
Am Montag, 22. November 2021, 21:26:48 CET schrieb Erich Titl: > Hi KP > > Am 22.11.2021 um 19:38 schrieb Erich Titl: > > > Hi KP > > > > ....> > > >> > >> > >> For rtty you may need libevdev2 on the host. > >> > >> > > > Reading package lists... Done > Building dependency tree > Reading state information... Done > libevdev2 is already the newest version (1.9.0+dfsg-1ubuntu0.1). > > mega@leafbuilder:~/leaf/devel/bering-uclibc$ sudo apt-get install > libevdev-dev > Reading package lists... Done > Building dependency tree > Reading state information... Done > Suggested packages: > libevdev-doc > The following NEW packages will be installed: > libevdev-dev > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 48.7 kB of archives. > After this operation, 287 kB of additional disk space will be used. > Get:1 http://ch.archive.ubuntu.com/ubuntu focal-updates/main amd64 > libevdev-dev amd64 1.9.0+dfsg-1ubuntu0.1 [48.7 kB] > Fetched 48.7 kB in 1s (59.2 kB/s) > Selecting previously unselected package libevdev-dev:amd64. > (Reading database ... 148548 files and directories currently installed.) > Preparing to unpack .../libevdev-dev_1.9.0+dfsg-1ubuntu0.1_amd64.deb ... > Unpacking libevdev-dev:amd64 (1.9.0+dfsg-1ubuntu0.1) ... > Setting up libevdev-dev:amd64 (1.9.0+dfsg-1ubuntu0.1) ... > Processing triggers for man-db (2.9.1-1) ... > > > mega@leafbuilder:~/leaf/devel/bering-uclibc$ ./buildtool.pl build rtty > make the list of required source packages: nothing to do [0.K.] > make the list of required build packages: rtty [0.K.] > > build source/package: rtty > ------------------------ > calling 'make build' for rtty make build failed for > /home/mega/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc/rtty/bu > ildtool.mk , please have a look at the logfile > /home/mega/leaf/devel/bering-uclibc/log/buildtoollog at > /home/mega/leaf/devel/bering-uclibc/buildtool/Make.pm line 424. > > make: Entering directory > '/home/mega/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc/rtty' > mkdir -p > /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty > mkdir -p > /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty/etc > /init.d mkdir -p > /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty/etc > /default ( cd rtty-7.4.2; cmake . > -DCMAKE_C_COMPILER=i486-unknown-linux-uclibc-gcc > -DCMAKE_INSTALL_PREFIX=/usr > -DCMAKE_FIND_ROOT_PATH=/home/mega/leaf/devel/bering-uclibc/build/i486-unknow > n-linux-uclibc/rtty ) > CMake Error at > /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 > (message): > Could NOT find Libev (missing: LIBEV_LIBRARY LIBEV_INCLUDE_DIR) > Call Stack (most recent call first): > /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 > (_FPHSA_FAILURE_MESSAGE) > cmake/Modules/FindLibev.cmake:25 (find_package_handle_standard_args) > src/CMakeLists.txt:7 (find_package) > Looks like you haven't build libev before...? My log looks different: ( cd rtty-7.4.2; cmake . -DCMAKE_C_COMPILER=i486-unknown-linux-uclibc-gcc - DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_FIND_ROOT_PATH=/leaf/master/build/i486- unknown-linux-uclibc/rtty ) -- The C compiler identification is GNU 9.4.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /leaf/master/toolchain/i486-unknown-linux- uclibc/bin/i486-unknown-linux-uclibc-gcc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Found Libev: /leaf/master/staging/i486-unknown-linux-uclibc/usr/lib/ libev.so (found version "4.33") -- Found OpenSSL: /leaf/master/staging/i486-unknown-linux-uclibc/usr/lib/ libcrypto.so (found version "1.1.1l") -- Could NOT find WolfSSL (missing: WOLFSSL_LIBRARY WOLFSSL_INCLUDE_DIR) -- Could NOT find MbedTLS (missing: MBEDTLS_LIBRARY MBEDX509_LIBRARY MBEDCRYPTO_LIBRARY MBEDTLS_INCLUDE_DIR) -- Found ZLIB: /leaf/master/staging/i486-unknown-linux-uclibc/usr/lib/libz.so (found version "1.2.11") -- Select OpenSSL as the SSL backend -- Configuring done -- Generating done -- Build files have been written to: /leaf/master/source/i486-unknown-linux- uclibc/rtty/rtty-7.4.2 make -j17 -C rtty-7.4.2 kp > > cheers > > ET |