--On Monday, September 05, 2005 14:41:45 +0900 Georgi Georgiev
<[EMAIL PROTECTED]> wrote:
> key sequence works fine with my slang-linked mutt, but it
> does not with a ncurses-linked mutt. I am aware what Control-S is
> supposed to do historically.
stty stop undef
--
--
This is not supposed to start a flame-fest, but I need some advice.
As of mutt-1.5.10-r1, the slang use flag is ignored and ncurses is used
instead. After checking out bugs #96603 #102558 #57416 (mentioned in the
ChangeLog as the reasoning behind the no-slang decision) I got some idea
as to why --
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 11795 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KE
On Sunday 04 September 2005 04:52 pm, Stuart Herbert wrote:
> On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote:
> > If it isn't fit to be marked stable, it shouldn't be out of
> > package.mask. ~arch means "candidate for going stable after more
> > testing", not "might work".
>
> Agreed, bu
On Sunday 04 September 2005 03:59 pm, Ciaran McCreesh wrote:
> On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert <[EMAIL PROTECTED]>
>
> wrote:
> | > Arch teams need to be allowed to override maintainers where
> | > appropriate,
> |
> | Why not talk to the package maintainers instead, and convince
On Mon, 2005-09-05 at 01:12 +0200, Kevin F. Quinn wrote:
> 6) I notice the amd64 team requre their arch testers to
>take the ebuild quiz; I think this is a bit harsh, as
>arch testers are regular users without commit access to
>CVS etc. A simpler quiz targetted at ensuring the arch
>
On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]>
wrote:
| 3) All packages need to be assigned an x86 arch team member
|responsible.
Why?
| 6) I notice the amd64 team requre their arch testers to
|take the ebuild quiz; I think this is a bit harsh, as
|arch testers
Nevermind, torsmo is superseeded by conky.
On Mon, 2006-09-04 at 16:51 -0600, Lares Moreau wrote:
> I'm addding functionality to torsmo by adding support for i8k, The dell
> laptop utils. I am using existing source code from the i8kutils package
> to extend this functionality.
>
> Now my questi
We seem to be heading towards a situation where the x86 arch
team do all marking of stuff stable on x86. This I like.
Some observations - these may be phrased in the affirmative
but please take them as observations/suggestions :)
1) The x86 arch team will need to be large(ish) to keep pace.
He
I'm addding functionality to torsmo by adding support for i8k, The dell
laptop utils. I am using existing source code from the i8kutils package
to extend this functionality.
Now my question is, Since I am using source code from i8kutils and
adding it to torsmo, which would be the most appropriate
On Sun, 04 Sep 2005 22:43:20 +0100 Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote:
| > Yeah, foser's on holiday. Good time to push the GLEP through.
|
| How typical of you to try and drag this discussion down into something
| personal :( If yo
On Sun, 04 Sep 2005 22:54:02 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:
> Maybe the answer is to have separate trees for arches and general
> packages then? That would be one solution.
>
> (Although not one that I'd personally prefer. I'd rather the package
> maintainers learned to work wi
On Sun, 2005-09-04 at 14:31 -0600, Jason Wever wrote:
> I've filed notes in the tracker bug you put in the Gentoo Bugzilla but
> other than your initial response, I haven't gotten any feedback on them.
Sorry, I hadn't realised you were waiting for a response from us.
That's now sorted.
I apprecia
On Sun, 2005-09-04 at 15:45 -0600, Jason Wever wrote:
> This is the current policy, though it gets violated quite often.
Maybe the answer is to have separate trees for arches and general
packages then? That would be one solution.
(Although not one that I'd personally prefer. I'd rather the pack
On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote:
> If it isn't fit to be marked stable, it shouldn't be out of
> package.mask. ~arch means "candidate for going stable after more
> testing", not "might work".
Agreed, but we both know that it's just not how many devs work atm.
Perhaps that
On Sun, 04 Sep 2005 22:39:44 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:
> Yes, but if package maintainers aren't allowed to mark packages as
> stable on anything but the "maintainer arch" (unless they are also a
> member of an arch team), this problem shouldn't happen.
This is the current po
On Sunday 04 September 2005 23:35, Jason Wever wrote:
> For the most part, this makes sense, However we do have times where a
> particular arch team may need to stabilize a package sooner in the case
> where earlier versions are broken.
Why this remembers me xine-lib on sparc? :))
--
Diego "Flam
On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote:
> Yeah, foser's on holiday. Good time to push the GLEP through.
How typical of you to try and drag this discussion down into something
personal :( If you keep feeling the need to do this, do everyone a
favour and keep your mouth shut inste
Hi Grant,
On Sun, 2005-09-04 at 15:53 -0500, Grant Goodyear wrote:
> I'm still thinking about the concept of a "maint" option. This
> question I can answer, however. It's not unheard of for a package with
> a lot of dependencies to be marked stable when one of the dependencies
> has not yet been
On Sun, 4 Sep 2005 15:43:11 -0500
Grant Goodyear <[EMAIL PROTECTED]> wrote:
> I agree that the arch teams shouldn't be marking packages stable in
> advance of when the the maintainer thinks it's ready. At the same
> time, it's the respective arch teams, as "owners" of their entire
> stable tree,
On Sunday 04 September 2005 22:53, Grant Goodyear wrote:
> I tend to think that's fair. At least in my view, the goal is not to
> minimize the importance of package maintainers, but simply to separate
> package maintainance from tree maintainance.
That's right. I think this is good, as a maintaine
On Sun, 2005-09-04 at 14:40 -0600, Joshua Baergen wrote:
> A possible way to alleviate this is proactivity on the maintainer's
> part. Our current rule for going testing->stable is 30 days. If we
> could alert the arch teams x number of days in advance they could
> test
> it before the end of
On Sun, 4 Sep 2005 15:53:07 -0500 Grant Goodyear <[EMAIL PROTECTED]>
wrote:
| I'm still thinking about the concept of a "maint" option. This
| question I can answer, however. It's not unheard of for a package
| with a lot of dependencies to be marked stable when one of the
| dependencies has not
On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| > Arch teams need to be allowed to override maintainers where
| > appropriate,
|
| Why not talk to the package maintainers instead, and convince them
| that you need a different version marking "maint" instead? Why
|
On Sun, 04 Sep 2005 21:11:03 +0100 Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| Depends on how many refuse I guess ;-) There doesn't seem to be much
| sign of any opposition to the concept so far.
Yeah, foser's on holiday. Good time to push the GLEP through.
| We have an elected council now; if t
Stuart Herbert wrote: [Sun Sep 04 2005, 03:26:37PM CDT]
> I've no personal problem with arch teams sometimes needing to do their
> own thing, provided it's confined to a specific class of package.
> Outside of the core packages required to boot & maintain a platform,
> when is there ever a need for
Stuart Herbert wrote:
I've no personal problem with arch teams sometimes needing to do their
own thing, provided it's confined to a specific class of package.
Outside of the core packages required to boot & maintain a platform,
when is there ever a need for arch maintainers to decide that they kn
Vapier wrote: [Sun Sep 04 2005, 01:00:41PM CDT]
> this isnt quite true ... non-x86 archs usually take their queues for
> when packages should be moved to stable from the maintainer of the
> package
Perfectly reasonable.
> in other words, arch teams generally defer to maintainers (and rightly
> so
Stuart Herbert wrote:
The introduction of the x86 arch
team will, at some point, turn the x86 arch team into a bottleneck (just
like all the other arch teams already are)
A possible way to alleviate this is proactivity on the maintainer's
part. Our current rule for going testing->stable is
On Sun, 04 Sep 2005 18:47:30 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:
> We hope to move these packages to ~arch (on architectures that the PHP
> Herd supports) on Thursday 8th September, as part of our migration
> plans [2]. If you find any problems with the packages, please file
> bugs in
On Sun, 2005-09-04 at 21:05 +0100, Ciaran McCreesh wrote:
> Workable for a certain category of packages so long as it's advisory
> only.
Workable for the vast majority of packages in the tree I expect.
> Arch teams need to be allowed to override maintainers where
> appropriate,
Why not talk to
On Sun, 2005-09-04 at 14:16 -0500, Grant Goodyear wrote:
> * Having bodies on [EMAIL PROTECTED] is just the starting point. The
>more difficult part will be convincing people that it is in their
>best interests to do things this way. Similarly, what do we do with
>devs who refuse?
On Sun, 04 Sep 2005 20:48:52 +0100 Stuart Herbert <[EMAIL PROTECTED]>
wrote:
| Introduce a new arch keyword "maint", to turn the concept of the
| "maintainer arch" from an intangible into something real. Package
| maintainers can then mark packages "~maint" or "maint" as required,
| and leave the
Hi Grant,
On Sun, 2005-09-04 at 09:37 -0500, Grant Goodyear wrote:
> Dear all,
> Here's a GLEP that I'm thinking about right now. It's not yet
> official, since I'd like to get some feedback beforehand (which helps to
> ensure that I'm not abusing my GLEP-editor powers). If you have
> addition
Ciaran McCreesh wrote: [Sun Sep 04 2005, 01:41:41PM CDT]
> On Sun, 4 Sep 2005 09:37:11 -0500 Grant Goodyear <[EMAIL PROTECTED]>
> wrote:
> | There will be a considerable one-time cost involved in establishing a
> | robust x86 arch team.
>
> Justify this please. If there is a cost associated, the
050904 Andrew Gaffney wrote:
> Philip Webb wrote:
>> I actually have
>> /etc/make.profile -> /usr/portage/profiles/default-linux/x86/2005.1
>> So when I enter 'emerge -Cp devfsd', why do I get :
>> "!!! Trying to unmerge package(s) in system profile. 'sys-fs/devfsd'
>>!!! This could be damag
On Sunday 04 September 2005 01:36 pm, Philip Webb wrote:
> 050904 Sebastian Bergmann wrote:
> > Philip Webb schrieb:
> >> /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals :
> >
> > You are using the 2.4 subprofile of 2005.1.
>
> So when I enter 'emerge -Cp devfsd', why do I get :
>
>
On Sunday 04 September 2005 10:37 am, Grant Goodyear wrote:
> This policy for x86 is quite different from how every other arch marks
> packages stable. For the non-x86 archs, each arch has a specific "arch
> team" which is responsible for moving packages from ``~arch`` to ``arch``.
> This approac
On Sun, 4 Sep 2005 09:37:11 -0500 Grant Goodyear <[EMAIL PROTECTED]>
wrote:
| There will be a considerable one-time cost involved in establishing a
| robust x86 arch team.
Justify this please. If there is a cost associated, the details of this
cost should be provided.
--
Ciaran McCreesh : Gento
On Sun, 04 Sep 2005 20:22:54 +0200 Bjarke Istrup Pedersen
<[EMAIL PROTECTED]> wrote:
| Any plans on moving webapp-config as an eselect module? :-)
That one's way beyond the scope of what eselect was designed for.
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail
On Sun, 2005-09-04 at 20:22 +0200, Bjarke Istrup Pedersen wrote:
> Any plans on moving webapp-config as an eselect module? :-)
No.
Best regards,
Stu
--
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer http://www.gentoo.org
On Sunday 04 September 2005 15:11, Philip Webb wrote:
> Having gone over to Udev, I went to unmerge Devfs & got a big red warning.
> It appears that the 2005.1 profile gives Devfs as a virtual:
> is this an oversight or is there a reason behind it ?
> I would have assumed that Udev would now be the
Philip Webb wrote:
050904 Sebastian Bergmann wrote:
Philip Webb schrieb:
/usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals :
You are using the 2.4 subprofile of 2005.1.
The 2.4 subdir is the place I found Devfs mentioned,
but I don't seem to be using that subdir.
I actually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Huddleston skrev:
> I've recently updated opengl-update to use the eselect framework. I
> think the team has done a great job as it was extremely easy to port the
> bash script to an eselect module. However, when I placed it in the
> portage t
Hi,
The PHP Herd is pleased to announce that it has added new packages to
Portage which will allow Gentoo to provide stable PHP4 and PHP5 packages
on the same box at the same time. These packages have come from the
successful PHP Overlay [1].
At the heart of these packages is the new dev-lang/ph
050904 Sebastian Bergmann wrote:
> Philip Webb schrieb:
>> /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals :
> You are using the 2.4 subprofile of 2005.1.
The 2.4 subdir is the place I found Devfs mentioned,
but I don't seem to be using that subdir.
I actually have
/etc/make.profi
On Sun, 4 Sep 2005 11:08:58 +0200 Christian Parpart <[EMAIL PROTECTED]>
wrote:
| Maybe I do not understand the diffference between "I assume" and "I
| know", and "I know" I meant the first, however, in that case, Grant,
| I do not know why you're requesting this combine when you know about
| these
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since the 2nd, I have discovered that my ISP has messed up my
primary inbox, so I have received almost no mail, including anything
to an @gentoo.org address. I have now forwarded (I believe) @gentoo
mail to what appears to be a good address for me.
Dear all,
Here's a GLEP that I'm thinking about right now. It's not yet
official, since I'd like to get some feedback beforehand (which helps to
ensure that I'm not abusing my GLEP-editor powers). If you have
additional arguments either pro or con, please send them my way so that
I may incorpor
Philip Webb schrieb:
> /usr/portage/profiles/default-linux/x86/2005.1/2.4/virtuals :
You are using the 2.4 subprofile of 2005.1.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
signature.asc
Philip Webb wrote:
Having gone over to Udev, I went to unmerge Devfs & got a big red warning.
It appears that the 2005.1 profile gives Devfs as a virtual:
is this an oversight or is there a reason behind it ?
I would have assumed that Udev would now be the required device manager.
/usr/portage/
Having gone over to Udev, I went to unmerge Devfs & got a big red warning.
It appears that the 2005.1 profile gives Devfs as a virtual:
is this an oversight or is there a reason behind it ?
I would have assumed that Udev would now be the required device manager.
/usr/portage/profiles/default-linu
sorry, this is just test, please ignore.
--
Sergey Kuleshov<[EMAIL PROTECTED]>
Home Page: http://svyatogor.gnns.net
Jabber: [EMAIL PROTECTED]
ICQ: 158439855
--
gentoo-dev@gentoo.org mailing list
On Friday 02 September 2005 06:28, Lance Albertson wrote:
> Grant Goodyear wrote:
> > Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT]
> >
> >>This just leads me to assume you're not really a coder (wrt native
> >>programming languages like C/C++), are you?
> >
> > *Grin* This sort of co
54 matches
Mail list logo
