going
-
Posts
508 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Event Comments posted by going
-
-
3 часа назад, Igor сказал:
Probably OBS is best maintained, but overkill and complicated ?
The first problem is to make the source package and this must be done in the OS build environment.
When there is a properly working source package, and for debian these are several files, we can send them to any service for assembly. It does not matter in principle.
No one will do the manual work for us.I am talking about providing the user with tools to work on creating source packages and then assembling them in the native environment, i.e. in the OS in which the binary package will be installed.
We are talking about the process of developing a package from source texts, and not about which service to build it on.
11.04.2023 в 18:50, Igor сказал:keeping as a standalone functionality
this mechanism can exist completely independently, and can be invoked independently. The build system can use some parts of it for its tasks, but not vice versa.
Can we start discussing the algorithm?
I'm already doing something and I've done something. -
1 час назад, rpardini сказал:
Another good option is the OpenSUSE
Hi Ricardo. This is my favorite service.
Do you suggest making a package in it for Armbian? -
5 часов назад, Igor сказал:
something else
Before the mechanism is implemented and moves to the assembly system, it is necessary to ask a question, and who needs it and why.
If only to collect a small collection of packages for internal consumption by Armbian as the organization that distributes these packages, then this is one option. This option existed before.
If we plan to give the user the opportunity to build any package in a chroot environment or natively, then this is another goal. And it involves assembling several packages for internal consumption. But as part of a more general capability.5 часов назад, Igor сказал:Just its not used much
It was little used because it was hard coded to build multiple packages using configuration files. And it was always the same version of the package.
Igor, you know that I have redone it a little, and it is now in the master branch collecting packages in a clean environment every time.
Why is this the case? Because all the distributions I know do exactly that.
The build system, by its very nature, should provide some customization options and tools for the developer's work.If this is not the case, the developer will find an alternative or redo the algorithm of the build script.
5 часов назад, Igor сказал:keeping as a standalone functionality
There will always be poorly or not very well functioning packages that can be fixed.
And for this , there must be a mechanism for building in the chroot environment.I am developing it and it is becoming more functional.
-
The developers of Armbian abandoned the old mechanism, why?
What is the main reason?
It worked well and is working today for me.It will be very interesting for me to look at the new algorithm in a descriptive way before it is implemented programmatically.
-
-
[🌱] Downloading Kernel bundle [ stable; this might take a long time ] Initializing download: https://mirrors.edge.kernel.org/pub/scm/.bundles/pub/scm/linux/kernel/git/stable/linux/clone.bundle File size: 4.2958 Gigabyte(s) (4612578906 bytes)@rpardini We've already discussed this. And I see it again. Who should I bill for such a large traffic?
-
I promised that I would try to run a test build in the "armbian-next" branch.
The first run with my test config failed.[💥] Error occurred in main shell [ code 2 at /home/leo/armbian/lib/functions/configuration/main-config.sh:59 do_main_configuration() --> ./lib/functions/configuration/main-config.sh:59 prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:109 cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12 armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:121 cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:154 main() --> ./compile.sh:52 ] [🌿] Built ANSI log file [ /home/leo/armbian/output/logs/armbian-build-28afec36-cd02-43ba-be63-5334f3516cba.ansitxt.log ] [💥] Error occurred in main shell [ code 2 at /home/leo/armbian/lib/functions/cli/utils-cli.sh:215 cli_standard_relaunch_docker_or_sudo() --> ./lib/functions/cli/utils-cli.sh:215 cli_standard_build_pre_run() --> ./lib/functions/cli/cli-build.sh:5 armbian_cli_pre_run_command() --> ./lib/functions/cli/utils-cli.sh:107 cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:67 main() --> ./compile.sh:52 ]I very briefly looked at the code that the tracer output.
For lib/functions/configuration/main-config.sh:59 file
This is a very gross mistake. The name of the remote repository can be anything. "origin" is a common option, but far from the only one.
leo@vm-jammy:~/armbian$ echo "$(git remote)" armbian host
Weekly developers meetup
in Community Calendar
12Posted
The most interesting thing about this is that the Armbian build system (what is in the lib folder) becomes unnecessary.
Only settings and patch folders are needed.
If I have OBS, then I need filling in the working directory to build packages.
And only this:
build> tree packages/deb-build/ packages/deb-build/ ├── htop │ └── debian │ ├── changelog │ ├── control │ ├── copyright │ ├── docs │ ├── install │ ├── rules │ ├── source │ │ └── format │ ├── upstream │ │ └── metadata │ └── watch ...... └── README.mdThe "watch" file contains all the necessary information to download the source code archive.
One line of code is needed and the source package is ready in its expanded form.
One more line of code to collect the entire collection of binary and debian source packages.
Ricardo thanks for the tip.