Re: debian/watch file and berlios
Thank you Lutz!
Just checked -- it worked!
On Thu, 22 Mar 2007, Lutz Henckel wrote:
Hi Yarik,
is should work again. A wrong configuration has forbidded
access of User Agents beginning with D.
Ciao
Lutz
Yaroslav Halchenko schrieb:
Dear Lutz,
I am a Debian developer who packages a FOSS software hosted at
berlios.de. As a part of packaging, we use a convenience tool named
uscan which checks the upstream page for available new versions.
Since some time ago, berlios's website is not allowing the tool to use
its native Agent string (Debian uscan 2.9.27) and forbids the access.
Is there a chance to adjust web server configuration to allow uscan to
access the pages? If it is not of your responsibility, could you
please forward this request to appropriate person?
For the reference and examples of invocation please see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397354
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409137
Thank you in advance for your help
Cheers
Yarik
On Mon, 19 Mar 2007, Yaroslav Halchenko wrote:
I am sorry if I am trying to wake up a dead issue, but
On Thu, 23 Nov 2006, Julian Gilbey wrote:
On Wed, Nov 22, 2006 at 11:17:29AM -0500, Justin Pryzby wrote:
I think there are 2 problems:
- Berlios apparently rejects based on User-Agent.
Fixed in 2.9.24, I believe.
Indeed there is a changelog entry:
* uscan: set HTTP user agent name (Closes: #397354)
and current 2.9.27 version of uscan has:
$user_agent-agent('Debian uscan 2.9.27');
and my uscan fails with:
,---
| -- In debian/watch, processing watchfile line:
|opts=downloadurlmangle=s/prdownload/download/
http://developer.berlios.de/project/showfiles.php?group_id=7729
http://prdownload.berlios.de/keyjnotegui/keyjnotegui-(.*).tar.bz2
| uscan warning: In watchfile debian/watch, reading webpage
| http://developer.berlios.de/project/showfiles.php?group_id=7729 failed:
403 Forbidden
`---
so imho issue persists since berlios seems to don't allow uscan as the
agent effectively bringing #397354 back alive:
,---
| *$ lynx -dump
'http://developer.berlios.de/project/showfiles.php?group_id=7729' | head -3
| [1]BerliOS :[2]DevCounter [3]WebCalendar [4]Developer
| [5]SourceAgency [6]SourceLines[7]Partners [8]Contact Us
| $ lynx -useragent='Debian uscan 2.9.27' -dump
'http://developer.berlios.de/project/showfiles.php?group_id=7729'
| Warning: User-Agent string does not contain Lynx or L_y_n_x!
|Forbidden
|You don't have permission to access /project/showfiles.php on this
|server.
| _
| Apache/1.3.34 Server at developer.berlios.de Port 80
`---
P.S. Sorry for an extensive list of Addressees -- just wanted to
follow-up on existing thread/issue.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: openjpeg
On Wed, Mar 21, 2007 at 04:49:42PM +0100, Romain Beauxis wrote: Le mercredi 21 mars 2007 16:32, Paul TBBle Hampson a écrit : * debian/copyright: add licence section header between copyright part and licence part.. Policy required it to be verbatim but you may still seperate what is licence and what is copyright.. OK. How do I describe the statement of copyright and license for the Debian packaging? It's both license and copyright. Well.. As explained before, copyright lists the guys that have worked in the code, with statements like (c) 2007 Someone Licence is the part that talks about rights granted on the code from the above copyright owners.. Simply add a Licence: line between copyright and the other part and its ok.. Also, now that we come to this point, have you checked all file headers ? I know it is a boring job, but it often gives you some very interesting results... upstream authors are not always consistent with the licence they give and some part of code they may take from other sources.. Given that you have read the REJECT FAQ, I guess you are aware of this point.. Erk. The template in dh_make needs fixing then... Drat, I forgot to check the stuff I wasn't building. _ There's a couple of copies of a four-clause BSD-licensed getopt.[ch], one attrubution-only type copyright in the jp3d library, and one java file that may be freely used or adapted. I guess the question is, to reroll without the getopt stuff, or email upstream and try and explain the issue to them, as well as the issue with the sonames. And the jpwl header stuff. And by email I apparently mean 'sourceforge forum'. I've got a bad feeling about this... * debian/control: still you define a libopenjpeg-tools, and still the typo... Wait, which typo are you talking about? I fixed the short description, and there's a bunch of 'r's in the long description of libopenjpeg1 in my local copy, dunno if they made it to the upload. (My laptop keyboard seems to occasionally insert a whole bunch of 'r's in vim... _) Yes I mean those r :) OK, fixed. I've renamed libopenjpeg-tools to openjepg-tools, but I remain convinced that this is needlessly inconsistent with libjpeg and libjasper's usage, and the libpkg guide. Well, those utilities seem to be usefull outside of the library usage. Take the user point of view, would you understand the a libopenjpeg-utils in fact contains utilities that have a more general usage than only for testing the library or whatever is library specific ? Other formulation would be : why do you think this package name has to be libopenjpeg specific ? The position I'm in is that if I want to see what came with a library, I'll look for it by package name, so if it starts with 'lib' it'll be in the output of an apt-cache search near the library itself. The short description tells me they're tools for the JPEG 2000 image compression codec, rather than being something library-specific like a *-config (which would be in -dev instead) and the long description even tells me what the tools are and what they do. If I want to find a tool to do something, I'd search on keywords, not names, and find it no matter what it's called. Mind you, in contrast to the below, the upstream project name is openjpeg, not libopenjpeg... Anyway, I've made the change, and I can appreciate both sides of the discussion. I'm not thrilled by the change, as I was of the understanding that without a clear style guide or policy position, such choices were at the descretion of the maintainer. I can think of mpeg3-utils for instance... Given that there's no such thing as mpeg3, that's an awful example. ^_^ libmpeg3 is the name of the project, and mpeg3-utils has managed to lose the 'lib', so it doesn't look like it belongs to that project, while instead looking like it is a tool to manipulate data according to an imaginary MPEG standard. And the short description claims it's a library, too, since it seems to share the short description with libmpeg3-1 _I'd_ have pulled this up as an example of why I think openjpeg-tools is the wrong name, were I trying to argue that. -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpROv9CucNzO.pgp Description: PGP signature
Re: Creating a source tarball for repackaged source using dpkg-source -b
On Thu, Mar 15, 2007 at 12:22:12PM +, Ben Hutchings wrote: On Fri, 2007-03-09 at 23:50 +, James Westby wrote: snip 4. Run tar czf package_upstream-version.dfsg.orig.tar.gz \ package-upstream-version.orig/ (adjusting paths appropriately) I have never checked that tar czf actually produces gzip -9 files, so you might need to form a pipeline if not. snip It doesn't. The pipeline would be: tar cf - $source_dir | gzip -c9 $tarball Or set GZIP=-9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dh_wraporig [was: Creating a source tarball for repackaged source...]
I hacked up a small script dh_wraporig
http://svn.debian.org/wsvn/pkg-exppsy/tools/dh_wraporig
for the cases when
* repackaging is required to remove some non-dfsg content
* wrapping original source-ball is desired (.xpi for ice*
extension, or even if .zip/.rar is shipped) to preserve the original
sources for easy confirmation of their authenticity
Customization of the parameters is done via their definition in
debian/dh_wraporig.local.
Now, whenever a new upstream version comes out, dh_wraporig is called by uscan
and my new fresh .orig.tar.gz is created for me automatically with
undesired content removed, or original source wrapped in the tarball and then
optional command ran (like svn-upgrade) on the generated tarball. Also I get an
updated debian/README.Debian-source file which looks like
,
| README on source packaging of remake:
| --
|
| The source tarball of the package was generated by
| dh_wraporig v.0.1.236 script which
| can be obtained from alioth's exppsy project repository:
| http://svn.debian.org/wsvn/pkg-exppsy/tools/dh_wraporig
|
| For this package dh_wraporig performed following actions:
| * Extracted files from
| md5:23428d1d5e85774b2a4149ef01fddaac ../remake_3.80+dbg0.62.orig.tar.gz
| * Removed following files/directories:
| doc/make.{texi,info*,html} doc/{make-stds,fdl}.*
|
| Additional information:
| * Following patches were present to be applied to the original source
| at build time
| 00-dfsg-no-makedoc
| 00-correct-info-title
`---
debian/dh_wraporig.local for this case looks like
,---
| # later on should be changed to svn-upgrade
| # but now that would just annoy
| post_command=
|
| #
| # files/directories to delete. bash patterns
| delete_files='doc/make.{texi,info*,html} doc/{make-stds,fdl}.*'
|
| #
| # suffix to attach
| suffix_out=~dfsg
|
| #
| # for now we better simply create a symlink
| do_orig_symlink= pleasedo ;-)
|
| #
| # do we need original tarball? I guess so for now,
| # if not - uncomment
| #do_delete_originals= kill the beast
|
| #
| # Create README.Debian-source
| do_create_readme= of course
`---
Then in collaboration with uscan's
,---
| opts=versionmangle=s/-//,dversionmangle=s/~dfsg\.\d+$//
`---
at the end I am effortlessly getting
,---
| remake-3.80+dbg0.62~dfsg.1.tar.gz
`---
This way anyone who gets this source can confirm the authenticity of upstream
tarball, and can replicate all the steps which were done to ship debian version
of the upstream source. Otherwise, I found it difficult some times to
figure out what was actually done to the upstream source and what tarball was
actually used to generate .orig.tar.gz.
May be an improved version of such script can become a part of debhelper utils
- that would unify things a bit.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating a source tarball for repackaged source using dpkg-source -b
Ben Hutchings [EMAIL PROTECTED] wrote: This is what you should do *if* you need to repackage upstream source. That is only necessary if it: - contains non-DFSG-compliant material, and you want to upload to main - is not a gzipped tarball - is divided into multiple tarballs It is not necesssary to repackage merely to change the directory name (dpkg-source -x deals with that automatically) or to improve compression. Mmm. Mentors should (and do!) reject packages that have been unnecessarily repackaged by checking their MD5 or SHA1 sums against the upstream version. -- Chris Lamb, Leamington Spa, UKGPG: 0x634F9A20 signature.asc Description: PGP signature
