date:20111004

Re: release number when upstream only has git hashes?

2011-10-04 Thread Eric Smith

I wrote:
 What should I use for the release number in a spec when upstream does 
 not have releases, and *only* has git hashes?  It's not a prerelease 
 since it is not clear that there will ever be any official release.

I meant version number, not release number.  I imagine that the 
release number should still be 0.1.mmddgithashprefix.  Or for 
this case, should the date and git hash go into the version?

Thanks,
Eric


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

2011-10-04 Thread Richard W.M. Jones

On Mon, Oct 03, 2011 at 05:33:47PM -0500, Eric Sandeen wrote:
 On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
  At 100T it doesn't run out of memory, but the man behind the curtain
  starts to show.  The underlying qcow2 file grows to several gigs and I
  had to kill it.  I need to play with the lazy init features of ext4.

Actually this one isn't too bad once I let it run to the finish.  The
qcow2 file ends up just 7.8G.  I'll try mounting it etc later.

 Bleah.  Care to use xfs? ;)

Just playing with ext4 at the limits :-)

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://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

2011-10-04 Thread Richard W.M. Jones

100T seems to work for light use.

I can create the filesystem, mount it, write files and directories and
read them back, and fsck doesn't report any problems.

Filesystem  Size  Used Avail Use% Mounted on
/dev/vda199T  129M   94T   1% /sysroot

Linux (none) 3.1.0-0.rc6.git0.3.fc16.x86_64 #1 SMP Fri Sep 16 12:26:22 UTC 2011 
x86_64 x86_64 x86_64 GNU/Linux

e2fsprogs-1.42-0.3.WIP.0925.fc17.x86_64

qcow2 is very usable as a method for testing at this size.

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://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

2011-10-04 Thread Farkas Levente

On 10/04/2011 01:03 AM, Eric Sandeen wrote:
 On 10/3/11 5:53 PM, Farkas Levente wrote:
 On 10/04/2011 12:33 AM, Eric Sandeen wrote:
 On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
 On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote:
 I wasn't able to give the VM enough memory to make this succeed.  I've
 only got 8G on this laptop.  Should I need large amounts of memory to
 create these filesystems?

 At 100T it doesn't run out of memory, but the man behind the curtain
 starts to show.  The underlying qcow2 file grows to several gigs and I
 had to kill it.  I need to play with the lazy init features of ext4.

 Rich.


 Bleah.  Care to use xfs? ;)

 why we've to use xfs? really? nobody really use large fs on linux? or
 nobody really use rhel? why not the e2fsprogs has too much upstream
 support? with 2-3TB disk the 16TB fs limit is really funny...or not so
 funny:-(
 
 XFS has been proven at this scale on Linux for a very long time, is all.

the why rh do NOT support it in 32 bit? there're still system that
should have to run on 32 bit:-(


-- 
  Levente   Si vis pacem para bellum!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

2011-10-04 Thread Farkas Levente

On 10/04/2011 01:03 AM, Eric Sandeen wrote:
 Large filesystem support for ext4 has languished upstream for a very
 long time, and few in the community seemed terribly interested to test it,
 either.  

why? that's what i simple do not understand!?...

-- 
  Levente   Si vis pacem para bellum!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: release number when upstream only has git hashes?

2011-10-04 Thread Ralf Corsepius

On 10/04/2011 08:04 AM, Eric Smith wrote:
 I wrote:
 What should I use for the release number in a spec when upstream does
 not have releases, and *only* has git hashes?  It's not a prerelease
 since it is not clear that there will ever be any official release.

 I meant version number, not release number.

OK, this makes a big difference.

If the project doesn't use an internal version number, I'd use 0 and 
never increment it.

  If the project has some internal version number (e.g. most autoconf 
based project have one, even if they don't have a release tarball), I'd 
use this one.

 I imagine that the
 release number should still be 0.1.mmddgithashprefix.

I'd use 0.mmddgithash.%{?dist} or similar.

The only points that count are
- Do not introduce (inofficial) version numbers (Upstream is the only 
authority to set them), because they may cause problems, should upstream 
once start to use version numbers.

- Within a version all release tags must be steadily incrementable and 
should provide sufficient human readable information to allow others to 
verify the tarball.

 Or for
 this case, should the date and git hash go into the version?

I'd recommend doing so, because this helps verifying/regenerating the 
tarball.

On a wider scope, I'd however question if such a project is mature and 
stable enough and maintained well enough to be included into Fedora. 
Many projects, which do not release tarballs in longer terms often prove 
to be poorly upstream maintained and to be problematic when it comes to 
inclusion into a distro (e.g. lack of stable APIs, SONAME etc).

Ralf
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

audio passthrough is still non-obvious

2011-10-04 Thread Ian Malone

Hi,

I'm not starting by filing this as a bug as it encompasses a number of
issues and it's not clear where the problem really lies, so I thought
I'd start a discussion here first.

I posted on what I'm trying to do previously (in F13) here:
http://lists.fedoraproject.org/pipermail/users/2010-October/384578.html

Basically I have a sound card, a guitar amplifier and a pair of
headphones on the front of my computer. I'd like to be able to have
the amp plugged into the back of the computer and hear the output
through the headphones with other sound (i.e. pulseaudio) still
working. Passthrough or monitoring the input if you like.

This is definitely possible, this is a real sound card and has a
hardware mixer. If I run alsa mixer, select the physical card and turn
on the AC97 mixer then the line-in gets mixed into the output. I'm
happy with that personally.

However it's really not obvious, and since the introduction of PA in
Fedora it hasn't been possible to easily access the hardware mixers
directly (as they're all hidden behind the PA device volume controls,
which also drive them in odd ways). I can see why that was done, and
it generally works okay now that drivers have been fixed (by card
initially had weird volume issues due to a driver issue), but now that
PA has matured we're still hiding one of the three functions of a
soundcard. (What can it do? It can play back, it can record, it can
pass through.) If the hardware capability is there then is should be
available, in some ways it's superior to anything discussed below. So
that's issue #1.

Someone will suggest I try module-loopback (see the email thread
referenced above and
http://thelinuxexperiment.com/guinea-pigs/jon-f/pulseaudio-monitoring-your-line-in-interface/
). This has a latency of somewhere between .5 and 1s and the
latency_msec option doesn't seem to be able to reduce this. This makes
it unsuitable for musical use, to which you might say 'use jack' (see
a bit further down). However this isn't doing anything particularly
complex and what many people might see as a basic feature (see the
many references to module-loopback across the web) doesn't need the
extra complications of running JACK. I think this is an issue with
module-loopback, particularly as the other pulseaudio solution:
parec --latency-msec=1 | pacat --latency-msec=1
has lower latency (still noticeable, but 1/2s, maybe 1/3rd)
It's still inferior to being able to employ the hardware mixer as that
doesn't require 10% CPU (on an Athlon 640). In addition, latency might
be acceptable for some other applications (e.g. a stereo or radio
going through the computer), but as you go to 1second even adjusting
volume on the source device becomes frustrating and, speaking of
volume, module-loopback doesn't really allow control of this easily.
For many applications access to the hardware mixer would be the best
solution. There are areas for which the pulseaudio loopback could be
useful, such as chaining a webcam microphone to the soundcard output,
but it's not universally suitable.

Finally JACK. This is an area which has improved. Back in F13 if I
wanted to include an effects loop rather than the pure passthrough
discussed above I had to:
1. Load qjackctl, get ready to hit start
2. run pulseaudio -k
3. Start jack
4. Load module-jack-source and module-jack-sink
5. The join up whatever path I wanted for the signal chain.
This tended to crash, it seems more stable now (stable enough that I
can use it as an alternative loopback too), so kudos to the people
working on that. However the setup is a bit convoluted, and it seems a
pity the module-jackdbus-detect isn't available (or doesn't work as it
might help avoid the juggling needed:
pactl load-module module-jackdbus-detect
Failure: Module initalization failed

93 matches

Mail list logo