Samuli Suominen wrote:
>> I am sorry for posting this question but I saw no other way (got really
>> confused). I am developping an application (a text editor) and I would
>> like to see it into Gentoo distro, but I can't really understand the way
>> that thing goes. I read the documentation about
Yannick Chabanois wrote:
> Not really a problem, I can had gentoo and funtoo trees in
> gpo.zugaina.org. This will be available very soon ( next week ?) with
> the new version of the site.
> All source code of gpo.zugaina.org will be made available in the same time.
That's great news!
Please keep
Robert Buchholz wrote:
>> preserve-libs
>> splitdebug
>> unmerge-logs
>
> These are documented in Portage 2.2 make.conf(5).
Just updated to make.conf from revision 13844.
http://smolt.hartwork.org:45678/static/man/man5/make.conf.5.html
My "man2tidyhtml" wrapper around manServer [1] is now
Sebastian Pipping wrote:
> An ebuild for manServer is in the pipeline, currently waiting for the
> next reply from upstream.
manServer ebuild here, new 1.08 release from upstream
http://git.goodpoint.de/?p=overlay-sping.git;a=tree;f=app-text/manserver
Sebastian
Sebastian Pipping wrote:
> An ebuild for man2tidyhtml will follow.
Here it is:
http://git.goodpoint.de/?p=overlay-sping.git;a=tree;f=app-text/man2tidyhtml
Sebastian
Hello again!
Today 19:00 UTC is "firm pencils down" for Gentoo Google Summer of Code.
That means ..
we enter the phase where you should *join me* with development.
Looking at
http://soc.gentooexperimental.org/projects/stats/issues
there is a more work to do (and will always be), both Ge
Hi there!
With the GSoC deadline behind me I took the liberty to put a few hours
into something Funtoo-related that I've been wanting to do before.
Funtoo's tree is a melting pot currently combining ebuilds from the
trees (from [1])
- gentoo
- mpd
- perl-experimental
- sunrise
with
-
Hello!
Just a quick update: the first report table on installed packages just
arrived. Have a look here:
http://smolt.hartwork.org:45678/static/stats/gentoo.html#installed_packages_most_installed_world
Sebastian
Duncan wrote:
> I haven't installed this yet. I should...
by now there's a
gentoo-smolt- ebuild
in the sping overlay to ease things up a bit.
sebastian
Hello!
Arrivals
The third peport table on installed packages "most-unmasked" has just
arrived:
http://smolt.hartwork.org:45678/static/stats/gentoo.html#installed_packages_most_unmasked
Questions
=
Before adding the forth "least-installed" table, I'd like to take the
chance to
Nikos Chantziaras wrote:
> Is there something special required to use smolt? I get to a page that
> tells me this after I submit my profile:
>
> Error: Critical: New versions of smolt use a public UUID. Yours is:
> pub_----
What version/edition of Smolt are you tr
Nikos Chantziaras wrote:
>> What version/edition of Smolt are you trying to commit with?
>
> The only available one: app-admin/smolt-1.2
Smolt 1.2 does not have the Gentoo-specific client code you need, yet.
Please try again with
app-admin/gentoo-smolt-
from my "sping" overlay.
Sebas
Sebastian Pipping wrote:
> Commits are done automatically, triggering and pushing is
> manual at the moment.
By now a cron-based setup is running syncing the pure-funtoo overlay
(and therefore also its atom and rss feeds) every 24 hours.
Sebastian
Nikos Chantziaras wrote:
> There seems to be a bit of (minimal) duplication between pure-funtoo and
> sunrise:
>
> app-office/thinking-rock-bin
> dev-tex/mimetex
> x11-drivers/xf86-video-nouveau
>
> And since sunrise is the most popular overlay, it might be a good idea
> to also omit packag
Nikos Chantziaras wrote:
> Uhm, I just discovered that there are conflicts with portage too. That
> is not good. After I added pure-funtoo, it messed up my emerge -u world
> (stuff like wanting to upgrade to sys-apps/baselayout-2.1.5).
Hopefully fixed
http://git.goodpoint.de/?p=pure-funtoo.git;a
Nikos Chantziaras wrote:
> Done. Seems to work OK. Though there's no info about the scanning of
> packages and my profile page only lists hardware.
I cannot find any new entries in the database.
Have you been using
--server=http://smolt.hartwork.org:45678/
on submission? I mentioned that i
Jeremy Olexa wrote:
>> - Would zero-install packages be more interesting than
>>almost-zero ones or the other way around?
>
> I don't really understand this question. Does "zero-install" mean that
> they are not installed at all? This isn't really useful, because the
> ommition of a package f
Nikos Chantziaras wrote:
> I use overlays for packages I can't get through portage. If they
> conflict, I don't use them.
Why do you apply such a general rule?
For instance I have been using dev-util/diffuse from the zugaina
overlay until a newer version went into the gentoo tree.
Portage tell
Nikos Chantziaras wrote:
> (so that smoltGui can actually be
> used at all since it doesn't take a --server parameter.)
Good catch. Just opened a new task for it here:
http://soc.gentooexperimental.org/issues/show/67
>> Before submission you can view all the data you submit.
>> Near the bottom
Nikos Chantziaras wrote:
> And I was under the impression that pure-funtoo
> falls under this category: providing packages that don't exist in portage.
If you want to you can adjust funtoo-ripper to do just that on your
local machine. All you have to do is adjust the
EbuildTree._minus
funct
Nikos Chantziaras wrote:
> Seems to work OK now and I just submitted my data to smolt.hardwork.org.
Great to hear, thank you.
Sebastian
Nikos Chantziaras wrote:
> [..] since [smoltGui] doesn't take a --server parameter [..]
Fixed/added.
http://git.goodpoint.de/?p=smolt-gentoo.git;a=commitdiff;h=707e98bd454ae416bec7870296ed108549275ecc
Sebastian
Christian Faulhammer wrote:
> That's a nice starting point to have a look if they aren't installed
> they are unpopular or because they fail to build (which makes them a
> candidate for removal).
I'm not following - how would we find out about the reason a package is
never reported installed?
I'
Christian Faulhammer wrote:
> Hi,
>
> Sebastian Pipping :
>
>> Christian Faulhammer wrote:
>>> That's a nice starting point to have a look if they aren't installed
>>> they are unpopular or because they fail to build (which makes them a
>>
Sebastian Pipping wrote:
> What's next
> ===
> Besides before-mentioned table the task
>
> Collect FEATURES variables in three sets (conf, defaults, globals),
> not merged
> http://soc.gentooexperimental.org/issues/show/58
>
> is next on my list.
D
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
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
> """ % excerpts
> UnicodeDecodeError: 'ascii'
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 awa
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 """ %
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
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
Wikpe
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 resourc
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 beli
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
>> 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
I think Richard was including the manual setup required to use layman
and the procedure required to ad
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
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 w
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. G
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 mod
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 f
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
:
layman-global.txt
=
http://git.goodpoint.de/?p=overlay-sping.git
Gentoo overlay of Sebastian Pipping
=
repositories.xml
=
Gentoo overlay of Sebast
volk...@gentoo.org wrote:
> I think we
> should introduce a 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
>> =
>> > name="sping"
>> quality="experimental"
>
Ciaran McCreesh wrote:
> On Mon, 28 Sep 2009 20:23:34 +0200
> Sebastian Pipping 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
&
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) th
Ciaran McCreesh wrote:
> On Wed, 30 Sep 2009 17:51:02 +0200
> Sebastian Pipping 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
Ciaran McCreesh wrote:
> Sure. Just periodically fetch the repository centrally. Have a master
> list of sync URLs with expected repository names, and use that to
> generate the full master list that includes metadata.
>
> Added bonus: you can quickly remove any repository that no longer
> exists.
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 o
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)
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.
http://git.goodpoint.de/?p=overlays-xml-specification.git;a=commitdiff;h=8b10c5c7fd5b42bb5540fd686e0d97f5d
-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 change
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
bec
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 ba
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
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 acc
>>> 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 s
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 inad
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 02:45, Mike Frysinger wrote:
> if you want to keep all of layman's stuff together, then about your only
> option is to create your own tree at like /var/layman/.
anybody objecting to /var/layman ?
> the better idea
> though would be to split your stuff along the proper lines.
>
>
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 =
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 ove
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 someh
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 ma
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 b
Maybe this flyer can help with brainstorming:
http://a3li.li/files/gentoo-flyer-en.pdf
Sebastian
time 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
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
> Content-Type: text/plain
> Posted: 2010-02-25
> Revision: 1
>
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, t
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 tha
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 p
On 02/28/10 20:54, Markos Chandras wrote:
> Do we still have bugdays? Who is taking care of this project and the
> respective webpage? I think we first need to answer these questions before we
> even consider resurrect this project
welp -> away
deathwing00 -> mail contact with me
gurlig
Quoting Ioannis Aslanidis :
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 for confirmed bugday
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 no
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 yest
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
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 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 :
>> 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 go
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
t
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. Prep
101 - 200 of 439 matches
Mail list logo
