Accepted trac 0.11.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 16 Aug 2008 00:08:30 +0100 Source: trac Binary: trac Architecture: source all Version: 0.11.1-2 Distribution: unstable Urgency: low Maintainer: Debian Trac Team [EMAIL PROTECTED] Changed-By: Luis Matos [EMAIL PROTECTED] Description: trac - Enhanced wiki and issue tracking system for software development Closes: 495019 Changes: trac (0.11.1-2) unstable; urgency=low . * Upstream version Trac 0.11.1 contains a number of bug fixes and minor enhancements. * Patch setup.py to install the contrib dir ( Closes: #495019 ) * Modified compatible version of trac-bzr so that trac 0.11.1 an be used with the current trac-bzr version. Checksums-Sha1: d0bf72110b94fdea838923a77b17484b507ba287 1390 trac_0.11.1-2.dsc 162b750c80927471c157f02db79ee6b6398fe9e9 27398 trac_0.11.1-2.diff.gz 60a54a12288a546285aa2dbf051c67217e0d6759 557128 trac_0.11.1-2_all.deb Checksums-Sha256: 58ff1a477642b4f0705fbd140d345bb88b9d78906bb180d8a16d2294f35b7696 1390 trac_0.11.1-2.dsc 4d12308a31b63b071a4beff4ae68abe4cdacbd266518119be9920f9b771e9e68 27398 trac_0.11.1-2.diff.gz b00ddf1bae5bac7579e627d529d2406cdf1169e4d4b189c0e5c67c4aa2f4af88 557128 trac_0.11.1-2_all.deb Files: 2fda01ebbfdffbfc7ad6c30158cf2d2a 1390 web optional trac_0.11.1-2.dsc e76b05ce9066655a7d5d37cf7fcae992 27398 web optional trac_0.11.1-2.diff.gz 1dbb035c853a04e196ddfc5bbd8f682a 557128 web optional trac_0.11.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFIpxdlYzuFKFF44qURAlT9AJ9ydwdcOqID/t84aFrpesQU5CE4nwCfWBM5 7UmDpXEDWJ3gSNcvoA2myS0= =76ie -END PGP SIGNATURE- Accepted: trac_0.11.1-2.diff.gz to pool/main/t/trac/trac_0.11.1-2.diff.gz trac_0.11.1-2.dsc to pool/main/t/trac/trac_0.11.1-2.dsc trac_0.11.1-2_all.deb to pool/main/t/trac/trac_0.11.1-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted trac 0.11.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 07 Aug 2008 02:06:25 +0100 Source: trac Binary: trac Architecture: source all Version: 0.11.1-1 Distribution: experimental Urgency: low Maintainer: Debian Trac Team [EMAIL PROTECTED] Changed-By: Luis Matos [EMAIL PROTECTED] Description: trac - Enhanced wiki and issue tracking system for software development Closes: 400774 435321 436293 493079 494003 Changes: trac (0.11.1-1) experimental; urgency=low . * New upstream version * Added dh_link to debian/rules Closes: #494003. * Adding $(PYVER) in rules also Closes: #493079. * Trac 0.11 also seems to close old bugs. ( Closes: #436293, #400774, #435321 ). Checksums-Sha1: fad369a3ff05cee70499d158af5ddbe1f5a546d0 1398 trac_0.11.1-1.dsc d5f4141a6501a059f46d69259bdb56c36f60096b 685841 trac_0.11.1.orig.tar.gz b8e6b6b4fdb7d7507cfc2bafeea3b5c4c8d8d243 26953 trac_0.11.1-1.diff.gz 1c7edc0d2e9478e28a28fab3d07f8644939bd3d0 536480 trac_0.11.1-1_all.deb Checksums-Sha256: 6e06e259ae0c468edb994eec63d90d70436382c3ad4f95613f92500521eb41e3 1398 trac_0.11.1-1.dsc 226ecd2826cbfa7c6338688e68b125df33e6d659bd267ec483f8f300837b9638 685841 trac_0.11.1.orig.tar.gz 20fb4bc0f9f4a572e07ce30f4586902ec22f3002ad1bfb9060540b0ff80e6bda 26953 trac_0.11.1-1.diff.gz ee3981b9ca6605670f2127090d5aaee620707f93f2d5f66336c1b10eaf359b8a 536480 trac_0.11.1-1_all.deb Files: 05df4234d960d45ff4e6715f90320d24 1398 web optional trac_0.11.1-1.dsc f7372de0cac1315a6ea9db6ef27b435b 685841 web optional trac_0.11.1.orig.tar.gz 7ed1f52a02583f6a534c7b46677a5f08 26953 web optional trac_0.11.1-1.diff.gz 233de1ebd7ec2e707acf8526fea9e179 536480 web optional trac_0.11.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkid0zwACgkQLqiZQEml+FWGBwCcD2W63MuPxa3v4C7qVL/YwLKb JREAn2ueI8Ke4Q6lOIcdiBlq6QZXvU9G =2Org -END PGP SIGNATURE- Accepted: trac_0.11.1-1.diff.gz to pool/main/t/trac/trac_0.11.1-1.diff.gz trac_0.11.1-1.dsc to pool/main/t/trac/trac_0.11.1-1.dsc trac_0.11.1-1_all.deb to pool/main/t/trac/trac_0.11.1-1_all.deb trac_0.11.1.orig.tar.gz to pool/main/t/trac/trac_0.11.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted trac 0.11-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 21 Jul 2008 21:23:12 +0100 Source: trac Binary: trac Architecture: source all Version: 0.11-3 Distribution: unstable Urgency: low Maintainer: Debian Trac Team [EMAIL PROTECTED] Changed-By: Luis Matos [EMAIL PROTECTED] Description: trac - Enhanced wiki and issue tracking system for software development Closes: 490926 Changes: trac (0.11-3) unstable; urgency=low . * Updated Readme.Debian - Thanks to W. Martin Borgert. Closes: #490926 * added the coderanger's website as trac info source * Removed php-cli and clearsilver from suggests * Upstream prefers psycopg2 for postgresql backend * Removed the jquery.js file, added a dependency for jquery * Updated the watch file since now trac packages start with a T * Added Homepage field in debian/control * Added a suggests on libapache2-mod-wsgi * Added me as Uploader so lintian won't complain about NMU's Checksums-Sha1: d5a0384d6e25b74c740b7dff5ba250646e01dad3 1384 trac_0.11-3.dsc 624c412df18f5c9226cd187dff1c2f48448aa5d0 25692 trac_0.11-3.diff.gz c42ea72005920ce8d8a1542d159911cc7a4258b7 532256 trac_0.11-3_all.deb Checksums-Sha256: a8c38b80c8ccec49e1993ac8ba65123fd523dcf0cd27bf35271ee872ebe552aa 1384 trac_0.11-3.dsc 5f694aeccbe6b33c9d8478983de80c53880c743f32913a8426c9c7d131d02bec 25692 trac_0.11-3.diff.gz 08eef668aff11495e7aa37256b55fc2ab6f69cfd920d3ce7fe797f9ed6975d6e 532256 trac_0.11-3_all.deb Files: 2686c1745a2e4cba357e863034ee8424 1384 web optional trac_0.11-3.dsc 5f891a5878b719bf3b2f627f557d1c9f 25692 web optional trac_0.11-3.diff.gz e37b471d963003999a0bcde4914dee34 532256 web optional trac_0.11-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiE8SkACgkQLqiZQEml+FU7rQCdFdumIgFmVZLlhOnrmo/0mwmF e8AAn1xdwvlA/G3/CrNzNPxRVlP9IHeb =28n7 -END PGP SIGNATURE- Accepted: trac_0.11-3.diff.gz to pool/main/t/trac/trac_0.11-3.diff.gz trac_0.11-3.dsc to pool/main/t/trac/trac_0.11-3.dsc trac_0.11-3_all.deb to pool/main/t/trac/trac_0.11-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted trac 0.11-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 13 Jul 2008 23:46:20 +0100 Source: trac Binary: trac Architecture: source all Version: 0.11-2 Distribution: unstable Urgency: low Maintainer: Debian Trac Team [EMAIL PROTECTED] Changed-By: Luis Matos [EMAIL PROTECTED] Description: trac - Enhanced wiki and issue tracking system for software development Closes: 489727 490275 490320 Changes: trac (0.11-2) unstable; urgency=low . * Re-added python-setup-tools to build dependences. Closes: #490320 #468705 * New upstream release Closes: 489727 * Added sugestion for other vcs support available: git bazaar mercurial * Added spamfilter plugin to sugests * Moved packaging from python-support to python-central * Added an entry to the NEWS about the cgi Closes: #490275 * Updated 10_remove_trac_suffix_from_title patch to be used in 0.11 Checksums-Sha1: 1bf7433a43703e6ccdd547962ca45a0a5b87 1308 trac_0.11-2.dsc 4eef08085e5d5d6cee7179a2e1f7764785c39418 9960 trac_0.11-2.diff.gz 93e75b686115e5fe9928e8bebee0366197b7074e 545982 trac_0.11-2_all.deb Checksums-Sha256: 8108769126b48cbb05789be90f1a52fe03b1a9a35141948e31b52abb4ba46df6 1308 trac_0.11-2.dsc e39d8acb8dbad45c110c02700188166540f45fb41ee1f813e69b7586fbb91dcf 9960 trac_0.11-2.diff.gz dad67abd9682f66c933ecf3bf68c041f4259c8cb434ff120cf298f21261e7cc9 545982 trac_0.11-2_all.deb Files: 00a1b8d70983e77b0bbc83a6b819f360 1308 web optional trac_0.11-2.dsc 6a996ba47084fa4e4758091ecfad38b0 9960 web optional trac_0.11-2.diff.gz 5987d5fb85edc337e8a36ed238614efd 545982 web optional trac_0.11-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh7yNcACgkQLqiZQEml+FVqFQCeJ947DgV1gAXAY+qKPRMZFWCH 880AoKptJqGxKAGahk+znRjhVklY48XP =s+ia -END PGP SIGNATURE- Accepted: trac_0.11-2.diff.gz to pool/main/t/trac/trac_0.11-2.diff.gz trac_0.11-2.dsc to pool/main/t/trac/trac_0.11-2.dsc trac_0.11-2_all.deb to pool/main/t/trac/trac_0.11-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Testing Security team
Nico Golde escreveu: Hi Francesco, * Francesco P. Lovergine [EMAIL PROTECTED] [2007-10-15 16:05]: On Mon, Oct 15, 2007 at 11:20:02AM +0200, Nico Golde wrote: Yes true but in most cases the code base is nearly the same and we can check this without knowing ;) I wonder if in those special cases an Embed: source tag could be added in debian/control to help tracking things. That would be a nice thing, also if this would include information if the code is really included or just statically linked against it. Well, I would consider statically linking a non embedded (i.e. a packaged) library a bug... Are there known cases where this is a required condition? Yes, dpkg for example links statically against libbz2 and zlib just to pick a famous example. Kind regards Nico So ... do as i say, don't do as i do !!! kind regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
backports tool
Hello there ... i had an idea that probably someone already had ... i am using etch and i use anjuta for c/c++ development. i would try anjuta 2.2 because it seems to be a huge improvement over 1.2.4. To do that i have to put the sid sources to sources.list, re-compile some stuff and then install them. the search for the dependencies and download one by one is a complicated and time wasting task. how about the development of tool on we could: - add the sid repos to sources.list - with a simple command download every needed source package (dependencies) - build the packages - install all the packages. examples: apt-backport install anjuta -t sid this would download all needed dependencies from sid, recompile the needed and install all. apt-backport build anjuta -t sid builds the needed dependencies and anjuta is this doable? Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backports tool
Seg, 2007-09-03 às 14:46 +0200, Sebastian Harl escreveu: Hi Luis, On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote: how about the development of tool on we could: - add the sid repos to sources.list This should be done manually, it only has to be done once anyway. of course - with a simple command download every needed source package (dependencies) You would have to do some kind of recursion here to build all required build dependencies in the correct order. This might get pretty bloated, just think of gimp which requires an up to date version of gtk which needs an up to date version of glib... so imagine doing that by hand ... is this doable? Sure, it is (basically anything that can be expressed by some kind of algorithm is doable ;-). However, I think it makes much more sense to take the time (once!) to build a clean backport of the package in testing which can be uploaded to backports.org, so anybody can benefit from it. this is meant for users to use not-in-backports situation, like testing newer software. This tool can also be used to backport some packages. With the possibility of forcing some versions, etc. I am developing some software and i like to test some newer (like anjuta). But, i like too much of having stable system. I know this tool could bring some instability, but it is known. Cheers, Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backports tool
Seg, 2007-09-03 às 09:05 -0400, Roberto C. Sánchez escreveu: On Mon, Sep 03, 2007 at 01:09:14PM +0100, Luis Matos wrote: how about the development of tool on we could: - add the sid repos to sources.list - with a simple command download every needed source package (dependencies) - build the packages - install all the packages. A few caveats: - package names (especially libraries) often change between releases - not all current build-dependencies of the package may be in stable - of the resultant packages, some will conflict with each other true ... Backporting is nearly always better left as a manual endeavour. yes, but having this kind of tool you can limit the building dependencies. See this tool as an simple buildd to instant build a package. Regards, -Roberto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Qua, 2007-08-08 às 20:30 +0200, Hendrik Sattler escreveu: Additionally, it should be noted that a desktop task has nothing with multimedia (means: surprise, you can use a desktop without music and movies). I think we need to have multiple desktop tasks. One desktop-simple, desktop-multimedia-support, etc This would also simplify the use of tasks to enhance the desktop, like desktop-c-gtk-devel, desktop-python-gtk-devel, desktop-php-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Qui, 2007-08-09 às 14:10 +0200, Michael Banck escreveu: On Thu, Aug 09, 2007 at 10:27:40AM +0100, Luis Matos wrote: Qua, 2007-08-08 às 20:30 +0200, Hendrik Sattler escreveu: Additionally, it should be noted that a desktop task has nothing with multimedia (means: surprise, you can use a desktop without music and movies). I think we need to have multiple desktop tasks. One desktop-simple, desktop-multimedia-support, etc This would also simplify the use of tasks to enhance the desktop, like desktop-c-gtk-devel, desktop-python-gtk-devel, desktop-php-devel As long as those are not exposed to the user at installation - fine; for installation, we should have exactly one desktop task per environment, and that should installed whatever is needed to give a rather complete desktop experience, IMHO. i think that beside the expansion of tasks, the after install tasksel should be improved. if we can install a simple desktop and then have some place that the user can access to install more stuff and easily expand it's environment. having a console tasksel is not enough ... someone was developing a gtk+ front end ... right? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Qui, 2007-08-09 às 15:24 -0300, Gustavo Franco escreveu: Btw, desktop-c-gtk-devel and desktop-python-gtk-devel makes no sense, IMHO. It's too specific that we will need desktop-$every_language_in_debian-gtk-devel. What a task like desktop-php-devel will contain, vim? For those who like emacs are we going to add desktop-php-emacs-devel? Please think about needed use cases (ask debian-user, check popcon, ...) and set of packages that should satisfy that, not some cool random task names. this was discussed a long time ago ... i am going to make a proposal. these tasks are useful for inexperienced developers, because not all developers have skills to search for a good IDE for some language. I want to propose sometime during lenny development cycle some developer oriented tasks. something like an apt-get install gnome-devel but ina task sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Qui, 2007-08-09 às 10:42 -0700, Joey Hess escreveu: Luis Matos wrote: having a console tasksel is not enough ... someone was developing a gtk+ front end ... right? DEBIAN_FRONTEND=gnome tasksel ? that's a pretty hack ... why does tasksel does not get the debconf option on which front end to use? ... but anyway, this tasksel ould be improved with some extra options ... i know, however that that's not easy to expand the tasksel because it is based in debconf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what happened to g77-3.4-doc?
Qui, 2007-07-19 às 02:43 -0400, Kamaraju S Kusumanchi escreveu: Hi Can someone tell me what happened to the g77-3.4-doc package? Or better, How can I get a manual page for g77? Why I need this:- I was trying to compile refblas3 package with gfortran instead of g77. reflblas3's debian/rules file uses an option -ff90 which is passed onto g77. I want to know what this option does. However, the lack of manual page for g77 prevents me understand the significance of this option. Can someone help me? I used fortran some while ago ... -ff90 seems to be to the compiler use the fortran90 syntax. fortran is like SQL ... SQL90, SQL92 ... they are the year of the revisions. g77 stands for the 1977 revision. -ff90 stands for the 1990 revision. thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Targeting RPM and Debian from a Debian box?
Sex, 2007-07-06 às 18:47 +0200, Bernd Zeimetz escreveu: Hi, My development workstation is running Debian, and I'd like to produce both .deb and .rpm releases of my software. you can easily use virtual machines like xen and qemu to build and test them. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making in stable or testing
Dom, 2007-06-24 às 17:05 +0200, [EMAIL PROTECTED] escreveu: Hello devolpers, I want devolp packages for debian, must I make it in stable or testing? check your timetable ... do you want to develop your application to start to use in th next two months or 2 years? the first one, develop in stable. the second develop in testing, because by the time you finish, the actual stable will be in shortly replaced, or will already be. Regards, polopolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making in stable or testing
LOL ... i don't know why, i understand that he wanted to develop some application for debian ... well .. i must not be in one of my days! Dom, 2007-06-24 às 18:02 +0200, Guus Sliepen escreveu: On Sun, Jun 24, 2007 at 05:25:29PM +0100, Luis Matos wrote: Dom, 2007-06-24 às 17:05 +0200, [EMAIL PROTECTED] escreveu: Hello devolpers, I want devolp packages for debian, must I make it in stable or testing? check your timetable ... do you want to develop your application to start to use in th next two months or 2 years? the first one, develop in stable. the second develop in testing, because by the time you finish, the actual stable will be in shortly replaced, or will already be. You should develop packages in unstable, never in testing. If you also want people who are currently running stable to use your package, then you can also build the package in stable, but this will not be part of any official Debian repository. You might try to get it in the backports archive though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 20:27 -0400, Felipe Sateler escreveu: Luis Matos wrote: Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu: Installing a newer kernel is not an upgrade, in a sense. You are installing new software alongside the old one. Thus the usual expectations don't hold. the usual expectation that i have with a new kernel is to improve my operating system ... that includes no regressions on supporting my hardware - for example, wifi or graphic card. But it doesn't hold, since you are actually installing a _new_ package, not upgrading an existing. basically that is not true. Imagining moving system like CUT (testing) you must predict these issues. It is a New package, but one that can make the system unusable (or parts of it). PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. what about checking the *-modules-2.6.A packages available and compare them with the previous version? That would live everyone waiting for the every module to be ready, of which they may not be using some. true ... and if unstable has a low priority than testing, users ould fetch that from unstable easily. But, if testing is *always* usable, then it has to be that way. if the count of both are equal, then kernel *and* modules can go into testing. If, for some reason a module is not available or cannot migrate into testing, kernel would not migrate. Note that independent of wether modules are in testing or not, upgrading a kernel *won't* install the modules (out of tree modules, that is). You still have to install them by hand. That is what I was referring to. not true. there are meta pckages that do that for me. kernel has linux-image-2.6-k8 (for example), modules have name-module-2.6-k8 . when an new kernel is uploaded, it is upgrade because there is a new meta package. the same way, if there is new module meta package, then, the modules will be upgraded. the problem here is that the kernel meta package is upgraded *but* because there is no modules meta package, those are not upgraded. I think i am not mistaken. -- Felipe Sateler Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 17:49 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 05:32:01PM +0100, Luis Matos wrote: Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? Some packages are allowed to pass into testing even if other depends on it, but has issues that will take some time to resolve. This will make that that package, that is now in testing, will not be installable in anyway. This happens sometimes. Well, tough. Take it up with the maintainers who don't coordinate their uploads to unstable with the maintainers of related packages. The release team only breaks packages in testing when we *have* to do so to move the release forward (meaning, a net reduction in RC problems). i am not blaming the Release Team --- for real. I just want that automatic passages from unstable for testing, when debian is not in a pre-stable-release state have more verifications such as reverse depends. That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. No. The nvidia kernel packages are a particular case where the module packages were willfully broken in testing by the release team because of long-outstanding RC bugs in related nvidia packages. Again, this was a necessary trade-off which reduced the overall number of release-critical problems in testing. i am generally speaking ... the nvidia package was an example that occurred to me (and i stop using it since then). Other problems like that happened to me. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. true. nvidia-kernel (meta packge) depends on linux-image-2.6.10. a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did not pass because it is too young. You either don't know how testing works, or you don't know how the Debian kernel packages are structured. I think i know (i let the space open for the uncertain). And the kernel packages was an example on how things can be broken in testing and give ideas to prevent them to have CUT (Constantly Usable Testing). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 13:08 +0200, Emanuele Rocca escreveu: * Luis Matos [EMAIL PROTECTED], [2007-06-14 1:14 +0100]: Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu: Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. this makes the snapshots just like the current ones (i think cd sets are built weekly r monthly, can anyone confirm this?) They're built weekly, see http://www.debian.org/devel/debian-installer/ I don't think that we should release a snapshot of CUT each and every month. i fully agree ... My suggestion was just to use months rather than numbers to refer to CUT snapshots, but keeping the when it's ready philosophy and all the other points of Joey's proposal: http://kitenet.net/~joey/code/debian/cut/ agreed. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 19:18 +0200, Josselin Mouette escreveu: Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit : I just want that automatic passages from unstable for testing, when debian is not in a pre-stable-release state have more verifications such as reverse depends. I really don't understand what checks you want to add over those already being done. I just want to ensure that *ALL* the necessary checks are made when a package steps into testing so that the package that passes don't break anything. I presented here the kernel and kernel modules case, but some other already happened to me (that cases that we just ... don't upgrade and forget). I also would like to have testing *Oficial* snapshots as demonstration of debian's current state, testing being promoted as bleeding edge system for home/power users and CUT. Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 20:10 +0200, Martijn van Oosterhout escreveu: I explicitly check to see if there's a kernel upgrade and abort if that's the case, as I do not have the time to sort out the mess before the next reboot. Ideally, it could just install, without having it automatically used next time. Then, when I have time and everything is right, then the bootloader uses the new kernel. i don't think this is a reliable situation. At first look, a new package version is better than it's last. If the kernel breaks at boot, the bootloader allows you to boot with the old kernel as _special_ option. -- Luis Matos [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 14:40 -0700, Steve Langasek escreveu: It's an example that does not support your thesis. I have explained to you that packages are *not* propagated automatically to testing when they break the installability of other packages present in testing; that the nvidia modules packages include metapackages designed to keep the modules in sync with the kernel; and that the nvidia modules were specifically broken *by the release team* during the etch release because this was the lesser evil. You insist that there need to be more automatic checks for testing, but you haven't identified any checks that aren't already in place. yes, i failed to show an existing situation ... i no longer use testing. I know how the passage is done. dependencies are checked. But, i had issues in the past (etch testing cycle). Since Gustvo raised the testing problems, i thought i should gave my word has *testing* user. You grabbed the nvidia problem ... that was just one. Other was with xorg and xbase-clients (a newer version of xbase-clients[0] was needed), when the xorg 7.0 x11-common package entered testing. xorg 7.0 (or 6.9 ... i don't remember) dropped the use of the symlink to /usr/X11/bin (or other place, i can't remember) ... i even opened a bug [1] (which i closed a few weeks ago - this was the 6.x to 6.9 transition). i just want to say that things like these can't happen ... (in this case, reverse dependencies where ok ... by the way). [0] http://packages.debian.org/unstable/x11/xbase-clients [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370370 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Ter, 2007-06-12 às 17:03 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu: Personally I think the current system is fine. just a note, as user: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) You won't find a contractual guarantee from Debian about either of these things, for *any* of the Debian suites. look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). - There are no public, announced, snapshots from testing (so people can download and install). Other than the d-i betas? yes ... for example, every 6 months ... all teams can organize to ship a preview release of debian. Teams will know that day X at Y time full set of cd's will be built. so teams will have +/- stable packages in testing and debian will have an automatic version. d-i per se is not a debian release. This will give users another view of debian. For example, debian lenny preview A would be announced and people would install it and test it. Otherwise, no one will use it. - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. (... and this is why getting rid of experimental is a horrible idea.) i think we cannot give up of experimental ... it's a place for ... experimental packages and preview packages (samba 4, for example), - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) raises hand you lucky person. :) - kernel modules simply die, when the kernel is upgraded, but the modules aren't ( people using non-free nvidia modules, raise their hands; people using wifi modules raise their hands) That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. And, just a note ... we are talking about testing, not stable. So ... automatically pass to testing ... is bad. Invalid premise - invalid conclusion. it's not invalid ... it's valid by the reasons above. So ... more package tests are need (such as test reverse depends) What do you mean? i mean that the passage f packages from unstable to testing needs to be more difficult. for example, if a package has, for example, important or serious bugs, should not pass to testing,even if it has security issues ... because it will break testing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 03:45 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. You are never going to get a statement from the Debian project telling users to use one suite or another (or at least, you shouldn't); the most we should be doing is giving users a list of pros and cons for each suite and letting them decide which fits their needs. I'm all in favor of reducing the number of decisions users have to make *in the software* :), but on something as high-level as which distro/suite to use, misestimating a user's needs is the kind of thing that will sour the user on Debian for a very long time. Yes, but debian *only* publicites the use of stable (that home users or desktop users tag as stale). If you publicity say that testing (or maybe this should be renamed :( ) is the way for an up-to-date, latest software distribution , then they will use it. for now it only states that testing is ... testing, right? There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). More strict upload rules for what? To have security updates in testing, easily and stable ... not to upgrade a new version into testing that can break stuff, or some mixed unstable and testing upload. - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? Some packages are allowed to pass into testing even if other depends on it, but has issues that will take some time to resolve. This will make that that package, that is now in testing, will not be installable in anyway. This happens sometimes. That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. true. nvidia-kernel (meta packge) depends on linux-image-2.6.10. a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did not pass because it is too young. nvidia-kernel is unusable. Or the user reboots with the new kernel, or edits by hand the xorg.conf . I used testing since about 3 months after sarge was released ... it was quite stable, but some transitions broke my system and it should not happen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 12:39 +0200, Gabor Gombas escreveu: On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. Then create an empty nvidia-module package that depends on the latest nvidia-module-X.Y.Z package and conflicts with linux-image-$ARCH X.Y.Z. Just because you're using non-free kernel modules does not mean that everyone else _not_ using those modules should be penalized. but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. you had the example with nvidia modules, what about wifi modules ... what about ... camera modules (i think they are all in the same source package now). They all BREAK in this case. How many of debian developers and contributors use these modules? Or alternatively, just reboot with the old kernel just like you'd do when you found out that any random driver you happen depend on stops working in the new kernel version. that is an *extreme* situation ... when there is BUG in the software ... not just because some package entered testing and broke your system. Gabor cheers, Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... if ... *if* i had used module-assistant to use nvidia graphics (or camera modules, or wifi, or what else), i would not mind to do that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... If you're using non-free drivers, the first part of your sentence above doesn't apply. I agree ... so what about the linux-modules-contrib-2.6 source package? Usually, however, those non-free drivers that are built for each kernel get built before the new kernel migrates to testing, but given that those builds can't be handled by the general mechanism for building add-on modules, I don't think the currency of those builds can be guaranteed. agreed. My recommendation is to always use module-assistant for all non-free drivers that you want to use. That way, if there is a build in non-free, you can be pleasantly surprised, but your normal method will always work. i don't think that this is useful in a debian way. That is equal to tell the maintainer to stop his work. Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. i hope so. i want to tell a couple of things: 1. My critic goes for the automatic passage of packages that make other packages (already available in testing) uninstallable or conflictive. In these 2 sets are packages that have reverse depends and, for example, the kernel. 2. You, like other, confirm this situation, but for some reason, you just don't explicit agree with it. 3. My main objective is to turn testing an *REAL* alternative for stable. I've used testing (now i am running stable). It's quite stable, but some upgrades break stuff. This breakage should not happen and packages that cause breakage should not pass into testing. 4. Making testing more visible as a bleeding edge (+/-) *stable* distribution would be a nice thing and people would appreciate. Making snapshots (full cd sets called previews, for one example) would make it visible and useful. Users with testing (commonly home or power users) can see it's system evolute, while it remains stable, usable and bleeding edge (stability would be preferred over bleeding edge). 5. CUT is *THE* option for testing that would permit this. just my thoughts. Luis Matos -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu: Luis Matos wrote: Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... Installing a newer kernel is not an upgrade, in a sense. You are installing new software alongside the old one. Thus the usual expectations don't hold. the usual expectation that i have with a new kernel is to improve my operating system ... that includes no regressions on supporting my hardware - for example, wifi or graphic card. PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. what about checking the *-modules-2.6.A packages available and compare them with the previous version? if the count of both are equal, then kernel *and* modules can go into testing. If, for some reason a module is not available or cannot migrate into testing, kernel would not migrate. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu: * Joey Hess [EMAIL PROTECTED], [2007-06-11 19:56 -0400]: Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ Snapshots should be made available regularly, so that users who need a firm foundation for deployment have one. They'd be numbered, so we could call them cut 4, cut 5, etc. Each would be a snapshot of testing at a point when it was in especially good shape. Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. this makes the snapshots just like the current ones (i think cd sets are built weekly r monthly, can anyone confirm this?) I realize that 'freezing' testing when it is in good shape we adhere to the when it's ready philosophy, but can you think of a rough estimate about how often it could happen? think about transitions .. let's get etch release cycle example. i think 2 or 3 snapshots would be good. (not time ordered) 1. transition to xorg 2. new gnome version 3. new kde version 4. new gcc version these are quite predictable, and i think the main objective is not FULL stability, but to have a work base. So, if we predict that in the next month a big transition will be made, then, a snapshot will be made with the transition objectives. When they are accomplished, debian would ship a snapshot. By scheduling the snapshot, other maintainers can upload their new packages that will be included in the snapshot. remind you that if packages only pass to testing *ready for stable* (more or less) any snapshot would be quite stable and usable (+/- like an ubuntu release - this was a bad joke). Having this *release* would make people to use more debian. Of course the system would be continuously updated. ciao, ema best regards, Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 16:18 -0700, Russ Allbery escreveu: For non-free, this is inevitable without significant changes to the way that Debian works that I don't believe will happen. Debian has provided a different solution in the form of module-assistant that in my experience works great. I recommend that you learn how to use it rather than tilting at windmills. this is not a discussion on how to support non-free drivers ... module-assistant is not an answer to the modules-contrib and modules-extra (at least). (i have used module-assistant and i think is a great tool) the problem here (that happened to me with other packages) is that some packages with reverse dependencies passed into testing making other packages uninstalable. kernel and modules is just one problem. my point here is that i think the current structure is ok, but ... the passage to testing has to be done with more care (care it already has). i am not whining about the use of nvidia non-free drivers ... i am whining about have a good CUT and *THAT* requires the paragraph before. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 19:20 -0400, David Nusinow escreveu: By the time it hit testing it worked pretty well for most people. We broke a few things, but it was nice for just about everyone. Everyone except those people using proprietary drivers, but they know they've already dug their own grave there. If Luis wants to keep whining about it, I suggest he talk to nvidia. lol ... the passage from xorg 6 to 7 was a big passage ... i had some uninstalable packges (not nvidia related), i even opened a bug[0], that i closed some weeks ago when i reviewed the bugs i've submitted. this is one example about the problem i am trying to get attention to. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370370 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu: Personally I think the current system is fine. just a note, as user: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) - There are no public, announced, snapshots from testing (so people can download and install). - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Package conflicts, etc, etc. (i used etch when it was testing since almost sarge's release). - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) - kernel modules simply die, when the kernel is upgraded, but the modules aren't ( people using non-free nvidia modules, raise their hands; people using wifi modules raise their hands) ... ... So ... automatically pass to testing ... is bad. So ... more package tests are need (such as test reverse depends) Then, announce snapshots and that testing is (+/-) STABLE, USABLE and SECURE, presenting users with a clear message in debian's site. best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Ter, 2007-06-12 às 23:32 +0200, Vince HK escreveu:
Lucas Nussbaum wrote:
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
NO!
unstable is meant for packages that should be in the next stable release,
as such only packages that are in the maintainer's opinion ready to
migrate
to testing should be uploaded to unstable.
Then shouldn't we have a more aggressive policy about removals from
unstable, for packages that have failed to get into testing during the
past n months ?
Actually, I support that. What about a push from unstable to
experimental when a package fails to behave ? (given reasonable amount
of time and notice, of course).
Also providing apt with an option like apt-get install --reinstall
{oldstable, stable, testing, unstable} would be nice.
experimenting packages from experimental would be easy, and reverting
those test would be also.
This way, I tend to believe more people would have their eyes on
experimental, and that might solve some of the problems adressed in this
thread.
Regards,
Vincent
--
Vincent Fourmond, Debian Developer
http://vincent.fourmond.neuf.fr/
-- pretty boring signature, isn't it ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Sex, 2007-06-08 às 09:58 +0200, Francesco P. Lovergine escreveu: On Thu, Jun 07, 2007 at 09:24:48AM +0200, Stefano Zacchiroli wrote: On Thu, Jun 07, 2007 at 12:59:38AM +0200, Michael Vogt wrote: The big new stuff is: - support for unattended installing security upgrades (via the unattended-upgrades package and the apt cronjob) This sounds juicy, assuming it matches what I've in mind; where can I find more info on this new feature? It looks also very dangerous :) There are a lot of server (mostly in Small business) that would benefit a *lot* from this. i have 2 servers that i only login for apt-get update apt-get upgrade -y, they are running sarge (yet) and only install security upgrades. These 2 server will not be put in danger by making the update upgrade in an autonomous way. one good feature would be (i don't know if it's included) an option to mail the sysadmin when a new kernel is installed. Because reboot cannot be automated ... or let the sysadmin install only the kernel manually (or have an option do that) but inform the sysadmin mail command is our friend) for the existence of new kernel.. -- Francesco P. Lovergine ps: DD's and debian contributers ... if i had not said this before, You're Cool. (ok, i'm cool too). best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Sex, 2007-06-08 às 06:21 -0400, Roberto C. Sánchez escreveu: On Fri, Jun 08, 2007 at 11:36:57AM +0100, Luis Matos wrote: Sex, 2007-06-08 às 09:58 +0200, Francesco P. Lovergine escreveu: On Thu, Jun 07, 2007 at 09:24:48AM +0200, Stefano Zacchiroli wrote: On Thu, Jun 07, 2007 at 12:59:38AM +0200, Michael Vogt wrote: The big new stuff is: - support for unattended installing security upgrades (via the unattended-upgrades package and the apt cronjob) This sounds juicy, assuming it matches what I've in mind; where can I find more info on this new feature? It looks also very dangerous :) There are a lot of server (mostly in Small business) that would benefit a *lot* from this. i have 2 servers that i only login for apt-get update apt-get upgrade -y, they are running sarge (yet) and only install security upgrades. These 2 server will not be put in danger by making the update upgrade in an autonomous way. one good feature would be (i don't know if it's included) an option to mail the sysadmin when a new kernel is installed. Because reboot cannot be automated ... or let the sysadmin install only the kernel manually (or have an option do that) but inform the sysadmin mail command is our friend) for the existence of new kernel.. How is what you describe different from what cron-apt already does? the ability to REAL integration with apt and extend it's options ... i consider it like ... the next cron-apt stage (integration in apt). Regards, -Roberto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Sex, 2007-06-08 às 13:01 +0200, Gabor Gombas escreveu: On Fri, Jun 08, 2007 at 11:36:57AM +0100, Luis Matos wrote: i have 2 servers that i only login for apt-get update apt-get upgrade -y, they are running sarge (yet) and only install security upgrades. These 2 server will not be put in danger by making the update upgrade in an autonomous way. IIRC a security update in sarge changed sudo's behaviour and that broke many local scripts. We decided that the security threat addressed by the update was basically zero and went back to the old version - finding fixing all the broken scripts was simply not worth the effort. So an automatic security update _can_ break a working server. as i said ... in many cases it wont ... in those servers i run samba/ftp/http . backup script is ordered by the user. simple pages in /var/www and user's home. one is also a mail server with no backup. Gabor here ... update upgrade would not break anything ... and the changes are easy to revert (install older packages, pin them and wait for the bug to be fixed). We (admins) allways hope that the behaviour of the packages don't change, that's why we all use debian. Still, things can happen. I must remember you that is is a small business server. less than 10 posts. Imagine a person that has 10 clients like this? of course that the upgrade time must be set ... imagine all 10 break at the same time :P in resume, i think you are right ... but not all situations require such a right handling. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Large static datasets like genomes (Re: Reasonable maximum package size ?)
Frank Küster escreveu: Santiago Vila [EMAIL PROTECTED] wrote: On Wed, 6 Jun 2007, Tim Cutts wrote: (aside: I'd love it if we could have some sort of user package system which could allow non-root users to install software packages in areas they have access to, and yet have full dependency checking on the main system packages) dpkg --admindir=$HOME/somedirectory should allow that (should in the sense that if it does not work, we should consider it as a bug, not in the sense that I may have tried it recently). I don't think so - you missed the and yet have full dependency checking on the main system packages part, didn't you? Regards, Frank can we have a per packge permission set??? kind of users can update package X and Y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
Frans Pop wrote: On Tuesday 05 June 2007 15:14, Anthony Towns wrote: I'm not sure if avoiding duplicating the data (1G of data is bad, but 1G of the same data in a .orig.tar.gz _and_ a .deb is absurd) is enough to just use the existing archive and mirror network, or if it'd still be worth setting up a separate apt-able archive under debian.org somewhere for _really_ big data. IMO it would be worth it if we could split out gigabytes of data from the main archive and thus significantly reduce the bandwidth needed for mirror syncs. Especially if that data is only used by an extremely small subset of users/developers. The advantages would be: - overall reduced use of resources like disk space and bandwidth - lower the barrier to create local mirrors, not only for home users, but also for mirrors in areas that are not that well connected to the rest of the world [1] - make it possible to not include such data on the regular binary CDs, but for example on separate arch-independent data CDs Debian 15 cd's, 2 dvd + 1 DVD human genome + 2 DVD games + 2 DVD other data :P this would be really fun ... and i agree with this ... LOL. also, i agree with dividing the main package in smaller packages (pkg-1 + pkg-2 = PKG) also ajt really touched a point: orig.tar.gz would also be hudge. So, maybe introducing some kind of packaging that would forget the orig.tar.gz would be nice. dividing the data separed like main/contrib/non-free/DATA/DATA-non-free/DATA-contrib would be good. A few faster mirrors could support the few users that need this kind of packages. It is likely that this issue will only become bigger with time, so investing in a structural solution IMO makes sense. makes all sense. Cheers, FJP [1] This was for example a real problem when I was in Bhutan last year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Web design [Was: Wanted: introductory page for all teams]
maybe you can use the debianart.org platform. Dom, 2007-05-27 às 09:30 -0400, Kevin Mark escreveu: On Sun, May 27, 2007 at 11:35:26AM +0200, Andreas Tille wrote: On Sun, 27 May 2007, Frans Pop wrote: Yes, a complete redesign of the website is a herculean task, but contributing to specific pages or parts is trivial. OTOH, I expect that for a webdesign professional even a redesign would be quite manageable as AFAICT the technical structure of the website is not all that complicated. What about a web design contest. Once we had a not really appealing logo and solved this problem via a logo contest. I remember other projects that did a contest for a good web design. Perhaps we might solve a problem that no DD really wants to solve himself? Kind regards I was pondering a few ideas: a) create a website mockup designs gallery where folks could submit screenshots of their designs b) create a mockup site where folks can use a copy of the website data with an apache instance and use that to display new design ideas so that the main site is not touched. maybe mockup.debian.net/~design1, mockup.debian.net/~design2, etc. virtual machines or virtual hosts? I percieve a lot of negative energy when random non-DD folks ask about helping out with a website re-design and that leads to folks 'heading for the exits'. If there was a place for folks to try stuff without messing with the actual infrastrure, it would allow folks to 'go crazy' with new and creative ideas with the benefit for DD's to feel 'safe' about not distroying 'important links' that users need and wouldn't lead to a revolt requring a GR. Any attempt that leads to a unilateral, perminent design change makes DD's go bonkers, or so it seems. So a mockup site would allow folks to see, comment and get used to a new design and build consesus without needing a GR. [funny how GR almost sounds like 'G' -- the sound of an angry DD ;-)] -K -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted trac 0.10.4-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 20 May 2007 22:46:56 +0100 Source: trac Binary: trac Architecture: source all Version: 0.10.4-1 Distribution: unstable Urgency: low Maintainer: Jesus Climent [EMAIL PROTECTED] Changed-By: Luis Matos [EMAIL PROTECTED] Description: trac - Enhanced wiki and issue tracking system for software development Closes: 414134 420219 422409 Changes: trac (0.10.4-1) unstable; urgency=low . * New upstream release (Closes: #414134, #420219) * Fixed typo in debian/copyright file (Closes: #422409) Files: 4e5ead21be4462caf9057acfc1a56dab 714 web optional trac_0.10.4-1.dsc 52a3a21ad9faafc3b59cbeb87d5a69d2 449116 web optional trac_0.10.4.orig.tar.gz 2009747a16096be31dc3555c7da8a68a 8793 web optional trac_0.10.4-1.diff.gz da54e1801833494d78b7562c8ad29e59 386598 web optional trac_0.10.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGVFSfLqiZQEml+FURAiTXAJ9iq0VERRu2aDuG4bpUJz0U3+1NyACeKNxi c9lGd396BhnGaOsW4ghXj78= =BW5B -END PGP SIGNATURE- Accepted: trac_0.10.4-1.diff.gz to pool/main/t/trac/trac_0.10.4-1.diff.gz trac_0.10.4-1.dsc to pool/main/t/trac/trac_0.10.4-1.dsc trac_0.10.4-1_all.deb to pool/main/t/trac/trac_0.10.4-1_all.deb trac_0.10.4.orig.tar.gz to pool/main/t/trac/trac_0.10.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#424875: ITP: libical0 -- libical offers parsing of ical text data.
typo: http://freeassociation.sourceforge.net/ two s's in association. Qui, 2007-05-17 às 17:03 +0200, Michal Čihař escreveu: Hi I wanted to find out more about this library, but... On Thu, 17 May 2007 16:27:31 +0200 Wilfried Goesgens [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Wilfried Goesgens [EMAIL PROTECTED] * Package name: libical0 Version : 0.27.1 Upstream Author : Art Cancro [EMAIL PROTECTED] * URL : http://freeasociation.sf.net An error has been encountered in accessing this page. 1. Server: freeasociation.sourceforge.net 2. URL path: / 3. Error notes: File does not exist: /home/groups/f/fr/freeasociation/htdocs/ 4. Error type: 404 5. Request method: GET 6. Request query string: 7. Time: 2007-05-17 08:02:07 PDT (1179414127) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how long is 'pending'
Frank Küster escreveu: Neil Williams [EMAIL PROTECTED] wrote: How long should bugs be tagged pending in advance of an upload? Is it acceptable to tag a bug pending when fixed upstream and the maintainer is confident of an upstream release in under a week? (This is easy for me, I'm also upstream in many cases. :-)) Does it depend on the severity of the bug? Does it depend on the priority of the package? (or the popcon score?) Does it depend on how many bugs are tagged pending for that package? Should the bug be tagged pending as soon as it has been fixed with a local test package, no matter what? I use pending to indicate fix found, tested, committed to the repository. This means there's no need for anyone to work on it. Whether the upload should be done ASAP or in the next couple of weeks depends on the severity of the bug. As basically a user and not a developper, when i found a tag pending i expect: - the bug is confirmed - there is a fix - the fix is going to be in the next upload. - next upload can take anykind of time ( time is not a friend of debian, as we all know) Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Seg, 2007-05-14 às 17:03 +0200, Petter Reinholdtsen escreveu: Interesting analysis, with several good points on keeping the stable release working with newer hardware and keeping the software selection relevant. But my first impression after reading your long text is that you are ignoring the work going on at backports.org, and the ideas that has been floating around on making a Debian release based on the stable version for the base packages, and include upgraded packages like the kernel, X, Gnome, KDE and other hardware- and user-interacting packages from backports.org. You might want to have a look into those ideas. One good point would be to include tested backports into stable release cycle. I don't mean base backports, but mainly user interfaces and so on. i'll give one simple example: - with network-manager-gnome, every time i connect to a radius network i have to put username, password and certificate. A newer version now saves this info. do i have to spend 2 years (at least) doing so to have a debian stable distribution? I've also seen ideas on making releases based on testing, now that we have security fixes for the packages in testing. It could give a snapshot of internally consistent packages (as opposed to unstable). There are people that use testing. In my work computer i only upgrade from stable to testing more or less at 3/4 of stable's release cycle. i don't think this is a way out ... maybe a better one is the one stated above. best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announce: DebianArt.org
Dom, 2007-05-13 às 00:43 +0200, Tim Dijkstra escreveu: On Wed, 9 May 2007 17:49:18 -0300 André Luiz Rodrigues Ferreira [EMAIL PROTECTED] wrote: Hi all, The user can put the follows categories: - Wallpaper - Splash screen - Icon - System sound - Logo - Usplash - T-shirt - Screenshot - Generic What do you think? We think this is one of the available ways for a best desktop It would be nice if someone could make some nice splash themes for splashy;) It supports different splash screens during boot, shutdown, hibernate and resume. wasn't these made before etch? based on the more-blue theme? in releated note, andre are you available to update debian more-blue's splsh screen into something more round, like the login screen (and whitier)? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422137: ITP: 09F911029D74E35BD84156C5635688C0 -- l33t h4x0r numb3r
oh ... dot com is already taken... http://09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63.com/ best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installation Desktop Option.
Qui, 2007-04-26 às 19:37 +0930, Stef Daniels escreveu: Hi again, On 26/04/07, Luis Matos [EMAIL PROTECTED] wrote: i think you should read the 'fine' instalation manual where it says that you can select the desktop at boot prompt Yes the doc's are great and well done, however, the install methods making it more streamline with choices, or are we wanting an install in 3 clicks or under? yes but the installer only hs options for the ones that are possible in the first cd ( the full first cd). This is going to change, i believe, in tasksel for lenny, with information about what is on the cd and what you have to download. I 'personally' feel as part of the installation process, the clear option of which Desktop Manager you would like (something similar to what SUSE has). With perhaps making it part of the GTK Debian Installer. I am aware of the boot options, the various selections and ways to get around gnome to kde, however, I feel that we can achieve in making something better, why not try it Or see what people think. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installation Desktop Option.
Qui, 2007-04-26 às 04:02 +0930, Stef Daniels escreveu: Hi Greg and others, On 26/04/07, Greg Folkert [EMAIL PROTECTED] wrote: Like these: http://cdimage.debian.org/debian-cd/4.0_r0/i386/iso-cd/debian-40r0-i386-kde-CD-1.iso http://cdimage.debian.org/debian-cd/4.0_r0/i386/iso-cd/debian-40r0-i386-xfce-CD-1.iso Yes there are these options.. Or something different? Suppose as a 'net-install' or 'businesscard' install with regards to install. as apposed to specific images of Debian for download. -- greg, [EMAIL PROTECTED] i think you should read the 'fine' instalation manual where it says that you can select the desktop at boot prompt -- Regards, Stef (VK5HSX) Amateur Radio StationEmail: [EMAIL PROTECTED] Adelaide, Sth AustraliaAX25: [EMAIL PROTECTED] Debian GNU\Linux User(www.au.debian.org) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: spam from bugs.debian.org
Qua, 2007-04-25 às 13:50 -0500, David Moreno Garza escreveu: Steve Greenland wrote: I'd guess that Bugzilla's mandatory registration is why. OTOH, Bugzilla's mandatory is why I rarely report bugs for projects that use Bugzilla. I don't think making it harder for users to report problems is a good trade-off. I totally agree on this. The easier we get our users to report bugs, the hardest we get releases 0:-) So let's put a better filter in bugs.d.o for it to randomly reject 50% of the accepted emails. Maybe b.d.o can block the people that send RC bugs ... those persons are rude ... send RC bugs elsewhere and don't spam BTS. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ Una vida sencilla para nada es aburrida. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installation Desktop Option.
Qua, 2007-04-25 às 13:53 -0500, David Moreno Garza escreveu: That's why the Debian CD team provides Kebian and Xebian for you :-) calling them like this would make kde people and xfce people to look more to debian ... or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a new CDD sub-project: Debian4Business
Ter, 2007-04-24 às 16:44 +0200, Michelle Konzack escreveu: Hello Arjan and *, Am 2007-04-18 15:24:36, schrieb [EMAIL PROTECTED]: I would like to start a new sub-project called Debian4Business or perhaps Debian-Office.I have a slight preference for the first name, but this is discussable of course. I am open... I have a small company, that provides legal services. About 6 months ago (I use linux for more than 8 years already) all desktops are running Linux now. The people using those desktops have no prior linux experience. I have tried several distributions, but with every distribution I see problems appear with the people that use it. These problem appear because no distribution is really focused on business use within small and mid-sized companies. I am Debian GNU/Linux Consultant in Strasbourg/Frace and using my own CDD for my cusomers which is a BUSINESS equivalent for Skolelinux debian-edu. My CD provides ALL packages for the installation of Office-Workstations and required server (postgresql, apache, nfs, samba, cups, courier...) Of course there are some distro's with exactly this goal, however they are usually commercial products/forks. Probably all very good distro's but also awfully expensive, and that makes them not very interesting for small- and mid-sized companies. FullACK I believe there is definetely a 'market' for a business oriented linux based on open source/GPL/Debian social-contract, maintained for and by it's users instead of a commercial base. The open source/GPL/DSC concept works for individuals, so why it wouldn't/couldn't work for businesses? 2800 installations in region Strasbourg(FR), Colmar(FR), Mulhouse(FR), Kehl(DE) Offenburg(DE), Lahr(DE) and Freiburg(DE) give me a ... :-) My goal with this project is to create a CDD that provides it's users with the tools they need to easily install and use the things a small and mid-sized business needs in their working environment. This goes for both server and desktop tasks. A small and mid-sized company often doesn't have a permanent system manager, that's exactly why things have to be simple. Of course it should also include the common office tools, like an office package (openoffice), email, groupware, etc etc. This would be definitivly a business clone of Skolelinux. yes. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a new CDD sub-project: Debian4Business
Ter, 2007-04-24 às 16:44 +0200, Michelle Konzack escreveu: Hello Arjan and *, Am 2007-04-18 15:24:36, schrieb [EMAIL PROTECTED]: I would like to start a new sub-project called Debian4Business or perhaps Debian-Office.I have a slight preference for the first name, but this is discussable of course. I am open... I have a small company, that provides legal services. About 6 months ago (I use linux for more than 8 years already) all desktops are running Linux now. The people using those desktops have no prior linux experience. I have tried several distributions, but with every distribution I see problems appear with the people that use it. These problem appear because no distribution is really focused on business use within small and mid-sized companies. I am Debian GNU/Linux Consultant in Strasbourg/Frace and using my own CDD for my cusomers which is a BUSINESS equivalent for Skolelinux debian-edu. My CD provides ALL packages for the installation of Office-Workstations and required server (postgresql, apache, nfs, samba, cups, courier...) humm ... would you like to share? Of course there are some distro's with exactly this goal, however they are usually commercial products/forks. Probably all very good distro's but also awfully expensive, and that makes them not very interesting for small- and mid-sized companies. FullACK I believe there is definetely a 'market' for a business oriented linux based on open source/GPL/Debian social-contract, maintained for and by it's users instead of a commercial base. The open source/GPL/DSC concept works for individuals, so why it wouldn't/couldn't work for businesses? 2800 installations in region Strasbourg(FR), Colmar(FR), Mulhouse(FR), Kehl(DE) Offenburg(DE), Lahr(DE) and Freiburg(DE) give me a ... :-) My goal with this project is to create a CDD that provides it's users with the tools they need to easily install and use the things a small and mid-sized business needs in their working environment. This goes for both server and desktop tasks. A small and mid-sized company often doesn't have a permanent system manager, that's exactly why things have to be simple. Of course it should also include the common office tools, like an office package (openoffice), email, groupware, etc etc. This would be definitivly a business clone of Skolelinux. yes. as i can see, skolelinux has many of this. Maybe some generalization of some features for both use and then special features for the business one would be nice. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a new CDD sub-project: Debian4Business
cc'ing debian-custom so we can get off devel. Qua, 2007-04-18 às 22:34 +0200, Andreas Tille escreveu: On Wed, 18 Apr 2007, Luis Matos wrote: A cdd would be good for some first testing, but having it included in debian would be great. Argh - the usual missunderstanding: If you use the term Custom Debian Distribution your first Google hit gives the definition: Custom Debian Distribution (CDD): a subset of Debian that is configured to support a particular target group out-of-the-box. So having it included in Debian is solved by definition - and this would be the right thing to do. The mailing list that is relevant for this [EMAIL PROTECTED] it true it's debian, but ... i meant in debian's main (general) distribution, that is, as option in tasksel and not only as meta-package ... but there is no problem. Maybe an tasksel interface for included cdds would be nice :) If you ask me you should read [1] and [2] and finally come up with a proposal on the debian-custom list. I really like your idea. well ... one more to help then :P Kind regards Andreas. [1] http://wiki.debian.org/CustomDebian [2] http://people.debian.org/~tille/cdd PS: I really hate that people were able to convince me to agree to the name Custom Debian Distributions for the thingy that was called Debian Internal Projects because it is so terribly missleading that nobody becomes an idea what we really mean by this term. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a new CDD sub-project: Debian4Business
Maybe some kind of proposal to change tsksels behaviour to warn user that the option he has choosen requires more cd's or download of files trought network. tasksel is a good tool, but it really lacks expansibility ... mainly because it was not made with that purpose. At least, we could preseed some options, (like debian-med) but that wouldn't come in tasksel's options, like kde-desktop and xfce-desktop. Qui, 2007-04-19 às 13:31 +0200, Andreas Tille escreveu: On Thu, 19 Apr 2007, Luis Matos wrote: it true it's debian, but ... i meant in debian's main (general) distribution, that is, as option in tasksel and not only as meta-package ... but there is no problem. Well, there is definitely more in Debian than you can select via tasksel. ;-)) But your argument has a point and there was a time when I tried to get Debian-Med included into tasksel (see bug #186085). Maybe an tasksel interface for included cdds would be nice :) Some suggestions how to enhance tasksel are given in http://people.debian.org/~tille/cdd/ch-todo.en.html#s-visibility Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TaskSel proposal (Was: Proposal for a new CDD sub-project: Debian4Business)
Frans Pop escreveu: On Thursday 19 April 2007 14:46, Andreas Tille wrote: IMHO the best solution would be if tasksel would have a two level selection: I doubt this is going to happen in the in tasksel. For one thing, its maintainer has quite strong feelings against it. For another thing, a two-level selection is not that easy to implement using the debconf protocol; and you _have_ to use the debconf protocol for integration with the installer. The only way to implement something two-level currently is the way it was done for the list of all countries in D-I. Note that the presentation for that was changed to a collapsible list in the graphical frontend. grabbing from here: 1 - i would want that cdd's where instalable trought tasksel. 2 - 2 layer tasks are impossible. Ok. We can live with it. 3 - there are tasks that are only activated trough preseeding. CDDs should have this option. Also, can we arrange some kind of cdds-pre-selection in d-i? One page fter tasksel that would have the cdds listed, or previously. Or at least an yes/no question, do you want to install any CDD? this would make one bad thing. apt would download packages 2 times, but i think that is not that bd. However, you _can_ use a custom version of tasksel on your CDD with a custom set of tasks as I did for Dzongkha Linux. How that is done is explained here: http://www.dit.gov.bt/admin/index.php/Main_Page:d-i Note that support for scanning and swapping multiple CDs during the installation _is_ a D-I goal for Lenny. that would resolve the not in the first CD/DVD problem. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TaskSel proposal (Was: Proposal for a new CDD sub-project: Debian4Business)
Well ... i think you exagerated a little bit. 2 layer is not multiple layer and tasksel is not apt, aptitude or synaptic. but it can be done. I'll give you the desktop task example. there is a team, debian-desktop that supports and organizes all desktop tasks. by this i mean that there should be a team with, for example, apache and zope teams for Web Servers. like frans pop already said, cdebconf protocol is not ready for multilayer. The one layer tasksel is exactly to help user to choose one task and not become undecided if will install gnome or kde. Making things hard, tasksel could be a one layer interface (like it is) with an option for expansion, But i think this would mean that tasksel would be re-written and without using cdebconf's interfaces, which would break d-i, making hard changes in the new cdebconf's protocol. am i right Frans Pop? Andreas Tille escreveu: On Thu, 19 Apr 2007, Luis Matos wrote: At least, we could preseed some options, (like debian-med) but that wouldn't come in tasksel's options, like kde-desktop and xfce-desktop. IMHO the best solution would be if tasksel would have a two level selection: [x] Desktop environment [x] Gnome [ ] KDE [ ] XFCE # We could provide more than # `This task provides basic desktop software and serves as a basis for the # Gnome and KDE desktop tasks.' # but just the environment the user wants. If nothing of the second # level is selected, we go with the current selection list [ ] Web Server # perhaps rename to Web Application Server [x] Apache [ ] PHP [ ] Zope # Probably there are more things users might need on a # Machine that serves web applications [ ] Print server [ ] DNS server [ ] File server [x] NFS [ ] Samba [ ] Mail server [x] Exim [ ] Postfix # Perhaps we need an exlusively selection feature here because these two # conflicts [ ] SQL database [ ] MySQL [ ] PostgreSQL [ ] Laptop --- now comes the new part [ ] Custom Debian Distribution [ ] Debian-Edu [ ] Debian-Jr. [ ] Debian-Med The (random) alternatives given above (and marked randomly) make clear that the first level is so unspecific that no reasonable selection can be done, because there are quite common alternatives in nearly every section and it is not really clear what becomes installed. So I would regard this as a necessary enhancement to tasksel because I always ended up selecting nothing at all when I installed a new box, because I do not know exactly for instance what database server get's installed (well, I'm lucky enought that postgresql-8.1 is my server of choice but I was not sure whether MySQL is installed in addition, which I do not want nor MySLQ users would regard this entry useful). IMHO this multi level selection is a usual feature of modern install programs (in general) and seems to be absolutely necessary for me. This would more or less solve the CDD problem really simple. Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a new CDD sub-project: Debian4Business
Hello there ... Qua, 2007-04-18 às 15:24 +0200, [EMAIL PROTECTED] escreveu: I would like to start a new sub-project called Debian4Business or perhaps Debian-Office.I have a slight preference for the first name, but this is discussable of course. a bit of background. Last week i emailed debian-desktop list to propose as lenny release goal to add a task called enterprise-desktop and also one called enterprise-server, names are not important. I am just giving my support to this. I have a small company, that provides legal services. About 6 months ago (I use linux for more than 8 years already) all desktops are running Linux now. The people using those desktops have no prior linux experience. I have tried several distributions, but with every distribution I see problems appear with the people that use it. These problem appear because no distribution is really focused on business use within small and mid-sized companies. Of course there are some distro's with exactly this goal, however they are usually commercial products/forks. Probably all very good distro's but also awfully expensive, and that makes them not very interesting for small- and mid-sized companies. I believe there is definetely a 'market' for a business oriented linux based on open source/GPL/Debian social-contract, maintained for and by it's users instead of a commercial base. The open source/GPL/DSC concept works for individuals, so why it wouldn't/couldn't work for businesses? I think the majoraty of debian's instalations are in corportive environments, server And/or desktops. So i think that debian should have the goal to give those users a better solution than the general one. My goal with this project is to create a CDD that provides it's users with the tools they need to easily install and use the things a small and mid-sized business needs in their working environment. This goes for both server and desktop tasks. A small and mid-sized company often doesn't have a permanent system manager, that's exactly why things have to be simple. Of course it should also include the common office tools, like an office package (openoffice), email, groupware, etc etc. My first proposal was to create 2 tasks in tasksel. We have desktop task, so we could add an enterprise-desktop task. My point was to provide centralized authentication and information, having something like libpam-ldap and libpam-mount installed and configured by debconf's interface. For -ldap is easy, just now, it just asks for the server, but -mount would mount server partitions as well as user's desktop preferences. Also, it would be given care to the tools and packages included. A cdd would be good for some first testing, but having it included in debian would be great. I would very much like to hear the opinions of the developer community. The first -and very important- step to be taken is to form a group of people that support this goal and are willing to work on it. count with me. If there are no major objections I will start to get things going. Regards, Arjan van Eersel Dit bericht is verzonden via mijndomein.nl best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Sex, 2007-04-13 às 14:47 +0300, costin c escreveu: May be some informations or tips about how to build a particular package from maintainers/developers of that package could help new maintainers who want to learn how to build/debug packages in generally. for taht you have: - new maintainers guide - debian policy - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Please CC the debian-devel list. Sex, 2007-04-13 às 18:26 +0300, costin c escreveu: On 4/13/07, Luis Matos [EMAIL PROTECTED] wrote: Sex, 2007-04-13 às 14:47 +0300, costin c escreveu: May be some informations or tips about how to build a particular package from maintainers/developers of that package could help new maintainers who want to learn how to build/debug packages in generally. for taht you have: - new maintainers guide - debian policy - [EMAIL PROTECTED] Many details (low and high level) are still missing. If new maintainer or developer has some linux experiences, will do heavily search about missing details, but if he/she came from *doze at some point, probably will abandon his/here work. Missing details about working with source packages (and other things) can be found through various sites/forums like debian-administration.org, debianhelp.co.uk and many other. One problem is that all those informations are not centralized or structured in some way. do you use gnome? Do you know devhelp? This is a good documentation tool, if used. If is there going to be development tasks, Maintainer docs should go there, so the developper has all documentation in one place, and easilly searchable. Something you learn by the documentation in the files that are created with, for example dhmake. other docs are in /usr/share/doc and are not available in a way that user (developer) can easilly read/study. For example, to attach a patch to a debian package ( to change the source code as needed) is just one more call in the rules file and put the patch in place... Comparing with ubuntu, because it is focused in newbies, they have good wiki documentation and howto's. People just go there, follow the howto's and hope they work. Debian on the other hand, i think, have lot's of unrelated doc's. But they have them. For example, one complain i got from rpm packging system is that even if it was more easilly to packge than debian, it was not provided by good documentation. In the case of debian that documentation exists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Qui, 2007-04-12 às 09:53 +0200, Josselin Mouette escreveu: Le mercredi 11 avril 2007 à 23:20 +0100, Luis Matos a écrit : Tasksel has no devel task. There are no development environments for example: C/gtk, C#/GTK, Java/Gtk, python/gtk pre-defined. apt-get install gnome-devel i think that is better to have something like gnome-devel-c-cplusplus, gnome-devel-csharp, gnome-devel-java (this would be very good), gnome-devel-python ... gnome-devel has what? anjuta, devhelp, glade and ... i see for example that it has no -dev dependency ... so ... how are people going to compile stuff against gnome/gtk/linux libraries? They are only recomends. this should be an IDES/DOCS/LIBRARIES set. So the developer (as user) can have the development environment complete. This can be even better if it has an option to install this in tasksel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Qui, 2007-04-12 às 11:03 +0200, Reinhard Tartler escreveu: Santiago Vila [EMAIL PROTECTED] writes: i don't mean all the debug and etc stuff... But the a beginner environment for people to start to use and learn about linux development. I don't think beginner and developer belong in the same sentence. At least for debian, this seems to be quite right. Since this inquiry is valid however, it seems to me that it would make sense the think about some CDD specialised for developers. This would be very nice ... maybe some livecd's? ( it does not need necessarilly to be cdd) Volunteers? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Qui, 2007-04-12 às 10:58 +0200, Gabor Gombas escreveu: On Thu, Apr 12, 2007 at 12:57:09AM +0200, Santiago Vila wrote: I don't think beginner and developer belong in the same sentence. Yes they do. I met people who develop commercial software but who are completely ignorant about any system administration tasks. They're not the people who use computers because they like it and like to figure out how it works. They use computers because they get money for it. They are not intereted in doing anything at all that is not strictly related to the edit-compile-run cycle. This is what i ment!!! Of course with such workers you do need a dedicated system administrator but that was not the point here. I think of my coleagues and some people i know that are interested in programming and not making sys admin stuff. They just want to install some cd and have all the development environment. For example, one person i know, just goes to synaptic and starts to install everything he just thinks it has something to do with what he wants. So he has lots and lots of stuff that are just filling disk space and are not used. Imagine this when an upgrade is needed. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Qui, 2007-04-12 às 09:37 -0300, André Luiz Rodrigues Ferreira escreveu: 2007/4/12, Luis Matos [EMAIL PROTECTED]: Qui, 2007-04-12 às 09:53 +0200, Josselin Mouette escreveu: Le mercredi 11 avril 2007 à 23:20 +0100, Luis Matos a écrit : Tasksel has no devel task. There are no development environments for example: C/gtk, C#/GTK, Java/Gtk, python/gtk pre-defined. apt-get install gnome-devel i think that is better to have something like gnome-devel-c-cplusplus, gnome-devel-csharp, gnome-devel-java (this would be very good), gnome-devel-python ... Yeap! IMHO a meta-package would be better... But ... it would be great to have some tasksel submenu gnome-devel and the select the environments. anyway ... an wishlist bug is on the way to gnome-devel. gnome-devel has what? anjuta, devhelp, glade and ... i see for example that it has no -dev dependency ... so ... how are people going to compile stuff against gnome/gtk/linux libraries? They are only recomends. this should be an IDES/DOCS/LIBRARIES set. So the developer (as user) can have the development environment complete. This can be even better if it has an option to install this in tasksel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Andre Luiz Rodrigues Ferreira (si0ux) [EMAIL PROTECTED] *** Orlandia - SP - Brazil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Qui, 2007-04-12 às 14:39 +0200, Josselin Mouette escreveu: Le jeudi 12 avril 2007 à 14:25 +0100, Luis Matos a écrit : gnome-devel has what? anjuta, devhelp, glade and ... ... and gnome-core-devel. you killed me ... true, it has the -dev packages. do you agree with the previous post about dividing gnome-devel in some of them (or criating some of them). i see for example that it has no -dev dependency ... so ... how are people going to compile stuff against gnome/gtk/linux libraries? They are only recomends. No. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
Qui, 2007-04-12 às 20:40 +0200, Andrea Bolognani escreveu: On Thu, 12 Apr 2007 20:27:25 +0200 Julien Cristau [EMAIL PROTECTED] wrote: On Thu, Apr 12, 2007 at 20:25:35 +0200, Andrea Bolognani wrote: Still I don't see the advantage of having a complete development environment on a live CD. Who is supposed to use this? Students, who typically only have a windows install at home. It's much easier (for them and for the teachers) to give them a live cd with everything they might need for their university projects (at least in the first few years) than to give them instructions to get a useful development environment under windows. You convinced me ;) (I prefer the approach they use in my university: it's like GNU/Linux is the reference operating system in this course, so if you don't have it installed, you're better installing it quickly! But I'm going OT now :) To add to this, the live cd can be installed in the hard drive. So, if a windows developer grabs the C# debian development disk and checks that it's programs really work in debian, he will gradually change. We can make these cd's easilly available ( thanks to the live project people ) because they can be built with a list of packages. One we have some development meta-packages, we can make these cd's with tasksel's desktop task + devel metapackages. So i can go to my industrial informatics teacher a show him that he can develop visual basic applications in linux. -- KiyuKo eof AT kiyuko DOT org Resistance is futile, you will be garbage collected. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use bz2 not gz for orig.tar ?
Qui, 2007-04-12 às 21:03 +0200, Robert Millan escreveu: On Fri, Apr 13, 2007 at 03:38:56AM +1000, Drew Parsons wrote: Why not lzma? It reduces size even more It's the same question really. Do we want to move on from gz? I guess bzip2 is more widely known than lzma, that is we're more likely to directly use upstream's tarballs by adding bzip2 support. Certainly X.org releases tarballs both gz and bz2 compressed. But the question could be made more general. Why do we explicitly enforce gz compression at the moment, why couldn't we support *any* compression scheme that upstream developer or Debian maintainer might care to use? (perhaps the CPU arguments answer this sufficiently, though I'm not convinced by them myself). I think binaries are more important, since they're unpacked an order of magnitude more times than source. agreed ... faster in binaries, better in source. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
Qua, 2007-04-11 às 17:33 +0200, Robert Millan escreveu: I don't know what the critical mass of Linux users is that generates interest for Linux among software vendors. We seem to be far from it. Yes, but Microsoft is much farther. I wouldn't be surprised if our 64-bit userbase outnumbered win64's already. When 64-bit computing as a whole starts to become significant, they'll start to be interested in either of these platforms. don't forget the servers boost on amd64 + linux that every big companies (hp, ibm, sun for example) sold. many companies are promoting amd64 with linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
Qua, 2007-04-11 às 13:12 -0400, Lennart Sorensen escreveu: I can't stand visual studio. It drives me nuts. It makes it so hard to figure out what is going on and wants to get in the way of everything. Give me plain simple makefiles and source code files I can edit (preferably with vim) and I can actually get some work done. I don't like development tools that magically do stuff without telling you and without really letting you change the behaviour if the magic didn't actually do what you wanted. Visual Studio makes the job for non-professional programmers a pretty good job. I am in the final year of my Mechnical Engeneering degree and many of my coleagues does not have programing experience, so they program *only* in Visual Basic. So does a lot's of engineerings that are in front of teams to develop software, like my boss. So ... when yu want something, just let's hope microsoft has it developed ... when in linux, you just can have the simpliest platform nd the more complex one too. I think unfortunately GUI tools let people think they know what they are doing, and makes them think they know how to program. For a large portion of those users, they really don't know what they are doing (especially when visual basic gets involved), and end up writing unmaintainable bloated crap with many dumb bugs. No ... gui tools helps people with some non coding work. Having, for example, an F11 key to compile, or someone to edit most of my makefiles is pretty good. Still ... i agree ... i hate Visual Studio because you only have the gui. I develop in anjuta and use gdb for debug, along with other memory debuggers. Of course you can write unmaintainable bloated crap with vim and makefiles too, but at least you have to do a bit of work, not just click pretty buttons. lol ... there you have to at least think what you are doing for sure. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Development environments.
Qua, 2007-04-11 às 22:56 +0200, Michael Banck escreveu: On Wed, Apr 11, 2007 at 08:01:09PM +0100, Luis Matos wrote: Visual Studio makes the job for non-professional programmers a pretty good job. Please remember that this is debian-devel and not some general discussion forum. Please allow me do a small fast question/comment. I think debian has some closed doors on developpers that come from windows. Tasksel has no devel task. There are no development environments for example: C/gtk, C#/GTK, Java/Gtk, python/gtk pre-defined. Environments where developpers can simply install and start working. There is no standard IDE (ok, i know mono for gtk#, bluefish for web stuff, anjuta for C, Kdevelop for a bunch - that is very good, ok... vim and emacs) that people can use in a Visual Studio Way. i don't mean all the debug and etc stuff... But the a beginner environment for people to start to use and learn about linux development. It's not a great dificulty to set this up, but having this prepared makes things easier for windows to linux developers. It is a good thing to put in lenny. thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
Ter, 2007-04-10 às 08:28 -0600, Warren Turkal escreveu: On Tuesday 10 April 2007 07:43, Tshepang Lekhonkhobe wrote: I may have exaggerated by saying 20 years, but I will not settle for less than 10. And we need those anyway to compare results obtained by one software against the other. This is interesting. I often hear people citing pros and cons of FLOSS and commercial stuff, but don't remember anyone stating such extravagant development gaps as 10 years or so. I'd like to hear opinions of others who have also used those Cplex Maple, and whatever else you may have in mind. This however brings to mind libre CAD stuff which truly lags behind. People wouldn't use those programs more than the free equivalents if there weren't some reason. Sometimes that reason is that the proprietary solution has a larger library of extras (libs, etc.) around it that makes it easier to quickly do something without reinventing the wheel. Sometimes the reason is as simple as someone doesn't want to have to learn a new software package or port all there stuff to a new software. These are hard barriers to overcome. Maybe software vendors will look at linux for more power for less hardware, using 64 bit solution. Talking about CAD and CAM, for example, they need too much of power, even if machines are currently enought. Having linux to complete use 64 bit solutions may open a door for software vendors to built their applications on linux. Free cad implementations are too simple for use in some industrial environments, when programs like CATIA or Solidorks, or inventor, Come in Mind. These programs are expensive and require power that can be better used in 64 bit platform. CATIA has unix versions ... i don't really know if they will ever have linux versions. best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
Most people and main developpers only know windows' tools for development, that's for sure. I am currently developping an industrial application for windows and linux, because i forced the use of gtk (so i can develop and run it on linux), but my boss is forcing me to only develop in and for windows, because it is the OS that everybody uses ... It doesn't matter if there is a dependence on windows, if there re other better oeses ... many industrial tools are developped in visual basic ... things like CNC software controlers. Can linux and opensource OS compete with the facility to develop in windows? Ter, 2007-04-10 às 12:25 -0400, Matthias Julius escreveu: Luis Matos [EMAIL PROTECTED] writes: Free cad implementations are too simple for use in some industrial environments, when programs like CATIA or Solidorks, or inventor, Come in Mind. These programs are expensive and require power that can be better used in 64 bit platform. 64bit Linux has been available since years. Pro/E is available for 32bit RHEL only. UGS NX was to be ported to Linux as well, but I couldn't find any information on their website. It seems like you have to log in first and you have to be a customer for that. So why is nobody adopting 64bit Linux (or *BSD)? Autodesk will not even have a win64 port of Inventor with the upcoming release. They do have one for AutoCAD. I doubt Autodesk will ever port their software to Linux. They are tied up with MS all over. Inventor requires MS Excell and it uses VBA. Their data management system requires MS IIS and MS SQL Server. They are just switching from OpenGL to DirectX... AFAIK it doesn't look much better for SolidWorks. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade Experiences (27 Sarges - Etch, and counting)
Seg, 2007-02-12 às 20:35 +0100, Adrian von Bidder escreveu: On Monday 05 February 2007 17.23:28 Maarten Verwijs wrote: I took the plunge and upgraded about half of the Lab here to Etch. This is about 27 machines to date, catering almost the same amount of users. Hi, Manually? I'd just like to point out that for 27 machines, setting up a fai server is definitely worth the effort! Painless re-installs, and moving our fai setup from sarge to etch (including LDAP auth, NFS homes and some local specialties) cost me less than 2 days. (Of course, if you really upgraded these machines manually, the RMs and many others are grateful for the testing :-) remotely run echo deb http://ftp.mirror.debian.org/debian etch main contrib non-free /etc/apt/sources.list apt-get update apt-get dist-upgrade -y ... it's not 2 days of work :P besides this, i agree that fai is a lot better to manage all users ... seems to be that these 27 machines have only local users (i think ... ) cheers -- vbi -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade Experiences (27 Sarges - Etch, and counting)
Seg, 2007-02-05 às 17:23 +0100, Maarten Verwijs escreveu: hi, I took the plunge and upgraded about half of the Lab here to Etch. This is about 27 machines to date, catering almost the same amount of users. In totall there are 62 Debian Desktops here. Most of the Sarge-machines recently upgraded were installed almost 2 years ago. as debian user ... i just have to say WOW!!! Etch is really in shape :P I want to congratulate ALL debian developers, they are doing awesome work:P All machines are Pentium IV's (2.8 through 3.2 Ghz), with 'round 1GB of memory. A small list of software installed (before upgrade): - Gnome - KDE - XFCE - autofs - XFree86-4 - subversion - NIS (yp) - Firefox - XEmacs - Emacs - Vim - Tetex - snmp - ntp - cups - openoffice (from backports) - Evolution None of the users have expressed complaints or problems, even after asking several times. If something was wrong with their XFCE/KDE/GNOME, they'd let me know. :) There are 2 things that require me to do some manual labour: * Opera. If opera is installed, upgrading from XFree86 to Xorg fails. Xorg wants to remove a folder that Opera still has a symlink in. well ... this is an important move in this version :P No biggy: remove opera prior to upgrading. Luckily for Debian, this is not their problem: it's Opera's. * Autofs and NIS. We still use NIS (yes we do) and NIS starts _after_ autofs. This means autofs is not aware of the NIS information. Therefor: no /home/* This is a known bug, that i can work around using rc.local. So as far as I'm concerned: Etch is ready to go! Thanks for all the hard work! Debian is still the one and only distribution for me. It Just Works. Thanks for your efforts. If you need more details about the installed Sarge machines that were upgraded, please let me know. Kindest regards, Maarten -- Maarten Verwijs Debian Administrator Netherlands Institute for Space Research (www.sron.nl) -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /var/www or /var/web
Sáb, 2007-01-20 às 11:39 -0500, Roberto C. Sanchez escreveu: On Sat, Jan 20, 2007 at 08:28:57AM +0100, Michael Koch wrote: The idea behind using /var/www for all webservers is that the user can install a different webserver and it just servers his/her content. All packaged web aoolications are put into /var/www too so choosing a different root for MyServer defeats this and makes no sense for Debian. Then why to some applications install into /usr/share/foo and then ask you to create an alias in your apache config? i think this is a way to go. one thing is to choose the web server's root. Other one is to choose the place were you want to put your things. for example, phpsysinfo installs on /usr/share/phpsysinfo and symb links into /var/www/phpsysinfo. this is ok, but maybe, a better location is sysinfo or hwinfo. the easiest way to do this without handling links is to add an alias in the web server, which i think should be the default behaviour. the same happens with squirrelmail. you would prefer /webmail or a single webmail.domain.com host than domain.com/squirrelmail . so i think all packages should come with symbolic link or the alias option. Not to install directly on /var/www . Regards, -Roberto -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /var/www or /var/web
The point and not. 1) debian default installation is for the default user. default user can simply want to have a localhost with php on it for development. So installing on /var/www is good for him. 2) webservers For a webserver (serves only one vhost) default /var/www is most of times ok. 3) webhosting These kind of implementations are setup according to the desire of the IT person who maintains it. I, for example, like to have a /srv/www/vhost , a /srv/svn(/vhost), etc . like ftp servers point the anonymous user to /home/ftp , webserver point default behaviour to /var/www. This is good for default instalations. Power users should change as they pleased. I think /srv is meant to this in cases of webhosting or serving any kind of service (for example file serving) Sáb, 2007-01-20 às 22:38 +, Kai Hendry escreveu: On 2007-01-20T15:09-0600 Steve Greenland wrote: I disagree. In particular, your method requires more work: I have to modify DNS in addition to any other setup work. True. Updating DNS for Web services is a pain. I usually shoot for a wildcard entry. The nice thing about opinions is that everyone can have one. The nice thing about Debian defaults is that no one forces you to use them. The way that Debian 'defaults' /var/www with Apache and inconsistently with Web applications isn't wanted usually by Webmasters. Though then again, that's really an opinion. ;) -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Proposal for official screenshot repo
Sáb, 2007-01-06 às 12:01 +0100, Bernhard R. Link escreveu: * Luis Matos [EMAIL PROTECTED] [070105 18:13]: Such a gallery should at least include some notice about the copyright owners and licenses of the parts it is composed from, best with also links to the source packages used. (And the one operating that gallery ask a lawyer if more is needed) ofcourse ... uploading the screenshot, the user is agreeing with it. The user is agreeing with what? LOL - It was a talk about the screenshots license ... the user is agreeing with the license the site is giving. Debian will propose gpl for the screenshots (or other), and the user must accept it to upload the screenshot. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qui, 2007-01-04 às 20:22 -0500, Matthias Julius escreveu: Luis Matos [EMAIL PROTECTED] writes: There could be another archive called updates.debian.org where selected packages go in in coordination with the security and stable release teams. that would be nicier ... but that's a bit of volatile's purpose. Although it is not very used. You are right. It does sound a lot like volatile. I didn't know much abaut it up to now. Maybe all that needs to be done is to make it more official, have it supported by the security team and put a commented out line for it into sources.list. I think for desktop use, volatile could be a good answear to update some software. Also, like to servers. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Proposal for official screenshot repo
Sex, 2007-01-05 às 14:13 +0100, Bernhard R. Link escreveu: Such a gallery should at least include some notice about the copyright owners and licenses of the parts it is composed from, best with also links to the source packages used. (And the one operating that gallery ask a lawyer if more is needed) ofcourse ... uploading the screenshot, the user is agreeing with it. my thought goes to application only upload, i.e. ... a screenshot for evolution would a screenshot of only the evolution window and maybe on some interacting with the system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
creative conmmons is considered free by debian?
Later back, some issues occored and i was told that CC was not, but a new version was to come. is it considered free now? the 2.5 or 1.0? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Proposal for official screenshot repo
Maybe in the /debian package, there could be a package.png that is the screenshot and make them available in the mirrors (pool). maybe creating a file such as Packages.gz or an extension to it, informing that it has the screenshot available. then the user could access the pool ... or ... use some kind of client that uses the apt-get database to search for screenshots. For example, a simple gtk window with a combo box with the packages' names who has screenshots, and the user could: 1 - select the package 1.1 - application downloads it 2 - view in the application window 3 - full screen ( maybe using eog?) i think it is simple. Although ... the package will see it's source size increased and... 1 MB for 10% of debian's packages is +/- 2 Gb more of disk space in the mirrors. The screenshots can also use a similar process but use a package of their own. With the same process described, a package_0.3-1.dscr will have a bunch of screenshots of package. This package can be downloaded and untared for view, in the user's application. What do you think? Got lost?? Javier Fernández-Sanguino Peña wrote: On Thu, Jan 04, 2007 at 12:05:03AM +0100, Nico Golde wrote: Hi, this idea has been discussed recently, I just can't remember when exactly though, I'd say in the late 6 monthes. Maybe you can grab some names of people that were involved in the first proposal there. It may have been proposed on -project rather than devel. But I suppose google will know about it. Maybe the following? http://lists.debian.org/debian-devel/2006/04/msg00915.html It's not exactly the same idea. The proposer (Gonéri Le Bouder [0]) focused on what the layout and distribution of images [1] should be, but not on: - who provides the screenshots? how are they uploaded and validated? (is there an upload queue who manages all this automatically?) - is there a web interface to that information or it will just be used by package managers? The Alioth project was named 'apt-pixmap' [1] there has been no activity in its mailing list [2] and the original location of the proof of concept [3] does not exist any longer. So I guess the project did not spark enough attention. Some of the information in the project as well as the threads can be used to draft a new proposal, however. I think that something similar to backports.org (a service where both DDs and non-DDs could upload screenshots to) and provided a web interface to view screenshots by package version would be really cool. Regards Javier [0] Who, BTS is now the proud father of a little girl: http://orniere-du-globe.net/blog/?p=312 :-) [1] Based on Debian packages or TAR files so the user could download *all* the screenshots using a specific tool. Which, BTW, I don't think is a good idea. [2] http://alioth.debian.org/projects/apt-pixmap/ [3] http://lists.alioth.debian.org/mailman/listinfo/apt-pixmap-repo [4] http://gloria.rulezlan.org/debian2/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu: On Thu, Jan 04, 2007 at 11:00:16AM +, Paul Waring wrote: I think the problem that many people find with Debian is that they do want the stability and security of stable, but at the same time they don't want to be a dozen releases behind upstream. I've seen many occasions where there's been a new release with useful features that has been available in upstream for months and it's still not in Debian stable, even though it is available in the package repositories of other Linux distributions. It's not so much a case of wanting to be on the bleeding edge for most people, but more that we don't want to still be powering our machines with crank handles when everyone else has moved on to electricity. backports.org is, to my mind, a perfect solution to this problem; it allows you to selectively upgrade your favourite/important packages that you need, whilst retaining the stable base on which to run them. here i agree that backports.org is the way out and that should be official so maintainers could upload backports in a easier and have a better security support. (and gives users other view for it if backports.org is indeed in debian and recommended by debian.) One proviso I would add to that is that it's only good so long as it doesn't move too much focus away from Debian's own stable releases. I can't see any evidence of that at present. It's also possibly the case that backports.org could/should made more official or at least offically recommended by Debian, although I understand why this isn't necessarily the case right now. However, the original question was about hardware support, which is a rather special case. I've spent many frustrated hours getting Debian stable onto modern hardware using various tricks and hacks, and I'm sure anyone running Debian extensively in production has had similar experiences. This is one area where an official updated installer and kernel would greatly improve life, and I'm very interested by Moritz's comment that this is planned for etch. oh yeah ... in the woody time, i was save by a d-i rc1, installing new hp proliants. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qui, 2007-01-04 às 16:43 -0500, Matthias Julius escreveu: Luis Matos [EMAIL PROTECTED] writes: Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu: backports.org is, to my mind, a perfect solution to this problem; it allows you to selectively upgrade your favourite/important packages that you need, whilst retaining the stable base on which to run them. here i agree that backports.org is the way out and that should be official so maintainers could upload backports in a easier and have a better security support. (and gives users other view for it if backports.org is indeed in debian and recommended by debian.) Maybe backports.org is too much and changing to frequently to provide security support for and to be really stable. backports use testing as base for the packages. setting up security for backports is a bit easier than for testing. Lot less packages. My point is, for example, when the security team lauches a DSA, it always sees if both unstable and testing are afected. They already monitor testing and unstable too ... it's just a question of applying patches. (maybe a apt-patch package. in which he rebuilds the package with the selected patch). The same would do for backports, security team would patch the package and send it to the buildd. I know ... it's more and more work for the security team ... There could be another archive called updates.debian.org where selected packages go in in coordination with the security and stable release teams. that would be nicier ... but that's a bit of volatile's purpose. Although it is not very used. at a certain point several packages could be updated, because mainstream releases an important release. Like mysql-5.0, or ooo 2.0 ... and they could be addressed to backports or volatile or updates (volatile, for me, means critical updates for debian stable ... because stable must remain ... stable). We definitly need something to make debian stable move while it is stable. Someone talked about the release cycles ... i think debian should not move to less than one year ... we already have ubuntu and see what is going there with the 6 months. The main problem for the year release is desktop, because linux has suffered lots of evolution in this field in so little time. Companies that deploy linux on desktop seem to seek for updating contantly the desktop (or others let them to rott). I think what debian needs is a lift in the desktop part, and the desktop team is moving. (the desktop team needs designers or people in the design area) I always compared debian stable with RHEL. They both target the same, i think. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Proposal for official screenshot repo
Qui, 2007-01-04 às 16:49 -0500, Roberto C. Sanchez escreveu: - Requiring a new package upload just for screenshots (If we want to allow user contributed screenshots, the updates to the screenshots really need to be able to happen independently of the package uploads. I think the screenshot only package is a good option. The packages can be generated automatically from somewhere and uploaded to debian and target the same version as the package. The could be an web interface to help DD's to upload a gallery of images and select the ones to that version (for example changing package foo-0.3 to 0.3.1 will not change it's look, so, the DD goes to the web interface and ask to rebuild the package for the new version). i also think that user uploaded screenshots can be possible, but i desagree ... or ... their upload is accepted, but, the DD has to select the screenshot from the web interface's screenshot list. Then, from the mirror, with the application like synaptic, it can download the screenshot package with several screenshots and see. Always DD controled. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Sex, 2007-01-05 às 00:57 +0100, Daniel Baumann escreveu: Luis Matos wrote: backports use testing as base for the packages. setting up security for backports is a bit easier than for testing. Lot less packages. My point is, for example, when the security team lauches a DSA, it always sees if both unstable and testing are afected. They already monitor testing and unstable too ... it's just a question of applying patches. (maybe a apt-patch package. in which he rebuilds the package with the selected patch). The same would do for backports, security team would patch the package and send it to the buildd. I know ... it's more and more work for the security team ... thinking aloud: hypothetically assumed that (parts of) backports.org would get official, i could do security support for it as i do it atm for about half of the packages on backports.org anyway. That was a good idea (if backports integrate debian). The security team already monitors testing and unstable ... do, it is only needed for someone to patch the packages. I am not a DD ... But this could be a good step to bring backports.org into debian for etch. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
etch's upgrades during life cycle
Hello i m a debian user and like many other debian users there are things in debian that i like and dislike. I am going to get a round no for what i am asking, but i think it is a good question. Many users have complaints about in the middle of the life cycle, or before the debian stable release no longer supports new hardware. Therefor a new kernel would be needed for d-i ( or an hardware compatibility update for the kernel and modules). My proposal would be in point releases to change the kernel a bit to support more hardware. That kernel would be tested, ofcourse. What i am saying is: is it possible to in a lenny or lenny++ change the way debian upgrades it's stable, just for the kernel? Other programs can be upgraded by volatile's repository or backports but the kernel is something that is crucial. We (users) just want to enter the cd in the cdrom reader and ... get debian installed in 15 minutes. i know the work that would be needed and probably the bugs that would come up... another choice would be a new package of modules, with the correspondent udeb for d-i. Please, don't kill me because someone has to talk about this once in a while. -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qua, 2007-01-03 às 22:13 +0100, Daniel Baumann escreveu: Luis Matos wrote: What i am saying is: is it possible to in a lenny or lenny++ change the way debian upgrades it's stable, just for the kernel? both things are already solved unofficially. there are kernel backports [0], and kenshi makes stable-with-new-kernel installer-images[1]. so, basically, you are asking to make them (more) official now? basically yes. When a user approaches debian, goes to www.debian.org then follows the link to the distribution, grabs the iso, burns it and install it. when it does not fit ... he will say that debian does not support hardware foo (this can be truth) and goes for another distribution. Even, i don't know if the d-i images posted there have security updates. People know that a kernel that is debian supported is secure and bug free (or more bug free than others). So, if we loose security and stability ... why use debian? [0] http://www.backports.org/debian/pool/main/l/linux-2.6/ [1] http://kmuto.jp/debian/d-i/ -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Qua, 2007-01-03 às 22:28 +0100, Daniel Baumann escreveu: Luis Matos wrote: So, if we loose security and stability ... why use debian? security and stability, that is excately what makes these backports unofficial (more stability and bugs are an issue than security, though). however, if you want to have latest and greatest but with stability and security as you know it from debian stable, then you are asking for the impossible. i don't want the latest and the greatest ... i want a newer kernel :P not means to be the latest ... even when you know that there are some buggy releases. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- Best Regards, -- Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #397716 - please provide a debian-icon on the default desktop install, not an ubuntu one
Sex, 2006-11-10 às 13:52 +0100, Josselin Mouette escreveu: Le vendredi 10 novembre 2006 à 12:16 +0100, Holger Levsen a écrit : last weekend I did a etch default debian install, in which gnome is the default desktop environment. update-manager is installed as a part of it, and accessable over the Desktop/Administration/update-manager menu. The icon for the menu shows a cd with an ubuntu-logo, which I think is very bad marketing for debian. P.P.S.: _I_ do think this is somewhat release critical :-D Not only somewhat. According to the Ubuntu trademark policy [1], we have to obtain Ubuntu's approval before using this logo. So, what the hell is that logo making there? [1] http://www.ubuntu.com/ubuntu/TrademarkPolicy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DPL Debate prepared questions list [Debian Policy Sucks]
Ritesh Raj Sarraf wrote: On Tuesday 21 March 2006 02:09, Joey Hess wrote: Ritesh Raj Sarraf wrote: So what do you people suggest in such cases: 1) Intel 1000MT NIC sucks, throw it away ? 2) Unh! Why don't you change to Debian Unstable ? 3) Buddy! We are all volunteers. Go and roll your own kernel with the patches ? 4) Wait! That hardware isn't officially supported by us. Build only machines which are known to work with Debian Stable? 5) etch beta 2 was released last week with support for your hardware So my question is: I discovered it today. But there might have been many Debian Users who might have discovered this issue earlier. What choice are they given ? Is the choice: Wait till etch gets released ? RHEL and SLES do a damn good job of Hardware Bug Fixing and Feature Enhancement for the software they ship. Why can't we do it ? Is it just because our policy doesn't allow it ? Can't we revise the policy ? Thanks, Ritesh There was spoken at sarge's release that there would be kernel updates on him. This would be a good thing, even if older got not supported, because if you upgrade to a new securiy kernel update, why not to a new kernel? That is what dcc is trying to do, and what i think is wourth of. (sorry my bad english) Also, this could be happening inside volatile, but it seems not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
changing distribution names to achieve world domination
voxvirus @ ptnet realize that people are not well informed about debian. So, for marketing strategy we have a small proposition to the naming scheme, for achieving world domination: stable - server testing - desktop unstable - game_arena experimental - winxp the choices are obvious: stable is a server dedicated system, stable, well constructed and infallible. testing is an updated system, stable enought . unstable is bleeding edge, new techology, for teenage geeks . experimental is ... well ... crappy ... unstable ... crashing ... unoying system. It can crash, it can work (we can put this part for gaming?). just a funny note. regards, Luis Matos _gass_ @ptnet gass @ freenode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
