Re: watch file with multiple download url

[Paul Wise]

On Tue, Jan 17, 2017 at 2:47 PM, PICCA Frederic-Emmanuel wrote:

> so it seems that I have a problem with the upstream versioning
...
> the final release is tango-9.2.5a which is considered lower than 
> tango-9.2.5-rcx
>
> how should I change my watch file to take this into account.

This has nothing to do with that you have multiple download URLs.

You are simply missing to replace - with ~ to sort RCs before final versions.

uversionmangle=s/-rc/~rc/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

RE:watch file with multiple download url

[PICCA Frederic-Emmanuel]

> uscan works out of the box with both URLs as far as I can tell.


you I uncomment everythongs and uscan check at bothe URL compares the version  
and at the end download the most recent package from the right URL ?


ok, I uncomment both URL and now I get this

version=4
opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \
 
http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate
opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \
 
ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate


picca@mordor:~/Debian/tango/tango$ uscan --verbose
uscan info: uscan (version 2.17.0) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="tango" version="9.2.5a+dfsg1-2" (as seen in 
debian/changelog)
uscan info: package="tango" version="9.2.5a+dfsg1" (no epoch/revision)
uscan info: Check debian/watch and debian/changelog in ./.git/refs/tags
uscan info: ./debian/changelog sets package="tango" version="9.2.5a+dfsg1"
uscan info: Process ./debian/watch (package=tango version=9.2.5a+dfsg1)
uscan info: opts: dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1
uscan info: line: 
http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate
uscan info: Parsing dversionmangle=s/\+dfsg\d*$//
uscan info: Parsing repacksuffix=+dfsg1
uscan info: line: 
http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate
uscan info: sf.net redirection to qa.debian.org/watch/sf.php
uscan info: Last orig.tar.* tarball version (from debian/changelog): 
9.2.5a+dfsg1
uscan info: Last orig.tar.* tarball version (dversionmangled): 9.2.5a
uscan info: Requesting URL:
   https://qa.debian.org/watch/sf.php/tango-cs/
uscan info: Matching pattern:
   
(?:(?:https://qa.debian.org)?\/watch\/sf\.php\/tango\-cs\/)?tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))(?:\?.*)?
uscan info: Found the following matching hrefs on the web page (newest first):
   /watch/sf.php/tango-cs/tango-9.2.5a.tar.gz (9.2.5a) index=9.2.5a-1
   /watch/sf.php/tango-cs/tango-9.2.5a.tar.gz (9.2.5a) index=9.2.5a-1
   /watch/sf.php/tango-cs/tango-9.2.2.tar.gz (9.2.2) index=9.2.2-1
   /watch/sf.php/tango-cs/tango-9.2.2.tar.gz (9.2.2) index=9.2.2-1
   /watch/sf.php/tango-cs/tango-9.2.1.tar.gz (9.2.1) index=9.2.1-1
   /watch/sf.php/tango-cs/tango-9.2.1.tar.gz (9.2.1) index=9.2.1-1
   /watch/sf.php/tango-cs/tango-8.1.2c-patched.tar.gz (8.1.2c-patched) 
index=8.1.2c-patched-1
   /watch/sf.php/tango-cs/tango-8.1.2c.tar.gz (8.1.2c) index=8.1.2c-1
   /watch/sf.php/tango-cs/tango-8.0.5.tar.gz (8.0.5) index=8.0.5-1
uscan info: Matching target for downloadurlmangle: 
https://qa.debian.org/watch/sf.php/tango-cs/tango-9.2.5a.tar.gz
uscan info: Upstream URL (downloadurlmangled):
   https://qa.debian.org/watch/sf.php/tango-cs/tango-9.2.5a.tar.gz
uscan info: Newest upstream tarball version selected for download 
(uversionmangled): 9.2.5a
uscan info: Download filename (filenamemangled): tango-9.2.5a.tar.gz
uscan info: Newest version of tango on remote site is 9.2.5a, local version is 
9.2.5a+dfsg1
 (mangled local version is 9.2.5a)
uscan info:=> Package is up to date for from
  https://qa.debian.org/watch/sf.php/tango-cs/tango-9.2.5a.tar.gz
uscan info: opts: dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1
uscan info: line: 
ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate
uscan info: Parsing dversionmangle=s/\+dfsg\d*$//
uscan info: Parsing repacksuffix=+dfsg1
uscan info: line: 
ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate
uscan warn: more than one main upstream tarballs listed.
uscan info: Last orig.tar.* tarball version (from debian/changelog): 
9.2.5a+dfsg1
uscan info: Last orig.tar.* tarball version (dversionmangled): 9.2.5a
uscan info: Requesting URL:
   ftp://ftp.esrf.eu/pub/cs/tango/
uscan info: matching pattern 
(?:(?:ftp://ftp.esrf.eu)?\/pub\/cs\/tango\/)?tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
uscan info: Standard FTP listing.
uscan info: Found the following matching files on the web page (newest first):
   tango-9.2.5-rc2.tar.gz (9.2.5-rc2) index=9.2.5-rc2-1
   tango-9.2.5-rc1.tar.gz (9.2.5-rc1) index=9.2.5-rc1-1
   tango-9.2.5a.tar.gz (9.2.5a) index=9.2.5a-1
   tango-9.2.2.tar.gz (9.2.2) index=9.2.2-1
   tango-9.1.0.tar.gz (9.1.0) index=9.1.0-1
   tango-8.1.2c.tar.gz (8.1.2c) index=8.1.2c-1
   tango-8.1.2b.tar.gz (8.1.2b) index=8.1.2b-1
   tango-8.1.2a.tar.gz (8.1.2a) index=8.1.2a-1
   tango-8.1.2.tar.gz (8.1.2) index=8.1.2-1
   tango-8.0.5.tar.gz (8.0.5) index=8.0.5-1
   tango-7.2.6-svn-17100-win-x64-msvc-2010.zip 
(7.2.6-svn-17100-win-x64-msvc-2010) index=7.2.6-svn-17100-win-x64-msvc-2010-0
   tango-7.2.6a.tar.gz (7.2.6a) index=7.2.6a-1
   tango-7.2.6.tar.gz (7.2.6) index=7.2.6-1
   

Bug#835274: bcron

[Dmitry Bogatov]

[2017-01-12 20:00] Gianfranco Costamagna 
> >I consider disabling mentioned three tests (exec-fds,
> >spool-list-perms,sched_dump). WDYT?
>
> probably the best solution right now

Did it. New revision is on mentors, hash commit in git is fbd6d60.

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.

Re: watch file with multiple download url

[Paul Wise]

On Mon, Jan 16, 2017 at 11:01 PM, PICCA Frederic-Emmanuel wrote:

> No issues, I just wanted to know if I could have something with uscan which 
> work out of the box with both URL's.
> So I would like something without the comment / uncomment trick.

uscan works out of the box with both URLs as far as I can tell.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: git-p4 package?

[Sean Whitton]

Dear Luke,

On Mon, Jan 16, 2017 at 11:27:22PM +, Luke Diamand wrote:
> I put in a patch to add a git-p4 package, here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773245
> 
> I was wondering what I need to do next for this to be merged? Or if
> I've done it wrong somehow?

I haven't looked at the patch, but you haven't done anything wrong with
regard to Debian procedures.  It's simply a matter of waiting for a
response from the maintainers of the git package.

You could prepare an NMU of the git package and submit a request for
sponsorship to DEFERRED, but that would be unusual for a bug of wishlist
severity.  Please read up on NMUs in the Debian Developer's Reference,
so that you are properly informed of your options.

-- 
Sean Whitton


signature.asc
Description: PGP signature

mpgrafic - mpirun test program as root in automatic build

[Boud Roukema]

hi Debian-mentors,

Is it reasonable to override the mpirun (openmpi_2.0.2~git.20161225-8)
default preference of refusing to run as root?

I've started packaging mpgrafic for debian - this is my first
debianisation, apart from minor private hacks after extracting debian
source packages:

https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/

I've added regression-test-0.3.7.sh to the upstream version of
mpgrafic. This is a "reproducible run" test. The test runs the main
binary, mpgrafic, with a frontend "mpirun", which, in general, allows
a program to run on many different machines, without shared memory.
This test runs explicitly on exactly one processor, for reproducibility.

Since, in general, there is no reason for mpirun to run as root,
the sid version of mpirun (from openmpi) apparently refuses to run as root.
(I have not reproduced this behaviour myself - Ole Streicher
has warned me about it.) The openmpi developers provide an option
--allow-run-as-root.

In version 0.3.7.4-1, the debian-only, openmpi-only use of this option in
debian/rules + regression-test-0.3.7.sh

https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/debian/rules
https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/regression-test-0.3.7.sh

should presumably allow debian automatic builds to pass "make check".

Is the choice to use the option --allow-run-as-root safe from a general
system security point of view?

My arguments against (i.e. it would be unsafe):

* A newbie might download/extract the debian source as root,
unintentionally modify the fortran source to do some dangerous things
with files and directories, change the -n 1 option to -n 32 for a cluster
of 4 machines each with 8 processors, and then try "make check".
Since the --allow-run-as-root option is enabled in regression-test-0.3.7.sh,
the newbie does some dangerous root operations.

Counterarguments (i.e. it would be safe):

** If the newbie has ignored the recommendation of building
debian packets from source with fakeroot debian/rules binary, then s/he
is already taking superuser risks, and we can't do much to help him/her;

** Introducing system-dangerous operations in fortran is possible, but unlikely
for someone just wishing to make a cosmology calculation;

** If the newbie modifies the -n 1 option, then s/he would see
the much more obvious --allow-run-as-root option and should learn
enough to realise that running as root is unlikely to be needed when
compiling/running the package as an ordiner user.

An alternative I see to enabling --allow-run-as-root would be e.g.

adduser --no-create-home --disabled-password mpgrafic
mpirun -n 1 ... ;
deluser mpgrafic

but that would unnecessarily require build dependence on adduser, and
creating/removing users is itself a security-related issue that
automated checkers (e.g. lintian) might (or should?) be concerned
about.

I'd like to rename mpgrafic-0.3.7.4 to 0.3.8 upstream, along with the
debian versions 0.3.7.4-1 and 0.3.8-1, but first it would be
good to hear some opinions on this.

tracker: https://tracker.debian.org/pkg/mpgrafic

Cheers
Boud

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

[sorry, this got stuck in my drafts folder]

Dear Nicholas,

On Sun, Jan 15, 2017 at 10:26:44PM -0700, Nicholas D Steeves wrote:
> Thank you again for your patience and extra help!

No problem.  I hope that this was educational for you as a new DM --
that's probably more important than the updated package.

> > > Ah!  Yes, this is the spec that addresses my question to #3.  That
> > > said, in the past some of my other work on d/copyright has been said
> > > to be "worse than useless" even though it adhered to the spec, and
> > > even though it seemed to reflect what I saw reading the packages
> > > COPYING file, in addition to spending a while reading VCS commits for
> > > stuff I wasn't sure about.  This has led me to wonder about the tribal
> > > rules that are not in the spec...
> > 
> > Could you give me an example of a rule like that?
> 
> It'll take time to dig up examples from my backups, so I'll need to
> defer concrete examples until something like mid February.  It might
> be stuff like my failure to identify a package that is following DEP-5
> vs SPDX, but because of comments like "worst than useless" I figured
> there must have been some rule I didn't understand...because that's
> way too strong of a reaction for something that is a question of
> style. :-)  At this point, however, I don't think further discussion
> fits into this thread, because it is too tangential to muse-el.

Okay.  Probably best to address you question to the d-mentors list.

> By the way, is one space indentation for copyright definition blocks
> what should now be used (commit
> 5ba94789a7f35d5938d88226c6ea35fd98635a5b)?  I noticed the packaging
> guide's example uses one space, but most of the copyright-format/1.0
> packages I've looked at use four.  Just a convention?

I've only seen it done with a single space.  If it works with more than
one, fine.

> > > Would you please check to see if my latest commit to d/copyright
> > > is ok?  It's what makes the most sense to me.  As far as I can
> > > tell, it might be problematic because it infers that Eric Marsden
> > > changed cgi.el in 2003.  If it's problematic I'll revert it, then
> > > dch -r.
> > 
> > No, it doesn't actually imply that Marsden changed that file in 2004
> > (the spec does explain this!).
> 
> Ah, from packaging-manuals/copyright-format/1.0 "Not all copyright
> notices may apply to every individual file, and years of publication
> for one copyright holder may be gathered together" [1].  So short form
> rules I misunderstood are:
> 
> * Wildcards are hungry globs.
> * Lists of files are white-space, tab, or newline separated strings.
> * Years may be specified as either a comma-separated list of discrete
>   years, or a year-to-year range.
> * Refer to individual files or VCS for specific dates when multiple
>   files are grouped, because [1].

I don't know whether this list is an accurate list of what you
misunderstood, but the four bullet points are true of the format :)

> I also wonder how many contributors there must be to justify a
> "Primary copyright holder, and others" statement, and also if one
> needs to do VCS archaeology to find and list all of the potential
> one-off contributors.

That's beyond my knowledge, I'm afraid.  You might want to ask d-legal.

-- 
Sean Whitton


signature.asc
Description: PGP signature

git-p4 package?

[Luke Diamand]

Hi!

I put in a patch to add a git-p4 package, here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773245

I was wondering what I need to do next for this to be merged? Or if
I've done it wrong somehow?

Thanks
Luke

Bug#844184: marked as done (RFS: muse-el/3.20+dfsg-1 [ITA])

[Debian Bug Tracking System]

Your message dated Mon, 16 Jan 2017 22:23:48 +
with message-id 
and subject line closing RFS: muse-el/3.20+dfsg-1 [ITA]
has caused the Debian Bug report #844184,
regarding RFS: muse-el/3.20+dfsg-1 [ITA]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
844184: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844184
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for review and a sponsor for my package "src:muse-el".
I've CC'd Sean Whitton who is willing to help me with elpa, LISP, and
any emacs-on-Debian integration issues.
Here are a few things I'm wondering about:

Are the generated packages in the correct sections for an elpafied
package?
Is removing hrefs to favicon.ico (Bug: #775885) sufficient?
Distributing a favicon.ico seems unnecessary and honestly, I'm
against it. In Canada, because the author retains all distribution
rights in the absence of a license or declared copyright, even
something as trivial as a favicon.ico can be unredistributable.  I
couldn't find the license on Michael Olson's website
, so I decided it was best not to copy it.

Do my patches look ok?
Should elpafied packages continue to be arch-independent?
Is debian/changelog too verbose and could it be condensed?

Package name: muse-el
Version : 3.20+dfsg-1
Section : editors

It builds those binary packages:

  elpa-muse  - Author and publish projects using Wiki-like markup
  muse-el- transitional dummy package for elpa-muse.

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/muse-el

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/muse-el/muse-el_3.20+dfsg-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

muse-el (3.20+dfsg-1) unstable; urgency=medium

  * New Maintainer.
  * debian/control:
- Bump required debhelper to >=9.
- Update emacs dependency.
- Add emacs-goodies-el dependency, which provides htmlize.el.
  * Switch to debcompat 9; Switch to 3.0 (quilt) non-native packaging.
  * Add patch to fix privacy breaches; removes hrefs. (Closes: #775885)
  * Elpafy! (depends on dh-elpa).
  * Add patch to disable non-DFSG compliant texi stuff.
  * Install docs and examples the new dh_way.
  * debian/rules:
- add override to build examples and autoloads.
- add override to install upstream changelog series.
  * debian/copyright:
- Fix misattributed source (found by comparing timestamps in comments
  between gna.org tarballs and git sources).
- Update format.
- Add debian/* section.
  * Include images used by the QuickStart.muse example. (Closes: #720121)
  * Add patch to use Debian's "see" command instead of "open".  Thank
you Kevin Ryde, I didn't know about the existence of "see" before
reading this bug report. (Closes: #720126)
  * Patch README to explain how installed files relate to src:muse-el.

 -- Nicholas D Steeves   Tue, 18 Oct 2016 20:58:45 -0400


Regards,
Nicholas D Steeves
--- End Message ---
--- Begin Message ---
Package muse-el version 3.20+dfsg-1 is in NEW now,
and the package at mentors is not newer (2017-01-15) than the package in NEW 
(2017-01-15),
so there is currently no package to sponsor.

https://ftp-master.debian.org/new/muse-el_3.20+dfsg-1.html
https://mentors.debian.net/package/muse-el

If for some reason you need to replace the package in NEW,
then you can upload an updated package to mentors
and feel free to reopen this RFS 844184 or open a new RFS.--- End Message ---

Bug#851606: RFS: rmlint/2.4.6-1 [ITP]

[Carlos Maddela]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "rmlint"

 * Package name: rmlint
   Version : 2.4.6-1
   Upstream Author : Christopher Pahl 
 * URL : https://rmlint.readthedocs.io/
 * License : GPL-3
   Section : utils

  It builds these binary packages:

rmlint - Extremely fast tool to remove filesystem lint
rmlint-gui - GTK+ frontend to rmlint

  To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/rmlint


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/r/rmlint/rmlint_2.4.6-1.dsc

  More information about rmlint can be obtained from 
https://rmlint.readthedocs.io/.

  Initial upload:

   rmlint (2.4.6-1) unstable; urgency=medium

 * Initial upload to Debian. Thanks to Axel Beckert for getting
   it all started. (Closes: #845155)

-- Carlos Maddela   Tue, 17 Jan 2017 04:45:28 +1100


  Regards,
   Carlos Maddela

RE:watch file with multiple download url

[PICCA Frederic-Emmanuel]

> Just uncommenting both seems to work for me, what issue do you get?

No issues, I just wanted to know if I could have something with uscan which 
work out of the box with both URL's.
So I would like something without the comment / uncomment trick.

Cheers

Re: watch file with multiple download url

[Paul Wise]

On Mon, Jan 16, 2017 at 5:34 PM, PICCA Frederic-Emmanuel wrote:

> Here my current watch content where I comment and uncomment the URL.

Just uncommenting both seems to work for me, what issue do you get?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

watch file with multiple download url

[PICCA Frederic-Emmanuel]

Hello,

for one of my package, I need to check at two location for new upstream release.
the official release are usually located on sourceforge.

but rc's are usually provided via their internal ftp.

This is important for me to be able to prepare experimental upload of the rc's.
so I would like to let uscan check the two location and download the newest 
from the right URL.

Is it possible with uscan ?

Here my current watch content where I comment and uncomment the URL.

version=4
#opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \
# 
http://sf.net/tango-cs/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate
opts=dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1 \
 
ftp://ftp.esrf.eu/pub/cs/tango/tango-(\d\S*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate


Cheers

Frederic