Re: [gentoo-dev] Managing updates on many identical Gentoo systems
On Thu, 1970-01-01 at 00:00 +, Anthony G. Basile wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > Hi everyone, > > I'm trying to design an update system for many identical Gentoo systems. > Using a binhost is obvious, but there are still problems with this > approach. > > Unless there's some magic I don't know about (and this is why I'm > sending this email) each machine still needs to have the portage tree > installed locally (1.5 GB) or somehow mounted by a network filesystem > (which is not practical if the machines are not on a local network). > Furthermore, each machine would have to run emerge locally to do the > calculation of what packages need updating. > > This procedure is redundant because each machine is housing the same > data and doing the same dependence-tree calculation. It should be > possible to do this calculation on a centralized binhost and simply > communicate the update information to the remote machines. They would > then only have to download the .tbz2's and install them, keeping a tidy > /var/db/pkg. Thus they avoid having to house the portage tree and > burning cpu cycles that just calculate redundant information. > > I'm inspired here by OpenBSD's pkg_add which doesn't require all of > ports to be installed, and mender which is a > > Any ideas? No ideas but I am interested in solutions. I am thinking/looking at updating embedded devices. Also, I guess you have the common problem with changes in /etc/ files which needs to be kept in sync. Jocke
Re: [gentoo-dev] EAPI 7 can be used in the Gentoo repository
Great news :) W.r.t the new support for cross building, it would be grep if the eclass user could make use of the new --prefix support in recent shadow utilities so users can be added to cross ROOT. Jocke On Sun, 2018-05-06 at 18:52 +0200, Ulrich Mueller wrote: EAPI 7 has been approved by the Council one week ago [1]. The latest Portage version in ~arch (2.3.36) supports it, and the Infra team has upgraded the rsync master so that metadata cache generation will work correctly. Therefore, EAPI 7 ebuilds can be committed to the Gentoo repository from now on. (Make sure that all inherited eclasses are supporting the new EAPI, though.) Some pointers to documentation: - Package Manager Specification, in PDF and HTML format: https://projects.gentoo.org/pms/latest/ or install ~app-doc/pms-7_p20180430 - List of changes in EAPI 7: https://projects.gentoo.org/pms/7/pms.html#x1-179000E - EAPI Cheat Sheet (print out, and fold to a leaflet): https://projects.gentoo.org/pms/7/eapi-cheatsheet.pdf - mgorny's (unofficial) guide: https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html Ulrich [1] https://bugs.gentoo.org/654262
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
On Fri, 2016-05-27 at 18:21 -0400, NP-Hardass wrote: > On 05/27/2016 06:05 PM, Daniel Campbell wrote: > > On 05/27/2016 02:45 PM, NP-Hardass wrote: > > > Not on hand, but as the MATE maintainer, I can tell you that starting > > > with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four > > > more are. > > > > > > > > Aha, thanks for offering that info. Which ones if you don't mind? > > > in 1.14 x11-misc/mozo and mate-extra/mate-system-monitor. Don't have > the 1.16 ones handy as I haven't been able to work on it the last week > (more hw issues) > NP, there are 2 patches floating on the MATE ml that move the dependency on sys-power/upower-pm-utils consolekit(suspend/resume is handled by consolekit instead). Wold you be interested to add those to gentoo MATE? Jocke
[gentoo-dev] Bug 548208 - net-fs/nfs-utils: enable gssproxy support (to replace rpc-svcgssd) seems forgotten?
Could someone from core systems look at https://bugs.gentoo.org/show_bug.cgi?id=548208 and "unbreak" unstable nfs-utils for openrc, please? Jocke
[gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in
I know this might be a bit off topic but I just want some clues Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to "(null)". This creates a /(null) dir. with various stuff in it. I am trying to find out what sets XDG_RUNTIME_DIR? We auth. against Windows AD using sssd, but root is a local UNIX user only(not in AD) Any clues? Jocke
Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in
On Wed, 2016-10-05 at 23:10 +0800, Jason Zaman wrote: > On Wed, Oct 05, 2016 at 02:58:20PM +0000, Joakim Tjernlund wrote: > > > > I know this might be a bit off topic but I just want some clues > > > > Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to > > "(null)". This > > creates a /(null) dir. with various stuff in it. > > > > I am trying to find out what sets XDG_RUNTIME_DIR? > its https://bugs.gentoo.org/585688 > fixed in sys-auth/consolekit-1.1.0-r1 > > I'd forgotten to update the stablereq to that, will do it now. Ah, I see that now. Thou after installing sys-auth/consolekit-1.1.0-r1 I get XDG_RUNTIME_DIR but no the directory is not created for root, seems to be fixed by: https://github.com/ConsoleKit2/ConsoleKit2/commit/664d2fdbd966764836b1f4da2dbc5750c7f01f0f
Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in
On Thu, 2016-10-06 at 00:04 +0800, Jason Zaman wrote: > On Wed, Oct 05, 2016 at 03:58:44PM +0000, Joakim Tjernlund wrote: > > > > On Wed, 2016-10-05 at 23:10 +0800, Jason Zaman wrote: > > > > > > On Wed, Oct 05, 2016 at 02:58:20PM +, Joakim Tjernlund wrote: > > > > > > > > > > > > I know this might be a bit off topic but I just want some clues > > > > > > > > Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to > > > > "(null)". This > > > > creates a /(null) dir. with various stuff in it. > > > > > > > > I am trying to find out what sets XDG_RUNTIME_DIR? > > > its https://bugs.gentoo.org/585688 > > > fixed in sys-auth/consolekit-1.1.0-r1 > > > > > > I'd forgotten to update the stablereq to that, will do it now. > > > > Ah, I see that now. > > Thou after installing sys-auth/consolekit-1.1.0-r1 I get XDG_RUNTIME_DIR > > but no the directory is not created for root, seems to be fixed by: > > https://github.com/ConsoleKit2/ConsoleKit2/commit/664d2fdbd966764836b1f4da2dbc5750c7f01f0f > > Yep, that patch is what the -r1 bump was for. Did you remember to > restart consolekit after updating? > ehh, no. It worked after a restart(but I had to manually kill the daemon first)
Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in
On Thu, 2016-10-06 at 00:18 +0800, konsolebox wrote: > On Wed, Oct 5, 2016 at 10:58 PM, Joakim Tjernlund > wrote: > > > > Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to > > "(null)". This > > creates a /(null) dir. with various stuff in it. > > > > I am trying to find out what sets XDG_RUNTIME_DIR? > > It's pam_ck_connector.so. Also see > https://bugs.gentoo.org/show_bug.cgi?id=588840 for details. > Got it and consolekit-1.1.0-r1 works around the issue. Thanks
[gentoo-dev] Mirrors corrupts?
Tried several mirrors and I still get:
gentoo-jocke gentoo64 # emerge -avNDuv world
[ebuild U ] x11-libs/libX11-1.6.4 [1.6.3] USE="ipv6 -doc -static-libs
{-test}" ABI_X86="32 (64) (-x32)"
[ebuild U ] x11-libs/libXfixes-5.0.3 [5.0.2] USE="-static-libs"
ABI_X86="(64) -32 (-x32)"
[ebuild U ] x11-libs/libXrender-0.9.10 [0.9.9] USE="-static-libs"
ABI_X86="32 (64) (-x32)"
[ebuild U ] x11-libs/libXi-1.7.7 [1.7.6] USE="-doc -static-libs"
ABI_X86="(64) -32 (-x32)"
[ebuild U ] x11-libs/libXrandr-1.5.1 [1.5.0] USE="-static-libs"
ABI_X86="(64) -32 (-x32)"
[ebuild U ] x11-libs/libXv-1.0.11 [1.0.10] USE="-static-libs" ABI_X86="(64)
-32 (-x32)"
[ebuild U ] x11-libs/libXtst-1.2.3 [1.2.2] USE="-doc -static-libs"
ABI_X86="(64) -32 (-x32)"
[ebuild U ] sys-apps/man-pages-4.07 [4.06] USE="nls" L10N="-da -de -fr -it
-ja -nl -pl -ro -ru -zh-CN"
[ebuild U ] net-wireless/wpa_supplicant-2.6 [2.5-r2] USE="dbus gnutls hs2-0
qt4 readline ssl -ap -eap-sim
-fasteap (-libressl) -p2p (-ps3) -qt5 (-selinux) -smartcard -tdls
-uncommon-eap-types (-wimax) -wps"
Would you like to merge these packages? [Yes/No]
>>> Verifying ebuild manifests
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libX11/libX11-1.6.4.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 1619
!!! Expected: 1620
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXfixes/libXfixes-5.0.3.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 709
!!! Expected: 710
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXrender/libXrender-0.9.10.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 649
!!! Expected: 650
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXi/libXi-1.7.7.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 973
!!! Expected: 974
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXrandr/libXrandr-1.5.1.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 798
!!! Expected: 799
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXv/libXv-1.0.11.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 669
!!! Expected: 670
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXtst/libXtst-1.2.3.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 831
!!! Expected: 832
!!! Digest verification failed:
!!! /usr/portage/net-wireless/wpa_supplicant/wpa_supplicant-2.6.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 10295
!!! Expected: 10296
>>> Emerging (1 of 9) x11-libs/libX11-1.6.4::gentoo
>>> Jobs: 0 of 9 complete, 1 runningLoad avg: 0.77, 0.36, 0.22
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libX11/libX11-1.6.4.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 1619
!!! Expected: 1620
>>> Failed to emerge x11-libs/libX11-1.6.4
>>> Jobs: 0 of 9 complete, 1 failed Load avg: 0.77, 0.36, 0.22
*** Resuming merge...
>>> Emerging (1 of 8) x11-libs/libXfixes-5.0.3::gentoo
>>> Jobs: 0 of 8 complete, 1 runningLoad avg: 0.73, 0.37, 0.22
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXfixes/libXfixes-5.0.3.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 709
!!! Expected: 710
>>> Failed to emerge x11-libs/libXfixes-5.0.3
>>> Jobs: 0 of 8 complete, 1 failed Load avg: 0.73, 0.37, 0.22
*** Resuming merge...
>>> Emerging (1 of 7) x11-libs/libXrender-0.9.10::gentoo
>>> Jobs: 0 of 7 complete, 1 runningLoad avg: 0.78, 0.39, 0.23
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXrender/libXrender-0.9.10.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 649
!!! Expected: 650
>>> Failed to emerge x11-libs/libXrender-0.9.10
Re: [gentoo-dev] Mirrors corrupts?
On Sat, 2016-10-08 at 18:07 +0200, Jeroen Roovers wrote: > On Sat, 8 Oct 2016 14:52:13 + > Joakim Tjernlund wrote: > > > > > Tried several mirrors and I still get: > > > https://bugs.gentoo.org/show_bug.cgi?id=596462 Thanks, I added myself to CC list
Re: [gentoo-dev] grub-2 configuration
On Tue, 2016-10-18 at 12:45 -0400, Tom H wrote: > On Tue, Oct 11, 2016 at 10:54 AM, M. J. Everitt wrote: > > > > On 11/10/16 15:42, Tom H wrote: > > > > > > > > > You can use exactly the same text in 40_grub that you'd use in > > > grub.cfg and have the latter generated. > > > > That's a useful tit-bit .. thanks! > > You're welcome. > > I doubt that the grub developers intended 40_custom to be the only > "/etc/grub.d/" file to be executed but it's practical for generating a > simple grub.cfg. This is what I use in a Debian VM: > We still use grub-1 and I really like the automatic generation of new grub menu entries using genkernel --bootloader=grub, does this work with grub2 as well? Jocke
Re: [gentoo-dev] grub-2 configuration
On Wed, 2016-10-19 at 15:21 -0400, Tom H wrote:
> On Tue, Oct 18, 2016 at 1:20 PM, Joakim Tjernlund
> wrote:
> >
> > On Tue, 2016-10-18 at 12:45 -0400, Tom H wrote:
> > >
> > > On Tue, Oct 11, 2016 at 10:54 AM, M. J. Everitt
> > > wrote:
> > > >
> > > > On 11/10/16 15:42, Tom H wrote:
> > > > >
> > > > >
> > > > > You can use exactly the same text in 40_grub that you'd use in
> > > > > grub.cfg and have the latter generated.
> > > >
> > > > That's a useful tit-bit .. thanks!
> > >
> > > You're welcome.
> > >
> > > I doubt that the grub developers intended 40_custom to be the only
> > > "/etc/grub.d/" file to be executed but it's practical for generating a
> > > simple grub.cfg. This is what I use in a Debian VM:
> >
> > We still use grub-1 and I really like the automatic generation of new
> > grub menu entries using genkernel --bootloader=grub, does this work
> > with grub2 as well?
>
> It looks ike you can pass "--bootloader=grub2" but it's not documented
> in the man page because gen_bootloader.sh has:
OK, good.
>
> set_bootloader() {
> case "${BOOTLOADER}" in
> grub)
> set_bootloader_grub
> ;;
> grub2)
> set_bootloader_grub2
> ;;
> *)
> print_warning "Bootloader ${BOOTLOADER} is not currently supported"
> ;;
> esac
> }
>
> but it looks like, unlike for grub-legacy, you need a grub config file
> ("/boot/grub{,2}/grub.cfg") to exist.
That is reasonable, to create a new entry one needs to copy the previous and
replace the
kernel.
Would be nice if someone could confirm this though.
Jocke
[gentoo-dev] LLVM News item
Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read: .. In order to enable all targets, add the following to your /etc/portage/package.use or equivalent file: sys-devel/llvm LLVM_TARGETS: * sys-devel/clang LLVM_TARGETS: * ... I would like to control such variables(LLVM_TARGETS) through the profile as well but it seems not supported? Jocke
Re: [gentoo-dev] LLVM News item
On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote: > On Tue, 25 Oct 2016 17:32:22 + > Joakim Tjernlund wrote: > > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read: > > .. > > In order to enable all targets, add the following to your > > /etc/portage/package.use or equivalent file: > > > > sys-devel/llvm LLVM_TARGETS: * > > sys-devel/clang LLVM_TARGETS: * > > ... > > > > I would like to control such variables(LLVM_TARGETS) through the profile as > > well but it seems not supported? > > Why not? We're already setting the defaults in profiles, and you can do > whatever you want in your own profile. The news item is focused on > regular users, so it covers the usual configuration files rather than > creating custom profiles. > How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) I just tested to add: # > svn diff Index: package.use === --- package.use (revision 1087) +++ package.use (working copy) @@ -1,3 +1,6 @@ +sys-devel/llvm LLVM_TARGETS: * +sys-devel/clang LLVM_TARGETS: * Then I get: # > emerge -aNDuv world --- Invalid USE flag for 'sys-devel/llvm' in '/var/lib/layman/transmode/profiles/gentoo64/package.use': 'LLVM_TARGETS:' --- Invalid USE flag for 'sys-devel/llvm' in '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*' --- Invalid USE flag for 'sys-devel/clang' in '/var/lib/layman/transmode/profiles/gentoo64/package.use': 'LLVM_TARGETS:' --- Invalid USE flag for 'sys-devel/clang' in '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
Re: [gentoo-dev] LLVM News item
On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote: > On 25/10/16 03:32 PM, Ian Stakenvicius wrote: > > > > On 25/10/16 03:08 PM, Joakim Tjernlund wrote: > > > > > > On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote: > > > > > > > > On Tue, 25 Oct 2016 17:32:22 + > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and > > > > > read: > > > > > .. > > > > > In order to enable all targets, add the following to your > > > > > /etc/portage/package.use or equivalent file: > > > > > > > > > > sys-devel/llvm LLVM_TARGETS: * > > > > > sys-devel/clang LLVM_TARGETS: * > > > > > ... > > > > > > > > > > I would like to control such variables(LLVM_TARGETS) through the > > > > > profile as > > > > > well but it seems not supported? > > > > > > > > Why not? We're already setting the defaults in profiles, and you can do > > > > whatever you want in your own profile. The news item is focused on > > > > regular users, so it covers the usual configuration files rather than > > > > creating custom profiles. > > > > > > > > > > How? in my profile(which inherits > > > gentoo:default/linux/amd64/13.0/desktop) I just tested to add: > > > # > svn diff > > > Index: package.use > > > === > > > --- package.use (revision 1087) > > > +++ package.use (working copy) > > > @@ -1,3 +1,6 @@ > > > +sys-devel/llvm LLVM_TARGETS: * > > > +sys-devel/clang LLVM_TARGETS: * > > > > > > Then I get: > > > # > emerge -aNDuv world > > > --- Invalid USE flag for 'sys-devel/llvm' in > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > 'LLVM_TARGETS:' > > > --- Invalid USE flag for 'sys-devel/llvm' in > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > '*' > > > --- Invalid USE flag for 'sys-devel/clang' in > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > 'LLVM_TARGETS:' > > > --- Invalid USE flag for 'sys-devel/clang' in > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > '*' > > > > > > > Syntax error: > > > > sys-devel/llvm llvm_targets_firstone llvm_targets_secondone .. > > sys-devel/clang llvm_targets_firstone llvm_targets_secondone .. This is standard USE flags, not the VAR: x y z syntax > > > > > > You can't specify wildcards to enable groups of use flags. > > > > > > Correction, the earlier syntax *is* supposed to work (and tested that > it works here, with VIDEO_CARDS).. If I had to guess this probably > relates to an issue with the transmode overlay. > Hmm, are you saying that you can write: x11-base/xorg-drivers VIDEO_CARDS: intel radeon in your profile? Any idea what my issue might be? Jocke
Re: [gentoo-dev] LLVM News item
On Tue, 2016-10-25 at 16:07 -0400, Ian Stakenvicius wrote: > On 25/10/16 04:02 PM, Joakim Tjernlund wrote: > > > > On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote: > > > > > > On 25/10/16 03:32 PM, Ian Stakenvicius wrote: > > > > > > > > > > > > On 25/10/16 03:08 PM, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote: > > > > > > > > > > > > > > > > > > On Tue, 25 Oct 2016 17:32:22 + > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item > > > > > > > and read: > > > > > > > .. > > > > > > > In order to enable all targets, add the following to your > > > > > > > /etc/portage/package.use or equivalent file: > > > > > > > > > > > > > > sys-devel/llvm LLVM_TARGETS: * > > > > > > > sys-devel/clang LLVM_TARGETS: * > > > > > > > ... > > > > > > > > > > > > > > I would like to control such variables(LLVM_TARGETS) through the > > > > > > > profile as > > > > > > > well but it seems not supported? > > > > > > > > > > > > Why not? We're already setting the defaults in profiles, and you > > > > > > can do > > > > > > whatever you want in your own profile. The news item is focused on > > > > > > regular users, so it covers the usual configuration files rather > > > > > > than > > > > > > creating custom profiles. > > > > > > > > > > > > > > > > How? in my profile(which inherits > > > > > gentoo:default/linux/amd64/13.0/desktop) I just tested to add: > > > > > # > svn diff > > > > > Index: package.use > > > > > === > > > > > --- package.use (revision 1087) > > > > > +++ package.use (working copy) > > > > > @@ -1,3 +1,6 @@ > > > > > +sys-devel/llvm LLVM_TARGETS: * > > > > > +sys-devel/clang LLVM_TARGETS: * > > > > > > > > > > Then I get: > > > > > # > emerge -aNDuv world > > > > > --- Invalid USE flag for 'sys-devel/llvm' in > > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > > > 'LLVM_TARGETS:' > > > > > --- Invalid USE flag for 'sys-devel/llvm' in > > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > > > '*' > > > > > --- Invalid USE flag for 'sys-devel/clang' in > > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > > > 'LLVM_TARGETS:' > > > > > --- Invalid USE flag for 'sys-devel/clang' in > > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use': > > > > > '*' > > > > > > > > > > > > > Syntax error: > > > > > > > > sys-devel/llvm llvm_targets_firstone llvm_targets_secondone .. > > > > sys-devel/clang llvm_targets_firstone llvm_targets_secondone .. > > > > This is standard USE flags, not the VAR: x y z syntax > > > > > > > > > > > > > > > > > > > > > You can't specify wildcards to enable groups of use flags. > > > > > > > > > > > > > > Correction, the earlier syntax *is* supposed to work (and tested that > > > it works here, with VIDEO_CARDS).. If I had to guess this probably > > > relates to an issue with the transmode overlay. > > > > > > > Hmm, are you saying that you can write: > > x11-base/xorg-drivers VIDEO_CARDS: intel radeon > > in your profile? > > > > Any idea what my issue might be? > > > > Jocke > > > > In my profile as in /etc/portage/package.use/ , yes. Specifically I > tested VIDEO_CARDS: * I thought it was obvious that I was referring to a custom profile as in eselect profile .. > > I *didn't* try to mess with my in-repo profile though. Given that > repositories may well need to follow PMS, and the USE_EXPAND: * syntax > is a portage'ism, this is why they are being rejected in the > transmode-overlay case. I certainly can't find an example of this > syntax in the gentoo repo. Portage supports lots more than PMS as is, should we remove that? Just because something is supported in portage, you don't have to use it in official repos. Our overlay is used to maintain all the linux computers we have here and /etc/portage is the individual using a particular computer. It would be nice if portage, in general, supported the same features/syntax as /etc/portage does. Jocke
Re: [gentoo-dev] grub-2 configuration
On Thu, 2016-10-20 at 11:03 -0400, Tom H wrote:
> On Wed, Oct 19, 2016 at 4:43 PM, Joakim Tjernlund
> wrote:
> >
> > On Wed, 2016-10-19 at 15:21 -0400, Tom H wrote:
> > >
> > >
> > > but it looks like, unlike for grub-legacy, you need a grub config file
> > > ("/boot/grub{,2}/grub.cfg") to exist.
> >
> > That is reasonable, to create a new entry one needs to copy the previous
> > and replace the
> > kernel.
> >
> > Would be nice if someone could confirm this though.
>
> if [[ -z "${GRUB_CONF}" ]]; then
> print_error 1 "Error! Grub2 configuration file does not exist, please
> ensure grub2 is correctly setup first."
> return 0
> fi
Tried to make grub2 and EFI work on a HP Skylake laptop but failed. This laptop
PXE boots linux
during install in BIOS mode so no EFI vars etc. available when installing grub2.
Is this an impossible combo? Do I need to EFI boot in order to install grub2
efi?
Jocke
Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls
On Tue, 2016-12-27 at 00:22 -0800, Daniel Campbell wrote:
> On 12/26/2016 12:22 PM, Mike Gilbert wrote:
> > Bug: https://bugs.gentoo.org/603776
> > ---
> > eclass/toolchain.eclass | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> > index 55249b00249b..97511ee12440 100644
> > --- a/eclass/toolchain.eclass
> > +++ b/eclass/toolchain.eclass
> > @@ -2119,13 +2119,13 @@
> >
> > do_gcc_config() {
> > if ! should_we_gcc_config ; then
> > - env -i ROOT="${ROOT}" gcc-config --use-old --force
> > + env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old
> > --force
> > return 0
> > fi
> >
> > local current_gcc_config target
> >
> > - current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET}
> > 2>/dev/null)
> > + current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config
> > -c ${CTARGET} 2>/dev/null)
> > if [[ -n ${current_gcc_config} ]] ; then
> > local current_specs use_specs
> > # figure out which specs-specific config is active
> > @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
> > # if the current config is invalid, we definitely want a new one
> > # Note: due to bash quirkiness, the following must not be 1 line
> > local curr_config
> > - curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) ||
> > return 0
> > + curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c
> > ${CTARGET} 2>&1) || return 0
> >
> > # if the previously selected config has the same major.minor (branch) as
> > # the version we are installing, then it will probably be uninstalled
> > # for being in the same SLOT, make sure we run gcc-config.
> > - local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S
> > ${curr_config} | awk '{print $2}')
> > + local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}"
> > gcc-config -S ${curr_config} | awk
> > '{print $2}')
> >
> > local curr_branch_ver=$(get_version_component_range 1-2
> > ${curr_config_ver})
> >
> >
>
> Seems like an obvious bug and fix; is there any reason passing CHOST
> around might be a bad idea? It seems to me that it enforces the behavior
> it's meant to have to begin with and makes it more obvious that CHOST is
> used.
Will that work for cross toolchains well?
Jocke
Re: [gentoo-dev] [PATCH 3/4] dev-util/jenkins-bin: bump to v2.204.1
On Wed, 2019-12-25 at 16:11 +0100, Thomas Deutschmann wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> Package-Manager: Portage-2.3.82, Repoman-2.3.20
> Signed-off-by: Thomas Deutschmann
> ---
> dev-util/jenkins-bin/Manifest | 1 +
> .../jenkins-bin/jenkins-bin-2.204.1.ebuild| 47 +++
> 2 files changed, 48 insertions(+)
> create mode 100644 dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
>
> diff --git a/dev-util/jenkins-bin/Manifest b/dev-util/jenkins-bin/Manifest
> index 39d97b60d3e..854cbb4f581 100644
> --- a/dev-util/jenkins-bin/Manifest
> +++ b/dev-util/jenkins-bin/Manifest
> @@ -2,4 +2,5 @@ DIST jenkins-bin-2.190.1.war 78245883 BLAKE2B
> 6c80eaebc6fe34e2c889c78a34dfc3e105
> DIST jenkins-bin-2.190.2.war 78243424 BLAKE2B
> 7a6bd4cf1c070ce3a09fb84b3dbe7e87f474f4254dd4b4fcffdd7dedf7d4c2ba91d8783e727321439bfeb02da721e4d539cba76312c21b523a9bf336a964
> SHA512
> b1f59ef10dfdfda06bedbf9a40a9e83e159b44b2b5574cba4d62547294386224f64d856490fd4477fb3300a4119d17fc284819719218dfcf32d3dc20ce468847
> DIST jenkins-bin-2.190.3.war 78247363 BLAKE2B
> 99d4c13236b4b4f7308c7993033d1e5f9dd2fd9926febf52ffdacea595fecaba0d0eb8962761d8a6f983eaf9738f8be1ba4df785bb2fe6b613ac8cadcc618e23
> SHA512
> 4ffa2ce3be4d55f0df8021026115d9ce8f1d0f4faa16eaf9f327ce17105f61731730c2a0124fb9af5d8c16c8fee9200f9b785b23856896e292a19f5404a9d2c2
> DIST jenkins-bin-2.197.war 78309466 BLAKE2B
> c3d34c6fc40a82148eafa978c8787375ece6522d0d936b42f0296ee13cd084669bfa31975c0ad27816bdd4c1266cb066c0909774199a1373661a7ec524c06e91
> SHA512
> 3b6a00dee5aeb8a94c8f75323c2469b54fe96d90bf8371898e41dc5bdecaa472f112bff1466481c66c9c7a07b22cbe799a08e45ac486d68fd5bdc7c20d43d722
> +DIST jenkins-bin-2.204.1.war 63433755 BLAKE2B
> 53cb254ddf3b59e083b564adf8d5696c61012e6d0d26b622eac7023268d5ba3d43082d07cae5654e032169cd144a5338f2553d4ee39c851c4126fe0be5378f1e
> SHA512
> 2ebf1ff7792a2ba80d8cf6f8675864580533b62659346e9ef3334ff988899d735d5d72cb3a89308cd9287bcaa74c42306cbf80a716d03658ad748688f94f394b
> DIST jenkins-bin-2.205.war 62738246 BLAKE2B
> de350469e3a6e0d93f6d05c38f7669ce630f01a0284db83a0ba002e15ef712b4dddca6dcac804ab45c898f5c73cdac99bfe9b9bb99f6534c1446d8f4545660ec
> SHA512
> 1c0b12cdf7dadaba8d81ede769f76b059c7869732610353658cc928dd8c4943f8cf8beb15498a0dd4e064688cfdb7f88faaa9165c6da97c20d5e99080a12f413
> diff --git a/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> new file mode 100644
> index 000..f29b83b491f
> --- /dev/null
> +++ b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> @@ -0,0 +1,47 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit systemd
> +
> +DESCRIPTION="Extensible continuous integration server"
> +HOMEPAGE="https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.io%2F&data=02%7C01%7Cjoakim.tjernlund%40infinera.com%7Cf63d3323a1844a3463cc08d7894d0284%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637128836158940038&sdata=EZ5QAWXzcxCKufgyrnYoYyL4uPSmG5rENE4zQG747Gg%3D&reserved=0";
> +LICENSE="MIT"
> +SRC_URI="https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirrors.jenkins-ci.org%2Fwar-stable%2F%24&data=02%7C01%7Cjoakim.tjernlund%40infinera.com%7Cf63d3323a1844a3463cc08d7894d0284%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637128836158940038&sdata=YZPJP7qtEM17poTYYuclipefI2YRyt1AF2PPaQjoL1I%3D&reserved=0{PV}/${PN/-bin/}.war
> -> ${P}.war"
> +RESTRICT="mirror"
> +SLOT="lts"
> +KEYWORDS="~amd64 ~x86 ~amd64-linux"
> +IUSE=""
> +
> +COMMON_DEPS="acct-user/jenkins
> + acct-group/jenkins"
> +
> +DEPEND="${COMMON_DEPS}"
> +
> +RDEPEND="${COMMON_DEPS}
> + media-fonts/dejavu
> + media-libs/freetype
> + !dev-util/jenkins-bin:0
> + >=virtual/jre-1.8.0"
> +
> +S=${WORKDIR}
> +
> +JENKINS_DIR=/var/lib/jenkins
Home dir is hardcoded, should just follow what acct-user/jenkins has defined.
Then one can finally choose some other dir for jenkins without duplicating the
ebuild.
Jocke
[gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
I wonder if it would be possible to use the script from
sys-apps/getent(included below)
to impl. getent in user.eclass instead of using glibc's getent? I cannot see
any downside, is there one?
This would help a lot(just seed your groups/users is in ROOT/etc/{passwd,group
...} first)
when cross building or ROOT != / as it would be trivial for the script to
respect ROOT/EPREFIX
sys-apps/getent:
#!/bin/sh
#
# Closely (not perfectly) emulate the behavior of glibc's getent utility
#
#passwd|shadow|group|aliases|hosts|networks|ethers|netgroup|protocols|services|rpc
# only returns the first match (by design)
# dns based search is not supported (hosts,networks)
# case-insensitive matches not supported (ethers; others?)
# may return false-positives (hosts,protocols,rpc,services,ethers)
[ -z "$PATH" ] && PATH="/bin:/usr/bin" || PATH="${PATH}:/bin:/usr/bin" export
PATH
file="/etc/$1"
case $1 in
passwd|group)
match="^$2:\|^[^:]*:[^:]*:$2:" ;;
shadow)
match="^$2:" ;;
networks|netgroup)
match="^[[:space:]]*$2\>" ;;
hosts|protocols|rpc|services|ethers)
match="\<$2\>" ;;
aliases)
match="^[[:space:]]*$2[[:space:]]*:" ;;
""|-h|--help)
echo "USAGE: $0 database [key]"
exit 0 ;;
*)
echo "$0: Unknown database: $1" 1>&2
exit 1 ;;
esac
if [ ! -f "$file" ] ; then
echo "$0: Could not find database file for $1" 1>&2
exit 1
fi
if [ $# -eq 1 ] ; then
exec cat "$file"
else
sed "s/#.*//; /$match/q; d" "$file" | grep . || exit 2
fi
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On Wed, 2015-06-10 at 14:06 -0400, Anthony G. Basile wrote: > On 6/10/15 1:52 PM, Mike Gilbert wrote: > > On Wed, Jun 10, 2015 at 12:44 PM, Joakim Tjernlund > > wrote: > > > I wonder if it would be possible to use the script from > > > sys-apps/getent(included below) > > > to impl. getent in user.eclass instead of using glibc's getent? I cannot > > > see any downside, is there one? > > > > > glibc's getent can get data from any NSS plugin (ie. LDAP, MySQL, > > etc). Switching to use sys-apps/getent would mean that lookups would > > only be performed against the local flat files. > > > > I added sys-apps/getent for musl and did not expect it to be used by > anything else. When I moved that script into sys-libs/musl, I masked > getent: > > # /usr/portage/profiles/package.mask: > # Anthony G. Basile (14 May 2015) > # No longer required by any packages in the tree. > # Masked for removal in 30 days. > > If you want to keep it, we can remove the mask, but it does block > against glibc and uclibc. > I think one would have to take the guts of the script and transform it into an egetent eclass function. Your script has done the hard part already so it should be easy to mangle into an eclass fkn. Jocke
Re: [gentoo-dev] Impl. egetent in user.eclass using script from sys-apps/getent?
On Wed, 2015-06-10 at 18:48 +, Robin H. Johnson wrote:
> On Wed, Jun 10, 2015 at 04:44:17PM +0000, Joakim Tjernlund wrote:
> > I wonder if it would be possible to use the script from
> > sys-apps/getent(included below)
> > to impl. getent in user.eclass instead of using glibc's getent? I
> > cannot see any downside, is there one?
> >
> > This would help a lot(just seed your groups/users is in
> > ROOT/etc/{passwd,group ...} first)
> > when cross building or ROOT != / as it would be trivial for the script to
> > respect ROOT/EPREFIX
> This would totally break when those services come from an NSS provider
> other than files or compat.
But does user.eclass support anything but local system users ?
>
> There was a non-upstream patch to support NSS on non-root filesystems,
> which would probably help a lot more; I haven't seen that original patch
> in a while, so here's a very quick and completely untested
> re-implementation of it.
>
> In your case, you probably should MAKE sure that regardless of the
> system nsswitch settings, the NSS file provider gets used.
>
> Usage: NSS_FILES_ROOT=$ROOT/etc getent -s files passwd ...
>
[gentoo-dev] Managing etc/* in an embbeded system
We got an embedded gentoo system where we need to manage many conf files under /etc that we have modified and should be under our control when an SW upgrade is performed. Cloning every ebuild where we have modified its conf file(s) under /etc feels awkward so I am looking for some other way to do this automatically during SW upgrade and I figured this can not be an unique problem for us, so I wonder how other people have solved this problem? Our customers will not use emerge directly and we will provide binary pkgs. Any ideas welcome :) Jocke
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Wed, 2015-07-22 at 07:14 -0400, Rich Freeman wrote: > On Wed, Jul 22, 2015 at 6:17 AM, Panagiotis Christopoulos > wrote: > > > > you can subscribe to gentoo-embedded mailing list and ask there, as your > > product > > is embedded. Also, man make.conf and search for CONFIG_PROTECT. If I > > understood > > you correctly, it may be what you need. > > > > That list is certainly a a good place if it is active, but I get the > impression that he wants to package/manage his config files in some > way. That is, install package foo, and then automatically get his > config files for foo. Yes, I need to be able to change my own config files too over time. > > Short of going to a true config management system, I'd consider just > having a tarball/etc full of config files that you unpack after you've > set up your system (or clone it from a git repo or whatever). If you > have config files for packages you didn't install it isn't a big deal > - they just use up a few inodes, and if you install the packages later > the CONFIG_PROTECT settings will prevent them from being overwritten. > > A portage-based alternative is to stick them all in a package(s) > (which will generate collision warnings, and since it would respect > config protect it would mean you have to merge in all the changes), or > fork all the ebuilds. I just don't think portage is really meant as a > full-fleged configuration management tool. There can not be any manual merges after an SW update here. I started to look at INSTALL_MASK, what if I set INSTALL_MASK to point to all conf files I want to manage myself. Then /etc/inittab etc. will not be touched when updating init Then I add my own ebuild containing my modified conf files but how to manage INSTALL_MASK, CONFIG_PROTECT etc.? Is it possible from within the ebuild change INSTALL_MASK, CONFIG_PROTECT? Then I could just zap INSTALL_MASK before installing my files. > Also, if you're doing lots of these installs you might want to look at > a true config management tool like ansible or puppet/chef. That could > take care of all the installation as well as the configuration, and > could be tied into portage. sound complicated for what I want to do
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Wed, 2015-07-22 at 14:30 +0200, Michał Górny wrote:
>
> Joakim Tjernlund napisał:
>
> > We got an embedded gentoo system where we need to manage many conf
> > files under /etc that we have
> > modified and should be under our control when an SW upgrade is
> > performed.
> >
> > Cloning every ebuild where we have modified its conf file(s) under /etc
> > feels awkward so
> > I am looking for some other way to do this automatically during SW
> > upgrade and I figured
> > this can not be an unique problem for us, so I wonder how other people
> > have solved this problem?
> > Our customers will not use emerge directly and we will provide binary
> > pkgs.
> >
> > Any ideas welcome :)
> >
> > Jocke
>
> Maybe post-phase hooks would help you. Not around a PC right now but I think
> they're described in portage.5.
> Long story short, you create per-package env files in /etc/portage/env (you
> can pin them generically or to a
> specific version, or package spec via package.env) and declare
> post_src_install() where you add your custom
> config files atop the package.
>
hmm, that sounds interesting but I don't quite get what to do, you think I
should copy over /etc/inittab after
it has been installed by sys-apps/sysvinit with my own version(which is stored
where?)
This gave me an idea though:
In /etc/portage/env/install-mask.conf I add
INSTALL_MASK="${INSTALL_MASK} /etc/inittab /etc/xxx"
then in /etc/portage/package.env/install-mask
sys-apps/sysvinit install-mask.conf
sys-apps/xxx install-mask.conf
...
(Can I do this from my own custom profile instead? how?)
This should prevent sys-apps/sysvinit to install conf files I want to manage,
right?
Then I create my own new ebuild holding all config files I have changed myself.
Jocke
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Wed, 2015-07-22 at 16:39 +0200, Michał Górny wrote:
> Dnia 2015-07-22, o godz. 13:20:10
> Joakim Tjernlund napisał(a):
>
> > On Wed, 2015-07-22 at 14:30 +0200, Michał Górny wrote:
> > >
> > > Joakim Tjernlund napisał:
> > >
> > > > We got an embedded gentoo system where we need to manage many conf
> > > > files under /etc that we have
> > > > modified and should be under our control when an SW upgrade is
> > > > performed.
> > > >
> > > > Cloning every ebuild where we have modified its conf file(s) under /etc
> > > > feels awkward so
> > > > I am looking for some other way to do this automatically during SW
> > > > upgrade and I figured
> > > > this can not be an unique problem for us, so I wonder how other people
> > > > have solved this problem?
> > > > Our customers will not use emerge directly and we will provide binary
> > > > pkgs.
> > > >
> > > > Any ideas welcome :)
> > > >
> > > > Jocke
> > >
> > > Maybe post-phase hooks would help you. Not around a PC right now but I
> > > think they're described in
> > > portage.5.
> > > Long story short, you create per-package env files in /etc/portage/env
> > > (you can pin them generically or
> > > to a
> > > specific version, or package spec via package.env) and declare
> > > post_src_install() where you add your
> > > custom
> > > config files atop the package.
> > >
> >
> > hmm, that sounds interesting but I don't quite get what to do, you think I
> > should copy over /etc/inittab
> > after
> > it has been installed by sys-apps/sysvinit with my own version(which is
> > stored where?)
>
> Yes, exactly. You can either copy your own, or modify (sed? patch?)
> the standard one. You can store it anywhere, download (unless you
> use network-sandbox) from the net or just inline via here-doc syntax.
Ok, then I got it.
>
> > This gave me an idea though:
> > In /etc/portage/env/install-mask.conf I add
> > INSTALL_MASK="${INSTALL_MASK} /etc/inittab /etc/xxx"
> > then in /etc/portage/package.env/install-mask
> > sys-apps/sysvinit install-mask.conf
> > sys-apps/xxx install-mask.conf
> > ...
> > (Can I do this from my own custom profile instead? how?)
> >
> > This should prevent sys-apps/sysvinit to install conf files I want to
> > manage, right?
> >
> > Then I create my own new ebuild holding all config files I have changed
> > myself.
>
> Sure. Though I don't understand why would you set it per ebuild -- you
> can set it in make.conf globally in that case, or in make.defaults in
> your profile. If doing the latter, remember to use
> INSTALL_MASK="${INSTALL_MASK} ..." if you want to add additional dirs
> afterwards.
Right, I could add the INSTALL_MASK in make.defaults in my custom profile.
Then just for my own ebuild add package.env which clears INSTALL_MASK etc. so
I can install my own conf files using emerge only.
Seems easier as it does not seem to be package.env support in the profile?
Jocke
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Wed, 2015-07-22 at 22:38 +0800, Jason Zaman wrote:
> On Wed, Jul 22, 2015 at 01:20:10PM +0000, Joakim Tjernlund wrote:
> > On Wed, 2015-07-22 at 14:30 +0200, Michał Górny wrote:
> > >
> > > Joakim Tjernlund napisał:
> > >
> > > > We got an embedded gentoo system where we need to manage many conf
> > > > files under /etc that we have
> > > > modified and should be under our control when an SW upgrade is
> > > > performed.
> > > >
> > > > Cloning every ebuild where we have modified its conf file(s) under /etc
> > > > feels awkward so
> > > > I am looking for some other way to do this automatically during SW
> > > > upgrade and I figured
> > > > this can not be an unique problem for us, so I wonder how other people
> > > > have solved this problem?
> > > > Our customers will not use emerge directly and we will provide binary
> > > > pkgs.
> > > >
> > > > Any ideas welcome :)
> > > >
> > > > Jocke
> > >
> > > Maybe post-phase hooks would help you. Not around a PC right now but I
> > > think they're described in
> > > portage.5.
> > > Long story short, you create per-package env files in /etc/portage/env
> > > (you can pin them generically or
> > > to a
> > > specific version, or package spec via package.env) and declare
> > > post_src_install() where you add your
> > > custom
> > > config files atop the package.
> > >
> >
> > hmm, that sounds interesting but I don't quite get what to do, you think I
> > should copy over /etc/inittab
> > after
> > it has been installed by sys-apps/sysvinit with my own version(which is
> > stored where?)
> >
> > This gave me an idea though:
> > In /etc/portage/env/install-mask.conf I add
> > INSTALL_MASK="${INSTALL_MASK} /etc/inittab /etc/xxx"
> > then in /etc/portage/package.env/install-mask
> > sys-apps/sysvinit install-mask.conf
> > sys-apps/xxx install-mask.conf
> > ...
> > (Can I do this from my own custom profile instead? how?)
> >
> > This should prevent sys-apps/sysvinit to install conf files I want to
> > manage, right?
> >
> > Then I create my own new ebuild holding all config files I have changed
> > myself.
>
> Or you can put a script in /etc/portage/hooks/install/, it will get run
> after src_install() during generation of VDB and all that, you could
> probably move everything from /etc/ to /etc-orig/ then all packages will
> be have things set there, then put your own files in /etc and you can
> always refer to /etc-orig/ or even use overlayfs or something to mount
> your files on top so they cover the package ones.
This also seems viable, need to look at hooks and such though. Are such hooks
native to portage?
Jocke
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: > > Sent from an iPhone, sorry for the HTML... > > > On Jul 22, 2015, at 5:38 PM, Rich Freeman wrote: > > > > On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund > > wrote: > > > > > > There can not be any manual merges after an SW update here. > > > > > > I started to look at INSTALL_MASK, what if I set INSTALL_MASK > > > to point to all conf files I want to manage myself. > > > Then /etc/inittab etc. will not be touched when updating init > > > > This sounds like overkill. > > > > If you've already installed a custom /etc/inittab, then when you > > emerge init, it won't overwrite your inittab even if you don't change > > anything in your portage config. emerge won't touch any files in /etc > > unless they don't already exist. > > > ..AND have been modified. IIRC if the hash of the config files match what > they were when the package was > previously emerged, then the files are updated aren't they? > > I expect that this is fine in the situation described, but it's worth knowing > that a config file left > unmodified may be replaced with a different vanilla config file later on. Sure, but what if I need to change a conf file in an installed system? Or rebuild a a system from scratch? The user only runs a one SW update command to update an installed system in the field and cannot edit a bunch of files too. Especially when there are hundreds of systems sitting in remote locations. This is why I need a way change conf files automatically and I want to use ebuilds/profile as far as possible. I think there is room for some improvement here in portage to allow this kind of customization. Jocke
SV: Re: [gentoo-dev] Managing etc/* in an embbeded system
This looks really promising, I am traveling ATM but will look closer at this mid next week. Thanks, Jocke Jocke Originalmeddelande Från: Zac Medico Datum: Till: gentoo-dev@lists.gentoo.org Rubrik: Re: [gentoo-dev] Managing etc/* in an embbeded system On 07/23/2015 12:46 AM, Joakim Tjernlund wrote: > On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: >> >> Sent from an iPhone, sorry for the HTML... >> >>> On Jul 22, 2015, at 5:38 PM, Rich Freeman wrote: >>> >>> On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund >>> wrote: >>>> >>>> There can not be any manual merges after an SW update here. >>>> >>>> I started to look at INSTALL_MASK, what if I set INSTALL_MASK >>>> to point to all conf files I want to manage myself. >>>> Then /etc/inittab etc. will not be touched when updating init >>> >>> This sounds like overkill. >>> >>> If you've already installed a custom /etc/inittab, then when you >>> emerge init, it won't overwrite your inittab even if you don't change >>> anything in your portage config. emerge won't touch any files in /etc >>> unless they don't already exist. >> >> >> ..AND have been modified. IIRC if the hash of the config files match what >> they were when the package was >> previously emerged, then the files are updated aren't they? >> >> I expect that this is fine in the situation described, but it's worth >> knowing that a config file left >> unmodified may be replaced with a different vanilla config file later on. > > Sure, but what if I need to change a conf file in an installed system? Or > rebuild a a system from scratch? > The user only runs a one SW update command to update an installed system in > the field and cannot edit a bunch > of files too. Especially when there are hundreds of systems sitting in remote > locations. If you use the profile-bashrcs profile-formats setting [1], then your profiles can use package.bashrc to define post_src_install and/or INSTALL_MASK to remove unwanted config files from upstream packages. Then you can easily replace the upstream config files with config files installed by your own configurations installed by your own ebuilds. > This is why I need a way change conf files automatically and I want to use > ebuilds/profile as > far as possible. I think there is room for some improvement here in portage > to allow this kind > of customization. A template engine such as jinja [2] can be use to automate rendering of your config files with settings that are specific to a particular system. [1] https://gitweb.gentoo.org/proj/portage.git/commit/?id=803dafc462027d6015721f40513abb5f57dc1178 [2] http://jinja.pocoo.org/ -- Thanks, Zac
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote: > On 07/23/2015 12:46 AM, Joakim Tjernlund wrote: > > On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: > > > > > > Sent from an iPhone, sorry for the HTML... > > > > > > > On Jul 22, 2015, at 5:38 PM, Rich Freeman wrote: > > > > > > > > On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund > > > > wrote: > > > > > > > > > > There can not be any manual merges after an SW update here. > > > > > > > > > > I started to look at INSTALL_MASK, what if I set INSTALL_MASK > > > > > to point to all conf files I want to manage myself. > > > > > Then /etc/inittab etc. will not be touched when updating init > > > > > > > > This sounds like overkill. > > > > > > > > If you've already installed a custom /etc/inittab, then when you > > > > emerge init, it won't overwrite your inittab even if you don't change > > > > anything in your portage config. emerge won't touch any files in /etc > > > > unless they don't already exist. > > > > > > > > > ..AND have been modified. IIRC if the hash of the config files match > > > what they were when the package > > > was > > > previously emerged, then the files are updated aren't they? > > > > > > I expect that this is fine in the situation described, but it's worth > > > knowing that a config file left > > > unmodified may be replaced with a different vanilla config file later on. > > > > Sure, but what if I need to change a conf file in an installed system? Or > > rebuild a a system from scratch? > > The user only runs a one SW update command to update an installed system in > > the field and cannot edit a > > bunch > > of files too. Especially when there are hundreds of systems sitting in > > remote locations. > > If you use the profile-bashrcs profile-formats setting [1], then your > profiles can use package.bashrc to define post_src_install and/or > INSTALL_MASK to remove unwanted config files from upstream packages. > Then you can easily replace the upstream config files with config files > installed by your own configurations installed by your own ebuilds. Finally getting back to this after lots of distractions. I cannot get profile-formats = profile-bashrcs to work. I have in metadata/layout.conf: masters = gentoo profile-formats = portage-2 profile-bashrcs then in profiles/tmv3-target-overlay/profile.bashrc: INSTALL_MASK= Doing portageq envvar INSTALL_MASK just yields an empty line I guess I am missing something here?
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Tue, 2015-08-11 at 10:55 -0700, Zac Medico wrote: > On 08/11/2015 10:48 AM, Joakim Tjernlund wrote: > > On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote: > > > On 07/23/2015 12:46 AM, Joakim Tjernlund wrote: > > > > On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: > > > > > > > > > > Sent from an iPhone, sorry for the HTML... > > > > > > > > > > > On Jul 22, 2015, at 5:38 PM, Rich Freeman wrote: > > > > > > > > > > > > On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund > > > > > > wrote: > > > > > > > > > > > > > > There can not be any manual merges after an SW update here. > > > > > > > > > > > > > > I started to look at INSTALL_MASK, what if I set INSTALL_MASK > > > > > > > to point to all conf files I want to manage myself. > > > > > > > Then /etc/inittab etc. will not be touched when updating init > > > > > > > > > > > > This sounds like overkill. > > > > > > > > > > > > If you've already installed a custom /etc/inittab, then when you > > > > > > emerge init, it won't overwrite your inittab even if you don't > > > > > > change > > > > > > anything in your portage config. emerge won't touch any files in > > > > > > /etc > > > > > > unless they don't already exist. > > > > > > > > > > > > > > > ..AND have been modified. IIRC if the hash of the config files match > > > > > what they were when the > > > > > package > > > > > was > > > > > previously emerged, then the files are updated aren't they? > > > > > > > > > > I expect that this is fine in the situation described, but it's worth > > > > > knowing that a config file > > > > > left > > > > > unmodified may be replaced with a different vanilla config file later > > > > > on. > > > > > > > > Sure, but what if I need to change a conf file in an installed system? > > > > Or rebuild a a system from > > > > scratch? > > > > The user only runs a one SW update command to update an installed > > > > system in the field and cannot edit > > > > a > > > > bunch > > > > of files too. Especially when there are hundreds of systems sitting in > > > > remote locations. > > > > > > If you use the profile-bashrcs profile-formats setting [1], then your > > > profiles can use package.bashrc to define post_src_install and/or > > > INSTALL_MASK to remove unwanted config files from upstream packages. > > > Then you can easily replace the upstream config files with config files > > > installed by your own configurations installed by your own ebuilds. > > > > Finally getting back to this after lots of distractions. > > I cannot get profile-formats = profile-bashrcs to work. > > I have in metadata/layout.conf: > > masters = gentoo > > profile-formats = portage-2 profile-bashrcs > > then in profiles/tmv3-target-overlay/profile.bashrc: > > INSTALL_MASK= > > Doing portageq envvar INSTALL_MASK just yields an empty line > > I guess I am missing something here? > > > > > > See the "man portage" for profile-bashrcs details. It uses > package.bashrc rather than profile.bashrc, so that explains why it's not > working for you. hmm, I figured I could use profile.bashrc to set stuff for all pkgs? In any case I tried package.bashrc but portageq envvar INSTALL_MASK does not print anything either. It occurred to me that portageq envvar is not the right tool see variable defined in bash scripts? Is there some other tools I can use? Jocke
[gentoo-dev] Where did vanilla-sources-3.14.x go?
vanilla-sources 3.14.x is gone from the tree. Jocke
Re: [gentoo-dev] [RFC] New Project: MATE
On Thu, 2015-07-02 at 21:50 +0200, Pacho Ramos wrote: > El jue, 02-07-2015 a las 15:40 -0400, NP-Hardass escribió: > > Greetings all, > > > > Looking for some feedback on creating a new project and herd for the > > MATE Desktop environment. The goal, like many other DE based > > projects, > > is to provide up to date packaging and as complete an offering of the > > DE's packages as possible. > > > > Currently, the packages of the MATE Desktop DE are listed as > > maintained > > by TomWij (who is on long term devaway). Prior to acceptance into > > the > > Gentoo repo, it was worked on by lxnay and steev. All 3 have either > > not responded to inquiries, or have expressed limited interest in > > maintaining the DE. As a result, I felt the best way to support > > users > > was to move support of MATE away from any individual, and create a > > project and associated herd to manage the packages, thus allowing any > > developer that is interested in helping out an easy means of doing > > so. > > > > I've created a prospective Wiki project page: > > https://wiki.gentoo.org/wiki/Project:MATE and intend to have a mail > > alias, m...@gentoo.org, and an email channel for Gentoo support and > > development, #gentoo-mate. > > > > Any feedback regarding the aforementioned would be greatly > > appreciated. > > > > -- > > NP-Hardass > > > I fully agree and I hope that helps with current MATE maintenance that > is a bit stalled due to Tomwij devaway Had a look at gentoo-mate repo and it seems it has stalled? Jocke
[gentoo-dev] https://packages.gentoo.org/ and Changelogs
The Changelogs on https://packages.gentoo.org/ are old, from before the git migration. Could this be fixed? Jocke
Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)
On Tue, 2015-12-01 at 22:58 +, James Le Cuirot wrote: > [SNIP really good writeup, thanks :)] > There's also a further complication here that I forgot to mention to > mgorny. While calling configure with --with-sysroot certainly helps, > it still stumbles on a significant number of packages that do > relinking at the end of the build if elibtoolize hasn't been called. > elibtoolize has long patched ltmain.sh with ELT-patches/cross/link-ROOT I looked at ELT-patches/cross/link-ROOT and it has --- libltdl/config/ltmain.sh2008-09-07 19:56:33.0 +0200 +++ libltdl/config/ltmain.sh.new2009-02-15 20:37:47.0 +0100 @@ -5768,7 +5768,7 @@ test "$hardcode_direct_absolute" = no; then add="$libdir/$linklib" elif test "$hardcode_minus_L" = yes; then - add_dir="-L$libdir" + add_dir="-L$ROOT/$libdir" add="-l$name" elif test "$hardcode_shlibpath_var" = yes; then case :$finalize_shlibpath: in @@ -5785,7 +5785,7 @@ fi else # We cannot seem to hardcode it, guess we'll fake it. - add_dir="-L$libdir" + add_dir="-L$ROOT/$libdir" I think this should be "add_dir=-L$lt_sysroot$libdir" rather than ROOT. See also bug https://bugs.gentoo.org/show_bug.cgi?id=521184 and since I think this is also a libool bug there is a post upstream http://lists.gnu.org/archive/html/libtool/2015-10/msg00012.html This has not gotten any attention from upstream libtool folks. Would be great if someone more could push for such a change. Jocke > when cross-compiling and this still applies to the very latest libtool. > I filed several bugs about this before realising that fixing this > globally would be better. elibtoolize doesn't require anything to be > installed and the description does say "this function should always be > safe to run" but I suppose calling it unconditionally might screw up > patching in some isolated cases. What do you think? > > Phew, I'm done. Please be gentle! :) >
Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)
On Thu, 2015-12-03 at 23:32 +, James Le Cuirot wrote: > On Thu, 3 Dec 2015 08:22:01 + > Joakim Tjernlund wrote: > > > > There's also a further complication here that I forgot to mention to > > > mgorny. While calling configure with --with-sysroot certainly helps, > > > it still stumbles on a significant number of packages that do > > > relinking at the end of the build if elibtoolize hasn't been called. > > > elibtoolize has long patched ltmain.sh with > > > ELT-patches/cross/link-ROOT > > > > I looked at ELT-patches/cross/link-ROOT and it has > > --- libltdl/config/ltmain.sh2008-09-07 19:56:33.0 > > +0200 +++ libltdl/config/ltmain.sh.new 2009-02-15 > > 20:37:47.0 +0100 @@ -5768,7 +5768,7 @@ > > test "$hardcode_direct_absolute" = no; then > > add="$libdir/$linklib" > > elif test "$hardcode_minus_L" = yes; then > > - add_dir="-L$libdir" > > + add_dir="-L$ROOT/$libdir" > > add="-l$name" > > elif test "$hardcode_shlibpath_var" = yes; then > > case :$finalize_shlibpath: in > > @@ -5785,7 +5785,7 @@ > > fi > > else > > # We cannot seem to hardcode it, guess we'll fake it. > > - add_dir="-L$libdir" > > + add_dir="-L$ROOT/$libdir" > > > > I think this should be "add_dir=-L$lt_sysroot$libdir" rather than > > ROOT. See also bug https://bugs.gentoo.org/show_bug.cgi?id=521184 > > and since I think this is also a libool bug there is a post upstream > > http://lists.gnu.org/archive/html/libtool/2015-10/msg00012.html > > This has not gotten any attention from upstream libtool folks. Would > > be great if someone more could push for such a change. > > Agreed. I already wondered if there was an autotools variable that > would be more appreciate. Since aballier also said that this should be > corrected, I'll see about doing that in conjunction with these changes. > > I wouldn't hold your breath for upstream. I've heard of them ignoring > other issues like the "as-needed" one for years. Upstream seems a bit unfocused and probably needs some prodding to get going. The suggested change is simple and won't affect normal libtool use so it should not be to hard to get it committed. Jocke, off for the weekend as of now.
Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)
On Thu, 2015-12-03 at 09:28 +0100, Alexis Ballier wrote: > On Wed, 2 Dec 2015 23:20:05 + > James Le Cuirot wrote: > > > On Wed, 2 Dec 2015 12:40:08 +0100 > > Alexis Ballier wrote: > > > > > On Tue, 1 Dec 2015 22:58:55 + > > > James Le Cuirot wrote: > > > [...] > > > > > > > > I raised one further point with mgorny that he feels could > > > > potentially go into EAPI 7 but I think could remain an > > > > implementation detail. In cases #3 and #4 (basically when > > > > ROOT != / and PORTAGE_CONFIGROOT != /), the toolchain needs to > > > > know how to source headers and libraries from ROOT instead of /. > > > > > > Use SYSROOT. ROOT has nothing to do with building. This should be > > > defined in PMS though. > > > > In case #2, ROOT != / but SYSROOT = / so I take your point that > > SYSROOT would negate the need to check which use case we're dealing > > with. > > > > I looked into SYSROOT while I was writing cross-boss. It's used in > > some crossdev scripts, most notably cross-pkg-config, but not by > > pkg-config itself. It's also used in a small handful of eclasses and > > other *-config scripts but that's all. Conversely, the aforementioned > > libtool patch uses ROOT and I suspect many other things do too. In > > practise, you need to set both. > > The libtool patch has probably not been updated after SYSROOT > introduction. Feel free to file a bug about it. > > > On reflection, I'm now thinking that we should call it something less > > generic. I also found that the Qt build uses SYSROOT for its own > > purposes so you cannot rely on it in toolchain wrappers. ROOT is > > probably just as unreliable. For that reason, I ended up using > > CB_SYSROOT in cross-boss. > > > > I forgot to mention earlier that if ROOT were used, PMS actually > > forbids it from being referenced in the src_* phases so this > > restriction would need to be lifted. Relying on the toolchain's > > internal sysroot is not sufficient. > > And PMS is absolutely right. > > Put simple: > SYSROOT is where "sources" are installed (headers, .so, etc); think > debian's -dev packages. > ROOT is where packages are merged. > > Meaning: > > RDEPEND are installed to ROOT > DEPEND are installed to SYSROOT hmm, this implies that a pkg in both DEPEND and RDEPEND should be installed in both SYSROOT and ROOT? Does portage do this ATM? > (BDEPEND are installed to /)
[gentoo-dev] anongit.gentoo.org/repo/sync/gentoo.git not syncing any more?
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > in case the package does not work with java > 1.8 (still, i suggest we > first try to resolve the issue before we use this restriction as it > might cause some issues in the future) > virtual/jdk:1.8 > virtual/jre:1.8 This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will try to build with java-11 and the build will fail. Jocke
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote: > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > > in case the package does not work with java > 1.8 (still, i suggest we > > > first try to resolve the issue before we use this restriction as it > > > might cause some issues in the future) > > > virtual/jdk:1.8 > > > virtual/jre:1.8 > > > > This does not seem to be enforced by java eclasses. Example > > dev-java/icedtea-web has > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system > > default will > > try to build with java-11 and the build will fail. > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. > regular java apps use classes from jre (java runtime engine) and so they > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this > icedtea-web issue, this should be filed as a bug. thank you for > mentioning this. Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed RDEPEND to virtual/jdk:1.8 it still fails. > > Jocke > > fordfrog > >
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote: > Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a): > > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote: > > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): > > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > > > > in case the package does not work with java > 1.8 (still, i suggest we > > > > > first try to resolve the issue before we use this restriction as it > > > > > might cause some issues in the future) > > > > > virtual/jdk:1.8 > > > > > virtual/jre:1.8 > > > > This does not seem to be enforced by java eclasses. Example > > > > dev-java/icedtea-web has > > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as > > > > system default will > > > > try to build with java-11 and the build will fail. > > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. > > > regular java apps use classes from jre (java runtime engine) and so they > > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this > > > icedtea-web issue, this should be filed as a bug. thank you for > > > mentioning this. > > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and > > changed > > RDEPEND to virtual/jdk:1.8 it still fails. > yes, looking at that icedtea-web ebuild, it inherits none of java > eclasses so it can't behave as a package that inherits a java eclass. > gyakovlev would definitely know better. generally, this thread is meant > for packages that inherit one of java eclasses, and even that is > oversimplified. > > > Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or JAVA_HOME in ebuilds? However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to use BDEPEND here? Also, RDEPEND does not seem to matter, only BDEPEND
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On Thu, 2021-04-15 at 16:35 +, Joakim Tjernlund wrote: > On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote: > > Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a): > > > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote: > > > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a): > > > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote: > > > > > > in case the package does not work with java > 1.8 (still, i suggest > > > > > > we > > > > > > first try to resolve the issue before we use this restriction as it > > > > > > might cause some issues in the future) > > > > > > virtual/jdk:1.8 > > > > > > virtual/jre:1.8 > > > > > This does not seem to be enforced by java eclasses. Example > > > > > dev-java/icedtea-web has > > > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as > > > > > system default will > > > > > try to build with java-11 and the build will fail. > > > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. > > > > regular java apps use classes from jre (java runtime engine) and so they > > > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this > > > > icedtea-web issue, this should be filed as a bug. thank you for > > > > mentioning this. > > > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and > > > changed > > > RDEPEND to virtual/jdk:1.8 it still fails. > > yes, looking at that icedtea-web ebuild, it inherits none of java > > eclasses so it can't behave as a package that inherits a java eclass. > > gyakovlev would definitely know better. generally, this thread is meant > > for packages that inherit one of java eclasses, and even that is > > oversimplified. > > > > > > Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or > JAVA_HOME in ebuilds? > However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to > use BDEPEND here? > > Also, RDEPEND does not seem to matter, only BDEPEND Filed bug https://bugs.gentoo.org/783027 with a small patch, in case you want to comment.
[gentoo-dev] python and frieds installs test code
I have noted that python, portage and gentoolkit appers to install many MB of what appers to be test code: python: /usr/lib/python*/test, /usr/lib/python*/ctypes/test, /usr/lib/python*/lib2to3/tests, /usr/lib/python*/unittest, /usr/lib/python*/distutils/tests ... portage/gentoolkit: /usr/lib/python*/site-packages/portage/tests /usr/lib/python*/site-packages/gentoolkit/test .. Didn't look further, I guess there is more pkgs The question then is, are these required in a running system? Jocke
