modem-manager-gui packaging
by Artur Iwicki
Some time ago I've adopted modem-manager-gui. Recently upstream has released a new version, and while packaging this new version, I noticed a couple of issues:
1) mmgui can work with a couple of backends (different modem managers and connection managers). Each backend module is compiled into a different .so and they're all included in the package. mmgui is smart enough to recognize that a module cannot be used because it's appropriate daemon isn't running, so this isn't a problem by itself. The issue is: the new mmgui version also ships with an ofono plugin and a NetworkManager dispatcher.d script. Shipping these files without having a Requires: on ofono and NM seems dirty to me, but then - requiring all the possible backends would pull in unnecessary packages. I could separate the backends into individual packages, but I wonder - how the handle the dependencies, then? What I'd like to achieve is that one of the backends is the "recommended" one, while the others are optional. I'm not very accustomed to the weak dependencies mechanism, so I wonder: would something like "Recommends: mmgui-modemmanager; Suggests: mmgui-ofono mmgui-some_other_
backend" suffice?
2) Both the old and the new version install a polkit policy (in /usr/share/polkit-1/actions). fedora-review says that even with a "Requires: polkit", the directories have no known owners.
3) Similarly to the above - the package installs some help files in /usr/share/help. These are available in a couple languages. fedora-review says that some of the language directories (like /usr/share/help/pl) are unowned. I ran "dnf provides" and it looks like a few other packages that ship help files simply declare themselves are owning these directories. Should I do the same?
6 years, 2 months
Orphaning git-bugzilla
by Matěj Cepl
Hi,
will there be anybody crying for git-bugzilla if I let it die?
Anybody, orphaning it.
Best,
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mcepl(a)ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Wise walks steady step, only fools around them dance contemporary
dances.
-- Franz Kafka
6 years, 2 months
Fwd: Re: EXTERNAL: Re: After suspension
by Wells, Roger K.
sorry mistakenly sent to individual (Jared K Smith)
-------- Forwarded Message --------
Subject: Re: EXTERNAL: Re: After suspension
Date: Wed, 21 Mar 2018 13:23:22 -0400
From: Wells, Roger K. <wellsr(a)leidos.com>
To: Jared K. Smith <jsmith(a)fedoraproject.org>
On 01/06/2018 09:20 PM, Jared K. Smith wrote:
> (Apologies for the top-posting -- I'm on a mobile device at the moment.)
>
> Interesting... I noticed something similar today, but with a WebDAV
> external filesystem mounted. Turning off fprintd seemed to stop the
> delay, however. Does turning off fprintd solve the problem for you as
> well?
>
sorry for the huge delay. fprintd is not run on this machine.
more below
> -Jared
>
> On Thu, Jan 4, 2018 at 8:18 AM, Wells, Roger K. <wellsr(a)leidos.com
> <mailto:wellsr@leidos.com>> wrote:
>
> On 01/02/2018 01:18 PM, Al Stone wrote:
>
> On 12/26/2017 12:23 PM, Wells, Roger K. wrote:
>
> Small inconvenience but new and annoying:
> Machine is Thinkpad x260
> uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP
> Mon Dec 18 16:06:12
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Desktop: Gnome 3.26.4-1.fc27.x86_64
>
> When the lid is opened on the suspended machine the screen
> saver appears and the
> clock proceeds to update until
> the enter key is hit. Then the clock stops updating for
> 27 seconds followed by
> the login entry dialog appearing.
> Then everything is back to normal.
> This began right after the upgrade from F26 to F27 and has
> persisted through one
> or two subsequent routine updates.
> There are inconsistencies, sometimes it only does it when
> there is only wireless
> connections and no wired options.
> Sometimes it doesn't do it at all, no pattern here.
> Sometimes the 27 second delay is much shorter but this is
> quite rare.
> I have been running Fedora/Gnome for years and have never
> seen this.
>
> Any thoughts or things to try to help pin it down will be
> appreciated.
>
> thanks
>
> There have been a lot of recent changes in ACPI code for
> suspend and hibernate;
> it's always possible that something got tweaked in a recent
> kernel that could
> affect this particular model of machine.
>
> That being said, the 27 second delay sounds like the laptop
> hibernated (not
> suspended); if you waited a variable length of time to open
> the lid again, it
> might explain some of the variation -- sometimes it suspended,
> sometimes it was
> caught before hibernation was complete, sometime it was caught
> after it had
> fully hibernated. The other things that occur to me are that
> perhaps hibernate
> was not working before for this model of laptop and now it
> does; or, the power
> settings changed defaults, or did not retain settings when
> updating; or, some
> of the recent changes for lid notification aren't quite right
> for this laptop
> (there have been a few cases of that). Those are some of the
> places where I
> would start looking, at least...
>
> It turns out that this delay only occurs when the suspend happened
> when an external filesystem is mounted.
> In this case a cifs mount, and IIRC there have been some issues
> related to version changes that necessitated specifying "vers=1.0"
> in the fstab file.
> I will do some experiments and report back if anything interesting
> develops.
>
To clarify: the external filesystem is a wired network cifs mounted
filesystem. I suspend the system by closing the lid, without bothering
to unmount the cifs filesystems. Later when I open the lid if the
network wire is plugged in all is good, no delay. If the network wire
is not plugged in I get the delay (~30secs while something times out)
after that all works as expected. The issue is this: I have been using
the same setup back to fedora 16 or so without this issue. At about the
transition from f26 to f27 this issue developed. It is not fatal just
inconvenient and I expect that developers would like to see it go away
(a bit amateurish, and yes I am a developer as well)
> --
> Roger Wells, P.E.
> leidos
> 221 Third St
> Newport, RI 02840
> 401-847-4210 <tel:401-847-4210> (voice)
> 401-849-1585 <tel:401-849-1585> (fax)
> roger.k.wells(a)leidos.com <mailto:roger.k.wells@leidos.com>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-leave(a)lists.fedoraproject.org
> <mailto:devel-leave@lists.fedoraproject.org>
>
>
>
>
> _______________________________________________
> devel mailing list --devel(a)lists.fedoraproject.org
> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells(a)leidos.com
6 years, 2 months