<Begasus[m]>
it's linked at the buildmaster page also
<Begasus[m]>
Repository build
<OscarL>
(my last link is to an "updated" report.txt)
<Begasus[m]>
back in the sadle now :)
<Begasus[m]>
I guess we can drop python3.9 in pytest also, it's broken anyway now
<OscarL>
(both repo_consistency.txt and report.txt get written in HaikuPorter's OUTPUT_DIR
<Begasus[m]>
having only one should be sufficiant
<Begasus[m]>
also local OscarL ?
<OscarL>
repo_consistency.txt shows build-requires issues, while the older report.txt only seems to show runtime ones. Point for the "new guy" :-D
<OscarL>
Begasus[m]: only if you're running HaikuPorter in buildmaster mode, I guess.
<Begasus[m]>
ah, no worries then, not needed here
<OscarL>
files get generated from: "buildmaster/backend/assets/loop"
<Begasus[m]>
yeah, I guess for that akregator thing it's missing secondaryArchSuffix for dbus
<OscarL>
re: broken _python39 packages... feel free to drop them all. If something breaks... because somehow is still using Python 3.9 (and I didn't found it yet), we should be moving it to 3.10 anyway.
<Begasus[m]>
didn't tackle pytest as it's using the default version thingy in there :)
* OscarL
*finally* notices that the "Repository build" link is the one for report.txt :-D (still half-asleep).
<Begasus[m]>
if dropping 3.9 (which should) then the default version variables should be removed also
<Begasus[m]>
for akregator, so it should use the latest one?
<OscarL>
first saw the new build page first on mobile phone (no "mouse over tooltip" there showing the URLs :-D), and only clicked on the raw link for the new report.
<Begasus[m]>
took me a few clicks this morning also before finding it out :)
<OscarL>
Begasus[m]: don't drop the defaultVersion variables. We may need to re-add them next.
<Begasus[m]>
that's why I haven't touched it OscarL , I'll let those for you :)
<Begasus[m]>
biab
<OscarL>
(when we start to add the "next" Python version, but before making it the "default")
<Begasus[m]>
ow lol, looks like already got a newer dbus recipe here :P
<Begasus[m]>
1.12.20 still has cmd:python in BUILD_PREREQUIRES
<Begasus[m]>
should we fix that to please the consistency report OscarL ?
<Begasus[m]>
not sure why I marked 1.16.2 as broken, packaging and content look pretty good :)
<OscarL>
all those packages requiring cmd:python (2.x)... either need to be updated (or dropped) at some point. Not that much of a hurry for build-requires, I guess, but yeah... all go to the ToDo list :-)
dodo75 has joined #haiku
dodo75 has quit []
dodo75 has joined #haiku
<Begasus[m]>
bugger :P
<OscarL>
feel free to work on them, if you feel like it (I need to better time my online/sleep schedule to be able to download things)
<OscarL>
why 32 bits buildmaster expects to find "kglobalaccel6_doc-6.13.0.DependencyInfo"? Could it be due to the ARCHITECTURES_doc="any"?
<OscarL>
I'm not up-to-speed with jmairboeck changes around those _doc / "any" parts :-(
<nephele>
what is kglobalaccel?
<Begasus[m]>
one of the KDE frameworks
<Begasus[m]>
I don't think jmairboeck saw that consistency report yet also OscarL
<Begasus[m]>
could maybe alter something on haikuporter side?
<OscarL>
I can't really comment where the issue is or how to fix it (I only glanced at some commit logs and issues regarding _doc and "any" arch changes, but I'm way off from understanding the nuances there).
<Begasus[m]>
well those docs now are true "any" arch unlike before, so dropping secondaryArchSuffix is one of those changes needed
<Begasus[m]>
eeps, my new dbus package is more then double the size of the current :P
<OscarL>
I see. Yeah, that sounds like what could fix that kglobalaccel. (as it PROVIDES_doc one with a suffix)
<Begasus[m]>
ah, no not double :P
<Begasus[m]>
err ... I removed the doc packages for the frameworks on last bump
<Begasus[m]>
so there shouldn't be one for kglobalaccel?
nephele has quit [Ping timeout: 480 seconds]
<OscarL>
still seeing it here, Begasus[m].
<Begasus[m]>
in that log yes
<Begasus[m]>
eeps
<OscarL>
(just did a git pull upstream/master, and it is there on the .recipe)
<Begasus[m]>
problem 1: package kglobalaccel6_doc-6.13.0-1 requires kglobalaccel6==6.13.0, but none of the providers can be installed
<Begasus[m]>
so somewhere this is left behind in the version bump
<Begasus[m]>
frameworks are at 6.16.0 now
<Begasus[m]>
lol!
<Begasus[m]>
seems I didn't push the change for that one :P
<OscarL>
those sounds like could be problematic (if _doc are to be "true any")
<OscarL>
"irq" is just a variant of "inrecipe", but using "query" instead of "find" (as it is faster for me, on this install where query properly works :-D)
<nekobot>
• Begasus (863851e2): kglobalaccel6, bump to 6.16.0 (#12663)
<Begasus[m]>
one down
<Begasus[m]>
the other kde related ones will be fixed in gear25.08
<Begasus[m]>
localy upped already to 25.04.3
<OscarL>
Nice. Thanks for all your work, Begasus[m]. We appreciate you!
<Begasus[m]>
heh :)
<OscarL>
(or at least I do... can't really talk for the rest of crazy ones in here! :-P)
<Begasus[m]>
thanks, as long as the joy is still there and the brain co-ops you're not done with me yet :P
BrunoSpr has joined #haiku
BrunoSpr has quit []
<OscarL>
Sounds like a win-win to me! Happy to have you around for many years to come.
<Begasus[m]>
not sure where I'll be in 10 years :)
<erysdren>
love ya both both OscarL and Begasus[m], thanks so much for working on Haiku
<Begasus[m]>
I'm not working on Haiku, but thanks erysdren :)
<Begasus[m]>
seems dbus doesn't even require python OscarL :P
<erysdren>
you know what i mean :P
<Begasus[m]>
yeah ;)
<OscarL>
aww! Thank you so much erysdren! I was having you in my mind lately... as I have being playing some sick DOOM total-conversions... and I thought.... "Mmm, wonder what erysdren thinks about this one?" :-)
<erysdren>
:D
<OscarL>
Ashes 2063. What a trip! (played HardReset, Episode 1 + Dead Man Walking, just started Episode 2). Need to try to run it on Haiku still :-)
<erysdren>
originally a boxed game on shelves, but in 2016 or so it was made free and open source, through and through
<erysdren>
by the company
<erysdren>
so it's not abandonware but properly free
<OscarL>
even GOG is giving away Postal 2 these days... doubt we'll have much trouble accepting Postal :-)
<erysdren>
the main issue i forsaw is finding a non-bundled source for the POSTAL game data
<erysdren>
it's free on Steam (and GOG iirc) but the game data is not included with the source code repo
<OscarL>
and if we do... maybe we need to start some "secondary channel" for stuff that can't fit HaikuPorts for one reason or another.
<Begasus[m]>
you could always add the engine and add some text on the game data erysdren ?
<erysdren>
for Ken's Labyrinth i ended up downloading the game data from Ken's own website and unzipping it into the proper Haiku data dir
<erysdren>
in the recipe
<erysdren>
but can't easily do that with POSTAL
Forza_ is now known as Forza
<OscarL>
Begasus[m]: or a post-install script that ask the user to first do whatever it is needed, perhaps.
<Begasus[m]>
something like that OscarL yeah
<erysdren>
good idea
<OscarL>
mmm, thinking about that one... say that the user is asked: "Do you want to do this and that, or cancel the install?" is that even possible from a post-intall script?
<erysdren>
vendoring the 450 mb of game data into the haikuports repo ain't gonna happen :P
BrunoSpr has joined #haiku
<Begasus[m]>
OscarL: I think you'd need to call "pkgman uninstall ..." when the user decides to click on "No"? :P
<OscarL>
erysdren: yeah... sounds a bit much. (even if we have tex/texlive 4 GB, last I remember?)
BrunoSpr has quit []
<Begasus[m]>
well, split up, it's still quite big if you install all "required" packages for texlive though
<Begasus[m]>
but those are a good thing to have around
<OscarL>
Begasus[m]: sounds like a bug/defect then. One could resonably expect that an install fails if the post-install script fails.
<Habbie>
i had a post-install fail yesterday. it did not abort the install
<Begasus[m]>
the basic parts are fine OscarL
<Begasus[m]>
it's packages that require it need additional packages from it
<OscarL>
Habbie: hello there! good day to you! Thanks for the info. Shows a weak spot on the system, IMO.
<Begasus[m]>
post-install is triggered "after" install, so I don't think it can atm?
<OscarL>
right. "post" should have triggered some warnings in my brain, but it failed to do so.
<Begasus[m]>
heh
<OscarL>
I maybe was mixing up "pre-install" which I don't think we have, but maybe should?
<Begasus[m]>
I'm not touching something there :D
<OscarL>
Habbie: read some of the logs lately, and I was reminded of your changes for your chomebook. Just a suggestion... would you mind pushing your intel_extreme driver changes? they don't need to be "perfect" to be usefull, just not only on *your* HDD/SSD :-)
<Habbie>
OscarL, can i get you to review them right now? :)
<OscarL>
some things in intel iGPU does not make much sense anyway.
<Habbie>
yes, you can ignore the previous commit, this one basically replaces it
<Habbie>
i think line 115 really is wrong, but I can probably fix that
<Habbie>
otherwise users with a 9d80 lose brightness control
nephele has joined #haiku
AlienSoldier has joined #haiku
<OscarL>
my point is... you did the work to make it work OK on your hardware, and you are a "recurring/frequent" user. I rather have *your* system working, than somene elses.
<Habbie>
sure
<Habbie>
i'll try handle it soon
<Habbie>
i did submit something else to gerrit this week!
<nephele>
=me waves hello
<AlienSoldier>
wgen i boot back to my 32bit install from my 64bit install the clock is off by 4 hours and the haiku volume keep the position they where in the 64 bit OS.
<AlienSoldier>
*when
<AlienSoldier>
volume as in disk
<OscarL>
how the fuck you reply so fast, LOL. haven't even hit Enter, and you already replied. Man.... is this how I find out my brain is a turle's one? :-D
<Begasus[m]>
dbus-daemon[89729]: Failed to start message bus: Failed to bind socket "/tmp/dbus-xq7N4JeS6S": Permission denied
<Begasus[m]>
serves you well :P
<nephele>
AlienSoldier: haiku has a setting wether the CMOS clock is in UTC or in local time, maybe you have mismatched these settings?
<Habbie>
OscarL, i.. don't know. i just do :>
<OscarL>
yeah... I'm tagging you and waddlesplash as "probably bots" anyway! :-P
<nephele>
We've had enough bots today already :)
<AlienSoldier>
nephele seem like it, i was looking for the problem on the 64bit side, but it seem it was the 32bit one :) thank you. Is there any advantage to use GTM over local or vice versa.
<AlienSoldier>
That sure was annoying :)
<nephele>
AlienSoldier: windows uses local time, unix uses UTC time.... you have to have both match but other than that there is no difference on which you should pick
<nephele>
if you only run haiku it doesn't matter aslong as they match
<AlienSoldier>
awsome
<Begasus[m]>
thanks on cleaning that nephele :)
<Habbie>
can you tell haiku what the hardware clock uses?
<nephele>
yes Habbie
<Habbie>
oh it does
<nephele>
Begasus[m]: cleaning? you mean the forum?
<Begasus[m]>
forum yes (if that was you)
<AlienSoldier>
now if i could have numpad support in iceweasel and find how to do French accent in it also the 64bit experience would be lot better.
<nephele>
ah yes, i did delete like 25 users and about 48forum topics or something
<nephele>
AlienSoldier: do it in styledEdit and copy it over
<Begasus[m]>
so then yes, thanks :D
<AlienSoldier>
nephele that is what i do currently, but it is.... annoying :)
<OscarL>
Desktop PCs using UTC is crazy. "normal" user will *always* set their BIOSes to localtime. Doing anything else is dumb, IMO (for *desktop* systems).
<nephele>
i always have it in utc time OscarL
<Habbie>
UTC time in BIOS is easier for DST though ;)
<nephele>
local time seems wierd because of daylight saving time
<OscarL>
nephele: you are not a *normal* user.
<nephele>
:(
<Begasus[m]>
fits right in OscarL :P
<AlienSoldier>
some users here are supra luminal
<Begasus[m]>
luminal?
<AlienSoldier>
faster than light
<OscarL>
system ask for time... user watches its clocks, and answers. It is not that difficult to understand why *Desktop* system should default to localtime.
<nephele>
I just let it use NTP
<Begasus[m]>
ah :)
<Habbie>
OscarL, except, on a unix system, the kernel clock is always UTC; display is just configuration
<OscarL>
sure, but don't mess with the user's PC system. your OS doesn't *owns" the PC the user is using. thus... if it is a desktop system... default to localtime instead of messing with the poor user's time scale.
<nephele>
OscarL: i don't know what the default is, but haiku won't manipulate the clock unless you tell it to
<Habbie>
on my haiku install, GMT is selected
<Habbie>
i don't -think- i picked anything
<OscarL>
Haiku does that right. True. I should clarify that I'm pissed at most linuxes :-D
<AlienSoldier>
perhaps the 32bit and 64bit build have different install default value. i don't remember having changed mines, but perhpas i did.
<Habbie>
hmm, but, fUseGmtTime(false),
<Habbie>
i don't know where defaults are
<nephele>
would have to look at the code, but if it initializes with false and there are no settings it may probably just write that out, or keep that same choice in memory
<Habbie>
ack
<Habbie>
which suggests that i -did- change the default
<Habbie>
oh wait i can reboot into one i definitely did not change
<Habbie>
because i dd'ed a nightly to that partition last week
<nephele>
I want a Haiku that can completely recover from not having any settings :)
<nephele>
if you delete all settings that shouldn't be too bad
<Habbie>
funky, haiku crashed on boot
<OscarL>
My point is... default user... get asked (or finds out time doesn't matches): what time is it? It will ALWAYS reply in local time. Why mess with that?ç
<nephele>
OscarL: i dunno. that's not a question i want to answer as a user
<nephele>
i answer to the timezone, cus i know what that is
<OscarL>
Begasus[m]: will do now. sorry if slow.
<nephele>
but the time? if i want to check that i check a computer
<Habbie>
ok. clean install is set to Local
<nephele>
so if the computer asked i have to check on another computer
<nephele>
i'd rather supply timezone and tell it to stuff it and use ntp
<Habbie>
it would be better if the computer could ask another computer
<Habbie>
nephele, yes :)
<OscarL>
My point is... if your *DESKTOP* computer user needs to know about timezones... other that what it sees on his clock... your OS has already failed.
<Begasus[m]>
no rush OscarL .... .....
<Habbie>
OscarL, well, that's problematic, because then all OSes are failing
<nephele>
nah. timezones are a political failure, not one of the computer
<nephele>
DST is annoying. but basically everyone knows their timezone... it's "pick a vaguely close city"
<OscarL>
Habbie: somehow "Windows has beeing faiing less that then rest" is my point.ç
<Habbie>
windows also asks on install
<nephele>
.... by beeing preinstalled and preconfigured?
<nephele>
you could make an argument that Haiku, if you install it to a windows system, could canibalize some settings from the install though
<OscarL>
I never had a Windows install mess with my BIOS-set time-date.
<Habbie>
oh i have :D
<nephele>
of course it does, as soon as you tell it to use another timezone
<nephele>
you just don't have to when it is already configured correctly
<OscarL>
Only Linux (In my experience) have messed with that.... even in a "live USB envirement".
<OscarL>
fuck that.
<nephele>
on the one hand, i agree, on the other we also don't make *any* special accomodations for usb "live" enviroments
<nephele>
not even having a proper concept for that...
<OscarL>
if you are a *desktop* OS. DO NOT ASSUME your users will use anything other than localtime. it is not that diffucult to understand.
<Habbie>
timezone: BIOS
<Habbie>
(i'm not really joking)
<nephele>
we can't assume anything, not even the timezone... and that means users have to configure it
<OscarL>
end users do not care for timezones... will reply with local time. assume that.
<OscarL>
if you ask for location...
<nephele>
we don't ever ask that question in either case OscarL...
<nephele>
If it's broken, use the settings, if you want to set the time manually you can do so, if you want to use network time you have to set the timezone
<OscarL>
then *you* (the OS) can figure out what the timezone should be? or ask the user for location.
janking has quit [Quit: Vision[]: i've been blurred!]
<nephele>
We can't really
<nephele>
without location data, and that is well, contentious
<nephele>
there is a patch that would use mozillas location service for like i think ip based rough lookup? but i don't like it, it contacts mozilla
<OscarL>
again... I'm mostly mad at Linuxes here. not Haiku :-)
<nephele>
I have a new debian install
<nephele>
unlike chimeraOS it can actually shut down the computer
<nephele>
I hope to put thsi advancement in technology to good use
<nephele>
kallisti5[m]: There is a lot of scraping bs going on that would be nice to remove for ressources sake, but for the spamming itself i think PulkoMandy's suggestion to just manually aprove a new users first post is fine
<OscarL>
Begasus[m]: same as with some Python recipes... can't trust inrecipe with those, as many .recipes are using $foobar, and inrecipe will not be able to match the *content* of that $foobar.
<Begasus[m]>
${targetU}_gcc$secondaryArchSuffix ... no wonder :P
<Begasus[m]>
there is a bin and static libraries ... gcc thing, not going to fiddle too much there
<Habbie>
which one means "compile once, use on every arch"? any or all?
<Begasus[m]>
well ... not upstream yet :)
<Habbie>
ag
<Habbie>
ah
<Habbie>
Packages that have no architecture-specific binaries (e.g. a Perl script) would be marked with "any"
<Begasus[m]>
"any" is for all arch's, eg can be installed on any arch
<Habbie>
yeah
<Habbie>
any for avr_libc is good
<Habbie>
that compiled stuff is not for your haiku
<Begasus[m]>
the arduine should be fixed, because it requires avr_libc$secondaryArchSuffix, which isn't available
<OscarL>
that's not how *I* interpret "any" packages.
<Habbie>
because of any?
<Begasus[m]>
I guess the "any" superseeds the secondary architecture yes
<OscarL>
any packages, for me, should be *installable*/*usable* regardless of your installed Haiku arch.
<Habbie>
yes
<Habbie>
that's what avr_libc is
<OscarL>
(not saying I'm right, ofr course)
<Begasus[m]>
right
<Begasus[m]>
then SECONDARY_ARCHITECTURES= should be dropped on avr_libc
<OscarL>
in the case of "avr_libc"... I guess the *resulting" libc is not mean to be used in Haiku, thus it might be consided "any"... but you have to compile it somehow, and that's ARCHITECTURE dependent. so it might not be "any" at all?
<OscarL>
as in... I don't care if Haiku 32 or 64 bits produce "the same resulting avr_libc"... as .hpkg... those are definitively not "any"?
<Begasus[m]>
produced binaries/libraries shouldn't be in "any" package also imho
xet7_ has joined #haiku
<Begasus[m]>
even if not directly visible as it is in this case?
<OscarL>
IMO, not much different from tools producing, say, .png files. Resulting files are "any", but the .hpkg if is not.
xet7_ has quit [Remote host closed the connection]
<Habbie>
the compilation is not arch dependent
<Habbie>
the compiler just needs to be able to run on whatever your build host is
<OscarL>
<inseert default "packaging is hard" statement here>
<Begasus[m]>
well "hp avr_libc_x86" can't be build, "unsupported on target architecture"
<Habbie>
OscarL, what if the package contains -only- .png?
<OscarL>
.hpkg is any in that case. it doesn't requires anything ARCH specific.
<Habbie>
ok
xet7 has quit [Ping timeout: 480 seconds]
<Habbie>
then avr_libc is any :)
<OscarL>
thus my <packaging is hard> statement :-P
<Habbie>
debian:
<Habbie>
gcc-avr/testing 1:14.2.0-2 amd64
<Habbie>
avr-libc/testing 1:2.2.1-1 all
<Begasus[m]>
me is still not conviced :)
<Habbie>
(i think their 'all' is our 'any')
<Habbie>
Begasus[m], can i help?
<Begasus[m]>
trying a build for _x86 atm Habbie
<Begasus[m]>
just can't wrap my head around this, the package provides binary/libraries/headers, feels strange those could be "any" arch
mmu_man has quit [Ping timeout: 480 seconds]
<Habbie>
i get that
<Habbie>
and they're not
<Habbie>
but they're not for haiku
<Habbie>
the .png example really fits here
<Begasus[m]>
well it's used/required for at least one package which is reported in the buildmaster report.txt
<OscarL>
Habbie: re: ".png only package" vs avr-libc... the former is to be "consumed" by "any" Haiku arch, while the latter can't. Does that distinction makes more sense?
<Habbie>
OscarL, that distinction makes sense, but does not apply here. the latter is to be consumed by any haiku arch too.
<FreeFull>
Is there any way to change the LCD subpixel orientation?
* Begasus[m]
is getting some gcc build flashbacks ...
<Begasus[m]>
°_0
<OscarL>
as in... "use avr-libc to create a different binary for whatever system...". <packaging is hard>^2
<Habbie>
the libraries in avr-libc target exactly one system, which is not a haiku system
<Begasus[m]>
maybe we can just let PulkoMandy fix it :P
* Begasus[m]
ducks
<OscarL>
Begasus[m]: isn't that why Debian used (still does?) to reject packages without an active maitainer? :-D
<OscarL>
just saying... Debian is certainly onto something with its "you want this? you better fix it if something breaks, or we drop it".
<Begasus[m]>
quick fix would probably be remove the seconddaryArchSuffix for avr_libc in arduino
<PulkoMandy>
you want me to make avr-libc an any package? Sounds doable
<Begasus[m]>
that's not the problem, that already works PulkoMandy :)
<Begasus[m]>
requires "avr_libc_x86" of package "arduino_x86-1.6.1-1" could not be resolved
<PulkoMandy>
ah, yes, the secondary arch suffix can probably be removed there then
<PulkoMandy>
I don't use the Arduino things myself
<Begasus[m]>
probably saves a lot of headache for now :)
<PulkoMandy>
I think it's the right thing to do, and we missed it when making avr_libc an any package
<Begasus[m]>
OK, plan then, make avr_libc trully "any" arch, and remove the suffix in arduino for it
<Habbie>
+1
<nephele>
"or you can be smarter like Nephele and batch it instead of doing it one by one" That goes with the saying, work smarter, not harder xD
<Begasus[m]>
I "think" the issue only popped up after the latest changes to "any" packages, the requirement in arduino hasn't changed since the start
<Begasus[m]>
Error: problem 1: package openjdk24_default-24.0.0.1-1 conflicts with openjdk8_default provided by openjdk8_default-1.8.u442_b00-1
<Begasus[m]>
bah, old openjdk .....
ThinkPadR40Fox has joined #haiku
<OscarL>
re: _default packages/provides... each .recipe being to "known" every other possible conflicting package is far from ideal.
<ThinkPadR40Fox>
Hello everyone and good afternoon
<Begasus[m]>
Hi ThinkPadR40Fox
<ThinkPadR40Fox>
How's everyone doing?
<Begasus[m]>
going nuts here, aside from that, not too bad :)
<ThinkPadR40Fox>
I see
<bjorkintosh>
Begasus[m]: why are you going nuts there?
<ThinkPadR40Fox>
That's good that you're doing not too bad, tho. I'm doing fine, just tired and sleepy, I have slept in and woke up not too long ago (it's 16:45 for me rn)
<Begasus[m]>
bjorkintosh: catch up log :)
<OscarL>
I kinda thinkg that no package should declare itself to be the "_default" one ever (as in.. all packages are able to be installed side-by-side, with the system providing some way to setting the "default" one, outside of packaging constraints)
Skipp_OSX has joined #haiku
<nephele>
_default is usefull to me, like for openjdk
* bjorkintosh
goes back.
<nephele>
but there the _default one iirc only provides the default symlink, pulling in the "normal" one
<bjorkintosh>
ah AVR
<ThinkPadR40Fox>
Welcome in, Skipp_OSX
<OscarL>
useful, sure. correct? not sure.
<nephele>
build a jar catapult to execute jar files ;)
<OscarL>
nephele: I did pushed a PR for "selectable default Python interpreter" (only to discover that that was basically what OpenJDK packages already did :-P)
<OscarL>
still not convinced that it is the right way to to things, in particular, because it forces each .recipe to be aware of all the rest of available versions, or be broken if it is not.
<OscarL>
thus my pondering if a "select default version for X package" (via symlinks, most likely) is not just simply a better alternative.
<nekobot>
[haiku/haiku] 812cf76fbf1f - Interface kit: Be explicit about text color for DrawLabel
<OscarL>
(as in... select a defailt one... but not by installing a _default .hpkg file, but via calling some other system wide script/system)
<OscarL>
what's called in Debian? select-alternatives or something like that?
<ThinkPadR40Fox>
Also, just a question. The official minimum system requirements specify that it needs at least a Pentium CPU. My question now is, which Pentium class CPU is the bare bones minimum to run Haiku?
<OscarL>
ThinkPadR40Fox: if not specified, I would assume a P5 at 60 MHz?
<ThinkPadR40Fox>
I know that Haiku can run on Pentium III-class CPUs (such as the Pentium M, also known as the P6 architecture)
<ThinkPadR40Fox>
I see
<Skipp_OSX>
It's going to be very slow on an OG Pentium, and you'd need to have at least 256MiB of RAM.
<ThinkPadR40Fox>
384*
<ThinkPadR40Fox>
I tried 256MiB, Haiku doesn't like that
<ThinkPadR40Fox>
(at least R1/Beta5 32-bit)
<OscarL>
ThinkPadR40Fox: if you find a Pentium where it doens't works... should file a bug report so at least the minumun requirements get updated :-)
<ThinkPadR40Fox>
Yea
<ThinkPadR40Fox>
My oldest system that I own right now is my ThinkPad R40 (from which I'm chatting here rn), and it has a Pentium M (P6), so that works
<Skipp_OSX>
R1B5 barely boots on 256mb we've done improvements to that in nightlies, but 256mb is bare minimum just to boot.
<FreeFull>
I have a working install of Haiku inside 86box, emulating a Pentium II
<Skipp_OSX>
I have a P233 with 512MB of RAM I could try it on
<FreeFull>
It's slow but functional
<ThinkPadR40Fox>
Even tho recommended system specs are Pentium 4 as for the CPU, Haiku runs decently well on this Pentium M 1.3GHz
<ThinkPadR40Fox>
I see
* OscarL
remembers running BeOS on an AMD K5 PR133 (100 MHz) with 16 MB of RAM. ran circles around Win98, after installing a UniVBE TSR for VESA 2.0 support :-D.
<ThinkPadR40Fox>
Damn-
<OscarL>
ThinkPadR40Fox: nightlies (despite some "fat" due to debugging stuff) should be more "lean" regarding RAM usage.
<nekobot>
• Begasus (d840d5b1): avr_libc, this is any architecture, can't use SECONDARY_ARCHITECTURES (#12669)
<Habbie>
nice
<OscarL>
waddlesplash: "git fetch ssh://OscarL@git.haiku-os.org/haiku refs/changes/31/9531/7 && git checkout -b change-9531 FETCH_HEAD" should be enough to get said changes and parents, right?
<waddlesplash>
mm, I think so? I don't usually use that mechanism to download changes
<OscarL>
k
<OscarL>
seems that got me 3 changes..., all kernel/block_cache related, sounds about right.
<nephele>
faster git status sounds great
* OscarL
using an HDD for a couple of years would be pleased :-D
<nephele>
git status takes way too much time from webkit dev
<nephele>
i'm already employing the usual assortions of tricks to go status -uno Source/ and stuff :)
<waddlesplash>
the remaining bottleneck I need to try and fix is the entry cache
<waddlesplash>
I have one commit in that stack for it but it makes little difference
<waddlesplash>
need to do some more experiments to try and reduce lock contention there too
<waddlesplash>
we're getting to the point where we're probably going to need to import some "atomic hashtable" or something like that
<OscarL>
k, let's fire up a build (on the N4020 netboot, on a VM, so this will take a while).
<nephele>
for what do you need an atomic hashtable? or is that just in the sense of a faster implementation compared to what we are doing now?
<waddlesplash>
it avoids locks
<waddlesplash>
most of these changes I have been working on are about reducing lock contention
<waddlesplash>
the entry cache is almost entirely down to lock contention during 'garbage collection' cycles
* OscarL
looked up atomic hashtables. lock-free. cool.
<OscarL>
waddlesplash: just a comment. ran the equivalent to "dd if=/dev/sda of=/dev/null bs=1M count=1024 status=progress" in both Haiku and Linux (for several "bs=X" sizes") and repeated runs. On an SSD via USB adapter.
<OscarL>
Noticed some weird fluctuations in speed in Haiku, thus why I tested Linux. Seems the SSD is just trash-cheap, but in any case... repeated runs were way faster on Linux.
<OscarL>
as in top speed in Haiku was around say 200 MB/s, vs 800 MB/s (once the data was cached).
<OscarL>
lows were bad on both, thus why I blame the "el cheapo" SSD :-D
<nephele>
maybe getting a faster ssd for my haiku is the answer, the other pc has one that does 11GB/S or something.... maybe that would be fast enough for webkit
<OscarL>
nephele: only if your CPU is fast enough... down here... SSD helped a lot while unpacking/deleting stuff, but CPU still way too slow while compiling :-P
<nephele>
my cpu is fast enough, but for stuff like git status and the like it could be an improvement
<nephele>
ideally those are tools i could use almost realtime, but currently have to wait quite a while even for single invocations
ThinkPadR40Fox has quit [Ping timeout: 480 seconds]
<OscarL>
I wish RAMFS and/or ramdisk were a bit less buggy. Should probably try to come up with decent enough tickets for those.
<nephele>
Well, haiku is nice, even in beta :P
<nephele>
just imagine what haiku release will be like
<OscarL>
(RAMFS is getting better, still have some differences in behaviour vs BFS)
<OscarL>
ramdisk... still manage to KDL that one last I've tried.
<OscarL>
nephele: Haiku was very nice for me even in 2005, when I ran it in bare metal, even without an app_server :-D. I'm "sold" already :-P
<OscarL>
"src/bin/listimage.c:41:31" warns about format "%u". phschafft would surely frown. ;-P
<OscarL>
Seems like a B_PRId32 should be B_PRIu32 instead?
mmu_man has joined #haiku
<OscarL>
If I were to tackle several compile warnings at once... would it make sense to group/submit them in a "per warning type" fashion? (say... tackle most/all the "comparing ints of differnet signedness" together)
<nephele>
sure, whatever is easiest for you
<nephele>
there were some examples of people fixing all warnings in $component for -WError for example
<OscarL>
alright, thanks. will probably attempt one of those next time I do a full build (if I get the Phenom II X4 working again well enough).
OscarL has quit [Remote host closed the connection]
<nekobot>
• Begasus (4e0ce8f3): kpublictransport_kf6, bump to 25.04.3 (#12675)
<dodo75>
yep the open port for Tracker is releated with NFS share... When I mount an NFS share and then open folders on that share, then a port is open for Tracker... a feature or a bug... !?
<Habbie>
boo, i forgot Pe does not auto save when it loses focus
<Habbie>
so now i have a haiku with native resolution but no working brightness slider ;)
<nephele>
i know the feeling
<Habbie>
<me> jam
<Habbie>
10 minutes pass
<Habbie>
<me> dd
<Habbie>
10 seconds pass
<Habbie>
<me> shutdown
<Habbie>
<Pe> did you want to save this or nah
<nephele>
i even patched it to get brightness, but managed to destroy my laptop beforei ever got the patch working
<Habbie>
oh, i had working brightness before today's edit :D
<Habbie>
i just moved some defines around and saved the .h but not the .cpp
<nephele>
anarchos finished the patch though :)
<Habbie>
nice
shrimpPaste has joined #haiku
shrimpPaste is now known as bergamot
<OscarL>
Habbie: I'm re-reading your intel_extreme.h change. Yeah, instead of re-defining that INTEL_PCH_CNP_LP_DEVICE_ID, you should define a new one, and add a "case INTEL_PCH_CNP_LP_DEVICE_ID" in driver.cpp's detect_intel_pch()
<Habbie>
i now have INTEL_PCH_CNP_LP_DEVICE_ID2, with a comment
<OscarL>
re: codenames... I find Intel's to be kinda insane.
<Habbie>
OscarL, HD 500, sounds right
<nephele>
chromebooks seems like a e-waste construction to me
<nephele>
it's nice that you can use it with haiku though
<Skipp_OSX>
they're most for schools that need cheap laptops and don't care about other stuff
<Habbie>
OscarL, but Cannon Lake for the PCH
diver has quit [Quit: Leaving.]
<Habbie>
uh. formally also apollo
diver has joined #haiku
diver has quit []
diver has joined #haiku
<Habbie>
guess i'm adding a category
diver has quit []
diver has joined #haiku
janking has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
<OscarL>
For my Gemini Lake (Celeron N4020), we just return INTEL_PCH_CNP in that switch (otherwise we lose brightness control :-D)
diver has quit []
diver has joined #haiku
<Habbie>
OscarL, ah, i see there's prior art for ... as i type this i see your line
<Habbie>
yes
<Habbie>
so i'm logging Apollo and returning CNP
diver has quit []
<OscarL>
exactly.
diver has joined #haiku
<Habbie>
let's update pci.ids while i'm here
diver has quit []
diver has joined #haiku
diver has quit []
<Habbie>
oh 5a85 is already in there
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
* OscarL
slaps diver's IRC client.
diver has quit []
* Habbie
builds haiku again
diver has joined #haiku
janking has quit [Quit: Vision[]: i've been blurred!]
diver has quit []
diver has joined #haiku
<nephele>
maybe i should do some webkit2...
diver has quit []
diver has joined #haiku
<bergamot>
I'm still relatively new to programming compared to some but I'm thinking of trying to do what I can to get a port of Pure Data working in Haiku
diver has quit []
diver has joined #haiku
<Habbie>
bergamot, oh interesting
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
<bergamot>
A new version recently just came out and it seems like it'd be a fun piece of software to have in the haiku repos
diver has quit []
diver has joined #haiku
<Habbie>
definitely
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
<OscarL>
diver... your client is misbehaving.
diver has quit []
<Habbie>
they most likely won't read that
diver has joined #haiku
<OscarL>
yeah... hoping to sound a bit polite before asking for someone to kick him :-P
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
* OscarL
can't hide connects/disconnects on this client :-/
<Habbie>
OscarL, love the feedback, will have a look
<nephele>
what dns problem?
<nephele>
maybe habbie can help you *ducks*
diver has quit []
diver has joined #haiku
<bergamot>
It recognized my card and network but couldn't connect
<nephele>
why do you think that is a dns problem?
diver has quit []
diver has joined #haiku
<bergamot>
because the browser didn't work even when it showed being connected to the right network or something similar
diver has quit []
<bergamot>
lemme find the error
diver has joined #haiku
<OscarL>
Habbie: I'd place INTEL_PCH_APL_LP_DEVICE_IDright before the INTEL_PCH_APL_LP_DEVICE_ID, for example
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
<OscarL>
**err before the INTEL_PCH_GMP_DEVICE_ID (GeminiLake is HD 600, for reference)
diver has joined #haiku
diver has quit []
<bergamot>
it says configuring, then no link
diver has joined #haiku
<nephele>
that doesn't sound related to DNS
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
<OscarL>
bergamot: some wifi drivers can be very picky. Have one that refused to connect to my router, but has no issues connecting to my phone's hotspot, for example.
diver has joined #haiku
diver has quit []
diver has joined #haiku
diver has quit []
diver has joined #haiku
<OscarL>
once in a blue moon... it would connect to the router, but next day it wouldn't anymore. ¯\_(ツ)_/¯
diver has quit []
diver has joined #haiku
<nephele>
I tried debugging a router this weekend that would refuse to give out ipv4 adresses
<OscarL>
these "mobile" chips are oddballs, based on *mostly* on Kaby Lake, but with some minor updates from newer parts (at least that's my understanding).
<OscarL>
in any case... ordering is just cosmetics.
bergamot has joined #haiku
diver has quit []
diver has joined #haiku
<Habbie>
yeah, but some sensible grouping makes sense
<Habbie>
and now i'm next to the other pretend kabys
<Habbie>
Broxton was famously 'cancelled' but still lives on as Apollolake
<Habbie>
ah!
<OscarL>
HD 500 --> ApolloLake GT1. HD 505 -> ApolloLake GT1.5
<OscarL>
(considering the core config: 96:12:2 vs 144:18:3)
<Habbie>
right
<OscarL>
I'd probably add a line for the HD505 (0x5A84), even if untested... it is more than likely to work fine.
<Habbie>
will do
janking has joined #haiku
<Habbie>
OscarL, reload :)
<Habbie>
nephele, not kernel module, but maybe looks like firmware, yes
<OscarL>
could drop the broxton reference in commit message. Will let others nit pick further :-P. Thanks for the changeset Habbie.
<nephele>
well its checking the modprobe dir for some reason
<Habbie>
OscarL, yeah makes sense now
<Habbie>
nephele, right, but the modprobes appear to just be settings for existing kernel drivers
<Habbie>
OscarL, last push (still transmitting) and then i'll wait for reviewers :)
<Habbie>
ohh my previous patch got merged
<nephele>
Habbie: i'll tell OscarL to review your patch :P
<Habbie>
ahahahaha
* Habbie
does another build just to be sure
<OscarL>
-3 just to be mean.
<Habbie>
:)
<Habbie>
nephele, anyway, i should try the audio thing on debian, and then if it works, figure out what the hell it is. if it really is "audio for all chromebooks" that would be pretty nice
<nephele>
i'm kinda excited you getting this all to work :) one less type of computer to have to meet an e-waste fate
<Habbie>
:D
<nephele>
Reminds me, i still have a tablet with debian on it, i should try updating it...
<Habbie>
i mean, haiku is not the only saviour from e-waste
<Habbie>
but yes
<nephele>
and also figure out how the hell touchscreen calibration works on linux
<OscarL>
def avs_config() (the one for Habbie's machine) seems to just unpack/copy a firmware file. do our HDA driver does any "load firmware" at all?
<nephele>
i mean, basically everything works except for the touchscreen
<nephele>
the RAM is a little low trying to run gnome, but other than that... even hdmi out works. Just that it's barely useable as a tablet without a working touchscreen
<nephele>
i only need to calibrate it somehow
<nephele>
if i could figure that out maybe i'd use the thing
<nephele>
already get much better battery life on it than windows factory advertises xD
<Habbie>
neat
<Habbie>
i'm unplugging power now
<Habbie>
haiku says 375 hours
<Habbie>
oh 24 hours
<Habbie>
no wait that's the clock. 6 hours.
<nephele>
haiku on the tablet would be kinda cool, but then again, no touchscreen OS, so pretty pointless
<Habbie>
OscarL, hah, now i also see Apollo Lake GT1 in Screen prefs, of course :)
<OscarL>
:-)
Skipp_OSX has joined #haiku
<OscarL>
I guess that as those are user-facing strings... using the device names would have been better than the codenames, but I ain't going to change all that in the intel_extreme driver :-D
<Habbie>
hehe
<nephele>
that was also one of the things that was really nice to be able to drag & drop from the preferences
<nephele>
i forgot to mention it in my email
<Habbie>
what thing?
<nephele>
the identification of the screen/gpu
<nephele>
in screen prefs
<Habbie>
ah right
<Skipp_OSX>
I wanted to add GPU to sys info but nooooooooooooooooo
<Skipp_OSX>
Why would anyone want to see their GPU in your list of system information?
<OscarL>
AboutSystem info layout is a bit wack, IMO too. but... "bikesheding".
<Skipp_OSX>
some people don't like the info being in the label
<nephele>
we can bikeshed sure... system runtime display is a waste of energy ;)
<Skipp_OSX>
you're probably right there
<Skipp_OSX>
but BeOS did it so we do
<nephele>
I'm often hearing "BeOS did it" but usally only when people discuss things they don't like...
<Skipp_OSX>
only when I'm trying to put a feature from BeOS back in...
<nephele>
heh :)
janking has quit [Quit: Vision[]: i've been blurred!]
dcro has quit [Ping timeout: 480 seconds]
nephele has quit [Quit: Vision[]: i've been blurred!]