wmtime 1.0b2-14 2012-11-23 22:50

[Bart Martens]

On Fri, Nov 23, 2012 at 10:56:20PM +, Doug Torrance wrote:
> bartm wrote on 23 Nov 2012 17:54 :
> > The file wmtime_1.0b2.orig.tar.gz at mentors is not identical to the one in
> > Debian.  What is debian/0001-Packaging-for-Debian.patch for ? The changelog
> > entry of 1.0b2-13 "Rebuilding source package correctly" is not useful if you
> > didn't change the source package.  The homepage in the "Homepage" field is 
> > not
> > useful since it states that http://packages.qa.debian.org/w/wmtime.html is 
> > the
> > (home) website, and the version available for download is older than the 
> > newest
> > already in Debian.  I suggest to not use this website in the "Homepage" 
> > field,
> > and also not in debian/watch.  Using 7 in debian/compat is quite low 
> > nowadays.
> > Some changes are not mentioned in debian/changelog, for example replacing
> > dh_clean by dh_prep.  Isn't it better to use a higher debian/compat number 
> > so
> > that debian/rules can be simplified instead ? I suggest to add the fixes for
> > bugs 639626 and 661843 in debian/patches.
> 
> Thank you so much for your input.  This is my first attempt at maintaining a
> Debian package, so I truly appreciate it!

I guessed already that you are a beginner.  Your positive attitude makes it a
pleasure to give review comments.  Feel free to ask questions on
debian-mentors@lists.debian.org about Debian packaging.

> 
> I believe that I have made of all the changes that you outlined.

Not yet all of them, but you're making progress.

> I've
> uploaded a new source package (wmtime-1.0b2-14) to mentors.debian.net if you
> would be interested in taking a look.

I suggest to merge the changelog entries from 1.0b2-11 to 1.0b2-14, although it
is not really an error to use multiple entries.  The entry "Rebuilt source
package" is still in the changelog, and this makes no sense because there were
no changes to the source package involved.  I see that debian/compat still has
7 while debian/patches/upstream_changes mentions 9.  If you can recognize
separate changes from the past, then separate patches is slightly better than
one upstream_changes patch, although I understand you may not want to do that
effort.  The Homepage http://wmaker.friedcheese.org/ is by "the Debian
maintainer for the wmtime package" so that's probably Paul Harris who is no
longer maintaining the Debian package, so I suggest to not use this website in
Homepage and debian/watch either.  If wmtime no longer has any upstream
maintainer, then you will in fact become the upstream maintainer.  Then you are
free to make a new upstream homepage, or to simply not use the field "Homepage"
in debian/control and not use a debian/watch file.  The file
debian/patches/series only mentions upstream_changes so the other patches are
not used, meaning that the bugs are probably not really fixed.  Did you test
the resulting binary package ?

Regards,

Bart Martens


-- 
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/20121124073459.gd9...@master.debian.org

Processed: retitle to RFS: wmtime/1.0b2-14 [ITA]

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 693495 RFS: wmtime/1.0b2-14 [ITA]
Bug #693495 [sponsorship-requests] RFS: wmtime/1.0b2-13 [ITA]
Changed Bug title to 'RFS: wmtime/1.0b2-14 [ITA]' from 'RFS: wmtime/1.0b2-13 
[ITA]'
> stop
Stopping processing here.

Please contact me if you need assistance.
-- 
693495: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693495
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.c.135373084616840.transcr...@bugs.debian.org

Re: Some easy-looking rc bugs

[Michael Gilbert]

On Fri, Nov 23, 2012 at 7:28 PM, Michael Gilbert wrote:
> On Sat, Nov 17, 2012 at 10:07 PM, Michael Gilbert wrote:
>> The following look like they'll be pretty easy, so they're a prime
>> opportunity for mentees to build, test, and prepare a package to be
>> potentially sponsored:
>
> So, it's been almost a week, and I decided to take a look at where
> things stand with these easy bugs.  Here is what happened:
>
> 687848 - No progress
> 688712 - Fixed by Vincent Cheng (DM)
> 688891 - Fixed by gregor hermann (DD)
> 690148 - Question about bug status added by Stefan Baur (DC), but no progress
> 691929 - Fixed by Tobias Frost (DC) and uploaded to delayed/10
> 691271 - Fixed by Tobias Frost (DC) and uploaded to delayed/5
> 692555 - Patch proposed by gregor hermann (DD), Tobias Frost (DC)
> wanted to do an nmu, but the maintainer asked him to wait
> 693208 - No progress
> 693371 - Fixed by Kel Modderman (DC), an uploader on the package
> 693460 - Triaging and new bug opened by Margarita Manterola (DD)
>
> So, 7/10 bugs fixed!

Correction: of course if I could actually count, that's 5/10 and 1
likely to be fixed quite soon.  Even so, I do see those as good
numbers.

Best wishes,
Mike


-- 
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/CANTw=MP4_HQGvM+FzKKkuUtfqizKLZuXP5YVA=nsbbnessg...@mail.gmail.com

Re: Some easy-looking rc bugs

[Michael Gilbert]

On Sat, Nov 17, 2012 at 10:07 PM, Michael Gilbert wrote:
> The following look like they'll be pretty easy, so they're a prime
> opportunity for mentees to build, test, and prepare a package to be
> potentially sponsored:

So, it's been almost a week, and I decided to take a look at where
things stand with these easy bugs.  Here is what happened:

687848 - No progress
688712 - Fixed by Vincent Cheng (DM)
688891 - Fixed by gregor hermann (DD)
690148 - Question about bug status added by Stefan Baur (DC), but no progress
691929 - Fixed by Tobias Frost (DC) and uploaded to delayed/10
691271 - Fixed by Tobias Frost (DC) and uploaded to delayed/5
692555 - Patch proposed by gregor hermann (DD), Tobias Frost (DC)
wanted to do an nmu, but the maintainer asked him to wait
693208 - No progress
693371 - Fixed by Kel Modderman (DC), an uploader on the package
693460 - Triaging and new bug opened by Margarita Manterola (DD)

So, 7/10 bugs fixed!  That's a really encouraging stat.  So, please
thank everybody involved in getting those resolved.  I think I'll keep
doing this about every week, since the results are fairly interesting.

Note that I've coined a term above, DC = Debian Contributor = someone
doing Debian bug triage, creating patches, or other tasks who has yet
to be seen on nm.debian.org.

Best wishes,
Mike


-- 
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/CANTw=mm82x_8dbtpazycpn2xsin6vo2g-tnvsd7by9wcawb...@mail.gmail.com

Re: Closing a bug report twice (different versions) ?

[Don Armstrong]

On Fri, 23 Nov 2012, Joachim Wiedorn wrote:
> Can this bug report be closed especially for version 1.24-3.1 by
> writing the bug report number in the changelog a second time ->
> automatic "done"?

Yes. Multiple -done mails with version pseudoheaders are handled
properly by the BTS.
 
> Or is the only way to solve it by a mail to cont...@bugs.debian.org
> with:
> 
> fixed  
> thanks

No, but you can also do this.


Don Armstrong

-- 
[T]he question of whether Machines Can Think, [...] is about as
relevant as the question of whether Submarines Can Swim.
 -- Edsger W. Dijkstra "The threats to computing science"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121123230848.gc19...@teltox.donarmstrong.com

Closing a bug report twice (different versions) ?

[Joachim Wiedorn]

Hello!

What is the right way, if a bugreport were closed with the newest sid
version because this bug were fixed in this sid version, but the same bug
is not fixed in freezed testing/wheezy version?

Example:

Found in version 
Fixed in version 
Done: ...

Can this bug report be closed especially for version 1.24-3.1 by writing
the bug report number in the changelog a second time -> automatic "done"?

Or is the only way to solve it by a mail to cont...@bugs.debian.org with:

fixed  
thanks

---
Have a nice day.

Joachim (Germany)


-- 
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/20121123224654.5b4a4...@jupiter.home

Bug#692923: Bug#689012: Status of chrony

[Joachim Wiedorn]

Hello Enrico,

Enrico Zini wrote on 2012-11-23 22:23:

> So please do not consider the ball to be in the release team's court:
> for this to be fixed, the relevant changes need to be backported to
> 1.24.

I am on the way to upload a new chrony version 1.24-3.1+deb7u1
as David Prévot wrote on 2012-11-10 17:40. Before this I must
solve the right way for "handling" the related bug reports.
I will do all at this weekend.

---
Have a nice day.

Joachim (Germany)


--
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/20121123225344.5f948...@jupiter.home

Bug#692923: Bug#689012: Status of chrony

[Enrico Zini]

On Fri, Nov 16, 2012 at 07:49:46AM -0600, John Hasler wrote:

> None of these bugs (or any bugs above "normal") apply to the version of
> Chrony in Sid.  They could all by fixed by migrating that version (the
> current upstream release) to Wheezy but as it is frozen that is not
> possible unless the release team decides to make an exception.  That is
> entirely up to them.

I did a debdiff of the changes from 1.24 to 1.26, limited to .c, .h and
config files, and it is vast:

 89 files changed, 4332 insertions(+), 2655 deletions(-)

Please check http://release.debian.org/wheezy/freeze_policy.html
Rule #5. If the version in unstable already includes significant changes
  not related to the bug to be fixed, contact the release team about
  uploading to testing-proposed-updates. Changed dependencies, new
  upstream versions, changed library names and completely rewriting the
  packaging are "significant changes". So are lots of other things.

When it says "uploading to testing-proposed-updates", it implies
uploading a version of 1.24 with only the changes needed to fix the RC
bugs. t-p-u is needed because a hypotetical 1.24+squeeze1 cannot go in
through sid, since sid has a higher version.

So please do not consider the ball to be in the release team's court:
for this to be fixed, the relevant changes need to be backported to
1.24.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Re: jquery.js from Doxygen in documentation, what to do about it

[Russ Allbery]

Thomas Goirand  writes:
> On 11/24/2012 01:54 AM, Gert Wollny wrote:

>> Now I've seen that Doxgen has the jquery-1.3.2.js file in the debian/
>> directory and in fact with this script the pages display correctly. My
>> question is now, should I also include this source file in the source
>> distribution, or would it suffice to document that the source code to
>> the copressed files can be found with the according doxygen version?

> In Debian, you should always be able to build from source.  So if you
> could use the original source code, and delete the binary file (eg: the
> minimized jscript) that would be the best option.

Sadly, that's not really helpful advice for Gert, since his package just
has Doxygen-generated documentation.  The jquery code is coming from
Doxygen.  So from his perspective, he *is* building from source, but
Doxygen, when building the documentation from comments, is including a
Javascript library that Lintian is complaining about.

> P.S: The above isn't an approval for embedding yet another version of
> jquery in your package, I think it should be avoided as well if
> possible. Probably one of the options is to patch upstream source code
> so that it can work with the target Debian package and still render
> well. I have no idea how practical that would be though.

This would be something that would need to be done in the doxygen package,
not in Gert's package.

For right now, I think the best thing for the Doxygen *clients* to do is
just ignore this issue.  It may need a bug against doxygen, though (and
possibly some help for the Doxygen maintainer).

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87d2z4hywu@windlord.stanford.edu

Re: jquery.js from Doxygen in documentation, what to do about it

[Thomas Goirand]

On 11/24/2012 01:54 AM, Gert Wollny wrote:
> Now I've seen that Doxgen has the jquery-1.3.2.js file in the debian/
> directory and in fact with this script the pages display correctly. My
> question is now, should I also include this source file in the source
> distribution, or would it suffice to document that the source code to
> the copressed files can be found with the according doxygen version?
>
> Many thanks,
> Gert
In Debian, you should always be able to build from source.
So if you could use the original source code, and delete the
binary file (eg: the minimized jscript) that would be the best
option.

There's few compressor available in Debian, like yui-compressor,
and the ones from nodejs (but these are only in SID).

Cheers,

Thomas

P.S: The above isn't an approval for embedding yet another
version of jquery in your package, I think it should be avoided
as well if possible. Probably one of the options is to patch
upstream source code so that it can work with the target
Debian package and still render well. I have no idea how
practical that would be though.


-- 
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/50afd45b.5030...@debian.org

Bug#693495: RFS: wmtime/1.0b2-13 2012-11-20 13:32

[Bart Martens]

Hi Doug,

The file wmtime_1.0b2.orig.tar.gz at mentors is not identical to the one in
Debian.  What is debian/0001-Packaging-for-Debian.patch for ? The changelog
entry of 1.0b2-13 "Rebuilding source package correctly" is not useful if you
didn't change the source package.  The homepage in the "Homepage" field is not
useful since it states that http://packages.qa.debian.org/w/wmtime.html is the
(home) website, and the version available for download is older than the newest
already in Debian.  I suggest to not use this website in the "Homepage" field,
and also not in debian/watch.  Using 7 in debian/compat is quite low nowadays.
Some changes are not mentioned in debian/changelog, for example replacing
dh_clean by dh_prep.  Isn't it better to use a higher debian/compat number so
that debian/rules can be simplified instead ? I suggest to add the fixes for
bugs 639626 and 661843 in debian/patches.

Regards,

Bart Martens


-- 
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/20121123175450.gb32...@master.debian.org

jquery.js from Doxygen in documentation, what to do about it

[Gert Wollny]

Dear all,

I'm currently staring with packaging some software (initially intended 
for debian-med) and amongst these packages is a software library with 
its Doxygen created documentation.


Doxygen created a jquery.js script that depends somehow on the options 
used to run the document creation by combining some files that are based 
on the original GPLed jquery library.


I tried my first packaging steps in Ubuntu 12.04 there I ran into the 
following problem:


The first packaging (obviously) resulted in the 
embedded-javascript-library lintian error. After searching the web for 
solutions I found that I should use the packaged version of jquery.js. 
Unfortunately this didn't render the page correctly, probably because 
the installed version of Doxygen 1.7.6.1 creates a jquery 1.3.2 based 
script, and the version packaged with libjs-jquery is 1.7.1.


It seems that Doxygen version 1.8.2 now uses jquery 1.7.1, but that 
version is only in experimental, jquery is at 1.7.2 in sid, and jquery 
upstream is already at 1.8.3. Which makes it somewhat likely that 
whichever version of the two package other Debian based distributions 
might grab, there is a good chance that the jquery's do not coincide.


Which means, the best option from a users perspective seems to be to 
keep the jquery script created by Doxygen and override the lintian 
warning. However, Andreas Tille told me on debian-med that this is 
considered as binary without source code, which would trigger a RC bug.


Now I've seen that Doxgen has the jquery-1.3.2.js file in the debian/ 
directory and in fact with this script the pages display correctly. My 
question is now, should I also include this source file in the source 
distribution, or would it suffice to document that the source code to 
the copressed files can be found with the according doxygen version?


Many thanks,
Gert


--
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/50afb85f.6030...@gmail.com

Bug#694072: RFS: filebot/3.1

[Reinhard Pointner]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my application "filebot"

  Package name: filebot
  Version : 3.1
  Upstream Author : Reinhard Pointner 
  URL :  
http://filebot.sourceforge.net
  License : GPLv2
  Section : misc

To access further information about this application, please visit the 
following URL:
http://filebot.sourceforge.net/

I've got pre-built debs here and all the source is on sourceforge as well:

https://sourceforge.net/projects/filebot/files/filebot/FileBot_3.1/filebot_3.1_i386.deb

https://sourceforge.net/projects/filebot/files/filebot/FileBot_3.1/filebot_3.1_amd64.deb


Regards,
Reinhard Pointner

Re: RFS: MiceAmaze video game

[Raphael Champeimont]

Thank you for all your comments.
I will come back later with a new upstream release, especially for the
font rendering which requires big changes. That was probably something
to be done anyway, since I guess it would improve the font rendering
quality which I was not too happy about.
For the rest I will make the necessary changes.

bye,
Raphael

2012/11/23 Paul Wise :
> You might be interested in joining the Debian games team:
>
> http://wiki.debian.org/Games/Team
>
> Here is a review of your package:
>
> You are missing a watch file:
>
> http://wiki.debian.org/debian/watch
>
> You don't include any FreeDesktop menu or Debian menu files, so
> non-technical users will probably not be able to start your game on
> Debian.
>
> I would suggest to update debian/compat to 9 and change the debhelper
> build-dep to 9
>
> Your Makefile does not support DESTDIR.
>
> Your Makefile includes this very inappropriate line:
>
> CC=g++
>
> I would suggest dropping the whole release/debug thing, this will
> allow you to use the more standard CXXFLAGS instead of
> CXXFLAGS_RELEASE/CXXFLAGS_DEBUG/CXXFLAGS_COMMON. Alternatively you
> could just switch to a standard build system like autotools or cmake.
>
> I would strongly suggest that the text be rendered at runtime or at
> the very least the PNG files created from the DejaVu font should
> rendered at build time from ttf-dejavu. Rendering the text at runtime
> will allow you to add translations, making the game accessible to more
> users. I would recommend quesoglc for this. I would recommend these
> files be rendered at runtime or build time:
>
> data/images/chars/*
> data/images/license.png
> data/images/title.png
> data/images/first.png
>
> I would suggest that these files be created from mouse.png at build
> time using imagemagick or similar: icon.ico icon32.bmp
>
> The eagle.png image looks like it was cut out of some off-the-shelf
> clipart. Are you the copyright holder for that? Where did the image
> come from? Is there an SVG/WMF that it was rendered from (best render
> at build time)?
>
> You are embedding a copy of SOIL. Please remove that from the upstream
> tarball and build-depend on libsoil-dev instead. That would also get
> rid of one gcc warning, one lintian warning and two cppcheck warnings.
>
> Your debian/changelog includes UNRELEASED in the suite, shouldn't that
> be "unstable"?
>
> All of the files in src/ have "All rights reserved." in them but no
> license statement:
>
> http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/
>
> Your configuration file loading should use getpwuid() or similar if
> getenv('HOME') fails.
>
> src/Functions.* are not valid UTF-8.
>
> You might want to use the new format for debian/copyright:
>
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>
> Since you are upstream for a game, please read these documents:
>
> http://wiki.debian.org/UpstreamGuide
> http://www.freedesktop.org/wiki/Games/Upstream
>
> Automatic checks from here:
>
> http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
>
> gcc:
>
> gcc -O2 -s -Wall -o obj/stb_image_aug.o -c ../../src/stb_image_aug.c
> ../../src/stb_image_aug.c: In function 'parse_png_file':
> ../../src/stb_image_aug.c:2341:28: warning: variable 'invalid_chunk'
> set but not used [-Wunused-but-set-variable]
>
> lintian:
>
> P: miceamaze source: source-contains-prebuilt-windows-binary SOIL/testSOIL.exe
> I: miceamaze source: debian-watch-file-is-missing
> P: miceamaze: no-upstream-changelog
>
> cppcheck:
>
> [SOIL/src/original/stb_image-1.16.c:2924]: (error) Memory leak: out
> [SOIL/src/stb_image_aug.c:2651]: (error) Memory leak: out
>
> isutf8:
>
> src/Functions.h: line 63, char 1, byte offset 11: invalid UTF-8 code
> src/Functions.cpp: line 84, char 1, byte offset 20: invalid UTF-8 code
>
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
> http://bonedaddy.net/pabs3/


-- 
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/CA+_0haKPXFcbaTa76pWt_s+oZBSNEex2MPeL44HiBxGh=rf...@mail.gmail.com