Kevin F. Quinn wrote:
The expectation here is that when a new version of gcc is
stabilized, that users will upgrade to that in a reasonable amount
of time, and use that (by selecting it with gcc-config) for
compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on
2-Dec-2005, and
Richard Fish wrote:
Having dozens (hundreds? all?) ebuilds check for a minimum version
Probably just the ebuilds that happen to use new GCC features before
the mass of the general public has changed to that version. But yes,
a minimum version constraint could theoretically end up in a lot of
Jakub Moc wrote:
Sigh. Because it would break your system!
You really need to research better if you insist on beating a dead
horse over and over again. Kindly read the toolchain.eclass:
You're misreading me.
I was merely counter-arguing Kevin, who said that Portage provides
plenty of
Molle Bestefich wrote:
The current situation is very annoying for users that update often,
and also makes Portage mostly unusable for automatic server upgrades
After unmerging mono-tools so Portage could finally run a whole
update, it stopped halfway through because of this bug:
http
I'd like to take a stab at maintainership (or at least fixing) an
unmaintained ebuild.
What versioning system do you guys use (CVS?), and what's the URL for
checking out ebuilds?
(I was thinking that I'd conjure up a patch and submit it here so
someone with commit access can put it in.)
--
Jakub Moc wrote:
Try reading the bug - users are basically being shoved off with an
arrogant silence and a stamp on their forehead saying INVALID.
Nothing personal against Jakub Moc who probably has a lot to do, but
the handling of relevant issues raised in the bugzilla is just
Ioannis Aslanidis wrote:
You'd rather fill in a bug report and submit the patch in the bug.
Not in this list, definitely.
Oh, ok. Never mind then, I fear I'd be spending way too much time
fighting with Jakub trying to get the ebuild in the tree. I'll just
drop it.
(Nothing personal, I just
Richard Fish wrote:
The expectation here is that when a new version of gcc is stabilized,
that users will upgrade to that in a reasonable amount of time, and
use that (by selecting it with gcc-config) for compiling all new
updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the
current
What versioning system do you guys use (CVS?),
and what's the URL for checking out ebuilds?
bugs.gentoo.org is where this kind of work is done.
There's already an existing but unmaintained ebuild.
That's what I wanted to check out, so I could modify it and submit a diff -u.
--
Richard Fish writes:
Unfortunately the Gentoo dev's have taken the rather unusual
step of _breaking the tree_ due to a security problem.
Thanks for the info.
I would really wish that there was some mechanism in place to make
sure that the tree was never broken.
The current situation is very
Pierre Guinoiseau writes:
pam-login is now included in shadow, you no longer need to emerge it.
Thanks, that's what I needed to know.
I had done an emerge -D world, and suddenly I couldn't turn on the
PC. I later found out that /sbin/login had been removed.
Richard Fish writes:
USE=mono
I think a piece might be missing from Portage.
I'll depict my workflow as an example.
I'm preparing to upgrade:
# emerge --sync
# emerge -Dp world
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking x11-libs/libXinerama-1.0.1)
[blocks B ] =x11-base/xorg-x11-6.9 (is blocking
Molle Bestefich wrote:
I think a piece might be missing from Portage.
I'll depict my workflow as an example.
Same thing with a package called 'seamonkey':
# emerge -Dpt world
These are the packages that would be merged, in reverse order:
Calculating world dependencies... done!
[blocks B
Dont snip. The relevant part comes *after* the blocks lines.
Aah. I get it. Thanks.
Sorry for the noise.
www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
Also, you are mis-interpreting the blocks lines. The correct
reading of X (is blocking Y) is that you have (or should
[snip - Mike, Robin, Joerg, Alec and Marius were kind enough to answer my
questions...]
Thanks guys!
That should shave a couple of hours off each nightly backup.. :-))
--
gentoo-dev@gentoo.org mailing list
Hi
Follow-up question to the backup thingy.
Is there an easy way to share Portage's database between multiple
virtual machines?
Optimally, I would emerge --sync and the results would land in a
filesystem that I'd share between VMs, so I don't have to do emerge
--sync in each and all of them.
Hi
Portage takes up a lot of space and time when doing server backups.
How much of Portage needs to be backup up?
Any large parts of the tree that I can just dump?
Thanks!
CC appreciated :).
--
gentoo-dev@gentoo.org mailing list
If you want central control of what's happening in the repository,
Subversion seems like the way to go.
Better to fix the design of the repository, so that it can't be
broken in the first place, than to try putting band-aids in place
to cover the gaps.
Wow, way out of scope.
Sure, a Portage
Having a live tree requires people to be perfect. People are not
perfect and requiring it is ridiculous. I love having commits in my
local tree within the hour, but having a stable and unstable branch
makes a lot of sense.
Does it? How does having a stable and unstable branch differ from
19 matches
Mail list logo
