Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files

2010-04-25 Thread Yuri Vasilevski
Hello,

On Sun, 25 Apr 2010 13:18:25 +0200
Angelo Arrifano mik...@gentoo.org wrote:

 Hello developers developers and developers,
 
 Ever wondered how much crap is left in your X-years old Gentoo box?
 
 I just developed a python utility to efficiently find orphaned files
 in the system. By orphaned files I mean the files that are present on
 system directories and don't belong to any installed package.
 
 The package builds a virtual filesystem (cache) on the RAM using
 python hash tables. Then it uses the cache to find the ownership of
 files inside user-specified dirs.
 
 Building the cache takes less than 10 seconds here in a system with
 1366 installed packages.
 
 This is not intended to be a finished program yet, I'm looking forward
 for your constructive commentaries.

There is a tool that does that, qfile from app-portage/portage-utils.
Check the -o, --orphans* List orphan files option.

It's not as straight forward as it could be, as it checks only for
files specified as arguments or read from file.

But you can trivially use it like:
# find /dir/you/want/to/check/for/orphans | qfile -o -f -

Best,
Yuri.



Re: [gentoo-dev] LICENSE and revbumps

2008-08-27 Thread Yuri Vasilevski
On Wed, 27 Aug 2008 08:10:06 +0200
Ulrich Mueller [EMAIL PROTECTED] wrote:

  Should LICENSE changes require a revision bump?
 
 No, since it would be a waste of users' resources.
 
 For example, if a dev has missed a change from GPL-2 to GPL-3 (which I
 guess is a common case), would you really have users reinstall the
 package in this case? What would be the benefit?

As an example, the user is developing a program under a licence
compatible with GPL-3 but incompatible with GPL-2, he wants to extend
it with the functionality provided by this library (lets assume the
package in question is a library) and he is considering to statically
link some bits from it.

Now he can do the right way and read the whole web page from that
package and learn all about it and all the other candidates, or just
first apply a quick filter by checking the LICENCE file and then decide
to look for another candidate.

I personally would would go with the filtering approach to narrow my
search and reduce the time I need to spend looking.

As Another example, the user might statically link bits of the exact
same library against a GPL-2 (not a GPL-2 or latter) program, just
because he is misinformed by portage that the program is GPL-2 and then
he gets into a legal problem.

so, my point is that licences are very important in some environments
and to some people, and having an inconsistently can cause serious
legal problems to users. So it is very important to keep them in sync
in all tree of upstream, portage tree and vdb tree.

Yuri.



Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

2008-08-26 Thread Yuri Vasilevski
Hi,

On Tue, 26 Aug 2008 13:40:36 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:

 I'm doing some research on our usages of the $Header$ keyword in our
 main CVS repo.
 
 Q: Are there any other use-cases you have and actively use?

I use the revision present in the header to identify changes in
ebuild files that didn't needed a revision dump.

Kindest regards,
Yuri.



Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

2008-08-26 Thread Yuri Vasilevski
On Tue, 26 Aug 2008 13:54:21 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:

 On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote:
   I'm doing some research on our usages of the $Header$ keyword in
   our main CVS repo.
   
   Q: Are there any other use-cases you have and actively use?
  I use the revision present in the header to identify changes in
  ebuild files that didn't needed a revision dump.
 Err, what do you mean by revision dump?

revision dump is when foo-1.0-r4 becomes foo-1.0-r5.

But when foo-1.0-r4 is updated in-place, I use CVS revisions
(ej: 1.12 - 1.13 in 2nd word in $ Header: )

Yuri.



Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

2008-08-26 Thread Yuri Vasilevski
On Tue, 26 Aug 2008 14:45:25 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:

 On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote:
   Err, what do you mean by revision dump?
  revision dump is when foo-1.0-r4 becomes foo-1.0-r5.
 That's revision 'B'ump, not 'D'ump.

Sorry, not native English speaker :$

  But when foo-1.0-r4 is updated in-place, I use CVS revisions
  (ej: 1.12 - 1.13 in 2nd word in $ Header: )
 The $Header$ is filled out automatically by CVS, what are you using
 the $Header$ string for?
 
 Why do you need to identify the changes? Considering that the checksum
 changes as well, is detecting change not sufficient? (or asking the
 VCS for what files have changed since your last check time).

I am writing a tool that creates deb (as in Debian package format) based
distributions from gentoo packages and that tool encodes the CVS
revision as part of debian revision of the packages. So I need this
part to be chronologically ordered, as opposed to have only the
knowledge of whenever the file has changed or not.



Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

2008-08-26 Thread Yuri Vasilevski
On Tue, 26 Aug 2008 15:25:16 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:

 On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
   Why do you need to identify the changes? Considering that the
   checksum changes as well, is detecting change not sufficient? (or
   asking the VCS for what files have changed since your last check
   time).
  I am writing a tool that creates deb (as in Debian package format)
  based distributions from gentoo packages and that tool encodes the
  CVS revision as part of debian revision of the packages. So I
  need this part to be chronologically ordered, as opposed to have
  only the knowledge of whenever the file has changed or not.
 I'd call that critically dangerous in missing some changes.
 If I have a file in $FILESDIR, and change it, but it has the same
 name, there is no commit to the ebuild, and your .debs won't pick up
 changes at all. This is usually for cases with compile fixes that
 don't need revision bumps at all, but sometimes there are also
 changes to scripts.

Yes, I know that this will not protect me against changes in a file from
${FILESDIR} nor a change in a file in ${A}, but that was the best way I
could think of to make debian source packages (I create as well) as
reproducible as possible.

For the source packages I create a debian/rules[1] file that basically
calls ebuild foo.ebuild with the right options and to compile and then
install to a temporary directory and then call some debhelper scripts
to turn that directory into a proper .deb package. So from my
perspective the .ebuild file can be considered part of the debian/rules
files and because of that I really need to keep track of changes in it.

And for the rest of files, I bump ( :-D ) another revision counter with
each rebuild of the same debian source package version, so until I find
some better way to catch changes in any bit of the source (be it the
ebuild, files from ${A} or files from ${FILESDIR)/) I still don't have
conflicts.

 If you're making binary package .debs, I gather that you are grabbing
 the (pre|post)(inst|rm) and setup blocks for inclusion?

Yes, I certainly do.

 That is an interesting use case, and would that would present a
 problem with any VCS migration.
 - Under SVN, you'd only have the global revision, which might not
   uniquely identify the file.
 - Bzr doesn't support keyword expansion in any released version. There
   are/were plans for it in 1.7, but I haven't seen anything since the
   first prototype.
 - Hg supports it with an extension:
   http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension
   But has warnings about why it sucks
   http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan
   See the 'keyword update intervals' item (mainly having to touch
 every file in the repo sometimes).
 - Git supports only the $Id$ keyword, and expands it to the SHA1 of
 the file, which ends up being a duplicate of the information we have
 in the Manifest.

I am aware about this problem, and unless this is explicitly taken into
consideration on migration, I guess I'll have to keep a local database
of order of ebuilds as part of the metadata associated with each
distribution my tool creates.

[1] debian/rules files is a make file that provides the right targets
for debian tools call it and generate deb binary packages. So it
is kind of the equivalent of .ebuild scripts for debian.



Re: [gentoo-dev] LICENSE and revbumps

2008-08-26 Thread Yuri Vasilevski
On Tue, 26 Aug 2008 20:17:48 -0600
Ryan Hill [EMAIL PROTECTED] wrote:

 Should LICENSE changes require a revision bump?

A licence changes what get's installed, ok the files are the same, but
the meaning of having the same files is different. So I say yes.

 It kinda seems to me the answer should be yes.  I don't know if any PM
 currently implements LICENSE filtering so there may not be any
 technical reason for it yet.  And so I guess it comes down to a
 philosophical question - what determines the licence(s) a currently
 installed package is covered by?  My thought is that this would be the
 value in /var/db/pkg/${P}/LICENSE, being the LICENSE value at install
 time, and therefore a change in the tree requires reinstallation to
 change that value.

Correct.

 On the other hand, it also seems completely ridiculous from a
 practical POV to have to wait 30 days (and waste arch team resources)
 to fix an incorrect licence on a stable package.

I think it should be sensible to make the stabilization request a lot
earlier specifying the reason behind the creation of that newer
revision in the bug and the stabilization process should be pretty much
automatic, without wasting to much time from arch teams.

On the other hand, I think it would be wise to create an explicit
exception for this case in stabilization rules and to allow the uploader
of the corrected ebuild to keep the same KEYWORDS instead of
downgrading them to unstable.

Kindest regards,
Yuri.



[gentoo-dev] FRC: debtools herd creation

2008-05-16 Thread Yuri Vasilevski
Hello All,

I will be adding some debian build tools to the tree, and would like to
create the debtools herd to associate with the packages.

I'll be adding things like debhelper, lintian and a little
bit later things like apt, aptitude, cdebootstrap, debian-live and some more.
Also there is debootstrap with [EMAIL PROTECTED] which I'd
like to adopt.

Any comments, sugestions and objections are more than welcome.

Kindest regards,
Yuri.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] debianutils: system worthy ?

2008-01-28 Thread Yuri Vasilevski
On Mon, 28 Jan 2008 07:23:18 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:

 now that the mktemp binary has been moved out of debianutils and
 integrated straight into coreutils, perhaps it's time to ask how
 important this package is to everyone.  current debianutils is part
 of system and provides:
  - installkernel
  - run-parts
  - tempfile
  - savelog
  - mkboot
 do people consider these things critical ?  i dont know the last time
 i personally needed/wanted any of these ...

I would say drop it from system and add to RDEPEND in kernel-2.eclass
for ${ETYPE} == sources.

Kindest regards,
Yuri.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] USE flag documentation

2008-01-13 Thread Yuri Vasilevski
Hello,

On Sun, 13 Jan 2008 20:24:53 -0500
Mark Loeser [EMAIL PROTECTED] wrote:

 What exactly do we need this system to do that we can't do now?

The only interesting thing I can think of, is to expose some of the USE
flags logic found in some ebuilds in a parseable fashion.

I'm talking about things like (from mplayer-1.0_rc2_p24929-r2.ebuild):

- Two flags are mutually exclusive:
  ( cdio implies !cdparanoia ) and (cdparanoia implies !cdio)
- A flag makes sense only if another flag is on:
  !encode implies !aac

This way portage will be able to inform/warn the user automatically
that the set of USE flags the user has chosen really means some other
thing. Something like:

[ebuild   R   ] media-video/mplayer-1.0_rc2_p24929-r2  USE=X cdio -aac#1 
-cdparanoia#2 -encode ...

#1 aac needs encode
#2 cdio conflicts with cdparanoia

But this logic will have to be exposed on a .ebuild level.

 Is overriding the USE flag with use.local.desc sufficient and we just
 need to document the current solution properly?

I would say yes.

Also, what would we gain switching to xml?
The format as it is now is trivially parseable and human friendly.
While if the data is in xml format it will be less human friendly, as
well as, it will be harder to extract the information from shell
scripts.

Kindest regards,
Yuri.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: [GLEP] RFC - Keywording scheme

2007-04-25 Thread Yuri Vasilevski
On Wed, 25 Apr 2007 23:39:47 +0200
Rémi Cardona [EMAIL PROTECTED] wrote:

 Grant Goodyear a écrit :
  Fabian Groffen wrote: [Sat Apr 14 2007, 03:33:03AM CDT]
  For people that like reading it in html or via the web:
  http://dev.gentoo.org/~grobian/gleps/glep-keywords.html
  http://dev.gentoo.org/~grobian/gleps/glep-keywords.txt
  
  So what would a version of Gentoo for amd64 based on FreeBSD but
  using glibc be called?  (It's not an entirely academic question;
  Debian folks have worked on such a distribution for some time.)
  I can't really tell from the text in your proposed GLEP.
 
 I'm sure this GLEP can be extended later on should anyone feel like 
 doing a glibc-based freebsd port of gentoo (hurts my brains just
 writing this :) )

I think it will be better if this scheme is specified in friendlier
way for future expansions, hence I this it should be more flexible.

I would propose this two modifications:

(a) Instead of using n-tuples to describe a keyword, to use sets.

Both ways can be made semantically equivalent if we add the
restrictions that the sets of all the possible architecture, kernel,
userland, libc, ... sub-keywords are disjoint. (i.e. If there is a
userland sub-keyword bsd, then there can't be a kernel or libc
sub-keyword named bsd, they have to be named in a slightly different
way.)

But on the other hand, the notation will be way more flexible as a
keyword can only specify the relevant sub-keywords, while the rest can
be considered to be a wildcard (to mean all)

(b) In case there are several keywords A and B:
- if A is more specific that B, A takes precedence (ej. with !uclibc
  arm:uclibc the package can be installed on any system that does not
  uses uclibc as libc or on any system with arm hardware.)
- if A is exactly as specific as B, the union of A and B is used (ej.
  !uclibc arm this is equivalent to the previous example.)

So to give more examples,

A package that can only be build on arm, sparc and x86 with linux and
glibc or arm with uclibc can be specified as:
{arm,sparc,x86}:linux:glibc arm:uclibc

A package (lets say linux-headers) that makes sense on all systems that
support linux and only them can be specified as:
linux

A package that is stable with gnu userland but still in testing with
bsd userland:
{some,arches}:gnu ~{some,arches}:bsd or just gnu ~bsd for all
arches.

Note that I propose to mark testing the whole set of sub-keywords, not
just like I run stable x86 with unstable bsd as I think it does not make
any sense as the resulting combination is still considered
unstable/testing.

There are two things I see against my proposal:
- This is not fully backward compatible, as it is currently equivalent
  to normal arch keywords if the user runs linux with glibc/uclibc,
  while it has a completely different meaning for Gentoo/Alt users.
  But I don't see it as a big problem because, as far as I understand,
  this will be just one of many changes that need to be made to make
  Gentoo/Alt as integrated as GNU/Linux is now into portage.

- For this to work, the keyword resolver will have to be way more
  complex than it is now, as it will have to compute the subset of all
  possible keywords some ebuild defines to see if user's accept
  keywords intersect it.

Kindest regards,
Yuri.
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] $Header:$ and ebuilds

2007-04-20 Thread Yuri Vasilevski
On Fri, 20 Apr 2007 14:52:46 +0200
Fabian Groffen [EMAIL PROTECTED] wrote:

 On 20-04-2007 15:45:00 +0300, Petteri Räty wrote:
   I use it to make deltas of changes made in the tree, and apply
   those deltas on the overlay I'm using.  Without $Header: $ there
   I have no way to actually see which version I'm dealing with, so
   which revisions to retrieve for differences.
   For that reason, I prefer as much files as possible in the tree
   to have a $Header: $ somewhere, so I can easily sync, keeping my
   local changes.
  
  Is the info you need in CVS/ ?
 
 That requires:
 a) an up-to-date CVS tree checkout
 b) a CVS tree (not a regular rsynced one)
 c) parsing of the CVS/Entries file
 
 So in principle, yes I think it can be done using the CVS directory,
 but I prefer not to.

+1 on this one.

I am writing some script to automate package building and use the
Header field to detect CVS revision changes. I know I could do it with
hash values, but then it would be harder to have builds from
different revisions of the same ebuild file time ordered.

Best,
Yuri.
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] dont use `which` in ebuilds

2007-03-12 Thread Yuri Vasilevski
On Mon, 12 Mar 2007 16:36:03 -0700
Ned Ludd [EMAIL PROTECTED] wrote:

 And matches $(which 
 x11-misc/xoo/xoo-0.7.ebuild:25:

Fixed.

Best wishes,
Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GPL-2 vs GPL-2+

2006-12-22 Thread Yuri Vasilevski
Hi,

On Fri, 22 Dec 2006 21:56:54 +0100
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

 At the moment we represent the software we consider under GNU General
 Public License, version 2 of the license, but we cannot be sure it's
 alright to license it to any later version. Linux kernel for
 instance is licensed _only_ under GPLv2, but not any later version.

I don't think this is a good solution, as in any case the package is
licensed under GPL-2, so how about for the packages that only support
GPL-2 we set:

LICENSE=GPL-2

While for the ones that support v2 or later (this is actually a special
case of multiple licensing) we do:

LICENSE=GPL-2 GPL-3

when it becomes available?

Best,
Yuri.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GPL-2 vs GPL-2+

2006-12-22 Thread Yuri Vasilevski
On Fri, 22 Dec 2006 17:06:32 -0500
Alec Warner [EMAIL PROTECTED] wrote:

 Yuri Vasilevski wrote:
  Hi,
  
  On Fri, 22 Dec 2006 21:56:54 +0100
  Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
  
  At the moment we represent the software we consider under GNU
  General Public License, version 2 of the license, but we cannot be
  sure it's alright to license it to any later version. Linux
  kernel for instance is licensed _only_ under GPLv2, but not any
  later version.
  
  I don't think this is a good solution, as in any case the package is
  licensed under GPL-2, so how about for the packages that only
  support GPL-2 we set:
  
  LICENSE=GPL-2
  
  While for the ones that support v2 or later (this is actually a
  special case of multiple licensing) we do:
  
  LICENSE=GPL-2 GPL-3
 
 If you meant:
 
 LICENSE= || ( GPL-2 GPL-3 )
 
 then I agree ;)
 
 It would be under Either the GPL-2 OR a later version, not both, yes?

Right, thanks for catching that.

Yuri.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GPL-2 vs GPL-2+

2006-12-22 Thread Yuri Vasilevski
On Fri, 22 Dec 2006 23:31:04 +0100
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

 On Friday 22 December 2006 22:53, Yuri Vasilevski wrote:
  While for the ones that support v2 or later (this is actually a
  special case of multiple licensing) we do:
 
  LICENSE=GPL-2 GPL-3
 
  when it becomes available?
 There is one problem at least for this: to apply this method you'd
 have to change _all_ the ebuilds in the tree referring to GPL-2 or
 later when GPL-3 is published, while with GPL-2+ we can start
 gradually now.

Yes, this will require us to update ebuils once in like 5 (or 15?)
years to catch with FSF. But at the benefit of having less confusion
for users about What the heck is a GPL-2+? for at last the same period
of time.

GPL-2 is not a licence nor it is not a standard notation for that way
of having multilicencing. So users will have to check what's the
meaning of that + at the end of GPL-2+, so I think it'll create much
more confusion than the work of updating packages with each new version
of GPL.

Also there could be a case that softer v3 is out, FSF will rethink and
come up with something acceptable to Linus (and other people that
refuse to migrate), as (as far as I can understand) GPL-3 will not be
compatible with GPL-2. So there could be the case of having a package
licenced under GPL-2, GPL-2.1 or later. (This is just an example, I
actually have no idea whatever this will be the case of having a softer
GPL-3.x.)

 Also it would be more useful for users to know what can be licensed
 in 2+ and what requires 2 strictly.

This info can be easily and automatically extracted from LICENSE
variable by applying some boolean logic ;-)

Yuri.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] portage idea - auto embed user patches

2006-12-21 Thread Yuri Vasilevski
Hello,

On Thu, 21 Dec 2006 17:32:41 +0300
Alexander Zubkov [EMAIL PROTECTED] wrote:

 Hi!
 I have some idea on extending portage building system (ebuild?).
 Sometimes I'm (for example) want to apply custom patch to some
 package. This patch can do something unusual, that can not be
 accepted by maintainers and I know this. But I like features in my
 patch and want it to apply automatically when updating the package.
 Not to do it like this: $
 ebuild /usr/portage/pkg-categoty/some-package/some-package-1.0 unpack
 $ cd /var/tmp/portage/pkg-categoty/some-package/work/... $ patch -p1
  ~/my-patch-for-some-package $ cd
 $ ebuild /usr/portage/pkg-categoty/some-package/some-package-1.0 merge
 
 It is lot of manual work. The idea is having an file, for example
 /etc/portage/package.patch with contents like this:
 =pkg-category/some-package-1*  /path/to/my-patch-for-some-package
 
 Of course, patches could fail in newer versions. But when I'll use
 that feature - I'll understand why it can be and it'll be more
 convenient to maintain it.

You can use portage's bashrc to do that kind of autopatching.

Best regards,
Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-17 23:59 UTC

2006-12-18 Thread Yuri Vasilevski
Hi,

On Mon, 18 Dec 2006 10:02:00 -0500
Chris Gianelloni [EMAIL PROTECTED] wrote:

 On Sun, 2006-12-17 at 23:20 -0800, Robin H. Johnson wrote:
  The attached list notes all of the packages that were added or
  removed from the tree, for the week ending 2006-12-17 23h59 UTC.
 
 OK.  Here's a fun question for you...
 
 Is it possible to have a slightly modified version of this script run,
 and the output sent to gwn-feedback for inclusion in the GWN?  This
 would make my life tremendously easier, since currently I have to
 completely reformat this by hand.
 
 Basically, I would want the output to look like:

I think it should also include the Homepage(s) and Description of the
packages so readers could easily check what that additions are all
about. While I'm not that sure that additions date and probably who
made the addition are that important for readers.

 table
 
 tr
 thPackage:/th
 thAddition date:/th
 thContact:/th
 /tr
 
 tr
 tisci-biology/amap/ti
 ti11 Dec 06/ti
 timail link=[EMAIL PROTECTED]Donnie Berkholz/mail/ti
 /tr
 
 /table

So I think it should be something like:

table

tr
thPackage:/th
thHomepage:/th
thDescription:/th
/tr

tr
tiuri 
link=http://packages.gentoo.org/packages/?category=sci-biology;name=amap
sosci-biology/amap/uri/ti
tiuri link=http://bio.math.berkeley.edu/amap/;Homepage/uri/ti
tiProtein multiple-alignment-based sequence annealing/ti
/tr

/table

Best,
Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-17 23:59 UTC

2006-12-18 Thread Yuri Vasilevski
Hi,

On Mon, 18 Dec 2006 11:38:14 -0500
Alec Warner [EMAIL PROTECTED] wrote:

  I think it should also include the Homepage(s) and Description of
  the packages so readers could easily check what that additions are
  all about. While I'm not that sure that additions date and probably
  who made the addition are that important for readers.
 
 The only reason the contact and date are there is because the code
 for removals and additions is basically the same (A or D tells me
 which one it is) and all that info is available in the CVS history
 file.  The problem with HOMEPAGE or DESCRIPTION is that they are
 version specific and there is no way to choose which version to pick
 in the case where more than one version was added at the same time.

The way I implemented this was to get the homepage(s) and description
from the newest version, but I think absolutely any convention will
work as in the very rare cases where someone commits several versions
with different homepages or descriptions, giving the info about just
one of the versions should be quite a good indicator on what this
package is all about, else the versions should not share the same
package name (in the case that they do completely different things).

Also, to get that info you can use portageq in a reasonably simple way,
something like:

let ebuild be $CATEGORY/$PF

homepage=$(PORTDIR_OVERLAY=${CVS_DIR} portageq metadata / ebuild \
${ebuild} HOMEPAGE)
description=$(PORTDIR_OVERLAY=${CVS_DIR} portageq metadata / ebuild \
${ebuild} DESCRIPTION)

This will make the script a little bit slower, but it should not be
that hard to integrate.

Best,
Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-17 23:59 UTC

2006-12-18 Thread Yuri Vasilevski
On Mon, 18 Dec 2006 13:28:22 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:

 On Mon, Dec 18, 2006 at 02:53:56PM -0600, Yuri Vasilevski wrote:
  This will make the script a little bit slower, but it should not be
  that hard to integrate.
 Please read the message that I sent as well. In specific, there is NO
 way we can gaurentee that the machine has an up to date copy of the
 tree
 - thus why we use CVS history directly.

Yes, sorry, my mistake. For some reason I assumed that on the CVS
server you also have the tree ready to use and in an unpacked form.

Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: persistence of eclasses for installed packages

2006-11-04 Thread Yuri Vasilevski
On Sat, 4 Nov 2006 06:46:02 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:

 On Saturday 04 November 2006 06:14, Petteri Räty wrote:
  Zac Medico kirjoitti:
   What do people think about these two approaches?  Personally, I
   would prefer approach #2 for the sake of simplicity and
   maintainability.  The sooner that we start storing eclasses.tbz2
   for each installed package, the sooner that we will be able to
   have more freedom with the eclasses in the live portage tree.
 
  One thing that comes to mind is that how do we handle the case
  where the old version of the eclass has a major bug in pkg_postrm
  for example.

I think it is also possible that changes into a eclass introduce a new
unexpected bug, so this shouldn't be the only reason to stop doing this.

How about introducing a variable OBSOLETES=list of cvs revisions,
this way it can be automatically detected if the cached ebuild/eclass
can be used or if it needs to be ignored and the newer version from
portage that obsoletes it has to be used?

 that would be the only thing keeping me from saying LETS DO #2 NOW ;)

I'd vote, lets do #2 in any case.

Yuri.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: put new additions along with removals in GWN

2006-10-28 Thread Yuri Vasilevski
Hi,

On Sat, 28 Oct 2006 19:58:09 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Sat, 28 Oct 2006 20:42:14 +0200 Paul de Vrieze [EMAIL PROTECTED]
 wrote:
 |  Someone needs to implement the foo; however.
 | 
 | (Not on cvs, but on a normal tree, but maybe works on cvs. There is
 a | sanity check by checking that a dir contains at least 1 ebuild)
 
 If the foo were that simple, someone would have done it long ago. It
 needs to take into account updates/.

I have sent my script directly to wolf31o2 some days ago thinking that
the exact technical details can considered spam for the majority
subscribed on the list, but for completeness I'm attaching in in this
e-mail.

It works comparing two different portage snapshots that it can also
download.

Best,
Yuri.

gen_newpkg_table.sh
Description: application/shellscript


Re: [gentoo-dev] heads up: adding ca-certificates as a PDEPEND to openssl

2005-12-30 Thread Yuri Vasilevski
Hi,

On Fri, 30 Dec 2005 17:34:59 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:

 just a heads up ... i'm going to be adding the ca-certificates package as a 
 PDEPEND to the openssl package so most everyone in Gentoo will end up with it 
 on their system
 
 for those wondering what this is:
 http://packages.debian.org/unstable/misc/ca-certificates
 basically it's additional certificates that arent part of the default openssl 
 distribution

I'm not so sure that this is a good idea, as adding CA root
certificates is a way to make (good) money for some free projects and
unfortunately for some non free ones too. I'm not sure if openssl
charges certificate inclusion, but if it does this will interfere with
the founding policies (and then development) of openssl.

Now, being a little bit less ideological, I think it is perfectly ok to
add certificates from some organizations like CACert.org that try to
make security free for all Internet users as well as open source
projects' certificates (like debian ones). But it should be up to
businesses to buy they're way into openssl by the means of this
sponsoring.

So my suggestions is to add root certificates only for non for profit
organizations. (For intermediate certificates that already have root
certificate bundled with openssl it ok in all cases). Or at last don't
make it a RDEPEND but an einfo you may want to intall X for Y reason.


 this will inadvertently fix this fun bug:
 http://bugs.gentoo.org/101457
 and probably more in the future

In this king of cases it is probably better to ask upstream to bug
they're CA to sponsor openssl or use some free CA.

Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] revdep-rebuild

2005-08-13 Thread Yuri Vasilevski
Hi,

On Sat, 13 Aug 2005 18:01:05 -0700
Stefan Jones [EMAIL PROTECTED] wrote:

 So I have started making a small C program which does the
 Checking dynamic linking consistency... part of the revdep-rebuild
 program (I think this the the most time intensive part).

I think it'll be better/preferable if you make it an applet for
portage-utils.

Yuri.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] splitting one source package into many binaries

2005-06-16 Thread Yuri Vasilevski
Hi,

On Thu, 16 Jun 2005 12:40:39 -0500
Brian Jackson [EMAIL PROTECTED] wrote:

 Rafael Espndola wrote:
  I am using Gentoo to build some small systems. While things like the
  minimal useflag is a joy, the monolithic nature of most gentoo
  packages is a headache.
  
  Kde has been spit and libstdc++ can be installed without gcc but there
  are many other packages that don't have this feature. For example,
  installing qt also installs qt designer.
 
 Use INSTALL_MASK to keep it from getting installed. Keep both pieces.

I think that it's not the way to go because this will create
the exact problem that existed with installing an incomplete
kde before there where split ebuilds for it.

And this problem is that when you emerge a package it expects
it's dependencies to have the things it'll use form them. And
with INSTALL_MASK you brake this assumption in a way that there
is no easy way for an ebuild to verify that it's dependencies
have installed the things that the package needs.

So I think it may be good for some packages to be split in
several packages (but right now I can't think of any), but I
think it'll be much better introduce more granularity into
many ebuils with use flags. This is specially the case (in
my opinion) of packages that can have both client and server
functionality (the best example I can think of is net-fs/samba,
which I mostly use just to mount shares form other servers).

Just my 2 non convertible (i.e. non developers) cents.
Yuri.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Hi guys !!

2005-06-04 Thread Yuri Vasilevski
Hi,

On Sat, 04 Jun 2005 14:48:18 -0400
Aaron Walker [EMAIL PROTECTED] wrote:

  I want to know how to make ebuilds (please if you could send me the web 
  site that explains it),
 
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
 
  I suggest you to make an ebuild for wxmaxima: 
  http://wxmaxima.sourceforge.net
 
 Bugs/new ebuilds requests go to http://bugs.gentoo.org/.

http://bugs.gentoo.org/show_bug.cgi?id=83167

Best regards,
Yuri.
-- 
gentoo-dev@gentoo.org mailing list