[arch-general] Custom libexecdir not recommended for gnome
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...
On 07/01/2012 11:17 PM, 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):
I'm using myself pptp plugin from networkmanager and I don't have your issue. And fedora is going to ditch /usr/libexec as well so they should fix this properly in the software.
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...
-- Ionuț
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.
On 07/03/2012 01:17 AM, Clemens Buchacher wrote:
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:
hmm no. it's saved.
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.
-- Ionuț
Greetings all, I have an HP LaserJet M1132 hooked via a USB port. It worked quite fine until my recent -Syu, where it suddenly stopped working. Since I had hplip upgraded, I assumed I have to reinstall the printer, so I removed it via the CUPS webinterface and right now I can't seem to get it installed again! Both CUPS and hp-setup fail to see it, however lsusb, dmesg and usb-devices clearly show it's there. The device node permissions are fine too. usblp is blacklisted, but I tried the installation after probing it, which didn't help. lpinfo -v stopped showing anything about USB. It doesn't seem that -Syu has something to do with it, since downgrading all the packages I've upgraded didn't help, I'm thinking this has something to do with the libusb -> libusbx transition earlier. Also tried the suggested solution to the same problem from here with no luck: https://bbs.archlinux.org/viewtopic.php?pid=1119424#p1119424 Anyone can help? -- Serge Hooge () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Greetings all,
I have an HP LaserJet M1132 hooked via a USB port. It worked quite fine until my recent -Syu, where it suddenly stopped working. Since I had hplip upgraded, I assumed I have to reinstall the printer, so I removed it via the CUPS webinterface and right now I can't seem to get it installed again! Both CUPS and hp-setup fail to see it, however lsusb, dmesg and usb-devices clearly show it's there. The device node permissions are fine too. usblp is blacklisted, but I tried the installation after probing it, which didn't help. lpinfo -v stopped showing anything about USB.
It doesn't seem that -Syu has something to do with it, since downgrading all the packages I've upgraded didn't help, I'm thinking this has something to do with the libusb -> libusbx transition earlier.
Also tried the suggested solution to the same problem from here with no luck: https://bbs.archlinux.org/viewtopic.php?pid=1119424#p1119424
Anyone can help?
-- Serge Hooge
() ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
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." * -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present. Headmaster Squall :: The Wired/Section-9 Close the world txen eht nepo $3R14L 3XP3R1M3NT$ #L41N http://twitter.com/headmastersqual
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 1 July 2012 22:17, Clemens Buchacher <drizzd@aon.at> 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. Lukas
On Mon, Jul 2, 2012 at 6:53 AM, Lukáš Jirkovský <l.jirkovsky@gmail.com> wrote:
On 1 July 2012 22:17, Clemens Buchacher <drizzd@aon.at> 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
participants (6)
-
Clemens Buchacher
-
Ionut Biru
-
Lukáš Jirkovský
-
Serge Hooge
-
Squall Lionheart
-
Tom Gundersen