-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/09/2014 04:07 PM, hasufell wrote:
> I ask the council to vote on banning pkg-config files that would
> be added or renamed downstream (at least this will prevent new
> violations).
I want to repeat my stance from the linked bug that making thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
# Matti Bickel (21 Nov 2013)
# Outdated, beta and abandoned upstream, removal on 20131220
dev-php/PEAR-File_PDF
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
# Matti Bickel (13 Nov 2013)
# Now included in dev-php/phpunit, removal on 20131213
dev-php/DBUnit
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/2013 11:17 AM, Amadeusz Żołnowski wrote:
> Quoting Pacho Ramos (2013-01-17 20:21:30)
>> # Pacho Ramos # Still uses depend.php
>> (#449820), upstream dead for ages and # newer versions don't
>> work. Removal in a month. www-apps/online-bookm
# Matti Bickel (26 Jun 2012)
# Dead upstream. Use any other wiki software like ikiwiki.
# Removal on 26th Jul 2012
www-apps/phpwiki
# Matti Bickel (18 Mar 2012)
# masked for removal in 30 days, ~15 Apr 2012
# unmaintained upstream (bug #396963)
dev-php/PEAR-DB_DataObject_FormBuilder
Hi folks,
I thought I'd throw this out, so nobody is suprised when I start to put
qawarns in the eclass: I don't think php-lib-r1.eclass has any value now
that we have EAPI4. The only thing it basically does is
a) setting RDEPEND="dev-lang/php"
and
b) provide a php_lib_r1_src_install that accepts
# Matti Bickel (16 Jan 2012)
# Now part of dev-lang/php; merge it with USE="intl"
# Removal in 30 days, bug #396975
dev-php/PEAR-I18N
Hi folks,
coming back from an extended vacation I found bug #351266[1] still open.
The root cause of this install failure seems to be libtool trying to
relink php's apache module. I'm not entirely sure what causes this (as
my system doesn't relink the library), but more importantly I failed to
fin
Hi all,
this is a quick note that the php team (well, Ole and me) has decided to
kill of the dev-php5 category.
We think it's confusing and the distinction of which packages go where
isn't as clear as it should be. I find myself regularly looking in
dev-php instead of dev-php5.
As php extensions (
On 01/27/2011 07:42 PM, Tomáš Chvátal wrote:
> Only to gain the ~allarch. When it gains it gets tested by arch member
> of any team and stabled. Verstanden? :)
Yep, I think I did. But what if introduce, say, a non-portable find
command into a new revision that breaks on some arches. I'll carry ove
On 01/27/2011 06:59 PM, Tomáš Chvátal wrote:
> Adding ebuilds with noarch keyword must be preceded with:
> All ebuilds seeking to have this feature implemented must be discussed
> on #gentoo-dev mailing list and proven not having portability issues.
So instead of opening a bug for all arches, I po
On 01/27/2011 05:30 PM, Ciaran McCreesh wrote:
> No, since there's no such thing as an app that's guaranteed to be
> portable.
What about app-doc/php-doc? Yeah, single use case. But I feel stupid
requesting keywords for it. It's all text.
signature.asc
Description: OpenPGP digital signature
On 01/20/2011 09:46 PM, Diego Elio Pettenò wrote:
> So I'm not asking _you_ to waste 90% of your time discussing and
> auditing licenses. We have a team for that.
We do? Cool, I didn't know about that. Which team is it?
> At the same time I'm not going to ask the developers to all evaluate
> case
On 01/20/2011 08:42 PM, Diego Elio Pettenò wrote:
> We do distribute part of our packages as binaries already so we have to
> be compliant with their licenses to begin with. Better doing it with a
> single sweep than trying to come up with abstruse case-by-case points,
> no?
No. Licenses are not a
First, thanks for pointing this out.
On 01/20/2011 07:51 PM, Diego Elio Pettenò wrote:
> License compliance when distributing binaries;
Not sure what you mean: if someone quickpkg's php and needs all the
source? Well, they already downloaded them. Better keep them around,
since it's *your* binary
On 01/20/2011 01:50 AM, Diego Elio Pettenò wrote:
> I just wanted to write here a clarification regarding self-produced
> distfiles, such as patchset tarballs, SCM snapshots and the like. Some
> people seem under the impression that the correct way to host these is
> to use mirror://gentoo/ and cop
On 01/12/2011 02:53 AM, Ajai Khattri wrote:
> C: /usr/bin/php-cgi -v -d session.save_path=/tmp
>
> OK, this is a masked ebuild but what does this actually mean and how can
> we fix it?
Which version of php is this? A
On 12/18/2010 08:35 PM, Ryan Hill wrote:
> On Fri, 17 Dec 2010 15:25:04 +
> Ciaran McCreesh wrote:
>
>> So would anyone be especially opposed to making "best leftmost" an
>> explicit requirement, enforced by repoman where possible (at least for
>> the >= / < case)?
>
> I already thought that
On 10/25/2010 06:23 PM, Petteri Räty wrote:
> On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>> I would like to request that 2 additional features are added to EAPI="4".
>> These features will be needed for further development of python.eclass.
>>
>> 1. Support for "." character
On 10/24/2010 02:07 PM, Samuli Suominen wrote:
> On 10/24/2010 02:48 PM, Matti Bickel (mabi) wrote:
>> -phpconfutils_extension_with "pdo-sqlite" "sqlite" 1 "/usr"
>> +phpconfutils_extension_with "pdo-sqlite" &qu
On 09/20/2010 12:00 AM, Duncan wrote:
> Given that no set eapi is taken to be eapi=0, and this is proposed as part
> of a new eapi, eapi MUST be set before pkg-inherit, if pkg-inherit and
> thus per-pkg eclasses are to be used at all. The last sentence of the top
> paragraph (of the two) should
On 09/26/2010 03:22 PM, Ciaran McCreesh wrote:
> Isn't the amount of work to get per-package eclasses basically the same
> as the amount of work to get per-(package and category) eclasses?
Actually, I don't know. Tell me. I've no clue how much PM implementation
effort this will be, yet.
signat
On 09/19/2010 10:49 PM, Andreas K. Huettel wrote:
>
> Wouldn't it also make sense to have "per-category eclasses"? This
> seems much more useful for me.
Yes, probably. But it'll be enough getting per-package eclasses in,
right now. I'll revisit this when we finally merge dev-php5 and dev-php.
If
On 09/20/2010 07:30 PM, Alec Warner wrote:
> Under the new system I can put the code:
>
> 1) In a global eclass, any ebuild can likely use it
> 2) In a per-package eclass, only one package can use it
> 3) In a pkg eblit, only one package can use it
Per package eclasses are pretty much eblits with
t PMs.
GLEP: 62
Title: Per package eclasses
Version:
Last-Modified:
Author: Matti Bickel
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
Post-History:
Abstract
This document proposes a new kind of eclasses, which are specific to a certain
package (hence "per-pa
On 09/16/2010 09:29 PM, Mike Frysinger wrote:
>> +if [[ -f ${D}/usr/bin/fox-config ]] ; then
>> +mv "${D}/usr/bin/fox-config" "${D}/usr/bin/fox-${FOXVER}-config"
>> fi
>
> seems like you would want || die here
Why? I can't imagine how that could fail.
signature.asc
Descri
On 09/16/2010 08:32 PM, Peter Volkov wrote:
> В Чтв, 16/09/2010 в 16:24 +0200, Matti Bickel пишет:
>> +FOXVER=`get_version_component_range 1-2 ${FOX_PV}`
>
> It's better to prefer $() style over ``:
> http://mywiki.wooledge.org/BashFAQ/082
Hmm, I prefer Backticks p
On 09/16/2010 04:41 PM, Jeremy Olexa wrote:
> Hey Matti, few quick things.
Thanks, all done. FOXCONF is now documented (though not set by default).
Updated diff and eclass attached.
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header
On 09/16/2010 03:31 PM, Matti Bickel wrote:
--
Now complete with attachments :)
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.8 2008/10/12 12:31:36
mabi Exp $
# fox eclass
Hi folks,
The fox eclass accumulated a lot of cruft over the years. Specifically,
it includes quite a bit of code to support versions loong gone from our
tree. The only officially supported versions now are 1.6 and 1.7.
Thus, I've edited it a bit. Main points are EAPI2 phase support and a
lot of
On 08/05/2010 05:27 AM, Brian Harring wrote:
> If a PM encounters an EAPI it doesn't understand/support, by
> definition the metadata it tried generating is not usable- the PM
> doesn't support that new EAPI thus it has zero clue how to
> generate/store metadata appropriately for that EAPI.
I g
On 08/03/2010 12:17 AM, David Leverton wrote:
> On 2 August 2010 22:40, Matti Bickel wrote:
>> On 08/02/2010 08:16 PM, David Leverton wrote:
>>> If so, it sounds like what you really want is per-package eclasses
>>> (maybe with elibs as well to hold the non-metad
On 08/02/2010 10:15 PM, Ciaran McCreesh wrote:
> Aren't you really after per-package eclasses, not elibs?
Yes. I don't care whether the snippets may affect metadata. They already
don't (at one time they did, but we got warned that that's illegal -
that's why php-5.3 ebuilds have their metadata fol
On 08/02/2010 09:51 PM, Mike Frysinger wrote:
> On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible.
>
> current eblits support isnt going anywhere. so
On 08/02/2010 08:16 PM, David Leverton wrote:
> On 2 August 2010 12:11, Brian Harring wrote:
>> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>>> Hi folks,
>>>
>>> I've been told that my use of eblits in dev-lang/php is something
&g
Hi folks,
I've been told that my use of eblits in dev-lang/php is something I
should get rid of as soon as possible. Suggested alternative by ferring:
use elibs.
So here goes: I want to see GLEP33[1] implemented in portage, so I can
shift the eblits core and currently global functions into elibs
On 07/17/2010 09:58 PM, Matti Bickel wrote:
> since there's no dev-lang/php-5.1* version in the tree anymore, this
> eclass is useless. It will be removed on 17th August 2010.
I've just been told by scarabeus that eclass removal is a two years
minimum process. So it'll be rem
Hi,
since there's no dev-lang/php-5.1* version in the tree anymore, this
eclass is useless. It will be removed on 17th August 2010.
signature.asc
Description: OpenPGP digital signature
On 07/17/2010 07:58 PM, Petteri Räty wrote:
>> As the CC'ing should be done by the security folks/the maintainer when a
>> new ebuild is ready, I don't think it needs to be in devmanual. The
>> relevant people should be aware of the process.
>>
> If relevant people already know the policy and act a
On 07/17/2010 07:02 PM, Petteri Räty wrote:
>> Do stabilisations on the security bug so arch team members can skim
>> through their stabilisation list by just looking for secur...@g.o to
>> find the vulnerable packages.
>>
>> V-Li
>>
>
> If you want things to happen this way then it should be at
On 07/10/2010 10:34 AM, Brian Harring wrote:
> If people want to allow eclasses to have fluid APIs (specifically
> removal of functionality), that's a discussion that needs to start on
> the dev level.
>
> Anyone got strong opinions on this one?
The argument was presented a long time before: we
Yeah, we have dropped support for PHP-4 in the tree for ages, but in the
php4 overlay it still lives on.
This is just a reminder that php4 will be even more broken when the
recent patches will get applied. The php team does and will not support
installations running on the php4 overlay and will co
Hi,
yet another patch from Ole in a bid to rid the php eclasses from some
long forgotten code. The patches should be self-explanatory - just rip
out everything related to dev-php4 :)
Comments welcome.
All the work will go into our overlay (slotting branch:
http://git.overlays.gentoo.org/gitweb/?
Hi,
in concert with bug 319623 the php team would like to remove virtual/php
from the depend.php eclass. This will change DEPEND and RDEPEND strings
for quite some packages.
The basic idea is:
virtual/php is only provided by dev-lang/php and has been for quite some
time now. There are no plans to
Late to the party, but anyway:
# Matti Bickel (04 Jul 2010)
# Dead upstream (bug #324825)
# Masked for removal in 30 days
dev-php5/znf
signature.asc
Description: OpenPGP digital signature
On 06/19/2010 09:10 AM, "Paweł Hajdan, Jr." wrote:
> I think that is the point. Is just not being actively hostile a success?
Given our past, yes. Given the size of our project, yes. The sheer size
of the project guarantees that not everybody will like everyone. They
merely get along and no thread
# Matti Bickel (13 Jun 2010)
# Dead upstream (bug #321685)
# Removal on 2010-07-13
dev-php5/jargon
dev-php5/creole
signature.asc
Description: OpenPGP digital signature
On 06/13/2010 10:41 AM, Michał Górny wrote:
> Wouldn't it be better to officially support moving unmaintained
> packages directly into Sunrise? In this case by 'unmaintained' I mean
> those which have open bugs assigned to 'maintainer-needed' for a long
> time, and are potentially a candidates for
On 06/06/2010 12:40 PM, Thomas Sachau wrote:
> My base proposal for this is something like this:
>
> Every package defines the language(s), where it could be installed for
> multiple slots, e.g.:
>
> MULTI_SLOT="python" or
> MULTI_SLOT="python ruby"
>
> Additionally, it should define the suppor
On 05/26/2010 11:01 AM, Duncan wrote:
[Reopening on RESO FIXED bugs as non-reporter]
> That's what clone bug is for... or at least what /I/ use it for.
Resulting in extra work for wranglers. At least for the packages I
maintain, I actually read my bugmail and will respond to comments even
in RESO
On 05/25/2010 10:08 PM, Harald van Dijk wrote:
> NEEDINFO bugs cannot be reopened by other users, even if they provide
> the requested information.
I utterly fail at finding documentation on that. I've recently hit a
problem where a user couldn't reopen a RESO FIXED bug, too. Are bugzi
permissions
On 05/25/2010 10:08 PM, Harald van Dijk wrote:
> http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml
Cool, I clearly not up to date here, I've never thought this to be a
project. Thanks for the link.
Wrt mentioning metadata.xml for herd lookup in there: I've found
willikins' meta -v (in a q
On 05/25/2010 09:33 PM, Mike Frysinger wrote:
> i posted some specific examples already ...
Sure enough. Just wanted to know if there's more to it than build.log
and emerge --info. I'll try to extract something more than that next
time. Goes w/o saying that bug cleanup should be done prior
to assi
On 05/25/2010 08:24 PM, Mike Frysinger wrote:
> they are supposed to be doing basic triage, user feedback
Can you be more specific? I wrangle bugs when there's a need and I'd
like to hear what maintainers want to see on a bug assigned to them.
If info is missing I usually ask for it and assign the
On 05/14/2010 03:34 PM, Samuli Suominen wrote:
> I'd like to see the whole thing go away. It's this one user I've pretty
> much ever seen using it. And he's using it to change "RESOLVED" status
> to "VERIFIED" on e.g. removal bugs, stabilization bugs, keywording bugs...
cleanup++
>> [1] - http:/
On 04/26/2010 11:40 AM, "Paweł Hajdan, Jr." wrote:
> To make it easier to find stabilization bugs with arch-testers'
> comments, I'd like to add new flags to Gentoo bugzilla.
Can you explain how the "TESTED" Keyword is not sufficient for your
goal? It explicitly states: "Ebuilds that have been mar
Nirbheek Chauhan wrote:
> On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel wrote:
>> I rather like the changelogs auto-generated. A method to link my git
>> commit to bugzie would be awesome. I *do* envy debian and others for the
>> auto bughandling they have. Previewing m
Alec Warner wrote:
> On Tue, Apr 13, 2010 at 9:12 AM, Matti Bickel wrote:
>> Nirbheek Chauhan wrote:
>>> From my PoV, editing ChangeLog is like editing history. Complete no-no.
>> It is possible in all major SCMs for a reason. And I (as a user) would
>> laugh at C
Nirbheek Chauhan wrote:
> From my PoV, editing ChangeLog is like editing history. Complete no-no.
It is possible in all major SCMs for a reason. And I (as a user) would
laugh at Changelog entries saying "um, I got that bug number wrong, it
is really #1234". If I (as a developer) log such edits, I'
Zeerak Mustafa Waseem wrote:
> But isn't it the councils purpose to lead gentoo?
It's my understanding that council gets elected to lead gentoo as a
whole. But in the end the one doing the work gets to decide what's going
on (as long as it's intra-project; the only thing i remember where
council g
/me puts on his asbestos underwear
Markos Chandras wrote:
> So the attendance to council meetings is enough to prove that a member is
> active? 0_o
Yes. Anything else is just too hard to measure, imo. If you notice a
council member acting w/o knowing what the heck is going on, then vote
him dow
Hi folks,
this is my first eclass proposal, so rip it apart gently ;)
Disclaimer: the work proposed is NOT my own, but rather contributed by
vapier (see [1] or sys-libs/glibc) and kumba (see [2] or
sys-kernel/mips-sources).
I propose to add eblits.eclass[2] (attached to this message) with the
pu
Alistair Bush wrote:
> I'm not overly concerned about what wiki we use. But may I suggest we
> approach gentoo-wiki to see whether they would like to be involved.
+1, especially the "overly concerned" part. Seriously folks. Just start
it. Take whatever you as a person feel comfortable with. Tal
Alec Warner wrote:
> The above are all pretty easy to do with the data in the tree. Some
> other useful ideas might be:
> - compare open bugs for the package, when was the last bug for a
> package closed (bugs data kinda sucks for this)
An additional search: last touched by assignee between neve
Alec Warner wrote:
> Could we generate a bugzilla search for arch teams? Do arch teams
> already use existing bugzilla functionality?
At least when i was with the ppc team, we had a bugzie search. And
bugzie already sorts your query for you. I guess it could be made to
only show keyword=STABLEREQ
Samuli Suominen wrote:
> if a package is broken, and been in treecleaners queue for too long, and
> it would be a semi-trivial fix, it simply doesn't get done without manpower
Because i can't find this info on the treecleaner project page: is there
a bugzilla query for the "treecleaners queue", so
Ryan Hill wrote:
> I can't find it any more, but that's probably where this idea came
> from. It never really made sense to me but I've done it on several occasions.
me too. I guess it's been handed down for ages.
signature.asc
Description: OpenPGP digital signature
Jeremy Olexa wrote:
> There is an optional tag in metadata.xml.
Good. Seems i'm not the first who thought about that ;)
Yeah, maybe we can get the package managers to display the URLs
corresponding to the atoms to be installed/updated when given a flag.
But maybe that already exists, i haven't ha
Angelo Arrifano wrote:
> What do you people think on a new pkg_changelog function that would
> instruct the ebuild how to retrieve this kind of information from the
> package?
No, please don't. I'm okay with it if your mean "at the end of
emerge -u ", but wouldn't it be pointless to see what chang
Zeerak Mustafa Waseem wrote:
> On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote:
>> A stable user who doesn't want python 3 installed shouldn't have it
>> forced on them. If something is pulling in python-3 then that
>> package needs to have its dependencies fixed. IIRC Portage isn't
>>
e the same no matter who you like best is
> incredibly usefull.
++
Please, do it.
Even an educated guess is better than nothing, raising the probability
bug-wranglers can handle the bug even before it hits other devs' inboxes.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (k
i went for
EAPI=2.
How are other ebuild developers doing this? What's the package manager
ppls take on this?
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgpr5TMoF3mbY.pgp
Description: PGP signature
s -r examples
> to:
> dodoc examples
>
>
> Your comments?
Yes, please. It will simplify dozens of ebuilds and feels 'natural' to
me. Keeping with doins, etc. i would propose to make it
dodoc -r $something
And thanks for your analysis.
--
Regards, Matti Bickel
Sig
Peter Volkov wrote:
> В Вск, 08/02/2009 в 23:06 +0100, Matti Bickel пишет:
> > +# could probably be lower
> > +WANT_AUTOCONF="latest"
> > +WANT_AUTOMAKE="latest"
>
> These are defaults. You don't need to specify them.
>
> > +
Hi,
shame on me, here i'm wondering why noone replies...
Sorry, i failed to send the updated patch o.O
Here's the patch again w/ your suggestions included.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
--- /usr/portage/eclass/fox.eclass 2008-1
ons. Thank you.
And i'll see to fulfill my promise to get gentoo-stats going.
See you on the other side (or some other event around here).
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgpl5mKjPyzyw.pgp
Description: PGP signature
ll have the
same path.. my poor ibook would take too long for such a thing, so
sorry, no data here.
And while your proposal sounds more compliant to the DRY principle, i
would object it on the basis that it makes a single ebuild actually
harder to understand as you have to read (1) eclasses, (2
60? I don't know, and it's not important
at this point) maintainers could move to stable their package themself
IF the automatic tests indicate success AND no arch member has spoken
up.
just my $0.02
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgpaOntcepuKy.pgp
Description: PGP signature
s-manpages
> format.
I also included some eclass-manpage foo now, thanks for the hint.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
--- gentoo-x86/eclass/fox.eclass2008-10-12 14:31:36.0 +0200
+++ fox-proposed.eclass 2008-10-13 20:27:05.0 +0200
@@
of einfo
* apply more variable quoting
I'm sure, I missed one or the other issue. That's why I'm posting it
here for public review. If you have requests or comments to make, please
reply to this thread.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
#
ate the work you, and especially donnie with the
planning, put into this.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgp7xuStDxCE4.pgp
Description: PGP signature
critical i like timely feedback on it,
in a "hey, this has been out for some days, fixes issue X, which is
kind of important to me, could we have a bump in the tree?" kind of way.
I DO get annoyed by "package X has a bugfix release out 5 hours now, why
isn't it in the tr
re only applied for >=2.6.22 and first only if >2.6.20.
The point is that if you stick to "ge" OR "gt", everyone could just skip
reading the comparison and focus on the numbers. Will be fixed in the
next release, along with kernel-2.4 support...
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgpGNkr8MFQEL.pgp
Description: PGP signature
for long. But as long as
they do, they serve as a big reminder in your inbox of what is wrong.
Just my 0.02$
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgpSepMsMY6j8.pgp
Description: PGP signature
# Matti Bickel <[EMAIL PROTECTED]> (18 Sep 2007)
# Masked for removal in 30 days
# Last release 2005, only works with
# unsupported FXRuby-1.0 or -1.2. (bug #177785)
net-irc/xdcc-fetch
Jokey agreed to let it go. This will greatly simplify FXRuby stuff :-)
--
Regards, Matti Bickel
Mike Doty <[EMAIL PROTECTED]> wrote:
> Matti Bickel wrote:
> > Hi,
> > as previously mentioned, ion2 is currently broken (bug #167468) and
> > going away in favour of the soon to be stable x11-wm/ion3.
> >
> > It will be p.masked and removed in 30 days unle
, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgpcllsOLLfLh.pgp
Description: PGP signature
Christian Heim <[EMAIL PROTECTED]> wrote:
> On Wednesday 29 August 2007 21:41:07 Christian Heim wrote:
> maintainer-needed:
> - x11-wm/ion2 (twp)
Will have last-rites this week.
With the advent of ion3 stable in my overlay there's no use to keep it.
--
Regards, Matti Bic
a gentoo developer on it.
Please help Flammie with that :)
--
Regards, Matti Bickel
Encrypted/Signed Email preferred
pgpdWg7s5MB62.pgp
Description: PGP signature
t it to be a atom, else you
have to prefix it with ">=" to be a CPV. If i choose to specify sys-utils/bar
then i get any version of bar, which is fine. If i choose to specify
sys-utils/bar-3 and bar-3 is not a valid atom, repoman cries at me.
Thus, you can continue using the tree j
t's helps your bloodpressure, your fellow
devs and our users. So please stop this nonsense and name-calling.
--
Regards, Matti Bickel
Encrypted/Signed Email preferred
pgprTlgdsqp6P.pgp
Description: PGP signature
is ml..
However, i don't think think his reasoning is justified here. We do
inform the user, everything else is not within our reach. And imho the
license doesn't require more.
If i get a cease and desist over *that*, well, screw it.
--
Regards, Matti Bickel
Encrypted/Signed Email prefer
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> Matti Bickel <[EMAIL PROTECTED]> wrote:
> > How's that? I agree that this timely response clause will mean ion-3
> > will never go stable. That's the only thing i could envision to be a
> > policy violation.
. That's why i'm trying to reach a compromise on those
USE patches we apply. That's why the next build will tell ppl to bug me first.
In general: i don't think forking is an option. I won't be maintaining a fork
myself to begin with. If the general feeling is that ion is un
ttps://lists.berlios.de/pipermail/ion-general/2007-April/001959.html
http://archlinux.org/pipermail/tur-users/2007-April/004634.html
--
Regards, Matti Bickel
Encrypted/Signed Email preferred
Copyright (c) Tuomo Valkonen 1999-2007.
The code of this project is "essentially" license
Robin H. Johnson <[EMAIL PROTECTED]> wrote:
> Taking into account the other reasonable input, how about the name of
> attribute 'automatic-bug' ?
I would like "assign" somewhere in the name, but i'd be fine with your
proposal as well.
--
Regards, Matti Bi
. Will you bring back xmms? Will your program include
last-rites for packages you "convert" over from maintainer-needed?
Oh, and about that "theology" herd - i do find 'theology' a kinda narrow
naming, but that's just me.
--
Regards, Matti Bickel
Encrypted/Signed Email preferred
pgpTVOJsY2bso.pgp
Description: PGP signature
able tennis. Now come over here and beat
> me! No, not far at all, just the other side of Europe, so no excuses :p
I'll be umpire of this. And after that, i'll beat you two :p
We need one more for a double..
--
Regards, Matti Bickel
Homepage: http://www.rateu.de
Encrypted/Signed Emai
s while
testing. Nothing sucks more than us discovering "ups, $maintainer hasn't
tested this code to be endian aware and it goes nuts on my machine" and
the maintainer not responding to it (yes, i'll prod $maintainer
seperatly on IRC, but bugs is just way easier).
--
R
1 - 100 of 119 matches
Mail list logo
