Re: [Cooker] Some Ideas for the future
Chad wrote: 2)Next I'd propose the development of an app called some thing like bugdrake. It would be a Wizard/Gui client side front end for Bugzilla. Something like drakbug ?
Re: [Cooker] Some Ideas for the future
Le Mercredi 19 Mars 2003 10:39, Chad a crit : - resume on partial downloads as the default behavior Isn't allready done ? - rsync support (if it isn't already present) http://plf.zarb.org/~nanardon, select cooker version, search url begining by rsync://, oh ! I debug rsync support myself. - support for multiply mirror choosing the fastest/local ones first You can add multiple mirror, and choose it by a regexp with --media option. -- Linux pour Mac !? Enfin le moyen de transformer une pomme en vritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
Re: [Cooker] Some Ideas for the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2)Next I'd propose the development of an app called some thing like bugdrake. It would be a Wizard/Gui client side front end for Bugzilla. Something like drakbug ? That I hadn't noticed before :-o It's lacking some of the features I suggested though (like scaning the hardware) and it could do with alot more visability! It also doesn't seem to bother checking the dependences and their versions either. Chad - -- Fairy Tale, n.: A horror story to prepare children for the newspapers. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+eEA8IzniS8MsaSYRAsHtAJ9Raeq6mIeoJaY4eqgJaEXYrz8NiACePMLD 5mnFWWmoP8faGlvR3KETa1U= =4sag -END PGP SIGNATURE-
Re: [Cooker] Some Ideas for the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le Mercredi 19 Mars 2003 10:39, Chad a crit : - resume on partial downloads as the default behavior Isn't allready done ? Does it first I've heard of it. If I run urpmi with the noclean option and interupt it part way through downloading a pacakge it doesn't seem to resume the file it was downloading were it left off it starts on that file again doesn't it? - rsync support (if it isn't already present) http://plf.zarb.org/~nanardon, select cooker version, search url begining by rsync://, oh ! I debug rsync support myself. Not sure but to be really usefull doesn't rsync support require a local copy of the package to update (compare to the netone and d/l the difs)? Otherwise I see no difference between it and ftp. - support for multiply mirror choosing the fastest/local ones first You can add multiple mirror, and choose it by a regexp with --media option. Yes I know that but by default it only uses one of them if that mirror is lagging or down it doesn't move on to the next one does it? Chad -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+eEIRIzniS8MsaSYRAuiaAKCBE+hOPtlJJ/Er23Rnf4nJ45OisQCfScYQ 1HJ0OEeln8mbm8KkAMRMusI= =kCJR -END PGP SIGNATURE-
Re: [Cooker] Some Ideas for the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Other things that it could be used for would be for the download of large Main packages. For example the updated Kernel-source or kde packages. Urpmi could ask for the CD to be inserted grab the origional versions of the package's off that and then use rsync to update them to the new/current version of the kernel-sources/kde after all most of the kernel doesn't change between updates It would save abit of download time for dialup users. Theres over 100MB's of updates for mdk 9 if the orgional packages where copied off cd and then updated to the new versions using rsync you'd probably save at least HALF of that bandwidth and a fair bit of time! Or on systems with LOTS of storage space urpmi could creat a copy of the cooker repostitory on the disk and just update the differences when ever new versions are released and install instead of having to download the complete package each time it was changed. Chad Le Mercredi 19 Mars 2003 11:10, Chad a crit : - rsync support (if it isn't already present) http://plf.zarb.org/~nanardon, select cooker version, search url begining by rsync://, oh ! I debug rsync support myself. Not sure but to be really usefull doesn't rsync support require a local copy of the package to update (compare to the netone and d/l the difs)? Otherwise I see no difference between it and ftp. It retrieve hdlist faster because it download only diff. Otherwise, what do you mean by rsync support ? else than it actually do ? - -- Humans live best when each has his place to stand, when each knows where he be longs in the scheme of things and what he may achieve. Destroy the place and you destroy the person. - -Bene Gesserit Teaching % Has not religion claimed a patent on creation for all of these millennia? - -The Tleilaxu Question, from Muad'dib Speaks -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+eEl1IzniS8MsaSYRAhukAJ9wv8IBc0utPQWr1iYqnrnW1qAmbQCgkSyE WG/J94QGhkVlo8hWz6p9aGg= =jAgH -END PGP SIGNATURE-
Re: [Cooker] Some Ideas for the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chad wrote: 3)The final suggestion I have is for the creation of an App called something like drakecooker or cookerdrake. This would be a program for helping with cooker testing. A gui or commandline interface which could control updateing the cooker installation. Allowing users to choose when and what parts of cooker they wanted to update and set up cron jobs to do it. I don't think this is *really* necessary: [bgmilne:/home/bgmilne/rpm/BUILD]# cat /etc/cron.daily/update #!/bin/sh LOG=/var/log/updates rm -f /var/cache/urpmi/rpms/*.rpm unset ftp_proxy unset http_proxy echo Running updates on `date` $LOG urpmi.update --wget ftp1 ftp2 /var/log/updates 21 #urpmi --wget --auto-select --auto --no-verify-rpm /var/log/updates urpmi --wget --auto-select --auto /var/log/updates 21 ls /var/cache/urpmi/rpms/*.rpm /dev/null [ $? -eq 0 ] rpm -Uvh /var/cache/urpmi/rpms/*.rpm /var/log/updates 21 -It would report/list what packages had been updated after runing the update cooker command and list the changes made to them (scan the changelog in the spec file). Subscibe to the changelog list for this, you get the changelog *before* upgrading, so you can avoid packages (via skip.list) if necessary. - List requests for moreinfo on bugs and specific requests for testing of new or updated packages. Read the changelogs. (see above). It would be closely tied to bugdrake allowing easy bug reporting etc. -report bugs in areas of interest. drakbug is for people who don't subscribe to cooker. cookers are expected to be able to give better diagnostics than drakbug (ie intelligent bug reports as opposed to automated ones). So you could tell it you wanted to mainly test Multimedia pacakges it would then list new, needinfo and unresolved bugs from the mulitmedia packages section that you could have a look at, test etc. - and have a package/cvs upload front end for uploading changes or patches. If you are subscribe to cooker, you can easily filter/search bug reports in your mail client. I think a 'build-from-source' tool would be more important to cookers. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+eE+CrJK6UGDSBKcRAgOvAJ0abdIXPewOmZ0vFs2h9n9Cr3XprgCfZX3N yxztdN/p4Gwr+HW8/+mIGac= =B3v8 -END PGP SIGNATURE-
Re: [Cooker] Some Ideas for the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 3)The final suggestion I have is for the creation of an App called something like drakecooker or cookerdrake. This would be a program for helping with cooker testing. A gui or commandline interface which could control updateing the cooker installation. Allowing users to choose when and what parts of cooker they wanted to update and set up cron jobs to do it. I don't think this is *really* necessary: This was more aimed at those who've downloaded the RC's and want to help with the debuging part aren't really linux experts. The cookerdrake idea I think would still be usefull as It would provided one central location for collecting the info like requests for testing and changelog stuff It's certainly not needed for the developers but for the more casual cooker members it might be of some use. Especially for those who want to do testing but don't want to get 200 emails a day in there hotmail inbox from cooker! drakbug is for people who don't subscribe to cooker. cookers are expected to be able to give better diagnostics than drakbug (ie intelligent bug reports as opposed to automated ones). Exactly your'd want drakbug to be used by those who weren't on the cooker list. Those who aren't on cooker list are generally the ones who produce the worst bug reports! If you added the features I mentioned to drakbug and stuck it on the desktop of the RC's in plain view it would probably cut down on the number of bad bug reports that turn up. And having it grab data on dependencies, Version and hardware would help in alot of bugs. Think back to the isa sound card problem that was in cooker last week it took half a dozen emails before it was found out that the card was an ISA version. I think a 'build-from-source' tool would be more important to cookers. Yes the build from source would be the one I'd like the most by far! (urpms --flags=-march=k6-2 -o3 * ) Chad -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+eFUSIzniS8MsaSYRAnccAJoDK5byRKnciR13VbWiltUcucltpQCfQ7uG OQ2ySU2TzTbp9hrRG481ono= =eK2P -END PGP SIGNATURE-
Re: [Cooker] Some Ideas for the future
Ainsi parlait Chad : 3)The final suggestion I have is for the creation of an App called something like drakecooker or cookerdrake. This would be a program for helping with cooker testing. A gui or commandline interface which could control updateing the cooker installation. Allowing users to choose when and what parts of cooker they wanted to update and set up cron jobs to do it. -It would report/list what packages had been updated after runing the update cooker command and list the changes made to them (scan the changelog in the spec file). - List requests for moreinfo on bugs and specific requests for testing of new or updated packages. It would be closely tied to bugdrake allowing easy bug reporting etc. -report bugs in areas of interest. So you could tell it you wanted to mainly test Multimedia pacakges it would then list new, needinfo and unresolved bugs from the mulitmedia packages section that you could have a look at, test etc. - and have a package/cvs upload front end for uploading changes or patches. Cooker is supposed to be an experimental distribution, higly instable, not meant for everyday use. If you're using it, you're supposed to be some kind of unix guru able to recover your hard disk the day when booting won't work anymore. More and more users forget about this, and would like to benefit from the bleeding edge applications available in cooker without suffering any risk. Moreover, they want gui because command-line is too difficult to use, and documentation to hard to read. That's a misunderstanding of cooker purpose IMHO. Investing time and resource for improving cooker usability is a non-sense, not because we want to stay l337, but because those resource would be more useful for other purposes. Of course, we could discuss of what kind of improvement, but GUIs are definitevely too much work, and there is nothing in your list that could not be solved by some trivial script. -- Disks are always full. It is futile to try to get more disk space. Data expands to fill any void. -- Murphy's Computer Laws n4
Re: [Cooker] Some Ideas for the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chad wrote: drakbug is for people who don't subscribe to cooker. cookers are expected to be able to give better diagnostics than drakbug (ie intelligent bug reports as opposed to automated ones). Exactly your'd want drakbug to be used by those who weren't on the cooker list. Those who aren't on cooker list are generally the ones who produce the worst bug reports! If you added the features I mentioned to drakbug and stuck it on the desktop of the RC's in plain view it would probably cut down on the number of bad bug reports that turn up. And having it grab data on dependencies, Version and hardware would help in alot of bugs. Think back to the isa sound card problem that was in cooker last week it took half a dozen emails before it was found out that the card was an ISA version. The biggest problem there was the user not doing what he was asked to do, while flatly refusing to listen to what the developers told him about his card. He would most likely have complained that drakbug misrepresented his hardware anyway. And we only have the influx of bad bug reports from about RC1 onwards anyway. If you're going to add 'cooker' to the name of a tool, it had better have some value the other 85% of the time. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+eF2hrJK6UGDSBKcRAmB5AJ4gFOhtQbY2vTe8S1ObLMKORTpGLACgnkU8 osCqP8LFOYAtDR60I3OG+mw= =yU07 -END PGP SIGNATURE-
Re: [Cooker] Some Ideas for the future
It would be a Wizard/Gui client side front end for Bugzilla. Something like drakbug ? It seems to be a nice tool to help newbies reporting bugs, but how can they know that this tool exists ? I can't see any shortcut for this app in my sweet gnome menus :)
Re: [Cooker] Some Ideas for the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chad wrote: Le Mercredi 19 Mars 2003 10:39, Chad a crit : - resume on partial downloads as the default behavior Isn't allready done ? Does it first I've heard of it. If I run urpmi with the noclean option and interupt it part way through downloading a pacakge it doesn't seem to resume the file it was downloading were it left off it starts on that file again doesn't it? Maybe it works with rsync sources? - rsync support (if it isn't already present) http://plf.zarb.org/~nanardon, select cooker version, search url begining by rsync://, oh ! I debug rsync support myself. Not sure but to be really usefull doesn't rsync support require a local copy of the package to update (compare to the netone and d/l the difs)? Otherwise I see no difference between it and ftp. It will always help with hdlists ... And if Francois looks at --repackage, maybe it would be possible to rebuild a package from the installed one first, rename it to the one being downloaded, and then upagrading the new one after rysncing? Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+eE6DrJK6UGDSBKcRAvsIAJ0fCIwsq7P227K9qDsLJb7IfzBx4wCgsapg ddrxXYwYJpVyBEotI591hOw= =ZO+b -END PGP SIGNATURE-
