Re: [gentoo-dev] Rewriting bash-completion.eclass

2011-09-01 Thread Jeremy Olexa

On 09/01/2011 07:48 AM, Michał Górny wrote:

Hello,

Our bash-completion.eclass is awful and ugly. I'm not even talking
about flags and stuff now but dobashcompletion() itself.

That function doesn't follow do*() argument scheme; it matches rather
one used by new*() funcs. Sadly, a number of ebuilds is using that
scheme to rename installed file.

Furthermore, it uses two eclass variables to switch the behavior.

BASHCOMPFILES allows it to install multiple files (but works only if no
arguments are passed).

BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not
used) and makes it ignore the second argument.

I think the way to go would be to reimplement it completely. Maybe just
put dobashcomp() and newbashcomp() functions in eutils (to not collide)
and deprecate bash-completion.eclass?



De-facto maintainer signing off, your ideas have been read and 
well-accepted by myself. Carry on as you see fit, IMO.

-Jeremy



Re: [gentoo-dev] USE=introspection has been unmasked in the tree

2011-08-16 Thread Jeremy Olexa

On 08/16/2011 06:07 PM, Nirbheek Chauhan wrote:

The use-case for disabling introspection globally is if you will never
use any gobject language bindings for the next 4-5 years.


FYI: I disabled it globally, already, on my server. As the rrdtool stack 
pulls in pango with the +introspection default. Useless to me, and my 
host. No problems since June 24 2011. (I thought it was already unmasked 
since I discovered it enabled back then)


% grep intro /etc/portage/make.conf
USE=${USE} -python -perl -introspection # questionable defaults

=D

Take care,
-Jeremy



Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

2011-08-16 Thread Jeremy Olexa

On 08/16/2011 09:01 PM, Dale wrote:


Allow me to start this way. If you change a page, send me a link,


http://archives.gentoo.org/gentoo-doc-cvs/



Re: [gentoo-dev] Voting on adding Leechcraft to the tree

2011-07-20 Thread Jeremy Olexa

On Wed, 20 Jul 2011 19:05:54 +0400, Maxim Koltsov wrote:

Hi devs,
I got a request to add Leechcraft (http://leechcraft.org/) to the
portage tree. Leechcraft is modular internet client with many 
plugins.

Main problem with it is that it has very few (less than 5, i suppose)
active maintainers, and is needed by very limited amount of users
(mainly friends of project lead). So, i want to use gentoo-dev ML as
tool to 1) advert Leechcraft to larger audience and 2) ask Gentoo
developers and users: is it worth to be in tree?
If there are 5 votes for Leechcraft and no unfixable complaints from
other devs, i will start adding Leechcraft to tree.
Here you can see existing ebuilds and other info:
http://code.google.com/p/rion-overlay/source/browse/#hg%2Fnet-misc

http://code.google.com/p/rion-overlay/source/browse/eclass/leechcraft.eclass
Contacts of the project lead and supposed package maintaner in gentoo
(with me as proxy): d34df...@jabber.ru (XMPP).


There are no restrictions based on popularity of a package being 
added to the portage tree. As a matter of fact, if even only you, 
yourself, used the package it is still valid to add to the tree provided 
someone is adequately maintaining it. You do get that privilege as a 
Gentoo Developer - the meta-distro is yours.


-Jeremy



Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

2011-06-29 Thread Jeremy Olexa

On Wed, 29 Jun 2011 17:31:43 +0200, Patrick Lauer wrote:

On 06/29/11 17:14, Olivier Crête wrote:


Stop polluting the thread with $init vs $init2, please.
-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/inspircd: inspircd-1.1.19.ebuild inspircd-1.1.23.ebuild

2011-05-11 Thread Jeremy Olexa

On 05/11/2011 07:39 AM, Samuli Suominen (ssuominen) wrote:

ssuominen11/05/11 12:39:52

   Removed:  inspircd-1.1.19.ebuild inspircd-1.1.23.ebuild
   Log:
   drop 2 oldest, fails to build with gcc-4.4 and openssl-1

   (Portage version: 2.2.0_alpha31/cvs/Linux x86_64)



Please make updating the ChangeLog a part of your new workflow, 
http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html




Re: [gentoo-dev] hardened flavor of the developer profile

2011-05-05 Thread Jeremy Olexa

On Thu, 05 May 2011 17:23:51 +0200, Paweł Hajdan, Jr. wrote:

Currently I'm using the default/linux/x86/10.0/developer profile, but
I'd like to switch to hardened on my developer system to catch more 
issues.


However, eselect profile list only displays one hardened profile for 
me:


$ eselect profile list
Available profile symlink targets:
snip

I'm using eselect-1.2.11.

When listing the profiles directory in CVS, the hardened profile 
seems

to have developer and other sub-profiles:

ph@localhost ~/gentoo-x86/profiles $ ls -l hardened/linux/x86/
total 48
snip

Any ideas how to get a hardened+developer profile?


Those profiles that you are seeking are *not* listed in 
PORTDIR/profiles/profiles.desc which is why they don't show up in 
eselect output. This means that repoman does not check those profiles at 
all. I am curious as to how much value they actually have ;) With that 
being said, eselect is NOT the only way to set your profile, you can 
just as easily create a symlink.

-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-kernel/git-sources: ChangeLog git-sources-2.6.39_rc6.ebuild

2011-05-04 Thread Jeremy Olexa

On Wed,  4 May 2011 15:13:18 + (UTC), Mike Pagano (mpagano) wrote:

mpagano 11/05/04 15:13:18

  Modified: ChangeLog
  Added:git-sources-2.6.39_rc6.ebuild
  Log:
  Version bump
snip
K_EXTRAEINFO=This kernel is not supported by Gentoo due to its 
unstable and
experimental nature. If you have any issues, try a matching 
vanilla-sources
ebuild -- if the problem is not there, please contact the upstream 
kernel
developers at http://bugme.osdl.org and on the linux-kernel mailing 
list to
report the problem so it can be fixed in time for the next kernel 
release.


pkg_postinst() {
postinst_sources
}


Hello Mike,

http://bugme.osdl.org is 404, do you mean bugzilla.kernel.org? I've 
tried to ask you on IRC once about this in the recent past but we didn't 
connect.


Thanks, Jeremy



Re: [gentoo-dev] Re: openrc portage news item

2011-04-30 Thread Jeremy Olexa

On 04/30/2011 07:58 AM, Brian Harring wrote:

On Sat, Apr 30, 2011 at 08:03:43AM -0400, Rich Freeman wrote:

snip a lot of crap that is ignoring what I've been asking

Frankly getting fairly annoyed people are immediately taking it to
the rhel/ubuntu extremes- that is *not* what I asked and is frankly
a strawman argument.  Occasional pain on upgrades is a given in
gentoo, although anyone claiming we've not kept an eye on those sharp
corners is delusional (versioned eapi, etc-update's very existance,
portage warning on removal of a pkg in the system set, the list goes
on).  Hell, even the notification mechanism y'all want to use for
informing is an example of trying to soften those corners were
possible, rather than precluding their existance.

I asked if we had looked at scripting away some of the upgrade pains.


This openrc upgrade is the *least* painful Gentoo upgrade I have 
experienced. What a waste of time (IMO) to script some defaults.

-Jeremy



It's a pretty simple fucking question requiring either a 5 second
no or 5 minutes of yes, heres what we looked at, they were deemed
too painful.  Answering that also is a helluva lot quicker then
people trading barbs over we need to release it now or proper SA;
while your retort was dead on for what folks should do, it was
completely unrelated to answering the question I'm *asking*.

If we didn't look into it, that's fine.  Means I've got something to
poke at over the weekend.

If we did, and it was ruled out, awesome, I have other things on my
todo list I'll poke at this weekend.

~harring





Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-29 Thread Jeremy Olexa

On 04/29/2011 01:34 PM, Samuli Suominen wrote:

On 04/29/2011 09:26 PM, Mark Loeser wrote:

Samuli Suominen (ssuominen)ssuomi...@gentoo.org  said:

ssuominen11/04/29 18:13:31

   Removed:  transmission-2.12.ebuild
   Log:
   drop old, broken with stable libnotify

   (Portage version: 2.2.0_alpha30/cvs/Linux x86_64, RepoMan options: --force)


When removing an ebuild, please do document it in the ChangeLog.

Thanks,



no thanks



Not that I want to start a war over this little thing, but multiple 
times I've cursed under my breath trying to track down something *not* 
documented in the ChangeLog and I've asked you multiple times as well to 
start doing thing. So, it makes my life easier if you document removals 
in the ChangeLog too, please do.

-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-admin/gentoo-rsync-mirror: metadata.xml ChangeLog

2011-04-26 Thread Jeremy Olexa

On 04/26/2011 07:17 PM, Dane Smith (c1pher) wrote:

c1pher  11/04/27 00:17:00

   Modified: metadata.xml ChangeLog
   Log:
   app-admin/gentoo-rsync-mirror: Updated maintainer info in metadata.


Hmm, I was thinking about removing this package on behalf of 
mirror-admins, because we haven't kept it up to date. Is it actually 
useful to install a few config files?

-Jeremy


Index: metadata.xml
===
RCS file: /var/cvsroot/gentoo-x86/app-admin/gentoo-rsync-mirror/metadata.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- metadata.xml2 Jun 2010 06:42:03 -   1.5
+++ metadata.xml27 Apr 2011 00:16:59 -  1.6
@@ -3,6 +3,12 @@
  pkgmetadata
  herdno-herd/herd
  maintainer
-emailmaintainer-nee...@gentoo.org/email
+   emailc1p...@gentoo.org/email
+   nameDane Smith/name
+/maintainer
+maintainer
+   emailrgkm...@gmail.com/email
+   nameRobert Kowalski/name
+   descriptionProxy Maintainer. CC on bugs/description
  /maintainer
  /pkgmetadata






[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.desc

2011-04-24 Thread Jeremy Olexa

On 04/24/2011 11:22 AM, Michael Sterrett (mr_bones_) wrote:

mr_bones_11/04/24 16:22:55

   Modified: use.desc
   Log:
   remove unused use flags

Revision  ChangesPath
1.458profiles/use.desc



  ppds - Adds support for automatically generated ppd (printing driver) files
-prefix - Defines if a Gentoo Prefix offset installation is used
  prelude - Adds support/bindings for the Prelude Intrusion Detection System


Hello Michael,

Would you mind changing your method to determine un-used USE flags?

% qgrep -H use prefix|wc -l
106
% qgrep -H prefix? |grep -v kdeprefix|wc -l
36

I think it is helpful to have the 'prefix' USE flag description, even 
though users can not/should not mess with it, because people will see it 
in ebuilds, etc.


Thanks,
Jeremy



Re: [gentoo-dev] Disabling locale at emerge output

2011-04-22 Thread Jeremy Olexa

On Fri, 22 Apr 2011 13:31:30 +0200, Tomáš Chvátal wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,
I am quite getting annoyed by bugzilla attached outputs in various
interesting languages like Portugalese or French. I can read Russian 
so

that is at least bit ok :)

I can understand that it might be nice to user to see these messages 
in
their native language, but it gets hell annoying when we have to 
figure

out wtf is going on with their build when they attach it to the bug.


I only spend a minimal amount of time on figuring out what is wrong - 
RESOLVED:NEEDINFO, move on. So, I could care less on what portage does.

-Jeremy

So I would like portage to filter/set environment the way it is 
always

English.

Opinions?

Cheers

Tom





[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/layman: ChangeLog layman-1.2.3.ebuild

2011-04-07 Thread Jeremy Olexa
On 04/06/2011 12:28 PM, Arfrever Frehtes Taifersar Arahesis (arfrever) 
wrote:

arfrever11/04/06 17:28:22

   Modified: ChangeLog layman-1.2.3.ebuild
   Log:
   Fix deprecation warning.


FYI, you changed it to EAPI=3 and left epause() in the ebuild.
-Jeremy




Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

2011-03-27 Thread Jeremy Olexa

On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:

On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexadarks...@gentoo.org  wrote:

On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:


Index: metadata.xml
===
?xml version=1.0 encoding=UTF-8?
!DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd;
pkgmetadata
herdno-herd/herd
maintainer
   emailmaintainer-nee...@gentoo.org/email
/maintainer
/pkgmetadata


Can this practice of adding m-n packages to gentoo-x86 be stopped? If you
add it, take responsibility for it, please. If you don't want to take
responsibility for it, at least find a team that is willing to look after
it.



If you prohibit people from doing that, they'll just commit it
normally, and then remove themselves a week later.


Why does anyone need to *add* a package that is maintainer-needed? This 
is one of the problems of the gentoo-x86 tree - too many 
maintainer-needed packages. It is a bad thing for our users because when 
they submit bugs and/or fixes, they go [generally] unnoticed for ages. 
Also, as you may know, the treecleaner team is constantly fighting 
with removing m-n packages.


The tree has 679 m-n packages. 
http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml




I propose that we should be more aggressive about package.masking (for
removal) all maintainer-needed packages from the tree by doing that
one month after they become maintainer-needed. If someone doesn't
volunteer to take care of it, it probably wasn't important anyway.



That is abit extreme for me (read: I don't have motivation to fight the 
flames), but I wouldn't complain if someone else did it to be honest.


-Jeremy



Re: Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

2011-03-27 Thread Jeremy Olexa

On 03/27/2011 09:08 AM, René 'Necoro' Neumann wrote:


If you cannot find someone else as a maintainer and someone is willing
to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though



% cvs di
Index: metadata.xml
===
RCS file: /var/cvsroot/gentoo-x86/dev-vcs/stgit/metadata.xml,v
retrieving revision 1.1
diff -u -r1.1 metadata.xml
--- metadata.xml6 Mar 2010 15:58:48 -   1.1
+++ metadata.xml27 Mar 2011 18:56:24 -
@@ -3,6 +3,12 @@
 pkgmetadata
 herdno-herd/herd
 maintainer
-  emailmaintainer-nee...@gentoo.org/email
+  emailgen...@necoro.eu/email
+  nameRené 'Necoro' Neumann/name
+  descriptionProxy maintainer, assign bugs/description
+/maintainer
+maintainer
+  emaildarks...@gentoo.org/email
+  descriptionProxy committer, CC bugs/description
 /maintainer
 /pkgmetadata

All yours, pleasure to work with you. Please maintain a relationship on 
relevant bugs and poke me via personal email when I forget to do 
something =D (By the way, I know nothing of this package and will rely 
on you to do the work minus committing, I'll do that for you)


-Jeremy



Re: [gentoo-dev] RFC: Remove .lzma in favor of .xz portage snapshots

2011-03-27 Thread Jeremy Olexa

On 03/04/2011 11:33 AM, Jeremy Olexa wrote:

Hello all, This email is to solicit concerns or thoughts about removing
the .lzma portage snapshots.

The facts:
- Starting on 2011-03-03, I enabled .xz compression on snapshots that
Gentoo makes available[1].
- On 2011-01-05, Mike added[2] .xz support to emerge-webrsync.
- xz-utils is now in the system set[3] anyway and .xz instead of .lzma
should eliminate some confusion for new users.

That is about all I can think of. My opinion is that this is mostly a
cosmetic change (as lzma is generated via xz-utils anyway) but makes
sense given the popular[4] compression choices. I'd like to target
2011-04-01 as the date to turn off lzma generation. After generation is
turned off, the lzma archives will fall off the mirrors in 7 days. Any
concerns?


Done as of today, ahead of schedule because I have time now :)
-Jeremy



Thanks,
Jeremy

[1]: http://gentoo.osuosl.org/snapshots/
[2]:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9ff806
[3]:
http://archives.gentoo.org/gentoo-dev/msg_998b4e7fdf578346bb5cfc66be340f7d.xml

[4]: Without known data to back this up, I'm using the short options of
tar(1) to form some opinion as presented by the community.






Re: [gentoo-dev] rejecting unsigned commits

2011-03-27 Thread Jeremy Olexa

On 03/24/2011 04:59 PM, Mike Frysinger wrote:


this is especially important for the people doing arch keywording
since they make a ton of commits.  i'm looking at you armin76.


One thing I don't get amidst this whole conversation is why I should 
sign a Manifest file when committing KEYWORDS or something equally as 
trivial like deleting ebuilds. By signing the Manifest, I interpret that 
as yes, I committed this Manifest file and yes I trust every hash in 
this Manifest file when in reality, I have no clue if the Manifest file 
is correct because I didn't inspect anything.


Am I missing something?

Thanks,
Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

2011-03-26 Thread Jeremy Olexa

On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:


Index: metadata.xml
===
?xml version=1.0 encoding=UTF-8?
!DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd;
pkgmetadata
herdno-herd/herd
maintainer
   emailmaintainer-nee...@gentoo.org/email
/maintainer
/pkgmetadata


Can this practice of adding m-n packages to gentoo-x86 be stopped? If 
you add it, take responsibility for it, please. If you don't want to 
take responsibility for it, at least find a team that is willing to look 
after it.


Thanks,
-Jeremy



Re: [gentoo-dev] virtual/ffmpeg and media-video/libav

2011-03-23 Thread Jeremy Olexa

On Wed, 23 Mar 2011 15:08:01 +0100, Tomáš Chvátal wrote:

Hi guys,
As there is new ffmpeg fork that is a bit alive we should provide it 
as

alternative to current media-video/ffmpeg.

So libav is stored in media-video/libav (look at it, try to find 
issues

and stuff).

Virtual package is virtual/ffmpeg where now i implemented it to have
versioned dependencies.
So there is virtual/ffmpeg-0.6 virtual/ffmpeg- where the apps can
decide what they need.
Samuli pointed out that we do not slot ffmpeg nor support versioned 
deps

and always demand everything to be working with latest. If you have
strong opinion on that one please express it here so the virtual gets
redesigned to just simple virtual/ffmpeg-0.1 without any version 
stated

in it. I myself like the chance to express the version explicitly.
Virtual itself provide access to all useflags currently used in eapi2
deps. More can be added when required.

For what is libav i would suggest you go to their homepage
http://libav.org/ or poke Diego or Luca whom are actually members of
upstream :)

And finally the list of current dependencies over ffmpeg see in 
attachment.


Cheers

Tomas


When reading about the fork awhile back, I assumed that ffmpeg would 
die and libav would continue in its place. Do we really need a virtual 
for this??

-Jeremy



Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass

2011-03-15 Thread Jeremy Olexa

On 03/15/2011 10:00 PM, Jeroen Roovers wrote:

On Tue, 15 Mar 2011 18:06:36 -0400
Mike Frysingervap...@gentoo.org  wrote:


# The full name and version of the EMBASSY package
(excluding the Gentoo # revision number)
EF=$(echo ${EN} | tr [:lower:] [:upper:])-${PV}


ugh, but i guess we cant do much until we have newer bash


bash 4.1 has been stable for half a year now. Not long enough?

EF=${EN^^}


Not until PMS specifies[1] something other than: The interpreter is 
assumed to be GNU bash, version 3.2 or later


[1]: http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-650007

-Jeremy




Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/libva: ChangeLog libva-1.0.10.ebuild

2011-03-09 Thread Jeremy Olexa

On 03/09/2011 06:08 AM, Alexis Ballier wrote:


Or maybe just piss me off ?


Please calm down. I would have taken some action too if it was in my bug 
queue (via CC) and the primary maintainer didn't respond for 6 months. 
It isn't flaming the users to respond and acknowledge their work but 
politely refusing.


-Jeremy



[gentoo-dev] RFC: Remove .lzma in favor of .xz portage snapshots

2011-03-04 Thread Jeremy Olexa
Hello all, This email is to solicit concerns or thoughts about removing 
the .lzma portage snapshots.


The facts:
- Starting on 2011-03-03, I enabled .xz compression on snapshots that 
Gentoo makes available[1].

- On 2011-01-05, Mike added[2] .xz support to emerge-webrsync.
- xz-utils is now in the system set[3] anyway and .xz instead of .lzma 
should eliminate some confusion for new users.


That is about all I can think of. My opinion is that this is mostly a 
cosmetic change (as lzma is generated via xz-utils anyway) but makes 
sense given the popular[4] compression choices. I'd like to target 
2011-04-01 as the date to turn off lzma generation. After generation is 
turned off, the lzma archives will fall off the mirrors in 7 days. Any 
concerns?


Thanks,
Jeremy

[1]: http://gentoo.osuosl.org/snapshots/
[2]: 
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9ff806
[3]: 
http://archives.gentoo.org/gentoo-dev/msg_998b4e7fdf578346bb5cfc66be340f7d.xml
[4]: Without known data to back this up, I'm using the short options of 
tar(1) to form some opinion as presented by the community.




Re: [gentoo-dev] RFC: Remove .lzma in favor of .xz portage snapshots

2011-03-04 Thread Jeremy Olexa

On Fri, 4 Mar 2011 16:18:40 -0500, Mike Frysinger wrote:

On Friday, March 04, 2011 12:33:08 Jeremy Olexa wrote:

snip
 The facts:
 - Starting on 2011-03-03, I enabled .xz compression on snapshots 
that

 Gentoo makes available[1].
snip


i dont think we're generating .xz yet ... otherwise, let's do it
-mike


It makes me sad that you didn't even read my first bullet point :) Yes. 
We are generating xz snapshots now.

-Jeremy



Re: [gentoo-dev] Adding app-arch/xz-utils to the system set

2011-03-01 Thread Jeremy Olexa

On Mon, 31 Jan 2011 22:33:54 -0100, Jorge Manuel B. S. Vicetto wrote:

Hello.

Given the increased use of lzma compressed files, including on 
portage

snapshots, I'd like to add app-arch/xz-utils to the system set.
We already have a few bugs about requiring xz-utils such as
347557[1] and 305127[2].

 [1] - https://bugs.gentoo.org/show_bug.cgi?id=347557
 [2] - https://bugs.gentoo.org/show_bug.cgi?id=305127

Can anyone think of any reason not to do it?


Well, the interesting bit of info is that the wider developer community 
maybe already assumes it to be in the system set. *OR* can't be bothered 
to remember that it is NOT in the system set. The data to back up this 
statement is in https://bugs.gentoo.org/349315 in which ~20 packages are 
discovered to be missing the build time dep.


So, after 30 days on the mailing list..now does anyone have a reason to 
not do it? The benefits are obvious in my opinion and they all lead to a 
better user experience which should be the main goal. The drawbacks are 
slim, which include but are not limited to, a larger system set [by one 
package].


Let's add it to improve the situation in general.

Thanks,
-Jeremy




[gentoo-dev] Pending removal(?) of media-libs/pdflib

2011-02-21 Thread Jeremy Olexa
The bugs are stacking up[1] and upstream only offers a paid version of 
pdflib-8[2]. It is my understanding that there is no way for us to 
package future versions and the bundled libs are vulnerable[3].


So, should it be removed? For more info, see the tracker bug for its 
removal[1], there are a number of rdeps that will require fixing[4].


[1]: https://bugs.gentoo.org/355971
[2]: http://www.pdflib.com/download/free-software/pdflib-lite-7/
[3]: https://bugs.gentoo.org/253263
[4]: http://tinderbox.dev.gentoo.org/misc/rindex/media-libs/pdflib

Thanks,
-Jeremy



[gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11

2011-02-12 Thread Jeremy Olexa

On 02/04/2011 01:50 PM, Jeremy Olexa wrote:

Hello,

The CVS-RSYNC service has moved hosts and now we generate the
use.local.desc file via egencache. As such, there is no need for this
file to be in CVS anymore and will be removed on 2011-02-11. This email
is meant as a heads up as I am not sure about everyone's individual
setups or what repercussions there might be.

-Jeremy



This file is now removed from CVS.

+  12 Feb 2011; Robin H. Johnson robb...@gentoo.org -use.local.desc:
+  use.local.desc is now generated purely in the rsync tier and is no longer
+  required in CVS. If you were looking to change it, you should be using
+  metadata.xml instead.

If you've been following the thread, you've seen people complain that 
emerge --sync is re-syncing a bunch of files. I've confirmed with 
multiple people that the syncing is normal again, it was just a one time 
hit. I am sorry for that happening, but we now have greater reliability 
in the CVS-RSYNC service. :)


Thanks,
Jeremy



Re: [gentoo-dev] Re: [gentoo-dev-announce] Removing profiles/use.local.desc file from CVS on 2011-02-11

2011-02-06 Thread Jeremy Olexa

On 02/05/2011 08:34 PM, Zac Medico wrote:

On 02/05/2011 02:31 PM, Ryan Hill wrote:

On Sat, 5 Feb 2011 18:04:03 +0100
Luca Longinotticht...@longitekk.com  wrote:



Hi, could any of this cause a (kinda) full resync from the mirrors?
Because an emerge --sync I'm doing now is syncing up _all_ files in the
tree and taking ages on my laptop, on the other hand the emerge --sync
I did yesterday at around 1400 CET just synced the changed files, as
usual... I also tried multiple mirrors, thinking maybe one of them was
the problem, but they all happily continued syncing everything.
At the end of the sync, Portage also processed all the update-files,
which too is strange. All the modification times of the files seem to
have been updated... The date on my system is set correctly, so I can't
really explain why this would suddenly happen, as between yesterday and
today I didn't update Portage or rsync.


I've had this happen twice in a row, last night and today.


The sizes of the snapshot deltas [1] also seem to show an unusually big
change:

  snapshot-20110201-20110202.patch.bz202-Feb-2011 19:57  163K
  snapshot-20110202-20110203.patch.bz203-Feb-2011 19:57  113K
  snapshot-20110203-20110204.patch.bz204-Feb-2011 19:53  1.3M

I guess that something about the master rsync mirror has changed. It
used to be osprey.gentoo.org, but the size of the
snapshot-20110203-20110204.patch.bz2 file on osprey is only 107213 bytes.


I can imagine that the first delta has a large changeset because of the 
process involved. However, it looks normal now, again. It is just part 
of the upgrade path of changing the service to a new host [that does 
things ever so slightly different].


120Ksnapshot-20110202-20110203.patch.bz2
1.4Msnapshot-20110203-20110204.patch.bz2
260Ksnapshot-20110204-20110205.patch.bz2
124Ksnapshot-20110205-20110206.patch.bz2

As for the re-syncing all files thing - I can't reproduce that, though 
I've seen multiple reports. Did it settle down now? (I assume so)


-Jeremy



Re: [gentoo-dev] Lastrite: lince and slmodem

2011-02-01 Thread Jeremy Olexa

On 02/01/2011 07:33 PM, Matt Turner wrote:

On Tue, Feb 1, 2011 at 10:30 PM, Samuli Suominenssuomi...@gentoo.org  wrote:

You can't really expect me to take responsibility for a commit I can't
test.


And I don't.

Maybe you did this already, but it seems like the amount of time spent
masking a package could have been spent poking whoever is supposed to
be maintaining it (Alin Năstacmrn...@gentoo.org
). Admittedly, the last changes to the ebuild came 18 months ago...

Matt



Cmon Matt, a bug open for over 1 year with 12 comments is not enough 
poking for you? Alin is not _overly_ active with Gentoo[1][2] but he is 
active enough that he should have seen the bug reports, but apparently 
doesn't care. Now, at least 3 users care, so if someone could test 
it..that would be nice for their sake.


[1]: 
http://bugs.gentoo.org/custom_userhistory.cgi?matchstr=mrn...@gentoo.org

[2]: http://cia.vc/stats/author/mrness

-Jeremy



[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions

2011-01-27 Thread Jeremy Olexa

On Mon, 24 Jan 2011 13:31:20 +0100, Christian Faulhammer wrote:

Hi,

over the course of the years the x86 (and other architectures as 
well)

has given away permissions to maintainers/teams to mark packages
stable themselves.  As there never was a definitive list what
exceptions exist, I compiled a list of the ones I could get from the
top of my head in [1].  Please yell if you have those
permissions so I can complete the list for reference purposes.

V-Li

[1] http://www.gentoo.org/proj/en/base/x86/exceptions.xml


Probably OT, sorry. Isn't it time we gained this concept of noarch 
for packages that only install text files or packages that don't compile 
anything...

-Jeremy



Re: [gentoo-dev] Slacker arches

2011-01-25 Thread Jeremy Olexa

On Tue, 25 Jan 2011 12:38:03 +0100, Tomáš Chvátal wrote:

Only exception from this rule are toolchain and base-system bugs, 
since


In both threads you recently started, you used the term base-system 
bugs but I think you mean @system packages - there are a ton of 
base-system packages that are not critical and wouldn't apply to either 
of your threads. Is this an accurate assumption on my part here?


-Jeremy



Re: [gentoo-dev] On hosting self-produced distfiles

2011-01-21 Thread Jeremy Olexa

On Thu, 20 Jan 2011 01:50:35 +0100, Diego Elio Pettenò wrote:

snip
Pushing files that are still available somewhere else, but cannot be
directly fetched for whatever reason is still to be bone
through /space/distfiles-local.


This, above, is an important point for the below comment.

*PLEASE NOTE:* This is to be considered QA policy, so we're going to 
ask
soon to enforce this. This requirement, though, _will_ be superseded 
as
soon as Infra provides us with a proper archive for this kind of 
files.


I wonder how the QA team is going to enforce this? I can't think of any 
heuristics to distinguish between mirror://gentoo/self-produced 
distfile and mirror://gentoo/upstream distfile not self-produced - 
One way this can happen is dead upstream but useful application. Yes, we 
have GENTOO_MIRRORS but I've seen it often enough that GENTOO_MIRRORS 
value is invalid (user error) and SRC_URI is invalid which leads to a 
non-ideal user experience - at which point $dev normally changes SRC_URI 
to mirror://gentoo/.


Care to touch on that topic? Note: An acceptable answer to me would be 
update documentation and use common sense because I don't think there 
is any other option. At risk of being too wordy, I'll leave it at that.


Thanks,
Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-java/maven-bin: ChangeLog maven-bin-1.0.2.ebuild maven-bin-1.1-r1.ebuild maven-bin-1.1.ebuild

2011-01-18 Thread Jeremy Olexa
On Wed, 19 Jan 2011 01:58:27 + (UTC), Miroslav Sulc (fordfrog) 
wrote:

fordfrog11/01/19 01:58:27

  Modified: ChangeLog
  Added:maven-bin-1.0.2.ebuild 
maven-bin-1.1-r1.ebuild

  Removed:  maven-bin-1.1.ebuild
  Log:
  dev-java/maven-bin: resurrected version 1.0.2



Index: ChangeLog


+  19 Jan 2011; Miroslav Šulc fordf...@gentoo.org 
+maven-bin-1.0.2.ebuild,

+  -maven-bin-1.1.ebuild, +maven-bin-1.1-r1.ebuild:
+  Resurrected version 1.0.2, reslotted version 1.1 to slot 1.1,
removed version
+  1.1 that was in slot 1.0 and added information about reslotting to 
1.0.2

+  ebuild


There is no reason to add an -r1 just to change the SLOT. There is 
'slotmove' in profiles/updates/ for that.


-Jeremy



Re: [gentoo-dev] mysterious change of system python to python3

2011-01-11 Thread Jeremy Olexa

On Tue, 11 Jan 2011 19:30:03 +0100, Paweł Hajdan, Jr. wrote:
I've noticed at least two forums threads that suggest there might be 
a

bug resulting in automatic flip of system python to python3:

http://forums.gentoo.org/viewtopic-t-859654-highlight-.html
http://forums.gentoo.org/viewtopic-p-6541077.html

Do you think it may be a bug, and if so, how can we debug it?


Both of those threads were on new installs. There was a regression in 
stage building for some time that set python3 as the default system 
python. That was fixed here:


5   01 Jan 2011; Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org
6   python-2.6.6-r1.ebuild:
7   Non-maintainer commit.
8 	Reverting commit that broke stage generation for python-2.6.6-r1 as 
it wasn't

9   reverted before - bug 347867.
10  This commit was accepted by Arfrever.

See also, bug 330655. FWIW, I have recently confirmed that there is 
expected behavior now in the stage3-amd64-20110106 tarball.


-Jeremy



Re: [gentoo-dev] mysterious change of system python to python3

2011-01-11 Thread Jeremy Olexa

On Tue, 11 Jan 2011 20:34:45 +0100, Sebastian Pipping wrote:

On 01/11/11 20:13, Jeremy Olexa wrote:


Both of those threads were on new installs. There was a regression 
in

stage building for some time that set python3 as the default system
python. That was fixed here:

5 01 Jan 2011; Jorge Manuel B. S. Vicetto 
jmbsvice...@gentoo.org

6 python-2.6.6-r1.ebuild:
7 Non-maintainer commit.
8 Reverting commit that broke stage generation for 
python-2.6.6-r1

as it wasn't
9 reverted before - bug 347867.
10 This commit was accepted by Arfrever.

See also, bug 330655. FWIW, I have recently confirmed that there is
expected behavior now in the stage3-amd64-20110106 tarball.


The commit that was reverted was the one breaking the stages (my 
fault).

You may be mixing something up.


Jorge's revert fixed the overall issue that I mentioned and the 
issues that Paweł and Dale are referring to in the very recent 
troubleshooting mediums. I may be mixing up some of the bug numbers, but 
it is hard to keep track of all the python3/stage3 issues. So, at least 
the week of 20101228 stage3's had python3 set as default python and the 
week of 20110106 stage3's had python2.6 again, based on my personal 
testing.


15:06 @darkside_ jmbsvicetto: mr releng. :) the 20101228 i{4,6}86 
stages have python-3.1 set as the default system python. is this 
intended?

15:07  jmbsvicetto darkside_: no :\
15:08  jmbsvicetto darkside_: and that would explain some of the 
recent mails
15:08  jmbsvicetto darkside_: I'll do more tests tonight to see if we 
can fix that

... some days elapsed
13:50  jmbsvicetto darkside_: python-2.6.6-r1 hadn't been reverted. 
Now that it is, stage3 shouldn't have python-3.1 as default


-Jeremy




Re: [gentoo-dev] app-emulation/virtualbox-ose got renamed to app-emulation/virtualbox

2011-01-07 Thread Jeremy Olexa

On 01/07/2011 10:07 AM, Rich Freeman wrote:


Bottom line is that if the goal is to let users of a package know
about a change, -dev-announce is neither sufficient nor on-topic.  At
least, that's my thinking...


I agree, why do I as a reader of gentoo-dev{,-announce} care about vbox? 
I've never used it. I assume the intent was to get the original message 
to vbox USERS, not the general dev population.. :)


-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-geosciences/mapserver: mapserver-5.4.2-r1.ebuild ChangeLog

2010-12-23 Thread Jeremy Olexa

On 12/23/2010 10:58 AM, Justin Lecher (jlec) wrote:

jlec10/12/23 16:58:12

   Modified: mapserver-5.4.2-r1.ebuild ChangeLog
   Log:
   Added missing src_unpack




+src_unpack() {
+   default
+}
+


FYI: This adds no value to the ebuild. The default src_unpack is ran 
when src_unpack() is not defined. 
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/index.html

-Jeremy



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-geosciences/mapserver: mapserver-5.4.2-r1.ebuild ChangeLog

2010-12-23 Thread Jeremy Olexa

On 12/23/2010 01:07 PM, Justin (jlec) Lecher wrote:

On 23/12/10 19:47, Mike Gilbert wrote:

On 12/23/2010 12:18 PM, Jeremy Olexa wrote:

FYI: This adds no value to the ebuild. The default src_unpack is ran
when src_unpack() is not defined.


Unless src_unpack() is exported in one of the many eclasses that ebuild
inherits. In which case this would un-export it and bring the behavior
back to default.



That's right. The magic comes from the loved python.eclass. If it is not
added the webapp.eclass does some things.



You know...I did test the results before posting to the -dev list ;) So, 
yes, I knew that there was a interesting call in src_unpack from the 
ruby eclass, but it didn't change the results. You could add a comment 
on WHY you explicitly define the function in the future, as I am 
guessing no one besides you currently knows.. :)

-Jeremy

% diff -ur mapserver-5.4.2-r1.orig/ mapserver-5.4.2-r1.edit/
File mapserver-5.4.2-r1.orig/.ipc_in is a fifo while file 
mapserver-5.4.2-r1.edit/.ipc_in is a fifo
File mapserver-5.4.2-r1.orig/.ipc_out is a fifo while file 
mapserver-5.4.2-r1.edit/.ipc_out is a fifo
diff -ur mapserver-5.4.2-r1.orig/temp/environment 
mapserver-5.4.2-r1.edit/temp/environment
--- mapserver-5.4.2-r1.orig/temp/environment2010-12-23 
21:25:57.216256714 -0600
+++ mapserver-5.4.2-r1.edit/temp/environment2010-12-23 
21:29:29.858254479 -0600

@@ -297,7 +297,7 @@
 declare -x 
S=/var/tmp/portage/sci-geosciences/mapserver-5.4.2-r1/work/mapserver-5.4.2

 declare -x SANDBOX_DEBUG=0
 declare -x SANDBOX_DENY=
-declare -x SANDBOX_PID=2383
+declare -x SANDBOX_PID=3207
 declare -x 
SANDBOX_PREDICT=/var/tmp/portage/sci-geosciences/mapserver-5.4.2-r1/homedir:/dev/crypto:/var/cache/fontconfig

 declare -x SANDBOX_READ=/:/dev/stdin:/var/tmp
 declare -x SANDBOX_VERBOSE=1
@@ -9371,7 +9371,7 @@
 }
 src_unpack ()
 {
-default
+ruby_src_unpack $@
 }
 strip-flags ()
 {



[gentoo-dev] net-misc/wicd (+deps) needs new maintainer

2010-12-20 Thread Jeremy Olexa
Pretty well used app, I feel. I just don't have extremely mobile laptops 
anymore..and not much motivation to maintain this app.


Many open bugs that could use fixing, upstream is slow to make new 
releases. The person responsible for wicd, gets the following list:


x11-misc/ktsuss
dev-python/python-iwscan
dev-python/python-wpactrl
net-misc/wicd

-Jeremy



Re: [gentoo-dev] net-misc/wicd (+deps) needs new maintainer

2010-12-20 Thread Jeremy Olexa

On 12/20/2010 11:28 AM, Thomas Kahle wrote:

On 11:06 Mon 20 Dec , Jeremy Olexa wrote:

Pretty well used app, I feel. I just don't have extremely mobile laptops
anymore..and not much motivation to maintain this app.


I have both, where should I sign?  Added myself as maintainer, will look
at the boogs after the holidays.


Thanks Thomas. Feel free to ask me questions about the package(s).
-Jeremy


Cheers,
Thomas


Many open bugs that could use fixing, upstream is slow to make new
releases. The person responsible for wicd, gets the following list:

x11-misc/ktsuss
dev-python/python-iwscan
dev-python/python-wpactrl
net-misc/wicd

-Jeremy








[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-firewall/shorewall6-lite: ChangeLog shorewall6-lite-4.4.15.1.ebuild

2010-12-16 Thread Jeremy Olexa
On Wed, 15 Dec 2010 20:06:14 + (UTC), Constanze Hausner (constanze) 
wrote:

constanze10/12/15 20:06:14

  Modified: ChangeLog
  Added:shorewall6-lite-4.4.15.1.ebuild
  Log:
  Version bump as requested by bug #339034. Thanks to Zoltan Karcagi.

  (Portage version: 2.1.9.24/cvs/Linux x86_64)


Hello Constanze,
I know you are new and I know you just did a version bump (which is 
normally just a rename). But, I always look for ways to reduce the 
signal to noise ratio of the packages so that user can quickly get good 
info instead of wading through the garbage. So, the next time you touch 
the shorewall suite, you may want to look all the einfo calls...



src_compile() {
einfo Nothing to compile.
}


This could be rewritten as:

src_compile() { :; }

because why would anyone really care if there is nothing to compile?!


pkg_postinst() {
einfo
einfo Documentation is available at http://www.shorewall.net;
einfo There are man pages for ${PN}(8) and for each
einfo configuration file.


ya, there are man pages for most every app...no need to explictly state 
that.



einfo
einfo You should have already generated a firewall script with
einfo 'shorewall compile' on the administrative Shorewall6.
einfo Please refer to
einfo http://www.shorewall.net/CompiledPrograms.html;
einfo
einfo Known problems:
einfo

http://shorewall.net/pub/${MY_PN}/${MY_PV_TREE}/${MY_P}/known_problems.txt;
}


In general, I think einfo is pretty worthless because of the default 
PORTAGE_ELOG_CLASSES=log warn error value.


A challenge to everyone (myself included): Remove useless messages in 
your ebuilds.


-Jeremy



Re: [gentoo-dev] Disabling auto-bumping of active Python version

2010-12-01 Thread Jeremy Olexa

On Wed, 01 Dec 2010 21:58:20 +0100, Paweł Hajdan, Jr. wrote:

On 12/1/10 9:34 PM, Joshua Saddler wrote:

Catalyst sends automated emails to rel...@gentoo.org from the
various build boxes: dolphin, poseidon, other dev.g.o machines.


So we have some automatic reporting. Can we have a webpage for that, 
or

a mailing list that people can subscribe to?


Before anyone creates a duplicate bug: http://bugs.gentoo.org/329165 ;)
-Jeremy


Idea: make python team receive those emails. ;-)


I am curious how often stage builds fail (how long can they be
broken until we actually care?)


Fairly often, especially in the last couple of months or so. There
were some arches that, last I checked, hadn't had
any new media in several months.


Do we have some bugs or other actions towards fixing those problems?


I see messages like this pretty much every day. Releng is
understaffed on a few arches, which is why no one has time to track
down the errors, fix them, and get the builds completed.


Is it possible to bisect the portage tree and identify a breaking 
commit?


By the way, it would be great to have some kind of continuous
integration for the portage tree, even something very basic, and 
visible

to the public.





Re: [gentoo-dev] PYTHON_DEPEND in EAPI =4, PYTHON_BDEPEND

2010-11-28 Thread Jeremy Olexa

On 11/28/2010 02:15 PM, Markos Chandras wrote:

On Sun, Nov 28, 2010 at 08:32:16PM +0100, Arfrever Frehtes Taifersar Arahesis 
wrote:

I would like to introduce incompatible improvements in syntax of PYTHON_DEPEND 
variable in
EAPI=4. The new syntax will depend on whether given package supports 
installation for
multiple Python ABIs. The extended functionality will replace PYTHON_USE_WITH* 
variables.

[...]


Your changes are far too complicated to me. Python eclass and
consequently writing python ebuilds is a difficult task already.
If you keep adding more and more magic in this eclass,
you will end up supporting and fixing all the python ebuilds by
yourself. Maybe you should consider splitting python eclass
into two separate modules. One for core functionality and
another one which will inherit this core eclass and export
a simple API so the rest of us can use python eclass without
having to study all the documentation for a month.



Ditto, I've already stopped caring about python ebuilds in Gentoo Linux.
-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-fonts/font-misc-misc: ChangeLog font-misc-misc-1.0.0.ebuild

2010-11-23 Thread Jeremy Olexa

On Sat, 20 Nov 2010 17:34:32 + (UTC), Michal Gorny (mgorny) wrote:

mgorny  10/11/20 17:34:32

  Modified: ChangeLog
  Removed:  font-misc-misc-1.0.0.ebuild
  Log:
  Remove redundant version.


Since when is it ok to ignore [easily avoided] repoman warnings?

KEYWORDS.dropped  2
   media-fonts/font-misc-misc/font-misc-misc-1.1.0.ebuild: amd64-linux 
ppc-macos sparc-solaris x64-solaris x86-interix x86-linux x86-macos 
x86-solaris
   media-fonts/font-misc-misc/font-misc-misc-1.1.2.ebuild: amd64-linux 
ppc-macos sparc-solaris x64-solaris x86-interix x86-linux x86-macos 
x86-solaris


which causes issues like https://bugs.gentoo.org/346411

-Jeremy



Re: [gentoo-dev] Re: Restabilizing MIPS

2010-11-15 Thread Jeremy Olexa

On Mon, 15 Nov 2010 14:41:17 -0500, Matt Turner wrote:

snip

I'm not planning an ad-hoc at-random stabilization/keywording spree.

I'd just like to have a stable and tested base system.


Sure, but you have to understand the concerns here. You have no 
long-term plan, you are underestimating the size of the team needed to 
keep a stable tree, and you are new. Do you blame people for raising 
questions and providing tips? No one is trying to stop you here, just 
trying to help.


Maybe an alternative is to keep a stable base system in an overlay 
until you can verify: that it is doable, the mips team can keep up, and 
the team doesn't burn out regarding keywording?


-Jeremy



Re: [gentoo-dev] Restabilizing MIPS

2010-11-14 Thread Jeremy Olexa

On 11/11/2010 05:00 PM, Matt Turner wrote:

Hi,
I'd like to begin stabilizing packages on MIPS. I've gotten acks from
Redhatter, leio, and r0bertz, and Kumba doesn't really care.

What's the best method to go about doing this? Stabilize the system
packages, then remove ~mips from ACCEPT_KEYWORDS in the profiles?
Should we target package versions that aren't stabilized on other
architectures yet, so that we'll have an extended testing period
before they'll come up for stabilization? That is, can I plan to make
gcc-4.5.1 or something the first restabilized version of gcc, go ahead
and begin testing it, and be ready for stabilization when toolchain
requests it?


What is the long term plan here? Stable @system set, stable everything 
currently ~mips keyworded, or something random in between that? I'd 
caution mips keywording here in general as the team is small and seems 
unlikely to keep up from my POV. I'm not being negative, just being 
real. I suppose it is somewhat possible to keep up if the mips team 
dropped some ~mips packages in general and focused on the @system set.


-Jeremy



Re: [gentoo-dev] Re: fat binaries

2010-11-14 Thread Jeremy Olexa

On 11/14/2010 05:41 PM, Thomas Kahle wrote:

On 00:30 Mon 15 Nov , Diego Elio Pettenò wrote:

Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:

I have a package (sci-libs/mpir) whose configure supports building of
fat binaries with both x86 and amd64 assembler in the binary.


Oh the heck are they implemented? If they are FatELF, no they shouldn't
be used, ever, full stop.


They don't tell.  From the manual:

Fat binary, ‘--enable-fat’

Using ‘--enable-fat’ selects a “fat binary” build on x86 or x86 64
systems, where optimized low level subroutines are chosen at runtime
according to the CPU de- tected. This means more code, but gives
reasonable performance from a single bi- nary for all x86 chips, or
similarly for all x86 64 chips. (This option might become available for
more architectures in the future.)


This is useless for Gentoo Users, IMO. Besides, the people that *want* 
this (anyone?) can use 'EXTRA_ECONF=--enable-fat emerge sci-libs/mpir'


-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: metadata.xml ChangeLog quassel-9999.ebuild quassel-0.7.1.ebuild

2010-11-04 Thread Jeremy Olexa
On Thu,  4 Nov 2010 14:33:59 + (UTC), Tomas Chvatal (scarabeus) 
wrote:

scarabeus10/11/04 14:33:59

  Modified: metadata.xml ChangeLog quassel-.ebuild
quassel-0.7.1.ebuild
  Log:
  Introduce logrotate useflag.


Please remove the logrotate useflag, it should NOT be introduced.

https://bugs.gentoo.org/198901 - [TRACKER] Nuking logrotate use flag

-Jeremy



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/blogtk: blogtk-1.0.ebuild

2010-10-28 Thread Jeremy Olexa

On Thu, 28 Oct 2010 11:17:41 -0300, Alexis Ballier wrote:

Good luck if you want to fix these issues, I'm pretty sure there 
are

hundreds of such warnings in the tree.


You mean thousands? There is no real reason to fix these repoman 
warnings in the name of qa ;) Upon commit of an actual worthwhile 
change, the header will be updated automatically. No one needs to 
manually update the header when they commit, I guess that wasn't the 
case in the past because I see the blogtk header had an older date the 
eva's last commit to it. meh, commit stats ftw!


% qgrep -H Copyright 1999-2009 Gentoo Foundation |wc -l
5449
% qgrep -H Copyright 1999-2008 Gentoo Foundation |wc -l
2776
% qgrep -H Copyright 1999-2007 Gentoo Foundation |wc -l
1471
% qgrep -H Copyright 1999-2006 Gentoo Foundation |wc -l
592
% qgrep -H Copyright 1999-2005 Gentoo Foundation |wc -l
313
% qgrep -H Copyright 1999-2004 Gentoo Foundation |wc -l
38
% qgrep -H Copyright 1999-2003 Gentoo Foundation |wc -l
0
% qgrep -H Copyright 1999-2002 Gentoo Foundation |wc -l
0



Re: [gentoo-dev] Bugzilla: Do not allow users to CC arches

2010-10-19 Thread Jeremy Olexa

On Tue, 19 Oct 2010 22:33:17 +0100, Markos Chandras wrote:

Hi

This is getting worse and worse lately. Users tend to CC arches on
various bugs based on their architecture. Is it possible to restrict 
this

kind of option to normal users? Either hide the entire box or disable
the CC button I don't know. It is just get really annoying to see so
many irrelevant bugs in our inboxes

Thank you


Maybe educate users? Here is some sample text, not too hard :)

Hi, removing am...@g.o from CC. Please do not add arches to CC 
yourself. Thanks for your assitance and using Gentoo Linux.


-Jeremy



Re: [gentoo-dev] RFC: fox.eclass update

2010-09-16 Thread Jeremy Olexa
On Thu, 16 Sep 2010 16:24:18 +0200, Matti Bickel m...@gentoo.org
wrote:
 On 09/16/2010 03:31 PM, Matti Bickel wrote:
 --
 Now complete with attachments :)

Hey Matti, few quick things.

* Can you add eclass-manpages documentation?
* econf doesn't need to || die
* What is the mysterious FOXCONF variable in econf for? (could just be
documented? or removed?)







Re: [gentoo-dev] About wormo's situation?

2010-09-16 Thread Jeremy Olexa
On Thu, 16 Sep 2010 23:12:10 +0200, Pacho Ramos pa...@gentoo.org
wrote:
 Hello
 
 I have seen some package metadatas still referring to wormo as their
 maintainer:
 $ grep -r wormo */*/metada*
 app-admin/ulogd/metadata.xml: emailwo...@gentoo.org/email
 app-arch/pdv/metadata.xml:  emailwo...@gentoo.org/email
 www-client/lynx/metadata.xml: emailwo...@gentoo.org/email
 
 
 But, reading http://bugs.gentoo.org/show_bug.cgi?id=72682 looks like she
 retired some time ago. What is her real situation? Should that packages
 be moved to maintainer-needed (if nobody cares about them)? 
 
 Please note that this problem appeared because a user mailed us about
 some unresolved problem with ulogd since a lot of time.
 
 Thanks a lot for clarifying this :-)

Quote from bug: ..increase her activity by proxy-maintaining some
packages and
http://bugs.gentoo.org/custom_userhistory.cgi?matchstr=wo...@gentoo.org
shows recent activity. So, I don't know..have you tried contacting her
via direct email? :) Otherwise if there is no action on bugs, I'd wager
that it is 'ok' for you to fix - especially if you communicate and
willing to fix what you break.

-Jeremy



Re: [gentoo-dev] keepdir /var/run/package/?

2010-08-12 Thread Jeremy Olexa
On Thu, 12 Aug 2010 21:48:04 +0300, Samuli Suominen
ssuomi...@gentoo.org wrote:

 It says Files under this directory, not Files and directories under
 this directory.

Oh, cmon. If you are going to selectively quote, then I'll give you
this: This directory contains system information data describing the
system since it was booted. So in my opinion, it is fine to rm -rf
/var/run/* on system shutdown...

 
 Futhermore is continues with,
 
 Programs may have a subdirectory of /var/run; this is encouraged for
 programs that use more than one run-time file.

 So I'd say keepdir is legal here...

Then the app in question can (and should) make the directory, not the
ebuild.

-Jeremy



Re: [gentoo-dev] RFC: Reviving GLEP33

2010-08-05 Thread Jeremy Olexa

On 08/05/2010 12:22 PM, Matti Bickel wrote:


I guess the point here is that we need a stable version of PMs for a
reasonable time before we switch tree ebuilds to it.
People will hate me if I use EAPI4 functionality in php ebuilds as soon
as councils approves EAPI4. Security might want a word with me if it's a
fast-stable security release.


People will not hate you - if the portage with EAPI4 is in ~arch, you 
can have PHP w/EAPI4 in ~arch, even on zero-day of release. Likewise 
with stable tree. It does not matter when council approves EAPI4, it 
matters when portage has the implementation and is released..


The caveat is with @system packages, especially bash/python/portage itself.

-Jeremy



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/datetime: ChangeLog datetime-2.12.5.ebuild

2010-08-04 Thread Jeremy Olexa

On 08/04/2010 03:05 AM, Peter Volkov wrote:

В Втр, 03/08/2010 в 17:12 -0500, Jeremy Olexa пишет:

On Thu, 29 Jul 2010 20:22:47 + (UTC), Arfrever Frehtes Taifersar
Arahesis (arfrever)arfre...@gentoo.org  wrote:

snip
SRC_URI=http://pypi.python.org/packages/source/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz;
snip


This is a perfect example of over-complexification - Why didn't you
just use D instead of ${MY_PN:0:1} ?


Just take a look at pypi.python.org repository structure. This URL can
be copypasted from one package into another package from the same
repository without any changes...



You can't copy/paste MY_PN, so while you are changing that, is it that 
hard to change *one* more character? Of the 290 ebuilds that use pypi, 
172 of them use MY_PN. 83 use ${PN:0:1} for which your argument holds 
some water. As I said in the original message, I think we should strive 
for user friendly-ness but I guess I might be alone in that opinion. =/


-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/datetime: ChangeLog datetime-2.12.5.ebuild

2010-08-03 Thread Jeremy Olexa
On Thu, 29 Jul 2010 20:22:47 + (UTC), Arfrever Frehtes Taifersar
Arahesis (arfrever) arfre...@gentoo.org wrote:
 snip
 SRC_URI=http://pypi.python.org/packages/source/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz;
 snip

This is a perfect example of over-complexification - Why didn't you
just use D instead of ${MY_PN:0:1} ?

While technically not /wrong/ - it is harder to read for no gain. I'm
confident that our fellow devs can read this but I think we should all
strive for being more user-friendly.

Thanks,
Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-3.1.2_p20100801. ebuild python-2.7_p20100801.ebuild python-2.6.5_p20100801.ebuild

2010-08-02 Thread Jeremy Olexa

   Modified: ChangeLog
   Removed:  python-3.1.2_p20100801.ebuild
 python-2.7_p20100801.ebuild
 python-2.6.5_p20100801.ebuild
   Log:
   remove the backported versions; they're autogenerated, obviously
 not tested for 2.6 (bug 330937, breaking portage for anyone runing
 unstable python at time of commit), and have been the source of a
 shitload of other rather odd bugs till identification of what was
 occuring (bug 330667).  ignoring a PDEPEND.bad for 3.1.2-r3 for
 =app-admin/python-updater-0.8 also to get these removed

 +  -python-2.6.5_p20100801.ebuild, -python-2.7_p20100801.ebuild,
 +  -python-3.1.2_p20100801.ebuild:
 +  Remove untested versions, one of which flat out breaks emerge (bug
 330937).
 +  These should not be re-added without going through devrel/qa.

Hello fellow developers,
There is quite an issue with python here that I want a wider audience
to be aware of because it did affect our users. Especially ~arch users
that were trying to avoid python-3. The intent of this email is purely
FYI.

(You can find a fix on the mentioned bug, if you are wondering)

-Jeremy



Re: [gentoo-dev] News item announcing as-needed (glep 42 stuff)

2010-07-27 Thread Jeremy Olexa

On 07/27/2010 11:51 AM, Jeroen Roovers wrote:

 Since the QA trigger in portage is based on --hash-style=gnu,
you'd have to make that the default as well to find a package
ignoring LDFLAGS...


Put that in the dev profile(s) then. :)
-Jeremy



Re: [gentoo-dev] Git Commit Procedures

2010-07-25 Thread Jeremy Olexa

On 07/24/2010 10:10 AM, Richard Freeman wrote:


I'm trying to make a correction to the devmanual (assuming this is
supposed to be general access) for bug 293629. However, I can't seem to
find where to clone the repository from.


See Git Repositories on http://sources.gentoo.org

or

http://sources.gentoo.org/gitweb/?p=devmanual.git;a=summary



If this isn't supposed to be edited by devs at large, then somebody can
feel free to close that bug. It had been open for ages so I figured I
might just see if I could take care of it.


Attach a patch to bug. That repo is not open for anyone to commit to, 
you have to be a member of the QA team, (or approval from Halcy0n or 
Betelguese)


-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog

2010-07-22 Thread Jeremy Olexa
On Thu, 22 Jul 2010 15:48:51 + (UTC), Thomas Beierlein (tomjbe)
tom...@gentoo.org wrote:
 snip
   elif [[ ${dbnum} -gt 1 ]]; then
   eerror
   eerror You have set ${P} to use multiple database 
 types.
   eerror I don't know which to set as the default!
   eerror You can use /etc/portage/package.use to set 
 per-package USE flags
   eerror Set it so only one database type, mysql, 
 postgres, sqlite3
   eerror
   die Multiple database types selected.

Hello Thomas,
I've just noticed this code snippet. Please don't die here, instead
pick a default if there are conflicting choices in USE.

For reference, please see Conflicting USE Flags section on this page,
http://devmanual.gentoo.org/general-concepts/use-flags/index.html

Thanks,
Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/netbeans: ChangeLog netbeans-6.9-r3.ebuild

2010-07-21 Thread Jeremy Olexa
On Mon, 19 Jul 2010 20:24:40 + (UTC), Miroslav Sulc (fordfrog)
fordf...@gentoo.org wrote:
 fordfrog10/07/19 20:24:40
 
   Modified: ChangeLog netbeans-6.9-r3.ebuild
   Log:
   netbeans-6.9-r3: added support for including custom patches when
 building netbeans

 + # Support for custom patches
 + if [ -n {NETBEANS_PATCHES_DIR} -a -d ${NETBEANS_PATCHES_DIR} ] ; 
 then
 + local files=`find ${NETBEANS_PATCHES_DIR} -type f`
 +
 + if [ -n ${files} ] ; then
 + einfo Applying custom patches:
 +
 + for file in ${files} ; do
 + epatch ${file}
 + done
 + fi
 + fi
 +

Miroslav, You just reinvented the wheel :) Any reason why epatch_user()
from euitls.eclass doesn't work here?
-Jeremy



Re: [gentoo-dev] Re: Over using preserve_old_lib, don't do that

2010-07-15 Thread Jeremy Olexa
On Thu, 15 Jul 2010 15:24:08 +0100, Mike Auty ike...@gentoo.org
wrote:
 snip a bunch of stuff
 If portage offers a way to turn off functionality (like preserving
 libraries), it should actually turn it off, rather than sometimes turn
 it off...

Yes, you are referring to
https://bugs.gentoo.org/show_bug.cgi?id=326275 I do believe this was
already mentioned in the thread. :)

On my build host, I have made preserve_old_lib() do nothing because I
expect my build host to always have the proper linking and it can
tolerate temp breakage as long as my client gets the proper packages in
the end.

-Jeremy



[gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 commit in sci-as tronomy/kapteyn: metadata.xml ChangeLog kapteyn-1 .9.2.ebuild)

2010-07-13 Thread Jeremy Olexa
On Tue, 13 Jul 2010 19:25:51 + (UTC), Kacper Kowalik (xarthisius)
xarthis...@gentoo.org wrote:

   if use doc; then
   insinto /usr/share/doc/${PF}
   doins doc/*.pdf || die

An open question to all:

Should we be hiding pdf's behind USE=doc?? I've seen it here and there
as of late. I thought USE=doc was for compiling docs and/or pulling in
extra deps to build docs.

Thanks,
Jeremy



Re: [gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 com mit in sci-astronomy/kapteyn: metadata.xml ChangeLo g kapteyn-1.9.2.ebuild)

2010-07-13 Thread Jeremy Olexa
On Tue, 13 Jul 2010 12:43:17 -0700, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 On 7/13/10 12:32 PM, Jeremy Olexa wrote:
 On Tue, 13 Jul 2010 19:25:51 + (UTC), Kacper Kowalik (xarthisius)
 xarthis...@gentoo.org wrote:

 if use doc; then
 insinto /usr/share/doc/${PF}
 doins doc/*.pdf || die

 An open question to all:

 Should we be hiding pdf's behind USE=doc?? I've seen it here and there
 as of late. I thought USE=doc was for compiling docs and/or pulling in
 extra deps to build docs.
 
 In my opinion we're never going to have 100% consistency here. I'd say
 let everybody implement it in a way one thinks is the best.

I will highly disagree with this statement. If *WE* are not consistent,
how do the users of the distro know what to expect? Why does this USE
flag have a different standard then the rest?
 
 The description of the flag is Adds extra documentation (API, Javadoc,
 etc). So if something is an extra documentation, it seems to be fine to
 hide it behind USE=doc.
 
 And I'd prefer to keep the meaning of extra documentation flexible and
 open to interpretation, just because there is no obvious benefit to aim
 for 100% consistency here, and overstandardization would be bad.

No obvious benefit besides being consistent to our userbase. Do our
users expect non-consistent USE flags? That sounds bad to me. Sadly, I
think this is a subject that we will never get a consensus on. Maybe
the
description should be changed to:

global:doc: Adds extra documentation (API, Javadoc, PDFs at
maintainer's discretion, etc)

-Jeremy



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/default/linux: make.defaults

2010-07-12 Thread Jeremy Olexa

On 07/12/2010 12:12 AM, Samuli Suominen wrote:

On 07/12/2010 07:53 AM, Jeremy Olexa wrote:

On 07/11/2010 02:50 PM, Samuli Suominen (ssuominen) wrote:

-LDFLAGS=-Wl,-O1
+LDFLAGS=-Wl,-O1 ${LDFLAGS}


My existing, custom, entry for LDFLAGS breaks with this change. Not nice.

%% grep LDFLAGS /etc/make.conf
LDFLAGS=${LDFLAGS},--hash-style=gnu -Wl,--as-needed

-Jeremy


that only worked before because of a fluke (= profiles had only one
LDFLAGS before).
it's not valid to assume -Wl gets passed from previous instance and
leave next ones dangling.



Ok, I thought it was alittle funny to change a variable's behavior 
from non-stacking to stacking. If no one else has a problem with it, I 
will just change my make.conf and get over it. No worries.


-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/default/linux: make.defaults

2010-07-11 Thread Jeremy Olexa

On 07/11/2010 02:50 PM, Samuli Suominen (ssuominen) wrote:

-LDFLAGS=-Wl,-O1
+LDFLAGS=-Wl,-O1 ${LDFLAGS}


My existing, custom, entry for LDFLAGS breaks with this change. Not nice.

%% grep LDFLAGS /etc/make.conf
LDFLAGS=${LDFLAGS},--hash-style=gnu -Wl,--as-needed

-Jeremy



Re: [gentoo-dev] zlib ebuild from OSS-QM

2010-07-06 Thread Jeremy Olexa
On Mon, 5 Jul 2010 18:48:43 +0200, Enrico Weigelt weig...@metux.de
wrote:
 Hi folks,
 snip
 please refer my recent postings on details what the oss-qm
 project is all about. just a few words: the main idea is to
 snip

Enrico, There are actually so many 404s on your homepage (including
both links in your email signature) that it quickly loses my attention
span.

-Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/pedro: metadata.xml ChangeLog pedro-1.5.ebuild

2010-07-02 Thread Jeremy Olexa
On Fri,  2 Jul 2010 23:59:34 + (UTC), Keri Harris (keri)
k...@gentoo.org wrote:
 Index: pedro-1.5.ebuild
 ===
 # Copyright 1999-2010 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/net-misc/pedro/pedro-1.5.ebuild,v
 1.1 2010/07/02 23:59:34 keri Exp $
 
 EAPI=1
 
 inherit eutils

Why do you need to inherit eutils? Nothing uses it.

 
 DESCRIPTION=Pedro is a subscription/notification communications system
 HOMEPAGE=http://www.itee.uq.edu.au/~pjr/HomePages/PedroHome.html;
 SRC_URI=http://www.itee.uq.edu.au/~pjr/HomePages/PedroFiles/${P}.tgz
   doc? ( mirror://gentoo/${PN}-manual-${PV}.tar.gz )
 
 LICENSE=GPL-2
 SLOT=0
 KEYWORDS=~amd64 ~ppc ~sparc ~x86
 IUSE=doc examples
 
 DEPEND=dev-libs/glib:2
 
 S=${WORKDIR}/${P}
 
 src_unpack() {
   unpack ${A}
   cd ${S}
 }

This is the default src_unpack and can be dropped.

 
 src_compile() {
   econf || die econf failed
   emake || die emake failed
 }

econf() doesn't need || die but furthermore, this is the default
src_compile and can be dropped.

 
 src_install() {
   emake DESTDIR=${D} install || die emake install failed
 
   dodoc AUTHORS README
 
   if use doc ; then
   dodoc ${WORKDIR}/${PN}.pdf
   fi
 
   if use examples ; then
   insinto /usr/share/doc/${PF}/examples
   doins src/examples/*.{c,tcl}
   doins src/java_api/*.java
   doins src/python_api/*.py
   fi
 }

Those are just cosmetic fixes above, but this should be fixed:

 * QA Notice: Files built without respecting LDFLAGS have been detected
 *  Please include the following list of files in your report:
 * /usr/bin/pedro
 * /usr/bin/ptick

Thanks,
Jeremy



[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse

2010-06-30 Thread Jeremy Olexa
On Wed, 30 Jun 2010 17:09:00 +0200, Diego E. 'Flameeyes' Pettenò
flamee...@gentoo.org wrote:

 Please check the linked documentation or my blog post[1] on the matter
 if you want to understand the reasoning. I'll be dropping the flag and
 its context from now on if I stumble across it, without further
 warnings.

Hey Diego, (not sure if you are on -dev list or not, therefore adding
you to cc)

What is the consensus on if the metadata.xml specifies that it will add
CFLAGS? Surely it is not as black/white as the global suggests..?

local:debug:app-portage/eix: Build with CXXFLAGS/LDFLAGS for debugging
support; not recommended for normal use.

Thanks,
Jeremy



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/python-openid: python-openid-2.2.4.ebuild

2010-06-28 Thread Jeremy Olexa
On Mon, 28 Jun 2010 19:42:27 + (UTC), Arfrever Frehtes Taifersar
Arahesis (arfrever) arfre...@gentoo.org wrote:
 arfrever10/06/28 19:42:27
 
   Modified: python-openid-2.2.4.ebuild
   Log:
   Fix dependencies.
   (Portage version: HEAD/cvs/Linux x86_64)

Is there any reason you are so non-verbose here? 'cvs log' or '$EDITOR
ChangeLog' equally give us no information about your commit. You are
making it hard on other devs in my opinion, I don't think intentionally,
but can't you just use the ChangeLog more?? At least, that is my small
request and I think others feel the same. If not, I will quietly go back
in my corner.

-Jeremy

 Index: python-openid-2.2.4.ebuild
 ===
 -EAPI=2
 -
 -NEED_PYTHON=2.5
 +EAPI=3
 +PYTHON_DEPEND=2:2.5
  SUPPORT_PYTHON_ABIS=1
 +RESTRICT_PYTHON_ABIS=2.4 3.*
  
  inherit eutils distutils
  
 @@ -22,7 +22,6 @@
   postgres? ( dev-python/psycopg )
   sqlite? ( || ( dev-lang/python[sqlite] =dev-python/pysqlite-2 ) )
  DEPEND=${RDEPEND}
 -RESTRICT_PYTHON_ABIS=3.*




[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dns/bind: bind-9.7.0_p2-r1.ebuild metadata.xml Ch angeLog bind-9.7.1.ebuild bind-9.6.2 _p2.ebuild

2010-06-28 Thread Jeremy Olexa
On Mon, 28 Jun 2010 20:10:45 + (UTC), Christian Ruppert (idl0r)
id...@gentoo.org wrote:
 snip lots
 + gssapi? ( || ( =app-crypt/heimdal-1.2.1-r4
 =app-crypt/mit-krb5-1.6.3-r6 ) )

Christian,

Any reason you aren't using virtual/krb5 ?

-Jeremy



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/python-openid: python-openid-2.2.4.ebuild

2010-06-28 Thread Jeremy Olexa
On Mon, 28 Jun 2010 22:26:17 +0200, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 2010-06-29 04:05:54 Jeremy Olexa napisał(a):
 On Mon, 28 Jun 2010 19:42:27 + (UTC), Arfrever Frehtes Taifersar
 Arahesis (arfrever) arfre...@gentoo.org wrote:
  arfrever10/06/28 19:42:27
 
Modified: python-openid-2.2.4.ebuild
Log:
Fix dependencies.
(Portage version: HEAD/cvs/Linux x86_64)

 Is there any reason you are so non-verbose here? 'cvs log' or '$EDITOR
 ChangeLog' equally give us no information about your commit. You are
 making it hard on other devs in my opinion, I don't think intentionally,
 but can't you just use the ChangeLog more??
 
 It was intermediate commit during my work on python-openid-2.2.5.ebuild.
 python-openid-2.2.4.ebuild has been mentioned in ChangeLog in final commit.

You are correct - 2.2.4 IS mentioned in the ChangeLog during the
subsequent commit. So you think it is ok to hide the first commit under
a ChangeLog entry of Version bump ? I don't see the logic. My issue
with this is that other devs (or users) still don't know how or why the
dependancies got in the 2.2.5 version or what deps were fixed.

In this case, I would have committed a new 2.2.5 version with the
ChangeLog entry of: Version bump, fix python dependancies that are
incorrect in the old or somthing like that. This way commit #1 is not
hidden and placed under a false entry of commit #2.

-Jeremy



Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open

2010-06-21 Thread Jeremy Olexa
On Sat, 5 Jun 2010 17:04:24 +0300, Dror Levin sp...@gentoo.org wrote:

 I'll nominate robbat2, darkside and ferringb.

Dror,
Thanks for the vote of confidence. Now, I realize it is past the
deadline for acceptance but I was not intending to accept after I saw
the current batch of people that have accepted (in a good way). I think
there is a change coming to the Council and I am looking forward to
that. I always expect my free time to diminish in the summer months here
and wouldn't look forward to adding more volunteer time to my sparse
free time.

Thanks again,
-Jeremy



Re: [gentoo-dev] Tone in Gentoo

2010-06-18 Thread Jeremy Olexa

On 06/18/2010 09:25 PM, Sebastian Pipping wrote:


   In #gentoo-infra snip


#gentoo-infra is a private channel and you don't have to be in there. No 
public community members/users are in there. The tone can be anything 
that is acceptable to the normal inhabitants of said channel.


This topic is old and I haven't said anything in the thread until now 
because I didn't have anything to contribute and it looks like you don't 
either. =/


On a final note, no wonder third parties claim[1] that Gentoo Developers 
have an affinity for in-fighting between members. I *strongly* feel that 
instead of threads like this, people can, and should be, leading by 
example and recruiting people that show similar feelings. As Patrick 
said[2], back to bug fixing and using time wisely.


-Jeremy

[1]: http://distrowatch.com/dwres.php?resource=major
[2]: 
http://archives.gentoo.org/gentoo-dev/msg_1c5e5274c6b6cfc2d3683f51c3556a15.xml




Re: [gentoo-dev] Proposing fundamental changes to DevRel

2010-06-16 Thread Jeremy Olexa
On Thu, 17 Jun 2010 02:00:21 +0200, Sebastian Pipping
sp...@gentoo.org wrote:

 yngwin's devaway message still reads
 
   inactive, pending resolution of devrel issue.
 
 yngwin retired.  I woudn't go as far as saying that his case made him
 retire but I definitely say that _DevRel failed on his case_.
 I believe I had enough insight to be able to say.

How do you have enough insight to know this stuff? Was it public? I
consider myself pretty active in the community and don't know a thing
about yngwin's case. It is all pretty vague to me. /me shrugs.

 I would like to propose these fundamental changes to DevRel:
 snip

I can't comment on the rest due to the above.

-Jeremy



Re: [gentoo-dev] FW: [Bug 150091] app-forensics/samhain ebuild issues

2010-06-12 Thread Jeremy Olexa

On 06/12/2010 10:39 PM, sch...@subverted.org wrote:

Why was a valid package removed for an errant comment in the ebuild?
It's not dead upstream, and someone (me) took the time to actually look
at it and note that the issue was at least mostly addressed, except for
the comment.


Hi.

Most importantly, the package had no maintainer to help it along. So, we 
could leave it masked indefinitely (because no dev cared enough to 
improve the ebuild). Or, we could remove it. Cruft in the tree is not ok 
because it helps no one. =/ The package was masked since March, which 
gives more than enough time for another dev to pick it up but since no 
one did, it was treecleaned.


Feel free to write an ebuild for the pending version bump to 2.7.1 and 
then maybe one of the proxy maintainers will help you out for 
gentoo-x86. Also, there is the sunrise project where you can maintain it 
yourself: http://www.gentoo.org/proj/en/sunrise/




Then again, what's one more in my overlay of 54 packages, most of which
have had valid fixes posted for months, if not years?


Shortage of man power will do this, especially for maintainer-needed 
packages. It was not my intent to personally offend you regarding this 
package.


-Jeremy




--dc

- Forwarded message from bugzilla-dae...@gentoo.org -

Subject: [Bug 150091] app-forensics/samhain ebuild issues
Reply-To: DO NOT REPLYdevn...@localhost.invalid
To: sch...@subverted.org
From: bugzilla-dae...@gentoo.org
Date: Sat, 12 Jun 2010 20:04:25 + (UTC)

DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
whose email is mentioned below. To comment on this bug, please visit:

Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=150091
Secure: https://bugs.gentoo.org/show_bug.cgi?id=150091


darks...@gentoo.org changed:

What|Removed |Added

  Status|NEW |RESOLVED
Keywords|PMASKED |
  Resolution||FIXED
   Status Whiteboard|Pending removal 22. 5. 2010 |Pending removal: 2010-05-22




--- Comment #6 from darks...@gentoo.org  2010-06-12 20:04  ---
removed from tree






[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild

2010-06-10 Thread Jeremy Olexa
On Thu, 10 Jun 2010 19:19:33 + (UTC), Arfrever Frehtes Taifersar
Arahesis (arfrever) arfre...@gentoo.org wrote:
 arfrever10/06/10 19:19:33
 
   Modified: traits-3.4.0.ebuild
   Log:
   Fix dependencies. Use -fno-strict-aliasing.
   (Portage version: HEAD/cvs/Linux x86_64)
 
 Revision  ChangesPath
 1.3  dev-python/traits/traits-3.4.0.ebuild

I see no reason to *not* add a ChangeLog entry here. Please, consider
the fact that some people don't want to go digging in cvs log to see who
added -fno-strict-aliasing or why. (as an example. I, personally, don't
care about -fno-strict-aliasing)

-Jeremy



Re: [gentoo-dev] Gentoo stats server/client @ 2010-04-21

2010-04-20 Thread Jeremy Olexa

On 04/20/2010 08:44 PM, Sebastian Pipping wrote:
snip


   Another thing I've been working on is re-shaping the Gentoo code in
   a way that it's now ready to go upstream, at least from my point of
   view.  I have requested permission to merge it in a few hours ago:
   Let's see how upstream thinks about it.

   So that's the news I wanted to share with you.


Great, thanks! I've been waiting for your project to become more 
official for months. :) :)




[gentoo-dev] RFC: Disabling some of our Mail Lists

2010-04-20 Thread Jeremy Olexa

Hello,
As suggested in bug 291860, I am heading up an infra cleanup project to 
disable/close some mailing lists. Since the list is quite large, I want 
to send it out for RFC. A few of the important reasons to disable some 
of our mail lists are:


* Confusing to users because there are so many lists that aren't being 
used. How should you know which one is active without more research?

* More lists means more managing, more spam attempts and infra overhead.

I want to emphasize that the lists will be closed for new posts but the 
archives will remain available. Disabled lists can be re-enabled by 
filing an infra-bugs request. My suggestions to disable are as follows:


gentoo-doc-lt
Reason: Only 1 post, late 2008

gentoo-extreme-security
Reason: Never was a real project, 1 post.

gentoo-doc-id
Reason: Only posts have been 2 spam messages.

gentoo-forum-translations
Reason: 2 posts, 2007.

gentoo-translators
Reason: 3 posts, all spam. 2008

gentoo-arm
Reason: 4 posts total, last 2006. ACKd with team.

gentoo-gwn-fr
Reason: GWN is not active.

gentoo-gwn-pl
Reason: GWN is not active.

gentoo-dev-lang
Reason: 7 posts total, last 2007

gentoo-ia64
Reason: Not active. last 2006

tenshi-announce
Reason: Not used, current release is .11, last used for .4 2006

gentoo-scire
Reason: Dead, last 2008

tenshi-user
Reason: Not used, last 2006

gentoo-media
Reason: Besides spam, last used 2006

gentoo-proctors
Reason: Not used since 2007. 14 message total. ACKd with team.

gentoo-gwn-nl
Reason: GWN is not alive.

gentoo-doc-hu
Reason: Last project commit: 3 years ago, last ML 2007

gentoo-user-kr
Reason: Rarely used, last late 2009 with no reply

gentoo-doc-nl
Reason: last 2007

gentoo-gnustep
Reason: Keep but questionable. Probably be closed during next cleanup

gentoo-xbox
Reason: Dead project

gentoo-cygwin
Reason: Dead Project, last 2008

gentoo-gwn-de
Reason: GWN is not alive.

gnap-dev
Reason: Dead Project, some life recent but..?

www-redesign
Reason: Dead Project

gentoo-gwn
Reason: Dead project

gentoo-installer
Reason: Dead project

gentoo-performance
Reason: Not active, recent spam

gentoo-osx
Reason: Dead project



Re: [gentoo-dev] Python 3.1: Stabilization and news item

2010-03-26 Thread Jeremy Olexa

On Fri, 26 Mar 2010 16:28:29 +, Alec Warner anta...@gentoo.org
wrote:
 On Fri, Mar 26, 2010 at 4:08 PM, Dale rdalek1...@gmail.com wrote:

 As a user, I still think this could turn into a real mess.  I think
there
 will be quite a few that will see python being updated, run
python-updater
 and switch it to the new python.  At that point, it is going to hit the
fan.
  I know because this is what I always do.  News item or not, when
python
 gets updated, I run python-updater and make sure it is selected.
 
 My assumption here is that eselect-python will not let you select v3
 as your python version without some prodding (eg setting stupid
 environment variables or similar.)

Alec, don't assume ;)

 * Messages for package dev-lang/python-3.1.2:

 * 
 * WARNING!
 * Many Python modules haven't been ported yet to Python 3.*.
 * Python 3 hasn't been activated and Python wrapper is still configured
to use Python 2.
 * You can manually activate Python 3.1 using `eselect python set
python3.1`.
 * It is recommended to currently have Python wrapper configured to use
Python 2.
 * Having Python wrapper configured to use Python 3 is unsupported.

%% sudo eselect python set python3.1
%% python --version
Python 3.1.2

-Jeremy



Re: [gentoo-dev] Python 3.1: Stabilization and news item

2010-03-24 Thread Jeremy Olexa

On Wed, 24 Mar 2010 10:32:37 -0700, Joshua Saddler nightmo...@gentoo.org
wrote:
  But everyone else in Gentoo does, so . . .
 
 Some Gentoo developers/users, who aren't Python maintainers, said that
 they didn't object to have Python 3 installed.
 
 They're in the minority, judging by the replies in this thread.

I hate to get into the mix of this, but I suggest researching on vocal
minority and/or silent majority - the most vocal ones on this thread are
the minority of the population. I'm not attacking anyone, mind you.

I haven't expressed anything on this thread but I'm ok with marking it
stable and having concerned users mask it. The stages might get kinda funky
with both python-2 and 3 on them, but..if they are not BROKEN, I don't
care.

-Jeremy



[gentoo-dev] bug-wranglers queue is large

2010-03-23 Thread Jeremy Olexa

Given that the b-w queue is over 200 bugs and some have not been wrangled
for 3 weeks...

Could everyone spend 5 minutes wrangling 5 bugs? (or more if you are
willing :)

Thanks,
Jeremy



[gentoo-dev] misc packages up for grabs

2010-03-23 Thread Jeremy Olexa

I will be moving these to maintainer-needed in a few days. I no longer use
them and have little motivation to fix incoming bugs. Don't bother to ask,
just feel free to change metadata.xml to yourself.

Thanks,
Jeremy

 app-admin/bcfg2
Has a proxy maintainer that I haven't heard from in quite some time.

 app-arch/makeself
No longer use. No updates and nothing to do for this one.

 app-emulation/fuse-utils
 app-emulation/fuse
 app-emulation/libspectrum
Rarely need to do any work. Has a proxy maintainer.

 app-text/pdf2oo
No longer use. No updates and nothing to do for this one.

 dev-python/skype4py
 net-im/skysentials
No longer use. Could use some love. Allows you to SMS from skype.

 net-misc/pytvshows
No longer use.

 sys-apps/kexec-tools
No longer use. Has a herd but could use a dedicated maintainer.

 sys-apps/preload
No longer use, a few open bugs.



Re: [gentoo-dev] [RFC] ebuild function to show package changelog

2010-03-12 Thread Jeremy Olexa

On Fri, 12 Mar 2010 17:59:58 +0100, Matti Bickel m...@gentoo.org wrote:

 As an alternative, let the ebuild provide a variable that points to
 upstreams online Changelog or something, so you as a human can go parse
 it yourself. But then you could also just take the HOMEPAGE variable
 that's already there.

There is an optional changelog tag in metadata.xml.

Should contain a URL where the location of the upstream changelog can be
found. The URL must be version independent and must point to a changelog
which is only updated on new releases of the corresponding package. (This
also implies that one can link to an automatically updated changelog in
case of vcs snapshots only.) 

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=4#doc_chap2

-Jeremy



Re: [gentoo-dev] Handling of keywording bugs with only one arch

2010-03-12 Thread Jeremy Olexa

On Fri, 12 Mar 2010 21:18:03 +0200, Petteri Räty betelge...@gentoo.org
wrote:
 There seems to be two different schools on who to assign a keywording
 bug with only a single arch. I have myself assigned it to the arch in
 question but there's a difference of opinion here:
 http://bugs.gentoo.org/show_bug.cgi?id=272160#c5
 Let's get agreed on a single approach and I will add a note here:
 http://devmanual.gentoo.org/keywording/index.html
 I naturally support the approach I have been doing as I think the arch
 team is the one in charge.

The problem with assigning bugs to arch teams is when the user comments
on the bug after it is resolved. If the arch team is CC'd, they remove
themselves when done and any comments after the bug is closed goes to
someone that is interested. If the arch team is assigned, then the comment
basically goes to /dev/null. So, if we are to improve the user experience,
assign to maintainer and CC arch team.

-Jeremy



Re: [gentoo-dev] Split desktop profile patches news item for review

2010-03-04 Thread Jeremy Olexa

On Thu, 4 Mar 2010 16:52:50 +0200, Theo Chatzimichos
tampak...@gentoo.org
wrote:
snip
 The following issues raised though:
snip
 3) There were no desktop dirs for bsd/prefix etc.

That is not an issue for any prefix profiles. It is this way on purpose.

Thanks,
Jeremy



Re: [gentoo-dev] Re: [RFC] Remove cups from default profile to solve circular deps

2010-03-04 Thread Jeremy Olexa

On Thu, 4 Mar 2010 17:04:17 + (UTC), Duncan 1i5t5.dun...@cox.net
wrote:
 Ben de Groot posted on Thu, 04 Mar 2010 13:28:24 +0100 as excerpted:
 
 On 4 March 2010 08:08, Joshua Saddler nightmo...@gentoo.org wrote:
 Your logic is very thin here. By that same line of reasoning, neither
 are the gtk or qt flags, since you don't need 'em if you're building,
 say, a *box desktop.
 
 Toolkits are more directly useful to a desktop than printing.
 
 Printing is something I'd argue is part of a desktop environment.
 
 And I'd argue it isn't necessarily so.
 
 Indeed.  Some (many?) of us use printing uncommonly enough that it's 
 cheaper to put it on a thumb drive and take it to a printer than buy a 
 printer -- and pay for another $10-30 ink cartridge every time we want
to 
 print something, because the last one dried up between uses.  (I keep 
 thinking I'll buy a laser printer, but never seem to get around to doing

 the research on best supported, etc, and always seem to have other
things 
 to spend the money on.  Besides, the tech keeps getting better, so a bit

 of delay isn't hurting... which I've been saying for years now.  How
many 
 are in a similar position?)

Similarly, I have never *owned* a printer because work or school always
has had free printing. So, my opinion is that the Gentoo default of
USE=cups in desktop profiles is bogus for *my* Gentoo desktops. But, I'm
not a desktop profile consumer anyway because they are sub-optimal, imo. ;)

-Jeremy



Re: [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2

2010-03-03 Thread Jeremy Olexa

Petteri Räty wrote:

On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:

Members of Gentoo Python Project have agreed to deprecate the following 
functions
in EAPI =2:
  - python_version()
  - python_mod_exists()
  - python_tkinter_exists()
  - distutils_python_version()
  - distutils_python_tkinter()

These functions are already banned in EAPI =3.

1. In this week, these functions will start printing deprecation warnings in 
older EAPIs.
2. On 2010-07-01, these functions will start calling die().
   (If any ebuilds in gentoo-x86 still call any of these functions on 
2010-07-01,
then addition of calls to die() will be delayed.)
3. On 2011-01-01, these functions will be removed.



Removing eclass functions like this is not allowed by current policy. If
you want to do it, you should discuss about changing policy.


That is a bogus policy - never heard of it myself, either.

I don't always agree with Arfrever's methods but he has thought this one 
out and has a decent migration plan, imo. Sounds good to me.


-Jeremy



Regards,
Petteri






Re: [gentoo-dev] [RFC] New eclass for x11 packages

2010-02-18 Thread Jeremy Olexa

On Thu, 18 Feb 2010 23:33:42 +0100, Tomáš Chvátal scarab...@gentoo.org
wrote:
 Requires eapi3 or any later when added, so wont work with eapi 012.

Hey, can you explain why you choose to do this and what benefit there is
to doing so? Thanks.
-Jeremy



Re: [gentoo-dev] eutils changes wrt EAPI-3 - ebeep and epause no longer available

2010-02-17 Thread Jeremy Olexa

Maciej Mrozowski wrote:

A as result of discussion http://www.mail-archive.com/gentoo-
d...@lists.gentoo.org/msg37300.html
ebeep and epause functions defined in eutils are not available in EAPI = 3.
For interactive installs, PROPERTIES=interactive should be used instead.



Maybe ebeep and epause should be defined in EAPI=3 but a qa warning so 
things actually get fixed?


Something like this (not tested):

%% cvs di eutils.eclass
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.330
diff -u -r1.330 eutils.eclass
--- eutils.eclass   15 Feb 2010 02:10:39 -  1.330
+++ eutils.eclass   17 Feb 2010 14:13:16 -
@@ -50,6 +50,15 @@
done
fi
 }
+else
+   ebeep() {
+   eqawarn ebeep is not defined in EAPI=3, please file a 
bug at

+   http://bugs.gentoo.org;
+   }
+   epause() {
+   eqawarn epause is not defined in EAPI=3, please file a 
bug at

+   http://bugs.gentoo.org;
+   }

 fi

-Jeremy



Re: [gentoo-dev] Re: eutils changes wrt EAPI-3 - ebeep and epause no longer available

2010-02-17 Thread Jeremy Olexa

On Wed, 17 Feb 2010 19:13:06 +0200, Petteri Räty betelge...@gentoo.org
wrote:
 On 17.2.2010 16.33, Torsten Veller wrote:
 
 
 --- eutils.eclass   15 Feb 2010 02:10:39 -  1.330
 +++ eutils.eclass   17 Feb 2010 14:13:16 -
 @@ -50,6 +50,15 @@
 done
 fi
  }
 +else
 +   ebeep() {
 +   eqawarn ebeep is not defined in EAPI=3, please file
 
 The problem here is that eqawarn isn't defined in EAPI 3.
 
 
 Just shows that committing things to central eclasses without review is
 a bad thing. I improved the code so that it doesn't at least call
 eqawarn without first checking if it exists. Instead of code like this
 in the eclasses, I think this should be done by Portage grepping logs. I
 think it's already running searches over it for gcc things any way.

What is going on with all these undocumented changes? When I look at the
council logs to see what is in EAPI3, I don't see anything about removing
functions. This is just silly and wastes alot of people's time for no
practical gain. In my EAPI3 portage, bin/isolated-functions.sh still has
eqawarn() defined. So, what am I missing now?

Also, other people think it is OK to change the behavior of functions and
not document it in devmanual?

 Regards,
 Petteri



Re: [gentoo-dev] Re: eutils changes wrt EAPI-3 - ebeep and epause no longer available

2010-02-17 Thread Jeremy Olexa

On Wed, 17 Feb 2010 18:11:42 +, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Wed, 17 Feb 2010 18:03:42 +
 Jeremy Olexa darks...@gentoo.org wrote:
 What is going on with all these undocumented changes? When I look at
 the council logs to see what is in EAPI3, I don't see anything about
 removing functions. This is just silly and wastes alot of people's
 time for no practical gain.
 
 Being in eutils, none of this has anything to do with PMS or the
 Council.

So, I was highlighting a problem. No one wants to write docs, which is
quite bad for the health of Gentoo.

 
 In my EAPI3 portage, bin/isolated-functions.sh still has eqawarn()
 defined. So, what am I missing now?
 
 eqawarn has never been defined in any EAPI. It's a Portage internal,
 not something for ebuilds to use. If you'd like it to be in an EAPI, you
 can propose it for EAPI 5.

Yes, correct. For some reason, I thought it was valid to use eqawarn in
ebuilds. Now I guess a valid fix for eutils.eclass would be:

%% cvs di eutils.eclass 
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.333
diff -u -r1.333 eutils.eclass
--- eutils.eclass   17 Feb 2010 17:10:23 -  1.333
+++ eutils.eclass   17 Feb 2010 18:20:18 -
@@ -54,13 +54,11 @@
 else
 
 ebeep() {
-   [[ $(type -t eqawarn) == function ]]  \
-   eqawarn QA Notice: ebeep is not defined in EAPI=3, please
file a bug at http://bugs.gentoo.org;
+   einfo QA Notice: ebeep is not defined in EAPI=3, please
file a bug at http://bugs.gentoo.org;
 }
 
 epause() {
-   [[ $(type -t eqawarn) == function ]]  \
-   eqawarn QA Notice: epause is not defined in EAPI=3,
please file a bug at http://bugs.gentoo.org;
+   einfo QA Notice: epause is not defined in EAPI=3, please
file a bug at http://bugs.gentoo.org;
 }
 
 fi

(where einfo is used because it doesn't need to be logged)

-Jeremy



Re: [gentoo-dev] Remove dev-status of mips profiles

2010-02-11 Thread Jeremy Olexa

On Thu, 11 Feb 2010 10:41:41 -0800, Brian Harring ferri...@gmail.com
wrote:
 On Thu, Feb 11, 2010 at 04:54:38PM +0100, Torsten Veller wrote:
 Can we please move the mips profiles from dev to exp in
 profiles/profiles.desc?
 
 
 The ~150 mips development profiles increase the time for a 
 `repoman -d full` run in dev-perl/ from three to five minutes. That is
 an increase of roughly 66 percent.
 repoman further prints more than 2000 lines of output for two
keywording
 problems.
 
 Quick pcheck visibility scan of the full tree, stats follow:
 
 mips profiles still enabled:
 * 116191 seperate dependency issues, 1 line per profile/dependency 
   issue
 * roughly 2m39s run time
 
 mips profiles disabled (leaving mips-irix however)
 * 9550 seperate dependency issues, 1 line per profile/dependency issue
 * roughly 1m54s run time.
 
 So... mips accounts for about 30% of the pcheck runtime, and *92%* of 
 known visibility issues.  As for the runtime difference between 
 pcheck/repoman, pcheck has some tricks internally to reduce the # of 
 profiles it has to scan down to just the unique USE/mask set- I'd 
 expect the mips impact to be far larger w/out that trick in place.
 
 At the very least if it's going to be kept around, experimental or 
 not, the number of profiles in use there *really* needs reduction- 
 mips has roughly 117 profiles listed in profiles.desc out of 217- 
 literally ~54%  of all dev/stable/experimental profiles.

I agree, I wasn't sure why so many profiles were added[1] for a dead team
(for all intensive purposes). Seems quite silly to me to leave them as
'dev' status. If a member of the mips team would reply to this thread, that
would be good. (and surprising to me :)

I would guess that it would be far easier to work in an overlay at this
point. I would also guess that if there are ANY mips users out there that
they would have to use some other ACCEPT_KEYWORDS value because the shape
of ~mips is so...bad.
-Jeremy

[1]:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/profiles.desc?r1=1.151r2=1.152

 
 Either way, stats to chew on.
 ~harring



Re: [gentoo-dev] [rfc] layman storage location (again)

2010-01-15 Thread Jeremy Olexa

On Fri, 15 Jan 2010 20:36:20 +0100, Sebastian Pipping sp...@gentoo.org
wrote:
 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 don't think it should be changed again. It is quite annoying to have to
hunt down where the $next layman location is.

Why can't layman create /usr/local/portage/layman at runtime if it doesn't
exist and then you can remove the keepdir line from the ebuild??

-Jeremy

 
 I would like to get it right with the next switch.
 Would
 
   /var/lib/layman
 
 do well?  /var/cache/layman seems inadequate as it might not be
 regenerated [2] without losses (as upstream moves along).
 
 Would be great to hear a few opinions.  Thanks!
 
 
 
 Sebastian
 
 
 [1] https://bugs.gentoo.org/253725
 [2] http://devmanual.gentoo.org/general-concepts/filesystem/index.html



Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-11 Thread Jeremy Olexa

On Mon, 11 Jan 2010 20:36:37 -0500, Richard Freeman ri...@gentoo.org
wrote:
 On 01/11/2010 06:30 PM, Arnaud Launay wrote:

 As a newsmaster, I'm a bit concerned by this.
 
 Yeah, inn seems like a really high-profile package to mask for removal. 
   It would be conspicuous in its absence.
 
 Would it make sense to post on -dev BEFORE masking packages like this? 
 I'm sure there are lots of people who would chip in before something 
 like this dies.

(A general reply, not targeted towards you, Rich)

Speaking on behalf of the treecleaners:
The fact is, some of us have never heard of inn and until Gentoo has
some sort of popularity tracking software/tool, the treecleaners will
continue to mask unmaintained software. We can't possible know about every
package in the tree and if it looks like it is unmaintained (open bugs w/o
action) then we will mask it for removal unless someone fixes it and
maintains it.

Let's all move on here and be happy that someone is now maintaining such a
popular package. Thanks jer/rej - I'll add you to metadata so it doesn't
become unmaintained again :) Wasn't there a GSoC project on popularity of
packages? Let's get it implemented already! ;)

-Jeremy

 
 Right now lots of users are going to get errors due to a masked package 
 until somebody takes the initiative to fix it.  I suspect that nobody 
 wants to poke their head up and risk getting it shot off by doing 
 something like that...
 
 Perhaps Gentoo needs a little more of Wikipedia's Be Bold attitude and

 a little less of their delete first and ask questions later attitude.
 
 Note - I'm not suggesting the problem shouldn't be fixed - I'm just 
 suggesting that in this case the solution is worse than the original 
 problem.
 
 Rich



Re: [gentoo-dev] Non-free software in Gentoo

2009-12-28 Thread Jeremy Olexa

Vincent Launchbury wrote:

Hi,

I recently emailed the Gentoo PR team, voicing my concerns about the
amount of non-free software within Gentoo. I got an interesting response
from Sebastian Pipping, who said that while Gentoo is all about choice,
including the choice to install non-free software, the project is
interested in making it easy for people to run a 100% free system,
should they choose that path.

I found out about the license filtering feature in the dev version of
portage, and used it to remove all the non-free software from my
system. However, it wasn't a perfect experience. Based on what Sebastian
had to say, and my own experience using it, I have a few suggestions.

1) Not all of the licenses are completely accurate. For example, the
Linux kernels are listed as soley GPL-2, yet they contain blobs of
non-free firmware. Perhaps a general-purpose not-free license could be
appended to such packages. This would only affect people who choose to
use the feature. It could be minused from the FSF-APPROVED group for
example.

Also relating to this, what is freedist? The package app-text/dos2unix
lists 'freedist' as its license, and /usr/portage/licenses/freedist says
only Freely Distributable. Several other packages do this, and I'm
sure it's not correct. I'm not entirely sure, but I think the dos2unix
package is from http://www.thefreecountry.com/tofrodos/, which clearly
says its GPLv2. Packages like this could be looked into and fixed.


File bugs mate. Licensing is not exactly clear to all users or devs.  As 
can be seen here[1] for dos2unix. It sounds like you care in this area, 
so get involved.


[1]: https://bugs.gentoo.org/show_bug.cgi?id=177822

-Jeremy



2) There are no free versions of the kernel in the main tree. The Latin
American FSF maintains blob-free kernels at
http://www.linux-libre.fsfla.org/pub/linux-libre/releases/. They could
be added alongside the official vanilla ebuilds.

3) Some free software packages bring in non-free optional dependencies
by default. For example, media-gfx/imagemagick brings in
media-fonts/corefonts. As suggested by Sebastian, a free profile could be
created, that changes these defaults, to reduce the hassle of
maintaining a free system. Again, this would only affect users who
choose to use that profile.

4) Using something like ACCEPT_LICENSES=-* @FSF-APPROVED is a good
start, but its quite a hassle to keep checking all the licenses. One
annoyance is packages like sys-devel/gcc. gcc has the libgcc license,
which is just GPLv2+, with some extra permissions granted. Although it's
important to make such a distinction, these extra freedoms are
irrelevant to license filtering.

I suppose the only feasible way to fix this would be to expand the
license groups in /usr/portage/profiles/license_groups. Would it cause
any problems if they were quite large?

Another option might be to introduce an optional IS_FREE=yes/no option
to the ebuild files, which could override the other license settings.

5) Documentation on how to set up and maintain a fully free system could
be added.


To summarize, my general idea is to fix some licensing issues, introduce
the libre kernels and have a 100% free profile that would create the
least possible amount of hassle for anyone using it. This in turn would
make Gentoo more accessible to the free software community, without
affecting people that don't use the profile.

This is my first post here, so I apologize if it's misdirected. I'm not
sure if I'd really be able to help much on the technical side, but if
this garners any cooperation, I'll gladly help out with anything I can.
If someone could point me in the right direction, I'd be very grateful.

Kind Regards,
Vincent Launchbury.







Re: [gentoo-dev] QA last rites for media-gfx/viewer

2009-12-25 Thread Jeremy Olexa

James Cloos wrote:

Diego == Diego E Petten� flamee...@gmail.com writes:


Diego # Fails to build if /usr/X11R6 is not present (bug #247737,

A bit trivial of an issue to drop a package, ja?

The QA team should generate more patches and fewer kills.

-JimC


Also, where is the removal notice on bugzilla? I was going to create a 
version bump bug that blocked the removal bug but it didn't exist. In 
this case, not only did the QA team not create a (seemingly trivial) 
patch, but they didn't even follow standard package removal protocol.


-Jeremy



Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

2009-12-20 Thread Jeremy Olexa

Fabian Groffen wrote:

On 15-12-2009 09:54:36 -0700, Denis Dupeyron wrote:

I will be following up discussions on various mailing lists to prepare
the agenda. If you already want to suggest topics feel free to reply
to this thread. You'll get a second chance with the meeting reminder
approximately two weeks before the meeting. I will be sending a
message about the two topics which did not make it last time and
explain why. I should have sent that much earlier but well... you
know...


I'd like to council to discuss the current *$^!! policy of
-dev-announce and -dev.  I'd propose to at least implement the following
behaviour such that I:
- don't have to see some mails 3 (!) times and many 2 times
- don't get lost where the mail is/was
- get broken threading because the original mail was sent to another
  list

Proposed behaviour:
Aautomatically send all mail sent to -dev-announce to -dev.
Benefits:
- any reply-to hackery for -dev-announce to -dev unnecessary
- being subscrived to -dev alone is enough (alternatively -dev-announce
  can be /dev/null-ed)
- threads are complete, instead of scattered over some lists
- multiple copies can be avoided
- cross-list posting can be reduced to a minimum




In general there are too many mail lists to even care about the 
semantics of -dev-announce. Even this thread is being carried out on 
-dev and -council. Well, that was the attempt, but no one that has 
replied so far is on the -council list so the attempted thread on that 
list is dead too.

-Jeremy



Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat

2009-12-20 Thread Jeremy Olexa

David Abbott wrote:

To nominate anyone for the empty seat, please send an email to the
gentoo-dev ml. Anyone can nominate for the Council, but only current
Gentoo Developers can stand for and vote in the election.


I nominate (in no particular order):
jmbsvicetto
tove
darkside



Flattered, but I decline. I don't agree with the way the Council works 
and don't have motivation to attempt to change it.

-Jeremy



[gentoo-dev] About treecleaners, a status update

2009-12-20 Thread Jeremy Olexa

Hello all,
The treecleaner team wanted to update you all on the status.

Bottom line: We could use more people.

What we do:
The treecleaner team last-rites and removes ebuilds as applicable. The 
reasons for removal are many. If we can trivially fix the package, we 
will try our best.

What we want to do:
We want to be more proactive, instead of reactive. It would be nice to 
seek out packages that haven't been touched in 4 years and do a QA 
audit. Similarly, it would be nice to *look* for bugs instead of just 
wait until they are assigned to us. We also lost the ability to vote on 
packages because all that we see are those that are already broken and 
there isn't enough collective time between us to vote.

How you can help:
If you are interested in joining the team. Stop by #gentoo-treecleaners in
irc 
and look for one of us. You do not need to be a dev to join the team.

Thanks,
Jeremy (on behalf of the treecleaners)



  1   2   >