Re: Re: [Cooker] The Weekly Cooker -- idea.
The idea wasn't about saving bandwidth, but about increasing the testing time available for cooker. I mean 24 hours is just not enough time to give a distro any kind of full rigours of testing. A weekly ISO image, sanctioned by Mandrakesoft of the cooker distro would give a full week to testers to hack, as well as give those who like the hemoraging edge (downloading via. network every day) what they like as well. On Tue, 05 Jun 2001, Blue Lizard ([EMAIL PROTECTED]) wrote: Eaon wrote: That seems a wee bit daft. In exactly what way does it save bandwidth to have someone download 1 Gig of individual RPMs versus 1 Gig of ISOs? It's still 1 Gig. Anyway, I'm seeing ISOs there. They're kind of scattered - some in Mandrake-iso (SNF, freq, corpo) and some in Mandrake/iso (8.0) - but they are there. Eaon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Blue Lizard Sent: Monday, June 04, 2001 5:15 PM To: [EMAIL PROTECTED] Subject: Re: [Cooker] The Weekly Cooker -- idea. The big guy at rpmfind got real mad and took off ALL isos cuz it took up so much bandwidth. See the note he left in the directory. Dont think he ever put em back up. This was one day after i was downloading them both at same time amounting to 600kbs. Dont ask me. And i saw some isos and figured the move-around would confuse the mirroring process enough to get em on there :)
Re: Re: [Cooker] The Weekly Cooker -- idea.
If these weekly files were auto-generated on a weekly basis (on the mirrors themselves), AND Bugzilla had a weekly entry for the weekly cooker (dated, of course), then this would be a perfectly viable alternative. On Mon, 4 Jun 2001, pablito ([EMAIL PROTECTED]) wrote: on the Weekly Cooker idea -- wouldn't it be possible to write a script that automatically builds iso files of the current cooker every week, and stick it on the mirror sites? The script would run at a certain time every week. That way, you could have a daily cooker, and those who have troubles making these iso files could download weekly iso files. although maybe the mirrors wouldn't be happy running scripts. -- -Original Message- From: Kyle Jacobs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wednesday, May 30, 2001 7:48 PM Subject: [Cooker] The Weekly Cooker I think its time we all took a look at the cooker release policy. What we appear to be doing now is releasing daily cookers. Each day, a new Distro for public testing, tinkering and revision.
Re: Re: [Cooker] The Weekly Cooker
If the cooker releases were reduced to just 1 or 2 a week, then the Mandrakesoft staff would actually have time to test, before releasing a cooker to ensure the minimal functionality of installing, and booting. I just think that a majority of problems that weren't addressed in the 8.0 release came because of the philosohy of the gaurenteed daily releases. 24 hours isn't enough time for people to do a good job until the next release. On Wed, 30 May 2001, Tim ([EMAIL PROTECTED]) wrote: This idea has one flaw that I forsee as a fatal one. What if that one release is a complete dud? There have been times in the past when a cooker release was a complete no go for some people. They needed the daily updates to get back to testing. Perhaps personally you could just upgrade files from time to time and then do a complete install once a week for testing purposes? Personally I like my hourly cron job running the rsync script to update my local tree. Just my 2 cents. -Tim And a weekly cooker doesn't mean a featureless one. We can throw all the new, bleeding and hemorrhaging edge technology we want into the weeks cooker, and spend the week not only addressing the regular components, but also the new- technology ones. If a weekly cooker sounds too sparse, how about two weekly cookers? One at the beginning of the week, one at the end? Just thought this might be a good idea.
Re: Re: [Cooker] The Weekly Cooker
My comment was to the idea that a weekly release could be tested to ensure minimal functionality before being release for one weeks worth of testing. The originial idea is that only one or two cookers a week could not only simplify the development process, but also streamline it. Instead of having to file bug reports (That end up in the cooker mailing list) every day with every release, a single weekly release would give testers five whole days to throughly document AND test their bugs for things (like reoccourance), and five days to submit that info. The results could then go into the next weeks cooker, which could feature the fixes and the results from the previous weeks bug reports. One complaint is that some cookers don't function AT ALL, and that the next days cooker could be required to resume testing. My proposal was that the Mandrakesoft staff test at minimum the installer and boot process before releasing the weekly cooker, all other problems (including installation and boot problems not addressed already) could be submitted through Bugzilla by the public. On Thu, 31 May 2001, Vincent Meyer ([EMAIL PROTECTED]) wrote: I thought the testing was OUR job! We find the bugs, they squash the bugs, no? V. On Thursday 31 May 2001 04:57 pm, you wrote: If the cooker releases were reduced to just 1 or 2 a week, then the Mandrakesoft staff would actually have time to test, before releasing a cooker to ensure the minimal functionality of installing, and booting.
[Cooker] The Weekly Cooker
I think its time we all took a look at the cooker release policy. What we appear to be doing now is releasing daily cookers. Each day, a new Distro for public testing, tinkering and revision. I have a few concerns about this policy. First, the core value of the cooker; testing. We (the public) only get 24 hours (time zone dependent, because none of us are up or available for that whole 24 hours ) to test a distro. We're seeing all the bugs haphazardly reported into the Cooker mailing list, not bugzilla. We also don't get a lot of time to do anything with the latest cooker and submit our works. Not all bugs can be properly addressed through the cooker. Once a bug gets reported, it is almost distinctly date dependent (for a certain days cooker), and by the time its even noticed (most likely the next business day) the bug could have very well been addressed. And promptly renewed again in the next, next cooker. Even the guys at Mandrakesoft cant possibly detect, address, and fix 26 (or more) component bugs in the 8, 16 or even 20 hours they have before another cooker is produced and released. We often see a lot of reoccurring bugs (that are sometimes called todays distro, with today being a relative term) that keep appearing, even though some times we are sure they are fixed, someone complains. I propose this; A weekly cooker. Our Five cookers-a-week could be slimmed down into just one. On Monday (or Sunday) , a cooker could be released, then, for the seven days proceeding, Mandrakesoft staff and cooker fans can install, hack, crack and best of all REPORT problems. Problems reported would have days to be addressed instead of just hours (or maybe even a full day if its a weekend) before the next cooker. And, because cooker problems could be limited into just four a month, an entry for the weekly cooker could be placed into Mandrakesofts bugzilla system. After all, using bugzilla unquestionably makes it easier to manage your bug reports. Having seven days to hack, crack and break a distro also can provide more bug reports, reports that arent currently being addressed because they arent being raised. People who download cooker have less than a full day to report problems. Unless theyre installing every day with a notepad and pencil in hand to write down encountered bugs, (and they DO encounter bugs) then they might not feel so inclined to report a bug, no matter how serious. And a weekly cooker doesnt mean a featureless one. We can throw all the new, bleeding and hemorrhaging edge technology we want into the weeks cooker, and spend the week not only addressing the regular components, but also the new- technology ones. If a weekly cooker sounds too sparse, how about two weekly cookers? One at the beginning of the week, one at the end? Just thought this might be a good idea.
Re: Re: [Cooker] Eazel services picked up and expanded by Mandrake?
Cash. On Thu, 17 May 2001, Armisis Aieoln ([EMAIL PROTECTED]) wrote: What does mandrake need to make this a viable option? dave On Thursday 17 May 2001 15:04, you wrote: SI Reasoning [EMAIL PROTECTED] writes: I liked the drag and drop interface for moving files within eazel services. What if Mandrake picked it up and allowed for such things as photo galleries, etc like Yahoo. Maybe Mandrake can have a linux enhanced web portal... with email , calendering, etc... that sync's with netscape, outlook, and the gnome and kde apps like calendering, etc. this is not what it is planned in our buisness plan sigh.
[Cooker] Without Eazel, Nautilus is, what exactly?
With the sad, but expected report from Eazel softare of their recent dissoulution into Linux cyber-history, we stand only to remember the glory of their intent; Make Linux work for the masses. Amen. Now that the eulogy is done with, what on earth are we going to do about a product that is layden with Eazel Services components? I think Mandrake should concider removing all the Eazel service nonsense stuck in Nautilus, and just make it a Mozilla based GNOME enviroment (translation; make it what we're already using it for). Or, replace all the Eazel service stuff with Mandrakeupdate stuff... That would be interesting...
Re: Re: [Cooker] DANGER: WinME update may trash all non-Windows partitions
Again, there are no Windows update service packs, or other Windowsupdate critical updates that modify a volumes MBR. To do so might interfere with the existing Windows boot (or alternative method used to boot windows) and create a totaly unbootable system. If you can recall the instance where the MBR was corrupted or damaged, or more spificaly, WHICH crticial update you installed created the problem, reporting it as a bug to Microsoft would be a prudent step. To report a critical update bug, use the Windows report tool in the System Information application (Programs/Accessories/System Tools/System Information). On Thu, 10 May 2001, Simon Peter Nicholls ([EMAIL PROTECTED]) wrote: I've had exactly the same corruption we're talking about on two of my machines, but they were both running win98 second edition plus updates. No amount of fiddling would fix the partitions. At the time I had my suspicions it was scandisk doing the dirty deed. Now I keep windows trussed up in a little virtual machine file - only need it for Dreamweaver ultradev now. I tried to find a utility to lock the partition table when running under windows but failed - anyone know anything? Cheers, Si. JJ wrote: Same here, I've had Mandrake on my other partition (ext2) since win95---winME, and have used windows update with no problems, we, no problems with the ext2 partition, or Lilo.. Cheers, JJ
Re: Re: [Cooker] Standards prerelease - 30 days till...
There are two tools: 1. lsblibchk This tool will scan ALL library paths to ensure that your distro contains the nessecary library files (as defined in the LSB library dependency section of revision .9.0) this is a distro compliance checker, NOT an app complaince checker. However, the other tool; lspappchk is a PROGRAM complaince tool. This program analyzes the function calls, and what dependency library files your app uses (must be run on the COMPILED EXECUCATABLE example; lsbappchk /usr/bin/bash The following output will tell you what function calls (and library VERSIONS) are not LSB complaint, check the LSB .9.0 for what calls ARE compliant, at http://www.linuxbase.org/spec/lsbreview.html On Wed, 09 May 2001, Alessandro Ronchi ([EMAIL PROTECTED]) wrote: At 03.07 09/05/01 -0400, you wrote: Get your compliance testing software now! ftp://lsb.sourceforge.net/pub/lsb/lsbdev How does that test work? Linux mandrake 7.0 is one of the less standard distro, in the table. But a lot of things are changed from that version, what about new? Alessandro Ronchi zoddo- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-= Rappresentante degli studenti nel consiglio di Corso di laurea di Scienze dell'informazione di Cesena. http//rappresentanti.csr.unibo.it
[Cooker] Standards prerelease - 30 days till...
The LSB's somewhat tenative standards have gel'ed quite a bit, they're releasing .9.0 of their Linux standards for a 30-day peer review, then it's going to the FSF. http://www.linuxbase.org/spec/lsbreview.html I hope the cooker will be following these standards very soon. Also, developers; the LSB complaince developers tools are NOW AVAILABLE from the LSB. Its a quick, and easy process to ensure your application is LSB complaint for the future... Get your compliance testing software now! ftp://lsb.sourceforge.net/pub/lsb/lsbdev
Re: [Cooker] SGI releases XFS for Linux
I think this new file system should be available in the next cooker, just for testing purposes. After all, you never know if it's better than ReiserFS until you try it... Right? On Tue, 01 May 2001, Pierre Fortin ([EMAIL PROTECTED]) wrote: http://eltoday.com/article.php3?ltsn=2001-05-01-001-14-PS -- Support Linux development: http://www.linux- mandrake.com/donations/
Re: [Cooker] Readonly NTFS5 partitions?
Mandrake 8.0 and Cooker both have support for NTFS5 (NTFS under Win2k, and 'Whistler'). simply type the 'mount' command in reguard to which drive AND partition contains the NTFS volume Example: mount /dev/hdc1 /mnt/disk (Will mount the secondary/master hard drive's first available partition) DO NOT ENTER FILE SYSTEM TYPES in the mount command. Use the straight mount request, and the kernel will autodetect the revision of NTFS used on that volume. NOTES; Linux doesn't support Windows' Dynamic Volume's. Such as simple dynamic volumes, striped and mirrored volumes, etc. Confer with the Microsoft help in reguard to the definitions of Dynamic Volumes, striping and mirroring. On Fri, 27 Apr 2001, Robert Nicholson ([EMAIL PROTECTED]) wrote: Is there any way to get read only access to my win2k NTFS partition from Mandrake 8? OR is the NTFS support in 2.4.3 only for WinNT NTFS file systems?
Re: [Cooker] DrakConf cups autoinstall feature
I can't say it's presumptuous; the user is clearly attempting to configure the Linux print system. If CUPS is not available, it is clearly not installed, and the feature is useless. Rather than just not working, or giving a cryptic error message, the program intelligently requests the install sources so that the feature in question CAN be installed. I for one, think its time for MORE presumptuous action on the behalf of the operating system. On 22 Apr 2001 21:49:17, Eaon ([EMAIL PROTECTED]) wrote: DrakConf-0.61-44mdk I'd never used the thing before, so I was just clicking around randomly checking stuff out. When I clicked on Printing, it suddenly kicked off and installed the cups RPMs. Everything else that I clicked on that I had never used before just had a You haven't used this before. Click the Configure button to set it up message (and matching Configure button). Why does printing go and install stuff without asking first? Rather presumptuous, wouldn't you say? Eaon
Re: Re: [Cooker] Sticking to LSB
Actually, I was refering more to the FHS release, not the LSB standards. FHS release 2.1 seems to be quite solid, and with the cooker being "prerelease" by default, would be an excelent place to begin implementation toward the standard. FHS 2.2 is in public review, and as of yet, I don't see any tremendous "make and break" changes between 2.1 and 2.2. As for LSB complaince, I haven't checked up on their standards releases, but last I checked they were way too remedial of definitions to have anything to truely adhere to. This may have changed... But instituting /opt, and /media as well as the permition strucures mentioned in the 2.1 specs sounds like a good start. On 09 Apr 2001 13:30:36, Chmouel Boudjnah ([EMAIL PROTECTED]) wrote: Kyle Jacobs [EMAIL PROTECTED] writes: I feel inclined to disagree with this. It's time to get ready for the big changeover. FHS and LSB standards are very important for programmers AND distro makers to get a firm grasp of, and these tenative standards are an excelent example. FHS compliance is very important if technologies like universal installers and universal RPM's are to become popular. Subsequently, Mandrake should show its support of the upcoming standards in their release to not only bolster support of the standards, but to assist in preparing programmers as well. What do you want ? We going to do a complete switch to the current specification and in one week a troll come to change all the LSB and we had to change it again ? -- MandrakeSoft Inc http://www.chmouel.org --Chmouel
RE: [Cooker] fonts
Yes, the fonts are all fixed (Traktopel Beta 3) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ray Sent: Tuesday, April 03, 2001 3:20 PM To: [EMAIL PROTECTED] Subject: [Cooker] fonts Are the fonts fixed in the latest beta 3 ??? Kde fonts were real bad in advanced editor and viewing files in Konqueror. I just want to know before I try another install. I use the editor alot. -- Ray
RE: [Cooker] KDE or QT crashing
Mandrakesoft DOES maintian a bugzilla tracking system for Mandrake Linux users. You need to 'register' an e-mail address to submit the reports, but aside from that, its a pretty straight forward process. On the web @ https://qa.mandrakesoft.com Yes, you do need an SSL complaint web-browser to visit this site. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Carl Olof Englund Sent: Tuesday, April 03, 2001 7:58 PM To: [EMAIL PROTECTED] Subject: [Cooker] KDE or QT crashing I hope I can send this to this list.. I didn't see any Mandrake bug reports list, probably because you should report problems to the separate program developers. I did post this to one of the KDE lists but so far noone has noticed and the bug report wizard only allows you to select separate applications while this concerns the entire KDE.. SO.. I'm running Linux Mandrake 7.2 with some updates (KDE and QT, anyway) on two computers. KDE RPM versions are 2.0.1-1mdk and 2.0.1-2mdk. On the P166 KDE is extremely unstable while on my P233MMX it's stable enough to be of use. Gnome works like a charm on both of them. I've tried reinstalling KDE and the KDE/QT updates for Mandrake 7.2, but to no avail. I'm hoping we could pinpoint the problem and have it fixed by the time Mandrake 8 is released. Can I get you any technical information about the system (P166)? What do you want and how can I obtain it? / Carl -- -- "So slay me now! I have little magic left." - Kallak, leader of the royal mystics (The legend of Kyrandia) http://www.acc.umu.se/~diskdoc --
