Hi!
* Lucas Nussbaum lu...@lucas-nussbaum.net [091125 19:06]:
Why the harsh answer?
Sorry, the answer was not intended as such (but can indeed be seen as
such). Sorry again :(
Best Regards,
Alexander
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of
On Thu, Nov 26, 2009 at 5:47 AM, Nicolas Joseph
gege2...@redaction-developpez.com wrote:
These should be installed to /usr/share instead. You might need to
patch the source to install them in the right place. See here for why:
http://lintian.debian.org/tags/image-file-in-usr-lib.html
If
Quoting Patrick Matthäi pmatth...@debian.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nuno Paquete schrieb:
Hi everyone,
I want to be a part of Debian developers team and I'm interested in some
orphaned projects.
I'm reading a lot about Debian developing and how to be a Debian
On 2009-11-26, George Danchev danc...@spnet.net wrote:
* start with learning how Debian Bug Tracking System is manipulated
(which is one of the most valuable Debian assets)
* look for neglected bug reports, eventually in packages you are using
* try to submit patches and/or helpful comments
On Thursday 26 November 2009 07:29:17 Charles Plessy wrote:
If a NMU is unavoidable (as opposed to an adoption) maybe it would make
sense to orphan it at the same time, unless Jorge is still interested in
maintaining it.
mppenc has been deprecated by upstream in favour of musepack-tools
On Thu, 26 Nov 2009 16:35:27 +0800, Paul Wise p...@debian.org wrote:
On Thu, Nov 26, 2009 at 5:47 AM, Nicolas Joseph
gege2...@redaction-developpez.com wrote:
These should be installed to /usr/share instead. You might need to
patch the source to install them in the right place. See here for
Esteemed Debian mentors,
Is it considered acceptable for a package to blindly delete, then
recreate its entire directory under /usr/share/doc upon installation or
upgrade ?
Although I probably will do a conditional backup of such a hypothtical
folder in {pre,post}inst anyhow (polite feels like
On Qui, 26 Nov 2009, Lucas B. Cohen wrote:
Esteemed Debian mentors,
Is it considered acceptable for a package to blindly delete, then
recreate its entire directory under /usr/share/doc upon installation or
upgrade ?
Although I probably will do a conditional backup of such a hypothtical
folder
Eduardo M KALINOWSKI wrote:
On Qui, 26 Nov 2009, Lucas B. Cohen wrote:
Is it considered acceptable for a package to blindly delete, then
recreate its entire directory under /usr/share/doc upon installation or
upgrade ?
Why exactly do you want to do that? What do you want to achieve?
I'm
Le 26 nov. 09 à 13:38, Lucas B. Cohen a écrit :
Esteemed Debian mentors,
Is it considered acceptable for a package to blindly delete, then
recreate its entire directory under /usr/share/doc upon installation
or
upgrade ?
[...]
In worse-case scenarios, these could be illogically interpreted
Thibaut Paumard wrote:
Le 26 nov. 09 à 13:38, Lucas B. Cohen a écrit :
Esteemed Debian mentors,
Is it considered acceptable for a package to blindly delete, then
recreate its entire directory under /usr/share/doc upon installation or
upgrade ?
[...]
In worse-case scenarios, these could
Hi!
* Lucas B. Cohen mli...@free.fr [091126 14:40]:
Why exactly do you want to do that? What do you want to achieve?
I'm triaging bugs opened against the Bacula package, and a patch has
been submitted to a .preinst file that can swipe /usr/share/doc/bacula
during upgrades.
Could you
Le 26 nov. 09 à 14:40, Lucas B. Cohen a écrit :
Eduardo M KALINOWSKI wrote:
On Qui, 26 Nov 2009, Lucas B. Cohen wrote:
Is it considered acceptable for a package to blindly delete, then
recreate its entire directory under /usr/share/doc upon
installation or
upgrade ?
Why exactly do
On Thu, Nov 26, 2009 at 03:00:18PM +0100, Lucas B. Cohen wrote:
Of course I understand the standard files under doc/ (and even the whole
directory) are under dpkg's control (obviously the, changelog copyright,
etc.). But perhaps user's don't.
Users don't have write access to anything under
Thibaut Paumard wrote:
I suppose you mean:
bacula: usr-share-doc-symlink-without-dependency
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554197
The idea is to delete the directory in order to replace it by a symlink.
That's the one, thank you.
In my opinion, it is OK to do that
Roger Leigh wrote:
Users don't have write access to anything under /usr in general
(and /usr/share/doc in particular). If they did place files there,
they must have done it after gaining root privs. I.e. they took
deliberate steps to do something they should not under normal
circumstances
On Thu, Nov 26, 2009 at 10:05:59AM +, Sune Vuorela wrote:
On 2009-11-26, George Danchev danc...@spnet.net wrote:
* start with learning how Debian Bug Tracking System is manipulated
(which is one of the most valuable Debian assets)
* look for neglected bug reports, eventually in
Dear mentors, Dear Java people,
I'm packaging sweethome3d [1], a java application which depends on many
libraries, all open source and released under DSFG-compatible licenses:
(a) libitext-java
(b) libvecmath-java
(c) libjava3d-java
(d) freehep-vectorgraphics-svg
(e) sunflow
(f) Java3D 3DS
Dear mentors,
I am looking for a sponsor for my package glpeces.
* Package name: glpeces
Version : 4.0-1
Upstream Author : Innocent De Marchi tangram.pe...@gmail.com
* URL : http://www.mallorcaweb.net/tangrampeces/
Le jeudi 26 novembre 2009 18:51:12, Gabriele Giacone a écrit :
Dear mentors, Dear Java people,
Hi Gabriele,
Welcome a board!
I'm packaging sweethome3d [1]
Great!
And now (f). It's a loader for file in 3D Studio format [4] by
Microcrowd under LGPL
* Package name: java3ds-fileloader
Hello,
while building the new package 'Xfe' I can see that buildd failed on
some architectures.
See: https://buildd.debian.org/~luk/status/package.php?suite=p=xfe
They failed all with the same error:
checking for gcc... ccache cc
checking for C compiler default output file name...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Wiedorn schrieb:
Hello,
while building the new package 'Xfe' I can see that buildd failed on
some architectures.
See: https://buildd.debian.org/~luk/status/package.php?suite=p=xfe
They failed all with the same error:
checking
On Thu, 2009-11-26 at 20:34 +0100, Joachim Wiedorn wrote:
Hello,
while building the new package 'Xfe' I can see that buildd failed on
some architectures.
See: https://buildd.debian.org/~luk/status/package.php?suite=p=xfe
They failed all with the same error:
checking for gcc...
On Thu, 26 Nov 2009 10:59:24 +0100
Jorge Salamero Sanz ben...@debian.org wrote:
On Thursday 26 November 2009 07:29:17 Charles Plessy wrote:
If a NMU is unavoidable (as opposed to an adoption) maybe it would make
sense to orphan it at the same time, unless Jorge is still interested in
Sorry for my late reply, seems I've dropped the mail by error...
Your package drops this symlink with out any mention of that in the
changelog:
lrwxrwxrwx root/root /usr/share/bluemindo/COPYING -
../common-licenses/GPL-3
Did you mean to do that?
Let me check... Yeah, the program does
rom: David Bremner brem...@unb.ca
To: debian-mentors@lists.debian.org
Subject: RFS: lrslib
Dear All;
I am looking for a sponsor for my package lrslib.
* Package name: lrslib
Version : 0.42c-1
Upstream Author : David Avis a...@cs.mcgill.ca
* URL :
Hi David,
On Thu, Nov 26, 2009 at 04:39:20PM -0400, David Bremner wrote:
I am looking for a sponsor for my package lrslib.
* Package name: lrslib
Version : 0.42c-1
Upstream Author : David Avis a...@cs.mcgill.ca
* URL : http://cgm.cs.mcgill.ca
* License
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
Barry deFreese wrote:
IOhannes,
Obviously the preferred method is to create an arch-indep doc package. But
personally for such a small package I would sponsor even with that. (I can't
speak for others though).
sorry to be so nagging,
Hi,
I'm having an issue with distributing a .deb package that has a dependency
on another .deb package that might not be in an available repository (or the
target may not have a network connection at the time of installation). What
I'd like to do, ideally, is embed the dependency inside the
I'm about to release a new version of roxterm and I've been asked to
support GNOME default applications
http://live.gnome.org/ControlCenter/AddingDefaultApplications. Would
you recommend leaving it up to the upstream Makefile or deferring it to
postinst?
--
TH * http://www.realh.co.uk
--
To
Hello -
I am the original author of Apt-Spy (up until ver 2.x) until a friend
(Steven Holmes) took it over and did a re-write.
Stephen Stafford was an acquaintance of mine that was maintaining the
package, but it seems he has since let it go.
I have two requests :
1. I'd like
On Thu, 2009-11-26 at 22:24 +0100, IOhannes m zmölnig wrote:
i'm wondering what would be the best way to keep it maintained in
debian. should i try and join the multimedia team?
should i try and nag the old maintainer (günter geiger) to sponsor the
package?
You are more than welcome to join
On Thu, 2009-11-26 at 12:59 -0800, Joe Smith wrote:
Is this something that's fundamentally impossible or is there some way
to achieve what I need?
I believe this is fundamentally impossible given your description of the
constraints; as you've discovered, dpkg will take out a lock on its
status
What should go in a Debian changelog compared to the upstream changelog?
(a) Confine it to new upstream release, a list of any closed debian
bugs and packaging changes?
(b) As above plus a summary of the most important upstream changes?
(c) Details of all the upstream changes too?
--
TH *
On Thu, Nov 26, 2009 at 10:29:31PM +, Tony Houghton wrote:
What should go in a Debian changelog compared to the upstream changelog?
(a) Confine it to new upstream release, a list of any closed debian
bugs and packaging changes?
(b) As above plus a summary of the most important upstream
On Thu, Nov 26, 2009 at 10:29:31PM +, Tony Houghton wrote:
What should go in a Debian changelog compared to the upstream changelog?
(a) Confine it to new upstream release, a list of any closed debian
bugs and packaging changes?
Keep it to a minimum (that's what upstream's changelog is
Tony Houghton h...@realh.co.uk writes:
What should go in a Debian changelog compared to the upstream
changelog?
Well now, there's “should” and there's “should”.
(a) Confine it to new upstream release, a list of any closed debian
bugs and packaging changes?
Of the options you present, this
On Fri, 27 Nov 2009 10:35:34 +1100
Ben Finney ben+deb...@benfinney.id.au wrote:
Tony Houghton h...@realh.co.uk writes:
What should go in a Debian changelog compared to the upstream
changelog?
Well now, there's “should” and there's “should”.
(a) Confine it to new upstream release, a
Tony Houghton h...@realh.co.uk writes:
Good point. Is there not a control field where you can give a URL for
an upstream changelog?
No, I don't think such a thing belongs in the ‘control’ file. There is
significant pressure *against* adding fields to that file, since the
addition of such a
On Fri, Nov 27, 2009 at 2:13 AM, Innocent De Marchi
tangram.pe...@gmail.com wrote:
Section : games
...
glpeces- Peces (Tangram game)
If you are interested in improving gaming in Debian, you might want to
join the Debian Games Team:
http://wiki.debian.org/Games/Team
--
bye,
On Fri, Nov 27, 2009 at 3:42 AM, Felipe Sateler fsate...@gmail.com wrote:
Your package build-depends on ccache, and it actively enforces it in the
debian/rules file. Why is that?
I would be willing to bet money that the problem is that buildd's have
no (writable) home directory, so ccache
Le Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney a écrit :
Rather, it would be good to have a facility similar to the way the
Debian changelog is currently available: have the upstream changelog
published in a predictable location by package name.
A good project from someone with a lot
On Fri, Nov 27, 2009 at 5:23 AM, Tony Houghton h...@realh.co.uk wrote:
I'm about to release a new version of roxterm and I've been asked to
support GNOME default applications
http://live.gnome.org/ControlCenter/AddingDefaultApplications. Would
you recommend leaving it up to the upstream
I'd suggest contacting the currently listed maintainer and asking them
if they would like to join you in collaborating on the resumption of
maintainence of apt-spy. I'd suggest importing the available history
of the software into a git repository and maintaining it in
collab-maint:
On Fri, Nov 27, 2009 at 4:59 AM, Joe Smith spam...@shaw.ca wrote:
I'm having an issue with distributing a .deb package that has a dependency
on another .deb package that might not be in an available repository (or the
target may not have a network connection at the time of installation). What
On Fri, Nov 27, 2009 at 9:39 AM, Charles Plessy ple...@debian.org wrote:
I propose to store this information and similar ones in a parsable file in the
debian directory of the packages. For instance, debian/upstream-metadata.yaml.
For packages stored in a VCS, this information will be easy to
Ben Finney wrote:
This is what I do. Rationale: The Debian changelog, unlike the upstream
changelog, is available for all Debian packages using standard tools
*before* installing the package, which as a user is the time I most want
to see what has changed in a new release of a package.
Le Fri, Nov 27, 2009 at 11:06:51AM +0800, Paul Wise a écrit :
On Fri, Nov 27, 2009 at 9:39 AM, Charles Plessy ple...@debian.org wrote:
I propose to store this information and similar ones in a parsable file in
the
debian directory of the packages. For instance,
On Fri, Nov 27, 2009 at 12:03 PM, Charles Plessy ple...@debian.org wrote:
Again, all of this is very preliminary and undocumented. The main message I
would like to give is that indeed, for all the information that is not
specific
to Debian, there must be other ways to make them flow from the
Hello,
thanks for this informations!
Fondest regards,
Joachim Wiedorn
signature.asc
Description: PGP signature
50 matches
Mail list logo
