(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 branch
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 ~arch
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 th
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 u
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
numbe
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 th
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``, ``bugs
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 flippin
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
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
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
Ciaran McCreesh wrote:
> On Sun, 12 Feb 2006 03:19:25 -0500 Mark Loeser <[EMAIL PROTECTED]>
> wrote:
> | So, what do we want to do about this? Should we have some repoman
> | warning if a USE flag exists in both files, or should it be
> | acceptable?
>
> The whole idea of global USE flags is that
Henrik Brix Andersen wrote:
> On Sat, Jan 21, 2006 at 08:32:20AM +0100, sanchan wrote:
>> And it is easier to add in rsync_exclude if you don't want it...
>> But it seems that there is no much consensus for the new category.
>> Tomorrow I've planned the final tests on tos-1.1.15 and nesc-1.2.1 that
Luca Barbato wrote:
> sanchan wrote:
>> Hi all, I'm working on TinyOS related ebuilds (Bug #78908) and since
>> actually there are 20 ebuilds in my overlay may be worth proposing a
>> dev-tos category.
>> It will take a few weeks in order to have all the ebuilds updated for
>> the new release of ti
Henrik Brix Andersen wrote:
> On Mon, Jan 09, 2006 at 05:12:31PM +0100, Andrea Barisani wrote:
>> USE=cacerts sounds the proper course of action to me.
>
> If this is implemented, please make it USE=cacert, not USE=cacerts.
Or USE=ca-cert even? cacert looks like one word to me.
--de.
--
gent
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 actua
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
>
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
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
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 ma
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
>
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
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.
Andrew Muraco wrote:
> Mark Loeser wrote:
>> Andrew Muraco <[EMAIL PROTECTED]> said:
>>> is a minimum. A full out doc with all the FAQ and important notes
>>> about what needs to be recompiled (in my opinion) would be a much
>>> more through upgrade path, ofcourse still include the einfo quick
>>>
Daniel Gryniewicz wrote:
> On Mon, 2005-11-28 at 19:12 +0100, Bjarke Istrup Pedersen wrote:
>
>> Does this mean that we can get rid of the libstd++ dependency of gcc,
>> and move it to the binary packages that depends on gcc 3.3 .
>> I know this has been discussed before, but once it's stable I se
Ned Ludd wrote:
> Good afternoon,
>
> probably in portage-2.0.54 a patch will be added to emit split debug
> info. Having a split debug allows us to retain all the advantages of
> stripping executables while gaining the ability to properly debug
> executables in bfd aware programs. It's been in te
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
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
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
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 the
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.
>>>
>> An
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 w
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
Dan Meltzer wrote:
Forever.
How about, "as long as relevant"? ;)
--de.
--
gentoo-dev@gentoo.org mailing list
Chris Gianelloni wrote:
On Thu, 2005-11-10 at 21:33 +, Stuart Herbert wrote:
Hence emerge --news.
Why?
There's no "emerge --etc" or "emerge --etc-update" functionality. Why
must it be "emerge --news" at all?
# emerge --help config
probably an emerge --help news that explains the basic
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.
;) Dis
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 ude
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
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 HOWTO
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 f
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 m
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 pac
Chris Bainbridge wrote:
Hi,
I was wondering if there's any chance of having the reiser4 patch for
grub (or even the whole grub-reiser4 distfile) added to the ebuild.
There are various bugs where people have posted patches for 0.96x
ebuilds which were never added and the bugs have been WONTFIXed
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 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 unma
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 w
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 main
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.
--
gentoo-de
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
Diego 'Flameeyes' Pettenò wrote:
On Saturday 06 August 2005 21:24, R Hill wrote:
compile a small test program containing SSE specific intrinsics and die
if it returns an error code? does valgrind's configure check for sse?
That will break while preparing packages for another
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 if
Alec Joseph Warner wrote:
Donnie Berkholz wrote:
Are you having a tough time filtering out enhancements in your queries
or something? I don't understand how feature requests could possibly
interfere with anything besides other enhancements.
Many of the enhancements aren't marked as such,
T
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 w
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 tech
Marco Matthies wrote:
Nathan L. Adams wrote:
The person reporting the bug can reopen the bug, as he/she is in a
perfect position to test the fix.
Just a thought I've had from time to time - why can't people other than
the reporter reopen a resolved bug report? I'm thinking that there are
cas
Nathan L. Adams wrote:
living. I know this fact: Sometimes the developer doesn't realise what
the actual problem is. Sometimes its because the end-user didn't
communicate well. Sometimes its because the developer is being an ass
(we've all been guilty of this). *That* is why verification should b
Nathan L. Adams wrote:
Gregorio Guidi wrote:
Any proposal that implies an enourmous increase of our human resources is
really useless for us.
Please accept the fact that we cannot change our resources at will, and adapt
any suggestion to this simple principle.
Now *that* is a reasonable argum
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 Lak
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 wa
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 out
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 `ere
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 t
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 gli
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 its
Daniel Gryniewicz wrote:
emerge gnome-2.8.3-r1.ebuild digest
s/emerge/ebuild
;)
--de.
--
gentoo-dev@gentoo.org mailing list
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 r
Maurice van der Pot wrote:
It's understandable that fixing this is a low priority thing, but what
I would like to propose is to either fix the tests or disable them.
The latter would be the thing to do for devs who are currently closing
bugs about tests with WONTFIX or similar.
If fixing the tes
Rumen Yotov wrote:
Can confirm that (much less collisons with 2005.0), but as there exist
some persistant collisions (nvidia-kernel, alsa-driver, some perl
modules, etc.) So i've put these in package.features/package.env file
(from Portage-Toys tools) to disable "collision-protect" just for them.
A
71 matches
Mail list logo
