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

[arch-dev-public] Heimdal changes
by Jan de Groot 13 Jan '09

13 Jan '09

Tonight I've been working on heimdal. I found out some things about this package: 1. It includes libeditline, a BSD port of libreadline. Nothing in the package uses this library, as heimdal is compiled with readline. The installed libreadline.* files are actually broken libraries, because they're missing the strlcopy symbols, which are only available on *BSD platforms, not in glibc. 2. We've been using patches from gentoo for a long while. The patches we included were introduced in some 0.7 version, and never reviewed in later versions. In the meanwhile, some don't apply or were replaced by newer patches. 3. Heimdal uses an internal snapshot of sqlite and links this one static inside the krb5 libraries. While this reduces dependencies, it has two problems: - security fixes in sqlite have to be tracked inside heimdal - static linking is evil because applications utilizing sqlite will end up with two copies of the sqlite library in memory I changed the PKGBUILD, added patches, added a dependency to sqlite3 and pushed it to testing. I also added -Wl,--as-needed to LDFLAGS to reduce link dependencies on sqlite3, as each and every binary links to it without these flags, while it's only used in the client libraries for the credentials cache. I would like to have some review on this, as it's a core package. This will also mean that sqlite3 has to be pulled from extra into core (or ssh and heimdal move to extra, as ssh is the only core package using heimdal, though I assume that's not a reasonable option).

10 24

[arch-dev-public] ffmpeg/x264 rebuild in [testing]
by Eric Bélanger 13 Jan '09

13 Jan '09

Hi, I just pushed an updated ffmpeg and x264 along with their corresponding rebuilds in testing. I only did the x86_64 packages. It would be great if someone would have time to build the i686 package. If not, I'll do them sometime this week. Updates: ffmpeg - Updated to svn snapshot dated at 20081220 (revision 16503) - soname bump: libavcodec.so.51 -> libavcodec.so.52 - liba52 wrapper was removed upstream x264 - Updated to 20090108 daily snapshot - soname bump: libx264.so.60 -> libx264.so.65 Rebuilds: avidemux - QT4 GUI is now included in package gstreamer0.10-bad-plugins motion mplayer opal sox transcode - upstream update,fixed imagemagick filter (FS#11039) vlc xine-lib - upstream update Please test and report any problems. Eric

4 6

Re: [arch-dev-public] mail 42388
by arch-dev-public＠archlinux.org 12 Jan '09

12 Jan '09

1 0

[arch-dev-public] [signoff] kernel26 2.6.28-3
by Tobias Powalowski 12 Jan '09

12 Jan '09

Hi guys, new kernel adresses the following things: just a quick rebuild which adds crda as optdepend. please signoff for both arches I would like to move in kernel, klibc, mkinitcpio, module-init-tools, crda (with depends) and binary modules this week to core if you are all fine with it. Showstopper: klibc needs to be fixed. It breaks compilation of tools. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4

[arch-dev-public] [signoff] klibc 1.5.15-1, klibc-extras, klibc-kbd, klibc-module-init-tools, klibc-udev
by Thomas Bächler 12 Jan '09

12 Jan '09

Okay, I updated klibc to 1.5.15 (properly fixing ext4 this time) and fixed the "klcc won't build anything" issue with a short workaround. The 1.5.15 update changed the ABI, so klibc-* and v86d are in testing as well. I also updated klibc-module-init-tools to 3.5 (matching the version of module-init-tools again). I only tested x86_64 and without ext4! So I need 2 signoffs for i686 and 1 for x86_64 (and maybe an ext4 test). Signoff procedure is to install the new packages, build a new initramfs and boot!

4 3

[arch-dev-public] Repo Hierarchy problems
by Xavier 11 Jan '09

11 Jan '09

On Sun, Jan 11, 2009 at 7:42 PM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: > > Check if these packages currently in extra have a (make)depends on > other packages from extra and so on. If these packages depends on too > many packages from extra, we might be better doing an exception and > keep them in extra. Otherwise we should try to move them to core. > So I just added some ugly codes to my tool to show this information. I added the list of dependencies that would need to be moved. Here is the result : Repo Hierarchy for Dependencies --------------------------------- extra/biopython depends on community/python-numpy (python-nose) Repo Hierarchy for Makedepends -------------------------------- extra/xosd depends on community/xmms () extra/flac depends on community/xmms () core/iputils depends on extra/opensp () core/iputils depends on extra/libxslt (libxml2 python tk sqlite3 tcl libxss libxft libxext scrnsaverproto libx11 xextproto libxcb kbproto xproto xf86bigfontproto xtrans inputproto xorg-util-macros xcb-proto libxdmcp libxau libxslt fontconfig libxrender freetype2 renderproto) core/iputils depends on extra/docbook-xsl (libxml2 libxslt docbook-xml python tk sqlite3 tcl libxss libxft libxext scrnsaverproto libx11 xextproto libxcb kbproto xproto xf86bigfontproto xtrans inputproto xorg-util-macros xcb-proto libxdmcp libxau fontconfig libxrender freetype2 renderproto unzip) core/madwifi-utils depends on extra/sharutils () core/e2fsprogs depends on extra/bc () extra/bigloo depends on community/jdk (jre) core/ca-certificates depends on extra/ruby (termcap-compat tk tcl libxss libxft libxext scrnsaverproto libx11 xextproto libxcb kbproto xproto xf86bigfontproto xtrans inputproto xorg-util-macros xcb-proto libxdmcp libxau libxslt python libxml2 sqlite3 fontconfig libxrender freetype2 renderproto) core/madwifi depends on extra/sharutils () extra/gnome-speech depends on community/espeak (portaudio xmms) The reasonable move are : python-numpy and python-nose from community to extra for biopython xmms from community to extra for xosd and flac sharutils from extra to core for madwifi-utils and madwifi bc from extra to core for e2fsprogs espeak, xmms and portaudio from community to extra for gnome-speech (I was wondering why xmms was here again, so I did a manual check : portaudio -> jack -> flac -> xmms) The problematic ones : core/iputils : libxslt and docbook-xsl in extra depend on libxml2, which needs python, which needs tk, which brings a lot of nice x11 stuff core/ca-certificates : ruby also depends on tk Just a guess, maybe it is possible to get a perfectly clean core chroot with a python and ruby version without tk support :)

2 1

[arch-dev-public] Further orphan clean-up
by Allan McRae 11 Jan '09

11 Jan '09

Hi, I have had a look at the orphaned packages in preparation for another round of clean-up. See my summary here: http://wiki.archlinux.org/index.php/User:Allan/Extra_Orphans_CleanUp What is listed is orphans that are out-of-date, fortune-mod packages and games that are orphaned for both arches. Some of the out-of-date orphans are requires for packages which do have maintainers. I have flagged the packages so have a quick look at the list and see you need them for one of your packages. Allan

2 2

[arch-dev-public] Welcome: Andrea Scarpino (BaSh)
by Aaron Griffin 10 Jan '09

10 Jan '09

I'd like to welcome Andrea into the fold here. If you don't know him, he goes by BaSh, and has been a TU for some time. Recently, he began helping us out as a Bug Wrangler on flyspray, which is greatly appreciated. Pierre has been asking for help with KDE maintenance, and Andrea has stepped up to the plate. So please welcome Andrea on board as a new packager / KDE maintainer. Welcome! Andrea, if you have any questions, feel free to ask the list, or any of us privately. Cheers, Aaron

4 4

[arch-dev-public] [signoff] pacman 3.2.2-1
by Dan McGee 10 Jan '09

10 Jan '09

Version bump. See NEWS (http://projects.archlinux.org/?p=pacman.git;a=blob;f=NEWS;h=f0a88fd88189fb2…) for more details. -Dan

10 11

Re: [arch-dev-public] [arch-general] x264, mplayer, ffmpeg rebuild?
by Eric Bélanger 09 Jan '09

09 Jan '09

On Mon, Dec 29, 2008 at 1:00 PM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Sun, Dec 28, 2008 at 5:34 PM, Scott Horowitz <stonecrest(a)gmail.com> wrote: >> On Sun, Dec 28, 2008 at 4:23 PM, Pierre Chapuis <catwell(a)archlinux.us> >> wrote: >>> >>> To me, the only way to use an up-to-date mplayer is to compile it yourself >>> on your machine (by using one of the AUR packages). >>> >>> Making a binary mplayer package is very difficult and the result can't be >>> perfect for everybody because you have to make choices about what will be >>> enabled in it (and add deps) and what will not (but some users might want >>> it). It's the prototype of the package that should stay source-based if >>> possible. >> >> That may be so, but there are binary packages available. And while that is >> the case, they should be updated every so often. I mean, ffmpeg is almost 6 >> months old and it's tied to revision 14236 - the current revision is 16380! >> We are 2000 commits behind, it's astounding. >> >> Not to mention I recently ran up into a bug where ffmpeg causes mpd to >> crash, and it's because the package is so out-dated. And there are other bug >> reports as well, dealing with other crashes and broken ogg support: >> >> http://bugs.archlinux.org/index.php?string=ffmpeg&project=1 >> >> So the question remains, will these packages be updated anytime soon? >> >> Back to your point about it being difficult to package - while I realize >> there are resource implications to this suggestion, I think the goal would >> be to have a couple different binary packages available to hit the most >> common uses, like is done with some other packages. I wouldn't throw up my >> hands and resort to compiling from source. Any idea how long it takes to >> compile mplayer on a p3? Trust me, it's not fun. > > This is a valid point, and I do agree. The "problem" here is all the > legwork with x264 and ffmpeg rebuilds... It's a lot of deps and a lot > of them (avidemux comes to mind) just don't compile against newer > versions. > > If anyone is interested in speeding up this process, I would love some > help with the following: > a) Bump x264 to the latest version > b) Bump ffmpeg to latest version > c) Rebuild all deps for the above > c') Patch apps that fail the build, and submit patches upstream > d) Post an FR listing the versions used and which packages build fine, > and which needs patches. Please attach the patches too. > > It's a lot of work, and I'd love to be able to do it sooner, rather > than later, but quite frankly, I have more pressing things to deal > with at this juncture. > FYI, I've started the rebuilds. The packages will be in the testing repo sometime soon depending how well it goes and how busy I am. FTR, I'm using a svn snapshot dating from 20081220 for ffmpeg. It's the date of the latest major change. Maybe using the very latest one would be unstable. For x264, I'm using the latest daily snapshot: 20090108. Let me know if it would be better to use other snapshots as I don't follow the developement of this stuff.

1 0