Forums

Skip to content

Advanced search
  • Quick links
    • Unanswered topics
    • Active topics
    • Search
  • FAQ
  • Login
  • Register
  • Board index Discussion & Documentation Documentation, Tips & Tricks
  • Search

app-portage/cfg-update - installation instructions

Unofficial documentation for various parts of Gentoo Linux. Note: This is not a support forum.
Post Reply
Advanced search
249 posts
  • Page 4 of 10
    • Jump to page:
  • Previous
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 10
  • Next
Author
Message
zebrapad
Tux's lil' helper
Tux's lil' helper
User avatar
Posts: 83
Joined: Mon Jul 12, 2004 8:24 am
Location: Leuven, Belgium

  • Quote

Post by zebrapad » Sat Jan 15, 2005 11:24 am

The script could add some option to copy the new file... example:
Update file : /etc/init.d/portmap ? [y|n|q|?] ?
[y]es merge the new and current config file in xxdiff
[n]o skip this file and go to the next config file
[q]uit quit immediately
change to:
(2/71) /etc/init.d/portmap [no index]
Update file : /etc/init.d/portmap ? [y|n|c|a|q|?] ?
[y]es merge the new and current config file in xxdiff
[n]o skip this file and go to the next config file
[c]opy copy the new file
[a]uto automatically merge the file
[q]uit quit immediately

plus,

if the user has created a .merge file ... do not ask for confirmation to use that merged file. Speaking for myself, I was sure when I saved it in xxdiff :)
specs that may be relevant to my post: AMD Phenom II X3 720, NVidia GTX260, Gentoo Linux 64bit 2008.0, GCC 4.4.1, -march=amdfam10 -O2 -pipe
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Sat Jan 15, 2005 6:52 pm

zebrapad wrote:The script could add some option to copy the new file...
Well, these are your options:

Code: Select all

  [y]es       merge the new and current config file in xxdiff
  [n]o        skip this file and go to the next config file
  [o]verwrite   <--------------- THIS IS WHAT YOU WANT !?
  [q]uit      quit immediately
But there are two situations that can disable the [o]verwrite option.

1. If cfg-update is installed while ._cfg0000_files are present on your
system, the first update session cannot use the automerge/overwrite
functionality! Cfg-update can't make a checksum index until all the
._cfg0000_files are updated manually... after it has created the checksum
index, cfg-update can automerge of if automerge is disabled if will show
the [o]verwrite option.

2. Unless, that configuration file has been edited by you. In this case
cfg-update disables the [o]verwrite function and forces you to update
the file with xxdiff. (this is what makes cfg-update so safe!)
plus, if the user has created a .merge file ... do not ask for confirmation to use that merged file. Speaking for myself, I was sure when I saved it in xxdiff :)
Well, if you have saved the merged result as .merge you still
have to replace the current config file with the .merge file, otherwise it
still isn't updated!

If you accept the .merge file, cfg-update will backup the current config
file before it overwrites it with the .merge file...
When all else fails, read the manual...
Registered Linux User #340626
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Mon Jan 24, 2005 5:30 pm

Version 1.7 released...

Please test it and report any bugs in this thread: Troubleshooting cfg-update...

It can use meld now :D
When all else fails, read the manual...
Registered Linux User #340626
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Wed Jan 26, 2005 7:47 am

I have fixed a typo in the ebuild...

Users who have installed cfg-update v1.7 before this post date/time should
manually edit "/usr/local/portage/app-portage/cfg-update-1.7.ebuild"
Just change line 18:

Code: Select all

gnome? ( >=dev-util-meld-0.9 )"
to:

Code: Select all

gnome? ( >=dev-util/meld-0.9 )"
Otherwise you can encounter this error:
emerge: there are no ebuilds to satisfy ">=dev-util-meld-0.9".

Code: Select all

root@kbl-vlis3383 852MHz 59C / $ emerge -uDp world

These are the packages that I would merge, in order:

Calculating world dependencies \
emerge: there are no ebuilds to satisfy ">=dev-util-meld-0.9".


!!! Problem with ebuild app-portage/cfg-update-1.7
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.
When all else fails, read the manual...
Registered Linux User #340626
Top
ccduffy
n00b
n00b
Posts: 3
Joined: Sat Feb 05, 2005 7:08 am
Location: Austin, TX

diff3 merging support?

  • Quote

Post by ccduffy » Sat Feb 05, 2005 7:19 am

I'm something of a fan of diff3-style merging (such that, instead of just merging 2 files together, a common ancestor is available to figure out which diff sections can be applied without human intervention and which require real human intervention) -- this should make it vastly easier to avoid presenting the user with updates to config files that they never touched/don't care about in the first place, and is IMNSHO the way that etc-update itself should have been written.

The etc-update replacement etc-update.rb (at http://www.wingding.demon.nl/etc-update.rb) does exactly this -- but lacks the other functionality and slickness of cfg-update (and, for whatever reason, doesn't see all pending updates). Any chance of some future cfg-update release adding diff3 functionality?

Roughly, this would mean keeping a full copy of the ancestor around (rather than just its md5sum) and using this file for merges. Both xxdiff and meld support 3-way merging (and though meld lacks diff3-style automerge support, it's on the TODO).
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

Re: diff3 merging support?

  • Quote

Post by xentric » Sat Feb 05, 2005 8:17 am

ccduffy wrote:I'm something of a fan of diff3-style merging (such that, instead of just merging 2 files together, a common ancestor is available to figure out which diff sections can be applied without human intervention and which require real human intervention)
I'm already implementing this in the next version... still have some testing to
do. kdiff3 can do this sort of diffing and merging and cfg-update already makes
backups of the files it updates, so keeping another (anchestor) copy shouldn't be
too much of a problem to implement.
When all else fails, read the manual...
Registered Linux User #340626
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Sun Feb 06, 2005 5:19 pm

I can't get a usable result with 3-way diffing/merging and I'm starting to believe
that it's not really usable for automatic updating of configuration files due to the
nature of the whole 3-way diffing thing... I conclude that 3-way diffing was designed
to merge differences, not similarities... Please correct me if I'm wrong!

Here's an example to illustrate the logic behind the 3-way diff:
Two developers are both editing the sourcecode of program v1.0 and after a long
day of fixing bugs and implementing new stuff they decide to combine their work
into a new version v2.0! So one of the developers simply does a 3-way diff/merge
"$diff3 MY_VERSION OLD_VERSION YOUR_VERSION --output NEW_VERSION"
This works for them because differing or new lines are added to the new version
of the program.


But merging configuration files needs a different 3-way diff. We need the similarities
not the differences! So here's what happends:

/etc/example.ancestor (This is the base- or ancestor-file we kept around)

Code: Select all

#header v1.0 - dec 2003
param1=customized_value
param2=customized_value
param3=default_value
/etc/example (This is the current configuration file)

Code: Select all

#header v1.1 - aug 2004
param1=customized_value
param2=customized_value
param3=default_value
/etc/._cfg0000_example (This is the newest version available):

Code: Select all

#header v1.2 - nov 2005
param1=default_value
param2=default_value
param3=default_value
param4=default_value
Here's what we need to successfully update our config file:
The ._cfg0000_ file has a new parameter (param4) and we want this to end
up in the merged output. But we also have customized values in the current
and ancestor file! So we want our customized values and the new parameter
all to end up in the output file, which will become our updated config file...



Ok, let's try running kdiff3 (or any other 3-way diff tool) like this:

Code: Select all

           MINE             YOURS                        ANCESTOR                   OUTPUT
kdiff3 /etc/example /etc/._cfg0000_example --base /etc/example.ancestor --output /etc/example.merged
/etc/example.merged (The automatically merged result)

Code: Select all

<merge conflict - 3 different lines - you have to manually choose>
param1=default_value
param2=default_value
param3=default_value
param4=default_value
Even though both the current config file and the old ancestor config file have
customized parameters, the "differing" version is used in the merged output.
We don't get our customized values but we do get the new parameter line.
To be useful for auto-updating we need both so we can't use 3-way diff like this!



Ok, let's try to trick the 3-way diff by using the ._cfg0000_ file as ancestor:

Code: Select all

           MINE                YOURS                    ANCESTOR                      OUTPUT
kdiff3 /etc/example.ancestor /etc/example --base /etc/._cfg0000_example --output /etc/example.merged
/etc/example.merged (The automatically merged result)

Code: Select all

<merge conflict - 3 different lines - you have to manually choose>
param1=custom_value
param2=custom_value
param3=default_value
<no source line>
Cool, now we have our customized values in the merged output. But this time
the new parameter isn't included automatically...


So, looking at these examples I think that 3-way diffing isn't very useful for
automatically merging configuration files. Well... at least it won't merge them
completely without user input. You'll be missing either your customized values
or newly included lines. You can't have both due to the fundamental design of
the 3-way diff. Or am I overlooking something? :roll:
When all else fails, read the manual...
Registered Linux User #340626
Top
ccduffy
n00b
n00b
Posts: 3
Joined: Sat Feb 05, 2005 7:08 am
Location: Austin, TX

3-way diffing

  • Quote

Post by ccduffy » Sun Feb 06, 2005 10:33 pm

xentric wrote:So, looking at these examples I think that 3-way diffing isn't very useful for
automatically merging configuration files. Well... at least it won't merge them
completely without user input. You'll be missing either your customized values
or newly included lines. You can't have both due to the fundamental design of
the 3-way diff. Or am I overlooking something? :roll:
Use the old original (non-modified) file as ancestor.

foo.conf.base:

Code: Select all

#header v1.0
param1=default_value
param2=default_value
param3=default_value
foo.conf:

Code: Select all

#header v1.0
param1=default_value
param2=modified_value
param3=modified_value
foo.conf.new:

Code: Select all

#header v1.1
param1=default_value
param2=default_value
param3=default_value
param4=default_value
Unfortunetly, GNU diff3 still doesn't handle this quite right -- its behaviour is closer if there's space between the parameters such that they don't get chunked together (in which case it preserves the user's changes to param2 but not param3), but it's still not adequate. I'm playing with finding a solution -- but in the mean time, a simple reapplication of GNU Arch's update algorithm, with a little extra help from wiggle, presents itself:

Code: Select all

diff -u3 foo.conf.base foo.conf.new > foo.conf.patch
patch foo.conf foo.conf.patch
wiggle foo.conf foo.conf.rej > foo.conf.updated
This is a slight bit dangerous, since wiggle tries hard to apply changes to the point of being willing to do risky things. Correspondingly, if patch outputs a reject file and it's necessary to call wiggle, this should be followed up by giving the user an opportunity to accept or reject wiggle's proposed resolution (using meld, xxdiff, whatever, to merge foo.conf with foo.conf.updated).

foo.conf.updated:

Code: Select all

#header v1.1 - dec 2004

param1=default_value
param2=modified_value
param3=modified_value
param4=default_value
Volia!

The immediate impact of all this that the unmodified _cfg files should start being saved for posterity ASAP, since none of this goodness (either as above or diff3-based, if those wrinkles ever get ironed out) works without them.
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Sun Feb 06, 2005 11:16 pm

Ahh... now I get it :D

I need to use the previous ._cfg0000_foo as the ancestor, not the previous
/etc/foo ! I verified it and it works as it should... thanks for pointing me in the right direction !
When all else fails, read the manual...
Registered Linux User #340626
Top
cmuench
Tux's lil' helper
Tux's lil' helper
Posts: 110
Joined: Tue Jan 04, 2005 12:24 pm
Contact:
Contact cmuench
Website

  • Quote

Post by cmuench » Mon Feb 07, 2005 9:25 pm

I did the digest instructions and it gave me this error

[code] ebuild /usr/local/portage/app-portage/cfg-update/cfg-update-1.7.ebuild digest
!!! aux_get(): ebuild path for 'app-portage/cfg-update-1.7' not specified:
!!! None
!!! aux_get(): ebuild path for 'app-portage/cfg-update-1.7' not specified:
!!! None
doebuild(): aux_get() error reading app-portage/cfg-update-1.7; aborting.
[/code]
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Tue Feb 08, 2005 4:52 pm

cmuench wrote:I did the digest instructions and it gave me this error...
Check if /etc/make.conf has this line:
PORTDIR_OVERLAY="/usr/local/portage"
If you use another overlay directoy you have to change the digest command
to match your overlay directory.
When all else fails, read the manual...
Registered Linux User #340626
Top
cmuench
Tux's lil' helper
Tux's lil' helper
Posts: 110
Joined: Tue Jan 04, 2005 12:24 pm
Contact:
Contact cmuench
Website

  • Quote

Post by cmuench » Tue Feb 08, 2005 9:23 pm

Okay i installed it okay and then when I typed in cfg-update -u it asked me about /etc/fstab I said overwrite without thinking. Know my /etc/fstab looks way different and I don't think its right. Is there any way I can get my old fstab. PLEASE HELP ME I don't want to reinstall my system.
Top
radfoj
Guru
Guru
User avatar
Posts: 490
Joined: Fri Dec 31, 2004 12:02 pm
Location: Tísek, Czech Republic
Contact:
Contact radfoj
Website

  • Quote

Post by radfoj » Tue Feb 08, 2005 9:40 pm

cmuench wrote:Okay i installed it okay and then when I typed in cfg-update -u it asked me about /etc/fstab I said overwrite without thinking. Know my /etc/fstab looks way different and I don't think its right. Is there any way I can get my old fstab. PLEASE HELP ME I don't want to reinstall my system.
I am also new to this script, but think, no problem. If you type "cfg-update" - it will show you options. You can see -b option, which list backup files and -r option will restore backup files. But be patient. You must a little understand, what are you doing. Btw. this thread is not for such questions. See first post here by xentric. Good luck.
Top
ccduffy
n00b
n00b
Posts: 3
Joined: Sat Feb 05, 2005 7:08 am
Location: Austin, TX

Release schedule? Public RCS access?

  • Quote

Post by ccduffy » Fri Feb 18, 2005 10:38 pm

So, I'll be honest: I'm impatient to see a diff3-enabled release.

Any word on when 1.8 will be done, other than "when it's ready"? How about public access to whatever revision control system you happen to use so that we can poke around / test your new version / break our systems with it?
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

Re: Release schedule? Public RCS access?

  • Quote

Post by xentric » Sat Feb 19, 2005 3:19 am

ccduffy wrote:So, I'll be honest: I'm impatient to see a diff3-enabled release.
I'm not using CVS but I'd give you a snapshot to play with if I thought it would be remotely useful.
Right now the v1.8 script doesn't update correctly and the 3-way-merge is only half implemented.
So I won't let you mess up your system with it... yet.

Can't give you an acurate estimate on when it's ready for release, but I'll promise to make you the
first official beta-tester of cfg-update when basic functionality is restored and 3-way-merging is
properly implemented :D OK !?
When all else fails, read the manual...
Registered Linux User #340626
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

Re: GUI alternative for etc-update -> cfg-update v1.7

  • Quote

Post by xentric » Wed Apr 06, 2005 8:38 pm

wrong button... oops
When all else fails, read the manual...
Registered Linux User #340626
Top
Freejack00
n00b
n00b
Posts: 22
Joined: Mon Aug 02, 2004 10:01 pm

  • Quote

Post by Freejack00 » Tue Apr 12, 2005 7:43 pm

Nice program and idea, would be nice to have a link to the program.
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Wed Apr 13, 2005 10:25 pm

Freejack00 wrote: would be nice to have a link to the program.
I'm afraid I don't understand what you want... if you want it in portage, just
hold your breath as I guess it won't take long before it will be accepted!

I'm currently testing the last fixes in version 1.7.1 and when it's done
it will hopefully be added to the main portage tree very soon!

I will not rush to release version 1.8.0 but it won't take long before
that version is ready for release. Implementing of 3-way merging is almost
done and there are only a few functional modifications I still have to do...
Considering the time I have at the moment, I guesstimate version 1.7.1
to be ready by this weekend, and version 1.8.0 in about 4 weeks...
When all else fails, read the manual...
Registered Linux User #340626
Top
infamousmrsatan
Apprentice
Apprentice
User avatar
Posts: 201
Joined: Thu Jan 08, 2004 12:06 pm
Location: California

  • Quote

Post by infamousmrsatan » Thu Jun 09, 2005 11:17 am

w00t!

I just noticed that cfg-update is in portage now! Anyway, I was wondering if there's any housekeeping I have to do if I have the old stuff installed in /usr/local/portage, etc. Is there anything I should/have to do, or just emerge the ebuild?

If this is mentioned elsewhere, feel free to just direct me.

Thanks in advanced!

jms
Registered Linux User 344425
Join the adopt an unanswered post initiative today!
Por favor, corrija mi espanol!
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Thu Jun 09, 2005 4:54 pm

I removed my overlay ebuild with "emerge -C cfg-update" and then
removed the /usr/local/app-portage/cfg-update directory...
Then I proceeded with a normal "emerge cfg-update". It will re-use
the checksum-index and shouldn't have any problems whatsoever.

Just follow the installation steps in the first post of this thread :)
When all else fails, read the manual...
Registered Linux User #340626
Top
[UK]Superdude
Tux's lil' helper
Tux's lil' helper
User avatar
Posts: 149
Joined: Mon Jul 22, 2002 10:34 am
Location: Adelaide, Australia

  • Quote

Post by [UK]Superdude » Sat Jun 11, 2005 8:05 am

Just thought I would quickly say how impressed I am with this tool.
I think the idea of indexing config files and recoording which ones are unmodified
is an innovation that really should be in portage by default.

Just a small thing that may imrpove it would be to set the alias in roots
.bash_profile (Ideally it would check to see what shell people are using
and update the correct profile). The main reason I say this is for the people
(like me :)) who use emerge -ps as a normal user for the searching of portage
and have no need to run cfg-update.
Was there any reason against doing it this way? I do realise that /etc/profile is convenient, but
I dont think it really needs to be a system wide alias, having it as root should be enough, shouldn't it?

In any case, good work, makes gentoo even more powerful than it was before
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Sat Jun 11, 2005 12:45 pm

[UK]Superdude wrote:Just a small thing that may imrpove it would be to set the alias in roots
.bash_profile (Ideally it would check to see what shell people are using
and update the correct profile). The main reason I say this is for the people
(like me :)) who use emerge -ps as a normal user for the searching of portage
and have no need to run cfg-update.
Was there any reason against doing it this way?
I have this issue on my todo list for the 1.8 version. I guess your suggestion
to put the alias in /root/.bash_profile is probably the best solution...
I can't make the checksum-index world writable (for security reasons)
so users need to use emerge (for installing) with root privileges anyway
if they want cfg-update to update it's checksum-index.
An alias in /root/.bash_profile will be sufficient.

I'll test it and implement it... Thanks !
When all else fails, read the manual...
Registered Linux User #340626
Top
jsgaarde
n00b
n00b
User avatar
Posts: 9
Joined: Thu Mar 24, 2005 7:48 pm

  • Quote

Post by jsgaarde » Sun Jun 12, 2005 11:36 am

I'm trying to run cfg-update, but:

First run

Code: Select all

gentoo jsg # cfg-update --off
Portage Log not found...
Enable PORT_LOGDIR in /etc/make.conf
Recommended: PORT_LOGDIR=/var/log/portage
Make sure the directory exists!
Create log dir

Code: Select all

gentoo jsg # mkdir /var/log/portage
Edited /etc/make.conf

Code: Select all

gentoo jsg # cat /etc/make.conf
# These settings were set by the catalyst build script that automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example
CFLAGS="-march=athlon-xp -pipe -O2"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
GENTOO_MIRRORS="http://mirror.uni-c.dk/gentoo http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo"
USE="-gtk -gnome qt kde dvd alsa cdr winbind live nas network divx4linux 3dnow nvidia mozilla sdl dvdr ffmpeg"
PORT_LOGDIR in /etc/make.conf
Second run

Code: Select all

gentoo jsg # cfg-update --off
No (protected) directories found...
Now what should I do?

Best regards
Jakob Simon-Gaarde
Top
mirko_3
l33t
l33t
User avatar
Posts: 605
Joined: Sun Nov 02, 2003 4:14 pm
Location: Birreria

  • Quote

Post by mirko_3 » Sun Jun 12, 2005 11:53 am

Code: Select all

mirko_3@mirko3 ~ $ cat /etc/make.conf|grep PORT_
PORT_LOGDIR=/var/log/portage
This, maybe?
Non fa male! Non fa male!
Top
xentric
Guru
Guru
User avatar
Posts: 410
Joined: Sun Mar 16, 2003 1:57 am
Location: Netherlands

  • Quote

Post by xentric » Sun Jun 12, 2005 8:18 pm

Yeah, it must have this line:

Code: Select all

PORT_LOGDIR=/var/log/portage

Code: Select all

No (protected) directories found...
This worries me... it basically means that you never have to use
etc-update or cfg-update because you never get any ._cfg0000_ files
on your system as portage simply replaces your config files with
default files. You can imagine what happends if /etc/fstab get's
overwritten. If you do a world update, your system may become
unbootable due to overwritten files...

If you really haven't got any protected directories you better
search the forums on how to fix this ASAP!


If you have fixed the above, you run "cfg-update --on" (only once)
to integrate cfg-update into every emerge action. You just turned it
off with the --off option. You can use cfg-update without emerge
integration, but then it can't tell you if files are modified or not...
that means manual merging for each and every ._cfg0000_ file.

For normal use you simply do "cfg-update -l" to see which files have
updates, followed by "cfg-update -u" to start the updating process.
It's as simple as that...

BTW, what gave you the impression that you should run "cfg-update --off"?
I really want to know if there are unclear instructions in the manpage,
install instructions on the forums, or in the usage output...
When all else fails, read the manual...
Registered Linux User #340626
Top
Post Reply

249 posts
  • Page 4 of 10
    • Jump to page:
  • Previous
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 10
  • Next

Return to “Documentation, Tips & Tricks”

Jump to
  • Assistance
  • ↳   News & Announcements
  • ↳   Frequently Asked Questions
  • ↳   Installing Gentoo
  • ↳   Multimedia
  • ↳   Desktop Environments
  • ↳   Networking & Security
  • ↳   Kernel & Hardware
  • ↳   Portage & Programming
  • ↳   Gamers & Players
  • ↳   Other Things Gentoo
  • ↳   Unsupported Software
  • Discussion & Documentation
  • ↳   Documentation, Tips & Tricks
  • ↳   Gentoo Chat
  • ↳   Gentoo Forums Feedback
  • ↳   Duplicate Threads
  • International Gentoo Users
  • ↳   中文 (Chinese)
  • ↳   Dutch
  • ↳   Finnish
  • ↳   French
  • ↳   Deutsches Forum (German)
  • ↳   Diskussionsforum
  • ↳   Deutsche Dokumentation
  • ↳   Greek
  • ↳   Forum italiano (Italian)
  • ↳   Forum di discussione italiano
  • ↳   Risorse italiane (documentazione e tools)
  • ↳   Polskie forum (Polish)
  • ↳   Instalacja i sprzęt
  • ↳   Polish OTW
  • ↳   Portuguese
  • ↳   Documentação, Ferramentas e Dicas
  • ↳   Russian
  • ↳   Scandinavian
  • ↳   Spanish
  • ↳   Other Languages
  • Architectures & Platforms
  • ↳   Gentoo on ARM
  • ↳   Gentoo on PPC
  • ↳   Gentoo on Sparc
  • ↳   Gentoo on Alternative Architectures
  • ↳   Gentoo on AMD64
  • ↳   Gentoo for Mac OS X (Portage for Mac OS X)
  • Board index
  • All times are UTC
  • Delete cookies

© 2001–2026 Gentoo Foundation, Inc.

Powered by phpBB® Forum Software © phpBB Limited

Privacy Policy