systemdlete | I installed davfs2 and mounted a http://... link with it. Both root AND regular user can create DIRECTORIES on the mounted file system, but they cannot create REGULAR files. | 00:21 |
---|---|---|
systemdlete | I've googled for this, and this was an issue way back when. I mean, like, 2006. So I'd think that would have been fixed by now, or some help would be given. | 00:21 |
systemdlete | New directories are created with correct ownership, and seem to reflect correct perms, taking into account the regular user's umask also. | 00:23 |
systemdlete | I've tried mounting with uid and gid to davfs2 but no help. | 00:24 |
systemdlete | I should mention, I supposed, that this is on ascii in a VM. | 00:25 |
systemdlete | nvm I figured it out. Seems you have to set the use_locks to 0 | 00:31 |
systemdlete | (that sounds dangerous. And it doesn't really explain the error -- why is creating directories OK, but not regular files with locks enabled?) | 00:32 |
systemdlete | or maybe I haven't REALLY figured it out. Maybe this is a kludge only? | 00:32 |
tom_work | Hello | 02:42 |
tom_work | I can't modprobe wireguard because the one provided by stable-backports is failing digital signature check | 02:43 |
tom_work | # modprobe wireguard | 02:43 |
tom_work | modprobe: ERROR: could not insert 'wireguard': Required key not available | 02:43 |
gnarface | tom_work: the running kernel is also from backports? if the module is the one that came with that kernel version i've got nothing, sorry. | 03:24 |
gnarface | i haven't messed with wireguard at all yet | 03:25 |
tom_work | the kernel is stable | 03:27 |
tom_work | the module came from bpo-stable | 03:27 |
gnarface | tom_work: ah, yea that's what thought you might be inferring. don't do that. if you're using modules from backports, use the kernel to match. same goes for firmware packages and non-free drivers. | 03:30 |
tom_work | why? | 03:31 |
gnarface | the short version is "economics" | 03:31 |
tom_work | the wireguard module was built specifically for 4.19 stable | 03:31 |
tom_work | and kernel 5.9 | 03:31 |
tom_work | well it's buggy and full of regressions | 03:31 |
tom_work | isn't it slower and larger too? | 03:32 |
tom_work | and because it's not stable it's going to be less secure | 03:32 |
gnarface | straw men | 03:32 |
gnarface | you've surrounded yourself with an army of straw men then surrendered to them | 03:33 |
gnarface | none of it is real without testing | 03:33 |
gnarface | and what i can tell you my testing has born: backports kernels, firmware, and modules are not intended to be used ala carte | 03:33 |
tom_work | I've run 5.6 on my workstation | 03:34 |
tom_work | can't keep 2 days uptime | 03:34 |
gnarface | i'm sorry to hear that but at this point i'm suspecting the issue is self-inflicted | 03:34 |
tom_work | weird stuff like certain netfilter rules when ipv6 packets flow through them anything else using ipv6 hangs | 03:34 |
gnarface | my guess is the failure to keep more than 2 days uptime with kernel 5.6 is very likely to have also been related to inappropriate pairings of certain key system component versions | 03:35 |
gnarface | there are some rules about Debian that are less well documented because they're a testing issue that ties directly to an economic issue, but if you follow the rules you tend not to have problems like this | 03:36 |
gnarface | if you start mixing and matching stuff all willy-nilly then well, you get what you ask for | 03:37 |
gnarface | you have to understand that the testing upstream doesn't account for this type of wild version-reshuffling | 03:38 |
gnarface | and frankly there's no money for it here | 03:38 |
gnarface | so that means you're likely testing combinations of modules and kernel versions that were literally never tested together before this | 03:39 |
gnarface | or, well, just reject my advice and continue to suffer. | 03:40 |
malikith | I've never been a fan of the backports, particularly for drivers/kernel. As for Wireguard, I compiled my kernel module from source. Probably the best way to go in my opinion. Works fine: https://www.wireguard.com/compilation/ | 03:41 |
gnarface | if you build it against the running kernel with matching headers, i don't see why it wouldn't work within a certain range of sanely-recent, supportable kernels. that doesn't sound remotely like what he was doing though, and i have no reason to believe that the beowulf-backports kernel is unstable without tampering, i've tested it rather extensively here | 03:44 |
gnarface | (as a nvidia customer you're fucking stuck with bleeding edge kernels, basically) | 03:45 |
gnarface | (that is, if you're actually doing anything with the cards) | 03:45 |
gnarface | he's already gone though so he will benefit from none of this insight | 03:46 |
smak | tried beowulf and the amdgpu stack was lacking support | 03:55 |
smak | graphics were fine but opencl was the snag.. | 03:56 |
smak | which release is closest to 16.04? | 03:57 |
gnarface | smak: uh... my sources tell me ubuntu 16.04 corresponded to debian stretch, which corresponds to devuan ascii, the version before beowulf, actually. rolling back to that is unlikely to fix your issue though since it predates your hardware probably. are you sure you didn't just forget to install the firmware-amd-graphics package? | 04:04 |
gnarface | smak: (ubuntu would have included non-free firmware by default even if you didn't ask for it, debian does not do that, and devuan only does it for the wifi firmware in the netinstall image) | 04:05 |
gnarface | smak: (AMD says their cards don't require the firmware but all you get is basic 2d unaccelerated framebuffer support without it) | 04:06 |
gnarface | smak: if you need a newer kernel (which is likely for a recent amdgpu video card) then make sure you get the kernel and that firmware-amd-graphics package both from beowulf-backports so you have a matching set | 04:07 |
smak | yeah i got a 5600 and although its not cutting edge (5700's are out as well as 3080's pretty popular) there were some issues.. notably ubuntu 20 posed some problems i could not overcome but 16.04's working well | 04:09 |
smak | i use the proprietary drivers downloaded from amd after updating repo with non free | 04:10 |
beagleburt | G'day from New Zealand everyone! I have installed Beowulf on a friend's box & have run into problems with Synaptic. I downloaded many Mate Desktop programs plus a few others but at the end of a mainly successful dwnld/installation I got the following msg: http://paste.debian.net/1167374 | 04:12 |
smak | i do believe i read the amdgpu stack is self contained for all distros other than redhat tho | 04:12 |
fsmithred | beagleburt, run 'apt update' and when it asks, say "yes" | 04:14 |
fsmithred | or apt-get --some-option-I-can't-remember update | 04:14 |
gnarface | smak: it was probably a mistake to get the drivers directly from AMD. that might work but this distro is only tested with stuff that is in the distro. | 04:14 |
smak | i thought get was depreciated | 04:15 |
gnarface | smak: you seem to be carrying TWO pieces of harmful misinformation in your head then | 04:15 |
smak | hrmm so if i venture another go you suggest just amdgpu-pro and the mesa opencl repo? | 04:16 |
fsmithred | --allow-releaseinfo-change | 04:16 |
fsmithred | 04:16 | |
gnarface | smak: no, i would suggest you get everything from beowulf first, but dont' forget the non-free firmware this time. it's only "self-contained" in the sense that it's also present in the distro. and if that doesn't work then ONLY upgrade the kernel, kernel headers, and firmware packages beowulf-backports, nothing else, and don't get any 3rd party software before it works | 04:17 |
smak | worth a shot.. | 04:18 |
gnarface | smak: in general this is the approach that has worked for other amdgpu users | 04:18 |
gnarface | smak: (and incidentally, nvidia users with 1060's and later, too) | 04:18 |
beagleburt | fsmithred, tku! I will try to instruct my (non-computer literate) friend to do those suggestions. BTW: what does 'qq' mean? | 04:19 |
gnarface | smak: unbuntu society diverged, they advise certain procedures that are considered borderline suicidal here | 04:19 |
smak | i am trying to push for a 3DFX revival, hoping for a new Voodoo card | 04:19 |
gnarface | hehe | 04:19 |
smak | ya ubuntu isn't my choice distro using now purely out of necessity to get SOME drivers working | 04:20 |
gnarface | smak: well, most the practical difference for most people is just that they include all the packages you need so you don't have to figure out that you need to enable non-free to install stuff like firmware-amd-graphics manually | 04:21 |
gnarface | smak: sometimes they'll be quicker to release a fixed version, but most the time that means they're also just as quick to release broken versions | 04:21 |
fsmithred | qq means I tried to quit while I was in the wrong window. twice | 04:21 |
fsmithred | just have friend do apt update and say yes. Easy to remember. | 04:22 |
beagleburt | fsmithred, ok - t.a. 'b'ye for now | 04:22 |
gnarface | smak: oh, and permissions will be different if you're not familiar with how Ubuntu used to work before systemd | 04:22 |
smak | are there any plans to diverge from the standard debian release with native zfs installs and the like? | 04:22 |
gnarface | smak: one other gotcha - make sure you're in the "video" group | 04:22 |
fsmithred | aren't there licensing issues with zfs? | 04:23 |
gnarface | smak: i'm not an official source in this context, but afaik there are currently no plans to diverge from debian any more than it already has | 04:23 |
gnarface | fsmithred: yes, still, afaik, but that's never been common knowledge because people don't understand how BSD could have it too then :-/ | 04:23 |
smak | what permissions need to be formalized? i havent had to actually do anything there since old freebsd audio required a sound group | 04:24 |
fsmithred | your answer was better, anyway. We don't want to do any more work than is necessary. | 04:24 |
gnarface | smak: depends on what you're doing, to a significant degree. at least video and audio, you'll probably want. it'll only put you in the group matching your username, by default. | 04:25 |
smak | gnarface okay thats cool, thanks you have been super helpful. | 04:25 |
smak | hrmm i havent done anything yet but its a side box not my primary which is running openbsd currently | 04:25 |
gnarface | smak: no problem. here's a debian wiki entry about system groups that should still be mostly relevant https://wiki.debian.org/SystemGroups | 04:25 |
gnarface | smak: (scroll down to "groups without an associated user" for the list of stuff you might want to add yourself to. as i'm looking at this, you probably want to be in the "cdrom" group too if you have an optical drive) | 04:26 |
smak | ya i know there is great use to be made for security but i havent ventured too far in to seperate slices and permissions just yet, still honing my pf skillset | 04:26 |
smak | tbh | 04:27 |
fsmithred | look in /etc/adduser.conf for EXTRA_GROUPS | 04:27 |
gnarface | smak: in general for stuff like this, filesystem permissions, system group designations, etc, you'll find that documentation pertaining to Debian Wheezy will still be mostly accurate for all versions of Devuan | 04:27 |
smak | cool i'll check it when i go for a new install | 04:27 |
fsmithred | you might want netdev and plugdev | 04:27 |
fsmithred | I think you'll get most of those groups if you create a user in the installer | 04:29 |
gnarface | i'm not sure, i think it depends on the choices | 04:29 |
gnarface | other choices that seem unrelated | 04:29 |
fsmithred | that could be | 04:30 |
danuan | <gnarface> no necessarily so, for nvidia drivers , especialy when doing cuda installs i went trough like 6 iterations before making it all work , and it always seemed , approved drivers or cuda from repositories would majorly fail or just partialy. and proprietary nvidia install always were best | 04:30 |
smak | back in the day getting my 7950 was a task too, fotunately people were much more open about optimizing configurations at that time though | 04:32 |
gnarface | danuan: well, i admit that my one dive into cuda included the shocking revelation that their "reverse-compatibility" attempt at an API level itself actually sabotaged reverse compatibility with a library i'd compiled made to support Rage in Wine with the extra eye-candy, so your account is highly believable, but doesn't really change my advice | 04:32 |
gnarface | danuan: (sometimes you might have to make a choice between CUDA working and the rest of the system working) | 04:33 |
smak | is rage that game with a gorilla on the cd cover? i think i have an unopened copy kicking around | 04:33 |
smak | with like 3 copies of leisure suit larry heh | 04:33 |
gnarface | gorilla?... hmm, i don't think so... uh | 04:33 |
danuan | i know nothing of cuda , btw , i was doing it for someone with a few different cards , trying to figure out which latest driver version for which card would support which version of cuda . | 04:34 |
gnarface | smak: are you thinking of Rampage? hehe, this is the Rage i'm talking about: https://en.wikipedia.org/wiki/Rage_(video_game) | 04:34 |
smak | no i just checked its "primal rage" | 04:34 |
gnarface | smak: for the first 3 weeks it actually worked better in Wine than windows, then wine suffered a mysterious regression that lasted until exactly the day after nobody cared about Rage in Windows anymore | 04:35 |
gnarface | oh shit i'm starting to editorialize now, i guess that means it's time for me to take a break | 04:35 |
gnarface | peace all, i'll be back later | 04:36 |
smak | cool looks very book of eli.. id made some pretty great games man. | 04:36 |
brocashelm | getting a segmentation fault in ceres when i try to load file or url on mpv; anything possibly related to updating libmesa or another video driver? | 17:11 |
brocashelm | i can confirm: mesa-va-drivers and mesa-vdpau-drivers are causing segfaults with processes such as mpv | 17:21 |
brocashelm | (for ceres/unstable) | 17:21 |
fsmithred | same version of mpv in chimaera is working | 17:22 |
fsmithred | huh. Maybe you should remove those mesa packages. They aren't installed here. | 17:23 |
xinomilo | just upgraded mesa* to 20.2.1 and mpv still works, but might need to reboot to check for sure | 17:25 |
brocashelm | it happened the moment i upgraded | 17:26 |
brocashelm | so i apt held them for the time being | 17:27 |
fsmithred | well, I can't install it to test. I just filled up my root parttition. | 17:27 |
brocashelm | at least one of these is causing segfaults (some were held back automatically by the repo because deps not yet satisfied): libegl-mesa0 libegl1-mesa-dev libgbm1 libgbm1:i386 libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-dri:i386 libglapi-mesa libglapi-mesa:i386 libgles2-mesa-dev libglx-mesa0 libglx-mesa0:i386 libosmesa6:i386 libxatracker2 mesa-va-drivers mesa-vdpau-drivers mesa-vulkan-drivers mesa-vulkan-drivers:i386 | 17:29 |
fsmithred | I added the first two mesa libs you mentioned, but they are chimaera versions. Still working ok. | 17:36 |
brocashelm | strange. not sure why that happened | 17:40 |
fsmithred | I have a ceres VM, but it's gonna take some time to upgrade and install some things | 17:41 |
xinomilo | no i386 here, so i guess its arch-specific packages at fault | 17:58 |
brocashelm | amd64 for me | 18:32 |
brocashelm | i think i'll just keep those packages on hold for a while until debian package team issues a fix | 18:33 |
brocashelm | their devs have been upgrading builds like crazy lately | 18:33 |
oel | \join #wpdk1 | 18:53 |
hagbard_ | forward slash | 18:55 |
oel | yes ;) | 18:55 |
systemdlete | how do I install the headers for libc? If I try to install stdlibc++, it wants to install 2gb of files. I don't need 98% of them. I just want, say, <sys/time.h> etc | 20:04 |
systemdlete | stdlibc++ wants to install all sorts of x-compile and arch headers. I don't need/want them all. | 20:04 |
fsmithred | systemdlete, this one? linux-libc-dev: /usr/include/linux/time.h | 20:11 |
systemdlete | That's installed. | 20:11 |
systemdlete | and so is libc6-dev | 20:11 |
systemdlete | I think I see the problem | 20:12 |
systemdlete | There is no link from /usr/include/x86_64-linux-gnu to /usr/include/sys | 20:12 |
systemdlete | and, no, I don't want the kernel headers, just the userland headers | 20:13 |
systemdlete | (I have the kernel headers actually) | 20:13 |
hagbard_ | libc6-dev, i think? | 20:15 |
systemdlete | I've got that one (see above) | 20:15 |
fsmithred | I have /usr/include/x86_64-linux-gnu/sys/ but no /usr/include/sys | 20:17 |
systemdlete | So how is the developer supposed to include, say, <sys/time.h>, which is explicitly named in some of the man pages for time routines? | 20:17 |
systemdlete | (this is kind of silly) | 20:18 |
systemdlete | apt should assume that MOST development work will be for the platform the system is running on. | 20:18 |
systemdlete | Either that, or every unix/linux man(3) page needs serious updating | 20:18 |
* systemdlete longs for the days when these things were done for the user and things progressed more or less straight forward... | 20:19 | |
fsmithred | Are you saying that more was done for the user in the past than is done now? | 20:20 |
systemdlete | no | 20:21 |
fsmithred | I don't know enough to answer your question | 20:21 |
systemdlete | If I have a c source with a call to "#include <sys/time.h>' as shown in various man(3) pages, it doesn't exist. | 20:22 |
systemdlete | (assume the simplest of all c sources here. A 10 liner maybe) | 20:23 |
fsmithred | and normally it should be found in /usr/include/sys/time.h? | 20:23 |
systemdlete | right | 20:23 |
systemdlete | the "angle brackets" usually mean to look under /usr/include | 20:23 |
fsmithred | ln -s /usr/include/x86_64-linux-gnu/sys/time.h /usr/include/time.h | 20:23 |
systemdlete | yep | 20:23 |
fsmithred | sorry | 20:23 |
fsmithred | I dropped a sys | 20:24 |
systemdlete | ??? | 20:24 |
fsmithred | /usr/include/sys/time.h at the end | 20:24 |
fsmithred | but really | 20:24 |
fsmithred | link the whole dir | 20:24 |
systemdlete | of course. But I don't remember this "step" when I did development work on linux in the past. | 20:25 |
systemdlete | I mean, like, 10 years ago maybe, or longer? | 20:25 |
fsmithred | was it on something other than debian? | 20:25 |
systemdlete | probably. RH, CentOS... I didn't do much on debian then. Maybe that's it. | 20:25 |
DPA | In my gcc, /usr/include/x86_64-linux-gnu is in the search path, so include will find it: https://pastebin.com/7FTjcHn2 | 20:25 |
fsmithred | yeah, that would probably make a difference | 20:25 |
systemdlete | But what if that path is not in your search path, DPA? | 20:26 |
systemdlete | What I am saying is that the installer and tools should ASSUME that we are targeting the platform we are running on and only explicitly request when cross-compiling | 20:27 |
systemdlete | which brings up a question. Why isn't that path in *MY* gcc search path then? | 20:28 |
systemdlete | Did I miss a step somehow? | 20:28 |
systemdlete | nvm. I think we have solved this matter. Thanks. | 20:28 |
systemdlete | I'll just make the link, that's all. | 20:28 |
DPA | Then the compiler was wrongly configured, or I think in case of gcc, there is a spec file somewhere. Where did you get it from? | 20:30 |
DPA | gcc, I mean. | 20:31 |
DPA | Oh, it looks like the spec file gets compiled into gcc. I always disliked this compile time config bs regarding libcs that gcc and clang do. | 20:35 |
systemdlete | sounds like maybe too much dependency? | 20:38 |
systemdlete | Sorry, fsmithred. I keep forgetting that this is based on debian. These problems are not the fault of you or devuan really. | 20:39 |
systemdlete | Didn't mean to be a hot-head about it. | 20:40 |
fsmithred | I started with redhat and suse, so I feel your pain. | 20:40 |
brocashelm | i have never installed debian myself | 20:40 |
brocashelm | i did try lmde briefly, but that was it | 20:40 |
brocashelm | devuan is my first proper "debian" install | 20:40 |
fsmithred | all the downstream distros are contaminated with the same "debian way" | 20:41 |
systemdlete | Actually, in this case, I was merely wanting to examine sys/time.h for comparison (reference) with a different kernel level on a different distro -- I didn't expect that the file regimen would be different for these. | 20:41 |
systemdlete | (I know, I know. Again, sorry man) | 20:41 |
fsmithred | np | 20:42 |
systemdlete | I have been thinking -- and I'm sure at least some of you all have too -- if there were a way to sort of "automatically" convert the packages to maybe pacman or apk format (maybe adding some adjustments for sanity), if that wouldn't make life a little easier? I realize this is "work" to a degree, but once the tools to do this transformation were complete, it probably wouldn't be difficult there on out for subsequent releases. | 20:43 |
systemdlete | I like to use "pacapt" because it emulates pacman. I think, though, that I like apk the most. | 20:43 |
systemdlete | (apk being based on the same library as pacman, btw) | 20:43 |
fsmithred | how would that be easier? | 20:44 |
systemdlete | It won't make any difference, in the end, in terms of running devuan, but it might make it easier to locate files etc. | 20:44 |
fsmithred | apt-file find <file> | 20:44 |
fsmithred | apt-file list <package> | 20:45 |
systemdlete | well, for instance, with pacapt, I can find files easily. apt-file is not even installed by default | 20:45 |
systemdlete | at least not here it wasn't. I didn't even know it existed. | 20:45 |
fsmithred | does alien do that? | 20:45 |
systemdlete | what is "alien"? | 20:45 |
fsmithred | converts packages to another type | 20:45 |
systemdlete | oh. | 20:46 |
systemdlete | not sure. | 20:46 |
fsmithred | deb <-> rpm | 20:46 |
systemdlete | ah. | 20:46 |
systemdlete | well, rpm is another beast of great proportions, isn't it? | 20:46 |
systemdlete | I like yum, though, I admit. | 20:46 |
systemdlete | I think apt is supposed to be like yum/dng | 20:46 |
fsmithred | alien [--to-deb] [--to-rpm] [--to-tgz] [--to-slp] [options] file [...] | 20:47 |
systemdlete | I guess that, as long as I have pacapt, I'll be happy enough. It does 99% of the stuff I want/need. | 20:47 |
fsmithred | probably the other way around (yum is supposed to be like apt) | 20:47 |
DHE | rpm is just the raw tool. it has no dependency fetching capabilities and doens't know what a repo is. yum/dnf is that layer | 20:47 |
DHE | so I guess it's like dpkg ? | 20:47 |
fsmithred | yes | 20:48 |
fsmithred | rpm -i <package> | 20:48 |
systemdlete | fsmithred: Yeah, as much as I disliked some aspects of rpm, I do miss the original RH 4 and 5, and later, CentOS | 20:48 |
fsmithred | no pacman in alien | 20:48 |
systemdlete | Well, I think you won this round | 20:49 |
fsmithred | ? | 20:49 |
systemdlete | I should be grateful that we have even devuan. | 20:50 |
systemdlete | ! | 20:50 |
systemdlete | I almost gave up on linux altogether, seriously. I was starting to look at solaris, openindiana | 20:50 |
systemdlete | (their packaging makes debian look very smart) | 20:50 |
fsmithred | kolibri FTW! | 20:55 |
brocashelm | to follow up on my mpv issue earlier, it was hwdec=auto-safe option causing the segfault; works now | 21:11 |
unixbsd | is there a editor like vi in devuan? | 21:14 |
unixbsd | there is no elvis, just only the big, heavy vim.tiny or vim. | 21:14 |
debdog | elvis-tiny? what version of devuan? | 21:15 |
unixbsd | apt-get install install elvis gives nothing found on ascii. | 21:16 |
fsmithred | vim-tiny I think is the default | 21:16 |
unixbsd | beurk | 21:16 |
unixbsd | is there something smaller? | 21:16 |
fsmithred | nano is there | 21:16 |
debdog | p elvis-tiny - Tiny vi compatible editor for the base system | 21:16 |
unixbsd | vi ? | 21:16 |
unixbsd | on slackware, there is vi. | 21:16 |
unixbsd | On bsd, as well. | 21:16 |
fsmithred | Elvis-tiny is based on a 1991 Minix version of elvis. You should install another vi-editor (such as "vim", "elvis" or | 21:17 |
fsmithred | "nvi") if you want a vi editor that is full featured and has no bugs. | 21:17 |
debdog | I see | 21:18 |
unixbsd | that's all we have.... I look on bsd if I can compile the vi from pcdos. | 21:18 |
unixbsd | kilo would be nice to have, kilo is very well known. | 21:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!