| Message ID | cover.1730976866.git.jstancek@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tools: ynl: two patches to ease building with rpmbuild | expand |
On Mon, 11 Nov 2024 14:04:43 +0100 Jan Stancek wrote: > I'm looking to build and package ynl for Fedora and Centos Stream users. Great to hear! > Default rpmbuild has couple hardening options enabled by default [1][2], > which currently prevent ynl from building. Could you rebase on: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/ and resend? I see some fuzz: Applying: tools: ynl: add script dir to sys.path Using index info to reconstruct a base tree... M tools/net/ynl/cli.py M tools/net/ynl/ynl-gen-c.py Falling back to patching base and 3-way merge... Auto-merging tools/net/ynl/ynl-gen-c.py Auto-merging tools/net/ynl/cli.py Applying: tools: ynl: extend CFLAGS to keep options from environment With that fixed feel free to add to the patches: Acked-by: Jakub Kicinski <kuba@kernel.org> One thing I keep thinking about, maybe you already read this, is to add some sort of spec search path and install the specs under /usr. So the user can simply say --family X on the CLI without specifying the fs full path to the YAML file. Would you be willing to send a patch for this?
On Tue, Nov 12, 2024 at 12:52 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Mon, 11 Nov 2024 14:04:43 +0100 Jan Stancek wrote: > > I'm looking to build and package ynl for Fedora and Centos Stream users. > > Great to hear! > > > Default rpmbuild has couple hardening options enabled by default [1][2], > > which currently prevent ynl from building. > > Could you rebase on: > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/ > and resend? I see some fuzz: > > Applying: tools: ynl: add script dir to sys.path > Using index info to reconstruct a base tree... > M tools/net/ynl/cli.py > M tools/net/ynl/ynl-gen-c.py > Falling back to patching base and 3-way merge... > Auto-merging tools/net/ynl/ynl-gen-c.py > Auto-merging tools/net/ynl/cli.py > Applying: tools: ynl: extend CFLAGS to keep options from environment > > > With that fixed feel free to add to the patches: > > Acked-by: Jakub Kicinski <kuba@kernel.org> Will do. > > > One thing I keep thinking about, maybe you already read this, is to > add some sort of spec search path and install the specs under /usr. > So the user can simply say --family X on the CLI without specifying > the fs full path to the YAML file. Would you be willing to send a patch > for this? I can look at adding--family option (atm. for running ynl in-tree). One thing I wasn't sure about (due to lacking install target) was whether you intend to run ynl always from linux tree. If you're open to adding 'install' target, I think that should be something to look at as well. It would make packaging less fragile, as I'm currently handling all that on spec side. Thanks, Jan
Jan Stancek <jstancek@redhat.com> writes: > On Tue, Nov 12, 2024 at 12:52 AM Jakub Kicinski <kuba@kernel.org> wrote: >> >> One thing I keep thinking about, maybe you already read this, is to >> add some sort of spec search path and install the specs under /usr. >> So the user can simply say --family X on the CLI without specifying >> the fs full path to the YAML file. Would you be willing to send a patch >> for this? > > I can look at adding--family option (atm. for running ynl in-tree). > > One thing I wasn't sure about (due to lacking install target) was whether > you intend to run ynl always from linux tree. > > If you're open to adding 'install' target, I think that should be something > to look at as well. It would make packaging less fragile, as I'm currently > handling all that on spec side. Hi Jan, I am happy to work with you on adding an install target, plus some other UX improvements like --family. Thanks, Donald.
On Tue, 12 Nov 2024 09:16:07 +0100 Jan Stancek wrote: > One thing I wasn't sure about (due to lacking install target) was whether > you intend to run ynl always from linux tree. > > If you're open to adding 'install' target, I think that should be something > to look at as well. It would make packaging less fragile, as I'm currently > handling all that on spec side. Yes, definitely open to adding an install target. Assume that whatever is missing or done strangely from packaging perspective is due to incompetence rather than intentional design :)