* OscarL
thinks https://review.haiku-os.org/c/haiku/+/5575 could be merged. It makes the minimize_all input_server addon actually usable and handy to have. Not too disruptive even, as it is not part of the default images.
Maturi0n_ has quit [Ping timeout: 480 seconds]
KitsunePrefecture has quit [Quit: Vision[]: i've been blurred!]
mmu_man has quit [Ping timeout: 480 seconds]
<zdykstra>
That's a neat one!
<zdykstra>
How goes, Oscar?
raymondmendoza has quit [Quit: leaving]
<OscarL>
Hello zdykstra! Sorry for the delay, was distracted :-)
<OscarL>
All good on my end, hope the same on yours!
<zdykstra>
The snow that came in over night has melted, so maybe spring will start to rear its head
raymondmend has joined #haiku
raymondmend is now known as raymondmendoza
_Dario_ has quit [Quit: Vision[]: i've been blurred!]
kinkinkijkin has quit [Read error: Connection reset by peer]
bbjimmy_64 has joined #haiku
frkazoid333 has joined #haiku
freakazoid332 has quit [Ping timeout: 480 seconds]
raymondmendoza has quit [Quit: Vision[]: i've been blurred!]
Begasus has joined #haiku
<Begasus>
g'morning peeps
<andreasdr[m]>
Good morning Begasus
<Begasus>
Moin andreasdr[m] :)
<Begasus>
OscarL, around?
<OscarL>
Yup
<OscarL>
Good day.
<Begasus>
+1 on unicorn, tested on 32bit also :)
<Begasus>
aloha :)
<OscarL>
Doing a last test on a unicorn variant...
<OscarL>
I've checked the patch for the bindings with upstream... they solved it differently... by just adding the missing ".2" to the lib name, LOL :-D
<OscarL>
and... the trick to avoid rebuilding libunicorn.so when building the bindings? "export LIBUNICORN_PATH=$libDir".... taken from the F***ing README.txt from the bindings/python folder :-D
<OscarL>
Seems reading the docs sometimes helps :-P
<Begasus>
I had that too at one point (it's mentioned in the cmakelist.txt I think) :)
<OscarL>
I wasn't sure about moving it to dev-python, as it seems coupled with unicorn releases (and it uses the same sources for both, albeit not the same dir due to one being "any" and the other "x86" on 32 bits at least).
<OscarL>
Patches should not interfear with each other, and will go away on the next update.
<OscarL>
s/interfear/interfere/ (i guess)
<OscarL>
k, last test on 64 bits to check everything works.
humdinger has joined #haiku
<humdinger>
Merry DST everyone
<OscarL>
Bonjour, moisieur.
<Begasus>
Guten Morgen hehr humdinger :)
<humdinger>
Gude Morge (?)
<Begasus>
Fast :) Goede morgen
<humdinger>
Goede Begasus
<OscarL>
Mmm, guess I should rename "unicorn_bindings" to "unicorn_python", just in case.
<Begasus>
or maybe KISS and leave it as it is atm in 1 recipe? ;)
<OscarL>
re: rename.... nah... that would end with "unicorn_python_python3x" packages, and that woudl be worse.
<Begasus>
no time to test this morning
<OscarL>
Begasus: and suffer again the long build times from the main lib when we need to fix something on the bindings?
<Begasus>
dogschool in a bit (got exams with the youngest) :)
<OscarL>
(if we leave it as one recipe, I mean)
<OscarL>
re: no testing time.... no problem. plenty of things to do :-)
vezhlys has quit [Quit: Leaving]
<Begasus>
texlive wasn't done at the first check (if you mention long build times) :)
<andreasdr[m]>
Hi there Humdinger
<humdinger>
hullo
CPYou has joined #haiku
<OscarL>
Begasus: heh :-D I dont envy you or jmairboeck on that one.
<CPYou>
moin'
<Begasus>
moin CPYou
<Begasus>
k, time to head out, cu later!
<OscarL>
later!
<OscarL>
mmm hp checks the presence of flag.patchset, but it has no idea of which patches where actually applied :-/
<OscarL>
(this precludes safely using the same source dir for multiple recipes I'm finding)
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
Begasus has quit [Ping timeout: 480 seconds]
<OscarL>
(seems we can't do that in any case, due to "work-*/port.recipe"... oh well... I'll move recipes around then)
CPYou has quit [Ping timeout: 480 seconds]
hackkitten has joined #haiku
AlaskanEmily has quit [Remote host closed the connection]
<OscarL>
why ARCHITECTURES="any" and not simply "all" ? isn't "any" specificaly for packages with no arch-specific binaries? (ie, scripts, data, etc, and not for compiled code?)
<OscarL>
or is that library one of those that are header-only?
<OscarL>
welp... it indeed provides "devel:librapidjso" and no "lib:librapidjso", so basically that answers my question :-D
<Begasus>
;)
<Begasus>
any is arch independent and can be used accross archittectures, all means that will build for primara and (or) secondary architectures
<Begasus>
so you can't use gcc2 packages on a 64bit system, the any packages you can
<Begasus>
s/primara/primary/ :)
<OscarL>
yup, I think I just focused too much on the "lib" part of librapidjso, and it using cmd:gcc.... and I thought... how's that not binary specific? then I read the finer details :-P
<Begasus>
Installing Haiku on the other laptop on bare metal, saw there was an empty space of around 360GB (and windows boots into BSOD there), so will see if I can run it on internal hard drive instead of the external now :)
<OscarL>
nice. good luck with that!
<Begasus>
could pottentional speed up some builds (no bottleneck on USB then) :)
<OscarL>
indeed.
<OscarL>
So.... back to that rapidjson recipe... it is actually CMake the one requiring cmd:gcc and not the lib (as it doesn't gets anything compiled).
<OscarL>
it could drop the "cmd:ld" thou.
<OscarL>
(I've just ran "hp rapidjson" with that removed)
<OscarL>
anyway... one less mystery for me :-D
<Begasus>
About 26GB to be installed, this will take a bit longer then a default install :)
<OscarL>
:-). Still faster than a Win98 install I bet (or at least with only one reboot) :-)
<Begasus>
np matt1 , as long as we stay polite and keep religion out :)
<matt1>
ok xD
<matt1>
i am crazy about religion ... but np
<Begasus>
every one is entitled to their own, we need to respect that too (imho)
<matt1>
ok, but under everything there is religion, but i respect you ...
<Begasus>
yep, and you are entitled to your own, just no need to enforce it on others :)
<matt1>
ok, but it was to share interests ... ok, i understand => i need also a religion channel ...
<Begasus>
yep, this is about Haiku and everything related, though small talk is not disalowed :)
<Begasus>
but I'm no op here, just my 2 cents :)
<matt1>
i have to respect you => it is true ...
<Begasus>
cleaning up some administrative states atm, should do that more often :)
<matt1>
cu, cheers ;)
matt1 has left #haiku [#haiku]
<jmairboeck>
Begasus: do you want to have a go at texlive 2023 on 32 bit? I submitted a PR today.
<Begas_VM>
saw it earlier jmairboeck
<Begas_VM>
will have a go at it, maybe not just now but will do :)
<jmairboeck>
you probably have to enable the secondaryArch for icu70 and build that first, I didn't do that
<jmairboeck>
and libxml2
<Begas_VM>
seems I still have icu-57 installed (trying to remove that results in wanting to remove a lot of packages)
<jmairboeck>
icu57 is needed for gcc2 stuff, that one is no problem
<Begas_VM>
ah, ok, then it's no problem
<jmairboeck>
gcc11 things currently use icu66_x86
<Begas_VM>
Trying to clean up my system on the other laptop, long overdue ;)
<jmairboeck>
I hope that my change for libxml2 works correctly (i.e. use icu-57 for gcc2 and icu70 everywhere else)
<Begasus>
k, first icu70, then libxml2
<Begasus>
Don't have to tell you that building Texlive should take some time :)
<jmairboeck>
yes, I have let it run over night :)
<Begasus>
probably icu70 also
<jmairboeck>
that one was not so bad
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
<Begasus>
got way to much installed that isn't used ;)
<Begasus>
jmairboeck, did you check if TeXstudio still works without rebuilding?
<jmairboeck>
I didn't install everything yet, but I suppose it will because it is just calling tex and not linking to anything
<jmairboeck>
I'm currently testing libxml2 on 32 bit
<Begasus>
right
Begasus_32 has joined #haiku
<jmairboeck>
there was actually a typo in the libxml2 recipe, fixed now
<Begasus>
just pulled in the sources before you pushed, what was the typo?
<jmairboeck>
$effectiveTargetArchitecture was missing the last "t"
<Begasus>
got it, thanks
<Begasus>
building icu70 atm
nosycat has joined #haiku
<jmairboeck>
it is a complicated variable name, and it is not helpful that unknown variables expand to nothing in bash
<zdykstra>
Could be helpful to add a shellcheck check to recipes
<Begasus>
even the simple ones can cause typos :)
<zdykstra>
Though shellcheck might be impossible to build on Haiku
<Begasus>
those variables could slip through (if you are not able to add them to a spellcheck) I guess zdykstra ?
<zdykstra>
shellcheck, not spell check - it's a tool that is built to find those types of things
<Begasus>
ah, misread :)
<zdykstra>
It'll warn if an unitialized variable appears out of nowhere :)
<zdykstra>
How are you, Begasus? Still recovering well?
<Begasus>
Fine so far, still have to take things easy, thanks for asking
<jmairboeck>
what is also not helpful is that pkgman doesn't resolve dependencies from local files, that means that pkgman install texlive_full-2023-1-any.hpkg doesn't work
<Begasus>
will be a long while to full recovery
<jmairboeck>
and texlive_*-any.hpkg doesn't either because I have some packages installed and get a "name already in use" error
<zdykstra>
How hard is it to make your own repo? On Void Linux, it's a single command to turn a directory of packages into a repository
<zdykstra>
Might be a good option for testing
<jmairboeck>
yes, making $haikuports/packages a real repository would be a good thing :)
<Begasus>
doesn't help the end user I guess?
<jmairboeck>
in opensuse, I use createrepo for that, it creates a "repodata" subfolder containing yum repo metadata, then the folder can be added as a normal repository in zypper
<jmairboeck>
I put all my self-built and downloaded RPMs in there
<Begasus>
don't know if it using it or not now jmairboeck (gcc2 version)
<jmairboeck>
I noticed that too, I'm not sure
<jmairboeck>
my master thesis compiled in Texstudio :)
<Begasus>
nice!
<jmairboeck>
it took me quite a while to figure out and install the necessary packages
<Begasus_32>
maybe it needs " --with-icu add ICU support (off)"
<Begasus>
I think it defaults to off,
<jmairboeck>
besides the ones, texstudio requires, it also needed algorithm.sty, a.k.a tex:algorithms (note the 's'), a.k.a. texlive_mathscience, and biblatex.sty, a.k.a. texlive_bibtexextra
<jmairboeck>
maybe it wouldn't need ICU at all then?
<Begasus>
trying a new build with "--with-icu"
<jmairboeck>
could we then remove the ICU requirement instead?
<Begasus>
if it looks like it isn't neede I think so
<Begasus>
checked others? (opensuse?)
<jmairboeck>
the reason for rebuilding libxml2 was to get rid of an (implicit) requirement of icu66_devel from the texlive build
<jmairboeck>
on my host system (opensuse) libxml2 doesn't seem to require icu
<Begasus>
at repology it's a mix, some mention it, some don't
<Begasus_32>
checking for icu-i18n... yes
<Begasus>
so I'm guessing in it's current state it isn't using icu
<Begasus>
one less dependency if it is ok without it :)
<Begasus>
don't know if libxml2 is integrated in the Haiku source though, maybe some of the core developers has an answer to that
<jmairboeck>
ICU is definitely, hence we need to take care here
<jmairboeck>
yes, PulkoMandy explained to me, that Haiku doesn't expose ICU publicly, so doesn't depend on the devel package
<jmairboeck>
for me, it boiled down to building libxml2 with icu 70, then I could reinstall all necessary devel packages (for texlive) without needing icu66_devel any more
<Begasus>
well for libxml2 it seems you don't need icu
<jmairboeck>
maybe if libxml2 doesn't even need ICU we could just remove that dependency and be fine as well
<jmairboeck>
texlive 2023 definitively needs ICU 70, or using its bundled ICU instead (and probably need to patch that) or patching out the newer unicode stuff that bibtex is using
<jmairboeck>
but as we already have a (disabled) recipe for icu70, I went with the first option
<Begasus>
that's the one (gcc2) still build with ICU
<zdykstra>
sit down at my desk and get a new mail notification ... for spam. *sigh*
<Begasus_32>
checking for library containing connect... none required
<Begasus>
so libxml2 is checking for some network connectivity?
<Begasus>
jmairboeck, first texlive, or texlive_core?
<jmairboeck>
texlive_core
<Begasus>
k, build boosted
<jmairboeck>
for building, it would always be that way round (texlive_core first), for installing them, I would have liked to swap those around, but haikuporter doesn't support that
<OscarL>
Begasus: just in case.... libxml2 from my beta4 32 bits doesn't shows any icu usage (unilke the lddtree you posted).
<Begasus>
well, that's build faster then texlive
<Begasus>
because of the "--with-icu" switch I used earlier OscarL :)
_Dario_ has joined #haiku
<OscarL>
ahh.... should try to keep BOTH eyes open while reading... /me's sleepy :-P
<Begasus>
so now we are sure it wasn't used in the current version in the depot +1
<jmairboeck>
then you can merge my PR, Begasus?
<Begasus>
getting late there I suppose OscarL ?
<Begasus>
let some time pass over it, and maybe add some comments on the checks we did here
<jmairboeck>
(it is untested, but I tested it before on the texlive branch, both x86_gcc2 and x86_64)
<Begasus>
it's a pretty common library, so need to be sure we're not doing anything wrong here (which I doubt))
<jmairboeck>
maybe korli does it anyway later :)
<Begasus>
maybe also move the PR for ICU into a seperate PR and enabling it for 64bit/32bit with a conflict to the ICU66 devel package?
<jmairboeck>
should we maybe clean the libxml2 recipe up anyway? (and remove the python2.7 subpackage, or upgrade it to python3.x). What do you think, OscarL? ;)
<OscarL>
Begasus: just my regularly crazy sleep schedule, or lack of one, really :-P
<Begasus>
I've seen patches for python that aren't in our libxml2 patch
<jmairboeck>
our python support in libxml2 is based on python 2.7
<Begasus>
whoot!
<OscarL>
Kill 2.7 with fire! :-)
<jmairboeck>
ok, but I think that is more something for you, OscarL :)
<Begasus>
heh
<jmairboeck>
I'm not a python expert
<OscarL>
jmairboeck: k... but for after I sleep :-D
<jmairboeck>
although I did port frescobaldi and its dependencies
<Begasus>
did some python recipes too (but I got a general.python.recipe to help me those) :)
<Begasus>
s/general/generic/
<nosycat>
Getting rid of Python 2,7 is no easy job. Debian maintainers celebrated successfully doing it just in time for the code freeze a month or two ago.
<OscarL>
heh, I introduced Trac and SVN on my old job (ca 2007)... after watching them being used by Haiku for long before that.
<Begasus>
only a few that use python2
* Begasus
looks at OscarL :)
<OscarL>
not sure I want to touch that "gtk_doc" one :-)
<Begasus>
don't think gtk_doc is that big of a deal?
<OscarL>
as long as it doens't needs too many GTK dependencies...
<OscarL>
but... will surely take a look.
<Begas_VM>
hmm ... seems in the recipe for it it's using python3.9 already?
<jmairboeck>
OscarL: we also use trac at our company, even before I've known Haiku, but it is only a legacy system now (mostly moved to Jira and already in the process of moving away from that one), only a few rebellious projects (including mine) are still using trac.
<OscarL>
yeah, by today's standards seems a bit oldish now :-)... but I would rather eat dirt than having to deal with Jira ever again.
<jmairboeck>
but the main reason for that is that we also use SVN, and moving that to git would be a non-trivial task
<OscarL>
(based on my experience with that from 9 years ago)
<jmairboeck>
and as long as we use svn, we'll keep trac
<jmairboeck>
I want a decent web interface for my repository :)
<OscarL>
understandable.
<jmairboeck>
yeah, Jira is pretty complex and not ideal at all. Besides, they are killing on-premises support, moving everything to the cloud, that's why we will probably move away from it soon
<OscarL>
Add IBM's Lotus Notes to the things that makes want to eat dirt instead of touching them ever again :-D
<jmairboeck>
never had to deal with that fortunately
<jmairboeck>
but I have heard some horror stories ;)
<OscarL>
On of those "things that only Managers find useful"... and/or "You better use it, like it or not, because we already spent a crap ton of money for it".
<OscarL>
Heh, we have packages of "backport_tempfiles" for python 3.8 and 3.9... when it's repo says: "Supported Python versions... CPython: 2.7, 3.4, 3.5, 3.6"
<OscarL>
Guess it's time to retire it.
<OscarL>
"backports_weakref" can go too.
<Begas_VM>
you're throwing my work out? ;)
<OscarL>
how can I surpass you if I don't sabotage you a little bit, eh? :-P
<Begas_VM>
heh, not even sure why they were needed back then :)
<Begas_VM>
*** Failed to find a match for "python3.9>=3.9": Name not found
<Begas_VM>
k, leaves libxml2_python for OscarL :)
<OscarL>
I'll probably remove it too :-P
* OscarL
erases all the things!
<Begas_VM>
would be my guess too, don't know if that one is even used at all
<OscarL>
(and that's reason #546342349 of why he doesn't gets commit access)
<Begas_VM>
not all, first you'd have to fix pip :P
<OscarL>
let's see if korli agrees with the removals :-)
<Begasus>
+1 sounds ok with me
<Begasus>
added some comments on the PR's jmairboeck :)
<Begasus>
for texlive it's too early ;)
<jmairboeck>
yes, that's why it's a draft :)
xet7 has joined #haiku
diver1 has joined #haiku
Diver is now known as Guest8937
diver1 is now known as Diver
<OscarL>
Question... Should I keep or drop the comment on this line? "pyVer=${pythonVersion//.} # remove dot from version"
<OscarL>
I've first added it because I'm such a bash noob.
<OscarL>
but if everyone is familiar with that "//", not much point in keeping it :-D
<Begasus>
need to know where it's used
<OscarL>
(hard for me to gauge that's normal bash, and what's esoteric bash :-D)
<Begasus>
but heading out for food in a bit
<jmairboeck>
I think similar things are used often enough without a comment. I've done it too. But I also have to look it up regularly when writing it to get the exact syntax right ...
<OscarL>
jmairboeck: yeah...know the feeling. I think I'll drop it then (or at least stop adding it :-D)
<Begasus>
bbl
<OscarL>
later!
jmairboeck has quit [Ping timeout: 480 seconds]
_Dario_ has quit [Quit: Vision[]: i've been blurred!]
jmairboeck has joined #haiku
gouchi has joined #haiku
bjorkint0sh has joined #haiku
bjorkintosh has quit [Ping timeout: 480 seconds]
nosycat has quit [Quit: Leaving]
<OscarL>
jmairboeck: I think I'll steal your "commandSuffixes" from the frescobaldi recipe, but using (3.8 3.9 3.10) instead of (38 39 310), so, thanks for that :-)
<OscarL>
seems korli didn't noticed it, and forgot to change it when he moved frescobaldi to 3.9
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
mrnhmath has joined #haiku
<Begasus>
closing down here, g'night peeps!
Begasus has quit [Quit: Leaving]
jmairboeck_haiku has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
HaikuUser has quit []
<jmairboeck>
OscarL: thanks for noticing. I just created a quick PR to fix the commandSuffixes
Diver has quit [Quit: Leaving.]
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
Diver has joined #haiku
jmairboeck has quit [Quit: Konversation terminated!]
chuggy has joined #haiku
B2IA has quit [Ping timeout: 480 seconds]
B2IA has joined #haiku
<Habbie>
ohh, need to remember to make the vis recipe conflict with vim
vezhlys has quit [Quit: Leaving]
gouchi has quit [Quit: Quitte]
xet7 has quit [Remote host closed the connection]
xet7 has joined #haiku
<Habbie>
is there a way to search for packages that provide cmd:vi?
<Habbie>
(pkgman search cmd:vi also matches, say, cmd:vifm)
<Habbie>
i see there's a CONFLICTS missing between vim and qvim, for at least the 'view' command
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
hackkitten has quit [Ping timeout: 480 seconds]
mrnhmath has quit [Read error: Connection reset by peer]
mrnhmath has joined #haiku
mrnhmath has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.49.5/20230325043552]]
<trungnt2910[m]>
How can I open a file with the executable bit set, for example because it is mounted through a remote file system hosted on Windows, through Tracker without having to unset the executable bit?