rfc: give koji diff capabilities
by Development discussions related to Fedora
Probably thought of a million times, but was wondering whether it would
be possible, and useful to give diff capabilities within the koji web
interface.
eg: x86_64 build
...
Output build.log (tail)
root.log (tail)
state.log (tail)
could become:
Output build.log (tail) (diff)
root.log (tail) (diff)
state.log (tail) (diff)
hovering over diff would cause a (json) load of options:
- diff -u with other arch:
i686, ppc, ppc64
- diff -u with other version:
list other builds in this release (eg devel): 4.3-1, 4.3-4,
- diff -u with other release:
list other releases of same version that have been built: f12, f13
The diff could be generated to look like a viewvc side by side diff.
Bonus points if the diff ignores things like:
- tmp file names (/var/tmp/rpm-tmp.trZK8P)
- log address: 0x2b9c82662f90
- builder: x86-05.phx2.fedoraproject.org
Previously, I found the build logs rather boring; by saving each
locally, then running meld on them, I immediately see what has changed
between eg F12 and devel.
Any comments (other than 'show me the money/code') ?
13 years, 11 months
Feature, Fedora 14: Go Programming
by Brandon Lozza
Hi,
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
privileges).
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
features.
13 years, 11 months
Evolution update in F13
by Jesse Keating
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
- --
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/
iEYEARECAAYFAkwlO0cACgkQ4v2HLvE71NXVxwCfS59qPC/vUPT1rEIMrhMRijDL
C9gAnj8FKdjdPHqL4lZPFWiAMKWsEXma
=OHPB
-----END PGP SIGNATURE-----
13 years, 11 months
How to lure me to updates-testing
by Nathanael D. Noblet
Hello,
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.
#3) Reminders
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
13 years, 11 months
libjpeg-turbo conflicts in rawhide
by Rich Mattes
Hi all,
I'm trying to build a package that has a BuildRequires: libjpeg-devel in
Rawhide [1]. 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?
Thanks,
Rich
[1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066
13 years, 11 months
my EPEL-6 packages up for takers
by Patrice Dumas
Hello,
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:
acpitool
asa
bibexport
BibTool
bitmap
boolstuff
cernlib
cernlib-g77
cppunit
dap-freeform_handler
dap-hdf4_handler
dap-netcdf_handler
dap-server
docbook2X
elektra
esmtp
flasm
g2clib
gnochm
gpicview
grads
halevt
html2ps
kchmviewer
libdap
libdockapp
libesmtp
libnc-dap
libsx
ooo2txt
pam_ssh
perl-Algorithm-CurveFit
perl-Cache
perl-Feed-Find
perl-File-BaseDir
perl-File-DesktopEntry
perl-File-MimeInfo
perl-File-NFSLock
perl-Heap
perl-HTML-FormatText-WithLinks
perl-LWP-Authen-Wsse
perl-Math-MatrixReal
perl-Math-Symbolic
perl-Module-Signature
perl-Parse-Yapp
perl-Statistics-Descriptive
perl-Test-Distribution
perl-Text-CHM
perl-Text-Unidecode
pmount
ps2eps
python-chm
tetex-elsevier
tetex-tex4ht
uread
wdm
wmacpi
wmix
xbae
xchm
xdialog
--
Pat
13 years, 11 months
Proposed release criteria additions for F14+
by Adam Williamson
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
13 years, 11 months
Feature Request: nsupdate-gss
by Trever L. Adams
Hello,
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.
Trever
13 years, 11 months
