sfox | Is there a preferred way to install bitcoin-qt on Devuan? | 04:36 |
---|---|---|
gnarface | it's not in the repos? | 04:37 |
gnarface | the preferred way is to install from devuan repos only | 04:37 |
gnarface | the preferred way to install software that isn't from devuan repos is to build it from upstream source | 04:37 |
gnarface | (build+package using dpkg-buildpackage, just like debian) | 04:38 |
gnarface | however, if they have a debian package it might work anyway. just make sure you don't accidentally pull any extra debian versions of packages that are already in devuan; you can risk corrupting your install | 04:39 |
debdog | why go to all that package overhead? just stay inside /usr/local/ for your self compiled software | 04:40 |
gnarface | well, the packages just make everything easier to cleanly uninstall | 04:41 |
gnarface | also they track dependencies and avoid certain collisions | 04:41 |
gnarface | if you just have one thing in /usr/local it probably doesn't matter, but it can quickly become a mess if you have a whole environment of unpackaged stuff in there | 04:42 |
debdog | I know what you're talking about. but there are ways around that even inside local | 04:44 |
debdog | prolly a POV discussion | 04:44 |
debdog | from my POV packages are just another layer I do not like to cope with | 04:46 |
sfox | > it's not in the repos? | 04:48 |
sfox | it's in ceres but not chimaera | 04:48 |
sfox | gnarface, would installing the ceres package in chimaera risk corrupting my install? | 04:49 |
brocashelm | first, check the dependencies. if you can successfully pull them from chimaera, then it usually should be a safe install | 05:35 |
brocashelm | if they can't be met, then you cannot do it in chimaera without breaking things | 05:36 |
brocashelm | you could try moving your repo over to daedalus (it's stabilizing in hard freeze at the moment), since it's still close to ceres | 05:37 |
gnarface | sfox: there's some risk, but less. before you take the risk though make sure it's not in chimaera-backports | 05:50 |
sfox | it's not | 06:20 |
sfox | I ended up just using the generic amd64 build from bitcoin.org | 06:21 |
sfox | seems to work well enough | 06:21 |
sfox | just kludgely that it's in it's own folder instead of the usual binary locations | 06:21 |
sfox | what's to be expected when daedalus stablizes? | 06:22 |
gnarface | what do you mean stabilizes? it's already frozen. very little should change other than bug fixes until release. | 06:30 |
gnarface | i think that may mean your software already is too late to make it into the release, but if there's enough demand they may put it in daedalus-backports | 06:32 |
gnarface | building a package may be easier than it sounds though just fyi | 06:32 |
gnarface | it's harder to find out how than it is to actually do, if the source is already debianized | 06:33 |
gnarface | and if it's not, you can always use checkinstall to make a simple package, as long as it builds clean | 06:34 |
gnarface | i could be wrong about it being too late to get into daedalus though, you could ask that question of debian upstream, someone there would know | 06:44 |
brocashelm | sfox: if you decide to switch to daedalus, it would be a good idea to include ceres and pin ceres to 50 on your apt's preferences.d section | 06:50 |
brocashelm | so that any package that's not available in daedalus that you need from ceres can be installed, like that bitcoin-qt | 06:50 |
brocashelm | daedalus is just about to get another 6.1 kernel upgrade (since ceres has it available now). although it's unlikely it will release at 6.2 at this point | 06:52 |
* Xenguy wonders if anyone still uses 'checkinstall' to create DEBs? | 07:07 | |
Xenguy | Aha, gnarface mentioned it, good | 07:07 |
Xenguy | Used to really enjoy that utility, a long time ago now | 07:08 |
Xenguy | Used it frequently at one point, but not anymore | 07:08 |
sfox | brocashelm, isn't that the kernel with rust in it? | 07:25 |
sfox | Not looking forward to that | 07:25 |
brocashelm | sfox: 6.2 | 07:25 |
brocashelm | AFAIK | 07:25 |
brocashelm | me neither, but it's been a long history of subversion | 07:26 |
sfox | I've already switched most of my servers to FreeBSD | 07:26 |
sfox | Can't do that for laptops and desktops though | 07:26 |
brocashelm | wayland, pipewire, elogind/systemd, etc. are unavoidable at this point | 07:27 |
brocashelm | can't install/use mpv without some dbus, avahi, wayland, pulseaudio "libs" | 07:27 |
brocashelm | so i try to remove as much as i can | 07:27 |
onefang | Big self built packages should go in /opt to keep /usr/local free for smaller things. | 07:30 |
sfox | do we at least get pipewire? | 07:35 |
sfox | onefang, is there a user opt as opposed to a system opt? | 07:35 |
brocashelm | alsa is all i need | 07:35 |
brocashelm | simply removing systemd is not enough to fight against the infection | 07:36 |
onefang | You can put anything you want in your own home directory. I use ~/src for anything I don't want to bother installing outside of my home. | 07:37 |
onefang | I have ALSA and JACK, no pulse, no pipewire. | 07:37 |
brocashelm | gstreamer is another one most people overlook | 07:38 |
brocashelm | have to be careful not to remove its core packages if you're on a gtk system | 07:38 |
Xenguy | Everybody used to use /usr/local before the Man told them to use /opt | 07:40 |
Xenguy | Then they kept using /usr/local anyway = ) | 07:40 |
FatPhil | the description of /opt in the LFS just says "I'm gibbering, ignore me" to me. | 08:54 |
FatPhil | FHS? | 08:55 |
gnarface | FHS | 08:55 |
FatPhil | I'm gibbering, ignore me | 08:55 |
gnarface | i think the distinction is supposed to be that /opt is supposed to be for 3rd party stuff and /usr/local is supposed to be for your in-house stuff | 08:57 |
FatPhil | "Locally installed software must be placed within /usr/local" | 08:59 |
FatPhil | "/opt is reserved for the installation of add-on application software packages." | 09:00 |
FatPhil | The "standard" contradicts itself => it can be safely ignored. | 09:00 |
FatPhil | Also, "must" > "is reserved for" | 09:01 |
rwp | The systemd folks already decided to abandon FHS so all systemd systems ignore it. | 09:10 |
rwp | For a while /opt was where corporate software wanted to be installed. But no one could agree or converge upon a format. | 09:11 |
rwp | So the FHS just said /opt was for "that stuff" and left it flexible by not specifying it. | 09:11 |
rwp | In practice people use or don't use /opt as they feel like it. And that seems to be okay. | 09:12 |
FatPhil | its history certainly is back in the "corporate" era of unix, yeah | 09:12 |
FatPhil | My peave about possible file locations is something debian's suffered from, and thus made me suffer from, for decades. Because /usr might be a remote mount, it mounts all remote mounts before relying on /usr being present. NFS ones fail, as they rely on /usr (which is dumb #1). Init then never goes back and tries again, after /usr is mounted (that's dumb #2). There's even a field in fstab which can give | 09:20 |
FatPhil | this hint - it's just ignored. | 09:20 |
FatPhil | ignoring that field is dumb #3. It's a conurbation of dumb. | 09:21 |
onefang | I tend to put large packages in /opt/$packagename, so they are easier to manage. And sometimes there's more than one copy of a package in there, which is hard to manage in /usr/local. | 09:51 |
brocashelm | the only shit i ever put in /opt was for xampp/lampp data | 10:06 |
brocashelm | that and wine-devel (?) | 10:06 |
ecxod | hat jemand eine Ahnung wie gross chimera ist ? | 13:32 |
buZz | similar size to previous editions | 13:32 |
ecxod | I plan to make a mirror ... | 13:32 |
ecxod | contabo has cheap servers and I need to know how much space is necessarry | 13:33 |
buZz | its similar to https://www.debian.org/mirror/size | 13:33 |
buZz | although i guess a lot smaller? hmm | 13:33 |
buZz | https://ftp.fau.de/devuan/devuan_mirror_walkthrough.txt | 13:34 |
buZz | gee, thats small! | 13:34 |
onefang | You beat me to it. | 13:34 |
buZz | high five onefang | 13:35 |
onefang | It's that small coz most get redirected to Debian mirrors, since we only change a small subset of Debian. | 13:35 |
onefang | If you are setting up a public Devuan package mirror, I'll be the one you talk to, since I'm the package mirror herder. But it's late Friday night here, I'll be switching to weekend mode soon. | 13:37 |
onefang | "here" being Australia. | 13:38 |
ecxod | 400 GB SSD is enough ? | 13:38 |
buZz | is 400 more than 60? | 13:38 |
buZz | is that what you're asking us? | 13:39 |
ecxod | no | 13:39 |
buZz | ecxod: maybe read 13:34:11 < buZz> https://ftp.fau.de/devuan/devuan_mirror_walkthrough.txt | 13:39 |
ecxod | you said devuan is not complete on devuan servers, it is mostly on debian servers | 13:39 |
onefang | That devuan_mirror_walkthrough.txt document will explain a lot. | 13:40 |
buZz | ecxod: have you tried reading the document? :) | 13:41 |
ecxod | i am reading it right now | 13:42 |
ecxod | but in the document are no information about how much traffic is expected, and how much ram is expected | 13:54 |
ecxod | this are important informations | 13:54 |
ecxod | it should be possible to get this informations from other mirrors | 13:55 |
onefang | I can't help much with info from my mirror, it runs virtual worlds as well, so is kinda beefy. | 13:56 |
onefang | Other mirror operators hang out here to, so maybe they can help with that info. | 13:57 |
ecxod | one mirror needs 4,6 terra | 14:01 |
ecxod | there is a package called debmirror | 14:05 |
bb|hcb | ecxod: Current sizes are 134G for ISO and 21G for packages. Note that most of the packages come from Debian, so if you want to have everything locally, you need to mirror Debian too | 21:56 |
bb|hcb | Debian package mirror size is 1.8T now... | 21:57 |
bb|hcb | About traffic - it depends on many things and can not be predicted. In general it is not a good idea to run a mirror on a metered connection/hosting | 21:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!