- Arch-general - lists.archlinux.org

[arch-general] [signoff] kernel26-lts 2.6.32.28-4
by Tobias Powalowski 13 Feb '11

13 Feb '11

Latest LTS kernel is in testing, - rebuild against latest binutils/glibc please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] streamtuner2 - python developers please have a look
by Andreas Radke 12 Feb '11

12 Feb '11

I'd like to replace streamtuner with streamtuner2 in extra. But there's one major bug that is a stopper to me. http://sourceforge.net/projects/streamtuner2/forums/forum/1173108/topic/377… Upstream is aware of it but seems unable to fix it. I know we have some python coders around. Maybe you can have a look at it. -Andy

1 0

Re: [arch-general] [arch-dev-public] Vi package
by David Campbell 11 Feb '11

11 Feb '11

Excerpts from Allan McRae's message of 2011-02-10 17:12:54 -0500: > Is the current vi package actually usable for an install by someone more > familiar with it? Yes, I have used it a few times, and prefer it over nano. -- David Campbell

3 2

[arch-general] Laptop beeps after resuming from suspension
by Thomas Dean 11 Feb '11

11 Feb '11

Hi folks, I have an encounter with a small but annoying problem. After typing pm-suspend and then resuming my laptop, it sometimes beeps, which never happens if I haven't ever suspend it. For example, when I type too much backspace in VIM, it beeps; when I push the shutdown button, it beeps; when I type Page Down button at the end of the text, it beeps, too. Could you please tell me how to shut its beeping? Thanks, Thomas

4 8

[arch-general] A repo-add replacement?
by Magnus Therning 11 Feb '11

11 Feb '11

I've noticied that repo-add will blindly overwrite the entry of an already added package with whatever you point it to. Even if the existing entry is for a version that is newer. It basically means that "repo-add repo.db.tar.gz *.pkg.tar.xz" doesn't work that well :-( Is there some other tool for building a a repo db that doesn't follow my instructions so blindly? ;-) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

3 5

Re: [arch-general] [arch-dev-public] glib2 2.28 from testing
by Ng Oon-Ee 11 Feb '11

11 Feb '11

On Fri, 2011-02-11 at 00:52 +0200, Ionuț Bîru wrote: > Hi, > i was a bit to excited by the new gtk3 released and i moved it to > testing without realizing that the new application lookup that comes > with it would break gnome 2.32 handling applications badly. > > Please revert back to core/extra with pacman -Syuu if you managed to > upgrade. > Sorry to ask a simple question, but the recommendation to revert is for glib2 or gtk3?

2 1

Re: [arch-general] [arch-dev-public] Vi package
by Loui Chang 11 Feb '11

11 Feb '11

On Wed 09 Feb 2011 11:23 -0500, Stéphane Gaudreault wrote: > Hi, > > I was looking at FS#20778 and was wondering what we should do with it. > > While it is true that the "traditional vi" is buggy and not user > friendly. It does not seems that BusyBox is a good alternative. > > There are options here: > > 1) Statu quo > Pro : > * Support for multi-byte character encodings like UTF-8 > * Small size > Cons : > * Did I said that it is buggy ? > * Use of this old software in the installer may give a strange > impression to new users as they are faced with an editor from the > '70 on a distro where everything is up to date. > * Appears to be no longer be updated upstream. > > Opinions? I'd say stick with the status quo. I don't find anything too wrong with the traditional vi. There's the file size and line length limit and those aren't really that bad. The wide terminal issue has been worked around by changing the config header. If you want to do heavy editing other programs are more appropriate in our modern age. Vi is more appropriate for light editing like when doing installation or configuration. Are other bugs that you mention documented somewhere? I'm interested in learning about them. If you can use vim you probably should be able to use vi without too much difficulty. I guess you could argue that having two basic editors (vi and nano) is unnecessary, vi is usually expected to be on a basic system, and nano just bugs me. :D

1 0

Re: [arch-general] [arch-dev-public] Vi package
by Marek Otahal 10 Feb '11

10 Feb '11

On Thursday 10 of February 2011 17:59:26 Pierre Schmitz wrote: > On Thu, 10 Feb 2011 17:52:16 +0100, Jan de Groot wrote: > > On Thu, 2011-02-10 at 17:24 +0200, Ionuț Bîru wrote: > >> we did had vi being a stripped vim package in the past. We got rid of > >> it > >> because upstream vim started to not helping arch users because "it > >> was > >> broken". That impression was given by our users who didn't understand > >> that python and other crap that vim support is in vim package and not > >> in vi. > >> > >> now the same situation is now. Some users don't understand that vi is > >> nvi and what they want is in vim. > > > > I don't think we should go back to a fucked vim package with /etc/virc > > like we had it in the past. We switched from that to nvi, which fucked > > up files if they contained unicode stuff (it would just segfault in the > > middle of a save operation, leaving you with a broken file). > > After that, we decided to go for busybox, which works fairly well as vi, > > is maintained, but doesn't do anything that looks like vim. > > > > IMHO vi is totally useless on most systems. I prefer to uninstall it and > > do ln -s vim /usr/bin/vi instead. Users who complain about vi being too > > limited should do that too. > > I wonder the same. I cannot imagine why anybody would want to use vi. > Personally I would not mind if nano was the only interactive editor in > [core]. But keeping the current busybox vi is also fine. Hello, first, I apologize for off-topic, but i seek help on vim. Reading this thread I decided I want to learn how to get more from vim, so I started with vimtutor. So far I ran into two issues that were incompatible with the vimtutor, *) 7G moves you to line 7, I had to do 7gg instead *) " Lesson 5.3: SELECTING TEXT TO WRITE ** To save part of the file, type v motion :w FILENAME ** 1. Move the cursor to this line. 2. Press v and move the cursor to the fifth item below. Notice that the text is highlighted. 3. Press the : character. At the bottom of the screen :'<,'> will appear. 4. Type w TEST , where TEST is a filename that does not exist yet. Verify that you see :'<,'>w TEST before you press <ENTER>. 5. Vim will write the selected lines to the file TEST. Use :!dir or !ls to see it. Do not remove it yet! We will use it in the next lesson. "...this doesn't work for me, I switch to visual mode, after : the '<,'> doesn't appear though. Can somebody enlighten me, is this behavior -some config in vim -- where and how can I set it? -mistakes in the tutorial (could be updated) -mistakes in vim Many thanks, mark the vimmer :) -- Marek Otahal :o)

2 1

[arch-general] trinity pkgbuild: rewrite to dl svn - Use fixed svn rev or latest?
by David C. Rankin 10 Feb '11

10 Feb '11

Guys, I'm rewriting a set trinity pkgbuilds to download the trinity/<module> code in the pkgbuild instead of using the existing source in the local copy of the complete trinity svn tree. This will also allow the packages to be built in an archroot and get around the empty src problem I was having with makechrootpkg using the code in the existing tree. My PKGBUILD question is can I use the latest svn revision to build from, or do I need to use a fixed svn revision for $pkgver? The examples I've looked at do something like: pkgver=123456 <snip> build() { cd $srcdir msg "Connecting to $_svntrunk SVN server...." if [ -d $_svnmod/.svn ]; then (cd $_svnmod && svn up -r $pkgver) else svn co $_svntrunk --config-dir ./ -r $pkgver $_svnmod fi <snip> I want to vary this to use the latest revision instead of a fixed revision: pkgver=123456 <snip> build() { cd ${srcdir} msg "Connecting to SVN server...." if [ -d ${_svn_module}/.svn ]; then (cd ${_svn_module} && svn up) [[ $? -eq 0 ]] || _co_failed=1 else (svn co $_svn_trunk ${_svn_module}) [[ $? -eq 0 ]] || _co_failed=1 fi cd ${_svn_module} pkgver=$(getsvnrev) <snip> Is this OK, or should I avoid using the latest version to prevent potential inconsistencies? Also, if you see anything else that will bite me, let me know. Thanks. -- David C. Rankin, J.D.,P.E.

3 5

Re: [arch-general] [arch-dev-public] Fwd: [arch-dev] [signoff] ppp-2.4.5-2
by Dave Reisner 10 Feb '11

10 Feb '11

On Wed, Feb 09, 2011 at 03:26:29PM -0500, Eric Bélanger wrote: > Forwarding to public ML. > > > ---------- Forwarded message ---------- > From: Stéphane Gaudreault <stephane(a)archlinux.org> > Date: Wed, Feb 9, 2011 at 2:23 PM > Subject: [arch-dev] [signoff] ppp-2.4.5-2 > To: arch-dev(a)archlinux.org > > > * Rebuild of old package > * Tidy up PKGBUILD > * Fix build error with recent kernel > * Fix permissions on libs > > Please signoff both as I do not run this pkg. > Thanks > > Stéphane I recall last time there was a new build of ppp around, it came down to user signoffs. In case it comes down to that again, I can still connect to my VPN, so I'll sign off for x86_64. dave

1 0