-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I recently upgraded the version of a program which has a debian
package, but it's outdated[1][2][3] at this point. My original
sponsor[4] seems unresponsive, I assume he's busy, so I'm requesting
another interim sponsor so that I can get the upgraded
Kapil Hari Paranjape wrote:
Hello,
I am currently the maintainer (non-DD) of tex4ht. This package consists of
only two (!) compiled executables and a large number of Arch: all files.
At least in etch I would like to split this package as suggested in best
packaging practice (Debian Ref). But that
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anibal Monsalve Salazar wrote:
|
| You shouldn't use 1.9.8-4-0.1, it's a NMU version.
|
It's an 'unofficial' package. I'll change it to a proper version when I feel
it's completely ready for upload. Until then I'm not worried about this.
Something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Package name: ucon64
~ Version : 1.9.8-4
~ Upstream Author : NoisyB (Dirk) [EMAIL PROTECTED]
* URL : http://ucon64.sourceforce.net/
* License : GPL
~ Description : Swiss Army Knife of emulation utilities
~
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Weinehall wrote:
|
| Well, I'm not fond of non-free either, and I neither use nor maintain
| any non-free packages, so sponsoring one would indeed be a bit awkward.
| And reading the thread on debian-legal, it seems that upstream has a
| somewhat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anibal Monsalve Salazar wrote:
|
| You shouldn't use 1.9.8-4-0.1, it's a NMU version.
|
It's an 'unofficial' package. I'll change it to a proper version when I feel
it's completely ready for upload. Until then I'm not worried about this.
Something like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| I'll have a look at this package this weekend, and if everything is ok,
| I'll sponsor you. I've got 16 years of experience with 6510-assembly,
| which should be enough... Granted, I haven't done any
| 65816-programming.
|
|
| Regards: David
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| I'll have a look at this package this weekend, and if everything is ok,
| I'll sponsor you. I've got 16 years of experience with 6510-assembly,
| which should be enough... Granted, I haven't done any
| 65816-programming.
|
|
| Regards: David
Package name: cc65
Version : 2.10.1
Upstream Author : Ullrich von Bassewitz [EMAIL PROTECTED]
URL : http://www.cc65.org/
License : zlib-alike
Description : Cross development suite for 65xxx processors
cc65 in a suite of utilities designed to allow
Package name: cc65
Version : 2.10.1
Upstream Author : Ullrich von Bassewitz [EMAIL PROTECTED]
URL : http://www.cc65.org/
License : zlib-alike
Description : Cross development suite for 65xxx processors
cc65 in a suite of utilities designed to allow
Christoph Wegscheider wrote:
I also have some questions:
1.) Is a successfull pbuilder build a guaranty for correct Build-Depends?
As long as you haven't mucked with the settings and installed extra
packages in the pbuilder chroot by default, this is one of the best ways
to be sure, yes.
Christoph Wegscheider wrote:
I also have some questions:
1.) Is a successfull pbuilder build a guaranty for correct Build-Depends?
As long as you haven't mucked with the settings and installed extra
packages in the pbuilder chroot by default, this is one of the best ways
to be sure, yes.
2.) Is
* Package name: gens
Version : 2.12-rc3
Upstream Author : Stephane Akhoun
* URL : http://sourceforge.net/projects/gens/
* License : GPL
Description : Sega Genesis/CD/32X emulator
Gens is a Sega Genesis/CD/32X emulator, originally written for Windows
but
Argh, hold off on this, I just noticed part of this package needs to go
in non-free.
Ok, nevermind... this package has a mess of non-free, I need some
serious time to sort through what's even redistributable.
Teach me to get overzealous, sheesh...
* Package name: gens
Version : 2.12-rc3
Upstream Author : Stephane Akhoun
* URL : http://sourceforge.net/projects/gens/
* License : GPL
Description : Sega Genesis/CD/32X emulator
Gens is a Sega Genesis/CD/32X emulator, originally written for Windows
but
Argh, hold off on this, I just noticed part of this package needs to go
in non-free.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Ok, nevermind... this package has a mess of non-free, I need some
serious time to sort through what's even redistributable.
Teach me to get overzealous, sheesh...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mike Williams wrote:
One of my packages (librmagick-ruby) recently stopped working (details left
intentionally vague). I believe this was due to a change in one of the
libraries it depends on.
In any case, rebuilding against an updated sid install got it working
again, without any source
Mike Williams wrote:
One of my packages (librmagick-ruby) recently stopped working (details left
intentionally vague). I believe this was due to a change in one of the
libraries it depends on.
In any case, rebuilding against an updated sid install got it working
again, without any source changes
Package name: xfce4-xmms-controller-plugin
Version : 1.4.3
Upstream Author : Eoin Coffey [EMAIL PROTECTED]
URL : http://eoin.angrystickman.com/
License : GPL-2
Description : XMMS controller plugin for the XFce4 panel
This plugin allows you to
Package name: xfce4-xmms-controller-plugin
Version : 1.4.3
Upstream Author : Eoin Coffey [EMAIL PROTECTED]
URL : http://eoin.angrystickman.com/
License : GPL-2
Description : XMMS controller plugin for the XFce4 panel
This plugin allows you to
Ok, I found a few pieces of related software that I'd like to package
up. They rely on a program called ZDoom, which I believe somebody else
is intending to package soon-ish. It's a very enhanced source port of
Doom. I'm pretty sure the binary packages belong in contrib, as they
rely on the
Matthew Palmer wrote:
Neither of those files grants your the right to make unlimited copies of the
original source, let alone distribute modified versions. The addendum
might be considered to allow unmodified distribution, but it contradicts the
previous EULA. As such, it is not suitable for
Benjamin Cutler wrote:
The code is originally Copyright Raven, not Activision. Activision is
only mentioned in the EULA. Nowhere in the actual source is Activision
mentioned at all. But if I can't get a satisfactory response from
Raven fairly soon, I'll see what Activision has to say
Matthew Palmer wrote:
What are .acs files when they're at home? General data goes in either
/usr/share or /usr/lib, depending on the architecture-specificity.
They're uncompiled script files. It the case of the .acs files in the
acc package, they're basically a string of #defines not
Matthew Palmer wrote:
Ayup. Fairly obviously somebody just decided hey, let's release the source
for this but didn't really think through the ramifications of what they
were doing.
I wonder if the Open Source Initiative would consider helping companies to
openly licence their software
Matthew Palmer wrote:
You could put zeth in contrib if it depends on acc, or if acc isn't
required, then zeth could go in main.
It's Recommends: acc, but it also relies on commercial WAD data to
function, so zeth is definitely a contrib package.
The biggest problem is going to be that
Ok, I found a few pieces of related software that I'd like to package
up. They rely on a program called ZDoom, which I believe somebody else
is intending to package soon-ish. It's a very enhanced source port of
Doom. I'm pretty sure the binary packages belong in contrib, as they
rely on the
Matthew Palmer wrote:
Neither of those files grants your the right to make unlimited copies of the
original source, let alone distribute modified versions. The addendum
might be considered to allow unmodified distribution, but it contradicts the
previous EULA. As such, it is not suitable for
Benjamin Cutler wrote:
The code is originally Copyright Raven, not Activision. Activision is
only mentioned in the EULA. Nowhere in the actual source is Activision
mentioned at all. But if I can't get a satisfactory response from
Raven fairly soon, I'll see what Activision has to say
Matthew Palmer wrote:
Ayup. Fairly obviously somebody just decided hey, let's release the source
for this but didn't really think through the ramifications of what they
were doing.
I wonder if the Open Source Initiative would consider helping companies to
openly licence their software properly,
Matthew Palmer wrote:
You could put zeth in contrib if it depends on acc, or if acc isn't
required, then zeth could go in main.
It's Recommends: acc, but it also relies on commercial WAD data to
function, so zeth is definitely a contrib package.
The biggest problem is going to be that the
Brian Nelson wrote:
A few more minor problems:
* In interface.fl:163:
callback {system(xterm -e zless
/usr/share/doc/stripclub/readme.txt.gz);}
You can't rely on xterm being available unless you depend upon it, and
even still, that's bad practice. Instead, you should use
Brian Nelson wrote:
A few more minor problems:
* In interface.fl:163:
callback {system(xterm -e zless
/usr/share/doc/stripclub/readme.txt.gz);}
You can't rely on xterm being available unless you depend upon it, and
even still, that's bad practice. Instead, you should use
Brian Nelson wrote:
Benjamin Cutler [EMAIL PROTECTED] writes:
After dinking around with the build tools for a bit, I'm reasonably sure
this is put together correctly, so here goes.
I'm looking for a sponsor for my package stripclub, an online comic
reader and archiver. It supports
Jepri wrote:
'Kay, couple of points here.
1) You could pop up a message box saying You can now import your
comics from /home/.../.../whatever. Or even better, you could pop
up the import dialog, already open to the right directory. That would
make it feel a little bit more
1) You could pop up a message box saying You can now import your
comics from /home/.../.../whatever. Or even better, you could pop
up the import dialog, already open to the right directory. That would
make it feel a little bit more user-orientated, and people like me
wouldn't get
Jepri wrote:
I've attached the debug log. In my first mail I was adding the issue
as a footnote to what I thought were the bigger problems. Looks like
this one is the biggie.
Regrettably I can't seem to find my .comic file (I think the download
overwrote it, I called mine 'sluggy' as
Nicolas Kratz wrote:
Ahem. You DO know that tools like this one are actively damaging online
comic creators?
Most of them are getting a fair share of their revenue from ad sales,
which stripclub, komics etc. pp. are bypassing, or merchandise, which
the user of stripclub will not know about
Brian Nelson wrote:
Oops, I didn't realize you're also the upstream author. That makes the
copyright more OK than I realized. Still, you should include more on
the GPL (versioning, etc.), like in the example in that email.
Fixed, I believe.
Normally you create a package using the
http://www.cs.colostate.edu/~cutlerbc/stripclub/
My bad, correct url is:
http://www.cs.colostate.edu/~cutler/stripclub/
Brian Nelson wrote:
Benjamin Cutler [EMAIL PROTECTED] writes:
After dinking around with the build tools for a bit, I'm reasonably sure
this is put together correctly, so here goes.
I'm looking for a sponsor for my package stripclub, an online comic
reader and archiver. It supports the vast
Jepri wrote:
'Kay, couple of points here.
1) You could pop up a message box saying You can now import your
comics from /home/.../.../whatever. Or even better, you could pop
up the import dialog, already open to the right directory. That would
make it feel a little bit more user-orientated,
1) You could pop up a message box saying You can now import your
comics from /home/.../.../whatever. Or even better, you could pop
up the import dialog, already open to the right directory. That would
make it feel a little bit more user-orientated, and people like me
wouldn't get confused
Jepri wrote:
I've attached the debug log. In my first mail I was adding the issue
as a footnote to what I thought were the bigger problems. Looks like
this one is the biggie.
Regrettably I can't seem to find my .comic file (I think the download
overwrote it, I called mine 'sluggy' as well)
Nicolas Kratz wrote:
Ahem. You DO know that tools like this one are actively damaging online
comic creators?
Most of them are getting a fair share of their revenue from ad sales,
which stripclub, komics etc. pp. are bypassing, or merchandise, which
the user of stripclub will not know about since
Jepri wrote:
In Debian, /etc/alternatives/x-www-browser is a link to an installed
browser.
That might not be the users first choice of browser, but that's
another fight for another time.
Alright, that works for Debian, but I'm guessing there's not much of a
standard Linux-wide?
--
To
Brian Nelson wrote:
Oops, I didn't realize you're also the upstream author. That makes the
copyright more OK than I realized. Still, you should include more on
the GPL (versioning, etc.), like in the example in that email.
Fixed, I believe.
Normally you create a package using the current
exist, mostly dealing with server
oddities. The package was built with pbuilder (sid), and is lintian clean.
Package Name: stripclub
Version : 0.6.1
Upstream Author : Benjamin Cutler [EMAIL PROTECTED]
URL : http://sourceforge.net/projects/stripclub/
License
Steve Langasek wrote:
No, you also have to be sure that the package that is being uploaded to
the archive *was* built on sid, not just that it could have been.
For sponsored uploads, this is usually not an issue, since the sponsor
ought to be doing a rebuild from source before uploading.
Steve Langasek wrote:
No, you also have to be sure that the package that is being uploaded to
the archive *was* built on sid, not just that it could have been.
For sponsored uploads, this is usually not an issue, since the sponsor
ought to be doing a rebuild from source before uploading.
Is
Steve Langasek wrote:
IIRC, the --distribution argument only has an effect the first time you
run 'pbuilder create'.
What should I have done instead to ensure the program was being built
against sid, in that case?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Just how important is it that a package be created on a box running sid?
I'm currently running sarge, and would like to package a program myself
instead of waiting for somebody else, but I'm not sure I want to start
running sid just so I can do that.
I currently have an RFP out on wnpp to see
Just how important is it that a package be created on a box running sid?
I'm currently running sarge, and would like to package a program myself
instead of waiting for somebody else, but I'm not sure I want to start
running sid just so I can do that.
I currently have an RFP out on wnpp to see
First off I'll admit I only gave a quick glance at the Debian New
Maintainters' Corner, but from what I saw, it looked like the first
step wasn't an automated thing. It sounds like the first thing I need to
do it get to know some of the current developers...
In summary the reason I want to
First off I'll admit I only gave a quick glance at the Debian New
Maintainters' Corner, but from what I saw, it looked like the first
step wasn't an automated thing. It sounds like the first thing I need to
do it get to know some of the current developers...
In summary the reason I want to
Ok, would just like to apologize for that little snafu. Not the best
start on a mailing list. Ugh.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
First off I'll admit I only gave a quick glance at the Debian New
Maintainters' Corner, but from what I saw, it looked like the first
step wasn't an automated thing. It sounds like the first thing I need to
do it get to know some of the current developers...
In summary the reason I want to
Ok, would just like to apologize for that little snafu. Not the best
start on a mailing list. Ugh.
62 matches
Mail list logo
