leaf-devel — This is a discussion list for development topics.

[leaf-devel] updating to gcc 13

[KP.Kirchdoerfer <ka...@be...>]

Hi all;

with latest upgrade on my development machine gcc 9 was gone once and forever.
Avoiding to work on a VM, I've decided it's time to move on to a more recent 
gcc - that means: GCC 13.

I've worked on this task in a private branch for some time, so things almost 
went well, when updating the gcc in our toolchain.
A few packages needed patches, some old without maintenance for years that 
don't build any longer will be removed - see below.

The one and only package I'm not fine with is siproxd. Though I tried alot, I'm 
not there yet.

Why not gcc 14 you may ask.
It seems our outdated module-init-tools in toolchain won't build, I guess this 
could be  solved by replacing them with kmod.

The Packages removed are openrrcp, havp, afspfs and libcdada.

I'll commit the changes to git master.

Opinions,  questions and ideas are welcome.

regards kp

[leaf-devel] Dual BIOS/EFI boot install script

[Lars K. <lar...@gm...>]

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

[leaf-devel] Fwd: Re: Storage issue for project: leaf

[Erich T. <eri...@th...>]

Re: [leaf-devel] EFI support

[Lars K. <lar...@gm...>]

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
>

Re: [leaf-devel] EFI support

[KP.Kirchdoerfer <ka...@be...>]

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] EFI support

[Lars K. <lar...@gm...>]

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

Re: [leaf-devel] Mailing list leaf-devel

[Mike N. <mh...@gm...>]

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

Re: [leaf-devel] Mailing list leaf-devel

[Mike N. <mh...@gm...>]

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

Re: [leaf-devel] Mailing list leaf-devel

[Mike N. <mh...@gm...>]

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

Re: [leaf-devel] Mailing list leaf-devel

[Erich T. <eri...@th...>]

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

Re: [leaf-devel] Mailing list leaf-devel

[Mike N. <mh...@gm...>]

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

Re: [leaf-devel] Mailing list leaf-devel

[Tom E. <te...@sh...>]

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
                       \________________________________________

[leaf-devel] Open Source Security

[Mike N. <mh...@gm...>]

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

Re: [leaf-devel] Mailing list leaf-devel

[Boris <bo...@ca...>]

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

[leaf-devel] Mailing list leaf-devel

[Erich T. <eri...@th...>]

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

Re: [leaf-devel] Packages repository (solved)

[Boris <bo...@ca...>]

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

[leaf-devel] Packages repository (solved)

[Erich T. <eri...@th...>]

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

[leaf-devel] Just a test

[Erich T. <eri...@th...>]

Test, please disregard.

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

[leaf-devel] Packages repository

[Erich T. <eri...@th...>]

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

Re: [leaf-devel] Packages repository

[KP.Kirchdoerfer <ka...@be...>]

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

[leaf-devel] Packages repository

[Erich T. <eri...@th...>]

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

[leaf-devel] pkgconf

[KP.Kirchdoerfer <ka...@be...>]

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

Re: [leaf-devel] Vector Packet Processing (VPP) in Leaf Bearing

[KP.Kirchdoerfer <ka...@be...>]

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

[leaf-devel] Vector Packet Processing (VPP) in Leaf Bearing

[<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

Re: [leaf-devel] crashing package list

[Erich T. <eri...@th...>]

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