Re: [gentoo-dev] Re: GCC 4.6.0

2011-04-03 Thread Branko Badrljica
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...

2010-11-23 Thread Branko Badrljica

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...

2010-11-22 Thread Branko Badrljica

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...

2010-11-22 Thread Branko Badrljica

Erm, link is http://cobra-language.com http://cobra-language.com/


[gentoo-dev] Cobra as a Python replacement for portage infra...

2010-11-22 Thread Branko Badrljica

( 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

2009-10-13 Thread Branko Badrljica

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

2009-10-13 Thread Branko Badrljica

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

2009-10-13 Thread Branko Badrljica

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

2009-10-13 Thread Branko Badrljica

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

2009-10-13 Thread Branko Badrljica

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

2009-10-13 Thread Branko Badrljica

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

2009-10-13 Thread Branko Badrljica

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

2009-10-10 Thread Branko Badrljica

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 ?

2009-05-24 Thread Branko Badrljica
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...

2009-02-09 Thread Branko Badrljica
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 ?

2008-12-22 Thread Branko Badrljica
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 ?

2008-12-21 Thread Branko Badrljica
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

2008-12-08 Thread Branko Badrljica
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

2008-07-18 Thread Branko Badrljica

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?

2008-04-16 Thread Branko Badrljica

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