On Sun, Jul 01, 2012 at 11:43:28PM +0300, Ionut Biru wrote:

I'm using myself pptp plugin from networkmanager and I don't have your issue.

And you are also using gnome-shell and have configured "Always ask" for the password? Note sure if this problem exists only recently, but here are the versions I used: gnome-shell version 3.4.1-3 networkmanager version 0.9.4.0-6 networkmanager-pptp version 0.9.4.0 As I understand it, networkmanager-pptp uses a gnome-shell service which in turn calls back a networkmanager-pptp specific password dialog. How convoluted. I do not claim to understand all the mechanisms behind it. But if you do not see this with the exact same setup, that would be stranger still.

And fedora is going to ditch /usr/libexec as well so they should fix this properly in the software.

Good to know. Thanks.

Not sure if this is related, but after my update this morning I am getting this message in my CUPS configuration. Searched the web and only found bug report entry on the Ubuntu forms. Not sure of a solution yet.

*"The PPD version (5.2.7) is not compatible with Gutenprint 5.2.8." *

Not exactly what I had, but it simply looks like your PPD's outdated. Have you tried fetching a more recent PPD and pointing CUPS to it? I managed to get my printer working right after installing it in a Debian machine without a failure. As I plugged it back to my Arch and ran hp-setup it suddenly got recognized, but hp-setup kept failing. Installing via the CUPS webinterface helped, the Test Page is fine. -- Serge Hooge () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On Mon, Jul 2, 2012 at 6:53 AM, Lukáš Jirkovský wrote:

On 1 July 2012 22:17, Clemens Buchacher wrote:

...

Hi,

I'd like to bring to your attention the discussion surrounding gnome-shell/networkmanager bug #679212 (NetworkManager VPN secrets: NetworkAgent internal error):

https://bugzilla.gnome.org/show_bug.cgi?id=679212

A fix for this particular bug is under way. The cause for the bug was Arch Linux's use of different libexecdirs for gnome-shell and networkmanager plugins (/usr/lib/gnome-shell and /usr/lib/networkmanager, respectively), instead of the default /usr/libexec. This is in accordance with Arch Packaging Standards:

"Avoid using /usr/libexec/ for anything. Use /usr/lib/${pkgname}/ instead." [1]

What is the motivation for this rule? In response to the above bug report, a gnome-shell dev says that he "could consider this weird libexecdir setting a distribution problem." Since this seems to be an unusual setting, I suspect that there might still be many more bugs lurking around for which Arch Linux plays beta tester. Indeed, this is not the first time that I am having trouble with Arch Linux packages using custom installation directories [2].

Maybe it's not such a big deal and it's just me having some tough luck (2 events do not make a good statistic). But expectations upstream seem to contradict the Arch Linux rule, so I wanted to bring it up for discussion.

Clemens

[1] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_etique... [2] http://gnu-octave-repository.2306053.n4.nabble.com/geometry-1-4-0-cannot-han...

libexec is not part of FHS, so I would say it's gnome guys who should fix that.

As far as I know, Fedora/RedHat are the only ones to use this location. Unless I'm mistaken there is a push internally there to stop using it and instead use /usr/lib/<pkgname> like everyone else. Aside from that, it really makes no sense to distinguish between the two folders, it is perfectly possible to have binaries that should belong to both. -t