[Cooker] [Bug 6350] [kdebase-progs] New: kcontrol has broken theme manager
http://qa.mandrakesoft.com/show_bug.cgi?id=6350 Summary: kcontrol has broken theme manager Product: kdebase-progs Version: 3.1.93-19mdk Platform: All OS/Version: All Status: UNCONFIRMED Severity: major Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] kcontrol's theme manager is totally broken. This means that KDE cannot use themes, either included ones, ones made by users, or any of the hundreds available places like kde-look.org. 1) Load kcontrol 2) Select Appearance Themes 3) Select Theme Manager 4) You get the error: The was an error loading the module. 5) Click on details, to see: The diagnostics is: Library files for libkcm_themes.la not found in paths Possible reasons: An error occurred during your last KDE upgrade leaving an orphaned control module You have old third party modules lying around. Check these points carefully and try to remove the module mentioned in the error message. If this fails, consider contacting your distributor or packager. It appears that libkcm_themes.* is not included in any of the *kdebase* packages. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 6350] [kdebase-progs] kcontrol has broken theme manager
http://qa.mandrakesoft.com/show_bug.cgi?id=6350 --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 16:56 --- Because bugzilla is whining about it (it thinks -9 instead of -19 is the latest), let me give more version info: This is with the latest kdebase (and other kde) stuff, but AFAIR, this bug has been there since 3.1.93 started. $ rpm -qa | grep kdebase | sort -n kdebase-common-3.1.93-19mdk kdebase-kate-3.1.93-19mdk kdebase-kdeprintfax-3.1.93-19mdk kdebase-kdm-3.1.93-19mdk kdebase-kdm-config-file-3.1.93-19mdk kdebase-konsole-3.1.93-19mdk kdebase-nsplugins-3.1.93-19mdk kdebase-progs-3.1.93-19mdk kdebase-servicemenu-1.0-13mdk libkdebase4-3.1.93-19mdk libkdebase4-kate-3.1.93-19mdk libkdebase4-konsole-3.1.93-19mdk libkdebase4-nsplugins-3.1.93-19mdk -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: kcontrol's theme manager is totally broken. This means that KDE cannot use themes, either included ones, ones made by users, or any of the hundreds available places like kde-look.org. 1) Load kcontrol 2) Select Appearance Themes 3) Select Theme Manager 4) You get the error: The was an error loading the module. 5) Click on details, to see: The diagnostics is: Library files for libkcm_themes.la not found in paths Possible reasons: An error occurred during your last KDE upgrade leaving an orphaned control module You have old third party modules lying around. Check these points carefully and try to remove the module mentioned in the error message. If this fails, consider contacting your distributor or packager. It appears that libkcm_themes.* is not included in any of the *kdebase* packages.
[Cooker] [Bug 5308] [subversion-repos] svnadmin create seems to be creating wrong repository format
http://qa.mandrakesoft.com/show_bug.cgi?id=5308 --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 03:33 --- Just FYI: one of the 0.28-series subversion RPMs mandrake shipped had a svnadmin that made repositories in format '2' but marked them as '1'. If you have a repository like this, *NO* version will load or dump it directly; you have to do an 'echo 2 repos/format' first. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: trying to do a dump and restore svnadmin create etc [EMAIL PROTECTED] svn]# svnadmin load etc /mnt/disk/backups/etc.svn.dmp.20030906 svn: Unsupported repository version svn: Expected version '2' of repository; found version '1' [EMAIL PROTECTED] svn]# looking at etc/format shows a format number of 1 and not 2
[Cooker] [Bug 5258] [subversion-client-common] New: ra modules aren't loaded - missing .so link
http://qa.mandrakesoft.com/show_bug.cgi?id=5258 Product: subversion-client-common Component: packaging Summary: ra modules aren't loaded - missing .so link Product: subversion-client-common Version: 0.28.1-1mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm filling this against subversion-client-common, but it actually applies to the subversion-client-local and subversion-client-dav as well. Here is the bug and a possible fix: If you try to use svn, it won't be able to use any transports, because it can't load the ra modules it needs. You can tell the problem pretty easily: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: (Well, NONE are listed!) The problem can be seen if you do an 'strace svn --version': I won't paste it here, but basically svn is looked all over the place for it's ra modules named .so but there is no symlink to .so for any of the transports, only .so.0's. I fixed this on my system by just doing: $ cd /usr/lib $ ln -s libsvn_ra_dav-1.so.0 libsvn_ra_dav-1.so $ ln -s libsvn_ra_svn-1.so.0 libsvn_ra_svn-1.so $ ln -s libsvn_ra_local-1.so.0 libsvn_ra_local-1.so And now: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' schema - handles 'https' schema * ra_local : Module for accessing a repository on local disk. - handles 'file' schema * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' schema So it looks like either those .so symlinks need to be packaged, or svn needs to be compiled in such a way that it looks for the .so.0 files when doing dynamic loading of the ra modules. BTW, despite the flurry of subversion bugs lately, the packaging of it has been getting immensely better. Keep up the good work! =) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4066] [subversion-repos] updating subversion via urpmi gives errors
http://qa.mandrakesoft.com/show_bug.cgi?id=4066 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 18:32 --- This is fixed in the latest subversion packages, at least as of *-0.28.1-1mdk. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: [EMAIL PROTECTED] joe]$ sudo /usr/sbin/urpmi subversion-repos To satisfy dependencies, the following packages are going to be installed (10 MB): ADVX-build-9.2-1mdk.noarch apache2-devel-2.0.46-3mdk.i586 expat-1.95.6-3mdk.i586 libexpat0-1.95.6-3mdk.i586 libexpat0-devel-1.95.6-3mdk.i586 libgdbm2-devel-1.8.0-21mdk.i586 libsasl2-2.1.13-2mdk.i586 libsasl2-devel-2.1.13-2mdk.i586 libsubversion0-0.23.0-2mdk.i586 pam-0.75-33mdk.i586 pam-devel-0.75-33mdk.i586 subversion-client-common-0.23.0-2mdk.i586 subversion-client-local-0.23.0-2mdk.i586 subversion-repos-0.23.0-2mdk.i586 Is this OK? (Y/n) y The following packages have bad signatures: /var/cache/urpmi/rpms/pam-devel-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/expat-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/ADVX-build-9.2-1mdk.noarch.rpm /var/cache/urpmi/rpms/libexpat0-devel-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-local-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsubversion0-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/pam-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/subversion-repos-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libgdbm2-devel-1.8.0-21mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-devel-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libexpat0-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/apache2-devel-2.0.46-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-common-0.23.0-2mdk.i586.rpm Do you want to continue installation ? (y/N) y installing /var/cache/urpmi/rpms/pam-devel-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/expat-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/ADVX-build-9.2-1mdk.noarch.rpm /var/cache/urpmi/rpms/libexpat0-devel-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-local-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsubversion0-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/pam-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/subversion-repos-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libgdbm2-devel-1.8.0-21mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-devel-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libexpat0-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/apache2-devel-2.0.46-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-common-0.23.0-2mdk.i586.rpm Installation failed: libldap.so is needed by subversion-client-local-0.23.0-2mdk liblber.so is needed by subversion-client-local-0.23.0-2mdk libldap.so is needed by libsubversion0-0.23.0-2mdk liblber.so is needed by libsubversion0-0.23.0-2mdk libsvn_diff-1.so is needed by libsubversion0-0.23.0-2mdk libldap.so is needed by subversion-repos-0.23.0-2mdk liblber.so is needed by subversion-repos-0.23.0-2mdk libsvn_diff-1.so is needed by subversion-client-common-0.23.0-2mdk libldap.so is needed by subversion-client-common-0.23.0-2mdk liblber.so is needed by subversion-client-common-0.23.0-2mdk
[Cooker] [Bug 2493] [xinitrc] automatic gpg-agent startup for X
http://qa.mandrakesoft.com/show_bug.cgi?id=2493 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 18:47 --- I think this is a really good idea. I actually implemented this myself on my systems before seeing this bug--it would be great to have it integrated into Mandrake. BTW, an IMHO slightly better way to have the gpgagent startup script work is the following (that I stole from somewhere off the web and modified a little): if test -f $HOME/.gpg-agent-info kill -0 `cut -d: -f 2 $HOME/.gpg-agent-info` 2/dev/null; then GPG_AGENT_INFO=`cat $HOME/.gpg-agent-info` export GPG_AGENT_INFO else eval `/usr/bin/gpg-agent --daemon` echo $GPG_AGENT_INFO $HOME/.gpg-agent-info fi The advantage of this is: 1) If an existing gpg-agent is already running, it doesn't kill it. (kill -0 just tests) 2) Since we store info in $HOME/.gpg-agent-info, if for some [bizarre] reason the user is running an unrelated process called gpg-agent, we neither kill it (which is intrusive and wrong) nor are we confused into thinking it's the gpg-agent we are looking for. This is the same reason that initscripts save pids and don't just do killalls. Again, as Pascal pointed out, this script has to be included in the context of the Xsession--it **will not** work to put a script in xinit.d -- this actually seems to me to be a gpg-agent bug, actually, as it should be able to support the same semantics as ssh-agent... but that's another bugzilla bug for another day. =) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: It would be great if gpg-agent could be automatically started at X start when people use kmail AEGYTEN crypto plugins. The attached patch and script I currently use could make it. The patch ensure that if the script is installed it is run in the current shell context (this is very important to get the GPG_AGENT_INFO env variable available on the desktop) The script kills all previous gpg-agent process for the user login in and starts a new one, exporting the correct env variable.
[Cooker] [Bug 5259] [newpg] New: gpg-agent should support ssh-agent-like 'exec'ing
http://qa.mandrakesoft.com/show_bug.cgi?id=5259 Product: newpg Component: program Summary: gpg-agent should support ssh-agent-like 'exec'ing Product: newpg Version: 0.9.4-2mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] One of the greatest things about ssh-agent is that it can exec another program transparently. I *often* end up running things like: ssh-agent startx or ssh-agent bash ... in fact, Mandrake's init scripts are smart enough to ssh-agent your whole session this way if it's installed. This is wonderful! gpg-agent, on the other hand, is a little trickier to use. It operates in the other mode that ssh-agent supports, which is to daemonize and spit out an environment variables. This works okay, but to get the above uses, I have to do: eval `gpg-agent --daemon` startx and then when X exists, if I wanted gpg-agent to only live for the scope of that session, I have to now find and kill it. Or save the pid and kill that, or do a messy killall. Accordingly, if I want to *only* have a gpg-agent work for the life of a shell, I have to do something like: eval `gpg-agent --daemon` bash killall gpg-agent So, SUGGESTION: Let's support gpg-agent startx or gpg-agent bash gpg-agent in this case can work like ssh-agent does. Set up it's environment internally, then fork and exec the given command, then when that process ends, exit. Thus, we have a nice encapsulated contex for gpg-agent with a known lifespan, without any external messiness. This also means I could now easily do: gpg-agent ssh-agent startx or ssh-agent gpg-agent bash This is very clean and nice. =) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 2493] [xinitrc] automatic gpg-agent startup for X
http://qa.mandrakesoft.com/show_bug.cgi?id=2493 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 19:10 --- If this bug (that I just filed) was fixed first, it would save a lot of hassle, and the Xsession could be implemented *exactly* the same way that ssh-agent is now: http://qa.mandrakesoft.com/show_bug.cgi?id=5259 If you agree, vote of that one too! =) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: It would be great if gpg-agent could be automatically started at X start when people use kmail AEGYTEN crypto plugins. The attached patch and script I currently use could make it. The patch ensure that if the script is installed it is run in the current shell context (this is very important to get the GPG_AGENT_INFO env variable available on the desktop) The script kills all previous gpg-agent process for the user login in and starts a new one, exporting the correct env variable.
[Cooker] [Bug 5259] [newpg] gpg-agent should support ssh-agent-like 'exec'ing
http://qa.mandrakesoft.com/show_bug.cgi?id=5259 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 19:57 --- Well, with ssh-agent currently, if I do: $ ssh-agent tcsh (now inside the spawned tcsh): $ killall ssh-agent ssh-agent dies, but nothing bad happens to tcsh (or bash, or startx or anything else I've tried) Also a clairification: gpg-agent --daemon command does in fact run command. However, unlike ssh-agent, gpg-agent stays alive indefinately after command exits. I guess what would be nice is additional symantics like: gpg-agent --exec command Where it would start gpg-agent, run the command, and exit gpg-agent when the command finishes (this is how ssh-agent currently works if used in this mode). -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: One of the greatest things about ssh-agent is that it can exec another program transparently. I *often* end up running things like: ssh-agent startx or ssh-agent bash ... in fact, Mandrake's init scripts are smart enough to ssh-agent your whole session this way if it's installed. This is wonderful! gpg-agent, on the other hand, is a little trickier to use. It operates in the other mode that ssh-agent supports, which is to daemonize and spit out an environment variables. This works okay, but to get the above uses, I have to do: eval `gpg-agent --daemon` startx and then when X exists, if I wanted gpg-agent to only live for the scope of that session, I have to now find and kill it. Or save the pid and kill that, or do a messy killall. Accordingly, if I want to *only* have a gpg-agent work for the life of a shell, I have to do something like: eval `gpg-agent --daemon` bash killall gpg-agent So, SUGGESTION: Let's support gpg-agent startx or gpg-agent bash gpg-agent in this case can work like ssh-agent does. Set up it's environment internally, then fork and exec the given command, then when that process ends, exit. Thus, we have a nice encapsulated contex for gpg-agent with a known lifespan, without any external messiness. This also means I could now easily do: gpg-agent ssh-agent startx or ssh-agent gpg-agent bash This is very clean and nice. =)
[Cooker] [Bug 5259] [newpg] gpg-agent should support ssh-agent-like 'exec'ing
http://qa.mandrakesoft.com/show_bug.cgi?id=5259 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 20:11 --- Created an attachment (id=746) -- (http://qa.mandrakesoft.com/attachment.cgi?id=746action=view) Wrapper script that would do the trick Hmmm... well, maybe it's not as good as a patch to the source (which I was considering), but here is a small wrapper shell script that will give the right kind of semantics and isn't as intrusive. This will let you run: gpg-agent-exec command A gpg-agent will be started that is just in the context of that command, and when command is finished, the corresponding gpg-agent will be stopped. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: One of the greatest things about ssh-agent is that it can exec another program transparently. I *often* end up running things like: ssh-agent startx or ssh-agent bash ... in fact, Mandrake's init scripts are smart enough to ssh-agent your whole session this way if it's installed. This is wonderful! gpg-agent, on the other hand, is a little trickier to use. It operates in the other mode that ssh-agent supports, which is to daemonize and spit out an environment variables. This works okay, but to get the above uses, I have to do: eval `gpg-agent --daemon` startx and then when X exists, if I wanted gpg-agent to only live for the scope of that session, I have to now find and kill it. Or save the pid and kill that, or do a messy killall. Accordingly, if I want to *only* have a gpg-agent work for the life of a shell, I have to do something like: eval `gpg-agent --daemon` bash killall gpg-agent So, SUGGESTION: Let's support gpg-agent startx or gpg-agent bash gpg-agent in this case can work like ssh-agent does. Set up it's environment internally, then fork and exec the given command, then when that process ends, exit. Thus, we have a nice encapsulated contex for gpg-agent with a known lifespan, without any external messiness. This also means I could now easily do: gpg-agent ssh-agent startx or ssh-agent gpg-agent bash This is very clean and nice. =)
[Cooker] [Bug 2493] [xinitrc] automatic gpg-agent startup for X
http://qa.mandrakesoft.com/show_bug.cgi?id=2493 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 20:17 --- This isn't the keychain solution Buchan mentioned, but if we add the script gpg-agent-exec to the newpg package (see the attachment on https://qa.mandrakesoft.com/show_bug.cgi?id=5259), this would allow the Xsession to be really simple: just add gpg-agent-exec to $AGENT (like ssh-agent is). This is a less-than perfect solution, since it does add an extra shell process that hangs around... but if bug 5259 gets fixed in gpg-agent itself, that would go away. I'm not familiar with keychain, so I'll have to look at that more before I can comment much about that. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: It would be great if gpg-agent could be automatically started at X start when people use kmail AEGYTEN crypto plugins. The attached patch and script I currently use could make it. The patch ensure that if the script is installed it is run in the current shell context (this is very important to get the GPG_AGENT_INFO env variable available on the desktop) The script kills all previous gpg-agent process for the user login in and starts a new one, exporting the correct env variable.
[Cooker] [Bug 2493] [xinitrc] automatic gpg-agent startup for X
http://qa.mandrakesoft.com/show_bug.cgi?id=2493 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 20:29 --- From the last xinitrc CHRPM: -=-=-=- Frederic Lepied [EMAIL PROTECTED] 2.4.4-76mdk - enable to source /etc/X11/xinit.d scripts if they contain the special comment # to be sourced (bug #2493) I guess this means that now we *can* just drop something in xinit.d. Notice it even references this bug. =) Okay, to summarize: In the short term, I guess the fix should be to just put a gpg-agent script in xinit.d -- this script should appropriately start (or not) gpg-agent and set the correct environment variables. This will fix this bug and also 1292. In the longer term, Buchan has recommended keychain as a way to do things better than ssh-agent and gpg-agent currently do. I don't know much about keychain at the moment, so I'll go research it some, as it sounds nice. I guess we probably ought to move discussion for a keychain-based solution to cooker or file a wishlist bug against the keychain package (for gpg-agent support). -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: It would be great if gpg-agent could be automatically started at X start when people use kmail AEGYTEN crypto plugins. The attached patch and script I currently use could make it. The patch ensure that if the script is installed it is run in the current shell context (this is very important to get the GPG_AGENT_INFO env variable available on the desktop) The script kills all previous gpg-agent process for the user login in and starts a new one, exporting the correct env variable.
[Cooker] [Bug 5258] [subversion-client-common] ra modules aren't loaded - missing .so link
http://qa.mandrakesoft.com/show_bug.cgi?id=5258
--- Additional Comments From [EMAIL PROTECTED] 2003-04-09 21:32 ---
It seems like just including the .so's in the packages would be enough to fix
it.
I grabbed the SRPM and tried the following patch:
--- subversion.spec 2003-09-02 06:49:18.0 -0600
+++ subversion.new.spec 2003-09-04 11:47:01.0 -0600
@@ -51,5 +51,5 @@
Name: %{rname}
Version: %{rversion}
-Release: 1mdk
+Release: 2mdk
License: BSD
Group: Development/Other
@@ -465,5 +465,5 @@
%attr(0755,root,root) %{_libdir}/libsvn_client*so.*
#%attr(0755,root,root) %{_libdir}/libsvn_ra-*.so
-%attr(0755,root,root) %{_libdir}/libsvn_ra-*so.*
+%attr(0755,root,root) %{_libdir}/libsvn_ra-*so*
%attr(0644,root,root) %{_mandir}/man1/svn.1*
@@ -471,10 +471,10 @@
%defattr(0644,root,root,0755)
#%attr(0755,root,root) %{_libdir}/libsvn_ra_local-*.so
-%attr(0755,root,root) %{_libdir}/libsvn_ra_local-*so.*
+%attr(0755,root,root) %{_libdir}/libsvn_ra_local-*so*
%files client-dav
%defattr(0644,root,root,0755)
#%attr(0755,root,root) %{_libdir}/libsvn_ra_dav-*.so
-%attr(0755,root,root) %{_libdir}/libsvn_ra_dav-*so.*
+%attr(0755,root,root) %{_libdir}/libsvn_ra_dav-*so*
%files python
@@ -516,4 +516,8 @@
%changelog
+* Thu Sep 04 2003 Wesley J. Landaker [EMAIL PROTECTED] 0.28.1-2mdk
+- include ra_*.so files, and not just the ra_*.so.0 ones
+- close #5258
+
* Tue Sep 02 2003 Oden Eriksson [EMAIL PROTECTED] 0.28.1-1mdk
- 0.28.1
However, I can't built it because all the files in /usr/include/apr-0 are
missing... and urpmf doesn't think that anything provides those... and there is
no libapr0-devel... ?!
Anyway, if I build straight from the subversion sources, it does make the .so
links, so I think the problem is just that they aren't being included.
As for the build problems, is this because of a package change in apache or
apr? I see that /usr/include/apache2 *does* contain all the apr headers...
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: ASSIGNED
creation_date:
description:
I'm filling this against subversion-client-common, but it actually applies to
the subversion-client-local and subversion-client-dav as well.
Here is the bug and a possible fix:
If you try to use svn, it won't be able to use any transports, because it
can't load the ra modules it needs. You can tell the problem pretty easily:
$ svn --version
svn, version 0.28.1 (r6906)
compiled Sep 2 2003, 14:53:52
Copyright (C) 2000-2003 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
The following repository access (RA) modules are available:
(Well, NONE are listed!)
The problem can be seen if you do an 'strace svn --version': I won't paste it
here, but basically svn is looked all over the place for it's ra modules named
.so but there is no symlink to .so for any of the transports, only
.so.0's.
I fixed this on my system by just doing:
$ cd /usr/lib
$ ln -s libsvn_ra_dav-1.so.0 libsvn_ra_dav-1.so
$ ln -s libsvn_ra_svn-1.so.0 libsvn_ra_svn-1.so
$ ln -s libsvn_ra_local-1.so.0 libsvn_ra_local-1.so
And now:
$ svn --version
svn, version 0.28.1 (r6906)
compiled Sep 2 2003, 14:53:52
Copyright (C) 2000-2003 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
The following repository access (RA) modules are available:
* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' schema
- handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
- handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' schema
So it looks like either those .so symlinks need to be packaged, or svn needs
to be compiled in such a way that it looks for the .so.0 files when doing
dynamic loading of the ra modules.
BTW, despite the flurry of subversion bugs lately, the packaging of it has
been getting immensely better. Keep up the good work! =)
[Cooker] [Bug 5265] [apache2-devel] New: apr-config --includedir gives the wrong directory
http://qa.mandrakesoft.com/show_bug.cgi?id=5265 Product: apache2-devel Component: program Summary: apr-config --includedir gives the wrong directory Product: apache2-devel Version: 2.0.47-5mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] apr-config --includedir gives $ apr-config --includedir /usr/include/apr-0 However, there is nothing in /usr/include/apr-0 anymore. It appears that all the apr headers are actually found under /usr/include/apache2 -- if this is correct, apr-config needs to be updated. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5258] [subversion-client-common] ra modules aren't loaded - missing .so link
http://qa.mandrakesoft.com/show_bug.cgi?id=5258 [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||5265 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 21:38 --- Okay, apr-config --include gives the wrong path. That's what's screwing things up. I filed a bug and made this bug depend on it. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: I'm filling this against subversion-client-common, but it actually applies to the subversion-client-local and subversion-client-dav as well. Here is the bug and a possible fix: If you try to use svn, it won't be able to use any transports, because it can't load the ra modules it needs. You can tell the problem pretty easily: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: (Well, NONE are listed!) The problem can be seen if you do an 'strace svn --version': I won't paste it here, but basically svn is looked all over the place for it's ra modules named .so but there is no symlink to .so for any of the transports, only .so.0's. I fixed this on my system by just doing: $ cd /usr/lib $ ln -s libsvn_ra_dav-1.so.0 libsvn_ra_dav-1.so $ ln -s libsvn_ra_svn-1.so.0 libsvn_ra_svn-1.so $ ln -s libsvn_ra_local-1.so.0 libsvn_ra_local-1.so And now: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' schema - handles 'https' schema * ra_local : Module for accessing a repository on local disk. - handles 'file' schema * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' schema So it looks like either those .so symlinks need to be packaged, or svn needs to be compiled in such a way that it looks for the .so.0 files when doing dynamic loading of the ra modules. BTW, despite the flurry of subversion bugs lately, the packaging of it has been getting immensely better. Keep up the good work! =)
[Cooker] [Bug 5258] [subversion-client-common] ra modules aren't loaded - missing .so link
http://qa.mandrakesoft.com/show_bug.cgi?id=5258 [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn|5265| --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 22:02 --- Uh... looks like experimenting with the upstream source messed me up. My fault! There isn't a problem with apr-config. Okay, let me repent of my evils and see if this works now. =) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: I'm filling this against subversion-client-common, but it actually applies to the subversion-client-local and subversion-client-dav as well. Here is the bug and a possible fix: If you try to use svn, it won't be able to use any transports, because it can't load the ra modules it needs. You can tell the problem pretty easily: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: (Well, NONE are listed!) The problem can be seen if you do an 'strace svn --version': I won't paste it here, but basically svn is looked all over the place for it's ra modules named .so but there is no symlink to .so for any of the transports, only .so.0's. I fixed this on my system by just doing: $ cd /usr/lib $ ln -s libsvn_ra_dav-1.so.0 libsvn_ra_dav-1.so $ ln -s libsvn_ra_svn-1.so.0 libsvn_ra_svn-1.so $ ln -s libsvn_ra_local-1.so.0 libsvn_ra_local-1.so And now: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' schema - handles 'https' schema * ra_local : Module for accessing a repository on local disk. - handles 'file' schema * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' schema So it looks like either those .so symlinks need to be packaged, or svn needs to be compiled in such a way that it looks for the .so.0 files when doing dynamic loading of the ra modules. BTW, despite the flurry of subversion bugs lately, the packaging of it has been getting immensely better. Keep up the good work! =)
[Cooker] [Bug 5265] [apache2-devel] apr-config --includedir gives the wrong directory
http://qa.mandrakesoft.com/show_bug.cgi?id=5265 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 22:03 --- Apparently compiling subversion from the base source also messed up my apr-config. This is my fault, sorry. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: apr-config --includedir gives $ apr-config --includedir /usr/include/apr-0 However, there is nothing in /usr/include/apr-0 anymore. It appears that all the apr headers are actually found under /usr/include/apache2 -- if this is correct, apr-config needs to be updated.
[Cooker] [Bug 5258] [subversion-client-common] ra modules aren't loaded - missing .so link
http://qa.mandrakesoft.com/show_bug.cgi?id=5258 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 22:23 --- Created an attachment (id=750) -- (http://qa.mandrakesoft.com/attachment.cgi?id=750action=view) SPEC file patch that works for me This spec file patch works for me here just fine after getting rid of my bad apr-config cruft that was lying around. As you can see from the patch, basically I just told it to include *so* instead of *so.* where appropriate. After building with this svn --version shows all three ra transports as being available (local, dav, and svn). -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: I'm filling this against subversion-client-common, but it actually applies to the subversion-client-local and subversion-client-dav as well. Here is the bug and a possible fix: If you try to use svn, it won't be able to use any transports, because it can't load the ra modules it needs. You can tell the problem pretty easily: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: (Well, NONE are listed!) The problem can be seen if you do an 'strace svn --version': I won't paste it here, but basically svn is looked all over the place for it's ra modules named .so but there is no symlink to .so for any of the transports, only .so.0's. I fixed this on my system by just doing: $ cd /usr/lib $ ln -s libsvn_ra_dav-1.so.0 libsvn_ra_dav-1.so $ ln -s libsvn_ra_svn-1.so.0 libsvn_ra_svn-1.so $ ln -s libsvn_ra_local-1.so.0 libsvn_ra_local-1.so And now: $ svn --version svn, version 0.28.1 (r6906) compiled Sep 2 2003, 14:53:52 Copyright (C) 2000-2003 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' schema - handles 'https' schema * ra_local : Module for accessing a repository on local disk. - handles 'file' schema * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' schema So it looks like either those .so symlinks need to be packaged, or svn needs to be compiled in such a way that it looks for the .so.0 files when doing dynamic loading of the ra modules. BTW, despite the flurry of subversion bugs lately, the packaging of it has been getting immensely better. Keep up the good work! =)
[Cooker] [Bug 5220] [gcc-c++] ICE in lookup_template_function at cp/pt.c:4005
http://qa.mandrakesoft.com/show_bug.cgi?id=5220 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #730 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2003-03-09 18:12 --- Created an attachment (id=733) -- (http://qa.mandrakesoft.com/attachment.cgi?id=733action=view) Maybe it will really get attached this time? Odd, it uploaded fine on the gcc bugzilla site. Well, let's try it again and see if it works. =) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: Compiling some code with some partially specialized templates causes and ICE. The code itself may be incorrect in some way, but it shouldn't cause an ICE. Here is the appropriate info. I will attach the preprocessed source in just a moment (there doesn't seem to be a way to do it from this bugzilla screen). $ g++ -o test Convert.ii -v Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk) /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/cc1plus -fpreprocessed Convert.ii -quiet -dumpbase Convert.ii -auxbase Convert -version -o /tmp/ccBkAw2p.s GNU C++ version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk) (i586-mandrake-linux-gnu) compiled by GNU C version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk). GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48162 Convert.cpp:14: internal compiler error: in lookup_template_function, at cp/pt.c:4005 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. I also reported this to the GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12146
[Cooker] [Bug 5220] [gcc-c++] ICE in lookup_template_function at cp/pt.c:4005
http://qa.mandrakesoft.com/show_bug.cgi?id=5220
--- Additional Comments From [EMAIL PROTECTED] 2003-03-09 18:16 ---
BTW, the code is actually bad; there is a stray template in this snippet
(from Convert.ii -- line no ~17495)
template
Value convert_std__string(const std::string ) {
return Value(rb_str_new(s.data(), s.length()));
}
That doesn't forgive the ICE, but hopefully will make it easier to track down.
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: NEEDINFO
creation_date:
description:
Compiling some code with some partially specialized templates causes and ICE.
The code itself may be incorrect in some way, but it shouldn't cause an ICE.
Here is the appropriate info. I will attach the preprocessed source in just a
moment (there doesn't seem to be a way to do it from this bugzilla screen).
$ g++ -o test Convert.ii -v
Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking --enable-long-long
--enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal
--host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk)
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/cc1plus -fpreprocessed
Convert.ii -quiet -dumpbase Convert.ii -auxbase Convert -version -o
/tmp/ccBkAw2p.s
GNU C++ version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk) (i586-mandrake-linux-gnu)
compiled by GNU C version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk).
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48162
Convert.cpp:14: internal compiler error: in lookup_template_function, at
cp/pt.c:4005
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:https://qa.mandrakesoft.com/ for instructions.
I also reported this to the GCC bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12146
[Cooker] [Bug 5220] [gcc-c++] New: ICE in lookup_template_function at cp/pt.c:4005
http://qa.mandrakesoft.com/show_bug.cgi?id=5220 Product: gcc-c++ Component: program Summary: ICE in lookup_template_function at cp/pt.c:4005 Product: gcc-c++ Version: 3.3.1-2mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Compiling some code with some partially specialized templates causes and ICE. The code itself may be incorrect in some way, but it shouldn't cause an ICE. Here is the appropriate info. I will attach the preprocessed source in just a moment (there doesn't seem to be a way to do it from this bugzilla screen). $ g++ -o test Convert.ii -v Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk) /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/cc1plus -fpreprocessed Convert.ii -quiet -dumpbase Convert.ii -auxbase Convert -version -o /tmp/ccBkAw2p.s GNU C++ version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk) (i586-mandrake-linux-gnu) compiled by GNU C version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk). GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48162 Convert.cpp:14: internal compiler error: in lookup_template_function, at cp/pt.c:4005 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. I also reported this to the GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12146 -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5220] [gcc-c++] ICE in lookup_template_function at cp/pt.c:4005
http://qa.mandrakesoft.com/show_bug.cgi?id=5220 --- Additional Comments From [EMAIL PROTECTED] 2003-03-09 02:21 --- Created an attachment (id=730) -- (http://qa.mandrakesoft.com/attachment.cgi?id=730action=view) This is the preprocessed source that makes it ICE. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Compiling some code with some partially specialized templates causes and ICE. The code itself may be incorrect in some way, but it shouldn't cause an ICE. Here is the appropriate info. I will attach the preprocessed source in just a moment (there doesn't seem to be a way to do it from this bugzilla screen). $ g++ -o test Convert.ii -v Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk) /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/cc1plus -fpreprocessed Convert.ii -quiet -dumpbase Convert.ii -auxbase Convert -version -o /tmp/ccBkAw2p.s GNU C++ version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk) (i586-mandrake-linux-gnu) compiled by GNU C version 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk). GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48162 Convert.cpp:14: internal compiler error: in lookup_template_function, at cp/pt.c:4005 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. I also reported this to the GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12146
[Cooker] [Bug 4066] [subversion-repos] updating subversion via urpmi gives errors
http://qa.mandrakesoft.com/show_bug.cgi?id=4066 --- Additional Comments From [EMAIL PROTECTED] 2003-29-08 23:11 --- Not to mention that 0.28.0 is already out (but the filesystem schema is not the same, you have to svndump and svnload) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: [EMAIL PROTECTED] joe]$ sudo /usr/sbin/urpmi subversion-repos To satisfy dependencies, the following packages are going to be installed (10 MB): ADVX-build-9.2-1mdk.noarch apache2-devel-2.0.46-3mdk.i586 expat-1.95.6-3mdk.i586 libexpat0-1.95.6-3mdk.i586 libexpat0-devel-1.95.6-3mdk.i586 libgdbm2-devel-1.8.0-21mdk.i586 libsasl2-2.1.13-2mdk.i586 libsasl2-devel-2.1.13-2mdk.i586 libsubversion0-0.23.0-2mdk.i586 pam-0.75-33mdk.i586 pam-devel-0.75-33mdk.i586 subversion-client-common-0.23.0-2mdk.i586 subversion-client-local-0.23.0-2mdk.i586 subversion-repos-0.23.0-2mdk.i586 Is this OK? (Y/n) y The following packages have bad signatures: /var/cache/urpmi/rpms/pam-devel-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/expat-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/ADVX-build-9.2-1mdk.noarch.rpm /var/cache/urpmi/rpms/libexpat0-devel-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-local-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsubversion0-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/pam-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/subversion-repos-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libgdbm2-devel-1.8.0-21mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-devel-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libexpat0-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/apache2-devel-2.0.46-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-common-0.23.0-2mdk.i586.rpm Do you want to continue installation ? (y/N) y installing /var/cache/urpmi/rpms/pam-devel-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/expat-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/ADVX-build-9.2-1mdk.noarch.rpm /var/cache/urpmi/rpms/libexpat0-devel-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-local-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsubversion0-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/pam-0.75-33mdk.i586.rpm /var/cache/urpmi/rpms/subversion-repos-0.23.0-2mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libgdbm2-devel-1.8.0-21mdk.i586.rpm /var/cache/urpmi/rpms/libsasl2-devel-2.1.13-2mdk.i586.rpm /var/cache/urpmi/rpms/libexpat0-1.95.6-3mdk.i586.rpm /var/cache/urpmi/rpms/apache2-devel-2.0.46-3mdk.i586.rpm /var/cache/urpmi/rpms/subversion-client-common-0.23.0-2mdk.i586.rpm Installation failed: libldap.so is needed by subversion-client-local-0.23.0-2mdk liblber.so is needed by subversion-client-local-0.23.0-2mdk libldap.so is needed by libsubversion0-0.23.0-2mdk liblber.so is needed by libsubversion0-0.23.0-2mdk libsvn_diff-1.so is needed by libsubversion0-0.23.0-2mdk libldap.so is needed by subversion-repos-0.23.0-2mdk liblber.so is needed by subversion-repos-0.23.0-2mdk libsvn_diff-1.so is needed by subversion-client-common-0.23.0-2mdk libldap.so is needed by subversion-client-common-0.23.0-2mdk liblber.so is needed by subversion-client-common-0.23.0-2mdk
[Cooker] [Bug 4879] [pysol] pysol won't start: could not find the file 'pysol_23.pyc'
http://qa.mandrakesoft.com/show_bug.cgi?id=4879 --- Additional Comments From [EMAIL PROTECTED] 2003-26-08 05:16 --- Thanks for the fix. =) About the GPL issue I mentioned: It doesn't matter whether the sources the author provides have a Makefile to create the pysol_23.pyc -- the GPL still requires the distribution of the source files when distribute binaries, even if they are available from some third party. Anyway, I'm not the copyright holder, and if the author of pysol (or it's GPL'd libraries that it uses) doesn't say anything, then nobody is going to bother you about the violation. But as a Linux distributor, doesn't it seem like the right thing to do to follow the GPL, whether or not an author complains? It really doesn't look good when Linux distributions violate the GPL. =( BTW, the README from the source package says that the pysol_23.pyc is basically just a compiled concatination of the files--it doesn't give instructions how to do this, but it seems straightforward. If you don't want to build the .pyc from the sources, you ought to just include them in the /usr/share/doc tree instead. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: When trying to start pysol, it fails with the following message: $ pysol /usr/games/pysol: could not find the file 'pysol_23.pyc' !
[Cooker] [Bug 4879] [pysol] New: pysol won't start: could not find the file 'pysol_23.pyc'
http://qa.mandrakesoft.com/show_bug.cgi?id=4879 Product: pysol Component: program Summary: pysol won't start: could not find the file 'pysol_23.pyc' Product: pysol Version: 4.81-4mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When trying to start pysol, it fails with the following message: $ pysol /usr/games/pysol: could not find the file 'pysol_23.pyc' ! -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4879] [pysol] pysol won't start: could not find the file 'pysol_23.pyc'
http://qa.mandrakesoft.com/show_bug.cgi?id=4879 --- Additional Comments From [EMAIL PROTECTED] 2003-25-08 03:36 --- Hmmm... interestingly enough, the pysol SRPM doesn't contain the pysol source code, it only contains the byte-compiled version. This means not only that it can't be rebuilt to work with Python 2.3, but unless Mandrake distributes the real pysol source code somewhere, this is actually a GPL violation. Might wanna fix that. =) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: When trying to start pysol, it fails with the following message: $ pysol /usr/games/pysol: could not find the file 'pysol_23.pyc' !
[Cooker] [Bug 4879] [pysol] pysol won't start: could not find the file 'pysol_23.pyc'
http://qa.mandrakesoft.com/show_bug.cgi?id=4879 --- Additional Comments From [EMAIL PROTECTED] 2003-25-08 03:27 --- I think the problem is that the changelog says: * Tue Aug 12 2003 Per ?vind Karlsen [EMAIL PROTECTED] 4.81-4mdk - rebuild for new python But: $ rpm -ql pysol | grep pyc /usr/share/games/pysol/pysol_15.pyc /usr/share/games/pysol/pysol_16.pyc /usr/share/games/pysol/pysol_20.pyc /usr/share/games/pysol/pysol_21.pyc /usr/share/games/pysol/pysol_22.pyc (Notice there is no pysol_23.pyc included!) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: When trying to start pysol, it fails with the following message: $ pysol /usr/games/pysol: could not find the file 'pysol_23.pyc' !
[Cooker] [Bug 4594] [gaim] gaim encryption is completely missing
http://qa.mandrakesoft.com/show_bug.cgi?id=4594 --- Additional Comments From [EMAIL PROTECTED] 2003-10-08 19:13 --- The deaddog packages fix this. There is no -2mdk on Mandrake servers, at least not as of 1 second ago, so marking this as resolved is probably premature. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: After upgrading to gaim-0.66-1mdk, the gaim encryption plugin is completely missing. It's not in the plugin's menu, and $ rpm -q gaim gaim-0.66-1mdk $ rpm -q libgaim-remote0 libgaim-remote0-0.66-1mdk Oddly enough, the .so seems to be there: $ rpm -ql gaim | grep encrypt /usr/lib/gaim/encrypt.so But it doesn't show up in the plugins menu, and when someone tries to communicate with you using gaim-encryption, you get the please install gaim-encryption message.
[Cooker] [Bug 4594] [gaim] gaim encryption is completely missing
http://qa.mandrakesoft.com/show_bug.cgi?id=4594 --- Additional Comments From [EMAIL PROTECTED] 2003-10-08 19:30 --- Well, I saw a -2mdk annoucement on cooker, so perhaps it really is fixed. I'll try the official packages once they hit the mirrors and see. ;) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: After upgrading to gaim-0.66-1mdk, the gaim encryption plugin is completely missing. It's not in the plugin's menu, and $ rpm -q gaim gaim-0.66-1mdk $ rpm -q libgaim-remote0 libgaim-remote0-0.66-1mdk Oddly enough, the .so seems to be there: $ rpm -ql gaim | grep encrypt /usr/lib/gaim/encrypt.so But it doesn't show up in the plugins menu, and when someone tries to communicate with you using gaim-encryption, you get the please install gaim-encryption message.
[Cooker] [Bug 4594] [gaim] New: gaim encryption is completely missing
http://qa.mandrakesoft.com/show_bug.cgi?id=4594 Product: gaim Component: packaging Summary: gaim encryption is completely missing Product: gaim Version: 0.66-1mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After upgrading to gaim-0.66-1mdk, the gaim encryption plugin is completely missing. It's not in the plugin's menu, and $ rpm -q gaim gaim-0.66-1mdk $ rpm -q libgaim-remote0 libgaim-remote0-0.66-1mdk Oddly enough, the .so seems to be there: $ rpm -ql gaim | grep encrypt /usr/lib/gaim/encrypt.so But it doesn't show up in the plugins menu, and when someone tries to communicate with you using gaim-encryption, you get the please install gaim-encryption message. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4235] [Bugzilla] my bugs should only list bugs that're assigned to me
http://qa.mandrakesoft.com/show_bug.cgi?id=4235 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 19:02 --- If this change were to be made, it had best be configurable. What one expects to get when they ask for My Bugs is quite a bit different depending on if you are a developer who is fixing lots of bugs or a user who is reporting lots of bugs. Sometimes, you are both. Because I'm not a Mandrake developer, but instead an avid cooker tester, when I click on My Bugs, I want to have a list of all the bugs I've reported--so I can make sure they still exist in new versions, add more info about them, etc, etc. Anyway, I have no problem with the current behavior, but I can certainly see the advantage if the query for My Bugs were configurable, or instead, if there were simply separate My Bugs and a My Bug Reports sections. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: the my bugs link currently list both: - bugs that're assigned to me - bugs that i've reported i do think that bugzilla should only list bugs that're assigned to me in that page. the query must be altered
[Cooker] [Bug 4220] [lyx] New: libaiksaurus-1.0_0 and libAiksaurus0 interact weirdly with lyx
http://qa.mandrakesoft.com/show_bug.cgi?id=4220 Product: lyx Component: packaging Summary: libaiksaurus-1.0_0 and libAiksaurus0 interact weirdly with lyx Product: lyx Version: 1.3.2-2mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I can run this all day long and it will never resolve. Apparently both packages obsolete each other or something: - (h:626) (j:0) (s:0) -- (10:23 AM) (Sun Jul 20) - [EMAIL PROTECTED] /home/wjl]$ urpmi lyx To satisfy dependencies, the following packages are going to be installed (18 MB): libAiksaurus0-0.15-2mdk.i586 lyx-1.3.2-2mdk.i586 Is this OK? (Y/n) y installing //data/mirrors/Mandrake-devel/cooker/i586/Mandrake/RPMS2/libAiksaurus0-0.15-2mdk.i586.rpm //data/mirrors/Mandrake-devel/cooker/i586/Mandrake/RPMS/lyx-1.3.2-2mdk.i586.rpm Preparing...## 1:libAiksaurus0 ## 2:lyx## - (h:627) (j:0) (s:0) -- (10:38 AM) (Sun Jul 20) - [EMAIL PROTECTED] /home/wjl]$ urpmi --auto-select The following packages have to be removed for others to be upgraded: lyx-1.3.2-2mdk.i586 (due to missing libAiksaurus.so.0) (y/N) y To satisfy dependencies, the following packages are going to be installed (0 MB): libaiksaurus-1.0_0-1.0.1-1mdk.i586 Is this OK? (Y/n) y installing //data/mirrors/Mandrake-devel/cooker/i586/Mandrake/RPMS2/libaiksaurus-1.0_0-1.0.1-1mdk.i586.rpm urpmi lyx Preparing...## 1:libaiksaurus-1.0_0 ## - (h:628) (j:0) (s:0) -- (10:42 AM) (Sun Jul 20) - [EMAIL PROTECTED] /home/wjl]$ urpmi lyx To satisfy dependencies, the following packages are going to be installed (18 MB): libAiksaurus0-0.15-2mdk.i586 lyx-1.3.2-2mdk.i586 Is this OK? (Y/n) y installing //data/mirrors/Mandrake-devel/cooker/i586/Mandrake/RPMS2/libAiksaurus0-0.15-2mdk.i586.rpm //data/mirrors/Mandrake-devel/cooker/i586/Mandrake/RPMS/lyx-1.3.2-2mdk.i586.rpm Preparing...## 1:libAiksaurus0 ## % -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4222] [frozen-bubble] New: frozen-bubble requires gimp and gimp-perl?!
http://qa.mandrakesoft.com/show_bug.cgi?id=4222 Product: frozen-bubble Component: packaging Summary: frozen-bubble requires gimp and gimp-perl?! Product: frozen-bubble Version: 1.0.0-3mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For some reason, frozen-bubble recently started depending on the gimp and gimp-perl packages. This is pretty annoying, since I have gimp1_3 installed and to installed frozen-bubble, I have to --force it in, otherwise gimp1_3 gets removed when gimp-1.3 gets installed. $ rpm -q gimp1_3 gimp1_3-1.3.14-2mdk $ urpmi frozen-bubble To satisfy dependencies, the following packages are going to be installed (32 MB): frozen-bubble-1.0.0-3mdk.i586 gimp-1.2.5-3mdk.i586 gimp-perl-1.2.5-3mdk.i586 Is this OK? (Y/n) n If I rpm -Uvh --nodeps frozen-bubble in, it runs perfectly, leaving my gimp1_3 installation unscathed. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3889] [urpmi] urpme could display what it does
http://qa.mandrakesoft.com/show_bug.cgi?id=3889 --- Additional Comments From [EMAIL PROTECTED] 2003-08-07 16:47 --- If you do urpmi name it tells you what it is installing, even if it's an exact match to the name you typed and is a single package -- so it seems logical that if you do urpme name it should tell you what it is uninstalling in the same way. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: Hi, when I want to remove package and I do not know its exact name, I type 'urpme name', urpme makes its job without output, then I would like to know which package was removed, just to be sure that it removed the desired package and not some other with a similar name. Thanks, Jan Halasa
[Cooker] [Bug 3927] [gaim] [PATCH] encrypt plugin doesn't work with jabber
http://qa.mandrakesoft.com/show_bug.cgi?id=3927 [EMAIL PROTECTED] changed: What|Removed |Added Version|0.62-2mdk |0.64-1mdk --- Additional Comments From [EMAIL PROTECTED] 2003-26-06 19:08 --- This bug is still there in gaim-0.64-1mdk -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: The gaim encrypt plugin doesn't work with Jabber. It works perfectly with MSN, AIM, ICQ, and IRC. On every other transport, if you click on the Tx lock icon and send a message, it says Requesting key... and then requests the key from the other client (also gaim) and sends the message encrypted. On Jabber, if you do the same procedure, it says Requesting key... and then ... nothing. It sends some weird nonsense to the other client, but doesn't give a coherent error message or diagnostic on either end.
[Cooker] [Bug 3747] [xterm] Broken lines on all terminal emulators
http://qa.mandrakesoft.com/show_bug.cgi?id=3747 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 17:23 --- See this howto for more info on how to correctly create color prompts with bash. As was mentioned, you have to use \[ and \] around control characters so that bash can count characters correctly. http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/ Especially see: http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html Which specially talks about this issue. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: This happens on Mandrake (and maybe others) on any terminal emulator (konsole, aterm, xterm, rxvt, Eterm, etc) on Mdk9.1 and earlier versions. To reproduce it: 1. On X, open any terminal (eg. xterm). Don't maximize it. 2. Write 'top' and press ENTER. top uses all the window. 3. Maximize the window. 4. Press 'q' to quit top 5. Start writing anything until you reach the right-most part of the screen. Before reaching the right margin, the cursor will go the the beginning of the line (as if it were going to pass to the next line, but it doesn't). PS: I first thought it was due to KDE and filed a bug at http://bugs.kde.org/show_bug.cgi?id=53418See the screenshot there.
[Cooker] [Bug 4058] [gtkwave] New: gtkwave is *NOT* a sound application, it's a CAE/EDA tool.
http://qa.mandrakesoft.com/show_bug.cgi?id=4058 Product: gtkwave Component: packaging Summary: gtkwave is *NOT* a sound application, it's a CAE/EDA tool. Product: gtkwave Version: 2.0.0-0.pre3.1mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] gtkwave is packaged as being in the Sound group, and shows up under the Multimedia/Sound menu. gtkwave is *NOT* a sound application, it's a CAE/EDA tool.Perhaps this confusion arose because of the wave in the name? It is used to view graphically the output of various hardware simulation tools; these are usually called waves, but have absolutely nothing to do with sound or .wav files or anything like that. Anyway, gtkwave is an extremely useful program, but it really should be in the same group as the geda-* packages (assuming they themselves are in the correct group ;) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4037] [lyx] New: lyx includes doesn't work with sgml-tools (linuxdoc)
http://qa.mandrakesoft.com/show_bug.cgi?id=4037 Product: lyx Component: program Summary: lyx includes doesn't work with sgml-tools (linuxdoc) Product: lyx Version: 1.3.2-2mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Lyx is supposed to work with linuxdoc (see http://www.sad.it/~jug/lyx/lyxdoc/Extended/node34.html), and Lyx includes templates for linuxdoc_article and docbook_article. However, loading these templates fails when it doesn't find the right LaTeX classes. This is easily repeatable: 1. Load Lyx 2. File-New from Template 3. Double click on linuxdoc_article.lyx A box pops up saying: Textclass error The document uses an unknown textclass linuxdoc. -- substituting default. This also happens when selecting several other templates. It may be that these LaTeX classes are supposed to be included by another package, but if that is the case, I don't know where they would be: I have almost everything related to LaTeX installed on my system, as well as sgml-tools and a lot of the docbook packages. For some of the classes (i.e. the one for the IEEETrans.lyx template that also has this problem) there may be a problem with distribution because of copyrights. However, it seems logical that at least *LINUXDOC* should be supported out-of-the-box if sgml-tools and friends are all installed. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4028] [OpenOffice.org] Lost libgcc3.2 and libstdc++3.2
http://qa.mandrakesoft.com/show_bug.cgi?id=4028 --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:53 --- I'd confirm this if there were a way to. ;) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4028] [OpenOffice.org] Lost libgcc3.2 and libstdc++3.2
http://qa.mandrakesoft.com/show_bug.cgi?id=4028 --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:53 --- I'd confirm this if there were a way to. ;) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Cooker] [Bug 4028] [OpenOffice.org] Lost libgcc3.2 and libstdc++3.2
http://qa.mandrakesoft.com/show_bug.cgi?id=4028 --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:53 --- I'd confirm this if there were a way to. ;) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Cooker] [Bug 1702] [lilo] Lilo does not load successfully
http://qa.mandrakesoft.com/show_bug.cgi?id=1702 --- Additional Comments From [EMAIL PROTECTED] 2003-03-26 06:06 --- I've seen a similar problem with LILO, except instead of 99's I get 40's (i.e. L40 40 40 40 40 40... for several lines). I've seen this on several different computers that are completely different architectures (AMD's and Intels of various ages). Usually loading up the CD rescue disk and reinstalling the bootloader makes it work; sometimes I have to do that twice before it does. The only suspicious hardware that any of those computers share in common is a PCI UDMA/66 controller that comes with Maxtor 80G HD's, although I also have computers with that controller in it that have never had any lilo problems. With out lilo or anything, windows, of course, never has any problems booting---but I don't really care if windows boots. ;) Anyway, I've seen this off and on since around the Mandrake 8.2 time frame. I've also had (on the same computers) GRUB occasionally fail in a similar way (it writes GRUB then nothing, and hangs). --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Hardware Motherboard: Asus A7N8X Deluxe (w/ SATA) and nVIDIA geForce2 chipset Error: I was able to get through a complete install of linux-mandrake 9.1 beta 3. However, when I reboot my system and Lilo is attempting to load, all I see on the screen is the letter L and a pattern like this: L99 99 99 99 99 99 99 99 99 99... etc It repeats the 9's for like 5 or 6 lines. Any clues? P.S. - virus protection on board is turned off.
[Cooker] [Bug 3397] [KDE] wallpapers don't change correctly between desktops when using mixed japanese/english locale
http://qa.mandrakesoft.com/show_bug.cgi?id=3397 --- Additional Comments From [EMAIL PROTECTED] 2003-03-18 18:35 --- Another update on this: Using the ~/.i18n file that doesn't work, if I completely close all programs (so nothing is in the session) log out and log back in, and then do nothing but move between desktops, the wallpaper changes. However, as soon as I load an application (the application I tried is konqueror--I don't know if it has to be a KDE app that loads or what, I haven't too many variations--I just ran into this accidentally), it goes into broken mode. However, if I'm on, say, desktop #3 when this happens, it's locked on desktop #3's wallpaper. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I have multiple KDE desktops, each configured with different wallpaper settings. If I switch between them, the wallpaper does not change, but any apps with software transparency (i.e. konsole) are transparent to the *correct* wallpaper. This is easily repeatable and I can easily repeat this on any machine. My ~/.i18n looks like this: $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=ja_JP.UTF-8 LANGUAGE=en_US.UTF-8 LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=ja_JP.UTF-8 LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US XMODIFIERS=@im=kinput2 XIM=kinput2 XIM_PROGRAM=kinput2 This gives me english interface and units for everything, but allows the japanese input method (kinput2) to work (it also breaks handling in KDE for the multi_key, but that's another story!) Anyway, with this ~/.i18n, switching between desktops doesn't change the background wallpaper. It's really annoying. However, if I switch my ~/.i18n back to the following, it magically works again (but of course, now I can't enter japanese, which is a big problem!) $ cp ~/.i18n-en ~/.i18n $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=en_US LANGUAGE=en_US:en LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=en_US LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US
[Cooker] [Bug 3397] [KDE] New: wallpapers don't change correctly between desktops when using mixed japanese/english locale
http://qa.mandrakesoft.com/show_bug.cgi?id=3397 Product: KDE Component: KDE Summary: wallpapers don't change correctly between desktops when using mixed japanese/english locale Version: 3.1-83mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have multiple KDE desktops, each configured with different wallpaper settings. If I switch between them, the wallpaper does not change, but any apps with software transparency (i.e. konsole) are transparent to the *correct* wallpaper. This is easily repeatable and I can easily repeat this on any machine. My ~/.i18n looks like this: $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=ja_JP.UTF-8 LANGUAGE=en_US.UTF-8 LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=ja_JP.UTF-8 LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US XMODIFIERS=@im=kinput2 XIM=kinput2 XIM_PROGRAM=kinput2 This gives me english interface and units for everything, but allows the japanese input method (kinput2) to work (it also breaks handling in KDE for the multi_key, but that's another story!) Anyway, with this ~/.i18n, switching between desktops doesn't change the background wallpaper. It's really annoying. However, if I switch my ~/.i18n back to the following, it magically works again (but of course, now I can't enter japanese, which is a big problem!) $ cp ~/.i18n-en ~/.i18n $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=en_US LANGUAGE=en_US:en LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=en_US LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3397] [KDE] wallpapers don't change correctly between desktops when using mixed japanese/english locale
http://qa.mandrakesoft.com/show_bug.cgi?id=3397 --- Additional Comments From [EMAIL PROTECTED] 2003-03-17 16:30 --- In the ~/.i18n that doesn't work, if I change LANG=ja_JP.UTF-8 to LANG=ja_JP.UTF-8:en_US The wallpapers start changing correctly again. =) Please note, however, that this is a workaround, but the bug is still there--no locale setting should affect if desktop wallpaper renders correctly or not! --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I have multiple KDE desktops, each configured with different wallpaper settings. If I switch between them, the wallpaper does not change, but any apps with software transparency (i.e. konsole) are transparent to the *correct* wallpaper. This is easily repeatable and I can easily repeat this on any machine. My ~/.i18n looks like this: $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=ja_JP.UTF-8 LANGUAGE=en_US.UTF-8 LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=ja_JP.UTF-8 LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US XMODIFIERS=@im=kinput2 XIM=kinput2 XIM_PROGRAM=kinput2 This gives me english interface and units for everything, but allows the japanese input method (kinput2) to work (it also breaks handling in KDE for the multi_key, but that's another story!) Anyway, with this ~/.i18n, switching between desktops doesn't change the background wallpaper. It's really annoying. However, if I switch my ~/.i18n back to the following, it magically works again (but of course, now I can't enter japanese, which is a big problem!) $ cp ~/.i18n-en ~/.i18n $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=en_US LANGUAGE=en_US:en LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=en_US LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US
[Cooker] [Bug 3282] [xli] xloadimage binary is missing from xli package
http://qa.mandrakesoft.com/show_bug.cgi?id=3282
--- Additional Comments From [EMAIL PROTECTED] 2003-03-17 17:37 ---
Here is a patch for the spec. I also uploaded the SRPM into incoming.
--- xli.spec.orig 2001-10-16 09:23:57.0 -0600
+++ xli.spec2003-03-17 09:34:10.0 -0700
@@ -2,7 +2,7 @@
# one.
%define name xli
%define version 1.17.0
-%define release 4mdk
+%define release 5mdk
%define url http://pantransit.reptiles.org/prog/
Summary: XLI - X11 Image Loading Utility
@@ -58,6 +58,7 @@
ln -sf xli $RPM_BUILD_ROOT/usr/X11R6/bin/xsetbg
ln -sf xli $RPM_BUILD_ROOT/usr/X11R6/bin/xview
+ln -sf xli $RPM_BUILD_ROOT/usr/X11R6/bin/xloadimage
# quick fix for doc permissions
chmod 644 $RPM_BUILD_DIR/%{name}-%{version}/README*
@@ -67,12 +68,15 @@
%files
%defattr(-,root,root)
-%doc chkgamma.jpg README* ABOUTGAMMA ChangeLog COPYRIGHT
+%doc chkgamma.jpg README* ABOUTGAMMA COPYRIGHT
%{prefix}/bin/*
%config(noreplace) /etc/X11/app-defaults/*
%{prefix}/man/*/*
%changelog
+* Mon Mar 17 2003 Wesley J. Landaker [EMAIL PROTECTED] 1.17.0-5mdk
+- added missing link to xloadimage
+
* Tue Oct 16 2001 Renaud Chaillat [EMAIL PROTECTED] 1.17.0-4mdk
- rebuilt with libpng3
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
The xloadimage binary is missing from the xli package. This is required by gpg (gnupg)
to add a
JPG photo to a key.
xli provides xloadimage, but doesn't include it in the package.
[Cooker] [Bug 3397] [KDE] wallpapers don't change correctly between desktops when using mixed japanese/english locale
http://qa.mandrakesoft.com/show_bug.cgi?id=3397 --- Additional Comments From [EMAIL PROTECTED] 2003-03-17 17:54 --- No, the common background option is not turned on, but that would have been pretty cool if that's all it was. =) But no, this really is a bug--hence, as I said, the *transparency* of things like konsole the correct background, but the main background on the desktop doesn't update. =( Interestingly enough, though, the transparency feature in xchat shows the *incorrect* background, but is consistant with what is displayed on the screen. It seems that only KDE Konsole-type transparency (as opposed to XRender transparents on the menus, which obviously is consistant with what's on the screen) is affected. This says to me that KDE has updated it's internal this is what the desktop background image is variables so that konsole grabs the right pixmap, but what the desktop itself displays on the screen is always the wallpaper from desktop #1. Again, this change can be easily reproduced by changing nothing but the ~/.i18n file. I've reproduced this on 3 computers with different kinds of processors and different video cards. It's not just a simple bad setting. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I have multiple KDE desktops, each configured with different wallpaper settings. If I switch between them, the wallpaper does not change, but any apps with software transparency (i.e. konsole) are transparent to the *correct* wallpaper. This is easily repeatable and I can easily repeat this on any machine. My ~/.i18n looks like this: $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=ja_JP.UTF-8 LANGUAGE=en_US.UTF-8 LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=ja_JP.UTF-8 LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US XMODIFIERS=@im=kinput2 XIM=kinput2 XIM_PROGRAM=kinput2 This gives me english interface and units for everything, but allows the japanese input method (kinput2) to work (it also breaks handling in KDE for the multi_key, but that's another story!) Anyway, with this ~/.i18n, switching between desktops doesn't change the background wallpaper. It's really annoying. However, if I switch my ~/.i18n back to the following, it magically works again (but of course, now I can't enter japanese, which is a big problem!) $ cp ~/.i18n-en ~/.i18n $ cat ~/.i18n LC_TELEPHONE=en_US LC_PAPER=en_US LC_NAME=en_US LC_CTYPE=en_US LANGUAGE=en_US:en LC_NUMERIC=en_US LC_MEASUREMENT=en_US LC_MONETARY=en_US LC_TIME=en_US LANG=en_US LC_IDENTIFICATION=en_US LC_ADDRESS=en_US LC_MESSAGES=en_US LC_COLLATE=en_US
[Cooker] [Bug 3282] [xli] New: xloadimage binary is missing from xli package
http://qa.mandrakesoft.com/show_bug.cgi?id=3282 Product: xli Component: packaging Summary: xloadimage binary is missing from xli package Version: 1.17.0-4mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The xloadimage binary is missing from the xli package. This is required by gpg (gnupg) to add a JPG photo to a key. xli provides xloadimage, but doesn't include it in the package. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3282] [xli] xloadimage binary is missing from xli package
http://qa.mandrakesoft.com/show_bug.cgi?id=3282 --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 22:17 --- Okay, looking at how the program works, there isn't a seprate xloadimage binary, it just needs to be linked to xli. Adding this line to the spec fixed it: ln -sf xli $RPM_BUILD_ROOT/usr/X11R6/bin/xloadimage (Actually, and completely unrelated, I also had to remove the reference to ChangeLog as well, but that must have built on somebodies system with it there or how did we get a binary package?) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: The xloadimage binary is missing from the xli package. This is required by gpg (gnupg) to add a JPG photo to a key. xli provides xloadimage, but doesn't include it in the package.
[Cooker] [Bug 2769] [mdkkdm] mdkkdm only partly localized
http://qa.mandrakesoft.com/show_bug.cgi?id=2769 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 18:43 --- *** This bug has been confirmed by popular vote. *** --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: Posting this as a bug for lack of any official reaction on cooker-i18n :-( See URL for problem description - mdkkdm apparently isn't localized in a number of languages. The translators would like to correct this but the gettext catalogs for mdkkdm are nowhere to be found. Releasing 9.1 with a halfway localized default desktop manager would not only look bad but would also devaluate all the hard work of the volunteer translators.
[Cooker] [Bug 3172] [kernel] all interrupts routed to CPU0 cripples kernel performance
http://qa.mandrakesoft.com/show_bug.cgi?id=3172 --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 17:25 --- Everyone - I will re-post the details I sent to cooker before, and try to give more details tonight, I promise. =) I am tied up at work right now - I did post a lot of [fairly] detailed info in the cooker list yesterday; I had tried to make a bug but bugzilla was giving me problems (internal server errors) at the time. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: This bug has been signaled on cooker mailing list, I signal it on behalf of Wesley J Landaker, who could not reach Bugzilla: IO-APIC is enabled on my system, however all interrupts are routed to CPU0. This didn't used to be the case, and I see a *drastic* performance hit because of this (for instance, using mencoder to capture real-time TV I used to get 35fps, now I can't even get 20fps). It has been confirme by several people with different kernels: with standard kernel 2.4.21, I observed a very drastic performance problem with mencoder, encoding a video or TV, or encoding sound in oggvorbis (about 5 times slower). This happens also with the smp kernel, and this is even worse with the multimedia kernel.
[Cooker] [Bug 3172] [kernel] all interrupts routed to CPU0 cripples kernel performance
http://qa.mandrakesoft.com/show_bug.cgi?id=3172 --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 17:31 --- Okay, work machine, SMP, same behavior as at home. EXCEPT: this work machine is 9.0, but with the 2.4.19-24mdksmp kernel! $ cat /proc/interrupts CPU0 CPU1 0: 52397687 0IO-APIC-edge timer 1: 265376 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 1 0IO-APIC-edge serial 4: 1 0IO-APIC-edge serial 6: 81 0IO-APIC-edge floppy 8: 53359184 0IO-APIC-edge rtc 15: 78446 1IO-APIC-edge ide1 16: 2 0 IO-APIC-level ohci1394 17: 21516 0 IO-APIC-level Intel 82801BA-ICH2 19:1317838 0 IO-APIC-level usb-uhci 22: 614901 0 IO-APIC-level aic7xxx 23: 65467297 0 IO-APIC-level usb-uhci, eth0 NMI: 0 0 LOC: 52397233 52397231 ERR: 0 MIS: 0 Notice APIC is enabled; I can do the same cat trick to /proc/irq/x/smp_affinity and get the same behavior I mentioned before (CPU1 starts handling some interrupts). This machine (work)'s info: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) XEON(TM) CPU 2.40GHz stepping: 4 cpu MHz : 2392.762 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4771.02 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) XEON(TM) CPU 2.40GHz stepping: 4 cpu MHz : 2392.762 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4784.12 $ cat /var/log/dmesg Linux version 2.4.19-24mdksmp ([EMAIL PROTECTED]) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #1 SMP Thu Jan 30 10:32:17 MST 2003 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7ff77000 (usable) BIOS-e820: 7ff77000 - 7ff79000 (ACPI NVS) BIOS-e820: 7ff79000 - 8000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 000fe710 hm, page 000fe000 reserved twice. hm, page 000ff000 reserved twice. hm, page 000f reserved twice. Advanced speculative caching feature not present On node 0 totalpages: 229376 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: WS 530 APIC at: 0xFEE0 Processor #0 Unknown CPU [15:2] APIC version 20 Processor #2 Unknown CPU [15:2] APIC version 20 I/O APIC #4 Version 32 at 0xFEC0. Processors: 2 Kernel command line: BOOT_IMAGE=2419-24smp ro root=801 devfs=mount hdd=ide-scsi ide_setup: hdd=ide-scsi Initializing CPU#0 Detected 2392.762 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 4771.02 BogoMIPS Memory: 904556k/917504k available (1315k kernel code, 12564k reserved, 487k data, 140k init, 0k highmem) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode cache hash table entries: 65536 (order: 7, 524288 bytes) Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) CPU: Before vendor init, caps: 3febfbff , vendor = 0 CPU: L1 I cache: 12K, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 CPU: After vendor init, caps: 3febfbff Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 3febfbff CPU: Common caps: 3febfbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done.
[Cooker] [Bug 3172] [kernel] all interrupts routed to CPU0 cripples kernel performance
http://qa.mandrakesoft.com/show_bug.cgi?id=3172 --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 19:30 --- I tried booting with acpi=off as someone suggested; it doesn't make any difference. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: This bug has been signaled on cooker mailing list, I signal it on behalf of Wesley J Landaker, who could not reach Bugzilla: IO-APIC is enabled on my system, however all interrupts are routed to CPU0. This didn't used to be the case, and I see a *drastic* performance hit because of this (for instance, using mencoder to capture real-time TV I used to get 35fps, now I can't even get 20fps). It has been confirme by several people with different kernels: with standard kernel 2.4.21, I observed a very drastic performance problem with mencoder, encoding a video or TV, or encoding sound in oggvorbis (about 5 times slower). This happens also with the smp kernel, and this is even worse with the multimedia kernel.
[Cooker] [Bug 3172] [kernel] all interrupts routed to CPU0 cripples kernel performance
http://qa.mandrakesoft.com/show_bug.cgi?id=3172 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 04:32 --- Eric, I can confirm what you've written here: I tried reverting to as many kernels as I could try, and they all had the same (bad) performance. In addition, after using smp_affinity to make IRQ's route to both CPUs, mencoder performance didn't improve. For now, I'll see if I can get back the performance I need by recompiling from source here. However, it's still perturbing to see that by default IRQ's are not being routed to both processors when the APIC is enabled. Even if it's not the cause of this particular performance problem, it's still something that's changed for the worse. Perhaps we should open a bug just about that issue? --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: This bug has been signaled on cooker mailing list, I signal it on behalf of Wesley J Landaker, who could not reach Bugzilla: IO-APIC is enabled on my system, however all interrupts are routed to CPU0. This didn't used to be the case, and I see a *drastic* performance hit because of this (for instance, using mencoder to capture real-time TV I used to get 35fps, now I can't even get 20fps). It has been confirme by several people with different kernels: with standard kernel 2.4.21, I observed a very drastic performance problem with mencoder, encoding a video or TV, or encoding sound in oggvorbis (about 5 times slower). This happens also with the smp kernel, and this is even worse with the multimedia kernel.
[Cooker] [Bug 3172] [kernel] all interrupts routed to CPU0 cripples kernel performance
http://qa.mandrakesoft.com/show_bug.cgi?id=3172 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 05:04 --- Recompiling mplayer (tried both in plf mode and not, tried with optimizations and not) didn't help. I'll try Thomas' test kernel and see if it helps. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: This bug has been signaled on cooker mailing list, I signal it on behalf of Wesley J Landaker, who could not reach Bugzilla: IO-APIC is enabled on my system, however all interrupts are routed to CPU0. This didn't used to be the case, and I see a *drastic* performance hit because of this (for instance, using mencoder to capture real-time TV I used to get 35fps, now I can't even get 20fps). It has been confirme by several people with different kernels: with standard kernel 2.4.21, I observed a very drastic performance problem with mencoder, encoding a video or TV, or encoding sound in oggvorbis (about 5 times slower). This happens also with the smp kernel, and this is even worse with the multimedia kernel.
[Cooker] [Bug 3172] [kernel] all interrupts routed to CPU0 cripples kernel performance
http://qa.mandrakesoft.com/show_bug.cgi?id=3172 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 05:35 --- Using Thomas's kernel + mencoder recompiled has better performance, but not nearly what I used to have. I used to be able to (easily) get 30fps recording; when I first saw this problem after an update, it dropped drastically (it couldn't even sustain 15fps). Now it's pretty steady at ~20fps if nothing else is running, but can't do any better. If it makes a shred of difference, I'm using the following command, which has worked for months and months and months just fine: mencoder -tv on:driver=v4l:width=496:height=384:chanlist=us-cable:channel=3:norm=ntsc -oac copy -ovc lavc -lavcopts vcodec=mjpeg -endpos 02:20:00 Well, maybe this isn't a kernel problem and is really a library issue. I don't know: any ideas how to track it down? This computer tracks cooker more-or-less in real time. I don't just have old versions of everything lying around. =) Anyway, as far as this particular bug goes, 'cat /proc/interrupts' still shows only CPU0 getting IRQs (which still seems fishy to me) ... --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: This bug has been signaled on cooker mailing list, I signal it on behalf of Wesley J Landaker, who could not reach Bugzilla: IO-APIC is enabled on my system, however all interrupts are routed to CPU0. This didn't used to be the case, and I see a *drastic* performance hit because of this (for instance, using mencoder to capture real-time TV I used to get 35fps, now I can't even get 20fps). It has been confirme by several people with different kernels: with standard kernel 2.4.21, I observed a very drastic performance problem with mencoder, encoding a video or TV, or encoding sound in oggvorbis (about 5 times slower). This happens also with the smp kernel, and this is even worse with the multimedia kernel.
[Cooker] [Bug 3004] [cowsay] cowsay has unexpanded macro %PREFIX% in script (was: doesn't require the right perl packages)
http://qa.mandrakesoft.com/show_bug.cgi?id=3004
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-03-11 02:05 ---
Yay! It works now!
\ ^__^
\ (oo)\___
(__)\ )\/\
||w |
|| ||
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: RESOLVED
creation_date:
description:
cowsay doesn't require the right perl packages to run:
$ cowsay
/usr/bin/cowsay: line 9: syntax error near unexpected token `('
/usr/bin/cowsay: line 9: `use Text::Tabs qw(expand);'
$ rpm -q cowsay
cowsay-3.03-1mdk
(This should be filed under cowsay, but that doesn't exist in bugzilla yet.)
[Cooker] [Bug 3064] [apache-conf] New: apache-conf overwrites favicon.ico even if it's changed
http://qa.mandrakesoft.com/show_bug.cgi?id=3064 Product: apache-conf Component: packaging Summary: apache-conf overwrites favicon.ico even if it's changed Version: 2.0.44-11mdk Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] apache-conf overwrites favicon.ico even if it's changed. This is extremely annoying, because I have a special favicon.ico for my domain. Every time apache-conf gets updated, it nukes my favicon and replaces it with the packaged version. The solution is probably to just mark this as a %conf file in the spec so that if it hasn't been modified, it gets updated, but if the user has modified it, the new one comes in as an .rpmnew --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3064] [apache-conf] apache-conf overwrites favicon.ico even if it's changed
http://qa.mandrakesoft.com/show_bug.cgi?id=3064 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-10 01:53 --- Yes, I'm running the latest version and selected the right one in bugzilla. However, I just tried down-grading and then re-upgrading it and does indeed seem to do the right thing now. I must have had it nuked before this was fixed and didn't notice at the time (as there have been a few apache-conf's in a short time). Anyway, looks like this was already fixed and I was just seeing the effects of a previously bad package from a few days ago or something. I'll go ahead and mark this as fixed; but I'll keep a close eye on -12mdk. ;) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: apache-conf overwrites favicon.ico even if it's changed. This is extremely annoying, because I have a special favicon.ico for my domain. Every time apache-conf gets updated, it nukes my favicon and replaces it with the packaged version. The solution is probably to just mark this as a %conf file in the spec so that if it hasn't been modified, it gets updated, but if the user has modified it, the new one comes in as an .rpmnew
[Cooker] [Bug 3004] [cowsay] cowsay has unexpanded macro %PREFIX% in script (was: doesn't require the right perl packages)
http://qa.mandrakesoft.com/show_bug.cgi?id=3004
[EMAIL PROTECTED] changed:
What|Removed |Added
Platform|Other |PC
Summary|cowsay doesn't require the |cowsay has unexpanded macro
|right perl packages |%PREFIX% in script (was:
||doesn't require the right
||perl packages)
--- Additional Comments From [EMAIL PROTECTED] 2003-03-10 02:21 ---
Okay, different problem with -2mdk:
$ echo moo | cowsay
cowsay: Could not find default.cow cowfile!
The problem is an unexpanded macro (%PREFIX% - /usr) on this line:
-$cowpath = $ENV{'COWPATH'} || '%PREFIX%/share/cows';
cowthink has the same problem.
Changing %PREFIX% to /usr makes it work correctly.
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
cowsay doesn't require the right perl packages to run:
$ cowsay
/usr/bin/cowsay: line 9: syntax error near unexpected token `('
/usr/bin/cowsay: line 9: `use Text::Tabs qw(expand);'
$ rpm -q cowsay
cowsay-3.03-1mdk
(This should be filed under cowsay, but that doesn't exist in bugzilla yet.)
[Cooker] [Bug 3004] [cowsay] cowsay has unexpanded macro %PREFIX% in script (was: doesn't require the right perl packages)
http://qa.mandrakesoft.com/show_bug.cgi?id=3004
--- Additional Comments From [EMAIL PROTECTED] 2003-03-10 02:24 ---
Just saw the changelog message arrive 30 seconds after I submitted the last bug
update;
looks like this is fixed in -3mdk. =)
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
cowsay doesn't require the right perl packages to run:
$ cowsay
/usr/bin/cowsay: line 9: syntax error near unexpected token `('
/usr/bin/cowsay: line 9: `use Text::Tabs qw(expand);'
$ rpm -q cowsay
cowsay-3.03-1mdk
(This should be filed under cowsay, but that doesn't exist in bugzilla yet.)
[Cooker] [Bug 3004] [perl] New: cowsay doesn't require the right perl packages
http://qa.mandrakesoft.com/show_bug.cgi?id=3004
Product: perl
Component: packaging
Summary: cowsay doesn't require the right perl packages
Version: 5.8.0-19mdk
Platform: Other
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
cowsay doesn't require the right perl packages to run:
$ cowsay
/usr/bin/cowsay: line 9: syntax error near unexpected token `('
/usr/bin/cowsay: line 9: `use Text::Tabs qw(expand);'
$ rpm -q cowsay
cowsay-3.03-1mdk
(This should be filed under cowsay, but that doesn't exist in bugzilla yet.)
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3006] [Bugzilla] New: Incorrect messsage about operating systems when entering a bug about bugzilla
http://qa.mandrakesoft.com/show_bug.cgi?id=3006 Product: Bugzilla Component: Bugzilla Summary: Incorrect messsage about operating systems when entering a bug about bugzilla Version: 2.17 Platform: Other OS/Version: All Status: UNCONFIRMED Severity: trivial Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When entering a bug about Bugzilla, there is a bug. (Oh the irony! ;) Very trivial, but it says: We've made a guess at your operating system and platform. Please check them and, if we got it wrong, email [EMAIL PROTECTED] However, there *is* no option for operating system or platform, so: 1) No, you haven't made a guess (or you have and haven't told me about it), and 2) I can't check them or see if you've got them wrong. There is however, a mysterious Architecture box that lists things like DEC, HP, SGI and Sun, which obviously makes absolutely no sense at all when reporting on anything related to cooker. =) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3007] [Bugzilla] New: Bugzilla isn't updated with current cooker packages
http://qa.mandrakesoft.com/show_bug.cgi?id=3007 Product: Bugzilla Component: Bugzilla Summary: Bugzilla isn't updated with current cooker packages Version: 2.17 Platform: Other OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Bugzilla isn't updated with current cooker packages. I just tried to submit a bug for the newly added cowsay package in contribs, but it's not yet listed in bugzilla. By the time something has been added to contribs, updated into the hdlist, put on the mirrors, filtered it's way down to my local mirror and I've gotten around to reading the changelog list, seeing a notice about a new package, getting around to installing it and finding a bug and going to report it (whew!) it should also be in bugzilla! =) Anyway, since bugzilla is now the prefered method of reporting bugs, it should acurately and speedily reflect exactly what's in cooker so that bugs can be reported easily. The other solution, would be to have a not-listed category you could select in bugzilla... but perhaps that would be abused (although I kind of doubt it). --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 1179] [kdebase] Mandrake's new kdm is welcomed with extreme displeasure
https://qa.mandrakesoft.com/show_bug.cgi?id=1179 --- Additional Comments From [EMAIL PROTECTED] 2003-02-20 16:20 --- I notice this bug is marked as INVALID, yet it was only after I suggested in this bug report to put the new kdm in mdkkdm as a separate package that it was done--before that it was the default, and you *did* remove the old kdm. (Mind you, it wasn't my idea--it was suggest in cooker--but I did post it here several days before it was implemented that way--using exactly the package name I made up on-the-spot). Anyway, thank you for fixing this bug -- as in, thank you for putting mdkkdm in it's own package. I think it's great that Mandrake is taking steps to fill a need that they see for a simpler dm that can be used by default without *replacing* the more advanced features of the original kdm. However, keep in mind that what you have done is fixed a lot of the bugs people reported, acted like they never were there in the first place, then replied annoymously ([EMAIL PROTECTED] is ... who?) while trivializing the valid concerns of club members, volunteers, and stockholders, and then called the whole thing INVALID. The way to get better participating and input is to thank people for reporting bugs, not trivialize and scoff. Again, even though I think you've been a bit rude, thank you for fixing this bug -- separating the packages and perserving the original kdm is exactly what the point of this bug was. Now, let's get back to work. We've got other bugs to fix. ;) -- Wes --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: I've openned this as a bug because I think it has real usability and security problems, and because there is an easy solution: The new Mandrake kdm that removes the login text field, forces users to login in only if they are listed, and makes loging in a two-stage process is a big usability and security problem. A good solution would probably be: 1) A mdkkdm package (that can be installed by default) that has this new kdm in it (although, I surely hope that it is improved before it's used anywhere!) 2) The original unmodified (but it can be branded, as usual--we have no problem with that) kdm being installed by kdebase, and used if mdkkdm is not installed. Others have made plenty of comments in the cooker ML and can add comments here as appropriate.
