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

[arch-dev-public] [signoff] glibc-2.12-3
by Allan McRae 23 Jun '10

23 Jun '10

The new defaults in makepkg more aggressively strip shared libraries. Doing this for certain libraries in glibc causes gdb breakage so all file stripping must be done manually. Also, grab the latest from the glibc-2.12 branch as it contains a couple of new bugfixes. Signoff both, Allan

5 6

[arch-dev-public] Pacman Architecture option (was: [signoff] pacman 3.4.0-2)
by Dan McGee 22 Jun '10

22 Jun '10

On Tue, Jun 22, 2010 at 10:33 AM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > On Tue, 22 Jun 2010 17:21:32 +0200, Thomas Bächler <thomas(a)archlinux.org> > wrote: >> Am 22.06.2010 15:31, schrieb Allan McRae: >>> "Architecture = auto" causes issues on any system where the kernel is >>> not built for the same architecture as the packages (waves hand as >>> someone who cannot use it...). "Architecture = none" causes no >>> restrictions on the system setup so is the default. >> >> 'Architecture = auto' is the common case, so it should be the default >> (and actually, the default configuration file contains it). >> 'Architecture = none' is a rare corner case that virtually nobody will >> need, so it should not be the default. Just my 2 cents on sane default >> values. > > I agree with Thomas here; the common case should be the default; not the > rare corner case. At least on Arch you don't have mixed architectures > anyway. This is the last thing I will say on this. Where the heck were you guys 11 months ago? Surely not following development, but you want to piss about it now. Discussion: http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/008965.html http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/008968.html http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/008970.html Patches (with no feedback, mind you): http://mailman.archlinux.org/pipermail/pacman-dev/2009-August/009193.html Yes, Aaron did seem to lean your direction, but nothing persuasive enough to convince either me (who proposed the idea) or Xavier (who coded the idea) change our minds. It's put up or shut up, so to speak. I'm not saying you guys need to be turning out a patch a week to be able to offer opinions, but the statue of limitations on complaints is surely shorter than 11 months. Please don't see this as a personal blow to either of you guys- you both do a lot of great work around here. It just sucks to see 6 or so emails bitching about a feature (not even a bug!) that has been set for as long as this one has. -Dan

3 3

[arch-dev-public] News Draft- pacman 3.4.0 released
by Dan McGee 22 Jun '10

22 Jun '10

Pacman 3.4.0 released The latest and greatest version of pacman is now available in [core]. As usual, please report any issues or regressions to the <a href="http://bugs.archlinux.org/?project=3">bug tracker</a> after searching to see if your bug already exists. The changes in this release are detailed in the NEWS file located in GIT, which can be accessed <a href="http://projects.archlinux.org/pacman.git/tree/NEWS?id=v3.4.0">here</a>. Noteable changes in this release: <ul> <li>New "Architecture" option that will restrict pacman to installing only packages from the given architecture</li> <li>Installing packages with -U can handle installing dependencies</li> <li>New --print and --print-format options to output in suitable format for wrapper scripts</li> <li>Repository updates are faster as only new entries are extracted</li> <li>makepkg now aborts automatically with any errors during packaging</li> <li>makepkg now allows overrides of pkgver, pkgrel and arch in split packages</li> <li>...and many more improvements.</li> </ul> Thanks again to all of the developers and contributors that have made this release possible!

3 4

[arch-dev-public] [signoff] pacman 3.4.0-2
by Dan McGee 22 Jun '10

22 Jun '10

On Wed, Jun 16, 2010 at 9:42 PM, Allan McRae <allan(a)archlinux.org> wrote: > On 17/06/10 12:34, Dan McGee wrote: >> >> Upstream release, please signoff. >> > > Please make sure to update your makepkg.conf when updating to this, > _including in your chroots_. There may be file stripping issues if you do > not... > > And a summary of the upstream changes: > http://projects.archlinux.org/pacman.git/tree/NEWS?id=v3.4.0 OK, new -2 release in testing with the following changes, I'd like signoffs for real this time around: * We now have manpages * Fix optdepends * Patch the above mentioned strip libraries issue with patch from git so it is not disastrous There is also a new pacman-mirrorlist package in testing with the following change: * Move to multi-arch and use $arch variable in the list Please ensure it works with the new pacman; it will not be moving before it. -Dan

5 8

[arch-dev-public] dbscripts pkg pools
by Aaron Griffin 22 Jun '10

22 Jun '10

Hello all, I've had these patches sitting around for a bit: http://code.phraktured.net/cgit.cgi/dbscripts/log/?h=pkgpools I'd like to see if someone else has the time to test them. I have tested them with the following procedure: * created ./testing/{staging,myrepo,packages,package-cleanup}/ with necessary subdirs * modified config to point to these paths * commented out all the SVN malarky in db-add/db-remove/ftpdir-cleanup/etc * changed get_repos_for_host() to return "myrepo" Testing: * Add a package to myrepo - Package file in packages/os/*/ - Relative symlink in myrepo/os/*/ - In myrepo DB * Remove package from repo 'foo' - Removed from myrepo DB * Run cron-jobs/ftpdir-cleanup - Symlink is removed from myrepo/os/*/ - Package file moved from packages/os/*/ to package-cleanup/ Anyone else want to verify this, or should I push it to master? Aside: Would it be a good idea to add a "svn" function which could: a) handle svn checkout failures (we don't, right now) b) be easily switched out for dry-run style testing

6 31

[arch-dev-public] [PATCH] commitpkg: add newline to make output look more orderly
by Eric Bélanger 22 Jun '10

22 Jun '10

Signed-off-by: Eric Bélanger <snowmaniscool(a)gmail.com> --- commitpkg | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/commitpkg b/commitpkg index bd8c450..9f0b8c6 100755 --- a/commitpkg +++ b/commitpkg @@ -104,7 +104,7 @@ done if [ "${arch[*]}" == 'any' ]; then if [ -d ../repos/$repo-i686 -a -d ../repos/$repo-x86_64 ]; then pushd ../repos/ >/dev/null - echo -n "removing $repo-i686 and $repo-x86_64..." + echo "removing $repo-i686 and $repo-x86_64..." svn rm $repo-i686 svn rm $repo-x86_64 svn commit -q -m "removed $repo-i686 and $repo-x86_64 for $pkgname" -- 1.7.1

2 2

[arch-dev-public] SVN repository maintenance
by Dan McGee 22 Jun '10

22 Jun '10

I'd like to do some maintenance operations on our SVN packages repository on gerolde at some point (svn-packages). The format is still that from the 1.4.X series and we can make it a lot more efficient and get some space savings by doing either an in place upgrade and modification (easier but not preferred) or by doing a dump/load into the new format. In order to do this though, I need to make the repository temporarily unavailable for everyone for however long this takes. I don't foresee it taking more than 4 or so hours from start to finish. Does anyone have any objections with me doing this sometime tonight, e.g. 22nd June from 3 AM UTC - 7 AM UTC? -Dan

3 4

[arch-dev-public] [Bug] db-scripts fail to remove split package
by Thomas Bächler 21 Jun '10

21 Jun '10

I made this change to the kernel26 PKGBUILD: http://repos.archlinux.org/wsvn/packages/?op=comp&compare[]=%2Fkernel26%2Ft… However, db-testing fails to remove the kernel26-firmware package. I need to remove it manually.

4 6

[arch-dev-public] [signoff] libfetch 2.32
by Dan McGee 21 Jun '10

21 Jun '10

* Upstream update, one fix- Fix NULL dereference after failed calloc call. * Add license file * Move to package() function Please signoff both -Dan

5 4

[arch-dev-public] Committing multi-arch split packages
by Jan de Groot 21 Jun '10

21 Jun '10

So we have multi-arch split package support in Makepkg now. I tested this a bit, and results are nice: $ du -hs /srv/ftp/testing/os/*/wesnoth-1.8.2-2-*.pkg.tar.xz 266M /srv/ftp/testing/os/i686/wesnoth-1.8.2-2-i686.pkg.tar.xz 266M /srv/ftp/testing/os/x86_64/wesnoth-1.8.2-2-x86_64.pkg.tar.xz $ du -hs wesnoth-1.8.2-3-* wesnoth-data-1.8.2-3-any.pkg.tar.xz 3.2M wesnoth-1.8.2-3-i686.pkg.tar.xz 3.2M wesnoth-1.8.2-3-x86_64.pkg.tar.xz 262M wesnoth-data-1.8.2-3-any.pkg.tar.xz Downside of this is that makechrootpkg builds the -any package twice, so things could be improved there. Question is: how will commitpkg and our dbscripts handle this?

3 2