[arch-general] Recent upgrade of vimgvim generates assertion errors in console
Hi guys, Just paste my post from forum. Have you guys encountered this issue after recent upgrades of vim gvim: ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed This happens when running gvim in the console. It works all fine except the warnings. Downgrading to version 7.2.266 can avoid this. Best Regards -- LI Ye
Re: [arch-general] CDROM cannot mount
On Thu, Feb 18, 2010 at 20:50, clemens fischer ino-n...@spotteswoode.dnsalias.org wrote: I thought multi-session CDs must be finished or finalized before they can be fully used? Do not know...my pc boots them without problems...so i think it's not a problem of writing method...
Re: [arch-general] Recent upgrade of vimgvim generates assertion errors in console
On Fri, Feb 19, 2010 at 08:00, LI Ye leeyee@gmail.com wrote: Hi guys, Just paste my post from forum. Have you guys encountered this issue after recent upgrades of vim gvim: ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed This happens when running gvim in the console. It works all fine except the warnings. Downgrading to version 7.2.266 can avoid this. I see exactly the same thing, but since it doesn't seem to hurt I decided to simply wait for the vim developers to fix this at some point in the future. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Re: [arch-general] pacman.conf: can I use wildcards?
Am Fri, 19 Feb 2010 06:51:40 +0100 schrieb Attila vodoo0...@sonnenkinder.org: Oh, so if someone use 'usr/lib/*' than the lib of every new or updated package will get installed with the '.pacnew' ending? Right, that's what NoUpgrade in pacman.conf does. ;-) Greetings, Heiko
[arch-general] Was the kernel suspend to disk feature removed on 2.6.32.8-1
Hi all, Previously I was having the following settings: /etc/default/grub -- GRUB_CMDLINE_LINUX_DEFAULT='resume=/dev/sda5' grub.cfg --- linux /vmlinuz26 root=/dev/sda7 ro resume=/dev/sda5 I have installed: acpitool 0.5.1-1 kernel26 2.6.32.8-1 And fro quiet a long time I've been using the kernel suspend feature through acpitool, so in order to suspend I've always done: acpitool -S As of now, it seems storing the state into the swap area is working. Problem is that when booting, the kernel is not even trying to see if there's state stored in the swap, since I don't see any message about it, and all I'm getting is plain boot. So I suspect the kernel is not compiled with built in support for suspend to disk. Is this true? Thanks, -- Javier.
Re: [arch-general] Was the kernel suspend to disk feature removed on 2.6.32.8-1
On Fri, Feb 19, 2010 at 10:37 AM, Javier Vasquez j.e.vasque...@gmail.com wrote: Hi all, Previously I was having the following settings: /etc/default/grub -- GRUB_CMDLINE_LINUX_DEFAULT='resume=/dev/sda5' grub.cfg --- linux /vmlinuz26 root=/dev/sda7 ro resume=/dev/sda5 I have installed: acpitool 0.5.1-1 kernel26 2.6.32.8-1 And fro quiet a long time I've been using the kernel suspend feature through acpitool, so in order to suspend I've always done: acpitool -S As of now, it seems storing the state into the swap area is working. Problem is that when booting, the kernel is not even trying to see if there's state stored in the swap, since I don't see any message about it, and all I'm getting is plain boot. So I suspect the kernel is not compiled with built in support for suspend to disk. Is this true? Add the resume hook to the end of the HOOKS list in /etc/mkinitcpio.conf and rebuild your initramfs. This has to be added manually now with the non-klibc mkinitcpio.
Re: [arch-general] pacman.conf: can I use wildcards?
At Freitag, 19. Februar 2010 12:01 Heiko Baums wrote: Right, that's what NoUpgrade in pacman.conf does. ;-) Thanks for the smiley at the end because i was very silly (oder anderes gesagt die Leitung auf der ich stand ging mindestens zweimal um die Erde -) ). See you, Attila
Re: [arch-general] Was the kernel suspend to disk feature removed on 2.6.32.8-1
Am 19.02.2010 16:40, schrieb Ray Kohler: Add the resume hook to the end of the HOOKS list in /etc/mkinitcpio.conf and rebuild your initramfs. This has to be added manually now with the non-klibc mkinitcpio. Actually, all documentation I knew of always said it was necessary to add it. The old and much-hated kinit always applied some kind of magic we had no control of, including resuming although not told to do so. So, dumping kinit may have removed undocumented features - mainly because I didn't even know those features existed. signature.asc Description: OpenPGP digital signature
[arch-general] Abort forced filesystem check on boot
Hi, I have written a small patch for rc.sysinit which gives the user the ability to abort a forced filesystem check with pressing the escape-key. I haven't found another feature-request in the bugtracker for this so I opened one: http://bugs.archlinux.org/task/18400 . What do you think about it? signature.asc Description: PGP signature
Re: [arch-general] Abort forced filesystem check on boot
Hello, Rorschach wrote: Hi, I have written a small patch for rc.sysinit which gives the user the ability to abort a forced filesystem check with pressing the escape-key. I haven't found another feature-request in the bugtracker for this so I opened one: http://bugs.archlinux.org/task/18400 . What do you think about it? You can use Ctrl+C, at least it works for me. Best regards, Paulo Santos
Re: [arch-general] Recent upgrade of vimgvim generates assertion errors in console
On Fri, Feb 19, 2010 at 4:17 AM, Magnus Therning mag...@therning.org wrote: On Fri, Feb 19, 2010 at 08:00, LI Ye leeyee@gmail.com wrote: Hi guys, Just paste my post from forum. Have you guys encountered this issue after recent upgrades of vim gvim: ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed This happens when running gvim in the console. It works all fine except the warnings. Downgrading to version 7.2.266 can avoid this. I see exactly the same thing, but since it doesn't seem to hurt I decided to simply wait for the vim developers to fix this at some point in the future. Agreed. I see lots of gtk related warnings all the time when running GUI apps from the command line. Try running firefox that way :S
[arch-general] Postfix Package Upgrade
I was curious how a user like myself can find out when the 'Postfix' package from Arch Linux will be upgraded from 2.6.5 to 2.7.0? Is there a way I can see the release schedule or a round about guess-tamite as to when it will be released?
Re: [arch-general] Postfix Package Upgrade
On 02/19/2010 07:36 PM, Carlos Williams wrote: I was curious how a user like myself can find out when the 'Postfix' package from Arch Linux will be upgraded from 2.6.5 to 2.7.0? Is there a way I can see the release schedule or a round about guess-tamite as to when it will be released? I guess that will happen when postfix dev release the final stable version, right now it seems to be just a stable _release candidate_.
Re: [arch-general] Postfix Package Upgrade
On Fri, Feb 19, 2010 at 3:04 PM, Mauro Santos registo.maill...@gmail.com wrote: I guess that will happen when postfix dev release the final stable version, right now it seems to be just a stable _release candidate_. I show on their site that Postfix 2.7.0 is released as stable and not a R.C. Am I missing something? http://www.postfix.org/announcements.html
Re: [arch-general] Postfix Package Upgrade
On 02/19/2010 10:07 PM, Carlos Williams wrote: On Fri, Feb 19, 2010 at 3:04 PM, Mauro Santos registo.maill...@gmail.com wrote: I guess that will happen when postfix dev release the final stable version, right now it seems to be just a stable _release candidate_. I show on their site that Postfix 2.7.0 is released as stable and not a R.C. Am I missing something? http://www.postfix.org/announcements.html when the maintainer has time to update it. -- Ionut
Re: [arch-general] Postfix Package Upgrade
On Fri, Feb 19, 2010 at 3:07 PM, Carlos Williams carlosw...@gmail.comwrote: On Fri, Feb 19, 2010 at 3:04 PM, Mauro Santos registo.maill...@gmail.com wrote: I guess that will happen when postfix dev release the final stable version, right now it seems to be just a stable _release candidate_. I show on their site that Postfix 2.7.0 is released as stable and not a R.C. Am I missing something? http://www.postfix.org/announcements.html Geez, a whole week? Arch must be falling apart at the seams. Bump the version in the PKGBUILD out of ABS and build it yourself? Running fine here for the past few days...
Re: [arch-general] Postfix Package Upgrade
On 02/19/2010 08:07 PM, Carlos Williams wrote: On Fri, Feb 19, 2010 at 3:04 PM, Mauro Santos registo.maill...@gmail.com wrote: I guess that will happen when postfix dev release the final stable version, right now it seems to be just a stable _release candidate_. I show on their site that Postfix 2.7.0 is released as stable and not a R.C. Am I missing something? http://www.postfix.org/announcements.html My bad, I just checked this mirror (in my country) ftp://ftp.inescn.pt/pub/net/mail/postfix/index.html for the downloads available but it seems this mirror is not up to date.
[arch-general] [patch] AIF, discover repos on iso.
Hi List,
The attached patch fixes a TODO in lib-pacman of aif.
Instead of hardcoding that `core' is always available locally and falling
back to net for others, it now checks /src/ for repos.
It assumes repos are stored at /src/$repo/pkg/. All these repos are added
as cache dirs.
While preparing pacman, a number of repo names are provided to be
prepared.
All those repos which were requested are added as actual repo. If this
repo is available locally, the url points to disk. Otherwise it falls back
to the mirrorlist.
Please let me know what you think.
Greetings/Groetjes
Mark Pustjens
--
Currently there's five machines permanently networked here. They *all*
contain the serious core stuff. A couple of the machines are pensioned off
486s, with little other value now. Plus there's two Jaz drives in the
building and the portable also carries a fair amount of stuff. Plus every
Friday a man comes around and carves all the new stuff onto stone slabs and
buries them in the garden... I think I'm okay.
(alt.fan.pratchett)diff -u -Naur aif-2009.08.07/src/core/libs/lib-pacman.sh
aif-2009.08.07-new/src/core/libs/lib-pacman.sh
--- aif-2009.08.07/src/core/libs/lib-pacman.sh 2009-08-07 21:25:04.0
+0200
+++ aif-2009.08.07-new/src/core/libs/lib-pacman.sh 2010-02-19
22:12:33.0 +0100
@@ -62,25 +62,34 @@
[ $var_PKG_SOURCE_TYPE = cd ] local serverurl=${var_FILE_URL}
[ $var_PKG_SOURCE_TYPE = net ] local serverurl=${var_SYNC_URL}
- [ -z $1 ] repos=core
- [ -n $1 ] repos=$@
- # Setup a pacman.conf in /tmp
- cat EOF /tmp/pacman.conf
-[options]
-CacheDir = ${var_TARGET_DIR}/var/cache/pacman/pkg
-CacheDir = /src/core/pkg
-EOF
-
-for repo in $repos
-do
- #TODO: this is a VERY, VERY dirty hack. we fall back to net for any
non-core repo because we only have core on the CD. also user maybe didn't pick
a mirror yet
- if [ $repo != core ]
- then
- add_pacman_repo target ${repo} Include = $var_MIRRORLIST
+ if [ -z $1 ]; then
+ repos=core
else
- add_pacman_repo target ${repo} Server =
${serverurl/\$repo/$repo} # replace literal '$repo' in the serverurl string by
$repo where $repo is our variable.
+ repos=$@
fi
-done
+
+ # We make the assumption that /src/ contains a number of directories,
each
+ # of which contains a package repository under subdir `pkg'.
+ # Eg: /src/core/pkg is a package repository.
+ local_repos=`ls /src/`
+
+ # Setup a pacman.conf in /tmp
+ echo [options] /tmp/pacman.conf
+ echo CacheDir = ${var_TARGET_DIR}/var/cache/pacman/pkg
/tmp/pacman.conf
+ for repo in ${local_repos}; do
+ echo CacheDir = /src/${repo}/pkg /tmp/pacman.conf
+ done
+
+ # Add each repo to the config file
+ # If the repo is available locally, add a local url, otherwise refer to
the mirrorlist.
+ for repo in ${repos}; do
+ if echo ${local_repos} | grep ^${repo}$ /dev/null ;then
+ add_pacman_repo target ${repo} Server =
file:///src/${repo}/pkg
+ else
+ add_pacman_repo target ${repo} Include =
${var_MIRRORLIST}
+ fi
+ done
+
# Set up the necessary directories for pacman use
[ ! -d ${var_TARGET_DIR}/var/cache/pacman/pkg ] mkdir -m 755 -p
${var_TARGET_DIR}/var/cache/pacman/pkg
[ ! -d ${var_TARGET_DIR}/var/lib/pacman ] mkdir -m 755 -p
${var_TARGET_DIR}/var/lib/pacman
Re: [arch-general] [patch] AIF, discover repos on iso.
On Fri 19 Feb 2010 22:26 +0100, Mark Pustjens wrote: The attached patch fixes a TODO in lib-pacman of aif. Instead of hardcoding that `core' is always available locally and falling back to net for others, it now checks /src/ for repos. It assumes repos are stored at /src/$repo/pkg/. All these repos are added as cache dirs. While preparing pacman, a number of repo names are provided to be prepared. All those repos which were requested are added as actual repo. If this repo is available locally, the url points to disk. Otherwise it falls back to the mirrorlist. Please let me know what you think. Nice. You probably should send that to the arch-releng mailing list.
Re: [arch-general] [patch] AIF, discover repos on iso.
On Fri, Feb 19, 2010 at 3:26 PM, Mark Pustjens pustj...@dds.nl wrote:
Hi List,
The attached patch fixes a TODO in lib-pacman of aif.
Instead of hardcoding that `core' is always available locally and falling
back to net for others, it now checks /src/ for repos.
It assumes repos are stored at /src/$repo/pkg/. All these repos are added as
cache dirs.
While preparing pacman, a number of repo names are provided to be prepared.
All those repos which were requested are added as actual repo. If this repo
is available locally, the url points to disk. Otherwise it falls back to the
mirrorlist.
CCing to the arch-releng list
diff -u -Naur aif-2009.08.07/src/core/libs/lib-pacman.sh
aif-2009.08.07-new/src/core/libs/lib-pacman.sh
--- aif-2009.08.07/src/core/libs/lib-pacman.sh 2009-08-07 21:25:04.0
+0200
+++ aif-2009.08.07-new/src/core/libs/lib-pacman.sh 2010-02-19
22:12:33.0 +0100
@@ -62,25 +62,34 @@
[ $var_PKG_SOURCE_TYPE = cd ] local serverurl=${var_FILE_URL}
[ $var_PKG_SOURCE_TYPE = net ] local serverurl=${var_SYNC_URL}
- [ -z $1 ] repos=core
- [ -n $1 ] repos=$@
- # Setup a pacman.conf in /tmp
- cat EOF /tmp/pacman.conf
-[options]
-CacheDir = ${var_TARGET_DIR}/var/cache/pacman/pkg
-CacheDir = /src/core/pkg
-EOF
-
-for repo in $repos
-do
- #TODO: this is a VERY, VERY dirty hack. we fall back to net for any
non-core repo because we only have core on the CD. also user maybe didn't pick
a mirror yet
- if [ $repo != core ]
- then
- add_pacman_repo target ${repo} Include = $var_MIRRORLIST
+ if [ -z $1 ]; then
+ repos=core
else
- add_pacman_repo target ${repo} Server =
${serverurl/\$repo/$repo} # replace literal '$repo' in the serverurl string by
$repo where $repo is our variable.
+ repos=$@
fi
-done
+
+ # We make the assumption that /src/ contains a number of directories,
each
+ # of which contains a package repository under subdir `pkg'.
+ # Eg: /src/core/pkg is a package repository.
+ local_repos=`ls /src/`
+
+ # Setup a pacman.conf in /tmp
+ echo [options] /tmp/pacman.conf
+ echo CacheDir = ${var_TARGET_DIR}/var/cache/pacman/pkg
/tmp/pacman.conf
+ for repo in ${local_repos}; do
+ echo CacheDir = /src/${repo}/pkg /tmp/pacman.conf
+ done
+
+ # Add each repo to the config file
+ # If the repo is available locally, add a local url, otherwise refer to
the mirrorlist.
+ for repo in ${repos}; do
+ if echo ${local_repos} | grep ^${repo}$ /dev/null ;then
+ add_pacman_repo target ${repo} Server =
file:///src/${repo}/pkg
+ else
+ add_pacman_repo target ${repo} Include =
${var_MIRRORLIST}
+ fi
+ done
+
# Set up the necessary directories for pacman use
[ ! -d ${var_TARGET_DIR}/var/cache/pacman/pkg ] mkdir -m 755 -p
${var_TARGET_DIR}/var/cache/pacman/pkg
[ ! -d ${var_TARGET_DIR}/var/lib/pacman ] mkdir -m 755 -p
${var_TARGET_DIR}/var/lib/pacman
[arch-general] Planet Arch Linux atom feed.
Guys, if any of you are subscribed to planet arch, then you must have noticed a problem with some of the feeds. The problem is, the summary of the feed displays fine, but when i open the feed, it shows the xml of the feed instead of showing the website. http://planet.archlinux.org/atom.xml (this is shown). This happens with only a few of the feeds. Recently happened with these feeds: Arch Haskell News: February 2010, Archiso-live 20100217 Release. I am using firefox with newsfox. Anyone else notice this? Godane's Development Blog
