Re: [arch-dev-public] Maintaining consolekit support in community
On Fri, Oct 19, 2012 at 02:47:24PM +0200, Lukas Jirkovsky wrote: > On 19 October 2012 14:41, Thomas Bächler wrote: > > > > As long as all bug reports for non-logind systems go straight to Lukas > > (and whoever else maintains this), I don't care. If we don't have those > > packages in community, they'll be in a third-party repository - and I > > prefer having them in community in this case. > > Well, I can keep these packages in AUR as Andrea suggested in the > first post, but given that according to package statistics [0] there > are still lots of systems not using systemd I think having them in > community is preferable. > > [0] https://www.archlinux.de/?page=PackageStatistics This isn't accurate at all. Package stats is purely aggregate. There is no such thing as tracking of users or machines, so anyone who's reported and uninstalled initscripts since, and then reported again isn't going to have the "desired" effect. Sadly, in its current state, there's very little stats in package stats. d
[arch-dev-public] Integrity Check x86_64: core, extra, community, multilib 19-10-2012
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 Duplicate PKGBUILDs - /srv/abs/rsync/x86_64/community/python-pymongo vs. /srv/abs/rsync/x86_64/community/python2-pymongo /srv/abs/rsync/x86_64/extra/nouveau-dri vs. /srv/abs/rsync/x86_64/extra/mesa /srv/abs/rsync/x86_64/multilib/lib32-nouveau-dri vs. /srv/abs/rsync/x86_64/multilib/lib32-mesa Missing Makedepends - community/alex --> 'haskell-quickcheck=2.5-2' community/gtk2hs-buildtools --> 'happy=1.18.9-6' community/haddock --> 'happy=1.18.9-6' community/sbaz --> 'tomcat' community/sysprof --> 'kernel26-headers' Repo Hierarchy for Dependencies - community/playonlinux depends on multilib/wine (88 extra (make)deps to pull) core/grub-common depends on extra/freetype2 (0 extra (make)deps to pull) core/grub-common depends on extra/fuse (198 extra (make)deps to pull) core/grub-efi-i386 depends on extra/dosfstools (0 extra (make)deps to pull) core/grub-efi-i386 depends on extra/efibootmgr (0 extra (make)deps to pull) core/grub-efi-x86_64 depends on extra/dosfstools (0 extra (make)deps to pull) core/grub-efi-x86_64 depends on extra/efibootmgr (0 extra (make)deps to pull) extra/archboot depends on community/arch-wiki-lite (13 extra (make)deps to pull) extra/archboot depends on community/arch-wiki-lite (13 extra (make)deps to pull) extra/archboot depends on community/chntpw (11 extra (make)deps to pull) extra/archboot depends on community/cpupower (12 extra (make)deps to pull) extra/archboot depends on community/haveged (0 extra (make)deps to pull) extra/archboot depends on community/squashfs-tools (0 extra (make)deps to pull) extra/archboot depends on community/systemd-arch-units (11 extra (make)deps to pull) extra/archboot depends on community/usb_modeswitch (0 extra (make)deps to pull) extra/archboot depends on community/wvdial (14 extra (make)deps to pull) extra/archboot depends on community/xl2tpd (0 extra (make)deps to pull) extra/archiso depends on community/squashfs-tools (0 extra (make)deps to pull) extra/audacity depends on community/ffmpeg-compat (15 extra (make)deps to pull) extra/gnucash depends on community/aqbanking (13 extra (make)deps to pull) extra/gnucash depends on community/libdbi-drivers (13 extra (make)deps to pull) extra/mod_perl depends on community/perl-linux-pid (11 extra (make)deps to pull) extra/msmtp depends on community/gsasl (11 extra (make)deps to pull) extra/python2-pygame depends on community/portmidi (15 extra (make)deps to pull) extra/ruby depends on community/libyaml (0 extra (make)deps to pull) extra/wireshark-cli depends on community/portaudio (15 extra (make)deps to pull) extra/zeitgeist depends on community/xapian-core (11 extra (make)deps to pull) Repo Hierarchy for Makedepends community/virtualbox depends on multilib/dev86 (6 extra (make)deps to pull : lib32-glibc gcc-multilib gcc-libs-multilib binutils-multilib gcc-ada-multilib lib32-gcc-libs) community/virtualbox depends on multilib/gcc-multilib (6 extra (make)deps to pull : gcc-libs-multilib binutils-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 gcc-libs-multilib binutils-multilib gcc-ada-multilib lib32-glibc lib32-gcc-libs) community/virtualbox-guest-source depends on multilib/dev86 (6 extra (make)deps to pull : lib32-glibc gcc-multilib gcc-libs-multilib binutils-multilib gcc-ada-multilib lib32-gcc-libs) community/virtualbox-guest-source depends on multilib/gcc-multilib (6 extra (make)deps to pull : gcc-libs-multilib binutils-multilib gcc-ada-multilib lib32-glibc gcc-multilib lib32-gcc-libs) community/virtualbox-guest-source depends on multilib/lib32-glibc (6 extra (make)deps to pull : gcc-multilib gcc-libs-multilib binutils-multilib gcc-ada-multilib lib32-glibc lib32-gcc-libs) community/virtualbox-guest-utils depends on multilib/dev86 (6 extra (make)deps to pull : lib32-glibc gcc-multilib gcc-libs-multilib binutils-multilib gcc-ada-multilib lib32-gcc-libs) community/virtualbox-guest-utils depends on multilib/gcc-multilib (6 extra (make)deps to pull : gcc-libs-multilib binutils-multilib gcc-ada-multilib lib32-glibc gcc-multilib lib32-gcc-libs) community/virtualbox-guest-utils depends on multilib/lib32-glibc (6 extra (make)deps to pull : gcc-multilib gcc-libs-multilib binutils-mul
[arch-dev-public] Integrity Check i686: core, extra, community 19-10-2012
= 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/i686/community/python-pymongo vs. /srv/abs/rsync/i686/community/python2-pymongo /srv/abs/rsync/i686/extra/nouveau-dri vs. /srv/abs/rsync/i686/extra/mesa Missing Makedepends - community/alex --> 'haskell-quickcheck=2.5-2' community/gtk2hs-buildtools --> 'happy=1.18.9-6' community/haddock --> 'happy=1.18.9-6' community/sbaz --> 'tomcat' community/sysprof --> 'kernel26-headers' Repo Hierarchy for Dependencies - core/grub-common depends on extra/freetype2 (0 extra (make)deps to pull) core/grub-common depends on extra/fuse (198 extra (make)deps to pull) core/grub-efi-i386 depends on extra/dosfstools (0 extra (make)deps to pull) core/grub-efi-i386 depends on extra/efibootmgr (0 extra (make)deps to pull) core/grub-efi-x86_64 depends on extra/dosfstools (0 extra (make)deps to pull) core/grub-efi-x86_64 depends on extra/efibootmgr (0 extra (make)deps to pull) extra/archboot depends on community/arch-wiki-lite (13 extra (make)deps to pull) extra/archboot depends on community/arch-wiki-lite (13 extra (make)deps to pull) extra/archboot depends on community/chntpw (11 extra (make)deps to pull) extra/archboot depends on community/cpupower (12 extra (make)deps to pull) extra/archboot depends on community/haveged (0 extra (make)deps to pull) extra/archboot depends on community/squashfs-tools (0 extra (make)deps to pull) extra/archboot depends on community/systemd-arch-units (11 extra (make)deps to pull) extra/archboot depends on community/usb_modeswitch (0 extra (make)deps to pull) extra/archboot depends on community/wvdial (14 extra (make)deps to pull) extra/archboot depends on community/xl2tpd (0 extra (make)deps to pull) extra/archiso depends on community/squashfs-tools (0 extra (make)deps to pull) extra/audacity depends on community/ffmpeg-compat (22 extra (make)deps to pull) extra/gnucash depends on community/aqbanking (13 extra (make)deps to pull) extra/gnucash depends on community/libdbi-drivers (13 extra (make)deps to pull) extra/mod_perl depends on community/perl-linux-pid (11 extra (make)deps to pull) extra/msmtp depends on community/gsasl (11 extra (make)deps to pull) extra/python2-pygame depends on community/portmidi (22 extra (make)deps to pull) extra/ruby depends on community/libyaml (0 extra (make)deps to pull) extra/wireshark-cli depends on community/portaudio (22 extra (make)deps to pull) extra/zeitgeist depends on community/xapian-core (11 extra (make)deps to pull) Repo Hierarchy for Makedepends core/ca-certificates depends on extra/python2 (198 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (199 extra (make)deps to pull) core/dbus-core depends on extra/libx11 (198 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/filesystem depends on community/asciidoc (198 extra (make)deps to pull) core/glib2 depends on extra/python2 (198 extra (make)deps to pull) core/groff depends on extra/ghostscript (198 extra (make)deps to pull) core/groff depends on extra/netpbm (198 extra (make)deps to pull) core/groff depends on extra/psutils (198 extra (make)deps to pull) core/grub-bios depends on extra/autogen (199 extra (make)deps to pull) core/grub-bios depends on extra/bdf-unifont (202 extra (make)deps to pull) core/grub-bios depends on extra/fuse (198 extra (make)deps to pull) core/grub-bios depends on extra/help2man (199 extra (make)deps to pull) core/grub-bios depends on extra/python (198 extra (make)deps to pull) core/grub-bios depends on extra/ttf-dejavu (198 extra (make)deps to pull) core/grub-common depends on extra/autogen (199 extra (make)deps to pull) core/grub-common depends on extra/bdf-unifont (202 extra (make)deps to pull) core/grub-common depends on extra/fuse (198 extra (make)deps to pull) core/grub-common depends on extra/help2man (199 extra (make)deps to pull) core/grub-common depends on extra/python (198 extra (make)deps to pull) core/grub-common depends on extra/ttf-dejavu (198 extra (make)deps to pull) core/grub-efi-i386 depends on extra/autogen (199 extra (make)deps to pull) core/grub-efi-i386 depends on extra/bdf-unifont (202 extra (make)deps to pull) core/grub-efi-i386 depends on extra/fuse (198 extra (make)deps to pull) core/grub-efi-i386 depends on extra/help2man (199 extra (make)deps to pull) core/grub-efi-i386 depends on extra/python (198 extra (make)deps to pull) core/grub-efi-i386 depends on extra/ttf-dejavu (198 extra (make)deps to pull) core/grub-ef
Re: [arch-dev-public] Maintaining consolekit support in community
Please don't. Consolekit is not maintained upstream anymore and should get killed with fire. null
Re: [arch-dev-public] Maintaining consolekit support in community
On 19 October 2012 18:17, Lukas Jirkovsky wrote: > Hello, > I'd like to maintain some basic support support for consolekit in > [community], more specifically the polkit-consolekit, > kdebase-workspace-consolekit packages and eventually consolekit > package itself as long as possible, if you're not against it. > > I'm running kde (networkmanager) without systemd without problems on > my laptop with these packages. > > Lukas I'll help out with this for as long as I am able to, i.e. until I "move" to systemd. -- GPG/PGP ID: C0711BF1
Re: [arch-dev-public] (re-)adopt your python packages
Am 19.10.2012 15:52, schrieb Stéphane Gaudreault: > Le 2012-10-19 09:11, Dan McGee a écrit : >> Just a friendly reminder for those of you that rebuilt your python >> packages recently for the 2/3 naming convention: if you changed the >> 'pkgbase' value in the PKGBUILD, your package is probably listed as an >> orphan in archweb. See the below link for a list of those that need >> adopting: >> >> https://www.archlinux.org/packages/?q=python&maintainer=orphan&limit=all&sort=-last_update >> >> >> Thanks! >> -Dan > > Hi Dan, > > Do you think it would be a good (and feasible) ideaif the person who > upload a package for the first timewas automatically flagged as > maintainer on archweb? Feasible: Sure - first packager -> maintainer. Seems easy. Does it make sense? No idea. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] (re-)adopt your python packages
On Fri, Oct 19, 2012 at 8:52 AM, Stéphane Gaudreault wrote: > Le 2012-10-19 09:11, Dan McGee a écrit : > >> Just a friendly reminder for those of you that rebuilt your python >> packages recently for the 2/3 naming convention: if you changed the >> 'pkgbase' value in the PKGBUILD, your package is probably listed as an >> orphan in archweb. See the below link for a list of those that need >> adopting: >> >> >> https://www.archlinux.org/packages/?q=python&maintainer=orphan&limit=all&sort=-last_update >> >> Thanks! >> -Dan > > > Hi Dan, > > Do you think it would be a good (and feasible) ideaif the person who upload > a package for the first timewas automatically flagged as maintainer on > archweb? It would be possible to use the packager for this purpose, but I'm not so sure it would be a great idea to do this automatically. It is a harder question than it seems to determine if a package is being uploaded for the first time (nearly everything is "new" in testing, as opposed to a verbump in extra). What could be done is a simple report showing orphan packages with their last packager, so at a glance you could see if you should be adopting anything. -Dan
Re: [arch-dev-public] (re-)adopt your python packages
Le 2012-10-19 09:11, Dan McGee a écrit : Just a friendly reminder for those of you that rebuilt your python packages recently for the 2/3 naming convention: if you changed the 'pkgbase' value in the PKGBUILD, your package is probably listed as an orphan in archweb. See the below link for a list of those that need adopting: https://www.archlinux.org/packages/?q=python&maintainer=orphan&limit=all&sort=-last_update Thanks! -Dan Hi Dan, Do you think it would be a good (and feasible) ideaif the person who upload a package for the first timewas automatically flagged as maintainer on archweb? Regards, Stéphane
Re: [arch-dev-public] Maintaining consolekit support in community
Le 2012-10-19 08:42, Lukas Jirkovsky a écrit : On 19 October 2012 14:00, Stéphane Gaudreault wrote: The problem is that it will eventually become an unmantainable mess, not because of initscripts itself (Tom, Dave et al did a great job to keep it in a good state), but because most devs are not going to provide much support on the rc scripts in their packages once the switch to systemd will be completed. Also new packages will probably not include any rc scripts in a short future. Stéphane I know that at some point of time it will become unmaintainable. But I believe it should be possible to support initscripts for next few months without any larger problems. As for the rc scripts – these are low maintenance, so keeping them is not a problem. I'm sure I will have to switch to systemd on all my systems eventually, but I don't give up that easily ;-) Certainly Lukas intends to create and maintain an initscripts-arch-rc.d package similar to systemd-arch-units. He would surely not expect every packager to duplicate their work for two init systems, when most of us agree to deprecate one and move towards the other. Right Lukas? Sure. If the package maintainer decides to drop rc srcipt from the package, I can keep it in such package. As the rc scripts doesn't need to be changed often I think this isn't a big problem, unless some of the applications starts requiring systemd for their services. Lukas Ok, if I can give my rc scripts to you, then I am happy :) Stéphane
[arch-dev-public] (re-)adopt your python packages
Just a friendly reminder for those of you that rebuilt your python packages recently for the 2/3 naming convention: if you changed the 'pkgbase' value in the PKGBUILD, your package is probably listed as an orphan in archweb. See the below link for a list of those that need adopting: https://www.archlinux.org/packages/?q=python&maintainer=orphan&limit=all&sort=-last_update Thanks! -Dan
Re: [arch-dev-public] Maintaining consolekit support in community
On 19 October 2012 14:41, Thomas Bächler wrote: > > As long as all bug reports for non-logind systems go straight to Lukas > (and whoever else maintains this), I don't care. If we don't have those > packages in community, they'll be in a third-party repository - and I > prefer having them in community in this case. Well, I can keep these packages in AUR as Andrea suggested in the first post, but given that according to package statistics [0] there are still lots of systems not using systemd I think having them in community is preferable. [0] https://www.archlinux.de/?page=PackageStatistics
Re: [arch-dev-public] Maintaining consolekit support in community
On 19 October 2012 14:00, Stéphane Gaudreault wrote: > > The problem is that it will eventually become an unmantainable mess, not > because of initscripts itself (Tom, Dave et al did a great job to keep it in > a good state), but because most devs are not going to provide much support > on the rc scripts in their packages once the switch to systemd will be > completed. Also new packages will probably not include any rc scripts in a > short future. > > Stéphane I know that at some point of time it will become unmaintainable. But I believe it should be possible to support initscripts for next few months without any larger problems. As for the rc scripts – these are low maintenance, so keeping them is not a problem. I'm sure I will have to switch to systemd on all my systems eventually, but I don't give up that easily ;-) > Certainly Lukas intends to create and maintain an initscripts-arch-rc.d > package similar to systemd-arch-units. He would surely not expect every > packager to duplicate their work for two init systems, when most of us > agree to deprecate one and move towards the other. Right Lukas? Sure. If the package maintainer decides to drop rc srcipt from the package, I can keep it in such package. As the rc scripts doesn't need to be changed often I think this isn't a big problem, unless some of the applications starts requiring systemd for their services. Lukas
Re: [arch-dev-public] Maintaining consolekit support in community
Am 19.10.2012 12:19, schrieb Andrea Scarpino: > On Friday 19 October 2012 12:17:06 Lukas Jirkovsky wrote: >> Hello, >> I'd like to maintain some basic support support for consolekit in >> [community], more specifically the polkit-consolekit, >> kdebase-workspace-consolekit packages and eventually consolekit >> package itself as long as possible, if you're not against it. >> >> I'm running kde (networkmanager) without systemd without problems on >> my laptop with these packages. > > Please don't. We'll never drop initscripts this way. > Use AUR instead. As long as all bug reports for non-logind systems go straight to Lukas (and whoever else maintains this), I don't care. If we don't have those packages in community, they'll be in a third-party repository - and I prefer having them in community in this case. Regarding initscripts: Once Tom stops taking care of them, either someone else will or they will be dropped. It doesn't concern me either way. My only requirements are 1) Lukas takes care of the bugs. 2) It doesn't cause problems for those that don't use these packages. 3) It stays in community and doesn't touch core or extra. It's a principle I claimed to follow in all those lengthy systemd discussions: If someone wants to do this extra work, let them. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Maintaining consolekit support in community
[2012-10-19 08:00:36 -0400] Stéphane Gaudreault: > most devs are not going to > provide much support on the rc scripts in their packages once the > switch to systemd will be completed. Certainly Lukas intends to create and maintain an initscripts-arch-rc.d package similar to systemd-arch-units. He would surely not expect every packager to duplicate their work for two init systems, when most of us agree to deprecate one and move towards the other. Right Lukas? -- Gaetan
Re: [arch-dev-public] Maintaining consolekit support in community
Le 2012-10-19 06:28, Lukas Jirkovsky a écrit : On 19 October 2012 12:19, Andrea Scarpino wrote: Please don't. We'll never drop initscripts this way. Use AUR instead. -- Andrea Arch Linux Developer Actually, what would be the problem of me maintaining initscripts in community too, if that time comes? The problem is that it will eventually become an unmantainable mess, not because of initscripts itself (Tom, Dave et al did a great job to keep it in a good state), but because most devs are not going to provide much support on the rc scripts in their packages once the switch to systemd will be completed. Also new packages will probably not include any rc scripts in a short future. Stéphane
Re: [arch-dev-public] Maintaining consolekit support in community
On 19 October 2012 12:46, Allan McRae wrote: > On 19/10/12 20:28, Lukas Jirkovsky wrote: >> On 19 October 2012 12:19, Andrea Scarpino wrote: >>> >>> Please don't. We'll never drop initscripts this way. >>> Use AUR instead. >>> >>> -- >>> Andrea >>> Arch Linux Developer >> >> Actually, what would be the problem of me maintaining initscripts in >> community too, if that time comes? I don't plan to switch to systemd >> anytime soon. I don't see any problem dropping the initscripts & >> consolekit packages to AUR when no one (including me) would be willing >> to maintain them. >> > > So "maintaining" initscript would me actually adjusting/fixing them as > needed or just putting a package there? I'd probably do only the bugfixing – I don't think there's any new functionality needed. > Because there has been repeated > calls for actually contributors towards initscripts without any > response. And if you are not going to do actual development of > initscripts, I will have to object on the basis that the software is > unmaintained upstream. > > Allan > It's possible that I missed some of this calls for contributors, but I already presented my will to help. I was told that mostly the testing is needed, and, well, initscripts works for me without any problems, so there are no bug reports from the in this regard. But I don't see any problem in diving into bugtracker and trying to fix some of the current issues too. Lukas
Re: [arch-dev-public] Maintaining consolekit support in community
On 19/10/12 20:28, Lukas Jirkovsky wrote: > On 19 October 2012 12:19, Andrea Scarpino wrote: >> >> Please don't. We'll never drop initscripts this way. >> Use AUR instead. >> >> -- >> Andrea >> Arch Linux Developer > > Actually, what would be the problem of me maintaining initscripts in > community too, if that time comes? I don't plan to switch to systemd > anytime soon. I don't see any problem dropping the initscripts & > consolekit packages to AUR when no one (including me) would be willing > to maintain them. > So "maintaining" initscript would me actually adjusting/fixing them as needed or just putting a package there? Because there has been repeated calls for actually contributors towards initscripts without any response. And if you are not going to do actual development of initscripts, I will have to object on the basis that the software is unmaintained upstream. Allan
Re: [arch-dev-public] Maintaining consolekit support in community
On Friday 19 October 2012 12:28:00 Lukas Jirkovsky wrote: > Actually, what would be the problem of me maintaining initscripts in > community too, if that time comes? I don't plan to switch to systemd > anytime soon. I don't see any problem dropping the initscripts & > consolekit packages to AUR when no one (including me) would be willing > to maintain them. > We are already having issues in maintaining two init systems. (e.g. we don't know which one users are using, see FS#32028). https://bugs.archlinux.org/task/32028 -- Andrea Arch Linux Developer
Re: [arch-dev-public] Maintaining consolekit support in community
On 19 October 2012 12:19, Andrea Scarpino wrote: > > Please don't. We'll never drop initscripts this way. > Use AUR instead. > > -- > Andrea > Arch Linux Developer Actually, what would be the problem of me maintaining initscripts in community too, if that time comes? I don't plan to switch to systemd anytime soon. I don't see any problem dropping the initscripts & consolekit packages to AUR when no one (including me) would be willing to maintain them. Lukas
Re: [arch-dev-public] Maintaining consolekit support in community
On 19 October 2012 12:19, Andrea Scarpino wrote: > On Friday 19 October 2012 12:17:06 Lukas Jirkovsky wrote: >> Hello, >> I'd like to maintain some basic support support for consolekit in >> [community], more specifically the polkit-consolekit, >> kdebase-workspace-consolekit packages and eventually consolekit >> package itself as long as possible, if you're not against it. >> >> I'm running kde (networkmanager) without systemd without problems on >> my laptop with these packages. > > Please don't. We'll never drop initscripts this way. > Use AUR instead. > > -- > Andrea > Arch Linux Developer OK
Re: [arch-dev-public] Maintaining consolekit support in community
On Friday 19 October 2012 12:17:06 Lukas Jirkovsky wrote: > Hello, > I'd like to maintain some basic support support for consolekit in > [community], more specifically the polkit-consolekit, > kdebase-workspace-consolekit packages and eventually consolekit > package itself as long as possible, if you're not against it. > > I'm running kde (networkmanager) without systemd without problems on > my laptop with these packages. Please don't. We'll never drop initscripts this way. Use AUR instead. -- Andrea Arch Linux Developer
[arch-dev-public] Maintaining consolekit support in community
Hello, I'd like to maintain some basic support support for consolekit in [community], more specifically the polkit-consolekit, kdebase-workspace-consolekit packages and eventually consolekit package itself as long as possible, if you're not against it. I'm running kde (networkmanager) without systemd without problems on my laptop with these packages. Lukas
Re: [arch-dev-public] GNOME 3.6 hits [testing]
On 10/19/2012 07:20 AM, Allan McRae wrote: > On 19/10/12 06:12, Jan Steffens wrote: >> libpangox has been split from pango and now resides in pangox-compat. This >> will >> require rebuilds to update dependencies. > > Is there a TODO list being generated for this? > > Allan > gtkglext gtkglextmm gtkmathview nvidia-utils gambas3-gb-gtk-opengl gliv i'll fix nvidia later today. -- Ionuț signature.asc Description: OpenPGP digital signature
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 290 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 6 fully signed off packages * 306 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (290 total) == * ibus-1.4.99.20120822-1 (i686) * ibus-1.4.99.20120822-1 (x86_64) * glib2-2.34.1-1 (i686) * glib2-2.34.1-1 (x86_64) * cantarell-fonts-0.0.10.1-1 (any) * gnome-backgrounds-3.6.0-1 (any) * gnome-common-3.6.0-1 (any) * gnome-icon-theme-3.6.0-1 (any) * gnome-icon-theme-symbolic-3.6.0-1 (any) * gnome-tweak-tool-3.6.1-1 (any) * gnome-user-docs-3.6.0-1 (any) * gnome-video-effects-0.4.0-2 (any) * gsettings-desktop-schemas-3.6.0-1 (any) * orca-3.6.1-1 (any) * pyatspi-2.6.0-2 (any) * yelp-tools-3.6.0-1 (any) * yelp-xsl-3.6.0-1 (any) * anjuta-3.6.1-1 (i686) * anjuta-extras-3.6.0-1 (i686) * at-spi2-atk-2.6.1-1 (i686) * at-spi2-core-2.6.1-1 (i686) * atk-2.6.0-1 (i686) * banshee-2.6.0-1 (i686) * baobab-3.6.2-1 (i686) * brasero-3.6.0-1 (i686) * cheese-3.6.1-1 (i686) * clutter-1.12.2-1 (i686) * clutter-gst-1.9.92-1 (i686) * clutter-gtk-1.4.0-1 (i686) * colord-0.1.23-1 (i686) * dconf-0.14.0-1 (i686) * devhelp-3.6.0-2 (i686) * empathy-3.6.0.2-1 (i686) * eog-3.6.1-1 (i686) * eog-plugins-3.6.1-1 (i686) * epiphany-3.6.1-1 (i686) * epiphany-extensions-3.6.0-1 (i686) * evince-3.6.0-1 (i686) * evolution-3.6.0-1 (i686) * evolution-data-server-3.6.1-1 (i686) * evolution-ews-3.6.0-1 (i686) * farstream-0.2.1-1 (i686) * file-roller-3.6.1.1-1 (i686) * folks-0.8.0-1 (i686) * gcalctool-6.6.1-1 (i686) * gcr-3.6.1-1 (i686) * gdk-pixbuf2-2.26.4-1 (i686) * gdl-3.6.0-1 (i686) * gdm-3.6.1-1 (i686) * gedit-3.6.1-1 (i686) * ghex-3.6.1-1 (i686) * gjs-1.34.0-1 (i686) * glade-3.14.1-1 (i686) * glib-networking-2.34.0-1 (i686) * glibmm-2.33.14-1 (i686) * gnome-bluetooth-3.6.0-2 (i686) * gnome-color-manager-3.6.0-1 (i686) * gnome-contacts-3.6.1-1 (i686) * gnome-control-center-3.6.1-1 (i686) * gnome-desktop-1:3.6.1-1 (i686) * gnome-dictionary-3.6.0-1 (i686) * gnome-disk-utility-3.6.1-1 (i686) * gnome-documents-3.6.0-1 (i686) * gnome-font-viewer-3.6.0-1 (i686) * gnome-games-3.6.1-1 (i686) * gnome-keyring-3.6.1-1 (i686) * gnome-menus-3.6.0-1 (i686) * gnome-nettool-3.2.0-1 (i686) * gnome-online-accounts-3.6.0-1 (i686) * gnome-panel-3.6.0-1 (i686) * gnome-phone-manager-0.68-3 (i686) * gnome-power-manager-3.6.0-1 (i686) * gnome-screensaver-3.6.1-1 (i686) * gnome-screenshot-3.6.0-1 (i686) * gnome-search-tool-3.6.0-1 (i686) * gnome-session-3.6.1-1 (i686) * gnome-settings-daemon-3.6.1-2 (i686) * gnome-shell-3.6.1-1 (i686) * gnome-system-log-3.6.0-1 (i686) * gnome-system-monitor-3.6.0-1 (i686) * gnome-terminal-3.6.0-1 (i686) * gnome-themes-standard-3.6.1-1 (i686) * gnome-user-share-3.0.4-1 (i686) * gobject-introspection-1.34.1.1-1 (i686) * grilo-0.2.2-1 (i686) * grilo-plugins-0.2.2-1 (i686) * gssdp-0.12.2.1-1 (i686) * gthumb-3.1.1-1 (i686) * gtk3-3.6.1-1 (i686) * gtkhtml4-4.6.0-1 (i686) * gtkmm3-3.5.13-1 (i686) * gtksourceview3-3.6.0-1 (i686) * gucharmap-3.6.0-1 (i686) * gupnp-0.18.4-1 (i686) * gvfs-1.14.0-1 (i686) * json-glib-0.15.2-1 (i686) * kdebase-workspace-4.9.2-5 (i686) * libcroco-0.6.7-1 (i686) * libgdata-0.13.2-1 (i686) * libgee-0.6.6-1 (i686) * libgnome-keyring-3.6.0-1 (i686) * libgnomekbd-3.6.0-1 (i686) * libgweather-3.6.0-1 (i686) * libnice-0.1.3-1 (i686) * libpeas-1.6.1-1 (i686) * librsvg-2.36.4-1 (i686) * libsoup-2.40.1-1 (i686) * libxklavier-5.3-1 (i686) * mousetweaks-3.6.0-1 (i686) * mutter-3.6.1-2 (i686) * nautilus-3.6.0-1 (i686) * nautilus-open-terminal-0.19-3 (i686) * nautilus-sendto-3.6.0-1 (i686) * networkmanager-0.9.6.0-5 (i686) * pango-1.32.1-1 (i686) * pidgin-2.10.6-2 (i686) * polkit-0.107-4 (i686) * pygobject-3.4.1.1-1 (i686) * rest-0.7.90-1 (i686) * rhythmbox-2.98-2 (i686) * seahorse-3.6.1-1 (i686) * slim-1.3.4-4 (i686) * sushi-3.6.0-1 (i686) * telepathy-farstream-0.6.0-1 (i686) * telepathy-gabble-0.17.1-1 (i686) * telepathy-glib-0.20.0-1 (i686) * telepathy-mission-control-5.14.0-1 (i686) * totem-3.6.0-1 (i686) * totem-plparser-3.4.3-1 (i686) * tracker-0.14.2-2 (i686) * udisks2-1.99.0-1 (i686) * vala-0.18.0-1 (i686) * vinagre-3.6.1-1 (i686) * vino-3.6.1-1 (i686) * vte3-0.34.1-1 (i686) * xfce4-session-4.10.0-6 (i686) * xorg-xdm-1.1.11-4 (i686) * yelp-3.6.0-1 (i686) * zenity-3.6.0-1 (i686) * anjuta-3.6.1-1 (x86_64) * anjuta-extras-3.6.0-1 (x86_64) * at-spi2-atk-2.6.1-1 (x86_64) * at-spi2-core-2.6.1-1 (x86_64) * atk-2.6.0-1 (x86_64) * banshee-2.6.0-1 (x86_64) * baobab-3.6.2-1 (x86_64) * brasero-3.6.0-1 (x86_64) * cheese-3.6.1-1 (x86_64) * clutter-1.12.2-1 (x86_64) * clutter-gst-1.9.92-1 (x86_64) * clutter-gtk-1.4.0-1 (x86_64) * colord-0.1.23-1 (x86_64) * dconf-0.14.0-1 (x86_64) * devhelp-3.
