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

[arch-dev-public] Xorg changes / DRM modules
by Andreas Radke 24 Dec '09

24 Dec '09

I've updated the git packages for nouveau and ati ddx driver packages in testing. I also updated the nouveau-drm package. This required to add the new nouveau-firmware package. It will be also needed to use kernel nouveau-drm module that will be introduced with kernel 2.6.33. I will keep updating the separate nouveua-drm module for a while to get features and fixes faster than in Linus tree. The firmware will probably also result in loading issues in early kms mode. We might think about recommending late mode for now. libdrm has been updated to 2.4.17 - this is breaking all radeon 3d stuff and will require changes in MESA when I understand the upstream devs right. Mesa7.7 is expected in a few days anyways and should make Radeon 3d stuff working again after a few late commits (7.7rc4 doesn't build with new libdrm). Other drivers should still work. Please test them. Radeon kms is still buggy like hell and unusable for my RC410 [Radeon Xpress 200M] card. It makes X and the whole system freeze instantly when moving windows around or when I try to start 3d apps. Sometimes even at Xorg start at all. This has been introduced with 2.6.32 kernels. Upstream recommends to try the various drm trees: http://article.gmane.org/gmane.comp.video.dri.devel/40626 Any opinions from other ati users what branch is the most stable and useful these days? I'm thinking about adding a radeon-drm kernel module package to solve the tons of speed and stability issues. As already written on the closed devel list, I'd like to get help for these packages from other devs and community members. Whoever is well informed in Xorg/kernel drm development and wants to help to stabilize our drivers please contact me. -Andy

3 7

[arch-dev-public] Punishment needed for not building in a chroot
by Allan McRae 24 Dec '09

24 Dec '09

Hi, We have been through this many times... you should always build in a clean chroot. But there are continuously bugs about packages linking to non-deps. We should never have such bugs. e.g. (FS#17409) > readelf -d /usr/bin/mpd ... 0x00000001 (NEEDED) Shared library: [libjack.so.0] ... > pactree -u mpd | sort ... gmp imlib2 kbproto kernel-headers ... How did that get to linking to jack without jack being in its dependency tree? Poor packaging... The tools are very simple to use and are described in the wiki (http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot) There is _no_ excuse not to use them. The are minor changes needed for doing i686 builds on x86_64 and vise versa, but there are plenty of us doing that so help is available. Ask for help if needed. So, we need a creative punishment for those that causes bugs by not building in a clean chroot. It is too early in the morning for me to be creative so I am struggling to come up with ideas besides beatings and removal of commit privileges. Any better ideas? Allan

8 24

[arch-dev-public] Added category to Community project on flyspray
by Andrea Scarpino 23 Dec '09

23 Dec '09

Hi, I added "Packages: Testing" category to Community project on our flyspray. Sorry if I should ask first. -- Andrea `bash` Scarpino Arch Linux Developer

2 1

[arch-dev-public] [signoff] udev-147-1
by Tobias Powalowski 23 Dec '09

23 Dec '09

Hi Major changes: - Minimal kernel version bumped to 2.6.27: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=1da6c797fdbb9437… - Older kernels than 2.6.31 might need the udev-compat package: Most NAME= instructions got removed. Kernel 2.6.31 supplies the needed names if they are not the default. To support older kernels, the NAME=rules need to be added to the compat rules file. Other changes: To support DEVPATH strings larger than the maximum file name length, the private udev database format has changed. If some software still reads the private files in /dev/.udev/, which it shouldn't, now it's time to fix it. Please do not port anything to the new format again, everything in /dev/.udev is and always was private to udev, and may and will change any time without prior notice. Multiple devices claiming the same names in /dev are limited to symlinks only now. Mixing identical symlink names and node names is not supported. This reduces the amount of data in the database significantly. NAME="%k" causes a warning now. It's is and always was completely superfluous. It will break kernel supplied DEVNAMEs and therefore it needs to be removed from all rules. Symlinks to udevadm with the old command names are no longer resolved to the udevadm commands. The udev-acl tool got adopted to changes in ConsoleKit. Version 0.4.11 is required now. The option "last_rule" does no longer exist. Its use breaks too many things which expect to be run from independent later rules, and is an idication that something needs to be fixed properly instead. The gudev API is no longer marked as experimental, G_UDEV_API_IS_SUBJECT_TO_CHANGE is no longer needed. The gudev introspection is enabled by default now. Various projects already depend on introspection information to bind dynamic languages to the gudev interfaces. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

7 16

[arch-dev-public] Moonlight in Arch Linux
by Daniel Isenmann 22 Dec '09

22 Dec '09

Hi, I know that this topic was discussed in January this year and we decided to put it to AUR and if it have enough votes to [community]. For all new developers, here is the discussion from January: http://mailman.archlinux.org/pipermail/arch-dev-public/2009-January/010029.… Now it's in community, but it's outdated and which is the real problem, you must build it with a fresh built and installed mono during compilation time. It depends very close to mono and therefor I would like to bring it to [extra], to maintain it with the rest of the mono stack which I already do. Also a bug report was posted because of this issue: http://bugs.archlinux.org/task/17573 The maintainer in community seems not be active anymore (Timm Preetz) and moonlight is orphan. Any objections from your side? Cheers, Daniel

5 15

[arch-dev-public] [signoff] kernel 2.6.32.1-1
by Tobias Powalowski 20 Dec '09

20 Dec '09

Hi guys, Upstream changes: http://kernelnewbies.org/LinuxChanges Arch Linux bugfixes/feature requests: http://bugs.archlinux.org/task/16855 # added CONFIG_PM_DEBUG http://bugs.archlinux.org/task/17106 # added CONFIG_MMIOTRACE Arch Linux changes: - splitted kernel-headers to extra package If you want to build external modules please install: pacman -S kernel26-headers Please change your PKGBUILDS to makedepend on this package. - added xen support to 64bit kernel - changed intel kms enabled by default - changed to new firewire subsystem: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

[arch-dev-public] [signoff] kernel26-lts-2.6.27.42-1 & kernel26-lts-headers-2.6.27.42-1
by Tobias Powalowski 20 Dec '09

20 Dec '09

Hi guys, - added pvops options to latest release on x86_64 - splitted header into seperate package - synced PKGUILD structure with .32 please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] chroots config question
by Paul Mattal 19 Dec '09

19 Dec '09

Regarding the below: http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot It reads: "The -C and -M flags are optional, but it is recommended to provide these with clean pacman.conf and makepkg.conf files (directly from the pacman package) during first creation of clean chroot to ensure lack of user specific adjustments." I think this is misleading. If you *don't* provide these arguments, what you get is the default config files directly from the pacman package, right? So the desired thing in most circumstances is, presumably, NOT to override? - P

3 3

[arch-dev-public] Integrity Check x86_64: core, extra, community 18-12-2009
by repomaint＠archlinux.org 18 Dec '09

18 Dec '09

================================================== = Integrity Check x86_64 of core,extra,community = ================================================== Performing integrity checks... ==> parsing pkgbuilds ==> parsing db files ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking hierarchy ==> checking for circular dependencies ==> checking for differences between db files and pkgbuilds Missing Dependencies ---------------------- community/eclipse-ve --> 'eclipse<3.3' extra/archboot --> 'libdownload>=1.3-3' extra/digikam --> 'liblcms' Missing Makedepends --------------------- extra/kdelibs3 --> 'autoconf<2.64' extra/v86d --> 'kernel26<2.6.30' Repo Hierarchy for Dependencies --------------------------------- extra/haskell-hashed-storage depends on community/haskell-zlib (0 extra (make)deps to pull) extra/munin depends on community/perl-html-template (0 extra (make)deps to pull) extra/munin depends on community/perl-log-log4perl (0 extra (make)deps to pull) extra/munin-node depends on community/perl-net-server (0 extra (make)deps to pull) extra/pan depends on community/gmime22 (0 extra (make)deps to pull) Repo Hierarchy for Makedepends -------------------------------- core/ca-certificates depends on extra/ruby (25 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (26 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/groff depends on extra/ghostscript (146 extra (make)deps to pull) core/groff depends on extra/netpbm (45 extra (make)deps to pull) core/groff depends on extra/psutils (147 extra (make)deps to pull) core/iputils depends on extra/docbook-xsl (26 extra (make)deps to pull) core/iputils depends on extra/libxslt (25 extra (make)deps to pull) core/iputils depends on extra/opensp (28 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (0 extra (make)deps to pull) core/udev depends on extra/gperf (0 extra (make)deps to pull) core/udev depends on extra/libxslt (25 extra (make)deps to pull) extra/bigloo depends on community/jdk (1 extra (make)deps to pull : jre) extra/dbus-python depends on community/docutils (0 extra (make)deps to pull) extra/gnome-speech depends on community/espeak (2 extra (make)deps to pull : portaudio docutils) extra/grml-zsh-config depends on community/txt2tags (0 extra (make)deps to pull) extra/xqf depends on community/chrpath (0 extra (make)deps to pull) Packages found in tree, but not in db --------------------------------------- extra/openoffice-en-US Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 5 Repo hierarchy problems: 22 Circular dependencies: 0 In db, but not in tree: 0 In tree, but not in db: 1

2 1

[arch-dev-public] Integrity Check i686: core, extra, community 18-12-2009
by repomaint＠archlinux.org 18 Dec '09

18 Dec '09

================================================ = Integrity Check i686 of core,extra,community = ================================================ Performing integrity checks... ==> parsing pkgbuilds ==> parsing db files ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking hierarchy ==> checking for circular dependencies ==> checking for differences between db files and pkgbuilds Missing Dependencies ---------------------- community/eclipse-ve --> 'eclipse<3.3' extra/archboot --> 'libdownload>=1.3-3' Missing Makedepends --------------------- extra/kdelibs3 --> 'autoconf<2.64' extra/v86d --> 'kernel26<2.6.30' Repo Hierarchy for Dependencies --------------------------------- extra/haskell-hashed-storage depends on community/haskell-zlib (0 extra (make)deps to pull) extra/munin depends on community/perl-html-template (0 extra (make)deps to pull) extra/munin depends on community/perl-log-log4perl (0 extra (make)deps to pull) extra/munin-node depends on community/perl-net-server (0 extra (make)deps to pull) extra/pan depends on community/gmime22 (0 extra (make)deps to pull) Repo Hierarchy for Makedepends -------------------------------- core/ca-certificates depends on extra/ruby (25 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (26 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/groff depends on extra/ghostscript (145 extra (make)deps to pull) core/groff depends on extra/netpbm (45 extra (make)deps to pull) core/groff depends on extra/psutils (146 extra (make)deps to pull) core/iputils depends on extra/docbook-xsl (26 extra (make)deps to pull) core/iputils depends on extra/libxslt (25 extra (make)deps to pull) core/iputils depends on extra/opensp (28 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (0 extra (make)deps to pull) core/udev depends on extra/gperf (0 extra (make)deps to pull) core/udev depends on extra/libxslt (25 extra (make)deps to pull) extra/bigloo depends on community/jdk (1 extra (make)deps to pull : jre) extra/gnome-speech depends on community/espeak (1 extra (make)deps to pull : portaudio) extra/grml-zsh-config depends on community/txt2tags (0 extra (make)deps to pull) extra/xqf depends on community/chrpath (0 extra (make)deps to pull) Packages found in tree, but not in db --------------------------------------- extra/openoffice-en-US Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 4 Repo hierarchy problems: 21 Circular dependencies: 0 In db, but not in tree: 0 In tree, but not in db: 1

1 0