Re: Possibly hijacking netcdf
I told someone to go ahead feel free to take it over. I don't remember who. I clearly don't have the time to do a proper job of this. I don't even use netcdf anymore, so I don't really have much motivation to package it. I did start packing the newest version, but I didn't make any real progress. I had a good reason until the dependencies for netcdf 4 were in debian. The responsible thing for me to do at this point is give the package up to another interested party, so please feel free to take it over. Warren Turkal Linux Enthusiast and Libre Software Advocate On Sep 21, 2009 12:47 AM, "Francesco P. Lovergine" wrote: Hi folks after at least other 2 messages sent without answer in the past year and half and the latest below (with the same result at this moment), I'm going to hijack the netcdf package in order to move forward with version 4. If someone had objections about, please talk now or never :) - Forwarded message from "Francesco P. Lovergine" - Date: Mon, 7 Sep 2009 15:33:51 +0200 From: "Francesco P. Lovergine" To: Warren Turkal Cc: fran...@debian.org Subject: Netcdf status User-Agent: Mutt/1.5.20 (2009-06-14) Warren are you still motivated in maintaining netcdf in Debian? Your last update is quite dated and is has been already NMUed a couple of times. If not, we at DebianGis could properly migrate to current version 4 the current version and taking care of migration for squeeze. -- Francesco P. Lovergine - End forwarded message - -- Francesco P. Lovergine
Re: what happened to g77-3.4-doc?
On Thursday 19 July 2007 00:43, Kamaraju S Kusumanchi wrote: > Why I need this:- I was trying to compile refblas3 package with gfortran > instead of g77. I have had a reworked Debian package for refblas3 that uses gfortran for a while. It compiles. However, the regression tests don't pass for some reason. I have posted it at [1]. Would you be interested in checking it out? Feel free to use it to generate a proper Debian package for refblas3 using gfortran. At [1], there is also a directory called cmake_test where I was experimenting with building refblas3 with cmake. Also, you can connect to [1] with read-only webdav if that's useful to you. [1]http://www.penguintechs.org/~wt/debian/refblas3/ wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#428877: ITP: callweaver -- Community-driven open source PBX software
On Friday 15 June 2007 00:46:45 Marcus Better wrote: > It would be helpful to know how it differs from Asterisk, since Asterisk > too supports many of the features you list. Where Asterisk requires copyright assignment to Digium for code incorporated in to the mainline, Codeweaver allows contributors to maintain their own copyright on the code. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Monday 11 June 2007 23:56:16 Kevin Mark wrote: > Oddly enough if you had posted this a bit earlyer, one of the US folks > who will attend Debconf (this year in the UK) could have brought it with > them. This would make it easy to directly give it to many folks who are > part of Debian. Although it may still be possible, if it is done in an > extreamly timely manner, as Debconf is June 17th-23rd. Maybe There > should be some announment a month or two before debconf so that hardware > donations can be co-ordinated around it and the participants I live in Fort Collins, CO. Some of the HP Linux Labs people live here. Are any of them on the list and care to speak up? wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Monday 11 June 2007 21:52:09 Kevin Mark wrote: > As shipping may be a consideration, in the cost-benefit analysis, it may > be useful to say where in the world you are, in a general way, so that > someone in the area, who could use them, could reply. I will ship anywhere in the US. Exporting them would have to be investigated. Thanks, wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SCSI drives for donation
I personally have 6 or 7 U320 73GB 10K RPM SCSI drives that I am not using for anything interesting. Can anyone tell me if these would be useful to Debian or recommend another free software group to donate them? Thanks, wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Monday 11 June 2007 13:09:40 Roberto C. Sánchez wrote: > That may be true when it comes to breakdowns. However, I challenge you > to show me a "cheap" desktop disk that is also SCSI or SAS *and* > hotpluggable. While not SCSI or SAS, there are SATA controllers that support hotplugging drives. wt -- Warren Turkal
Re: Why not move Apt to a relational database
On Monday 04 June 2007 15:23:54 Roger Leigh wrote: > Sorry, but I fail to see the connection between busybox and sqlite. > If enabled, sqlite would be part of dpkg, probably either statically > linked or dynamically loaded. I would think static, for safety. Doesn't Busybox include an implementation of dpkg? wt -- Warren Turkal
Re: start-stop-daemon for user processes
On Sunday 03 June 2007 15:11:36 Vincent Danjean wrote: > To be run by a user, you can look at launchtool (in the package with > the same name). > Description: Runs a command supervising its execution > Runs a user-supplied command supervising its execution in > many ways: > [...] This looks like it may be what I need. The runit solution just didn't seem like it was intended for my use case. I will check this out. wt -- Warren Turkal
Re: Why not move Apt to a relational database
On Monday 04 June 2007 01:34:01 Neil Williams wrote: > That could actually be quite difficult - how would you migrate from one > to the other? Have the raw files and the sqlite cache on the mirrors. Give the local program the option to use either. Then you could use the raw files if the sqlite cache can't be used. > The installer will inevitably use the smallest possible > combination of packages, the finished installation might need to use > sqlite. Besides, you still have the same problems of trying to copy > package sets and having to run sqlite before anything else can be done. I don't understand why you'd have to run sqlite before anything else. It is a library, not an RDBMS like PostgreSQL. > Migrating from a busybox rootfs (without dpkg) would potentially cause > more problems and making busybox depend on sqlite is plain crazy. No need with the above approach, as the dpkg from busybox could still use the raw files. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: start-stop-daemon for user processes
On Saturday 02 June 2007 23:03, Russ Allbery wrote: > Could you say more about why not? It looked to me like you could use its > supervise equivalent without the whole init replacement stuff. I took a closer look. It looked like the runit wanted to replace init entirely. I don't see how to separate the functionality for running and keeping a service started upon user login and stopping it on logout. Do you have any suggestions? BTW, is Debian planning on using something other than init in future versions? wt -- Warren Turkal
Re: start-stop-daemon for user processes
On Saturday 02 June 2007 21:45, Russ Allbery wrote: > Take a look at runit. It's quite a bit like daemontools without the weird > licensing. Runit doesn't appear to be useful for non-system tasks, like starting jackd and restarting it if it dies (i.e. on suspend/resume). wt -- Warren Turkal
start-stop-daemon for user processes
Hello, Is there anything like daemontools in main? I would like it to work with user processes. I would like to use it to make sure a user process stays running while I am logged in. Does anyone have any suggestions? wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python, then C++, or C++ from the start?
On Wednesday 30 May 2007 09:34, martin f krafft wrote: > But I am asking you still: can you think of anything to say against > such an approach? Please don't flame languages or anything of that > sort. The question is just: is it viable for a C++ coder with > a Python proficiency to mockup a new application in Python first? A similar approach seems to have worked pretty well for git. I think that some of the core functionality was C with a lot of scripts for functionality. Slowly, a lot of the scripts have become C code. It seems rational to allow the python and C/C++ code to work together so that you can transition from one to the other and aren't just strictly porting from one to the other at the "end" of the project. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get
On Friday 18 May 2007 08:03, Howard Young wrote: > Thank you for this link. I have read the information but it seems not to > have a specific option for what I want. If you use aptitude for everything, it will keep track of packages that are automatically installed when a specific package is installed. For instance, if I install a package that pulls in libpq4, I can remove that package and aptitude will remove the libpg4 assuming I haven't installed anything else that depends on it. I believe this functionality would address what you want. The key is that you have to use aptitude for all package installation/uninstallation tasks. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: initramfs-tools postinst causes system inconsistency?
On Tuesday 15 May 2007 15:54, maximilian attems wrote: > afaik uswsusp does not support full > 2.6.15 range, > so better stay on the safe side. What about > 2.6.18? I am not sure Debian should be that worried about kernels before the one that shipped with the last stable. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mounting Oracle Cluster Filesystem during boot
On Saturday 05 May 2007 19:32, Patryk Ściborek wrote: > Hello everyone! Hi. :) *snip* > In my opinion second solution is better. I suppose that similar problems > may occur with other cluster file systems like GFS, so this problem > should be solved in generic way. I agree that this should be solved in a generic way. In order to make this more useful, shared network block storage like AOE and ISCSI should be part of this solution. wt -- Warren Turkal
Re: Bug#422297: ITP: g95 -- The G95 fortran compiler
On Friday 04 May 2007 16:41, Kevin B. McCarty wrote: > Do you happen to know whether g95 uses the same ABI as either gfortran > or g77? Because if not, maintaining FORTRAN library packages in Debian > is going to become even more complicated, unless we are satisfied with > just providing the g95 compiler but not providing sets of libraries that > work with it. I am pretty sure that g95 doesn't use the same ABI as gfortran. However, I believe that it does use the g77 ABI. I would say that we should start thinking about a Fortran policy. I would say that Debian's default compiler for Fortran should be gfortran from the GCC. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
New netcdf packages in experimental
NetCDF-using package maintainers, I have had new NetCDF packages uploaded to experimental. Probably the biggest change is that they use gfortran instead of g77 for building the Fortran code. I don't believe that any of the packages using netcdf as a build-dep actually use the Fortran API and should not be affected by the change. The following packages build depend on the NetCDF library: dx gdal genesis gmt grace grace6 gri kst labplot minc nco netcdf-perl octave2.1-forge octave2.9-forge python-scientific If you are responsible for any of these packages, could you please try to build them against the netcdf library in experimental? If you have problems, I will be more than happy to help find and fix the issue. If I am missing any packages, please let me know. Thanks, wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should an init-script print output, if verbose is set to no in /etc/default/rcS or by /lib/init/vars.sh?
On Saturday 28 April 2007 15:23, Marc Haber wrote: > The LSB init script stuff is a red herring anyway since the Interface > is badly designed and utterly incomplete. Init scripts are therefore > forced to abuse the provided functions if something "special" is > needed. Could you elaborate on this thought? It may be useful to think about for extending the LSB semantics and rolling them into the standard. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
On Monday 23 April 2007 12:58, Alan Ezust wrote: > let's say you need to build from source a program such as "gimp" which has > many library dependencies. You don't know what they are, and you want > debian to auto-install the -dev packages you need. apt-get build-dep is > your friend. Speaking of which, will aptitude ever have this functionality? It would be nice to get the markauto goodness from aptitude when installing builddeps. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use bz2 not gz for orig.tar ?
On Wednesday 11 April 2007 20:52, Don Armstrong wrote: > Presumably the wig-and-pen source format will (eventually?) support > this? Is progress on dpkg-source v2 actually being made? wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On Tuesday 10 April 2007 07:43, Tshepang Lekhonkhobe wrote: > > I may have exaggerated by saying 20 years, but I will not settle for > > less than 10. And we need those anyway to compare results obtained by > > one software against the other. > > This is interesting. I often hear people citing pros and cons of FLOSS > and commercial stuff, but don't remember anyone stating such > extravagant development gaps as 10 years or so. I'd like to hear > opinions of others who have also used those Cplex Maple, and whatever > else you may have in mind. This however brings to mind libre CAD stuff > which truly lags behind. People wouldn't use those programs more than the free equivalents if there weren't some reason. Sometimes that reason is that the proprietary solution has a larger library of extras (libs, etc.) around it that makes it easier to quickly do something without reinventing the wheel. Sometimes the reason is as simple as someone doesn't want to have to learn a new software package or port all there stuff to a new software. These are hard barriers to overcome. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ethernet interface numbering in etch
On Tuesday 27 March 2007 11:55, Matthias Julius wrote: > I almost wrote that myself, but they have different names and dont > compete for numbers. That's not necessarily true. My IPW2200 has eth2 on my laptop. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ethernet interface numbering in etch
On Monday 26 March 2007 16:00, Bernd Zeimetz wrote: > you could mount them by UUID instead of the device name. Don't forget having to use a static fsid parameter in /etc/exports for the affected mounts. Otherwise, the device major/minor numbers for the mounted devices still affect what machines that currently have the volume mounted see. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems packaging a kernel using cdbs
On Monday 26 March 2007 12:09, Alan Ezust wrote: > I tried building using make-kpkg with --initrd binary options, and ended > up with a cpio archive. Why? I have no idea. An initramfs is a cpio archive. I am assuming that are you referring to the file created after the kernel is installed. Is that correct? wt -- Warren Turkal
Re: Ethernet interface numbering in etch
On Monday 26 March 2007 10:11, John Goerzen wrote: > I have spent the past few days trying to figure out why some of our > machines seem to have ethernet interface numbers that jump around -- > eth0 one day, then eth4 or eth5 another. As a corollary to this, I have machines where the disks swap device files on each boot. It's pretty annoying when my nfs volumes switch which device name is used to mount them. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
On Monday 12 March 2007 10:08, Hendrik Sattler wrote: > Is there any real need for such a tool in Debian? > It's not an administrative tool and it's obviously not meant for security > tests. I just can't see what the normal use of this tool would be. Educational reasons. I could see someone demonstrating breaking weak passwords with such a tool. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Wednesday 28 February 2007 01:19, Hamish Moffatt wrote: > In all fairness, you didn't seem to comment on his response to your > suggestion. I did comment on his suggestion. "Yes, it should start before NFS because its not just mounting a file system like NFS. It needs to make the block devices available." Not to mention there was a thread on debian-devel at the time where I thought he was MIA because he was so unresponsive. > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552;msg=30;att=0). > This seems to be more of a case of not liking his solution than having a > legitimate grievance? The solution flat out does not work. I mean, as his scripts are written, the machine hangs on shutdown. Here's the basic happenings of that bug. Sept. 14 - I send initial bug report. Oct. 2 - After 3.5 weeks the maintainer releases a new package, claiming it fixed the bug. I then attempt to point out that the script is not working. Oct. 3 - I attach my implementation of the init script that at least lets the filesystems mount. Oct. 9 - I try to get the maintainer to do something about letting it propagate to testing as I think the "fix" is not a fix. I do not escalate the bug myself because I am not the maintainer. Oct. 12 - The maintainer replies only because a thread on debian-devel[1] calls into question his ability to maintain the package. I then respond with a comment on the only thing relevant in the email (the order of start scripts and how AOE is different from NFS). I provide a link to Coraid's (the implementer of aoe in the kernel) documentation about setting up this hardware. Nov. 8 - I document why the new revision of the package doesn't work even for the mounting case, and I document that udev may be the right way to completely avoid the race condition. I'd like to point out that the above occurred over about a two month period. One response from the maintainer that was prompted by pinging debian-devel is ridiculous. As you can see there is only one human response in there, and I did respond to the critical question of his email. He seems to only respond when things get emotionally charged or when I publically tried to see if some other developer could comment on my changes. The maintainer's behavior made him very discouraging to work with. I just stopped dealing with him after a while. It hasn't stopped me from filing other bug reports. You may think I'm a whiner, but the fact of the matter is that my hardware flat out does not work with his scripts, and he was unresponsive to my suggestions for fixing them. He didn't even want to consider the use case that someone might want to treat a block device like a block device instead of a filesystem container. If you don't want to consider it non-responsive, it was at least really unproductive and frustrating. [1]http://lists.debian.org/debian-devel/2006/10/msg00451.html wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
This is from the perspective of a non-DD systems administrator. While most maintainers are good. Some are pretty lousy with regard to addressing issue even when one is proactive about finding a solution. On Monday 26 February 2007 14:55, Don Armstrong wrote: > I don't believe any maintainer of > packages, given enough hours in the day, would fail to respond to > reasonable bug reports. I don't agree with this statement. I have dealt with some maintainers that refuse to acknowledge a bug when I report it. At the worst, the maintainer makes some wild assumption and code dumps a new revision of their package. That action causes me to have to totally work around their packages to make things work. The aoetools package is a fine example of this phenomenon. I have to completely override what that package does with it's init script to get my aoe devices working. [1] is a good example of a maintainer refusing to acknowledge any level of my trying to help find a solution for a bug. Paraphrased, the maintainers response was it won't work, with no interest in my use case (that of using block storage hosted on a network like aoe or iscsi), even when I tried to produce some fixed that worked for me. I have had to write initramfs-tools scripts and shutdown scripts to work around the package. These scripts live at [2]. I am interested in getting a more robust framework for this type of storage integrated into Debian so that AOE and ISCSI storage can be used more effectively, but when I bring it up, I just get a the-maintainer-is-right slap down, and the maintainer has no interest. I even provided some prototype scripts to get my use case working. The aoetools are in such bad shape that they can't even be used with the ocfs2tools (same maintainer) without a lot of manual work. As another data point, [3] could be fixed with my initramfs-tools scripts. I am sure that the scripts are not generic enough to go in unchanged, but a little respect from the maintainer, and maybe some help getting this use case working would be appreciated. Also, that same maintainer has been downright insulting, which doesn't make me want to help out at all. [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552 [2]http://penguintechs.org/~wt/debian/aoe_stuff/aoe-block.tar [3]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408044 wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: block device served over network connections
On Wednesday 20 December 2006 17:29, Ron Johnson wrote: > Roll a custom kernel that either statically links the modules, or > loads them in your preferred order? I don't see how this helps me bring up the network at the right time. I guess you are suggesting this in addition to shuffling around init scripts. I have a working solution that doesn't require building modules statically into the kernel. I would like to see a mechanism to support this type of use case (network hosted block level storage) in a more generic way so that I (and others) don't have to reinvent the wheel when doing this. If that wheel has not been invented, I would like to help do so. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: block device served over network connections
On Wednesday 20 December 2006 02:59, Wouter Verhelst wrote: > Just rearrange the initscripts so that mdadm is ran _after_ aoetools. If it were only that easy, I would do that. However, there is much more to it. For instance, the mdadm and lvm and evms run in the initramfs. Also the ethernet card receiving the AOE data needs to be up to talk to the devices, and thus needs to be up. An IP is not neccesarily needed for AOE (think "ip link set eth1 up") unlike ISCSI. I wish there were a way to make the aoetools script work, but it is fundamentally broken. I would like to work with the maintainer, but he has been pretty unresponsive to this use case. I have now added the scripts to make it work from initramfs and to make sure the network is up during shutdown at the right time to let the lvm subsystem properly shut down. I also disabled the aoetools scripts. I have posted the required scripts at [1]. Granted, they are a total hack, but they work. I wish someone smarter than me about this stuff would take a look. As one improvement, I could probably use the /etc/default/aoetools in the initramfs script. wt [1]http://penguintechs.org/debian/aoe_stuff/aoe-block.tar -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
block device served over network connections
DDs, I am looking for some info on this subject. I have looked at both the aoetools and open-iscsi for a solution to the following problem. I have a block device that is served over aoe. Basically, I would like to take two of these devices (e0.0 and e1.0) and create a raid1 with software RAID. However, I am not really sure how to solve this one. I am emailing here because I think the infrastructure to do such a thing may not exist in Debian. The basic problem is the network devices that receive info related to the block device must be up early enough that the mdadm discovery has not happened. It would be fairly easy to right a script that simply does "ifconfig eth0 up" and performs discovery (additionally disabling /etc/rcS.d/S41aoetools and essentially doing my own thing), but I would like to know if there is official Debian infrastructure for this sort of thing. Are there any other packages I should be looking at to make this happen? If not, maybe this is something that should be considered by some people who care as network based block storage is getting more common. With NBD, AOE, and ISCSI (and others I am sure), I don't think that each package should implement their own way of dealing with this problem, and I hope some kind of normalized way of dealing with this problem can be made available, if it is not already available. Thanks, wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not use [EMAIL PROTECTED] for bug ping-pong
On Tuesday 12 December 2006 04:05, Don Armstrong wrote: > [If you're doing this, you > better have already written (or gotten someone else to write) the > patch to fix whatever bug you want reopened and fixed; otherwise the > ctte will likely close and ignore your bug report too.] So even if it's a relevant bug, the result will never be to leave the bug open until it's fixed? wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
On Tuesday 07 November 2006 10:49, Matthias Julius wrote: > But, I am not sure whether you can count them all as individual > installations as many of those probably get installed on one system > and then copied to another. And they are managed by only a few admins. Preseed is your friend. It's extremely easy to setup netboots that are customized however you want these days. There is no reason you can't install nfs stuff as part of your preseed. We use a postinstall init.d script to install extra packages we need, like gfortran and other goodies. > I would guess that most people who install a linux system don't need > NFS. I think that is a largely fair statement. None of my home systems or laptops use it. > And actually, NFS us not required to run Debian. This is the coup de grace. Why should something be essential if it is not really, well "essential"? > Do I don't think it > needs to be in the default installation even if 70% of the users will > use it. IMHO Word. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thanks!
On Thursday 26 October 2006 16:42, Ben Finney wrote: > It's great to give positive feedback, and even better that you've done > so in public. I'd call it morale-boosting, certainly not unproductive. I guess some of us just forget how great Debian is or get blinded by the vision we have that Debian will be. To all the developers, thanks for your tireless work on Debian itself and evangelism for the Debian cause. Thanks, wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc6 2.5 and Etch
On Wednesday 25 October 2006 20:42, Kevin Mark wrote: > When Sarge was released, amd64 was not officially released but had an > unofficial release. why not do the same with the hopes tha etch+1 will > see m68k in relase shape? AMD64 is a modern architecture. M68k is an architecture that saw its prime many years ago. AMD64 also has a much larger user base considering that most of the m68k machines I know of are more toys than workhorses. Also, I think it could be that the Debian folks saw a strategic advantage is shipping a more normal version of Debian for the AMD64 arch. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
On Friday 13 October 2006 09:18, John Goerzen wrote: > Why are we leaving CLI users out in the cold? I would guess that no one has developed the requisite components for a CLI interface. This is clearly something that no developers (Debian or otherwise) have picked up as an important or fun project. I am not sure how much utility having it for the CLI would be considering that pmount is available to do it manually. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: support of aoe devices and aoetools package
On Thursday 12 October 2006 17:50, David Martínez Moreno wrote: > El miércoles, 11 de octubre de 2006 17:44, Warren Turkal escribió: > > First of all, the implementation aoetools include to enable mounting the > > aoe devices at boot time is severely lacking. This support was > > implemented in response to bug #387552 [1], which is now closed. They > > depend on a filesystem argument in fstab called _netdev, and they do not > > work with lvm > > Argument that I extracted from S35mountall.sh and mount manpage... > > I do not really know much about LVM and its shortcomings or requisites, > and how it deals with networked volumes, but I am sure it is not as easy as > you draw it. Consider that it is not only a networked volume. It is also a network block device. You treat it something like an NFS mount in your implementation, which it is not what it is. BTW, my script is loosely based on an example on the coraid support website (the only manufacturers of AOE devices that I am aware of) at [1]. > > (or any other dev mapper based system) at all as far as I can tell. I > > contributed a new init script [2] that attempts to address these > > shortcomings while removing the need for the special fstab option. I > > submitted this info to bug #387552, but have received no response yet. I > > was tempted to reopen the bug, but I didn't think that'd be proper. I > > have also CCed the maintainer on all mailings to make sure that he got > > it. > > As I replied in a former mail, your approach is simply broken. I didn't have any replies mentioning my implementation from you until a few hours ago. How was I supposed to know your reaction to it if you didn't even respond until today? > You > decided to unconditionally initialize network before stage 40, in fact, > even before stage 35 (mountall), and with the first lines of your script > being: > > modprobe -r aoe > modprobe aoe > > mount /usr > > sleep 1 This script implemented the version for when the aoe tools were located in /usr. Also note that this script was a prototype. I was willing to put more time once I got some feedback from you. Instead I got a package bomb with an underfeatured implementation. If you don't like the unchecked interface activation Also note, enabling the ethernet device doesn't enable the TCP/IP unless you assign an address. The reason for enabling the interfaces is to enable the aoe as block devices that can be used for lvm physical volumes. > You are *not* taking care of _anyone_ having a different setting from > yours. As I told you before, this kind of scripts are nice for your > homegrown machines, but not for general use. Your script is not good for general use. You don't allow any more abstract uses of the block devices. You only allow laying a filesystem directly on them with no device manager stuff (lvm, evms, etc.) to manage it. My script was the beginning of a prototype implementation. If you had replied to it before now, maybe I would have known your objections in a reasonable time frame instead of being surprised by an implementation that I felt was lacking. > > I am basically writing here to see what I can do to at least get someone > > to look over the idea presented in the script to see if they think it > > would be a good idea. It is also frustrating to not receive any response > > when I clearly have a personal stake in this matter (that being that I > > have to support aoe based hardware). > > I am sorry for not being much more responsive, really. Apart from that, > given that your first try to compose a working 11-1 aoetools release was > not very 'careful' (bashisms, missing variables, and so on), and your > second try to solve another problem on this matter was simply to mess with > the init stages in runlevel S, you might understand that I did not make a > lot of effort to reply to you in time. Thanks for finding the bashisms in the aoe-* scripts. Maybe that lack of transparency led to this misunderstanding? Your implementation is not any better. Releasing what you did without input of actual users who have a stake in its use is somewhat disheartening. > If you want, we can forward this issue to the Debian Technical Comitee, > where they will study this issue and make an official *technical* > (non-emotional) report. If they say so, I will accept to configure network > interfaces before stage 40, but not before that. I don't think we need to bureaucracy of the tech committee. I would rather rationally present my functional requirements and see what kind of solution we can come to. However, without any kind of response until today, I didn't feel that was happenin
support of aoe devices and aoetools package
Debian Developers, I hope this is the right forum to express this idea. I have not received any feedback from the maintainer of the aoetools package, so I wanted to voice my concerns over that package in front of a wider audience as I don't want to see the aoetools ship in the crappy form in which they now exist for Etch. I have sent many messages to bugs and received little to no correspondence from the maintainer. First of all, the implementation aoetools include to enable mounting the aoe devices at boot time is severely lacking. This support was implemented in response to bug #387552 [1], which is now closed. They depend on a filesystem argument in fstab called _netdev, and they do not work with lvm (or any other dev mapper based system) at all as far as I can tell. I contributed a new init script [2] that attempts to address these shortcomings while removing the need for the special fstab option. I submitted this info to bug #387552, but have received no response yet. I was tempted to reopen the bug, but I didn't think that'd be proper. I have also CCed the maintainer on all mailings to make sure that he got it. I am basically writing here to see what I can do to at least get someone to look over the idea presented in the script to see if they think it would be a good idea. It is also frustrating to not receive any response when I clearly have a personal stake in this matter (that being that I have to support aoe based hardware). wt [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387552 [2]http://bugs.debian.org/cgi-bin/bugreport.cgi/etc.tar.gz?bug=387552;msg=20;att=1 wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mozilla 1.6b
Thomas E. Vaughan wrote: *snip* > Any help appreciated. Did you see the mozilla-snapshot package? Try installing it. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org
