Re: [gentoo-dev] Documentation Encoding
Damian Szeluga wrote: I'm using UTF-8 encoding in my system. The main problem is, that lots of /usr/share/man/* and /usr/share/doc/* files are iso8859-2 encoded (as my LINGUAS is set to pl). I think, that Portage itself should recode all the files, which go to /usr/share/man/ and /usr/share/doc/ directories to UTF-8 by default. Not sure if that will be an easy task since the source encoding is probably not known. Probably this should go upstream? There's also a problem with Groff, which is unable to show unicode chars correctly. I made a package to solve it (http://hoth.amu.edu.pl/~d_szeluga/groff-utf8.tar.bz2), but I think it's a bit dirty hack. I am absolutely out of time now, hope to be able to look at it in a week. .. actually I had a look :-) So this is a different package from groff as it seems. http://www.haible.de/bruno/packages-groff-utf8.html Dunnow, but probably trying to integrate UTF-8 support in groff and working with upstream should be doable if that package is working? We in JP land often have problems with Japanese man pages and others and there was a patch floating around (USE=cjk emerge groff) that kind of solves the problem a bit. So, fixing groff is definately a good idea! Any takers? ;-) The last time I looked in the code I couldn't make much out of it :-( Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugday reminder
Bjarke Istrup Pedersen wrote: Something interresting has happend since last, the new bugday site has gone into official beta, and can been seen on http://bugday.gentoo.org/bugdaytest . Please do some testing with it, and report any bugs you find back to me. Bug #1: Do *NOT* ask for Bugzilla credentials over plain HTTP! Even if it is just beta testing, you are using real account information and that is a very bad approach as far as security practices go. Add SSL support (or fix it, 'cause https://bugday.gentoo.org/bugdaytest/ is a 404 and https://bugday.gentoo.org/ is plain bugs.gentoo org or is it?) Bug #2: Add an error page explaining what is wrong with a login attempt If you try to login, you are just thrown back to the original URL (slightly dressed up as http://bugday.gentoo.org/bugdaytest/bugday.php) without any notice of a failed login attempt. When Bug #1 gets fixed, I can further test. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sandboxes
Thomas Cort wrote: Thoughts on ideas on this somewhat more focussed idea? ( or at least I think it's more focused :P ) Will there be restrictions on what can go into these overlays? There are some ebuilds that aren't allowed in the main portage tree. One example is winex-cvs (see app-emulation/winex-cvs/winex-cvs-3000.ebuild for details). Interesting comments, and I cannot blame them too much. Another example... an overlay dev could take an existing ebuild that has RESTRICT=fetch and modify it to fetch the package directly without user interaction. Yes, this one is a good example. So, in order not to be utterly responsible for distributing such things as *semi-offcial* gentoo work, I'd suggest just providing a bit easier way to use external overlays than the current one (which is easy enough once you set it up, but generally hard for n00bs). I have my own overlay for quite some time and it had helped a few people, not counting me (/me != dev) [1] [1] http://rsync.tar.bz/ I know this is always a topic on whether to have a knife is good or bad, and whether just possessing a gun makes you a bad guy... Same is here - if there is a possibility some people will eventually abuse it. But is this enough to disallow it whatsoever. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
Lars Weiler wrote: * Patrick Lauer [EMAIL PROTECTED] [06/02/28 11:58 +0100]: Enabling the unicode useflag in the profiles should help our international users and should not cause any problems. Are there any known bugs / problems this would trigger? Any reasons against that? It is enabled by default. At least on ppc. And that since, uhm, summer 2004? I can't say if there are any problems, as I didn't received a bug for a long time. Well there are a few problems, but yes I cannot name them now. Using Japanese, Cyrillic and English in a few encodings each is a big nightmare. Nowadays I try to move everything to UTF-8, but there are those windoze users and webdevs that make all Japanese in Shift_JIS ... So support of wide range of encodings is a must, but UTF-8 is the truth. The only thing that's nasty: we don't have any good utf8-fonts for the console. And not only the console. Even for xterm there are not many good fonts (known to me) that display both Japanese and Cyrillic in regular and bold. Currently there is only on combination that works for me. So fonts, font config and related stuff is what has to be fixed first. Kalin. P.S. And before fixed, it has to be filed... Promise to take notes (again) when I see something. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2006.0 - me having a bad day?
Jeffrey Forman wrote: On Sun, 2006-02-26 at 22:54 -0500, Andrew Muraco wrote: I second that there is a massive confusion of naming, and this needs to get sorted out (or atleast explained) Because I'm sure the mirrors will start getting slamed with people downloading 2006.0. Lets not waste anyone's bandwidth nor the mirrors by leading people to download the wrong thing. Andrew, I do not mean to cop an attitude, but please give me some time here to figure this out. This is the first time I myself am handling the bouncer administration for a release, and I would really appreciate some patience on your part. I am updating the page as fast as I find an error in it. Thanks. Thank you for your effort, Jeffrey! It may turn a good day after all :-) Have you (or RT) actually thought of providing a pivoted list for downloads? I feel it is more reasonable to first choose your arch (i.e. on what hardware you want to install Gentoo) and then see what options you have. As opposed to the following imaginary n00b: 1. I want a Universal CD! 2. Hmm, it is not that universal if I need to choose my arch (I've read the link on arches!)! 3. Hey, wait a minute! What is that 64bit - 32bit userland ??? What is 64bit? What is userland? (wasn't coverd under arches) 4. Lets do some research... ok, I got it there is difference between kernel that is 64bit and userland, cool! They should have stated: 64bit kernel + 32bit userland (and a plus is better than a minus, even if it is a hyphen) 5. Hmm, but I am using P4 after all, so I need x86! 6. Oops, where is the x86 Universal CD? 7. OK, there is a lonely x86 link under Gentoo 2006.0 LiveCD, probably that is what I need. But why did the change the name??? 8. Oh cool they have torrents here! Let me get that x86 Live CD with my torrent tool! Should probably be faster... (click on the torrent link) 9. Hmm, that x86-livecd-2006.0 should probably do. It is a CD image, so probably is an ISO file... Click! 10. Lets get some coffee, I am tired. But wait, what are these stages bla-bla (reading the handbook) OK, great, I might need them (didn't read that thoroughly after all, kind of tired). The torrents are not that fast after all and there are not enough seeds for stage3-x86-2006.0... (click back) 11. And where is the x86 package CD after all!!! Oh, it might be part of the LiveCD? I wonder, but is there any documentation (looking around the page...) Anywhere I can see the contents of the ISO files [1] (looking and clicking around...) no. 12. Sip from a big mug of coffee - Gentoo is not that hard after all, lets wait and see what am I downloading... [1] It might be a good idea to implement that. So sometiing like: Select your download according to your hardware architecture. (see ... for info on architectures or ... for the explanaiton of different CD types ) x86 (486, PentiumIII, Celeron... define it better) minimal livecd amd64 (AMD Athlon64 ...) minimal install packages . This will be easier not only for n00bs, I guess and is inspired by the Don't MAKE me think book on web design/usability. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] 2006.0 - me having a bad day?
Contgrats to the release team :-) But let me whine a bit, even a few KB: I just saw the GWN and the news about 2006.0 ... So reading at the release notes: This is also the first release with the Gentoo Linux Installer officially debuting on the x86 LiveCD, which will fully replace the Universal and PackageCD set. The LiveCD also features a fully-fledged Gnome environment. However the (normal) link to download it: http://www.gentoo.org/main/en/where.xml Shows: Gentoo 2006.0 Minimal install CD (around 125 megabytes depending on arch) alpha amd64 hppa ia64 ppc (32 bit) ppc64 sparc64 x86 Gentoo 2006.0 Universal install CD (up to 600 megabytes depending on arch) alpha amd64 hppa ppc (32 bit) ppc (64 bit) sparc64 Gentoo 2006.0 Package CD (up to 700 megabytes depending on arch) amd64 ppc (ppc) ppc (g4) ppc (64 bit - 32bit userland) ppc (64 bit - 64bit userland) sparc64 So there are the Minimal, Universal and Package CDs... No word of a LiveCD... No link to a Universal CD for x86... Browsing trough the torrents, there is a x86-livecd-2006.0 and x86-installcd-2006.0 ... yes, I figured out that x86-installcd-2006.0 is the Gentoo 2006.0 Minimal install CD for x86 or is it... will any n00b figure it out? And probably the properly(?) named livecd-amd64-installer-2006.0 and install-amd64-universal-2006.0 are here just to add some spice to the soup... Aha if I track all links in the bouncer, I start to understand... So, a link like that: http://bouncer.gentoo.org/?productgentoo-2006.0-universalos=amd64 is for the Gentoo 2006.0 Universal install CD for amd64 arch - cool! And it will bring you to install-amd64-universal-2006.0.iso! So just s/gentoo/install/ and stuff the os=(.*) in the middle - a piece of cake. Aaah, however forget about the Gentoo 2006.0 Package CD - they have a naming on their own and its scheme is too difficult to explain in a long mail like that. Just to toss a random example: packages-ppc64-32ul-2006.0.iso comes for ppc (64 bit - 32bit userland) of a Gentoo 2006.0 Package CD. The correspondence between Universal install CD and install-, Package CD and packageS is a drill left to the reader :-) And we are talking consistency here, yes simple as that. There are probably(?) good reasons behind the naming of the iso files (the torrent list does not show the .iso, but who cares, once you stuff it in your client you'll see it is an iso, right!), but are they good enough for inconsistent naming? Or there is a scheme I cannot guess... They might be good reasons not to include the Universal instal CD (i.e. which one in the torrents? aha, probably after all there is no Universal install CD for x86, it is called a LiveCD??? or /me again wrong...) in the bouncer - sure that is the most wanted CD, but that eats the most bandwidth. Or is it because it was hard to write the XML of the page because it is a structured, clerly defined language and makes it difficult to use inconsistent naming of the iso files?? Well, if that was the reason... But who knows. I might be just having a bad morning transforming into a bad day... I din't have enough time or will to help with the release, so I can only whine out loud. If you've read so far, fell free to light up your flamethrower, I should be able to stand it, or simply turn to ash. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: emerge snapshots
Hi all. During the last many months, more than once an idea occured in my mind, so I decided to share it. 2006-01-25T01:34 kalin $ dd if=/dev/brain of=gentoo-dev bs=1 count=3292 Do you think it will be good to have something like a snapshot of the installed packages? Something that will help when something unexpectedly breaks and you cannot fix it bu shuffling around its dependencies. Because s--t does happen; sometimes. Right now vmware-workstaion is broken and I am failing to understand why for the last few hours. But that is just an example, forget about it. So how can we get that thing? Let's call it emerge snapshot not to be confused with portage snapshots used during install. One way is to employ a version control system, say subversion, to keep the list of installed packages. It has to be updated during emerge. Also there should be a way to insert markers like OK, tested and working, going to try this fuzzy foo install, mark! All these should be timestamped. So after the _BANG_ my box is b0rked, it will be easy to retrace your steps by just doing `emerge --log 3` to see the last three labels/log entries: 35442006-01-01T12:12OK, tested and working 35452006-01-01T12:12going to try this fuzzy foo install, mark 35462006-01-01T12:12yay, new modular X is in ~arch (-: then `emerge --revert -r3544` and everything is smooth and runnig again. The behind the scenes actions to be taken by portage is to unmerge everything that was merged after -r3544 That was the easy part. Now what if some config file is b0rked? Solution 0 (slow, disk space): _before_ upgrading a package, or even before installing the same package in a new SLOT, do `quickpkg $PACKAGE` Solution 1 (better): Anybody? Some notes to consider: AFAIK, at present portage leaves most (all?) files that are in CONFIG_PROTECT on unmerge... is there any easy way to trace which files are left over in the system and delete them? Parsing the logs might help, but unless it is automated it will be error prone and cumbersome. Now imagine this timeline: r100 emerge foo r101 emerge --unmerge foo r102 Is there anything else to be taken care so that the system @r100 and @102 is the same? (sans system logs, user created files and the like) I guess all the tools and info are already in portage and by writing a bunch of scripts (to parse the logs mainly) it will be feasible to make it work. But if it is automated, this will give _HUGE_ advantages: 1. Users will be instructed to revert to a good point when something breaks. Probably an automated reporter can be hacked up 2. Bugs can easily be confirmed if there is enough CPU power (Give me your broken emerge snapshot and the one before that) 3. devs and trying-to-be-devs, testers will be able to test easily if package foo-2.3.4 does break something without the need of things like vmware (snapshots) 4. Any n00b will have the Ctrl+Z, Recycle bin, Trash bin, :undo whatever to their whole system 5. (dangerous) Experimenting on semi-production servers will be easy! 6. Given the above 5, Gentoo user base will grow enourmously: You have the flexibility, now you have stability. No need to dream, welcome to reality: it's called Gentoo! (from the 2006.3 release campaign :-) I know it is far from a GLEP, but let me first see how people feel about it. Even if not implemented as a whole (at first) it will greatly improve our Gentoo life. Any comments? It is an RFC after all :-) 2006-01-25T02:07 kalin $ -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] webapp.eclass documentation
Renat Lumpau wrote:
I just committed our new documentation [1] for webapp.eclass. We hope that it
will help devs and users write and maintain ebuilds for web applications.
Comments and patches are welcome.
We also have a brand new project page [2], courtesy of wrobel.
[1] http://www.gentoo.org/proj/en/webapps/webapp-eclass.xml
[2] http://www.gentoo.org/proj/en/webapps/
A few comments:
1. I can see this in many places of the Gentoo docs, so it is not specific
to this particular doc, but still: the CSS for span.code would better be
changed to use another color than the links. I very often catch myself
trying to click on it (e.g. I expected man 5 webapp.eclass to be a link to
the on-line man page; BTW that would not be a bad idea at all if it can be
kept in sync).
So if this is not supposed to be changed locally, (I see it is coming from
http://www.gentoo.org/css/main.css?d=20051010 ) whom shall I contact?
2. Consider this paragraph:
webapp.eclass is located in the usual place in the Portage tree. By default,
it will be found in /usr/portage/eclass/webapp.eclass. By definition, the
source code is the ultimate documentation and should be consulted whenever
something does not perform as expected or further clarification is required.
By default, it will be found in /usr/portage/eclass/webapp.eclass. is not
acurate I think ( found in /usr/portage/eclass/ is better). Even better if
you combine the first two sentences:
webapp.eclass is located under /usr/portage/eclass in a Gentoo default
installation.
BTW, is there an easy way to get the source XML of this (and other) doc? So
I can send patches directly.
3. The Beginner, Intermediate, Advanced section titles might be better if
they are a bit longer, say: A Beginner example ebuild: www-apps/gallery
Is the version required for the sect title? Yes, it is required inside the
explanation though.
4. This warning:
Warning: If the package requires specific Perl modules, all dependencies
must have ebuilds available. Relying on CPAN is not acceptable.
Why is that? If I have a webapp that needs =dev-perl/foo-3.0.4 which does
not have (yet) an ebuild in /usr/portage what to do? Isn't the normal way to
fail the emerge because 'cannot find any ebuilds that satisfy
=dev-perl/foo-3.0.4! '
A helpful hint Try using `g-cpan -i foo` and reemerge ${PKG} will be very
good solution. Act accordingly for PHP, Ruby and whatever we have.
5. Just below the above warning, the discussion about databases...
A common mistake with specifying dependencies for web applications is to
unconditionally RDEPEND on a database engine such as MySQL or PostgreSQL.
Many, if not all, web applications are able to connect to a remote
database server. Thus, a local database should not be a requirement;
Perfect up to here.
the right syntax for dealing with this is:
Code Listing 2.8: Database Dependencies
mysql? ( =dev-db/mysql-4 )
/me might be wrong, but isn't this asking for the availability of a MySQL
server installed? Don't tell me webapp.eclass treats the RDEPEND differently!
Isn't it more normal to depend on, say dev-perl/DBD-mysql for a Perl webapp?
( change accordingly for PHP, etc.)
6. The last word :-)
- contact the web-apps herd or ask on aIRC/a.
+ contact the web-apps herd or discuss it on a#gentoo-web/a IRC channel.
Imagine reading it printed :-|
7. Having gone over it, why not webappS.eclass ?
$ ls /usr/portage/eclass/*s.eclass |wc -l
23
examples: euitls, games, nsplugins, xemacs-packages ...
Kalin.
--
|[ ~~ ]|
+- http://ThinRope.net/ -+
|[ __ ]|
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
Philipp Riegger wrote: On Jan 13, 2006, at 8:05 PM, Philippe Trottier wrote: Recipe for disaster, specially in a place like mine where sparc, alpha, x86_64 and ppc32/64 mix... not counting ia64 for a test run soon... If you really want to do this, someone has to make a rendezvous a la Apple. Where not only distcc says I am available but I am also doing the right stuff. This all is something, icecream[1] can do, i think. I am very interested in getting icecream to work with gentoo. [1] http://wiki.kde.org/icecream Yeah, this looks nice, will give it a try. Unfortunately it does not seem a drop-in-replacement for distcc (see the bottom of [1] above for Gentoo part) Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some LaTeX news
Alexandre Buisse wrote: Hi, for all of you who have been using latex on gentoo, here are some news on what is currently happening. A news is a good news, glad that there is something happening. First of all, we have a new tetex (tetex-3.0_p1). It should have hit the mirrors this morning. This is not an official release from upstream (that would be 3.1) but a snapshot of their development tree that corrects some bugs with the autotools (see bug #113024). If we manage to solve the etex related problems (all the Fatal error: I'm stymied), it could be a good candidate for stabilisation. A very exciting package has been added to portage lately, but it's still quite experimental : dev-tex/mpm (only keyworded ~x86 and hard-masked at the moment). It's basically the MikTeX package manager adapted for unix systems. As the texmf tree is always organized in the same way, it can interact with tetex quite nicely. Basically, you tell it which package you want from CTAN and it installs it automatically. It has so far been tested by a few people, including me, and seems to work fine without corrupting anything. However, it needs a lot more testing before even going to ~arch. Please report bugs or success in bug #110494 if you give it a try. What about having a g-ctan instead? Wasn't there one around, more or less based on g-cpan? And, last but not least, a LaTeX doc began. It's still a very early draft but any (constructive) criticism and help is most welcome. The discussion happens in bug #118405 and the last draft can be found on my devpage (http://dev.gentoo.org/~nattfodd). Not sure how does the new tetex handle i18n, but less than a year ago I had to use ptex to write Japanese (in euc-jp, AFAIR). There was some rumble about UTF-8 support, but did it get in? I have touched *tex only once (not very successfull because of i18n and windoze interoperability) since I left the university, but might look back again. XML---PDF is a tempting path, but is yet to be developed to *tex heights. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
Philippe Trottier wrote:
Lisa Seelye wrote:
On Thu, 2006-01-12 at 00:18 +, Ferris McCormick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 11 Jan 2006, Lisa Seelye wrote:
On Wed, 2006-01-11 at 14:51 -0800, Robin H. Johnson wrote:
I've been cleaning up media-fonts/ to work with modular-X, and I see a
lot of ebuilds with stuff like this:
for font in *.bdf; do
/usr/X11R6/bin/bdftopcf ${font} `basename $font .bdf`.pcf
done
gzip *.pcf
For having 100 files in *bdf, this is so serial it's painful.
And here I was hoping Distcc would get some usage. :(
Distcc gets lots of usage with modular X. But for the fonts? :)
Time for distfont? ;)
Make this distributed tool for tar zip bzip2 and gzip and I'm in, I
don't think it would be useful with anything else than Gigabit Ethernet.
We might want to have in the make.conf 2 separate variables, one of them
saying how many threads can be run on the machine, then How many
threads/process across a cluster.
For example, my Dual Xeon EM64T file server can do make -j4 locally,
like in make install, make docs etc etc, But for compiling I can use
-j20, really not useful over -j8 anyway. But the point is, it would be
usefully to separate the load distribution on the local machine and
cluster nodes.
As the discusison started...
I would like to be able to limit the -jN when there is no distcc host
available or when compiling c++ code, otherwise my poor laptop is dead with
-j5 compiling pwlib when the network is down
It is particular example, but being able to limit portage in some way as
total CPU, total MEM might be interesting (just nice-ing is not enough)
Kalin.
--
|[ ~~ ]|
+- http://ThinRope.net/ -+
|[ __ ]|
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
Patrick Lauer wrote: On Fri, 2006-01-13 at 19:53 +0900, Kalin KOZHUHAROV wrote: Make this distributed tool for tar zip bzip2 and gzip and I'm in, I don't think it would be useful with anything else than Gigabit Ethernet. One 2Ghz CPU can't even saturate a 100Mbit line with bzip2 as far as I can tell. Although the speedups won't be extreme it could just work. We might want to have in the make.conf 2 separate variables, one of them saying how many threads can be run on the machine, then How many threads/process across a cluster. For example, my Dual Xeon EM64T file server can do make -j4 locally, like in make install, make docs etc etc, But for compiling I can use -j20, really not useful over -j8 anyway. But the point is, it would be usefully to separate the load distribution on the local machine and cluster nodes. As the discusison started... I would like to be able to limit the -jN when there is no distcc host available or when compiling c++ code, otherwise my poor laptop is dead with -j5 compiling pwlib when the network is down As far as I can tell distcc isn't smart enough for dynamic load balancing. One could hack portage to test each server in the distcc host list and remove missing servers for each run - doesn't look elegant to me. Yes, might be a solution, even if not elegant. I am thinking also of automating distcc configuration (i.e. no need to run --set-hosts) and one idea is to use DNS with some TXT record, but that is just an idea - no patching is done yet. Not sure if distcc has local limiter, i.e. if it it set with localhost/2 and portage user (or some other user != root) tries to start 3 processes, the 3rd just blocks (and not take memory). I think not, so this thing might be interesting to implement (for old laptops with less memory). I think I should resubscribe to the distcc list :-) It is particular example, but being able to limit portage in some way as total CPU, total MEM might be interesting (just nice-ing is not enough) Very difficult - usually gcc uses ~25M per process (small source files), but I've seen 100M (most larger C++ files) and heard of ~600M per process for MySQL Limiting that is beyond the scope of portage. Hmm, may be not limiting the total usage, but more like just adjusting MAKEOPTS='-j1' in some cases (NOTE: to /me, define some cases). Implementing the above Local limiter in distcc will solve that automagically. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
Mike Frysinger wrote:
as one of the new sane features of the next portage-2.1_pre release, we're
looking to cut out use.defaults support
existing stable users wont be affected as the 2.0.x versions will continue to
carry support for this, but some of you stable users may notice some USE
flags suddenly disappearing
to recap, use.defaults inserts USE flags for you based upon what packages you
have installed when you havent declared a preference. for example, if you
have neither '-cups' or 'cups' in your USE (either in your make.conf,
profile, env, whatever), but you do have the net-print/cups package
installed, portage will add 'cups' to your USE
Can I just ask, since when is this feature on? I have never run into it...
Or is it because I always had:
USE=-* ${MY_USE}
in /etc/make.conf?
Is -* counted as preference? I thought that is ignoring just the ones in
the profile (just is plain wrong, as I didn't even feel there were other
useflags :-)
Kalin
--
|[ ~~ ]|
+- http://ThinRope.net/ -+
|[ __ ]|
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: ca-certificates PDEPEND
Andrea Barisani wrote: On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote: On Mon, 2006-01-09 at 16:55 +0100, Andrea Barisani wrote: Regarding the inclusion of ca-certificates as a PDEPEND (yeah a brief exchange of emails already happened on -dev but since it's not so easy to track it I'm lagging behind on this) I would like to express that I really don't like the fact that we are trusting cacert.org certs (among others) without providing it as a choice. Despite all the political views that we can throw in favour of a cacert.org are trying to make the SSL certs world less evil argument this is some major policy that we are supporting and it shouldn't be taken that lightly (I don't remember such a major confrontation about this) and I really don't think this should be a default policy but rather user's choice. Technically cacert.org is not a recognized CA in the proper way (and don't point that a proper CA is a lame concept and a snake oil thing..this is not the point). [CCing [EMAIL PROTECTED] because this concerns the team as well imho.] Just my 2 eurocent. P.S. I know that firefox doesn't trust /etc/ssl/certs by default, dunno about konqueror. The point is still relevant though. Do you think the PDEPEND of the ca-certs should be tied to a USE= flag? If so should it be a 'no*certs' flag or a USE=cacerts ? USE=cacerts sounds the proper course of action to me. I was just `emerge world -vDatu --newuse` on some ~x86 boxen and I saw the new (at least to me) cacert ebuild getting pulled. Although, I support cacert.org and use it occasionally, I also think making it the default is a bit too quick for now. Making it a useflag might be better. Are there any other packages like cacert now? Didn't see any, but time will tell. Might be a better solution to have a more general ebuild that installs CA certs and it will have different (local) useflags. Just my 2 non-dev Japanese yen :-) Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [dRFC] slotted mysql ready
Francesco Riosa wrote:
Background, to make life easyer for people that use more versions of
mysql (and just for fun) MySQL is going to be slotted.
Currently the slot enabled versions are mysql-4.1.16-r30
mysql-5.0.18-r30 mysql-5.1.4_alpha-r30, in short those with -r30.
The few patches needed are already included in current ~ mysql-4.1.16
and mysql-5.0.18 but hidden due to SLOT=0, starting from 2005-11
An eselect-mysql module has been prepared to create simlinks for the
desired version of mysql making easy to switch between them (hopefully)
The libraries (libmysqlclient co) don't follow this logic and the
higher version is always the default (similarly to sys-libs/db).
So how does this affect packages that use say dev-perl/DBD-mysql ?
If they can only use mysql-5, then the will be broken if they connect to a
mysql-4 server using non
UTF-8 encoding. (bad wording, but generally speaking, there is an inconsistence
in character
encoding betweet mysql-4 and mysql-5 that DOES break things on non ISO-8859-1
encoded databases)
The rc-scripts have been modified to use the logic of
sys-apps/baselayout net.ethx = net.lo symlink to be able to start more
servers at once (this is working from 2005-11 but reworked today)
Additionally the ebuilds code has been moved to two new eclasses,
mysql_fx.eclass and mysql.eclass, the first own support functions, the
last own the src_* pkg_* functions.
The initial idea is that when a specific ebuild need to marked stable
the code is moved from the mysql.eclass to the ebuild itself, to froze it.
Documentation on:
o switch to slotted
o upgrade with no downtime using this new capabilities
need to be written from scratch (this is going to be the more difficult
part for me).
there is a bash construct the eclass use to retrieve the latest two
chars of a string, in the form: MYVAR=${MYARRAY[3]:(-2)} , is this
acceptable?
The intention is to made mysql-5.0.18-r30 stable on 2005-02-15 at
maximum on the first archs.
AFAIK I'm the only one who have seen this stuff until now, any comment,
any suggestion is highly apreciated.
Kalin.
--
|[ ~~ ]|
+- http://ThinRope.net/ -+
|[ __ ]|
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Catalyst{,2} and 2006.0
Some time ago I sent a mail with the above subject and there was no response... Now I saw it went to the gentoo-server ML :-( /me bad So, resending some thoughts about catalyst here... So far I have played with catalyst, lately catalyst2, since gentoo-1.4 was released. AFAIR, 3 or 4 times. More or less it ended up nowhere because of lack of _real_ examples and documentation (seems to be getting better these days) combined with the long times to make a custom install CD starting form stage1. Machines are getting faster and more (as numbers of boxen), distcc and ccache are improving, so the latter problem has also been getting easier. So what about the first problem? Working, real configs for gentoo releases? I am thinking something of the kind, will it be possible/good/easy to start preparing a few configs for the next release (2006.0 right?), complete configs starting from say stage1-x86-2005.1-r1.tar.bz2 (as usually x86 is getting the most beating). BTW, will next release use catalyst or catalyst2? And as a good practice, leave all configs (for some time) in the source of catalyst sot that anybody , more in practice than in theory, can produce an install CD. The political aspect is that some script kiddies can start producing/selling/advertising my 0wn lin'x bootable CD, but hope we can catch them and educate them early that they'd better mention Gentoo :-) Customized bootable CD can be used NOT only for: Installing on strange hardware Upgrading some part of a release (kernel, gcc, security patches, etc.) quicker for new installs Changing some packages for others as default (vim for nano, iproute2 for ifconfig, mtr for traceroute, etc.) Giving to a (close or girl-) friend to install in a snap on her exotic laptop Making a quick restore CD (this thread was about that) Making a bootable gcc/distcc node (to use those few remaining windoze machines in your office at night, 'cause most don't support PXE netboot) Feel more Gentoo: optimized and customized for just about any application or need Make a small print firewall, still based on Gentoo one more reason yet another one [ add your 10 reasons here ] So, what do you think about that? Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Henrik Brix Andersen wrote: On Sun, Jan 01, 2006 at 05:30:01AM +, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I would like GLEP 45 [1] - GLEP date format - to be discussed and voted on. [1]: http://www.gentoo.org/proj/en/glep/glep-0045.html I am not a full time dev, so I cannot vote, but I am for this change. For the last several years I have been fighting with all possible software and OSes and even appliancies to implement/display/store ISO-8601 dates. I realized how good it is since I came to Japan which uses ore or less the same date format. 2006-01-02T13:10+0900 Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
Lares Moreau wrote: On Tue, 2005-12-27 at 22:10 +0200, Petteri Räty wrote: I see the point about not showing all the QA stuff to the 'regluar' user. Maybe only show this info on screen with --verbose set. As for the QA-warnings file, how does this differ from parsing the files in PORTLOG_DIR? Stuff that goes to PORT_LOGDIR is also shown to the user. Could it be split? Have the QA stuff shown on screen only when --verbose is set, but have all the information written to PORT_LOGDIR no matter the flag. That will be difficult to explain as a behaviour, not logical to me. In my experience most users don't use PORT_LOGDIR in the first place. People who want the information define PORT_LOGDIR and have the information. Why add files containing duplicate information? ditto. Imagine a world where every (Gentoo) user is a developer... dream... more! You are right - impossible. However, by bitching about problems, there are some users that decide to check WTF is this warning, in turn they urge devs to fix it (and that is the main point of QA, right?), they report it with their bug reports and so on. In other words, the problem gets _NOTICED_ by everybody. IMHO, leave it as it is now and don't bother. It is not that much of an output, compared to the compile output anyway. I'd prefer even having it red/bold/whatever for easy spotting. And for the future, what about defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in make.conf? And act acording to this, but trying to move the user up a level or two most of the time. Kalin. /know_how -master --dev/ -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
Lares Moreau wrote: On Wed, 2005-12-28 at 10:34 +0900, Kalin KOZHUHAROV wrote: what about defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in make.conf? And act acording to this, but trying to move the user up a level or two most of the time. This is what happens anyway, but it is called FEATURES :) From `man make.conf` FEATURES = sandbox ccache autoaddcvs Defines actions portage takes by default. These options should not be changed by anyone but developers and/or maintainers. 'sandbox' is an important part of FEATURES and should not be disabled by default. This is an incremental variable. So I guess I am close to developers and/or maintainers as I change that on day 0 on any Gentoo box I install :-) s/'sandbox' is an important part of FEATURES and should not be disabled by default/ 'sandbox' is an important part of FEATURES and should not be disabled by default (but disabled on `emerge perl`)/g or die; I still think, GENTOO_LEVEL is a better one though. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
Chris Bainbridge wrote: On 19/12/05, Peter Johanson [EMAIL PROTECTED] wrote: Or maybe not, I dunno. The point being I don't think we should immediately write off any of the distributed SCMs without pondering how they might make a difference or be usable. It would be very useful for people who aren't devs but only if they have access to the repository. It would also be useful for devs to have a standard way of publishing their testing/development portage overlays. On the first point, would any of the alternative SCMs prove to be better than CVS resource wise for providing anonymous access to users? It might also be useful to facilitate non-devs contributing patches to the tree - rather than posting files into bugzilla they could point towards whereever they publish their current tree (or changes), and developers can then work with their changes directly instead of the bugzilla upload/download dance we do now. I am using subversion for a year now, both for work, personal data, system administration (~/, /etc/ on most machines) and gentoo development (my overlay). Migrated from CVS that was used only for some code repositories. It felt like changing a Trabant for Subaru (substitute your fav. rally car)! Because of the ease-of-use and flexibility of access (ssh, https) I started using it everywhere (See good article My life in subversiion). As far as speed is concerned, it is comparable with CVS. Storage-space-wise, it takes about twice the space because a pristine copy of every file is held locally (this allows diffs, reverts, etc. to be done from the local copy, so the server is not contacted). Branching/merging is logical, svn:externals is very useful to import other repositories in place. Currently lacks owner:group and permisosons storage, but can be implemented as a wrapper. Compared to CVS, it is a clear winner in my opinion. And learnig curve is steep. Just my 2 yen. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
