# Sebastian Pipping sp...@gentoo.org (27 Nov 2012)
# Masked for removal in 30 days.
# Server and software development discontinued upstream (bug #438082)
app-admin/smolt
# Sebastian Pipping sp...@gentoo.org (27 Nov 2012)
# Masked for removal in 30 days.
# Licensing issues, turned out not distributable (bug #444332)
app-admin/profiler
On 11/24/2012 10:12 PM, Pacho Ramos wrote:
# Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Upstream dead and
no longer runs (#402669). # Removal in a month app-cdr/dvd95
Bug fixed. I just ripped a DVD with dvd95 successfully.
+ 02 Dec 2012; Sebastian Pipping sp...@gentoo.org package.mask
On 20.12.2012 19:14, Ciaran McCreesh wrote:
The tree is a database. It belongs in /var/db/.
I don't see /var/db in the latest release of the Filesystem Hierarchy
Standard:
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY
I would prefer something that blends with FHS.
Best,
On 20.12.2012 18:27, Ulrich Mueller wrote:
Now I wonder: After removal of e.g. the Portage tree from a system, it
is generally not possible to restore it. (It can be refetched, but not
to its previous state.)
Same is true for distfiles, at least to some degree. They may have
vanished
Coming to my mind:
There have been continued regular releases of genkernel integrating
patches from various people:
http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=tags
And there has been a constant stream of people asking for user overlay
hosting or getting an existing overlay
Looks like great work so far.
On 11.02.2013 01:20, Michał Górny wrote:
Secondly, I'd like to make it clear that the old python.eclass is
'almost' deprecated. We're in process of converting the in-tree
packages to use the new eclasses but that's a lot of work [3].
[..]
Markos Chandras wrote:
Hello folks,
Qt-creator[1] program can support perforce[2] software configuration
manager.
My concern is the perforce license. According to their site[3] there is a
dual(?) license.
There is the standard commercial license[4] and one for free software
Markos Chandras wrote:
Sebastian,
Why would I want to do that? The license files should stay untouched.
There is
nothing wrong of having both licenses on ebuild since this is the upstream
policy.
I forgot that the license files upstream might change
so I agree you need a copy
Ryan Hill wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
Um, why?
I'm not having six identical patches with different version numbers in
FILESDIR.
Good point.
Sebastian
Ryan Hill wrote:
Alin Năstac mrn...@gentoo.org wrote:
I suppose what everyone does in their part of the tree is their
business, but a small subset of packages I maintain have other
maintainers as well. It is annoying to see rules you assume being
respected on your ebuilds being broken at
Timothy Redaelli wrote:
Hi,
Some repositories has the git (or svn) and http support. I saw that we choose
the git/svn one (it's faster i know, but it does not works under proxy).
I propose a E{GIT,SVN}_REPO_HTTP_URI (or similar) variable that uses the http
Good idea.
variant when the
Fabian Groffen wrote:
I think what's missing is the following observation:
${PN}-fix-issue.patch naming is bad if you patch code that is (likely)
to change in newer releases. This is almost always the case. Ultimate
example, patch something in ffmpeg or mplayer, and the next snapshot
will
Marijn Schouten (hkBst) wrote:
Furthermore a lot of our patches are in the sed format and I happen to think
that's a good thing.
My current view is that sed patches should only be used where
static patches don't work, ignoring laziness (including mine)
for the moment.
Why do you feel sed
Just an idea without knowing all the details:
Could
- --emerge-info and --emerge-info-verbose
options be added to paludis or
- a converter script be written to convert
paludis output to feel like emerge output
to solves this issue? Would that technically
be possible? Is paludis
Ciaran McCreesh wrote:
Taking any of it out would be
removing things that are required to determine the cause of a bug.
I doubt that's true in most cases: The information needed to
finding the bug is a (possibly small) subset of the whole.
I don't see how additionally providing a stripped
Robert Buchholz wrote:
Note that we have a Summer of Code student this year who is working on a
project to gather both hardware and software statistics from Gentoo
users. If you have any special requirements for your platform, I am
sure he has open ears. No need to invent two wheels at the
Hello!
Quick (re-)introduction: My task for Gentoo/Google Summer of Code 2009
is to give Gentoo a Debian popcon equivalent, a tool to collect
statistics on what package is installed how often. To achieve this
goal I'm extending Smolt (a tool currently doing similar things with
hardware
Related to my previous mail 'Inviting you to project PackageMap'
(blog post version at http://blog.hartwork.org/?p=373)
# Clone repo
git clone git://git.goodpoint.de/packagemap.git
cd packagemap
# Prepape CPE database
( cd nvd ./download-nvdcve.sh ./extract-cpe.sh )
# Create packagemap
Hello!
In response to Donnie's request on status updates to the gentoo-dev list
this mail here. I posted the actual content as blog posts through
Planet Gentoo before.
So for anyone not subscribed to Planet Gentoo these are the related
blog posts:
- TurboGears 2 and Gentoo
Richard Hughes wrote:
I'm slightly worried about it being called a service. Is it going to
be a new process that just does the mapping or is this a bad choice of
words? If it is a new process then I'm not sure such a thing will
catch on.
I'm not yet sure about how a mapper will keep it's data
Petteri Räty wrote:
Sebastian Pipping wrote:
To count into the same bucket we use global identifiers for the
products that fall out of a package. Gentoo package dev-util/git
can produce product cpe://a:git:git, Debian's git-core can, too.
That string before is a CPE URI [1], a concept close
Steven J Long wrote:
You might as well use Gentoo's version specification for your internal
format, as it's the most comprehensive. The most you need to add is
debian epochs.
I'm not sure what you are referring to.
Please share more details or pointers.
XML was never meant for data-storage
Petteri Räty wrote:
I mean making metadata.xml the authoritative source for mapping CPE to
Gentoo packages. I don't want to see the situation when adding new
packages to the tree would need some mapping being done in an external
web service.
Well, it's a nothing more than git commit and push
Robert Buchholz wrote:
On Saturday 13 June 2009, Sebastian Pipping wrote:
One of the stronger points for collaborating at the source is that
poeple who are not Gentoo devs (yet) and therefore have no write
access to the Gentoo tree can still extend and fix the Gentoo
packagemap entries
Robert Buchholz wrote:
The consumers of the PackageMap will always only use the central
database.
I'm not sure about that. I rather assume it will happen.
Especially use ignoring the substitution map.
I am convinced the project will be more viable if people can choose
their level of
I start to understand the real benefits of moving a larger
part of the maintenance down to the distro level as you proposed.
Okay, let's add support for CPEs at distro package level
and sync up and down with the central packagemap database.
Please contact me for collaboration on sync scripts
and
Marijn Schouten (hkBst) wrote:
Sebastian Pipping wrote:
I start to understand the real benefits of moving a larger
part of the maintenance down to the distro level as you proposed.
Okay, let's add support for CPEs at distro package level
and sync up and down with the central packagemap
Paul Wise wrote:
On Thu, 2009-06-18 at 02:09 +0200, Sebastian Pipping wrote:
It could be interesting how much the list of homepages
in say Debian packages and Gentoo packages overlap.
Debian sid amd64 binary packages:
$ grep -h ^Homepage
/var/lib/apt/lists
Paul Wise wrote:
The scripts were in my mail and the files are on every Debian mirror:
wget -O -
http://ftp.debian.org/debian/dists/unstable/main/binary-amd64/Packages | grep
-h ^Homepage | sort | uniq -c | sort -n -r | head -n 10
wget -O -
Marijn Schouten (hkBst) wrote:
Neither of the gits gentoo has seems very split,
I was referring to git in Debian here:
Package: git-core
Binary: git-core, git-doc, git-arch, git-cvs, git-svn,
git-email, git-daemon-run, git-gui, gitk, gitweb
texlive with (http://www.tug.org/texlive/)
Sebastian Pipping wrote:
I'd like to determine the subset of URLs that appear
exactly once in both gentoo and debian source packages.
Mappable homepages in Debian: 6222
Mappable homepages in Gentoo: 9582
Shared (without normalization): 1183
With normalization for
SourceForge
Just a quick note that target
Make existing data processing fine-configurable
by now is complete and part of smolt's upstream code:
http://git.fedorahosted.org/git/smolt.git
The motivation for this feature was to allow users
to shape smolt's behavior to fir their needs for privacy:
If a
Petteri Räty wrote:
You need to come up with the needed DTD changes for metadata.xml. Last
time the schema was changed it was done with a GLEP so writing one seems
prudent here too especially if we are going to make the value mandatory
after it was been added to all existing packages. Also
I've been working on the first Gentoo-specific data collecting bytes
today. As smolt is written in Python using Portage's Python API was an
easy choice. Here's an excerpt of data sets and their status of
processing that I've been working with today:
Collected and auto-filtered:
-
First thanks for sharing your concerns and setup bits.
That's the right thing at the the right time.
Robin H. Johnson wrote:
Relevant to this, I might not want to disclose my profile inheritance
tree. Here's one of them for you:
/etc/make.profile
Sebastian Pipping wrote:
A) Download and keep a snapshot of layman-global.txt in sync ourselves
B) Use heuristic on layman's cache
- Resolve ${cache} from /etc/layman/layman.cfg
- Parse all ${cache}/cache_*.xml files using the Layman API
- Compare the list
I more or less took a week off GSoC for LinuxTag.
It gave me the chance to further spread the ideas
behind Gentoo (and also PackageMap) a bit. I think
that was worth not producing any code during the time.
There is lots of things to do, I'm back at it.
Sebastian
Sérgio Almeida wrote:
user action bin {
description Change Python's Version
type sym
sym python {
bin python
target /usr/bin/python
prefix /usr/bin/
regexp python([0-9]+\.[0-9]+$)
sym python-config {
Duncan wrote:
Note that one can set PORTAGE_RSYNC_EXTRA_OPTS in make.conf, with the
contents being added to the normal rsync command. Looking at the rsync
manpage, there's the --exclude-from=/path/to/exclude.file option.
[..]
However, it should be obvious that
anything a sysadmin wishes
Robin H. Johnson wrote:
I'm wondering how profiles should be reported. Rather than just the
endpoint, I'm thinking that we should resolve them and generate a list,
like the above, then explicitly whiteout the non-public ones.
So in the above, you'd report:
===
(censored) X 13
Robin H. Johnson wrote:
1. That's not the only location used for layman.
- At home: /code/gentoo/layman/
- At work: /usr/local/portage-layman/
- Gentoo Infra: /usr/portage/local/layman/
2. Just because an overlay is distributed by layman does NOT mean that
it's safe to disclose the
Hello!
app-portage/mirrorselect is a single file Python program.
It contains a class MirrorParser that parses mirrors.xml from the Gentoo
website. I would like to use that code (unmodified) for my GSoC
project.
My request is to extract an extra file for that class from
mirrorselect so the
Lars Wendler wrote:
So what do you think? Should we convert the bug into a tracker and open bugs
for any package using the USE-flag that should be converted into the other
one?
+1 from me, sounds reasonable.
Sebastian
Robin H. Johnson wrote:
On Sun, Jul 05, 2009 at 02:44:07AM +0200, Sebastian Pipping wrote:
When collecting information on the SYNC variable for my Summer of Code
gentoo stats project I'd like to check if the URL in SYNC is publically
known or some private/secret rsync mirror. The page behind
Rémi Cardona wrote:
And now for some bikeshedding fun, which flag are we going to keep? ;)
My vote would be for cdaudio as that
- is more general (including analog playback)
- is more user friendly
but let those decide who impkement it.
Sebastian
Robin H. Johnson wrote:
I'll try to suck that down soon and build up a larger history with old
tarballs, and then push it somewhere useful.
To re-build mirrorselect's complete history we'd need the original
tarballs for each line starting with [ ] below.
Please let us now if you have some of
Fabian Groffen wrote:
So alternative, what if
we extend the layman-global.txt (which is xml in reality...) file with
an extra property per overlay which holds the contents of it's
repo_name?
Good idea.
I'll try to create a map for all overlays in layman-global.txt as a next
step. Layman and
Sebastian Pipping wrote:
I'll try to create a map for all overlays in layman-global.txt as a next
step. Layman and shell tools should help with that.
Believe it or not: discs space issues disallow me to have an answer
already. The code is there, I just cannot checkout all overlays at the
same
Robert Buchholz wrote:
1. has no DTD/xml validation schema
I'd like to be part of the schema creation process but feel that having
pre-mature schema's on the list and it's archives is not a good idea.
If we had a schema file: where would we store it?
Sebastian
Tobias, thanks for taking the time to test my code!
Tobias Klausmann wrote:
/home/klausman/tmp/smolt-gentoo/client/distros/gentoo/globaluseflags.py:22:
DeprecationWarning: the sets module is deprecated
I'm looking for advice how to best handle this.
@all
If you read this and know how please
Victor, thanks for participating!
Victor Ostorga wrote:
1. Local overlays are not taken into account, the output is like
follows:
Active overlays:
Names:
[]
Paths:
[]
Total: 1
Known: 0
Secret: 1
Does it have a profiles/repo_name file?
Can you share the output of
#
Victor Ostorga wrote:
1. Local overlays are not taken into account, the output is like
$ emerge --info --verbose | grep OVERLAY
PORTDIR_OVERLAY=/usr/local/portage
It is a local overlay which I use to do some tests.
That overlay is ignored to protect your privacy.
A good way to include it
So here's the current result of my analysis:
==
Format:
repo_name, # layman-global.txt
Entries:
maekke's overlay, # maekke
kde, # kde-testing
ERROR: Overlay lordvan lacks repo_name entry
ERROR: Overlay rox lacks
Petteri Räty wrote:
You need to come up with the needed DTD changes for metadata.xml. Last
time the schema was changed it was done with a GLEP so writing one seems
prudent here
I have started
- writing a GLEP
- extending the DTD
- extending a sample metadata.xml
Related gitweb over here:
Sebastian Pipping wrote:
Robert Buchholz wrote:
1. has no DTD/xml validation schema
I'd like to be part of the schema creation process [..]
First try on a DTD and Relax NG schema for Layman's current overlays.xml
format (used in layman-global.txt) over here:
http://git.goodpoint.de
Zac Medico wrote:
So what's needed to get a new mirrorselect release out?
Are all of your changes here?
git://git.goodpoint.de/mirrorselect.git
Yes.
Now we just need to create an ebuild to install it, and put it in
the tree. You can file a bug for that and assign it to tools-portage.
Sebastian Pipping wrote:
I have started
- writing a GLEP
- extending the DTD
- extending a sample metadata.xml
Related gitweb over here:
http://git.goodpoint.de/?p=metadata-xml-cpe-glep.git
Especially as this is my first GLEP and it will affect most of you in
the long run, I depend
Pacho Ramos wrote:
Have you think about enabling cdda USE flag by default in *desktop*
profiles? I think that most of desktop users will want to get cdaudio
support by default
There's quite a few notebooks without cd/dvd drives around these days.
I cannot tell how much that's in percent of all
Hello!
Just a few words for proof of life. I'm knee-deep in SQL alchemy stuff
at the moment. I guess a good explanation why Gentoo had to live
without its own popcon before is that it's a lot of work shoveling the
data into a database alone, relating to a 20+ table scenario. Still,
things are
Robin H. Johnson wrote:
So, please test at:
http://bugs-web-lb.gentoo.org/
HTTP and HTTPS available.
Nice, makes a very responsive impression to me.
Sebastian
Mike Frysinger wrote:
If you have something you'd wish for us to chat about, maybe even
vote on, let us know ! Simply reply to this e-mail for the whole
Gentoo dev list to see.
I would love to see the GLEP on CPE names in metadata.xml discussed,
Hello again!
Just a few quick updates. By now the server side accepts
Gentoo-specific data from the client (transfered as JSON) and updates
that machine's previous submission in the database. (That's not as
trivial as it may sound at first.) As a single submission produces a
few thousand
I haven't mentioned yet that I have started using the provided Redmine
installation, especially its bug tracker lately. The reason I post
about this is these two links that might be of interest to some of you:
Gentoo/Smolt/GSOC tasks
http://soc.gentooexperimental.org/projects/stats/issues
hi there!
intro + high level stuff
=
the stats gathering project that i'm currently working on mainly
involves data specific to the package manager, i.e. portage. as some
gentoo users are using paludis instead of portage the question arises if
and how we should integrate
Hello again!
I have set up a test server of the current stats code. If you have a
minute to check it out that would rock. I'm very interested in overall
feedback and bug reports.
To check it out please do as following:
0) Make sure you have these packages installed:
Sebastian Pipping wrote:
0) Make sure you have these packages installed:
sys-apps/portage
dev-util/git
dev-python/rhpl
dev-python/urlgrabber
dev-python/simplejson
dev-python/dbus-python
From what I hear not everyone has the HAL daemon
Sebastian Pipping wrote:
3) Run the client (which asks and shows details before submission)
# python sendProfile.py \
--server=http://smolt.hartwork.org:45678/
I forgot to mention you need to create a random machine id one way or
another before you can submit data
Mark Bateman wrote:
emerge rhpl -va
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N] net-wireless/wireless-tools-29 USE=nls -multicall 288 kB
[ebuild N] dev-python/rhpl-0.213 236 kB
Total: 2 packages (2 new), Size of
Dirkjan Ochtman wrote:
On Mon, Aug 10, 2009 at 12:08, Sebastian Pippingwebmas...@hartwork.org
wrote:
0) Make sure you have these packages installed:
dev-python/rhpl
dev-python/urlgrabber
dev-python/dbus-python
What do you need these for?
a short and correct answer
Ben de Groot wrote:
So hereby we announce the Gentoo Multimedia overlay. It is located at
http://gitorious.org/gentoo-multimedia and any developers who want to
join can let us know their gitorious account name, so they can be added.
Good idea!
Out of curiousity: Is a gitorious account a
Federico Ferri wrote:
note that for sound-related packages there exists pro-audio overlay
my impression is that pro-audio really focuses on _professional_ audio
software. that's two very different sets of applications. i don't see
any benefits from mixing them, do you?
sebastian
Josh Saddler wrote:
I'm well aware of that. It's A Dumb Policy(tm). :)
What advantage do you see in forcing people to have their overlays
hosted on http://git.overlays.gentoo.org/gitweb/ ?
Sebastian
Federico Ferri wrote:
1st: you could make an ebuild for it ;)
i just made one but it's not that useful yet, as the code is not
runnable from any location yet...
2nd: how to improve the output: you could make every data an
hyperlink: that would help understand better the contents
actually
Federico Ferri wrote:
1st: you could make an ebuild for it ;)
Done. Look for app-admin/gentoo-smolt- in the sping overlay.
Running
# smoltSendProfile --server=http://smolt.hartwork.org:45678/
should work fine after.
Sebastian
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 how to
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 me
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 hosted
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
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 ask
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 trying
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.
Sebastian
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 packages found
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
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 in
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 from the
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 tells
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
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've
Christian Faulhammer wrote:
Hi,
Sebastian Pipping webmas...@hartwork.org:
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
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.
Done.
Previous test participants
1 - 100 of 435 matches
Mail list logo
