IRC Logs for #crux-devel Saturday, 2019-03-16

*** nthwyatt has joined #crux-devel00:39
*** nthwyatt has quit IRC00:47
*** darfo has joined #crux-devel00:47
*** xor29ah has quit IRC02:27
frinnstconfigure: error: the autotools build system has been deprecated in favour of meson and will be removed eventually.02:37
frinnstfun fun, mesa3d 19.0.002:37
frinnstdefer it to 3.5?02:37
frinnstcan still work around with --enable-autotools02:37
frinnstbut meh, why bother?02:38
jaegersure02:38
*** xor29ah has joined #crux-devel02:39
frinnstmeson.build:732:2: ERROR:  Problem encountered: Python (3.x) mako module >= 0.8.0 required to build mesa.02:40
frinnstasdf02:40
frinnsttoo late to fuck around with this02:40
*** uplime has joined #crux-devel07:23
juefrinnst: as usual we should wait on 19.0.1 cause 19.0.0 is called a "development" release09:18
juefrinnst: besides that 19.0.0 builds fine with --enable-autotools, guess we need a a python3-mako port first before we can use meson09:20
jueI'd vote to defer 19.0.0 to 3.509:22
juemeson.build:1239:6: ERROR:  Problem encountered: The Nouveau driver requires rtti. You either need to turn off nouveau or use an LLVM built with LLVM_ENABLE_RTTI.10:15
juewell ... :)10:15
juehere's the Pkgfile -> https://cfe6e54af5350d09.paste.se/10:25
pedjajue, I suggested building llvm/cmake with rtti a while back :)11:23
ryuotranslation: "i tolda so"11:23
pedjait's enabled on pretty much every distribution afaict11:23
pedjaryuo, nah :)11:24
ryuolol11:24
pedjaI hit that issue with one of the dependencies for a application11:24
juepedja: did you create a ticket for that?11:26
juebtw, with autotools mesa builds and _works_ just fine for nouveau ;)11:27
pedjano. I thought that the issue is rare enough, so not worth bothering you guys with it :)11:27
pedjaI just built llvm/cmake myself and moved on11:28
juetsss ...11:28
jue:)11:31
pedjafwiv, it doesn't seem to break anything, so :)11:36
jueRomster: would you mind adding a python3-mako port to opt?11:55
juepedja: could you paste your changes to cmake somewhere, please?12:00
pedjajue, apologies, that was supposed to be 'llvm/clang'. I blame my stupid brain for that :)12:02
jueah, ok12:04
pedjatime to make coffee extra strong this time12:06
ryuojue: question. if i wanted to apply for commit access, would i need to maintain a repo of some ports first? it feels like a waste of time because i already know what i need to do for the most part...12:12
ryuoi've been helping write some of Romster's ports even.12:13
Romsteri can do that jue12:26
Romsterso do we wait for tek or just add rtti to llvm/clang12:27
ryuobetter question. do you have the time to take for tek?12:27
ryuos/take/wait/12:27
jueprobably not, I'll add rtti to at least llvm and send him an info, only for 3.5 oc12:32
Romsterright12:32
ryuojue: when you got a moment i'd appreciate an answer to my question. thanks.12:40
jueryuo: commit access to what?12:43
ryuojue: contrib initially.12:45
ryuopossible others that could use basic upkeep in time.12:45
ryuoi'm only talking ports at present.12:46
ryuofor example i noticed that the compat32 stuff tends to fall behind.12:47
ryuothe main port they are based on.12:47
juesure, no objections from my side, I'm very glad if you will help us :)12:47
ryuoi just have no means to commit basic things myself at present. i'll try the process.12:48
ryuoobviously anything major i should still discuss.12:48
ryuoi have experience from my time with frugalware. i had to discuss things at times.12:48
ryuoi have an idea for some port packaging for the kernel that might be attractive... if it's liked maybe it can be merged to opt, but i'll start it off in contrib.12:49
ryuoi just think some basic packaging for the kernel could help make CRUX more approachable to newbies.12:50
Romsterryuo, i used to package the kernel got lazy just do it manually. it is the crux way.12:50
ryuoto each their own, Romster... the manual way has its own problems.12:51
ryuoi'm not wanting to deprive anyone of that option.12:51
ryuoonly provide a choice.12:51
jueI bet jaeger and frinnst are happy as well to welcome you, we have to wait for one of them because they are familiar with the whole process (git access etc.)12:51
ryuouse a well built hefty kernel? or go with a custom built one?12:52
Romsterjue, i added them ports in 3.4 i'll merge them into 3.5 and fix the footprints12:52
ryuoi aim to support both by allowing the user to specify system specific kernel configs, or a general purpose fallback if one isn't available.12:52
ryuoperhaps even precompiled kernels.12:52
ryuomy idea was to allow the kernel to be upgradeable via the ports system.12:53
ryuobut ofc, only if they've opted into it.12:53
ryuothe crux way should be kept as the default.12:53
ryuocall me lazy, Romster, but i've found i'd rather pay the price of having a full kernel sitting around than custom it for each install. both have their issues.12:55
Romstereach to there own if you can do it elegantly and others accept it.12:58
Romsterusers can use which way they want to go.12:58
ryuoone method is fatter but more practical when you have many deployments.13:00
ryuothe other is slimmer but impractical for scale.13:00
ryuobut, i prefer the first because disk space is rather cheap these days.13:00
ryuoeven in all its bulk, it's not that much in terms of modern disk usage.13:01
juehere's a revised Pkgfile for mesa -> https://9d7a8f268d8d9cec.paste.se/13:01
ryuothough it's a fair point fo embedded Linux.13:01
Romsteri think it more of code path and speed, and latency.13:01
ryuobut crux doesn't target that.13:01
ryuoRomster: well.. extra kernel modules impose no runtime cost afaik. the kernel only loads what it needs.13:02
Romsterthat is true more so built in.13:02
ryuobuiltin stuff takes up memory regardless.13:02
ryuoonly really practical for custom builds.13:03
ryuoso i generally think the main tradeoff is disk space.13:03
ryuoyou have to keep the modules around somewhere in the chance they are used.13:03
ryuoand uncompressed, it's maybe a few hundred megabytes.13:03
Romsterjue, pushed python3-{markupsafe,mako}13:04
ryuoif kmod had compression support enabled, it could be shaved down considerably.13:04
Romsteranything else jue or you got the rest of the change over covered?13:05
jueRomster: thanks, just pushed llvm13:06
Romsteri'll have to do the same for llvm-3213:06
ryuoRomster: i once experimented with using xz instead of gzip for compressing man pages, but it's a terrible idea. xz made no significant difference because manpages aren't big enough.13:06
Romsteri was on that boat ages ago and yeah some conclusion.13:07
ryuoit made a minor difference for kernel modules.13:07
ryuonot much13:07
ryuolike 10M overall.13:07
ryuokernel modules are highly variable in size and tend towards the small size too.13:07
ryuothis feature has been available for years but i only see ARCH using compressed modules.13:08
ryuoon that note, i'll also see if there's an initrd system that could work with CRUX without much hassle.13:08
ryuothere's a serious lack in support for advanced installations that only an initrd can solve.13:09
ryuothe most common one is LUKS for root.13:09
ryuojust something for contrib in the beginning.13:10
Romsterjue, you are also enabling rtti for clang too? should keep them in sync.13:12
juenot yet, but can do that too13:23
juefrinnst: FYI, pushed a first version of mesa 19, build with meson/ninja, to 3.513:25
Romster3.5 is getting a lot of changes13:41
Romsteri am off to bed, i'll bump compat-32/llvm-32 and mesa3d-32 in 3.5 after sleep.13:43
juejaeger: pushed the python changes to packages.opt14:10
juehope that's not too late for the new build you've planned ;)14:11
jaegerjue: it's already done but I don't mind starting another one. It doesn't require any tough work, just time15:07
jaegerAs for ryuo joining contrib, I don't have any particular objection, he's been around a long time15:09
jaegerjue: with the llvm/mesa stuff as well, makes sense to build another bootstrap anyway15:13
jaegerryuo: dracut works well in my experience. Used it recently for ZFS root tests15:23
jaegerbetter-initramfs and mkinitrd both worked but I don't think either of them are active anymore15:23
jaegerRomster, jue: just for clarification, python3-{mako,markupsafe} replace the python-{mako,markupsafe} ports, right? If so, I'll update setup-helper with the same15:28
jaegeralso, should python-setuptools be replaced with python3-setuptools?15:28
pedjagood thing that cuda-10.1 supports gcc8, one less PITA to build15:34
pedjathat just leaves gcc-fortran :)15:36
ryuoindeed.15:37
pedjait's nbd, thou15:39
ryuonbd?15:39
pedjano big deal :)15:39
ryuoInteresting...15:44
ryuohm.15:44
ryuoi may try mmap as an optimization to reading large pkgutils databases into memory.15:44
ryuobut then that's less useful for general purpose code.15:45
ryuobut it would reduce heap fragmentation...15:45
ryuobut it could work because all i'm really doing is copying strings if i build it the usual way... the pkgutils db has no other types at present.15:46
ryuoi could overwrite the newlines in the private mapping with null terminators...15:48
ryuoand only unmap it once the database is unloaded.15:48
ryuoonly drawback is it complicates modifications...15:48
pedjaout of curiosity, would there be any gains if pkgdb is binary, say sqlite, instead of text?15:48
*** onodera has joined #crux-devel15:48
ryuopossibly, but there's little point right now.15:49
pedjawhat would be pros and cons of that?15:49
ryuowell, the data would be more structured, allowing for potentially faster processing. the database engine could be used to facilitate data operations.15:49
ryuoas is, you have to modify the in memory structure by hand and then push it back to disk, effectively overwriting it all.15:50
ryuoeverything is contiguous so you have to move stuff over so to speak to make room, etc.15:51
ryuohonestly, it's a bit of a problem that the on disk format is presorted. if it wasn't, you could just append to it for installing new packaging.15:51
ryuobut, very small benefit in one case.15:52
ryuomost pkg operations are likely upgrades.15:52
ryuowhich is sort of a hybrdi install/remove operation.15:52
pedjaqueries are the most often operations15:52
ryuoi meant in terms of modifications.15:53
pedjaah, right15:53
ryuothere's no issues with queries. they have no side effects.15:53
ryuothe existing format's worst problem isn't that it is text...15:53
ryuoit's that you can't expand it. it's stuck with what it has.15:54
ryuothere's no way to add custom fields.15:54
ryuosqlite is too rigid for my tastes...15:54
ryuoi'd want to advocate for something like apt's text format.15:54
ryuonamed fields, basically.15:55
ryuoallows you to arbitrarily extend it.15:55
ryuocourse, it can't be done without some form of transition tech.15:55
ryuoand even if we had other fields in mind...15:56
ryuowhat would they be?15:56
ryuopkgutils only has its own ideas about how the database is structured.15:56
pedjathat's interesting. I'll have to check how is zypper's package db structured next time I boot opensuse VM :)15:56
ryuoas is, dependencies are tracked in prt-get.15:57
ryuovia special port comments15:57
ryuoas is, it seems like too much work to transition to a new format.15:57
ryuodo you see anyone thinking it's problematic?15:57
ryuoright now the system is split between pkgutils and prt-get.15:58
ryuoyou can design a new format... but you'd also have to transition stuff to it.15:58
ryuothis isn't the early days of CRUX anymore.15:58
pedjaplumbing and porcelain, as Romster said, iirc :)15:58
ryuoso, basically, it's of little use?15:59
ryuoit seems to be the case...15:59
ryuoi can't see any benefit. CRUX has always had a more distributed approach to more complex packaging metadata.15:59
ryuoit's all in the ports tree.15:59
ryuofor auxiliary data15:59
ryuopkgutils is very basic... to expand the database would complicate it...16:00
ryuoif integration was a big deal for CRUX, it'd have been done already.16:00
ryuoi think it's unworkable, unless someone can come up with a reason as to why it should be changed.16:01
ryuoi see no particular benefit. maybe some speed, but that's not worth changing what people are familiar with.16:01
pedjaagreed16:02
ryuoplus it breaks 3rd party tools. i'm making a library to organize access to it, but can't risk breaking anything that bypasses it.16:02
ryuohm.16:03
ryuoi like the idea of mmap, but it seems problematic.. i guess i'll just use the regular heap.16:04
ryuothat's what pkgutils uses in a sense.16:04
pedjadepinst that can install and update/rebuild dependencies as needed would be nice16:05
ryuomixing data from different allocation methods is problematic in C.16:05
ryuowell, i'll look at prt-get later.16:05
ryuobut it'll be awhile.16:05
ryuoi think our core tools are better off using C even if it is more work.16:05
ryuoas is, no one really wants to touch the C++.16:05
pedjaheh16:05
ryuoC may be more approachable.16:05
ryuoplus, it's less prone to unexpected crap.16:06
ryuoC++ has so much automatic behavior it's easy to get screwed by it.16:06
pedjaafaik, Linus is not a fan of it :)16:07
ryuoi sometimes find trying to make classes work correctly an exercise in frustration.16:07
ryuothere's implicit copy constructors that can ruin your day.16:07
ryuoit's no wonder people don't want to mess with it.16:07
ryuoC++ is more nuanced than C.16:07
ryuothere's very little to surprise you.16:08
ryuoonce you learn about its UB at least.16:08
ryuothe biggest UB is probably uninitialized memory.16:08
ryuobasically stack and most heap allocations are uninitialized by default.16:09
ryuoif you try to read from them prior to the first write, you enter UB.16:09
pedjaa friend of mine is learning c#16:09
ryuowhich means your program can literally do anything because the contents are whatever is lying around in RAM.16:09
ryuoWhat about C#? i know it initializes everything to some kind of default value16:10
juejaeger: yes, I've removed python-setuptools with my commit to iso.git16:11
pedjahe works in the Windows shop, so he has to get familiar with it for some major project, iirc16:11
ryuoi generally will assign explicit values to all stack variables and let the compiler optimize away pointless initializers.16:11
ryuosome crap is better left for the compiler to do.16:11
ryuoi find char arrays perhaps the most interesting. they have the most unique ways to initialize them.16:13
ryuochar x[] = "foo";16:13
ryuox will be size 4, and initialized to a copy of foo.16:13
ryuochar x[16] = "foo";16:13
juejaeger: and python3-setuptools was already there16:13
ryuox will be size 16, and initialized to a copy of foo.16:13
juebbl16:14
ryuocan be useful for avoiding an initialize use of strcpy.16:14
ryuoi may try a miniature destructor system in the future...16:15
ryuobasically, embed a function pointer at the start of each struct.16:15
ryuocall it with the pointer to the struct, let it free the memory, and call the "destructors" of any of its nested structs.16:15
ryuobasically a clone of how C++ destructors work.16:16
jaegerjue: ok16:17
ryuoi've consider having pkgutils able to create the root if it doesn't exist... but...16:18
ryuothat seems to be a job better done by auxiliary scripts.16:18
pedjaOSL is supposed to have C-like syntax. i wouldn't know :)16:18
ryuoOSL?16:18
pedjaopen shading language16:18
ryuoOh.16:18
pedjalanguage spec is ~100 pages16:19
ryuoand even if i wanted to implement it, i can't figure out a sane way to "lock" the root before it exists.16:19
ryuohm. i guess i could lock down the common base directory, but that has its own problems.16:20
ryuoeither way, it's a task that's rather complicated to do from C.16:20
ryuoand only a very niche use case: initial creation of a new chroot16:20
ryuoi think it's best left to the bootstrapping scripts to setup the skeletal structure.16:21
ryuohm. interesting.17:16
ryuoi'll probably make a separate repo for the language bindings to this library...17:17
ryuoSWIG is what i plan to use for them.17:17
ryuohm. this seems like a suitable callback system...17:26
ryuo4 arguments...17:26
ryuofirst pass the user's context pointer... then the event type.. and 2 arguments as unions to be "arguments" for the particular event.17:27
juejaeger: forgot to adjust setup-helper, shall I do it or are you already on it?18:14
juejaeger: nm, just saw that you said that18:16
jaegerno worries :)18:19
ryuoi was considering using inline functions... i think i'm not going to bother for now.18:34
ryuoi should profile it after i build it... inlining only makes sense if it's in a performance critical area.18:34
ryuoand there's also the problem that inlining makes some things unavailable at link time.18:35
ryuogiven that this library is more likely to be bottlenecked by IO... cpu optimizations seem premature.18:36
ryuowow. i finally found a use for offsetof.20:55
*** onodera has quit IRC22:32

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!