mingw32 debuginfo packages without sources, build id
by Ville Skyttä
Hello,
I noticed a bunch of mingw32*-debuginfo packages that contain only *.debug (no
sources, no build id) appeared in Rawhide. Is this how mingw32 debuginfo
packages are supposed to look like, or is the infrastructure for creating the
debuginfo packages not quite complete, or are these packaging bugs?
mingw32-boost-debuginfo-1.39.0-2.fc12.noarch
mingw32-cairomm-debuginfo-1.8.0-3.fc12.noarch
mingw32-glib2-debuginfo-2.21.2-2.fc12.noarch
mingw32-glibmm24-debuginfo-2.20.0-4.fc12.noarch
mingw32-gtkmm24-debuginfo-2.16.0-2.fc12.noarch
mingw32-libglade2-debuginfo-2.6.4-3.fc12.noarch
mingw32-libglademm24-debuginfo-2.6.7-7.fc12.noarch
mingw32-libgnurx-debuginfo-2.5.1-5.fc12.noarch
mingw32-libsigc++20-debuginfo-2.2.2-8.fc12.noarch
mingw32-libsqlite3x-debuginfo-20071018-8.fc12.noarch
mingw32-libxml++-debuginfo-2.26.0-2.fc12.noarch
mingw32-pangomm-debuginfo-2.24.0-3.fc12.noarch
mingw32-plotmm-debuginfo-0.1.2-3.fc12.noarch
mingw32-qt-debuginfo-4.5.2-1.fc12.noarch
mingw32-qwt-debuginfo-5.1.1-8.fc12.noarch
mingw32-sqlite-debuginfo-3.6.14.2-1.fc12.noarch
mingw32-tcl-debuginfo-8.5.7-6.fc12.noarch
mingw32-wpcap-debuginfo-4.1.beta5-6.fc12.noarch
mingw32-zfstream-debuginfo-20041202-6.fc12.noarch
14 years, 9 months
Updates can't handle multiple bug #s?
by Jerry James
I just submitted this update:
https://admin.fedoraproject.org/updates/edit/xemacs-21.5.29-1.fc11,
which is supposed to close two bugs. When I submitted it, I got this:
500 Internal error
The server encountered an unexpected condition which prevented it from
fulfilling the request.
I checked "My updates" before retyping the whole thing and, sure
enough, there it is, but with only 1 of the two bug numbers I tried to
enter. I've tried editing it several times now, always with an
internal server error and no change to the update as a result. I've
tried entering the two bug numbers as "xxx xxx", "xxx,xxx", and
"#xxx,#xxx", but no joy.
--
Jerry James
http://www.jamezone.org/
14 years, 9 months
TeX Live 2008 available for testing
by Jindrich Novy
Good news everyone!
I've invented a device that installs TeX Live 2008 on your Fedora!
</futurama>
TeX Live 2008 is now packaged and available for testing. It is not in
Fedora yet because it requires reviews of couple of packages. But you
can test it before it happens.
If you want to give it a try, install this package:
# rpm -i http://jnovy.fedorapeople.org/texlive/texlive-release-2008-1.fc11.noarch.rpm
then you can do:
# yum install texlive
if you don't have texlive already installed. While upgrading from
older texlive release please remove all the texlive packages before the
upgrade, especially be sure that the /usr/share/texmf directory is
removed. This is because the famous directory -> symlink upgrade RPM
bug.
The packaging follows upstream packaging metadata so basically you
have the same package naming in upstream TeX Live. The fedora one is
prefixed with the "texlive-*" prefix.
Currently you can use metapackages to install TeX Live:
texlive-scheme-basic
texlive-scheme-context
texlive-scheme-full
texlive-scheme-gust
texlive-scheme-gutenberg
texlive-scheme-medium
texlive-scheme-minimal
texlive-scheme-omega
texlive-scheme-tetex
texlive-scheme-xml
By default when you install TeX Live by "yum install texlive" the
scheme-basic is pulled in.
You can install collections as well, there are 84 of them, list is here:
http://jnovy.fedorapeople.org/texlive/collections
You can install the individual packages as well, complete list is here:
http://jnovy.fedorapeople.org/texlive/pkgs
For more information you can see the Feature page here:
http://fedoraproject.org/wiki/Features/TeXLive
I've put a lot of effort to reduce the total amount from ~4000 to the
current ~1600 source RPMs that need to be reviewed and imported into
Fedora. This is not an easy task but considering that all (except
the main one) of them are automatically generated it could be
possible.
Note that it is in testing state so (many) bugs could occur. There are
possible clashes with applications packaged separately (such as
dvipdfmx, etc.) so we may want to discuss these conflicts with
respective fedora package maintainers to fix them. In case you are a
maintainer of such package please send me an email to jnovy(a)redhat.com
so that we can sort it out on the TeX Live side (packages maintained
separately are preferred).
Thanks,
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
14 years, 9 months
Use of Priority and Severity fields in Bugzilla
by Adam Williamson
Hi, folks.
We in the QA and BugZappers groups have been working for a while on a
proposal to use the severity and priority fields in Bugzilla. With the
help of various groups, and after considerable feedback both within our
groups and from the development group, we're ready to put this into
place now.
To briefly explain the system, the priority field will be reserved by
policy for developers only. You can use it to organize bugs into the
order you'd like to tackle them. Or, you can not. It's entirely up to
you. The policy makes maintainers the sole 'owners' of this field;
no-one else is supposed to touch it, and there are no rules or
guidelines for how it should be used, it's entirely up to developers'
discretion. Significantly, Bugzilla is now configured so that only
members of the 'fedorabugs' FAS group can touch this field, so there is
less chance that - if you decide to actually use it - disgruntled
users / reporters will mess with your settings.
The severity field is reserved by policy to the Bugzappers team and
developers. Again, it's been restricted in Bugzilla now so that only
members of 'fedorabugs' can touch it. The policy is that triagers will
set this field initially as part of triage, but developers have the
final say, and if a developer decides to change the setting chosen by a
triager, the triager is to accept that decision and not change it back.
The guidelines for how the various settings should be used are here:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_...
The severity setting will be used in future as part of the QA and
BugZapper processes - for instance, we're planning to do a weekly review
of 'urgent' severity bugs, and will also review these during blocker bug
review meetings.
This policy and the changes to Bugzilla configuration are all in line
with proposals made during the last few weeks, and sent for feedback to
-devel-list a few weeks back. No opposition has been received to the
proposal in this form. Having said that, if you have a big problem with
this policy, please do let us know and we'll try to accommodate your
concerns.
Thanks very much, and please do contact me directly or test-list (or
anyone else in QA or BugZappers) with any questions relating to this.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
14 years, 9 months
Missing libxklavier.so.12 dependency
by Clemens Eisserer
Hi,
For a few days now updating rawhide doesn't work, because it misses a
dependency:
kdebase-workspace-4.2.95-3.fc12.i586 from rawhide has depsolving problems
--> Missing Dependency: libxklavier.so.12 is needed by package
kdebase-workspace-4.2.95-3.fc12.i586 (rawhide)
Error: Missing Dependency: libxklavier.so.12 is needed by package
kdebase-workspace-4.2.95-3.fc12.i586 (rawhide)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
Is this anything to worry about my system, or will that be fixed anyway?
Thanks, Clemens
14 years, 9 months
(A)synchronous file operations & xdg-open
by Jerry James
This came up in https://bugzilla.redhat.com/show_bug.cgi?id=472402 but
is worth a more general discussion amongst the developer community, I
think.
The xdg-open tool is generally a good thing for the users, but at
least a couple of cases have arisen where it is not doing the right
thing. The problem seems to be that there are two modes of operation
that are wanted.
(1) Launch a tool that can display a persistent URL. This can be
asynchronous, since the object identified by the URL isn't going away.
(2) Launch a tool that can display or edit a temporary file. This
must be synchronous, since the entity that created the temporary file
needs to read it after it is edited, and remove it in either case.
xdg-open is being used for both cases. Some of the tools it invokes,
such as gnome-open, operate in mode 1 and some (kfmclient?) in mode 2.
When a mode 1 tool is used in a situation that demands a mode 2 tool,
bad things happen (see also
https://bugzilla.redhat.com/show_bug.cgi?id=435107).
It appears to me that we either need to split xdg-open into two tools,
representing the two modes of operation, or else give xdg-open a
command-line switch to demand synchronous operation. We also need to
figure out which tools it invokes that operate in mode 1 and find mode
2 equivalents for them. What do you think?
--
Jerry James
http://www.jamezone.org/
14 years, 9 months
No FESCo meeting for 2009-07-03
by Jon Stanley
Due to the US holiday, FESCo will not hold it's regularly scheduled
meeting tomorrow. All business will be postponed until next week.
Have a great 4th if you're in the US, and if you're anywhere else,
have a great 4th anyway! :)
-Jon
14 years, 9 months
Re: Raising the bar
by Matthias Clasen
On Tue, 2009-06-30 at 13:55 -0400, Christopher Beland wrote:
> On Mon, 2009-06-29 at 15:27 -0400, Matthias Clasen wrote:
> > If you have ideas for
> > other areas that could benefit from this kind of attention, please let
> > us know.
>
> I can think of a number of different cross-component tests...
[...]
Yeah, this is a very nice checklist for 'basic sanity'. And any bug you
file about a problem in one of those categories certainly qualifies as a
'fit and finish' issue. But as a test day topic, it might be a bit
boring to spend the whole day testing e.g. copy-and-paste between app X
and Y to fill a big matrix...
Matthias
14 years, 9 months
packaging fix in boost
by Petr Machata
Hi,
recently we've (that's "we" as in me and Benjamin Kosnik, not a royal
"we") broken up boost to sub-packages in Fedora Rawhide, but we forgot
to drop a filelist at the main boost package, intended as an umbrella
over all the sub-packages. So in the end, main boost package was still
as big as it always was and all benefits (and bugs) that the split could
bring were lost. Meh.
boost-1.39.0-3.fc12 that should fix the above is being built right now.
Maintainers of dependent packages, especially those that are known to
be on the Live CD, might want to consider a rebuild.
Thanks,
PM
14 years, 9 months
Package reviews
by Peter Robinson
Hi All,
I'm working to get the core moblin packages into Fedora with the plan
of having at least experimental support in time for F-12. If you've
got a few spare cycles and have some time to review a package there's
a list against the tracker bug here.
https://bugzilla.redhat.com/show_bug.cgi?id=506446
Regards,
Peter
14 years, 9 months
