Re: [gentoo-user] Update gentoo from live usb?
On Sun, Jan 30, 2022, 01:36 Andreas Fink wrote: > Hello, > > I have a couple of systems that I do not update regularily (some not > even for years). But then sometimes I feel, hey I should do an update. > I have one master build server which builds packages and keeps them as > binary packages, annd all my systems pull the gentoo portage tree from > this master build server, additionally also the configs in /etc/portage > is the same amongst all boxes, i.e. use flags et al are all the same. > > Now comes the misery when I want to update an old box, because of > unsupported EAPI and what not. One way that I used in the past was to > extract a stage-3 tarball over the existing root system, and then do > the upgrade, which works to some extent, but it does not seem right. > Coming now to my question: Is it possible to start a live gentoo system > with a recent portage version and then tell portage that it should > install the packages in /mnt/gentoo (which is the real system I care > about). I have heard about the prefix project, but I'm not sure if this > is exactly what I want. > Maybe a second approach would be to get the minimal set of binary > packages from the master build server and extract them manually, such > that I end up with a recent enough portage which supports all EAPIs > that are in the tree. But I have no clue how to get the minimal set of > packages that I would need to extract. > > Does anybody have other approaches (besides starting from scratch)? > Portage is supposed to offer an upgrade path for any system up to a year out of date. If you grab the version of portage from the last upgrade time of the system being updated plus 6-12 months (however daring you feel like being) you should be able to upgrade it that much without needing to do a lot of fiddling. Repeat until you're updated. Going forward, you could consider having your build host take a snapshot / backup of the binpkgs it builds every 3-6 months, with the associated portage tree, so that you can use those to update your sporadically updated machines. I strongly recommend against overwriting your system with a stage3. Any package that has a changed list of files will leave orphans behind. And finding them all will be pretty dang hard. Personally I just make a point to keep my not very large number of machines updated, but I do it by hand. You might want to look and see if anyone's written any scripts that automatically update + restart services / reboot periodically, and email you upon problem >
Re: [gentoo-user] Suggestions for NAS appliance?
On Fri, Nov 12, 2021 at 11:31 AM Laurence Perkins wrote: > > > > -Original Message- > > From: Peter Humphrey > > Sent: Friday, November 12, 2021 12:19 AM > > To: gentoo-user@lists.gentoo.org > > Subject: Re: [gentoo-user] Suggestions for NAS appliance? > > > > On Thursday, 11 November 2021 22:43:17 GMT Mark Knecht wrote: > > > On Thu, Nov 11, 2021 at 3:21 PM Laurence Perkins > > > > > wrote: > > > > The genpi64 project is supposedly back up and running, so you can > > > > get newer images that need fewer updates again. > > > > > > > > > > > > > > > > From: Mark Knecht > > > > Sent: Wednesday, November 10, 2021 8:06 PM > > > > To: Gentoo User > > > > Subject: Re: [gentoo-user] Suggestions for NAS appliance? > > > > > > Do you have a better URL than I have? > > > > > > https://github.com/sakaki-/gentoo-on-rpi-64bit > > > > I gogled for 'genpi64 project' and got this: https://github.com/GenPi64 > . > > > > -- > > Regards, > > Peter. > > Yes, that one. I think the build.dist is the repo you want. I don't know > if they're providing finished images yet or not, but it should at least be > capable of building them for you on something more powerful than the pi > itself. > > LMP > I am one of the contributors to the new/reincarnated GenPi64 project. The build.dist repository contains our image builder, and you should be able to run it on the raspberry pi itself, or on an x86_64 machine. I recommend using the alpha9 branch of the repository, it has the latest improvements. It basically downloads an aarch64 stage3, and chroots into it and runs various configuration commands, including emerge to install new packages. The builder doesn't currently setup a distcc cross-compiler for you, but there are patches available for that if you really want to give that a try. It's tricky to set up. You might have some trouble with the kernel build, or the final image partition setup, but we're happy to help out if you just open an issue on github. We do have hosted images here: https://packages.genpi64.com/ -- be warned, these are not considered high quality yet. But they work well enough for the several people who've reported back to us. and our readme here: https://github.com/GenPi64/gentoo-on-rpi-64bit We're actively looking for more contributors. Currently it's just 3 very busy people, so any help is good help.
[gentoo-user] Can't attach file to bug on bugs.gentoo.org
Just me? Or something wrong? Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at webmas...@gentoo.org to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log. -- Apache Server at bugs.gentoo.org Port 443
Re: [gentoo-user] an efficient idea for an alternative portage synchronisation
On Fri, Jun 18, 2021, 07:10 caveman رَجُلُ الْكَهْفِ 穴居人 < toraboracave...@protonmail.com> wrote: > tl;dr - i'm suggesting a new file syncing protocol > for portage syncing. details of this one is in > section 2. > > > 1. background > - > rsync needs to read all files in order to compare > them. this is too expensive and doesn't scale as > portage's tree grows in size.. > > on the other hand, git gets away with this, by > maintaining a history of edits. so git doesn't > need to compare all files, instead it walks > through the history. > > but git has another issue: the history getting > too big. this causes: > - `git clone` to needlessly take too long, as > many old histories become irrelevant as they > get fully overwridden by newer ones. > - this also causes `git pull` to be slower > than needed, as the history is not ideally > compressed. > - plus, the disk space that's wasted for > histories. > > > 2. new protocol > --- > to solve issues above, i think the ideal solution > is this protocol: > - each history is a number representing a > logical clock. 1st history is 0, 2nd is 1, > etc. > - the server maintains a list of N past many > histories of the portage tree. > - when a client requests to update its portage > tree, it tells the server its current > history. e.g. say client is currently > located in logical time 1234567. > - the server is maintaining only the past N > histories: > - if 1234567 is behind those maintained N > ones, then the server sends a full > portage tree from scratch. > - if 1234567 is within those maintained N > ones, then the server has two options: > (1) either send all changes since > 1234567, as they happened > historically. this is a bad idea. > no good reason for it. > > (2) better: the server can send the > compressed histories. compressed > histories are done once, and > cached, in a scalable way. the > cache itself is incremental, so > updating the cache is cheap > (details section 2.2.). > > e.g. if there are 5000 histories > that the client lacks since time > 1234567, then there is a chance > that many of the changes are just > a waste of time. e.g. add a file, > then delete the same file, then > add a different file again. so > why not just lie about the > history, and send the last file, > escaping ones int he middle? same > can be thought about diffs to code > blocks. > > 2.1. properties of this new protocol > > so this new protocol has these properties: > - unlike rsync, it doesn't need to compare all files > individually. > - unlike git, the history doesn't grow on the > client. history remains only a single > number representing a logical clock. > - the history on the server is limited to N > past entries. no devs will cry, because > this is not a code collaboration app, but > simply a file synchronisation app to replace > rsync. so the admins are free to set N as > small as they please, without worrying about > harming collaborating devs. > - server has the option to compress histories > to clients, and these histories are > cacheable for more performance. > > > 2.2. how it will feel to admins/devs > > - the devs simply commit their changes to the > portage tree via git. > - the git server will have hooks to execute an > external command for this new protocol, that > will calculate all diffs necessary in order > to build a new history. > > e.g. if current history is 3, and a dev > makes a new commit via git, then the git > hooks will execute the external command to > calculate the diff for the affected files by > the git commit, such that history 30001 is > created. > > the hooked external command will also see if > it can compress the histories, for the past > M many entries since 30001. > > so that clients that live in time 30001-M, > who ask for 30001, can get the compressed > history instead of raw actual histories from > 30001-m to 30001. > > ty, > cm > It seems like you are almost asking for git's --clone-depth and --sync-depth flags. Its not an exact match for your proposal but its very close. >
Re: [gentoo-user] I am thinking of buying Raspberry Pi 4 Model B 8GB with 7 or 10 inch touch screen display in June 2021
On Sun, May 9, 2021 at 4:29 PM Nils Freydank wrote: > The Raspberry Pi image (stage3) seems to be unmaintained so far: > https://wiki.gentoo.org/wiki/Raspberry_Pi#gentoo-on-rpi3-64bit > There's a maintained image for 64bit raspberry pi's with this project: https://github.com/GenPi64
Re: [gentoo-user] Console scrollback is back again!
On Tue, Apr 6, 2021 at 4:54 AM Alan Mackenzie wrote: > Hello, Michael. > > On Mon, Apr 05, 2021 at 18:08:58 -0500, Michael Jones wrote: > > [ ] > > > Without looking at the patch itself: > > > Have you considered something like kmscon as a userland alternative? > > To be honest, no. I wasn't really aware of it when I starting working on > the Linux console. > > According to Wikipedia, the last release was in 2013, and development > stopped altogether in 2015. The Gentoo package for it is masked. > Good points, and I can't speak to the code cleanliness of kmscon, or potential security problems. That being said, even though I was annoyed when the scrollback was removed from the kernel, I do understand the reason for it being removed. It does seem like the kind of functionality that would be better provided by userspace. > > I installed it on my laptop, and aside from not working with gpmd or > > consolation for mouse support, it's a perfectly functional local tty. > > I suppose it's one of these programs that once working, pretty much > carries on working for ever. > That's entirely possible :-) Maybe someone (not necessarily you) will find the removal of the scrollback buffer to be enough motivation to bring kmscon back to life as a project.
Re: [gentoo-user] Console scrollback is back again!
On Mon, Apr 5, 2021, 13:13 Alan Mackenzie wrote: > Hello, Wol. > > On Mon, Apr 05, 2021 at 18:44:15 +0100, antlists wrote: > > On 05/04/2021 18:12, Alan Mackenzie wrote: > > > Bug reports and other comments are welcome, of course. > > > > > > If anybody would like the corresponding patch which works on 5.4.n, > for n > > >> = 80, that is available, too. > > > Why did it get removed from the kernel? > > Allegedly, there were security problems with it. I think the kernel > people had a program which fired random inputs at lots of components, > and noted when things went wrong; and things went wrong in the scroll > back component. And they couldn't find anybody to look into these > problems. > > That's the official position. I'm a bit more cynical about it. > > > If you want to get it back in, couldn't you ping Greg KH and get some > > help - or even just advice - getting it accepted? > > I have no reason to believe all the "security problems" will have been > resolved by my hacking. I took the algorithmic bits from 4.19.97 > basically unchanged. > > Maybe there's not much enthusiasm for this feature, in which case I will > keep it working for myself. Linux is basically unusable to me without > it. There are probably quite a few patches to restore the scrollback > floating around the web by now: the changes were not particularly > difficult to anybody who knows the code, but getting to know the code > was unusually difficult. > > We'll see how people react to it here, first. > > > Cheers, > > Wol > > -- > Alan Mackenzie (Nuremberg, Germany). Without looking at the patch itself: Have you considered something like kmscon as a userland alternative? I installed it on my laptop, and aside from not working with gpmd or consolation for mouse support, it's a perfectly functional local tty.
Re: [gentoo-user] Gentoo on rpi
Help wanted https://github.com/GenPi64/Build.Dist On Mon, Feb 8, 2021, 09:36 Peter Humphrey wrote: > Hello list, > > I have a Pi 400, on which I'd like to install Gentoo if I can. I've tried > a > few approaches so far, but each one has fallen foul of some obstacle. For > instance, today I tried installing a small Gentoo system into a chroot, to > do > the compiling there. It seemed to be going well until time came to upgrade > openssl. It stopped when it couldn't cope with the ARM platform. Zlib also > failed, needing static compilation, I think. > > I see references to using crossdev, wine and taking a prebuilt system from > various sources, but I haven't found a way through yet. > > What setup do people use for compiling for Raspberry Pi? > > -- > Regards, > Peter. > > > > >
Re: [gentoo-user] Re: Gentoo as NAS
Use the plex overlay. It's updated regularly. Faster than the official gentoo repo was. On Thu, Feb 4, 2021 at 5:56 PM Grant Edwards wrote: > On 2021-02-04, Neil Bothwick wrote: > > On Thu, 4 Feb 2021 15:04:14 -0300, Raphael MD wrote: > > > >> Said that, what could be the effort to turn my Gentoo in a NAS service, > >> setting up SAMBA, Plex, quotas and ZFS? > > > > I see Plex as the main problem, as it is no longer in portage. > > One way round that would be to run it under Docker. > > The whole Plex thing is something I need to figure out. I suppose it's > either give up on it completely or Docker. Complaints in the Plex > forums about it using an obsolte version of Python are pretty much met > with a response of "shut up and go away". :/ > > -- > Grant > > > >
Re: [gentoo-user] Gentoo as NAS
I do this with btrfs instead of zfs. Its no more complicated than any other service configuration. Gentoo doesn't make this harder or easier than any other distribution. On Thu, Feb 4, 2021, 12:04 Raphael MD wrote: > Hello everyone, > > I'm thinking about using Gentoo as a NAS serve. I know there are some NAS > distributions like FreeNAS that are claimed to be rock solid, but FreeNAS > support for GPU and other things sounds poor to me. > > Said that, what could be the effort to turn my Gentoo in a NAS service, > setting up SAMBA, Plex, quotas and ZFS? > > Anyone has already tried it? > > Thanks! > > M.S. Raphael Mejias Dias > Nuclear Engineer | Reactors > > Secure e-mail: raphael.mejias.d...@protonmail.com > PGP Key for raph...@gmail.com: > https://pgp.mit.edu/pks/lookup?op=get=0x87BC5A746072F951 >
Re: [gentoo-user] [OT] rsync rules question
On Wed, Oct 14, 2020 at 2:48 PM antlists wrote: > On 14/10/2020 20:22, Neil Bothwick wrote: > > Alternatively, for more instant updates, you could look at > > net-p2p/syncthing. > > Not sure what you use for it, but there are mirrored filesystems that > run over a network. So the two systems will update in sync if they're > both switched on, or will defer updates and sync as soon as the second > system powers up. > > Cheers, > Wol > > Could you list a few examples to help people find filesystems like this?
[gentoo-user] Pam configuration for winbind
With the recent update to sys-auth/pambase-20201013, i find myself struggling to understand how to adapt the new default configuration to work with winbind. I'm writing to the list for help with this. First, I'll provide my current system-auth, the new system-auth that comes from sys-auth/pambase-20201013, and my attempt at merging the two versions. After those items, I have several questions which I'll ask at the end of my email. First, here's my current /etc/pam.d/system-auth file: authrequired pam_env.so authsufficient pam_unix.so try_first_pass likeauth nullok authsufficient pam_winbind.so use_first_pass authrequired pam_deny.so account sufficient pam_unix.so account required pam_winbind.so password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow password sufficient pam_winbind.so use_authtok password optional pam_permit.so session required pam_limits.so session required pam_env.so session required pam_unix.so session required pam_winbind.so session optional pam_permit.so Here's the new version that comes from sys-auth/pambase-20201013 with the useflags: gnome-keyring nullok passwdqc sha512 systemd authrequired pam_env.so authrequired pam_unix.so try_first_pass likeauth nullok authoptional pam_permit.so authrequired pam_faillock.so preauth authsufficient pam_unix.so nullok try_first_pass auth[default=die] pam_faillock.so authfail account required pam_unix.so account optional pam_permit.so account requiredpam_faillock.so password required pam_passwdqc.so config=/etc/security/passwdqc.conf password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow password optional pam_permit.so session required pam_limits.so session required pam_env.so session required pam_unix.so session optional pam_permit.so Here's my attempt at merging these two together. authrequiredpam_env.so authrequiredpam_faillock.so preauth authsufficient pam_unix.so nullok try_first_pass authsufficient pam_winbind.so use_first_pass authrequisite pam_faillock.so authfail account requiredpam_faillock.so account sufficient pam_unix.so account sufficient pam_winbind.so account optionalpam_permit.so passwordrequiredpam_passwdqc.so config=/etc/security/passwdqc.conf passwordsufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow passwordsufficient pam_winbind.so use_authtok passwordoptionalpam_permit.so session requiredpam_limits.so session requiredpam_env.so session requiredpam_unix.so session requiredpam_winbind.so session optionalpam_permit.so Questions: 1. Why does sys-auth/pambase use the "likeauth" flag? I cannot find any real information about this except for a redhat bugzilla ticket that says it's for legacy usage from 2004. https://bugzilla.redhat.com/show_bug.cgi?id=120418 2. Why is pam_faillock.so used with "preauth" after the first use of pam_unix.so ? The manpage for pam_faillock.so says that faillock should be called with the "preauth" command prior to asking for the user's password. 3. Why is pam_permit.so used as the last item in each section other than auth? The manpage for pam_permit indicates that this module always returns success. Using it as an optional module is a no-op. 4. Why is pam_faillock.so the last module for the "account" type, instead of the first module, as from the example in the manpage? 5. Why use [default=die] instead of requisite for pam_faillock.so in the auth section?
Re: [gentoo-user] gcc is being built again??
On Tue, Sep 29, 2020 at 12:48 PM n952162 wrote: > 10 weeks ago, I updated my system and it took days to build. I just > started a new update of my system, and it looks like it will take at > least more than a day again ... > > Why is gcc being rebuilt after 10 weeks, for example? > > Need more information. Show the result of emerge --update --newuse --changed-use --deep @world -p
Re: [gentoo-user] Raspberry Pi with 8GB
On Sun, Jun 7, 2020 at 8:40 PM james wrote: > Gentoo Folks, > > Has anyone ported gentoo to the newest Raspberry Pi > with 8 gig of ram? > > > https://www.admin-magazine.com/News/Raspberry-Pi-with-8GB-of-RAM-Now-Available > > If so, I'd be curious as to your performance and using it as a > workstation or mobile/laptop. > > https://projects.raspberrypi.org/en/projects/raspberry-pi-setting-up > > None of the usual gentoo embedded sites I have search list gentoo on > this device. > > All input is welcome. 8GB on a 64 bit arm low power (embedded) board, or > a cluster of 4+ such boards is > of keen interest to my new, gentoo centric low power goals. > > > TIA, > James > > This is the current state of the art, as far as I am aware. https://github.com/sakaki-/gentoo-on-rpi-64bit
Re: [gentoo-user] Re: Gentoo RPi boot to ram or read-only FS?
On Tue, May 26, 2020 at 1:27 PM Neil Bothwick wrote: > On Tue, 26 May 2020 19:14:18 +0100, antlists wrote: > > > > That's the Gentoo version that I'm using. But I'm looking for a way > > > to make it bullet-proof to having the plug pulled. > > > > Don't use an SD card? Seriously, pulling the power on an SD card has > > been known to corrupt it beyond recovery. BUT. > > Mounting the card with sync will significantly reduce the likelihood of > corruption, at a cost of reduced life. > > > Is the big worry that the home directory will get corrupted etc etc? I > > don't know if you can partition an SD card, but look at doing a > > kiosk-style install with the OS protected and read-only. Then look at > > sticking a loopback device on top of home, so that any changes exist > > only in ram, and are lost on shutdown. Hopefully, that means you now > > have a system that can boot and run off a write-protected SD card :-) > > This will mitigate the reduced life as you are hardly writing to the > card. Booting from a read-only / has caused problems for me in the past, > because of the inability to write to /etc. > Consider a hybrid approach like how many embedded systems do things. E.g. openwrt. /root is actually a read-only squashfs image, and on top of that there's an overlay fs that uses a second partition as it's backing storage. This way, almost all of your system is purely read-only, but you have the ability to store changes to things you need to store changes for.
Re: [gentoo-user] Re: Gentoo RPi boot to ram or read-only FS?
On Tue, May 26, 2020 at 12:16 PM Grant Edwards wrote: > On 2020-05-26, Frank Tarczynski wrote: > > > I'm building a video conference appliance using a Raspberry Pi 4 for > > my parents. > > Sorry, no advice running Gentoo on RPi. I run OSMC/Kodi on an older > RPi, and it works fine, but I don't think there are any video > conference apps for Kodi. > > But... > > For skype and zoom, I'd probably just buy them a 10" Kindle Fire. > > There are Zoom and Skype apps available for it. Main drawback: > smallish screen and limited to 4 video windows at a time in > zoom. However, it's portable: you can flip to the back camera and walk > around the house/yard to show something to people. It's also nice in > that you can just tap on a Zoom invite url in the email app, and it > "just works". > > I haven't trie Skype on Fire. > > You can add hangounts/duo, but you've got to futz around sideloading > the Google App store first. > > -- > Grant FYI, this project exists: https://github.com/sakaki-/gentoo-on-rpi-64bit
Re: [gentoo-user] Getting rid of unwanted languages (Was: Re: gimp help not available, even with USE doc)
On Mon, May 4, 2020 at 10:31 AM Peter Humphrey wrote: > On Monday, 4 May 2020 15:08:12 BST Dr Rainer Woitok wrote: > > Here are mine for comparison: > > # grep -E '^(LANG|LC_|L10)' /etc/portage/make.conf > L10N="en-GB en" > LANG="en_GB.UTF-8" > LANGUAGE="en_GB.UTF-8" > > I can't find any documentation on the use of "LANG" or "LANGUAGE" in /etc/portage/make.conf. I'm looking here: https://wiki.gentoo.org/wiki//etc/portage/make.conf#LINGUAS Is there another source that describes these variables and how to use them?
Re: [gentoo-user] prevent users from shutting down while other users logged in
On Wed, Apr 29, 2020 at 11:19 AM Raffaele BELARDI wrote: > I often have the kids working on my main ~amd64 PC (XFCE, OpenRC, > -consolekit) while I ssh into it doing some maintenance from an old PC. > Often they shut it down without telling me first, so I loose part of my > stuff. Is there a way to tell XFCE/elogind/PAM/lightdm/whoever to not allow > shutdown from a regular user while another user is logged in? I understand > that logind/systemd provides the system-inhibit [1] user command just for > that, but I don’t find the analogous for OpenRC/elogind. > > > > Basically I’d like that: > > - if there is more than one user logged in, either locally via lighdm or > remotely via SSH, the shutdown XFCE button is grayed out. Once all users > except one have logged out, the button is again available > > - from the ssh shell the command would be always available (root or normal > user, I don’t care) > > - permanently disabling the shutdown for the kids is not optimal, they > should be able to stop the machine if he/she is the only user > > > > Thanks, > > > > raffaele > > > > [1] https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html > > > What's to stop them from shutdown via the physical power button? I know that's almost always how I shut down a computer, and I tend not to even think of using the menu. As for how to inhibit, you'll probably need to combine something that reads the currently active user sessions, with a patch to the XFCE menu to use that information.
Re: [gentoo-user] Gentoo Tinderboxes?
On Thu, Apr 23, 2020 at 3:21 PM Steven Lembark wrote: > > Q: You have Docker (or any other lxc) running on something local? > > We could use my system here as a sandbox. There should be a decent > way to have a "gentoo-qc" image for testing: Just snag the image and > have it "emerge --update" to see what works, or something similar. > > > -- > Steven Lembark 5725 Aylesboro Ave > Workhorse ComputingPittsburgh PA 15217 > lemb...@wrkhors.com+1 888 359 3508 > If this question is directed at me, then here's some information: 1) Already installed, and used regularly: systemd-nspawn 2) Docker, or others: Well, whatever tool is needed is only an emerge away If someone were to add (or, if there is already such a feature and I'm just not aware...) automatic build log uploads on failure to the make.conf FEATURES variable, I would also be OK to enable that on my equipment.
Re: [gentoo-user] Is Gentoo dead?
On Thu, Apr 23, 2020 at 1:15 PM Caveman Al Toraboran < toraboracave...@protonmail.com> wrote: > On Wednesday, April 22, 2020 9:34 PM, Michael Orlitzky > wrote: > > > Dependency resolution is indeed a (formally) hard problem. Solving the > > traveling salesman problem is also hard. Solving the traveling salesman > > problem while being punched in the face is even harder. When I complain > > about portage being slow, what I mean is that I want to stop being > > punched in the face so that I can concentrate all of my energy on the > > underlying hard problem. > > any reason why is it a traveling salesman problem, > and not just a tree walk with heuristics to handle > exceptions (e.g. cycles)? > > You can see more information about the portage dependency solver situation with this mailing list post: https://archives.gentoo.org/gentoo-dev/message/40f9585ba6a9850eb82853d945d608eb The github repository in question is here: https://github.com/HyVar/gentoo_to_mspl/ Note: I have nothing to do with this project, I just remembered the mailing list post, and thought it was a good idea.
Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, Apr 22, 2020 at 2:19 PM Michael Orlitzky wrote: > On 4/22/20 3:15 PM, Michael Jones wrote: > > > > Why would I need to emerge world? Portage knows the full list of > > packages that depend on openssl, transitively. > > > > Unless you're generalizing to say that (almost) everything depends on > > openssl, I suppose. > > > > Also, didn't the handbook, at one point, say not to sync portage more > > than once a day? So why would package installations happen 20 times per > > day? > > It's not that everything depends on OpenSSL, but that everything depends > on /something/. If everything is statically linked, then any update of > any package sets off a chain reaction of other packages that trigger > rebuilds of other packages that trigger rebuilds of... > > If you only sync once a day, then yes, you'll only have to rebuild once > a day. I sync considerably more than that though, and besides, it takes > me about a week to emerge -e @world. > > Well, I suppose that's the consequence that someone would have to accept if they wanted to link things statically. I use static libraries for work in some situations, and understand the cost of using them But I don't generally want my entire system statically linked, only a few things. Regardless, thank you for clarifying.
Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, Apr 22, 2020 at 1:33 PM Michael Orlitzky wrote: > On 4/22/20 2:24 PM, Michael Jones wrote: > > > > > > On Wed, Apr 22, 2020 at 1:19 PM Michael Orlitzky > <mailto:m...@gentoo.org>> wrote: > > > > How do you plan to update all of your programs when there's a > security > > vulnerability in, say, OpenSSL? > > > > > > Is there some reason why all packages that depend on OpenSSL, > > transitively, could not be recompiled? > > If you statically link more than a few things, this is emerge -e @world > twenty times a day. > > Why would I need to emerge world? Portage knows the full list of packages that depend on openssl, transitively. Unless you're generalizing to say that (almost) everything depends on openssl, I suppose. Also, didn't the handbook, at one point, say not to sync portage more than once a day? So why would package installations happen 20 times per day?
Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, Apr 22, 2020 at 1:19 PM Michael Orlitzky wrote: > How do you plan to update all of your programs when there's a security > vulnerability in, say, OpenSSL? > Is there some reason why all packages that depend on OpenSSL, transitively, could not be recompiled?
Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, Apr 22, 2020 at 11:47 AM wrote: > C is more widespread, than C++. > Yes, this is true. > C++ is unneededly complex and for such core thing like a portage > C would be better. C code is simpler and robust. More people know it. > More people can send patches. Etc. > I disagree to the fullest, most intense, way possible. Nevertheless, this subject is way off topic for this list, so I'll just say we can agree to disagree, and not engage in the subject on-list any further. I'd be happy to discuss the subject with anyone who wants to contact me privately, however.
Re: [OBORONA-SPAM] Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, Apr 22, 2020 at 11:30 AM wrote: > > No-no. C++ is a nightmare. A few people want to use it. > C++ is an extremely widespread language with millions of lines of code written daily world wide. Lots of people want to use it. Just not people who want to write a PMS compliant package manager.
Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, Apr 22, 2020 at 11:28 AM Michael Orlitzky wrote: > I won't say this is impossible, but in general it hasn't been true for a > long time in Gentoo. Old libraries are left behind until you rebuild the > things that link against them (that's what emerge @preserved-rebuild > does). When used correctly, subslot dependencies in ebuilds avoid the > need for even that additional step. > > Right. Gentoo has safeguards in place already. Static-linking is only one tool in a large toolbox, and given Portage is a python program, it's not applicable to this situation. I was referring to the case of some hypothetical package manager built with C/C++. In that situation, staticly linking the package manager would provide one aspect of defense against self-breakage.
Re: [OBORONA-SPAM] Re: [gentoo-user] Is Gentoo dead?
On Wed, Apr 22, 2020 at 11:18 AM Alessandro Barbieri < lssndrbarbi...@gmail.com> wrote: > Nothing should be statically linked, please stop spreading the disease. > On a source-based distribution, the thing that manages package installations can break itself if it incorrectly installs a library that a subsequent run of itself would dynamically link against. There are plenty of valid use-cases for statically linked binaries. One such use case is that the C++ standard doesn't acknowledge the existence of dynamic linking in the first place. (It doesn't say it's invalid, just the standard doesn't address the concept one way or another, implicitly assuming static linking).
Re: [gentoo-user] Gentoo Tinderboxes?
On Wed, Apr 22, 2020, 04:46 Peter Humphrey wrote: > On Tuesday, 21 April 2020 23:36:21 BST Michael Jones wrote: > > On Tue, Apr 21, 2020 at 5:02 PM Gregory Rudolph wrote: > > > I would also offer up some computing power for that, on VMs, or > physical > > > hardware with different configurations. I'd like to be more involved > with > > > the Gentoo Development community, but time is rarely ever on my side. > > > > > > > > > Best wishes, gentoo's not dead, > > > > Right, I'm sitting on several big-beefy x86_64 machines (They're older > > machines, but they check out...) that typically are powered off. > > > > I would be happy to donate CPU cycles from one of them. > > Have you thought of contributing their power to BOINC projects? There's a > wide > choice. > > https://boinc.berkeley.edu/ > > "BOINC is an open-source software platform for computing using volunteered > resources." > > -- > Regards, > Peter. > They don't have GPUs (headless servers) so the calculations they can manage for boinc are going to be on the lower end. If it works similarly to folding at home. Not a bad suggestion. But at the moment I'm.more concerned with Gentoo QA >
Re: [gentoo-user] Gentoo Tinderboxes?
On Tue, Apr 21, 2020 at 5:02 PM Gregory Rudolph wrote: > I would also offer up some computing power for that, on VMs, or physical > hardware with different configurations. I'd like to be more involved with > the Gentoo Development community, but time is rarely ever on my side. > > > Best wishes, gentoo's not dead, > Right, I'm sitting on several big-beefy x86_64 machines (They're older machines, but they check out...) that typically are powered off. I would be happy to donate CPU cycles from one of them.
Re: [gentoo-user] Gentoo Tinderboxes?
On Tue, Apr 21, 2020 at 3:27 PM Rich Freeman wrote: > There are some QA/CI tools out there that have substantially improved > the quality of the distro, and most of them have started out as one > dev just creating a tinderbox or whatever and filing bugs when they > see problems. The only real downside to this is if somebody quits we > might lose these tools - but there are efforts to host them on infra > once we start to treat them as part of the core experience. When they > start out they're just one dev's random contributions and they may or > may not persist. > Speaking of tinderboxes: Is there any kind of QA tool that normal end users can contribute CPU cycles to? Given the massive combinatorial explosion of package configurations that can be installed using Gentoo, one might imagine that there's some value in simply installing programs with different USE combinations and running the self-tests for those programs. What I don't want to do is anything manual. Be it filing bugs, or testing things. But I'd be happy to run some arbitrary QA tool in a virtual machine or chroot nearly indefinitely.
Re: [gentoo-user] speedup remote portage
You can separate the package directory and distfiles directory from the ebuild tree. PORTDIR="/usr/portage" DISTDIR="/usr/portage-distfiles" PKGDIR="/usr/portage-packages" That lets you keep the ebuilds local to your laptop. On Wed, Feb 26, 2020 at 9:08 PM William Kenworthy wrote: > PORTDIR="/mnt/mfs/portage" > > /mnt/mfs is a moosefs fuse mount > > shared full tree including distfiles, and separate package files for > different hardware groups > > > BillK > > > > On 27/2/20 9:56 am, Michael Jones wrote: > > When you say you have a remote portage. What do you mean? > > The actual portage tree, with all the ebuilds? Or something else? > > On Wed, Feb 26, 2020, 18:08 William Kenworthy wrote: > >> Hi, >> >> due to space considerations on my laptop I have moved portage onto a >> network share (moosfs, mfsmounted) - slower but works fine. However, >> being a laptop trying to update/install when out and about is both very >> slow and network intensive through a vpn - again, it works but is even >> slower to the point of not always being practical >> >> Is there a way to localise/speedup portage scanning parts of the >> update/install process? >> >> 1. put it on a squashfs share to save space (the laptop is running btrfs >> with compression so I don't think that will get me much) >> >> 2. put portage on an sd card and mount it when necessary >> >> The laptop is a Surface Pro4 so expanding the storage is not practical - >> though I could shrink the windows partition a little more. >> >> BillK >> >> >> >> >>
Re: [gentoo-user] speedup remote portage
When you say you have a remote portage. What do you mean? The actual portage tree, with all the ebuilds? Or something else? On Wed, Feb 26, 2020, 18:08 William Kenworthy wrote: > Hi, > > due to space considerations on my laptop I have moved portage onto a > network share (moosfs, mfsmounted) - slower but works fine. However, > being a laptop trying to update/install when out and about is both very > slow and network intensive through a vpn - again, it works but is even > slower to the point of not always being practical > > Is there a way to localise/speedup portage scanning parts of the > update/install process? > > 1. put it on a squashfs share to save space (the laptop is running btrfs > with compression so I don't think that will get me much) > > 2. put portage on an sd card and mount it when necessary > > The laptop is a Surface Pro4 so expanding the storage is not practical - > though I could shrink the windows partition a little more. > > BillK > > > > >
Re: [gentoo-user] Re: Compiling first and then installing using -K
On Tue, Feb 25, 2020, 23:04 Dale wrote: > Dale wrote: > > > > P. S. Starting to wonder if I should copy my current install over and > > start there. I'd assume skipping /home, /proc and /sys would get me > > started. Still, gonna try the stage3 again. Just for giggles. Do all > > this while I cook some BBQ chicken for supper tomorrow night. > > > > Wanted to update on this, in case some other poor soul wants to go down > this path. The PS above is what I ended up doing. That stage3 tarball > never worked. It was like running in circles trying to emerge > anything. Plus, copying over from my current install gives me a 100% > clone of my install. So, I created a script, y'all would call it a > joke, to copy over all the directories/files from my current install. > That seems to work. I actually noticed I'm a version behind on > kde-plasma and am upgrading it in the chroot as I type. Once that is > done, I can copy over the binaries and do a emerge -k for the running > install. This is my scripts, y'alls jokes. lol > > > root@fireball / # cat /root/gentoo-mount > mount --types proc /proc /backup/gentoo-build/proc/ > mount --rbind /sys /backup/gentoo-build/sys/ > mount --rbind /dev /backup/gentoo-build/dev/ > > > root@fireball / # cat /root/gentoo-rsync-build > rsync -av --progress --delete /bin/* /backup/gentoo-build/bin/ > rsync -av --progress --delete /boot/* /backup/gentoo-build/boot/ > rsync -av --progress --delete /etc/* /backup/gentoo-build/etc/ > rsync -av --progress --delete /lib/* /backup/gentoo-build/lib/ > rsync -av --progress --delete /lib64/* /backup/gentoo-build/lib64/ > rsync -av --progress --delete /opt/* /backup/gentoo-build/opt/ > rsync -av --progress --delete /run/* /backup/gentoo-build/run/ > rsync -av --progress --delete /sbin/* /backup/gentoo-build/sbin/ > rsync -av --progress --delete /usr/* /backup/gentoo-build/usr/ > rsync -av --progress --delete /var/* /backup/gentoo-build/var/ > > echo "Sync done" > root@fireball / # > > > The first one mounts things, if they are not already mounted. The > second one syncs up everything, except /dev, /sys etc etc. > > I'll know in a couple hours or so how well this works. I can't see why > I would have any problems but . . . . . I'm me. ROFL :/ > > Dale > > :-) :-) > You might want to take a look at this : https://wiki.gentoo.org/wiki/Project:RelEng_GRS Its been a long time since I messed with it. But here's my configuration if it does you any good. https://github.com/jonesmz/grs/tree/desktop-amd64-hardened >
Re: [gentoo-user] Portage: how can I retain build directories?
On Wed, Feb 19, 2020 at 4:00 PM n952162 wrote:
> On 2020-02-16 17:34, Peter Humphrey wrote:
> > On Sunday, 16 February 2020 15:40:43 GMT n952162 wrote:
> >> On 2020-02-16 16:27, Michael Orlitzky wrote:
> >>> On 2/16/20 10:19 AM, n952162 wrote:
> Is there an option to inhibit that the build directories (presumably,
> those in /var/tmp) be retained instead of being cleaned up?
> >>> FEATURES=noclean says it will do that
> >> Ah, an environment variable. I hadn't thought of that.
> > Don't you have a FEATURES= line in make.conf?
> >
> No ... should I?
>
>
>
There are lots of features that you can enable or disable.
Here's what I have, for example:
FEATURES="${FEATURES} buildpkg binpkg-multi-instance clean-logs
compress-build-logs compressdebug installsources parallel-fetch
parallel-install split-elog split-log nostrip userfetch usersync"
Re: [gentoo-user] Desktop-no-multilib profile - possible?
On Wed, Feb 19, 2020 at 3:21 PM Holger Hoffstätte < hol...@applied-asynchrony.com> wrote: > Hi, > > I will never ever run 32bit software again and would really like to have > a desktop-no-multilib profile, in sync with the regular desktop but simply > without the multilib goop. My server is running precisely as I want with > plain no-multilib, and I know I could just copy my USE flags over and > maintain my own "self-made-desktop" settings, but that would mean I'd lose > all the defaults and ongoing updates, which *are* kind of nice. > > Suggestions and dirty hacks welcome. :) > > thanks, > Holger > > This is what I've done on my system. Maybe it'll help you, maybe it won't. Best of luck :-) - rm /etc/portage/make.profile mkdir /etc/portage/make.profile echo "5" > /etc/portage/make.profile/eapi cat >> /etc/portage/make.profile/parent <<< EOF ../../../usr/portage/profiles/default/linux/amd64/17.1 ../../../usr/portage/profiles/features/hardened/amd64 ../../../usr/portage/profiles/targets/systemd EOF
Re: [gentoo-user] Re: Compiling first and then installing using -K
On Tue, Feb 18, 2020 at 1:22 PM Rich Freeman wrote: > On Tue, Feb 18, 2020 at 2:06 PM Nikos Chantziaras > wrote: > > > > It gets worse. The container reconfigured the keyboard shortcuts on the > > host! After booting a container, alt+Fn or alt+left/right on the host > > started switching to the linux text-mode console. I pressed alt+f2 to > > bring up the plasma search, I ended up on TTY2... ha ha. > > > > Remember how I said I'll use nspawn from now on? I take that back. Let's > > just say this thing is not even remotely production ready. > > Never had any issues with it, but I've never tried to use my host root > as the input filesystem. I suspect the issue is that this is giving > the container access to the host /dev, /sys and so on, and thus the > container isn't ending up being contained. Normally you don't go > mounting a host /dev inside a container image before launching it... > > -- > Rich > > @Nikos Chantziaras In case it helps you at all, here's an example nspawn configuration file that I've been using for quite a while. I have a skeleton filesystem tree in /var/lib/machines/multimedia-state that bind-mount read-writable stuff. Everything else is read-only bind-mounted from my root FS. I store things like samba configuration, and local state, there. For example, the container is a member of my samba4 domain controller. I use systemd-machined to launch this container at boot. mimir /etc/systemd/nspawn # cat multimedia.nspawn [Exec] PrivateUsers=false MachineID=131472ae68624b99b5ce0bf18194cda1 [Files] BindReadOnly=/bin/ BindReadOnly=/usr/ BindReadOnly=/var/ BindReadOnly=/lib/ BindReadOnly=/etc/ BindReadOnly=/sbin/ BindReadOnly=/lib64/ BindReadOnly=/var/lib/machines/multimedia-state/etc/fstab:/etc/fstab BindReadOnly=/var/lib/machines/multimedia-state/etc/hostname:/etc/hostname Bind=/var/lib/machines/multimedia-state/var/log/:/var/log/ Bind=/var/lib/machines/multimedia-state/var/lib/samba/:/var/lib/samba/ Bind=/var/lib/machines/multimedia-state/var/cache/samba/:/var/cache/samba/ Bind=/var/lib/machines/multimedia-state/etc/systemd/system/:/etc/systemd/system/ TemporaryFileSystem=/home/ TemporaryFileSystem=/var/tmp/ TemporaryFileSystem=/var/lib/machines/ Bind=/media/raid/multimedia/ [Network] MACVLAN=general
Re: [gentoo-user] Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions)
> > > You might want to take note of the email address for Rich. He is a > developer and has a better understanding of the inner workings of Gentoo. > When he posts about how things work within Gentoo, he does it with > knowledge that most users don't have. > > The thing about Gentoo is this. There's not enough manpower to do > everything that every user wants. If a user wants something that the > current devs can't deliver, then that user has few options. If that user > is capable of creating a patch to fix a bug, then they can do so and apply > that patch locally. If that user can help with the ebuild and post > patches/fixes to BGO, git or whatever then they can do that. However, it > still falls to the active dev as to whether he/she applies it or not. It > could be that the patch fixes one problem but creates another based on USE > flags etc. The devs do tend to test fixes before putting them in the tree > even if the test may be limited in scope. The other option is to wait for > someone else to fix it, the bug to be fixed by the dev etc. I fall into > the last category because I don't code. Even my scripts don't deserve to > be called that but I don't think there is a name for my little script > thingys. > > Ignore Rich if you want but you would be the one missing out on inside > info. > > Dale > > :-) :-) > Thank you Dale. I'm well aware of who Rich is. That's why I was discussing the subject with him in the first place.
Re: [gentoo-user] Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions)
On Sun, Feb 9, 2020 at 8:07 PM Rich Freeman wrote: > You could have jumped through all the required hoops and still had it > ignored. > That's pretty horrible, honestly. Why isn't Gentoo doing better than that? Yes, yes, Gentoo is run by volunteers, so on and so forth. But it's entirely possible (and regularly accomplished in other organizations) to emphasise a culture that actively tries to not ignore low hanging fruit for so long. > > I'm not attempting to be contradictory for the sake of being > > contradictory, but the situation is significantly more complicated > > than what you said > > Not sure how that could be. I literally said "If you do report an > issue it might or might not get fixed." I'm pretty sure that hits all > the examples you supplied, being that it was basically a tautology. > There simply are no guarantees. > There's what you write, and what other people try to guess as to your meaning. Apparently you intended to mean the tautology, where I instead thought you meant something more interesting than that. Honestly, this conversation is just making me less interested in contributing to Gentoo in the future. Not only do 1-liner pull requests that fix broken packages get rejected / not fixed for a year, but now I'm being replied to with word-games when I try to discuss the issues that I face as an end-user. > Add to that, Gentoo has *so many bugs* that your bug tracking > > software, when told to simply "Give me all of the bugs" refuses to > > actually do so. > > It generally isn't a problem unless you run queries with no filters at > all. Sure, if you literally ask it for "all of the bugs" you won't > get them. So don't ask it for all of them. I'll note that even if we > closed all the bugs you'd still get the same error unless you only > asked for OPEN bugs. :) > > And if what you want is all old bugs closed, you can just filter by > date, and then you'll get all the benefits of those bugs being > filtered as far as query response limits are concerned. > My issue is that the list of open bugs is one of many proxy-indicators for other aspects of the Gentoo development process. While fixing the list of open bugs is not directly a fix for any of the potential underlying reasons for the various fuzzy and not clearly identified problems, it will very slightly reduce the overall "badness" while being trivial to implement. I imagine bugzilla already has some kind of plugin that would accomplish this that just needs to be enabled. > > Why should I continue opening new bugs, (or even better, provide > > patches) when I have new problems? > > Simple. If you provide a patch or bug you're more likely to get a > response than if you don't. There are no guarantees either way. > That's not supported by my experiences. Anecdotes aren't data, but so far the bug's reports and patches that I've provided get ignored, but the issues that I just wait to get fixed for me get fixed. So it seems to me like I should only file bugs for things that I want to inflict longer wait times on the rest of the community, and I shouldn't file bugs for things I actually want fixed. If you know of anyone who's attempted to do some statistical modeling of the bug fix rate in Gentoo, I would appreciate being connected to their research so I can stop feeling like a fool for attempting to help. > I don't see the problem as Gentoo not knowing that there are issues > > that should be tracked. I see it as a problem of Gentoo can't engage > > with it's user community in an effective way. And I see having over > > 10,000 open bugs as one of the barriers between effective user > > engagement and what we have today. > > I don't see how open bug counts are really the problem here. > The amount of open bugs, directly, is not the problem. The problem is that you're lying to people if you keep a bug in bugzilla open for 10+ years. You know it won't be worked on, they know it won't be worked on. So just close the bug. > Is there ever a time cutoff, after which a bug should automatically be > closed, in your opinion? > > No. > Then I'm not going to continue this discussion with you. Your perspective on this is utterly incompatible with mine. > > Surely if something hasn't been addressed in 20 years, it won't be? > > If nobody can bother to fix 20 year old bugs on some piece of > software, why would you be running it today, and thus why would you be > searching for bugs for it? > Then why is it still in the Gentoo package repository? If it's not in the Gentoo package repository, why is there an open bug in bugzilla about it? > Chances are if anybody is maintaining the package then it will > eventually get noticed and fixed. If nobody is maintaining it then > the open bugs aren't really impeding anybody doing fixes. > Again, this is contrary to my experiences, and what the Gentoo bug tracker has in it. > > 2. The maintainer of the package in question failed to address > > the problem, even to acknowledge
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
On Sun, Feb 9, 2020 at 5:55 PM james wrote: > Sure the many of the wonderful folks that visit gentoo-user would > participate, just a little bit? I would be willing to help. However, if left to my own devices, I would just close anything with no activity for 10 years, and remind the cc list of anything with no activity for 5 years of the bug as the first thing I did. So any effort that I participate in to try to improve that is going to need the Gentoo developers to give clear instructions on how they want the project to go.
[gentoo-user] Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions)
On Sun, Feb 9, 2020 at 5:43 PM Rich Freeman wrote: > Bugs get closed all the time. Bugs also get opened and and linger all > the time. I couldn't tell you the ratio, but that is the nature of > things. > > If you don't report an issue, and nobody else is aware of it, I can > pretty much guarantee that nobody will fix it. If you do report an > issue it might or might not get fixed. That's the nature of the > beast. Or in my case, I sometimes post 1-line pull requests to the Gentoo github, which fix packages being unable to compile, which get rejected because I didn't jump through enough hoops, and the bug remains unfixed for over a year after I open the PR. I stopped posting PRs after that, since it's a waste of my time. Or I post patches to Bugzilla for some package, the Gentoo maintainer agrees to accept them after Upstream reviews it, and upstream takes 3 years to review, with dead mailing list during that 3 year period. On the flip side, I regularly see issues get fixed between when I notice the issue, and the issue is reported (by myself in many cases) on Bugzilla. I'm not attempting to be contradictory for the sake of being contradictory, but the situation is significantly more complicated than what you said, but English is imprecise, so I understand that you're aware of these things. Filing bugs, or patches, or PRs, or instructions for fixing, or even attempting to get fixes into the appropriate upstream project, regularly results in no outcome for me at all. Neither positive or negative. Just nothing. Add to that, Gentoo has *so many bugs* that your bug tracking software, when told to simply "Give me all of the bugs" refuses to actually do so. Why should I continue opening new bugs, (or even better, provide patches) when I have new problems? I don't see the problem as Gentoo not knowing that there are issues that should be tracked. I see it as a problem of Gentoo can't engage with it's user community in an effective way. And I see having over 10,000 open bugs as one of the barriers between effective user engagement and what we have today. > Honestly, I'm not sure how having bots beg bug reporters about letting > their bugs be closed relentlessly (albeit at a very slow rate) until > they finally stop responding is going to improve things. Somebody > reports an issue and is frustrated that nobody does anything about it. > Is there ever a time cutoff, after which a bug should automatically be closed, in your opinion? I thought my proposal of a single reminder email after 5 years, and then auto-close after 10 years, was reasonable. Is 10 years for the reminder email, and 20 for the auto-close better? Surely if something hasn't been addressed in 20 years, it won't be? > Will reminding them that we didn't do anything about it in 5-10 years > improve how they feel about the issue? If they reply that it still is > an issue, will it help that we reply again in another 5 years to ask > if it is still an issue help? Yes, it will improve how I feel about it. Either: 1. The bug hasn't been acted on in the previous 5 years on bugzilla, but maybe it's been fixed and the original reporter / developer forgot to do anything in bugzilla about it. Or no one realized it was fixed. This kind of thing happens all the time. 2. The maintainer of the package in question failed to address the problem, even to acknowledge the problems existence, in the preceding 5 years. Maybe it fell through the cracks? Maybe it's being deliberately ignored? Computers can do things for us automatically, like remind people about things. > It seems like picking at a scab when the only people paying attention to a > bug are the reporter and a bot. > A scab that's failed to heal in 5 years is a pretty serious injury. > My gut feeling is that this sort of thing will make people even less > likely to report new bugs they find, because they're constantly being > reminded of ancient situations where this turned out to be a waste of > time. If they weren't reminded of this they'd be more likely to > report an issue, and that might or might not be a waste of time. > So stop making it a waste of people's time? You're reaction to this suggestion gives me the impression that Gentoo, as a project, considers it to be just fine for issues to be completely untouched for a decade, no acknowledgment, no action. Do you think that's fine? Or not? I just want to make sure I fully understand your point of view. Personally, I don't. But I'm not a Gentoo developer, so *shrug*. Obviously everybody would prefer that all bugs get fixed promptly. > Short of that, I'm not sure that automatically closing the bugs is an > improvement on what currently happens. But, it probably wouldn't > personally offend me if old bugs were closed. It just means that if > somebody does pick up that package and starts maintaining it again and > are cleaning things up, they might not fix some lingering issue that > they aren't aware of with it. > >
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
On Sun, Feb 9, 2020 at 3:04 PM Michael Jones wrote: > https://bugs.gentoo.org/buglist.cgi?limit=0=changed > <https://bugs.gentoo.org/buglist.cgi?limit=0=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---> > > Apparently better than it used to be. The last time I surveyed bugzilla it > date%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=--- > <https://bugs.gentoo.org/buglist.cgi?limit=0=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---> > Corrected hyperlink: https://bugs.gentoo.org/buglist.cgi?limit=0=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
On Fri, Feb 7, 2020 at 2:25 PM Rich Freeman wrote: > On Fri, Feb 7, 2020 at 2:34 PM Michael Jones wrote: > > > > Here's an example of how 4.19.97 being stabilized might have exposed > users to functionality breaking bugs: https://bugs.gent was released on > Jan 18thoo.org/706036 <https://bugs.gentoo.org/706036> > > > > Honestly I'd rather see the 30 day stabilization policy apply to LTS > kernels vs. being stabilized faster. Maybe I'm once bitten twice shy. > > One issue here is that the kernel upstream doesn't really consistently > label kernels for bug criticality (including security bugs), or > severity of regressions. > > So, in general any newer release should only make things better, but > if a particular release made things much worse you'd only know from > general discussion on high-volume lists. > > I follow upstream directly and just tend to hold off a day or two > before updates, and look for signs of chatter before doing so. That > is hardly optimal. > > A company like RedHat just hires a ton of kernel engineers to > basically do their own QA on top of upstream's - they can stay on top > of those sorts of problems. I'm sure the Gentoo kernel team does a > better job than I personally do, but I doubt they can sink as much > time as that. > > Again, no animosity against anyone: But Rich, Linux-4.19.97 was released on Jan 17th, and then gentoo-sources-4.19.97 was released on Jan 18th, whereas https://bugs.gentoo.org/706036 was acknowledged to be fixed by Linux-4.19.99 on Jan 29th, and it's now Feb 9th and no newer gentoo-sources package has been stabilized. So we've got some inconsistency in how the gentoo-sources package is stabilized. You don't mind going directly with the upstream package, but I personally do, which is why I used the gentoo-sources package for my kernel needs in large part because I have trust in the Gentoo distribution to provide that small but crucial extra layer of insider knowledge on how likely a particular upstream kernel release is going to break my systems. I certainly don't have a relationship with Gentoo where I pay money to someone and expect some kind of service level guarantees, so honestly this email is just a lot of hot-air. But if Gentoo wants to provide good experiences to end users who are updating their kernels, I personally think it's worth considering the release cadance and whether the currently used one is the right fit for the actual goals of the project. I'm not saying the current cadance isn't the right one, and i'm not saying it is. I'm just saying in this particular situation, it didn't fit one specific end-users needs, and maybe that's fine, and maybe it's not. I'm not the one putting in the work, so I'm not going to say the project *should* take an action. Just point out that there was a problem from my perspective. > > As an aside: The gentoo bug tracker has way too many open bugs > > (Thousands and thousands of them opened over 10 years ago), and the > > search interface is... frustrating. Took me over 5 minutes to find > > that bug despite being a commenter on it. Does anyone know if there's > > any plans for that situation to change in any way? > > I doubt it, but the search interface is probably more likely to change > than the number of open bugs. > > I mean, you could just close bugs without resolving them after a > period of time. That would make the open bug counts look better, but > it wouldn't change the actual quality of the distro, and would just > tend to hide problems packages that are still in the repo. Obviously > fixing bugs would be the ideal path, but we're volunteer driven, so > that is up to the volunteers. I mean, we could just remove any > package from the repo that has open bugs older than a certain time, > but that seems likely to just end up with a repo without any packages > in it. Unless the bugs have security implications or are causing > impact to updates to other packages there usually isn't any policy > requiring that they be fixed. > > I'm sure lots of people would be up for improving the UI, though that > still requires volunteer work. Also, if the fix involves switching > away from bugzilla that is a much bigger hurdle, and one challenge is > that Gentoo doesn't like to host stuff written in Java/Ruby, which > tends to exclude a lot of popular stuff. I don't sysadmin webservers > for a living, so I won't comment on whether that policy is a good one > or a bad one, but I suspect those behind it know a lot more about > maintaining webservers than I do... > > -- > Rich > > https://bugs.gentoo.org/buglist.cgi?limit=0=changed <https://bugs.gentoo.org/buglist.cgi?limit=0=changeddate%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=Gentoo%20Linux_format=advanced=---> Appare
Re: [gentoo-user] Re: Question about gentoo-sources kernel release versions
I'll start by saying that I appreciate all the work the Gentoo developers do, and by no means have any animosity for them for this, Here's an example of how 4.19.97 being stabilized might have exposed users to functionality breaking bugs: https://bugs.gentoo.org/706036 Took me several hours to figure out why several of my machines weren't working right. Honestly I'd rather see the 30 day stabilization policy apply to LTS kernels vs. being stabilized faster. Maybe I'm once bitten twice shy. As an aside: The gentoo bug tracker has way too many open bugs (Thousands and thousands of them opened over 10 years ago), and the search interface is... frustrating. Took me over 5 minutes to find that bug despite being a commenter on it. Does anyone know if there's any plans for that situation to change in any way? On Fri, Feb 7, 2020 at 11:56 AM Franz Fellner wrote: > That doesn't apply to the kernel. > 4.19.97 got tagged on January 17. > January 18. it was stable on amd64 and x86 - one day instead of 30. > Here is the stabilization request: https://bugs.gentoo.org/705006 > There were some issues and changes to the targeted versions. > > > Am Fr., 7. Feb. 2020 um 19:18 Uhr schrieb Mike Gilbert >: > >> On Thu, Feb 6, 2020 at 10:23 PM Matt Connell >> wrote: >> > >> > On 2020-02-06 11:40, Ian Zimmerman wrote: >> > > 5.4 has just become the newest LTS. >> > >> > I see that now. But my original question still stands as to why the >> > stable version of gentoo-sources is consistently a few versions behind >> > the latest LTS release. >> >> Typically, Gentoo maintainers leave new versions in ~arch for some >> time so they can be tested by a broad set of people. Stabilization >> bugs are normally not filed until a given version has spent at least >> 30 days in ~arch. >> >> See GLEP 40 for details on this process. >> >> https://www.gentoo.org/glep/glep-0040.html >> >>
Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive
On Wed, Jan 8, 2020 at 1:01 AM Wols Lists wrote: > On 06/01/20 19:55, Michael Jones wrote: > > > > As for windows 10 licensing, don't trust me on this blindly, but your > > license should be tied to the hardware fingerprint of the laptop. So > > even installing windows fresh on your new SSD should result in Windows > > activating automatically. In fact, you might want to take this > > opportunity to try that out, to get a completely fresh installation > > without the decade of old cruft built up by window's lack of a package > > manager. > > Two points with this - firstly if (like me) you DON'T have an MS > account, this fingerprint is not stored anywhere so that won't work. > Secondly, the fingerprint is likely stored on the hard drive somewhere > so if you clone the hard drive you are hopefully good, and thirdly it's > possible that the new hard drive will break the fingerprint so you're > SOL whatever you do. However, in that last case, if you ring the > licencing help line they MAY give you a new code because it is, still, > technically the same laptop. > > Cheers, > Wol > > I don't mean to continue the windows discussion on the gentoo list, but I wanted to point out that this is incorrect I don't have a microsoft account at all, and regularly reactivate Windows 10 Home / Pro using the hardware fingerprint method using completely clean installations on factory-new harddrives with existing hardware. The fingerprint is stored on Microsoft's activation servers somewhere. I don't know how it works beyond that it's not required that you have a Microsoft account to use it.
Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive
I would be extremely surprised if it activated after not having done so within an hour. You can manually trigger activation in the Windows 10 settings menu somewhere, and get an answer immediately. You *do* need to make sure the version of Windows is 100% identical to what was previously installed though, down to the various international version that have different language packs and misc media features enabled / disabled. On Mon, Jan 6, 2020 at 6:39 PM Mark Knecht wrote: > > > On Mon, Jan 6, 2020 at 5:19 PM Bill Kenworthy wrote: > > > > Hi Mark, > > was your old version Win10 PRO" as well? - as far as I know a > > reinstall will only validate if the hardware as recorded at MS mostly > > matches and its the same version. Cloning via dd, then running through > > the re-validation checks, then making changes in small steps is the only > > way I have been able to make it work despite what is written in the link > > below. > > > > Also check out: > > > https://www.techrepublic.com/article/windows-10-will-microsoft-charge-you-if-you-need-to-reinstall/ > > > > BillK > > > > Bill, >It's a great question that I cannot answer with certainty unless I put > the old drive back in. I thought it was when I did the install this > afternoon but I wasn't sure. > >I'm going to let the machine sit overnight and see if it activates > automatically. If it doesn't I'll go back to the old drive and if needed > will do a new reinstall with the right version. If I can get away with this > path I will. If not I'll go with something like Mick suggested. > > thanks, > Mark >
Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive
You can use the Windows 10 Download Tool (Or similarly named thing, sorry, I can't find the details of it at this time) to download an ISO image Combine that with the rufus program https://rufus.ie/ (I use the portable one, personally) to create a Windows 10 USB installer stick. On Mon, Jan 6, 2020 at 2:39 PM Mark Knecht wrote: > Hi Michael, >Thanks for the response. Great info. > >The install Win 10 clean sounds wonderful if it works. With no DVD in > this machine it sounds like I should investigate an install from USB if the > machine supports it. It's an Asus gaming laptop circa 2008 so hopefully > that works but I've never done it on this machine. > > Cheers, > Mark > > On Mon, Jan 6, 2020 at 12:56 PM Michael Jones wrote: > >> Generally the way I've handled this situation in the past is like so >> (this is written from memory, so expect gratuitous problems). >> >> On the machine with the drive attached >> mbuffer -i /dev/mydrive | xz -e -9 | mbuffer -O hostname:port >> >> On a machine with storage space >> mbuffer -I port -o /path/to/storage.xz >> >> To make a backup. >> >> >> In terms of cloning windows to another harddrive in general, as long as >> the destination harddrive is large enough to fit the original drive without >> issues, simply running: >> >> dd if=/dev/original of=/dev/destination >> (I prefer dcfldd, personally) >> >> Is enough. Run gparted (the graphical version, for nice wizards) after, >> and it'll fixup your partition table for you to match the new size, and you >> can re-size any partitions you have to make them match as well. I do >> exactly this all the time and have yet to have a problem. >> >> As for windows 10 licensing, don't trust me on this blindly, but your >> license should be tied to the hardware fingerprint of the laptop. So even >> installing windows fresh on your new SSD should result in Windows >> activating automatically. In fact, you might want to take this opportunity >> to try that out, to get a completely fresh installation without the decade >> of old cruft built up by window's lack of a package manager. >> >> If it doesn't activate as soon as you plug in an ethernet cable, you can >> just wipe your SSD and copy your old installation as discussed already. >> >> >> >> On Mon, Jan 6, 2020 at 1:11 PM Mark Knecht wrote: >> >>> Hi all, >>>I haven't been here in a couple of years. IT's great to see some >>> familiar names posting. Cheers to all. >>> >>>I have a laptop running Win 10 with no (working) DVD/CDROM. For >>> various reasons I want to move from a 10 year old laptop drive to a new SSD >>> and am looking for guidance on I might do that. Win 10 is properly licensed >>> but through a weird channel - it was Win 7 that M$ allowed to convert to >>> Win 10 for free and I'm nervous that if the hard drive died I'd have to >>> purchase a new license as the free conversion path likely doesn't exist >>> anymore. >>> >>>Both drives are nominally 500GB. >>> >>>The older hard drive fdisk info shows: >>> >>> root@science:~# fdisk --list /dev/sde >>> Disk /dev/sde: 465.8 GiB, 500107862016 bytes, 976773168 sectors >>> Disk model: ASM1053E >>> Units: sectors of 1 * 512 = 512 bytes >>> Sector size (logical/physical): 512 bytes / 512 bytes >>> I/O size (minimum/optimal): 512 bytes / 512 bytes >>> Disklabel type: dos >>> Disk identifier: 0xe0c5913d >>> >>> Device Boot Start End Sectors Size Id Type >>> /dev/sde1 63 45062324 45062262 21.5G 1c Hidden W95 FAT32 >>> (LBA) >>> /dev/sde2 * 45062325 288063133 243000809 115.9G 7 HPFS/NTFS/exFAT >>> /dev/sde3 288063488 289247231 1183744 578M 27 Hidden NTFS >>> WinRE >>> /dev/sde4 289249254 976768064 687518811 327.9G fd Linux raid >>> autodetect >>> root@science:~# >>> >>> The Linux RAID autodetect is from running Gentoo at some earlier time >>> and probably doesn't need to be copied. I'm not at all sure what /dev/sde3 >>> is or whether it's required to make M$ happy. >>> >>>The new SSD is unused and shows: >>> >>> root@science:~# fdisk --list /dev/sdf >>> Disk /dev/sdf: 465.8 GiB, 500107862016 bytes, 976773168 sectors >>> Disk model: ASM1053E >>> Units: sectors of 1 * 512 = 512 bytes >>> Sector size (logical/physical): 512 bytes / 4096 bytes >>> I/O size (minimum/optimal): 4096 bytes / 4096 bytes >>> root@science:~# >>> >>>The appear to have the same sector count and overall size. >>> >>>I can make a 1TB drive available in my big machine and work over USB >>> (which is what I'm doing to get the info above) but I'm unclear how much of >>> this can be done automatically and how much I might need to do by hand. >>> >>>As long as I don't hurt the old drive I can put data on the SSD >>> multiple times to get through the process in case I have trouble. >>> >>>Does anyone have experience with this sort of issue and can you point >>> me toward some instructions I might try? >>> >>> Thanks, >>> Mark >>> >>> >>>
Re: [gentoo-user] Guidance on using Gentoo to clone a Win 10 system drive
Generally the way I've handled this situation in the past is like so (this is written from memory, so expect gratuitous problems). On the machine with the drive attached mbuffer -i /dev/mydrive | xz -e -9 | mbuffer -O hostname:port On a machine with storage space mbuffer -I port -o /path/to/storage.xz To make a backup. In terms of cloning windows to another harddrive in general, as long as the destination harddrive is large enough to fit the original drive without issues, simply running: dd if=/dev/original of=/dev/destination (I prefer dcfldd, personally) Is enough. Run gparted (the graphical version, for nice wizards) after, and it'll fixup your partition table for you to match the new size, and you can re-size any partitions you have to make them match as well. I do exactly this all the time and have yet to have a problem. As for windows 10 licensing, don't trust me on this blindly, but your license should be tied to the hardware fingerprint of the laptop. So even installing windows fresh on your new SSD should result in Windows activating automatically. In fact, you might want to take this opportunity to try that out, to get a completely fresh installation without the decade of old cruft built up by window's lack of a package manager. If it doesn't activate as soon as you plug in an ethernet cable, you can just wipe your SSD and copy your old installation as discussed already. On Mon, Jan 6, 2020 at 1:11 PM Mark Knecht wrote: > Hi all, >I haven't been here in a couple of years. IT's great to see some > familiar names posting. Cheers to all. > >I have a laptop running Win 10 with no (working) DVD/CDROM. For various > reasons I want to move from a 10 year old laptop drive to a new SSD and am > looking for guidance on I might do that. Win 10 is properly licensed but > through a weird channel - it was Win 7 that M$ allowed to convert to Win 10 > for free and I'm nervous that if the hard drive died I'd have to purchase a > new license as the free conversion path likely doesn't exist anymore. > >Both drives are nominally 500GB. > >The older hard drive fdisk info shows: > > root@science:~# fdisk --list /dev/sde > Disk /dev/sde: 465.8 GiB, 500107862016 bytes, 976773168 sectors > Disk model: ASM1053E > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0xe0c5913d > > Device Boot Start End Sectors Size Id Type > /dev/sde1 63 45062324 45062262 21.5G 1c Hidden W95 FAT32 > (LBA) > /dev/sde2 * 45062325 288063133 243000809 115.9G 7 HPFS/NTFS/exFAT > /dev/sde3 288063488 289247231 1183744 578M 27 Hidden NTFS WinRE > /dev/sde4 289249254 976768064 687518811 327.9G fd Linux raid > autodetect > root@science:~# > > The Linux RAID autodetect is from running Gentoo at some earlier time and > probably doesn't need to be copied. I'm not at all sure what /dev/sde3 is > or whether it's required to make M$ happy. > >The new SSD is unused and shows: > > root@science:~# fdisk --list /dev/sdf > Disk /dev/sdf: 465.8 GiB, 500107862016 bytes, 976773168 sectors > Disk model: ASM1053E > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 4096 bytes > I/O size (minimum/optimal): 4096 bytes / 4096 bytes > root@science:~# > >The appear to have the same sector count and overall size. > >I can make a 1TB drive available in my big machine and work over USB > (which is what I'm doing to get the info above) but I'm unclear how much of > this can be done automatically and how much I might need to do by hand. > >As long as I don't hurt the old drive I can put data on the SSD > multiple times to get through the process in case I have trouble. > >Does anyone have experience with this sort of issue and can you point > me toward some instructions I might try? > > Thanks, > Mark > > >
Re: [gentoo-user] upgrading (profiles, too)
On Wed, May 29, 2019 at 2:46 PM wrote: > Hi, > > I'm currently at 4.14.65-gentoo and I understand my cheap hp laptop's > amdgpu could finally get better support if I upgrade to 4.16 or 4.17.1. > Can I just do that, or would it be better (or even possible) to go in > smaller increments? > > Also, something's always complaining to me about my profile, > default/linux/amd64/13.0/desktop, being out-of-date. Should I upgrade to > 17 at the same time? I've seen lots about the differences between > different types of profiles but not about the differences between different > versions of a profile type. What's different? > > Thanks for any thoughts. > > You can change kernel versions in any way you see fit. You're unlikely to run into any significant issues from upgrading by 2 or 3 releases at once. My personal recommendation is to conduct the profile update as a separate task from the kernel update, simply because they are not really related to each other.
Re: [gentoo-user] VRFs / Jails / Containers
systemd-nspawn is also an option, but I don't think that'll work with OpenRC. On Sat, Feb 2, 2019 at 9:56 PM Grant Taylor < gtay...@gentoo.tnetconsulting.net> wrote: > On 2/2/19 7:36 PM, Bill Kenworthy wrote: > > LXC containers ?? > > Maybe. > > I just feel like that's more heavy weight than I want. > > I'm functionally running a series of ip commands to configure networking > in a special way. > > Maybe I should look into what it takes to extend netifrc to support what > I want. I sort of think that VRF could model off of bonding and / or > bridge and / or VLAN devices. At least in the master / slave aspect. > > I'm sure that veth will be a new concept, but it may be able to model > after a tunnel interface. > > It would be really nice to have network namespace support. But I don't > see anything that could be modeled off of. > >
Re: [gentoo-user] Pick your hypothesis:
On Thu, Jan 24, 2019 at 2:33 PM Jack wrote: > On 2019.01.24 15:17, Michael Jones wrote: > [snip] > > A lot of people run emerge without checking the preliminary console > > output. > But most (I hope) of them understand the possible problems, and are > willing to "pick up the pieces" if something goes wrong. Most of them > do not blame the Gentoo developers in such a case. > Of course. > > I don't think it's fair to imply that doing that is somehow wrong. > Some/many of us might disagree. If you don't check the output to see > exactly what emerge is going to do, it may well not do what you > want/expect. Is it "wrong" to drive your car with a blindfold on. > You're absolutely right that if you don't check the output, it might be doing something different than what you expect. I don't really see how the car analogy is applicable though, so I can't agree with that. > > The vast majority of Linux distributions support unattended upgrades > > without a second thought. > The vast majority of Linux distributions are binary distributions, > where a package either works or not, and if it doesn't, it is very > likely a packaging error. The vast majority of Linux distributions do > not install from source, with lots of ways of configuring things to the > user's liking, many of which possible configurations will not work. I > would say that binary distributions are much more deterministic in > their behavior. You really can't run Gentoo safely for very long > without paying close attention to what you are doing - with both > installs and upgrades. > > Well,lets break this down into smaller pieces: > The vast majority of Linux distributions are binary distributions, where a package either works or not, and if it doesn't, it is very likely a packaging error. Sure, a lot of the time problems with binary distros are packaging errors. Bugs can happen in a lot of ways. Sometimes the package is just broken *shrug*. > The vast majority of Linux distributions do not install from source, with lots of ways of configuring things to the user's liking, many of which possible configurations will not work. Sure, that's true. While I agree that the number of user facing toggles increase the likelihood of something going wrong, I don't agree that this is inherently an excuse. Obviously it's an explanation as to how something going wrong wasn't able to be addressed ahead of time, but it's not automatically a fair excuse / justification for delivering an ebuild to the portage tree that has problems. I'm not arguing that the Gentoo developers are somehow beholden to users, nor am I saying that it's wise to assume everything will work correctly. I'm simply saying that it's not fair to say that not checking the output of emerge is inherently wrong. If it was inherently wrong, then emerge should not allow for a package to be emerged until the user has reviewed it's stated plan. > You really can't run Gentoo safely for very long without paying close attention to what you are doing - with both installs and upgrades. I don't know that this is true. I've had the same set of use flags configured on all of my Gentoo computers for 5-ish years now, and I've only very rarely messed with them. For the most part, running "eix-sync && emerge --update --newuse --deep @world" once a week has allowed me to have unattended upgrades for many months at a time, only needing to adjust one or two things every several months. Needing to tweak something is my exception, not my rule. My reason for replying initially was that I didn't think it was fair to make light of users who don't expect to *need* to scrutinize the output of emerge every single time they run it. Those people exist (hi, nice to meet you), and it's not fair to say they're wrong or somehow making a grave error in judgement. It's entirely fair to say that they are treading on thin ice, and that if they choose to do this they should understand the risks, but it's not fair to say they're automatically wrong to use the tool in a way that the tool allows itself to be used. Either way, we don't need to turn this into a long and in depth discussion, so I probably won't reply to the list again unless you have any specific questions or concerns for me. Happy compiling :-)
Re: [gentoo-user] Pick your hypothesis:
On Thu, Jan 24, 2019 at 2:04 PM Dale wrote: > Neil Bothwick wrote: > > On Thu, 24 Jan 2019 13:42:04 -0600, Dale wrote: > > > >> I'm trying to recall but am not sure, is this the same Alan that used to > >> come on here and post this sort of thing when the problem was in the > >> chair not Gentoo? I recall the person I'm speaking of having a script > >> that just created a mess and then he blamed it on Gentoo. I might still > >> have some of those emails but someone else may recall if this is the > >> same person or not. > > It is. > > > > > > > Yep. I went and found this little gem. For those interested, this is > the script he used back then. I'm not sure if he still does today or > not. Some of you may find it funny. Some may just cry, for various > reasons. ;-) > > Alan Grimes wrote: > > I use two scripts for all emerge use, the goal is to run one command and > > then walk away: > > > > Standard general update script: > > ### > > tortoise ~ # cat sysupdate > > > > #they must have moved or removed the logs, might have to track them down > > again... > > #rm /var/log/emerge* > > > > # cache /usr/portage > > echo "caching /usr/portage. This will take a long time." > > time ls -R /usr/portage > /dev/null > > > > emerge --sync > > layman --sync ALL > > > > emerge --update --verbose portage > > emerge --update --newuse --deep --with-bdeps=y system --keep-going > > emerge --update --newuse --deep --with-bdeps=y world --keep-going > > > > rm -f /var/cache/revdep-rebuild/*.rr > > revdep-rebuild > > emerge --skipfirst --resume > > emerge --skipfirst --resume > > etc-update > > eclean-dist > > > > > > The eclean line was added just a few days ago from this thread... > > > > This one is intended to be a nice gentle update script. > > It caches the portage tree, then syncs everything, then updates > > everything starting with critical system packages, then all world > > packages... > > > > Then it cleans stuff up, it jcakhammers the revdep-rebuild but not too > > hard > > > > > > This next script is what I use when emerge starts giving me shit: > > > > ## > > tortoise ~ # cat keepgoing > > emerge --update --newuse --deep --with-bdeps=y system > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > > > emerge --update --newuse --deep --with-bdeps=y world > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > > > rm /var/cache/revdep-rebuild/*.rr > > revdep-rebuild > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > emerge --skipfirst --resume --nodeps > > > > etc-update > > ### > > > > It's basically the same as the working section of the above but instead > > of letting emerge do it's thing, it jackhammers that bitch as hard as > > possible to get as much updated as possible, but it requires emerge to > > do something and not error out for no good reason... I expect prune and > > depclean to be useless but I kinda need update to basically work every > > time. =\ > > Whatever fails on this script, I just live with until next week/month. > > > > ### > > tortoise ~ # ./pretendupdate > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies / > > > > !!! Problem resolving dependencies for sys-apps/util-linux from @system > > ... done! > > > > !!! The ebuild selected to satisfy "sys-apps/util-linux" has unmet > > requirements. > > - sys-apps/util-linux-2.27.1::gentoo USE="caps cramfs ncurses nls pam > > python readline suid udev unicode -build -fdformat -kill (-selinux) > > -slang -static-libs -systemd -test -tty-helpers" ABI_X86="32 64 -x32" > > PYTHON_SINGLE_TARGET="-python2_7 -python3_3 -python3_4" > > PYTHON_TARGETS="python2_7 python3_4 -python3_3" > > > > The following REQUIRED_USE flag constraints are unsatisfied: > > python? ( exactly-one-of ( python_single_target_python2_7 > > python_single_target_python3_3 python_single_target_python3_4 ) ) > > > > The above constraints are a subset of the following complete > expression: > > python? ( exactly-one-of ( python_single_target_python2_7 > > python_single_target_python3_3 python_single_target_python3_4 ) > > python_single_target_python2_7? ( python_targets_python2_7 ) > > python_single_target_python3_3? ( python_targets_python3_3 ) > > python_single_target_python3_4? ( python_targets_python3_4 ) ) > > > > (dependency required by "@system" [set]) > > (dependency required by "@world" [argument]) > > > > tortoise ~ #
Re: [gentoo-user] backing up a partition
try fsarchiver On Thu, Aug 30, 2018 at 11:53 AM, Philip Webb wrote: > 180825 Philip Webb wrote: > > Thanks for the replies : > > it looks as if 'tar' mb adequate, but I'll think re it & make a test. > > I used 'tar -a' to copy the contents of the partition to a USB stick, > then copied them back to another partition, updated Lilo > & it booted successfully into the new partition, which works the same. > > -- > ,, > SUPPORT ___//___, Philip Webb > ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto > TRANSIT`-O--O---' purslowatchassdotutorontodotca > > >
