libera/#devuan/ Friday, 2020-10-16

systemdleteI 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
systemdleteI'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
systemdleteNew directories are created with correct ownership, and seem to reflect correct perms, taking into account the regular user's umask also.00:23
systemdleteI've tried mounting with uid and gid to davfs2 but no help.00:24
systemdleteI should mention, I supposed, that this is on ascii in a VM.00:25
systemdletenvm I figured it out.  Seems you have to set the use_locks to 000: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
systemdleteor maybe I haven't REALLY figured it out.  Maybe this is a kludge only?00:32
tom_workI can't modprobe wireguard because the one provided by stable-backports is failing digital signature check02:43
tom_work# modprobe wireguard02:43
tom_workmodprobe: ERROR: could not insert 'wireguard': Required key not available02:43
gnarfacetom_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
gnarfacei haven't messed with wireguard at all yet03:25
tom_workthe kernel is stable03:27
tom_workthe module came from bpo-stable03:27
gnarfacetom_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
gnarfacethe short version is "economics"03:31
tom_workthe wireguard module was built specifically for 4.19 stable03:31
tom_workand kernel 5.903:31
tom_workwell it's buggy and full of regressions03:31
tom_workisn't it slower and larger too?03:32
tom_workand because it's not stable it's going to be less secure03:32
gnarfacestraw men03:32
gnarfaceyou've surrounded yourself with an army of straw men then surrendered to them03:33
gnarfacenone of it is real without testing03:33
gnarfaceand what i can tell you my testing has born:  backports kernels, firmware, and modules are not intended to be used ala carte03:33
tom_workI've run 5.6 on my workstation03:34
tom_workcan't keep 2 days uptime03:34
gnarfacei'm sorry to hear that but at this point i'm suspecting the issue is self-inflicted03:34
tom_workweird stuff like certain netfilter rules when ipv6 packets flow through them anything else using ipv6 hangs03:34
gnarfacemy 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 versions03:35
gnarfacethere 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 this03:36
gnarfaceif you start mixing and matching stuff all willy-nilly then well, you get what you ask for03:37
gnarfaceyou have to understand that the testing upstream doesn't account for this type of wild version-reshuffling03:38
gnarfaceand frankly there's no money for it here03:38
gnarfaceso that means you're likely testing combinations of modules and kernel versions that were literally never tested together before this03:39
gnarfaceor, well, just reject my advice and continue to suffer.03:40
malikithI'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:
gnarfaceif 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 here03: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
gnarfacehe's already gone though so he will benefit from none of this insight03:46
smaktried beowulf and the amdgpu stack was lacking support03:55
smakgraphics were fine but opencl was the snag..03:56
smakwhich release is closest to 16.04?03:57
gnarfacesmak: 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
gnarfacesmak: (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
gnarfacesmak: (AMD says their cards don't require the firmware but all you get is basic 2d unaccelerated framebuffer support without it)04:06
gnarfacesmak: 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 set04:07
smakyeah 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 well04:09
smaki use the proprietary drivers downloaded from amd after updating repo with non free04:10
beagleburtG'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:
smaki do believe i read the amdgpu stack is self contained for all distros other than redhat tho04:12
fsmithredbeagleburt, run 'apt update' and when it asks, say "yes"04:14
fsmithredor apt-get --some-option-I-can't-remember update04:14
gnarfacesmak: 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
smaki thought get was depreciated04:15
gnarfacesmak: you seem to be carrying TWO pieces of harmful misinformation in your head then04:15
smakhrmm so if i venture another go you suggest just amdgpu-pro and the mesa opencl repo?04:16
fsmithred --allow-releaseinfo-change04:16
gnarfacesmak: 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 works04:17
smakworth a shot..04:18
gnarfacesmak: in general this is the approach that has worked for other amdgpu users04:18
gnarfacesmak: (and incidentally, nvidia users with 1060's and later, too)04:18
beagleburtfsmithred, tku!  I will try to instruct my (non-computer literate) friend to do those suggestions. BTW: what does 'qq' mean?04:19
gnarfacesmak: unbuntu society diverged, they advise certain procedures that are considered borderline suicidal here04:19
smaki am trying to push for a 3DFX revival, hoping for a new Voodoo card04:19
smakya ubuntu isn't my choice distro using now purely out of necessity to get SOME drivers working04:20
gnarfacesmak: 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 manually04:21
gnarfacesmak: 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 versions04:21
fsmithredqq means I tried to quit while I was in the wrong window. twice04:21
fsmithredjust have friend do apt update and say yes. Easy to remember.04:22
beagleburtfsmithred, ok - t.a. 'b'ye for now04:22
gnarfacesmak: oh, and permissions will be different if you're not familiar with how Ubuntu used to work before systemd04:22
smakare there any plans to diverge from the standard debian release with native zfs installs and the like?04:22
gnarfacesmak: one other gotcha - make sure you're in the "video" group04:22
fsmithredaren't there licensing issues with zfs?04:23
gnarfacesmak: 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 has04:23
gnarfacefsmithred: yes, still, afaik, but that's never been common knowledge because people don't understand how BSD could have it too then :-/04:23
smakwhat permissions need to be formalized? i havent had to actually do anything there since old freebsd audio required a sound group04:24
fsmithredyour answer was better, anyway. We don't want to do any more work than is necessary.04:24
gnarfacesmak: 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
smakgnarface okay thats cool, thanks you have been super helpful.04:25
smakhrmm i havent done anything yet but its a side box not my primary which is running openbsd currently04:25
gnarfacesmak: no problem. here's a debian wiki entry about system groups that should still be mostly relevant
gnarfacesmak: (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
smakya 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 skillset04:26
fsmithredlook in /etc/adduser.conf for EXTRA_GROUPS04:27
gnarfacesmak: 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 Devuan04:27
smakcool i'll check it when i go for a new install04:27
fsmithredyou might want netdev and plugdev04:27
fsmithredI think you'll get most of those groups if you create a user in the installer04:29
gnarfacei'm not sure, i think it depends on the choices04:29
gnarfaceother choices that seem unrelated04:29
fsmithredthat could be04: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 best04:30
smakback in the day getting my 7950 was a task too, fotunately people were much more open about optimizing configurations at that time though04:32
gnarfacedanuan: 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 advice04:32
gnarfacedanuan: (sometimes you might have to make a choice between CUDA working and the rest of the system working)04:33
smakis rage that game with a gorilla on the cd cover? i think i have an unopened copy kicking around04:33
smakwith like 3 copies of leisure suit larry heh04:33
gnarfacegorilla?... hmm, i don't think so... uh04:33
danuani 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
gnarfacesmak: are you thinking of Rampage? hehe, this is the Rage i'm talking about:
smakno i just checked its "primal rage"04:34
gnarfacesmak: 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 anymore04:35
gnarfaceoh shit i'm starting to editorialize now, i guess that means it's time for me to take a break04:35
gnarfacepeace all, i'll be back later04:36
smakcool looks very book of eli.. id made some pretty great games man.04:36
brocashelmgetting 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
brocashelmi can confirm: mesa-va-drivers and mesa-vdpau-drivers are causing segfaults with processes such as mpv17:21
brocashelm(for ceres/unstable)17:21
fsmithredsame version of mpv in chimaera is working17:22
fsmithredhuh. Maybe you should remove those mesa packages. They aren't installed here.17:23
xinomilojust upgraded mesa* to 20.2.1 and mpv still works, but might need to reboot to check for sure17:25
brocashelmit happened the moment i upgraded17:26
brocashelmso i apt held them for the time being17:27
fsmithredwell, I can't install it to test. I just filled up my root parttition.17:27
brocashelmat 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:i38617:29
fsmithredI added the first two mesa libs you mentioned, but they are chimaera versions. Still working ok.17:36
brocashelmstrange. not sure why that happened17:40
fsmithredI have a ceres VM, but it's gonna take some time to upgrade and install some things17:41
xinomilono i386 here, so i guess its arch-specific packages at fault17:58
brocashelmamd64 for me18:32
brocashelmi think i'll just keep those packages on hold for a while until debian package team issues a fix18:33
brocashelmtheir devs have been upgrading builds like crazy lately18:33
oel\join #wpdk118:53
hagbard_forward slash18:55
oelyes ;)18:55
systemdletehow 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> etc20:04
systemdletestdlibc++ wants to install all sorts of x-compile and arch headers.  I don't need/want them all.20:04
fsmithredsystemdlete, this one?  linux-libc-dev: /usr/include/linux/time.h20:11
systemdleteThat's installed.20:11
systemdleteand so is libc6-dev20:11
systemdleteI think I see the problem20:12
systemdleteThere is no link from /usr/include/x86_64-linux-gnu to /usr/include/sys20:12
systemdleteand, no, I don't want the kernel headers, just the userland headers20:13
systemdlete(I have the kernel headers actually)20:13
hagbard_libc6-dev, i think?20:15
systemdleteI've got that one (see above)20:15
fsmithredI have /usr/include/x86_64-linux-gnu/sys/ but no /usr/include/sys20:17
systemdleteSo 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
systemdleteapt should assume that MOST development work will be for the platform the system is running on.20:18
systemdleteEither that, or every unix/linux man(3) page needs serious updating20:18
* systemdlete longs for the days when these things were done for the user and things progressed more or less straight forward...20:19
fsmithredAre you saying that more was done for the user in the past than is done now?20:20
fsmithredI don't know enough to answer your question20:21
systemdleteIf 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
fsmithredand normally it should be found in /usr/include/sys/time.h?20:23
systemdletethe "angle brackets" usually mean to look under /usr/include20:23
fsmithredln -s /usr/include/x86_64-linux-gnu/sys/time.h /usr/include/time.h20:23
fsmithredI dropped a sys20:24
fsmithred /usr/include/sys/time.h at the end20:24
fsmithredbut really20:24
fsmithredlink the whole dir20:24
systemdleteof course.  But I don't remember this "step" when I did development work on linux in the past.20:25
systemdleteI mean, like, 10 years ago maybe, or longer?20:25
fsmithredwas it on something other than debian?20:25
systemdleteprobably.  RH, CentOS... I didn't do much on debian then.  Maybe that's it.20:25
DPAIn my gcc, /usr/include/x86_64-linux-gnu is in the search path, so include will find it:
fsmithredyeah, that would probably make a difference20:25
systemdleteBut what if that path is not in your search path, DPA?20:26
systemdleteWhat 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-compiling20:27
systemdletewhich brings up a question.  Why isn't that path in *MY* gcc search path then?20:28
systemdleteDid I miss a step somehow?20:28
systemdletenvm.  I think we have solved this matter.  Thanks.20:28
systemdleteI'll just make the link, that's all.20:28
DPAThen 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
DPAgcc, I mean.20:31
DPAOh, 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
systemdletesounds like maybe too much dependency?20:38
systemdleteSorry, fsmithred.  I keep forgetting that this is based on debian.  These problems are not the fault of you or devuan really.20:39
systemdleteDidn't mean to be a hot-head about it.20:40
fsmithredI started with redhat and suse, so I feel your pain.20:40
brocashelmi have never installed debian myself20:40
brocashelmi did try lmde briefly, but that was it20:40
brocashelmdevuan is my first proper "debian" install20:40
fsmithredall the downstream distros are contaminated with the same "debian way"20:41
systemdleteActually, 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
systemdleteI 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
systemdleteI 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
fsmithredhow would that be easier?20:44
systemdleteIt 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
fsmithredapt-file find <file>20:44
fsmithredapt-file list <package>20:45
systemdletewell, for instance, with pacapt, I can find files easily.  apt-file is not even installed by default20:45
systemdleteat least not here it wasn't.  I didn't even know it existed.20:45
fsmithreddoes alien do that?20:45
systemdletewhat is "alien"?20:45
fsmithredconverts packages to another type20:45
systemdletenot sure.20:46
fsmithreddeb <-> rpm20:46
systemdletewell, rpm is another beast of great proportions, isn't it?20:46
systemdleteI like yum, though, I admit.20:46
systemdleteI think apt is supposed to be like yum/dng20:46
fsmithredalien [--to-deb] [--to-rpm] [--to-tgz] [--to-slp] [options] file [...]20:47
systemdleteI guess that, as long as I have pacapt, I'll be happy enough.  It does 99% of the stuff I want/need.20:47
fsmithredprobably the other way around (yum is supposed to be like apt)20:47
DHErpm is just the raw tool. it has no dependency fetching capabilities and doens't know what a repo is. yum/dnf is that layer20:47
DHEso I guess it's like dpkg ?20:47
fsmithredrpm -i <package>20:48
systemdletefsmithred:  Yeah, as much as I disliked some aspects of rpm, I do miss the original RH 4 and 5, and later, CentOS20:48
fsmithredno pacman in alien20:48
systemdleteWell, I think you won this round20:49
systemdleteI should be grateful that we have even devuan.20:50
systemdleteI almost gave up on linux altogether, seriously.  I was starting to look at solaris, openindiana20:50
systemdlete(their packaging makes debian look very smart)20:50
fsmithredkolibri FTW!20:55
brocashelmto follow up on my mpv issue earlier, it was hwdec=auto-safe option causing the segfault; works now21:11
unixbsdis there a editor like vi in devuan?21:14
unixbsdthere is no elvis, just only the big, heavy vim.tiny or vim.21:14
debdogelvis-tiny? what version of devuan?21:15
unixbsdapt-get install install elvis gives nothing found on ascii.21:16
fsmithredvim-tiny I think is the default21:16
unixbsdis there something smaller?21:16
fsmithrednano is there21:16
debdogp   elvis-tiny                                                               - Tiny vi compatible editor for the base system21:16
unixbsdvi ?21:16
unixbsdon slackware, there is vi.21:16
unixbsdOn bsd, as well.21:16
fsmithredElvis-tiny is based on a 1991 Minix version of elvis. You should install another vi-editor (such as "vim", "elvis" or21:17
fsmithred "nvi") if you want a vi editor that is full featured and has no bugs.21:17
debdogI see21:18
unixbsdthat's all we have.... I look on bsd if I can compile the vi from pcdos.21:18
unixbsdkilo would be nice to have, kilo is very well known.21:37

Generated by 2.17.0 by Marius Gedminas - find it at!