Re: RFS: wmmixer

[Rodolfo kix Garcia]

On Mon, 11 Jul 2011 00:17:20 +0100, Michael Tautschnig wrote:

Hi again,

[...]


>Minor improvements to be made:
>- You don't need to build-depend on quilt.

I don't know how to solve it. I cannot found the build-depend.



Sorry, I meant the Build-Depends: entry in debian/control.

[...]

>
>Concerning your question for getting rid of binary-arch in 
debian/rules: please
>see the man pages of dh_installchangelogs, etc. You will find that 
mostly you
>may specify the upstream files in debian/.  files, 
e.g., for
>dh_installexamples use debian/wmmixer.examples. If that option 
isn't available,

>use overrides, e.g., override_dh_installchangelogs.

Ok, but these files (CHANGES, README, home.mixer) are included in
the original source. To make that, I need to create a patch to move
these files to the correct name in the debian folder. I don't have
problems to do that, but I am not sure if is correct. What do you
think?


[...]

No, you don't need to rename anything. These files, such as
debian/wmmixer.examples should then contain a list of file names to
be installed
as examples.

Does this help as clarification?

Best,
Michael


Thanks Michael,

A new version is in mentors. The changes includes all your comments.

- new wmmixer.changelogs file
- new wmmixer.docs file
- new wmmixer.examples
- debian standards version 3.9.2
- no quilt in control file
- no quilt include in rules
- rules file simplified using debhelper 7

I think the package is finished now.

Thanks a lot for your help.

Regards,

kix.

--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/451fa95dc6c58285f4c2bd5001ec1...@kix.es

Re: Incorporating patches best practice

[Ben Finney]

Gary Briggs  writes:

> The FLTK maintainer submitted a bug today to let me know that he's
> created a change that will impact me:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633474
>
> In the email, he attached a patch.

Until upstream releases a new version with that patch applied, then it's
a separate patch IMO.

> 1) Obviously not appropriate in the general case, but I could do a
> major new release, since I've added a couple of big features since the
> last deiban package.

A new release of the same upstream version? Sure, but any changes would
be distinct from the upstream version still.

> 2) Re-package the current package, but include the one patch, and ramp
> the debian version suffix [to 0.16-2]

That sounds like the right option. The patch can go in ‘debian/patches/’
until upstream releases a new version which incorporates it.

> 3) Re-package at the current version and ramp the debian version
> suffix, but include the patch directly in the source; basically,
> change the main source tarball to be the current svn version.

That would be a lie: you would be claiming the source is what upstream
calls version 0.16, but it's not.

> Of course, that would include the major changes I've made since I
> officially released 0.16...

If you've been making changes that make your release different from the
upstream version, they should be applied as patches to that version.

Please don't modify the source of an already-released version directly
to apply your changes.

> I suspect that the best answer is #2, but that feels a little hokey
> when I'm the upstream as well as the package maintainer.

You need to wear different hats :-)

For more on how to be an upstream which makes Debian's work easier, see
http://wiki.debian.org/UpstreamGuide> and especially
http://wiki.debian.org/UpstreamGuide#Releases_and_Versions>.

-- 
 \ “I have yet to see any problem, however complicated, which, |
  `\  when you looked at it in the right way, did not become still |
_o__)more complicated.” —Paul Anderson |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762n9fmfp@benfinney.id.au

Incorporating patches best practice

[Gary Briggs]

The FLTK maintainer submitted a bug today to let me know that he's
created a change that will impact me:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633474

In the email, he attached a patch. I'm unsure of the best approach to
take for updating my package; I see three obvious choices:
1) Obviously not appropriate in the general case, but I could do a major
new release, since I've added a couple of big features since the last
deiban package.
2) Re-package the current package, but include the one patch, and ramp
the debian version suffix [to 0.16-2]
3) Re-package at the current version and ramp the debian version suffix,
but include the patch directly in the source; basically, change the main
source tarball to be the current svn version. Of course, that would include
the major changes I've made since I officially released 0.16...

I suspect that the best answer is #2, but that feels a little hokey when
I'm the upstream as well as the package maintainer.

Thanks,
Gary


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110711023347.gp3...@gamehenge.icculus.org

Re: RFS: mgen

[Karl Goetz]

On Tue, 14 Jun 2011 17:39:50 +0200
Raoul Borenius  wrote:

> Dear mentors,
> 
> I am looking for a sponsor for my package "mgen".
> 
> * Package name: mgen
>   Version : 5.02-1
>   Upstream Author : Naval Research Laboratory
> 
> * URL : http://cs.itd.nrl.navy.mil/work/mgen/index.php
> * License : Open Source

huh?  ^^^

> http://mentors.debian.net/debian/pool/main/m/mgen/mgen_5.02-1.dsc

I can't find a LICENCE or COPYING file in the package either.
thanks,
kk


-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Re: dpkg status Conffiles obsolete flag?

[Ansgar Burchardt]

Hi,

>> I am hoping to understand the "obsolete" flag on conffiles in the dpkg
>> status file.  There are many packages that include this flag at the
>> end of the line.  For example:
[...]
>
> They are obsolete because they no longer exist in the package.  It is
> the package maintainer's task to deal with them (e.g. remove them if
> they are unmodified and no longer needed).  Unfortunately, this is often
> not done.
>
>> The reason I am looking at this is because I am trying to automate
>> system upgrades from Lenny to Squeeze and some packages have init.d
>> scripts that are marked obsolete and I am trying to understand why.
>>
>> Could some kind soul enlighten me on how conffiles are marked obsolete?
>
> When they are no longer shipped in the package that used to contain
> them; dpkg does not currently remove obsolete conffiles unless that
> package is purged, see #330256¹.

dpkg-maintscript-helper(1) also has a good explanation what happens and
why.  It also makes dealing with them (in maintainer scripts) easier.

Regards,
Ansgar


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/851uxxu47b@tsukuyomi.43-1.org

Re: RFS: wmmixer

[Michael Tautschnig]

Hi again,

[...]
> 
> >Minor improvements to be made:
> >- You don't need to build-depend on quilt.
> 
> I don't know how to solve it. I cannot found the build-depend.
> 

Sorry, I meant the Build-Depends: entry in debian/control.

[...]
> >
> >Concerning your question for getting rid of binary-arch in debian/rules: 
> >please
> >see the man pages of dh_installchangelogs, etc. You will find that mostly you
> >may specify the upstream files in debian/.  files, e.g., for
> >dh_installexamples use debian/wmmixer.examples. If that option isn't 
> >available,
> >use overrides, e.g., override_dh_installchangelogs.
> 
> Ok, but these files (CHANGES, README, home.mixer) are included in
> the original source. To make that, I need to create a patch to move
> these files to the correct name in the debian folder. I don't have
> problems to do that, but I am not sure if is correct. What do you
> think?
> 
[...]

No, you don't need to rename anything. These files, such as
debian/wmmixer.examples should then contain a list of file names to be installed
as examples.

Does this help as clarification?

Best,
Michael



pgparXZ6kFeFf.pgp
Description: PGP signature

Re: RFS: wmmixer

[Rodolfo kix Garcia]

On 10/07/11 02:00, Michael Tautschnig wrote:

Hi,

[...]


Can you check the package again.



I've got a few questions concerning your changes, which aren't necessarily bugs,
but at least I'd like to see the rationale.

- The most recent policy version is 3.9.2; why did you update to 3.9.1 only?


Because the package was update some months ago. The new policy version 
is newer than the update. Changed to in the changelog file 3.9.2. No new 
changes needed.



- Why has the priority been changed to extra?


I changed the priority to extra because some dependency has lower 
priority and lintian showed an error. Now I cannot reproduce the error, 
therefore I change the priority to optional.



- What is the upstream status of your patches, have you forwarded them/tried to
   contact upstream?


Very good question. WMaker is an "old" windowmanager and some 
applications are distributed in many webpages. The wmaker-dev team has a 
webpage for the applications at http://dockapps.org, but some are not 
updated, has bugs, ...


I am talking with the wmaker-dev group to create a repository (git) to 
save all the applications. Carlos R. Mafra has a repository in 
http://repo.or.cz/w/dockapps.git and we will try to save the dockapps there.


I will save a comment in the watch file about it. The application is in 
the repo at 
http://repo.or.cz/w/dockapps.git/tree/21625f40b5f71ecd4b9832836f1a89ef3bb20b74:/wmmixer-1.5



Minor improvements to be made:
- You don't need to build-depend on quilt.


I don't know how to solve it. I cannot found the build-depend.


- No need for "include /usr/share/quilt/quilt.make" in debian/rules


Done


- debian/watch only holds a comment, that doesn't really help uscan to check the
   status. Could you make that a proper watch file?


The files are now in a git folder. This git do not include tar.gz files. 
I added the new git folder as comment in the watch file. I cannot found 
info about how to include git in the watch file (if is possible).




Concerning your question for getting rid of binary-arch in debian/rules: please
see the man pages of dh_installchangelogs, etc. You will find that mostly you
may specify the upstream files in debian/.  files, e.g., for
dh_installexamples use debian/wmmixer.examples. If that option isn't available,
use overrides, e.g., override_dh_installchangelogs.


Ok, but these files (CHANGES, README, home.mixer) are included in the 
original source. To make that, I need to create a patch to move these 
files to the correct name in the debian folder. I don't have problems to 
do that, but I am not sure if is correct. What do you think?



Please provide some information on the questions I've posed above and please
take a look at the possible improvements. Then your package should be ready to
be uploaded.


Please, reply me about my questions. Then, I will upload a new version.


Hope this helps,


Yes! Thanks a lot for your time.

kix.


Michael




--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1a2cb3.3040...@kix.es

Re: RFS: taxbird (updated package)

[Michael Tautschnig]

Hi Olaf,

> Dear mentors,
> 
> I am looking for a sponsor for the new version 0.16-0.1
> of the package "taxbird".
> 
> It builds these binary packages:
> taxbird- The first free Elster client (German Tax Declarations)
> 
[...]

Could you please briefly explain why you are NMUing this package? Are you
intending to take over package maintainership? What about the previous
maintainer?

Thanks a lot,
Michael



pgp4HYNTgaXLU.pgp
Description: PGP signature

Re: RFS: JLDrill

[Michael Tautschnig]

Hi again,

> On 11 July 2011 06:09, Michael Tautschnig  wrote:
> > Just one more note, though: you don't even have filed an ITP for this 
> > package,
> > which could also have drawn more interest to this package.
> 
> Hi Michael.  Thanks for the response.  Since I didn't get a response
> for the RFP, I thought I would wait until the next release before I tried 
> again.
> I will definitely contact the Debian Ruby team.  Thanks for the advice.
> Also, what is an ITP?  I'm new to Debian, so I'm not familiar with
> everything yet.
> 

Oops, sorry for being brief on that. An "ITP" is the intent-to-package, which is
a bug report to be filed against the wnpp pseudo package. Have you already had a
chance to read the "Debian New Maintainers' Guide"? I'd suggest to start from
there, which at least will briefly touch upon the ITP in the section dedicated
to debian/changelog. 

Hope this helps,
Michael



pgpbfHP4xE671.pgp
Description: PGP signature

Re: RFS: mosh

[Michael Tautschnig]

Hi,

I'm sorry, I haven't yet reviewed your package, I'm only commenting on the
issues you raised.

[...]
> It builds these binary packages:
> mosh   - fast R6RS Scheme interpreter
> mosh-doc   - reference documentation for Mosh
> 
[...]
> 
> #1.  It requires an embedded copy of the Boehm GC.  dmoerner previously
> attempted to unbundle this and it did work, however a recent change in
> Mosh relies on a non-default compile time configuration of the GC, and
> also bugfixes which are only present in the CVS version.  As such it's
> quite impractical to unbundle the GC library at the moment, and the
> upstream bug is marked WONTFIX.  See:
> http://code.google.com/p/mosh-scheme/issues/detail?id=156
> 
> For reference, I have attempted to build against a libgc using a default
> configuration and it breaks badly at runtime.
> 

Given that, according to the discussion in #156, some earlier version had
apparently worked fine: couldn't the Debian package simply revert that
"optimization" that requires GC_DONT_ADD_BYTE_AT_END?

I must state that a package that only works under very specific compile-time
settings of an external library makes me shiver. It seems that mosh has no
safety checks and the necessity to rely on such low-level optimizations raises
questions about the design of this software...

> #2.  psyntax-mosh requires several Scheme sources to be compiled into a
> single 'binary' (which is actually text, but not human-editable).
> However, the build script requires a previous version of Mosh.  Releases
> are distributed with a precompiled version so the users doesn't need an
> older version.  I asked about this on IRC, and it seems it's
> unacceptable to use the precompiled file in the final build, so two
> solutions were suggested.  One is to initially build using the
> precompiled file and then rebuild over the top using the
> now-bootstrapped version (The version doesn't necessarily need to be
> older.)  The other method is to split the source package into two
> packages, mosh-bootstrap and mosh, where mosh-bootstrap is
> arch-independent and mosh arch-dependent.  Neither of these are clean
> but that is probably unavoidable.
> 

Well, then, which route did you follow? I don't really see a problem with the
rebuild-over-the-top variant, although of course this introduces some
complexity.

Best regards,
Michael



pgpVecbDlSo3u.pgp
Description: PGP signature

Re: RFS: JLDrill

[Mike Charlton]

On 11 July 2011 06:09, Michael Tautschnig  wrote:
> Just one more note, though: you don't even have filed an ITP for this package,
> which could also have drawn more interest to this package.

Hi Michael.  Thanks for the response.  Since I didn't get a response
for the RFP, I thought I would wait until the next release before I tried again.
I will definitely contact the Debian Ruby team.  Thanks for the advice.
Also, what is an ITP?  I'm new to Debian, so I'm not familiar with
everything yet.

MikeC


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/camzseavk65nopag9z8rvo1hj+jrsap7hbsolyf7gknvsszu...@mail.gmail.com

Re: RFS: gogglesmm

[Michael Tautschnig]

Hi,

> Dear mentors,
> 
> I am looking for a sponsor for my package "gogglesmm".
> 
> * Package name: gogglesmm
>   Version : 0.12.2-5
>   Upstream Author : Sander Jansen 
> * URL : http://code.google.com/p/gogglesmm/
> * License : GPLv3
>   Section : sound
> 
> It builds these binary packages:
> gogglesmm  - Goggles Music Manager
> 
> The package appears to be lintian clean.
> 
[...]

I've taken a look at your package and noticed the following issues that I'd like
to see addressed before sponsoring its upload:

- No ITP. Please file an ITP first and close it in your changelog.
- The conflicts/replaces for musicmanager-tray, musicmanager seem strange as
  neither of which exists as a Debian package.
- debian/copyright: Please indicate which version of the GPL your packaging
  conforms to. Updating debian/copyright to DEP-5 format would be a plus.
- Some header files in src/ are LGPL, not GPL. Needs to be noted in
  debian/copyright.
- Have you considered moving to v3 (quilt) source format, dropping dpatch?
- I can't confirm the lintian-cleanliness, there's one warning about the lack of
  a man page and several info-level messages.

Hope this helps,
Michael



pgpwMtr1EoSAz.pgp
Description: PGP signature

Re: RFS: JLDrill

[Michael Tautschnig]

Hi,

> This is again a request for a sponsor for JLDrill, a Japanese
> language learning tool.  I'm not a Debian developer
> and have had some difficulty making good packages.  I
> appreciate your patience! :-)  This time I have removed the need for rake
> to build the debian package.  I've left ruby, rspec, rcov and ruby-gems
> in the build dependencies because they are  necessary if you
> want to do development on JLDrill, but they should no longer
> be necessary to build the debian package (I use the debhelper
> scripts now).
> 
[...]

It appears that this RFS is open for quite a while now, with no substantial
response. As myself I have no knowledge about packaging ruby applications, I'd
like to point out the Debian ruby teams instead. Please take a look at
http://wiki.debian.org/Teams/Ruby and contact those people.

Just one more note, though: you don't even have filed an ITP for this package,
which could also have drawn more interest to this package.

Best regards,
Michael



pgp6ChewKWbDy.pgp
Description: PGP signature

Re: RFS: mgen

[Michael Tautschnig]

Hi,

> Dear mentors,
> 
> I am looking for a sponsor for my package "mgen".
> 
> * Package name: mgen
>   Version : 5.02-1
>   Upstream Author : Naval Research Laboratory 
> * URL : http://cs.itd.nrl.navy.mil/work/mgen/index.php
> * License : Open Source
>   Section : net
> 
> It builds these binary packages:
> mgen   - The Multi-Generator for IP network performance tests
> 
> The package appears to be lintian clean.
>

Err, no:

W: mgen source: debian-rules-missing-recommended-target build-arch
W: mgen source: debian-rules-missing-recommended-target build-indep
W: mgen source: out-of-date-standards-version 3.8.4 (current is 3.9.2)
I: mgen source: debian-watch-contains-dh_make-template
E: mgen: helper-templates-in-copyright
W: mgen: description-synopsis-starts-with-article
I: mgen: arch-dep-package-has-big-usr-share 4497kB 92%

[...]

Anyhow, despite these the package looks pretty much ok; and all of the above
should be easy to address. Just two more issues that need to be resolved:

- The package ships PDF files; please rebuild them from source as part of the
  package build process; I suppose all the necessary sources are part of the
  package anyhow.  Otherwise we will be in trouble and those files will have to
  be removed.
- Your debian/watch file is slightly broken: the final src-mgen-(.*).02.tar.gz
  should probably be src-mgen-(.*).tar.gz, otherwise the Debian package will be
  reported as being newer than upstream.

Two further nice-to-have changes: Use dh 7 simplified debian/rules; this would
immediately address the first two lintian warnings. Moving debian/copyright to
DEP-5 could go along with the fix of the error reported by lintian.

Hope this helps,
Michael




pgp39xby647nc.pgp
Description: PGP signature

Re: dacco and qdacco packages waiting sponsor

[Michael Tautschnig]

Hi,

> Hi!
> 
> These packages are waiting for a sponsor:
> http://mentors.debian.net/debian/pool/main/q/qdacco and
> http://mentors.debian.net/debian/pool/main/d/dacco.
> 
> This is a Catalan-English dictionary and a query GUI.
> 
[...]

I've just uploaded dacco, looks good.

For qdacco, however, I get an FTBFS because of an outdated symbols file. Looking
at the diff, this is quite likely caused by name mangling changes in GCC. I'd
suggest moving to c++ tags, as supported by recent dpkg-gensymbols, which permit
to use human readable signatures. Please let me know if you need any help with
those.

Thanks a lot for your work,
Michael



pgpjx4XNzZtZU.pgp
Description: PGP signature

Re: RFS: Jampal (2nd try)

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10.07.2011 18:21, Peter Bennett wrote:
> Hi Arno
> Which VCS links are you referencing in the control file? I am using the
> sourceforge.net subversion for the debian files, is there a better choice?

Please see [1]. The VCS should point to the version control system YOU
are using to maintain and deploy your stuff for Debian. Its not about
the upstream repository.

If you are maintaining this stuff in a Sourceforge repository from you,
that's fine and point there then. Otherwise I'd suggest you to go with
collab-maint [2]

> I am cleaning up the descriptions for jampal and tagbkup.
> Regarding openoffice, I am removing it from the dependency lists. It is
> only used for a couple of commands and I have added error messages to
> those that will tell the user if he needs openoffice/libreoffice and
> does not have it.

Fair enough


[1]
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-vcs
[2] http://wiki.debian.org/Alioth/PackagingProject
- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOGgjlAAoJEMcrUe6dgPNtxoAQAKfK0KJIXVDLh1AJfhOgfu+V
7umPofYocAV66eVkBQ5uPFg4T0CGYXwdKJVxPNZjo4Q6SX5EevaJDgpnnl1BvpLG
J3YK2yCJ1Up7fm2TT/wnJsS/Nsqr9pUaYor54GW7BmOpoRujaulAFiEiRbSO9AK4
pJVxIUgj2u4Yq6y8r5nyQuUPOYLXRQ298LJy6lQOTMvBYRH62LjbwOjwK9Gwkn9I
nblH0qbcx8NI8N6ov5MmpkA210Y9jlmSa65aOEPeRmARAysgYATBWYwY73pdtNsf
rSodVtZEv6EmaYfFS8pnuJOxXNgP5e9dl+UPZ5X6YwF9KFbGXDHE6YWRo9+7Rzjn
jRrBCVySs57o1K+j3Nr0B7hDw8ChChDnhjM8KJldTz3JevxKk1hbiGDEqjQ3aQpH
0DTtRk6rs/Qg3C6jliYxh5OlAK4fY/tQtXDys0pkRz3YWEgwr1TecWOEHjyMx1+l
Buaeg6LhZEwX7Zk9mj1S694XZdqB1NrPHcbxAGNCDzZi8NgcotugTWkwPfCuNOm9
3Mkqgk3F7+Qmz2etAjRfbXfWL7JavZ29eDhd2fAsQRAwcHaL/0UrzoZCE+ka6qYr
mSeVIFVaQRXHQrbAt706t57OTH0RFWBgX7eQCjwxaEHXHW7lxd2htUnAx0AcA8KI
DpHt/BK0qv41WVMvcYAM
=skjh
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1a08e5.8070...@toell.net

Re: dpkg status Conffiles obsolete flag?

[Sven Joachim]

On 2011-07-10 20:55 +0200, Bob Proulx wrote:

> I am hoping to understand the "obsolete" flag on conffiles in the dpkg
> status file.  There are many packages that include this flag at the
> end of the line.  For example:
>
> Package: file
> Conffiles:
>  /etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete
>  /etc/magic 272913026300e7ae9b5e2d51f138e674 obsolete
>
> And there many more examples such as in apache2.2-common and gsfonts.
> These conffiles that are marked obsolete do exist on the system. 
>
> I could not find where this was documented.  The man page or dpkg says:
>
>/var/lib/dpkg/status
>   Statuses of available packages. This file contains
>   information about whether a package is marked for
>   removing or not, whether it is installed or not,
>   etc. See section INFORMATION ABOUT PACKAGES for more
>   info.
>
> But the section "INFORMATION ABOUT PACKAGES" does not say anything
> about this field that I could find.
>
> I downloaded the source to several packages having obsolete conffiles
> marked and I could not find any reference in the package that would
> cause those files to be marked as obsolete.

They are obsolete because they no longer exist in the package.  It is
the package maintainer's task to deal with them (e.g. remove them if
they are unmodified and no longer needed).  Unfortunately, this is often
not done.

> The reason I am looking at this is because I am trying to automate
> system upgrades from Lenny to Squeeze and some packages have init.d
> scripts that are marked obsolete and I am trying to understand why.
>
> Could some kind soul enlighten me on how conffiles are marked obsolete?

When they are no longer shipped in the package that used to contain
them; dpkg does not currently remove obsolete conffiles unless that
package is purged, see #330256¹.

Cheers,
   Sven


¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330256


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87box16ht7@turtle.gmx.de

dpkg status Conffiles obsolete flag?

[Bob Proulx]

I am hoping to understand the "obsolete" flag on conffiles in the dpkg
status file.  There are many packages that include this flag at the
end of the line.  For example:

Package: file
Conffiles:
 /etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete
 /etc/magic 272913026300e7ae9b5e2d51f138e674 obsolete

And there many more examples such as in apache2.2-common and gsfonts.
These conffiles that are marked obsolete do exist on the system. 

I could not find where this was documented.  The man page or dpkg says:

   /var/lib/dpkg/status
  Statuses of available packages. This file contains
  information about whether a package is marked for
  removing or not, whether it is installed or not,
  etc. See section INFORMATION ABOUT PACKAGES for more
  info.

But the section "INFORMATION ABOUT PACKAGES" does not say anything
about this field that I could find.

I downloaded the source to several packages having obsolete conffiles
marked and I could not find any reference in the package that would
cause those files to be marked as obsolete.

The reason I am looking at this is because I am trying to automate
system upgrades from Lenny to Squeeze and some packages have init.d
scripts that are marked obsolete and I am trying to understand why.

Could some kind soul enlighten me on how conffiles are marked obsolete?

Thanks!
Bob



signature.asc
Description: Digital signature

Re: RFS: steadyflow (now in Ubuntu)

[Maia Kozheva]

Thanks for sponsoring!

Maia

11.07.2011 01:09, Michael Tautschnig wrote:
>> I've uploaded a new version to mentors, which patches the upstream build
>> system to use valac-0.12 as the executable name. Not very pretty, but
>> since we depend on the versioned package anyway, the version can always
>> be changed in both places.
>>
> 
> Ok, looks good. Built & uploaded.
> 
> Thanks a lot for your work,
> Michael
> 




signature.asc
Description: OpenPGP digital signature

Re: RFS: steadyflow (now in Ubuntu)

[Michael Tautschnig]

> I've uploaded a new version to mentors, which patches the upstream build
> system to use valac-0.12 as the executable name. Not very pretty, but
> since we depend on the versioned package anyway, the version can always
> be changed in both places.
> 

Ok, looks good. Built & uploaded.

Thanks a lot for your work,
Michael



pgpHVqgENQ8vQ.pgp
Description: PGP signature

Re: RFS: steadyflow (now in Ubuntu)

[Maia Kozheva]

I've uploaded a new version to mentors, which patches the upstream build
system to use valac-0.12 as the executable name. Not very pretty, but
since we depend on the versioned package anyway, the version can always
be changed in both places.

11.07.2011 00:25, Michael Tautschnig wrote:

> I'm afraid, however, that you will have to cope with this situation. You could
> use Build-Conflicts to hack away the problem, but then I wonder whether the
> problem would just be deferred to runtime?
> 
> Best,
> Michael
> 




signature.asc
Description: OpenPGP digital signature

Re: RFS: steadyflow (now in Ubuntu)

[Michael Tautschnig]

Hi,

> This is strange. I just tried building it in a sid pbuilder, and it
> succeeded - in fact, I cannot reproduce this build error at all. Could
> it be possible that you have vala-0.12 installed alongside some other
> version of Vala (say, 0.10) and it's not the default version selected in
> alternatives?
> 
[...]

Hmm, indeed I do:

# dpkg -l | grep vala
ii  libvala-0.10-00.10.4-1  
C# like language for the GObject system - library
ii  libvala-0.12-00.12.1-1  
C# like language for the GObject system - library
ii  valac 0.10.4-1  
C# like language for the GObject system
ii  valac-0.100.10.4-1  
C# like language for the GObject system
ii  valac-0.120.12.1-1  
C# like language for the GObject system

I'm afraid, however, that you will have to cope with this situation. You could
use Build-Conflicts to hack away the problem, but then I wonder whether the
problem would just be deferred to runtime?

Best,
Michael



pgpx5JRfRllcB.pgp
Description: PGP signature

Re: RFS: Jampal (2nd try)

[Peter Bennett]

Hi Arno

Thanks for your comments. I am fixing the items you mention as well as
the ones from Benoît.
Which VCS links are you referencing in the control file? I am using the
sourceforge.net subversion for the debian files, is there a better choice?
I am cleaning up the descriptions for jampal and tagbkup.
Regarding openoffice, I am removing it from the dependency lists. It is
only used for a couple of commands and I have added error messages to
those that will tell the user if he needs openoffice/libreoffice and
does not have it.
I shall be creating a new package soon.

Regards
Peter


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e19d184.1050...@comcast.net

Re: RFS: steadyflow (now in Ubuntu)

[Maia Kozheva]

This is strange. I just tried building it in a sid pbuilder, and it
succeeded - in fact, I cannot reproduce this build error at all. Could
it be possible that you have vala-0.12 installed alongside some other
version of Vala (say, 0.10) and it's not the default version selected in
alternatives?

10.07.2011 22:50, Michael Tautschnig wrote:
> 
> Ok, cool, please just let me/the list know when an updated version is 
> available.
> 
> Best,
> Michael
> 




signature.asc
Description: OpenPGP digital signature

Re: RFS: steadyflow (now in Ubuntu)

[Michael Tautschnig]

> The reason I added libappindicator-dev | hello was to avoid this
> dependency being the only delta between Debian and Ubuntu. This way I'd
> be able to sync from Debian into Ubuntu without changes. If that's flat
> out unacceptable, I'll leave the dependency out and add it in Ubuntu
> only until libappindicator appears in Debian.
> 

I would be fine sponsoring the package with the libappindicator-dev | hello;
it'll be your task to handle possible build failures :-)

> As for the second reason, it's strange - it built last time I checked.
> I'll look into it.
> 
[...]

Ok, cool, please just let me/the list know when an updated version is available.

Best,
Michael



pgpscJn22YZV9.pgp
Description: PGP signature

Re: RFS: steadyflow (now in Ubuntu)

[Maia Kozheva]

The reason I added libappindicator-dev | hello was to avoid this
dependency being the only delta between Debian and Ubuntu. This way I'd
be able to sync from Debian into Ubuntu without changes. If that's flat
out unacceptable, I'll leave the dependency out and add it in Ubuntu
only until libappindicator appears in Debian.

As for the second reason, it's strange - it built last time I checked.
I'll look into it.

10.07.2011 21:36, Michael Tautschnig wrote:
> Hi,
> 
>> I have updated my steadyflow package on mentors to the latest upstream 
>> version 
>> 0.1.7, based on the version of the package I got approved into Ubuntu 
>> Oneiric. 
>> I would be grateful if someone could review and sponsor the package.
>>
>> I'm upstream and a DM, and if I have the DM-Upload-Allowed flag set on this 
>> package, I'll be able to maintain it from now on in both Debian and Ubuntu 
>> without any need for further sponsorship.
> 
> The package looks mostly fine as far as the formal aspects are concerned, but
> there are two practical problems:
> 
> - libappindicator-dev doesn't exist in Debian, and I do have certain doubt 
> that
>   the autobuilders would successfully resolve the alternative depends to 
> hello.
>   I'd suggest removing libappindicator-dev from the build dependencies.
> - The package FTBFS:
> 
> dh_auto_configure -- -DCOMPILE_GSETTINGS_ON_INSTALL=OFF
> [...]
> -- Checking for libappindicator...
> -- checking for module 'appindicator-0.1'
> --   package 'appindicator-0.1' not found
> -- checking for a minimum Vala version of 0.12.0
> CMake Error at cmake/ValaVersion.cmake:88 (message):
>   Vala version 0.12.0 or greater is required.
> Call Stack (most recent call first):
>   CMakeLists.txt:35 (ensure_vala_version)
> 
> Hope this helps,
> Michael
> 




signature.asc
Description: OpenPGP digital signature

Re: RFS: Jampal (2nd try)

[Niels Thykier]

On 2011-07-10 16:45, Peter Bennett wrote:
> Hi Benoît
> 

Hi

> I am about to release a new version of jampal, and I have addressed most
> of these issues (see below) in my latest debian build. However I still
> have a couple of questions.
> I am using wheezy/sid x86_64
> This is the lintian report
> lintian -I --pedantic *.dsc
> P: jampal source: unneeded-build-dep-on-quilt
> 
> I still have the quilt in there in case I need to apply some patches. Is
> this OK or should I remove the dependency?
> 
> [...]

I believe that the following should answer your question:
 $ lintian-info -t unneeded-build-dep-on-quilt
[...]
N: This package build-depends on quilt, which is not required since
N: dpkg-source will apply patches at unpack time for 3.0 (quilt) source
N: packages.
[...]
N: [...] If you keep the build-depends on quilt to ease backporting
N: to older releases, then please ignore/override this tag.
[...]

~Niels


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e19c05e.2050...@thykier.net

Re: RFS: Jampal (2nd try)

[Peter Bennett]

Hi Benoît

I am about to release a new version of jampal, and I have addressed most
of these issues (see below) in my latest debian build. However I still
have a couple of questions.
I am using wheezy/sid x86_64
This is the lintian report
lintian -I --pedantic *.dsc
P: jampal source: unneeded-build-dep-on-quilt

I still have the quilt in there in case I need to apply some patches. Is
this OK or should I remove the dependency?

I am not sure what to do about the copyright on ID3v2. It is not a
license, and it is not code that is copyright. This is documentation
that I have included from ID3v2 in the help files. It makes sense that
the documentation cannot be changed since it describes a standard.
Perhaps the copyright statement for the documentation should not be
included in the debian/copyright file?

Peter

On 7/1/2011 6:02 PM, Benoît Knecht wrote:
> Hi Peter,
>
> Peter Bennett wrote:
>> I am looking for a sponsor for my package "jampal".
>> This is my second attempt. I have fixed errors that were pointed out to
>> me last time.
>>
>> * Package name: jampal
>>   Version : 02.01.03-1
>>   Upstream Author : I am the upstream author. Peter Bennett
>> .
>> * URL : http://jampal.sourceforge.net
>> * License : GPLv3 or higher
>>   Section : sound
>>
>> It builds these binary packages:
>> tagbkup- back up and restore mp3 tags
>> jampal - mp3 song library management system and player
> I reviewed your package, and here's a list of things that could be
> improved:
>
>   - Your debian/watch file currently matches the upstream version
> 'build-Linux-x86_64-02.01.04', which is not what you want; you need
> to refine it; also, this file shouldn't be executable.
>
>   - lintian -I --pedantic jampal_02.01.03-1.dsc reports the following:
>
>   P: jampal source: source-contains-svn-commit-file svn-commit.2.tmp
>   P: jampal source: source-contains-svn-commit-file svn-commit.tmp
>   P: jampal source: source-contains-prebuilt-windows-binary 
> misc/windows-32/mbrola.exe
>   P: jampal source: source-contains-prebuilt-windows-binary 
> misc/windows-32/pttsjni.dll
>   P: jampal source: source-contains-prebuilt-windows-binary 
> misc/windows-32/libgcc_s_dw2-1.dll
>   P: jampal source: source-contains-prebuilt-windows-binary 
> misc/windows-32/ptts.exe
>   P: jampal source: unneeded-build-dep-on-quilt
>   W: jampal source: out-of-date-standards-version 3.9.1.0 (current is 
> 3.9.2)
>
>   - debian/copyright: I don't think ID3V2 is a free license; it doesn't
> seem to allow modifications, only redistribution. Also, you may want
> to upgrade to the latest DEP-5 revision.
>
>   - debian/control: you recommend openoffice packages, it seems
> overkill. "The Recommends field should list packages that would be
> found together with this one in all but unusual installations" [1],
> would you say it's the case here?
>
> [1] 
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
>
> Your long description seems a bit convoluted and you repeat the
> words "the library" a lot. Also, your spelling of ID3v2 is not
> consistent. Have a look at [2] for the best practices.
>
> [2] 
> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-control
>
>   - debian/patches: if you're upstream, you shouldn't have any patches
> here, you can merge them directly.
>
>   - debhelper compatibility level should be 8 (in debian/compat and
> debian/control).
>
> Cheers,
>


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e19bafc.4000...@comcast.net

Re: RFS: steadyflow (now in Ubuntu)

[Michael Tautschnig]

Hi,

> I have updated my steadyflow package on mentors to the latest upstream 
> version 
> 0.1.7, based on the version of the package I got approved into Ubuntu 
> Oneiric. 
> I would be grateful if someone could review and sponsor the package.
> 
> I'm upstream and a DM, and if I have the DM-Upload-Allowed flag set on this 
> package, I'll be able to maintain it from now on in both Debian and Ubuntu 
> without any need for further sponsorship.

The package looks mostly fine as far as the formal aspects are concerned, but
there are two practical problems:

- libappindicator-dev doesn't exist in Debian, and I do have certain doubt that
  the autobuilders would successfully resolve the alternative depends to hello.
  I'd suggest removing libappindicator-dev from the build dependencies.
- The package FTBFS:

dh_auto_configure -- -DCOMPILE_GSETTINGS_ON_INSTALL=OFF
[...]
-- Checking for libappindicator...
-- checking for module 'appindicator-0.1'
--   package 'appindicator-0.1' not found
-- checking for a minimum Vala version of 0.12.0
CMake Error at cmake/ValaVersion.cmake:88 (message):
  Vala version 0.12.0 or greater is required.
Call Stack (most recent call first):
  CMakeLists.txt:35 (ensure_vala_version)

Hope this helps,
Michael



pgpvBcNxZaopk.pgp
Description: PGP signature

Re: RFS: propel

[Michael Tautschnig]

Hi,

> Dear mentors,
> 
> I am looking for a sponsor for my package "propel".
> 
> * Package name: propel
>   Version : 1.5.6-1
>   Upstream Author : [fill in name and email of upstream]
> * URL : http://www.propelorm.org/
> * License : MIT License
>   Section : php
> 
> It builds these binary packages:
> propel - Object-Relational Mapping (ORM) library written in PHP5
> 
> The package appears to be lintian clean.
>

Further comments follow below, but that's simply not true: I got 13 warnings and
1 error.

> The upload would fix these bugs: 330203
> 
> My motivation for maintaining this package is: I'm user of symfony
> framework with Propel as ORM.
> 
[...]

Have you spoken to the symfony maintainers for sponsorship? As you are anyway
intending to upload this package with pkg-symfony-maint set as maintainer, you
would probably want to incorporate their feedback and might well get much more
appropriate input from that side.

For the general comments, however, I've got three notes:

- test/etc/xsl has files with Apache 2.0 license. This must be noted in
  debian/copyright.
- Having read the package description in debian/control, I have no idea what
  this package is about. Please make it much more verbose and possibly reword
  it. Here, the debian-l10n-english list may be of help.
- A new upstream release is available.

Best regards,
Michael



pgp2AIVUVUmmQ.pgp
Description: PGP signature

Re: RFS: xxxterm (2nd attempt)

[Luis Henriques]

Hi Kilian,

Kilian Krause  writes:
> Even though I've not found a debian/copyright info for *.png and *.desktop
> files I'll sponsor your package as is. Please try to clarify what license
> upstream intended for them (probably ISC too) and document that
> appropriately (or even better have them ship a LICENSE file in their
> tarball). Let's see what FTPmasters will have to say.
>
> Further I'm still finding lintian moaning about:
> I: xxxterm: hyphen-used-as-minus-sign usr/share/man/man1/xxxterm.1.gz:70
> I: xxxterm: hyphen-used-as-minus-sign usr/share/man/man1/xxxterm.1.gz:71
> I: xxxterm: hyphen-used-as-minus-sign usr/share/man/man1/xxxterm.1.gz:748
> E: xxxterm: menu-icon-not-in-xpm-format usr/share/pixmaps/xxxtermicon32.png
>
> So you may still want to patch your manpage accordingly.
>
> The last one I personally don't consider a show-stopper here as
> http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.7 reads
> "should".
>
> Thus, built, signed, uploaded.

That's great, thanks a lot.

I will keep working on the package, following your suggestions.

Cheers,
--
Luis Henriques


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r55y5jtr@gmail.com

Re: RFS: assaultcube-data (updated package)

[Michael Tautschnig]

Hi,

> Dear mentors,
> 
> I am looking for a sponsor for the new version 1.1.0.4+repacknot1-1
> of my package "assaultcube-data".
> 
> It builds these binary packages:
> assaultcube-data - data files for AssaultCube
> assaultcube-server-anticheat - AssaultCube server with closed source
> anti-cheat module
> 
> The changes are:
> * Update manpages
> - CC-BY-NC-SA (previous license was incorrect given content used)
> - Few formatting fixes
>   * Update debian/copyright
> - Note license of manpages
> - "Files:" headers pointing at directory instead of license file.
>   * Update debian/rules to dh7 format
>   * New package: assaultcube-server-anticheat, installs upstream
> server binaries
>   * Create a wrapper script for the server with "--help" for manpage
>   * Don't repack anymore.
> 
[...]

Thanks a lot for updating this package. Yet the new non-repacking leaves some
doubts to me:

- "Don't repack anymore." is a nice hint that something has changed, but yet it
  left me to find this out myself via the debdiff. 
- Using "repacknot1" as version appears to be a cruel hack. Ideally we'd have a
  new upstream version that could be packaged, but if that doesn't happen
  soonish, we'll have to live with that hack. (Introducing an epoch doesn't seem
  like a better solution either...)
- Why do server binaries belong to a "data" package? Isn't that just a hack to
  avoid a new source package?
- The original license appears to disallow re-packaging/splitting, hence there
  must be some exclusive exception provided to Debian. This is, however, not
  detailed in the copyright file.

Best regards,
Michael



pgp18JSNz1JWU.pgp
Description: PGP signature

Re: RFS: naev

[Simon McVittie]

On Sat, 09 Jul 2011 at 18:34:09 -0700, Vincent Cheng wrote:
> Thanks for the review. Please also consider reviewing my most
> up-to-date packaging in the Debian Games svn repository; my Naev
> packaging at mentors.d.n is heavily outdated at the moment, mostly
> because I'm getting tired of having to upload a 200 MB tarball every
> time I want to make a minor change to my packaging.

Have you considered splitting the package, along the same lines as OpenArena
and Nexuiz? Even if your upstream always releases the code and data together,
you're much more likely to need to fix bugs in the packaging or code than
you are in the data. If you keep the .menu files and other Debian additions
with the code, you'll only need to upload a relatively small .deb for fixes
to either the code, or the menu entries etc.

There are basically three ways you could go:

* Single monolithic source package, like Wesnoth. As you have noted, this is
  a pain to upload!

* One source package for code (and other small/easy-to-patch things like menu
  entries and man pages), one for data, like OpenArena in squeeze.
  naev Depends: naev-data with version constraints. This is quicker for
  you to upload, but if the -data package is too large, it won't get into
  debian-cd CD releases, only DVDs and BluRays (I think the cutoff for CDs
  is a couple of hundred MB).

* One source package for code, several for data, like OpenArena in
  sid/experimental. naev Depends: naev-textures, naev-music, naev-data
  (or whatever) with version constraints. When I asked the ftp-masters,
  Mark Hymer said they didn't object to this. Steve McIntyre (debian-cd
  maintainer) recommended aiming for about 50 to 100 MB when splitting
  data packages like this.

> As far as I understand, it's not an issue that blocks Naev from
> entering the archives (while binaries/executables need to be able to
> be built from source code, I don't think policy mandates that images
> must be built/rendered from source...if that's the case, an awful lot
> of packages currently in Debian would have to tweak their build
> system).

In my understanding of Policy and the DFSG, there's a difference between
data not being built from source code, and data not being accompanied by
source code at all.

Data not *being built from* source code is a technical bug: it means upstream
haven't given you a deterministic build system (and you haven't been able
to construct one). It's a bug, but not necessarily a fatal one.

(OpenArena has that bug too - upstream don't provide a build system for the
data, probably because it involves a lot of manual exporting; the derived
files are checked-in to svn alongside the source files.)

Data not *having* source code is a Policy/DFSG bug. In principle, for each
file in the binary package, the DFSG require you to include corresponding
source code in the source package, even if it isn't actually rebuilt.

For some (most?) game upstreams, it's difficult to tell what the corresponding
source code *is* (is image.jpg the preferred form for modification or is
there a .xcf version somewhere? we just don't know), but you should at least
include a best-effort guess at what the source is. (OpenArena also has this
problem; the source packages in sid/experimental contain my best guess at
what the source was.)

Where possible, the most reliable way to know that the "source" you're
providing is the actual source is to rebuild it, but I realise this isn't
always feasible, particularly for upstreams whose background is game modding
rather than Free Software.

S


-- 
To UNSUBSCRIBE, email to debian-devel-games-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110710075050.ga2...@reptile.pseudorandom.co.uk


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110710075050.ga2...@reptile.pseudorandom.co.uk

Re: RFS: mosquitto

[Michael Tautschnig]

Hi Roger,

[...]
> >> Lintian run as "lintian -iIE --pedantic" gives the following output:
> >>
> >> W: mosquitto source: debhelper-overrides-need-versioned-build-depends
> >> (>= 7.0.50~)
> > [...]
> >
> > Instead of copy-pasting this lintian warning, you should have addressed it 
> > :-/ -
> > could you please fix that and re-upload to mentors? I will then happily 
> > sponsor
> > your upload.
> 
> I'm sure I had an email from this list in the past with a very lucid
> reason why I shouldn't heed that warning, but I can't seem to find it
> now. I certainly can't remember the reasoning. I've made the change
> and re-uploaded. It is now lintian clean.
> 

Well, most likely this is the initial email of the "nitpicking..." thread.
Indeed that included a discussion about debhelper versions and compatibility
levels, but the main point was a different one: a sponsor's request to update to
debhelper version 8 from 7 or 7.0.50, which may induce undesired changes. In
your case, however, you are already using features (dh overrides) of 7.0.50, but
weren't declaring a proper build dependency. Does this help to clarify?

Package reviewed, built, and uploaded.

Thanks a lot for the work,
Michael



pgpsFG4YRyhgu.pgp
Description: PGP signature

Re: RFS: naev

[Paul Wise]

On Sun, Jul 10, 2011 at 9:50 AM, Simon McVittie wrote:

> In my understanding of Policy and the DFSG, there's a difference between
> data not being built from source code, and data not being accompanied by
> source code at all.
>
> Data not *being built from* source code is a technical bug: it means upstream
> haven't given you a deterministic build system (and you haven't been able
> to construct one). It's a bug, but not necessarily a fatal one.
>
> (OpenArena has that bug too - upstream don't provide a build system for the
> data, probably because it involves a lot of manual exporting; the derived
> files are checked-in to svn alongside the source files.)
>
> Data not *having* source code is a Policy/DFSG bug. In principle, for each
> file in the binary package, the DFSG require you to include corresponding
> source code in the source package, even if it isn't actually rebuilt.
>
> For some (most?) game upstreams, it's difficult to tell what the corresponding
> source code *is* (is image.jpg the preferred form for modification or is
> there a .xcf version somewhere? we just don't know), but you should at least
> include a best-effort guess at what the source is. (OpenArena also has this
> problem; the source packages in sid/experimental contain my best guess at
> what the source was.)
>
> Where possible, the most reliable way to know that the "source" you're
> providing is the actual source is to rebuild it, but I realise this isn't
> always feasible, particularly for upstreams whose background is game modding
> rather than Free Software.

In the case of naev, I was able to find the source code by
interrogating upstream on the #debian-games IRC channel. I found out
that the pre-built data is in the same VCS as the engine and the
source for the data exists, but is in two separate git repositories
(one shared with vegastrike/adonthell), is rarely rebuilt and
currently the 3D stuff cannot be rebuilt with current tools, since the
Blender Python API changed very incompatibility.

git://github.com/bobbens/naev.git
https://github.com/Deiz/naev-artwork.git
http://pingus.seul.org/~grumbel/vegastrike.git/

Personally I would not be willing to upload naev in its current state.

Ideally there would be multiple source packages that build their
respective data/code properly into corresponding binary packages,
perhaps like this:

naev
naev-engine
naev-tools
naev-gfx
naev-ships
naev-asteroids
naev-people

Fedora on the other hand are fine with this situation:

http://cedarandthistle.wordpress.com/2011/07/09/naev-is-now-in-fedora/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6E-7vXAkdjR=zmqvuio4u76orswst3vcvvbq+40n1x...@mail.gmail.com

Re: RFS: cmsmadesimple

[Michael Tautschnig]

Hi again,

[...]
> > One suggestion for the package install procedure, though: why do you first
> > install all the files and afterwards remove them again via an override in
> > debian/rules? Wouldn't it be much cleaner to only install the desired files?
> > 
> 
> I preferred this method for a couple of reasons, firstly because I think the
> code for installing all of the folders separately would be much bigger and 
> also
> because this makes the packaging a bit less error prone. If I do all of the
> install in the .install file, I would have to have a lot of lines (because I
> have to omit the translation files and the shared libs) and if upstream adds 
> any
> files or folders, these might not get included without changing the install 
> file.
> 
[...]

I do agree that this incurs some risk. With the use of wildcards, however, I'm
not quite sure whether the .install file will really be more complicated: you're
now spending > 60 lines in your debian/rules file on removing files (including
comments, though).

My concern is a security-related one: yes, your package might break if you fail
to install a newly-added file. But it will be completely broken. On the other
hand, if you fail to remove a newly-added file that unfortunately contains some
security problem which would have been already addressed in the system version
of that file, this problem will go undetected until exploited.

Thanks again for your work,
Michael



pgpFc5MymMjlB.pgp
Description: PGP signature

Re: RFS: qasmixer

[Sebastian H.]

>> Got it and found the package in the NEW queue.
>> http://ftp-master.debian.org/new.html
>>
>> It shows "source" and "i386" which is fine for (my) netbook(s).
>> I wonder though, will there be an amd64 package at some point?
> 
> Packages get build for all architectures after they reach the archive,
> ie. after NEW.  You can see the build status and logs at [1] (also
> linked from the PTS [2]).
> 
> Regards,
> Ansgar
> 
> [1] 
> [2] 

Thank you for the info.
That's nice, the build log shows where the armel build fails.
I'll try to fix that for the next release.

Regards,
Sebastian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e197e64.7090...@gmx.de

Re: RFS: mosquitto

[Roger Light]

Hi Michael,

> Thanks a lot for updating your package. I've reviewed your changes and it 
> looks
> mostly fine, except for one issue:
>
>>
>> Lintian run as "lintian -iIE --pedantic" gives the following output:
>>
>> W: mosquitto source: debhelper-overrides-need-versioned-build-depends
>> (>= 7.0.50~)
> [...]
>
> Instead of copy-pasting this lintian warning, you should have addressed it 
> :-/ -
> could you please fix that and re-upload to mentors? I will then happily 
> sponsor
> your upload.

I'm sure I had an email from this list in the past with a very lucid
reason why I shouldn't heed that warning, but I can't seem to find it
now. I certainly can't remember the reasoning. I've made the change
and re-uploaded. It is now lintian clean.

Thanks,

Roger


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAH7zdyd+DhXmYKZtQ4eZjNWj3joWJQmk4WmL=ETKrBt=sne...@mail.gmail.com

Re: RFS: cmsmadesimple

[Cristian Henzel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Michael,

On 07/10/11 05:03, Michael Tautschnig wrote:
> Hi,
> 
> Sorry for taking so long for anyone to respond. Indeed this is a very nice
> example of making proper use of existing Debian packages, despite upstream
> shipping all the duplicate code. The only remaining point is
> modules/Printing/tcpdf/fonts/: it wouldn't occur to me as a surprise to find
> this freefont code to be part of some of the *-freefont packages!?
> 

indeed I didn't think about the fonts, I will look into it for the next version
though.

> One suggestion for the package install procedure, though: why do you first
> install all the files and afterwards remove them again via an override in
> debian/rules? Wouldn't it be much cleaner to only install the desired files?
> 

I preferred this method for a couple of reasons, firstly because I think the
code for installing all of the folders separately would be much bigger and also
because this makes the packaging a bit less error prone. If I do all of the
install in the .install file, I would have to have a lot of lines (because I
have to omit the translation files and the shared libs) and if upstream adds any
files or folders, these might not get included without changing the install 
file.

> Anyhow, built, signed, and uploaded. But as a new upstream version is already
> available, there is a chance for you to update the packaging as well :-)
> 

Thank you very much! I will update the package ASAP.

> Thanks a lot for your work,
> Michael
> 


- -- 

Best regards,
Mit freundlichen Grüßen,

Cristian Henzel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOGXS6AAoJENnza/EQjIwPOXwP/A5DEHeaQ2pFYknaOMq8EYi3
fjLNl3TOKV5ZfOlHnNfnj2jvt8cbWrQH0UK7mWB5u/G029yGWDwQpQmgR0ZQD/3f
NW3MIP2px3T73o9LXQYyUAXExD/EakCEew5+emmT80ONvP13wEXU+RyzIzL/9gZ+
2zFOC7m0EFzxv9QswqiSOV8GWjUCgj/mSJJVG0Rs7W9vAZWRzoY/thvxh68f8MhC
HxH6h9yxl+cDoq5pZSS9iDsDXReM21l5BrxTDj0Npprxmk+f94PayiISKMDUCbbm
4O4yEqgBc/tfjKidySbGApv53ZZdfY6MbHtKQDOo6hZrM39LiXnF5EkwxpUoNuxw
cVs+f8MeqsiRyk93lZKr06zn7CzmVIk3W/Sr4m8njBowm+9aeUIoedi2TfoFoRuQ
Ngot91OOt4SEe2wU4bzaKGp3opTgM6pJFTRCmyJ+jFwTHSgTf6d62NChCkCugM1s
MszpKYPrENKUzpN4LNeL3IgknxEoeBjy24LQmYnaGtZenmmV0WAkE+mqkb2t483B
7JQt5kVIWQdQ1k7NGhkRrSrpUw3iNgCx50/Qx+/SEtSCoYmW4A4R6FnDTuWjambB
FceqQIjnc21b4hIdnocYnfFUU+9uwXkuP5qK6teuCtXEEND2qRLdNt7OWhEz8rGU
0CzpqRjyPmMIXgeZYSit
=NvKX
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1974eb.8050...@rspwn.com

Re: dfsg tarball and non-dfsg version number

[Kilian Krause]

Hi Anton,

On Sun, Jul 10, 2011 at 02:52:48AM +0400, Anton Martchukov wrote:
> On Sat, Jul 09, 2011 at 02:57:20PM -0700, Hamish wrote:
> > +dfsg into version name:
> > as our build will be bit-for-bit identical to one built from a non-
> > stripped version of the source (the only difference between the
> > source tarballs being unused mac/windows dirs), I don't see a
> > point in adding the +dfsg to the binary package version, it
> > clutters for no reason. (if pbuilder method has issues, then fix
> > pbuilder...)
> 
> Does anybody have a clue if it will build by autobuilder fine?

The autobuilders will find and use it just fine.

> When debian changelog lists version 2.4.708 and corresponding
> tarball is opencpn_2.4.708+dfsg.orig.tar.gz since some
> non-dfsg binaries has been stripped off.
> 
> E.g. pbuilder fails to find the tarball unless version in
> changelog is changed to 2.4.708+dfsg.

That's due to the naming convention. See
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
for in-depth discussion. You may use ~dfsg, +dfsg, -dfsg just fine inside
upstream_version. Just be aware that ~dfsg is the only form that will allow
upstream's original version to increase to any value and still allow a
smooth upgrade as the ~ is always smaller than any other ascii char by
design.

That being said, of course if your Debian version is 2.4.708+dfsg-1 then
this reads:
* epoch: ""
* upstream_version: 2.4.708+dfsg
* debian_revision: 1

Therefor your orig tarball needs the +dfsg too (this is not part of the
debian revision).

In case you need this as regexp:
(\d+:)?(.*)(-[\d\.]+(\+b\d+)?)?
might work. (Untested though but should do for regular and Debian native
versions)

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature