[gentoo-user] wpa_supplicant not starting dhcpcd
I have this line in /etc/conf.d/net: config_wlp3s0="dhcp" given: $ifconfig wlp3s0 wlp3s0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:192.168.178.42 Bcast:192.168.178.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2008 errors:0 dropped:0 overruns:0 frame:0 TX packets:335 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:619501 TX bytes:40551 but I still have to manually start dhcpcd (now, after installing kernel 4.19.72). Another problem - wpa_supplicant then defines a default gateway, even though one already existed for the wired connection: config_enp2s0="192.168.179.20 netmask 255.255.255.0 brd 192.168.179.255" routes_enp2s0="default via 192.168.179.24" I have to then manually delete that when I'm on wireless. That all happened automatically before. I wonder how I broke that all.
[gentoo-user] Re: Upgrading to icu-65.1 causes problems
Hartmut Figge: >So, a missing file. Attempting to emerge without glibmm. Until the next stop. This time gst-plugins-base-1.14.5-r1 which required gudev/gudev.h in /usr/include/gudev-1.0. That doesn't exist anymore and seems to have been part of udev in the past. Interesting day. :) llvw took over 2 hours to emerge and there are some other heavy bricks in the future. Maybe I will emerge some of those to spare time in the future. Apart from that I will wait until the current mess is fixed. Hartmut
Re: [gentoo-user] How does the emerge process recognizes, whether a certain package is installed?
On Wed, Dec 18, 2019 at 1:55 PM Neil Bothwick wrote: > > On Wed, 18 Dec 2019 19:24:03 +0100, tu...@posteo.de wrote: > > > What is the mechanism and how does it work, which > > cares, that a certain package of a certain version > > gets installed only once? > > The package database is at /var/db/pkg > It is probably worth noting that there really isn't anything preventing a package from being re-installed over the same version of itself. Portage shouldn't generally try to do this unless there is some reason to rebuild it (slot op dep change/etc). However, you can force it to do so (harmlessly) at any time just by running emerge -1 . In general when a package is installed and another package exists in the same slot (whether the same version or not), first portage installs the new package, and then it removes the old version. However, portage tracks files by hash and modification date so when it goes to remove the old package, any files that were overwritten by the new package will no longer match, and thus will not be removed. Any files installed by the old version which were not overwritten by the new version (which could be the same version) will get removed. This also allows updates to system/toolchain/etc packages in-place without too much disruption to running processes (obviously already open files are unaffected regardless due to unix mechanics, but you could get race conditions with files that aren't actually open if it were done the other way around). -- Rich
Re: [gentoo-user] How does the emerge process recognizes, whether a certain package is installed?
On Wed, 18 Dec 2019 19:24:03 +0100, tu...@posteo.de wrote: > What is the mechanism and how does it work, which > cares, that a certain package of a certain version > gets installed only once? The package database is at /var/db/pkg -- Neil Bothwick Good fortune will find you provided you left clear instructions. pgpIKNhbCzRk0.pgp Description: OpenPGP digital signature
[gentoo-user] How does the emerge process recognizes, whether a certain package is installed?
Hi, the subject explained it nearly complete: What is the mechanism and how does it work, which cares, that a certain package of a certain version gets installed only once? Thanks for any help in advance! Cheers! mcc
Re: [gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …
On Wed, Dec 18, 2019 at 11:03 AM Grant Edwards wrote: > > On 2019-12-18, (Nuno Silva) > wrote: > > > The EAPI problem is in a package that is pulled as a dependency of > > portage. > > > > Unless there's a simple hack to solve this, you will need to use older > > ebuilds or split the update in several steps, using older versions of > > the portage tree. The following notes show a way of achieving this: > > > > https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo > > In my experience of situations like this, it's often a lot less work > to just backup /etc and user home directories and re-install from > scratch. > That wiki article seems a bit dated, though it has the right general concept. IMO it is way simpler than that. You could of course do a reinstall and move your /etc and /home - that will certainly be the cleanest approach. You'll probably clear out a lot of orphans or things that are config-protected that have moved that way (well, less so if you keep /etc whole). I think some of this hinges on just HOW old that system is. What was the date that it was last updated on? Assuming it isn't older than 2015 I think the simplest safe approach is to switch to a git repo, and then update it by date. You can use https://anongit.gentoo.org/git/repo/sync/gentoo.git as it has the metadata cache included, but that didn't really start until Aug 2018. Commits before that date won't include metadata, though you can build that yourself. It also uses CI checks so in theory every merge commit is clean and consistent. You can do date-based checkouts. I'd try jumping one year at a time updating @system or at least portage+toolchain. If one of those updates fails you can do a shorter update interval. You probably don't need to update @world until you get up to the current date. As long as @system is updated it should be able to bootstrap everything else. You can't just jump to the current portage as the current portage ebuild is going to use an EAPI that isn't supported by the version of portage you already have. Portage is usually updated in EAPI conservatively to minimize this issue, but if you want to jump multiple years at a time it won't work. Jumping 6-12mo at a time will minimize this issue. -- Rich
Re: [gentoo-user] Mounting USB sticks automagically.
On Wednesday, 18 December 2019 16:46:49 GMT Dr Rainer Woitok wrote: > Mick, > > On Tuesday, 2019-12-17 23:44:19 +, you wrote: > > ... > > And ... usually by the sys-fs/udisks package, which performs the > > automounting. If for some reason you have uninstalled udisks, > >$ equery --no-color list -F '$mask2,$location $fullversion:$slot $cp' > sys-fs/udisks * Searching for udisks in sys-fs ... >amd64,IP- 2.8.4:2 sys-fs/udisks >$ > > And before I forget: hibernate, suspend, shutdown, and restart also do > no longer work for an unprivileged user. I only noticed that yesterday > evening when I pressed the power button which I have configured to do > hibernation. It only locked the screen. However, > ># echo disk > /sys/power/state > > did work. > > Sincerely, > Rainer OK, are you running consolekit, or elogind? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Upgrading to icu-65.1 causes problems
Hartmut Figge: >At the moment the emerge runs through and is at (107 of 188). Will take >some time before that is finished. Stopped with an error >>> Emerging (148 of 188) dev-cpp/glibmm-2.60.1::gentoo >>> Failed to emerge dev-cpp/glibmm-2.60.1, Log file: >>> '/var/tmp/portage/dev-cpp/glibmm-2.60.1/temp/build.log' Reason for that was In file included from /usr/include/sigc++-2.0/sigc++/signal.h:8, from /usr/include/sigc++-2.0/sigc++/sigc++.h:104, from /var/tmp/portage/dev-cpp/glibmm-2.60.1/work/glibmm-2.60.1/glib/glibmm/thread.h:50, from /var/tmp/portage/dev-cpp/glibmm-2.60.1/work/glibmm-2.60.1/glib/glibmm.h:88, from /var/tmp/portage/dev-cpp/glibmm-2.60.1/work/glibmm-2.60.1/glib/glibmm/bytearray.cc:4: /usr/include/sigc++-2.0/sigc++/signal_base.h:24:10: fatal error: sigc++config.h: No such file or directory So, a missing file. Attempting to emerge without glibmm. Hartmut
Re: [gentoo-user] safe use of .gnupg
191218 Mick wrote: > On Wednesday, 18 December 2019 07:33:51 GMT Andrew Udvare wrote: >> On Dec 17, 2019, at 20:51, Philip Webb wrote: >>> When encrypting a file, I was told : >>> root:552 root> gpg -c >>> gpg: WARNING: unsafe ownership on homedir '/home/purslow/.gnupg' >>> The file is owned by my user, ie : . >>> This seems to be the default when 'gpg' is installed. >> It's probably complaining if you're running as root >> and you've set the GPG home did to be in /home/purslow/.gnupg >> rather than /root/.gnupg (and owned by root:root). >> Otherwise try setting that directory to 0700 permission (u+rwx g-rwx o-rwx). > You're using a symmetric cipher, so the complaint is only a warning > about the ownership of the gnupg configuration file being used. > You may wish your root user to have different gnupg settings > than your plain user and gnupg is warning you about it. > However, this is rather odd. When you first use gnupg as any user > without specifying a configuration file, it will try to create a new > ~/.gnupg directory with default settings and public/private keys; e.g. > # gpg -c > gpg: directory '/root/.gnupg' created > gpg: keybox '/root/.gnupg/pubring.kbx' created > Given the above the directory and files in /root/.gnupg > should be owned by root:root, rather than root:552 , > if '552' in your message is some group ID. No (smile) : '552' is the command-line number in the line spec. Thanks for both replies : I can now re-arrange things appropriately. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Upgrading to icu-65.1 causes problems
Greetings, after today's 'emerge -pv -uDN @world' I was surprised by --- Total: 189 packages (90 upgrades, 5 in new slots, 94 reinstalls), Size of downloads: 822.841 KiB WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: dev-libs/icu:0 (dev-libs/icu-65.1:0/65.1::gentoo, ebuild scheduled for merge) conflicts with >=dev-libs/icu-64.2:0/64.2= required by (net-libs/nodejs-12.13.0:0/0::gentoo, installed) dev-libs/icu:0/64.2= required by (app-text/libqxp-0.0.2:0/0::gentoo, installed) dev-libs/icu:0/64.2= required by (media-libs/libvisio-0.1.7:0/0::gentoo, installed) dev-libs/icu:0/64.2= required by (app-text/libebook-0.1.2-r1:0/0::gentoo, installed) dev-libs/icu:0/64.2= required by (app-text/libmspub-0.1.4:0/0::gentoo, installed) dev-libs/icu:0/64.2 required by (app-office/libreoffice-bin-6.2.8.2:0/0::gentoo, ebuild scheduled for merge) ^^^ >=dev-libs/icu-59.1:0/64.2= required by (dev-lang/spidermonkey-60.5.2_p0-r2:60/60::gentoo, installed) dev-libs/icu:0/64.2= required by (mail-mta/postfix-3.4.5-r1:0/0::gentoo, installed) >=dev-libs/icu-51.2-r1:0/64.2=[abi_x86_32(-),abi_x86_64(-)] required by (media-libs/harfbuzz-2.6.4:0/0.9.18::gentoo, installed) dev-libs/icu:0/64.2= required by (media-libs/raptor-2.0.15-r2:2/2::gentoo, installed) >=dev-libs/icu-3.6:0/64.2=[abi_x86_32(-),abi_x86_64(-)] required by (dev-libs/boost-1.71.0:0/1.71.0::gentoo, installed) dev-libs/icu:0/64.2= required by (media-libs/libcdr-0.1.5:0/0::gentoo, installed) dev-libs/icu:0/64.2= required by (media-libs/libzmf-0.0.2:0/0::gentoo, installed) --- Preliminary solution was inserting '>dev-libs/icu-64.2' in package.mask. At the moment the emerge runs through and is at (107 of 188). Will take some time before that is finished. - I am using a mostly stable Gentoo. icu-65.1 has just reached stable and caused the mess. Seems to be a bug. Hartmut
[gentoo-user] Re: Mounting USB sticks automagically.
Grant, On Wednesday, 2019-12-18 15:57:41 -, you wrote: > ... > I do it by manually writing udev rules that watch for specific devices > and mount them at particular paths. It used to work out of the box without writing udev rules. > handled by the "desktop" enviroment — which you don't mention. I'm using Xfce. Sincerely, Rainer
Re: [gentoo-user] Mounting USB sticks automagically.
Mick, On Tuesday, 2019-12-17 23:44:19 +, you wrote: > ... > And ... usually by the sys-fs/udisks package, which performs the > automounting. > If for some reason you have uninstalled udisks, $ equery --no-color list -F '$mask2,$location $fullversion:$slot $cp' sys-fs/udisks * Searching for udisks in sys-fs ... amd64,IP- 2.8.4:2 sys-fs/udisks $ And before I forget: hibernate, suspend, shutdown, and restart also do no longer work for an unprivileged user. I only noticed that yesterday evening when I pressed the power button which I have configured to do hibernation. It only locked the screen. However, # echo disk > /sys/power/state did work. Sincerely, Rainer
Re: [gentoo-user] Mounting USB sticks automagically.
Neil, On Tuesday, 2019-12-17 21:35:11 +, you wrote: > ... > This is normally handled by the desktop environment, which desktop are > you using? Xfce. Sincerely, Rainer
[gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …
On 2019-12-18, (Nuno Silva) wrote: > The EAPI problem is in a package that is pulled as a dependency of > portage. > > Unless there's a simple hack to solve this, you will need to use older > ebuilds or split the update in several steps, using older versions of > the portage tree. The following notes show a way of achieving this: > > https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo In my experience of situations like this, it's often a lot less work to just backup /etc and user home directories and re-install from scratch. That's not to say I didn't once battle my way through an upgrade like that just to see if I could do it... -- Grant Edwards grant.b.edwardsYow! I'm continually AMAZED at at th'breathtaking effects gmail.comof WIND EROSION!!
[gentoo-user] Re: Mounting USB sticks automagically.
On 2019-12-17, Dr Rainer Woitok wrote: > Can someone please guide me to rig up my box so it again mounts plugged > in USB sticks automatically to "/run/media/.../"? I do it by manually writing udev rules that watch for specific devices and mount them at particular paths. On most systems, it was probably handled by the "desktop" enviroment — which you don't mention. -- Grant Edwards grant.b.edwardsYow! Are you mentally here at at Pizza Hut?? gmail.com
[gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …
On 2019-12-18, Ilya Trukhanov wrote: > On Sun, Dec 15, 2019 at 07:01:15PM +0100, Thomas Schweikle wrote: >> The current version of portage supports EAPI '6'. You must upgrade to a >> newer version of portage before EAPI masked packages can be installed. > > The message is pretty clear. You need to upgrade portage first. Try > `emerge -1 portage`. This should take care of the EAPI message. The EAPI problem is in a package that is pulled as a dependency of portage. Unless there's a simple hack to solve this, you will need to use older ebuilds or split the update in several steps, using older versions of the portage tree. The following notes show a way of achieving this: https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo -- Nuno Silva
Re: [gentoo-user] abendbrot overlay missing?
On 18.12.19 11:19, Ilya Trukhanov wrote: > Seems to be gone from: > https://github.com/gentoo-mirror/abendbrot > https://qa-reports.gentoo.org/output/repos/ > > Anyone knows what happened to it? And any way to learn about this in > advance? Doesn't look like repositories.xml is version controlled, couldn't > find anything in the mailing lists, either. > https://gitweb.gentoo.org/data/api.git/log/files/overlays/repositories.xml removed in the following commit: repositories.xml: Remove inactive repos with issues https://gitweb.gentoo.org/data/api.git/commit/files/overlays/repositories.xml?id=ecb82a86b7af1a29f12f56c6c25a044890d7be80
[gentoo-user] abendbrot overlay missing?
Seems to be gone from: https://github.com/gentoo-mirror/abendbrot https://qa-reports.gentoo.org/output/repos/ Anyone knows what happened to it? And any way to learn about this in advance? Doesn't look like repositories.xml is version controlled, couldn't find anything in the mailing lists, either.
Re: [gentoo-user] trying to upgrade some old, never upgraded image for an embedded system …
On Sun, Dec 15, 2019 at 07:01:15PM +0100, Thomas Schweikle wrote: > The current version of portage supports EAPI '6'. You must upgrade to a > newer version of portage before EAPI masked packages can be installed. The message is pretty clear. You need to upgrade portage first. Try `emerge -1 portage`. This should take care of the EAPI message. Good luck with the 17.1 profile migration. Though if the system is not amd64, you should have nothing to worry about.
Re: [gentoo-user] safe use of .gnupg
On Wednesday, 18 December 2019 07:33:51 GMT Andrew Udvare wrote: > > On Dec 17, 2019, at 20:51, Philip Webb wrote: > > > > When encrypting a file, I was told : > > root:552 root> gpg -c > > gpg: WARNING: unsafe ownership on homedir '/home/purslow/.gnupg' > > > > The file is owned by my user, ie : . > > This seems to be the default when 'gpg' is installed. > > It's probably complaining if you're running as root and you've set the GPG > home did to be in /home/purslow/.gnupg rather than /root/.gnupg (and owned > by root:root). Otherwise try setting that directory to 0700 permission > (u+rwx g-rwx o-rwx). > > Andrew Other than what Andrew said, you're using a symmetric cipher, so the complaint is only a warning about the ownership of the gnupg configuration file being used. You may wish your root user to have different gnupg settings than your plain user and gnupg is warning you about it. However, this is rather odd. When you first use gnupg as root (or as any user) without specifying a configuration file, it will try to create a new ~/.gnupg directory with default settings and public/private keys; e.g. # gpg -c gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created Given the above the directory and files in /root/.gnupg should be owned by root:root, rather than root:552 (if '552' in your message is some group ID). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
