Re: Running a 32bits on debian amd64 system
On Mon, Jul 13, 2009 at 5:41 PM, Cyril Brulebois wrote: > Which obviously hadn't been updated in *years*. RT*appropriate*FM. 1. This is the #1 link on a google search, 2. this is listed as *Please either ask in IRC channel if unsure or refer to the The Debian GNU/Linux AMD64 HOW-TO for a more up-to-date manual.* From: http://wiki.debian.org/DebianAMD64Faq Would you be kind enough to actually quote the document (URL) which you call 'appropriate' Thank you. -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
On Tue, Jul 14, 2009 at 5:04 PM, Johannes Wiedersich wrote: > Mathieu Malaterre wrote: >> You do not need to be rude when I explicitly quote the actual doc I am >> reading, which obviously should not recommend the use of chroot > > FWIW, this is the wrong mailing list for that kind of question. People > tend to be more helpful, if the correct form and forum/list is chosen > (debian-user or debian-amd64 in this case). Please also search the > list's archives. I see... Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
At Wed, 15 Jul 2009 10:24:06 +0200, Mathieu Malaterre wrote: > > On Mon, Jul 13, 2009 at 5:41 PM, Cyril Brulebois wrote: > > Which obviously hadn't been updated in *years*. RT*appropriate*FM. > Would you be kind enough to actually quote the document (URL) which > you call 'appropriate' As several people already pointed out, 1) schroot is most likely the answer to your original question. It has reasonable docs included with it. 2) debian-devel is not the right venue for this discussion. Thanks for not pursuing the question of who was rude to whom or did or did not read the right thing any further, at least on this list. All the best, d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Chegou uma fotomensagem Vivo
quarta-feira, 15 de julho de 2009 09:56:00 Olá, A Vivo-Brasil Temuma fotomensagem para voce. Remetida por, 8207 Paravisualizar a Vivo Fotomensagem Clique no link abaixo: http://www.vivo.com.br/clientes/mensagens/ver_mensagem.php?view=000475367865234 Umabraço Equipe Tim Brasil. Vivo BRASIL - Todos os DireitosReservados - Empresa Brasileira de Telefonia Movel2009
Re: remastering ISOs to append boot options
MaTa, le Sat 11 Jul 2009 18:21:16 +0200, a écrit : > The PC have a RJ-45 connector? Can be that a "net plu"g is a serial console > too. It could not have. My question is about rs-232 console. > I have installed Debian in SunFire V120 (Sparc maquine with RJ-45 connector > "serial console") through hyperterminal with the standard Debian installation > CD > > A possible alternate way can be a preseed installation (a preconfigured file) Ok, but how do you proceed? Don't you need to either pass options to the kernel or prepare a particular image with the preseed config file? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
* Cyril Brulebois: >> You do not need to be rude when I explicitly quote the actual doc I am >> reading, which obviously should not recommend the use of chroot > > Which obviously hadn't been updated in *years*. Can we move the content to a different URL and replace it with more helpful pointers? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
2009/7/15 Samuel Thibault > MaTa, le Sat 11 Jul 2009 18:21:16 +0200, a écrit : > > The PC have a RJ-45 connector? Can be that a "net plu"g is a serial > console > > too. > > It could not have. My question is about rs-232 console. > > > I have installed Debian in SunFire V120 (Sparc maquine with RJ-45 > connector > > "serial console") through hyperterminal with the standard Debian > installation > > CD > > > > A possible alternate way can be a preseed installation (a preconfigured > file) > > Ok, but how do you proceed? Don't you need to either pass options to > the kernel or prepare a particular image with the preseed config file? > The preseed file it's "only" a text file with options that you can choose in installer predefined in a file. To install a system using it needs to "remaster" de CD with a little modification in boot options and include the preseed file. It's no very complicated A little/not exactly "quick guide" can be: (I'm not and expert, sorry if I'm wrong and for my english): 1) Copy all contents of the media (CD/DVD) into a local directory: mkdir /tmp_dir mount /dev/cdrom /media/cdrom rsync -a /media/cdrom /tmp_dir 2) Modify a line in /tmp_dir/isolinux/txt.cfg file: append vga=normal initrd=/install.386/initrd.gz -- quiet to append vga=normal initrd=/install.386/initrd.gz preseed/file=/cdrom/preseed.cfg -- quiet 3) Copy preseed file to root tmp_dir folder cp some_location/preseed.cfg /tmp_dir/preseed.cfg 4) Rebuild the iso file with: cd /tmp_dir mkisofs -r -V "Custom Debian Install CD" -cache-inodes -J -l -b isolinux/isolinux.bin \ -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table \ -o outputdir/modified_image.iso ./ (like the instruction /media/cdrom/.disk/mkisofs ) I recomend (I'm not an expert) to search too about "debconf-get-selections --installer", "DEBIAN_FRONTEND=text" and HOWTO remaster/rebuild a Debian image. :P http://www.debian.org/releases/lenny/i386/apb.html.en http://www.debian.org/releases/lenny/example-preseed.txt http://wiki.debian.org/DebianInstaller/Preseed etc... > > Samuel > > > -- > To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > >
Re: remastering ISOs to append boot options
MaTa, le Wed 15 Jul 2009 22:40:28 +0200, a écrit : > 2009/7/15 Samuel Thibault > > > I have installed Debian in SunFire V120 (Sparc maquine with RJ-45 > > connector > > > "serial console") through hyperterminal with the standard Debian > > installation > > > CD > > > > > > A possible alternate way can be a preseed installation (a preconfigured > > file) > > > > Ok, but how do you proceed? Don't you need to either pass options to > > the kernel or prepare a particular image with the preseed config file? > > The preseed file it's "only" a text file with options that you can choose in > installer predefined in a file. To install a system using it needs to > "remaster" de CD with a little modification in boot options and include the > preseed file. It's no very complicated That's precisely my point. You are saying it's not very complicated, but it's not very trivial either (no need to give me info, it's already in the wiki etc), while I think it could be trivialized with a few helper tools, I'm just wondering where such tools could be maintained and advertized. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Sat, 04 Jul 2009, sean finney wrote: > > I believe it's important to be able to know where the patch came from. > > I do think that knowing where the patch came from is very important, > and one of the main driving rationales behind this proposal. > > but more than a URL or a revision/commit id, and something that might > need to be kept up-to-date? what's the benefit of having it be in > such a strict and machine readable format? what benefit will a parser > provide us being able to figure this out over us just reading it ourselves? Distribution-wide statistics. But I agree that this benefit doesn't warrant that this categorization be made mandatory. So I suggest to make that prefix optional like you suggested: > at the very least, could "other" be implied with the lack of this field? > i.e., it seems much more natural to say > > Origin: http://blah/foo.html > > and allow the keywords like "upstream" to be used as optional sugar to > add further information. Ok. > > Are you saying that you don't want Bug- but only Bug without > > any requirement to indicate the vendor ? > > > > I think it would be bad because it would not allow to differentiate the > > upstream bug url from the others. > > is there a benefit to differentiating in a machine readable way? if a > human reads that, they should by context be able to tell which references > the upstream (i.e. bugs.project.net), vs. debian (i.e. bugs.debian.org) vs > some other vendor just by reading it. > > if there's a rationale, i think it should be included in the DEP to > clarify why this is important. for example, is it so that the patch > can be traded between distros with minimal fuss to the headers? Yes, and also upstream is the central reference so if we want to return/display a single bugtracker entry, we should be able to select the upstream one when available. > Origin: Some User > > okay, maybe that should be Author, but then why have an additional and > duplicate field "Origin: other, submitted by..." requirement? Ok, let's make Origin optional when there's an Author field. > On Wed, Jul 01, 2009 at 02:08:28PM +0200, Raphael Hertzog wrote: > > That said, supporting the "patch as script" case needs some trickery to > > be able to reuse existing parsers (stripping "# " before passing lines > > to the parser). But allowing invalid lines as comments in the middle will > > make it completely impossible to reuse standard parsers. > > what about allowing the freetext preceeding or following the fields, > but specifying the fields are to be uninterrupted? normalizing that > into something that you could throw at a standard parser is only a > handful of lines of code at most, and if you're already doing some > trickery wrt dpatch's '#' that's a pretty marginal cost. How do you expect to recognize the real starting point for the fields? The freetext might contain text that look like field names at the start of a line... I don't think that requesting fields to be first in the patch file (except shebang lines) is a real burden for maintainers... What do others people think ? > On Fri, Jul 03, 2009 at 02:07:15PM +0100, Jon Dowland wrote: > > One thing I would like to see patch metadata help > > facilitate is patch review. At the moment the "Reviewed-by" > > header proposed would allow a tool to ensure at least two > > sets of eyeballs had seen a patch; however, patches can go > > stale. I think some chronological information is needed > > alongside the review. I propose a "Last-Reviewed" header to > > capture this information. > > seems reasonable... Given that we can have multiple Reviewed-by fields, how would both fields be linked together? I think we should rather recommend to include a timestamp in the review itself (supplementary lines in the Reviewed-by field?). Is it important to be able to automatically extract that information or is that mainly for the maintainer's consumption? Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On Fri, 03 Jul 2009, James Westby wrote: > To my reading it is not clear whether this is valid: > > #!/usr/bin/dpatch-run > # > # Description: ... > > and I think it should be. It is valid. That's the whole point of supporting fields inside shell comments (and the reason why shebang lines are allowed before the fields). > Also, can you use "#" comments if it isn't a dpatch file? I can > imagine that some would write it like that for other patch formats. Yes, dpatch is only quoted as an example. Feel free to improve the wording to make it clearer. > Is it worth advising that lines be < 80 characters (including > "Description: ")? Added. > > one should simply indicate the URL where the patch got grabbed > > "one should simply indicate the URL where the patch was taken from" is > less colloquial English. Replaced. > > Bug- or Bug (optional) > > I think your reasoning behind this is good, however, without a list of > vendors is there going to be a problem with consistency in the Vendors? I don't know. We can add an appendix listing most common vendor names corresponding to all major linux distributions. Not sure it's needed. > Is it Bug-Debian or Bug-debian? Should we just specify that parsers > should compare the vendors in a case-insensitive manner when they do so, > and assume that there aren't two names for a distribution? It should be case-insensitive yes. The dpkg-vendor tool already handles those names in a (mostly) case-insensitive way. > > Author (optional) > > Can be given multiple times I assume? That should be explicit as the way > to handle multiple authors. Done. > > This field can be used to record the date when the meta-information > > have been last updated. > > "was last updated" is more usual English. > > What do you see as the use for this? Is it just informational? Yes, it's for the maintainer so that he knows last time he verified that the meta-information are still up-to-date. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On Sat, Jul 4, 2009 at 3:01 AM, Jakub Wilk wrote: > * Jonathan Yu , 2009-07-03, 21:03: >> >> Maybe an idea is to have a format like: >> >> Bug: #123456 (assumes Debian BTS) >> Bug: BTS#123456 (same as above, but explicit) >> Bug: RT#123456 (to point to the CPAN Request Tracker) > > So, you are expecting that someone who reviews a patch would known how to > convert bug numbers to URLs for *all* these trackers? Actually, I was expecting that a program they were using would do that sort of thing on their behalf, or a script to do it. What if the URL changes but all the data is moved over? That's a corner case, but hey, you never know. > > -- > Jakub Wilk > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On Fri, 03 Jul 2009, Jon Dowland wrote: > One thing I would like to see patch metadata help > facilitate is patch review. At the moment the "Reviewed-by" > header proposed would allow a tool to ensure at least two > sets of eyeballs had seen a patch; however, patches can go > stale. I think some chronological information is needed > alongside the review. I propose a "Last-Reviewed" header to > capture this information. Only Sean Penny acked this suggestion. What do other people think of it? > I decided on a separate header for this for two reasons > > * adding the date info to the Reviewed-by header will make >it quite a lot longer Is that a problem? In fact, if we ask people to review our patches I would rather record their comments and not only the time of their review. In that case, adding a timestamp in a multi-line comments is not a big deal. > * generally you only need to know the date of the last >review, not the date of last review per reviewer. Why? You might not trust all reviewers... > Secondly, why not use RFC 2822 for the date field used in > Last-Update (and my proposed Last-Reviewed)? It has a > better granularity including timezone support, is output by > GNU date(1) easily with the -R argument and is already in > use for email Date: headers and Debian .changes files > amongst others. We don't need that granularity and it's somewhate cumbersome to have to include the ouptput of date -R when most of the content is typed directly by the maintainer. Note that the date field is always populated by the program in all examples you give. There's no such program for patch headers... so I'd rather keep it very simple. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On Wed, 15 Jul 2009, Jonathan Yu wrote: > > So, you are expecting that someone who reviews a patch would known how to > > convert bug numbers to URLs for *all* these trackers? > Actually, I was expecting that a program they were using would do that > sort of thing on their behalf, or a script to do it. Most patches are exchanged by VCS or mail. There's no special program in the standard workflow... we should cater to real use case and for this I tend to agree that using plain URLs is the best compromise. > What if the URL changes but all the data is moved over? That's a > corner case, but hey, you never know. You update the links exactly like you would have to update all the parsers that hardcode the bug number -> URL mapping. Anyway, trying to optimize a spec for corner cases like this one is a bad idea in general. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On 15/07/09 at 23:56 +0200, Raphael Hertzog wrote: > On Fri, 03 Jul 2009, Jon Dowland wrote: > > One thing I would like to see patch metadata help > > facilitate is patch review. At the moment the "Reviewed-by" > > header proposed would allow a tool to ensure at least two > > sets of eyeballs had seen a patch; however, patches can go > > stale. I think some chronological information is needed > > alongside the review. I propose a "Last-Reviewed" header to > > capture this information. > > Only Sean Penny acked this suggestion. What do other people think of it? I think that this information should be stored outside of the patch (in the history of a VCS, for example). -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537193: ITP: gtk2-engines-aurora -- Aurora gtk+-2.0 theme engine
Package: wnpp Severity: wishlist Owner: Chow Loong Jin * Package name: gtk2-engines-aurora Version : 1.5.1 Upstream Author : Eric Matthews * URL : http://www.gnome-look.org/content/show.php?content=56438 * License : GPL-2+ Programming Lang: C Description : Aurora gtk+-2.0 theme engine "Aurora" refers to the nautral light displays in the sky in polar regions. This package contains the Aurora theme engine for the GTK+ toolkit, version 2.0. .. GTK+ is a multi-platform tookit for creating graphical user interfaces. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#537110: ITP: libdap -- A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and Server-side support classes and a prototype implementation of the AIS
Youhei SASAKI wrote: > Package: wnpp > Owner: Youhei SASAKI > Severity: wishlist > > * Package name: libdap > Version : 3.8.2 > Upstream Author : The University of Rhode Island and The Massachusetts > Institute of Technology > * URL or Web page : http://opendap.org/download/libdap++.html > * License : GNU Lesser GPL 2.1 > Description : A C++ SDK contains an implementation of DAP 2.0 and 3.1, > Client- and Server-side support classes and a prototype implementation of the > AIS > Programing Lang : C, C++, Fortran > > A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and > Server-side support classes and a prototype implementation of the AIS. > > Upstream published new version 3.9.3, but can't build libnc-dap[1] > using libdap ver. 3.9.3. So I ITP libdap ver.3.8.2 Could you include a brief description of DAP and AIS? Reading this description made absolutely no sense to me. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#537110: ITP: libdap -- A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and Server-side support classes and a prototype implementation of the AIS
Hi, Faidon > Could you include a brief description of DAP and AIS? > Reading this description made absolutely no sense to me. DAP is Data Access Protocol. AIS is Ancillary Information Services provides some syntax and semantics. - syntax: the computer representation of a data object, data types and structures at the computer level; e.g., This data is a floating point array of 20 by 40 elements. - semantics: The information about the contents of an object; e.g., This data is sea surface temperature in degrees Celsius for a certain region of the Earth. This library provides C++ SDK for OpeNDAP(Opensource Network Data Access Protocol). OpeNDAP is a framework that simplifies all aspects of scientific data networking. OPeNDAP provides software which makes local data accessible to remote locations regardless of local storage format. OPeNDAP also provides tools for transforming existing applications into OPeNDAP clients (i.e., enabling them to remotely access OPeNDAP served data). Timeline: Thu, 16 Jul 2009 02:23:58 +0300: [Faidon Liambotis ] wrote: > Youhei SASAKI wrote: >> Package: wnpp >> Owner: Youhei SASAKI >> Severity: wishlist >> >> * Package name: libdap >> Version : 3.8.2 >> Upstream Author : The University of Rhode Island and The Massachusetts >> Institute of Technology >> * URL or Web page : http://opendap.org/download/libdap++.html >> * License : GNU Lesser GPL 2.1 >> Description : A C++ SDK contains an implementation of DAP 2.0 and 3.1, >> Client- and Server-side support classes and a prototype implementation of >> the AIS >> Programing Lang : C, C++, Fortran >> >> A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and >> Server-side support classes and a prototype implementation of the AIS. >> >> Upstream published new version 3.9.3, but can't build libnc-dap[1] >> using libdap ver. 3.9.3. So I ITP libdap ver.3.8.2 > Could you include a brief description of DAP and AIS? > Reading this description made absolutely no sense to me. > > Thanks, > Faidon Regards, --- Youhei SASAKI web: http://www.gfd-dennou.org/arch/uwabami Key fingerprint: 8BF1 ABFE 00D2 526D 6822 2AC6 13E0 381D AEE9 95F4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537199: ITP: yajl -- Yet Another JSON Library
Package: wnpp Severity: wishlist Owner: John Stamp * Package name: yajl Version : 1.0.5 Upstream Author : Lloyd Hilaiel * URL : http://lloyd.github.com/yajl/ * License : BSD Programming Lang: C Description : Yet Another JSON Library A small, fast library for parsing JavaScript Object Notation (JSON) data streams. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537200: ITP: lastfm-desktop -- The official Last.fm desktop application suite
Package: wnpp Severity: wishlist Owner: John Stamp * Package name: lastfm-desktop Version : 0+git20090709 Upstream Author : Jono Cole Doug Mansell Max Howell * URL : http://github.com/jonocole/lastfm-desktop/ * License : GPL3+ Programming Lang: C++ Description : The official Last.fm desktop application suite Last.fm's collection of applications for streaming and scrobbling music. I'm planning to package this once it gets to a releasable state, which will hopefully be soon. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537204: ITP: embassy-domsearch -- Extra EMBOSS commands to search for protein domains
Package: wnpp
Severity: wishlist
Owner: Charles Plessy
Dear all,
15th of July is the traditional EMBOSS release (EMBOSS is a set of command line
tools for molecular biologists). Two satellite packages are already present in
Debian and here is the ITP for a third. Package structure is trivial and upload
will follow shortly. It will not add to my long list of work-in-progress ITPs.
Package name: embassy-domsearch
Version : 0.1.0 (+20980715)
Upstream Author : Jon Ison (ji...@ebi.ac.uk) and collaborators.
URL :
http://emboss.sourceforge.net/apps/cvs/embassy/index.html#DOMSEARCH
License : GPL-2+
Programming Lang: C
Description : Extra EMBOSS commands to search for protein domains
debian/copyright
Machine-readable license summary, see ‘http://dep.debian.net/deps/dep5/’.
Name: DOMAINATRIX
Contact : Jon Ison (ji...@ebi.ac.uk)
Source : ftp://emboss.open-bio.org/pub/EMBOSS/DOMSEARCH-0.1.0.tar.gz
Copyright: Jon Ison (ji...@ebi.ac.uk), Matt Blades, Ranjeeva Ranasinghe.
License: GPL-2+
This package 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; either version 2 of the License, or
(at your option) any later version.
This package 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 package; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
On Debian systems, the complete text of the GNU General Public License version
2 can be
found in ‘/usr/share/common-licenses/GPL-2’.
debian/control
--
Source: embassy-domsearch
Section: science
Priority: optional
Build-Depends: cdbs, debhelper (>= 7), libajax6-dev, libnucleus6-dev,
emboss-lib, libx11-dev, libgd2-xpm-dev
Maintainer: Debian-Med Packaging Team
DM-Upload-Allowed: yes
Uploaders: Charles Plessy
Vcs-Browser:
http://svn.debian.org/wsvn/debian-med/trunk/packages/embassy-domsearch/trunk/?rev=0&sc=0
Vcs-Svn:
svn://svn.debian.org/svn/debian-med/trunk/packages/embassy-domsearch/trunk/
Standards-Version: 3.8.2
Homepage: http://emboss.sourceforge.net/apps/cvs/embassy/index.html#DOMSEARCH
Package: embassy-domsearch
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Recommends: emboss
Suggests: embassy
Description: Extra EMBOSS commands to search for protein domains
The DOMSEARCH programs were developed by Jon Ison and colleagues at MRC HGMP
for their protein domain research. They are included as an EMBASSY package as
a work in progress.
.
Applications in this DOMSEARCH release are seqfraggle (removes fragment
sequences from DHF files), seqnr (removes redundancy from DHF files), seqsearch
(generates PSI-BLAST hits (DHF file) from a DAF file), seqsort (Remove
ambiguous classified sequences from DHF files) and seqwords (Generates DHF
files from keyword search of UniProt).
I will upload the source package to the debian-med Subversion repository after
I escape from a strange svn bug that crashes my machine when doing ‘svn mv’.
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
keysigning in Cáceres : list and keyring files were released
On Mon, Jul 13, 2009 at 08:47:13PM +1000, Anibal Monsalve Salazar wrote: >The kesignings in Cáceres during DebConf9 will be done as >suggested by Don Armstrong in his mail message available at: > > http://lists.debconf.org/lurker/message/20090623.174353.1b5c91ec.en.html > >There is an extension to the deadline. The new deadline is 23:59 UTC on >Wednesday 15th of July, 2009. Both list and keyring files were uploaded to http://people.debian.org/~anibal/ksp-dc9/ signature.asc Description: Digital signature
Bug#537206: ITP: ctcs -- hardware testing/burnin suite
Package: wnpp Severity: wishlist Owner: Matthew Palmer * Package name: ctcs Version : 1.3.1pre1 Upstream Author : Jason T. Collins * URL : http://sourceforge.net/projects/va-ctcs/ * License : GPL Programming Lang: C Description : hardware testing/burnin suite The Cerberus Test Control System is is a test suite for use by developers and others to test hardware. It includes a modular test system that allows you to build and integrate your own tests. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debconf-discuss] keysi gning in Cáceres: list and keyring files were released
also sprach Aníbal Monsalve Salazar [2009.07.16.0546 +0200]: > Both list and keyring files were uploaded to > http://people.debian.org/~anibal/ksp-dc9/ To prevent wasting copious amounts of paper, please consider loading the list onto your laptop, bring something to affix your ID to the outer case so you don't have to hold it, and see if you can take notes on it like that while standing up. -- .''`. martin f. krafft : :' : DebConf orga team; press officer `. `'` `- DebConf9: 24-30 Jul 2009, Extremadura, ES: http://debconf9.debconf.org a friend is someone with whom you can dare to be yourself digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: remastering ISOs to append boot options
2009/7/15 Samuel Thibault > MaTa, le Wed 15 Jul 2009 22:40:28 +0200, a écrit : > > 2009/7/15 Samuel Thibault > > > > I have installed Debian in SunFire V120 (Sparc maquine with RJ-45 > connector > > > > "serial console") through hyperterminal with the standard Debian > installation > > > > CD > > > > > > > > A possible alternate way can be a preseed installation (a > preconfigured file) > > > > > > Ok, but how do you proceed? Don't you need to either pass options to > > > the kernel or prepare a particular image with the preseed config > file? > > > > The preseed file it's "only" a text file with options that you can choose > in > > installer predefined in a file. To install a system using it needs to > > "remaster" de CD with a little modification in boot options and include > the > > preseed file. It's no very complicated > > That's precisely my point. You are saying it's not very complicated, > but it's not very trivial either (no need to give me info, it's already > in the wiki etc), while I think it could be trivialized with a few > helper tools, I'm just wondering where such tools could be maintained > and advertized. > > Samuel > I'm sorry if i don't understand what you mean, and sorry for my english. I know some existing tools that can help you. Some are: - live-magic - debian-cd - simple-cdd - live-helper > > > -- > To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > >
