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

Re: [arch-dev-public] [arch-commits] CVS update of core/base/glibc (11 files)
by Dan McGee 29 Oct '07

29 Oct '07

On 10/29/07, andyrtr(a)archlinux.org <andyrtr(a)archlinux.org> wrote: > Date: Monday, October 29, 2007 @ 17:26:29 > Author: andyrtr > Path: /home/cvs-core/core/base/glibc > > Added: locale.patch (1.1) weekday.patch (1.1) > Modified: PKGBUILD (1.72 -> 1.73) locale.gen (1.4 -> 1.5) > Removed: first_weekday.diff (1.3) fix-C-first_weekday.diff (1.1) > glibc-2.5-branch_update-2.patch (1.1) > glibc-2.6-malloc-fixes.patch (1.1) locales-fr.diff (1.2) > locales_GB.diff (1.1) pl_PL-miesiace.patch (1.1) > > upgpkg: glibc 2.7-2 > update weekday/locale patching to current Debian state; update list of supported locales.gen; clean unneeded patches > > > ---------------------------------+ > PKGBUILD | 26 > first_weekday.diff | 1948 - > fix-C-first_weekday.diff | 27 > glibc-2.5-branch_update-2.patch |48089 -------------------------------------- > glibc-2.6-malloc-fixes.patch | 952 > locale.gen | 809 > locale.patch |21965 +++++++++++++++++ > locales-fr.diff | 282 > locales_GB.diff | 42 > pl_PL-miesiace.patch | 33 > weekday.patch | 1865 + > 11 files changed, 24255 insertions(+), 51783 deletions(-) > > > The diff is longer than the limit of 39KB. Can we please run patches through gzip for anything over like 1000 lines? This really kills the people that use abs. -Dan

2 2

[arch-dev-public] Killing CVS [was: Status Report 2007-10-15]
by Aaron Griffin 29 Oct '07

29 Oct '07

On 10/15/07, Andreas Radke <a.radke(a)arcor.de> wrote: > >From what I read and talk around it seems most European devs are more > comfortable with svn and American devs prefer git. Heh, you forgot Canadian! Either way, I think the distinction is more like so: The coders tend to prefer git, while the non-coders prefer svn. I'm glad you brought this up as it's something that has gone by the wayside for far too long. I have basically been waiting to see how other discussions have gone. So let me make a few salient points here: * The SCM doesn't matter. It doesn't. We're not doing anything complicated that we need advanced features for. The *ONLY* reason we use an SCM at all for PKGBUILDs is to track history. We keep discussing all this stuff as if we need super advanced features for PKGBUILDs and local branches, complex N-way merges, etc etc. We don't. We need to commit, and update. That's it. * There will always be a discomfort when we switch these things. However, if all developers use devtools except in extreme circumstances, there's no reason this discomfort should actually cause any problems. * Pros and cons are useless here. As I said in the first point, we have no need for the advanced features based on our usage patterns. Sure, we can make use of them later, but right now it shouldn't be weighting any decision. * Changing SCMs is fairly easy. If we fuck up, we change to something else - I could do all the grunt work here if people see this as any sort of issue (it's a 5-10 line config file for tailor) ------------------------------ So, here's what I'd like to do. This decision is fairly arbitrary, so let's try and throw out FACTUAL points FOR each SCM. I don't want to see any "X is better than Y because of Z" drivel. I want to see "X supports Z". Everyone has their "baby" SCM. That's not the issue. We need to make a decision, and opinions should have no place here. So. Bring up your points as they apply to our usage patterns. We'll discuss this until this weekend, and come next monday, I'd like to start a vote and see if we can get anywhere. Thanks guys, Aaron

8 31

[arch-dev-public] kernel module guidelines
by Paul Mattal 29 Oct '07

29 Oct '07

Should we add some material to the Arch Packaging Guidelines in the wiki describing the preferred structure of kernel module packages? That is, thing + thing-utils, where thing depends on thing-utils, and allows thing-otherkernel to provide thing and depend on thing-utils? I'm happy to take a crack at adding that language, just wanted to sanity check if there's some reason we don't have that in there. - P

4 4

[arch-dev-public] Kernel 2.6.24-rc1
by Alexander Baldeck 28 Oct '07

28 Oct '07

Hey all, I thought it would be worthwile to mention my experiences with 2.6.24-rc1 on my x86_64 laptop. Compiling ========= It seems that i386 and x86_64 get merged into only one architecture called x86. That brings a few issues with the current PKGBUILD, such as files not being there to copy anymore. When every x86_64 tag gets changed into just x86 though, everything is fine. I was able to cleanly build and use madwifi, nvidia on the other hand failed to even just build. Pretty much to be expected, huh? Anyway, I don't know how much changed for our i686 side. Running ======= One out of 4 boots my machine hung right after detecting its discs. At first I though it had to do with the new "tickless kernel" option but in the end I wasn't able to solve it. I'm using sata-nv on a all nvidia board. Anyway, just a little heads up for all of you in case you wondered what's so special about .24. ;) Cheers, -G

2 1

[arch-dev-public] [signoff] pciutils, usbutils (x86_64 only at this moment)
by Jan de Groot 28 Oct '07

28 Oct '07

During my update for hal, I noticed someone moved pci.ids and usb.ids from pciutils and usbutils to a place where many packages don't expect them. I moved them to /usr/share/hwdata, which is the same location used by Fedora/Redhat. Please signoff.

2 2

[arch-dev-public] missing packages in i686/extra
by Andreas Radke 28 Oct '07

28 Oct '07

==> Generating Text Package List... notice: Missing madplay-0.15.2b-2-i686.pkg.tar.gz in ftp site notice: Missing wine-0.9.47-1-i686.pkg.tar.gz in ftp site notice: Missing notification-daemon-xfce-0.3.6-1-i686.pkg.tar.gz in ftp site Please fix it. Andy

1 0

[arch-dev-public] [signoff] libldap 2.3.39-1
by Andreas Radke 28 Oct '07

28 Oct '07

in testing for both archs. nothing special. removed the no more working but unneeded bd detection. Andy

2 1

[arch-dev-public] libldap forces us to add db4.5 to core
by Andreas Radke 28 Oct '07

28 Oct '07

OpenLDAP cannot work together with recent db4.6. Last well supported db release is the db4.5 tree. db4.1 is to buggy and outdated to work well with recent ldap versions. I'm going to add db4.5 to core/lib. libldap/nfsidmap/nfs-utils depend on it. I will put it into testing to get some signoffs. OpenLDAP related packages from extra will also be rebuilt. This will save us also some rebuilds for the next db so.bump. Any concerns? Andy

1 1

[arch-dev-public] Super Quick Git Guide
by Roman Kyrylych 28 Oct '07

28 Oct '07

Hi! Bacause many of our projects use git now I thought that this quick git tutorial writen by Dan [1] may be useful for those who are new to git but want to contribute. It was my first introduction to git and I found it very useful. So here it is on our wiki: http://wiki.archlinux.org/index.php/Super_Quick_Git_Guide [1] ihttp://archlinux.org/pipermail/pacman-dev/2007-March/007850.html -- Roman Kyrylych (Роман Кирилич)

3 2

[arch-dev-public] [signoff] kernel26 2.6.23.1-6
by Tobias Powalowski 27 Oct '07

27 Oct '07

Hi kernel 2.6.23 for both arches in testing, please signoff this one adresses these bugs: http://bugs.archlinux.org/task/8435 http://bugs.archlinux.org/task/8431 http://bugs.archlinux.org/task/8422 - added some genpatches from gentoo - added fix for 2 ide modules in pair mode - added fix for zd1211rw oops greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1