Re: Bug#592721: unblock: embassy-* and emboss.

2010-09-05 Thread Julien Cristau
On Sun, Sep  5, 2010 at 09:22:13 +0900, Charles Plessy wrote:

> Le Sat, Sep 04, 2010 at 06:50:03PM +0200, Julien Cristau a écrit :
> > On Sun, Sep  5, 2010 at 01:12:20 +0900, Charles Plessy wrote:
> > 
> > > Just remove the embassy packages. This is a perfectly acceptable solution 
> > > that
> > > I accepted in advance in the first email of this thread.
> > > 
> > That's not going to fix emboss.  Are you going to fix that one, or
> > should it get removed as well?
> 
> I can prepare an update to add Breaks in emboss-lib, libajax6 and libnucleus6
> in Squeeze, to open the way to a safe removal of the embassy pakcages.  But
> EMBOSS 6.1 is an obsolete upstream version. The package in Sid is by all means
> superior, and does not need a Breaks declaration unless we would like to 
> support
> the use of a mixture of Lenny and Squeeze.
> 
We do support partial upgrades.  If a package combination is allowed by
their declared relationships, and doesn't work, that's a serious bug in
those packages.  Now I don't know the details of emboss and empathy, so
I don't know what breaks when mixing lenny and squeeze, but hopefully
you do, so you can explain.

[...]
> If you were thinking about other release-critical issues, please open a
> bug so that our discussion can be more concrete.
> 
I've opened one, but I'd still like answers to the questions I asked
in this thread.

Cheers,
Julien


signature.asc
Description: Digital signature


Re: Bug#592721: unblock: embassy-* and emboss.

2010-09-05 Thread Charles Plessy
Le Sun, Sep 05, 2010 at 01:20:33PM +0200, Julien Cristau a écrit :
> > 
> We do support partial upgrades.

The EMBOSS and EMBASSY packages are released together each year on the 15th of
July (and sometimes the 15th of January). In my experience, upstream does not
support the use of EMBASSY packages that were not released together with the
EMBOSS packages.

I do not think that our EMBOSS users expect us to provide a compatibility
that upstream does not.

I can add ‘Breaks: embassy-domalign << 0.1.0+20100721-1~, embassy-domainatrix
<< 0.1.0+20100721-1~, embassy-domsearch << 0.1.0++20100721-1~, embassy-phylip
<< 3.69+20100721-1~, emboss << 6.3.1-5~’ to the libajax6, libnucleus6 and
emboss-lib packages, and keep the versions up to date when upstream will
release a new version. This will avoid users making mixtures that are not
supported.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100905122345.gb5...@merveille.plessy.net



charset d'un mail

2010-09-05 Thread pmd
bonjour,
je me suis fait un petit programme d'automatisme qui envoie des mails d'infos 
par msmtp.
Ca marche très bien mais j'ai un problème de charset. 
Je ne trouve pas dans mes nombreuses recherche google comment indiquer à msmtp 
quel charset choisir.
Je ne peux donc pas mettre de caractère accentué.
Merci de vos avis.
Cordialement
pmd

-- 
pmd 



-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100905205842.9bf5a92c.debian...@orange.fr



Re: Connecting those interested in getting GT.M into the Debian repositories

2010-09-05 Thread Alan O'Neill

Hi Andreas,

Thanks for the offer of the help!  It makes me feel much better.  As I 
mentioned, packaging is fairly new to me, but I have a great deal of 
knowledge of GT.M including developing in MUMPS and also configuring 
GT.M (e.g., setting up global directories, configuring dual-logical 
sites, etc.).  I also have a fair amount of experience with VistA, and I 
have setup VistA environments in GT.M before.  So I hope to offer a lot 
on these fronts.


So now to my next question.  I've read about Subversion before, and I 
like the idea a lot, but I don't have experience using it.  To help 
myself out, I downloaded the "Version Control for Subversion" book from 
http://svnbook.red-bean.com/en/1.5/svn-book.pdf and started reading.  
It's quite the book!  I think I'm beginning to see the big picture of 
how it works, but before I issue any write commands to 
svn://svn.debian.org/svn/debian-med/trunk/packages/..., I want to run 
some things by you first.


The package I'm ready to submit installs the 32-bit version of GT.M 
5.4.000A.  Additionally, I'll be able to build a package for the 64-bit 
version.  I could also build packages for earlier versions, if desired, 
and as new versions come out, I could put those together as well.  I've 
walked a bit of the directory structure under 
http://svn.debian.org/viewsvn/debian-med/trunk/packages/, and it appears 
that the next level is a package name followed immediately by "trunk" 
and the "debian" directory (e.g., 
.../trunk/packages/fastdnaml/trunk/debian).  So should I store things at


.../trunk/packages/fis-gtm-54000A-32/trunk/

or is it preferable to store it something like

.../trunk/packages/fis-gtm/54000A/32/trunk/

or perhaps something else?

My second question is about how to issue the actual commands to submit 
the package.  For the purpose of this e-mail, I'll guess that I'll be 
storing things under .../trunk/packages/fis-gtm/54000a/32/trunk.  On my 
local server, I issued the following command to create a test area.


svnadmin create /home/alan/debian-med

Then I issued this next command to import my files

svn import  
file:///home/alan/debian-med/trunk/packages/fis-gtm/54000a/32/trunk


At this point it seems that svn knows about my files.  And I can even 
checkout the files with


svn checkout 
file:///home/alan/debian-med/trunk/packages/fis-gtm/54000a/32/trunk


But all this stuff seems to work because the files are already on my 
server.  Of course, my goal is to put the files onto the server where 
the actual debian-med lives.  So I seem to be approaching things from 
the wrong end.  Can you give me a hint as to how the svn command(s) 
should be structured to copy the files from my server to debian-med?


Thanks again!

Alan

On 09/04/2010 02:39 PM, Andreas Tille wrote:

On Sat, Sep 04, 2010 at 01:16:06PM -0400, Alan O'Neill wrote:
   

I'm certainly still interested in helping to get GT.M into the stream,
but I'm feeling a little overwhelmed with what seem to be the
requirements.
 

We are here to help you overcoming the feeling of beeing overwhelmed.

   

I like, though, that the documentation recommends working
with a mentor when you're new to packaging (which I certainly am :).  I
gather from what I've read in your postings, that you're adept at these
things.  My hope is that you or someone else in this group might be able
to provide me with some assistance.
 

This is in fact what we really want to do here.  VistA is a real killer
application and it would drastically enhance Debian Med so we are really
interested.  IMHO sharing expertise is the most straightforeward way to
go here:  We are lacking expertise in GT.M, but we are knowing a lot
about packaging - so we try to do our best here.

   

To let you know where things are, I've tried several times to create an
account at alioth.debian.org, but when I try to confirm the account, it
returns the error message "Error Could Not Get User".  Have you
encountered this problem before?  (If it's helpful, the account name I
selected was "alanoneill".)
 

This seems to have worked:

https://alioth.debian.org/users/alanoneill-guest/

and I just have added you to the Debian Med team which grants you commit
permission to SVN and Git.

   

Also, I've made the following changes to the package:

- I used the information in the Debian Med Policy to update some of the
fields in the DEBIAN/control file.
- Where appropriate, I changed the owner and/or group from "bin" to
"fis-gtm".
 

Great.

   

- I put the permissions on the directories back to r-xr-xr-x (awaiting
Bhaskar's response to your question).

Looking forward to hearing from you.
 

I would recommend to commit your current state of work to

svn://svn.debian.org/svn/debian-med/trunk/packages/gtm/trunk

(or any better name than gtm according to your own decision - just follow
the example of all the other packages there).

Do not hesitate to keep on asking if something remains unclear.

Kind regards

  Andreas