| init2winit | how are you going to compile for arm on a talos, or on any format that isnt a server? someone who has a talos 2 told me that cross compiling for arm/anything not ppc is about the same benchmark as 200mhz pentium. this is using qemu-tcg, as virtualbox is not available and qemu-kvm does not cross-arch | 00:20 |
|---|---|---|
| init2winit | specing, | 00:20 |
| init2winit | Most of the world's chips and devices are arm, so arm compilation matters | 00:20 |
| init2winit | and the synquacer is the only in order server I could find | 00:21 |
| init2winit | of any architecture | 00:21 |
| init2winit | this will use less power and be invulnerable to almost all spectre attacks (cache vulns being the exc) | 00:22 |
| init2winit | gnarface, see above re cache vulns | 00:22 |
| gnarface | init2winit: not sure about coming from ppc, but for whatever it's worth, i found the reports of a cross-compiling performance hit going from amd64 to aarch64 to be highly exaggerated | 00:27 |
| gnarface | ymmv but i was using an old phenom IIx4 | 00:27 |
| init2winit | many projects compile arm from x64...it may not be perfect, but it seems ppc is particularly bad | 00:29 |
| gnarface | interesting... i wonder why | 00:30 |
| init2winit | quoting my source gnarface "it works much better on cisc, it was basically designed to "emulate other things on x86"" | 00:31 |
| specing | init2winit: it doesen't take much resources to compile a <100 KB binary for cortex-m | 00:33 |
| specing | init2winit: what does crosscompiling have to do with qemu? | 00:33 |
| init2winit | specing you constantly choosing to find an argument that makes me wrong is turning me off | 00:36 |
| specing | stop being wrong :) | 00:36 |
| gnarface | it's what you fall back on if the cross compiler is broken? (as it is from everything before ceres/gcc7 as far as i could tell) just a guess | 00:36 |
| init2winit | the cortex-m argument was the straw that broke the camel's back for me | 00:36 |
| specing | I used cortex-m since it is the only ARM compiling Im doing | 00:37 |
| gnarface | alright guys this is straying far from #devuan specific support. we can rant in #debianfork | 00:37 |
| specing | I gave up on SoC ARM long time ago | 00:37 |
| init2winit | i will stop answering you from now on... | 00:37 |
| init2winit | gnarface, im actually considering porting to devuan to arm boards or helping in compil...maybe its still OT compared to dev1-arm but yeah | 00:38 |
| gnarface | init2winit: i did it once or twice for a pinebook, so i know some of the steps if you need any insight | 00:42 |
| gnarface | init2winit: (the biggest insight i can provide is simply the thing about doing it from ceres; the earlier stock debian cross-compilers were all broken for aarch64 - the second biggest insight is just that it's "aarch64" not "arm64" as would make sense... that wasted a day or two of my time alone) | 00:43 |
| init2winit | aarch64 : the two are interchangeable...i grep for both | 00:53 |
| init2winit | i think gcc uses aarch64 is what you mean? any other place like kernel/dtb bsp? | 00:54 |
| gnarface | i meant specifically with gcc, for the environment variables for cross-building the kernel, u-boot, atf and all that | 00:57 |
| gnarface | it was a important piece of information curiously omitted from all the documentation i could find | 00:58 |
| tuxd3v | init2winit: there are two different family compilers | 01:25 |
| init2winit | gnarface did you update the docum? file a bug? | 01:28 |
| init2winit | tuxd3v, why you prefer rockpi over rock64 | 01:29 |
| tuxd3v | inside each family you have also 2 different compilers, so 4 options.. | 01:30 |
| tuxd3v | aarch32-elf | 01:30 |
| tuxd3v | aarch63-elf | 01:30 |
| tuxd3v | aach32-linux-gnu | 01:31 |
| init2winit | gnarface, could you give an idea how long it took to crash course all this to finally running devuan/os on the device? | 01:31 |
| tuxd3v | aarch6-linux-gnu | 01:31 |
| tuxd3v | but I have them, i could give you the links, I am using the open ARM official toolchains | 01:32 |
| tuxd3v | rock64 is good | 01:32 |
| init2winit | that 4 is hard to type huh tuxd3v ;) | 01:32 |
| tuxd3v | you right | 01:32 |
| tuxd3v | :) | 01:32 |
| tuxd3v | 2 times.. | 01:33 |
| tuxd3v | rockpi4A is also good | 01:33 |
| init2winit | tbh i dont care about 32...someone else will have to take care of that, unless I need it to run a full distro and the repos correctly | 01:34 |
| init2winit | does rockpi not work w panfrost? | 01:35 |
| init2winit | https://forum.pine64.org/showthread.php?tid=7839 | 01:36 |
| init2winit | gnarface, was the wireless soldered in the pinebook? | 01:37 |
| tuxd3v | No, it has a mali 450, but there are a driver also open source for it, in any case you have the proprietary driver.. | 01:39 |
| tuxd3v | The driver til mali 450, is the mesa-lima | 01:39 |
| tuxd3v | rock64 is a very used board, it gives you 2 GB RAM for almost 35$, and a big GPIO specs | 01:40 |
| tuxd3v | is also has mmc( flash ) support | 01:40 |
| tuxd3v | its nice | 01:40 |
| gnarface | init2winit: the bug was well known. the docs were on the debian wiki but clearly written by someone shilling for a 3rd party compiler. so, no. | 01:40 |
| gnarface | init2winit: once i got someone to answer a few key questions, i got it up and running in about 3 days. i could streamline the process probably in just a few minutes over build-time though, and the aarch64 packages in the debian repo more or less work. you only need to build the kernel and the boot stuff | 01:42 |
| gnarface | init2winit: and i believe it has wifi and bluetooth built-in. if you don't want them though, you can always just exclude them from the dtb | 01:42 |
| init2winit | tuxd3v, y not spend 10-20dollars more for 4gb? i think its 44usd for 4gb...thats the main advantage of rockchips they're earlier to reach more ram vs. the h6 allwinner or the i.mx8m | 01:42 |
| tuxd3v | init2winit: the best option would be some one get a diferent board, with a diferent CPU, in that way, everybody would extend devuan support on ARM world.. | 01:43 |
| tuxd3v | I have a cluster of 4 nanopi fire3 octacore( 32 cores ), still to try to port, but I have a plan :) | 01:44 |
| tuxd3v | 1 rockpro64 4GB, 1 rockpi4A 1GB, i orangepi one plus, and 2 raspberrypi's second version | 01:45 |
| tuxd3v | have some :) | 01:45 |
| init2winit | tuxd3v, as much as I want to support all makers, I think the libre community will have more leverage if it zones in on the librest devices and gives them an econ advantage. That way, all manuf will see that libre firmware/datasheets = more profit | 01:45 |
| tuxd3v | the arm laptop, is waiting shipping :) | 01:45 |
| init2winit | tuxd3v, ? what you mean have some? | 01:46 |
| tuxd3v | ho I forgot, I also own a Olimex lime 2 | 01:46 |
| tuxd3v | I own some boards, some 10 lets say | 01:47 |
| tuxd3v | but no rock64 | 01:47 |
| tuxd3v | rpi4 | 01:48 |
| tuxd3v | and so on.. | 01:48 |
| init2winit | gnarface, just to confirm, 3 days while using a sunxi image, or you actually compiled and ported everything yourself to pinebook? | 01:49 |
| gnarface | init2winit: sorry, maybe i misread your question. rephrase? | 01:50 |
| init2winit | i thought the sunxi devuan images were replace dtb and dd if of you go... | 01:50 |
| gnarface | init2winit: oh, sorry: to be clear, 3 days was the time it took me from start to finish to figure out how to build a pinebook image from scratch myself, cross-compiling from my AMD desktop, once i got started. (that it took me 2 weeks to find someone on irc who could tell me the parts the debian wiki omitted about where to actually start was a separate issue) | 01:52 |
| init2winit | ive seen procedures for libreelec say, they tell you to pick the right dtb for your board, place it at the right path in the downloaded image you just untar'ed say, and then i think retar.gz and copy it to a sd or mmc card | 01:53 |
| gnarface | yea it should be that easy if you have a valid dtb, u-boot, and kernel builds. but the dtb for these was still being figured out at the time, and both u-boot and kernel needed unofficial patches. since then, the new dtb and relevant u-boot patches have been mainlined but not the kernel ones. | 01:54 |
| sedrosken | can I use the Wine repository meant originally for Debian? | 01:55 |
| gnarface | sedrosken: you can, and I do, but i would advise against it anyway | 01:55 |
| gnarface | sedrosken: (i assume you're talking about winehq-staging, right?) | 01:55 |
| sedrosken | yes and no, I'd use their stable build because I need i386 wine and on my Debian system the normal repos didn't include 32-bit wine packages | 01:56 |
| gnarface | init2winit: and fyi some limit of the hardware i think means you need a different u-boot build for every device | 01:56 |
| tuxd3v | init2wini: there are several processes, each person use one final to copy things and make the img.. | 01:57 |
| sedrosken | I'm just doing some preliminary sanity checks to see if devuan is right for my setup, gonna kick it around in a vm later and see how feasible it is to swap runit to pid1 | 01:57 |
| tuxd3v | init2winit: but generally dtbs,kernel, uboot script goes to /boot | 01:57 |
| gnarface | sedrosken: well, usually winehq-staging works for me in ceres with ceres' native wine-development dependencies. usually | 01:58 |
| tuxd3v | init2winit: kernel headers /usr/include, kernel modules /lib | 01:58 |
| sedrosken | I'm running Buster on my Debian setup, maybe it has new enough packages that the winehq stable builds don't die yet | 01:58 |
| gnarface | sedrosken: wait. go back. the normal debian repos don't have a 32-bit wine build???? since when? | 01:59 |
| sedrosken | since buster at least | 01:59 |
| tuxd3v | you compile a kernel its headers, and kernel dtb, also you compile uboot, for a specific board | 01:59 |
| gnarface | can someone confirm this?? | 01:59 |
| gnarface | sedrosken: sorry i have to double check you on that. stand by | 01:59 |
| sedrosken | I vaguely remember that being the reason I swapped to the winehq repo for it | 01:59 |
| sedrosken | it's been a few months I could be wrong | 01:59 |
| sedrosken | probably am wrong by now | 01:59 |
| init2winit | yes tuxd3v that seems very standard fhs to me | 02:00 |
| gnarface | sedrosken: well pkginfo isn't showing them but i think that might just be because pkginfo only searches the amd64 section | 02:01 |
| sedrosken | like I said, I could be and very well possibly am wrong | 02:01 |
| init2winit | gnarface, is allwinner/pinebook still not in mainline k? | 02:01 |
| init2winit | ??? | 02:02 |
| gnarface | sedrosken: i'm still seeing wine32-development and wine64-development in ceres anyway as of the moment | 02:02 |
| gnarface | sedrosken: i *do* know they've been renaming and restructuring stuff over the past year to try to improve multi-arch support | 02:02 |
| tuxd3v | but then there are several things that you need to kinow, about the boot process... and here is were I say we should have diferent boards so that we extend the offer | 02:02 |
| gnarface | sedrosken: (mostly in futility as well) | 02:02 |
| sedrosken | nice! so I shouldn't need to use the winehq repos then | 02:02 |
| tuxd3v | because allwinner, boot in a way diferent fr5om rockchip | 02:02 |
| tuxd3v | fr5om -> from | 02:02 |
| sedrosken | to be clear, I'm working with some... legacy applications not easily replaced that don't behave well in a 64-bit wineprefix | 02:03 |
| gnarface | init2winit: *pinebooks* anyway, still not in mainline kernel, correct. maybe all the pine aarch64 stuff, i'm not sure. presumably they had 32-bit stuff though that has been there for a while already. | 02:03 |
| tuxd3v | the boot process is important becasue you need to create partitions acordingly with that, and place the bootloader at specific location in the sdcard, so that in the boot process, CPU will pick it.. | 02:04 |
| gnarface | init2winit: and the thing that held the pinebook support back so long was actually mostly just the screen support | 02:04 |
| tuxd3v | gnarface: does you already have one pro laptop? | 02:05 |
| gnarface | sedrosken: well if they're legacy then that is probably correct. i'm still using winehq-staging for stuff that is distinctly newer. even too new for wine-development (*cough* Blizzard games *cough*) | 02:05 |
| sedrosken | as for testing, I'm mostly just checking how it handles encrypted LVM and if that changes when I swap init | 02:05 |
| gnarface | tuxd3v: no, not yet. i just have a 14" and one of the limited-run 11" ones with the 1080p screen | 02:05 |
| sedrosken | it *shouldn't* but that might not mean that it *doesn't* since I distinctly remember that being a problem a long time ago when most of the init freedom movement was just shoving other stuff in place of systemd on systemd-default distros | 02:06 |
| tuxd3v | I think than the next one will be based in the Allwiner H6, and 3GB RAM@1.8Ghz, but I could be wrong.. :) | 02:07 |
| gnarface | sedrosken: yea i dunno about that. there might be a trick to it. people have run into some gotchas. i vaguely recall something about needing to pass an extra environment variable to GRUB or something | 02:07 |
| gnarface | sedrosken: CRYPTSETUP something | 02:07 |
| sedrosken | oh yeah I'm prepared for that, that's standard no matter what you use IIRC | 02:07 |
| golinux | "i think that might just be because pkginfo only searches the amd64 section" WRONG | 02:07 |
| gnarface | golinux: sorry, that's not the case? | 02:08 |
| golinux | Correct | 02:08 |
| gnarface | golinux: should i be seeing wine32 in a search of ceres? | 02:09 |
| fsmithred | if you're searching at pkginfo, no. | 02:10 |
| init2winit | sedroken - have you managed to use winetricks to switch your default windows to windows vista/7/etc? Also using/installing wine32 and installing dlls/dependancies through winetricks...did the trick for me | 02:10 |
| gnarface | fsmithred: how about if i'm searching with apt-cache search? | 02:11 |
| fsmithred | golinux, was pkginfo upgraded to do find other arches? | 02:11 |
| sedrosken | my application works fine in a 32-bit wineprefix no matter what version is selected but yes I can specify different Windows versions | 02:11 |
| fsmithred | TBH, I haven't figured out how to do that. Maybe possible if multiarch is enabled. | 02:12 |
| gnarface | fsmithred: well, i do have multi-arch enabled, and it does show up for me. | 02:12 |
| golinux | I think I'm not understanding something. I'll shut up. | 02:12 |
| gnarface | fsmithred: but i'm not seeing it on pkginfo... but then i'm not seeing wine64 in pkginfo either.... | 02:12 |
| gnarface | golinux: i really just thought someone had told me that was the case previously | 02:13 |
| Jjp137 | okay steam doesn't show up in pkginfo at all, and we know that's 32-bit only, so it doesn't show i386 packages | 02:13 |
| Jjp137 | (there's steam-devices but that's not an exact match) | 02:13 |
| gnarface | Jjp137: no something else is up, because wine64 isn't showing either now that i'm looking | 02:13 |
| Jjp137 | huh | 02:13 |
| sedrosken | oh, ASCII is only at kernel 4.9? ouch | 02:13 |
| golinux | https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=steam&release=any | 02:13 |
| gnarface | sedrosken: there's a newer one in ascii-backports | 02:14 |
| sedrosken | oh cool | 02:14 |
| gnarface | sedrosken: (if you get that kernel and you're gaming, you will probably want to get your video drivers/mesa from there too) | 02:14 |
| sedrosken | because my laptop has some hardware that doesn't quite need linux-5.2 or whatever's newest now but it does need newer than 4.9 | 02:14 |
| gnarface | 4.19 | 02:15 |
| sedrosken | oh ok good | 02:15 |
| sedrosken | that works | 02:15 |
| gnarface | there's updated mesa and nvidia-drivers in there to accompany it | 02:15 |
| sedrosken | nice, for what that's worth since I'm not going to be using AMDGPU, I'm going to be using radeon since it's an old GCN radeon and it freaks out on resume from suspend with amdgpu in use no matter what distro | 02:16 |
| gnarface | hmm. i can't tell you what that will mean for mesa, whether you'd want the backported one or not | 02:16 |
| gnarface | i guess you'd have to just go by trial and error | 02:16 |
| sedrosken | probably since I'll be using the backported kernel | 02:16 |
| sedrosken | to be honest the most intense graphical thing I'll be doing on there is h.264 decoding and maybe playing some Quake III | 02:17 |
| sedrosken | I'm going to give XFCE another spin since it's honestly my favorite, I've got MATE on the laptop right now and I've bent it to my will but I wonder if I couldn't do it a bit lighter in XFCE | 02:18 |
| gnarface | yea i dunno. i'm honestly starting to consider switching to blackbox for gaming, but it's a real pain in the ass with multiple displays | 02:19 |
| fsmithred | gnarface, I see wine64 for ascii, beowulf and jessie, but not for ceres (at pkginfo) | 02:20 |
| sedrosken | if I were going to go to a bare WM, it'd probably be i3wm | 02:20 |
| fsmithred | I see wine64 and wine32 with apt-cache search | 02:21 |
| fsmithred | oh, I'm just searching jessie here | 02:22 |
| fsmithred | bbiab | 02:22 |
| gnarface | sedrosken: it seems to be worse though, a lot of the games in the wild seem to go crazy when forced to interact with a tiling WM | 02:23 |
| sedrosken | that's why i'd toggle floating, or fullscreen | 02:23 |
| gnarface | sedrosken: i don't have that problem with blackbox at least, just problems with stuff being placed badly | 02:23 |
| gnarface | yea if you know to do that, i think you can get around a lot of the recurring issues | 02:24 |
| sedrosken | but generally something I install i3wm on isn't going to be something I'm playing games with anyway :P | 02:24 |
| sedrosken | I think it's meta-space by default fyi | 02:25 |
| sedrosken | to toggle floating | 02:25 |
| sedrosken | it's been a hot minute since I've used i3 though, I'm pretty rusty | 02:25 |
| gnarface | i don't know much about it first hand, i just remember TwistedFate complaining that the performance hit from untiling in i3wm was so bad that even KDE ran games faster... which is a counter-intuitive outcome to say the least | 02:31 |
| sedrosken | weird | 02:31 |
| sedrosken | not something I've ever noticed | 02:31 |
| gnarface | but a lot of the games react super badly if you don't until them; black screens, freezes, crashes, etc. | 02:31 |
| gnarface | s/until/untile/ | 02:31 |
| gnarface | i guess i don't even know for sure how much of that is being complicated by mesa or what though | 02:34 |
| GyrosGeier | hi | 13:53 |
| GyrosGeier | can I crossgrade an existing Debian installation with sysvinit to Devuan, or do I have to reinstall? | 13:54 |
| HeadlessHorseman | 'crossgrade' usually refers to changing arches, eg going from i386 to amd64. That's more complicated than upgrading from Debian to Devuan, though I'm unsure if there's instructions for how to do it. I know in unstable it's not too complicated to switch from systemd to sysvinit+elogind, so I'd imagine it's something like that. | 13:57 |
| GyrosGeier | I have a rather minimal setup anyway | 14:06 |
| GyrosGeier | and I'm already running sysvinit | 14:06 |
| GyrosGeier | but libvirt people seem to want to use systemd more extensively in the future | 14:07 |
| GyrosGeier | so I'm at a dead end | 14:07 |
| gnarface | GyrosGeier: it might work | 14:17 |
| yeti | the 1st pre-ubuntus were transgraded from debian | 14:18 |
| yeti | I tried it and back within few hours | 14:18 |
| yeti | I use "transgrade" for mutating installs between near siblings of distributions | 14:19 |
| yeti | switching a VPS from suse to debian in 2000(+/-) I didnt dare to do it in place... | 14:20 |
| tarzeau | only thing keeping me from devuan is their ugly logo and name | 14:20 |
| GyrosGeier | then again the logot was probably made using free software | 14:20 |
| tarzeau | it's not like one can't make great logos with free software | 14:21 |
| yeti | I debootstrapped a minimal debian on what was use's swap and from tht jumpbar debootstrapped the final debianin the previous suseroot | 14:21 |
| tarzeau | but you have to try hard to get it like it is now | 14:21 |
| GyrosGeier | mmh | 14:21 |
| GyrosGeier | I'm ssh'd into a server | 14:21 |
| yeti | I dont care for the names as long as they arent offensive | 14:21 |
| tarzeau | the kerning before the U and after it is wrong, i'd put together EV (like NASA) anyways the D E combination is super ugly | 14:22 |
| tarzeau | the color is even worse so | 14:22 |
| yeti | tarzeau: that's probably subject to evolve | 14:22 |
| yeti | just talk to the tight ones | 14:22 |
| yeti | golinux(?) | 14:22 |
| yeti | oops | 14:23 |
| yeti | Right ones | 14:23 |
| yeti | silly offby1s | 14:23 |
| yeti | sometimes they make weird senses | 14:23 |
| yeti | (changed keyboard some days ago) | 14:24 |
| yeti | lots of offby1s now | 14:24 |
| GyrosGeier | tell me about it | 14:24 |
| GyrosGeier | I switched to jp layout recently | 14:24 |
| GyrosGeier | now \ and / are next to each other on the bottom row | 14:25 |
| yeti | \o/ | 14:25 |
| GyrosGeier | zxcvbnm,.cannot upgrade exactly | 14:25 |
| GyrosGeier | erm | 14:25 |
| GyrosGeier | yeti, exactly that's what it's for | 14:25 |
| GyrosGeier | bottom row ends in m , . \ / | 14:25 |
| GyrosGeier | and shift is smaller | 14:25 |
| DonkeyHotei | there need to be established and supported procedures for transgrading from *buntu to devuan and/or devuan derivatives | 14:29 |
| DonkeyHotei | at least | 14:30 |
| yeti | start with: 0 - backup | 14:30 |
| yeti | :-) | 14:30 |
| yeti | as config is kept on remuving (!not purging!) throwing away some big blocks makes sense | 14:31 |
| yeti | 1 - backup etc on disk (etc.old ?) | 14:31 |
| DonkeyHotei | it would certainly be less work than maintaining amprolla repositories for ubuntu as well as debian (which would be ideal) | 14:31 |
| yeti | after devuan world domination | 14:32 |
| yeti | it's just a matter of (wo)manpower being available | 14:32 |
| yeti | <--- joking... I'm not an "official"! | 14:33 |
| yeti | implant that idea into debian | 14:34 |
| yeti | ubuntu --> debian --> devuan | 14:34 |
| yeti | .-D | 14:34 |
| GyrosGeier | meh | 14:51 |
| * GyrosGeier is an idiot | 14:51 | |
| GyrosGeier | I thought I had already switched that box to sysvinit | 14:51 |
| GyrosGeier | going to Devuan there is harder because it wants to immediately remove the systemd package | 14:52 |
| GyrosGeier | which doesn't work before the reboot | 14:52 |
| GyrosGeier | within Debian, I can leave the non-init systemd installed for the reboot | 14:53 |
| GyrosGeier | but I have to wait until I can reboot anyway | 14:53 |
| GyrosGeier | 2 ARC-1231-VOL#01 Raid Set # 01 Raid5 6000.0GB 00/00/01 Checking(86.3%) | 14:53 |
| GyrosGeier | that will take a few hours still | 14:54 |
| fsmithred | GyrosGeier, migrating from buster to beowulf can be tricky. I haven't tried it lately, but here are some recent accounts: | 16:35 |
| fsmithred | https://dev1galaxy.org/viewtopic.php?id=3044 | 16:35 |
| fsmithred | https://lists.dyne.org/lurker/message/20190910.115958.b53645c9.en.html | 16:35 |
| fsmithred | https://lists.dyne.org/lurker/message/20190911.162520.65051441.en.html | 16:35 |
| GyrosGeier | hm | 16:55 |
| GyrosGeier | seemed to go without a problem | 16:55 |
| GyrosGeier | but I had to do two steps, first installing sysvinit-core and holding systemd, then rebooting, then finishing up | 16:56 |
| GyrosGeier | I couldn't install elogind before the reboot | 16:57 |
| nexgen | Hello | 19:05 |
| nexgen | Please let me know are there any news about approximate Beowulf release date/month/year ? | 19:05 |
| nexgen | at least 2020? | 19:06 |
| nexgen | or even later | 19:06 |
| nexgen | what is going after it? | 19:06 |
| nexgen | Devuan to fork all software like OpenBSD ? | 19:06 |
| nexgen | Actually I love Devuan so much | 19:07 |
| nexgen | it is super stable | 19:07 |
| nexgen | I did not have such stable installation ever yet | 19:07 |
| nexgen | Devuan Ascii + Linux Libre + ZFS 0.7.12 | 19:08 |
| nexgen | Thank you very much for your work | 19:08 |
| * nexgen I guess Oracle Solaris is envious of Devuan stability | 19:10 | |
| IgnoreRelayChat | Hi | 19:22 |
| IgnoreRelayChat | How to install snapd on ascii? | 19:23 |
| golinux | IgnoreRelayChat: snapd is a banned package | 19:42 |
| IgnoreRelayChat | golinux: Thanks. Can you point me towards an explanation to why that is? | 19:44 |
| golinux | systemd | 19:46 |
| golinux | https://pkgmaster.devuan.org/bannedpackages.txt | 19:46 |
| IgnoreRelayChat | … I could have come to that conclusion myself. sigh. Thanks for your help! It is greatly appreciated. | 19:47 |
| golinux | YW | 19:47 |
| * yeti will never understand why installing packages needs a demon | 19:49 | |
| yeti | is that poetteringstuff too? | 19:49 |
| golinux | Don't know. Just know that it is bloatware with a hook to systemd | 19:51 |
| golinux | Another part of the "lockin". | 19:52 |
| GyrosGeier | snapd runs containers | 20:18 |
| GyrosGeier | systemd has very specific rules on how containers should behave | 20:18 |
| GyrosGeier | there is a way to do containers without coordinating with systemd, but I think the snap people just went for the systemd API | 20:19 |
| GyrosGeier | so basically "it could be ported, but nobody cares enough" | 20:20 |
| yeti | I'm not running a system with package management to install a different manager atop | 20:28 |
| * tuxd3v "yeti: I'm not running a system with package management to install a different manager atop" | 23:47 | |
| tuxd3v | I run luarocks, separatly :) | 23:48 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!