- Arch-general - lists.archlinux.org

Re: [arch-general] Fwd: /etc/cron.hourly/ntp isn't working.
by Daenyth Blank 26 Nov '08

26 Nov '08

> this is because the init scripts use some fancy options to set colors. > This seems to be done by stty, which won't work on a fake tty like the > one used by cron. > I don't know why you're restarting openntpd from cron every hour though, > as it's a daemon that keeps running all the time. Restarting it has no > use. Well, I think I had added it because it seemed that after a long uptime it wasn't working properly... dunno. I've disabled it now.

1 0

Re: [arch-general] [arch-dev-public] Other things gleaned from package list statistics
by Dieter Plaetinck 24 Nov '08

24 Nov '08

Aaron Griffin wrote: > On Sun, Nov 23, 2008 at 5:28 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > >> There are a few packages people have installed that we have killed >> that show up really high on the list: >> >> liblbxutil-84.79 % >> csup -44.39 % >> xorg-xsm-43.74 % >> >> It might be worth posting a news item saying these packages are >> worthless on a modern-day Arch system (as long as you have a newer X)? >> I know I had some of them installed. >> > > Hmm, is there a more generic way to handle cases like this? -Qm can > help us in these cases, but considering how much people use the AUR, > we need to be careful. > Don't liblbxutil and xorg-xsm become orphans when the user upgrades to that particular X version? I noticed I don't have these packages and I don't even know why (I did clean up my orphans recently, like every good user should) I do have csup explicitly installed , because it used to be in the base-devel group. I guess that's where http://bugs.archlinux.org/task/8242 - "Keep track of groups and allow upgrading them with pacman -Syu" - comes in.

1 0

Re: [arch-general] [sqlite3] x86_64 version mismatch?
by Andreas Radke 23 Nov '08

23 Nov '08

Am Sat, 22 Nov 2008 19:54:09 +0100 schrieb Gerhard Brauer <gerhard.brauer(a)web.de>: > Hello, > > > in the extra.db.tar.gz on ftp.archlinux.org sqlite3 version for x86_64 > is 3.6.6-1. But the binary is > still /extra/os/x86_64/sqlite3-3.6.5-1-x86_64.pkg.tar.gz > > Seems that this version upgrade have done today (22.11) so could it be > possible that ftp.archlinux.org mirrors have currently only synced the > database file? Is it a missing upload or only a sync problem? > > Regards > Gerhard > The new package is still in my pipeline. We have issues with the db-updates. See dev-public list. -Andy

3 2

Re: [arch-general] [arch-dev-public] [signoff] device-mapper 1.02.29-1 & lvm2 2.02.43-1
by Eric Bélanger 23 Nov '08

23 Nov '08

On Mon, 17 Nov 2008, Thomas Bächler wrote: > Eric Bélanger schrieb: >> device-mapper 1.02.29-1 and lvm2 2.02.43-1 are now in testing for both >> arches. It's a minor upstream update. The most important change is: >> "Starting with LVM2 release 2.02.43, the device-mapper files are now >> included with the LVM2 releases (in ../lvm2)." >> I've modified the PKGBUILD accordingly. >> >> Please test and signoff. I would like 2 signoff for i686 because I don't >> use lvm2 on my i686 system so I could only do minor testing. As I believe >> few devs use this, signoffs from users are welcomed. > > Signoff x86_64 > > Still missing 1-2 signoffs for i686. Anyone? Devs or users? Thanks. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Re: [arch-general] [arch-dev-public] [signoff] new toolchain - major binutils/glibc bumps
by Emmanuel Benisty 23 Nov '08

23 Nov '08

Hi, On Sat, Nov 22, 2008 at 2:57 PM, Andreas Radke <a.radke(a)arcor.de> wrote: > I've bumped kernel-headers 2.6.27.6-2, binutils 2.19-1, glibc 2.9-1 and > rebuilt gcc-libc/gcc,gcc-gcj. I also fixed valgrind for new glibc. > Please test them all carefully. We usually run into some upstream > issues here. Especially new glibc: > > "There is one known potential problem with the name resolving which has > been extensively changed. Under some circumstance (always involving > broken servers) requests are not completely processed. Often a second > call fixes the problem. This might be fixed in the latest code, maybe > not. Unfortunately no reported has been able or willing to provide the > information needed to track down the problem." Bug is alive. http://bbs.archlinux.org/viewtopic.php?id=59452 cheers.

1 1

Re: [arch-general] [arch-dev-public] memcached
by Pierre Schmitz 23 Nov '08

23 Nov '08

>> PS: for php sites that only run on one server I think Xcache is also >> better >> then memcached, no context switching at all... >> PPS: do we use an opcode cache already for the php site(s)? eaccelerator? >> xcache etc? it can be a huge improvement > > APC is used for a PHP opcode cache, so yes, we do have this in place. APC does not only store opcodes, but e.g. Mediawiki uses it to store Objects in RAM. So memcached is not needed here. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

2 1

Re: [arch-general] [arch-dev-public] [signoff] bison 2.4-1
by Eric Bélanger 23 Nov '08

23 Nov '08

On Sat, 22 Nov 2008, Hussam Al-Tayeb wrote: > On Tue, 2008-11-11 at 20:15 -0500, Eric Bélanger wrote: >> On Tue, 11 Nov 2008, Eric Bélanger wrote: >> >>> On Tue, 11 Nov 2008, Andreas Radke wrote: >>> >>>> Am Sun, 9 Nov 2008 22:47:56 -0500 (EST) >>>> schrieb Eric Bélanger <belanger(a)ASTRO.UMontreal.CA>: >>>> >>>>> >>>>> Hi, >>>>> >>>>> bison 2.4-1 is in testing for both arches. Please signoff. >>>>> >>>>> Changes: minor upstream update, Added info file support. >>>>> >>>>> Eric >>>>> >>>> please first make sure it doesn't cause this compile issue: >>>> http://bbs.archlinux.org/viewtopic.php?id=58782 >>>> >>> >>> I have this build issue as well. I'll need to fix that before pushing bison >>> to core. I did tried to build bmpx that has bison as makedepends before >>> adding it to testing. It looks like it didn't triggered this problem. I'll >>> guess I'll use gcc for future tests. >>> >> >> It's already a known issue upstream: >> http://www.mail-archive.com/bug-bison@gnu.org/msg01218.html >> >> There are plans to release a 2.4.1 soon to fix this problem. I'll probably >> just wait for 2.4.1 then. > > > Bison 2.4 also breaks compiling of webkit from svn. > Thanks for reporting. A fixed libwebkit is now in svn (available through abs). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Re: [arch-general] test
by Hubert Grzeskowiak 23 Nov '08

23 Nov '08

Aaron Griffin wrote: > Silly me for not reading the docs - that list is required.. hah ts ts ts, evil ]:->

1 0

Re: [arch-general] [.hu ftp mirror issue] unable (access denied) to rsync from rsync://rsync.archlinux.org/ftp/
by Gergely TAMAS 23 Nov '08

23 Nov '08

Hi! Good catch... ;) The previously used ip alias has been deleted... > Can you open a bug report (http://bugs.archlinux.org, Arch Linux > project) saying your mirror location has changed IPs? Then all > relevant parties can address it there. Done. I used category 'System' - could not find a better suitable one. Thanks, -- Gergely

1 0

Re: [arch-general] [arch-dev-public] Get Arch Link
by Dieter Plaetinck 19 Nov '08

19 Nov '08

Aaron Griffin wrote: > On Tue, Nov 18, 2008 at 4:38 PM, Dusty Phillips <buchuki(a)gmail.com> wrote: > >> I think there should be a download link in the "About" text, a >> download link on the right hand side, and leave the "Get Arch" link on >> the menu. If anybody misses it in all three places they probably >> wouldn't pass Simo's "Are you human" test on the forum anyway. >> > > I still think there needs to be one in the giant "what's arch" blurb > on the main page. If you're reading that text, you're probably new and > looking for a download. > 1) +1 for general UI revamp. I think most of us agree that it's at _least_ "weird" to have so many important links in the bottom right corner, which is pretty much the least likely place to scan. 2) +1 for renaming "Get arch" to "Download" 3) I would put a new menu item in the top menu, called "About" which also links to the /about page 4) At the end of the 'about' talk, you can put a download link, you can really make it stand out there (after text, few empty lines, then in the center the blue 'download link') 5) I think 2 + 3&4 are better solutions then Aarons "adding a link to the download page in the "what's arch" blurb"-idea: it could be useful, but I think the top-right links really attract the eyes already, and 4 is a good fallback for users who take the other route. 6) The 'releases' block on frontpage: how relevant is any of the information in there?. Only the last release is somewhat relevant on the front page. I suggest removing the block there and moving the information to the download page. (which also needs a revamp/restructure btw, there is lots of wasted space there. 7) the 'package repositories' and 'recent updates' blocks and 'package search' field on the frontpage. Is any of that relevant on the frontpage? Maybe we should put an item 'Packages' in the top menu, and link to /packages. We could extend the packages page (or divide packages related things over multiple pages) to add an overview of available repositories, recently updated packages etc. Putting the above things together: the blocks on the right are gone, the 'documentation' , 'community' etc links can go up, replacing the blocks and making the links more visible. (I do think that having all links visible separately can be good thing - eg they are not hidden because of a menu with 2 levels whether it be dropdown or a tabbed menu with main items and subitems) When we get that far, we might as well swap right and left too: the top menu items aligned left, the links on the left, and the 'about box' and the news on the center/right, but this is more a matter of personal taste I guess. Just my 8 cents :-) PS: I can help with the redesign/restructure if needed, but preferably only after a consensus is reached. It's not that I really like designing things "for fun" but if we reach a (sort of) consensus and you lack the manpower, I would be glad to help. Dieter

1 0