Re: [gentoo-dev] Last rites for media-video/realone, media-video/realvideo-codecs and old versions of realplayer
Alle 20:16, mercoledì 16 novembre 2005, Mike Frysinger el ga butta: > |On Wed, Nov 16, 2005 at 07:48:56PM +0100, Diego 'Flameeyes' Petten?? wrote: > |> On Wednesday 16 November 2005 19:34, Julien Allanos (dju`) wrote: > |> > So, what are the substitutes? > |> > |> win32codecs and realplayer-10.0.0.6 ? > | > |you asking or telling ? didnt you learn anything in elementary > | school ? -mike noone here speak english at elementary school, I suggest you to follow one course here to learn about it. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [test/suggestion request] MySQL rc scripts
---> ChangeLog extract
19 Nov 2005; Francesco Riosa <[EMAIL PROTECTED]> +files/mysql-slot.conf.d,
+files/mysql-slot.rc6:
These two are born for slotted MySQL, however they work as is on normal
MySQL
installations too. (require my_print_defaults)
Features added or changed
- Not using mysqld_safe anymore
- preparsing of my.cnf file, all options outed at startup
- (possible to) override my.cnf option from conf.d/mysql
- Start multiple server with different config files
- using new svc "--nicelevel" option, nice level may be specified on per
server basis
- stronger error handling
- some new warnings
- slotted mysql management
<--- ChangeLog extract
Since these script have some improvements and since they are compatible
with the current stable, probably I'll bump the stable MySQL version to
use them (no, not tomorrow but not so far in time).
However my knowledge of "sys-apps/baselayout" is not so deep, so could
someone take a look at the two ?
Things that I'm worried about:
- They use a good quantity of bash magic, how much it's compatible with
every gentoo supported system?
- Will be future changes of baselayout be compatible with ?
- how much is it compatible with *past* release of baselayout ?
- and with sys-apps/*layout?
- the rc-script force "start-stop-daemon" to start multiple daemons from
the same script, how is it good/bad, thoughts ?
- the code is readable or an effort should be done to make it simplyer ?
please add your own here
provided you have dev-db/mysql already emerged testing is as easy as:
# mv /etc/init.d/mysql /etc/init.d/mysql~
# /etc/init.d/mysql stop
# cp ${PORTDIR}/dev-db/mysql/files/mysql-slot.conf.d /etc/conf.d/mysql
# cp ${PORTDIR}/dev-db/mysql/files/mysql-slot.rc6 /etc/init.d/mysql
# chmod +x /etc/init.d/mysql
# /etc/init.d/mysql start
TIA,
Francesco Riosa
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] request for comments/review: twisted.eclass
Alle 19:03, mercoledì 23 novembre 2005, Marien Zwart el ga butta:
> |Hi all,
> |
> |Since it's policy and especially since it's the first time I write
> | one of these things I'm submitting an eclass I want to add to the
> | tree for review. It will only be used by the twisted subpackages
> | I'll be maintaining (see bug 80639).
> |
> |Subpackage ebuilds using this only have to set MY_PACKAGE,
> |DESCRIPTION, KEYWORDS and DEPEND. I'd like to get rid of MY_PACKAGE
> | but I haven't figured out how to convert lowercase to uppercase
> | without using tr (MY_PACKAGE will be "Conch" if PN is
> | "twisted-conch"). Also adds the ability to run the unit tests for
> | the package and updates twisted's plugin cache.
bash doable like this:
--- code
word="abc"
newword=""
lcase=( a b c d e f g h i j k l m n o p q r s t u v w x y z )
ucase=( A B C D E F G H I J K L M N O P Q R S T U V W X Y Z )
for (( i=0 ; i<${#word} ; ++i )) ; do
letter=${word:$i:1}
for j in ${!lcase[*]} ; do
letter=${letter/${lcase[${j}]}/${ucase[${j}]}}
done
newword="${newword}${letter}"
done
echo "${newword} == ucase( ${word} )"
--- code
but why not
`tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`
^^^ this one is chosen from MySQL configure script so it should be
portable (or as often I'm missing something ?)
> |
> |Would like to hear about any ideas on how to do that case conversion
> |and any bugs spotted. If there are no objections I'd like to add
> | this to the tree in about two days, so bug 80639 can finally be
> | fixed.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
my apologies for the mess with this release of MySQL 5.0.16 and for the
one will come with the dev-db/mysql-4.1.15-r1 ebuild
Here is the relevant list of bugs opened (and closed) as a consequence
of the new ebuild.
[Bug 113451] mysql-4.1.15 re-keyworded as -* with no note in changelog
as to why
[Bug 113440] typo in mysql-5.0.16-r2 init script
[Bug 113356] /etc/init.d/mysql script fails to start server in
mysql-5.0.16
[Bug 113352] mysql-5.0.16-r1 does not
create /usr/lib{64}/libmysqlclient.so.15 symlink
[Bug 113334] mysql MD5 mysql-extras-20050920.tar.bz2 VERIFY FAILED! (old
ebuild has correct value)
If you installed 5.0.16, the 1st and don't want to re-emerge it, follow
these steps:
(may need to adjust the path accordingly with ARCH and personal
settings)
# emerge --sync
# cp /usr/portage/dev-db/mysql/files/mysql-slot.rc6 /etc/init.d/mysql
# chmod +x /etc/init.d/mysql
# cd /usr/lib{64}
# for i in libmysqlclient.so libmysqlclient_r.so ; do \
for j in "" .15 .15.0 .15.0.0 ; do \
echo ln -s /usr/lib/${i}.15.0.0 ${i}${j} \
; done \
; done
# chown -R mysql:mysql /var/run/mysqld/
Regards,
Francesco R.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
Alle 23:37, giovedì 24 novembre 2005, Robin H. Johnson el ga butta:
> |On Thu, Nov 24, 2005 at 10:51:42PM +0100, Francesco R. wrote:
> |> # for i in libmysqlclient.so libmysqlclient_r.so ; do \
> |> for j in "" .15 .15.0 .15.0.0 ; do \
> |> echo ln -s /usr/lib/${i}.15.0.0 ${i}${j} \
> |> ; done \
> |> ; done
> |
> |ldconfig should have created these symlinks, unless something was
> | wrong with the .so.15.0.0.
did'nt know that, I will try in the ebuild too
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
Problem fixed, going to readd ~amd64 now, sync again in 30 min. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Adding large files to the mirrors?
Il 16/10/2013 11:15, Mike Auty ha scritto: > Hiya, [snip] > So downloading them manually is a pain (the larger tables aren't in a > single zip, they're split amongst 12 files for each table), and the > ebuild to do the downloading is already built. I'll include a > postinst note indicating that the tables are getting stored twice, and > I should even be able to give them an indication of how much space > they're wasting. I'll also provide a URL they can visit if they want > to download manually instead. > > The question then becomes, do I split the ebuild into two (giving us > three ebuilds for what is otherwise a tiny package) just so some SRCs > are mirror-restricted and others aren't? All of that hinges on > whether our servers can handle the extra size... > > Mike 5:) Add a bash script that can download all the files and mention it in postinst. the script will download all the files in current directory and put them in the correct place.
[gentoo-dev] keep a gen 2013 snapshot on mirrors
long story short having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch) greatly simplified the upgrade of an old server on a client. Why not keep a copy on the servers? I mean http://distfiles.gentoo.org/snapshots/ thanks, Francesco Riosa
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Il 14/11/2013 05:38, Johann Schmitz ha scritto: > >> long story short having a portage-20130126.tar.bz2 snapshot > >> (before the EAPI 5 switch) greatly simplified the upgrade of an > >> old server on a client. > > > Updating from old portage versions or > profiles isn't fun but it basically boils down to Sorry for the snip, but all you said is valid only if: you remember to update portage _before_ an emerge --sync _and_ you are able to do it. basically what I did was to remove the old snapshot find an old snapshot but recent enough to have EAPI5 portage. yes some wget of some distfiles was needed but it made the whole thing possible. Alternatively build a completely new system and then switch is a possibility, nothing deadly but as said a simple copy of a january snapshot would have made some paths simpler cheers, Francesco Riosa
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Il 13/11/2013 20:12, Rich Freeman ha scritto: > On Wed, Nov 13, 2013 at 1:58 PM, Francesco R. wrote: >> long story short >> having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch) >> greatly simplified the upgrade of an old server on a client. >> >> Why not keep a copy on the servers? I mean >> http://distfiles.gentoo.org/snapshots/ >> > Going back in time with portage is the easy part - it is in CVS. > > The real problem is all the distfiles themselves, especially things > like out-of-tree patch tarballs hosted by devs. > > Rich Rich, that made me smile, none of my remote machine has cvs since a _very_ long time say 2006. We are speaking of box that have troubles to emerging anything new, plus me and most of the internet barely remember cvs up :) I do highly appreciate the suggestion to keep a @system distfiles snapshot (once a year + portage snapshot would be a bone), but that it's not strictly needed, just a 40MB bzipped files on a public directory and maybe some change to the cron that wipe old files. cheers, Francesco R.
Re: [gentoo-dev] New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
Il 16/12/2013 01:30, Matt Turner ha scritto: > On Sun, Dec 15, 2013 at 4:20 PM, Andreas K. Huettel > wrote: >> Am Montag, 16. Dezember 2013, 00:34:13 schrieb Matt Turner: >>> 3dnow: Use the 3DNow! instruction set >>> 3dnowext: Use the Enhanced 3DNow! instruction set >>> mmx: Use the MMX instruction set >>> mmxext: Use the Extended MMX instruction set (intersection of Enhanced >>> 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) >>> sse: Use the SSE instruction set >>> sse2: Use the SSE2 instruction set >>> sse3: Use the SSE3 instruction set (pni in cpuinfo) >>> ssse3: Use the SSSE3 instruction set >>> sse4_1: Use the SSE 4.1 instruction set >>> avx: Use the AVX instruction set >>> avx2: Use the AVX2 instruction set >> What's the point of these flags? >> (or to be more precise, are they really justified whenever they are used?) >> >> Usually the set of cpu instructions should be controlled by your CFLAGS, and >> I've been actively patching packages (that do not do manually coded assembly) >> to make such flags unnecessary. > Often they're for enabling assembly code that uses these instruction > sets. For pixman, a package that I'm very familiar with, they turn on > code using these instruction sets using intrinsics in C. I believe > they are justified. > > If the package simply uses the flag to add an -m flag to CFLAGS, > then we should definitely remove it. If I recall correctly, I have > only seen one instance of this. > another possible case are packages that do run-time checking of usable instruction set. The use flag could restrict the code to be compiled and installed from the ebuild. Probably never used like this tough
[gentoo-dev] mount portage from squashfs
Proposal, create snapshots of portage as squashfs iso, to be used in place of /usr/portage directory. prior art: see #1 Already working here: one central server which keep the portage full tree and that after a sync create "portage.sqsh" a squashfs 4.0 iso. Advantages are mainly: - cleaner root directory (ext4: du -sh /usr/portage ~= 600M | find /g/portage | wc -l ~= 13) - faster `emerge --sync` with fast connections - faster `emerge -uDpvN world` - less cpu/disk load on the server (if not serving from memory) Disadvantages - need to mount portage, or to use autofs - need kernel >= 2.6.30 - bigger rsync transfer size (?= 2x) #2 - bigger initial transfer size, lzma snapshot currently weight 30.8M, portage.sqsh 45M How it's done here: Currently on the dispatcher the following run after every emerge --sync: mksquashfs /usr/portage /srv/portage.sqsh \ -noappend -no-exports -no-recovery -force-uid 250 -force-gid 250 The clients run from cron the following: umount /g/portage 2>/dev/null \ ; cp /srv/server/portage.sqsh /var/tmp/portage.sqsh \ && mount /usr/portage /etc/fstab: /srv/server/portage.sqsh /usr/portage squashfs loop,ro,noauto 1 1 some real data: stats for a portage sync, one day Number of files: 136429 Number of files transferred: 326 Total file size: 180345216 bytes Total transferred file size: 1976658 bytes Literal data: 1976658 bytes Matched data: 0 bytes File list size: 3377038 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 47533 Total bytes received: 4120255 sent 47533 bytes received 4120255 bytes 124411.58 bytes/sec total size is 180345216 speedup is 43.27 stats for a portage.sqsh sync, one day Number of files: 1 Number of files transferred: 1 Total file size: 46985216 bytes Total transferred file size: 46985216 bytes Literal data: 8430976 bytes Matched data: 38554240 bytes File list size: 27 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 48096 Total bytes received: 8454837 sent 48096 bytes received 8454837 bytes 5668622.00 bytes/sec total size is 46985216 speedup is 5.53 #1 http://forums.gentoo.org/viewtopic-p-2218914.html http://www.mail-archive.com/gentoo-...@gentoo.org/msg05240.html #2 May be mitigated by mksquashfs '--sort' option, to be tested - francesco (vivo)
Re: [gentoo-dev] mount portage from squashfs
On Wed, Aug 12, 2009 at 10:51 PM, Robin H. Johnson wrote: > On Wed, Aug 12, 2009 at 05:17:55PM +0200, Francesco R wrote: > > Proposal, create snapshots of portage as squashfs iso, to be used in > > place of /usr/portage directory. > To all of these suggestions, I'd like to point out that if you're > willing to pay the same cost in administration (maintaining a separate > filesystem for /usr/portage), then you can have EVERYTHING in the > advantages list, and none of the things in the disadvantages list by > simply using a small reiserfs space for /usr/portage, with tail-packing > enabled. well squashfs has a pair of advantages over reiserfs, duplicate file detection, compression and a bright future. > > > For the rsync.g.o main rotation servers, we actually do that, just > RAM-backed to serve files as fast as possible without hitting disk. > only possibility to cope with the load they have I think > > When you removed bandwidth limitations and disk limitations on the > client side, I believe the record time for a emerge --sync that was 24 > hours out of date was somewhere around 23 seconds. 23 seconds are ... a lot without bandwidth and disk limitation, disk time for 50 MB is 1 sec (or even much less), and it transfer the whole iso in that time > > If you really wanted to get the rsync transfer size down, see what you > can do about the 'file list size' section, which is eating up a lot of > the download gains with the classical rsync:// sync. > IMHKnowledge the only way to do this is to have one index file (or files) the file should contain a triple ctime, status and file name (ordered by ctime possibly descending), and provide a cheap way to retrieve the list of files changed in a certain amount of time, status would be needed mainly for deleted files, but it can be modified or added too. Portage already has timestamp in /metadata so that skew of the client clock are not a problem, skew on the server would be. As a side advantage this could be served by an http server, still having rsync as an option. Currently rsync already use the option --whole-file and does only time/size check, if those differ, it downloat the full (little) file. Right ? This would be interesting too, but what happen if the timestamp in the client is too old or absent? fallback to rsync? How much time or how much size would the index file be allowed to grow? P.S. as a http client curl would be more useful than wget because it permit to download more file in one session
Re: [gentoo-dev] Re: Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 1:31 AM, Ryan Hill wrote: > On Sun, 20 Sep 2009 08:55:00 +1200 > Alistair Bush wrote: > > > > Stabilization of Python 3.1.* will be requested at the beginning of > > > november. There was a suggestion to create a news item which would > inform > > > users that temporarily they shouldn't switch to Python 3 as their main > > > interpreter. Python ebuilds don't automatically activate Python 3, so > I'm > > > not sure if the news item is required. What is your opinion about it? > > > > > > > Stablise. > > > > And to pacify all the cry babies out there could we update portage tools > to > > call /usr/bin/python2.6 directly? (yes I realise this will break, but at > least > > it is a suggestion) Or how about we (remove python3.1 from the > menu)/(stick > > a big fat warning message)/(do something else) on eselect-python. Or > create a > > "system-python" link that all gentoo core apps use instead of > /usr/bin/python > > (longer term solution?). [rant]Hell maybe we could even start using > those > > slot dep thingy me bobbies to depend only a slot. So ppl don't have > python3.1 > > unless something depends on it. Does portage have support for slots in > world? > > [/rant] > > Or we could, say, leave it ~arch. > > Why do you need python-3 in stable? > > Someone here want people install paludis? because when I've switched to python 3.0 just out of curiosity, it broke totally that python written package manager who is portage. So another package manager was needed to re-install a sane portage. Still, do you really want to have it in tree as stable? Really? Than at least please update eselect python in such a way it could not in any case be used to choose a python version >= 3
Re: [gentoo-dev] Re: Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 2:42 AM, Alistair Bush wrote: > > > > Someone here want people install paludis? because when I've switched to > > python 3.0 just out of curiosity, it broke totally that python written > > package manager who is portage. > > So another package manager was needed to re-install a sane portage. > > No it wasn't. [1] You just didn't know that ( which is completely > understandable ). Just as you must not have understood the implications of > emerge -C python:2.6. I don't want to be mean but would you like to > enlighten > us as to how you managed to unemerge python:2.6 while using python3 when > portage didn't work with python3. > > [1] > http://tinderbox.dev.gentoo.org/default-linux/amd64/dev-lang/python-2.6.2- > r1.tbz2 > > I did not unmerge > > > Still, do you really want to have it in tree as stable? Really? > > Yes really. > > what said in the previous message which you snipped, eselect python should forget about >=python-3 is still valid IMHO
Re: [gentoo-dev] About libpng-1.4 handling
2010/5/11 Graham Murray > George Prowse writes: > > > I have run revdep-rebuild about 30 times and I still can't fix > > it. revdep-rebuild does not fix it and libpng needs to have some > > serious action before it goes stable because I booted into, basically > > a completely broken machine because I had to stop a large upgrade on > > the previous emerge (~300 packages) in the middle. > > Are the failures during a gtk-doc scan? If so then try unmerging the > affected package and then manually re-emerging it. > > For me not, possibly it's a problem with la files, steps done by me follow: revdep-rebuild -- --keep-going lafilefixer --justfixit # this does not work `revdep-rebuild -- --keep-going` export PKGLIST="$(qfile --slots --quiet --nocolor $(grep -l png12 /usr/lib64/*.la))" # PKGLIST="gnome-base/libgnomecanvas:0 gnome-base/libbonoboui:0 gnome-base/libgnomeui:0 gnome-base/gnome-keyring:0 # gnome-base/libglade:2.0 dev-cpp/gtkmm:2.4 dev-cpp/gtkmm:2.4 gnome-extra/evolution-data-server:0" sudo rm $(grep -l png12 /usr/lib64/*.la) gnome-extra/evolution-data-server:0" sudo emerge -1av $PKGLIST revdep-rebuild -- --keep-going # should do
Re: [gentoo-dev] showing file diffs as root
why not make a temporary copy of the files with appropriate permission,
send a message the application the user originally opened to diff the files,
then apply the user modified file and cleanup the $tmpdir?
This would leave the user the possibility to choose whatever application she
want to do the merge, which is a big plus.
2010/5/30 Christopher Harvey
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello gentoo-dev,
>
> I'm working on an app for GSoC that needs to show a diff of two files
> to the user. Right now I've just been calling meld from the python
> os.system call. I tried running my application as root to show diffs
> of system files that belong to root. I got this error:
>
> Traceback (most recent call last):
> File "/usr/bin/meld", line 90, in
>meldapp.main()
> File "/usr/lib/meld/meldapp.py", line 982, in main
>app = MeldApp()
> File "/usr/lib/meld/meldapp.py", line 562, in __init__
>self.prefs = MeldPreferences()
> File "/usr/lib/meld/meldapp.py", line 435, in __init__
>super(MeldPreferences, self).__init__("/apps/meld", self.defaults)
> File "/usr/lib/meld/prefs.py", line 92, in __init__
>self._gconf.add_dir(rootkey, gconf.CLIENT_PRELOAD_NONE)
> glib.GError: Failed to contact configuration server; some possible
> causes are that you need to enable TCP/IP networking for ORBit, or you
> have stale NFS locks due to a system crash. See
> http://projects.gnome.org/gconf/ for information. (Details - 1:
> Failed to get connection to session: Did not receive a reply. Possible
> causes include: the remote application did not send a reply, the
> message bus security policy blocked the reply, the reply timeout
> expired, or the network connection was broken.)
>
> I haven't looked into why this is happening very much because calling
> os.system("meld file1 file2 &") in python is putting up so many red
> flags in my head it's not funny. If anybody could tell me the proper
> gentoo/linux/python way to present a root level diff to a user running
> a program through su or sudo I'd really appreciate the help.
>
> thanks,
> Chris
>
> - --
> My GnuPGP key at:
> www.basementcode.com/public_key.txt
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJMAn1RAAoJEDqfZIFeqFH7brQH/RqeUmCHuopa+SufkzNNT4Ys
> 7IJArQCik3vBLJLpeTM3gf3NL3KMWjyzlxxQ8L74KAhItPuA3cVUQKQrSnOCBiDa
> y6yfDttBbOptOtcUYn7WkXQDm+BYEdpviMfjtym5ZF2nlGOMzZMxknP4ywXnhLZN
> q2169haoG0p1g0D11q2H9B4Vk++PUil7VLgzOfAOcLQ9YpFDkXIdxy5FRaRkx8K4
> lcPfmzFha8OkdBpsXPJdhtY5pmzOEf+ziprDlyD7eCkE1xAkRNhjsNtEz9CTXeLh
> l46/tUCZTx+aX9ABW0m13Ache8jGN36+TvsRzRKfzqaMJ0z/wEOeESooPFYHnl0=
> =FxxJ
> -END PGP SIGNATURE-
>
>
>
Re: [gentoo-dev] New eclass: autotools-utils.eclass
2010/7/19 Ciaran McCreesh
> On Mon, 19 Jul 2010 18:23:36 +0200
> Maciej Mrozowski wrote:
> > status quo should be challenged occasionally.
> >
> > Fixed autotools-utils.eclass, kde4-functions.eclass, virtuoso.eclass
> > case ${EAPI:-0} in
> > 2|3|4) ;;
> > - *)
> > DEPEND="EAPI-TOO-OLD" ;;
> > + *) die "EAPI=${EAPI} is not
> > supported" ;;
> > esac
>
>
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-functions.eclass?r1=1.18&r2=1.19&;
>
> This was changed for a reason. Did you find out what that reason was
> before reverting it?
>
the comment for that commit is:
"Update kde4 eclasses from kde-testing. Mostly minor sinc. Introduce support
for stable koffice2"
So, since the reason it's not mentioned, the reason is not existent.
>
> --
> Ciaran McCreesh
>
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
2010/8/10 Brian Harring
> On Mon, Aug 09, 2010 at 07:05:11PM -0400, Mike Frysinger wrote:
> > On Mon, Aug 9, 2010 at 7:03 PM, Markos Chandras wrote:
> > > On Sat, Aug 07, 2010 at 10:16:24PM -0400, Mike Frysinger wrote:
> > >> obviously you only mean linux x86/amd64 dev profiles. i dont have a
> strong
> > >> opinion on that small subset in either direction.
> > >
> > > So do you agree to make this linker option default to linux x86/amd64
> dev/
> > > profiles?
> >
> > add them or dont add them, "i dont have a [...] opinion [...] in
> > either direction". if put to a vote, i'd abstain.
>
> Possibly a stupid question, but any reason we've not looked at
> injecting something that has lower actual affect but can still be used
> for a canary? I'm thinking of --build-id specifically...
>
> ~brian
>
I don't know how --hash-style=gnu is used to check for LDFLAGS, so this may
be OT.
On my personal and _breakable_ desktop I do use
LDFLAGS="${LDFLAGS} -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-Wl,--sort-common -Wl,--build-id"
in make.conf.
Would this two liners tell me which package who install binaries in /usr/bin
does not respect ldflags?
# for i in /usr/bin/* ; do eu-unstrip -n -e $i ; done &> build-id.txt
# qfile $(grep '0x[0-9]*+0x[0-9]* - ' build-id.txt | awk '{ print $3 }')
On a side note, I've noticed that build-id change at every re-compilation of
the package, even if nothing changed in the system, since it's supposed to
be a "160-bit SHA1 hash on the normative parts of the output contents"
should it be the same if the package is compiled on the same system with no
changes?
Output of the two liners for this system:
sys-apps/turbotail (/usr/bin/turbotail)
app-arch/rzip (/usr/bin/runzip)
app-arch/rzip (/usr/bin/rzip)
dev-lang/go (/usr/bin/6a)
dev-lang/go (/usr/bin/6cov)
dev-lang/go (/usr/bin/6l)
dev-lang/go (/usr/bin/6nm)
dev-lang/xharbour (/usr/bin/pprun)
dev-lang/xharbour (/usr/bin/hbmake)
dev-lang/xharbour (/usr/bin/hbdict)
dev-lang/xharbour (/usr/bin/xbscript)
dev-lang/perl (/usr/bin/perl)
dev-lang/perl (/usr/bin/perl5.12.1)
dev-lang/R (/usr/bin/Rscript)
x11-misc/xcb (/usr/bin/xcb)
dev-libs/dietlibc (/usr/bin/dnsd)
dev-libs/dietlibc (/usr/bin/elftrunc)
app-text/o3read (/usr/bin/utf8tolatin1)
app-accessibility/festival (/usr/bin/audsp)
app-accessibility/espeak (/usr/bin/espeak)
sys-devel/gcc (/usr/bin/x86_64-pc-linux-gnu-gcjh-4.4.4)
sys-devel/gcc (/usr/bin/gcjh-4.4.4)
sys-devel/llvm-gcc (/usr/bin/llvm-gcov)
sys-devel/qconf (/usr/bin/qconf)
www-plugins/lightspark (/usr/bin/lightspark)
Re: [gentoo-dev] Re: use_echo() as a universal '?:' operator-like function
2010/9/11 "Paweł Hajdan, Jr."
> On 9/11/10 11:03 AM, Jonathan Callen wrote:
> > Just as a proof-of-concept, here's one implementation of such a
> > function, allowing for an arbitrary number of arguments:
> >
> > use_echo() {
> > while [[ $# -gt 1 ]]; do
> > if use "$1"; then
> > echo "$2"
> > return
> > fi
> > shift 2
> > done
> > [[ $# -eq 1 ]] && echo "$1"
> > }
>
> Looks good to me. If it doesn't get included in any eclass, I will just
> paste it to the chromium ebuilds. :)
>
> Paweł
>
> I don't count but sometimes I do still read ebuilds, the function proposed
look a bit^W unreadable to me,
may I suggest to aggregate use and echo, separating them with a comma ",".
The first element with an empty "use" always echo and return.
See implementation and example below
use_case() {
local u
local c
while [[ $# -gt 0 ]]
do
u=${1%%,*}
c=${1#*,}
if [[ ${u} == "" ]] || use $u
then
echo ${c}
break
fi
shift
done
}
echo $(use_case useA,echoA useB,echoB ,echoC)
Re: [gentoo-dev] lcars gets his commit bit
Grant Goodyear wrote: >Dear all, > After quite some time "merely" being an infra dev, lcars has >finally taken the leap and gained commit access to the tree. He's >going to be officially taking over sendmail and supporting other >packages that infra uses, so please feel free to start shoveling bugs >his way! *Grin* > >-g2boojum- > > newer than you but every occasion is good for a welcome ;-) conspiracy ? hum good idea lakes of wine and beer ? still better -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] DBD-mysql select failures with MySQL 4.1
Anthony Gorecki wrote: >On Sunday, June 26, 2005 9:28 pm, Zac Medico wrote: > > >>Have you checked the DBI error status? See the parts about $DBI::err, >>$DBI::errstr, and RaiseError here: >> >> > >In all cases, DBI::err() returns undefined, indicating no error. It's quite >perplexing. > > > > Maybe we are a bit off topic on this list ... but here we are. Going to give some hints where to search the source of the error, nothing else, sorry. a) take a look at mysql logs. b) re-emerge =DBD-mysql-2.9007 c) try something like "log = /tmp/mysqld.sql" in "[mysqld_safe]" section of my.cnf then restart mysql. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
Paul de Vrieze wrote:
>On Thursday 30 June 2005 23:11, Dan Armak wrote:
>
>
>>Instead of 'exit 1', qt_min_version should use die. I use that in
>>deprange and it does work inside $DEPEND.
>>
>>
>
>Wouldn't this be a good time to implement actual dependency ranges in
>portage. Btw. I normally use the following hack that portage might
>actually be made to understand:
>
>DEPEND="
>Paul
>
>
>
Hum ranges ? This remember me something ... ahh yes I've written a pair
of function to apply patches only for ranges of versions, pure bash
inheriting versionator.eclass .
Here they are:
# this function use "version_compare" to check if a version number
# fall inside a range.
# the range may include or not the extremes, a square bracket mean
# that the extreme is included, a round one mean that the extreme
# fall outside the range.
# examples:
# with $PVR=3 these ones evaluates as _true_:
# [2,4] [3,4] [2,3] [,4] [2,]
# (2,4)
# (,4) (2,) [3,3] [3,4) (2,3]
# with $PVR=3 these ones evaluates as _false_:
# [8,9]
# (3,4) (2,3) (8,9)
# (3,3)
check_version_range() {
local range_s="${1}"
local have_s="${2:-${PVR}}"
[[ -z "$range_s" ]] && return 1
local bound kind vc
bound=${range_s%%,*}
bound=${bound:1}
bound=${bound:-0}
local kind=${range_s:0:1}
case "$kind" in
'[') kind=2;;
'(') kind=1;;
*) die "check_version_range left kind error: \"${range_s}\""
return 50;;
esac
version_compare "${bound}" "${have_s}"
[[ $? -gt $kind ]] && return 2
local bound=${range_s##*,}
bound=${bound:0:$(( ${#bound} -1 ))}
bound=${bound:-9}
local kind=${range_s:$(( ${#range_s} -1 ))}
case "$kind" in
']') kind=2;;
')') kind=3;;
*) die "check_version_range right kind error: \"${range_s}\""
return 50;;
esac
#'
version_compare "${bound}" "${have_s}"
vt=$?
[[ $vt -lt $kind ]] && return 3
return 0
}
# Find all the applicable patch files in a directory and move them in
# EPATCH_SOURCE (yes EPATCH_SOURCE here is a /destination/)
# two optional arguments are accepted:
# 1) directory where find the candidate patches (default to $FILESDIR)
# 2) version on which check applicable patches (default to $PVR)
# the file examined must have one or more line starting with the string
# "###MY_VER_RANGE" and followed from one or two version numbers (VN).
# For every of the so formatted lines the function will check if our
# version is greatest or equal to the first VN and less than the second
# VN (defaulted to infinite if empty)
# example:
###MY_VER_RANGE 4.0 4.0.16
###MY_VER_RANGE 4.1 4.1.4
###MY_VER_RANGE 5.0
# if a patch contains these three lines then:
# all version >= 4.0 but < 4.0.16,
# all version >= 4.1 but < 4.0.16,
# all version >= 5.0 will be affected by this patch
#
# bug uses version_compare declared experimental
# <[EMAIL PROTECTED]> (2005-05-18)
copy_applicable_patches() {
local filesdir="${1:-${FILESDIR}}"
local have_s="${2:-${PVR}}"
[[ -d "${EPATCH_SOURCE}" ]] || die "\$EPATCH_SOURCE must be a directory"
[[ -d "${filesdir}" ]] || die 'sourcedir must be a directory'
local filecandidates=""
filecandidates="$( ls ${filesdir}/*.${EPATCH_SUFFIX} 2>/dev/null )"
if [[ -z $filecandidates ]] ; then
einfo "No candidate patches found (lucky version?)"
return 0
fi
local ver_ranges use_flags
local has_ver=1 has_use=1
local apply=1
local filelist=""
for x in ${filecandidates} ; do
# Gater data
ver_ranges=$( head -n50 "${x}" | sed '/^###MY_VER_RANGE/'\!'d; s///;q' )
use_flags=$( head -n50 "${x}" | sed '/^###MY_USE_FLAG/'\!'d; s///;q' )
if [[ -n "${ver_ranges}" || -n "${use_flags}" ]] ; then
if [[ -z "${ver_ranges}" ]] ; then
has_ver=0
else
has_ver=1
for y in ${ver_ranges} ; do
if check_version_range "${y}" "${have_s}" ; then
has_ver=0
continue
fi
done
fi
if [[ -z "${use_flags}" ]] ; then
has_use=0
else
has_use=1
for y in ${use_flags} ; do
if [[ "${y:0:1}" == "-" ]] ; then
if ! useq "${y:1}" ; then
has_use=0
continue
fi
else
if useq "${y}" ; then
has_use=0
continue
fi
fi
done
fi
if [[ $has_ver -eq 0 && $has_use -eq 0 ]] ; then
filelist="${filelist} ${x}"
einfo "adding $(basename ${x}) ${ver_ranges} ${use_flags}"
else
einfo "skipping $(basename ${x}) ${ver_ranges} ${use_flags}"
fi
fi
done
filelist="${filelist:1}"
[[ -n "$filelist" ]] && cp $filelist "${EPATCH_SOURCE}"
}
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
Francesco R wrote: [snip] s/ ># example: >###MY_VER_RANGE 4.0 4.0.16 >###MY_VER_RANGE 4.1 4.1.4 >###MY_VER_RANGE 5.0 ># if a patch contains these three lines then: ># all version >= 4.0 but < 4.0.16, ># all version >= 4.1 but < 4.0.16, ># all version >= 5.0 will be affected by this patch > > / example: ###MY_VER_RANGE [4.0,4.0.16) [4.1,4.1.4) [5.0,] # if a patch contains the previous line then: # all version >= 4.0 but < 4.0.16, # all version >= 4.1 but < 4.0.16, # all version >= 5.0 will be affected by this patch / [snip] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New MySQL doc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris White wrote: >Here's the initial devspace draft of the new MySQL draft I've been working on: > >http://dev.gentoo.org/~chriswhite/mysql.html > >Comments, etc are welcome. > >Chris White one reminder: "Code listing 1.3: MySQL configuration" probably will change for mysql-4.1 and better (when unmasked) and having the possibility to scroll the screen, "Code listing 4.19: Finding our guest user in the user table" mysql> SELECT * FROM user WHERE User = 'guest'; may become "Code listing 4.19: Finding our guest user in the user table" mysql> SELECT * FROM user WHERE User = 'guest' \G to make it more readable. See J.M. email too the default my.cnf has the following line bind-address= 127.0.0.1 that actually restrict the server access to local machine only. You may want to signal this in the "Granting Privleges with GRANT" section. Last but not last, thankyou -> nice intro document Francesco R. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0tyw1wNBTLVPMuARAroiAJsHl8+M1cOD0Yq2Zlti8kVaMxDnIQCdFIke NS4BndQanBMCysEuApHAwG0= =dy9e -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] init script guidelines
Eric Brown wrote: > Services that use Gentoo init scripts often report a status of [started] or > > [OK] even though they fail to start. The most recent bug like this that I've > > > found is with snort. If you have a bad rule, snort will initialize, the > > rc-scripts will give it an [OK] status, and then it will die once it parses > the > > rules. > > > > The real problem is not that the daemons don't return errors, but that our > init > > scripts do not make reasonable attempts to verify service startup. If a > Gentoo > > init script claims that a service started, it should make an effort to check > > > that the processes are actually running shortly after the script is run, even > if > > start-stop-daemon says the parent process initialized. Relying on the return > > > value of start-stop-daemon is simply insufficient for some services. > > > > I am aware that there are services that can monitor the status of other > services > > (app-admin/mon?) but I think this issue is a little different. If an ebuild > > > developer is aware of an error condition can commonly occur shortly after a > > daemon initializes, why not attempt to catch those errors? Most of them > could > > probably be caught by simply checking to see if the process is still running > > > shortly after the script is run. > > > > I propose increasing developer awareness of this problem, perhaps through > some > > formal guidelines for ebuild developers. At the very least, I would like to > see > > these bugs being acknowledged in bugs.gentoo.org instead of getting the same > old > > upstream/it's not our fault response. We are responsible for our init > scripts, > > and they are important to our users. > > > > I have 2 ideas for the actual implementation: > > > > 1) Some kind of check() function in the init.d script, or a generic check() > function > > that just checks with ps | grep. This might typically be called after having > the > > init script sleep for a certain amount of time. > > > > 2) Some kind of special init script that checks registered daemons after all > services > > have started. (i.e. it depends on all daemons, or they are put into it’s > config file). > > With this scheme we could avoid excessive sleeping during startup (to keep it > fast), > > And perhaps even keep using service specific check() functions > > > > Does anyone else think this idea is worth looking into? > http://bugs.gentoo.org/show_bug.cgi?id=90471 We managed this checking for the socket mysql always create on *nix . But whit a timeout of five seconds if there is no error message nor socket in that time the script assume the server started. I'm the first to say that this need to be improved but it's a start. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] init script guidelines
Roy Marples wrote: >On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote: > > > > >>The real problem is not that the daemons don't return errors, but that our >>init >>scripts do not make reasonable attempts to verify service startup. If a >>Gentoo >>init script claims that a service started, it should make an effort to check >>that the processes are actually running shortly after the script is run, even >>if >>start-stop-daemon says the parent process initialized. Relying on the return >>value of start-stop-daemon is simply insufficient for some services. >> >> > >I agree. > >Infact, rc-services.sh (/lib/rcscripts/sh) has been totally re-written >for the baselayout-1.12.x branch. It now intercepts calls to >start-stop-daemon and checks if the daemon is still active after a >default time of 0.1 (adjustable) seconds. If not, the we assume the >daemon failed. This solves many existing bugs :) > >Also, we kill any rogue processes and other such checks when a stop call >to start-stop-daemon is made - which is handy for when asterisk fails to >start and leaves mpg123 processes lying around :) > >Check it out when baselayout-1.12.0pre1 hits portage! > >Caveat: - some init scripts abuse start-stop-daemon. One example are all >courier scripts which pass the env program as a daemon. This is easily >worked around, but we fail badly if env then calls a shell script which >in turn launches a daemon. Of all the server stuff I run, only couier >has this issue - but there may be other programs too. Basically >start-stop-daemon should only call daemons! > >http://bugs.gentoo.org/show_bug.cgi?id=98745 > >Roy > > what about to define two additional functions check_startup() and check_shutdown() intended to be filled from package mantainer. The rc scripts can call these one to check if a service is started/stopped or not. If not it wait and retry untill a timeout is reached. This open the road also to centralized policies of waits between check like : (1,1,1,1,1,1) (1,2,3,4,5,6) (1,2,4,8,16,32) and other nice stuff. Francesco -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] MySQL ebuild removal selection
These ebuilds are scheduled for removal in the next 24 hours: - mysql-3.23.58 mysql-4.0.22-r1 mysql-4.0.23 mysql-4.0.23-r1 mysql-4.0.23-r2 mysql-4.0.24-r1 mysql-4.0.24-r2 mysql-4.0.25-r1 mysql-4.1.8 mysql-4.1.8-r1 These will survive: --- mysql-3.23.58-r1 mysql-4.0.22 mysql-4.0.22-r2 mysql-4.0.24 mysql-4.0.25-r2 mysql-4.1.13-r1 (masked) mysql-5.0.9_beta-r2 (masked) mysql-5.0.10_beta (masked) If you have some particular reason for keeping any of them drop me a note on/off list. Best regards Francesco R. -- . These pages are best viewed by coming to my house and looking at . . my monitor. [S. Lucas Bergman (on his website)]. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL ebuild removal selection
Jason Wever wrote: >On Thu, 18 Aug 2005 03:59:42 +0200 >Francesco R <[EMAIL PROTECTED]> wrote: > > > >>If you have some particular reason for keeping any of them drop me >>a note on/off list. >> >> > >I'm sure you've done your due diligence, but please double check that >you are not removing the latest stable or testing keywords for any >architectures when you do this cleanup. > > was looking for a "better keyword grep" yesterday . The expanded version of the previous post is: breakall mysql $ eshowkw [snip and resort] 3.23.58 | ~ ~ + ~ ~ 4.0.23-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.0.23| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.0.23-r2 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.0.24-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.0.24-r2 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.0.25-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.1.8 | ~ ~ 4.1.8-r1 | ~ ~ ~ ~ ~ 3.23.58-r1| + + + + + 4.0.22| + + + + + + + + + + + 4.0.22-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 4.0.22-r2 | + + + + + + + + + + + 4.0.24| + + + + + + + + + + + 4.0.25-r2 | ~ + ~ ~ ~ ~ ~ ~ ~ ~ + 4.1.13-r1 | ~ ~ ~ ~ ~ ~ 5.0.9_beta-r2 | ~ ~ ~ ~ ~ ~ 5.0.10_beta | ~ ~ ~ ~ ~ ~ If it's correct thank ciaranm for this script, if it's not blame him ;-) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Luca Barbato wrote: >Christian Parpart wrote: > > > >>Using the "minimal" useflag for this - IMHO - is a misuse of the idea of >>"minimal" semantically - as I do understand minimal in a way like "don't >>overbloat me with patches and other feature additions"-alike. >> >> > >minimal is about keeping the package at the minimum, that means strip >every feature that won't prevent it to run. > > > Maybe it's foggy for mysql usage, better suggestions (clientonly, libonly) ? >>Do we have a general accepted gentoo policy for this? >> >> > >Usually the policy is "If the upstream has planned that we'll follow, >otherwise no" > > [IMHO] Upstream distribuite binaryes of only libraryes, in this direction it's supported. Build them from the source only libs is not deeply supported, see below. [/IMHO] > > >>And... any thoughts on this subject? >> >> >> > >I'd prefer to have those features enabled by useflag, sometimes (eg. >qemu) I can split functionality in separated ebuild and use a metaebuild >to let users merge both w/out major overhead. > >In your case a useflag IMHO would be enough since the situation require >a particular setup and in the case the constraint changes won't be a >problem rebuild a full mysql. > >The question is, does the mysql configure script have a "clientonly" >and/or a "libraryonly" option? > > there is an option for configure "--without-server" , but actually the server is still build. Take a look at >= dev-db/mysql-4.0.24-r2 for how "minimal" use flag is used, basically it force some flag off and remove some files from the install. >There were a client and server useflag discussion before. > >lu > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Lance Albertson wrote: >Mike Frysinger wrote: > > >>On Thursday 18 August 2005 10:28 am, Christian Parpart wrote: >> >> >> >>>Do we have a general accepted gentoo policy for this? >>> >>> >>general policy is to not split packages (and i agree with this ...) >> >> > >bind and bind-tools is split ;) Why is it so bad to split packages? (I'm >just curious) Seems a bit odd that we can't have a library only, client >only, etc package like the other distros. Of course, I understand that >we could use useflags for that, but is that really the best solution for > this particular issue? > >Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;) > > > vimdiff bind-tools/bind-tools-9.2.5.ebuild bind/bind-9.2.5-r5.ebuild In the eventuality of mysql being splitted the landscape is totally different. The code to duplicate is a 40% of the ebuild speaking of volume, in maintenance the percentage is bigger. I'm a (little) sysadmin too, redundancy is good speaking of servers but maintain a cluster or simply to synced servers is more difficult (and error prone) that maintain only one, right ? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] last rites for "dev-db/mysqltool"
It's dead upstream and the ebuild need to be rewritten from scratch. Unless there is some volenterous it will be sadly removed 2005-08-29 See bugs 77539,93725 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Fixing the TERM mess
Ciaran McCreesh wrote:
>On Sun, 21 Aug 2005 18:43:54 -0400 Dan Meltzer
><[EMAIL PROTECTED]> wrote:
>| putty pretends to be an xterm and dies at xtermcontrol --get-bg... I
>| can test other things if you need.. just give me some idea :)
>
>Thanks. The other useful one is to see whether it does 256 colours
>properly like real xterm does. The following bash script, when run with
>'256' as its argument, should look the same as it does when run under
>a real xterm.
>
>
>#!/usr/bin/env bash
># vim: set sw=4 sts=4 et :
>
>[[ -z "${1}" ]] && cat
>count should usually be either 88 (rxvt-based terminals) or 256
>(xterm-based terminals).
>END
>
>echo -n " 0: "
>for (( a = 0 ; a < ${1} ; a++ )) ; do
>echo -n -e "\e[38;5;${a#0}m#\e[48;5;${a#0}mX\e[0;0m "
>[[ -z "${a##*9}" ]] && echo -n -e "\n\e[0;0m$(printf '%3d' ${a} ): "
>done
>echo -e "\e[0;0m" ; echo
>
>
>
Probably putty use "xterm" as default instead to be usable on most
configurations.
I've found that putty is the best (free on windows) "linux" term
emulator around.
As a consequence all my win boxes use it with the following settings:
Terminal -> Keyboard -> The Functions keys and keypad -> Linux
Connection -> Data -> Terminal-type string -> "linux"
with this settings the "xtermcontrol --get-bg" output this:
xtermcontrol: TERM=linux: probably not xterm variant
The script you posted here has good results for $1 = 256 for putty
version 0.58 .
For version 0.56 of putty the for loop need to start from "13" instead
of "0" or it screwed up things at the extend that a "reset" need to be
run. Additionally the color support is limited to 16 .
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
Chris Gianelloni wrote: >On Tue, 2005-08-30 at 01:03 -0500, Brian Harring wrote: > > >>On Sat, Aug 27, 2005 at 03:42:25AM -0500, Brian Harring wrote: >> >> >>>Hola all. >>> >>>Straight to the point, I'm proposing that the following files- >>>arch.list >>>categories >>>use.desc >>>use.local.desc >>>package.mask >>>updates >>> >>> >>Addition to this list: thirdpartymirrors . >> >> > >Question about thirdpartymirrors (this is for everyone, not just >Brian)... > >What is the preferred method for listing mirrors, just listing the site >name, or listing the site name plus path to the particular item? > > example from mysql mirrors: ftp://mirror.mcs.anl.gov/pub/mysql http://mirror.sit.wisc.edu/mysql http://mysql.orst.edu The mirror item should be the minimum common denominator between the mirrors. In this specific case because the mirror is usable also for other products of mysql. >The reason that I ask is the 3dgamers mirror rotation could have the >paths added to it, which would actually shorten a lot of SRC_URI's in >quite a few games ebuilds. > > > there are always excepitions ;-) You are speaking of paths that will *never* change right ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Is this also a good time to note that the amd64 and x86 could > *easily* be covered under the same keyword? We cover a large > variety of mips machines/userlands under one keyword, with > differences much more significant then that between x86 and amd64. Sorry I disagree with this, differences exists and sometimes are a problem. Some package and library don't compile cleanly under amd64 arch. On few but existant cases it's good to have two different archs. Not even going near the analizing the differences in the profiles. rgs, Francesco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFHTN1wNBTLVPMuARAkCpAJ4gkQQ9Ntp9j5dsldyFLLt1lj/iTgCfahlF avwo9tHBaW1LTWWPeLPDFO4= =yYUZ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Stephen P. Becker wrote:
>>> Is this also a good time to note that the amd64 and x86 could
>>> *easily* be covered under the same keyword? We cover a large
>>> variety of mips machines/userlands under one keyword, with
>>> differences much more significant then that between x86 and amd64.
>>
>>
>>
>> Sorry I disagree with this, differences exists and sometimes are a
>> problem. Some package and library don't compile cleanly under amd64
>> arch.
>> On few but existant cases it's good to have two different archs. Not
>> even going near the analizing the differences in the profiles.
>
>
> So these things won't compile in a x86 chroot on a amd64 box even?
Never said this, I've a dual opteron running informix that can *only*
run under a x86 environment.
this is the profile for the main environment:
make.profile -> ../usr/portage/profiles/default-linux/amd64/2005.0
and this one for the chroot:
/chroot/ifx/etc/make.profile ->
../usr/portage/profiles/default-linux/x86/2004.0/
They are covered from completely different keywords and profiles.
> I find that really hard to believe. Besides, close collaboration
> between folks with x86 and folks with amd64 installs can make it easy
> to ensure the same versions work on both arches (if you really want to
> call them separate arches...) Your profile argument is silly too,
> since both arches could *easily* be merged into sub-profiles in our
> cascading system.
Maybe I've not understud the first sentence, what are you saying is that
amd64 teams can do x86 testing, we agree on this (all not kernel related).
profiles: /usr/portage/profiles/default-linux{/amd64/2005.1/ ,
x86/2005.1/} looks rather different to me (not analized them deeply)
> Besides, we have the same sorts of problems on mips, except they are
> magnified since we have a possibility of 3 different userland ABIs, on
> both big and little endian hardware. After dealing with this sort of
> stuff for a long time with *far* fewer developers and time in general,
> I'm really not impressed with your argument. You'll have to do better
> then that.
With your experience what are the pro and cons of merging different archs ?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env
Roy Marples wrote:
>I just love replying to myself!
>
>On Tue, 2005-08-30 at 22:32 +0100, Roy Marples wrote:
>
>
>>#!/bin/sh
>>
>>/bin/env -i \
>>CONSOLETYPE="${CONSOLETYPE}" \
>>IN_BACKGROUND="${IN_BACKGROUND}" \
>>IN_HOTPLUG="${IN_HOTPLUG}" \
>>/lib/rcscripts/sh/runscript.sh $*
>>
>>
>
>A quick reboot shows we need much more. Here's what works on my system
>
>/bin/env -i \
>BOOT="${BOOT}" \
>CONSOLETYPE="${CONSOLETYPE}" \
>CRITICAL_SERVICES="${CRITICAL_SERVICES}" \
>START_CRITICAL="${START_CRITICAL}" \
>STOP_CRTIICAL="${STOP_CRITICAL}" \
>OLDSOFTLEVEL="${OLDSOFTLEVEL}" \
>SOFTLEVEL="${SOFTLEVEL}" \
>IN_BACKGROUND="${IN_BACKGROUND}" \
>IN_HOTPLUG="${IN_HOTPLUG}" \
>/lib/rcscripts/sh/runscript.sh $*
>
>
>
>
>>Right away we can see that we actually do need some to keep some env
>>vars and the list would be constantly updated. There's also nothing to
>>stop the user from setting them and then running a script which kind of
>>defeats the purpose here anyway.
>>
>>Personally I'm against this.I'd like to know what Azarah and Vapier
>>think of this though. Others too!
>>
>>
>
>I think I just added a few more reasons why I don't like this
>
>Roy
>
>
>
Read only the last three messages of the thread, hoping to not say
idiotic things.
Rewriting the previous script in the following manner:
[code]
VARS_TO_EXPORT="BOOT CONSOLETYPE CRITICAL_SERVICES START_CRITICAL
STOP_CRITICAL OLDSOFTLEVEL SOFTLEVEL IN_BACKGROUND IN_HOTPLUG"
RUNSCRIPT="/bin/env -i"
for i in ${VARS_TO_EXPORT} ; do
RUNSCRIPT="${RUNSCRIPT} ${i}=\${${i}}"
done
RUNSCRIPT="${RUNSCRIPT} /lib/rcscripts/sh/runscript.sh $*"
eval $RUNSCRIPT
[/code]
should make it easyer to maintain, also "VARS_TO_EXPORT" could be placed
in /etc/rc.conf (with a better name) .
Running the rc scripts from a clean environment make easyer to debug
things, it caused at least one headheache to me installing SuSE + apache
+ php + informix some years ago.
just my 2 cents.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] MySQL 4.0 => 4.1 upgrade
Please notice that MySQL-5.0 has been erroneously unmasked for few hours but it will return under the package.mask cover at next rsync. The MySQL herd is pleased to announce that Mysql 4.1 has been unmasked today and is now marked unstable. Hope that it's possible to stabilize it soon, here there is a upgrade path. .--- | propedeutic readings: http://dev.mysql.com/doc/mysql/en/upgrading-from-4-0.html http://dev.mysql.com/doc/mysql/en/news-4-1-x.html http://dev.mysql.com/doc/mysql/en/replication-upgrade-4-0.html .--- | Upgrade path: [[[ User with a old (<4.0.24 ??) mysql start from here ]]] quickpkg dev-db/mysql cmd# emerge -av --buildpkg =mysql-4.0.25-r2 cmd# ebuild \ /var/db/pkg/dev-db/mysql-4.0.25-r2/mysql-4.0.25-r2.ebuild config # Insert some kind of data fex attached "backup_mysql_4.0.sql.gz" [[[ User with a recent version of mysql start from here ]]] cmd# mysqldump \ -uroot \ -p$PASSWORD \ -hlocalhost \ --all-databases \ --all \ --opt \ --allow-keywords \ --flush-logs \ --hex-blob \ --master-data \ --max_allowed_packet=16M \ --result-file=BACKUP_MYSQL_4.0.SQL # check the backup file, try one one load on a mysql-4.0 server cmd# /etc/init.d/mysql stop cmd# quickpkg dev-db/mysql cmd# rm -rf /var/lib/mysql/ [[[ Real upgrade start here ]]] cmd# emerge -C mysql cmd# rm -rf /var/lib/mysql/ /var/run/mysqld/ /var/log/mysql cmd# emerge -av --buildpkg =mysql-4.1.14 cmd# revdep-rebuild cmd# ebuild /var/db/pkg/dev-db/mysql-4.1.14/mysql-4.1.14.ebuild config cmd# /etc/init.d/mysql start cmd# cat backup_mysql_4.0.sql \ | mysql \ -uroot \ -p$PASSWORD \ -hlocalhost \ --max_allowed_packet=16M cmd# mysql_fix_privilege_tables \ --defaults-file=/etc/mysql/my.cnf \ --user=root \ --password=$PASSWORD cmd# /etc/init.d/mysql restart -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 => 4.1 upgrade
Maurice van der Pot wrote: >Is this path going to be published somewhere or is this mail it? > > Not from me atm, I feel very bad at writing anglish documentation. An eventual reader sure feel worst. >On Thu, Sep 08, 2005 at 01:08:06PM +0200, Francesco R wrote: > > >>cmd# ebuild /var/db/pkg/dev-db/mysql-4.1.14/mysql-4.1.14.ebuild config >> >> >This asks for a password, but not all passwords can be entered. >Specifically one with a ` in it fails =] > >Also, when it outputs: >"Check the password" >it is asking you to enter the password again. I wasn't sure how to >interpret this, because the password was shown on the screen so it might >have been asking me to verify it and type ok or something. > > It's a mixture, I've received a suggestion in bugzilla on howto hide the password, but need to be tested on all platform before. > >And here's a character case mismatch: > > >>--result-file=BACKUP_MYSQL_4.0.SQL >>cmd# cat backup_mysql_4.0.sql \ >> >> > > > ach it has been discovered, I was already singing victory. >Regards, >Maurice. > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 => 4.1 upgrade
Michael Kohl wrote: >On Sat, 10 Sep 2005 18:24:46 +0200 >Maurice van der Pot <[EMAIL PROTECTED]> wrote: > > > >>Is this path going to be published somewhere or is this mail it? >> >> > >As Francesco said he won't publish a guide somewhere and I think MySQl >is a widely used package, I decided to write up a little guide: > >http://dev.gentoo.org/~citizen428/mysql-update.txt > >Yep, it's only plain text, no fancy GuideXML. I'm tired, so the wording >most probably isn't perfect. Still it's better than nothing and you >have a link to give to interested users... > > Convert a document from text to xml is something that I can do ;) . http://dev.gentoo.org/~vivo/doc/mysql-update.html /home/vivo/public_html/docmysql-update.xml the xml is chmoded 664, change, destroy, and revert whatever you want there. It's a extended and reorganized version from your txt doc. >Hope someone finds this useful, > > me for sure, thanks a lot. Documentation herd what now ? cheers Francesco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 => 4.1 upgrade
Martin Schlemmer wrote: [...] >Just use bash's built-in read function: > >- >local password newpasswd ># Read the password into $password >read -sp "Please enter password: " password ># Just echo a newline so that next output start on new line >echo > > [...] >Or something to that regards. > > In Cvs, thanks. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 => 4.1 upgrade
Jason Wever wrote: > On Thu, 8 Sep 2005, Francesco R wrote: > > >> Please notice that MySQL-5.0 has been erroneously unmasked for few > hours > >> but it will return under the package.mask cover at next rsync. > >> > >> The MySQL herd is pleased to announce that Mysql 4.1 has been unmasked > >> today and is now marked unstable. > > > Is there any particular reason that the utf8 use flag was > re-introduced rather than using the unicode use flag like everything > else does (and was standardized on)? Because it does not "Adds support for Unicode" but "switch default to utf8 character set" in MySQL config file, it's not possible to deactivate support for unicode in 4.1 version. > > Regards, > -- Jason Wever > Gentoo/Sparc Co-Team Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 => 4.1 upgrade
Jason Stubbs wrote: >On Monday 12 September 2005 00:05, Francesco R wrote: > > >>http://dev.gentoo.org/~vivo/doc/mysql-update.html >> >> > >With step 2, you should probably mention the issues that can arise with >non-ASCII data in char fields. The character set really needs to specified >in the dump. After the upgrade to 4.1, the default charset of the server >should be set to something compatible and then the charset of the data >should be specified to mysql when re-importing the backup. > > --default-character-set=charset should be that of my.cnf config file, mysqldump don't permit an atomic setting of this variable. The only option for this kind of users is to atomically dump the tables and then concat the results. Importing in mysql-4.1 it's ok, provided your default character set is utf8. Russian, asian whatever person has experience on this please speak now to correct what affermed here. >Just another one of the many gotchas... > > > expand this please -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 => 4.1 upgrade
Ciaran McCreesh wrote: >On Sun, 11 Sep 2005 19:46:25 +0200 Francesco R <[EMAIL PROTECTED]> wrote: >| > Is there any particular reason that the utf8 use flag was >| > re-introduced rather than using the unicode use flag like everything >| > else does (and was standardized on)? >| >| Because it does not "Adds support for Unicode" but "switch default to >| utf8 character set" in MySQL config file, it's not possible to >| deactivate support for unicode in 4.1 version. > >Bleh. A USE flag for a configuration file setting? Just install with >sane defaults and let the sysadmin change it if necessary... > > > Agree, all toghether please say that it should be defaulted to "utf8" also if the previous default was latin1. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] lights on internals
The ready to cut ebuild at the bottom print it's environment (variable
and functions) to a bunch of files into /var/tmp/fakebuild/.
May be useful for who want to have a look at "what" and "when" is
avaible during the various emerge phases (but not limited to).
usage:
# env -i \
PORTDIR_OVERLAY=/the/path/ \
fakebuild_progr=100 \
ebuild fakebuild-1.ebuild digest
# env -i \
fakebuild_progr=200 \
PORTDIR_OVERLAY=/the/path/ \
emerge --buildpkgonly =fakebuild-1
hint: try also the following:
- remove the egrep, sort after "typeset" to have also the sorce code of
the functions
- remove "{pkg,src}*" functions (after the previous step) to have a
look at the predefined functions.
--- app-misc/fakebuild --
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
DESCRIPTION="fake ebuild to test environment"
HOMEPAGE="http://dev.gentoo.org/~vivo/";
SRC_URI=""
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86"
print_env() {
local fakebuild_output_dir="/var/tmp/fakebuild"
mkdir -p "${fakebuild_output_dir}" || die
[[ -z "${fakebuild_progr}" ]] && fakebuild_progr=100
fakebuild_progr=$(( $fakebuild_progr +1 ))
export fakebuild_progr
local fakebuild_ext="${1}.${fakebuild_progr}"
# not sorting, break multiline vars
einfo "${fakebuild_output_dir}/env_${fakebuild_ext}"
env \
&> "${fakebuild_output_dir}/env_${fakebuild_ext}"
# Remove egrep and sort to see the source of every fx
einfo "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
typeset \
| egrep '^\b.* \(\)' \
| sort \
&> "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
}
print_env "global_scope"
pkg_setup(){ print_env "pkg_setup" ; }
src_unpack() { print_env "src_unpack" ; }
src_compile() { print_env "src_compile" ; }
src_test() { print_env "src_test" ; }
src_install() { print_env "src_install" ; }
pkg_preinst() { print_env "pkg_preinst" ; }
pkg_postinst() { print_env "pkg_postinst" ; }
--- app-misc/fakebuild --
--
___ __ _ ___ ___
/ ___/_ \_ \/ \ / / ___/ ___/ _ / ___/ _ \ /_ \
/ __/ _/__ / \ \/ / /__/ _/_ _\ \/ /__/ / / / / _/
/_/ /_/\_\/_/_/_/ \__/\___///___ \___/\/ / /\_\o
Simultaneous breaking of databases and backups since '90s.
World wide since 2005.0
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] lights on internals
Brian Harring wrote:
>On Sun, Oct 02, 2005 at 11:07:13PM +0200, Francesco R wrote:
>
>
>>The ready to cut ebuild at the bottom print it's environment (variable
>>and functions) to a bunch of files into /var/tmp/fakebuild/.
>>May be useful for who want to have a look at "what" and "when" is
>>avaible during the various emerge phases (but not limited to).
>>print_env() {
>>local fakebuild_output_dir="/var/tmp/fakebuild"
>>mkdir -p "${fakebuild_output_dir}" || die
>>
>>[[ -z "${fakebuild_progr}" ]] && fakebuild_progr=100
>>fakebuild_progr=$(( $fakebuild_progr +1 ))
>>export fakebuild_progr
>>
>>local fakebuild_ext="${1}.${fakebuild_progr}"
>>
>># not sorting, break multiline vars
>>einfo "${fakebuild_output_dir}/env_${fakebuild_ext}"
>>env \
>>&> "${fakebuild_output_dir}/env_${fakebuild_ext}"
>>
>># Remove egrep and sort to see the source of every fx
>>einfo "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
>>typeset \
>>| egrep '^\b.* \(\)' \
>>| sort \
>>&> "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
>>}
>>
>>
>
>This won't work as you expect. Env is a binary, it only gets
>the exported env.
>
>
>
Got the point (maybe), "typeset" is a Bash built-in.
The first part of the "typeset" output command give the variable list
*and* it's different from the output of "env" binary.
The output is different in two ways, first the vars are differently
formatted, missing apices " ' " for example.
env also is missing all .bashrc defined vars (speaking of a normal
environment not of a portage/emerge one).
==> the "env" command should be replaced by
typeset &> tmpfile
tmpfile | grep -B1 "$(egrep "^\b.* \(\)" tmpfile | head -n 1)" |
head -n '-1'
(basically the output of typeset cutted at first function)
>Elaborate on the "what and when" bit also, since the env that's dumped
>to ebuild.sh varies depending on a lot of things.
>~harring
>
>
>
The environment is changing between the various predefined functions and
in the global scope of an ebuild, at the moment only for vars, not for
functions.
example of variable vars are:
SANDBOX_*
PORTAGE_RESTRICT
TMP
EBUILD_PHASE
TMPDIR
PWORKDIR
DISTCC_DIR
LD_PRELOAD
All variables that must stay readonly, or not readed at all, inside an
ebuild but may explain at the human that's writing one, what's happening
and when.
better ?
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.
mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be time to stabilize the 4.1 branch of mysql. ARCH teams, robbat2, php-herd, thoughts ? If no one is versus I'll stabilize 4.1.14 for "x86" and "amd64" tomorrow (with dev-perl/DBD-mysql-2.9007), then mysql-5.0 will be unmasked. Furter note to the "sh" ARCH, my apologies, I've removed your keyword from mysql-4.0.[456]* ebuilds, repoman commit gived me a "badindev" for dev-perl/DBI. Best regards, Francesco Riosa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.
Alle 16:06, lunedì 17 ottobre 2005, Francesco R. ha scritto: > mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be > time to stabilize the 4.1 branch of mysql. has been reported on GWN, thanks gui [snip] > > If no one is versus I'll stabilize 4.1.14 for "x86" and "amd64" > tomorrow (with dev-perl/DBD-mysql-2.9007), then mysql-5.0 will be > unmasked. Little step back here, I'm working with "x86" and "amd64" ARCH teams to do a better testing before. Anyway it should be still stabilized soon. [snip] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Unmasking dev-db/mysql-5
Alle 16:06, lunedì 17 ottobre 2005, Francesco R. ha scritto: > mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be > time to stabilize the 4.1 branch of mysql. > MySQL 4.1 is (keyworded) stable for "amd64" and "x86" . Going through step 2 now, unmasking MySQL 5.0 . As a security measure ARCHs that does not have a stable 4.1 have been removed from keywords . Best regards, Francesco Riosa -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Slotted MySQL ; mysql-herd
There are these ebuilds in cvs from few minutes: mysql-4.0.26-r30.ebuild mysql-4.1.15-r30.ebuild mysql-5.0.15-r30.ebuild these ones contain a starting point ebuild to make a slotted mysql installation. The motivations that push this choice are both developement and user side. Making a long story short there are two points: We want to support every major.minor version of mysql, having slotted mysql make life easyer to developers in testing all supported versions. User side, slotted mysql server and client make possible a smooter upgrade, keeping downtimes to the minimum (a stop and start in the best case). ; Further these days I was wondering to populate a bit more "mysql-herd" of developers and packages, also to cover my personal lack of knowledge on some languages (deeper explanation in private mails ;-) So if you're interested in join the herd, let me know (sorry non-dev, I cannot mentor these days). I'm listed on devaway from 2005-10-01 to 2005-10-10, will answer when I'll come back. Cheers, Francesco Riosa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
2010/12/13 Ryan Hill
> On Sun, 12 Dec 2010 09:01:13 -0400
> "Sergio D. Rodríguez Inclan" wrote:
>
> > El 12/12/2010 02:46 a.m., Ryan Hill escribió:
> > > I think the fewer sources of magic USE flags the better. Maybe we
> could
> > > document how to figure out what instruction sets a processor supports
> in the
> > > handbook instead.
>
> > A good manual would be greatly appreciated :)
>
> I wrote a guide a couple weeks ago that might be a good starting point.
>
> http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS
>
>
if I read correctly the article on the wiki it does circa what the script
reported below does.
would be possible to adopt something similar for automatic C*FLAGS selection
if someone step in willing to take the pain to mantain it.
#!/usr/bin/python
# Copyright 2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# Author: Francesco Riosa
# extrapolated from http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS, errors
are mine
# kate: encoding utf-8; eol unix
# kate: indent-width 4; mixedindent off; replace-tabs on;
# kate: remove-trailing-space on; space-indent on
# echo "int main() { return 0; }" | gcc -march=native -v -E - 2>&1 | grep
march
# echo "int main() { return 0; }" | gcc -march=core2 -v -Q -x c - 2>&1
"""
example output:
./hw-cflags.py
extrapolating flags for gcc-4.4.5
useful flags: -march=core2 -msse4.1 --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic
redundant:-mcx16 -msahf
extrapolating flags for gcc-4.5.1
useful flags: -march=core2 -msse4.1 --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2
redundant:-mcx16 -msahf
"""
import os
import time
import fnmatch
from subprocess import Popen, PIPE
GCC_PATH = '/usr/bin/'
GCC_LIST = fnmatch.filter(os.listdir(GCC_PATH), 'gcc-[0-9].*')
GCC_LIST.sort()
def extract_flags(gcccmd, header):
# get output from gcc
buf = ''
devnul = open('/dev/null', 'w')
p = Popen(gcccmd, stdin=PIPE, stdout=devnul, stderr=PIPE)
p.stdin.write("""int main() { return 0; }""")
p.stdin.close()
while p.poll() is None:
t = p.stderr.read()
buf = "buf%s" % t
time.sleep(0.01)
p.stderr.close()
devnul.close()
# parse it
flags = []
add = False
for line in buf.split('\n'):
if line.startswith(header):
add = True
flags += line.strip().split(' ')
continue
if add:
if line.startswith(' '):
flags += line.strip().split(' ')
else:
break
# extract flags we are interested in
t = []
march = ''
mtune = '-mtune=generic'
for i in xrange(len(flags)):
if flags[i].startswith('-m'):
if flags[i].startswith('-mtune'):
mtune = flags[i]
elif flags[i].startswith('-march'):
march = flags[i]
else:
t.append(flags[i])
elif flags[i] == '--param':
t.append("%s %s" % (flags[i], flags[i+1]))
flags = t
return march, mtune, flags
for gcc in GCC_LIST:
print "extrapolating flags for %s" % gcc
gcccmd = [ GCC_PATH + gcc, '-march=native', '-v', '-E', '-', ]
header='COLLECT_GCC_OPTIONS'
march, mtune, flags_native = extract_flags(gcccmd, header)
gcccmd = [ GCC_PATH + gcc, march, '-v', '-Q', '-x', 'c', '-', ]
header='options enabled:'
t, t, flags_enabled = extract_flags(gcccmd, header)
redundant_flags = []
useful_flags = []
for x in flags_native:
if x in flags_enabled:
redundant_flags.append(x)
else:
useful_flags.append(x)
if gcc < "gcc-4.5.0":
mtune = '-mtune=generic'
print " useful flags: %s %s %s " % (march, " ".join(useful_flags),
mtune)
print " redundant:%s" % " ".join(redundant_flags)
print
Re: [gentoo-dev] Re: Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
2010/12/13 Konstantin Tokarev
>
>
> 13.12.2010, 18:53, "Francesco R" :
> > 2010/12/13 Ryan Hill
> >> On Sun, 12 Dec 2010 09:01:13 -0400
> >> "Sergio D. Rodríguez Inclan" wrote:
> >>
> >>> El 12/12/2010 02:46 a.m., Ryan Hill escribió:
> >>> > I think the fewer sources of magic USE flags the better. Maybe we
> could
> >>> > document how to figure out what instruction sets a processor supports
> in the
> >>> > handbook instead.
> >>
> >>> A good manual would be greatly appreciated :)
> >>
> >> I wrote a guide a couple weeks ago that might be a good starting point.
> >>
> >> http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS
> >
> > if I read correctly the article on the wiki it does circa what the script
> reported below does.
> > would be possible to adopt something similar for automatic C*FLAGS
> selection if someone step in willing to take the pain to mantain it.
> >
> > #!/usr/bin/python
> > # Copyright 2010 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # Author: Francesco Riosa
> > # extrapolated from http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS,
> errors are mine
> >
> > # kate: encoding utf-8; eol unix
> > # kate: indent-width 4; mixedindent off; replace-tabs on;
> > # kate: remove-trailing-space on; space-indent on
> >
> > # echo "int main() { return 0; }" | gcc -march=native -v -E - 2>&1 | grep
> march
> > # echo "int main() { return 0; }" | gcc -march=core2 -v -Q -x c - 2>&1
> >
> > """
> > example output:
> > ./hw-cflags.py
> > extrapolating flags for gcc-4.4.5
> > useful flags: -march=core2 -msse4.1 --param l1-cache-size=32 --param
> l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic
> > redundant:-mcx16 -msahf
> >
> > extrapolating flags for gcc-4.5.1
> > useful flags: -march=core2 -msse4.1 --param l1-cache-size=32 --param
> l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2
> > redundant:-mcx16 -msahf
> > """
> >
> > import os
> > import time
> > import fnmatch
> > from subprocess import Popen, PIPE
> >
> > GCC_PATH = '/usr/bin/'
> > GCC_LIST = fnmatch.filter(os.listdir(GCC_PATH), 'gcc-[0-9].*')
> > GCC_LIST.sort()
> >
> > def extract_flags(gcccmd, header):
> > # get output from gcc
> > buf = ''
> > devnul = open('/dev/null', 'w')
> > p = Popen(gcccmd, stdin=PIPE, stdout=devnul, stderr=PIPE)
> > p.stdin.write("""int main() { return 0; }""")
> > p.stdin.close()
> > while p.poll() is None:
> > t = p.stderr.read()
> > buf = "buf%s" % t
> > time.sleep(0.01)
> > p.stderr.close()
> > devnul.close()
> >
> > # parse it
> > flags = []
> > add = False
> > for line in buf.split('\n'):
> > if line.startswith(header):
> > add = True
> > flags += line.strip().split(' ')
> > continue
> > if add:
> > if line.startswith(' '):
> > flags += line.strip().split(' ')
> > else:
> > break
> >
> > # extract flags we are interested in
> > t = []
> > march = ''
> > mtune = '-mtune=generic'
> > for i in xrange(len(flags)):
> > if flags[i].startswith('-m'):
> > if flags[i].startswith('-mtune'):
> > mtune = flags[i]
> > elif flags[i].startswith('-march'):
> > march = flags[i]
> > else:
> > t.append(flags[i])
> > elif flags[i] == '--param':
> > t.append("%s %s" % (flags[i], flags[i+1]))
> > flags = t
> >
> > return march, mtune, flags
> >
> > for gcc in GCC_LIST:
> >
> > print "extrapolating flags for %s" % gcc
> >
> > gcccmd = [ GCC_PATH + gcc, '-march=native', '-v', '-E', '-', ]
> > header='COLLECT_GCC_OPTIONS'
> > march, mtune, flags_native = extract_flags(gcccmd, header)
> >
> > gcccmd = [ GCC_PATH + gcc, march, '-v', '-Q', '-x', 'c', '-', ]
> > header='options enabled:'
> > t, t, flags_enabled = extract_flags(gcccmd, header)
> >
> > redundant_flags = []
> > useful_flags = []
> >
> > for x in flags_native:
> > if x in flags_enabled:
> > redundant_flags.append(x)
> > else:
> > useful_flags.append(x)
> >
> > if gcc < "gcc-4.5.0":
> > mtune = '-mtune=generic'
> >
> > print " useful flags: %s %s %s " % (march, " ".join(useful_flags),
> mtune)
> > print " redundant:%s" % " ".join(redundant_flags)
> > print
>
> Note that for some architectures (e.g, PowerPC) you need to add "-mcpu"
> case
> (-mcpu has the same meaning as -march on x86)
>
>
> --
> Regards,
> Konstantin
>
>
Assuming there is some possibility of Gentoo using some automated method of
choice of CFLAGS the arch maintainers should really step in and tell what
works on their cpus and be able to modify/disable it.
There are other shortcomings in the script, for example it does not work
with
Re: [gentoo-dev] Re: glibc-2.13 news item?
2011/2/9 Ryan Hill
> On Tue, 08 Feb 2011 09:52:55 +0100
> "Paweł Hajdan, Jr." wrote:
>
> > It seems that with glibc-2.13 there are some serious compatibility
> > issues. There are good warnings on the planet
> > (http://psykil.livejournal.com/340806.html), but not every ~arch user
> > reads the planet, so how about creating news item with detailed
> > instructions how to ensure smooth glibc-2.13 update or recover a hosed
> > system?
>
> We've blocked prelink in the ebuild so if a user is able to sync they're
> either not going to be affected or already have been.
>
> Also I've the strong suspect that these changes:
* New optimized string functions for x86-64: strnlen (SSE2),
strcasecmp (SSE2, SSSE3, SSE4.2), strncasecmp (SSE2, SSSE3, SSE4.2)
Implemented by Ulrich Drepper.
Interact badly with strong optimizations like these
CFLAGS="-O2 -march=core2 -pipe"
CFLAGS="${CFLAGS} -msse4.1 --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2" # native
CFLAGS="${CFLAGS} -fgcse-after-reload -fpredictive-commoning
-ftree-vectorize -funswitch-loops" # O3 - -finline-functions -fipa-cp-clone
CFLAGS="${CFLAGS} -fgraphite-identity -floop-block -floop-interchange
-floop-strip-mine" # graphite & co (-fira-loop-pressure no good amd64)
using gcc-4.5.2
Since the upgrade I do get portage emerging text files .sh, .conf and such
as file of the exact same size but filled of \0, luckily most upgrade fails.
cpu is:
model name : Intel(R) Core(TM)2 Quad CPUQ8400 @ 2.66GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts
tpr_shadow vnmi flexpriority
I've masked glibc-2.13, also I'm not filing a bug, because of non-usual
CFLAGS and because I'm not totally sure is glibc related.
Re: [gentoo-dev] Re: glibc-2.13 news item?
2011/2/9 Michał Górny > > On Wed, 9 Feb 2011 13:32:36 +0100 > Francesco R wrote: > > > Since the upgrade I do get portage emerging text files .sh, .conf and > > such as file of the exact same size but filled of \0, luckily most > > upgrade fails. > > I've seen similar issue in bug #353907 [1] but there they blame > coreutils and/or btrfs. Maybe you should take a look. > > [1] http://bugs.gentoo.org/show_bug.cgi?id=353907 > thanks Michał Górny, I had portage tmpdir on btrfs. My fault then, please ignore the noise in the my previous message. Best regards, Francesco R.
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
2011/2/22 Rich Freeman : > On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller wrote: >>> On Tue, 22 Feb 2011, Mike Frysinger wrote: >>> that might disallow it for binaries, but it doesnt disallow it from >>> being used in ebuilds. same situation as binary kernel drivers -- >>> make it the end user's problem. >> >> Why should we impose such trouble on our users, when there's a (IMHO >> superior) replacement? Build gnuplot with USE="cairo" and you can get >> PDF output with the "pdfcairo" terminal. Even with proper utf-8 >> support, which was always broken with pdflib. > > +1 to both - if a free alternative works then we should always prefer > it. However, at worst linking license issues should just force us to > set RESTRICT="bindist" or the like (and mirror as well if we can't > distribute the source). As long as users don't redistribute software > they don't need to worry about licenses if the person sending it to > them had the license to distribute it in the first place. > > Rich > Last time (many moons ago) I've checked cairo did not generated pdf it did generated raster images and wrapped them in a thin pdf layer. pdflib is generating vector pdf which is a different thing.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
2011/6/11 Mike Frysinger : > On Saturday, June 11, 2011 16:24:00 Ciaran McCreesh wrote: >> On Sat, 11 Jun 2011 15:58:43 -0400 Mike Frysinger wrote: >> > > So, effectively the QA team lead can appoint the people who elect >> > > him. I'm not at all implying that Diego would abuse his position, >> > > but still I think that this is not a sane situation. >> > >> > it does seem trivial to remove people who disagree with you and thus >> > cement an echo chamber >> >> Are you talking in a hypothetical future situation, or has this already >> happened? If so, can you point to an example of where Diego's been >> removing people for disagreeing with him, rather than for disagreeing >> with the Council? > > how is disagreeing with a Council decision valid grounds either ? punting > people because they disagree with any group isn't really valid. > -mike a user POV: If you are in the role of enforcing decision of the council and with "disagreeing" you mean acting versus their decision yes it's a very much valid ground. In real life if you are a policeman and disagree with politicians you must anyway enforce their laws or you're jailed. Anyway maybe the whole QA should resign (you too Diego) and election done again, seem the more correct thing at this point
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
2011/7/3 Paul Arthur :
> On 2011-07-03, Jonathan Callen wrote:
>> Peter Volkov wrote:
rm -rf "${D}/usr/share/doc/aria2"
>>>
>>> || die
>>
>> `rm -f` never fails -- if the target does not exist, then rm simply returns
>> true. (The only reason it would fail that I can think of is /bin/rm not
>> existing, in which case you have a bigger problem.)
>>
>> To test, try `rm -f /nonexistant/file; echo $?`
>
> jill-zeke /var/tmp $ rm -f testfile
> rm: cannot remove `testfile': Operation not permitted
> jill-zeke /var/tmp $ echo $?
> 1
rm -f "chuck norris"
rm: cannot remove `Chuck Norris': Operation not contemplated
echo $?
42
> jill-zeke /var/tmp $ rm -rf testdir
> rm: cannot remove `testdir/test': Permission denied
> jill-zeke /var/tmp $ echo $?
> 1
>
>
> --
> Suddenly, the door crashed open. Outside, purple prose rained down
> like a bad metaphor.
> --SteveD on RPGnet
>
>
>
[gentoo-dev] Re: color management in gentoo (kde expecially) proposal for help
re-adding the list, gmail still fool me some times. 2012/2/23 Kai-Uwe Behrmann : > Hello, > > glad to read from you. > > Am 23.02.12, 15:47 +0100 schrieb Francesco Riosa: > >> Hi, >> my name is Francesco Riosa, I would be interested in a more >> complete support of the oyranos color managment programs in ::gentoo. >> Oyranos is intended to be multy platform and in some sense multy os, >> but in the current incarnation has good support for kde. > > > Joseph works on a GUI front end for Qt to broaden the support. And you are > right, KDE's KolorManager is in the best shape. Synnefo is already in a good shape too right? I would also like to see a complete replacement for icc-examin, expecially it's ability to see multiply profiles in the same 3d space, you know, to be able to say those 300€ for a better monitor were a good price ;-) >> In case there is interest I can apply to return as a developer in >> gentoo, will respond to emails this week end (25/26 Feb) > > > I read this as a offer to help packaging in gentoo. Typical I work with > packagers and like to easen their work. Personally I maintain a openSUSE > colour managed software stack as packager myself and be open for suggestions > or ideas from Fedora and gladly from gentoo as well. indeed it's an offer for direct or proxyed help gentoo, a pair of ideas that would help gentoo later > > Often it was mentioned to use autotools or cmake. The next soon to be > released rersion of libXcm, one small library, will be autotooled. The > conversion is a hard and time consuming part for me, but we hope to get all > packages converted. Initially I had some help, which was a good kick off. unlike the rest of the world I prefer cmake over autotools, but if you need help on autotools I suggest to ask this list, there is a lot of expertise here and packagers are going to fix bug in build system anyway, so better soon than later. Gentoo has good support for quite every build system out there, but yes the two you mentioned are preferred. While gentoo is more flexible than binary distro, there is one thing that help them a lot, do releases (possibly often), they need a fixed point to start with, having only a git repository where to pull mean to be a second class cityzen. > In case you want to maintain gentoo specific files inside the upstream > packages and keep them up to date, that is possible. I do so with a rpm and > deb make target. Not sure if that makes sense for gentoo. I'm quite sure it's not needed, to the opposite, generally those files go out of sync easily and are better mantained by gentoo devs. > > The build scripts and a README are linked here: > http://www.oyranos.org/wiki/index.php?title=Oyranos/git > icc_examin-build-local.sh can be adapted. > As one nice step it would be great, if you can name one or more command > lines to get gentoo ready for building Oyranos and the other parts of the > software stack. So people could test Oyranos from git easily inside gentoo. I've the complete oyranos software stack building well in gentoo at the moment (using git) :-) >> I'm _not_ offering support for digikam, for which I develop, because I >> would like to mantain a two step verification process >> (developer/packager) >> >> Regards, >> Francesco > > kind regards > Kai-Uwe > -- > www.oyranos.org > oy#open...@freenode.org
Re: [gentoo-dev] Free Gentoo
On Saturday 21 January 2012 21:56:22 Markos Chandras wrote: > On 01/21/2012 06:01 PM, . wrote: > > Hello there! > > > > Is there a chance that Gentoo may become a free distro? > > > > I'm so unhappy with the fact that there are some non-free packages > > in the main tree. The main goal of the GNU project was to replace > > the proprietary Unix system. You are actually ruining this goal. > > > > I'm also dissatisfied with the name of the distro. Linux is the > > kernel not the whole system. > > > > > > Cheers. > > Please guys stop replying to this email. It is clearly a spam or a > flamebait. Try to avoid (unnecessary) flames :) well, while the original mail was disturbing most of the reply have been fun to read (some even instructive), so may be this time it was worth an exception and feeding the troll :-)
[gentoo-dev] LANG=en_GB.UTF-8 by default
as subject says could gentoo change the policy and set an UTF-8 environment by default? http://www.gentoo.org/doc/en/utf-8.xml how to do it very well but having it already set could have the following two advantages: 1) well utf-8 is everywhere, even the linux weekly newsletter has it in 2012 2) the user need to change, not to create a /etc/env.d/XX-lc, creating a standard place where every gentoo install has this settings. contra? P.S. would be nice to have a wd_WD.UTF-8 with WD standing for world, just a country is so 1900
