Re: [Cooker] Sony Cli, Palm, Handspring, PalmOS users, please read
Frederic Crozat wrote: Folks, I'm trying to fix bug #3381, which is a problem with some Palm/Clié/other PalmOS PDA which requires using /dev/usb/tts/0 instead of /dev/usb/tts/1 Currently, I only know of 3 problematic models : -Sony Clié N770C/E (Vendor=054c ProdID=0060) -Palm m130 (Vendor=0830 ProdID=0050) -Sony Clié 320 (Vendor=054c, ProdID unknown) So, if you have another PDA which requires this kind of changes, please, post it here, with Vendor and ProdID (check /proc/bus/usb/devices after pressing hotsync) If you have a PalmOS PDA which does NOT requires this but which is not correctly described in /usr/share/doc/pilot-link-0.11.8/README.usb (it doesn't have USBx info, it is missing for the list, etc..), please, post here too. I'd like to get the pilot-link up to date to be sure /dev/pilot is always symlinked to the correct usb serial devices. If you have a Palm Tungsten T3, I know they don't work yet but I plan to fix that as soon as I receive mine :)) (probably next week, replacing my Clié N770C/E). Thanks for your cooperation :) I have a Sony PEG-N760C (asian version of the N770C): ID 054c:0066 Sony Corp. Clie PEG-N7x0C PalmOS PDA Serial regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] [Bug 6119] [autofs] [amd64] parsing autofs names goes wrong
http://qa.mandrakesoft.com/show_bug.cgi?id=6119 --- Additional Comments From [EMAIL PROTECTED] 2003-11-14 12:51 --- This package solves the issue: http://people.mandrakesoft.com/~gbeauchesne/x86_64/testing/autofs-4.0.0-0.20.2mdk.amd64.rpm -- 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: after putting a symlink (/usr/lib64/autofs -- /usr/lib/autofs), otherwise autofs won't start, see bug 5351: When I do ls /build/plf the following shows up in the log files, as you can see, it is looking up /build/: Oct 9 21:10:00 turaco automount[930]: attempting to mount entry /build/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=nisObject)(cn=)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): no entry for found, trying cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=nisObject)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): getting first entry for cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): query succeeded, no matches for ((objectclass=nisObject)(cn=/)) Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=automount)(cn=)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): no entry for found, trying cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=automount)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): getting first entry for cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): query succeeded, no matches for ((objectclass=automount)(cn=/)) For ls /build/cooker it only looks up /build/er : Oct 9 21:20:00 turaco automount[930]: attempting to mount entry /build/er Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): searching for ((objectclass=nisObject)(cn=er)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): no entry for er found, trying cn=/ Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): searching for ((objectclass=nisObject)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): getting first entry for cn=/ Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): query succeeded, no matches for ((objectclass=nisObject)(cn=/)) Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): searching for ((objectclass=automount)(cn=er)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): no entry for er found, trying cn=/ Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): searching for ((objectclass=automount)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): getting first entry for cn=/ Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): query succeeded, no matches for ((objectclass=automount)(cn=/)) For ls /build/cookcooker it only looks up /build/cooker: Oct 9 21:40:00 turaco automount[930]: attempting to mount entry /build/cooker Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): searching for ((objectclass=nisObject)(cn=cooker)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): no entry for cooker found, trying cn=/ Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): searching for ((objectclass=nisObject)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): getting first entry for cn=/ Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): query succeeded, no matches for ((objectclass=nisObject)(cn=/)) Oct 9 21:40:07 turaco automount[1162]: lookup(ldap): searching for ((objectclass=automount)(cn=cooker)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:40:07 turaco automount[1162]: lookup(ldap): examining first entry Oct 9 21:40:07 turaco automount[1162]: lookup(ldap): entry 0 is anorien:/data/build/ Oct 9 21:40:07 turaco automount[1162]: parse(sun): expanded entry: anorien:/data/build/cooker Oct 9 21:40:07 turaco automount[1162]: parse(sun): gathered options: Oct 9 21:40:07 turaco automount[1162]: parse(sun): dequote(anorien:/data/build/cooker) - anorien:/data/build/cooker Oct 9 21:40:07 turaco automount[1162]: parse(sun): core of entry: options=, loc=anorien:/data/build/cooker Oct 9 21:40:07 turaco kernel: automount[1162]: segfault at 007f54907738 rip 002a964aac37 rsp 007f54907740 error 6 I guess the first 4 characters in to be mounted directories name get lost. This only takes place on amd64 (alpha, i586 and sparc are fine)
[Cooker] [Bug 5351] [autofs] [amd64] ldap support in autofs broken
http://qa.mandrakesoft.com/show_bug.cgi?id=5351
--- Additional Comments From [EMAIL PROTECTED] 2003-11-14 12:51 ---
This packages solves the issue:
http://people.mandrakesoft.com/~gbeauchesne/x86_64/testing/autofs-4.0.0-0.20.2mdk.amd64.rpm
--
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 autofs initscript contains:
function getldapmounts()
{
/usr/lib/autofs/autofs-ldap-auto-master 2 /dev/null
}
This file cannot be found because the file is packaged in /usr/lib64 (and not:
/usr/lib).
Difference in filelist for the autofs package between amd64 and i586 platforms:
amd64 files:
/usr/lib64/autofs
/usr/lib64/autofs/autofs-ldap-auto-master
/usr/lib64/autofs/lookup_file.so
/usr/lib64/autofs/lookup_ldap.so
/usr/lib64/autofs/lookup_multi.so
/usr/lib64/autofs/lookup_nisplus.so
/usr/lib64/autofs/lookup_program.so
/usr/lib64/autofs/lookup_userhome.so
/usr/lib64/autofs/lookup_yp.so
/usr/lib64/autofs/mount_afs.so
/usr/lib64/autofs/mount_autofs.so
/usr/lib64/autofs/mount_bind.so
/usr/lib64/autofs/mount_changer.so
/usr/lib64/autofs/mount_ext2.so
/usr/lib64/autofs/mount_generic.so
/usr/lib64/autofs/mount_nfs.so
/usr/lib64/autofs/parse_sun.so
i586 files:
/usr/lib/autofs
/usr/lib/autofs/autofs-ldap-auto-master
/usr/lib/autofs/lookup_file.so
/usr/lib/autofs/lookup_ldap.so
/usr/lib/autofs/lookup_multi.so
/usr/lib/autofs/lookup_nisplus.so
/usr/lib/autofs/lookup_program.so
/usr/lib/autofs/lookup_userhome.so
/usr/lib/autofs/lookup_yp.so
/usr/lib/autofs/mount_afs.so
/usr/lib/autofs/mount_autofs.so
/usr/lib/autofs/mount_bind.so
/usr/lib/autofs/mount_changer.so
/usr/lib/autofs/mount_ext2.so
/usr/lib/autofs/mount_generic.so
/usr/lib/autofs/mount_nfs.so
/usr/lib/autofs/parse_sun.so
[Cooker] [Bug 6316] [arts] libarts-devel Provides missing on -devel package
http://qa.mandrakesoft.com/show_bug.cgi?id=6316 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-13 16:14 --- fixed in 1.1.93-4mdk -- 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: libarts-devel Provides missing on -devel package: $ rpm -qp --provides libarts1-devel-1.1.93-3mdk.i586.rpm | sort devel(libartsc) devel(libartscbackend) devel(libartsdsp) devel(libartsdsp_st) devel(libartsflow) devel(libartsflow_idl) devel(libartsgslplayobject) devel(libartswavplayobject) devel(libgmcop) devel(libkmedia2) devel(libkmedia2_idl) devel(libmcop) devel(libmcop_mt) devel(libqtmcop) devel(libsoundserver_idl) libarts1-devel = 3001:1.1.93-3mdk libarts2-devel = 3001:1.1.93-3mdk libarts3-devel = 3001:1.1.93-3mdk
[Cooker] [Bug 6313] [rpm] conditional BuildRequires not picked up in query
http://qa.mandrakesoft.com/show_bug.cgi?id=6313
--- Additional Comments From [EMAIL PROTECTED] 2003-10-11 16:40 ---
OK, so the reason by that one BuildRequires wasn't included in the rpm
headers was because the src.rpm package was built on Gwenole's amd64
system: gauss.mandrakesoft.com.
It would be an option to install the src.rpm file and then run urpmi
against the .spec file, also with the required options (--with plf) when
required.
Issue is, rpm can't determin the BuildRequires from a .spec file alone.
--
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 a package has conditional BuildRequires (like ImageMagick) these are not
picked up when querying the package:
Normal:
[EMAIL PROTECTED] i586]$ rpm -qpR
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm | wc -l
15
--with plf:
[EMAIL PROTECTED] i586]$ rpm -qpR
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm --with plf | wc -l
15
[EMAIL PROTECTED] i586]$ rpm --with plf -qpR
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm | wc -l
15
[EMAIL PROTECTED] i586]$ rpm -qpR --with plf
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm | wc -l
15
From the ImageMagick.spec file:
%if %build_plf
%define enablelzw 1
%define enablejasper1
%define enablefpx 1
%endif
%if %{enablefpx}
BuildRequires: libfpx1-devel
%endif
%if %{enablejasper}
BuildRequires: libjasper-devel
%endif
So, one would expect to see a number larger than 15 when queried with the --with
plf option.
Re: [Cooker] perl-5.8.2-1mdk broken
Tried to rebuild perl-MDK-Common, but it breaks: make[2]: Entering directory `/usr/src/RPM/BUILD/perl-MDK-Common/perl_checker.src' making ._ncdi/parser.di from parser.mli making ._ncdi/types.di from types.mli making ._d/parser.d from parser.ml File parser.mly, line 480, characters 0-2: Syntax error make[2]: *** [._d/parser.d] Error 2 make[2]: *** Deleting file `._d/parser.d' $ rpm -q ocaml ocaml-3.07-1mdk -o- kk1 True, probably unrelated to the new perl as slbd tried to build it on 07-Nov-2003 03:52: http://eijk.homelinux.org/build/cooker/i586/problem/perl-MDK-Common-1.1.8-1mdk Stefan Installed perl-5.8.2-1mdk perl-base-5.8.2-1mdk which broke rpmdrake, urpmi, Mandrake Control Center, etc . . . Error was that all mandrake perl scripts could not locate MDK/Common.pm Solution was to re-install perl-5.8.1-1mdk perl-base-5.8.1-1mdk -- Rgds, Steve smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] [Bug 6233] [drakfirsttime] BuildRequires missing
http://qa.mandrakesoft.com/show_bug.cgi?id=6233 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 12:20 --- I've yet to see the package containing the fix on the mirrors. Shall we keep the bug open until then? -- 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: See URL: make[1]: Entering directory `/home/slbd/RPM/BUILD/drakfirsttime-0.92/po' perl_checker -q --generate-pot drakfw.pot ../drakfw ../drakfirsttime/data.pm ../drakfirsttime/gui.pm ../drakmail make[1]: perl_checker: Command not found make[1]: *** [drakfw.pot] Error 127 make[1]: Leaving directory `/home/slbd/RPM/BUILD/drakfirsttime-0.92/po' make: *** [all] Error 2 error: Bad exit status from /home/slbd/tmp/rpm-tmp.89453 (%install)
[Cooker] [Bug 6232] [userdrake] BuildRequires: pam-devel missing
http://qa.mandrakesoft.com/show_bug.cgi?id=6232 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 12:21 --- I've yet to see the package containing the fix on the mirrors. Shall we keep the bug open until then? -- 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: See URL: rm -f blib/arch/auto/USER/USER.so LD_RUN_PATH= gcc -shared -L/usr/local/lib USER.o -o blib/arch/auto/USER/USER.so -luser -lcrypt -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpam_misc -lpam /usr/bin/ld: cannot find -lpam_misc collect2: ld returned 1 exit status make: *** [blib/arch/auto/USER/USER.so] Error 1 error: Bad exit status from /home/slbd/tmp/rpm-tmp.15774 (%build)
[Cooker] Provides naming: what Provides libarts-devel?
What package provides libarts-devel (not libarts1-devel, libarts2-devel or libarts3-devel, but libarts-devel exactly)? Some packages have libarts-devel as a BuildRequires, but currently no package (in cooker) provides it. See: http://eijk.homelinux.org/build/cooker/urpmi/i586/TiMidity++-2.12.0-0.pre1.4mdk What should be used as BuildRequires for this Provides? libarts1-devel currently Provides the following: ]$ rpm -qp --provides /mirrors/cooker/i586/Mandrake/RPMS/libarts1-devel-1.1.93-3mdk.i586.rpm |sort devel(libartsc) devel(libartscbackend) devel(libartsdsp) devel(libartsdsp_st) devel(libartsflow) devel(libartsflow_idl) devel(libartsgslplayobject) devel(libartswavplayobject) devel(libgmcop) devel(libkmedia2) devel(libkmedia2_idl) devel(libmcop) devel(libmcop_mt) devel(libqtmcop) devel(libsoundserver_idl) libarts1-devel = 3001:1.1.93-3mdk libarts2-devel = 3001:1.1.93-3mdk libarts3-devel = 3001:1.1.93-3mdk regards, Stefan
[Cooker] [Bug 6313] [rpm] New: conditional BuildRequires not picked up in query
http://qa.mandrakesoft.com/show_bug.cgi?id=6313
Summary: conditional BuildRequires not picked up in query
Product: rpm
Version: 4.2-9mdk
Platform: PC
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: program
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When a package has conditional BuildRequires (like ImageMagick) these are not
picked up when querying the package:
Normal:
[EMAIL PROTECTED] i586]$ rpm -qpR
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm | wc -l
15
--with plf:
[EMAIL PROTECTED] i586]$ rpm -qpR
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm --with plf | wc -l
15
[EMAIL PROTECTED] i586]$ rpm --with plf -qpR
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm | wc -l
15
[EMAIL PROTECTED] i586]$ rpm -qpR --with plf
/mirrors/cooker/SRPMS/ImageMagick-5.5.7.12-1mdk.src.rpm | wc -l
15
From the ImageMagick.spec file:
%if %build_plf
%define enablelzw 1
%define enablejasper1
%define enablefpx 1
%endif
%if %{enablefpx}
BuildRequires: libfpx1-devel
%endif
%if %{enablejasper}
BuildRequires: libjasper-devel
%endif
So, one would expect to see a number larger than 15 when queried with the --with
plf option.
--
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 6316] [arts] New: libarts-devel Provides missing on -devel package
http://qa.mandrakesoft.com/show_bug.cgi?id=6316 Summary: libarts-devel Provides missing on -devel package Product: arts Version: 1.1.93-2mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] libarts-devel Provides missing on -devel package: $ rpm -qp --provides libarts1-devel-1.1.93-3mdk.i586.rpm | sort devel(libartsc) devel(libartscbackend) devel(libartsdsp) devel(libartsdsp_st) devel(libartsflow) devel(libartsflow_idl) devel(libartsgslplayobject) devel(libartswavplayobject) devel(libgmcop) devel(libkmedia2) devel(libkmedia2_idl) devel(libmcop) devel(libmcop_mt) devel(libqtmcop) devel(libsoundserver_idl) libarts1-devel = 3001:1.1.93-3mdk libarts2-devel = 3001:1.1.93-3mdk libarts3-devel = 3001:1.1.93-3mdk -- 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 6319] [libkdemultimedia1-noatun-devel] I can' install the package
http://qa.mandrakesoft.com/show_bug.cgi?id=6319 --- Additional Comments From [EMAIL PROTECTED] 2003-08-11 19:20 --- [lrathle] wrote: try updating your urpmi media. devel(libartsmidi_idl) is Provided by: $ urpmq devel(libartsmidi_idl) libkdemultimedia1-common-devel regards, Stefan -- 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 get this error : libkdemultimedia1-noatun-devel-3.1.3-16mdk.i586 (devel(libartsmidi_idl) unsatisfied) (Y/n) Thank you,
[Cooker] [Bug 6319] [libkdemultimedia1-noatun-devel] I can' install the package
http://qa.mandrakesoft.com/show_bug.cgi?id=6319 --- Additional Comments From [EMAIL PROTECTED] 2003-08-11 20:10 --- [lrathle] wrote: ^^^ remove the leading ( urpmq devel(libartsgui_kde) regards, Stefan -- 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 get this error : libkdemultimedia1-noatun-devel-3.1.3-16mdk.i586 (devel(libartsmidi_idl) unsatisfied) (Y/n) Thank you,
Re: [Cooker] reliable mirrors . . .
Le Jeudi 06 Novembre 2003 22:00, Stefan van der Eijk a écrit : Really nice site, very usefull, but what is your reference point? The reference is the hdlist on the ftp. Which ftp? On a ftp, urpmi will get it (or synthesis). So after getting the file, all files who can be DL are referenced in this file. Having more files in directory than listed in the hdlist isn't bad, but missing files makes trouble. So the current script: * Download the hdlist * Make a list of all rpm listed in the hdlist. * Look for these files in the directory * Count the missing files (files listed in hdlist, but not present on ftp) At end, the script print the number of missing files. This is done only for RPMS from cooker, and for contrib. When someone want to install a cooker or work on it, he need a coherent FTP who can provide rpms in sync with the hdlist. This was the bad problem who was present some months ago with mirrors (hdlist not sync-ed). Having a up to date mirror sync-ed with kenobi is more difficult, and for me, cannot be done, as rpms are updated continuously. Emmanuel
Re: [Cooker] reliable mirrors . . .
Perhaps the mtime of the hdlist (or synthesis) files should be compared, together with the SHA1 hash of these files. Since these files are regenerated a few times throughout the day, perhaps the version of these files can be tracked and compared. regards, Stefan
Re: [Cooker] reliable mirrors . . .
Warly wrote: John Allen [EMAIL PROTECTED] writes: On Thursday 06 November 2003 20:35, Blindauer Emmanuel wrote: Le Jeudi 06 Novembre 2003 18:14, Robert Fox a écrit : Maybe someone should be a mirror monitor and be the main point of contact with the mirror owners when something goes wrong! http://extasia.u-strasbg.fr/~blindaue/mirrors.php You don't do uninett.no Also it would be better to test the mirrors against the hdlist/synthesis of the master site (wherever that is) updates every 2 hours the status of mirrors, looking into hdlist.cz and looking for the files inside to be present in the directory of the ftp. But I can't test more than that. I tried to have a more efficient rsync process to our mirror reference machine (I decrease contrib frequency mirroring to test if main only can be kept correctly up to date). Maybe we will have to switch to a every 2 hour frequency if one hour delay is too short for mirror to catch on. I'm sorry, but this doesn't sound right. I'm behind a crappy cable connection and I'm capable of pulling a good mirror, every hour, from kenobi. If kenobi was updated every 10mins, I would probably sync every 10 mins. I can't imagine why cooker.mandrakesoft.com shouldn't be able to do the same... IMHO cutting down on the frequency won't help, it'll just worsen the problem. What you need to do is make sure that you don't mirror the same thing twice -- i.e. don't start a second mirror process if the first one is still running. I'm running the following cronjobs for my mirrors: 0 0-22/2 * * * if [ `ps -u $UID | grep all.sh | wc -l` = 0 ]; then ~/bin/all.sh cooker upload /dev/null 21 ; fi 0 1-23/2 * * * if [ `ps -u $UID | grep all.sh | wc -l` = 0 ]; then ~/bin/all.sh cooker /dev/null 21 ; fi on the even hours packages are uploaded (ftpcooker / ftpcontrib is invoked) on the odd hours they aren't. If the all.sh script is found running under the current user, then a new one doesn't start. Increasing the frequency will make the mirror more up2date and decrease the load on it -- if you need to tranfer 100Mb, it's better to do it 12* 8.125Mb spread over the hour than 1* 100Mb at :00. Again, just make sure you don't two all.sh running. please take this into consideration. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] reliable mirrors . . .
Emmanuel, Maybe someone should be a mirror monitor and be the main point of contact with the mirror owners when something goes wrong! http://extasia.u-strasbg.fr/~blindaue/mirrors.php Really nice site, very usefull, but what is your reference point? Your site says that sunet is up2date, yet after a fresh ( illegal) mirror fron kenobi (IMHO the one and only true source) the following src.rpm are removed: 1449 files to consider deleting lftp-2.6.8-1mdk.src.rpm deleting kdepim-3.1.93-6mdk.src.rpm deleting kdemultimedia-3.1.93-4mdk.src.rpm deleting kdelibs-3.1.93-11mdk.src.rpm deleting kdebase-3.1.93-13mdk.src.rpm deleting kdeadmin-3.1.93-5mdk.src.rpm deleting gnopernicus-0.7.1-1mdk.src.rpm deleting gda2.0-1.0.1-1mdk.src.rpm deleting gail-1.4.1-1mdk.src.rpm deleting fetchmail-6.2.5-1mdk.src.rpm deleting evolution-1.4.5-1mdk.src.rpm deleting drakxtools-9.3-3mdk.src.rpm deleting drakconf-9.3-1mdk.src.rpm deleting clips-6.21-3mdk.src.rpm deleting atk1.0-1.4.1-1mdk.src.rpm My conclusion is that sunet.se is *not* up2date, the reference point needs to be adjusted to the systems at the office in Paris (rue d'Aboukir). updates every 2 hours the status of mirrors, looking into hdlist.cz and looking for the files inside to be present in the directory of the ftp. But I can't test more than that. True, cause you don't have access to what should be your reference point. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] reliable mirrors . . .
Olivier Blin wrote: On Thu, 6 Nov 2003 23:04:34 +0100 Guillaume Rousse [EMAIL PROTECTED] wrote: I'd really like to have someting as RSS to publish mirrors list. Mandrake would publish it this way, third-party projects as PLF or JPackage would also, and tools as urpmi.setup could easily retrieve and use them... That could also be used by the network install, to be more friendly, it would let the user pick an entry in the mirror list, what do you think of it ? Let's do it! smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] urpmi-4.4-42mdk
Thierry Vignaud wrote: Guillaume Rousse [EMAIL PROTECTED] writes: Guillaume Rousse [EMAIL PROTECTED] 4.4-42mdk - added bash-completion - spec cleanup - bziped additional sources this package and especially its spec file is in cvs. Shouldn't the .spec file contain a header to warn the packager? Such as: # Changed by Makefile of cvs. # Please change this file only in cvs! See: http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowTo#Packages_maintained_in_CVS regards, Stefan i just committed your changes in cvs but do not forget this when altering packages whose upstream maintainer is mandrake and ask someone to commit them back into cvs smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] urpmi noarch source
Hi, Since cooker has been defrosted, perhaps this is the right moment to discuss putting the .noarch.rpm packages into a seperate (shared) location. This is already being done at PLF, see: ftp://ftp.easynet.fr/plf/mandrake/cooker With the recent upload of a number of rather large noarch.rpm packages: $ ls -Sl /mirrors/contrib/i586/ | less total 2927844 *-rw-rw-r--1 stefan build136673076 Nov 5 16:09 uqm-data-0.3-1mdk.noarch.rpm* *-rw-rw-r--1 stefan build122147932 Nov 5 16:09 vegastrike-data-0.4.1-1mdk.noarch.rpm* -rw-rw-r--1 stefan build77352529 Oct 28 19:46 flightgear-0.9.3-1mdk.i586.rpm *-rw-rw-r--1 stefan build67695745 Mar 11 2003 tetex-cmsuper-0.3.3-2mdk.noarch.rpm* -rw-rw-r--1 stefan build60821073 Feb 28 2003 ncbi-tools-6.1-1mdk.i586.rpm -rw-rw-r--1 stefan build56017805 Oct 28 01:00 freedroidRPG-0.9.9-1mdk.i586.rpm *-rw-rw-r--1 stefan build54203818 Nov 5 16:09 vegastrike-data-music-0.3.1-1mdk.noarch.rpm * it's becoming evident that a lot of bandwidth and space is being wasted on the mirrors. Of the (7) packages in contrib above 50Mb, 4 of them are noarch.rpm's. I'll bet a case of Grolsch that the other ones can also be split up into (large) noarch.rpm and (smaller) arch.rpm packages. How did PLF do it? How is it working there (comments please!)? Can this be implemented for cooker (and the 10.0 release)? regards, Stefan van der Eijk smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] Internal Server Error [qa.mandrakesoft.com]
I'm getting these errors regularly on qa.mandrakesoft.com: === Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache-AdvancedExtranetServer/2.0.47 (Mandrake Linux/4mdk) mod_perl/1.99_09 Perl/v5.8.1 mod_ssl/2.0.47 OpenSSL/0.9.7b Server at qa.mandrakesoft.com Port 80 ===
Re: [Cooker] urpmi --auto-select + recompile from src.rpm
Hello, I was wondering, if there is some way to upgrade (or install) new packages form src.rpm source packages, rather than from precompiled i586.rpm packages, with the ease urpmi provides, so that one could fully benefit from his/her CPU. urpmi --auto-selects can only be used to upgrade precompiled packages, and won't help much if someone wants to update whole system from source src.rpm packages. What I mean, if there is some script, that would download new src.rpm packages from let's say cooker, recompile them for a given architecture, and than install. Doing this manually is somewhat long, slow, monotonous... Regards, Tomasz Chmielewski Perhaps slbd may suite your needs... http://qa.mandrakesoft.com/twiki/bin/view/Main/SlBd regards, Stefan
[Cooker] [Bug 6020] [gimp] circular Build dependency with printer-drivers
http://qa.mandrakesoft.com/show_bug.cgi?id=6020
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-10-23 15:53 ---
I guess it ain't that easy:
http://eijk.homelinux.org/build/new_cooker/sparc/problem/gimp-1.2.5-6mdk
checking for sendmail... no
checking for gimpprint-config... no
configure: error:
*** Check for libgimpprint failed. You can download it from
*** http://gimp-print.sourceforge.net/ or you can build without it by passing
*** --disable-print to configure (but you won't be able to print then).
error: Bad exit status from /home/slbd/tmp/rpm-tmp.6738 (%build)
if the --disable-print switch is passed and some other minor changes to the
.spec file the package does compile:
--- gimp.spec.orig 2003-10-01 15:36:01.0 +0200
+++ gimp.spec 2003-10-23 15:31:58.0 +0200
@@ -44,7 +44,9 @@
Provides: gimp-data-min
Requires: gtk+ = 1.2.8 glib = 1.2.8
Requires: %{svlibname} = %version-%release, aalib
-BuildRequires: libbmpeg-devel, libpng-devel, libjpeg-devel,
aalib-devel, xpm-devel, gpm-devel, gnome-libs-devel, ncurses-devel, slang-devel,
libtiff-devel, perl-devel = %{perlver}, perl-Parse-RecDescent, perl-PDL =
2.4.0-1mdk, perl-GTK, libgimpprint-devel = 4.2
+BuildRequires: libbmpeg-devel, libpng-devel, libjpeg-devel,
aalib-devel, xpm-devel, gpm-devel, gnome-libs-devel, ncurses-devel, slang-devel,
libtiff-devel, perl-devel = %{perlver}, perl-Parse-RecDescent, perl-PDL =
2.4.0-1mdk, perl-GTK
+# do not require libgimpprint-devel since gimp-print is built by printer-utils
+# BuildRequires: libgimpprint-devel = 4.2
BuildRequires: glib-gettextize, gettext-devel
#gtk-doc is needed to build, but currently broken
@@ -172,7 +174,7 @@
%endif
perl -pi -e s/(|\|-l| )mpeg/\1bmpeg/g configure
-%configure2_5x --with-mp=yes
+%configure2_5x --with-mp=yes --disable-print
eval `perl -V:installarchlib`
perl -pi -e s!-Wl,-rpath,$installarchlib/CORE!!g plug-ins/perl/Makefile
@@ -200,7 +202,7 @@
#
# Remove the GIMP-Print plugin
#
-rm $RPM_BUILD_ROOT/%_libdir/gimp/%subver/plug-ins/print
+#rm $RPM_BUILD_ROOT/%_libdir/gimp/%subver/plug-ins/print
#
# This perl madness will drive me batty
@@ -436,6 +438,9 @@
%changelog
+* Wed Oct 01 2003 Stefan van der Eijk [EMAIL PROTECTED] 1.2.5-7mdk
+- Remove libgimpprint-devel BuildRequires
+
* Sat Sep 06 2003 Thierry Vignaud [EMAIL PROTECTED] 1.2.5-6mdk
- fix #4950 (missing mime type in menu entry)
--- Additional Comments From [EMAIL PROTECTED] 2003-10-26 14:44 ---
fixes implemented in gimp-1.2.5-7mdk
--
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:
libgimpprint-devel is required to build gimp. This package is built by
printer-drivers. Printer-drivers requires gimp-devel to be built. This results
in a circular build dependency.
Some package requested cannot be installed:
gimp-1.2.5-6mdk.src (due to unsatisfied libgimpprint-devel[= 4.2])
http://eijk.homelinux.org/build/cooker/urpmi/sparc/gimp-1.2.5-6mdk
Some package requested cannot be installed:
printer-drivers-1.0-116mdk.src (due to unsatisfied gimp-devel)
http://eijk.homelinux.org/build/cooker/urpmi/sparc/printer-drivers-1.0-116mdk
[Cooker] [Bug 6041] [gnome-db] DOC_DIR is incorrect in %makeinstall
http://qa.mandrakesoft.com/show_bug.cgi?id=6041
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-10-26 14:46 ---
fixed in gnome-db-0.2.96-10mdk
--
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 DOC_DIR is set incorrectly so the %makeinstall fails. Affects all platforms.
This diff fixes it:
$ diff gnome-db.spec.orig gnome-db.spec
15c15
Release: 9mdk
---
Release: 10mdk
103c103
%makeinstall_std DOC_DIR=%{_datadir}/gnome/html
---
%makeinstall_std DOC_DIR=$RPM_BUILD_ROOT%{_datadir}/gnome/html
177a178,180
* Thu Oct 02 2003 Stefan van der Eijk [EMAIL PROTECTED] 0.2.96-10mdk
- fix install path for docs
[Cooker] [Bug 6232] [userdrake] New: BuildRequires: pam-devel missing
http://qa.mandrakesoft.com/show_bug.cgi?id=6232 Summary: BuildRequires: pam-devel missing Product: userdrake Version: 0.92-9mdk Platform: PC URL: http://eijk.homelinux.org/build/cooker/i586/problem/user drake-0.92-24mdk OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] See URL: rm -f blib/arch/auto/USER/USER.so LD_RUN_PATH= gcc -shared -L/usr/local/lib USER.o -o blib/arch/auto/USER/USER.so -luser -lcrypt -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpam_misc -lpam /usr/bin/ld: cannot find -lpam_misc collect2: ld returned 1 exit status make: *** [blib/arch/auto/USER/USER.so] Error 1 error: Bad exit status from /home/slbd/tmp/rpm-tmp.15774 (%build) -- 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 6232] [userdrake] BuildRequires: pam-devel missing
http://qa.mandrakesoft.com/show_bug.cgi?id=6232 --- Additional Comments From [EMAIL PROTECTED] 2003-10-26 17:03 --- Created an attachment (id=937) -- (http://qa.mandrakesoft.com/attachment.cgi?id=937action=view) diff for userdrake.spec file -- 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: See URL: rm -f blib/arch/auto/USER/USER.so LD_RUN_PATH= gcc -shared -L/usr/local/lib USER.o -o blib/arch/auto/USER/USER.so -luser -lcrypt -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpam_misc -lpam /usr/bin/ld: cannot find -lpam_misc collect2: ld returned 1 exit status make: *** [blib/arch/auto/USER/USER.so] Error 1 error: Bad exit status from /home/slbd/tmp/rpm-tmp.15774 (%build)
[Cooker] [Bug 6233] [drakfirsttime] New: BuildRequires missing
http://qa.mandrakesoft.com/show_bug.cgi?id=6233 Summary: BuildRequires missing Product: drakfirsttime Version: 0.92-3mdk Platform: PC URL: http://eijk.homelinux.org/build/cooker/i586/problem/drak firsttime-0.92-4.2.92mdk OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] See URL: make[1]: Entering directory `/home/slbd/RPM/BUILD/drakfirsttime-0.92/po' perl_checker -q --generate-pot drakfw.pot ../drakfw ../drakfirsttime/data.pm ../drakfirsttime/gui.pm ../drakmail make[1]: perl_checker: Command not found make[1]: *** [drakfw.pot] Error 127 make[1]: Leaving directory `/home/slbd/RPM/BUILD/drakfirsttime-0.92/po' make: *** [all] Error 2 error: Bad exit status from /home/slbd/tmp/rpm-tmp.89453 (%install) -- 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 6233] [drakfirsttime] BuildRequires missing
http://qa.mandrakesoft.com/show_bug.cgi?id=6233 --- Additional Comments From [EMAIL PROTECTED] 2003-10-26 17:09 --- Created an attachment (id=938) -- (http://qa.mandrakesoft.com/attachment.cgi?id=938action=view) diff for drakfirsttime.spec -- 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: See URL: make[1]: Entering directory `/home/slbd/RPM/BUILD/drakfirsttime-0.92/po' perl_checker -q --generate-pot drakfw.pot ../drakfw ../drakfirsttime/data.pm ../drakfirsttime/gui.pm ../drakmail make[1]: perl_checker: Command not found make[1]: *** [drakfw.pot] Error 127 make[1]: Leaving directory `/home/slbd/RPM/BUILD/drakfirsttime-0.92/po' make: *** [all] Error 2 error: Bad exit status from /home/slbd/tmp/rpm-tmp.89453 (%install)
Re: [Cooker] uncompress package not exist ?
Hello , The software Informix and Borland C++ Builder X and other require uncompress , but urpmi uncompress not found. At this momement there is no package in cooker (or contrib) that Provides uncompress: $ urpmq uncompress no package named uncompress However, the ncompress package contains the uncompress binary: $ urpmf bin/uncompress ncompress:/usr/bin/uncompress regards, Stefan And rpmfind.org find just cooker version. Please , create this. Thank you
[Cooker] Re: [Maintainers] rejected uploads
sorry about this... I think that you are some difficulties to understand when I say something to you. You are not autorize to upload KDE package ! You can send me patch. The last time you broke arts during my holiday. Excuse me? Arts was not broken by me, it was already broken. Sorry before my holydays we could install packages. If you count that arts was already installed, then yes. Otherwise: no. After we coudn't. And the people who uploaded it it was YOU ! excuse me, but this is too easy. The arts package was not the one that broke it. Some other package broke it, and as long as the arts package wasn't replaced, it was fine. So replacing or reinstalling the arts package equals to breaking it? And when you claimed to have fixed it, it was still broken... Remember? No reply to this comment? Strange... It's easy to blame somebody without looking at what is _really_ going on. Come on, investigate and look at the root cause before you blame somebody. The arts issue was, in the end, due to other packages having epochs attached to them. We've had similar issues with perl and gaim for a while. Now you de-synchronize cooker and conflict with my packages. Cooker is already de-syncronized anyway. it is true when the people upload without thinking yep... happens all the time. But of course, only contributors screw-up, right? Q: Which one is leading at the moment? amd64 or i586? So DON'T TOUCH KDE PACKAGE !! fix the upload rules... check on src.rpm and not on binary rpm... Warly bugs. Warly, can you put this as a requirement for the new upload mechanism? That it checks on the src.rpm, and not on the name of the binary rpm? I hope that you understand ! Sure, the issue is that I have had bad experiences working with you. Same problem for me, and I am not the only one to have problems with you. Interesting... Many contributors are also always complaining about the same mdk employees (the same ones that comlain about us)... I guess this goes both ways :-) What I also find interesting is it's always the me (or other contributors) that doing things wrong or seeing things incorrectly. All approaches to these mdk employees to find a way to cooperate remain unanswered. Your reply is evidence of this, again. If applogizing doesn't help and neither does offering to leave things behind us and find a way to cooperate, how do you want things to improve? Ignoring e-mails, denying the truth (about BuildRequire, etc), which causes this behaviour from my side. If the kde packages would be in good state, kde packagers would implement patches smoothly then this situation wouldn't exist. And you created better packages ? Yes, I think so. I think that I have contributed quite a bit over the last few years, re-read cooker... Re-read cooker and looks at all the problems which you created. Please re-read the lists, I have the feeling you're slightly mis-informed. The most changes (to packages) I've put through have not touched the package at all. They mostly involved fixing dependency issues (BuildRequires, etc). These changes do not break things, unless the breakage was already there (arts), and then it only becomes visible. Changes to packages that involve chaning the content of a package (version changes, patches, etc) from me are rare. I would like to propose that we put all of this behind us and find a *structured* way to improve the packages that meets the need of the official maintainers and the contributors. sadly, no answer from Laurent, as usual... regards, Stefan
Re: [Cooker] Test kernel 2.4.22-12mdk
On Mon, 13 Oct 2003 17:24:06 +0200 (CEST) Stefan van der Eijk [EMAIL PROTECTED] wrote: I just built the 6Gb i686 version. Besides lilo complaining about labels that are too long it was a hitchless upgrade. Whenever I tried the 6Gb i686, rebuilt for athlon, be it either mdk or tmb after 24 hrs, almost to the min. system would lock-up. hmmm. I didn't change the .config file, just enabled to build the i686-up-4GB kernel in the .spec file. It's running stable since yesterday afternoon on my Athlon 1800XP. Although the DMA on my IBM harddisk (IC35L120AVV207-0) is still turned off after a while. Thomas is aware of this, we're still chasing the issue. regards, Stefan
[Cooker] urpmi.update broken?
Has anybody else noticed that urpmi.update may be broken? when I run urpmi.update, it doesn't pick up changes. Removing the media and adding it again lets it pick up the changes. # urpmq libltdl3 -r libltdl3-1.4.3-7mdk # urpmi.update -a # urpmq libltdl3 -r libltdl3-1.4.3-7mdk # urpmi.removemedia cooker # urpmi.addmedia cooker file://mirrors/cooker/i586/Mandrake/RPMS with ../base/hdlist.cz # urpmq libltdl3 -r libltdl3-1.4.3-8mdk regards, Stefan
Re: [Cooker] urpmi.update broken?
On Tuesday 14 October 2003 4:45 am, Stefan van der Eijk wrote: Has anybody else noticed that urpmi.update may be broken? when I run urpmi.update, it doesn't pick up changes. Removing the media and adding it again lets it pick up the changes. # urpmq libltdl3 -r libltdl3-1.4.3-7mdk # urpmi.update -a # urpmq libltdl3 -r libltdl3-1.4.3-7mdk # urpmi.removemedia cooker # urpmi.addmedia cooker file://mirrors/cooker/i586/Mandrake/RPMS with ../base/hdlist.cz # urpmq libltdl3 -r libltdl3-1.4.3-8mdk regards, Stefan In order to get urpmi to update my sources I have to almost constantly use urpmi.update -a --no-md5sum. Can you see if this is the problem? # urpmi.update cooker examining MD5SUM file copying source hdlist (or synthesis) of cooker... ...copying done computing md5sum of copied source hdlist (or synthesis) copy of [/mirrors/cooker/i586/Mandrake/base/hdlist.cz] failed reading rpm files from [/mirrors/cooker/i586/Mandrake/RPMS] /var/cache/urpmi/headers/eroaster-2.1.0-11mdk.noarch /var/cache/urpmi/headers/eroaster-2.1.0-10mdk.noarch /var/cache/urpmi/headers/spec-helper-0.9.2-3mdk.noarch unable to write list file of cooker writing list file for medium cooker examining synthesis file [/var/lib/urpmi/synthesis.hdlist.cooker.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.contrib.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.plf.cz] performing second pass to compute dependencies examining hdlist file [/var/lib/urpmi/hdlist.cooker.cz] examining hdlist file [/var/lib/urpmi/hdlist.contrib.cz] built hdlist synthesis file for medium contrib examining hdlist file [/var/lib/urpmi/hdlist.plf.cz] built hdlist synthesis file for medium plf found 6813 headers in cache removing 0 obsolete headers in cache write config file [/etc/urpmi/urpmi.cfg] now, with the --no-md5sum: # urpmi.update cooker --no-md5sum copying source hdlist (or synthesis) of cooker... ...copying done examining hdlist file [/var/cache/urpmi/partial/hdlist.cooker.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.contrib.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.plf.cz] performing second pass to compute dependencies examining hdlist file [/var/lib/urpmi/hdlist.cooker.cz] built hdlist synthesis file for medium cooker examining hdlist file [/var/lib/urpmi/hdlist.contrib.cz] built hdlist synthesis file for medium contrib examining hdlist file [/var/lib/urpmi/hdlist.plf.cz] built hdlist synthesis file for medium plf found 6813 headers in cache removing 0 obsolete headers in cache write config file [/etc/urpmi/urpmi.cfg] looks like it... Stefan
Re: [Cooker] Test kernel 2.4.22-12mdk
I just built the 6Gb i686 version. Besides lilo complaining about labels that are too long it was a hitchless upgrade. Removed acpi=off from the append line, and everything is working! I see 3 USB busses (6 ports in total). Networking works, IDE is at UDMA133 (disk only goes to UDMA100). excellent work!! Stefan 1.) it would be good to update the acpi to the latest release. it would probably solve most of the acpi irq problems for most KT400 Nforce2 boards with USB or onboard LAN acpi 20031002 is in my kernel-tmb-2.4.22.12.tmb.1mdk that should hit the mirrors soon... and are already at: www.iki.fi/tmb/Cooker/ along with the BadRAM fix and some other stuff... So for any of you that have a nForce2 or KT400 boards... go grab it and let me know if you are as happy as I am ;-) 2.) what about the usb updates that went in 23-pre5 - 23-pre6 - various fixes - usb gadgets support Theese goes into my 2mdk 3.) what about device-mapper (LVM2 support) ? Thomas could you also take a look ? Theese goes into my 2mdk [...] it seems there is a new acpi release 20032002, but it's not fully uploaded yet ? I grabbed them directly from the acpi site... Since not everything got added to this build, I'll hope to have the next one out tomorrow -- Regards Thomas
[Cooker] [Bug 6119] [autofs] New: [amd64] parsing autofs names goes wrong
http://qa.mandrakesoft.com/show_bug.cgi?id=6119 Product: autofs Component: program Summary: [amd64] parsing autofs names goes wrong Product: autofs Version: 4.0.0-0.19mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] after putting a symlink (/usr/lib64/autofs -- /usr/lib/autofs), otherwise autofs won't start, see bug 5351: When I do ls /build/plf the following shows up in the log files, as you can see, it is looking up /build/: Oct 9 21:10:00 turaco automount[930]: attempting to mount entry /build/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=nisObject)(cn=)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): no entry for found, trying cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=nisObject)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): getting first entry for cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): query succeeded, no matches for ((objectclass=nisObject)(cn=/)) Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=automount)(cn=)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): no entry for found, trying cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): searching for ((objectclass=automount)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): getting first entry for cn=/ Oct 9 21:10:00 turaco automount[1144]: lookup(ldap): query succeeded, no matches for ((objectclass=automount)(cn=/)) For ls /build/cooker it only looks up /build/er : Oct 9 21:20:00 turaco automount[930]: attempting to mount entry /build/er Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): searching for ((objectclass=nisObject)(cn=er)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): no entry for er found, trying cn=/ Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): searching for ((objectclass=nisObject)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): getting first entry for cn=/ Oct 9 21:20:03 turaco automount[1142]: lookup(ldap): query succeeded, no matches for ((objectclass=nisObject)(cn=/)) Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): searching for ((objectclass=automount)(cn=er)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): no entry for er found, trying cn=/ Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): searching for ((objectclass=automount)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): getting first entry for cn=/ Oct 9 21:20:06 turaco automount[1142]: lookup(ldap): query succeeded, no matches for ((objectclass=automount)(cn=/)) For ls /build/cookcooker it only looks up /build/cooker: Oct 9 21:40:00 turaco automount[930]: attempting to mount entry /build/cooker Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): searching for ((objectclass=nisObject)(cn=cooker)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): no entry for cooker found, trying cn=/ Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): searching for ((objectclass=nisObject)(cn=/)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): getting first entry for cn=/ Oct 9 21:40:03 turaco automount[1162]: lookup(ldap): query succeeded, no matches for ((objectclass=nisObject)(cn=/)) Oct 9 21:40:07 turaco automount[1162]: lookup(ldap): searching for ((objectclass=automount)(cn=cooker)) under ou=auto.build,dc=mandrake,dc=vpn Oct 9 21:40:07 turaco automount[1162]: lookup(ldap): examining first entry Oct 9 21:40:07 turaco automount[1162]: lookup(ldap): entry 0 is anorien:/data/build/ Oct 9 21:40:07 turaco automount[1162]: parse(sun): expanded entry: anorien:/data/build/cooker Oct 9 21:40:07 turaco automount[1162]: parse(sun): gathered options: Oct 9 21:40:07 turaco automount[1162]: parse(sun): dequote(anorien:/data/build/cooker) - anorien:/data/build/cooker Oct 9 21:40:07 turaco automount[1162]: parse(sun): core of entry: options=, loc=anorien:/data/build/cooker Oct 9 21:40:07 turaco kernel: automount[1162]: segfault at 007f54907738 rip 002a964aac37 rsp 007f54907740 error 6 I guess the first 4 characters in to be mounted directories name get lost. This only takes place on amd64 (alpha, i586 and sparc are fine) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are
[Cooker] Re: [Maintainers] Cooker and AMD64
Frederic, I've got access to an amd64 machine and have been rebuilding cooker main and contrib packages on that host with slbd. I've been uploading the contrib packages, but not the main packages due to specific request from Gwenole. At this moment I've got over 250 cooker packages with the same version-release number as in i586 cooker, but that aren't in the amd64 tree. For alpha and sparc these packages would be uploaded by my upload bot. Can these packages be of any use? I think it would be more effective if MDK staff would spend their time testing the product instead of building it (manually). In the end, most packages won't need to be changed, and for the packages that are changed (after testing as revealed a fault), those changes will end up in the SRPMS. and, I guess most contributors are waiting for cooker/main to open up again. This may speed up this process (without sacrificing quality). just trying to help out... Stefan Frederic Lepied wrote: Cooker is still frozen and will remain frozen until the 9.2 AMD64 version is finished. Only src.rpm modified for the AMD64 port are allowed to be uploaded in main. We need to do that because we don't want to fork the 9.2. To be able to use these src.rpm for 9.2 security updates on the ia32 architecture, recompile your packages on ia32 and test them to see if there is a regression. If all is ok, upload the resulting binaries to cooker. If there is a problem, create a new src.rpm with a new release, upload them to cooker and send a mail to Gwenole to warn him about the problem. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] cooker alive and well
Warly wrote: Austin [EMAIL PROTECTED] writes: FINALLY! Cooker seems to be re-opened, so I hope we can stop all this political/ bureaucratic/philosophical banter and start developing an operating system again! No it is not, just a mistake. We want the amd64 to be merged and finished before an opening. I have 271 slbd built amd64 cooker packages that I can upload. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] cooker alive and well
Gwenole Beauchesne wrote: On Tue, 7 Oct 2003, Stefan van der Eijk wrote: We want the amd64 to be merged and finished before an opening. I have 271 slbd built amd64 cooker packages that I can upload. cooker packages or contrib packages? that's not the same... I am automatically rebuilding cooker main and cooker contrib packages on the amd64 box at CSC. I'm only uploading cooker contrib. But I also have 271 cooker packages that can be uploaded, but I won't because I'm not supposed to -- you said I couldn't. anyway, enjoy building manually... I keep track and I'll see the numbers of packages that I _could_ upload go down, as you catch up :-) regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] cooker alive and well
Gwenole Beauchesne wrote: On Tue, 7 Oct 2003, Stefan van der Eijk wrote: I am automatically rebuilding cooker main and cooker contrib packages on the amd64 box at CSC. I'm only uploading cooker contrib. But I also have 271 cooker packages that can be uploaded, but I won't because I'm not supposed to -- you said I couldn't. Indeed, because there are no extra package you could provide in main that are not already available. Unless you fixed the remaining ones that has to. anyway, enjoy building manually... I keep track and I'll see the numbers of packages that I _could_ upload go down, as you catch up :-) Ahaha, you are really funny Stefan, GB, you're funny too! packages I rebuild manually are those that needs to be fixed. But of course, I suppose your marvellous slbd script auto-fixes packages, isn't it? Uh... it just builds them... AFAIK all changes should be in the SRPMS, shouldn't they? Or am I missing something? So the packages resulting from rebuilding the packages in SRPMS should contain the fixes. Now, let's see what the number is today: $ ~/bin/amd64_upload_cooker.sh | wc -l 265 That's 6 less than the last time I checked... regards, Stefan acpid-1.0.2-4mdk apache2-2.0.47-6mdk apache2-common-2.0.47-6mdk apache2-devel-2.0.47-6mdk apache2-manual-2.0.47-6mdk apache2-mod_auth_mysql-2.0.47_1.11-3mdk apache2-mod_auth_pgsql-2.0.47_2.0.1-3mdk apache2-mod_cache-2.0.47-6mdk apache2-mod_dav-2.0.47-6mdk apache2-mod_deflate-2.0.47-6mdk apache2-mod_disk_cache-2.0.47-6mdk apache2-mod_file_cache-2.0.47-6mdk apache2-mod_ldap-2.0.47-6mdk apache2-mod_mem_cache-2.0.47-6mdk apache2-mod_proxy-2.0.47-6mdk apache2-mod_ssl-2.0.47-6mdk apache2-modules-2.0.47-6mdk apache2-source-2.0.47-6mdk apache-conf-2.0.47-8mdk apache-suexec-1.3.28-1mdk at-spi-1.3.7-1mdk bg5ps-1.3.0-7mdk bind-9.2.3-0.rc2.1mdk bind-devel-9.2.3-0.rc2.1mdk bind-utils-9.2.3-0.rc2.1mdk bootloader-utils-1.6-3mdk bootsplash-2.0.6-1mdk bug-buddy-2.4.0-1mdk cim-3.36-5mdk console-tools-0.2.3-46mdk cups-1.1.19-10mdk cups-common-1.1.19-10mdk cups-drivers-1.1-116mdk cups-serial-1.1.19-10mdk dia-0.91-9mdk drakxtools-9.2-16mdk drakxtools-http-9.2-16mdk drakxtools-newt-9.2-16mdk epiphany-1.0-1mdk epiphany-devel-1.0-1mdk exif-0.6-3mdk fbtv-3.88-4mdk foomatic-db-3.0-1.20030908.3mdk foomatic-db-engine-3.0-1.20030908.3mdk foomatic-filters-3.0-1.20030908.3mdk gail-1.4.0-2mdk gal2.0-1.99.9-3mdk gcc-3.3.1-2mdk gcc-c++-3.3.1-2mdk gcc-colorgcc-3.3.1-2mdk gcc-cpp-3.3.1-2mdk gcc-doc-3.3.1-2mdk gcc-doc-pdf-3.3.1-2mdk gcc-g77-3.3.1-2mdk gcc-gnat-3.3.1-2mdk gcc-gpc-3.3.1-2mdk gcc-java-3.3.1-2mdk gcc-objc-3.3.1-2mdk gcj-tools-3.3.1-2mdk gdb-5.3-25mdk gexif-0.5-5mdk ghostscript-7.07-0.12mdk ghostscript-module-X-7.07-0.12mdk gimpprint-4.2.5-30mdk glade-0.6.4-5mdk glade2-2.0.0-3mdk gnome-desktop-2.4.0-1mdk gnome-mime-data-2.4.0-2mdk gnome-pilot-2.0.10-3mdk gnome-speech-0.2.7-1mdk gnome-utils-2.4.0-1mdk gpdf-0.110-1mdk gphoto2-2.1.2-1mdk gtk+2.0-2.2.4-2mdk gtkam-0.1.11-0.dev1.6mdk gtksourceview-0.6.0-4mdk gucharmap-1.0.0-1mdk g-wrap-1.3.4-9mdk harddrake-9.2-16mdk harddrake-ui-9.2-16mdk icewm-1.2.13-0.3.1mdk icewm-gnome-1.2.13-0.3.1mdk icewm-light-1.2.13-0.3.1mdk initscripts-7.06-32mdk kdegraphics-3.1.3-35mdk kdegraphics-common-3.1.3-35mdk kdegraphics-kdvi-3.1.3-35mdk kdegraphics-kfax-3.1.3-35mdk kdegraphics-kghostview-3.1.3-35mdk kdegraphics-kiconedit-3.1.3-35mdk kdegraphics-kooka-3.1.3-35mdk kdegraphics-kpaint-3.1.3-35mdk kdegraphics-kpovmodeler-3.1.3-35mdk kdegraphics-kruler-3.1.3-35mdk kdegraphics-ksnapshot-3.1.3-35mdk kdegraphics-kuickshow-3.1.3-35mdk kdegraphics-kview-3.1.3-35mdk kdegraphics-mrmlsearch-3.1.3-35mdk kdeutils-3.1.3-20mdk kdeutils-ark-3.1.3-20mdk kdeutils-common-3.1.3-20mdk kdeutils-kcalc-3.1.3-20mdk kdeutils-kcharselect-3.1.3-20mdk kdeutils-kdepasswd-3.1.3-20mdk kdeutils-kdessh-3.1.3-20mdk kdeutils-kdf-3.1.3-20mdk kdeutils-kedit-3.1.3-20mdk kdeutils-kfloppy-3.1.3-20mdk kdeutils-khexedit-3.1.3-20mdk kdeutils-kjots-3.1.3-20mdk kdeutils-ksim-3.1.3-20mdk kdeutils-ktimer-3.1.3-20mdk lib64apr0-2.0.47-6mdk lib64at-spi0-1.3.7-1mdk lib64at-spi0-devel-1.3.7-1mdk lib64cim3-3.36-5mdk lib64cim3-devel-3.36-5mdk lib64console0-0.2.3-46mdk lib64console0-devel-0.2.3-46mdk lib64console0-static-devel-0.2.3-46mdk lib64cups2-1.1.19-10mdk lib64cups2-devel-1.1.19-10mdk lib64gail17-1.4.0-2mdk lib64gail17-devel-1.4.0-2mdk lib64gal2.0_5-1.99.9-3mdk lib64gal2.0_5-devel-1.99.9-3mdk lib64gdk_pixbuf2.0_0-2.2.4-2mdk lib64gdk_pixbuf2.0_0-devel-2.2.4-2mdk lib64gimpprint1-4.2.5-30mdk lib64gimpprint1-devel-4.2.5-30mdk lib64gnome-desktop-2_2-2.4.0-1mdk lib64gnome-desktop-2_2-devel-2.4.0-1mdk lib64gnome-pilot2-2.0.10-3mdk lib64gnome-pilot2-devel-2.0.10-3mdk lib64gnomespeech6-0.2.7-1mdk lib64gnomespeech6-devel-0.2.7-1mdk lib64gpio0-0.0.2-11mdk lib64gpio0-devel-0.0.2-11mdk lib64gtk+2.0_0-2.2.4-2mdk lib64gtk+2.0_0-devel-2.2.4-2mdk lib64gtk+-linuxfb-2.0_0-2.2.4-2mdk lib64gtk+-linuxfb-2.0_0-devel-2.2.4-2mdk lib64gtksourceview-1.0_0-0.6.0-4mdk lib64gtksourceview-1.0_0-devel
[Cooker] [Bug 5210] [gcc] [alpha] unrecognizable insn compiling fork.c of kernel (and glibc)
http://qa.mandrakesoft.com/show_bug.cgi?id=5210 --- Additional Comments From [EMAIL PROTECTED] 2003-07-10 14:50 --- some discussions about this in this thread: http://www.lib.uaa.alaska.edu/axp-list/archive/2003-09/0049.html -- 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'm seeing this behaviour on the alpha with recent version of gcc. This bug is preventing glibc and kernel packages from building. This bug has also been logged in gnu's gcc bugzilla, bug #11717: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11717 Examples of failing builds: http://eijk.homelinux.org/build/cooker/alpha/problem/kernel-2.4.22.3mdk-1-1mdk gcc -D__KERNEL__ -I/home/slbd/RPM/BUILD/kernel-2.4/linux-2.4.22/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -nostdinc -iwithprefix include -DKBUILD_BASENAME=fork -c fork.c -o fork.o fork.c: In function `dup_mmap': fork.c:151: error: unrecognizable insn: (insn 31 27 36 0 0x2daf2e8 (set (reg/v/f:DI 75) (symbol_ref:DI (@Lmmlist_lock))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI (@Lmmlist_lock)) (nil))) fork.c:151: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. http://eijk.homelinux.org/~stefan/glibc-2.3.2-14mdk mkdir /usr/src/RPM/BUILD/glibc-2.3.2/build-alpha-linux/libio fileops.c: In function `mmap_remap_check': fileops.c:612: error: unrecognizable insn: (insn 305 383 306 17 0x2abf0d8 (set (reg/f:DI 212) (symbol_ref:DI (@L_IO_file_jumps))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI (@L_IO_file_jumps)) (nil))) fileops.c:612: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. A quick search on google (recog.c 2175) shows that other platforms also have this issue. preprocessed source is available.
[Cooker] [Bug 6041] [gnome-db] New: DOC_DIR is incorrect in %makeinstall
http://qa.mandrakesoft.com/show_bug.cgi?id=6041
Product: gnome-db
Component: packaging
Summary: DOC_DIR is incorrect in %makeinstall
Product: gnome-db
Version: 0.2.96-9mdk
Platform: PC
URL: http://eijk.homelinux.org/build/cooker/i586/problem/gnom
e-db-0.2.96-9mdk
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: packaging
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The DOC_DIR is set incorrectly so the %makeinstall fails. Affects all platforms.
This diff fixes it:
$ diff gnome-db.spec.orig gnome-db.spec
15c15
Release: 9mdk
---
Release: 10mdk
103c103
%makeinstall_std DOC_DIR=%{_datadir}/gnome/html
---
%makeinstall_std DOC_DIR=$RPM_BUILD_ROOT%{_datadir}/gnome/html
177a178,180
* Thu Oct 02 2003 Stefan van der Eijk [EMAIL PROTECTED] 0.2.96-10mdk
- fix install path for docs
--
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 6020] [gimp] New: circular Build dependency with printer-drivers
http://qa.mandrakesoft.com/show_bug.cgi?id=6020 Product: gimp Component: packaging Summary: circular Build dependency with printer-drivers Product: gimp Version: 1.2.5-6mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] libgimpprint-devel is required to build gimp. This package is built by printer-drivers. Printer-drivers requires gimp-devel to be built. This results in a circular build dependency. Some package requested cannot be installed: gimp-1.2.5-6mdk.src (due to unsatisfied libgimpprint-devel[= 4.2]) http://eijk.homelinux.org/build/cooker/urpmi/sparc/gimp-1.2.5-6mdk Some package requested cannot be installed: printer-drivers-1.0-116mdk.src (due to unsatisfied gimp-devel) http://eijk.homelinux.org/build/cooker/urpmi/sparc/printer-drivers-1.0-116mdk -- 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.
Re: [Cooker] Opteron and nForce3
Frederic, CSC at Warwick is running a Penguin Computing Altus1000, see: http://qa.mandrakesoft.com/twiki/bin/view/Main/MdkPorts#amd64 This is the machine that is compiling the contribs at the moment. As far as I know, they've haven't had many issues with the box. It's running amd64 version of cooker at the moment, and it behaves like any other Mandrake box. Of course, it's a _very_ fast Mandrake box :-) regards, Stefan Has anyone on the cooker list had the privilege to try the upcoming 9.2 on an Opteron/nForce3 configuration (single or dual Opteron)? Yes, this also applies to nForce3 based Athlon64 systems. Disks I Were the disks using SATA? tested so far flied at around 57 MB/sec, i.e. faster than anything I used so far. Not only the disks were fast, the rest of the platform was obviously very fast too. ;-) What Opteron proc did you use? You can try yourself, Warly should have stopped generating broken hdlists for now. i.e. fully rsync'ed my tree from Friday. I'm thinking of getting such a system in the next 2-3 months :) I just wanted to ensure I would'nt get stuck with not very well supported *yet* hardware. Note to ASUS SK8N users: they must update their BIOS to something = 1002 first. I believe a bios version 1003_03 is available since 19/9/2003 (http://www.amdzone.com/#1). smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] nss_ldap-211-1mdk
[EMAIL PROTECTED] (Stefan van der Eijk) writes: This is a cryptographically signed message in MIME format. --ms090903010403020401070506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit After updating to nss_ldap-211-1mdk I'm getting errors as such: $ ls -l total 68060 ls: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen [EMAIL PROTECTED] stefan]$ ssh kenobi.mandrakesoft.com ssh: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen Anybody else? yes, I have it too ... so I think the best thing will be to go back to the 207 version for the moment ... Yes, I agree. Leave 211 for after 9.2. Stefan
Re: [Cooker] Re: [CHRPM] nss_ldap-211-1mdk
Florin wrote:
[EMAIL PROTECTED] (Stefan van der Eijk) writes:
[EMAIL PROTECTED] (Stefan van der Eijk) writes:
This is a cryptographically signed message in MIME format.
--ms090903010403020401070506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
After updating to nss_ldap-211-1mdk I'm getting errors as such:
$ ls -l
total 68060
ls: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen
[EMAIL PROTECTED] stefan]$ ssh kenobi.mandrakesoft.com
ssh: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen
Anybody else?
yes, I have it too ... so I think the best thing will be to go back to the
207 version for the moment ...
Yes, I agree. Leave 211 for after 9.2.
Can you try the 211-2mdk package at
http://people.mandrakesoft.com/~florin/www/rpms/ldap and tell me if it
works for you ?
Tried it, doesn't work :-(
If not, what is your /etc/ldap.conf file ?
Here it is:
# @(#)$Id: ldap.conf,v 2.28 2001/08/28 12:17:29 lukeh Exp $
#
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
#
# PADL Software
# http://www.padl.com
#
# Your LDAP server. Must be resolvable without using LDAP.
host ldap.eijk.nu
# The distinguished name of the search base.
base dc=eijk,dc=nu
# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator
# The LDAP version to use (defaults to 3
# if supported by client library)
ldap_version 3
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
binddn cn=proxyuser,dc=eijk,dc=nu
# The credentials to bind with.
# Optional: default is no credential.
bindpw ***
# The distinguished name to bind to the server with
# if the effective user ID is root. Password is
# stored in /etc/ldap.secret (mode 600)
#rootbinddn cn=manager,dc=eijk,dc=nu
# The port.
# Optional: default is 389.
#port 389
# The search scope.
#scope sub
scope one
#scope base
# Search timelimit
#timelimit 30
# Bind timelimit
#bind_timelimit 30
# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
#idle_timelimit 3600
# Filter to AND with uid=%s
pam_filter objectclass=account
# The user ID attribute (defaults to uid)
pam_login_attribute uid
# Search the root DSE for the password policy (works
# with Netscape Directory Server)
#pam_lookup_policy yes
# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=eijk,dc=nu
# Group member attribute
#pam_member_attribute gid
# Template login attribute, default template user
# (can be overriden by value of former attribute
# in user's entry)
#pam_login_attribute userPrincipalName
#pam_template_login_attribute uid
#pam_template_login nobody
# HEADS UP: the pam_crypt, pam_nds_passwd,
# and pam_ad_passwd options are no
# longer supported.
# Do not hash the password at all; presume
# the directory server will do it, if
# necessary. This is the default.
#pam_password clear
# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service.
#pam_password crypt
# Remove old password first, then update in
# cleartext. Necessary for use with Novell
# Directory Services (NDS)
#pam_password nds
# Update Active Directory password, by
# creating Unicode password and updating
# unicodePwd attribute.
#pam_password ad
# Use the OpenLDAP password change
# extended operation to update the password.
#pam_password exop
pam_password crypt
# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be 'd with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd ou=People,
# to append the default base DN but this
# may incur a small performance impact.
nss_base_passwd ou=People,dc=eijk,dc=nu
nss_base_shadow ou=People,dc=eijk,dc=nu
nss_base_group ou=Group,dc=eijk,dc=nu
#nss_base_hosts ou=Hosts,dc=eijk,dc=nu?one
#nss_base_services ou=Services,dc=eijk,dc=nu?one
#nss_base_networks ou=Networks,dc=eijk,dc=nu?one
#nss_base_protocols ou=Protocols,dc=eijk,dc=nu?one
#nss_base_rpc ou=Rpc,dc=eijk,dc=nu?one
#nss_base_ethersou=Ethers,dc=eijk,dc=nu?one
#nss_base_netmasks ou=Networks,dc=eijk,dc=nu?ne
#nss_base_bootparamsou=Ethers,dc=eijk,dc=nu?one
#nss_base_aliases ou=Aliases,dc=eijk,dc=nu?one
#nss_base_netgroup ou=Netgroup,dc=eijk,dc=nu?one
# attribute/objectclass mapping
# Syntax:
#nss_map_attribute rfc2307attributemapped_attribute
#nss_map_objectclass
[Cooker] Re: [CHRPM] nss_ldap-211-1mdk
After updating to nss_ldap-211-1mdk I'm getting errors as such: $ ls -l total 68060 ls: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen [EMAIL PROTECTED] stefan]$ ssh kenobi.mandrakesoft.com ssh: relocation error: /lib/libnss_ldap.so.2: undefined symbol: dbopen Anybody else? Florin [EMAIL PROTECTED] 211-1mdk - 211 -=-=-=- smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] [Bug 5658] [gcc2.96] New: Can't install BuildRequires (bison[= 1.35])
http://qa.mandrakesoft.com/show_bug.cgi?id=5658 Product: gcc2.96 Component: packaging Summary: Can't install BuildRequires (bison[= 1.35]) Product: gcc2.96 Version: 2.96-0.83mdk Platform: PC URL: http://eijk.homelinux.org/build/cooker/urpmi/i586/gcc2.9 6-2.96-0.83mdk OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Some package requested cannot be installed: gcc2.96-2.96-0.83mdk.src (due to unsatisfied bison[= 1.35]) http://eijk.homelinux.org/build/cooker/i586/gcc2.96-2.96-0.83mdk http://eijk.homelinux.org/build/cooker/urpmi/i586/gcc2.96-2.96-0.83mdk BTW: do we still *need* this package? or can be be removed? -- 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.
Re: [Cooker] um.
Han Boetes wrote: Stefan van der Eijk [EMAIL PROTECTED] wrote: Somebody whos name is lost wrote: i know, and i have the same opinion as you, but what can we do ?-( How about: help Mandrakesoft come up with a better way to generate revenue? Hear hear, Howbout an uitzendbureau? What's the english word? Temp agency? Or consultancy? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] um.
Adam Williamson wrote: On Fri, 2003-09-12 at 02:47, Svetoslav Slavtchev wrote: On Fri, 12 Sep 2003 09:20, Adam Williamson wrote: http://www.mandrakesoft.com/partners/advertising no. I'm all for it. I replace the screensaver and bookmarks straight away anyway, and it's a simple way to fund your favourite distro. It's not as if we're seeing in-yer-face popups or anything. Cheers; Leon me doesn't use screensaver :) nor default bookmarks :) about the install ( may be will skip a CD install and will use urpmi.update urpmi --autoselect ) My point wasn't really about whether it affected us directly. Obviously it won't - given that we use Cooker, I don't know if we'll even ever *see* the offending adverts. The point is I think it's a horrible way of generating revenue which is being introduced by stealth - I only found out about this because OSNews discovered the page and flagged it up in a news story, I haven't seen anything from a Mandrake source announcing this, and it hasn't been mentioned on this list at all, which seems a little odd. I'm more concerned with the horribly unprofessional impression that an installation and first boot sequence plastered with adverts will have on a new user, compared to distributions which have none. Interesting. People on this list seem only mention how *not* to generate cash. This product is being developed by a company, i.e bills, salaries and taxes need to be paid. Instead of complaining on how not to generate cash, could we perhaps focus on finding an acceptable way for the $$$ to flow into mdk. We (contributors) will also benefit from it. Perhaps we can make a topic on the wiki discussing this. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] um.
On Fri, Sep 12, 2003 at 08:17:45AM +0200, Stefan van der Eijk wrote: Interesting. People on this list seem only mention how *not* to generate cash. This product is being developed by a company, i.e bills, salaries and taxes need to be paid. You are right, my personal feeling is that an adware version of mandrake will have the effect of enraging many people from the linux community. But i might as well be wrong. I believe people at mandrake who tought this up already evaluated such issues. I've put up a page on the wiki where idea's can be posted discussed: http://qa.mandrakesoft.com/twiki/bin/view/Main/HowtoGenerateRevenue i am not switching to debian anyway :))) You're free to, if you want. regards, Stefan
Re: [Cooker] um.
On Fri, 2003-09-12 at 09:53, Stefan van der Eijk wrote: On Fri, Sep 12, 2003 at 08:17:45AM +0200, Stefan van der Eijk wrote: Interesting. People on this list seem only mention how *not* to generate cash. This product is being developed by a company, i.e bills, salaries and taxes need to be paid. You are right, my personal feeling is that an adware version of mandrake will have the effect of enraging many people from the linux community. But i might as well be wrong. I believe people at mandrake who tought this up already evaluated such issues. I've put up a page on the wiki where idea's can be posted discussed: http://qa.mandrakesoft.com/twiki/bin/view/Main/HowtoGenerateRevenue Thanks Stefan! I'll go submit busking on the street of Paris to that too ;) :-) Beats working in the AnneFrank plantsoen in Eindhoven, the Netherlands. But I bet the revenue will be higher in Eindhoven, that is, *if* you're into that trade *G*. Stefan
Re: [Cooker] um.
i know, and i have the same opinion as you, but what can we do ?-( How about: help Mandrakesoft come up with a better way to generate revenue? Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] um.
http://www.mandrakelinux.com/en/mdkads.php3 I think your concerns are unfounded, and I also think you're being a little silly. Do you close your eyes when you're driving around and see billboards that advertise stuff? Do you close your eyes and mute the TV when the commercials are on? Do you leave the theatre because you paid to see a movie and not a car commercial before the feature starts? I think you're a little out of line here, personally. It's not that intrusive, there will be no plastering of ads, and once you modify the bookmarks, they're gone. How many times do you plan to install and actually watch the entire install (does anyone do that anymore?) Besides, it's ok to advertise links to OSS and GNU stuff but it's not ok to advertise Linux-related commercial stuff to make a couple bucks so we can have another version of Mandrake in the future? I hate to say it, but it cracks me up how people are so against advertising, our business model, and things we do to make revenue so that the developers and others in the company can eat and afford to spend all of their time working on the distro. Sounds like the community would rather have a nice distribution but all the developers should be homeless and starving. (And no, I won't bother contributing to this thread anymore) Well said! Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] lilo borks when removing kernel
:45 diag1.img -rw-r--r--1 root root16796 Sep 3 17:45 diag2.img drwxr-xr-x2 root root 1024 Feb 15 2003 grub/ -rw-r--r--1 root root 199166 Sep 7 22:50 initrd-2.4.22-2mdkenterprise.img -rw-r--r--1 root root 203237 Sep 6 21:43 initrd-2.4.22-3.tmb.2mdkenterprise.img -rw-r--r--1 root root 202619 Sep 9 18:40 initrd-2.4.22-6mdkenterprise.img -rw-r--r--1 root root 203653 Sep 9 18:45 initrd-2.4.22-7mdkenterprise.img lrwxrwxrwx1 root root 32 Sep 11 08:58 initrd-enterprise.img - initrd-2.4.22-2mdkenterprise.img lrwxrwxrwx1 root root 36 Sep 9 20:30 kernel.h - /boot/kernel.h-2.4.22-6mdkenterprise -rw-r--r--1 root root6 Aug 29 14:21 kernel.h-2.4.22 -rw-r--r--1 root root 537 Sep 9 20:30 kernel.h-2.4.22-6mdkenterprise drwx--2 root root12288 Feb 15 2003 lost+found/ -rw---1 root root 281600 Sep 11 08:58 map lrwxrwxrwx1 root root 15 Feb 15 2003 message - message-graphic -rw-r--r--1 root root 164762 Sep 9 18:40 message-graphic -rw-r--r--1 root root 256 Feb 15 2003 us.klt -rw-r--r--1 root root 1383847 Sep 7 23:02 vmlinuz-2.4.22-6mdkenterprise -rw-r--r--1 root root 1383773 Sep 11 08:44 vmlinuz-2.4.22-7.tmb.1mdkenterprise -rw-r--r--1 root root 1383846 Sep 9 07:38 vmlinuz-2.4.22-7mdkenterprise lrwxrwxrwx1 root root 29 Sep 11 08:58 vmlinuz-enterprise - vmlinuz-2.4.22-2mdkenterprise Notice that: 1/ the symlinks of initrd-enterprise.img and vmlinuz-enterprise are both pointing to the kernel I just removed; 2/ only the vmlinuz-2.4.22-2mdkenterprise file has been removed, initrd-2.4.22-2mdkenterprise.img is still there. This will leave me with a system that won't boot the default entry in lilo. Time to report this in bugzilla or will a quick fix do? regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Rusty's brain broke
Thomas,
Is anybody getting this message after upgrading to the latest kernel?
kernel: MASQUERADE: No route: Rusty's brain broke!
I am using nat/masquerading to share the internet. To enable internet
sharing I must revert back to 2.4.21.
Hope to see this get fixed soon.
Until the right fix this does the trick.
I suppose Juan has on his queue, or is wating for the final fix.
= net/ipv4/netfilter/ipt_MASQUERADE.c 1.6 vs edited =
--- kernel/net/ipv4/netfilter/ipt_MASQUERADE.c Tue Aug 12 11:30:12 2003
+++ kernel/net/ipv4/netfilter/ipt_MASQUERADE.c Thu Aug 28 16:54:15 2003
@@ -90,6 +90,7 @@
#ifdef CONFIG_IP_ROUTE_FWMARK
key.fwmark = (*pskb)-nfmark;
#endif
+ key.oif = 0;
if (ip_route_output_key(rt, key) != 0) {
/* Funky routing can do this. */
if (net_ratelimit())
I added this to my current kernel that's building right now...
(2.4.22-7.tmb.1mdk)
if it finishes cleanly on my local buildhost, I'll push it to klama,
and it should hit the contribs at mid-day UTC...
You're my hero!!
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
[Cooker] [Bug 5351] [autofs] New: [amd64] ldap support in autofs broken
http://qa.mandrakesoft.com/show_bug.cgi?id=5351
Product: autofs
Component: autofs
Summary: [amd64] ldap support in autofs broken
Product: autofs
Version: 4.0.0-0.19mdk
Platform: PC
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: autofs
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
the autofs initscript contains:
function getldapmounts()
{
/usr/lib/autofs/autofs-ldap-auto-master 2 /dev/null
}
This file cannot be found because the file is packaged in /usr/lib64 (and not:
/usr/lib).
Difference in filelist for the autofs package between amd64 and i586 platforms:
amd64 files:
/usr/lib64/autofs
/usr/lib64/autofs/autofs-ldap-auto-master
/usr/lib64/autofs/lookup_file.so
/usr/lib64/autofs/lookup_ldap.so
/usr/lib64/autofs/lookup_multi.so
/usr/lib64/autofs/lookup_nisplus.so
/usr/lib64/autofs/lookup_program.so
/usr/lib64/autofs/lookup_userhome.so
/usr/lib64/autofs/lookup_yp.so
/usr/lib64/autofs/mount_afs.so
/usr/lib64/autofs/mount_autofs.so
/usr/lib64/autofs/mount_bind.so
/usr/lib64/autofs/mount_changer.so
/usr/lib64/autofs/mount_ext2.so
/usr/lib64/autofs/mount_generic.so
/usr/lib64/autofs/mount_nfs.so
/usr/lib64/autofs/parse_sun.so
i586 files:
/usr/lib/autofs
/usr/lib/autofs/autofs-ldap-auto-master
/usr/lib/autofs/lookup_file.so
/usr/lib/autofs/lookup_ldap.so
/usr/lib/autofs/lookup_multi.so
/usr/lib/autofs/lookup_nisplus.so
/usr/lib/autofs/lookup_program.so
/usr/lib/autofs/lookup_userhome.so
/usr/lib/autofs/lookup_yp.so
/usr/lib/autofs/mount_afs.so
/usr/lib/autofs/mount_autofs.so
/usr/lib/autofs/mount_bind.so
/usr/lib/autofs/mount_changer.so
/usr/lib/autofs/mount_ext2.so
/usr/lib/autofs/mount_generic.so
/usr/lib/autofs/mount_nfs.so
/usr/lib/autofs/parse_sun.so
--
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] Rusty's brain broke!
with kernel-enterprise-2.4.22-4mdk I'm getting the following errors with iptables / NAT: Sep 6 00:30:50 taz kernel: MASQUERADE: No route: Rusty's brain broke! Sep 6 00:31:21 taz kernel: MASQUERADE: No route: Rusty's brain broke! Sep 6 00:31:52 taz kernel: MASQUERADE: No route: Rusty's brain broke! Sep 6 00:32:23 taz kernel: MASQUERADE: No route: Rusty's brain broke! Sep 6 00:32:54 taz kernel: MASQUERADE: No route: Rusty's brain broke! Sep 6 00:33:25 taz kernel: MASQUERADE: No route: Rusty's brain broke! anybody else? regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] pkgconfig not required by -devel
Guillaume Rousse wrote: Ainsi parlait Michael Scherer : i suggest the last solution, but, maybe someone see a problem ? Yes, coherency with other development tools. How many packages really requires autoconf/automake ? I guess less than 1%. However, autoconf/automake are rpm-build dependencies. Here we have more packages requiring what appears some new build tool, and we are gonna add it as an explicit require for each of them. This is plainly silly. If you're going to do it manually, like we are doing right now, *then* it's silly. If you're going to do it automatically, I have less issues with it. I think it's ellegant not to let rpm-build require all the build tools, otherwise rpm-build will become something like basesystem. Perhaps introducing circular dependencies, etc. Doing it with a find-requires script is fine. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Initscripts: many services missing
Quel Qun wrote: As of tonight, many services are not started in runlevel 3 although they are listed as on by chkconfig. I had to start syslog, xinetd, network and xfs manually, and surely some others are missing. But, it does boot a lot faster, right? See, it's a new feature! :-) Since syslog is one of the missing in action, it is quite difficult to guess what is going on. initscripts-7.06-21mdk I confirm this. Also, some new directories have been created: /etc/rc0.d through /etc/rc6.d: $ ls /etc/rc?.d/ /etc/rc0.d/: S00killall@ S01halt@ /etc/rc1.d/: S00single@ /etc/rc2.d/: S99local@ /etc/rc3.d/: S99local@ /etc/rc4.d/: S99local@ /etc/rc5.d/: S99local@ /etc/rc6.d/: S00killall@ S01reboot@ regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: problems with UDMA66/100 on nForce2 boards (Abit NF7)
I'm running an Asus A7N8X Deluxe (333) with an IBM disk. My machine sometimes locks up, mostly after running for a few days. The lockup leaves the the caps and scroll lock lights on on the keyboard. Also, the disk regularly gets reset, resulting in very conservative IDE settings (dma turned off, etc). I've discussed this with Thomas back in July, his -tmb kernels were more stable than the mandrake kernels at that time. I'll try the mem=nopentium option. regards, Stefan I have confimed that with mem=nopentium I can use UDMA66/100 reliably on the Abit NF7-v1.2 board with either my Maxtor or Western Digital drives. Unfirtunately I can also confim that even with mem=nopentium the system locks hard when using UDMA66/100 on the Abit NF7-v2.0 board with either my Maxtor or Western Digital drives. This leads me to believe that it is an nForce2 Ultra 400 chipset, and or an Abit motherboard BIOS issue. That said it could also/just be a kernel incompatibility with the Ultra 400 chipset, I just don't know. Is anybody else running with an nForce2 Ultra 400, using UDMA66/100? Have you encountered these hangs? TIA -- John Allen, Email: mailto:[EMAIL PROTECTED] MandrakeClub Silver Member.
Re: [Cooker] pkgconfig not required by -devel
[..] using the patch and automaticaly adding it to the package that need it this would only add pkgconfig for library that really use it when aclocal is used, and is automated, so no need to change library, just rebuild them. all file dropped in /usr/share/aclocal are included in ./configure script whan aclocal is used, so, if the file check pkgconfig existence, with a macro, it mean that all configure script trying to detect this library will use pkgconfig, and so it is good to add it as requires. i suggest the last solution, but, maybe someone see a problem ? if not, i will submit a bugreport during the weekend. You have my support. Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] [Bug 5210] [gcc] New: [alpha] unrecognizable insn compiling fork.c of kernel (and glibc)
http://qa.mandrakesoft.com/show_bug.cgi?id=5210 Product: gcc Component: gcc Summary: [alpha] unrecognizable insn compiling fork.c of kernel (and glibc) Product: gcc Version: 3.3.1-2mdk Platform: DEC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: gcc AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm seeing this behaviour on the alpha with recent version of gcc. This bug is preventing glibc and kernel packages from building. This bug has also been logged in gnu's gcc bugzilla, bug #11717: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11717 Examples of failing builds: http://eijk.homelinux.org/build/cooker/alpha/problem/kernel-2.4.22.3mdk-1-1mdk gcc -D__KERNEL__ -I/home/slbd/RPM/BUILD/kernel-2.4/linux-2.4.22/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -nostdinc -iwithprefix include -DKBUILD_BASENAME=fork -c fork.c -o fork.o fork.c: In function `dup_mmap': fork.c:151: error: unrecognizable insn: (insn 31 27 36 0 0x2daf2e8 (set (reg/v/f:DI 75) (symbol_ref:DI (@Lmmlist_lock))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI (@Lmmlist_lock)) (nil))) fork.c:151: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. http://eijk.homelinux.org/~stefan/glibc-2.3.2-14mdk mkdir /usr/src/RPM/BUILD/glibc-2.3.2/build-alpha-linux/libio fileops.c: In function `mmap_remap_check': fileops.c:612: error: unrecognizable insn: (insn 305 383 306 17 0x2abf0d8 (set (reg/f:DI 212) (symbol_ref:DI (@L_IO_file_jumps))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI (@L_IO_file_jumps)) (nil))) fileops.c:612: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. A quick search on google (recog.c 2175) shows that other platforms also have this issue. preprocessed source is available. -- 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.
Re: [Cooker] pkgconfig not required by -devel
Michael,
Would you consider making this into a find-requires script? In that case
the dependencies won't need to be added manually.
regards,
Stefan
Hi.
will trying to fix buildrequires, i have come on this one
http://eijk.homelinux.org/build/contrib/i586/problem/ices-0.3-2mdk
the compilation stopped when configure tried to detect libshout3-devel,
listed as buildrequires. It stopped because pkgconfig was not found.
libshout3-devel should require pkgconfig, since it is needed for the
proper auto detection of the include.
there is a lot of package who drop a file in /usr/lib/pkgconfig/ without
having a requires on pkgconfig.
this script [1] gives most of the package who misses the requires on
pkgconfig [2].
Am i wrong when i say they should be fixed ?
Because there is a lot of wrong requires, i may have missed a detail
Some of the packages are not -devel library, i guess they should be
fixed, because pkgconfig files belong to the -devel.
And some are not library, such as linphone, who does not provides any
include or libray, so i guess there is a problem.
[1]
for i in `urpmf '/usr/lib/pkgconfig/' | awk -F: '{print $1}' | sort |
uniq `;
do
if ! urpmq -d $i | grep -q pkgconfig ; then
echo $i ;
fi;
done;
[2]
autotrace
epiphany-devel
gdesklets
gedit
gkrellm-devel
gnome-mime-data
gnome-python
gnome-system-tools
gok
gretl
gstreamer-python
gtk-doc
gtk-engines2
gtkmathview
ImageMagick
libaiksaurus-1.0_0-devel
libalsa2-devel
libalsaplayer0-devel
libaudiofile0-devel
libavifile0.7-devel
libdia-newcanvas0
libdirectfb0.9_18-devel
libebg1
libecore0
libedb1
libeet0
libefs1-devel
libesound0-devel
libevas1
libexif9-devel
libflatzebra0.1
libfontconfig1-devel
libgmime2.0-devel
libgnokii0
libgphoto2-devel
libgsl0-devel
libgtkglarea2.0
libgtksharpglue-devel
libladcca1-devel
liblrdf0-devel
libmnote7-devel
libmpeg2dec0-devel
libmusicbrainz2-devel
libneon0.24-devel
libnspr4-devel
libnss3-devel
libogre0-devel
libopenbabel0-devel
libopenssl0.9.7-devel
libots-1_0-devel
libparagui1.0-devel
libpng3-devel
libscaffold-1_0-devel
libshout3-devel
libsmi2-devel
libsqlite0-devel
libstartup-notification-1_0-devel
libticables3-devel
libticalcs4-devel
libtifiles0-devel
libtre3-devel
libuser1-devel
libxfree86-devel
libxine1-devel
libxml++10-devel
libxml1-devel
libxml2-devel
libxslt1-devel
linphone
mozilla-devel
mozilla-firebird-devel
pstoedit
pyorbit-devel
rhythmbox
spirit
streamtuner-devel
zziplib0-devel
smime.p7s
Description: S/MIME Cryptographic Signature
[Cooker] [Bug 4888] [gcc] Internal compiler error (busybox)
http://qa.mandrakesoft.com/show_bug.cgi?id=4888 --- Additional Comments From [EMAIL PROTECTED] 2003-01-09 10:49 --- I'm seeing similar behaviour on the alpha with recent version of gcc. This bug is preventing glibc and kernel packages from building. This bug has also been logged in gnu's gcc bugzilla, bug #11717: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11717 Examples of failing builds: http://eijk.homelinux.org/~stefan/glibc-2.3.2-13mdk mkdir /usr/src/RPM/BUILD/glibc-2.3.2/build-alpha-linux/libio fileops.c: In function `mmap_remap_check': fileops.c:612: error: unrecognizable insn: (insn 305 383 306 17 0x2abf0d8 (set (reg/f:DI 212) (symbol_ref:DI (@L_IO_file_jumps))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI (@L_IO_file_jumps)) (nil))) fileops.c:612: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. http://eijk.homelinux.org/build/cooker/alpha/problem/kernel-2.4.22.3mdk-1-1mdk gcc -D__KERNEL__ -I/home/slbd/RPM/BUILD/kernel-2.4/linux-2.4.22/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -nostdinc -iwithprefix include -DKBUILD_BASENAME=fork -c fork.c -o fork.o fork.c: In function `dup_mmap': fork.c:151: error: unrecognizable insn: (insn 31 27 36 0 0x2daf2e8 (set (reg/v/f:DI 75) (symbol_ref:DI (@Lmmlist_lock))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI (@Lmmlist_lock)) (nil))) fork.c:151: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. A quick search on google (recog.c 2175) shows that other platforms also have 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: UNCONFIRMED creation_date: description: Using 3.1.1-1mdk (also tried 3.1.1-0.7mdk as installed by 9.2Beta2) I get an internal compiler error when compiling busybox-1.00-pre2 from sources, as downloaded from http://busybox.net. (Distribution: 9.2 beta 2, updated gcc to cooker version to get past error) Steps followed: 1. Unpack the busybox archive; 2. make menuconfig (just select exit to config with defaults) 3. make dep 4. make, which results in the following break: gcc -I./include -Wall -Wstrict-prototypes -Wshadow -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=0 -falign-jumps=0 -falign-loops=0 -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG -c -o libbb/dump.o libbb/dump.c libbb/dump.c: In function `rewrite': libbb/dump.c:307: error: unrecognizable insn: (insn:HI 1110 915 34 0x403030dc (set (reg:CC 17 flags) (compare:CC (const:SI (plus:SI (symbol_ref:SI (lcc)) (const_int 1 [0x1]))) (reg/f:SI 116))) -1 (nil) (expr_list:REG_DEAD (reg/f:SI 116) (nil))) libbb/dump.c:307: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:https://qa.mandrakesoft.com/ for instructions. make: *** [libbb/dump.o] Error 1
Re: [Cooker] pkgconfig not required by -devel
Oden Eriksson wrote: måndagen den 1 september 2003 21.16 skrev Guillaume Rousse: Ainsi parlait Oden Eriksson : I agree, rpm-devel should require pkgconfig. Same for me. That's silly to add it to all packages individually. So..., what do you all suggest? File a bugreport or bug the rpm package maintainer? I personally think this solution would benefit the most... I guess there are 3 options: - add it as a Requires to rpm-build (not rpm-devel!) - add some functionality to the find-requires script - hunt down the packages and add it to the spec file Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] for those interested in the ports...
FYI: This evening slbd has started building on sparc (next to amd64, alpha and i586). See: http://eijk.homelinux.org/build/cooker/sparc/?C=M;O=D regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] packages without a src.rpm
FYI: The following i586 cooker packages have no src.rpm: bootsplash-themes-1.4.1-1mdk.i586.rpm howto-html-hu-9.1-0.5mdk.noarch.rpm howto-html-id-9.1-0.5mdk.noarch.rpm kdebase-kdm-3.1.3-3mdk.i586.rpm kdebase-kdm-config-file-3.1.3-3mdk.i586.rpm koffice-devel-1.3-0.beta2.6mdk.i586.rpm libalsa2-static-devel-0.9.0-0.14rc7mdk.i586.rpm libdb4.0-4.0.14-6mdk.i586.rpm libdb4.0-devel-4.0.14-6mdk.i586.rpm libdb4.0-static-devel-4.0.14-6mdk.i586.rpm libdbcxx4.0-4.0.14-6mdk.i586.rpm libdbjava4.0-4.0.14-6mdk.i586.rpm libdbtcl4.0-4.0.14-6mdk.i586.rpm libexif8-0.5.9-3mdk.i586.rpm libexif8-devel-0.5.9-3mdk.i586.rpm libgcj3-static-devel-3.2.3-1mdk.i586.rpm libopenhbci10-0.9.11-1mdk.i586.rpm libopenhbci10-devel-0.9.11-1mdk.i586.rpm libopenhbci6-0.9.9-2mdk.i586.rpm libopenhbci6-devel-0.9.9-2mdk.i586.rpm libsasl7-1.5.28-7mdk.i586.rpm libsasl7-plug-anonymous-1.5.28-7mdk.i586.rpm libsasl7-plug-crammd5-1.5.28-7mdk.i586.rpm libsasl7-plug-digestmd5-1.5.28-7mdk.i586.rpm libsasl7-plug-gssapi-1.5.28-7mdk.i586.rpm libsasl7-plug-login-1.5.28-7mdk.i586.rpm libsasl7-plug-plain-1.5.28-7mdk.i586.rpm libtpctl2-4.3-3mdk.i586.rpm libtpctl2-devel-4.3-3mdk.i586.rpm perl-GTK2-devel-0.0.cvs.2003.04.07.1-2mdk.i586.rpm rxvt-devel-2.7.8-8mdk.i586.rpm smartmontools-5.1-10.1mdk.i586.rpm The following packages in i586 contrib have no src.rpm: ScalablePBS-2.3.12-2mdk.i586.rpm ScalablePBS-client-2.3.12-2mdk.i586.rpm ScalablePBS-xpbs-2.3.12-2mdk.i586.rpm amavis-ng-0.1.6.4-2mdk.noarch.rpm bbdb-2.34-2mdk.noarch.rpm ccscript2-2.4.4-1mdk.i586.rpm crimson-field-0.3.0-2mdk.i586.rpm cyrus-imapd-debug-2.1.13-1mdk.i586.rpm digikam-0.5.1-5mdk.i586.rpm emacs-xslide-0.2.b3-2mdk.noarch.rpm firestarter-0.9.1-2mdk.i586.rpm gfontview-0.5.0-9mdk.i586.rpm hddtemp-0.3-0.beta4.2mdk.i586.rpm kgamma-1.0.1-2mdk.i586.rpm libScalablePBS2-devel-2.3.12-2mdk.i586.rpm libbeast0-0.5.0-1mdk.i586.rpm libbeast0-devel-0.5.0-1mdk.i586.rpm libfwbuilder4-0.10.13-1mdk.i586.rpm libfwbuilder4-devel-0.10.13-1mdk.i586.rpm libgimp14-1.3.14-2mdk.i586.rpm libgimp14-devel-1.3.14-2mdk.i586.rpm libgimp16-1.3.16-3mdk.i586.rpm libgimp16-devel-1.3.16-3mdk.i586.rpm libgltt2-2.5.2-3mdk.i586.rpm libgltt2-devel-2.5.2-3mdk.i586.rpm libnessus2-2.0.7-1mdk.i586.rpm libnessus2-devel-2.0.7-1mdk.i586.rpm libqscintilla1-1.0-1mdk.i586.rpm libqscintilla1-devel-1.0-1mdk.i586.rpm libsip9-3.5-1mdk.i586.rpm libsip9-devel-3.5-1mdk.i586.rpm libsmi-0.4.0-2mdk.i586.rpm libsmi-devel-0.4.0-2mdk.i586.rpm libwpd-1_0-devel-0.5.0-1mdk.i586.rpm libwpd-tools-0.5.0-1mdk.i586.rpm libwxBase0-2.2.7-3mdk.i586.rpm libwxBase0-devel-2.2.7-3mdk.i586.rpm libxml++9-0.23.0-1mdk.i586.rpm libxml++9-devel-0.23.0-1mdk.i586.rpm mtr-0.51-2mdk.i586.rpm mtr-gtk-0.51-2mdk.i586.rpm nessus-libs-1.2.7-1mdk.i586.rpm nvtv-0.4.4-1mdk.i586.rpm openvpn-debug-1.4.1-1mdk.i586.rpm pam_mount-0.5.14-2mdk.i586.rpm perl-BerkeleyDB-debug-0.20-2mdk.i586.rpm perl-Crypt-CBC-2.08-3mdk.noarch.rpm perl-Crypt-OpenSSL-DSA-debug-0.11-2mdk.i586.rpm perl-Math-BaseCalc-1.011-2mdk.noarch.rpm perl-Net-Jabber-1.28-3mdk.noarch.rpm perl-Test-Simple-0.47-2mdk.noarch.rpm perl-Tie-IxHash-1.21-3mdk.noarch.rpm perl-XML-Stream-1.15-3mdk.noarch.rpm perl-XML-XUpdate-LibXML-0.4.0-1mdk.noarch.rpm pyddr-0.7.1-1mdk.noarch.rpm pyddr-music-1.0-1mdk.noarch.rpm python-bsddb3-4.1.3-2mdk.i586.rpm python-fpconst-0.6.0-2mdk.noarch.rpm regutils-0.10-2mdk.i586.rpm speaker3-0.5-2mdk.i586.rpm squaroid-0.60.3-4mdk.i586.rpm sylpheed-0.9.3-3mdk.i586.rpm vrflash-0.20-2mdk.i586.rpm wmnd-0.4.3-2mdk.i586.rpm xcoral-3.40-2mdk.i586.rpm xmms-Zon-0.04.1_beta2-5mdk.i586.rpm xmms-gdancer-0.4.5-2mdk.i586.rpm xsitecopy-0.11.4-2mdk.i586.rpm xxdiff-2.9-2mdk.i586.rpm smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] Re: [CHRPM] Xaw3d-1.5-13mdk
--=-=-= * Wed Jul 30 2003 Gwenole Beauchesne [EMAIL PROTECTED] 1.5-13mdk - BuildRequires: xpm-devel --=-=-= Isn't this BuildRequires redundant, as it is already Required by XFree86-devel? I was hoping the strategy would be to remove redundant BuildRequires (unless a specific version of a package is Required), rather than adding more redundant ones. See: http://qa.mandrakesoft.com/twiki/bin/view/Main/MandrakeLinux?topic=BuildRequires Here are the build logs of the previous package (until -13mdk is built): http://eijk.homelinux.org/build/cooker/i586/OK/Xaw3d-1.5-12mdk And the urpmi install log: http://eijk.homelinux.org/build/cooker/urpmi/i586/Xaw3d-1.5-12mdk regards, Stefan @@@ Installing: XFree86-devel installing /mirrors/cooker/i586/Mandrake/RPMS/freetype-1.3.1-20mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/fontconfig-2.2.1-1mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/libxpm4-devel-3.4k-26mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/libxpm4-3.4k-26mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/libexpat0-devel-1.95.6-4mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/XFree86-devel-4.3-13mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/freetype2-2.1.4-4mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/zlib1-devel-1.1.4-8mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/libfontconfig1-2.2.1-1mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/libexpat0-1.95.6-4mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/freetype2-devel-2.1.4-4mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/XFree86-libs-4.3-13mdk.i586.rpm /mirrors/cooker/i586/Mandrake/RPMS/libfontconfig1-devel-2.2.1-1mdk.i586.rpm Preparing... ## 1:libexpat0 ## 2:freetype2 ## 3:zlib1-devel ## 4:freetype2-devel ## 5:libexpat0-devel ## 6:libxpm4 ## 7:freetype ## 8:libfontconfig1 ## 9:fontconfig ## 10:XFree86-libs ## 11:libxpm4-devel ## 12:libfontconfig1-devel ## 13:XFree86-devel ## @@@ Installing: bison installing /mirrors/cooker/i586/Mandrake/RPMS/bison-1.875-3mdk.i586.rpm Preparing... ## 1:bison ## @@@ Installing: flex installing /mirrors/cooker/i586/Mandrake/RPMS/flex-2.5.4a-21mdk.i586.rpm Preparing... ## 1:flex ## @@@ Redundant BuildRequires: libxpm4-devel @@@ XFree86-devel Removing XFree86-devel XFree86-libs bison flex fontconfig freetype freetype2 freetype2-devel libexpat0 libexpat0-devel libfontconfig1 libfontconfig1-devel libxpm4 libxpm4-devel zlib1-devel
Re: [Cooker] urpmi wierdness
There is a strange things with your rpm database, at the very
beginning, libexpat0 is installed and in another transaction later,
fontconfig and libfontconfig1 installation fails due to
libexpat.so.0 not available which are provided by the previous
installation of libexpat0 normally...
I can't deny to say that what you're seeing is strange, I also think
it's strange. What we're talking about is a chrooted install, but the
db seems fine to me:
# chroot /chroot/cooker/
[EMAIL PROTECTED] /]# rpm -Va
S.5T c /etc/bashrc
S.5T c /etc/services
..5T c /etc/shells
L... /lib/cpp
S.5T c /etc/info-dir
...T c /etc/syslog.conf
S.5T c /etc/rc.d/init.d/functions
Any other way to check the health of the installation?
Well after the problem occurred, check rpm -q --whatprovides
libexpat.so.0 just to see ?
I can't really do that... slbd is running, installing packages into the
chroot, rebuilding the src.rpm and then de-installin the installed
packages.
To try it manually: create a chroot environment, with only basesystem +
rpm-build
and then urpmi the packages into the chroot with this command (${a} is the
package name):
sudo urpmi -q -p ${a} \
--auto \
--media ${MEDIA} \
--no-verify-rpm \
--root ${CHROOT_PATH}
I just added this to it (and a \ behind the --root command) and it went
fine:
--split-length 0
In fact, did you used --test because this option cannot run with splited
transactions ? But it seems no according to your logs, unless you have
used them before and silently ?
Nope.
Anyway, I changed slbd to use --split-length 0 and here's the result:
http://eijk.homelinux.org/build/cooker/urpmi/i586/k3b-0.9-2mdk
All packages install as expected -- the old behavior is back my
problem seems fixed.
Question remains: why aren't the packages installed properly without
setting this option?
I have no idea, this is the first time I see such behaviour, the rpmdb
is closed and reopened each time for a new transaction (as if there were
multiple rpm invocation).
Yes.
I'll try to reproduce here as I only use splited transaction when
auto-selected (but it is not a full install of new packages, but a
progressive cooker upgrade).
Perhaps try using a bare chroot environment and then installing
kdelibs-devel into it, as it is quite a large install.
regards,
Stefan
PS: is --root functionality planned for urpme ?
[Cooker] [Bug 4230] [initscripts] killproc kills outside it own chroot
http://qa.mandrakesoft.com/show_bug.cgi?id=4230 --- Additional Comments From [EMAIL PROTECTED] 2003-02-08 01:25 --- The patch works for me. The issue hasn't been fixed in initscripts-7.06-16mdk (released 2003/08/01). -- 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: native system: / chroot system: /chroot xfs is used as an example, same applies to other daemons (cron, etc) Deinstall XFree86-xfs from chroot system. xfs is not running in chroot (no pid file), killproc doesn't find a pid file, looks up the xfs processes in the process table and kills them. Result: xfs running in native system ( / ) is killed. possible fix: check if the process you are trying to kill has the same root. - lsof will give this information in rtd. - compare if /proc/$$/root = /proc/$kill_pid/root
[Cooker] [Bug 4207] [rpm] BuildRequires parsing (rpm -qpR) incorrect
http://qa.mandrakesoft.com/show_bug.cgi?id=4207
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-02-08 01:26 ---
behaviour doesn't occur anymore. fixed?
--
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:
I think there is a bug in the mechanism to get the BuildRequires out of a
package with rpm -qpR.
Where is gd-devel?:
$ rpm -qpR /mirrors/cooker/SRPMS/glibc-2.3.2-5mdk.src.rpm | sort
binutils = 2.13.90.0.18-2mdk
gcc = 2.96-0.50mdk
gettext
patch
perl
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(VersionedDependencies) = 3.0.3-1
tetex
tetex-latex
texinfo
But there in glibc.spec:
# Define to bootstrap new glibc
%define build_bootstrap0
%define build_profile1
%define build_nscd1
%define build_doc1
%define build_utils1
%define build_i18ndata1
%define build_timezone1
# Disable a few defaults when cross-compiling a glibc
%if %{name} != glibc
%define build_doc0
%define build_pdf_doc0
%define build_biarch0
%define build_check0
%define build_debug0
%define build_nscd0
%define build_profile0
%define build_utils0
%define build_i18ndata0
%define build_timezone0
%endif
# Allow --with[out] feature at rpm command line build
%{expand: %{?_without_PDF:%%global build_pdf_doc 0}}
%{expand: %{?_without_CHECK:%%global build_check 0}}
%{expand: %{?_without_UTILS:%%global build_utils 0}}
%{expand: %{?_without_BOOTSTRAP:%%global build_bootstrap 0}}
%{expand: %{?_with_PDF:%%global build_pdf_doc 1}}
%{expand: %{?_with_CHECK:%%global build_check 1}}
%{expand: %{?_with_UTILS:%%global build_utils 1}}
%{expand: %{?_with_BOOTSTRAP:%%global build_bootstrap 1}}
I guess rpm -qpR takes the define from the cross-compiling section...
Re: [Cooker] kernel-2.4.2.6.4tmb
Steffen Barszus wrote: Am Donnerstag, 31. Juli 2003 18:36 schrieb Svetoslav Slavtchev: Keep'em coming... that's pretty much all of them except: alsa-rtc support DC09_alsa_rtc_support.patch mod_dvb-1.0.0-pre3 (~3Mb) http://varna.demon.co.uk/~svetlio/ruby-contrib/MC25_mod_dvb_1.0.0-pre3.tar This one should wait one or two days. DVB driver will become 1.0.0 this week according to Johannes Stelzenbach on dvb mailinglist. Can the Marvel (for MGA TV products) be merged too? See: http://sourceforge.net/projects/marvel I've been able to build them and run them on my box. The only issue I see is configuring the /etc/modules.conf file to get the modules loaded properly. But this can also be done with the drakxtv tool. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] kernel-2.4.2.6.4tmb
Svetoslav Slavtchev wrote: Quoting Stefan van der Eijk [EMAIL PROTECTED]: Steffen Barszus wrote: Am Donnerstag, 31. Juli 2003 18:36 schrieb Svetoslav Slavtchev: Keep'em coming... that's pretty much all of them except: alsa-rtc support DC09_alsa_rtc_support.patch mod_dvb-1.0.0-pre3 (~3Mb) http://varna.demon.co.uk/~svetlio/ruby-contrib/MC25_mod_dvb_1.0.0-pre3.tar This one should wait one or two days. DVB driver will become 1.0.0 this week according to Johannes Stelzenbach on dvb mailinglist. Can the Marvel (for MGA TV products) be merged too? See: http://sourceforge.net/projects/marvel I've been able to build them and run them on my box. The only issue I see is configuring the /etc/modules.conf file to get the modules loaded properly. But this can also be done with the drakxtv tool. regards, Stefan the Makefile looks pretty confusing, and the dvd parts needs the windows drivers. do you need only make mjpeg or also the dvd addon? Sorry, I should have mentioned it. Only the make mjpeg. The make dvd stuff is for obseleted addon hardware. I don't expect many people have that kit. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] kernel 2.6
Olivier Thauvin wrote: Le Mercredi 30 Juillet 2003 16:07, Gwenole Beauchesne a écrit : On Sat, 26 Jul 2003, Stefan van der Eijk wrote: I saw in 2.4 spec sparc is still blacklist. Are you aware we are trying to restart cooker on this arch ? We don't want you make all the works, but please help us ! same applies to alpha, ppc and x86_64 [EMAIL PROTECTED] a]$ cat /proc/cmdline auto BOOT_IMAGE=2421-6 ro root=305 quiet devfs=mount [EMAIL PROTECTED] a]$ uname -m How about... a uname -a? x86_64 [EMAIL PROTECTED] temp]$ cat /etc/mandrake-release Mandrake Linux release 9.2 (Cooker) for amd64 What's the problem? Or, are you still telling things without checking? Gwenole, I don't understand you sometimes... I'm starting to get used to it... :-/ You know that the kernel don't build on most arch except x86*. Neither does glibc. I've seen the recent version fail on alpha and x86_64 (turaco at CSC). I'll try on my sparc soon too, but I expect similar results. Second point, you are running cooker? Of course he is... I am surprised ! Where can we get these cooker? On his machine... where is is being tested (any test reports yet?). How to access on it? I asked to warly, he don't have it, and don't know if it exist. You didn't notice this on the wiki. Are you aware Jaroslaw Zachwieja give us 3 sparc, 1 alpha and 1 bi opteron to make build, test, and package. Yep... We've got slbd running on turaco (the bi-opteron) churning out packages... They have also been put online at CSC, as there were people interested in it. BTW: I've had three requests this week from people wanting to install cooker alpha on their boxes. I just make kernel-2.6 for ppc... I will make it sparc, alpha ASAP, but I will blacklist x86_64 ! No way to check, I won't loose my time. Olivier, you have access to turaco, don't you? If you need anything else installed to build the kernel, shout. Please look: http://qa.mandrakesoft.com/twiki/bin/view/Main/MdkPorts If you're working on main, we are interest to build contrib ! brp... why not work _together_ on _both_? Is that so difficult to do? What we really need is the cooker versions for the archs to continue building, no matter if arch specific development is going on. What happened to ppc is unacceptable, IMHO. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] perl-5.8.0-28mdk gaim
Pixel wrote: Stefan van der Eijk [EMAIL PROTECTED] writes: perl gaim are still fighting when perl is upgraded. Situation is simliar with some kde packages and arts. # rpm -Fvh perl-*5.8* error: Failed dependencies: perl-base = 5.8.0 is needed by (installed) gaim-0.64-1mdk it looks like a rpm bug, uh? indeed. is rpm -V gaim ok before installation of perl ? after installation of perl? Both are OK. I suspect some form of an epoc issue that causes this. We've seen similar things with arts in combination with kdebase / kdelibs. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] urpmi wierdness
Hello, I'm having some issues with urpmi lately. Take a look here: http://eijk.homelinux.org/build/cooker/urpmi/i586/k3b-0.9-2mdk As you can see 2 packages are basically being installaed by urpmi: kdelibs-devel (fails) and libcdda0-devel (is installed) I can't judge the interals of urpmi (I'm a no-no in perl) but the difference I see with urpmi shipped with 9.1 is that urpmi now splits up the job into smaller bits and tries to install those, seperately. The nice things of the version shipped with 9.1 are: - it does the calculation first; - if something isn't right then it gives the reason why something has failed; - when something is wrong in the calculation it doesn't install any packages. With the current version it goes ahead and tries to install packages anyway, leaving the user with without the package he wanted to install. There is also no clear error message that the package he was trying to install didn't make it, or why it didn't make it. There are some messages (for the individual packages) why they didn't make it, but these often overlap -- because package A failed to install, package B also failed to install. Instead of giving the combined error, which in most cases will be LESS, now the user can go ahead and puzzle what is going on. May I ask what the long term strategy is for urpmi? Are these issues known and being worked on? Is there a possibility to get the 9.1 version back? Why I'm saying this: urpmi isn't helping me (with slbd) at this momment. I'm capable to install kdelibs-devel by hand on a system and the system ends up without any dependency issues, and only with cooker packages. Why can't urpmi do the same? It _used_ to be possible... regards, Stefan PS: this issue isn't limited to kdelibs-devel. The number of packages that can't be installed due to urpmi not being able to install the BuildRequires is increasing, on a daily basis. See: Packages with missing BuildRequires: http://eijk.homelinux.org/build/cooker/i586/ Urpmi install logs: http://eijk.homelinux.org/build/cooker/urpmi/i586/
Re: [Cooker] urpmi wierdness
Stefan van der Eijk [EMAIL PROTECTED] writes: Hello, Hello, I'm having some issues with urpmi lately. Take a look here: http://eijk.homelinux.org/build/cooker/urpmi/i586/k3b-0.9-2mdk There is a strange things with your rpm database, at the very beginning, libexpat0 is installed and in another transaction later, fontconfig and libfontconfig1 installation fails due to libexpat.so.0 not available which are provided by the previous installation of libexpat0 normally... I can't deny to say that what you're seeing is strange, I also think it's strange. What we're talking about is a chrooted install, but the db seems fine to me: # chroot /chroot/cooker/ [EMAIL PROTECTED] /]# rpm -Va S.5T c /etc/bashrc S.5T c /etc/services ..5T c /etc/shells L... /lib/cpp S.5T c /etc/info-dir ...T c /etc/syslog.conf S.5T c /etc/rc.d/init.d/functions Any other way to check the health of the installation? Anyway, I changed slbd to use --split-length 0 and here's the result: http://eijk.homelinux.org/build/cooker/urpmi/i586/k3b-0.9-2mdk All packages install as expected -- the old behavior is back my problem seems fixed. Question remains: why aren't the packages installed properly without setting this option? regards, Stefan
Re: [Cooker] Re: [CHRPM] perl-5.8.0-28mdk gaim
Still there... # rpm -Fvh perl-5.8.0-29mdk.i586.rpm perl-base-5.8.0-29mdk.i586.rpm error: Failed dependencies: perl-base = 5.8.0 is needed by (installed) gaim-0.64-2mdk perl gaim are still fighting when perl is upgraded. Situation is simliar with some kde packages and arts. # rpm -Fvh perl-*5.8* error: Failed dependencies: perl-base = 5.8.0 is needed by (installed) gaim-0.64-1mdk --=-=-= * Wed Jul 16 2003 Pixel [EMAIL PROTECTED] 5.8.0-28mdk - Getopt::Long 2.33 02 --=-=-= smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] beta of updated mdk-rpm-howto
Guillaume, Could you do us a favour? Merge it into the one on the wiki? http://qa.mandrakesoft.com/twiki/bin/view/Main/MandrakeLinux?topic=RpmHowto Thanks, Stefan Available here: http://peoples.mandrakesoft.com/~gc/mdk-rpm-howto/ Interesting/important changelogs: revision 1.28 date: 2003/07/28 17:07:36; author: gc; state: Exp; lines: +7 -3 protect update-alternatives --remove in case we don't remove the package revision 1.26 date: 2003/07/28 16:13:22; author: gc; state: Exp; lines: +35 -8 static-devel lib policy revision 1.25 date: 2003/07/28 15:50:17; author: gc; state: Exp; lines: +32 -3 percent-makeinstall_std and percent-configure2_5x revision 1.24 date: 2003/07/28 15:19:05; author: gc; state: Exp; lines: +9 -1 percent-mklibname Please spot problems (with suggestions if possible), and ask for more undocumented stuff I've forgotten (with details). PS: yes I'm back from holidays :/
[Cooker] Re: [Contrib-Rpm] squirrelmail-1.4.1-1mdk
Giuseppe, * Sat Jul 26 2003 Giuseppe Ghibò [EMAIL PROTECTED] 1.4.1-1mdk - Release 1.4.1. - Removed Patch0. - Added Patch8 from select_range plugin. - added session.bug_compat_42 Off to php config. - added safe_mode Off to php config, otherwise can't send mails. - change $default_folder_prefix from mail/ to , as it's already set in this way in the latest uw-imap-2002d rpm. - Added change_pass plugin to change password (Requires: poppassd-ceti). --=-=-= I'm having a slight problem with this version of Squirrelmail: When I want to browse my Inbox I get the following error: *ERROR:* *ERROR : Bad or malformed request.* Query: FETCH (FLAGS UID RFC822.SIZE BODY.PEEK[HEADER.FIELDS (Date To Cc From Subject X-Priority Content-Type)]) Server responded: Bogus sequence in UID FETCH The other folders work fine. I searched the Squirrelmail site and found the following on it. It's a know issue and it was solved right after 1.4.1 release. Regards, Stefan http://www.squirrelmail.org/wiki/en_US/CompatibilityErrorWithUW CompatibilityErrorWithUW http://www.squirrelmail.org/wiki/en_US/find/CompatibilityErrorWithUW SquirrelMail http://www.squirrelmail.org/wiki/en_US/SquirrelMail | RecentChanges http://www.squirrelmail.org/wiki/en_US/RecentChanges | Preferences http://www.squirrelmail.org/wiki/en_US/preferences /Unknown error: * CAPABILITY IMAP4 IMAP4REV1/ (Error message was trimmed) If you get this error with UW IMAP 2000, you need to upgrade your SquirrelMail http://www.squirrelmail.org/wiki/en_US/SquirrelMail installation. This was fixed several versions ago (and there's some new security and features since your version). It happened because we didn't properly parse the login string. UW 2000 was the first server that we have seen that added extra lines of information when logging in, even though it was in the RFC properly. It's all better now. -- I have uw-IMAP on Redhat 8 with php version 4.2.2 and SM 1.4.1, when I turn on server-threading I intermittently get the following error in my message list for my INBOX (or any other folder where i've turned threading on); ERROR : Bad or malformed request. Query: FETCH (FLAGS UID RFC822.SIZE BODY.PEEK[HEADER.FIELDS (Date To Cc From Subject X-Priority Content-Type)]) Server responded: Bogus sequence in UID FETCH Once I get this error it's there solidly until I edit my .conf file and turn threading off for that folder or globally turn it off at conf.pl. It's annoying because I have to be in a shell session and I don't have shell access from work, the reason I turned to SM in the first place... and i'm left with unreadable INBOX until I get home. I don't have a solution, other than to not turn threading on. It's annoying as I like threading view. I set up the IMAP server type as 'uw', I'm not sure if it's made any difference; also I've added extra memory to php.ini, again I will have to test to see what condition turns the mailbox threading bad. scot. *There is a solution. Uprade to the latest SquirrelMail http://www.squirrelmail.org/wiki/en_US/SquirrelMail 1.4.2 CVS STABLE snapshot. This was fixed shortly after the release of 1.4.1* Marc Groot Koerkamp. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] openldap 2.1.22 inkompatible to directory_administrator-1.4-1
Falko, I do suggest you try the new directory administrator package as Buchan said. We want to be able to run openldap with as little configuration changes as possible. thanks I should try it on Monday, which security issues does you mean?? I'm not sure if there are security issues with these setting, but it does sound like it: From slapd.conf(5) man page: allow features Specify a set of features (separated by white space) to allow (default none). bind_v2 allows acceptance of LDAPv2 bind requests. Note that slapd(8) does not truely implement LDAPv2 (RFC 1777), now Historic (RFC 3494). bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty). bind_anon_dn allows unauthenticated (anonymous) bind when DN is not empty. update_anon allow unauthenticated (anony- mous) update operations to be processed (subject to access con- trols and other administrative limits). As you can see, some annoymous actions are allowed with these options. There may be cases where the information stored in the LDAP is to be kept confidential and you only want authenticated requests to be able to access it. My concern is that with these options: bind_anon_cred bind_anon_dn (not: bind_v2) information leakage may be possible. I needed my LDAP to work again quickly (also using autofs) and this made it happen... If you copy these settings, I suggest you look into the *possible* consequences -- I won't accept responsibility if these setting lead to your LDAP server being opened up. Regards, Stefan Regards Falko On Sat, 26 Jul 2003 01:49:31 +0200 Stefan van der Eijk [EMAIL PROTECTED] wrote: Add the following line to the end of /etc/openldap/slapd.conf: allow bind_anon_cred bind_anon_dn bind_v2 It works for me (I had the same issues) but there may be security consequences with this configuration. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] kernel 2.6
Olivier Thauvin wrote: Le Vendredi 25 Juillet 2003 22:41, Warly a écrit : Anyone with a kernel 2.6 can upload it. Of course the Andrey supermount patch included would increase significanly its sex appeal. I am working on a spec, of course it will minimal. My goal is not to make it perfect, I can't, but quickly upload something to make my works availlable for any other jedi. I have somethings buildable: - kernel-2.6.0-test1 - patch-ac3 - supermount patch (rediff over -ac3 patch) But, dear kernel team, please, make somethings buildable on all arch ! If you need account on computer, ask ! I saw in 2.4 spec sparc is still blacklist. Are you aware we are trying to restart cooker on this arch ? We don't want you make all the works, but please help us ! same applies to alpha, ppc and x86_64 Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] openldap 2.1.22 inkompatible to directory_administrator-1.4-1
Falko Pilz wrote: Hello, I've today updatet my LDAP-Server (not critical still a playground) After that an also updatet directory_administrator couldn't access the LDAP-Server because of an LDAP-protocol mismatch / disallowed. Pecause of that openldap's tools like ldapsearch and ldapadd still works my question is, because of no config changes. It could an error in dir_adm or in openldap the protocol was changed. Regards Falko Add the following line to the end of /etc/openldap/slapd.conf: allow bind_anon_cred bind_anon_dn bind_v2 It works for me (I had the same issues) but there may be security consequences with this configuration. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] RedHat trying to beat us at our own game?
Keld Jørn Simonsen wrote: On Wed, Jul 23, 2003 at 11:50:14AM +0100, Jaroslaw Zachwieja wrote: On ??ro 23. lipca 2003 11:39, Keld Jørn Simonsen wrote: On Wed, Jul 23, 2003 at 08:22:48AM +0100, Jaroslaw Zachwieja wrote: On ?ro 23. lipca 2003 03:34, Olivier Thauvin wrote: But lot of things are actually missing in RH: urpmi Cmon, RH makes money on up2date - they have a real package management system, just want you to pay money for it. Apt-get still a pile of --force --nodeps poo. apt-get is production quality for redhat. But not for Mandrake. Probably due to errors in the dependencies. You call broken updates, upgrades, conflicts, unintentional rollbacks and coredumps a production quality??? Maybe in RH terms : I have not experienced that. Anyway I would be interested in hearing about your experiences, and suggested ways forward. They say that apt-get works swell on debian, so distributions like redhat and mandrake should be able to do it too. And mandrakeupdate/urpmi and up2date do the job - where is the difference? Main difference (IMHO, from what I've seen): * urpmi is a cash generator. You need to pay (or tollerate being nagged every 60 days) to use it; * up2date only has installing / upgrading functionality, like urpmi; * up2date doesn't have functionality of urpme (removing packages) urpmf (listing files contained in packages), urpmq querying packages (dependencies, Provides / Requires, versions, etc); * up2date can't connect to more media. With urpmi it's possible to configure multiple media and have different media servicing different environments -- /chroot/9.0 uses --media=9.0, /chroot/9.1 uses --media =9.1, etc) * RedHat's errata's don't provide hdlists. This makes using urpmi on them (without downloading the whole thing to make your own hdlists) less attractive; * Nice thing about up2date is the web interface where it's possible to manage packages on your system(s); Has anybody provided an alternative service for RHN / up2date? This should be possible, since which service you connect to is configureable, and the up2date software itself is open. Just putting the server part together. Leverage the Internet mirrors or torent, and price it at 50% of what RHN costs... You can't call it RedHat, then make it RedCapNetwork...Why not? RedHat made a biz-model out of keeping systems up2date, which makes sense. Mandrake built a technically superior product (IMHO), but just forgot the biz-model... regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] RedHat trying to beat us at our own game?
Andi Payn wrote: On Wednesday 23 July 2003 09:54, Luca Olivetti wrote: Andi Payn wrote: On the other hand, the fact that it's so much easier to get stuff into Mandrake contribs I beg to differ. I took more than a year to get cyrus-imapd in contribs. Not saying it's as easy as it ideally should be, just that it's usually much easier than getting stuff into Redhat. (Which is why freshrpms and similar collections exist.) actually, we should try to get some agreement on packaging standards with RedHat, or at least, with their contributors, so that at least these contrib archives can be merged... or am I being the idealist again? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] RedHat trying to beat us at our own game?
Main difference (IMHO, from what I've seen): * urpmi is a cash generator. You need to pay (or tollerate being nagged every 60 days) to use it; I think you mean up2date is a cash generator; Yes, yet annother typo :-/ urpmi is more a cash drainer for Mandrake: They pay people to code urpmi and keep the repositories up to date, but since not a single Mandrake user knows how cool urpmi is it generates $0 in new sales. Of course if everyone knew how cool urpmi was, that'd be a different story. I recently managed to get someone off of Debian after two years of listening to him bitch about how Woe is me, Debian is so out of date, but I can't live without apt-get, and I can't believe anything like that could work for rpm. I did the same with a number of Sun employees. And this was already back in 2001, even then urpmi was cool. * up2date can't connect to more media. With urpmi it's possible to configure multiple media and have different media servicing different environments -- /chroot/9.0 uses --media=9.0, /chroot/9.1 uses --media =9.1, etc) If you run up2date from within the chroots (using /chroot/8.1/usr/sbin/up2date, /chroot/9/usr/sbin/up2date, etc., and the corresponding /chroot/*/etc/whatever-up2date-uses) they can each have their own media (by selecting a different service and/or by having a different /etc/redhat-release file). What you can't do is update a _single_ environment from multiple media (e.g., the way most people have main, contribs, update, and plf as media and urpmi searches all of them). True. * Nice thing about up2date is the web interface where it's possible to manage packages on your system(s); If we got gnorpm working again, we'd have the same functionality, wouldn't we? And you forgot another big difference: * up2date has an automated update system, which (IIRC) can tell you when new updates are available, optionally automatically download them for you when your online and idle, and even more optionally automatically install them for you. True. Doesn't MDK have something like this in place? Has anybody provided an alternative service for RHN / up2date? This should be possible, since which service you connect to is configureable, and the up2date software itself is open. Just putting the server part together. I think the server software is also open source. So just get a server and run it, right? exactly. Leverage the Internet mirrors or torent, and price it at 50% of what RHN costs... You can't call it RedHat, then make it RedCapNetwork...Why not? In my last post, I suggested a group of Redhat users running such a service for free. But yeah, I guess the same idea could also be used to run the service for half price. RedCapNetwork could still be a trademark violation; if your name is intended to or likely to confuse or mislead a reasonable customer, you can't use it. So, if you're sure it'd be obvious to any reasonable person you (or Redhat's lawyers) can imagine that RCN isn't the same thing as RHN, you'd be fine, but I'm not sure it is, and Redhat probably has better lawyers than you. Why not just call it Up2date Network? Or, if they've trademarked up2date just RPM Update Network. BlueCapNetwork? :-) RedHat made a biz-model out of keeping systems up2date, which makes sense. Mandrake built a technically superior product (IMHO), but just forgot the biz-model... I doubt up2date is a substantial piece of Redhat's revenue; I just don't see how a subscription service for a free distribution that anyone else can give away updates for isn't going to make you rich. Especially when you give it to individuals and non-commercial organizations for free, Not anymore. It's (demo) becoming nagware. And there are limitations on the functionality of the nag version. When managing more than 1 server you'd really want the basic or perhaps enterpise scheme. See: http://www.redhat.com/software/rhn/offerings/ and you throw it in with the service contracts you sell to corporate customers. perhaps. anyway, how much would it cost RH to run the RHN service? Now, if you throw in a few proprietary programs (which users _can't_ just share with each other or set up their own mirrors for)... well, then you have MandrakeClub minus the goodwill. Which might make you half as rich and successful as Mandrake hmmm... wasn't RH making more $$$ than MDK? MDK is giving away the updates _and_ the mechanism to do it efficiently away for free. At least RH has made it part of their biz model. And it probably doesn't cost much to operate. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] RedHat trying to beat us at our own game?
Stefan van der Eijk wrote: Keld Jørn Simonsen wrote: On Wed, Jul 23, 2003 at 11:50:14AM +0100, Jaroslaw Zachwieja wrote: On ??ro 23. lipca 2003 11:39, Keld Jørn Simonsen wrote: On Wed, Jul 23, 2003 at 08:22:48AM +0100, Jaroslaw Zachwieja wrote: On ?ro 23. lipca 2003 03:34, Olivier Thauvin wrote: But lot of things are actually missing in RH: urpmi Cmon, RH makes money on up2date - they have a real package management system, just want you to pay money for it. Apt-get still a pile of --force --nodeps poo. apt-get is production quality for redhat. But not for Mandrake. Probably due to errors in the dependencies. You call broken updates, upgrades, conflicts, unintentional rollbacks and coredumps a production quality??? Maybe in RH terms : I have not experienced that. Anyway I would be interested in hearing about your experiences, and suggested ways forward. They say that apt-get works swell on debian, so distributions like redhat and mandrake should be able to do it too. And mandrakeupdate/urpmi and up2date do the job - where is the difference? Main difference (IMHO, from what I've seen): * urpmi is a cash generator. You need to pay (or tollerate being nagged every 60 days) to use it; that should have been up2date, not urpmi. flame me!!! regards, Stefan PS: Mom told me to get 7-8 hours of sleep a day, why don't I just stick to it?? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] RedHat trying to beat us at our own game?
Andi Payn wrote: On Wednesday 23 July 2003 13:13, Stefan van der Eijk wrote: Andi Payn wrote: Not saying it's as easy as it ideally should be, just that it's usually much easier than getting stuff into Redhat. (Which is why freshrpms and similar collections exist.) actually, we should try to get some agreement on packaging standards with RedHat, or at least, with their contributors, so that at least these contrib archives can be merged... or am I being the idealist again? I agree with you, but yes, you probably are. In fact, I think we had essentially this same discussion around the time of the 9.1 beta, and most people thought we were being too idealistic. What you're looking for is a system to ensure that, without access to both both Redhat and Mandrake boxes, a contributor can create a package that will build on either (I don't think it's necessary that, having been built on one, it will install on the other). Right? Just having src.rpm compatibility would be nice to start with. I don't beleive in binary compat anymore :-/ the .spec might be littered with defines, but hey, get more done in less time for a larger audience... defining these standards is going to be dikke stront though... I've thought about this before, and I can write up a concrete proposal for the tools and policies needed, if people other than Stefan are interested. If not, I won't waste my time and the list's bandwidth. First, IMHO, we need to get our own packaing policies up2date with what they're doing. RPM howto is on the wiki -- hint! Then we can discuss with others on how they do things, where the differences are and how things can be packaged so that it will build on both sides. By the way, has anyone wondered whether Redhat has any interest in more cooperation with Mandrake? It's all well and good for Mandrake developers and contributors to look for ways to help Redhat be more like our favorite distro, but it's always possible they'd look at it more as hostile subversion than as altruism I really don't know... It's on my todo list to join the RH community thingy... regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] RedHat trying to beat us at our own game?
http://www.linuxandmain.com/modules.php?name=Newsfile=articlesid=364 This is the proof that we are on the good way. Mandrake is then the leader :-) Next step : RH will be a retailer of Mandrake boxes ! Hmmm, compare: http://rhl.redhat.com/ to: http://qa.mandrakesoft.com/wiki Just wondering how OPEN RedHat will be to changes other souls bring in... I'll be keeping an eye on it... could be interesting to get some of MDK's ideas into RHL. Standardisation. More competition. WDYT? smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] [Bug 4230] [initscripts] New: killproc kills outside it own chroot
http://qa.mandrakesoft.com/show_bug.cgi?id=4230 Product: initscripts Component: initscripts Summary: killproc kills outside it own chroot Product: initscripts Version: 7.06-14mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: initscripts AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] native system: / chroot system: /chroot xfs is used as an example, same applies to other daemons (cron, etc) Deinstall XFree86-xfs from chroot system. xfs is not running in chroot (no pid file), killproc doesn't find a pid file, looks up the xfs processes in the process table and kills them. Result: xfs running in native system ( / ) is killed. possible fix: check if the process you are trying to kill has the same root. - lsof will give this information in rtd. - compare if /proc/$$/root = /proc/$kill_pid/root -- 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.
Re: [Cooker] RedHat trying to beat us at our own game?
Just wondering how OPEN RedHat will be to changes other souls bring in... I'll be keeping an eye on it... could be interesting to get some of MDK's ideas into RHL. Like separate lib packages, urpm, and version numbers with dots? yes perl and devel dependencies, etc. Let's face it, RedHat is more likely to survive... By the way, has anyone downloaded their new beta yet? What version is it? I think that more user participation is going to be especially hard for Redhat, considering the problems they'll have disentangling distro problems from upstream problems. If a GNOME package has a bug, they can't exactly say, not our fault, go talk to Havoc. Very true. Considering how Mandrake is dealing with it, Mandrake has been quite open to contributors for a number of years, and is opening up more lately. RedHat will go through the same pains... But I find it interesting to follow, from an organisation point of view. I've discussed with my collegues about my suggestions that MDK should open up their development more (do stuff WiKi style). One of them suggested to bring in a sociologist to observe what's happening... In effect, what is going on at MDK can be considered a social experiment :-) Let's hope the experiment will go down in history as a succes. Interesting read: http://workingknowledge.hbs.edu/pubitem.jhtml?id=3582t=technology regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] RedHat trying to beat us at our own game?
I've discussed with my collegues about my suggestions that MDK should open up their development more you mean about: - distro devel (that is packaging) ? to start with, yes. - tools (that is giving the communauty more control on tool design or even let some people alter tools) ? if / when some good pops up, certainly. The key thing mdk needs to do is have control and overview. Make things transparant, auditable and be able to roll-back changes that didn't work out that well. Leverage the good stuff that is available out there... Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Mdk-rpm-howto on the wiki ( was : [CHRPM] dmapi-2.0.5-3mdk)
I got started on it, but decided to ask the list first. The conclusion of the discusion was that it is a good idea, but we (I think Dams was also involved in the thread) weren't sure how it should be done. - One big document, or split up per chapter? IMHO, split up by chapter is better. One big docuement is not pratical, because of the time evolved to transmit it over the net , to read it and so on. With one big page, we will see that all the document have been updated. With small chapter, we will see which chapter have changed. - Naming of chapters in WiKi style or not? This would be consistent to name them in a wiki-like fashion, and will favorate the linking through the pages. I do not see why we should not name them in the wiki style, but, i may be wrong. Just put the document on the WiKi. It's one big document (for the moment), and I've started applying WiKi to it. How to go forward: - First get the document in WiKi, so it's 100% identical as the original HTML document. - Then start splitting it up and doing smart WiKi stuff with it... I've you've got access to the WiKi and have nothing todo, feel free to WiKi it. Original document: http://www.linux-mandrake.com/howtos/mdk-rpm/mdk-rpm.html WiKi document: http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowto regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] Re: [CHRPM] nfs-utils-1.0.4-1mdk -- rpc.mountd crashes
--=-=-= * Wed Jul 16 2003 Juan Quintela [EMAIL PROTECTED] 1.0.4-1mdk - remove patch5 (time.h) already included upstream. - remove patch2 no-chroot (not needed after removing patch0). - remove patch0 (drop privs) included better patch upstream. - 1.0.4. --=-=-= I just updated this package, and rpc.mountd crashes on the second request it gets: Restart the NFS services: [EMAIL PROTECTED] root]# service nfs stop Stopping NFS mountd:[FAILED] Stopping NFS daemon:[FAILED] Stopping NFS services: [ OK ] [EMAIL PROTECTED] root]# service nfs start Starting NFS services: [ OK ] Starting NFS daemon:[ OK ] Starting NFS mountd:[ OK ] check to see if rpc.mountd is running: [EMAIL PROTECTED] root]# service nfs status rpc.mountd (pid 3192) is running... nfsd (pid 3181) is running... 3180 (pid 3179) is running... 3178 (pid 3177) is running... 3174 (pid 3173) is running... 3172 (pid ) is running... on the remote system: # ls /mirrors/cooker/SRPMS check to see if rpc.mountd is still running: [EMAIL PROTECTED] root]# service nfs status rpc.mountd (pid 3192) is running... nfsd (pid 3181) is running... 3180 (pid 3179) is running... 3178 (pid 3177) is running... 3174 (pid 3173) is running... 3172 (pid ) is running... on the remote system: # ls /mirrors/contrib/SRPMS *ls: /mirrors/contrib/SRPMS: No such file or directory* check to see if rpc.mountd is running: [EMAIL PROTECTED] root]# service nfs status *rpc.mountd is stopped* nfsd (pid 3181) is running... 3180 (pid 3179) is running... 3178 (pid 3177) is running... 3174 (pid 3173) is running... 3172 (pid ) is running... On my network this is reproduceable. rpc.mountd survives the first request, the second request kills it. Anybody else see this behaviour? regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] nfs-utils-1.0.4-1mdk -- rpc.mountd crashes
Juan Quintela wrote: stefan == Stefan van der Eijk [EMAIL PROTECTED] writes: --=-=-= * Wed Jul 16 2003 Juan Quintela [EMAIL PROTECTED] 1.0.4-1mdk - remove patch5 (time.h) already included upstream. - remove patch2 no-chroot (not needed after removing patch0). - remove patch0 (drop privs) included better patch upstream. - 1.0.4. --=-=-= stefan I just updated this package, and rpc.mountd crashes on the second stefan request it gets: Damn thing, will test here. I tested it lightly before shipping, but it looked as if it worked well. No problem, these things happen. Thanks for your quick reply! If I can be of any assistance to test anything, please inform me. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
Gwenole Beauchesne wrote:
On Thu, 17 Jul 2003, Stefan van der Eijk wrote:
* Thu Jul 17 2003 Stefan van der Eijk [EMAIL PROTECTED] 2.0.5-3mdk
- add missing .so symlink in /lib
- Why put a .so symlink in /lib?
- Why use /lib since it was necessary to use /%{_lib} and fixed that way?
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Funny thing is, it is installed in the build dir, but I guess symlinks
are not detected as unpackaged files.
And at the moment xfsdump doesn't compile, and this fixes that:
http://eijk.homelinux.org/build/cooker/i586/problem/xfsdump-2.0.3-1mdk
/usr/bin/libtool --mode=link gcc -o xfsdump arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stream.o util.o sproc.o inv_api.o inv_core.o inv_files.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o hsmapi.o inomap.o var.o /usr/lib/libuuid.a /usr/lib/libhandle.la /usr/lib/libattr.la /usr/lib/libdm.la ../librmt/librmt.la
mkdir .libs
gcc -o xfsdump arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stream.o util.o sproc.o inv_api.o inv_core.o inv_files.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o hsmapi.o inomap.o var.o /usr/lib/libuuid.a /lib/libhandle.so /lib/libattr.so /lib/libdm.so ../librmt/.libs/librmt.al
gcc: /lib/libdm.so: No such file or directory
make[1]: *** [xfsdump] Error 1
make: *** [default] Error 2
error: Bad exit status from /home/slbd/tmp/rpm-tmp.16807 (%build)
Any objections to updating xfsdump to 2.2.3?
# diff xfsdump.spec.orig xfsdump.spec
2c2
%define version 2.0.3
---
%define version 2.2.3
16c16,20
BuildRequires: libattr-devel libext2fs-devel libxfs-devel libdm-devel
---
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
BuildRequires:ncurses-devel
46a51,53
# Remove unpackaged files (se)
rm -rf %{buildroot}/%{_docdir}/%{name}
53c60
/sbin/*
---
%{_bindir}/*
57a65,70
* Thu Jul 18 2003 Stefan van der Eijk [EMAIL PROTECTED] 2.2.3-1mdk
- 2.2.3
- remove unpackaged files
- some files in %%{_bindir}/*
- no more files in /sbin/*
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
symlinks.
Fine with me, as long as xfsdump will build.
And I insist on %{_lib} %{_libdir}. I had fixed that for lib64
but this magically vanished.
Yes, I agree. Sorry about that.
Any objections to updating xfsdump to 2.2.3?
I don't know, kernel people will answer. And I suppose Vincent already
issued an update to 2.2.3.
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
Always BuildRequires: thing-devel forms only, not libthing-devel.
Sure, but:
$ urpmq attr-devel
no package named attr-devel
$ urpmq dm-devel
no package named dm-devel
$ urpmq ext2fs-devel
no package named ext2fs-devel
$ urpmq xfs-devel
no package named xfs-devel
I understand where this is coming from, and I agree that it needs to be
done. But I don't think that it needs to be brought up in this
discussion. I'm getting the feeling that somebody is looking for
something to pick on...
I suggest:
* rpmlint is adjusted to warn about ( enforce?) this on uploads;
* a document is written describing these changes so this can be
finalized into some sort of guideline / policy. So people can
read it through, understand how it works and how it should be
implemented in the packages;
For instance: I don't understand how the mklib stuff works and how I
should fix the rpmlint errors I get on the topic.
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
symlinks.
Fine with me, as long as xfsdump will build.
And I insist on %{_lib} %{_libdir}. I had fixed that for lib64
but this magically vanished.
Yes, I agree. Sorry about that.
Any objections to updating xfsdump to 2.2.3?
I don't know, kernel people will answer. And I suppose Vincent already
issued an update to 2.2.3.
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
Always BuildRequires: thing-devel forms only, not libthing-devel.
Sure, but:
$ urpmq attr-devel
no package named attr-devel
$ urpmq dm-devel
no package named dm-devel
$ urpmq ext2fs-devel
no package named ext2fs-devel
$ urpmq xfs-devel
no package named xfs-devel
I understand where this is coming from, and I agree that it needs to be
done. But I don't think that it needs to be brought up in this
discussion. I'm getting the feeling that somebody is looking for
something to pick on...
I suggest:
* rpmlint is adjusted to warn about ( enforce?) this on uploads;
* a document is written describing these changes so this can be
finalized into some sort of guideline / policy. So people can
read it through, understand how it works and how it should be
implemented in the packages;
For instance: I don't understand how the mklib stuff works and how I
should fix the rpmlint errors I get on the topic.
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
[...] Always BuildRequires: thing-devel forms only, not libthing-devel. stefan Sure, but: ok, will fix in teh same batch. /me decides to spend the rest of the evening recompiling all his packages. Just wondering, is there going to be a scheme to retire some of the Obseletes / Provides pairs that are floating arround. Some packages are packed with them, perhaps some system / procedure can be throught of to manage this. Or to give a sign when some of them can be removed. /me thinks that this is optimist. :-) stefan $ urpmq attr-devel stefan no package named attr-devel stefan $ urpmq dm-devel stefan no package named dm-devel stefan $ urpmq ext2fs-devel stefan no package named ext2fs-devel stefan $ urpmq xfs-devel stefan no package named xfs-devel stefan I understand where this is coming from, and I agree that it needs to stefan be done. But I don't think that it needs to be brought up in this stefan discussion. I'm getting the feeling that somebody is looking for stefan something to pick on... stefan I suggest: stefan * rpmlint is adjusted to warn about ( enforce?) this on uploads; stefan * a document is written describing these changes so this can be stefan finalized into some sort of guideline / policy. So people can stefan read it through, understand how it works and how it should be stefan implemented in the packages; There is a document: http://people.mandrakesoft.com/~gc/somewhere Did you look in the TeamRoom(tm) yet? stefan For instance: I don't understand how the mklib stuff works and how I stefan should fix the rpmlint errors I get on the topic. Just fixed it for dmapi, it is trivial: %define lib_name_orig %mklibname dm instead of %define lib_name_orig libdm OK... This explains how it was done for this package. I guess this can be applied to any package complaining about missing mklib? Rule of thumb: - when you have a problem of that kind, look for a package maintained by gb about how it is done there :p uhm... you are kidding, right? We need to do better than this... at least write a page on the wiki about it... or make a link on the wiki to where the document is. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
[Cooker] [Bug 4207] [rpm] New: BuildRequires parsing (rpm -qpR) incorrect
http://qa.mandrakesoft.com/show_bug.cgi?id=4207
Product: rpm
Component: program
Summary: BuildRequires parsing (rpm -qpR) incorrect
Product: rpm
Version: 4.2-12mdk
Platform: PC
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: program
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I think there is a bug in the mechanism to get the BuildRequires out of a
package with rpm -qpR.
Where is gd-devel?:
$ rpm -qpR /mirrors/cooker/SRPMS/glibc-2.3.2-5mdk.src.rpm | sort
binutils = 2.13.90.0.18-2mdk
gcc = 2.96-0.50mdk
gettext
patch
perl
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(VersionedDependencies) = 3.0.3-1
tetex
tetex-latex
texinfo
But there in glibc.spec:
# Define to bootstrap new glibc
%define build_bootstrap0
%define build_profile1
%define build_nscd1
%define build_doc1
%define build_utils1
%define build_i18ndata1
%define build_timezone1
# Disable a few defaults when cross-compiling a glibc
%if %{name} != glibc
%define build_doc0
%define build_pdf_doc0
%define build_biarch0
%define build_check0
%define build_debug0
%define build_nscd0
%define build_profile0
%define build_utils0
%define build_i18ndata0
%define build_timezone0
%endif
# Allow --with[out] feature at rpm command line build
%{expand: %{?_without_PDF:%%global build_pdf_doc 0}}
%{expand: %{?_without_CHECK:%%global build_check 0}}
%{expand: %{?_without_UTILS:%%global build_utils 0}}
%{expand: %{?_without_BOOTSTRAP:%%global build_bootstrap 0}}
%{expand: %{?_with_PDF:%%global build_pdf_doc 1}}
%{expand: %{?_with_CHECK:%%global build_check 1}}
%{expand: %{?_with_UTILS:%%global build_utils 1}}
%{expand: %{?_with_BOOTSTRAP:%%global build_bootstrap 1}}
I guess rpm -qpR takes the define from the cross-compiling section...
--
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.
