-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello dear engineers.
I have prepared some new packages for Debian, would you be interested?
These packages have been verified and have the confirmed tags.
1. vifm
RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093235
https
Hello,
On Sun 01 May 2022 at 07:52am +08, Paul Wise wrote:
> On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote:
>
>> This would really slow things down;
>> I don't think we could work that way.
>
> Using separate bug reports or not would of course be up to the person
> filing them, but I expe
On Sat, 30 Apr 2022, Paul Wise wrote:
> I suppose debbugs could allow the package state to go out of sync with
> NEW and instead retain the addresses for a certain period of time
> after packages are removed from NEW and while there are open bugs on
> the packages that were removed from NEW.
This
What does it help to have it sitting there instead of rejected?
I gave it more thought, and I don't think it has to be sitting in
the NEW queue at all. As far as I understand it, the main advantage
to gain is additional context; a bug report provides documentation
and a place to discuss solutions
view?
>If it will clutter the NEW queue with half-processed packages, I'd
>say it is a bad tradeoff, because it adds mental load to the FTP
>team. At a minimum, there needs to be appropriate tooling which
>allows to distinguish easily between new packages requiring FTP team
>revi
a minimum, there needs to be appropriate tooling which
allows to distinguish easily between new packages requiring FTP team
review and packages waiting for fixes to be applied.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling
Paul Wise left as an exercise for the reader:
> I think the same problem and suggestions also apply with the current
> system of prods and rejects, so please do add or propose adding it in
> the appropriate documentation and templates. I will of course seek to
> preserve these statements if I end u
On Sat, 2022-04-30 at 22:47 -0400, nick black wrote:
> i understand. i suppose that what i'm saying is it will probably
> be worthwhile to convey in Mentors etc. documentation that
> "resolving the bugs filed thus far [regarding the package in
> NEW] does not imply that no further bugs will be fil
Paul Wise left as an exercise for the reader:
> > if resolving the resulting bug report is the bar needing clearing to
> > enter the archive, that does seem to require FTPmasters to create a
> > complete statement of REJECT-worthy problems in each uploaded
> > package, which seems like more work th
On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote:
> This would really slow things down;
> I don't think we could work that way.
Using separate bug reports or not would of course be up to the person
filing them, but I expect the process could be automated well enough
that it wouldn't be much
Hello,
On Sat 30 Apr 2022 at 07:44AM +08, Paul Wise wrote:
> It also means the ftpmasters can file separate bugs for each problem,
> rather than combining them all into one mail.
This would really slow things down; I don't think we could work that
way.
--
Sean Whitton
signature.asc
Descripti
On Sat, 2022-04-30 at 03:09 -0400, nick black wrote:
> currently, as far as i understand things, a REJECT can be issued
> for the first REJECT-worthy problem.
The same would occur under the proposal, except that there would
presumably be separate bug reports for separate issues.
> if resolving t
Paul Wise left as an exercise for the reader:
> Packages with incomplete or incorrect debian/copyright information
> currently would recieve a REJECT rather than acceptance. The proposal
> would not change that, just turn that REJECT into a bug report, which
> you could fix in a second upload to NE
On Sat, 2022-04-30 at 00:13 +, Scott Kitterman wrote:
> I'm still not understanding how any of that needs to have a package
> we've decided not to accept sitting in New?
My thinking is that debbugs would require a package (imported from
new.822) to exist for maintainer addresses. If you file
On April 29, 2022 11:44:54 PM UTC, Paul Wise wrote:
>On Fri, 2022-04-29 at 23:32 +, Scott Kitterman wrote:
>
>> I don't understand why this is any better than just rejecting the
>> package? Once it's been determined that the upload won't be
>> accepted, I don't see a benefit to having it r
On Fri, 2022-04-29 at 23:32 +, Scott Kitterman wrote:
> I don't understand why this is any better than just rejecting the
> package? Once it's been determined that the upload won't be
> accepted, I don't see a benefit to having it remain in New.
The initial upload might not get an ACCEPT, bu
On Fri, 2022-04-29 at 18:08 +0200, Andreas Tille wrote:
> To give some actual examples that IMHO are candidates for accept + bug
> report:
Packages with incomplete or incorrect debian/copyright information
currently would recieve a REJECT rather than acceptance. The proposal
would not change that
On April 29, 2022 11:04:57 PM UTC, Paul Wise wrote:
>On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote:
>
>> Just to clarify: is this suggesting that packages from NEW would end
>> up in the archive even with serious bugs? If not, what's the point of
>> the "eventual removal" above? I'm n
with serious defects:
>
> I'm not sure I understand what it proposed:
>
> > The ftpmasters could simply file severity serious bug reports against
> > NEW packages that have issues blocking their entry into Debian. When
> > there are minor issues noticed at the same t
On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote:
> Just to clarify: is this suggesting that packages from NEW would end
> up in the archive even with serious bugs? If not, what's the point of
> the "eventual removal" above? I'm not following you here...
No, the bugs I propose to be filed
t; > I'm not sure I understand what it proposed:
> > > The ftpmasters could simply file severity serious bug reports against
> > > NEW packages that have issues blocking their entry into Debian. When
> > > there are minor issues noticed at the same time, then file bu
le severity serious bug reports against
> > NEW packages that have issues blocking their entry into Debian. When
> > there are minor issues noticed at the same time, then file bugs of a
> > lower severity. Only when a NEW package has not had its serious bugs
> > fixed in a long
On Wednesday, April 27, 2022 8:54:05 PM EDT Paul Wise wrote:
> Hi all,
>
> During the discussions about NEW on debian-devel in recent times, I had
> the idea that instead of the current mechanism of sending REJECT mails,
> Debian could switch to using the BTS for most feedback
On 2022-04-29 at 08:36, Steve McIntyre wrote:
> Paul Wise wrote:
>
>> During the discussions about NEW on debian-devel in recent times, I
>> had the idea that instead of the current mechanism of sending
>> REJECT mails, Debian could switch to using the BTS for most
>
Paul Wise wrote:
>
>During the discussions about NEW on debian-devel in recent times, I had
>the idea that instead of the current mechanism of sending REJECT mails,
>Debian could switch to using the BTS for most feedback on NEW packages.
>
>This means that most discussion about
t; > That's true. I just wanted to mention that some of your ideas
> > are in a way used even now.
>
> Yeah, the proposal was derived from the suggestion to file ITPs for all
> NEW packages, mostly aimed at avoiding the deficiencies with that idea.
Nice.
Kind regards
Andreas.
--
http://fam-tille.de
ome of your ideas
> are in a way used even now.
Yeah, the proposal was derived from the suggestion to file ITPs for all
NEW packages, mostly aimed at avoiding the deficiencies with that idea.
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
ified criteria for
prioritisation of processing of NEW packages, but requesting a review
on #debian-ftp for particular reasons (RC bug fixes, new binaries,
waiting time etc) often means that someone will review it much sooner.
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Descript
Hi Paul,
Am Thu, Apr 28, 2022 at 06:46:43PM +0800 schrieb Paul Wise:
> There are two main categories of NEW packages; source and binary.
> Packages adding an new source should have an ITP bug, but don't
> always, for eg the Rust/Golang teams don't file them for every
> libr
On Apr 28, Paul Wise wrote:
> During the discussions about NEW on debian-devel in recent times, I had
> the idea that instead of the current mechanism of sending REJECT mails,
> Debian could switch to using the BTS for most feedback on NEW packages.
This looks like a good idea to me, bu
On Thu, 2022-04-28 at 09:36 +0200, Andreas Tille wrote:
> What about WNPP bug? When I asked ftpmaster to kindly CC their
> rejects to the WNPP bug I was told that not all packages in new have WNPP
> bugs. If we want to formalise this it could probably be enforced that new
> packages
Hi Paul,
Am Thu, Apr 28, 2022 at 08:54:05AM +0800 schrieb Paul Wise:
> During the discussions about NEW on debian-devel in recent times, I had
> the idea that instead of the current mechanism of sending REJECT mails,
> Debian could switch to using the BTS for most feedback on NEW
Hi all,
During the discussions about NEW on debian-devel in recent times, I had
the idea that instead of the current mechanism of sending REJECT mails,
Debian could switch to using the BTS for most feedback on NEW packages.
This means that most discussion about NEW packages would become public
>> As we have received no notice of errors and as we also do not see
>> anything bad ourself, I just activated the new generator for the
>> archive. Starting with the next dinstall run in a few minutes all
>> Packages and Sources files[2] will be generated using the new tool.
> is that a related br
Hi again,
Cyril Brulebois (08/05/2011):
> is that a related breakage?
>
> [Can't debootstrap]
>
> Same happens with ftp{.fr,.uk,.de,}.debian.org; with i386 and amd64.
Also, ftp.ch.d.o exhibited the infamous Hash Sum mismatches for the
kfreebsd-i386 sid chroot on io.debian.net; switching to ftp.d
Hi,
Joerg Jaspert (07/05/2011):
> As we have received no notice of errors and as we also do not see
> anything bad ourself, I just activated the new generator for the
> archive. Starting with the next dinstall run in a few minutes all
> Packages and Sources files[2] will be generated using the ne
> As we already noted in our meeting minutes, there is one difference in
> the files that you might notice: The order of the fields within one
> entry is different. This should not create any trouble with compliant
> 822 parsers, as order does not matter, but in case you do some weird
> parsing on
Evgeni Golov wrote:
> On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
>
>>> That probably won't make much time difference on "fast" archs (i386,
>>> amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
>>> hold up testing transition :().
>> A missing build will only sl
Le February 12, 2008 03:19:47 am Joerg Jaspert, vous avez écrit :
> On 11293 March 1977, Philippe Cloutier wrote:
>
> Lets jump in here, even if not all points address your mail only.
>
> > If by "disfavour" you imply that it's intentional that NEW packages
>
On 11293 March 1977, Philippe Cloutier wrote:
Lets jump in here, even if not all points address your mail only.
> If by "disfavour" you imply that it's intentional that NEW packages
> aren't built before being accepted, I think you're wrong. I think it
> wo
the usage of the buildd power in Debian?
It avoids building packages that will be rejected.
If by "disfavour" you imply that it's intentional that NEW packages
aren't built before being accepted, I think you're wrong. I think it
would require not completely trivial chan
Le Mon, Feb 11, 2008 at 02:44:59PM -0500, Philippe Cloutier a écrit :
>
> If the NEW package gets earlier in the queue, it's built more quickly,
> but packages that come later are built more slowly.
Dear Philippe,
if the ressources are scarce, I think that it would be fair that the
internal comp
On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
> > That probably won't make much time difference on "fast" archs (i386,
> > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > hold up testing transition :().
> A missing build will only slow testing migration if
Hi,
On Mon, 2008-02-11 at 18:02 +0900, Charles Plessy wrote:
> Le Sun, Feb 10, 2008 at 08:06:38PM +0100, Evgeni Golov a écrit :
> > On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
> >
> > > > That probably won't make much time difference on "fast" archs (i386,
> > > > amd64 etc), but
Le Sun, Feb 10, 2008 at 08:06:38PM +0100, Evgeni Golov a écrit :
> On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
>
> > > That probably won't make much time difference on "fast" archs (i386,
> > > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > > hold up test
On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
> > That probably won't make much time difference on "fast" archs (i386,
> > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > hold up testing transition :().
> A missing build will only slow testing migration if t
That probably won't make much time difference on "fast" archs (i386,
amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
hold up testing transition :().
A missing build will only slow testing migration if the package wasn't
built when the unstable testing delay is over. Since a
Hi *,
at the moment I am preparing the next release of pokerth, which will
contain the pokerth-server package. As this one is new, the whole
pokerth will have to go through NEW again.
However, there is already pokerth 0.6-1-2 in the archive and I do not
change the source tarball, so the chances I
Nico Golde wrote:
>Hi,
>if we would drop some archs now, what is the best way of
>making new packages. Should we just fill in the archs which
>are supported in the future too to hold the load on the
>archs buildds which will be dropped low?
>
>
No. Just leave it as any u
Hallo Adam,
* Adam M. <[EMAIL PROTECTED]> [2005-04-12 23:09]:
> Nico Golde wrote:
> >if we would drop some archs now, what is the best way of
> >making new packages. Should we just fill in the archs which
> >are supported in the future too to hold the load on the
>
* Nico Golde wrote:
> if we would drop some archs now, what is the best way of making new
> packages. Should we just fill in the archs which are supported in
> the future too to hold the load on the archs buildds which will be
> dropped low?
No. It's called proposal because it&
Hi,
if we would drop some archs now, what is the best way of
making new packages. Should we just fill in the archs which
are supported in the future too to hold the load on the
archs buildds which will be dropped low?
regards nico
--
Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http
Hi.
(My apologies if -devel is the wrong place to put this - hints for better
locations are appreciated.)
While I understand that new packages need to be checked, I wondered whether this
rule could be relaxed somewhat for soversion-changing of libraries (i.e. the
advance from lib(.*)\d+ to lib\1
On Wed, Jun 18, 2003 at 01:15:43PM +0200, Jose Carlos Garcia Sogo wrote:
> El día 18 jun 2003, Aníbal Monsalve Salazar escribía:
> > On Wed, Jun 18, 2003 at 11:11:56AM +0200, Pierre Machard wrote:
> > > Your package require a manual action in oder to enter into the pool.
> > > That's why a progress
El día 18 jun 2003, Aníbal Monsalve Salazar escribía:
> On Wed, Jun 18, 2003 at 11:11:56AM +0200, Pierre Machard wrote:
> > Your package require a manual action in oder to enter into the pool.
> > That's why a progressing web page or something like that is not
> > available.
> >
> > Once your pac
On Wed, Jun 18, 2003 at 07:02:10PM +1000, Aníbal Monsalve Salazar wrote:
> I have a new package called fprobe and it's in the new package queue. It
> was uploaded on 14 June as you can see from the message below.
The NEW queue needs manual intervention, so it only gets processed every
now and then
On Wed, Jun 18, 2003 at 11:11:56AM +0200, Pierre Machard wrote:
> Your package require a manual action in oder to enter into the pool.
> That's why a progressing web page or something like that is not
> available.
>
> Once your package get into debian, then you can have an overview of its
> stat
On Wed, Jun 18, 2003 at 05:33:55PM +1000, An?bal Monsalve Salazar wrote:
> Is there a web page where I can see how my packages are progressing in
> the new packages queue?
I'm afraid not. You said you only uploaded it four days ago; I wouldn't
be at all worried about anything
ssing in
> > > the new packages queue?
> >
> > http://packages.qa.debian.org
>
> I don't think http://packages.qa.debian.org is the answer as I have
> tried it already.
>
> I have a new package called fprobe and it's in the new package queue. It
On Wed, Jun 18, 2003 at 10:04:59AM +0200, Pierre Machard wrote:
> On Wed, Jun 18, 2003 at 05:33:55PM +1000, Aníbal Monsalve Salazar wrote:
> > Is there a web page where I can see how my packages are progressing in
> > the new packages queue?
>
> http://packages.qa.debian.or
On Wed, Jun 18, 2003 at 05:33:55PM +1000, Aníbal Monsalve Salazar wrote:
> Is there a web page where I can see how my packages are progressing in
> the new packages queue?
http://packages.qa.debian.org
Cheers,
--
Pierre Machard
<[EMAIL
Is there a web page where I can see how my packages are progressing in
the new packages queue?
On Wed, Apr 16, 2003 at 09:47:59PM +, Miquel van Smoorenburg wrote:
> So I made sysvinit Pre-Depend on initscripts. But that results
> in the following installation problem:
> # dpkg -i *.deb
Pre-Depends aren't resolved by a single invocation of dpkg -i
(whereas Depends are). This is why you u
the files in /etc/init.d/* that used to
be in sysvinit. They are conffiles.
However if you then install the new packages, and you install
the new sysvinit first, sysvinit will 'orphan' the former
conffiles in /etc/init.d (fortunately they are not deleted)
and when you then install inits
On Mon, Apr 15, 2002 at 09:29:10PM +1000, Anthony Towns wrote:
> ] Build-Depends: debhelper (>> 3.0.0), tmake, libqt3-mt-dev, libssl-dev
> ^^
> OpenSSL can't be used with GPL licensed software.
The psi binary package doesn't cont
On Mon, Apr 15, 2002 at 12:44:24PM +0200, Jan Niehusmann wrote:
> Can anybody tell me why the psi package in queue/new doesn't get
> processed?
] You are free to distribute this software under the terms of
] the GNU General Public License.
] On Debian systems, the complete text of the GNU General
Hi!
Can anybody tell me why the psi package in queue/new doesn't get
processed? I made an upload which only changed 'non-US' to 'net' nearly
three weeks ago. (I added another upload with new features last week)
If there is anything wrong with this package, please tell me, so I can
correct it.
Ja
On Mon, 8 Apr 2002, Michael Piefel wrote:
> clear to someone who takes the easy path like me. It would also help if
> I could see your current source; the CVS archive on cvs.debian.org does
> not seem to be current.
It is current.
Jason
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
Am 7.04.02 um 16:53:16 schrieb Jason Gunthorpe:
> Bzzt, I accepted the parts of your patches that met my criterea and asked
> you to rework the rest, you never did, so big surprise that it is
> incomplete.
Oh, I'm very sorry that I didn't read your mind correctly.
The problem is I really don't k
On Sun, 7 Apr 2002, Michael Piefel wrote:
> You, Jason, did not add full i18n support to APT, and were not willing
> to accept my patches for woody. This is OK, as APT is a very central
> package and has been in different shades of freeze for quite some time.
Bzzt, I accepted the parts of your p
Am 6.04.02 um 21:52:03 schrieb Jason Gunthorpe:
> Because it is a bad idea?
As Steve pointed out, good or bad idea is not really a good reason for
delaying packages, at least it has not been so far. Furthermore I don't
think it is a bad idea, for the following reason:
You, Jason, did not add ful
On Sat, Apr 06, 2002 at 09:52:03PM -0700, Jason Gunthorpe wrote:
> > I REALLY REALLY would like to see translated apt in woody.
> > And i cannot understand why apt-i18n is not installed so we could
> > test it. Adding apt-i18n to unstable will not break anything, but
> > interested developers can
On Sun, 7 Apr 2002, Erich Schubert wrote:
> I REALLY REALLY would like to see translated apt in woody.
> And i cannot understand why apt-i18n is not installed so we could
> test it. Adding apt-i18n to unstable will not break anything, but
> interested developers can test this before adding it to
I REALLY REALLY would like to see translated apt in woody.
And i cannot understand why apt-i18n is not installed so we could
test it. Adding apt-i18n to unstable will not break anything, but
interested developers can test this before adding it to real apt.
I've been thinking about calling to sign
The release seems to draw near, but we won't see one of our central
packages translated, namely APT.
Why won't we? Well, perhaps because nobody tried to i18n it, perhaps?
No, that's not it. Well, maybe there are no translations ready. No,
that's not it either.
Patches are ready, 13 translations a
Andreas Metzler wrote:
>
>
> Yes, if you want mp3-Encoding.
>
> I see that it links against libvorbis, so perhaps sometime it'll
> be possible to use vorbis for soundcompression.
> cu andreas
Yep - as soon as we will have more programmers in avifile team :)
[EMAIL PROTECTED]
"AM" == Andreas Metzler <[EMAIL PROTECTED]> writes:
[...]
>> But avifile need lame to encode sound no ?
> Yes, if you want mp3-Encoding.
> I see that it links against libvorbis, so perhaps sometime it'll
> be possible to use vorbis for soundcompression.
No, vcr only works with lame.
Chri
On Tue, Sep 25, 2001 at 11:11:58AM +0200, Eric Van Buggenhaut wrote:
> On Mon, Sep 24, 2001 at 02:01:15PM +0200, Christian Marillat wrote:
> > "EVB" == Eric Van Buggenhaut <[EMAIL PROTECTED]> writes:
> > Yes. Read legal archive:
> > http://lists.debian.org/debian-legal/2001/debian-legal-200101
On Mon, Sep 24, 2001 at 02:01:15PM +0200, Christian Marillat wrote:
> "EVB" == Eric Van Buggenhaut <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >> http://lists.debian.org/debian-devel/2001/debian-devel-200101/msg02634.html,
> >> I
> >> guess.
>
> > IIUC, this message refers to using codecs fr
Christian Marillat <[EMAIL PROTECTED]> wrote:
> "AM" == Andreas Metzler <[EMAIL PROTECTED]> writes:
[snip]
>> vcr uses avifile, which is not restricted to the win*-codecs anymore,
>> but supports/includes libffmpeg (http://ffmpeg.sourceforge.net GPL),
>> too.
> But avifile need lame to encode
"AM" == Andreas Metzler <[EMAIL PROTECTED]> writes:
> On Mon, Sep 24, 2001 at 02:57:05PM +0200, Christian Marillat wrote:
>>> While reading that discussion I do get the impression that
>>> OpenDivX is not DFSG compatible.
>>
>> Yes, And this is why I don't want to include transcode or x2divx
On Mon, Sep 24, 2001 at 02:57:05PM +0200, Christian Marillat wrote:
>> While reading that discussion I do get the impression that
>> OpenDivX is not DFSG compatible.
>
> Yes, And this is why I don't want to include transcode or x2divx or
> another in Debian. Whitout codecs these packages are unusa
"GS" == Guus Sliepen <[EMAIL PROTECTED]> writes:
[...]
>> Yes. Read legal archive:
>>
>> http://lists.debian.org/debian-legal/2001/debian-legal-200101/threads.html#00027
> While reading that discussion I do get the impression that OpenDivX is not
> DFSG compatible.
Yes, And this is why I
On Mon, Sep 24, 2001 at 02:01:15PM +0200, Christian Marillat wrote:
> > IIUC, this message refers to using codecs from microsoft.com, while the
> > divx4linux library provides equivalent,free codecs.
>
> > Is this correct ?
>
> Yes. Read legal archive:
>
> http://lists.debian.org/debian-legal/2
"EVB" == Eric Van Buggenhaut <[EMAIL PROTECTED]> writes:
[...]
>> http://lists.debian.org/debian-devel/2001/debian-devel-200101/msg02634.html,
>> I
>> guess.
> IIUC, this message refers to using codecs from microsoft.com, while the
> divx4linux library provides equivalent,free codecs.
> I
On Mon, Sep 24, 2001 at 12:25:28PM +0200, Guus Sliepen wrote:
> On Mon, Sep 24, 2001 at 12:15:43PM +0200, Eric Van Buggenhaut wrote:
>
> > Is there any problem keeping them from being included in Debian ?
>
> http://lists.debian.org/debian-devel/2001/debian-devel-200101/msg02634.html, I
> guess.
On Mon, Sep 24, 2001 at 12:15:43PM +0200, Eric Van Buggenhaut wrote:
> Is there any problem keeping them from being included in Debian ?
http://lists.debian.org/debian-devel/2001/debian-devel-200101/msg02634.html, I
guess.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PR
On Sun, Sep 23, 2001 at 11:33:29PM +0200, Guus Sliepen wrote:
> On Sun, Sep 23, 2001 at 11:17:47PM +0200, NORMAND Jacques wrote:
>
> > I want to pack the divx4linux codec on one hand and the transcode utilities
> > on the other. But I never packed libraries and docs aren't that clear with
> > that
On Sun, Sep 23, 2001 at 11:17:47PM +0200, NORMAND Jacques wrote:
> I want to pack the divx4linux codec on one hand and the transcode utilities
> on the other. But I never packed libraries and docs aren't that clear with
> that topic. That's why I wan't some clarifications and guidances.
>
> first
I am new to package maintaining (even not an official maintainer) and it's
my second try. My test was on a local-used distributed.net client.
(www.fafa37.com for those want want to take a look).
I want to pack the divx4linux codec on one hand and the transcode utilities
on the other. But I never p
* Fredrik Steen
| On Tue, May 08, 2001 at 03:40:56PM +0200, Wichert Akkerman wrote:
| | Previously Fredrik Steen wrote:
| | > I think that is a great idea. I support it.
| |
| | So you're volunteering to actually implement that?
|
| I could give it a try. Don't really know where to start.
| Wher
On Tue, May 08, 2001 at 03:40:56PM +0200, Wichert Akkerman wrote:
| Previously Fredrik Steen wrote:
| > I think that is a great idea. I support it.
|
| So you're volunteering to actually implement that?
|
| Wichert.
|
| --
|
|
Previously Fredrik Steen wrote:
> I think that is a great idea. I support it.
So you're volunteering to actually implement that?
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
| [EMAIL PROTECTE
On Mon, May 07, 2001 at 08:40:19PM +0200, Piotr Krukowiecki wrote:
| Hi
|
| What do you think about making a new list which would be used to
| announce new packages in Debian ?
| It could be done automatically, when package is uploaded for the first
| time. It would contain description of package
On Mon, May 07, 2001 at 08:40:19PM +0200, Piotr Krukowiecki wrote:
| Hi
|
| What do you think about making a new list which would be used to
| announce new packages in Debian ?
| It could be done automatically, when package is uploaded for the first
| time. It would contain description of package
Hi
What do you think about making a new list which would be used to
announce new packages in Debian ?
It could be done automatically, when package is uploaded for the first
time. It would contain description of package etc.
DWN includes some info about new packages, but it's not very
inform
"Christophe Prud'homme" <[EMAIL PROTECTED]> writes:
> Hi
>
> I am developper on two projects:
> 1- corelinux (LGPL): http://corelinux.sourceforge.net OOA and OOD for Linux
> 2- freefem(GPL): http://kfem.sourceforge.net Finite Element Code and
>
>
> I have created rather involved
Hi
I am developper on two projects:
1- corelinux (LGPL): http://corelinux.sourceforge.net OOA and OOD for Linux
2- freefem(GPL): http://kfem.sourceforge.net Finite Element Code and
I have created rather involved debian packages for them and I would like to
submit them to woody (
Raul Miller wrote:
> Which implies that we should validate packages against developer's key
> before install, and that we should have some kind of list indicating
> which developers are working on which package for which architecture
> which is maintained under tighter control than the mirrors.
>
>
On Mon, Sep 27, 1999 at 11:22:32AM -0500, Steve Greenland wrote:
> I think the key difference is that if some one screws with the BTS or
> the Debian web site, it's not going to *me* any harm during the time
> it takes to discover and undo the damage. If someone installs a bad or
> malicious libc6
1 - 100 of 113 matches
Mail list logo
