Re: [gentoo-user] Updating Gentoo
Hi there,
I'm using Sakaki's Genup Script exclusively for quite a long time now.
No problems there and it updates everything (i.e. portage, overlays if
you have some installed, etc.)
Have a look at it:
https://github.com/sakaki-/genup
greetz
m4110c
Thus spoke Consus (con...@ftml.net):
> Hi,
>
> For quite a bit I'm using this script to update my stable Gentoo system:
>
> $ cat $(which sysupdate)
> #!/bin/sh
> # Update the whole system
>
> set -e
>
> echo "==> Syncing Portage tree..."
> emerge --sync --quiet
>
> echo "==> Updating world..."
> emerge -auDU --with-bdeps=y @world
>
> echo "==> Removing old dependencies..."
> emerge -qc
>
> echo "==> Upgrading Perl packages (if needed)..."
> perl-cleaner --quiet --modules --ph-clean --delete-leftovers
>
> # TODO: Check errors
> cur_kver=$(readlink /usr/src/linux | sed 's/linux-//')
> new_kver=$(cd /usr/src && ls -1d linux-* | sort -Vr | head -1 | sed
> 's/linux-//')
>
> if [ "${cur_kver}" != "${new_kver}" ]; then
> echo "==> Switching to kernel ${new_kver}..."
> eselect kernel set linux-${new_kver}
> if [ ! -e "/boot/vmlinuz-${new_kver}" ]; then
> echo "==> Building kernel ${new_kver}..."
> genkernel kernel
> fi
> else
> # Rebuild initramfs if third-party modules were updated
> if [ -n $(find /lib/modules/${cur_kver} \
> -newer /boot/initramfs-${cur_kver}.img) ]; then
> dracut -f
> fi
> fi
>
> Still, it won't catch some issues with Go or Haskell (as there are
> separate app-admin/go-updater and app-admin/haskell-updater ebuilds
> still around in the Tree) + there is a separate genkernel post-install
> script that cleans up old kernels during the kernel update.
>
> So, I was wondering -- maybe there is a
> fool-proof-one-command-that-do-it-all solution wondering somewhere?
>
--
m4110c
mailto: dis...@mm-no.de
Re: [gentoo-user] Updating Gentoo
Hi, Here I’m using this script: https://git.grifon.fr/alarig/gentoo-auto-update/src/branch/master/check_updates.sh But it’s not perfect also ;) -- Alarig
[gentoo-user] Updating Gentoo
Hi,
For quite a bit I'm using this script to update my stable Gentoo system:
$ cat $(which sysupdate)
#!/bin/sh
# Update the whole system
set -e
echo "==> Syncing Portage tree..."
emerge --sync --quiet
echo "==> Updating world..."
emerge -auDU --with-bdeps=y @world
echo "==> Removing old dependencies..."
emerge -qc
echo "==> Upgrading Perl packages (if needed)..."
perl-cleaner --quiet --modules --ph-clean --delete-leftovers
# TODO: Check errors
cur_kver=$(readlink /usr/src/linux | sed 's/linux-//')
new_kver=$(cd /usr/src && ls -1d linux-* | sort -Vr | head -1 | sed
's/linux-//')
if [ "${cur_kver}" != "${new_kver}" ]; then
echo "==> Switching to kernel ${new_kver}..."
eselect kernel set linux-${new_kver}
if [ ! -e "/boot/vmlinuz-${new_kver}" ]; then
echo "==> Building kernel ${new_kver}..."
genkernel kernel
fi
else
# Rebuild initramfs if third-party modules were updated
if [ -n $(find /lib/modules/${cur_kver} \
-newer /boot/initramfs-${cur_kver}.img) ]; then
dracut -f
fi
fi
Still, it won't catch some issues with Go or Haskell (as there are
separate app-admin/go-updater and app-admin/haskell-updater ebuilds
still around in the Tree) + there is a separate genkernel post-install
script that cleans up old kernels during the kernel update.
So, I was wondering -- maybe there is a
fool-proof-one-command-that-do-it-all solution wondering somewhere?
[gentoo-user] Imagemagick not being detected by emacs
Hello all, I'm struggling to get emacs to incorporate imagemagick to allow for rudimental image viewing and manipulation functionality. I have both media-gfx/imagemagick-7.0.8-50 and app-editors/emacs-26.2 installed. With imagemagick installed prior to an emacs rebuild the compiler output says something to the effect of 'Imagemagick detected... no' despite the `imagemagick` USE flag being enabled. Similarly, when I run eval-expression in emacs for (image-type-available-p 'imagemagick), a value of nil is returned meaning that emacs is still unaware of imagemagick. I think I can probably add imagemagick to the environment path but I am unsure which directory to add. Most of the binaries live in /usr/bin which is already on the PATH by default. Would appreciate any suggestions the mailing list could offer. All the best, James
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On domenica 21 luglio 2019 12:44:14 CEST Mick wrote: > On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote: > > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > > > Hello to everyone, > > > > > since yesterday emerge --sync fails because it can't refresh keys. > > > > > The > > > > > messages I get are: > > > > > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > > > * Refreshing keys via WKD ... [ !! ] > > > > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > > > > keyring > > > > > > > > > > refresh failed: > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > > > OpenPGP keyring refresh failed: > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > Perhaps something to do with this? > > > > > > > > https://www.bleepingcomputer.com/news/security/public-certificate-pois > > > > on > > > > in > > > > g-> > > > > > > can-break-some-openpgp-implementations/ > > > > > > > Aside: > > > > I have already switched my personal gpg configuration to use the new > > > > isolated keyserver. > > > > > > Thanks for the answer. I'd heard of this attack and read this [1] > > > article > > > on gentoo.org. From what I understand, it said that in theory there > > > shouldn't be problems when syncing because "The gemato tool used to > > > verify the Gentoo ebuild repository uses WKD by default. During normal > > > operation it should not be affected by this vulnerability". Reading the > > > article again, I now see it also says that "In the worst case; Gentoo > > > repository syncs will be slow or hang" which, as you suggest, could very > > > well be what's happened on my system. Unfortunately, the article doesn't > > > say what to do if this happens. > > > > > > Tomorrow I'll try investigating more. > > > > > > Stefano > > > > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html > > > > It seems I found out how to fix the issue. I tried comparing my > > /usr/share/portage/config/repos.conf with the one which comes with a > > current stage3 and found out mine had the line > > > > sync-openpgp-keyserver = hkps://keys.gentoo.org > > > > which was missing in the file from stage3. Removing it (both here and in > > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope > > this is the correct fix. I don't remember ever writing this line, so I > > suppose it came with the original stage3 I built my system from or was > > changed by another update (an update of what, however? According to > > `equery > > b`, this file doesn't belong to any package). > > > > I hope thing will keep working. > > > > Stefano > > I grepped two older installations I had immediate access to and there is no > directive containing "openpgp" anywhere within /etc/portage/. > > In a new-ish installation there were a number of entries in /etc/portage/ > repos.conf/gentoo.conf, but no keyserver URI: > > $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf > sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc > sync-openpgp-key-refresh-retry-count = 40 > sync-openpgp-key-refresh-retry-overall-timeout = 1200 > sync-openpgp-key-refresh-retry-delay-exp-base = 2 > sync-openpgp-key-refresh-retry-delay-max = 60 > sync-openpgp-key-refresh-retry-delay-mult = 4 > > Perhaps you had added a keyserver as a fall back when you were configuring > your system to use WKD? I haven't implemented WKD because there was no news > item advising us to do so. Maybe. I really know nothing about these issues, so I'm sure I wouldn't have added that line by myself. Maybe I read about them somewhere and I forgot about it. Stefano
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote: > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > > Hello to everyone, > > > > since yesterday emerge --sync fails because it can't refresh keys. The > > > > messages I get are: > > > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > > * Refreshing keys via WKD ... [ !! ] > > > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > > > keyring > > > > > > > > refresh failed: > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > OpenPGP keyring refresh failed: > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > Perhaps something to do with this? > > > > > > https://www.bleepingcomputer.com/news/security/public-certificate-poison > > > in > > > g-> > > > > can-break-some-openpgp-implementations/ > > > > > Aside: > > > I have already switched my personal gpg configuration to use the new > > > isolated keyserver. > > > > Thanks for the answer. I'd heard of this attack and read this [1] article > > on gentoo.org. From what I understand, it said that in theory there > > shouldn't be problems when syncing because "The gemato tool used to > > verify the Gentoo ebuild repository uses WKD by default. During normal > > operation it should not be affected by this vulnerability". Reading the > > article again, I now see it also says that "In the worst case; Gentoo > > repository syncs will be slow or hang" which, as you suggest, could very > > well be what's happened on my system. Unfortunately, the article doesn't > > say what to do if this happens. > > > > Tomorrow I'll try investigating more. > > > > Stefano > > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html > > It seems I found out how to fix the issue. I tried comparing my > /usr/share/portage/config/repos.conf with the one which comes with a current > stage3 and found out mine had the line > > sync-openpgp-keyserver = hkps://keys.gentoo.org > > which was missing in the file from stage3. Removing it (both here and in > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope > this is the correct fix. I don't remember ever writing this line, so I > suppose it came with the original stage3 I built my system from or was > changed by another update (an update of what, however? According to `equery > b`, this file doesn't belong to any package). > > I hope thing will keep working. > > Stefano I grepped two older installations I had immediate access to and there is no directive containing "openpgp" anywhere within /etc/portage/. In a new-ish installation there were a number of entries in /etc/portage/ repos.conf/gentoo.conf, but no keyserver URI: $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc sync-openpgp-key-refresh-retry-count = 40 sync-openpgp-key-refresh-retry-overall-timeout = 1200 sync-openpgp-key-refresh-retry-delay-exp-base = 2 sync-openpgp-key-refresh-retry-delay-max = 60 sync-openpgp-key-refresh-retry-delay-mult = 4 Perhaps you had added a keyserver as a fall back when you were configuring your system to use WKD? I haven't implemented WKD because there was no news item advising us to do so. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > Hello to everyone, > > > since yesterday emerge --sync fails because it can't refresh keys. The > > > messages I get are: > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > * Refreshing keys via WKD ... [ !! ] > > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > > keyring > > > > > > refresh failed: > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > gpg: keyserver refresh failed: No keyserver available > > > > > > OpenPGP keyring refresh failed: > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > gpg: keyserver refresh failed: No keyserver available > > > > Perhaps something to do with this? > > > > https://www.bleepingcomputer.com/news/security/public-certificate-poisonin > > g-> > can-break-some-openpgp-implementations/ > > > Aside: > > I have already switched my personal gpg configuration to use the new > > isolated keyserver. > > Thanks for the answer. I'd heard of this attack and read this [1] article on > gentoo.org. From what I understand, it said that in theory there shouldn't > be problems when syncing because "The gemato tool used to verify the Gentoo > ebuild repository uses WKD by default. During normal operation it should > not be affected by this vulnerability". Reading the article again, I now > see it also says that "In the worst case; Gentoo repository syncs will be > slow or hang" which, as you suggest, could very well be what's happened on > my system. Unfortunately, the article doesn't say what to do if this > happens. > > Tomorrow I'll try investigating more. > > Stefano > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html It seems I found out how to fix the issue. I tried comparing my /usr/share/portage/config/repos.conf with the one which comes with a current stage3 and found out mine had the line sync-openpgp-keyserver = hkps://keys.gentoo.org which was missing in the file from stage3. Removing it (both here and in /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope this is the correct fix. I don't remember ever writing this line, so I suppose it came with the original stage3 I built my system from or was changed by another update (an update of what, however? According to `equery b`, this file doesn't belong to any package). I hope thing will keep working. Stefano
