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

2011-04-24 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25-04-2011 00:55, Duncan wrote:
 1)  FEATURES=locale would be off by default, so portage would build with 
 POSIX locale by default.
Will this feature effect the whole build process? This might cause
locale dependent bugs (such as difference of capitalizations in Turkish
or different letter order in some locales causing grep matches to fail)
to go unnoticed.

- -- 
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk208w4ACgkQRh6X64ivZaJ67ACfQrym1J193eQukbMHcm3PSxVw
W6kAn2GERQdAXuKvF/L2xSL8FsTYd9kS
=0Sgu
-END PGP SIGNATURE-



Re: [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 Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Java packages doesn't support slotmove. The slot number is used
extensively everywhere including reverse dependencies.

On 19-01-2011 04:09, Jeremy Olexa wrote:
 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
 
 

- -- 
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk02ZkkACgkQRh6X64ivZaIbbACfRBlAIhUoO27yKNFBkxCp35Hy
m08An18DIFZSINIpTRIVPUWuy42AKH+9
=NFLZ
-END PGP SIGNATURE-



Re: [gentoo-dev] Google Code-In: 13-18 year olds in open source

2010-10-29 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 29-10-2010 20:46, Jorge Manuel B. S. Vicetto wrote:
 As you can see in the link for the current proposals, I've proposed a
 general task of providing translations of our documentation for Portuguese.
 I have a very strong suspicion that most if not all of our non-english
 docs could either benefit from a review or are in need of major work.
 Are there any developers from non english speaking countries that are
 willing to serve as contacts for candidates wanting to translate any of
 the docs on http://www.gentoo.org/doc/en/ to your locale?
As said on IRC I'd love to help Turkish translation if any student
volunteers.

- -- 
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzLE0cACgkQRh6X64ivZaK7ywCeP5VROErro7b8ZwrVPpG5L1tA
pu4AmwXRL2GBxZlI99mfZrprdC/WeGtn
=uP9w
-END PGP SIGNATURE-



Re: [gentoo-dev] libnl v2.x

2010-10-24 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Please use Bugzilla to report and request version bumps.

On 24-10-2010 15:40, Kfir Lavi wrote:
 Hi Marcelo and dev's,
 Looking on libnl website, there is a new release of libnl.

- -- 
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzEKi8ACgkQRh6X64ivZaKWogCdHUzqx1ccKiMESn4opVlSA6ea
XzQAnA5RjRuGWPwpFRrsyrsh8A3U/NnC
=OWzA
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: Moving packages to dev-vcs

2010-03-05 Thread Serkan Kaba
repoman was referencing the main tree for that (or maybe the overlays
additionally) and the issue was fixed when I syced.

2010/3/5 Christian Faulhammer fa...@gentoo.org:
 Hi,

 Serkan Kaba ser...@gentoo.org:
 I'm hitting a repoman failure
 
 repoman: dev-vcs is not an official category.  Skipping QA checks in
 this directory.
 Please ensure that you add dev-vcs to
 /home/firari/Desktop/çalışma/gentoo/gentoo-x86/profiles/categories
 if it is a new category.
 -
 After hitting it for the first time I updated the whole profiles dir
 and still failing

  It is in profiles/categories, so everything should be fine.

 V-Li

 --
 Christian Faulhammer, Gentoo Lisp project
 URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

 URL:http://gentoo.faulhammer.org/




Re: [gentoo-dev] Moving packages to dev-vcs

2010-03-04 Thread Serkan Kaba
I'm hitting a repoman failure

repoman: dev-vcs is not an official category.  Skipping QA checks in
this directory.
Please ensure that you add dev-vcs to
/home/firari/Desktop/çalışma/gentoo/gentoo-x86/profiles/categories
if it is a new category.
-
After hitting it for the first time I updated the whole profiles dir and
still failing

Thanks in advance.
-- 
Sincerely,
Serkan KABA
Gentoo Developer



[gentoo-dev] Last rites: dev-java/adaptx

2009-06-01 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

# Serkan Kaba ser...@gentoo.org (01 Jun 2009)
# Last-rited Bug #272117
# Hard depends on Java 1.4 (Bug #118291)
dev-java/adaptx

- --
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkokEXQACgkQRh6X64ivZaLe7QCfSBWecTEV5FolqQlwkCrUzIni
P1YAnRP7HdzEHPtAICAW7P8ICunc4VIj
=hG19
-END PGP SIGNATURE-



[gentoo-dev] Re: EAPI roadmap

2009-03-22 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thilo Bangert yazmış:
 i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont expect to 
 have en EAPI=2 capable package manager stable within a reasonable 
 timeframe.
2.1.6 is stable and supports EAPI2

- --
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknGHSsACgkQRh6X64ivZaKlRwCfRqdpdvroDZN0OQOycCo1N6Qi
rjcAnRzNxfxQ6SK2pmFRzWbiLYR1rGwW
=LZcB
-END PGP SIGNATURE-



Re: [gentoo-dev] LC_ALL=C Set by default for portage

2009-03-08 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Harald van Dijk yazmış:
 On Sun, Mar 08, 2009 at 09:27:20PM +0100, Alexis Ballier wrote:
 Moreover this would automagically solve the [a-z]  friends regexp
 failures; though that's still good QA to fix them but we wouldn't
 encounter them anymore.
 
 We would encounter them when using the programs outside of portage, but
 not when running the testsuite (if available) from within portage. It
 would succeed in working around compile-time only bugs, but it would be
 a major pain for locale bugs that can also cause problems at run time.
 
 
I agree. There are quite a number of bugs, either compile time or
runtime, that can be spotted and reported to upstream (and hope that
they get fixed) in Turkish locale and I posted on my dev blog why[1]
this happens. I choose to translate the messages after the build.log if
I reproduce the bug only in Turkish locale. If our bug reporting guide
is not guiding people (yeah people don't read docs and especially ones
that are longer than a paragraph and in a language that they can't read)
portage could say a few words on sending the bug report in English if it
spots another locale with the exception of the bug being a locale
specific issue.

1:
http://blogs.gentoo.org/serkan/2008/11/16/applications_failing_with_turkish_locale
- --
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm0kPgACgkQRh6X64ivZaKsKgCfYPtokmwM6G1jyBM1tbBZOrc5
RVwAnAwkHu+nIN4Khtj0lZYgSRnjKiMC
=9n5G
-END PGP SIGNATURE-



Re: [gentoo-dev] when the music's over

2009-03-08 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ali Polatel yazmış:
 Hey everyone,
 It's my turn to say goodbye.
 It's been really nice for two years. I've had great fun and have no bad
 feelings as I leave. This mail is meant as an apology to people who are
 awaiting my return. I'm sorry to let you down.
 So when the fun^Wmusic's over, turn off gentoo^Wthe lights.
 
 Ah.. the reasons? there are no reasons, who needs reasons when you got 
 exherbo?
 
 Goodbye all you people
 There's nothing you can say
 To make me change my mind
 Goodbye
 
It's sad to hear you going. It was a privilege to work with you fellow.
I wish you good luck and success with rest of the life and Exherbo.

- --
Sincerely,
Serkan KABA
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm0mX0ACgkQRh6X64ivZaIwpwCeNtgguX2WbtpBqornpCfMXK5C
1lwAnjWom/lobhgT/Eg/Z5QC5358O5nZ
=BLeo
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Serkan Kaba
2009/2/24 Ferris McCormick fmc...@gentoo.org

 On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
  On Mon, 23 Feb 2009 16:15:25 -0600
  Ryan Hill dirtye...@gentoo.org wrote:
   Can we ban eclasses from setting EAPI?  Is there any case where it
   would be sane?
 
  It's already banned from a QA perspective, but from a package manager
  perspective people have done it in the past and possibly still do do
  it, and the spec doesn't forbid it.
 

 For what it's worth, no eclass in the gentoo-x86/eclass tree sets EAPI.
 I don't know about anyplace else.

 Regards,
 Ferris
 --
 Ferris McCormick (P44646, MI) fmc...@gentoo.org
 Developer, Gentoo Linux (Sparc, Userrel, Trustees)

lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use slot
deps. And I think that's a valid usage.

1:
http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/lucene-contrib.eclass


Re: [gentoo-dev] GCC 4.3 patches will be applied nowish

2009-02-10 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremy Olexa yazmış:
 Surely, at this point we aren't going to let all those bugs hold up
 gcc-4.3 stabilization? Most of which were only found via Diego's
 tinderboxing which implies that no user cares enough about the package
 to report a bug (or no one uses the package).
That can also mean no user of the package upgraded to gcc 4.3 yet.
 
 -Jeremy
 
 

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmR3mEACgkQRh6X64ivZaLeKwCfWawweD0qNm8hEmcP1Ca9pnJW
pM4Anif80hh+C/ETGb1FVYl0jNEyMBj/
=5DRm
-END PGP SIGNATURE-



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomáš Chvátal yazmış:
 On Sunday 30 November 2008 14:23:48 Diego 'Flameeyes' Pettenò wrote:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions) and we
 get rid of the variable for the next EAPI version?
 I would rather see something like:
 
 packagename/metadata.xml
 packagename/package-base.ebuild
I've been thinking of something like this for a long time. It would
greatly improve maintanance (we could put some common ebuild logic
there,too) and reduce the tree size.
 packagename/packagename-version.ebuild
 packagename/Manifest
 packagename/Changelog
 
 Where package-base would store everything basic for the ebuild, licences and 
 so on, and in package-version would be only specific changes for the version 
 (for example patching Makefile).
 
 Variables will be overridable this way and thus i think it would be nicer.
 

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkymmIACgkQRh6X64ivZaKaNQCfYT0Db8zjcIYkzZcPPn83IxMM
UIgAniA8kdc511KJ9eaDNwp8YR7CqKkf
=JcT+
-END PGP SIGNATURE-



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tobias Scherbaum yazmış:
 Jan Kundrát:
 Diego 'Flameeyes' Pettenò wrote:
 I have a very quick proposal: why don't we move the packages' homepage
 in metadata.xml (since it's usually unique for all the versions)
 I believe the reason was that HOMEPAGE might change with new versions 
 and that metadata.xml didn't (doesn't?) support version-specific data.
 
 In most (nearly all?) cases a HOMEPAGE change does also affect older versions.
 Does someone have an example where older versions stay at an old homepage
 and newer versions moved to a new homepage? Which (and how many) packages 
 would be affected by that?
 
 If this does affect a larger number of packages (i doubt so) we might add 
 something like this:
 link type=homepage:oldhttp://package.oldbarfoo.org/link
 or we allow more than 1 homepage item to be specified of which we can
 use the title attribute to describe for which versions this homepage
 item applies. Anyways, all of these would only be quick hacks for a
 rather short timeframe which it takes to stable a new version and remove
 the older one.
 
 In general I do like that proposal, especially the addition of further
 links for bug trackers, forums, irc-channels, gentoo-specific
 documentation and so on.
 
   Tobias

I don't know if there are others but I can give one specific example,
sun-{jdk,jre-bin} where homepage differs in SLOT's
1.4 pointing to http://java.sun.com/j2se/1.4.2/ , 1.5 to
http://java.sun.com/j2se/1.5.0/ , 1.6 to http://java.sun.com/javase/6/
and 1.7 will probably have something new.

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkym5wACgkQRh6X64ivZaKyWQCbBuzASFIYg+Ua5rifXVbig0RA
c+wAnRdETeKiyDESLKspQ52uNAHx+HrL
=OPAH
-END PGP SIGNATURE-



Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Volkov yazmış:
 В Вск, 30/11/2008 в 14:50 +0100, Tobias Scherbaum пишет:
 In most (nearly all?) cases a HOMEPAGE change does also affect older 
 versions.
 Does someone have an example where older versions stay at an old homepage
 and newer versions moved to a new homepage?
 
 Yes. This is quite a common case when one upstream stopped development
 of the package and new developer took it. traceroute, flow-tools are
 just examples from the top of my head. I remember I saw more such
 things...
 
 Also sometimes it's useful to have different HOMEPAGE for different
 versions.
 
 
 And in general, Diego. What are you trying to improve with this change?
 The original intention was to separate common information from all
 ebuilds into metadata.xml. But obviously, HOMEPAGE changes from ebuild
 to ebuild. Now if intention is separate some information from ebuild
 into metadata.xml then, please, tell me what is the criterion for such
 information? Why not LICENSE? Currently I don't think this change worth
 our efforts...
 
LICENSE should definetely be avoided to be defined per-package. Upstream
may decide to relicense new version of packages.
- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkyrJ0ACgkQRh6X64ivZaI4EwCfWECIM3Hecu04yHCeoCKEJqki
VMQAnj+aIeQ5Bf9cA0iQm/wT8U7hZWAV
=wW6Q
-END PGP SIGNATURE-



Re: [gentoo-dev] Please avoid absolute paths in patched filenames

2008-11-17 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This check was added to epatch all of a sudden breaking all working
patches in the tree, although defending those patches having absolute
paths, we as Java team had several bugs filed due to that. Maybe the
tree should be scanned for those and fixed.

Diego 'Flameeyes' Pettenò yazmış:
 I ask it here as a favour, please avoid using absolute paths in the
 filenames of patched files. This mean avoid having stuff like
 
 --- foobar/foo.c
 +++ /tmp/foobar/foobar.c
 
 This tends to break from time to time, and I had to fix at least three
 packages since I started my treewide build for these problems. I already
 asked Zac about adding such a check on repoman, but in the mean time I'd
 like to ask here for people to verify their packages.
 
 I actually am culprit of doing this some time ago but I learnt my lesson
 the hard way :P My suggestion for everybody else is to use quilt when
 you need to write patches.
 
 And if you have patches with the filenames like I shown above, you can
 change it the git way so that it becomes:
 
 --- a/foobar/foo.c
 +++ b/foobar/foo.c
 
 and the problem is usually solved.
 
 Thanks,

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkhxhgACgkQRh6X64ivZaK4wwCeIUCZ6BIqWvo7tiFXpXa+Njpe
AL4An2E5N+yGaIfv1kPaV4Gc9W8DG3M3
=2nhY
-END PGP SIGNATURE-



Re: [gentoo-dev] Please avoid absolute paths in patched filenames

2008-11-17 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mart Raudsepp yazmış:
 On Mon, 2008-11-17 at 20:24 +0100, Diego 'Flameeyes' Pettenò wrote:
 I ask it here as a favour, please avoid using absolute paths in the
 filenames of patched files. This mean avoid having stuff like

 --- foobar/foo.c
 +++ /tmp/foobar/foobar.c

 This tends to break from time to time, and I had to fix at least three
 packages since I started my treewide build for these problems. I already
 asked Zac about adding such a check on repoman, but in the mean time I'd
 like to ask here for people to verify their packages.

 I actually am culprit of doing this some time ago but I learnt my lesson
 the hard way :P My suggestion for everybody else is to use quilt when
 you need to write patches.

 And if you have patches with the filenames like I shown above, you can
 change it the git way so that it becomes:

 --- a/foobar/foo.c
 +++ b/foobar/foo.c

 and the problem is usually solved.
 
 Could you please expand on what the actual problem is for reference,
 having never seen them fail myself or hear any fail for others?
 
 

See bug #237667 and dev-thread
http://archives.gentoo.org/gentoo-dev/msg_777d416bb082a45b0e4848d8db5bfec8.xml

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkiSXEACgkQRh6X64ivZaJfgACfbA/wjlEoldGyZUaDev0jXyng
/SkAoIHS1c8x2bAHbeFDO+r4M8NIK++R
=+Ho/
-END PGP SIGNATURE-



Re: [gentoo-dev] Remember: workarounds don't warrant RESO FIXED!

2008-11-16 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think, resolving as UPSTREAM might be more logical as we can't force
every upstream to fix their *borked* build system and the bug will be
left open forever.

Diego 'Flameeyes' Pettenò yazmış:
 Guys, please remember that if you work something around, you should
 _not_ close the bug as RESO FIXED but keep the bug open so that the
 issue can be addressed and fixed _properly_. Otherwise we'll end up with
 ebuilds full of workarounds without even documentation on why the
 workaround is applied!
 
 With workarounds I mean, as examples:
 
 - FEATURES=test failures;
 - broken parallel make that requires -j1;
 - flags filtering, included -Wl,--no-as-needed appending
 
 This is important because:
 
 a) we want test to work or get fixed upstream;
 b) we want users to get parallel build if they request parallel build;
 c) we want --as-needed to be used, not ignored.
 
 If the bug is open and comes out on searches and all the rest, then we
 have higher chances that someone might _fix_ it, without having to look
 to see if there actually is one...
 
 Thanks!
 

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkgTssACgkQRh6X64ivZaJq7gCfUSK2fcYQTXeddGfcM0xBLx2S
elQAn3S0hc62XuLrubvpn7kCQhwfiIim
=mvB8
-END PGP SIGNATURE-



[gentoo-dev] Last rites: dev-java/gnu-jaxp

2008-10-09 Thread Serkan Kaba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

# Serkan Kaba [EMAIL PROTECTED] (09 Oct 2008)
# Masked for removal in 30 days (see bug #240734)
# Included in gnu-classpath. No reverse dependencies.
dev-java/gnu-jaxp

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjuYDIACgkQRh6X64ivZaIjwACfaNteORON2imPDWYDz5cx/NmD
4gAAn38zmiCdJEj7Z6GqtOb8SgdDR1lv
=ZoVi
-END PGP SIGNATURE-



[gentoo-dev] Breakages due to new epatch behavior

2008-09-25 Thread Serkan Kaba

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The fix applied for bug 237667 casued all patches that have a full path
(other than /dev/nul) either on the left or right hand side to fail.
Bugs 238648, 238464, 238402 were caused because of that and I fixed 3
more patches under dev-java. There seems to be many more of those in the
tree.

So, please revert the commit because stable ebuilds are also victims of
the change.

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjcA54ACgkQRh6X64ivZaIafQCbBun0BffGVj5YhQt0+WOG8XDq
M5gAn0OtIECLHRENDT02LNsmmdZjYOv7
=aQAt
-END PGP SIGNATURE-



Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins

2008-09-15 Thread Serkan Kaba

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Can you add it to #gentoo-tr. seqizz is the channel founder.

Thanks.

Robin H. Johnson yazmış:
| Hi folks,
|
| Sorry that it's taken this long to get completed, but the Jeeves
| replacement, Willikins, is finally 99% done, and ready to join lots of
| channels.
|
| Getting the bot out there
| -
| If you would like to have the new bot in your #gentoo-* channel, would
| each channel founder/leader please respond to this thread, stating the
| channel name, and that they are the contact for any problems/troubles.
|
| Bug reports
| ---
| Please open a bug in the Gentoo Infrastructure product, using the
| 'Other' component, and assign it directly to me.
|
| Custom bot functionality:
| -
| Here's all the functionality that we have assembled, beyond the standard
| rbot stuff.
| Bugzilla
| 
| !bug [ZILLA] ID
| Looks up bug #ID in the per-channel default or specified bugzilla.
|
| !bugstats [ZILLA]
| Totals of bugs per the bugzilla 'status' field.
|
| !archstats [ZILLA] [STATUS] [RESO]
| Totals of bugs per architecture, optionally with some specific set of
| status or resolution values, comma delimited.
|
| status = OPEN, DONE, UNCONFIRMED,NEW,ASSIGNED,REOPENED, RESOLVED,
VERIFIED, CLOSED
| Reso = FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME,
|CANTFIX, NEEDINFO, TEST-REQUEST, UPSTREAM
| zilla = gentoo xine sourcemage redhat mozilla kernel fdo abisource
| apache kde gnome
| If you want another bugzilla, file a bug.
|
| Gentoo-specific
| ===
| !meta [-v] [CAT/]PACKAGE
| Print the metadata and optionally herd members for a given package.
|
| !changelog [CAT/]PACKAGE
| Changelog stats for a package
|
| !devaway list
| List all away developers.
|
| !devaway DEVNAME
| Display .away message for a single developer.
|
| !herd HERD
| Show herd members
|
| !expn NAME
| Show the expansion of any public Gentoo mail alias
|
| !glsa GLSAID
| Shows the title and external IDS for any given GLSA ID.
|
| !earch [CAT/]PACKAGE
| Earch output for a given package
|
| !rdep [CAT/]PACKAGE
| Reverse RDEPEND for a given package
|
| !ddep
| Reverse DEPEND for a given package
|
| What isn't supported yet
| 
| 1. !glsa -s TEXT
| This used to search for GLSAs that matched that string in their title or
| external IDS.
|
| 2. New bug announcements
| Jeeves used to announce brand new bugs to #gentoo-bugs as well as
| targeted channels or users, depending on the product, component,
| assignee, cc and a number of other factors (deeply nested if/else
| trees). The old implementation had this in code entirely, and it would
| be nice to avoid having to modify the code whatsoever, and instead have
| some domain-specific language for doing this.
|
| Source availability
| ---
| Gentoo specific:
| http://git.overlays.gentoo.org/gitweb/?p=proj/rbot-gentoo.git
| Bugzilla support:
| http://git.overlays.gentoo.org/gitweb/?p=proj/rbot-bugzilla.git
| (flameeyes has his own tree as well, but he's been sick lately, so it
| was lagging behind my development)
|
| Right now, if you want to run your own instance of the bot, you will
| need the latest Git tree of the rBot itself, as upstream only fixed the
| last remaining issue a couple of hours ago.
|
| Thanks to
| -
| solar:
| Running the old Jeeves Eggdrop till now, and helping to document all of
| the Eggdrop functionality we used.
|
| flameeyes:
| Bugzilla plugin development
|
| halcy0n:
| Gentoo-specific stuff
|
| tango_, jsn-:
| (rbot upstream developers) For fixing the bugs as I found them :-).
|

- --
Sincerely,
Serkan KABA
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjPEZkACgkQRh6X64ivZaKG6ACaAkFRNsOY4dOrc3TiUm51xLBs
CXAAn3laozO4uamWVmDWCcXCCLzb7Auy
=zIAm
-END PGP SIGNATURE-