Re: [gentoo-dev] Packages up for grabs due dang concentrating in gnome work
On Fri, Jun 08, 2012 at 03:06:52PM +0200, Pacho Ramos wrote: > app-admin/logrotate > > Feel free to get them I'll take this one if nobody else wants to maintain it. Thanks. pgpvqZPluCrrO.pgp Description: PGP signature
[gentoo-dev] app-misc/lirc needs some love
Hello Is anyone familiarized with lirc? Due all their opened bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=lirc&list_id=1087335 and, specially: https://bugs.gentoo.org/show_bug.cgi?id=160134 that is also affecting 0.9, all lirc versions in the tree are broken for a long time. Thanks! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribió: > On 06/08/2012 12:23 PM, Pacho Ramos wrote: > > El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: > >> On 06/08/2012 01:38 AM, Pacho Ramos wrote: > >>> El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: > On 06/07/2012 12:24 PM, Pacho Ramos wrote: > > El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: > >> On 06/07/2012 12:00 PM, Pacho Ramos wrote: > >>> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: > On Thu, 07 Jun 2012 20:43:54 +0200 > Pacho Ramos wrote: > >> I would prefer, as a workaround, allow reverse deps to RDEPEND on > >> glib:2.* instead. That way it would cover more cases when more than > >> two slots are available > > > > Well, per: > > http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b > > > > looks like "*" usage for SLOTs would be allowed :), or I am > > misinterpreting it? > > It's not a wildcard. > > >>> > >>> But it looks like a valid usage for cases like glib vs. > >>> dbus-glib/gobject-introspection I have exposed as example, and also > >>> allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, not > >>> sure about others I could be missing now...) > >> > >> The :* operator doesn't trigger any rebuilds though. Quoting the PMS > >> patch that you linked: > >> > >> * Indicates that any slot value is acceptable. In addition, for runtime > >> dependencies, indicates that the package will not break if the matched > >> package is uninstalled and replaced by a different matching package in > >> a > >> different slot. > > > > I mean, use it in conjunction with ":=", one for rebuild and other to > > indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to > > periodically update RDEPENDs or need to go back from :SLOT depends to > > old =category/package-version-* ways) > > > > Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue > > that arises with using only SLOTs for this) > > What you're talking about here is more similar to ABI_SLOT operator deps > than what was originally intended for SLOT operator deps. In other > words, anyone who is opposed to ABI_SLOT operator deps is likely to also > be opposed to your proposal. > >>> > >>> Oh :(, and what is the reason to want to prevent this behavior? Looks > >>> much simpler to me than needing to use ranges for dependencies or > >>> needing to create "compat" packages to hide the problem :| > >> > >> It's close enough to ABI_SLOT that it would make more sense just to use > >> ABI_SLOT because it's more flexible. > > > > In that case, I think it's clear we need ABI_SLOT ;) The problem is how > > to document it in a way people agree with including it for eapi5 :| > > We can just write a specification for this one feature, and ask the > Council to approve it. That would be nice, if you remember, I started with "elog/ecommand splitting solution" to try to get this long standing issue solved "soon" and, since looks like each eapi takes more than a year to complete, I would really prefer to see it included in eapi5, specially after seeing that this "ABI_SLOT" idea was suggested years ago but the issue stalled later multiple times signature.asc Description: This is a digitally signed message part
[gentoo-dev] Fwd: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 FYI, after talking to radhermit and hwoarang on #gentoo-dev, I masked these two versions. See my comments on https://bugs.gentoo.org/416081 for details. Michael Weber - Original Message Subject: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask Date: Sat, 9 Jun 2012 10:49:07 + (UTC) From: Michael Weber (xmw) Reply-To: gentoo-dev@lists.gentoo.org, x...@gentoo.org To: gentoo-comm...@lists.gentoo.org xmw 12/06/09 10:49:07 Modified: ChangeLog package.mask Log: Masking =sys-fs/mdadm-3.2.4 and =sys-fs/mdadm-3.2.5 for bug 416081 Revision ChangesPath 1.6651 profiles/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?rev=1.6651&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?rev=1.6651&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?r1=1.6650&r2=1.6651 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v retrieving revision 1.6650 retrieving revision 1.6651 diff -u -r1.6650 -r1.6651 - --- ChangeLog 8 Jun 2012 18:37:58 - 1.6650 +++ ChangeLog 9 Jun 2012 10:49:07 - 1.6651 @@ -1,11 +1,14 @@ # ChangeLog for profile directory # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 - -# $Header: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v 1.6650 2012/06/08 18:37:58 tove Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v 1.6651 2012/06/09 10:49:07 xmw Exp $ # # This ChangeLog should include records for all changes in profiles directory. # Only typo fixes which don't affect portage/repoman behaviour could be avoided # here. If in doubt put a record here! + 09 Jun 2012; Michael Weber package.mask: + Masking =sys-fs/mdadm-3.2.4 and =sys-fs/mdadm-3.2.5 for bug 416081 + 08 Jun 2012; Torsten Veller package.mask: Mask dev-perl/CPAN-Mini-Phalanx for removal (#420075) 1.13840 profiles/package.mask file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13840&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13840&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.13839&r2=1.13840 Index: package.mask === RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v retrieving revision 1.13839 retrieving revision 1.13840 diff -u -r1.13839 -r1.13840 - --- package.mask 8 Jun 2012 18:37:58 - 1.13839 +++ package.mask9 Jun 2012 10:49:07 - 1.13840 @@ -1,5 +1,5 @@ - -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13839 2012/06/08 18:37:58 tove Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13840 2012/06/09 10:49:07 xmw Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked. Please be extremely @@ -31,6 +31,17 @@ #--- END OF EXAMPLES --- +# Michael Weber (9 Jun 2012) +# The mentioned versions fail to assemble raid 0/1/5 devices. +# As reported in bug 416081 users end up with multiple raids +# all consiting of single drives. disk/by-uuid is preseved +# for single disks, so users end up with auto-mounted raids +# effectivly running on single disks. +# @base-system feel free to re-evaluate the severeness of this +# regression and drop the mask. Masked for now. +=sys-fs/mdadm-3.2.4 +=sys-fs/mdadm-3.2.5 + # Torsten Veller (08 Jun 2012) # Masked for removal (#420075) # The Phalanx Project is finished and no longer active - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/TKrIACgkQknrdDGLu8JBNKAD/Y80SjlzvUjG1nC0FTGoQSNGO 0VaypBDvIVqWzqXqmdcA+gLTkNgiYIW4fitSyyCXO55iP0uN/4qql44E31QIgzd/ =Af73 -END PGP SIGNATURE-
Re: [gentoo-dev] About forcing rebuilds of other packages issue
El sáb, 09-06-2012 a las 12:46 +0200, Pacho Ramos escribió: > El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribió: > > On 06/08/2012 12:23 PM, Pacho Ramos wrote: > > > El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió: > > >> On 06/08/2012 01:38 AM, Pacho Ramos wrote: > > >>> El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió: > > On 06/07/2012 12:24 PM, Pacho Ramos wrote: > > > El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió: > > >> On 06/07/2012 12:00 PM, Pacho Ramos wrote: > > >>> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió: > > On Thu, 07 Jun 2012 20:43:54 +0200 > > Pacho Ramos wrote: > > >> I would prefer, as a workaround, allow reverse deps to RDEPEND on > > >> glib:2.* instead. That way it would cover more cases when more > > >> than > > >> two slots are available > > > > > > Well, per: > > > http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b > > > > > > looks like "*" usage for SLOTs would be allowed :), or I am > > > misinterpreting it? > > > > It's not a wildcard. > > > > >>> > > >>> But it looks like a valid usage for cases like glib vs. > > >>> dbus-glib/gobject-introspection I have exposed as example, and also > > >>> allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, > > >>> not > > >>> sure about others I could be missing now...) > > >> > > >> The :* operator doesn't trigger any rebuilds though. Quoting the PMS > > >> patch that you linked: > > >> > > >> * Indicates that any slot value is acceptable. In addition, for > > >> runtime > > >> dependencies, indicates that the package will not break if the > > >> matched > > >> package is uninstalled and replaced by a different matching package > > >> in a > > >> different slot. > > > > > > I mean, use it in conjunction with ":=", one for rebuild and other to > > > indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to > > > periodically update RDEPENDs or need to go back from :SLOT depends to > > > old =category/package-version-* ways) > > > > > > Allowing that, we wouldn't need ABI_SLOT (at least to prevent this > > > issue > > > that arises with using only SLOTs for this) > > > > What you're talking about here is more similar to ABI_SLOT operator > > deps > > than what was originally intended for SLOT operator deps. In other > > words, anyone who is opposed to ABI_SLOT operator deps is likely to > > also > > be opposed to your proposal. > > >>> > > >>> Oh :(, and what is the reason to want to prevent this behavior? Looks > > >>> much simpler to me than needing to use ranges for dependencies or > > >>> needing to create "compat" packages to hide the problem :| > > >> > > >> It's close enough to ABI_SLOT that it would make more sense just to use > > >> ABI_SLOT because it's more flexible. > > > > > > In that case, I think it's clear we need ABI_SLOT ;) The problem is how > > > to document it in a way people agree with including it for eapi5 :| > > > > We can just write a specification for this one feature, and ask the > > Council to approve it. > > That would be nice, if you remember, I started with "elog/ecommand > splitting solution" to try to get this long standing issue solved "soon" > and, since looks like each eapi takes more than a year to complete, I > would really prefer to see it included in eapi5, specially after seeing > that this "ABI_SLOT" idea was suggested years ago but the issue stalled > later multiple times Also, taking into account that all affected packages should start migrating to eapi5 to really allow us to stop needing to use current "tricks", would be much better to start as soon as possible instead of waiting for another eapi cycle, that would delay "real solution" (I mean, new eapi used by all affected packages in the tree) even more months (or years) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Fri, 08 Jun 2012 12:31:55 -0700 Zac Medico wrote: > We can just write a specification for this one feature, and ask the > Council to approve it. The last feature someone did that way was REQUIRED_USE, and we all know how that turned out... What you *should* do is get an implementation, then try converting lots of ebuilds with and without being able to use ABI_SLOT. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/09/2012 05:15 AM, Ciaran McCreesh wrote: > On Fri, 08 Jun 2012 12:31:55 -0700 > Zac Medico wrote: >> We can just write a specification for this one feature, and ask the >> Council to approve it. > > The last feature someone did that way was REQUIRED_USE, and we all know > how that turned out... > > What you *should* do is get an implementation, then try converting lots > of ebuilds with and without being able to use ABI_SLOT. Okay, so let's create an ABI_SLOT operator specification, just for testing purposes. In order to keep things as simple as possible, let's make our model as close as possible to the existing SLOT operator model. Ebuilds that do not define ABI_SLOT will be considered to have an implicit ABI_SLOT value that is equal to their SLOT value. This way, ABI_SLOT operator deps will behave identically to SLOT operator deps when ABI_SLOT is undefined. A dependency atom will have optional SLOT and ABI_SLOT parts. Using the dbus-glib depedency on glib:2 as an example [1], the dbus-glib dependency will be expressed with an atom such as dev-libs/glib:2:= and the package manager will translate that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always used to distinguish SLOT deps, and ':=' is always used to distinguish ABI_SLOT deps. Is that syntax good? [1] http://archives.gentoo.org/gentoo-dev/msg_9f2d42da278f4815f2bfe57bfc5c2de5.xml -- Thanks, Zac
[gentoo-dev] gtk3 useflag and support of older toolkits
Bug #420433 lately introduced the discussion again if and when we should support older (deprecated) toolkit versions. As for the named bug it may make sense to support it, cause the gtk3 useflag would lead to different (reduced) functionality of that package. (but that shall not be the discussion here) Generally I think gtk3 useflags should be avoided and only be a workaround during migration to gtk+:3. Optimally gtk+:3 should always be forced when available and not leading to major issues. On the other hand... if gtk+:3 implementation is broken I would suggest to simply force gtk+:2 without any gtk3 useflag. So we have ONE working toolkit version. Introducing stuff like gtk3 useflag will let users think this is about choice, but it's actually not (gtk+:2 is not being developed any longer afais). Would it make sense to add a tracker for packages currently using gtk3 useflag, so this will not become a habit and only be a workaround? # quse -N gtk3 app-editors/emacs/emacs-24.1_rc.ebuild app-editors/emacs-vcs/emacs-vcs-24.1.-r1.ebuild app-emulation/virt-viewer/virt-viewer-0.4.2.ebuild app-emulation/virt-viewer/virt-viewer-0.5.2.ebuild app-emulation/virt-viewer/virt-viewer-0.5.3.ebuild app-i18n/fcitx/fcitx-4.2.1.ebuild app-i18n/fcitx/fcitx-4.2.4.ebuild app-i18n/fcitx-configtool/fcitx-configtool-0.4.1.ebuild app-i18n/fcitx-configtool/fcitx-configtool-0.4.4.ebuild app-i18n/ibus/ibus-1.4.1.ebuild app-i18n/ibus-unikey/ibus-unikey-0.6.1.ebuild app-i18n/uim/uim-1.7.1-r1.ebuild app-i18n/uim/uim-1.7.1.ebuild app-i18n/uim/uim-1.7.3.ebuild app-i18n/uim/uim-1.8.0.ebuild app-office/libreoffice/libreoffice-3.6..ebuild app-office/libreoffice/libreoffice--r2.ebuild gnome-base/librsvg/librsvg-2.34.1-r1.ebuild gnome-base/librsvg/librsvg-2.34.2.ebuild lxde-base/lxdm/lxdm-0.4.1-r1.ebuild lxde-base/lxdm/lxdm-0.4.1-r2.ebuild lxde-base/lxdm/lxdm-0.4.1-r4.ebuild lxde-base/lxdm/lxdm-0.4.1-r5.ebuild media-libs/libcanberra/libcanberra-0.28-r5.ebuild media-plugins/audacious-plugins/audacious-plugins-3.2.2-r1.ebuild media-plugins/audacious-plugins/audacious-plugins-3.2.3.ebuild media-sound/audacious/audacious-3.2.2-r1.ebuild media-sound/audacious/audacious-3.2.3.ebuild media-sound/mp3splt-gtk/mp3splt-gtk-0.7.0.930.ebuild media-sound/mp3splt-gtk/mp3splt-gtk-0.7.1.ebuild media-sound/mp3splt-gtk/mp3splt-gtk-0.7.2.ebuild net-dns/avahi/avahi-0.6.30-r1.ebuild net-dns/avahi/avahi-0.6.30-r3.ebuild net-libs/gtk-vnc/gtk-vnc-0.4.3-r1.ebuild net-libs/gtk-vnc/gtk-vnc-0.4.4.ebuild net-libs/gtk-vnc/gtk-vnc-0.5.0-r1.ebuild net-libs/gtk-vnc/gtk-vnc-0.5.0.ebuild net-misc/spice-gtk/spice-gtk-0.11.ebuild net-misc/spice-gtk/spice-gtk-0.12.ebuild net-misc/spice-gtk/spice-gtk-0.7.159.ebuild net-misc/spice-gtk/spice-gtk-0.8.ebuild net-p2p/eiskaltdcpp/eiskaltdcpp-2.2.6.ebuild net-p2p/eiskaltdcpp/eiskaltdcpp-2.2.7.ebuild net-p2p/eiskaltdcpp/eiskaltdcpp-.ebuild sci-mathematics/gretl/gretl-1.9.7.ebuild sci-mathematics/gretl/gretl-1.9.8.ebuild www-client/dwb/dwb-2012.02.01.ebuild www-client/dwb/dwb-2012.05.11.ebuild www-client/dwb/dwb-.ebuild www-client/opera/opera-11.64.1403.ebuild www-client/opera/opera-12.00.1448.ebuild www-client/opera/opera-12.00.1450.ebuild www-client/opera-next/opera-next-12.00.1440.ebuild www-client/opera-next/opera-next-12.00.1441.ebuild www-client/opera-next/opera-next-12.00.1445.ebuild www-client/opera-next/opera-next-12.00.1448.ebuild www-client/opera-next/opera-next-12.00.1450.ebuild www-client/uget/uget-1.8.0.ebuild www-client/uget/uget-.ebuild www-client/uzbl/uzbl-2011.07.17.ebuild www-client/uzbl/uzbl-2011.07.25.ebuild www-client/uzbl/uzbl-2011.10.01.ebuild www-client/uzbl/uzbl-2011.11.28.ebuild www-client/uzbl/uzbl-.ebuild x11-themes/light-themes/light-themes-0.1.8.29.ebuild x11-themes/light-themes/light-themes-0.1.8.32.ebuild x11-themes/light-themes/light-themes-0.1.9.1.ebuild
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sun, 2012-06-10 at 04:38 +0200, hasufell wrote: > Bug #420433 lately introduced the discussion again if and when we should > support older (deprecated) toolkit versions. > > As for the named bug it may make sense to support it, cause the gtk3 > useflag would lead to different (reduced) functionality of that package. > (but that shall not be the discussion here) > > Generally I think gtk3 useflags should be avoided and only be a > workaround during migration to gtk+:3. Optimally gtk+:3 should always be > forced when available and not leading to major issues. > On the other hand... if gtk+:3 implementation is broken I would suggest > to simply force gtk+:2 without any gtk3 useflag. So we have ONE working > toolkit version. > > Introducing stuff like gtk3 useflag will let users think this is about > choice, but it's actually not (gtk+:2 is not being developed any longer > afais). > > Would it make sense to add a tracker for packages currently using gtk3 > useflag, so this will not become a habit and only be a workaround? The Gnome team's recommendation is to avoid gtk3 or gtk2 USE flags. For libraries, if possible, try splitting gtk2 and gtk3 support into different slots (see net-libs/webkit-gtk for an example; the gtk2-based versions have -r2xx revision numbers and go in slot 2, while the gtk3-based versions have -r3xx revision numbers and go in slot 3). Unfortunately, for a few libraries, this splitting is difficult to do in a sane and maintainable manner, so then a gtk3 USE flag could be the least bad solution. For applications, just pick one version of gtk. If a particular version works better, use only that one (e.g. if building an application against gtk3 would result in reduced functionality or introduce crashes, or if upstream calls it experimental, you should probably stick with gtk2 for now). If the results of building against gtk2 or gtk2 are mostly equivalent, I suggest only building against gtk3, because gtk2 is basically legacy code that doesn't get much attention from gtk upstream. -Alexandre
