Re: [arch-dev-public] [signoff] openssh-5.8p1-1
On Fri, 2011-02-04 at 08:42 +0100, Gaetan Bisson wrote: Hi all, OpenSSH 5.8 has just been released as a security update on 5.7; see the Changelog below. Nothing but the version numbers and checksums changed in the PKGBUILD of openssh-5.8-p1-1, which I just put in [testing]. Please test and signoff so we can move this as quickly as possible. Cheers. All good here! Signoff x86_64. -- Guillaume signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] [signoff] openssh-5.8p1-1
Le 4 février 2011 02:42:17, Gaetan Bisson a écrit : Hi all, OpenSSH 5.8 has just been released as a security update on 5.7; see the Changelog below. Nothing but the version numbers and checksums changed in the PKGBUILD of openssh-5.8-p1-1, which I just put in [testing]. Please test and signoff so we can move this as quickly as possible. Cheers. Signoff i686 (in a VM) Stéphane
[arch-dev-public] [signoff] sysfsutils-2.1.0-6
* Rebuild of old package * Tidy up PKGBUILD Please note that I have not adressed FS#16766. Please signoff both. Thanks Stéphane
Re: [arch-dev-public] [signoff] sqlite3 - 3.7.5-1
anyone for i686? state about tcl? -Andy
Re: [arch-dev-public] [signoff] sqlite3 - 3.7.5-1
On 04/02/11 23:19, Andreas Radke wrote: anyone for i686? state about tcl? I can give an i686 signoff. No idea about tcl though...
Re: [arch-dev-public] MySQL 5.5
2011/1/30 Andreas Radke a.ra...@arcor.de: Am Wed, 26 Jan 2011 21:36:52 -0200 schrieb Ángel Velásquez an...@archlinux.org: 2011/1/26 Ángel Velásquez an...@archlinux.org: 2011/1/26 Andrea Scarpino and...@archlinux.org: On Wednesday 26 January 2011 16:23:46 Ángel Velásquez wrote: Why partition table plugin was disabled? any particular reason? I talked with some MySQL dev and they said that their usage is very low, do we need them? Well I use it on productions systems, and though previous versions of Arch package had this support enabled by default. I figured out that the support was disabled cause I was trying to partitionate some tables :). Anyway I've rebuilt with abs the mysql and I have it for my machine, just I thought it was any reason in particular to don't add this. I'm rebuilding this package with the partition table support, talking in #archlinux-dev seems that it's a cool feature and it's worth to have it on our package. So I will put a new version in [testing] I've just finished the missing rebuilds. koffice-kexi is done in the poppler rebuild in staging that will soon also move to testing. -Andy Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-dev-public] MySQL 5.5
Am Fri, 4 Feb 2011 16:41:06 -0200 schrieb Ángel Velásquez an...@archlinux.org: I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams Sounds good to me if you can make sure we don't break everybody systems. The poppler rebuild sitting in testing also has to wait for the mysql move. -Andy
Re: [arch-dev-public] MySQL 5.5
On 02/04/2011 08:41 PM, Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams does this update needs some manually steps that have to be done? does a simply pacman -Syu /etc/rc.d/mysql restart do the job? -- Ionuț
Re: [arch-dev-public] MySQL 5.5
On Fri, Feb 4, 2011 at 1:40 PM, Ionuț Bîru ib...@archlinux.org wrote: On 02/04/2011 08:41 PM, Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams does this update needs some manually steps that have to be done? does a simply pacman -Syu /etc/rc.d/mysql restart do the job? I believe running mysql-upgrade is recommended after the restart as well. -Dan
Re: [arch-dev-public] MySQL 5.5
2011/2/4 Dan McGee dpmc...@gmail.com: On Fri, Feb 4, 2011 at 1:40 PM, Ionuț Bîru ib...@archlinux.org wrote: On 02/04/2011 08:41 PM, Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams does this update needs some manually steps that have to be done? does a simply pacman -Syu /etc/rc.d/mysql restart do the job? I believe running mysql-upgrade is recommended after the restart as well. -Dan As Dan's pointed just need a pacman -Syu mysql-upgrade /etc/rc.d/mysql restart , I've tried on two machines on production, and my workstation for weeks and it's working just fine, Maybe we can write a news about it (because some people usersread .install messages :P) -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-dev-public] MySQL 5.5
2011/2/4 Ángel Velásquez an...@archlinux.org: 2011/2/4 Dan McGee dpmc...@gmail.com: On Fri, Feb 4, 2011 at 1:40 PM, Ionuț Bîru ib...@archlinux.org wrote: On 02/04/2011 08:41 PM, Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams does this update needs some manually steps that have to be done? does a simply pacman -Syu /etc/rc.d/mysql restart do the job? I believe running mysql-upgrade is recommended after the restart as well. -Dan As Dan's pointed just need a pacman -Syu mysql-upgrade /etc/rc.d/mysql restart , I've tried on two machines on production, and my workstation for weeks and it's working just fine, Maybe we can write a news about it (because some people usersread .install messages :P) Don't you want to run upgrade after restart?
Re: [arch-dev-public] MySQL 5.5
2011/2/4 Dan McGee dpmc...@gmail.com: 2011/2/4 Ángel Velásquez an...@archlinux.org: 2011/2/4 Dan McGee dpmc...@gmail.com: On Fri, Feb 4, 2011 at 1:40 PM, Ionuț Bîru ib...@archlinux.org wrote: On 02/04/2011 08:41 PM, Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams does this update needs some manually steps that have to be done? does a simply pacman -Syu /etc/rc.d/mysql restart do the job? I believe running mysql-upgrade is recommended after the restart as well. -Dan As Dan's pointed just need a pacman -Syu mysql-upgrade /etc/rc.d/mysql restart , I've tried on two machines on production, and my workstation for weeks and it's working just fine, Maybe we can write a news about it (because some people usersread .install messages :P) Don't you want to run upgrade after restart? pacman -Syu /etc/rc.d/mysqld restart mysql-upgrade -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-dev-public] MySQL 5.5
On Friday 04 February 2011 16:41:06 Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. Yes, I'd like to wait until 5.5.9, but I understand that we don't know when MySQL devs will release it. I just added two patches to our MySQL in [testing], I didn't rebuild it so you can add something else or write a better post_install message. :) I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams Thank you. If you take the responsability I vote +1 for the move and I'll try to be present as much as I can (will be hard). Another note Angel: maybe in the announcement you should write that example, archive, blackhole and federated engine are now disabled. -- Andrea
[arch-dev-public] Integrity Check i686: core, extra, community 04-02-2011
= 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 Makedepends - community/xmobar -- 'haskell-parsec=3.1.0' Repo Hierarchy for Dependencies - extra/miro depends on community/python-pycurl (0 extra (make)deps to pull) extra/perl-text-wrapi18n depends on community/perl-text-charwidth (0 extra (make)deps to pull) Repo Hierarchy for Makedepends core/binutils depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/ca-certificates depends on extra/python2 (60 extra (make)deps to pull) core/ca-certificates depends on extra/ruby (157 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (61 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (3 extra (make)deps to pull : dejagnu expect tcl) core/gcc depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-ada depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-fortran depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-libs depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-objc depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/glib2 depends on extra/python2 (60 extra (make)deps to pull) core/groff depends on extra/ghostscript (157 extra (make)deps to pull) core/groff depends on extra/netpbm (60 extra (make)deps to pull) core/groff depends on extra/psutils (157 extra (make)deps to pull) core/kernel26 depends on extra/docbook-xsl (60 extra (make)deps to pull) core/kernel26 depends on extra/xmlto (60 extra (make)deps to pull) core/kernel26-docs depends on extra/docbook-xsl (60 extra (make)deps to pull) core/kernel26-docs depends on extra/xmlto (60 extra (make)deps to pull) core/kernel26-headers depends on extra/docbook-xsl (60 extra (make)deps to pull) core/kernel26-headers depends on extra/xmlto (60 extra (make)deps to pull) core/lilo depends on extra/sharutils (60 extra (make)deps to pull) core/links depends on extra/libpng (3 extra (make)deps to pull : dejagnu expect tcl) core/links depends on extra/libtiff (60 extra (make)deps to pull) core/links depends on extra/libxt (60 extra (make)deps to pull) core/pam depends on extra/docbook-xml (60 extra (make)deps to pull) core/pam depends on extra/docbook-xsl (60 extra (make)deps to pull) core/pam depends on extra/w3m (60 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (3 extra (make)deps to pull : dejagnu expect tcl) core/sqlite3-doc depends on extra/tcl (3 extra (make)deps to pull : dejagnu expect tcl) core/udev depends on extra/gobject-introspection (62 extra (make)deps to pull) core/udev depends on extra/gperf (3 extra (make)deps to pull : dejagnu expect tcl) core/udev depends on extra/libxslt (60 extra (make)deps to pull) core/udev-compat depends on extra/gobject-introspection (62 extra (make)deps to pull) core/udev-compat depends on extra/gperf (3 extra (make)deps to pull : dejagnu expect tcl) core/udev-compat depends on extra/libxslt (60 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 (3 extra (make)deps to pull : portaudio jack2-dbus celt-0.7) 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/libreoffice-extension-ct2n depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-diagram depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-hunart depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-nlpsolver depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-numbertext depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-oooblogger depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-pdfimport depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-presentation-minimizer depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-presenter-screen depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-report-builder depends on community/cppunit (0 extra (make)deps to pull) extra/libreoffice-extension-typo depends on community/cppunit (0 extra
[arch-dev-public] Integrity Check x86_64: core, extra, community, multilib 04-02-2011
Warning : the repository multilib does not exist in /srv/abs/rsync/any === = Integrity Check x86_64 of core,extra,community,multilib = === 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 PKGBUILDs --- /srv/abs/rsync/any/multilib Missing Makedepends - community/xmobar -- 'haskell-parsec=3.1.0' Repo Hierarchy for Dependencies - community/winetricks depends on multilib/wine (72 extra (make)deps to pull) extra/miro depends on community/python-pycurl (0 extra (make)deps to pull) extra/perl-text-wrapi18n depends on community/perl-text-charwidth (0 extra (make)deps to pull) Repo Hierarchy for Makedepends community/virtualbox depends on multilib/gcc-multilib (6 extra (make)deps to pull : binutils-multilib gcc-libs-multilib gcc-ada-multilib lib32-glibc gcc-multilib lib32-gcc-libs) community/virtualbox depends on multilib/lib32-glibc (6 extra (make)deps to pull : gcc-multilib binutils-multilib gcc-libs-multilib gcc-ada-multilib lib32-glibc lib32-gcc-libs) community/virtualbox-guest-additions depends on multilib/gcc-multilib (6 extra (make)deps to pull : binutils-multilib gcc-libs-multilib gcc-ada-multilib lib32-glibc gcc-multilib lib32-gcc-libs) community/virtualbox-guest-additions depends on multilib/lib32-glibc (6 extra (make)deps to pull : gcc-multilib binutils-multilib gcc-libs-multilib gcc-ada-multilib lib32-glibc lib32-gcc-libs) community/virtualbox-guest-modules depends on multilib/gcc-multilib (6 extra (make)deps to pull : binutils-multilib gcc-libs-multilib gcc-ada-multilib lib32-glibc gcc-multilib lib32-gcc-libs) community/virtualbox-guest-modules depends on multilib/lib32-glibc (6 extra (make)deps to pull : gcc-multilib binutils-multilib gcc-libs-multilib gcc-ada-multilib lib32-glibc lib32-gcc-libs) core/binutils depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/ca-certificates depends on extra/python2 (60 extra (make)deps to pull) core/ca-certificates depends on extra/ruby (157 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (61 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (3 extra (make)deps to pull : dejagnu expect tcl) core/gcc depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-ada depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-fortran depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-libs depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/gcc-objc depends on extra/dejagnu (3 extra (make)deps to pull : expect dejagnu tcl) core/glib2 depends on extra/python2 (60 extra (make)deps to pull) core/groff depends on extra/ghostscript (157 extra (make)deps to pull) core/groff depends on extra/netpbm (60 extra (make)deps to pull) core/groff depends on extra/psutils (157 extra (make)deps to pull) core/kernel26 depends on extra/docbook-xsl (60 extra (make)deps to pull) core/kernel26 depends on extra/xmlto (60 extra (make)deps to pull) core/kernel26-docs depends on extra/docbook-xsl (60 extra (make)deps to pull) core/kernel26-docs depends on extra/xmlto (60 extra (make)deps to pull) core/kernel26-headers depends on extra/docbook-xsl (60 extra (make)deps to pull) core/kernel26-headers depends on extra/xmlto (60 extra (make)deps to pull) core/lilo depends on extra/sharutils (60 extra (make)deps to pull) core/links depends on extra/libpng (3 extra (make)deps to pull : dejagnu expect tcl) core/links depends on extra/libtiff (60 extra (make)deps to pull) core/links depends on extra/libxt (60 extra (make)deps to pull) core/pam depends on extra/docbook-xml (60 extra (make)deps to pull) core/pam depends on extra/docbook-xsl (60 extra (make)deps to pull) core/pam depends on extra/w3m (60 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (3 extra (make)deps to pull : dejagnu expect tcl) core/sqlite3-doc depends on extra/tcl (3 extra (make)deps to pull : dejagnu expect tcl) core/udev depends on extra/gobject-introspection (62 extra (make)deps to pull) core/udev depends on extra/gperf (3 extra (make)deps to pull : dejagnu expect tcl) core/udev depends on extra/libxslt (60 extra (make)deps to pull) core/udev-compat depends on extra/gobject-introspection (62 extra (make)deps to pull) core/udev-compat depends on extra/gperf (3 extra (make)deps to pull : dejagnu expect tcl) core/udev-compat depends on extra/libxslt (60 extra (make)deps to pull) extra/bigloo depends on community/jdk (2 extra (make)deps to pull : jre chrpath) extra/gnome-speech
Re: [arch-dev-public] MySQL 5.5
2011/2/4 Andrea Scarpino and...@archlinux.org: On Friday 04 February 2011 16:41:06 Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. Yes, I'd like to wait until 5.5.9, but I understand that we don't know when MySQL devs will release it. I just added two patches to our MySQL in [testing], I didn't rebuild it so you can add something else or write a better post_install message. :) I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams Thank you. If you take the responsability I vote +1 for the move and I'll try to be present as much as I can (will be hard). Another note Angel: maybe in the announcement you should write that example, archive, blackhole and federated engine are now disabled. -- Andrea Ok here is the draft: Title: MySQL 5.5 update Hi people, MySQL 5.5 (5.5.8) is on [extra] . This time we disabled Archive, Blackhole and Federated engine support. After doing -Syu please do: /etc/rc.d/mysqld restart mysql_upgrade Please feel free to add or remove words, or rephrase the announce. Have fun -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-dev-public] MySQL 5.5
2011/2/4 Ángel Velásquez an...@archlinux.org: 2011/2/4 Andrea Scarpino and...@archlinux.org: On Friday 04 February 2011 16:41:06 Ángel Velásquez wrote: Talking with Andrea on irc he told to us (Ionut, me and the rest who were present) that he would like to wait until 5.5.9 is out. AFAIK 5.5.9 haven't setted a release day yet, so can we move this and then wait for the 5.5.9?, I think doing this rebuild and wait for 5.5.9 without know if it will be released on two months or so is too much, if somebody know when will be the release date please tell us and can we planify then, but now mysql rebuild is stucked on [testing]. Yes, I'd like to wait until 5.5.9, but I understand that we don't know when MySQL devs will release it. I just added two patches to our MySQL in [testing], I didn't rebuild it so you can add something else or write a better post_install message. :) I vote for move this to [extra] I can take the responsability if it's needed to check bugs of mysql package until Andrea is back from exams Thank you. If you take the responsability I vote +1 for the move and I'll try to be present as much as I can (will be hard). Another note Angel: maybe in the announcement you should write that example, archive, blackhole and federated engine are now disabled. -- Andrea Ok here is the draft: Title: MySQL 5.5 update Hi people, MySQL 5.5 (5.5.8) is on [extra] . This time we disabled Archive, Blackhole and Federated engine support. MySQL 5.5 is now in [extra]. This is a major version upgrade from the 5.1 editions previously in the repositories. Archive, Blackhole, and Federated engine support are no longer included in this package (ed: is there a why here? we should tell them if so). After doing -Syu please do: After upgrading the MySQL package and restarting the database, you will need to run `mysql_upgrade` to ensure your tables are up to date and compatible with MySQL 5.5. /etc/rc.d/mysqld restart mysql_upgrade Please feel free to add or remove words, or rephrase the announce. Have fun s/on/in/, a bit more full sentence-y, and attempting to provide people with the why and not just blind commands to run. -Dan
Re: [arch-dev-public] MySQL 5.5
New draft: MySQL 5.5 is now in [extra]. This is a major version upgrade from the 5.1 editions previously in the repositories. Archive, Blackhole, and Federated engine support are no longer included in this package, since is not used heavily. After upgrading the MySQL package and restarting the database, you will need to run `mysql_upgrade` to ensure your tables, views and store procedures are up to date and compatible with MySQL 5.5. End of draft: Btw, I think Andrea removed the support for Archive, Blackhole and Federated engine for the same reasons which removed partition tables (which I enabled back again) -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-dev-public] MySQL 5.5
2011/2/4 Ángel Velásquez an...@archlinux.org: New draft: MySQL 5.5 is now in [extra]. This is a major version upgrade from the 5.1 editions previously in the repositories. Archive, Blackhole, and Federated engine support are no longer included in this package, since is not used heavily. since they are not heavily used After upgrading the MySQL package and restarting the database, you will need to run `mysql_upgrade` to ensure your tables, views and store procedures are up to date stored procedures and compatible with MySQL 5.5. End of draft: Btw, I think Andrea removed the support for Archive, Blackhole and Federated engine for the same reasons which removed partition tables (which I enabled back again) -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-dev-public] MySQL 5.5
On Friday 04 February 2011 19:45:23 Ángel Velásquez wrote: New draft: MySQL 5.5 is now in [extra]. This is a major version upgrade from the 5.1 editions previously in the repositories. Archive, Blackhole, and Federated engine support are no longer included in this package, since is not used heavily. I would add: A backup of your databases before the upgrade is recommended. After upgrading the MySQL package and restarting the database, you will need to run `mysql_upgrade` to ensure your tables, views and store procedures are up to date and compatible with MySQL 5.5. End of draft: Btw, I think Andrea removed the support for Archive, Blackhole and Federated engine for the same reasons which removed partition tables (which I enabled back again) Yes, and you forgot the Examples engine too. -- Andrea
Re: [arch-dev-public] MySQL 5.5
MySQL 5.5 is now in [extra]. This is a major version upgrade from the 5.1 editions previously in the repositories. Archive, Blackhole, and Federated engine support are no longer included in this package, since they are not heavily used. After upgrading the MySQL package and restarting the database, you will need to run `mysql_upgrade` to ensure your tables, views and stored procedures are up to date and compatible with MySQL 5.5. End of draft I ate that 'd' from Stored, thanks Dan and Andrea, for the corrections, I will be doing the announcement and the move tomorrow morning at 11:00 am ART Good luck with your studies Andrea (in bocca al lupo). -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-dev-public] MySQL 5.5
On Friday 04 February 2011 19:55:29 Ángel Velásquez wrote: I ate that 'd' from Stored, thanks Dan and Andrea, for the corrections, I will be doing the announcement and the move tomorrow morning at 11:00 am ART Then can I push mysql -8 on [testing] now with those 2 patches? Good luck with your studies Andrea (in bocca al lupo). Crepi! :) -- Andrea
[arch-dev-public] [signoff] coreutils-8.10-1
Upstream update. Signoff both, Allan NEWS * Noteworthy changes in release 8.10 (2011-02-04) [stable] ** Bug fixes du would abort with a failed assertion when two conditions are met: part of the hierarchy being traversed is moved to a higher level in the directory tree, and there is at least one more command line directory argument following the one containing the moved sub-tree. [bug introduced in coreutils-5.1.0] join --header now skips the ordering check for the first line even if the other file is empty. [bug introduced in coreutils-8.5] rm -f no longer fails for EINVAL or EILSEQ on file systems that reject file names invalid for that file system. uniq -f NUM no longer tries to process fields after end of line. [bug introduced in coreutils-7.0] ** New features cp now copies sparse files efficiently on file systems with FIEMAP support (ext4, btrfs, xfs, ocfs2). Before, it had to read 220 bytes when copying a 1MiB sparse file. Now, it copies bytes only for the non-sparse sections of a file. Similarly, to induce a hole in the output file, it had to detect a long sequence of zero bytes. Now, it knows precisely where each hole in an input file is, and can reproduce them efficiently in the output file. mv also benefits when it resorts to copying, e.g., between file systems. join now supports -o 'auto' which will automatically infer the output format from the first line in each file, to ensure the same number of fields are output for each line. ** Changes in behavior join no longer reports disorder when one of the files is empty. This allows one to use join as a field extractor like: join -a1 -o 1.3,1.1 - /dev/null
Re: [arch-dev-public] Adding multi arch, pkgver and/or pkgrel support in repo scripts
On Fri, Feb 4, 2011 at 1:49 AM, Pierre Schmitz pie...@archlinux.de wrote: On Thu, 3 Feb 2011 17:33:10 -0500, Eric Bélanger wrote: On Thu, Feb 3, 2011 at 6:23 AM, Pierre Schmitz pie...@archlinux.de wrote: 2) check_splitpkgs: get correct arch for svnnames Feel free to send me you ideas or some rough patches for a review. I got rid of that function. It seemed to be used to make sure split packages all have the same pkgver and pkgrel which is not longer relevant. I suppose it could be readded later on with some of my changes in it. So far, I'm trying to get the correct logic so there's some code duplication that might be moved to a function eventually. This function should not be removed but improved; e.g. a check if missing if a split package was removed and then automatically remove the split package from the repo. This function ensures that the repo contains the same as abs/svn. Sure. Once the logic is done, we can add and improve sanity/integrity checks. But: I don't like supporting different pkgver or pkgrel for split packages. Imho this is a feature of makepkg that has issues by design: * Source packages with the same file name no longer point to the same packages I haven't thought about the sourceballs script yet but there might be a way to tell it to update the sourceballs. Also, the reason we have these sourceballs is to comply with licenses. As long as the upstream sources are there, it shouldn't be a major problem if the PKGBUILD inside them is a little bit out-of-date. So it shouldn't be a stopper IMO. * The repos subdir in svn (might) no longer contains the PKGBUILD that a package was built with I don't see why or how this would happen. The trunk gets copied to the repos subdir with archrelease. We can no longer guarantee that a package in the repo was built with the PKGBUILD in the svn/repos dir or abs. Or in short: you cannot use abs to rebuild the repo. * Same issue with ABS which is no longer in sync with the actual binary packages I believe that ABS use svn to gets its data. As I said above, it shouldn't be affected. It sure is. What you propose is just being more relaxed on integrity and literally decouple the binary repos from svn. I think I understand what you mean now. So basically, if I have a split PKGBUILD with multi arch/pkgver/pkgrel and I do a pkgrel bump on the 'any' arch package only, then there will be a mismatch between the PKGBUILD in repos/extra-i686 and the one in repos/extra-any (and similar for extra-x86_64.). Is this the cause of the svn and binary repos decoupling you mentionned and because of that abs won't be able to work? If so, we could make sure that repos/$repo-any is in sync with the $repo-i686 and $repo-x86_64 directory. For example, if I update the 'any' package of a multi-arch split PKGBUILD in extra, the archrelease would run on extra-any and will run on extra-i686 and extra-x86_64 if they exist already. If I update the i686/x86_64 package, then archrelease is ran on i686/x86_64 and on extra-any if it exist already. I believe that would keep the repos and svn coupled. As far as abs goes, for the x86_64 abs tree it would just grab the content of repos/$repo-x86_64. If that directory is missing it would check for repos/$repo-any and add it (so that 'any' arch only PKGBUILD would be in tree). Feel free to let me know if you think it wouldn't work or would over-complicate things. This is not a minor straight forward change and should be done right. In fact I already had some ideas about this. I could send a more detailed mail if wanted. In short it repos like this: * Use svn just for trunk (or other branches) but no longer try to tag what is actually in the repos. Means removing the repos subdir completely. That would make it difficult to quickly know what PKGBUILD was used to build the packags in the repos as trunk only contains the latest version of the PKGBUILD. With the repos directory, it's easy and fast to know what package version is in extra, whihc one for testing and what are latest chenges in trunk. Of course, we can use svn log or cgit but how dbscripts will be able to do this? Unless we don't check anymore the svn against the packages in the repos, I can't see how it could be done. Wouldn't that decouple the svn from the repos completely? * Instead switch to a pure package based approach. dbscripts will only know about single packages. (would still need an integrity check to search for removed split packages) That might simplyfy things. So it might be worthwhile to switch to this proposed setup instead of my above suggestion above to modify the current one. I'm not decided yet. * Improve makepkg to create source packages with every build. Should be like $pkgbase-$pkgver-$pkgrel-$arch.src.tar.xz I suppose that would be enabled with a switch. And that also you're talking about makepkg --source and not makepkg --allsource otherwise we'll have disk space and bandwith issues. *
Re: [arch-dev-public] [signoff] coreutils-8.10-1
Le 4 février 2011 18:18:09, Allan McRae a écrit : Upstream update. Signoff both, Allan NEWS * Noteworthy changes in release 8.10 (2011-02-04) [stable] ** Bug fixes du would abort with a failed assertion when two conditions are met: part of the hierarchy being traversed is moved to a higher level in the directory tree, and there is at least one more command line directory argument following the one containing the moved sub-tree. [bug introduced in coreutils-5.1.0] join --header now skips the ordering check for the first line even if the other file is empty. [bug introduced in coreutils-8.5] rm -f no longer fails for EINVAL or EILSEQ on file systems that reject file names invalid for that file system. uniq -f NUM no longer tries to process fields after end of line. [bug introduced in coreutils-7.0] ** New features cp now copies sparse files efficiently on file systems with FIEMAP support (ext4, btrfs, xfs, ocfs2). Before, it had to read 220 bytes when copying a 1MiB sparse file. Now, it copies bytes only for the non-sparse sections of a file. Similarly, to induce a hole in the output file, it had to detect a long sequence of zero bytes. Now, it knows precisely where each hole in an input file is, and can reproduce them efficiently in the output file. mv also benefits when it resorts to copying, e.g., between file systems. join now supports -o 'auto' which will automatically infer the output format from the first line in each file, to ensure the same number of fields are output for each line. ** Changes in behavior join no longer reports disorder when one of the files is empty. This allows one to use join as a field extractor like: join -a1 -o 1.3,1.1 - /dev/null Signoff x86_64 Stéphane
Re: [arch-dev-public] MySQL 5.5
On Fri, 4 Feb 2011 18:22:08 -0200, Ángel Velásquez wrote: 2011/2/4 Dan McGee dpmc...@gmail.com: 2011/2/4 Ángel Velásquez an...@archlinux.org: As Dan's pointed just need a pacman -Syu mysql-upgrade /etc/rc.d/mysql restart , I've tried on two machines on production, and my workstation for weeks and it's working just fine, Maybe we can write a news about it (because some people usersread .install messages :P) Don't you want to run upgrade after restart? pacman -Syu /etc/rc.d/mysqld restart mysql-upgrade I don't think it's that easy as the restart could/will fail. You also need to adjust the my.cnf. I had some options in there that are no longer valid. -- Pierre Schmitz, https://users.archlinux.de/~pierre
