(apologies in advance if this goes through twice)
Chris Gianelloni wrote:
On Sat, 2006-07-01 at 12:18 -0600, Ryan Hill wrote:
Should arch testers start working with 4.1.1 then? And do you want bugs to
block #117482?
Arch testers should contact their architecture's leads or Release
Dan Armak wrote:
On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote:
The commit marked with @ is a special comit called a 'merge'.
I hope that clarifies the merge tracking part.
You just described what merging is. Svn can do that too with svn merge. But,
if I merge changesets from
James Potts wrote:
-fvisibility-inlines-hidden not only breaks a number of kde apps afaik (it's
filtered now),
Again, probably -fvisibility=hidden. Many people have had success building KDE
with both flags enabled lately, so maybe that's something that could be
revisited when 4.1 goes
Mike Frysinger wrote:
for you peeps who want to give this a shot, sync up and try glibc-2.4-r2.
hopefully i wont have [m]any more changes to make before i release it into
~arch.
pretty cool. couple dumb questions though.
one, does this make the compile time explode? IIRC that was one of
Patrick McLean wrote:
For about a month now, we (amd64) have had some code in our
profile.bashrc that filters CFLAGS that are unrecognized by gcc, and
warnings the user about bad CFLAGS.
The broken flags part is useful.
So far it has worked fairly well, and it has really cut down on the
Donnie Berkholz wrote:
R Hill wrote:
There's an endless number of CFLAGS that could be warned about, and just
as many situations where they're actually useful. Aside, I've yet to
hear of _anything_ that's broken because of -fvisibility-inlines-hidden.
(course someone will undoubtedly point one
Simon Strandman wrote:
It seems like toolchain.eclass does something wrong when configuring gcc
4.1 snapshots. I decided to try gcc 4.1 on my server so I created a
gcc-4.1.1.20060324 ebuild and defined the SNAPSHOT variable in it
(current cvs has a lot of bugfixes since the release). This is
Marcelo Góes wrote:
GLEP: 46
Title: Allow upstream tags in metadata.xml
Version: $Revision: 1.1 $
i'm offline for the week, so ignore any of this that has already been discussed
in the meantime.
This GLEP defines the following four tags for ``upstream``:
``maintainer``, ``changelog``,
Ned Ludd wrote:
232 matches. http://tinyurl.com/pmrmx
The vast majority of which have an explanation in the comment directly
preceding.
--de.
--
gentoo-dev@gentoo.org mailing list
Kevin F. Quinn (Gentoo) wrote:
When re-assigning, it is extremely useful for the new assignee to see
some relevant text, as this is the first bit of text they may see. If
you just re-assign with '.' then the new assignee has to browse the bug
to decide how to prioritise etc - which means
(sorry if this double posts)
Brian Harring wrote:
Yo...
attached is a patch enabling confcache support for portage. Lots of
testing, plus fixups from comments from folks prior.
So... giving it a few days, nows the time to bitch if you dislike the
implementation (and no, I'm not rewriting
Marius Mauch wrote:
On Sun, 12 Feb 2006 14:49:55 -0500
Mark Loeser [EMAIL PROTECTED] wrote:
On a more global scale, we should decide if this is valid though. I
haven't exactly been convinced that it is useful, but I'm not opposed
to the idea. I'd just like to see a decision one way or another.
Mark Loeser wrote:
R Hill [EMAIL PROTECTED] said:
Anyways I just like anything that makes use.desc more useful than
foo - adds support for foo
That's really a completely separate issue. By allowing duplicate entries we
just allow people to put useless information in two places instead
Olivier Crete wrote:
On Tue, 2006-17-01 at 18:03 +0100, Diego 'Flameeyes' Pettenò wrote:
On Tuesday 17 January 2006 17:51, Olivier Crete wrote:
The argument in favor of splitdebug is that it allows users to give
useful bugreports when using tools such as gnome's bug-buddy.
Erm actually it
Carsten Lohrke wrote:
On Monday 26 December 2005 14:57, Drake Wyrm wrote:
You're going to be hard-pressed to get any kind of consensus on this
issue. Many dev seems to feel that the license belongs there. In some
cases the COPYING, LICENSE, and/or INSTALL files contain, not boilerplate
Peter wrote:
To Gentoo nVidia users:
We are in the process of developing and testing
a unified nVidia driver ebuild. When implemented,
it will replace the nvidia-kernel, nvidia-glx, and
nvidia-settings ebuilds. It will also add the utility
nvidia-xconfig.
Well I just wanted to say thanks
Diego 'Flameeyes' Petten wrote:
On Saturday 24 December 2005 16:31, Peter wrote:
Not really. glx does not compile at all and the entire pkg file has to be
extracted. Same amount of files being processed...
No, because the glx part files needs to be processed by portage, too, and
that's
Diego 'Flameeyes' Petten wrote:
Another package leaving the tree, again because of transcode1 CLI changes.
It does not work as intended with transcode 1.0 and has other problems, too.
Hoping in newer versions to come out better, I'm going to mask and it's
pending removal one week from now.
Diego 'Flameeyes' Petten wrote:
Oh well, media-video/dvdrip has many issues reported in bugzilla (some have
patches, most haven't), and depends on a version of transcode with many
issues, too (and force us to leave transcode 1 masked).
Nobody in video herd is looking at it right now, last
Kurt Lieber wrote:
On Sat, Dec 10, 2005 at 11:52:33AM + or thereabouts, Ian Leitch wrote:
For the time being and near future, I think moves should be done by hand.
What are your thoughts on this, infra?
As for moving packages by hand vs. using a tool, that's not really infra's
call.
George Prowse wrote:
After some talk in the forums a point came up that we need a way to
reduce the long used gentoo system to a bare point before X but after
any baselayout upgrade had been applied.
This script would enable two things: a person to rebuild his system
after a library
Andrej Kacian wrote:
On Sun, 20 Nov 2005 20:39:43 -0600
R Hill [EMAIL PROTECTED] wrote:
* if ebuild installs COPYING and/or INSTALL into doc.
Is this actually important? There are a hell of a lot of ebuilds that fail
under this rule. I'd like to start filing patches for some
Mike Frysinger wrote:
On Wed, Nov 23, 2005 at 01:40:45AM -0500, Curtis Napier wrote:
The artwork is all part of the winning design. Any issues with the
infinity symbol should have been addressed a year ago.
well it clearly wasnt, might as well cover it now before the site goes
live ... as
Chris Gianelloni wrote:
On Tue, 2005-11-22 at 16:26 +0100, Marc Hildebrand wrote:
Chris Gianelloni wrote:
[..]
Now, on the topic of the tarballs.
Give me one example of something that you can do with a stage1 or stage2
tarball that you cannot with a stage3 tarball.
Answer: Download it in
Andrea Barisani wrote:
At least let's draft a nice
and visible document explaining the change and why people should not use this
anymore since judging from the complaints lots of people just don't get it.
I think that a lot of people use stage 1 because they're under the impression
that they
Dan Meltzer wrote:
On 11/22/05, R Hill [EMAIL PROTECTED] wrote:
What about someone on dialup who needs a rescue CD to boot into their system
after they've trashed the MBR? 88MiB vs 14MiB is a big difference in this
case.
Erm, why would I need a stage 1 for a rescue cd?
christ, i must
Donnie Berkholz wrote:
Our policy for X is that if upstream won't accept it, we won't either.
Perhaps you'd be interested in adopting that and convincing the reported
to get upstream interested?
I remember trying that as an argument against the reiser4 patch for grub.
Nobody seemed to agree
Daniel Ahlberg wrote:
* if ebuild installs COPYING and/or INSTALL into doc.
Is this actually important? There are a hell of a lot of ebuilds that fail
under this rule. I'd like to start filing patches for some of the packages in
this list so I'm interested in knowing what's worth fixing and
Dan Meltzer wrote:
Forever.
How about, as long as relevant? ;)
--de.
--
gentoo-dev@gentoo.org mailing list
Jason Stubbs wrote:
I seem to be repeating myself... What's an example of repository-specific
non-package-specific news? Why does `emerge --changelog` not suffice for
package-specific news?
a) maintainers don't put important news in their changelogs.
there are a few exceptions. gregkh's
Nathan L. Adams wrote:
Just keep in mind that portage is supposed to be non-interactive and
most users like it that way. (Although the countdown when cleaning out
old packages kinda breaks that idea, but I digress.)
This must be some definition of the word interactive i'm not aware of.
;)
Donnie Berkholz wrote:
Thanks to the dedicated work of Joshua Baergen and me, you've got just
what you asked for -- newer X than even money can buy. Pound on it, test
it, break it, and file bugs. Let us know how it works.
You probably already know of it, but when following your modular-X
Massimiliano Bellomo wrote:
a lot of blocks by a phantom package xorg-x11-7 !!
Any ideas ??
# echo x11-base/xorg-x11-6.8.2-r6 /etc/portage/profile/package.provided
--de.
--
gentoo-dev@gentoo.org mailing list
Chris Gianelloni wrote:
Here's my question... use.local.desc is already package-specific, so why
would we need yet *another* place to put package-specific definitions?
Would it not be enough to have use.local.desc overlay on use.desc? If
package foo uses global USE flag bar in a way different
Martin Schlemmer wrote:
On Sat, 2005-10-01 at 21:22 +0100, Ciaran McCreesh wrote:
We've discussed adding this to metadata.xml a few times in the past,
but every time there was opposition from a vocal minority of one who
claimed that USE flags should always do exactly the same thing for
every
Dan Meltzer wrote:
Hello,
I am a frequenter of #gentoo-*, as many of you know :)
Tonight, hanging out in #gentoo, I observed a huge amount of incorrect
information once again.. tonight about profiles, cascading and all
that jazz, which to be honest is fairly undocumented. I decided to
give a
Homer Parker wrote:
On Mon, 2005-09-12 at 18:47 -0400, Stephen P. Becker wrote:
Let me clarify here. I'm not concerned about ATs having more
privileges
at all. I just want to know why if we're making them full developers
for all intents and purposes, we don't go the extra step and get them
On Sun, 04 Sep 2005 21:26:37 +0100, Stuart Herbert wrote:
Why not talk to the package maintainers instead, and convince them that
you need a different version marking maint instead? Why override
(which, tbh, smacks of we arch teams know best, life would be better
without package maintainers)
On Mon, 05 Sep 2005 12:02:02 -0500, Mike Doty wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
R Hill wrote:
[snip]
| How about the ATs cc the maintainer on the bug they file to get the pkg
| bumped to stable, and giving them a period of time (48 hours? a week?)
| in which to raise
On Mon, 05 Sep 2005 21:09:28 +0100, Stuart Herbert wrote:
Many *users* look on package.masked packages as being dangerous to
install, but are much more willing to run ~arch packages. If you mask a
version of a popular package, you'll get a lot of correspondence asking
you when you'll unmask
Ciaran McCreesh wrote:
I've been going through the EBUILD list at random and providing lists of
things that need to be fixed before the ebuild can be considered for
inclusion. The WONTFIX resolution along with a comment asking for the
submitter to reopen with a fixed ebuild is used when problems
Ciaran McCreesh wrote:
Yeah, the lack of reopening powers is a problem. I'd rather this was
solved by a) letting any authenticated user reopen any bug and, if
necessary, b) allowing developers to lock bugs.
Agreed. I've requested this before but haven't had any response.
--de.
--
Maurice van der Pot wrote:
The new valgrind version (3.0.0) requires sse support. If you have a
processor without sse, you'll need to stay at 2.4.1.
To make people aware of this, I could use the sse use flag in 3.0.0
and die if it is not present, telling people to mask versions 3.0.0
and up
Christian Parpart wrote:
On Sunday 24 July 2005 20:29, Ivan Yosifov wrote:
What's up with genlop ?
There are 9 open bugs, some including trivial fixes ( like #97049 ),
the homepage http://pollycoke.org/genlop.html ( as listed in the
ebuild ) is dead. If my understanding is correct, unmaintained
Craig Lawson wrote:
Comments?
This subject has also been brought up on the forum[1] very recently.
There have been some interesting ideas and alternatives posed that seem
workable. I was hoping some of the developers, if they have a moment,
could consider and critique these suggestions so
Nathan L. Adams wrote:
I'm assuming that this would only apply to cases where the dev has
provided a fix (in most cases I assume they would have reproduced the
problem). The reporter's test would have the benefits mentioned above,
and if the Team Lead tested, they could review the fix for
Mike Doty wrote:
All-
Please take a moment to welcome our newest developer, Josh_B. Josh is
from Canada. Josh has joined to help out the X herd. In his own words,
I'm originally from Saskatoon, Saskatchewan, but moved to Edmonton,
Alberta in 1992. For the summer I am living in Sylvan
Chris Gianelloni wrote:
On Tue, 2005-05-24 at 14:44 -0600, R Hill wrote:
Really? What does such a team do?
They do exactly what is said above. They test ebuilds that are
submitted. They also test patches and just about anything else that
goes into bugzilla. Basically, they are a group
Chris Gianelloni wrote:
I dunno if it's really big work to have a look at one site to see if
there are ebuilds you missed when they were updated.
It was not my intention to make really more work. It was just to find a faster
way for outdated ebuilds getting updated.
There is really only one
Hello.
Jeffrey Forman wrote:
The upgrade for bugs.gentoo.org went exactly as I had planned for.
Completed in under 20 minutes, which included this email. I've upgraded
our Bugzilla from the old 2.18rc2 to 2.18.1. This fixes more security
and code than I can even begin to mention. I have cleaned
Mike Frysinger wrote:
my proposal is to implement a new utility (called 'erescue' for lack of a
better name) that is written in C and designed to be statically linked ...
then next time you break a core system package which cannot be recovered by
simply running `emerge` a few times, you run
On 5/16/05, Alec Warner [EMAIL PROTECTED] wrote:
On Mon, 16 May 2005 19:45:05 -0400 Mike Frysinger [EMAIL PROTECTED]
| On Monday 16 May 2005 07:08 pm, Ciaran McCreesh wrote:
| What, so that you can see which bugs a small but vocal group of
| ricers are interested in rather than the ones
Mike Frysinger wrote:
On Wednesday 11 May 2005 05:20 pm, Francesco Riosa wrote:
what we have:
At the moment have_NPTL is defined in eclass/eutils.eclass, it compile a
small test program to check if glibc have nptl support.
hasnt this been outgrown ? people should `use nptl` now i think
in fact
Alin Nastac wrote:
Hi folks,
I think we should make a new category called app-cellphone containing
the following packages:
net-dialup/gammu
net-dialup/gnokii
net-dialup/wammu
net-wireless/gnome-phone-manager
Yes, I know. It is a short list, but shouldn't be a category
representative for
Georgi Georgiev wrote:
maillog: 30/04/2005-13:43:42(-0600): R Hill types
Maybe a way of lessening the annoyance of test failures would be having
a way to resume the build at the install phase. I'm thinking of
something similar the touch ${BUILDDIR}/.compiled trick. as it is, if
you remove
55 matches
Mail list logo
