ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa>
GenXML question, if you have a helper function that's only needed on certain arches, is it better to #if ARCH it, or mark it UNUSED?
<alyssa>
(To quiet -Wunused-functions)
<alyssa>
Kayden: ^
<Kayden>
both are good
<Kayden>
I like UNUSED if it's something fairly simple, it just isn't needed
<Kayden>
if it's something totally specific to one gen, ifdef can be good too
<Kayden>
(thinking...if the helper queries some info, and the other gens just don't -need that-, then UNUSED...if it's some totally HW specific thing, ifdef)
<Kayden>
ah
<Kayden>
sometimes I also ifdef out the insides of functions
<Kayden>
and mark it UNUSED
<Kayden>
that way the callers don't need to ifdef, too
<Kayden>
I'd say do whatever seems the most natural to you :)
<alyssa>
Okey
<alyssa>
I'm not used to so much #ifdef :-p
<alyssa>
Thanks :)
<Kayden>
Yeah, it takes a bit of getting used to :(
<alyssa>
OTOH I do like that a huge amount of copypaste and extra indentation levels go away
<alyssa>
GenXML is compiler-assisted copypaste but still
<Kayden>
Yep. In the end, it does end up being a lot less duplicated crap
<Kayden>
but there's definitely some artistic taste in "I should really just ifdef this whole function" vs ifdef'ing pieces of it
<Kayden>
one of my favorite pieces is src/mesa/drivers/dri/i965/genX_state_upload.c:1166
<Kayden>
where I have the same code able to pack into 3 different hardware structs via the use of typedef XD
<Kayden>
because they all have the same fields, they just keep moving them all over the place
<alyssa>
Heh
<Kayden>
we also have a few cases of things moving between registers, so we just #ifdef #define WOTS_IT_CALLED REG1 #else #define WOTS_IT_CALLED REG2 #endif
<Kayden>
that way things can match the actual docs but the code doesn't have to get pointlessly duplicated
<alyssa>
Nod
tursulin has quit [Read error: Connection reset by peer]
<Kayden>
of course, if you're RE'ing and naming things whatever you want, then ... :D
<alyssa>
Benefits of not having actual docs ;D
<zmike>
#define MY_FIRST_REGISTER 1
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
Lightkey has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
gpoo has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
sdutt_ has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gpoo has quit [Ping timeout: 480 seconds]
gpoo has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
boistordu has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
anujp has joined #dri-devel
xcube has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Company has quit [Read error: Connection reset by peer]
anujp has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
tzimmermann has joined #dri-devel
itoral has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
mlankhorst has joined #dri-devel
Hi-Angel has joined #dri-devel
tobiasjakobi has joined #dri-devel
Anorelsan has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
aravind has joined #dri-devel
ced117_ has joined #dri-devel
danvet has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<tzimmermann>
danvet, airlied, there are still patches in -misc-fixes from last cycle. i'd send them now. and for the -rc1 update, can you forward drm-fixes, so i can backmerge?
frieder has joined #dri-devel
<danvet>
mripard, ^^ if you miss the merge window cut-off make sure your last -fixes lands in the merge window pull request and doesn't get lost
<danvet>
tzimmermann, pushed drm-fixes to -rc1
<danvet>
thx for taking care of this
<airlied>
danvet: I pushed fixes/next to rc1 already I thought
<danvet>
airlied, indeed
<danvet>
or at least git says it's up-to-date now
* danvet
didn't look that closely
Ahuj has joined #dri-devel
rasterman has joined #dri-devel
<MrCooper>
karolherbst: yay qemu
<tzimmermann>
danvet, can i delete tags from drm-misc?
pochu has joined #dri-devel
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
mlankhorst has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
* icecream95
thinks there might be a bug around handling of LTO
<icecream95>
$ ls -sh src/gallium/targets/dri/libgallium_dri.so
<icecream95>
I guess it would help if I used the right linker (I set /bin/ld -> ld.lld)
frieder has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
thelounge78 is now known as alatiera
<karolherbst>
MrCooper: I doubt it's a qemu issue though :D on x86 it takes like 3 seconds
<karolherbst>
I think it's just broken on s390x and it loops infinitly
<MrCooper>
doubtful
<MrCooper>
llvmpipe may hit some SIMD code which is expensive to emulate
<MrCooper>
I think these tests are pretty slow for other archs via qemu as well
<karolherbst>
I don't think so, because those tests didn't timeout earlier. My assumption is, that we changed something in the format code and the code can't deal with it... but I can take a loop and verify :)
<MrCooper>
earlier when? qemu was upgraded from 3.1 to 5.2 on the CI runners a while ago
<karolherbst>
locally
<karolherbst>
at some point
camus has joined #dri-devel
<pq>
tzimmermann, deleting (or changing) git tags is not a thing. The deletion does not propagate to anyone who already saw the tag.
<danvet>
tzimmermann, s/severla/several/ in your vgem patch
<danvet>
if you haven't pushed it out yet
<tzimmermann>
pq, i always git-fetch with --prune. should delete the tag. but it doesn't matter anyway. i used the existing tag for the pull mail
<tzimmermann>
danvet, thanks
camus1 has quit [Ping timeout: 480 seconds]
sravn has quit [Ping timeout: 480 seconds]
<pq>
tzimmermann, most people don't do that I would think, and you would need to use --prune-tags for tags. And will lose your local tags.
sravn has joined #dri-devel
sravn_ has joined #dri-devel
sravn has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<pq>
What should a KMS device be displaying when there is no fbcon on it, and the last KMS client quits?
<pcercuei>
it should turn the hardware OFF, no?
<emersion>
it should keep displaying the last frame?
flacks has quit [Quit: Quitter]
<emersion>
(required for the so-called "flicker-free boot experience")
<pq>
AMD on 5.10.0 kernel from Debian Bullseye shows a stripey pattern. Maybe unused memory. :-)
<pq>
I wonder if I'm blinded once I get Weston to turn on HDR on that...
flacks has joined #dri-devel
iive has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
Company has joined #dri-devel
phomes has quit [Quit: Page closed]
<tzimmermann>
danvet, airlied, there are still patches left in drm-misc-next-fixes. do you want the PR against drm-next or drm-fixes ?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Simon_ has joined #dri-devel
Peste_Bubonica has joined #dri-devel
Simon_ has quit [Remote host closed the connection]
nirmoy has joined #dri-devel
vivijim has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
sdutt has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<bnieuwenhuizen>
jekstrand: I downgraded my remote for the main repo to use https, so I can't make that mistake
<jekstrand>
bnieuwenhuizen: I probably should delete my "public" remote, honestly.
<jekstrand>
I occasionally have to use it to do maintainery things but it's been quite a while since I actually needed it.
<jekstrand>
karolherbst: Does the nouveau GLSL IR back-end still exist or is nouveau all NIR these days?
heat has joined #dri-devel
<karolherbst>
jekstrand: it still exists
<alyssa>
jekstrand: there's a TGSI backend
<alyssa>
i thought
<karolherbst>
ehh glsl ir?
<karolherbst>
mhhh
<karolherbst>
jekstrand: soo... the gallium driver is either tgsi or nir
<karolherbst>
_but_
<karolherbst>
we have this classic driver to pre nv30 GPUs
<karolherbst>
but those are all fixed pipeline
<karolherbst>
nv30 has its own backend consuming TGSI
<karolherbst>
and it can't do nir
<karolherbst>
nv50+ can potentially be nir
<karolherbst>
volta+ is nir only
<karolherbst>
the problem really is nv30 as it has its own compiler
urja has quit [Read error: Connection reset by peer]
<karolherbst>
well.. it's more an assembler than a real compiler
urja has joined #dri-devel
<jekstrand>
karolherbst: I was hoping to delete some compute-specific GLSL IR passes
<karolherbst>
mhhh
<karolherbst>
which ones?
<karolherbst>
at least compute is nv50+ only
<karolherbst>
so we could move bits into codegen
<jekstrand>
lower_cs_derived and lower_shared_reference
cphealy_ has joined #dri-devel
<jekstrand>
Not worth moving into nv50
<karolherbst>
mhh
<karolherbst>
we don't set PIPE_CAP_CS_DERIVED_SYSTEM_VALUES_SUPPORTED
<karolherbst>
hh wait
<jekstrand>
Oh, and lower_64bit_integer_instructions
<karolherbst>
yeah.. PIPE_CAP_CS_DERIVED_SYSTEM_VALUES_SUPPORTED is 0
<karolherbst>
jekstrand: uhhh
<karolherbst>
mhh
<karolherbst>
that 64 bit is annoying
<karolherbst>
mhh
<karolherbst>
I wish I'd have more time for all of this :(
<karolherbst>
(or have other people working on that stuff)
<jekstrand>
karolherbst: Yeah, nouveau seriously needs more devs
<karolherbst>
at least I managed to fix multithreading....
<karolherbst>
but that meant doing nothing else for a long time :(
<karolherbst>
but yeah...
cphealy has quit [Ping timeout: 482 seconds]
<karolherbst>
no good idea on how to tackle that really :/
<karolherbst>
documentation is crappy, sure.. hard to get into the topic, true, and companies hiring our devs :P
<karolherbst>
not a good starting point
<jekstrand>
Yeah
<jekstrand>
Most people who work on nouveau tend to get hired.
<karolherbst>
yeah...
<karolherbst>
I just got lucky getting hired by RH :p
<jekstrand>
Good thing RH is willing to fund it some
<karolherbst>
well.. yeah...
<karolherbst>
kind of
<jekstrand>
I said "some" :)
<karolherbst>
jekstrand: the problem is.. officially I don't work on nouveau stuff :)
<jekstrand>
RH funds it more than Nvidia does. :P
<karolherbst>
true
<karolherbst>
so.. my official responsibility is multi arch, but I do nouveau stuff, because I don't have to spend 100% of my time on multi arch :D
<karolherbst>
oh well...
<karolherbst>
I think Ben is the only one doing it for real, and then mainly hw enabelement
<karolherbst>
just the CL stuff was "special"
<karolherbst>
this just fitted into that nvidia HMM stuff, as an open source userspace impl had to be provided and so on
<karolherbst>
and I was like: okay.. I know exactly what I want to do for that: nir for nouveau and that clover spirv/nir stuff :P
<jekstrand>
Someone's got to work on realizing airlied's grand compute plans. :)
<karolherbst>
:D
<karolherbst>
yeah...
<karolherbst>
I wished I had a bit more time for that honestly
<karolherbst>
but I do care more about nouveaus graphics bits than the compute parts honeslty
<jekstrand>
I'm just glad that your work, the MSFT stuff, and my RT work all came together at the same time.
<alyssa>
"nvidia HMM stuff, as an open source userspace impl had to be provided"
<alyssa>
that's what that was about?!
<karolherbst>
alyssa: yep.. :D
<karolherbst>
funny isn't it?
<alyssa>
:V
<karolherbst>
I thought I make the best out of it :D
anujp has joined #dri-devel
<karolherbst>
which I think I managed to do :D
<karolherbst>
pierre kind of started that CL stack for nouveau by doing spirv to codegen and I was like: nah.. let's trash that approach :D
pendingchaos has quit [Quit: No Ping reply in 180 seconds.]
<alyssa>
vtntn
<karolherbst>
hey there was another idea: llvm to TGSI
<karolherbst>
:D
<alyssa>
where do you come up with these ideas
pendingchaos has joined #dri-devel
<karolherbst>
this was before nir even existed
<karolherbst>
like 2016?
<karolherbst>
or so
<karolherbst>
ehh
<karolherbst>
I think nir was already there
<karolherbst>
but...
<karolherbst>
it was all messy at that time
<karolherbst>
and every path meant a lot of work
<karolherbst>
oh well... doesn't matter :D
<karolherbst>
I think I made not the worst choice here :p
<marex>
hey, I was wondering about the kernel display pipeline design and backlight handling
<marex>
so when the pipeline comes up, the backlight is turned ON first thing, and then the scanout engine starts pushing data out (e.g. on DPI)
<marex>
but that might lead to flicker on some panels which expect data available before backlight is enabled
<marex>
is there any sane way to swap the order of enablement ?
<marex>
i.e. data first, backlight second ; instead of ; backlight first, data second ?
cphealy_ has quit [Ping timeout: 480 seconds]
<marex>
danvet: ^
<marex>
anholt: ^
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
<danvet>
marex, that sounds like a bug somewhere
<danvet>
or maybe you're using fbdev
<danvet>
bug in the display driver I mean
<marex>
danvet: mxsfb in fact, that is drm simple-pipe derivative
<marex>
danvet: btw unrelated, but could you pick the ACKed mxsfb patches posted to dri-devel ? They are fixes and would be nice if they were not left to rot
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
<marex>
danvet: the mxsfb starts the display, which starts the backlight, first , and only then it can start scanning out data, once mxsfb is done probing
<lynxeye>
marex: Aren't you one of the maintainers of mxsfb-drm?
<marex>
lynxeye: I think it is somehow delegated to drm-misc ; are you suggesting I apply my own patches ?
<lynxeye>
Your ordering issue must be a bug in mxsfb. Normally you do panel_prepare -> do modeset to driver pixel data -> panel_enable
<lynxeye>
Only the panel_enable enables the backlight connected to the panel.
<lynxeye>
marex: You are listed as maintainer of this driver and since it's in drm-misc, you should be able to push your own patches, once they are acked/reviewed.
sneil__ has quit []
rgallaispou1 has left #dri-devel [#dri-devel]
anujp has quit [Ping timeout: 480 seconds]
<tzimmermann>
danvet, -misc-fixes should now be ready for your patch
<marex>
lynxeye: except the backlight is enabled already during mxsfb probe
sneil has joined #dri-devel
<danvet>
marex, yeah that sounds buggy
<danvet>
marex, if you don't have drm-misc commit rights, pls apply for them
<danvet>
then get your patches acked/reviewed (cross review with someone else to get that going)
<marex>
danvet: OK, I think I need to spend some time to read through all that
<marex>
danvet: I have a fdo gitlab account, but I suspect that's not enough
cphealy has joined #dri-devel
<danvet>
marex, drm-misc is still on the old gitlab ssh account
<marex>
danvet: the old gitlab ?
<danvet>
old freedesktop infra :-)
* danvet
confused
<marex>
danvet: and what exactly does that imply for me ?
* marex
confused more
bcarvalho has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
YaLTeR[m] has joined #dri-devel
xcube has joined #dri-devel
nchery has quit [Quit: WeeChat 2.4]
<danvet>
marex, if you have a bunch of mxfsb patches merged, apply for commit rights per that link
<danvet>
and then get going
<marex>
danvet: thank you, I did read that link
mbrost has joined #dri-devel
mattrope has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
nchery has joined #dri-devel
anujp has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<marex>
danvet: oh, you mean I need to apply for "Legacy SSH accounts" ?
<danvet>
marex, yup
tzimmermann has quit [Quit: Leaving]
<vivijim>
danvet: I'm not able to push drm-intel-fixes
<vivijim>
$ dim push drm-intel-fixes -f
<vivijim>
Pushing 193 commits. Are you sure? (y/N)
<vivijim>
error: dst ref refs/heads/drm-intel-fixes receives from more than one src
<vivijim>
error: failed to push some refs to 'ssh://git.freedesktop.org/git/drm/drm-intel'
<vivijim>
any idea?
<vivijim>
I even setup a clean environment from scratch here
pochu has quit [Ping timeout: 481 seconds]
tobiasjakobi has joined #dri-devel
* vivijim
pushing with git directly
<vivijim>
oh the hooks :(
<danvet>
:-)
<danvet>
naughty vivijim naughty!
<vivijim>
:)
<vivijim>
danvet: there's something with dim and new git version that might not be right
<danvet>
2.32.0 here
<vivijim>
oh... 2.31.1 here
gouchi has joined #dri-devel
NiksDev2 has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
<vivijim>
danvet: oh, pushing with dim push-fixes works... pushing with dim push-branch drm-intel-fixes doesn't... (mind blowing)
ngcortes has joined #dri-devel
<danvet>
vivijim, wow
<danvet>
yeah that sounds funny
<vivijim>
is this why we haven't killed the aliases yet?!
<vivijim>
yeap
<danvet>
I just used dim push-branch, works here
<vivijim>
probably something with worktree?!
<danvet>
vivijim, I have no idea tbh
<vivijim>
nevermind... I will put a mental note to continue using the alias :)
<danvet>
vivijim, checking why dim is confused here would be good
<danvet>
maybe the check to deprecate the aliases got it wrong?
NiksDev2 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
<airlied>
jekstrand: I got back on the opencl wagon this week :-P
tlwoerner has quit [Read error: No route to host]
<jekstrand>
airlied: Image support soon, maybe?
<jekstrand>
\o/
<airlied>
jekstrand: starting with baseline CL 3.0, images are still messy :-P
camus has quit [Read error: Connection reset by peer]
<jekstrand>
Sure. Bigger numbers are better, right?
<airlied>
bigger numbers have more CTS? :-P
camus has joined #dri-devel
<jekstrand>
It also lets us enable features more peacemeal which is good
<airlied>
though CL CTS is the only CTS where if someone suggested a test that test every uint64_t value for each api someone would approve it
<airlied>
and someone else would say its acceptable for CTS runtime to be 20 years
<alyssa>
airlied: Crikey
<alyssa>
Testing eery 2^32 input can be reasonable. Testing eery 2^64 input never is..
<jekstrand>
Nah. You just need a big enough GPU. :)
<airlied>
alyssa: tbh testing very 2^32 isn't really smart thinking either by default
<alyssa>
jekstrand: I guess if I made a cluster of 65 of my laptops I could do it in a year..
<alyssa>
cwabbott: For what it's worth, Bifrost and newer are supposed to support bindless textures/samplers
<alyssa>
Although at a perf penalty..
<alyssa>
Also allegedly supports bindless UBOs and bindless attributes/images/varyings
<alyssa>
In our case the bindless handles would just be GPU pointers (so.. uint64_t)
<alyssa>
--wait, no, that's wrong
<alyssa>
hold on
<alyssa>
Uh. Right. Ok.
<alyssa>
Bindless on Bifrost would require allocations to all be in the bottom 38-bits of gpu a
<alyssa>
gpu va
<alyssa>
And then bindless handles would be u32's which are the pointers divided by 32-bytes
pochu has joined #dri-devel
lynxeye has joined #dri-devel
NiksDev has joined #dri-devel
<alyssa>
Notice that Bifrost sampler/texture descriptors are exactly 32-bytes, and their first 4-bits are a type field allowing hardware validation.
<alyssa>
UBOs/attrbutes/images/varyings don't have either of those properties ... you could still make it work if you aligned everything and didn't need robustness...
Peste_Bubonica has quit [Quit: Leaving]
aravind has quit []
bcarvalho has joined #dri-devel
* airlied
requests llvm commit rights
pscoe2 has joined #dri-devel
<alyssa>
airlied: 🍿
<pscoe2>
Hi mesa experts, I am getting erros while trying to compile mesa main following the ci instructions. Is this the right forum to find help?
<alyssa>
Sure, what errors?
pochu has quit [Ping timeout: 480 seconds]
<pscoe2>
The clang build runs fine but when i try to make libclc, it errors out while trying to verify llvm-as
<steev>
sources probably still needs a deb-src line though (just match to deb line)
<steev>
oh that's cool
<anholt>
I don't keep it in my environment because it's slow
<anholt>
but way better than guessing package names
<ccr>
you should be able to just copy the "deb" line(s) in /etc/apt/sources.list and change it to "deb-src" for the source packages.
<karolherbst>
anholt: doesn't work :)
jewins has quit [Quit: jewins]
<karolherbst>
well.. probably for x86, but it didn't for s390x
<karolherbst>
"function not implemented" or something
<ccr>
for dbgsyms I think you need "deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main contrib" or so, I'm on debian "testing" so you'll have to change to whatever you're on
<karolherbst>
ccr: I asked for a simple way :D
<karolherbst>
I don't want to know what I need to put in there
* ccr
shrugs :)
<karolherbst>
well.. aother distros have a "whatever_package_manager debuginfo-install $package" and you are done
<steev>
that... seems simple?
<karolherbst>
steev: it's not :)
<steev>
TIL editing a file isn't simple
<karolherbst>
steev: ... and how do I know what to put in there?
<steev>
we literally just told you
<karolherbst>
what if I have a package from "updates" and not "main"?
<ccr>
tbh, I don't know why the apt src/dbgsym repos are not set automatically at install
<karolherbst>
and it doesn't match anymore?
<steev>
then you get to pick up the pieces
<karolherbst>
ccr: yeah...
<karolherbst>
steev: I don't want do :D
<karolherbst>
hence me asking for a "simple" way
<steev>
then don't break your system
<karolherbst>
but if there is no simple way, then just tell me there isn;t :)
<karolherbst>
*isn't
<karolherbst>
I know I can pick the pieces, point was, I want something simple I can't get wrong :D
<ccr>
the #definition of "simple" may vary :P
<karolherbst>
ccr: no?
<steev>
apparently so
<karolherbst>
apt debuginf-install $whatever would be simple
<karolherbst>
everything else is stupid
<karolherbst>
:D
<karolherbst>
honestly
<steev>
that's definitely one opinion
<karolherbst>
you don't have to defend debian here....
macromorgan_ has quit [Read error: Connection reset by peer]
<steev>
apt is open source, send a pull request
<ccr>
imo there are worse things. a friend of mine uses Arch and sometimes I wonder why some things on it are so ass-backwards. but shrug.
<steev>
i'm not defending debian, i just don't see how adding a line to your sources.list is difficult
<karolherbst>
steev: right.. because I have enough time for that
macromorgan has joined #dri-devel
<karolherbst>
ccr: :D
<karolherbst>
true
<karolherbst>
steev: I explained
<steev>
realistically, it's probably already in there, and just commented out
<karolherbst>
I have not a good idea on how debian works
<steev>
you explained that you're lazy
<karolherbst>
so I don't know if I have to add 1 or 2 or 3 lines or whatever
<karolherbst>
I don't want to have to think about it at all
<karolherbst>
heck
<karolherbst>
even a "apt install debuginfo-repos" would be better
<karolherbst>
and I wouldn't be able to get this wrong
<karolherbst>
but fine.. I can't have the nice thanks...
<steev>
somehow i think you would
<karolherbst>
*thinks
<karolherbst>
,... thngs
<karolherbst>
... nvm
<ccr>
this is one of those "with power of some configurability comes slight inconvenience" things.
<karolherbst>
steev: yeah.... if you say so
<steev>
and even then, you're on s390x, and almost everything is gonna be set up for x86_64
<karolherbst>
ccr: I think this is a very stupid approach because that makes your OS silly to use, but whatever
<steev>
so at some point, you're gonna have to roll up your sleeves and learn some things
<karolherbst>
right, because there is a benefit of learning how debian does it's debug packages stuff a crappy way :)
<karolherbst>
very interesting topic
<karolherbst>
again.. you don't have to defend debian here
<steev>
well, if you're planning on debugging stuff on debian, yes, it would be helpful if you learned how to do it
<karolherbst>
well.. guess I just use a differen OS for building my development containers then...
<steev>
do what you think is best for you
<ccr>
let us know how that goes :)
<karolherbst>
probably better
boistordu has quit [Remote host closed the connection]
<steev>
karolherbst: how about this - sudo apt install debian-goodies; find-dbgsym-packages [core_path|running_pid|binary_path]
<karolherbst>
steev: I still need to add the repos by hand, wouldn't I?
<steev>
no
<steev>
dbgsym packages are in the main repo, but not all packages are built with them iirc
<karolherbst>
okay, then let me try that
<steev>
you typically need a deb-src line for the *source packages* - typically these lines are already in sources.list but commented out as most people do not need the source packages, and it just takes longer to apt update
<karolherbst>
"IPC::System::Simple required for Fatalised/autodying system() at /usr/bin/find-dbgsym-packages line 27." :)
<steev>
sounds like some perl package isn't properly dep'd on :(
<karolherbst>
yeah.. seems like it
<steev>
i have it here, but then again, i have packaging stuffs installed
<steev>
it's libipc-system-simple-perl
<karolherbst>
and I disabled recommended and suggested auto install
<karolherbst>
ahh...
<steev>
well that's why then
<karolherbst>
debian-goodies has no hard deps :)
<steev>
because it's recommended
<karolherbst>
libipc-system-simple-perl sounds like the right one
<karolherbst>
yeah... seems like that tooling can't handle that the container is x86 but has s390x packages installed :/
<karolherbst>
errors out with "not a dynamic executable" :)
<karolherbst>
I mean I used debian, because at least this bit was easy to setup and crosscompiling and everything works
<karolherbst>
just getting debug packages is for some reason painful
<karolherbst>
guess I will add those lines and see where this gets me.. I just hoped for something simple
<steev>
you may want to add :s390x to the end of whatever dbgsym package you want, so it knows to pull the correct architecture
<karolherbst>
ohh sure, but I was refering to find-dbgsym-packages not really working
<karolherbst>
well.. at least installing it does seem to work.. now let's see if gdb is happy
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
yay.. it works :)
<karolherbst>
but now I need the sources :)
<karolherbst>
at least I get a backtrace now
<karolherbst>
anyway.. thanks for your suggestions, I just hoped for something more intuitive
tobiasjakobi has quit [Remote host closed the connection]
boistordu_ex has joined #dri-devel
<dcbaker>
venemo: we usually don't have one, but we're like 19 hours away from me making the branch. Just let me know when you convince marge, I'll wait for you
Hi-Angel has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
karolherbst has quit [Remote host closed the connection]