Re: [gentoo-user] Re: Compiling first and then installing using -K
On Mon, Feb 17, 2020 at 4:32 PM Nikos Chantziaras wrote: > > On 18/02/2020 01:21, Rich Freeman wrote: > > On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras wrote: > >> Hm. I'm too chicken to try it because I'm not sure it does what I think > >> it does, but does the "--ephemeral" option pretty much do *exactly* what > >> Dale was asking about? Can you start your current "/" as a container > >> as-is, emerge packages in it and save them as binaries, then install > >> those from the outside, then shutdown the container and all is forgotten? > > > > Obvious way to test this would be to just set up a VM. It has the > > obvious advantage of always being in-sync with your host config. > > > > I think I might actually try playing around with this. I'm on zfs > > though so I'm not sure how it will perform. > > I just tested it in a throw-away Ubuntu VM running on ext4. It crashed > and burned due to disk space. It tried to duplicate the whole "/" with > zero error checks. So free space reached 0 but it still didn't abort. I > had to abort with ctrl+c. Free space was then 200MB (out of 20GB). I did > "du -sh /*" to find where all the GBs went, but it doesn't find it. > > So... yeah. Not very convincing implementation. Don't try it at home, > kids :-P > Ouch!
Re: [gentoo-user] Re: Compiling first and then installing using -K
On Mon, Feb 17, 2020 at 6:31 PM Nikos Chantziaras wrote: > > On 18/02/2020 01:21, Rich Freeman wrote: > > On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras wrote: > >> Hm. I'm too chicken to try it because I'm not sure it does what I think > >> it does, but does the "--ephemeral" option pretty much do *exactly* what > >> Dale was asking about? Can you start your current "/" as a container > >> as-is, emerge packages in it and save them as binaries, then install > >> those from the outside, then shutdown the container and all is forgotten? > > > > Obvious way to test this would be to just set up a VM. It has the > > obvious advantage of always being in-sync with your host config. > > > > I think I might actually try playing around with this. I'm on zfs > > though so I'm not sure how it will perform. > > I just tested it in a throw-away Ubuntu VM running on ext4. It crashed > and burned due to disk space. It tried to duplicate the whole "/" with > zero error checks. So free space reached 0 but it still didn't abort. I > had to abort with ctrl+c. Free space was then 200MB (out of 20GB). I did > "du -sh /*" to find where all the GBs went, but it doesn't find it. > Hmm, if it just resorted to doing a cp it might have tried to copy the copy, or if it was really brain-dead it might not have limited itself to the root filesystem. Granted, the necessary files might not all be on one filesystem to begin with, but it would obviously have to avoid copying /proc and so on. I mean, it might have trouble with: -r 1 root root 128T Feb 11 14:31 /proc/kcore -- Rich
[gentoo-user] Re: Compiling first and then installing using -K
On 18/02/2020 01:21, Rich Freeman wrote: On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras wrote: Hm. I'm too chicken to try it because I'm not sure it does what I think it does, but does the "--ephemeral" option pretty much do *exactly* what Dale was asking about? Can you start your current "/" as a container as-is, emerge packages in it and save them as binaries, then install those from the outside, then shutdown the container and all is forgotten? Obvious way to test this would be to just set up a VM. It has the obvious advantage of always being in-sync with your host config. I think I might actually try playing around with this. I'm on zfs though so I'm not sure how it will perform. I just tested it in a throw-away Ubuntu VM running on ext4. It crashed and burned due to disk space. It tried to duplicate the whole "/" with zero error checks. So free space reached 0 but it still didn't abort. I had to abort with ctrl+c. Free space was then 200MB (out of 20GB). I did "du -sh /*" to find where all the GBs went, but it doesn't find it. So... yeah. Not very convincing implementation. Don't try it at home, kids :-P
Re: [gentoo-user] Re: Compiling first and then installing using -K
On Mon, Feb 17, 2020 at 6:00 PM Nikos Chantziaras wrote: > > On 17/02/2020 21:46, Rich Freeman wrote: > > > > Well, if you decide to play with it I'll offer up: > > https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/ > > Hm. I'm too chicken to try it because I'm not sure it does what I think > it does, but does the "--ephemeral" option pretty much do *exactly* what > Dale was asking about? Can you start your current "/" as a container > as-is, emerge packages in it and save them as binaries, then install > those from the outside, then shutdown the container and all is forgotten? You know, I think that might actually work. Note that it depends on reflinks or snapshots for efficient operation, and I'm not sure what the full list of supported filesystems are. They do mention btrfs. I'm not sure if zfs is supported (zfs supports snapshots but clones would be needed here and those have some limitations, and zfs does not support reflinks). You'd obviously have to bind-mount your binary package directory - I think you could do that even using the same root as this would enable writes to that one path to escape the mount namespace and get into your host filesystem. Obvious way to test this would be to just set up a VM. It has the obvious advantage of always being in-sync with your host config. I think I might actually try playing around with this. I'm on zfs though so I'm not sure how it will perform. -- Rich
[gentoo-user] Re: Compiling first and then installing using -K
On 17/02/2020 21:46, Rich Freeman wrote: Well, if you decide to play with it I'll offer up: https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/ Hm. I'm too chicken to try it because I'm not sure it does what I think it does, but does the "--ephemeral" option pretty much do *exactly* what Dale was asking about? Can you start your current "/" as a container as-is, emerge packages in it and save them as binaries, then install those from the outside, then shutdown the container and all is forgotten?
Re: [gentoo-user] Re: Compiling first and then installing using -K
On Mon, Feb 17, 2020 at 2:24 PM Nikos Chantziaras wrote: > > On 17/02/2020 21:05, Rich Freeman wrote: > > I wouldn't use a chroot for anything at this point - anything you can > > do with one you can do just as easily with a container, with more > > separation. They're just as easy to set up as well - I personally use > > nspawn to run my containers but I'm sure lxc is almost as simple and > > of course it doesn't require running systemd. > > nspawn seems very nice indeed. Haven't used it before, and that's simply > because I never heard of it :-) Now that I did, it looks like it's what > I'll be using from now on: > > https://wiki.archlinux.org/index.php/Systemd-nspawn Well, if you decide to play with it I'll offer up: https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/ That, and: ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=guest --directory=/path/to/container/root --network-bridge= KillMode=mixed Type=notify Though, if I didn't already have this recipe handy I'd be using nspawn units I suppose. Oh, this does require a bridge for your networking. If you're using KVM you probably already have one set up - the approach is identical. Rich
[gentoo-user] Re: Compiling first and then installing using -K
On 17/02/2020 21:05, Rich Freeman wrote: I wouldn't use a chroot for anything at this point - anything you can do with one you can do just as easily with a container, with more separation. They're just as easy to set up as well - I personally use nspawn to run my containers but I'm sure lxc is almost as simple and of course it doesn't require running systemd. nspawn seems very nice indeed. Haven't used it before, and that's simply because I never heard of it :-) Now that I did, it looks like it's what I'll be using from now on: https://wiki.archlinux.org/index.php/Systemd-nspawn Getting back to the original topic - you can just build binary packages for stuff like qt without using a container, but if you do so you won't be able to build more than one layer of dependencies. Unfortunately, Qt depends on itself (qtgui depends on qtbase, for example,) so you can't even do that.
Re: [gentoo-user] Re: Compiling first and then installing using -K
On Mon, Feb 17, 2020 at 1:21 PM Nikos Chantziaras wrote: > > probably much slower.) A chroot or container on the other hand is > extremely lightweight. There's no virtualization involved (or very > little of it), so it should be pretty much as fast as a native system. Chroots and containers are exactly as fast as the native system, and don't involve any virtualization. In fact, on linux you can't NOT run a process in a chroot or container. Every process has a root directory and a set of namespaces applied to it, including init, and every new process just inherits the settings of the process that execed it. All linux users are essentially using at least one container. As such, running more than one container doesn't involve any kernel behavior that running a single container doesn't involve. Now, it is true that if you're running multiple containers you're more likely to have multiple copies of glibc and so on in RAM, and thus there is a memory overhead, though that applies system-wide, and not just to the processes running inside the additional containers. Maybe the one bit of overhead is the first time you launch a particular process in a particular container any shared libraries it uses will have to be loaded into RAM, while on the host there is a decent chance that some of them are already in RAM. We're really splitting hairs at this point, however. I wouldn't use a chroot for anything at this point - anything you can do with one you can do just as easily with a container, with more separation. They're just as easy to set up as well - I personally use nspawn to run my containers but I'm sure lxc is almost as simple and of course it doesn't require running systemd. Getting back to the original topic - you can just build binary packages for stuff like qt without using a container, but if you do so you won't be able to build more than one layer of dependencies. It still cuts down on the merge time considerably, but obviously not as much as it does if you build everything ahead of time. -- Rich
[gentoo-user] Re: Compiling first and then installing using -K
On 17/02/2020 20:01, Dale wrote: Nikos Chantziaras wrote: On 17/02/2020 10:26, Dale wrote: I ran into a issue with qt upgrades and it got interesting. Since it was part way through, some applications that I needed wouldn't open due to a mismatch in versions. [...] !!! --buildpkgonly requires all dependencies to be merged. !!! Cannot merge requested packages. Merge deps and try again. So, I have to emerge packages in order to emerge others. I get that packages depend on each other but is there a way around that? You'd need to maintain two gentoo installs (A and B) with the same exact configuration with B serving as the build machine. Then you'd emerge the packages in B, make binary packages out of every package, and then emerge those in A. Would a chroot work for that? I'm pretty sure it would but want to be certain before I set all that up. I'm pretty sure I can dig around and find a hard drive somewhere. Sure. Although it might be easier to use a container instead (like LXD or Docker.) Grub has nothing to do with it. You wouldn't actually run grub in the container or chroot. You'd only install the grub package. A VM like Mark suggested would probably be even easier to set up. Although getting to the packages would be more complicated and it would also be slower (and with the recent meltdown/spectre mitigation stuff, probably much slower.) A chroot or container on the other hand is extremely lightweight. There's no virtualization involved (or very little of it), so it should be pretty much as fast as a native system.
Re: [gentoo-user] Firefox and script block tool/addon
Spackman, Chris wrote: > On 2020/02/17 at 02:31am, Dale wrote: >> Dale wrote: >> I been playing with this add-on and watched some videos on it. While >> it does some things better, it just isn't specific enough for what I >> need. In some cases, if I blocked scripts with it, some sites >> wouldn't work at all or caused other issues. In a way it's better than >> noscript but it still just doesn't go far enough. I wish adblock >> would list elements the way it used to. That worked great because I >> could block scripts on a individual basis. Allow the ones I need and >> block the ones that cause issues. > I'm really surprised that umatrix (not ublock origin!) can't do what you > need. As you note, it is much more granular than NoScript. Blocking > elements at the subdomain level, you'd think, would be granular enough > for most web pages. > > Are you saying you want to additionally allow / block scripts not just > on a per-subdomain basis but on a per-individual-script basis? I've been > using things like NoScript and uMatrix for many years, and I don't think > even I would want to deal with that. How would you know which ones to > allow? The Reg is showing 7, of which I allow 3. The Guardian has like > 28, of which I allow 19. It would not be fun to try to go through all of > those to figure out which ones are absolutely necessary. You'd be > examining, allowing, and reloading 20 times per site, at first. > > Maybe the Tor Browser people would be interested in working on such an > add on? > Yes, blocking on a per script basis is what I need. On one site, I'm sure it has a couple dozen scripts on it. From what I could see, I really only need to block 2 maybe 3. The others are needed for certain things on the page to work. Some are needed to make the page load at all. The thing about getting it set up, once done, it's done. It may take 30 minutes or a hour but once it is done, it won't require much if any attention from then on. As I pointed out, I used to do this in Seamonkey with adblock. It worked well. In some cases, I'd block all by default and then set exceptions for the ones I need to work. Whichever is easier. Maybe one day I'll run up on a add-on that does this. Maybe. ;-) Dale :-) :-)
Re: [gentoo-user] Re: Compiling first and then installing using -K
On Mon, Feb 17, 2020 at 11:02 AM Dale wrote: > Nikos Chantziaras wrote: > > On 17/02/2020 10:26, Dale wrote: > >> I ran into a issue with qt upgrades and it got interesting. Since it > >> was part way through, some applications that I needed wouldn't open due > >> to a mismatch in versions. [...] > >> > >> !!! --buildpkgonly requires all dependencies to be merged. > >> !!! Cannot merge requested packages. Merge deps and try again. > >> > >> So, I have to emerge packages in order to emerge others. I get that > >> packages depend on each other but is there a way around that? > > You'd need to maintain two gentoo installs (A and B) with the same > > exact configuration with B serving as the build machine. Then you'd > > emerge the packages in B, make binary packages out of every package, > > and then emerge those in A. > > > > > > > > > Would a chroot work for that? I'm pretty sure it would but want to be > certain before I set all that up. I'm pretty sure I can dig around and > find a hard drive somewhere. > > While at it, I wouldn't want grub or anything to pick it up. Since grub > does so much automatically, would it "detect" that install or would it > ignore it? > > Thanks. > > Dale > > Virtualbox should do it. Easy to maintain, easy to delete when your done. > It will create a virtual disk using space on your current system so no > requirement for a new drive. You can take images for backup if you ever > decide you need that. Gentoo is very happy in a VB VM. Mark
Re: [gentoo-user] Re: Compiling first and then installing using -K
Nikos Chantziaras wrote: > On 17/02/2020 10:26, Dale wrote: >> I ran into a issue with qt upgrades and it got interesting. Since it >> was part way through, some applications that I needed wouldn't open due >> to a mismatch in versions. [...] >> >> !!! --buildpkgonly requires all dependencies to be merged. >> !!! Cannot merge requested packages. Merge deps and try again. >> >> So, I have to emerge packages in order to emerge others. I get that >> packages depend on each other but is there a way around that? > You'd need to maintain two gentoo installs (A and B) with the same > exact configuration with B serving as the build machine. Then you'd > emerge the packages in B, make binary packages out of every package, > and then emerge those in A. > > > Would a chroot work for that? I'm pretty sure it would but want to be certain before I set all that up. I'm pretty sure I can dig around and find a hard drive somewhere. While at it, I wouldn't want grub or anything to pick it up. Since grub does so much automatically, would it "detect" that install or would it ignore it? Thanks. Dale :-) :-)
Re: [gentoo-user] packages.gentoo.org: Empty page
On 2/16/20 6:42 PM, Dale wrote: Alexey Mishustin wrote: I'm in the southeast part of USA and your link works here with Seamonkey.� This is the link I have bookmarked. https://packages.gentoo.org/packages/updated I found a consolidated list that might fit your need if/when the other lists are problematic:: https://gentoobrowse.randomdan.homeip.net/#2020-02-17 I have to manually refresh it dailey, and as you scroll down, it lists up the the (3) most recent days of releases. hth, James
Re: [gentoo-user] Firefox and script block tool/addon
On 2020/02/17 at 02:31am, Dale wrote: > Dale wrote: > I been playing with this add-on and watched some videos on it. While > it does some things better, it just isn't specific enough for what I > need. In some cases, if I blocked scripts with it, some sites > wouldn't work at all or caused other issues. In a way it's better than > noscript but it still just doesn't go far enough. I wish adblock > would list elements the way it used to. That worked great because I > could block scripts on a individual basis. Allow the ones I need and > block the ones that cause issues. I'm really surprised that umatrix (not ublock origin!) can't do what you need. As you note, it is much more granular than NoScript. Blocking elements at the subdomain level, you'd think, would be granular enough for most web pages. Are you saying you want to additionally allow / block scripts not just on a per-subdomain basis but on a per-individual-script basis? I've been using things like NoScript and uMatrix for many years, and I don't think even I would want to deal with that. How would you know which ones to allow? The Reg is showing 7, of which I allow 3. The Guardian has like 28, of which I allow 19. It would not be fun to try to go through all of those to figure out which ones are absolutely necessary. You'd be examining, allowing, and reloading 20 times per site, at first. Maybe the Tor Browser people would be interested in working on such an add on? -- Chris Spackman ch...@osugisakae.com ESL Coordinator The Graham Family of Schools ESL Instructor Columbus State Community College Japan Exchange and Teaching Program Wajima, Ishikawa 1995-1998 Linux user since 1998 Linux User #137532
[gentoo-user] Re: Compiling first and then installing using -K
On 17/02/2020 10:26, Dale wrote: I ran into a issue with qt upgrades and it got interesting. Since it was part way through, some applications that I needed wouldn't open due to a mismatch in versions. [...] !!! --buildpkgonly requires all dependencies to be merged. !!! Cannot merge requested packages. Merge deps and try again. So, I have to emerge packages in order to emerge others. I get that packages depend on each other but is there a way around that? You'd need to maintain two gentoo installs (A and B) with the same exact configuration with B serving as the build machine. Then you'd emerge the packages in B, make binary packages out of every package, and then emerge those in A.
Re: [gentoo-user] Firefox and script block tool/addon
Dale wrote: > Corpo wrote: >> Le 24/01/2020 à 22:52, Dale a écrit : >>> Howdy, >>> >>> I use Firefox and have a issue with scripts on some sites. I have >>> noscript installed and for the most part, it works. That said, there is >>> times when it doesn't do what I need. It seems, from what I can find >>> anyway, that you can either allow scripts or not allow scripts but can't >>> pick and choose. For example. Let's say I'm on abc.com and I need some >>> scripts to run but want to block other scripts. With noscript, I either >>> allow all from a site or none. What I'd like to find is a script block >>> tool that will list all the scripts and allow me to block some but allow >>> others. Believe it or not, I use to use adblock, a much older version, >>> to do this. I'd tell adblock to list all the objects, sort them by type >>> and then go through the scripts until I find the magic settings that >>> allows the site to work but not run scripts I don't want. >>> >>> I've installed and tried quite a few script block tools but none of them >>> seem to do what I want to do. I've even tried a few addons that only >>> had a very few users, just hoping it would do this. Has anyone ever >>> seen a script block tool, or some other tool with a different name, that >>> works this way? I need a addon that allows me to refine and be >>> selective on what scripts run and which ones are blocked. >>> >>> Thanks much to all. >>> >>> Dale >>> >>> :-) :-) >>> >> umatrix maybe? >> >> >> > > I installed it and I think it will do what I want. I just need to > figure out the details of how to make it get there. Based on the > description, it seems to be the best one yet. Now to head over to > youtube and see some tips and tricks. ;-) I might add, one website > that was really bad seems to be a lot better. Time will tell tho. > > Thanks. > > Dale > > :-) :-) > I been playing with this add-on and watched some videos on it. While it does some things better, it just isn't specific enough for what I need. In some cases, if I blocked scripts with it, some sites wouldn't work at all or caused other issues. In a way it's better than noscript but it still just doesn't go far enough. I wish adblock would list elements the way it used to. That worked great because I could block scripts on a individual basis. Allow the ones I need and block the ones that cause issues. Thanks for the info. It was worth a try at least. Dale :-) :-)
[gentoo-user] Compiling first and then installing using -K
Howdy, I ran into a issue with qt upgrades and it got interesting. Since it was part way through, some applications that I needed wouldn't open due to a mismatch in versions. When I tried to logout and back in, sddm wouldn't come up either, same reason I assume. Now that I'm back, I'm wanting to see if I can do upgrades by building the packages first and then using the -K option. Thing is, when I tried that just now for the rest of this huge upgrade, I get this little message at the bottom. !!! --buildpkgonly requires all dependencies to be merged. !!! Cannot merge requested packages. Merge deps and try again. So, I have to emerge packages in order to emerge others. I get that packages depend on each other but is there a way around that? Would I need to set up a chroot and build it there or is there a better way. Since it is the compiling that seems to cause issues generally, I'm wanting to do that first and then it just install from the binary. I figure someone out there has found a good way to do this. I just hope someone is willing to share their good way to do this. ;-) Dale :-) :-)
