freenode/#devuan/ Thursday, 2019-10-31

init2winithow 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-arch00:20
init2winitMost of the world's chips and devices are arm, so arm compilation matters00:20
init2winitand the synquacer is the only in order server I could find00:21
init2winitof any architecture00:21
init2winitthis will use less power and be invulnerable to almost all spectre attacks (cache vulns being the exc)00:22
init2winitgnarface, see above re cache vulns00:22
gnarfaceinit2winit: 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 exaggerated00:27
gnarfaceymmv but i was using an old phenom IIx400:27
init2winitmany projects compile arm from may not be perfect, but it seems ppc is particularly bad00:29
gnarfaceinteresting... i wonder why00:30
init2winitquoting my source gnarface "it works much better on cisc, it was basically designed to "emulate other things on x86""00:31
specinginit2winit: it doesen't take much resources to compile a <100 KB binary for cortex-m00:33
specinginit2winit: what does crosscompiling have to do with qemu?00:33
init2winitspecing you constantly choosing to find an argument that makes me wrong is turning me off00:36
specingstop being wrong :)00:36
gnarfaceit'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 guess00:36
init2winitthe cortex-m argument was the straw that broke the camel's back for me00:36
specingI used cortex-m since it is the only ARM compiling Im doing00:37
gnarfacealright guys this is straying far from #devuan specific support.  we can rant in #debianfork00:37
specingI gave up on SoC ARM long time ago00:37
init2winiti will stop answering you from now on...00:37
init2winitgnarface, im actually considering porting to devuan to arm boards or helping in compil...maybe its still OT compared to dev1-arm but yeah00:38
gnarfaceinit2winit: i did it once or twice for a pinebook, so i know some of the steps if you need any insight00:42
gnarfaceinit2winit: (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
init2winitaarch64 : the two are interchangeable...i grep for both00:53
init2winiti think gcc uses aarch64 is what you mean? any other place like kernel/dtb bsp?00:54
gnarfacei meant specifically with gcc, for the environment variables for cross-building the kernel, u-boot, atf and all that00:57
gnarfaceit was a important piece of information curiously omitted from all the documentation i could find00:58
tuxd3vinit2winit: there are two different family compilers01:25
init2winitgnarface did you update the docum? file a bug?01:28
init2winittuxd3v, why you prefer rockpi over rock6401:29
tuxd3vinside each family you have also 2 different compilers, so 4 options..01:30
init2winitgnarface, could you give an idea how long it took to crash course all this to finally running devuan/os on the device?01:31
tuxd3vbut I have them, i could give you the links, I am using the open ARM official toolchains01:32
tuxd3vrock64 is good01:32
init2winitthat 4 is hard to type huh tuxd3v ;)01:32
tuxd3vyou right01:32
tuxd3v2 times..01:33
tuxd3vrockpi4A is also good01:33
init2winittbh 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 correctly01:34
init2winitdoes rockpi not work w panfrost?01:35
init2winitgnarface, was the wireless soldered in the pinebook?01:37
tuxd3vNo, 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
tuxd3vThe driver til mali 450, is the mesa-lima01:39
tuxd3vrock64 is a very used board, it gives you 2 GB RAM for almost 35$, and a big GPIO specs01:40
tuxd3vis also has mmc( flash ) support01:40
tuxd3vits nice01:40
gnarfaceinit2winit: 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
gnarfaceinit2winit: 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 stuff01:42
gnarfaceinit2winit: 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 dtb01:42
init2winittuxd3v, 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.mx8m01:42
tuxd3vinit2winit: 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
tuxd3vI have  a cluster of 4 nanopi fire3 octacore( 32 cores ), still to try to port, but I have a plan :)01:44
tuxd3v1 rockpro64 4GB, 1 rockpi4A 1GB, i orangepi one plus, and 2 raspberrypi's second version01:45
tuxd3vhave some :)01:45
init2winittuxd3v, 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 profit01:45
tuxd3vthe arm laptop, is waiting shipping :)01:45
init2winittuxd3v, ? what you mean have some?01:46
tuxd3vho I forgot, I also own a Olimex lime 201:46
tuxd3vI own some boards, some 10 lets say01:47
tuxd3vbut no rock6401:47
tuxd3vand so on..01:48
init2winitgnarface, just to confirm, 3 days while using a sunxi image, or you actually compiled and ported everything yourself to pinebook?01:49
gnarfaceinit2winit: sorry, maybe i misread your question.  rephrase?01:50
init2winiti thought the sunxi devuan images were replace dtb and dd if of you go...01:50
gnarfaceinit2winit: 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
init2winitive 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 card01:53
gnarfaceyea 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
sedroskencan I use the Wine repository meant originally for Debian?01:55
gnarfacesedrosken: you can, and I do, but i would advise against it anyway01:55
gnarfacesedrosken: (i assume you're talking about winehq-staging, right?)01:55
sedroskenyes 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 packages01:56
gnarfaceinit2winit: and fyi some limit of the hardware i think means you need a different u-boot build for every device01:56
tuxd3vinit2wini: there are several processes, each person use one  final to copy things and make the img..01:57
sedroskenI'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 pid101:57
tuxd3vinit2winit: but generally dtbs,kernel, uboot script goes to /boot01:57
gnarfacesedrosken: well, usually winehq-staging works for me in ceres with ceres' native wine-development dependencies.  usually01:58
tuxd3vinit2winit: kernel headers /usr/include, kernel modules /lib01:58
sedroskenI'm running Buster on my Debian setup, maybe it has new enough packages that the winehq stable builds don't die yet01:58
gnarfacesedrosken: wait.  go back.  the normal debian repos don't have a 32-bit wine build????  since when?01:59
sedroskensince buster at least01:59
tuxd3vyou compile a kernel its headers, and kernel dtb, also you compile uboot, for a specific board01:59
gnarfacecan someone confirm this??01:59
gnarfacesedrosken: sorry i have to double check you on that.  stand by01:59
sedroskenI vaguely remember that being the reason I swapped to the winehq repo for it01:59
sedroskenit's been a few months I could be wrong01:59
sedroskenprobably am wrong by now01:59
init2winityes tuxd3v that seems very standard fhs to me02:00
gnarfacesedrosken: well pkginfo isn't showing them but i think that might just be because pkginfo only searches the amd64 section02:01
sedroskenlike I said, I could be and very well possibly am wrong02:01
init2winitgnarface, is allwinner/pinebook still not in mainline k?02:01
gnarfacesedrosken: i'm still seeing wine32-development and wine64-development in ceres anyway as of the moment02:02
gnarfacesedrosken: i *do* know they've been renaming and restructuring stuff over the past year to try to improve multi-arch support02:02
tuxd3vbut 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 offer02:02
gnarfacesedrosken: (mostly in futility as well)02:02
sedroskennice! so I shouldn't need to use the winehq repos then02:02
tuxd3vbecause allwinner, boot in a way diferent fr5om rockchip02:02
tuxd3vfr5om -> from02:02
sedroskento be clear, I'm working with some... legacy applications not easily replaced that don't behave well in a 64-bit wineprefix02:03
gnarfaceinit2winit: *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
tuxd3vthe 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
gnarfaceinit2winit: and the thing that held the pinebook support back so long was actually mostly just the screen support02:04
tuxd3vgnarface: does you already have one pro laptop?02:05
gnarfacesedrosken: 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
sedroskenas for testing, I'm mostly just checking how it handles encrypted LVM and if that changes when I swap init02:05
gnarfacetuxd3v: no, not yet.  i just have a 14" and one of the limited-run 11" ones with the 1080p screen02:05
sedroskenit *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 distros02:06
tuxd3vI think than the next one will be based in the Allwiner H6, and 3GB RAM@1.8Ghz, but I could be wrong.. :)02:07
gnarfacesedrosken: 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 something02:07
gnarfacesedrosken: CRYPTSETUP something02:07
sedroskenoh yeah I'm prepared for that, that's standard no matter what you use IIRC02:07
golinux"i think that might just be because pkginfo only searches the amd64 section"   WRONG02:07
gnarfacegolinux: sorry, that's not the case?02:08
gnarfacegolinux: should i be seeing wine32 in a search of ceres?02:09
fsmithredif you're searching at pkginfo, no.02:10
init2winitsedroken - 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 me02:10
gnarfacefsmithred: how about if i'm searching with apt-cache search?02:11
fsmithredgolinux, was pkginfo upgraded to do find other arches?02:11
sedroskenmy application works fine in a 32-bit wineprefix no matter what version is selected but yes I can specify different Windows versions02:11
fsmithredTBH, I haven't figured out how to do that. Maybe possible if multiarch is enabled.02:12
gnarfacefsmithred: well, i do have multi-arch enabled, and it does show up for me.02:12
golinuxI think I'm not understanding something.  I'll shut up.02:12
gnarfacefsmithred: but i'm not seeing it on pkginfo... but then i'm not seeing wine64 in pkginfo either....02:12
gnarfacegolinux: i really just thought someone had told me that was the case previously02:13
Jjp137okay steam doesn't show up in pkginfo at all, and we know that's 32-bit only, so it doesn't show i386 packages02:13
Jjp137(there's steam-devices but that's not an exact match)02:13
gnarfaceJjp137: no something else is up, because wine64 isn't showing either now that i'm looking02:13
sedroskenoh, ASCII is only at kernel 4.9? ouch02:13
gnarfacesedrosken: there's a newer one in ascii-backports02:14
sedroskenoh cool02:14
gnarfacesedrosken: (if you get that kernel and you're gaming, you will probably want to get your video drivers/mesa from there too)02:14
sedroskenbecause 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.902:14
sedroskenoh ok good02:15
sedroskenthat works02:15
gnarfacethere's updated mesa and nvidia-drivers in there to accompany it02:15
sedroskennice, 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 distro02:16
gnarfacehmm. i can't tell you what that will mean for mesa, whether you'd want the backported one or not02:16
gnarfacei guess you'd have to just go by trial and error02:16
sedroskenprobably since I'll be using the backported kernel02:16
sedroskento be honest the most intense graphical thing I'll be doing on there is h.264 decoding and maybe playing some Quake III02:17
sedroskenI'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 XFCE02:18
gnarfaceyea i dunno.  i'm honestly starting to consider switching to blackbox for gaming, but it's a real pain in the ass with multiple displays02:19
fsmithredgnarface, I see wine64 for ascii, beowulf and jessie, but not for ceres (at pkginfo)02:20
sedroskenif I were going to go to a bare WM, it'd probably be i3wm02:20
fsmithredI see wine64 and wine32 with apt-cache search02:21
fsmithredoh, I'm just searching jessie here02:22
gnarfacesedrosken: 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 WM02:23
sedroskenthat's why i'd toggle floating, or fullscreen02:23
gnarfacesedrosken: i don't have that problem with blackbox at least, just problems with stuff being placed badly02:23
gnarfaceyea if you know to do that, i think you can get around a lot of the recurring issues02:24
sedroskenbut generally something I install i3wm on isn't going to be something I'm playing games with anyway :P02:24
sedroskenI think it's meta-space by default fyi02:25
sedroskento toggle floating02:25
sedroskenit's been a hot minute since I've used i3 though, I'm pretty rusty02:25
gnarfacei 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 least02:31
sedroskennot something I've ever noticed02:31
gnarfacebut a lot of the games react super badly if you don't until them; black screens, freezes, crashes, etc.02:31
gnarfacei guess i don't even know for sure how much of that is being complicated by mesa or what though02:34
GyrosGeiercan 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
GyrosGeierI have a rather minimal setup anyway14:06
GyrosGeierand I'm already running sysvinit14:06
GyrosGeierbut libvirt people seem to want to use systemd more extensively in the future14:07
GyrosGeierso I'm at a dead end14:07
gnarfaceGyrosGeier: it might work14:17
yetithe 1st pre-ubuntus were transgraded from debian14:18
yetiI tried it and back within few hours14:18
yetiI use "transgrade" for mutating installs between near siblings of distributions14:19
yetiswitching a VPS from suse to debian in 2000(+/-) I didnt dare to do it in place...14:20
tarzeauonly thing keeping me from devuan is their ugly logo and name14:20
GyrosGeierthen again the logot was probably made using free software14:20
tarzeauit's not like one can't make great logos with free software14:21
yetiI debootstrapped a minimal debian on what was use's swap and from tht jumpbar debootstrapped the final debianin the previous suseroot14:21
tarzeaubut you have to try hard to get it like it is now14:21
GyrosGeierI'm ssh'd into a server14:21
yetiI dont care for the names as long as they arent offensive14:21
tarzeauthe kerning before the U and after it is wrong, i'd put together EV (like NASA) anyways the D E combination is super ugly14:22
tarzeauthe color is even worse so14:22
yetitarzeau: that's probably subject to evolve14:22
yetijust talk to the tight ones14:22
yetiRight ones14:23
yetisilly offby1s14:23
yetisometimes they make weird senses14:23
yeti(changed keyboard some days ago)14:24
yetilots of offby1s now14:24
GyrosGeiertell me about it14:24
GyrosGeierI switched to jp layout recently14:24
GyrosGeiernow \ and / are next to each other on the bottom row14:25
GyrosGeierzxcvbnm,.cannot upgrade exactly14:25
GyrosGeieryeti, exactly that's what it's for14:25
GyrosGeierbottom row ends in m , . \ /14:25
GyrosGeierand shift is smaller14:25
DonkeyHoteithere need to be established and supported procedures for transgrading from *buntu to devuan and/or devuan derivatives14:29
DonkeyHoteiat least14:30
yetistart with: 0 - backup14:30
yetias config is kept on remuving (!not purging!) throwing away some big blocks makes sense14:31
yeti1 - backup etc on disk (etc.old ?)14:31
DonkeyHoteiit would certainly be less work than maintaining amprolla repositories for ubuntu as well as debian (which would be ideal)14:31
yetiafter devuan world domination14:32
yetiit's just a matter of (wo)manpower being available14:32
yeti<--- joking... I'm not an "official"!14:33
yetiimplant that idea into debian14:34
yetiubuntu --> debian --> devuan14:34
* GyrosGeier is an idiot14:51
GyrosGeierI thought I had already switched that box to sysvinit14:51
GyrosGeiergoing to Devuan there is harder because it wants to immediately remove the systemd package14:52
GyrosGeierwhich doesn't work before the reboot14:52
GyrosGeierwithin Debian, I can leave the non-init systemd installed for the reboot14:53
GyrosGeierbut I have to wait until I can reboot anyway14:53
GyrosGeier  2 ARC-1231-VOL#01  Raid Set # 01   Raid5   6000.0GB 00/00/01   Checking(86.3%)14:53
GyrosGeierthat will take a few hours still14:54
fsmithredGyrosGeier, migrating from buster to beowulf can be tricky. I haven't tried it lately, but here are some recent accounts:16:35
GyrosGeierseemed to go without a problem16:55
GyrosGeierbut I had to do two steps, first installing sysvinit-core and holding systemd, then rebooting, then finishing up16:56
GyrosGeierI couldn't install elogind before the reboot16:57
nexgenPlease let me know are there any news about approximate Beowulf release date/month/year ?19:05
nexgenat least 2020?19:06
nexgenor even later19:06
nexgenwhat is going after it?19:06
nexgenDevuan to fork all software like OpenBSD ?19:06
nexgenActually I love Devuan so much19:07
nexgenit is super stable19:07
nexgenI did not have such stable installation ever yet19:07
nexgenDevuan Ascii + Linux Libre + ZFS 0.7.1219:08
nexgenThank you very much for your work19:08
* nexgen I guess Oracle Solaris is envious of Devuan stability19:10
IgnoreRelayChatHow to install snapd on ascii?19:23
golinuxIgnoreRelayChat: snapd is a banned package19:42
IgnoreRelayChatgolinux: Thanks. Can you point me towards an explanation to why that is?19:44
IgnoreRelayChat… I could have come to that conclusion myself. sigh. Thanks for your help! It is greatly appreciated.19:47
* yeti will never understand why installing packages needs a demon19:49
yetiis that poetteringstuff too?19:49
golinuxDon't know.  Just know that it is bloatware with a hook to systemd19:51
golinuxAnother part of the "lockin".19:52
GyrosGeiersnapd runs containers20:18
GyrosGeiersystemd has very specific rules on how containers should behave20:18
GyrosGeierthere is a way to do containers without coordinating with systemd, but I think the snap people just went for the systemd API20:19
GyrosGeierso basically "it could be ported, but nobody cares enough"20:20
yetiI'm not running a system with package management to install a different manager atop20:28
* tuxd3v "yeti: I'm not running a system with package management to install a different manager atop"23:47
tuxd3vI run luarocks, separatly :)23:48

Generated by 2.17.0 by Marius Gedminas - find it at!