FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 07-26-2012, 08:29 PM
Benjamin Drung
 
Default Request for review

Am Donnerstag, den 26.07.2012, 09:06 -0500 schrieb Robert Park:
> Quite the thorough review, thank you!

You're welcome.

> >> Of course, it
> >> looks like debian is in freeze, so I guess I'm supposed to pursue
> >> acceptance in universe before I'll be able to get it into debian
> >> unstable. Is that right? I filed a needs-packaging bug in launchpad.
> >
> > The Debian freeze prevents packages to move from unstable to testing,
> > but it does not prevent new packages into unstable. It's recommended to
> > get the package in Debian first and then use requestsync (or syncpackage
> > if you have upload rights) to get it synced into Ubuntu.
>
> Yes in theory, however I've been following a few other people's
> request for sponsorship in debian-mentors and it seems nearly
> impossible to get sponsorship during the freeze, because nobody cares
> about new packages and everybody is busy testing the frozen 'testing'
> distro.

Getting sponsors is sometimes complicated due to missing man power, but
I doubt that this is connected to the freeze.

> > I had a quick look at your package on mentors:
> >
> > 1) The changelog should only contain entries for version that are
> > actually in the archive. In your case, only one changelog entry would
> > remain.
>
> But the program has been packaged on a launchpad PPA up until this
> point, so theoretically there are users in the wild with old versions
> of this package. It's not like this is the first ever version of the
> package and I just arbitrarily felt like creating a retroactive
> changelog for nonexistent packages. Am I seriously supposed to
> truncate the changelog just because I'm seeking the package's
> inclusion in debian?

It's my opinion, that debian/changelog should only contain entries for
uploads to Debian. IMO every new upload to Debian should add only one
new block in the changelog file. Having entries like "gottengeography
(1.1-2) unstable; urgency=low" are misleading, because they were never
uploaded to unstable. It should at least detectable, what versions were
uploaded to Debian and which were uploaded somewhere else.

> > 8) Do you really need patches for your Debian package?
>
> Why not? The patches are mostly to do with distutils, specifically in
> the sense that the 'upstream' tarball is configured to be able to run
> uninstalled, but the debian package drops some of that code because it
> was interfering with the building of the package.

Not every change there looks like a needed packaging change. Example:

--- gottengeography-2.1.orig/gg/version.py
+++ gottengeography-2.1/gg/version.py
@@ -8,7 +8,7 @@

APPNAME='GottenGeography'
PACKAGE='gottengeography'
-VERSION='2.0'
+VERSION='2.1'

AUTHOR='Robert Park'
EMAIL='rbpark@exolucere.ca'

--
Benjamin Drung
Debian & Ubuntu Developer
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-26-2012, 08:41 PM
Robert Park
 
Default Request for review

On Thu, Jul 26, 2012 at 3:29 PM, Benjamin Drung <bdrung@ubuntu.com> wrote:
>> Yes in theory, however I've been following a few other people's
>> request for sponsorship in debian-mentors and it seems nearly
>> impossible to get sponsorship during the freeze, because nobody cares
>> about new packages and everybody is busy testing the frozen 'testing'
>> distro.
>
> Getting sponsors is sometimes complicated due to missing man power, but
> I doubt that this is connected to the freeze.

Alright, well I'll give it a shot soon, once I have the package a bit
more cleaned up.

> It's my opinion, that debian/changelog should only contain entries for
> uploads to Debian. IMO every new upload to Debian should add only one
> new block in the changelog file. Having entries like "gottengeography
> (1.1-2) unstable; urgency=low" are misleading, because they were never
> uploaded to unstable. It should at least detectable, what versions were
> uploaded to Debian and which were uploaded somewhere else.

I see where you're going with this. I guess I will truncate it then.
Originally I was concerned about "losing" so much "information", but
really the git changelog on github is always going to be there, so a
truncated changelog file isn't a big deal at all then.

> Not every change there looks like a needed packaging change. Example:
>
> --- gottengeography-2.1.orig/gg/version.py
> +++ gottengeography-2.1/gg/version.py
> @@ -8,7 +8,7 @@
>
> APPNAME='GottenGeography'
> PACKAGE='gottengeography'
> -VERSION='2.0'
> +VERSION='2.1'

Well, this is quite embarrassing ;-)

You see, I shipped the 2.1 upstream tarball with the version defined
as 2.0 (ie, I forgot to update the version string before releasing the
tarball). I know it's frowned upon to change a release after it's in
the wild, and I didn't think it would be unacceptable to simply
correct this in the debian package, so that's why that patch is there.

I'm currently working on unifying as much as possible the 'master' and
'debian' branches, in the hopes that indeed there can be no patches
and you can just drop the 'debian/' folder into the upstream tarball
and build a package.

Thanks again!

--
http://gottengeography.ca

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-26-2012, 08:42 PM
Scott Kitterman
 
Default Request for review

On Thursday, July 26, 2012 10:29:02 PM Benjamin Drung wrote:
> > > 1) The changelog should only contain entries for version that are
> > > actually in the archive. In your case, only one changelog entry would
> > > remain.
> >
> >
> >
> > But the program has been packaged on a launchpad PPA up until this
> > point, so theoretically there are users in the wild with old versions
> > of this package. It's not like this is the first ever version of the
> > package and I just arbitrarily felt like creating a retroactive
> > changelog for nonexistent packages. Am I seriously supposed to
> > truncate the changelog just because I'm seeking the package's
> > inclusion in debian?
>
> It's my opinion, that debian/changelog should only contain entries for
> uploads to Debian. IMO every new upload to Debian should add only one
> new block in the changelog file. Having entries like "gottengeography
> (1.1-2) unstable; urgency=low" are misleading, because they were never
> uploaded to unstable. It should at least detectable, what versions were
> uploaded to Debian and which were uploaded somewhere else.

I have seen it done both ways, but this too is my preference. It's not like
there's something wrong with the older changes, but it's simply not relevant
to Debian. I have, in the past, made the historical changelog something like
debian/changelog.old, made a new one and then shipped the old one in
/usr/share/doc/$PACKAGE.

There isn't hard policy on this. One of the difficulties of needing to be
sponsored is that to some degree you've got to conform to the sponsor's view
on things. For me that was part of the motivation to become a DD and an
ubuntu-dev.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-27-2012, 12:11 AM
Robert Park
 
Default Request for review

On Thu, Jul 26, 2012 at 3:41 PM, Robert Park <robru@gottengeography.ca> wrote:
> I'm currently working on unifying as much as possible the 'master' and
> 'debian' branches, in the hopes that indeed there can be no patches
> and you can just drop the 'debian/' folder into the upstream tarball
> and build a package.

Ok, so I mostly have succeeded in this unification, but there is one
point where I'm not sure if the solution I've come up with is the best
one or not.

In my setup.py, it's necessary to do some things slightly differently
depending on whether a .deb is being built, or if the program is being
installed directly to the system (by a user). For example, if a user
downloads git master and runs 'sudo ./setup.py install', it is
necessary for the setup.py script to call 'glib-compile-schemas' at
the end, otherwise the program will crash on launch. But calling
glib-compile-schemas isn't necessary to build a .deb, since debian is
smart enough to call glib-compile-schemas on it's own after the .deb
has been installed.

Previously, my solution was to just unconditionally run
glib-compile-schemas from within setup.py in the git master branch,
and then maintained a separate 'debian' branch that cut that part out
of the setup.py. Now what I've done is written a test into the
setup.py so that it only runs glib-compile-schemas if setup.py is
being called by a user, not by debhelper.

My question is, what would be the best way to test, from within
setup.py, whether or not setup.py is being called by a user or by
debhelper? The test that I came up with was to see whether or not the
commandline option '--root' was specified, assuming that if --root is
present, then we must have been called by debhelper and thus calling
glib-compile-schemas is pointless, but if --root wasn't specified,
then we're installing to the system and glib-compile-schemas will be
necessary for the program to run.

This is what I'm talking about if you're curious:

https://github.com/robru/gottengeography/commit/2b7573b23722440a645ee6600fcfe14d0fa2ea51

It seems like a reasonable test to me, but I'm just wondering if maybe
there's a better or more common approach to this problem.

Thanks again!

--
http://gottengeography.ca

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 04:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org