I'd like to recommend a Go compiler be included with Fedora 14. We
would have two options:
1) GCC-GO (Included in GCC 4.5?)
2) Google's Go Compiler. (One is made by Conrad Meyer, he mentioned it
wouldn't be too easy to add because goinstall basically wants root
Benefits to Fedora
A garbage collected *compiled* language which aims to be as fast as C.
The applications it compiles doesn't require a runtime present to
work. It's comparable to Java and C# but with a lot of Python-like
The page "Package Change Requests for existing packages" is unclear:
Please expand on what "explanatory text" you want in addition to the
"Package Change Request" template. If there is a branch request, e.g. for
a released dist version, is it necessary to transcribe the filled out
template into a full sentence?
-----BEGIN PGP SIGNED MESSAGE-----
Can anybody tell me what went wrong with this update? It was submitted
at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was
submitted for stable two hours later. Between that submission and the
push to stable (push to stable happened at 18:09 on 06-25) numerous
negative karma came in due to broken deps. The update went out anyway,
and now we have a mess of broken updates on a critical path package, and
have to scramble to fix it with more updates, on a Friday.
Can anybody help me understand the scenario here? Should we start
filtering out push requests that have more than -2 karma?
Fedora -- Freedom² is a feature!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I've been watching the discussion in the bodhi thread. As a long time fedora / redhat system user (since 0.5.1). Recently I've been getting myself involved in the community, packaging and what not. I have watched the discussions related to testing for the last few releases. I administer a number of Fedora systems, and I have a few friends that have since started using linux as their main OS. I would *love* to help more by providing feedback on updates-testing releases, I also know that my less experienced friends are would be willing to participate with a few issues resolved to help them out. Here are the deficiencies as I see them (which honestly could be a matter of not knowing).
#1) Easy way to know where a package came from.
For example, as far as I am aware, I cannot query anything that tells me X packages are from Y repo. If I were to become a 100% always enabled updates-testing, most of my packages would be from that repo, however if I only do it occasionally I'd just have to remember
#2 ) Easy way to downgrade if I were to run into problems
I understand that this isn't foolproof, and that for some issues (some huge glibc error) my system could conceivably require advanced knowledge to boot into a rescue mode, download packages and force the downgrade. However some way to view the updates-testing packages I have installed, and downgrade to the 'released' version would be awesome.
Knowing which packages I have installed that I have yet to provide karma for. Nothing too insane as I know that if updates-testing was installed and I always installed everything from it, there are lots of packages I couldn't really know if they worked or had regressions. So alongside this feature would be a way to have a whitelist or blacklist of packages I want to test or ignore.
#4) Easy way to update the karma on packages I've installed
I've heard of fedora-easy-karma, and it likely does what I want, but I think it needs to be integrated into a complete tool that includes # 1 & 2.
#5) Easy way to turn on/off my willingness to use updates-testing.
Sometimes I could be busy and only want tested updates, it would be nice if this imaginary tool I'm describing allowed me to say I'm done testing for now, and it deals with disabling the repo and any reminders. If there was some nice tool to deal with updates-testing enabling and the inclusion/exclusion of packages I wanted to test and all that I laid out I would be on it in a second, and I'm guessing you'd have even more testers.
One more clarifying point. I am *not* complaining about the current situation, I know there are limited resources. I agree with the critpath updates policy for the most part. I agree the quality of the packages needs to remain high and that part of that is autoqa, testers and maintainers doing their jobs. I also realize that if I had the skills and time I could write this tool. This is not a demand or complaint. I just wanted to illustrate from my point of view what would make using updates-testing a *lot* easier for me. It is quite possible everything I've outlined is already doable, if so then the last thing is I guess an easy way for people like me to know about it so we can use it.
Just my thoughts,
Nathanael d. Noblet
I'm trying to build a package that has a BuildRequires: libjpeg-devel in
Rawhide . I get a message in root.log that libjpeg-turbo-devel
obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead.
Unfortunately, when it pulls in dependencies for my other BuildRequires,
it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict
since they both provide libjpeg.so.62.0.0
The only thing I can think of is that one of the packages I'm requiring
has an explicit dep on libjpeg (I'm about to investigate which). For
the time being, is there any to work around this?
I won't, at least for now, maintain the packages I maintain in EPEL-5 in
EPEL-6. I have added a nobranch file in all of them. If you want to take up
the package, you can. It is still unclear to me how to practically ensure
that you become the EPEL-6 branch owner, instead of me, though. Hopefully
this will be sorted out.
If you want to maintain the EL-5 (or even EL-4) branch too, don't
hesitate, the less package I maintain the better I am.
I think that wdm should not be maintained in EL-6 anyway, since upstream
is dead and there is no ConsoleKit integration.
For the dap-* packages it maybe worth waiting for a stabilisation of
the ABI, and maybe integration with bes and packaging of olfs to have a
working hyrax server before branching. My guess is that there are no
users of these packages anyway. Also maybe the opendap implementantion
in netcdf itself could be used instead of libdap/libnc-dap.
The list is:
Sorry for the cross-post, but figured it's worth CCing devel in case
anyone has concerns on these.
I'm currently working on a plan to expand desktop validation testing. As
part of the discussion around this, Christoph Wickert proposed several
additions to the release criteria that seem sensible to me. I'd like to
propose we add these to the criteria for F14 and on:
* Saving passwords in the desktop default keyring (if the desktop
implements one), and retrieving passwords from the keyring, must work
* The desktop default update manager must not periodically check for
updates when the system is booted live, but must periodically check for
updates when running on an installed system
* The desktop's offered mechanisms for shutting down, logging out and
rebooting must work
Anyone have comments or objections to these? Suggestions for what
release they should come in? I'd say #1 should be final and #2 and #3
should be beta, off the top of my head.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
I am wondering if someone would be willing to package
http://samba.org/~tridge/junkcode/tsig-gss/ and maybe work with the
ddclient people to add support for adding A and AAAA records with this.
(I do not know if bind shipped in Fedora has the tsig updates or not,
but it should.) If possible, can this be modified to do reverse DNS
setup as well and have ddclient do that setup as well?
I have attached my beginning of a spec file. I cannot tell you if it is
any good or not.
Thank you for whoever is willing to pick this up.
Hi, due to a shift in requirements and time constrains I just orphanned
or am about to orphan the following:
About to orphan in a couple of days:
rubygem-bacon -- A ruby-based testing framework
rubygem-configuration -- Pure Ruby scoped configuration files
rubygem-diff-lcs -- Provide a list of changes between two sequenced collections
rubygem-rack-test -- Simple testing API built on Rack
rubygem-syntax -- Ruby library for performing simple syntax highlighting
rubygem-test-spec -- Behaviour Driven Development interface for Test::Unit
rubygem-treetop -- A Ruby-based text parsing and interpretation DSL
Orhpaned, have other maintainers:
rubygem-cucumber -- Tool to execute plain-text documents as functional tests
rubygem-launchy -- Helper class for cross-platform launching of applications
rubygem-polyglot -- Allow hooking of language loaders for specified extensions into require
rubygem-rubigen -- A framework to allow Ruby applications to generate file/folder stubs
rubygem-shotgun -- Automatic reloading version of the rackup command
rubygem-sinatra -- Ruby-based web application framework
rubygem-term-ansicolor -- Ruby library that colors strings using ANSI escape sequences
If you wish to take over maintenance of those packages, please add
yourself to pkgdb. Thank you!
Flash is the Web2.0 version of blink and animated gifs.
-- Stephen Smoogen