date:20110223

On Tue, 22.02.11 22:25, Jon Masters (jonat...@jonmasters.org) wrote:

 
 On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:
 
  2) Fedora 16 ships without LVM as the volume manager and instead use
  BTRFS's built in volume management, again just for the default.
 
 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.
 
 Should the switch to BTRFS by default happen, this will be one more
 thing I will have to fix immediately during installation. The list grows
 longer and longer over time - please don't make this change.

Aren't you exaggerating your conservatism a bit?

Are there actually new Fedora features you do support? The only signal
you appear to be sending all the time is NO!.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Manipulate Dev. release number properly

2011-02-23 Thread Petr Pisar

On Wed, Feb 23, 2011 at 08:18:53PM +0800, Robin Lee wrote:
 We can use the v-string feature provided by Perl itself to normalize the
 version numbers of CPAN module rpms. We always convert the legacy decimal
 versions to normalized v-string, and use the v-string number as the rpm
 version, since v-string is friendly with rpm and also works within the Perl
 world.
 
 We can get a normalized v-string like this:
 
 Perl require version;
 1
 Perl version-parse(1.94_56)-normal
 v1.945.600
 
 So the rpm version of perl(CPAN) should be 1.945.600 , and the one of
 perl(Moose) should be 1.120 .
 
I've alredy proposed something similar at
https://fedoraproject.org/wiki/Perl/Tips#Dot_approach, converting all
decimal digits to single-placed version components: 1.94_56 → 1.9.4.5.6.

Provided version module deals with it too and it's provided by Perl, I think
reusing Perl version tool is better.

 And we can even enhance rpmbuild, so when we deal with unstable CPAN
 modules, we can tell it to keep or discard the numbers after the underscore
 in specfiles. Or we can think out a more sophisticated guideline for
 versioning rpms of unstable CPAN modules.

My feeling of rpm maintainers is they want to do the stuff. I would like to
see Perl dependencies scanner in perl package, outside of rpm.

-- Petr


pgpe4aDpuILWP.pgp
Description: PGP signature
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 679380] perl-Coro-5.372 is available

2011-02-23 Thread bugzilla

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 
changed:

   What|Removed |Added

Summary|perl-Coro-5.371 is  |perl-Coro-5.372 is
   |available   |available

--- Comment #1 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org 2011-02-23 07:42:26 EST ---
Latest upstream release: 5.372
Current version in Fedora Rawhide: 5.37
URL: http://search.cpan.org/dist/Coro/

Please consult the package update guidelines before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Package_update_guidelines

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 679752] New: perl-PDF-API2-2.017 is available

2011-02-23 Thread bugzilla

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-PDF-API2-2.017 is available

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

   Summary: perl-PDF-API2-2.017 is available
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
 Component: perl-PDF-API2
AssignedTo: bjohn...@symetrix.com
ReportedBy: upstream-release-monitor...@fedoraproject.org
 QAContact: extras...@fedoraproject.org
CC: bjohn...@symetrix.com,
fedora-perl-devel-l...@redhat.com
Classification: Fedora


Latest upstream release: 2.017
Current version in Fedora Rawhide: 2.016
URL: http://search.cpan.org/dist/PDF-API2/

Please consult the package update guidelines before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Package_update_guidelines

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: rawhide report: 20110222 changes

2011-02-23 Thread Bastien Nocera

On Wed, 2011-02-23 at 12:09 +0100, Alexandre Mazari wrote:
 Hi,
 
 The following update breaks gdm and gnome-session at runtime for me:
 
 gsettings-desktop-schemas-0.1.
 7-1.fc16
 --
 * Mon Feb 21 2011 Bastien Nocera bnoc...@redhat.com 0.1.7-1
 - Update to 0.1.7
 
 Those packages might need an update too, where they use the right
 gsettings keys.

Those new packages are getting built.

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

Re: rawhide report: 20110222 changes

2011-02-23 Thread Bastien Nocera

On Wed, 2011-02-23 at 12:23 +0100, Alexandre Mazari wrote:
 And libpeas-0.7.2-1.fc16 breaks gedit:
 
 (gedit:2796): GLib-GObject-WARNING **: specified class size for type
 `GeditPluginsEngine' is smaller than the parent type's `PeasEngine'
 class size

And GEdit needs a rebuild/new version too.

 On Wed, Feb 23, 2011 at 12:09 PM, Alexandre Mazari sca...@gmail.com wrote:
  Hi,
 
  The following update breaks gdm and gnome-session at runtime for me:
 
  gsettings-desktop-schemas-0.1.
  7-1.fc16
  --
  * Mon Feb 21 2011 Bastien Nocera bnoc...@redhat.com 0.1.7-1
  - Update to 0.1.7
 
  Those packages might need an update too, where they use the right
  gsettings keys.
 
 
 
 
 -- 
 If you open your mind too much, you brain will fall out
 Tim Minchin


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

Re: Plans for BTRFS in Fedora

On Tue, Feb 22, 2011 at 10:25 PM, Jon Masters jonat...@jonmasters.org wrote:
 On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:

 2) Fedora 16 ships without LVM as the volume manager and instead use
 BTRFS's built in volume management, again just for the default.

 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.

 Should the switch to BTRFS by default happen, this will be one more
 thing I will have to fix immediately during installation. The list grows
 longer and longer over time - please don't make this change.


Theres no sense in using LVM if BTRFS can do the same job better.  I'm
not suggesting removing LVM altogether, just not using it for the
default pick the layout for me option, you can always do your own
thing with a custom layout.

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

Re: [ACTION REQUIRED] orphaned packages in rawhide

2011-02-23 Thread Patrick MONNERAT

On Mon, 2011-02-07 at 15:59 -0500, Bill Nottingham wrote: 
 Each release, we undergo the effort to track down owners for orphaned
 packages in the release, and block those orphaned packages where
 necessary. It's that time again for Fedora 15.
 
 The following packages are currently orphaned and exist in F-15. As
 you can see, there are a lot of dependencies on these packages. Please
 pick up these packages if you have a need for them.
 
 

 Orphan xca

I take it.

Patrick


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

Re: Plans for BTRFS in Fedora

On Tue, Feb 22, 2011 at 11:57 PM, Bruno Wolff III br...@wolff.to wrote:
 On Tue, Feb 22, 2011 at 14:51:50 -0500,
  Josef Bacik jo...@toxicpanda.com wrote:

 3) All the various little tools that we have for putting together
 LiveCD's that are very ext* centered.  I've not even looked at this
 yet, but I assume it's going to be kind of a pain.

 I like to see live CDs just use squashfs directly and not a squashed copy
 of an ext3/4 image. However this will break using dd to copy the image
 for installs which will slow things down. Further however, there is at least
 some interest in having live CDs and ananconda share the same install method,
 so this might be happening in any case.


This would be a great thing in general since the default ext* image is
shrunk down to be installed which creates a bad fs layout which has
performance implications.  Sure it may be faster for the install, but
overall it hurts our users.  So moving away from this dd an image
thing would be good for everybody.  Thanks,

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread drago01

On Wed, Feb 23, 2011 at 4:25 AM, Jon Masters jonat...@jonmasters.org wrote:
 On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:

 2) Fedora 16 ships without LVM as the volume manager and instead use
 BTRFS's built in volume management, again just for the default.

 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.

 Should the switch to BTRFS by default happen, this will be one more
 thing I will have to fix immediately during installation. The list grows
 longer and longer over time - please don't make this change.

Oh god changes how dare we even think about those evil things!

Now seriously we cannot make progress when every time a (bigger)
change is proposed people start screaming but this changes what we
had before,
and regarding this particular case I think LVM by default has pretty
much always been a bad idea anyway.
And it is not like installing an OS is something you do everyday so
you install your OS, do the changes you think are necessary and be
done with it.
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing in the
past (i.e stagnation).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Camilo Mesias

Hi

I wanted to second these questions...

2011/2/22 Jóhann B. johan...@gmail.com:
 Will there be any performance penalties making this move?
[...]
 What benefit will this switch bring to the novice desktop end users?

 Will the novice desktop end user ever take advantages of any of the features 
 that btrfs brings?

Since upgrading (downgrading?) my netbook to use an SSD I went with
the Anaconda defaults (using LVM etc) and that probably wasn't in my
best interest - judging from benchmarks at the time of read
performance in the LVM compared to the underlying device, also from
the point of not being able to add complex disk arrays to the netbook
any time soon.

I think Fedora could do more to support lower end devices *well*, in
addition to allowing people to use the very latest technology on
larger (ie. desktop and server) platforms. My impression right now is
I'd be interested to try BTRFS for the server and maybe larger
desktops, but would probably want to avoid it for anything smaller.

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

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 8:29 AM, Camilo Mesias cam...@mesias.co.uk wrote:
 Hi

 I wanted to second these questions...

 2011/2/22 Jóhann B. johan...@gmail.com:
 Will there be any performance penalties making this move?
 [...]
 What benefit will this switch bring to the novice desktop end users?

 Will the novice desktop end user ever take advantages of any of the features 
 that btrfs brings?

 Since upgrading (downgrading?) my netbook to use an SSD I went with
 the Anaconda defaults (using LVM etc) and that probably wasn't in my
 best interest - judging from benchmarks at the time of read
 performance in the LVM compared to the underlying device, also from
 the point of not being able to add complex disk arrays to the netbook
 any time soon.

 I think Fedora could do more to support lower end devices *well*, in
 addition to allowing people to use the very latest technology on
 larger (ie. desktop and server) platforms. My impression right now is
 I'd be interested to try BTRFS for the server and maybe larger
 desktops, but would probably want to avoid it for anything smaller.


Your impression is wrong, there has been quite a bit of work done to
make BTRFS work well on small devices, it is the default filesystem
for meego which goes on phones, which is much smaller than anything
you are going to have on your netbook.  Thanks,

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Camilo Mesias

Josef,

On Wed, Feb 23, 2011 at 1:42 PM, Josef Bacik jo...@toxicpanda.com wrote:
 Your impression is wrong, there has been quite a bit of work done to
 make BTRFS work well on small devices, it is the default filesystem
 for meego which goes on phones, which is much smaller than anything
 you are going to have on your netbook.  Thanks,

thanks for the info, I will be sure to test it when it is available.
My impression was based on a quick read of the BTRFS FAQ. I saw more
related to problems of limited disk space than to SSD support (but
granted, what mention there is sounds promising). I will test.

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

Re: Plans for BTRFS in Fedora

On 02/22/2011 10:25 PM, Jon Masters wrote:
 On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:
 
 2) Fedora 16 ships without LVM as the volume manager and instead use
 BTRFS's built in volume management, again just for the default.
 
 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.

I think this is more than a little bit over the top, but there are some
legitimate concerns we do need to keep track of and figure out solutions
to.  Off the top of my head, we need to figure out what we're doing with
encrypted volumes:

1) can btrfs do encrypted volumes?  Or, somewhat weirder but possibly better,
   encrypted volumes with non-encrypted subvolumes?
   a) if encrypted volumes but not plaintext subvolumes, then we need /boot
  split out to a separate physical partition, maybe
   b) if it can do encrypted subvolumes of non-encrypted volumes, we
  could make a /boot and a /sysroot and mount /sysroot as / I guess
   c) if no encrypted volumes, or if that functionality won't land at the
  same time as the basic parts, then we need to talk about UI for disk
  encryption:
  I) keeping lvm when encrypt data is checked in the anaconda UI,
 so we can continue to use luks on a VG in those cases.
  II) it may be worth investigating identifying machine classes during
  installation and varying the defaults based on them.  We talk about
  doing this every 3 or 4 releases for various reasons and usually
  decide it's a terrible idea and do something else.

 Should the switch to BTRFS by default happen, this will be one more
 thing I will have to fix immediately during installation. The list grows
 longer and longer over time - please don't make this change.

I think you're confusing necessity and desire here.

-- 
Peter

Computers don't make errors.  What they do, they do on purpose.
-- Dale
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread John Reiser

On 02/23/2011 05:07 AM, drago01 wrote:
 Defaults should be chooses on the metric what provides the best
 experience for the users not based on what we have been doing in the
 past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
and will be for yet a while longer.

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

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 9:18 AM, John Reiser jrei...@bitwagon.com wrote:
 On 02/23/2011 05:07 AM, drago01 wrote:
 Defaults should be chooses on the metric what provides the best
 experience for the users not based on what we have been doing in the
 past (i.e stagnation).

 *One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
 and will be for yet a while longer.


Well if data corruption is the test then we shouldn't be using Ext4
either, there was one fixed as recently as the beginning of this
month.  File systems are software like anything else, there will be
bugs.  Off the top of my head I can think of 3 data corrupters we've
had in 4 years of working on BTRFS, and they've all been hard to hit
and have not to my knowledge been seen by users, only us developers in
testing.  BTRFS is young, but we have to start somewhere.  Thanks,

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Nathaniel McCallum

On Wed, 2011-02-23 at 09:27 -0500, Josef Bacik wrote:
 On Wed, Feb 23, 2011 at 9:18 AM, John Reiser jrei...@bitwagon.com wrote:
  On 02/23/2011 05:07 AM, drago01 wrote:
  Defaults should be chooses on the metric what provides the best
  experience for the users not based on what we have been doing in the
  past (i.e stagnation).
 
  *One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
  and will be for yet a while longer.
 
 
 Well if data corruption is the test then we shouldn't be using Ext4
 either, there was one fixed as recently as the beginning of this
 month.  File systems are software like anything else, there will be
 bugs.  Off the top of my head I can think of 3 data corrupters we've
 had in 4 years of working on BTRFS, and they've all been hard to hit
 and have not to my knowledge been seen by users, only us developers in
 testing.  BTRFS is young, but we have to start somewhere.  Thanks,

From a user's perspective, I've been using btrfs for about 1.5 years on
multiple computers and I've been very happy (particularly on my netbook
where the transparent compression increases the disk writes
considerably).  I had one small problem where btrfs wouldn't mount, but
by booting off of a newer kernel I had no problems.

Thanks for your hard work on btrfs everyone!

Nathaniel

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

Re: state of systemd in Fedora and services pledge

On Wed, Feb 23, 2011 at 01:30:52AM +0100, Lennart Poettering wrote:
 On Tue, 22.02.11 12:19, Toshio Kuratomi (a.bad...@gmail.com) wrote:
 
  2011/2/22 Michał Piotrowski mkkp...@gmail.com:
   Hi,
  
   I wonder what is the actual state of Fedora systemd integration? I
   hope that there is more systemd native services than listed on
   https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability
  
   Currently I have quite a lot of work, but I make a systemd services
   pledge - I'll write three services per week if 10 other people do the
   same
   http://www.pledgebank.com/systemdservices
  
  uh... How are you creating the spec file?  In testing, I've yet to get
  a specfile that performs as expected.  I'd be happy if you could take
  a look at the proposed guidelines and figure out if this is a
  guidelines bug, a systemd bug, a testing bug, or a bug in the packages
  that I'm testing with.
 
 Did you actually check if you had at least chkconfig 1.3.50-1 installed
 when you tested this, as I wrote in the FPC bug?
 
 Also, Michał's work is about adding systemd unit files, not about adding
 SysV init scripts, because those already exist...
 
Okay, I've tried all sorts of different wording to get you to understand
what is being tested.  I'll try one more before giving up:

Are you proposing that system V init scripts be banned for F15 and that we
do not allow upgrades from F14 to F15, only new installs?

If you aren't proposing that, then testing that we can successfully upgrade
from a systemVinit script using package to a systemd unit file using package
is a test that needs to pass.

-Toshio


pgpqwEJJCZB6R.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 02/23/2011 03:27 PM, Josef Bacik wrote:
On Wed, Feb 23, 2011 at 9:18 AM, John Reiserjrei...@bitwagon.com wrote:
On 02/23/2011 05:07 AM, drago01 wrote:
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing in the
past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL. Btrfs is too young,
and will be for yet a while longer.

Well if data corruption is the test then we shouldn't be using Ext4
either, there was one fixed as recently as the beginning of this
month. File systems are software like anything else, there will be
bugs. Off the top of my head I can think of 3 data corrupters we've
had in 4 years of working on BTRFS, and they've all been hard to hit
and have not to my knowledge been seen by users, only us developers in
testing. BTRFS is young, but we have to start somewhere. Thanks,

I'm actually not that worried about corruption as that is something that
can be fixed once discovered. What creeps me out about btrfs at the moment
is this:

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

The fact that the FS needs manual rebalance operations and that these can
take a while (even tough this can be done online) doesn't exactly make
btrfs the ideal candidate for an end-user desktop system that should pretty
much be able to look after itself.
I'm actually quite interested in btrfs especially for servers because of
it's features but this problem really worries me.

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Eric Sandeen

On 2/23/11 5:38 AM, Jóhann B. Guðmundsson wrote:
 On 02/23/2011 01:26 AM, Josef Bacik wrote:
 Various things, better data integrity to start with, and if you
 install the yum-fs-snapshot you have the ability to rollback easily.
 
 So we got the above + What Lennart mentioned as benefits to the end user.
 
 Now if we continue to hang on to the outdated concept ( From my 
 perspective ) of defaults as opposed to allowing each SIG to control 
 and set it's own defaults that suits their target end user base.
 
 For example any of the *DE might not want to switch to BTRFS until all 
 GUI tool for their end user to take advantage of what it has to offer 
 are in place while the Server SIG might certainly do.
 
 Hence I propose that we open a ticket with FESCO which will request them 
 to do something like this.
 
 Review the current filesystem default
 
 Gather feed back from various SIG with in the community to create a good 
 criteria for what needs to be in place in a filesystem for it to be 
 considered as an a default for Fedora.
 
 Gather a list of all existing linux filesystems ( there seems to be a 
 new one popping up every other month or so ).

Perhaps, but the list of possibly usable defaults for Fedora is not very long.

ext3, ext4, xfs, btrfs for now, I'd say.

Anything that popped up last month is not going to be ready for primetime
for years.

That said, I'd love to see it easy to tweak the default from among the supported
anaconda filesystems via kickstart or boot-time option, vs. having to go into
the detailed custom storage setup screen.  ext3 please is a lot simpler 
request
than custom partitioning with volume managers, and today it's all rolled into
one...

-Eric

 Filter out those that do not live up to that criteria and any base line 
 they set for their decision like must not perform worse then the 
 current default must work well on SSD's etc..  settle on one that 
 benefits most likely most the novice end users.
 ( We experienced users are able to choose tweak and turn any knob at 
 install time to suit our need which makes the novice end user the lowest 
 dominator)
 
 JBG

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

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn
denni...@conversis.de wrote:
On 02/23/2011 03:27 PM, Josef Bacik wrote:
On Wed, Feb 23, 2011 at 9:18 AM, John Reiserjrei...@bitwagon.com wrote:
On 02/23/2011 05:07 AM, drago01 wrote:
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing in the
past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL. Btrfs is too young,
and will be for yet a while longer.

I'm actually not that worried about corruption as that is something that
can be fixed once discovered. What creeps me out about btrfs at the moment
is this:

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

Yes this is one of the more complicated areas of BTRFS and tends to
blow up in our faces a lot. That being said it's only a big deal if
you tend to run your filesystem close to full a lot, which most people
do not. It is an area that we work very hard to make sure it's not a
problem, hopefully we have eliminated all of the big problems and you
should really only see ENOSPC when you actually fill up the disk.
Thanks,

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

Re: state of systemd in Fedora and services pledge

2011/2/23 Toshio Kuratomi a.bad...@gmail.com:
 On Wed, Feb 23, 2011 at 01:30:52AM +0100, Lennart Poettering wrote:
 On Tue, 22.02.11 12:19, Toshio Kuratomi (a.bad...@gmail.com) wrote:

  2011/2/22 Michał Piotrowski mkkp...@gmail.com:
   Hi,
  
   I wonder what is the actual state of Fedora systemd integration? I
   hope that there is more systemd native services than listed on
   https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability
  
   Currently I have quite a lot of work, but I make a systemd services
   pledge - I'll write three services per week if 10 other people do the
   same
   http://www.pledgebank.com/systemdservices
  
  uh... How are you creating the spec file?  In testing, I've yet to get
  a specfile that performs as expected.  I'd be happy if you could take
  a look at the proposed guidelines and figure out if this is a
  guidelines bug, a systemd bug, a testing bug, or a bug in the packages
  that I'm testing with.

 Did you actually check if you had at least chkconfig 1.3.50-1 installed
 when you tested this, as I wrote in the FPC bug?

 Also, Michał's work is about adding systemd unit files, not about adding
 SysV init scripts, because those already exist...

 Okay, I've tried all sorts of different wording to get you to understand
 what is being tested.  I'll try one more before giving up:

 Are you proposing that system V init scripts be banned for F15 and that we
 do not allow upgrades from F14 to F15, only new installs?

 If you aren't proposing that, then testing that we can successfully upgrade
 from a systemVinit script using package to a systemd unit file using package
 is a test that needs to pass.

I'm not a Fedora developer and I do not know much about RPM's. Could you
write something more about what problem you mean?


 -Toshio

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




-- 
Best regards,
Michal

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Jóhann B. Guðmundsson

On 02/23/2011 03:33 PM, Josef Bacik wrote:

 I'm actually not that worried about corruption as that is something that
 can be fixed once discovered. What creeps me out about btrfs at the moment
 is this:

 https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

 The fact that the FS needs manual rebalance operations and that these can
 take a while (even tough this can be done online) doesn't exactly make
 btrfs the ideal candidate for an end-user desktop system that should pretty
 much be able to look after itself.
 I'm actually quite interested in btrfs especially for servers because of
 it's features but this problem really worries me.

 Yes this is one of the more complicated areas of BTRFS and tends to
 blow up in our faces a lot.  That being said it's only a big deal if
 you tend to run your filesystem close to full a lot, which most people
 do not.  It is an area that we work very hard to make sure it's not a
 problem, hopefully we have eliminated all of the big problems and you
 should really only see ENOSPC when you actually fill up the disk.
 Thanks,

I'm pretty sure for novice end user desktops the same procedure that 
would clean up old snapshot on regular intervals could make rebalance 
operation run at the same time since it can be done online...

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Simo Sorce

On Wed, 23 Feb 2011 10:33:26 -0500
Josef Bacik jo...@toxicpanda.com wrote:

On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn
denni...@conversis.de wrote:
On 02/23/2011 03:27 PM, Josef Bacik wrote:
On Wed, Feb 23, 2011 at 9:18 AM, John Reiserjrei...@bitwagon.com
wrote:
On 02/23/2011 05:07 AM, drago01 wrote:
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing
in the past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL. Btrfs is too young,
and will be for yet a while longer.

Well if data corruption is the test then we shouldn't be using Ext4
either, there was one fixed as recently as the beginning of this
month. File systems are software like anything else, there will be
bugs. Off the top of my head I can think of 3 data corrupters
we've had in 4 years of working on BTRFS, and they've all been
hard to hit and have not to my knowledge been seen by users, only
us developers in testing. BTRFS is young, but we have to start
somewhere. Thanks,

I'm actually not that worried about corruption as that is something
that can be fixed once discovered. What creeps me out about btrfs
at the moment is this:

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

The fact that the FS needs manual rebalance operations and that
these can take a while (even tough this can be done online)
doesn't exactly make btrfs the ideal candidate for an end-user
desktop system that should pretty much be able to look after itself.
I'm actually quite interested in btrfs especially for servers
because of it's features but this problem really worries me.

Sorry josef,
but I do that all the time with my Virtual Machines, as I
do not give them more space then strictly needed.

I did that to the point that I needed to uninstall a few devel packages
in order to upgrade from f14 to rawhide on a VM ...

I am, not sure how common it is on a desktop, just wanted to point out
it is a use case to be able to run with little disk at least for
development VMs. (I guess I can manually run whatever tool there, as
long as it is clearly recognizable when I need to do so).

Simo.

--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

2011-02-23 Thread Jóhann B. Guðmundsson

On 02/23/2011 03:04 PM, Toshio Kuratomi wrote:
 Are you proposing that system V init scripts be banned for F15 and that we
 do not allow upgrades from F14 to F15, only new installs?

The backwards compatibility code would never have been added if that had 
ever been the intention now would it :)

 If you aren't proposing that, then testing that we can successfully upgrade
 from a systemVinit script using package to a systemd unit file using package
 is a test that needs to pass.

First could you be a bit more specific what exactly is the problem so we 
can test for that when we host systemd test day if I'm getting you right 
what you are describing might fall under release blocker...

As I get it we have a package with $oldversion with the traditional init 
script now there is an update/upgrade that contains a $new-version with 
systemd native service files and that update/upgrade is failing somehow?

As Lennart mentioned have you tried chkconfig 1.3.50-1 [1] it contains 
few patches from him amongst [2]...

systemd compatibility was only added to chkconfig couple of days ago 
up to that point systemd and chkconfig did not compute each other :)

1. http://koji.fedoraproject.org/koji/buildinfo?buildID=229902
2. 
http://git.fedorahosted.org/git/?p=chkconfig.git;a=commit;h=fbe103ec4b79a0952e1fd9a7ce69d19acc80d4a9

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Jon Masters

On Wed, 2011-02-23 at 07:15 -0500, Josh Boyer wrote:
 On Tue, Feb 22, 2011 at 10:25 PM, Jon Masters jonat...@jonmasters.org wrote:
  On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:
 
  2) Fedora 16 ships without LVM as the volume manager and instead use
  BTRFS's built in volume management, again just for the default.
 
  In my personal opinion, this is a poor design decision. Yes, BTRFS can
  do a lot of volume-y things, and these are growing by the day, but I
  don't want my filesystem replacing a full volume manager and I am
  concerned that this will lead to less testing and exposure to full LVM
  use within the Fedora community. Instead, I'd like to counter-propose
  that everything stay exactly as it is, with users being able to elect to
  switch to BTRFS (sub)volumes if they are interested in doing so.
 
  Should the switch to BTRFS by default happen, this will be one more
  thing I will have to fix immediately during installation. The list grows
  longer and longer over time - please don't make this change.
 
 You seem to spend a lot of time during your installs undoing all the
 new things that were done for the release.  Perhaps a rapid changing,
 bleeding-edge distribution isn't quite suited to your needs.  Maybe
 you would be more comfortable with Debian or CentOS?

I'll bite. I am, indeed, a fan of various Enterprise Linux distributions
and I make no pretense that I am not. I do run an Enterprise Linux on
one desktop, and it's also true that I intentionally run my primary
desktop several Fedora releases behind so as to avoid many of the
problems I see from some of these changes. However, I also run more
recent Fedora releases, and on those releases, I typically have to undo
changes such as the one originally being proposed (replacing LVM).

Again, I feel the solution is to have a Fedora architect whose role is
to realize the problems caused by seemingly isolated changes, and stop
them from propagating. You don't just replace years of UNIX (or Linux)
history/heritage overnight without bothering a chunk of the users.

Jon.


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

Re: Plans for BTRFS in Fedora

On Wed, 23.02.11 11:41, Jon Masters (jonat...@jonmasters.org) wrote:

  You seem to spend a lot of time during your installs undoing all the
  new things that were done for the release.  Perhaps a rapid changing,
  bleeding-edge distribution isn't quite suited to your needs.  Maybe
  you would be more comfortable with Debian or CentOS?
 
 I'll bite. I am, indeed, a fan of various Enterprise Linux distributions
 and I make no pretense that I am not. I do run an Enterprise Linux on
 one desktop, and it's also true that I intentionally run my primary
 desktop several Fedora releases behind so as to avoid many of the
 problems I see from some of these changes. However, I also run more
 recent Fedora releases, and on those releases, I typically have to undo
 changes such as the one originally being proposed (replacing LVM).
 
 Again, I feel the solution is to have a Fedora architect whose role is
 to realize the problems caused by seemingly isolated changes, and stop
 them from propagating. You don't just replace years of UNIX (or Linux)
 history/heritage overnight without bothering a chunk of the users.

We have that already. It's called FESCO, and is pluralistic and
democratic and stuff.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On 02/23/2011 11:41 AM, Jon Masters wrote:

 Again, I feel the solution is to have a Fedora architect whose role is
 to realize the problems caused by seemingly isolated changes, and stop
 them from propagating.

Fedora historically relies on an open source model for this - there
are a lot of smart people working on Fedora, and we depend on each and
every one of them to realize the problems caused by seemingly isolated
changes. With that in mind, I'm wondering if you have any input as to
what problems there might be with the change in question.

 You don't just replace years of UNIX (or Linux) history/heritage
 overnight without bothering a chunk of the users.

This is something what we've historically been willing to do in Linux,
and so far we've had pretty good results.

-- 
Peter

RFC 882 put the dots in .com.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

On Wed, 23.02.11 07:04, Toshio Kuratomi (a.bad...@gmail.com) wrote:

   uh... How are you creating the spec file?  In testing, I've yet to get
   a specfile that performs as expected.  I'd be happy if you could take
   a look at the proposed guidelines and figure out if this is a
   guidelines bug, a systemd bug, a testing bug, or a bug in the packages
   that I'm testing with.
  
  Did you actually check if you had at least chkconfig 1.3.50-1 installed
  when you tested this, as I wrote in the FPC bug?
  
  Also, Michał's work is about adding systemd unit files, not about adding
  SysV init scripts, because those already exist...
  
 Okay, I've tried all sorts of different wording to get you to understand
 what is being tested.  I'll try one more before giving up:

No. Never did. I was suggesting to ship systemd unit files and SysV
service files side by side. The current draft is tougher however, and
asks packages to remove SysV scripts if service files are around, or
split them into subpackages. That's more than what I asked for and I had
in my original draft. But of course I am happy with this too.

 Are you proposing that system V init scripts be banned for F15 and that we
 do not allow upgrades from F14 to F15, only new installs?

No. Never did.

 If you aren't proposing that, then testing that we can successfully upgrade
 from a systemVinit script using package to a systemd unit file using package
 is a test that needs to pass.

Well, I still fail to see what the packaging guidlines for systemd unit
files have to do with chkconfig, but well, maybe I am just blind.

Anyway, we don't really have to continue this discussion
here. Regardless whether chkconfig is relevant for the systemd
guidelines or not let's stay constructive: I think that the newer
chkconfig version fixes your problems, and would like to ask you to test
things with that. 

Thank you,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

On Wed, Feb 23, 2011 at 04:38:50PM +0100, Michał Piotrowski wrote:
 2011/2/23 Toshio Kuratomi a.bad...@gmail.com:
  On Wed, Feb 23, 2011 at 01:30:52AM +0100, Lennart Poettering wrote:
  On Tue, 22.02.11 12:19, Toshio Kuratomi (a.bad...@gmail.com) wrote:
 
   2011/2/22 Michał Piotrowski mkkp...@gmail.com:
Hi,
   
I wonder what is the actual state of Fedora systemd integration? I
hope that there is more systemd native services than listed on
https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability
   
Currently I have quite a lot of work, but I make a systemd services
pledge - I'll write three services per week if 10 other people do the
same
http://www.pledgebank.com/systemdservices
   
   uh... How are you creating the spec file?  In testing, I've yet to get
   a specfile that performs as expected.  I'd be happy if you could take
   a look at the proposed guidelines and figure out if this is a
   guidelines bug, a systemd bug, a testing bug, or a bug in the packages
   that I'm testing with.
 
  Did you actually check if you had at least chkconfig 1.3.50-1 installed
  when you tested this, as I wrote in the FPC bug?
 
  Also, Michał's work is about adding systemd unit files, not about adding
  SysV init scripts, because those already exist...
 
  Okay, I've tried all sorts of different wording to get you to understand
  what is being tested.  I'll try one more before giving up:
 
  Are you proposing that system V init scripts be banned for F15 and that we
  do not allow upgrades from F14 to F15, only new installs?
 
  If you aren't proposing that, then testing that we can successfully upgrade
  from a systemVinit script using package to a systemd unit file using package
  is a test that needs to pass.
 
 I'm not a Fedora developer and I do not know much about RPM's. Could you
 write something more about what problem you mean?
 
If a particular piece of software is going to convert from systemv init
scripts to systemd unit files we'll end up with two important rpm files.
One that is before the conversion and has sysv init scripts and one that is
after the conversion and has systemd unit files.

The rpm packages contain small (usually shell) scripts that allow the
package to register themselves with the init system.  These will turn
the service on if that's allowed by policy, restart the service if it's
already running, stop the service before uninstallation, etc.

The proposed Packaging Guidelines for systemd:
https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft

Needs to contain the necessary scriptlets for packages that use systemd unit
files.  At the moment, the draft only contains scriptlets for a default-off
case.  We also need scriptlets for services which autostart and for services
which bus activate.  Given that FESCo seems to be moving towards a policy
that allows a broad range of services to autostart, we probably need the
autostart guidelines in place soon.  The bus activated scriptlets are needed
but we may be able to delay as it sounds like we only want a few services to
be bus activated anyway and those services can be started as normal until we
have guidelines on how they need to be set to autostart.

The scriptlets that we currently have do not work in testing.  I have tested
the migration path from a sysv init script using service to an upgraded
package using systemd unit files and that doesn't work.  at some point
someone also needs to test the upgrade between systemd unit file using
services but I personally haven't had time for that yet.  The FPC ticket has
the steps that would constitute a good test of those services.

Without guidelines that work, current work to port to systemd unit files
could have several undesirable effects.  Least critically would be that the
ported packages would need to be revisited to have their spec files updated.
Most critically, the unit file using packages would break end users systems
when they upgrade the package from F15 to F14.

-Toshio


pgphWbHNoA7Jq.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Jesse Keating

On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.

Can you expand upon this more?  The filesystem is shrunk down when the 
live image is built, but then once it is installed the fs is resized to 
fill out the physical disk / partition it is being installed to.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

On Wed, Feb 23, 2011 at 04:34:00PM +, Jóhann B. Guðmundsson wrote:
 First could you be a bit more specific what exactly is the problem so we 
 can test for that when we host systemd test day if I'm getting you right 
 what you are describing might fall under release blocker...
 
Yes, if we're moving services to unit files then it definitely will need to
be a release blocker.

 As I get it we have a package with $oldversion with the traditional init 
 script now there is an update/upgrade that contains a $new-version with 
 systemd native service files and that update/upgrade is failing somehow?
 
 As Lennart mentioned have you tried chkconfig 1.3.50-1 [1] it contains 
 few patches from him amongst [2]...

yes, still happens.

-Toshio


pgptmnOWymWSZ.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 13 ARM Beta Release

2011-02-23 Thread Paul Whalen


The Fedora 13 ARM Beta is now available for download. There are still a number 
of packages that haven’t been built for ARM due to build failures or missing 
dependencies. We’re a little behind the primary architectures so we have the 
ability to look at later releases to see if these failures have been fixed – 
thankfully a large number include support for ARM. Because of this we expect 
that with Fedora 14 and 15 we will be closer in line with the primary 
architectures.


A new root file system is available for download - 
http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta-2011-02-22.tar.bz2


The password for the root account is “fedoraarm”. 


Instructions for using the root file system can be found at - 
http://fedoraproject.org/wiki/Architectures/ARM/Using


The Fedora 13 ARM repository is temporarily located at – 
http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-02-21/f13-arm/arm/os/


A comparision of the packages included in this beta release with the versions 
included in the primary 32-bit architecture (i686) - 
http://hongkong.proximity.on.ca/f13-arm-beta1/


The Fedora 13 ARM Beta release notes - 
http://fedoraproject.org/wiki/Architectures/ARM/F13-ARM-Beta1


We will now be working to get the remaining packages in Fedora 13 built, then 
move on to updates and Fedora 14.


Enjoy,
Paul Whalen
http://paulfedora.wordpress.com


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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Lars Seipel

On Wednesday 23 February 2011 15:07:55 Peter Jones wrote:

 1) can btrfs do encrypted volumes?

Not yet.  Although this was a planned feature at some point, according to 
Josef, nobody has done it yet.

If you want to stack it on top of dm-crypt there are caveats as well.

From btrfs-wiki:
btrfs volumes on top of dm-crypt block devices (and possibly LVM) require
 write-caching to be turned off on the underlying HDD. Failing to do so, in
 the event of a power failure, may result in corruption not yet handled by
 btrfs code. (2.6.33)

Is this still prevailing as of 2.6.38?

While it may work if you're lucky (at least it did for me since F13) it can 
also munch your data. That's what happened to me last night in F15 (didn't 
lose any data though as such stuff was somewhat expected). Btrfs root partition 
(no LVM) on a dm-crypt volume on Intel 32 GB solid state drive.

After an unclean shutdown I was no longer able to mount the filesystem and 
therefore start the system. I even managed to crash a live system when trying 
to mount the decrypted luks volume containing the btrfs.

As I didn't have much time I just dd'ed an image to a spare disk and 
reinstalled. If there is any debugging value in this, I can make it available 
as long as I can be sure all data could be stripped from it (btrfs-image does 
exactly this, right?).

Be aware that the crash-on-shutdown didn't happen with an official Fedora 
kernel. Due to the update embargo on F15 I built an updated Kernel checked out 
with fedpkg.

If btrfs should become the default filesystem for Fedora (which I strongly 
support) a nice and clean solution for encrypted filesystems has to be found. 
Falling back to ext4  lvm when the encryption checkbox gets ticked is just 
plain ugly. Not supporting encrypted disks at all would be even worse.

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

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Eric Sandeen

On 2/23/11 11:42 AM, Jesse Keating wrote:
 On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.
 
 Can you expand upon this more?  The filesystem is shrunk down when the 
 live image is built, but then once it is installed the fs is resized to 
 fill out the physical disk / partition it is being installed to.

Shrinking down the filesystem tends to scramble it a bit.  All the allocator 
decisions that were made based on fs size at the time of install go out the 
window as resize2fs fills in every hole it can find to maximally compress the 
fs.

I haven't done a real analysis but I would expect that inode::data locality and 
filesystem fragmentation suffer as a result.

Resizing it back up after the install just attaches free space to the end of 
the shrunken fs.

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

Re: state of systemd in Fedora and services pledge

On Wed, Feb 23, 2011 at 04:34:00PM +, Jóhann B. Guðmundsson wrote:
 On 02/23/2011 03:04 PM, Toshio Kuratomi wrote:
  Are you proposing that system V init scripts be banned for F15 and that we
  do not allow upgrades from F14 to F15, only new installs?
 
 The backwards compatibility code would never have been added if that had 
 ever been the intention now would it :)
 
  If you aren't proposing that, then testing that we can successfully upgrade
  from a systemVinit script using package to a systemd unit file using package
  is a test that needs to pass.
 
 First could you be a bit more specific what exactly is the problem so we 
 can test for that when we host systemd test day if I'm getting you right 
 what you are describing might fall under release blocker...
 
 As I get it we have a package with $oldversion with the traditional init 
 script now there is an update/upgrade that contains a $new-version with 
 systemd native service files and that update/upgrade is failing somehow?
 
 As Lennart mentioned have you tried chkconfig 1.3.50-1 [1] it contains 
 few patches from him amongst [2]...
 
 systemd compatibility was only added to chkconfig couple of days ago 
 up to that point systemd and chkconfig did not compute each other :)
 
 1. http://koji.fedoraproject.org/koji/buildinfo?buildID=229902
 2. 
 http://git.fedorahosted.org/git/?p=chkconfig.git;a=commit;h=fbe103ec4b79a0952e1fd9a7ce69d19acc80d4a9
 
Looking at that patch it looks like all it does is have chkconfig forward
a request on to systemd if the package included systemd unit files.  If it
does more than that please let me know as that would mean that we'd need to
test upgrading from F14 to F15 separately from upgrading a sysv initscript
using package to a systemd unit file package on F15.

-Toshio


pgpPfLHPwtiTH.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 11:41:49AM -0500, Jon Masters wrote:

 Again, I feel the solution is to have a Fedora architect whose role is
 to realize the problems caused by seemingly isolated changes, and stop
 them from propagating. You don't just replace years of UNIX (or Linux)
 history/heritage overnight without bothering a chunk of the users.

LVM is functional for enterprise environments but awful for the common 
home or office cases. If btrfs lives up to its promises it'll give us 
something that provides pretty much all the functional beneft of LVM 
without the additional abstraction that makes seemingly straightforward 
tasks sufficiently awkward that even I find it abstruse (and I hack on 
ACPI). I think that's entirely in keeping with Linux heritage.

(AIX, on the other hand, delights in partying like it's 1979. Are you 
confusing the two?)

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

2011-02-23 Thread Colin Walters

On Wed, Feb 23, 2011 at 12:39 PM, Toshio Kuratomi a.bad...@gmail.com wrote:

 The scriptlets that we currently have do not work in testing.  I have tested
 the migration path from a sysv init script using service to an upgraded
 package using systemd unit files and that doesn't work.  at some point
 someone also needs to test the upgrade between systemd unit file using
 services but I personally haven't had time for that yet.  The FPC ticket has
 the steps that would constitute a good test of those services.

This is a live yum upgrade?  That not working doesn't seem hard
blocker to me - we currently recommend preupgrade which is non-live
for precisely these kinds of reasons.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Casey Dahlin

On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote:
 On 2/23/11 11:42 AM, Jesse Keating wrote:
  On 2/23/11 5:00 AM, Josef Bacik wrote:
  This would be a great thing in general since the default ext* image is
  shrunk down to be installed which creates a bad fs layout which has
  performance implications.
  
  Can you expand upon this more?  The filesystem is shrunk down when the 
  live image is built, but then once it is installed the fs is resized to 
  fill out the physical disk / partition it is being installed to.
 
 Shrinking down the filesystem tends to scramble it a bit.  All the allocator
 decisions that were made based on fs size at the time of install go out the
 window as resize2fs fills in every hole it can find to maximally compress the
 fs.
 

Is there some sort of sparsifying defrag we could do after copying the image
over? The dd-based install is so fast that we could actually afford another
pass if we needed it IMHO.

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

Re: state of systemd in Fedora and services pledge

On Wed, 23.02.11 09:39, Toshio Kuratomi (a.bad...@gmail.com) wrote:

 The proposed Packaging Guidelines for systemd:
 https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
 
 Needs to contain the necessary scriptlets for packages that use systemd unit
 files.  At the moment, the draft only contains scriptlets for a default-off
 case.  We also need scriptlets for services which autostart and for services
 which bus activate.  

There is no difference between autostart and bus activate. There's
only enabled or not.

I have now added a %post example for a service that should be enable by default.

 Given that FESCo seems to be moving towards a policy that allows a
 broad range of services to autostart, we probably need the autostart
 guidelines in place soon.  The bus activated scriptlets are needed but
 we may be able to delay as it sounds like we only want a few services
 to be bus activated anyway and those services can be started as normal
 until we have guidelines on how they need to be set to autostart.

Well, in the default Fedora install there are actually quite a few bus
services, more than non-bus services.

 The scriptlets that we currently have do not work in testing.  I have tested
 the migration path from a sysv init script using service to an upgraded
 package using systemd unit files and that doesn't work.  at some point
 someone also needs to test the upgrade between systemd unit file using
 services but I personally haven't had time for that yet.  The FPC ticket has
 the steps that would constitute a good test of those services.

Would be cool to include the .spec file and .service file you used in
that ticket. It's otherwise difficult to help you from the distance.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Eric Sandeen

On 2/23/11 12:15 PM, Casey Dahlin wrote:
 On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote:
 On 2/23/11 11:42 AM, Jesse Keating wrote:
 On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.

 Can you expand upon this more?  The filesystem is shrunk down when the 
 live image is built, but then once it is installed the fs is resized to 
 fill out the physical disk / partition it is being installed to.

 Shrinking down the filesystem tends to scramble it a bit.  All the allocator
 decisions that were made based on fs size at the time of install go out the
 window as resize2fs fills in every hole it can find to maximally compress the
 fs.

 
 Is there some sort of sparsifying defrag we could do after copying the image
 over? The dd-based install is so fast that we could actually afford another
 pass if we needed it IMHO.

Not really... e4defrag could maybe, in theory, but its still pretty unloved.

I wonder how it'd go to prep the install on a sparse image of some reasonable 
size,
and then do an efficient sparse copy of that onto the target.  That would save 
the
scrambling, at least, and still give us minimum space usage on the install disc.

-Eric
 
 --CJD

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

Re: Plans for BTRFS in Fedora

On 02/23/2011 01:15 PM, Casey Dahlin wrote:
 On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote:
 On 2/23/11 11:42 AM, Jesse Keating wrote:
 On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.

 Can you expand upon this more?  The filesystem is shrunk down when the
 live image is built, but then once it is installed the fs is resized to
 fill out the physical disk / partition it is being installed to.

 Shrinking down the filesystem tends to scramble it a bit.  All the allocator
 decisions that were made based on fs size at the time of install go out the
 window as resize2fs fills in every hole it can find to maximally compress the
 fs.


 Is there some sort of sparsifying defrag we could do after copying the image
 over? The dd-based install is so fast that we could actually afford another
 pass if we needed it IMHO.

Just as soon as you write it ;)

-- 
 Peter

RFC 882 put the dots in .com.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

On Wed, 23.02.11 09:56, Toshio Kuratomi (a.bad...@gmail.com) wrote:

  systemd compatibility was only added to chkconfig couple of days ago 
  up to that point systemd and chkconfig did not compute each other :)
  
  1. http://koji.fedoraproject.org/koji/buildinfo?buildID=229902
  2. 
  http://git.fedorahosted.org/git/?p=chkconfig.git;a=commit;h=fbe103ec4b79a0952e1fd9a7ce69d19acc80d4a9
  
 Looking at that patch it looks like all it does is have chkconfig forward
 a request on to systemd if the package included systemd unit files.  If it
 does more than that please let me know as that would mean that we'd need to
 test upgrading from F14 to F15 separately from upgrading a sysv initscript
 using package to a systemd unit file package on F15.

That patch adds the glue to forward 'chkconfig on' and friends to
'systemctl enable' if necessary (and it also adds a daemon reload when
changes are made to /etc/rc.d) The reverse glue (i.e. forward 'systemctl
enable' to 'chkconfig on' where necessary) has been in systemd for much
longer.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On 02/23/2011 12:50 PM, Lars Seipel wrote:
 On Wednesday 23 February 2011 15:07:55 Peter Jones wrote:
 
 1) can btrfs do encrypted volumes?
 
 Not yet.  Although this was a planned feature at some point, according to
 Josef, nobody has done it yet.
 
 If you want to stack it on top of dm-crypt there are caveats as well.

Right, which is what we'd wind up doing in the encrypted case.

 From btrfs-wiki:
 btrfs volumes on top of dm-crypt block devices (and possibly LVM) require
 write-caching to be turned off on the underlying HDD. Failing to do so, in
 the event of a power failure, may result in corruption not yet handled by
 btrfs code. (2.6.33)
 
 Is this still prevailing as of 2.6.38?

So, don't hold me to this, but it looks as if the normal lvm behaviour was
fixed at least as of d87f4c14f2 .  That being said, dm-crypt still just throws
REQ_FLUSH away instead of figuring out the block remaps involved and issuing
the right bios. Of course, this is a problem with dm-crypt and _any_ filesystem.

-- 
Peter

RFC 882 put the dots in .com.

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

Minutes/Summary from today's FESCo meeting (2011-02-23)

===
#fedora-meeting: FESCO (2011-02-23)
===

Meeting started by nirik at 17:30:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-23/fesco.2011-02-23-17.30.log.html

Meeting summary
---
* init process  (nirik, 17:30:01)
  * mclasen unable to attend today.  (nirik, 17:34:39)
  * present mjg59 kylem notting nirik SMParrish_mobile mmaslano  (nirik,
17:35:08)

* #516 Updates policy adjustments/changes  (nirik, 17:35:17)
  * ACTION: mmaslano to update wiki for the 3days in testing vs 7 days
in testing for branched releases.  (nirik, 17:38:17)

* #515 Investigate a features repo for stable releases  (nirik,
  17:39:33)

* #517 Updates Metrics  (nirik, 17:40:53)

* #544 List of services that may start by default  (nirik, 17:42:35)
  * LINK: https://fedoraproject.org/wiki/User:Kevin/DefaultServices
(nirik, 17:43:18)
  * LINK: https://fedorahosted.org/fpc/ticket/60   (nirik, 17:44:27)
  * ACTION: nirik will ask for feedback on the proposed policy on devel
list, will gather info and revisit next week.  (nirik, 17:59:04)

* #563 suggested policy: all daemons must set RELRO and PIE flags
  (nirik, 17:59:54)
  * ACTION: kylem will talk with toolchain folks about this, see if
making it default in f16 makes sense and what the tradeoffs are.
(nirik, 18:11:18)

* #275 Propose a soft-path via co-maintainer status to becoming
  sponsored  (nirik, 18:12:08)
  * AGREED: proposal from
https://fedorahosted.org/fesco/ticket/275#comment:10 accepted. will
work to update docs and announce.  (nirik, 18:23:00)
  * ACTION: abadger1999 to update wiki pages.  (nirik, 18:25:27)
  * ACTION: nirik to announce new policy  (nirik, 18:25:33)

* Fedora Engineering Services  (nirik, 18:25:59)
  * LINK: https://fedorahosted.org/fedora-engineering-services/report/6
(nirik, 18:26:46)

* Open Floor  (nirik, 18:43:08)
  * LINK: https://fedoraproject.org/wiki/Mass_Rebuild_SOP   (nirik,
18:48:28)
  * LINK: https://fedoraproject.org/wiki/Alpha_Freeze_Policy   (nirik,
18:49:02)
  * ACTION: mmaslano to add notes about announcements and scheduling to
the mass rebuild sop and freeze policies pages.  (nirik, 18:50:42)

Meeting ended at 18:52:11 UTC.




Action Items

* mmaslano to update wiki for the 3days in testing vs 7 days in testing
  for branched releases.
* nirik will ask for feedback on the proposed policy on devel list, will
  gather info and revisit next week.
* kylem will talk with toolchain folks about this, see if making it
  default in f16 makes sense and what the tradeoffs are.
* abadger1999 to update wiki pages.
* nirik to announce new policy
* mmaslano to add notes about announcements and scheduling to the mass
  rebuild sop and freeze policies pages.




Action Items, by person
---
* abadger1999
  * abadger1999 to update wiki pages.
* kylem
  * kylem will talk with toolchain folks about this, see if making it
default in f16 makes sense and what the tradeoffs are.
* mmaslano
  * mmaslano to update wiki for the 3days in testing vs 7 days in
testing for branched releases.
  * mmaslano to add notes about announcements and scheduling to the mass
rebuild sop and freeze policies pages.
* nirik
  * nirik will ask for feedback on the proposed policy on devel list,
will gather info and revisit next week.
  * nirik to announce new policy
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nirik (149)
* kylem (34)
* mjg59 (27)
* mmaslano (24)
* RobbieAB (19)
* notting (18)
* abadger1999 (16)
* zodbot (10)
* ajax (10)
* SMParrish_mobile (1)
* glisse (1)
* daniel_hozac (1)
* sochotni (1)
* SMParrish (0)
* mclasen (0)
* cwickert (0)
--
17:30:01 nirik #startmeeting FESCO (2011-02-23)
17:30:01 zodbot Meeting started Wed Feb 23 17:30:01 2011 UTC.  The chair is 
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
17:30:01 nirik #meetingname fesco
17:30:01 nirik #chair mclasen notting nirik SMParrish kylem ajax cwickert 
mjg59 mmaslano
17:30:01 nirik #topic init process
17:30:01 zodbot The meeting name has been set to 'fesco'
17:30:01 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 
mmaslano nirik notting
17:30:05 mjg59 Hi
17:30:45 nirik morning everyone.
17:31:16 sochotni damn timezones :-)
17:32:30 SMParrish_mobile here but mobile so will be in and out
17:32:30 * nirik waits a bit more for quorum.
17:33:02 * notting is here
17:33:07 * mmaslano too
17:33:47 nirik well, thats 5 I guess...
17:34:05 mjg59 kylem is here
17:34:10 kylem shh.
17:34:22 nirik ok, 6. ;)
17:34:39 nirik #info mclasen unable to attend today.
17:35:08 nirik #info present mjg59 kylem notting nirik SMParrish_mobile 
mmaslano
17:35:17 nirik #topic #516 Updates policy adjustments/changes
17:35:17 nirik .fesco 516
17:35:22 zodbot

Services that can start by default policy feedback

Greetings. 

FESCo is looking at the question of what services can start by default
(ie, you install something and it's set to start automatically next
time you boot up). 

We have a draft at: 

https://fedoraproject.org/wiki/User:Kevin/DefaultServices

With a policy and list of exceptions. 

We would like to gather feedback on this over the next week, and
revisit at our next meeting. 

Some questions: 

* Do you know of/maintain another service that should start by default?
  Why? 

* Do you think there is some other hurestic we could use to determine
  when services should start by default? are there other categories
  than one-shot, network facing? 

Constructive feedback welcome. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

BTRFS on servers (was Re: Plans for BTRFS in Fedora)

2011-02-23 Thread Jonathan Dieter

On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
 I'm actually quite interested in btrfs especially for servers because
 of it's features

For what it's worth, we've been running btrfs on our school fileservers
since September.  After a few teething problems (fixed by
increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
trouble.

The best part is we no longer need LVM on those servers and we get the
benefit of painless snapshot generation (we tried LVM snapshots and they
were *slow*).

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minutes/Summary from today's FESCo meeting (2011-02-23)

On Wed, 23.02.11 11:53, Kevin Fenzi (ke...@scrye.com) wrote:

 * #544 List of services that may start by default  (nirik, 17:42:35)
   * LINK: https://fedoraproject.org/wiki/User:Kevin/DefaultServices
 (nirik, 17:43:18)
   * LINK: https://fedorahosted.org/fpc/ticket/60   (nirik, 17:44:27)
   * ACTION: nirik will ask for feedback on the proposed policy on devel
 list, will gather info and revisit next week.  (nirik, 17:59:04)

This list does not mention bus services at all. Traditionally they
weren't really that visible and if they were bus activatable they were
always enabled with no way to disable them. With the advent of systemd
we now ideally make them visible in the list of active services like any
other service.

Traditionally bus activated services were enabled by default. I think
this kinda made sense, so I don't think this new policy should now force
the maintainers of udisks, pk, CK, upower and so on to disable their
services by default. That would be backwards.

And yupp we have more bus services on a default fedora install than
non-bus services.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

On Wed, Feb 23, 2011 at 01:10:43PM -0500, Colin Walters wrote:
 On Wed, Feb 23, 2011 at 12:39 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
 
  The scriptlets that we currently have do not work in testing.  I have tested
  the migration path from a sysv init script using service to an upgraded
  package using systemd unit files and that doesn't work.  at some point
  someone also needs to test the upgrade between systemd unit file using
  services but I personally haven't had time for that yet.  The FPC ticket has
  the steps that would constitute a good test of those services.
 
 This is a live yum upgrade?  That not working doesn't seem hard
 blocker to me - we currently recommend preupgrade which is non-live
 for precisely these kinds of reasons.

No.  This is an upgrade of a single package from one that has sysv init
scripts to a later version that has systemd unit files.  If this isn't
working, then chances are good that any of the whole-distro upgrade methods
are going to fail as well.

-Toshio


pgpMmnyeSMJcy.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS on servers (was Re: Plans for BTRFS in Fedora)

On Wed, Feb 23, 2011 at 2:00 PM, Jonathan Dieter jdie...@lesbg.com wrote:
 On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
 I'm actually quite interested in btrfs especially for servers because
 of it's features

 For what it's worth, we've been running btrfs on our school fileservers
 since September.  After a few teething problems (fixed by
 increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
 trouble.


Wait what?  I know we use lots o ram, but you shouldn't have to bump
min_free_kbytes.  What were you seeing?  Thanks,

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

Re: Minutes/Summary from today's FESCo meeting (2011-02-23)

On Wed, 23 Feb 2011 20:02:48 +0100
Lennart Poettering mzerq...@0pointer.de wrote:

 This list does not mention bus services at all. Traditionally they
 weren't really that visible and if they were bus activatable they were
 always enabled with no way to disable them. With the advent of systemd
 we now ideally make them visible in the list of active services like
 any other service.

Yeah, I noted that in the meeting... 

 Traditionally bus activated services were enabled by default. I think
 this kinda made sense, so I don't think this new policy should now
 force the maintainers of udisks, pk, CK, upower and so on to disable
 their services by default. That would be backwards.
 
 And yupp we have more bus services on a default fedora install than
 non-bus services.

Whats the easy way to list them? 
To show if they are set to start by default or not? (or does that make
sense for dbus at all, since they would start when asked to?)

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
 LVM is functional for enterprise environments but awful for the common 
 home or office cases.

Define awful.  I make use of it all the time on home and office
desktops and even my notebook computer.  It makes it easy to reassign
disk space from purpose A to purpose B (it would be easier if there was
a way to shrink a mounted ext3/ext4 FS, but that's a hard problem).
Logical volumes for virtual machines perform better (and virtualization
is something becoming more common on the desktop for compatibility).

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS on servers (was Re: Plans for BTRFS in Fedora)

2011-02-23 Thread Jonathan Dieter

On Wed, 2011-02-23 at 14:18 -0500, Josef Bacik wrote:
 On Wed, Feb 23, 2011 at 2:00 PM, Jonathan Dieter jdie...@lesbg.com wrote:
  On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
  I'm actually quite interested in btrfs especially for servers because
  of it's features
 
  For what it's worth, we've been running btrfs on our school fileservers
  since September.  After a few teething problems (fixed by
  increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
  trouble.
 
 
 Wait what?  I know we use lots o ram, but you shouldn't have to bump
 min_free_kbytes.  What were you seeing?  Thanks,

Sorry, I didn't mean to imply it was btrfs that was causing the problem.
We got new servers when we did our upgrade and ran into problems with
the e1000e kernel module being unable to allocate memory even though
there was loads free.  Bumping up min_free_kbytes fixed it.

See https://bugzilla.redhat.com/show_bug.cgi?id=626851 for more detail.

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 01:38:05PM -0600, Chris Adams wrote:

 Define awful.  I make use of it all the time on home and office
 desktops and even my notebook computer.  It makes it easy to reassign
 disk space from purpose A to purpose B (it would be easier if there was
 a way to shrink a mounted ext3/ext4 FS, but that's a hard problem).
 Logical volumes for virtual machines perform better (and virtualization
 is something becoming more common on the desktop for compatibility).

You can't move PVs. You need a separate /boot. If you use more than one 
disk then it adds significant fragility to the boot process. It slows 
down booting. It provides some functionality that's hugely useful in a 
small number of cases, and in every other case it just makes your life 
more complicated. btrfs does the former without anywhere near as much of 
the latter.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 07:49:49PM +, Matthew Garrett wrote:

 You can't move PVs. You need a separate /boot. If you use more than one 
 disk then it adds significant fragility to the boot process. It slows 
 down booting. It provides some functionality that's hugely useful in a 
 small number of cases, and in every other case it just makes your life 
 more complicated. btrfs does the former without anywhere near as much of 
 the latter.

Also, the management tools are worse than AIX had in 1992. I'll accept 
that that's not an inherent flaw in the implementation, merely an 
inconvenient aspect of reality.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS on servers (was Re: Plans for BTRFS in Fedora)

On Wed, Feb 23, 2011 at 2:42 PM, Jonathan Dieter jdie...@lesbg.com wrote:
 On Wed, 2011-02-23 at 14:18 -0500, Josef Bacik wrote:
 On Wed, Feb 23, 2011 at 2:00 PM, Jonathan Dieter jdie...@lesbg.com wrote:
  On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
  I'm actually quite interested in btrfs especially for servers because
  of it's features
 
  For what it's worth, we've been running btrfs on our school fileservers
  since September.  After a few teething problems (fixed by
  increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
  trouble.
 

 Wait what?  I know we use lots o ram, but you shouldn't have to bump
 min_free_kbytes.  What were you seeing?  Thanks,

 Sorry, I didn't mean to imply it was btrfs that was causing the problem.
 We got new servers when we did our upgrade and ran into problems with
 the e1000e kernel module being unable to allocate memory even though
 there was loads free.  Bumping up min_free_kbytes fixed it.

 See https://bugzilla.redhat.com/show_bug.cgi?id=626851 for more detail.


Ah ok, good, nevermind then :),

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

Re: Plans for BTRFS in Fedora

Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
 You can't move PVs.

What do you think pvmove does?

 You need a separate /boot.

That's needed for more than just LVM (and probably won't go away, as it
is a lot simpler to handle a single method in the installer).

 If you use more than one 
 disk then it adds significant fragility to the boot process.

How does it do that (any more than any other multi-disk setup)?

 It slows 
 down booting.

Cite numbers?  It was slower early on, but it goes right by now.  I
don't doubt it adds some time (of course), but I don't see it being any
significant amount.

 It provides some functionality that's hugely useful in a 
 small number of cases, and in every other case it just makes your life 
 more complicated.

For most, it doesn't make things any more complicated (because they
never touch it).  I'd say that LVM is useful in a growing number of
cases.

 btrfs does the former without anywhere near as much of 
 the latter.

Oh, I don't object to btrfs and having the basic volume management in
the filesystem layer.  AdvFS on DEC Unix was great in that respect.  I
object to your painting of LVM aw awful.
-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Ralf Ertzinger

Hi.

On Wed, 23 Feb 2011 13:38:05 -0600, Chris Adams wrote

 Define awful.  I make use of it all the time on home and office
 desktops and even my notebook computer.  It makes it easy to reassign
 disk space from purpose A to purpose B (it would be easier if there
 was a way to shrink a mounted ext3/ext4 FS, but that's a hard
 problem). Logical volumes for virtual machines perform better (and
 virtualization is something becoming more common on the desktop for
 compatibility).

If you never tried the kind of freedom BTRFS and ZFS give you for
shifting around disk space, try it. Seriously. Then you'll see where
the awful comes from. In perspective it really is.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 02:08:08PM -0600, Chris Adams wrote:
 Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
  You can't move PVs.
 
 What do you think pvmove does?

Move PEs from one PV to another. You can't move a PV.

  You need a separate /boot.
 
 That's needed for more than just LVM (and probably won't go away, as it
 is a lot simpler to handle a single method in the installer).

Unless you're booting off iSCSI or really, really love software RAID 
(which btrfs also kindly simplifies), the only reason you need a 
separate /boot is because we're slow at putting updated filesystem 
support in grub because there's no need because we default to a separate 
/boot. There's a certain amount of circularity there.

  If you use more than one 
  disk then it adds significant fragility to the boot process.
 
 How does it do that (any more than any other multi-disk setup)?

My experience with LVM is that any number of error states dump me into 
an awkward recovery scenario. Again it's not an inherent problem with 
the technology, more just that because nobody outside the enterprise 
world really cares about LVM nobody has bothered making it easy for 
non-sysadmins to handle this stuff.

  It slows 
  down booting.
 
 Cite numbers?  It was slower early on, but it goes right by now.  I
 don't doubt it adds some time (of course), but I don't see it being any
 significant amount.

Talk to Lennart about it. It's on the order of two seconds.

  btrfs does the former without anywhere near as much of 
  the latter.
 
 Oh, I don't object to btrfs and having the basic volume management in
 the filesystem layer.  AdvFS on DEC Unix was great in that respect.  I
 object to your painting of LVM aw awful.

My objections to the technology aren't that strong. My objections to the 
user experience are.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

2011/2/23 Toshio Kuratomi a.bad...@gmail.com:
 On Wed, Feb 23, 2011 at 04:38:50PM +0100, Michał Piotrowski wrote:
 2011/2/23 Toshio Kuratomi a.bad...@gmail.com:
  On Wed, Feb 23, 2011 at 01:30:52AM +0100, Lennart Poettering wrote:
  On Tue, 22.02.11 12:19, Toshio Kuratomi (a.bad...@gmail.com) wrote:
 
   2011/2/22 Michał Piotrowski mkkp...@gmail.com:
Hi,
   
I wonder what is the actual state of Fedora systemd integration? I
hope that there is more systemd native services than listed on
https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability
   
Currently I have quite a lot of work, but I make a systemd services
pledge - I'll write three services per week if 10 other people do the
same
http://www.pledgebank.com/systemdservices
   
   uh... How are you creating the spec file?  In testing, I've yet to get
   a specfile that performs as expected.  I'd be happy if you could take
   a look at the proposed guidelines and figure out if this is a
   guidelines bug, a systemd bug, a testing bug, or a bug in the packages
   that I'm testing with.
 
  Did you actually check if you had at least chkconfig 1.3.50-1 installed
  when you tested this, as I wrote in the FPC bug?
 
  Also, Michał's work is about adding systemd unit files, not about adding
  SysV init scripts, because those already exist...
 
  Okay, I've tried all sorts of different wording to get you to understand
  what is being tested.  I'll try one more before giving up:
 
  Are you proposing that system V init scripts be banned for F15 and that we
  do not allow upgrades from F14 to F15, only new installs?
 
  If you aren't proposing that, then testing that we can successfully upgrade
  from a systemVinit script using package to a systemd unit file using 
  package
  is a test that needs to pass.

 I'm not a Fedora developer and I do not know much about RPM's. Could you
 write something more about what problem you mean?

 If a particular piece of software is going to convert from systemv init
 scripts to systemd unit files we'll end up with two important rpm files.
 One that is before the conversion and has sysv init scripts and one that is
 after the conversion and has systemd unit files.

IFAIU RPM after conversion should have both - sysv init scripts and
systemd services.
Why do you want to remove sysvinit scripts? Both scripts can coexist
without any problem.


 The rpm packages contain small (usually shell) scripts that allow the
 package to register themselves with the init system.  These will turn
 the service on if that's allowed by policy, restart the service if it's
 already running, stop the service before uninstallation, etc.

 The proposed Packaging Guidelines for systemd:
 https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft

 Needs to contain the necessary scriptlets for packages that use systemd unit
 files.  At the moment, the draft only contains scriptlets for a default-off
 case.  We also need scriptlets for services which autostart and for services
 which bus activate.  Given that FESCo seems to be moving towards a policy
 that allows a broad range of services to autostart, we probably need the
 autostart guidelines in place soon.  The bus activated scriptlets are needed
 but we may be able to delay as it sounds like we only want a few services to
 be bus activated anyway and those services can be started as normal until we
 have guidelines on how they need to be set to autostart.

 The scriptlets that we currently have do not work in testing.  I have tested
 the migration path from a sysv init script using service to an upgraded
 package using systemd unit files and that doesn't work.  at some point
 someone also needs to test the upgrade between systemd unit file using
 services but I personally haven't had time for that yet.  The FPC ticket has
 the steps that would constitute a good test of those services.

 Without guidelines that work, current work to port to systemd unit files
 could have several undesirable effects.  Least critically would be that the
 ported packages would need to be revisited to have their spec files updated.
 Most critically, the unit file using packages would break end users systems
 when they upgrade the package from F15 to F14.

Thanks for the explanation of the problem.


 -Toshio

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




-- 
Best regards,
Michal

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

Re: Plans for BTRFS in Fedora

On 02/23/2011 03:33 PM, Matthew Garrett wrote:
 On Wed, Feb 23, 2011 at 02:08:08PM -0600, Chris Adams wrote:
 Once upon a time, Matthew Garrettmj...@srcf.ucam.org  said:
 You can't move PVs.

 What do you think pvmove does?

 Move PEs from one PV to another. You can't move a PV.

 You need a separate /boot.

 That's needed for more than just LVM (and probably won't go away, as it
 is a lot simpler to handle a single method in the installer).

 Unless you're booting off iSCSI or really, really love software RAID
 (which btrfs also kindly simplifies), the only reason you need a
 separate /boot is because we're slow at putting updated filesystem
 support in grub because there's no need because we default to a separate
 /boot. There's a certain amount of circularity there.

Also we need to have the initramfs on an unencrypted chunk of disk.

 If you use more than one
 disk then it adds significant fragility to the boot process.

 How does it do that (any more than any other multi-disk setup)?

 My experience with LVM is that any number of error states dump me into
 an awkward recovery scenario. Again it's not an inherent problem with
 the technology, more just that because nobody outside the enterprise
 world really cares about LVM nobody has bothered making it easy for
 non-sysadmins to handle this stuff.

Yep.

-- 
 Peter

RFC 882 put the dots in .com.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

2011-02-23 Thread Tomasz Torcz

On Tue, Feb 22, 2011 at 08:40:01PM +0100, Michał Piotrowski wrote:
 Hi,
 
 I wonder what is the actual state of Fedora systemd integration? I
 hope that there is more systemd native services than listed on
 https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability

  I have written handful of service definitions for packages listed there,
filling bugs in bugzilla afterwards.  Not a single maintainer responded :(

  OTOH, one upstream accepted unit definition and will ship with next version.

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

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

Re: state of systemd in Fedora and services pledge

W dniu 23 lutego 2011 21:48 użytkownik Tomasz Torcz
to...@pipebreaker.pl napisał:
 On Tue, Feb 22, 2011 at 08:40:01PM +0100, Michał Piotrowski wrote:
 Hi,

 I wonder what is the actual state of Fedora systemd integration? I
 hope that there is more systemd native services than listed on
 https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability

  I have written handful of service definitions for packages listed there,
 filling bugs in bugzilla afterwards.  Not a single maintainer responded :(

I hope that developers of these packages will wake up soon :)

It is possible that the problem described by Toshio Kuratomi has some
connection with this. But OTOH a few of the services that I have
written was accepted by maintainers


  OTOH, one upstream accepted unit definition and will ship with next version.

 --
 Tomasz Torcz            There exists no separation between gods and men:
 xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

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




-- 
Best regards,
Michal

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

Re: Plans for BTRFS in Fedora

Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
 On Wed, Feb 23, 2011 at 02:08:08PM -0600, Chris Adams wrote:
  Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
   You can't move PVs.
  
  What do you think pvmove does?
 
 Move PEs from one PV to another. You can't move a PV.

Not exactly; pvmove moves data from one PE to another (either in another
PV or in the same PV).  I guess I don't understand your original
objection though.  You can move data around within a PV (granted the
command usage to do this is non-obvious and it would be good for that to
improve, but it is also not a common use case) and from one PV to
another; what else is there to move?

   You need a separate /boot.
  
  That's needed for more than just LVM (and probably won't go away, as it
  is a lot simpler to handle a single method in the installer).
 
 Unless you're booting off iSCSI or really, really love software RAID 
 (which btrfs also kindly simplifies),

Using software RAID means really, really love it?  How else do you
propose to boot from software RAID (if you just kinda like it)?  We're
talking about the typical home/office desktop, so you aren't going to
have hardware RAID, and Linux software RAID is superior to motherboard
software RAID.

 the only reason you need a 
 separate /boot is because we're slow at putting updated filesystem 
 support in grub because there's no need because we default to a separate 
 /boot. There's a certain amount of circularity there.

Encrypted root filesystem requires a separate (non-encrypted) /boot, and
I think that's only going to increase in popularity (especially on
notebooks and other mobile devices).

 My experience with LVM is that any number of error states dump me into 
 an awkward recovery scenario.

I guess in the years I've used LVM, I haven't run into that any number
of error states (at least AFAIK, but since you didn't identify any of
them, it is hard to say).  Sure, when LVM was new, I had to learn a few
more commands to handle the system didn't boot case, but IIRC only
once was that related to LVM (and that was because I renamed a VG
without rebuilding the initrd, which may be no longer an issue with
dracut).

If you don't know what you are doing, just fsck is going to be a
problem.  That's an issue with documentation and maybe making better
recovery tools, not LVM.  Adding a new set of commands to learn with
BTRFS isn't magically going to make it easier; you still have to learn
new stuff.

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

Once upon a time, Ralf Ertzinger fed...@camperquake.de said:
 If you never tried the kind of freedom BTRFS and ZFS give you for
 shifting around disk space, try it. Seriously. Then you'll see where
 the awful comes from. In perspective it really is.

You cut out the parts of my email where I said I don't have any problem
with BTRFS, and I look forward to it making things better.  As I said, I
used AdvFS on DEC Unix for many years; ZFS and BTRFS are late-comers to
the filesystem/LVM party (although they obviously bring more to the
table).

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

New path available for joining the Fedora package maintainers group

Greetings. 

FESCo has added an additional path to becoming a co-maintainer of an
existing package in the Fedora package collection for folks who are not
currently in the packager group. 

Traditionally, you would gain sponsorship by submitting a new package
you create and demonstrating your understanding of the guidelines and
processes from the review process. 

This new path requires you to convince an existing maintainer
to mentor you in the processes and guidelines of package maintenance,
and would allow you to be sponsored by FESCo or an existing sponsor to
co-maintain those package(s) with your mentor guiding you. 

Please see: 
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
For the full description and process for this path to becoming a package
maintainer. 

kevin


signature.asc
Description: PGP signature
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

PolicyKit authentication agent changes

2011-02-23 Thread Matthias Clasen

As of version 0.100 (which will land in F15 as a post-alpha update), the
polkit-gnome package will no longer install an autostart file for
polkit-gnome-authentication-agent-1. Instead, each desktop environment
is reponsible for making sure that an authentication agent is running.

For GNOME, this is done by gnome-session installing an autostart file
with OnlyShowIn=GNOME;. Other desktop environments that rely on
polkit-gnome need to do something similar.

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

Re: state of systemd in Fedora and services pledge

On Wed, Feb 23, 2011 at 09:33:33PM +0100, Michał Piotrowski wrote:
 2011/2/23 Toshio Kuratomi a.bad...@gmail.com:
  If a particular piece of software is going to convert from systemv init
  scripts to systemd unit files we'll end up with two important rpm files.
  One that is before the conversion and has sysv init scripts and one that is
  after the conversion and has systemd unit files.
 
 IFAIU RPM after conversion should have both - sysv init scripts and
 systemd services.
 Why do you want to remove sysvinit scripts? Both scripts can coexist
 without any problem.
 
Agreement in the packaging committee is that we want one or the other but
not both because of the confusion having both will cause to people using the
package.  For example, if both are installed, a system admin might try to edit 
the
SysVinit script and not understand why his changes aren't having an effect
on the system.

The brief version of that is in the first note here:
https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft#Unit_Files

-Toshio


pgpmVw9i7fsny.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge

2011-02-23 Thread Kevin Kofler

Tomasz Torcz wrote:
   I have written handful of service definitions for packages listed there,
 filling bugs in bugzilla afterwards.  Not a single maintainer responded :(

We really need this kind of stuff to just get committed by provenpackagers 
on a FESCo mandate.

Instead of micromanaging things like testing of updates, FESCo should be 
focusing on getting systemwide features actually implemented systemwide, 
rather than getting held hostage by recalcitrant maintainers.

Kevin Kofler

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

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 4:37 PM, Kevin Kofler kevin.kof...@chello.at wrote:
 Jon Masters wrote:
 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.

 And I'd like to counter-counter-propose that we just stop using ANY kind of
 subvolumes or volume management by default and just default to plain old
 partitions. IMHO, LVM causes more problems than it fixes. Sure, you can
 easily add storage from another disk, but in exchange there's no
 straightforward way to resize your partitions, at least none of the common
 partition editors can do it. There's also a performance penalty.


Sorry I should clarify, when I say use Btrfs's volume management stuff
I mean just doing normal partitions and then creating a Btrfs
filesystem and then add disks to the fs as required.  Thanks,

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

Re: fail to install gcc on fresh rawhide-from-F15

2011-02-23 Thread Jim Meyering

Andreas Schwab wrote:
 Jim Meyering j...@meyering.net writes:

 --- Package glibc.x86_64 0:2.8.90-11 will be a downgrade

 Where did you get that ANCIENT package?  It's almost 3 years(!) old.

I have *no* idea.
As I said, I installed F15 (into existing partitions,
but told anaconda to format /, /var and /usr -- perhaps something
went wrong there? -- but even the, the preceding system to use
those partitions was running rawhide, and the box itself is barely
two years old) and then upgraded to rawhide.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi update issue

2011-02-23 Thread Paul Howarth

On Wed, 23 Feb 2011 15:54:12 -0600
Dennis Gilmore den...@ausil.us wrote:

 On Wednesday, February 23, 2011 02:22:22 am gia...@gmail.com wrote:
  I'm trying to push an updated rawstudio package to testing but bodhi
  (the web interface) is saying:
  
  Unable to save update with conflicting builds of the same package:
  rawstudio-1.2-9.fc15.20110221svn3825 and
  rawstudio-1.2-9.fc14.20110221svn3825. Please remove one and try
  again.
  
  Is this normal? I'm not sure why those those builds are conflicting.
 you have to create one update per fedora release.  you cant create a
 single update for all fedora's  the conflict is that the builds are
 for different releases

I used the Bodhi web interface to create updates for bluefish for f13,
f14, f15 and el6 all at the same time earlier today. What's the
difference here?

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

Re: state of systemd in Fedora and services pledge

2011/2/23 Kevin Kofler kevin.kof...@chello.at:
 Tomasz Torcz wrote:
   I have written handful of service definitions for packages listed there,
 filling bugs in bugzilla afterwards.  Not a single maintainer responded :(

 We really need this kind of stuff to just get committed by provenpackagers
 on a FESCo mandate.

 Instead of micromanaging things like testing of updates, FESCo should be
 focusing on getting systemwide features actually implemented systemwide,
 rather than getting held hostage by recalcitrant maintainers.

+1


        Kevin Kofler

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




-- 
Best regards,
Michal

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

Re: state of systemd in Fedora and services pledge

2011/2/23 Toshio Kuratomi a.bad...@gmail.com:
 On Wed, Feb 23, 2011 at 09:33:33PM +0100, Michał Piotrowski wrote:
 2011/2/23 Toshio Kuratomi a.bad...@gmail.com:
  If a particular piece of software is going to convert from systemv init
  scripts to systemd unit files we'll end up with two important rpm files.
  One that is before the conversion and has sysv init scripts and one that is
  after the conversion and has systemd unit files.

 IFAIU RPM after conversion should have both - sysv init scripts and
 systemd services.
 Why do you want to remove sysvinit scripts? Both scripts can coexist
 without any problem.

 Agreement in the packaging committee is that we want one or the other but
 not both because of the confusion having both will cause to people using the
 package.  For example, if both are installed, a system admin might try to 
 edit the
 SysVinit script and not understand why his changes aren't having an effect
 on the system.

Indeed it can be a problem.


 The brief version of that is in the first note here:
 https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft#Unit_Files

 -Toshio

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




-- 
Best regards,
Michal

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

Re: state of systemd in Fedora and services pledge

Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
 Instead of micromanaging things like testing of updates, FESCo should be 
 focusing on getting systemwide features actually implemented systemwide, 
 rather than getting held hostage by recalcitrant maintainers.

So, FESCO should be forcing maintainers that don't agree with you to do
what you want to have a consistent system, but not forcing you to do
something to have a consistent system because you don't agree with
FESCO?

Nice.
-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fail to install gcc on fresh rawhide-from-F15

2011-02-23 Thread Jussi Lehtola

On Wed, 23 Feb 2011 23:05:50 +0100
Jim Meyering j...@meyering.net wrote:
 Andreas Schwab wrote:
  Jim Meyering j...@meyering.net writes:
 
  --- Package glibc.x86_64 0:2.8.90-11 will be a downgrade
 
  Where did you get that ANCIENT package?  It's almost 3 years(!) old.
 
 I have *no* idea.

Maybe you missed my former reply.

On Wed, 23 Feb 2011 00:28:57 +0200
Jussi Lehtola jussileht...@fedoraproject.org wrote:
 I'd say there's something seriously wrong with your yum configuration
 or the rawhide mirror you've been using. There hasn't been a gcc-4.3.1
 in Fedora for a couple of years.
 
 Check that the rawhide yum configuration (package
 fedora-release-rawhide) is installed, run
  # yum clean all
 and try again.
-- 
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

dist-git branch change update

2011-02-23 Thread Jesse Keating

https://fedoraproject.org/wiki/Dist_Git_Branch_Proposal

Current status is that I've got a staging environment setup 
(pkgs01.stg.fedoraproject.org) that has a snapshot of the repos from a 
few days ago and the branches have been renamed.  I also have a set of 
fedora-packager (fedpkg) updates in testing or soon to be in testing 
(fedora-packager-0.5.6.0-1) that should work with repositories that have 
branches in the old style (f??/master) or the new style (f??).

I want people to test these fedpkg builds against the current server to 
make sure I haven't broken anything, and if interested I can provide you 
a small patch that will allow you to test against the stg server with 
the renamed branches.

I need to work on some local migration scripts that people can run to 
fix up local clones.

So please test and let me know of any problems you find.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED v2] Orphan removal

2011-02-23 Thread Hans Ulrich Niedermann

On Wed, 2011-02-23 at 17:26 -0500, Bill Nottingham wrote:

 Orphan: gdk-pixbuf
 freetennis requires gdk-pixbuf-devel = 1:0.22.0-38.fc12
 soundtracker requires libgdk_pixbuf.so.2
 soundtracker requires gdk-pixbuf-devel = 1:0.22.0-38.fc12
 tracker requires gdk-pixbuf-devel = 1:0.22.0-38.fc12
 viking requires gdk-pixbuf-devel = 1:0.22.0-38.fc12
 xmms-xosd requires libgdk_pixbuf.so.2
 xosd requires gdk-pixbuf-devel = 1:0.22.0-38.fc12
 xqf requires gdk-pixbuf = 1:0.22.0-38.fc12
 zathura requires gdk-pixbuf-devel = 1:0.22.0-38.fc12

soundtracker-0.6.8-11.fc15 without gdk-pixbuf is waiting to be moved
from testing to stable. So from the soundtracker point of view,
gdk-pixbuf can be retired.


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

Re: Bodhi update issue

2011-02-23 Thread Dennis Gilmore

On Wednesday, February 23, 2011 04:08:03 pm Paul Howarth wrote:
 On Wed, 23 Feb 2011 15:54:12 -0600
 
 Dennis Gilmore den...@ausil.us wrote:
  On Wednesday, February 23, 2011 02:22:22 am gia...@gmail.com wrote:
   I'm trying to push an updated rawstudio package to testing but bodhi
   (the web interface) is saying:
   
   Unable to save update with conflicting builds of the same package:
   rawstudio-1.2-9.fc15.20110221svn3825 and
   rawstudio-1.2-9.fc14.20110221svn3825. Please remove one and try
   again.
   
   Is this normal? I'm not sure why those those builds are conflicting.
  
  you have to create one update per fedora release.  you cant create a
  single update for all fedora's  the conflict is that the builds are
  for different releases
 
 I used the Bodhi web interface to create updates for bluefish for f13,
 f14, f15 and el6 all at the same time earlier today. What's the
 difference here?
 
 Paul.

you created 4 updates, he is trying to create 1

Dennis


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: state of systemd in Fedora and services pledge