Re: dist-git proof of concept phase 1 complete

[Adam Miller]

+1 to Adam W because I'm an ultra git neophyte (and a CVS one for that
matter) but the current make file automation essentially removes that as an
issue. I'm not saying I'm against learning git if need be, but I agree that
it would be an unfortunate regression.

-Adam (From Android - CM)

On Dec 16, 2009 4:27 PM, "Adam Williamson"  wrote:

On Wed, 2009-12-16 at 10:42 -0500, Simo Sorce wrote: > But for anyone that
does not using "master" ...
I would hope you don't have to. To be a Fedora maintainer you hardly
have to know a thing about CVS, after all - you can do all common
operations via the Makefiles. I would hope the fpkg (or whatever) tool
will do the same for the git-based system; if not, I'd consider that a
significant regression.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- fedora-devel-list mailing list fedora-devel-list@redhat.com
https://www.redhat.com/mailman/list...
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: dist-git proof of concept phase 1 complete

[Jesse Keating]

On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote:
> git://publictest5.fedoraproject.org/git/pkgs/  eg if you wished
> to clone the kernel, you'd type:
> 
> git clone git://publictest5.fedoraproject.org/git/pkgs/kernel 

Just an FYI, the hostname (and path) changed slightly.

git clone git://pkgs.stg.fedoraproject.org/kernel

I hope to have ssh authenticated push support ready in the next day or
so, complete with the same ACLs we have currently with CVS.  I could use
a lot of people cloning and committing to test the performance of the
ACL system.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Outage Notification - 2009-12-19 02:00 UTC

[Mike McGrath]

Sorry everyone, I was off by a day.  I've updated it.

-Mike



On Thu, 17 Dec 2009, Mike McGrath wrote:

> There will be an outage starting at 2009-12-19 02:00 UTC, which will
last
> approximately 2 hours.
>
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
>
> date -d '2009-12-19 02:00 UTC'
>
> Affected Services:
>
> Buildsystem
> CVS / Source Control
> Database
> Fedora Hosted
> Mail
> Mirror System
> Translation Services
> Websites
>
> Unaffected Services:
> Torrent
> DNS
> Fedora People
> Fedora Talk
>
> Ticket Link:
>
> https://fedorahosted.org/fedora-infrastructure/ticket/1884
>
> Reason for Outage:
> We have a lot of temporary solutions in place from the move, we're moving
> things back to their more permanents solutions.  The main outages won't
> last the full two hours.  The vpn setup should only takes 10-20 minutes.
> The db1 migration will take at least an hour though.
>
>
> Contact Information:
>
> Please join #fedora-admin in irc.freenode.net or respond to this email to
> trackthe status of this outage.
>
> ___
> Fedora-devel-announce mailing list
> fedora-devel-annou...@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-announce
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Outage Notification - 2009-12-18 02:00 UTC

[Mike McGrath]

There will be an outage starting at 2009-12-18 02:00 UTC, which will last
approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2009-12-18 02:00 UTC'

Affected Services:

Buildsystem
CVS / Source Control
Database
Fedora Hosted
Mail
Mirror System
Translation Services
Websites

Unaffected Services:
Torrent
DNS
Fedora People
Fedora Talk

Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/1884

Reason for Outage:
We have a lot of temporary solutions in place from the move, we're moving
things back to their more permanents solutions.  The main outages won't
last the full two hours.  The vpn setup should only takes 10-20 minutes.
The db1 migration will take at least an hour though.


Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to
trackthe status of this outage.

___
Fedora-devel-announce mailing list
fedora-devel-annou...@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: 190 packages with .la file(s)

[Christoph Wickert]

Am Montag, den 30.11.2009, 14:42 +0100 schrieb Pierre-Yves:

> If I run:
> for i in $(repoquery --disablerepo=rpmfusion\* -f "*.la"
> --qf="%{name}.%{arch}" | grep "x86_64" | sort | uniq); do repoquery -s
> $i; done | sort | uniq 

> exo-0.3.105-1.fc12.src.rpm

fixed

> gtkglextmm-1.2.0-10.fc12.src.rpm

I took it over while ago because it's a dep of one of my packages. Need
to look into that deeper.

> xfce4-session-4.6.1-3.fc12.src.rpm

fixed

Christoph

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Adam Williamson]

On Thu, 2009-12-17 at 22:08 +0100, nodata wrote:

> Here is my point: Windows requires a reboot less often than Linux. Argue 
> all you want, it's true.

It's entirely false, because Linux *never* requires a reboot. Fedora
(not Linux, you are generalizing too far) *advises* reboots, it never
requires them. Windows forces you to reboot - literally, you cannot
prevent it from rebooting when it decides you have to.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Review swaps

[Josephine Tannhäuser]

2009/12/17, Peter Robinson :
> Anyone interested in swapping a couple of package reviews?
I currently try to review 2 of your previous review request. you
should finish them first

-- 
Josephine "Fine" Tannhäuser
2.6.31.5-127.fc12.i686.PAE

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

RE: packages requiring me to reboot...

[Otto Haliburton]

> -Original Message-
> From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
> boun...@redhat.com] On Behalf Of nodata
> Sent: Thursday, December 17, 2009 15:09
> To: Development discussions related to Fedora
> Subject: Re: packages requiring me to reboot...
> 
> Am 2009-12-17 15:02, schrieb Otto Haliburton:
> >
> >
> >> -Original Message-
> >> From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
> >> boun...@redhat.com] On Behalf Of Eelko Berkenpies
> >> Sent: Thursday, December 17, 2009 05:09
> >> To: Development discussions related to Fedora
> >> Subject: Re: packages requiring me to reboot...
> >>
> >> On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton
> >>   wrote:
> >>>
> >>> - Original Message - From: "nodata"
> >>> To: "Development discussions related to Fedora"
> >>> 
> >>> Sent: Wednesday, December 16, 2009 11:29 AM
> >>> Subject: Re: packages requiring me to reboot...
> >>>
> >>>
>  Am 2009-12-16 18:21, schrieb Seth Vidal:
> >
> >
> > On Wed, 16 Dec 2009, nodata wrote:
> >
> >>>
> >>> we're talking about the experienced user who is comfortable
> knowing
> >>> what
> >>> does and does not need a reboot.
> >>>
> >>> All I'm saying is - we've not taken away any option, the
> experienced
> >>> user can do what they want.
> >>>
> >>> -sv
> >>>
> >>
> >> True, but the default should be sensible.
> >
> > And the default is sensible for the inexperienced user:
> >
> > Don't try to explain to the user how to restart the apps
> individually,
> > tell them to bounce the box and it will be the right version when it
> > comes back.
> >
> > -sv
> >
> 
>  On the other hand I think requiring more reboots than Windows is a
> bad
>  thing...
> 
> >>> windows update will automatically reboot your system when it
> >> automatically
> >>> updates it
> >>> windows tried the optional stuff but now almost every case it requires
> a
> >>> restart.
> >>
> >> I don't like the term "experienced user" and I never feel comfortable
> >> adding myself to that group but anyway,
> >>
> >> - I don't want Windows to automatically reboot so I disable the
> >> automatic Windows Update on the machines I'm using.
> >>
> >> - I don't want my Fedora to reboot automatically so I disable and
> >> remove PackageKit on the machines I'm using.
> >>
> >> There isn't that much I could say about the times Fedora ask for a
> >> reboot but at least I think it's kind of "unfair" to compare it with
> >> an OS which pushes their updates just once a month.
> >>
> >> Just my € 0.02.
> > first of all PackageKit does not do mandatory reboots.  If you hadn't
> > disabled it you would know that.  In fact the people that are
> complaining
> > don't seem to have any idea why reboots are necessary.  You need to get
> a
> > grip on file processing, cache, and other processes that speeds up
> execution
> > then you will know why it is not trivial. i.e. you kill a task that is
> in
> > the process of writing data to a file after you update it.  What
> happens
> >>
> >> --
> >> With kind regards / Met vriendelijke groet,
> >>
> >> Eelko Berkenpies
> >> http://blog.berkenpies.nl/
> >>
> >> --
> >> fedora-devel-list mailing list
> >> fedora-devel-list@redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> >
> 
> I wish mailing list discussions were point-for-point for-and-against. It
> would be so much easier.
> 
> Here is my point: Windows requires a reboot less often than Linux. Argue
> all you want, it's true.
> 
> Linux has quicker security updates than Linux. That's an advantage.
> 
> ksplice can patch a running kernel...
LOL, you have to be joking with all the stuff that blows up around here you
would trust someone patch you kernel  while it was running and especially if
like me you run a custom built kernel.  I applaud your trust and guts if you
will stand for that.
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

RE: packages requiring me to reboot...

[Otto Haliburton]

> -Original Message-
> From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
> boun...@redhat.com] On Behalf Of nodata
> Sent: Thursday, December 17, 2009 15:09
> To: Development discussions related to Fedora
> Subject: Re: packages requiring me to reboot...
> 
> Am 2009-12-17 15:02, schrieb Otto Haliburton:
> >
> >
> >> -Original Message-
> >> From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
> >> boun...@redhat.com] On Behalf Of Eelko Berkenpies
> >> Sent: Thursday, December 17, 2009 05:09
> >> To: Development discussions related to Fedora
> >> Subject: Re: packages requiring me to reboot...
> >>
> >> On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton
> >>   wrote:
> >>>
> >>> - Original Message - From: "nodata"
> >>> To: "Development discussions related to Fedora"
> >>> 
> >>> Sent: Wednesday, December 16, 2009 11:29 AM
> >>> Subject: Re: packages requiring me to reboot...
> >>>
> >>>
>  Am 2009-12-16 18:21, schrieb Seth Vidal:
> >
> >
> > On Wed, 16 Dec 2009, nodata wrote:
> >
> >>>
> >>> we're talking about the experienced user who is comfortable
> knowing
> >>> what
> >>> does and does not need a reboot.
> >>>
> >>> All I'm saying is - we've not taken away any option, the
> experienced
> >>> user can do what they want.
> >>>
> >>> -sv
> >>>
> >>
> >> True, but the default should be sensible.
> >
> > And the default is sensible for the inexperienced user:
> >
> > Don't try to explain to the user how to restart the apps
> individually,
> > tell them to bounce the box and it will be the right version when it
> > comes back.
> >
> > -sv
> >
> 
>  On the other hand I think requiring more reboots than Windows is a
> bad
>  thing...
> 
> >>> windows update will automatically reboot your system when it
> >> automatically
> >>> updates it
> >>> windows tried the optional stuff but now almost every case it requires
> a
> >>> restart.
> >>
> >> I don't like the term "experienced user" and I never feel comfortable
> >> adding myself to that group but anyway,
> >>
> >> - I don't want Windows to automatically reboot so I disable the
> >> automatic Windows Update on the machines I'm using.
> >>
> >> - I don't want my Fedora to reboot automatically so I disable and
> >> remove PackageKit on the machines I'm using.
> >>
> >> There isn't that much I could say about the times Fedora ask for a
> >> reboot but at least I think it's kind of "unfair" to compare it with
> >> an OS which pushes their updates just once a month.
> >>
> >> Just my € 0.02.
> > first of all PackageKit does not do mandatory reboots.  If you hadn't
> > disabled it you would know that.  In fact the people that are
> complaining
> > don't seem to have any idea why reboots are necessary.  You need to get
> a
> > grip on file processing, cache, and other processes that speeds up
> execution
> > then you will know why it is not trivial. i.e. you kill a task that is
> in
> > the process of writing data to a file after you update it.  What
> happens
> >>
> >> --
> >> With kind regards / Met vriendelijke groet,
> >>
> >> Eelko Berkenpies
> >> http://blog.berkenpies.nl/
> >>
> >> --
> >> fedora-devel-list mailing list
> >> fedora-devel-list@redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> >
> 
> I wish mailing list discussions were point-for-point for-and-against. It
> would be so much easier.
> 
> Here is my point: Windows requires a reboot less often than Linux. Argue
> all you want, it's true.
I have three computers running windows XP Windows Vista and Windows Vista
Premium 24 hours per day, I have 2 computers dedicated to Linux so I know
what I am talking about.  Windows is a commercial system, it gets paid for
what it produces and so it would be nice for them to boot less, but now they
reboot on every update and that is once a week generally on Tuesday.

> 
> Linux has quicker security updates than Linux. That's an advantage.
> 
> ksplice can patch a running kernel...

If you really want that then you can design and use it yourself.  I don't
believe that anyone wants to patch a running Kernel especially without
testing and not be able to recover the old kernel.  Are you really thinking
and considering the reasons for a reboot, #1 is simplicity!!!
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rpm cpio error: prelink and SBCL

[Jerry James]

On Thu, Dec 17, 2009 at 1:54 PM, Jakub Jelinek  wrote:
> You need to first prelink -u on a copy of the program, then
> run it and let it dump itself, then package it up.

Ah, thanks.

> I'd actually argue that such packaging is broken anyway, because you didn't
> compile the binary you are packaging from source, you copied it from
> /usr/bin.

True, so future sbcl updates wouldn't be reflected in the saved image.
 How should I deal with that?  I can think of a few approaches.

1. Put an explicit versioned dependency on the sbcl used to build.
Then every sbcl update breaks upgrades for anyone with my package
installed until I get around to rebuilding it.  It looks like maxima
has taken this approach.

2. Don't dump an executable, but instead store individual FASL files
that are loaded at runtime by whatever version of sbcl happens to be
installed.  The application I'm working with did not take this
approach because of the large size of the application, which would
lead to a significant startup delay.  Plus, the SBCL documentation
explicitly doesn't guarantee that FASL files generated by one version
can be loaded and used without error by another version.

3. Compile sbcl AND the application I really want to build from
source.  Not only will that make my spec file significantly more
complex, but then I have to stay on top of future sbcl updates so I
can update my package, too.  That doesn't seem any better than what
I'm doing now (embedding the existing sbcl binary into my
application).

Even with its faults, #1 seems best to me.  Does anybody see another
approach that will work better?
-- 
Jerry James
http://www.jamezone.org/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[nodata]

Am 2009-12-17 15:02, schrieb Otto Haliburton:




-Original Message-
From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
boun...@redhat.com] On Behalf Of Eelko Berkenpies
Sent: Thursday, December 17, 2009 05:09
To: Development discussions related to Fedora
Subject: Re: packages requiring me to reboot...

On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton
  wrote:


- Original Message - From: "nodata"
To: "Development discussions related to Fedora"

Sent: Wednesday, December 16, 2009 11:29 AM
Subject: Re: packages requiring me to reboot...



Am 2009-12-16 18:21, schrieb Seth Vidal:



On Wed, 16 Dec 2009, nodata wrote:



we're talking about the experienced user who is comfortable knowing
what
does and does not need a reboot.

All I'm saying is - we've not taken away any option, the experienced
user can do what they want.

-sv



True, but the default should be sensible.


And the default is sensible for the inexperienced user:

Don't try to explain to the user how to restart the apps individually,
tell them to bounce the box and it will be the right version when it
comes back.

-sv



On the other hand I think requiring more reboots than Windows is a bad
thing...


windows update will automatically reboot your system when it

automatically

updates it
windows tried the optional stuff but now almost every case it requires a
restart.


I don't like the term "experienced user" and I never feel comfortable
adding myself to that group but anyway,

- I don't want Windows to automatically reboot so I disable the
automatic Windows Update on the machines I'm using.

- I don't want my Fedora to reboot automatically so I disable and
remove PackageKit on the machines I'm using.

There isn't that much I could say about the times Fedora ask for a
reboot but at least I think it's kind of "unfair" to compare it with
an OS which pushes their updates just once a month.

Just my € 0.02.

first of all PackageKit does not do mandatory reboots.  If you hadn't
disabled it you would know that.  In fact the people that are complaining
don't seem to have any idea why reboots are necessary.  You need to get a
grip on file processing, cache, and other processes that speeds up execution
then you will know why it is not trivial. i.e. you kill a task that is in
the process of writing data to a file after you update it.  What happens


--
With kind regards / Met vriendelijke groet,

Eelko Berkenpies
http://blog.berkenpies.nl/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list





I wish mailing list discussions were point-for-point for-and-against. It 
would be so much easier.


Here is my point: Windows requires a reboot less often than Linux. Argue 
all you want, it's true.


Linux has quicker security updates than Linux. That's an advantage.

ksplice can patch a running kernel...

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Electric Fence - still reliable?

[Michael Schwendt]

Fedora 12 with LD_PRELOAD=libefence.so.0.0 EF_ALLOW_MALLOC_0=1, what is
more likely that these are false positives or real bugs?
---

$ gnome-terminal

  Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens 
Segmentation fault (core dumped)

 ==> in ORBit corba-any.c


$ geeqie

  Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens 
Geeqie 1.0beta2, This is an alpha release.
Could not init LIRC support

ElectricFence Aborting: free(86c6e00): address not from malloc().
Illegal instruction (core dumped)

 ==> in glib2 gslice.c


$ gnome-calculator

  Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens 
Segmentation fault (core dumped)

 ==> in ORBit iop-profiles.c


$ audacious

  Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens 

** (audacious:2106): WARNING **: Could not open 
file:///home/misc/.adplug/adplug.db for reading or writing: Error opening file: 
No such file or directory

ElectricFence Aborting: free(910c700): address not from malloc().
Illegal instruction (core dumped)

 ==> gtkicontheme.c -> glib2 gsplice.c


$ gnote

  Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens 

ElectricFence Aborting: free(91d1600): address not from malloc().
Illegal instruction (core dumped)

 ==> ? (didn't wait in ABRT for further 32 debuginfos to download)

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rpm cpio error: prelink and SBCL

[Jakub Jelinek]

On Thu, Dec 17, 2009 at 01:48:20PM -0700, Jerry James wrote:
> On Thu, Dec 17, 2009 at 11:24 AM, Jerry James  wrote:
> > So this is going to hit anybody who tries to package up an executable
> > produced by SBCL.  Perhaps this should be noted on
> > https://fedoraproject.org/wiki/Packaging:Lisp.
> 
> And it's even worse than I thought: "prelink -u saved-image" strips
> out the dumped Lisp image!  I had a saved image go from 43MB to 171552
> bytes when I did that.  It looks like putting this in the spec file
> works:

You need to first prelink -u on a copy of the program, then
run it and let it dump itself, then package it up.

I'd actually argue that such packaging is broken anyway, because you didn't
compile the binary you are packaging from source, you copied it from
/usr/bin.

Jakub

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Colin Walters]

On Thu, Dec 17, 2009 at 3:21 PM, Ewan Mac Mahon  wrote:
>
> That would fail pretty badly in the case of Firefox with multiple
> windows open.

True; there's nothing stopping us from adding something
Firefox-specific as a short term measure, since how it does session
saving is fairly unique right now (ideally we add a nice API for this
to GTK+ which then has to be mirrored in XUL).   Killing the process
though has the downside of triggering the "Well, that was
embarassing..." which is arguably a Firefox bug though.

Anyways, "the perfect is the enemy of the good", etc.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rpm cpio error: prelink and SBCL

[Jerry James]

On Thu, Dec 17, 2009 at 11:24 AM, Jerry James  wrote:
> So this is going to hit anybody who tries to package up an executable
> produced by SBCL.  Perhaps this should be noted on
> https://fedoraproject.org/wiki/Packaging:Lisp.

And it's even worse than I thought: "prelink -u saved-image" strips
out the dumped Lisp image!  I had a saved image go from 43MB to 171552
bytes when I did that.  It looks like putting this in the spec file
works:

%global __prelink_undo_cmd %{nil}

-- 
Jerry James
http://www.jamezone.org/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Ewan Mac Mahon]

On Thu, Dec 17, 2009 at 12:05:15PM -0500, Colin Walters wrote:
> On Thu, Dec 17, 2009 at 10:51 AM, James Antill  
> wrote:
> >
> >  How do you plan on restarting firefox? Or you just planning to kill()
> > and get the user to restart?
> 
> Trying to send a close button event to the app's windows is probably
> our best short-term approach; 

That would fail pretty badly in the case of Firefox with multiple
windows open. Firefox's session support can restore multiple tabs to
multiple windows if you quit it and restart, but if you have two windows
open, close one, then close the second causing the browser to quit, then
on restart the session that is restored will only contain the tabs from
the second window. The logic goes that the first window was no longer
part of the session when the app quit. Simply killing the process is
actually less disruptive.

Ewan


pgpucZcTAZjFl.pgp
Description: PGP signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

RE: packages requiring me to reboot...

[Otto Haliburton]

> -Original Message-
> From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
> boun...@redhat.com] On Behalf Of Przemek Klosowski
> Sent: Thursday, December 17, 2009 13:05
> To: fedora-devel-list@redhat.com
> Subject: Re: packages requiring me to reboot...
> 
> On 12/17/2009 01:50 PM, nodata wrote:
> 
> > yep. but all of that assumes I know what I am doing, and the people that
> > this is aimed at don't. windows requires fewer reboots now.
> 
> +1, and remember that they have an advantage right off the bat:
> 
> - much fewer subsystems (Windows and a couple of tiny apps, vs. Linux's
> entire universe of applications)
> 
> - patch model that pushes large patch sets at long intervals rather than
> frequent fine-grained patches.
> 
> I think Linux has to have a better heuristic as to when a reboot is
> necessary. Actually, any event that breaks the user's work flow is as
> bad: X crash/logoff is as disruptive as a reboot, unless we had a way to
> restore the application state in the way Firefox or Emacs or OpenOffice
> recover from crashes (restarting, opening the windows where they were
> and recovering the content).
> 
I am now getting a picture of why this subject is so hard to grasp, everyone
who is for fewer reboots address the issue on a task by task bases, while
those who support reboots think of it on a system bases.  Windows now
restarts each time a patch occurs, at the current time I can't think of any
patch in the last 3 months which hasn't required a reboot. Another reason is
that some of the windows operating systems are coming to their end of life
cycle, and windows is choosing to do a lot of patches in one update, but
believe me, it is startling to come in the next morning to see your computer
restarted with a message that a update was performed and you were restarted
and that occurs with all of the windows operating systems that are currently
supported.  Linux has many applications that are running and on each update
you can have as many as many as 65(the last update) task being updated each
week and how you will avoid reboots will be amazing to me.  I think then
people will complain that it takes 6 hours to update now and it use to take
30 minutes.  At the present time you have apps that run across logoff and
login, so trying to get into starting and stopping task in update situations
will be a nightmare, but if there are some ambitious people out there go at
it, there are only 5000 apps that need to be updated to solve the problem.
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: 190 packages with .la file(s)

[Tom "spot" Callaway]

On 11/30/2009 08:42 AM, Pierre-Yves wrote:

> gambas2-2.18.0-1.fc12.src.rpm

Gambas is... special. It needs these .la files to function.

~spot

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Useless setroubleshoot alerts

[Chuck Anderson]

On Wed, Dec 09, 2009 at 01:34:45PM +, Christopher Brown wrote:
> SELinux was quite good on F11 and F12. Now it would seem it is 
> starting to regress again.

Your expectations are too high if you think rawhide shouldn't have 
regressions.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Przemek Klosowski]

On 12/17/2009 01:50 PM, nodata wrote:


yep. but all of that assumes I know what I am doing, and the people that
this is aimed at don't. windows requires fewer reboots now.


+1, and remember that they have an advantage right off the bat:

- much fewer subsystems (Windows and a couple of tiny apps, vs. Linux's 
entire universe of applications)


- patch model that pushes large patch sets at long intervals rather than 
frequent fine-grained patches.


I think Linux has to have a better heuristic as to when a reboot is 
necessary. Actually, any event that breaks the user's work flow is as 
bad: X crash/logoff is as disruptive as a reboot, unless we had a way to 
restore the application state in the way Firefox or Emacs or OpenOffice 
recover from crashes (restarting, opening the windows where they were 
and recovering the content).


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[nodata]

Am 2009-12-17 10:36, schrieb Otto Haliburton:




-Original Message-
From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
boun...@redhat.com] On Behalf Of nodata
Sent: Thursday, December 17, 2009 01:01
To: Development discussions related to Fedora
Subject: Re: packages requiring me to reboot...

Am 2009-12-17 00:08, schrieb Jeff Spaleta:

On Wed, Dec 16, 2009 at 2:01 PM, Gregory Maxwell

wrote:

Yes- users with more expertise are more likely to complain about this,
but thats not reason to dismiss the issue. If there were truly a
disconnect here betweens the needs of the novices and those of the
expert users you could argue favouring the novices, but that just
isn't applicable here.


Uhm. am I missing something. Aren't we talking about reboot requests
that PK is spawning and I can choose to cancel in the UI interaction
because I know better instead of mandatory reboots?

-jef



No, we're talking about requiring fewer reboots for normal users.

Prompting a user like this teaches them to ignore recommendations. This
isn't a good thing.


there are no mandatory reboots in PackageKit, you are notified what packages
will cause a request to reboot and you can exit the process without
rebooting!!  Or you can remove the packages from the update processes
and install when convenient for you.


yep. but all of that assumes I know what I am doing, and the people that 
this is aimed at don't. windows requires fewer reboots now.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rpm cpio error: prelink and SBCL

[Jerry James]

On Thu, Dec 17, 2009 at 10:12 AM, yersinia  wrote:
> You probably have a prelinked file in BUILD ROOT (objdump -s  |
> grep prelink) . Try to get rid of this in %install with prelink -u

Oh ho!  The sbcl executable has already been prelinked.  When
save-lisp-and-die is called (at least with :executable t), the sbcl
executable itself is dumped with the Lisp core written into it.  So we
wind up with a prelinked image in the build directory, like so:

--
$ objdump -s /usr/bin/sbcl | grep -F prelink
Contents of section .gnu.prelink_undo:
$ sbcl
This is SBCL 1.0.30-2.fc12, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (defun my-fun () "Isn't this fun?")

MY-FUN
* (save-lisp-and-die "sbcl-test" :executable t)
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into sbcl-test:
writing 6176 bytes from the read-only space at 0x2000
writing 4064 bytes from the static space at 0x2010
writing 42983424 bytes from the dynamic space at 0x10
done]
$ objdump -s sbcl-test | grep -F prelink
Contents of section .gnu.prelink_undo:
--

So this is going to hit anybody who tries to package up an executable
produced by SBCL.  Perhaps this should be noted on
https://fedoraproject.org/wiki/Packaging:Lisp.
-- 
Jerry James
http://www.jamezone.org/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Adam Williamson]

On Thu, 2009-12-17 at 10:51 -0500, James Antill wrote:

> > The UI isn't very pretty at the moment (it just fails with an update
> > error) but I'll work on something a little bit more user friendly.
> 
>  How do you plan on restarting firefox? Or you just planning to kill()
> and get the user to restart?

If we're just talking about Firefox (i.e. not the general case), then it
has its own 'restart Firefox' hook you might be able to access. It's
used, for instance, when you enable or disable an extension. I'm not
sure if you can poke it from an external app easily, though.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Review swaps

[Peter Robinson]

Hi All,

Anyone interested in swapping a couple of package reviews?

mx https://bugzilla.redhat.com/show_bug.cgi?id=538465
moblin-app-installer https://bugzilla.redhat.com/show_bug.cgi?id=546301

Regards,
Peter

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rpm cpio error: prelink and SBCL

[yersinia]

On Thu, Dec 17, 2009 at 5:13 PM, Jerry James  wrote:
> Is that due to prelink?  If so, what is broken?  SBCL, because it
You probably have a prelinked file in BUILD ROOT (objdump -s  |
grep prelink) . Try to get rid of this in %install with prelink -u

Regards

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Colin Walters]

On Thu, Dec 17, 2009 at 10:51 AM, James Antill  wrote:
>
>  How do you plan on restarting firefox? Or you just planning to kill()
> and get the user to restart?

Trying to send a close button event to the app's windows is probably
our best short-term approach; slightly longer term, we could have apps
expose a standard interface for Quit (e.g. over dbus).

Knowing how to restart is trickier, (though we could use the
window-to-app mapping system we need for gnome 3 anyways) but it's
also very simple in this case if we require that packages contain at
most one .desktop file.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

rpm cpio error: prelink and SBCL

[Jerry James]

I'm trying to package up a Common Lisp application that is built with
SBCL.  Near the end of the rpmbuild run, I see this right before the
list of Provides:

prelink: 
/home/jamesjer/rpmbuild/BUILDROOT/pvs-sbcl-4.2-2.svn20091008.fc12.x86_64/usr/lib64/pvs/bin/ix86_64-Linux/runtime/pvs-sbclisp:
Section .gnu.version created after prelinking

The rpmbuild run appears to complete successfully.  However, when I
try to rpm -i the resulting rpm, I get this:

# rpm -i pvs-sbcl-4.2-2.svn20091008.fc12.x86_64.rpm
error: unpacking of archive failed on file
/usr/lib64/pvs/bin/ix86_64-Linux/runtime/pvs-sbclisp;4b2a52f1: cpio:
Digest mismatch
# rpm -K pvs-sbcl-4.2-2.svn20091008.fc12.x86_64.rpm
pvs-sbcl-4.2-2.svn20091008.fc12.x86_64.rpm: sha1 md5 OK

Is that due to prelink?  If so, what is broken?  SBCL, because it
isn't putting a .gnu.version section in the executable images it
creates?  Prelink, because it somehow manages to break the rpm?  Both?
 And how do I build an RPM that can be installed successfully?

Thanks,
-- 
Jerry James
http://www.jamezone.org/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: review request - rasmol, Molecular Graphics Visualization Tool

[Tom "spot" Callaway]

On 11/24/2009 10:50 PM, Adam Williamson wrote:
> But I dunno if there's a policy
> requirement that you should anyway.

FWIW, the policy says:

"If a package contains a GUI application, then it needs to also include
a properly installed .desktop file. For the purposes of these
guidelines, a GUI application is defined as any application which draws
an X window and runs from within that window."

https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files

So, the rasmol app doesn't meet that criteria, so a .desktop file is not
required (although, it is worth noting that it is also permitted if the
maintainer wishes to do so).

~spot


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: autofs not installed by default

[Todd Volkert]

Hm - perhaps it was as part of the first boot, post-anaconda.  Basically, it
was when I was asked to create a user account.  I selected "use network
login" (paraphrasing) instead of creating a local account.

On Thu, Dec 17, 2009 at 10:09 AM, Bill Nottingham wrote:

> Todd Volkert (tvolk...@gmail.com) said:
> > The past few Fedora installs, I've specified a NIS server during the
> > Anaconda installation so I don't have to create any local user accounts.
> >  However, once installation is complete, I can't log into any NIS
> accounts
> > because autofs insn't installed, causing the user accounts' home folders
> to
> > not be mounted.  I have to sign in as root, install autofs, then all is
> > well.
>
> How have you set up a NIS server as part of the install? It's not part
> of the anaconda configuration screens.
>
> > My question is: shouldn't autofs be installed by default, as part of the
> > base installation?
>
> For many use cases in Fedora, it's not needed; we're trying to keep the
> core/base groups reasonably small.
>
> If you use kickstart, you can both set up NIS and install autofs with
> directives in your kickstart file.
>
> Bill
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[James Antill]

On Wed, 2009-12-16 at 08:50 +, Richard Hughes wrote:
> 2009/12/15 Colin Walters :
> > This exists?  Can you point me to the code?
> 
> I only finished this just this morning.
> 
> It's just been pushed to git master. You want to see this commit
> http://cgit.freedesktop.org/packagekit/commit/?id=66d3fc26054abd528ee18017d9c67edb6400f239
> for the juicy config bits.

 Looking at 3cb32ad40af3a38456e09baf1b29b046d82c587e, AIUI the commit
with the code bits in it, I'm pretty sure you are now requiring
filelists to be downloaded for all updates.

> The UI isn't very pretty at the moment (it just fails with an update
> error) but I'll work on something a little bit more user friendly.

 How do you plan on restarting firefox? Or you just planning to kill()
and get the user to restart?

-- 
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.25
http://yum.baseurl.org/wiki/YumMultipleMachineCaching

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: safe way to standby sata hdd?

[Eric Sandeen]

Michał Piotrowski wrote:
> 2009/12/16 Eric Sandeen :
>> Michał Piotrowski wrote:
>>> Hi,
>>>
>>> I've got a home database/symfony env/etc../file server. It's based on
>>> Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power
>>> connected through Sata. First drive has / and /home filesystem, second
>>> has /home/samba4. On the first drive there are two directories
>>> /home/samba2 and /home/samba3 where I'm mounting ecryptfs.
>>> /home/samba4 is also crypted by default.
>>>
>>> I'm wondering if there is a safe way for such configuration to put
>>> second harddrive into sleep (or both drives) after some idle time?
>>> After some googling I've found some resolutions (haven't tested any of
>>> these yet):
>>> - hdparm -S
>> I use this for the data drive on my mythbox.  I just put this in my
>> /etc/rc.local -
>>
>> # Spin down in 1 hours idle time
>> hdparm -S 240 /dev/sda
> 
> Have you used this for a disk with your rootfs?

In the past I have, but lately getting the root to actually get idle
is just about impossible it seems.  I now have an ssd root and
don't bother.

>> (yeah, oddly, sda is not my boot drive) :)
>>
>>> - sdparm --set=STANDBY
>>> - and laptop_tools
>>>
>>> I'm really not convinced that these methods are safe for my
>>> configuration. Anyone have tried this before?
>> Yep.  What kind of safety are you worried about?
> 
> I know that ecryptfs is just fs stack on top of my ext3 partition, but
> still I care about data integrity.

Ok but what does that have to do with spinning down a disk? :)

>>  It should just work,
>> although you want a long enough idle time that you're not constantly
>> spinning the disk up and down.
> 
> Actually /home/samba4 is not mounted all the time - I'm umountig this
> fs when I'm not using it. I'm wondering if there will be any problems
> with data integrity when I forgot to umount ecryptfs and disk will be
> stopped.

I don't think so.  Any access should just spin up the disk and carry on.

-Eric

>> Is there any nice user-friendly frontend to set this?  It'd be nice
>> to expose more power management choices to the users (for anything
>> that can't be easily defaulted, that is).
>>
>> -Eric
> 
> Regards,
> Michal
> 

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Election results for FAmSCo, FESCo coming shortly

[Paul W. Frields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Our election coordinator, Nigel Jones, was too swamped today to
process all of the election results, but will be doing so later today
(UTC time).  Thanks for your patience, and thanks to Nigel for all his
work coordinating the voting system and results.

- -- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLKkm/rNvJN70RNxcRAjY9AKCoRs/EplwBz3kXCbYJlW9heW19TQCgtHmx
wmnUs+PWljamrXBKBi1jq/c=
=8gZv
-END PGP SIGNATURE-

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: autofs not installed by default

[Bill Nottingham]

Todd Volkert (tvolk...@gmail.com) said: 
> The past few Fedora installs, I've specified a NIS server during the
> Anaconda installation so I don't have to create any local user accounts.
>  However, once installation is complete, I can't log into any NIS accounts
> because autofs insn't installed, causing the user accounts' home folders to
> not be mounted.  I have to sign in as root, install autofs, then all is
> well.

How have you set up a NIS server as part of the install? It's not part
of the anaconda configuration screens.

> My question is: shouldn't autofs be installed by default, as part of the
> base installation?

For many use cases in Fedora, it's not needed; we're trying to keep the
core/base groups reasonably small.

If you use kickstart, you can both set up NIS and install autofs with
directives in your kickstart file.

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Offline for one month or more

[Chitlesh GOORAH]

Hello there,

I'm currently relocating to another country and will be fedora-offline
for a while, probably one month (probably be on and off).

If my packages require immediate actions for any reason, please do the
necessary in my place.
https://admin.fedoraproject.org/pkgdb/users/packages/chitlesh

As far as the FEL spin is concerned, it is still scheduled for F-13
and recent work done by Shakthi Kannan and Arun Sag made
microelectronics design even more exciting.

If you have any question, please email us on FEL's mailing list.
Shakthi Kannan and others would be pleased to answer you.

I wish you all Merry Christmas and New Year 2010 ;)

Kind regards,
Chitlesh Goorah

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

autofs not installed by default

[Todd Volkert]

Hi all,

The past few Fedora installs, I've specified a NIS server during the
Anaconda installation so I don't have to create any local user accounts.
 However, once installation is complete, I can't log into any NIS accounts
because autofs insn't installed, causing the user accounts' home folders to
not be mounted.  I have to sign in as root, install autofs, then all is
well.

My question is: shouldn't autofs be installed by default, as part of the
base installation?

-T
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Fedora update submission page broken for multiple packages

[Toshio Kuratomi]

On Thu, Dec 17, 2009 at 01:35:44PM +0100, Michael Schwendt wrote:
> On Wed, 16 Dec 2009 18:41:22 -0500, Tom wrote:
> 
> > Orcan Ogetbil writes:
> > > If there is a way to file an update (same version and release except
> > > the disttag) to multiple branches, please let me know.
> > 
> > Usually it works: just add all the package NVRs to the same update
> > submission.  (That's what the "add another package" button is for.)
> 
> For "multiple branches"?  That has never worked for me either.
> 
This used to work.  Once the update is submitted, bodhi breaks it into two
update requests when it saves it.

> "Add another package" is to push multiple packages in a single
> bodhi ticket. That has worked for me.
> 
This works as well.  When bodhi saves this, it saves the set of packages
into a single update request so that they all get puhed together.

I do not know if there's any bugs when these two features are used together
but that doesn't sound like what was attempted here.

> > The case I was complaining about seems to be that adding a new package
> > to an *existing* update request doesn't work.
> 
I don't know if this has worked in the past but given that you can add
multiple builds of a package to multiple branches via the add another package
mechanism, this seems like it should work.

> Not even when "editing" the update request again? That will pull it
> back into "pending", however. And the package to add must not be part
> of a different update request ticket already.
> 

-Toshio


pgpfsirTdZV04.pgp
Description: PGP signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

RE: packages requiring me to reboot...

[Otto Haliburton]

> -Original Message-
> From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
> boun...@redhat.com] On Behalf Of Eelko Berkenpies
> Sent: Thursday, December 17, 2009 05:09
> To: Development discussions related to Fedora
> Subject: Re: packages requiring me to reboot...
> 
> On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton
>  wrote:
> >
> > - Original Message - From: "nodata" 
> > To: "Development discussions related to Fedora"
> > 
> > Sent: Wednesday, December 16, 2009 11:29 AM
> > Subject: Re: packages requiring me to reboot...
> >
> >
> >> Am 2009-12-16 18:21, schrieb Seth Vidal:
> >>>
> >>>
> >>> On Wed, 16 Dec 2009, nodata wrote:
> >>>
> >
> > we're talking about the experienced user who is comfortable knowing
> > what
> > does and does not need a reboot.
> >
> > All I'm saying is - we've not taken away any option, the experienced
> > user can do what they want.
> >
> > -sv
> >
> 
>  True, but the default should be sensible.
> >>>
> >>> And the default is sensible for the inexperienced user:
> >>>
> >>> Don't try to explain to the user how to restart the apps individually,
> >>> tell them to bounce the box and it will be the right version when it
> >>> comes back.
> >>>
> >>> -sv
> >>>
> >>
> >> On the other hand I think requiring more reboots than Windows is a bad
> >> thing...
> >>
> > windows update will automatically reboot your system when it
> automatically
> > updates it
> > windows tried the optional stuff but now almost every case it requires a
> > restart.
> 
> I don't like the term "experienced user" and I never feel comfortable
> adding myself to that group but anyway,
> 
> - I don't want Windows to automatically reboot so I disable the
> automatic Windows Update on the machines I'm using.
> 
> - I don't want my Fedora to reboot automatically so I disable and
> remove PackageKit on the machines I'm using.
> 
> There isn't that much I could say about the times Fedora ask for a
> reboot but at least I think it's kind of "unfair" to compare it with
> an OS which pushes their updates just once a month.
> 
> Just my € 0.02.
first of all PackageKit does not do mandatory reboots.  If you hadn't
disabled it you would know that.  In fact the people that are complaining
don't seem to have any idea why reboots are necessary.  You need to get a
grip on file processing, cache, and other processes that speeds up execution
then you will know why it is not trivial. i.e. you kill a task that is in
the process of writing data to a file after you update it.  What happens
> 
> --
> With kind regards / Met vriendelijke groet,
> 
> Eelko Berkenpies
> http://blog.berkenpies.nl/
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

rawhide report: 20091217 changes

[Rawhide Report]

Compose started at Thu Dec 17 08:15:09 UTC 2009

Broken deps for i386
--
1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3
anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0
anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0
beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3
cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15
ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4
ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4
ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4
ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4
ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4
ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4
ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4
ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4
ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4
ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4
ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4
ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4
ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4
ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4
ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4
ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4
ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4
ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4
ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4
ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4
ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4
ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4
ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4
ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4
ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4
ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4
ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4
ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4
ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:

Re: Fedora update submission page broken for multiple packages

[Michael Schwendt]

On Wed, 16 Dec 2009 18:41:22 -0500, Tom wrote:

> Orcan Ogetbil writes:
> > If there is a way to file an update (same version and release except
> > the disttag) to multiple branches, please let me know.
> 
> Usually it works: just add all the package NVRs to the same update
> submission.  (That's what the "add another package" button is for.)

For "multiple branches"?  That has never worked for me either.

"Add another package" is to push multiple packages in a single
bodhi ticket. That has worked for me.

> The case I was complaining about seems to be that adding a new package
> to an *existing* update request doesn't work.

Not even when "editing" the update request again? That will pull it
back into "pending", however. And the package to add must not be part
of a different update request ticket already.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot - semi-off -topic response

[David Timms]

On 12/17/2009 08:38 AM, Jon Masters wrote:
> On Wed, 2009-12-16 at 16:30 -0500, Przemek Klosowski wrote:
> 
>> too. My own preference would be a more discriminating dialog
>> that offers three possibilities: 'do nothing', 'bounce the 
>> service/application' and 'reboot'.
> 
> Yup, +1
Bounce the application would be really cool for eg firefox, thunderbird,
that continue to work, but some things sort of don't (like new popups
dont open and so forth). In doing so the application would need to
return to the identical locations, arrangements that it was bounced from.

And really, the above shouldn't be difficult for a computer to do:
- have window, pos,size, doc open, caret position and so on, even those
pesky web forms with unsubmitted data and so on. Make it part of the
freedesktop standards - an app forcibly closed or ?disappears shall
reopen as if nothing changed ! (although firefox multi-tab and working
out which tab not to reopen after a crash is a good game).

Make open documents files etc, be always stored immediately on change
with snapshots at each save to disk, few minutes of operation etc. Make
it like paper, but actually better, you know: what is written on paper
doesn't mysteriously disappear when an update or a power failure, or app
crash occurs, nor does it disappear from where you left it.

I think the above scenario for user apps would seem to be a reasonable
goal. On the other hand, services are not so clear cut. If I'm an
external user logged into the web service, filling a form, I don't
expect even momentary downtime to cause me to lose information I'm
entering, or corrupt a file I have open / editing on network share
(though see the works better than paper description).

In the first example, would it make sense for the web server to start
all new processes using the new updated code, while existing users stay
connected to the existing instance, until these timeout/logout and no
user's connection is using the old code.

When a reboot is really needed, a PK dialog could inform of the need,
and ask when that could occur (do at 4:30 am tueday morning)

ps: did gnome desktop regain the feature of autologin and rerun apps on
desktop capability of pre f-10 ?

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Eelko Berkenpies]

On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton
 wrote:
>
> - Original Message - From: "nodata" 
> To: "Development discussions related to Fedora"
> 
> Sent: Wednesday, December 16, 2009 11:29 AM
> Subject: Re: packages requiring me to reboot...
>
>
>> Am 2009-12-16 18:21, schrieb Seth Vidal:
>>>
>>>
>>> On Wed, 16 Dec 2009, nodata wrote:
>>>
>
> we're talking about the experienced user who is comfortable knowing
> what
> does and does not need a reboot.
>
> All I'm saying is - we've not taken away any option, the experienced
> user can do what they want.
>
> -sv
>

 True, but the default should be sensible.
>>>
>>> And the default is sensible for the inexperienced user:
>>>
>>> Don't try to explain to the user how to restart the apps individually,
>>> tell them to bounce the box and it will be the right version when it
>>> comes back.
>>>
>>> -sv
>>>
>>
>> On the other hand I think requiring more reboots than Windows is a bad
>> thing...
>>
> windows update will automatically reboot your system when it automatically
> updates it
> windows tried the optional stuff but now almost every case it requires a
> restart.

I don't like the term "experienced user" and I never feel comfortable
adding myself to that group but anyway,

- I don't want Windows to automatically reboot so I disable the
automatic Windows Update on the machines I'm using.

- I don't want my Fedora to reboot automatically so I disable and
remove PackageKit on the machines I'm using.

There isn't that much I could say about the times Fedora ask for a
reboot but at least I think it's kind of "unfair" to compare it with
an OS which pushes their updates just once a month.

Just my € 0.02.

-- 
With kind regards / Met vriendelijke groet,

Eelko Berkenpies
http://blog.berkenpies.nl/

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: packages requiring me to reboot...

[Richard Hughes]

2009/12/16 Nathanael D. Noblet :
> So basically, PK is designed for the non-experienced users, as such
> everything it does is dumbed down, and experienced users should just ignore
> it, using other tools to keep their system up to date.

See http://www.packagekit.org/pk-profiles.html

Richard.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Why pavucontrol is not installed by default?

[Rahul Sundaram]

On 12/17/2009 03:20 PM, Christof Damian wrote:

> I just find it annoying that some people seem to have "File a bug." in
> their signature, when one should assume that on fedora-devel everyone
> would file a bug for valid problems. It might and should be different
> on fedora or the forums.

They do that because the assumption that everyone will have filed bugs
would have been very wrong considering the past experiences.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Why pavucontrol is not installed by default?

[Christof Damian]

On Thu, Dec 17, 2009 at 08:19, Rahul Sundaram
 wrote:
> On 12/17/2009 12:46 PM, Christof Damian wrote:
>> On Wed, Dec 16, 2009 at 19:58, Lennart Poettering  
>> wrote:
 pavucontrol currently crashes (and pulseaudio) for me on one machine
 and I need this functionality.
>>>
>>> File a bug.
>>
>> Could everyone on this list please assume that I filed a bug or found
>> the bug already reported if I mention a bug.
>
> Useful to add a reference to those bug reports in that case.

The thing is that the thread wasn't about this bug and I wasn't
complaining about the bug.

I just wanted to know in which direction pulseaudio is going. I could
as well have said: "In the future there will be no pavucontrol, how
will this be possible then".

I just find it annoying that some people seem to have "File a bug." in
their signature, when one should assume that on fedora-devel everyone
would file a bug for valid problems. It might and should be different
on fedora or the forums.

Christof

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

RE: packages requiring me to reboot...

[Otto Haliburton]

> -Original Message-
> From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-
> boun...@redhat.com] On Behalf Of nodata
> Sent: Thursday, December 17, 2009 01:01
> To: Development discussions related to Fedora
> Subject: Re: packages requiring me to reboot...
> 
> Am 2009-12-17 00:08, schrieb Jeff Spaleta:
> > On Wed, Dec 16, 2009 at 2:01 PM, Gregory Maxwell
> wrote:
> >> Yes- users with more expertise are more likely to complain about this,
> >> but thats not reason to dismiss the issue. If there were truly a
> >> disconnect here betweens the needs of the novices and those of the
> >> expert users you could argue favouring the novices, but that just
> >> isn't applicable here.
> >
> > Uhm. am I missing something. Aren't we talking about reboot requests
> > that PK is spawning and I can choose to cancel in the UI interaction
> > because I know better instead of mandatory reboots?
> >
> > -jef
> >
> 
> No, we're talking about requiring fewer reboots for normal users.
> 
> Prompting a user like this teaches them to ignore recommendations. This
> isn't a good thing.
> 
there are no mandatory reboots in PackageKit, you are notified what packages
will cause a request to reboot and you can exit the process without
rebooting!!  Or you can remove the packages from the update processes
and install when convenient for you.
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)

[Paul Jakma]

On Wed, 16 Dec 2009, Matthew Garrett wrote:

The problem here is that you appear to be massively underestimating 
the amount of work that would be required to actually support this 
configuration.


Support is a multi-valued thing as well as a process. Not every i has 
to be dotted for something to be of use. E.g. there are secondary 
arches to act as staging grounds. I would not except everything to be 
magically perfect tomorrow, however there may be low-hanging fruit 
(like yum having separate notions of default native word-size for 
userspace and kernel, see below).


We'd need to audit every ioctl entry point, every 
file in proc and every sysfs attribute.


Or just let people file bugs as they find things..

We'd need to port every application that uses vm86 over to using 
x86emu.


Or let people using such apps continue to use a 32bit kernel (such 
kernel would have to continue to be supported, obv).


We'd need to add, test and support a 32-to-64 bit cross building 
toolchain.


GCC has a -m64 flag that may or may not help somewhat there (though, 
it got b0rken, though possibly just in combination with profiling).


yum would need some amount of work that Seth has implied 
is significant.


That's may be the easiest bit. It updates packages just fine, except 
it doesn't know I want it to install 64bit kernels, after I forced it 
to think the machine was 32bit.


That's a lot of work for marginal benefits, and nobody seems 
interested in stepping up to do that work.


I.e. money meet mouth, mouth likewise, you mean? :)

I'll try poke at it later in 2010. I'm more a C programmer than a 
python programmer, so I'd rather look at stuff like things like the 
SG_IO interface (which Peter Jones pointed me at in private) than at 
yum, but I'll see.


regards,
--
Paul Jakma  p...@jakma.org  Key ID: 64A2FF6A
Fortune:
One of the disadvantages of having children is that they eventually get old
enough to give you presents they make at school.
-- Robert Byrne

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list