-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 this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
# Matti Bickel m...@gentoo.org (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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
# Matti Bickel m...@gentoo.org (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 pa...@gentoo.org # Still uses depend.php
(#449820), upstream dead for ages and # newer versions don't
work. Removal in a month.
# Matti Bickel m...@gentoo.org (26 Jun 2012)
# Dead upstream. Use any other wiki software like ikiwiki.
# Removal on 26th Jul 2012
www-apps/phpwiki
# Matti Bickel m...@gentoo.org (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 m...@gentoo.org (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
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 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/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 post
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 over
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 copy
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*
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
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? All
On 12/18/2010 08:35 PM, Ryan Hill wrote:
On Fri, 17 Dec 2010 15:25:04 +
Ciaran McCreesh ciaran.mccre...@googlemail.com 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
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 . characters in names
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 sqlite3 1 /usr
That's a regression (because USE=sqlite3 is deprecated
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/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.
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/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
Title: Per package eclasses
Version:
Last-Modified:
Author: Matti Bickel m...@gentoo.org
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-package
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
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
#
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 personally, as I like to conserve
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
Description:
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
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 08/02/2010 08:16 PM, David Leverton wrote:
On 2 August 2010 12:11, Brian Harring ferri...@gmail.com 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
I should get rid of as soon as possible
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 dont waste time trying to
change
On 08/03/2010 12:17 AM, David Leverton wrote:
On 2 August 2010 22:40, Matti Bickel m...@gentoo.org 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-metadata code), which
aren't
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 least
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
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 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 removed 17th August 2012
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
Late to the party, but anyway:
# Matti Bickel m...@gentoo.org (04 Jul 2010)
# Dead upstream (bug #324825)
# Masked for removal in 30 days
dev-php5/znf
signature.asc
Description: OpenPGP digital signature
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
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:
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
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
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 the
# Matti Bickel m...@gentoo.org (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/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 supported slots,
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 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/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
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
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/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] -
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 marked as
Nirbheek Chauhan wrote:
On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel m...@gentoo.org 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 more than a raw
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'm
Alec Warner wrote:
On Tue, Apr 13, 2010 at 9:12 AM, Matti Bickel m...@gentoo.org 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 Changelog entries saying um
/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 down
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
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
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. Talk
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 never
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
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 atom, but wouldn't it be pointless to see what
Jeremy Olexa wrote:
There is an optional changelog 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
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
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
greedy
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 (key 4849EC6C
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
}
doins -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
Signed/Encrypted email
Peter Volkov p...@gentoo.org 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.
+ eautomake || die automake error
eautomake dies on its own
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-10-12 14:36
.
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) -base.ebuild
and (3) -version.ebuild.
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key
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
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
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
@@ -1,8 +1,12 @@
# Copyright 1999-2005
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)
# Copyright 1999
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 tree yet!!? - but i don't get those bump requests...
--
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)
pgpQTUflDLLsB.pgp
)
Tobias Scherbaum (dertobi123)
Looks like a mandate for the preexisting council. Thanks to everyone for
your confidence in us!
Thanks to you guys for working on the council.
I really appreciate the work you, and especially donnie with the
planning, put into this.
--
Regards, Matti Bickel
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
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
Signed/Encrypted
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 unless someone speaks up and
solves the issues
, 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 Bickel
Signed/Encrypted email
with that :)
--
Regards, Matti Bickel
Encrypted/Signed Email preferred
pgpdWg7s5MB62.pgp
Description: PGP signature
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 just fine :)
HTH,
--
Regards, Matti Bickel
Encrypted/Signed Email preferred
pgpKkjqgEdTea.pgp
Description: PGP signature
, 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
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 unacceptable in
the tree, i'll mask it pending removal.
--
Regards, Matti Bickel
Encrypted
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.
Right, and packages that aren't aiming for stable
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 preferred
pgp4MSlQKyGCY.pgp
Description: PGP signature
/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 licensed under the LGPL, version
2.1, unless otherwise indicated in components taken
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
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 Bickel
Encrypted/Signed Email preferred
! 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 Email preferred
pgpfusH8wCtzB.pgp
Description: PGP signature
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).
--
Regards, Matti Bickel
Homepage: http://www.rateu.de
Alec Warner [EMAIL PROTECTED] wrote:
Dude masterdriverz is like 29, he just masquerades as a young person to
pick up all the 16 year old hotties on irc.
There's such a thing? I mean for real, and not 40 year old fatties
posing as 16 year old hotties to masterdriverz..
--
Regards, Matti Bickel
can that be kept secret?
--
Regards, Matti Bickel
Homepage: http://www.rateu.de
Encrypted/Signed Email preferred
pgpSbg74jRcs0.pgp
Description: PGP signature
give the community
some credit. We're not powerless, we'll never be.
--
Regards, Matti Bickel
Homepage: http://www.rateu.de
Encrypted/Signed Email preferred
pgpoJ5TYtw83W.pgp
Description: PGP signature
1 - 100 of 114 matches
Mail list logo
