Zac Medico wrote:
With the introduction of autobuilds, would it be a good idea to rename
the profiles so that they don't have the date association? This does
seem to confuse a number of new users who will appear asking where the
2009 profiles are.
Maybe, but you could also look at this as a
Samuli Suominen wrote:
You do realize all this discussion is now pointless as 10.0 profiles are
in place already? :-p
So what do we do?
Sebastian
Josh Saddler wrote:
So what do we do?
http://www.gentoo.org/doc/en/gentoo-upgrading.xml
Please give more precise content pointers or summarize what you want to
point out.
Sebastian
Alexey Shvetsov wrote:
Hi all!
seems smoltSendProfile doesnt work with unicode locales =)
100%] x11-wm/twm-1.0.4
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/smolt/client/sendProfile.py,
line 211, in module
% excerpts
UnicodeDecodeError: 'ascii' codec
Mike Frysinger wrote:
10.0 is retarded
How would you like the problem to be addressed?
Sebastian
Mounir Lamouri wrote:
It's even worst when we try to use ACCEPT_LICENSE to have a free
operating system. Let's suppose 'free' in fsf free and osf free,
LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most
LGPL-2 licensed packages in the tree are LGPL-2+ actually.
Are you aware
Christian Faulhammer wrote:
I have just committed a patch [1] that could fix it. Please try again
with the latest HEAD and let me know how it works for you.
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/smolt/client/sendProfile.py,
line 215, in module %
Mounir Lamouri wrote:
However I do notice that GPL-2+ could make things easier.
Why not introduce a license group for it like @GPL-2+ or so, instead?
That would be transparent and use existing means.
I don't understand where the black magic is.
It would be in the implementation and in the
Ulrich Mueller wrote:
IMHO the main disadvantage is that ebuilds would have to be converted
to EAPI-4 for this,
Why do they _have_ to? I understand that it's optional and that we can
take time with it until a new license (e.g. GPL-4) arrives.
Also, scripts/tools can help with the transition.
Hello there!
Among other information the Gentoo page at DistroWatch [1] displays a
table on about 200 selected packages [2] and how up to date Gentoo is
per package. I assume that DistroWatch is still one of the first places
people go to get a feeling for a Distro they heard about, besides
Ryan Hill wrote:
Personally I don't see how gaming the system helps us in any way.
I was afraid it could be read in such a way. Handing out fake version
numbers would be much easier, wouldn't it? I want every single package
int he tree to be stable, up to date and polished. But as our
Aaron Bauman wrote:
Sebastian,
I definitely admire your point and know that through your tracking and
Google
SoC project you have good visibility on this I do however have to disagree.
As much as I enjoy the open source community and admire the products they put
out I do believe
Marijn Schouten (hkBst) wrote:
koffice (2.0.2) 1.6.3
There has been koffice-meta-2.0.2 for a while.
Good catch, thank you!
Sebastian
Jesús Guerrero wrote:
On Sun, 13 Sep 2009 06:47:27 -0400, Richard Freeman ri...@gentoo.org
Right now it is at least a little painful to get set up with an overlay.
No, it's a matter of using layman -a whatever
I think Richard was including the manual setup required to use layman
and the
Richard Freeman wrote:
Personally, I like the overlay idea, but right now it just isn't
necessary. In theory proxy maintainers work almost as well, and we're
not really making heavy use of this model right now.
I disagree about this. One of the reasons my overlay is fun to me is
because I am
Alexander Færøy wrote:
Second issue: I want foopackage and barpackage, but not your hacked gcc
Overlays can overshadow tree packages, which can have undesired effects.
Support for overlay information in package.mask?
Once we have repository-specific atoms we get that for free.
Maybe we can
Dale wrote:
Good question. How would a person know if distrowatch leads people to
Gentoo or not? It's not like there is really any way to find out.
- analysing referrer logs
- doing polls
sebastian
Duncan wrote:
Agreed. Yes, overlays are perhaps a bit more trouble to setup than
simply maintaining normal tree updates once setup. But let's get some
context here. layman's no difficulty at all, really, when compared to
the ordinary stuff we expect Gentoo users to do all the time.
Ciaran McCreesh wrote:
Not quite. If both an overlay and the main tree provide foo-1.2,
masking foo-1.2::overlay in Portage would end up masking every foo-1.2.
Why?
You also need proper multiple repository support to make it work;
merely adding repo dep specs on top of a pure overlay model
Ciaran McCreesh wrote:
Because an overlay model has only a single foo-1.2. Think of it like
stacks of paper. You've got your main repository:
::gentoofoo-1.1 foo-1.2 foo-1.3
and on top of that you put your overlay:
::extras foo-1.2 foo-1.4
::gentoo foo-1.1
Zac Medico wrote:
It shouldn't be too difficult to tweak portage so that multiple
ebuilds of the same version from different repositories are visible
to portage's dependency resolver. Currently, it uses a collection of
3 repositories to resolve dependencies: installed, ebuild, and
binary
Fabian Groffen wrote:
Should we start filing bugs on these issues? In the end, they are
broken scripts on the system. Is there interest for porting the Prefix
shebang QA check to normal Portage?
Sounds useful to me, my vote for it.
Sebastian
Patrick Lauer wrote:
I'd like to collect your success stories, endorsements and case studies so we
can present to the rest of the world how using Gentoo makes your life easier
and is totally awesome.
I had a similar thing in mind, too. Nice to see, you're goinf for it.
I would suggest
contact=sebast...@pipping.org
name=sping src=git://git.goodpoint.de/overlay-sping.git
status=unofficial
type=git
linkhttp://git.goodpoint.de/?p=overlay-sping.git/link
descriptionGentoo overlay of Sebastian Pipping/description
/overlay
volk...@gentoo.org wrote:
I think we
should introduce a longdescription field even with a lang parameter
like we already have in metadata.xml.
Done.
http://git.goodpoint.de/?p=overlays-xml-specification.git;a=commit;h=c13a394fe1a868012548b2be5fb58359b3bc2891
Sebastian
Tiziano Müller wrote:
Am Montag, den 28.09.2009, 20:23 +0200 schrieb Sebastian Pipping:
repositories.xml
=
repo
name=sping
quality=experimental
status=unofficial
descriptionGentoo overlay
Ciaran McCreesh wrote:
On Mon, 28 Sep 2009 20:23:34 +0200
Sebastian Pipping webmas...@hartwork.org wrote:
Now please ask questions and let us know what you think.
Here's an alternative idea:
* Move the repository information into the overlays themselves. Require
overlays to provide
Fabian Groffen wrote:
Point remains that it looks in-consistant, for repo, name is an
attribute, while for owner it is a sub-element. Why having attributes
in the first place anyway?
It's closer to the original layman-global.txt which also makes the
converter scripts simpler (and faster) than
Ciaran McCreesh wrote:
On Wed, 30 Sep 2009 17:51:02 +0200
Sebastian Pipping webmas...@hartwork.org wrote:
At the moment moving overlay meta info into the overlays does not seem
like a good idea to. It would mean that any script working with
overlays needs to check the repo out to get
Zac Medico wrote:
I propose support for license groups in ebuilds then, I guess.
That seems like a reasonable solution. So, an ebuild can do
something like LICENSE=@GPL-2+ and that will expand to whatever
the definition of the GPL-2+ license group happens to be. When a new
version of GPL
Tiziano Müller wrote:
What if that metadata format changes later or is extended by
additional required entries?
How about using the power of xml and version the schemas? As long as the
metadata-file specifies the respective dtd/xsd/relaxng you know exactly
how to validate (and parse) it and
Tiziano Müller wrote:
A simple rule of thumb is: use attributes for values with predefined
contents, use elements otherwise. So, make name an element please.
Okay, let's give it a try.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sebastian Pipping wrote:
I have created another script yesterday that can auto-merge information
from gitosis.conf into repositories.xml. With that script in a Git hook
setting up new Git-based Gentoo-hosted overlays requires changes at only
My vote for it, sounds reasonable.
Sebastian
Thomas Sachau wrote:
In addition, i see a trend to enabled more more more USE flags (either over
profiles or via IUSE
+flag).
I'm not sure for how much of the IUSE=+foo cases this applies but I
can explain one of them:
In xfce-base/xfce4-session-4.6.1-r1 there is +fortune in IUSE
because
Patrick Lauer wrote:
Calling EAPI is ... well ... I can't even think of a place to start to
explain
how wrong it is. How on earth are you going to parse an eclass that supports
multiple EAPIs where one EAPI were to support features of bash 4?
The only way to do it would be to force bash 4
Torsten Veller wrote:
What's the status of the stats project? What's missing? What help is
needed?
Hello Torsten, thanks for your interest.
Let me quote myself from a recent reply on a similar question:
for the quickest summary possible these steps are needed:
- make me have and take time
Just a quick note:
The server on http://smolt.hartwork.org:45678/ is up again, it was down
yesterday.
Sebastian
On 12/24/09 05:53, Ronan Arraes Jardim Chagas wrote:
Nevertheless, the current portage ebuild
installs a wrong libpgf.pc, because it states that the include
directory is /usr/include but it really is /usr/include/libpgf (can
anyone fix it or should I open a bug?).
I would say open a bug as it
On 01/10/10 09:29, Arfrever Frehtes Taifersar Arahesis wrote:
I would like to suggest introduction of support for PYTHON_DEPEND variable,
which
would be a better replacement for NEED_PYTHON variable. NEED_PYTHON variable
does not allow to specify that e.g. only versions of Python 2 are
PYTHON_DEPEND=2:2.5:2.6
Dependency on Python 2.6 or 2.5.
The colon (':') has two different semantics here.
This violates different things should look different.
You are designing a language here. Please improve the proposal.
Sebastian
On 01/11/10 09:47, Arfrever Frehtes Taifersar Arahesis wrote:
2010-01-11 04:55:02 Sebastian Pipping napisał(a):
PYTHON_DEPEND=2:2.5:2.6
Dependency on Python 2.6 or 2.5.
The colon (':') has two different semantics here.
The colon is only separator of components, so it has the same
Hello!
By default layman currently stores overlays into
/usr/local/portage/layman
(was /usr/portage/local/layman before that).
As of bug 253725 [1] that's not without problems.
I would like to get it right with the next switch.
Would
/var/lib/layman
do well? /var/cache/layman seems
On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
- From the alternatives, /var/lib/layman doesn't sound right. If
/var/cache/layman doesn't work, what about /var/spool/layman instead?
Okay, how about
/var/spool/layman
then? Any objections?
Sebastian
On 01/16/10 05:39, Mike Frysinger wrote:
On Friday 15 January 2010 20:55:18 Sebastian Pipping wrote:
On 01/16/10 02:45, Mike Frysinger wrote:
the better idea
though would be to split your stuff along the proper lines.
cache files = /var/cache/layman/
as i said: it's not a normal cache
On 01/16/10 12:17, Fabian Groffen wrote:
How about storing it in DISTDIR (like metadata.xml)? Or storing it
somewhere in the rsync image?
I'm not really sure what you have in mind.
Can you make it a bit more visual for me?
Sebastian
On 01/16/10 13:56, Ben de Groot wrote:
anybody objecting to /var/layman ?
I like that.
it seems that
/var/layman
is the only location nobody has objected to, yet. i plan to go with
that atm. /var/lib/layman is my second favorite.
again, any objections?
sebastian
On 01/16/10 19:31, Nirbheek Chauhan wrote:
Why not make it a configuration option, with the default as
/var/layman (or whatever you want)?
It is configurable already (see /etc/layman/layman.cfg)
#---
# Defines the directory where
On 01/16/10 23:46, Benedikt Böhm wrote:
One thing all you /usr naggers forget is, that /var cannot be shared
read-only via nfs (or bind mounts in case of virtual servers).
Why is that? Please tell more.
Sebastian
On 01/17/10 10:01, Ciaran McCreesh wrote:
I realise this is a lost cause, but... Repositories are databases, so
/var/db/ is your friend.
Right, that's a way you can see it.
Does anyone _strongly_ prefer
/var/db/layman
over
/var/layman
?
Sebastian
On 01/17/10 21:31, Thilo Bangert wrote:
/var/layman i dislike due to this sentence in the FHS:
Applications must generally not add directories to the top level of
/var. Such directories should only be added if they have some system-wide
implication[...]
isn't a package tree somehow
On 01/16/10 19:52, Peter Hjalmarsson wrote:
That is for the overlays, yeah?
But hov about the cache_*.xml files?
I think what he meant was that should layman really only has one
directory? One for cache (downloaded/downloadable lists of overlays?
in /var/cache/layman/?), one for the
On 01/18/10 01:38, Sebastian Pipping wrote:
On 01/17/10 21:31, Thilo Bangert wrote:
/var/layman i dislike due to this sentence in the FHS:
Applications must generally not add directories to the top level of
/var. Such directories should only be added if they have some system-wide
Maybe this flyer can help with brainstorming:
http://a3li.li/files/gentoo-flyer-en.pdf
Sebastian
for a proper review just
let me know.
Here we go:
===
Title: Layman storage path changed from version 1.3.0 on
Author: Sebastian Pipping sp...@gentoo.org
Content-Type: text/plain
Posted: 2010-02-25
Revision: 1
News-Item-Format: 1.0
On 02/25/10 01:15, Sebastian Pipping wrote:
===
Title: Layman storage path changed from version 1.3.0 on
Author: Sebastian Pipping sp...@gentoo.org
Content-Type: text/plain
Posted: 2010-02-25
Revision: 1
News-Item-Format
I agree that additional repoman checks can help to improve quality in
Gentoo...
It seems that currently neither metagen nor repoman check what I put in
for herd (i.e. if such a herd exists or not).
Does anyone feel like getting his hands on that or like teaming up on it?
Sebastian
Stop.
Is introduction of such a high level of bureaucracy really a good idea?
In my eyes it could backfire and make matters worse as people either
- start ignoring it due to high noise
- reduce people's activity below set permissions
To summarize presented proposal has a few points that may not
Hello!
I'm surprised that there is no keyword in Gentoo's bugzilla [1] to mark
bugs for bugday. Is there a good reason why such a keyword does not
exist? Would it be hard to set up?
Thanks,
Sebastian
[1] https://bugs.gentoo.org/describekeywords.cgi
On 02/27/10 17:22, Mark Loeser wrote:
I think the goal was to have http://bugday.gentoo.org/ fill this role
whenever i visit bugday.gentoo.org it takes minutes to load.
afair for the two bugdays i participated it didn't display anything
helpful (to me), especially: why does it show fixed bugs,
On 02/27/10 16:39, Roy Bamford wrote:
That sounds good. If it were an enumerated type bugs could be graded
for bugday too.
.e.g.
Novice
You need to have fixed a few
Intermediate
We don't have a clue.
I'm not suggesting any grades - those are just for illustration.
I had that idea
On 02/27/10 19:14, Roy Bamford wrote:
What would be the criteria for marking a bug as bugday?
I would say something along a yes to
Could this task fit for being solved by someone who
is not a Gentoo developer?
It's not precise, does it need to be?
Why whould it be any better than a
Quoting Ioannis Aslanidis aslani...@gmail.com:
I would prefer to keep the keyword for
Bugday Members to administer.
I don't think that sending mails would work well.
If you want extra control/QA for bugday team members
I would propose two different keywords: one for bugday
candidates and one
On 03/02/10 02:09, Duncan wrote:
... And here I'm proposing three:
BUGDAY(nomination)
BUGDAY-ACCEPTED (or whatever is thought appropriate)
NOBUGDAY (or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...)
The latter would be for nominated bugs that were declined as
On 03/02/10 02:32, Alec Warner wrote:
BUGDAY (nomination)
BUGDAY-ACCEPTED (or whatever is thought appropriate)
NOBUGDAY(or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...)
I think the last one is over-engineering a bit; bugzilla keywords are
not permanent
How are they not
On 03/01/10 22:17, Ioannis Aslanidis wrote:
getting control of bugday.gentoo.org and be able to upload our own
content would be great.
The current page is said to generate one XML request per bug listed on
the page for each request. From my experience trying to remove bugs
from that page
On 03/02/10 20:28, Nathan Zachary wrote:
This looks like overkill to me. One keyword should be enough, and for
supplementary information Status Whiteboard could be used.
I agree. Simply having the BUGDAY keyword should be sufficient, and
more information can be provided elsewhere in the
On 03/02/10 21:47, Alec Warner wrote:
I would recommend not hardcoding 10 seconds; but otherwise caching is good ;)
What do you propose?
Sebastian
On 03/04/10 10:35, Ciaran McCreesh wrote:
On Thu, 4 Mar 2010 10:32:47 +0100
Ulrich Mueller u...@gentoo.org wrote:
On Thu, 4 Mar 2010, Christian Faulhammer wrote:
My proposal would be to call it dev-scm and put all version
controls, direct frontends, plugins and the like into that.
I like the
On 03/04/10 17:38, Christian Faulhammer wrote:
Hi,
Sebastian Pipping sp...@gentoo.org:
Agreed, scm is a bad choice.
So it is really tracked in
http://bugs.gentoo.org/show_bug.cgi?id=56967 now. If there is
anything to comment do it there.
Is that a good idea?
Maybe we should restrict
On 03/04/10 15:52, Theo Chatzimichos wrote:
Hello
I have managed to split the desktop profile to gnome and kde submenus.
How about XFCE (and LXDE)?
The
result can be found in kde-crazy overlay (not in layman) [1]
If this is ever going to be used as a real overlay please set repo_name
to
Hello!
So now that we have a new category dev-vcs we need to move suitable
stuff over there. Moving packages is complex and error prone:
This mail tries to guide you through and summarize the process, please
read on.
HINT: Please keep CVS' radius of operation small to reduce risks.
0.
On 03/04/10 19:22, Arfrever Frehtes Taifersar Arahesis wrote:
All problems, which were blocking stabilization of Python 3, have been fixed.
Stabilization of Python 3.1.2 is currently scheduled on 2010-04-19.
#python on Freenode still reads It's too early to use Python 3.x.
Are they wrong?
Are
On 03/04/10 23:19, Christian Faulhammer wrote:
That is the normal procedure when pkgmoving a package. So nothing
special. :)
I'm a bit worried because I assume that moving packages is not an
everyday action for most developers.
- Pushing news out to Gentoo users (and developers)
For
On 03/04/10 22:38, Robin H. Johnson wrote:
This contains a critical bug...
cvs add and the matching commit aren't mentioned anywhere...
That's a valid complaint, yes.
I left it out knowingly, maybe not for the better.
Sebastian
Hello!
All of these tools had maintainer-needed in metadata.xml when I checked
yesterday:
dev-util/aegis
dev-util/archway
dev-util/cvsspam
dev-util/guilt
dev-util/stgit
dev-util/svk
dev-util/svnmailer
If anyone feels like adopting one or two of these: properly moving them
over to
On 03/05/10 18:10, Jeroen Roovers wrote:
4. Notify
=
[..]
This step should probably include correcting all open bug
reports' Summaries to point to the new category, so that CAT/PN can be
found using the simple search interface.
Good catch. Thanks for fixing those on monotone (and
On 03/04/10 23:11, Brian Harring wrote:
Random sidenote, anyone looked at using an alternate vcs to do the
work, then proxy it back? Specifically thinking of workflow like svk
(or in this case hg cvs,
https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS ). The
reason I ask is that
On 03/06/10 20:09, David Leverton wrote:
This sounds like the sort of thing Bugzilla's flags mechanism is for.
http://www.bugzilla.org/docs/2.22/html/flags-overview.html
Good idea!
What I wonder now is:
- Will it work with our very instance of Bugzilla?
- Can certain flag states be required
On 03/06/10 08:08, Petteri Räty wrote:
After the move is done could you please come up with a list of all the
things you needed to take into account and then work with me for example
to get it included in devmanual.
Good idea.
I opened a bug for it so we don't forget about it.
Hello!
There are a few patterns for potentially low hanging fruits among Gentoo
bugs:
SRC_URI errors
Missing depencies
...
What else?
Anything you look after repeatedly that doesn't take days to get it fixed?
Sebastian
On 03/08/10 18:08, Mark Loeser wrote:
What is this even in reference to? Its not at all clear what you are
trying to do.
Okay, sorry.
I was wondering what classes of bugs there are that are
- reoccuring (therefore beloning to a class or pattern)
- relatively easy to fix
- ideally suited
On 03/08/10 14:27, Markos Chandras wrote:
Documentation installation
There are few packages that call missing documents on dodoc commands
any idea how to find all these bugs?
sebastian
On 03/08/10 14:13, Róbert Čerňanský wrote:
On Mon, 08 Mar 2010 11:06:40 +0100
Sebastian Pipping sp...@gentoo.org wrote:
There are a few patterns for potentially low hanging fruits among
Gentoo bugs:
SRC_URI errors
Missing depencies
(Sorry for answering a developer targeted question
Hello!
Intro
=
The latest version of webalizer is 2.01 while upstream is at 2.21 by
now. The reason it's not been bumped in Gentoo is the two use flags
geoip and xtended.
The former alone pulls in a feature patch called geolizer, while the
latter pulls a feature patch called webalizer
Hello!
There are quite a few bugs open for it plus the latest version (1.50.18)
is not even in Gentoo but on SourceForge only.
Its upstream Gunnar left Gentoo due to lack of time recently.
As I got project admin rights for layman from Gunnar before I know that
a similar thing should be
Hello!
We have about 500 bump request open at the moment:
https://bugs.gentoo.org/buglist.cgi?quicksearch=bump
I assume that quite a few of them would be no big deal to their
maintainers in Gentoo.
Bugday is occupying the first Saturday of the month: how about bumpday
on the third Saturday of
On 03/10/10 06:00, Joshua Saddler wrote:
I'm prolly not the only one who feels this way, so you really need to pick
your bugs carefully!
Agreed, yes.
Bumpdays are otherwise a good idea, though I'm not sure why we need a
separate day for that in addition to our standard bugdays.
While
Done.
Three packages now, webalizer bumped.
- app-admin/geolizer
- app-admin/webalizer
- app-admin/webalizer-xtended
I'm 100% sure i broke something, please let me know what it is once you
found out ;-)
Sebastian
On 03/10/10 15:41, Mark Loeser wrote:
I don't even think the maintainer-needed ones should be bumped. Who
knows what bugs you are introducing into the tree. This is why things
eventually get treecleaned.
I purposely wrote no big deal _to their maintainers_ - I wonder why
everyone is so scare
On 03/10/10 14:59, Ben de Groot wrote:
I think it would be better to have it all happen on the same day. If those
are easy bumps, they fit very well with bugday. And those devs who
want to work on that, can then join the general bugday mayhem. ;-)
You might be spreading things too thinly
I was curious to see how far we have come so far:
Still to be moved
=
dev-util/aegis
dev-util/cola
dev-util/colorsvn
dev-util/cvs
dev-util/cvs2cl
dev-util/cvs2svn
dev-util/cvsd
dev-util/cvsgraph
dev-util/cvsps
dev-util/cvsq
dev-util/cvsutils
dev-util/easygit
dev-util/fossil
On 03/04/10 22:38, Robin H. Johnson wrote:
This contains a critical bug...
cvs add and the matching commit aren't mentioned anywhere...
I've been moving Git today, properly hopefully.
This is what I've been doing on the shell basically:
cd gentoo-x86
# Copy package to new location
cd
On 03/18/10 21:53, Doktor Notor wrote:
Why on earth would you mask a working
package with extremely active maintainer in CVS
Upstream stability is unequel Gentoo stability.
Sebastian
On 03/19/10 13:36, Peter Volkov wrote:
В Срд, 10/03/2010 в 05:08 +0100, Sebastian Pipping пишет:
How about a monthly bumpday?
Good idea, but it should follow our policy to inform maintainers _in
advance_: e.g. on first bumpday to work on bumps and notify maintainer
about this work
On 03/23/10 20:24, Thomas Kahle wrote:
Currently I am waiting for my extended
bugzilla rights http://bugs.gentoo.org/show_bug.cgi?id=309967 .
For the list record: halcy0n gave him permissions in the meantime.
Thomas, welcome on buzilla board!
Sebastian
abhik,
this is gentoo-dev. please take this to gentoo-soc, instead.
thanks,
sebastian
Hello!
When browsing through emerge logs (using elogv) I often come across
stuff that doesn't affect me. Two examples:
x11-base/xorg-server-1.7.6 warns:
You must rebuild all drivers if upgrading from xorg-server 1.6
or earlier, because the ABI changed.
dev-db/mysql-5.1.45-r1 logs:
Hello,
On 03/31/10 07:28, Alec Warner wrote:
Currently a number of developers have engaged Google Apps Team Edition
for gentoo.org. However Team Edition does not come with gmail and a
subset of Team Edition users would like to host their gentoo.org mail
on gmail.
Activating Standard
On 03/31/10 22:19, Ciaran McCreesh wrote:
Is there some kind of evilness in this usage of has_version that I am
not aware of?
Unfortunately, yes.
Historically, has_version in pkg_postinst would return results based
upon the version that *was* installed.
What's status quo? What did it
101 - 200 of 435 matches
Mail list logo
