Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not)
On 6/8/21 4:40 am, Frank Steinmetzger wrote: > Am Tue, Aug 03, 2021 at 10:18:06AM +0200 schrieb Frank Steinmetzger: > >>> You could delete and rebuild the cache each time (or I think there is a >>> way to do without it). >> If the cache can be easily rebuilt, then there’d be no need to store it at >> all. > Here’s an afterthought that just hit me: > there should actually be no point in archiving the cache at all. If you had > a disaster and do a full restore from borg, the old cache data becomes > invalid anyways, because the files’ inodes will now be different. AFAIK, > inodes are one way of detecting file changes. Different inode → file must be > different → rehash. > > (Unless `borg extract` updates the borg cache for files it restores, which I > doubt because the destination path is arbitrary.) > Agreed - I do get a warning on restore and my first choice is always delete the cache AND the security directory - I should just go ahead and do it anyway I guess. Also, it would be a good time to read the borg create statement (https://borgbackup.readthedocs.io/en/stable/usage/create.html) for the file change detection parameters - moosefs and snapshots required non-default options to get it right. BillK
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
On Thu, 5 Aug 2021 10:10:27 +0200, Dr Rainer Woitok wrote: > > Why not write the output to a file ? -- eg > > 'emerge --ask --depclean > '. > > Then you can look at the output at leisure, even on another machine. > > Depending on the number of packages you've installed and depending on > the speed of your rig "emerge --depclean" may take some time, and thus I > tried to avoid splitting it into two calls, one to just announce what > would be done and one to really do it. > > But meanwhile I'm suspecting that any call along the lines of > ># emerge --ask ... | $PAGER > > is doomed to fail because both, "emerge" and the pager are trying to > read the user's answer from the same input device (maybe "/dev/tty") and > thus both are stumbling over the other's feet. The only way out would > be just another option causing "emerge" to page internally. > > Therefore my "edepclean" alias now calls "emerge" twice, like so: > ># emerge --depclean --pretend | $PAGER ># emerge --depclean -- ask --quiet How about emerge -ca | tee >depclean.txt Then if the list is short you can read it in the console and just hit y or n. Otherwise, hit n and read the file. It will save calculating dependencies twice, and we all know how slow that can be. -- Neil Bothwick A pessimist is an optimist who's given it some thought. pgpYFGrG7aQwg.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Neil, On Friday, 2021-08-06 08:33:33 +0100, you wrote: > ... > ># emerge --depclean --pretend | $PAGER > ># emerge --depclean -- ask --quiet > > How about emerge -ca | tee >depclean.txt > > Then if the list is short you can read it in the console and just hit y > or n. Otherwise, hit n and read the file. It will save calculating > dependencies twice, and we all know how slow that can be. Nice idea, Neil. Thanks :-) Sincerely, Rainer
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/3/21 5:54 PM, Peter Humphrey wrote: On Tuesday, 3 August 2021 15:51:15 BST Arve Barsnes wrote: On Tue, 3 Aug 2021 at 15:58, Neil Bothwick wrote: I don't see them when syncing from a cron script, when all output is captured and emailed, but do when running sync on a shell. It seems you only see this when running sync interactively. I see these messages in the output from my cron "script". I use "/usr/sbin/emaint sync -a", and it regularly shows the message about new portage versions. The message might not be generated by the sync itself, but from the postsync 'eix-update' which would maybe show messages like this. I sync daily via git, ... Then you probably build a lot more than I do. I synced, like yesterday or the day before, and then, on a second machine, I synced today, in order to update from the first machine, using a binary update, and, in fact, I was able to get thunderbird, but llvm AND clang, both huge builds, had to be rebuilt! Oh man. Bad luck? No, life with gentoo. (sorry, Peter, for the direct email, apparently a mis-click) ... and every time a new version of portage is included I see a prominent warning to update it before anything else. Portage has done this for many years, apart from a few months a year or two ago.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Tue, Aug 3, 2021 at 2:03 AM n952162 wrote: > > Well, what you say is likely true, but does "old software" really need > to be kept working? Couldn't problems necessarily only be dealt with > in the newest versions? > I think you are misunderstanding what actually went wrong in your situation. Nothing broke in your existing software. You're using an old version of portage. It will continue to work as it always has. However, you wanted to use it with a newer version of the software repository. This contained a package that wasn't compatible with old versions of portage. The version of portage you're using detected this, and refused to install it, so as to not randomly break your system. Your system continued to work as it always had. You just couldn't install that particular package, or anything that depends on it. Generally we try to maintain a reasonably sane upgrade path going back maybe six months or so. You just needed to update portage first. If your system is more than a month or two out of date just running emerge -uD world or whatever blindly is more likely to run into a problem. It shouldn't break your system unless you go adding random options to the command line to override safety features, but it might involve a few steps (like updating portage, @system, and so on before trying to update everything). It usually isn't unmanageable, but Gentoo is definitely not an LTS-oriented distro. If you want to only get security fixes for three years and then update everything in one go, then stick with something like RHEL, Ubuntu LTS, or debian stable. Those distros deliver exactly that sort of experience, and really there isn't as much benefit to something like Gentoo if you're just going to update it every other year anyway. -- Rich
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/6/21 2:16 PM, Rich Freeman wrote: On Tue, Aug 3, 2021 at 2:03 AM n952162 wrote: Well, what you say is likely true, but does "old software" really need to be kept working? Couldn't problems necessarily only be dealt with in the newest versions? I think you are misunderstanding what actually went wrong in your situation. Nothing broke in your existing software. You're using an old version of portage. It will continue to work as it always has. However, you wanted to use it with a newer version of the software repository. This contained a package that wasn't compatible with old versions of portage. The version of portage you're using detected this, and refused to install it, so as to not randomly break your system. Your system continued to work as it always had. You just couldn't install that particular package, or anything that depends on it. I think that doesn't characterize my point quite. I was complaining, mostly, that isodate had to be the thing that was incompatible with my configuration. Maybe there is a unavoidable reason that that package had to move to the newest EAPI, or maybe it was just a sense that it's cool to be with the cutting edge. It seems to me that isodate (which is actually tied, perhaps indirectly, to clearly slow United Nations rule-making) must be pretty stable. Generally we try to maintain a reasonably sane upgrade path going back maybe six months or so. You just needed to update portage first. My update was two months late. If your system is more than a month or two out of date just running emerge -uD world or whatever blindly is more likely to run into a problem. It shouldn't break your system unless you go adding random options to the command line to override safety features, I don't have the expertise to do something like that. but it might involve a few steps (like updating portage, @system, and so on before trying to update everything). It usually isn't unmanageable, but Gentoo is definitely not an LTS-oriented distro. If you want to only get security fixes for three years and then update everything in one go, then stick with something like RHEL, Ubuntu LTS, or debian stable. Those distros deliver exactly that sort of experience, and really there isn't as much benefit to something like Gentoo if you're just going to update it every other year anyway. Those distros are not source distros. I'm making an argument that there's a large space between binary distributions and source distributions that pass every upstream change down in realtime. Gentoo is in the best position to service that space
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/6/21 2:37 PM, n952162 wrote: On 8/6/21 2:16 PM, Rich Freeman wrote: On Tue, Aug 3, 2021 at 2:03 AM n952162 wrote: Well, what you say is likely true, but does "old software" really need to be kept working? Couldn't problems necessarily only be dealt with in the newest versions? I think you are misunderstanding what actually went wrong in your situation. Nothing broke in your existing software. You're using an old version of portage. It will continue to work as it always has. However, you wanted to use it with a newer version of the software repository. This contained a package that wasn't compatible with old versions of portage. The version of portage you're using detected this, and refused to install it, so as to not randomly break your system. Your system continued to work as it always had. You just couldn't install that particular package, or anything that depends on it. I think that doesn't characterize my point quite. I was complaining, mostly, that isodate had to be the thing that was incompatible with my configuration. Maybe there is a unavoidable reason that that package had to move to the newest EAPI, or maybe it was just a sense that it's cool to be with the cutting edge. It seems to me that isodate (which is actually tied, perhaps indirectly, to clearly slow United Nations rule-making) must be pretty stable. Generally we try to maintain a reasonably sane upgrade path going back maybe six months or so. You just needed to update portage first. My update was two months late. If your system is more than a month or two out of date just running emerge -uD world or whatever blindly is more likely to run into a problem. It shouldn't break your system unless you go adding random options to the command line to override safety features, I don't have the expertise to do something like that. but it might involve a few steps (like updating portage, @system, and so on before trying to update everything). It usually isn't unmanageable, but Gentoo is definitely not an LTS-oriented distro. If you want to only get security fixes for three years and then update everything in one go, then stick with something like RHEL, Ubuntu LTS, or debian stable. Those distros deliver exactly that sort of experience, and really there isn't as much benefit to something like Gentoo if you're just going to update it every other year anyway. Those distros are not source distros. I'm making an argument that there's a large space between binary distributions and source distributions that pass every upstream change down in realtime. Gentoo is in the best position to service that space I see that that begs the question of why someone would be interested in a source distribution. With a binary distribution, you fly on trust. With a source distribution, you do, too, given the size of the code base. The difference is, with a source distribution, there's a "paper trail" that can be followed back if that trust was abused. That's just about impossible with a binary distro.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Friday, 6 August 2021 12:58:59 BST n952162 wrote: > (sorry, Peter, for the direct email, apparently a mis-click) It's easily forgiven. For who among us has never misclicked? :) -- Regards, Peter.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/6/21 5:09 PM, Peter Humphrey wrote: On Friday, 6 August 2021 12:58:59 BST n952162 wrote: (sorry, Peter, for the direct email, apparently a mis-click) It's easily forgiven. For who among us has never misclicked? :) :-)))
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Fri, Aug 6, 2021 at 8:37 AM n952162 wrote: > > I was complaining, mostly, that isodate had to be the thing that was > incompatible with my configuration. Maybe there is a unavoidable reason > that that package had to move to the newest EAPI, or maybe it was just a > sense that it's cool to be with the cutting edge. It seems to me that > isodate (which is actually tied, perhaps indirectly, to clearly slow > United Nations rule-making) must be pretty stable. > it is generally encouraged that packages use the latest EAPI - there are a lot of reasons for doing so. The main ones that get held back are packages that would interfere with updating portage and the toolchain, since those are what are most needed when somebody does an update. All you need to do in order to resolve an incompatible EAPI issue is update portage. We don't really provide support for running out-of-date versions of portage itself. There really isn't much reason to run an old version of portage - it is unlikely that updating portage is going to cause incompatibilities on your system as almost nothing uses portage except the distribution itself. It might not hurt if that error message included the suggestion to run "emerge -u portage" to update it. It does say that the solution is to update portage - it just doesn't explicitly tell you how to do so. > > Those distros are not source distros. I'm making an argument that > there's a large space between binary distributions and source > distributions that pass every upstream change down in realtime. Gentoo > is in the best position to service that space > There may be a nice for a release-based source-based distribution, and nothing is stopping anybody from adding releases to Gentoo (a trivial way to do this would be to just fork the repository and update it in releases). I just don't think there is THAT much interest among the community in doing so, and even if such a thing were created I'm pretty skeptical that they wouldn't at least keep portage and the EAPIs cutting-edge, as it doesn't really hurt anything to do so. If you want to kick something like that off though feel free. All you need to do is clone the Gentoo repository, and use some branches/tags/etc to manage it. You could pull in whatever you want in whatever branch you want, and curate releases. Really the only hard part would be the curation and QA. If you wanted somebody to run the CI tools against your repo and file bugs for you I wouldn't be surprised if infra was willing to do so. It would still be a fair bit of work, and I'm really skeptical that it would get much use. To address your follow-up email, many popular binary distros have been working on reproducible builds, so if your main concern is fear of what might be bundled inside packages, I'd think that would mitigate a lot of it. -- Rich
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/6/21 8:22 PM, Rich Freeman wrote: On Fri, Aug 6, 2021 at 8:37 AM n952162 wrote: I was complaining, mostly, that isodate had to be the thing that was incompatible with my configuration. Maybe there is a unavoidable reason that that package had to move to the newest EAPI, or maybe it was just a sense that it's cool to be with the cutting edge. It seems to me that isodate (which is actually tied, perhaps indirectly, to clearly slow United Nations rule-making) must be pretty stable. ... It might not hurt if that error message included the suggestion to run "emerge -u portage" to update it. It does say that the solution is to update portage - it just doesn't explicitly tell you how to do so. The way out of my dilema would be first to emerge portage and then emerge @world? ... To address your follow-up email, many popular binary distros have been working on reproducible builds, so if your main concern is fear of what might be bundled inside packages, I'd think that would mitigate a lot of it. I will look into reproducible builds, thank you.
[gentoo-user] Recommend C source browser/editor?
Would anybody care to recommend a tool for browsing around (and editing) a tree of somebody-else's C code? I prefer emacs for day-to-day editing of my code (when I know what's where), but I'm looking for something to browse around a tree of unfamiliar source code and make minor changes. I briefly tried emacs+cscope at a few points in the past, but it just never worked very well. It would be nice to have something that I can just point at a tree of source files and not to have to spend a lot of time setting up a "project" or "workspace" or whatever... Mostly I'd like to be able to: * Click on a function and list places from which it is called(). * Click on a function call and goto it's definition. I don't care at all about debugging. This is embedded, real-time code for which a debugger is pretty useless. It would be nice to be able configure a function key to run an arbitrary shell command that will run a "make" to build a binary, download the binary to the target hardware, and start it. If it can parse gcc error messages from a "make" command, that would be nice, but not required. I run mostly a GTK based system (but usually have quite a few QT libraries installed to support things like Wireshark). Any suggestions?
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Fri, Aug 6, 2021 at 2:41 PM n952162 wrote: > > On 8/6/21 8:22 PM, Rich Freeman wrote: > > On Fri, Aug 6, 2021 at 8:37 AM n952162 wrote: > >> I was complaining, mostly, that isodate had to be the thing that was > >> incompatible with my configuration. Maybe there is a unavoidable reason > >> that that package had to move to the newest EAPI, or maybe it was just a > >> sense that it's cool to be with the cutting edge. It seems to me that > >> isodate (which is actually tied, perhaps indirectly, to clearly slow > >> United Nations rule-making) must be pretty stable. > >> > > ... > > It might not hurt if that error message included the suggestion to run > > "emerge -u portage" to update it. It does say that the solution is to > > update portage - it just doesn't explicitly tell you how to do so. > > > The way out of my dilema would be first to emerge portage and then > emerge @world? In this case that would probably fix it. Some update issues can get messy if you don't update often, but usually for EAPI issues you just need to update portage itself. -- Rich
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 06/08/2021 19:41, n952162 wrote: It might not hurt if that error message included the suggestion to run "emerge -u portage" to update it. It does say that the solution is to update portage - it just doesn't explicitly tell you how to do so. The way out of my dilema would be first to emerge portage and then emerge @world? Probably. If you've left it that long you might find you still have a few problems. If you find you have trouble once portage is updated, I've found that the following often works ... First do a --update @system (NO deep, no changed use, no nothing like that). If that succeeds, the remaining steps will be hassle but nothing serious. Then try the same with @world. Finally update @world with deep, newuse etc. If emerge keeps giving up with too many blocks, just do a oneshot emerge of a bunch of stuff it says it *can* emerge, and you'll likely find after a couple of shots of that that it suddenly works. The other trick I try is, IFF @system was successful, just do a oneshot delete of any blocking packages and again it should suddenly start working. Cheers, Wol
