Re: [Cooker] urpmi strange output
Charles Shirley <[EMAIL PROTECTED]> writes: > With installed version: urpmi-4.4-4mdk, I update with: > > urpmi --auto-select > > which installs updated packages, but urpmi finishes up with: > > "Everything already installed" > > As though there was nothing to update, even though there were > several packages installed. This was a bug in urpmi fixed in 5mdk (now 6mdk is in cooker friday). François.
Re: [Cooker] Cooker development - how do things happen?
On Sunday 22 June 2003 08:29 pm, magic wrote: > >Simply seeking enlightment... > This won't answer all of your questions, but the cooker TWiki is a start. http://qa.mandrakesoft.com/twiki/bin/view/Main/CookerHowTo is the specific Cooker HOWTO, while http://qa.mandrakesoft.com/twiki/bin/view/Main/MandrakeLinux is more info about what is going on development wise. BTW, I am interested in what the Cooker HOWTO document should additionally address, so feedback, especially that which is critical or points out problems, is very welcome. -- Greg
[Cooker] wheel mouse Arowana
(please, have a look at the message"Missing dependencies when MakeCD" that could be the reason) on update from 9.1 (was in 9.1): wheel mouse Arowana MSWH-03 www.arowanashop.com 3 buttons yes *wheell no* (same thing for 9.1) SetMouseSettings - type: 13 brate: 1200 srate:0 chmid: 0 em3but:0 em3tim 50 res:0 flags:120 Succeeded
[Cooker] Missing dependencies when MakeCD
On update from 9.1: REJECTED master disc 1 squidGuard-1.2.0-6mdk.i586 (Missing dependencies: perl(LWP::Parallel::UserAgent)) REJECTED master disc 1 swatch-3.0.4-2mdk.noarch (Missing dependencies: perl(Bit::Vector)) REJECTED master disc 1 ucd-snmp-utils-4.2.3-6mdk.i586 (Missing dependencies: perl(Term::ReadKey)) REJECTED master disc 1 unicon-3.0.3-12mdk.i586 (Missing dependencies: libnewt.so.0.50) MakeCD sent a lot of error messages but the iso are there could you explain what's wrong here? do I forgot something?
[Cooker] install doesn't update medias
(please, have a look at the message"Missing dependencies when MakeCD" that could be the reason) On update from 9.1: Doesn't have asked me for other CD! same thing for 9.1(quick install, not checked that) but for some debian CD are read skipped stage of pakages install! install XFree and al when configure X uname "running cooker 2.4.21-0.13" on reboot urpmi only knows MDK 9.1's CD1
[Cooker] Cooker development - how do things happen?
Hello all, I've been 'lurking' on the list for about 8 months now, and providing comments (as few as they are) whenever I can. I was wondering how the development process works. Is there a centralized list (a basic todo list) for the development direction Mandrake is heading? The reason I ask, is that although I've been following the list, I can't seem to visualize the direction development is going (especially the server components). As I'm working on a corporate mailserver, I closely watch the cyrus (imap), postfix, openldap, cyrus (sasl) and other related threads. To say I've learned alot, would be an understatement. So, how does the cooker work? What decides if a package goes into main, or is a contrib? What determines if a cooker package moves into updates? And if (in the mailserver case above) how is it determined what packages are added, and when? And finally, why doesn't [EMAIL PROTECTED] .com ever answer an email? Simply seeking enlightment... Thanks, S
[Cooker] [Bug 2872] [drakxtools] XFdrake crashes during tesing when run inside X on mdk-9.1rc1/2 and 9.1 final
http://qa.mandrakesoft.com/show_bug.cgi?id=2872 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-23-06 02:42 --- > I don't understand, DrakX checks wether xfs is running, cf line 46 If it checks (as you say), why does it stop and then start the service, even after knowing that its running ? In any case, the main issue that XFdrake is crashing is still unresolved. -- 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: Start XFdrake within Xwindows from a terminal. Test the X configuration. If the test is successful, XFdrake shows a nice colorful screen and asks if the user can see it ok. Click yes/no. Now XFdrake window should reappear. However when normal screen is restored, the XFdrake window is found to have vanished. Pressing ctrl-c to interrupt the hung XFdrake process.
[Cooker] [Bug 3465] [ethemes] Do NOT package .xvpics directory
http://qa.mandrakesoft.com/show_bug.cgi?id=3465 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|UNCONFIRMED |NEW Ever Confirmed||1 Summary|.xvpics directory |Do NOT package .xvpics ||directory --- Additional Comments From [EMAIL PROTECTED] 2003-23-06 02:31 --- I still see the following .xvpics directories: /usr/X11R6/share/enlightenment/themes/Aliens/pix/bg_giger/.xvpics /usr/X11R6/share/enlightenment/themes/Aliens/pix/dragbar/.xvpics /usr/X11R6/share/enlightenment/themes/minEguE/borders/PAGER/images/.xvpics /usr/X11R6/share/enlightenment/themes/minEguE/common/images/.xvpics /usr/X11R6/share/enlightenment/themes/minEguE/epplets/images/.xvpics confirming -- 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: some temporary files were packaged by error. search the .xvpics directory in Aliens and minEguE theme
[Cooker] [Bug 3464] [enlightenment] Do NOT package .xvpics directory
http://qa.mandrakesoft.com/show_bug.cgi?id=3464 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|UNCONFIRMED |NEW Component|enlightenment |packaging Ever Confirmed||1 Summary|.xvpics directory |Do NOT package .xvpics ||directory --- Additional Comments From [EMAIL PROTECTED] 2003-23-06 02:28 --- I still see the following .xvpics directory: /usr/X11R6/share/enlightenment/themes/ShinyMetal/epplets/images/.xvpics -> packaging + confirming -- 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: some temporary files are packaged by error. just remove the .xvpics directory
[Cooker] clisp probs && maxima
when starting maxima I get this error:
clisp:
/home/peroyvind/rpm/tmp/clisp-2.30-buildroot/usr/lib/clisp/base/lisp.ru
n: No such file or directory
I edited the clisp.spec and attach the diff to the current spec. Don't
shoot me, it's late and I needed that fixed some way or another.
maxima needs a rebuild against the new clisp. And I'd love to see the
current menu entry fixed (s/Maxsima/Maxima/) or, preferably, renamed to
xmaxima.
Mark
--- clisp.spec.mdk 2003-06-17 20:15:00.0 +0200
+++ clisp.spec 2003-06-22 22:59:22.0 +0200
@@ -48,8 +48,8 @@
--fsstnd=redhat \
--host=%{_target_platform}
-(cd src
-./makemake --with-readline --with-gettext --with-dynamic-ffi --fsstnd=redhat >
Makefile
+(cd src
+./makemake --prefix=/usr --with-readline --with-gettext --with-dynamic-ffi
--fsstnd=redhat > Makefile
%make config.lisp
%make CFLAGS="-W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type
-fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE
-DDYNAMIC_FFI -DNO_SIGSEGV $RPM_OPT_FLAGS"
%make check
@@ -58,21 +58,10 @@
%install
rm -rf $RPM_BUILD_ROOT
-mkdir -p $RPM_BUILD_ROOT%_bindir
-mkdir -p $RPM_BUILD_ROOT%_libdir
-(
-cd src ;
-%makeinstall
-mkdir -p $RPM_BUILD_ROOT%_mandir
-#mv $RPM_BUILD_ROOT%_prefix/man/* $RPM_BUILD_ROOT%_mandir
-#rm -fr $RPM_BUILD_ROOT%_prefix/man
-
-mkdir -p $RPM_BUILD_ROOT%_docdir/%name
-mv $RPM_BUILD_ROOT%_prefix/doc/* $RPM_BUILD_ROOT%_docdir/%name
-rm -fr $RPM_BUILD_ROOT%_prefix/doc
-mv $RPM_BUILD_ROOT%_datadir/dvi $RPM_BUILD_ROOT%_docdir/%name/dvi
-mv $RPM_BUILD_ROOT%_datadir/html $RPM_BUILD_ROOT%_docdir/%name/html
+(
+cd src
+%makeinstall_std
)
%{find_lang} %{name}
@@ -82,14 +71,10 @@
%files -f %{name}.lang
%defattr(-,root,root)
+%doc ANNOUNCE COPYRIGHT GNU-GPL INSTALL SUMMARY src/clisp.html src/README
doc/impnotes.html doc/clisp.png
%{_bindir}/clisp
%{_libdir}/clisp
-%doc ANNOUNCE COPYRIGHT GNU-GPL INSTALL SUMMARY
-%doc src/clisp.html
-%doc src/README
-%doc src/impnotes.html src/clisp.png
-%{_docdir}/clisp
-%{_mandir}/*/*
+%{_mandir}/*
%clean
rm -fr $RPM_BUILD_ROOT
Re: [Cooker] Can't start gnome
On Sun, 2003-06-22 at 21:18, John Johnson wrote: > Apologies for the html format and yes upgrading freetype2 using MDK > packaging solved the problem. Strangely the previous installed version of > freetype2 *was* MDK's. If you run Cooker you have to run *all* Cooker. You shouldn't run some packages from a stable release and try and upgrade bits from Cooker, that isn't what it's designed for. -- adamw
[Cooker] Kernel build broken(2)
Well, It also breaks later on with /usr/src/RPM/BUILD/kernel-2.4/linux-2.4.20/drivers/net/irda/ma600.c ma600.c:189:40: pasting ";" and "return" does not give a valid preprocessing token ma600.c:303:40: pasting ";" and "return" does not give a valid preprocessing token It's nice and sunny outside, I give up. -- _ _ _ _ | |_| | |_/ | | / / -_) | / / | |_\_\___|_|_\_\_| @ sbcglobal.net signature.asc Description: This is a digitally signed message part
Re: [Cooker] Instant spam/antivirus filter for postfix(allmost.).
On Sun, Jun 08, 2003 at 12:20:10AM +0200, Troels Liebe Bentsen wrote: > Hey i have been toying with antivirus and spam filtering with postfix, > and have made some packages for mandrake, think this would make things > much easier to setup and make Mandrake more "Enterprise ready", > amavis-new scales quite well(10+ msg/day), and is running at several > large companies. > > you can urpmi it at (for 9.1): > http://tlb.rapanden.dk/RPMS/amavis-new/ > (look at the howto) Thanks a lot, I'll give it a try (when I have time :( ) If it works well, I think it would be very good to have in the next mandrake (or enterprise) version Cheers Simon
[Cooker] Kernel build broken?
Just curious, how does Juan to build an rpm? $ rpm --rebuild --with up --without smp --without secure --without enterprise --without BOOT --without minimal --without mydsdt --without debug --without doc --with source --target athlon kernel-2.4.21-0.rc1.1mdk-1-1mdk.src.rpm Using the last gcc-3.3-2mdk breaks at the atm driver stage: gcc -D__KERNEL__ -I/usr/src/RPM/BUILD/kernel-2.4/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -DMODULE -DMODVERSIONS -include /usr/src/RPM/BUILD/kernel-2.4/linux-2.4.20/include/linux/modversions.h -g -nostdinc -iwithprefix include -DKBUILD_BASENAME=ambassador -c -o ambassador.o ambassador.c ambassador.c:301:22: atmsar11. start: No such file or directory ambassador.c:302: error: parse error before ';' token ambassador.c:305:24: atmsar11. regions: No such file or directory ambassador.c:310:21: atmsar11. data: No such file or directory make[2]: *** [ambassador.o] Error 1 make[2]: Leaving directory `/usr/src/RPM/BUILD/kernel-2.4/linux-2.4.20/drivers/atm' make[1]: *** [_modsubdir_atm] Error 2 make[1]: Leaving directory `/usr/src/RPM/BUILD/kernel-2.4/linux-2.4.20/drivers' Applying this patch seems to get the build going: --- kernel-2.4/linux-2.4.20/drivers/atm/ambassador.c.orig 2003-06-22 13:19:29.0 -0700 +++ kernel-2.4/linux-2.4.20/drivers/atm/ambassador.c2003-06-22 13:19:48.0 -0700 @@ -290,12 +290,12 @@ /** microcode **/ #ifdef AMB_NEW_MICROCODE -#define UCODE(x) UCODE1(atmsar12.,x) +#define UCODE(x) UCODE1(atmsar12,x) #else -#define UCODE(x) UCODE1(atmsar11.,x) +#define UCODE(x) UCODE1(atmsar11,x) #endif #define UCODE2(x) #x -#define UCODE1(x,y) UCODE2(x y) +#define UCODE1(x,y) UCODE2(x.y) static u32 __initdata ucode_start = #include UCODE(start) -- _ _ _ _ | |_| | |_/ | | / / -_) | / / | |_\_\___|_|_\_\_| @ sbcglobal.net signature.asc Description: This is a digitally signed message part
Re: [Cooker] Can't start gnome
Apologies for the html format and yes upgrading freetype2 using MDK packaging solved the problem. Strangely the previous installed version of freetype2 *was* MDK's. - Original Message - From: "Frederic Crozat" <[EMAIL PROTECTED]> Newsgroups: liste.cooker To: <[EMAIL PROTECTED]> Sent: Sunday, June 22, 2003 3:44 AM Subject: Re: [Cooker] Can't start gnome > Le Sat, 21 Jun 2003 18:00:04 -0400, John Johnson a écrit : > > Since upgrading to the latest version of cooker (as of june 17), I'm unable= > > to start gnome. When starting gnome using startx, I get the gnome splash = > > screen and then I'm immediately dumped to the command prompt. The following= > > error message is displayed: > > gnome-session: Relocation error /usr/lib/libfontconfig.so.1: Undefined symb= > > ol: FT_Get_BDF_Property. > > First, stop posting in HTML.. > > Second, I'm almost sure you are not using freetype2 from Mdk packages.. > > -- > Frédéric Crozat > MandrakeSoft > > >
Re: [Cooker] [PATCH] ext3 may be mounted as ext2 in rc.sysinit
On Sunday 22 June 2003 21:35, Andrey Borzenkov wrote: > rc.sysinit checks for kernel 2.2 and mounts ext3 as ext2 if it > detects old kernel. It does it by doing > > uname -r | grep 2.2 > > unfortunately, it happily matches x.y.z2-2*mdk (or, 3.2.2 for that > matter :) I was cought by 2.5.72-2bor ... > > attached patch changes it to grep for '^2\.2' that should be more > robust ... I use auto instead of ext3 in my fstab, and, if ext3 is not enabled in the kernel, it mount the partion using ext2. This may be cleaner ? I never tried if it work, but, a friend say it did. -- Michaël Scherer
[Cooker] [PATCH] ext3 may be mounted as ext2 in rc.sysinit
rc.sysinit checks for kernel 2.2 and mounts ext3 as ext2 if it detects old kernel. It does it by doing uname -r | grep 2.2 unfortunately, it happily matches x.y.z2-2*mdk (or, 3.2.2 for that matter :) I was cought by 2.5.72-2bor ... attached patch changes it to grep for '^2\.2' that should be more robust ... -andrey initscripts-7.06-2.2.patch.bz2 Description: BZip2 compressed data
Re: [Cooker] rpmdrake and newbies: they sometimes miss *installed* software
On Tue, Jun 17, 2003 at 05:02:49PM +0200, [EMAIL PROTECTED] wrote: > On 17 Jun 2003, Guillaume Cottenceau wrote: > > > > mandrakeclub (or do a telephone poll for registered users, but that will > > > be more expensive). > > > > I don't like mandrakeclub much. > why? This is ofcourse a bit oftopic. But club gives you an excellent few > of the (paying) user experience of the distro. Mandrake lacks resources > currently. I assume they also lack resources for doing market research of > individual users. Being actively involved in the club, would tell you what > users interest the most (it ofcourse also costs too much time for every > cooker to do it, but it is in contrast to this list, feedback of non-tech > users). > Ok, above only explains 1 possible advantage of club, that ofcourse does > not mean you have to like or dislike it. > If I were an AOL user I'd say "me too", but I'll expand a bit ;-) I'm a silver member of mandrakeclub and I rarely visit the site and find something useful there. Maybe I'm not the targeted user of mandrake club, since I know most things that come up in the forums and the security updates announces come in via e-mail. Voting for RPM's is nice, but hardly something that should be available all the time. The forums have not nearly enough presence of mandrake employees, so it has degenerated in a shouting competition where newbies cry that things aren't working properly (mostly organisational) and "loyal" members saying the same, but more politely. I believe mandrakeusers.org provides more value than club does and for free too. The software that is members-only is so hard to reach that I don't bother anymore, getting it directly from the source is easier. (with the exception of a few real commercial ones, but staroffice is not part of that anymore, so why bother) So I'm a member, mainly because I don't want mandrake to die! Cheers, Simon
[Cooker] [Bug 2449] [gtk-engines] Chinese locale doesn't work with gtk+1.2 applications
http://qa.mandrakesoft.com/show_bug.cgi?id=2449 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:56 --- *** Bug 2448 has been marked as a duplicate of this bug. *** -- 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 Chinese locale doesn't work with gtk+1.2 applications. Works fine with 2.0. You can see the problem by logging in as Chinese, and bringing up gnumeric and comparing the menu with a gtk+2.0 application like gnome-terminal. gnumeric and rpmdrake show roman character garbage, while gtk+2.0 applications show chinese characters. The problem seems to be that the gtkrc file for 1.2 and zh_CN.utf-8 is broken although I haven't figured out how to fix it. Setting the locale to zh_CN makes everything work fine and one can workaround the problem by setting the locale.alias file in gdm to log in as zh_CN rather than zh_CN.utf-8. I think the same problem happens with zh_TW and zh_CN.utf-8.
[Cooker] [Bug 3984] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3984 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:29 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 2448] [gtk-engines] Chinese locale doesn't work with gtk+1.2 applications
http://qa.mandrakesoft.com/show_bug.cgi?id=2448 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:56 --- *** This bug has been marked as a duplicate of 2449 *** -- 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: The Chinese locale doesn't work with gtk+1.2 applications. Works fine with 2.0. You can see the problem by logging in as Chinese, and bringing up gnumeric and comparing the menu with a gtk+2.0 application like gnome-terminal. gnumeric and rpmdrake show roman character garbage, while gtk+2.0 applications show chinese characters. The problem seems to be that the gtkrc file for 1.2 and zh_CN.utf-8 is broken although I haven't figured out how to fix it. Setting the locale to zh_CN makes everything work fine and one can workaround the problem by setting the locale.alias file in gdm to log in as zh_CN rather than zh_CN.utf-8. I think the same problem happens with zh_TW and zh_CN.utf-8.
[Cooker] [Bug 3985] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3985 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:34 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3985] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3985 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** This bug has been marked as a duplicate of 3989 *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3863] [snort] New: Bad config file, prevents start !!!!
http://qa.mandrakesoft.com/show_bug.cgi?id=3863 Product: snort Component: snort Summary: Bad config file, prevents start Product: snort Version: 2.0.0-2mdk Platform: PC OS/Version: All Status: RESOLVED Severity: blocker Priority: P2 Component: snort AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There is a typo in file: /etc/snort/rules/deleted.rules alert udp $EXTERNAL_NET 4120 -> $HOME_NET any (msg:"BACKDOOR DeepThroat access"; content: "--Ahh"; reference:arachnids,405; sid:113; classtype:misc-act ivity; rev:4;) There is one space in "act ivity", snort will not start due to this typo, the correct line is below: alert udp $EXTERNAL_NET 4120 -> $HOME_NET any (msg:"BACKDOOR DeepThroat access"; content: "--Ahh"; reference:arachnids,405; sid:113; classtype:misc-activity; rev:4;) Linux-phased, Mandrake Soft Support --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:41 --- *** This bug has been marked as a duplicate of 3864 *** -- 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 3871] [rfbdrake] New: RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing
http://qa.mandrakesoft.com/show_bug.cgi?id=3871 Product: rfbdrake Component: rfbdrake Summary: RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing Product: rfbdrake Version: 0.9.1-9mdk Platform: PC OS/Version: All Status: RESOLVED Severity: major Priority: P2 Component: rfbdrake AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello Currently using latest cookers packages under GNOME environnment for all softs & utils, and now it is now impossible for me to launch RFBdrake ( or even x0rfbserv directly ) without having all the currently opened windows being borders and reduce/maximize buttons wiped. Immediatly after launching the rfbdrake tool in Server/Daemon mode, when the little icon of x0rfb appears on the screen and so the daemon is listening on to connections from clients, the screen is refreshed 4 or 5 times on the row and then i don't have any borders and reduce/maximize buttons on windows that were opened, focus on windows doesn't work anymore too. It seems like the window manager used is completly workless after initializing x0rfbserv, even after rebooting the box, windows are still borderless and "maximize/reduce buttons" less. The only way to recover my gnome environnement useable is to delete from my homedir all .gno* dirs ! after this all my windows turn back useable with borders and buttons available and moveable on the screen. Latest precision : i saw that in Gnome properties Control Center : the Windows icon is useless after launching x0rfb, it tells me an error message saying that no window manager was properly responding ... can't understand why, but after deleting .gno* on my home dir, everything was clean and the Windows icon was working properly ! The problem appears only after launching x0rfb, and is solved only by deleting .gno*, so it makes rfbdrake unusable at the moment since it cannot be launched. --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:39 --- *** This bug has been marked as a duplicate of 3873 *** -- 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 3989] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3989 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** Bug 3986 has been marked as a duplicate of this bug. *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time.
[Cooker] [Bug 3988] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3988 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:26 --- *** This bug has been marked as a duplicate of 3989 *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3872] [rfbdrake] RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing
http://qa.mandrakesoft.com/show_bug.cgi?id=3872 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:41 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Hello Currently using latest cookers packages under GNOME environnment for all softs & utils, and now it is now impossible for me to launch RFBdrake ( or even x0rfbserv directly ) without having all the currently opened windows being borders and reduce/maximize buttons wiped. Immediatly after launching the rfbdrake tool in Server/Daemon mode, when the little icon of x0rfb appears on the screen and so the daemon is listening on to connections from clients, the screen is refreshed 4 or 5 times on the row and then i don't have any borders and reduce/maximize buttons on windows that were opened, focus on windows doesn't work anymore too. It seems like the window manager used is completly workless after initializing x0rfbserv, even after rebooting the box, windows are still borderless and "maximize/reduce buttons" less. The only way to recover my gnome environnement useable is to delete from my homedir all .gno* dirs ! after this all my windows turn back useable with borders and buttons available and moveable on the screen. Latest precision : i saw that in Gnome properties Control Center : the Windows icon is useless after launching x0rfb, it tells me an error message saying that no window manager was properly responding ... can't understand why, but after deleting .gno* on my home dir, everything was clean and the Windows icon was working properly ! The problem appears only after launching x0rfb, and is solved only by deleting .gno*, so it makes rfbdrake unusable at the moment since it cannot be launched.
[Cooker] [Bug 3989] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3989 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** Bug 3984 has been marked as a duplicate of this bug. *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time.
[Cooker] [Bug 507] [userdrake] ldap integration with userdrake not working
http://qa.mandrakesoft.com/show_bug.cgi?id=507 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 22:03 --- multiple submission verified duplicate -- 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: VERIFIED creation_date: description: When you enable ldap from within userdrake, you can see any existing users/groups, but can't change or add anything. I've been able to get this to work only very occasionally. Most of the time, even simply changing a user's password and attempting to save the changes results in userdrake segfaulting. User adds, group adds etc... all lead to a segfault when you attempt to save. It's possible to use directory_administrator to add users/groups, but I find userdrake's interface for assigning groups better.
[Cooker] [Bug 3872] [rfbdrake] New: RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing
http://qa.mandrakesoft.com/show_bug.cgi?id=3872 Product: rfbdrake Component: rfbdrake Summary: RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing Product: rfbdrake Version: 0.9.1-9mdk Platform: PC OS/Version: All Status: RESOLVED Severity: major Priority: P2 Component: rfbdrake AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello Currently using latest cookers packages under GNOME environnment for all softs & utils, and now it is now impossible for me to launch RFBdrake ( or even x0rfbserv directly ) without having all the currently opened windows being borders and reduce/maximize buttons wiped. Immediatly after launching the rfbdrake tool in Server/Daemon mode, when the little icon of x0rfb appears on the screen and so the daemon is listening on to connections from clients, the screen is refreshed 4 or 5 times on the row and then i don't have any borders and reduce/maximize buttons on windows that were opened, focus on windows doesn't work anymore too. It seems like the window manager used is completly workless after initializing x0rfbserv, even after rebooting the box, windows are still borderless and "maximize/reduce buttons" less. The only way to recover my gnome environnement useable is to delete from my homedir all .gno* dirs ! after this all my windows turn back useable with borders and buttons available and moveable on the screen. Latest precision : i saw that in Gnome properties Control Center : the Windows icon is useless after launching x0rfb, it tells me an error message saying that no window manager was properly responding ... can't understand why, but after deleting .gno* on my home dir, everything was clean and the Windows icon was working properly ! The problem appears only after launching x0rfb, and is solved only by deleting .gno*, so it makes rfbdrake unusable at the moment since it cannot be launched. --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:39 --- *** This bug has been marked as a duplicate of 3873 *** -- 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 507] [userdrake] ldap integration with userdrake not working
http://qa.mandrakesoft.com/show_bug.cgi?id=507 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 22:02 --- *** This bug has been marked as a duplicate of 506 *** -- 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 you enable ldap from within userdrake, you can see any existing users/groups, but can't change or add anything. I've been able to get this to work only very occasionally. Most of the time, even simply changing a user's password and attempting to save the changes results in userdrake segfaulting. User adds, group adds etc... all lead to a segfault when you attempt to save. It's possible to use directory_administrator to add users/groups, but I find userdrake's interface for assigning groups better.
[Cooker] [Bug 3989] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3989 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:26 --- *** Bug 3983 has been marked as a duplicate of this bug. *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time.
[Cooker] [Bug 3864] [snort] New: Bad config file, prevents start !!!!
http://qa.mandrakesoft.com/show_bug.cgi?id=3864 Product: snort Component: snort Summary: Bad config file, prevents start Product: snort Version: 2.0.0-2mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: blocker Priority: P2 Component: snort AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There is a typo in file: /etc/snort/rules/deleted.rules alert udp $EXTERNAL_NET 4120 -> $HOME_NET any (msg:"BACKDOOR DeepThroat access"; content: "--Ahh"; reference:arachnids,405; sid:113; classtype:misc-act ivity; rev:4;) There is one space in "act ivity", snort will not start due to this typo, the correct line is below: alert udp $EXTERNAL_NET 4120 -> $HOME_NET any (msg:"BACKDOOR DeepThroat access"; content: "--Ahh"; reference:arachnids,405; sid:113; classtype:misc-activity; rev:4;) Linux-phased, Mandrake Soft Support --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:41 --- *** Bug 3863 has been marked as a duplicate of this bug. *** -- 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 3863] [snort] Bad config file, prevents start !!!!
http://qa.mandrakesoft.com/show_bug.cgi?id=3863 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:43 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: There is a typo in file: /etc/snort/rules/deleted.rules alert udp $EXTERNAL_NET 4120 -> $HOME_NET any (msg:"BACKDOOR DeepThroat access"; content: "--Ahh"; reference:arachnids,405; sid:113; classtype:misc-act ivity; rev:4;) There is one space in "act ivity", snort will not start due to this typo, the correct line is below: alert udp $EXTERNAL_NET 4120 -> $HOME_NET any (msg:"BACKDOOR DeepThroat access"; content: "--Ahh"; reference:arachnids,405; sid:113; classtype:misc-activity; rev:4;) Linux-phased, Mandrake Soft Support
[Cooker] [Bug 3988] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3988 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:34 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3989] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3989 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** Bug 3985 has been marked as a duplicate of this bug. *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time.
[Cooker] [Bug 3986] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3986 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:29 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 506] [userdrake] ldap integration with userdrake not working
http://qa.mandrakesoft.com/show_bug.cgi?id=506 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 22:02 --- *** Bug 507 has been marked as a duplicate of this bug. *** -- 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: When you enable ldap from within userdrake, you can see any existing users/groups, but can't change or add anything. I've been able to get this to work only very occasionally. Most of the time, even simply changing a user's password and attempting to save the changes results in userdrake segfaulting. User adds, group adds etc... all lead to a segfault when you attempt to save. It's possible to use directory_administrator to add users/groups, but I find userdrake's interface for assigning groups better.
[Cooker] [Bug 3987] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3987 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** This bug has been marked as a duplicate of 3989 *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3989] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3989 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** Bug 3987 has been marked as a duplicate of this bug. *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time.
[Cooker] [Bug 2448] [gtk-engines] Chinese locale doesn't work with gtk+1.2 applications
http://qa.mandrakesoft.com/show_bug.cgi?id=2448 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:57 --- multiple submission verified duplicate -- 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: VERIFIED creation_date: description: The Chinese locale doesn't work with gtk+1.2 applications. Works fine with 2.0. You can see the problem by logging in as Chinese, and bringing up gnumeric and comparing the menu with a gtk+2.0 application like gnome-terminal. gnumeric and rpmdrake show roman character garbage, while gtk+2.0 applications show chinese characters. The problem seems to be that the gtkrc file for 1.2 and zh_CN.utf-8 is broken although I haven't figured out how to fix it. Setting the locale to zh_CN makes everything work fine and one can workaround the problem by setting the locale.alias file in gdm to log in as zh_CN rather than zh_CN.utf-8. I think the same problem happens with zh_TW and zh_CN.utf-8.
[Cooker] [Bug 3873] [rfbdrake] RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing
http://qa.mandrakesoft.com/show_bug.cgi?id=3873 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:39 --- *** Bug 3871 has been marked as a duplicate of this bug. *** -- 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: Hello Currently using latest cookers packages under GNOME environnment for all softs & utils, and now it is now impossible for me to launch RFBdrake ( or even x0rfbserv directly ) without having all the currently opened windows being borders and reduce/maximize buttons wiped. Immediatly after launching the rfbdrake tool in Server/Daemon mode, when the little icon of x0rfb appears on the screen and so the daemon is listening on to connections from clients, the screen is refreshed 4 or 5 times on the row and then i don't have any borders and reduce/maximize buttons on windows that were opened, focus on windows doesn't work anymore too. It seems like the window manager used is completly workless after initializing x0rfbserv, even after rebooting the box, windows are still borderless and "maximize/reduce buttons" less. The only way to recover my gnome environnement useable is to delete from my homedir all .gno* dirs ! after this all my windows turn back useable with borders and buttons available and moveable on the screen. Latest precision : i saw that in Gnome properties Control Center : the Windows icon is useless after launching x0rfb, it tells me an error message saying that no window manager was properly responding ... can't understand why, but after deleting .gno* on my home dir, everything was clean and the Windows icon was working properly ! The problem appears only after launching x0rfb, and is solved only by deleting .gno*, so it makes rfbdrake unusable at the moment since it cannot be launched.
[Cooker] [Bug 3871] [rfbdrake] RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing
http://qa.mandrakesoft.com/show_bug.cgi?id=3871 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:41 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Hello Currently using latest cookers packages under GNOME environnment for all softs & utils, and now it is now impossible for me to launch RFBdrake ( or even x0rfbserv directly ) without having all the currently opened windows being borders and reduce/maximize buttons wiped. Immediatly after launching the rfbdrake tool in Server/Daemon mode, when the little icon of x0rfb appears on the screen and so the daemon is listening on to connections from clients, the screen is refreshed 4 or 5 times on the row and then i don't have any borders and reduce/maximize buttons on windows that were opened, focus on windows doesn't work anymore too. It seems like the window manager used is completly workless after initializing x0rfbserv, even after rebooting the box, windows are still borderless and "maximize/reduce buttons" less. The only way to recover my gnome environnement useable is to delete from my homedir all .gno* dirs ! after this all my windows turn back useable with borders and buttons available and moveable on the screen. Latest precision : i saw that in Gnome properties Control Center : the Windows icon is useless after launching x0rfb, it tells me an error message saying that no window manager was properly responding ... can't understand why, but after deleting .gno* on my home dir, everything was clean and the Windows icon was working properly ! The problem appears only after launching x0rfb, and is solved only by deleting .gno*, so it makes rfbdrake unusable at the moment since it cannot be launched.
[Cooker] [Bug 3873] [rfbdrake] New: RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing
http://qa.mandrakesoft.com/show_bug.cgi?id=3873 Product: rfbdrake Component: rfbdrake Summary: RFBdrake makes Windows borders and reduce/maximize buttons completly disappearing Product: rfbdrake Version: 0.9.1-9mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: major Priority: P2 Component: rfbdrake AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello Currently using latest cookers packages under GNOME environnment for all softs & utils, and now it is now impossible for me to launch RFBdrake ( or even x0rfbserv directly ) without having all the currently opened windows being borders and reduce/maximize buttons wiped. Immediatly after launching the rfbdrake tool in Server/Daemon mode, when the little icon of x0rfb appears on the screen and so the daemon is listening on to connections from clients, the screen is refreshed 4 or 5 times on the row and then i don't have any borders and reduce/maximize buttons on windows that were opened, focus on windows doesn't work anymore too. It seems like the window manager used is completly workless after initializing x0rfbserv, even after rebooting the box, windows are still borderless and "maximize/reduce buttons" less. The only way to recover my gnome environnement useable is to delete from my homedir all .gno* dirs ! after this all my windows turn back useable with borders and buttons available and moveable on the screen. Latest precision : i saw that in Gnome properties Control Center : the Windows icon is useless after launching x0rfb, it tells me an error message saying that no window manager was properly responding ... can't understand why, but after deleting .gno* on my home dir, everything was clean and the Windows icon was working properly ! The problem appears only after launching x0rfb, and is solved only by deleting .gno*, so it makes rfbdrake unusable at the moment since it cannot be launched. --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:39 --- *** Bug 3872 has been marked as a duplicate of this bug. *** -- 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 3983] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3983 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:29 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3987] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3987 [EMAIL PROTECTED] changed: What|Removed |Added CC||bugzilla- ||[EMAIL PROTECTED] Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:29 --- Multiple submission verified duplicate -- 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: VERIFIED creation_date: description: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3984] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3984 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** This bug has been marked as a duplicate of 3989 *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3986] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3986 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:27 --- *** This bug has been marked as a duplicate of 3989 *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
[Cooker] [Bug 3989] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3989 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:26 --- *** Bug 3988 has been marked as a duplicate of this bug. *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time.
[Cooker] [Bug 3983] [initscripts] Using LVM on /usr loses time setting
http://qa.mandrakesoft.com/show_bug.cgi?id=3983 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 21:26 --- *** This bug has been marked as a duplicate of 3989 *** -- 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: Due to the fact that /etc/rc.d/rc.sysinit runs "hwclock --hctosys --localtime" before running "/sbin/vgscan && /sbin/vgchange -a y", and hwclock depends on /etc/localtime, which is linked to a file in /usr/share/zoneinfo/*/*, if /usr uses LVM, it isn't set up when the time setting occurs, and so time synchronization with the local time zone doesn't occur. This bug manifests itself when running with the hardware clock set to local time instead of UTC, so the default system date is off by the difference between UTC and local time. This bug could be fixed by running "hwclock --hctosys --localtime" after LVM setup of /usr, though that might cause other issues, if the date needs to be set prior to that time. Ideally, LVM should be set up earlier in /etc/rc.d/rc.sysinit, but an alternate possibility would be to have a local copy of the current /usr/share/zoneinfo/*/* file in the *unmounted* version of the /usr tree (the solution I use myself). In other words, in the *unmounted* /usr tree, there should be 'share/zoneinfo/America/Anchorage' (in my case), which is a copy of the live one in /usr, and should be added/removed on the next reboot after changing the time zone. This would also take some doing to get right, as the change could not happen while /usr was mounted but would have to be postponed for the next reboot, prior to setting the time with hwclock.
Re: [Cooker] gettext and libiconv.so.2
On Sun, 22 Jun 2003 08:00:44 -0400 Charles A Edwards <[EMAIL PROTECTED]> wrote: > > When trying to build gettext-12.1, or even rebuilding the current > cooker gettext-0.11.5-6mdk.src.rpm the build fails because > libiconv.so.2 can not be found. After sending I realized what was causing this. The gettext.spec runs %configure2_5x --enable-shared --with-included-gettext but it should be %configure2_5x --enable-shared --with-included-gettext --without-java Without that addition at configure, if gcc-java is installed, the default is to build with java which does require that libiconv.so.2 be present. Charles -- I'm a Hollywood writer; so I put on a sports jacket and take off my brain. - Mandrake Linux 9.2 on PurpleDragon Kernel- 2.4.21-0.1mdk http://www.eslrahc.com - pgp0.pgp Description: PGP signature
[Cooker] Mandrake Control Center - no fonts visible on clean install
Hi, On a clean install, Mandrake Control Center, and Mandrake Firsttime do not display any text. Is this a know issue? V.
Re: [Cooker] rpm-build probs - nvidia-gl
Danny wrote: > On Sun, 22 Jun 2003, Buchan Milne wrote: >> > I guess so. I have installed from prosuite CDs and didN't looked at >> it, and it is not bad that the RPM is installed on that machine, >> since it is my 9.1 stable installation. And Buchans solution works >> fine here. >> > >> >> BTW, I forgot to mention, the %__find_requires entry should be in your >> ~/.rpmmacros, not in the spec file (otherwise you will add it to each >> spec file for a package linking to libGL.so.1, instead of once ...). > > Buchan, wouldn't it be possible to fix this problem in the new nvidia > rpms you are making? Just adding this to the global rpmmacros? If it can be done via a macro, and it can be "stacked" (ie different settings in global macros and user macros and/or in spec files all taken into account), but I don't think I would want to redefine %__find_requires in /etc/rpm/macros (could be confusing ...). Good idea though ... I will have to track down the macro and test it ... Hmm, Warly said it was '_requires_exceptions', but it doesn't seem to work on 9.1, and my cooker box is a bit inaccessible right now, I will try tomorrow on cooker. Regards, Buchan
Re: [Cooker] rpm-build probs - nvidia-gl
On Sun, 22 Jun 2003, Buchan Milne wrote: > > > > I guess so. I have installed from prosuite CDs and didN't looked at it, > > and it is not bad that the RPM is installed on that machine, since it > > is my 9.1 stable installation. And Buchans solution works fine here. > > > > BTW, I forgot to mention, the %__find_requires entry should be in your > ~/.rpmmacros, not in the spec file (otherwise you will add it to each spec > file for a package linking to libGL.so.1, instead of once ...). Buchan, wouldn't it be possible to fix this problem in the new nvidia rpms you are making? Just adding this to the global rpmmacros? d.
[Cooker] Re: [Contrib-Rpm] xmmsao-0.5-1mdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 22 June 2003 06:30, Levi Ramsey wrote: > - disable debug package why are you actually disabling the debug package? IMHO it would be better to fix whatever problem that's introduced with the debug package than disabling it.. it creates mess and it's always a good thing to have them easily built.. - -- Regards, Per Øyvind Karlsen Sintrax Solutions http://www.sintrax.net - +47 41681061 - GPG Key: http://sintrax.net/~hawkeye/key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+9coEv8F7V9JOSuURAtFUAKDWOi+MH/MohZ1PLTTFoMALZhPsAwCgkEEX h3H70PRi36A9RM4HRxG2IqI= =kbQe -END PGP SIGNATURE-
Re: [Cooker] FreeCraft project terminated!
On Sunday 22 June 2003 05:44, Leon Brooks wrote: > On Sun, 22 Jun 2003 01:44, Charles Shirley wrote: > > Such a shame... Now how will I waste my spare time? > > With the reincarnation, whatever it gets called. I have kept out a copy > of the 1.18 SRPM and the same thing (apparently) from Debian at > http://www.arach.net.au/~brooks/clone/ > > Cheers; Leon Indeed! I was a bit shocked at how quickly and without warning FreeCraft project folded, but I am heartened by the volume of responses the action has generated among its community of enthusiasts. I think I can safely lay my fears to rest. I only wish I had any kind of artistic talent so that I could help with the FCMP, since it seems that the replacement project will no longer be able to play War Craft, which is fine with me since I never played it anyway, only FreeCraft + FCMP. -Charles -- +-% He's a real UNIX Man $-++ \ Sitting in his UNIX LAN \ Charles A. Shirley\ \ Making all his UNIX plans \ cashirley (at) comcast (dot) net \ +--# For nobody @--++
Re: [Cooker] php dependency woes
> hello, > i noticed that php-cli, php-cgi and apache2-mod_php all provide php430 > and obsolete it. Did not check mod_php, but i believe it might be the > same. php-cli and php-cgi also both provide and obsolete php and php3. > This causes that only one of said packages can be installed at a time, > since installing one would automatically remove the other. Bug in rpm-4.2 (any package that provides a name will be uninstalled by any package that obsoletes the same name), Fred Lepied is apparently working on a fix? > also it is impossible to rebuild php if you have it installed since it > buildconflicts with > libphp_common432 > libphp_common430 > php-devel > which php itself provides. Intended AFAIK. Instead you could have your new php link against the currently installed version, and have a library mismatch mixup ...
[Cooker] [Bug 992] [Installation] Intallation frozen
http://qa.mandrakesoft.com/show_bug.cgi?id=992 --- Additional Comments From [EMAIL PROTECTED] 2003-22-06 17:53 --- Does anyone know if this problem was already solved in cooker? -- 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: I have a K7VMM Mother Board, Athlon XP-1800, 256 DDR-RAM, 80GB HDD, Liteon CDRW. I have other Athlon machines to. On the K7VMM instalation of mandrake 9.1 betas 2 froze the PC just after the very first screen where you can pres enter or F1. I have presed F1 and tryed text, noapic, meem=248 (8 are video), I have also tried changind lost of things at BIOS. Nothing works. The same happens with Mandrake 9.0 relase version and RedHat8.0. Mandrake 8.2 Installs and run very good. No text is displayed so ther are no mesages I can add. A guy on a forum told me to install 8.2 and then to upgrade to 9.0 threw a floppy disk (direct instalation with floppy does not work) When I get this info my drive was unusuable so I have not try. I did try the installation from floppy does not work.
Re: [Cooker] rpm-build probs - nvidia-gl
Ainsi parlait Buchan Milne : > >> Don't install the NVIDIA driver from an RPM? The last couple of > >> versions use an install script > > Which sucks, cause you download 4.2MB of binary objects compiled for 93 > kernels you aren't running ... I have a wrapper rpm around the script > which creates <3MB total for the GLX (2.2MB) and kernel module (600kB) > RPMS instead of 6MB+. The tar.gz are still available. -- Software bugs are impossible to detect by anybody except the end user. -- Murphy's Computer Laws n°10
[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.
Re: [Cooker] rpm-build probs - nvidia-gl
Am Sonntag, 22. Juni 2003 15:14 schrieb Buchan Milne: > > > > I guess so. I have installed from prosuite CDs and didN't looked at it, > > and it is not bad that the RPM is installed on that machine, since it > > is my 9.1 stable installation. And Buchans solution works fine here. > > BTW, I forgot to mention, the %__find_requires entry should be in your > ~/.rpmmacros, not in the spec file (otherwise you will add it to each spec > file for a package linking to libGL.so.1, instead of once ...). > > Regards, > Buchan Sure :) Done so. I have grepped trough /usr/lib/rpm/* and looked after something similar like you told me. Saw it and have put it in my ~/.rpmmacros as user defined counterpart of the macros there to not break anything seriously :) Steffen
[Cooker] php dependency woes
hello, i noticed that php-cli, php-cgi and apache2-mod_php all provide php430 and obsolete it. Did not check mod_php, but i believe it might be the same. php-cli and php-cgi also both provide and obsolete php and php3. This causes that only one of said packages can be installed at a time, since installing one would automatically remove the other. also it is impossible to rebuild php if you have it installed since it buildconflicts with libphp_common432 libphp_common430 php-devel which php itself provides. regards, L. -- Luca Berra -- [EMAIL PROTECTED] /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \
Re: [Cooker] rpm-build probs - nvidia-gl
> I guess so. I have installed from prosuite CDs and didN't looked at it, > and it is not bad that the RPM is installed on that machine, since it > is my 9.1 stable installation. And Buchans solution works fine here. > BTW, I forgot to mention, the %__find_requires entry should be in your ~/.rpmmacros, not in the spec file (otherwise you will add it to each spec file for a package linking to libGL.so.1, instead of once ...). Regards, Buchan
Re: [Cooker] rpm-build probs - nvidia-gl
> On Sunday 22 June 2003 12:29, Adam Williamson wrote: >> On Sun, 2003-06-22 at 10:09, Steffen Barszus wrote: >> > Hi! >> > >> > I try to package some kde-rpms. Since I have the NVIDIA drivers >> installed, the buildscript seems to think that the apps/rpms depends >> on the open-gl libs. Is there a way to avoid this somehow ? I guess >> others have encountered the same problems, but i have not found a >> real solution. Any hints how to build kde-packages without having >> them depend on NVIDIA-driver RPM ? >> >> Don't install the NVIDIA driver from an RPM? The last couple of >> versions use an install script Which sucks, cause you download 4.2MB of binary objects compiled for 93 kernels you aren't running ... I have a wrapper rpm around the script which creates <3MB total for the GLX (2.2MB) and kernel module (600kB) RPMS instead of 6MB+. >, so shouldn't bother RPM >> dependencies... > it'll still add dependency on the library, won't it? Yes: $ ldd /usr/bin/mysqlcc |grep core libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40ba4000) $ ldd /usr/lib/libGL.so.1|grep core libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x4007e000) > I mean, it does'nt add dependencies on the NVIDIA-GLX package itself but > on the libraries, or..? Yes, either you have to revert to the original libGL.so.1, or fool rpm into ignoring it ... Regards, Buchan
Re: [Cooker] rpm-build probs - nvidia-gl
Am Sonntag, 22. Juni 2003 14:49 schrieb Per Øyvind Karlsen: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sunday 22 June 2003 12:29, Adam Williamson wrote: > > On Sun, 2003-06-22 at 10:09, Steffen Barszus wrote: > > > Hi! > > > > > > I try to package some kde-rpms. Since I have the NVIDIA drivers > > > installed, the buildscript seems to think that the apps/rpms depends on > > > the open-gl libs. Is there a way to avoid this somehow ? I guess others > > > have encountered the same problems, but i have not found a real > > > solution. Any hints how to build kde-packages without having them > > > depend on NVIDIA-driver RPM ? > > > > Don't install the NVIDIA driver from an RPM? The last couple of versions > > use an install script, so shouldn't bother RPM dependencies... > > it'll still add dependency on the library, won't it? > I mean, it does'nt add dependencies on the NVIDIA-GLX package itself but on > the libraries, or..? I guess so. I have installed from prosuite CDs and didN't looked at it, and it is not bad that the RPM is installed on that machine, since it is my 9.1 stable installation. And Buchans solution works fine here. Steffen
Re: [Cooker] rpm-build probs - nvidia-gl
On Sun, 2003-06-22 at 13:49, Per Øyvind Karlsen wrote: > > > I try to package some kde-rpms. Since I have the NVIDIA drivers > > > installed, the buildscript seems to think that the apps/rpms depends on > > > the open-gl libs. Is there a way to avoid this somehow ? I guess others > > > have encountered the same problems, but i have not found a real solution. > > > Any hints how to build kde-packages without having them depend on > > > NVIDIA-driver RPM ? > > > > Don't install the NVIDIA driver from an RPM? The last couple of versions > > use an install script, so shouldn't bother RPM dependencies... > it'll still add dependency on the library, won't it? > I mean, it does'nt add dependencies on the NVIDIA-GLX package itself but on > the libraries, or..? Oh, that might be right - if so I misread Steffen's mail. -- adamw
[Cooker] gettext and libiconv.so.2
When trying to build gettext-12.1, or even rebuilding the current cooker gettext-0.11.5-6mdk.src.rpm the build fails because libiconv.so.2 can not be found. Unless I have missed something there are no libiconv rpms and no current pkg includes any libiconv.so*, though glibc-devel does contain libiconv.h I can pkg libiconv-1.8 and the gettext build will successfully complete but how is that the Mdk build of gettext is able to be done? The last update for it was Jun 03 by Stew Benedict. As I said I may just be missing something but I would be most grateful if someone could enlighten me as to what it is. Charles -- I just got my PRINCE bumper sticker ... But now I can't remember WHO he is ... - Mandrake Linux 9.2 on PurpleDragon Kernel- 2.4.21-0.1mdk http://www.eslrahc.com - pgp0.pgp Description: PGP signature
Re: [Cooker] rpm-build probs - nvidia-gl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 22 June 2003 12:29, Adam Williamson wrote: > On Sun, 2003-06-22 at 10:09, Steffen Barszus wrote: > > Hi! > > > > I try to package some kde-rpms. Since I have the NVIDIA drivers > > installed, the buildscript seems to think that the apps/rpms depends on > > the open-gl libs. Is there a way to avoid this somehow ? I guess others > > have encountered the same problems, but i have not found a real solution. > > Any hints how to build kde-packages without having them depend on > > NVIDIA-driver RPM ? > > Don't install the NVIDIA driver from an RPM? The last couple of versions > use an install script, so shouldn't bother RPM dependencies... it'll still add dependency on the library, won't it? I mean, it does'nt add dependencies on the NVIDIA-GLX package itself but on the libraries, or..? - -- Regards, Per Øyvind Karlsen Sintrax Solutions http://www.sintrax.net - +47 41681061 - GPG Key: http://sintrax.net/~hawkeye/key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+9aXUv8F7V9JOSuURAkJoAJ9fb99/ogxGdDCM1555GdxM7+l7eQCgz08e BXP+oBnPAwBhgYWFj6yz57s= =zgZZ -END PGP SIGNATURE-
Re: [Cooker] rpm-build probs - nvidia-gl
On Sun, 2003-06-22 at 10:09, Steffen Barszus wrote: > Hi! > > I try to package some kde-rpms. Since I have the NVIDIA drivers installed, the > buildscript seems to think that the apps/rpms depends on the open-gl libs. Is > there a way to avoid this somehow ? I guess others have encountered the same > problems, but i have not found a real solution. Any hints how to build > kde-packages without having them depend on NVIDIA-driver RPM ? Don't install the NVIDIA driver from an RPM? The last couple of versions use an install script, so shouldn't bother RPM dependencies... -- adamw
Re: [Cooker] rpm-build probs - nvidia-gl
Am Sonntag, 22. Juni 2003 11:34 schrieb Buchan Milne:
>
>
> > Hi!
> >
> > I try to package some kde-rpms. Since I have the NVIDIA drivers
> > installed, the buildscript seems to think that the apps/rpms depends on
> > the open-gl libs. Is there a way to avoid this somehow ? I guess others
> > have encountered the same problems, but i have not found a real
> > solution. Any hints how to build kde-packages without having them
> > depend on NVIDIA-driver RPM ?
>
> I use:
>
> %__find_requires%{_my_bindir}/find-requires-nonvidia
> %{?buildroot:%{buildroot}}
>
> and
>
> http://ranger.dnsalias.com/mandrake/configs/find-requires-nonvidia
>
> But there is apparently a better solution using an rpm macro ... can't
> find it now.
Thanks Buchan. I guess this will work for now :)
Thanks a lot
Steffen
Re: [Cooker] rpm-build probs - nvidia-gl
> Hi!
>
> I try to package some kde-rpms. Since I have the NVIDIA drivers
> installed, the buildscript seems to think that the apps/rpms depends on
> the open-gl libs. Is there a way to avoid this somehow ? I guess others
> have encountered the same problems, but i have not found a real
> solution. Any hints how to build kde-packages without having them
> depend on NVIDIA-driver RPM ?
>
I use:
%__find_requires%{_my_bindir}/find-requires-nonvidia
%{?buildroot:%{buildroot}}
and
http://ranger.dnsalias.com/mandrake/configs/find-requires-nonvidia
But there is apparently a better solution using an rpm macro ... can't
find it now.
Re: [Cooker] FreeCraft project terminated!
On Sun, 22 Jun 2003 01:44, Charles Shirley wrote: > Such a shame... Now how will I waste my spare time? With the reincarnation, whatever it gets called. I have kept out a copy of the 1.18 SRPM and the same thing (apparently) from Debian at http://www.arach.net.au/~brooks/clone/ Cheers; Leon
Re: [Cooker] skel.spec
On Sat, 21 Jun 2003 21:11, Per Øyvind Karlsen wrote: > hehe, thx, my first name is Per Øyvind, last name is Karlsen:) > it's a double name, both Per or Øyvind is a name, but I'm named Per > Øyvind Kind of like Billy Joe Cartwright or my own youngest daughter, Anne-Rose Brooks? We write an accent-grave on the e in Anne not out of great cultural understanding but so that I can call her something like Anna-Rose and my wife can call her something like Annie-Rose. (-: We also have friends who have 11 children, one of whom is named Jonathan and another one John. Causes endless confusion when Aussies typically abberviate Jonathan to Jon. Leon is hard to get wrong, but I still get called Niel, Noel, Leo and Len (in approximately that order of frequency) by strangers. Cheers; Leon
[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 14:11 --- Some news: This is highly related to the prompt: on a real terminal (Ctrl+Alt+F1), I have only to set my coloured prompt with: export PS1="\e[31;1m\h:\w\e[33;1m#\e[0m" and then the bug appears: the cursor jumps before arriving at the end of the line. It happens only with colours, so a PS1="\e[34mC:\\> " would also do it and a PS1="C:\\> " will correct it. The bug is probably when counting the number of chars that has the prompt; it may count more than the actual number. At the examples above, both prompts have 5 chars, but the first acts as if it had more (although "\e[34m" is 0 chars long...). -- 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] rpm-build probs - nvidia-gl
Hi! I try to package some kde-rpms. Since I have the NVIDIA drivers installed, the buildscript seems to think that the apps/rpms depends on the open-gl libs. Is there a way to avoid this somehow ? I guess others have encountered the same problems, but i have not found a real solution. Any hints how to build kde-packages without having them depend on NVIDIA-driver RPM ? Thanks in Advance Steffen
Re: [Cooker] Can't start gnome
Le Sat, 21 Jun 2003 18:00:04 -0400, John Johnson a écrit : > Since upgrading to the latest version of cooker (as of june 17), I'm unable= > to start gnome. When starting gnome using startx, I get the gnome splash = > screen and then I'm immediately dumped to the command prompt. The following= > error message is displayed: > gnome-session: Relocation error /usr/lib/libfontconfig.so.1: Undefined symb= > ol: FT_Get_BDF_Property. First, stop posting in HTML.. Second, I'm almost sure you are not using freetype2 from Mdk packages.. -- Frédéric Crozat MandrakeSoft
