<nielx[m]>
not necessarily related. It always helps to add a stacktrace
<nielx[m]>
it is a very generic python error where a list (or another iterable) is expected, and there is nothing (NoneType)
<alexmu>
I'm adding some debug statements to see why it craps out
netpositive has joined #haiku
<julicenri>
Just wondering, who's handling the backgrounds package for beta 3?
alexmu has quit [Ping timeout: 480 seconds]
blu256 has quit [Ping timeout: 480 seconds]
tqh has joined #haiku
blu256 has joined #haiku
<PulkoMandy>
I don't think anyone is working on the backgrounds package
netpositive has quit [Remote host closed the connection]
<julicenri>
Who's curating the background contest submissions?
<julicenri>
I sent my entries to bitigchi, but I don't know if they're in charge of curation.
<Begasus>
julicenri, you could use $cmakeDirArgs and -DCMAKE_INSTALL_BINDIR=$appsDir there too (just need to rm the $dataDir I presume since doesn't contain anything valuable there for us) :)
<julicenri>
Would this allow for using `make install` for the INSTALL() stage?
<Begasus>
yep
<Begasus>
ps not checked ;)
<Begasus>
got 2 builds running on the laptop(s), so can't check atm
<julicenri>
I swear, the tabs->spaces thing is fixed for real this time.
<Begasus>
yeah, good now :P
<julicenri>
Resolved :P
mmu_man has joined #haiku
netpositive has joined #haiku
odnes_ has joined #haiku
odnes has quit [Read error: Connection reset by peer]
Maturion has quit [Ping timeout: 480 seconds]
blu256 has quit [Read error: Connection reset by peer]
blu256 has joined #haiku
<Begasus>
julicenri, are you running x86_64?
<julicenri>
Yes
<Begasus>
ok, will do a check on x86_gcc2 later then
<Not-5835>
[haiku/infrastructure] nielx pushed 1 commit to master [+0/-0/±1] https://git.io/Jngm3
<Not-5835>
[haiku/infrastructure] nielx 96e28e5 - Redis: update image to redis:6.2
<julicenri>
Begasus: Could you point me to some recipes that use $cmakeDirArgs and -DCMAKE_INSTALL_BINDDIR=$appsDir?
<julicenri>
I'd like to have some references to use.
<vazub[m]>
Is there any way to easily echo HaikuPorts variables (e.g. $libDir etc.) to see what values they are bound to? Or do I have to dig into code internals to learn that?
<Begasus>
$libDir refers to /boot/system/lib
<Begasus>
I think it's possible though
<vazub[m]>
that was just reference example, but I actually meant generic approach
<Begasus>
but not directly from cli?
<vazub[m]>
whatever works, I just want to learn more about those, as documentation is a bit scarce in that regard
<julicenri>
Huh, the system's telling me to reboot to complete the install process of a built package.
<julicenri>
Never seen that before.
moochris has joined #haiku
<vazub[m]>
Begasus: there is BuildRecipes doc on wiki, but it lists all variables with high-level descriptions what they do, but not actual values
moochris has quit []
moochris has joined #haiku
moochris has quit []
moochris has joined #haiku
<Begasus>
think I've seen it happen once here too julicenri
<Begasus>
in a recipe it should be possible vazub[m]
gingi has joined #haiku
<vazub[m]>
so I can just create a dummy recipe and test/echo any variables by running it? ok
<gingi>
hi
<Begasus>
yeah, should be possible, was just thinking about one too :)
<Begasus>
hi gingi
<julicenri>
So, attempting to use -DCMAKE_INSTALL_BINDIR seems to generate an invalid binary that can't be opened.
<Begasus>
did you use "-DCMAKE_INSTALL_BINDIR=$appsDir"?
<julicenri>
Yes, that.
<Begasus>
what's the error?
<julicenri>
> Could not open "ytdl-gui" with application "Tracker" (invalid argument). Would you like to find some other suitable application?
<julicenri>
That's the error in the dialog box that appears.
<Begasus>
boosting a build here
alexmu has joined #haiku
<Begasus>
vazub[m], you might want to check "$prefix/lib" etc too, as they differ from "$libDir" for 32bit (depending on the architecture used)
<Begasus>
eg "$libDir" for primary equels "$prefix/lib", for secondary equels "$prefix/lib/x86"
<julicenri>
Hold on, just noticed that installing the package creates two entries in $appsDir: ytdl-gui and youtubedl-gui
<julicenri>
Think I might've figured out where the issue is.
<Begasus>
basic one is the later, so you need to mv ;)
<julicenri>
Nah, I'll just change the symlink appropriately.
<julicenri>
Works just as well and means that the mv can be cut out.
<Begasus>
the rdef should be pointed to the correct binary also then
<Begasus>
and probable would be better to rename the recipe then too :)
<julicenri>
I was thinking of doing that, but I was concerned that it might break existing installs.
<julicenri>
No wait, I still am concerned with breaking existing installs.
<Begasus>
works fine here ;)
<julicenri>
I haven't pushed the commit yet.
<Begasus>
I can do those localy (as I suggested before) ;)
<Begasus>
existing installs from? julicenri
ChrisMoore[m] has joined #haiku
<julicenri>
Wouldn't people who already installed ytdl_gui become stranded if the package name changes to youtubedl_gui?
<julicenri>
As in, they won't receive the update.
<Begasus>
if it's merged they will receive the new one with an update
<julicenri>
Even with a package name change?
<Begasus>
if they launch if from Deskbar there wouldn't be a change
<julicenri>
Well sure, but would pkgman know that ytdl_gui became youtubedl_gui?
<Begasus>
well, I guess a search for it would reveal that
<Begasus>
"pkgman search youtubedl" would show both the binary package and the gui package then ;)
<julicenri>
Screw it, just gonna do a mv rename to avoid renaming the package and possible update continuity issues.
<Begasus>
it is called youtubedl_gui, so might as well stick with it ;)
<julicenri>
Eh, just don't want to deal with breaking update continuity.
<Begasus>
it's a small change so no need to worry about changes later (and no need to use "mv" ...)
<Begasus>
anyway, no big deal, only need to rm the $dataDir also in INSTALL
Begas_64 has quit [Quit: Vision[0.10.3]: i've been blurred!]
alexmu has quit [Ping timeout: 480 seconds]
gingi has quit [Quit: Vision[0.10.3]: i've been blurred!]
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #haiku
ClaudioM has quit [Quit: leaving]
* leont
is looking into making perl work a bit better on haiku
ClaudioM has joined #haiku
<julicenri>
Oh, the sysadmins might be into having Perl working better on Haiiku.
<PulkoMandy>
our perl port certainly didn't get a lot of attention for a few years now
<PulkoMandy>
thanks for helping with that :)
<leont>
Fixes an issue with exit statuses: it seems a fixup for BeOS is not appropriate for Haiku
<leont>
I see a networking failure that seems to boil down to "haiku doesn't support SO_REUSEADDR", can that be correct?
<PulkoMandy>
we fixed some bugs around that recently (in the last few months I think)
<PulkoMandy>
I think now it should be fine
<leont>
I'm running beta2, I guess I should be running nightly for this, or wait for beta3? (how soon is that expected?)
<Begasus>
julicenri, maybe also adjust this? application/x-vnd.ytdl_gui
<leont>
Also, it seems the test for SysV message queues is failing to remove the queue (Bad Address), even if it succeeds at all the other tests.
<PulkoMandy>
we are creating the beta3 branch on monday, and releasing it probably sometime this summer
<PulkoMandy>
so, current nightlies should be quite close to it
<leont>
That sounds like I shouldn't wait for it
<PulkoMandy>
yes, I think it's probably better to work from the nightlies
<PulkoMandy>
it's possible that we have bugs in dup/dup2, I didn't see anything in the bugtracker, but maybe no one had found the bug yet
<leont>
Yeah, may have to try it out in C code
<B2IA>
(countryboy) hello from beshare ...
<B2IA>
(countryboy) full-sync ok ...
<B2IA>
(countryboy) also rebooted ...
<countryboy>
could we keep the two ways ?
countryboy has left #haiku [#haiku]
aeryndunham has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
mchasard has joined #haiku
mchasard has quit []
jmairboeck has joined #haiku
aeryndunham has quit [Quit: Leaving]
aeryndunham has joined #haiku
mmu_man has joined #haiku
<julicenri>
Begasus: What needs to be adjusted in the app signature, exactly?
Maturion has joined #haiku
moochris has quit [Quit: Vision[0.10.3]: i've been blurred!]
moochris has joined #haiku
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #haiku
tbcr has joined #haiku
<jmairboeck>
Begasus: I just found out that the missing files in texlive are not supposed to be installed directly, they are only included in the tarball if one wants to run tex directly from a build, from an installation, they are supposed to be generated by the "updmap" command. The generated files are put into var, so it actually works as intended. My test document now also works after running the command. I have thought about whether we should put it into the
<jmairboeck>
install section of the recipe, but it seems it generates the files based on the installed fonts, so I think it should actually be done by the user. So there is nothing to change here :)
<PulkoMandy>
you could put it as a post-install command then?
<B2IA>
(Butler) Message sent.
<jmairboeck>
PulkoMandy: probably could be done, but I'm not sure if it is worth it. If the user installs new fonts afterwards, they probably want to regenerate the map files anyway
<Begasus>
just got back from a visite to our grandchildren, now some time with the dogs here, will get back later
<leont>
Ran the test suite on nightly, and now I have more failures instead of less 🥲
<vazub[m]>
I was successful in extracting runtime HaikuPorts variable values and prepped a handy markdown reference, if anyone is interested ( Begasus for viz)
ClaudioM has quit [Quit: leaving]
<Begasus>
vazub[m], could you show me the recipe you worked on?
cocobean has joined #haiku
<vazub[m]>
It is a dummy one, just barely based on the original port template. openlibm itself is still wip. I can send it to you though.
<Begasus>
don't suspect it should be related to any other packages, but I could look into it vazub[m]
gouchi has joined #haiku
moochris has quit [Quit: Vision[0.10.3]: i've been blurred!]
AlwaysLivid has joined #haiku
AlwaysLivid is now known as Guest2767
Guest2767 has quit []
AlwaysLivid_ has joined #haiku
<AlwaysLivid_>
Hi, may I ask who's responsible for featuring applications in HaikuDepot?
<Begasus>
GCI was fine for that I gather AlwaysLivid_
<AlwaysLivid_>
I am not following.
<Begasus>
*featuring applications
<nephele[m]>
haiku on a phone would be neat
<PulkoMandy>
an OS using Haiku parts on a phone would be nice (maybe) but it would not be Haiku :)
<nephele[m]>
Indeed
<nephele[m]>
I would expect atleast a different name, and most servers shared, but for example a different UI
<AlwaysLivid_>
It could happen. Not sure if you're familiar with "Phosh" and the PinePhone.
<nephele[m]>
maybe a different "main view" an application would provide for a phone form factor
<AlwaysLivid_>
Let's get ARM working first :D
<nephele[m]>
isnt phosh some wayland compositor?
<AlwaysLivid_>
Yeah, but it comprises of an application launcher too.
<Diver>
AlwaysLivid_: I have permissions to do that, so you want to change something?
<Begasus>
shouldn't bare metal be more important atm?
<AlwaysLivid_>
Begasus, yes.
<nephele[m]>
Okay, linux has many wayland compositira, not sure how relevant that is too haiku :)
<Begasus>
Is it possible to use a empty SOURCE_URI in a recipe?
<nephele[m]>
but yes i do know the pinephone alwayslivid
<AlwaysLivid_>
I'm not talking technical details, I'm talking about the UI characteristics, nephele[m].
<Begasus>
I know PhoS (knew) :)
<AlwaysLivid_>
and how desktop apps are made to fit
<nephele[m]>
running desktop apps without explicit support on phones seems like a huge mistake to me
AlwaysLivid_ is now known as AlwaysLivid
<Begasus>
There is a difference in "native" and other apps ... (see progress on Qt)
<AlwaysLivid>
nephele[m], many of them work just fine
<AlwaysLivid>
Diver, yeah, I can come up with a list and come back with it on Wednesday (I'll message some apps I've been looking at now), but it's more of an issue as to how this is going to be done in the long-term. I'm going to message a few applications in a bit after I gather them.
<nephele[m]>
alwayslivid: perhaps for linux standards
<nephele[m]>
but really, you basically ask devs that made their app for the desktop to suddenly support a completely different UI workflow
<Niklas[m]1>
This Haiku Phone idea is really good but I think it will be very much work to make it usable
<Diver>
AlwaysLivid[m]: send the list to me here or on Telegram and I'll add them
<nephele[m]>
and if they dont they get users complaining that app X doesnt work with the phone
<PulkoMandy>
let's do computers first, ok?
<AlwaysLivid>
Got it, Diver.
<AlwaysLivid>
Yeah, let's not get sidetracked.
<Begasus>
+1 PulkoMandy
<psydroid>
yes, Haiku on my Orange Pi first
<nephele[m]>
Pulkomandy: i dont think those are completely independant really
Begasus_32 has quit [Quit: Vision[0.10.3]: Gone to the dogs!]
<nephele[m]>
woth more and more semi desktops :P
<AlwaysLivid>
Let's get the desktop version to run on ARM first, then we'll talk :D
<psydroid>
and then on my Jetson Nano
<AlwaysLivid>
If we fix bugs and features related to scaling on the desktop platform, that will be more likely to happen.
<nephele[m]>
I would really love to have a small form factor device that runs Haiku normally om a commected display, but can do phone stuff aswell
<nephele[m]>
alwayslivid: nobody in haiku cares abour ARM anymore, that port is abandoned pretty much
<psydroid>
ARM64 too?
<nephele[m]>
Scaling isn't a problem imo.. more general UI paradigms
<AlwaysLivid>
No Haiku Phone, then :/
<AlwaysLivid>
unless if we used some RISC-V stuff, but
<AlwaysLivid>
yeah
<nephele[m]>
ARM64 is a different arch
<AlwaysLivid>
*ARM64, sorry, thought that was basically the default at this point..
<psydroid>
yes, all my hardware is ARM64
<AlwaysLivid>
because nobody cares about ARM anywhere at all
<PulkoMandy>
why would we care about 32bit ARM?
<PulkoMandy>
being limited to 2GB of RAM is not fun
<nephele[m]>
2GB is what my laptop has :)
<AlwaysLivid>
is it fun?
<nephele[m]>
The laptop works fine for casual stuff
<AlwaysLivid>
so not very fun? :P
<nephele[m]>
Some of my motovation of keeping user older hw is also to reduce waste
<Begasus>
heading down here, cu peeps!
<AlwaysLivid>
byeee
<nephele[m]>
comes with the territory i suppose :)
Begasus has quit [Quit: Ex-Chat]
<nephele[m]>
night begasus
<AlwaysLivid>
to be honest, i'm also a fan of using the least amount of resources when computing, but it's like
<AlwaysLivid>
there's stuff being done that more people will use right now and in the long run and are very huge efforts in themselves
<nephele[x]>
Just a minor code style fix for my previous commit
<nephele[x]>
AlwaysLivid: We don't need to be perfectly minimalistic, but if we can keep old HW working with some effort that seems worth it to me
<PulkoMandy>
we do our part on x86 already
<PulkoMandy>
ARM is covered by RiscOS
<nephele[x]>
Certainly
<nephele[x]>
I am happy to use haiku on x86, even if i only have one device that has this arch
<AlwaysLivid>
nephele[x], agreed to be honest, but it's not like it ever worked there in the first place, right
<AlwaysLivid>
i'd object to a breaking change, but
<nephele[x]>
I'd be fine with breaking BeOS compat on x86 if the choice is that or dropping the arch for instance
<nephele[x]>
in practice i don't need it :g
<nephele[x]>
arm32 is not really relevant to us i don't think, there is basically no boards that make sense for haiku to target at this point, for arm64 there is some atleast
<nephele[x]>
though, running on the pinebook is a more currently interesting target than a phone formfactor, but to me those seem to be two unrelated tasks (designing some apis for mobile applications vs running on a new arch(
<nephele[x]>
enough monologing, i should fix another renga bug :)
<AlwaysLivid>
if we get it to run on the *pinetab*, it will be able to run on the pinephone too
<AlwaysLivid>
hypothetically speaking
<nephele[x]>
Well, you brought up arm arch severall times, i am not convinced this has much to do with phone support in general other than specific HW support
<nephele[x]>
for example, we might need better power management, but we also need this on laptops potentially
<nephele[x]>
The main point that is different about a phone is really the UI imo, and i don't think the normal Haiku guis and app style would work as such if you just did something like scaling it down
<Niklas[m]1>
Well,first we'd need touchscreen support for supporting the PineTab or PinePhone...or my x86 laptop with a touch screen :D
<nephele[x]>
wasn't a patch merged for that`
<nephele[x]>
pulkomandy: thanks :D
<Niklas[m]1>
I don't know.Haiku doesn't work on that laptop at all but from what I read in the forum,touch support isn't available.
<nephele[x]>
i vaguely remember some i2c support landing in the sourcetree... that obviously doesn't mean "we now support touch everywhere" since there is a bit more to it, but it could be an improvement
<PulkoMandy>
"touch support" doesn't really mean a lot
<PulkoMandy>
your touchscreen could be USB (that should work already) or i2c (there is a work in progress driver, it's in our sources, but it's not compiled in by default because on some machines it keeps moving the cursor all the way to the left even if you don't touch anything)
<Niklas[m]1>
I don't know what it is.Both lsusb and lspci don't list it
<nephele[x]>
it's neither usb nor pci
<nephele[x]>
i2c i mean
<PulkoMandy>
it's probably i2c then, yes
<Niklas[m]1>
And what's the command for listing i2c devices?lsi2c doesn't exist
<Vidrep_64>
If someone wants to create a patch, I'll gladly test it on this system before it's committed to master
alexmu has quit [Ping timeout: 480 seconds]
Maturion has quit [Remote host closed the connection]
Maturion has joined #haiku
ClaudioM has joined #haiku
<tqh>
I think very few now about intel p-states and how to fix it. Probably ask korli to take a look.
jmairboeck has quit [Quit: Konversation terminated!]
<AlwaysLivid>
Hi, does anyone else get the problem with "Your browser cannot play this video"?
<AlwaysLivid>
I'm currently doing some testing in order to spot what the breaking change was and I'm not sure what people mean exactly by saying "it's not working" (e.g. it doesn't cause a system-wide crash)
<nephele[x]>
that's really vague alwayslivid...
<AlwaysLivid>
YouTube shows that message directly in the browser.
<nephele[x]>
Oh, that, it's broken
<AlwaysLivid>
What's even vaguer is the "YouTube is not working", which is preventing me from locating and dealing that change.
<AlwaysLivid>
*with that change.
<AlwaysLivid>
That's the problem. Right?
<nephele[x]>
People expect youtube to work, they get on the side, it doesn't and they complain, thus your perception
<nephele[x]>
There was no change in our webkit port that cause youtube to break, they just changed their website to require an api we don't have
<AlwaysLivid>
Diver reported that YouTube works in hrev54402. nephele[x]
<AlwaysLivid>
... The message I got on YouTube, that's the problem people are reporting. Is that correct?
<AlwaysLivid>
Because "broken" is way too vague and I cannot spend hours on a false pointer that may be caused by something different
<nephele[x]>
We already know what the problem is, not sure what you are investigating? :)
cocobean has quit [Quit: Page closed]
<AlwaysLivid>
Do we really, though?
<nephele[x]>
yes...
<AlwaysLivid>
... How can it possibly even be a result of a backend change if YouTube can work in a previous revision?
<nephele[x]>
Media source extensions has to be enabled in our webkit port and implemented properly, without this youtube likely won't work, it may be that some youtube videos work regardless because youtube follows a really wierd rollout model for new requirements
<nephele[x]>
AlwaysLivid: haikuwebkit is not part of the haiku package
<AlwaysLivid>
But we're talking about Web+ here.
<nephele[x]>
no, we are talking about webkit
<AlwaysLivid>
... I highly doubt it, the problem is that YouTube randomly stopped working in WebPositive.
<AlwaysLivid>
And that's exactly what I am looking into
<AlwaysLivid>
and that's what my question was about
<nephele[x]>
and again, webkit is not parr of the haiku package, it is in a seperate package
<nephele[x]>
and it basically wasn't updated in about 9 months or so
<nephele[x]>
Web+ is not responsible for rendering any web content, that's all in webkit
<AlwaysLivid>
so it hasn't worked for 9 months is what you're telling me?
<nephele[x]>
no
<nephele[x]>
I just said it wasn't updated for long, i didn't claim that it not beeing updated caused yougtube to stop working
<AlwaysLivid>
but if the separate package hosted in haiku's servers that's automatically bundled with each new nightly build hasn't changed at all
<AlwaysLivid>
but hrev54402 allegedly works, the very next revision doesn't
<Vidrep_64>
tqh, I see PulkoMandy has set it as a blocker for Beta 3, so maybe it will get a look (or maybe not) :)
<nephele[x]>
alwayslivid: If you wish to try and bisect the entire haikuwebkit tree to find a potential change there, you can do so, or you could spend your time on implementing MSE, which we already know we definetely need for youtube support but don't have
<AlwaysLivid>
this conversation has confused me big time, especially because as you're telling me, there literally wasn't a change
<AlwaysLivid>
i'll continue looking into the thing that i was looking into, which was definitely NOT haikuwebkit
<nephele[x]>
Youtube changed
<AlwaysLivid>
that makes sense
<AlwaysLivid>
but why the heck would the previous revision work and the next one would not?
<nephele[x]>
and their website is incredibly hard to a/b test against, because they will serve you random versions of websites sometimes
<AlwaysLivid>
despite no changes in the web+ or the haikuwebkit code
<nephele[x]>
I don't know if there was a haikuwebkit change at that time, you would have to check if there was
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #haiku
<nephele[x]>
and if diver sais that it worked with one state and not a different one he could look at his state file to see which version was active for each state respectively
<AlwaysLivid>
jesus
AlwaysLivid is now known as Guest2778
Guest2778 has quit []
AlwaysLivid has joined #haiku
gordonjcp has quit [Ping timeout: 480 seconds]
AlwaysLivid is now known as Guest2780
<PulkoMandy>
nephele[x], you are missing the latest information I'd say
<PulkoMandy>
I trust Diver (who has been testing and finding hrev numbers for like 10 years) to do things right
<PulkoMandy>
so we have this new info now
<PulkoMandy>
everyone believed it was MSE and a change on youtube side
<PulkoMandy>
it turns out it is not and people should not trust me
<PulkoMandy>
(as usual, I keep saying it, but no one listens)
<nephele[x]>
Sure I do too, but i am saying that hrev numbers are not directly related to haikuwebkit versions
<PulkoMandy>
there is no change of haikuwebkit version
Guest2780 is now known as AlwaysLivid
<PulkoMandy>
he tried the same version on beta2 (works) and on nighly (does not work)
<nephele[x]>
with haikulauncher?
<PulkoMandy>
hence why we're looking at hrevs: the problem is somewhere in haiku and not in haikuwebkit
<PulkoMandy>
no, with webpositive by downloading old nightly builds and beta2 and running them
<PulkoMandy>
AlwaysLivid, so, yes, "this content is not supported in your browser" is the first problem
<PulkoMandy>
I don't know if there is a bug report about it
<nephele[x]>
This content is not supported sounds like a codec problem
<AlwaysLivid>
so that's not the problem i am looking to prevent?
<PulkoMandy>
(possibly one of these issues where everyone thought "the devs must already know" and so no one ever reported it)
<PulkoMandy>
it is. Beta 2 has working video, nightlies have this error
<PulkoMandy>
nighlies should have working video instead
<AlwaysLivid>
i've officially lost track completely, am I actually coming across a huge layer of problems on top of each other
<PulkoMandy>
what other problems do you see?
<AlwaysLivid>
if the 'your browser cannot play this video' is not the problem somehow miraculously caused by the macdecorator change, what is?
<PulkoMandy>
it's probably not that change
<PulkoMandy>
why are you looking at this specific change only?
<PulkoMandy>
diver gave me this info: hrev54415 works, 54428 doesn't
<AlwaysLivid>
I got the number wrong.
<PulkoMandy>
although I looked at that list and didn't find anything obviously related
<AlwaysLivid>
... I thought it was hrev54503 and hrev54402, but I completely skipped over the 4, so I only counted the previous change in.
<PulkoMandy>
there is however a change to media kit in that list
<PulkoMandy>
so the first thing I'd check would be hrev54422
<AlwaysLivid>
how much time do i have?
<nephele[x]>
We can update webpositive after the beta too
<AlwaysLivid>
the reviewers won't like that
<AlwaysLivid>
whatever
<PulkoMandy>
I don't work for the reviewers
<AlwaysLivid>
how much time do i have?
<AlwaysLivid>
me neither and i know
<PulkoMandy>
the users will still like it
<PulkoMandy>
I have my whole life and I hope it will be long
<AlwaysLivid>
as long as we get it to work, it'll be fine, but ASAP is a good idea too.
<nephele[x]>
No need to rush, better to take this as a learning exercise
<PulkoMandy>
stop putting yourself under artificial stress, you don't need that and it makes you produce bad quality work
<AlwaysLivid>
true.
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<PulkoMandy>
if it's not in the beta3 changelog it will be in the beta4 one
<AlwaysLivid>
it's more of a question of 'whether should i come up with a script that will build images for each of the 100 changes and test each one of them if the hrev you're talking about doesn't work'
<AlwaysLivid>
or whether i should just take it the chill kind of way and just do it manually because who cares
<nephele[x]>
why not use git bisect + qemu?
<AlwaysLivid>
would rather emulate multiple instances at once
<PulkoMandy>
if it's not this one I have no idea what else in that range it could be, the other ones are unrelated changes
<PulkoMandy>
yes, git bisect will get you through this by building haiku about 7 times
<AlwaysLivid>
checking
<nephele[x]>
git bisect is mathematically already the quickest way to narrow it down if you don't know, but in this case i certainly agree, that seems to be the only one that really sticks out
<nephele[x]>
(the quickest way without prior knowledge)
mmu_man has joined #haiku
<PulkoMandy>
another way to help here is making a simpler test case than "youtube". In this case it would be a webpage which use html5 video tag and tries to list the codecs supported by the browser, and see if it's different between beta2 and nightlies because of this change (that's where I expect it would have an impact)
<PulkoMandy>
actually
<PulkoMandy>
html5test.com does that
<PulkoMandy>
and it says we only have ogg theora
<PulkoMandy>
which I think youtube doesn't use?
<PulkoMandy>
we probably want h264 and maybe webm/vp8 to be reported as available?
<nephele[x]>
safari on ios has yes for MPEG4 ASP; h.264 and h.265
<PulkoMandy>
vivaldi on windows has h264, ogg theora and both webm versions