Nasina has quit [Read error: Connection reset by peer]
Aedil has joined #haiku
<Viking667>
How do I find out what libraries a binary is linked against? ldd doesn't seem to exist here, funnily enough.
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
<Begasus[m]>
g'morning peeps
<Begasus[m]>
Viking667: readelf -d should give you a clue on what libraries a bin is linked to
OscarL has joined #haiku
<OscarL>
Good morning Begasus[m], Viking667.
Aedil has quit [Quit: leaving]
<OscarL>
still sleepy, and haven't booted Haiku yet, Begasus[m].... but have you used readelf/nm on libroot to search for those openpty/forkpty symbols?
<Begasus[m]>
Hola OscarL
<OscarL>
the bpa.st you linked shows that libpython.so have them as UND, so their must be in some library it is linked to.
<Begasus[m]>
checked with lgrep on it OscarL , no hits on openpty/forkpty
<Begasus[m]>
they are mentioned in the python source OscarL
<Begasus[m]>
I used #undef to undefine them, then the linker errors were gone
<Begasus[m]>
25: 0000000000006a00 269 FUNC GLOBAL DEFAULT 12 openpty
<Begasus[m]>
105: 0000000000006a00 269 FUNC GLOBAL DEFAULT 12 openpty
<OscarL>
again... libpython ALREADY links to libbsd...
<Begasus[m]>
yeah I see it
<OscarL>
you can see it by starting python3.10 and then: listimage python3.10 | grep bsd
<OscarL>
it links and loads it just OK.
<OscarL>
problem is on pyqt6' side of things.
<Begasus[m]>
but why do I get this then?
<Begasus[m]>
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/13.3.0/../../../../x86_64-unknown-haiku/bin/ld: /packages/python3.10-3.10.16-1/.self/lib/python3.10/config-3.10/libpython3.10.a(posixmodule.o): in function `os_openpty':
<Begasus[m]>
posixmodule.c:(.text.unlikely+0x5865): undefined reference to `openpty'
<Begasus[m]>
posixmodule.c is from python
<OscarL>
in THAT recipe try forcing -lbsd and/or using -D_DEFAULT_SOURCE, no on the python recipes.
<OscarL>
(because the issue is not on python recipe/package)
<OscarL>
let's start afresh...
<Begasus[m]>
pyqt6 uses sip-build for the build :)
<Begasus[m]>
let's check it ...
<OscarL>
I have beein commenting after seeing this: 15:43 <Begasus[m]> OscarL, if you are awake :-) https://bpa.st/YJUA
<OscarL>
mmm, wrong paste....
<Begasus[m]>
that was the first paste :)
<OscarL>
"that or out libbsd doesn't support them? AC_CHECK_LIB(bsd,openpty, [AC_DEFINE(HAVE_OPENPTY) LIBS="$LIBS -lbsd"]) "
<OscarL>
sorry, got confused, those AC_CHECK_LIBs are from autotools, right? (not cmake)... and I thought that came from pyqt6, as you were having problems with it.
<Begasus[m]>
errr ... short memory :) I think they were from autotools on python
<OscarL>
no, my bad there... seems I missread that too.... "pyqt6 updated here (boost 1.87.0 done earlier) " and THEN you mention the issues with openpty.
<OscarL>
let's back up a bit... with default python3.10 from the repos... what was the original problem you were having?
<Begasus[m]>
yeah, those looked OK, then I started out checking Krita with pyqt6 (wasn't in it before) and got those linker errors
<Begasus[m]>
everything build ok with default python as in pyqt6 was/is(?) fine and packaged OK
<Begasus[m]>
only when I included pyqt6 in krita I got those undefined references
<Begasus[m]>
but krita doesn't use those funtions
<OscarL>
can you get (clean if possible) logs from the linker error from when Krita fails to start?
<Begasus[m]>
well pyqt6 rebuilding atm, will take a bit
<OscarL>
("tail -f /var/syslog", hit enter a couple times, then try starting Krita)
<Begasus[m]>
then I'll do another build for krita
<OscarL>
understood, no rush.
<Begasus[m]>
but could launch krita for the log atm
<OscarL>
FWIW, `python3.10 -c "import os; os.openpty()"` works fine, hinting again that it can see those openpty symbols from libbsd just fine.
<Begasus[m]>
biab
<Begasus[m]>
yeah, checked that yesterday also
<Begasus[m]>
pyqt6 didn't take -D_DEFAULT_SOURCE, rerun ...
<OscarL>
I'm still not sure where the openpty issue comes from.
<OscarL>
how you determined that was the problem? (thus why I asked for logs from when trying to start Krita... to see possible runtime_loader errors regarding those symbols).
<OscarL>
not saying you're wrong... just saying *I* am not seeing the connection yet.
<OscarL>
are there more messages above that "runtime_loader: Cannot open file liblibpython3.10.so.1.0" line?
<Begasus[m]>
Krita builds OK without pyqt6, so including it revealed the error
<OscarL>
...like some missing symbols, or something?
<Begasus[m]>
no, it start with the runtime_loader
<Begasus[m]>
$python -m compileall -d / $prefix/lib/python$pythonVersion (this is used in INSTALL in pyqt6, I guesss it needs an export for -D_DEFAULT_SOURCE also then?
<OscarL>
from the last log you posted... notice that it says it can't find "liblibpython3.10.so.1.0" or "liblibpython3.10", so it tries both. That looks like it is using dlopen() instead of linking to libpython to me.
<Begasus[m]>
mind you, this is an experimental qt6 still :)
<OscarL>
as the libpython.so lib "is fine" (so far at least)....
<Begasus[m]>
k, time for the doggies :)
<OscarL>
the issue *might* be on how dlopen is used? (again, assuming dlopen() is used).
<Viking667>
"The dogs of war, and men of hate..."
<OscarL>
remember the issue with CudaText? the RDL_LAZY vs RLD_ALL (or whatever they were called)?
<OscarL>
neoncortex: about cutemarked... I see from its recipe that the app is marked as "B_SINGLE_LAUNCH". I don't know anything else about said app, but to allow multiple instances, the recipe will need to be changed.
<OscarL>
(or poke Begasus[m] about it when he comes back :-D)
<Viking667>
I'm more wondering what reason "the author(s)" had for making it singleton.
<OscarL>
Viking667: might have just copied a template .rdef.in file, and forgottent o change it to B_MULTIPLE_LAUNCH.
<Viking667>
It's possible.
<OscarL>
flag introduced in 2018. we could blame humdingerb, but he seldomly visits the channel nowadays :-)
<Viking667>
? who was/is flag?
<Viking667>
s/who/who\/what/
<OscarL>
B_SINGLE_LAUNCH in an .rdef.in file for cutemarked's .recipe file.
<Viking667>
ah, right.
<Viking667>
I thought those were referred to as keywords... guess I'm learning something, at least if I remember it several months down the line.
<OscarL>
used at build time to add some "resources" to the cutemarked binary, so the system knows things about it, such as icon, version, supported filetypes, and how it is supposed to be launched (single, mutlple, background, etc)
<Viking667>
I notice that fnc has made it to the HaikuPorts - I also see that libfossil hadn't, when I last checked.
<OscarL>
Viking667: I didn't opened a PR for libfossil because it makes little sense for now.
<OscarL>
(not really needed by any other software)
<OscarL>
and because I would still have to modify my early recipe+patch to remove the bits about fnc from it :-)
<Viking667>
I'd like to suggest that the f-apps are used by the libfossil team, as I may have said yesterday. They're intended to be scriptable front-ends to fossil's functionality.
<Viking667>
By the way, the two fnc codebases have been caught up to each other.
<OscarL>
alright, seee, that's a valid use case for having it :-)
<Viking667>
i.e. they're now identical. the only real reason for fnc is if you don't strictly need f-timeline, f-vdiff, and all the other wonderful little apps that aren't fnc.
<Viking667>
s/reason for fnc/reason for the standalone fnc package/
<OscarL>
will nuke fnc from my libfossil's recipe (was cool having only one recipe for all of it, though :-D)
<Viking667>
well, I'd suggest (instead) that you could run them both. You'd just have to mention conflict
<Viking667>
i.e. you can't install fnc if you have libfossil, and installing libfossil will replace fnc.
<Viking667>
does Haiku have that concept yet?
<Begasus[m]>
does one or the other suppliment it?
<Viking667>
well, fnc from the libfossil package "is" fnc from the fnc package.
<Viking667>
Literally the only difference is how fnc's made. That's it.
<Begasus[m]>
that I knew :)
<Viking667>
I think they've only been correlated yesterday or so.
<Begasus[m]>
there is no internal requirement for the other?
<Viking667>
As you said, fnc comes with its own libfossil, but that's without all the f-apps that come with the libfossil package.
<Begasus[m]>
well, I know already that fnc doesn't need libfossil
<OscarL>
Begasus[m]: fnc statically links to an "all-in-one" libfossil.{c,h}, it doesn't requires libfossil.so.
<Viking667>
^^
<OscarL>
so adding a conflict between fnc and libfossil makes little sense.
<Begasus[m]>
ok, then just do a libfossil package with the f- binaries and leave fnc out of it?
<OscarL>
what would confilct is fnc and the fnc build FROM the libfossil recipe, if we still include it.
<Viking667>
as such, the two fnc binaries are "almost" identical, and are identical in function.
<OscarL>
Begasus[m]: yeah, that's why I would just make as if libfossil didn't knew a thing about fnc.
<Begasus[m]>
or drop fnc recipe and do a one in all package
<Viking667>
That's what I'd possibly suggest
<Viking667>
I found value in having separate packages when one fnc was working properly
<OscarL>
that was my first approach Begasus[m], but the patch was fugly, because I made it againts and older (current?) libfossil "release".
<Viking667>
the other wasnt at that time, at least not for me. Now they're both working, I have no reason to prefer the standalone fnc
<Begasus[m]>
then go with option 1 ;)
<Viking667>
Who's on first?
<Begasus[m]>
err * :P
<Viking667>
fnc's value as a standalone package is for when you don't need any of the f-apps. That's really about it. Some people may want that.
<Begasus[m]>
1 = all-in-one
<Viking667>
Ah, right. I see what you mean now.
<Begasus[m]>
2 = seperate libfossil / fnc
<Viking667>
(with libfossil disincluding fnc)
<OscarL>
to be honest... this fnc/libfossil interbreeding-but-separate-projects feels a bit weird. if they are so intertwined, one would think that just having it the libfossil way would be better.
<Begasus[m]>
well you could split 1 in 2 packages
<Begasus[m]>
PROVIDES_fnc and you have all-in-one* recipe
<Begasus[m]>
but still can install fnc as standalone
<OscarL>
my original recipe already had: libfossil (just the .so), libfossil_devel, libfossil_tools (the f-xxx apps), and "fnc" package from the same recipe.
<Viking667>
It could conceivably be confusing if someone installs the libfossil-with-missing-fnc, expecting that fnc will be part of that package.
<Viking667>
but the PROVIDES_fnc could definitely work, if that works the way I think it does.
<Begasus[m]>
OscarL: checked repology how others package it?
<Viking667>
fossil's a fairly small project - mainly used by the sqlite creators and a zillion other small codebases on chiselapp
<Viking667>
fossil _has_ been used to attempt a .fossil of the NetBSD source code. It was definitely not suitable for a codebase of that size.
<Begasus[m]>
OscarL: fnc requires libfossil in there?
<Viking667>
On our codebases, fnc includes its own libfossil.[ch]
<OscarL>
Begasus[m]: I'm not 100% sure now, was my first attempt. If I re-do it, will double check with readelf to see what needs what.
<Viking667>
and the libfossil code tree has a client/fnc/ with files inside to compile fnc against THAT libfossil.
<OscarL>
"first make it work, then make it better"
<Viking667>
...which reminds me, I must go check out the sqlite recipe.
<OscarL>
nobody sane will install libfossil expecting to find /bin/fnc. that's what the "fnc" package, that provides "cmd:fnc" is for (no matter if from "standalone fnc" or the copy from libfossil).
<Viking667>
well, libfossil includes /whatever/bin/fnc
<OscarL>
in Haiku, you would just do: "pkgman install cmd:fnc" and done.
* Begasus[m]
is going nuts ...
<OscarL>
jeez.
<Viking667>
(assuming you don't compile with --no-fnc)
<Begasus[m]>
lol
<Viking667>
Yeah. It's got confusing.
<Viking667>
I wish I could point Stephan to this chat, but he's far too busy already.
<OscarL>
why the heck those are separate projects again?
<OscarL>
:-)
<Viking667>
he's 2IC on the sqlite project and the fossil project and is lead on the libfossil project.
<Begasus[m]>
will fnc package pick up the f- binaries when they are installed from another package?
<Viking667>
well, fnc as a separate package is good if you have no requirements for any of the f-apps. fnc does not use the f-apps
<OscarL>
fnc as in cmd:fnc from the standalone fnc recipe I mean.
<Viking667>
mmm.
* Begasus[m]
trips over the "if" :)
<Viking667>
if you want the f-apps, you could go with the all-in-one. that way the argument is over.
<Viking667>
I am not sure if you'd honestly not want fnc, but would want the f-apps.
<Viking667>
I find great value in fnc, I use it most of the time I'm outside the web browser.
<Begasus[m]>
but not the f-apps?
<Begasus[m]>
k, cleaning krita-master and starting from scratch ...
<OscarL>
I *could* just not use PACKAGE_NAME_client="fnc" in my libfossil recipe, and add a CONFLICTS to a "libfossil_client" package.
<Viking667>
I have used the f-apps
<OscarL>
that way you either would install libfossil_client OR fnc to get /bin/fnc installed :-)
<Viking667>
(as in, I have them all installed, but I'm aware of the "conflict" between the two fnc.
<Viking667>
hm. That'd work.
<Viking667>
so, libfossil, libfossil_client (though technically, all the f-apps are "clients" that use libfossil.so), and libfossil_devel (and libfossil_source)
<OscarL>
(still make having a separate fnc recipe less appealing, but... oh well)
<Viking667>
well, libfossil_client (if it points to the f-apps) will require libfossil the package.
<OscarL>
libfossil_client won't point to f-apps. f-apps belong to "libfossil_tools".
<Viking667>
fnc doesn't require the libfossil package installed
<Viking667>
so, five packages then.
<Viking667>
libfossil, libfossil_devel, libfossil_source, libfossil_client (for fnc) and libfossil_tools (with the f-apps)
<OscarL>
libfossil_client (or I could name it libfossil_fnc for clarity) would contain that "copy/version" of /bin/fnc
<Viking667>
libfossil_fnc could work well.
<OscarL>
Begasus[m]: re:repology, only AlpineLinux seems to carry libfossil, and they use "--no-fnc", and provide /bin/fnc from its upstream.
<Begasus[m]>
PACKAGE_NAME won't work on buildmasters anyway for now anyway
<Begasus[m]>
right, saw that one from Alpine
<OscarL>
PACKAGE_NAME has been introduced long ago, no?
<OscarL>
what's new is being able to use "." (dots) in package names (that won't work currently).
<Begasus[m]>
does it work on buildmasters? I think jmairboeck only did some changes just recently on it?
<Begasus[m]>
ok, that shouldn't be an issue then
jmairboeck has joined #haiku
<OscarL>
speaking of the devil :-P
<jmairboeck>
Hi Begasus[m], OscarL!
<OscarL>
hello there jmairboeck!
<Begasus[m]>
hi jmairboeck ! :)
<Begasus[m]>
jmairboeck: save us!! :D
<jmairboeck>
PACKAGE_NAME does work on the buildmasters, but the syntax for packageEntries is different before my change
<jmairboeck>
and I removed support for the old syntax in my change because nothing was using it until now
<OscarL>
my tentative recipe was using: "packageEntries client $prefix/bin/fnc $manDir", would that cause problems?
<jmairboeck>
you'd have to use packageEntries "fnc-$portVersion-$REVISION" instead of packageEntries client
<jmairboeck>
but that syntax won't work any more once the new changes are deployed
<OscarL>
ah, alright... let's just forget about using PACKAGE_NAME for this particular recipe then. Can make it better in the future.
<jmairboeck>
or we could revert the removal of the old syntax and support both, I committed that separately
<Begasus[m]>
my thought too, once this is in place on buildmasters we can start using it properly
<OscarL>
do you guys would preffer libfossil_client or libfossil_fnc as name for the package that provides that "copy/version" of /bin/fnc ?
<Begasus[m]>
libfossil_fnc here
<Viking667>
Me personally? I'd say libfossil_fnc too. It makes the meaning a little more obvious.
<Begasus[m]>
+1
<jmairboeck>
+1
<Viking667>
I personally define all of the f-apps as clients of libfossil too, but that's just my personal interpretation.
<OscarL>
we have reached consensus, then.
<Viking667>
What's it called when everyone decides the same thing?
<OscarL>
Viking667: we use the "_tools" suffix extensibly for those cases where there's a lib + commands.
<Begasus[m]>
_tools is a common package name already in many places
<Viking667>
Ah, then that would make sense for f-apps.
<OscarL>
Viking667: libfossil doesn't do "proper" versioned releases, no?
<OscarL>
Begasus[m]: not seeing "tagged" source tarballs for it, so we need to do the equivalent of $srcGitRev... I used "$fossilHash" in my recipe for that reason.
<Viking667>
That's the absolute-freshest version as of this timestamp
<Viking667>
Ah, hang on. I'll look in the fossil for the unversioned file.
<jmairboeck>
OscarL: just to clarify: my recent change in haikuporter was just to support the simpler form of packageEntries and getPackagePrefix when using PACKAGE_NAME and/or PACKAGE_VERSION. The recipe attributes themselves were already supported before, but cumbersome to use because of that.
<OscarL>
jmairboeck: thanks. yeah.... current form is much better. thanks for working on that.
<Viking667>
hm, the unversioned amalgamation file is of no use for you building a recent package.
<Begasus[m]>
mixed it up with fnc download
<OscarL>
Viking667: I know, I didn't downladed the .zip file... I just used that same hash.
<Viking667>
yes, fnc has standalone downloads.
<Viking667>
but those tend to get updated on an ad-hoc basis.
<OscarL>
and the new build is with "stock" python from repos, right?
<Begasus[m]>
local build one
<Begasus[m]>
"/boot/system/apps/Krita/lib/krita-python-libs/PyKrita/krita.so" has no json! (from Terminal launch)
<Begasus[m]>
not sure if it's related
<Begasus[m]>
this one "doesn't" use system layout :P
<OscarL>
that locally build python is not using the "#undef HAVE_OPENPTY" patch, right?
<OscarL>
is kritapykrita.so loaded with dlopen()?
<Begasus[m]>
right
<Begasus[m]>
how do I check that?
<OscarL>
grep the sources, I'm affraid.
<jmairboeck>
and does that link to libbsd.so?
<OscarL>
"dlopen("
<Begasus[m]>
readelf -d shows libbsd jmairboeck (on libpython*)
<Begasus[m]>
but used -D_DEFAULT_SOURCE in python's recipe, so I guess a change there is needed OscarL ? as I'm not getting the undefined reference now?
<jmairboeck>
ok, and PyQt6?
<OscarL>
Begasus[m]: if you see any dlopen call use RTLD_LAZY, that might be the problem. RTDL_NOW might be needed, as was the case with CudaText.
<jmairboeck>
because I think I saw something about libpython3.10.a in your logs earlier, so that wouldn't link libpython.so then
<jmairboeck>
if it is using a static libpython, then it must link libbsd itself
<jmairboeck>
because for the static libpython, no linking is involved at all
<OscarL>
we don't provide static libpython (there's a "/boot/system/lib/python3.10/config-3.10/libpython3.10.a" that I will remove on the next .recipe update, though)
<OscarL>
(leftover from who knows when)
<Begasus[m]>
didn't cross it before also OscarL thought it was a must keep around one :)
<OscarL>
I still have no idea where you got the linking errors related to openpty :-)
<nekobot>
• jmairboeck (259f4224): add portBaseName variable (portName without secondaryArchSuffix)…
<OscarL>
knowing where those appear might help narrow things down
<jmairboeck>
OscarL: I think PyQt6 tried to use that, if I read the logs correctly
<Begasus[m]>
jmairboeck: how does that work if you build a package for both arch's on 32bit?
<Begasus[m]>
you know both pyqt6 and krita are no small projects? :P
<jmairboeck>
also, OscarL, good news for you: there will be a $portBaseName variable soon (not merged yet)
<Begasus[m]>
k, pyqt6 rebuild without changes
<OscarL>
thanks jmairboeck :-) (still think I would have preffered for $portName to just not include the suffix originally, but I guess that boat is long departed :-D)
<jmairboeck>
Begasus[m]: that concrete change is only for "any" packages, although $portBaseName is now provided additionally if you need it.
<Begasus[m]>
ah so it replaces semi broken $portName then?
<jmairboeck>
if you want to call it that, yes
<Begasus[m]>
been long time since I ran into it, and mostly used in python recipes I think? :)
<OscarL>
that "'finddir B_USER_CONFIG_DIRECTORY' failed." is unexpected :-/
<Begasus[m]>
KERN: runtime_loader: Cannot open file liblibpython3.10 (needed by /boot/system/lib/libQt6Core.so.6.8.3): No such file or directory
<Begasus[m]>
why does it use "liblibpython*" (notice double "lib")?
<OscarL>
in any case.... seems to point out to krita (or its plugins) not using the proper PYTHONPATH, as setting it gets rid of most errors, leaving that ""/boot/system/apps/Krita/lib/krita-python-libs/PyKrita/krita.so" has no json!"
<OscarL>
good catch on that liblib.
<Begasus[m]>
well, you told to use $appsDir instead of system paths this week :P
<Begasus[m]>
the build without pyqt6 still launches fine, no output in syslog
<OscarL>
to be able to be of any real help I would need to download krita's, pyqt6's sources, and deps...
<OscarL>
and as HAL 9000 would say: "I'm afraid I can't do that, Dave"
<Begasus[m]>
;)
<Begasus[m]>
maybe there was a reason it wasn't included in the first time :)
<Begasus[m]>
rebuild krita with system layout ...
<Begasus[m]>
also building with KF6 6.12.0 here which is not in the depot
<Begasus[m]>
checking a build on the other laptop for krita from repo with pyqt5
<B2IA>
(UnrealNeil) Butler Catsup
<OscarL>
Begasus[m]: best guess I have... either PyQt6 is missing some, say, .pc file that krita might rely on to find stuff about Python, or krita's plugins themselves have some broken detection of where Python is located. (besides that "has no json! error for krita.so/krita.pyi... no idea about that).
<Begasus[m]>
yeah, about those json I have no clue either
<Begasus[m]>
could ask around in the krita room later if I checked all paths possible to see if it's not an issue on my end
* OscarL
thinks he has a "finished" libfossil recipe.
* OscarL
wishes pkgman didn't downloaded the repo file when installing local files :-(
<OscarL>
I'm paying for those 2 MB now.
<Begasus[m]>
:(
<Begasus[m]>
don't exseed(?) your limit
<OscarL>
will need to remember to unplug the VM in those cases, but then pkgman sometimes freezes :-D
<Begasus[m]>
we can check later and if need be comment on a PR
<OscarL>
after I had "locked up" this PC, if I only do "text stuff" (IRC, basic webpage navigation with no big screenshots, etc), I can do some light stuff during the day, thanksfully. Still need to be careful about unexpected larger downloads :-)
<OscarL>
(still can use the netbook though, as soon as I connect that thing.... it eats all my data, damn windows :-D)
<OscarL>
*still can't use...
<Begasus[m]>
net crawlers :P
<Begasus[m]>
3 laptops running Haiku atm :)
<Begasus[m]>
1 not really up to building large projects, the third one makes a lot of noise (airplane taking off) but at least doesn't crash/shuts down now :)
<OscarL>
`fnc --version`: fnc 0.19 [f477bb5096] 2025-03-26 22:42:49 UTC
<OscarL>
and: /bin/fnc belongs to: libfossil_fnc-2025.04.04-1-x86_64.hpkg"
<OscarL>
good.
<Begasus[m]>
nice! stand-alone or requires libfossil?
<OscarL>
and added custom SUMMARY/DESCRIPTION for some of the sub-packages.
<Begasus[m]>
what does sort -u do?
<Begasus[m]>
+1 :)
<OscarL>
sorts, and removes duplicates.
<OscarL>
equivalent to using: <some command> | uniq | sort
<Begasus[m]>
could be handy for larget lists :)
<phschafft>
em, sort | uniq
<OscarL>
conceptually, I mean. why would one want to sort duplicates?
<phschafft>
because uniq *CANNOT* detech duplicates without sorting first?
<OscarL>
ah, ok, wasn't aware of that.
<OscarL>
guess I had always used uniq last then :-D
<phschafft>
printf "%s\n" a b a | uniq | sort
<phschafft>
vs.
<phschafft>
printf "%s\n" a b a | sort | uniq
<phschafft>
****detect
<OscarL>
thanks for the correction phschafft.
<neoncortex>
OscarL: I see. I will use something else for now.
<OscarL>
neoncortex: if the app is intended to allow multiple instances, then it is a bug on its recipe. and the fix should be pretty easy (if one of the members at HaikuPorts has time to check a build for that change).
r6fej has joined #haiku
<neoncortex>
OscarL: I have no idea if that is the case. I just discovered it in haiku ports.
<neoncortex>
err, haiku depot.
<neoncortex>
ports is from another system xD
<OscarL>
I can't do it myself, as I don't have the proper dependencies installed (and my internet is pretty limited). I'll ask Begasus[m] about it to see if he can check it :-)
<phschafft>
OscarL: oh, didn't want to correct you. just hope we can all lift each other up :)
<Begasus[m]>
which package OscarL neoncortex ?
<neoncortex>
CuteMarkEd.
<OscarL>
phschafft: it was a sincere thanks from my part, phschafft.
<neoncortex>
I'm just starting with this, and I hope to turn self sufficient in the future. I need to revisit C++, and make some programs, and understand that system, and ... It will take time.
<neoncortex>
Begasus[m]: that.
<Begasus[m]>
ok, easy fix, will push to haikuports
<neoncortex>
marvelous =D
* phschafft
wonders what happens if they run at -3GHz.
<OscarL>
(PR opened for libfossil)
<OscarL>
AFAICT, libfossil seems to still assume man pages go under share/man, though.
<Begasus[m]>
bugger, forgot to create a branch ... :)
<OscarL>
(so I just kept the manual moving of man pages to the right place)
<Viking667>
hm. Where _do_ man pages go on a Haiku system?
<Begasus[m]>
jikes, lot's of errors on krita and pyqt5 :P
<Viking667>
OscarL: ah, so a tweak of recipe then.
<OscarL>
or to be technically correct... man pages can be in the places the following command outputs: `findpaths B_FIND_PATH_DOCUMENTATION_DIRECTORY man`
<nekobot>
• threedeyes (8c49eaa1): Iceweasel: implement remote server for cli args, update patchset
<Begasus[m]>
instead of $PREFIX/$MANDIR I think it's using?
<Viking667>
probably.
<OscarL>
Viking667: right, I saw .tcl code and stepped back :-D
<Viking667>
tcl isn't that hard to understand
<OscarL>
using "-c :" with findpaths is great, as it concatenates the different dirs, and you can use it for thing like setting "path" variables: "findpaths -c : B_FIND_PATH_DOCUMENTATION_DIRECTORY man"
<OscarL>
I know, but I'm just way too unfamiliar with it.
<Viking667>
I'll probably head off really soon. Let me know when a libfossil recipe makes it to HaikuPorts
<OscarL>
and my memory stack is getting shorter and shorter :-(
<Begasus[m]>
neoncortex: cutemarked should be ready to update
<Begasus[m]>
tss kiddo :P
<Viking667>
s/ a /; s/recipe/recipes/
<neoncortex>
Begasus[m]: worked like a charm. Thank you so much =D
<Begasus[m]>
np :)
<OscarL>
coffee effect wore off, /me starts "head-banging" but not due to listentening to metal music.
<Begasus[m]>
whoop
<Begasus[m]>
already froze cutemarked :P
<Begasus[m]>
whatch the keyboard OscarL ! :P
<OscarL>
dfasr q34 141 xa
<OscarL>
(too late :-O)
<Begasus[m]>
lol
gouchi has joined #haiku
AlienSoldier has quit [Quit: Vision[]: i've been blurred!]
<Viking667>
If docs go into /boot/system/documentation/man, bin stuff goes into /boot/system/bin, libs into /boot/system/lib, and other stuff into other places? so --prefix=/boot/system won't entirely work?
<OscarL>
prefix works. what doesn't works is assuming "share" exists.
<Begasus[m]>
docs go into */documentation/packages/foo" manpages go to "*/documentations/man" :)
<OscarL>
(same with "include" vs "headers" for example)
<Begasus[m]>
"develop/headers"*
<OscarL>
that, told you I'm half asleep :-). I' better try to sleep some more, lol.
<OscarL>
See you around folks.
OscarL has quit [Quit: zzzZZZzzz]
<Viking667>
Yeah, */share is a slightly more recent Linuxy thing. When I first started, it was /usr/doc, /usr/man and so on.
<Viking667>
So. Can cutemarked run more than one instance, or not?
<Begasus[m]>
afaik /usr/local/share has been around for a while?
<Begasus[m]>
yes
<Viking667>
/usr/local/share has been around since /usr/share was a thing. Might be part of the xdesktop stuff.
<Viking667>
I'm trying not to fall asleep here, but it's nearly midnight. I'm off for now, folks.
<Begasus[m]>
if it would use something like MANDIR=$prefix/share and then for install MANDIR/man/man1 or something I think that should work to change MANDIR in the recipe without tweaking
<Begasus[m]>
cu Viking667
<Begasus[m]>
and thanks!
<Begasus[m]>
afk for a bit too
<Viking667>
's okay, I'm just the intermediary...
<Viking667>
the laugh is: I'm being pointed to as the guy who did all this, when all I am is a messenger.
<Viking667>
I'd have to give credit where credit is due, in this case, OscarL and Begasus[m]
<Viking667>
(I tried acknowledging such in my commit message)
Viking667 has quit [Quit: *sleep, that knits up the ravell'd sleeve of care...*]
gouchi has quit [Quit: Quitte]
BrunoSpr has joined #haiku
dqk_ has joined #haiku
dqk has quit [Ping timeout: 480 seconds]
BrunoSpr has quit [Read error: Connection reset by peer]
mmu_man has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
diver1 has quit [Quit: Leaving.]
wicknix has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
wicknix_ has quit [Ping timeout: 480 seconds]
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
deneel has joined #haiku
Nasina has joined #haiku
FreeFull has joined #haiku
andreaallegri has joined #haiku
andreaallegri has left #haiku [#haiku]
oevl has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
bbjimmy has joined #haiku
wicknix has quit [Ping timeout: 480 seconds]
andreaallegri has joined #haiku
<andreaallegri>
I am not the inventor of haiku, nor of the name ... :)
<andreaallegri>
Andrea Allegri wanted the name openbeos ... :)
<andreaallegri>
but freedom
nipos has left #haiku [Disconnected: Received SIGTERM]
jmairboeck has quit [Quit: Konversation terminated!]
Nasina has joined #haiku
Aedil has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
gouchi has quit [Quit: Quitte]
oevl has joined #haiku
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
mmu_man has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
Viking667 has joined #haiku
<Viking667>
'llo - I'm only here for a very short while
<phschafft>
:)
PetePete has joined #haiku
<PetePete>
hai, all.
<phschafft>
morning
<Viking667>
For a user-installed compile, where do docs (like man pages, text files, READMEs, FAQs et al) go?
<PetePete>
I was wondering about something the other day
<PetePete>
Regarding encryption...
<PetePete>
Puppy Linux uses some mechanism to encrypt what they call a "personl" file (basically it appears to be a persistence file.
<PetePete>
Is there any reason (self proclaimed retard here, btw) Haiku cannot implement this feature?
<phschafft>
can you define '"personal"' a bit more?
* phschafft
offers Viking667 a cookie while he waits for a reply.
<PetePete>
The best I can do is explain how Puppy does it:
<PetePete>
when you boot Puppy, it runs in ram by default (zram boot option) but I'm not sure this is the key, it's just the default behavior. Anyway, while booting, it asks if you would like to load a persistence file. If you hav never created one, you can do so at shutdown (you get asked if you would like to create one, with or without encryption).
<PetePete>
I suppose what I'm really asking is whether or not Haiku can make use of persistence, so that we can encrypt that file, thus bascially providing full system encryption.
<phschafft>
that is basically dumping the user's home into a file on disk?
Nasina has joined #haiku
<PetePete>
I believe that is correct, but in Puppy, it includes installed software.
<phschafft>
ah
<PetePete>
Ubuntu/Mint/MX et al also offer persistence options on their live usbs
<PetePete>
I do not presume to be a big [outside-the-box] thinker... I have just been really trying to figure out a way to make it easy for Haiku to offer full encryption, without having to invest much into the development of such a feature.
Nasina has quit [Read error: Connection reset by peer]
<PetePete>
Like, I wonder if some dev sees the suggestion and thinks, "hey.. that's actually not difficult to achieve" (vs having to rewrite the boot loader and come up with some way to do full disk encryption)
* Viking667
disapparates
Viking667 has quit [Quit: *croak*]
diver1 has quit [Ping timeout: 480 seconds]
<phschafft>
I think one way or another there are two components required: 0) some kind of encryption layer. I very much enjoy how that works with e.g. LUKS on linux. basically, one block device in, one block devices out. B) support to open such a volume early so booting works.
<PetePete>
Yeah. I think Puppy uses GPG or tar
<PetePete>
in fact, I believe it's tar
<PetePete>
and I THINK it just swap out the persistence file like it's a system image of some sort because the system is running in ram
<PetePete>
I also might be a lumatic.
<PetePete>
lunatic, even.
neoncortex has quit [Quit: Vision[]: i've been blurred!]
<PetePete>
And then... I had one more crazy idea... Could a clever Ventoy hack facilitate encryption for Haiku?