Re: sbuild “Failed to fetch source files”

[Johannes Schauer]

Hi,

Quoting Ben Finney (2016-04-21 04:17:02)
> I am using ‘sbuild(1)’ successfully for some packages. For one package,
> though, I'm getting an error I don't understand: The source package is not
> found by Sbuild.
> 
> One version finds the source package correctly:
> 
> =
> +==+
> | python-coverage 3.7.1+dfsg.1-1 (amd64) 21 Apr 2016 
> 11:29 |
> +==+
> 
> Package: python-coverage
> Version: 3.7.1+dfsg.1-1
> Source Version: 3.7.1+dfsg.1-1
> […]
> 
> +--+
> | Fetch source files  
>  |
> +--+
> 
> 
> Local sources
> -
> 
> /home/bignose/Projects/debian/python-coverage/build-area/python-coverage/python-coverage_3.7.1+dfsg.1-1.dsc
>  exists in 
> /home/bignose/Projects/debian/python-coverage/build-area/python-coverage; 
> copying to chroot
> […]
> =
> 
> 
> When I try another version, Sbuild apparently can't find the source package:
> 
> =
> +==+
> | ./python-coverage 4.0.3+dfsg.1-1 (amd64)   21 Apr 2016 
> 11:10 |
> +==+
> 
> Package: ./python-coverage
> Version: 4.0.3+dfsg.1-1
> Source Version: 4.0.3+dfsg.1-1
> […]
> 
> +--+
> | Fetch source files  
>  |
> +--+
> 
> 
> Check APT
> -
> 
> Checking available source versions...
> W: Unable to locate package ./python-coverage
> apt-cache returned no information about ./python-coverage source
> Are there any deb-src lines in your /etc/apt/sources.list?
> […]
> =
> 
> Why does it need to check APT, when the source package is all local to
> the source control file?

could you show us the exact sbuild invocation you used in each of the above two
cases?

Thanks!

cheers, josch


signature.asc
Description: signature

sbuild “Failed to fetch source files”

[Ben Finney]

Howdy all,

I am using ‘sbuild(1)’ successfully for some packages. For one package,
though, I'm getting an error I don't understand: The source package is
not found by Sbuild.

One version finds the source package correctly:

=
+==+
| python-coverage 3.7.1+dfsg.1-1 (amd64) 21 Apr 2016 11:29 |
+==+

Package: python-coverage
Version: 3.7.1+dfsg.1-1
Source Version: 3.7.1+dfsg.1-1
[…]

+--+
| Fetch source files   |
+--+


Local sources
-

/home/bignose/Projects/debian/python-coverage/build-area/python-coverage/python-coverage_3.7.1+dfsg.1-1.dsc
 exists in 
/home/bignose/Projects/debian/python-coverage/build-area/python-coverage; 
copying to chroot
[…]
=


When I try another version, Sbuild apparently can't find the source package:

=
+==+
| ./python-coverage 4.0.3+dfsg.1-1 (amd64)   21 Apr 2016 11:10 |
+==+

Package: ./python-coverage
Version: 4.0.3+dfsg.1-1
Source Version: 4.0.3+dfsg.1-1
[…]

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...
W: Unable to locate package ./python-coverage
apt-cache returned no information about ./python-coverage source
Are there any deb-src lines in your /etc/apt/sources.list?
[…]
=

Why does it need to check APT, when the source package is all local to
the source control file?

Both source packages extract just fine:

=
$ outdir=$(mktemp -t -d)
$ package_name=python-coverage

$ package_version=3.7.1+dfsg.1-1
$ dpkg-source --extract 
../build-area/${package_name}/${package_name}_${package_version}.dsc 
$outdir/${package_name}-${package_version}/
dpkg-source: warning: extracting unsigned source package 
(../build-area/python-coverage/python-coverage_3.7.1+dfsg.1-1.dsc)
dpkg-source: info: extracting python-coverage in 
/tmp/tmp.XbUdOVqBzy/python-coverage-3.7.1+dfsg.1-1
dpkg-source: info: unpacking python-coverage_3.7.1+dfsg.1.orig.tar.gz
dpkg-source: info: unpacking python-coverage_3.7.1+dfsg.1-1.debian.tar.xz
dpkg-source: info: applying 01.omit-resource-files-from-distutils-setup.patch
dpkg-source: info: applying 02.rename-public-programs.patch

$ package_version=4.0.3+dfsg.1-1
$ dpkg-source --extract 
../build-area/${package_name}/${package_name}_${package_version}.dsc 
$outdir/${package_name}-${package_version}/
dpkg-source: warning: extracting unsigned source package 
(../build-area/python-coverage/python-coverage_4.0.3+dfsg.1-1.dsc)
dpkg-source: info: extracting python-coverage in 
/tmp/tmp.XbUdOVqBzy/python-coverage-4.0.3+dfsg.1-1
dpkg-source: info: unpacking python-coverage_4.0.3+dfsg.1.orig.tar.gz
dpkg-source: info: unpacking python-coverage_4.0.3+dfsg.1-1.debian.tar.xz
dpkg-source: info: applying 01.omit-resource-files-from-distutils-setup.patch
dpkg-source: info: applying 02.rename-public-programs.patch
=

So if both source packages are readily useable from the same location as
the source control file, why does only one of them work within the
Sbuild run?

-- 
 \  “Compulsory unification of opinion achieves only the unanimity |
  `\of the graveyard.” —Justice Roberts in 319 U.S. 624 (1943) |
_o__)  |
Ben Finney

Re: Seeking Sponsors for my package - roadfighter

[Paul Wise]

On Wed, 2016-04-20 at 07:19 -0300, Carlos Donizete Froes wrote:

> I need to solve part of the lintian, someone help me?

You will need to tell us what you need help with before we can help.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

[Nicholas D Steeves]

On 20 April 2016 at 18:33, James Cowgill  wrote:
>> "if [ -x /usr/sbin/update-initramfs ] && [ -e 
>> /etc/initramfs-tools/initramfs.conf ]"
>
> I don't think there's anything particularly wrong with that line.
>
> The previous attempts at fixing this (using 'hash' and 'command -v')
> are both bashisms so they shouldn't be used.
>
> If you really want to fix the lintian warning, using 'which' is
> probably the best idea here since it's an essential executable, not a
> shell builtin.
>
> if which update-initramfs > /dev/null 2>&1 && [ -e 
> /etc/initramfs-tools/initramfs.conf ]

My first instinct was to use `which command`, which is what I
generally use, but because this was official Debian work I read up on
which vs hash vs command -v.  What I found was that `which` has
undefined exit values from xNIX to yNIX, and is apparently considered
bad style by some people.  Hash was the oldest posix-correct way to do
it, using a shell internal function.  In this case, I think it broke
on piuparts because piuparts used bash; so I think this was an dashism
rather than a bashism ;-)

That's why I eventually settled on command -v, because "POSIX shells
users have command -v" (
http://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then
).

> Also see:
> https://www.debian.org/doc/manuals/developers-reference/ch06.html#bpp-debian-maint-scripts
> https://lintian.debian.org/tags/command-with-path-in-maintainer-script.html

Yes, I read this for my initial upload.  When Gianfranco's requested
fixing piupart's warning I inferred that the manual was out of date
relative to the current/sid standard that piupart was checking for.

On 20 April 2016 at 17:24, Gianfranco Costamagna
 wrote:
> Hi,
> you missed the change on postrm, and BTW I think this is out of the NMU 
> scope, can we please leave the change
> out?
> I'm not too confident about it, I would like to just rename the package and 
> let xnox give his opinion on
> the postinst and postrm scripts.

Thank you, I would be happy to!  Honestly, changing the postinst and
postrm scripts make me feel like I was walking the "package hijack"
line...uncomfortable.  Needless to say, what I've learned is that I
definitely need to get sbuild setup with automatic lintian and
piuparts checks to get it right on the first upload.  All apprentices
are started with repetitive tasks until they master precision while
working quickly, and sometimes the mentor throws in challenges 'just
to test the apprentice's problem solving skills.  I figured this was
something like that.  I've reuploaded to the same location, with a
postrm fix.  Here is the patch to restore "if [ -x
/usr/sbin/update-initramfs ]" if you prefer the xnox's original:

diff -ur ./debian/btrfs-progs.postinst
../btrfs-progs-4.4.1-static_path/debian/btrfs-progs.postinst
--- ./debian/btrfs-progs.postinst   2016-04-15 15:48:08.0 -0400
+++ ../btrfs-progs-4.4.1-static_path/debian/btrfs-progs.postinst
 2016-04-20 19:21:38.921718780 -0400
@@ -4,7 +4,7 @@

 case "${1}" in
configure)
-   if [ -x `command -v update-initramfs` ] && [ -e
/etc/initramfs-tools/initramfs.conf ]
+   if [ -x /usr/sbin/update-initramfs ] && [ -e
/etc/initramfs-tools/initramfs.conf ]
then
update-initramfs -u
fi
diff -ur ./debian/btrfs-progs.postrm
../btrfs-progs-4.4.1-static_path/debian/btrfs-progs.postrm
--- ./debian/btrfs-progs.postrm 2016-04-20 19:20:06.649840857 -0400
+++ ../btrfs-progs-4.4.1-static_path/debian/btrfs-progs.postrm
2016-04-20 19:21:58.049693561 -0400
@@ -4,7 +4,7 @@

 case "${1}" in
remove)
-   if [ -x `command -v update-initramfs` ] && [ -e
/etc/initramfs-tools/initramfs.conf ]
+   if [ -x /usr/sbin/update-initramfs ] && [ -e
/etc/initramfs-tools/initramfs.conf ]
then
update-initramfs -u
fi
diff -ur ./debian/changelog ../btrfs-progs-4.4.1-static_path/debian/changelog
--- ./debian/changelog  2016-04-20 19:18:09.337997103 -0400
+++ ../btrfs-progs-4.4.1-static_path/debian/changelog   2016-04-20
19:22:16.621669102 -0400
@@ -6,7 +6,6 @@
   * Update standards version to 3.9.7 (no changes needed).
   * debian/control: Add "Breaks" per Gianfranco Costamagna's suggestion
   * Change lintian override to reflect package rename
-  * Address lintian error "command-with-path" in postinst and postrm scripts

  -- Nicholas D Steeves   Fri, 15 Apr 2016 15:48:37 -0400

Cheers,
Nicholas

Re: Uncertain ABI with libags and GSequencer

[James Cowgill]

Hi,

On Wed, 2016-04-20 at 22:46 +0200, Joël Krähemann wrote:
> I'm the developer of Advanced Gtk+ Sequencer or for short gsequencer.
> Now I would like to provide following libraries in a non-standard
> location like /usr/share/gsequencer.
> 
> * libags
> * libags-thread
> * libags-server
> * libags-audio
> * libags-gui
> * libgsequencer
> 
> I think that libgtk-2.0 initially did the same in its early years
> about 15 years ago. Are there any documents or guidelines to provide
> libraries for debian GNU/Linux? And what if I can't guarantee ABI
> conformance, yet?

Firstly, you should use /usr/lib/gsequencer as the proper place to put
private libraries. /usr/share is for arch-independent files only.

As long as they're private, you can do pretty much what you want with
your libraries. Other Debian packages must not use them however.
Breaking the ABI is also not an issue (for Debian at least).

If you ever want to move them into a public directory you would need to
give them a proper SONAME and make sure the ABI isn't broken regularly.

> What about providing static linked GSequencer since I use it to debug
> the application?

Are you talking about fully statically linked (including static libc
etc) or just statically link against your libraries?

Using static libc is not allowed except in special circumstances. If
it's just your private libraries then you are free to do that if you
want. Is it totally nessesary though? Why can't you debug your
application when it isn't statically linked? Is such a package actually
useful to other people?

James

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

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

[James Cowgill]

On Wed, 2016-04-20 at 21:24 +, Gianfranco Costamagna wrote:
> Hi,
> you missed the change on postrm, and BTW I think this is out of the
> NMU scope, can we please leave the change
> out?
> I'm not too confident about it, I would like to just rename the
> package and let xnox give his opinion on
> the postinst and postrm scripts.
> 
> maybe somebody on -mentors can give an opinion about what is wrong
> with this line
> "if [ -x /usr/sbin/update-initramfs ] && [ -e 
> /etc/initramfs-tools/initramfs.conf ]"

I don't think there's anything particularly wrong with that line.

Thr previous attempts at fixing this (using 'hash' and 'command -v')
are both bashisms so they shouldn't be used.

If you really want to fix the lintian warning, using 'which' is
probably the best idea here since it's an essential executable, not a
shell builtin.

if which update-initramfs > /dev/null 2>&1 && [ -e 
/etc/initramfs-tools/initramfs.conf ]

Also see:
https://www.debian.org/doc/manuals/developers-reference/ch06.html#bpp-debian-maint-scripts
https://lintian.debian.org/tags/command-with-path-in-maintainer-script.html

James

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

Re: RFS: setop/0.1-1 [ITP]

[Gianfranco Costamagna]

Hi,

>First of all thank you very much for taking care of me. I had already 
>given up and left setop behind me.

lets recover :)

>Is it this one?
>
>I exactly followed all instructions from 
> and/or 
> and still don’t know, where my 
>mistake was.

not sure, I don't know why a new bug hasn't been opened.

BTW there should be two bugs, not a single one, and there are automatic
scripts that correlates them by blocking the ITP by the RFS one.

can you please try again?

>In summary – you probably hear that often – it is very difficult for a 
>newbie to make everything right. Moreover, I think there are mistakes in 
>some guides that lead to errors.

if you find mistakes... well, correct them please :)

>Omitting -O3 yields in making a debug version (equal to -O0) on my 
>system. By default, the make file shall produce a release build, and by 
>testing I found out that O2 and O3 are best compared to the alternatives 
>(e. g. Os).
>Ok?

no.
man dh_strip
(snip)

you have to produce debug builds with -g and so on.

dh_strip extracts the symbols from the binaries, producing a debug-symbols-free 
binary

>I don’t understand what you mean by that.

BIN=foo means nobody can change that

BIN?=foo means "assign foo if nothing else is already defined"

in fact, it means:
export BIN=bar in rules
has the effect to have a BIN=bar in the build.

Same for HELP

and LIBS
(in this case)
LIBS+="-lfoo -lbar"

even if this case (LIBS) is really a corner case, so nevermind

>You’re correct, I meant libboost-dev.

ok

>public domain

it was fine
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

just be sure to mention it correctly on the copyright file
https://codesearch.debian.net/results/License%3A%20unlicense/page_0

(sorry, my fault)


>You should check it. It’s taken from /watch#GitHub>, but mentors.debian.net says it doesn’t work.

uscan --debug doesn't work too.
Probably you have to git tag v0.1 and git push --tags?
it is failing to parse the html, not having releases there might be the reason.

I'll leave checking this to you.

Bests,

Gianfranco

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

[Gianfranco Costamagna]

Hi,
you missed the change on postrm, and BTW I think this is out of the NMU scope, 
can we please leave the change
out?
I'm not too confident about it, I would like to just rename the package and let 
xnox give his opinion on
the postinst and postrm scripts.

maybe somebody on -mentors can give an opinion about what is wrong with this 
line
"if [ -x /usr/sbin/update-initramfs ] && [ -e 
/etc/initramfs-tools/initramfs.conf ]"

sorry!

Gianfranco





Il Venerdì 15 Aprile 2016 22:03, Nicholas D Steeves  ha 
scritto:
On 15 April 2016 at 09:25, Gianfranco Costamagna

 wrote:
> also some issues might be fixed in a later release
>
> http://debomatic-amd64.debian.net/distribution#unstable/btrfs-progs/4.4.1-1.1/lintian
>
> I: btrfs-progs source: duplicate-short-description btrfs-tools btrfs-tools-dbg
> I: btrfs-progs source: duplicate-long-description btrfs-tools btrfs-tools-dbg
> W: btrfs-progs source: dbg-package-missing-depends btrfs-tools-dbg
>
> and take care of piuparts
> http://debomatic-amd64.debian.net/distribution#unstable/btrfs-progs/4.4.1-1.1/piuparts
>
>   /var/lib/dpkg/info/btrfs-progs.postinst: 7: hash: update-initramfs: not 
> found

P.S. I've reuploaded a package to mentors that uses command -v instead
of hash.  It should be available at the same URL as before, as soon as
mentors finishes building it.

Uncertain ABI with libags and GSequencer

[Joël Krähemann]

Hello everybody

I'm the developer of Advanced Gtk+ Sequencer or for short gsequencer.
Now I would like to provide following libraries in a non-standard
location like /usr/share/gsequencer.

* libags
* libags-thread
* libags-server
* libags-audio
* libags-gui
* libgsequencer

I think that libgtk-2.0 initially did the same in its early years
about 15 years ago. Are there any documents or guidelines to provide
libraries for debian GNU/Linux? And what if I can't guarantee ABI
conformance, yet? What about providing static linked GSequencer since
I use it to debug the application?


To get a brief overview of the API visit:

http://gsequencer.org/api/ags/

http://gsequencer.org
https://tracker.debian.org/pkg/gsequencer

thank you all.

best regards,
Joël Krähemann

Bug#820733: Package Series

[Giorgio Sartore]

Hi Gianfranco,
here I am again. As you can see on 
http://mentors.debian.net/package/series I fixed all the issues in my 
package.


You told me to come back when I have a larger userbase, so I created my 
own repository for Ubuntu: ppa:mani-ddev/series. You can download and 
install my program for Ubuntu Trusty and Wily.
I also committed the first release on my git 
(https://github.com/Mani-GS/series), added a homepage 
(http://mani-gs.github.io/series/) and removed binaries.


Now I was thinking to create a click package and upload it on the Ubuntu 
Software Center, just to let people download it and make grow the 
userbase. Is it a good idea?
I'm working hard on this little project and I hope that one day it will 
be published on Debian :)


Thanks for your invaluable help.

Best regards,
Giorgio

Il 13/04/2016 11:59, Gianfranco Costamagna ha scritto:

Hi again,

stuff to do:

fix lintian, make a real copyright file, fix flags, fix useless files, convert 
the format to quilt...

come back if you don't know how to fix issues, when you have a larger userbase, 
and when you learn how
to tag release, remove useless stuff and *not* commit binaries on git :)


and the package has to build on a clean pbuilder/sbuild environment


there is a lot of work to do here!
(I suggest you to go on irc oftc and ask on -mentors, or click on the link on 
mentors website, each
lintian warning has an explanation that helps in fixing it)


cheers,

G.

Bug#821837: marked as done (RFS: openresolv/3.8.0-1 [ITA] - - management framework for resolv.conf)

[Debian Bug Tracking System]

Your message dated Wed, 20 Apr 2016 18:53:50 + (UTC)
with message-id <519206876.6643963.1461178430845.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#821837: RFS: openresolv/3.8.0-1 [ITA] - - management 
framework for resolv.conf
has caused the Debian Bug report #821837,
regarding RFS: openresolv/3.8.0-1 [ITA] - - management framework for resolv.conf
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.)


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

Dear mentors,

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

 * Package name: openresolv
   Version : 3.8.0-1
   Upstream Author : Roy Marples 
 * URL : http://roy.marples.name/projects/openresolv/home
 * License : BSD-2-clause
   Section : net

  It builds those binary packages:

openresolv - management framework for resolv.conf

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

  http://mentors.debian.net/package/openresolv


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

dget -x 
http://mentors.debian.net/debian/pool/main/o/openresolv/openresolv_3.8.0-1.dsc

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

  Changes since the last upload:

* New upstream release
- Fix doesn't work with multiple domains in search,
  they are concatenated. (Closes: #817841)
  * New Maintainer (Closes: #770083)
  * d/patches
- Update resolvconf.8.in-spell
  * d/copyright
- Update copyright



  Regards,
   J.S.Júnior


signature.asc
Description: Message signed with OpenPGP using GPGMail
--- End Message ---
--- Begin Message ---
Happily sponsored! thanks for your contribution to Debian!

cheers,

G.





Il Martedì 19 Aprile 2016 19:36, Junior Santos  ha scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: openresolv
   Version : 3.8.0-1
   Upstream Author : Roy Marples 
* URL : http://roy.marples.name/projects/openresolv/home
* License : BSD-2-clause
   Section : net

  It builds those binary packages:

openresolv - management framework for resolv.conf

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

  http://mentors.debian.net/package/openresolv


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

dget -x 
http://mentors.debian.net/debian/pool/main/o/openresolv/openresolv_3.8.0-1.dsc

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

  Changes since the last upload:

* New upstream release
- Fix doesn't work with multiple domains in search,
  they are concatenated. (Closes: #817841)
  * New Maintainer (Closes: #770083)
  * d/patches
- Update resolvconf.8.in-spell
  * d/copyright
- Update copyright



  Regards,
   J.S.Júnior--- End Message ---

Bug#817949: marked as done (RFS: niceshaper/1.2.2-2 [ITP] -- Dynamic Traffic Shaper)

[Debian Bug Tracking System]

Your message dated Wed, 20 Apr 2016 18:49:51 + (UTC)
with message-id <13102776.6753476.1461178191977.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#817949: RFS: niceshaper/1.2.2-1 [ITP]
has caused the Debian Bug report #817949,
regarding RFS: niceshaper/1.2.2-2 [ITP] -- Dynamic Traffic Shaper
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.)


-- 
817949: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817949
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: niceshaper
  Version : 1.2.0-1
  Upstream Author : Mariusz Jedwabny 
* URL : http://niceshaper.jedwabny.net
* License : GPL-2
  Section : net

It builds those binary packages:

  niceshaper - Dynamic Traffic Shaper

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

  http://mentors.debian.net/package/niceshaper


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

  dget -x 
http://mentors.debian.net/debian/pool/main/n/niceshaper/niceshaper_1.2.0-1.dsc

More information about niceshaper can be obtained from 
http://niceshaper.jedwabny.net.

Changes since the last upload:

niceshaper (1.2.0-1) unstable; urgency=low

  * New upstream release.

 -- Mariusz Jedwabny   Wed, 09 Mar 2016 20:35:56 +


Regards,
 Mariusz Jedwabny
--- End Message ---
--- Begin Message ---
Hi,

>I've just uploaded 1.2.2-2 version.


just wrong.

one single entry means a single line with 1.2.2-1 and "initial release closes: 
#xxx"
(I did that and attached the debian directory to this email)


I also enabled hardening stuff on rules and sponsored the package :)

>to inform that these are licensed under GPL-2+
>and who are the authors.


fine for me.

the files are license-compatible with your sources.

thanks for your contribution to Debian!

BTW there is an empty /var/lib/niceshaper, but according to main
./src/main.cc:std::string vardir = "/var/lib/niceshaper";

it seems used somewhere, so I didn't bother for this
(used a runtime? maybe better use tmp for temporary files?)

(BTW I uploaded on deferred/1, this means you have 24 hours to ask me
to delete the upload in case you don't want my changes in)


cheers,

G.

niceshaper_1.2.2-1.debian.tar.xz
Description: application/xz
--- End Message ---

Bug#814550: marked as done (RFS: codecrypt/1.7.4-1 (ITP #814462))

[Debian Bug Tracking System]

Your message dated Wed, 20 Apr 2016 18:30:36 + (UTC)
with message-id <1642172381.6606122.1461177036634.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#814550: RFS: codecrypt/1.7.3-1 (ITP #814462)
has caused the Debian Bug report #814550,
regarding RFS: codecrypt/1.7.4-1 (ITP #814462)
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.)


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

Dear mentors,

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

 * Package name: codecrypt
   Version : 1.7.3-1
   Upstream Author : Mirek Kratochvil 
 * URL : https://github.com/exaexa/codecrypt
 * License : LGPL3
   Section : utils

It builds those binary packages:

  codecrypt  - post-quantum encryption&signing tool

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

  http://mentors.debian.net/package/codecrypt


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

  dget -x 
http://mentors.debian.net/debian/pool/main/c/codecrypt/codecrypt_1.7.3-1.dsc


More information about codecrypt can be obtained from the quick README on the
GitHub page (see URL). The software is a simplified post-quantum-only workalike
of GnuPG, useful mainly for working with some non-mainstream and non-RSA crypto
in a human-friendly way. Debianization process is watched in github issue #10.


With regards,
 Mirek Kratochvil
--- End Message ---
--- Begin Message ---
Hi,



I did sponsor the package, after changing the rules file
(removed uncommented stuff, added harderning stuff, new tarball attached)

some nitpicks.
the tool is called codecrypt, and the binary ccr.

How do you expect users to find it?


another issue: the binary is ~500k

how do you feel about having a libcodecryptfoo and link it to the binary?
does it sound good to you?

anyway, thanks for your contribution to Debian!

cheers,

Gianfranco

Il Domenica 17 Aprile 2016 16:57, Miroslav Kratochvil  ha 
scritto:



Thanks a lot for the review, I've fixed the license issues, libs and build 
deps. New uploaded version should appear on mentors in no time.

The code with `make dist' and `mk-orig-source' is a fossil from first packaging 
attempt (trying to get both GBP and development in one repo). Now the package 
repo is a separate, "completely normal" gbp with import-orig's here: 
https://github.com/exaexa/codecrypt-debian (relevant discussion can be found on 
pkg-privacy ML on alioth).


Best regards and thanks again.


-mk


On Mon, 4 Apr 2016 at 21:05 Gianfranco Costamagna  
wrote:

control: owner -1 !
>control: tags -1 moreinfo
>
>Hi, lets review:
>
>control:
>autotools-dev, dh-autoreconf,
>
>I think autoreconf alone should be enough.
>
>libgmp10, libcrypto++9v5, libfftw3-double3
>
>on noes! shlibs:Depends should do that automatically. If not, it means your 
>binaries are not
>linking correctly the library from the development package in 
>build-dependencies.
>
>Please remove and test a built deb file under section debian/control to see 
>how they were substituted.
>
>copyright: license is wrong.
>(licensecheck is a good help)
>
>
>rules:
>$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM).tar.gz:
>$(MAKE) dist
>
>.PHONY: mk-orig-source
>mk-orig-source: $(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM).tar.gz
>ln -f "$<" ../$(DEB_SOURCE)_$(DEB_VERSION_UPSTREAM).orig.tar.gz
>
>
>why? you already use uscan and uupdate to download the tarball, why is the 
>above code useful?
>
>other stuff LGTM
>
>cheers
>G.
>
>


codecrypt_1.7.4-1.debian.tar.xz
Description: application/xz
--- End Message ---

Bug#818974: packaging

[Gianfranco Costamagna]

Hi, quick answer:
thanks for the fixes.


some quick issues:
copyright is missing the copyright text 
(look e.g. hedgewars package to see a some licenses to copy-paste)

Depends: is for runtime dependencies, having a -dev here is just wrong.
please let shlibs:Depends do its job, and probably if it fails it is because no 
libraries are currently using the libraries?



I see you have some dlopens, in that case you might want to runtime depends on 
the runtime libraries
(and do source uploads at each soname bump)

SIGH.

gedit license:
(snip)
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

(snip)

you seem to be GPL-2+ on your software.

still don't see changes, e.g. source/format and so on
debian/files is useless.

it is all for now, I'll try again when you fix the above.

cheers,

G.


Il Mercoledì 20 Aprile 2016 15:00, Roderick MacKenzie 
 ha scritto:
control: tags -1

Hi All,

  Thanks for all the comments.  Sorry for the delay in responding, I
realized that it would be much better if the code built using
autotools - rather than my random build system.  So, I swapped out the
build system for autotools, this took quite a while.  The old build
system also autogenerated some .c/.h files that I thought was not a
nice thing to do, I think also the debian build system complained
about this.  So I rewrote the plugin system to avoid having to do this
- this also required significant changes to the code – which also took
time.  Below I’ve indicated how I’ve addressed each comment, given on
the thread above.  I also got some comments from IRC, which I’ve put
right at the bottom of the post.  I have indicated comments with a
“Q:” and my answers with an “A:”

A new copy of the deb files can be downloaded from:

https://github.com/roderickmackenzie/gpvdm/releases/tag/gpvdm-4.42

Happy to make more changes if needed,

Rod



Q: $ find -type f \( -iname '*.sh' -o -iname '*.bash' \) -exec bashate
--ignore E002,E003 {} +
E010: Do not on same line as for: 'for i in `find -type f` ; do md5sum
$i; done >list.dat'
- ./update.sh : L23
E001: Trailing Whitespace: 'mkdir ${rpmdir} '
- ./make_rpm.sh : L33
E001: Trailing Whitespace: 'cd ${rpmdir} '
- ./make_rpm.sh : L34
E010: Do not on same line as for: 'for i in `find|grep -v .git|grep -v
.o$|grep -v ~$|grep -v materials|grep -v dll$|grep -v .so$`'
- ./to_github.sh : L123
4 bashate error(s) found


A:I’ve fixed this now and the command gives no errors.

Q: # Check with upstream where the GIMP XCF source files are.
$ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg'
-o -iname '*.jpeg' \) -exec grep -iF gimp {} +
Binary file ./images/image.jpg matches
Binary file ./images/icon.png matches
Binary file ./images/splash.png matches

# Check with upstream where the Inkscape SVG source files are.
$ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg'
-o -iname '*.jpeg' \) -exec grep -iF inkscape {} +
Binary file ./images/dir_file.png matches
Binary file ./images/book.png matches
Binary file ./images/play.png matches
...
A: All inkscape svg files used by the code are now there in the
./images/ directory, and the build system generates the pngs from the
svg files. Three png files did not play nice with rsvg, so I just ship
the svg and png files together and don’t let the build system generate
them. I don’t have the XCF files for the jpgs, I don’t think I ever
saved them.


Q: $ find -type f -iname '*.sh' -exec checkbashisms {} +
could not find any possible bashisms in bash script ./clean_all.sh
could not find any possible bashisms in bash script ./update.sh
could not find any possible bashisms in bash script ./winpub.sh
could not find any possible bashisms in bash script ./buildplugins.sh
could not find any possible bashisms in bash script ./make_rpm.sh
could not find any possible bashisms in bash script ./get_elec_plugins.sh
A: Fixed, no errors are given anymore.


Q: cme check dpkg
...
Warning in 'control source Standards-Version' value '3.9.6': Current
standards version is 3.9.7
File debian/copyright line 1 has a syntax error:
DpkgSyntax error: Invalid line (missing ':' ?) : Copyright
2015 Roderick Charles Ian MacKenzie 
A: Fixed, no errors are given.


Q: $ codespell --quiet-level=3
/inp.c:577: compatability  ==> compatibility
/dump_dynamic.c:399: efficency  ==> efficiency
/makefile:17: inital  ==> initial
/LICENSE:169: publically  ==> publicly
/make_rpm.sh:159: automaticly  ==> automatically
/make_rpm.sh:205: intergration  ==> integration
/gui/update.py:101: forbiden  ==> forbidden
/gui/update.py:145: avaliable  ==> available
/gui/copying.py:48: nTo  ==> not  | disable due to \n
/gui/listen_for_files_on_network.py:70: recived  ==> received
/gui/cmp_class.py:234: extention  ==> extension
/gui/qe.py:234: Efficency  ==> Efficiency
/solvers/newton_norm/newton.c:1470: propper  ==> proper
/solvers/newton/newton.c:1572: propper  ==

Bug#818921: marked as done (RFS: python-neovim-gui/0.1.1-1 [ITP])

[Debian Bug Tracking System]

Your message dated Wed, 20 Apr 2016 16:14:22 + (UTC)
with message-id <1135144354.1254435.1461168862094.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]
has caused the Debian Bug report #818921,
regarding RFS: python-neovim-gui/0.1.1-1 [ITP]
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.)


-- 
818921: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818921
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-neovim-gui"

* Package name: python-neovim-gui
  Version : 0.1.1
  Upstream Author : Thiago de Arruda 
* URL : https://github.com/neovim/python-gui
* License : Apache 2.0
  Section : editors
  Description : Simple nvim gui implemented using Gtk

It builds this binary package:
   python3-neovim-gui - Simple nvim gui implemented using Gtk (Python 3)

I intend to maintain it under the DPMT umbrella, which I am part of.

To access further information about this package, please visit the following 
URL:
   https://anonscm.debian.org/cgit/python-modules/packages/python-neovim-gui.git


Regards,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
done :)





Il Mercoledì 20 Aprile 2016 17:48, Víctor Cuadrado Juan  ha 
scritto:
tags 818921 - moreinfo
thanks

On Wed, 13 Apr 2016 15:06:21 + (UTC) Gianfranco Costamagna
 wrote:
> 
> >> please add them as build-dependencies and check that python3:Depends do 
> >> its job
> >
> >Fixed.
> >* Added neovim check.
> >* python3-click is only present on testing and unstable as 6.2, I have
> >   added the check but it could be dropped.
> >* pygobject is provided by python3-gi-cairo, python3-cairo,
> >   gir1.2-gtk-3.0 as jpleau and I tracked down [2][3].
> 
> 
> no. You need to add them to build-dependencies, remove them from 
> runtime-dependencies and
> verify python3:Depends is actually adding them. (by opening the built deb 
> file and checking the debian/control inside).
>
> install_requires is parsed during build, and information is extracted and 
> converted in needed runtime
> Debian packages.
> (feel free to keep them in both build-dependencies and runtime-dependencies 
> if the version is not correctly parsed)
> (see borgbackup git history of debian/control file)

That's indeed the case, the version doesn't get parsed. I have left them
in Depends.


> is it more a module or an application?
> I guess an application, so maybe the applications team is more
> appropriate
> you cant do something like
> python3
> import neovim-gui, right?

It ships things on /usr/lib/python3/dist-packages/, so it's a module
with a script then.


> pynvim
> Traceback (most recent call last):
> File "/usr/bin/pynvim", line 5, in 
> from pkg_resources import load_entry_point
> ImportError: No module named 'pkg_resources'


Fixed.


I have removed the moreinfo tag, ready for a RFS.

Thanks in advance :)

Cheers,


-- 
Víctor Cuadrado Juan  m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.--- End Message ---

Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]

[Víctor Cuadrado Juan]

tags 818921 - moreinfo
thanks

On Wed, 13 Apr 2016 15:06:21 + (UTC) Gianfranco Costamagna
 wrote:
> 
> >> please add them as build-dependencies and check that python3:Depends do 
> >> its job
> >
> >Fixed.
> >* Added neovim check.
> >* python3-click is only present on testing and unstable as 6.2, I have
> >   added the check but it could be dropped.
> >* pygobject is provided by python3-gi-cairo, python3-cairo,
> >   gir1.2-gtk-3.0 as jpleau and I tracked down [2][3].
> 
> 
> no. You need to add them to build-dependencies, remove them from 
> runtime-dependencies and
> verify python3:Depends is actually adding them. (by opening the built deb 
> file and checking the debian/control inside).
>
> install_requires is parsed during build, and information is extracted and 
> converted in needed runtime
> Debian packages.
> (feel free to keep them in both build-dependencies and runtime-dependencies 
> if the version is not correctly parsed)
> (see borgbackup git history of debian/control file)

That's indeed the case, the version doesn't get parsed. I have left them
in Depends.


> is it more a module or an application?
> I guess an application, so maybe the applications team is more
> appropriate
> you cant do something like
> python3
> import neovim-gui, right?

It ships things on /usr/lib/python3/dist-packages/, so it's a module
with a script then.


> pynvim
> Traceback (most recent call last):
> File "/usr/bin/pynvim", line 5, in 
> from pkg_resources import load_entry_point
> ImportError: No module named 'pkg_resources'

Fixed.


I have removed the moreinfo tag, ready for a RFS.

Thanks in advance :)

Cheers,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#818974: packaging

[Roderick MacKenzie]

control: tags -1

Hi All,

  Thanks for all the comments.  Sorry for the delay in responding, I
realized that it would be much better if the code built using
autotools - rather than my random build system.  So, I swapped out the
build system for autotools, this took quite a while.  The old build
system also autogenerated some .c/.h files that I thought was not a
nice thing to do, I think also the debian build system complained
about this.  So I rewrote the plugin system to avoid having to do this
- this also required significant changes to the code – which also took
time.  Below I’ve indicated how I’ve addressed each comment, given on
the thread above.  I also got some comments from IRC, which I’ve put
right at the bottom of the post.  I have indicated comments with a
“Q:” and my answers with an “A:”

A new copy of the deb files can be downloaded from:

https://github.com/roderickmackenzie/gpvdm/releases/tag/gpvdm-4.42

Happy to make more changes if needed,

Rod



Q: $ find -type f \( -iname '*.sh' -o -iname '*.bash' \) -exec bashate
--ignore E002,E003 {} +
E010: Do not on same line as for: 'for i in `find -type f` ; do md5sum
$i; done >list.dat'
 - ./update.sh : L23
E001: Trailing Whitespace: 'mkdir ${rpmdir} '
 - ./make_rpm.sh : L33
E001: Trailing Whitespace: 'cd ${rpmdir} '
 - ./make_rpm.sh : L34
E010: Do not on same line as for: 'for i in `find|grep -v .git|grep -v
.o$|grep -v ~$|grep -v materials|grep -v dll$|grep -v .so$`'
 - ./to_github.sh : L123
4 bashate error(s) found


A:I’ve fixed this now and the command gives no errors.

Q: # Check with upstream where the GIMP XCF source files are.
$ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg'
-o -iname '*.jpeg' \) -exec grep -iF gimp {} +
Binary file ./images/image.jpg matches
Binary file ./images/icon.png matches
Binary file ./images/splash.png matches

# Check with upstream where the Inkscape SVG source files are.
$ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg'
-o -iname '*.jpeg' \) -exec grep -iF inkscape {} +
Binary file ./images/dir_file.png matches
Binary file ./images/book.png matches
Binary file ./images/play.png matches
...
A: All inkscape svg files used by the code are now there in the
./images/ directory, and the build system generates the pngs from the
svg files. Three png files did not play nice with rsvg, so I just ship
the svg and png files together and don’t let the build system generate
them. I don’t have the XCF files for the jpgs, I don’t think I ever
saved them.


Q: $ find -type f -iname '*.sh' -exec checkbashisms {} +
could not find any possible bashisms in bash script ./clean_all.sh
could not find any possible bashisms in bash script ./update.sh
could not find any possible bashisms in bash script ./winpub.sh
could not find any possible bashisms in bash script ./buildplugins.sh
could not find any possible bashisms in bash script ./make_rpm.sh
could not find any possible bashisms in bash script ./get_elec_plugins.sh
A: Fixed, no errors are given anymore.


Q: cme check dpkg
...
Warning in 'control source Standards-Version' value '3.9.6': Current
standards version is 3.9.7
File debian/copyright line 1 has a syntax error:
DpkgSyntax error: Invalid line (missing ':' ?) : Copyright
2015 Roderick Charles Ian MacKenzie 
A: Fixed, no errors are given.


Q: $ codespell --quiet-level=3
/inp.c:577: compatability  ==> compatibility
/dump_dynamic.c:399: efficency  ==> efficiency
/makefile:17: inital  ==> initial
/LICENSE:169: publically  ==> publicly
/make_rpm.sh:159: automaticly  ==> automatically
/make_rpm.sh:205: intergration  ==> integration
/gui/update.py:101: forbiden  ==> forbidden
/gui/update.py:145: avaliable  ==> available
/gui/copying.py:48: nTo  ==> not  | disable due to \n
/gui/listen_for_files_on_network.py:70: recived  ==> received
/gui/cmp_class.py:234: extention  ==> extension
/gui/qe.py:234: Efficency  ==> Efficiency
/solvers/newton_norm/newton.c:1470: propper  ==> proper
/solvers/newton/newton.c:1572: propper  ==> proper
A: Fixed


Q: $ find -type f -iname '*.c' -exec complexity {} +

A: This seems to measure the complexity of the code.


Q: $ cppcheck -j1 --quiet -f .
[complex_solver.c:131]: (error) Common realloc mistake: 'x' nulled but
not freed upon failure
[complex_solver.c:132]: (error) Common realloc mistake: 'xz' nulled
but not freed upon failure
[complex_solver.c:133]: (error) Common realloc mistake: 'Ap' nulled
but not freed upon failure
[complex_solver.c:134]: (error) Common realloc mistake: 'Ai' nulled
but not freed upon failure


A: Fixed – now gives no output.

Q: $ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
/gui/gpvdm.desktop: error: line "   Name=gpvdm" starts with a
space. Comment, group and key-value lines should not start with a
space. The validation will continue, with the leading spaces ignored.
/gui/gpvdm.desktop: error: line "
Icon=/usr/share/gpvdm/gui/image.jpg" starts with a space. Comment,
group and key-value lines should not 

Bug#821907: RFS: fbless/0.2.3-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: fbless
  Version : 0.2.3-1
  Upstream Author : Con Radchenko 
* Url : https://github.com/matimatik/fbless
* Licenses: GPL-2+
  Section : text

It builds those binary packages:

fbless -- terminal fiction book reader

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

http://mentors.debian.net/package/fbless

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

http://mentors.debian.net/debian/pool/main/f/fbless/fbless_0.2.3-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/fbless.git

More information about fbless can be obtained from 
https://github.com/matimatik/fbless

Changes since last upload:

  * Initial release (Closes: #821903)

Regards,
  Dmitry Bogatov

Bug#821885: marked as done (RFS: flintqs/1.0-1 (RC #760193))

[Debian Bug Tracking System]

Your message dated Wed, 20 Apr 2016 10:18:49 + (UTC)
with message-id <343733720.6059011.1461147529623.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#821885: RFS: flintqs/1.0-1 (RC #760193)
has caused the Debian Bug report #821885,
regarding RFS: flintqs/1.0-1 (RC #760193)
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.)


-- 
821885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821885
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: flintqs
   Version : 1.0-1
   Upstream Author : William Hart
 * URL : https://github.com/sagemath/FlintQS
 * License : GPL-2+
   Section : math

  It builds those binary packages:

flintqs- Program using quadratic sieve to factor integers

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


  http://mentors.debian.net/package/flintqs


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

dget -x 
http://mentors.debian.net/debian/pool/main/f/flintqs/flintqs_1.0-1.dsc


  Changes since the last upload:
  * New upstream release. (Closes: #760193)
  * Point to new upstream repository.
  * Push standards-version up.
  * Simplify packaging as upstream now uses autotools.

Upstream changed their versioning scheme, this is really the latest.

  Regards,
   Julien Puydt
--- End Message ---
--- Begin Message ---
hi, done!



g.



Il Mercoledì 20 Aprile 2016 10:39, Julien Puydt  ha 
scritto:



Package: sponsorship-requests
Severity: important

Dear mentors,

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

  * Package name: flintqs
Version : 1.0-1
Upstream Author : William Hart
  * URL : https://github.com/sagemath/FlintQS
  * License : GPL-2+
Section : math

   It builds those binary packages:

 flintqs- Program using quadratic sieve to factor integers

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

  http://mentors.debian.net/package/flintqs


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

 dget -x 
http://mentors.debian.net/debian/pool/main/f/flintqs/flintqs_1.0-1.dsc

   Changes since the last upload:
   * New upstream release. (Closes: #760193)
   * Point to new upstream repository.
   * Push standards-version up.
   * Simplify packaging as upstream now uses autotools.

Upstream changed their versioning scheme, this is really the latest.

   Regards,
Julien Puydt--- End Message ---

Re: Seeking Sponsors for my package - roadfighter

[Carlos Donizete Froes]

Yes, I'm using quilt to make the changes in the upstream source.

I need to solve part of the lintian, someone help me?


Em Qua, 2016-04-20 às 12:32 +0800, Paul Wise escreveu:
> On Mon, 2016-04-18 at 01:15 -0300, Carlos Donizete Froes wrote:
> 
> > I would like to help in this case.
> 
> Only make changes by sending upstream patches and getting them to
> release new versions. If they don't respond you can include the patches
> in the debian/patches/ directory.
> 

-- 
Carlos Donizete Froes [a.k.a coringao]
- https://wiki.debian.org/coringao
GPG: 4096R/C325F557
EAD9 DDCB DC86 4561 7612  A34F A9CD 6C31 C325 F557


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

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Ben Finney  writes:

> I will merge the “common” files into the ‘colossal-cave-adventure’
> binary package.

This is now done, and the updated source package is available:

$ dget -x 
http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc

-- 
 \  “Not using Microsoft products is like being a non-smoker 40 or |
  `\ 50 years ago: You can choose not to smoke, yourself, but it's |
_o__)   hard to avoid second-hand smoke.” —Michael Tiemann |
Ben Finney 

Bug#821885: RFS: flintqs/1.0-1 (RC #760193)

[Julien Puydt]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: flintqs
   Version : 1.0-1
   Upstream Author : William Hart
 * URL : https://github.com/sagemath/FlintQS
 * License : GPL-2+
   Section : math

  It builds those binary packages:

flintqs- Program using quadratic sieve to factor integers

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


  http://mentors.debian.net/package/flintqs


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

dget -x 
http://mentors.debian.net/debian/pool/main/f/flintqs/flintqs_1.0-1.dsc


  Changes since the last upload:
  * New upstream release. (Closes: #760193)
  * Point to new upstream repository.
  * Push standards-version up.
  * Simplify packaging as upstream now uses autotools.

Upstream changed their versioning scheme, this is really the latest.

  Regards,
   Julien Puydt

Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]

[Tiago Ilieve]

Nicolas,

On 20 April 2016 at 03:49, Nicolas Dandrimont  wrote:
> Tiago, when replying to a RFS, please use the bug report rather than the
> mailing list.

Yeah, I've only noticed this after my last message in the thread. Now
I figured that this happened because I've replied his second message,
which hadn't the bug address in the "Reply-To:" header.

Thanks for the reminder.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Markus Koschany  writes:

> The rationale for providing multiple binary packages is that users
> should be able to install a subset of an application and save some
> disk space.

Another important rationale for splitting common files to a separate
binary package, is to avoid duplication and potential divergence.

> In this case they always have to install both packages because
> otherwise the game would be broken. It would be a different case if
> they already had a choice and could choose between different variants.

My intention was to enable existing and future implementations to have
the canonical data file available, without needing to deal with the
Python application.

> I wouldn't decline to upload but you should take this wall of text
> into consideration. In my opinion you can always split the package
> later when a potential port might require it.

Fair enough. I will merge the “common” files into the
‘colossal-cave-adventure’ binary package.

> Indeed they redirect all requests now. I don't know if that comes with
> a performance penalty though. I wonder why we need two fields,
> Vcs-Browser and Vcs-Git, if they are identical...

Because the meanings are different (one is for VCS operations on the
repo, one is for web-browser access to browse the repo). And commonly
they are not the same URL.

-- 
 \“I hate it when my foot falls asleep during the day, because |
  `\that means it's gonna be up all night.” —Steven Wright |
_o__)  |
Ben Finney

Re: Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]

[Pierre-Elliott Bécue]

Le mercredi 20 avril 2016 à 08:49:27+0200, Nicolas Dandrimont a écrit :
> Tiago, when replying to a RFS, please use the bug report rather than the
> mailing list.
> 
> * Tiago Ilieve  [2016-04-12 03:23:50 -0300]:
> 
> > > When I tried to dput I've been refused it because 1.4.0-1 was already on 
> > > the
> > > server. That's the only way I found. Maybe I did something wrong.
> > 
> > Maybe you uploaded again before mentors.d.n processed the first
> > upload? There's an waiting time ("How long will it take until my
> > upload is available to sponsors?" from its Q&A[5]) between the upload
> > and the package actually being available in there. I'm suggesting this
> > because mentors.d.n even store different versions of the package, even
> > when you did not bump its version. You can always use the delete
> > button from its web interface as well.
> 
> Please don't.
> 
> Pierre-Elliott, please post full error messages when you have an issue, not
> your interpretation of the message. You probably got tripped by the fact that
> dput leaves a .upload file along your .changes to avoid double uploads. You 
> can
> either remove the .upload file or use dput -f to bypass that check.
> 
> No need to bump the revision number (which might end you up forgetting to
> upload the original tarball) or removing the package from mentors.d.n (which
> will remove history).
> 
> Bye,

Oh, well, understood, I missed that.

Thanks for the hint, should I reupload the package with -1 version, after
fixing the changelog? From where I stand that looks awkward but I'm eager to
follow any suggestion.

-- 
PE


signature.asc
Description: PGP signature