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

Re: [arch-dev-public] [signoff] gawk-3.1.8-1
by Tobias Powalowski 14 May '10

14 May '10

Hi bump to latest version, Changes from 3.1.7 to 3.1.8 --------------------------- 1. The zero flag no longer applies to %c and %s; apparently the standards changed at some point. 2. Updated to latest infrastructure: Autoconf 2.65, Automake 1.11.1, libtool 2.2.6b, Bison 2.4.2. 3. Failure to open a socket is no longer a fatal error. 4. dfa.h and dfa.c are now more-or-less in sync with GNU grep, for the first time in many years. 5. Gawk no longer includes its own copy of libsigsegv but it will use it if installed on the build system. The --disable-libsigsegv configure option is now gone. 6. The ' flag (%'d) is now just ignored on systems that can't support it. 7. Lots of bug fixes, see the ChangeLog. please signoff both arches, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] libgpg-error 1.7-3
by Thomas Bächler 14 May '10

14 May '10

This moves the shared library from /usr/lib to /lib, so that dynamically links cryptsetup works before /usr is mounted.

3 2

[arch-dev-public] [signoff] kernel26 2.6.33.4-1
by Thomas Bächler 14 May '10

14 May '10

Upstream update, please test carefully and sign off. So far, this build has only been tested in 32 and 64 Bit KVM devices.

5 4

[arch-dev-public] Website updated- package maintainer changes
by Dan McGee 13 May '10

13 May '10

Hey guys, I just pushed a website update today that improves something everyone has been clamoring for- package maintainers. The quick hits: * Package maintainership is now by 'pkgbase'. If you "adopt" one package, you become a maintainer for all packages with that same pkgbase (including across all architectures). This also means when a package is converted from arch-specific to arch-independent, you won't have to re-adopt it. * We will never lose package maintainer info if we lose packages and they come back in a later processing of the DB. Eric will be glad to hear this. * Multiple maintainers are supported. See http://www.archlinux.org/packages/extra/x86_64/thunderbird/ for an example. All maintainers will get an email when the package is marked out of date (if they are signed up to do so). With all that said, the concept of package adoption is now not an exclusive affair- multiple people can adopt packages and all be listed as maintainers. Let me (and the list) know if you have any questions. -Dan

7 11

[arch-dev-public] [signoff] popt 1.16-1
by Andrea Scarpino 13 May '10

13 May '10

Upstream release. ChangeLog: - add lv.po, update translations (Translation Project). - include xcode project files in distributed popt tar ball. - make distcheck is now squeaky clean. - permit VPATH builds. - add shallow tests using ISP/RAS api-sanity-autotest.pl. - prefix bit set routines with popt to avoid symbol coolisions w rpm. - add tdict.c to exercise popt bit sets against /usr/dict/words. - add poptBitsArgs() method to generate args bit set. - add methods for bit set union and intersection. - permit comma separated attribute lists, handle negated attributes. - better test for POPT_ARG_BITSET. - add POPT_ARG_BITSET handling. - add POPT_ARG_SHORT handling. - handle all callback traversals within a C switch (for extendability ease). - add popt.pc. - devzero2000: add AC_CONFIG_AUX_DIR, AC_CONFIG_MACRO_DIR to configure. Create build-aux - devzero2000: del acinclude.m4 : AC_CHECK_VA_COPY is not used -- Andrea Scarpino - andreascarpino.it KDE Maintainer in Arch Linux

4 9

[arch-dev-public] Add -fstack-protector{-all} to default CFLAGS?
by Allan McRae 12 May '10

12 May '10

Hi, We have a bug report asking to enable stack-smashing protection in our package building. Looking at the overhead estimates by other distros that use it, overall it appears fairly minimal (OpenBSD says 1.3% on average). There used to be some build issues (see bottom of this page for Ubuntu report: https://wiki.ubuntu.com/GccSsp) but I am not sure of the current status. Also, it can be disabled with -fno-stack-protector if needed. I am in favour of doing this. I think adding -fstack-protector is enough as that adds protection to only functions "vulnerable" to buffer overflows (as defined by gcc... mainly character arrays) while -fstack-protector-all adds it to all functions. We should maybe also add -D_FORTIFY_SOURCE=2. This detects some buffer overflows compile time and others at run time. It was designed to have minimal runtime overhead. Any opinions? Allan

5 10

[arch-dev-public] [signoff] libgcrypt 1.4.5-2
by Thomas Bächler 11 May '10

11 May '10

This moves the shared library from /usr/lib to /lib, so that dynamically linked cryptsetup works before /usr is mounted.

3 4

[arch-dev-public] [toolchain] gcc 4.5 breakage
by Thomas Bächler 10 May '10

10 May '10

I noticed problem with gcc 4.5 and the GAP system (http://www.gap-system.org) first: It throws a few aliasing warnings, and the program breaks. When I used -fno-strict-aliasing, the warnings disappeared, but the breakage remained, unless I used -O0. Fixing the aliasing problems also fixed the breakage. Now I noticed the exact same issue with busybox: - Building with -Os throws lots of aliasing warnings, busybox's sed breaks - Building with -Os -fno-strict-aliasing builds without warnings, but it still breaks. - Building with -O0 works, but it isn't optimal. This will affect LOTS of other programs and these errors will not show up as errors or warnings during the build procedure.

4 10

[arch-dev-public] Redefining [testing] and a new [staging] repo
by Pierre Schmitz 09 May '10

09 May '10

Hi all, here is another crazy idea I was thinking about for some days. This should improve our overall package quality and simplify our work flow. The problem with out current [testing] repository are these: * it is only used by very few people. Most of the times we don't get much feedback until packages are moved to core or extra * it is often in a inconsistent state; especially during incomplete so name bump rebuilds * sometimes packages are known to be broken or unstable On the other side we are sometimes in need of some intermediate repository. For example single people stack a pile of packages in their home dirs until they can be moved to a repo at once. We have also seen temporary repos like jpng to manage larger rebuilds. My idea is to redefine the testing repo and introduce a new staging one. (remember the good old days? ;-)) With the implementation of the package pooling moving packages between repos can be done with nearly no overhead. So ideally we should be able to use testing more often, even for a very short period like a day. proposal for [testing] * never push any known-to-be-broken packages here (for example incomplete rebuilds) * candidates for core are put here * ideally new builds of important/critical packages or major rebuilds can be put here to test them by a larger audience. * don't put any package in here which are never meant to be moved to core/extra. (like experimental alpha software etc.) proposal for [staging] * this repo should only used by devs and tus * it is not meant to be used on a production system * it should only be enabled in a packages build environment (chroot) * this could be even excluded from outbound rsync. Due to package pooling packages would still be propagated. And moving those packages to other repos will be "instantly". Summing things up more packages should be passed through testing, more users should be able to use testing without breaking their systems and we don't have to make them reading the high traffic arch-dev-public list. We also should be able to collaborate more in packaging: Dev A puts a new lib into [staging] and another one can start rebuild other packages using that lib. Another common use case would be large builds like KDE we usually start packaging one week before release. Till now those were put into users' staging dirs and the other devs had to manually download them, create a local repo and install them. So, what do you think about this idea? Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

5 8

Re: [arch-dev-public] [arch-general] [signoff] kernel26 2.6.33.3-2 (and aufs2)
by Pierre Schmitz 09 May '10

09 May '10

On Sat, 8 May 2010 00:04:43 +0200, Dieter Plaetinck <dieter(a)plaetinck.be> wrote: > On Sun, 02 May 2010 17:49:13 +0200 > Pierre Schmitz <pierre(a)archlinux.de> wrote: > >> This new kernel just exports some additional symbols for aufs2 which >> was updated to a new snapshot. This should hopefully fix some issues >> with the .33 kernel and aufs. Related aufs packages are: aufs2 >> 2.6.33_20100425-2 and aufs2-util 20100422-1 >> >> In addition to regular sign-off some feedback about aufs would be >> nice; especially if you use archiso. > > http://build.archlinux.org/isos/archlinux-2010.05.07-netinstall-i686.iso > boots fine on my system. signoff i686. > > once i have rebuilt images (with correct copyright statement) i will > let the community test, then you'll have a bit more feedback about how > well it works ;) > > Dieter It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed with this version. So, I'll move these to core/extra. -- Pierre Schmitz, https://users.archlinux.de/~pierre

1 0