Re: [arch-general] [arch-dev-public] The need for /lib64 - testing please
On Thu, Jun 30, 2011 at 23:48, Allan McRae wrote: > Hi all, > > I was looking at the /lib64 folder and wondering what it is really needed > for... It just seems clutter to me on a pure x86_64 system (or even with a > multilib in lib32 folders like we have). As far as I can tell, most things > are perfectly fine without that folder and its two symlinks. > > I would like some help testing removing this so I can get an idea of what > issues people run into. There is bound to be some software that makes > assumptions about /lib64 in its installation and I would like to know (a) > how widespread that issue is and (b) how hard it is to work around. > > If you want to try it out, just remove the /lib64 folder (after making sure > it only has symlinks to ld-2.13.so and ld-linux-x86-64.so.2 in it. Run your > system as usual for a while and report any issues you come across. > > Thanks, > Allan > Allan: The binary version of VirtualBox from AUR fails without the /lib64 folder. I renamed the folder to /lib64.old, rebooted, the tried several apps. VBox was the only failure, so far. I tried reinstalling it and rebuilding the kernel modules to no avail. The message I get is: "no such executable. /opt/var/VirtualBox does not exist" From memory but very close. I get the same message when I try to run any of the virtualbox progs. The symlink in /usr/bin show to be broken. It shows an 'x' in the lower right corner. If I rename /lib64.old to /lib64 it runs with no problems. I haven't investigated any farther. Myra -- Life's fun when your sick and psychotic!
Re: [arch-general] [arch-dev-public] The need for /lib64 - testing please
On 06/30/2011 10:48 PM, Allan McRae wrote: > Hi all, > > I was looking at the /lib64 folder and wondering what it is really > needed for... It just seems clutter to me on a pure x86_64 system (or > even with a multilib in lib32 folders like we have). As far as I can > tell, most things are perfectly fine without that folder and its two > symlinks. > > I would like some help testing removing this so I can get an idea of > what issues people run into. There is bound to be some software that > makes assumptions about /lib64 in its installation and I would like to > know (a) how widespread that issue is and (b) how hard it is to work > around. > > If you want to try it out, just remove the /lib64 folder (after making > sure it only has symlinks to ld-2.13.so and ld-linux-x86-64.so.2 in it. > Run your system as usual for a while and report any issues you come across. > > Thanks, > Allan > removed and anxious to see results. i DO have mutlilib enabled/used fwiw. JB
Re: [arch-general] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2
Am Friday 01 July 2011, 07:33:33 schrieb Christian Hesse: > Thomas Bächler on Thu, 30 Jun 2011 20:15:01 +0200: > > This is a huge release and should stay in testing for a while. I want to > > point out two significant changes: > > > > 1) We now have a build() function instead of an install() function - the > > latter was an unfortunate conflict with the install utility. The hooks > > in the repository have been adjusted, but backward-compatibility code is > > in place (a deprecation warning will be printed). All these packages > > have conflicts=(mkinitcpio<0.7). > > > > 2) We now use bsdcpio instead of gen_init_cpio. This obsoletes the > > gen_init_cpio package and adds a dependency on libarchive. This also > > speeds up the image generation considerably. > > > > Other changes include massive cleanups and fixes, code refactoring, and > > changes that should finally make the -b (basedir) option useful. > > > > Please test and sign off. > > Works without problems with LUKS encrypted lvm2. Works fine with mdadm RAID1 signoff both greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2
Thomas Bächler on Thu, 30 Jun 2011 20:15:01 +0200: > This is a huge release and should stay in testing for a while. I want to > point out two significant changes: > > 1) We now have a build() function instead of an install() function - the > latter was an unfortunate conflict with the install utility. The hooks > in the repository have been adjusted, but backward-compatibility code is > in place (a deprecation warning will be printed). All these packages > have conflicts=(mkinitcpio<0.7). > > 2) We now use bsdcpio instead of gen_init_cpio. This obsoletes the > gen_init_cpio package and adds a dependency on libarchive. This also > speeds up the image generation considerably. > > Other changes include massive cleanups and fixes, code refactoring, and > changes that should finally make the -b (basedir) option useful. > > Please test and sign off. Works without problems with LUKS encrypted lvm2. -- Schoene Gruesse Chris
Re: [arch-general] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2
On 30 June 2011 20:15, Thomas Bächler wrote:
> This is a huge release and should stay in testing for a while. I want to
> point out two significant changes:
>
> 1) We now have a build() function instead of an install() function - the
> latter was an unfortunate conflict with the install utility. The hooks
> in the repository have been adjusted, but backward-compatibility code is
> in place (a deprecation warning will be printed). All these packages
> have conflicts=(mkinitcpio<0.7).
>
> 2) We now use bsdcpio instead of gen_init_cpio. This obsoletes the
> gen_init_cpio package and adds a dependency on libarchive. This also
> speeds up the image generation considerably.
>
> Other changes include massive cleanups and fixes, code refactoring, and
> changes that should finally make the -b (basedir) option useful.
>
> Please test and sign off.
>
> Here comes the full shortlog:
>
> Dave Reisner (52):
> init: don't attempt modprobe if $MODULES is empty
> mkinitcpio.conf: s/raid/mdadm/
> mkinitcpio: deprecate install() in install hooks
> dmesg: remove install/hook
> functions: cleanup and refactor add_binary
> functions: refactor add_module
> functions: remove add_device
> functions: remove add_symlink2
> use bsdcpio to create images
> functions: refactor add_file
> functions: document hook API
> mkinitcpio.conf: note implicit support for lzop
> mkinitcpio: use simple PEs instead of externals
> mkinitcpio: allow specifying kernel ver as path to image
> lsinitcpio: new utility to dump contents of images
> Makefile: refactor and simplify
> mkinitcpio: bashify preset build loop
> use consistent vim modelines
> declare all variables in mkinitcpio
> mkinitcpio: refactor and bashify early path calculations
> declare SAVELIST, QUIET, SHOW_AUTOMODS as faux booleans
> mkinitcpio: remove cruft in getopts loop
> overhaul output, introducing color
> functions: refactor add_symlink
> functions: simplify parse_hook
> mkinitcpio: bashification, part 1/2
> mkinitcpio: bashification, part 2/2
> add -t option to specify alternate build directory
> install/keymap: refactor and bashify
> mkinitcpio: declare usage as a heredoc
> remove support for -m to add a startup message
> install/base: cleanup and simplify
> functions: remove get_module_name
> init: declare PATH, remove absolute paths
> init: remove unnecessary variable declarations
> mkinitcpio: allow overriding the compression method
> mkinitcpio: only show usage on request
> mkinitcpio.5: alphabetize options for easier nav
> README: update copyright year, add self as author
> mkinitcpio: catch errors in parse_hook
> add a PKGBUILD for easier testing from the repo
> mkinitcpio: allow absolute paths to preset files
> install/{sata,pata,scsi}: cleanup and simplify
> properly support $BASEDIR
> install/autodetect: refactor and simplify hook
> functions: support $BASEDIR in modprobe
> Makefile: the Makefile itself is a dep for the manpage
> functions: add missing 'command' before install
> functions: s/basedir/BASEDIR/
> functions: fix pathing issue with $BASEDIR
> install/base: use private API call to add config
> mkinitcpio: fix resolution issues with RTLD
>
> Eric Bélanger (1):
> Added usbinput to default hooks (implements FS#19328)
>
> Gerardo Exequiel Pozzi (3):
> Fix some install hooks due recent change in all_modules()
> Add missing /etc/bash_completion.d in Makefile
> Add asciidoc as makedepends in private PKGBUILD.
>
> Sebastien Luttringer (6):
> Add bash completion to mkinitcpio
> Fix printing of bash usage when asking for a bad hook
> Print pretty message if no help is defined in hook
> Use error function instead of echo
> Add lsinitcpio bash completion
> Use _get_comp_words_by_ref in bash completion
>
> Thomas Bächler (7):
> Merge branch 'master' of https://github.com/seblu/arch-mkinitcpio
> into working
> Remove old '-m' option from bash completion.
> emove old '-a' option from bash completion and fix '-s' option.
> Merge branch 'working'
> Add .gitignore file
> install/keymap: fix installation ($buildroot -> $BUILDROOT)
> Release version 0.7
>
>
Sign-off x86_64 mkinitcpio on a pretty simple setup without LVM or
RAID. The speedup is impressive.
Lukas
[arch-general] The need for /lib64 - testing please
Hi all, I was looking at the /lib64 folder and wondering what it is really needed for... It just seems clutter to me on a pure x86_64 system (or even with a multilib in lib32 folders like we have). As far as I can tell, most things are perfectly fine without that folder and its two symlinks. I would like some help testing removing this so I can get an idea of what issues people run into. There is bound to be some software that makes assumptions about /lib64 in its installation and I would like to know (a) how widespread that issue is and (b) how hard it is to work around. If you want to try it out, just remove the /lib64 folder (after making sure it only has symlinks to ld-2.13.so and ld-linux-x86-64.so.2 in it. Run your system as usual for a while and report any issues you come across. Thanks, Allan
Re: [arch-general] Something Broken with Perl!
On Thu, Jun 30, 2011 at 12:20:17PM -0700, Steve Holmes wrote: > On 6/30/11, gt wrote: > > perl-scalar-utils was available in aur earlier i think. But it was > > removed sometime back. > > Yeah, I figure this package replaced that one. Anyway, it contains > the library that is causing my problems. I wouldn't mind merely > removing this package but then the packages requiring > perl-scalar-list-utils will start complaining so I feel like I might > be getting trapped in dependency hell. If that library is indeed a > part of other standard packages, then at least automake should start > working again. Did you try rebuilding perl-scalar-list-utils?
Re: [arch-general] NOT SOLVED [was Re: Warning - Thunderbird 5 Breaks Access to pop accounts]
On 06/30/2011 04:23 PM, David C. Rankin wrote: Aargh! This is frustrating. On initial start, tbird 5 seems to check my accounts just fine, but when attempting a manual mail check, I get the following error: Sending of password did not succeed. Mail server pop.suddenlinkmail.com responded: please send PASS command Anybody know why this would happen? What to check? It is repeatable every time. I'll wireshark the communication and see if that help... Hmm.. This seems intermittent. It happens, then it doesn't happen. When the pop account succeeds, It works like it should: 0040 2d 90 2b 4f 4b 20 70 6c 65 61 73 65 20 73 65 6e -.+OK pl ease sen 0050 64 20 50 41 53 53 20 63 6f 6d 6d 61 6e 64 0d 0a d PASS c ommand.. I'll keep trying to capture the failure and try and figure out exactly where it is failing. Murphy's law - with wireshark running -- the login works :) -- David C. Rankin, J.D.,P.E.
[arch-general] NOT SOLVED [was Re: Warning - Thunderbird 5 Breaks Access to pop accounts]
On 06/30/2011 04:09 PM, David C. Rankin wrote: On 06/30/2011 09:25 AM, David C. Rankin wrote: On 06/29/2011 02:46 PM, Karol Babioch wrote: Hi, Am 29.06.2011 21:25, schrieb David C. Rankin: is part of it in xulrunner xulrunner isn't needed anymore, when I remember it right. What kind of security do you have on your mail server? Maybe there is a problem with certificate(s), or something like this. I hate to admit it, but this ISP has no security - it's "plain". So that might be confusing the smarter apps looking for a cert?? I can't explain it. I dropped back to tty1 and updated to tbird 5 again and this time all the pop accounts are working. I don't know what happened with the last update. The only difference this time was I exited the desktop before updating. It makes no sense, but whatever didn't work with the last install seems to be working fine now. Thanks for your thoughts and feedback letting me know it was working for you. Aargh! This is frustrating. On initial start, tbird 5 seems to check my accounts just fine, but when attempting a manual mail check, I get the following error: Sending of password did not succeed. Mail server pop.suddenlinkmail.com responded: please send PASS command Anybody know why this would happen? What to check? It is repeatable every time. I'll wireshark the communication and see if that help... -- David C. Rankin, J.D.,P.E.
[arch-general] SOLVED [was Re: Warning - Thunderbird 5 Breaks Access to pop accounts]
On 06/30/2011 09:25 AM, David C. Rankin wrote: On 06/29/2011 02:46 PM, Karol Babioch wrote: Hi, Am 29.06.2011 21:25, schrieb David C. Rankin: is part of it in xulrunner xulrunner isn't needed anymore, when I remember it right. What kind of security do you have on your mail server? Maybe there is a problem with certificate(s), or something like this. I hate to admit it, but this ISP has no security - it's "plain". So that might be confusing the smarter apps looking for a cert?? I can't explain it. I dropped back to tty1 and updated to tbird 5 again and this time all the pop accounts are working. I don't know what happened with the last update. The only difference this time was I exited the desktop before updating. It makes no sense, but whatever didn't work with the last install seems to be working fine now. Thanks for your thoughts and feedback letting me know it was working for you. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Something Broken with Perl!
On 6/30/11, gt wrote: > On Thu, Jun 30, 2011 at 05:42:47AM -0700, Steve Holmes wrote: >> After plowing through this thread, I am replying to say that the >> library in question belongs to perl-scalar-list-utils which can be >> found in AUr. It is required by other packages like >> perl-eval-closure. It is all part of a long list of cascading >> dependencies for perl-moos and perl-net-twitter. >> >> One other thing I observe with this package is that >> perl-scalar-list-utils has a 'replaces' entry, replacing >> perl-scalar-utils; I don't see that name in any repos nor my system at >> the moment. > > perl-scalar-utils was available in aur earlier i think. But it was > removed sometime back. Yeah, I figure this package replaced that one. Anyway, it contains the library that is causing my problems. I wouldn't mind merely removing this package but then the packages requiring perl-scalar-list-utils will start complaining so I feel like I might be getting trapped in dependency hell. If that library is indeed a part of other standard packages, then at least automake should start working again.
[arch-general] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2
This is a huge release and should stay in testing for a while. I want to
point out two significant changes:
1) We now have a build() function instead of an install() function - the
latter was an unfortunate conflict with the install utility. The hooks
in the repository have been adjusted, but backward-compatibility code is
in place (a deprecation warning will be printed). All these packages
have conflicts=(mkinitcpio<0.7).
2) We now use bsdcpio instead of gen_init_cpio. This obsoletes the
gen_init_cpio package and adds a dependency on libarchive. This also
speeds up the image generation considerably.
Other changes include massive cleanups and fixes, code refactoring, and
changes that should finally make the -b (basedir) option useful.
Please test and sign off.
Here comes the full shortlog:
Dave Reisner (52):
init: don't attempt modprobe if $MODULES is empty
mkinitcpio.conf: s/raid/mdadm/
mkinitcpio: deprecate install() in install hooks
dmesg: remove install/hook
functions: cleanup and refactor add_binary
functions: refactor add_module
functions: remove add_device
functions: remove add_symlink2
use bsdcpio to create images
functions: refactor add_file
functions: document hook API
mkinitcpio.conf: note implicit support for lzop
mkinitcpio: use simple PEs instead of externals
mkinitcpio: allow specifying kernel ver as path to image
lsinitcpio: new utility to dump contents of images
Makefile: refactor and simplify
mkinitcpio: bashify preset build loop
use consistent vim modelines
declare all variables in mkinitcpio
mkinitcpio: refactor and bashify early path calculations
declare SAVELIST, QUIET, SHOW_AUTOMODS as faux booleans
mkinitcpio: remove cruft in getopts loop
overhaul output, introducing color
functions: refactor add_symlink
functions: simplify parse_hook
mkinitcpio: bashification, part 1/2
mkinitcpio: bashification, part 2/2
add -t option to specify alternate build directory
install/keymap: refactor and bashify
mkinitcpio: declare usage as a heredoc
remove support for -m to add a startup message
install/base: cleanup and simplify
functions: remove get_module_name
init: declare PATH, remove absolute paths
init: remove unnecessary variable declarations
mkinitcpio: allow overriding the compression method
mkinitcpio: only show usage on request
mkinitcpio.5: alphabetize options for easier nav
README: update copyright year, add self as author
mkinitcpio: catch errors in parse_hook
add a PKGBUILD for easier testing from the repo
mkinitcpio: allow absolute paths to preset files
install/{sata,pata,scsi}: cleanup and simplify
properly support $BASEDIR
install/autodetect: refactor and simplify hook
functions: support $BASEDIR in modprobe
Makefile: the Makefile itself is a dep for the manpage
functions: add missing 'command' before install
functions: s/basedir/BASEDIR/
functions: fix pathing issue with $BASEDIR
install/base: use private API call to add config
mkinitcpio: fix resolution issues with RTLD
Eric Bélanger (1):
Added usbinput to default hooks (implements FS#19328)
Gerardo Exequiel Pozzi (3):
Fix some install hooks due recent change in all_modules()
Add missing /etc/bash_completion.d in Makefile
Add asciidoc as makedepends in private PKGBUILD.
Sebastien Luttringer (6):
Add bash completion to mkinitcpio
Fix printing of bash usage when asking for a bad hook
Print pretty message if no help is defined in hook
Use error function instead of echo
Add lsinitcpio bash completion
Use _get_comp_words_by_ref in bash completion
Thomas Bächler (7):
Merge branch 'master' of https://github.com/seblu/arch-mkinitcpio
into working
Remove old '-m' option from bash completion.
emove old '-a' option from bash completion and fix '-s' option.
Merge branch 'working'
Add .gitignore file
install/keymap: fix installation ($buildroot -> $BUILDROOT)
Release version 0.7
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Something Broken with Perl!
On Thu, Jun 30, 2011 at 05:42:47AM -0700, Steve Holmes wrote: > After plowing through this thread, I am replying to say that the > library in question belongs to perl-scalar-list-utils which can be > found in AUr. It is required by other packages like > perl-eval-closure. It is all part of a long list of cascading > dependencies for perl-moos and perl-net-twitter. > > One other thing I observe with this package is that > perl-scalar-list-utils has a 'replaces' entry, replacing > perl-scalar-utils; I don't see that name in any repos nor my system at > the moment. perl-scalar-utils was available in aur earlier i think. But it was removed sometime back.
Re: [arch-general] Warning - Thunderbird 5 Breaks Access to pop accounts
On 06/29/2011 02:46 PM, Karol Babioch wrote: Hi, Am 29.06.2011 21:25, schrieb David C. Rankin: is part of it in xulrunner xulrunner isn't needed anymore, when I remember it right. What kind of security do you have on your mail server? Maybe there is a problem with certificate(s), or something like this. I hate to admit it, but this ISP has no security - it's "plain". So that might be confusing the smarter apps looking for a cert?? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Something Broken with Perl!
On Thu, Jun 30, 2011 at 09:13:31AM +0300, Ionut Biru wrote: > On 06/30/2011 03:35 AM, Steve Holmes wrote: > >I think when perl was upgraded to 5.14, something broke with one of > >its libraries. Whenever I type 'automake' or attempt to recompile > >several perl packages from AUR, I get the following error message: > >/usr/bin/perl: symbol lookup error: > >/usr/lib/perl5/vendor_perl/auto/List/Util/Util.so: undefined symbol: > >Perl_Istack_sp_ptr > > > >Thoughts anyone? I see this as a show stopper for any development > >right now. > > > >Thanks. > > > pacman -Qo /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so > > maybe you installed some perl modules outside of pacman perl-scalar-list-utils - found in AUR; it is required by perl-eval-closure and replaces perl-scalar-utils.
Re: [arch-general] Something Broken with Perl!
On Thu, Jun 30, 2011 at 02:23:23PM +0200, Thomas Bächler wrote: > Am 30.06.2011 13:25, schrieb Casey Peter: > > On 06/30/2011 05:08 AM, Thomas Bächler wrote: > >> Am 30.06.2011 12:59, schrieb Jelle van der Waa: > >>> This discussion needs more info: > >>> pacman -Q perl mod_perl those two provide XSLoader.pm. > >> They provide it, but at a different path. The file mentioned here is not > >> contained in any package we built. > >> > > Not a clue at this point. Yesterday, ptal-init worked fine. perl > > upgrade and now that error on boot up. > > You have a file on your system that causes breakage, and is either not > tracked by pacman, or contained in a non-official package. Isn't the > solution obvious here? In the first case, delete the file, in the second > case, delete the broken package. > After plowing through this thread, I am replying to say that the library in question belongs to perl-scalar-list-utils which can be found in AUr. It is required by other packages like perl-eval-closure. It is all part of a long list of cascading dependencies for perl-moos and perl-net-twitter. One other thing I observe with this package is that perl-scalar-list-utils has a 'replaces' entry, replacing perl-scalar-utils; I don't see that name in any repos nor my system at the moment.
Re: [arch-general] Something Broken with Perl!
Am 30.06.2011 13:25, schrieb Casey Peter: > On 06/30/2011 05:08 AM, Thomas Bächler wrote: >> Am 30.06.2011 12:59, schrieb Jelle van der Waa: >>> This discussion needs more info: >>> pacman -Q perl mod_perl those two provide XSLoader.pm. >> They provide it, but at a different path. The file mentioned here is not >> contained in any package we built. >> > Not a clue at this point. Yesterday, ptal-init worked fine. perl > upgrade and now that error on boot up. You have a file on your system that causes breakage, and is either not tracked by pacman, or contained in a non-official package. Isn't the solution obvious here? In the first case, delete the file, in the second case, delete the broken package. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Synaptics Gesture Suite on Arch?
On Thu, Jun 30, 2011 at 12:51 PM, Alper Kanat wrote: > For such questions I'd like to remind the following XKCD: > http://xkcd.com/619/ Actually, I also uploaded something yesterday, although was reluctant to post because it's way OT. Sorry for this. http://i.imgur.com/pxSNG.jpg
Re: [arch-general] Something Broken with Perl!
On 06/30/2011 05:52 AM, John K Pate wrote: I do have a few AUR packages on my system, but no breakages from anything other than ptal-init as reported. I had a breakage (with the same error message) with rxvt-unicode-chinese from the AUR, but it was resolved upon upgrading to the new version. I don't know if the fix was due to recompiling or the new version, however. == John K Pate http://homepages.inf.ed.ac.uk/s0930006/ Trouble with this is...breakage is not AUR related (that I'm aware of)...nor was any of the package(s) updated AUR related. The reboot was for the kernel, or I might not have seen this for a bit. :-/ C
Re: [arch-general] Something Broken with Perl!
> I do have a few AUR packages on my system, but no breakages from > anything other than ptal-init as reported. I had a breakage (with the same error message) with rxvt-unicode-chinese from the AUR, but it was resolved upon upgrading to the new version. I don't know if the fix was due to recompiling or the new version, however. == John K Pate http://homepages.inf.ed.ac.uk/s0930006/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: [arch-general] Something Broken with Perl!
On 06/30/2011 05:08 AM, Thomas Bächler wrote: Am 30.06.2011 12:59, schrieb Jelle van der Waa: This discussion needs more info: pacman -Q perl mod_perl those two provide XSLoader.pm. They provide it, but at a different path. The file mentioned here is not contained in any package we built. Not a clue at this point. Yesterday, ptal-init worked fine. perl upgrade and now that error on boot up. Just passing the info along. I do have a few AUR packages on my system, but no breakages from anything other than ptal-init as reported. C
Re: [arch-general] Something Broken with Perl!
Am 30.06.2011 12:59, schrieb Jelle van der Waa: > This discussion needs more info: > pacman -Q perl mod_perl those two provide XSLoader.pm. They provide it, but at a different path. The file mentioned here is not contained in any package we built. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Something Broken with Perl!
On 06/30/2011 12:51 PM, Thomas Bächler wrote:
Am 30.06.2011 11:54, schrieb Casey Peter:
On 06/30/2011 03:33 AM, Thomas Bächler wrote:
Am 30.06.2011 11:09, schrieb Casey Peter:
I'm seeing this during boot:
Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module',
$Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25.
Wed Jun 29 14:48:09 2011: Compilation failed in require at
/etc/rc.d/ptal-init line 115.
Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at
/etc/rc.d/ptal-init line 11
with regard to the ptal-init for my hp officejet. Is this related?
This file is not part of any Arch package either.
Actually, it is. It is a script required for the officejet series of
printers included in this package:
I am talking about /usr/lib/perl5/core_perl/XSLoader.pm.
This discussion needs more info:
pacman -Q perl mod_perl those two provide XSLoader.pm.
Btw i can't see that hpoj has been rebuild for perl, but it doesn't fail
here with /etc/rc.d/ptal-init
--
Jelle van der Waa
Re: [arch-general] Synaptics Gesture Suite on Arch?
For such questions I'd like to remind the following XKCD: http://xkcd.com/619/ --- Quis custodiet ipsos custodes? On Wed, Jun 29, 2011 at 13:47, Christian Hesse wrote: > > Why would someone want to have a 'synaptics gesture suite'? >
Re: [arch-general] Something Broken with Perl!
Am 30.06.2011 11:54, schrieb Casey Peter:
> On 06/30/2011 03:33 AM, Thomas Bächler wrote:
>> Am 30.06.2011 11:09, schrieb Casey Peter:
>>> I'm seeing this during boot:
>>>
>>> Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module',
>>> $Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25.
>>> Wed Jun 29 14:48:09 2011: Compilation failed in require at
>>> /etc/rc.d/ptal-init line 115.
>>> Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at
>>> /etc/rc.d/ptal-init line 11
>>>
>>> with regard to the ptal-init for my hp officejet. Is this related?
>> This file is not part of any Arch package either.
>>
> Actually, it is. It is a script required for the officejet series of
> printers included in this package:
I am talking about /usr/lib/perl5/core_perl/XSLoader.pm.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Something Broken with Perl!
On 06/30/2011 03:33 AM, Thomas Bächler wrote:
Am 30.06.2011 11:09, schrieb Casey Peter:
I'm seeing this during boot:
Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module',
$Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25.
Wed Jun 29 14:48:09 2011: Compilation failed in require at
/etc/rc.d/ptal-init line 115.
Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at
/etc/rc.d/ptal-init line 11
with regard to the ptal-init for my hp officejet. Is this related?
This file is not part of any Arch package either.
Actually, it is. It is a script required for the officejet series of
printers included in this package:
@Kandalf ~]$ pacman -Ss hpoj
extra/hpoj 0.91-16 [installed]
Hewlett-Packard OfficeJet, PSC, LaserJet, and PhotoSmart printer
multi-function peripherals (MFPs) drivers
and is placed in the rc.conf to initialize the printer.
example: DAEMONS=(syslog-ng !hwclcock crond dbus networkmanager ntpd
!alsa avahi-daemon_ptal-ini_t @cups clamav sensors dropboxd netfs)
Casey
Re: [arch-general] Something Broken with Perl!
Am 30.06.2011 11:09, schrieb Casey Peter:
> I'm seeing this during boot:
>
> Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module',
> $Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25.
> Wed Jun 29 14:48:09 2011: Compilation failed in require at
> /etc/rc.d/ptal-init line 115.
> Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at
> /etc/rc.d/ptal-init line 11
>
> with regard to the ptal-init for my hp officejet. Is this related?
This file is not part of any Arch package either.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Something Broken with Perl!
On 06/30/2011 02:32 AM, Thomas Bächler wrote:
Am 30.06.2011 02:35, schrieb Steve Holmes:
/usr/bin/perl: symbol lookup error:
/usr/lib/perl5/vendor_perl/auto/List/Util/Util.so: undefined symbol:
Perl_Istack_sp_ptr
That file is not part of any package in the Arch repositories.
I'm seeing this during boot:
Wed Jun 29 14:48:09 2011: XSLoader::load('Your::Module',
$Your::Module::VERSION) at /usr/lib/perl5/core_perl/XSLoader.pm line 25.
Wed Jun 29 14:48:09 2011: Compilation failed in require at
/etc/rc.d/ptal-init line 115.
Wed Jun 29 14:48:09 2011: BEGIN failed--compilation aborted at
/etc/rc.d/ptal-init line 11
with regard to the ptal-init for my hp officejet. Is this related?
Bog standard arch 64 box updated to current updates as of 6/29/11...no
issues other than this, but it breaks the printer.
Casey
Re: [arch-general] Something Broken with Perl!
Am 30.06.2011 02:35, schrieb Steve Holmes: > /usr/bin/perl: symbol lookup error: > /usr/lib/perl5/vendor_perl/auto/List/Util/Util.so: undefined symbol: > Perl_Istack_sp_ptr That file is not part of any package in the Arch repositories. signature.asc Description: OpenPGP digital signature
