Examine individual changes
From Gentoo Wiki
This page allows you to examine the variables generated by the Abuse Filter for an individual change, and test it against filters.
Variables generated for this change
| Variable | Value |
|---|---|
Edit count of the user (user_editcount) | 72 |
Name of the user account (user_name) | 'Jlpoole' |
Age of the user account (user_age) | 390820866 |
Page ID (page_id) | 747 |
Page namespace (page_namespace) | 1 |
Page title (without namespace) (page_title) | 'Binary package guide' |
Full page title (page_prefixedtitle) | 'Talk:Binary package guide' |
Action (action) | 'edit' |
Edit summary/reason (summary) | ' Verify binary package OpenPGP signatures - More Detail' |
Old content model (old_content_model) | 'wikitext' |
New content model (new_content_model) | 'wikitext' |
Old page wikitext, before the edit (old_wikitext) | '{{Talk page}}
== My Server and Client(s) Setup ==
{{talk|done|date=06 August 2020}}
When I get more time, I'll try studying the article. In the meantime, for the past few years, I've used two of my own scripts called "$HOME/bin/sync-server.sh" & "$HOME/bin/sync-clients.sh" with HOSTNAME checking to make sure they're host or client as well as incorporating some of the commands from "Binary Package Guide". I used well structured Bash Scripting techniques with Functions. Again, I'll try posting them sometime (or I can EMail them upon request), but they're pretty basic. The only trivial part is checking for updating the kernel if it's needed, if so then cp the .config file over and build/install the kernel. Then re-run emerge world as some packages break if there's no .config file immediately following a kernel upgrade. The client scripts finally EMail the server to notify emerge completion. The only rsync'ing I do these days, are /etc/portage files and /usr/local/portage containing my custom ebuilds. No NFS utilization as it complicates things greatly. Everything depends on emerge & layman for syncing. Signed: [[User:Roger|Roger]] 18:33, 15 November 2011 (UTC)
: I'm so glad you like your scripts, Roger. Since you have left the wiki editors with no easy way to reach you, I am closing this discussion. --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:41, 6 August 2020 (UTC)
== 32 bit and 64 bit Package Binary Server ==
{{talk|done}}
I've just upgrade to a 64 bit platform (i7 8x3.5Ghz CPU, w/ 32G RAM) and seem quite capable of building both 32 and 64 bit entire system packages within minutes or an hour or so, and distributing to my older 32 bit platforms versus building them specifically for each arch, on each arch. Would be nice to see some Wiki info on making Gentoo build 32 and 64 bit binary packages. From what I'm guessing, the 32 bit builds performed on a 64 bit platform need to be performed within a chrooted build environment?
After figuring or documenting this, making sure the USE flags are compatible across the 32 & 64 bit binaries need to be addressed. ... shrugs ... I'd love to push the older 32 bit platforms into a binary distro, but nothing seems reasonably stable on any distro except Gentoo, including having Gentoo's flexibility with having newer packages/ebuilds easily available. [[User:Roger|Roger]] 10:18, 13 December 2012 (UTC)
: I guess nobody else really cares. It's been eight years since Roger wrote this, and he's not readily accessible. --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:38, 6 August 2020 (UTC)
:: I care. And currently I'm unable to setup crossdev environment with {{c|i686-pc-linux-gnu-emerge}} and all the necessary layout under {{Path|/usr/i686-pc-linux-gnu}}
:: Cause all I get is this:
::{{RootCmd|crossdev -t i686-pc-linux-gnu --init-target|output=<pre> * Refusing to create a cross-compiler using the same * target name as your host utils. * Consider using sys-devel/multilib-gcc-wrapper package.</pre>}}
:: -- [[User:Anon|Anon]] ([[User talk:Anon|talk]]) 19:50, 2 July 2023 (UTC)
::: With the addition of the chroot guide being added to the article this can now be closed as it's the most suitable way to create a x86 binhost on x86_64.
::: [[User:Immolo|Immolo]] ([[User talk:Immolo|talk]]) 10:58, 14 August 2023 (UTC)
== Is the support for multiple binary package servers still incomplete ? ==
{{talk|done|date=6 August 2020}}
{{Note|The support for multiple binary package servers is somewhat incomplete. If several servers serve a binary package for the same package version, then only the first one will be considered. This can be problematic when these binary packages differ in their USE variable configuration and the USE variable configuration of a later binary package would match the systems configuration.}}
In my own testing I've not been able to reproduce any of the caveats described. Shouldn't we remove this note ? [[User:Sdrik|Sdrik]] ([[User talk:Sdrik|talk]]) 15:25, 27 March 2018 (UTC)
: I'm pretty sure the caveat is still important. You won't run into this unless you're maintaining your own private repositories, and compile two different versions of the same program. --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:24, 6 August 2020 (UTC)
== What about compiler flags when -march=native is used? ==
{{talk|done|date=6 August 2020}}
Am I missing something? building a package and control USE flags is one thing. However, given I have on my hots, i.e. builder machine, -march=native in CFLAGS, it will invoke gcc for its own processor, including processor flags at the stage of compilation. And such a code may be useless on another machine. This should be somehow reflected in the document especially given that the handbook suggests -march=native as the most standard approach. --[[User:Alex-kas|Alex-kas]] ([[User talk:Alex-kas|talk]]) 19:41, 2 February 2020 (UTC)
: Good point. But it's already addressed in "Using Binary Packages":
<!--T:54-->
'''For binary packages to be usable on other systems they must fulfill some requirements:'''
<!--T:123-->
'''* The client and server architecture and <var>[[CHOST]]</var> must match.<br><br>'''
: Doesn't that answer your question? --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:33, 6 August 2020 (UTC)
== We should list available bin package compression formats ==
{{talk|done}}
Portage supports {{c|BINPKG_COMPRESS}} variable which allows for different compression formats to be used, such as lz4. We should list them all here.
[[User:Juippis|Juippis]] ([[User talk:Juippis|talk]]) 13:49, 15 December 2021 (UTC)
: Thanks for the heads up! Sounds like a very good idea, but I don't use this, so I wouldn't know what to add off the top of my head. I have a project that builds packages though, so I may get a chance to come to this with a bit of knowledge some time.
: Comments like this are great, because they focus attention on particular changes that need to be made, so someone will surely get around to this eventually. Feel free to make any changes to fix this yourself however, if you know what needs doing, and don't mind: this seems like the sort of change that users will benefit from :).
: Boilerplate: Remember that no matter if changes aren't perfect, or if the formatting is a bit off, as long as edits make things a bit better, it's a step in the right direction ;). The [[Gentoo_Wiki:Contributor%27s_guide|contributor's guide]] gives a few tips on how to easily make contributions ;).
: I will close this discussion soon, if nothing more is added, as this seems like a pretty complete informational comment in and of itself (see [[Help:Talk_pages#Closing_discussions|closing discussions]]).
: -- [[User:Kyoreln|Kyoreln]] ([[User talk:Kyoreln|talk]]) 14:48, 15 December 2021 (UTC)
:: Done now, I was hoping to get the formats listed here, but they could be found from portage's man page easily after all.
:: [[User:Juippis|Juippis]] ([[User talk:Juippis|talk]]) 08:38, 17 December 2021 (UTC)
::: Fantastic, thanks !! -- [[User:Ris|Ris]] ([[User talk:Ris|talk]]) 09:30, 20 February 2022 (UTC)
== Clarifying the information in the "Understanding the binary package format" section ==
{{talk|open}}
i came to the "Understanding the binary package format" section of this page due to trying to understand the format of the xpak that gets downloaded by the gentoo-kernel-bin ebuild. In that particular case, the compression format is xz, not bz2; but {{c|qtbz2}} can nevertheless be used to split that file into its .tar.xz and the xpak archive components, despite the command name, and despite this not being documented in the man page for {{c|qtbz2}}. Should this section be changed to reflect all this? [[User:Flexibeast|Flexibeast]] ([[User talk:Flexibeast|talk]]) 12:52, 9 March 2022 (UTC)
: Excellent observation. Perhaps the developer of the {{Package|sys-kernel/gentoo-kernel-bin}} package has set custom compression formats on the build machine that is assembling the package... which was discovered by you as you manually disassembled the package step-by-step. binpkg compression can be changed to support various compression algorithms such as bzip2, gzip, lz4, lzip, lzop, xz, and zstd (search for <var>BINPKG_COMPRESS</var> on the {{c|man make.conf}}) for more information... --[[User:Maffblaster|Maffblaster]] ([[User talk:Maffblaster|talk]]) 00:28, 10 March 2022 (UTC)
== Mixing the formats XPAK and GPKG ==
{{talk|open}}
Are there any implications when switching an existing build server to GPKG? Is it enough to configure the format in make.conf? Do clients using the binary packages get along with some as XPAK and others as GPKG? According to this page it does not seem necessary to rebuild all packages to GPKG nor clean XPAK from the packages dir? Is that correct?--[[User:Onkobu|Onkobu]] ([[User talk:Onkobu|talk]]) 15:48, 2 January 2023 (UTC)
: I don't think there are any implications, as long as all clients support all used formats (GPKG is a newer addition). You should be able to just set the format in make.conf on the server, doing so on the client is not necessary. Clients will use whatever the build server sets in {{C|$PKGDIR/Packages}}. Portage saves the binary package filename separately for each package in {{C|$PKGDIR/Packages}} so it will know which file to use. Rebuilding all packages to the same format is not necessary. After switching file format, the old binary package file will remain until cleaned with {{C|eclean packages}}. [[User:Jjakob|Jjakob]] ([[User talk:Jjakob|talk]]) 15:31, 22 May 2023 (UTC)
== Binary package OpenPGP signing ==
{{talk|open}}
I tried to enable this on my machine. I symlinked root's gpg-agent socket to my user's agent extra socket so that root can use my user's gpg smartcard. Imported my gpg public key into root's truststore and set it to ultimate trust. I tried signing some git commits as root and it worked so I know this part works.
Enabled signing by setting
{{FileBox|filename="/etc/portage/make.conf"|lang=sh|1=
BINPKG_FORMAT="gpkg"
FEATURES="buildpkg binpkg-signing"
BINPKG_GPG_SIGNING_GPG_HOME="/root/.gnupg"
BINPKG_GPG_SIGNING_KEY="my key fingerprint"
}}
When I run emerge the package is successfully built and signed (I am requested to press the UIF touch button on my key 3 times after the package is built) but then it fails to verify its signature:
{{RootCmd|"emerge -1 dev-libs/tree-sitter"|output=<pre>
... cut ...
>>> Completed installing dev-libs/tree-sitter-0.20.8 into /var/tmp/portage/dev-libs/tree-sitter-0.20.8/image
... cut ...
>>> Done.
!!!
gpg: keyblock resource '/etc/portage/gnupg/pubring.kbx': No such file or directory
[GNUPG:] ERROR add_keyblock_resource 33587281
[GNUPG:] PLAINTEXT 74 0
[GNUPG:] NEWSIG
gpg: Signature made Mon 22 May 2023 04:51:16 PM CEST
gpg: using EDDSA key FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERRSIG 1E936484FFE8BA69 22 10 01 1684767076 9 FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] NO_PUBKEY 1E936484FFE8BA69
gpg: Can't check signature: No public key
gpg: can't create `/etc/portage/gnupg/random_seed': No such file or directory
!!! Invalid binary package: '/var/cache/binpkgs/dev-libs/tree-sitter-0.20.8.gpkg.tar.3271', GPG verify failed
Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)
handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)>
Traceback (most recent call last):
File "/usr/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb
listener(self)
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 49, in _task_exit_handler
self._start_next_task()
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 43, in _start_next_task
self._start_task(task, self._task_exit_handler)
File "/usr/lib/python3.11/site-packages/_emerge/CompositeTask.py", line 112, in _start_task
task.start()
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 34, in start
self._start()
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 518, in _start
self.ebuild_build._record_binpkg_info(self.ebuild_binpkg)
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 560, in _record_binpkg_info
"BINPKGMD5": f"{pkg._metadata['MD5']}\n",
^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute '_metadata'
Terminated
</pre>}}
Is the section missing an instruction to also follow the {{Link|Binary_package_guide#Verify_binary_package.27s_OpenPGP_signature}} section?
Or is my global {{C|1="USE{{=}}verify-sig"}} causing this?
[[User:Jjakob|Jjakob]] ([[User talk:Jjakob|talk]]) 15:16, 22 May 2023 (UTC)
-------------------------------------------------------------------------------------------
I am having the same issue, emerge --info | grep -i home yields :
PORTAGE_GPG_SIGNING_COMMAND="gpg --sign --digest-algo SHA256 --clearsign --yes --default-key "${PORTAGE_GPG_KEY}" --homedir "${PORTAGE_GPG_DIR}" "${FILE}""
I didn't see either PORTAGE_GPG_DIR or PORTAGE_GPG_KEY in the environmental variables.
so I created them in the make.conf (this could be a version issue/oversight)
Also, I moved the homedir to portage (/var/lib/portage/home), as I use the portage user. After setting the read permissions on 'other' I was able for the process to read trusted.db, and I was able to successfully build a gpkg package. Also, depending on the situation, the .gnupg directory appears to need 'other' accesss, even though emerge uses root. which is weird. anyways.
I am happy to allow portage to have it's own gpg home directory/key. And I am avoiding using the root directory for now
Also, if I opt not to have all four (BINPKG or PORTAGE prefixed) variables set, i get errors. during binpkg creation.
** ALSO I ADDED :
BINPKG_GPG_VERIFY_GPG_HOME=".../.gnupg" ... I have to say, its quite convoluted, perhaps simplifying the gpg variables if its possible, or perhaps just a rewrite in the docs.
--ciaran
[[User:pcxmac|pcxmac]] ([[User talk:pcxmac|talk]]) 08:32, 13 Oct 2023 (PST)
== gpg-keepalive feature ==
{{talk|open}}
I have tried to gpg-keepalive feature, and it does not seem to work. If the compilation last too long, the GPG passphrase is again asked at the end. If I type it, it appears in clear text. Then if I type enter, it hangs, the binary package is not created and the package is not installed.
Any idea on this ?--
[[User:FrancoisVal|FrancoisVal]] ([[User talk:FrancoisVal|talk]]) 13:34, 5 January 2024 (CET)
: Have you tried contacting [[support]], {{u|FrancoisVal}} ? If you find a way to fix this, please do [[What_to_do_when_noticing_an_error_on_the_wiki|add a tip or troubleshoot entry to the article]] so that future readers can avoid the issue :) -- [[User:Ris|Ris]] ([[User talk:Ris|talk]]) 08:46, 2 March 2024 (UTC)
== "chroot" and "cross-compile" not enough for my (common ?) use case ==
===Feel free to reopen===
{{talk|closed}}
My use case is that I want to build on amd64 for amd64 but with completely different cpu features.
Sometimes the target has features that are not on the host.<br>
I know about these 3 ways :
# crosscompiling with emerge-x86_64-mycustomtargetname-linux-gnu instead of emerge-x86_64-pc-linux-gnu (made by crossdev)
# emerge --root=/usr/mycustomtargetname/ --sysroot=/usr/mycustomtargetname
# chroot
The problems I had:
* with 1. : crossdev refused to build a cross compiler with the same tuple (emerge-x86_64-pc-linux-gnu). Then I used another tuple like : cross-x86_64-mycustomtargetname-linux-gnu-gcc
* with 2. : some packages built with the wrong flags and illegal instructions were embedded. I think sqlite was the culprit.
* with 3. : what is described under point 8. "What Goes Wrong" here in this article: [[User:NeddySeagoon/Build_In_A_Chroot]]
Way 1 seems to work.
My hope is that the packages respect the flags more strictly if they think
that they are cross-compiling because the CHOST and CBUILD tuples are different
with way 1.
For the binpkgs to be accepted by the target host I also had to change the target hosts
CHOST. But this worked like so: [[Changing_the_CHOST_variable]]<br><br>
Way 1 is the only way I found to do this.<br><br>
A nice side effect of this approach is that it automatically refuses to install packages with the wrong cflags/opcodes, because of the different CHOST.
Isn't this a somewhat common use case ?
<br>[[User:Alexander-n8hgeg5e|Alexander-n8hgeg5e]] ([[User talk:Alexander-n8hgeg5e|talk]]) 16:03, 29 February 2024 (UTC)<br>
Now I figured out that some packages like dev-libs/gobject-introspection<br>
refuse to cross-compile.<br>
I guess "Way 3" but inside a virtual machine is the prevailing method.<br>
I think it should be mentioned in the article.
<br>[[User:Alexander-n8hgeg5e|Alexander-n8hgeg5e]] ([[User talk:Alexander-n8hgeg5e|talk]]) 16:03, 29 February 2024 (UTC)<br>
:I don't think it's possible to use a chroot with CPU functions that are not available on the host. Me, personally, I've just started to use a chroot on an amd64 Ryzen Arch Linux as host (would be march=znver3, but since it's Arch it's actually x86-64 baseline), the target is an amd64 Intel Core i-3000 Gentoo (march=ivybridge). All the functions that the chrooted environment use are available on the host, even though one is Intel and one is AMD, because the Intel arch is so much older. At least I hope that that's the case, but so far everything worked.
:If both systems are AMD64, the CHOST should be identical anyways: x86_64-pc-linux-gnu. I would recommend to step down to the lowest CFLAGS on the target system that is also supported by the host. psABI architecture levels also come to mind, as in e.g. x86-64-v2. Ubuntu has a blog page that sums this up nicely, [https://ubuntu.com/blog/optimising-ubuntu-performance-on-amd64-architecture here]. GCC uses them with [https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html option -march=], so in your target system's /etc/portage/make.conf you'd use CFLAGS="-march=x86-64-v2". Or -v3 or none, just "x86-64", whatever both systems support.
:I tried crossdev (cross-compiling) once on an amd64 host for a ppc64 target, but I couldn't make it work.
:[[User:Luttztfz|Luttztfz]] ([[User talk:Luttztfz|talk]]) 20:46, 29 February 2024 (UTC)
:: Hm, I think you are right. Now after reading your comment I think way 3(chroot) and way 2(emerge --root= --syroot=) is the usual approach if you are on the same architecture like amd64.
:: The virtual machine seems not to be the solution because the vm could have a big performance problem if it had to emulate a feature inside the chroot.
:: I got very far with this cross compile approach. In one instance it compiled the whole system (ceph node) and only one package (scipy) had to be compiled on the target. But I couldn't automatically fetch the package back to the subtree (/usr/x86_64-mycustomtargetname-linux-gnu) because portage refused somehow to use a binhost declared inside the subtree.
:: I used the same profile and everything as on the target and somehow I had to recompile cross-x86_64-something-linux-gnu/gcc a few times.
::[[User:Alexander-n8hgeg5e|Alexander-n8hgeg5e]] ([[User talk:Alexander-n8hgeg5e|talk]]) 23:51, 1 March 2024 (UTC)
::: Looks like you might get more help from [[support]], {{u|Alexander-n8hgeg5e}}. If you manage to find out the best way to cross compile for your use, please do [[What_to_do_when_noticing_an_error_on_the_wiki|make the article more clear]] for everyone else :) -- [[User:Ris|Ris]] ([[User talk:Ris|talk]]) 08:42, 2 March 2024 (UTC)' |
New page wikitext, after the edit (new_wikitext) | '{{Talk page}}
== My Server and Client(s) Setup ==
{{talk|done|date=06 August 2020}}
When I get more time, I'll try studying the article. In the meantime, for the past few years, I've used two of my own scripts called "$HOME/bin/sync-server.sh" & "$HOME/bin/sync-clients.sh" with HOSTNAME checking to make sure they're host or client as well as incorporating some of the commands from "Binary Package Guide". I used well structured Bash Scripting techniques with Functions. Again, I'll try posting them sometime (or I can EMail them upon request), but they're pretty basic. The only trivial part is checking for updating the kernel if it's needed, if so then cp the .config file over and build/install the kernel. Then re-run emerge world as some packages break if there's no .config file immediately following a kernel upgrade. The client scripts finally EMail the server to notify emerge completion. The only rsync'ing I do these days, are /etc/portage files and /usr/local/portage containing my custom ebuilds. No NFS utilization as it complicates things greatly. Everything depends on emerge & layman for syncing. Signed: [[User:Roger|Roger]] 18:33, 15 November 2011 (UTC)
: I'm so glad you like your scripts, Roger. Since you have left the wiki editors with no easy way to reach you, I am closing this discussion. --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:41, 6 August 2020 (UTC)
== 32 bit and 64 bit Package Binary Server ==
{{talk|done}}
I've just upgrade to a 64 bit platform (i7 8x3.5Ghz CPU, w/ 32G RAM) and seem quite capable of building both 32 and 64 bit entire system packages within minutes or an hour or so, and distributing to my older 32 bit platforms versus building them specifically for each arch, on each arch. Would be nice to see some Wiki info on making Gentoo build 32 and 64 bit binary packages. From what I'm guessing, the 32 bit builds performed on a 64 bit platform need to be performed within a chrooted build environment?
After figuring or documenting this, making sure the USE flags are compatible across the 32 & 64 bit binaries need to be addressed. ... shrugs ... I'd love to push the older 32 bit platforms into a binary distro, but nothing seems reasonably stable on any distro except Gentoo, including having Gentoo's flexibility with having newer packages/ebuilds easily available. [[User:Roger|Roger]] 10:18, 13 December 2012 (UTC)
: I guess nobody else really cares. It's been eight years since Roger wrote this, and he's not readily accessible. --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:38, 6 August 2020 (UTC)
:: I care. And currently I'm unable to setup crossdev environment with {{c|i686-pc-linux-gnu-emerge}} and all the necessary layout under {{Path|/usr/i686-pc-linux-gnu}}
:: Cause all I get is this:
::{{RootCmd|crossdev -t i686-pc-linux-gnu --init-target|output=<pre> * Refusing to create a cross-compiler using the same * target name as your host utils. * Consider using sys-devel/multilib-gcc-wrapper package.</pre>}}
:: -- [[User:Anon|Anon]] ([[User talk:Anon|talk]]) 19:50, 2 July 2023 (UTC)
::: With the addition of the chroot guide being added to the article this can now be closed as it's the most suitable way to create a x86 binhost on x86_64.
::: [[User:Immolo|Immolo]] ([[User talk:Immolo|talk]]) 10:58, 14 August 2023 (UTC)
== Is the support for multiple binary package servers still incomplete ? ==
{{talk|done|date=6 August 2020}}
{{Note|The support for multiple binary package servers is somewhat incomplete. If several servers serve a binary package for the same package version, then only the first one will be considered. This can be problematic when these binary packages differ in their USE variable configuration and the USE variable configuration of a later binary package would match the systems configuration.}}
In my own testing I've not been able to reproduce any of the caveats described. Shouldn't we remove this note ? [[User:Sdrik|Sdrik]] ([[User talk:Sdrik|talk]]) 15:25, 27 March 2018 (UTC)
: I'm pretty sure the caveat is still important. You won't run into this unless you're maintaining your own private repositories, and compile two different versions of the same program. --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:24, 6 August 2020 (UTC)
== What about compiler flags when -march=native is used? ==
{{talk|done|date=6 August 2020}}
Am I missing something? building a package and control USE flags is one thing. However, given I have on my hots, i.e. builder machine, -march=native in CFLAGS, it will invoke gcc for its own processor, including processor flags at the stage of compilation. And such a code may be useless on another machine. This should be somehow reflected in the document especially given that the handbook suggests -march=native as the most standard approach. --[[User:Alex-kas|Alex-kas]] ([[User talk:Alex-kas|talk]]) 19:41, 2 February 2020 (UTC)
: Good point. But it's already addressed in "Using Binary Packages":
<!--T:54-->
'''For binary packages to be usable on other systems they must fulfill some requirements:'''
<!--T:123-->
'''* The client and server architecture and <var>[[CHOST]]</var> must match.<br><br>'''
: Doesn't that answer your question? --[[User:Davidbryant|Davidbryant]] ([[User talk:Davidbryant|talk]]) 14:33, 6 August 2020 (UTC)
== We should list available bin package compression formats ==
{{talk|done}}
Portage supports {{c|BINPKG_COMPRESS}} variable which allows for different compression formats to be used, such as lz4. We should list them all here.
[[User:Juippis|Juippis]] ([[User talk:Juippis|talk]]) 13:49, 15 December 2021 (UTC)
: Thanks for the heads up! Sounds like a very good idea, but I don't use this, so I wouldn't know what to add off the top of my head. I have a project that builds packages though, so I may get a chance to come to this with a bit of knowledge some time.
: Comments like this are great, because they focus attention on particular changes that need to be made, so someone will surely get around to this eventually. Feel free to make any changes to fix this yourself however, if you know what needs doing, and don't mind: this seems like the sort of change that users will benefit from :).
: Boilerplate: Remember that no matter if changes aren't perfect, or if the formatting is a bit off, as long as edits make things a bit better, it's a step in the right direction ;). The [[Gentoo_Wiki:Contributor%27s_guide|contributor's guide]] gives a few tips on how to easily make contributions ;).
: I will close this discussion soon, if nothing more is added, as this seems like a pretty complete informational comment in and of itself (see [[Help:Talk_pages#Closing_discussions|closing discussions]]).
: -- [[User:Kyoreln|Kyoreln]] ([[User talk:Kyoreln|talk]]) 14:48, 15 December 2021 (UTC)
:: Done now, I was hoping to get the formats listed here, but they could be found from portage's man page easily after all.
:: [[User:Juippis|Juippis]] ([[User talk:Juippis|talk]]) 08:38, 17 December 2021 (UTC)
::: Fantastic, thanks !! -- [[User:Ris|Ris]] ([[User talk:Ris|talk]]) 09:30, 20 February 2022 (UTC)
== Clarifying the information in the "Understanding the binary package format" section ==
{{talk|open}}
i came to the "Understanding the binary package format" section of this page due to trying to understand the format of the xpak that gets downloaded by the gentoo-kernel-bin ebuild. In that particular case, the compression format is xz, not bz2; but {{c|qtbz2}} can nevertheless be used to split that file into its .tar.xz and the xpak archive components, despite the command name, and despite this not being documented in the man page for {{c|qtbz2}}. Should this section be changed to reflect all this? [[User:Flexibeast|Flexibeast]] ([[User talk:Flexibeast|talk]]) 12:52, 9 March 2022 (UTC)
: Excellent observation. Perhaps the developer of the {{Package|sys-kernel/gentoo-kernel-bin}} package has set custom compression formats on the build machine that is assembling the package... which was discovered by you as you manually disassembled the package step-by-step. binpkg compression can be changed to support various compression algorithms such as bzip2, gzip, lz4, lzip, lzop, xz, and zstd (search for <var>BINPKG_COMPRESS</var> on the {{c|man make.conf}}) for more information... --[[User:Maffblaster|Maffblaster]] ([[User talk:Maffblaster|talk]]) 00:28, 10 March 2022 (UTC)
== Mixing the formats XPAK and GPKG ==
{{talk|open}}
Are there any implications when switching an existing build server to GPKG? Is it enough to configure the format in make.conf? Do clients using the binary packages get along with some as XPAK and others as GPKG? According to this page it does not seem necessary to rebuild all packages to GPKG nor clean XPAK from the packages dir? Is that correct?--[[User:Onkobu|Onkobu]] ([[User talk:Onkobu|talk]]) 15:48, 2 January 2023 (UTC)
: I don't think there are any implications, as long as all clients support all used formats (GPKG is a newer addition). You should be able to just set the format in make.conf on the server, doing so on the client is not necessary. Clients will use whatever the build server sets in {{C|$PKGDIR/Packages}}. Portage saves the binary package filename separately for each package in {{C|$PKGDIR/Packages}} so it will know which file to use. Rebuilding all packages to the same format is not necessary. After switching file format, the old binary package file will remain until cleaned with {{C|eclean packages}}. [[User:Jjakob|Jjakob]] ([[User talk:Jjakob|talk]]) 15:31, 22 May 2023 (UTC)
== Binary package OpenPGP signing ==
{{talk|open}}
I tried to enable this on my machine. I symlinked root's gpg-agent socket to my user's agent extra socket so that root can use my user's gpg smartcard. Imported my gpg public key into root's truststore and set it to ultimate trust. I tried signing some git commits as root and it worked so I know this part works.
Enabled signing by setting
{{FileBox|filename="/etc/portage/make.conf"|lang=sh|1=
BINPKG_FORMAT="gpkg"
FEATURES="buildpkg binpkg-signing"
BINPKG_GPG_SIGNING_GPG_HOME="/root/.gnupg"
BINPKG_GPG_SIGNING_KEY="my key fingerprint"
}}
When I run emerge the package is successfully built and signed (I am requested to press the UIF touch button on my key 3 times after the package is built) but then it fails to verify its signature:
{{RootCmd|"emerge -1 dev-libs/tree-sitter"|output=<pre>
... cut ...
>>> Completed installing dev-libs/tree-sitter-0.20.8 into /var/tmp/portage/dev-libs/tree-sitter-0.20.8/image
... cut ...
>>> Done.
!!!
gpg: keyblock resource '/etc/portage/gnupg/pubring.kbx': No such file or directory
[GNUPG:] ERROR add_keyblock_resource 33587281
[GNUPG:] PLAINTEXT 74 0
[GNUPG:] NEWSIG
gpg: Signature made Mon 22 May 2023 04:51:16 PM CEST
gpg: using EDDSA key FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERRSIG 1E936484FFE8BA69 22 10 01 1684767076 9 FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] NO_PUBKEY 1E936484FFE8BA69
gpg: Can't check signature: No public key
gpg: can't create `/etc/portage/gnupg/random_seed': No such file or directory
!!! Invalid binary package: '/var/cache/binpkgs/dev-libs/tree-sitter-0.20.8.gpkg.tar.3271', GPG verify failed
Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)
handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)>
Traceback (most recent call last):
File "/usr/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb
listener(self)
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 49, in _task_exit_handler
self._start_next_task()
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 43, in _start_next_task
self._start_task(task, self._task_exit_handler)
File "/usr/lib/python3.11/site-packages/_emerge/CompositeTask.py", line 112, in _start_task
task.start()
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 34, in start
self._start()
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 518, in _start
self.ebuild_build._record_binpkg_info(self.ebuild_binpkg)
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 560, in _record_binpkg_info
"BINPKGMD5": f"{pkg._metadata['MD5']}\n",
^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute '_metadata'
Terminated
</pre>}}
Is the section missing an instruction to also follow the {{Link|Binary_package_guide#Verify_binary_package.27s_OpenPGP_signature}} section?
Or is my global {{C|1="USE{{=}}verify-sig"}} causing this?
[[User:Jjakob|Jjakob]] ([[User talk:Jjakob|talk]]) 15:16, 22 May 2023 (UTC)
-------------------------------------------------------------------------------------------
I am having the same issue, emerge --info | grep -i home yields :
PORTAGE_GPG_SIGNING_COMMAND="gpg --sign --digest-algo SHA256 --clearsign --yes --default-key "${PORTAGE_GPG_KEY}" --homedir "${PORTAGE_GPG_DIR}" "${FILE}""
I didn't see either PORTAGE_GPG_DIR or PORTAGE_GPG_KEY in the environmental variables.
so I created them in the make.conf (this could be a version issue/oversight)
Also, I moved the homedir to portage (/var/lib/portage/home), as I use the portage user. After setting the read permissions on 'other' I was able for the process to read trusted.db, and I was able to successfully build a gpkg package. Also, depending on the situation, the .gnupg directory appears to need 'other' accesss, even though emerge uses root. which is weird. anyways.
I am happy to allow portage to have it's own gpg home directory/key. And I am avoiding using the root directory for now
Also, if I opt not to have all four (BINPKG or PORTAGE prefixed) variables set, i get errors. during binpkg creation.
** ALSO I ADDED :
BINPKG_GPG_VERIFY_GPG_HOME=".../.gnupg" ... I have to say, its quite convoluted, perhaps simplifying the gpg variables if its possible, or perhaps just a rewrite in the docs.
--ciaran
[[User:pcxmac|pcxmac]] ([[User talk:pcxmac|talk]]) 08:32, 13 Oct 2023 (PST)
== gpg-keepalive feature ==
{{talk|open}}
I have tried to gpg-keepalive feature, and it does not seem to work. If the compilation last too long, the GPG passphrase is again asked at the end. If I type it, it appears in clear text. Then if I type enter, it hangs, the binary package is not created and the package is not installed.
Any idea on this ?--
[[User:FrancoisVal|FrancoisVal]] ([[User talk:FrancoisVal|talk]]) 13:34, 5 January 2024 (CET)
: Have you tried contacting [[support]], {{u|FrancoisVal}} ? If you find a way to fix this, please do [[What_to_do_when_noticing_an_error_on_the_wiki|add a tip or troubleshoot entry to the article]] so that future readers can avoid the issue :) -- [[User:Ris|Ris]] ([[User talk:Ris|talk]]) 08:46, 2 March 2024 (UTC)
== "chroot" and "cross-compile" not enough for my (common ?) use case ==
===Feel free to reopen===
{{talk|closed}}
My use case is that I want to build on amd64 for amd64 but with completely different cpu features.
Sometimes the target has features that are not on the host.<br>
I know about these 3 ways :
# crosscompiling with emerge-x86_64-mycustomtargetname-linux-gnu instead of emerge-x86_64-pc-linux-gnu (made by crossdev)
# emerge --root=/usr/mycustomtargetname/ --sysroot=/usr/mycustomtargetname
# chroot
The problems I had:
* with 1. : crossdev refused to build a cross compiler with the same tuple (emerge-x86_64-pc-linux-gnu). Then I used another tuple like : cross-x86_64-mycustomtargetname-linux-gnu-gcc
* with 2. : some packages built with the wrong flags and illegal instructions were embedded. I think sqlite was the culprit.
* with 3. : what is described under point 8. "What Goes Wrong" here in this article: [[User:NeddySeagoon/Build_In_A_Chroot]]
Way 1 seems to work.
My hope is that the packages respect the flags more strictly if they think
that they are cross-compiling because the CHOST and CBUILD tuples are different
with way 1.
For the binpkgs to be accepted by the target host I also had to change the target hosts
CHOST. But this worked like so: [[Changing_the_CHOST_variable]]<br><br>
Way 1 is the only way I found to do this.<br><br>
A nice side effect of this approach is that it automatically refuses to install packages with the wrong cflags/opcodes, because of the different CHOST.
Isn't this a somewhat common use case ?
<br>[[User:Alexander-n8hgeg5e|Alexander-n8hgeg5e]] ([[User talk:Alexander-n8hgeg5e|talk]]) 16:03, 29 February 2024 (UTC)<br>
Now I figured out that some packages like dev-libs/gobject-introspection<br>
refuse to cross-compile.<br>
I guess "Way 3" but inside a virtual machine is the prevailing method.<br>
I think it should be mentioned in the article.
<br>[[User:Alexander-n8hgeg5e|Alexander-n8hgeg5e]] ([[User talk:Alexander-n8hgeg5e|talk]]) 16:03, 29 February 2024 (UTC)<br>
:I don't think it's possible to use a chroot with CPU functions that are not available on the host. Me, personally, I've just started to use a chroot on an amd64 Ryzen Arch Linux as host (would be march=znver3, but since it's Arch it's actually x86-64 baseline), the target is an amd64 Intel Core i-3000 Gentoo (march=ivybridge). All the functions that the chrooted environment use are available on the host, even though one is Intel and one is AMD, because the Intel arch is so much older. At least I hope that that's the case, but so far everything worked.
:If both systems are AMD64, the CHOST should be identical anyways: x86_64-pc-linux-gnu. I would recommend to step down to the lowest CFLAGS on the target system that is also supported by the host. psABI architecture levels also come to mind, as in e.g. x86-64-v2. Ubuntu has a blog page that sums this up nicely, [https://ubuntu.com/blog/optimising-ubuntu-performance-on-amd64-architecture here]. GCC uses them with [https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html option -march=], so in your target system's /etc/portage/make.conf you'd use CFLAGS="-march=x86-64-v2". Or -v3 or none, just "x86-64", whatever both systems support.
:I tried crossdev (cross-compiling) once on an amd64 host for a ppc64 target, but I couldn't make it work.
:[[User:Luttztfz|Luttztfz]] ([[User talk:Luttztfz|talk]]) 20:46, 29 February 2024 (UTC)
:: Hm, I think you are right. Now after reading your comment I think way 3(chroot) and way 2(emerge --root= --syroot=) is the usual approach if you are on the same architecture like amd64.
:: The virtual machine seems not to be the solution because the vm could have a big performance problem if it had to emulate a feature inside the chroot.
:: I got very far with this cross compile approach. In one instance it compiled the whole system (ceph node) and only one package (scipy) had to be compiled on the target. But I couldn't automatically fetch the package back to the subtree (/usr/x86_64-mycustomtargetname-linux-gnu) because portage refused somehow to use a binhost declared inside the subtree.
:: I used the same profile and everything as on the target and somehow I had to recompile cross-x86_64-something-linux-gnu/gcc a few times.
::[[User:Alexander-n8hgeg5e|Alexander-n8hgeg5e]] ([[User talk:Alexander-n8hgeg5e|talk]]) 23:51, 1 March 2024 (UTC)
::: Looks like you might get more help from [[support]], {{u|Alexander-n8hgeg5e}}. If you manage to find out the best way to cross compile for your use, please do [[What_to_do_when_noticing_an_error_on_the_wiki|make the article more clear]] for everyone else :) -- [[User:Ris|Ris]] ([[User talk:Ris|talk]]) 08:42, 2 March 2024 (UTC)
== Verify binary package OpenPGP signatures ==
{{talk|open}}
I think this section should provide a recommended package and therefore this paragraph:
1. Generate (or use an existing) key with signing abilities, and export the public key to a file.
might be altered to state (perhaps including a colorized console consistent with this page's style):
1. If you do not have an existing key with signing abilities, emerge app-crypt/gnupg and then generate a key. See https://wiki.gentoo.org/wiki/GnuPG.
~~~~' |
Unified diff of changes made by edit (edit_diff) | '@@ -220,2 +220,16 @@
::: Looks like you might get more help from [[support]], {{u|Alexander-n8hgeg5e}}. If you manage to find out the best way to cross compile for your use, please do [[What_to_do_when_noticing_an_error_on_the_wiki|make the article more clear]] for everyone else :) -- [[User:Ris|Ris]] ([[User talk:Ris|talk]]) 08:42, 2 March 2024 (UTC)
+
+
+== Verify binary package OpenPGP signatures ==
+{{talk|open}}
+
+I think this section should provide a recommended package and therefore this paragraph:
+
+ 1. Generate (or use an existing) key with signing abilities, and export the public key to a file.
+
+might be altered to state (perhaps including a colorized console consistent with this page's style):
+
+ 1. If you do not have an existing key with signing abilities, emerge app-crypt/gnupg and then generate a key. See https://wiki.gentoo.org/wiki/GnuPG.
+
+~~~~
' |
Old page size (old_size) | 19892 |
Lines added in edit (added_lines) | [
0 => '',
1 => '',
2 => '== Verify binary package OpenPGP signatures == ',
3 => '{{talk|open}}',
4 => '',
5 => 'I think this section should provide a recommended package and therefore this paragraph:',
6 => '',
7 => ' 1. Generate (or use an existing) key with signing abilities, and export the public key to a file.',
8 => '',
9 => 'might be altered to state (perhaps including a colorized console consistent with this page's style):',
10 => '',
11 => ' 1. If you do not have an existing key with signing abilities, emerge app-crypt/gnupg and then generate a key. See https://wiki.gentoo.org/wiki/GnuPG.',
12 => '',
13 => '~~~~'
] |
Lines removed in edit (removed_lines) | [] |
New page text, stripped of any markup (new_text) | ' NoteThis is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.
Contents
1 My Server and Client(s) Setup
2 32 bit and 64 bit Package Binary Server
3 Is the support for multiple binary package servers still incomplete ?
4 What about compiler flags when -march=native is used?
5 We should list available bin package compression formats
6 Clarifying the information in the "Understanding the binary package format" section
7 Mixing the formats XPAK and GPKG
8 Binary package OpenPGP signing
9 gpg-keepalive feature
10 "chroot" and "cross-compile" not enough for my (common ?) use case
10.1 Feel free to reopen
11 Verify binary package OpenPGP signatures
My Server and Client(s) Setup[edit source]
Talk status
This discussion is done as of 06 August 2020.
When I get more time, I'll try studying the article. In the meantime, for the past few years, I've used two of my own scripts called "$HOME/bin/sync-server.sh" & "$HOME/bin/sync-clients.sh" with HOSTNAME checking to make sure they're host or client as well as incorporating some of the commands from "Binary Package Guide". I used well structured Bash Scripting techniques with Functions. Again, I'll try posting them sometime (or I can EMail them upon request), but they're pretty basic. The only trivial part is checking for updating the kernel if it's needed, if so then cp the .config file over and build/install the kernel. Then re-run emerge world as some packages break if there's no .config file immediately following a kernel upgrade. The client scripts finally EMail the server to notify emerge completion. The only rsync'ing I do these days, are /etc/portage files and /usr/local/portage containing my custom ebuilds. No NFS utilization as it complicates things greatly. Everything depends on emerge & layman for syncing. Signed: Roger 18:33, 15 November 2011 (UTC)
I'm so glad you like your scripts, Roger. Since you have left the wiki editors with no easy way to reach you, I am closing this discussion. --Davidbryant (talk) 14:41, 6 August 2020 (UTC)
32 bit and 64 bit Package Binary Server[edit source]
Talk status
This discussion is done.
I've just upgrade to a 64 bit platform (i7 8x3.5Ghz CPU, w/ 32G RAM) and seem quite capable of building both 32 and 64 bit entire system packages within minutes or an hour or so, and distributing to my older 32 bit platforms versus building them specifically for each arch, on each arch. Would be nice to see some Wiki info on making Gentoo build 32 and 64 bit binary packages. From what I'm guessing, the 32 bit builds performed on a 64 bit platform need to be performed within a chrooted build environment?
After figuring or documenting this, making sure the USE flags are compatible across the 32 & 64 bit binaries need to be addressed. ... shrugs ... I'd love to push the older 32 bit platforms into a binary distro, but nothing seems reasonably stable on any distro except Gentoo, including having Gentoo's flexibility with having newer packages/ebuilds easily available. Roger 10:18, 13 December 2012 (UTC)
I guess nobody else really cares. It's been eight years since Roger wrote this, and he's not readily accessible. --Davidbryant (talk) 14:38, 6 August 2020 (UTC)
I care. And currently I'm unable to setup crossdev environment with i686-pc-linux-gnu-emerge and all the necessary layout under /usr/i686-pc-linux-gnu
Cause all I get is this:
root #crossdev -t i686-pc-linux-gnu --init-target * Refusing to create a cross-compiler using the same * target name as your host utils. * Consider using sys-devel/multilib-gcc-wrapper package.
-- Anon (talk) 19:50, 2 July 2023 (UTC)
With the addition of the chroot guide being added to the article this can now be closed as it's the most suitable way to create a x86 binhost on x86_64.
Immolo (talk) 10:58, 14 August 2023 (UTC)
Is the support for multiple binary package servers still incomplete ?[edit source]
Talk status
This discussion is done as of 6 August 2020.
NoteThe support for multiple binary package servers is somewhat incomplete. If several servers serve a binary package for the same package version, then only the first one will be considered. This can be problematic when these binary packages differ in their USE variable configuration and the USE variable configuration of a later binary package would match the systems configuration.
In my own testing I've not been able to reproduce any of the caveats described. Shouldn't we remove this note ? Sdrik (talk) 15:25, 27 March 2018 (UTC)
I'm pretty sure the caveat is still important. You won't run into this unless you're maintaining your own private repositories, and compile two different versions of the same program. --Davidbryant (talk) 14:24, 6 August 2020 (UTC)
What about compiler flags when -march=native is used?[edit source]
Talk status
This discussion is done as of 6 August 2020.
Am I missing something? building a package and control USE flags is one thing. However, given I have on my hots, i.e. builder machine, -march=native in CFLAGS, it will invoke gcc for its own processor, including processor flags at the stage of compilation. And such a code may be useless on another machine. This should be somehow reflected in the document especially given that the handbook suggests -march=native as the most standard approach. --Alex-kas (talk) 19:41, 2 February 2020 (UTC)
Good point. But it's already addressed in "Using Binary Packages":
For binary packages to be usable on other systems they must fulfill some requirements:
* The client and server architecture and CHOST must match.
Doesn't that answer your question? --Davidbryant (talk) 14:33, 6 August 2020 (UTC)
We should list available bin package compression formats[edit source]
Talk status
This discussion is done.
Portage supports BINPKG_COMPRESS variable which allows for different compression formats to be used, such as lz4. We should list them all here.
Juippis (talk) 13:49, 15 December 2021 (UTC)
Thanks for the heads up! Sounds like a very good idea, but I don't use this, so I wouldn't know what to add off the top of my head. I have a project that builds packages though, so I may get a chance to come to this with a bit of knowledge some time.
Comments like this are great, because they focus attention on particular changes that need to be made, so someone will surely get around to this eventually. Feel free to make any changes to fix this yourself however, if you know what needs doing, and don't mind: this seems like the sort of change that users will benefit from :).
Boilerplate: Remember that no matter if changes aren't perfect, or if the formatting is a bit off, as long as edits make things a bit better, it's a step in the right direction ;). The contributor's guide gives a few tips on how to easily make contributions ;).
I will close this discussion soon, if nothing more is added, as this seems like a pretty complete informational comment in and of itself (see closing discussions).
-- Kyoreln (talk) 14:48, 15 December 2021 (UTC)
Done now, I was hoping to get the formats listed here, but they could be found from portage's man page easily after all.
Juippis (talk) 08:38, 17 December 2021 (UTC)
Fantastic, thanks !! -- Ris (talk) 09:30, 20 February 2022 (UTC)
Clarifying the information in the "Understanding the binary package format" section[edit source]
Talk status
This discussion is still ongoing.
i came to the "Understanding the binary package format" section of this page due to trying to understand the format of the xpak that gets downloaded by the gentoo-kernel-bin ebuild. In that particular case, the compression format is xz, not bz2; but qtbz2 can nevertheless be used to split that file into its .tar.xz and the xpak archive components, despite the command name, and despite this not being documented in the man page for qtbz2. Should this section be changed to reflect all this? Flexibeast (talk) 12:52, 9 March 2022 (UTC)
Excellent observation. Perhaps the developer of the sys-kernel/gentoo-kernel-bin package has set custom compression formats on the build machine that is assembling the package... which was discovered by you as you manually disassembled the package step-by-step. binpkg compression can be changed to support various compression algorithms such as bzip2, gzip, lz4, lzip, lzop, xz, and zstd (search for BINPKG_COMPRESS on the man make.conf) for more information... --Maffblaster (talk) 00:28, 10 March 2022 (UTC)
Mixing the formats XPAK and GPKG[edit source]
Talk status
This discussion is still ongoing.
Are there any implications when switching an existing build server to GPKG? Is it enough to configure the format in make.conf? Do clients using the binary packages get along with some as XPAK and others as GPKG? According to this page it does not seem necessary to rebuild all packages to GPKG nor clean XPAK from the packages dir? Is that correct?--Onkobu (talk) 15:48, 2 January 2023 (UTC)
I don't think there are any implications, as long as all clients support all used formats (GPKG is a newer addition). You should be able to just set the format in make.conf on the server, doing so on the client is not necessary. Clients will use whatever the build server sets in $PKGDIR/Packages. Portage saves the binary package filename separately for each package in $PKGDIR/Packages so it will know which file to use. Rebuilding all packages to the same format is not necessary. After switching file format, the old binary package file will remain until cleaned with eclean packages. Jjakob (talk) 15:31, 22 May 2023 (UTC)
Binary package OpenPGP signing[edit source]
Talk status
This discussion is still ongoing.
I tried to enable this on my machine. I symlinked root's gpg-agent socket to my user's agent extra socket so that root can use my user's gpg smartcard. Imported my gpg public key into root's truststore and set it to ultimate trust. I tried signing some git commits as root and it worked so I know this part works.
Enabled signing by setting
FILE "/etc/portage/make.conf" BINPKG_FORMAT="gpkg"
FEATURES="buildpkg binpkg-signing"
BINPKG_GPG_SIGNING_GPG_HOME="/root/.gnupg"
BINPKG_GPG_SIGNING_KEY="my key fingerprint"
When I run emerge the package is successfully built and signed (I am requested to press the UIF touch button on my key 3 times after the package is built) but then it fails to verify its signature:
root #"emerge -1 dev-libs/tree-sitter"... cut ...
>>> Completed installing dev-libs/tree-sitter-0.20.8 into /var/tmp/portage/dev-libs/tree-sitter-0.20.8/image
... cut ...
>>> Done.
!!!
gpg: keyblock resource '/etc/portage/gnupg/pubring.kbx': No such file or directory
[GNUPG:] ERROR add_keyblock_resource 33587281
[GNUPG:] PLAINTEXT 74 0
[GNUPG:] NEWSIG
gpg: Signature made Mon 22 May 2023 04:51:16 PM CEST
gpg: using EDDSA key FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERRSIG 1E936484FFE8BA69 22 10 01 1684767076 9 FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] NO_PUBKEY 1E936484FFE8BA69
gpg: Can't check signature: No public key
gpg: can't create `/etc/portage/gnupg/random_seed': No such file or directory
!!! Invalid binary package: '/var/cache/binpkgs/dev-libs/tree-sitter-0.20.8.gpkg.tar.3271', GPG verify failed
Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)
handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)>
Traceback (most recent call last):
File "/usr/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb
listener(self)
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 49, in _task_exit_handler
self._start_next_task()
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 43, in _start_next_task
self._start_task(task, self._task_exit_handler)
File "/usr/lib/python3.11/site-packages/_emerge/CompositeTask.py", line 112, in _start_task
task.start()
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 34, in start
self._start()
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 518, in _start
self.ebuild_build._record_binpkg_info(self.ebuild_binpkg)
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 560, in _record_binpkg_info
"BINPKGMD5": f"{pkg._metadata['MD5']}\n",
^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute '_metadata'
Terminated
Is the section missing an instruction to also follow the Binary_package_guide#Verify_binary_package.27s_OpenPGP_signature section?
Or is my global "USE=verify-sig" causing this?
Jjakob (talk) 15:16, 22 May 2023 (UTC)
I am having the same issue, emerge --info | grep -i home yields :
PORTAGE_GPG_SIGNING_COMMAND="gpg --sign --digest-algo SHA256 --clearsign --yes --default-key "${PORTAGE_GPG_KEY}" --homedir "${PORTAGE_GPG_DIR}" "${FILE}""
I didn't see either PORTAGE_GPG_DIR or PORTAGE_GPG_KEY in the environmental variables.
so I created them in the make.conf (this could be a version issue/oversight)
Also, I moved the homedir to portage (/var/lib/portage/home), as I use the portage user. After setting the read permissions on 'other' I was able for the process to read trusted.db, and I was able to successfully build a gpkg package. Also, depending on the situation, the .gnupg directory appears to need 'other' accesss, even though emerge uses root. which is weird. anyways.
I am happy to allow portage to have it's own gpg home directory/key. And I am avoiding using the root directory for now
Also, if I opt not to have all four (BINPKG or PORTAGE prefixed) variables set, i get errors. during binpkg creation.
ALSO I ADDED :
BINPKG_GPG_VERIFY_GPG_HOME=".../.gnupg" ... I have to say, its quite convoluted, perhaps simplifying the gpg variables if its possible, or perhaps just a rewrite in the docs.
--ciaran
pcxmac (talk) 08:32, 13 Oct 2023 (PST)
gpg-keepalive feature[edit source]
Talk status
This discussion is still ongoing.
I have tried to gpg-keepalive feature, and it does not seem to work. If the compilation last too long, the GPG passphrase is again asked at the end. If I type it, it appears in clear text. Then if I type enter, it hangs, the binary package is not created and the package is not installed.
Any idea on this ?--
FrancoisVal (talk) 13:34, 5 January 2024 (CET)
Have you tried contacting support, FrancoisVal  ? If you find a way to fix this, please do add a tip or troubleshoot entry to the article so that future readers can avoid the issue :) -- Ris (talk) 08:46, 2 March 2024 (UTC)
"chroot" and "cross-compile" not enough for my (common ?) use case[edit source]
Feel free to reopen[edit source]
Talk status
This discussion is done.
My use case is that I want to build on amd64 for amd64 but with completely different cpu features.
Sometimes the target has features that are not on the host.
I know about these 3 ways :
crosscompiling with emerge-x86_64-mycustomtargetname-linux-gnu instead of emerge-x86_64-pc-linux-gnu (made by crossdev)
emerge --root=/usr/mycustomtargetname/ --sysroot=/usr/mycustomtargetname
chroot
The problems I had:
with 1. : crossdev refused to build a cross compiler with the same tuple (emerge-x86_64-pc-linux-gnu). Then I used another tuple like : cross-x86_64-mycustomtargetname-linux-gnu-gcc
with 2. : some packages built with the wrong flags and illegal instructions were embedded. I think sqlite was the culprit.
with 3. : what is described under point 8. "What Goes Wrong" here in this article: User:NeddySeagoon/Build_In_A_Chroot
Way 1 seems to work.
My hope is that the packages respect the flags more strictly if they think
that they are cross-compiling because the CHOST and CBUILD tuples are different
with way 1.
For the binpkgs to be accepted by the target host I also had to change the target hosts
CHOST. But this worked like so: Changing_the_CHOST_variable
Way 1 is the only way I found to do this.
A nice side effect of this approach is that it automatically refuses to install packages with the wrong cflags/opcodes, because of the different CHOST.
Isn't this a somewhat common use case ?
Alexander-n8hgeg5e (talk) 16:03, 29 February 2024 (UTC)
Now I figured out that some packages like dev-libs/gobject-introspection
refuse to cross-compile.
I guess "Way 3" but inside a virtual machine is the prevailing method.
I think it should be mentioned in the article.
Alexander-n8hgeg5e (talk) 16:03, 29 February 2024 (UTC)
I don't think it's possible to use a chroot with CPU functions that are not available on the host. Me, personally, I've just started to use a chroot on an amd64 Ryzen Arch Linux as host (would be march=znver3, but since it's Arch it's actually x86-64 baseline), the target is an amd64 Intel Core i-3000 Gentoo (march=ivybridge). All the functions that the chrooted environment use are available on the host, even though one is Intel and one is AMD, because the Intel arch is so much older. At least I hope that that's the case, but so far everything worked.
If both systems are AMD64, the CHOST should be identical anyways: x86_64-pc-linux-gnu. I would recommend to step down to the lowest CFLAGS on the target system that is also supported by the host. psABI architecture levels also come to mind, as in e.g. x86-64-v2. Ubuntu has a blog page that sums this up nicely, here. GCC uses them with option -march=, so in your target system's /etc/portage/make.conf you'd use CFLAGS="-march=x86-64-v2". Or -v3 or none, just "x86-64", whatever both systems support.
I tried crossdev (cross-compiling) once on an amd64 host for a ppc64 target, but I couldn't make it work.
Luttztfz (talk) 20:46, 29 February 2024 (UTC)
Hm, I think you are right. Now after reading your comment I think way 3(chroot) and way 2(emerge --root= --syroot=) is the usual approach if you are on the same architecture like amd64.
The virtual machine seems not to be the solution because the vm could have a big performance problem if it had to emulate a feature inside the chroot.
I got very far with this cross compile approach. In one instance it compiled the whole system (ceph node) and only one package (scipy) had to be compiled on the target. But I couldn't automatically fetch the package back to the subtree (/usr/x86_64-mycustomtargetname-linux-gnu) because portage refused somehow to use a binhost declared inside the subtree.
I used the same profile and everything as on the target and somehow I had to recompile cross-x86_64-something-linux-gnu/gcc a few times.
Alexander-n8hgeg5e (talk) 23:51, 1 March 2024 (UTC)
Looks like you might get more help from support, Alexander-n8hgeg5e . If you manage to find out the best way to cross compile for your use, please do make the article more clear for everyone else :) -- Ris (talk) 08:42, 2 March 2024 (UTC)
Verify binary package OpenPGP signatures[edit source]
Talk status
This discussion is still ongoing.
I think this section should provide a recommended package and therefore this paragraph:
1. Generate (or use an existing) key with signing abilities, and export the public key to a file.
might be altered to state (perhaps including a colorized console consistent with this page's style):
1. If you do not have an existing key with signing abilities, emerge app-crypt/gnupg and then generate a key. See https://wiki.gentoo.org/wiki/GnuPG.
Jlpoole (talk) 02:17, 30 March 2024 (UTC)' |
Parsed HTML source of the new revision (new_html) | '<div class="mw-parser-output"><div class="alert alert-info gw-box" style="padding-top: 8px; padding-bottom: 8px;"><strong><i class="fa fa-sticky-note-o fa-rotate-180"></i> Note</strong><br />This is a <i>Talk page</i> - please see the documentation about <a href="/wiki/Help:Talk_pages" title="Help:Talk pages">using talk pages</a>. Add newer <i>comments</i> below older ones, <b><a href="/wiki/Help:Signatures" title="Help:Signatures">sign comments</a> using four tildes</b> (<code>~~~~</code>), and indent successive comments with colons (<code>:</code>).
Add new <i>sections</i> at the bottom of the page, under a heading (<code>== ==</code>). Please remember to <b>mark sections as "open for discussion"</b> using <code>{{talk|open}}</code>, so they will show up in the list of <a href="/wiki/Category:Open_discussions" title="Category:Open discussions">open discussions</a>.</div>
<div id="toc" class="toc" role="navigation" aria-labelledby="mw-toc-heading"><input type="checkbox" role="button" id="toctogglecheckbox" class="toctogglecheckbox" style="display:none" /><div class="toctitle" lang="en" dir="ltr"><h2 id="mw-toc-heading">Contents</h2><span class="toctogglespan"><label class="toctogglelabel" for="toctogglecheckbox"></label></span></div>
<ul>
<li class="toclevel-1 tocsection-1"><a href="#My_Server_and_Client.28s.29_Setup"><span class="tocnumber">1</span> <span class="toctext">My Server and Client(s) Setup</span></a></li>
<li class="toclevel-1 tocsection-2"><a href="#32_bit_and_64_bit_Package_Binary_Server"><span class="tocnumber">2</span> <span class="toctext">32 bit and 64 bit Package Binary Server</span></a></li>
<li class="toclevel-1 tocsection-3"><a href="#Is_the_support_for_multiple_binary_package_servers_still_incomplete_.3F"><span class="tocnumber">3</span> <span class="toctext">Is the support for multiple binary package servers still incomplete ?</span></a></li>
<li class="toclevel-1 tocsection-4"><a href="#What_about_compiler_flags_when_-march.3Dnative_is_used.3F"><span class="tocnumber">4</span> <span class="toctext">What about compiler flags when -march=native is used?</span></a></li>
<li class="toclevel-1 tocsection-5"><a href="#We_should_list_available_bin_package_compression_formats"><span class="tocnumber">5</span> <span class="toctext">We should list available bin package compression formats</span></a></li>
<li class="toclevel-1 tocsection-6"><a href="#Clarifying_the_information_in_the_.22Understanding_the_binary_package_format.22_section"><span class="tocnumber">6</span> <span class="toctext">Clarifying the information in the "Understanding the binary package format" section</span></a></li>
<li class="toclevel-1 tocsection-7"><a href="#Mixing_the_formats_XPAK_and_GPKG"><span class="tocnumber">7</span> <span class="toctext">Mixing the formats XPAK and GPKG</span></a></li>
<li class="toclevel-1 tocsection-8"><a href="#Binary_package_OpenPGP_signing"><span class="tocnumber">8</span> <span class="toctext">Binary package OpenPGP signing</span></a></li>
<li class="toclevel-1 tocsection-9"><a href="#gpg-keepalive_feature"><span class="tocnumber">9</span> <span class="toctext">gpg-keepalive feature</span></a></li>
<li class="toclevel-1 tocsection-10"><a href="#.22chroot.22_and_.22cross-compile.22_not_enough_for_my_.28common_.3F.29_use_case"><span class="tocnumber">10</span> <span class="toctext">"chroot" and "cross-compile" not enough for my (common ?) use case</span></a>
<ul>
<li class="toclevel-2 tocsection-11"><a href="#Feel_free_to_reopen"><span class="tocnumber">10.1</span> <span class="toctext">Feel free to reopen</span></a></li>
</ul>
</li>
<li class="toclevel-1 tocsection-12"><a href="#Verify_binary_package_OpenPGP_signatures"><span class="tocnumber">11</span> <span class="toctext">Verify binary package OpenPGP signatures</span></a></li>
</ul>
</div>
<h2><span id="My_Server_and_Client(s)_Setup"></span><span class="mw-headline" id="My_Server_and_Client.28s.29_Setup">My Server and Client(s) Setup</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=1" title="Edit section: My Server and Client(s) Setup">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-check fa-fw fa-2x"></span></span><span>This discussion is done as of 06 August 2020.</span></div>
</div>
<p>When I get more time, I'll try studying the article. In the meantime, for the past few years, I've used two of my own scripts called "$HOME/bin/sync-server.sh" & "$HOME/bin/sync-clients.sh" with HOSTNAME checking to make sure they're host or client as well as incorporating some of the commands from "Binary Package Guide". I used well structured Bash Scripting techniques with Functions. Again, I'll try posting them sometime (or I can EMail them upon request), but they're pretty basic. The only trivial part is checking for updating the kernel if it's needed, if so then cp the .config file over and build/install the kernel. Then re-run emerge world as some packages break if there's no .config file immediately following a kernel upgrade. The client scripts finally EMail the server to notify emerge completion. The only rsync'ing I do these days, are /etc/portage files and /usr/local/portage containing my custom ebuilds. No NFS utilization as it complicates things greatly. Everything depends on emerge & layman for syncing. Signed: <a href="/index.php?title=User:Roger&action=edit&redlink=1" class="new" title="User:Roger (page does not exist)">Roger</a> 18:33, 15 November 2011 (UTC)
</p>
<dl><dd>I'm so glad you like your scripts, Roger. Since you have left the wiki editors with no easy way to reach you, I am closing this discussion. --<a href="/wiki/User:Davidbryant" title="User:Davidbryant">Davidbryant</a> (<a href="/wiki/User_talk:Davidbryant" title="User talk:Davidbryant">talk</a>) 14:41, 6 August 2020 (UTC)</dd></dl>
<h2><span class="mw-headline" id="32_bit_and_64_bit_Package_Binary_Server">32 bit and 64 bit Package Binary Server</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=2" title="Edit section: 32 bit and 64 bit Package Binary Server">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-check fa-fw fa-2x"></span></span><span>This discussion is done.</span></div>
</div>
<p>I've just upgrade to a 64 bit platform (i7 8x3.5Ghz CPU, w/ 32G RAM) and seem quite capable of building both 32 and 64 bit entire system packages within minutes or an hour or so, and distributing to my older 32 bit platforms versus building them specifically for each arch, on each arch. Would be nice to see some Wiki info on making Gentoo build 32 and 64 bit binary packages. From what I'm guessing, the 32 bit builds performed on a 64 bit platform need to be performed within a chrooted build environment?
</p><p>After figuring or documenting this, making sure the USE flags are compatible across the 32 & 64 bit binaries need to be addressed. ... shrugs ... I'd love to push the older 32 bit platforms into a binary distro, but nothing seems reasonably stable on any distro except Gentoo, including having Gentoo's flexibility with having newer packages/ebuilds easily available. <a href="/index.php?title=User:Roger&action=edit&redlink=1" class="new" title="User:Roger (page does not exist)">Roger</a> 10:18, 13 December 2012 (UTC)
</p>
<dl><dd>I guess nobody else really cares. It's been eight years since Roger wrote this, and he's not readily accessible. --<a href="/wiki/User:Davidbryant" title="User:Davidbryant">Davidbryant</a> (<a href="/wiki/User_talk:Davidbryant" title="User talk:Davidbryant">talk</a>) 14:38, 6 August 2020 (UTC)</dd></dl>
<dl><dd><dl><dd>I care. And currently I'm unable to setup crossdev environment with <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">i686-pc-linux-gnu-emerge</span> and all the necessary layout under <span style="font-family: monospace; font-size: 95%; color: #3c763d; font-weight: 600;">/usr/i686-pc-linux-gnu</span></dd></dl></dd></dl>
<dl><dd><dl><dd>Cause all I get is this:</dd>
<dd><div class="cmd-box"><div><code style="color: #ef2929; font-weight: bold;">root <span style="color:royalblue;">#</span></code><span class="tripleclick-separator"></span><code>crossdev -t i686-pc-linux-gnu --init-target</code></div><pre> * Refusing to create a cross-compiler using the same * target name as your host utils. * Consider using sys-devel/multilib-gcc-wrapper package.</pre></div></dd>
<dd>-- <a href="/index.php?title=User:Anon&action=edit&redlink=1" class="new" title="User:Anon (page does not exist)">Anon</a> (<a href="/index.php?title=User_talk:Anon&action=edit&redlink=1" class="new" title="User talk:Anon (page does not exist)">talk</a>) 19:50, 2 July 2023 (UTC)</dd></dl></dd></dl>
<dl><dd><dl><dd><dl><dd>With the addition of the chroot guide being added to the article this can now be closed as it's the most suitable way to create a x86 binhost on x86_64.</dd>
<dd><a href="/wiki/User:Immolo" title="User:Immolo">Immolo</a> (<a href="/index.php?title=User_talk:Immolo&action=edit&redlink=1" class="new" title="User talk:Immolo (page does not exist)">talk</a>) 10:58, 14 August 2023 (UTC)</dd></dl></dd></dl></dd></dl>
<h2><span id="Is_the_support_for_multiple_binary_package_servers_still_incomplete_?"></span><span class="mw-headline" id="Is_the_support_for_multiple_binary_package_servers_still_incomplete_.3F">Is the support for multiple binary package servers still incomplete ?</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=3" title="Edit section: Is the support for multiple binary package servers still incomplete ?">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-check fa-fw fa-2x"></span></span><span>This discussion is done as of 6 August 2020.</span></div>
</div>
<div class="alert alert-info gw-box" style="padding-top: 8px; padding-bottom: 8px;"><strong><i class="fa fa-sticky-note-o fa-rotate-180"></i> Note</strong><br />The support for multiple binary package servers is somewhat incomplete. If several servers serve a binary package for the same package version, then only the first one will be considered. This can be problematic when these binary packages differ in their USE variable configuration and the USE variable configuration of a later binary package would match the systems configuration.</div>
<p>In my own testing I've not been able to reproduce any of the caveats described. Shouldn't we remove this note ? <a href="/index.php?title=User:Sdrik&action=edit&redlink=1" class="new" title="User:Sdrik (page does not exist)">Sdrik</a> (<a href="/index.php?title=User_talk:Sdrik&action=edit&redlink=1" class="new" title="User talk:Sdrik (page does not exist)">talk</a>) 15:25, 27 March 2018 (UTC)
</p>
<dl><dd>I'm pretty sure the caveat is still important. You won't run into this unless you're maintaining your own private repositories, and compile two different versions of the same program. --<a href="/wiki/User:Davidbryant" title="User:Davidbryant">Davidbryant</a> (<a href="/wiki/User_talk:Davidbryant" title="User talk:Davidbryant">talk</a>) 14:24, 6 August 2020 (UTC)</dd></dl>
<h2><span id="What_about_compiler_flags_when_-march=native_is_used?"></span><span class="mw-headline" id="What_about_compiler_flags_when_-march.3Dnative_is_used.3F">What about compiler flags when -march=native is used?</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=4" title="Edit section: What about compiler flags when -march=native is used?">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-check fa-fw fa-2x"></span></span><span>This discussion is done as of 6 August 2020.</span></div>
</div>
<p>Am I missing something? building a package and control USE flags is one thing. However, given I have on my hots, i.e. builder machine, -march=native in CFLAGS, it will invoke gcc for its own processor, including processor flags at the stage of compilation. And such a code may be useless on another machine. This should be somehow reflected in the document especially given that the handbook suggests -march=native as the most standard approach. --<a href="/index.php?title=User:Alex-kas&action=edit&redlink=1" class="new" title="User:Alex-kas (page does not exist)">Alex-kas</a> (<a href="/index.php?title=User_talk:Alex-kas&action=edit&redlink=1" class="new" title="User talk:Alex-kas (page does not exist)">talk</a>) 19:41, 2 February 2020 (UTC)
</p>
<dl><dd>Good point. But it's already addressed in "Using Binary Packages":</dd></dl>
<p><b>For binary packages to be usable on other systems they must fulfill some requirements:</b>
</p><p><b>* The client and server architecture and <var><a href="/wiki/CHOST" title="CHOST">CHOST</a></var> must match.<br /><br /></b>
</p>
<dl><dd>Doesn't that answer your question? --<a href="/wiki/User:Davidbryant" title="User:Davidbryant">Davidbryant</a> (<a href="/wiki/User_talk:Davidbryant" title="User talk:Davidbryant">talk</a>) 14:33, 6 August 2020 (UTC)</dd></dl>
<p><br />
</p>
<h2><span class="mw-headline" id="We_should_list_available_bin_package_compression_formats">We should list available bin package compression formats</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=5" title="Edit section: We should list available bin package compression formats">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-check fa-fw fa-2x"></span></span><span>This discussion is done.</span></div>
</div>
<p>Portage supports <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">BINPKG_COMPRESS</span> variable which allows for different compression formats to be used, such as lz4. We should list them all here.
</p><p><a href="/wiki/User:Juippis" title="User:Juippis">Juippis</a> (<a href="/wiki/User_talk:Juippis" title="User talk:Juippis">talk</a>) 13:49, 15 December 2021 (UTC)
</p>
<dl><dd>Thanks for the heads up! Sounds like a very good idea, but I don't use this, so I wouldn't know what to add off the top of my head. I have a project that builds packages though, so I may get a chance to come to this with a bit of knowledge some time.</dd></dl>
<dl><dd>Comments like this are great, because they focus attention on particular changes that need to be made, so someone will surely get around to this eventually. Feel free to make any changes to fix this yourself however, if you know what needs doing, and don't mind: this seems like the sort of change that users will benefit from :).</dd></dl>
<dl><dd>Boilerplate: Remember that no matter if changes aren't perfect, or if the formatting is a bit off, as long as edits make things a bit better, it's a step in the right direction ;). The <a href="/wiki/Gentoo_Wiki:Contributor%27s_guide" title="Gentoo Wiki:Contributor's guide">contributor's guide</a> gives a few tips on how to easily make contributions ;).</dd></dl>
<dl><dd>I will close this discussion soon, if nothing more is added, as this seems like a pretty complete informational comment in and of itself (see <a href="/wiki/Help:Talk_pages#Closing_discussions" title="Help:Talk pages">closing discussions</a>).</dd></dl>
<dl><dd>-- <a href="/wiki/User:Kyoreln" class="mw-redirect" title="User:Kyoreln">Kyoreln</a> (<a href="/wiki/User_talk:Kyoreln" class="mw-redirect" title="User talk:Kyoreln">talk</a>) 14:48, 15 December 2021 (UTC)</dd></dl>
<dl><dd><dl><dd>Done now, I was hoping to get the formats listed here, but they could be found from portage's man page easily after all.</dd>
<dd><a href="/wiki/User:Juippis" title="User:Juippis">Juippis</a> (<a href="/wiki/User_talk:Juippis" title="User talk:Juippis">talk</a>) 08:38, 17 December 2021 (UTC)</dd></dl></dd></dl>
<dl><dd><dl><dd><dl><dd>Fantastic, thanks !! -- <a href="/wiki/User:Ris" title="User:Ris">Ris</a> (<a href="/wiki/User_talk:Ris" title="User talk:Ris">talk</a>) 09:30, 20 February 2022 (UTC)</dd></dl></dd></dl></dd></dl>
<h2><span id="Clarifying_the_information_in_the_"Understanding_the_binary_package_format"_section"></span><span class="mw-headline" id="Clarifying_the_information_in_the_.22Understanding_the_binary_package_format.22_section">Clarifying the information in the "Understanding the binary package format" section</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=6" title="Edit section: Clarifying the information in the "Understanding the binary package format" section">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-clock-o fa-fw fa-2x"></span></span><span>This discussion is still ongoing.</span></div>
</div>
<p>i came to the "Understanding the binary package format" section of this page due to trying to understand the format of the xpak that gets downloaded by the gentoo-kernel-bin ebuild. In that particular case, the compression format is xz, not bz2; but <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">qtbz2</span> can nevertheless be used to split that file into its .tar.xz and the xpak archive components, despite the command name, and despite this not being documented in the man page for <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">qtbz2</span>. Should this section be changed to reflect all this? <a href="/wiki/User:Flexibeast" title="User:Flexibeast">Flexibeast</a> (<a href="/wiki/User_talk:Flexibeast" title="User talk:Flexibeast">talk</a>) 12:52, 9 March 2022 (UTC)
</p>
<dl><dd>Excellent observation. Perhaps the developer of the <span style="white-space: nowrap;" class="plainlinks" title="External link to https://packages.gentoo.org for the sys-kernel/gentoo-kernel-bin package."><a rel="nofollow" class="external text" href="https://packages.gentoo.org/packages/sys-kernel/gentoo-kernel-bin"><span style="font-family: monospace; font-size: 95%; color: MidnightBlue;">sys-kernel/gentoo-kernel-bin</span></a><span style="color: grey; margin-left: 0.1em; font-size: 70% !important;" class="fa fa-hdd-o fa-fw"></span></span> package has set custom compression formats on the build machine that is assembling the package... which was discovered by you as you manually disassembled the package step-by-step. binpkg compression can be changed to support various compression algorithms such as bzip2, gzip, lz4, lzip, lzop, xz, and zstd (search for <var>BINPKG_COMPRESS</var> on the <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">man make.conf</span>) for more information... --<a href="/wiki/User:Maffblaster" title="User:Maffblaster">Maffblaster</a> (<a href="/wiki/User_talk:Maffblaster" title="User talk:Maffblaster">talk</a>) 00:28, 10 March 2022 (UTC)</dd></dl>
<h2><span class="mw-headline" id="Mixing_the_formats_XPAK_and_GPKG">Mixing the formats XPAK and GPKG</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=7" title="Edit section: Mixing the formats XPAK and GPKG">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-clock-o fa-fw fa-2x"></span></span><span>This discussion is still ongoing.</span></div>
</div>
<p>Are there any implications when switching an existing build server to GPKG? Is it enough to configure the format in make.conf? Do clients using the binary packages get along with some as XPAK and others as GPKG? According to this page it does not seem necessary to rebuild all packages to GPKG nor clean XPAK from the packages dir? Is that correct?--<a href="/wiki/User:Onkobu" title="User:Onkobu">Onkobu</a> (<a href="/wiki/User_talk:Onkobu" title="User talk:Onkobu">talk</a>) 15:48, 2 January 2023 (UTC)
</p>
<dl><dd>I don't think there are any implications, as long as all clients support all used formats (GPKG is a newer addition). You should be able to just set the format in make.conf on the server, doing so on the client is not necessary. Clients will use whatever the build server sets in <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">$PKGDIR/Packages</span>. Portage saves the binary package filename separately for each package in <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">$PKGDIR/Packages</span> so it will know which file to use. Rebuilding all packages to the same format is not necessary. After switching file format, the old binary package file will remain until cleaned with <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">eclean packages</span>. <a href="/index.php?title=User:Jjakob&action=edit&redlink=1" class="new" title="User:Jjakob (page does not exist)">Jjakob</a> (<a href="/index.php?title=User_talk:Jjakob&action=edit&redlink=1" class="new" title="User talk:Jjakob (page does not exist)">talk</a>) 15:31, 22 May 2023 (UTC)</dd></dl>
<h2><span class="mw-headline" id="Binary_package_OpenPGP_signing">Binary package OpenPGP signing</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=8" title="Edit section: Binary package OpenPGP signing">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-clock-o fa-fw fa-2x"></span></span><span>This discussion is still ongoing.</span></div>
</div>
<p>I tried to enable this on my machine. I symlinked root's gpg-agent socket to my user's agent extra socket so that root can use my user's gpg smartcard. Imported my gpg public key into root's truststore and set it to ultimate trust. I tried signing some git commits as root and it worked so I know this part works.
Enabled signing by setting
</p>
<div class="box-caption"><span class="label" style="margin-right: .5em; background-color: #54487A">FILE</span> <strong><code style="border: none; background: none; color: #54487A; margin-right: .5em;">"/etc/portage/make.conf"</code></strong><strong></strong></div> <div class="mw-highlight mw-highlight-lang-sh mw-content-ltr" dir="ltr"><pre><span></span><span class="nv">BINPKG_FORMAT</span><span class="o">=</span><span class="s2">"gpkg"</span>
<span class="nv">FEATURES</span><span class="o">=</span><span class="s2">"buildpkg binpkg-signing"</span>
<span class="nv">BINPKG_GPG_SIGNING_GPG_HOME</span><span class="o">=</span><span class="s2">"/root/.gnupg"</span>
<span class="nv">BINPKG_GPG_SIGNING_KEY</span><span class="o">=</span><span class="s2">"my key fingerprint"</span>
</pre></div>
<p>When I run emerge the package is successfully built and signed (I am requested to press the UIF touch button on my key 3 times after the package is built) but then it fails to verify its signature:
</p>
<div class="cmd-box"><div><code style="color: #ef2929; font-weight: bold;">root <span style="color:royalblue;">#</span></code><span class="tripleclick-separator"></span><code>"emerge -1 dev-libs/tree-sitter"</code></div><pre>... cut ...
>>> Completed installing dev-libs/tree-sitter-0.20.8 into /var/tmp/portage/dev-libs/tree-sitter-0.20.8/image
... cut ...
>>> Done.
!!!
gpg: keyblock resource '/etc/portage/gnupg/pubring.kbx': No such file or directory
[GNUPG:] ERROR add_keyblock_resource 33587281
[GNUPG:] PLAINTEXT 74 0
[GNUPG:] NEWSIG
gpg: Signature made Mon 22 May 2023 04:51:16 PM CEST
gpg: using EDDSA key FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERROR keydb_search 33554445
[GNUPG:] ERRSIG 1E936484FFE8BA69 22 10 01 1684767076 9 FE4A3C99DCC974A683D406031E936484FFE8BA69
[GNUPG:] NO_PUBKEY 1E936484FFE8BA69
gpg: Can't check signature: No public key
gpg: can't create `/etc/portage/gnupg/random_seed': No such file or directory
!!! Invalid binary package: '/var/cache/binpkgs/dev-libs/tree-sitter-0.20.8.gpkg.tar.3271', GPG verify failed
Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)
handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7f26fed69c40>>)>
Traceback (most recent call last):
File "/usr/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb
listener(self)
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 49, in _task_exit_handler
self._start_next_task()
File "/usr/lib/python3.11/site-packages/_emerge/TaskSequence.py", line 43, in _start_next_task
self._start_task(task, self._task_exit_handler)
File "/usr/lib/python3.11/site-packages/_emerge/CompositeTask.py", line 112, in _start_task
task.start()
File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line 34, in start
self._start()
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 518, in _start
self.ebuild_build._record_binpkg_info(self.ebuild_binpkg)
File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 560, in _record_binpkg_info
"BINPKGMD5": f"{pkg._metadata['MD5']}\n",
^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute '_metadata'
Terminated
</pre></div>
<p>Is the section missing an instruction to also follow the <a href="/wiki/Binary_package_guide#Verify_binary_package.27s_OpenPGP_signature" title="Binary package guide">Binary_package_guide#Verify_binary_package.27s_OpenPGP_signature</a> section?
Or is my global <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">"USE=verify-sig"</span> causing this?
</p><p><a href="/index.php?title=User:Jjakob&action=edit&redlink=1" class="new" title="User:Jjakob (page does not exist)">Jjakob</a> (<a href="/index.php?title=User_talk:Jjakob&action=edit&redlink=1" class="new" title="User talk:Jjakob (page does not exist)">talk</a>) 15:16, 22 May 2023 (UTC)
</p>
<hr />
<p>I am having the same issue, emerge --info | grep -i home yields :
PORTAGE_GPG_SIGNING_COMMAND="gpg --sign --digest-algo SHA256 --clearsign --yes --default-key "${PORTAGE_GPG_KEY}" --homedir "${PORTAGE_GPG_DIR}" "${FILE}""
</p><p>I didn't see either PORTAGE_GPG_DIR or PORTAGE_GPG_KEY in the environmental variables.
so I created them in the make.conf (this could be a version issue/oversight)
</p><p>Also, I moved the homedir to portage (/var/lib/portage/home), as I use the portage user. After setting the read permissions on 'other' I was able for the process to read trusted.db, and I was able to successfully build a gpkg package. Also, depending on the situation, the .gnupg directory appears to need 'other' accesss, even though emerge uses root. which is weird. anyways.
</p><p>I am happy to allow portage to have it's own gpg home directory/key. And I am avoiding using the root directory for now
Also, if I opt not to have all four (BINPKG or PORTAGE prefixed) variables set, i get errors. during binpkg creation.
</p>
<ul><li><ul><li>ALSO I ADDED :</li></ul></li></ul>
<p>BINPKG_GPG_VERIFY_GPG_HOME=".../.gnupg" ... I have to say, its quite convoluted, perhaps simplifying the gpg variables if its possible, or perhaps just a rewrite in the docs.
</p><p>--ciaran
</p><p><a href="/index.php?title=User:Pcxmac&action=edit&redlink=1" class="new" title="User:Pcxmac (page does not exist)">pcxmac</a> (<a href="/index.php?title=User_talk:Pcxmac&action=edit&redlink=1" class="new" title="User talk:Pcxmac (page does not exist)">talk</a>) 08:32, 13 Oct 2023 (PST)
</p>
<h2><span class="mw-headline" id="gpg-keepalive_feature">gpg-keepalive feature</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=9" title="Edit section: gpg-keepalive feature">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-clock-o fa-fw fa-2x"></span></span><span>This discussion is still ongoing.</span></div>
</div>
<p>I have tried to gpg-keepalive feature, and it does not seem to work. If the compilation last too long, the GPG passphrase is again asked at the end. If I type it, it appears in clear text. Then if I type enter, it hangs, the binary package is not created and the package is not installed.
Any idea on this ?--
<a href="/index.php?title=User:FrancoisVal&action=edit&redlink=1" class="new" title="User:FrancoisVal (page does not exist)">FrancoisVal</a> (<a href="/index.php?title=User_talk:FrancoisVal&action=edit&redlink=1" class="new" title="User talk:FrancoisVal (page does not exist)">talk</a>) 13:34, 5 January 2024 (CET)
</p>
<dl><dd>Have you tried contacting <a href="/wiki/Support" title="Support">support</a>, <a href="/index.php?title=User:FrancoisVal&action=edit&redlink=1" class="new" title="User:FrancoisVal (page does not exist)">FrancoisVal <i class="fa fa-user"></i></a> ? If you find a way to fix this, please do <a href="/wiki/What_to_do_when_noticing_an_error_on_the_wiki" title="What to do when noticing an error on the wiki">add a tip or troubleshoot entry to the article</a> so that future readers can avoid the issue :) -- <a href="/wiki/User:Ris" title="User:Ris">Ris</a> (<a href="/wiki/User_talk:Ris" title="User talk:Ris">talk</a>) 08:46, 2 March 2024 (UTC)</dd></dl>
<h2><span id=""chroot"_and_"cross-compile"_not_enough_for_my_(common_?)_use_case"></span><span class="mw-headline" id=".22chroot.22_and_.22cross-compile.22_not_enough_for_my_.28common_.3F.29_use_case">"chroot" and "cross-compile" not enough for my (common ?) use case</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=10" title="Edit section: "chroot" and "cross-compile" not enough for my (common ?) use case">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<h3><span class="mw-headline" id="Feel_free_to_reopen">Feel free to reopen</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=11" title="Edit section: Feel free to reopen">edit source</a><span class="mw-editsection-bracket">]</span></span></h3>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-check fa-fw fa-2x"></span></span><span>This discussion is done.</span></div>
</div>
<p>My use case is that I want to build on amd64 for amd64 but with completely different cpu features.
Sometimes the target has features that are not on the host.<br />
I know about these 3 ways :
</p>
<ol><li>crosscompiling with emerge-x86_64-mycustomtargetname-linux-gnu instead of emerge-x86_64-pc-linux-gnu (made by crossdev)</li>
<li>emerge --root=/usr/mycustomtargetname/ --sysroot=/usr/mycustomtargetname</li>
<li>chroot</li></ol>
<p>The problems I had:
</p>
<ul><li>with 1. : crossdev refused to build a cross compiler with the same tuple (emerge-x86_64-pc-linux-gnu). Then I used another tuple like : cross-x86_64-mycustomtargetname-linux-gnu-gcc</li></ul>
<ul><li>with 2. : some packages built with the wrong flags and illegal instructions were embedded. I think sqlite was the culprit.</li></ul>
<ul><li>with 3. : what is described under point 8. "What Goes Wrong" here in this article: <a href="/wiki/User:NeddySeagoon/Build_In_A_Chroot" title="User:NeddySeagoon/Build In A Chroot">User:NeddySeagoon/Build_In_A_Chroot</a></li></ul>
<p>Way 1 seems to work.
My hope is that the packages respect the flags more strictly if they think
that they are cross-compiling because the CHOST and CBUILD tuples are different
with way 1.
For the binpkgs to be accepted by the target host I also had to change the target hosts
CHOST. But this worked like so: <a href="/wiki/Changing_the_CHOST_variable" title="Changing the CHOST variable">Changing_the_CHOST_variable</a><br /><br />
Way 1 is the only way I found to do this.<br /><br />
A nice side effect of this approach is that it automatically refuses to install packages with the wrong cflags/opcodes, because of the different CHOST.
</p><p>Isn't this a somewhat common use case ?
<br /><a href="/index.php?title=User:Alexander-n8hgeg5e&action=edit&redlink=1" class="new" title="User:Alexander-n8hgeg5e (page does not exist)">Alexander-n8hgeg5e</a> (<a href="/index.php?title=User_talk:Alexander-n8hgeg5e&action=edit&redlink=1" class="new" title="User talk:Alexander-n8hgeg5e (page does not exist)">talk</a>) 16:03, 29 February 2024 (UTC)<br />
Now I figured out that some packages like dev-libs/gobject-introspection<br />
refuse to cross-compile.<br />
I guess "Way 3" but inside a virtual machine is the prevailing method.<br />
I think it should be mentioned in the article.
<br /><a href="/index.php?title=User:Alexander-n8hgeg5e&action=edit&redlink=1" class="new" title="User:Alexander-n8hgeg5e (page does not exist)">Alexander-n8hgeg5e</a> (<a href="/index.php?title=User_talk:Alexander-n8hgeg5e&action=edit&redlink=1" class="new" title="User talk:Alexander-n8hgeg5e (page does not exist)">talk</a>) 16:03, 29 February 2024 (UTC)<br />
</p>
<dl><dd>I don't think it's possible to use a chroot with CPU functions that are not available on the host. Me, personally, I've just started to use a chroot on an amd64 Ryzen Arch Linux as host (would be march=znver3, but since it's Arch it's actually x86-64 baseline), the target is an amd64 Intel Core i-3000 Gentoo (march=ivybridge). All the functions that the chrooted environment use are available on the host, even though one is Intel and one is AMD, because the Intel arch is so much older. At least I hope that that's the case, but so far everything worked.</dd>
<dd>If both systems are AMD64, the CHOST should be identical anyways: x86_64-pc-linux-gnu. I would recommend to step down to the lowest CFLAGS on the target system that is also supported by the host. psABI architecture levels also come to mind, as in e.g. x86-64-v2. Ubuntu has a blog page that sums this up nicely, <a rel="nofollow" class="external text" href="https://ubuntu.com/blog/optimising-ubuntu-performance-on-amd64-architecture">here</a>. GCC uses them with <a rel="nofollow" class="external text" href="https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html">option -march=</a>, so in your target system's /etc/portage/make.conf you'd use CFLAGS="-march=x86-64-v2". Or -v3 or none, just "x86-64", whatever both systems support.</dd>
<dd>I tried crossdev (cross-compiling) once on an amd64 host for a ppc64 target, but I couldn't make it work.</dd>
<dd><a href="/wiki/User:Luttztfz" title="User:Luttztfz">Luttztfz</a> (<a href="/index.php?title=User_talk:Luttztfz&action=edit&redlink=1" class="new" title="User talk:Luttztfz (page does not exist)">talk</a>) 20:46, 29 February 2024 (UTC)
<dl><dd>Hm, I think you are right. Now after reading your comment I think way 3(chroot) and way 2(emerge --root= --syroot=) is the usual approach if you are on the same architecture like amd64.</dd>
<dd>The virtual machine seems not to be the solution because the vm could have a big performance problem if it had to emulate a feature inside the chroot.</dd>
<dd>I got very far with this cross compile approach. In one instance it compiled the whole system (ceph node) and only one package (scipy) had to be compiled on the target. But I couldn't automatically fetch the package back to the subtree (/usr/x86_64-mycustomtargetname-linux-gnu) because portage refused somehow to use a binhost declared inside the subtree.</dd>
<dd>I used the same profile and everything as on the target and somehow I had to recompile cross-x86_64-something-linux-gnu/gcc a few times.</dd>
<dd><a href="/index.php?title=User:Alexander-n8hgeg5e&action=edit&redlink=1" class="new" title="User:Alexander-n8hgeg5e (page does not exist)">Alexander-n8hgeg5e</a> (<a href="/index.php?title=User_talk:Alexander-n8hgeg5e&action=edit&redlink=1" class="new" title="User talk:Alexander-n8hgeg5e (page does not exist)">talk</a>) 23:51, 1 March 2024 (UTC)</dd></dl></dd></dl>
<dl><dd><dl><dd><dl><dd>Looks like you might get more help from <a href="/wiki/Support" title="Support">support</a>, <a href="/index.php?title=User:Alexander-n8hgeg5e&action=edit&redlink=1" class="new" title="User:Alexander-n8hgeg5e (page does not exist)">Alexander-n8hgeg5e <i class="fa fa-user"></i></a>. If you manage to find out the best way to cross compile for your use, please do <a href="/wiki/What_to_do_when_noticing_an_error_on_the_wiki" title="What to do when noticing an error on the wiki">make the article more clear</a> for everyone else :) -- <a href="/wiki/User:Ris" title="User:Ris">Ris</a> (<a href="/wiki/User_talk:Ris" title="User talk:Ris">talk</a>) 08:42, 2 March 2024 (UTC)</dd></dl></dd></dl></dd></dl>
<p><br />
</p>
<h2><span class="mw-headline" id="Verify_binary_package_OpenPGP_signatures">Verify binary package OpenPGP signatures</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Talk:Binary_package_guide&action=edit&section=12" title="Edit section: Verify binary package OpenPGP signatures">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<div id="infobox-stack" class="list-group" style="width: 25em; float: right; clear: right; font-size: 90%; margin-left: 1em;">
<div class="list-group-item text-center" style="padding-top: 3px; padding-bottom: 3px; background-color: #463C65; color: white;"><b>Talk status</b></div>
<div id="infobox" class="list-group-item" style="display: flex; align-items: center; padding: 5px; min-height: 3em;"><span style="display: inline-block; width: 3em; overflow: hidden; text-align: center;"><span class="fa fa-clock-o fa-fw fa-2x"></span></span><span>This discussion is still ongoing.</span></div>
</div>
<p>I think this section should provide a recommended package and therefore this paragraph:
</p>
<pre> 1. Generate (or use an existing) key with signing abilities, and export the public key to a file.
</pre>
<p>might be altered to state (perhaps including a colorized console consistent with this page's style):
</p>
<pre> 1. If you do not have an existing key with signing abilities, emerge app-crypt/gnupg and then generate a key. See <a rel="nofollow" class="external free" href="https://wiki.gentoo.org/wiki/GnuPG">https://wiki.gentoo.org/wiki/GnuPG</a>.
</pre>
<p><a href="/wiki/User:Jlpoole" title="User:Jlpoole">Jlpoole</a> (<a href="/wiki/User_talk:Jlpoole" title="User talk:Jlpoole">talk</a>) 02:17, 30 March 2024 (UTC)
</p>
' |
Unix timestamp of change (timestamp) | 1711765053 |