Re: Fedora Notifications System.

[Kevin Kofler]

Mahmoud Abdul Jawad wrote:
> 3. keep a history of the notifications
> 4. max. number of notifications at the time
> 5. click able notifications
> 6. stackable notifications

I think that, at least on KDE, you really want to leave that stuff to the 
KNotify system, it already does all this stuff well. Only for point 5, you 
have to set some actions and handle the signals KNotify sends you. In 
principle, it's also possible to disable notifications of a given class 
(e.g. the one you'd define and use for the Fedora notifications) in KNotify, 
but it makes more sense to be able to disable the whole thing, including the 
fetching, it's no use fetching data just to have the resulting notifications 
eaten by KNotify at the user's request, that's why I didn't include your 
point 1 in the above list.

Kevin Kofler

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

Re: drop default MTA for Fedora 15

[Rudolf Kastl]

2010/8/25 Adam Williamson :
> On Tue, 2010-08-24 at 22:41 +0100, Matthew Garrett wrote:
>> On Tue, Aug 24, 2010 at 11:52:45AM -0700, Adam Williamson wrote:
>>
>> > FWIW, I'm with Jon and Adam on this one. I just don't see how not having
>> > an MTA by default is a win, except in disk space terms, and it takes up
>> > a tiny amount of disk space (especially if we pick a lighter-weight one
>> > than sendmail to be the default). I think it makes sense to keep one,
>> > for all the good reasons they cited.
>>
>> Shipping an MTA by default just gives developers the expectation that if
>> they pass something to sendmail then it'll be read by a human. Since
>> that's plainly untrue we should stop doing it and replace it with
>> something that's actually useful.
>
> By all means change the default MTA to something that 'works out of the
> box' in some way, yes. That'd be great, and much more of a feature than
> 'let's just remove it'.

as i wrote before i am not religous at all about an mta itsself but
rather about proper working notifications with history for raid
failure and logwatch. so a clear +1 here.

kind regards,
rudolf kastl

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedora mission (was Re: systemd and changes)

[Stephen John Smoogen]

On Wed, Aug 25, 2010 at 19:41, Mike McGrath  wrote:
> On Tue, 24 Aug 2010, Jeff Spaleta wrote:
>
>> On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields  wrote:
>> > I don't think anyone can generalize that the usage of Fedora is
>> > declining.  What we can prove, and certainly is troublesome, is that
>> > yum check-ins of successive releases have been dropping by a couple
>> > percent each release (although downloads are actually up), compared on
>> > a per-week basis.  It's no less likely that this decrease is due to
>> > people just staying on a stable release, even past EOL.  I've heard
>> > anecdotal evidence to support that, which is no more or less valuable
>> > than any other anecdotal evidence being presented, I suppose (IOW,
>> > probably not worth a thing).  If someone can present a hard analysis
>> > that points to only one possible scenario, fantastic -- we can start
>> > looking at causes.
>>
>> One additional metric which I'd like to see is the raw number of yum
>> check-ins per week regardless of ip-addresses as an historic trend.
>> As a stand alone metric its prone to both over and under counting like
>> the other metrics but in a different way. It would be interesting to
>> see if the raw yum check-in counts as an historic trend followed the
>> download trending or the unique-ip trending.
>>
>
> Ask and ye' shall receive.
>
> http://mmcgrath.fedorapeople.org/yum_hits.html
>
> I'm not quite sure what to make of it all yet except that this trend does
> conflict with the "current release" numbers we have on the statistics page
> (indicating people are using Fedora even after EOL) and that security
> incidents requiring a rebuild of everything is bad for business, at least
> temporarily :)

My graphic is not up to date but similar...

http://smooge.fedorapeople.org/images/growth-over-time.png

I need to update the numbers to after may and get the data 'cleaner'
and my lines darker because mmcgrath's looks better than mine.


-- 
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora Notifications System.

[Kevin Kofler]

Michal Hlavinka wrote:
> disabling something won't fix it, also I don't think this is that bad that
> it requires extra patch to turn it off by default and diverge from
> upstream

It shouldn't require a patch, just a config setting. That's what kde-
settings is for.

(But I also think the default should be changed upstream. This is really not 
what the notification system was designed for.)

Kevin Kofler

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

Re: Fedora Notifications System.

[Kevin Kofler]

Manuel Escudero wrote:
> I dont' know if it's possible to tweak the code of these apps, Or we can
> use Google Gadgets as a Base,

Please don't rely on Google stuff. The native RSS plasmoid is just fine. 
There's also Akregator, which is a regular KDE app to browse RSS feeds. We 
don't really need to tweak their code, we just need to set them to the right 
feed. For the plasmoid, this can be done with Plasma scripting. Akregator 
takes command-line arguments.

Kevin Kofler

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

Re: systemd and cgroups: heads up

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2010 05:46 PM, Lennart Poettering wrote:
> On Wed, 25.08.10 17:04, Matthew Miller (mat...@mattdm.org) wrote:
> 
>> If you are using the libcgroup package, and in particular the cgconfig
>> serivice, be aware that this will break systemd. This package is pulled into
>> Fedora by policycoreutils, so you likely have it on your system. However,
>> cgconfig is not enabled by default.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=626794
> 
> Hmm, why is libcgroup pulled in by policycoreutils? What's the
> rationale?
> 
> libcgroup should not interfere with /sys/fs/cgroup/systemd. That's
> systemd's turf, and to make that clear it is called... well... "systemd"...
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=627378
> 
> Lennart
> 
It is used for confining sandboxes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx1zbEACgkQrlYvE4MpobMS1ACfYGRnHGP5iVwHj028QUIfetnU
sxkAn0np53Rc2NDhfgecLFbReVMZq3KN
=11Jh
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora Notifications System.

[Manuel Escudero]

2010/8/25 Mika Kuusela 

> On Wed, 2010-08-25 at 20:05 -0500, Manuel Escudero wrote:
>
> > Now, this is the Fedora search engine:
> >
> >
> > http://ubuntuone.com/p/DuP/
> >
> >
> > I was wondering if it's possible to integrate a search box into hermes
> > that uses that engine as a base...
>
> The start.fedoraproject.org search engine is nothing but a Google search
> box. AFAIK, there have been discussions on the advisory-board list that
> "something" should be done with it, either make it to redirect to
> fedoraproject.org or something else.
>
>
> --
> Mika Kuusela
> wilmore @ #fedora-qa
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

@Mika: Thank's for the info, I've got another idea ;)

-- 
<-Manuel Escudero->
Linux User #509052
@GWave: jmlev...@googlewave.com
@Blogger: http://www.blogxenode.tk/ (Xenode Systems Blog)
PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31  1F8F 4AF4 D00C 50E7 ABC6
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora Notifications System.

[Mika Kuusela]

On Wed, 2010-08-25 at 20:05 -0500, Manuel Escudero wrote:

> Now, this is the Fedora search engine:
> 
> 
> http://ubuntuone.com/p/DuP/
> 
> 
> I was wondering if it's possible to integrate a search box into hermes
> that uses that engine as a base...

The start.fedoraproject.org search engine is nothing but a Google search
box. AFAIK, there have been discussions on the advisory-board list that
"something" should be done with it, either make it to redirect to
fedoraproject.org or something else.


-- 
Mika Kuusela
wilmore @ #fedora-qa

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

Re: fedora mission (was Re: systemd and changes)

[seth vidal]

On Wed, 2010-08-25 at 20:41 -0500, Mike McGrath wrote:
> On Tue, 24 Aug 2010, Jeff Spaleta wrote:
> 
> > On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields  
> > wrote:
> > > I don't think anyone can generalize that the usage of Fedora is
> > > declining.  What we can prove, and certainly is troublesome, is that
> > > yum check-ins of successive releases have been dropping by a couple
> > > percent each release (although downloads are actually up), compared on
> > > a per-week basis.  It's no less likely that this decrease is due to
> > > people just staying on a stable release, even past EOL.  I've heard
> > > anecdotal evidence to support that, which is no more or less valuable
> > > than any other anecdotal evidence being presented, I suppose (IOW,
> > > probably not worth a thing).  If someone can present a hard analysis
> > > that points to only one possible scenario, fantastic -- we can start
> > > looking at causes.
> >
> > One additional metric which I'd like to see is the raw number of yum
> > check-ins per week regardless of ip-addresses as an historic trend.
> > As a stand alone metric its prone to both over and under counting like
> > the other metrics but in a different way. It would be interesting to
> > see if the raw yum check-in counts as an historic trend followed the
> > download trending or the unique-ip trending.
> >
> 
> Ask and ye' shall receive.
> 
> http://mmcgrath.fedorapeople.org/yum_hits.html
> 
> I'm not quite sure what to make of it all yet except that this trend does
> conflict with the "current release" numbers we have on the statistics page
> (indicating people are using Fedora even after EOL) and that security
> incidents requiring a rebuild of everything is bad for business, at least
> temporarily :)
> 

HAHAHAH August 2008.

sigh.

-sv


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

Re: fedora mission (was Re: systemd and changes)

[Mike McGrath]

On Tue, 24 Aug 2010, Jeff Spaleta wrote:

> On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields  wrote:
> > I don't think anyone can generalize that the usage of Fedora is
> > declining.  What we can prove, and certainly is troublesome, is that
> > yum check-ins of successive releases have been dropping by a couple
> > percent each release (although downloads are actually up), compared on
> > a per-week basis.  It's no less likely that this decrease is due to
> > people just staying on a stable release, even past EOL.  I've heard
> > anecdotal evidence to support that, which is no more or less valuable
> > than any other anecdotal evidence being presented, I suppose (IOW,
> > probably not worth a thing).  If someone can present a hard analysis
> > that points to only one possible scenario, fantastic -- we can start
> > looking at causes.
>
> One additional metric which I'd like to see is the raw number of yum
> check-ins per week regardless of ip-addresses as an historic trend.
> As a stand alone metric its prone to both over and under counting like
> the other metrics but in a different way. It would be interesting to
> see if the raw yum check-in counts as an historic trend followed the
> download trending or the unique-ip trending.
>

Ask and ye' shall receive.

http://mmcgrath.fedorapeople.org/yum_hits.html

I'm not quite sure what to make of it all yet except that this trend does
conflict with the "current release" numbers we have on the statistics page
(indicating people are using Fedora even after EOL) and that security
incidents requiring a rebuild of everything is bad for business, at least
temporarily :)

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

Old gdm themes

[Garrett Holmstrom]

Why are bluecurve-gdm-theme and fedoraflyinghigh-gdm-theme still in the 
distribution?  The other gdm theme packages were deprecated after F12 
(!?!), and I was under the impression that none of them work with 
new-style gdm at all.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora Notifications System.

[Manuel Escudero]

2010/8/24 Manuel Escudero 

>
>
> 2010/8/24 Kevin Kofler 
>
> Michal Hlavinka wrote:
>> > disagree, have you seen your notifications after leaving your computer
>> > alone for several hours with IM client connected (with whatever status)?
>> >
>> > You'll get tons of "User XY has changed status to: blah blah"
>>
>> Well, IMHO Kopete shouldn't spam notifications for this type of non-
>> exceptional event at all. Is this enabled by default? If so, maybe we
>> should
>> disable it by default in kde-settings?
>>
>>Kevin Kofler
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>>
>
>
> Hey people! I have an advance for you, it's somewhat interesting... We're
> close to have what we're looking for... I'll share a video soon... :D
>
>
> --
> <-Manuel Escudero->
> Linux User #509052
> @GWave: jmlev...@googlewave.com
> @Blogger: http://www.blogxenode.tk/ (Xenode Systems Blog)
> PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31  1F8F 4AF4 D00C 50E7 ABC6
>
>
Well, now I have free time, let's see... I've been investigating and there's
a Plasma Widget called "RSSNOW", That's for KDE...
and For Gnome and derivates, there's a "Feed Reader" Screenlet... We also
have a "Fedora Search Engine"
So I was thinking in something like this:

http://ubuntuone.com/p/DuN/

I dont' know if it's possible to tweak the code of these apps, Or we can use
Google Gadgets as a Base, we build a Feed Parser that let the user suscribe
to a fedora Feed (Like planet's one or the twitter/facebook ones or
something else) so the users can select what kind of news they wanna recieve
and everytime there's a new
update the parser pop out and send a visual notification to the user.

Now, this is the Fedora search engine:

http://ubuntuone.com/p/DuP/

I was wondering if it's possible to integrate a search box into hermes that
uses that engine as a base...

I wanted to share a video of the "basic idea" but these pictures are enough
:)


-- 
<-Manuel Escudero->
Linux User #509052
@GWave: jmlev...@googlewave.com
@Blogger: http://www.blogxenode.tk/ (Xenode Systems Blog)
PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31  1F8F 4AF4 D00C 50E7 ABC6
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: is it still possible to use upstart as the init-system in F-14?

[Lennart Poettering]

B1;2590;0cOn Thu, 26.08.10 00:45, M A Young (m.a.yo...@durham.ac.uk) wrote:

> 
> On Wed, 25 Aug 2010, Rahul Sundaram wrote:
> 
> > On 08/25/2010 05:35 PM, M A Young wrote:
> >> Yes, upstart still works. I tried systemd and couldn't get it to work, so
> >> I switched the machine back to upstart. You may need a rescue disk to make
> >> the switch if your computer doesn't boot with systemd. I might try systemd
> >> again when more of the bugs have been ironed out.
> > Do you have any unreported bugs?
> 
> I tried it again, and basically the boot doesn't ever finish, it just sits 
> there without any useful indication as to what the problem is until I get 
> fed up and use the sysrq keys to reboot it ctrl-alt-del doesn't work).

This looks like the stuff I pointed out in this HEADS-UP mail:

http://lists.fedoraproject.org/pipermail/devel/2010-August/140294.html

plus the two followup mails.

Oh, and when you copy the command lines from that mail, make sure to
replace " at " by "@" as the archiver mangled this.

Lennart

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

Re: is it still possible to use upstart as the init-system in F-14?

[Tom London]

On Wed, Aug 25, 2010 at 4:45 PM, M A Young  wrote:
> On Wed, 25 Aug 2010, Rahul Sundaram wrote:
>
>> On 08/25/2010 05:35 PM, M A Young wrote:
>>> Yes, upstart still works. I tried systemd and couldn't get it to work, so
>>> I switched the machine back to upstart. You may need a rescue disk to make
>>> the switch if your computer doesn't boot with systemd. I might try systemd
>>> again when more of the bugs have been ironed out.
>> Do you have any unreported bugs?
>
> I tried it again, and basically the boot doesn't ever finish, it just sits
> there without any useful indication as to what the problem is until I get
> fed up and use the sysrq keys to reboot it ctrl-alt-del doesn't work).
>
>        Michael Young
> --

This sounds like a previously discussed issue with "upgrading a system
to systemd".

Referring to Lennart's HEADS UP:


 Heya,

 just a little heads up for when you upgrade a rawhide system that is a
 few weeks old to current rawhide: since we changed the way how some of
 the default symlinks of systemd are created you will end up with an
 installation that lacks many of the necessary symlinks -- but only if
 you upgrade from a systemd version from older rawhide to current
 rawhide. It's really only a problem in this case. It is not a problem
 with fresh F14 installations, and it is not a problem with upgrades from
 F13. The fix is easy: after upgrading just run this command as root and
 the missing links should be created:

# systemctl enable ge...@.service prefdm.service getty.target
rc-local.service remote-fs.target

 And that should make things work again.

 Sorry for the late heads-up.

 Lennart

Could this fix your boot hang?

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

If you cannot boot after installing systemd v8...

[Lennart Poettering]

Heya!

We shifted a few files around and most likely your
/etc/systemd/system/default.target link will now point into the void, in
case anaconda wrote it. If that happens to you and you end up in a
rescue shell instead of a full system after booting with v8, then please
execute the following:

  # ln -sf /lib/systemd/system/graphical.target 
/etc/systemd/systemd/default.target

or

  # ln -sf /lib/systemd/system/multi-user.target 
/etc/systemd/systemd/default.target

You can also choose to boot up into a normal system without the correct
default.target link, by passing "5" resp "3" on the kernel cmdline.

Sorry for breaking this (again), but with this in place things should be
at the appropriate places now for F14.

The bug against anaconda is already filed.

Lennart

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

Re: is it still possible to use upstart as the init-system in F-14?

[M A Young]

On Wed, 25 Aug 2010, Rahul Sundaram wrote:

> On 08/25/2010 05:35 PM, M A Young wrote:
>> Yes, upstart still works. I tried systemd and couldn't get it to work, so
>> I switched the machine back to upstart. You may need a rescue disk to make
>> the switch if your computer doesn't boot with systemd. I might try systemd
>> again when more of the bugs have been ironed out.
> Do you have any unreported bugs?

I tried it again, and basically the boot doesn't ever finish, it just sits 
there without any useful indication as to what the problem is until I get 
fed up and use the sysrq keys to reboot it ctrl-alt-del doesn't work).

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

Re: drop default MTA for Fedora 15

[Ben Boeckel]

pbrobin...@gmail.com  wrote:
> Its got nothing to do with gnome what so ever. I don't see what that
> has to do with the discussion. I actually want it so its easy to make
> tiny appliances and routers without having to manually strip a whole
> lot of crap out. As I mentioned above there's nothing to stop it being
> included in another comps group, but moving it out of core AND base as
> being mandatory (when its not).
>
> Peter

Here's a list of things I take out of my system via a kickstart file
(last reviewed for F13, systemd seems to have required a few selinux
things in the list):

@minimal

-audit
-authconfig
-checkpolicy
-cyrus-sasl
-efibootmgr
-iptables-ipv6
-libselinux-utils
-libsemanage
-policycoreutils
-procmail
-selinux-policy
-selinux-policy-targeted
-setserial

I imagine the selinux and iptables stuff will stay in @core and/or @base
but if the MTA is leaving, machines are usable without those packages as
well.

--Ben

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

Re: Testing zsh completion for fedpkg

[Ben Boeckel]

Christopher Aillon  wrote:
> I missed the first notice of this go by, but I use zsh so can play with 
> it in the next few days.  Can you post the updates so I don't hit the 
> same bugs you did?

Sure. Attached. The bugs were mainly with zsh conventions and getting
the sed command for the branch selection corrected.

--Ben
#compdef fedpkg

_fedpkg_help_args=( {-h,--help}'[show the help message]' )
_fedpkg_arches_array=( noarch i386 x86_64 ppc ppc64 s390x )
_fedpkg_arches_regex="(${(j:|:)_fedpkg_arches_array})"
_fedpkg_arches="('${(j:' ':)_fedpkg_arches_array}')"
_fedpkg_branches_array=( "master" "f"{1..14} )
_fedpkg_branches="('${(j:' ':)_fedpkg_branches_array}')"

# Main dispatcher
_fedpkg ()
{
local curcontext="$curcontext" state lstate line

_arguments -s \
$_fedpkg_help_args \
{-u,--user}'[username]:username' \
'--path[directory to interact with instead of current dir]:path:_dirs' \
'-v[verbose]' \
'-q[only display errors]' \
'*::fedpkg command:_fedpkg_command'
}

(( $+functions[_fedpkg_command] )) || _fedpkg_command ()
{
local -a _fedpkg_cmds
_fedpkg_cmds=(
"help:show usage"
"build:request build"
"chain-build:build current package in order with other packages"
"clean:remove untracked files"
"clog:make a clog file containing top changelog entry"
{clone,co}":clone and checkout a module"
"commit:commit changes"
"compile:local test rpmbuild compile"
"diff:show changes between commits, commit and working tree, etc"
"gimmespec:print spec file name"
"import:import content into a module"
"install:local test rpmbuild install"
"lint:run rpmlint against local build output"
"local:local test rpmbuild binary"
"mockbuild:local test build using mock"
"new:diff against last tag"
"new-sources:upload new source files"
"patch:create and add a gendiff patch file"
"prep:local test rpmbuild prep"
"push:push changes to remote repository"
"scratch-build:request scratch build"
"sources:download source files"
"srpm:create a source rpm"
"switch-branch:switch release branches"
"tag-request:submit last build as a releng tag request"
"unused-patches:print list of patches not referenced by name in 
specfile"
"update:submit last build as an update"
"upload:upload source files"
"verrel:print the name-version-release"
)

if (( CURRENT == 1 )); then
_describe -t commands 'fedpkg command' _fedpkg_cmds || compadd "$@"
else
local curcontext="$curcontext"

cmd="${${_fedpkg_cmds[(r)$words[1]:*]%%:*}}"
# Deal with any aliases
case $cmd in
co) cmd="clone";;
esac

if (( $#cmd )); then
curcontext="${curcontext%:*:*}:fedpkg-${cmd}:"

local update_policy
zstyle -s ":completion:${curcontext}:" cache-policy update_policy
if [[ -z "$update_policy" ]]; then
zstyle ":completion:${curcontext}:" cache-policy 
_fedpkg_caching_policy
fi

_call_function ret _fedpkg_$cmd || _fedpkg_help_arg
else
_message "unknown fedpkg command: $words[1]"
fi

return ret
fi
}

# Ripped from _git, any way to access it without copy/paste?
(( $+functions[__git_command_successful] )) ||
__git_command_successful () {
  if (( ${#pipestatus:#0} > 0 )); then
_message 'not a git repository'
return 1
  fi
  return 0
}

(( $+functions[__git_files] )) ||
__git_files () {
  local expl files ls_opts opts gitdir

  zparseopts -D -E -a opts -- -cached -deleted -modified -others -ignored 
-unmerged -killed

  gitdir=$(_call_program gitdir git rev-parse --git-dir 2>/dev/null)
  __git_command_successful || return

  ls_opts=("--exclude-per-directory=.gitignore")
  [[ -f "$gitdir/info/exclude" ]] && 
ls_opts+="--exclude-from=$gitdir/info/exclude"

  files=(${(ps:\0:)"$(_call_program files git ls-files -z $ls_opts $opts 
2>/dev/null)"})
  __git_command_successful || return

  _wanted files expl 'index file' _multi_parts $@ - / files
}


# Help messages are ubiquitous
(( $+functions[_fedpkg_help_arg] )) || _fedpkg_help_arg ()
{
_arguments -s \
$_fedpkg_help_args
}

# Architecture completion
(( $+functions[_fedpkg_arches_values] )) || _fedpkg_arches_values ()
{
_values -s , 'architectures' \
$_fedpkg_arches_array
}

# Branch completion
(( $+functions[_fedpkg_branch] )) || _fedpkg_branch ()
{
local _branches
fedpkg switch-branch > /dev/null 2> /dev/null || return 1
_branches=( $(fedpkg switch-branch -l | sed -n -e 's!^ 
*!!;s!^origin/!!;/^master$/p;s!/master$!!p' | sort -u) )
_arguments -s \
":branch:($_branches)"
}

# Package list completion
(( $+functions[_fedpkg_packages] )) || _fedpkg_packages ()
{
[[ -x koji ]] && return 1
if [[ ${+_p

Re: systemd and cgroups: heads up

[Lennart Poettering]

On Wed, 25.08.10 17:04, Matthew Miller (mat...@mattdm.org) wrote:

> If you are using the libcgroup package, and in particular the cgconfig
> serivice, be aware that this will break systemd. This package is pulled into
> Fedora by policycoreutils, so you likely have it on your system. However,
> cgconfig is not enabled by default.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=626794

Hmm, why is libcgroup pulled in by policycoreutils? What's the
rationale?

libcgroup should not interfere with /sys/fs/cgroup/systemd. That's
systemd's turf, and to make that clear it is called... well... "systemd"...

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

Lennart

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

systemd and cgroups: heads up

[Matthew Miller]

If you are using the libcgroup package, and in particular the cgconfig
serivice, be aware that this will break systemd. This package is pulled into
Fedora by policycoreutils, so you likely have it on your system. However,
cgconfig is not enabled by default.

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

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[drago01]

On Wed, Aug 25, 2010 at 5:56 PM, Adam Williamson  wrote:
> On Wed, 2010-08-25 at 15:35 +0200, drago01 wrote:
>
>> Indeed, imo we should add them to the release criteria.
>
> It's a rather indigestible lump, for the criteria. James and I were
> thinking about a 'module' system for the release criteria so it can link
> out to other pages, but I'm wondering when a dilution effect would start
> kicking in. I'm not sure everything on that list is genuinely something
> we'd hold up a release for, either. But it's certainly something I want
> to use for the systemd test day.

Well I am not saying "go add the whole list" ... but at least a subset of it.
Having a working initsystem should be release goal imo (where working
is more than just "it boots").
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git rebase OK on Fedora git branches?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/25/10 3:45 AM, Stanislav Ochotnicky wrote:
> Excerpts from Daniel P. Berrange's message of Wed Aug 25 11:08:16 +0200 2010:
>> On Tue, Aug 24, 2010 at 11:34:36AM -0700, Jesse Keating wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 8/24/10 6:43 AM, Richard W.M. Jones wrote:
 Is it OK to use 'git rebase -i' to compress my mistakes together into
 a single working Fedora git commit?  (Provided I don't push things in
 between or otherwise try to rewrite public history)

 I'm a bit confused by whether 'fedpkg commit', 'fedpkg build', 'fedpkg
 push' etc are doing magic that will be broken by this.

 Rich.

>>>
>>> You are free to do any sort of history altering actions you want prior
>>> to a push.  fedpkg will prevent you from trying to build something that
>>> hasn't been pushed unless you're doing a scratch build.  commit and push
>>> are very thin wrappers over the git equivs.
>>
>> Is there a server side hook/check to prevent accidentally pushing
>> non-fastforward commits ?
> 
> Standard git repositories deny pushing non fast-forward commits unless
> you --force the push. So yes I guess there is protection, I haven't
> tried if --force is allowed or not (I guess it should not be on allowed
> on standard branches)
> 
> 

Right now the ACL system prevents non-fast forward pushes, even with
- --force, for everything.  I have on my "white board" to look into
allowing non-fastforward changes within the user/* branch space, as well
as completely open ACLs within that branch space.  It's not the top of
my whiteboard yet though.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx1fDIACgkQ4v2HLvE71NXX7ACfRVnwQ8xhGqlJgrPijmR101FB
PoAAmgJ3I4TCQ0GK3B1WWIbrE5IlqSd3
=tLfM
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Testing zsh completion for fedpkg

[Christopher Aillon]

On 08/24/2010 07:31 PM, Ben Boeckel wrote:
> Jesse Keating  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 7/30/10 9:34 PM, Ben Boeckel wrote:
>>> I'd like to get some wider testing on it than what I subjected it to.
>>> Constructive criticism welcome.
>>>
>>
>> Did you ever get testing on this?
>
> Nothing past my own usage. I hit some bugs, but fixed those I did find.

I missed the first notice of this go by, but I use zsh so can play with 
it in the next few days.  Can you post the updates so I don't hit the 
same bugs you did?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd or why will user fall away from fedora?

[Richard W.M. Jones]

On Wed, Aug 25, 2010 at 01:38:00PM -0400, Jon Masters wrote:
> Anyway, I've always read the boot time thing as just a bit of fun had by
> those who probably notice it the most. I've yet to be convinced it
> really matters to everyone else any more,

libguestfs cares (and you'll care if you're waiting for a libguestfs
command to run).  We don't run systemd or very much of userspace, but
we care how long it takes to boot KVM, the kernel and udevd.

I'm happy to say with the latest set of changes (not yet pushed out to
Fedora), this is down to under 5 seconds.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: a note on order of arguements to systemctl command

[Matthew Miller]

On Wed, Aug 25, 2010 at 03:51:11PM -0400, Bill Nottingham wrote:
> > I'm not saying that systemctl's syntax needs to be changed. I am saying,
> > however, that it's important to get the service command working with
> > systemctl so that people can use that instead.
> FYI, this is done in git, will be built today/tomorrow.

I saw -- thanks, and looking forward to trying it.

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd or why will user fall away from fedora?

[dr johnson]

Certainly will after there is a new version pushed out.  Currently I'm
blocked by three other "fixed upstream" bugs that have been closed with no
update to f14 repos.

Maybe the new revision will solve the bootime issue too.

I am very curious if anyone can demonstrate that systemd is actually faster
than upstart at all. Even if only by one second.

 -dj



-- 
   Scire ubi aliquid invenire possis, ea demum maxima pars eruditionis est
--Anonymous


-Original Message-


On Wed, Aug 25, 2010 at 2:52 PM, Bill Nottingham  wrote:

> dr johnson (d...@www.uk.linux.org) said:
> > That would be all grand and spiffy if it were actually faster bootup.
> >
> > Bootchart here reports that systemd is 8 seconds *SLOWER* than upstart.
>  No
> > idea why, but systemd just hangs for 8 seconds doing "nothing" that I can
> > see.  No logs anywhere that are meaningful.  Default clean install from
> > Alpha iso or Nightly livecd -- both do the same.
>
> Can you file this, please? (Apologies if I missed it.)
>
> Bill
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Matthew Miller]

On Wed, Aug 25, 2010 at 03:27:54PM -0400, Bill Nottingham wrote:
> chkconfig is different, because it's not a 1:1 mapping, and there are
> different semantics involved. I'd like to have it working so that the
> automated uses in scripts/frameworks work (checking whether a service is
> enabled, for example), with the realization that everything it's used for
> isn't going to be supported.

I think that either having chkconfig working fully *or* having an arguably
improved systemd replacement¹ is a blocker. The automated uses should work,
but also these basic end-user/admin use cases (refinements welcome, btw):

  - enable a service in its "normal" targets

  - disable a service in all targets 

  - enable/disable a service ("unit" in systemd-speak) in a given target
with one easy command

  - nicely list all units that will be enabled in a given target
(recursively, with some thought put into the formatting)

  - nicely list all targets in which a given unit will be enabled
(with the option of only showing targets which are sensible
for isolate/switch-to).

I don't think this is an onerous requirement, because systemctl already does
the first two things, and does the last two are almost there (just with no
pretty output). The middle thing, as I understand it, Lennart would rather
people do by manually creating and moving symlinks, but I think there's a
pretty good case for having a user-interface to do it.

(That case being: people used to administer sysvinit runlevels by
manipulting symlinks, and it sucked. Then we got chkconfig as standard, and
it was much nicer.)

And in the "or" case, there needs to be really good release notes, offering
tasty, tasty cake. That is:

 1) explaining that the change is necessary because the semantics don't
 match exactly,

 2) giving a concise explanation of why the new semantics are better

 3) showing off the command and how to use it

 4) showing something cool this give you that chkconfig doesn't offer.





1. as discussed here:
http://lists.fedoraproject.org/pipermail/devel/2010-August/141713.html


-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaned package: system-config-display

[Rahul Sundaram]

 On 08/26/2010 01:22 AM, Adam Jackson wrote:
> I don't have time for it, and I think it's fundamentally misguided.  If
> someone else feels like owning it, go wild.
>
> This will probably also require access to the upstream repo, so, do
> speak up if you take it so we can sort that out.

Assuming noone picks it up, we will have to document this in the release
notes.  Can you give a brief explanation on why you believe it is
misguided for the sake of documentation?

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

Re: systemd or why will user fall away from fedora?

[Bill Nottingham]

dr johnson (d...@www.uk.linux.org) said: 
> That would be all grand and spiffy if it were actually faster bootup.
> 
> Bootchart here reports that systemd is 8 seconds *SLOWER* than upstart.  No
> idea why, but systemd just hangs for 8 seconds doing "nothing" that I can
> see.  No logs anywhere that are meaningful.  Default clean install from
> Alpha iso or Nightly livecd -- both do the same.

Can you file this, please? (Apologies if I missed it.)

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

Orphaned package: system-config-display

[Adam Jackson]

I don't have time for it, and I think it's fundamentally misguided.  If
someone else feels like owning it, go wild.

This will probably also require access to the upstream repo, so, do
speak up if you take it so we can sort that out.

- ajax


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: a note on order of arguements to systemctl command

[Bill Nottingham]

Matthew Miller (mat...@mattdm.org) said: 
> I'm not saying that systemctl's syntax needs to be changed. I am saying,
> however, that it's important to get the service command working with
> systemctl so that people can use that instead.

FYI, this is done in git, will be built today/tomorrow.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> Hmm, so this is about files that are deleted but still mapped by init,
> and which can only be deleted when init stops referencing them, but that
> is required to remount the fs r/o? Did I get this right?

Correct. 

> I am not really convinced that reexecing is the right answer for this
> problem. But well, since this already works anyway I guess this doesn't
> really matter too much.

It's the only answer I know of which doesn't require kernel changes.

> > > > PACKAGING
> > > > - Guidelines for packaging systemd units shall be formalized.
> > > 
> > > As pointed out elsewhere, I'd avoid this for F14.
> > 
> > Then we should put "don't" in the guidelines, instead. We need to set clear
> > expectations for package maintainers as to what they should be doing. (And
> > certainly not switching the state of their packages mid-release.)
> 
> Well, if we can agree on "don't, unless you contacted Lennart or [add
> list here] and he said it's OK" then I am fine with this.

That works for me.

> Well, if we can agree on "after all sysv services that include no proper
> ordering dependency information in the LSB headers", then I'd be fine
> with this. If sysv services contain LSB headers, we should follow the
> ordering it encodes, not come with implicit additional rules.

SysV services don't have a dependency concept of 'this needs to run
after me', AFAIK. So rc.local always implying 'I'm the last thing' isn't
something that could be stated correctly in mere LSB deps.

> > OK, so now you've stated 5 times in this mail some equivalent of
> > 'that's not my package, it shouldn't be my problem, I don't want to be
> > responsible for this.'
> > 
> > I'm going to be blunt. I DON'T CARE.
> 
> Yay, thanks that you don't care. You are aware that by putting
> everything on a single man's shoulders and then telling him "you don't
> care" you make him feel really welcome and make him wonder why he
> even bothers with this shit?

I'm not putting it on the shoulders of one man. I'm putting it on the
shoulders of *the project*. These are the issues that need to work;
these are the bugs that need to be fixed. If the scenarios have problems,
we'll assign bugs and go from there. But in *generating* the scenarios that
need to work, I'm not concerned with whose plate it falls on - it falls
on everyone's.

> > Sure, I suppose individual maintainers want to push their code over the 
> > wall and
> > then sit in their silo and claim 'that's not my problem' and 'someone else
> > needs to fix that', well, that's their right to be lame. But we, as Fedora,
> > as producers of a product that we ship to our users, don't have that luxury.
> 
> But you enable them to block out change. For example, if somebody
> refuses to merge a patch that adds a systemd equivalent for an upstart
> config hook he has, he can sink the whole systemd in fedora project. I
> am pretty sure some folks would be really happy to have that power...

That's what provenpackager and FESCo is for. We've forced patches to be
merged in the past. (Related to PA, if I remember right.)

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Chris Adams (cmad...@hiwaay.net) said: 
> > > This is a very big change. chkconfig has worked for a long, long time. Its
> > > elegance and simplicity is one of the nice administrative features of Red
> > > Hat based distributes. People like it.
> > 
> > Yes, and they should continue to use it -- for sysv scripts.
> 
> I thought the last big discussion resulted in agreement that chkconfig
> and service should continue to work for all services.  Is that not the
> case?

service can, because it's pretty much a 1:1 mapping. (It's currently fixed
in git; it's telling you it's using systemctl while doing the appropriate
thing.)

chkconfig is different, because it's not a 1:1 mapping, and there are
different semantics involved. I'd like to have it working so that the
automated uses in scripts/frameworks work (checking whether a service is
enabled, for example), with the realization that everything it's used for
isn't going to be supported.

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

Re: fedora mission (was Re: systemd and changes)

[jpirie23]

> And some of us students switched to
>Fedora *because of* the stable 
>updates vision.

>In my experience, the lack of Fedora users >at my university is mostly
>due to other distros having better >marketing and the fact that new
>people will use whatever they can get help >with (ie. whatever distro
>their friends are using).  It has little to >nothing to do with "people
>slowly destroying what Fedora is all about."

Could not agree more strongly with you. +1. 

IMHO this is the distribution that all of the Computer Science students should 
be using and I encourage many to use it, but in the cases I know of where they 
are not, it has nothing to do with those aforementioned people and more to do 
with loyalty to a Debian based distribution for one reason or another (usually 
because their other distro is less technically challenging and they opt for the 
lazy route!).
--
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedora mission (was Re: systemd and changes)

[Eli L.]

> Matthew Miller wrote:
>> I don't know a single student using Fedora anymore,
>> I don't know *what* to blame that on
>
> I blame it on people slowly destroying what Fedora is all about, with things
> like that "stable updates vision".

And some of us students switched to Fedora *because of* the stable
updates vision.

In my experience, the lack of Fedora users at my university is mostly
due to other distros having better marketing and the fact that new
people will use whatever they can get help with (ie. whatever distro
their friends are using).  It has little to nothing to do with "people
slowly destroying what Fedora is all about."

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

Re: How many lost users is an acceptable loss in exchange for systemd?

[Petrus de Calguarium]

Gregory Maxwell wrote:

> To say it bluntly:  Any significant infrastructural change _will_ cost
> Fedora some users in the short term.
> 

I'm not lost.

I am using F14α as my day-to-day system since the weekend. I am considering 
putting F14α 
on my laptop, too, so goodbye F13. I have experienced no problems whatsoever 
that could 
in any way be attributed to systemd, AFAICT (some minor video compositing 
glitches, a 
few spambayes, gnome-keyring crashes, that's about it).

I trust that the developers know more than I know. They haven't left me lying 
yet. Novel 
ideas and the brainpower to be able to implement them are what make Fedora 
stand out 
from the other distros.


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

Re: Fedora Notifications System.

[Mahmoud Abdul Jawad]

after spending two days reading the two fedora mailing lists (fedora
users & fedora devel), i got a list of ideas that need to be
implemented in order to keep the things up:
1. the abililty to turn off the system
2. smart notifications (maybe multilanguage, geolocation-based, &
time-aware notes)
3. keep a history of the notifications
4. max. number of notifications at the time
5. click able notifications
6. stackable notifications
7. manageable feeds

any issue about any of those points??

-- 
Regards,,
Mahmoud Abdul Jawad
@meGenius
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd or why will user fall away from fedora?

[Jon Masters]

On Wed, 2010-08-25 at 18:37 +0100, Matthew Garrett wrote:
> On Wed, Aug 25, 2010 at 09:31:30AM -0400, Jon Masters wrote:
> 
> > [...@constitution ~]$ uptime
> >  09:28:22 up 24 days, 16:32,  9 users,  load average: 1.17, 0.50, 0.37
> 
> So you're running an insecure kernel? Our security churn is bad enough 
> right now that rebooting is something people do fairly regularly.

Yup, this desktop is running a kernel that still needs upgrading. I've
scheduled some time later this week to build a new one and test it
before I reboot the machine, but I won't be doing a yum update. When
I've got anecdotal evidence that updates have weeklong soak test time,
the barrier to entry is much higher, or similar, then I will do that.

Jon.


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

Re: systemd or why will user fall away from fedora?

[Jon Masters]

On Wed, 2010-08-25 at 17:06 +0100, Richard W.M. Jones wrote:

> I reboot virtual machines all the time, certainly 100 times a day
> would not be unusual on a work day.
> 
> Not an argument for or against systemd BTW, just an observation that
> how you use your computer is not how others use their computers.  You
> need to measure these things scientifically, not base it on your own
> personal experience.

Both true. I also have dozens of virtual machines that are frequently
rebooted, but generally speaking I hit the virtual button and don't care
whether it takes 30, or 38 seconds to get there. It's like when watching
a server and often laughing at how long it'll take the BIOS and bootable
devices to do their thing compared with the eventual, actual boot.

Anyway, I've always read the boot time thing as just a bit of fun had by
those who probably notice it the most. I've yet to be convinced it
really matters to everyone else any more, but you're right about stats
being the answer. I'd love to see a Fedora User Survey about what they
actually care about, and I asked for one to be done some time ago.

Jon.


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

Re: systemd or why will user fall away from fedora?

[Matthew Garrett]

On Wed, Aug 25, 2010 at 09:31:30AM -0400, Jon Masters wrote:

> [...@constitution ~]$ uptime
>  09:28:22 up 24 days, 16:32,  9 users,  load average: 1.17, 0.50, 0.37

So you're running an insecure kernel? Our security churn is bad enough 
right now that rebooting is something people do fairly regularly.

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

Re: How many lost users is an acceptable loss in exchange for systemd?

[seth vidal]

On Wed, 2010-08-25 at 13:12 -0400, Gregory Maxwell wrote:
> And, yes, the harm won't be equally distributed— it seems to me that
> Fedora has ignored quite a bit of harm because it didn't primarily
> fall on what the developer's considered a "typical desktop"  (which,
> as far as I can tell, really means a particularly narrow set of laptop
> hardware with a particularly narrow set of users and use cases).  Why
> Fedora keeps chasing a market which Ubuntu has undeniably won is
> beyond me— but nevertheless it's not acceptable to pretend that harms
> don't exist simply because they don't hit the one use case you care
> about most, not unless Fedora is willing to say that people running
> servers, developers, and other power users ought to use some other
> distribution and that Fedora doesn't care if it loses all of these
> users.
> 


Well - to be fair - fedora is going to take a big ding in terms of users
whenever rhel6 (and centos6, I assume) is released.

It'll be relatively new and stable-focused.

Just like we did with rhel5..


-sv


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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Matthew Miller]

On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote:
> backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes,
> etc. welcome.

We need something in here about cgroups. Doing something useful by default
with cgroups is one of the big selling points for systemd. We should be
clear on what's intented to work now (each user session in a unique cgroup)
and insure that that's working, document (loosely) plans for the future, and
define how systemd's use of cgroups should interact with other tools (like
libcgroup) for this release and for the future.


-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

How many lost users is an acceptable loss in exchange for systemd?

[Gregory Maxwell]

In many of the recent systemd threads there is an underlying point
which I think is on many people's minds but which I haven't seen
called out. I think this is a generic issue, so it's a but unfair to
single out systemd but it makes a good example.

To say it bluntly:  Any significant infrastructural change _will_ cost
Fedora some users in the short term.

The amount lost depends on the specific feature and the effort put in
to minimize the bugs and disruption, — usually with enough effort and
enough compromises and concessions the number can be made arbitrarily
small but it will not be zero. This is especially the case for
features which make the system more or less unrecoverable inoperable
for 'normal' users when something goes wrong, but it's true more
generally as well.

And I do think that some loss is acceptable— without tolerating some
loss Fedora simply couldn't move forward— no matter how wise or
overdue a change is there will be bugs, differences in taste, and
disruption. There are some people who are continuing to use Fedora
only because learning SomethingElse™ is too much work but when Fedora
changes and they'll have to learn either way Fedora's "advantage"
vanishes to them.

And, yes, the harm won't be equally distributed— it seems to me that
Fedora has ignored quite a bit of harm because it didn't primarily
fall on what the developer's considered a "typical desktop"  (which,
as far as I can tell, really means a particularly narrow set of laptop
hardware with a particularly narrow set of users and use cases).  Why
Fedora keeps chasing a market which Ubuntu has undeniably won is
beyond me— but nevertheless it's not acceptable to pretend that harms
don't exist simply because they don't hit the one use case you care
about most, not unless Fedora is willing to say that people running
servers, developers, and other power users ought to use some other
distribution and that Fedora doesn't care if it loses all of these
users.

Consider systemd— even if far more work goes into it I think we can
admit that it will be very likely that there will be some users with
some weird configurations which won't boot up with it.  We can blame
their weird configurations, hardware, and random packages as much as
we like— but at the end of it some of these users are going to leave
Fedora because of the change.   Some administrators are going to hate
the management changes and switch off Fedora as a result.  We might
all agree that they're lazy or crazy but it is what it is.

These losses can be reduced by making systemd emulate the old stuff
more accurately (at a cost to systemd's long term purity), by more
testing, by providing fallbacks, etc. But some compromises aren't
acceptable, no testing is perfect, and many people will never learn
about the fallbacks.

The same stuff could have been said about kernel modesetting.

The sooner people admit this the sooner people can agree on what the
acceptable loss level is... Without knowing the acceptable loss level
it won't be easy to agree on a release criteria or agree on how much
mitigating compromises are required to get there. Denying it or
blaming other packages just makes the Fedora community blind to the
risks, which is sad since many of them can be reduced and managed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd or why will user fall away from fedora?

[Richard W.M. Jones]

On Wed, Aug 25, 2010 at 12:20:52PM +0200, Christof Damian wrote:
> On Tue, Aug 24, 2010 at 23:06, Mike McGrath  wrote:
> > On Tue, 24 Aug 2010, Till Maas wrote:
> >> If they like a faster bootup, then yes, they will. And I as a
> >> workstation user like it.
> >>
> >
> > [citation needed]
> >
> > I asked for this and was told by developers they were reluctant to post
> > the data.
> 
> I also wonder who these people are who boot their computers so often
> that boot-up speed makes any difference over a whole day.

I reboot virtual machines all the time, certainly 100 times a day
would not be unusual on a work day.

Not an argument for or against systemd BTW, just an observation that
how you use your computer is not how others use their computers.  You
need to measure these things scientifically, not base it on your own
personal experience.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Fedora 14 Beta Blocker Bug Review Meeting #1 2010-08-27 @ 16:00 UTC (12 PM EST)

[James Laska]

> When: Friday, 2010-08-27 @ 16:00 UTC (12 PM EST)
> Where: #fedora-bugzappers on irc.freenode.net

Right of the coat tails of Fedora 14 Alpha, it's time for another
installment of  the blocker bug review meeting!  Friday kicks
off the first of several Beta bug review meetings.

If you are the owner of a F14Beta bug, please take a moment to update
the bug with:
 1. feedback as to whether you believe it is a blocker
 2. plans/expectations for addressing the bug

If you have a bug that is *not* listed, but should be considered as a
blocker bug:
 1. Please consult the release criteria
(https://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria)
 2. Add a comment to the bug indicating which criteria are impacted
 3. Simply add 'F14Beta' to the "Blocks" field of the bug you are
concerned about

Included below is the current F14Beta blocker bug list.  We'll be
discussing each bug to determine if they meet the criteria, should stay
on the list, and are getting the attention they need.

https://bugzilla.redhat.com/show_bug.cgi?id=624208
   NEW :: mesa :: Adam Jackson
   [F14 REGRESSION] KDE desktop effects with OpenGL: no display updates

https://bugzilla.redhat.com/show_bug.cgi?id=618504
   NEW :: xmlrpc-c :: Enrico Scholz
   Cannot submit abrt bugs

https://bugzilla.redhat.com/show_bug.cgi?id=623126
   NEW :: qemu :: Justin M. Forbes
   F14 Alpha CD install fails in KVM guest

https://bugzilla.redhat.com/show_bug.cgi?id=624971
   NEW :: preupgrade :: Richard Hughes
   Fail to upgrade with preupgrade-1.1.4-1.fc13

https://bugzilla.redhat.com/show_bug.cgi?id=621027
   NEW :: fedora-logos :: Tom "spot" Callaway
   Graphical screen in anaconda shows F-13

https://bugzilla.redhat.com/show_bug.cgi?id=621685
   MODIFIED :: anaconda :: Brian C. Lane
   TypeError: sequence item 0: expected string, NoneType found
https://bugzilla.redhat.com/show_bug.cgi?id=622927
   MODIFIED :: anaconda :: Radek Vykydal
   F14 Alpha RC2 - /etc/resolv.conf gets corrupted, cannot download
packages
https://bugzilla.redhat.com/show_bug.cgi?id=623524
   NEW :: anaconda :: Anaconda Maintenance Team
   Err during filesystem check after upgrading bootloader

https://bugzilla.redhat.com/show_bug.cgi?id=615386
   ON_QA :: autofs :: Ian Kent
   automount[3035]: open_lookup:90: cannot open lookup module ldap
(/usr/lib64/autofs/lookup_ldap.so: undefined symbol:
krb5_get_init_creds_keytab)

See you Friday,
James


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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Adam Williamson]

On Wed, 2010-08-25 at 15:35 +0200, drago01 wrote:

> Indeed, imo we should add them to the release criteria.

It's a rather indigestible lump, for the criteria. James and I were
thinking about a 'module' system for the release criteria so it can link
out to other pages, but I'm wondering when a dilution effect would start
kicking in. I'm not sure everything on that list is genuinely something
we'd hold up a release for, either. But it's certainly something I want
to use for the systemd test day.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: is it still possible to use upstart as the init-system in F-14?

[Adam Williamson]

On Wed, 2010-08-25 at 13:05 +0100, M A Young wrote:
> On Wed, 25 Aug 2010, Peter Lemenkov wrote:
> 
> > I would like to know before trying/upgrading F-14 is it still possible
> > to use upstart instead of systemd in F-14?
> 
> Yes, upstart still works. I tried systemd and couldn't get it to work, so 
> I switched the machine back to upstart. You may need a rescue disk to make 
> the switch if your computer doesn't boot with systemd. I might try systemd 
> again when more of the bugs have been ironed out.

This will happen when you file a bug report. :) You're not hitting some
sort of typical breakage everyone already knows about - systemd works
fine here, and as far as I can tell, is generally working OK in the
Alpha.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: drop default MTA for Fedora 15

[Adam Williamson]

On Wed, 2010-08-25 at 09:01 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > FWIW, I'm with Jon and Adam on this one. I just don't see how not having
> > an MTA by default is a win, except in disk space terms, and it takes up
> > a tiny amount of disk space (especially if we pick a lighter-weight one
> > than sendmail to be the default). I think it makes sense to keep one,
> > for all the good reasons they cited.
> 
> It also takes up live image space, which is a very scarce resource, it's 
> always a fight to keep our live images within the size constraints.

The fairly freakin' outdated size constraints? I wish we could resurrect
that thing from F13 about making the live images 1GB. No-one burns them
to CDs any more.

(BTW, Size: 1618955 - it's 1.6MB, installed. That's pretty tiny
even by live CD standards.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: drop default MTA for Fedora 15

[Adam Williamson]

On Tue, 2010-08-24 at 22:41 +0100, Matthew Garrett wrote:
> On Tue, Aug 24, 2010 at 11:52:45AM -0700, Adam Williamson wrote:
> 
> > FWIW, I'm with Jon and Adam on this one. I just don't see how not having
> > an MTA by default is a win, except in disk space terms, and it takes up
> > a tiny amount of disk space (especially if we pick a lighter-weight one
> > than sendmail to be the default). I think it makes sense to keep one,
> > for all the good reasons they cited.
> 
> Shipping an MTA by default just gives developers the expectation that if 
> they pass something to sendmail then it'll be read by a human. Since 
> that's plainly untrue we should stop doing it and replace it with 
> something that's actually useful.

By all means change the default MTA to something that 'works out of the
box' in some way, yes. That'd be great, and much more of a feature than
'let's just remove it'.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

F-14 Branched report: 20100825 changes

[Branched Report]

Compose started at Wed Aug 25 13:15:34 UTC 2010

Broken deps for x86_64
--
PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so
PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit)
QuantLib-test-1.0.1-3.fc14.x86_64 requires 
libboost_unit_test_framework.so.1.41.0()(64bit)
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2
1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10
cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires 
libpython2.6.so.1.0()(64bit)
evince-libs-2.31.90-1.fc14.i686 requires libpoppler.so.7
evince-libs-2.31.90-1.fc14.x86_64 requires libpoppler.so.7()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit)
fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10
fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_iostreams-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10
glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10
libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit)
libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10
libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10
libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10
libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit)
1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4
1:libguestfs-1.5.2-4.fc14.x86_64 requires /lib64/libxtables.so.4
libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.i686 requires 
libboost_filesystem-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libpst-python-0.6.47-4.fc14.x86_64 requires 
libboost_python.so.1.41.0()(64bit)
libvirt-qpid-0.2.18-1.fc14.x86_64 requires libqmf.so.1()(64bit)
libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10
libvte-java-0.12.1-15.fc12.x8

Re: stuck on git (again)

[Andreas Schwab]

Michael Cronenworth  writes:

> Without that config option you need:
>
> $ git push f13/master

The first argument is the repository to push to.  Also, since local and
remote branch have different names you have to specify both.

$ git push origin f13:f13/master

(fedpkg should have reverted to use matching branch names!)

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Broken dependencies: perl-Pugs-Compiler-Rule

[buildsys]

perl-Pugs-Compiler-Rule has broken dependencies in the F-14 tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
On i386:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
Please resolve this as soon as possible.


--
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: stuck on git (again)

[Todd Zullinger]

Neal Becker wrote:
> Michael Cronenworth wrote:
>
>> Neal Becker wrote:
>>> No idea what this means.
>>
>> It means it has been 10 commits since you have pushed ("synced")
>> with the git repo living on pkgs.fedoraproject.org. Remember that
>> you have your own unique git repository living on your local
>> system.
>
> But all I did was update the spec file (and did new sources), so how
> is that 10 commits?

You mentioned doing a merge of the origin/master branch.  That would
likely pull in a number of new commits.

Prior to the switch to git, the imported cvs "branches" might look
identical, but when they were imported to git, they have different
histories and different commit id's.  So the first merge you do to
sync f13 with master will bring in all the commits that are on master
which aren't on f13.  Future merges should be less noisy.

-- 
ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
Don't take life seriously, you'll never get out alive.



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

Re: stuck on git (again)

[Michael Cronenworth]

Neal Becker wrote:
> git config --global push.default tracking
> seems to have fixed things.  (Still don't know what this magic means)

Git can push to one or many branches. You have to specify which branch 
to push - it can't read your mind. :)

Without that config option you need:

$ git push f13/master

With that config option:

$ git push

Defaults to whatever branch you are currently tracking.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: a note on order of arguements to systemctl command

[Matthew Miller]

On Wed, Aug 25, 2010 at 08:41:52AM -0500, David Smith wrote:
> > I'm still trying to work out how to get systemctl to boot
> > my netbook into run level 5. The usual way of changing this
> > seems to have no effect and that is a problem.

RFE to make it a feature of systemctl:


At a minimum, this should be explained in a comment in a "dummy" inittab
file. But I'm still holding out hope for implementation of
backwards-compatibility for initdefault:



-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: stuck on git (again)

[Michael Cronenworth]

Neal Becker wrote:
> But all I did was update the spec file (and did new sources), so how is that
> 10 commits?

$ git log
Check out who has been committing?

You might also find the gitk tool (or other equivalents found in the 
Fedora repos) useful for visualizing the history.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: stuck on git (again)

[Neal Becker]

Michael Cronenworth wrote:

> Neal Becker wrote:
>> No idea what this means.
> 
> It means it has been 10 commits since you have pushed ("synced") with
> the git repo living on pkgs.fedoraproject.org. Remember that you have
> your own unique git repository living on your local system.

But all I did was update the spec file (and did new sources), so how is that 
10 commits?

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Jakub Jelinek]

On Wed, Aug 25, 2010 at 04:08:49PM +0200, Lennart Poettering wrote:
> On Wed, 25.08.10 03:03, Miloslav Trmač (m...@volny.cz) wrote:
> > The traditional solution is to reexec not on shutdown, but immediately
> > after init upgrade (which also frees the inodes early); this can still
> > race with shutdown in theory, but is probably good enough in practice.
> 
> Well, while reexecing on package upgrades might kinda help fix the issue
> I think it doesn't really scale, because you'd have to reexec systemd
> when any of the libs it uses is upgraded, i.e. glibc, audit, selinux,
> tcpwrap, pam, libcap.

glibc %post (and prelink cron scripts) already telinit u when libc/ld.so
(resp. any library) changes.

> So I guess there's isn't really any other option then reexecing init in
> some way on shutdown.

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

Re: stuck on git (again)

[Michael Cronenworth]

Neal Becker wrote:
> No idea what this means.

It means it has been 10 commits since you have pushed ("synced") with 
the git repo living on pkgs.fedoraproject.org. Remember that you have 
your own unique git repository living on your local system.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: stuck on git (again)

[Neal Becker]

Till Maas wrote:

> On Wed, Aug 25, 2010 at 03:57:31PM +0200, Andreas Schwab wrote:
>> Till Maas  writes:
>> 
>> > git config  --add push.default tracking
>> 
>> push.default can only have one value, so --add does not make sense.
> 
> Ok, I adjusted it here:
> https://fedoraproject.org/wiki/Using_Fedora_GIT
> 
> Regards
> Till
git config --global push.default tracking
seems to have fixed things.  (Still don't know what this magic means)

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

Re: stuck on git (again)

[Neal Becker]

Andreas Schwab wrote:

> Neal Becker  writes:
> 
>> $ fedpkg push
>> Everything up-to-date
>> $ fedpkg build
>> Could not initiate build: There are unpushed changes in your repo
>>
>> Clue?
> 
> $ git status
> 
> Andreas.
> 
 git status
# On branch f13
# Your branch is ahead of 'origin/f13/master' by 10 commits.
#
nothing to commit (working directory clean)

No idea what this means.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Lennart Poettering]

On Wed, 25.08.10 03:03, Miloslav Trmač (m...@volny.cz) wrote:

> > > > > If the libraries or binaries used by systemd are replaced during 
> > > > > runtime,
> > > > > and it is not re-executed on shutdown, the filesystem will have busy 
> > > > > inodes
> > > > > on shutdown. (If you'd like to take the filesystem semantics up with 
> > > > > the
> > > > > kernel, feel free to tilt at that windmill.)
>  
> > Well, what me still puzzles is this: the reexec is done asynchronously,
> > via signals. Shouldn't this be done synchronously at least to make
> > sure the daemon really is reexec'ed when we try to remount r/o?
>
> The traditional solution is to reexec not on shutdown, but immediately
> after init upgrade (which also frees the inodes early); this can still
> race with shutdown in theory, but is probably good enough in practice.

Well, while reexecing on package upgrades might kinda help fix the issue
I think it doesn't really scale, because you'd have to reexec systemd
when any of the libs it uses is upgraded, i.e. glibc, audit, selinux,
tcpwrap, pam, libcap.

So I guess there's isn't really any other option then reexecing init in
some way on shutdown.

Lennart

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

Re: stuck on git (again)

[Till Maas]

On Wed, Aug 25, 2010 at 03:57:31PM +0200, Andreas Schwab wrote:
> Till Maas  writes:
> 
> > git config  --add push.default tracking
> 
> push.default can only have one value, so --add does not make sense.

Ok, I adjusted it here:
https://fedoraproject.org/wiki/Using_Fedora_GIT

Regards
Till


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

Re: stuck on git (again)

[Andreas Schwab]

Neal Becker  writes:

> $ fedpkg push
> Everything up-to-date
> $ fedpkg build
> Could not initiate build: There are unpushed changes in your repo
>
> Clue?

$ git status

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: stuck on git (again)

[Andreas Schwab]

Till Maas  writes:

> git config  --add push.default tracking

push.default can only have one value, so --add does not make sense.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: stuck on git (again)

[Neal Becker]

Neal Becker wrote:

> $ fedpkg push
> Everything up-to-date
> $ fedpkg build
> Could not initiate build: There are unpushed changes in your repo
> 
> Clue?
> 

Here's what I tried to do.
After clone, then build for F15 OK.

 git merge -m "Initial pseudo merge for dist-git setup" -s ours 
origin/{f12,f13}/master

OK, now try f13 branch:

 fedpkg switch-branch f13

I see my f13 files are not updated, so I do:

 git merge master
Updating 095f524..d2d9bec
Fast-forward
 .gitignore  |1 +
 Cython.spec |   11 ---
 sources |2 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

Now seems to be updated.

 git push
Counting objects: 1, done.
Writing objects: 100% (1/1), 259 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To ssh://nbec...@pkgs.fedoraproject.org/Cython
   793e85d..d2d9bec  master -> master

Then:

fedpkg build
Could not initiate build: There are unpushed changes in your repo

fedpkg push
Everything up-to-date


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

Re: stuck on git (again)

[Till Maas]

On Wed, Aug 25, 2010 at 09:39:09AM -0400, Neal Becker wrote:
> $ fedpkg push
> Everything up-to-date
> $ fedpkg build
> Could not initiate build: There are unpushed changes in your repo
> 
> Clue?

You might need to do this to get the push working:
git config  --add push.default tracking

Regards
Till


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

Re: stuck on git (again)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2010 09:39 AM, Neal Becker wrote:
> $ fedpkg push
> Everything up-to-date
> $ fedpkg build
> Could not initiate build: There are unpushed changes in your repo
> 
> Clue?
> 

Sounds like you have modified files in your checkout that aren't
committed and pushed to the master.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx1HoIACgkQeiVVYja6o6NdxACdGYQoTJhh5iTPrSo2C3eloQID
IiAAoIzfQF7NMyzNKMCFbf26T0uVX/d8
=dtSe
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: a note on order of arguements to systemctl command

[David Smith]

On 08/25/2010 01:39 AM, pbrobin...@gmail.com wrote:
> I'm still trying to work out how to get systemctl to boot
> my netbook into run level 5. The usual way of changing this
> seems to have no effect and that is a problem.

There's a new question/answer just added to the systemd FAQ that
explains this:


Q: How do I change the default runlevel to boot into?

A: The symlink /etc/systemd/system/default.target controls where we boot
into by default. Link it to the target unit of your choice. For example,
like this:

# ln -sf /lib/systemd/systemd/multi-user.target
/etc/systemd/system/default.target

or

# ln -sf /lib/systemd/systemd/graphical.target
/etc/systemd/system/default.target


-- 
David Smith
dsm...@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: drop default MTA for Fedora 15

[mike cloaked]

On Wed, Aug 25, 2010 at 10:32 AM, Till Maas  wrote:
> On Wed, Aug 25, 2010 at 10:20:44AM +0100, mike cloaked wrote:
>> On Wed, Aug 25, 2010 at 9:12 AM, drago01  wrote:
>>
>> >> It also takes up live image space, which is a very scarce resource, it's
>> >> always a fight to keep our live images within the size constraints.
>> >
>> > Which is fixable by admitting that we lost that fight and move to a
>> > modern medium that actually has space to provide a non crippled user
>> > experience. (not talking about MTAs here but in general).
>>
>> I wonder what fraction of users don't use DVD these days?
>
> Here, USB sticks are more common than DVD devices. Especially to install
> on notebooks or netbooks without an optical drive.

True - and I use the same! But some old machines won't boot off
usbkeys so I use both methods.

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

stuck on git (again)

[Neal Becker]

$ fedpkg push
Everything up-to-date
$ fedpkg build
Could not initiate build: There are unpushed changes in your repo

Clue?

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

Re: is it still possible to use upstart as the init-system in F-14?

[Lennart Poettering]

On Wed, 25.08.10 13:05, M A Young (m.a.yo...@durham.ac.uk) wrote:

> 
> On Wed, 25 Aug 2010, Peter Lemenkov wrote:
> 
> > I would like to know before trying/upgrading F-14 is it still possible
> > to use upstart instead of systemd in F-14?
> 
> Yes, upstart still works. I tried systemd and couldn't get it to work, so 
> I switched the machine back to upstart. You may need a rescue disk to make 
> the switch if your computer doesn't boot with systemd. I might try systemd 
> again when more of the bugs have been ironed out.

Bugzilla ids?

Lennart

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

Re: systemd or why will user fall away from fedora?

[Jon Masters]

On Wed, 2010-08-25 at 12:20 +0200, Christof Damian wrote:
> On Tue, Aug 24, 2010 at 23:06, Mike McGrath  wrote:
> > On Tue, 24 Aug 2010, Till Maas wrote:
> >> If they like a faster bootup, then yes, they will. And I as a
> >> workstation user like it.
> >>
> >
> > [citation needed]
> >
> > I asked for this and was told by developers they were reluctant to post
> > the data.
> 
> I also wonder who these people are who boot their computers so often
> that boot-up speed makes any difference over a whole day.

Must be a limited set of developers. Let's face it, the average user
doesn't reboot all that often if they're doing suspend/resume, etc.
Those doing kernel development/plumbing hopefully have a separate test
box that isn't running a lot anyway (so won't take long to boot).

My desktop uptime:

[...@constitution ~]$ uptime
 09:28:22 up 24 days, 16:32,  9 users,  load average: 1.17, 0.50, 0.37

So clearly I'm absolutely, desperately concerned with 30 seconds or 5
minutes of boot time and it would be devastating if it took longer...

Jon.


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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[drago01]

On Wed, Aug 25, 2010 at 3:27 PM, Matthias Clasen  wrote:
> On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote:
>
>> > I'm going to be blunt. I DON'T CARE.
>>
>> Yay, thanks that you don't care. You are aware that by putting
>> everything on a single man's shoulders and then telling him "you don't
>> care" you make him feel really welcome and make him wonder why he
>> even bothers with this shit?
>>
>> > Sure, I suppose individual maintainers want to push their code over the 
>> > wall and
>> > then sit in their silo and claim 'that's not my problem' and 'someone else
>> > needs to fix that', well, that's their right to be lame. But we, as Fedora,
>> > as producers of a product that we ship to our users, don't have that 
>> > luxury.
>>
>> But you enable them to block out change. For example, if somebody
>> refuses to merge a patch that adds a systemd equivalent for an upstart
>> config hook he has, he can sink the whole systemd in fedora project. I
>> am pretty sure some folks would be really happy to have that power...
>
> Hey, lets not get carried away here. It is pretty clear that Bills list
> of checkpoints for init / boot functionality covered not just systemd,
> but plymouth, gdm, initscripts, kernel, dracut, and a bunch of other
> early userspace packages. I'm sure the maintainers of those packages
> will be willing to help with making the init / boot experience of Fedora
> 14 great.
>
> To my knowledge, this is the first time we've ever looked at codifying
> what behaviours we expect in this area (why didn't we do this exercise
> for upstart ?). It is very useful, and if nothing else, this is already
> a very useful outcome of  the systemd adventure.

Indeed, imo we should add them to the release criteria.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd and changes

[Matthias Clasen]

On Tue, 2010-08-24 at 19:32 -0400, Matthew Miller wrote:
> On Wed, Aug 25, 2010 at 01:29:20AM +0200, Lennart Poettering wrote:
> > Note that I have now changed git upstream to preferably return 3 or 5 if
> > multiple different answers would make sense. This should avoid most
> > problems with scripts doing "if [ `runlevel` = 3 ] ; then", even if
> > that's a kinda broken thing to do. Since runlevels 3 and 5 are the ones
> > anaconda writes this should be the safest bet.
> 
> For the record, I agree that those scripts are probably horrible old
> kludges. It's just nice when we can not break those. So, again, thanks for
> reponsiveness on this, Lennart.

Hey Matt, I'd like to thank you for staying constructive and friendly in
these heated debates, that is really great.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Matthias Clasen]

On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote:

> > I'm going to be blunt. I DON'T CARE.
> 
> Yay, thanks that you don't care. You are aware that by putting
> everything on a single man's shoulders and then telling him "you don't
> care" you make him feel really welcome and make him wonder why he
> even bothers with this shit?
> 
> > Sure, I suppose individual maintainers want to push their code over the 
> > wall and
> > then sit in their silo and claim 'that's not my problem' and 'someone else
> > needs to fix that', well, that's their right to be lame. But we, as Fedora,
> > as producers of a product that we ship to our users, don't have that luxury.
> 
> But you enable them to block out change. For example, if somebody
> refuses to merge a patch that adds a systemd equivalent for an upstart
> config hook he has, he can sink the whole systemd in fedora project. I
> am pretty sure some folks would be really happy to have that power...

Hey, lets not get carried away here. It is pretty clear that Bills list
of checkpoints for init / boot functionality covered not just systemd,
but plymouth, gdm, initscripts, kernel, dracut, and a bunch of other
early userspace packages. I'm sure the maintainers of those packages
will be willing to help with making the init / boot experience of Fedora
14 great.

To my knowledge, this is the first time we've ever looked at codifying
what behaviours we expect in this area (why didn't we do this exercise
for upstart ?). It is very useful, and if nothing else, this is already
a very useful outcome of  the systemd adventure.


Matthias

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

Re: systemd or why will user fall away from fedora?

[Nathaniel McCallum]

On 08/25/2010 06:20 AM, Christof Damian wrote:
> On Tue, Aug 24, 2010 at 23:06, Mike McGrath  wrote:
>> On Tue, 24 Aug 2010, Till Maas wrote:
>>> If they like a faster bootup, then yes, they will. And I as a
>>> workstation user like it.
>>>
>>
>> [citation needed]
>>
>> I asked for this and was told by developers they were reluctant to post
>> the data.
> 
> I also wonder who these people are who boot their computers so often
> that boot-up speed makes any difference over a whole day.

I reboot my computer ~5-10 times a day due to this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=625187

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

Re: is it still possible to use upstart as the init-system in F-14?

[Rahul Sundaram]

 On 08/25/2010 05:35 PM, M A Young wrote:
> On Wed, 25 Aug 2010, Peter Lemenkov wrote:
>
>> I would like to know before trying/upgrading F-14 is it still possible
>> to use upstart instead of systemd in F-14?
> Yes, upstart still works. I tried systemd and couldn't get it to work, so 
> I switched the machine back to upstart. You may need a rescue disk to make 
> the switch if your computer doesn't boot with systemd. I might try systemd 
> again when more of the bugs have been ironed out.
Do you have any unreported bugs?

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

Re: systemd and changes

[Till Maas]

On Tue, Aug 24, 2010 at 02:33:25PM -0700, Jesse Keating wrote:
> On 8/24/10 2:13 PM, Till Maas wrote:
> > On Tue, Aug 24, 2010 at 01:15:54PM -0700, Jesse Keating wrote:
> > 
> >> Because generally whats on the mainboard (or in the laptop) works.  If
> >> it didn't work, the first reaction isn't "Oh I need to go buy a better
> >> one" it's "why the heck can't linux work with this, is linux still a
> >> piece of crap?".  Replacing the soundcard in a laptop is even more tricky.
> > 
> > People thinking that "linux is still a piece of crap" are usually not
> > that active in the FOSS development. And the first lesson I learned when
> > I started using linux was to buy hardware after checking that it is
> > compatible with linux. And this is usually followed by everyone I know
> > personally who is using linux. Do you really buy new hardware without
> > checking its compatibility with linux first?
> 
> Video and wifi I check into.  Other than that I expect everything else
> to just work.

Then I guess you are lucky or do not use certain type of hardware. I
would check every bit of hardware, e.g. the onboard NIC (I know in the
past there have been issues with atheros or nvidia(?) devices not
directly working), the webcam (if I wanted one), USB3 (afaik there are
already boards providing it). Even for hard disks it is somehow
necessary, because of 4k sector hard disks, which were not properly
supported when the hit the market. Then for notebooks there are special
keys, that might not work, a fingerprint sensor, integrated modem and
umts device. And then there are even normal keyboards with special keys
that might not work. And there are also peripherals like printers or
scanners. I even came across a USB-serial adapter that does not work
with linux. I am not sure, but I believe that using different CPU speeds
did not work directly in linux, too. And probably PAE, too. So any
component may not directly work in linux and this is something that one
has to expect using linux as long as hardware vendors do not provide
drivers for linux before they push the device on the market. And
soundcards tend to be a less stable component, since there are lots of
different chipsets.

> > And do you use your soundcard in a way that you benefit from the
> > Pulseaudio features?
> > 
> 
> I can't really answer that because I don't really know what the features
> are over what we had previously.  I like for my applications to be able
> to use my soundcard all at the same time, which I had issues with before
> pulse, but that was on previous hardware as well.

This is the one feature that was available by buying a good soundcard.
And this does not mean a high-end one, but not a random one.

Regards
Till


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

Re: drop default MTA for Fedora 15

[Ralf Corsepius]

On 08/25/2010 03:05 PM, Andreas Schwab wrote:
> Ralf Corsepius  writes:
>
>> On 08/25/2010 09:08 AM, Kevin Kofler wrote:
>>> Chris Adams wrote:
 How many users use "at" or "bc" (well, I use "dc" all the time)?
>>>
>>> Well, at least "at" is a nice command and some people use it, but…
>>>
 What about "ed"?
>>>
>>> … it's time we drop such legacy junk!
>>
>> What you offend as "legacy junk" is mandated by POSIX:
>
> POSIX mandates a lot of legacy junk.

No disagreement, ed has outlived itself, but "standards" are around for 
reasons ... e.g. to have a reliable foundation for other stuff.

Besides this, I can't find arguing against a 50k application in the 
light of the 100's of MB of "hardly functional, but modern kiddy junk" 
Fedora is loaded with, to be laughable.

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

Re: drop default MTA for Fedora 15

[Andreas Schwab]

Ralf Corsepius  writes:

> On 08/25/2010 09:08 AM, Kevin Kofler wrote:
>> Chris Adams wrote:
>>> How many users use "at" or "bc" (well, I use "dc" all the time)?
>>
>> Well, at least "at" is a nice command and some people use it, but…
>>
>>> What about "ed"?
>>
>> … it's time we drop such legacy junk!
>
> What you offend as "legacy junk" is mandated by POSIX:

POSIX mandates a lot of legacy junk.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: is it still possible to use upstart as the init-system in F-14?

[Peter Lemenkov]

2010/8/25 Dennis Gilmore :

> appending init=/sbin/upstart  to your boot line will get you booting using
> upstart.

Thanks for the tip!

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: is it still possible to use upstart as the init-system in F-14?

[Dennis Gilmore]

On Wednesday, August 25, 2010 07:05:06 am M A Young wrote:
> On Wed, 25 Aug 2010, Peter Lemenkov wrote:
> > I would like to know before trying/upgrading F-14 is it still possible
> > to use upstart instead of systemd in F-14?
> 
> Yes, upstart still works. I tried systemd and couldn't get it to work, so
> I switched the machine back to upstart. You may need a rescue disk to make
> the switch if your computer doesn't boot with systemd. I might try systemd
> again when more of the bugs have been ironed out.
> 
>   Michael Young
appending init=/sbin/upstart  to your boot line will get you booting using 
upstart.

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: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Matthew Miller]

On Wed, Aug 25, 2010 at 02:05:01PM +0200, Jan Safranek wrote:
> > bug number?
> https://bugzilla.redhat.com/show_bug.cgi?id=626794

thanks.

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: drop default MTA for Fedora 15

[Ralf Corsepius]

On 08/25/2010 09:08 AM, Kevin Kofler wrote:
> Chris Adams wrote:
>> How many users use "at" or "bc" (well, I use "dc" all the time)?
>
> Well, at least "at" is a nice command and some people use it, but…
>
>> What about "ed"?
>
> … it's time we drop such legacy junk!

What you offend as "legacy junk" is mandated by POSIX:
http://www.opengroup.org/onlinepubs/9699919799/utilities/ed.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: is it still possible to use upstart as the init-system in F-14?

[M A Young]

On Wed, 25 Aug 2010, Peter Lemenkov wrote:

> I would like to know before trying/upgrading F-14 is it still possible
> to use upstart instead of systemd in F-14?

Yes, upstart still works. I tried systemd and couldn't get it to work, so 
I switched the machine back to upstart. You may need a rescue disk to make 
the switch if your computer doesn't boot with systemd. I might try systemd 
again when more of the bugs have been ironed out.

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

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Jan Safranek]

On 08/25/2010 01:59 PM, Matthew Miller wrote:
> On Wed, Aug 25, 2010 at 12:58:26PM +0200, Jan Safranek wrote:
>> It should also mount nothing else unless it is absolutely necessary for
>> systemd! Currently systemd mounts all control groups controllers
>> (/cgroup/cpu, /cgroup/cpuset, /cgroup/cpuacct, ...), which breaks libcgroup.
>
> bug number?

https://bugzilla.redhat.com/show_bug.cgi?id=626794
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: drop default MTA for Fedora 15

[Matthew Miller]

On Wed, Aug 25, 2010 at 09:08:22AM +0200, Kevin Kofler wrote:
> > What about "ed"?
> … it's time we drop such legacy junk! Scripts are all written to sed (or 
> something entirely different, like awk or perl) these days, and nobody 
> seriously uses ed for interactive editing (there are tons of more usable 
> text editors around). Sure, we can keep "ed" in the repository, but I don't 
> see why we install it by default.

It is very convenient for blind users with a line-based braille terminal. Do
we ship accessibility tools for Gnome by default? If so, I think we can
afford to ship poor little ed.

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Matthew Miller]

On Wed, Aug 25, 2010 at 12:58:26PM +0200, Jan Safranek wrote:
> It should also mount nothing else unless it is absolutely necessary for 
> systemd! Currently systemd mounts all control groups controllers 
> (/cgroup/cpu, /cgroup/cpuset, /cgroup/cpuacct, ...), which breaks libcgroup.

bug number?

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20100825 changes

[Rawhide Report]

Compose started at Wed Aug 25 08:15:34 UTC 2010

Broken deps for x86_64
--
OpenSceneGraph-libs-2.8.3-2.fc14.i686 requires libpoppler.so.6
OpenSceneGraph-libs-2.8.3-2.fc14.x86_64 requires 
libpoppler.so.6()(64bit)
PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so
PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit)
RackTables-0.18.3-1.fc15.noarch requires /usr/local/bin/php
RackTables-0.18.3-1.fc15.noarch requires perl(File::FnMatch)
RackTables-0.18.3-1.fc15.noarch requires perl(Net::Telnet::Cisco)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10
cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
cinepaint-0.22.1-17.fc14.x86_64 requires liboyranos.so.0.1.9()(64bit)
cinepaint-libs-0.22.1-17.fc14.i686 requires liboyranos.so.0.1.9
cinepaint-libs-0.22.1-17.fc14.x86_64 requires 
liboyranos.so.0.1.9()(64bit)
cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
dpm-python3-1.7.4.7-3.fc14.x86_64 requires python(abi) = 0:3.1
dpm-python3-1.7.4.7-3.fc14.x86_64 requires libpython3.1.so.1.0()(64bit)
emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit)
fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10
fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
gedit-vala-0.6.1-1.fc13.x86_64 requires libvala.so.0()(64bit)
gloobus-preview-0.4.1-6.fc14.x86_64 requires libpoppler.so.6()(64bit)
3:gnome-commander-1.2.8.7-1.fc14.x86_64 requires 
libpoppler.so.6()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
inkscape-0.48-0.4.20100505bzr.fc14.x86_64 requires 
libpoppler.so.6()(64bit)
inkscape-view-0.48-0.4.20100505bzr.fc14.x86_64 requires 
libpoppler.so.6()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
lfc-python3-1.7.4.7-3.fc14.x86_64 requires libpython3.1.so.1.0()(64bit)
lfc-python3-1.7.4.7-3.fc14.x86_64 requires python(abi) = 0:3.1
libextractor-plugins-pdf-0.6.1-1402.fc14.x86_64 requires 
libpoppler.so.6()(64bit)
libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10
libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit)
libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10
libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10
libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10
libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit)
libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.i686 requires 
libboost_filesystem-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libselinux-python3-2.0.96-3.fc14.x86_64 requires python(abi) = 0:3.1
libsemanage-python3-2.0.45-5.fc14.x86_64 requires 
libpython3.1.so.1.0()(64bit)
libsemanage-python3-2.0.45-5.fc14.x86_64 requires python(abi) = 0:3.1
libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10
libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.1

Re: drop default MTA for Fedora 15

[Emmanuel Seyman]

* mike cloaked [25/08/2010 12:27] :
>
> I wonder what fraction of users don't use DVD these days?

I've switched to PXE-based installs. Haven't used a DVD/CD in ages.

Emmanuel

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

Re: systemd and changes

[Till Maas]

On Wed, Aug 25, 2010 at 05:25:17AM +0200, Kevin Kofler wrote:
> Matthew Miller wrote:
> > When there's a compelling use case for NetworkManager on machines that
> > don't move around?
> 
> The "compelling use case" is that it doesn't make sense to maintain 2 pieces 
> of core infrastructure code doing the same thing, especially when one's 
> functionality is a subset of the other's. (Now the problem is that it still 
> isn't, which I hadn't been aware of before this discussion, hopefully the 
> missing stuff like bridging will get added to NM soon, and hopefully there 
> won't be another missing piece "everyone" will be complaining about (before, 
> it was systemwide settings, static IPs and IPv6, those are all implemented 
> now AFAIK).)

Does it support setting "ip rule" commands if an interface is up?
http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html
Did not show this. And it seems not to be able to create tun or tap
devices, which requires only a small ifup-tun script with the old
system.

> And FWIW, strictly speaking, there's a compelling use case for NM on a 
> machine that doesn't move around: If the network plug is in another room and 
> you don't want to extend a 20m cable through 2+ doors, you have to use 
> wireless networking. If you want to use something secure, you cannot rely on 
> unencrypted wireless or WEP, you have to use WPA (or WPA2) with AES/CCMP 
> (warning: TKIP is also insecure!). But the old network service does not 
> support WPA. You either have to apply an unofficial patch (which was never 

With the old network service it was still possible to manually use
iwconfig and wpa-supplicant and therefore WPA. Or to create a OpenVPN
tunnel, which I would prefer more than using WPA in terms of security.
But with NetworkManager running, the command line tools usually do not
work as expected.

Regards
Till


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

[Bug 627192] New: Padre-0.32 requires newer Thread::Queue

[bugzilla]

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

Summary: Padre-0.32 requires newer Thread::Queue

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

   Summary: Padre-0.32 requires newer Thread::Queue
   Product: Fedora
   Version: 12
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: medium
  Priority: low
 Component: perl-Padre
AssignedTo: mmasl...@redhat.com
ReportedBy: ppi...@redhat.com
 QAContact: extras...@fedoraproject.org
CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com
Classification: Fedora
Target Release: ---


When exiting padre from perl-Padre-0.32-3, I get error message:

Can't locate object method "insert" via package "Thread::Queue" at
/usr/lib/perl5/vendor_perl/5.10.0/Padre/TaskManager.pm line 358.
Perl exited with active threads:
1 running and unjoined
0 finished and unjoined
0 running and detached

This leads to unclean padre termination.

Current Thread::Queue-2.00 version (perl-5.10.0-91.fc12.x86_64 package) does
not provide the `insert' method.

According META.yml from padre sources, Thread::Queue >= 2.11 is needed.

-- 
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: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Jan Safranek]

On 08/24/2010 05:06 AM, Bill Nottingham wrote:
> GENERAL SANITY
> - Booting a system shall achieve a similar result as booting in upstart:
> -- The same set of services will be started.
> -- The services shall function the same.
> -- The same set of devices and filesystems shall be mounted.
> -- The same set of devices and filesystems shall be fscked.

It should also mount nothing else unless it is absolutely necessary for 
systemd! Currently systemd mounts all control groups controllers 
(/cgroup/cpu, /cgroup/cpuset, /cgroup/cpuacct, ...), which breaks libcgroup.


Jan

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

Re: drop default MTA for Fedora 15

[Rudolf Kastl]

2010/8/24 pbrobin...@gmail.com :
> On Tue, Aug 24, 2010 at 9:36 AM, Rudolf Kastl  wrote:
>> my desktop runs on software mirror raid below an lvm. not for
>> performance but for data recovery reasons. mdmonitor does mail
>> notification. will this be fixed? how about logwatch, it is really
>> useful to have to get an overview what happened on the system in a
>> neat summary. also handy for desktops but just not recognized and
>> presented in an end user compatible way. just my opinion.
>
> Neither of those need to run a MTA locally to work, you just need to
> point them to a mail server, even then they need to be configured to
> send the mail to something other than root anyway. Removing the
> default MTA won't change these out of the box and if you still want to
> run a local MTA its as simple as selecting it during install. I use
> all of the above on dozens of servers and none of them run a mail
> server locally.

well yeah i am well aware of that and yup i can set that up i am just
curious if i am the only one that prefers to have local delivery
available for that kinda setups. i agree that local root notification
isnt helpful for a datacenter. i also agree that /etc/aliases has to
be adjusted for making the logwatch stuff for end users useful and the
user would also need to have the default mail client preconfigured to
have any out of the box use for it. but if you have a
desktop/workstation that is standalone there is no such thing as an
external mail server for raid failure notifications that makes any
sense. i mean do you want to be dependent on a working networking to
be notified of raid failures in an obvious way? i am not argueing for
keeping the default mta necasserily, but as a user id expect that if i
select raid setup in a clicky installer that the system is
preconfigured in a by default useful manner. that includes obvious
ways for notifying me about raid failure. the current functionality of
mdmonitor requires an email address to be set. maybe for that kinda
stuff using our desktop notification system would be something useable
(if you want to discuss that please open a seperate thread though... i
dont wanna hijack this one).



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

Re: git rebase OK on Fedora git branches?

[Stanislav Ochotnicky]

Excerpts from Daniel P. Berrange's message of Wed Aug 25 11:08:16 +0200 2010:
> On Tue, Aug 24, 2010 at 11:34:36AM -0700, Jesse Keating wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On 8/24/10 6:43 AM, Richard W.M. Jones wrote:
> > > Is it OK to use 'git rebase -i' to compress my mistakes together into
> > > a single working Fedora git commit?  (Provided I don't push things in
> > > between or otherwise try to rewrite public history)
> > > 
> > > I'm a bit confused by whether 'fedpkg commit', 'fedpkg build', 'fedpkg
> > > push' etc are doing magic that will be broken by this.
> > > 
> > > Rich.
> > > 
> > 
> > You are free to do any sort of history altering actions you want prior
> > to a push.  fedpkg will prevent you from trying to build something that
> > hasn't been pushed unless you're doing a scratch build.  commit and push
> > are very thin wrappers over the git equivs.
> 
> Is there a server side hook/check to prevent accidentally pushing
> non-fastforward commits ?

Standard git repositories deny pushing non fast-forward commits unless
you --force the push. So yes I guess there is protection, I haven't
tried if --force is allowed or not (I guess it should not be on allowed
on standard branches)

-- 
Stanislav Ochotnicky 
Associate Software Engineer - Base Operating Systems Brno

PGP: 71A1677C
Red Hat Inc.   http://cz.redhat.com


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

is it still possible to use upstart as the init-system in F-14?

[Peter Lemenkov]

Hello All!

I would like to know before trying/upgrading F-14 is it still possible
to use upstart instead of systemd in F-14?

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [setroubleshoot] - Rebuild for python-2.7

[Jochen Schmitt]

 Am 25.08.2010 12:10,chrieb Michael Schwendt:
>
> And apart from that, the setroubleshoot version in F-14 is newer. Why
> not sync the changes?

Thank you for your comments. I have double check the situation and find
out that you
have right with your explaination, so I have to sync the rawhide version
with that on F-14

Best Regards:

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

Re: systemd or why will user fall away from fedora?

[drago01]

On Tue, Aug 24, 2010 at 11:06 PM, Mike McGrath  wrote:
> On Tue, 24 Aug 2010, Till Maas wrote:
>
>> On Tue, Aug 24, 2010 at 10:46:41PM +0200, Farkas Levente wrote:
>>
>> > for workstation most users already use ubuntu. why? because it's more
>> > user friendly.
>>
>> There is nothing wrong with using Ubuntu, if it servers their needs.
>>
>> > do you think workstation users will like this kind of changes?
>>
>> If they like a faster bootup, then yes, they will. And I as a
>> workstation user like it.
>>
>
> [citation needed]
>
> I asked for this and was told by developers they were reluctant to post
> the data.

http://lwn.net/Articles/401441/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd or why will user fall away from fedora?

[Christof Damian]

On Tue, Aug 24, 2010 at 23:06, Mike McGrath  wrote:
> On Tue, 24 Aug 2010, Till Maas wrote:
>> If they like a faster bootup, then yes, they will. And I as a
>> workstation user like it.
>>
>
> [citation needed]
>
> I asked for this and was told by developers they were reluctant to post
> the data.

I also wonder who these people are who boot their computers so often
that boot-up speed makes any difference over a whole day.

I like the on-demand service features of systemd though. I just hate
that Fedora will be a different beast from any other Linux for the
foreseeable future.

It will also be interesting to see what this will mean in relation to
RHEL, because one of the reasons I use Fedora is that I can transfer
stuff I learn and use on Fedora to RHEL/CentOS. If they are very
different I can as well choose one SuSe (if I want to stick with RPM
at least).

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