I'd like to add a few words from the users perspective:
-
1) How do you feel when you receive an early version bump request?
I hope developers are not annoyed - well, sometimes the words chosen are
maybe a bit too offensive.
I like these bump requests. I add myself as a CC and wait for
In an ebuild, i'd like to specify an download as-filename. That means,
out there, there is a file called http://host/myprogram-1.2.3/patch01;
which i'd like to download as myprogram-1.2.3-patch01.
http://bugs.gentoo.org/show_bug.cgi?id=177863
We're planning to support that in a coming
Hi,
so a while back, i already had the problem. And just now, i ran into the
problem again:
In an ebuild, i'd like to specify an download as-filename. That means,
out there, there is a file called http://host/myprogram-1.2.3/patch01;
which i'd like to download as myprogram-1.2.3-patch01.
Of
There are many more ebuilds than just hal which fail with a compressed
pci.ids file. And many of them are non-obvious. It took me more than
I little bit of effort after the zlib USE flag was first added to the
pciutils ebuild to figure out why so many packages where failing...
Oh! Really?
Hi,
so today, pciutils-2.2.4-r3 went stable on x86.
It's a known issue, that pciutils compiled with zlib use-flag turned on
(which is default) doesn't work with the version of hal, which is
currently stable on x86.
So at the moment, hal-0.5.9-r1 is stable on x86. It went stable weeks or
even
Why did you provocate this breakage?
This is not a good idea, IMHO.
No. And many gave up getting this sensible again.
As is, the default USE flags for a desktop profile lead to a compilation
failure when unattended due to this, which is very very bad.
I'm not even complaining about that.
Why did you provocate this breakage?
Which breakage? It didn't install a gzipped pci.ids here.
That is with USE=hal. Crap...
Oh! So USE=hal forces pciutils not to use zlib?
And so the check, which the hal ebuild performs, should be modified to
check for USE=hal rather than for USE=!zlib ?
Hi,
so as you plugin a USB-disk, the kernel will recognize it, and it will
be called sda, sdb, sdc or whatever ...
I don't like that - why doesn't it get some more usefull device-name?
Some device name, that
a) indicates, that it is usb (for example put them to /dev/usb) and
b) uses a numering
Raymond Lewis Rebbeck schrieb:
On Saturday, 23 December 2006 2:40, Sven Köhler wrote:
Hi,
so as you plugin a USB-disk, the kernel will recognize it, and it will
be called sda, sdb, sdc or whatever ...
I don't like that - why doesn't it get some more usefull device-name?
Some device name
Hi,
when does udev load all the modules and does coldplug?
Is it happening before /etc/init.d/modules?
If yes, than i would like to shout: are you crazy?
Well, until udev became stable, /etc/modules.autoload.d/kernel-2.? was a
good place, to load modules in a specific order - before coldplug.
Unfortunatly, the order of loading of modules defines the ordner of
the network-interfaces (if you different types of network cards).
This is what udev's interface renaming capability is for. Define names
for your interfaces according to their MAC address, for example, and
all is good. It's
As others have said, look at using udev to name your network devices in
a persistant manner, it's the best solution.
Yes, i agree. But i have thought about it, and i wonder, if it's going
to work if:
1. udev loads the modules which results in a natural order: saying
eth0 and eth1 are used.
2.
Hi,
i had some orphaned files in /etc/udev/rules.d. Namely 40-fuse.rules and
60-fuse.rules.
The files were never removed, since they are protected - aren't they?
So that is _very_, _very_ unpractical, because the older your gentoo
gets, the more of such orphaned files you get.
Have you ever
In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced
to /lib/rcscripts/init.d which is safe as /lib is always on the same
partition as /.
From a filesystem usage point of view though, storing actively changing
state data on /lib is ugly. The tmpfs
Hi,
when i load the module for my network-card, then baselayout thinks, that
it's a good idea to a) start net.eth0 even though it's not in any
runlevel and b) start net.eth0 in runlevel boot.
So that's something, that i don't really understand. I think, that the
following behaviour would be more
when i load the module for my network-card, then baselayout thinks, that
it's a good idea to a) start net.eth0 even though it's not in any
runlevel and b) start net.eth0 in runlevel boot.
yes, the default behavior is to do hot/cold plugging
That is not a problem. The problem is, that the
X.Org 7.1 has been released from its binary driver jail to the
(un?)stable masses! Does it build? Only on Tuesdays! Does it run?
Often! Will it damage your system? I like cheese!
Hmm, xorg-server-1.1* is stable now, but xorg-x11-7.1 is not. Did you
forget that ebuild? ;-)
signature.asc
I discovered that ppp-2.4.4 set a default route without a gateway. It is
totally fine from IP routing point of view (the simple fact that route
is through the point-to-point link is enough to know the next hop),
except that openswan's %defaultroute need a default gateway in order to
work.
default dev ppp0 scope link instead default via a.b.c.d dev ppp0.
And? What the difference? For the P-t-P connection, there is not
difference. There is only one destination, you can send the packets to:
the ppp-server on the other side.
Only for normal network-connections (eth0, ...), you have
So before PerlMagick becomes independant of ImageMagick's configure,
upstream must change a few things.
Has it changed that much recently? Because it *was* seperate for aeons
and aeons before this. Installing perlmagick via use flag is a recent
edition in the scheme of things.
I'm sorry,
the maintainer of media-gfx/imagemagick sekretarz is not responding to
bugmail
and the package has two open security bugs.
https://bugs.gentoo.org/show_bug.cgi?id=143533
https://bugs.gentoo.org/show_bug.cgi?id=144091
Anyone willing to help take care of this package please CC yourself
the maintainer of media-gfx/imagemagick sekretarz is not responding to
bugmail
and the package has two open security bugs.
https://bugs.gentoo.org/show_bug.cgi?id=143533
https://bugs.gentoo.org/show_bug.cgi?id=144091
Anyone willing to help take care of this package please CC yourself on
So, wondering why people use Gentoo. Put [dev] or something if you're an
actual gentoo dev and [user] if you're a user. Doesn't need to be fancy, you
can put community or something if that's all you want. All responses off
list please. Thanks.
Hi,
so i'm using Gentoo because of the
Hi,
it's this bug:
https://bugs.gentoo.org/show_bug.cgi?id=121142
There's no comment by the maintainer for a while. I wrote the patches
that are needed to fix the problem. They work fine as far as i can tell.
So what's wrong wrong here?
I don't want to sell my patches to anyone.
But i'd like
There's no comment by the maintainer for a while. I wrote the patches
that are needed to fix the problem. They work fine as far as i can tell.
Don't feel too bad - I frequently post patches to bugs reported on the same
day and ask for feedback. Some of which are now over a year old without
net-misc/bcm4400 is a kernel driver built as an external package through
portage. The codebase which this package use has been discontinued
upstream. The upstream replacement (which is not in Portage directly) is
simply a copy of the in-kernel b44 driver code.
For this reason we are
Hey you Gentoo-Developers!
On gentoo.org, in the great announcement of Gentoo 2006.1, it says:
The most popular architectures now use GCC 4.1, glibc 2.4 and baselayout
1.12.1, as well as including a new profile layout, with separate desktop
and server profiles.
So i took you at your word, but
I'd like to suggest we make FEATURES=test (and therefore USE=test) the
default behaviour, rather than the opt-in we currently have. Far too
many packages fail their test phase.
I have a related question, but first a comment:
I like the idea, that packages run their self-tests before they get
This came up in Bug 138792 [dobin etc. should automatically die on failure]
It needs more discussion on the mailing lists.
Some excerpts from the bug: The proposal from Paul Bredbury:
Hi, I propose that the following ebuild commands themselves *die* on
failure, because the vast majority of
I've been thinking about this recently. What qemu does is compile a C
implementation of the target processor's instruction set into an object
file when qemu is built, then at run-time (JIT time) it cut-n-pastes
bits of that object file when it compiles the target executable into
native code
then it's broken by design ... sure the idea about how qemu goes about its
emulation is pretty goddamn cool, but gcc has never said that you can rely on
certain behavior
very right!
but you cannot change the world :-(
signature.asc
Description: OpenPGP digital signature
Hi,
i just wanted to ask, if the is an eclass or something else, that
enables me to temporarly select a certain gcc-version? or perhaps just
finding the path to the gcc and g++ executables of a specific
gcc-versions (like gcc-3.*)?
some software, like qemu and others, are simply not compatible
some software, like qemu and others, are simply not compatible with gcc
4.x and they will not become compatible due to severe conceptional issues.
then they stay broken ... add a warning to the ebuild if `gcc-major-version`
is 4 (see toolchain-funcs.eclass)
Hmm, but ...
there is the
/etc/ppp/plugins/rp-pppoe.so - /usr/lib/pppd/2.4.2/rp-pppoe.so
Is this symlink needed? And why is it installed by rp-pppoe?
(And is the /etc/ppp/plugins dir needed at all? What do plugins do in
/etc/ppp/plugins? Don't they belong to /usr/lib/pppd/2.4.2/ ?)
That is the place where
Hi,
at the moment, /usr/lib/pppd/2.4.2/rp-pppoe.so is installed by
net-dialup/ppp - nothing special - well, it's not a very recent version.
In the syslog it says:
RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
On the other hand, i've got net-dialup/rp-pppoe-3.8 installed and it
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
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.
May I suggest reading the fine handbook?
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4chap=3#doc_chap4
Yes, it's beautiful,
but it doesn't tell you in which file to enter the lines :
config_eth0=( adsl )
adsl_user_eth0=username
Where do you put them ? And yes, I
I also noticed the --oneshot fix.
i noted this already elsewhere in the thread
dont you read all of the e-mails !?
???
I just wanted to say Thank you for both fixes.
signature.asc
Description: OpenPGP digital signature
I have no clue, what bootstrap.sh is for anymore.
For me, Installing gentoo was always like this:
Ok, let me remind all. Stage 1 is a minimal system that is mainly built
statically with the sole purpose of being suitable to build a working system
from. It contains a cripled compiler as
Mike Frysinger is talking about choice and ignores me if i tell him,
that the emerge -e system uses the crippled gcc 3.3 for the first 10
packages until emerge -e system finally rebuilds gcc 3.3 (only due to
some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc
3.3).
i
Hi,
bootstrap.sh installs gcc 3.4! So far so good, but gcc 3.3 is not
unmerged. The consequence is, that emerge -e system installs gcc 3.4
and then afterwards gcc 3.3 instead of libstdc++-v3.
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
that's a bad idea imo
let the user decide which gcc they wish to have
But doesn't bootstrap.sh rebuild gcc? I have to take a look again, but i
think bootstrap.sh rebuilt gcc 3.4 only
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
that's a bad idea imo
let the user decide which gcc they wish to have
So i understand what you're trying to tell me, but bootstrap.sh makes
the choice already:
bootstrap.sh only
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
so that a clean system is built with gcc 3.4 only!
Nope. We don't want to remove that choice from the user. We are
working now towards the 2006.0 release, which means GCC 3.3 will not
that sounds rather unlikely, if gcc-3.4 was installed `emerge -e system`
would have rebuilt it, not the 3.3 version (unless there is a dep on
3.4 in system).
Does this have something to do with it?
gcc-3.4.4-r1.ebuild:
PDEPEND=|| ( app-admin/eselect-compiler sys-devel/gcc-config )
at any rate, this will all fix itself when 2006.0 is released
OK, i give up.
IMHO, i would expect that /usr/portage/scripts/bootstrap.sh; emerge -e
system results in a system, that has a certain integrity with a
minimum of manual steps. (gentoo install being as easy as possible)
At the moment,
Seems like a bit ranting to me. Why do you use unsupported installation
method if you want it simple?
I don't know about Sven, but the reasons I prefer the unsupported
installation method is all outlined here:
I have no clue, what bootstrap.sh is for anymore.
For me, Installing gentoo was
Hi,
so look at this:
# equery l |grep sun-jdk
dev-java/sun-jdk-1.4.2.10
dev-java/sun-jdk-1.5.0.06-r2
# emerge -up sun-jdk
These are the packages that I would merge, in order:
Calculating dependencies ...done!
# emerge --oneshot =dev-java/sun-jdk-1.4* -p
These are the packages that I would
init.d scripts should have a pure env given to them ... which means, they
should be run with `env -i` and have only whitelisted variables given to them
(and everything that appears in /etc/conf.d/$service /etc/conf.d/rc
and /etc/rc.conf) ...
Now that may be too few variables. At least the
I must say I have been wondering about this for a while too.
A solution might be add some sort of flag to packages that are binary,
and then let portage install libstdc++ the first time you install this
kind of package.
You mean, like have binary packages depend on
Perhaps the init script loader should be changed such that the environment
variables from the shell calling the script are ignored, and an
environment equal to that when being called by init is used.
Definitely. There shouldn't be two different environments depending on
whether a init-script
The init script will not see those variables when it is run by /sbin/rc
which is in turn run by init which is what happens on boot. The
environment is empty then, and if you want to reproduce it accurately
for your tests, you should do:
env -i /etc/init.d/test restart
It does see
Hi,
i just wrote an init.d-script and i thought that the LANG variable was
inherited since it set system-wide in /etc/env.d/02locale and therefor
is also found in /etc/profile.env
Now i noticed, that LANG isn't set for the process started by my
init.d-script.
So what's the intension to ignore
The termcap method is provided by libtermcap-compat. Most applications
which use this method only do so as an option for systems where terminfo
is not available -- for example, for Vim, terminfo vs termcap is a
compile-time option. The termcap database is limited, generally out of
date and
See, certain terminal emulators lie about their TERM setting. Usually
it's things that aren't xterm pretending to be an xterm, although rxvt
sometimes crops up too. Examples of things pretending to be xterm
include Konsole, Gnome Terminal.
The logic behind it goes like this:
* We don't
In my humble opinion, Gentoo is missing too many points to be an
enterprise Linux. We commit to a live tree. We don't have true QA,
testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles.
We don't really have product lifecycles, since we don't generally
backport fixes to older
Out of curiousity, has any put any thought into some automated method
or hook for allowing restarting of rc-scripts on upgrade/re-emerge of
a package?
Other question is if any such hook is even needed.
So... thoughts? I don't really have any input on it, aside from I'd
like to gather
Unless there are objections, I am planning on unmasking
gentoolkit-0.2.1_pre3 this weekend. This build of gentoolkit contains
the new version of revdep-rebuild. This version has been in the tree
and package masked since 12 June. During that time, I have not received
any bug reports and the
59 matches
Mail list logo
