[Testing Update] 2019-12-08 - Systemd 242.153-2, Pamac 9.2, Linux-Firmware

:astonished:

Have you seen how many commits there are to go through? Literally thousands and that’s not even a joke.

Guess we know what @kdemeoz is doing for the next six months :rofl:

4 Likes

You seem like the kind of chap to already know this, but for anyone who doesn't: git bisect splits the amount in half with each test. You'd normally need to test 10-11 commits tops to find the "bad" one.

Humour not something you’re familiar with I see :wink:

2 Likes

Probably coz [you & i know that] we use the correct number & type of vowels. in Straya, which might confuse some...
:wink:

2 Likes

I am confident that the fault lies with sustemd not firetools. The timing gives it away IMO. Firetools version has been unchanged for months, & has worked perfectly fine with varying systemd versions... until the one i reported. Downgrading systemd back to that older series entirely eliminates the symptoms again. Re-upgrading systemd instantly initiates the symptoms again. If the scenario were reversed clearly i would be pointing the finger at firetools not systemd.

Exactamundo Potsie :grin:

Actually I'm quite confident it is the other way around. :wink:
Unfortunately software sometimes can't keep backwards compatibility forever and there are breaking changes introduced. Now if another app relies on that software, it has to adapt...
Nothing prevents you from filing a bug report with systemd though, so give it a try :slight_smile:

Anyways, looking at firetools github, there were several commits after the last release version (also one which is named "fix fstats netfilter" and if I remember correctly it was something related to fstats that caused your issue?). You can just try to compile the latest version from git. Maybe that fixes your issue already...

I do understand your broader point, but still feel your argument is wobbly wrt this specific example. Blaming Firetools because Systemd changed is akin to blaming the mugging victim for being in the park at the same time as the mugger was there.

Suppose I frequent a park at a certain time, if a mugger announces that he'll be mugging at that park on that time, should I change the time at witch I go to the park? (assuming I don't want to be mugged)
If I willfully go to the park at the mugging time, I'm I to blame?

Wow, an exemplary example of tangentialising an analogy into irrelevance. Well done.

2 Likes

But what a great imagination! :smile:

1 Like

I probably expressed it wrongly. I don't really want to blame anyone (my feeling says firetools will need to adapt and fix something here).

My point was that if there is an issue with firetools now, they need to investigate why that is and then either fix it in their program or tell systemd -> "hey you guys broke this and that piece, fix it". Of course that is annoying for the firetools devs, no doubt about that. Wouldn't be the first time systemd annoys people with breaking stuff :wink: .

Going the other route and addressing it to systemd directly (as a user), saying: "Hey you guys broke my favorite app with your latest version, fix it" would mean that systemd has to investigate firetools and debug that app. I don't think they are going to do that...

In this particular case there are a few reasons why it doesn't make progress I think:

The userbase for firetools seems to be rather small, otherwise there would have been some other people complaining about that (note, I'm just talking about the firetools gui thing which is causing issues, not firejail itself). Apparently there is only one developer maintaining that app (who is most probably not on the latest systemd version, otherwise he'd have noticed...) and it would be quite some effort for him to set up a test system to reproduce the issue. So he probably just doesn't care... (Wait until he is on systemd 243 with his ubuntu. Something is going to happen then :smile:)

1 Like

I had significant issues with your earlier post, but with this quote from your new post i can only unreservedly agree.

My essential sense of this problem, before & now, is that it is not firetools' fault, & thus wrong to blame them... however i judged that there is no realistic probability of the systemd devs bending to firetools, so the unpleasant pragmatic probability is that the firetools devs, though innocent, nevertheless will need to adjust their code. It was based on that logic that earlier i chose to report the problem on the firetools site rather than the systemd site.

systemd changed something in v243. If firetools is depending on some API of systemd they should adopt to those changes.

This however should be done in a way so a newer version of firetools still works on older systemd versions. So a git-bisect against systemd based on the last working version as starting point might help to find the needed commit which changed the API.

3 Likes

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by