Revert "dbus: update to 1.13.18"

This reverts commit 0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92.

 root@finn:/# /etc/init.d/dbus start
 dbus[2537]: Failed to start message bus: Failed to open "/dbus-1/system.conf": No such file or directory

I guess simple run testing still is too much to expect when
doing arbitrary changes packaging?  Just commit the broken
package and let someone else clean up the mess.  Is that
your idea of contributing?

FWIW, the version update was fine. So if the commit hadn't
been such a squashed mess, then both changes didn't have to
be reverted.  But I'm not going clean that up.  I am not
your mother.

The repeated lack of run testing major changes really makes
me wonder what it takes to get commit rights around here.
Not much, from the looks of it.

Cc: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 utils/dbus/Makefile | 55 ++++++++++++++++++++++++++++-----------------
 1 file changed, 35 insertions(+), 20 deletions(-)

>
> This reverts commit 0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92.
>
>  root@finn:/# /etc/init.d/dbus start
>  dbus[2537]: Failed to start message bus: Failed to open "/dbus-1/system.conf": No such file or directory
>

The avahi package is also affected by this breakage and crash loop in
the current master.

On Apr 21, 2021, at 10:46, Ansuel Smith <ansuelsmth@gmail.com> wrote:

>> 
>> This reverts commit 0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92.
>> 
>> root@finn:/# /etc/init.d/dbus start
>> dbus[2537]: Failed to start message bus: Failed to open "/dbus-1/system.conf": No such file or directory
>> 
> 
> The avahi package is also affected by this breakage and crash loop in
> the current master.

Rosen Penev <rosenp@gmail.com> writes:

> Why was this sent here? dbus is in the packages feed.

Sorry, I assumed that was obvious.  I'll explain

There is a continous push to move packages from the OpenWrt core repo to
the "packages" repo. This would have been fine if both these repos could
be trusted.  Unfortunately, that is not the case.

That's why this is relevant to OpenWrt. The low standards of the
packages repo reflects back to OpenWrt.  I believe core needs to take
control over packages again, or something must be done to improve the
quality of the packages repo.

When a package cannot even be installed, like the current example, then
how do we know what security issues other packages have? No testing and
no review is a recipe for disaster.  No one should use the packages repo
as is.

The bad or missing procedures adds to this.  Why can anyone commit their
own code without any review?  Why are squashed commits allowed?  One
commit, one change is a golden rule.  There's a reason for that.

IMHO, the problem with the packages repo is mostly about attitude. There
is no reason to skip run testing in the first place.  This buggy change
would never have been commited by any qualified developer.

And you got a report 19 days ago that the package was uninstallable:
https://github.com/openwrt/packages/commit/0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92#commitcomment-49147445
The only logical thing to do would be an immediate revert.  But no, the
package is still broken.  Why?

So the question for OpenWrt core is: Do you really want to depend on the
packages repo?  Going down with it?


(As you know, dbus is not the first package you've left so broken that a
simple install was enough to find the bug.  I stumbled on
https://github.com/openwrt/packages/pull/14366 a while ago - I assume
there are plenty more)


Bjørn

Hi Bjørn,

Le dim. 25 avr. 2021 à 09:53, Bjørn Mork <bjorn@mork.no> a écrit :
>
> Rosen Penev <rosenp@gmail.com> writes:
>
> > Why was this sent here? dbus is in the packages feed.
>
> Sorry, I assumed that was obvious.  I'll explain
>
> There is a continous push to move packages from the OpenWrt core repo to
> the "packages" repo. This would have been fine if both these repos could
> be trusted. Unfortunately, that is not the case.
>
> That's why this is relevant to OpenWrt. The low standards of the
> packages repo reflects back to OpenWrt.  I believe core needs to take
> control over packages again, or something must be done to improve the
> quality of the packages repo.

I see you are the maintainer of "conserver", why should any of the
core developers care about such a niche software and spend time run
testing it ? ;)

The packages repo was moved to Github and control was given to non
core developers to be able to scale better.
Before that it was more or less impossible to add new packages or do
modifications to them.
You have to think of OpenWrt packages as Ubuntu PPA or Fedora Copr,
each package has a separate maintainer and quality will vary,
and you can install only the packages you are interested in while
building using "./scripts/feeds install <package>"

It's not perfect, but asking the core maintainers to review an
additional 1000 packages is not going to fly.
The only improvements that scale are more automation and CI IMO, but
if you have concrete ideas I'm all ears.

> When a package cannot even be installed, like the current example, then
> how do we know what security issues other packages have?

Are you trying at the same time to complain about not run-tested
updates and possibly having packages not up to date ?
For dbus there is no maintainer
(https://github.com/openwrt/packages/blob/3ddefd7feb2014e8a45cfbb1491f4afc1a1d2d04/utils/dbus/Makefile#L18),
I would personally mark it as broken or remove it instead of making it
work again, but it means removing some other packages.

> No testing and no review is a recipe for disaster.

I believe each maintainer is usually given some time to review / test
changes on their packages,
but here there is no maintainer :(

> No one should use the packages repo as is.

1 package out of 1000 has been broken for more than 2 weeks, seems a
bit of an overreaction don't you think ?
Even if 100 packages are broken I prefer the current situation,
because we still have 900 packages working to answer everyone specific
needs

> The bad or missing procedures adds to this.  Why can anyone commit their
> own code without any review?

The occasional breakage isn't worth the extra effort of having each
commit reviewed by someone else, and nobody has offered to do that.
Not everyone has commit access, and Rosen isn't anyone, he is the top
contributor to OpenWrt packages and by far (~2400 commits),
sure he causes breakage from time to time but he is also there to fix it.

>  Why are squashed commits allowed?  One
> commit, one change is a golden rule.  There's a reason for that.

For PR only merge and rebase is enabled for multiple months now, where
do you see squashed commits ?

> IMHO, the problem with the packages repo is mostly about attitude. There
> is no reason to skip run testing in the first place.  This buggy change
> would never have been commited by any qualified developer.

No need for attacks.
Run testing is the job of the maintainer, no maintainer == no run testing
Should we let the package stay without update ? or should we just remove it ?

> And you got a report 19 days ago that the package was uninstallable:
> https://github.com/openwrt/packages/commit/0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92#commitcomment-49147445
> The only logical thing to do would be an immediate revert.  But no, the
> package is still broken.  Why?

Yes this should have been reverted immediately, everything else in
this email is overreaction to me

> So the question for OpenWrt core is: Do you really want to depend on the
> packages repo?  Going down with it?

$ find . -name Makefile | grep '^./package/' | wc -l
264
$ find . -name Makefile | grep '^./feeds/packages/' | wc -l
1039

> (As you know, dbus is not the first package you've left so broken that a
> simple install was enough to find the bug.  I stumbled on
> https://github.com/openwrt/packages/pull/14366 a while ago - I assume
> there are plenty more)

More than happy to merge broken packages removal, you can ping me,
and looking forward to your concrete proposals to improve the current
status quo ;)

Etienne

>
> Bjørn

Etienne Champetier <champetier.etienne@gmail.com> writes:

> Are you trying at the same time to complain about not run-tested
> updates and possibly having packages not up to date ?

No.  The package was fine before the version was changed.  In fact, it
was in much better shape before it was changed to a development version
by the very same non-maintainer.

If you don't care enough to even install the package, then please don't
touch the package.

> I would personally mark it as broken or remove it instead of making it
> work again, but it means removing some other packages.

I'd be all for that, if you apply that rule to all the unmaintained
packages in the repo.  It's a much better solution than having the repo
full of arbitrary untested changes to unmaintained packages.

Wrt dbus I'm pretty sure it would provoke an adoption.  There are
multiple packages depending on it, and as the immediate reports tell
you:  This particualr umaintained package is in active use.



Bjørn

... I know you won't like this. But in the end, I guess D-Bus, glib2 and in the end all of MM dependencies will have to be incorporated in the core.

A stac, of big big software, I know. But supporting 4G/5G in the end will required that.

On Mon, 26 Apr 2021, Bjørn Mork wrote:

> Date: Mon, 26 Apr 2021 07:51:51
> From: Bjørn Mork <bjorn@mork.no>
> To: Etienne Champetier <champetier.etienne@gmail.com>
> Cc: Rosen Penev <rosenp@gmail.com>,
>     OpenWrt Development List <openwrt-devel@lists.openwrt.org>
> Subject: Re: Brokenness of the OpenWrt "packages" repo
> 
> Etienne Champetier <champetier.etienne@gmail.com> writes:
>
>> Are you trying at the same time to complain about not run-tested
>> updates and possibly having packages not up to date ?
>
> No.  The package was fine before the version was changed.  In fact, it
> was in much better shape before it was changed to a development version
> by the very same non-maintainer.
>
> If you don't care enough to even install the package, then please don't
> touch the package.
>
>> I would personally mark it as broken or remove it instead of making it
>> work again, but it means removing some other packages.
>
> I'd be all for that, if you apply that rule to all the unmaintained
> packages in the repo.  It's a much better solution than having the repo
> full of arbitrary untested changes to unmaintained packages.
>
> Wrt dbus I'm pretty sure it would provoke an adoption.  There are
> multiple packages depending on it, and as the immediate reports tell
> you:  This particualr umaintained package is in active use.
>
>
>
> Bjørn
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Sorry ... I don't mean to undervalue the efforts to build an alternate software stack for that, like the very uqmi one.
But there's a whole lot of complexity underneath ...

On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote:
> ... I know you won't like this. But in the end, I guess D-Bus, glib2 and in the end all of MM dependencies will have to be incorporated in the core.
> 
> A stac, of big big software, I know. But supporting 4G/5G in the end will required that.

ModemManager is not the only way to use 4G/5G modems. You can use
umbim or uqmi for most tasks. Both projects are straight forward, well
documented code, easy to extend in case you miss anything.
Depending on half of the Freedesktop universe in order to initialize
a network interface or receive an SMS in a very complicated way doesn't
feel justified to me.


> 
> On Mon, 26 Apr 2021, Bjørn Mork wrote:
> 
> > Date: Mon, 26 Apr 2021 07:51:51
> > From: Bjørn Mork <bjorn@mork.no>
> > To: Etienne Champetier <champetier.etienne@gmail.com>
> > Cc: Rosen Penev <rosenp@gmail.com>,
> >     OpenWrt Development List <openwrt-devel@lists.openwrt.org>
> > Subject: Re: Brokenness of the OpenWrt "packages" repo
> > 
> > Etienne Champetier <champetier.etienne@gmail.com> writes:
> > 
> > > Are you trying at the same time to complain about not run-tested
> > > updates and possibly having packages not up to date ?
> > 
> > No.  The package was fine before the version was changed.  In fact, it
> > was in much better shape before it was changed to a development version
> > by the very same non-maintainer.
> > 
> > If you don't care enough to even install the package, then please don't
> > touch the package.
> > 
> > > I would personally mark it as broken or remove it instead of making it
> > > work again, but it means removing some other packages.
> > 
> > I'd be all for that, if you apply that rule to all the unmaintained
> > packages in the repo.  It's a much better solution than having the repo
> > full of arbitrary untested changes to unmaintained packages.
> > 
> > Wrt dbus I'm pretty sure it would provoke an adoption.  There are
> > multiple packages depending on it, and as the immediate reports tell
> > you:  This particualr umaintained package is in active use.
> > 
> > 
> > 
> > Bjørn
> > 
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel

> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Daniel Golle <daniel@makrotopia.org> writes:

> Depending on half of the Freedesktop universe in order to initialize
> a network interface or receive an SMS in a very complicated way doesn't
> feel justified to me.

I have been very pleased with uqmi and umbim as alternatives for tiny
embedded devices, and I am hoping that they wiil be updated and
maintained.  But they're not an option at all with the latest generation
modems, and I don't see that changing anytime soon.  They lack all the
5G stuff, multiplexing support, and there is no alternative application
at all for the new PCIe drivers (Qualcomm MHI or Intel IOSM).

We've come to a point where ModemManager is pretty much required on
OpenWrt too.  And I believe that's good.  The alternative isn't
uqmi/umbim or similar, but a desktop distro running on your "embedded"
router.




Bjørn

On 25/04/21 15:51, Bjørn Mork wrote:
> Rosen Penev <rosenp@gmail.com> writes:
> 
>> Why was this sent here? dbus is in the packages feed.
> 
> Sorry, I assumed that was obvious.  I'll explain
> 
> There is a continous push to move packages from the OpenWrt core repo to
> the "packages" repo. This would have been fine if both these repos could
> be trusted.  Unfortunately, that is not the case.
> 
> That's why this is relevant to OpenWrt. The low standards of the
> packages repo reflects back to OpenWrt.  I believe core needs to take
> control over packages again, or something must be done to improve the
> quality of the packages repo.


Nobody had "control" over most non-core packages before when they were 
in core repo, so nobody would review contributions that would bitrot and 
eventually get closed. That's why they get moved to packages repo.

I think the only way forward is improving quality/rules/integration 
tests or whatever in the package repo, "going back" would just mean the 
package will never get updated in years even if it has bugs because no 
core developer cares enough (or knows enough) to review and merge 
contributions.


> When a package cannot even be installed, like the current example, then
> how do we know what security issues other packages have? No testing and
> no review is a recipe for disaster.  No one should use the packages repo
> as is.
> 
> The bad or missing procedures adds to this.  Why can anyone commit their
> own code without any review?  

To be fair, there is plenty of "commit their own code without any 
review" in core repo too. It's just that the developer is much more 
experienced and makes less mistakes. Maybe.

> Why are squashed commits allowed?  One
> commit, one change is a golden rule.  There's a reason for that.
> 
> IMHO, the problem with the packages repo is mostly about attitude. There
> is no reason to skip run testing in the first place.  This buggy change
> would never have been commited by any qualified developer.

I think the main problem is about rules and enforcement of them. Are 
there rules for the package repo?
Are there "super users" that can enforce them, revert the commits just 
because it's not conformant to rules and scold anyone that is caught 
merging bad stuff?
Can someone lose commit access if he keeps ignoring rules?

In core repo (on Github mostly) I've seen Adrian Schmutzler do this a 
bit with the newer core developers. But it's a single person posting 
some comment every once in a while, and there are not a lot of "new core 
developers" all the time.

For packages feed it will have to require more people or at least more 
automation.

> 
> And you got a report 19 days ago that the package was uninstallable:
> https://github.com/openwrt/packages/commit/0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92#commitcomment-49147445
> The only logical thing to do would be an immediate revert.  But no, the
> package is still broken.  Why?
> 
> So the question for OpenWrt core is: Do you really want to depend on the
> packages repo?  Going down with it?

Depend on what? dbus and all other stuff in packages are not required by 
core to work.

If they are broken, the issue is only in the package repo, which is seen 
as "additional functionality", and thus less critical.

That's the way packages repos has always been seen as. It's not a "core 
repo" but a "community repo", similar to Ubuntu PPA repos, or Arch's AUR 
repos, or OpenSUSE's OBS repos. It's stuff maintained by third parties 
that shares the same build infrastructure, and as such it may or may not 
blow up in your face.

-Alberto

> 
> 
> (As you know, dbus is not the first package you've left so broken that a
> simple install was enough to find the bug.  I stumbled on
> https://github.com/openwrt/packages/pull/14366 a while ago - I assume
> there are plenty more)
> 
> 
> Bjørn
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>

On 26/04/21 07:51, Bjørn Mork wrote:
> Etienne Champetier <champetier.etienne@gmail.com> writes:
> 
>> Are you trying at the same time to complain about not run-tested
>> updates and possibly having packages not up to date ?
> 
> No.  The package was fine before the version was changed.  In fact, it
> was in much better shape before it was changed to a development version
> by the very same non-maintainer.
> 
> If you don't care enough to even install the package, then please don't
> touch the package.
> 
>> I would personally mark it as broken or remove it instead of making it
>> work again, but it means removing some other packages.
> 
> I'd be all for that, if you apply that rule to all the unmaintained
> packages in the repo.  It's a much better solution than having the repo
> full of arbitrary untested changes to unmaintained packages.
> 
> Wrt dbus I'm pretty sure it would provoke an adoption.  There are
> multiple packages depending on it, and as the immediate reports tell
> you:  This particualr umaintained package is in active use.
> 

I also second this. If there is no maintainer, the maintainer is unable 
to do his job (let's say it's the 4th time he merged stuff that was 
blatantly obviously not tested) or the current maintainer is unreachable 
for more than X time, the package should be dropped(moved to the broken 
package repo or not, it's still in git history anyway).

That is the best way to get someone to volunteer as maintainer, even if 
this person will just be a glorified tester, aka someone that only runs 
tests on the package after any change.

-Alberto

> 
> 
> Bjørn
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>

On 26/04/21 16:01, Daniel Golle wrote:
> On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote:
>> ... I know you won't like this. But in the end, I guess D-Bus, glib2 and in the end all of MM dependencies will have to be incorporated in the core.
>>
>> A stac, of big big software, I know. But supporting 4G/5G in the end will required that.
> 
> ModemManager is not the only way to use 4G/5G modems. You can use
> umbim or uqmi for most tasks. 

In my experience their ability to handle device-specific bugs or "perks" 
is limited, unless your modem is 100% perfect and never crashes ever and 
can actually handle the autoreconnect on its own, you will end up in 
situations where you need to just set up a script that pings Google and 
reboots the router if network fails.

They also don's support a lot of new LTE features like band lock, band 
aggregation and more, they are way too simple. I have bought a consumer 
modem/router that is like 3 times faster while using the same type of 
CAT6 modem due to band aggregation and the reconnect sequence if the 
connection drops is very fast because I have set the only 2 LTE bands it 
can use.

MM is so much better than that. But my main issue with MM is that both 
maintainers (package and upstream MM maintainers) have not found a way 
to integrate it well enough with OpenWrt's internals so that when the 
modem disconnects there is nothing that notices this issue and nothing 
that reacts to it. So I had to cobble together a script to do this 
missing link, but it's far from a decent solution. (see the issue thread 
I opened about this)

Hence why I eventually bought an actual self-contained modem with web 
interface and all, it's just so much better speed and is less painful to 
use.

-Alberto


Both projects are straight forward, well
> documented code, easy to extend in case you miss anything.
> Depending on half of the Freedesktop universe in order to initialize
> a network interface or receive an SMS in a very complicated way doesn't
> feel justified to me.
> 
> 
>>
>> On Mon, 26 Apr 2021, Bjørn Mork wrote:
>>
>>> Date: Mon, 26 Apr 2021 07:51:51
>>> From: Bjørn Mork <bjorn@mork.no>
>>> To: Etienne Champetier <champetier.etienne@gmail.com>
>>> Cc: Rosen Penev <rosenp@gmail.com>,
>>>      OpenWrt Development List <openwrt-devel@lists.openwrt.org>
>>> Subject: Re: Brokenness of the OpenWrt "packages" repo
>>>
>>> Etienne Champetier <champetier.etienne@gmail.com> writes:
>>>
>>>> Are you trying at the same time to complain about not run-tested
>>>> updates and possibly having packages not up to date ?
>>>
>>> No.  The package was fine before the version was changed.  In fact, it
>>> was in much better shape before it was changed to a development version
>>> by the very same non-maintainer.
>>>
>>> If you don't care enough to even install the package, then please don't
>>> touch the package.
>>>
>>>> I would personally mark it as broken or remove it instead of making it
>>>> work again, but it means removing some other packages.
>>>
>>> I'd be all for that, if you apply that rule to all the unmaintained
>>> packages in the repo.  It's a much better solution than having the repo
>>> full of arbitrary untested changes to unmaintained packages.
>>>
>>> Wrt dbus I'm pretty sure it would provoke an adoption.  There are
>>> multiple packages depending on it, and as the immediate reports tell
>>> you:  This particualr umaintained package is in active use.
>>>
>>>
>>>
>>> Bjørn
>>>
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>

On 4/26/21 3:58 PM, Alberto Bursi wrote:
> 
> 
> On 26/04/21 16:01, Daniel Golle wrote:
>> On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote:
>>> ... I know you won't like this. But in the end, I guess D-Bus, glib2 
>>> and in the end all of MM dependencies will have to be incorporated in 
>>> the core.
>>>
>>> A stac, of big big software, I know. But supporting 4G/5G in the end 
>>> will required that.
>>
>> ModemManager is not the only way to use 4G/5G modems. You can use
>> umbim or uqmi for most tasks. 
> 
> In my experience their ability to handle device-specific bugs or "perks" 
> is limited, unless your modem is 100% perfect and never crashes ever and 
> can actually handle the autoreconnect on its own, you will end up in 
> situations where you need to just set up a script that pings Google and 
> reboots the router if network fails.
> 
> They also don's support a lot of new LTE features like band lock, band 
> aggregation and more, they are way too simple. I have bought a consumer 
> modem/router that is like 3 times faster while using the same type of 
> CAT6 modem due to band aggregation and the reconnect sequence if the 
> connection drops is very fast because I have set the only 2 LTE bands it 
> can use.
> 
> MM is so much better than that. But my main issue with MM is that both 
> maintainers (package and upstream MM maintainers) have not found a way 
> to integrate it well enough with OpenWrt's internals so that when the 
> modem disconnects there is nothing that notices this issue and nothing 
> that reacts to it. So I had to cobble together a script to do this 
> missing link, but it's far from a decent solution. (see the issue thread 
> I opened about this)
> 
> Hence why I eventually bought an actual self-contained modem with web 
> interface and all, it's just so much better speed and is less painful to 
> use.
> 
> -Alberto
> 
> 
> Both projects are straight forward, well
>> documented code, easy to extend in case you miss anything.
>> Depending on half of the Freedesktop universe in order to initialize
>> a network interface or receive an SMS in a very complicated way doesn't
>> feel justified to me.
>>
>>
>>>
>>> On Mon, 26 Apr 2021, Bjørn Mork wrote:
>>>
>>>> Date: Mon, 26 Apr 2021 07:51:51
>>>> From: Bjørn Mork <bjorn@mork.no>
>>>> To: Etienne Champetier <champetier.etienne@gmail.com>
>>>> Cc: Rosen Penev <rosenp@gmail.com>,
>>>>      OpenWrt Development List <openwrt-devel@lists.openwrt.org>
>>>> Subject: Re: Brokenness of the OpenWrt "packages" repo
>>>>
>>>> Etienne Champetier <champetier.etienne@gmail.com> writes:
>>>>
>>>>> Are you trying at the same time to complain about not run-tested
>>>>> updates and possibly having packages not up to date ?
>>>>
>>>> No.  The package was fine before the version was changed.  In fact, it
>>>> was in much better shape before it was changed to a development version
>>>> by the very same non-maintainer.
>>>>
>>>> If you don't care enough to even install the package, then please don't
>>>> touch the package.
>>>>
>>>>> I would personally mark it as broken or remove it instead of making it
>>>>> work again, but it means removing some other packages.
>>>>
>>>> I'd be all for that, if you apply that rule to all the unmaintained
>>>> packages in the repo.  It's a much better solution than having the repo
>>>> full of arbitrary untested changes to unmaintained packages.
>>>>
>>>> Wrt dbus I'm pretty sure it would provoke an adoption.  There are
>>>> multiple packages depending on it, and as the immediate reports tell
>>>> you:  This particualr umaintained package is in active use.
>>>>
>>>>
>>>>
>>>> Bjørn

I feel this with a lighter tone, but I philosophically agree with Bjorn.

Here is an example of enforcement concerns. I am an active maintainer. I 
have a day job and all, but I do get to at least commenting on PR once a 
week. Here committer and merger where separate individuals. The 
maintainer wasn't contacted. Neither participant is even a user of 
Unbound, self-stated in PR, or tested the work. I realize the change was 
trivial, and that is not my point. An automated test-hook could have 
checked if the maintainer commented or the maintainer was AWOL before 
marking the PR ready. Trivial or complex, maintainers need to be in the 
loop or we lose continuity in quality and we discourage their "feeling 
of ownership" when we bypass them.

SEE: https://github.com/openwrt/packages/pull/15511

- Eric

On Mon, 26 Apr 2021, Alberto Bursi wrote:

> Date: Mon, 26 Apr 2021 21:58:23
> From: Alberto Bursi <bobafetthotmail@gmail.com>
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: Brokenness of the OpenWrt "packages" repo
> 
>
>
> On 26/04/21 16:01, Daniel Golle wrote:
>> On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote:
>>> ... I know you won't like this. But in the end, I guess D-Bus, glib2 and 
> in the end all of MM dependencies will have to be incorporated in the core.
>>>
>>> A stac, of big big software, I know. But supporting 4G/5G in the end will 
> required that.
>> 
>> ModemManager is not the only way to use 4G/5G modems. You can use
>> umbim or uqmi for most tasks. 
>
> In my experience their ability to handle device-specific bugs or "perks" 
> is limited, unless your modem is 100% perfect and never crashes ever and 
> can actually handle the autoreconnect on its own, you will end up in 
> situations where you need to just set up a script that pings Google and 
> reboots the router if network fails.
>
> They also don's support a lot of new LTE features like band lock, band 
> aggregation and more, they are way too simple. I have bought a consumer 
> modem/router that is like 3 times faster while using the same type of 
> CAT6 modem due to band aggregation and the reconnect sequence if the 
> connection drops is very fast because I have set the only 2 LTE bands it 
> can use.
>
> MM is so much better than that. But my main issue with MM is that both 
> maintainers (package and upstream MM maintainers) have not found a way 
> to integrate it well enough with OpenWrt's internals so that when the 
> modem disconnects there is nothing that notices this issue and nothing 
> that reacts to it. So I had to cobble together a script to do this 
> missing link, but it's far from a decent solution. (see the issue thread 
> I opened about this)

That's why in the end, admittedly for different reasons, we ended up writing our own software to do so.
It included an ubus script that tried to match MM bearers with network configurations. In the end it somewhat works, but the integration layer between MM and openwrt is still little bit fragile.
It was enough to add a WireGuard interface to the system to stop MM from starting up. Setting the interface to not auto-start was enough to fix the isue.
If you know me, you know I try to avoid absolute statements in general, and I absolutely don't mean to criticise other people's work here.
The problem is the 5G modems out there are simply too complex to be handled e.g.: statelessly.
I don't like to have this big stack of software on my devices as well, but there are times where you need to compromise. Once it was enough to use AT commands by hand, now its not the case anymore, at least for modern QMI-based modems.
Bring in the multi-bearer dual-stack scenario and you have such a complexity growth...

In general, uqmi and umbim are extremely clean and well-done. I estimate all of you a lot folks. But modems' firmware is a strange world. :)

If you're under the impression a 5G modem might be an over-complicated gigantic piece of software / hardware complexity, I would second you.
That requires scaling of complexity in the host side as well.
Sudden resets and other characteristics, lets you having to be careful to stay consistent with modem state even when MM is behind you, doing it's great amount of work.
This time it's not useless complexity. But well yes - it's a lot of complexity.
Trying to trust the Modem firmware to do things like auto-connecting is very smart and appropriate - if you knw it's going to work. but we're going to face lots of different hardware with different bugs.
So unfortunately we should handle all of them.

>
> Hence why I eventually bought an actual self-contained modem with web 
> interface and all, it's just so much better speed and is less painful to 
> use.
>
> -Alberto
>
>
> Both projects are straight forward, well
>> documented code, easy to extend in case you miss anything.
>> Depending on half of the Freedesktop universe in order to initialize
>> a network interface or receive an SMS in a very complicated way doesn't
>> feel justified to me.
>> 
>> 
>>>
>>> On Mon, 26 Apr 2021, Bjørn Mork wrote:
>>>
>>>> Date: Mon, 26 Apr 2021 07:51:51
>>>> From: Bjørn Mork <bjorn@mork.no>
>>>> To: Etienne Champetier <champetier.etienne@gmail.com>
>>>> Cc: Rosen Penev <rosenp@gmail.com>,
>>>>      OpenWrt Development List <openwrt-devel@lists.openwrt.org>
>>>> Subject: Re: Brokenness of the OpenWrt "packages" repo
>>>>
>>>> Etienne Champetier <champetier.etienne@gmail.com> writes:
>>>>
>>>>> Are you trying at the same time to complain about not run-tested
>>>>> updates and possibly having packages not up to date ?
>>>>
>>>> No.  The package was fine before the version was changed.  In fact, it
>>>> was in much better shape before it was changed to a development version
>>>> by the very same non-maintainer.
>>>>
>>>> If you don't care enough to even install the package, then please don't
>>>> touch the package.
>>>>
>>>>> I would personally mark it as broken or remove it instead of making it
>>>>> work again, but it means removing some other packages.
>>>>
>>>> I'd be all for that, if you apply that rule to all the unmaintained
>>>> packages in the repo.  It's a much better solution than having the repo
>>>> full of arbitrary untested changes to unmaintained packages.
>>>>
>>>> Wrt dbus I'm pretty sure it would provoke an adoption.  There are
>>>> multiple packages depending on it, and as the immediate reports tell
>>>> you:  This particualr umaintained package is in active use.
>>>>
>>>>
>>>>
>>>> Bjørn
>>>>
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>> 
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>