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
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 {
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
Hello!
As part of my Gentoo Google Summer of Code activities
I am making use of the Portage Python API. As some of
you can tell much quicker than me
- if the API can answer question X, and
- where to find functionality for task Y
I come here to ask for precise pointers related to
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
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:
-
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
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
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
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
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
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
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
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
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
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
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
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
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
401 - 435 of 435 matches
Mail list logo
