Bug#846325: RFS: netperfmeter/1.6.1-1
Control: noowner -1 Timeout... Therefore removing the owner tag and no longer indicating that I will sponsor the upload. On Fri, 30 Dec 2016 12:18:56 +0100 Tobias Frostwrote: > ping? > >
Bug#851756: RFS: telegram-desktop/1.0.0-2
19.01.2017 00:23, Gianfranco Costamagna пишет: I see tag for 1.0.1 pushed on github [1] This is alpha version. It is not in upstream changelog on [1]. To be noted upstream author does not always publish the tags in time. P.S.: I don't know how to put this remote changelog into the package. [1] https://desktop.telegram.org/changelog
Re: mpgrafic - mpirun test program as root in automatic build
On Thu, Jan 19, 2017 at 7:44 AM, Sean Whitton wrote: > This is temporarily false: #852071 Is there a typo in that bug? I get a 404 -- bye, pabs https://wiki.debian.org/PaulWise
Re: question on binary-or-shlib-defines-rpath
Dear Nico, On Wed, Jan 18, 2017 at 10:39:47PM +, Nico Schlömer wrote: > That's not true later on when the libraries are _installed_, of course. For > this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves exactly > that purpose. For some reason, lintian doesn't seem to be happy with that > though. I believe that this Lintian tag checks only the contents of your final binary packages. Are you absolutely sure that you do not install any of these test suite files? If so, it's probably a Lintian bug. -- Sean Whitton signature.asc Description: PGP signature
Re: mpgrafic - mpirun test program as root in automatic build
Hello, On Wed, Jan 18, 2017 at 02:25:41PM +0800, 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. This is temporarily false: #852071 -- Sean Whitton signature.asc Description: PGP signature
question on binary-or-shlib-defines-rpath
Hi everyone, I'm co-maintaining the Trilinos package [1] in Debian and recently found a bunch of new lintian warnings of the kind binary-or-shlib-defines-rpath [2]. It say in the description of the warning: ``` To fix this problem, look for link lines like: gcc test.o -o test -Wl,--rpath,/usr/local/lib or gcc test.o -o test -R/usr/local/lib and remove the -Wl,--rpath or -R argument. ``` Indeed, the Trilinos installation contains many of those lines, but they are necessary too. When executing the test binaries (which are compiled in the build tree alongside the libraries), they have to find the linked shared libraries. Messing with the rpath is necessary. That's not true later on when the libraries are _installed_, of course. For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves exactly that purpose. For some reason, lintian doesn't seem to be happy with that though. Any hints? Cheers, Nico [1] https://tracker.debian.org/pkg/trilinos [2] https://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html [3] https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_INSTALL_RPATH.html
Bug#851799: RFS: hamlib/3.1.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "hamlib" * Package name : hamlib Version : 3.1.0-1 Upstream Author : Kamal Mostafa, Colin Tuckley * URL : https://sourceforge.net/projects/hamlib/ * License : LGPLv2 Section : hamradio It builds those binary packages: libhamlib++-dev - Development C++ library to control radio transceivers and receive libhamlib-dev - Development library to control radio transceivers and receivers libhamlib-doc - Documentation for the hamlib radio control library libhamlib-utils - Utilities to support the hamlib radio control library libhamlib2 - Run-time library to control radio transceivers and receivers libhamlib2++c2 - Run-time C++ library to control radio transceivers and receivers libhamlib2-perl - Run-time perl library to control radio transceivers and receivers libhamlib2-tcl - Run-time Tcl library to control radio transceivers and receivers lua-hamlib2 - Run-time Lua library to control radio transceivers and receivers python-libhamlib2 - Run-time Python library to control radio transceivers and receive To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hamlib Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hamlib/hamlib_3.1.0-1.dsc More information about hello can be obtained from https://sourceforge.net/projects/hamlib Changes since the last upload: * Team upload * New upstream release * Changed manpages directory in manpage-hyphen-fixes.patch * Added Lua binding * Fixed broken libhamlib2-tcl package * Bump Standards-version to 3.9.8 Regards, Ervin Hegedüs -- I � UTF-8
Bug#851756: RFS: telegram-desktop/1.0.0-2
Hello >Version : 1.0.0-2~rc2 >https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc I see tag for 1.0.1 pushed on github [1] Isn't it a good release? I didn't look at the code, but instead of an rc, I would prefer a stable 1.0.1 (even if it is just a tag and not a release, so I might be *very* wrong) G. [1] https://github.com/telegramdesktop/tdesktop/releases
Bug#851756: RFS: telegram-desktop/1.0.0-2
On Wed, Jan 18, 2017 at 10:07:34PM +0300, Коля Гурьев wrote: > > Why is it in contrib? > From what I understand, there are packages with dependencies on non-free > software in contrib section. This program does not work if Telegram server > is stopped for any reason. But this server is proprietary, more accurately, > it does not even distribute in public. So I thought the package has to be in > contrib. Correct me, please, if I am wrong. Clients for proprietary servers are packaged in main, e.g. pyicqt. -- WBR, wRAR signature.asc Description: PGP signature
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
Etienne Dysli-Metref: > On 17/01/17 18:30, Niels Thykier wrote: E: libshibsp7: postinst-must-call-ldconfig usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 >> >> This lintian error: >> >> * is aimed at stretch or later, and >> * should be ignored for stable and stable-backports Correction; I was wrong - this lintian error is correct for a lintian from stable (I confused it with a newer lintian tag). This occurs because you are using debhelper from backports, which uses a trigger instead of maintscript to call ldconfig. The end result is the same for you though - ignore the warning. :) > > After having overridden this lintian error, it turns out it was a bit of > a red herring: piuparts still reports files left after purging. > > [...] Correct, this lintian warning is completely unrelated to your piuparts issue. > > So is the postrm script from shibboleth-sp2-utils not executed? > It is definitely called - if it wasn't, almost everything would be failing on piuparts.d.o and dpkg in stable would completely an utterly broken with us drowning in RC bugs. :) Most likely, there is an issue with either the postrm script OR the helpers used in it. I am not an expert on the helpers, so I cannot help there. Thanks, ~Niels
Bug#851756: RFS: telegram-desktop/1.0.0-2
I already fixed a few things: debian/changelog, the list of build dependencies. My fork on Github is specified temporally in debian/control. I just don't know a more appropriate value for this field at the moment. I've putted the current changes back to [1]. I would appreciate your advice about my debian/rules. What can I improve it? [1] https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-1.dsc 18.01.2017 19:05, Mattia Rizzolo пишет: Now, I usually don't sponsor NEW packages for new people without a record of past contributions to Debian, as I don't trust them to stick around and actually maintain the package), but I'm inclined to make an exception to this rule of mine on the basis that I'd love to have this package for myself (but be aware, I really expct the package to be maintained…). I will do my best for that. By the way, this is my nickname in Telegram: https://t.me/mymedia 18.01.2017 19:22, Andrey Rahmatullin пишет: Why is it in contrib? From what I understand, there are packages with dependencies on non-free software in contrib section. This program does not work if Telegram server is stopped for any reason. But this server is proprietary, more accurately, it does not even distribute in public. So I thought the package has to be in contrib. Correct me, please, if I am wrong.
Bug#851789: RFS: python-h5netcdf/0.3.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-h5netcdf" * Package name: python-h5netcdf Version : 0.3.1-1 Upstream Author : Stephan Hoyer* URL : https://github.com/shoyer/h5netcdf * License : BSD Section : python It builds those binary packages: python-h5netcdf - netCDF4 support for Python 2 via h5py python3-h5netcdf - netCDF4 support for Python 3 via h5py To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-h5netcdf Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-h5netcdf/python-h5netcdf_0.3.1-1.dsc Or checkout the packaging repository at: https://anonscm.debian.org/git/debian-science/packages/python-h5netcdf.git Changes since the last upload: * Initial release. (Closes: #851378) Regards, Ghislain Vaillant
Fattura TIM linea Fissa - Gennaio 2017 - scadenza 12/01/2017
<<< text/html: Unrecognized >>>
Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]
Hi Adrey, On Wed, Jan 18, 2017 at 11:16:16PM +0500, Andrey Rahmatullin wrote: > On Wed, Jan 18, 2017 at 04:57:44PM +0100, Ervin Hegedüs wrote: > > I'm member of the team (as guest: > > https://alioth.debian.org/users/airween-guest/). As I wrote, I > > noticed the team through the list - no response. > In that case this upload should be a team upload and not a NMU. See > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-team-upload thanks a lot! a. -- I � UTF-8
Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]
On Wed, Jan 18, 2017 at 04:57:44PM +0100, Ervin Hegedüs wrote: > I'm member of the team (as guest: > https://alioth.debian.org/users/airween-guest/). As I wrote, I > noticed the team through the list - no response. In that case this upload should be a team upload and not a NMU. See https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-team-upload -- WBR, wRAR signature.asc Description: PGP signature
Bug#851756: RFS: telegram-desktop/1.0.0-2
Why is it in contrib? -- WBR, wRAR signature.asc Description: PGP signature
Bug#851756: RFS: telegram-desktop/1.0.0-2
Control: owner -1 ! Control: tag -1 moreinfo On Wed, Jan 18, 2017 at 04:46:46PM +0300, Коля Гурьев wrote: > I am looking for a sponsor for my package "telegram-desktop" Hi! I am an heavy user of telegram, and I was looking forward for this package, despite the privacy concerns, etc. > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc I will be reviewing this package more deeply, bug few things I can tell you already: * changelog for the first upload should use a -1 version, and only contain on line "Initial upload. (Closes: #x)" or somesuch, so please get rid of all the rest * Vcs-* fields should point to a *packaging* repository, not the upstream git repo; that said, I'd love to see a git repository used for packaging this, this is the tool I prefer for this job: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html * please use `wrap-and-sort -ast` (or somesuch) to make a diff-frindly list of build-deps * d/rules is incredibly verbose, I can't believe such a thing is needed (once I'll look deeply I can tell you more, I just know I'm not happy to see such d/rules). * The bug you reference is still a RFP, you should turn it into an ITP https://www.debian.org/devel/wnpp/#howto-rfp if you don't know the BTS and how to deal with it, read all of https://www.debian.org/Bugs/ and subpages. Now, I usually don't sponsor NEW packages for new people without a record of past contributions to Debian, as I don't trust them to stick around and actually maintain the package), but I'm inclined to make an exception to this rule of mine on the basis that I'd love to have this package for myself (but be aware, I really expct the package to be maintained…). -- 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
Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]
Hi Adrey, On Wed, Jan 18, 2017 at 08:35:50PM +0500, Andrey Rahmatullin wrote: > On Wed, Jan 18, 2017 at 04:29:43PM +0100, Ervin Hegedüs wrote: > > > Why are doing this NMU? > > because lintian indicated that I must give NMU as version to that > > package > I've meant why are you doing this upload of someone else's package. because there aren't any member, who did it. Anyway, I just would like to help to maintain (I've made soma part of the upstream version, I thought I can help...). I'm member of the team (as guest: https://alioth.debian.org/users/airween-guest/). As I wrote, I noticed the team through the list - no response. > > Okay, thanks for your feedback - what should I do now? > As this is a team-maintained package you should join the team and work on > this package as a team member. see above. > Note though that you have only a week to > get this package uploaded to sid before the freeze. I know that, that's why I uploades to mentors.debian.org. a.
Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]
On Wed, Jan 18, 2017 at 04:29:43PM +0100, Ervin Hegedüs wrote: > > Why are doing this NMU? > because lintian indicated that I must give NMU as version to that > package I've meant why are you doing this upload of someone else's package. > Okay, thanks for your feedback - what should I do now? As this is a team-maintained package you should join the team and work on this package as a team member. Note though that you have only a week to get this package uploaded to sid before the freeze. -- WBR, wRAR signature.asc Description: PGP signature
Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]
Hi, On Wed, Jan 18, 2017 at 08:15:53PM +0500, Andrey Rahmatullin wrote: > Control: tags -1 + moreinfo > > Why are doing this NMU? because lintian indicated that I must give NMU as version to that package > Does it fix any bugs? yes, till I worked on the package, I've found a bug (a binary package is empty), but I didn't reported that, just fixed it in new version. I don't know that the Bump-Standard-Version modifaction is fixup or not. > Have you read about the NMU > procedure at > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu > and followed it? yes - post factum (now). I've made the package about two weeks ago, and wrote a notification to debian-hams@ list, but still didn't get any answer. > Besides, it even has a wrong version suffix. Okay, thanks for your feedback - what should I do now? a.
Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]
Control: tags -1 + moreinfo Why are doing this NMU? Does it fix any bugs? Have you read about the NMU procedure at https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu and followed it? Besides, it even has a wrong version suffix. -- WBR, wRAR signature.asc Description: PGP signature
Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "hamlib" * Package name : hamlib Version : 3.1.0-1+nmu1 Upstream Author : Kamal Mostafa, Colin Tuckley * URL : https://sourceforge.net/projects/hamlib/ * License : LGPLv2 Section : hamradio It builds those binary packages: libhamlib++-dev - Development C++ library to control radio transceivers and receive libhamlib-dev - Development library to control radio transceivers and receivers libhamlib-doc - Documentation for the hamlib radio control library libhamlib-utils - Utilities to support the hamlib radio control library libhamlib2 - Run-time library to control radio transceivers and receivers libhamlib2++c2 - Run-time C++ library to control radio transceivers and receivers libhamlib2-perl - Run-time perl library to control radio transceivers and receivers libhamlib2-tcl - Run-time Tcl library to control radio transceivers and receivers lua-hamlib2 - Run-time Lua library to control radio transceivers and receivers python-libhamlib2 - Run-time Python library to control radio transceivers and receive To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hamlib Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hamlib/hamlib_3.1.0-1+nmu1.dsc More information about hamlib can be obtained from https://sourceforge.net/projects/hamlib/ Changes since the last upload: * NMU * New upstream release * Changed manpages directory in manpage-hyphen-fixes.patch * Added Lua binding * Fixed broken libhamlib2-tcl package * Bump Standards-version to 3.9.8 Regards, Ervin Hegedüs
Re: mpgrafic - mpirun test program as root in automatic build
Paul Wisewrites: > On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote: > >> Also when using cowbuilder? At least I see the whole build done by root >> when running in my cowbuilder chroot. That was the point that lead to >> the trouble here... > > Yep. I tested this with id and override_dh_auto_* in cowbuilder: > > fakeroot debian/rules clean >debian/rules override_dh_auto_clean > uid=0(root) gid=0(root) groups=0(root),1234(pbuilder) > debian/rules build >debian/rules override_dh_auto_configure > uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder) >debian/rules override_dh_auto_build > uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder) >debian/rules override_dh_auto_test > uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder) > fakeroot debian/rules binary >debian/rules override_dh_auto_install > uid=0(root) gid=0(root) groups=0(root),1234(pbuilder) OK, I finally found it: I had a line BUILDUSERNAME= in my .pbuilderrc, which was obviously interpreted as root. Thanks Ole
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
On 17/01/17 18:30, Niels Thykier wrote: >>> E: libshibsp7: postinst-must-call-ldconfig >>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 > > This lintian error: > > * is aimed at stretch or later, and > * should be ignored for stable and stable-backports After having overridden this lintian error, it turns out it was a bit of a red herring: piuparts still reports files left after purging. > 0m39.2s 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 So is the postrm script from shibboleth-sp2-utils not executed? signature.asc Description: OpenPGP digital signature
Bug#851756: RFS: telegram-desktop/1.0.0-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "telegram-desktop" * Package name: telegram-desktop Version : 1.0.0-2~rc2 Upstream Author : John Preston* URL : https://desktop.telegram.org/ * License : GPLv3 Section : net It builds those binary packages: telegram-desktop - official telegram messaging app To access further information about this package, please visit the following URL: https://mentors.debian.net/package/telegram-desktop Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * Fixed restart when choosing language * Made x32 build, but only inside chroot jail * Updated README for Debian * Renamed binary * Solve command-in-menu-file-and-desktop-file problem, fix icon links * Solve binary-or-shlib-defines-rpath lintian error * Initial build (Closes: #767418) Regards, Nicholas Guriev
Re: mpgrafic - mpirun test program as root in automatic build
On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote: > Also when using cowbuilder? At least I see the whole build done by root > when running in my cowbuilder chroot. That was the point that lead to > the trouble here... Yep. I tested this with id and override_dh_auto_* in cowbuilder: fakeroot debian/rules clean debian/rules override_dh_auto_clean uid=0(root) gid=0(root) groups=0(root),1234(pbuilder) debian/rules build debian/rules override_dh_auto_configure uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder) debian/rules override_dh_auto_build uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder) debian/rules override_dh_auto_test uid=1234(pbuilder) gid=1234(pbuilder) groups=1234(pbuilder) fakeroot debian/rules binary debian/rules override_dh_auto_install uid=0(root) gid=0(root) groups=0(root),1234(pbuilder) -- bye, pabs https://wiki.debian.org/PaulWise
Bug#851696: marked as done (RFS: python-qtpy/1.2.0-1)
Your message dated Wed, 18 Jan 2017 10:18:08 + with message-id <1484734688.18572.27.ca...@gmail.com> and subject line Re: Bug#851696: RFS: python-qtpy/1.2.0-1 has caused the Debian Bug report #851696, regarding RFS: python-qtpy/1.2.0-1 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.) -- 851696: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851696 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 "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 --- End Message --- --- Begin Message --- Uploaded by Fred Picca--- End Message ---
Bug#851606: RFS: rmlint/2.4.6-1 [ITP]
Hi Carlos, Carlos Maddela wrote: >rmlint (2.4.6-1) unstable; urgency=medium > > * Initial upload to Debian. Thanks to Axel Beckert for getting >it all started. (Closes: #845155) > > -- Carlos MaddelaTue, 17 Jan 2017 04:45:28 +1100 Thanks a lot for taking care of the rmlint Debian package! I'll surely have a look it, but chances are high that I will do so only after 24th of January due to the imminent freeze in Testing. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
On 17/01/17 18:30, Niels Thykier wrote: >>> E: libshibsp7: postinst-must-call-ldconfig >>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 > > This lintian error: > > * is aimed at stretch or later, and > * should be ignored for stable and stable-backports Thanks Niels! :) That's a bit strange though because I'm running lintian from stable (2.5.30+deb8u4). It wouldn't surprise me if I were running a more recent version. I'll create an override for this test in jessie-backports then. Cheers, Etienne signature.asc Description: OpenPGP digital signature
Re: mpgrafic - mpirun test program as root in automatic build
Paul Wisewrites: > 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. Also when using cowbuilder? At least I see the whole build done by root when running in my cowbuilder chroot. That was the point that lead to the trouble here... Best Ole
Re: mpgrafic - mpirun test program as root in automatic build
On Wed, 18 Jan 2017, Paul Wise wrote: 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. Thanks for the clarification :). That's consistent with my experience, and seems like reasonable policy. Cheers Boud