Henrik Brix Andersen wrote:
On Sat, Apr 15, 2006 at 02:06:00AM +0300, Alin Nastac wrote:
dev-libs/openobex-1.2 is now in the tree.
Why did you p.mask openobex-apps before openobex-1.2 is stable?
For forcing users to test openobex-1.2 ;)
I think openobex-1.2 should be unmasked, but
Danny van Dyk wrote:
It is my pleasure to announce publicly that ian! has passed all
necessary quizzes to touch our holy gra^H^H^H portage tree.
Ian - welcome :)
--
Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51
desktop-misc, desktop-dock, x86, java, apache...
signature.asc
Hello.
IMO the very important element of gentoo user relations that is absent
at w.g.o is search field! Gentoo does not have good searching point.
Each time I encounter bug/problem before asking for help if I'm a good
boy I have to search for solution in different places: forums, mailing
On Mon, Apr 17, 2006 at 09:19:38AM +0300, Alin Nastac wrote:
Henrik Brix Andersen wrote:
Why did you p.mask openobex-apps before openobex-1.2 is stable?
For forcing users to test openobex-1.2 ;)
I think openobex-1.2 should be unmasked, but I am waiting for ticho to
actually do this.
See
On Mon, Apr 17, 2006 at 11:21:29AM +0200, Henrik Brix Andersen wrote:
Please solve this mess - don't package.mask openobex-apps until
openobex-1.2 has the same KEYWORDS as openobex.
... as openobex-apps, of course.
./Brix
--
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution |
Henrik Brix Andersen wrote:
On Mon, Apr 17, 2006 at 11:21:29AM +0200, Henrik Brix Andersen wrote:
Please solve this mess - don't package.mask openobex-apps until
openobex-1.2 has the same KEYWORDS as openobex.
... as openobex-apps, of course.
./Brix
OK, I've removed the hard mask
Donnie Berkholz wrote:
We are working to ensure the dependencies work as smoothly as possible,
but I expect there will be some issues since it's difficult to require
updates to all these optional drivers following an update to the server.
wouldn't ! atoms solve that problem?
--
Kind Regards,
On Sun, Apr 16, 2006 at 08:20:13PM -0400, Curtis Napier wrote:
Congratulations Christian! :-)
Congrats++
Wernfried
--
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org
Simon Stelling wrote:
Donnie Berkholz wrote:
We are working to ensure the dependencies work as smoothly as possible,
but I expect there will be some issues since it's difficult to require
updates to all these optional drivers following an update to the server.
wouldn't ! atoms solve that
Hi all,
By request, the ati VIDEO_CARDS setting has been split into three
separate settings, one for each driver: Mach64/Rage XL (mach64), Rage128
(r128), and all Radeons (radeon).
This will reduce build time on mesa, x11-drm, and kdrive (once I update
it). It will also significantly reduce the
Donnie Berkholz wrote:
Simon Stelling wrote:
Donnie Berkholz wrote:
We are working to ensure the dependencies work as smoothly as possible,
but I expect there will be some issues since it's difficult to require
updates to all these optional drivers following an update to the server.
Alec Warner wrote:
Well the semantics of the blocker is that the new driver won't work with
the old server; is that true? Or just the old drivers won't work with
the new server?
New server requires new drivers. Old server requires old drivers. There
is no valid combination of new and old.
On Sun, 2006-16-04 at 20:38 -0400, Thomas Cort wrote:
Olivier Fisette wrote:
Another dev from Québec city! Welcome to the team, Thomas.
Thank you for the warm welcome. I'm actually in North Hatley (near
Sherbrooke) in the province of Québec. Another Gentoo developer,
deltacow, also lives
On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote:
Alec Warner wrote:
Well the semantics of the blocker is that the new driver won't work with
the old server; is that true? Or just the old drivers won't work with
the new server?
New server requires new drivers. Old server
On Mon, 17 Apr 2006 09:19:48 -0700,
Donnie Berkholz [EMAIL PROTECTED] wrote:
Simon Stelling wrote:
Donnie Berkholz wrote:
We are working to ensure the dependencies work as smoothly as
possible, but I expect there will be some issues since it's
difficult to require updates to all these
Olivier Crête wrote:
On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote:
Alec Warner wrote:
Well the semantics of the blocker is that the new driver won't work with
the old server; is that true? Or just the old drivers won't work with
the new server?
New server requires new drivers.
On Monday 17 April 2006 22:26, Olivier Crête wrote:
Then you should probably has new drivers block old servers and new
servers block old drivers...
Better have new drivers depend on new server rather...
--
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/Alt lead,
Thomas de Grenier de Latour wrote:
What about a big PDEPEND in xorg-server-1.1 ebuild, with a bunch of
video_cards_foobar? ( =x11-drivers/xf86-video-foobar-NewVersion )?
That should be enough to force a smooth update of the video drivers
after the server. And, the RDEPEND on video drivers could
Donnie Berkholz wrote:
The drivers cannot be upgraded until a newer server is installed. So
technically, this would allow things to work by forcing people to
unmerge all their drivers before upgrading, then remerge the new
versions. That's not a very desirable solution either, but do you think
Donnie Berkholz wrote:
Olivier Crête wrote:
On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote:
Alec Warner wrote:
Well the semantics of the blocker is that the new driver won't work
with the old server; is that true? Or just the old drivers won't
work with the new server?
New
A valid problem with this approach. Is requiring everyone to unmerge
drivers a worse solution than breaking some people who emerged drivers
directly?
I very much dislike making people unmerge things. It's not intuitive
for anyone, having to remove the old program to upgrade a dependency
Hi,
The obvious symptom when you don't have any valid VIDEO_CARDS set will
be that the xorg-x11 ebuild tries to pull in everything. Warnings or
die()'s about this change are useless, they will be too late because all
the drivers will have already been built at that point.
but doesn't portage
Sven Köhler wrote:
Would it harm anything, if the drivers become a dependency of the second
kind?
It would mean that you could have the xorg-x11 metabuild installed and
yet still not have a complete installation, if the emerge failed after
it was installed.
The question of what type of
Would it harm anything, if the drivers become a dependency of the second
kind?
It would mean that you could have the xorg-x11 metabuild installed and
yet still not have a complete installation, if the emerge failed after
it was installed.
Yes, you're right. I missed that point.
On Mon, 17 Apr 2006 13:43:32 -0700,
Donnie Berkholz [EMAIL PROTECTED] wrote:
Is requiring everyone to unmerge drivers a worse solution than
breaking some people who emerged drivers directly?
Depends how many people are on each side i guess. But here, i would
expect really very few people to be
Thomas de Grenier de Latour wrote:
So imho, that's a lot of unlikely conditions one should join to end
with broken drivers, and i don't think you should care too much about
it.
Thanks for your input.
The ati -- {mach64,radeon,r128} change may make some of the above more
likely to happen
On Mon, 17 Apr 2006 17:48:07 -0700,
Donnie Berkholz [EMAIL PROTECTED] wrote:
- at the opposite of the xorg-x11 meta ebuild, a pkg_setup check
xorg-server (if hasq ati $VIDEO_CARDS; then eerror ...) makes
sense, since it would die at the right time, before the drivers
updates.
FYI, the
Simon Stelling wrote:
Next bunch of bugs that need a decision:
Bug: portage: emerge unmerge ... should stop in case of an error
http://bugs.gentoo.org/show_bug.cgi?id=118515
Another WONTFIX/WILLFIX issue
Bug: need a way to package.unmask packages in profiles
I'm writing a superkaramba theme for showing the current available
updates on a system (www.tomek.ca for an example), but I'm having
trouble parsing the list into seperate properties for each ebuild
(package name, version, use flag).
Right now, I'm trying get the ebuild information through
29 matches
Mail list logo
