- Arch-general - lists.archlinux.org

[arch-general] [signoff] kernel26-lts 2.6.32.29-1
by Andreas Radke 18 Feb '11

18 Feb '11

Upstream update. Please signoff. -Andy http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.…

1 0

[arch-general] Trinity - traditional PKGBUILD set done
by David C. Rankin 18 Feb '11

18 Feb '11

Guys, I have completed a set of traditional PKGBUILD scripts for Trinity that download the needed svn source and build the Trinity packages as usual rather than you needing to put the PKGBUILD script in the svn tree. The are normal tarballs that contain the PKGBUILDs and any patches needed. Note: you must build in a clean environment without kde4/Qt4 or kdemod3 present. A clean Arch install in a Virtualbox VM works fine. For those wanting to give them a try, here is the build order with links: trinity-qt3: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-qt3.tar.gz trinity-pyqt3: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-pyqt3.tar.gz trinity-tqtinterface: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-tqtinterface.tar.… trinity-arts: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-arts.tar.gz trinity-kdelibs: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-kdelibs.tar.gz trinity-kdebase: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-kdebase.tar.gz NOTE: you can start Trinity after you build and install trinity-kdebase trinity-kdevelop: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-kdevelop.tar.gz trinity-kdewebdev: http://www.3111skyline.com/dl/dt/trinity/arch/src/trinity-kdewebdev.tar.gz I have also updated the wiki with links: https://wiki.archlinux.org/index.php/Trinity If you experience any problems -- let me know :) -- David C. Rankin, J.D.,P.E.

1 2

[arch-general] [signoff] kernel26-2.6.37-6
by Tobias Powalowski 18 Feb '11

18 Feb '11

Hi guys, - rebuild against latest binutils/glibc greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-general] makechrootpkg -d and corrupted repos
by Magnus Therning 18 Feb '11

18 Feb '11

Over the last few weeks I've noticed that the repository created by 'makechrootpkg -d' regularly becomes corrupted. Subsequent builds result in something like resolving dependencies... looking for inter-conflicts... Targets (2): haskell-boolean-0.0.1-1 haskell-memotrie-0.4.9-1 Total Download Size: 0.00 MB Total Installed Size: 1.36 MB Proceed with installation? [Y/n] checking package integrity... :: File haskell-boolean-0.0.1-1-x86_64.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] :: File haskell-memotrie-0.4.9-1-x86_64.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package) haskell-boolean-0.0.1-1-x86_64.pkg.tar.xz is invalid or corrupted haskell-memotrie-0.4.9-1-x86_64.pkg.tar.xz is invalid or corrupted Errors occurred, no packages were upgraded. I then have to jump into the chroot and manually re-build the repo DB using repo-add. After that I can re-issue the command and everything is fine. I've not done any research into this issue, but when I've asked around in the ArchHaskell group no one recognises this issue. However, I seem to be the only one building on x86_64, but I'm nonplused why that would play any role. So I thought I'd ask a little wider, has anyone else seen this behaviour when using 'makechrootpkg -d'? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

1 1

[arch-general] 2011.02-1 archboot "2k11-R1" ISO hybrid image released
by Tobias Powalowski 18 Feb '11

18 Feb '11

Hi Arch community, Arch Linux (archboot creation tool) 2011.02-1, "2k11-R1" has been released. To avoid confusion, this is not an official arch linux iso release! Homepage and for more information on archboot: http://wiki.archlinux.org/index.php/Archboot Forum: https://bbs.archlinux.org/viewtopic.php?id=113741 Summary: - bump to latest kernels - introduce full UEFI bootloader support with new grub2 packages. Hybrid image file and torrent is provided, which include i686 and x86_64 core repository. Please check md5sum before using it. Hybrid image file is a standard CD-burnable image and also a raw disk image. - Can be burned to CD(RW) media using most CD-burning utilities. - Can be raw-written to a drive using 'dd' or similar utilities. This method is intended for use with USB thumb drives. Please get it from your favorite arch linux mirror: - https://downloads.archlinux.de/iso/archboot/2011.02/ - <yourmirror>/iso/archboot/2010.12/ Have fun, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] sanity check - pkgbuild writing svn rev as $pkgver for new packages - help?
by David C. Rankin 17 Feb '11

17 Feb '11

Guys, I'm working on a second set of pkgbuild for Trinity that do the svn download for you and work like normal pkgbuilds for other svn projects. One issue I'm having is getting the "finished package name" to include the svn revision as $pkgver instead of the initial (eg. pkgver=9999). The bottom line is if I update pkgver in build() it isn't used when the final package is written. If I only update it between build() and package() then the final package gets the correct svn rev as $pkgver, but all messages during build are wrong. So I end up updating the pkgver in build() and then between build() and package(). That doesn't seem right. The problem seems like a scope issue for pkgver. If set in build() pkgver isn't seen globally in the PKGBUILD script, even though it is declared with global scope and updated in build(). Can somebody familiar with PKGBUILDs give the following a quick look to make sure it is reasonable and I'm not biting my myself by the double call to update pkgver? http://www.3111skyline.com/dl/dt/trinity/arch/pkgbuild/svn/PKGBUILD-tqtinte… Thanks! -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] should kdepim-libkdepim-4.4.10-1 and kdepim-runtime-4.4.10-1 still be on the system with kde 4.6?
by David C. Rankin 17 Feb '11

17 Feb '11

Guys, Removing kde4 from a test box to work with Trinity, I ran across a few kde4 files that looked like they were orphans. I had already removed kde4 with: pacman -R kde gtk-kde4 kdebindings-smoke kdeplasma-addons-libs kmldonkey konq-plugins kopete-cryptography qtcurve-kde4 yakuake Checking /usr/share/autostart, there were still files present. So checking ownership I found: 15:51 supersff:~> l /usr/share/autostart/ total 40 drwxr-xr-x 2 root root 4096 Feb 17 15:32 . drwxr-xr-x 404 root root 12288 Feb 17 15:47 .. -rw-r--r-- 1 root root 4417 Jan 27 08:47 kaddressbookmigrator.desktop -rw-r--r-- 1 root root 10584 Jan 19 16:04 nepomukserver.desktop -rw-r--r-- 1 root root 908 Dec 9 02:51 polkit-kde-authentication-agent-1.desktop 15:51 supersff:~> pmq -o /usr/share/autostart/nepomukserver.desktop /usr/share/autostart/nepomukserver.desktop is owned by kdebase-runtime 4.6.0-1 15:52 supersff:~> pmq -o /usr/share/autostart/kaddressbookmigrator.desktop /usr/share/autostart/kaddressbookmigrator.desktop is owned by kdepim-runtime 4.4.10-1 15:52 supersff:~> pmq -o /usr/share/autostart/polkit-kde-authentication-agent-1.desktop /usr/share/autostart/polkit-kde-authentication-agent-1.desktop is owned by polkit-kde 0.99.0-1 Trying to remove the packages listed dependencies I thought would have already been removed when I removed kde: 15:52 supersff:~> sudo pacman -R kdebase-runtime kdepim-runtime polkit-kde checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: kcoloredit: requires kdebase-runtime :: kdebindings-python: requires kdepim-runtime :: kdepim-libkdepim: requires kdepim-runtime :: kdiff3: requires kdebase-runtime :: kfax: requires kdebase-runtime :: kgrab: requires kdebase-runtime :: kgraphviewer: requires kdebase-runtime :: kiconedit: requires kdebase-runtime :: kpovmodeler: requires kdebase-runtime :: kwebkitpart: requires kdebase-runtime I guess if they are just dependent on the kdebase-runtime, then they could have been separately installed. The big thing that caught my eye were the kde44 version on the kdepim files when I went to remove all the dependencies: 15:52 supersff:~> sudo pacman -R kdebase-runtime kdepim-runtime polkit-kde kcoloredit kdebindings-python kdepim-libkdepim kdiff3 kfax kgrab kgraphviewer kiconedit kpovmodeler kwebkitpart checking dependencies... Remove (13): kwebkitpart-1.1-1 kpovmodeler-1.1.3-3 kiconedit-4.4.0-1 kgraphviewer-2.1.1-1 kgrab-0.1.1-3 kfax-3.3.6-2 kdiff3-0.9.95-2 kdepim-libkdepim-4.4.10-1 kdebindings-python-4.6.0-1 kcoloredit-2.0.0-4 polkit-kde-0.99.0-1 kdepim-runtime-4.4.10-1 kdebase-runtime-4.6.0-1 Total Removed Size: 84.10 MB Is there any problem with the kdepim 4.4 files with the kde 4.6 install? Just thought I would run this by the experts. -- David C. Rankin, J.D.,P.E.

2 1

[arch-general] vi dependency mailx - why not mailx-heirloom?
by David C. Rankin 17 Feb '11

17 Feb '11

Guys, Just a quick question on the vi dependency of mailx. Why not mailx-heirloom? It provides a great deal more capability with attachments, and flexibility as a cli mailer. The issues is down in the noise, but why drive a pinto if you can drive a jag? -- David C. Rankin, J.D.,P.E.

2 1

[arch-general] Trinity Running on Arch Linux!
by David C. Rankin 17 Feb '11

17 Feb '11

Guys, It works! After building kdebase (and fighting with other modules), I just decided to start trinity and see if it would work. Changed ~/.xinitrc to 'startkde' and then typed 'startx' and: http://www.3111skyline.com/dl/dt/trinity/ss/trinity-first-run.jpg http://www.3111skyline.com/dl/dt/trinity/ss/trinity-running_01.jpg (this is running in a clean virtualbox Arch install) There is still work to be done, because all modules have not yet been ported to CMake, but for a proof of concept for the PKGBUILDs on Arch -- a complete success. I'll bring the wiki up to date later today, but it already contains the PKGBUILDs that will build Trinity into a working desktop with a single [very 'Quick & Dirty'] build script called 'bldtrin.sh' (for development purposes only). For those interested. See the wiki: https://wiki.archlinux.org/index.php/Trinity -- David C. Rankin, J.D.,P.E.

7 9

[arch-general] Question about automated builder
by Thomas S Hatch 17 Feb '11

17 Feb '11

I have mentioned this subject before on aur-general, but I wanted to open a discussion about it in the broader community. I have spent a great deal of my career working with Red Hat Linux, as have many in the professional Linux world, and there is one project that is amazingly useful for the Red Hat world, and that is Koji. You can take a look at the web interface for koji here: http://koji.fedoraproject.org/koji/ Basically, koji acts as a continuous build server for the fedora project's rpms. it has a number of benefits, one is that all of the building is done in a controlled environment, so we have a %100 assurance that the packages makedepends are correct, and and the packages are all built inside of clean chroots. Koji also allows for very simple mass-rebuilds of packages, since all anyone needs to do it increment the release number and koji can pick up the change and build the package. I have been passively working on a similar project called quarters, but I must admit that my motivation is somewhat low not knowing if the project is in demand. So here is my question, do we think that something like this would be a benefit to Arch? Is this the type of project that should merit my attention? Also, if we do think that this would be a good thing to have for Arch, I would like feedback on what types of features the system would have and how it would behave. Right now I am following the idea of supporting a distributed build system so that we can have any number of build servers in the fray working away to produce Arch packages for us. I am also attempting to build it in such a way that a database is not required and that the interface would be amazingly simple (this is Arch after all). This would mean that by mearly checking into svn a package would be built, and then an interface would pop up for the right people to sign it off, and once it has been signed off it would move over. Or at least that is the basic idea I am running on. The code has not come very far, but if the Arch community and developers think that this is a good idea then please let me know, my motivation should soar and I will make Arch a super continuous package build system! -Thomas S Hatch -TU

11 32