tuxd3v | hello, what should the package to install devua ascii... the default one.. of 'libcurl-dev' ? | 00:21 |
---|---|---|
tuxd3v | libcurl4-openssl-dev 7.52.1-5+deb9u9 | 00:21 |
tuxd3v | libcurl4-gnutls-dev 7.52.1-5+deb9u9 | 00:21 |
tuxd3v | based on devuan guidelines? | 00:22 |
debdog | libcurl4-openssl-dev | 00:33 |
tuxd3v | debdog: thanks, I choosed that :) | 00:39 |
tuxd3v | from ascii-backports | 00:39 |
debdog | backports *shiver* ;) | 00:40 |
tuxd3v | actually; I am searching for newer versions of gcc in the ARM port, but only found 6.3 | 00:41 |
tuxd3v | arm64 | 00:41 |
tuxd3v | I was expecting gcc 8.3 | 00:42 |
debdog | heehee | 00:42 |
tuxd3v | there are a big jump in support from 6.3 to 8.3 or even 9.1 | 00:43 |
tuxd3v | but 9.X has better mips32r5 support, apart from arm | 00:43 |
tuxd3v | I will stay with 6.3 for now :) | 00:43 |
yeti | pic32? | 00:43 |
debdog | *thumpsup* | 00:44 |
debdog | b | 00:44 |
yeti | *thumpsub* ok | 00:44 |
tuxd3v | yeti: no its for MIPS32 Release 5( Warrior class ) | 00:45 |
yeti | ok | 00:45 |
tuxd3v | they differ, mips32r5 is a Aplication processor that runs bigger OSes | 00:45 |
tuxd3v | it also has SIMD( SMA ), similar like armv8 | 00:46 |
tuxd3v | but a cleaner SIMD implementation | 00:46 |
tuxd3v | anyway, I am for arm64 now :) | 00:46 |
* debdog passes out o/ | 00:46 | |
yeti | _o/" | 00:46 |
tuxd3v | but yeah I do have pic32 too :) | 00:46 |
tuxd3v | several, to be honest :) | 00:47 |
* tuxd3v debdog: o/ | 00:47 | |
yeti | I got some to play with retrobsd but meanwhile I cannot get the toolchain compiled so that got stuck | 00:47 |
yeti | maybe the PIC32M micropython port will get interesting someday | 00:48 |
tuxd3v | yeah, the amount of headaches we have to take to enjoy our beloved juice :) | 00:48 |
yeti | retrobsd is very picky about the gcc version needed to build it and new gccs can't built that onls 4.8-ish one any more | 00:49 |
tuxd3v | I will try retrobsd on them some day.. | 00:49 |
yeti | onls->old | 00:49 |
yeti | same sh*t with propellergcc (4.6-ish sibling) | 00:50 |
tuxd3v | yeah I heard of it.. unfortunatly, I believe I saw a 5.3 version or so, but yeah around the 4.x series :( | 00:50 |
yeti | the official one stil is the 4.6ish | 00:51 |
yeti | there is a 6.y-ish one which doesnt build on arm | 00:51 |
yeti | but that's unofficial and unfinished | 00:51 |
tuxd3v | I didn't kew.. | 00:51 |
yeti | and now with prop2 $they just wait fpr the community to fix that mess | 00:52 |
tuxd3v | Actually I still need to aquire some force that moovs me into that.. but it would be nice I think.. | 00:52 |
yeti | that's why I'll probably ditch parallax stuff | 00:52 |
yeti | just keeping in touch with the hive | 00:52 |
yeti | propeller1 | 00:53 |
yeti | https://hive-project.de/ | 00:53 |
yeti | maybe when fat FPGAs wit foss toolchains are big enough to model a P2, I'll play with them | 00:54 |
yeti | but not earlier | 00:54 |
yeti | we need te fpgas to get self hosting | 00:55 |
yeti | depending on some legacy oses to being able to run some toolchains feels so unhealthy | 00:56 |
yeti | every system should be self-hosting... even if a rebuild takes a week to compile | 00:56 |
yeti | faster shortcuts ok... but fpr worst case, self hosting is the best option | 00:57 |
yeti | typing make fetch instead of git fetch... need soime ZZZzzzz...... too | 01:03 |
yeti | _o/" | 01:03 |
tuxd3v | yeit: I agree with you, a lot of work is needed, to standardize everything and make it self-hosting.. | 01:05 |
tuxd3v | yeti: I agree with you, a lot of work is needed, to standardize everything and make it self-hosting.. | 01:06 |
tuxd3v | yeti: bye o/ | 01:06 |
agris | Why is Beowuld not consider 'stable' by Devuan? | 09:31 |
agris | *Beowulf | 09:31 |
gnarface | agris: i think there's some broken polkit stuff still | 11:00 |
gnarface | something related to permissions backends anyway | 11:01 |
agris | gnarface, where can I find the details on this> | 11:01 |
gnarface | bugs.devuan.org, the mailing list, or ask one of the project leads maybe | 11:02 |
gnarface | or just ask any of the people hanging around here who have used it what is still broken | 11:02 |
agris | I meant like a specific bug number | 11:03 |
gnarface | in theory bugs.devuan.org should be the definitive list but i don't think everyone is using it | 11:03 |
agris | but gnarface it's interesting you mention polkit | 11:03 |
gnarface | are you seeing issues with it? | 11:03 |
agris | that's mostly a desktop usage related issue right? | 11:03 |
gnarface | uh, yea | 11:03 |
agris | not server usecase | 11:03 |
gnarface | you could easily avoid using it, yes | 11:03 |
agris | unrelated note but have you ever played around with OpenRC from backports or used the beowulf version? | 11:04 |
gnarface | never touched it, sorry | 11:04 |
agris | k | 11:04 |
gnarface | people around here have though, there has been much discussion about it | 11:05 |
gnarface | probably on the mailing list and in the forum too | 11:05 |
agris | It's interesting the newer version contains that openrc-init binary while the ascii stable version doesn't | 11:06 |
agris | which can be used by the kernel directly | 11:07 |
agris | Will AppArmor be a part of the beowulf base install like it is with debian? | 11:30 |
gnarface | agris: i can't be sure, but it's not on the banned packages list, so i think probably, yes: http://packages.roundr.devuan.org/bannedpackages.txt | 13:14 |
gnarface | agris: the whole point is to leave everything the same except what has to be changed to get rid of of systemd | 13:15 |
gnarface | agris: if it's only part of the debian base install because systemd or something else banned pulls it in, then it wouldn't be, obviously, but you could still get it from the repo | 13:16 |
gnu_srs2 | And clean up all left-over buildd chroots? | 13:57 |
gnu_srs2 | Sorry, wrong channel 8-) | 13:58 |
fsmithred | agris, take a look at this thread: https://lists.dyne.org/lurker/thread/20191109.113406.444a57a8.en.html | 15:35 |
fremmy | HELLO | 19:35 |
* tuxd3v fremmy: hello | 19:56 | |
tuxd3v | hello all, | 20:50 |
tuxd3v | I am crosscompiling from x86 to aarch64 | 20:50 |
tuxd3v | on kernel Makefile: | 20:50 |
tuxd3v | HOSTCFLAGS, HOSTCXXFLAGS, KBUILD_HOSTCFLAGS, KBUILD_HOSTCXXFLAGS flags... should I use -march=armv8-a | 20:52 |
tuxd3v | because the host here is x86.. | 20:52 |
tuxd3v | I am crosscompiling it to aarch64.. | 20:52 |
tuxd3v | I receive a error.. in arm gcc cross-toolchain 8.3 | 20:53 |
tuxd3v | ? | 20:53 |
tuxd3v | scripts/basic/fixdep.c:1:0: error: bad value (armv8-a+simd+crypto+crc) for -march= switch | 20:53 |
tuxd3v | if it was in gcc 6.3 , ok I understood that gcc 6.3 doesn't support simd+crypto, I believe but its in 8.3 :/ | 20:54 |
systemdlete2 | Puzzle? My Ascii VM (not the one for backup, this is a different one) runs logwatch once a day. I don't notice any large installs or updates for the past week or so. I also run a tool I wrote myself which keeps track of growing directories. It seems that /var/cache/apt/archives has been growing steadily for a week or so now, but I don't see any new files in that directory recently. | 21:39 |
systemdlete2 | Also: Why are there files in the directory with "funny" names? E.g. file_1%3a5.30-1+deb9u3_amd64.deb | 21:40 |
* systemdlete2 double checks to make sure this report is accurate... | 21:40 | |
* tuxd3v ^^^^ | 21:47 | |
tuxd3v | :) | 21:48 |
systemdlete2 | seriously, what is up with this? Do you know, tuxd3v? | 21:48 |
tuxd3v | you doublechecked? | 21:52 |
systemdlete2 | Yeah, just to make sure my own script was still working right. It is... though I see it gets different values than df | 21:52 |
systemdlete2 | I've been running this script for over a year now without changes or issues. | 21:53 |
systemdlete2 | I do a call on inode (perl) to get the filesiz value, add it to the rest of the files in a directory. Save the total for each directory. Then compare results day to day. | 21:54 |
systemdlete2 | I use a heuristic to determine if a directory is on a trajectory to unsustainable growth... | 21:54 |
systemdlete2 | Unless perl is lying to me, something isn't quite right. I have 53,000 *.deb files in my apt cache directory. That's easy enough to fix... | 21:55 |
systemdlete2 | But why the "funny" file names? That doesn't make sense. | 21:56 |
tuxd3v | I also have some, | 21:56 |
tuxd3v | 14 in total deb packages | 21:56 |
tuxd3v | in the archive | 21:56 |
systemdlete2 | 14? | 21:57 |
systemdlete2 | not 14,000 | 21:57 |
tuxd3v | majority come from ascii-backports, if not all | 21:57 |
tuxd3v | no, only 14 | 21:58 |
systemdlete2 | Sorry, I have 1338 files | 21:58 |
tuxd3v | root@OnePlus:~# ls -l /var/cache/apt/archives/|grep "%"|wc -l | 21:59 |
tuxd3v | 14 | 21:59 |
systemdlete2 | ok, so my situation is not unique then | 21:59 |
systemdlete2 | dpkg does not work on those packages because the name is "funny" | 22:00 |
tuxd3v | sorry.. I am posting the resolt of a rootfs for a arm device :D | 22:00 |
tuxd3v | I have 180 | 22:00 |
tuxd3v | which is a lot.. | 22:00 |
systemdlete2 | well, 180 or 1338 is not a problem really | 22:00 |
systemdlete2 | the real issue is the total disk space they take up -- after a while, I mean | 22:01 |
systemdlete2 | almost 3GB in my case | 22:01 |
systemdlete2 | (df -ks /var/cache/apt/archives) | 22:01 |
tuxd3v | apt-get clean, solves it for sure :) | 22:03 |
systemdlete2 | Ok, my script's numbers match the df (closely, but not precisely of course) | 22:03 |
systemdlete2 | aha! the deb files have the timestamp from the repo. If I use ls -lc I can see when the inodes were created. | 22:04 |
systemdlete2 | this makes much more sense now | 22:04 |
systemdlete2 | (sorry to bug you all) | 22:04 |
systemdlete2 | (again. *sigh*) | 22:04 |
systemdlete2 | looks like a kernel update? | 22:07 |
systemdlete2 | this system probably needs a reboot anyway, after running out of space on / | 22:10 |
systemdlete2 | (one of many reasons I generally don't like one big fs) | 22:10 |
tuxd3v | don't know about that timestamp.. | 22:10 |
tuxd3v | we had one some weeks ago.. | 22:10 |
systemdlete2 | I could be a bit behind, with all the other stuff I am working on | 22:11 |
systemdlete2 | 4.9.0.6 -> 4.9.0.7 | 22:11 |
systemdlete2 | I'm more curious how apt is able to handle those '*%*' deb files when dpkg complains it can't. I guess apt is using an API rather than calling dpkg directly. | 22:13 |
systemdlete2 | anyway, back later. Thanks | 22:13 |
tuxd3v | don't know, what I know is that kernel 5.4 will be huggeee | 22:22 |
tuxd3v | I am used to compile for arm64, and I complain to myself due to sizes of 12Mb... they 5.4 without a lot of things, goes in more than 17MB | 22:23 |
tuxd3v | crazzyy | 22:23 |
tuxd3v | and there are no support for comporessed images | 22:23 |
tuxd3v | .. | 22:23 |
tuxd3v | comporessed -> compressed | 22:30 |
tuxd3v | in aarch64 | 22:30 |
tuxd3v | the usual images zImage os uImage, are not used in aarch64 | 22:31 |
_abc_ | Hello. There seems to be no cddafs opening way in devuan with thunar as file manager. Is there some non free presumably plugin? Searching by name cdda does not find anything useful. | 22:51 |
_abc_ | thunar claims audio disks are not mountable | 22:51 |
_abc_ | kde used to be able to do this (kde3) | 22:52 |
rrq | "cddafs" is a MacOS thingy isn't it; you'd look for "cddfs" in Linux, and not find that in Devuan either... google says there's something at "SlackBuilds.org" | 22:55 |
rrq | .. or "fuse-cddfs" for netbsd | 22:57 |
rrq | .. or maybe "cdfs" from ubuntu ? (I remember I used cdfs late last millenium) | 23:00 |
rrq | (or some few years ago at least) | 23:01 |
_abc_ | cdfs is not present in packages | 23:02 |
_abc_ | xmms2 plugin cdda exists | 23:02 |
_abc_ | interesting there's cdparanoia which will happily get the cdda tracks but no fs mode access. | 23:21 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!