Re: packages requiring me to reboot...

[Richard Hughes]

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.

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.

Richard.

-- 
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 Mail Lists :
>   The last part is a clean up phase which could be deferred to reboot
> or perhaps something a little more clever.

The devil is in the detail :)

Richard.

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

[Andreas Schwab]

Jesse Keating  writes:

> On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote:
>> 
>> My thinking is that we don't use origin/next or origin/maint either
>> and both are common upstream in git and the kernel.
>> 
>> While origin/master is common, 
>
> origin/master isn't "common", it's the friggin default.  Every single
> git repo I interact with has development happening on origin/master.
> It's way more than just "common".

You can set any branch as default via origin/HEAD, and some do.  It is
also easy to make origin/devel an alias for origin/master.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

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

rawhide report: 20091216 changes

[Rawhide Report]

Compose started at Wed Dec 16 08:15:08 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:

safe way to standby sata hdd?

[Michał Piotrowski]

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
- sdparm --set=STANDBY
- and laptop_tools

I'm really not convinced that these methods are safe for my
configuration. Anyone have tried this before?

BTW. I'm using F11 on this system - it appears that I even don't have
/etc/hdparm.conf...

Regards,
Michal

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

yum-presto behaviour on arm

[Andy Green]

Hi -

Is yum-presto known to work on arm?  Today I changed our repo to use 
deltarpms and tested it out.  I noticed...


1) On a package where I know the bulk of the unpacked data is some fonts 
inside an ELF executable that didn't change, the compression result 
was... not good


  Old RPM:  25424385 txtr-reader-0.1-417.fc11.armv5tel.rpm
  New RPM:  25465487 txtr-reader-0.1-420.fc11.armv5tel.rpm
Delta RPM:  25465402 txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm

So it saved me 85 bytes from 25MByte :-)

The actual procedure here is the createrepo is run on an x86_64 box over 
these arm packages and then rsync'd on a server.


2) Using deltarpms fails

Loaded plugins: presto
Setting up Update Process
Resolving Dependencies
There are unfinished transactions remaining. You might consider running 
yum-complete-transaction first to finish them.

--> Running transaction check
---> Package txtr-reader.armv5tel 0:0.1-420.fc11 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved


 PackageArchVersion Repository 
Size


Updating:
 txtr-readerarmv5tel0.1-420.fc11txtradevel 
24 M


Transaction Summary

Install  0 Package(s)
Update   1 Package(s)
Remove   0 Package(s)

Total download size: 24 M
Downloading Packages:
Setting up and reading Presto delta metadata
Downloading DeltaRPMs:
Rebuilding rpms from deltarpms
/var/cache/yum/txtradevel/deltas/txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm: 
md5 mismatch of result
Error rebuilding rpm from 
txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm! Will download full 
package.

Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : txtr-reader 
 1/2
  Cleanup: txtr-reader 
 2/2


Updated:
  txtr-reader.armv5tel 0:0.1-420.fc11 



Complete!

Any advice welcomed, it would be great to reduce this 25MByte package 
down since the vast bulk of it is exactly the same each time :-)


-Andy

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

Re: yum-presto behaviour on arm

[Jonathan Dieter]

On Wed, 2009-12-16 at 14:06 +, Andy Green wrote:
> Hi -
> 
> Is yum-presto known to work on arm?  Today I changed our repo to use 
> deltarpms and tested it out.  I noticed...
> 
> 1) On a package where I know the bulk of the unpacked data is some fonts 
> inside an ELF executable that didn't change, the compression result 
> was... not good
> 
>Old RPM:  25424385 txtr-reader-0.1-417.fc11.armv5tel.rpm
>New RPM:  25465487 txtr-reader-0.1-420.fc11.armv5tel.rpm
> Delta RPM:  25465402 txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm
> 
> So it saved me 85 bytes from 25MByte :-)
> 
> The actual procedure here is the createrepo is run on an x86_64 box over 
> these arm packages and then rsync'd on a server.
> 
> 2) Using deltarpms fails

> 
> Any advice welcomed, it would be great to reduce this 25MByte package 
> down since the vast bulk of it is exactly the same each time :-)
> 
> -Andy
> 

If you can get me ssh access to an arm machine, I'll look into both of
these problems. Please also open a bug against deltarpm (otherwise, I'll
totally forget about this).

Jonathan


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: yum-presto behaviour on arm

[Andy Green]

On 12/16/09 14:12, Somebody in the thread at some point said:

Hi -


Is yum-presto known to work on arm?  Today I changed our repo to use
deltarpms and tested it out.  I noticed...



If you can get me ssh access to an arm machine, I'll look into both of
these problems. Please also open a bug against deltarpm (otherwise, I'll
totally forget about this).


Thanks for the quick reply... I will see about setting something up and 
get back to you.


https://bugzilla.redhat.com/show_bug.cgi?id=548068

-Andy

--
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?)

[Matthew Garrett]

On Wed, Dec 16, 2009 at 12:30:11AM +, Paul Jakma wrote:
> On Tue, 15 Dec 2009, Matthew Garrett wrote:
>
>> And the remaining 0.1% of the work is probably the other 99.9% of the 
>> time. I think you massively underestimate the number of corner cases 
>> present in an utterly untested configuration.
>
> My data-point is that I ran an x86-64 kernel on i386 F10 for a few  
> months until I got tired of yum not being able to update kernel  
> packages. The kernel side apparently works fine AFAICT. The .1% is yum.

"It works for me" is a poor standard of support.

-- 
Matthew Garrett | mj...@srcf.ucam.org

-- 
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?)

[Seth Vidal]

On Wed, 16 Dec 2009, Matthew Garrett wrote:


On Wed, Dec 16, 2009 at 12:30:11AM +, Paul Jakma wrote:

On Tue, 15 Dec 2009, Matthew Garrett wrote:


And the remaining 0.1% of the work is probably the other 99.9% of the
time. I think you massively underestimate the number of corner cases
present in an utterly untested configuration.


My data-point is that I ran an x86-64 kernel on i386 F10 for a few
months until I got tired of yum not being able to update kernel
packages. The kernel side apparently works fine AFAICT. The .1% is yum.


"It works for me" is a poor standard of support.



and if running an x86_64 kernel on an i386 install is something we want to 
do then we can make some changes to make that work. But complaining that 
yum doesn't work for something it was never designed to work for is a bit 
silly.


-sv

"My this camel is not a very fast swimmer."


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

[Toshio Kuratomi]

On Wed, Dec 16, 2009 at 12:33:20AM -0500, Jon Masters wrote:
> On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote:
> 
> > master makes a lot of sense from a git perspective.  devel (or rawhide)
> > makes sense from what we actually call the code that that branch eventually
> > makes.  A symlink might alleviate the confusion but it could also add to it.
> > (For instance, I was operating in the kernel/devel branch but when I want to
> > git checkout -b devel git gives me a strange error.)
> > 
> > I don't see a clear answer for what's best here, yet. :-(
> 
> I think those of us who follow rawhide will quickly realize the change
> in naming (ok maybe a symbol is vaguely useful, and also needs to be
> explained somewhere when people inevitably ask) and move on. Conversely,
> someone who is new or hasn't followed "devel" branches before should
> just be able to use git how they have elsewhere and it should work.
> 
> Summary: easier to make life easier for new developers.
> 
Not all packagers use git elsewhere.

-Toshio


pgpcIBR0O52Mo.pgp
Description: PGP signature
-- 
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

[Simo Sorce]

On Wed, 2009-12-16 at 07:28 -0800, Toshio Kuratomi wrote:
> On Wed, Dec 16, 2009 at 12:33:20AM -0500, Jon Masters wrote:
> > On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote:
> > 
> > > master makes a lot of sense from a git perspective.  devel (or rawhide)
> > > makes sense from what we actually call the code that that branch 
> > > eventually
> > > makes.  A symlink might alleviate the confusion but it could also add to 
> > > it.
> > > (For instance, I was operating in the kernel/devel branch but when I want 
> > > to
> > > git checkout -b devel git gives me a strange error.)
> > > 
> > > I don't see a clear answer for what's best here, yet. :-(
> > 
> > I think those of us who follow rawhide will quickly realize the change
> > in naming (ok maybe a symbol is vaguely useful, and also needs to be
> > explained somewhere when people inevitably ask) and move on. Conversely,
> > someone who is new or hasn't followed "devel" branches before should
> > just be able to use git how they have elsewhere and it should work.
> > 
> > Summary: easier to make life easier for new developers.
> > 
> Not all packagers use git elsewhere.

But for anyone that does not using "master" as the default branch will
be a problem. If you never used git you have to learn a lot of things
anyway.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

(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?  It should just work,
although you want a long enough idle time that you're not constantly
spinning the disk up and down.

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

> BTW. I'm using F11 on this system - it appears that I even don't have
> /etc/hdparm.conf...
> 
> Regards,
> Michal
> 

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

ATTN: Changes to OCaml dependency generator for RPM 4.8 in Rawhide

[Richard W.M. Jones]

Since RPM 4.8 (now in Rawhide / Fedora 13), the external dependency
generator that we used to ship with OCaml has now gone upstream into
RPM.  This is a Good Thing, thanks to the RPM maintainers for adding
this.

If you own an OCaml library package, then there are some simple
adjustments you need to make to your OCaml spec files _in Rawhide_.

First of all, remove any lines that are exactly like any of these:

  %define _use_internal_dependency_generator 0
  %global _use_internal_dependency_generator 0
  %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
  %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh
  %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
  %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh

Any remaining calls to ocaml-find-{requires,provides}.sh must be ones
which take parameters, and these need to be modified.

Change:

  %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh 
or:
  %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh 

to:

  %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh 

and the same for "provides" instead of "requires".

For example, if your original spec files contained this block:

  %define _use_internal_dependency_generator 0
  %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh -i Asttypes -i 
Parsetree
  %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh

then following the rules above it would become:

  %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh -i Asttypes 
-i Parsetree

If you need any help, please ask on the list or see this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=545116

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

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

[Todd Zullinger]

Simo Sorce wrote:
> But for anyone that does not using "master" as the default branch
> will be a problem. If you never used git you have to learn a lot of
> things anyway.

I think the target audience is not mostly git users.  Most of the SCM
integration will be wrapped up in fedpkg calls anyway.  For those who
are not long time git users, there seems to be no compelling reason to
expose the devel branch as master -- and have to explain or document
that "F-n matches origin/F-n, expect for devel, which matches
origin/master because that's the default."

Those who are long time git users surely ought to know that master is
the convention, but is certainly not forced on you by git in any way.

Simo, is there a particular problem you are thinking of by not having
"master" as the default branch?

-- 
ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
Sometimes I think I understand everything, then I regain
consciousness.



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

Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10

[Matthew Miller]

On Thu, Dec 10, 2009 at 03:32:29PM -0500, Bill Nottingham wrote:
> One notable change that was made is that we were able to simplify the
> jobs to the point where the number of login consoles is now configurable,
> without editing or removing upstart job definitions.
> This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init;
> the default value is "/dev/tty/[1-6]", which means that mingetty
> will be started on ttys 1 through 6. Shell globs are accepted.

How hard would it be to make this be different in runlevels 3 and 5? I like
to have lots in runlevel 3, and few if X is available.


-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

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

[Toshio Kuratomi]

On Wed, Dec 16, 2009 at 10:42:28AM -0500, Simo Sorce wrote:
> On Wed, 2009-12-16 at 07:28 -0800, Toshio Kuratomi wrote:
> > On Wed, Dec 16, 2009 at 12:33:20AM -0500, Jon Masters wrote:
> > > On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote:
> > > 
> > > > master makes a lot of sense from a git perspective.  devel (or rawhide)
> > > > makes sense from what we actually call the code that that branch 
> > > > eventually
> > > > makes.  A symlink might alleviate the confusion but it could also add 
> > > > to it.
> > > > (For instance, I was operating in the kernel/devel branch but when I 
> > > > want to
> > > > git checkout -b devel git gives me a strange error.)
> > > > 
> > > > I don't see a clear answer for what's best here, yet. :-(
> > > 
> > > I think those of us who follow rawhide will quickly realize the change
> > > in naming (ok maybe a symbol is vaguely useful, and also needs to be
> > > explained somewhere when people inevitably ask) and move on. Conversely,
> > > someone who is new or hasn't followed "devel" branches before should
> > > just be able to use git how they have elsewhere and it should work.
> > > 
> > > Summary: easier to make life easier for new developers.
> > > 
> > Not all packagers use git elsewhere.
> 
> But for anyone that does not using "master" as the default branch will
> be a problem. If you never used git you have to learn a lot of things
> anyway.
> 
Yeah, not disagreeing with this at all.  Just disagreeing with the idea that
following the git conventions is a no brainer that's going to be intuitive
to everyone.

-Toshio


pgpxTEMM8BGbn.pgp
Description: PGP signature
-- 
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

[Toshio Kuratomi]

On Wed, Dec 16, 2009 at 10:13:33AM +0100, Andreas Schwab wrote:
> Jesse Keating  writes:
> 
> > On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote:
> >> 
> >> My thinking is that we don't use origin/next or origin/maint either
> >> and both are common upstream in git and the kernel.
> >> 
> >> While origin/master is common, 
> >
> > origin/master isn't "common", it's the friggin default.  Every single
> > git repo I interact with has development happening on origin/master.
> > It's way more than just "common".
> 
> You can set any branch as default via origin/HEAD, and some do.  It is
> also easy to make origin/devel an alias for origin/master.

So what's an alias?  It sounds like a git feature that makes an alternate
name for a branch and inside of git the two are 100% equivalent.  If that's
so, that's a much better solution than a symlink.

-Toshio


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

[Nathanael D. Noblet]

So again today, I see some updates two of which require a full system 
reboot.


nfs-utils and ibus-rawcode. My system seriously needs to be shut down 
for those to be properly updated? This is what I don't get. nfs-utils 
never got a system reboot before, it doesn't get one on RHEL/Centos 
boxes... What requires a reboot here? Again, I don't want the tone of 
this email to come off as anger, rude or whatever, mainly I'm wondering 
why so many packages require a reboot, why isn't nfs-utils just 
restarting any services it has or that depend on it if needed? Is that 
not reliable?


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

Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> > One notable change that was made is that we were able to simplify the
> > jobs to the point where the number of login consoles is now configurable,
> > without editing or removing upstart job definitions.
> > This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init;
> > the default value is "/dev/tty/[1-6]", which means that mingetty
> > will be started on ttys 1 through 6. Shell globs are accepted.
> 
> How hard would it be to make this be different in runlevels 3 and 5? I like
> to have lots in runlevel 3, and few if X is available.

Given how it's implemented, you could do something truly disgusting like

ACTIVE_CONSOLES=$([ "$RUNLEVEL" = 3 ] && echo '/dev/tty[1-6]' || echo 
'/dev/tty2')

I'm not sure I really want to *support* people doing that, though.

Bill

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

Re: ATTN: Changes to OCaml dependency generator for RPM 4.8 in Rawhide

[Panu Matilainen]

On Wed, 16 Dec 2009, Richard W.M. Jones wrote:


Since RPM 4.8 (now in Rawhide / Fedora 13), the external dependency
generator that we used to ship with OCaml has now gone upstream into
RPM.  This is a Good Thing, thanks to the RPM maintainers for adding
this.

If you own an OCaml library package, then there are some simple
adjustments you need to make to your OCaml spec files _in Rawhide_.

First of all, remove any lines that are exactly like any of these:

 %define _use_internal_dependency_generator 0
 %global _use_internal_dependency_generator 0
 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
 %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh
 %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
 %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh

Any remaining calls to ocaml-find-{requires,provides}.sh must be ones
which take parameters, and these need to be modified.

Change:

 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh 
or:
 %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh 

to:

 %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh 


Better yet, instead of overriding the __ocaml_requires (and _provides) 
macros, use the new option passing mechanism. See below...




and the same for "provides" instead of "requires".

For example, if your original spec files contained this block:

 %define _use_internal_dependency_generator 0
 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh -i Asttypes -i 
Parsetree
 %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh

then following the rules above it would become:

 %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh -i Asttypes 
-i Parsetree


With the new rpm, all you need to have in the spec for this case is:

%global __ocaml_requires_opts -i Asttypes -i Parsetree

These will get passed to __ocaml_requires automatically when it runs, 
and similarly to pass options to provides script, define 
__ocaml_provides_opts macro to your liking.


Oh and this is not ocaml-specific, any of the __foo_requires / 
__foo_provides helpers accept options in the same manner.


- Panu -

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

[Seth Vidal]

On Wed, 16 Dec 2009, Nathanael D. Noblet wrote:


So again today, I see some updates two of which require a full system reboot.

nfs-utils and ibus-rawcode. My system seriously needs to be shut down for 
those to be properly updated? This is what I don't get. nfs-utils never got a 
system reboot before, it doesn't get one on RHEL/Centos boxes... What 
requires a reboot here? Again, I don't want the tone of this email to come 
off as anger, rude or whatever, mainly I'm wondering why so many packages 
require a reboot, why isn't nfs-utils just restarting any services it has or 
that depend on it if needed? Is that not reliable?





you're an experienced user? You're comfortable knowing what does and what 
does not require a reboot? Then why are you using PK?


Disable pk and do the updates directly via yum.

Bam - no more requests to reboot.

-sv

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

[Peter Jones]

On 12/16/2009 11:43 AM, Seth Vidal wrote:
> you're an experienced user? You're comfortable knowing what does and
> what does not require a reboot? Then why are you using PK?
> 
> Disable pk and do the updates directly via yum.
> 
> Bam - no more requests to reboot.

I get what you're saying, and it's kindof a fair point, but there's also
some utility to having the system automatically, proactively notify you
of updates.

-- 
Peter

For some reason it has always seemed to me that the term software 
engineering contains some very optimistic assumptions about the 
nature of reality.

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

[Seth Vidal]

On Wed, 16 Dec 2009, Peter Jones wrote:


On 12/16/2009 11:43 AM, Seth Vidal wrote:

you're an experienced user? You're comfortable knowing what does and
what does not require a reboot? Then why are you using PK?

Disable pk and do the updates directly via yum.

Bam - no more requests to reboot.


I get what you're saying, and it's kindof a fair point, but there's also
some utility to having the system automatically, proactively notify you
of updates.


And you can do that. Just don't have pk DO the update.

There are lots of ways to get notifications of updates not using PK in the 
system.


And again, we're not talking about for the default everyday user.

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

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

[Chris Adams]

Once upon a time, Seth Vidal  said:
> we're talking about the experienced user who is comfortable knowing what 
> does and does not need a reboot.

It seems though that there is a problem with how the "needs a reboot"
option is set (and if that is the case, it should be addressed).  For
example, in the nfs-utils case, what happened to having the %post
scriptlet do "service foo condrestart"?  Is it impossible to restart the
daemons?

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

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

[Seth Vidal]

On Wed, 16 Dec 2009, Chris Adams wrote:


Once upon a time, Seth Vidal  said:

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


It seems though that there is a problem with how the "needs a reboot"
option is set (and if that is the case, it should be addressed).  For
example, in the nfs-utils case, what happened to having the %post
scriptlet do "service foo condrestart"?  Is it impossible to restart the
daemons?


well nfs restarts have never been likely to work if something is mounted 
iirc.


but I'm not the nfs expert here - maybe steve dickson can better answer 
this.

-sv

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

Re: ATTN: Changes to OCaml dependency generator for RPM 4.8 in Rawhide

[Richard W.M. Jones]

On Wed, Dec 16, 2009 at 06:34:09PM +0200, Panu Matilainen wrote:
> With the new rpm, all you need to have in the spec for this case is:
>
> %global __ocaml_requires_opts -i Asttypes -i Parsetree
>
> These will get passed to __ocaml_requires automatically when it runs,  
> and similarly to pass options to provides script, define  
> __ocaml_provides_opts macro to your liking.

OK, I didn't see that, but that's even better.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html

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

[Nathanael D. Noblet]

On 12/16/2009 09:51 AM, Seth Vidal wrote:



On Wed, 16 Dec 2009, Peter Jones wrote:


On 12/16/2009 11:43 AM, Seth Vidal wrote:

you're an experienced user? You're comfortable knowing what does and
what does not require a reboot? Then why are you using PK?

Disable pk and do the updates directly via yum.

Bam - no more requests to reboot.


I get what you're saying, and it's kindof a fair point, but there's also
some utility to having the system automatically, proactively notify you
of updates.


And you can do that. Just don't have pk DO the update.

There are lots of ways to get notifications of updates not using PK in
the system.

And again, we're not talking about for the default everyday user.

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.


yeah, I totally get what you mean. I just feel like there are more and 
more reboot requests because that is easier. Obviously I know when/if I 
need to reboot based on what I'm running. However I'm questioning the 
number of packages requesting a reboot I guess.


Maybe this is a feature that needs to be addressed in the rpm layer or 
something so that upgrades can have multiple effects with regards to 
needing a reboot. I'm not sure how PK gets the request to reboot from a 
package, but I'm wondering about it. For example, why aren't some of the 
packages simply a 'log out of X', or 'restart app', or ??? PK could 
provide that information. However, as it stands, if firefox is updated, 
I would (under the current way this seems to work) fully expect it to 
ask for my system to reboot, instead of closing FF and starting it 
again. I'm not sure if it does or not, but it seems like a package 
basically has complex upgrade issues, so we reboot. Are there other tags 
packages can have other than reboot? Should there be? etc etc..


I am an advanced user, and manage a handful of servers and workstations, 
so yes I don't have to reboot. I'm just wondering about the reboot 
'feature' usage patterns I'm seeing.


--
Nathanael

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

[Seth Vidal]

On Wed, 16 Dec 2009, Nathanael D. Noblet wrote:

Maybe this is a feature that needs to be addressed in the rpm layer or 
something so that upgrades can have multiple effects with regards to needing 
a reboot. I'm not sure how PK gets the request to reboot from a package, but 
I'm wondering about it.


It doesn't get it from the pkg. It uses the updateinfo.xml metadata that 
is generated by our update processing system that is called 'bodhi'.


You can see this data using the yum-security plugin.

seems like a package basically has complex upgrade issues, so we reboot. Are 
there other tags packages can have other than reboot? Should there be? etc 
etc..


No.


I am an advanced user, and manage a handful of servers and workstations, so 
yes I don't have to reboot. I'm just wondering about the reboot 'feature' 
usage patterns I'm seeing.


And again. PK is not designed for you. The 'reboot often' solution is not 
FOR you.


I said this earlier on another subject but you shouldn't be shocked that 
camels are slow swimmers.


-sv

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

Fedora update submission page broken for multiple packages

[Tom Lane]

I tried to submit an update for both the fc12 and fc11 versions of
postgresql.  It did not work; I had to file them as separate updates.
I'm pretty sure it used to work --- is my memory failing me, or is
this new breakage?  If the latter, where do I file bugs against the
submission webpage?

regards, tom lane

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

[Nathanael D. Noblet]

On 12/16/2009 10:11 AM, Seth Vidal wrote:



On Wed, 16 Dec 2009, Nathanael D. Noblet wrote:


Maybe this is a feature that needs to be addressed in the rpm layer or
something so that upgrades can have multiple effects with regards to
needing a reboot. I'm not sure how PK gets the request to reboot from
a package, but I'm wondering about it.


It doesn't get it from the pkg. It uses the updateinfo.xml metadata that
is generated by our update processing system that is called 'bodhi'.

You can see this data using the yum-security plugin.


Cool.




seems like a package basically has complex upgrade issues, so we
reboot. Are there other tags packages can have other than reboot?
Should there be? etc etc..


No.


The reason for this is that PKs target audience is not someone like me, 
and as such no need to provide different messages per package?





I am an advanced user, and manage a handful of servers and
workstations, so yes I don't have to reboot. I'm just wondering about
the reboot 'feature' usage patterns I'm seeing.


And again. PK is not designed for you. The 'reboot often' solution is
not FOR you.

I said this earlier on another subject but you shouldn't be shocked that
camels are slow swimmers.


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.


So one last question then, in the case of nfs-utils, (ignoring for now 
any nfs specific restart/condrestart issues). The packaging guidlines 
will continue to require that a post update script does what is sensible 
for an update, and not just depend on the admin rebooting their server?


--
Nathanael

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

[Michał Piotrowski]

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?

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

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

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

Re: packages requiring me to reboot...

[nodata]

Am 2009-12-16 17:51, schrieb Seth Vidal:



On Wed, 16 Dec 2009, Peter Jones wrote:


On 12/16/2009 11:43 AM, Seth Vidal wrote:

you're an experienced user? You're comfortable knowing what does and
what does not require a reboot? Then why are you using PK?

Disable pk and do the updates directly via yum.

Bam - no more requests to reboot.


I get what you're saying, and it's kindof a fair point, but there's also
some utility to having the system automatically, proactively notify you
of updates.


And you can do that. Just don't have pk DO the update.

There are lots of ways to get notifications of updates not using PK in
the system.

And again, we're not talking about for the default everyday user.

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.

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

[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

--
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 Wed, Dec 16, 2009 at 12:15:37PM -0500, Tom Lane wrote:
> I tried to submit an update for both the fc12 and fc11 versions of
> postgresql.  It did not work; I had to file them as separate updates.
> I'm pretty sure it used to work --- is my memory failing me, or is
> this new breakage?  If the latter, where do I file bugs against the
> submission webpage?
> 
It definitely worked prior to the move this weekend.  Do you have any error
messages or other information to help track this down?

There are two places that you could file this:

https://fedorahosted.org/bodhi
https://fedorahosted.org/fedora-infrastructure

-Toshio


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

[Seth Vidal]

On Wed, 16 Dec 2009, Nathanael D. Noblet wrote:


seems like a package basically has complex upgrade issues, so we
reboot. Are there other tags packages can have other than reboot?
Should there be? etc etc..


No.


The reason for this is that PKs target audience is not someone like me, and 
as such no need to provide different messages per package?


No, the reason for this is there  is not more to go on, yet. I would love 
to require more detailed info on the update including if it is an 
important/trivial/security/packaging/upstream-update or what not fix.



Hands are needed to help advance this. Care to lend one?




And again. PK is not designed for you. The 'reboot often' solution is
not FOR you.

I said this earlier on another subject but you shouldn't be shocked that
camels are slow swimmers.


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.


If what the experienced user wants to do is not something that PK can do 
or can be configured to do then, yes, disable it and move along.


Hell, same thing is true of yum. If you really know what you're doing and 
yum is in your way then stop using it.



So one last question then, in the case of nfs-utils, (ignoring for now any 
nfs specific restart/condrestart issues). The packaging guidlines will 
continue to require that a post update script does what is sensible for an 
update, and not just depend on the admin rebooting their server?


the post scripts do what is sensible, on many occasions restarting the 
daemon will not ensure that the new sw is in use and in other occasions 
there is no graceful way to restart.


so your options are:

1. don't restart but ask the user to
2. restart and drop whatever connections are active.

neither are great.

-sv

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


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

[Andreas Schwab]

Toshio Kuratomi  writes:

> On Wed, Dec 16, 2009 at 10:13:33AM +0100, Andreas Schwab wrote:
>> Jesse Keating  writes:
>> 
>> > On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote:
>> >> 
>> >> My thinking is that we don't use origin/next or origin/maint either
>> >> and both are common upstream in git and the kernel.
>> >> 
>> >> While origin/master is common, 
>> >
>> > origin/master isn't "common", it's the friggin default.  Every single
>> > git repo I interact with has development happening on origin/master.
>> > It's way more than just "common".
>> 
>> You can set any branch as default via origin/HEAD, and some do.  It is
>> also easy to make origin/devel an alias for origin/master.
>
> So what's an alias?

See git-symbolic-ref(1).  HEAD is an example.

> If that's so, that's a much better solution than a symlink.

They used to be implemented with a symlink.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

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

[Seth Vidal]

On Wed, 16 Dec 2009, nodata wrote:


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


Then I can think of a couple of solutions to this problem:

1. Have fewer update pushes per release - this is something I'm actively 
advocating and I think is possible


2. Match up more updates to a specific running app so we can see if the 
reboot is really necessary at all. - something else I've wrriten some code 
in support of.


How would you like to help in these goals?

-sv

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

[Nathanael D. Noblet]

On 12/16/2009 10:28 AM, Seth Vidal wrote:



On Wed, 16 Dec 2009, Nathanael D. Noblet wrote:


seems like a package basically has complex upgrade issues, so we
reboot. Are there other tags packages can have other than reboot?
Should there be? etc etc..


No.


The reason for this is that PKs target audience is not someone like
me, and as such no need to provide different messages per package?


No, the reason for this is there is not more to go on, yet. I would love
to require more detailed info on the update including if it is an
important/trivial/security/packaging/upstream-update or what not fix.


Hands are needed to help advance this. Care to lend one?


Yes. I'm attempting to become more involved. I've submitted my first 
package, and am going through the review process. That doesn't help in 
this particular case, but I am not complaining for the sake of 
complaining. I want to help. I fully realize what I use daily for work 
is the result of many people like you who build this stuff. Thus my 
desire to become part of it.


What can I do here?


the post scripts do what is sensible, on many occasions restarting the
daemon will not ensure that the new sw is in use and in other occasions
there is no graceful way to restart.

so your options are:

1. don't restart but ask the user to
2. restart and drop whatever connections are active.

neither are great.


For sure.

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

[Seth Vidal]

On Wed, 16 Dec 2009, Nathanael D. Noblet wrote:



Hands are needed to help advance this. Care to lend one?


Yes. I'm attempting to become more involved. I've submitted my first package, 
and am going through the review process. That doesn't help in this particular 
case, but I am not complaining for the sake of complaining. I want to help. I 
fully realize what I use daily for work is the result of many people like you 
who build this stuff. Thus my desire to become part of it.


What can I do here?


How much python do you know? We need some time spent on the updateinfo.xml 
and what information we provide there and tying this in with what info is 
required from packagers submitting updates to their pkgs.



Another good angle to approach is to talk to the folks in fedora-qa and 
see where they can use a hand.



-sv

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

[Nathanael D. Noblet]

On 12/16/2009 10:38 AM, Seth Vidal wrote:



On Wed, 16 Dec 2009, Nathanael D. Noblet wrote:



Hands are needed to help advance this. Care to lend one?


Yes. I'm attempting to become more involved. I've submitted my first
package, and am going through the review process. That doesn't help in
this particular case, but I am not complaining for the sake of
complaining. I want to help. I fully realize what I use daily for work
is the result of many people like you who build this stuff. Thus my
desire to become part of it.

What can I do here?


How much python do you know? We need some time spent on the
updateinfo.xml and what information we provide there and tying this in
with what info is required from packagers submitting updates to their pkgs.


Unfortunately very very little. I can program in C/C++ and PHP. I've 
used python years ago. However I can learn if I have to.



Another good angle to approach is to talk to the folks in fedora-qa and
see where they can use a hand.


Will do.

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

[Tom Lane]

Toshio Kuratomi  writes:
> On Wed, Dec 16, 2009 at 12:15:37PM -0500, Tom Lane wrote:
>> I tried to submit an update for both the fc12 and fc11 versions of
>> postgresql.  It did not work; I had to file them as separate updates.
>> I'm pretty sure it used to work --- is my memory failing me, or is
>> this new breakage?  If the latter, where do I file bugs against the
>> submission webpage?
>> 
> It definitely worked prior to the move this weekend.  Do you have any error
> messages or other information to help track this down?

Thinking back on it, it was probably at least partly user error, but
there should have been a way to recover.

> There are two places that you could file this:
> https://fedorahosted.org/bodhi

Thanks for the pointer, filed at
https://fedorahosted.org/bodhi/ticket/374

regards, tom lane

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


"It works for me" is a poor standard of support.


There must be something transmogrifying my emails before it reaches 
other subscribers of this list, either that or I am being 
unreasonable in thinking that by asking /if/ Fedora would consider 
*supporting* this configuration (i.e. in the future) that it would be 
clear that:


- I do not expect it to be supported already
- I am not complaining about software not working quite right now

E.g. I was impressed at how yum pretty much works (with minor 
tweaking to override which arch it think it's running on).


I didn't mean to complain or whinge or intend for people to think I 
had silly expectations of this being supported already. Apologies if 
I did and/or if that's how it came across.


regards,
--
Paul Jakma  p...@jakma.org  Key ID: 64A2FF6A
Fortune:
ASHes to ASHes, DOS to DOS.

--
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?)

[Debarshi Ray]

>> "It works for me" is a poor standard of support.
>
> There must be something transmogrifying my emails before it reaches other
> subscribers of this list, either that or I am being unreasonable in thinking

He is just pointing out that there is lot more work to do than you
think. In other words he is contesting your claim that "The kernel
side apparently works fine AFAICT".

Cheers,
Debarshi
-- 
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig

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

[Lennart Poettering]

On Wed, 09.12.09 13:51, Christof Damian (chris...@damian.net) wrote:

> 
> On Tue, Dec 8, 2009 at 12:59, Tomasz Torcz  wrote:
> > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote:
> >  pavucontrol is regarded as advance tool, but also partly
> > obsolete. Current gnome-volume-control superseded most of
> > its functionality: controlling different streams volume,
> > switching profile, outputs, fallback devices.
> 
> I am curious: If pavucontrol is obsolete, is there some other tool to
> tell skype to use headsets, while rhythmbox uses the speakers?

This is about the only feature still only available in pavucontrol,
that we'd like to support in g-v-c as well. During GUADEC we discussed
a few possible designs for this, so hopefully this will come soon.

> pavucontrol currently crashes (and pulseaudio) for me on one machine
> and I need this functionality.

File a bug.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4

-- 
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?)

[Matthew Garrett]

On Wed, Dec 16, 2009 at 06:29:17PM +, Paul Jakma wrote:
> On Wed, 16 Dec 2009, Matthew Garrett wrote:
>
>> "It works for me" is a poor standard of support.
>
> There must be something transmogrifying my emails before it reaches  
> other subscribers of this list, either that or I am being unreasonable in 
> thinking that by asking /if/ Fedora would consider *supporting* this 
> configuration (i.e. in the future) that it would be clear that:
> - I am not complaining about software not working quite right now

The problem here is that you appear to be massively underestimating the 
amount of work that would be required to actually support this 
configuration. We'd need to audit every ioctl entry point, every file in 
proc and every sysfs attribute. We'd need to port every application that 
uses vm86 over to using x86emu. We'd need to add, test and support a 
32-to-64 bit cross building toolchain. yum would need some amount of 
work that Seth has implied is significant. That's a lot of work for 
marginal benefits, and nobody seems interested in stepping up to do that 
work.

-- 
Matthew Garrett | mj...@srcf.ucam.org

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

Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10

[Matthew Miller]

On Wed, Dec 16, 2009 at 11:23:31AM -0500, Bill Nottingham wrote:
> > How hard would it be to make this be different in runlevels 3 and 5? I like
> > to have lots in runlevel 3, and few if X is available.
> Given how it's implemented, you could do something truly disgusting like
> ACTIVE_CONSOLES=$([ "$RUNLEVEL" = 3 ] && echo '/dev/tty[1-6]' || echo 
> '/dev/tty2')
> I'm not sure I really want to *support* people doing that, though.

You mean, you don't like the idea of having different numbers of consoles
running in different runlevels, or you don't like the
abusing-shell-script-as-config-file thing?

It's not a big deal, but it's something that's trivially done in traditional
inittab.

-- 
Matthew Miller 
Senior Systems Architect 
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

-- 
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, Debarshi Ray wrote:

He is just pointing out that there is lot more work to do than you 
think. In other words he is contesting your claim that "The kernel 
side apparently works fine AFAICT".


Well, I don't really know how to else to counter "there may be 
unknown bugs". Kernel sub-system interfaces generally are 
well-designed and specified (i.e. explicit widths of fields). Booting 
a system and using it for a while exercises many of the important 
ones.


Could there be bugs in some lesser-used, oddball interface? Of course 
(and I am sure there are - I think I gave an example in a thread 
earlier this year). They're likely to reasonably trivial bugs though 
(oversights in the interface specification, e.g. a 'long' instead of 
a __u32, etc). If there really are interfaces that are so messed up 
that they'd be hard to fix up, then that's probably a warning sign 
that the code may have deeper, bigger problems.


People who run into such bugs can always go back to a 32bit kernel 
(standard or PAE) until it's fixed, if it even affects them. They're 
put back in the same position as they're in now, which I'm sure must 
be acceptable.


Anyway.. I'll try look into this again later next year, and see if I 
can fix the "bugs" (in the RFE sense for yum, libvirt) I found. Was 
simply hoping to get other people interested in 32-on-64, no more or 
less.


regards,
--
Paul Jakma  p...@jakma.org  Key ID: 64A2FF6A
Fortune:
"Do you believe in intuition?"
"No, but I have a strange feeling that someday I will."

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

--
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: upstart-0.6.3 in rawhide, tomorrow 2009-12-10

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> > Given how it's implemented, you could do something truly disgusting like
> > ACTIVE_CONSOLES=$([ "$RUNLEVEL" = 3 ] && echo '/dev/tty[1-6]' || echo 
> > '/dev/tty2')
> > I'm not sure I really want to *support* people doing that, though.
> 
> You mean, you don't like the idea of having different numbers of consoles
> running in different runlevels, or you don't like the
> abusing-shell-script-as-config-file thing?

The latter. :)

Bill

-- 
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/16/2009 03:43 PM, Otto Haliburton wrote:


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.


Even when it asks, it does that with a modal focus-grabbing dialog 
window. I was once working on an important server, and was about to 
click OK on one of my dialog boxes, when a windows update confirmation 
popped up conveniently located so that my click went to IT, rebooting 
the server.  The queen was not amused.


HOWEVER, just because Windows suck doesn't mean that Linux should suck 
too. My own preference would be a more discriminating dialog
that offers three possibilities: 'do nothing', 'bounce the 
service/application' and 'reboot'.


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

[Jon Masters]

On Wed, 2009-12-16 at 16:30 -0500, Przemek Klosowski wrote:

> HOWEVER, just because Windows suck doesn't mean that Linux should suck 
> too. My own preference would be a more discriminating dialog
> that offers three possibilities: 'do nothing', 'bounce the 
> service/application' and 'reboot'.

Yup, +1

Jon.

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

Re: FUDConF13 videos

[Adam Williamson]

On Tue, 2009-12-15 at 09:31 -0600, Matt Domsch wrote:

> 2) The last 20 minutes of the Fedora Infrastructure: Sysadmins
>vs. Developers love-in.  I'm grateful to whoever shot this, but
>I've complete blanked on who it was now.  I'll be glad to give you
>attribution, please remind me!
> 
> http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-infrastructure-roundtable.ogg
> 
> If anyone else has video or audio from this or other Fedora events
> you'd care to share, please contact me and I'll help you get it into
> proper ogg format, tagged, and posted to Fedora Infrastructure servers
> for distribution.

That was me. :) I actually think Remy DeCausemaker was sitting in that
talk with his little recorder box - I don't know if it's only a voice
recorder, or also video. But he may have the whole thing. Have you
contacted him?
-- 
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

kernel/accounting question ...

[William W. Austin]

(I know that this question might be more reasonable on a kernel list,  
but a while back I posted the question twice and got no answers.)


The acct struct is defined in /usr/include/sys/acct.h includes both  
ac_io and ac_rw for bytes transferred and blocks read or written,  
respectively.  Fair and good - works (on paper) similarly to unix,  
solaris, hp-ux, etc.


However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw  
(blocks) are always set to 0 by these two lines:


ac.ac_io = encode_comp_t(0 /* current->io_usage */);
ac.ac_rw = encode_comp_t(ac.ac_io / 1024);

For most purposes, this probably wouldn't be an issue, but I also do  
extensive performance analysis on several platforms and have written a  
fairly compresive accounting package (as a wraparound for psacct or as  
a standalone) including both an improved acctcom and a built-in  
reporter for it.


Does anyone know wby the kernel zero's out the bytes transferred data?  
(Overhead comes to mind.) Not that it makes a huge differnce for my  
purposes (I had to write some wraparound code to make a  
"best-guestimate" about the data I'm missing), but curiosity is bugging  
me now.  When I compile my program on other OS's I get useful data for  
char and block i/o and I'd like to find out whether there is something  
obvious that I'm just totally missing here...).


Thanks

--
william w. austin   waus...@speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."


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

Re: kernel/accounting question ...

[Peter Jones]

On 10/19/2006 08:23 AM, William W. Austin wrote:
> 

Not that I've got an answer for your question, but you might want to
tell your computer that it's not 2006.

-- 
Peter

When privacy is outlawed only outlaws will have privacy.
-- Zimmermann

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

Re: kernel/accounting question ...

[Kevin Fenzi]

On Thu, 19 Oct 2006 08:23:49 -0400
"William W. Austin"  wrote:

> 
> (I know that this question might be more reasonable on a kernel
> list, but a while back I posted the question twice and got no
> answers.)

Possibly because the system you are sending email from thinks it's
2006, so many people wouldn't notice your old post if they are sorting
by date?



Fix your date and try the kernel list again?

kevin


signature.asc
Description: PGP signature
-- 
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

[Adam Williamson]

On Wed, 2009-12-16 at 10:42 -0500, Simo Sorce wrote:

> But for anyone that does not using "master" as the default branch will
> be a problem. If you never used git you have to learn a lot of things
> anyway.

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/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: Wednesday, December 16, 2009 15:30
> To: fedora-devel-list@redhat.com
> Subject: Re: packages requiring me to reboot...
> 
> On 12/16/2009 03:43 PM, Otto Haliburton wrote:
> 
> > 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.
> 
> Even when it asks, it does that with a modal focus-grabbing dialog
> window. I was once working on an important server, and was about to
> click OK on one of my dialog boxes, when a windows update confirmation
> popped up conveniently located so that my click went to IT, rebooting
> the server.  The queen was not amused.
> 
> HOWEVER, just because Windows suck doesn't mean that Linux should suck
> too. My own preference would be a more discriminating dialog
> that offers three possibilities: 'do nothing', 'bounce the
> service/application' and 'reboot'.
There is always the circle jerk argument, well linux reboots more than
windows, no, windows abandoned the mandatory restart to end up reinstating
it.  Then, because windows restarts after update sucks, so linux doesn't
need to suck like windows.  Rebooting after updates is not a trivial matter,
if you are a expert don't use PackageKit.  Even tho it notifies you of
updates doesn't mean you need to use it, there is synaptic, yum extender,
yum, etc. none of those require you to reboot, also I don't think that
PackageKit mandates a reboot, just asks and you can cancel out of it, I
don't remember now, but I think so I know it flags the packages that cause a
restart.  Anyway nothing will be solved in this thread, for those of us that
have been burned by failing to restart, and those that think that rebooting
after updates is trivial, will continue to do the things that are required
for us to be satisfied in a update.
> 
> --
> 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

acctcom for linux

[William W. Austin]

I recently made several updates to a Linux version of of acctcom  
(actually another accounting add-on package) which I've been using for  
several years, and one of the people testing it asked a question which  
I cannot answer.  I'm hoping that someone on this list can give me some  
info.


I have previously (over a year ago) asked on both this and a couple of  
kernel lists (several times there) about this issue, but nobody has  
ever answered.  So if you have any info about this, I'd really  
appreciate it.


As in many (all?) previous Linux kernels, the struct acct (defined in
/usr/include/sys/acct.h) has members ac_io and ac_rw which are  
presumably counts of characters transferred and blocks read/written  
respectively.


However, in the kernel code, the ac_io is set to 0 and the ac_rw gets  
set to (ac_io/512) or some such - it is set to 0 as well (and thus  
these are always reported as 0 in process accounting records.  not good  
if you're trying to measure them...).


Does anybody know why this is done that way?  A long time ago (IIRC  
late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the  
kernel code but was not successful (I finally produced a bootable  
kernel, but it was unstable.  Then I changed jobs, got swamped at work,  
and eventually gave up).


As I said above, I have previously asked about this issue without  
success, and I have essentially given up changing or "fixing" it.


But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's  
just too much work for too little added value), I'd really appreciate  
knowing the reason.  Curiosity and the cat and all that ...


Thanks
- Bill

--
william w. austin   waus...@speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."


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

[Gregory Maxwell]

On Wed, Dec 16, 2009 at 11:43 AM, Seth Vidal  wrote:
> you're an experienced user? You're comfortable knowing what does and what
> does not require a reboot? Then why are you using PK?
>
> Disable pk and do the updates directly via yum.
>
> Bam - no more requests to reboot.

This is a completely bogus rationale but one I commonly hear on this list.

I, and many other fedora users would be quite *capable* of running our
systems with any help of a distribution, we could go and fetch from
source and do all the integration ourselves...

...but we'd actually like to get some work done using our computers
and don't want to burn our lives away playing master-of-my-own-distro,
though we're willing to spend some time contributing to a shared
effort to build a good distribution for many.

In exchange for not having to personally micro-manage things, we're
willing to tolerate some things being configured in violation of our
own preferences or aesthetics, or even a few things being outright
broken, but that doesn't mean that it's not important for it to work
right.

Yes, I'm quite capable of executing some big manual process or
changing packagekit to behave like I want. But every such action has
costs, it takes time and effort which usually has to be repeated every
upgrade. The non-standard configuration carries the risk of triggering
bugs in other system components, breaking the upgrade process, etc.

The gratuitous reboots are harmful to all users.  They diminish a
significant advantage our systems can have compared to alternatives
like Microsoft Windows. They discourage the reporting of bugs in
applications… "System acting weird? Just restart!".  When triggered at
inconvenient times they can cause significant harm by interrupting
people's work.

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.

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

Re: Possible wrong versions tagged into f12-final

[Jesse Keating]

On Mon, 2009-11-09 at 11:19 +, Quentin Armitage wrote:
> I've noticed what might be a couple of anomalies regarding which
> versions of packages have been tagged into f12-final.  
> 
> freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but
> 0.9-10.fc11 tagged has been tagged into f12-final.
> 
> gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but
> 0.8.14.3.fc11 has been tagged into f12-final. It appears that
> 0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12
> rebuild).
> 
> Quentin Armitage
> 
> 

Yeah, looks like some fallout around the mass rebuild and getting things
tagged over.  Too late to do anything about F12 now, owners of those
packages might consider issuing updates (which would then be picked up
in F13)

-- 
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: packages requiring me to reboot...

[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

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

Re: Possible wrong versions tagged into f12-final

[Jonathan Underwood]

2009/12/16 Jesse Keating :
> On Mon, 2009-11-09 at 11:19 +, Quentin Armitage wrote:
>> I've noticed what might be a couple of anomalies regarding which
>> versions of packages have been tagged into f12-final.
>>
>> freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but
>> 0.9-10.fc11 tagged has been tagged into f12-final.
>>
>> gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but
>> 0.8.14.3.fc11 has been tagged into f12-final. It appears that
>> 0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12
>> rebuild).
>>
>> Quentin Armitage
>>
>>
>
> Yeah, looks like some fallout around the mass rebuild and getting things
> tagged over.  Too late to do anything about F12 now, owners of those
> packages might consider issuing updates (which would then be picked up
> in F13)

Bug #548216 filed for freenx-client
Bug #548218 filed for gauche

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

Re: acctcom for linux

[Jesse Keating]

On Tue, 2007-05-01 at 08:38 -0400, William W. Austin wrote:
> 05/01/2007 05:38:26 AM (Tue, 01 May 2007 08:38:26 -0400)

Your date is still wrong.

-- 
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: Fedora update submission page broken for multiple packages

[Orcan Ogetbil]

On Wed, Dec 16, 2009 at 12:15 PM, Tom Lane wrote:
> I tried to submit an update for both the fc12 and fc11 versions of
> postgresql.  It did not work; I had to file them as separate updates.
> I'm pretty sure it used to work --- is my memory failing me, or is
> this new breakage?  If the latter, where do I file bugs against the
> submission webpage?
>

When I tried submitting the same update for different Fedora releases
about a year ago, it did not work. I do not remember the error
message, but I figured that there was a policy to submit packages to
different Fedora releases separately. Since then I probably made
hundreds of updates each filed separately.

If there is a way to file an update (same version and release except
the disttag) to multiple branches, please let me know.

Thanks
Orcan

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

[Tom Lane]

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

The case I was complaining about seems to be that adding a new package
to an *existing* update request doesn't work.  If you get it right
before you hit "submit", it's worked for awhile.

regards, tom lane

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

Re: acctcom for linux

[Tony Nelson]

On 09-12-16 18:19:17, Jesse Keating wrote:
> On Tue, 2007-05-01 at 08:38 -0400, William W. Austin wrote:
> > 05/01/2007 05:38:26 AM (Tue, 01 May 2007 08:38:26 -0400)
> 
> Your date is still wrong.

No, the date is correct.  That's when the message was sent the first 
time around -- it's in the list archives.

I don't think he reads the list anymore.  I don't think he's aware that 
this is happening, so I've CC'd him.

-- 

TonyN.:'   
  '  

-- 
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: "Gregory Maxwell" 
To: "Development discussions related to Fedora" 


Sent: Wednesday, December 16, 2009 5:01 PM
Subject: Re: packages requiring me to reboot...


On Wed, Dec 16, 2009 at 11:43 AM, Seth Vidal  
wrote:

you're an experienced user? You're comfortable knowing what does and what
does not require a reboot? Then why are you using PK?

Disable pk and do the updates directly via yum.

Bam - no more requests to reboot.


This is a completely bogus rationale but one I commonly hear on this list.

I, and many other fedora users would be quite *capable* of running our
systems with any help of a distribution, we could go and fetch from
source and do all the integration ourselves...

that my friend is the open source concept.  The users test, develop, & 
create new ideas

for development.


...but we'd actually like to get some work done using our computers
and don't want to burn our lives away playing master-of-my-own-distro,
though we're willing to spend some time contributing to a shared
effort to build a good distribution for many.


then go commercial, you pays your money you get your dues


In exchange for not having to personally micro-manage things, we're
willing to tolerate some things being configured in violation of our
own preferences or aesthetics, or even a few things being outright
broken, but that doesn't mean that it's not important for it to work
right.


how much do you pay for Fedora, as I remember I think it is free!!!


Yes, I'm quite capable of executing some big manual process or
changing packagekit to behave like I want. But every such action has
costs, it takes time and effort which usually has to be repeated every
upgrade. The non-standard configuration carries the risk of triggering
bugs in other system components, breaking the upgrade process, etc.


as I said go commercial!!


The gratuitous reboots are harmful to all users.  They diminish a
significant advantage our systems can have compared to alternatives
like Microsoft Windows. They discourage the reporting of bugs in
applications… "System acting weird? Just restart!".  When triggered at
inconvenient times they can cause significant harm by interrupting
people's work.


If that is so, then you and them are wasting your time with open source


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.

every one contributes.  It's free that is why you need to be more 
tolerant.

--
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: kernel/accounting question ...

[Kevin Kofler]

Peter Jones wrote:
> Not that I've got an answer for your question, but you might want to
> tell your computer that it's not 2006.

William W. Austin (or possibly his ISP, Speakeasy) is actually resending 
mail which was originally sent back in 2006. I got 2 extra copies of a mail 
I already received back in 2006.

Kevin Kofler

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

Re: Static linking considered harmful

[William W. Austin]

On 2006-11-22 05:37:43, Patrice Dumas  wrote:


On Wed, Nov 22, 2006 at 10:29:44AM +, Andrew Haley wrote:
>  >
>  > Not only. There are cases when all those issues are moot,
>  > a prominent one
>  > being for numerical models. Compiling models statically makes
>  > it possible
>  > to run them on any other linux (including different fedora
>  > version) box
>  > without recompiling. So all the libraries that can be used for
>  > numerical
>  > computations should have static libraries kept.
>
> This seems like a non sequitur.  What's special about numerical
> computations?

I already explained it in my mail? To be more precise

* security considerations are moot
* nss, iconv are not needed

Other arguments for dynamic linking are not compulsory.



And numerical models are programs we would like to be able to run
on other linux box without recompiling. Imagine that compilation
takes 30 minutes and that you want to start 20 runs in paralell
from nfs mounted filesystem in an heterogeneous linux environment
with some redhat 6.2, 7.x, centos, debian, mandrake and fedora
core (real world example, of course).

--
Pat


I have to agree with Patrice Dumas.  I regularly do extensive numerical  
analysis and modeling using such a network, and the compilation time  
for the central program is VERY long, taking over 40 minutes on the  
fastest machine I have available. While I don't think we have anything  
older than RH8 in the pool of runtime machines, many of them cannot be  
upgraded for other reasons (I don't own them - I just get to use them  
when they are available, so the pool of machines changes probably every  
time I visit phase space), and if I had to do a compile for every  
different O/S+release combination I'm using, it would be a nightmare.


While my run time is longer than Pat's example (a little over 4 hours  
using around 30 machines), if I had to recompile for each of the  
different variations I use, it would be prohibitively time-consuming  
and would be a reason to stop upgrading several machines here.


I don't know whether eliminating static libraries would be a problem  
for other types of apps, for what I'm doing its elimination would be a  
disaster.


While I don't see a problem with eliminating static linking of system  
utilities, IMHO eliminating it for user-written utilities is not a  
"universal benefit."


--
william w. austin   waus...@speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."


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

FUDCon Toronto: please take the 5-minute feedback survey

[Mel Chua]

FUDCon Toronto (http://fedoraproject.org/wiki/FUDCon:Toronto_2009) is 
over - our largest FUDCon yet! We'd love to get your thoughts on how it 
went, so:


* If you attended FUDCon Toronto, either in-person or remotely via 
Fedora Live, please take this survey and tell us what you thought.
* If you didn't attend FUDCon Toronto but wanted to, please take this 
survey and tell us how we can help you get to the next one.
* If you didn't want to go to FUDCon Toronto, please take this survey 
and tell us why - it's anonymous. ;-)


The survey is available at 
http://fedoraproject.limequery.org/index.php?sid=34266&lang=en


There are 29 questions, most of the yes/no variety; the survey takes 
less than 5 minutes to complete (I just timed myself). A special thanks 
to Robyn Bergeron, Yaakov Nemoy, and the rest of the Fedora Marketing 
team for designing the survey so it *can* be completed in less than 5 
minutes!


Questions are previewable at 
https://fedoraproject.org/wiki/FUDCon_survey. The survey will be active 
from 12/16/2009 through 1/8/2010, and we'll be analyzing and announcing 
the results shortly after it closes. If you're curious about the 
process, interested in helping us analyze the results, or have any 
questions in general, join the conversation on the Fedora Marketing 
mailing list 
(https://www.redhat.com/mailman/listinfo/fedora-marketing-list).


--Mel

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

[Mail Lists]

On 12/16/2009 03:51 AM, Richard Hughes wrote:
> 2009/12/16 Mail Lists :
>>   The last part is a clean up phase which could be deferred to reboot
>> or perhaps something a little more clever.
> 
> The devil is in the detail :)
> 
> Richard.
> 

 Yes but how are:


   (a) Kill app - install - restart

   (b) install in separate are - on reboot
   (app is now dead, flip link to new install - delete old)


 Any different?

  We have ways now of running things as the system is going down or
coming up ... don't we ?

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

[Ralf Corsepius]

On 12/16/2009 06:34 PM, Seth Vidal wrote:



On Wed, 16 Dec 2009, nodata wrote:


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


Then I can think of a couple of solutions to this problem:

1. Have fewer update pushes per release - this is something I'm actively
advocating and I think is possible

Depends on what you actually have in mind.

Simply letting update pile up would seem a silly idea to me, it 
contradicts Fedora's goal and removes what makes Fedora "attractive".


Letting pile up "updates, which require a reboot, but are not addressig 
real bugs", could be applicable.



2. Match up more updates to a specific running app so we can see if the
reboot is really necessary at all. - something else I've wrriten some
code in support of.

Yes, this would be helpful - But only in case of non-bugfix updates.

Bug-fix updates should be pushed ASAP, IMO.

3. Having better tools to avoid reboots.
(Consider daemons, servers).

4. Maintainers to be more careful/reluctant/conservative, when 
considering to update packages, which require a reboot.


Ralf

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


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

Cheers,
Christof

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

Rahul

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