<RP>
Saur[m]: if we really want that level of redesign, now isn't the time :( Why can't people work on this at the start of releases :/
<Saur[m]>
RP, JPEW: I like the idea of switching to the SPDX license names in `LICENSE`. However, I do not think we want to try to validate that _only_ SPDX names are used. Instead you could warn or fail if any of the old mappings are used. This is because you can add other licenses than the SPDX licenses in your own layers and to handle that we would probably have to keep `AVAILABLE_LICENSES` around, which we don't want.
<RP>
Saur[m]: true, although we may want to ensure the license is defined somewhere, maybe as accepted non spdx licenses
<RP>
Saur[m]: it also brings to mind the idea of layer specific namespace variables
<RP>
I wish we'd had time for that one but I can barely keep things holding together
<RP>
I do want to do it
<Saur[m]>
RP: Well, what worries me more is that we do a simplistic "redesign" of the licensing variables now, and then have to redo it all again to get it right (because what's currently there isn't right).
<RP>
Saur[m]: I'm kind of resigned to that now. Incrementally improve but know we'll have to do better
<Saur[m]>
On an unrelated note, totally assuming that you have not had any time to look at the problem with the missing logs, would you accept a revert of the bitbake change for now? The reason I think this is warranted is that I believe it is better with some duplicated logs than with some missing logs. I will also throw in a bugzilla issue for good measures to describe the current problem.
<RP>
Saur[m]: It regresses on case in favour of another and if I take that it encourages nobody to fix anything and destroys the test cases I was trying to build. So no.
<Saur[m]>
Well, the problem now is that there is no information in the log about what caused a failure, making it impossible to debug it. Yesterday we upgraded to Hardknott 3.3.4, which has this change, and today I was faced with an error in package_write_rpm causing one of all our products to fail. Thankfully the error was consistent so that it was possible to rerun the build with `bitbake -v` and catch what actually happened, but that is not always the
<Saur[m]>
case.
<Saur[m]>
(Oh, and I will throw in the bugzilla issue regardless as the problem needs to be documented.)
<RP>
Saur[m]: I'm stressed, tired and it is past midnight here, even later for you. I'm trying very hard not to get annoyed/frustrated. The project is struggling with people expecting me to solve all these things. I can't do it all. I'm not taking hacks reverting things like that, particularly when your incentive to fix the real issue becomes near zero and it becomes "my" problem.
<RP>
I agree it is an issue. I don't believe for a second that I'm the only person who can fix it.
<Saur[m]>
Sorry, I am really not trying to push it on you. I know you are stressed, and the situation with the variable renamings and redesign isn't helping this at all. I really wish I could do more, and do my outmost to try to improve OE-Core where possible. Unfortunately, we do not have many developers inhouse with deep OE knowledge (I am one of the few), which means a lot of my time goes to help all the other developers with their more mundane OE
<Saur[m]>
related issues.
<RP>
You're worried about the issue and would like my help with it. I get that. I just don't have enough time :( This story repeats across so many people/companies
<RP>
I'm really close to just saying that if everyone thinks they can do this better with github pull requests and linting, that the current designs of things are stupid and easy to fix, that breaking changes should just be merged and people deal with it, then I'll just step aside and let everyone get on with it. I'm clearly too old, stuck in my ways and no use to the project. People would get quite the shock if I did that :/
<Saur[m]>
Well, I for one do not want to switch to github, because I hate its code review system. If you said Gerrit on the other hand, I would be all for it. ;) (And no, unfortunately I do not expect Gerrit to ever be considered as a replacement, regardless if it is way superior when it comes to reviewing code.)
<RP>
Saur[m]: sure, but I'm getting tired of trying to discuss it over and over again and defend the decision to use email. I'm getting really tired of a number of things :(
<Saur[m]>
Well, I do agree with the decision to stick with email. I think it works great in that it allows me to see everything that happens. It allows me to skip changes in recipes I do not care about but still know that something is going on in that area. I can also happen to see something in a mail and suddenly I have reviewed something that I probably will never even use, but knowing that OE as such will be a little bit better due to it. There are some
<Saur[m]>
drawbacks compared to a deicated review system such as Gerrit (or even github), but on the whole I think it is the right choice.
* moto-timo
in the same row on the bus as RP
<moto-timo>
Tired. Just chill out please.
<RP>
Saur[m]: lets just not do the debate yet again
<RP>
Saur[m]: that isn't going to help anyone
<Saur[m]>
Sorry, was not going for a debate. I just wanted to give you some encouragement that your choice was the right one.
<moto-timo>
I don’t see anyone remembering the mass exodus from GitHub when Microsoft bought it. And then the mass exodus back from GitLab. What’s next? Do you want your project to be tied to one vendor in ten years? Twenty?
<moto-timo>
Email is relatively simple infrastructure. And I’ll shut up now.
florian has quit [Ping timeout: 240 seconds]
<moto-timo>
My internal nag alarm reminds me that the distutils classes need to get moved to meta-python. The fallout has already been dealt with in the common, high-impact layers.
* RP
tries to remember what he was doing before getting pulled into a license discussion. Something about autobuilder build fixing
<moto-timo>
Something about saving the future
<moto-timo>
Parse errors will happen when distutils classes move. Unless someone can think of a warning mechanism for ‘inherit not-here-anymore’
<RP>
moto-timo: I think meta-oe still thinks it should override oe-core so if you leave class files with errors in oe-core, people should hit those if meta-oe isn't present?
<moto-timo>
bbclass “bbfatal this has been moved to meta-python”
<moto-timo>
Slightly more helpful than a parse error
<Saur[m]>
Stick a python() { ... } around that and you're about done. :)
<RP>
moto-timo: you know we could add a mechanism for this where a missing class triggers a message defined a bit like we did for BB_RENAMED_VARIABLES
<moto-timo>
because RP really wants more anonymous Python in core. Lol
<moto-timo>
RP: better!
<Saur[m]>
Well, in a removed class it wouldn't make a difference as it is not expected to be included in the first place.
<RP>
BB_REMOVED_CLASS_MSGS[image-prelink] = "fix USER_CLASSES in your local.conf"
<moto-timo>
And all this magically by Monday! 🤣
<moto-timo>
Just kidding
<Saur[m]>
Well, I guess that is not an all bad idea... Would avoid having to keep the oldclass.bcclass file around.
<moto-timo>
I need a search engine for my search engine
<RP>
moto-timo: according to the mailing list we only do broken feature additions so please include some bugs we can fix later
<moto-timo>
\o/
<moto-timo>
Saur[m]: indeed. Wheels are turning (no pun intended)
<RP>
the nice thing for that warning is there will be a clear area in the code to check the variable and show the message so there is little overhead
<Saur[m]>
moto-timo: Well, I know (almost) nothing about eggs end wheels, but I take it from you that it's a good thing. :)
<moto-timo>
Saur[m]: it is future bullet proof promise
<Saur[m]>
Somehow I think I'll record that as famous last words. ;)
<moto-timo>
And I don’t want to be bitching about kirkstone in two years like I sometimes feel with dunfell (dunfell was a GoodThingTM)
<moto-timo>
Saur[m]: indeed. I will be buying you beers now doubt
<RP>
"AssertionError: False is not true" - No matter how many of these I fix, there are still more :(
<moto-timo>
Lol. I doubt now, but ‘no doubt’ to be certain
<Saur[m]>
moto-timo: I wish we all could come together and buy some beers. It has just been too long. :(
<moto-timo>
Extreme understatement.
<moto-timo>
I hope no one has tooling assuming eggs or egg-info. They will shortly be damned. 🔥 🔥 👿 🔥 🔥
<Saur[m]>
moto-timo: Well, sometimes you just have to break some eggs (pun totally intended). ;)
<moto-timo>
We will not have any eggs anywhere
<moto-timo>
Saur[m]: indeed! 🤣
<moto-timo>
Reinvented the wheel!
jclsn7 has quit [Quit: Ping timeout (120 seconds)]
jclsn7 has joined #yocto
<moto-timo>
Can we rename kirkstone to super secret code name “omelette”?
* moto-timo
ducks
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
tangofoxtrot has quit [Remote host closed the connection]
<zyga[m]>
RP: are there any unit tests for that logic that can be used to debug this without performing full builds?
<zyga[m]>
RP: I don't think it's dict vs clone, I could be wrong but I think the reason is elsewhere
<RP>
zyga[m]: origenv could be moved out the loop, yes. That wouldn't break it though
<zyga[m]>
* RP: are there any unit tests for that logic that can be used to debug this without performing full builds?
<RP>
the empty values thing is a concern.
<RP>
I don't know how to reprocude the issue, no unit test I know of triggers this
<RP>
It doesn't even happen reliably in full builds
<zyga[m]>
not being versed in yocto, does d.getVars return None or an empty string in case the key is missing?
<RP>
None
<zyga[m]>
so that's something that's easy to fix
<zyga[m]>
the empty values
<zyga[m]>
just test with is None
<RP>
I suspect we don't ever use empty values here
<RP>
i.e. it is a tangental issue
<RP>
tangential
<zyga[m]>
so there are other places that could be the problem
<zyga[m]>
one thing I recall
<zyga[m]>
could it be inside bb.utils.environment?
<zyga[m]>
ha, actually
<zyga[m]>
one thing that is somewhat tricky/annoying is that manipulations of the environment of the current process are racy in stdlib
<zyga[m]>
(in C stlib)
<zyga[m]>
not sure if that affects os.environ
<zyga[m]>
I bumped into this while running concurent test in my Go programs
<zyga[m]>
I ended up entirely avoiding environment changes and instead make my logic run other process with a new env block
<zyga[m]>
RP: a silly way to debug this might be to log the new environement and see what the system says next time this happens
<zyga[m]>
silly but perhaps practical
<zyga[m]>
especially for rare issues that don't reproduce easily
<zyga[m]>
it might even be logged when the key error happens
<zyga[m]>
so it would not spam users by default
florian has joined #yocto
<zyga[m]>
RP: back to your original question, ** works fine assuming that bb.utils.environment takes ** on the other side
<zyga[m]>
so, if it does, the problem must be elsewhere
florian has quit [Ping timeout: 240 seconds]
<RP>
zyga[m]: looking at the traceback, the issue is that dict(os.environ) faults whilst iterating it's own internal data. I think the only way this can happen is if the lang encoding breaks :/
<zyga[m]>
I didn't notice that
<zyga[m]>
oooh
* zyga[m]
looks at the backtrace again
pgowda_ has quit [Quit: Connection closed for inactivity]
<zyga[m]>
so the bottom of the stack is indeed in os.py
<zyga[m]>
looking at sys.getfilesystemencoding
<zyga[m]>
RP: what is LC_CTYPE set to during the build?
<zyga[m]>
"The Python UTF-8 Mode is enabled if the LC_CTYPE locale is C or POSIX at Python startup (see the PyConfig_Read() function)."
<zyga[m]>
since python 3.7 sys.getfilesystemencoding retunrs 'utf-8' in the "python utf8 mode"
<zyga[m]>
I honestly don't know what to expect now, this is in the bowels of the python stack, where things are arguably a bit complex
<zyga[m]>
assuming it is using utf8
<zyga[m]>
I don't see how we would fail on encoding
goliath has quit [Quit: SIGSEGV]
<zyga[m]>
RP:my last idea is that modifying os.environ indeed calls putenv which may end up doing stuff I remarked upon earlier (race), but I don't think this is very likely
<RP>
zyga[m]: whether it does or doesn't the question is how does os.environ's self._data become inconsistent
<RP>
it should be set to something utf-8 and should be encoding/decoding consistently
<zyga[m]>
RP: is there any chance there are concurrent usages of the environment?
<zyga[m]>
RP: one more wild idea is surrogate escapes or whatever that thing was called exactly,
<zyga[m]>
invalid thing encoding happily but upsetting on the receiving end somehow
<zyga[m]>
just wild guess
<RP>
zyga[m]: you may have an idea there actually, sstate.bbclass does put this in a ThreadPool
<zyga[m]>
!
<zyga[m]>
there's no safety against concurrent modification
<RP>
well, python is meant to have some, but...
<zyga[m]>
I meant in os._Environ
<zyga[m]>
python only guarantees so much
<zyga[m]>
for larger structures there is none
<RP>
right
<zyga[m]>
your earlier remark, about copying the whole thing as a dict might be interesting
<zyga[m]>
then you get a plain python dic
<zyga[m]>
not the more complex and fancy _Environ type
<zyga[m]>
no changes to libc environment
<zyga[m]>
and you can grab a lock (bitbake side) around access to os.environ
<RP>
We need to setup the environment correctly at the top level, then it won't need to mess around with it
<zyga[m]>
I'm on super weak network until I have a replacement link installed but I'm trying to clone bitbake to make a small patch
<RP>
This isn't as simple as a lock. It will fix some errors but not others
florian has joined #yocto
<zyga[m]>
I'm not sure if you need to modify the real environment of the python process
<zyga[m]>
but if not, you can move out of the real environment type and use a plain dict (early, with a lock)
<zyga[m]>
and then pass the simpler env dict down to whatever needs it
<zyga[m]>
IIRC python still guarantees dict modification to be atomic (for the moment)
<zyga[m]>
RP: to clarify some of my earlier comments, I cannot send mail from my work address at all, not from an environment that I cannot use for work (inside corp vpn that is disconnected from internet)
florian has quit [Ping timeout: 240 seconds]
<RP>
zyga[m]: we need to modify the environment
<zyga[m]>
the real process environment you mean?
<RP>
yes
<zyga[m]>
(vs having a modified env block to pass to subprocess)
<zyga[m]>
ok
<zyga[m]>
hmm, then that has to be guarded with some lock :/
<RP>
It says I need to login to see that paste :/
<RP>
zyga[m]: I think this is a wake up call for this code, there are likely other issues here
<RP>
Not being able to send email from work is problematic given it is how the project operates :(
<zyga[m]>
I might send it from my personal address where I have a working SMTP system I can use while on the normal internet
<RP>
zyga[m]: can you use a pastebin which doesn't require a login?
<zyga[m]>
sure, sorry, I use this one since it's the default
<zyga[m]>
(ubuntu pastebin is using this to prevent people from hosting content there and using it for attacks)
<RP>
Using a different email address like that may be a necessary workaround. Some people have trouble accessing the web too, corporate environments are tricky :(
<zyga[m]>
looking at utils.py's environment function I would really stick a lock around that clone but that's only as good as having the same lock around all the other modifications
<zyga[m]>
there are 127 references to os.environ in bitbake tree now
<RP>
yes, that does. The third patch is fine. The second patch worries me a bit as we probably don't handle empty values elsewhere well and it may be easier not to support them
<RP>
The first change should be cosmetic but I am not so keen on them in general as there is a risk of breaking things for not that much gain
<RP>
zyga[m]: the lock would fix this error but not the big picture issue of why these are being set in the first place
<zyga[m]>
RP: one more (perhaps ugly) idea is to monkey-patch os.environ with a thread safe copy
<zyga[m]>
that is, a class that hides the real value and grabs a lock around all ops
xmn has joined #yocto
<zyga[m]>
no more corrputed representation
<zyga[m]>
but not sure how that affects the fact that many threads think they own environment
<zyga[m]>
probably only a little
Vonter has quit [Ping timeout: 240 seconds]
<zyga[m]>
RP: I have a few more patches that fix typos I found while looking
<RP>
zyga[m]: as I said, this bug shows there is a higher level threading issue in sstate.bbclass so I need to focus on fixing that
<Saur[m]>
RP: If I remember correctly, you told me that there is a way to configure the PR server so that if you, e.g., make a change, build, and then revert the change, the PR server still increases the PR rather than go back to the previous PR. But I have not been able to figure out how to do that.
<RP>
Saur[m]: change prserv.db.PRData(self.dbfile, read_only=self.read_only) to prserv.db.PRData(self.dbfile, read_only=self.read_only, nohist=False)
<RP>
Saur[m]: it was at some point a config but is only a parameter now :/
<RP>
zyga[m]: I thought you said you had a personal account?
<zyga[m]>
yes but it doesn't let me send with @huawei.com account
<zyga[m]>
I just tried sending and got "5.7.1 Not authorised to send from this header address"
<zyga[m]>
I don't know what to do with that
<zyga[m]>
my personal mail is on fastmail
<RP>
zyga[m]: you can just put a From: XXX <yyy@zzz> line at the start of the mail
<RP>
the commit will apply from the yyy@zzz address
<zyga[m]>
RP: not sure if that worked, git printed tons of mail headers back on me
<zyga[m]>
result 250
<Saur[m]>
RP: No wonder I couldn't find that. I was expecting a bitbake variable PRSERV_<something> or similar. Is there any reason this is not more easily available, or is jus that no one has implemented support for it?
<RP>
Saur[m]: I think it just got lost, no good reason
<Saur[m]>
RP: Ok, then I'll see if I can implement the necessary support. Previously having the PR go backwards when revering a change was normally just a nuisance, but with the recent change that causes the build to fail also for errors has made this a bit more irritating.
<Saur[m]>
Is `PRSERV_NOHIST` ok as variable to control this?
denna[m] has joined #yocto
<RP>
Saur[m]: PRSERV_HISTORY_MODE ?
Marc51 has joined #yocto
<Saur[m]>
Works for me :)
<smurray>
Saur[m]: I think dl9pf is considering setting up a binary packagefeed for AGL, so this caught my eye. I'm guessing it's difficult to have dnf do the rollback in this situation?
rber|res has quit [Remote host closed the connection]
<RP>
I think we're not going to get any more patches until next week, which is understandable but leaves me with a master-next I can't do much with now :/
<RP>
zyga[m]: I can't see any in my email
<RP>
zyga[m]: Non-member zygmunt.krynicki@huawei.com attempted to send message "[PATCH 17/17] wget: Fix grammar "can happen"", via email
<RP>
i.e. you're not a list member
<zyga[m]>
I have to subscribe?
<RP>
zyga[m]: yes, but you can suspend mail delivery if you don't want the email
<Saur[m]>
Another thing that I have seen now and then is that the PRServer seems to forget what its been doing and goes back to 0 for all packages, causing errors like "Package version for package alsa-lib went backwards which would break package feeds (from 0:1.2.6.1-r0.4 to 0:1.2.6.1-r0.0)" for basically everything. Is this a known problem?
<RP>
Saur[m]: no
<Saur[m]>
Hmm, ok.
<Saur[m]>
I have no idea what's causing it, and have not seen any pattern to when it happens, so I don't have much to go on.
lexano has quit [Ping timeout: 240 seconds]
<zyga[m]>
RP: sent again
<zyga[m]>
I think they got through this time
<RP>
zyga[m]: they did
<zyga[m]>
RP: should I post the other three? I think you had doubts about the safety of the empty-value env items
<RP>
zyga[m]: the last one was fine
<zyga[m]>
the loop invariant one?
<RP>
yes
<zyga[m]>
k
<zyga[m]>
done
<zyga[m]>
while I can fake-send my mail via fastmail, I can only receive feedback on my work computer
<zyga[m]>
I will try to check any comments via the website
<zyga[m]>
(that's a windows machine not connected to the regular internet)
lexano has joined #yocto
<Saur[m]>
zyga[m]: Commented. ;)
<zyga[m]>
saur2000[m]: what should I do now? re-send?
<zyga[m]>
(I have no way to see my work email here, I can only look at the website)
<zyga[m]>
(I've made the changes locally)
<Saur[m]>
zyga[m]: Well, typically, if you agree with my suggested changes, you update the commit locally, generate a new patch (with an increased patch number) and send it just like you sent the first patch.
<zyga[m]>
what is an increased patch number?
<zyga[m]>
and when I send it again, do I have to refer to the earlier mail message somehow?
Marc51 has quit [Quit: Client closed]
<Saur[m]>
In the mail subject, the first patch you sent had '[PATCH]' in it. Update that to, e.g., '[PATCHv2]'. You can do that with by using `git format-patch --subject-prefix='PATCHv2' ...` when you generate the patch.
<zyga[m]>
I see, is --subject-prefix also applicable to git send-email?
<zyga[m]>
I think so
<zyga[m]>
re-sent
<Saur[m]>
Looks correct. :)
<zyga[m]>
thanks!
Tokamak has joined #yocto
<zyga[m]>
I think this may get somewhat tedious once I do any non-trivial changes
<RP>
zyga[m]: you could use a different email address and just put the From: at the start of the commit log which git will then handle correctly
<zyga[m]>
RP: I'll ask my colleagues how they handle this
<zyga[m]>
offtopic: is there anyone looking at type hints for bitbake?
lexano has quit [Ping timeout: 256 seconds]
<zyga[m]>
RP: should I start from master or master-next?
<RP>
zyga[m]: for what?
<zyga[m]>
RP: for any changes I make
* zyga[m]
is unsure about what master-next is for
<Saur[m]>
zyga[m]: master-next is typically where RP tests and verifies changes before they are integrated. It also makes it possible for the rest of us to see what is on its way in.
<zyga[m]>
aha, so it's more like the outbox while master is the inbox?
<Saur[m]>
Typically you base your work on master. Only if you are making changes that depend on other changes that are in master-next should you use that instead.
<zyga[m]>
understood
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lexano has joined #yocto
lexano has quit [Ping timeout: 240 seconds]
lexano has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
<RP>
zyga[m]: where you've changed the same file I've squashed the commits
<zyga[m]>
RP: sure
<zyga[m]>
I sorted by file to make that easier
florian has joined #yocto
florian has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
<zyga[m]>
RP: does bitbake still tries to support python 2.x?
<RP>
zyga[m]: no
<zyga[m]>
RP: I'm looking at lib/codegen, shall I send a patch that removes two python2.6 specific node visitors?
* zyga[m]
is trying to grok bitbake better
<RP>
zyga[m]: some of code there is copied from an upstream so I suspect that one can be left
<zyga[m]>
I was thinking of Source.Generator.visit_{Print,Repr}
<Saur[m]>
Minimum Python version for bitbake is currently 3.6. However, we have not started to use 3.6-features like f-strings as it makes it harder to backport code to the Dunfell LTS release.
<zyga[m]>
based on my understanding that is dead code as the corresponding AST nodes no longer exist
<zyga[m]>
RP: when you say "can be left" do you mean "can be left intact" or "can be removed"
<RP>
zyga[m]: please just leave that file alone, it is a copy of an upstream module
<Saur[m]>
RP: Hmm, now I've been looking at the PRServer code for a while, and if I read the code and comments correctly, the default is `nohist=True`, which according to the documentation, means that the server should run in a mode where the PR can never go backwards (which is what I want). However, this does not match my experience if I do a build, make a change, do a build, revert the change, do a build as this leads to a PR going backwards. If I change
<Saur[m]>
it to `nohist=False`, the behavior remains the same... So it seems my quest for an option to make the PRServer do what I want has turned into a quest to find out why it is not doing what it is expected to do. Back to debugging...
<RP>
Saur[m]: you can see the nohist True/False codepaths and in theory this is what those did
<RP>
Saur[m]: I did wonder why it was defaulting to True and not working :/
Vonter has joined #yocto
<RP>
Saur[m]: you know as much as I do on this at this point. It once did work
<Saur[m]>
RP: Yeah, that's what I assumed. Will have to dig through 10 years of changes... But first, dinner.
<JaMa>
Saur[m]: good point, I was just looking which BSD-* in common-licenses and completely overlooked this removed part, thanks
<JaMa>
which looks the closest
goliath has quit [Quit: SIGSEGV]
bps has quit [Ping timeout: 272 seconds]
bps has joined #yocto
bps has joined #yocto
<RP>
JaMa: it does look like some BSD should be listed there
<RP>
JaMa: what do the other distros like debian do?
<zyga[m]>
RP: a few more patches, not sure if you like type annotations, I sent an rfc to test the waters
<zyga[m]>
RP: also one more typo and a small tweak
<zyga[m]>
RP: from an outsider pov it would be good to drop a comment to files imported from other places, to make it clear that changes there are undesired
<RP>
zyga[m]: We are not adding type annotations to bitbake
Tokamak has joined #yocto
<RP>
zyga[m]: I suspect simplediff comes from an external source too, similar to codegen :/
<zyga[m]>
RP: oh, too bad, I think they are very helpful
<zyga[m]>
RP: that's fine, it's just an RFC
<zyga[m]>
RP: may I ask why type annotations were rejected earlier?
<RP>
zyga[m]: it is not standard python, it looks ugly and I don't think it aids readability at all, I think it makes it worse
<zyga[m]>
RP: what do you mean it is not standard python?
<zyga[m]>
It's not only standard python but the semantics have now been standardized and typing has been added to stdlib
<zyga[m]>
it's not about readability, it's about machine verification in large codebases
<Saur[m]>
RP: Where does log messages from the PR Server end up? In the normal bitbake log, or somewhere else?
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<RP>
zyga[m]: I don't see wide usage of that kind of typing in general python code and I'm not convinced it will help much of what bitbake does
<RP>
zyga[m]: I do care a lot more about how readable the code is
<RP>
Saur[m]: to be honest I don't remember
<RP>
why am I still here on a weekend :(
<Saur[m]>
Ok, no problem, I'll figure it out. ;)
<zyga[m]>
RP: if that's the final decision I have no other things to convince you, bitbake is a huge python application and having type checking would definitely help to spot elusive and rare mistakes but it's certainly a change in how the code looks like. It serves as additional documentation but I guess not everyone likes it.
<RP>
zyga[m]: our time is better spent elsewhere
<RP>
sakoman: unfortunately I suspect dunfell is open to the race I'm trying to fix in master but in dunfell it is through the env changes in bb.utils.export_proxies :/
<RP>
sakoman: caused by the threading in sstate.bbclass
<RP>
sakoman: it less likely in dunfell on the autobuilder due to the lack of proxy vars in use there
florian has quit [Ping timeout: 240 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bps has quit [Ping timeout: 272 seconds]
goliath has joined #yocto
<RP>
Saur[m]: I did have a look at that logging change. If I split the tests into 16 originals and 4 from you, reverting that change gives 13 pass 7 failures compared to 19 pass and 1 fail before reverting it :/
<RP>
sorry, 12 original and 8 from you
florian has joined #yocto
sakoman has quit [Quit: Leaving.]
<Saur[m]>
RP: Yes, I am aware that reverting the change will bring back duplicated logs in a number of cases, and it is definitely not what I really want. However, that one case where there now is no log is a serious problem when something does go wrong. That said, if you happen to have some idea on how to fix it then I am all ears. Otherwise leave it be for now and I'll look at it. It's no real hurry since we would not be able to fix it in time for
<Saur[m]>
Honister 3.4.2 anyway (as I believe it is already in QA).
<Saur[m]>
I have a strict no-fork policy for Yocto/OE, and we only use the official Yocto releases, so I have until 3.4.3 to fix it. Until then we will have to make do with `bitbake -v`.
amitk has quit [Ping timeout: 272 seconds]
florian has quit [Ping timeout: 256 seconds]
davidinux1 has quit [Ping timeout: 256 seconds]
davidinux1 has joined #yocto
sakoman has joined #yocto
<Saur[m]>
Ok, I've looked into the prserver now, and it is not to blame. It is doing what it is supposed to, based on some extra logging I added (I found the logs in `cache/prserv.log`). It is probably the sstate cache that is too good at what it does.
<Saur[m]>
The typical use case is `devtool modify foo`, modify foo and build it a couple of times, `devtool reset foo`, build foo and the PR goes backwards because the sstate is now back where it was before the `devtool modify` and since externalsrc is no longer active, there is nothing that invalidates the cache for foo and thus nothing will cause a new PR to be requested.
<Saur[m]>
Oh well, at least I now know a bit more about the PRServer.