Re: [gentoo-dev] USE=-ipv6 in the hardened profile

[Anthony G. Basile]

On 02/08/2011 02:56 PM, Jan Kundrát wrote:
> Hi,
> current hardened profile sets USE=-ipv6, but I wasn't able to find any
> reason for that in the ChangeLogs. With the upcoming v6 frenzy, I was
> wondering if we can remove that default.
>
> With kind regards,
> Jan
>
 I don't know of any reason and all my hardened servers have it, so
yeah, its a good idea.  Let me do some more investigating to make sure
I'm not missing anything and then I'll add it.

-- 
Anthony G. Basile, Ph.D.
Gentoo Developer

[gentoo-dev] Re: Policy for conflicting USE flags

[Ryan Hill]

On Tue, 8 Feb 2011 22:29:11 +0100
Ulrich Mueller  wrote:

> EAPI 4 introduced the REQUIRED_USE variable, which allows to impose
> restrictions on the allowed USE flag combinations for an ebuild.
> 
> On the other hand, according to the devmanual, our policy on
> conflicting USE flags is as follows:
> 
> | 
> 
> | Occasionally, ebuilds will have conflicting USE flags for
> | functionality. Checking for them and returning an error is not a
> | viable solution. Instead, you must pick one of the USE flags in
> | conflict to favour and should alert the user that a particular flag
> | is being used instead.
> 
> Is this policy still valid, which would imply that REQUIRED_USE
> should be used only sparingly? Or should it be used in all cases of
> conflicting flags?
> 
> As an example for the two extreme cases, the app-editors/emacs-23.2-r3
> ebuild currently has only the following minimal solution:
> 
>REQUIRED_USE="aqua? ( !X )"
> 
> Whereas with taking account of all conflicts, it would look like this:
> 
>REQUIRED_USE="
>   alsa? ( sound )
>   X? (
>   !aqua
>   m17n-lib? ( xft )
>   ^^ (
>   gtk
>   motif
>   Xaw3d
>   ( !gtk !motif !Xaw3d )
>   )
>   toolkit-scroll-bars? ( || ( gtk motif Xaw3d ) )
>   )
>   !X? (
>   !gconf
>   !gif
>   !gtk
>   !imagemagick
>   !jpeg
>   !libxml
>   !m17n-lib
>   !motif
>   !png
>   !svg
>   !tiff
>   !toolkit-scroll-bars
>   !Xaw3d
>   !xft
>   !xpm
>   )"
> 
> If we really implemented it in this way, then I fear that it would be
> difficult for users to find out what flag combinations they can use.
> (As was pointed out in bug 347353, it is a satisfiability problem,
> which in the general case is NP-complete ...)
> 
> Some possible middle ground would block only combinations that lead
> to surprising results for the user. (Using the above example again,
> one would allow only one of "gtk", "Xaw3d", and "motif". But with
> USE="-X", one would simply ignore flags like "png" or "jpeg", because
> it can't be surprising that images can't be displayed without X.)
> 
> So, what policy should we follow here?

The guideline I usually follow is that flags depending on another flag being
set (eg. png needs X) should be ignored (you can always ewarn).  For flags
that conflict with other flags (exactly one of many, if-this-not-this) use
REQUIRED_USE.  Does that make sense?

If we went with your second extreme, if I wanted to disable X for emacs, I'd
also have to add 10 additional flags to package.use on my system to get it to
work.  If we were doing that for every package I'd switch distros.


-- 
fonts, gcc-porting,  it makes no sense how it makes no sense
toolchain, wxwidgets   but i'll take it free anytime
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

[gentoo-dev] Re: glibc-2.13 news item?

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


-- 
fonts, gcc-porting,  it makes no sense how it makes no sense
toolchain, wxwidgets   but i'll take it free anytime
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

[gentoo-dev] Policy for conflicting USE flags

[Ulrich Mueller]

EAPI 4 introduced the REQUIRED_USE variable, which allows to impose
restrictions on the allowed USE flag combinations for an ebuild.

On the other hand, according to the devmanual, our policy on
conflicting USE flags is as follows:

| 

| Occasionally, ebuilds will have conflicting USE flags for
| functionality. Checking for them and returning an error is not a
| viable solution. Instead, you must pick one of the USE flags in
| conflict to favour and should alert the user that a particular flag
| is being used instead.

Is this policy still valid, which would imply that REQUIRED_USE
should be used only sparingly? Or should it be used in all cases of
conflicting flags?

As an example for the two extreme cases, the app-editors/emacs-23.2-r3
ebuild currently has only the following minimal solution:

   REQUIRED_USE="aqua? ( !X )"

Whereas with taking account of all conflicts, it would look like this:

   REQUIRED_USE="
alsa? ( sound )
X? (
!aqua
m17n-lib? ( xft )
^^ (
gtk
motif
Xaw3d
( !gtk !motif !Xaw3d )
)
toolkit-scroll-bars? ( || ( gtk motif Xaw3d ) )
)
!X? (
!gconf
!gif
!gtk
!imagemagick
!jpeg
!libxml
!m17n-lib
!motif
!png
!svg
!tiff
!toolkit-scroll-bars
!Xaw3d
!xft
!xpm
)"

If we really implemented it in this way, then I fear that it would be
difficult for users to find out what flag combinations they can use.
(As was pointed out in bug 347353, it is a satisfiability problem,
which in the general case is NP-complete ...)

Some possible middle ground would block only combinations that lead
to surprising results for the user. (Using the above example again,
one would allow only one of "gtk", "Xaw3d", and "motif". But with
USE="-X", one would simply ignore flags like "png" or "jpeg", because
it can't be surprising that images can't be displayed without X.)

So, what policy should we follow here?

Ulrich

[gentoo-dev] USE=-ipv6 in the hardened profile

[Jan Kundrát]

Hi,
current hardened profile sets USE=-ipv6, but I wasn't able to find any
reason for that in the ChangeLogs. With the upcoming v6 frenzy, I was
wondering if we can remove that default.

With kind regards,
Jan



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Please review: updates for bzr.eclass

[James Cloos]

> "UM" == Ulrich Mueller  writes:

>> but please mv(1) old repos rather than rm(1)ing them;

UM> Is the following better?
UM> 


That looks perfect.

Thanks!

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] avoiding urgent stabilizations

[Donnie Berkholz]

On 12:37 Tue 08 Feb , Rich Freeman wrote:
> On Feb 8, 2011 11:44 AM, "Donnie Berkholz"  wrote:
> > (With exceptions for security issues.)
> 
> Other than monitoring bugzilla, how does a Gentoo user even know that 
> they have a package pending a security update?  It seems like glsa's 
> lag stabilization by a considerable timeframe.

I read LWN's security page and ensure updates happen, regardless of 
whether the ebuild exists yet.

But if I didn't, I would rely on GLSAs — either via the mailing list or 
with a daily sync and glsa-check.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpKFWCifmVrx.pgp
Description: PGP signature

Re: [gentoo-dev] avoiding urgent stabilizations

[Andreas K. Huettel]

On Tuesday 08 February 2011 18:57:20 Fabian Groffen wrote:
> On 08-02-2011 18:46:32 +0100, Andreas K. Huettel wrote:
> > > Other than monitoring bugzilla, how does a Gentoo user even know that they
> > > have a package pending a security update?  It seems like glsa's lag
> > > stabilization by a considerable timeframe.
> > 
> > Yep. GLSA is something that seems to happen roughly one year after no 
> > affected package is in tree anymore. 
> 
> Well, it's not too bad lately:
> http://archives.gentoo.org/gentoo-announce/
> 

Hmm. Maybe I should just subscribe to gentoo-announce again... :]

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfri...@gentoo.org
http://www.akhuettel.de/


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] avoiding urgent stabilizations

[Fabian Groffen]

On 08-02-2011 18:46:32 +0100, Andreas K. Huettel wrote:
> > Other than monitoring bugzilla, how does a Gentoo user even know that they
> > have a package pending a security update?  It seems like glsa's lag
> > stabilization by a considerable timeframe.
> 
> Yep. GLSA is something that seems to happen roughly one year after no 
> affected package is in tree anymore. 

Well, it's not too bad lately:
http://archives.gentoo.org/gentoo-announce/


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] avoiding urgent stabilizations

[Andreas K. Huettel]

> Other than monitoring bugzilla, how does a Gentoo user even know that they
> have a package pending a security update?  It seems like glsa's lag
> stabilization by a considerable timeframe.

Yep. GLSA is something that seems to happen roughly one year after no affected 
package is in tree anymore. 

[Sorry, no offense intended. I know we're all understaffed...]

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfri...@gentoo.org
http://www.akhuettel.de/


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] avoiding urgent stabilizations

[Rich Freeman]

On Feb 8, 2011 11:44 AM, "Donnie Berkholz"  wrote:
>
> (With exceptions for security issues.)

Other than monitoring bugzilla, how does a Gentoo user even know that they
have a package pending a security update?  It seems like glsa's lag
stabilization by a considerable timeframe.

I get the impression that half the reason for this is due to the difficulty
of generating the xml files.

Re: [gentoo-dev] avoiding urgent stabilizations

[Donnie Berkholz]

On 13:22 Tue 08 Feb , Fabian Groffen wrote:
> With Gentoo you should update on fairly regular intervals, and have 
> the time inbetween as short as possible, but 2 or 3 weeks appears to 
> be fine.  I myself have a cronjob that syncs every night, and mails me 
> the output of emerge -Dupv world.  When this list gets too large, it's 
> typically about time to do some updating.

FWIW, in experience from my past two positions, updates to "critical" 
systems at least quarterly, and no more than monthly, seem to produce 
good results that balance effort and stability.

(With exceptions for security issues.)

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgp1Jg4PAhd9O.pgp
Description: PGP signature

Re: [gentoo-dev] avoiding urgent stabilizations

[Rich Freeman]

On Tue, Feb 8, 2011 at 7:03 AM, Markos Chandras  wrote:
> I see what you are saying. However, the 6 months testing is far from
> what I have in mind.

I could see there being room for something in-between, but I share the
concerns of others that rolling releases are part of what makes
Gentoo, well, Gentoo.

The problem with snapshots is that there is almost always SOMETHING
wrong with them, and if you don't release until they're near-perfect
then you're pursing 99.999% quality and most devs don't care enough to
work hard towards that.  As a result you end up with very long release
cycles.

I could see room for a system where every week a portage snapshot is
created, and then run through automated testing.  The test results are
then posted, and the release tarball is made available for download.
Then people can update to it if they think it is good enough.  Serious
issues would of course be spotted and immediately fixed in-tree so
that the next weekly release is better, and the typical user
experience would still be to use the live tree so that they get an
experience similar to what they have.

Honestly, I don't even know that this would really work well.  It
might be better to just have a tinderbox that does automated full-tree
testing weekly and just post the results and let devs look at them and
fix things.

However, I don't think any system is likely to work (except on Debian
timelines) if it involves a release-when-its-ready approach unless
ready is something really minimal like "system set compiles and
boots."

Time vs quality vs cost - pick two.  Oh, for Gentoo we've pretty-much
picked cost as being about as close to zero as you can get, so make
that pick one.  Debian stable favors quality, and there are definitely
things I'd use debian for that I'd never use Gentoo for.  That isn't
knocking Gentoo - it is just a reflection of the fact that the distros
have different philosophies.

Re: [gentoo-dev] avoiding urgent stabilizations

[Roy Bamford]

Markos,

A few thoughts inlined.

On 2011.02.08 12:03, Markos Chandras wrote:
 
My main point was that as you move from an old dated set of packages to 
newer packages which by definition are less well tested, stability 
decreases. Users pick somewhere between the two extremes that they are 
happy with. Gentoo stable lies somewhere between Debian stable and LFS 
built live from all the repositories.

> I see what you are saying. However, the 6 months testing is far from
> what I have in mind. 
Thats what releng used to take.

> My only intention is to bring a more stable
> experience to our users. Or, stop claiming that our stable tree rocks
> and Gentoo is perfect for servers because it is not. Ye ye ye I know
> that many many of you have Gentoo on servers but do not forget that
> you
> are developers and you know your way around during breakages. Yes,
> stable tree breaks FAR TOO often. I blame myself for my arch testing
> of
> course however I can't do much about that. 
[snip]

For servers I can point you at the stillborn Gentoo-LAMP project. I 
don't remember much more than its name. Google seems to have forgotten 
it too.

A big part of the problem comes from being a meta-distro. Everyones 
Gentoo is different and we we cannot test all combinations to ensure 
everyone is ok.

More testing will not eliminate the issue but would catch some 
problems. There would be less breakage but not zero.  There is a trade 
off to be made there by both the developers doing the testing and 
the users experiencing the breakage.

I agree that given more resources, the tree could be improved but 
before we move in that direction, I would like to ask is that the best 
use of resources?

As I said above, users are aware of the trade offs involved in choosing 
Gentoo. Are our users really unhappy, or are they just looking for help 
to fix issues when they occur?
Most users do not expect a zero issue upgrade path.

[snip]
> 
> Our stable tree is definitely not suitable for server usage unless 
> you have plenty of free time to
> deal with stupid upgrades because nobody, for example, cared to write
> a
> proper elog or news item. 
[snip]
> 
> Either you like it or not, arch teams are understaffed. All of them.
All of Gentoo is understaffed.

> Therefore we cannot afford a updated stable tree with high QA around
> it. We need to find a more efficient way to test packages on testing
> tree so we can mark them stable with minimal time and cpu cost. We
> need
> dedicated build boxes, like Diego's tinderbox, to test the testing
> tree
> over and over against critical/common/trivial QA problems. If we
> manage
> that, moving packages from testing->stable will be much more time
> efficient and we can guarantee a high quality stable tree.
If this means a more up to date stable tree, that has to be good as the 
stable tree will move closer to testing and there will be fewer 
packages to maintain.  (Counting different versions as packages)
> 
> ps1: Personally I have stopped suggesting gentoo stable for server
> usage
> and I always suggest testing to new users.

I don't quite agree about not recommending Gentoo for servers. Gentoo 
is fine on servers but you need to run a testing environment for your 
updates so you know when you do do an update, exactly what in involved 
and what will happen.  Without your own testing, your server will go 
down from time to time. If you cannot do your own testing, either 
tolerate the downtime or don't use Gentoo.

> 
> ps2: Roy, this is not a personal attack. Do not misinterpret my tone
> :)

I see no personal attack in your words. 
> 
> Regards,
> -- 
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
> 
I'll buy you a  next time we meet.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgp1kdwTwgef8.pgp
Description: PGP signature

Re: [gentoo-dev] avoiding urgent stabilizations

[Paweł Hajdan, Jr.]

tl;dr - can we add more automated tests to auto-generated stages?

On 2/8/11 1:22 PM, Fabian Groffen wrote:
> Hmmm, odd.  I experience amd64 (stable) as being pretty stable on my 
> servers.  Last breakage which really got me upset was php, but
> that's already some time ago.

Makes sense. Most of the breakages I had in mind when starting this
thread were related to consolekit/policykit/login manager/de breakages,
or some desktop software not compiling with an updated gcc. Those issues
generally don't affect servers.

By the way, to turn this thread into some action: what testing do we
currently perform for auto-generated stages? It'd be cool to at least
compile-test that the stage can "emerge -e world" itself, and emerge
some common packages (with FEATURES="test" so that we run at least some
of the produced code).

> With Gentoo you should update on fairly regular intervals, and have
> the time inbetween as short as possible, but 2 or 3 weeks appears to
> be fine.  I myself have a cronjob that syncs every night, and mails
> me the output of emerge -Dupv world.  When this list gets too large,
> it's typically about time to do some updating.

Sounds like a good idea. I think I'll start using it.

> I have masked new major releases of PostgreSQL and MySQL for
> instance, and of course Python 3.

Yeah, this ease of masking is a great strength of Gentoo.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] avoiding urgent stabilizations

[Fabian Groffen]

On 08-02-2011 12:03:48 +, Markos Chandras wrote:
> I see what you are saying. However, the 6 months testing is far from
> what I have in mind. My only intention is to bring a more stable
> experience to our users. Or, stop claiming that our stable tree rocks
> and Gentoo is perfect for servers because it is not. Ye ye ye I know
> that many many of you have Gentoo on servers but do not forget that you
> are developers and you know your way around during breakages. Yes,
> stable tree breaks FAR TOO often. I blame myself for my arch testing of

Hmmm, odd.  I experience amd64 (stable) as being pretty stable on my
servers.  Last breakage which really got me upset was php, but that's
already some time ago.

> Our stable tree is definitely not suitable for server usage unless 
> you have plenty of free time to
> deal with stupid upgrades because nobody, for example, cared to write a
> proper elog or news item. You are probably not aware of that, since 99%
> of you run testing tree however if you visit forums and stuff you will
> see many many users complaining about stable tree. If we keep going down

With Gentoo you should update on fairly regular intervals, and have the
time inbetween as short as possible, but 2 or 3 weeks appears to be
fine.  I myself have a cronjob that syncs every night, and mails me the
output of emerge -Dupv world.  When this list gets too large, it's
typically about time to do some updating.

I think it is just regular sysadmin work to evaluate the list of
packages that's going in, and whether you deem that necessary.  I have
masked new major releases of PostgreSQL and MySQL for instance, and of
course Python 3.  I keep the rest updated, and in this way, I can only
say that I experience Gentoo to be definitely suitable for server usage,
with only little time caring about them.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] avoiding urgent stabilizations

[Markos Chandras]

On Tue, Feb 08, 2011 at 11:43:33AM +, Roy Bamford wrote:
> On 2011.02.07 20:50, Markos Chandras wrote:
> [snip]
> 
> > My suggestion, as I said to fosdem, is to freeze, or take a
> > snapshot if you like, of the current tree, stabilize what you need to
> > stabilize, test the whole tree ( at least compile wise ) for a couple
> > of weeks and then replace the existing stable tree. Of course this
> > requires automated script testing, hardware facilities etc etc that 
> > we don't have so claiming that stable tree is "stable" is quite 
> > wrong.
> > 
> > Regards,
> > -- 
> > Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
> > 
> 
> Markos,
> 
> This is exactly what releng used to do for installer CDs.  This was 
> last used for 2008.0 CD/DVD. A snapshot of the stable tree was taken in 
> February 200.8 and the release hit the mirrors in September.
> 
> The seven month test/fix/retest that it took meant that the CD would 
> not boot on new hardware as the kernel lacked drivers.
> 
> You will find similar lags when releng used this approach for other 
> earlier releases.
> 
> We would need to move to a release cycle like the kernel. Calling a 
> feature freeze at the start of the test cycle. As we can't everything, 
> we might as well distribute binaries of what was tested - just as 
> releng used to do. 
> 
> To me thats not Gentoo as we would loose the rolling updates.
>  
> There are degrees of stable.  I believe most Gentoo users 
> realise this fairly early on and stick with Gentoo because they like 
> the balance it strikes between Debian stable and bleeding edge.
> There is a price to pay for being more up to date and it a trade off 
> Gentoo users are aware off. Of course, that does not prevent them 
> bringing breakages to our attention. 
> 
> -- 
> Regards,
> 
> Roy Bamford
> (Neddyseagoon) a member of
> gentoo-ops
> forum-mods
> trustees

Roy, 

I see what you are saying. However, the 6 months testing is far from
what I have in mind. My only intention is to bring a more stable
experience to our users. Or, stop claiming that our stable tree rocks
and Gentoo is perfect for servers because it is not. Ye ye ye I know
that many many of you have Gentoo on servers but do not forget that you
are developers and you know your way around during breakages. Yes,
stable tree breaks FAR TOO often. I blame myself for my arch testing of
course however I can't do much about that. Arch teams cannot afford any
slacking (at least the two major arches) because we have 100 new bugs
every three days. This is extremely dangers to demotivate people who
will burn out sooner or later. You may think that this is an extreme
case but I can guarantee you that amd64 stable tree can become really
obsolete within one month. . 

Our stable tree is definitely not suitable for server usage unless 
you have plenty of free time to
deal with stupid upgrades because nobody, for example, cared to write a
proper elog or news item. You are probably not aware of that, since 99%
of you run testing tree however if you visit forums and stuff you will
see many many users complaining about stable tree. If we keep going down
this road we will end up sooner or later to be similar to Exherbo where
only really power users and developers will know their way around. 

Either you like it or not, arch teams are understaffed. All of them.
Therefore we cannot afford a updated stable tree with high QA around
it. We need to find a more efficient way to test packages on testing
tree so we can mark them stable with minimal time and cpu cost. We need
dedicated build boxes, like Diego's tinderbox, to test the testing tree
over and over against critical/common/trivial QA problems. If we manage
that, moving packages from testing->stable will be much more time
efficient and we can guarantee a high quality stable tree.

ps1: Personally I have stopped suggesting gentoo stable for server usage
and I always suggest testing to new users.

ps2: Roy, this is not a personal attack. Do not misinterpret my tone :)

Regards,
-- 
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


pgp2plyh7a28v.pgp
Description: PGP signature

Re: [gentoo-dev] avoiding urgent stabilizations

[Roy Bamford]

On 2011.02.07 20:50, Markos Chandras wrote:
[snip]

> My suggestion, as I said to fosdem, is to freeze, or take a
> snapshot if you like, of the current tree, stabilize what you need to
> stabilize, test the whole tree ( at least compile wise ) for a couple
> of weeks and then replace the existing stable tree. Of course this
> requires automated script testing, hardware facilities etc etc that 
> we don't have so claiming that stable tree is "stable" is quite 
> wrong.
> 
> Regards,
> -- 
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
> 

Markos,

This is exactly what releng used to do for installer CDs.  This was 
last used for 2008.0 CD/DVD. A snapshot of the stable tree was taken in 
February 200.8 and the release hit the mirrors in September.

The seven month test/fix/retest that it took meant that the CD would 
not boot on new hardware as the kernel lacked drivers.

You will find similar lags when releng used this approach for other 
earlier releases.

We would need to move to a release cycle like the kernel. Calling a 
feature freeze at the start of the test cycle. As we can't everything, 
we might as well distribute binaries of what was tested - just as 
releng used to do. 

To me thats not Gentoo as we would loose the rolling updates.
 
There are degrees of stable.  I believe most Gentoo users 
realise this fairly early on and stick with Gentoo because they like 
the balance it strikes between Debian stable and bleeding edge.
There is a price to pay for being more up to date and it a trade off 
Gentoo users are aware off. Of course, that does not prevent them 
bringing breakages to our attention. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpXWHwIwNyRh.pgp
Description: PGP signature

Re: [gentoo-dev] glibc-2.13 news item?

[Andreas K. Huettel]

Might be useful also because of some other new features, e.g. memcpy copying 
backwards (no joke).



On Tuesday 08 February 2011 09:52:55 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?
> 
> 

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfri...@gentoo.org
http://www.akhuettel.de/
--- Begin Message ---

Hi, 

Just for your information, this came up on kde-packagers ml... seems that 
glibc-2.13 does memcpy backwards under certain circumstances (no joke), 
breaking broken software even more. 

We'll probably see some surprises once you place it in the tree... 
Cheers, Andreas

http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278
http://sourceware.org/git/?p=glibc.git;a=commit;h=6fb8cbcb58a29fff73eb2101b34caa19a7f88eba

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

--- Begin Message ---
Howdy,

Due to the way memcpy() is implemented in some newer glibc [1],
users may experience crashes in the KDE imap4 ioslave.

Thanks to a patch contributed by a nice person, I have committed
a fix to both the 4.5 and 4.6 versions of kdepimlibs.

The file in question is kdepimlibs/kioslave/imap4/imap4.cpp

The SVN revisions are:
kdepimlibs 4.5 => r1216162
kdepimlibs 4.6 => r1216163

You might consider pushing a hotfix for this.
Regards,
Allen

[1] http://lwn.net/Articles/414467


___
Kde-packager mailing list
kde-packa...@kde.org
https://mail.kde.org/mailman/listinfo/kde-packager
--- End Message ---


signature.asc
Description: This is a digitally signed message part.
--- End Message ---


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] glibc-2.13 news item?

[Paweł Hajdan, Jr.]

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?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] avoiding urgent stabilizations

[Paweł Hajdan, Jr.]

On 2/8/11 9:24 AM, Markos Chandras wrote:
> On Mon, Feb 07, 2011 at 10:02:36PM +0100, "Paweł Hajdan, Jr." wrote:
>> There are machines available for various arches at
>> . I have
>> at least a few chromium-related chroots on miranda, and I've never heard
>> complaints, so it seems a few more chroots for arch testing wouldn't hurt.
>>
> No. Miranda, in particular, can go down anytime soon. This is what infra
> told me twice. 

Oh, they didn't tell me that. What's the problem with miranda?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] avoiding urgent stabilizations

[Markos Chandras]

On Mon, Feb 07, 2011 at 10:02:36PM +0100, "Paweł Hajdan, Jr." wrote:
> On 2/7/11 9:50 PM, Markos Chandras wrote:
> > My suggestion, as I said to fosdem, is to freeze, or take a
> > snapshot if you like, of the current tree, stabilize what you need to
> > stabilize, test the whole tree ( at least compile wise ) for a couple of
> > weeks and then replace the existing stable tree. Of course this requires
> > automated script testing, hardware facilities etc etc that we don't have
> > so claiming that stable tree is "stable" is quite wrong.
> 
> This more thorough testing sounds really interesting. But do we really
> lack hardware resources?
>
Yes!
> There are machines available for various arches at
> . I have
> at least a few chromium-related chroots on miranda, and I've never heard
> complaints, so it seems a few more chroots for arch testing wouldn't hurt.
> 
No. Miranda, in particular, can go down anytime soon. This is what infra
told me twice. 

> Of course for testing bootability and whether X11 starts up correctly,
> etc we'd probably have to host some virtual machines, but better compile
> testing (for example for toolchain updates) would be a good start.
> 
> Paweł
> 
Lets move this conversation on the thread that Tim started earlier
today. Seems like there is some hardware available for us on OSUOSL

Regards,
-- 
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


pgpKH5be3N1th.pgp
Description: PGP signature