- Arch-general - lists.archlinux.org

[arch-general] /srv/ vs. /home/httpd/html
by Jon Kristian Nilsen 30 Aug '08

30 Aug '08

I know this change has been running for some time now, but out of curiousity i'd like to know why it's been descided to put phpmyadmin/apache stuff in a new root folder called /srv/ instead of /home/* Isn't this a very personal setup compared to having this in the already existing /home/ folder? And not to forget that the change created a great deal of extra work for users who has been using /home/.. /srv/ must have some hidden important stability boosts?? And please don't get me wrong, i don't really care, since i have most of these folders mounted the way i want them, im still going to rebuild these packages and more using abs. Im just curious... -JK

3 3

Re: [arch-general] [arch-dev-public] Risky business: udev upgrade
by bardo 30 Aug '08

30 Aug '08

On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > start_udev is still there because people were jackasses and didn't > update initscripts when they updated udev.... or something.. I can't > remember the issue, but it was people being foolish and expecting > their systems to boot fine. > > Is everyone ok with removing it? Just remember to update /etc/udev/readme-udev-arch.txt: it still references start_udev as the way to reload rules, and it's also mentioned in another couple of places in that file. Corrado

2 1

Re: [arch-general] /srv/ vs. /home/httpd/html
by Daenyth Blank 30 Aug '08

30 Aug '08

It's for FHS compliance mostly. It was discussed on the arch-dev-public ml some time ago. Your apache config still points to /home, so it shouldn't actually matter. It's just a default.

1 0

[arch-general] Integrity Check
by Xavier 29 Aug '08

29 Aug '08

Hello, I rewrote stonecrest's python script which generated the Integrity Checks : http://projects.archlinux.org/?p=dbscripts.git;a=blob_plain;f=cron-jobs/che… last results : http://www.archlinux.org/pipermail/arch-dev-public/2008-August/007655.html Main changes include : * better and safer parsing of PKGBUILDs (it now relies on a separate bash script which source PKGBUILDs and generate python code, rather than trying to parse bash directly in python) * much better performance (thanks to a small python C extension which allows to call alpm_vercmp natively rather than having to fork the vercmp binary thousands of times) * more accurate dependency and provision handling (having worked on this part of the pacman code for a while probably helped me a bit here) > time ./check_archlinux.sh =================== = Integrity Check = =================== Performing integrity checks... ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends Missing Dependencies ---------------------- archboot --> 'bcm43xx-fwcutter>=006-2' Missing Makedepends --------------------- wpa_supplicant --> 'kernel26<2.6.25' xosd --> 'xmms' flac --> 'xmms' Summary --------- Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Invalid archs: 0 Missing (make)dependencies: 4 ./check_archlinux.sh 6,29s user 0,65s system 96% cpu 7,210 total

11 22

Re: [arch-general] [arch-dev-public] Cleaning up the base group
by RedShift 29 Aug '08

29 Aug '08

Thomas Bächler wrote: > Now that our installer installs the whole base group by default, I'd > wish it would stick to the essential part. I suggest cleaning this up a > bit: > > > Packages that IMO shouldn't be in base: > - dialog > Nothing depends on it, why do we even need it in core? > - hwdetect > Nothing uses it, we don't need that in core either > - ca-certificates, lzo2, openssl, wpa_supplicant > We need those in core, but really not in base > - dash > Nobody uses it by default, may IMO stay in core, but has no place in base > > - ppp, rp-pppoe (plus libpcap dep) > Only few people need those, leave them in core, but remove from base > - tcp_wrappers > No base package needs them as far I know, leave in core, remove from base > > We should also remove all packages from base that only are in there as a > dependency of another package and for no other reason, as they will be > pulled in when needed anyway. > > Packages that we should think about: > - mdadm > - pcmciautils > - cryptsetup, lvm2 (plus their deps libgcrypt, libgpg-error, device-mapper) > Those are base tools, but not everybody needs them. I'd like to keep > them in base, but maybe someone else may disagree. > - nano > Do we really need another editor in base? Let's leave it in core, remove > it from base. > > You should still make it possible to select which packages you want to install. Glenn

3 2

[arch-general] Should pkgtools be in community?
by Daenyth Blank 27 Aug '08

27 Aug '08

I was talking with some of the other TUs, and they thought that I should not include pkgtools in community, because it's an unofficial tool for archlinux. I wanted to get some arch dev's opinions on this, since I hadn't heard of anything against it before. Please let me know what you think. Thanks, --Daenyth

6 5

Re: [arch-general] [arch-dev-public] info files / documentation
by Xavier 26 Aug '08

26 Aug '08

On Mon, Aug 25, 2008 at 4:57 PM, Andreas Radke <a.radke(a)arcor.de> wrote: > > I think there was no rule decided. Afair we wanted to let it up to the > maintainer if he wants to add info files and further documentation when > he thinks it's helpful. I don't use the info command at all but could > also live with enabling all documentation. We ship headers in every > case so why not all possible content upstream developers install by > default. > > Maybe we should put a clear statement into the Arch packaging standards > wiki page. > The condition for letting it up to the maintainer was "if the docs are too big for a given package". http://www.archlinux.org/pipermail/arch-dev-public/2008-April/005913.html A side-note about the future docs handling in makepkg 3.3 : There was only one example of docs insanely big, and it was not info docs, but gtk-docs : http://www.archlinux.org/pipermail/arch-dev-public/2008-April/005923.html Allan also recently found out that info docs were not compressed: http://www.archlinux.org/pipermail/pacman-dev/2008-August/012780.html For fixing this, he decided to have man pages and info pages treated exactly the same, which makes perfectly sense and is fully supported by Dan and I. So with makepkg 3.3, the info pages will always be included and compressed : http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=7865fb9af487f7ca… The !docs option is still useful and needed for removing the really big docs like gtk-docs in the glib2 package.

1 0

[arch-general] Pacman 3.2.1 string freeze
by Dan McGee 25 Aug '08

25 Aug '08

String freeze for the pacman 3.2.1 release is now in effect. We have about 10 messages per language that are either fuzzy or new in this release, so nothing too serious. I've made some of the easy updates myself for your convenience: "Description:" -> remove the space "None" -> remove the '\n' "downloading %s\n" -> copy from the "Downloading %s" text if it was obvious to me "Are you sure" makepkg question -> remove the "[Y/n]" text Our pacman translation policy is outlined here. The important sections for translators are the introduction and up to (and including) pre-release updates. http://www.archlinux.org/pacman/translation-help.html As stated in the above document, PO files have been made available to translate: http://code.toofishes.net/pacman/po_files/ I'm shooting for a midweek release, so we have about 4 days to get translation updates in. Languages we currently have: cs:Vojtěch Gondžala <vojtech.gondzala(a)gmail.com> de: Matthias Gorissen <matthias(a)archlinux.de> en_GB: Jeff Bailes <thepizzaking(a)gmail.com> (Already complete) es: Juan Pablo Gonzalez <jotapesan(a)gmail.com> fr: Xavier Chantry <shiningxc(a)gmail.com> hu: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> it: Giovanni Scafora <linuxmania(a)gmail.com> pl: Mateusz Herych <heniekk(a)gmail.com> pt_BR: Hugo Doria <hugo(a)archlinux.org> ru: Sergey Tereschenko <serg.partizan(a)gmail.com> tr: Samed Beyribey <beyribey(a)gmail.com> zh_CN: 甘露(Lu.Gan) <rhythm.gan(a)gmail.com> If you wish to help translate, but your language is already listed as handled by someone, please contact them at the above addresses. If the language is listed as "no current translator", then please reply to ALL on this message stating you are doing the translation so we do not have duplicated effort (although you are more than welcome to work in teams). Once you have updated or completed a translation, simply tar and gzip the files up and send them back to pacman-dev(a)archlinux.org with a [translation] prefix in the message. For those that are used to the old method of updating translations (GIT patches), those are still acceptable as well. Please prefix the patch with "translation:" so it can be picked out easily. Any questions should be answered if you reply to this email on the list. -Dan

2 3

[arch-general] lua 5.1.4-1 in [extra]
by stefan-husmann＠t-online.de 24 Aug '08

24 Aug '08

Hello, I just saw lua 5.1.4-1 in [extra] (only for i686, x86_64 still has 5.1.3-3) but an older release 5.1.3-5 in [testing]. I guess it is a mistakenly uploaded package. Regards Stefan Husmann

1 0

[arch-general] 32-bit glibc package?
by David Rosenstrauch 21 Aug '08

21 Aug '08

I use Arch x86_64 - so far without a problem. But I've found recently that there's a few AUR packages that I'm unable to compile. (e.g., virtualbox-modules) Seems like the build needs the /usr/include/gnu/stubs-32.h file, which isn't installed on my Arch64 system. (glibc installs stubs-64.h instead.) But according to this thread, it appears that many distros work around this by having a 32-bit glibc package for this purpose: http://gcc.gnu.org/ml/gcc-help/2007-12/msg00055.html Does Arch have such a thing? Didn't look like it from surfing the packages in the repos (and AUR), but thought I'd ask anyway. If not, I'm not opposed to writing a new packages for this, but I'm not sure quite how to build a 32-bit glibc package that doesn't conflict with the 64-bit one. Anyone have any advice here? Thanks, DR

7 9