Re: summary of the Oldenberg d-i debcamp (and release plans)
Quoting Joey Hess ([EMAIL PROTECTED]): (debian-installer status summary in -devel and -boot. -i18n and -l10n-french added to CC) > Finally, and most important, we need a plan for how we will prepare d-i > for the first test cycle. So we tried to come up with one. This was > probably the hardest question of the whole meeting, and this is only a > provisional plan. .../... At which step do you think that all "to be translated" stuff will be frozen ? The translations teams are currently running after the d-i team changes, with the help of Denis Barbier's scripts, but this is currently a constant work as many templates often change even for minor things. Of course, there are perfectly valid reasons for the changes (and I even have some myself : for instance the use of 1st person in templates which I don't find really "professionnal")but a freeze is needed here, I think. Speaking for the french team, on behalf of its "leaders", Denis Barbier and Martin Quinson (as well as Pierre Machard who commits the changes in d-i CVS), we probably need about one week after templates freeze for making a very final review and commiting the changes to fr.po files This may differ for other teams, which have often far less contributors PS : I'll temporarily subscribe to debian-boot so that following all this become easier for me. I guess Pierre Machard and Denis Barbier are also subscribers to this list. Some other l10n teams members should probably try to follow -boot for a while, I guess, if that's not already done.
Re: Buildd's using really old packages
On Tue, Sep 30, 2003 at 11:25:50PM -0500, Chris Cheney wrote: > I noticed while verifying that the buildds weren't still using the buggy > g++ 3.3.2-0pre4 that some are using 3.3.2-0pre1 which is 6 weeks old. Is > there a particular reason some of the buildds are so out of date? They must be manually updated from time to time, unless some package build-depends on a more recent compiler than the one that is installed. Also, in some circumstances, they are deliberately not updated if a newer version of the toolchain is known to cause problems. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: d-i milo missing (might have fix)
On Tue, 30 Sep 2003 13:46:33 -0400 Greg Folkert <[EMAIL PROTECTED]> wrote: > > I have a DEC Alpha 1000/4 and a DEC Alpha 2100/4 (sable) that could be > stand a linux install on them. . > The 2100 would be the nasty one to get it to work on. They both > require milo, the sable has never booted linux "proper" ever, as it's > is the "early version" I know next to nothing about alphas other then, that I got a AlphaServer 2100 4/233 from my father-in-law once. Which I installed debian on quite easily with aboot... Not that I want you not to spend time on MILO, but I thought I'd tell you. grts Tim
Bug#213609: general: iproute2 on Woody is not patched to be used with HTB
Package: general Version: 20031001 Severity: normal -- System Information Debian Release: 3.0 Kernel Version: Linux poseidon 2.4.21 #2 SMP Tue Sep 30 13:03:12 ART 2003 i586 unknown
Re: Pavilion 04
How can I remove file from Outlook Express ? Eleanor
Bug#213638: ITP: wallpaper-tray -- A wallpaper changing utility for your GNOME Notification Area
Package: wnpp Severity: wishlist * Package name: wallpaper-tray Version : 0.4.0 Upstream Author : Gareth Foster <[EMAIL PROTECTED]> * URL : http://earthworm.no-ip.com/wp_tray/ * License : GPL Description : A wallpaper changing utility for your GNOME Notification Area This utility sits in your GNOME Panel Notification Area. It sets a random wallpaper from a list of directories eith at login, on a regular basis or on demand. I've got a standards compliant package here waiting to be uploaded, i just want to check the upstream developer is happy. Cheers, Rob
Re: d-i milo missing (might have fix)
On Wed, Oct 01, 2003 at 10:27:01AM +0200, Tim Dijkstra wrote: > On Tue, 30 Sep 2003 13:46:33 -0400 > Greg Folkert <[EMAIL PROTECTED]> wrote: > > > > I have a DEC Alpha 1000/4 and a DEC Alpha 2100/4 (sable) that could be > > stand a linux install on them. . > > The 2100 would be the nasty one to get it to work on. They both > > require milo, the sable has never booted linux "proper" ever, as it's > > is the "early version" > I know next to nothing about alphas other then, that I got a AlphaServer > 2100 4/233 from my father-in-law once. Which I installed debian on > quite easily with aboot... > Not that I want you not to spend time on MILO, but I thought I'd tell you. There are three reasons why using MILO may be necessary: - there's no version of SRM for your subarch - you need to dual-boot with WinNT (hah!) - you need the PC BIOS emulation features of ARC If none of these apply, then certainly, SRM+aboot is the way to go. -- Steve Langasek postmodern programmer pgpVclM7QU2uv.pgp Description: PGP signature
Re: d-i milo missing (might have fix)
On Wed, 1 Oct 2003 13:01:57 -0500 Steve Langasek <[EMAIL PROTECTED]> wrote: > On Wed, Oct 01, 2003 at 10:27:01AM +0200, Tim Dijkstra wrote: > > On Tue, 30 Sep 2003 13:46:33 -0400 > > Greg Folkert <[EMAIL PROTECTED]> wrote: > > > > > > I have a DEC Alpha 1000/4 and a DEC Alpha 2100/4 (sable) that > > > could be stand a linux install on them. . > > > The 2100 would be the nasty one to get it to work on. They both > > > require milo, the sable has never booted linux "proper" ever, as > > > it's is the "early version" > > > I know next to nothing about alphas other then, that I got a > > AlphaServer 2100 4/233 from my father-in-law once. Which I installed > > debian on quite easily with aboot... > > Not that I want you not to spend time on MILO, but I thought I'd > > tell you. > > There are three reasons why using MILO may be necessary: > > - there's no version of SRM for your subarch > - you need to dual-boot with WinNT (hah!) > - you need the PC BIOS emulation features of ARC > > If none of these apply, then certainly, SRM+aboot is the way to go. Ahh, never realized somebody would want WinNT ;) thanks for the explanation, Tim
local Release
I need to install debian unstable on certain machines. I have a mirror for this but I want some packages from testing, like galeon or smbclient. also I have my own packages. so I made a new 'release' called 'frankie', where I have my apps debs and symlinks to the versions I want from testing. I built a Packages.gz and Release files, added the deb line to sources.list, apt-get gets everything, no complain... *but*... now I set up atp.conf to have 'frankie' as the default release, but when I try to install galeon, it tries to get the unstable ones. if I try to get the frankie version w/ 'apt-get install galeon/frankie' I get: E: Release 'farnkie' for 'galeon' not found any hints? please cc: me, as I'm not subscibed to the list.
Re: local Release
Marcos Dione <[EMAIL PROTECTED]> wrote: [...] >*but*... now I set up atp.conf to have 'frankie' as the default > release, but when I try to install galeon, it tries to get the unstable > ones. if I try to get the frankie version w/ 'apt-get install > galeon/frankie' I get: > E: Release 'farnkie' for 'galeon' not found >any hints? >please cc: me, as I'm not subscibed to the list. Provide a Release file (in the same location as Packages.gz). Take a look at your favorite Debian mirror for examples. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Bug #213524
Hi, bug #213524 on automake has the potential to hit a lot of packages in a way that they become uninstallable. So far, diff, indent and nano have been affected, but there might be more to come. What could be done to limit the damage? --jcohen
Re: Bug #213524
On Wed, Oct 01, 2003 at 11:49:18PM +0200, Jochen Friedrich wrote: > bug #213524 on automake has the potential to hit a lot of packages in a > way that they become uninstallable. So far, diff, indent and nano have > been affected, but there might be more to come. > > What could be done to limit the damage? Fix install-info --version to use stdout, for example? At least I don't see the link between version information and errors... The automake maintainer should clone and and reassign the bug to dpkg. -- 2. That which causes joy or happiness.
Re: local Release
On Wed, Oct 01, 2003 at 11:34:10PM +0200, Andreas Metzler wrote: > Marcos Dione <[EMAIL PROTECTED]> wrote: > [...] > >*but*... now I set up atp.conf to have 'frankie' as the default > > release, but when I try to install galeon, it tries to get the unstable > > ones. if I try to get the frankie version w/ 'apt-get install > > galeon/frankie' I get: > > > E: Release 'frankie' for 'galeon' not found ^^^ yes, I did mispelled that one; was copied by hand... > Provide a Release file (in the same location as Packages.gz). Take a > look at your favorite Debian mirror for examples. Yes, I have one... it's: [EMAIL PROTECTED]:~$ cat /var/www/local/dists/frankie/main/binary-i386/Release Archive: frankie Component: main Origin: Credicoop Label: Debian Architecture: i386 anything wrong?
Re: Bug #213524
Jochen Friedrich <[EMAIL PROTECTED]> writes: > bug #213524 on automake has the potential to hit a lot of packages > in a way that they become uninstallable. So far, diff, indent and > nano have been affected, but there might be more to come. Ah! I've recently noticed that a recent install didn't seem to have odd info files missing from /usr/share/info/dir (in some cases even though I'd installed the package that day). This bug sounds like it's the one responsible. (Well, the change in behaviour of Debian's install-info, anyway.) > What could be done to limit the damage? No idea. It's annoying, however. Much more serious if packages are actually uninstallable, of course, although I haven't noticed that yet. Is there some way to rebuild /usr/share/info/dir?
Re: 2.5/2.6 IPsec stack should live in a kernel-patch!
On Wed, Oct 01, 2003 at 05:38:51PM -0500, Steve Langasek wrote: > [ObPrivate: this doesn't belong on private. Quote me freely.] > > On Wed, Oct 01, 2003 at 11:56:14PM +0200, martin f krafft wrote: > > > Thus I propose that Herbert should remove the IPsec patch and make > > it a separate kernel-patch. If anyone has other objections than "I > > won't do it because it's my choice, I don't feel like it, and there > > is nothing you can do about it", then please speak up. On the other > > hand, if you agree with me, let your voice be heard! > i'm interested only in the debian kernel without 2.5/2.6 IPsec. in my mind this should be vanilla kernel + debian fixes. ... > If you want this inter-developer dispute to be taken *seriously*, that > is most likely a matter for the technical committee (debian-ctte). > i vote for this bye -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: 2.5/2.6 IPsec stack should live in a kernel-patch!
On Thu, 2 Oct 2003 01:38:45 +0200 [EMAIL PROTECTED] (Domenico Andreoli) wrote: > On Wed, Oct 01, 2003 at 05:38:51PM -0500, Steve Langasek wrote: > > [ObPrivate: this doesn't belong on private. Quote me freely.] > > > > On Wed, Oct 01, 2003 at 11:56:14PM +0200, martin f krafft wrote: > > > > > Thus I propose that Herbert should remove the IPsec patch and make > > > it a separate kernel-patch. If anyone has other objections than "I > > > won't do it because it's my choice, I don't feel like it, and > > > there is nothing you can do about it", then please speak up. On > > > the other hand, if you agree with me, let your voice be heard! > > > i'm interested only in the debian kernel without 2.5/2.6 IPsec. in my > mind this should be vanilla kernel + debian fixes. > But 2.5/2.6 include IPSEC in the vanilla kernel! Jim Penny
ITP swiss-ephemeris
Package: wnnp Severity: normal Package name: swiss-ephemeris Version : 1.6.6 Upstream Author : Dieter Koch and Dr. Alois Treindl <[EMAIL PROTECTED]> URL : ftp://www.astro.ch/pub/swisseph License : DFSG-free I think, see below Description : Ephemeris of Astronomical/Astrological data The Swiss Ephemeris is a function package for the computation of planetary positions. It includes the planets, the moon, the lunar nodes, the lunar apogees, the main asteroids, Chiron, Pholus, the fixed stars and several "hypothetical" bodies. Hundreds of other minor planets are included as well. The precision of the Swiss Ephemeris is very high. It is at least as accurate as the Astromical Almanac, the standard planetary and lunar tables astronomers refer to. The data for 1800-2200 AD is also included. Here is the license: Included below is draft version 0.2 of the license that we are currently using for the Swiss Ephemeris Free Edition. The license is called the Swiss Ephemeris Public License (or "SEPL"), and qualifies as an Open Source license. It is thus appropriate for people wishing to write software under the Open Source model where all source code to the software is made available to all users and can be freely modified and redistributed. To develop software with the Swiss Ephemeris Free Edition, simply meet the requirements in the SEPL. Your software can be licensed by any license that permits the requirements in section 6. If you do not meet the requirements in the SEPL, for example if - you develop and distribute software which is sold for a fee higher than a reasonable copy charge - or/and you develop and distribute software which is not published under an Open Source or equivalent license you must purchase the Swiss Ephemeris Professional Edition under the Swiss Ephemeris Professional License. Comments to the license: 'Legally' developed in #5 means either developed under this license, #6, or under a professional license. THE SWISS EPHEMERIS PUBLIC LICENSE (SEPL) version 0.2 Copyright (C) 1998 Astrodienst AG, Switzerland. Everyone is permitted to copy and distribute this license document. This license applies to any software containing a notice placed by the copyright holder saying that it may be distributed under the terms of the SEPL version 0.2. Such software is herein referred to as the Swiss Ephemeris Software (SE). This license covers modification and distribution of the SE, use of third-party application programs based on the SE, and development of free software which uses the SE. Granted Rights 1. You are granted the rights set forth in this license provided you agree to any and all conditions in this license. Whole or partial distribution of the SE in any form signifies acceptance of this license. 2. You may copy and distribute the SE provided that the entire package is distributed, including this License. 3. You may make modifications to the SE files and distribute your modifications in a form distinct from the SE. The following restrictions apply to modifications: a. Modifications must not alter or remove any copyright notices in the SE. b. If modifications to the SE are released under this license, a non-exclusive right is granted to the holder of the copyright of the unmodified SE to distribute your modification in future versions of the SE provided such versions remain available under these terms in addition to any other license. 4. You may distribute machine-executable forms of the SE or machine-executable forms of modified versions of the SE, provided that you meet these restrictions: a. You accompany the SE with this license. b. You must ensure that all recipients of the machine-executable forms are also able to receive the complete machine-readable source code to the distributed SE, including all modifications, without any charge beyond the costs of data transfer. c. You ensure that all modifications included in the machine-executable forms are available under the terms of this license. 5. You may use the original or modified versions of the Swiss Ephemeris Software to compile, link and run application programs legally developed by you or third parties. 6. You may develop application programs, reusable components and other software items that link with the original or modified versions of the Swiss Ephemeris Software. These items, when distributed in machine-executable form, have the following restrictions: a. You must ensure that all recipients of machine-executable forms of these items are also able to receive and use the complete machine-readable source code to the items without any charge beyond the costs
