Re: [gentoo-user] nvidia-drivers-396.24-r1
I have exactly the same kernel (4.14.52-gentoo) and nvidia-drivers (396.24-r1) and I don't experience this issue (though games requiring Vulkan crash out sporadically - there's an ongoing issue on the nvidia forums for this, where apparently it's already been fixed in some ancient fork, and not merged back). Perhaps this is specific to the card? I have a 660ti. Have you checked that the nvidia module is even being loaded (lsmod | grep nvidia)? -d On July 9, 2018 00:46:34 Philip Webb wrote: 180610 Philip Webb wrote: I updated to the latest stable Nvidia-drivers-396.24-r1 , rebooted & 'startx' : the result was an X error "No devices detected ... no screens found". Downgrading to 390.48 got X working again. Nothing to see on the Forum or among Gentoo 'nvidia' bugs. My kernel is 4.9.16-gentoo. I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above with the same result ; downgrading to 390.67 got X working again. Has anyone else experienced this problem or similar ? Does anyone have advice ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] nvidia-drivers-396.24-r1
On 2018.07.08 18:46, Philip Webb wrote: 180610 Philip Webb wrote: > I updated to the latest stable Nvidia-drivers-396.24-r1 , > rebooted & 'startx' : > the result was an X error "No devices detected ... no screens found". > Downgrading to 390.48 got X working again. > Nothing to see on the Forum or among Gentoo 'nvidia' bugs. > My kernel is 4.9.16-gentoo. I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above with the same result ; downgrading to 390.67 got X working again. Has anyone else experienced this problem or similar ? Does anyone have advice ? Check the xorg log. New(er) nvidia-drivers often take a bit of time to get upgraded to handle the most recent kernels. There is likely a more concrete (if no less helpful) message in the xorg log. You may need to stick to an older driver and/or kernel until one of them catches up with the other. (I no longer have an nvidia card in my Gentoo box, so I have no current specifics, but even when I did, it was legacy 340.xx. Jack
Re: [gentoo-user] nvidia-drivers-396.24-r1
180610 Philip Webb wrote: > I updated to the latest stable Nvidia-drivers-396.24-r1 , > rebooted & 'startx' : > the result was an X error "No devices detected ... no screens found". > Downgrading to 390.48 got X working again. > Nothing to see on the Forum or among Gentoo 'nvidia' bugs. > My kernel is 4.9.16-gentoo. I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above with the same result ; downgrading to 390.67 got X working again. Has anyone else experienced this problem or similar ? Does anyone have advice ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] how best to encrypt a file
180703 Alec Ten Harmsel wrote: > On Tue, Jul 03, 2018 at 05:47:22AM -0400, Philip Webb wrote: >> I have a couple of small files which need to be encrypted : >> one is simple text ( .txt ), the other a spreadsheet ( .ods ). >> I haven't used encryption like this before : what do others use ? > I have used `gpg' to do this before: > # Encrypt with a passphrase > gpg -c > # Decrypt > gpg -d .gpg Thanx for this : I've used it to do the encryption I want. Thanx also to the others who replied : I will add the info to my notes. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: Re[4]: Re: Portage, git and shallow cloning
Rich Freeman wrote: > emerge --sync works just fine if > there are uncommitted changes in your repository, whether they are > indexed or otherwise. You are right. It seems to be somewhat "random" when git pull refuses to work and when not. I could not detect a common scheme. Maybe this has mainly to do with using overlayfs and git becoming confused.
Re: [gentoo-user] Re: Re[4]: Re: Portage, git and shallow cloning
On Sun, Jul 8, 2018 at 4:28 AM Martin Vaeth wrote: > > Rich Freeman wrote: > > It's the *history* of the metadata which matters here: You make a reasonable point here. > > "The council does not require that ChangeLogs be generated or > > distributed through the rsync system. It is at the discretion of our > > infrastructure team whether or not this service continues." > > The formulation already makes it clear that one did not want to > put pressure on infra, and at that time it was expected that > every user would switch to git anyway. The use of git for history, and yes, in general the Council tries not to forbid projects from providing services. The intent was to communicate that it was simply not an expectation that they do so. > At that time also the gkeys project was very active, and git was > (besides webrsync) the only expected way to get checksums for the > full tree. In particular, rsync was inherently insecure. Honestly, I don't think gkeys really played any part in this, but there was definitely an intent for signature checking in the tree to become more robust. As you point out (in a part I trimmed) it ought to be possible to do this. Indeed, git support for signing commits was considered a requirement for git implementation. > >> 4. Even if the user made the mistake to edit a file, portage should > >>not just die on syncing. > > > > emerge --sync won't die in a situation like in general. > > It does: git push refuses to start if there are uncommitted changes. > I did a test before I made my post. emerge --sync works just fine if there are uncommitted changes in your repository, whether they are indexed or otherwise. I didn't test merge conflicts but I'd hope it would fail if these exist. -- Rich
[gentoo-user] Re: Re[4]: Re: Portage, git and shallow cloning
Rich Freeman wrote: >> I was speaking about gentoo's git repository, of course >> (the one which was attacked on github), not about a Frankensteined one >> with metadata history filling megabytes of disk space unnecessarily. >> Who has that much disk space to waste? > > Doesn't portage create that metadata anyway when you run it You should better have it created by egencache in portage-postsyncd; and even more you should download some other repositories as well (news announcements, GLSA, dtd, xml-schema) which are maintained independently, see e.g. https://github.com/vaeth/portage-postsyncd-mv It is the Gentoo way: Download only the sources and build it from there. That's also a question of mentality and why I think most gentoo users who use git would prefer that way. > negating any space savings at the cost of CPU to regenerate the cache? It's the *history* of the metadata which matters here: Since every changed metadata file requires a fraction of a second, one can estimate rather well that several ten thousand files are changed hourly/daily/weekly (the frequency depending mainly on eclass changes: One change in some eclass requires a change for practically every version of every package) so that the history of metadata changed produced by this over time is enormous. This history, of course, is completely useless and stored completely in vain. One of the weaknesses of git is that it is impossible, by design, to omit such superfluous history selectively (once the files *are* maintained by git). >> For the official git repository your assertions are simply false, >> as you apprently admit: It is currently not possible to use the >> official git repo (or the github clone of it which was attacked) >> in a secure manner. > > Sure, but this also doesn't support signature verification at all > [...] so your points still don't apply. Hu? This actually *was* my point. BTW, portage might easily support signature verification if just distribution of the developers' public keys would be properly maintained (e.g. via gkeys or simpler via some package): After all, gentoo infra should always have an up-to-date list of these keys anyway. (If they don't, it would make it even more important to use the source repo instead of trusting a signature which is given without sufficient verification) >> Your implicit claim is untrue. rsync - as used by portage - always >> transfers whole files, only. > > rsync is capable of transferring partial files. Yes, and portage is explicitly disabling this. (It costs a lot of server CPU time and does not save much transfer data if the files are small, because a lot of hashes have to be transferred (and calculated - CPU-time!) instead.) > However, this is based on offsets from the start of the file There are new algorithms which support also detection of insertions and deletions via rolling hashes (e.g. for deduplicating filesystems). Rsync is using quite an advanced algorithm as well, but I would need to recheck its features. Anyway, it plays no role for our discussion, because for such small files it hardly matters, and portage is disabling said algorithm anyway. > "The council does not require that ChangeLogs be generated or > distributed through the rsync system. It is at the discretion of our > infrastructure team whether or not this service continues." The formulation already makes it clear that one did not want to put pressure on infra, and at that time it was expected that every user would switch to git anyway. At that time also the gkeys project was very active, and git was (besides webrsync) the only expected way to get checksums for the full tree. In particular, rsync was inherently insecure. The situation has changed meanwhile on both sides: gkeys was apparently practically abandoned, and instead gemato was introduced and is actively supported. That suddenly the gentoo-mirror repository is more secure than the git repository is also a side effect of gemato, because only for this the infra keys are now suddenly distributed in a package. > If you're using squashfs git pull probably isn't the right solution for you. Exactly. That's why I completely disagree with portage's regression of replacing the previously working solution by the only partially working "git pull". >> 4. Even if the user made the mistake to edit a file, portage should >>not just die on syncing. > > emerge --sync won't die in a situation like in general. It does: git push refuses to start if there are uncommitted changes. > but I don't think the correct default in this case should be > to just wipe out the user's changes. I do: Like for rsync a user should not do changes to the distributed tree (unless he makes a PR) but in an overlay; otherwise he will permanently have outdated files which are not correctly updated. *If* a user wants such changes, he should correctly use git and commit. But I am not against to make this an opt-in option for enabling it by a developer (or advanced
