Re: mpgrafic - mpirun test program as root in automatic build
On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote: > I guess by "both of these" you mean "most of the build steps (apart from > the 'debian/rules install' step)"? What I wrote wasn't clear and wasn't strictly true, sorry! When manually building from source: You always build/test as a normal user. You install as either root or normal user, depending on the install prefix. When doing Debian package builds: You always build/test as a normal user. You always install using fakeroot. -- bye, pabs https://wiki.debian.org/PaulWise
Re: mpgrafic - mpirun test program as root in automatic build
On Wed, 18 Jan 2017, Paul Wise wrote: On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote: I've looked a bit at buildd.debian.org, but it's not completely trivial to decide which is correct - do the buildd builds on the debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged user running fakeroot, or as (iii) an unprivileged user? (iii) an unprivileged user fakeroot is only used at `debian/rules install` time. Both of these are the same as if you were building manually from source. I guess by "both of these" you mean "most of the build steps (apart from the 'debian/rules install' step)"? cheers boud
Re: mpgrafic - mpirun test program as root in automatic build
On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote: > I've looked a bit at buildd.debian.org, but it's not completely > trivial to decide which is correct - do the buildd builds on the > debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged > user running fakeroot, or as (iii) an unprivileged user? (iii) an unprivileged user fakeroot is only used at `debian/rules install` time. Both of these are the same as if you were building manually from source. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#851696: RFS: python-qtpy/1.2.0-1
Hi Fred, On Tue, 2017-01-17 at 19:30 +, PICCA Frederic-Emmanuel wrote: > Hello Ghislain. > > do you know if this version is compatible with the reverse dependencies > already in Debian ? First of, the upstream changelog did not mention any API breakage, only fixes and new features (support for qtmultimedia). > python-qtpy > Reverse Depends: > python-spyder > python-ginga > python-qtawesome > python-glue Both qtpy 1.1.2 and qtpy 1.2.0 works with spyder 3.0.2 (tested in a venv). Since qtpy was designed for spyder, it is probably the best possible test we have in hand. > We are close from the freeze and I do not want to end up with a bunch of > autorm packages due to this kind of upload. I know, and there is still roughly a week to go. Since I use the packaged spyder, pyzo and git-cola quite extensively, I should be able to catch potential breakage quite quickly. > BUT if you can show that there is no problem I am ok to sponsorize this > package. Your call. Ghis
Bug#851696: RFS: python-qtpy/1.2.0-1
Hi Fred, On Tue, 2017-01-17 at 19:30 +, PICCA Frederic-Emmanuel wrote: > Hello Ghislain. > > do you know if this version is compatible with the reverse dependencies > already in Debian ? First of, the upstream changelog did not mention any breakage, only fixes and new features (support for qtmultimedia). Upstream has had a good track record at keeping these in check so far. > python-qtpy > Reverse Depends: > python-spyder > python-ginga > python-qtawesome > python-glue Both qtpy 1.1.2 and qtpy 1.2.0 works with spyder 3.0.2 (tested in a venv). Since qtpy was designed for spyder in the first place, it is probably the best possible test we have in hand. In addition, I have checked pyzo and git-cola. Both works fine with qtpy 1.1.2 and 1.2.0. > We are close from the freeze and I do not want to end up with a bunch of > autorm packages due to this kind of upload. Based on my initial testing, I am confident this is safe. I'd still have a week to fix things if disaster strikes, but I'd be really suprised. > BUT if you can show that there is no problem I am ok to sponsorize this > package. Your call. Ghis
Re: mpgrafic - mpirun test program as root in automatic build
On Tue, 17 Jan 2017, James Cowgill wrote:
I'm not sure I follow. Debhelper runs the testsuite during the build
target so it shouldn't be run as root anyway. I don't think you need any
workarounds at all for this.
I agree in terms of principles :), but I don't know what actually happens
on the buildd machines.
I've looked a bit at buildd.debian.org, but it's not completely
trivial to decide which is correct - do the buildd builds on the
debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
user running fakeroot, or as (iii) an unprivileged user?
Looking at git://git.debian.org/buildd-tools/sbuild.git it looks like
the user is "buildd" - but this is just a guess.
The mpirun exit-if-root mechanism is in
openmpi-2.0.2~git.20161225/orte/orted/orted_submit.c
Isolating this to lines 319-335, this is easy to test as a standalone
main program (see snippet.c below) - the exit-if-root test is triggered either
(i) using
root directly, or (ii) as ordinary user running fakeroot.
Even as fakeroot, both geteuid() and getuid() in the snippet below
report an identity of 0.
My own pbuilder setup - closely following the maint-guide.en.txt advice -
appears *not* to run "make check" as fakeroot or root, since I
do not see the error and exit due to running as root.
The snippet below can be tested:
user$ ./snippet
user$ fakeroot ./snippet
root# ./snippet
Cheers
Boud
--
/* inspired by openmpi-2.0.2~git.20161225/orte/orted/orted_submit.c root
detection */
/* (C) 2017 GPL-3+ B. Roukema if copyright is needed */
#include
#include
#include
int main(void)
{
int uid = 77 , euid = ;
euid = geteuid();
uid = getuid();
if (0 == euid){
printf("WARNING: You are effectively root.\n");
};
if (0 == uid){
printf("WARNING: You are really root.\n");
};
if (0 != uid && 0 != euid){
printf("You are not running as root :).\n");
}
return 0;
}
--
Re: mpgrafic - mpirun test program as root in automatic build
James Cowgill writes: > On 16/01/17 23:58, Boud Roukema wrote: >> 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. > > I'm not sure I follow. Debhelper runs the testsuite during the build > target so it shouldn't be run as root anyway. I don't think you need any > workarounds at all for this. I (as Bouds sponsor) have the problem that in my cowbuilder the build is done as root, leading to the questioned error message and a failure of the test and the build. Maybe in my setup something is wrong? Best regards Ole
Bug#851696: RFS: python-qtpy/1.2.0-1
Hello Ghislain. do you know if this version is compatible with the reverse dependencies already in Debian ? python-qtpy Reverse Depends: python-spyder python-ginga python-qtawesome python-glue We are close from the freeze and I do not want to end up with a bunch of autorm packages due to this kind of upload. BUT if you can show that there is no problem I am ok to sponsorize this package. Cheers Fred
Bug#851696: RFS: python-qtpy/1.2.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-qtpy" * Package name: python-qtpy Version : 1.2.0-1 Upstream Author : The Spyder Development Team * URL : https://github.com/spyder-ide/qtpy * License : Expat Section : python It builds those binary packages: python-qtpy - abtraction layer for PySide/PyQt4/PyQt5 (Python 2) python3-qtpy - abtraction layer for PySide/PyQt4/PyQt5 (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-qtpy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-qtpy/python-qtpy_1.2.0-1.dsc Successful build on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/python-qtpy/1.2.0-1/buildlog Changes since the last upload: * Switch to git-dpm * New upstream release * Bump minimum Python versions (2.7, 3.3) * Add new dependency on pyqt5.qtmultimedia * Simplify setup for tests in pybuild * Drop superfluous Testsuite field * Upgrade packaging to debhelper 10 * Support the nocheck build profile - Add versioned dependency on dpkg-dev - Mark test dependencies as !nocheck - Disable tests if nocheck requested * Fix whitespaces in rules file Regards, Ghislain Vaillant
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
Etienne Dysli-Metref: > Hello mentors, > > Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the > holidays, I'm now backporting it to jessie. So far there is nothing to > change, however piuparts gives me the following error (which does not > appear on stretch): > >> [...] > > So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). But > then a get a lintian error > >> E: libshibsp7: postinst-must-call-ldconfig >> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 > > [...] > > So hmm... any clues? Who's wrong? me, piuparts, lintian or debhelper? > > [...] > > Etienne > This lintian error: * is aimed at stretch or later, and * should be ignored for stable and stable-backports Thanks, ~Niels
Re: mpgrafic - mpirun test program as root in automatic build
Hi, On 16/01/17 23:58, Boud Roukema wrote: > 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". I'm not sure I follow. Debhelper runs the testsuite during the build target so it shouldn't be run as root anyway. I don't think you need any workarounds at all for this. James signature.asc Description: OpenPGP digital signature
Re: Looking for sponsoring/menthoring : openmeca package [ITP: #850590]
On Tue, 2017-01-17 at 11:06 +0100, dada wrote: > Le 2017-01-17 10:41, Mattia Rizzolo a écrit : > > On Tue, Jan 17, 2017 at 10:27:45AM +0100, dada wrote: > > > ** What I have already done for packaging openmeca ** > > > > > > - open an ITP (see > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590). > > >Andreas Tille (from debian-science) tell me that the soft fit > > > well with > > > the debian-science field. > > > > good. > > > > > - open a git repository for openmeca on alioth : > > > > > > https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/ > > >post a first version of the openmeca package on this git > > > repository. > > >This package seems to be right on my personal computer (Ubuntu > > > 16.04.1 > > > LTS and checked with "gbp buildpackage") > > > > good. (although you really should build it in Debian unstable, and > > test it there too). > > > > > - post an intent on the debian science list (see > > > https://lists.debian.org/debian-science/2017/01/msg00093.html) > > >but I have no answer. > > > > That's not an "intent" really, it's a forward of your ITP with "some" > > added text. > > > > > As I have no answer from the debian-science list (probably they have > > > no > > > time), I post my request on this list. > > > > 1) consider that 4 days are really little, also considering a week > > end > >was in the middle > > 2) the subject was really poor: most of use receive *a lot* of emails > >and subjects are important; I probably skipped that email thinking > > it > >was just a "FYI" of an ITP related to -science. > > > > > I am not used with the Debian policy so... please tell me if I am > > > wrong, > > > impatient, or something else > > > > The usual procedure (especially if the team have nothing else in > > place) > > is to open a RFS bug. I invite you to read > > https://mentors.debian.net/intro-maintainers especially from point 5 > > onward; mentors.d.n also gives you a template for the RFS bug (see > > point If you seek sponsorship via the Debian Science Team, just file an RFS and fill in an entry in the SoB page. https://wiki.debian.org/DebianPureBlends/SoB > > 4). (note that even if you'll have to upload a source packages to > > mentors.d.n, several of us still prefer to review using a git > > repository, so please include that too in the request). > > The reason to prefer an RFS bug over emails is that they don't get > > lost: > > several of us look at https://bugs.debian.org/sponsorship-requests > > from > > time to time and take care of pending request, whereas emails in a > > mailing list are much harder to keep track of. Also, please keep in mind that we are currently focusing on getting Stretch out in the next few months, so new packages have much lower priority at the moment. > Hello Matia, Thank you for your detailed and quick reply. > I am going to : 1) wait and 2) read the intro-maintainers. > > > Now, you don't have any package already in the archive, so my > > personal > > policy (https://people.debian.org/~mattia/sponsoring.html) "forbids" > > me > > to sponsoring the package, but I trust there are several other > > developers willing to do so :) I just wanted to explain better the > > usual procedure ^^ > > I understand your position for sponsoring, no problem ! > Best regards, Damien. >
Re: Looking for sponsoring/menthoring : openmeca package [ITP: #850590]
Le 2017-01-17 10:41, Mattia Rizzolo a écrit : On Tue, Jan 17, 2017 at 10:27:45AM +0100, dada wrote: ** What I have already done for packaging openmeca ** - open an ITP (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590). Andreas Tille (from debian-science) tell me that the soft fit well with the debian-science field. good. - open a git repository for openmeca on alioth : https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/ post a first version of the openmeca package on this git repository. This package seems to be right on my personal computer (Ubuntu 16.04.1 LTS and checked with "gbp buildpackage") good. (although you really should build it in Debian unstable, and test it there too). - post an intent on the debian science list (see https://lists.debian.org/debian-science/2017/01/msg00093.html) but I have no answer. That's not an "intent" really, it's a forward of your ITP with "some" added text. As I have no answer from the debian-science list (probably they have no time), I post my request on this list. 1) consider that 4 days are really little, also considering a week end was in the middle 2) the subject was really poor: most of use receive *a lot* of emails and subjects are important; I probably skipped that email thinking it was just a "FYI" of an ITP related to -science. I am not used with the Debian policy so... please tell me if I am wrong, impatient, or something else The usual procedure (especially if the team have nothing else in place) is to open a RFS bug. I invite you to read https://mentors.debian.net/intro-maintainers especially from point 5 onward; mentors.d.n also gives you a template for the RFS bug (see point 4). (note that even if you'll have to upload a source packages to mentors.d.n, several of us still prefer to review using a git repository, so please include that too in the request). The reason to prefer an RFS bug over emails is that they don't get lost: several of us look at https://bugs.debian.org/sponsorship-requests from time to time and take care of pending request, whereas emails in a mailing list are much harder to keep track of. Hello Matia, Thank you for your detailed and quick reply. I am going to : 1) wait and 2) read the intro-maintainers. Now, you don't have any package already in the archive, so my personal policy (https://people.debian.org/~mattia/sponsoring.html) "forbids" me to sponsoring the package, but I trust there are several other developers willing to do so :) I just wanted to explain better the usual procedure ^^ I understand your position for sponsoring, no problem ! Best regards, Damien.
Re: Looking for sponsoring/menthoring : openmeca package [ITP: #850590]
On Tue, Jan 17, 2017 at 10:27:45AM +0100, dada wrote: > ** What I have already done for packaging openmeca ** > > - open an ITP (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590). >Andreas Tille (from debian-science) tell me that the soft fit well with > the debian-science field. good. > - open a git repository for openmeca on alioth : > https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/ >post a first version of the openmeca package on this git repository. >This package seems to be right on my personal computer (Ubuntu 16.04.1 > LTS and checked with "gbp buildpackage") good. (although you really should build it in Debian unstable, and test it there too). > - post an intent on the debian science list (see > https://lists.debian.org/debian-science/2017/01/msg00093.html) >but I have no answer. That's not an "intent" really, it's a forward of your ITP with "some" added text. > As I have no answer from the debian-science list (probably they have no > time), I post my request on this list. 1) consider that 4 days are really little, also considering a week end was in the middle 2) the subject was really poor: most of use receive *a lot* of emails and subjects are important; I probably skipped that email thinking it was just a "FYI" of an ITP related to -science. > I am not used with the Debian policy so... please tell me if I am wrong, > impatient, or something else The usual procedure (especially if the team have nothing else in place) is to open a RFS bug. I invite you to read https://mentors.debian.net/intro-maintainers especially from point 5 onward; mentors.d.n also gives you a template for the RFS bug (see point 4). (note that even if you'll have to upload a source packages to mentors.d.n, several of us still prefer to review using a git repository, so please include that too in the request). The reason to prefer an RFS bug over emails is that they don't get lost: several of us look at https://bugs.debian.org/sponsorship-requests from time to time and take care of pending request, whereas emails in a mailing list are much harder to keep track of. Now, you don't have any package already in the archive, so my personal policy (https://people.debian.org/~mattia/sponsoring.html) "forbids" me to sponsoring the package, but I trust there are several other developers willing to do so :) I just wanted to explain better the usual procedure ^^ -- 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
Looking for sponsoring/menthoring : openmeca package [ITP: #850590]
Hello all, My name is Damien André, I am french and I am looking for menthoring/sponsoring for the openmeca software (see https://gitlab.com/damien.andre/openmeca). Openmeca is a graphical application for building multibody dynamics simulations. It may be usefull for learning and teaching mechanics, kinematics and dynamics. Some screencast are available on Youtube (sorry for gg inside) at the url : https://www.youtube.com/watch?v=N9Wy5MHmnJQ&list=PLjFD44HqZ1diZN45FSLO82NyuIgpu4Lml I develop this soft since 8 years and I think that the program has a sufficient level of quality for being included in the Debian distrib. ** Technical informations about openmeca ** - URL : https://gitlab.com/damien.andre/openmeca - License : GPL v3 - Programming Lang: C++ - Main Dependences: Qt5 ** What I have already done for packaging openmeca ** - open an ITP (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590). Andreas Tille (from debian-science) tell me that the soft fit well with the debian-science field. - open a git repository for openmeca on alioth : https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/ post a first version of the openmeca package on this git repository. This package seems to be right on my personal computer (Ubuntu 16.04.1 LTS and checked with "gbp buildpackage") - post an intent on the debian science list (see https://lists.debian.org/debian-science/2017/01/msg00093.html) but I have no answer. As I have no answer from the debian-science list (probably they have no time), I post my request on this list. I am not used with the Debian policy so... please tell me if I am wrong, impatient, or something else Please feel free to contact me for any further information. Damien André http://www.unilim.fr/pages_perso/damien.andre/
RE:watch file with multiple download url
> 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/ I will do this change and see if with two URL, uscan upload only one .tar.gz. I do not want to download two times the same pacakge from the two URL. thansk Fred
Re: git-p4 package?
[+Gerrit Pape's correct email address] On 17 January 2017 at 00:17, Sean Whitton wrote: > 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. Thanks - an NMU seems to be a bit drastic!
Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
Hello mentors, Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the holidays, I'm now backporting it to jessie. So far there is nothing to change, however piuparts gives me the following error (which does not appear on stretch): > 0m34.6s ERROR: FAIL: Package purging left files on system: > /etc/systemd/system/multi-user.target.wants/shibd.service -> > /lib/systemd/system/shibd.service not owned > /etc/systemd/system/shibd.service -> /dev/null not owned > /var/lib/systemd/deb-systemd-helper-enabled/ not owned > /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ > not owned > > /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/shibd.service > not owned > /var/lib/systemd/deb-systemd-helper-enabled/shibd.service.dsh-also not > owned > /var/lib/systemd/deb-systemd-helper-masked/ not owned > /var/lib/systemd/deb-systemd-helper-masked/shibd.service not owned It looked like dh-systemd wasn't properly cleaning up despite shibboleth-sp2-utils's postrm script looking like it would: > #!/bin/sh > > set -e > > if [ "$1" = purge ]; then > for dir in /var/cache/shibboleth /var/log/shibboleth; do > if dpkg-statoverride --list "$dir" >/dev/null 2>&1; then > dpkg-statoverride --remove "$dir" > fi > rm -rf "$dir" > done > fi > > # Automatically added by dh_installinit > if [ "$1" = "purge" ] ; then > update-rc.d shibd remove >/dev/null > fi > > > # In case this system is running systemd, we make systemd reload the unit > files > # to pick up changes. > if [ -d /run/systemd/system ] ; then > systemctl --system daemon-reload >/dev/null || true > fi > # End automatically added section > # Automatically added by dh_systemd_enable > if [ "$1" = "remove" ]; then > if [ -x "/usr/bin/deb-systemd-helper" ]; then > deb-systemd-helper mask shibd.service >/dev/null > fi > fi > > if [ "$1" = "purge" ]; then > if [ -x "/usr/bin/deb-systemd-helper" ]; then > deb-systemd-helper purge shibd.service >/dev/null > deb-systemd-helper unmask shibd.service >/dev/null > fi > fi > # End automatically added section So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). But then a get a lintian error > E: libshibsp7: postinst-must-call-ldconfig > usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 that I don't understand because the postinst script in libshibsp7_2.6.0+dfsg1-4~bpo8+1_amd64.deb contains: > #!/bin/sh > set -e > # Automatically added by dh_makeshlibs > if [ "$1" = "configure" ]; then > ldconfig > fi > # End automatically added section So hmm... any clues? Who's wrong? me, piuparts, lintian or debhelper? My source package is available at https://mentors.debian.net/package/shibboleth-sp2 if you want to take a look at it. Etienne signature.asc Description: OpenPGP digital signature
