[arch-dev-public] How to manually add or remove packages from the repos
Hi Devs and TUs. in same rare cases it is needed to manually add or remove packages from our repositories regardless what is in SVN. ATM theses cases are due to e.g. svn crashing and leaving us with an inconsitent state or when some split packages have been removed from a new version of the pkgbuild. However, using repo-add or repo-remove on the dbfiles is a bad idea as they don't lock the db files and don't set the correct permissions. In short, just don't even think about doing that. :-) I have added some simple wrapper which are /arch/db-repo-add and /arch/db-repo-remove. Usage is: * db-repo-add pkgfile repo arch * db-repo-remove pkgname repo arch with pkgname being a single package name (not pkgbase) and pkgfile the full path to a single package. arch is one of i686, x86_64 or any. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
[arch-dev-public] Fixing packages with broken sources
Hello Devs and TUs, as you might know some licenses require providing the sources somehow. While fixing the sourceballs script which implements this I discovered quit a lot of broken PKGBUILDs. We really need to fix those asap as this also breaks ABS and makes rebuilds a real pain (and impossible to automate in future). I have setup a todo list which can be found at http://www.archlinux.org/todo/48/ (there are also links to the raw logs if you like to see why makepkg failed) Here is how to fix it: * If you just missed uploading a source file to svn there is no need to repackage; just add that file and run archrelease $repo-$arch And: use devtools in futuer which prevent such errors * If the checksum is wrong: Have a look why this happened! This might be a serious problem. You need to rebuild and rerelase the package with a new pkgrel of course. * Upstream source has moved. If the checksum is still the same, just update the source url and use archrelease. No need to repackage. * Upstream source is gone. If there is a new version, update to that. If that happens regulary or there is no releiable upstream source you should upload the source to ftp.archlinux.org/other/$pkgname. If the source file is quite big, let me know; so I can blacklist it as there is no need to mirror it twice. Also, let me know if there are any false positives. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-dev-public] Fixing packages with broken sources
On Mon, 22 Nov 2010 15:09:39 +0100, Pierre Schmitz pie...@archlinux.de wrote: I have setup a todo list which can be found at http://www.archlinux.org/todo/48/ (there are also links to the raw logs if you like to see why makepkg failed) Somehow this list drop the split packages. A complete list can be found athttps://users.archlinux.de/~pierre/tmp/broken-pkgs.txt Also have a log at the raw log for other errors. -- Pierre Schmitz, https://users.archlinux.de/~pierre
[arch-dev-public] boost 1.45 rebuild
Hi, i just pushed in staging repository boost 1.45. Note to all packagers that they need to rebuild their packages against staging directory. I've saw a trend in the past then staging was used that they didn't enabled staging when building. -- Ionuț
Re: [arch-dev-public] boost 1.45 rebuild
On Mon, 22 Nov 2010 17:38:18 +0200, Ionuț Bîru ib...@archlinux.org wrote: Hi, i just pushed in staging repository boost 1.45. Note to all packagers that they need to rebuild their packages against staging directory. I've saw a trend in the past then staging was used that they didn't enabled staging when building. Which just means those people weren't using devtools as they should. :-) -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-dev-public] [signoff] filesystem 2010.11-2
On Sat, 20 Nov 2010 09:40:57 +0100, Pierre Schmitz pie...@archlinux.de wrote: Hi all, I recently adopted the orphaned package filesystem and made a little review/rewrite. Some of the changes may be questionable so don't hesitate to give suggestions. Pushed -2 into testing to fix/implement https://bugs.archlinux.org/task/21759 -- Pierre Schmitz, https://users.archlinux.de/~pierre
[arch-dev-public] O'Reilly book: Making Software
My boss just brought this book over to my desk. It's one of those theory books that's all about measuring lines of code and whatnot. But the reason he brought it over, is Chapter 8: Beyond Lines of Code: Do We Need More Complex Metrics?. Two pages in, it begins with: **Measuring the Source Code** We have selected for our case study the ArchLinux software distribution (http://archlinux.org), which contains thousands of packages, all open source. ArchLinux is a lightweight GNU/Linux distribution whose maintainers refuse to modify the source code packaged for the distribution, in order to meet the goal of drastically reducing the time that elapses between the official release of a package and its integration into the distribution. ... Because of the size of ArchLinux, using it as a case study gives us access to the original source code of thousands of open source projects, through the build scripts used by ABS (see Example 8-1) The chapter goes on with statistics and all that junk. They're not studying Arch, but using Arch as a launch pad for getting large amounts of open source source code for analysis. The numbers are interesting: The ArchLinux repositories contained 4096 packages (as of April 2010), with some of the packages being different versions of the same upstream project. After removing different versions, we obtained a sample of 4015 packages, containing 1272748 source code files. Among all those files, 576511 were written in C. However, there were repeated files. In the overall sample, only 776573 were unique files; in the C subsample, only 338831 were unique files. From these unique C files, 212167 were nonheader files and 126664 were header files.
Re: [arch-dev-public] O'Reilly book: Making Software
On 22 November 2010 19:39, Aaron Griffin aaronmgrif...@gmail.com wrote: My boss just brought this book over to my desk. It's one of those theory books that's all about measuring lines of code and whatnot. But the reason he brought it over, is Chapter 8: Beyond Lines of Code: Do We Need More Complex Metrics?. Two pages in, it begins with: **Measuring the Source Code** We have selected for our case study the ArchLinux software distribution (http://archlinux.org), which contains thousands of packages, all open source. ArchLinux is a lightweight GNU/Linux distribution whose maintainers refuse to modify the source code packaged for the distribution, in order to meet the goal of drastically reducing the time that elapses between the official release of a package and its integration into the distribution. ... Because of the size of ArchLinux, using it as a case study gives us access to the original source code of thousands of open source projects, through the build scripts used by ABS (see Example 8-1) The chapter goes on with statistics and all that junk. They're not studying Arch, but using Arch as a launch pad for getting large amounts of open source source code for analysis. The numbers are interesting: The ArchLinux repositories contained 4096 packages (as of April 2010), with some of the packages being different versions of the same upstream project. After removing different versions, we obtained a sample of 4015 packages, containing 1272748 source code files. Among all those files, 576511 were written in C. However, there were repeated files. In the overall sample, only 776573 were unique files; in the C subsample, only 338831 were unique files. From these unique C files, 212167 were nonheader files and 126664 were header files. Great! Proud to see Arch here :) The author might also be an Archer, who knows. BTW I also like the idea of your boss coming to give you the book like Oh and there this O'Reilly book about some of the stuff you do -- Guillaume
Re: [arch-dev-public] O'Reilly book: Making Software
On Mon, 22 Nov 2010 12:39:57 -0600 Aaron Griffin aaronmgrif...@gmail.com wrote: My boss just brought this book over to my desk. It's one of those theory books that's all about measuring lines of code and whatnot. But the reason he brought it over, is Chapter 8: Beyond Lines of Code: Do We Need More Complex Metrics?. Two pages in, it begins with: **Measuring the Source Code** We have selected for our case study the ArchLinux software distribution (http://archlinux.org), which contains thousands of packages, all open source. ArchLinux is a lightweight GNU/Linux distribution whose maintainers refuse to modify the source code packaged for the distribution, in order to meet the goal of drastically reducing the time that elapses between the official release of a package and its integration into the distribution. ... Because of the size of ArchLinux, using it as a case study gives us access to the original source code of thousands of open source projects, through the build scripts used by ABS (see Example 8-1) The chapter goes on with statistics and all that junk. They're not studying Arch, but using Arch as a launch pad for getting large amounts of open source source code for analysis. The numbers are interesting: The ArchLinux repositories contained 4096 packages (as of April 2010), with some of the packages being different versions of the same upstream project. After removing different versions, we obtained a sample of 4015 packages, containing 1272748 source code files. Among all those files, 576511 were written in C. However, there were repeated files. In the overall sample, only 776573 were unique files; in the C subsample, only 338831 were unique files. From these unique C files, 212167 were nonheader files and 126664 were header files. hmmm.. 39% of all files in our packages are duplicates. That's interesting. Wonder where they come from. Dieter
Re: [arch-dev-public] O'Reilly book: Making Software
On 23/11/10 07:09, Dieter Plaetinck wrote: On Mon, 22 Nov 2010 12:39:57 -0600 Aaron Griffinaaronmgrif...@gmail.com wrote: My boss just brought this book over to my desk. It's one of those theory books that's all about measuring lines of code and whatnot. But the reason he brought it over, is Chapter 8: Beyond Lines of Code: Do We Need More Complex Metrics?. Two pages in, it begins with: **Measuring the Source Code** We have selected for our case study the ArchLinux software distribution (http://archlinux.org), which contains thousands of packages, all open source. ArchLinux is a lightweight GNU/Linux distribution whose maintainers refuse to modify the source code packaged for the distribution, in order to meet the goal of drastically reducing the time that elapses between the official release of a package and its integration into the distribution. ... Because of the size of ArchLinux, using it as a case study gives us access to the original source code of thousands of open source projects, through the build scripts used by ABS (see Example 8-1) The chapter goes on with statistics and all that junk. They're not studying Arch, but using Arch as a launch pad for getting large amounts of open source source code for analysis. The numbers are interesting: The ArchLinux repositories contained 4096 packages (as of April 2010), with some of the packages being different versions of the same upstream project. After removing different versions, we obtained a sample of 4015 packages, containing 1272748 source code files. Among all those files, 576511 were written in C. However, there were repeated files. In the overall sample, only 776573 were unique files; in the C subsample, only 338831 were unique files. From these unique C files, 212167 were nonheader files and 126664 were header files. hmmm.. 39% of all files in our packages are duplicates. That's interesting. Wonder where they come from. A lot of projects include sources from their dependencies inside their tarball. Allan
Re: [arch-dev-public] [signoff] lvm2/device-mapper 2.02.76-1
Am 21.11.2010 09:14, schrieb Eric Bélanger: Hi, lvm2/device-mapper 2.02.76-1 are in testing. Please test and signoff. Signoffs from users are welcome. - Minor upstream update. ChangeLog below. Signoff both architectures. Only tested booting from LVM, as always. signature.asc Description: OpenPGP digital signature
[arch-dev-public] Integrity Check i686: core, extra, community 22-11-2010
= 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 Duplicate PKGBUILDs - /srv/abs/rsync/any/community/adesklet-weatherforecast vs. /srv/abs/rsync/i686/community/adesklet-weatherforecast /srv/abs/rsync/any/community/cgmail vs. /srv/abs/rsync/i686/community/cgmail /srv/abs/rsync/any/community/python-configobj vs. /srv/abs/rsync/i686/community/python-configobj /srv/abs/rsync/any/community/sauerbraten vs. /srv/abs/rsync/i686/community/sauerbraten /srv/abs/rsync/any/community/sauerbraten vs. /srv/abs/rsync/i686/community/sauerbraten /srv/abs/rsync/any/community/subdownloader vs. /srv/abs/rsync/i686/community/subdownloader /srv/abs/rsync/any/community/wammu vs. /srv/abs/rsync/i686/community/wammu /srv/abs/rsync/any/extra/getmail vs. /srv/abs/rsync/i686/extra/getmail /srv/abs/rsync/any/extra/python-formencode vs. /srv/abs/rsync/i686/extra/python-formencode /srv/abs/rsync/any/extra/pyxdg vs. /srv/abs/rsync/i686/extra/pyxdg /srv/abs/rsync/any/extra/scons vs. /srv/abs/rsync/i686/extra/scons /srv/abs/rsync/i686/extra/perl vs. /srv/abs/rsync/i686/core/perl Missing Dependencies -- extra/haskell-cgi -- 'haskell-parsec=3.1.0' Missing Makedepends - community/gnome-do-plugins -- 'flickrnet' community/ogmrip -- 'gpac' community/xmobar -- 'haskell-parsec=3.1.0' extra/v86d -- 'kernel262.6.33' Repo Hierarchy for Dependencies - extra/miro depends on community/python-pycurl (0 extra (make)deps to pull) Repo Hierarchy for Makedepends core/ca-certificates depends on extra/python (31 extra (make)deps to pull) core/ca-certificates depends on extra/ruby (148 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (32 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/glib2 depends on extra/python2 (31 extra (make)deps to pull) core/groff depends on extra/ghostscript (148 extra (make)deps to pull) core/groff depends on extra/netpbm (51 extra (make)deps to pull) core/groff depends on extra/psutils (148 extra (make)deps to pull) core/iputils depends on extra/docbook-xsl (31 extra (make)deps to pull) core/iputils depends on extra/libxslt (31 extra (make)deps to pull) core/iputils depends on extra/opensp (31 extra (make)deps to pull) core/kernel26 depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26 depends on extra/xmlto (31 extra (make)deps to pull) core/kernel26-docs depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26-docs depends on extra/xmlto (31 extra (make)deps to pull) core/kernel26-headers depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26-headers depends on extra/xmlto (31 extra (make)deps to pull) core/kernel26-manpages depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26-manpages depends on extra/xmlto (31 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (0 extra (make)deps to pull) core/udev depends on extra/gobject-introspection (35 extra (make)deps to pull) core/udev depends on extra/gperf (0 extra (make)deps to pull) core/udev depends on extra/libxslt (31 extra (make)deps to pull) core/udev-compat depends on extra/gobject-introspection (35 extra (make)deps to pull) core/udev-compat depends on extra/gperf (0 extra (make)deps to pull) core/udev-compat depends on extra/libxslt (31 extra (make)deps to pull) extra/bigloo depends on community/jdk (2 extra (make)deps to pull : jre chrpath) extra/gnome-speech depends on community/espeak (1 extra (make)deps to pull : portaudio) extra/go-openoffice depends on community/cppunit (0 extra (make)deps to pull) extra/grml-zsh-config depends on community/txt2tags (0 extra (make)deps to pull) extra/libiodbc depends on community/chrpath (0 extra (make)deps to pull) extra/libreoffice depends on community/cppunit (0 extra (make)deps to pull) extra/opengtl depends on community/llvm (0 extra (make)deps to pull) extra/openoffice-base-beta depends on community/cppunit (0 extra (make)deps to pull) extra/openoffice-base-devel depends on community/cppunit (0 extra (make)deps to pull) extra/openoffice-sdk-beta depends on community/cppunit (0 extra (make)deps to pull) extra/openoffice-sdk-devel depends on community/cppunit (0 extra (make)deps to pull) extra/speech-dispatcher depends on community/espeak (1 extra (make)deps to pull : portaudio) extra/vigra depends on community/python-sphinx (2 extra (make)deps to pull : python-pygments python-jinja) extra/xfconf depends on community/chrpath (0 extra (make)deps to pull) Packages found in
[arch-dev-public] Integrity Check x86_64: core, extra, community 22-11-2010
== = 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 Duplicate PKGBUILDs - /srv/abs/rsync/any/community/adesklet-weatherforecast vs. /srv/abs/rsync/x86_64/community/adesklet-weatherforecast /srv/abs/rsync/any/community/cgmail vs. /srv/abs/rsync/x86_64/community/cgmail /srv/abs/rsync/any/community/python-configobj vs. /srv/abs/rsync/x86_64/community/python-configobj /srv/abs/rsync/any/community/sauerbraten vs. /srv/abs/rsync/x86_64/community/sauerbraten /srv/abs/rsync/any/community/sauerbraten vs. /srv/abs/rsync/x86_64/community/sauerbraten /srv/abs/rsync/any/community/subdownloader vs. /srv/abs/rsync/x86_64/community/subdownloader /srv/abs/rsync/any/community/wammu vs. /srv/abs/rsync/x86_64/community/wammu /srv/abs/rsync/any/extra/getmail vs. /srv/abs/rsync/x86_64/extra/getmail /srv/abs/rsync/any/extra/python-formencode vs. /srv/abs/rsync/x86_64/extra/python-formencode /srv/abs/rsync/any/extra/pyxdg vs. /srv/abs/rsync/x86_64/extra/pyxdg /srv/abs/rsync/any/extra/scons vs. /srv/abs/rsync/x86_64/extra/scons Missing Dependencies -- community/dwarffortress -- 'lib32-gtk2' community/dwarffortress -- 'lib32-libsndfile' community/dwarffortress -- 'lib32-libxdamage' community/dwarffortress -- 'lib32-mesa' community/dwarffortress -- 'lib32-ncurses' community/dwarffortress -- 'lib32-openal' community/dwarffortress -- 'lib32-sdl_image' community/dwarffortress -- 'lib32-sdl_ttf' community/q4wine -- 'wine' community/winetricks -- 'wine' extra/haskell-cgi -- 'haskell-parsec=3.1.0' Missing Makedepends - community/gnome-do-plugins -- 'flickrnet' community/ogmrip -- 'gpac' community/virtualbox-ose -- 'gcc-multilib' community/virtualbox-ose -- 'lib32-glibc' community/virtualbox-ose-additions -- 'gcc-multilib' community/virtualbox-ose-additions -- 'lib32-glibc' community/virtualbox-ose-additions-modules -- 'gcc-multilib' community/virtualbox-ose-additions-modules -- 'lib32-glibc' community/xmobar -- 'haskell-parsec=3.1.0' extra/v86d -- 'kernel262.6.33' Repo Hierarchy for Dependencies - extra/miro depends on community/python-pycurl (0 extra (make)deps to pull) Repo Hierarchy for Makedepends core/ca-certificates depends on extra/python (31 extra (make)deps to pull) core/ca-certificates depends on extra/ruby (148 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (32 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/glib2 depends on extra/python2 (31 extra (make)deps to pull) core/groff depends on extra/ghostscript (148 extra (make)deps to pull) core/groff depends on extra/netpbm (51 extra (make)deps to pull) core/groff depends on extra/psutils (148 extra (make)deps to pull) core/iputils depends on extra/docbook-xsl (31 extra (make)deps to pull) core/iputils depends on extra/libxslt (31 extra (make)deps to pull) core/iputils depends on extra/opensp (31 extra (make)deps to pull) core/kernel26 depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26 depends on extra/xmlto (31 extra (make)deps to pull) core/kernel26-docs depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26-docs depends on extra/xmlto (31 extra (make)deps to pull) core/kernel26-headers depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26-headers depends on extra/xmlto (31 extra (make)deps to pull) core/kernel26-manpages depends on extra/docbook-xsl (31 extra (make)deps to pull) core/kernel26-manpages depends on extra/xmlto (31 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (0 extra (make)deps to pull) core/udev depends on extra/gobject-introspection (35 extra (make)deps to pull) core/udev depends on extra/gperf (0 extra (make)deps to pull) core/udev depends on extra/libxslt (31 extra (make)deps to pull) core/udev-compat depends on extra/gobject-introspection (35 extra (make)deps to pull) core/udev-compat depends on extra/gperf (0 extra (make)deps to pull) core/udev-compat depends on extra/libxslt (31 extra (make)deps to pull) extra/bigloo depends on community/jdk (2 extra (make)deps to pull : jre chrpath) extra/gnome-speech depends on community/espeak (1 extra (make)deps to pull : portaudio) extra/go-openoffice depends on community/cppunit (0 extra (make)deps to pull) extra/grml-zsh-config depends on community/txt2tags (0 extra (make)deps to pull) extra/libiodbc depends on community/chrpath (0 extra (make)deps to pull) extra/libreoffice depends on community/cppunit (0 extra (make)deps to pull) extra/opengtl depends on
Re: [arch-dev-public] Integrity Check i686: core, extra, community 22-11-2010
On Mon, 22 Nov 2010 16:52:14 -0500 (EST), repoma...@archlinux.org wrote: Summary - Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names:0 Duplicate PKGBUILDs: 12 Invalid archs: 0 Missing (make)dependencies:5 Repo hierarchy problems: 41 Circular dependencies: 0 In db, but not in tree:3 In tree, but not in db:1 Nobody noticed, but the integrity check was broken for a long time now. I somehow made it working again. Note: If python got updated to 2.7 on gerolde let me know, so I can update the alpm module. Am I right that this python module only export the vercmp method? http://projects.archlinux.org/dbscripts.git/tree/cron-jobs/check_archlinux/alpm.c Maybe it would be way more portable if we would just call the vercmp binary; or maybe python has such a method built-in like PHP has. Greetings and have fun fixing the new bugs that tool found, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-dev-public] Integrity Check i686: core, extra, community 22-11-2010
On Mon, Nov 22, 2010 at 3:58 PM, Pierre Schmitz pie...@archlinux.de wrote: Maybe it would be way more portable if we would just call the vercmp binary; or maybe python has such a method built-in like PHP has. I've used distutils.version to some success for this sort of thing. Not sure if it follows the pacman rules to the letter though
Re: [arch-dev-public] Integrity Check i686: core, extra, community 22-11-2010
On Monday 22 November 2010 22:52:14 repoma...@archlinux.org wrote: Duplicate PKGBUILDs - /srv/abs/rsync/any/community/adesklet-weatherforecast vs. /srv/abs/rsync/i686/community/adesklet-weatherforecast /srv/abs/rsync/any/community/cgmail vs. /srv/abs/rsync/i686/community/cgmail /srv/abs/rsync/any/community/python-configobj vs. /srv/abs/rsync/i686/community/python-configobj /srv/abs/rsync/any/community/sauerbraten vs. /srv/abs/rsync/i686/community/sauerbraten /srv/abs/rsync/any/community/sauerbraten vs. /srv/abs/rsync/i686/community/sauerbraten /srv/abs/rsync/any/community/subdownloader vs. /srv/abs/rsync/i686/community/subdownloader /srv/abs/rsync/any/community/wammu vs. /srv/abs/rsync/i686/community/wammu /srv/abs/rsync/any/extra/getmail vs. /srv/abs/rsync/i686/extra/getmail /srv/abs/rsync/any/extra/python-formencode vs. /srv/abs/rsync/i686/extra/python-formencode /srv/abs/rsync/any/extra/pyxdg vs. /srv/abs/rsync/i686/extra/pyxdg /srv/abs/rsync/any/extra/scons vs. /srv/abs/rsync/i686/extra/scons /srv/abs/rsync/i686/extra/perl vs. /srv/abs/rsync/i686/core/perl fixing these... Missing Dependencies -- extra/haskell-cgi -- 'haskell-parsec=3.1.0' reported: https://bugs.archlinux.org/task/21792 -- Andrea Scarpino Arch Linux Developer
Re: [arch-dev-public] [arch-notifications] Integrity Check i686: core, extra, community 22-11-2010
On Monday, November 22, 2010, Aaron Griffin aaronmgrif...@gmail.com wrote: On Mon, Nov 22, 2010 at 3:58 PM, Pierre Schmitz pie...@archlinux.de wrote: Maybe it would be way more portable if we would just call the vercmp binary; or maybe python has such a method built-in like PHP has. I've used distutils.version to some success for this sort of thing. Not sure if it follows the pacman rules to the letter though Look in the archives; we switched it on purpose and sped it up by like 10x. So calling the vercmp binary is not a great idea. -Dan
Re: [arch-dev-public] [arch-notifications] Integrity Check i686: core, extra, community 22-11-2010
On Mon, 22 Nov 2010 16:13:16 -0600, Dan McGee dpmc...@gmail.com wrote: On Monday, November 22, 2010, Aaron Griffin aaronmgrif...@gmail.com wrote: On Mon, Nov 22, 2010 at 3:58 PM, Pierre Schmitz pie...@archlinux.de wrote: Maybe it would be way more portable if we would just call the vercmp binary; or maybe python has such a method built-in like PHP has. I've used distutils.version to some success for this sort of thing. Not sure if it follows the pacman rules to the letter though Look in the archives; we switched it on purpose and sped it up by like 10x. So calling the vercmp binary is not a great idea. -Dan Good to know; found that commit from two years ago. :-) I need to have a closer look at that code; there is some new stuff we need to take care of. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-dev-public] [signoff] readline-6.1.002-2
[2010-11-20 20:35:54 +1000] Allan McRae: Remove sourcing ~/inputrc from /etc/inputrc (FS#21729) signoff i686
Re: [arch-dev-public] [signoff] libusb-0.1.12-5
[2010-11-19 16:21:27 +0100] Andrea Scarpino: - use package() - remove from base group - use tar.xz signoff i686
Re: [arch-dev-public] [signoff] filesystem 2010.11-2
[2010-11-22 19:31:48 +0100] Pierre Schmitz: I recently adopted the orphaned package filesystem and made a little review/rewrite. Some of the changes may be questionable so don't hesitate to give suggestions. Pushed -2 into testing to fix/implement https://bugs.archlinux.org/task/21759 signoff i686
Re: [arch-dev-public] [signoff] initscripts-2010.07-2 and wireless_tools-29-4
[2010-11-20 12:55:06 +0100] Pierre Schmitz: I rebuild both packages due to core cleanup/rebuild. I have also moved the file /etc/conf.d/wireless from wireless_tools to initscripts, where it really belongs. Future versions of initscripts might remove support for wireless/network then. signoff i686 (both packages)
Re: [arch-dev-public] Source package creation repaired
On Sun, Nov 21, 2010 at 6:41 PM, Pierre Schmitz pie...@archlinux.de wrote: Hi devs, I repaired the sourceball creation script the last days. I didn't active the cron job yet as a couple of packages should be fixed first (will send a new mail about that) * Similar to the package pool there are now two subdirs for our core/extra packages and the ones from community in ftp/sources. * The sourceballs user has srcdest set to ~/sourceballs so we don't need to redownload sources on every minor update * A cron job removes files older than 120 days from that srcdest folder * I have added a new rsync module to sigurd in order to provide these sources for gerolde * Instead of logging to files the plan is to send the output of the scripts to the arch-notifications mailing list A few suggestions about the notification email: 1) It would be helpfull to list the failed packages (content of failed.txt wich you apparently removed) before the makepkg output. At a glance, we'll be able to see if one of our package has failed without going through pages of output. Maybe it won't be as useful after we fix the current packages. 2) Seperate the makepkg output of each failed package with an empty line or a long line of dashes or equal signs. It'll make them easier to distinguish. 3) The script is checking for multilib repos for i686. As it dosn't find the db it just aborts but we should just skip the check. This will enable us to not send the email if there are no failures.
[arch-dev-public] [signoff] findutils-4.4.2-3
* Rebuild of old package * Tidy up PKGBUILD * Avoid building of locate (provided by mlocate) Please signoff both. Thanks Stéphane
[arch-dev-public] perl-5.12.2 rebuild list?
Hi, Can we get some details of what the perl-5.12.2 rebuild list is for? Its description is Build modules that have binary modules in them but surely there is binary compatibility between 5.12.1 and 5.12.2... Or have the expected paths for binaries changed again? Allan
