Debian 3.1r0 CD/DVD image problem
A bug has been discovered in the 3.1r0 CD/DVD images: new installs from these images will have a commented-out entry in /etc/apt/sources.list for http://security.debian.org/ testing/updates rather than an active entry for http://security.debian.org/ stable/updates, and thus will not get security updates by default. This was due to incorrect Release files on the images. If you have already installed a system using a 3.1r0 CD/DVD image, you do not need to reinstall. Instead, simply edit /etc/apt/sources.list, look for any lines mentioning security.debian.org, change testing to stable, and remove # from the start of the line. If you installed other than from a CD or DVD (for example, netboot, or booting from floppy and installing the base system from the network), you are not affected by this bug. New 3.1r0a images will be available shortly to correct this flaw. In the meantime, CD vendors should delay pressing CDs or DVDs of Debian 3.1. We apologise for the inconvenience. -- Colin Watson [EMAIL PROTECTED] Debian Release Team signature.asc Description: Digital signature
Re: Client P2P dans Sarge
Ça semble aussi prouver qu'on n'a toujours pas assimilé que le p2p est un fantastique système de cluster de serveurs de fichiers. Qu'on n'est Oui, probablement. Le manque d'attention à la maintenance des logiciels clients de P2P semble le prouver. Et il y a encore un sacré boulot à faire avant que les images ISO de Debian soient plus distribuées par P2P que par téléchargement bourrin sur les serveurs Debian, à vrai dire. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Client P2P dans Sarge
entièrement d'accord, je viens d'essayer : debian sarge sur - la mule : 7 fichiers, 5 complets, 5 sources - bittorrent : 3 moteurs de recherche, 1 réponse 1 feeder... absent. donc effectivement, avec un lien bittorrent directement sur les serveurs d'isos pour cliquer dessus, ça serait plus facile ;-) Alain Message d'origine Date: Tue, 7 Jun 2005 09:17:43 +0200 A: debian-devel-french@lists.debian.org Sujet: Re: Client P2P dans Sarge De: Martin Quinson [EMAIL PROTECTED] On Tue, Jun 07, 2005 at 08:25:36AM +0200, Christian Perrier wrote: Ça semble aussi prouver qu'on n'a toujours pas assimilé que le p2p est un fantastique système de cluster de serveurs de fichiers. Qu'on n'est Oui, probablement. Le manque d'attention à la maintenance des logiciels clients de P2P semble le prouver. Et il y a encore un sacré boulot à faire avant que les images ISO de Debian soient plus distribuées par P2P que par téléchargement bourrin sur les serveurs Debian, à vrai dire. Ben, si ca marchait en cliquant sur le lien betement depuis mon navigateur, je le ferais volontier. Mais là, faut réfléchir. Trop dur. Mt. Alain Cabiran [EMAIL PROTECTED] =
Re: Re: Client P2P dans Sarge
Le mardi 07 juin 2005 à 20:29 +0200, [EMAIL PROTECTED] a écrit : entièrement d'accord, je viens d'essayer : debian sarge sur - la mule : 7 fichiers, 5 complets, 5 sources - bittorrent : 3 moteurs de recherche, 1 réponse 1 feeder... absent. donc effectivement, avec un lien bittorrent directement sur les serveurs d'isos pour cliquer dessus, ça serait plus facile ;-) Par exemple, http://www.debian.org/CD/torrent-cd/ ? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Ports helping in World Domination? (was: Re: Canonical and Debian)
Quoting Julien BLACHE ([EMAIL PROTECTED]): Eh, to achieve Total World Domination, we need to support every architecture out of there. Looks like a step in the wrong direction ;) Well, frankly speaking, Julien, last time I checked most of so-called third world users mostly just don't care a shit of non i386 architectures..:-). They just want a functional operating system for the only architecture which is really available to them, no matter whether we like it or not. (oh, yes, I'm also aware of the ARM-based projects in India for very low entry-point computers...and, yes, I know that some exotic hardware lies in several black boxes) Not saying that Debian should focus on i386 systems. Just bringing us back to some reality.m68k, mips, mipsel ports are part of our patrimony and being a universal OS is part of Debian specifiticy and richnessbut we really shouldn't tell that it helps in world domination. And, no, I'm not throwing mud at these. Just reminding us a few facts, maybe : being able to run Debian on an Amiga doesn't help much in world domination. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of interface names (eth*, dummy*, ath*, tap*)
On Mon, Jun 06, 2005, Florian Weimer wrote: See nameif(8). Interface names can be chosen by the user. Hmm, no much point in preparing an interface name list indeed. If some drivers name where bound to this interface names, it would be quite complicated anyway. I'm going to propose upstream to look for a default route in the main table, and if none exist, select the first UP interface. Thanks,, -- Loïc Minier [EMAIL PROTECTED] Neutral President: I have no strong feelings one way or the other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
German newsticker announcements and architectures
Hi, I checked heise.de and golem.de for Sarge announcement. I just want to let you know that both news tickers stress out that Debian runs on 11 architectures which makes a difference to other distributions. I do not want to heat another Vancouver flamewar but I hope that the same news tickes do not start the Etch announcement with sentences like: Unfortunately Debian dropped the effort of supporting many architectures. but instead Even if only X architectures are in the main focus Debian struggles hard to continue the support of other not so common ones. or something like that. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of interface names (eth*, dummy*, ath*, tap*)
* Loïc Minier: On Mon, Jun 06, 2005, Florian Weimer wrote: See nameif(8). Interface names can be chosen by the user. Hmm, no much point in preparing an interface name list indeed. If some drivers name where bound to this interface names, it would be quite complicated anyway. I'm going to propose upstream to look for a default route in the main table, and if none exist, select the first UP interface. Which problem are you trying to solve, exactly? Looking at the routing table (which one?) is never a good idea.
Re: Re: Release update: minor delay; no non-RC fixes; upgrade reports
Hah...document a distribution's bugs in a wiki page is one funny idea that Knoppix used at the time I still used it, about a year ago. And it was one major reason I didn't wait to switch to Debian. It can be considered for tracking RC issues, but Roger still has a point that all bug reports may be useful doc for users. Plus, it's being honest about the real current state of the software (again to users). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312293: ITP: cl-utilities -- a Common Lisp library of common functions
Package: wnpp Severity: wishlist Owner: Peter Van Eynde [EMAIL PROTECTED] * Package name: cl-utilities Version : 1.1 Upstream Author : Peter Scott * URL : http://common-lisp.net/project/cl-utilities/ * License : public domain Description : a Common Lisp library of common functions This package provides a library of semi-standard functions that are otherwise re-implemented in many projects. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.10-my7 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Storage (was: Canonical and Debian)
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: That sounds retarded in an age where a 200GB HD cost less then 100 Euro... Regarding storage: Fast, cheap and secure; pick any two. Good Storage have more costs than the price of the cheapest disks on the market. For a file server, especially a software mirror for Internet users, you'll want fast and secure, you can't have cheap. Sorry. :P -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 03:21, Joey Hess wrote: Planned, and ground already laid in tasksel (and indeed, it does do it for some easy things like language tasks). One thing I really want to see happen is a laptop task. The big missing peice is some simple program tasksel can call out to, like if this_is_a_laptop; then .. fi This should use whatever hardware probing works best for laptops. This sounds like a good idea, but will need very careful logic. For instance, some older (APM-based) Toshiba laptops work well with the toshiba module and the toshset package where newer (ACPI-based) laptops need the toshiba-acpi module which does not work with toshset. I would suspect that similar distinctions exist for other makes. I'm interested in other ideas for automatic selection of default tasks. One thing I feel is currently missing is to show users which tasks have been automatically selected and the option to deselect them (maybe only at medium or lower priority). Which brings me to another pet wish: make it a lot easier to install at medium priority than currently. IMO there is a real use for medium priority: - experienced users now often choose expert and get confused by some of the informational dialogs (especially the unavailable drivers one) - for users installing for the first time the no dhcp boot option and such are not really obvious, medium priority can be used to offer useful freedom in a structured way keeping expert for difficult hardware pgpNsdIZI6dAN.pgp Description: PGP signature
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
Le mardi 07 juin 2005 à 05:10 +0200, Nicolas Schoonbroodt a écrit :
MMmmm these are good news :-),
If you can tell me where you find the tex2im depandancy (README,
INSTALL, ...) It can help me for remove it in the next version.
Well, I've just looked into your files.
I can now said that I've made a mistake. You're plugin seems to doesn't
use tex2im now.
But I know what makes me missunderstand :
in README file :
README:This is a plugin for Gaim [1] that allows you to display LaTeX
[2] output into your IMs. This plugin needs the tex2im tool [3].
Now, about the security problem...
(...)
I have blacklisted the same command than kopetetex, that is :
#define NB_BLACKLIST (42)
#define BLACKLIST
{\\def,\\let,\\futurelet,\\newcommand,\\renewcomment,\\else,\\fi,\\write,\\input,\\include,\\chardef,\\catcode,\\makeatletter,\\noexpand,\\toksdef,\\every,\\errhelp,\\errorstopmode,\\scrollmode,\\nonstopmode,\\batchmode,\\read,\\csname,\\newhelp,\\relax,\\afterground,\\afterassignment,\\expandafter,\\noexpand,\\special,\\command,\\loop,\\repeat,\\toks,\\output,\\line,\\mathcode,\\name,\\item,\\section,\\mbox,\\DeclareRobustCommand}
Great :-)
Why not define a WHITELIST instead of a BLACKLIST ? isn't it more
secured ?
So (in normal case) all of this command will not be authorised
(in fact, if you send a message like :
normal text \input in normal text $$equation$$ normal text $$equation $$
(or with the blacklisted command in the $$equation part$$) the message
_will not_ be transform using latex compiler. (with the is_blacklisted
function)
Ok thanks
If some other command have to be blacklisted, I hear you.
Well, I don't know LaTeX enough to gives you more commands (if there's
any)
If you have any suggestion with security problem (for example error in
my code, or latex hack to eviter (french word, don't know in English)
avoid no ? ;-) but I'm french too so it's not a problem for me to
understand
this security), you can continue the discussion here, I will read it.
Also other bug can be posted on sourceforge, for example.
Ok, I think we can know close my bug report on sourceforge no ?
Nicolas Schoonbroodt
Thank you very much for your help,
I hope I will be able to package it in Debian
--
Martin Braure de Calignon
(error3)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312269: ITP: emile -- Early Mac Image LoadEr, a bootloader for m68k macs
On Mon, 06 Jun 2005 23:50:46 +0200, Wouter Verhelst wrote: Owner: Wouter Verhelst [EMAIL PROTECTED] * Package name: emile Description : Early Mac Image LoadEr, a bootloader for m68k macs Thank you very much for finally deciding to package emile. I will be expecting eagerly the moment when I'll be able to purge the proprietary OSes from my machines. Keep the good work! -- Yavor Doganov Free Software Association - Bulgaria GNUstep Bulgarian Translation Project GNOME Bulgarian Translation Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 08:56, Frans Pop wrote: On Tuesday 07 June 2005 03:21, Joey Hess wrote: Planned, and ground already laid in tasksel (and indeed, it does do it for some easy things like language tasks). One thing I really want to see happen is a laptop task. The big missing peice is some simple program tasksel can call out to, like if this_is_a_laptop; then .. fi This should use whatever hardware probing works best for laptops. Another item that might be worth considering for laptops is a networking equivalent of the pmount group. People in these groups would be allowed to edit the network files (in particular /etc/network/interfaces) and bring interfaces up and down. Obviously on servers and corporate desktops this group would be empty or contain only system admins, but on a laptop you have to be able to fit into the network you are presented with and you do not want joe-user to be switching to root all the time just in order to do these functions. I realise that this would require fixes to a number of packages, and quite possibly some additional code to give a graphical interface to the /etc/networking/interfaces file would be a good idea for GUI only users and those who might not understand the consequences of incorrectly coded entries and need a program to do it for them. David This sounds like a good idea, but will need very careful logic. For instance, some older (APM-based) Toshiba laptops work well with the toshiba module and the toshset package where newer (ACPI-based) laptops need the toshiba-acpi module which does not work with toshset. I would suspect that similar distinctions exist for other makes. I'm interested in other ideas for automatic selection of default tasks. One thing I feel is currently missing is to show users which tasks have been automatically selected and the option to deselect them (maybe only at medium or lower priority). Which brings me to another pet wish: make it a lot easier to install at medium priority than currently. IMO there is a real use for medium priority: - experienced users now often choose expert and get confused by some of the informational dialogs (especially the unavailable drivers one) - for users installing for the first time the no dhcp boot option and such are not really obvious, medium priority can be used to offer useful freedom in a structured way keeping expert for difficult hardware -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PostgreSQL transition ahead
(Sorry if you got this mail several times, I just CC'ed it to every affected binary package). Hi fellow Debian developers! Three months ago I announced the first alpha versions of the new architecture of the PostgreSQL packages [1] in experimental. Now, a few months later, they are mature enough to be used in actual production environments. In addition, Sarge is out of the door (YAY!), so it's high time to break unstable again. :-) The packages have lived in Debian experimental for a while now and are tested by several people (who also write bug reports). Currently they have no open bugs and support all the features that the Sarge version did. However, the new structure is much easier to maintain and develop, and also offers many new features for users (multi-version, multi-cluster, painless upgrades, see [2]). I will upload the new packages to unstable very soon. This has a reasonably big impact to all packages that depend/build-depend on PostgreSQL since the package structure changed a bit: (1) postgresql-dev was split into libpq-dev (for client apps like postfix or pygresql) and postgresql-server-dev-version for server extensions (like postgresql-plruby and postgresql-ocaml). (2) PostgreSQL 8.0 brought a new SONAME for libpq (libpq4), which removed a few symbols which were only intended for internal use, but were used nevertheless by some client apps (like psql). libpq4 can talk to all PostgreSQL servers back to 7.3 (same like libpq3). (1) makes all packages FTBFS that build-depend on postgresql-dev (I CC'ed all affected packages). These need to be changed to depend on libpq-dev, and make buildable again. This will automatically care for (2) since libpq-dev makes the package depend on libpq4 then. The steps to adapt a client-side application to the new structure are: 1. Change the build-dependency postgresql-dev to libpq-dev. 2. Fix include directory path: - Very few packages use pg_config to determine include and library directories (e. g. pygresql). In this case no additional changes should be required any more. pg_config has been there for ages, but apparently nobody bothered to use it. - If the package does not use pg_config, then the ideal solution is to convert it to do so. This is easily possible for almost all packages (e. g. in debian/rules, add a configure option like --with-pgsql-include=`pg_config --includedir`). - If the packaging hardcodes include paths and has a crappy build system (cyrus-sasl2 was a pretty nonstandard one), then the quick fix is to hardcode the path for now (/usr/include/postgresql/8.0); however, this is not very robust, and it would be nice to eventually convert the package to use pg_config. 3. Test build. As a rule of thumb, if the package builds, it works. libpq-dev mainly changed paths and has a new library SONAME behind (libpq4), but the client library did not change any interface and thus should be fully backwards compatible. 4. Upload. :-) I already did these steps for a fair number of packages. So if you maintain one of the packages that have a debdiff at [3], you are lucky and only need to apply the patch there (however, cyrus-sasl2 and dovecot were nasty cases where the path has been hardcoded for now; this should be improved). The debdiffs were made for Ubuntu packages since I could upload them straight away. So the changelog patch will fail to apply, but the rest should be fine. The server-side packages are more delicate, though. Ideally they would be repackaged to build a module for all supported PostgreSQL versions (i. e. postgresql-7.4-plr, postgresql-8.0-plr, and so on). I will finish plr soon to show an example of how this is supposed to look like. Peter Eisentraut will package PL/Java soon. If you maintain such a package, please consider subscribing to [4] to coordinate the effort. Although the new packages will make all the client packages FTBFS, I will upload them to unstable soon, because: * The already built client app debs will just continue to work. * There is a clean upgrade path from the old postgresql package to the new one (just dist-upgrade). * Sid will be broken for a fair amount of time anyway since there are more transitions ahead of us (g++ 4.0, dbus, etc.) This mail already became longer than intended, so if you have any question, please contact [4] or me personally. Thanks and have a nice day! Martin [1] http://lists.debian.org/debian-devel/2005/03/msg01858.html [2] http://people.debian.org/~mpitt/postgresql-ng.html [3] http://people.ubuntu.com/~pitti/postgresql-transition/ [4] http://lists.alioth.debian.org/mailman/listinfo/pkg-postgresql-public -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 01:03, Javier Fernández-Sanguino Peña wrote: Feel free to add some new items or add (hopefully new) information to the ones I list below: -- [ Overall improvements ] - Implement some package reorganizations that have been postponed over several releases; example: #100332: tetex-bin: please move xdvi to its own package pgpcZfdXQ1b3d.pgp Description: PGP signature
Re: And now for something completely different... etch!
On 2005-06-07 04:57, Grzegorz B. Prokopski wrote: On Tue, 2005-07-06 at 01:03 +0200, Javier Fernández-Sanguino Peña wrote: - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5 Do we really need that? I thought I could always enable/disable/install/remove [xgk]dm. And are these runlevels mandated (or at least documented) by any standard (besides 'the RH way')? Are they at least consistent among ~all distros besides Debian? If we're gonna change this, could we please use the LSB definition [1]? [1] http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/runlevels.html -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam)
Re: libselinux1 - required
* Luke Kenneth Casson Leighton ([EMAIL PROTECTED]) [050607 02:01]: any progress on making libselinux1 a Required package? the possibility of having debian/selinux is totally dependent on this one thing happening. no libselinux1=Required, no debian/selinux [all dependent packages e.g. coreutils will be policy violations]. Sorry, but it only works the other way around. And, BTW, please give us at least some hours to recover after the release, before heading of to etch in that way :) Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Storage (was: Canonical and Debian)
On Tue, Jun 07, 2005 at 09:47:23AM +0200, Stig Sandbeck Mathisen wrote: Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: That sounds retarded in an age where a 200GB HD cost less then 100 Euro... Regarding storage: Fast, cheap and secure; pick any two. Good Storage have more costs than the price of the cheapest disks on the market. For a file server, especially a software mirror for Internet users, you'll want fast and secure, you can't have cheap. For lightly used archives, secure and cheap are more important then fast. So I pick secure and cheap in that case. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Storage (was: Canonical and Debian)
* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050607 10:51]: On Tue, Jun 07, 2005 at 09:47:23AM +0200, Stig Sandbeck Mathisen wrote: Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: That sounds retarded in an age where a 200GB HD cost less then 100 Euro... Regarding storage: Fast, cheap and secure; pick any two. Good Storage have more costs than the price of the cheapest disks on the market. For a file server, especially a software mirror for Internet users, you'll want fast and secure, you can't have cheap. For lightly used archives, secure and cheap are more important then fast. So I pick secure and cheap in that case. Actually, AFAI understood it, the issue is _not_ the hard disc, but the network traffic for mirroring all archs. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
On Mon, Jun 06, 2005 at 10:48:56PM -0400, Kevin Mark wrote: On Mon, Jun 06, 2005 at 05:11:44PM -0400, Stephen Frost wrote: * Colin Watson ([EMAIL PROTECTED]) wrote: On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote: * Steve Langasek ([EMAIL PROTECTED]) wrote: snip Perhaps that issue needs to be brought up more directly with the porters then, if possible. ie: Put a request out there for porters to check over what packages havn't been built for their architecture? I'm not entirely sure if that could really be easily extracted out seperately from what a buildd admin does (which would imply that we *do* need more buildd admins if only to help with this not-directly-answering-buildd- emails issue). Also, doesn't 'get required package uploads built everywhere' imply 'ask the buildd admins what the story wrt a current package is', at least in some cases? It would seem that if it's possible to decrease the turn-around time on that it'd be of some benefit... Hi Stephen etc., IIUC, this is a summary: make source, build package, upload i386 deb to incomming, tell wanna-build, [build on buildd, upload non-i386 deb to incomming] repeat for all archs Is the issue: 1) buildd availability (network or amount) That's not usually an issue. 2) buildd admin responcivness, Not commenting on this one, since I'm a buildd admin myself and one could ay I'm biased :-) 3) arch-specific issues that cause build problems for non-i386 not getting fixed? (would that be the 'porters' job?) It depends. If it fails to build because of an incorrect assumption (e.g., one regarding char signedness, endianness, whatever), I'd say it's a bug in the package and thus a job for the package maintainer. If it fails to build because of a bug in the toolchain, it would probably be a job for the toolchain maintainers and the porters. 4) buildd software issues(pbuild,sbuild,wanna-build,etc) Not relevant. Whether you have 2 architectures or 25, you'll always need to maintain sbuild, wanna-build, buildd. TTBOMK, there is no such thing as 'pbuild'; assuming you mean 'pbuilder', that is not part of the wanna-build suite and not used in autobuilding. 5) something else? Most likely. The RMs have stated a few times now that maintaining a distribution with 11 architectures gives them a headache. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond signature.asc Description: Digital signature
Re: Canonical and Debian
On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote: * Steve Langasek ([EMAIL PROTECTED]) wrote: Clone yourself and make yourself a slave to the buildds for 7 or 8 architectures, so that the release team doesn't have to. Neither the Whoah, whoah, whoah, is this actually an option? Last I checked that answer was 'no'. Well, I think there's still a moratorium on human cloning in the US, isn't there? There seems to be a few different reasons for this, but one of the big ones is wanna-build access, I believe. This is because of limitations of the current wanna-build framework, which may have now been resolved? I wasn't necessarily referring to being buildd admins. The biggest time sink, AIUI, is keeping machines of reasonable power up and running, which ought to be the responsibility of the local admin (porters, presumably); it's not lack of w-b access which causes buildd starvation for those architectures that have that problem. Yes, I imagine the w-b infrastructure's lack of scalability was probably a factor in being choosy about what machines to accept as buildds, but there are certainly going to be other factors that scale linearly with the number of buildds, so I don't foresee the w-b admins ceasing to concern themselves with getting the most bang per buildd. But while everyone's fretting over whether the w-b admins will allow m68k buildd #15 to connect, we have the following architecture problems right now, in no particular order: - alpha: one buildd, able to keep up with current package volume; no spare buildd due to the principal candidate being inexplicably unbootable now (oh yeah, btw, the primary failed and was off-line for a day, a week before release); no porter machine available. - hppa: one buildd, keeps up with package volume, but no backup buildd and gdb seems to kill its kernel (yay); one porter machine. - sparc: one buildd which is not consistently able to keep up with the volume of incoming packages; no backup buildd, no additional porter machine. - s390: one buildd, which consistently cannot build gtk+2.0 because it only has 2GB of space available for builds and gtk+2.0's requirements have recently exceeded this; a second possible buildd is not yet hooked into w-b because of what appear to be administrative details. (two porter machines available, though.) - powerpc: one buildd that's getting long in the tooth; one porter machine. (obviously a readily available architecture, but that doesn't really help much if the only configured buildd is down and it takes a week to designate configure a new one.) I have a really hard time believing that these architectures are blocked from adding a second buildd due to security or scalability concerns alone when at the same time we have roughly a dozen m68k buildds... Oh, you'll also note that the traditional slow architectures (mips, mipsel, m68k, arm) aren't on this problems list. That's because a *lot* of effort has been put into providing sufficient parallelization for each architecture; the ongoing cost to *maintain* these parallel buildds is higher than to maintain a single buildd, and given that each of arm, mips, and mipsel have had instances over the past year where they were short-handed, I don't know how realistic it is to expect that they'll stay caught up through etch's lifetime. The second most significant area of concern, for me, is having people being proactive about dealing with per-architecture build failures. There's no particular reason that should be the buildd admins' or the release team's area of responsibility, either; all it requires is people who know what they're doing to file sensible bug reports without gratuitously duplicating efforts, and people who know the architectures to help the maintainers sort out bugs. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote: On Jun 07, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: - _No_ bugs in base packages (well, at least no old bugs). Base system should be upgraded to latest upstream (forward patches!) this includes PAM, modutils... In my wishlist there is NO support of 2.4 kernels, so modutils would become unneeded. 2.4.x kernels are already obsolete by now except that for some doorstop architectures, I do not know about any other modern distribution which still installs one. Since (at least) potato, Debian has always supported more than one major line of kernels. I don't see why we suddenly would need to change that now. I _do_ agree, however, that 2.2 should be dropped. This might mean having to drop the mac subarch for m68k if the kernel isn't fixed by the time etch releases, but then so be it. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 11:12:50AM +0200, Wouter Verhelst wrote: On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote: On Jun 07, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: - _No_ bugs in base packages (well, at least no old bugs). Base system should be upgraded to latest upstream (forward patches!) this includes PAM, modutils... In my wishlist there is NO support of 2.4 kernels, so modutils would become unneeded. 2.4.x kernels are already obsolete by now except that for some doorstop architectures, I do not know about any other modern distribution which still installs one. Since (at least) potato, Debian has always supported more than one major line of kernels. I don't see why we suddenly would need to change that now. We've done this out of necessity -- *not* because it's a good idea. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Debian
Kern Sibbald wrote: Hello, I've just been looking at the new Debian Sarge release 3.1, and it looks very interesting. I'm not 100% happy with my Fedora FC3 system, so am thinking about loading it here and trying it out. It is quite a learning process though needing a lot of time ... :-) Well, i will be more than happy to help you with that, if you so desire :-) However, in looking through the packages, I see that they distribute just about every backup package that exists, *except* Bacula. Can you tell me why Bacula is not on their list? Sorry, Kern... but which list have you looked up in? (this is so that we can have it corrected as soon as possible) Bacula has indeed been released with Debian 3.1 Sarge: version 1.36.2-2sarge1 [1] or [2] (which is, as you might remember, 1.36.2 with all fixes from 1.36.3 backported to it) If not, can you tell me who I should talk to about resolving any problems they may have with Bacula? There are none, don't you worry. The only problems we had previously (due to license incompatibilities), you solved them very promptly and appropiately, by making a small license change(the exception to allow linking OpenSSL in, even though it is GPL-incompatible); This was almost a year ago. Since then, the only times when Bacula has not been included in the candidate set of packages (the /testing/ distribution) have been those when i had problems solving problems with the auto-configuration scripts; Even then, those were just about three times in the last couple of years [since i packaged and started maintaining Bacula for Debian] In fact, that is the reason why i hardly ever update the DEBs in SourceForge anymore: it is usually much more convenient for users to apt-get them. However, i still upload snapshots when i am satisfied with their quality --which does not happen so often--, so as to have another backup. Thanks. Thank you, indeed, for your contribution to Free Software. This release is a bit better just by including your work, Bacula -- just like it is because of the remaining circa nine thousand packages. Kind regards, José Luis Tallón [1] http://packages.debian.org/bacula [2] http://packages.debian.org/cgi-bin/search_packages.pl? \ searchon=namesversion=allexact=1keywords=bacula -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
On Mon, 6 Jun 2005 20:31:27 +0200, Michelle Konzack [EMAIL PROTECTED] wrote: This is what I not understand, because I have a full /debian-archive and WOODY mirror (including many CDs) and it use 420 GByte (4x 147 GByte) and now, POTATO is gone on ftp://ftp.debian.org/. Now I try to add 4-6 new 147 GByte Drives to mirror WOODY (bin+src+cd) which is around 110 GByte and then SARGE which is around 250 GByte. So, whre is THE problem ? We never released the. And please stop yelling at our releases. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: And now for something completely different... etch!
What about switching from getty to mingetty? Is there any reason to use getty by default? Regards, César
Re: Canonical and Debian
On Monday 06 June 2005 23:02, Marc Haber wrote: On Mon, 6 Jun 2005 20:31:27 +0200, Michelle Konzack [EMAIL PROTECTED] wrote: This is what I not understand, because I have a full /debian-archive and WOODY mirror (including many CDs) and it use 420 GByte (4x 147 GByte) and now, POTATO is gone on ftp://ftp.debian.org/. Now I try to add 4-6 new 147 GByte Drives to mirror WOODY (bin+src+cd) which is around 110 GByte and then SARGE which is around 250 GByte. So, whre is THE problem ? We never released the. Well actually:- apt-cache show the Package: the Priority: optional Section: editors Installed-Size: 808 Maintainer: Alen Zekulic [EMAIL PROTECTED] Architecture: i386 Version: 3.1-4 Depends: libc6 (= 2.3.2.ds1-4), libncurses5 (= 5.4-1), regina3 (= 3.3-1) Suggests: the-doc Filename: pool/main/t/the/the_3.1-4_i386.deb Size: 290744 MD5sum: 858f8f5519767c5872d4ba705fe1d34a Description: Full-screen character mode text editor THE (The Hessling Editor) is a text editor that uses both command line commands and key bindings to operate. It is intended to be similar to the VM/CMS System Product Editor, XEDIT and to KEDIT from Mansfield Software. David And please stop yelling at our releases. Greetings Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Luca - De Whiskey's - De Vitis MIA?
Hi Roberto, On Mon, 06 Jun 2005 at 23:52 -0400, Roberto C. Sanchez wrote: I am wondering what the deal is with Luca and his packages, specifically httperf. [snip] Just wondering what, if anything, should be done. Personally, I would be willing to adopt httperf because I would like to see the bugs fixed. Someone told me a few weeks ago that he is interested in coming back and start again working on his packages. I doubt that this will really happen, and if nobody object the Debian Zope Team will take over his zope packages in a few days. All in all, if he's interested in coming back he could join the team, too. -- Fabio Tranchitella [EMAIL PROTECTED].''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, 07 Jun 2005 01:10:15 +0200, Javier Fernández-Sanguino Peña wrote: Ok, so sarge has been released! We should all thank the Release Team for their hard work in putting this major release together. Yes. Thanks to everyone involved for the many, many hours they devoted to getting sarge into shape. So, without further delay, here's my Etch-wishlist, it's [based] on some of the things I've personally worked on and would like to keep working on for etch. Debian needs to make a release plan. The plan should establish a target release date for etch. Projects on the TODO-for-etch list must then be projects that can be completed within the allotted time. A choice has to be made early on whether to go for a short-term bugfix release or for a longer-term restructuring release. Respective development times would be, say, six months versus eighteen months. I hope that the DPL will get involved in this debate and steer it toward a firm decision. To begin with we can all go back and review: http://wiki.debian.net/index.cgi?ReleaseProposals -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, 07 Jun 2005 10:10:13 +0200, David Goodenough wrote: Another item that might be worth considering for laptops is a networking equivalent of the pmount group. People in these groups would be allowed to edit the network files (in particular /etc/network/interfaces) and bring interfaces up and down. http://people.redhat.com/dcbw/NetworkManager/ -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Japan Debian Mini Conf
Hello, Debian Guys. I feel honer that I announce you Japan Debian Mini Conf. In last year, I held Debian BoF in Kansai OpenSource. (http://k-of.jp) in Japanse language. Any Debian people enjoyed BoF. I also joined Asia Debian Mini Conf. I was excited to contact Great Debian Developers. ADMC infulenced me. Now, I would like to hold Japan Debian Mini Conf(Osaka) in Oct 2005. http://jdmc.k-of.jp/ If you stay Osaka Japan in Oct, You can meet Debian people. See you in Japan. Regards Yukiharu. -- --- Please check - http://www.good-day.co.jp/profile.html#saiyou --- blog - http://blog.good-day.net/~yabuki/diary/ --- Tel 06-4796-6670 FAX 06-4796-7373 --- Yukiharu YABUKI [EMAIL PROTECTED] --- GPG fingerprint = DB64 AF5C 4374 1E43 FA87 37AB 6692 F138 ED43 0BBA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Luca - De Whiskey's - De Vitis MIA?
On Tue, 7 Jun 2005, Fabio Tranchitella wrote: Someone told me a few weeks ago that he is interested in coming back and start again working on his packages. I doubt that this will really happen, and if nobody object the Debian Zope Team will take over his zope packages in a few days. All in all, if he's interested in coming back he could join the team, too. I do not know why you doubt that Luca will come back but as far as I know him from conferences I'm pretty sure that his main interest were good quality Debian packages and because I think the best way to this goal is to take over the packages by the Debian Zope Team he will appreciate your this effort. Did I understand things right that we now start to make Zope 2.7 the default Zope version? [Feel free to answer on zope packaging list which I read as well.] Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
On Tue, Jun 07, 2005 at 02:12:04AM -0700, Steve Langasek wrote: - sparc: one buildd which is not consistently able to keep up with the volume of incoming packages; no backup buildd, no additional porter machine. how powerfull would a machine need to be to be of any help here? would an ultra 10 or a netra x1 be sufficient? cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Canonical and Debian
On Tue, Jun 07, 2005 at 02:12:04AM -0700, Steve Langasek wrote: Oh, you'll also note that the traditional slow architectures (mips, mipsel, m68k, arm) aren't on this problems list. That's because a *lot* of effort has been put into providing sufficient parallelization for each architecture; the ongoing cost to *maintain* these parallel buildds is higher than to maintain a single buildd, Of course. Which is why we m68k people prefer to maintain our dozen buildd machines with 7 people, rather than with just one, as the mips(el) and arm buildd maintainers did, last I heard. However, that is not the only reason. The fact that there are more of us also means there are people readily available in case one of us goes on vacation, or in case an extra build daemon needs to be set up. Provided everyone has access everywhere (or at least mostly everywhere), it also means that urgent problems can be dealt with more speedily, because you don't have to hope that the one person who can fix it happens to be readily available when the buildd chroot breaks completely. There are more merits to a team-based approach; and while there most certainly are downsides (e.g. the fact that you don't see everything, so it's harder to see a pattern when many packages fail to build, and double effort may be spent in that area), I don't think the problems outweigh the benefits. and given that each of arm, mips, and mipsel have had instances over the past year where they were short-handed, I don't know how realistic it is to expect that they'll stay caught up through etch's lifetime. Well, see, I don't think it's a coincidence that m68k did not recently have problems keeping up whereas the other slow architectures did. As you know, m68k buildd maintenance has traditionally been a team-based effort, while it has always been a one-man show on the other architectures. Also, the group of porters and buildd maintainers is roughly the same on m68k, whereas it's completely distinct on some of the other architectures. Indeed, I was rather surprised to find out last FOSDEM that some arm people were pretty unhappy with the fact that there is no talk at all between the arm buildd maintainer and the people looking after the arm port; then again, it could be that they inflated their involvement in the arm port, and that in reality, there's actually nobody looking after the arm port but the buildd maintainer -- I don't know that, I'm not involved with ARM at all. Anyhow, the point I'm trying to make is that while I'm not one to tell other people how they should do what they're doing, it OTOH is not really fair to say that maintaining a larger set of autobuilders isn't really possible because it's not working out as it should on arm, mips, and mipsel. Perhaps these architectures would be better off rethinking the way they do things, going more towards an m68k-style team-based effort rather than the current state of affairs. The second most significant area of concern, for me, is having people being proactive about dealing with per-architecture build failures. There's no particular reason that should be the buildd admins' or the release team's area of responsibility, either; I agree with you on the release team bit; however, I don't think it's unfair to request that buildd admins handle build failures. If buildd admins of some other architectures can't keep up because they're handling all buildd hosts for 3 (or so) architectures, then the problem isn't that they're asked to do things that aren't their responsability; rather, the problem would be that they're trying to do more than they can handle. all it requires is people who know what they're doing to file sensible bug reports without gratuitously duplicating efforts, and people who know the architectures to help the maintainers sort out bugs. Well, IMNSHO, the first bit of this most certainly is the buildd maintainer's responsability. I'l plead guilty if told that I'm not always doing that properly as I should, but that doesn't change my opinion on this matter. Again, I don't think I'm in the right position to start telling other people how they should do the work they're doing; everyone should do what they think is best, as long as the work gets done, and if the buildd maintainers of the other architectures feel that they can do their job better by doing it all on themselves, then more power to them. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 02:18:47AM -0700, Steve Langasek wrote: On Tue, Jun 07, 2005 at 11:12:50AM +0200, Wouter Verhelst wrote: On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote: 2.4.x kernels are already obsolete by now except that for some doorstop architectures, I do not know about any other modern distribution which still installs one. Since (at least) potato, Debian has always supported more than one major line of kernels. I don't see why we suddenly would need to change that now. We've done this out of necessity -- *not* because it's a good idea. Obviously. What I meant is, we shouldn't throw out doorstop architectures (sic) because they still want 2.4. At least not with the current state of affairs; by the time etch releases, I might have changed my opinion on that subject. The situation is different for 2.2; I don't want to see 2.2 in etch as much as anyone else. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 09:26, Thomas Hood wrote: On Tue, 07 Jun 2005 10:10:13 +0200, David Goodenough wrote: Another item that might be worth considering for laptops is a networking equivalent of the pmount group. People in these groups would be allowed to edit the network files (in particular /etc/network/interfaces) and bring interfaces up and down. http://people.redhat.com/dcbw/NetworkManager/ -- Thomas Hood Reading the page at the URL I am a little unsure as to whether it requires the user to have root access or knowledge of the root password, or if the daemon simply does what the client code tells it to regardless. I will download the code and see if I can make it work. Has anyone made a DEB of it yet, apt-get.org could not find one. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 12:04:26PM +0200, Wouter Verhelst wrote: Obviously. What I meant is, we shouldn't throw out doorstop architectures (sic) because they still want 2.4. Which architecture do you refer to? All architectures supported by debian are supported much better by 2.6 thn by 2.4, in fact none of them is supported anymore upstream except for important bugfixes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 09:26, Thomas Hood wrote: On Tue, 07 Jun 2005 10:10:13 +0200, David Goodenough wrote: Another item that might be worth considering for laptops is a networking equivalent of the pmount group. People in these groups would be allowed to edit the network files (in particular /etc/network/interfaces) and bring interfaces up and down. http://people.redhat.com/dcbw/NetworkManager/ -- Thomas Hood Having downloaded NetworkManager I see that there are two things that I need that it does not do. Firstly it currently requires DHCP, and while that is fine for networks I control, others may not have it and do I need the ability to define static data which this does not give me. Secondly as far as I can see currently this is integrated into GNOME, but not KDE. While obviously I can run a GNOME app under KDE part of the point of an app like this is its menu applet, and unless something changed recently GNOME applets do not run under KDE. However it may be a good starting point. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Possible idea towards future package handling
I've just been reading on the wiki that someone things there should be a pretesting branch for Debian, (good idea in my opinion), but why don't we try and stop rouge packages at unstable. Some maintainers obviously make mistakes every now and then while packaging z, sometimes (if not all the time) the maintainer is generally unaware on any problems, so why not say the following: In addition to testings requirements (x days, no more RC bugs than the last version, all builds up to date), why don't we say, that all packages need to be verified as up to policy and installable/uninstallable by say 2 different people, this could be made up of a separate team (as I'm not sure on the numbers of uploads that pass though unstable a week I can't really guess the size), this would not require members to be DD's just people that have been around enough to earn respect of RM's/FTPMasters etc... In my opinion this could help cut down on Serious/Policy RC bugs before release times, Grave/Whatever RC bugs due to uninstallability, etc... etc... Which would hence mean that RM's would have less triage work to do for RC bugs during release season, FTP Masters would not have to worry about the mass rushes of hinting for removal because, a fair few bugs could be prevented. Of course I do realize it has cons, some of them that I can think of now are: * With 11 arch's at present this would mean a fair few people would be required to do this and not get each other bored. * To introduce, it would need a lot of planning, and WAY more detailed thought process. * Unstable uploads aren't made in an organized manner (i.e exactly 1 every 5 minutes), and could hold up serious uploads. * Some packages may be *so* dangerous (i.e. they it's a really poorly made package making it via some way to perform rm -rdf /etc/init.d or something) that it may cause frustration for people moderating the queue * The cons most likely outweigh the pros. Anyway, this is just opinion and something that I thought of, it most likely could be turned upside down and inside out to make it a WAY better idea, and also, as I'm not a DD I may have misjudged some parts of the release process etc. In general: I don't mind what happens to this idea, if can be improved then by all means, if it can't feel free to scrap/ignore it. -- N Jones Proud Debian FOSS User Debian Maintainer of: html2ps ipkungfu
Re: German newsticker announcements and architectures
In article [EMAIL PROTECTED] you wrote: I checked heise.de and golem.de for Sarge announcement. I just want to let you know that both news tickers stress out that Debian runs on 11 architectures they just quote the release notes/announcement. And I think they only report it because it is nearly the only positive feature you can find in there. I dont think the fact matters to them, they are just kind. Wait for a review, it is only a PR ticker. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ports helping in World Domination?
In article [EMAIL PROTECTED] you wrote: Well, frankly speaking, Julien, last time I checked most of so-called third world users mostly just don't care a shit of non i386 architectures..:-). They just want a functional operating system for the only architecture which is really available to them, no matter whether we like it or not. Too bad we dont support i386 anymore. And most first world users care about x86_64, which is also not released. Looks like the World has to wait before beeing dominated. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Luca - De Whiskey's - De Vitis MIA?
Roberto C. Sanchez wrote: I am wondering what the deal is with Luca and his packages, specifically httperf. httperf was uploaded once, 3.5 years ago. It has two important and one normal bug [0]. He has never responded to any bug on httperf. #215277: httperf: please update libssl dependency (1 year and 239 days) #308097: httperf errors out when requesting SSL sessions (30 days) #170060: Please move httperf to main archive (2 years and 198 days) Of his other packages [1], his latest upload was late 2003. He has a number of bugs open [2] as far back as 6 years ago. Many are unacknowledged, including two important bugs, one regarding a policy violation in a package description and another about a filename collision between a package he maintains and another package. Just wondering what, if anything, should be done. Personally, I would be willing to adopt httperf because I would like to see the bugs fixed. -Roberto [0] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=httperf [1] http://qa.debian.org/[EMAIL PROTECTED] [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=luca%40debian.org some people started to work on zope , on pkg-zope on alioth, and indeed we have not heard from him in a long time (that is, since June 2004) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Miles Bader([EMAIL PROTECTED])@2005-06-07 10:53: Stephen Birch [EMAIL PROTECTED] writes: The question was really this, if Ubuntu created a better bug tracking program would Debian want to run the new software on the debian servers thus replacing the current bug tracking programs? Is it better? That is the $64,000 question. IMHO the debian bug tracking tools are excellent. What I've read about Malone has been pretty vague; it would be nice to see a concise summary of the (intended) differences between it and the debian BTS. Of particular interest is how well it deals with email bug handling, lack of which seems to be the most serious problem with many BTSs (e.g. bugzilla). Yup ... again, debian bts does a great job with its email support. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
* Julien BLACHE | If you're not willing to maintain your packages on the architectures | supported by the Project (assuming it is possible, ie the packages | aren't arch-specific), then you're not helping the project, and you'd | better spend your time on another one. | | Last time I checked, we were all here to help this project build the | best OS ever. I'm not sure the best OS ever means we have to support everything from toasters to mainframes. If I spend time tracking down a bug which affects users on only a single, little-used architecture (because it's RC there) rather than tracking down bugs which are less important (bugs.d.o-important) but affects more users that is not necessarily a good way to spend my time. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Canonical and Debian
Michelle Konzack([EMAIL PROTECTED])@2005-06-06 20:22: Am 2005-06-06 19:22:08, schrieb Peter 'p2' De Schrijver: That sounds retarded in an age where a 200GB HD cost less then 100 Euro... Anyway you can always decide to mirror only part of the archive if you want to, even today. Using an ATA Disk for a Mirror ? Are ATA disks with software raid a reasonable cheaper solution or is ATA just too unreliable for this kind of application? Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Jun 07, Wouter Verhelst [EMAIL PROTECTED] wrote: Since (at least) potato, Debian has always supported more than one major line of kernels. I don't see why we suddenly would need to change that now. We did it because of the need to support doorstops, not because it's a good idea. 2.4 kernels are obsolete *now*, are not getting many new drivers and the lack of sysfs and other features make some packages much more complex than they should be. -- ciao, Marco signature.asc Description: Digital signature
Re: And now for something completely different... etch!
Javier Fernández-Sanguino Peña wrote: Ok, so sarge has been released! We should all thank the Release Team for their hard work in putting this major release together. But... how about we start discussing about what major release goals we want to set for Etch? I'd like to see: The ability to easily run multiple independent copies of a daemon. At the moment you'd have to manually edit init scripts and conf scripts but it'd be nice to see this automatically supported. The ability to have multiple versions of a package installed at the same time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Running daemons without root access?
Hi, Is it possible for a user to ensure that a certain app is (always) started after system start (and stopped before shutdown) without using root access? If so, how? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running daemons without root access?
On Die, 07 Jun 2005, Olaf van der Spek wrote: started after system start (and stopped before shutdown) without using root access? crontab @reboot man 5 crontab Herzliche Grüße Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MATCHING GREEN (adj.) (Of neckties.) Any colour which Nigel Rees rejects as unsuitable for his trousers or jacket. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running daemons without root access?
El mar, 07-06-2005 a las 11:41 +0200, Olaf van der Spek escribi: Hi, Is it possible for a user to ensure that a certain app is (always) started after system start (and stopped before shutdown) without using root access? If so, how? sudo - userslogin command arguments on call to executable at /etc/init.d/daemon then links in aproppiates /etc/rcX.d/ -- Guillermo Gutierrez Herrera [EMAIL PROTECTED] Redirects: [EMAIL PROTECTED] Key ID BA56673E 2005-05-22 Key fingerprint = EAEB BA85 74A4 74D2 FB9F 0B8D 503A 08D7 BA56 673E to import, type: gpg --keyserver pgp.rediris.es --recv-key BA56673E signature.asc Description: This is a digitally signed message part
Bug#312309: ITP: whitelister -- a Postfix Whitelister daemon
Package: wnpp Severity: wishlist Owner: Pierre Habouzit [EMAIL PROTECTED] * Package name: whitelister Version : 0.4 Upstream Author : Pierre Habouzit [EMAIL PROTECTED] * URL : https://projects.aaege.net/mailtools/wiki/Project.Whitelister * License : GPL v2 Description : a Postfix Whitelister daemon whitelister is a Postfix whitelister Policy Daemon aimed to whitelist mails that come from clean hosts wrt rbl/rhbl in order to let suspicious mails go through evil treatments like greylisting -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian
On Tuesday 07 June 2005 11:20, José Luis Tallón wrote: Kern Sibbald wrote: Hello, I've just been looking at the new Debian Sarge release 3.1, and it looks very interesting. I'm not 100% happy with my Fedora FC3 system, so am thinking about loading it here and trying it out. It is quite a learning process though needing a lot of time ... :-) Well, i will be more than happy to help you with that, if you so desire :-) OK, thanks. I'm downloading the first 4 isos with jigdo at the moment. I'm also reading the installation notes (rather large). However, in looking through the packages, I see that they distribute just about every backup package that exists, *except* Bacula. Can you tell me why Bacula is not on their list? Sorry, Kern... but which list have you looked up in? (this is so that we can have it corrected as soon as possible) I looked in Utilities where it says backup programs live. I found Amanda and afbackup there. Then I though I looked in both the compressed and uncompressed lists for 3.1 Sarge and did not find it. Well, after Marius provided the link, I found it was in Administration Utilities AND it is also in both the full compressed and uncompressed lists. I was just dumb and missed it. Bacula has indeed been released with Debian 3.1 Sarge: version 1.36.2-2sarge1 [1] or [2] (which is, as you might remember, 1.36.2 with all fixes from 1.36.3 backported to it) Oh, nice! Thanks. If not, can you tell me who I should talk to about resolving any problems they may have with Bacula? There are none, don't you worry. The only problems we had previously (due to license incompatibilities), you solved them very promptly and appropiately, by making a small license change(the exception to allow linking OpenSSL in, even though it is GPL-incompatible); This was almost a year ago. OK thanks. I'm not worrying any more. Since then, the only times when Bacula has not been included in the candidate set of packages (the /testing/ distribution) have been those when i had problems solving problems with the auto-configuration scripts; Even then, those were just about three times in the last couple of years [since i packaged and started maintaining Bacula for Debian] OK, this is no problem. It is normal that there are a few minor delays. I prefer that it installs correctly rather than worrying about deadlines. In fact, that is the reason why i hardly ever update the DEBs in SourceForge anymore: it is usually much more convenient for users to apt-get them. However, i still upload snapshots when i am satisfied with their quality --which does not happen so often--, so as to have another backup. Thanks. Thanks. Thank you, indeed, for your contribution to Free Software. This release is a bit better just by including your work, Bacula -- just like it is because of the remaining circa nine thousand packages. Kind regards, José Luis Tallón Thanks again for all your work on packaging Bacula. Hopefully, I'll learn how you build your debs ... :-) [1] http://packages.debian.org/bacula [2] http://packages.debian.org/cgi-bin/search_packages.pl? \ searchon=namesversion=allexact=1keywords=bacula -- Best regards, Kern ( /\ V_V
Re: Is Ubuntu a debian derivative or is it a fork?
* Joey Hess [EMAIL PROTECTED] [2005-06-06 22:08]: Personally I will not be suprised if some procmail recipe doesn't end up running somewhere that effectively changes this policy for them. (Didn't you have one, tbm? :-) No, I added some patches by hand for a while. I read -bugs-dist and wanted to spare other people to burden to look up the patches. However, I felt my actions weren't welcome. In any case, if we're not being treated like proper upstream maintainers, maybe we should write some tools to keep better track of those patches. After all, Ubuntu imports bugs from out BTS, so why shouldn't we do the same? (Of course, we shouldn't have to, but given current affairs, it appears as if we had.) -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
On Mon, Jun 06, 2005 at 07:58:13PM +0100, Colin Watson wrote: On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote: * Steve Langasek ([EMAIL PROTECTED]) wrote: Clone yourself and make yourself a slave to the buildds for 7 or 8 architectures, so that the release team doesn't have to. Neither the Whoah, whoah, whoah, is this actually an option? Last I checked that answer was 'no'. Hell, that's most of the *problem* here. The limited set of people running the buildds don't want to spend more time but being allowed to be a buildd maintainer seems to be limited to a rather small set of folks. There seems to be a few different reasons for this, but one of the big ones is wanna-build access, I believe. This is because of limitations of the current wanna-build framework, which may have now been resolved? I don't think Steve was talking about needing more buildd maintainers; he was talking about the task of chasing up issues involved in trying to get required package uploads built everywhere, which currently ends up being a very significant time drain on the release team (since that's the set of people who know which uploads have the highest priority). There could be specific buildd admins in charge of handling packages the release team need to be built quickly. That could even be partly automated with the existing framework (packages with freeze exceptions being built ASAP). I proposed to have $arch release assistant with some buildd admin power to help the release team. This is still an option. I got the possibly wrong impressions that: 1) The release team want some builds to be prioritized. 2) The buildd admins do not want to have to prioritize builds. and instead of trying to resolve this conflict, the decision was made to remove 60% of our architecture to work around the problem. Can't we start to go back and discuss a solution to this conflict ? This does not seem impossible to tacle. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
* Mark Brown [EMAIL PROTECTED] [2005-06-03 11:54]: personally agree with me, it's their policy and unfortunately it won't change... however, maybe there's still hope, now that more people are Has there been any explanation for the policy? I'm having a hard time thinking of any sensible reasoning. Not really. The only answer I got was that we should respect that they're chosing to contribute to Debian in that way. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Luca - De Whiskey's - De Vitis MIA?
On Mon, Jun 06, 2005 at 11:52:22PM -0400, Roberto C. Sanchez wrote: I am wondering what the deal is with Luca and his packages, specifically httperf. Yeah, I'm about to orphan his packages next time I'm orphaning packages of MIA maintainers. Simply didn't get around to it yet, thanks for nothing though! --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Is Luca - De Whiskey's - De Vitis MIA?
On Tue, Jun 07, 2005 at 02:56:08PM +0200, Jeroen van Wolffelaar wrote: On Mon, Jun 06, 2005 at 11:52:22PM -0400, Roberto C. Sanchez wrote: I am wondering what the deal is with Luca and his packages, specifically httperf. Yeah, I'm about to orphan his packages next time I'm orphaning packages of MIA maintainers. Simply didn't get around to it yet, thanks for nothing though! OK. I will prepare an upload of httperf and see if I can fix the bugs that are filed against it (one of them is mine). If you remember, drop a line or CC me on that one and after it is orphaned, I will pick it up. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpvjaphTlKIs.pgp Description: PGP signature
Re: And now for something completely different... etch!
* Joey Hess | Planned, and ground already laid in tasksel (and indeed, it does do it | for some easy things like language tasks). One thing I really want to | see happen is a laptop task. The big missing peice is some simple | program tasksel can call out to, like | | if this_is_a_laptop; then | .. | fi Look at the laptop-detect package in ubuntu. It should probably be uploaded to Debian too, even though it's really simple (37 lines of shell, it looks like). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
buildd machines (was Re: Canonical and Debian)
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: - sparc: one buildd which is not consistently able to keep up with the volume of incoming packages; no backup buildd, no additional porter machine. Second faster machine has been down, reportedly with disk problems. Even faster replacement machine (with more redunancy) has been offered. Apparently waiting coordination between doner (who is a DD) and Debian System Admin team. Offers of an addional buildd have been refused. Offers of addional hardware have been ignored or refused. Binary uploads of packages by a Debian developer trying to help the situation have been strongly discouraged. (Puting it mildly.) Exactly what can an ordinary Debian Developer do to fix this situation? How is it fair to blame the porters when the DSA and buildd teams refuse offers of help? -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
On Mon, Jun 06, 2005 at 06:35:50PM -0400, Daniel Jacobowitz wrote: On Mon, Jun 06, 2005 at 02:21:26PM -0700, Daniel Burrows wrote: On Monday 06 June 2005 01:11 pm, H. S. Teoh wrote: Make a version which generates the image on the sending side? [...] That would be a *very* nice plugin. The bad thing about the current plugin isn't only the security concern: it requires that the recipient have the plugin installed. If the image is generated on the sending side, it solves the security problem, and also makes it possible to send (La)TeX fragments to arbitrary recipients with no additional hassle. I think this is worth considering. But then you can only use the plugin if you can send images, which is almost never the case for me (image-sending never seems to work even if I'm using AIM, maybe because I'm behind a firewall). This I don't know anything about, but it seems like a good thing to fix instead of shoehorning LaTeX into the textual portion. Or you could shoehorn images into the textual portion, with uuencode. See X-Face. Note that such systems must traditionally use the most arcane and absurd image format possible. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
* Martin Michlmayr | In any case, if we're not being treated like proper upstream | maintainers, maybe we should write some tools to keep better track | of those patches. I think equating patches are provided as links rather than as attachments with we're not being treated like real upstream maintainers is absolutely silly. But then, I'm one of those people who don't like attachments at all and tend to give people URLs, if possible, for normal mails too. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 10:23:33AM +0200, Thomas Hood wrote: To begin with we can all go back and review: http://wiki.debian.net/index.cgi?ReleaseProposals I reviewed it and it still all falls into two groups: - Hopelessly unworkable or silly ideas. (Don't release, Release no matter how broken, Do vastly more work than we currently fail to do, Replace Debian with Redhat^WMandrake^WGentoo^WUbuntu) - Votes for more money (Suck less, Release better and more often) So that was pretty useless. The page itself is a good example of why things are the way they are, though. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Is Luca - De Whiskey's - De Vitis MIA?
On Tue, Jun 07, 2005 at 02:56:08PM +0200, Jeroen van Wolffelaar wrote: On Mon, Jun 06, 2005 at 11:52:22PM -0400, Roberto C. Sanchez wrote: I am wondering what the deal is with Luca and his packages, specifically httperf. Yeah, I'm about to orphan his packages next time I'm orphaning packages of MIA maintainers. Simply didn't get around to it yet, thanks for nothing though! ARGH, what a really dumb mistake. I mean noting, not nothing. Oops, means something completely different. --Jeroen Why don't we switch -devel to Dutch, much easier... -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Luca - De Whiskey's - De Vitis MIA?
On Tue, Jun 07, 2005 at 03:26:37PM +0200, Jeroen van Wolffelaar wrote: On Tue, Jun 07, 2005 at 02:56:08PM +0200, Jeroen van Wolffelaar wrote: On Mon, Jun 06, 2005 at 11:52:22PM -0400, Roberto C. Sanchez wrote: I am wondering what the deal is with Luca and his packages, specifically httperf. Yeah, I'm about to orphan his packages next time I'm orphaning packages of MIA maintainers. Simply didn't get around to it yet, thanks for nothing though! ARGH, what a really dumb mistake. I mean noting, not nothing. Oops, means something completely different. Thanks. That makes me feel *much* better. I wasn't sure if you really meant that. I actually thought you were directing that comment at Luca and forgot to specify. --Jeroen Why don't we switch -devel to Dutch, much easier... Because I haven't spoken any Dutch in about 15 years :-) There might even be people out there that have never had the benefit throughout their entire lives. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpan4LfzYuKM.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: - inetd begone! - xinetd (better mechanism to control DoS, privilege separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. - Better OS backup management - upgrade rollback? Selecting one of the many existing viable methods is pointless, as most people will just have to get rid of it again before using whatever they prefer. Creating a new one seems equally pointless. We do not have a shortage of backup tools. If you have specific issues with the particular tool you use, you know where to send them. - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5 No way. Debian has always avoided mindlessly dictating what runlevels must be used for. There's no reason to destroy this feature now. And there's no advantage to consuming an entire runlevel just to say /etc/init.d/xdm stop or /etc/init.d/networking stop, which is all that you are proposing. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 02:32:53PM +0100, Andrew Suffield wrote: On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: - inetd begone! - xinetd (better mechanism to control DoS, privilege separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. Why? What if I prefer to have something from inetd only when necessary instead of constantly running daemons everywhere? - Better OS backup management - upgrade rollback? Selecting one of the many existing viable methods is pointless, as most people will just have to get rid of it again before using whatever they prefer. Creating a new one seems equally pointless. We do not have a shortage of backup tools. If you have specific issues with the particular tool you use, you know where to send them. I think he was referring to being able to rollback to an earlier version of an installed package. Something which is currently not supported, AIUI. Maybe even an earlier release of Debian. - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5 No way. Debian has always avoided mindlessly dictating what runlevels must be used for. There's no reason to destroy this feature now. And there's no advantage to consuming an entire runlevel just to say /etc/init.d/xdm stop or /etc/init.d/networking stop, which is all that you are proposing. I agree. I rather like being able to configure run levels to my liking. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpufaQVeDlUh.pgp Description: PGP signature
Re: And now for something completely different... etch!
Christoph Hellwig wrote: Which architecture do you refer to? All architectures supported by debian are supported much better by 2.6 thn by 2.4, in fact none of them is supported anymore upstream except for important bugfixes. Be that as it may, my feeling from reading a great many installation reports is that giving users the ability to try 2.4 if 2.6 fails to work (or vice versa) saves a fair number of installs that otherwise wouldn't be possible for various reasons. Better supported != perfectly supported after all, and 2.6 certianly still contains some regressions from 2.4. -- see shy jo signature.asc Description: Digital signature
Re: And now for something completely different... etch!
Frans Pop wrote: This sounds like a good idea, but will need very careful logic. For instance, some older (APM-based) Toshiba laptops work well with the toshiba module and the toshset package where newer (ACPI-based) laptops need the toshiba-acpi module which does not work with toshset. I would suspect that similar distinctions exist for other makes. If installing both packages is a problem on some machines, we would need to either fix the package to not do evil things on unsupported hardware, or or have two tasks. I'm interested in other ideas for automatic selection of default tasks. One thing I feel is currently missing is to show users which tasks have been automatically selected and the option to deselect them (maybe only at medium or lower priority). Tasksel supports this (not based on priority though); we just currently hide the language tasks to keep the task list sane. Which brings me to another pet wish: make it a lot easier to install at medium priority than currently. IMO there is a real use for medium priority: - experienced users now often choose expert and get confused by some of the informational dialogs (especially the unavailable drivers one) - for users installing for the first time the no dhcp boot option and such are not really obvious, medium priority can be used to offer useful freedom in a structured way keeping expert for difficult hardware I agree, except I'd just as soon see these changes apply to expert mode installs. -- see shy jo signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 09:37:29AM -0400, Roberto C. Sanchez wrote: On Tue, Jun 07, 2005 at 02:32:53PM +0100, Andrew Suffield wrote: On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: - inetd begone! - xinetd (better mechanism to control DoS, privilege separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. Why? What if I prefer to have something from inetd only when necessary instead of constantly running daemons everywhere? Why on earth would you? It's just more administrative overhead, and yet another package you didn't need. - Better OS backup management - upgrade rollback? Selecting one of the many existing viable methods is pointless, as most people will just have to get rid of it again before using whatever they prefer. Creating a new one seems equally pointless. We do not have a shortage of backup tools. If you have specific issues with the particular tool you use, you know where to send them. I think he was referring to being able to rollback to an earlier version of an installed package. Something which is currently not supported, AIUI. Maybe even an earlier release of Debian. It's supported just fine if you take backups at the appropriate moment. I can't think of any useful way in which it could be more supported than that. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: And now for something completely different... etch!
[Andrew Suffield] It's supported just fine if you take backups at the appropriate moment. I can't think of any useful way in which it could be more supported than that. You should be careful when using your imagination as the guideline for what is useful or not. It might not be a very accurate source of information. RPM got rollback support, and it is very useful. I recommend reading some of the articles describing its support. For example URL:http://www.linuxjournal.com/article/7034 can be used to learn more about this feature. I wished dpkg supported a similar feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 08:03:31AM -0400, Joey Hess wrote: Frans Pop wrote: This sounds like a good idea, but will need very careful logic. For instance, some older (APM-based) Toshiba laptops work well with the toshiba module and the toshset package where newer (ACPI-based) laptops need the toshiba-acpi module which does not work with toshset. I would suspect that similar distinctions exist for other makes. If installing both packages is a problem on some machines, we would need to either fix the package to not do evil things on unsupported hardware, or or have two tasks. I am in favor of fixing the packages instead of complicating task selection. From a user persective, task selection should be a no brainer. The user, ideally, should not to be too concerned with whether the laptop has APM, ACPI, or both. I have already adopted toshutils and will be adopting/uploading toshset next week with a new version that is supposed to (according to upstream) handle both APM and ACPI variants. Let me know what I need to do. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpNPdDeqfGfd.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 16:25, Andrew Suffield wrote: On Tue, Jun 07, 2005 at 10:23:33AM +0200, Thomas Hood wrote: To begin with we can all go back and review: http://wiki.debian.net/index.cgi?ReleaseProposals I reviewed it and it still all falls into two groups: - Hopelessly unworkable or silly ideas. (Don't release, Release no matter how broken, Do vastly more work than we currently fail to do, Replace Debian with Redhat^WMandrake^WGentoo^WUbuntu) - Votes for more money (Suck less, Release better and more often) So that was pretty useless. The page itself is a good example of why things are the way they are, though. Would you please contribute your suggestions (either improve bits at that page or somewhere else) of how to improve things. Thanks. -- pub 4096R/0E4BD0AB 2003-03-18 danchev.fccf.net/key pgp.mit.edu fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 02:40:48PM +0100, Andrew Suffield wrote: On Tue, Jun 07, 2005 at 09:37:29AM -0400, Roberto C. Sanchez wrote: Why? What if I prefer to have something from inetd only when necessary instead of constantly running daemons everywhere? Why on earth would you? It's just more administrative overhead, and yet another package you didn't need. You can't really thank that in *every* case that is true. What if I or another user in a situation where the administrative overhead is better or more desirable than the overhead of having a daemon running in the background all the time? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgposrOBIKw6W.pgp Description: PGP signature
Re: Debian 3.1r0 CD/DVD image problem
Brian Teeman [EMAIL PROTECTED] wrote: Perhaps there is source for a very large game or something that could be left off?? ia32-libs has 214MB of source and is only shipped on ia64. It's possible that something could be worked out that way. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
quote who=Miles Bader date=2005-06-07 10:53:17 +0900 Stephen Birch [EMAIL PROTECTED] writes: The question was really this, if Ubuntu created a better bug tracking program would Debian want to run the new software on the debian servers thus replacing the current bug tracking programs? Is it better? I suspect that it will certainly be better than debbugs at some things. Of course, many of those things are the specific needs of Ubuntu developers. One of those is staying in sync with what goes on in Debian which, obviously, is not something Debbugs needs to worry about. ;) I think it's extremely unlikely that Debian will leave Debbugs for Malone. That said, I think that some Debian developers may choose to use it in addition to debbugs to keep on eye on bugs that elsewhere (Ubuntu and other places) just as many developers currently watch upstream BTSs for their packages. What I've read about Malone has been pretty vague; it would be nice to see a concise summary of the (intended) differences between it and the debian BTS. I'm not sure such a document exists at the moment but at the moment, Malone is still a bit immature and it's still taking shape. Of particular interest is how well it deals with email bug handling, lack of which seems to be the most serious problem with many BTSs (e.g. bugzilla). Email bug handling is something that many folks on the Ubuntu team want so it will eventually happen. It's certainly one of my favorite things about debbugs. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Debian 3.1r0 CD/DVD image problem
On Tue, 7 Jun 2005, Colin Watson wrote: A bug has been discovered in the 3.1r0 CD/DVD images: new installs from these images will have a commented-out entry in /etc/apt/sources.list for http://security.debian.org/ testing/updates rather than an active entry for http://security.debian.org/ stable/updates, and thus will not get security updates by default. This was due to incorrect Release files on the images. If you have already installed a system using a 3.1r0 CD/DVD image, you do not need to reinstall. Instead, simply edit /etc/apt/sources.list, look for any lines mentioning security.debian.org, change testing to stable, and remove # from the start of the line. If you installed other than from a CD or DVD (for example, netboot, or booting from floppy and installing the base system from the network), you are not affected by this bug. New 3.1r0a images will be available shortly to correct this flaw. In the meantime, CD vendors should delay pressing CDs or DVDs of Debian 3.1. We apologise for the inconvenience. Is there any way that the source can be remastered so that it fits on 2 dvd. Seems kind of daft that it stretches to three dvd for the sake of 212mb. If it can be squeezed onto two dvd then we will be able to press the dvd as a double sided dvd. As it is right now there has to be a third dvd. Perhaps there is source for a very large game or something that could be left off?? Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
quote who=Petter Reinholdtsen date=2005-06-04 21:24:54 +0200 I'd like to hear about it, because this is certainly not the common case, and there is an unfortunate amount of myth and rumour on this subject. Oh, it is definitely not the common case. My sample set is ~5 packages, and for most of them the maintainer of the Ubuntu package were very interested in cooperation and co-maintenance. My point is just that we should be aware of the border cases, and try to find procedures to handle those as well. Ultimately, we can't control every individual. Speaking as a project though, we're absolutely interested in as deep collaboration as possible -- particularly on this level. If you think somebody is letting a Debian Sux attitude get in the way, feel free to contact anyone on the Ubuntu community council or technical board to sort it out. We're all familiar faces from Debian and we're all committed making this work. :) Those names can be found here: http://www.ubuntu.com/community/processes/council http://www.ubuntu.com/community/processes/techboard Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Canonical and Debian
Tollef Fog Heen [EMAIL PROTECTED] wrote: I'm not sure «the best OS ever» means we have to support everything from toasters to mainframes. If I spend time tracking down a bug which affects users on only a single, little-used architecture (because it's RC there) rather than tracking down bugs which are less important (bugs.d.o-important) but affects more users that is not necessarily a good way to spend my time. Given our current architecture coverage, a bug on one architecture often also exists on at least one other architecture; because it doesn't manifest there doesn't mean it doesn't exist. A bug is a bug, whether it triggers or not. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Andrew Suffield [EMAIL PROTECTED] writes: On Tue, Jun 07, 2005 at 09:37:29AM -0400, Roberto C. Sanchez wrote: On Tue, Jun 07, 2005 at 02:32:53PM +0100, Andrew Suffield wrote: On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: - inetd begone! - xinetd (better mechanism to control DoS, privilege separation, etc.) xinetd begone. There is no justification for using anything resembling inetd on a modern system. Why? What if I prefer to have something from inetd only when necessary instead of constantly running daemons everywhere? Why on earth would you? It's just more administrative overhead, and yet another package you didn't need. Because I've something else to do with my RAM than to run yet another daemon that will be used at most every other month. -- Rémi Vanicat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging of freenx
On Tue, Jun 07, 2005 at 04:27:58PM +0200, Fabio Tranchitella wrote: On Tue, 07 Jun 2005 at 10:16 -0400, Roberto C. Sanchez wrote: I asked a while back (on IRC) about packaging the NX components that are under the GPL. Someone pointed me to Fabian's packages in Skole Linux. Anyhow, those packages are 6 months old and probably not going into Debian. Fabian has also not responded to my email. See #255850, maybe it could give you some information. OK. No activity in more than a year. The website where the packages were offered early in the thread no longer exists. If there are no objections, I will take over the ITP. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpynET6TL6UK.pgp Description: PGP signature
Re: Is Ubuntu a debian derivative or is it a fork?
quote who=John Goerzen date=2005-06-01 09:06:50 -0500 That sounds very nice indeed. If that pans out, and you also fix the UI issues (by which I mean I have to type approximately three times as many characters to accomplish the same thing that I do in darcs), that would be very nice. It blows my mind that people actually use tla or baz without very good shell completions. The lack of shell completions kept me from switching to baz for weeks. ;) bzr == bazaar-ng? Yes. -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, Jun 07, 2005 at 10:40:47AM -0400, Benj. Mako Hill wrote: quote who=John Goerzen date=2005-06-01 09:06:50 -0500 That sounds very nice indeed. If that pans out, and you also fix the UI issues (by which I mean I have to type approximately three times as many characters to accomplish the same thing that I do in darcs), that would be very nice. It blows my mind that people actually use tla or baz without very good shell completions. The lack of shell completions kept me from switching to baz for weeks. ;) IMHO, it's a bug if it doesn't work efficiently without specialized assistance from shell completions. For my own part, I've found the tla completion support to generally be buggy and not all that helpful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
quote who=Eduard Bloch date=2005-06-03 08:49:31 +0200 And I think it is a fair demand asking all Ubuntu Developers to wear the Ubuntu hats when Ubuntu specific questions are beeing discussed. Read: I expect you to specify [EMAIL PROTECTED] in the From: field, otherwise reading the mail discussions and understanding people's position becomes hard. If my position was Ubuntu Developer it would be that simple. But I'm *just* as much a Debian developer as I am an Ubuntu developer. I've certainly been working on Debian longer. I use ubuntu.com addresses when working on ubuntu lists and when communicating on behalf of the Ubuntu project or on behalf of my work on that project. I do the same with my Debian address. In threads like this, things get hairy because my opinions are informed in part by my work on Ubuntu, in part by my work on Debian, and in part by my own personal opinions. I'm certainly not speaking wholly for either Ubuntu nor Debian. It seems most appropriate to me to just using a From: line that is my personal email address but I am not means trying to hide any of my affiliations. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Possible idea towards future package handling
On Tue, Jun 07, 2005 at 10:26:43PM +1200, Nigel Jones wrote: I've just been reading on the wiki that someone things there should be a pretesting branch for Debian, (good idea in my opinion), but why don't we try and stop rouge packages at unstable. Some maintainers obviously make mistakes every now and then while packaging z, sometimes (if not all the time) the maintainer is generally unaware on any problems, so why not say the following: In addition to testings requirements (x days, no more RC bugs than the last version, all builds up to date), why don't we say, that all packages need to be verified as up to policy and installable/uninstallable by say 2 different people, this could be made up of a separate team (as I'm not sure on the numbers of uploads that pass though unstable a week I can't really guess the size), this would not require members to be DD's just people that have been around enough to earn respect of RM's/FTPMasters etc... Suggestion: seperate policy from mechanism. Have a system to distribute such information, then individuals (or groups) can implement specific policies as they see fit. For example, one site may wish to use 3 DD's, or any one of my 5 best mates, but not ... another may wish to do as you describe, another ... At first blush, such statements look a bit like BTS stuff, and packages such as apt-listbugs already exist. The problem may be getting such material accepted in the BTS. Perhaps a seperate system would be worth building ? Another system that comes to mind is popcon. In the interim you could try something along the lines of delaying updates from unstable (that you don't want to review) for some short period of time and then use apt-listbugs, whilst contributing bug reports for some list of packages you review. I also think this kind of thing could have a use, and would like to add rebuildablility of packages to the list: if I can build a package from source and confirm that it matches a distributed binary package, then I could share this information. (of course there are technical issues, and some may see the whole idea as of questionable value, but hey ...) Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging of freenx
On Tuesday, 7 June 2005 16:40, Roberto C. Sanchez wrote: On Tue, Jun 07, 2005 at 04:27:58PM +0200, Fabio Tranchitella wrote: On Tue, 07 Jun 2005 at 10:16 -0400, Roberto C. Sanchez wrote: I asked a while back (on IRC) about packaging the NX components that are under the GPL. Someone pointed me to Fabian's packages in Skole Linux. Anyhow, those packages are 6 months old and probably not going into Debian. Fabian has also not responded to my email. See #255850, maybe it could give you some information. OK. No activity in more than a year. The website where the packages were offered early in the thread no longer exists. Well, it indeed exists but some problems with the registrar left them without domain :P, you can find the packages at: http://kalyxo-archive.mornfall.net/ If there are no objections, I will take over the ITP. I don't have any objections if you have used FreeNX for a while, know its architecture, ... Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpsHUXAcJ8jW.pgp Description: PGP signature
Re: Canonical and Debian
On Tue, Jun 07, 2005 at 02:12:04AM -0700, Steve Langasek wrote: - hppa: one buildd, keeps up with package volume, but no backup buildd and gdb seems to kill its kernel (yay); one porter machine. The gdb kills sarti issue shouldn't be an issue once it's upgraded to sarge and running a kernel that actually works... The lack of backup buildd is simply because nobody has gone and set one up, it's not like we're lacking beefy hardware. Same with a porter machine. The second most significant area of concern, for me, is having people being proactive about dealing with per-architecture build failures. There's no particular reason that should be the buildd admins' or the release team's area of responsibility, either; all it requires is people who know what they're doing to file sensible bug reports without gratuitously duplicating efforts, and people who know the architectures to help the maintainers sort out bugs. Easier access to the information would help this. Trawling the web interface isn't my idea of fun, but if the fail logs for hppa hit my mailbox I would be more inclined to help... Regards, -- Kyle McMartin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
Le mardi 07 juin 2005 à 05:10 +0200, Nicolas Schoonbroodt a écrit :
So...(sorry for English)
lot of conversation about my plugin on your mailling list.
And also a bug report on sourceforge, related to your remark.
My message will be not complete (because it's 4.50 am here and that I
must be at school at 8am)
First of all, you speak of tex2im depandency. This is not needed since
version 0.3. Now I make the next system calls :
(yep, it's not a good way, for example if /tmp doesn't exist for example)
FILE_SOMETHING represent /tmp/gaimTeX.something
chdir(/tmp)
system(latex -interaction=nonstopmode FILE_TEX)
system(dvips -o FILE_PS -E FILE_DVI)
system(convert FILE_PS FILE_PNG)
and finaly a I do a
system(rm -rf /tmp/GaimTeX.*) somewhere
If you can tell me where you find the tex2im depandancy (README,
INSTALL, ...) It can help me for remove it in the next version.
Now, about the security problem...
Yes, I know it's possible to have some problems with latex call. But If
someone send
$$\input{/etc/passwd}$$
he will see (at best) the local /etc/passwd file, and the receiver, the
local /etc/passwd. So not the same.
And in reality, he well see nothing. One of the (the principal?) author
of kopeteTeX (which is compatible, for respond to one of the first
question)(the develloper is Olivier Goffart) as given me an advice, that
was to blacklist some command.
I have blacklisted the same command than kopetetex, that is :
#define NB_BLACKLIST (42)
#define BLACKLIST
{\\def,\\let,\\futurelet,\\newcommand,\\renewcomment,\\else,\\fi,\\write,\\input,\\include,\\chardef,\\catcode,\\makeatletter,\\noexpand,\\toksdef,\\every,\\errhelp,\\errorstopmode,\\scrollmode,\\nonstopmode,\\batchmode,\\read,\\csname,\\newhelp,\\relax,\\afterground,\\afterassignment,\\expandafter,\\noexpand,\\special,\\command,\\loop,\\repeat,\\toks,\\output,\\line,\\mathcode,\\name,\\item,\\section,\\mbox,\\DeclareRobustCommand}
So (in normal case) all of this command will not be authorised
(in fact, if you send a message like :
normal text \input in normal text $$equation$$ normal text $$equation $$
(or with the blacklisted command in the $$equation part$$) the message
_will not_ be transform using latex compiler. (with the is_blacklisted
function)
If some other command have to be blacklisted, I hear you.
If you have any suggestion with security problem (for example error in
my code, or latex hack to eviter (french word, don't know in English)
this security), you can continue the discussion here, I will read it.
Also other bug can be posted on sourceforge, for example.
Nicolas Schoonbroodt
Considering Nicolas Schoonbroodt (upstream author) 's mail,
do you think I can package it and ask for someone to upload it (on
mentors of course) ? Or do you think there is still security problem in
his software ?
I've read the sources, there is, as Nicolas said, a blacklist of command
that can't be use.
I send him a bug because there's a typo (\\renewcomment instead of \
\renewcommand).
Thank you all for your comments, I'll be more aware next time of
eventually security problems.
--
Martin Braure de Calignon
(error3)
Active member of Amaya fan club, and of her tatoo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Moving packages from experimental to unstable: use -v
It'd be nice if people who move packages from experimental to unstable used the -v option to dpkg-buildpackage. It has two main advantages: 1. bugs fixed in experimental get closed automatically by the upload 2. people who read d-d-changes like myself get an idea of the history of the package prior to its upload to unstable. (See also section 4.6.4.3 in the Developer's Reference.) Thanks, -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
On Mon 06/06/05 20:22, Michelle Konzack wrote: Am 2005-06-06 19:22:08, schrieb Peter 'p2' De Schrijver: I do not know a mirror without Raid-5 so asuming, there are someone which use 3Ware 3w9500 + four WD360GR (around 100 GByte) and they pay 1200 Euro for the Controller and four small 36 GByte Drives. While I don't run an official mirror, it is public (due to my laziness) for debian/sarge on x86/ppc and a testing AMD64 mirror. And I am just wondering why anyone would use RAID in a mirror for. RAID provides for the security of your data in case a disk fails (and occasionally performance boosts). But... its already a mirror... if my drives die, I just run debmirror The mirror will be gone for a bit, but thats not a huge loss (Usually). I guess if the network is expensive then thats an issue. But if the network is expensive why are you running a mirror in the first place? -- -- | Josh Lauricha| Ford, you're turning| | [EMAIL PROTECTED] | into a penguin. Stop| | Bioinformatics, UCR | it | || | OpenPG:| | 4E7D 0FC0 DB6C E91D 4D7B C7F3 9BE9 8740 E4DC 6184 | || | Geek Code: Version 3.12| | GAT/CS$/IT$ d+ s-: a- C$ UL$ P++ L| | $E--- W+ N o? K? w--(---) O? M+(++) V? PS++ PE-(--)| | Y+ PGP+++ t--- 5+++ X+ R tv DI++ D--- G++ | | e++ h- r++ z? | || -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
baz and tla
quote who=John Goerzen date=2005-06-07 09:48:47 -0500 On Tue, Jun 07, 2005 at 10:40:47AM -0400, Benj. Mako Hill wrote: quote who=John Goerzen date=2005-06-01 09:06:50 -0500 That sounds very nice indeed. If that pans out, and you also fix the UI issues (by which I mean I have to type approximately three times as many characters to accomplish the same thing that I do in darcs), that would be very nice. It blows my mind that people actually use tla or baz without very good shell completions. The lack of shell completions kept me from switching to baz for weeks. ;) IMHO, it's a bug if it doesn't work efficiently without specialized assistance from shell completions. Absolutely. The fact that such a workaround is essential is a sign of serious problem. :) tla has those in force. :) For my own part, I've found the tla completion support to generally be buggy and not all that helpful. The zsh completions for tla has treated me quite well. Bazaar is moving fast enough that it breaks pretty frequently. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Canonical and Debian
quote who=Jeroen van Wolffelaar date=2005-06-05 19:00:57 +0200 If you're going to complain about a cabal, please do try to get the facts straight: The DPL team consists of only one Canonical employee, who was even later, after the election, added (Benjamin Mako Hill) And for the record, the extent of my cabalistic work so far has been limited to editorial, ahem, *grammatical* changes to a couple DPL reports. ;) Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
quote who=Josselin Mouette date=2005-06-05 18:50:57 +0200 The problem is that the decisions are always taken for the Ubuntu distribution first. Then, people from Canonical or people wanting to keep compatibility between the two distributions will always want Debian to follow the decisions taken for Ubuntu, regardless of their technical merit and relevance for Debian. This way, Debian ends up being lead by Canonical, and always lagging behind. There are no closed Ubuntu development lists or IRC development channels and you can go see for yourself. I can save you the trouble and, as somebody with insider knowledge tell you that no such conspiracy, or the desire for one, exists in the Ubuntu community or within Canonical. Then again, I'm one of them so I hardly expect you to believe me. I'm not saying that for this particular decision, it wasn't the right thing to do. I'm questioning the independence of the project as a whole for important technical decisions. I think that Debians' instituational independence remains its strongest asset and the most attractive thing to me about the project on a personal level. Ubuntu hackers aren't trying to threaten that and, even if they were, I don't think they would be succesful. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Canonical and Debian
quote who=Josselin Mouette date=2005-06-05 19:15:49 +0200 Then how did these people end up choosing to support the same set of architectures as Ubuntu? It seems quite possible that the groups have come up with similar criteria independently of each other or separate criteria that arrived at the same conclusion. Of course, that's some less exciting that the Canonical controls Debian conspiracy. I know this has been discussed to death, but I still fail to see which problems in Debian the Vancouver proposal can actually solve. That's a completely separate issue -- and one that has been beaten well past death -- and I don't think it's particularly helpful to bring it up in the same breath. Let's keep them separate. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 11:40:55AM +0200, Olaf van der Spek wrote: The ability to have multiple versions of a package installed at the same time. (Sorry Olaf, for getting this twice, my fingers work too fast) No, dear $DEITY. This feature is the major thing I hate about rpms. It's so easy to get wrong and install a package's new version side-by-side when you meant to update the old one. And don't say just be careful when there are people in the world who are not seasoned sysadmin veterans who audit every init.d script and whatnot. Making installing another version on the side as a --force-this-I-really-want-to-kick-myself option would not be as bad, but still as bad. This just won't work. Both versions supply $PATH/$FILE, and then what? 1) divert the other? what's the use of another package version then 2) install to another dir / another name of the file? Again, what's the use 3) this is a library so it only has a .so file with another soname so no name clashes. Hey, oops, different library soname already means a different package (this, I think, is the reason why rpm supports multiple versions) -- Petri Latvala signature.asc Description: Digital signature
Re: Debian 3.1r0 CD/DVD image problem
[This is actually more a question for debian-cd. Cc set appropriately] On Tue, Jun 07, 2005 at 01:03:51PM +0100, Brian Teeman wrote: Is there any way that the source can be remastered so that it fits on 2 dvd. Seems kind of daft that it stretches to three dvd for the sake of 212mb. If it can be squeezed onto two dvd then we will be able to press the dvd as a double sided dvd. As it is right now there has to be a third dvd. Perhaps there is source for a very large game or something that could be left off?? Dropping a source package might get you into legal trouble (some of the licenses for software in Debian require you distribute the source, so you would need to be /very/ careful not to drop something which is under the GPL). Perhaps you could make the 3 DVD set actually a one double-sided DVD plus a CD one? -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ports helping in World Domination? (was: Re: Canonical and Debian)
On 6/6/05, Christian Perrier [EMAIL PROTECTED] wrote: Quoting Julien BLACHE ([EMAIL PROTECTED]): Eh, to achieve Total World Domination, we need to support every architecture out of there. Looks like a step in the wrong direction ;) Well, frankly speaking, Julien, last time I checked most of so-called third world users mostly just don't care a shit of non i386 architectures..:-). They just want a functional operating system for the only architecture which is really available to them, no matter whether we like it or not. I'm running Linux, and soon Debian, on consumer-market embedded wireless routers and file servers based on mipsel, arm, and powerpc (my personal favorite). They aren't graphical desktops, but their low power consumption and low price point make them excellent candidates for developing-country infrastructure gear -- not to mention learning environments for OS developers. Total World Domination means more than the desktop. Vanilla Debian isn't that well suited to be the actual embedded release, and of course buildroot works fine as a cross-compilation environment, but it can be very handy to test in a chroot. And when you're in a hurry, sometimes it's easier to use a buildroot environment hosted on the same arch than it is to fix a configure script that breaks on cross-compiles. Cheers, - Michael
Re: Is Ubuntu a debian derivative or is it a fork?
Joey Hess wrote: Matt Zimmerman wrote: On Thu, Jun 02, 2005 at 12:27:38AM -0400, Joey Hess wrote: Oh, I forgot to mention that if Ubuntu continues to ignore Ian Murdock's warnings about breaking compatability with debs, it will end up a fork in my book even if most of the underlying code is substantially the same, and this will be a very painful and damaging kind of fork too, as we will get deb dependency hell. If Ian were to approach Ubuntu (rather than, say, Slashdot) with clear and genuine concerns, I would be more than willing to discuss the situation with him to explain what we're doing and why. As noted, it was in his blog (and elsewhere, such as some webcast interview). I suspect he has a reason for bringing up this concern in public not private, but I can't speak for him of course. First of all, this whole discussion began when a reporter asked me a question, and I gave him an honest answer--I didn't go out of my way to start talking about it in public. As it turns out, a whole lot of other people have the same concern, and that's how the discussion started. If this was just me doing a bit of grandstanding, it would be a non-story (if anything, the story would be Ian Murdock is a dweeb.) Second, I've been trying to start a private conversation about this very issue since last November, and my attempts to do so have largely been ignored. If taking the concern public is the only way to get it addressed, then so be it. The bottom line is that I want to head this problem off before it becomes a problem--and it will, if we don't do something. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ A nerd is someone who uses a telephone to talk to other people about telephones. --Douglas Adams -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312282: marked as done (release-notes: --guess?)
Your message dated Tue, 7 Jun 2005 18:20:34 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#312282: release-notes: --guess? has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 7 Jun 2005 01:44:55 + From [EMAIL PROTECTED] Mon Jun 06 18:44:55 2005 Return-path: [EMAIL PROTECTED] Received: from neskaya.eckenfels.net [81.169.181.10] (mailnull) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DfT9D-ze-00; Mon, 06 Jun 2005 18:44:55 -0700 Received: from ecki by neskaya.eckenfels.net with local (Exim and XAMS ) id 1DfT98-000LAs-H7; Tue, 07 Jun 2005 03:44:50 +0200 Date: Tue, 7 Jun 2005 03:44:50 +0200 From: Bernd Eckenfels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: debian-doc@lists.debian.org Subject: release-notes: --guess? Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: Bernd Eckenfels [EMAIL PROTECTED] X-SA-Exim-Connect-IP: locally generated X-SA-Exim-Mail-From: [EMAIL PROTECTED] X-SA-Exim-Scanned: No (on neskaya.eckenfels.net); SAEximRunCond expanded to false Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: general Version: debian-doc@lists.debian.org Hello, the german release notes talk about the --guess option to deborphan, however this is only a prefix for multiple options, I guess this should mean --guess-dummy or maybe one of the --guess* options. Sorry dont know which package to report this bug against, thats why i mail directly. maybe it is a good idea to add how to report a bug in this file, too? Eventually we may also want to add a paragraph about how to find packages on your system which are not (wih the corect version) in the official release Greetings Bernd --- Received: (at 312282-done) by bugs.debian.org; 7 Jun 2005 16:20:46 + From [EMAIL PROTECTED] Tue Jun 07 09:20:46 2005 Return-path: [EMAIL PROTECTED] Received: from smtp-out4.tiscali.nl [195.241.79.137] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1Dfgom-0005iI-00; Tue, 07 Jun 2005 09:20:45 -0700 Received: from [195.240.184.66] (helo=strider.fjphome.nl) by smtp-out4.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl) id 1Dfgok-7g-SX; Tue, 07 Jun 2005 18:20:43 +0200 From: Frans Pop [EMAIL PROTECTED] Reply-To: debian-doc@lists.debian.org To: Bernd Eckenfels [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#312282: release-notes: --guess? Date: Tue, 7 Jun 2005 18:20:34 +0200 User-Agent: KMail/1.7.2 Cc: debian-doc@lists.debian.org, debian-l10n-german@lists.debian.org References: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/signed; boundary=nextPart1123822.qBpCBMOWh3; protocol=application/pgp-signature; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: --nextPart1123822.qBpCBMOWh3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 June 2005 03:44, Bernd Eckenfels wrote: the german release notes talk about the --guess option to deborphan, however this is only a prefix for multiple options, I guess this should mean --guess-dummy or maybe one of the --guess* options. The English version has so you might also find deborphan with the --guess= =20 options which has been translated to mit dem Parameter --guess, so I=20 guess this is primarily a translation problem. Therefore CCing the=20 l10n-german list. I agree though that the original could be improved. Sorry dont know which package to report this bug against, thats why i mail directly. maybe it is a good idea to add how to report a bug in this file, too? There is no (pseudo-)package for the release notes currently. The d-doc=20 list is used to discuss issues in them. As reassigning is not
