- Arch-dev-public - lists.archlinux.org

[arch-dev-public] netcfg2 in [testing]
by James Rayner 06 Nov '07

06 Nov '07

Just a heads up that I've put netcfg2 into [testing]... They work for me and others, and have proven to be solid for the last few months without many bugs -- they're well overdue for wider testing. Also... I'd like to move it into svn on projects.archlinux.org as there's no scm currently, who do I speak to about that? I'll post announcements tomorrow morning when I wake if nobody has any complaints. They'll follow as below. Cheers! James ---- netcfg2 is now in [testing]. netcfg2 aims to be a refined network profile system for Arch Linux, replacing the current implementation. Through this, it has also gained various features and improvements which are listed on the development wiki page (http://wiki.archlinux.org/index.php/Network_Scripts) Before it can replace the current profiles, netcfg2 needs testers of various wireless hardware and configuration to try the scripts and report back on the wiki page testing section (http://wiki.archlinux.org/index.php/Network_Scripts#Testing) Bugs can be filed at the bug tracker. Documentation for netcfg2 is located in the netcfg manpage, detailed examples in /etc/network.d/examples, and the wiki: http://wiki.archlinux.org/index.php/Network_Profiles

3 6

[arch-dev-public] /opt vs. /usr
by Varun Acharya 05 Nov '07

05 Nov '07

I remember there was a thread on the ML some time ago about packages still hanging about in /opt and not being moved to /usr. What's the final word on this? I ask because I want to move wicd into extra, and the source package contains binaries and a few scripts, defaulting to /opt. Shall I leave this as is, or move the /opt/wicd to /usr/lib/wicd ? Varun

5 4

[arch-dev-public] In what repo eventlog should be readded?
by Eric Belanger 05 Nov '07

05 Nov '07

Hi, >From Scott's email in the pacman-dev ML, I realized that the eventlog package, a makedepends for syslog-ng, has been moved to unsupported by mistake. So it should be readded to the repo. I wonder if it should be readded in extra or placed in core instead? Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

5 4

[arch-dev-public] sudo in base-devel group?
by Jason Chu 05 Nov '07

05 Nov '07

If I use the mkarchroot and makechrootpkg scripts to build packages, I need to have sudo installed. Using the current mkarchroot options I have to specify "base base-devel sudo". I just need to know if we're planning on putting sudo into base-devel or if I should update the mkarchroot and makechrootpkg scripts to reflect this. Jason

4 6

[arch-dev-public] km script missing with history in installer.git
by Tobias Powalowski 05 Nov '07

05 Nov '07

Hi subject says it all please add the km script too to this repository, thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4

[arch-dev-public] wicd in testing
by Varun Acharya 05 Nov '07

05 Nov '07

Hi all, I've uploaded wicd to testing for both x86_64 and i686. Though its an extra package, I'd like some thorough testing especially on wpa/wpa2 networks. Please signoff. Varun

1 0

[arch-dev-public] [testing] mlocate replacing slocate
by James Rayner 05 Nov '07

05 Nov '07

mlocate has replaced slocate as the default locate implementation, this is currently in [testing]. This was requested on the bug tracker a while back[1]. mlocate is used by Fedora at least and unlike slocate, no longer has the well known midnight updatedb crawl. In all other aspects it's compatible with and identical to slocate. James [1] http://bugs.archlinux.org/task/4490 As described by the README: mlocate is a locate/updatedb implementation. The 'm' stands for "merging": updatedb reuses the existing database to avoid rereading most of the file system, which makes updatedb faster and does not trash the system caches as much. The locate(1) utility is intended to be completely compatible to slocate. It also attempts to be compatible to GNU locate, when it does not conflict with slocate compatibility.

8 10

[arch-dev-public] slocate Replaced by mlocate
by James Rayner 05 Nov '07

05 Nov '07

mlocate has replaced slocate as the default locate implementation after a short period in [testing], and an even longer one in [extra]. This was requested on the bug tracker a while back[1]. mlocate is used by Fedora at least and unlike slocate, no longer has the well known midnight updatedb crawl. In all other aspects it's compatible with and identical to slocate. AndyRTR posted some performance measurements on the mailing list [2]. [1] http://bugs.archlinux.org/task/4490 [2] http://archlinux.org/pipermail/arch-dev-public/2007-November/002870.html As described by the README: mlocate is a locate/updatedb implementation. The 'm' stands for "merging": updatedb reuses the existing database to avoid rereading most of the file system, which makes updatedb faster and does not trash the system caches as much. The locate(1) utility is intended to be completely compatible to slocate. It also attempts to be compatible to GNU locate, when it does not conflict with slocate compatibility.

1 0

[arch-dev-public] Fwd: [tur-users] flyspray category for supp./unsupp. community packages?
by Roman Kyrylych 05 Nov '07

05 Nov '07

In case our flyspray admins don't read tur-users ML frequently. ---------- Forwarded message ---------- From: Roman Kyrylych <roman.kyrylych(a)gmail.com> Date: 1 Лис 2007 20:25 Subject: Re: [tur-users] [arch-dev-public] flyspray category for supp./unsupp. community packages? To: "Discussion about the Arch User Repository (AUR)" <tur-users(a)archlinux.org> 2007/10/25, Roman Kyrylych <roman.kyrylych(a)gmail.com>: > 2007/10/25, Thomas Bächler <thomas(a)archlinux.org>: > > Roman Kyrylych schrieb: > > > See http://archlinux.org/pipermail/arch-dev-public/2007-May/000718.html > > > Could we setup Flyspray so all community packages will reside in > > > "Packages: Community" category? > > > My concern is privilege separation between different categories of the > > > same project. > > > > What about creating a separate project? ArchLinux and Community are in a > > sense separate projects, so we could simply add a new one (with a good > > name, we already have an AUR project). > > > > As long as we can move bugs between projects (can we?), this shouldn't > > be a problem. It may confuse users though. > > > > Yes, the only problem with separate project is user confusion. > We are receiving ~10 reports per week in wrong project now, because > Flyspray remembers active project in a cookie. > > But it seems that we cannot do any privilege separation in one > project, so separate project appears to be the only good variant. > > Could our Flyspray admins give me the "Project Manager" status on > Community packages? ping There are already 2 bugreports in "Community Packages" project (one of which should be assigned to me) but I cannot do anything with them. Just give me the Project Manager status and then I'll setup everything else. -- Roman Kyrylych (Роман Кирилич)

2 2

[arch-dev-public] [PATCH] initscripts: Add a splash support
by Roman Kyrylych 05 Nov '07

05 Nov '07

Hi! This patch finishes the work done by dtw and iphitus for bringing an optional splash support to default initscripts. It eliminates the need for separate initscripts-splash package which provides/conflicts=('initscripts'). User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it. -- Roman Kyrylych (Роман Кирилич)

14 31