Your message dated Mon, 24 Jul 2017 11:33:17 +0200
with message-id <4df8239a-98c5-9d83-e00b-a52ecc2a0...@debian.org>
and subject line Re: Bug#869374: RFS:
golang-github-gin-contrib-sse/0.0~git20170109.0.22d885f-1 [ITP]
has caused the Debian Bug report #869374,
regarding RFS: golang-gith
On 07/22/2017 08:52 PM, Shengjing Zhu wrote:
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
>
> Dear mentors,
>
> I am looking for a sponsor for my package "golang-github-gin-contrib-sse"
Looks OK, h
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Dear mentors,
I am looking for a sponsor for my package "golang-github-gin-contrib-sse"
* Package name: golang-github-gin-contrib-sse
Version : 0.0~git20170109.0
Hi,
> I am looking for a sponsor for my package "caffe-contrib"
its in
G.
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "caffe-contrib"
* Package name : caffe-contrib
Version : 1.0.0~rc3-2
Upstream Author : BVLC
* URL : caffe.berkeleyvision.org
* License
Your message dated Tue, 5 Jul 2016 13:24:31 + (UTC)
with message-id <1304227701.3668261.1467725071992.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#829653: RFS: caffe-contrib/1.0.0~rc3-1 -- cuda version
of caffe [ITP]
has caused the Debian Bug report #829653,
regarding RFS:
http://debomatic-amd64.debian.net/distribution#experimental/caffe-contrib/1.0.0~rc3-1/buildlog
The lastest mentors package is fixed.
Please sponsor, thanks :-)
On 5 July 2016 at 03:30, Debian Bug Tracking System
wrote:
> Thank you for the additional information you have supplied regard
Well it seems that the first time mentors upload is going to FTBFS[1].
Hold on and I'll make an fixed upload.
the fix is to add flag -D_FORCE_INLINES to nvcc.
[1] dom-amd64: CUDA memcpy problem
--
Best,
Lumin
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: costamagnagianfra...@yahoo.it
, ghisv...@gmail.com
Dear mentors,
This cuda version is basically synced with the CPU version in
packaging.
I am looking for a sponsor for my package "caffe-contrib"
* Pa
;
>
>
>
>
>
> On 12 January 2015 at 18:32, Jonathan Nieder wrote:
>>
>> reassign 773245 src:git 1:2.1.3-1
>> quit
>>
>> Vincent Cheng wrote:
>>
>> > Yes, source packages in main can generate binary packages in contrib;
>> >
athan Nieder wrote:
> reassign 773245 src:git 1:2.1.3-1
> quit
>
> Vincent Cheng wrote:
>
> > Yes, source packages in main can generate binary packages in contrib;
> > Policy does not prevent this from happening, and there are existing
> > source packages in main,
reassign 773245 src:git 1:2.1.3-1
quit
Vincent Cheng wrote:
> Yes, source packages in main can generate binary packages in contrib;
> Policy does not prevent this from happening, and there are existing
> source packages in main, in the archive, which generate binary
> packages in
way to do this.
>
> The source code lives in the upstream git repository, but isn't packaged
> with the regular 'git' package because of the proprietary nature of
> Perforce. I thought I'd try to create a separate package that could go into
> contrib instead.
>
#x27;t packaged
with the regular 'git' package because of the proprietary nature of
Perforce. I thought I'd try to create a separate package that could go
into contrib instead.
I've created a bug report with a patch for the git package to implement
this (773245) which Jo
Your message dated Mon, 14 Apr 2014 11:22:34 +0200
with message-id <534ba8da.8020...@debian.org>
and subject line Fwd: wcslib-contrib_4.22-1_amd64.changes is NEW
has caused the Debian Bug report #743691,
regarding RFS: wcslib-contrib/4.22-1 [ITP] -- Draw and label curvilinear
coordinate
Control: owner -1 !
Control: tag -1 + pending
I'll take care of this one
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534ab6df.8010...@free.fr
X-Debbugs-Cc: debian-as...@lists.debian.org, debian-scie...@lists.debian.org
> I am looking for a sponsor for my package "wcslib-contrib"
>
> * Package name : wcslib-contrib
> Version : 4.20-1
Since upstream released the new version 4.22, I updated the packa
Le 05/04/2014 12:43, Ole Streicher a écrit :
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-Cc: debian-as...@lists.debian.org, debian-scie...@lists.debian.org
>
> Dear mentors,
>
> I am looking for a sponsor for my package "wcslib-contrib"
High O
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-as...@lists.debian.org, debian-scie...@lists.debian.org
Dear mentors,
I am looking for a sponsor for my package "wcslib-contrib"
* Package name : wcslib-contrib
Version : 4.20-1
Upstream Aut
>>> Should I produce 2 different source packages
>>> for main and contrib from the same upstream project?
>>
>> Short answer:
>> Yes, this is the best solution in such case.
>> (If there is no any possibility to avoid non-free dependencies.)
>
On Mon, Apr 22, 2013 at 02:28:14PM +0300, Boris Pek wrote:
> Hi Nicolas,
>
> > Should I produce 2 different source packages
> > for main and contrib from the same upstream project?
>
> Short answer:
> Yes, this is the best solution in such case.
> (If there is n
Hi Nicolas,
> Should I produce 2 different source packages
> for main and contrib from the same upstream project?
Short answer:
Yes, this is the best solution in such case.
(If there is no any possibility to avoid non-free dependencies.)
Some additional thoughts:
If tarball is quite smal
On Mon, Apr 22, 2013 at 12:56:25PM +0200, Nicolas Bourdaud wrote:
> My question is simple... Should I produce 2 different source packages
> for main and contrib from the same upstream project?
AFAIK yes.
--
WBR, wRAR
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debi
binary package of plugins: one is eligible for main, the other
must reside in contrib.
My question is simple... Should I produce 2 different source packages
for main and contrib from the same upstream project? Or can I use the
same source package that will produce most binary packages in main
> here?
I'd go for #3
> If I decide to move Moodle to contrib - how do I do it?
Change the Section lines in debian/control to contrib/
You probably want to keep moodle in main and the Flash files in
contrib. To do that you need to create 3 source packages. Firstly, a
normal moodle one
here? It seems to me that
splitting the package into two may be the best solution. I've read
similar discussion:
http://lists.debian.org/debian-mentors/2006/06/msg00051.html
but I'm not really any smarter.
If I decide to move Moodle to contrib - how do I do it?
Thanks for any hints,
On Tue, 2009-12-22 at 22:34 +0100, Ludovico Cavedon wrote:
> Felipe Sateler wrote:
> > On Mon, 2009-12-21 at 00:03 +0100, Ludovico Cavedon wrote:
> >> Upstream for tortoisehg (interface for mercurial) distributes in their
> >> tarball a file:
> >>contrib/_hg
Felipe Sateler wrote:
> On Mon, 2009-12-21 at 00:03 +0100, Ludovico Cavedon wrote:
>> Upstream for tortoisehg (interface for mercurial) distributes in their
>> tarball a file:
>> contrib/_hgtk
>> which enables zsh completion script for tortoisehg.
>>
>&
On Mon, 2009-12-21 at 00:03 +0100, Ludovico Cavedon wrote:
> Hi all,
> Upstream for tortoisehg (interface for mercurial) distributes in their
> tarball a file:
> contrib/_hgtk
> which enables zsh completion script for tortoisehg.
>
> I am not a zsh user and I would
Hi all,
Upstream for tortoisehg (interface for mercurial) distributes in their
tarball a file:
contrib/_hgtk
which enables zsh completion script for tortoisehg.
I am not a zsh user and I would not feel confident in installing that
script in a location so it is automatically enabled for
hem as private libraries. If something else
uses the libraries it might be a good idea to upload to experimental
only.
> B) ReSIProate libraries have no soname
See above. Please consider educating upstream about SONAMEs. In
addition, make it a Debian-specific SONAME if you change it.
> C)
ate has so many configuration options, that
compatibility is unlikely per se.
C) The contrib directory and the copyright file
reSIProcate contains a contrib directory which contains several third
party libraries. I use none of them and also don't intent to do so.
Can I keep them in the ta
Carlo Segre <[EMAIL PROTECTED]> writes:
> On Thu, 17 Apr 2008, Goswin von Brederlow wrote:
>
>>
>> Talk to aba (Andreas barth) who manages the non-free buildds.
>>
>
> Actually, I suggested to the non-free buildd admins that they allow
> selected contr
On Thu, 17 Apr 2008, Goswin von Brederlow wrote:
Talk to aba (Andreas barth) who manages the non-free buildds.
Actually, I suggested to the non-free buildd admins that they allow
selected contrib packages to be built on the non-free network but I have
not gotten a response back yet. That
Carlo Segre <[EMAIL PROTECTED]> writes:
> Hello All:
>
> I am continually running into a problem with one of my contrib
> packages (ifeffit). Unfortunately it depends on two non-free packages
> to build (pgplot5, latex2html). Some of the buildd machines build
> this pac
Hello All:
I am continually running into a problem with one of my contrib packages
(ifeffit). Unfortunately it depends on two non-free packages to build
(pgplot5, latex2html). Some of the buildd machines build this package
without problems if they have the non-free sources in sources.list
Le Mon, Oct 30, 2006 at 10:25:23AM +0100, Bas Wijnen a écrit :
> > > Charles Plessy <[EMAIL PROTECTED]> wrote:
>
> > Does it mean that the upload of packages which can not be built or used
> > using commands like dpkg, apt, or aptitude, as opposed to make, is
> > discouraged?
>
> I don't qu
On Fri, Oct 27, 2006 at 08:13:38AM +0900, Charles Plessy wrote:
> Le Thu, Oct 26, 2006 at 03:30:50PM +0200, Thibaut Paumard a ?crit :
> > Charles Plessy <[EMAIL PROTECTED]> wrote:
> > > Examples of packages which would be included in contrib are:
> > >
Le Thu, Oct 26, 2006 at 03:30:50PM +0200, Thibaut Paumard a écrit :
> Charles Plessy <[EMAIL PROTECTED]> wrote:
> > Examples of packages which would be included in contrib are:
> > * free packages which require [...] packages which
> > are not in our archiv
On Thu, 26 Oct 2006 21:48:24 +0900
Charles Plessy <[EMAIL PROTECTED]> wrote:
> Le Thu, Oct 26, 2006 at 02:25:31PM +0200, Bas Wijnen a écrit :
> from the policy:
>
> ----
> 2.2.2 The contrib category
> [...]
>
> I am therefore
but technically not Depends on), er,
> > obscure blobs of data, usually gathered by a way of sniffing data flow
> > between a proprietary application and a hardware device, and then just
> > repeated as is?
>
> Sounds like "contrib" to me. Packages in "main&qu
way of sniffing data flow
> between a proprietary application and a hardware device, and then just
> repeated as is?
Sounds like "contrib" to me. Packages in "main" should be free in that they
can be used and changed without (much) limitations. Technically that me
itialization process. A bunch of ready to
use "synch" files is available for no cost from the eciadsl upstream
(http://eciadsl.flashtux.org/download.php), but not included in eciadsl
package. Seems like all that "synch" data was sniffed from USB under
Windows and proprietary
On Thu June 8 2006 10:07, it was written:
> Users who accept that they might need non-free software to use things have
> contrib (and non-free) in their sources.list. Users who don't want it don't.
> If this script is in contrib, it is very visible for people who have contrib
&
Philipp Kern wrote:
On 5 Apr 2005, at 12:27, Benjamin Cutler wrote:
If your .changes file does not say contrib or non-free, then it will
not end up there once it hits the official archives.
How could I achieve this if I package something for contrib/non-free?
Regards,
Philipp Kern
Section: (non
On 5 Apr 2005, at 12:27, Benjamin Cutler wrote:
If your .changes file does not say contrib or non-free, then it will
not end up there once it hits the official archives.
How could I achieve this if I package something for contrib/non-free?
Regards,
Philipp Kern
PGP.sig
Description: This is a
Gerber van der Graaf wrote:
I recently uploaded some packages (Libgpiv_0.3.1, Gpivtools_0.3.1 and
Gpiv_0.2.1) to mentors.debian.net with dupload. It seemed that
everything went fine. But to me surprise they have been put in the
contrib repository, instead of main. How is the choice of repository
I recently uploaded some packages (Libgpiv_0.3.1, Gpivtools_0.3.1 and
Gpiv_0.2.1) to mentors.debian.net with dupload. It seemed that
everything went fine. But to me surprise they have been put in the
contrib repository, instead of main. How is the choice of repository
controlled, automatically or
Fri, 04 Feb 2005 19:44:48 +0100,
Daniel Leidert <[EMAIL PROTECTED]> wrote:
> Hello,
Hi,
> I have a question to one of my packages (Jmol, LGPL licensed), I
> unofficially maintain.
>
> Sources:
> http://debian.wgdd.de/debian/dists/unstable/contrib/source/science/
>
Hello,
I have a question to one of my packages (Jmol, LGPL licensed), I
unofficially maintain.
Sources:
http://debian.wgdd.de/debian/dists/unstable/contrib/source/science/
The package source comes with a few precompiled Java binaries (.jar).
Now I have the possibility to use Debian packages
On Sat, Oct 09, 2004 at 08:15:47PM +0200, Ramón Rey Vicente wrote:
> Leo "Costela" Antunes wrote:
> | PearPC does not need MacOS X or other non-free operating system to be
> | fully used, it can be used with Debian/PPC for example, so, does it need
> | to stay in contrib?
On Sat, Oct 09, 2004 at 08:15:47PM +0200, Ramón Rey Vicente wrote:
> Leo "Costela" Antunes wrote:
> | PearPC does not need MacOS X or other non-free operating system to be
> | fully used, it can be used with Debian/PPC for example, so, does it need
> | to stay in contrib?
ring security
> > scrutiny).
>
> Just upload a new, fixed version.
Note that you need to upload a new version anyway, as components (main,
contrib, non-free) are not overridden by the archive administrators.
--
Colin Watson [EMAIL PROTECTED]
ring security
> > scrutiny).
>
> Just upload a new, fixed version.
Note that you need to upload a new version anyway, as components (main,
contrib, non-free) are not overridden by the archive administrators.
--
Colin Watson [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leo "Costela" Antunes wrote:
| PearPC does not need MacOS X or other non-free operating system to be
| fully used, it can be used with Debian/PPC for example, so, does it need
| to stay in contrib?
And, whats about dosemu? dosemu not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leo "Costela" Antunes wrote:
| PearPC does not need MacOS X or other non-free operating system to be
| fully used, it can be used with Debian/PPC for example, so, does it need
| to stay in contrib?
And, whats about dosemu? dosemu not need
also sprach Leo Costela Antunes <[EMAIL PROTECTED]> [2004.10.07.1405 +0200]:
> PearPC does not need MacOS X or other non-free operating system to
> be fully used, it can be used with Debian/PPC for example, so,
> does it need to stay in contrib?
No, it can go into main if its licen
Hi all,
A couple of days ago, I uploaded PearPC for inclusion into the archive.
More specifically into the contrib/otherosfs section, but now I got one
doubt troubling me.
PearPC does not need MacOS X or other non-free operating system to be
fully used, it can be used with Debian/PPC for example
also sprach Leo Costela Antunes <[EMAIL PROTECTED]> [2004.10.07.1405 +0200]:
> PearPC does not need MacOS X or other non-free operating system to
> be fully used, it can be used with Debian/PPC for example, so,
> does it need to stay in contrib?
No, it can go into main if its licen
Hi all,
A couple of days ago, I uploaded PearPC for inclusion into the archive.
More specifically into the contrib/otherosfs section, but now I got one
doubt troubling me.
PearPC does not need MacOS X or other non-free operating system to be
fully used, it can be used with Debian/PPC for example
Matt Zimmerman:
> If the program cannot be compiled using free tools, then it is not very
> free.
Well, that's a matter of definition.
I'll have a look at using another cross-assembler. Fortunately, there
seems to be a GPL'ed 6502 cross-assembler, so I'll have a look into
using that one instead.
>
> Refer to the Debian Policy Manual, section 2.1.2.
>
>
> In addition, the packages in main
>
> * must not require a package outside of main for *compilation* or execution
> (thus, the package must not declare a "Depends", "Recommends", or
> "Build-Depends" relationship on a non-main package)
lso GPL, but the program used to compile those sources is not DFSG
> free. The remote computer software is available in both source and
> binary forms in the packages.
>
> So, my question is, if I did package this, can I place it in main, or
> must it go into contrib? Or could I packa
remote computer software is available in both source and
binary forms in the packages.
So, my question is, if I did package this, can I place it in main, or
must it go into contrib? Or could I package the main program in main,
and the remote computer routines in contrib? Or could I put those in
main as
Matt Zimmerman:
> If the program cannot be compiled using free tools, then it is not very
> free.
Well, that's a matter of definition.
I'll have a look at using another cross-assembler. Fortunately, there
seems to be a GPL'ed 6502 cross-assembler, so I'll have a look into
using that one instead
>
> Refer to the Debian Policy Manual, section 2.1.2.
>
>
> In addition, the packages in main
>
> * must not require a package outside of main for *compilation* or execution
> (thus, the package must not declare a "Depends", "Recommends", or
> "Build-Depends" relationship on a non-main package
lso GPL, but the program used to compile those sources is not DFSG
> free. The remote computer software is available in both source and
> binary forms in the packages.
>
> So, my question is, if I did package this, can I place it in main, or
> must it go into contrib? Or could I packa
remote computer software is available in both source and
binary forms in the packages.
So, my question is, if I did package this, can I place it in main, or
must it go into contrib? Or could I package the main program in main,
and the remote computer routines in contrib? Or could I put those in
main as
Steve Langasek wrote:
> If you build snd-gtk and snd-dmotif from the same source package, then
> all of the packages must go into contrib: a source package in main can
> also not build-depend on packages outside of main. The practical
> reason for this is that Debian's aut
* Stefan Schwandter ([EMAIL PROTECTED]) wrote :
> Hello,
>
>
> policy says that a package in main must not declare a releationship on a
> package not in main.
>
> I would like to split the snd package into a snd (arch-independent
> files), snd-gtk and snd-dmotif, where
Hello,
policy says that a package in main must not declare a releationship on a
package not in main.
I would like to split the snd package into a snd (arch-independent
files), snd-gtk and snd-dmotif, where snd-dmotif is in contrib. Is it
legal to declare a Depends: on snd-gtk|snd-dmotif in the
On Sat, Apr 13, 2002 at 12:36:12AM +0200, Martin Butterweck wrote:
> I made a package which has to go into contrib. Sadly, i have no idea of
> how to get it there. An appendix of the policy says I should state
> "contrib" as the distribution in the control file, but annot
On Sat, Apr 13, 2002 at 12:36:12AM +0200, Martin Butterweck wrote:
> I made a package which has to go into contrib. Sadly, i have no idea of
> how to get it there. An appendix of the policy says I should state
> "contrib" as the distribution in the control file, but annot
Hi,
I made a package which has to go into contrib.
Sadly, i have no idea of how to get it there.
An appendix of the policy says I should state "contrib" as the distribution in
the control file, but annotation 13 (chapter control files) tells me there is
no contrib distributio
Hi,
I made a package which has to go into contrib.
Sadly, i have no idea of how to get it there.
An appendix of the policy says I should state "contrib" as the distribution in the
control file, but annotation 13 (chapter control files) tells me there is no contrib
distributio
t to be
> sure...
You are doing the right thing - if you built the contrib packages from
the same source package as the packages in main then either the source
package in main wouldn't build without things from outside main or there
would be binaries in main without a corresponding source pack
Hello,
I'm preparing a new snd package. Because snd still works better with
motif I made three versions of my package: snd (with gtk), snd-dmotif
and snd-smotif. I have to use OpenMotif so snd-{s,d}motif have to go
into contrib.
Am I doing the right thing when I build the free package fro
On Sun, Nov 25, 2001 at 08:49:30AM -0500, Adam C Powell IV wrote:
>
> Right, but it seems policy does not allow a contrib source package to
> put binaries in both contrib and main. It's a policy issue, not a
> technical one: if a package is "tainted" with a non-fre
On Sun, Nov 25, 2001 at 08:49:30AM -0500, Adam C Powell IV wrote:
>
> Right, but it seems policy does not allow a contrib source package to
> put binaries in both contrib and main. It's a policy issue, not a
> technical one: if a package is "tainted" with a non-fre
). So the source
would become contrib, because some of the binaries would need contrib
software to build on one platform. But then, can I put the
gcc/g77-built binaries in main? Hmm, doubtful.
Of course you can.
gcc/g77 does not require any non-free software. They require a C
compiler, but any
2).
>>>
>>Right, thanks for pointing this out (I need to RTFP :-). So the source
>>would become contrib, because some of the binaries would need contrib
>>software to build on one platform. But then, can I put the
>>gcc/g77-built binaries in main? Hmm, doubtf
n main?
> >>
> >No, that would violate policy (2.1.2).
> >
> Right, thanks for pointing this out (I need to RTFP :-). So the source
> would become contrib, because some of the binaries would need contrib
> software to build on one platform. But then, can I put the
> gcc/
n main?
> >>
> >No, that would violate policy (2.1.2).
> >
> Right, thanks for pointing this out (I need to RTFP :-). So the source
> would become contrib, because some of the binaries would need contrib
> software to build on one platform. But then, can I put the
> gcc/
ointing this out (I need to RTFP :-). So the source
> would become contrib, because some of the binaries would need contrib
> software to build on one platform. But then, can I put the
> gcc/g77-built binaries in main? Hmm, doubtful.
Of course you can.
gcc/g77 does not require any non
James Troup wrote:
Adam C Powell IV <[EMAIL PROTECTED]> writes:
Can I "Build-Depends: ccc [alpha], cfal [alpha]" and still have the
source package in main?
No, that would violate policy (2.1.2).
Right, thanks for pointing this out (I need to RTFP :-). So the source
woul
ointing this out (I need to RTFP :-). So the source
> would become contrib, because some of the binaries would need contrib
> software to build on one platform. But then, can I put the
> gcc/g77-built binaries in main? Hmm, doubtful.
Of course you can.
gcc/g77 does not require any non
Adam C Powell IV <[EMAIL PROTECTED]> writes:
> Can I "Build-Depends: ccc [alpha], cfal [alpha]" and still have the
> source package in main?
No, that would violate policy (2.1.2).
--
James
need to RTFP :-). So the source
would become contrib, because some of the binaries would need contrib
software to build on one platform. But then, can I put the
gcc/g77-built binaries in main? Hmm, doubtful.
I guess the proper way to do this would be to assemble a separate
contrib "p
Greetings,
Having got the non-free cfal (Compaq Fortran for Linux Alpha, yes, the
acronym is backwards :-) compiler to work using my contrib Debian
packaging (realplayer-style RPM unpacker), I built PETSc using it, and
WOW, is it FAST! On a 600 MHz ev5, it is more than 2.5 times as fast
per
Adam C Powell IV <[EMAIL PROTECTED]> writes:
> Can I "Build-Depends: ccc [alpha], cfal [alpha]" and still have the
> source package in main?
No, that would violate policy (2.1.2).
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
Greetings,
Having got the non-free cfal (Compaq Fortran for Linux Alpha, yes, the
acronym is backwards :-) compiler to work using my contrib Debian
packaging (realplayer-style RPM unpacker), I built PETSc using it, and
WOW, is it FAST! On a 600 MHz ev5, it is more than 2.5 times as fast
per
On Wed, Feb 07, 2001 at 05:43:51PM +, James Troup wrote:
> Julian Gilbey <[EMAIL PROTECTED]> writes:
>
> > > I have packaged vpopmail and put it into main section of Debian. Then
> > > somebody reported that it depends on qmail and hence it should be moved
>
On Wed, Feb 07, 2001 at 05:43:51PM +, James Troup wrote:
> Julian Gilbey <[EMAIL PROTECTED]> writes:
>
> > > I have packaged vpopmail and put it into main section of Debian. Then
> > > somebody reported that it depends on qmail and hence it should be moved
&
Julian Gilbey <[EMAIL PROTECTED]> writes:
> > I have packaged vpopmail and put it into main section of Debian. Then
> > somebody reported that it depends on qmail and hence it should be moved
> > From mail to contrib/mail. I tried to upload fixed packages, but Debia
On Wed, Feb 07, 2001 at 04:54:10PM +0100, Ondrej Sury wrote:
>
> Hello,
>
> I have packaged vpopmail and put it into main section of Debian. Then
> somebody reported that it depends on qmail and hence it should be moved
> From mail to contrib/mail. I tried to upload fixed pa
Hello,
I have packaged vpopmail and put it into main section of Debian. Then
somebody reported that it depends on qmail and hence it should be moved
From mail to contrib/mail. I tried to upload fixed packages, but Debian
installer rejected those new packages. Now I don't know how to
Julian Gilbey <[EMAIL PROTECTED]> writes:
> > I have packaged vpopmail and put it into main section of Debian. Then
> > somebody reported that it depends on qmail and hence it should be moved
> > From mail to contrib/mail. I tried to upload fixed packages, but Debia
On Wed, Feb 07, 2001 at 04:54:10PM +0100, Ondrej Sury wrote:
>
> Hello,
>
> I have packaged vpopmail and put it into main section of Debian. Then
> somebody reported that it depends on qmail and hence it should be moved
> From mail to contrib/mail. I tried to upload fixed pa
Hello,
I have packaged vpopmail and put it into main section of Debian. Then
somebody reported that it depends on qmail and hence it should be moved
From mail to contrib/mail. I tried to upload fixed packages, but Debian
installer rejected those new packages. Now I don't know how to
On Mon, Jul 10, 2000 at 11:20:50AM -0700, Adam Klein wrote:
> So, I tried to upload to main, but it didn't work. What's
> the proper way to do this?
It depends on the value of "didn't work". Like most things.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
1 - 100 of 124 matches
Mail list logo
