Re: FREEZE RESCHEDULED
One of the best ways of getting the release-critical bugs under control is to freeze potato. As long as we can upload packages, we will upload bugs. If we freeze now, we can reduce the number of bugs to a reasonable level over the next few weeks. By the time boot-floppies are ready the bug count will be at a manageable level, and potato will be ready for release. How about a light freeze where we don't accept new packages until the next unstable. Then atleast we don't age the distribution, and we can still upgrade packages, and fix bugs. Every year with the same problems :-) This 'pre-release' will do it if we don't work on the new unstable; this one is only to upload new versions. Regards, Hartmut
Re: Debian's involvement in another exhibition
Where is Oldenburg geographically? E.g. how far from Holland? :-) Groningen is about 100km. It's 50km south of the coast, where the coast makes its way to the inner country. (difficult to explain.) _ (_) _ _/ -\ (_) (_) |\/ | o Aurich| | / \ /\ | | \ | o Emden|/ / o | | ---/ Groningen | | \-/ o Leer o Winschoten o o Oldenburg Assen =o Bremen o Emmen
Re: Too many kernels in unstable
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? What about just keeping the last 2.0.x and the last 2.2.x ? It's also a lot of space on the ftp site. And maybe one from the unstable tree 2.3.18 to test compatibility for 2.4 ? This are then only three kernel versions. Thanks, Hartmut
Re: Old Library dependencies Re: Release Plans (19990513)
Remove as many dependencies on old libraries as possible, this includes: libjpegg6a, libncurses3.4, newt0.25, libpgsql, tk4.2, tcl7.6, libwraster1, libpng0g and various older gtk/gnome libraries. Lintian has a depends-on-obolete-package tag. I will add newt0.25, libpgsql, tk4.2, tcl7.6, libwraster1, and libpng0g to its list. This way, the Lintian page for that tag will form a useful index. Why not libjpegg6a and libncurses3.4? What about xbase, emacs19, altgcc, freetype1, libc5, libg++27, libpaper, tclx76 and possible some more? Thnx, Hartmut
Re: Release Plans (1999-05-10)
Also the mozilla web pages are not very informative about non-i386 compilability, but then maybe i didn't search in the right place ... I don't know much about porting, but I do know that it works on Solaris, and some versions worked on AIX and HP-UX... since those OSs run on different architectures, I'd say it could work. Good luck :) For powerpc: the composer mode works. The normal mode (with menus) not. Thnx, Hartmut
Re: Release Plans (1999-05-10)
The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. The OF of my LongTrail works perfectly but i don't know how to set it up for autobooting. Booting from floppy is not (yet) possible (for initrd) because the kernel cannot read the floppy. So net or cd booting are the only choices. Currently i wait for manoj's update for his kernel-package with my changes. After that, compiling will be easier. But then i need kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree. Which class is rs/6000, chrp or prep? Thnx, Hartmut
Re: Release Plans (1999-05-10)
There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. And i guess this will be the same for apus systems, ... No! Only one (2) cd for all powerpc systems. Please think about a wrapper for this or special boot-arguments ... but not 5 different powerpc-images. Thnx, Hartmut
Re: Release Plans (1999-05-10)
For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I asked Steve to use the HFS options for PowerPC too (so the code's already there...) Great! One point i can strike off from my todo list. Thanks.
Re: Release Plans (1999-05-10)
On May 10, Paulo Henrique Baptista de Oliveira wrote: I think that Power PC will be included in potato. It will be definitly.
Re: Release Plans (1999-05-10)
Moin all, * Working disk sets for all released architectures. I don't know much about the plans for the boot-floppies yet. Could someone volunteer as a contact person, or tell me the best list to read? A minimum is two months for this -- if we start now to work on this. * glibc 2.1 source compatibility A larger task is to ensure that all packages still compile on a glibc 2.1 development system. The sparc people may have a list of problem packages. The packages must work for glibc-2.1 _and_ linux-2.2, this is important. I think we have more then 100 release-critical bugs, not all such bugs are marked as critical. I've put my autobuilder logfiles (for bad packages) on http://master.debian.org/~koptein -- please have a look at it. This are not all glibc-2.1, linux or dpkg bugs, but mainly. Timescale: The freeze is at least one month away, and possibly a lot more than that. I'm not going to set a date until the number of release-critical bugs has been reduced considerably. Correct. Potato Architectures: As far as I know it will be the same set as in slink, i.e. i386, m68k, sparc, and alpha. If any other architectures want to make a release they will have to decide soon. + PowerPC The biggest showstopper are the boot-floppies -- for all architectures! Other topics: language support for boot-floppies (and then also cd-images) and dpkg dselect (and newer apt-get versions). mozilla should work for potato Thnx, Hartmut
Re: Release Plans (1999-05-10)
Hi, BTW, I think it's good to set an *optimistic* freeze date, so people aren't shocked. I would set it at July 1, or maybe Bastille day (Debian pomme de terre?). For slink update or for potato? For potato we new min. two months and only if we start now working very hard (all maintainers, not only 10 people or so) on bad packages boot-floppies cd-images. The QA-team must then also have the power to do massive NMU's. How many open bugs have we, more then 7000? This must be down to ~1000. Thanks, Hartmut
Re: Release Plans (1999-05-10)
The best list is [EMAIL PROTECTED] The main problem we are facing is our official 2.2.x kernels are huge, and there's no way to put the kernel and the root.bin image on a single floppy. The proposed solution is building a modularized kernel, and loading the needed modules using an initrd image, but AFAICT, there's nobody working on that. What about the ramdisk/root.bin (and then also for the netboot-ramdisk)? They are also very huge now. Floppies with 1.7MB isn't good ... Regards, Hartmut
Re: Release Plans (1999-05-10)
There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs).
Re: KDE debian stuff
kdm not requiring xdm. (I migrated kdm out of kdebase so it is a seperate package..this should take care of this for the time being) migrate kde out of /usr/X11R6/bin and into /usr/bin (requested by someone) fixing up the scripts (still working on this...have current issues with the i18n stuff, but everything else works) /etc/init.d/kdm shouldn't use /etc/X11/config, its obsolete. #!/bin/bash # /etc/init.d/xdm: start or stop XDM. test -f /etc/X11/config || exit 0 grep -q ^xbase-not-configured /etc/X11/config exit 0 case $1 in start) grep -q ^start-kdm /etc/X11/config || exit 0 if grep -q ^start-xdm /etc/X11/config then echo WARNING : can only start kdm or xdm, but not both ! fi Thanks, Hartmut
Re: Release Plans (1999-05-10)
For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. PReP can't read msdos partition on cd?
Re: Release Plans (1999-05-10)
Hi, sorry for the confuse layout on http://master.debian.org/~koptein `log for successful build of x' means also a bad/failed package; this comes from an bad return value of one of the autobuilder scripts (don't know which one). Thanks, Hartmut
Re: Release Plans (1999-05-10)
mozilla should work for potato Maybe it will ;) We'll try. I try it now serveral weeks (not constantly), but all what i get is the 'composer' mode on powerpc (the one without the menus) or a window without anything in it. It makes no different if i use the M4 version from master or the cvs version (with idl). Any tips/hints for this? Thnx, Hartmut
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
3. Porters needn't to ask maintainers for permission No-one has to ask for permission for a NMU. That's the point of a NMU. You file a bug, you wait a reasonable time, if it's not closed, you do a MNU. ^^^ Ahhh! Now you have it! This is very bad! Because: low on time, low on hd space, low brain :-), and so on ... Forget it then. This is not possible. (Reminder: porters (i) talk about 200 packages, and after my list 'work for developers' only two people get in contact). I think, we should it do as we have it done the last three years. Thanks, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
But you're missing my point. Why does a binary-only NMU give you the right to skip waiting, while a normal NMU does not? Why are they different? Why does one let you circumvent the rules, for however noble a purpose? Binary-only and normal NMU's are the same thing, and if you can do a binary-only NMU w/o waiting, you should be able to do a normal NMU w/o waiting. And if you can do that, it follows you should, since a normal NMU is better. How will you feal, if i get one of your packages, make necessary patches for kernel-2.1 and glibc-2.1 and egcs to it and upload the package _with_ source (without asking you for permission) to master. And then you notice that this new source-package is broken on your system? binary-only MNU hits only one arch normal NMU hits possible all archs Another story: I patched a debian binary in february, forwarded the patch directly to the maintainer (not to the BTS) and uploaded this package as a binary-only MNU. This package (with the patch) is always not yet available, because the maintainer is very busy to make a new release. This is more then a 1/2 year ! Greetings, Hartmut PS: we talk no about two or three packages, porters means 100 or 200 packages :-) -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Ok, let us a little bit summarize: 1. binary-only NMUs breaks policity 2. every NMU must be with source 3. Porters needn't to ask maintainers for permission 4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer ok for all ? If the answer is 'yes' i agree ! If so, we (porters) increment always the debian package minor number +1 . MfG, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Upcoming 2.1 Release Architectures
If we call it something like a 'developer' release, or an 'early-access' release, then it sounds like a great idea, yes... as long as people don't get the impression that it is a full 2.1 release. Ok, under this impression powerpc is ready to go. I'll upload 2.1 kernel source and images for powerpc in three or four days to master. Possible we can have only _one_ source and not as for glibc-2.1 many source-packages available (2.0.93, 2.0.95). I'm not sure, if i should upload the cvs tree or the normal linus tree. Powerpc is nearly perfect with the official linux 2.1 tree, what about sparc? Thanks, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Hi James, Who said they were bad? They are very rarely necessary however, since 99.5% of the time (the only exception I know of is Hartmut's packages) yes, my packages are the only one that test masters scripts for non-i386 maintainer source uploads. :-) This is now possible but it was not always the case in the past. Its time to remember: - multi archs cds are comming - work is in progress for downloading serveral arch binaries from our web pages - documentation will be better and better - debian is always free but: we have always no consens for an easy installation - what means: (new) users have not the choice to select for a base- , middle- or big-installing procedure. This is more important then a x11 installation (for boot-floppies). [joda filter off] :-) Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Upcoming 2.1 Release Architectures
Could I get some official word on which architectures wish to be included in the 2.1 release of Debian? Thanks! PowerPC has more or less given up on making 2.1. We're moving well, but I'm of the inclination we shouldn't release until we have a truly stabilized libc - or at least until we're a lot closer. Right, powerpc shouldn't go in right now. We have more then 200 packages uncompiled (many maintainer doesn't response for bug lists!!!). We need a 2.1.x kernel source package, which isn't available for debian. Brian and the other arch maintainer with 2.1 kernels: what about to have the linux-cvs tree (as a debian package) in experimental?? This will help. Linux-2.1.125 is very near on linux-2.2 !! I like also to have the powerpc-debian-cd available before we release. Thanks, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Upcoming 2.1 Release Architectures
We need a 2.1.x kernel source package, which isn't available for debian. I don't see why you couldn't create one just for the powerpc arch. Either way, v2.2 of the kernel should be available before v2.2 of Debian. Yes, last rumors say that linux-2.2 came out short before christmas. Oh, i can generate a kernel-image_2.1.125-1_powerpc.deb along with source and dsc files and upload it to master, but will you and the other arch maintainer agree with this?? Brian and the other arch maintainer with 2.1 kernels: what about to have the linux-cvs tree (as a debian package) in experimental?? This will help. Linux-2.1.125 is very near on linux-2.2 !! I'm afraid I don't understand. What do you mean about the linux-cvs tree? The linux-cvs tree fits better for all architecturces then the 'normal' linus tree. But anyway, i think start working on pre-linux-2.2 is a good thing. Xfree needs some work for framebuffers, new alternativly x11 setup for boot-floppies, new config files for the kernel-package, ... BTW: have we binaries for the bttv driver available (video/audio driver)? Greetings, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Upcoming 2.1 Release Architectures
Oh, i can generate a kernel-image_2.1.125-1_powerpc.deb along with source and dsc files and upload it to master, but will you and the other arch maintainer agree with this?? If it's a powerpc package only, I don't see why there would be a problem. It should get installed automatically without ever coming to my attention. Or is there something I don't understand? Great news. But uploading a *.deb package without source?? I think this will be rejected!? And you mean uploading to unstable, not to experimental? And in the past, we have had one kernel-source with additionel patches for not fully supported architectures (as m68k). I think this will be similary for linux-2.2 - i386, alpha and powerpc are fully integrated, but arm and m68k won't (don't know it for sparc and mips). But uploading 2.1 kernel images will help. Thanks for the info. Regards, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Upcoming 2.1 Release Architectures
Brian Could I get some official word on which architectures wish Brian to be included in the 2.1 release of Debian? Thanks! I don't think sparc is ready to go, though Johnnie or Eric may see it differently. I'm neither Johnnie nor Eric but I think the basic tools on sparc are stabilizing (compiler, glibc2.1, kernel). I don't think Sparc is ready for a full blown quality release like i386. Does it make sense to go for a stabilized developer snapshot, i.e. a Sparc port which has base, required, standard and parts of the optional packages (sources based on the slink dist of i386) ? Kind of a official _development_ release with a big disclaimer about the development character of the port. Powerpc probably would be a second candidate for such a release. 2 reasons in favour: * we ease the work of the CD producers to provide a _reasonable_ (installable) snapshot of the ports * if there's a stabilized snapshot newbies will get (hopefully) a softer introduction in the wonders of the Linux-Sparc/Powerpc/Arm/... world Yes, that would be great! And to have all binaries and sources on cd's. Sparc and powerpc are easily setupable per tftpboot and from cd, but powerpc has no (tested!) boot-floppies. The point is not to have all 1500 debian packages available, it must be an easy-to-go system from ground. Is this the case for sparc: goahead! BTW: if sparc uses also linux-2.1.x, you have no kernel images available. MfG, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: PROPOSAL: one debian list for all porting efforts
to increase communication betweenm the ports and between porters and non-porters, I'd propose a new list: debian-porting or sim. I fully support this proposal (The name debian-porting seems fine to me) No, we haven't enough topics for this new list. IMHO, it makes sence to create a new list, since it seems 90% of the Debian developers use i386 only... :-) debian/i386 is also a port! MfG, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
There's been a lot of porting going on for Alpha, however, I can't really say that the number of packages that need to be ported to Alpha has been decreasing since the freeze; every time 20 packages are uploaded for Alpha, there are 22 new packages for i386 :-( Thats the reason for needing more time as two weeks after the deadline!! Minumum are four weeks! Bye, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *** The Upcoming Release of Hamm ***
Can I propose the following ? When we get into this state we announce an `early beta' and delay the release for at least a further two weeks to see if any more release-necessary bugs arise, or if there is discussion about the status of a bug. Make it harder! From now on no new upstream versions to frozen. Cleaning Incoming. 1. May is 'early beta' and 1. June is release time (to have some more time for arch maintainers and testers). Is this to hard? Bye, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GGI first release
On Jan 8, James A.Treacy wrote: Now that they have something running, one thing I'd like to know is how fast it is. Have they done any tests comparing it to XFree86? Or against the video stuff in 2.1'er kernels? Console speed, ... Thanks, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New required base packages for Amiga, Atari, ... detection
No, the CPUs are the same in this instance, but the hardware architectures are different. The types of programs that need this systen are hardware I seem to recall that the case in question (it _was_ Atari vs. Amiga, right?) still allowed you to run _the_very_same_kernel_ on both systems. Yes, but then you have both systems included in one kernel and such kernels are big. And i don't know if its always possible (as for two or three years). Bye, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: mgetty Needs Maintainer!
Some time ago, I handed mgetty over to Siggy Brentrup. However, I have not yet seen any mgetty uploaded by him and have not received any response to my e-mails. So...would somebody be willing to take over mgetty? Right now, it doesn't have any maintainer... Hi, i will get it; and i think voice should also included. Mgetty is with the current state of libc - libc6 a little bit hard to test it. But we will see .. Bye, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED] pgpm5waba9Pma.pgp Description: PGP signature
