Re: [arch-general] namcap.log in clean chroot
On Fri, 2009-06-12 at 11:07 +1000, Allan McRae wrote: > Baho Utot wrote: > > On Fri, 2009-06-12 at 10:27 +1000, Allan McRae wrote: > > > >> Baho Utot wrote: > >> > >>> I have install namcap to my clean chroot and it gives me this error: > >>> > >>> Error: Problem reading *.pkg.tar.gz > >>> usage: /usr/bin/namcap [-r rulelist | --rules=rulelist] [-i | --info] > >>> package .. > >>>-r list: returns list of available rules > >>>-i : prints information responses from rules > >>> > >>> Is there anything extra I need to do to get namcap working in clean > >>> chroot? > >>> > >>> > >> It is running but not finding any packages in the directory it is > >> looking at... > >> > >> Allan > >> > > > > Why not? I am using the arch devtools scripts and it is called from > > there. I am not calling it I think the makechrootpkg is calling it but > > I don't know for sure as I have not looked at the script > > > > The namcap.log file is in /home/Chroot/rw/pkgdest sub directory. > > > > I am using sudo makechroot -c -r /home/Chroot -u -- --noconfirm to run > > the clean chroot build. > > > > Should it not find the package? > > > > Well, you seem to be using the unreleased devtools from git so it could > be broken. I do not like having namcap (and hence python) in a "clean" > chroot so have never tested. > > Allan > > > > Yes I am using a git version, unionfs didn't work on my clean install and some one here gave me a url to the git version to work with aufs2 Does the unionfs work on a new install? I had trouble building in a clean chroot on my new install, it kept failing because unionfs was nissing.
Re: [arch-general] namcap.log in clean chroot
Baho Utot wrote: On Fri, 2009-06-12 at 10:27 +1000, Allan McRae wrote: Baho Utot wrote: I have install namcap to my clean chroot and it gives me this error: Error: Problem reading *.pkg.tar.gz usage: /usr/bin/namcap [-r rulelist | --rules=rulelist] [-i | --info] package .. -r list: returns list of available rules -i : prints information responses from rules Is there anything extra I need to do to get namcap working in clean chroot? It is running but not finding any packages in the directory it is looking at... Allan Why not? I am using the arch devtools scripts and it is called from there. I am not calling it I think the makechrootpkg is calling it but I don't know for sure as I have not looked at the script The namcap.log file is in /home/Chroot/rw/pkgdest sub directory. I am using sudo makechroot -c -r /home/Chroot -u -- --noconfirm to run the clean chroot build. Should it not find the package? Well, you seem to be using the unreleased devtools from git so it could be broken. I do not like having namcap (and hence python) in a "clean" chroot so have never tested. Allan
[arch-general] gmine build problem
I am try ing to build gmine and get this error make[3]: Nothing to be done for `install-data-am'. make[3]: Leaving directory `/build/src/gmime-2.2.21/src' make[2]: Leaving directory `/build/src/gmime-2.2.21/src' make[1]: Leaving directory `/build/src/gmime-2.2.21/src' Making install in mono make[1]: Entering directory `/build/src/gmime-2.2.21/mono' make[2]: Entering directory `/build/src/gmime-2.2.21/mono' make[2]: Nothing to be done for `install-exec-am'. /usr/bin/gacutil /i gmime-sharp.dll /f /package gmime-sharp /gacdir /build/pkg/lib Failure adding assembly gmime-sharp.dll to the cache: Strong name cannot be verified for delay-signed assembly make[2]: *** [install-data-local] Error 1 make[2]: Leaving directory `/build/src/gmime-2.2.21/mono' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/build/src/gmime-2.2.21/mono' make: *** [install-recursive] Error 1 ==> ERROR: Build Failed. Aborting... ==> Removing installed dependencies... checking dependencies... Any one know what this is about? Got a fix?
Re: [arch-general] namcap.log in clean chroot
On Fri, 2009-06-12 at 10:27 +1000, Allan McRae wrote: > Baho Utot wrote: > > I have install namcap to my clean chroot and it gives me this error: > > > > Error: Problem reading *.pkg.tar.gz > > usage: /usr/bin/namcap [-r rulelist | --rules=rulelist] [-i | --info] > > package .. > >-r list: returns list of available rules > >-i : prints information responses from rules > > > > Is there anything extra I need to do to get namcap working in clean > > chroot? > > > > It is running but not finding any packages in the directory it is > looking at... > > Allan Why not? I am using the arch devtools scripts and it is called from there. I am not calling it I think the makechrootpkg is calling it but I don't know for sure as I have not looked at the script The namcap.log file is in /home/Chroot/rw/pkgdest sub directory. I am using sudo makechroot -c -r /home/Chroot -u -- --noconfirm to run the clean chroot build. Should it not find the package?
Re: [arch-general] namcap.log in clean chroot
Baho Utot wrote: I have install namcap to my clean chroot and it gives me this error: Error: Problem reading *.pkg.tar.gz usage: /usr/bin/namcap [-r rulelist | --rules=rulelist] [-i | --info] package .. -r list: returns list of available rules -i : prints information responses from rules Is there anything extra I need to do to get namcap working in clean chroot? It is running but not finding any packages in the directory it is looking at... Allan
[arch-general] namcap.log in clean chroot
I have install namcap to my clean chroot and it gives me this error: Error: Problem reading *.pkg.tar.gz usage: /usr/bin/namcap [-r rulelist | --rules=rulelist] [-i | --info] package .. -r list: returns list of available rules -i : prints information responses from rules Is there anything extra I need to do to get namcap working in clean chroot?
Re: [arch-general] Installing packages with different glibc
Jan de Groot schrieb: Usually glibc and libstdc++ are backwards compatible. ABI doesn't change so programs compiled against older versions will always work with newer libraries. It's about forward compatibility. If you compile a program with a newer libstdc++, it will often not work with an older one. There's an exception though: programs that do their library versioning after the compiler that was used. Examples of this are Qt and Boost. Compiling Qt 3.x with gcc 4.4 meant recompiling KDE 3.x things because ABI changed in Qt because of a compiler change. This is still true for boost, but not for Qt 4. Qt 3 however is really annoying in that respect. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
Stiler (in AUR) allows tiling within openbox. I find it to be quite a nice program in conjunction with xbindkeys. Ben On Wed, Jun 10, 2009 at 5:47 AM, Andrei Thorp wrote: > I come from a place where they say, "Friends don't let friends use > non-tiling window managers" ;) > > As such, while we're on the topic, I think nothing really gives you > your bang for your computer power like a tiling wm does. > > Some of the best ones now seem to be: > > - Xmonad > - Wmii > - Awesome WM (My personal favourite which comes with a run prompt, > menus, and notifications built in) > > These systems tend to take more effort to run, but are very rewarding > when you learn them. They let you work faster and better than ever, > and are some of the most customizable window managers ever made. I've > also noted a rather large community within Arch that uses tiling WMs > and especially Awesome where it seems like half the IRC channel's on > Arch. > > Sorry for the plug, cheers ;) > > -AT >
Re: [arch-general] building vorbis-tools
On Thu, 2009-06-11 at 11:08 +0200, Jan de Groot wrote:
> On Thu, 2009-06-11 at 11:00 +0200, Andrea Scarpino wrote:
> > ==> Finished making: vorbis-tools 1.2.0-3 i686 (Thu Jun 11 10:56:54 CEST
> > 2009)
> >
> > Did you remove srcdir?
> > autoconf 2.63-1
>
> > > build()
> > > {
> > > cd $startdir/src/$pkgname-$pkgver
> > > autoconf
> > > ./configure --prefix=/usr --without-speex
> > > make || return 1
> > > make DESTDIR=$startdir/pkg install
> > > }
> > >
> > >
> > > what could cause this error?
>
> The fact that there's no || return 1 anywhere and autoconf fails
> silently on most setups doesn't mean there's no error. I don't see the
> need to run autoconf here, as there's no patching done to configure.ac
> here. If autoconf is needed, the whole autocrap should be used, not just
> autoconf.
>
I'll try it without the autoconf
But..
Then a bug report would be in order to remove autoconf from the PKGBUILD
file
Re: [arch-general] building vorbis-tools
On Thu, 2009-06-11 at 11:00 +0200, Andrea Scarpino wrote: > ==> Finished making: vorbis-tools 1.2.0-3 i686 (Thu Jun 11 10:56:54 CEST 2009) > > Did you remove srcdir? > autoconf 2.63-1 > > On 11/06/2009, Baho Utot wrote: > > vorbis-tools gives me the following error > > > > -> bsdtar -x -f vorbis-tools-1.2.0.tar.gz > > ==> Entering fakeroot environment... > > ==> Starting build()... > > aclocal.m4:14: error: this file was generated for autoconf 2.61. > > You have another version of autoconf. If you want to use that, > > you should regenerate the build system entirely. > > aclocal.m4:14: the top level > > autom4te: /usr/bin/m4 failed with exit status: 63 > > ==> ERROR: Build Failed. > > Aborting... I am building with clean chroot
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
> +1 for dwm/dmenu. I really like grouping by tags. Awesome certainly has tag-based management, and Xmonad probably also does considering it was a DWM clone once. In Awesome, at least, dmenu's pretty much obsoleted by Awesome's own built-in panels and tags have been taken much further than dwm due to the shifty add-on library that allows dynamic creation + deletion of tags, even based on events. Ex -> hit a bind to make a new tag (type to name it); set it up so when firefox opens, it gets its own tag, and that tag exists until firefox closes. -AT
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
On Thu, Jun 11, 2009 at 03:52:11AM +0800, Samuel Baldwin wrote: > dwm[0] is a great place to start as well, especially if you're > familiar with C and can patch it to your liking. The defaults are > perfectly fine (besides colours), though, and once you get your head > around tag-based window management, it's all you'll ever want. > > With dmenu, of course. > > [0] http://dwm.suckless.org/ +1 for dwm/dmenu. I really like grouping by tags.
Re: [arch-general] Stolen Logo
On Wed, Jun 10, 2009 at 2:31 PM, Andrew Przepioski wrote: > Damn, that's a nice story! That's probably how it all went down. ;) Yeah :D Or maybe the art guy saw the logo on the background of a web developer's computer ;) -AT
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
> If you have a lot of terminals, a tabbed or split-screen terminal app, like > Konsole or Terminator is probably more efficient. Disagreed, tiling window managers are entirely designed for tiling stuff. They tend to be _much_ better at it than stuff like screen and Terminator. I'm pretty confident in this assessment because I used screen for quite a while before I got into tiling. It's just not the same. Also, it's not even necessarily better on ram. If you're using a smart terminal like urxvt or XFCE Terminal, they can run in a shared mode where running a ton of terminals doesn't really skyrocket your ram (unlike gnome-terminal for example). -AT
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
> Just to crush the urban myth that gets mentioned more than it should be > recently: xmonad is not based on dwm. Yes, the idea of what should it do came > from dwm, but it was written from scratch (in haskell, no C code ever). Ah, understood. I think I read something about this like it's "based" on DWM, and I guess that means conceptually rather than literally. Sorry! -AT
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
> I like a lot yakuake for tabbed terminal. using konsole technologies, it add > a pretty cool drop-down feature, which allow to have a term at any moment, > just by typing F12. The nice things about some of these more powerful window managers is that it's pretty simple to write a bit of configuration to make this work for _any_ terminal or program. -AT
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
> In fact, Kris Maglione is preparing a new wmii release and he has been > spending a lot of effort in writing a new user guide. I've proof read > it (see suckless ML, and wmii source repo) and it's looking good. > "Not developed any longer" is just plain nonsense. Yep, sorry, I've been misinformed. -AT
Re: [arch-general] High fragmentation rate with ext4?
2009/6/11 Cá Vàng : > Hello everyone! > > As linux 2.6.30 is out, I decided to migrate my data partition to > ext4. Hoping for better performance and less fragmentation. > > But, after format it with "mkfs.ext4 - largefile /dev/..." and copy > all the file back to the partition, I got whooping number of 30% > non-contiguous files! Then I reformat it with reserved block set to > 10% (-m 10), still got the same fragment rate :-( Some updates, I tested copy one big file (about 3.6 GBs) to the new partition, and this is what I get: (ext3 mount as ext3)image.iso: 31 extents found, perfection would be 29 extents (ext3 mount as ext4)image.iso: 960 extents found, perfection would be 29 extents -- My job: Writing buggy softwares to make the world a worse place for humanity ( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼
Re: [arch-general] Installing packages with different glibc
On Thu, 2009-06-11 at 11:48 +0200, Thomas Bächler wrote: > This is > not often the case in glibc, but there's many more problems with C++ > programs and the standard C++ libs. Usually glibc and libstdc++ are backwards compatible. ABI doesn't change so programs compiled against older versions will always work with newer libraries. There's an exception though: programs that do their library versioning after the compiler that was used. Examples of this are Qt and Boost. Compiling Qt 3.x with gcc 4.4 meant recompiling KDE 3.x things because ABI changed in Qt because of a compiler change.
[arch-general] High fragmentation rate with ext4?
Hello everyone! As linux 2.6.30 is out, I decided to migrate my data partition to ext4. Hoping for better performance and less fragmentation. But, after format it with "mkfs.ext4 - largefile /dev/..." and copy all the file back to the partition, I got whooping number of 30% non-contiguous files! Then I reformat it with reserved block set to 10% (-m 10), still got the same fragment rate :-( Okay, so I try it again, this time with ext3, then I do a "mount -a" to remount all the partitions, copy some files (size between 2 MBs~40 MBs) back in, guess what? This is the result of fsck: 81 inodes used (0.07%) 69 non-contiguous files (85.2%) Then I remember that "mount -a" mount the partition as ext4 (since I haven't changed my fstab yet), okay, so I format it again, and mount it with "mount -t ext3 ", copy some files in and this is the result: 81 inodes used (0.07%) 9 non-contiguous files (11.1%) Still not as good as it was before, but much better than the 85.2 rate above. So is this a bug? Does anyone have this problem? My e2fsprogs version is 1.41.5-2
Re: [arch-general] Installing packages with different glibc
Gerardo Exequiel Pozzi schrieb: Baho Utot wrote: Does it create complications if I install packages built with a newer glibc-2.10.1-2 on a system with an older glibc-2.9-7? Yes and no. Depending if the executable or library that is linked to glibc uses a symbol with declaring what version use via ELF versioning. You obtain it with a simple "readelf -s /path/to/executable | grep @GLIBC_2.10". Do this "readelf -s /lib/libc.so.6 | grep @GLIBC_2.10" and get an idea of the minimal functions that are only in version 2.10 ;) I'm just taking a quick look over some random binaries: $ readelf -s file | grep @GLIBC|cut -d@ -f2 | cut -d\ -f1|sort -u For /bin/bash, this tells me our bash should work with glibc 2.4. /bin/ls should even work with 2.3. In general, all should work unless a new symbol is used, or an old symbol had incompatible changes. This is not often the case in glibc, but there's many more problems with C++ programs and the standard C++ libs. signature.asc Description: OpenPGP digital signature
Re: [arch-general] building vorbis-tools
On Thu, 2009-06-11 at 11:00 +0200, Andrea Scarpino wrote:
> ==> Finished making: vorbis-tools 1.2.0-3 i686 (Thu Jun 11 10:56:54 CEST 2009)
>
> Did you remove srcdir?
> autoconf 2.63-1
> > build()
> > {
> > cd $startdir/src/$pkgname-$pkgver
> > autoconf
> > ./configure --prefix=/usr --without-speex
> > make || return 1
> > make DESTDIR=$startdir/pkg install
> > }
> >
> >
> > what could cause this error?
The fact that there's no || return 1 anywhere and autoconf fails
silently on most setups doesn't mean there's no error. I don't see the
need to run autoconf here, as there's no patching done to configure.ac
here. If autoconf is needed, the whole autocrap should be used, not just
autoconf.
Re: [arch-general] Installing packages with different glibc
On Thu, 2009-06-11 at 10:54 +0200, Jan de Groot wrote: > On Thu, 2009-06-11 at 04:53 -0400, Baho Utot wrote: > > On Wed, 2009-06-10 at 22:05 -0400, Daenyth Blank wrote: > > > On Wed, Jun 10, 2009 at 19:45, Baho Utot wrote: > > > > Does it create complications if I install packages built with a newer > > > > glibc-2.10.1-2 on a system with an older glibc-2.9-7? > > > > > > > > According to LFS they say if you chnage glibc you should rebuilt all the > > > > installed packages with the newer glibc. > > > > > > > > Does this hold true for Arch? > > > > > > > Any packages in a repo should be fine. Other than that, try it. If you > > > get errors, recompile :P > > > > OH Yea try he says > > > > pacman -Syu > > installing stuff > > shutdown -r now.. broken desktop machine :P > > What is the reason exactly for using glibc 2.9-7 instead of 2.10 btw? Actually I have not tried it yet. I am compiling/building in a clean chroot and it has 2.10 installed there but one of my systems has 2.9-7 installed. I didn't want to break the system by installing packages built from the clean chroot w/2.10. I will upgrade the glibc to 2.10 later after I am OK with it if it happens to break something, as I need the system not to break until next month. :) Then if it breaks it will be OK.
Re: [arch-general] building vorbis-tools
==> Finished making: vorbis-tools 1.2.0-3 i686 (Thu Jun 11 10:56:54 CEST 2009)
Did you remove srcdir?
autoconf 2.63-1
On 11/06/2009, Baho Utot wrote:
> vorbis-tools gives me the following error
>
> -> bsdtar -x -f vorbis-tools-1.2.0.tar.gz
> ==> Entering fakeroot environment...
> ==> Starting build()...
> aclocal.m4:14: error: this file was generated for autoconf 2.61.
> You have another version of autoconf. If you want to use that,
> you should regenerate the build system entirely.
> aclocal.m4:14: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> ==> ERROR: Build Failed.
> Aborting...
>
> autoconf is in the PKGBUILD file
>
> build()
> {
> cd $startdir/src/$pkgname-$pkgver
> autoconf
> ./configure --prefix=/usr --without-speex
> make || return 1
> make DESTDIR=$startdir/pkg install
> }
>
>
> what could cause this error?
>
>
--
Andrea `BaSh` Scarpino
Arch Linux Developer
Re: [arch-general] Installing packages with different glibc
On Thu, 2009-06-11 at 04:53 -0400, Baho Utot wrote: > On Wed, 2009-06-10 at 22:05 -0400, Daenyth Blank wrote: > > On Wed, Jun 10, 2009 at 19:45, Baho Utot wrote: > > > Does it create complications if I install packages built with a newer > > > glibc-2.10.1-2 on a system with an older glibc-2.9-7? > > > > > > According to LFS they say if you chnage glibc you should rebuilt all the > > > installed packages with the newer glibc. > > > > > > Does this hold true for Arch? > > > > > Any packages in a repo should be fine. Other than that, try it. If you > > get errors, recompile :P > > OH Yea try he says > > pacman -Syu > installing stuff > shutdown -r now.. broken desktop machine :P What is the reason exactly for using glibc 2.9-7 instead of 2.10 btw?
Re: [arch-general] Installing packages with different glibc
On Wed, 2009-06-10 at 22:05 -0400, Daenyth Blank wrote: > On Wed, Jun 10, 2009 at 19:45, Baho Utot wrote: > > Does it create complications if I install packages built with a newer > > glibc-2.10.1-2 on a system with an older glibc-2.9-7? > > > > According to LFS they say if you chnage glibc you should rebuilt all the > > installed packages with the newer glibc. > > > > Does this hold true for Arch? > > > Any packages in a repo should be fine. Other than that, try it. If you > get errors, recompile :P OH Yea try he says pacman -Syu installing stuff shutdown -r now.. broken desktop machine :P
[arch-general] building vorbis-tools
vorbis-tools gives me the following error
-> bsdtar -x -f vorbis-tools-1.2.0.tar.gz
==> Entering fakeroot environment...
==> Starting build()...
aclocal.m4:14: error: this file was generated for autoconf 2.61.
You have another version of autoconf. If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:14: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
==> ERROR: Build Failed.
Aborting...
autoconf is in the PKGBUILD file
build()
{
cd $startdir/src/$pkgname-$pkgver
autoconf
./configure --prefix=/usr --without-speex
make || return 1
make DESTDIR=$startdir/pkg install
}
what could cause this error?
Re: [arch-general] Installing packages with different glibc
On Wed, 2009-06-10 at 23:49 -0300, Gerardo Exequiel Pozzi wrote: > Baho Utot wrote: > > Does it create complications if I install packages built with a newer > > glibc-2.10.1-2 on a system with an older glibc-2.9-7? > > > Yes and no. Depending if the executable or library that is linked to > glibc uses a symbol with declaring what version use via ELF versioning. > You obtain it with a simple "readelf -s /path/to/executable | grep > @GLIBC_2.10". > > Do this "readelf -s /lib/libc.so.6 | grep @GLIBC_2.10" and get an idea > of the minimal functions that are only in version 2.10 ;) > > And for threaded programs /lib/libpthread-2.10.1.so, but don't worry > about this at this time. > > > According to LFS they say if you chnage glibc you should rebuilt all the > > installed packages with the newer glibc. > > > Not at all as you can see :) > > > Does this hold true for Arch? > > > I doubt at this time. But later when the programs use specific features > of this version, for example malloc_info () fallocate (), yes. > > > If you are interested in these topics, can read a good paper from Ulrich > Drepper [#1] > > > Good Luck! > > > [#1] http://people.redhat.com/drepper/dsohowto.pdf > Ok more reading to do :) Thanks
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
On Wed, 10 Jun 2009 23:46:55 +0100 Damian wrote: > On Wed, 10 Jun 2009 17:02:39 -0400 > Andrei Thorp wrote: > > > Yeah, I think the big thing about using a tiling window manager is > > that it works best if you have a lot of terminals -- though > > reasonable ones (Awesome included) have a floating mode with > > regular windows with titlebars that is a lot like typical window > > managers. > > > > And yeah, shame but: > > - Wmii isn't really developed any longer, which is too bad because > > people really loved it. > > > > Cheers, > > > > -AT > > > > Alot of people think this which a shame tbh, wmii is still being > maintained quite religiously. Have a look at google code > http://code.google.com/p/wmii/updates/list to see latest updates. > It's a superb twm, great sane defaults but slightly lacking in > documentation of any real depth, although a new wiki is being worked > on. > In fact, Kris Maglione is preparing a new wmii release and he has been spending a lot of effort in writing a new user guide. I've proof read it (see suckless ML, and wmii source repo) and it's looking good. "Not developed any longer" is just plain nonsense. Dieter
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
2009/6/10 David Rosenstrauch > Andrei Thorp wrote: > >> Yeah, I think the big thing about using a tiling window manager is >> that it works best if you have a lot of terminals >> > > If you have a lot of terminals, a tabbed or split-screen terminal app, like > Konsole or Terminator is probably more efficient. > > DR I like a lot yakuake for tabbed terminal. using konsole technologies, it add a pretty cool drop-down feature, which allow to have a term at any moment, just by typing F12.
