Re: Who is (co-)maintaining lcdproc package ?
Hi, all Dominique Dumont wrote: In this package, lcdproc's maintainer is still Jose and Jonathan is listed as uploaders. Is this still valid ? Jose, so you want to resume maintaining lcdproc or do you want another one to take over ? As you prefer. I haven't uploaded any new versions due to a lack of sponsors. Anybody willing to step up for sponsoring and/or co-maintaining is welcome. Jonathan, as a DD, can you sponsor the new package ? He is essentially retired, as far as I can remember. But I would really love to have Jon back :-) Nick, do you want to be listed as uploaded ? Depending on your answers, I'll upload a new version with an updated maintainer/uploader list. (and with a correction in the bug list which is missing commas) If we can possibly have a new version which fixes the problems with armhf, I'll be all for it. Drop me a line if I can help (except that I can't upload it) Thank you for you time and interest, Dominique. Regards, J.L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d87d258.30...@adv-solutions.net
Re: Nota sobre el SO
Lobo Oscuro wrote: [...] pero no me conviene, soy un super iman para los problemas, ^ y no tengo paciencia para renegar. Esos son solo algunos, pero siempre hay algo que me choca, mas un sistema casi vacio como esto. Si la situacion se da regresare algun dia de nuevo a debian con conocimientos de todo www.debian.org http://www.debian.org y www.gnome.org http://www.gnome.org y www.kernel.org http://www.kernel.org y no se que otro sitio me falte para pasar a ser un completo y maldito geek tan masoquista como emo. Faltar al respeto a los demás como resultado de la propia frustración no suele conseguir como resultado que le ayuden a uno ... -- La vida es tan miserable y decadente, este mundo podrido que se cae a pedazos, no tiene recuperacion No soy emo, tengo cuchillo pero corto en pedazos a los demas, jojojo OwO Humanos masoquistas, de que se quejan? . y la firma indica dónde reside el auténtico problema -- To UNSUBSCRIBE, email to debian-devel-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cfcdd30.4040...@adv-solutions.net
Re: Sponsorizando paquetes de Debian-Ham
Jaime Robles wrote: Buenas, Hace unos meses un desarrollador de debian-ham dejó Debian y con ello muchos de los paquetes para radioaficionados se quedaron huerfanos. Eso hace que algunos tengamos que coger un poco más de trabajo. Afortunadamente hay algunas personas que de momento no son DD que están ayudando a generar los paquetes pero alguien tiene que subirlos. He subido unos cuantos paquetes tras comprobarlos y demás... he seguido algunos checklist que he encontrado para sponsors y esas cosas pero lo que no he encontrado es el procedimiento técnico para ponerme como sponsor y no como mantainer del paquete. Normalmente, añadir una línea * Upload sponsored by Jaime Robles ja...@robles.es en el changelog es el primer paso. Es decir... ¿Qué hay que hacer para que cuando construyo con debuild, los paquetes se firmen con mi clave para poderlos subir pero no figurar como maintainer sino como sponsor/uploader o como sea? ¿Dónde puedo encontrar documentación al respecto? $ debuild -i -us -uc ; debsign opciones . o, si tienes tu clave disponible en la misma máquina: $ debuild -k0x12345678 --- where 0x12345678 is replaced by your GPG key ID or other key identifier such as your email address. origen: man debuild Mi intención es poder ayudar a todas esas personas que quieren colaborar con debian-ham y hacerlo lo mejor posible ;-) Gracias por el esfuerzo! (aunque yo no sea Ham -- asignatura pendiente) Saludos, Jose -- To UNSUBSCRIBE, email to debian-devel-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc03e94.8010...@adv-solutions.net
Re: Sponsorizando paquetes de Debian-Ham
Ana Guerrero wrote: On Sat, Apr 10, 2010 at 11:02:12AM +0200, José Luis Tallón wrote: Normalmente, añadir una línea * Upload sponsored by Jaime Robles ja...@robles.es en el changelog es el primer paso. Esto es una tonteria que hace alguna gente y no da absolutamente ninguna información adicional que no se de ya. Gracias, Ana. Pero la pregunta era: para ponerme como sponsor y no como mantainer del paquete. Estoy completamente de acuerdo contigo en que no es necesario, pero de hecho, muchos DD exigen todavía esta entrada antes de hacer un upload. -- To UNSUBSCRIBE, email to debian-devel-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc043fa.5080...@adv-solutions.net
Re: Considering the removal of ntpdate
Florian Lohoff wrote: On Fri, Apr 24, 2009 at 12:30:36AM +0200, José Luis Tallón wrote: - For Squeeze: a package ntpdate which depends on rdate and provides a wrapper script, used to emulate ntpdate's main functionality (set the system's clock) in terms of rdate and mark it as deprecated - For Squeeze+1: just drop it * I do use ntpdate regularly --every time I fiddle with my system's clock or check a customer's older server-- for the same purpose that weasel gave before. rdate ist not a replacement for ntpdate - it does not use the ntp protocol but the time protocol (builtin inetd) - So making ntpdate depend on rdate is not a solution as it changes the protocol and i dont think all ntp servers also open/support the time protocol. f...@stereo:~$ egrep ^time|^ntp /etc/services time37/tcp timserver time37/udp timserver ntp 123/tcp ntp 123/udp # Network Time Protocol $ apt-cache show rdate [snip] Description: sets the system's date from a remote host rdate displays and sets the local date and time from the host name or address given as the argument. The time source may be an RFC 868 TCP protocol server, which is usually implemented as a built-in service of inetd(8), *or an RFC 2030 protocol SNTP/NTP server*. By default, rdate uses the RFC 868 TCP protocol. I referred to the other possibility, which uses rdate as an (S)NTP client. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Considering the removal of ntpdate
Christian Perrier wrote: Quoting Peter Eisentraut (pet...@debian.org): Nevertheless, since ntpdate used to be quite popular, I figured I'd better ask here for objections. Would there be a possibility to prove some kind of wrapper for those among our users who might have various local stuff that are using ntpdate ? From what was said in this thread, a quite feasible solution could be: - For Squeeze: a package ntpdate which depends on rdate and provides a wrapper script, used to emulate ntpdate's main functionality (set the system's clock) in terms of rdate and mark it as deprecated - For Squeeze+1: just drop it * I do use ntpdate regularly --every time I fiddle with my system's clock or check a customer's older server-- for the same purpose that weasel gave before. Regards, J.L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Faster shutdown and the ubuntu multiuser update-rc.d extension
Hi I was reading through my archived mail and stumbled upon this thread from over a year ago. Steve Langasek wrote: On Thu, Jan 03, 2008 at 10:48:01PM +0100, Gabor Gombas wrote: On Thu, Jan 03, 2008 at 10:40:32AM -0800, Steve Langasek wrote: Yep, waiting for an unrelated process to exit is surprisingly hard to do correctly. I wonder if the processor connector support in recent kernels could be used to create a kill_and_wait utility: - start listening on netlink for process-related events - send the signal to the process - wait until we receive a notification that the process has died (or a timeout has occured). - from time to time do a kill(pid, 0) just to be sure we did not loose netlink messages In that case, why would we not just migrate toward upstart as an init with service supervisor capabilities? :) Even though I quite like the init system we have right now, it might be in order to revive this subject for a while. That is, reconsider how we initialize the system to see if we can improve it. If there has been some recent (past six months or so) activity on this topic, please point me to it for I have failed to locate it. Regards, J.L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
Harald Braumann wrote: On Tue, 3 Feb 2009 11:14:03 -0800 Paul Menage men...@google.com wrote: On Tue, Feb 3, 2009 at 10:51 AM, sean finney sean...@seanius.net wrote: or /proc/bus/usb or /dev/shm or /dev/pts... :) /dev is a bit different though - even if it's mounted as a udev fs, you can create a new directory in there to act as a mount point. So, what's the problem with /dev/cgroups then? If shm/ and pts/ are allowed under /dev, wouldn't it be discriminating against cgroups/, to not allow it there? /dev/pts refers to the virtual pseudo-tty subsystem i.e. virtual pseudo-tty devices /dev/shm refers to the shared memory device (ok, this is a bit forced) /dev/log refers to the log device it could perfectly well be just a file. The fact that it is actually a socket (more like a pipe to the logging daemon) does not hinder its equivalence to a logfile. whereas I can't fathom why a cgroup feels like a /device/. I admit not being an expert in virtualization abstraction (I do run a significant number of virtual machines, tough), but in fact /sys seems to be a much better place for it. Please feel free to argue against if my proposal does not in fact make sense. While it does indeed feel hackish, mounting a tmpfs on /sys/cgroups and then creating as many subdirs as/if necessary is indeed achievable, practical and flexible. /proc might be useable though, but it has historically been associated with processes and the information related to them. And yes, that means that /proc/cpuinfo, /proc/meminfo, and /proc/bus would actually be out of place there... but keeping backwards compatibility and not surprising users is most important. IMHO, other mount points (/var/run/cgroups maybe?) might make sense too. However the fact that the most common use of cgroup is to split the system into virtual partitions in some way suggests it belongs in /sys. In any case, I want to show my appreciation and gratitude to all kernel hackers out there. You're doing a great job, people. Regards, J.L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: mass bug filing for undefined sn?printf use
Kees Cook wrote: Hi, I'd like to seek advice before I perform a mass-bug filing for this unstable (though semi-common) use of sprintf and snprintf: sprintf(buf, %s foo %d %d, buf, var1, var2); This is used in many upstreams to perform a format-string-handling version of strcat. This was originally noticed by Anders Kaseorg in Ubuntu[1], since -D_FORTIFY_SOURCE=2 triggers a change in behavior (buf is truncated before handling the rest of the format string instead of performing the concat). Upstream glibc points out[2] that using sprintf in this way is undefined under C99, and the man pages have now been updated[3] to reflect this. (Though I believe it is possible to patch glibc to avoid the change in behavior, it's probably best to work on fixing all the upstreams.) In Debian, some tools already compile natively with -D_FORTIFY_SOURCE=2, and some have Build-Depends on hardening-wrapper, which enables this compiler flag. As such, it seems sensible to have all affected packages fixed since the results of such a call could change. (Though it is not an RC issue.) And, a possible solution from Anders Kaseorg... This example sprintf() call could be fixed as follows: -sprintf(buf, %s plus %d, buf, k); +sprintf(buf + strlen(buf), plus %d, k); Similarly, an invalid snprintf() call could be fixed as follows: -snprintf(buf, buflen, %s plus %d, buf, k); +snprintf(buf + strlen(buf), buflen - strlen(buf), plus %d, k); Attached is a list of affected packages, generated via: pcregrep -M 'sprintf\s*\(\s*([^,]*)\s*,\s*%s[^]*\s*,\s*\1\s*,' pcregrep -M 'snprintf\s*\(\s*([^,]*)\s*,[^,]*,\s*%s[^]*\s*,\s*\1\s*,' The logs for individual packages can be seen here[4]. I've tried to trim out stuff that was Ubuntu-specific or not relevant, so apologies in advance if there are incorrect (or missing) things in the list. For LCDproc (as of 5.2), the only matching line is: contrib/interface-demo2/if_demo.c:sprintf(buffer, %s,%s, buffer, if_list[i].if_name); which resulting code is not even installed in binary form. Thoughts? Thanks, Thank you for taking the time to investigate this issue. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Security slightly compromised. Why is lenny-security altering uw-imap_2007b~dfsg.orig.tar.gz?
Nico Golde wrote: Yes. I see two possibilities here, one option is to get 8:2007b~dfsg-1 unblocked and let this migrate to lenny (there is some weird SONAME change though) or to reupload a +lenny2 version to testing-security again. Yuck! Opinions? 7:2007b~dfsg-4+lenny2 sounds better, IMHO Let's keep epochs for the occassions where real versioning goofups do happen :-) Cheers, J.L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug sprint: cookies assignments
Josselin Mouette wrote: Many thanks to José Luis Tallón for proposing to bake cookies, but there are already enough cookers in Spain. Thank you for organizing this all along, and thanks to *all* contributors, whether they fixed their bugs or not, for helping make a better free OS for everyone. Cheers, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
Yves-Alexis Perez wrote: On ven, 2008-09-12 at 11:32 +, Tzafrir Cohen wrote: This is a major bug IMHO. It means that at least for i386 dkms-generated debs cannot be put in repositories. Thus you require a build environment on the target host. No. You only need dkms. Hmm... How does dkms build the modules for a build kernel, then? Surely a compiler and linker must be needed, right? J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
David Paleino wrote:
On Fri, 12 Sep 2008 11:12:59 +, Tzafrir Cohen wrote:
Furthermore, m-a is part of the package management system, which is a
good thing.
Indeed, as reasoned below
[...]
Building packages should be the norm. Having many files under /lib that
cannot be tracked by debsums is not something I like.
[...]
The modules are meant to be handled by dkms, not dpkg. If you need a .deb, it
might be a problem, then.
There are a couple reasons against this IMHO:
- Having files *vital* to the system not tracked by dpkg is
counter-productive. At the very least it thwarts the most basic and
obvious way of integrity protection. It does provide a fantastic
opportunity to leave cruft behind when uninstalling, too
- Where, for security reasons, the full build is unavailable (i.e.
removed from production servers), source-only DKMS would be completely
unusable. However, in a farm of identical servers (quite normal
nowadays), a sysadmin would only need to have one particular machine
equipped with the build system plus full DKMS. Modules would then be
distributed to the other servers via a private repository.
The second item above brings the same issue again. My vote goes for
using an approach similar to module-assistant here, and generate
versioned modules which can co-exist within a system. Moreover, the
generated modules would be installed normally, under
/lib/modules/${KVERS} and tracked by dpkg.
One idea which comes to mind (without further thinking) is to merge both
approaches: dkms could become a subsystem of module-assistant in Debian:
As presented above, installing kernel-headers and/or booting a kernel
for which modules are unavailable would trigger building the necessary
modules with DKMS, and module-assistant would be used to generate the
policy-conforming .deb. This package would then be installed
automatically, so that boot can continue.
When the rebuild is triggered by booting with a new kernel, dpkg is not
active and can be invoked to *register* the new modules, hence realizing
the accountability objective.
When triggered by dpkg installing a -headers package well, we'll
have to devise a solution for this. As said before in this thread, and
knowing nary a thing about dpkg's internals, it might just not be
possible to do this. However, solving this problem might, as hinted
before, provide us with a more elegant solution to other issues.
In any case, since updating -headers can never happen without human
intervention (save, maybe, for apt-cron), it is not unreasonable to
require the admin to manually install the packages immediately after.
Moreover, some script might be provided to automate this process: e.g.
drop a file in some /etc/dkms/pending.d/module file which said script
would use in order to install the just-generated modules.
AFAICS, the aforementioned solution covers all three use cases:
- Updating -headers, wanting to have modules installed immediately (so
as not to lengthen the boot period --- think the VoIP case pointed out
before). Just run the provided script (à la update-grub)
- Updating -headers in the master machine, then being able to
replicate just the binary packages to other machines so that they are
available upon next boot, without the need for a working build
environment in those machines
- When the modules don't get installed before reboot, the built
packages can be looked for in some predetermined location. If
unavailable, the modules could be built and installed on the spot
(again, out of any dpkg loop)
I may perfectly well be leaving some use case out, but this could be a
starting point. My two cents.
J.L.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Change the format of /usr/share/bug/*/script
Gaudenz Steinlin wrote: On Thu, Sep 11, 2008 at 09:37:02PM +0800, Paul Wise wrote: On Thu, Sep 11, 2008 at 8:39 PM, Luca Bruno [EMAIL PROTECTED] wrote: First solution: change the scripts to use a bash function instead of cat EOF, like yesno() create a function display() without hacking cat() and keep going using a FIFO to deal with the UI Second solution: I don't know, I'm asking to you I'd suggest reviewing all the scripts in use and determining if they can become non-interactive. If not, perhaps something based on debconf would be good, since it has various frontends, including GNOME KDE? And debian-installer is useing it for a quite similar purpose. +1 for using debconf/cdebconf (I have no vote in this, but...) Plus, we already have the needed infrastructure to localize all prompts to the user. And we have the means to show most kinds of widgets (yesno / select / note / etc) in a frontend-independent way. Additionally, we already have the means to make those silent (i.e. noninteractive) via preseeding ... and having less code to maintain is always good, indeed. (this means reportbug's UI would just need to provide a debconf frontend for this to work as opposed to the full infrastructure) Just my two cents J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#478779: ITP: mumble -- Low latency VoIP system
Sune Vuorela wrote: On Thursday 01 May 2008, Jose Luis Tallon wrote: Package: wnpp Severity: wishlist Owner: Jose Luis Tallon [EMAIL PROTECTED] * Package name: mumble Version : 1.1.3 Upstream Author : Mikkel Krautz [EMAIL PROTECTED] and others * URL : http://mumble.sourceforge.net/ * License : GPL-2 Programming Lang: C++ Description : Low latency VoIP system isn't it already in the archive ? http://packages.qa.debian.org/m/mumble.html INDEED My apt-cache search returned no results ? I must have some broken cache file. Sorry for the noise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please remove 'progsreiserfs' from the Archive
Package: ftp.debian.org Severity: normal After a full release cycle, it is high time we did. Having nobody actually using 'progsreiserfs' ---the installations reported by popcon are certainly due to mistaken installations looking for 'reiserfsprogs'---, and given that upstream dissapeared quite some time ago, it is pointless to keep it in the Archive. Vorlon, this will additionally get rid of a source of RC bugs -- so much better for everybody :-) Regards, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Roundcube
gregor herrmann wrote: On Sat, 24 Feb 2007 23:27:26 -0200, Fernando M.M. wrote: Althought i have already seen some old discussion about packing the webmail Roundcube (1) i have not found the package using the package search (2). [..] Is someone working on it? Seems so: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333756 http://lists.debian.org/debian-webapps/2007/02/msg0.html http://lists.debian.org/debian-mentors/2007/02/msg00098.html I, for one, have kept and maintain my own Roundcube packages since Feb 2005. However, being beta software, and considering that it needs a quite robust dbconfig-common infrastructure to auto-configure it if packaging properly, I prefered to wait a bit. The fact that Neil posted an ITP also kept me away from posting my packages. Let's see what happens in the next few days. I can also 'dive in' and provide some patches :-) Regards, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why Beryl has just four packages?
Shawn Starr wrote: On Wednesday 14 February 2007 00:27, Anibal Avelar wrote: [snip] Heliodor I won't be including, gtk-window-decorator from compiz is the same thing and will work with beryl (im not sure of metacity themes as there are issues with this) What about requesting a Provides: beryl-heliodor from gtk-window-decorator for the time being? or better yet: a meta-package with the required Depends: upon gtk-window-decorator --- this would help end users while at the same time easing the upgrade path for the future should beryl's heliodor deviate from compiz. You can find the current work on git.debian.org as mentioned, when 0.2 gold is out we will have all copyright/license issues resolved finally. This is becoming of utmost importance as of lately. If we want Debian to remain viable in the long run, we need to keep the Archive free from legal issues. That's actually the main difference among Debian and Ubuntu/Linspire and other derivatives, and its strength :-) One important thing is the that beryl 0.1.4 has icons that are non-free (from the tango project) and these will be removed in beryl 0.2.0 as upstream has told me. Otherwise, beryl would have to go into non-free. Hopefully not. Upstreams tend to be quite responsive when it comes to licensing issues.. we are all in the same boat after all. Anyway, thank you for all your work, Shawn. It is much appreciated. Go Debian! :-) J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problema empaquetamiento (dh_install)
Christian Pinedo Zamalloa wrote: hola, estoy intentando crear mi primer paquete en Debian y me he encontrado con la necesidad de copiar unos archivos de la release al directorio usr/share/chessdb. Lo que he intentado es utilizar dh_install para ello. He creado debian/chessdb.install que contiene lo siguiente: tablebases usr/share/dokuwiki Luego he copiado el directorio tablebases recursivamente al directorio debian. Pero cuando arranco el debuild obtengo el siguiente error: dpkg-source -i -ICVS -I.svn -b chessdb-3.6.12.b8 dpkg-source: building chessdb using existing chessdb_3.6.12.b8.orig.tar.gz dpkg-source: building chessdb in chessdb_3.6.12.b8-1.diff.gz dpkg-source: cannot represent change to debian/tablebases/kbk.nbb.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/kbk.nbw.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/knk.nbb.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/knk.nbw.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/kpk.nbb.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/kpk.nbw.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/kqk.nbb.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/kqk.nbw.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/krk.nbb.emd: binary file contents changed dpkg-source: cannot represent change to debian/tablebases/krk.nbw.emd: binary file contents changed dpkg-source: warning: executable mode 0755 of `config.sub' will not be represented in diff dpkg-source: warning: executable mode 0755 of `config.guess' will not be represented in diff dpkg-source: warning: ignoring deletion of file Makefile.bak dpkg-source: building chessdb in chessdb_3.6.12.b8-1.dsc dpkg-source: unrepresentable changes to source debuild: fatal error at line 1228: dpkg-source -i -ICVS -I.svn -b chessdb-3.6.12.b8 failed Estoy clavado aquí y no se como avanzar agradecería cualquier consejo. Un saludo, dh_install puede copiar directorios, si mal no recuerdo (man dh_install ) Para evitar el error que te da, no tienes más que eliminar lo que copias dentro del directorio debian en tu target clean Pero... por qué no lo copias directamente *en su lugar definitivo* en lugar de usar dh_install ? Ten en cuenta que dh_install es más completo y potente que dh_movefiles [que está depreciado/obsoleto, por cierto...] Un saludo, José Luis Tallón -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libapache-mod-auth-mysql
Raphaël Pinson wrote: Hi devs, Some time ago, libapache-mod-auth-mysql was removed from Debian testing because it didn't work. However, this package is largely used and really needs to be present in Debian. After spending some time trying to find a patch, I finally packaged the new upstream version and made a new package, including a patch from Mandriva to make it work with Apache 2.2. Hmm... you too? what a pitty (duplicated effort :-( ) J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libapache-mod-auth-mysql
Peter Samuelson wrote: [Raphaël Pinson] Some time ago, libapache-mod-auth-mysql was removed from Debian testing because it didn't work. However, this package is largely used and really needs to be present in Debian. After spending some time trying to find a patch, I finally packaged the new upstream version and made a new package, including a patch from Mandriva to make it work with Apache 2.2. Does it actually work properly? Haven't tested it properly. Does it integrate with the apache 2.2 auth model? It mostly replaces it I understand the supported way forward is to use mod_authn_dbd (included in apache) with its mysql backend. Which I plan to try to support for etch, though we don't currently. Are you in a position to test a migration to mod_authn_dbd and report whether it works? Hmm.. the native module has much less features than this one. I don't really see them as competing, but as complementary approaches J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libapache-mod-auth-mysql
Raphaël Pinson wrote: Le Dimanche 21 Janvier 2007 21:14, José Luis Tallón a écrit : Raphaël Pinson wrote: Hi devs, Some time ago, libapache-mod-auth-mysql was removed from Debian testing because it didn't work. However, this package is largely used and really needs to be present in Debian. After spending some time trying to find a patch, I finally packaged the new upstream version and made a new package, including a patch from Mandriva to make it work with Apache 2.2. Hmm... you too? what a pitty (duplicated effort :-( ) Well I work for a webhosting service and had to provide a fast solution for this, so I packaged it cause no one seemed to have done it. Same here... I think co-maintainership would be the most appropriate here :-) I hope we can find a solution for Debian though, because lots of peopel using Debian are using this module and will be very disappointed when they migrate to Etch imo... Yes Thanks, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack the dhelp package
Esteban Manchado Velázquez wrote: Hi all, As Javier noted just after releasing Sarge [1], we need better documentation integration tools in Debian. Yes, we have dhelp [2], but it lacks loads of features, and it's not what I would call in shape [3]. I have tried to fix this situation, mostly by organizing and merging bug reports, and writing a couple of patches for them. Thank you (not that I have anything to do with this package, but all work is welcome) I have even rewritten dhelp_parse, one of the main utilities, in Ruby [4] (mostly because it's a huge PITA finding and fixing bugs in a largely text processing program... written in C). It maintains compatibility with the documentation database, so it's a drop-in replacement. At least it should :-) Ruby is not among the standard installation. May I suggest PERL instead? (Not that I prefer PERL to Ruby -- this is just for dependencies' sake) J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITA: lcdproc
Hi all, In agreement with the current maintainer, Jonathan Oxer, I will take over maintainership of lcdproc. As per his wishes, he will continue to be co-maintainer (uploader) for the time being. This is mostly to let ftpmasters know that he has indeed agreed to these terms so that the upload won't be rejected. Jon, just give an ACK on-list and that should be it. The upload will happen as soon as possible. Thanks, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ¿Se debe renombrar un paquete a -dfsg?
[EMAIL PROTECTED] wrote: Hola Una duda: No sé si siga en pie la costumbre de renombrar el .tar.gz original a -dfsg .tar.gz cuando uno le quita ciertos archivos que no se pueden distribuir con debian. ¿Es así, o simplemente quito los archivos y le dejo el nombre tal como está? Desde el momento que no es el pristine upstream tarball, deberías renombrarlo. Especialmente cuando el cambio se debe a que el original contenía ficheros no redistribuíbles... (además, les evitarás dolores de cabeza a los FTPmasters, y eso siempre es bueno) Saludos, Jose Luis Tallón -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Chicos... necesito un favor :-S
Alejandro Ríos P. wrote: Hola José. Si me permites comentar sobre el caso, creo que no debes tomar la situación en forma personal. Por lo que vi en el hilo de mensajes, hay varios usuarios de bacula que han estado esperando las actualizaciones del paquete y si el mantenedor principal (osea tu) no tiene el tiempo suficiente, pues lo mejor es que alguien más ayude con esto si puede. Yo te recomiendo que no repliques el trabajo de bacula que ya está haciendo John Goerzen y más bien aceptes la propuesta que él mismo dice que aceptaría sobre co-mantener el paquete. Ya lo he hecho. He creado un proyecto en Alioth y he añadido a todos los DDs que han mostrado interés (que han contestado a mi pregunta al respecto) Recuerda que la prioridad del proyecto son sus usuarios, no los mantenedores. Totalmente de acuerdo. Por eso desconfío de alguien que muestra interés justo ahora que va a empezar a usar Bacula en su trabajo. Otros DDs que también usan Bacula en el trabajo (Turbo, Phillip Matthias Hahn, Hamish Moffat, Christoph Haas) han resuelto los problemas que han ido encontrando y me han mandado los correspondientes parches... que yo he corrido a integrar (nótese mi reacción al NMU de John Goerzen @ 1.38.8-0.1 ) Cuando hace casi 3 años empecé a empaquetar Bacula, nadie mostró interés alguno... Lo que no me parece de recibo es secuestrar(hijack) un paquete cuando el maintainer está activo. Otros DDs se habían puesto en contacto conmigo anteriormente ofreciendo ayuda, y siempre la he agradecido. Por otro lado, la política de hechos consumados de John Goerzen es cuando menos deplorable. La actuación de mi AM me produce vergüenza ajena, cuando menos, por su hipocresía (considerando el muchísimo caso que me ha hecho durante estos más de 2 años que le tengo asignado, no deja de ser irónico que me reproche un retraso en subir paquetes -- a los hechos me remito) La connivencia de los FTP-masters no deja de sorprenderme también. Todo esto no hace sino demostrar que, al cabo, en Debian hay dos clases de personas que contribuyen su trabajo. El corporativismo de los DDs vocales en la lista no deja de sorprenderme. Ya veremos en qué afecta esto a mi disposición a colaborar en Debian. Gracias por opinar, no obstante, Alejandro. José Luis Tallón -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Chicos... necesito un favor :-S
Rudy Godoy wrote: El d�a 10/05/2006 a 14:20 José Luis Tallón escribi�... [snip] Dejame decirte algo, no lo tomes a mal, parte de la responsabilidad de ser encargado de un paquete es dar a conocer cuando no vamos a poder encargarnos adecuadamente de estos. Hay que avisar cuando uno no va a poder encargarse por un tiempo y estar abierto a orfanarlo o tener un co-maintainer. Lo he estado. Christoph Haas me lo propuso y figuraba como uploader en la última versión de Bacula que yo preparé. Otra cosa es que las circunstancias han sido extremadamente raras... cuando creía que me iba a poder dedicar tranquilamente a revisar todos mis paquetes, fallos hardware aleatorios me han traído de cabeza. El estar a 3000km de casa no ayuda tampoco. Yo no considero eso como alg�n ataque, es responsabilidad tuya y de los otros desarrolladores cuidar que el software en Debian este adecuadamente cuidado. Nuestra prioridad son los usuarios recuerda. Lo acepté cuando entré en NM, hace dos años y medio. Hasta ahora, mis usuarios no hacen más que darme las gracias (pese a todo, admito mi culpa)... por algo será. En todo caso, lo que critico es el COMO, no el QUE. Mi petición es esta: unos cuantos DDs que no les importe mandar paquetes en mi nombre, para limpiar la lista de bugs que tengo pendientes. Además, si alguno tiene algo bueno que decir de mí, ahora es la mejor oportunidad que va a tener en mucho tiempo :-O Como ya te dijeron, no recomendar�a duplicar el trabajo, pero si tienes otras cosas avisa e intentar� ayudarte. Mira mi lista de paquetes (incluye KBibTeX, en breve). Si hay alguno que te haga gracia, hazme de sponsor en la próxima versión... y asegúrate de mandar un informe sobre ello al DAM. (nótese que he solicitado a DAM un cambio de AM -- no creo que Stephen Frost esté siendo justo conmigo) Gracias, José Luis Tallón -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (END)
John Goerzen wrote: On Fri, May 12, 2006 at 03:13:31AM +0200, José Luis Tallón wrote: Jose, Before I comment on a few things, I want to make something clear to you. You have repeatedly accused me of having something personal against you, both in public and in private. It definitively has looked like that over time. NMUs are not personal attacks. I know that and appreciate them. The attitude and comments which went along with them were offensive to me however. I cannot recall ever having even *heard* of your existance prior to looking at Bacula, and didn't know a thing about you until later yet. Don't worry, you have won. Congratulations, mister Official Maintainer of Bacula in Debian. Time to step out for a while. [snip] What's more, I WOULD HOPE PEOPLE WOULD DO IT FOR ME. I have maintained my fair share of packages over the years, and I have also orphaned or given up packages for adoption over the years. I've been NMU'd, even recently. I am not mad at that. In fact, I am glad that these things have happened. (I wish it hadn't been necessary, but I'm glad that people have stepped up to do it when it was.) I did thank you for your NMU, and hurried to request your patches. That's a fact. A key difference is that I recognized when someone else would be better able to take care of a package, and amicably arranged with them to do so. Well... I said no(for the time being) and you didn't respect that. Instead, you simply proceeded with the hijack. [snip] I don't say this to try to prove that I'm some mighty Debian developer. I'm not, and I know it. I say this because I want you to understand something that you may not have had a chance to experience yet -- that is, that there is more to getting satisfaction from a project than doing everything yourself. I do know that. It's the manners that I don't like. I think the best compliment for a Debian developer is for a *user* of Debian to say, Wow, *Debian* is a solid OS that Just Works. NMUs make Debian better. They definitively do. Hijacking of packages, as in this case, can make Debian better too. Only when done in a proper way (my own POV, anyway) Remember, from the Social Contract, that Debian's priorities are its users and Free Software. Indeed. Those have been mine, even though you and some others differ. I cared about my users when I packaged Bacula for the first time almost three years ago. Attitudes like this will ensure that there is always half a year left until Etch is released. I beg to differ, but I can understand your point. Still much more than two months left for the base freeze. A transition takes 10 days at most. If you get the package right to start with, and uploaded on time. Which history indicates is not likely. Well... different conditions lead to different results. I have had a Bacula-1.38.9-1 of my own ready for a couple days already, but it hasn't been uploaded. Before you say anything: the one who was going to make the upload seems to prefer waiting until this thread ended instead of uploading the fixes. And not, it wasn't because of technical concerns, and it wasn't rover. Now it's too late. Thanks for nothing. * The last upload for Bacula was almost a year ago. There were no upstream releases for over six months, either. But there were RC bugs against it in Debian for over a year. You needed to make a new upload. As has been recently recognized publicly, it wasn't over a year old; And it had only been promoted to RC recently. Then your testing standards are insufficient for an upload to sid. You have uploaded packages that would not even *install from scratch* on most machines. Well... I fixed the bugs I found before every upload. Definitively the subset of machines you and I are talking about are different. There's nothing wrong with that, but then... [snip] The fact that you uploaded six versions of Bacula to NEW within one day gives an idea of the level of testing you give them. That is not correct. Here are the dates of the NEW acknowledgments from the ftp-master scripts for my uploads. Date: Wed, 03 May 2006 14:02:23 -0700 Date: Mon, 08 May 2006 14:02:15 -0700 Date: Tue, 09 May 2006 07:17:11 -0700 Date: Wed, 10 May 2006 11:17:05 -0700 Date: Wed, 10 May 2006 20:47:09 -0700 Date: Thu, 11 May 2006 15:17:12 -0700 BTW, you *KNEW* that your six versions of bacula within one day was inaccurate because the Debian Installer scripts CC'd you on every one of those messages whose dates I have just listed. I failed to check the dates for those. Sorry. Anyway, my point referred to the latest ones anyway. It only takes a few minutes to do a full build, and far less to do a partial build after making minor tweaks, and my machines aren't as powerful as that. But I did test my packages. Well... so did I. It doesn't matter anymore, though. [snip] It is less justifiable to withhold fixes
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Josselin Mouette wrote: Le vendredi 12 mai 2006 à 03:13 +0200, José Luis Tallón a écrit : Please tell me how in hell can you justify accusing me of not testing my packages, when you have obviously not done so. You seem to have some fixation with uploading, don't you?? Six versions in 24h ? Instead of uploading many half-baked packages, you could try getting one right before uploading. It is hardly justifiable to build and upload that many packages if you already foresee many more fixes needing to go in. I don't want to comment on the rest, as you are turning ridiculous, but let me just give you this advice: release early, release often. If that was easy for me, I would (I mean in Debian) It should have been as easy as for John and yourself since late 2004. But it still isn't. Nothing more to say on this. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
David Nusinow wrote: On Thu, May 11, 2006 at 09:30:40PM +0200, Roberto Lumbreras wrote: He has packaged the last version of bacula, and it is not uploaded because it's not ready, then a new version was showed up... he has a personal apt repository that users from bacula mailing list uses, and packages (not yet finished) in sourceforge... so is it clear for you that he is not going to work on it again? not for me, I think he was working, then the John started to do NMUs, and refusing to be co-maintainer with Jose Luis. After John has refused to do that, then Jose Luis has done the same. I think it's a kids game :-( John has managed to not only update to the latest upstream version in his upload, but he's also managed to fix 24 bugs by my count. It is notable that he has managed to achieve so much while Jose struggled just to update to the new version. I have been away from home for 20 months; During the latest 3 I have had random hardware errors which I couldn't fix. I have myself fixed in excess of 40 bugs in my packages in the last 48h, when I have been back to speed. So what??? Since John has said he's open to having an alioth group maintain bacula, with Jose on the team, Hmm.. he chose to hijack my package instead. That is *not* collaborative maintenance. I hope Jose chooses to actively work with everyone to get the help, and apparently training, that he needs to manage something this complicated. Sorry, but I fail to see how well you know my work for Debian (three years so far) in order to be able to judge me. Please check your facts before joining a thread this harsh. I got tons of help from people both in and out of Debian while working on Xorg, and I still get it almost daily. There's no shame in doing so, and Jose should take advantage of it to become a stronger maintainer. Correct. That's why I appreciate patches (and even NMUs). This is completely different. Hijacking a package without contacting the maintainer first is against the Developers' Reference and can only be considered a personal attack. I still don't know what is John Goerzen trying to achieve with this. More on this later. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
Steve Langasek wrote: It is the responsibility of a package maintainer to ensure that fixes for bugs are uploaded in a timely manner. If José Luis isn't able to do this, because he doesn't have a sponsor or for any other reason, then he is not an effective maintainer for the package. That is another matter, probably. I never claimed that I have been the best maintainer for this. Actually, we've heard in this thread that Stephen (his AM) *did* offer to sponsor bacula uploads, and José Luis did not avail himself of this. When the offer did come, I wasn't able to prepare the upload anyway. I suspected that Stephen, given the state of things, would be in excess picky with my packaging. Moreover, I couldn't trust that he would upload in a timely manner... So it's not at all clear to me why you think anyone other than José Luis should bear the responsibility of this package not being fixed. He has packaged the last version of bacula, and it is not uploaded because it's not ready, then a new version was showed up... he has a personal apt repository that users from bacula mailing list uses, and packages (not yet finished) in sourceforge... so is it clear for you that he is not going to work on it again? IME, making plans in Debian based on whether someone else has *promised* to do something does not give very good results. I can understand this. The bacula packages have been removed from testing *repeatedly* over the past year due to one RC bug or another being reported against it; and it seems that the only real movement towards getting them fixed has only come in response to John's takeover attempt. It does happen to be the same time when I am finally home (just returned from Sweden, where I have been for almost 21 months) and had the opportunity to work effectively on my packages again. Unfortunate coincidence, I must admit. I can't say that I fault John for wishing to take over this package and fix it. Thank you for being impartial and acting cool on this, Steve. However, regular practice for this is to offer help or co-maintainership (which others did before) and not hijacking the package. Even when I explicitly denied being willing to give up the package, John has attempted (and almost succeeded already) hijacking my package. This is what I don't accept. I have in the past always accepted patches and included them as soon as I could. How is it different this time? I can feel nervousness due to the upcoming freeze... there is still almost three months left for the base freeze. Why shouldn't I be able to fix my packages in a reasonable period of time (say, before the end of May) now that I am back home? Assuming I failed, this super-duper developer, John Goerzen, has proved to be able to fix everything to your liking in a very short amount of time, and so would be able to have Bacula in Etch in no time. If grave personal issues are not a valid excuse for not devoting Debian as much time as I would have liked to in the past months, then most of the people in this thread shall step out of it and shut up. I won't point fingers here. You know who you are, and I need not say it. If that is indeed the case, state it clearly so that all people approaching Debian will be warned beforehand. I will also consider whether I am interested in contributing any work to Debian in that case, too... as will probably most other people. However, I am amazed about how much attention Bacula has attracted as of lately... when I first packaged it and began maintaining it almost three years ago, nobody cared a bit about it. Now that the worst is over and Bacula is becoming famous, all sorts of people want to have their names attached to it... I can't hardly be surprised by this. Note, however, that I have accepted co-maintainership (as long as it is done on fair terms to me) and have even created an Alioth project for this. Thanks, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
Stephen Frost wrote: If the maintainer still wants to maintain it, help him, do NMUs, whatever, but I'm still looking for one reason you can take over the package against the maintainer's opinion. He wants to have his name on the package w/o doing the work (apparently). What if I prove you wrong? Afraid of that? You might as well not be right on this... J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
John Goerzen wrote: Hello, I intend to take over the Bacula package. I would first like to say thanks to Jose Luis Tallon for initially packaging it for Debian and maintaining it for these years. You have a funny sense of time, don't you? This is true; Years. Since October 2003. A brief history of why I intend to do this: * Bacula has had RC bugs open for more than a year. It was removed from testing several months ago because of this. * Bacula's current maintainer is not a Debian Developer and has been in NM since 2003. So what? If only the elite can contribute to Debian say so. Then, all non-DD maintainers will quit; We might as well flee away to Ubuntu like many former Debian users have done and are doing. At least, they manage to get a distro out of the door every six months. Note, however, that I love Debian as a distro. I just hate the rudeness of some people here (and regret that most of the gentlemen DDs that I have encountered in these years very seldom raise their voices here -- I assume they are devoting that time to Debian in some other way) * Bacula as it currently exists in sid is unbuildable and uninstallable. Bacula will not be present in etch unless significant problems are fixed. There is still half a year left until Etch is released. Still much more than two months left for the base freeze. A transition takes 10 days at most. * The last upload for Bacula was almost a year ago. There were no upstream releases for over six months, either. * The maintainer has repeatedly, over the last year, said he's working on this but hasn't made much real progress, and has made no upload to Debian. And I have. Prove otherwise if you can. I have my testing standards, and never upload anything without testing. You blame me for not testing packages and * Several additional critical-level or grave-level unreported bugs exist in the bacula Debian source tree (such as stopping database servers without permission and deleting files un-owned by a particular package) Then report them. That's what the BTS is for. * There are various policy compliance issues with the current packages. So? report them. That's the procedure you are supposed to follow. * The current maintainer does respond to pings, but has a long record of problems getting bugs (even RC bugs) fixed in a timely fashion. I assume you meant not fixed... I have already prepared an NMU that fixes 22 bugs, including all four RC bugs. I have tagged those bugs as pending. This release is currently sitting in NEW. I also prepared subsequent NMUs that fix critical, but unreported, bugs in the Debian Bacula packages. The fact that you uploaded six versions of Bacula to NEW within one day gives an idea of the level of testing you give them. For those unaware of Bacula's packaging: there are several components, in three flavors (SQLite, MySQL, PostgreSQL). This means that John Goerzen uploads packages without testing them. Either that or he enjoys 48h-days and has ultra-fast machines (I have an AMD3GHz/1GB RAM/SCSI discs for development). JGIt is not your place to upload known-broken software to sid. It is also not your place to fail to test them before uploading. Please tell me how in hell can you justify accusing me of not testing my packages, when you have obviously not done so. You seem to have some fixation with uploading, don't you?? Six versions in 24h ? Instead of uploading many half-baked packages, you could try getting one right before uploading. It is hardly justifiable to build and upload that many packages if you already foresee many more fixes needing to go in. Fixing the rest of the problems with Bacula requires a level of work that is not really appropriate for an NMU. I have discussed the situation with Jose's AM, Stephen Frost, who encouraged me to hijack the package. Stephen Frost: Thank you for showing how an AM *should not* proceed. After neglecting me for several months, and failing to process my NM answers in due time, you have now joined John Goerzen in trying to discourage me from working for Debian. I had to publicly ping you several times on -devel (as well as doing so privately) before I could even get acknowledgement that you had received my answers. If you are that busy (as you have admitted on -devel), then step down as AM and leave space for others who will be able to do better. You didn't, yet you now blame me for not keeping up to my duties as a maintainer and not wanting to work on this. 'nuff said. (This doesn't feel impartial with me anymore -- that would disqualify you as able to evaluate my work) I have also discussed the situation on #debian-devel, and consensus there seemed to be that a hijack was warranted. In short, I will be maintaining working Bacula packages My users don't seem to agree with you (w.r.t. to working Bacula packages)... I have *many* successful reports from my users, by the
Re: Intent to hijack Bacula
Gustavo Franco wrote: [snip] Thanks for this. I'm using backuppc at work and was considering to move our backups to bacula after upgrading our current hardware setup. Package updates and bug squashing in general was on the roadmap. :-) Bacula (specially 1.38.x is much better... hopefully you'll be delighted) That would be good if you, Jose and probably others joined a 'bacula' group in alioth to keep this in group maintenance. I have offered John co-maintenance recently. I previously declined very 'consistent' offers to adopt/take over Bacula, and offered co-maintenance instead. One of the main reasons: i have quite good relations with upstream (almost made them move main development to Debian -- will try again soon) and understand our user's problems quite well. Additionally, quite a lot of users have already contacted me. Hopefully i would be able to join with real work in the next month. Thoughts? You would be more than welcome... specially if you are any good with Postgres. I know that the current postinst could be better (was contributed and can't say much) Some work a much needed dbconfig-common migration would be very interesting, too (i don't feel i have resources enough to tackle that on my own) Closing, do you think it will be possible to ship in Etch a backup server task using bacula ? I think that's all up to add more stuff in debconf and prepare the task itself. Probably a goal for the first 'group upload', if you agree. I couldn't be happier if that happened. We have a bit less than 3 months (until Etch freezes) to get all of this in shape. Any other volunteers? J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bacula_1.38.8-0.1_i386.changes is NEW
John Goerzen wrote: Hello Jose, Before I reply to your message, I want to be clear that I'm going to be blunt here, and say exactly what I think. This is not intended to be an insult or an attack, but the reasons for these concerns. Ok. I don't like flamewars either. There are plenty on Debian-Devel. On Tue, May 09, 2006 at 07:42:17PM +0200, José Luis Tallón wrote: I'd rather have you as a co-maintainer. The unfortunate situation is that i have been in the NM queue for more than two years and a half now. The fact that i depend on my sponsors to get packages uploaded makes me delay them until i can guarantee a minimum level of quality (since i can't fix my mistakes easily). That situation sounds unfortunate; however, there are others that are able to successfully maintain packages in Debian -- with sponsors -- that don't have this sort of problem. Or at least not to the extent that you have. In fact, Stephen himself has offered to sponsor some of my upload, which i have so far declined -- that's not a personal issue in any way, but i'd rather save myself the trouble of explaining *once again* all my technical decisions for a particular package. Cristoph Haas is listed as uploader for Bacula. Turbo Fredriksson helped quite a bit. Moreover, i have had several personal issues during the last months, which made me unable to help. Unfortunate, but the proper thing to do in this situation is to announce the situation and solicit NMUs from people. As far as I have seen, you did not do this. Hmm... I will keep that in mind for the next time, should it ever happen (hopefully not) But I can't see it anywhere in the Policy nor in the Developers' Reference. There are several reasons I have made the NMUs I have, and that I intend to take over this package. Some of them are: * Release-critical bugs that were open for over a year (303862) or a very long time (343762). Some of these were trivial (10-second) fixes. Well... no upload = no bugfixes * Bacula was removed from testing three months ago due to its bugginess. So what? that's obvious. Buggy package == removed from testing. That is how we ensure our OS's quality. * Repeated promises from you in the BTS to make a new upload soon, reference to beta testers, etc., but no upload was forthcoming. Your last upload was almost a year ago. Yes. I am not proud of that. * Your in-progress 1.38 packages on SourceForge were a good start, but did not address many significant issues. Well.. i did close most of the outstanding bugs, and adapted to a new generation Bacula. Transition from 1.36 to 1.38 was not that easy, since it involved a delicate decision: splitting the sd in several flavors. There are a lot of problems that have persisted for literally years in the Bacula packages. Some of them are: * Your postinst scripts would stop (and later restart) database servers without first asking permission. A terrible no-no in production environments. Definitively, not MySQL not SQLite. As for Postgres... well, i never claimed to be any good with postgres, and adopted what was submitted. The RFH has been there, as you say, for years. BTW, the 0pre1 Debian version means something, and was advertised as such. * Your clean target was ineffective and caused a huge diff.gz For 1.38 ? Yes. Can't clean before you have it built, right? Those binaries were contributed by one of my users (Adam Thornton), when the two machines i had available were unable to build Bacula-1.38.7. I must say that i wasn't home at the time. * Bacula would link against Python 2.2 in some cases even though you dep'd on python2.3 Didn't get to it, either. Fortunately, your patches address that problem, right? * Policy violations in numerous places, including treatment of logfiles Touché as for the logfiles. I would like to know what are the other Policy violations you refer to, so that i can learn from those. * No rotation of logs That's a wishlist bug. I think that 'wishlist' comes after 'grave' or 'important'. Do you think otherwise? * Indiscriminate removing of /var/lib/bacula on removal, which would completely break the remaining bacula packages on a system Hmm.. never had that problem, but i understand your point. Please note that i also use Bacula in production in several machines. * Bashisms in debian/rules. Ok. Didn't notice those, nor did lintian or linda. Care to point them so that i can learn? * Poor handling of multiple-variants problem. Hacking up configure scripts instead of just calling configure several times (see the reference to vim in the debian developers' guide) Well I did build Bacula that way almost two years ago, with version 1.32f-4 till 1.32f-6. I was publicly reprehended by Turbo Fredriksson due to the amount of CPU wasted. He cared to contribute some patches which, after being integrated and enhanced
Re: Intent to hijack Bacula
John Goerzen wrote: On Wed, May 10, 2006 at 06:12:52PM +0200, Wouter Verhelst wrote: I have not withdrawn my intent to take over Bacula. I am volunteering to do some pretty significant work on it, and have already done so. You should not go ahead and remove José from maintenance over his objection if he offers you co-maintenance. Your reason for hijacking bacula seems to have been that José was slacking, not anything personal or some such. In that case, I can understand that you want to take over Well, I would say it's more that he has written very poor code -- some of which has been broken for several years The package itself is a bit more than two years old. Most of your concerns are with PostgreSQL-related code, which is much newer (first introduced w/ Bacula-1.36) -- and has not made much effort to fix it. For at least some of it, he does not believe there is a problem. Take a look at the BTS if you want. My first NMU closed 22 bugs (or will, once it gets out of NEW). so that the work gets done. But if José says I'm more than willing to let you help out, but I still want to work on it, then that should be respected; this is how it's always done in Debian. I have made it clear to everyone -- him included -- that I would be happy to receive patches. I will, however, be sure to review them before applying them. That means a change in maintainership without RFA/O nor MIA status. Of course, if I misunderstood something, or you have some compelling reason to block José from cooperating that you haven't talked about yet, I'm happy to be enlightened. The most compelling reason: http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];arch=source Please note that the pending upload bugs on that page are ones that are fixed in my NMU. Not anymore. I have already added some of my own o_O There are all sorts of other long-term blatant problems with Bacula that weren't reported to the BTS. Then go ahead and report them yourself. That's what the BTS is for. ... and attaching patches for NMUs once (or even before) they are uploaded, according to the Policy. Again, where are they? I had to ask for the diff corresponding to 1.38.8-0.1, but haven't received the patches for the following three uploads. Please, will you abide by the Policy before criticizing others' non-compliance ? I am still the maintainer, after all... His AM had already mentioned quite a few to him back in February. Yes. The ones relating to static linking I have already solved for a long time. The ones related to PgSQL... still didn't have the knowledge nor the time needed I don't believe jltallon is yet suited to maintain a package of this complexity. Well... at least this means I am not completely incompetent as a maintainer... You have just conceded that this package is tremendously complex. Thanks. I'd rather fix bugs than keep discussing. As I said before, I never liked flamewars (and, before you say it, I will: just watch out for uploads in my name. This time I have the means ) J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
Marco d'Itri wrote: On May 10, Wouter Verhelst [EMAIL PROTECTED] wrote: You should not go ahead and remove José from maintenance over his objection if he offers you co-maintenance. Your reason for hijacking bacula seems to have been that José was slacking, not anything personal or some such. In that case, I can understand that you want to take over so that the work gets done. But if José says I'm more than willing to let you help out, but I still want to work on it, then that should be respected; this is how it's always done in Debian. Except that he is not a developer and so far has not showed the minimal competence required to maintain a package, nor attempts to improve his procedures. Thank you, Marco. Personal issues are better left outside this discussion. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Chicos... necesito un favor :-S
Hola a todos!! Como algunos de vosotros ya sabéis, el año 2005 no ha sido nada bueno para mí. Esto me ha hecho descuidar mi trabajo en Debian. No pretendo que sirva como disculpa, pero como comprenderéis el llevar más de 2 años y medio en NM sin que mi AM me haga demasiado caso no contribuye a motivarme. El primer trimestre de 2006 lo he dedicado principalmente (jornadas de trabajo de alrededor de 20h) a quitarme de encima los asuntos pendientes de estudio para poder volver (he estado en Suecia). El hecho es que tengo mucho trabajo atrasado, muchos uploads pendientes y pocos sponsors a quiénes acudir. A mi AM prefiero no pedirle nada, porque después de la de hoy [1] está claro que no me tiene especial simpatía. Mi aptitud como maintainer habría que considerarla, pero me parece que se han pasado un poco (diga lo que diga John Goerzen, suena a ataque ad hominem). Mi petición es esta: unos cuantos DDs que no les importe mandar paquetes en mi nombre, para limpiar la lista de bugs que tengo pendientes. Además, si alguno tiene algo bueno que decir de mí, ahora es la mejor oportunidad que va a tener en mucho tiempo :-O Gracias a todos y a todas. J.L. [1] http://lists.debian.org/debian-devel/2006/05/msg00260.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stephen Frost MIA?
Martin Zobel-Helas wrote: Hi José, how about sending this to Frontdesk [EMAIL PROTECTED] or MIA, [EMAIL PROTECTED] instead of spamming debian-devel with that? Thank you for the suggestion. Will do that in the future. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Stephen Frost MIA?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stephen. Having sent you e-mails with my last answers to the TasksSkills stage of the NM process on 2005/10/05, and having received receipt confirmation from you on 2005/10/18, i still have no answer from you. Moreover, i have ping'd you on 2005/10/07, 10/12, 10/15 and 21/11; No answer so far either. Considering that my usual sponsor, Roberto Lumbreras (rover) is quite busy as of late, not being upload-capable myself yet is really damaging my productivity w.r.t. Debian. The fact that i have been in NM since november 2002 and did not see much progress does not help, either. Looking forward to hearing from you very soon. Regards, J.L. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDjRwKM/NWxgIQZSwRAgBDAJ9Ay8O+Krn6X7UxD8wNz8xBZeeg2gCgncrM /PIoJW8Ucb8xICn8UGiAy1k= =+WBy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
KDE ABI transition woes: linking both old and new libstdc++ ?'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I am rebuilding my KDE packages for upload, so as to fulfil the requirements of the C++ ABI transition in Sid, and i am encountering a serious(IMVHO) problem: binaries get linked to *both* libstdc++5 (old version) and libstdc++6 (new version, gcc4 - C++ ABIv2)... however, the binary package declares *exclusively* a dependency on libstdc++6 (which is good). Any advice on how to proceed with this?? I have already succesfully uploaded *one* package, but Linda complained loudly on the rest... some library not already transitioned??? Please, keep in mind that (at least on my system, updated last night) at least the pckages at, debhelper, dselect, mailx and nullmailer still depend on libstdc++5 :-O Looking forward to getting some advice on this. Best, J.L. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDKHLnM/NWxgIQZSwRAiGZAKDq9nds3zSXHtc5VsXvdc/ECIGHywCeI41k r7DHtp5ZeFm+iZdScRl5nN4= =/Kgw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDE ABI transition woes: linking both old and new libstdc++ ?'
Adeodato Simó wrote: * José Luis Tallón [Wed, 14 Sep 2005 20:58:47 +0200]: Hi, (Was the direct mail necessary?) Any advice on how to proceed with this?? I have already succesfully uploaded *one* package, but Linda complained loudly on the rest... some library not already transitioned??? There's known trouble with this check linda producing false positives. Just upload if no binary of yours DT_NEEDs libstdc++5. Well... this binaries *are* linked against both libstdc++5 *and* libstdc++6 ... $ ldd basket [snip] libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x40258000) libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0x4025b000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x4025f000) [snip] libqt-mt.so.3 = /usr/lib/libqt-mt.so.3 (0x4034b000) [snip] libdl.so.2 = /lib/tls/libdl.so.2 (0x40c48000) [snip] libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x40d91000) libm.so.6 = /lib/tls/libm.so.6 (0x40e77000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40e9d000) libc.so.6 = /lib/tls/libc.so.6 (0x40ea8000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x40fe1000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0x4109b000) /lib/ld-linux.so.2 (0x4000) So, as you can see, both libstdc++5 *and* 6 are linked in any ideas/suggestions/pointers/whatever are welcome. Best, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#325289: ITP: debian-hebrew -- Hebrew support in the Debian desktop
Lior Kaplan wrote: Package: wnpp Severity: wishlist Owner: Lior Kaplan [EMAIL PROTECTED] * Package name: debian-hebrew Version : 1.0.5 Upstream Author : Yaacov Zamir [EMAIL PROTECTED] * URL : http://debian-hebrew.alioth.debian.org * License : GPL Description : Hebrew support in the Debian desktop This meta package will install Hebrew desktop related Debian packages for use by Hebrew debian users. . It also includes a script 'hebrew-settings' to reconfigure the system to have a fully Hebrew-ized desktop. . Homepage: http://debian-hebrew.alioth.debian.org/ Hmm... wouldn't it be better to call it user-hebrew, just like user-euro-es, for example?? Basically, so as to avoid namespace pollution and potential confussion among users Any comments/feedback welcome. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323722: maintainer seems MIA, we should orphan this package.
Roberto Lumbreras wrote: Hi Sven... Jose Luis Tallon email is bouncing because he seems to be using some stupid RBL that bans every DSL user in the planet. Try sending mail from other account and it will work. Thanks, Rober... i'll have to remove that i think. Jose Luis is in the new maintainer process, and has been very active with his packages, as you can see: http://packages.qa.debian.org/b/bacula.html http://qa.debian.org/[EMAIL PROTECTED] I've been the sponsor for all these uploads, and definitely no, he is not MIA. Definitively NOT! Maybe you are right with progsreiserfs, it is not my favorite package to fsck my filesystem, it has lots of bugs, but if there are fixes we should let Jose Luis or someone to fix them. Well, in fact, there was a quite harsh discussion re: progsreiserfs, including upstream Hans Reiser himself. It was decided --with mediation from RM Steve Langasek-- that it shall be left in unstable with an RC bug for the time being until we could find some better solution... this might mean updating the packaged version, which i won't do until i can confirm *from upstream* that it is indeed stable. Thanks for your attention but i'm definitively *not* MIA. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323722: maintainer seems MIA, we should orphan this package.
Sven Luther wrote: On Thu, Aug 18, 2005 at 12:40:11PM +0200, Jos? Luis Tall?n wrote: Ok, but now that sarge is released, what are the plans for etch ? The question is if i keep parted without reiserfs support, or if i add it again ? If there really is interest in support for ReiserFS in PartEd, i will more actively maintain this package. It was left as it was just in case. Thanks for your attention but i'm definitively *not* MIA. Hehe, the bouncing email and the 1 year plus old changelog entry made me believe otherwise. But that said, have you looked at the patches in the bug-parted mailing list, do you want me to send them or something ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: Why are you guys using user space utilities not written by us that seem to not work? Could you change who is the debian maintainer for us?
Hans Reiser wrote: I can volunteer [EMAIL PROTECTED], the guy who writes our utilities (which work), for the task. Sorry, but this is the first thing i hear anything about this :-? This is the second time that Ed has broken Reiserfs support in Debian, and each time it breaks Namesys looks bad, because users have no idea it is not us who broke our code. Thanks to Cliff we now have an idea where some mysterious reports of things breaking have their source. Progsreiserfs are *not* in testing and have Release Critical bugs for a reason, and that is to avoid giving the impression that they are stable packages. In fact, they are even categorized under extra instead of optional, because they are lower priority. Who is jltallon? adv-solutions.net has no information on its web page explaining about who they are. Well, José Luis Tallón (that's me). Currently finishing the NM process at Debian and maintainer of some packages. Adv-solutions.net has no web page. It is one of my personal domains, with no commercial interests attached. Is Debian intending to code fork ReiserFS? Are you guys that nuts? Vitaly, please pursue this matter with Debian. Well, i would sincerely appreciate that somebody explained the full thing to me. I have been intending to upgrade progsreiserfs for quite some time now, but lacked the necessary time. And since they are not in testing, i really needed not worry. From what i read below, there is somebody actually using QtParted for their installer. This means i now have some incentive to devote work to this... i will try to have it upgraded as soon as possible, but i can't guarantee anything. I will try to keep you posted. Any additional feedback would be appreciated. Hans Subject: Re: Install errors, reiser3 messages From: Clifford Beshers [EMAIL PROTECTED] Date: Mon, 28 Feb 2005 12:12:38 -0800 To: Hans Reiser [EMAIL PROTECTED] To: Hans Reiser [EMAIL PROTECTED] CC: reiserfs-list@namesys.com Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 14707 invoked by uid 85); 28 Feb 2005 20:12:56 - Received: from [EMAIL PROTECTED] by thebsh.namesys.com by uid 82 with qmail-scanner-1.15 (spamassassin: 2.43-cvs. Clear:SA:0(0.0/2.0 tests=none autolearn=no version=2.60):. Processed in 8.523853 secs); 28 Feb 2005 20:12:56 - Received: from mail.linspire.com (HELO mail.lindows.com) (130.94.123.204) by thebsh.namesys.com with SMTP; 28 Feb 2005 20:12:47 - Received: by mail.lindows.com (Postfix, from userid 8) id 17AEC15C6D20; Mon, 28 Feb 2005 12:14:02 -0800 (PST) Received: from linspireinc.com (unknown [207.67.194.2])by mail.lindows.com (Postfix) with ESMTPid CC40A15C6CF3; Mon, 28 Feb 2005 12:14:01 -0800 (PST) Message-ID: [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20041006 Debian/1.6-5.1.0.50.linspire0.38 X-Accept-Language: en-us, en MIME-Version: 1.0 References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Lindows-Footer: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on thebsh.namesys.com X-Spam-DCC: : X-Spam-Status: No, hits=0.0 required=2.0 tests=none autolearn=no version=2.60 Well, I have some new info this morning. We attributed the errors to hard drive problems to start with as well, but the errors were too consistent and appeared on too many machines simultaneously. Over the weekend we have collected many reports of people being unable to install using reiser3, but succeeding with reiser4. This eliminates both bad CD burns and hard drive errors, so I went looking for another cause. Recently we included qtparted which pulls in a Debian package called ``progsreiserfs'' instead of ``reiserfsprogs.'' We are investigating this as the cause of the problems right now. We are seeing a behavior with the ``progsreiserfs'' tools that one install will generate errors, another will succeed but take a long time, and a third will succeed in the normal amount of time. Same machine, same hard disk, same CDROM. I'm including Debian's description of these packages below. Package: reiserfsprogs Status: install ok installed Priority: optional Section: admin Installed-Size: 1072 Maintainer: Ed Boraas [EMAIL PROTECTED] Architecture: i386 Version: 1:3.6.19-1 Depends: libc6 (= 2.3.2.ds1-4), libuuid1 Description: User-level tools for ReiserFS filesystems This package contains utilities to create, check, resize, and debug ReiserFS filesystems. . NOTE: Releases of Linux prior to 2.4.1 do not support ReiserFS on their own. Thus, these tools will only be useful with Linux 2.4.1 or later, or if your kernel has been built with the ReiserFS patch applied. This patch can be found in the appropriate kernel-patch-version-reiserfs packages. . Homepage: http://www.namesys.com/ zz:~# apt-cache show
Re: Firma de claves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juan Cespedes wrote: | On Mon, Jan 03, 2005 at 03:08:22PM +0100, Jose Carlos Garcia Sogo | wrote: | | Por lo que veo en http://nm.debian.org, el DAM te ha puesto en | estado de espera para la creación de la cuenta debido a que tu | clave GPG está solo firmada por la misma persona que te hace de | advocate. | | | No es por meterme con él, pero creo que si no tiene firmada la | clave por más gente es por dejadez... Podría ser, pero... | yo le veo varias veces al mes, ... AHORA VIVO EN ESTOCOLMO, así que complicado | él sabe perfectamente que soy DD, y que yo recuerde nunca me ha | pedido que se la firme :-) vaya, hombre no te acuerdas de lo de cabrón paranoico en la DebConf-ES ?? AHT, Alo y PerroVerd pueden confirmarlo... Pero, efectivamente, parece que después de casi una hora haciéndome hacer tonterías con los correos cifrados, no me la firmaste. Tienes mis mails cifrados y firmados, así que el dejado de esta historia eres tú ;) De buen rollo, pero no faltemos a la verdad :-D | | Dado el número de desarrolladores que hay en Madrid, creo que no | sería nada difícil quedar un día para intercambiar algunas firmas | (y algunas cervezas). | | | Aunque eso tampoco estaría mal. Josem, nunca te vienes a nuestras | cenas de Debian, y la verdad es que este año todavía no hemos hecho | ninguna. ¿Hace? ¡¡¡Mientras sea antes del 14 de Enero, a mí me vale!!! ¿Viernes 7, a eso de las 10 de la noche? Saludetes, ~José Luis -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2nYcM/NWxgIQZSwRApxQAJ4iT6vBKSaGGWwBLl8gWpZZWjON6ACeOKXc ns6xMUHuxtuJRILrl44woLI= =wyJZ -END PGP SIGNATURE-
Re: RFC: common database policy/infrastracture
First of all, this package would be a God-send for me (see below) Note that 'wwwconfig-common' already contains most of the needed infrastructure... but it is too php-oriented. Splitting it in purely Apache/PHP-oriented scripts (which would remain as wwwconfig-common) and a new 'dbconfig-common' package would probably be in order. Please note that i find the 'database-common' name choice a very unfortunate one...it would surely cause confusion for the end user... dbconfig-common has none of these problems. Oliver Elphick wrote: On Mon, 2004-10-18 at 08:19, Javier Fernández-Sanguino Peña wrote: I'm missing some Best practice on how to setup the database itself. That is, how to setup the tables (indexes, whatever...) that the application will use from the database and, maybe, even some initial data in some of the tables. I would suggest something like this: 1. Identify the server, database type (PostgreSQL, MySQL, Firebird, etc.) and access method (UNIX socket, TCP/IP, TCP/IP with SSL) 2. If your package needs to create a user or database, identify the database administrator's id and password; note that this may include doing su -c postgres or similar. Almost ok, except for the fact that most of us prefer to ask the database administrator's password(and usually name) during postint, so that it can be forgotten( db_reset()'d ). This passwords are(and should) usually only necessary to setup the database, while all the database-related operations from the packaged program are done via an unprivileged user which was setup precisely for this purpose. 3. Determine and, if necessary, create the database user which will own your package's database and other DB objects. If your chosen server is remote, or the server package's policy forbids application packages to change the authentication setup, this may require manual intervention by a database administrator. In that case, your package will be left installed but not yet usable - any attempt to use it should return a message saying what steps are needed to get it working. 4. For PostgreSQL, the preferred method of supplying a password from a script is by creating ~HOME/.pgpass (perms=0600) and specifying the password there as described in the PostgreSQL manual. If password-authenticated access to the database is required, the installation should create this file for the duration of the installation only; if it already exists with different contents, it should be moved aside. The installation script should use trap statements to ensure that everything is put back as it was at the termination of the script. 5. If the database does not already exist, a. Create the database, assigning it to the ownership of the chosen database user. For PostgreSQL: createdb -O owner [-E encoding] database_name b. As the owner, run an SQL script (appropriate to the kind of database) to create the schema and populate it. For PostgreSQL: psql -d database_name -f script_file -e [-h host] [-p port] -U database_owner or su - database_owner -c psql -d database_name -f script_file -e [-h host] [-p port] The latter is preferable if the system user database_owner exists, because it matches PostgreSQL's default authentication setup. At this point, database authentication may forbid the execution of the script; this again may need manual intervention by the database administrator. 6. If the database does exist, a. As the owner, run any script necessary to update the database objects. (The PostgreSQL script command is as above; the same caveats apply, though one would expect that password access as database_owner would already be set up and would therefore succeed.) If the database supports SQL transactions (as PostgreSQL does), SQL scripts should do everything inside a transaction, so that either all objects are successfully created and populated or else there is no change at all to the database. Ok... assuming this applies to user setup also :-? One common issue is that the application depends on that in order to work and it's not done automatically. Maybe the user is prompted to do it but he might be unable to do so until the installation is finished. For an example of this problem see #205683 (and #219696, #265735, #265878). The problem there is that the prompting is being done in the preinst, which is useless, because the files referred to do not yet exist. That is not specifically a database-using problem; it is simply a packaging error. That package should hold all the information it needs in its preinst script, or else not attempt to do things in the preinst. Hmmm. I think this package we are proposing should contain all the Debconf templates (to avoid duplicates in all packages, as it is now) and *routines* which perform the needed tasks as
Re: Bug#277658: ITP: smarty -- Template Engine for PHP
Raphaël 'SurcouF' Bordet wrote: Jose Luis Tallon wrote: Package: wnpp Severity: wishlist * Package name: smarty Version : 2.6.5 Upstream Author : Monte Ohrt [EMAIL PROTECTED] Andrei Zmievski [EMAIL PROTECTED] * URL : http://smarty.php.net/ * License : LGPL Description : Template Engine for PHP There're already exist a smarty package in debian: http://packages.debian.org/unstable/web/smarty Why this ITP ? Because i hadn't seen the package thanks for pointing it out. Less work for me (i needed it for the ITP of bacula-web). Bug already closed. Thanks again. J.L.
Re: ITH: basket ( was: About Basket packaging status)
Luke Kenneth Casson Leighton wrote: hi there, i don't believe i raised an ITP [if i did it was a mistake] but instead should have raised one of those notifications that the basket _should_ be packaged. [can't remember what it's called]. RFP. You can submit one of those with 'reportbug'. Don't worry, i'll package it and make the upload. ... odd: i also didn't receive the message below!!! strange... On Sat, Oct 23, 2004 at 02:18:40AM +0200, Jos? Luis Tall?n wrote: Since i have not received any answer since Oct 5th, i prepare to hijack Basket's ITP in 2 days' time barring answer from the OP (101 days in preparation) I believe that Basket is an useful application to have in Debian, and will take care of maintaining it as an official package. Best, ~J.L.
ITH: basket ( was: About Basket packaging status)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since i have not received any answer since Oct 5th, i prepare to hijack Basket's ITP in 2 days' time barring answer from the OP (101 days in preparation) I believe that Basket is an useful application to have in Debian, and will take care of maintaining it as an official package. Best, ~J.L. - Original Message Subject: About Basket packaging status Date: Tue, 05 Oct 2004 01:40:02 +0200 From: José Luis Tallón [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, Luke! ~ How is the BasKet packaging status?? I thought it would be wonderful to have it in Debian... have you already contacted upstream and began packaging? how is everything going?? ~ If you need some help or feel than you'd like to relinquish packaging to someone else, please contact me. Best, ~ J.L. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBeaNgM/NWxgIQZSwRArzNAJsET0J1q2pK84VYNvWz319HjxC7RwCfVupO NLiajUiP5hy6FR31KHIzoFo= =1wSl -END PGP SIGNATURE-
Re: Sobre cómo entrar
Alejandro Exojo wrote: - ¿Es muy complicado pasar el proceso de evaluación? No sé a qué nivel de exigencia se llega al evaluar a un candidato. Mira por donde Esto también me interesa a mí 0:-). Yo creo que me apuntaré a NM en cuanto acabe la carrera, pero no sé si debería esperar a saber un poco más, o se va aprendiendo bajo demanda y a medida que lo vayas necesitando. Los que hayáis pasado por el proceso hace, poco, ¿podríais comentar brevemente que es lo que se pregunta? Depende *mucho* del AM que te toque... yo llevo ya casi un año. En este tiempo, sólo me han permitido pasar la fase PhilosophyProcedures, pero si miráis mi lista de paquetes creo que veréis que he hecho unas cuantas cosas más... (bacula_1.34.6 está en camino) Típicamente, se tarda de un año a un año y medio. Lo que os garantizo es que, a poco que os toque un AM decente, de verdad vais a aprender cómo funciona Debian por dentro. Reconozco que es una puñeta, pero al final voy a agradecer el haber tenido que profundizar tanto: los problemas empiezan a desaparecer automágicamente cuando sabes lo suficiente. En cuanto a lo de acabar la carrera antes... depende de la motivación que tengas, y la posibilidad de sacar algo de tiempo. Considerando la cantidad de trabajo que hay por hacer, más gente que colabore (sea empaquetando ó --preferiblemente-- haciendo otras cosas) es importante: hay que reescribir mucha documentación para Sarge+1 gracias a las no tan geniales ideas de Mr.Stallman, traducir todo lo habido y por haber, buscar/crear sustitutos para los bits /non-free/ que quedan en el Archivo de Debian ... - ¿Es necesario darse de alta como desarrollador para mantener un paquete? No, esto es lo más interesante. Puedes mantener un paquete igual que si fueras un desarrollador de debian, pero el subirlo al archivo lo hace un desarrollador, que actúa como sponsor. En esta FAQ tienes todo lo necesario: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html Además, no veas lo que te hace aprender ( a mí que me lo digan!! ) Bienvenido abordo. José Luis Tallón
Re: Desarrolladores de habla hispana
At 10:39 25/03/2004, you wrote: El Jueves, 25 de Marzo de 2004 02:47, José Luis Tallón escribió: Debian-Lex ( se creó en ¿Octubre? recuerdo el post ... ) Javier de la Cueva tiene montada su Notaría a golpe de software libre a ver si convencemos a los demás :) Hey, hey, hey... Que soy un humilde abogado, no un notario. Ya me gustaría, ya XD Pues Iván Sánchez habla maravillas de ti ;-) lástima que no nos pudiéramos conocer el lunes :-( -- Saludos, Javier de la Cueva
Re: Desarrolladores de habla hispana
At 12:28 24/03/2004, you wrote: On Thu, Mar 18, 2004 at 11:18:44PM +0100, Amaya wrote: Quiero consultaros cuál es la mejor forma de confeccionar una lista de desarrolladores de habla hispana, además de una de residentes en España. Pues esta lista, como ya se ha dicho, pero, para tener en cuenta los que no están aquí habría que hacer un ping a todos. La lista [1] va adjunta. Te parecerá bonito... y los NM ?? ;) ( A ver si el bueno de mi AM saca tiempo y me hace algo de caso ) Un saludo Javi
Re: ip_conntrack, límite de contadores, y kernel 2.4.24
At 19:29 21/03/2004, you wrote: El dom, 21-03-2004 a las 17:40, José Luis Tallón escribió: At 10:38 21/03/2004, you wrote: Content-Type: text/plain; charset= Hola, Necesito saber si alguien ha tenido un problema con el kernel (especÃÂficamente las series 2.4) y si han tenido alguna solución, les narro el asunto... No entiendo... 2 procesadores Pentium4 (espero que sean Xeon), con sólo 512MB de memoria, y una NIC de $10 ??? Evidentemente poca memoria, tenÃa hace poco 1 Gb pero el problema ya existÃa; venga, no hay problema, se pondrá a sugerencia el Giga ya que el sistema llega a usar el swap con el paso de los dÃas... (Por si acaso esta en SMP y con high memory support 4 Gb, este quedo asà porque, repito antes tenÃa 1 Gb, podrÃa ser ese el problema porque ahora está con solo 512? de todas formas ocurria con el Giga...) El problema no está causado por la cantidad de memoria. Aunque si indicas que llega a usar 'swap', puede haber un proceso que tenga alguna fuga de memoria ( leak ), a lo peor el propio kernel... Yo usarÃa una ( ó dos ) Intel e100, al menos. En realidad tiene 4 Dlinks, muy baratas por cierto, ya se ha sugerido la adquisición de unas tarjetas de red de mejor calidad, Si, es bastante recomendable. el problema también se presenta con 3com (3c59x), recomienda alguna además de la Intel e100? El problema es posible que no tenga que ver con la tarjeta, pero el rendimiento mejorará mucho con otras tarjetas de mejor calidad. Las 3c59x no están nada mal, pero tienen problemas en configuraciones con múltiples VLAN ( tag-based VLAN / 802.1q ) e100 y e1000 dan buenos resultados en la práctica. He oído cosas buenas de las tigon3 y broadcom, pero no he podido verificarlo. Para qué tanta potencia de cálculo?? qué servicios presta esa máquina ? Lo más pesado es el Proxy con aceleración web... y claro el equipo ya estaba, y se tenÃa que usar como tal, yo he tenido equipos PII de 500 Mhz con iguales resultados, ni más ni menos, pero el tráfico en estos nunca fué tan grande, asà que este problema no lo he tenido hasta ahora... En estos momentos estoy poniendo a prueba 3 equipos (que cumplen la misma función y que siempre han estado en producción en diferentes lugares) a los cuales se les ha incrementado el tráfico, veremos como va... Un proxy caché necesita, por este orden, memoria, memoria, memoria, disco, potencia de cálculo ( entiendo que es eso a lo que se refiere proxy con aceleración web... ) Si tiene alguna otra sugerencia será bien venida. Pues no muchas más, sinceramente ... :-S En caso de que sea un defecto en el driver de la tarjeta de red, el cambio a las Intel debe solucionar el problema. En todo caso, mejorará el rendimiento. El aumento de memoria aumentará de forma apreciable el rendimiento de la máquina en su labor como proxy caché. En cuanto al desbordamiento de ip_conntrack ... Tengo máquinas que hacen wrap around( volver a 0 el contador de bytes transmitidos/recibidos al superar los 4G ) con cierta frecuencia y nunca tuve este problema, con ninguna clase de NIC, pero no estaban usando ip_conntrack ( IP pública rutada directamente en todas ellas ). 2.4.26-pre* presenta el mismo problema? sino, es un bug serio que hay que plantear en la LKML. Gracias por su ayuda No hay de qué darlas. Siento no poder ser de más ayuda. Saludos José Luis Tallón
Re: ip_conntrack, límite de contadores, y kernel 2.4.24
At 10:38 21/03/2004, you wrote: Content-Type: text/plain; charset= Hola, Necesito saber si alguien ha tenido un problema con el kernel (especÃficamente las series 2.4) y si han tenido alguna solución, les narro el asunto... No me ha pasado. Tengo un servidor que hace de Router con Debian woody stable, gcc 2.95.4, kernel 2.4.24, procesador Intel Petium IV (dual), 512 RAM, NIC D-Link. El kernel 2.4.24 usuado es el obtenido en kernel.org, lo que ya he notado es que cada cierto tiempo (aproximadamente entre 8 a 10 dÃas), el equipo genera un mensaje: No entiendo... 2 procesadores Pentium4 (espero que sean Xeon), con sólo 512MB de memoria, y una NIC de $10 ??? Yo usaría una ( ó dos ) Intel e100, al menos. Para qué tanta potencia de cálculo?? qué servicios presta esa máquina ? Mar 17 10:13:23 blackmarsh kernel: LIST_DELETE: ip_conntrack_core.c:302 `ct-tuplehash[IP_CT_DIR_REPLY]'(ddf5c414) not in ip_conntrack_hash[hr]. Después de ello queda completamente congelado y no hace nada, la única solución es darle reset. Ahora esta situación ha ocurrido en tres oportunidades y siempre ha sido justo cuando los contadores de transmisión de paquetes TX o los contadores de recepción de paquetes RX de la NIC estaban alcanzando el lÃmite (un número bastante grande). Como dato adicional el tráfico manejado por este equipo es bastante grande. Por ahora tengo una solución por ortodoxa, y dado que el equipo es rápido se reinicia una vez por semana, y con eso ese problema parece haber desaparecido, pero no me parece lo más adecuado. Es poco ortodoxo, desde luego, pero de momento... habrá que encontrar una solución al problema, por si acaso. Un saludo, José Luis Tallón
Re: MAX, la Debian de Madrid :)
At 15:00 15/03/2004, you wrote: Buenas noticias desde la Comunidad de Madrid: Apuestan por el Software Libre en la consejería de educación :) http://www.educa.madrid.org/web/madrid_linux/archivos/caracteristicas.html A ver si empiezan a ir por buen camino - Las aplicaciones de gestión están hechas en Java versión Oracle y sólo funcionan con una máquina virtual propietaria, y en versiones muy concretas. - Todo el sistema de groupware está montado con Exchange, y el acceso que ofrecen es Outlook Web Access Por que hagan algo bien no va a pasar nada ... ¿alguien la ha probado? ...yo me he pedido una , a ver cuando me la mandan :) Es una knoppix 3.3 modificada ... mira la página. Un saludo
Accepted bacula 1.32f-4-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 18 Feb 2004 00:04:11 +0100 Source: bacula Binary: bacula-console-gnome bacula bacula-fd bacula-director-common bacula-console bacula-director-mysql bacula-director-sqlite bacula-client bacula-doc bacula-server bacula-common bacula-sd Architecture: source i386 all Version: 1.32f-4-1 Distribution: unstable Urgency: low Maintainer: Jose Luis Tallon [EMAIL PROTECTED] Changed-By: José Luis Tallón [EMAIL PROTECTED] Description: bacula - Network backup, recovery and verification bacula-client - Network backup, recovery and verification (Client meta-package) bacula-common - Network backup, recovery and verification (Common Support files) bacula-console - Network backup, recovery and verification (Mgmt. Console) bacula-console-gnome - Network backup, recovery and verification (Console, Gnome version bacula-director-common - Network backup, recovery and verification (Director common files) bacula-director-mysql - Network backup, recovery and verification (Director daemon) bacula-director-sqlite - Network backup, recovery and verification (Director daemon) bacula-doc - Network backup, recovery and verification - Documentation bacula-fd - Network backup, recovery and verification (Filer daemon) bacula-sd - Network backup, recovery and verification (Storage daemon) bacula-server - Network backup, recovery and verification (Server meta-package) Closes: 188946 Changes: bacula (1.32f-4-1) unstable; urgency=low . * Do *not* depend on OpenSSL, since it is not really needed, as confirmed by upstream. . * Increase robustnes in bacula-director-mysql's postinst: succeed also when MySQL runs at localhost and network connectivity is disabled. . * Increase robustness polish some rough edges in the 'config' script: detect whether tables are created and act accordingly. . * Make bacula-director-mysql *restart* bacula if there was a previous version installed, do *stop* it on remove. . * Increase robustness of bacula-director-common's initscript : killall -15 if start-stop-daemon --stop did not succeed. . * Fix packaging bug in bacula-console introduced with prev. release changes. . * Fix several typos/leftovers from package polishing lately: mostly forgetting to update vars to reflect changes in file location/name . * New upstream version . * RFP/ITP fullfilled (Closes: bug#188946) . * Package sponsored by Roberto Lumbreras [EMAIL PROTECTED] . * Moved /usr/sbin/console to /usr/sbin/bacula-console, and provided a wrapper script so that it gets called with appropiate arguments, as a convenience to users. Added corresponding manpage (linked to console.1) . * Previous changes, before first upload to the Debian archive: . - bacula (1.32f-3-1) 28 Jan 2004 . * Fixed a typo in bacula-director-mysql, which made postinst stomp on existing configuration file. Noticed by Dick Middleton. Robustness features in bacula-director-mysql.postinst. . * Slightly better manpages. . * Readied for first upload to Debian's archive. . - bacula (1.32b-5) 24 Dec 2003 . * Completely revamped the bacula-director-mysql postinst, based upon suggestions/debugging by Frank Lenaerts. Most work was done during the DebConf-ES, with assistance from Alvaro Hernandez Tortosa [EMAIL PROTECTED] . * Added chmod 755 for scripts in the patches subdir to rules, fixing a sure FTBFS bug. Pointed by Frank Lenaerts [EMAIL PROTECTED] . - bacula (1.32b-4) 23 Nov 2003 . * Polished 'purge' behaviour[postrm scripts] -- do remove files. . * Updated Build-Depends debian/rules to better comply with policy, following advice from Roberto Lumbreras [EMAIL PROTECTED] . * Strengthened permissions on /etc/bacula and FD/SD/Director config files, to avoid giving away passwords to local users and thus avoid attacks. Problem reported/solution suggested by Frank Lenaerts. . * Verified dependencies, loosened a bit so that backporting is easier. Suggested by Frank Lenaerts [EMAIL PROTECTED] . - bacula (1.32b-3) 10 Nov 2003 . * Fixed several little packaging bugs: - Dir SD ports were mistakenly exchanged. - SD privileges were a little too low. - Gnome-Console's config file was missing. . - bacula (1.32b-2) 6 Nov 2003 . * Polished Packaging a little bit . * Fixed daemon stop bug, based on suggestions by Matthieu Racine [EMAIL PROTECTED] . * bacula-common's postinst now adds needed entries to /etc/services . - bacula (1.32b-1) 19 Oct 2003 . * Initial Packaging: 12 binary
Re: OLA!
At 20:58 28/02/2004, you wrote: Nacho Garcia wrote: Don't worry, I DO live in Spain and I had never seen anything like that before. Ick! ;) May that be ali-oli or something like that? I am also puzzled by this description :-) I assume it must be AjoBlanco... a garlic-based version of gazpacho quite popular in Málaga and to a lesser extent Huelva, Cádiz and Córdoba
Re: XFree y Debian
At 15:44 08/02/2004, you wrote: [snip] Hmm tras leer el thread (http://www.xfree86.org/pipermail/forum/2004-January/001893.html) la idea que se me queda es que solo los drivers desarrollados por XFree86 cambiarán su licencia, cualquier otro driver contribuido por empresas (como el de ATI) o personas externas a XFree86 mantienen la licencia anterior o la pueden cambiar a lo que se les antoje, por tanto sería factible, en mi opinión, tener unas X con una licencia que cumpla las DFSG, de hecho comentan algo que no sabía y es que parte de las bibliotecas que instalas con XFree86 vienen de X.org y dichas bibliotecas tampoco cambian de licencia, así que parece ser que no es tan catastrófico... aunque pensaba que XFree86 y X.org se habían unido hace unos dias :-? En la web de XFree86.org dicen que nada de nada. Lo que si que me ha quedado casi totalmente claro es que no piensan cambiar la licencia a algo compatible con la GPL :-| pues en el hilo hay un bonito comentario diciendo que ... «La GPL es la que tiene que cambiarse para que sea más compatible con otras licencias» y diversos ataques contra su efecto «virulento». Por tanto, mucho me temo que XFree86 acabará quedándose fuera... No es solución a largo plazo, desde luego, pero todo lo anterior a las XFree86 4.4.0rc3 mantiene la licencia anterior ... considerando que XFree86 4.3.x sigue en experimental, creo que tenemos hasta Sarge+1 para preocuparnos ;) José Luis
KDE-Look: Wallpaper para Debian
Podría venir de serie con la distribución ... es la perfecta respuesta para los *BSDeros http://www.kde-look.org/content/files/10584-dressel.jpg ... y seguro que ganamos usuarios ;-) Jose
DebTakeOver: Guillem barrapunteado
http://slashdot.org/articles/04/01/14/1319228.shtml?tid=106tid=117tid=185tid=90tid=99 Sin comentarios . :) Enhorabuena, Guillem... Ya era hora de que saliera en /. tu respuesta a los upgrades que dicen hacer los BSDeros de Linux a FreeBSD Como diría Amaya: All resistance is futile... you will be SlashDotted xD José Luis
Re: Para los que no fueron a la debconf
At 11:01 22/07/2003 +0200, you wrote: [snip] Algunos de los jovenes nacionales tuvieron que irse antes porque nesecitaban pillar un vion. Por cierto, tenemos que hacer publica la cancion del seat debianero junto con el mp3 original para que os echeis unas risas. porfa ! X- data -- Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 -- Registered Linux user #66350 proudly using Debian Sid Linux 2.4.21 - ... todos necesitamos creer en algo. - Si, yo también creo... Creo... que me voy a tomar una cerveza. --Sor Trini (Año Mariano)
Re: Camisetas
At 17:05 01/07/2003 +, you wrote: Hola Hablé con Sanguino hace poco de las camisetas que sobraron/devolvieron de los últimos envios (145). La idea que le plantee es venderlas a traves de la tienda virtual de Hispalinux.net http://www.hispalinux.net/tienda/merchandising_prods.html Por aquí hay un grupo de interesados/as. Si se ponen a la venta caen unas cuantas, seguro :D Debian r00lz ! ;)
Red-Handed SCO ?
http://www.theinquirer.net/?article=9952 OK, it's the inquirer It it was proved to be true, shouldn't we *all* Linux users ( as well as Stallman plus the FSF as a whole ) sue SCO for copyright infringement ??? That could be *quite funny* g g Regards, J.L.
Red-Handed SCO ?
http://www.theinquirer.net/?article=9952 OK, it's the inquirer It it was proved to be true, shouldn't we *all* Linux users ( as well as Stallman plus the FSF as a whole ) sue SCO for copyright infringement ??? That could be *quite funny* g g Regards, J.L.
Re: i386 compatibility libstdc++
At 11:36 28/04/2003 +0200, you wrote: We should still discuss an i686 (or i586) optimized port, but fixing the problem will make it possible to seperate the issues. Indeed! This is (suppossed to be)? just a first step, in order to solve the ABI compatibility issue with libstdc++5 An i586/i686 optimized version could be a high win, by any means. Maybe just to shut up those who say RedHat is faster... :-| Arnd J.L.
Re: i386 compatibility libstdc++
At 12:52 27/04/2003 -0400, you wrote: On Sat, 2003-04-26 at 03:56, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. I have a brand new 486-class system with 32MB of RAM. It's less than 6 months old. Please explain how I can get a similar system, running on a similar amount of power, and with no moving parts (i.e., no fans) using, even a P-II. Hey! Where did you get that from? I'd love to have one of those ( specially if they came in a 19 1U form factor or similar !!! ) There are many uses for Debian other than your GNOME or KDE desktop. Surely. This is why i proposed keeping everything compiled for 486 or higher -- that's where the upstream split is, too ... ( we would then need just an small subset of the packages recompiled for i386's libstdc++ ABI ) J.L.
Re: i386 compatibility libstdc++
At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) - Cache ( very much needed, i mught add ) - Pipeline attempt IIRC - Mandatory 32bits Bus/Memory IMHO, since we have concluded there are almost NO true i386 around ( not even for routers ), the first *easy* split would be to drop i386 in favour of i486 for Sarge+ ( does anybody really think i386 will survive another year/year-and-a-half ?? ). This will solve the ABI problem in one, easy, shot This means binary-i386 in Debian will really mean binary-i486 -- I don't see any problems here. We might then try to judge how much of a benefit we can get by moving on to i586+ for the vast majority of the archive ( other distributions support i586+ *only*, so it can't be that bad, can it? ). Retiring i586 right now looks a bit bold to be done right now. I do own a (retired now) 486, with 16MB -- it was really a pain when i last used it[ 2years ago], with SuSE 6.2 [released 1998]. These machines are only good for routers now, which means we could create a subarch, with just the kernel, basic libs, iptables, ssh, security tools and things like that (maybe Postfix/exim/sendmail ? ) -- no need for Apache, nor MySQL/PostgreSQL ( !!! ), especially no need for XFree, Gnome, KDE et al -- and everything would be fine. As a side effect, we would get the basic installation size down to about 50-65MB ( just guessing! ): this can only be an improvement. The smaller machines me or any of my friends/relatives/acquaintances are using are P90 w/32MB, loaded with say, 120GB IDE HDD -- used as servers connected to cable/ADSL lines, running mldonkey, ftp servers, grin -- All running Woody :D This means we shouldn't leave that *whole lot* of users without frequent security updates for Apache, Postfix/exim, proftpd, ... Regards, J.L.
Re: i386 compatibility libstdc++
At 14:17 26/04/2003 +0100, you wrote: I demand that José Luis Tallón may or may not have written... At 19:55 26/04/2003 +1000, you wrote: On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: 1a. create a stripped down version for i386, i.e. required/important and go for i486. Is there much performance improvement in dropping i386 in favour of i486+? - Integrated math coprocessor ( why does libc still check for its availability? ) [...] 486SX. Though I own one, these are not exactly *full* 486, but just the low-cost version... -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | We've got Shearer, you haven't You are taking yourself too seriously. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: llave gpg
At 18:02 23/04/2003 +0200, you wrote: Alberto Gonzalez Iniesta dijo: Pues vaya una mierda de flamewar que vamos a montar si todos estamos de acuerdo. Postfix rulez. Tú lo has querido. Postfix mola, pero mucho más con un messagewall delante. esto... enmedio, porfa ;)
Re: Debian for x86-64 (AMD Opteron)
At 01:18 22/04/2003 +1000, you wrote:
On Mon, 21 Apr 2003 21:18, Thomas Petazzoni wrote:
Why don't we consider the x86-64 as beeing a 64-bits-only architecture
Because we want to run Netscape, commercial games, Frauhofer MP3 en/decoders,
Oracle, and other binary-only i386 software.
If AMD had made a 64bit only CPU and devoted those extra transistors to cache
it would have improved performance for 64bit code. After paying the
performance penalty of a 32bit ISA it makes sense to take advantage of it.
IMVHO, there is an intermediate alternative: why not ...
... create a new x86-64 architecture
... tweak dpkg so that ${DEB_ARCH}==x86-64 admits both i386 and x86-64
binaries;
Naturally, x86-64 (native) would be preferred to i386 when available. If
there is no x86-64 binary, use i386 instead; Sky is blue, life is good ...
so,
- We will have native, optimized, packages for x86-64, thus benefiting
from the increased memory space addressing, extra integer size, Y2K38
compatibility ;) ...
- Since dpkg will allow installing binary packages from i386
- We can have an x86-64 Debian right now :D ( Opteron should be
released tomorrow, IIRC )
- Autobuilders will have much less load -- they need not build
everything *right now*
- We can have an smooth transition to 64 bits
Any comments, remarks, suggestions, etc. very much appreciated
Regards,
J.L.
Fwd: Re: Debian for x86-64 (AMD Opteron)
( forgot to Reply to the list, sorry )
Date: Mon, 21 Apr 2003 20:58:20 +0200
To: Josselin Mouette [EMAIL PROTECTED]
From: José Luis Tallón [EMAIL PROTECTED]
Subject: Re: Debian for x86-64 (AMD Opteron)
At 20:23 21/04/2003 +0200, you wrote:
Le lun 21/04/2003 à 19:52, José Luis Tallón a écrit :
IMVHO, there is an intermediate alternative: why not ...
... create a new x86-64 architecture
... tweak dpkg so that ${DEB_ARCH}==x86-64 admits both i386 and x86-64
binaries;
Naturally, x86-64 (native) would be preferred to i386 when
available. If
there is no x86-64 binary, use i386 instead; Sky is blue, life is good ...
This won't work, because you can't mix 32 and 64 bits code or libraries.
I think the appropriate solution is to make it a completely new arch,
with 32 bits compatibility libraries (at least glibc and xlibs) allowing
to run 32 bits proprietary software.
Correct me if i'm wrong -- you can't run 64bits software with 32bit
libraries, but you can run 64bit and 32bit processes concurrently, right?
Then: package foo64 would require libfoo64 -- apt-get will do the hard work
If there is no foo64, select foo [foo32] instead, which will pull libfoo
[libfoo32] from the archive if needed.
[ sonames would need to be tweaked in the 64bit versions, and some
adjustments might be necessary in the format of 'control' files ]
My point was on easing/accelerating availability of an x86-64 port of
Debian.
I most probably am overlooking something, however if there'd be a PPC64
or something ( transition to 64bits will happen sometime for all 32bit
architectures, i guess ), we would have most work already done... wouldn't we?
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
Regards,
J.L.
Re: Debian for x86-64 (AMD Opteron)
At 19:10 12/04/2003 +0200, you wrote:
On Saturday 12 April 2003 16:58, Marcelo E. Magallon wrote:
Arnd Bergmann [EMAIL PROTECTED] writes:
Every architecture knows where its libraries are installed. One way
would be to make 'dpkg-architecture -qDEB_HOST_LIBTYPE' return either
'lib' or 'lib64' depending on the architecture. You have to do
something like this anyway because the file list and the configure
arguments are also different.
I feel my leg being pulled :-)
Again, with -v -v -v, what do you write in the Architecture field
corresponding to the lib64foo package in the debian/control file?
Ok, now I see your point. What I wanted to do is put 'Architecture: any'
in the control file and use debian/substvars to define the actual
name of the binary package, e.g. 'Package: ${lib}foo'. I suppose there
is a good reason why using a generated package name does not work, so
we have to come up with something else.
Sorry for the confusion.
[ Disclaimer: just subscribed -- caught the thread already started ]
Sorry, i must me missing something obvious, but why would we need lib64foo ?
Why not just define the new architecture x86-64 and have katie/buildd do
the rest?
Users with Opteron/Athlon64 would have the additional bonus of a completely
optimized distro to run ( as good as or better than using a source-based
distribution such as Gentoo ), and it would be completely transparent for
developers...
Anything to do with the ability to mix-and-match 32 and 64-bit code in this
processors?
Arnd
Regards,
J.L.
