Re: [gentoo-dev] Project summaries - KDE team sumary
El dom, 10-05-2009 a las 20:54 +0300, Markos Chandras escribió: > We did quite good job in pushing Qt-4.5 packages really quick. We have a > stabilization process for 4.5.1 packages[1] as well. We maintain many qt4 I cannot see "[1]" link, seems missing in original mail I think that it's: http://bugs.gentoo.org/show_bug.cgi?id=266201 Best regards :-)
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
El jue, 14-05-2009 a las 03:32 +0300, Mart Raudsepp escribió: > Hello, > > I have had this project in my mind for a while, so it's about time to > get it out there, as to see if feedback finds it a good one - and if > that is so, if there are people who want to make it happen. > It is worded as a hypothetical project description for the purpose of > the text perhaps being a draft for the projects official description. So > in the following text instead of terms like "this project would be" I'm > purposely using terms like "this project is", as while writing it, it > got quickly very awkward writing "would be" and such all the time. > Please take it still as a proposal to be judged, commented, improved, > etc etc. And well, do that commenting and improving and volunteering ;) > > > Project maintainer-wanted > = > > Abstract: > There are currently quite some package requests (over 3000) languishing > on bugzilla waiting for a developer or team to get interested and > package it in the official gentoo-x86 portage tree. However in quite > some cases that might not happen for quite a while even with very > popular packages desired by users. The purpose of the maintainer-wanted > project is to get as many of such packages to the official tree as > possible as a stopgap solution. > > > > Details/implementation: > > The maintainer-wanted team is actively looking for popular packages in > bugzilla that have been waiting for packaging in the official > "gentoo-x86" tree for a while, and package and maintain as many of them > as the project teams manpower allows without sacrificing quality. > > To decide which libraries/application get packaged in the official tree > by the project, various factors can be considers by the team. These can > include metrics such as: > * bugzilla vote count amongst open maintainer-wanted packages > * recent general useful activity on the packages bugzilla entry > * past and present user community activity in providing ebuild > improvements, version bumps and fixes in the packages bugzilla > maintainer-wanted bug entry > * ease of the packaging thanks to active user contributions or > consistently good upstream packaging making the workload of the > maintainer-team not grow much > * team members interest and personal qualification in the type of the > package and its packaging methods > * ... > > > maintainer-wanted maintained packages are seen as a stopgap solution. As > such it is desired that eventually a team or developer takes over > maintenance to provide the packages dedicated care and free up the > maintainer-wanted team to make available more desired packages that do > not yet have a dedicated maintainer. To achieve that, various methods > are pursued: > > * Other teams and developers are encouraged to take over maintenance. > This includes proxy maintenance when for example a user is found to > consistently and with good quality help out the maintainer-wanted team > in providing fixes, improvements and bumps to an in-tree > maintainer-wanted maintained package. Taking over maintenance is as easy > as for maintainer-needed packages, however a notification to and > acknowledgment from a maintainer-wanted team member is appreciated. > > * Lists of maintainer-wanted packages are generated, sorted by category > of interest. Developers and dedicated package teams are encouraged to > find packages of interest from these lists and take over maintenance. > > * Simply the easier availability (and the resulting exposure) of a > package in the official tree (as opposed to an unreviewed, yet possibly > high quality, ebuild attached to bugzilla, which has thousands of such > entries) could catch the interest of another team or developer and they > are encouraged to take over maintenance when they have the capacity > (manpower/time etc) > > > In other ways the maintainer-wanted team is not significantly different > to other package maintaining teams: > * The project is responsible for their maintained packages. Quality is > not sacrificed; bugs on in-tree packages get acted upon, etc. As such it > is likely desired to have a different alias than the default one for new > packages (or a different good means of differentiating), as to not have > bugs against already in-tree packages get lost amongst the hundreds or > thousands of packages still waiting to get into the official package > tree. > * In-tree maintainer-wanted packages are also tried to be kept up to > date in regards to new stable upstream versions. Users are encouraged to > file bump requests on bugzilla even as 1-day requests due to the > diversity of packages maintained by the project and therefore too many > different places and notification mechanisms to manually check and > monitor for the team (bugzilla version bump requests solve the > diversity); at least until no mechanisms exist for automatic checking of > bumps, which could get implemented in the future. > > > The maintainer-te
Re: [gentoo-dev] zeroconf/avahi USE flag
Hello I would know what finally occurred with: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg31489.html Seems that last comment was: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg31502.html and, after that, activity stopped Is there any problem for having this "USE cleanup" done? Thanks a lot for the information :-)
[gentoo-dev] Please unmask app-emulation/emul-linux-x86-*-20081109
I sent months ago: http://bugs.gentoo.org/show_bug.cgi?id=254577 but I didn't get any reply yet. emul packages seem to be a bit unmaintained, also, there are no updates since months, guide for making emul packages is outdated (http://www.gentoo.org/proj/en/base/amd64/emul/index.xml ) and I have no idea about what amd64 plans to do on this area. But, at least, 20081109 emul packages fixes some important bugs that are currently affecting to people using stable. Can anybody take a look on it? Thanks a lot
Re: [gentoo-dev] eutils.eclass: make_desktop_entry doesn't follow freedesktop spec
El jue, 23-02-2012 a las 17:03 +0100, Ulrich Mueller escribió: > > On Thu, 23 Feb 2012, Samuli Suominen wrote: > > > TextEditor is a subcategory of Utility[1], so what pacho suggested > > is correct > > The cited specification [1] says: > | The table below describes Additional Categories. The Related > | Categories column lists one or more categories that are suggested > | to be used in conjunction with the Additional Category. > > As I read it, "Utility" is only a suggestion, but isn't mandatory as > main category for "TextEditor". > > Ulrich > > > [1] http://standards.freedesktop.org/menu-spec/latest/apa.html > > I have no problem on moving them to "Development" if you think their fit better there signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
El vie, 24-02-2012 a las 18:56 +0100, "Paweł Hajdan, Jr." escribió: > Currently preserve_old_lib functions generate two commands per preserved > lib: > > # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' > # rm '/usr/lib/libv8.so.3.9.4' > > I'd like to modify eutils.eclass to only generate one command: > > # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' && \ > rm '/usr/lib/libv8.so.3.9.4' > > What do you think? > Great, I am already running both in that way manually ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] eutils.eclass: make_desktop_entry doesn't follow freedesktop spec
El vie, 24-02-2012 a las 18:17 +0100, Ulrich Mueller escribió: > >>>>> On Thu, 23 Feb 2012, Pacho Ramos wrote: > > >> The cited specification [1] says: > >> | The table below describes Additional Categories. The Related > >> | Categories column lists one or more categories that are suggested > >> | to be used in conjunction with the Additional Category. > >> > >> As I read it, "Utility" is only a suggestion, but isn't mandatory > >> as main category for "TextEditor". > >> > >> > [1] http://standards.freedesktop.org/menu-spec/latest/apa.html > > > I have no problem on moving them to "Development" if you think their > > fit better there > > Please do. > > Ulrich > > Committed with that changes signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
El lun, 27-02-2012 a las 16:06 +0100, "Paweł Hajdan, Jr." escribió:
> On 2/24/12 6:56 PM, "Paweł Hajdan, Jr." wrote:
> > I'd like to modify eutils.eclass to only generate one command:
> >
> > # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' && \
> > rm '/usr/lib/libv8.so.3.9.4'
>
> Given supporting comments to this thread (and totally off-topic
> zfs/btrfs discussion), I'd like to commit the patch below in 24 hours.
>
> > --- eutils.eclass.orig 2012-02-26 10:02:24.0 +0100
> > +++ eutils.eclass 2012-02-26 10:03:17.0 +0100
> > @@ -1276,16 +1276,8 @@
> > fi
> > # temp hack for #348634 #357225
> > [[ ${PN} == "mpfr" ]] && lib=${lib##*/}
> > - ewarn " # revdep-rebuild --library '${lib}'"
> > + ewarn " # revdep-rebuild --library '${lib}' && rm '${lib}'"
> > done
> > - if [[ ${notice} -eq 1 ]] ; then
> > - ewarn
> > - ewarn "Once you've finished running revdep-rebuild, it should
> > be safe to"
> > - ewarn "delete the old libraries. Here is a copy & paste for
> > the lazy:"
> > - for lib in "$@" ; do
> > - ewarn " # rm '${lib}'"
> > - done
> > - fi
> > }
> >
> > # @FUNCTION: built_with_use
>
I think somebody pointed some "revdep-rebuild" versions where exiting
with successful code even when failed, was fixed version stabilized?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] The end of net-zope
El mié, 29-02-2012 a las 09:51 +0100, Dirkjan Ochtman escribió: > Tomorrow, March 1, is the deadline for removing almost all of the > Zope/Plone packages from the portage tree (those who still want them > can get them from Arfrever's Progress overlay). > > Since only one or two packages would remain in the category, do we > want the category to stay around, or should it be removed from the > tree? We could move the remaining packages to dev-python. > > Similarly, there is an empty herd. Do we have a procedure for > end-of-lifeing herds? > > Cheers, > > Dirkjan > > You can see here how we dropped a herd last time from retirement: https://bugs.gentoo.org/show_bug.cgi?id=401169 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due ken69267 retirement
Due his retirement the following packages need a new maintainer: app-misc/ignuit app-portage/gpytage app-shells/squirrelsh (this only needs a proxy-maintainer) Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] media-optical and net-zope herds are empty
Even if they have some people in their mail aliases, looks like herds are empty. If nobody volunteers to join to them, I think we should drop that herds and move their packages to maintainer-needed in a week or so. What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical and net-zope herds are empty
El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > Even if they have some people in their mail aliases, looks like herds > are empty. If nobody volunteers to join to them, I think we should drop > that herds and move their packages to maintainer-needed in a week or so. > > What do you think? > The same applies to "sgml" now that cryos is retiring :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > Even if they have some people in their mail aliases, looks like herds > > are empty. If nobody volunteers to join to them, I think we should drop > > that herds and move their packages to maintainer-needed in a week or so. > > > > What do you think? > > > > The same applies to "sgml" now that cryos is retiring :( and text-markup, I think it's the last empty herd now signature.asc Description: This is a digitally signed message part
[gentoo-dev] Important problems to maintain gtk-sharp ebuilds in their current splitted way
Hello We (dotnet team) are having a lot of problems to get gtk-sharp packages updated and fixed. All started time ago when we were unable to bump it due: https://bugs.gentoo.org/show_bug.cgi?id=382491 Now, a new important bug has appeared and we are lose about what is wrong and why has it broken recently: https://bugs.gentoo.org/show_bug.cgi?id=404139 Any help with this is appreciated, if nobody can help us, we will probably move back to monolithic gtk-sharp ebuild and hope that also helps to fix bug #404139 Thanks a lot for your help signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical and net-zope herds are empty
El dom, 04-03-2012 a las 14:06 +0100, Ulrich Mueller escribió: > >>>>> On Sun, 04 Mar 2012, Pacho Ramos wrote: > > > Even if they have some people in their mail aliases, looks like > > herds are empty. > > Sorry for nitpicking, but a "herd" is a collection of packages. So the > herds are not empty, but they have no maintainers. Well, I knew what a "herd" means exactly per devmanual ;), but, in real world, that "collection of packages" is really orphan (are like maintainer-needed packages but, what is worse, out of radar as they are not listed as orphan at all) (Personally I completely disagree with that sense of "herd" but, as looks the meaning is there since the beginning...) > > > If nobody volunteers to join to them, I think we should drop that > > herds and move their packages to maintainer-needed in a week or so. > > > What do you think? > > How many packages are in these two herds? If it's only a few, then > this certainly makes sense. > > Ulrich > > Only two for net-zope, but many more for, for example, sgml and media-optical. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical and net-zope herds are empty
El dom, 04-03-2012 a las 14:31 +0100, Pacho Ramos escribió: > El dom, 04-03-2012 a las 14:06 +0100, Ulrich Mueller escribió: > > >>>>> On Sun, 04 Mar 2012, Pacho Ramos wrote: > > > > > Even if they have some people in their mail aliases, looks like > > > herds are empty. > > > > Sorry for nitpicking, but a "herd" is a collection of packages. So the > > herds are not empty, but they have no maintainers. > > Well, I knew what a "herd" means exactly per devmanual ;), but, in real > world, that "collection of packages" is really orphan (are like > maintainer-needed packages but, what is worse, out of radar as they are > not listed as orphan at all) > Also, after re-reading devmanual, being 100% strict that collection of packages need to be "associated to a set of maintainers" (that is currently not the case :( ) > (Personally I completely disagree with that sense of "herd" but, as > looks the meaning is there since the beginning...) > > > > > > If nobody volunteers to join to them, I think we should drop that > > > herds and move their packages to maintainer-needed in a week or so. > > > > > What do you think? > > > > How many packages are in these two herds? If it's only a few, then > > this certainly makes sense. > > > > Ulrich > > > > > > Only two for net-zope, but many more for, for example, sgml and > media-optical. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: net-wireless/orinoco-sn, net-wireless/zd1201, net-wireless/hostap-driver, x11-misc/periodic-calendar, media-libs/libswf, net-misc/ajaxterm, media-gfx/swftools, dev-dotnet/mysql
# Pacho Ramos (06 Mar 2012) # Mask for removal as it fails to compile with recent # kernels. Use kernel driver instead, bug #209474 # Removal in a month. net-wireless/orinoco-sn # Pacho Ramos (06 Mar 2012) # Doesn't work with recent kernels, use kernel driver # instead, bug #214164. Removal in a month. net-wireless/zd1201 # Pacho Ramos (06 Mar 2012) # Doesn't work with recent kernels, use kernel driver # instead, bug #246986. Removal in a month. net-wireless/hostap-driver # Pacho Ramos (06 Mar 2012) # Our version is old and buggy, nobody willing to # update due deep changes in its way to be installed, # download it directly from upstream instead, bug #248588 # Removal in a month. x11-misc/periodic-calendar # Pacho Ramos (06 Mar 2012) # Pre-stripped files, no update since 2002, nothing # needs it, bug #251955. Removal in a month. media-libs/libswf # Pacho Ramos (06 Mar 2012) # Old, unmaintained and with security bug #269922 # Removal in a month. net-misc/ajaxterm # Pacho Ramos (06 Mar 2012) # Bundles some libraries, has an overflow, installs # broken symlinks, security issues. See bug #332649 # Removal in a month media-gfx/swftools # Pacho Ramos (06 Mar 2012) # Outdated, hard to bump and nobody willing to take # care of it. See bug #334927. Removal in a month. dev-dotnet/mysql-connector-net # Pacho Ramos (06 Mar 2012) # Doesn't respect LDFLAGS, old and replaced by kernel # driver for years, bug #339655. Removal in a month. app-laptop/acpi4asus # Pacho Ramos (06 Mar 2012) # Replaced by gnome-extra/panflute, bug #354245. # Removal in a month. gnome-extra/music-applet # Pacho Ramos (06 Mar 2012) # It spams dmesg, use kernel >= 3.0 driver instead. # See bug #367483, removal in a month. net-wireless/rtl8192se # Pacho Ramos (06 Mar 2012) # Our current version is too old, nobody wants to take # care of this package and upstream have changed their # build system completely, bug #372449. Removal in a month. dev-dotnet/edtftpnet # Pacho Ramos (06 Mar 2012) # Broken with gcc-4.6, old, unmaintained, upstream dead, # nothing needs it, bug #374803. Removal in a month. dev-python/PyQrcodec # Pacho Ramos (06 Mar 2012) # Broken for some time (bug #383933), upstream dead, # last release from 2008. Removal in a month. net-ftp/twoftpd # Pacho Ramos (06 Mar 2012) # No upstream, outdated, see bug #403377. Removal in a # month. app-i18n/man-pages-cs signature.asc Description: This is a digitally signed message part
[gentoo-dev] Doubts about need for "ewarn" when strip-linguas is used
I usually read messages in /var/log/portage/elog/summary.log to simply
warn me about "es es_ES" LINGUAS not being supported by that package.
That comes from eutils.eclass inside strip-linguas:
ewarn "Sorry, but ${PN} does not support the LINGUAS:" ${nols}
Is this warning really required, personally I know a lot of packages
that don't support spanish translations and I get no warning from them
(as they don't use strip-linguas). When I set LINGUAS variable in my
make.conf I assume a lot of packages won't support spanish translations,
and I see no point on being informed about that for some packages using
strip-linguas.
What do you think?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Doubts about need for "ewarn" when strip-linguas is used
El mar, 06-03-2012 a las 11:46 +0100, Pacho Ramos escribió:
> I usually read messages in /var/log/portage/elog/summary.log to simply
> warn me about "es es_ES" LINGUAS not being supported by that package.
> That comes from eutils.eclass inside strip-linguas:
> ewarn "Sorry, but ${PN} does not support the LINGUAS:" ${nols}
>
> Is this warning really required, personally I know a lot of packages
> that don't support spanish translations and I get no warning from them
> (as they don't use strip-linguas). When I set LINGUAS variable in my
> make.conf I assume a lot of packages won't support spanish translations,
> and I see no point on being informed about that for some packages using
> strip-linguas.
>
> What do you think?
OK with dropping message completely or use "einfo" instead of "ewarn"?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > > Even if they have some people in their mail aliases, looks like herds > > > are empty. If nobody volunteers to join to them, I think we should drop > > > that herds and move their packages to maintainer-needed in a week or so. > > > > > > What do you think? > > > > > > > The same applies to "sgml" now that cryos is retiring :( > > and text-markup, I think it's the last empty herd now Maybe we could do the same as did in the past for openoffice herd: - Change metadatas and bugs to assign them to maintainer-needed (and reflect reality) - Keep herd in metadatas and CCed them to bug reports The other option would be to simply drop that herds, assign packages to maintainer-needed and wait developers to grab whatever they want What do you prefer? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > On Fri, 09 Mar 2012 09:02:23 +0100 > Pacho Ramos wrote: > > > El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > > > El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > > > > Even if they have some people in their mail aliases, looks like > > > > > herds are empty. If nobody volunteers to join to them, I think > > > > > we should drop that herds and move their packages to > > > > > maintainer-needed in a week or so. > > > > > > > > > > What do you think? > > > > > > > > > > > > > The same applies to "sgml" now that cryos is retiring :( > > > > > > and text-markup, I think it's the last empty herd now > > > > Maybe we could do the same as did in the past for openoffice herd: > > - Change metadatas and bugs to assign them to maintainer-needed (and > > reflect reality) > > - Keep herd in metadatas and CCed them to bug reports > > > > The other option would be to simply drop that herds, assign packages > > to maintainer-needed and wait developers to grab whatever they want > > For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > removed almost all relevant packages, so there's no point in keeping > the herd. > OK but, what about the rest? ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: > On 03/09/2012 09:48 PM, Pacho Ramos wrote: > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > >> On Fri, 09 Mar 2012 09:02:23 +0100 > >> Pacho Ramos wrote: > >> > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > >>>> El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > >>>>> El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > >>>>>> Even if they have some people in their mail aliases, looks like > >>>>>> herds are empty. If nobody volunteers to join to them, I think > >>>>>> we should drop that herds and move their packages to > >>>>>> maintainer-needed in a week or so. > >>>>>> > >>>>>> What do you think? > >>>>>> > >>>>> > >>>>> The same applies to "sgml" now that cryos is retiring :( > >>>> > >>>> and text-markup, I think it's the last empty herd now > >>> > >>> Maybe we could do the same as did in the past for openoffice herd: > >>> - Change metadatas and bugs to assign them to maintainer-needed (and > >>> reflect reality) > >>> - Keep herd in metadatas and CCed them to bug reports > >>> > >>> The other option would be to simply drop that herds, assign packages > >>> to maintainer-needed and wait developers to grab whatever they want > >> > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > >> removed almost all relevant packages, so there's no point in keeping > >> the herd. > >> > > > > OK but, what about the rest? ;) > > Please leave at least media-optical@ be as it is. Changing it doesn't > make any sense. > > Well, the idea would be to get their bugs assigned to maintainer-needed and media-optical CCed if somebody wants to take that stuff someday, it would reflect better reality as, currently, their bugs are being assigned to an empty herd (yes, xarthisius (I think he was in alias but not officially in herd last time I checked, anyway it's only one example, nothing personal against him of course :)). What will occur when he simply drops his mail from alias as he never wanted to be a member of that herd? What would occur if he only wants to maintain some packages but others are getting ignored? The idea to get them moved to "orphan" is to reflect reality and, that way, try to get developers (or users willing to proxy maintain them) involved on exact apps they really want to keep maintained. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió: > El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: > > On 03/09/2012 09:48 PM, Pacho Ramos wrote: > > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > > >> On Fri, 09 Mar 2012 09:02:23 +0100 > > >> Pacho Ramos wrote: > > >> > > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > > >>>> El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > >>>>> El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > >>>>>> Even if they have some people in their mail aliases, looks like > > >>>>>> herds are empty. If nobody volunteers to join to them, I think > > >>>>>> we should drop that herds and move their packages to > > >>>>>> maintainer-needed in a week or so. > > >>>>>> > > >>>>>> What do you think? > > >>>>>> > > >>>>> > > >>>>> The same applies to "sgml" now that cryos is retiring :( > > >>>> > > >>>> and text-markup, I think it's the last empty herd now > > >>> > > >>> Maybe we could do the same as did in the past for openoffice herd: > > >>> - Change metadatas and bugs to assign them to maintainer-needed (and > > >>> reflect reality) > > >>> - Keep herd in metadatas and CCed them to bug reports > > >>> > > >>> The other option would be to simply drop that herds, assign packages > > >>> to maintainer-needed and wait developers to grab whatever they want > > >> > > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > > >> removed almost all relevant packages, so there's no point in keeping > > >> the herd. > > >> > > > > > > OK but, what about the rest? ;) > > > > Please leave at least media-optical@ be as it is. Changing it doesn't > > make any sense. > > > > > > Well, the idea would be to get their bugs assigned to maintainer-needed > and media-optical CCed if somebody wants to take that stuff someday, it > would reflect better reality as, currently, their bugs are being > assigned to an empty herd (yes, xarthisius (I think he was in alias but > not officially in herd last time I checked, anyway it's only one > example, nothing personal against him of course :)). What will occur > when he simply drops his mail from alias as he never wanted to be a > member of that herd? What would occur if he only wants to maintain some > packages but others are getting ignored? > > The idea to get them moved to "orphan" is to reflect reality and, that > way, try to get developers (or users willing to proxy maintain them) > involved on exact apps they really want to keep maintained. As talked just now with Samuli, he added him to media-optical (both, to alias and herds.xml) and then, this no longer applies to media-optical obviously ;) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Deprecate EAPI1?
After reading previous discussion: http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html Looks like preventing NEW commits from using eapi1 (via repoman) could be done without major issues. This could even being done also for eapi2 as it's close enough to eapi3, but I don't have a strong opinion about eapi2 deprecation (personally, I try to always use latest eapi if eclass allows me to do so). Any thoughts on this? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecate EAPI1?
El dom, 11-03-2012 a las 13:01 +0100, Pacho Ramos escribió: > After reading previous discussion: > http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html > > Looks like preventing NEW commits from using eapi1 (via repoman) could > be done without major issues. This could even being done also for eapi2 > as it's close enough to eapi3, but I don't have a strong opinion about > eapi2 deprecation (personally, I try to always use latest eapi if eclass > allows me to do so). > > Any thoughts on this? > > Thanks Well, the reasons for me preferring to not allow *new* ebuilds to use eapi1 is to try to move to use things like, for example, src_prepare/src_configure phases. I guess that phases were included for some "technical" reasons and, then, I think we should try to use them if possible install of still adding NEW ebuilds using old eapi0/1 way of doing things signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Deprecate EAPI1?
El mar, 13-03-2012 a las 11:52 -0700, Zac Medico escribió: > On 03/11/2012 05:49 PM, Brian Harring wrote: > > If people want to enforce the eapi1 is no longer used in the gentoo > > repo, that's fine- we stick a list of acceptable EAPI's into > > its layout.conf. > > That sounds pretty reasonable, although I think a deprecation warning > would be more appropriate that an outright ban. A deprecation warning > should be sufficient to send the intended message, without placing an > unnecessary burden on people doing simple version bumps or adding > ebuilds that are already well tested though they happen to use an older > EAPI. I fully agree with this approach signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: dev-libs/libtomcrypt, app-admin/srlog2, dev-libs/tomsfastmath, gnome-extra/hardware-monitor, dev-dotnet/gluezilla
# Pacho Ramos (18 Mar 2012) # Broken in several ways, removal in 30 days. # Bug 262601 dev-libs/libtomcrypt app-admin/srlog2 dev-libs/tomsfastmath # Pacho Ramos (18 Mar 2012) # Upstream dead, nobody willing to maintain it and # buggy, bug #348500. Removal in 30 days. gnome-extra/hardware-monitor # Pacho Ramos (18 Mar 2012) # Unmaintained, nothing needs it, bug #363205 # Removal in 30 days. dev-dotnet/gluezilla signature.asc Description: This is a digitally signed message part
Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)
El dom, 18-03-2012 a las 18:01 +0100, Pacho Ramos escribió: > El vie, 09-03-2012 a las 21:21 +0100, Pacho Ramos escribió: > > El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió: > > > El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: > > > > On 03/09/2012 09:48 PM, Pacho Ramos wrote: > > > > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > > > > >> On Fri, 09 Mar 2012 09:02:23 +0100 > > > > >> Pacho Ramos wrote: > > > > >> > > > > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > > > > >>>> El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > > > >>>>> El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > > > >>>>>> Even if they have some people in their mail aliases, looks like > > > > >>>>>> herds are empty. If nobody volunteers to join to them, I think > > > > >>>>>> we should drop that herds and move their packages to > > > > >>>>>> maintainer-needed in a week or so. > > > > >>>>>> > > > > >>>>>> What do you think? > > > > >>>>>> > > > > >>>>> > > > > >>>>> The same applies to "sgml" now that cryos is retiring :( > > > > >>>> > > > > >>>> and text-markup, I think it's the last empty herd now > > > > >>> > > > > >>> Maybe we could do the same as did in the past for openoffice herd: > > > > >>> - Change metadatas and bugs to assign them to maintainer-needed (and > > > > >>> reflect reality) > > > > >>> - Keep herd in metadatas and CCed them to bug reports > > > > >>> > > > > >>> The other option would be to simply drop that herds, assign packages > > > > >>> to maintainer-needed and wait developers to grab whatever they want > > > > >> > > > > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > > > > >> removed almost all relevant packages, so there's no point in keeping > > > > >> the herd. > > > > >> > > > > > > > > > > OK but, what about the rest? ;) > > > > > > > > Please leave at least media-optical@ be as it is. Changing it doesn't > > > > make any sense. > > > > > > > > > > > > > > Well, the idea would be to get their bugs assigned to maintainer-needed > > > and media-optical CCed if somebody wants to take that stuff someday, it > > > would reflect better reality as, currently, their bugs are being > > > assigned to an empty herd (yes, xarthisius (I think he was in alias but > > > not officially in herd last time I checked, anyway it's only one > > > example, nothing personal against him of course :)). What will occur > > > when he simply drops his mail from alias as he never wanted to be a > > > member of that herd? What would occur if he only wants to maintain some > > > packages but others are getting ignored? > > > > > > The idea to get them moved to "orphan" is to reflect reality and, that > > > way, try to get developers (or users willing to proxy maintain them) > > > involved on exact apps they really want to keep maintained. > > > > As talked just now with Samuli, he added him to media-optical (both, to > > alias and herds.xml) and then, this no longer applies to media-optical > > obviously ;) > > > > Will then do the following: > - Add a tag to their metadatas to get bugs assigned to > maintainer-needed > - Keep herd to get it CCed (like was done some weeks ago with openoffice > herd) > > This applies to "sgml" and "text-markup" since media-optical is active > again and looks like net-zope packages will go away soon > Finally, only sgml is inside this case as it contains a lot of packages: app-doc/halibut app-emacs/nxml-mode app-emacs/psgml app-office/passepartout app-text/asciidoc app-text/build-docbook-catalog app-text/docbook-dsssl-stylesheets app-text/docbook-sgml-dtd app-text/docbook-sgml-utils app-text/docbook-sgml app-text/docbook-xml-dtd app-text/docbook-xml-simple-dtd app-text/docbook-xsl-stylesheets app-text/docbook2X app-text/gentoo-guide-xml-dtd app-text/gnome-doc-utils app-text/grutatxt app-text/highlight app-text/html-xml-utils app-text/html2text app-text/html401 app-text/htmlrecode app-text/htmltidy app-text/linuxdoc-tools app-text/openjade app-text/opensp app-text/robodoc app-text/sablotron app-text/scrollkeeper-dtd app-text/scrollkeeper app-text/sgml-common app-text/sgmltools-lite app-text/sgrep app-text/txt2tags app-text/webgen app-text/xhtml1 app-text/xml2 app-text/xml2doc app-text/xmlformat app-text/xmlstarlet app-text/xmlto dev-ruby/xml-simple www-client/htmlview Is anyone willing to join the herd? If not, maybe somebody could take a few packages if they want to take care of only a set of them and not all the beast :-/ signature.asc Description: This is a digitally signed message part
Re: Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)
El dom, 18-03-2012 a las 13:38 -0400, Mike Gilbert escribió: > On Sun, Mar 18, 2012 at 1:28 PM, Pacho Ramos wrote: > > Is anyone willing to join the herd? If not, maybe somebody could take a > > few packages if they want to take care of only a set of them and not all > > the beast :-/ > > I took a look at the sgml bugs list, and most of them seem pretty > straightforward. I'll add myself and work on them as I have time. > > Please don't let that stop you if you are thinking of picking up any > of the packages in pacho's list. > > Thanks a lot Mike :D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty
El vie, 09-03-2012 a las 21:21 +0100, Pacho Ramos escribió: > El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió: > > El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió: > > > On 03/09/2012 09:48 PM, Pacho Ramos wrote: > > > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió: > > > >> On Fri, 09 Mar 2012 09:02:23 +0100 > > > >> Pacho Ramos wrote: > > > >> > > > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió: > > > >>>> El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió: > > > >>>>> El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió: > > > >>>>>> Even if they have some people in their mail aliases, looks like > > > >>>>>> herds are empty. If nobody volunteers to join to them, I think > > > >>>>>> we should drop that herds and move their packages to > > > >>>>>> maintainer-needed in a week or so. > > > >>>>>> > > > >>>>>> What do you think? > > > >>>>>> > > > >>>>> > > > >>>>> The same applies to "sgml" now that cryos is retiring :( > > > >>>> > > > >>>> and text-markup, I think it's the last empty herd now > > > >>> > > > >>> Maybe we could do the same as did in the past for openoffice herd: > > > >>> - Change metadatas and bugs to assign them to maintainer-needed (and > > > >>> reflect reality) > > > >>> - Keep herd in metadatas and CCed them to bug reports > > > >>> > > > >>> The other option would be to simply drop that herds, assign packages > > > >>> to maintainer-needed and wait developers to grab whatever they want > > > >> > > > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope, > > > >> removed almost all relevant packages, so there's no point in keeping > > > >> the herd. > > > >> > > > > > > > > OK but, what about the rest? ;) > > > > > > Please leave at least media-optical@ be as it is. Changing it doesn't > > > make any sense. > > > > > > > > > > Well, the idea would be to get their bugs assigned to maintainer-needed > > and media-optical CCed if somebody wants to take that stuff someday, it > > would reflect better reality as, currently, their bugs are being > > assigned to an empty herd (yes, xarthisius (I think he was in alias but > > not officially in herd last time I checked, anyway it's only one > > example, nothing personal against him of course :)). What will occur > > when he simply drops his mail from alias as he never wanted to be a > > member of that herd? What would occur if he only wants to maintain some > > packages but others are getting ignored? > > > > The idea to get them moved to "orphan" is to reflect reality and, that > > way, try to get developers (or users willing to proxy maintain them) > > involved on exact apps they really want to keep maintained. > > As talked just now with Samuli, he added him to media-optical (both, to > alias and herds.xml) and then, this no longer applies to media-optical > obviously ;) > Will then do the following: - Add a tag to their metadatas to get bugs assigned to maintainer-needed - Keep herd to get it CCed (like was done some weeks ago with openoffice herd) This applies to "sgml" and "text-markup" since media-optical is active again and looks like net-zope packages will go away soon signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] media-optical and net-zope herds are empty
El dom, 04-03-2012 a las 15:11 +0100, Dirkjan Ochtman escribió: > On Sun, Mar 4, 2012 at 14:31, Pacho Ramos wrote: > > Only two for net-zope, but many more for, for example, sgml and > > media-optical. > > We just cleaned out most of the net-zope packages. The remaining > net-zope packages will be maintained by the python team; the net-zope > herd can probably be removed. > > Cheers, > > Dirkjan > > Just moved two remaining packages to python ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?
El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió: > I'd like to help with this and will take a look at the bug below. I'd > like to be part of the cjk herd as well. > > On 03/05/12 05:56, Samuli Suominen wrote: > > Really need a reply on http://bugs.gentoo.org/405777 and nobody seems to > > be listening the cjk@ alias > > > > Should I just roll a dice and CC arch's? > > > > Thanks, > Will CC cjk team then to let them know you are interested to join (looks like there are four devs in cjk alias...) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due iluxa retirement
Due his retirement the following packages need a new maintainer: dev-cpp/cppserv Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due jokey retirement
Due his retirement the following packages need a new maintainer: app-misc/ytree app-portage/maintainer-helper app-shells/pdmenu dev-libs/libmba dev-vcs/easygit net-misc/italc net-misc/proxytunnel net-misc/x-lite (has a proxy maintainer!) sys-fs/archfs Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] lcd herd is empty
With jokey retirement (#118003) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due bass retirement
Due his retirement the following packages need a new maintainer: app-admin/localepurge app-admin/recursos app-doc/ebookmerge app-misc/gnomecatalog dev-embedded/gnap-dev dev-embedded/gnap net-analyzer/midas-nms net-im/coccinella net-misc/htbinit net-nds/lat Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] www-servers herd is empty
With bass retirement (#391429) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: > Hi, > I'd be interested in helping with www-servers, but I would have to > help by proxy because I am not a dev yet. > Chris Reffett > > On 03/18/12 15:27, Pacho Ramos wrote: > > With bass retirement (#391429) lcd has become empty, is anybody willing > > to join or should their packages be moved to maintainer-needed (CCing > > that empty herd to allow somebody joining in the future to easily > > resurrect the herd)? > > > > Thanks > > Thanks for offering your help, will CC gentoo-dev mailing list and proxy-maint to see how we could handle this case signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Packages up for grabs due bass retirement
El dom, 18-03-2012 a las 23:56 -0600, Ryan Hill escribió: > On Sun, 18 Mar 2012 20:25:58 +0100 > Pacho Ramos wrote: > > > Due his retirement the following packages need a new maintainer: > > > app-doc/ebookmerge > > This is something bass wrote that grabs html manuals from > http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to > http://code.google.com/p/htmlhelp/). I don't really see the usefulness of it > since almost all of the content is just html versions of standard info/man > pages. Anyways, it's completely broken as-is. > > I also though it could be treecleaned until I saw patches to fix that issues are included in: https://bugs.gentoo.org/show_bug.cgi?id=388927 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?
El lun, 19-03-2012 a las 13:32 +0900, Naohiro Aota escribió: > Hi, > > It is great to hear Jack is willing to join cjk herd. I can help Jack > working on cjk bugs. But, to be honest, I'm not familiar with recruiting > process so I need some devs to do or to help me on the recruiting. > > Also I've read the "Mentor Guide" [1] and found "your project lead must > be CC'd". I'm concerning about this "project". Does he need some project > to join in? or is it just enough to join cjk herd? > > [1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml I think joining to cjk would be enough :-/ > > Pacho Ramos writes: > > > El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió: > > > >> I'd like to help with this and will take a look at the bug below. I'd > >> like to be part of the cjk herd as well. > >> > >> On 03/05/12 05:56, Samuli Suominen wrote: > >> > Really need a reply on http://bugs.gentoo.org/405777 and nobody seems to > >> > be listening the cjk@ alias > >> > > >> > Should I just roll a dice and CC arch's? > >> > >> > >> > >> Thanks, > >> > > > > Will CC cjk team then to let them know you are interested to join (looks > > like there are four devs in cjk alias...) signature.asc Description: This is a digitally signed message part
[gentoo-dev] About maintaining sci-physics/abinit
Hello As talked some time ago with Donnie, sci-physics/abinit is hard to maintain and, then, he would like to lastrite it after moving package to sci overlay because looks like nobody from sci team wants to take it. If anybody is willing to help with maintaining abinit, could he take it? If not, could anybody with commit access to sci overlay to move abinit to it and let us lastrite it from main tree? Thanks a lot signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due jokey retirement
El lun, 19-03-2012 a las 10:56 -0500, Paul Varner escribió: > On 03/18/12 13:50, Pacho Ramos wrote: > > Due his retirement the following packages need a new maintainer: > > > > app-portage/maintainer-helper > > > > > > Thanks for taking them > > I've added app-portage/maintainer-helper to the tools-portage herd, > however, I've left it as maintainer-needed. So if anyone wants to take > it, feel free. The tools-portage herd will fix bugs for it as we find > the time. > > Regards, > Paul I disagree with leaving maintainer-needed as default assign, if you will fix bugs when you have time it's better than what I will do with maintainer-needed packages. Also, I think most of maintainers would like to have help with a lot of packages, but that is not enough reason to change their metadatas to get bugs assigned to maintainer-needed and us CCed Have you seen any case when "if anyone wants to take it" he is not able to because the package is "owned" by a herd? If you want to promote that package be taken by other as soon as possible, add a note to metadata telling that (I have seen it in some cases) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El lun, 19-03-2012 a las 20:48 +, Markos Chandras escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 03/19/2012 08:32 AM, Pacho Ramos wrote: > > El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: > >> Hi, I'd be interested in helping with www-servers, but I would > >> have to help by proxy because I am not a dev yet. Chris Reffett > >> > >> On 03/18/12 15:27, Pacho Ramos wrote: > >>> With bass retirement (#391429) lcd has become empty, is anybody > >>> willing to join or should their packages be moved to > >>> maintainer-needed (CCing that empty herd to allow somebody > >>> joining in the future to easily resurrect the herd)? > >>> > >>> Thanks > >>> > > > > Thanks for offering your help, will CC gentoo-dev mailing list and > > proxy-maint to see how we could handle this case > > > It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry > > - -- > Regards, > Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 We need to try to find a way to let him contribute, the problem is that I don't know much about Chris to know if he is ready to try to become a gentoo-dev in the near future :S signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due jokey retirement
El lun, 19-03-2012 a las 22:41 -0500, Paul Varner escribió: > On 3/19/12 2:26 PM, Pacho Ramos wrote: > > El lun, 19-03-2012 a las 10:56 -0500, Paul Varner escribió: > >> On 03/18/12 13:50, Pacho Ramos wrote: > >>> Due his retirement the following packages need a new maintainer: > >>> > >>> app-portage/maintainer-helper > >>> > >>> > >>> Thanks for taking them > >> > >> I've added app-portage/maintainer-helper to the tools-portage herd, > >> however, I've left it as maintainer-needed. So if anyone wants to take > >> it, feel free. The tools-portage herd will fix bugs for it as we find > >> the time. > > > > I disagree with leaving maintainer-needed as default assign, if you will > > fix bugs when you have time it's better than what I will do with > > maintainer-needed packages. > > Okay, I've taken out the maintainer-needed as the maintainer and have > just left it assigned to the herd. However, in reading through > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4, I > don't see a good mechanism to convey that the package is up for grabs, > but in the meantime go ahead and assign any bugs to the herd. > > Regards, > Paul > > Yeah, a mechanism for indicating a package is up for grabs would be interesting, the problem is how to prevent people from tagging as so a lot of packages and, then, making that mechanism completely useless as wouldn't distinct between "real" up for grabs packages or not "as real" :( But thanks a lot for taking care :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El mar, 20-03-2012 a las 11:40 +0200, Samuli Suominen escribió: > On 03/20/2012 11:36 AM, Pacho Ramos wrote: > > El lun, 19-03-2012 a las 20:48 +, Markos Chandras escribió: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA512 > >> > >> On 03/19/2012 08:32 AM, Pacho Ramos wrote: > >>> El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: > >>>> Hi, I'd be interested in helping with www-servers, but I would > >>>> have to help by proxy because I am not a dev yet. Chris Reffett > >>>> > >>>> On 03/18/12 15:27, Pacho Ramos wrote: > >>>>> With bass retirement (#391429) lcd has become empty, is anybody > >>>>> willing to join or should their packages be moved to > >>>>> maintainer-needed (CCing that empty herd to allow somebody > >>>>> joining in the future to easily resurrect the herd)? > >>>>> > >>>>> Thanks > >>>>> > >>> > >>> Thanks for offering your help, will CC gentoo-dev mailing list and > >>> proxy-maint to see how we could handle this case > >>> > >> It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry > >> > >> - -- > >> Regards, > >> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 > > > > We need to try to find a way to let him contribute, the problem is that > > I don't know much about Chris to know if he is ready to try to become a > > gentoo-dev in the near future :S > > I find the whole concept of www-servers herd flawed. > It's not very likely one person would be running many different servers, > and thus be able to contribute to them. > > Propably why the team has no members in the first place... > > Then, the way to go would be to move them to maintainer-needed and let people pick whatever they want. I agree and can do it myself just now if you let me do signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due www-server herd removal
As discussed in "[gentoo-dev] www-servers herd is empty" thread, we agreed with dropping this herd and let people get what they want to maintain. This is the list of orphan packages: www-servers/boa www-servers/bozohttpd www-servers/cherokee www-servers/fnord www-servers/lighttpd www-servers/mini_httpd www-servers/monkeyd www-servers/pound www-servers/pshs www-servers/publicfile www-servers/spawn-fcgi www-servers/thttpd www-servers/varnish www-servers/webfs Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Packages up for grabs due www-server herd removal
El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió: > As discussed in "[gentoo-dev] www-servers herd is empty" thread, > we agreed with dropping this herd and let people get what they want > to maintain. This is the list of orphan packages: [...] > www-servers/bozohttpd [...] This is a false positive: it already has a maintainer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Packages up for grabs due www-server herd removal
El mié, 21-03-2012 a las 12:28 +0100, Pacho Ramos escribió: > El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió: > > As discussed in "[gentoo-dev] www-servers herd is empty" thread, > > we agreed with dropping this herd and let people get what they want > > to maintain. This is the list of orphan packages: > [...] > > www-servers/bozohttpd > [...] > > This is a false positive: it already has a maintainer The same for: www-servers/lighttpd www-servers/pshs signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El jue, 22-03-2012 a las 15:46 +, Sven Vermeulen escribió: > On Wed, Mar 21, 2012 at 09:22:19AM +0100, Dirkjan Ochtman wrote: > > > Then, the way to go would be to move them to maintainer-needed and let > > > people pick whatever they want. I agree and can do it myself just now if > > > you let me do > > > > Seems sensible. > > I also dont mind helping out here, I use nginx, privoxy, squid and apache on > a daily basis (albeit not to their full potential). > > Wkr, > Sven Vermeulen > > The herd removal and assign to maintainer-needed was already done, then, feel free to add yourself to metadatas you prefer ;) (and remember to reassign existing bugs) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: net-im/msn-transport, net-im/yahoo-transport, net-p2p/giftoxic, net-p2p/dchub, dev-cpp/cppcsp2, dev-util/radare, www-servers/mini_httpd, net-analyzer/midas-nms, media-sound/dem
# Pacho Ramos # Fails to build (#239789), dead project (#303695). # Removal in 30 days. net-im/msn-transport # Pacho Ramos # Fails to build (#153266), dead. Removal in 30 days. net-im/yahoo-transport # Pacho Ramos # Segfaults, bug #168802. Dead since 2003. Removal in # 30 days. net-p2p/giftoxic # Pacho Ramos # Fails to build (#205375), doesn't respect LDFLAGS # (#337310), dead since 2006 (#370603). Removal in 30 # days. net-p2p/dchub # Pacho Ramos # Fortify kills its tests (#294824), dead since 2009 # and nothing needs it in the tree. Removal in 30 days. dev-cpp/cppcsp2 # Pacho Ramos # Installs to hard-coded python paths (#297040), buffer # overflow (#337478), nobody willing to maintain/fix it. # Removal in 30 days. dev-util/radare # Pacho Ramos # Security bugs (#301909, #303755). Removal in 30 days. www-servers/mini_httpd # Pacho Ramos # Tries to install data from local install (#332469), # doesn't respect LDFLAGS (#332467), dead since 2004. # Removal in 30 days. net-analyzer/midas-nms # Pacho Ramos # Doesn't respect LDFLAGS (#334717), still using glib:1, # dead upstream. Removal in 30 days. media-sound/demolition # Pacho Ramos # Overflows and multiple other problems (#336606), # removal in 30 days. net-fs/coda # Pacho Ramos # Propietary now, overflows (#337087). Removal in 30 # days. dev-db/ingres # Pacho Ramos # Buffer overflow (#337676), no update since 2003. # Removal in 30 days. net-irc/echat # Pacho Ramos # Buffer overflow (#338151), no release since 2007, # nothing in the tree needs it. Removal in 30 days. media-libs/libgiigic # Pacho Ramos # Buffer overflow (#339746), upstream dead, bundles # some libs. Removal in 30 days. app-editors/cssed # Pacho Ramos # Buffer overflow (#339842), dead since 2006. Removal # in 30 days. net-im/gyach # Pacho Ramos # Buffer overflow (#343575), dead since 2006. Removal # in 30 days. net-analyzer/pathrate # Pacho Ramos # Upstream dead, fails to build with gcc-4.6 (#363465), # removal in 30 days. dev-libs/sucs # Pacho Ramos # Fails to build (#367697), dead project. Removal in # 30 days. x11-misc/expocity # Pacho Ramos # Became propietary and no longer provides linux version, # removal in 30 days. net-misc/x-lite # Pacho Ramos # Needs net-misc/mDNSResponder (#405395), dead since # 2005 and not compatible with recent asterisk. Removal # in 30 days. net-misc/asterisk-res_bondia signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages maintained by volkmar need a co-maintainer
Due lack of time, volkmar's packages need a co-maintainer as talked with him: app-emulation/playonlinux app-emulation/vboxgtk dev-libs/xmlrpc-epi dev-python/graphy dev-util/bam media-libs/pnglite media-video/miro net-misc/plowshare net-misc/yaydl sci-libs/plotmm Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Hello I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower "emerge -pvuDN world" (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. Thanks for discussing this :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Will start to reply but will take some time as I don't have much this days :( El mar, 27-03-2012 a las 20:01 +0200, Sven Vermeulen escribió: > On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: > > I am a bit surprised handbook still doesn't suggest people to create a > > separate partition for /usr/portage tree. I remember my first Gentoo > > systems had it inside / and that lead to a lot of fragmentation, much > > slower "emerge -pvuDN world" (I benchmarked it when I changed my > > partitioning scheme to put /usr/portage) separate and a lot of disk > > space lost (I remember portage tree reached around 3 GB of disk space > > while I am now running with 300MB) > > > > Could handbook suggest people to put /usr/portage on a different > > partition then? The only doubt I have is what filesystem would be better > > for it, in my case I am using reiserfs with tail enabled, but maybe you > > have other different setups. > > To be honest, I don't think it is wise to describe it in the Gentoo Handbook > just yet. I don't mind having it documented elsewhere, but the separate > partition is not mandatory for getting Gentoo up and running. The > instructions currently also just give an example partition layout and tell > users that different layouts are perfectly possible. > > We need to take into consideration what is needed (must) for a Gentoo > installation, what is seriously recommended (should), what is nice to have > (could), etc. And for me, having a separate /usr/portage is a nice-to-have > imo. > > Wkr, > Sven Vermeulen > > My idea is to add a comment about this because it's not obvious having portage tree in a "common" partition with the rest of the system has some problems like high fragmentation, waste of disk space and also performance problems. I discovered it empirically when trying to get "emerge -pvuDN world" a bit faster. Also, once a partition scheme is chosen when installing Gentoo at first time, it's sometimes difficult to modify (for example, I was luck in my cases because I had big swap partitions I shrinked a bit for portage tree. You can probably see it's "nice-to-have" (as partition scheme that is shown in handbook showing partitions for /var, /home...), but it's better than letting people put their portage trees in a standard partition with the rest of the system signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 14:34 -0400, Alexandre Rostovtsev escribió: > On Tue, 2012-03-27 at 20:01 +0200, Sven Vermeulen wrote: > > On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: > > > I am a bit surprised handbook still doesn't suggest people to create a > > > separate partition for /usr/portage tree. I remember my first Gentoo > > > systems had it inside / and that lead to a lot of fragmentation, much > > > slower "emerge -pvuDN world" (I benchmarked it when I changed my > > > partitioning scheme to put /usr/portage) separate and a lot of disk > > > space lost (I remember portage tree reached around 3 GB of disk space > > > while I am now running with 300MB) > > > > > > Could handbook suggest people to put /usr/portage on a different > > > partition then? The only doubt I have is what filesystem would be better > > > for it, in my case I am using reiserfs with tail enabled, but maybe you > > > have other different setups. > > > > To be honest, I don't think it is wise to describe it in the Gentoo Handbook > > just yet. I don't mind having it documented elsewhere, but the separate > > partition is not mandatory for getting Gentoo up and running. The > > instructions currently also just give an example partition layout and tell > > users that different layouts are perfectly possible. > > > > We need to take into consideration what is needed (must) for a Gentoo > > installation, what is seriously recommended (should), what is nice to have > > (could), etc. And for me, having a separate /usr/portage is a nice-to-have > > imo. [...] > 2. The handbook should mention that a separate small /usr/portage > partition can noticeably improve performance for users with a rotational > hard drive, and that it's not needed for solid-state drives. It should > also mention that using Gentoo with a separate /usr/portage partition > will require some additional configuration (such as changing DISTDIR and > PKGDIR to avoid running out of space). > > -Alexandre. > > > This would be nice :D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 14:53 -0400, Ian Stakenvicius escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 27/03/12 02:47 PM, Rich Freeman wrote: > > On Tue, Mar 27, 2012 at 2:34 PM, Alexandre Rostovtsev > > > >> The partitioning scheme is something that the user needs to > >> decide on *before* getting Gentoo up and running. After the user > >> had finished installing the operating system, it's too late to > >> inform him about the advantages of a separate /usr/portage. > > > > Yes and no (if you have free space, you could easily move > > /usr/portage - some other changes are harder). > > > > However, you could extend this line of argument to raid, lvm, and > > even stuff like the use of systemd or an alternative package > > manager. All of those things are much easier to implement if you > > just start out with them. > > > > I'm all for creating a wiki to talk about some alternative > > options. Perhaps even link to it at the start of the handbook in > > the intro (if you're not in a rush and want to read about more > > advanced configurations, check out ...). > > > > However, I tend to agree that the handbook should be a > > nearly-foolproof no-frills Gentoo installation. > > > > > You know, we have "Code Listing 2.1: Filesystem Example" in Section 4, > we could always adjust that to have a /usr/portage partition in it > (take a bit of space away from /home, or something) > > It doesn't recommend/require anything, but when users see it they'll > think about it. This would be a good option, but I would anyway add a note warning people about the cons of having portage tree in a normal partition with the rest of the system, otherwise people could simply ignore that code listing because they could thing it's there simply on a try to get all system "splitted" ;) (for example, I don't usually have a separate partition for all what is listed there, only /, /home and /usr/portage) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 16:05 -0400, Alec Moskvin escribió: > On Tuesday 27 March 2012 14:34:03, Alexandre Rostovtsev wrote: > > On Tue, 2012-03-27 at 20:01 +0200, Sven Vermeulen wrote: > > > On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: > > > > I am a bit surprised handbook still doesn't suggest people to create a > > > > separate partition for /usr/portage tree. I remember my first Gentoo > > > > systems had it inside / and that lead to a lot of fragmentation, much > > > > slower "emerge -pvuDN world" (I benchmarked it when I changed my > > > > partitioning scheme to put /usr/portage) separate and a lot of disk > > > > space lost (I remember portage tree reached around 3 GB of disk space > > > > while I am now running with 300MB) > > > > > > > > Could handbook suggest people to put /usr/portage on a different > > > > partition then? The only doubt I have is what filesystem would be better > > > > for it, in my case I am using reiserfs with tail enabled, but maybe you > > > > have other different setups. > > > > > > To be honest, I don't think it is wise to describe it in the Gentoo > > > Handbook > > > just yet. I don't mind having it documented elsewhere, but the separate > > > partition is not mandatory for getting Gentoo up and running. The > > > instructions currently also just give an example partition layout and tell > > > users that different layouts are perfectly possible. > > > > > > We need to take into consideration what is needed (must) for a Gentoo > > > installation, what is seriously recommended (should), what is nice to have > > > (could), etc. And for me, having a separate /usr/portage is a nice-to-have > > > imo. > > > > The partitioning scheme is something that the user needs to decide on > > *before* getting Gentoo up and running. After the user had finished > > installing the operating system, it's too late to inform him about the > > advantages of a separate /usr/portage. > > It does not have to be a separate *physical* partition. It could be set > up as a loop device without any real downsides: > > /usr/portage/tree.ext4/usr/portage/tree ext4loop,noatime > 0 0 > > An advantage is that it can be easily resized if necessary. > > > IMHO, chapter 4 of the handbook needs the following changes: > > > > 1. ext4, not ext3, needs to be recommended as the default filesystem. We > > have kernel 3.2 marked stable, there is no need to keep talking about > > ext4 as if it's something experimental. > > > > 2. The handbook should mention that a separate small /usr/portage > > partition can noticeably improve performance for users with a rotational > > hard drive, and that it's not needed for solid-state drives. It should > > also mention that using Gentoo with a separate /usr/portage partition > > will require some additional configuration (such as changing DISTDIR and > > PKGDIR to avoid running out of space). > > > > -Alexandre. > > > > > > (I think this last reply can complete my replies to this thread for now :)) Looks then that there are several alternatives for portage tree, then, maybe the option would be to add a note to Gentoo Handbook explaining the cons of having portage tree on a standard partition and, then, put a link to a wiki page (for example) where all this alternatives are explained. What do you think about this approach? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El sáb, 31-03-2012 a las 08:44 +, Sven Vermeulen escribió: > On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote: > > Looks then that there are several alternatives for portage tree, then, > > maybe the option would be to add a note to Gentoo Handbook explaining > > the cons of having portage tree on a standard partition and, then, put a > > link to a wiki page (for example) where all this alternatives are > > explained. > > > > What do you think about this approach? > > I don't like the "cons" approach, as it gives the impression that users are > pushed into a negative solution, whereas the current situation works just > fine for almost all users. The approach for a different partition is for > performance reasons (which most users don't have any negative feelings > about) and as such might be read as a "ricer" approach. > > But perhaps it would be more "lean" to just start with a wiki page (or > document) for alternative / better partitioning layouts, and when that has > stabilized then we can talk about Handbook integration, not? > > Wkr, > Sven Vermeulen > > Current solution works but causes a really slow portage tree when ages passes (I still have a machine with tree in / and is really really slow but, since it's used by my father at his job, I am unable to solve it :( ). And not, I don't think it's a ricer approach at all, it's for performance and for save a lot of disk space too. About the wiki page, I can only document reiserfs+tail usage as it's the one I use and I know, about other alternatives like using squashfs, loop mount... I cannot promise anything as I simply don't know how to set them. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El sáb, 31-03-2012 a las 02:35 -0700, Brian Harring escribió: > On Sat, Mar 31, 2012 at 08:44:02AM +, Sven Vermeulen wrote: > > On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote: > > > Looks then that there are several alternatives for portage tree, then, > > > maybe the option would be to add a note to Gentoo Handbook explaining > > > the cons of having portage tree on a standard partition and, then, put a > > > link to a wiki page (for example) where all this alternatives are > > > explained. > > > > > > What do you think about this approach? > > > > I don't like the "cons" approach, as it gives the impression that users are > > pushed into a negative solution, whereas the current situation works just > > fine for almost all users. The approach for a different partition is for > > performance reasons (which most users don't have any negative feelings > > about) and as such might be read as a "ricer" approach. > > For modern hardware w/ a modern kernel (or at least >=2.6.38 for the > dcache resolution optimizations)... does anyone actually have real > performance stats for this? > > If the notion is a seperate FS, one tailored to the portage tree's > usage models (tail packing for example), sure, grok that although I > question how much people really are getting out of it. > > In the past, situation definitely differed- I'm just wondering if the > gain is actually worth debating it, rather than just ignoring it (or > sticking it in a foot note for people trying to use durons). > ~harring > > I did performance stats one year ago or so, but I don't have time to redo all of them to simply confirm how behave now with recent kernel (in that time, I checked reiserfs, ext2 with multiple block sizes). Regarding disk space usage, it's still valid today for sure signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El sáb, 31-03-2012 a las 19:25 -0400, Walter Dnes escribió: > On Sat, Mar 31, 2012 at 10:42:50AM -0700, Zac Medico wrote > > On 03/31/2012 06:34 AM, Pacho Ramos wrote: > > > About the wiki page, I can only document reiserfs+tail usage as it's the > > > one I use and I know, about other alternatives like using squashfs, loop > > > mount... I cannot promise anything as I simply don't know how to set > > > them. > > > > Squashfs is really simple to use: > > > >mksquashfs /usr/portage portage.squashfs > >mount -o loop portage.squashfs /usr/portage > > Don't the "space-saving filesystems" (squashfs, reiserfs-with-tail, > etc) run more slowly due to their extra finicky steps to save space? If > you really want to save a gigabyte or 2, run "eclean -d distfiles" and > "localepurge" after every emerge update. I've also cobbled together my > own "autodepclean" script that check for, and optionally unmerges > unneeded stuff that was pulled in as a dependancy of a package that has > since been removed. > I have distfiles on a completely different dir and, using different partition for ages for portage tree hasn't show that space saving problems signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Packages up for grabs due bass retirement
El lun, 19-03-2012 a las 21:20 -0600, Ryan Hill escribió: > On Mon, 19 Mar 2012 09:34:22 +0100 > Pacho Ramos wrote: > > > El dom, 18-03-2012 a las 23:56 -0600, Ryan Hill escribió: > > > On Sun, 18 Mar 2012 20:25:58 +0100 > > > Pacho Ramos wrote: > > > > > > > Due his retirement the following packages need a new maintainer: > > > > > > > app-doc/ebookmerge > > > > > > This is something bass wrote that grabs html manuals from > > > http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to > > > http://code.google.com/p/htmlhelp/). I don't really see the usefulness > > > of it > > > since almost all of the content is just html versions of standard info/man > > > pages. Anyways, it's completely broken as-is. > > > > > > > > > > I also though it could be treecleaned until I saw patches to fix that > > issues are included in: > > https://bugs.gentoo.org/show_bug.cgi?id=388927 > > Okay, I suppose people do use it. I'd like to start an app-doc herd (I think > vapier and me have half of app-doc/* covered anyways). This would fit in > there. In the meantime I'll take it. > > Any news on this herd creation? Looks like that package is still in maintainer-needed domain, for now I have fixed all his bugs I think, but better create that one for this and other packages that could benefit from active maintainers :) Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About maintaining sci-physics/abinit
El lun, 19-03-2012 a las 10:22 +0100, Pacho Ramos escribió: > Hello > > As talked some time ago with Donnie, sci-physics/abinit is hard to > maintain and, then, he would like to lastrite it after moving package to > sci overlay because looks like nobody from sci team wants to take it. > > If anybody is willing to help with maintaining abinit, could he take it? > If not, could anybody with commit access to sci overlay to move abinit > to it and let us lastrite it from main tree? > > Thanks a lot Maybe we could mask it for removal anyway as looks nobody wants to maintain it and our current versions are really old :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?
El lun, 19-03-2012 a las 09:37 +0100, Pacho Ramos escribió: > El lun, 19-03-2012 a las 13:32 +0900, Naohiro Aota escribió: > > Hi, > > > > It is great to hear Jack is willing to join cjk herd. I can help Jack > > working on cjk bugs. But, to be honest, I'm not familiar with recruiting > > process so I need some devs to do or to help me on the recruiting. > > > > Also I've read the "Mentor Guide" [1] and found "your project lead must > > be CC'd". I'm concerning about this "project". Does he need some project > > to join in? or is it just enough to join cjk herd? > > > > [1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml > > I think joining to cjk would be enough :-/ > > > > > Pacho Ramos writes: > > > > > El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió: > > > > > >> I'd like to help with this and will take a look at the bug below. I'd > > >> like to be part of the cjk herd as well. > > >> > > >> On 03/05/12 05:56, Samuli Suominen wrote: > > >> > Really need a reply on http://bugs.gentoo.org/405777 and nobody seems > > >> > to > > >> > be listening the cjk@ alias > > >> > > > >> > Should I just roll a dice and CC arch's? > > >> > > >> > > >> > > >> Thanks, > > >> > > > > > > Will CC cjk team then to let them know you are interested to join (looks > > > like there are four devs in cjk alias...) > > Any updates on this? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Doubts about need for "ewarn" when strip-linguas is used
El vie, 09-03-2012 a las 09:00 +0100, Pacho Ramos escribió:
> El mar, 06-03-2012 a las 11:46 +0100, Pacho Ramos escribió:
> > I usually read messages in /var/log/portage/elog/summary.log to simply
> > warn me about "es es_ES" LINGUAS not being supported by that package.
> > That comes from eutils.eclass inside strip-linguas:
> > ewarn "Sorry, but ${PN} does not support the LINGUAS:" ${nols}
> >
> > Is this warning really required, personally I know a lot of packages
> > that don't support spanish translations and I get no warning from them
> > (as they don't use strip-linguas). When I set LINGUAS variable in my
> > make.conf I assume a lot of packages won't support spanish translations,
> > and I see no point on being informed about that for some packages using
> > strip-linguas.
> >
> > What do you think?
>
> OK with dropping message completely or use "einfo" instead of "ewarn"?
Just done
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] enable verbose build whenever it's possible
El sáb, 05-11-2011 a las 21:03 -0600, Ryan Hill escribió: > On Sat, 5 Nov 2011 21:00:32 +0100 > Maciej Mrozowski wrote: > > > > I've seen too many bugs reports today that gave me cute, colorful > > > build.logs and almost no information about underlaying bug... > > > > That's usually because users sometimes attach only "relevant" parts of > > build > > log (well, relevant according to their taste = last lines, even when they > > use > > parallel compilation). > > I think you're confusing build log with build output. > > > Any particular example of bug report with entire build log from cmake-utils > > in > > fancy mode, and still being unable to locate the problem? > > > > I ask, because we're appending summary just after configure phase to make > > vorbose logging of whole build process unecessary. > > How are you supposed to debug a compile or linker error without the compiler > command line? > > How all this ended up? It would still be nice to have verbose output enabled by default (even people being able to use emerge --quiet to silent it) to check for undesired flags (like -Werror, -DG_DISABLE_DEPRECATED...) easily :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] enable verbose build whenever it's possible
El lun, 02-04-2012 a las 15:34 -0700, Zac Medico escribió: > On 04/02/2012 03:24 PM, Pacho Ramos wrote: > > How all this ended up? It would still be nice to have verbose output > > enabled by default (even people being able to use emerge --quiet to > > silent it) to check for undesired flags (like -Werror, > > -DG_DISABLE_DEPRECATED...) easily :) > > We've got a feature request bug about detecting -Werror here: > > https://bugs.gentoo.org/show_bug.cgi?id=409955 But that is the bug I was also waiting for ;), the problem is that it needs verbose output :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About maintaining sci-physics/abinit
El mar, 03-04-2012 a las 08:43 +0200, justin escribió: > On 03/04/12 00:11, Pacho Ramos wrote: > > El lun, 19-03-2012 a las 10:22 +0100, Pacho Ramos escribió: > >> Hello > >> > >> As talked some time ago with Donnie, sci-physics/abinit is hard to > >> maintain and, then, he would like to lastrite it after moving package to > >> sci overlay because looks like nobody from sci team wants to take it. > >> > >> If anybody is willing to help with maintaining abinit, could he take it? > >> If not, could anybody with commit access to sci overlay to move abinit > >> to it and let us lastrite it from main tree? > >> > >> Thanks a lot > > > > Maybe we could mask it for removal anyway as looks nobody wants to > > maintain it and our current versions are really old :/ > > Oh I am sorry for not replying. > We have a contributor who is doing a great job and maintains it in the > sci overlay. As there is currently no active contribution from the > developer teams site I would vote for removal and help Honza with his > contributions outside the tree. > > justin > Done: https://bugs.gentoo.org/show_bug.cgi?id=410639 Best regards signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due mrness retirement
Due his retirement the following packages need a new maintainer: dev-util/dialogblocks dev-util/helpblocks net-mail/sendEmail net-misc/openswan net-misc/taylor-uucp Thanks for taking them signature.asc Description: This is a digitally signed message part
[gentoo-dev] About how to handle wxGTK based packages with gnome profiles
Currently gnome profiles enable automatically "gtk" USE flag and, then, most gtk based GUIs are installed by default on systems using that profile. A special situation occurs when the package is based in wxGTK as explained in: https://bugs.gentoo.org/show_bug.cgi?id=411053 Currently, packages like mkvtoolnix simply builds without no gui at all when using gnome profile because its gui is build with "wxwidgets" USE flag. At first, I suggested to move from wxwidgets to "gtk" USE flag for that package because that wxwidgets based gui is the only gtk gui offered by that package. The problem is that their maintainers disagree with that approach as explained in referred bug report. Other option would be to enable "wxwidgets" by default for that profiles. What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About how to handle wxGTK based packages with gnome profiles
El mar, 10-04-2012 a las 09:12 +0200, "Paweł Hajdan, Jr." escribió: > On 4/10/12 8:58 AM, Pacho Ramos wrote: > > Other option would be to enable "wxwidgets" by default for that > > profiles. > > I prefer this. Changing USE flag meaning in a counter-intuitive way (to > let "gtk" mean "wxwidgets") would seem frustrating to me. > > With "wxwidgets" enabled by default people will get the most likely > desired result (i.e. GUI) "out of the box", and setting USE="-wxwidgets" > will have desired effect. > > Note that with USE="gtk" really meaning USE="wxwidgets", -wxwidgets > would have no effect on such a package, which is the potentially > surprising behavior I mentioned earlier. > OK, looks like I misunderstood how wxwidgets work and most opinions point to enable wxwidgets by default in gnome profiles, ok with that solution? signature.asc Description: This is a digitally signed message part
[gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
Hello From time to time I see old bug reports that are still wrongly opened and referring to old packages no longer in the tree. Would be possible to add a way to periodically check for bugs referring in summary to obsolete packages and, then, allow us to have a cleaner bug list? If the bug is referring to an overlay, it should state that in summary (like we do with [gnome-overlay] bugs) and skip checking for them. Thanks a lot signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages maintained by trapni need a co-maintainer
Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: dev-util/ciabot-svn media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin sys-apps/newrelic-sysmond signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages maintained by mduft need a co-maintainer
Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: app-portage/prefix-chain-setup net-proxy/cntlm sys-apps/prefix-chain-utils sys-devel/parity sys-libs/itx-bind sys-libs/suacomp signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
El sáb, 14-04-2012 a las 14:24 +0300, Samuli Suominen escribió: > On 04/14/2012 02:16 PM, Pacho Ramos wrote: > > Due long devaway, his packages need a co-maintainer, feel free to add to > > metadata if you want. Thanks: > > dev-util/ciabot-svn > > media-sound/teamspeak-client-bin > > media-sound/teamspeak-server-bin > > sys-apps/newrelic-sysmond > > > > I believe it's time to lastrite teamspeak* because they link against > mysql libraries with SONAME we don't ship anymore > Therefore rendering the packages useless > > - Samuli > > Fine with me if nobody wants to take care of that package and fixing it soon signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
El sáb, 14-04-2012 a las 12:42 -0300, Alexis Ballier escribió: > On Sat, 14 Apr 2012 13:02:27 +0200 > Pacho Ramos wrote: > > > Hello > > > > From time to time I see old bug reports that are still wrongly opened > > and referring to old packages no longer in the tree. Would be possible > > to add a way to periodically check for bugs referring in summary to > > obsolete packages and, then, allow us to have a cleaner bug list? > > -1, you really cant automate this. > > - for eg, keyword req, the version doesnt really matter and is usually > just there to help but should really be read as latest version; > closing/ignoring the bug while the latest version still lacks the > keywords is just wrong. > - for stablereq, that's a different story > > - for other bugs, some may have been fixed independently upstream, but > usually, they dont fix by themselves, so if a bug didnt get > attention, chances are its still valid. > > > moreover, doing this, you'll just encourage people not to fill the > version > > > IOW: If you want a cleaner bug list, ignore stable/kw reqs, then pay > attention to your bugs and fix them :) > > A. > > It's not for versions, only package names (there are still bugs referring to already removed packages for months) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 02:47 -0600, Ryan Hill escribió:
> > > > From time to time I see old bug reports that are still wrongly opened
> > > > and referring to old packages no longer in the tree. Would be possible
> > > > to add a way to periodically check for bugs referring in summary to
> > > > obsolete packages and, then, allow us to have a cleaner bug list?
>
> How exactly would you do this? Maintain a list of all packages ever removed
> from the tree? What if the package name is a common word? What about bugs
> requesting a previously removed package be re-added? Or a different
> project using the same name?
Well, I currently manually do eix searching to check it, maybe would be
a way to compare eix outputs with "${CATEGORY}/${PKGNAME}" from bug
summaries (bugs without that naming structure would be uncovered by
this, but we would still be able to easily check for obsolete bug
reports).
Regarding bugs asking package to be readded, that bugs should be
assigned to maintainer-wanted and, then, could be filtered.
>
> > It's not for versions, only package names (there are still bugs
> > referring to already removed packages for months)
>
> The person dumping the package should be checking for open bugs at the time
> of removal.
>
>
I agree... but it's usually forgotten as I have seen
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] About validate_desktop_entries in eutils.eclass
Hello I am unsure about validate_desktop_entries() utility. It's currently provided by eutils.eclass and only called by net-firewall/fwbuilder. Shouldn't this be moved to a "qa" check? Current way is pretty useless as it's not used by most of packages, and calling it from a lot of eclasses/ebuilds doesn't sound me like a good idea. What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 11:55 +0200, Pacho Ramos escribió:
> El dom, 15-04-2012 a las 02:47 -0600, Ryan Hill escribió:
> > > > > From time to time I see old bug reports that are still wrongly opened
> > > > > and referring to old packages no longer in the tree. Would be possible
> > > > > to add a way to periodically check for bugs referring in summary to
> > > > > obsolete packages and, then, allow us to have a cleaner bug list?
> >
> > How exactly would you do this? Maintain a list of all packages ever removed
> > from the tree? What if the package name is a common word? What about bugs
> > requesting a previously removed package be re-added? Or a different
> > project using the same name?
>
> Well, I currently manually do eix searching to check it, maybe would be
> a way to compare eix outputs with "${CATEGORY}/${PKGNAME}" from bug
> summaries (bugs without that naming structure would be uncovered by
> this, but we would still be able to easily check for obsolete bug
> reports).
>
> Regarding bugs asking package to be readded, that bugs should be
> assigned to maintainer-wanted and, then, could be filtered.
>
> >
> > > It's not for versions, only package names (there are still bugs
> > > referring to already removed packages for months)
> >
> > The person dumping the package should be checking for open bugs at the time
> > of removal.
> >
> >
>
> I agree... but it's usually forgotten as I have seen
>
Also, the idea is to simply generate a list with possible obsolete bug
reports, closing would still be done manually after checking for false
positives ;)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About validate_desktop_entries in eutils.eclass
El dom, 15-04-2012 a las 16:02 +0200, Michał Górny escribió: > On Sun, 15 Apr 2012 11:59:50 +0200 > Pacho Ramos wrote: > > > I am unsure about validate_desktop_entries() utility. It's currently > > provided by eutils.eclass and only called by net-firewall/fwbuilder. > > Shouldn't this be moved to a "qa" check? Current way is pretty useless > > as it's not used by most of packages, and calling it from a lot of > > eclasses/ebuilds doesn't sound me like a good idea. > > > > What do you think? > > Agreed. It should be in repoman. > The check needs to be run over desktop file going to be installed, not sure how repoman can handle it, it looked to me more like a emerge job (like is done with other qa checks run before installation) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 17:47 +0200, Marcin Mirosław escribió: > W dniu 2012-04-14 13:02, Pacho Ramos pisze: > > Hello > > > > From time to time I see old bug reports that are still wrongly > > opened and referring to old packages no longer in the tree. Would > > be possible to add a way to periodically check for bugs referring > > in summary to obsolete packages and, then, allow us to have a > > cleaner bug list? > > Hi, > what about siutation package was removed from tree. After sometime > other maintainer wants to put this package to the tree again, > shouldn't fix those bugs before doing this? > Marcin > As that results will simply be used to generate a list, it will be a good opportunity to really check that developer is taking care of it (I have also seen a lot of cases where a dev has a bug for this assigned to him for months without action) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
El dom, 15-04-2012 a las 19:10 +0300, Samuli Suominen escribió: > On 04/15/2012 06:47 PM, Marcin Mirosław wrote: > > W dniu 2012-04-14 13:02, Pacho Ramos pisze: > >> Hello > >> > >> From time to time I see old bug reports that are still wrongly > >> opened and referring to old packages no longer in the tree. Would > >> be possible to add a way to periodically check for bugs referring > >> in summary to obsolete packages and, then, allow us to have a > >> cleaner bug list? > > > > Hi, > > what about siutation package was removed from tree. After sometime > > other maintainer wants to put this package to the tree again, > > shouldn't fix those bugs before doing this? > > Marcin > > > > > > When package foobar gets removed from Portage, the remaining bugs > affecting foobar gets closed with resolution WONTFIX/OBSOLETE/FIXED > depending on type of the bug. > When package foobar gets readded to Portage, the maintainer needs to > check also for closed bugs. > That's how it is now, and the workflow wouldn't change with this proposal. > > So you are right, but irrelevant to the /topic in hand. > > - Samuli > > The problem is that, in reality, some bugs are forgotten and are keep opened. Currently, I manually check for them, but it's sometimes hard to do this manually. The idea of generating a QA report (like others in http://qa-reports.gentoo.org/) would allow me to easily review that list periodically to check that obsolete bugs are closed. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About how to handle wxGTK based packages with gnome profiles
El mié, 11-04-2012 a las 13:02 +0300, Samuli Suominen escribió: > On 04/11/2012 09:12 AM, Ryan Hill wrote: > > On Tue, 10 Apr 2012 22:21:20 +0200 > > Pacho Ramos wrote: > > > >> OK, looks like I misunderstood how wxwidgets work and most opinions > >> point to enable wxwidgets by default in gnome profiles, ok with that > >> solution? > > > > As I mentioned in the bug I'd like it default for desktop. There's nothing > > inherently "gnome" about wxwidgets other than the fact that it uses gtk+ > > widgets. If the idea is that you won't get any gui at all if wxwidgets > > isn't > > enabled (and I can't think of any packages where this isn't true) then kde > > users should be included too. > > > > > > +1 > > wxwidgets is not limited to gnome users, so goes to > profiles/targets/desktop/make.defaults > OK then to enable wxwidgets in desktop profile? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About how to handle wxGTK based packages with gnome profiles
El dom, 15-04-2012 a las 23:58 -0600, Ryan Hill escribió: > On Sun, 15 Apr 2012 18:59:11 +0200 > Pacho Ramos wrote: > > > OK then to enable wxwidgets in desktop profile? > > Yes. > Just done signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El lun, 16-04-2012 a las 03:04 +0200, Jeroen Roovers escribió:
> On Sun, 15 Apr 2012 11:55:04 +0200
> Pacho Ramos wrote:
>
> > Well, I currently manually do eix searching to check it, maybe would
> > be a way to compare eix outputs with "${CATEGORY}/${PKGNAME}" from bug
> > summaries (bugs without that naming structure would be uncovered by
> > this, but we would still be able to easily check for obsolete bug
> > reports).
>
> I only started fixing summaries to include valid, canonical
> cat/pkg[-ver] strings a few years ago because searching for a full
> atom in bugzilla's search would otherwise (and still does) fail.
>
> Before that it was mayhem, and it's mainly the older bugs you appear be
> worried about. Having a list of bugs to fix the cat/pkg for would have
> more uses than the one you're interested in.
>
>
> jer
>
>
I obviously agree, but both suggestions are not mutually exclusive I
think :)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by mduft need a co-maintainer
El lun, 16-04-2012 a las 11:00 +0200, Michael Haubenwallner escribió: > > On 04/14/2012 01:30 PM, Pacho Ramos wrote: > > Due long devaway, his packages need a co-maintainer, feel free to add to > > metadata if you want. Thanks: > > app-portage/prefix-chain-setup > > sys-apps/prefix-chain-utils > > Even if prefix-chaining most likely is broken ATM in prefix-portage, > (IMO) they still belong to prefix herd. Why have they shown up at all? > I probably missed prefix there when running epkginfo -Hm over mduft packages > > sys-libs/suacomp > > sys-devel/parity > > sys-libs/itx-bind > > Added myself, target Interix/Windows only. > Not sure if we can/want/should take them to prefix herd. > > > net-proxy/cntlm > > Still open. > > /haubi/ > > signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages inside lcd herd up for grabs
As lcd herd is empty for some time, these are the packages that are for grabs now: app-misc/g15mpd app-misc/glcdprocdriver app-misc/lcd-stuff app-misc/lcd4linux app-misc/lcdproc dev-libs/luise-bin dev-libs/serdisplib media-libs/libirman I will move them to maintainer-needed (keeping lcd herd and it CCed to allow the herd to revive in the future more easily) in a week. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About adding a way to check for bugs referring to no longer existing packages in the tree
El lun, 16-04-2012 a las 10:40 +0200, Pacho Ramos escribió:
> El lun, 16-04-2012 a las 03:04 +0200, Jeroen Roovers escribió:
> > On Sun, 15 Apr 2012 11:55:04 +0200
> > Pacho Ramos wrote:
> >
> > > Well, I currently manually do eix searching to check it, maybe would
> > > be a way to compare eix outputs with "${CATEGORY}/${PKGNAME}" from bug
> > > summaries (bugs without that naming structure would be uncovered by
> > > this, but we would still be able to easily check for obsolete bug
> > > reports).
> >
> > I only started fixing summaries to include valid, canonical
> > cat/pkg[-ver] strings a few years ago because searching for a full
> > atom in bugzilla's search would otherwise (and still does) fail.
> >
> > Before that it was mayhem, and it's mainly the older bugs you appear be
> > worried about. Having a list of bugs to fix the cat/pkg for would have
> > more uses than the one you're interested in.
> >
> >
> > jer
> >
> >
>
> I obviously agree, but both suggestions are not mutually exclusive I
> think :)
This is another example I hit today:
https://bugs.gentoo.org/show_bug.cgi?id=247750
that would benefit from this QA report
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] About dropping webapps-unmaintained alias
It's simply pointing to maintainer-needed and no bug is assigned to it. If a webapp package is orphan, it should go to maintainer-needed directly I think The same for webapps-request, that is a link to maintainer-wanted Thanks :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo
El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
> On Mon, Apr 23, 2012 at 8:28 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> > Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
> >
> >> Title: The default JPEG implementation
> >
> > [...]
> >
> >> All users are recommended to migrate:
> >>
> >> # emerge -C media-libs/jpeg:0
> >> # emerge -1 media-libs/libjpeg-turbo
> >
> > That of course leaves the system without a jpeg library between the jpeg
> > unmerge and the completion of the libjpeg-turbo merge. If the build
> > process fails for some reason...
> >
> > There's no way to use portage's automatic block-resolving ability here to
> > avoid that, I take it?
> >
>
> This works for me.
>
> floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild N ] media-libs/libjpeg-turbo-1.2.0-r1 USE="-java
> -static-libs" 0 kB
> [uninstall ] media-libs/jpeg-8d USE="-static-libs"
> [blocks b ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
> media-libs/libjpeg-turbo-1.2.0-r1)
>
>
I guess it will work when jpeg is not in world file... maybe people
should be told to drop it and, then, let emerge do all the work
automatically.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] dev-embedded/tigcc needs an urgent bump
Our stable versions are broken for a long time, they even don't compile, but we cannot stable latest testing version because of a buffer overflow problem. A bump could help, but looks like embedded team doesn't have enough time for it. Is anybody interested in taking care of it? Its bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=tigcc&list_id=978701 Thanks signature.asc Description: This is a digitally signed message part
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
El vie, 27-04-2012 a las 21:12 +0100, Ciaran McCreesh escribió: > On Fri, 27 Apr 2012 21:58:24 +0200 > Michał Górny wrote: > > Of course, if we take the 'quick EAPI 5 route', it won't include > > anything useful. In the meantime, do we have a complete list of > > candidates for EAPI 5? > > Let's continue this on the PMS list. > > * user patches > > * EAPI parsing > > * the things that were left out of 4: > > + slot operator deps > > + profile IUSE > > * No -j1 for src_test > > * Remove deprecated stuff > > * Zero or one REQUIRED_USE operator > > These might be cheap now? > > * New bash version > > * Get a versionator replacement into the PM > Could: https://bugs.gentoo.org/show_bug.cgi?id=408693 be handled also? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
El dom, 29-04-2012 a las 13:54 +0300, Samuli Suominen escribió: > On 04/28/2012 01:17 PM, Michael Weber wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > According to upstreams homepage [1], > > the current tagged v1.99.09 does support xulrunner 11.0. > > There is no such thing as "separate" Xulrunner 11.0. > > There is Firefox 11.0 but upstream stopped splitting it from Firefox and > our Firefox package doesn't ship with pkg-config files for it. > > So chmsee upstream very much failed... He should switch to something > else, like webkit-gtk or gtkhtml. > > - Samuli > > The problem is that looks like other major distributions are still providing xulrunner (from firefox): http://pkgs.fedoraproject.org/gitweb/?p=xulrunner.git;a=tree http://download.opensuse.org/factory/repo/src-oss/suse/src/xulrunner-12.0-1.1.src.rpm http://packages.debian.org/sid/xulrunner-10.0 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dev-embedded/tigcc needs an urgent bump
El lun, 23-04-2012 a las 20:35 +0200, Pacho Ramos escribió: > Our stable versions are broken for a long time, they even don't compile, > but we cannot stable latest testing version because of a buffer overflow > problem. A bump could help, but looks like embedded team doesn't have > enough time for it. Is anybody interested in taking care of it? > > Its bugs: > https://bugs.gentoo.org/buglist.cgi?quicksearch=tigcc&list_id=978701 > > Thanks Or maybe we should simply treeclean it if nobody is willing to fix/maintain it and since nothing in the tree needs it... signature.asc Description: This is a digitally signed message part
[gentoo-dev] About remembering to block bug 406437 for glib-2.32/gtk+-3.4 issues
Hello Please remember to make your bugs related with glib-2.32/gtk+-3.4 issues block bug 406437. That will allow us to get needed things stabilized in the future when we stabilize newer glib/gtk+ Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About validate_desktop_entries in eutils.eclass
El lun, 30-04-2012 a las 10:05 -0700, Zac Medico escribió: > On 04/29/2012 09:45 AM, Petteri Räty wrote: > > On 15.04.2012 17:12, Pacho Ramos wrote: > >> El dom, 15-04-2012 a las 16:02 +0200, Michał Górny escribió: > >>> On Sun, 15 Apr 2012 11:59:50 +0200 > >>> Pacho Ramos wrote: > >>> > >>>> I am unsure about validate_desktop_entries() utility. It's currently > >>>> provided by eutils.eclass and only called by net-firewall/fwbuilder. > >>>> Shouldn't this be moved to a "qa" check? Current way is pretty useless > >>>> as it's not used by most of packages, and calling it from a lot of > >>>> eclasses/ebuilds doesn't sound me like a good idea. > >>>> > >>>> What do you think? > >>> > >>> Agreed. It should be in repoman. > >>> > >> > >> The check needs to be run over desktop file going to be installed, not > >> sure how repoman can handle it, it looked to me more like a emerge job > >> (like is done with other qa checks run before installation) > > > > There's actually already code in repoman that runs > > desktop-file-validate. It of course only works for installed packages. > > Someone could make it run runtime too. > > The repoman code works on $FILESDIR. It looks like we also want to run > it after src_install. > > Also, it looks like we might need to handle a special case for Konqueror > Service Menus: > > https://bugs.gentoo.org/show_bug.cgi?id=414125 Yes, I would like to also check other desktop files than those coming from FILESDIR signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1
El sáb, 05-05-2012 a las 09:49 +0200, Kacper Kowalik escribió: > On 04.05.2012 18:30, hasufell wrote: > > # @ECLASS-VARIABLE: CMAKE_VERBOSE > > # @DESCRIPTION: > > # Set to enable verbose messages during compilation. > > > > By default this is deactivated which is inconvenient imo and results in > > pastes having minimum information. > > I have to tell users every time to recompile with CMAKE_VERBOSE=1 so > > that I have proper information on what is going on. > > > > Are there any arguments against this being default? > > > Hi, > It's been discussed previously here [1] > with nack from cmake-utils.eclass maintainers and general conclusion > that's too "expensive" to write to stdout :/ > If you're gonna make it happen this time, I'll owe you a beer... > Cheers, > Kacper > > [1] > http://archives.gentoo.org/gentoo-dev/msg_1b58b577fde07f7735ae6b9eb34885be.xml > That would be a good step to get https://bugs.gentoo.org/show_bug.cgi?id=384193 implemented some day ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
El dom, 06-05-2012 a las 07:33 -0400, Rich Freeman escribió: > On Sun, May 6, 2012 at 5:37 AM, Michał Górny wrote: > > > > I don't think even heavyweight DE/WM usually needs ldap... > > > > Tend to agree. I don't think we want to create a new profile every > time we want to change one of the flags. > > Some other questionable ones: > emboss - Adds support for the European Molecular Biology Open Software Suite > firefox - probably OK for what it does now, but not everybody uses it > xulrunner - not even used now > > There will always be some level of variation if you are looking at > single flags. What matters isn't coming up with profiles that exactly > match all of our users, but rather ones that are good for 80+% of > them. > > As far as ldap goes, if we wanted an "enterprise desktop" profile that > might be a good fit for such a configuration. I agree that -ldap > isn't really a lightweight desktop so much as a normal one. If you > really wanted "lightweight" then you'd probably not be running desktop > at all, or the regular desktop vs kde/gnome. Maybe "desktop" should be more lightweight oriented and for people (like me) wanting more, use gnome/kde instead (or create xfce/lxde... if they need other flags...) > > The bottom line is that we don't need 47 different profile targets - > there will always be a "use" for 1 more. That's why we all run Gentoo > - we aren't bound by the decisions made for us by the package > maintainers. > > Rich > > signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: > eclass/ has a ChangeLog > > (and this is getting old that everyone keeps ignoring it, I've proposed > punting the ChangeLog from eclass/ directory once, and repeating it now) > Maybe we could punt ChangeLog from eclass/ and generate it automatically from commit messages signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
El dom, 15-04-2012 a las 17:09 +0200, Philipp Riegger escribió: > On Sat, 14 Apr 2012 14:24:25 +0300 > Samuli Suominen wrote: > > > On 04/14/2012 02:16 PM, Pacho Ramos wrote: > > > Due long devaway, his packages need a co-maintainer, feel free to > > > add to metadata if you want. Thanks: > > > dev-util/ciabot-svn > > > media-sound/teamspeak-client-bin > > > media-sound/teamspeak-server-bin > > > sys-apps/newrelic-sysmond > > > > > > > I believe it's time to lastrite teamspeak* because they link against > > mysql libraries with SONAME we don't ship anymore > > Therefore rendering the packages useless > > Can you elaborate on this? I have these ebuilds in my local overlay, > renamed to install the latest versions. So maybe a (really simple) > version bump would be enough. > > Philipp > > Well, in tree versions are still buggy and outdated, I would vote for either: 1. Mask them for removal (server is already hardmasked, but client not). 2. Proxy maintain them if anyone volunteers. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: > Am Sonntag, 6. Mai 2012, 14:03:02 schrieb Pacho Ramos: > > El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: > > > eclass/ has a ChangeLog > > > > > > (and this is getting old that everyone keeps ignoring it, I've proposed > > > punting the ChangeLog from eclass/ directory once, and repeating it now) > > > > Maybe we could punt ChangeLog from eclass/ and generate it automatically > > from commit messages > > Maybe we could punt ChangeLogs generally and generate them from commit > messages... > > err... hasn't this been discussed before? > > :o( > > Well, in this case I intentionally was referring only to eclass/ as maybe it can be implemented for it even handling normal packages as currently signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 19:28 +0200, Fabian Groffen escribió: > On 06-05-2012 19:23:47 +0200, Pacho Ramos wrote: > > El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: > > > Maybe we could punt ChangeLogs generally and generate them from commit > > > messages... > > > > > > err... hasn't this been discussed before? > > > > > > :o( > > > > Well, in this case I intentionally was referring only to eclass/ as > > maybe it can be implemented for it even handling normal packages as > > currently > > The implementation has never been the problem. It's that people want to > be able to edit (correct) the messages. > > In that case... :-( Thanks for noticing signature.asc Description: This is a digitally signed message part
