IRC Logs for #crux-devel Tuesday, 2019-05-14

jaegerjue: if that looks ok to you I'll upload the tarball and bump core/ports00:43
ryuojaeger: what benefits did you think sqlite could provide?00:53
ryuoi was thinking it might make information lookup faster.00:53
ryuo(for pkgutils)00:54
ryuoas is, i have to basically load the text DB into my own structs and write my own queries.00:54
ryuoa relational DB might be more optimized for this work.00:54
jaegerhadn't put a lot of thought into it yet but having sql already there as an ease feature is handy. as far as speed, I doubt it'd make much noticeable difference for everyday usage00:55
ryuoi was thinking of having the library act as an interface to the DB backend, whatever it ends up being.00:55
ryuoit can be arbitrarily extended with more columns too.00:56
ryuoeither way i feel pkgutils' current format is too limited. you literally can't extend it at all.00:56
ryuocan't add fields really.00:56
ryuonot without breaking compatibility.00:57
jaegerthat's why I was considering separate metadata files somewhere00:57
ryuoXATTR is one possibility, but i wouldn't want to make that a requirement.00:57
ryuosqlite... has its own issues.00:58
ryuoit has limitations in how the schema can be modified after creation.00:58
ryuoyou can add but not remove columns, iirc.00:58
ryuomain advantage i see is making queries easier to write.00:59
ryuoit's a bit of a mess cross-referencing data without it.00:59
ryuosqlite would need to move to core if i added it...01:00
ryuois that something we can live with?01:00
ryuoit seems people hate it when packages are added to core.01:01
*** xor29ah has quit IRC01:10
*** xor29ah has joined #crux-devel01:12
Nomiushow far is 3.5?01:29
Nomiusryuo: you already have berkeley db, API is not as "cool" as sqlite, but for simple use might be good enough...01:38
ryuoNomius: ... that's not a relational database and it's lower level. not much point to it. i might as well stick with the existing one.01:59
NomiusI use sqlite for my package manager, I know you're looking for relational, but if your requirements are not too fancy it might worth take a look, I've used berkeley db and gdbm for small projects02:00
ryuoi see.02:01
NomiusMan, that could use a rewrite :-P02:04
ryuoheh... i see no foreign keys.02:04
ryuolet alone primary keys02:04
Nomiustbh, I suck at databases...02:05
NomiusAnd for a package manager it works fast enough02:05
ryuoi didn't specialize in it but i always try to get the maximum benefit. i guess we don't need relational, but it would help with handling some cases of overlap between packages.02:05
ryuomost files can only ever be associated with one package, but directories are shared.02:06
ryuostill, having a mechanic for tracking metadata is a good idea.02:06
ryuowe could use XATTR for optional metadata.02:07
ryuono need to modify the actual master database.02:07
ryuomain issue is we can't extend the existing one for compatibility reasons because fields are not labeled.02:08
ryuoDebian's text file format is far better.02:08
ryuotruth is, sqlite is only a light implementation of a relational DB. it doesn't support some more advanced stuff.02:09
ryuoi'm considering adding a real database and just maintain the old one in parallel in the short term.02:09
ryuoi guess berkeley DB is worth looking at.02:10
ryuowe don't need relational for something this simple i suppose.02:10
NomiusAre you looking at re-writting pkgtools?02:13
ryuoit's not pkgtools. it's called pkgutils.02:23
ryuoand yes, there's some interest in improvements to it.02:24
ryuobut the current source is locked to an application centric design. a library design was one thing that would be beneficial.02:24
ryuoproviding alternatives to the regular interface.02:25
ryuoi hate not having a library for the base line database.02:25
ryuothe idea was to retain compatibility and gradually phase out older parts.02:26
ryuothe text database's only real advantage is compatibility with AWK, but most of that can be done with pkginfo already.02:26
ryuomy thinking is to add some abstractions for reading data from the database02:27
ryuoperfectly doable from C. i have some ideas already.02:28
ryuoi imagine it could be useful for scripts that do custom analysis of the database.02:29
ryuoor something like that.02:29
NomiusI thought suckless used to have a good package manager somewhere, can't find it now02:31
ryuowouldn't cut it i imagine, CRUX has their own database format.02:31
ryuoand has a lot less features.02:31
ryuostill wouldn't hurt to see if there's some minimalist solutions that can be retrofitted.02:37
ryuoslackware's is the closest one...02:39
ryuosimilar design to CRUX.02:39
ryuoeh... no. it's all shell scripts. o.O02:40
Nomiusslackware package tools are a set of scripts, very posix compatible, but stills shell scripts so very unreliable...02:41
ryuoand slow.02:43
ryuothough pkgutils has some inefficient parts as is.02:43
ryuoi found i could cut the runtime of pkginfo's footprint mode in half at the cost of slightly more RAM usage.02:44
ryuoit was making two passes through the tarball when it didn't need to.02:45
ryuoby caching all the information in the first pass that is needed for the footprint02:45
ryuoyou can just analyze that after you have it all.02:45
ryuomuch faster.02:45
NomiusI might try¬°y arch02:57
NomiusAlthough I see pacman complex02:58
jaegersqlite can also be corrupted by reads on very rare occasions, so that makes it suspect03:49
juejaeger: looks ok for me07:58
*** erdic has joined #crux-devel09:18
TimB_Romster: minor fix for contrib/vte3-ng - there is a newer version out but termite fails to build with it for some reason, so I didn't bump that one09:32
Romster0.56.2.a should work TimB_11:05
TimB_Romster: tried it with version 14 and 15, fails to build with some include from vte3-ng11:08
Romsteradd JOBS=j1 make to termite11:09
Romsteradd JOBS=-j1 make to termite11:09
Romsterapparently it has a race issue11:10
TimB_oh, haven't checked that11:10
TimB_doesn't work for me11:13
Romstercan you paste the Pkgfile some where i'll test11:13
TimB_ termite vte3-ng11:14
TimB_thanks :)11:14
TimB_I'll have to get going soon11:14
TimB_will be back in the evening11:15
TimB_ that's my buildlog for termite11:16
TimB_ok, I'll be back later. cya11:19
jueRomster: we talked about that sometimes already, we don't have a policy to remove static libraries from packages, so I'd suggest to leave them alone, at least for opt ports11:42
Romsterwhere have i been removing static libraries in opt?11:50
Romstertim is talking about vte3-ng in contrib and his termite11:51
Romsteri know the policy if opt keep static libs11:51
Romsterand that even has --enable-static set but is in contrib.11:53
Romsterso i am a little confused to what you are referring to11:53
Romsteroh hum maybe you are refering to vte in opt having --disable-static and vte3 i hadn't noticed that. i'll fix those up soon11:55
juewell, for example libcroco, librsvg, libsndfile11:55
Romsteri only recently picked up librsvg, hmm i need ot go though all mine in opt, some used to live in contrib.11:56
Romsteri missed that11:56
jueno worries :)11:56
Romsteri over looked that sorry11:57
*** dlcusa has quit IRC11:58
Romsterpedja dropped maintaining vulkan when i fixed it up without first asking to get vulkan for mpv working again and i ended up making shaderc and i did ask about that awhile ago and got the response needs shaderc, nothing more happend, so i took libiity to make shaderc and i went though a rabbits burrow to get the headers to work with it. so i ended up deciding to commit that than to flyspray the entire thing as i wanted to commit shaderc and i12:02
Romstercouldn't without the other work. pedja got  mad and said i'd do a better job than him, i ignored that pedja then disowned them ports so then i decided well may as well move them to opt then wine can use vkd3d12:02
Romsteri went about the whole thing the wrong way12:02
Romsterand i still feel bad about it.12:03
pedjayou owe me beer for that :)12:03
Romsteri was happy with you maintaining it pedja sorry12:04
pedjait's OK. tbh, makes more sense for it to be in the officail repos, since there are in compat-32 already12:05
Romsteralso noticed you have spirv-tools and i got spirv-headers12:05
Romsterwell i added it to compat-32 if you want in opt if you're not there already i am sure jue would approve and you can maintain it :)12:06
Romsteri don't want to pinch ports, i got more than enough as it is now12:06
Romster/usr/ports/opt/polkit/Pkgfile has --disable-static and php who maintains php :P12:07
pedjaafaik, those can be split, but glslang or something still doesn't use system spirv-*12:07
Romsterdbus-glib whis is frinnst has --disable-static12:08
Romsterthey may need fixing too.12:08
pedjaRomster, opt access ? nah :)12:09
Romsteroh nuts i got spirv-tools in contrib and i moved glslang to opt. is it ok to take spirv-tools to opt too pedja?12:10
pedjaRomster, spirv-tools are the dep for it, afaik?12:11
pedjait being glslang12:11
Romsteryeah it's using internal headers for glslang atm, spirv-tools is a dep for glslang, and spirv-headers is for vkd3d12:13
Romsterit's rather confusing and i don't quite understand all the parts to it but it's working as that.12:13
Romsteri looked at other distros and they are doing that12:14
pedjastill not merged12:14
Romsterah must be soon then12:14
Romster lists spirv-tools they must be eager.12:14
Romstershould i remove that as a dep to glslang for the time being?12:15
pedjaspirv-* is the 'optional, but recommended' dependency, iirc12:15
jueRomster: well, you know php is a different thing ;) that's not a general library, disable-static is necessary to prevent that the extensions are build into the php binary12:15
pedjaRomster, something with validity check of the generated code. yes, it's a mess still :)12:16
Romsterright so php is a specal snowflake for that. kind of gathered it was set for a reason on php.12:16
Romsteri need to move that to opt and the spirv-headers for wine, i am amazed no none made a bug report on this.12:17
ryuomaybe that goes to show how many actually use it?12:19
Romsterwine is a bit exotic, jaeger and myself i am not aware of anyone else really.12:20
ryuooh. thought you meant php.12:20
ryuotruth is, i only see developers or web site admins using it.12:20
Romsterphp has --disable-static for a reason to stop modules being compiled in to php12:20
Romsteri used to use php12:21
ryuowell, seems kinda duh. if you're doing static linkage, that's the only way modules will work.12:21
pedjaRomster, I'd keep spirv-tools as a glslang dependency, building vulkan-examples repo, for instance, requires them. and one of these days glslang will use them too :)12:21
Romsteryeah that's what i gather too pedja so i'll plonk that in opt12:21
*** xor29ah has quit IRC12:22
pedjaas I mentioned before, upstream promised to get its shit together 'real soon' so12:23
ryuoRomster: seems tek_ hasn't said anything on IRC according to my logs since February.12:24
*** xor29ah has joined #crux-devel12:24
Romsterstill don't know why spirv-tools has it's own headers that are nut unified for spirv-headers12:25
Romsterand i had to use a more recent commit on the headers in that12:25
Romstertek_, be about12:26
*** dlcusa has joined #crux-devel12:26
Romsterllvm 8 and clang 8 is out now. last time i bumped llvm/clang tek went off at me so i'll wait this time. i don't see a big rush to move to 8 yet anyways12:26
pedjaleave it for 3.512:27
ryuoi don't get it. tek_ obviously has no time to adequately care for all these ports. so why snap at people who do?12:28
Romsterproper way is flyspray12:32
Romsterand i've fixed all my tickets12:32
ryuo"Works For Me"?12:33
Romsterno lol12:33
Romsteractually bumped and patched12:33
Romsterhexchat and wicd were long outstanding12:34
Romster 4th of November12:36
ryuoRomster has nothing to do. I better fix that.12:36
ryuoACTION files a bunch of tickets.12:36
Romster omg12:37
RomsterI think this got overlooked... maybe for CRUX2.612:37
Romstershould we just close that?12:38
jueryuo: have you seen that ->
*** stenur has joined #crux-devel12:42
ryuojue: yes, what about it?12:45
juewell, is that something you would implement? if not I'll close the ticket12:47
Romsterto be honest i haven't seen that unless it's in -vvv12:47
ryuoi'm not sure what they're trying to do.12:48
ryuoi guess it was related to detecting...12:49
ryuoRPath directories that are already defined at the system level?12:49
ryuosounds like something to ignore more than anything else.12:50
ryuoredundant, not seemingly harmful.12:50
ryuojue: no, not like this, but it raises a point for something to address in my next work on it.12:51
jueok, I'll close the ticket12:51
ryuomight be worth reporting in verbose output.12:51
ryuobut i can't see why it should be treated as an error/warning12:52
Romsterpedja, i'd post you a good beer from australia if that is allowed :D13:02
pedjabtw, I just checked. vkd3d and spirv-tools both compile using spirv-headers-1.4.113:03
pedjadon't know why vkd3d didn't pick up the spirv-tools, thou13:04
Romsteroh because it's usng a internal copy of a newer header files, i copied arch then i had to change commit version because of missing include file.13:08
Romsteri was just looking at that, surely i can just bump spirv-headers newer with that new include and make spirv-tools use system spirv-headers13:08
pedjano, I tried with my spirv-headers port13:09
pedjathe actual release, 1.4.113:09
pedjafor spirv-tools to pick it up, -DSPIRV-Headers_SOURCE_DIR=/usr13:10
Romsterwhere you getting 1.4.1 from?13:12
Romster sdk-
Romster v2019.213:13
Romsteri don't see any sdk on spirv-tools13:13
Romsterack that's vulkan-tools not spirv-tools13:14
RomsterACTION is a little confused.13:18
Romsterah now i get it13:19
pedjasorry about the confusion :)
Romsteryeah i got it, seems i need to add more things in than i had set in spirv-headers13:31
Romsterspir-v.xml looks interesting13:34
Romsterand is needed along with the json files to compile spirv-tools13:36
pedjaspirv-headers Pkgfile I've bben using
Romsterthe last time i looked at this i had to use a newer commmit than even arch was using to include a header file for it to work.13:37
Romsteroh heck so i've just been installing them and ignoring the cmake stuff -_-13:37
Romsteror is that new13:37
pedjano, it's been there for a while :)13:38
Romster i was derpy13:39
Romsterlet me guess you were waiting on 1.4.1 before splitting out the headers :)13:49
Romsterthat i worked around13:50
pedjaworked with 1.3.x something too13:50
pedjaiirc :)13:50
pedjacan't remember, tbh13:52
*** Romster has joined #crux-devel15:40
*** stenur has quit IRC18:03
ryuohm. interesting.21:13
*** stenur has joined #crux-devel23:50

Generated by 2.14.0 by Marius Gedminas - find it at!