Re: [gentoo-dev] Re: GCC 4.6.0
On 03. 04. 2011 16:04, Mike Frysinger wrote: On Sun, Apr 3, 2011 at 6:19 AM, Ryan Hill wrote: On Sun, 3 Apr 2011 05:50:32 Duncan wrote: Ryan Hill posted on Sat, 02 Apr 2011 22:11:12 -0600 as excerpted: You may also want to test your packages with the new -Ofast option to be sure it doesn't have any hardcoded assumptions about -O flags. The release description I've read for -Ofast says it includes -fast-math, among other things, a flag Gentoo has always strongly discouraged (you break with it, you keep the pieces) and which can get bugs resolved/ invalid as a result. Now that gcc 4.6 itself is more strongly supporting it as enabled with one of the -O options, is that policy going to change, or is Gentoo going to officially not support -Ofast, as well? I doubt we will. If a package breaks because of -Ofast there's really nothing we can do about it. It's not a bug in the compiler or the package, it's that you explicitly told it to generate non-standard-conformant code. obviously we will look at ICEs and such, but in terms of apps misbehaving at runtime, most likely we'll write it up as not a bug like Ryan says -mike Maybe slightly off topic, but still.. 1. I've noticed that -Ofast and couple other bits on gcc which I have seen on Open64 before. Are these new optimisations imported from Open64 or is this simply the result of good old competition of both teams ? 2. Is there any info on gcc version that will support -march=Bulldozer ? I have googled a couple of gcc-related posts about optimizing for this CPU architecture intricacies and I have hoped to see support for it in 4.6... Is this stuff still in early development or is it just waiting for AMD to ship the chips due to some kind of NDA ?
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
S, René 'Necoro' Neumann piše: Don't forget, that Cobra compiles to C# which then is compiled to .NET CLI. I don't think, that anyone here feels really good about having the core package of Gentoo to require Mono. Uh. I didn't know that. I've read only that it gets compiled into bytecode, which is then compiled into native code. It seemed convoluted, but what the heck, I figured it still beats classic interpreter. I didn't know it uses Mono etc. In that case, forget that I asked - this thing seems awkward from more than one angle...
[gentoo-dev] Cobra as a Python replacement for portage infra...
Hi to all, I am sorry if I'm wasting bandwidth on gentoo-dev with this, but I have found no good answere elsewhere. I have accidentally stumbled on Codelite ( at the first glance ) _great_ IDE for C/C++/Python ( www.codelite.org). While toying with its settings for various language syntaxes, I have glanced at Language named Cobra. Since emerge -s cobra gave me nothing, I took a peek at: www.cobra-language.org. It seems interesting- compiled Python-like language, that is speedwise much closer to C++ than to Python, static/dynamic binding, optional static variable typing etc... My question is, could existing Portage infrastructure be ported to such language with minimal effort and would it be worthwile to even try ? There are many operations that now take portage ages to complete, so it seems that this could be benefitial... Has anyone of Pythonistas tried to give Cobra a look or two ?
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
Erm, link is http://cobra-language.com http://cobra-language.com/
[gentoo-dev] Cobra as a Python replacement for portage infra...
( reposted as a new thread. Sorry for inconvenience.) Hi to all, I am sorry if I'm wasting bandwidth on gentoo-dev with this, but I have found no good answere elsewhere. I have accidentally stumbled on Codelite ( at the first glance ) _great_ IDE for C/C++/Python ( http://www.codelite.org ). While toying with its settings for various language syntaxes, I have glanced at Language named Cobra. Since emerge -s cobra gave me nothing, I took a peek at: www.cobra-language.com It seems interesting- compiled Python-like language, that is speedwise much closer to C++ than to Python, static/dynamic binding, optional static variable typing etc... My question is, could existing Portage infrastructure be ported to such language with minimal effort and would it be worthwile to even try ? There are many operations that now take portage ages to complete, so it seems that this could be benefitial... Has anyone of Pythonistas tried to give Cobra a look or two ?
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
William Hubbs wrote: On Tue, Oct 13, 2009 at 06:23:32PM +0300, Markos Chandras wrote: On Saturday 10 October 2009 23:30:05 Matthias Schwarzott wrote: On Samstag, 10. Oktober 2009, Nirbheek Chauhan wrote: On Sat, Oct 10, 2009 at 6:42 PM, Alin N??stac mrn...@gentoo.org wrote: On 10/9/09 7:57 PM, Matthias Schwarzott wrote: * does new scripts already can do all that was possible with net.* ? No. PPP is not compatible with the new scripts. Major regression. It never pays to drop surprises on people like this. I *strongly* suggest masking openrc-0.5.1 until the documentation is updated and a news file is sent. Why do you suggest masking it immediately? Emerging it without changing any use-flags, has oldnet enabled by default, so user gets exactly the same net init-scripts as with openrc-0.4 before, so where is the regression that needs to be masked? One can still use the same stuff and nobody is forced to transition to the new network script. Regards Matthias I agree with Nirbheek. You should always provide an updated documentation ( and a news item if necessary ) when you release a new major update of such core packages. I would like to see new openrc masked until the documentation is ready with full details about the transition to the new network init script. If you don't provide such documentation in time, you will fail to make users switch to new init script in the near future, since everybody will forget about this and will use the 'oldnet' use flag anyway. The sooner you will explain them how to migrate, the better results/feedback/updated systems you will get I do not agree that masking the new openrc is appropriate, since it works fine with the oldnet use flag and that is the default (I upgraded flawlessly and left the use flags alone). Maybe there should be a warning for now if you turn off the oldnet use flag that warns you that the new network scripts may not work in all situations. Then, when it comes time to migrate, you can drop the oldnet use flag entirely and explain in a news item how to migrate. Main question is NOT whether it works for you, but whether it will break stuff on significant percent of other users. It broke on my machine, for example, and it was quite disconcerting, since it was at quite inconvenient moment and I had note get to any shred of documentation about ANY kind of substantial behaviour change of new openrc...
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
William Hubbs wrote: On Tue, Oct 13, 2009 at 10:55:45PM +0200, Branko Badrljica wrote: Main question is NOT whether it works for you, but whether it will break stuff on significant percent of other users. It broke on my machine, for example, and it was quite disconcerting, since it was at quite inconvenient moment and I had note get to any shred of documentation about ANY kind of substantial behaviour change of new openrc... The default is to use the old net.ethx style network scripts, which still work as usual, so, that is why I said that I disagree about there being a regression. A regression means that something worked before, but it doesn't now, and that is not the case if you accept the defaults. Which I did. I don't have openrc in /etc/portage/package.use, so it was emerged with default USE flags ( if you count default as in as set in make.conf ). emerge -pv openrc woould emerge it as: sys-apps/openrc-0.5.1 [0.4.3-r4] USE=ncurses oldnet%* pam unicode -debug ... which means with oldnet flag. And whenever I tried it, it broke my system. If you accept the defaults and it doesn't work, I will gladly agree that there is a major regression and the package should be masked. On the other hand, if the new network scripts do not work, I don't see that as a show stopper. Yes, I would agree that there should be a warning about turning off the oldnet use flag, but I don't think this warrants masking the ebuild, unless I am missing something. If I am, definitely let me know. I don't feel comfortable with your philosophy. It doesn't matter how obvious matters seem to you, your changes can affect many people in many situations and configurations, not necessarily allways without unforseen consequences. I understand that Gentoo is not for pussies and that you can't make an ISO-9001 procedure for every change with every user, but it would really be nice to have at least some _basic_ safety, like mentioning changes in eselect news, or at least on home page of the package.
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
Thomas Sachau wrote: SNIP I disagree in this place. ~arch is called testing because it actually is about TESTING new versions and packages. You should expect problems and you should be able to recover from them and you should be able to use bugzilla. Else i suggest you move to a stable arch instead. Your arguments could make sense, if it would be about the stable tree, but forcing the testing tree to be a second stable tree, just with newer package versions isnt our goal nor does it help anyone. 1. Much of the time on Gentoo using of ~ packages is not user explicit choice but forced compromise. I don't remember exactly anymore what prompted me to enter openrc in package.keywords, but I surely remember having a few headaches with it. Same is with many other packages- many times using ~arch is the only answer, so 99% of the time it is used for getting some package to work and not for pure testing. Having in mind state of the matter in_real_world, I really don't think that having such things at least temporarily masked ( not to mention DOCUMENTED!) is really not overdoing it. 2. About using bugzilla- how the heck was I supposed to use it without net access ? 3. My main if not only argument was about at last documenting such changes. As it was done, it presented me with nasty surprise. Machine has gotten through upgrade world just fine and only after reboot it couldn't start network interfaces. Manual restart croaked with some error about python not being able to find some function. It felt exactly like a few last times when my ext4 decided to lose a few hundred essential system files. There was nothing to suggest openrc. After I lost some time reemerging system files and sifting through ebuilds, packages and scripts, that casual message here about new openrc hit me purely by chance, otherwise I would be in for much more pain. After I got system running again, I couldn't find anywhere anything at all about any substantial change in openrc. Not on bugzilla, not on openrc home page nor anywhere else. 4. About filing bugzilla bug, I can't do it now, since I am in a hurry and without it I can't contribute any really useful data. Will do when I get around to it...
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
Mike Frysinger wrote: i really dont buy this argument, but ignoring that, poor admin policy is no excuse. blindly accepting all unstable versions of a package instead of pinning a specific version and then expecting a stable system isnt going to happen. Thomas is absolutely right here. Well, if eh is absolutely right, then I won't argue anymore. But just as an notice, I didn't expect STABLE but at least DOCUMENTED system ? Is that too much to ask ? And even if I did a mistake of keywording openrc-0* instead of openrc-0.4-r3, do I really deserve such knife in the back ? Having some reasonable safety margin is base of sanity. Your PSU is galvanicaly insulated, but law demands that housing of your PC be connected to earth potential in case of insulation failing. Had that been done by Gentoo community courts would be full of cases of unreasonable dead jerks who should be grateful... documentation doesnt write itself. this isnt directed specifically at you, but clamoring gimme gimme gimme is more likely to get people to tell you to toss off than get what you want. And who should write documentation for new code ? Unreasonable users that find it not working or perhaps authors ? While I recognise the fact that Gentoo is not commercial distro, I want also some recognition for value of my time as a passive tester. I am happy to give what I can, but I expect at least some basic foundations for that. Having documentation about public changes at least for me falls well within that category. At least for me, even otherwise useful changes can have NEGATIVE value, if they gob heaps of my time totally unnecesarilly and total lack of documentation is on top of the list of best ways to piss on masses.
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
Dawid Węgliński wrote: sapphire ~ # qlist openrc | grep doc /usr/share/doc/openrc/net.example /usr/share/doc/openrc/net.default As said, I already did that. In fact, that was the first thing I was looking for. After seeing post here about radical changes in v0.5, that was the first thing I did. But net.example showed NO obvious changes. Nevertheless, I tried both- my original net and one that I derived from net.example anew. Just for the fun of it, I reemerged openrc-0.5-r1 just now, edited net.example, and tried both- my original net and edited net.example. This time, machine boots and sets both lo and eth0 without any error message, but it fails to set default route, so without manual route add default gw 192.168.1.1 net is dead. And machine is stuck at checking local filesystems for a whole few minutes now without apprently doing anything, but this is besides the point here. And, for the umpteenth time: 1. openrc was remerged with default oldnet flag 2. I did check net.example 3. All I asked is for this things to be available. Few words, if nothing else. Preferrably on news, so I can get them after emerge but bugzilla is also acceptable. Forums are nice, but not adequate communication channel for such purpose. I found only one chap with a problem close to mine on forum, and he was left without an answer: net.eth0 doesn't work at boot http://forums.gentoo.org/viewtopic-t-797108-highlight-openrc.html
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
Mike Frysinger wrote: the mailing list is not bugzilla. any complaints you have about USE=oldnet have nothing to do with this thread. it's a bug and should be treated as such. -mike Which is why I have posted here to gripe about having documented such changes in future. I was told that new openrc is surely fine because it works for some group of people, that obviously includes developer. It is not enough, and please, don't keep such things in the future in more or less closed circles of your pals. Even simple WARNING!!! Big changes, untested, not(yet) documented! would be nice. I know what arch~ _should_ mean, but you know what it actually means. So, a little bit of pragmatic flexibility here would certainly decrease amount of raining urine and improve Gentoo's likability. In any event, I don't intend to further this debate. Take it as a rant of some user that certainly can be wrong.
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
Mike Frysinger wrote: On Tuesday 13 October 2009 22:48:01 Branko Badrljica wrote: Mike Frysinger wrote: On Tuesday 13 October 2009 22:36:44 Branko Badrljica wrote: Mike Frysinger wrote: the mailing list is not bugzilla. any complaints you have about USE=oldnet have nothing to do with this thread. it's a bug and should be treated as such. Which is why I have posted here to gripe about having documented such changes in future. USE=oldnet is documented, end of story. you're complaining about a *bug*, not lack of documentation. stop mixing the two as you're only muddling this thread. Not really, but my fingers hurt. So, let's leave it at that, you were Right(tm) and I am misguided. I'm truly sorry for all the noise in you signal that i caused and wish you all the best. now that you've realized the error of your ways, i still dont see any bug reports in bugzilla about USE=oldnet. that leads me to conclude that testers have found no problems with it, only problems with USE=-oldnet. -mike And you won't see it from my hurting fingers. How can I trust my eyes and reason when I have you. Keep the God's Work - someone has to do it.
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
Joshua Saddler wrote: On Fri, 9 Oct 2009 19:57:07 +0200 Matthias Schwarzott z...@gentoo.org wrote: Hi there! As some of you have waited long for this to happen, sys-apps/openrc-0.5.1 is there. It has a default enabled (eapi-1) useflag oldnet to install the old-style network scripts called net.*. Regardless of this use-flag, the new init-script /etc/init.d/network is always installed. For transition to new-style network script there is something todo I think. Unordered list of todos: * hotplug? at least udev does explicitly call in net.* scripts * New systems should get old or new scripts? * does new scripts already can do all that was possible with net.* ? So far I hope the update does not break any system. In case this happens nevertheless open a bug as usual. Regards Matthias As long as this new version is ~arch (and not hardmasked), you also need to send some documentation updates for http://www.gentoo.org/doc/en/openrc-migration.xml; patches to bugs.gentoo.org, Documentation product. This way we in the GDP can take care of keeping the guide up-to-date. Thanks. I've just updated the system and it installed openrc-0.5.1. After reboot I have noticed that none of my network interfaces were configured ( lo,eth0). If it wasn't for this mail, it'd take a headache or two to figure out that init. script is new. But I still don't have a clue how to use it. I have started it, but it dd not seem to do anything. I thought that it would probably take settings from /etc/conf.d/net, but that doesn't seem to be the case, ande there is no other config in sight. Also, neither on gentoo.org or on roy.maples.name seem to be anything resembling documentation... Branko
[gentoo-dev] Has anyone tried to use Linux Unified Kernel ?
These gyus ( http://linux.insigma.com.cn/en/index.php ) are working on support for running Windows binaries in Linux kernel. It works by supporting Win syscalls directly in kernel or ( for unsupported ones ) by redirecting them to patched Wine server. Authors say that end effect is much less speed loss. Their previous versions were too limited and since they were written as a patch against vanilla-2.6.23, I had no luck trying them on anything newer. But latest version 0.24 is reportedly much closer to real deal. I could apply majority of the patches to gentoo-sources-2.6.29-r4 and I'm curious whether anyone here tried to fiddle with LUK and could post here final gentoo-ready version. Unfortunately, this version still doesn't support ext4, but this should come soon...
[gentoo-dev] Can't format floppy or write to it...
I needed to make bootable floppy for graphic card BIOS reflash and noticed that I can't fdformat floppy or even write to formatted one. I can mount it -o rw, but when I try to write, write would fail. Also, fdformat /dev/fd0 seems to be working, but just to the point,where it verifies written and fails on track 0. I have checked: - floppies for write protection ( it was off ) - for dirt on heads- I have cleaned floppy thoroughly - bad unit. Exchanged it with another, with exactly same result. - bad floppy disk. Tried a few other, with same result. Same disks formatted on another Windoze machine just fine. - bad access flags on /dev/fd0. ( Access: (0660/brw-rw) Uid: ( 0/ root) Gid: ( 11/ floppy) ) Here is output of fdformat /dev/fd0: LANG=en fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048 and here is dmesg | tail: Buffer I/O error on device fd0, logical block 32 end_request: I/O error, dev fd0, sector 288 Buffer I/O error on device fd0, logical block 36 end_request: I/O error, dev fd0, sector 308 Buffer I/O error on device fd0, logical block 38 end_request: I/O error, dev fd0, sector 333 Buffer I/O error on device fd0, logical block 41 end_request: I/O error, dev fd0, sector 45 Buffer I/O error on device fd0, logical block 5 Machine: Phenom 9950 Boartd Foxconn A7DA-S 8 Gig RAM. nVidia 8800GT with 1GiG RAM DDR3 DVD+ RW unit floppy 2x 500 Gb HDD SATA Gentoo 64-bit ( 2008.0-desktop profile ) pretty much latest version of everything kernel gentoo-sources-2.6.28-r1 Has anyone noticed anything remotely similar ? I can recall being able to use floppy normally with older 2.6.27 kernels, but can't try this now... Regards, Branko
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Duncan wrote: Branko Badrljica bran...@avtomatika.com posted 494f1518.2020...@avtomatika.com, excerpted below, on Mon, 22 Dec 2008 05:18:32 +0100: Maybe I should have filed this as a bug, but don't have a clue to which package should I assign it, if any. FWIW, this would have been a perfect question for the gentoo-desktop list, but doesn't really belong on the -dev list. There's also the gentoo-user list, altho that one has very heavy volume so you might not wish to subscribe there. Well, regarding the actual error, i think it might interest someone here, also. Although I mentioned just baselayout and openrc, I did check ( end reemerged etc) hal also, and it indeed emerged _without_ /etc/init.d/hald. I tracked it down to root cause: Although I don't use it, I have compiled-in selinux support ( and selinux=0 as kernel start parameter). When I was makeconfiging my kernel, I saw also SMACK support, read info and thought what the heck, it can't hurt me, but I might want to play with it, so I compiled-in that, too. Then after some time I realised that I never got to actually used all that and changed my config file by cutting out that all that security stuff. And recompiled all my kernels accordingly. Around that time I saw people recommending using tmpfs for /var/tmp as this would speed-up emerges etc, so I did that. I didn't know that while I was on SMACK (pun intended) , machine would add extended attr to every file machine would write. ( It was SMACK64 in security domain ). After cleaning my system, even though those attributes were still on all files, everything was fine until I actually tried to copy something from that FS to some other FS. /bin/cp would realise that there are extra security attrs on a file and would try to duplicate them on a copy. And since new kernel was without SMACK support, it would fail. When emerging stuff with /var/tmp on tmpfs, /bin/cp seems to get rarely used in such way when copying stuff into /var/tmp or maybe it was because distfiles were without SMACK attrs- so most ebuilds would seemingly sucseed. Most errors seem tho have been made when ebuild needed some local data, usually in /etc that had SMACK64 attr. If /bin/cp was used to get that data, it would fail, but this would not stop the ebuild. It would usually finished its work just as if nothing happened. Once I unmounted /var/tmp, ebuild could finish normally. Also, after removing security attr from all files, ebuild has started working normally from tmpfs partition again. It is also interesting that on 2.6.27* kernel ebuild fails sometimes and when it fails, it does so silently most of the time. With newest 2.6.28-rc9 i couldn't emerge a thing... Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge...
[gentoo-dev] what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Maybe I should have filed this as a bug, but don't have a clue to which package should I assign it, if any. I was forced to switch baselayout from stable 1.12.11* to 2.0.0, which triggered openrc install etc. I did all that etc , then after some time I noticed that system doesn't respond to PnP events. So I started looking around and have noticed that I have no /etc/init.d/hald and that hal daemon never gets called during boot. Then I tried to find alternate hald starting mechanism, but couldn't find any. I did emerge -pv system | grep hal and noticed that hal damon is not part of the system, but it is part of the world and it gets reemerged if I unmerge it, since 15-something packages depend on it throuh hal use flag. I took a peek at old and new baselayout and all openrc packages in tree I emerged ( 0.3 and 0.4.0). Their tar.bz2 files have nothing even remotely like /etc/init.d/hald Is this a bug or some kind of omission from my part ? Regards, Branko
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
While at it, it might be useful to have someghing like compiler-use file ( like package.use) for per-package compiler version and FLAGS to be used. It is annoying to have emerge -eD world fail because some package requires specific compiler version or because gcc-3.4 can't be compiled with -march=barcelona or with -combine CFLAGS... There should also be an option for the user to match compiler with compiler version, used to compile some other package. Perhaps with naming full name of the package instead of compiler name and version string in some file, like /etc/portage/package-infra.use or something like that. That approach could also be used for selecting specific version of perl/python/ruby/autotools/whatnot. ederico Ferri wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. please criticize this with anything constructive you can think of. thanks - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk9v14ACgkQV/B5axfzrPucugCfRN51KpJZ/HYCYA3v/Z2lAhaf 8eUAniZONnbWtN4f5CblJzaxEMbFWI3m =4l7H -END PGP SIGNATURE-
Re: [gentoo-dev] Re: ICC Profile
BTW: Is ICC really worth the fuss ? I have checked around and reported that newest gcc-4.3 is able to to catch and sometimes even outperform icc ( not always, naturally). Big news seemed to be thatnew gcc si close and sometimes better than icc. Is it any truth to that and if it is, what is the motive of having non-open icc option ? Adam Stylinski wrote: I actually know somebody working at intel, maybe he can get them more involved. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Michael Haubenwallner wrote: On Wed, 2008-04-16 at 07:34 +0100, Ciaran McCreesh wrote: snip Case D, Current Behaviour: User tries to upgrade coreutils. User gets a big flashy block error saying coreutils blocks mktemp. User doesn't realise that the safe upgrade path is to force the package manager to ignore the block, then manually uninstall mktemp straight afterwards. User instead uninstalls mktemp, which is a moderately critical binary. Or user uninstalls coreutils - yes, a colleague of mine actually did... /haubi/ So did I BTW. At the time, I understood the portage as if it wanted me to remove coreutils in order to be replaced by mktemp. Well, if thing says that it feels bothered by this blockage and would feel better if I removed it, I obliged it. Obviously, coreutils implied something with system importance, but I thought that portage feels confident about it, like it is going to be replaced with a mktemp in a second or two anyway and portage doesn't need ot for itself... Well, I was wrong, and had to make coreutils binpkg on main server and unpack it on blocked machine. Ofcourse, server was running selinux, so this emand borrowing also a few libs until I could revive portage... Regards -- gentoo-dev@lists.gentoo.org mailing list
