Re: pup: boon or curse? quicker updates or slower updates?
by Francois Aucamp
On Fri, 2007-03-09 at 18:06 +0530, Debarshi 'Rishi' Ray wrote:
> First of all someone who is using the command line interface and not
> the GUI, even when the GUI is available, is not a complete newbie. If
> he has the acumen to remember the 'cd', 'clear', 'ls', 'sudo yum',
> etc. dance then why can not he/she remember the 'apt-get update' and
> 'apt-get upgrade' dance?
>
I suppose this is a fair enough assumption. But, unlike 'cd', 'ls', etc
which perform _immediately-required_ actions, 'apt-get update' (from a
semi-newbie point of view) does nothing tangible. (Think: "It's updating
the repository information? What's that? Why is this needed? Why can't I
just install the program?") So unlike the basic commandline commands,
the "apt-get update" command gives no immediately obvious results to
someone coming from, say, That Other OS. Explaining to them what
"apt-get update" does is usually pointless, as they do not always
understand and definitely don't care. They _just want it to work_.
Oh, and you'd be surprised at how many "newbies" use/want to use the
command line (see comments about the yum gui below)...
> Even if it is still a problem, then consider that we have yum-updatesd
> downloading update information automatically in the background, and
> Yum itself engineered in such a way that it will download update
> information after 'metadata_expires' is reached. No matter how high
> the value of 'metadata_expires' is, this is simply not needed. If I am
> a newbie, and can not handle the 'apt-get update' and 'apt-get
> upgrade' dance, I will simply ask yum-updatesd to do the job for me.
> Provided, ofcourse, I have the bandwidth to do it efficiently.
> Otherwise, if I know my way around or have bandwidth issues, then I
> shall simply switch of yum-updatesd and resort to the apt-get update'
> and 'apt-get upgrade' dance.
>
Fair enough, but if you know what you're doing, then why not simply use
something like "yum -C update"? This does the same as "apt-get upgrade",
i.e. it runs from the local metadata cache.
> Secondly, since most newbies are prone to use GUI tools, if Pirut has
> a nice icon (like Synaptic) that prominently announces: "look for
> updates", then I do not think people have to remember any dance
> sequence at all. As far as I have seen, Ubuntu users (mostly newbies
> not knowing what 'ls' and 'clear' are) are so happy with their
> distribution simply because Synaptic precisely does this. I have not
> seen a single Pirut user who is even marginally content. If such a
> feature was removed to help any newbie, then it has surely failed to
> do so.
>
> Before finishing let me give my own example. The only repositories
> that I use are Fedora's Core, Updates and Extras; and ATRPMs. All
> these are mirrored locally on my LAN, and I do not use the upstream
> repositories ever, except for keeping the local ones updated. I do not
> run yum-updatesd too. On such a set-up when I start Pirut, it takes 15
> seconds to show the initial window, which is the 'browse' (leftmost)
> tab. Funnily it has no package or category listed. When I click the
> 'list' (rightmost) tab it takes a further 60 seconds to show the
> package list. Everytime I change tabs and come back to 'list' it takes
> the same amount of time as before. Since I do not use a US English
> desktop the tabs might not be named exactly 'browse' and 'list', but
> that is what they look like from the local language traslation.
I agree, Pirut's "lag time" is a pain, and as a whole the GUI isn't as
streamlined as Ubuntu's GUI update manager (synaptic with a "friendlier"
starting point). It's "list-page slowness" has some more problems than
just a "yum update"-induced issue, however; imho this needs
_desperately_ needs to be looked at. Some of our newbie users actually
prefer the yum-cli because of this.
I submitted a "concept" patch a while back that allows "off-line" and
"non-root" usage of Pirut (amongst some other things) - this same
technique could be used to lessen the metadata-update requirements of
the GUI, at least.
Interestingly enough, we are running a very similar setup. I, however,
use a managed mix of core, updates, extras, livna, rpmforge, kde-redhat,
freshrpms and dribble, and all our local machines update from a
centralized cache. As you can guess, this cache serves a fairly large
amount of machines. Explaining basic repository management (read:
apt-get update; apt-get upgrade or apt-get update, apt-get install X) to
_all_ of the people becomes a bit of a drag when a single "yum update"
or "yum install" command is enough. This is the same with Synaptic; the
package metadata gets old eventually (however it does prompt the user
when this happens, which is nice).
> I am basically an end-use when it comes to Yum and/or Pirut, but I
> know Python and do some programming and would like to help out
> regarding this if required.
>
Me too. Is there some (clear) way that the community can get more
involved in Pirut/yum's development (outside of only writing yum
plugins)?
To summarise:
I agree with almost everything you are saying (especially the
GUI-related stuff), I just feel that yum's _default_ behaviour should
not necessarily be similar to apt's. :-)
Cheers,
-Francois
--
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
CallCentre(a)csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
17 years, 1 month
Selinux and hal
by Bart Vanbrabant
Hello,
I'm using a fully updated rawhide installation. Today I got some updates
from extras. I think the problem started when the update of gutenprint
was installed. I keep getting this message from sealert:
Summary
SELinux is preventing /usr/sbin/hald (hald_t) "read" access to inotify
(inotifyfs_t).
Detailed Description
SELinux denied access requested by /usr/sbin/hald. It is not
expected that
this access is required by /usr/sbin/hald and this access may signal an
intrusion attempt. It is also possible that the specific version or
configuration of the application is causing it to require additional
access.
Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
against this
package.
Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try to
restore the default system file context for inotify, restorecon -v
inotify.
There is currently no automatic way to allow this access. Instead,
you can
generate a local policy module to allow this access - see
http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 - or you can
disable SELinux protection entirely for the application. Disabling
SELinux
protection is not recommended. Please file a
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Changing the "hald_disable_trans" boolean to true will disable SELinux
protection this application: "setsebool -P hald_disable_trans=1."
The following command will allow this access:
setsebool -P hald_disable_trans=1
Additional Information
Source Context system_u:system_r:hald_t
Target Context system_u:object_r:inotifyfs_t
Target Objects inotify [ dir ]
Affected RPM Packages
Policy RPM
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.disable_trans
Host Name duvel
Platform Linux duvel 2.6.20-1.2967.fc7PAE #1 SMP
Tue Mar 6
14:49:37 EST 2007 i686 athlon
Alert Count 261
First Seen Fri Mar 9 11:10:56 2007
Last Seen Fri Mar 9 11:10:58 2007
Local ID 0057c30e-29d5-4a43-a1c7-1b382f49f813
Line Numbers
Raw Audit Messages
avc: denied { read } for comm="hald" dev=inotifyfs egid=68 euid=68
exe="/usr/sbin/hald" exit=-13 fsgid=68 fsuid=68 gid=68 items=0
name="inotify"
path="inotify" pid=2255 scontext=system_u:system_r:hald_t:s0 sgid=68
subj=system_u:system_r:hald_t:s0 suid=68 tclass=dir
tcontext=system_u:object_r:inotifyfs_t:s0 tty=(none) uid=68
I've already gotten more than 260 of those messages in 5 minutes. I had
to kill auditd when it used 58% of my 1GB ram. For a daemon that has to
do some logging this is quite extreme.
Has anyone else seen this problem? Should I file bugreports somewhere?
thanks,
Bart
--
Bart Vanbrabant <bart.vanbrabant(a)zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1
17 years, 1 month
How does new F7 schedule affect Firefox
by Bojan Smojver
Now that the planned release date for F7 is 24 May 2007 (a month after
EOL for FF 1.5) and keeping in mind that FC6 will be supported until
F8T2 (so, say until about September 2007 or so), isn't that going to
cause the need for backporting of fixes to FF 1.5 for about 4 to 5
months? Wouldn't it be better (i.e. less effort) to bite the bullet now
and just upgrade the whole FC6 to FF 2.0?
PS. Yes, I'm aware that similar questions have been asked before, but F7
was on a different schedule then.
--
Bojan
17 years, 1 month
naming scheme for fonts packages?
by Jens-Ulrik Petersen
I am currently reviewing a Tibetan font for inclusion in Fedora.
It is called Tibetan Machine Uni, and we have had a lengthy
polite discussion on the naming of the package both in and out
of bugzilla, also with the upstream maintainer. (The project is hosted
on SourceForge and GPL fwiw). The package was submitted as
tibetan-machine-uni-fonts, so I suggested fonts-tibetan. However since
the font is also good for Bhutanese, the submitter and the maintainer
think fonts-tibetan-dzongkha (bhutanese) would be more appropriate.
It occurred to me that we really need some guideline about naming of
fonts packages. Most of our international fonts follow the naming
scheme "fonts-*" where "*" is the generally the English name of the
language, which makes the package pretty easy to find. And the
remainder are mostly suffixed with "-fonts". Currently in F7T2 there are:
fonts-ISO8859-2 fonts-KOI8-R fonts-arabic fonts-bengali fonts-chinese
fonts-gujarati fonts-hebrew fonts-hindi fonts-japanese fonts-kannada
fonts-korean fonts-malayalam fonts-oriya fonts-punjabi fonts-sinhala
fonts-tamil fonts-telugu
and:
bitmap-fonts bitstream-vera-fonts dejavu-lgc-fonts ghostscript-fonts
tetex-fonts urw-fonts xorg-x11-fonts
In Extras the fonts tend to be more alternative/miscellaneous I guess:
VLGothic-fonts artwiz-aleczapka-fonts charis-fonts dejavu-fonts
doulos-fonts gentium-fonts hunky-fonts linux-libertine-fonts
mathml-fonts mgopen-fonts terminus-font, and fonts-hebrew-fancy
So perhaps we need to set two naming conventions: using
"fonts-<language>" for standard international fonts and "<name>-fonts"
for alternative general fonts?
Of course "fonts-<language>" doesn't quite solve the problem for the
Tibetan font... ;) The name fonts-tibetan-script was also brought up,
and even fonts-bodic.
It would probably be good to add some text about in on
http://fedoraproject.org/wiki/Packaging/NamingGuidelines anyway.
Comments? Opinions?
Jens
17 years, 1 month
Re: Slightly OT: bad rap for Fedora, and realistic effects
by Jef Spaleta
On 2/22/07, Arthur Pemberton <pemboa(a)gmail.com> wrote:
> And this may or may not be the correct -list for this, but here goes.
> I think its fair to say that a lot of the louder voices on the
> internet do not like Fedora for fair and unfair reasons. My question
> is what does this do to Fedora, and RedHat by association. I can't
> imagine that anything good is coming of this. All the developers here
> are bound by the 24hr daily limit, ie. there is a finite amount of
> work that any developer can accomplish, esp. those not being paid to
> work on Fedora. Making the assumption that all these negative word of
> mouth is bleeding Fedora of contributors, then what's the plan?
First I'd stop making unfounded assumptions about how the contributor
numbers are falling.
There's no real evidence of that at all. We we saw this week was
another chapter of the lack of contribution from the same person, a
person with a long standing personal agenda which is at odds with the
policies of this project, and someone who consistently speaks based on
information which appears to be based on the a view of the fedora
project which is 6 months to a year out of date. At the end of the
day, this was not a suddenly new development, and it was not the loss
of an active contributor. What we have been seeing this week is a
skilled politician using what have become very standard tricks of the
trade. Its messy and its ugly, but anyone whose lived through the
last decade of US national political cycles should recognize it for
what it is. To re-use a phrase, Fedora's been swift-boated. It's
really unfortunate that such political skill has been squandered for
such a petty purpose. I fear for the health of the freespire project
if a board member of that project needs to publicly attack a competing
project via personal letters directly to the press.
But unlike politicians, we aren't gearing up for an election day.
There is no drop-dead date
by which we need to convince a majority of contributors to work with
us for X number of years. That's sort of the great thing about...
community. We don't need to strong arm, or twist the truth, or talk
smack about competing ideas. Fedora does not need to win a decisive
victory at the expense of other community projects. Fedora can
continue to build an active community and continue to make the long
term impact that it needs to make and fulfill its stated mission. All
we need to do is do our best is to be upfront about what this project
is, what its goals are, and to be as encompassing and supportive of as
many people's individual itches inside that framework.
If we wanted to run a counter political campaign, then I would very
much suggest everyone who is interested, write Max Spevack with a
short personal testimony with your positive personal pov as to what
you get out of being a contributor to Fedora. What you feel is
important about Fedora that makes it worth the time. Because that's
what matters. its not the number of contributors, or size of the
codebase, or the size of the userbase. What matters when choosing to
be a volunteer for any organization or project is knowing that by
contributing your time and your talents you are personally growing
from the experience and that your efforts are making a difference.
I'm sure Max won't mind compiling selected testimonials into a PR
piece to counter-balance any further poltical manipulation of the
laypress.
If we don't attract people who are looking for personal control,
instead of personal growth.. that is a perfectly acceptable outcome to
me. We don't need to attract everybody, niether as a user nor as a
contributor. We need to do our best to attract the people who would
work well inside the scope of the project... and at the same time help
others find projects which fit best for them. Fedora should be the
linux distribution like Progressive is to car insurance. If we aren't
the best choice for you, we'll help you find the distribution that is.
For some outspoken media-savvy people, a position on the freespire
board may very well be the project that fits them best. It's just
unfortunate that it took that person as long as it did to figure that
out. If I regret anything with regard to how this project has treated
said individual, it is that we didn't try hard enough earlier on to
help him find linspire sooner.
Does this project has problems to solve? Absolutely, but the important
ones the Fedora needs to focus on right now have nothing to do with
the screed we saw in the press this week. But every single important
problem that this project faces is the result of growth, and growing
pains can hurt like hell some times.
-jef"Fedora's growing up, soon there will be hair growing on it in
some very sensitive places"spaleta
17 years, 1 month
AMSN update problem.
by David Hunter
When I try to update AMSN to amsn - 0.96-6.fc7.i386 from amsn -
0.96-5.fc7.i386, software updater reports the following:
('file /usr/lib/tcl8.4 from install of amsn-0.96-6.fc7 conflicts with file
from package tcl-8.4.13-12.fc7', (7, '/usr/lib/tcl8.4', 0L))]
How do I rectify the problem?
--
David Hunter
17 years, 1 month
rawhide report: 20070306 changes
by Build System
Updated Packages:
anaconda-11.2.0.29-1
--------------------
* Mon Mar 05 2007 Jeremy Katz <katzj(a)redhat.com> - 11.2.0.29-1
- Fix some typos (clumens, dcantrell, katzj)
- Use depsolving from yum instead of our own stuff now that the yum
depsolving doesn't require header downloads
- Misc backend cleanups
- Fix deprecation warnings (#230951)
- Networking fixing (#210370)
- BR newt-static
brltty-3.7.2-3.fc7
------------------
* Mon Mar 05 2007 Tomas Janousek <tjanouse(a)redhat.com> - 3.7.2-3
- added the XWindow driver
- build fix for newer byacc
cairo-java-1.0.5-6.fc7
----------------------
* Mon Mar 05 2007 Stepan Kasal <skasal(a)redhat.com> - 1.0.5-6
- Touch aclocal.m4, configure, Makefile.in after applying the patch.
- Force -fPIC and avoid -Wall with gcj/ecj.
* Wed Feb 21 2007 Andrew Overholt <overholt(a)redhat.com> 1.0.5-5
- Bump for new gcj.
- Add patch for gcjh -> gjavah.
cscope-15.5-15.4.fc7
--------------------
* Mon Mar 05 2007 Neil Horman <nhorman(a)redhat.com> -15.5-15.4.dist
- Make sigwinch handler only register for curses mode (bz 230862)
dhcdbd-2.6-1.fc7
----------------
* Mon Mar 05 2007 David Cantrell <dcantrell(a)redhat.com> - 2.6-1
- Spec file cleanups to conform to Fedora packaging guidelines
- Run 'chkconfig --del dhcdbd' on package removal (#222514)
dhcp-12:3.0.5-25.fc7
--------------------
* Mon Mar 05 2007 David Cantrell <dcantrell(a)redhat.com> - 12:3.0.5-25
- Man pages need 0644 permissions (#222572)
* Thu Mar 01 2007 David Cantrell <dcantrell(a)redhat.com> - 12:3.0.5-24
- Include contrib/ subdirectory in /usr/share/doc (#230476)
- Added back Requires for perl since dhcpd-conf-to-ldap needs it (#225691)
- Put copies of dhcp-options and dhcp-eval man pages in the dhcp and
dhclient packages rather than having the elaborate symlink collection
- Explicitly name man pages in the %files listings
- Use the %{_sysconfdir} and %{_initrddir} macros (#225691)
- Use macros for commands in %build and %install
- Split README.ldap, draft-ietf-dhc-ldap-schema-01.txt, and
dhcpd-conf-to-ldap.pl out of the LDAP patch
- Split linux.dbus-example script out of the extended new option info patch
- Remove unnecessary changes from the Makefile patch
* Wed Feb 28 2007 David Cantrell <dcantrell(a)redhat.com> - 12:3.0.5-23
- Update Xen partial checksums patch
- Remove perl Requires (#225691)
- Make dhcp-devel depend on dhcp = e:v-r (#225691)
- libdhcp4client-devel Requires pkgconfig (#225691)
- Do not add to RPM_OPT_FLAGS, use COPTS variable instead (#225691)
- Use %{buildroot} macro instead of RPM_BUILD_ROOT variable (#225691)
- Preserve timestamps on all installed data files (#225691)
- Remove dhcp-options.5.gz and dhcp-eval.5.gz symlinking in post (#225691)
- Use %defattr(-,root,root,-) (#225691)
- Do not flag init scripts as %config in %files section (#225691)
fonts-indic-2.1.4-1.fc7
-----------------------
* Mon Mar 05 2007 Parag Nemade <pnemade(a)redhat.com> - 2.1.4
- Resolved Bugs from Parag Nemade
- Bug 221383: [kn_IN] GSUB combinations has problem with Ra
glib-java-0.2.6-8.fc7
---------------------
* Mon Mar 05 2007 Stepan Kasal <skasal(a)redhat.com> - 0.2.6-8
- Touch aclocal.m4, configure, Makefile.in after applying the patch.
gnupg-1.4.7-3
-------------
* Mon Mar 05 2007 Nalin Dahyabhai <nalin(a)redhat.com> - 1.4.7-3
- update to 1.4.7, changing the default to not allow multiple plaintexts in
a single stream
gzip-1.3.11-1.fc7
-----------------
* Mon Mar 05 2007 Ivana Varekova <varekova(a)redhat.com> - 1.3.11-1
- update to 1.3.11
remove uncompress
kdeadmin-7:3.5.6-2.fc7
----------------------
* Mon Mar 05 2007 Than Ngo <than(a)redhat.com> - 7:3.5.6-2.fc7
- cleanup specfiles
kdepim-6:3.5.6-3.fc7
--------------------
* Mon Mar 05 2007 Than Ngo <than(a)redhat.com> 3.5.6-3.fc7
- cleanup specfile
kernel-2.6.20-1.2966.fc7
------------------------
* Mon Mar 05 2007 Dave Jones <davej(a)redhat.com>
- Generate modules.(scsi|libata|networking)
* Mon Mar 05 2007 Dave Jones <davej(a)redhat.com>
- 2.6.21rc2-git4
* Mon Mar 05 2007 Dave Jones <davej(a)redhat.com>
- 2.6.21rc2-git3
libdhcp-1.23-1.fc7
------------------
* Mon Mar 05 2007 David Cantrell <dcantrell(a)redhat.com> - 1.23-1
- Pass %{_libdir} in %install
* Mon Mar 05 2007 David Cantrell <dcantrell(a)redhat.com> - 1.22-1
- Remove unused variables from nic.c
* Mon Mar 05 2007 David Cantrell <dcantrell(a)redhat.com> - 1.21-1
- Spec file cleanups for Fedora packaging guidelines
- Lose some of the NIC_DEBUG noise (#199481)
libgtk-java-2.8.7-4.fc7
-----------------------
* Mon Mar 05 2007 Stepan Kasal <skasal(a)redhat.com> - 2.8.7-4
- Touch aclocal.m4, configure, Makefile.in after applying patch1.
- Force -fPIC and avoid -Wall with gcj/ecj.
* Wed Feb 21 2007 Andrew Overholt <overholt(a)redhat.com> 2.8.7-3
- Rebuild for new gcj.
- Add patch for gcjh -> gjavah.
man-pages-fr-2.39-8.fc7
-----------------------
* Mon Mar 05 2007 Marcela Maslanova <mmaslano(a)redhat.com> 2.39-8
- merge review
- rhbz#230061
mlocate-0.16-1
--------------
* Tue Mar 06 2007 Miloslav Trmac <mitr(a)redhat.com> - 0.16-1
- Update to mlocate-0.16
- Enable PRUNE_BIND_MOUNTS by default
Resolves: #221755
openoffice.org-1:2.2.0-10.1
---------------------------
* Sun Mar 04 2007 Caolan McNamara <caolanm(a)redhat.com> - 1:2.2.0-10.1
- next release candidate
- drop d_type patch, no perceptable difference in performance
http://people.redhat.com/caolanm/speed/d_type.ods
privoxy-3.0.6-7.fc7
-------------------
* Mon Mar 05 2007 Karsten Hopp <karsten(a)redhat.com> 3.0.6-7
- rpmlint fixes
* Mon Mar 05 2007 Karsten Hopp <karsten(a)redhat.com> 3.0.6-6
- add upstream patch for dynamic pcre (#226316)
- use kill -s HUP instead of 'kill -HUP' (#193159)
setroubleshoot-1.9.3-1.fc7
--------------------------
* Mon Mar 05 2007 John Dennis <jdennis(a)redhat.com> - 1.9.3-1
- install icon in /usr/share/icons, refer to icon by name using standard API
- Fix performance problems in setroubleshoot browser log file scanning
- Significant rewrite of data/view management code in setroubleshoot
browser. data and view now cleanly separated, can easily switch
between data views while maintaining selections, view state, with
proper update of status information in status area
- Resolves Bug# 227806: right click context menu resets selection
- Logfile scans now operate in independent thread, proper asynchronous
updates of browser during scan, browser used to appear to hang
- Resolves Bug# 224340: Rewrite Menu/Toobar/Popup to use UIManger instead of glade
- Add toobar support
- Implement GUI to edit email recipient list in setroubleshoot browser
- Added user help to setroubleshoot browser
- Related Bug# 224343: Fix setroubleshoot browser to respond to desktop theme changes
- improve traceback error reporting in sealert
- rewrite AboutDialog, replacing glade version
- Resolves bug #229849 Bug# 230115, Relates bug #221850: fix uuid code to resolve
'_uuid_generate_random' is not defined error
tcp_wrappers-7.6-42.fc7
-----------------------
* Mon Mar 05 2007 Tomas Janousek <tjanouse(a)redhat.com> - 7.6-42
- added Obsoletes field so that the upgrade goes cleanly
- added dist tag
vixie-cron-4:4.1-76.fc7
-----------------------
* Mon Mar 05 2007 Marcela Maslanova <mmaslano(a)redhat.com> - 4:4.1-76
- rhbz#226529 merge review
vnc-4.1.2-15.fc7
----------------
* Mon Mar 05 2007 Adam Tkac <atkac redhat com> 4.1.2-15.fc7
- improved vnc-always_use_fb patch (some screen defects on 64bits)
- removed xserver tarball from source list
xorg-x11-drv-i810-1.6.5-13.fc7
------------------------------
* Mon Mar 05 2007 Adam Jackson <ajax(a)redhat.com> 1.6.5-13
- Updated modesetting driver to one that will actually work with a 1.3 server.
xorg-x11-server-1.2.99.901-1.fc7
--------------------------------
* Mon Mar 05 2007 Adam Jackson <ajax(a)redhat.com> 1.2.99.901-1
- xserver 1.3 RC1. RANDR 1.2 hotness in the hizzouse.
- xserver-1.2.0-honor-displaysize.patch: Honor the DisplaySize config
directive again (#220248)
- Clean up the post-install cleanup
* Fri Mar 02 2007 Adam Tkac <atkac(a)redhat.com> 1.2.0-10
- change permissions of files in source package to default from read-only
* Mon Feb 26 2007 Adam Tkac <atkac(a)redhat.com> 1.2.0-9
- Created new package (xorg-x11-server-source) which is needed to build VNC
server.
zsh-4.2.6-6.fc7
---------------
* Mon Mar 05 2007 James Antill <james(a)and.org> - 4.2.6-6
- Move requires to be scriptlet specific
- chmod functions, to shut rpmlint up (false positive warning)
- sed only the requied functions (again, shuts rpmlint up)
- Remove zsh-4.0.6-make-test-fail.patch
- Remove RPM_SOURCE_DIR var, using %{SOURCEx} and basename
Resolves: rhbz#226813
Broken deps for i386
----------------------------------------------------------
frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh
frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh
frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh
gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3
gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16
gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15
kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils
kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils
libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh
libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh
libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh
libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh
Broken deps for x86_64
----------------------------------------------------------
frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit)
frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh
frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit)
frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh
frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit)
frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh
gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit)
gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit)
gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit)
kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils
kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils
kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils
libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh
libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit)
libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh
libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit)
libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh
libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit)
libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh
libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit)
Broken deps for ia64
----------------------------------------------------------
gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit)
gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit)
gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit)
kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils
kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils
libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit)
libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit)
libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit)
libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit)
net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel
Broken deps for s390
----------------------------------------------------------
gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16
gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15
gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3
kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils
kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils
libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh
libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh
libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh
libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh
net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel
systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11
systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11
Broken deps for ppc
----------------------------------------------------------
gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3
gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16
gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15
kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils
kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils
libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh
libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh
libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh
libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh
net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel
Broken deps for s390x
----------------------------------------------------------
gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit)
gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit)
gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit)
kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils
kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils
kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils
libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit)
libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh
libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh
libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit)
libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh
libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit)
libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit)
libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh
net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel
net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel
Broken deps for ppc64
----------------------------------------------------------
gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit)
gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit)
gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit)
kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils
kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils
libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit)
libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit)
libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit)
libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit)
net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel
17 years, 1 month
glibc help needed with fakeroot: changes in chown?
by Axel Thimm
Hi,
fakeroot preloads its lib overriding file access and identity commands
to fake the impression of being root.
A couple of weeks ago fakeroot's chown stopped to work. This happens
even on an FC6 kernel (and a rawhide chroot), so it looks like
something changed in glibc that makes fakeroot break on chown. All
other overridden calls seems to work fine.
Can anyone please help with what has changed and suggest how to adjust
fakeroot?
Thanks!
--
Axel.Thimm at ATrpms.net
17 years, 1 month
Translations: String freezes, CVS converging, Packaging
by Dimitris Glezos
Hi all.
The L10n project has been discussing for a while now (also at FOSDEM with
mspevack) about ways to improve our translation processes. We estimate that more
than 1 out of 3 users uses a non-English desktop.
First of all, let's clarify here that for the time being, we are referring only
to applications that Fedora is upstream (anaconda, system-config-*, and
basically most of the non-deprecated stuff that appears on [1]).
[1]:http://i18n.redhat.com/cgi-bin/i18n-status?page=status&locale=es&branc...
The plan in mind includes three actions.
## String freezes
For F7, the RelEng team has introduced string freezes in the schedule [2]. This
means that application strings for F7 should be complete *by 19/3*. Translations
made after this date (and before the freeze) should be guaranteed to be included
in the release.
[2]: http://fedoraproject.org/wiki/Core/Schedule
To do this we need to try not to add new strings after the freeze and let the
L10n folks know if they need to do so. Also, maintainers should repackage before
each release (and after the translation freeze) without a bug needing to be
opened.
## CVS convergence
Right now translations are done on `i18n.redhat.com`. This requires contributors
to have one account on the Fedora Account System (FAS) and a different
one for translations. With the merge of Core and Extras, now is a good
point to get rid of this distinction.
The plan is to move all PO files on Fedora infrastructure under a new
CVS group (cvsl10n) [3]. An email will be sent to all translators to create a
FAS account if they don't have one and join the cvs group. Members of the L10n
team and ambassadors will help with this process.
[3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure
At this point we could discuss the idea for Fedora to act as upstream for
the translations of outside-hosted projects such as yum, smolt, and
pungi. The proposal is to host and maintain those project's
translations with the existing Fedora L10n community.
## Packaging translations
One final plan (and probably the one that needs most discussion) is about
changing the way we package translations. Right now PO files live inside the
application and are packaged there (GNOME-style). The plan is to move the PO
files in to their own directory and distinct package [4] (KDE-style langpacks).
[4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage
Cons: L10n team should maintain a package (or many) and packages should be
altered to accomodate the different locations of PO files.
Pros (many): increased modularity and maintenance (L10n repackages at
will). App packages will be smaller in size -- we could provide
one langpack or different ones per language.
Comments, suggestions?
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
17 years, 1 month
Kernel 2.6.19 squashfs problem and bugzilla
by Olivier Galibert
The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to
loop-mount the fc5 install Fedora/base/stage2.img file, at least
through nfs. You get:
squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher
SQUASHFS error: sb_bread failed reading block 0x9e8be8e1
SQUASHFS error: unable to read inode lookup table
As for bugzilla, I was wondering where to file that one, would it be
bugzilla.redhat.com or bugzilla.fedora.us? And if the latter, is it
going to actually work any time soon? I don't think I've ever been
able to contact it.
OG.
17 years, 1 month