Bug#845469: marked as done (RFS: ranger/1.8.1-0.1 [NMU])
Your message dated Wed, 25 Jan 2017 07:48:01 + (UTC) with message-id <2023944939.21038848.1485330481...@mail.yahoo.com> and subject line Re: Bug#845469: RFS: ranger/1.7.2+git20161104-0.1 [NMU] has caused the Debian Bug report #845469, regarding RFS: ranger/1.8.1-0.1 [NMU] 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.) -- 845469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845469 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 "ranger" * Package name: ranger Version : 1.7.2+git20161104-0.1 Upstream Author : [Roman Zimbelmann * URL : http://ranger.nongnu.org * License : GPL-3 Section : utils It builds those binary packages: ranger - File manager with an ncurses frontend written in Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ranger Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/ranger/ranger_1.7.2+git20161104-0.1.dsc Changes since the last upload: * Non-maintainer upload. * Merged lastest upstream git version. (Closes: #829114) * debian/patches: - Refresh 0002-make-sensible-decisions-on-which-pager-and-editor.patch. - Drop 0003-honour-TMPDIR-environment-variable.patch - included upstream. - Rename 0004-closes-772351-thanks-Raphael-Geissert.patch to 0003-closes-772351-thanks-Raphael-Geissert.patch. * debian/control: - Updated Standard-version to 3.9.8. - Move sudo from Recommends to Suggests. (Closes: #771803) * Bump debhelper version to 10. * Add debian/lintian-overrides. Regards, Mateusz Łukasik --- End Message --- --- Begin Message --- Hi, >ok but you still: >- have to restrict changes to a minimum necessary set (e.g. no bumping of >stuff) >- have to provide a debdiff on the bugs you close with what you want to be >sponsored, and tag it patch/pending >- explain why you are not packaging 1.7.2 but 1.7.2+something. > >For NMU stable releases are somewhat appreciated, unless you have reasons >for having a snapshot (also cherry-picks of particular upstream commits >are fine). > >and please explain why the new release is useful to Debian (new features? bugs >fixed?) > >according to upstream changelog it seems really about just bugfixes, so it >should be fine) I did the work, updated copyright file and uploaded in deferred/10 G.--- End Message ---
Bug#777651: marked as done (RFS: syncterm/1.0+dfsg-1 [ITP] -- BBS terminal program from Synchronet)
Your message dated Wed, 25 Jan 2017 04:29:09 + with message-id and subject line closing RFS: syncterm/1.0+dfsg-1 [ITP] -- BBS terminal program from Synchronet has caused the Debian Bug report #777651, regarding RFS: syncterm/1.0+dfsg-1 [ITP] -- BBS terminal program from Synchronet 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.) -- 777651: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777651 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 "syncterm" Package name: syncterm Version : 20141022+dfsg-1 Upstream Author : Deuce URL : http://syncterm.bbsdev.net/ License : LGPL Section : comm It builds those binary packages: syncterm - BBS terminal program from Synchronet syncterm-dbg - BBS terminal program from Synchronet (debug symbols) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/syncterm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/syncterm/syncterm_20141022+dfsg-1.dsc Changes since the last upload: Initial release (Closes: #739035) Hi all!, im search again for sponsor, last guy sems to be very busy, he help me very much to make this package, but at this time lost connection with that person. Saludos! -- Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar --- End Message --- --- Begin Message --- Package syncterm has been removed from mentors.--- End Message ---
Re: HELP: Fixing a debconf bug in proftpd
On Tue, 24 Jan 2017 22:47:00 +, Niels Thykier wrote: > > 1. Would anybody so kind to have a look at this issue? It is our show > > stopper to get back into testing. > > From a /very quick glance/, it looks like the package is basically using > "debconf as a registry". > > Longer version: In a "config" script, the debconf questions should be > "re-seeded" with the current default value /as defined in the actual > configuration file/ (rather than assuming the debconf database is up to > date). > See [localepurge template file] for an way of how to do this (ymmv). There's a more or less ready to use example also in debconf-devel(7) (scroll down to "Config file handling"). Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Pink Floyd: Comfortably numb signature.asc Description: Digital Signature
Bug#852504: RFS: udfclient/0.8.7-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "udfclient" * Package name: udfclient Version : 0.8.7-1 Upstream Author : Reinoud Zandijk * URL : http://www.13thmonkey.org/udfclient/ * License : Clarified Artistic License Section : otherosfs It builds those binary packages: udfclient - userland implementation of the UDF filesystem To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udfclient Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udfclient/udfclient_0.8.7-1.dsc More information about udfclient can be obtained from http://www.13thmonkey.org/udfclient/. Changes since the last upload: * New upstream release. Regards, Pali Rohár signature.asc Description: This is a digitally signed message part.
Re: HELP: Fixing a debconf bug in proftpd
Hilmar Preuße: > Hi, > > we got bug #820984 on debconf a while ago. I'm not very familiar w/ > debconf, hence I had a look into the templates/config delivered w/ > debconf itself. > I'm my eyes the code in proftpd is about a 1:1 copy of the code in > debconf, nevertheless it does not work as expected. > > 1. Would anybody so kind to have a look at this issue? It is our show > stopper to get back into testing. > 2. Is that bug even RC or could we lower it to important and address it > once we're back in testing? > > Many thanks, > Hilmar Hi, >From a /very quick glance/, it looks like the package is basically using "debconf as a registry". Longer version: In a "config" script, the debconf questions should be "re-seeded" with the current default value /as defined in the actual configuration file/ (rather than assuming the debconf database is up to date). See [localepurge template file] for an way of how to do this (ymmv). Rationale: Users update their configuration files (and not the debconf database). If you use the values from the configuration file, the user receives what they expect. If you use the debconf database, the user gets what they selected when they last configured the package (which can be many years older than their last change to their configuration files). Thanks, ~Niels [localepurge template file]: https://anonscm.debian.org/cgit/collab-maint/localepurge.git/tree/debian/localepurge.config#n89
Re: HELP: Fixing a debconf bug in proftpd
On 28.11.2016 21:24, Hilmar Preuße wrote: Hi, > we got bug #820984 on debconf a while ago. I'm not very familiar w/ > debconf, hence I had a look into the templates/config delivered w/ > debconf itself. > I'm my eyes the code in proftpd is about a 1:1 copy of the code in > debconf, nevertheless it does not work as expected. > > 1. Would anybody so kind to have a look at this issue? It is our show > stopper to get back into testing. > We're back in testing, but marked for autoremoval again. Would anybody be so kind to have a look at this? Attached is the config and the templates file. Many thanks! > 2. Is that bug even RC or could we lower it to important and address it > once we're back in testing? > At least this question is answered: it is an RC bug. Hilmar -- http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org # These templates have been reviewed by the debian-l10n-english # team # # If modifications/additions/rewording are needed, please ask # debian-l10n-engl...@lists.debian.org for advice. # # Even minor modifications require translation updates and such # changes should be coordinated with translators and reviewers. Template: shared/proftpd/inetd_or_standalone Type: select __Choices: from inetd, standalone Default: standalone _Description: Run proftpd: ProFTPD can be run either as a service from inetd, or as a standalone server. Each choice has its own benefits. With only a few FTP connections per day, it is probably better to run ProFTPD from inetd in order to save resources. . On the other hand, with higher traffic, ProFTPD should run as a standalone server to avoid spawning a new process for each incoming connection. #!/bin/sh set -e # Source debconf library. . /usr/share/debconf/confmodule action=$1 version=$2 db_title ProFTPD configuration db_set shared/proftpd/inetd_or_standalone standalone db_input high shared/proftpd/inetd_or_standalone || true db_go || true
Re: git-p4 package?
On Tue, Jan 24, 2017 at 11:48:24AM +, Luke Diamand wrote: > Is that normal for a package maintainer's email address? It's not, but Gerrit Pape hasn't made an upload of the package since 2013. I guess that those in the Uploaders field are the de facto maintainers. -- Sean Whitton signature.asc Description: PGP signature
Re: virtual packages, libraries, and dpkg-shlibdeps
j...@acorntoolworks.com (J.T. Conklin) writes: > I've tried adading a debian/shlibs file to map the library name to the > virtual package name. I may be just getting the syntax wrong, or perhaps > I'm barking up the wrong tree. It turns out I had a problem in the *.shlibs files where I used dashes instead of underscores in the library names. So while my approach works, I still welcome criticism/comments on the overall approach. Thanks in advance, --jtc
Re: Preference for build or debhelper installing systemd unit files?
Andreas Henriksson writes:
> Hello J.T. Conklin,
>
> On Wed, Jan 11, 2017 at 09:49:43AM -0800, J.T. Conklin wrote:
>> This question is related to components Dell EMC (my current employer)
>> are contributing to the Linux Foundation's openswitch project.
>>
>> With debhelper, systemd unit files can be installed by a package's build
>> (ie. the Makefile installs them in $DESTDIR/lib/systemd/system/...) or
>> they can be put in the debian/.service and dh_systemd_* will
>> copy them to the package. In both cases, the dh_systemd_* scripts
>> ensure that the proper boilerplate to enable/disable the service is
>> added to the package's {post,pre}{inst,rm} scriptlets.
>>
>> My question, in the case where the same organization/people are
>> responsible for both the software and the debian packaging, is whether
>> there is a preference of which method is used.
>
> Please do cooperate with your upstream on creating the best possible
> service files. For example sometimes it might be complicated to work out
> exactly which security restriction features you can turn on or not in a
> service file, hopefully with upstreams help you can work it out.
> Normally service files should not need to be distro specific.
Thanks Andreas,
Since Dell is contributing the content and the packaging, in effect we
are our own "upstream". While this gives us a lot of flexibility (some
would say "rope") to produce something that works, but not necessarily
doing the right thing. And since we own both halves, there is no excuse
not to follow best practices.
> This means prefer to *not* carry the service files in debian/*.service,
> because this directory is part of your debian delta (not upstream).
>
> At the same time it's not absolutely necessary for upstream to have
> Makefile code to install the files, sometimes they're just available in
> an example directory. In that case you can have them installed by just
> adding them to debian/foo.install
>
> Also, if there's some distro-specific thing you want to enable on top of
> the upstream provided service file you can handle that as a regular
> patch in debian/patches/foo.patch (which would be better than carrying
> your own copy in debian/foo.service which will sooner or later become
> outdated compared to upstreams).
>
> In general my recommendation is to always try to keep your debian/
> directory as minimal as possible. Everything you can and is useful to
> share with upstream you should try to push upstream.
These points are well taken, even if we're our own upstream. Keeps
separation of concerns well defined.
Thanks again,
--jtc
virtual packages, libraries, and dpkg-shlibdeps
This question is related to components Dell EMC (my current employer)
are contributing to the Linux Foundation's openswitch project.
Our architecture is made up of platform independent components/packages,
which are adapted to specific hardware platforms (ie. switches) by with
platform specific packages that provide a common API.
Each concrete platform specific package implementation "provides" a
virtual package corresponding to that API.
However, we've found a problem that when the virtual package is listed
as a build dependency, when ${shlibs:Depends} is expanded, it contains
the concrete package name that was used during the build, rather than
the virtual package. This now ties what should be a platform independent
package to specific hardware.
Although we can work around this by avoiding ${shlibs:Depends} and
maintaining the list of dependencies manually, this adds overhead and
a source of potential errors.
I've tried adading a debian/shlibs file to map the library name to the
virtual package name. I may be just getting the syntax wrong, or perhaps
I'm barking up the wrong tree.
Any advice or pointers would be most welcome,
--jtc
Bug#852474: RFS: hdparm/9.51+ds-1 -- tune hard disk parameters for high performance
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: mailatgo...@gmail.com Dear mentors, I am looking for a sponsor for my package "hdparm": * Package name: hdparm Version : 9.51 Upstream Author : Mark Lord * URL : http://sourceforge.net/projects/hdparm/files/hdparm/ * License : hdparm Section : Admin It builds following binary packages: - hdparm To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hdparm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hdparm/hdparm_9.51+ds-1.dsc More information about hdparm can be obtained from https://anonscm.debian.org/cgit/collab-maint/hdparm.git Changes since last upload: * New upstream version 9.51+ds * Bump debhelper version to v10 * Refresh and update patches, drop spelling.patch apllied by upstream * Add makefile.patch removing hardcoded "-j4" and LDFALGS, drop fix_ldflags.patch * Drop d/hdparm.preinst as it is substituted by d/hdparm.maintscript Best regards, Alex
Bug#851884: RFS: fdkaac/0.6.3-1
Sean Whitton writes: > I'm sorry for not conducting a more through review before, but I've > found the following remaining issues. Hopefully you can resolve them > quickly and I can upload for you. > > 1. The package does not build against sid because the build-dep >libfdk-aac-dev is not installable right now. Any ideas? libfdk-aac-dev:amd64 (0.1.4-2) installs just fine on my newly created sid virtual machine. I have also successfully built and installed the package on said sid machine. Could it be a problem that the packages I upload to mentors are built on wheezy? If so, I can just build and upload from the sid machine. > 2. The change to Vcs-Git is not mentioned in the changelog. Fixed and reuploaded to mentors. > Optional suggestion: > > 3. Your git repository does not exactly match the source package you >have provided. I've attached the diff. It's good practice to have >your git HEAD exactly match what you want to be uploaded. But if >this is difficult to fix, just ignore it and I will work from your >source package. From the diff I see the issue is different line terminators. But both my git repository and the source package have CRLFs (according to file(1)). I am using git-buildpackage with pristine-tar to build this package. I've checked and the .orig.tar.gz I was using is identical to the one created by pristine-tar, so I do not know where the LFs are coming from. Could you suggest a way to debug this? Thanks, -- Marius Gavrilescu signature.asc Description: PGP signature
Bug#852295: RFS: freecell-solver/4.8.0-1 NMU
Hello Shlomi, you need to make the package build against sid in less than one day.:q vi I did the changes and I'm attaching them here, lots of conflicts between fcs_enums.h and patsolve-shlomif/patsolve/fcs_enums.h fcs_dllexport.h and patsolve-shlomif/patsolve/fcs_dllexport.h (I'm removing them in clean target) and a bad include guard on cmd_line_enum.h http://debomatic-amd64.debian.net/distribution#unstable/freecell-solver/4.8.0-0.1/buildlog please make it build, or I won't be able to sponsor it in time for the freeze G. >I didn't look into the packaging, only into the diff between versions, >feel free to continue reviewing it. (thanks!)G. freecell-solver_4.8.0-0.1.debian.tar.bz2 Description: application/bzip
Re: git-p4 package?
Hi! Last week I followed up about how to proceed with this package On 17 January 2017 at 08:15, Luke Diamand wrote: > [+Gerrit Pape's correct email address] But p...@smarden.org seems to be bouncing. I eventually received this: > Hi. This is the qmail-send program at a.mx.smarden.org. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > : > No delivery confirmation received. Is that normal for a package maintainer's email address? Thanks Luke > > 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!
Bug#852415: RFS: scap-security-guide/0.1.31-3 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "scap-security-guide" Package name: scap-security-guide Version : 0.1.31-3 Upstream Author : Watson Yuuma Sato (ws...@redhat.com) URL : https://www.open-scap.org/security-policies/scap-security-guide/ License : unlicenced (see https://github.com/OpenSCAP/scap-security-guide/blob/master/LICENSE) Section : admin It builds those binary packages: ssg-base - SCAP Security guide base content and documentation ssg-debian8 - SCAP Guides and benchmarks targeting Debian 8 ssg-firefox - SCAP Guides and benchmarks targeting Firefox Browser ssg-jre- SCAP Guides and benchmarks targeting Java Runtime Environment ssg-ubuntu1604 - SCAP Guides and benchmarks targeting Ubuntu 16.04 ssg-webmin - SCAP Guides and benchmarks targeting Webmin To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scap-security-guide Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scap-security-guide/scap-security-guide_0.1.31-3.dsc More information about scap-security-guide can be obtained from https://www.open-scap.org/security-policies/scap-security-guide The repository is on https://github.com/OpenSCAP/scap-security-guide Changes since the last upload: * Add XCCDF benchmarks and guides for JRE and Webmin About SCAP-security-guide: SCAP-security-guide works with the OpenSCAP tool, which is already packaged in Debian. The goal of this package is to deploy SCAP XCCDF Benchmarks and Guides for various targets not deployed by the OpenSCAP core package, but supported by the SCAP-security-guide community in which I work as contributor for Ubuntu, Debian and ANSSI best practices. Using these guides/benchmarks, it is possible to validate conformity of Debian-based deployment against standard security policies such as ANSSI Best-practices, PCI-DSS, NIST SP-800... and to launch remediation scripts when needed. Using the OpenSCAP ecosystem, it is possible to manage the security policy of a complete infrastructure, when launching OpenSCAP tool with the above benchmarks through ssh (for e.g.) or on VM or docker templates. Regards, Philippe Thierry
