Is Daniel Lutz MIA?
Hi all, Does anyone know the status of Daniel Lutz? I had mailed him a while ago asking if he needs any help with the synergy package; the last upload of the package was 14 months ago, with quite a few bugs open that had not been dealt with, and a new major upstream stable release had been made in the end of 2004. Can anyone confirm that he is still active? Granted synergy is still in an okay shape, but if Daniel is indeed MIA, I will volunteer taking over maintenance of the package. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Daniel Lutz MIA?
On Sat, Jan 22, 2005 at 02:26:48PM +0100, Jeroen van Wolffelaar wrote: > Firstly, if you mail about someone on a public list, it is polite to > cc the person in question. Especially since google might start to show > your very message soonishly in its results. Now you mentioned it, indeed I should have remembered to cc Daniel. Hopefully this would not cause too much discomfort on his part, since I had already emailed him in private before (and received no reply yet). > Secondly, yes, I've been informed that there was not many acitivity > lately, but didn't yet follow up. I'll do so soon. > If you want to privately notify someone about suspected inactivity, > you can do so via [EMAIL PROTECTED] Could you explain these two bits? (No, this is a serious question.) I was following Section 7.4 of the developer's reference, and private notification of suspected inactivity through [EMAIL PROTECTED] is not listed anywhere in that section. Contacting QA is supposed to be the final step after you have looked at his packages, inquired on -devel and such to make sure that the developer is indeed missing. What happens after a message is sent to [EMAIL PROTECTED] You mentioned that you will follow up soon, and what is your (or QA's) role in this procedure? And finally, are there plans to update the Developer's Reference to reflect this change in standard procedure? Regards. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian boot disks with HPT 366
Jeff Licquia <[EMAIL PROTECTED]> wrote: > On Sat, Mar 04, 2000 at 03:28:51AM -0800, Anant Kabra wrote: >> Hi, >> >> Is including the HPT366 controller in the Debian boot >> disk controller something being considered? If not >> could someone point me to the sources from which the >> debian boot/root disks are made? > My main problem at this point is that I still cannot boot from the > disk on the HPT366 controller, and thus am forced to boot from > floppy. That's more of a laziness/priority issue for me, though. > Also: Rather than fight with the boot floppies on potato, I installed > slink and dist-upgraded to potato. For anyone who may wish to have more information on the HPT366 issues, here is a link you might find useful: http://www.csie.ntu.edu.tw/~b6506063/hpt366/ I have not looked into the potato boot disks yet, but if they decide to go for HPT366 support, in addition to the patched kernels, please remember to add the corresponding device files into /dev. -- Chuan-kai Lin
New key signing coordination page
Greetings all, With the help of Domenico Andreoli, I have revised the Debian (NM process) key signing coordination page. It is located here: http://oink.cc.ntu.edu.tw/~cklin/signing/ Now the operations are fully automated, with a PostgreSQL database in the back holding all information. The package, including the PHP script and some other documents, are released under GPL and also available from the page above. As always, feedbacks are welcome! -- Chuan-kai Lin
Re: What do you wish for in an package manager?
Ethan Benson <[EMAIL PROTECTED]> wrote: > the debian packaging system answered most things i want from a > packaging system. what exactly is missing/wrong with the debian > packaging system that makes you feel the need for wheel reinvention? I also cannot see anything wrong with the Debian packaging system, but that is just you and me and perhaps some others. From an engineering point of view, true, there is no point in fixing something that is not broken, but from a researching point of view, trying out new things is always desirable, because it increases the diversity of our thoughts. Let's say, what is wrong about the design of cockroaches? They are very strong and flexible, capable of surviving almost in any kind of rough environments. Cockroaches are perfectly fine creatures. The Debian packaging system may also be perfectly fine, but it would most definitely not be the end of history. There are rooms for snakes, birds, dogs, cats, monkeys, Homo Sapiens, and Robo Sapiens. Sometimes trying out different things are just for fun; besides, it is his time. But such activities are important in the long run. I would say this to the original poster: go for it, but please do not invent the same wheels again. Try something different. -- Chuan-kai Lin
Anybody seen Loic Prylli lately?
Greetings, Does anyone know where Loic has been lately (i.e., for the past two years or so)? AFAIK his last package upload was in November 1998, and the mail I sent him about whether he needs help with mailx has generated no reply. Since mailx is important, if the maintainer is indeed MIA, somebody should take over this package and jove. I would volunteer for mailx in the unlikely event that nobody else wants that package. -- Chuan-kai Lin
Re: Accepted fam 2.7.0-8 (source i386)
On Mon, Aug 29, 2005 at 08:09:06AM +0200, Aurelien Jarno wrote: > Chuan-kai Lin a ?crit : > > * Make libfam0 Provides libfam0c102 > I am afraid you can't do that. libfamc2 does NOT provide > the same interface as libfam, so they are both incompatible. It turns out that the published public interface of libfam as specified in fam(3) is purely in C (that is, C++ is used only internally), so libfam remains binary compatible across the g++ ABI change. This observation was pointed out to me only very recently, otherwise maybe we could have avoided the package name change altogether. See http://lists.debian.org/debian-release/2005/08/msg00090.html for discussions related to this change. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted fam 2.7.0-8 (source i386)
Russ Allbery <[EMAIL PROTECTED]> wrote: >> For more information see: >> http://lists.debian.org/debian-devel-announce/2005/07/msg7.html > This reference doesn't help with the question of libraries that use > C++ internally but don't expose a C++ interface. You are absolutely right about that. However, like vorlon, I had trouble remembering where the original discussion took place, so I supplied this link instead. If you inspect libfam.so.0.0.0 with readelf, you will see that it technically does export some C++ symbols. However, since none of those symbols are documented as part of the fam API, changes in those symbols should be pretty harmless. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted fam 2.7.0-8 (source i386)
Adeodato Sim? <[EMAIL PROTECTED]> wrote: > Changelog entries that make other developers go like, "huh, wtf?", > and force them to investigate a bit are, IMHO, a bad thing. Message received loud and clear. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#547375: ITP: mdm -- Utilities for single-host parallel shell scripting
Package: wnpp Severity: wishlist Owner: "Chuan-kai Lin" * Package name: mdm Version : 0.1.2 Upstream Author : "Chuan-kai Lin" * URL : http://mdm.berlios.de/ * License : Apache License 2.0 Programming Lang: C Description : Utilities for single-host parallel shell scripting The Middleman System (mdm) is a set of utilities that help you parallelize your shell scripts. Simply label the commands to run in parallel, and the System automatically exploits every parallelization opportunity that arises at runtime. You can also specify dependency between commands so that they run in an appropriate order. Comes with an ncurses-based monitoring console. Compatible with xargs, find, make, any shell, together, in a script or interactively. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]
On Mon, Mar 09, 2009 at 11:40:51AM +0100, Samuel Thibault wrote: > A lot of applications (including md5sum) would not necessarily print > their output atomically and then you get mixed output. Either we add > the option to findutils, or we package parallel. It appears to me that you can get the same functionality by using xargs with an adapted version of annotate-output(1) which is a part of devscripts. Are there other reasons to use parallel? -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]
On Mon, Mar 09, 2009 at 10:57:57PM +0100, Samuel Thibault wrote: > I thought at first "it's not particularly convenient", then "well, so > what". Now I'm thinking "Mmm, but people won't know they should do it > and blame xargs for being broken". Also annotate-output is not enough > when programs e.g. output Packages entries, which not only should be > line-atomic, but also paragraph-atomic... Below is what I had in mind when I mentioned adapting annotate-output to a different "atomic-output" script. This script is usefull not just with "xargs -P", but also with "make -j" and with standard background jobs (shell & operator), all of which produce mixed output. Similarly, about matching the number of parallel jobs with the number of processors/cores, we can write a script "ncpus" which returns the number of processors/cores/hyper-threads. You can use the ncpus script with xargs, with make, or with my new project mdm (mdm.berlios.de)... I consider separating these concerns (output management, processor thread detection) into small, separate, and reusable scripts a cleaner solution. Of course, doing it this way requires some user education, so a few manpage updates (for example, adding atomic-output and ncpus to the SEE ALSO section of xargs) may be in order. -- #! /bin/bash # Display stdout and stderr output after program termination # Adapted from annotate-output by Chuan-kai Lin # Original annotate-output author info and copyright notice as follows # this script was downloaded from: # http://jeroen.a-eskwadraat.nl/sw/annotate # and is part of devscripts 2.10.46 # Executes a program annotating the output linewise with time and stream # Version 1.2 # Copyright 2003, 2004 Jeroen van Wolffelaar # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA OUT=`mktemp /tmp/atomic.XX` || exit 1 ERR=`mktemp /tmp/atomic.XX` || exit 1 echo "-- `date +%H:%M:%S` Started $@" > $ERR echo "-- STDERR" >> $ERR echo "-- STDOUT" >> $OUT "$@" >> $OUT 2>> $ERR ; EXIT=$? cat $ERR cat $OUT echo "-- `date +%H:%M:%S` Finished with exitcode $EXIT" rm -f $OUT $ERR exit $EXIT -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
