Re: [depot_autoremove] Removing outdated PGKs from the depot

[Martin Stein]

Hi Alice,

I discovered Norman's mail right after sending my response :)
But yes, I'd also say that our ideas are compatible. Your plans sound
very reasonable to me and I appreciate that you're willing to get your
hands on it! Don't hesitate to ask if you run into uncertainties!

Cheers,
Martin

On 10.03.23 17:44, Alice Domage wrote:
> Dear Martin,
> 
> Thank you for sharing your thought!
> 
> If I understand correctly, your thoughts are aligned with Norman's
> suggestions.
> 
> So this would be a standalone component. It can be started manually for
> performing specific
> depot clean-up tasks. Eventually, a higher-level management component
> could also use it.
> 
> Cheers,
> Alice
> 
> On 3/10/23 10:25, Martin Stein wrote:
>> Hi Alice,
>>
>> AFAIK, this doesn't exist so far. I personally would really appreciate
>> to have such a tool at hand but don't have the time to dive into it
>> currently. However, I suspect that this kind of tool is part of a
>> complete new abstraction layer (software management) on top of the
>> current rather manual/low-level depot management (and not a mere
>> addition to the latter) because I see other tasks connected to it like
>> detecting and applying updates of packages in the "installed list" and
>> managing the "installed list".
>>
>> Cheers,
>> Martin
>>
>> ___
>> Genode users mailing list
>> users@lists.genode.org
>> https://lists.genode.org/listinfo/users
> 
> 
> ___
> Genode users mailing list
> users@lists.genode.org
> https://lists.genode.org/listinfo/users

___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: iwlwifi-9260-firmware

[Josef Söntgen]

Hi Alice,

> After some investigations, only the intel 'iwlwifi-9260-firmware'
> needs to be included for it to work. I forked 'dde_linux_firmware' [1]
> and created a pull request [2] to add the firmware and the license.
> Please let me know if this is appropriate.

Thanks for creating the PR.

I was wondering where you got the image file from as the size differs
from the one found in the vanilla 'linux-firmware.git' [1] repository
that I normally turn to. However, I added the image found there to the
'dde_linux_firmware' report and I prepared two fixup commits [2]. It
would be nice if you could give this FW image a try as well.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
[2] 
https://github.com/cnuke/genode/commits/issue%23xxx-iwlwifi-9260-razor15-2023-03-13

> Finally, I have a branch that implements the necessary changes on
> the genode repository [3]. It currently uses my fork of 'dde_linux_firmware'
> in 'dde_linux/ports/linux-firmware.port'. Wifi now works on my laptop.
> 
> If [2] is correct and accepted. I can adapt those changes if welcome to
> create a pull request for the genode repository.

I goes without saying that we gladly would incorporate the changes.


Regards
Josef

-- 
Josef Söntgen
Genode Labs

http://www.genode-labs.com/ · http://genode.org/


signature.asc
Description: PGP signature
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: Rockchip USB revisited

[Michael Grunditz]

> To cross-check, does the creation of the binary archive
> bin/arm_v8a/a64_usb_host_drv using the genode-allwinner repository work
> as it should?
>
Thanks for help! It builds ( but no cigar!).  I managed to put a
comment in a list , so everything failed :-)

___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: [depot_autoremove] Removing outdated PGKs from the depot

[Norman Feske]

Hi Alice,


The way I envision the implementation is as follows:

1. It creates a graph representing the depot state by traversing it. The 
graph is implemented with a dictionary.
Each node uses as a key a 'Depot::Archive::Path' and as a value a list 
of 'Depot::Archive::Path' that are dependencies neighbours.

Graph nodes can be of any archive type.

2. First, it goes through the packages. As you said, it registers 
dependencies. It also creates nodes for any dependencies
archive pointing to their referenced 'pkgs'. Thus, this creates loops in 
the graph between dependencies.


3. It iterates over its config and performs the required actions.

4. When a package is deleted, it traverses the neighbour dependencies 
list. Colours them for deletion, and remove the package reference.
If a node has an empty list of neighbours, it can be deleted safely, as 
it isn't in use any more.


Maybe it is beneficial to break down the problem even further. In fact, 
depot archive types do not arbitrary depend on one another. 
Specifically, binary archives cannot depend on each other. Also raw 
archives have no dependencies. Src archives can only depend on api 
archives but not on other src archives. Also api archives cannot have 
dependencies. For this current discussion, I'd leave out src and api 
archives anyway.


The only case where a dependency tree of multiple levels is formed are 
pkg archives depending on other pkg archives. With this observation, I 
would only look at pkg archives at first. Scanning the depot for the 
list of pkg archives should be quick enough. For each pkg, I would ask: 
"should this pkg be removed?". The answer is given by the . To 
implement this step, there is no need to build an internal data structure.


Then, after having removed pkg archives, I'd read the content of all 
remaining 'archives' files present in the depot, putting each line into 
a dictionary (removing duplicates that way). Now we know all archives 
that are still required.


With this list (dictionary) gathered, we can again go through the depot. 
For each bin or raw archive, we'd look whether it is featured in our 
list or not. If not, we can remove the sub directory. For each pkg 
archive, we look if it is either featured in our list or if it is tagged 
as manually installed by the user. If neither is the case, we can remove 
it as well, and remember that we should do another iteration of garbage 
collection (now with the pkg removed, further removals may become possible).


By breaking the problem down this way, there is no need to build a graph 
as internal data structure.


Transitive dependencies are handled by iterating the whole process as 
long as progress happens.


When a package depends on another package, it will be coloured for 
deletion as any other dependency.


But what if a pkg was manually installed by the user (lets say 
"blue_backdrop") and also happens to be a dependency of another 
dependent pkg (like "blue_backdrop_with_logo") installed separately?


In this case, I would expect to keep the "blue_backdrop" when 
uninstalling only the dependent pkg "blue_backdrop_with_logo". If the 
"blue_backdrop" had been installed as a mere side effect of installing 
"blue_backdrop_with_logo", I would expect to have it automatically 
removed along with "blue_backdrop_with_logo".


To take this decision, I think we have to preserve the information of 
how each pkg entered the depot. Hence, my suggestion to explicitly mark 
the pkg archives that entered the depot by user intent.


This way, I believe there is no need for persistent annotation of 'pkg' 
dependencies by the 'depot_download_manager'. I am concerned by the 
performance of such an algorithm and would have to finish a first 
implementation for certainty. As the dictionary is implemented with an 
AVL, it should perform in a reasonable time.


I would not be too concerned about performance at this point. The most 
costly step (apart from the deletion of files) is probably the gathering 
of the content of all 'archives' files found in the depot. To get a 
feeling of what to expect, you may issue the following command in your 
genode directory (with the depot you are currently working with):


  genode$ cat depot/*/pkg/*/*/archives

Cheers
Norman


--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: Rockchip USB revisited

[Norman Feske]

Hi Michael,


Yes I got that..If I do build the linux kernel it works. The problem
is that when it tries to use source tree from "depot" iit isn't
configured. I haven't refactored the sources yet (everything is named
a64)  and this is the output I get:


checking library dependencies...
  Library a64_linux
MERGEa64_linux.lib.a
  Library a64_linux_generated
MERGEa64_linux_generated.lib.a
CONFIG   Linux
  [Linux]  
/home/micken/oldhome/micken/src/new/genode/depot/genodelabs/api/a64_linux/2023-03-13/src/linux/
Makefile:621: arch/arm64/Makefile: No such file or directory
  [Linux]  make[9]: *** No rule to make target 'arch/arm64/Makefile'.  Stop.
  [Linux]  make[8]: *** [Makefile:185: __sub-make] Error 2


the content of the depot api archive is unconfigured. The configuration 
happens at build time of each driver that uses the API (so once for each 
binary archive). It may be helpful to peek into the build directory when 
building a depot binary by passing the argument KEEP_BUILD_DIR=1 to the 
tool/depot/create tool.


Since your error message complains about a missing Makefile, I suspect 
that something with the packaging of your a64_linux api archive went 
wrong. When looking at the a64_1inux api archive in my depot, I'm seeing 
a file at src/linux/arch/arm64/Makefile. Does it exist in your case? 
Have you re-used the depot recipe of for api/a64_linux [1] as is?


[1] 
https://github.com/genodelabs/genode-allwinner/blob/master/recipes/api/a64_linux/content.mk


To cross-check, does the creation of the binary archive 
bin/arm_v8a/a64_usb_host_drv using the genode-allwinner repository work 
as it should?


Cheers
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: Rockchip USB revisited

[Michael Grunditz]

> In the genode-allwinner repository, the Linux kernel's config step
> happens via the 'a64_linux_generated' pseudo library [1].
>
> [1]
> https://github.com/genodelabs/genode-allwinner/blob/master/lib/mk/spec/arm_v8/a64_linux_generated.mk
>
> If a target has 'a64_lx_emul' added to the 'LIBS' variable, the
> corresponding import file implicitly adds the 'a64_linux_generated'
> library [2].

Yes I got that..If I do build the linux kernel it works. The problem
is that when it tries to use source tree from "depot" iit isn't
configured. I haven't refactored the sources yet (everything is named
a64)  and this is the output I get:


checking library dependencies...
 Library a64_linux
   MERGEa64_linux.lib.a
 Library a64_linux_generated
   MERGEa64_linux_generated.lib.a
   CONFIG   Linux
 [Linux]  
/home/micken/oldhome/micken/src/new/genode/depot/genodelabs/api/a64_linux/2023-03-13/src/linux/
Makefile:621: arch/arm64/Makefile: No such file or directory
 [Linux]  make[9]: *** No rule to make target 'arch/arm64/Makefile'.  Stop.
 [Linux]  make[8]: *** [Makefile:185: __sub-make] Error 2

___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: Rockchip USB revisited

[Norman Feske]

Hi Michael,

On 2023-03-13 15:47, Michael Grunditz wrote:

I am trying to bring up EHCI using the A64 driver. I configiured build
system to download a tar ball with linux kernel. However in the:
"CONFIG Linux" step  I get this:

Makefile:621: arch/arm64/Makefile: No such file or directory

Which is natural since the source tree in depot isn't configured.


So the first questions is; when is the tree configured?
In the genode-allwinner repository, the Linux kernel's config step 
happens via the 'a64_linux_generated' pseudo library [1].


[1] 
https://github.com/genodelabs/genode-allwinner/blob/master/lib/mk/spec/arm_v8/a64_linux_generated.mk


If a target has 'a64_lx_emul' added to the 'LIBS' variable, the 
corresponding import file implicitly adds the 'a64_linux_generated' 
library [2].


[2] 
https://github.com/genodelabs/genode-allwinner/blob/master/lib/import/import-a64_lx_emul.mk


So it should be enough to add the following line to a target.mk file:

  LIBS += base a64_lx_emul

When processed by the Genode build system, the 'a64_linux_generated' 
library leaves a readily configured Linux build directory at 
/var/libcache/a64_linux_generated/.


Cheers
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Rockchip USB revisited

[Michael Grunditz]

Hi

I am trying to bring up EHCI using the A64 driver. I configiured build
system to download a tar ball with linux kernel. However in the:
"CONFIG Linux" step  I get this:

Makefile:621: arch/arm64/Makefile: No such file or directory

Which is natural since the source tree in depot isn't configured.


So the first questions is; when is the tree configured?

Michael

___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: PinePhone First Impressions & Questions

[Norman Feske]

Hi John,

I am itching to try the various presets, and was wondering if any of the 
following ideas would be feasible:


- Providing an on-disk depot for the presets.  (Excluding the web 
browser, which would be useless without connectivity anyway, seems like 
it would keep the size down.)


since you are building Sculpt images manually, you can craft an 
offline-usable image with the following tweaks.


- Slim down Sculpt in 'allwinner/sculpt/phone-pinephone.sculpt'.
  For a start, I would leave out all presets except for nano3d (for
  testing) and also remove the launchers.

- Add the following line to 'phone-pinephone.sculpt':

  ram_fs: depot

  This tells Sculpt's RAM file system to mount a tar archive as a pre-
  populated depot when started (it selects the config snippet at [1]).

- Build sculpt with 'DEPOT=tar' instead of 'DEPOT=omit'. This will
  integrate all depot content in the form of a tar file into the image.
  At runtime, this tar archive can then get picked up by the RAM file
  system.

After booting the fresh baked scenario (using fastboot [2] is much 
recommended), select the "ram fs" component in the runtime graph and 
activate "Use". This way, Sculpt will use the RAM file system as Sculpt 
partition and thereby use the pre-populated depot. Now, you should be 
able to activate the nano3d preset.


[1] 
https://github.com/genodelabs/genode/blob/master/repos/gems/sculpt/ram_fs/depot

[2] https://genodians.org/nfeske/2021-09-20-pine-fun-pinephone-boot

That's my usual work flow during Sculpt-image integration work. It does 
not touch the SD-card at all, which is very convenient for iterating 
quickly and crafting presents one by one.


It would be very cool if you get it to work because it opens up a lot of 
opportunities for experimentation.


Cheers
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: PinePhone Sculpt Build Problems

[Norman Feske]

Hi John,

thank you for reporting.

The sculpt_image.run script is intended for the automation of image 
releases. It is useful only if your are planning make your custom built 
image publicly available for others. For mere experimenting and testing, 
the sculpt_test.run script is probably easier to use.



/home/mainuser/Devel/genode_main/genode/repos/gems/run/sculpt_image.run
can't read "arg": no such variable
     while executing
"puts stderr "missing run-tool argument: $arg""
     (procedure "assert_run_arg" line 4)
     invoked from within
"assert_run_arg "--image-uboot-gzip-best""
     (file 
"/home/mainuser/Devel/genode_main/genode/repos/gems/run/sculpt_image.run" line 34)

...

This is too cryptic for me, as I am anything but a build system expert.


That's a slip-up on my side. I just fixed it on staging [1].

[1] 
https://github.com/genodelabs/genode/commit/c376660a097b2194182175e91f6343d130f1cb3d


The following steps may be unnecessary, but I was just trying things 
that seemed reasonable.  Running "prepare_port pine_uboot" worked fine, 
but "make u-boot/pine BOARD=pinephone" says:


checking library dependencies...
   Program u-boot/pine/pine_uboot
/bin/sh: 0: Illegal option -o pipefail
/bin/sh: 0: Illegal option -o pipefail
/bin/sh: 0: Illegal option -o pipefail
make[3]: *** [Makefile:556: 
/home/mainuser/Devel/genode_main/genode/build/arm_v8a/u-boot/pine/arm_trusted_firmware/sun50i_a64/debug] Error 2
make[2]: *** 
[/home/mainuser/Devel/genode_main/genode/repos/allwinner/src/u-boot/pine/target.mk:35: /home/mainuser/Devel/genode_main/genode/build/arm_v8a/u-boot/pine/arm_trusted_firmware/sun50i_a64/debug/bl31.bin] Error 2

make[1]: *** [var/libdeps:23: pine_uboot.prg] Error 2
make: *** [Makefile:336: gen_deps_and_build_targets] Error 2

I probably made a configuration mistake or forgot a step (or multiple).


It seems like the shell (implicitly) used by the build system of the ARM 
trusted firmware (ATF), does not know the '-o pipefail' argument that 
Genode's build systems sets by default [2] for safety reasons.


What puzzles me is that we explicitly "unexport" the '.SHELLFLAGS' in in 
the u-boot/pine/target.mk [3]. For some reason, the argument still ends 
up in the sub make for the ATF.


As an immediate work-around, you might remove the '-o pinefail' from 
Genode's build.mk file.


[2] 
https://github.com/genodelabs/genode/blob/master/tool/builddir/build.mk#L95
[3] 
https://github.com/genodelabs/genode-allwinner/blob/master/src/u-boot/pine/target.mk#L29



Cheers
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: sys/common_ansi.h not found (dde rump)- sculpt for virt qemu riscv

[Sebastian Sumpf]

Hello Pranab,

On 3/13/23 07:47, Pranab Kumar Rout cs21m045 wrote:

Hello genodians,
While building sculpt for virt_qemu_riscv, I found that dde_rump port is not 
prepared for RISCV. Taking help from the community, I used the same approach as 
for arm_v8a (aarch64) as found under "repos/dde_rump/lib/mk/spec/arm_64/*" just 
for "spec/riscv" in order to enable rump support for RISC-V.

I am getting this error. If you find it familiar, kindly help me
checking library dependencies...
   Library ldso_so_support
     COMPILE  so_support.o
     MERGE    ldso_so_support.lib.a
   Library ld
     CONVERT  ld.symbols.s
     ASSEMBLE ld.symbols.o
     MERGE ld.abi.so 
   Library base
     MERGE    base.lib.a
   Library block_session
     MERGE    block_session.lib.a
   Library config
     MERGE    config.lib.a
   Library file_system
     MERGE    file_system.lib.a
   Library file_system_session
     MERGE    file_system_session.lib.a
   Library os
     MERGE    os.lib.a
   Library rump_include
     MERGE    rump_include.lib.a
   Library rump
     COMPILE  __main.o
In file included from 
/genode/depot/genodelabs/src/rump/2023-03-07-b/src/lib/dde_rump/src/sys/sys/types.h:47,
                  from 
/genode/depot/genodelabs/src/rump/2023-03-07-b/src/lib/dde_rump/src/sys/lib/libkern/__main.c:33:

/genode/depot/genodelabs/bin/riscv/rump/2023-03-07-b.build/var/libcache/rump/include/machine/ansi.h:3:10:
 fatal error: sys/common_ansi.h: No such file or directory
     3 | #include 
       |  ^~~


When looking at "contrib/dde_rump-/src/lib/dde_rump_aarch64_backport" I 
can see that only "src/sys/arch" [1] is checked out from [2] while 
"common_ansi.h" resides under "src/sys/sys/common_ansi.h" [3]. Therefore, you 
could adjust [1] to also checkout "src/sys" or "src/sys/sys" and update the 
"INC_DIR" and/or symlinks under "dde_rump/lib/mk/spec/riscv" accordingly.


[1] repos/dde_rump/ports/dde_rump.port
[2] https://github.com/justincormack/netbsd-src
[3] 
https://github.com/justincormack/netbsd-src/blob/master/src/sys/sys/common_ansi.h


*Note: When adjusting "dde_rump.port" you need to execute

! ./tool/ports/update_hash dde_rump

in order to create a new hash for the port.

Regards,

Sebastian

--
Sebastian Sumpf
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth





___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

Re: First system image of Sculpt OS for the PinePhone

[Norman Feske]

Hi Pirmin,

thank you for testing the PinePhone image.

After some more testing I was able to turn on and off the modem multiple 
times. So I'm not sure, why this  wasn't working on my first try.


Unfortunately I still wasn't able to do calls.


The modem_pinephone.run script at the Allwinner repository [1] might be 
helpful to solve this mystery. It allows you to interactively talk to 
the modem using AT commands. You can find the commands for placing and 
receiving calls documented at the beginning of the run script. More 
detailed information is available at [2] in Section "LTE module 
information".


I wonder, are you able to unlock your SIM and issue/receive voice calls 
using this manual procedure? If yes, I would very much appreciate a log 
of the AT commands that work for you. So we can extend the AT-protocol 
driver [3] accordingly.


[1] 
https://github.com/genodelabs/genode-allwinner/blob/master/run/modem_pinephone.run
[2] 
https://wiki.pine64.org/index.php/PinePhone#Datasheets_for_components_and_peripherals
[3] 
https://github.com/genodelabs/genode-allwinner/tree/master/src/drivers/modem


Cheers
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth


___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users

sys/common_ansi.h not found (dde rump)- sculpt for virt qemu riscv

[Pranab Kumar Rout cs21m045]

Hello genodians,
While building sculpt for virt_qemu_riscv, I found that dde_rump port is
not prepared for RISCV. Taking help from the community, I used the same
approach as for arm_v8a (aarch64) as found under
"repos/dde_rump/lib/mk/spec/arm_64/*" just for "spec/riscv" in order to
enable rump support for RISC-V.
I am getting this error. If you find it familiar, kindly help me
checking library dependencies...
  Library ldso_so_support
COMPILE  so_support.o
MERGEldso_so_support.lib.a
  Library ld
CONVERT  ld.symbols.s
ASSEMBLE ld.symbols.o
MERGEld.abi.so
  Library base
MERGEbase.lib.a
  Library block_session
MERGEblock_session.lib.a
  Library config
MERGEconfig.lib.a
  Library file_system
MERGEfile_system.lib.a
  Library file_system_session
MERGEfile_system_session.lib.a
  Library os
MERGEos.lib.a
  Library rump_include
MERGErump_include.lib.a
  Library rump
COMPILE  __main.o
In file included from
/genode/depot/genodelabs/src/rump/2023-03-07-b/src/lib/dde_rump/src/sys/sys/types.h:47,
 from
/genode/depot/genodelabs/src/rump/2023-03-07-b/src/lib/dde_rump/src/sys/lib/libkern/__main.c:33:
/genode/depot/genodelabs/bin/riscv/rump/2023-03-07-b.build/var/libcache/rump/include/machine/ansi.h:3:10:
fatal error: sys/common_ansi.h: No such file or directory
3 | #include 
  |  ^~~
compilation terminated.
make[7]: *** [/genode/repos/base/mk/generic.mk:58: __main.o] Error 1
make[6]: *** [var/libdeps:184: rump.lib] Error 2
make[5]: *** [Makefile:336: gen_deps_and_build_targets] Error 2
make[4]: *** [/genode/tool/depot/mk/build_bin_archive:208:
/genode/depot/genodelabs/bin/riscv/rump/2023-03-07-b.build/bin] Error 1
make[3]: *** [/genode/depot/var/build.mk:264:
genodelabs/bin/riscv/rump/2023-03-07-b] Error 2
make[2]: *** [/genode/tool/depot/build:136:
execute_generated_build_mk_file] Error 2
make[1]: *** [/genode/tool/depot/create:59: build] Error 2
make[1]: Leaving directory '/genode/build/riscv'

I looked into a lot of files and configurations but couldn't understand
what am I missing. Kindly help me fix it.

Thanks & Regards,
Pranab
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users