Re: rawhide report: 20050731 changes

On Sun, 2005-07-31 at 17:58 +0200, Andreas Mueller wrote:
> Rodd Clarkson wrote:
> > Is this being addressed?
> >
> > This seems to have become a problem around the 27 of July, but it's a
> > little strange.  The brokens deps on the 27th report this problem
> > too, but strangely, ppp wasn't among the updates on that day (unless
> > I'm looking at the wrong thing).
> 
> libpcap was updated, it is build from the tcpdump src.rpm.

Ah, HA.  I searched google, but i showed libpcap belonging to libpcap so
that explains that.

> > I'm just a little surprised that this is still an issue after four
> > (or five) updates.
> 
> I think ppp just needs a rebuild.

Presumably isdn4k-utils will need to be rebuilt too.

R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rawhide report: 20050731 changes

On 1/08/2005 11:05 a.m., Rodd Clarkson wrote:

>>> I'm just a little surprised that this is still an issue after four
>>> (or five) updates.
>> I think ppp just needs a rebuild.
> 
> Presumably isdn4k-utils will need to be rebuilt too.

As does ethereal:

[root <at> tornado dovecot]# rpm -V ethereal
Unsatisfied dependencies for ethereal-0.10.11-4.i386: libpcap.so.0.9.1

reuben

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Exec-shield and memory randomization

On Sun, 2005-07-31 at 19:46 +0200, Arjan van de Ven wrote:
> > . That it, they seem independent, but most of the
> > documentation on exec-shield I have seen seems to suggest that turning
> > off exec-shield should turn off just about everything and leave you with
> > a pretty standard system, ala the pre-exec-shield days. Is that no
> > longer true?
> 
> well.. randomisation is now merged upstream....

I'm not sure I understand. So that means "yes, they are now
independent" ?

So assuming that's the case, what does the kernel look for in
determining whether to turn of randomization on a per-binary basis? In
reading some older materials (like last year's Security Enhancements in
Red Hat Enterprise Linux paper by Drepper), it looked like the presence
of an explicitly executable stack segment in the ELF binary would turn
off all the various exec-shield enhancements, including randomization.
I'm guessing that this is still true for exec-shield, but does anything
now control randomization?

Running readelf and looking at the stack segment shows:

[dave <at> linux ~]$ readelf -l /usr/bin/sbcl | fgrep STACK
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

which as I understood it means that the stack is being marked as
executable (the "E" in the "RWE" field, right?).

So shouldn't this binary not be getting randomized memory addresses in

Re: Exec-shield and memory randomization

On Sun, Jul 31, 2005 at 04:27:16PM -0700, Dave Roberts wrote:
> On Sun, 2005-07-31 at 19:46 +0200, Arjan van de Ven wrote:
> > > . That it, they seem independent, but most of the
> > > documentation on exec-shield I have seen seems to suggest that turning
> > > off exec-shield should turn off just about everything and leave you with
> > > a pretty standard system, ala the pre-exec-shield days. Is that no
> > > longer true?
> > 
> > well.. randomisation is now merged upstream....
> 
> I'm not sure I understand. So that means "yes, they are now
> independent" ?
> 
> So assuming that's the case, what does the kernel look for in
> determining whether to turn of randomization on a per-binary basis?

Nowhere.. it's on for everything. The theory is that randomisation doesn't
do anything "odd" at all that couldn't happen otherwise. (by for example
upgrading a few libraries or so)
So I'd like to get to the bottom of why this app is breaking

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Yesterday's rawhide sunk my iBook

> What about the cleanup scripts or removing old files? Looks to me
> like all that is only done at the very end right now. Maybe completing
> individual package updates in one step before updating the next
> package should be an option for users.

again - once this is handed off to ts.run() yum only reports what rpm
does. so if this is going to be an option (which I think is a bit silly,
tbh) it would need to be supported in rpm, first.

-sv

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

rawhide report: 20050801 changes

Updated Packages:

MAKEDEV-3.19-4
--------------
* Sun Jul 31 2005 Florian La Roche <laroche <at> redhat.com>
- remove /dev/MAKEDEV to build with newest rpm

* Thu Jul 21 2005 Nalin Dahyabhai <nalin <at> redhat.com> 3.19-3
- rebuild

* Thu Jul 21 2005 Nalin Dahyabhai <nalin <at> redhat.com> 3.19-2
- move usb-specific config file out, go with the mainline devices-2.6+.txt file
- update to 12 May devices-2.6+.txt:
  - add usb/legousbtower
  - add xvd
  - rename ttyIOC4 to ttyIOC
  - add 32 more ttyIOC nodes
  - add ttySIOC

am-utils-5:6.0.9-13
-------------------
* Sun Jul 31 2005 Florian La Roche <laroche <at> redhat.com>
- package all symlinks to libs

compat-slang-1.4.5-11
---------------------
* Sun Jul 31 2005 Florian La Roche <laroche <at> redhat.com>
- build with newest rpm

Re: Firefox seems to crash on middle clicks to various parts of the browser window.

Rodd Clarkson <rodd <at> clarkson.id.au> wrote:
> Anyone else seeing situations where firefox (deerpark) is crashing when
> you middle click on things?

Yep. Happens at random here.

firefox-1.1-0.2.5.deerpark.alpha2
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164726
> 
> 
> Rodd
> -- 
> "It's a fine line between denial and faith.
>  It's much better on my side"
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list <at> redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

new mach release

Hi everyone,

after some prerelease testing, a final mach 0.4.7 release has been made.
Please find the release notes attached.

This version works with either apt or yum, and works with selinux
enabled.

I'm still looking for people interested in discussing the refactoring of
mach into a more pythonic project (work going on in the mach3 directory
in cvs) - I need people to discuss ideas and approaches with.

Meanwhile, a package for Fedora Extras should soon be hitting the
repository.

Enjoy,
Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I love the way you love
but I hate the way
I'm supposed to love you back
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/

mach - make a chroot - RELEASE NOTES
------------------------------------

Re: SuperSavage/IXC 64 hassle making DRI and SELinux work together

Hi Dan,

thanks a lot for pointing this out. However, this seems to be due to
"SELinux" being work in progress. I have reinstalled FC4 from scratch,
installed alle available updates, and still obtain the same AVC messages
without even touching DRI. However, here the good news: after reinstalling
FC4 from scratch, both of "xorg-x11-6.8.2-37" (FC4 updates) and
"xorg-x11-6.8.99.16-0.homebrewn" (derived from M. Harris unstable
"xorg-x11-6.8.99.14-3" SRPM) allow for direct rendering even when "SELinux"
is active. The latter has the advantage of being up to date in terms of
OpenGL compatibility. It seems that the successive updates of various
packages, probably "audit" and "selinux-policy-targeted", messed up the
system. I still have the "mtrr: base(0xe4000000) is not aligned on a
size(0x5000000) boundary" warning, but apparently, it does not matter.

Cheers,

-Joachim

> This looks like you have some kind of labeleing problem.  utmp is
> labled  init_var_run_t, it should be initrc_var_run_t
> You may want to relabel.
> Have you tried to boot with enforcing=0?
>
> Dan
>
> --
>
>
> --

rawhide report: 20050802 changes

New package scim-anthy
	SCIM IMEngine for anthy for Japanese input

New package scim-tables
	SCIM Generic Table IMEngine

 
Updated Packages:

GConf-1.0.9-17
--------------
* Sun Jul 31 2005 Florian La Roche <laroche <at> redhat.com>
- remove gconftool to build with newest rpm

* Wed Mar 02 2005 Mark McLoughlin <markmc <at> redhat.com> 1.0.9-16
- Rebuild with gcc4

* Fri Aug 06 2004 Tim Waugh <twaugh <at> redhat.com> 1.0.9-15
- Fixed underquoted m4 definitions.

anthy-6700b-2
-------------
* Mon Aug 01 2005 Akira TAGOH <tagoh <at> redhat.com> - 6700b-2
- added Provides: anthy-libs = %{name}-%{version}

arts-8:1.4.2-1
--------------
* Mon Aug 01 2005 Than Ngo <than <at> redhat.com> 8:1.4.2-1
- update to 1.4.2