Re: uscan for a single text file

[Sergio Durigan Junior]

On Saturday, July 16 2016, Ole Streicher wrote:

> Sergio Durigan Junior  writes:
>>> What is wrong here? I thought that mk-orig.tar.gz should be called only
>>> when it is a tar archive?
>>
>> Yeah, uscan is the responsible for invoking mk-origtargz.  That can be a
>> problem indeed for cases like yours.
>
> Hmm, the manpage of uscan says:
>
> | Please note the repacking of the upstream tarballs by mk-origtargz
> | happens only if one of the following conditions is satisfied:
> |  · USCAN_REPACK is set in the devscript configuration.
> |  · --repack is set on the commandline.
> |  · repack is set in the watch line as opts="repack,...".
> |  · The upstream archive is of zip type including jar, xpi, ...
> |  · Files-Excluded or Files-Excluded-component stanzas are set in
> |debian/copyright to make mk-origtargz invoked from uscan remove 
> |files from the upstream tarball and repack it.
>
> Non of these is true in my case. So, isn't this a bug in uscan?

This snippet refers to the repacking of the upstream tarball.  Even when
no repacking is needed/requested, mk-origtargz is still invoked (it is
resposible for creating the symlink to the .orig.tar.gz file, for
example).

>> Here's a hacky solution.  First, in order to avoid calling mk-origtargz
>> you need to pass the --no-symlink option to uscan (or set the
>> USCAN_SYMLINK environment variable to "no").  That is unfortunately the
>> only way, and there is also no opts available that you can use inside
>> the watch file.
>
> wouldn't it be worth to add an option to uscan "opts=norepack"?

Not necessarily 'norepack', because of what I explained above.  But
yeah, as I mentioned to Gianfranco I also think it is worth adding an
option to disable the execution of mk-origtargz.  I went ahead and
submitted the following:

  

>> Also, I found a few problems with your repackaging script.  uupdate will
>> expect a certain pattern when decompressing it, like a directory named
>> package-version/, so you need to create that as well.  Attached on this
>> message is an updated script that seems to work (as far as I have
>> tested; I don't have the full package here).
>
> Yea, mine was a quick hack. In principle, I don't see a reason for this
> at all. Usually, the package is just downloaded and then processed
> further by other tools (gbp import-orig) or untarred manually.

Yeah, it is curious that mk-origtargz and uupdate both create the same
symlink from the original tarball to the .orig tarball.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: uscan for a single text file

[Ole Streicher]

Sergio Durigan Junior  writes:
>> What is wrong here? I thought that mk-orig.tar.gz should be called only
>> when it is a tar archive?
>
> Yeah, uscan is the responsible for invoking mk-origtargz.  That can be a
> problem indeed for cases like yours.

Hmm, the manpage of uscan says:

| Please note the repacking of the upstream tarballs by mk-origtargz
| happens only if one of the following conditions is satisfied:
|  · USCAN_REPACK is set in the devscript configuration.
|  · --repack is set on the commandline.
|  · repack is set in the watch line as opts="repack,...".
|  · The upstream archive is of zip type including jar, xpi, ...
|  · Files-Excluded or Files-Excluded-component stanzas are set in
|debian/copyright to make mk-origtargz invoked from uscan remove 
|files from the upstream tarball and repack it.

Non of these is true in my case. So, isn't this a bug in uscan?

> Here's a hacky solution.  First, in order to avoid calling mk-origtargz
> you need to pass the --no-symlink option to uscan (or set the
> USCAN_SYMLINK environment variable to "no").  That is unfortunately the
> only way, and there is also no opts available that you can use inside
> the watch file.

wouldn't it be worth to add an option to uscan "opts=norepack"?

> Also, I found a few problems with your repackaging script.  uupdate will
> expect a certain pattern when decompressing it, like a directory named
> package-version/, so you need to create that as well.  Attached on this
> message is an updated script that seems to work (as far as I have
> tested; I don't have the full package here).

Yea, mine was a quick hack. In principle, I don't see a reason for this
at all. Usually, the package is just downloaded and then processed
further by other tools (gbp import-orig) or untarred manually.

I still don't get the reason for the other stuff that uupdate does. But
thanks for the script; I'll use it ;-)

Best regards

Ole

Re: /usr/share/pyshared dir

[Herbert Fortes]

Em Sáb, 2016-07-16 às 21:24 +0500, Andrey Rahmatullin escreveu:
> On Sat, Jul 16, 2016 at 01:05:47PM -0300, Herbert Fortes wrote:
> > The package in Sid[0] has a /usr/share/pyshared
> > directory that will not be present if
> > you build (withour changes) the package today, 
> /usr/share/pyshared was used when we supported python 2.6. You can see
> that the sid package supports 2.6.

Ok. The package now is:

Depends: libextractor3 (>= 1:1.1), python:any (<< 2.8), python:any (>= 2.7.5-5~)

Thanks for the help.

> 
> > But it is reproducible[1].
> I guess the reproducible tools don't look at the sid binary packages.
> 

Yes, it does. testing and unstable for amd64, i386 and armhf

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libextractor-python.html



regards,
-- Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: blocked mentors queue?

[Felix Natter]

Stefan Tomanek  writes:

> Dies schrieb foss.freedom (foss.free...@gmail.com):
>
>> many thanks for the reply and guidance.  Have sent an email to
>> supp...@mentors.debian.net
>
> I've seen one new package appear on https://mentors.debian.net/packages/index,
> however the one I've uploaded last night still seems to be stuck - did you
> receive any news whether the queue will be processed or if further manual
> intervention is needed?

+1 from me: I uploaded two packages successfully this morning, but they
didn't appear yet.

Thanks and Best Regards,
-- 
Felix Natter

Re: /usr/share/pyshared dir

[Andrey Rahmatullin]

On Sat, Jul 16, 2016 at 01:05:47PM -0300, Herbert Fortes wrote:
> The package in Sid[0] has a /usr/share/pyshared
> directory that will not be present if
> you build (withour changes) the package today, 
/usr/share/pyshared was used when we supported python 2.6. You can see
that the sid package supports 2.6.

> But it is reproducible[1].
I guess the reproducible tools don't look at the sid binary packages.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: uscan for a single text file

[Sergio Durigan Junior]

On Saturday, July 16 2016, Gianfranco Costamagna wrote:

> Hi Sergio

Hey Gianfranco,

>>Yeah, uscan is the responsible for invoking mk-origtargz.  That can be a
>>problem indeed for cases like yours.
>
>
> do you have a solution for virtualbox-guest-additions-iso package?
> the same happens here since the orig file is an iso file :)

Oh, I have a solution!  Get rid of this proprietary software on Debian!
;-)

Seriously, though.  I've also had to do a few modifications to the
get-orig-source.sh script, and you'll also need to run uscan with the
--no-symlink option, but this should work.  Oh, and you will also need
to specify downloadurlmangle like this:

  opts="downloadurlmangle=s@(.*)@http:$1@" \
  
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VBoxGuestAdditions_([\d\.\-]+).iso
 \
debian /bin/sh debian/get-orig-source.sh

But that is because of a malformed URL at the virtualbox website.

BTW, it may be a good idea to implement some kind of in-file support to
specify the no-symlink option.  Maybe also using opts.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

#!/bin/sh

set -ex

if [ $# -ne 2 ]; then
  echo "Error: 3 parameters are required."
  exit 1
fi

if [ "$1" != "--upstream-version" ]; then
  echo "Error: First parameter needs to be --upstream-version."
  exit 1
fi

UPSTREAM_VERSION=$2
ORIG_TARBALL=`readlink -e ../`/VBoxGuestAdditions_${UPSTREAM_VERSION}.iso

ORGDIR=`pwd`

cd `dirname $ORIG_TARBALL`
if ! wget -O - 
http://download.virtualbox.org/virtualbox/$UPSTREAM_VERSION/SHA256SUMS | grep 
iso | sha256sum -c --strict -; then
  echo "Error: checksum doesn't match."
  exit 1
fi
cd $ORGDIR

PACKAGE_NAME=`awk '/^Source: / { print $2 }' debian/control`

if [ -z "$PACKAGE_NAME" ]; then
  echo "Error: couldn't determine package name."
  exit 1
fi

TMP=`mktemp -d`

if [ -z "$TMP" ]; then
  echo "Error: couldn't create a tmp dir."
  exit 1
fi

trap 'rm -r $TMP' EXIT

mkdir $TMP/${PACKAGE_NAME}-$UPSTREAM_VERSION
mv $ORIG_TARBALL $TMP/${PACKAGE_NAME}-$UPSTREAM_VERSION/
cd $TMP
tar czf ${PACKAGE_NAME}_$UPSTREAM_VERSION.orig.tar.gz 
${PACKAGE_NAME}-$UPSTREAM_VERSION
mv ${PACKAGE_NAME}_$UPSTREAM_VERSION.orig.tar.gz $ORGDIR/../
cd $ORGDIR
echo "Done, now you can run gbp import-orig 
../${PACKAGE_NAME}_$UPSTREAM_VERSION.orig.tar.gz"


signature.asc
Description: PGP signature

/usr/share/pyshared dir

[Herbert Fortes]

Hi,

I am doing a QA for python-extractor.

The package in Sid[0] has a /usr/share/pyshared
directory that will not be present if
you build (withour changes) the package today, 
my sid chroot env at least. But it is reproducible[1].

[0] - https://packages.debian.org/sid/all/python-extractor/filelist
[1] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libextractor-python.html

Others packages also have this directory[2].

[2] - 
https://packages.debian.org/search?suite=sid=all=any=contents=extractor.py

The source package name is libextractor-python and extractor.py
file is going to /usr/lib. Why /usr/share/pyshared/extractor.py ?

my debian/changelog until now:

  * QA upload.
  * debian/clean created:
  - rm egg-info files.
  * debian/compat:
  - 9
  * debian/control:
  - bump Standarsd-Version from 3.9.2 to 3.9.8
  - debhelper >= 9 and dh-python added to Depends field
  - using X-Python-Version
  - Recommends libextractor-plugins removed. (Closes:  #722200)
It was merged into libextractor3 1:1.1.
Thanks Micah Gersten.
  * debian/rules:
  - using PYBUILD.
  * debian/watch created.



regards,
-- Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Secure URI replacement for svn://anonscm.debian.org ?

[Thomas Schmitt]

Hi,

lintian.debian.org accuses package libburn of

  [I] vcs-field-uses-insecure-uri
vcs-browser http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/
vcs-svn svn://anonscm.debian.org/pkg-libburnia/trunk/libburn/

The first URI can simply be changed to https:, but the svn: URI makes
me riddle.

Simply replacing svn: by https: does not work
  $ svn co https://anonscm.debian.org/pkg-libburnia/trunk/libburn/
  svn: E170013: Unable to connect to a repository at URL 
'https://anonscm.debian.org/pkg-libburnia/trunk/libburn'
  ...

I myself address the SVN by
  svn+ssh://svn.debian.org/svn/pkg-libburnia/trunk
because i need commit access.

For a test of anonymous checkout i set up a new user by "adduser" with
no special permissions and no relation to the SSH software of Debian
servers.
The insecure URI works just fine for this user:
  $ svn co svn://anonscm.debian.org/pkg-libburnia/trunk/libburn/
  ...
  Checked out revision 390.

But svn+ssh: yields error:
  $ svn co svn+ssh://svn.debian.org/svn/pkg-libburnia/trunk/ibburn/
  ...
  Are you sure you want to continue connecting (yes/no)? yes
  svn: E170013: Unable to connect to a repository at URL 
'svn+ssh://svn.debian.org/svn/pkg-libburnia/trunk/libburn'
  ...

Same with the anonscm.debian.org hostname:
  svn: E170013: Unable to connect to a repository at URL 
'svn+ssh://anonscm.debian.org/pkg-libburnia/trunk/libburn'


Have a nice day :)

Thomas

Re: blocked mentors queue?

[Stefan Tomanek]

Dies schrieb foss.freedom (foss.free...@gmail.com):

> many thanks for the reply and guidance.  Have sent an email to
> supp...@mentors.debian.net

I've seen one new package appear on https://mentors.debian.net/packages/index,
however the one I've uploaded last night still seems to be stuck - did you
receive any news whether the queue will be processed or if further manual
intervention is needed?

Re: uscan for a single text file

[Gianfranco Costamagna]

Hi Sergio




>Yeah, uscan is the responsible for invoking mk-origtargz.  That can be a
>problem indeed for cases like yours.


do you have a solution for virtualbox-guest-additions-iso package?
the same happens here since the orig file is an iso file :)

thanks,
(I invoke debian/get-orig-source.sh manually to workaround the issue)
G.

Re: uscan for a single text file

[Sergio Durigan Junior]

On Friday, July 15 2016, Ole Streicher wrote:

> Hi,

Hey,

> I want to create a watch file for a package that contains a single text
> file (which itself has the version into it):
> version=3
> http://www.ngdc.noaa.gov/IAGA/vmod/igrf.html igrf(\d+)coeffs.txt \
>  debian debian/repackage.sh
>
> The "repackage.sh" script would then just create a tarball:
> #!/bin/sh
> set -e
>
> VERSION=$2
> BASEDIR=$(dirname $3)
>
> cd $BASEDIR
> tar cf igrf-coefficients_$VERSION.orig.tar igrf${VERSION}coeffs.txt
> rm -f igrf${VERSION}coeffs.txt
> xz igrf-coefficients_$VERSION.orig.tar
> exec uupdate --no-symlink --upstream-version ${VERSION} 
> igrf_${VERSION}.orig.tar.xz
>
> However, when I run this, uscan complaints:
> $ uscan 
> uscan: Newest version of igrf-coefficients on remote site is 12, local 
> version is 10
> uscan:=> Newer package available from
>   http://www.ngdc.noaa.gov/IAGA/vmod/igrf12coeffs.txt
> Parameter ../igrf12coeffs.txt does not look like a tar archive or a zip file. 
> at /usr/bin/mk-origtargz line 375.
> uscan: error: mk-origtargz --package igrf-coefficients --version 12 
> --compression gzip --directory .. --copyright-file debian/copyright 
> ../igrf12coeffs.txt gave error exit status 255
>
> --debug does not show more here.
> What is wrong here? I thought that mk-orig.tar.gz should be called only
> when it is a tar archive?

Yeah, uscan is the responsible for invoking mk-origtargz.  That can be a
problem indeed for cases like yours.

Here's a hacky solution.  First, in order to avoid calling mk-origtargz
you need to pass the --no-symlink option to uscan (or set the
USCAN_SYMLINK environment variable to "no").  That is unfortunately the
only way, and there is also no opts available that you can use inside
the watch file.

Also, I found a few problems with your repackaging script.  uupdate will
expect a certain pattern when decompressing it, like a directory named
package-version/, so you need to create that as well.  Attached on this
message is an updated script that seems to work (as far as I have
tested; I don't have the full package here).

Another option would be to create a redirector like the one we have for
PyPi, but that demands a bit more work I suppose.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

#!/bin/sh
set -e

VERSION=$2
OLDDIR=$PWD
BASEDIR=$PWD/../

cd $BASEDIR
mkdir igrf-coefficients-${VERSION}/
mv igrf${VERSION}coeffs.txt igrf-coefficients-${VERSION}/
tar cf igrf-coefficients_$VERSION.orig.tar igrf-coefficients-${VERSION}/
rm -rf igrf-coefficients-${VERSION}/
xz igrf-coefficients_$VERSION.orig.tar
cd $OLDDIR
exec uupdate --no-symlink --upstream-version ${VERSION} 
$BASEDIR/igrf-coefficients_$VERSION.orig.tar.xz


signature.asc
Description: PGP signature

Re: blocked mentors queue?

[foss.freedom]

many thanks for the reply and guidance.  Have sent an email to
supp...@mentors.debian.net

cheers

On 16 July 2016 at 10:23, Roger Shimizu  wrote:

> On Sat, Jul 16, 2016 at 5:26 PM, foss.freedom 
> wrote:
> > Hi,
> >
> >   I sent a package up to the mentors queue last night but it hasn't
> appeared
> > in "my packages" of the mentors website.
> >
> > I've checked ftp://mentors.debian.net/ and my package is there as are a
> few
> > other packages.
> >
> > I've tried to send a revised package today both via HTTP and FTP but am
> > getting a 403 / 553 error respectively.
> >
> > I've tried to delete an older version that was listed on "my packages" -
> my
> > packages now says I havent got any packages uploaded
>
> I had similar issue before.
> It need to contact 
> to let the admin remove the broken uploaded package.
> After that, you'll be able to upload again.
>
> Cheers,
> --
> Roger Shimizu, GMT +9 Tokyo
> PGP/GPG: 4096R/6C6ACD6417B3ACB1
>

Re: blocked mentors queue?

[Roger Shimizu]

On Sat, Jul 16, 2016 at 5:26 PM, foss.freedom  wrote:
> Hi,
>
>   I sent a package up to the mentors queue last night but it hasn't appeared
> in "my packages" of the mentors website.
>
> I've checked ftp://mentors.debian.net/ and my package is there as are a few
> other packages.
>
> I've tried to send a revised package today both via HTTP and FTP but am
> getting a 403 / 553 error respectively.
>
> I've tried to delete an older version that was listed on "my packages" - my
> packages now says I havent got any packages uploaded

I had similar issue before.
It need to contact 
to let the admin remove the broken uploaded package.
After that, you'll be able to upload again.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

blocked mentors queue?

[foss.freedom]

Hi,

  I sent a package up to the mentors queue last night but it hasn't
appeared in "my packages" of the mentors website.

I've checked ftp://mentors.debian.net/ and my package is there as are a few
other packages.

I've tried to send a revised package today both via HTTP and FTP but am
getting a 403 / 553 error respectively.

I've tried to delete an older version that was listed on "my packages" - my
packages now says I havent got any packages uploaded

Something wrong with the mentors upload queue?

thanks

David

Re: Call for review: Improving RFS template for mentors.debian.net

[HAYASHI Kentaro]

Hi,

On Fri, Jul 15, 2016 at 7:12 AM, Jakub Wilk  wrote:
>
> * Gianfranco Costamagna , 2016-07-14, 22:06:
>>>
>>> Typo:
>>> an QA upload -> an QA upload
>>
>> I fail to see differences...
>> did you mean "a QA upload"?
>
>
> Oops. I meant:
>
> an QA upload -> a QA upload

Thank you for feedback.
I also can't find difference too. :-P
Anyway,  I've fixed a typo in PR.

--
Kentaro Hayashi