Re: Build-Depends on source itself [libgap-sage]

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks for your prompt reply.

On 02/11/16 04:11, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:
> 
>> Let give a try. I am dealing with the libgap-sage package [1].
> 
> Thanks for the extensive details.


You are welcome. 
> 
>> To begin with, GAP is a Computer Algebra System (CAS).
>> From an upstream point of view, libgap is not part of GAP itself.
>> libgap is rather a library wrapper for gap meant to get a better
>> access to the GAP kernel and to be used within Sage, which is a kind
>> a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific 
>> oriented software packages).
>> Note that, for now at least, GAP itself does not furnish any library; hence 
>> libgap.
> 
> The libgap project seems like a workaround for this bug in GAP?

Indeed.

> 
>> Basically libgap adds a prefix to the GAP functions and variables,
>> and gather them in a library. We must have in mind the following points:
>> 1] The libgap source ball provides the modified source files with some delay
>> (current modified gap version in libgap is 4.8.3 while the current gap 
>> version is 4.8.5 ,
>> this version being the one in Stretch. In any case, the copyright headers of 
>> the source files
>> are not modified, so they cannot be packaged for copyright reasons.
> 
> That seems like a very suboptimal way to do it.

I guess that everybody is agree here.

> 
>> 2] The scripts that modify the original GAP source files is not distributed 
>> within
>> the libgap upstream source ball, but it is available via the libgap git 
>> repository [2] at Bitbucket
>> along some documentation for generating our own modified GAP source code. 
>> The current Debian source ball
>> for libgap is the git repository material (which unmodified contains but 
>> obsolete GAP material, version 4.8.3).
> 
> Ok, I'm glad this is not a DFSG violation. It could easily have been one.

I took care about this part of the story.

> 
>> 3] The libgap Debian package must be synchronized with the GAP Debian 
>> package, so modifying the (potentially)
>> patched GAP src/ is certainly not only a good idea but also a factor of 
>> stability and good maintenance.
> 
> Agreed.
> 
>> 4] Just the material in the subfolder src/ within the GAP source ball is 
>> needed, that is to say, not the all
>> source ball.
> 
> Makes sense.
> 
>> 5] We want a long term solution to ease the maintenance of Sage[Math] and 
>> its friends.
> 
> It seems clear to me that the only sane long-term solution is for GAP
> upstream to add a proper shared library.

Absolutely agree. My understanding is that the GAP upstream team is working on 
it.
But GAP is an heavy machinery, and  it might be not one of the top priorities.


 Has this been discussed with
> them at all?

I bet we can find long discussion about on the internet.

 Until GAP upstream are willing to do this,

Let focus on this part.


 I suggest one
> of the following:
> 
> Drop the libgap-sage source package entirely and add a secondary
> tarball to the Debian GAP source package containing only the libgap
> scripts and have the Debian build process for GAP use those scripts to
> create libgap-sage dev and lib binary packages. dpkg-source format v3
> can have multiple tarballs, which makes this doable sanely.
>

Keeping the `intersection' with the GAP debian package minimal is also a factor.

 
> OR
> 
> Get the GAP sources removed from the Bitbucket repository.
> 
> Have the build scripts in the libgap Bitbucket repository:
> 
> 1. require info on which source tree to copy or which version to download
> 2. copy that source tree or download that version
> 3. modify the local copy using the scripts as per normal
> 4. build the scripts as per normal
> 
> There might need to be some checking of the copied source tree to make
> sure the scripts still support it.

The current scheme of the libgap-sage package tends to this solution:
the first priority was to bring libga[-sage] to Debian.


> 
> Create a gap-libgap-sage-source (or similar) package from the GAP
> Debian package, containing the GAP src/ directory somewhere under
> /usr/src.
> 
> Have the libgap-sage package build-depend on gap-libgap-sage-source
> and point the libgap scripts at the GAP src/ directory under /usr/src.
> 
> Make sure that the libgap-sage package is binNMUed or rebuilt after
> every gap upload. I expect the script will need to change reasonably
> often due to changes in GAP though.

This is what I had in mind after reading your previous emails and the one of 
Den.

@Bill :
Which solution would you like to favour ?

Personally I prefer the second solution as it treats the GAP material as raw 
material
and that it puts a clear line between GAP and Sage as concerns Debian 
maintenance.

Can I start to write patch against the GAP debian/ material ?

Thanks,
Jerome

> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net

Re: Build-Depends on source itself [libgap-sage]

[Paul Wise]

On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:

> 2] The scripts that modify the original GAP source files is not distributed 
> within
> the libgap upstream source ball, but it is available via the libgap git 
> repository [2] at Bitbucket
> along some documentation for generating our own modified GAP source code. The 
> current Debian source ball
> for libgap is the git repository material (which unmodified contains but 
> obsolete GAP material, version 4.8.3).

One thing I just noticed: Please get libgap upstream to use the Python
subprocess module with shell=False instead of os.system, which is
deprecated and vulnerable to shell meta-character injection.

https://sources.debian.net/src/libgap-sage/4.8.3%2Bg69a66f0%2Bdsx-1/scripts/libGAPify.py/#L465

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself [libgap-sage]

[Paul Wise]

On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:

> Let give a try. I am dealing with the libgap-sage package [1].

Thanks for the extensive details.

> To begin with, GAP is a Computer Algebra System (CAS).
> From an upstream point of view, libgap is not part of GAP itself.
> libgap is rather a library wrapper for gap meant to get a better
> access to the GAP kernel and to be used within Sage, which is a kind
> a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific 
> oriented software packages).
> Note that, for now at least, GAP itself does not furnish any library; hence 
> libgap.

The libgap project seems like a workaround for this bug in GAP?

> Basically libgap adds a prefix to the GAP functions and variables,
> and gather them in a library. We must have in mind the following points:
> 1] The libgap source ball provides the modified source files with some delay
> (current modified gap version in libgap is 4.8.3 while the current gap 
> version is 4.8.5 ,
> this version being the one in Stretch. In any case, the copyright headers of 
> the source files
> are not modified, so they cannot be packaged for copyright reasons.

That seems like a very suboptimal way to do it.

> 2] The scripts that modify the original GAP source files is not distributed 
> within
> the libgap upstream source ball, but it is available via the libgap git 
> repository [2] at Bitbucket
> along some documentation for generating our own modified GAP source code. The 
> current Debian source ball
> for libgap is the git repository material (which unmodified contains but 
> obsolete GAP material, version 4.8.3).

Ok, I'm glad this is not a DFSG violation. It could easily have been one.

> 3] The libgap Debian package must be synchronized with the GAP Debian 
> package, so modifying the (potentially)
> patched GAP src/ is certainly not only a good idea but also a factor of 
> stability and good maintenance.

Agreed.

> 4] Just the material in the subfolder src/ within the GAP source ball is 
> needed, that is to say, not the all
> source ball.

Makes sense.

> 5] We want a long term solution to ease the maintenance of Sage[Math] and its 
> friends.

It seems clear to me that the only sane long-term solution is for GAP
upstream to add a proper shared library. Has this been discussed with
them at all? Until GAP upstream are willing to do this, I suggest one
of the following:

Drop the libgap-sage source package entirely and add a secondary
tarball to the Debian GAP source package containing only the libgap
scripts and have the Debian build process for GAP use those scripts to
create libgap-sage dev and lib binary packages. dpkg-source format v3
can have multiple tarballs, which makes this doable sanely.

OR

Get the GAP sources removed from the Bitbucket repository.

Have the build scripts in the libgap Bitbucket repository:

1. require info on which source tree to copy or which version to download
2. copy that source tree or download that version
3. modify the local copy using the scripts as per normal
4. build the scripts as per normal

There might need to be some checking of the copied source tree to make
sure the scripts still support it.

Create a gap-libgap-sage-source (or similar) package from the GAP
Debian package, containing the GAP src/ directory somewhere under
/usr/src.

Have the libgap-sage package build-depend on gap-libgap-sage-source
and point the libgap scripts at the GAP src/ directory under /usr/src.

Make sure that the libgap-sage package is binNMUed or rebuilt after
every gap upload. I expect the script will need to change reasonably
often due to changes in GAP though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself [libgap-sage]

[Jerome BENOIT]

Hello,


On 01/11/16 05:19, Paul Wise wrote:
> On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
>
>> for one of my package, libgap-sage [1], the source material used for build
>> is in fact seded meterial from an other package, gap: grossely the sed 
>> process
>> is the main part of libgap package: is there a standard way to use the Debian
>> source package of gap inside my own package libgap-sage ?
>> Any hint or example is welcome.
>
> At this time there is no way for source packages to build-depend on
> other source packages.
>
> The most often used workaround for this is binary packages with
> -source at the end of their names:
>
> $ aptitude search -- -source$


On 01/11/16 17:47, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 12:38 AM, Jerome BENOIT wrote:
> 
>> Is there any guidance for such source packages ? Which ones of them I may 
>> consider
>> a good example.
> 
> They are all about the same, ship the source under /usr/src, done.
> 
>> I guess it is the best way to proceed.
> 
> It is probably the least good way to proceed, please provide some
> details so we can discuss a proper solution.
> 

Let give a try. I am dealing with the libgap-sage package [1].

To begin with, GAP is a Computer Algebra System (CAS).
>From an upstream point of view, libgap is not part of GAP itself.
libgap is rather a library wrapper for gap meant to get a better
access to the GAP kernel and to be used within Sage, which is a kind
a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific oriented 
software packages).
Note that, for now at least, GAP itself does not furnish any library; hence 
libgap.

Basically libgap adds a prefix to the GAP functions and variables,
and gather them in a library. We must have in mind the following points:
1] The libgap source ball provides the modified source files with some delay
(current modified gap version in libgap is 4.8.3 while the current gap version 
is 4.8.5 ,
this version being the one in Stretch. In any case, the copyright headers of 
the source files
are not modified, so they cannot be packaged for copyright reasons.
2] The scripts that modify the original GAP source files is not distributed 
within
the libgap upstream source ball, but it is available via the libgap git 
repository [2] at Bitbucket
along some documentation for generating our own modified GAP source code. The 
current Debian source ball
for libgap is the git repository material (which unmodified contains but 
obsolete GAP material, version 4.8.3).
3] The libgap Debian package must be synchronized with the GAP Debian package, 
so modifying the (potentially)
patched GAP src/ is certainly not only a good idea but also a factor of 
stability and good maintenance.
4] Just the material in the subfolder src/ within the GAP source ball is 
needed, that is to say, not the all
source ball.
5] We want a long term solution to ease the maintenance of Sage[Math] and its 
friends.

For now, instead of a full source package and as suggested by Ben Finney, I 
think that a pure technical package
that would contain main the src/ subfolder material is the best option.
Of course, I am willing to write the patch against the GAP debian/ material 
that will introduce this src package.
And, before all, it must be done with the agreement of the GAP Debian package 
maintainer.

Thanks,
Jerome


[1] https://packages.qa.debian.org/libg/libgap-sage.html
[2] https://bitbucket.org/vbraun/libgap

Re: Build-Depends on source itself

[Ben Finney]

Jerome BENOIT  writes:

> for one of my package, libgap-sage [1], the source material used for build
> is in fact seded meterial from an other package, gap

One good solution would be to have the ‘gap’ package build a new binary
package, maybe ‘gap-data’, that contains the data you need in a format
likely to be useful for many purposes.

Could you work with the ‘gap’ package maintainer to achieve that?

Once ‘gap-data’ (if that is the name the ‘gap’ maintainers decide)
exists, your poposed pacakge can “Build-Depends: gap-data” and work
forward from there.

-- 
 \   “Don't worry about what anybody else is going to do. The best |
  `\ way to predict the future is to invent it.” —Alan Kay |
_o__)  |
Ben Finney

Re: RFS: node-everything.js/1.0.3-1

[Mattia Rizzolo]

On Thu, Oct 27, 2016 at 11:59:20PM -0300, Lucas Castro wrote:
>   Package: sponsorship-requests
>   Severity: optional
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "node-everything.js"

there, followed up a little over IRC, and uploaded!

(just FYI.  I also made him notice he didn't file a proper bug report…)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Build-Depends on source itself

[Paul Wise]

On Wed, Nov 2, 2016 at 12:38 AM, Jerome BENOIT wrote:

> Is there any guidance for such source packages ? Which ones of them I may 
> consider
> a good example.

They are all about the same, ship the source under /usr/src, done.

> I guess it is the best way to proceed.

It is probably the least good way to proceed, please provide some
details so we can discuss a proper solution.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself

[Jerome BENOIT]

Hello, thanks for the quick reply.

On 01/11/16 05:19, Paul Wise wrote:
> On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
> 
>> for one of my package, libgap-sage [1], the source material used for build
>> is in fact seded meterial from an other package, gap: grossely the sed 
>> process
>> is the main part of libgap package: is there a standard way to use the Debian
>> source package of gap inside my own package libgap-sage ?
>> Any hint or example is welcome.
> 
> At this time there is no way for source packages to build-depend on
> other source packages.
> 
> The most often used workaround for this is binary packages with
> -source at the end of their names:
> 
> $ aptitude search -- -source$

Is there any guidance for such source packages ? Which ones of them I may 
consider
a good example.


> 
> If you can provide some details about your situation, we can probably
> find a better solution.
> 

I guess it is the best way to proceed.

Thanks,
Jerome

Re: Bug#842528: RFS: wide-dhcpv6/20080615-17 -- DHCPv6 server/client for automatic IPv6 hosts configuration

[Roger Shimizu]

On Tue, Nov 1, 2016 at 2:26 PM, Adam Borowski  wrote:
>
> Why won't you put "export DEB_BUILD_OPTIONS=parallel=8" into your ~/.bashrc?
> It's not like your number of cores changes, and even if it does, you can
> export DEB_BUILD_OPTIONS=parallel=`nproc`
>
> (Please don't use `grep ^processor /proc/cpuinfo` nor `getconf
> _NPROCESSORS_ONLN` as neither is portable enough.)

When I read the debhelper 10 post [0], it says "defaults to building
in parallel", so I thought no other option is needed.
Thanks for letting me know it's better to put this into .bashrc, too.

[0] https://nthykier.wordpress.com/2016/09/11/debhelper-10-is-now-available/

PS. The parallel building issue of my package is fixed and uploaded.

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

Bug#842528: RFS: wide-dhcpv6/20080615-17 -- DHCPv6 server/client for automatic IPv6 hosts configuration

[Roger Shimizu]

On Tue, Nov 1, 2016 at 8:36 AM, Gianfranco Costamagna
 wrote:
>
> not outdated, just like mine, we don't use parallel in building
>
> DEB_BUILD_OPTIONS=parallel=8 can reproduce the issue (and bad me
> I didn't check that)
> probably some dependencies are not handled correctly in Makefile.in
> and having parallel enabled by default in compat 10 can't work.

Dear Gianfranco,

Thanks for letting me know the options to specify parallel number.
This helped me to get a build error reproducible environment so I can
spend some time and fix it finally.

The fixed build is uploaded.
Let us see the result in buildd.

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

Bug#837050: RFS: clsparse/0.10.1.0-1 [ITP]

[Gianfranco Costamagna]

On Mon, 12 Sep 2016 16:51:24 + (UTC) Gianfranco Costamagna 
 wrote:

> wrong licenses: I see lots of expat under
> ./src/library/kernels/*
> 
> 
> 2) usual cl missing header failure
> http://debomatic-i386.debian.net/distribution#unstable/clsparse/0.10.1.0-1/buildlog
> 
> please ping back once unstable is ok again
> (the same package in new queue that needs processing, right?)
> check-all-the-things is complaining about some stuff, but I don't think
> it is worth patching, maybe you can forward it upstream
> (e.g. missing initialization of variables, or typos)
> 
ping!
there seems to be a new opencl package but it doesn't help in making it build :)
(I have no time to investigate)
G.



signature.asc
Description: OpenPGP digital signature

Bug#837050: RFS: clsparse/0.10.1.0-1 [ITP]

[Ghislain Vaillant]

On 01/11/16 13:26, Gianfranco Costamagna wrote:

On Mon, 12 Sep 2016 16:51:24 + (UTC) Gianfranco Costamagna 
 wrote:


wrong licenses: I see lots of expat under
./src/library/kernels/*


2) usual cl missing header failure
http://debomatic-i386.debian.net/distribution#unstable/clsparse/0.10.1.0-1/buildlog

please ping back once unstable is ok again
(the same package in new queue that needs processing, right?)
check-all-the-things is complaining about some stuff, but I don't think
it is worth patching, maybe you can forward it upstream
(e.g. missing initialization of variables, or typos)


ping!
there seems to be a new opencl package but it doesn't help in making it build :)
(I have no time to investigate)
G.



I'll have a look and ping you back when I have something ready.

Cheers,
Ghis

Bug#842775: marked as done (RFS: dh-sysuser/1.3)

[Debian Bug Tracking System]

Your message dated Tue, 1 Nov 2016 08:26:05 + (UTC)
with message-id <1621091342.3249048.1477988765...@mail.yahoo.com>
and subject line Re: Bug#842775: RFS: dh-sysuser/1.3
has caused the Debian Bug report #842775,
regarding RFS: dh-sysuser/1.3
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.)


-- 
842775: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842775
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 "dh-sysuser"

* Package name: dh-sysuser
  Version : 1.3
  Upstream Author : Dmitry Bogatov 
* Url : 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

  * dh-sysuser
  * sysuser-helper

I would like to ask my so far the only user [galileo-daemon maintainer,
Dylan, in CC] to comment this release.

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

https://mentors.debian.net/package/dh-sysuser

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_1.3.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git

More information about dh-sysuser can be obtained from
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git

Changes since last upload:

  * Rethink what this package actually does. Instead of removing user, it
is just locked. It drastically simplify maintainer script code and
avoids tricky situation with `deluser --remove-home'.
(Closes: #840496)
+ Thanks: Simon McVittie 
  * New binary package: sysuser-helper. This way maintainer script
contains as little logic, as possible.
  * New option: home without arguments. It creates home directory
for system user somewhere under /var/lib.

Regards,
  Dmitry Bogatov

-- 
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.
--- End Message ---
--- Begin Message ---
Hi,

>I am looking for a sponsor for my package "dh-sysuser"
>(Closes: #840496)



I changed "96" to "69", signed and uploaded in deferred/5.
BTW is 1.3 a good versioning? seems a typo to bump
0.1, 0.2 and then 1.3...

anyway, in deferred/5.

G.--- End Message ---

RE: get 403 Forbidden when upload package to mentors.

[Xu, Guangxin]

Tsocks is a proxy application. I can try this on firewall free environments. 
Then report you back tomorrow.

Thanks

> -Original Message-
> From: paul.is.w...@gmail.com [mailto:paul.is.w...@gmail.com] On Behalf Of
> Paul Wise
> Sent: Tuesday, November 1, 2016 3:36 PM
> To: debian-mentors@lists.debian.org
> Subject: Re: get 403 Forbidden when upload package to mentors.
> 
> On Tue, Nov 1, 2016 at 2:56 PM, Xu, Guangxin wrote:
> 
> >   Uploading libyami-utils_1.0.0-1.dsc: Upload failed: 500 Internal
> > Server Error
> 
> The server side of that doesn't make much sense to me, see below.
> What is the tsocks prefix to dput for?
> Can you try http/ftp with a VPN or http with Tor?
> 
> (70007)The timeout specified has expired: mod_wsgi (pid=16043): Unable to
> get bucket brigade for request.
> mod_wsgi (pid=16039): Exception occurred processing WSGI script
> '/var/www/debexpo/live.wsgi'.
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/paste/cascade.py", line 107, in 
> __call__
> f = StringIO(environ['wsgi.input'].read(length))
> IOError: request data read error
> 
> --
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Re: get 403 Forbidden when upload package to mentors.

[Paul Wise]

On Tue, Nov 1, 2016 at 2:56 PM, Xu, Guangxin wrote:

>   Uploading libyami-utils_1.0.0-1.dsc: Upload failed: 500 Internal Server 
> Error

The server side of that doesn't make much sense to me, see below.
What is the tsocks prefix to dput for?
Can you try http/ftp with a VPN or http with Tor?

(70007)The timeout specified has expired: mod_wsgi (pid=16043): Unable
to get bucket brigade for request.
mod_wsgi (pid=16039): Exception occurred processing WSGI script
'/var/www/debexpo/live.wsgi'.
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/paste/cascade.py", line 107,
in __call__
f = StringIO(environ['wsgi.input'].read(length))
IOError: request data read error

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#842775: RFS: dh-sysuser/1.3

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-sysuser"

* Package name: dh-sysuser
  Version : 1.3
  Upstream Author : Dmitry Bogatov 
* Url : 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

  * dh-sysuser
  * sysuser-helper

I would like to ask my so far the only user [galileo-daemon maintainer,
Dylan, in CC] to comment this release.

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

https://mentors.debian.net/package/dh-sysuser

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_1.3.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git

More information about dh-sysuser can be obtained from
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git

Changes since last upload:

  * Rethink what this package actually does. Instead of removing user, it
is just locked. It drastically simplify maintainer script code and
avoids tricky situation with `deluser --remove-home'.
(Closes: #840496)
+ Thanks: Simon McVittie 
  * New binary package: sysuser-helper. This way maintainer script
contains as little logic, as possible.
  * New option: home without arguments. It creates home directory
for system user somewhere under /var/lib.

Regards,
  Dmitry Bogatov

-- 
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: get 403 Forbidden when upload package to mentors.

[Xu, Guangxin]

Hi Paul:
Thanks for reply.
I tried this before, it's not working , so Giafranco suggest me use ftp.


I tried this again, it still failed
gxxu@zion-debian:~/works/pbuild/libyami-utils$ tsocks dput mentors 
libyami-utils_1.0.0-1_source.changes
Checking signature on .changes
gpg: Signature made Tue 18 Oct 2016 05:16:22 AM PDT using RSA key ID FF093896
gpg: Good signature from "Xu Guangxin "
Good signature on 
/home/gxxu/works/pbuild/libyami-utils/libyami-utils_1.0.0-1_source.changes.
Checking signature on .dsc
gpg: Signature made Tue 18 Oct 2016 05:16:19 AM PDT using RSA key ID FF093896
gpg: Good signature from "Xu Guangxin "
Good signature on 
/home/gxxu/works/pbuild/libyami-utils/libyami-utils_1.0.0-1.dsc.
Uploading to mentors (via http to mentors.debian.net):
  Uploading libyami-utils_1.0.0-1.dsc: Upload failed: 500 Internal Server Error

thanks

> -Original Message-
> From: paul.is.w...@gmail.com [mailto:paul.is.w...@gmail.com] On Behalf Of
> Paul Wise
> Sent: Tuesday, November 1, 2016 12:56 PM
> To: debian-mentors@lists.debian.org
> Subject: Re: get 403 Forbidden when upload package to mentors.
> 
> On Tue, Nov 1, 2016 at 12:45 PM, Xu, Guangxin wrote:
> 
> > I am behind a firewall, is it related?
> 
> Most likely.
> 
> > Or I need configure something.
> 
> Try using http instead of ftp to do the upload.
> 
> > Uploading to mentors-ftp (via ftp to mentors.debian.net):
> >   Uploading libyami-utils_1.0.0-1.dsc: 425 Security: Bad IP connecting.
> 
> Somehow this managed to create an empty dsc file. I've removed it now so you
> can try http.
> 
> --
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise